Методика применения 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 файлы, он это увидит и предложит соответствующие действия.

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

[fill]

Наверно придется писать большими буквами (т.к. уже устал это повторять) ВСЕ ВАШИ ПРОБЛЕМЫ ИЗ-ЗА ИДЕОЛОГИИ ПРОЕКТИРОВАНИЯ ВЗЯТОЙ ИЗ PCAD-а.
1. Вы тащите все пины на символы - это источник ваших дальнейших проблем. Помимо того что они просто загромождают схему. Они например приведут к следующему:
Есть два пина, один с сигналом, другой не задействован. Соответственно один попал на "сигнальный" символ, другой на "неподсоединенный" символ. При перестановке сигнала между этими пинами, на обеих символах окажется бывший незадействованный пин, а ранее задействованный станет не размещенным. Поэтому придется перегенерировать все символы или решать эту проблему вручную. Эта же проблема будет при создании Full_PCB_Simbols.
2. Создание отдельных символов питания и т.п. удобно для построения многолистовой не иерархической схемы, и чревато дополнительными шагами для приведения схемы в порядок при итерациях перестановок.
3. Наиболее простой и производительный способ - это на символы выносить только пины с назначенными сигналами и не создавать отдельных пинов\символов для питания и т.п. В этом случае вы имеете функциональный символ на котором присутствуют все сигналы (многие в виде шин) который просто размещаете на вашей схеме и подключаете к нему цепи платы. Все остальные цепи\пины питания и т.п присутствую в PDB сгенеренном из IOD (раздел Supply_NC) и появляются на плате как глобальные цепи. Именно в этом случае нет никаких доп. шагов при различных перестановках, т.к. все изменения будут касаться только подсхемы генерируемой автоматом из IOD
4. Т.к. вы использовали отдельные символы питания и т.п. IOD сгенерировал две схемы. Первая стандартная используемая напрямую, т.к. является подсхемой для функционального символа. Вторая ( _top) для отображения "внешнего интерфейса", ее можно использовать только для копирования ее кусков на собственную схему. Если внимательно посмотрите на схему _top то увидите, что в отличие от подсхемы функционального символа на ней нет портов для связи цепей по иерархии и соответственно нет и ее символа.

[Frederic]

3. Наиболее простой и производительный способ - это на символы выносить только пины с назначенными сигналами и не создавать отдельных пинов\символов для питания и т.п. В этом случае вы имеете функциональный символ на котором присутствуют все сигналы (многие в виде шин) который просто размещаете на вашей схеме и подключаете к нему цепи платы. Все остальные цепи\пины питания и т.п присутствую в PDB сгенеренном из IOD (раздел Supply_NC) и появляются на плате как глобальные цепи. Именно в этом случае нет никаких доп. шагов при различных перестановках, т.к. все изменения будут касаться только подсхемы генерируемой автоматом из IOD

сгенерил только один функциональный символ (на рис. видно)
и не получается сигналы JTAG подключить
в AugmentedPins.txt видно что нет соединения "U1 | A21| <unconnected pin> " и т.д. в части JTAG
соответстенно в Ехр в разделе No connect Supply_NC пины JTAG присутствуют

как JTAG подключить ???

Эскизы прикрепленных изображений

 

[Inpharhus]

как JTAG подключить ???

В 3м шаге генерации в Symbol Wizard'e есть пункт "CONFIG and JTAG pins", возможно у вас просто выбрано "Do not use CONFIG and JTAG pins"

[Frederic]

В 3м шаге генерации в Symbol Wizard'e есть пункт "CONFIG and JTAG pins", возможно у вас просто выбрано "Do not use CONFIG and JTAG pins"

совершенно верно и это сделано сознательно.
если выбрать "использовать" то получается символ с сигналами JTAG и vref, а я НЕ ХОЧУ его иметь на схеме и контролировать.
символ питание убрал (стало место больше на схеме ) - цепи стали глабальными
хочу сделать все как пишет fill в п.3 , повторю еще
"3. Наиболее простой и производительный способ - это на символы выносить только пины с назначенными сигналами и не создавать отдельных пинов\символов для питания и т.п. В этом случае вы имеете функциональный символ на котором присутствуют все сигналы (многие в виде шин) который просто размещаете на вашей схеме и подключаете к нему цепи платы. Все остальные цепи\пины питания и т.п присутствую в PDB сгенеренном из IOD (раздел Supply_NC) и появляются на плате как глобальные цепи. Именно в этом случае нет никаких доп. шагов при различных перестановках, т.к. все изменения будут касаться только подсхемы генерируемой автоматом из IOD"

[Asb]

Э-э-э, а PCB символ под этим функциональным есть? А JTAG-pin'ы на нем есть ?
Вообще говоря я делаю немного по другому: В редакторе символов создаю свой конфигурационный символ и затем импортирую его в IOD как PCB символ.
В таблицу сигналов при этом, эти выводы можно не добавлять. В общем получается довольно удобно.
P.S. Маршрут DC-IOD-EXP, но не думаю, что в данном случае это существенно.

[Frederic]

Э-э-э, а PCB символ под этим функциональным есть? А JTAG-pin'ы на нем есть ?
Вообще говоря я делаю немного по другому: В редакторе символов создаю свой конфигурационный символ и затем импортирую его в IOD как PCB символ.
В таблицу сигналов при этом, эти выводы можно не добавлять. В общем получается довольно удобно.
P.S. Маршрут DC-IOD-EXP, но не думаю, что в данном случае это существенно.

конечно PCB символ под этим функциональным есть - иначе не выгрузить его в DxD
а вот JTAG-pin'ы на нем нет - в этом и загвоздка

я работаю в локальной базе, т.е. без ЦБ
и принципиально не хочу что то ваять в SE и импортироватть в IOD

как обычно без fill не разобраться

[Asb]

а вот JTAG-pin'ы на нем нет - в этом и загвоздка

А почему бы их туда не добавить в ручную из Pin-list (без Simbol Wizard'a). Понятно, что автоматизация не ice, но работать вроде должно.
P.S. Symbol Wizard'ом у меня вообще как то не очень получается пользоваться.