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

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

[SM]

Подскажите пожалуйста такую вещь по IOD:

- ПЛИСка Lattice LFXP2-5E-5MN132

Есть входная цепь "INCK", стандарт IO LVDS25, которая должна быть подключена на входной сигнал одной из двух PLL.
Я ставлю ей стандарт LVDS25, ставлю тип PLLDIFF, после чего assign говорит, что нету таких пинов. Хотя я то точно знаю, что есть, а именно
PT8A__ULC_GPLLT_IN_A__True_of_PT8B / PT8B__ULC_GPLLC_IN_A__Comp_of_PT8A
и второй вариант - PB26A__LRC_GPLLT_IN_A__True_of_PB26B / PB26B__LRC_GPLLC_IN_A__Comp_of_PB26A

В чем дело и как правильно тут поступить?

Дальше хуже. Кроме этого есть еще пины IN, тоже LVDS25, и это та же физическая цепь, что и INCK (ну т.е. входной сигнал должен прийти одновременно и на dedicated вход PLL-ки, и на generic IO. Ну надо так. Там ШИ-модулированный 150-Мбитный поток данных), и правило по ее размещению - должна быть в том же банке, что и INCK. Тоже не понял, как это задать.

[Inpharhus]

Есть входная цепь "INCK", стандарт IO LVDS25, которая должна быть подключена на входной сигнал одной из двух PLL.
Я ставлю ей стандарт LVDS25, ставлю тип PLLDIFF, после чего assign говорит, что нету таких пинов. Хотя я то точно знаю, что есть, а именно
PT8A__ULC_GPLLT_IN_A__True_of_PT8B / PT8B__ULC_GPLLC_IN_A__Comp_of_PT8A
и второй вариант - PB26A__LRC_GPLLT_IN_A__True_of_PB26B / PB26B__LRC_GPLLC_IN_A__Comp_of_PB26A

Рискну предположить что нужные пины имеют переключаемый тип и он в данный момент отличный от PLLDIFF, хотя я не совсем понял что именно вы делаете, да и IOD под рукой нет.

Второй раз повторяю - берем даташит и тупо создаем символ. Сигналы и питания назначаем при рисовании схемы. Назначение различных групп свапа вообще бесполезно, об этом тоже уже говорилось. Кроме того, группы свапа назначаются в pdb и никак не могут повлиять на создание символа.

Кому бесполезно, а кому нет. IOD генерит не только символ, но и pdb, главное не забыть о создании cell с указанным IOD именем.
Вот кстати удивляюсь этому, что сложно было интегрировать в IOD сразу все необходимые cell'ы? Нарисовать не сложно, но время...

Это Ваш ответ на вопрос о сигналах на этапе создания компонента? Первый раз слышу о сигналах в символе и pdb(кроме сигналов питания). Старею, наверное.

IOD на выходе может создавать схематик с символами и уже присоединенными цепями к пинам.

Сообщение отредактировал Inpharhus - Sep 17 2009, 09:37

[SM]

Рискну предположить что нужные пины имеют переключаемый тип и он в данный момент отличный от PLLDIFF, хотя я не совсем понял что именно вы делаете, да и IOD под рукой нет.

Я хочу соптимизировать подключение цепей к пинам исходя из заданных мной правил, как это показывал fill в ролике, где в IOD перенесено размещение компонентов на плате, и видны все цепи. Потом оттрассировать плату. После чего хочу сгенерировать verilog-шапку с получившимся назначением пинов, и начать писать описание устройства, реализованного в этой ПЛИС.

А вы в окне Pins на этих пинах установили нужный тип - я так понимаю они многозадачные?

А там предлагают только DIFF или IO, а PLLDIFF нету. DIFF не катит, так как свопится с чем попало.... А можно как-то "custom" тип добавить или сделать просто DIFF, но добавить констрейн, что только либо эта пара, либо та? Да и как я уже понял, в окне Pins не надо тип выставлять, IOD сам смотрит, есть ли нужный тип в списке, и если есть, то коннектит.

[Inpharhus]

А что - типы пинов переключать можно самому? Я думал IOD сам знает все варианты всех типов для всех пинов.

Не можно, а нужно Он-то знает, соответственно доступны для переключения только доступные для этих пинов варианты.

А там предлагают только DIFF или IO, а PLLDIFF нету. DIFF не катит, так как свопится с чем попало.... А можно как-то "custom" тип добавить или сделать просто DIFF, но добавить констрейн, что только либо эта пара, либо та?

Присвоить DIFF, выбрать 2 нужные пары пинов и присвоить им собственную группу свопирования.

[SM]

Присвоить DIFF, выбрать 2 нужные пары пинов и присвоить им собственную группу свопирования.

Ага, понял, спасибо. А как теперь поступить со второй частью вопроса - другой сигнал, который тоже DIFF, и правило для него "в том же банке, что и этот сигнал, но на любой дифпаре".

Вообще-то IOD тип пина сам меняет только в случае изменения типа сигнала к нему подключенного. Т.е. если сигнал назначен нами в пин и мы поменяли тип сигнала.

Ну как же так? Я вот описал пачку сигналов типа DIFF, сделал Assign pins with overwrite им, и он сам все подключил, куда надо причем, и поменял тип с IO на DIFF.

ЗЫ.
А можно как-то руками залезть в БД IOD-а и вручную нужным пинам добавить тип PLLDIFF? IMHO это упростило бы жизнь...

[Inpharhus]

Символ, что ли, нарисовать? С 1760 ногами? Ой, как страшно Ну допустим, за рабочий день справлюсь... Ну ладно, так и быть, специально для Вас - за два А если меня посадят библиотекарем на постоянку, заточу соответствующий инструмент, и буду выдавать такие страшные символы ну максимум за пару часов. А что?

А то что вы сами ответили на вопрос целесообразности IOD - экономия времени. А если "заточить" IOD, то и подгонять под ГОСТы почти нечего будет...
Повторю еще раз - IOD одновременно генерит еще и pdb, а это тоже время.
В любом случае сомневаюсь что какой-либо заточенный инструмент будет быстрее IOD по отношению к фпга, кроме случаев выхода новых плис еще не включенных в IOD и то лишь до момента выхода соответствующих библиотек

Ага, понял, спасибо. А как теперь поступить со второй частью вопроса - другой сигнал, который тоже DIFF, и правило для него "в том же банке, что и этот сигнал, но на любой дифпаре".

Ну наверно все оставшиеся дифпары банка объединить в другую группу свопирования и прицепить к какой-нибудь дифпаре этот сигнал.

А можно как-то руками залезть в БД IOD-а и вручную нужным пинам добавить тип PLLDIFF? IMHO это упростило бы жизнь...

Если разберетесь в синтаксисе .\IOD\library\devices\... далее производитель, модель фпга и редактирование файла *.dev

Сообщение отредактировал Inpharhus - Sep 17 2009, 09:58

[SM]

Ну наверно все оставшиеся дифпары банка объединить в другую группу свопирования и прицепить к какой-нибудь дифпаре этот сигнал.

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

В принципе да, но надо изучать документацию.

Спасибо еще раз, и Impharus-у тоже за наводку на .dev файлы, там по ходу можно и свои новые типы добавлять тоже.

[Inpharhus]

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

Насколько я знаю - нет. IOD генерит стандартный pdb, там же это невозможно?
А там их и не будет, группы свопирования имеют условные названия которые при генерации pdb становятся некими группами Просто для удобства IOD сразу часть пинов определяет в стандартные группы, но это наверняка прописано в движке IOD, а не в файле .dev

P.S. А цепи по-моему вообще не имеют групп свопирования.

Сообщение отредактировал Inpharhus - Sep 17 2009, 10:17

[SM]

Насколько я знаю - нет. IOD генерит стандартный pdb, там же это невозможно?

Так мне в pdb вообще группы свопирования не нужны. Мне нужно чтобы IOD все это знал. Что например на пару типа DIFFPLL, которая находится в группе свопирования DIFF_PLL_INPUTS, можно еще и два разных IO прицепить, если эти пины не заняты, и когда они IO, свопировать их по правилам свопа обычных IO...

P.S. А цепи по-моему вообще не имеют групп свопирования.

Имеют, имеют...

[Inpharhus]

Так мне в pdb вообще группы свопирования не нужны. Мне нужно чтобы IOD все это знал. Что например на пару типа DIFFPLL, которая находится в группе свопирования DIFF_PLL_INPUTS, можно еще и два разных IO прицепить, если эти пины не заняты, и когда они IO, свопировать их по правилам свопа обычных IO...

Так взаимодействие с проектом все равно через pdb происходит, если я всё правильно понимаю. Речь о маршруте DC-Exp, а с DxD не работал, не знаю как там.
Если работать в режиме синхронизации IOD с проектом думаю у вас всё получится. Когда надо - поменять группы свопирования и тип пинов...

[SM]

Так взаимодействие с проектом все равно через pdb происходит, если я всё правильно понимаю.

А как я понял - работа делается через аннотацию в Exp. А как в сам DxD - пока не знаю, я только начал делать символ и парт в IODе, ни в DxD, ни в Exp еще ничего не размещал. Но IOD спросил меня путь к проекту DxD-шному при создании IOD-ного проекта.

И... Я вообще не понимаю, на кой нужны группы свопирования в pdb, если все свопирование делается в IOD?

[fill]

А как я понял - работа делается через аннотацию в Exp. А как в сам DxD - пока не знаю, я только начал делать символ и парт в IODе, ни в DxD, ни в Exp еще ничего не размещал. Но IOD спросил меня путь к проекту DxD-шному при создании IOD-ного проекта.

И... Я вообще не понимаю, на кой нужны группы свопирования в pdb, если все свопирование делается в IOD?

Если внимательно посмотрите видео, то есть два варианта передачи PDB:
1. Через файл *.hkp - такой же путь используется для DC\DV - т.е. надо потом импортировать его в ЦБ или плату (намек тем кто это не заметил и всегда тащит все в ЦБ )
2. Через Local_PDB - сделан для DxD - т.е. данный файл при экспорте записывается в папку Integration и автоматически попадает в плату при прямой аннотации. Т.е. в случае DxD можно вообще не иметь ни символов ни PDB внутри ЦБ - процесс значительно ускоряется и упрощается.

Т.к свопировать можно и не выходя из Exp. - например есть у вас шина и надо переставить ее члены между собой, то и создаются группы свопирования в PDB - иначе это было бы невозможно и пришлось каждый раз переходить в IOD.

[SM]

2. Через Local_PDB - сделан для DxD - т.е. данный файл записывается в папку Integration и автоматически попадает в плату при прямой аннотации. Т.е. в случае DxD можно вообще не иметь ни символов ни PDB внутри ЦБ - процесс значительно ускоряется и упрощается.

Во - именно этот путь и есть наш

Т.к свопировать можно и не выходя из Exp. - например есть у вас шина и надо переставить ее члены между собой, то и создаются группы свопирования в PDB - иначе это было бы невозможно и пришлось каждый раз переходить в IOD.

Ну скажем так - мне это не нужно, так как я, как понял, все цепи ("нитки") увижу и из IOD. Да и сходить в IOD - это ведь просто переключиться в другое окно - мне не в напряг.

[Frederic]

Во - именно этот путь и есть наш

Ну скажем так - мне это не нужно, так как я, как понял, все цепи ("нитки") увижу и из IOD. Да и сходить в IOD - это ведь просто переключиться в другое окно - мне не в напряг.

не совсем так, при синхронизации из IOD в DxD д.б. закрыт DxD, IOD сам его откроет. не могу понять зачем это
да работаю без ЦБ, т.е. без символов и компанента.

главное не забыть о создании cell с указанным IOD именем.
Вот кстати удивляюсь этому, что сложно было интегрировать в IOD сразу все необходимые cell'ы? Нарисовать не сложно, но время...

но тогда надо несколько cell (с простыми площадками, площадки аддаптированные под ренгенконтрль, с переходными via, cell с микроvia ......)
а так для начала сгенери в PCB Matrix, но внимательно с cell Editor, если работать без ЦБ, то возможно удаление cell, не взирая что он используется в проекте

[SM]

не совсем так, при синхронизации из IOD в DxD д.б. закрыт DxD, IOD сам его откроет. не могу понять зачем это

Тааак.... Начинается... У меня IOD на одном компе, там нет DxD. А DxD на другом - там нет IOD. Такой раскордаж временный, из-за отсутствия линуксового IOD. Интересно, оно вообще получится так синхронизироваться? Я еще не успел попробовать синхронизацию.


А подправление .dev-файла руками на тему добавления типа PLLDIFF к нужным мне пинам сработало. Осталось таки въехать, можно ли задать такое правило свопа, навроде "цепь INCK должна быть подключена к пинам типа PLLDIFF, а цепь IN к пинам типа DIFF, и они обе обязаны быть в одном банке, но все равно в каком."