[fill 2]

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

 

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

[insector 0]

Александр, спасибо за описание, действительно - кратко, толково, без лишней воды.

Но, несмотря на безмерное уважение к Вам с моей стороны, по поводу продукта возникают некоторые вопросы:

 

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

Я, конечно, не махровый гуру, еще только учусь, но у нас все просто:

1. Сформировать перечень сигналов, которые пойдут в/на плис. Из них лишь небольшое кол-во является предопределенным, остальные свободные, поэтому это Я буду в декларативном порядке сообщать программисту какие сигналы на каких ножках будут, а не ОН мне. Т.к. ему это фиолетово, а мне на плате - нет. Случай с DDR модулем немного другой, но там тоже от программиста немного зависит.

2. Выслушать от программиста пожелания - какие бы он особые сигналы хотел видеть на спец. ножках, типа глобальных клоков.

3. Спокойно разводить плату.

4. Сообщить программисту где будут какие сигналы. И он за полчаса вручную их назначит.

 

В результате мне не нужно мучаться с IOD, писать там всякие описания и прочее. Как-то так, уж извините.

 

Может быть, конечно, если делать плату с 100 плисами, причем разными, через IOD это будет и удобнее. Я таких не делал. Но, если почитать, большинство народа, пройдя через кучу создания разных описаний, символов и наловив кучу глюков, остаются с недовольным осадком.

 

Случай, когда разводчик и программист в разных странах - не рассматриваю. Там - возможно.

[fill 2]

Тогда дополню:

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

2. IOD контролирует правильность назначения сигналов. Я уже видел проекты, где разработчики плат сделали ошибки в назначении сигналов "не в те выводы" - когда делали схему и плату они не всегда дотошно изучали datasheets. А затем схемотехники, заказавшие эти платы у них, разбирались почему они не работают и пытались ускорить процесс поиска таких неправильных назначений в том числе с помощью IOD.

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

[Vadim 0]

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

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

[SM 0]

поэтому это Я буду в декларативном порядке сообщать программисту какие сигналы на каких ножках будут, а не ОН мне. Т.к. ему это фиолетово, а мне на плате - нет.

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

[disel 0]

 

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

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

Поэтому можно забить на все глюки ИОД, коих ни чуть не меньше чем в ДхД.

[Vadim 0]

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

Допустим.

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

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

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

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

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

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

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

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

[Frederic 0]

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

интересно как ты в базе пропишишь ногу с функционалом Diff/Clock/IO/DiffClock ???

и через день придется поменять Clock на IO чтобы сделать своп

 

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

надо скачивать не даташит, а ээээ как правильно выразится файл распиновки для IOD

хотя даташин нужен, чтобы нарисовать Cell

 

Это же не трансформер какой нибудь, а FPGA!!!

в яблочко и этим подведен итог дискусии.

 

 

:bb-offtopic: в четверг я вправлю тебе мозги

[Vadim 0]

интересно как ты в базе пропишишь ногу с функционалом Diff/Clock/IO/DiffClock ???

Не поверишь, с помощью клавиатуры :)

и через день придется поменять Clock на IO чтобы сделать своп

Стесняюсь сказать, но мне не нужно менять "Clock на IO", чтобы сделать своп :)

надо скачивать не даташит, а ээээ как правильно выразится файл распиновки для IOD

хотя даташин нужен, чтобы нарисовать Cell

Ну если даташит не нужен, не скачивай. Медитируй над "файлом распиновки для IOD". Там информации больше :)

[disel 0]

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

Исключение человеческого фактора. Вероятность ошибки при вводе м\сх с 1000 ногами далека от нулевой, а ее цена очень высока.

Создать универсальный символ для ПЛИС невозможно, поскольку в каждом проекте свои сигналы, разные питания. И соответственно разные группы свапа.

 

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

Например есть группа ног для ЦАПа, они 3,3В, им заданы банки 1-2 где они могут свапиться, есть ноги АЦП, они ЛВДС, т.е.2,5В им заданы банки 3-4. И нужно поменять местами. Или для ЦАП отдать 1,3. А еще есть клоки которые должны попадать на клоковые ноги, МГТ с его питанием, и т.д.

В ИОД все это делается элементарно, в нем уже вся информация о плис. Без него все вручную, долго, непроизводительно, и при этом есть вероятность ошибки.

 

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

см. выше.

 

Стесняюсь сказать, но мне не нужно менять "Clock на IO", чтобы сделать своп

Каждый волен расставлять вокруг себя любые грабли. Удачи.

[Inpharh 0]

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

А в случае использования IOD даже не обязательно его качать, большинство ПЛИС уже в базе, надо только выбрать производителя, модель и корпус.

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

Сколько времени надо для того чтобы "тупо повторить даташит"? В IOD тупо генерация символов проделывается минут за 5-10, плюс полчаса-час на подгонку под ГОСТ, и это речь о корпусе FF1760 например.

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

[SM 0]

А сколько времени нужно для создания компонента? Создание групп свопирования

Группы свопирования для ФПГА вещь совершенно бездарная, так как можно или нельзя свопнуть два пина определяется не только даташитом на ПЛИС, но и доп.функциями пинов и назначением соответствующих цепей, и особенностями разводки схемы внутри ПЛИС. Так что нет смысла вообще определять свопируемые пины в pdb на плисину.

[Inpharh 0]

Группы свопирования для ФПГА вещь совершенно бездарная, так как можно или нельзя свопнуть два пина определяется не только даташитом на ПЛИС, но и доп.функциями пинов и назначением соответствующих цепей, и особенностями разводки схемы внутри ПЛИС. Так что нет смысла вообще определять свопируемые пины в pdb на плисину.

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

но внедрить что-то новое довольно сложно... вот и делается многое по-старинке

Изменено 16 сентября, 2009 пользователем Inpharhus

[Frederic 0]

Группы свопирования для ФПГА вещь совершенно бездарная, так как можно или нельзя свопнуть два пина определяется не только даташитом на ПЛИС, но и доп.функциями пинов и назначением соответствующих цепей, и особенностями разводки схемы внутри ПЛИС. Так что нет смысла вообще определять свопируемые пины в pdb на плисину.

в ЦБ вообще можно не делать компанент.

работать локально и как сказал Inpharhus для каждого проекта своя индивидульная плисина

[SM 0]

А кто мешает создавать отдельный pdb для каждого нового проекта учитывая все эти особенности? Или вы хотите сказать что проще редактировать схематик?

 

Да вот я пока ничего не хочу сказать :) Еще не вник в суть. Но точно могу сказать - что в pdb нет механизма учета "всех этих особенностей", поэтому однозначно делать это не в pdb. А значит именно IOD и генерация каждый раз всего заново для каждого проекта.

 

PS.

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