Методика применения I/O_Designer Опции

[fill]

Т.к. судя по всему многие до сих пор не понимают, что такое IOD и зачем он нужен, попытаюсь популярно объяснить это в приложении к ПЛИС:

1. Предположим мы начинаем новый проект платы в которой будет стоять ПЛИС(ы).
2. Проработали функционально наш проект и определили какие сигналы (цепи) будут подключены к ПЛИС.
3. Можно начинать определение ПЛИС, используя проект в IOD, сделать это можно несколькими путями:
а) Написали VHDL(Verilog) файл в котором есть "шапка", т.е. определены порты - соответственно его можно:
- прочитать в IOD и таким образом список сигналов окажется в IOD.
- передать разработчику ПЛИС (естественно если не он сам его сделал) для дальнейшего формирования функционально\структурного описания внутренности ПЛИС
б) Ввели сигналы непосредственно внутри IOD:
- можем сгенерить VHDL(Verilog) файл и передать разработчику ПЛИС.
4. Выбрали изготовителя ПЛИС, конкретный device и маршрут ПЛИС.
5. Сделали предварительное присвоение выводов внутри IOD.
6. Генерировали\нарисовали символ(ы) внутри IOD.
7. Экспортировали символы\PDB в DxDesigner.
8. Нарисовали схему платы в DxD.
9. Создали проект платы и сделали размещение.
10. Обратно аннотировали размещение в IOD.
11. Сделали перераспределение выводов для улучшения длин соединений и распутывания их.
12. Теперь надо связаться с разработчиком внутренности ПЛИС на предмет передачи ему информации о текущем распределении выводов. Передать ему можно любой файл из трех типов:
- P&R_Constraints_File (Actel (.pin, .gcf or .pdc), Altera (.csf or .qsf), Xilinx (.ucf), Lattice (.lpf)
- Pin Report File (Actel (.rpt), Altera (.pin), Xilinx (.pad or .csv), Lattice (.pad)
- FPGA Xchange File
Как правило любой из этих файлов могут прочитать (а также генерировать) системы разработки ПЛИС и таким образом ему не нужно будет в ручную определять выводы.
13. После того как разработчик ПЛИС одобрил это размещение или предложил свое (переделанное через такой же файл), вы решаете задачу трассировки платы. Походу этого естественно могут возникать вопросы дальнейших итерации по перераспределению выводов ибо как у разработчика платы может возникнуть потребность в этом, так и у разработчика ПЛИС - все это решается через процесс аннотаций и генерирования указанных выше обменных файлов. Процесс контролирует "Синхронизатор" - если изменились какие-либо подключенные к проекту IOD файлы, он это увидит и предложит соответствующие действия.

Естественно последовательность процесса и составные части каждый из вас сможет выбирать на свое усмотрение.

[Vadim]

1. Предположим мы начинаем новый проект платы в которой будет стоять ПЛИС(ы).

Предположим

2. Проработали функционально наш проект и определили какие сигналы (цепи) будут подключены к ПЛИС.

Ну, допустим

3. Можно начинать определение ПЛИС, используя проект в IOD, сделать это можно несколькими путями:
а) Написали VHDL(Verilog) файл в котором есть "шапка", т.е. определены порты - соответственно его можно:
- прочитать в IOD и таким образом список сигналов окажется в IOD.
- передать разработчику ПЛИС (естественно если не он сам его сделал) для дальнейшего формирования функционально\структурного описания внутренности ПЛИС
б) Ввели сигналы непосредственно внутри IOD:
- можем сгенерить VHDL(Verilog) файл и передать разработчику ПЛИС.

Я извиняюсь, но чтобы начинать определение ПЛИС, не нужно ничего, кроме Вашего любимого текстового редактора
И если уж так хочется сгенерить hdl-файл, а не набрать его ручками, никакие иоды не нужны. Достаточно скриптов

4. Выбрали изготовителя ПЛИС, конкретный device и маршрут ПЛИС.

Для этого иод не нужен

5. Сделали предварительное присвоение выводов внутри IOD.

Зачем? Предварительное присвоение выводов делается в схемном редакторе путем рисования схемы Для этого нам понадобятся библиотечные символы, схемный редактор и руки. Возможно даже голова, но никак не иод

6. Генерировали\нарисовали символ(ы) внутри IOD.
7. Экспортировали символы\PDB в DxDesigner.

Это ключевой момент. Если ПЛИС многоногая, и ее символ получается слишком большой, чтобы разместить ее на схеме, этот самый символ необходимо разбить на части. Причем я не верю, что существует ПЛИС, символ которой физически невозможно разместить на схеме. Это всегда можно сделать, но такой символ не будет удовлетворять гостам. Существует и другая причина побить символ на более мелкие - удобочитаемость. Во всех остальных случаях необходим один символ на одну ПЛИС, который рисуется штатными средствами используемого вами пакета разработки печатных плат. Таким образом, IOD предназначен лишь для разбиения символа ПЛИС на более мелкие, все остальное притянуто за уши. Имхо на всякий случай

8. Нарисовали схему платы в DxD.

Существует жизнь и вне DxD

9. Создали проект платы и сделали размещение.

Ну сделали

10. Обратно аннотировали размещение в IOD.

Это еще зачем?

11. Сделали перераспределение выводов для улучшения длин соединений и распутывания их.

Причем штатными средствами, без иодов

12. Теперь надо связаться с разработчиком внутренности ПЛИС на предмет передачи ему информации о текущем распределении выводов. Передать ему можно любой файл из трех типов:
- P&R_Constraints_File (Actel (.pin, .gcf or .pdc), Altera (.csf or .qsf), Xilinx (.ucf), Lattice (.lpf)
- Pin Report File (Actel (.rpt), Altera (.pin), Xilinx (.pad or .csv), Lattice (.pad)
- FPGA Xchange File
Как правило любой из этих файлов могут прочитать системы разработки ПЛИС и таким образом ему не нужно будет в ручную определять выводы.

Очень мило Ну если лень разработчику вручную определить выводы согласно имеющейся схеме, так и быть, я ему определю вручную. Затрачу я на это, ну, допустим, час. И что? А если очень хочется погенерить текстовые файлы, в моем распоряжении всегда есть всевозможные скриптовые языки

13. После того как разработчик ПЛИС одобрил это размещение или предложил свое переделанное (через такой же файл), вы решаете задачу трассировки платы. Походу этого естественно могут возникать вопросы дальнейших итерации по перераспределению выводов ибо как у разработчика платы может возникнуть потребность в этом, так и у разработчика ПЛИС - все это решается через процесс аннотаций и генерирования указанных выше обменных файлов. Процесс контролирует "Синхронизатор" - если изменились какие-либо подключенные к проекту IOD файлы, он это увидит и предложит соответствующие действия.

Перераспределение выводов делается путем правки схемы и прямой аннотации в плату без участия каких-либо посредников, которые непонятно что синхронизируют. И какие такие действия может предложить таинственный синхронизатор? Как у Жванецкого: "Продолжать движение!!!"?

[disel]

На создание компонета с ~700 ногами в ИОДе уходит час-два, это если не спешить. Это при том, что несколько групп свапирования, разные стандарты ввода-вывода, разные клоки, МГТ и т.д. И даже мысли не приходит что возможна ошибка с нумерацией, перепутыванием ног и прочими косяками. Изменения в сигналах делаются еще быстрее. ОДно из основных достоинств - это база по всем ПЛИС.
Даже думать не хочу сколько человеко-месяцев нужно чтобы без ошибки создать такой компонент без ИОД, а потом его править при изменении количества сигналов\банков и т.д.
Поэтому можно забить на все глюки ИОД, коих ни чуть не меньше чем в ДхД.

[Vadim]

На создание компонета с ~700 ногами в ИОДе уходит час-два, это если не спешить.

Допустим.

Это при том, что несколько групп свапирования, разные стандарты ввода-вывода, разные клоки, МГТ и т.д. И даже мысли не приходит что возможна ошибка с нумерацией, перепутыванием ног и прочими косяками.

Имхо, несерьезно. На этапе создания символа задача библиотекаря - тупо повторить даташит.

Изменения в сигналах делаются еще быстрее.

Извините, не понял, в каких таких сигналах?

ОДно из основных достоинств - это база по всем ПЛИС.

Сомнительное достоинство. Заходим на сайт производителя и скачиваем даташит.

Даже думать не хочу сколько человеко-месяцев нужно чтобы без ошибки создать такой компонент без ИОД, а потом его править при изменении количества сигналов\банков и т.д.

Т.е на создание компонента с 700 ногами без ошибок у Вас уйдет несколько человеко-месяцев? Не сочтите за наезд, но теперь я понимаю, что ИОД иногда полезен И не понимаю, зачем править созданный без ошибок компонент. Как в компоненте, серийно выпускаемой славной капиталистической промышленностью, может измениться количество сигналов (каких сигналов?) и банков? Это же не трансформер какой нибудь, а FPGA!!!