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

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

[insector]

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

Пока, я вижу в этом только один плюс: "Как правило любой из этих файлов могут прочитать системы разработки ПЛИС и таким образом ему не нужно будет в ручную определять выводы." Т.е. я убью 2 дня времени, пройду через кучу гемора с IOD, наловлю косяков и все это только для того, чтобы душечка программист не мучался с назначением портов вручную ?
Я, конечно, не махровый гуру, еще только учусь, но у нас все просто:
1. Сформировать перечень сигналов, которые пойдут в/на плис. Из них лишь небольшое кол-во является предопределенным, остальные свободные, поэтому это Я буду в декларативном порядке сообщать программисту какие сигналы на каких ножках будут, а не ОН мне. Т.к. ему это фиолетово, а мне на плате - нет. Случай с DDR модулем немного другой, но там тоже от программиста немного зависит.
2. Выслушать от программиста пожелания - какие бы он особые сигналы хотел видеть на спец. ножках, типа глобальных клоков.
3. Спокойно разводить плату.
4. Сообщить программисту где будут какие сигналы. И он за полчаса вручную их назначит.

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

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

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

[fill]

Тогда дополню:
1. Передача информации автоматом через файл исключает человеческий фактор - если у вас 1000 выводов, то при ручном вводе легко сделать ошибку, причем это касается как разработчика ПЛИС так и схемотехника-тополога (в PDB также легко можно сделать ошибку).
2. IOD контролирует правильность назначения сигналов. Я уже видел проекты, где разработчики плат сделали ошибки в назначении сигналов "не в те выводы" - когда делали схему и плату они не всегда дотошно изучали datasheets. А затем схемотехники, заказавшие эти платы у них, разбирались почему они не работают и пытались ускорить процесс поиска таких неправильных назначений в том числе с помощью IOD.
3. При достаточно плотном заполнении ПЛИС возникает потребность компромиса между получением нужной скорости внутри ПЛИС и внешней длины\распутывания связей на плате. Ориентируясь только на один критерий вы неизбежно проиграете в другом - выбрав только внешнюю длину\чистоту связей вы можете не получить нужную частоту внутри ПЛИС и наоборот. В таких случаях и нужны итерации назначения выводов, а значит 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 файлы, он это увидит и предложит соответствующие действия.

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

[SM]

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

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

[disel]

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

[Vadim]

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

Допустим.

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

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

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

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

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

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

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

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

[Frederic]

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

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

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

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

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

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


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

[Vadim]

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

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

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

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

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

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

[disel]

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

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

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

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

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

см. выше.

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

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

[Inpharhus]

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

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

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

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

[SM]

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

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

[Inpharhus]

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

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

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

[Frederic]

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

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

[SM]

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

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

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

[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. Тоже не понял, как это задать.

[Vadim]

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

Да-да. Людям следует доверять только в самом крайнем случае (Це)
Число пинов растет как на дрожжах

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

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

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

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

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

Совершенно верно. Особенно если разработчик настолько неуверен в своих действиях, что мысль о свапе двух пинов вызывает страх.

Удачи.

Действия я привык совершать осознанно и нести полную ответственность за их последствия, так что по крайней мере в вопросах свапа она мне вряд ли понадобится, тем не менее спасибо, и Вам тоже удачи

[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

[fill]

Подскажите пожалуйста такую вещь по 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

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

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

[SM]

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

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

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

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

[Vadim]

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

Конечно, не обязательно качать. Настоящие ковбои даташитов не читают (Це)

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

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

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

Не, ну про свопирование и человеческий фактор я третий раз повторять не буду. Устал.

[Inpharhus]

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

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

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

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

[fill]

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


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

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

[SM]

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

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

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

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

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

[fill]

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

Ключевое слово Assign pins with overwrite - вы принудили назначить сигнал в пин не его типа - в текущей версии не проверял, но так можно было назначить и в пин который не может быть такого типа вообще .

А можно как-то руками залезть в БД 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

[Vadim]

Кому бесполезно, а кому нет. IOD генерит не только символ, но и pdb, главное не забыть о создании cell с указанным IOD именем.

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

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

[SM]

в текущей версии не проверял, но так можно было назначить и в пин который не может быть такого типа вообще .

Неа, не даеть... Только в пины, которые могут быть такими. Он по ходу физически не может переписать тип пина на тот, которого нет в списке.

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

Ну что же... Порою...

[Vadim]

Повторю еще раз - IOD одновременно генерит еще и pdb, а это тоже время.

Повторите третий раз, пожалуйста. Очень хочется еще раз почитать А я пожалуй, третий раз повторять не буду. Не просто устал, а очень устал Просто сделаю выводы и пойду работать.
Всем иодным дизайнерам - привет!!!

[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. А цепи по-моему вообще не имеют групп свопирования.

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

[fill]

Неа, не даеть... Только в пины, которые могут быть такими. Он по ходу физически не может переписать тип пина на тот, которого нет в списке.


Ну что же... Порою...

[SM]

fill, а почему это в описании EE2007.7? IOD стал его частью? А не отдельным продуктом?

[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]

fill, а почему это в описании EE2007.7? IOD стал его частью? А не отдельным продуктом?

Он остался отдельным - ведь его можно использовать не только с Expedition. Просто его релизы синхронизуют теперь с текущим релизом EE, ведь внутри IOD можно создать сразу project в формате DxD и если его формат не совпадет с текущими возможностями DxD то ...

[AlexN]

уже второй раз вижу скриншот переведенного документа на 2007.7. А можно весь документ целиком увидеть?

[Inpharhus]

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

Тут не подскажу. Я в IOD генерил символ и компонент, на выходе имел .hkp и пачку .inp которые потом импортировал в центральную библиотеку и уже использовал в проекте.

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

Чтобы свопировать в Exp. А то ведь запаришься аннотировать туда-сюда...

[SM]

Чтобы свопировать в Exp. А то ведь запаришься аннотировать туда-сюда...

Так я IOD только ради того, чтобы свопировать в нем, и применить решил, так как правила свопирования EXP-а куцые и меня не устраивают.

[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 - это ведь просто переключиться в другое окно - мне не в напряг.

[Inpharhus]

Да и сходить в IOD - это ведь просто переключиться в другое окно - мне не в напряг.

Ну не просто переключиться, а еще провести синхронизацию. Пробуйте

[SM]

Ну не просто переключиться, а еще провести синхронизацию. Пробуйте

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

[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, и они обе обязаны быть в одном банке, но все равно в каком."

[fill]

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

Скорее всего неполучится, т.к. при экспорте из IOD запускается DxD для выполнения действий по генерированию подсхемы в проекте. Аннотация идет через схему. IOD<-->DxD<-->Exp

[SM]

Ну я все же надеюсь, что он генерирует какой-то скрипт, который потом выполняется в DxD. Если так - то можно попытаться его, скрипт, подсунуть вручную. А если нет - то можно попытаться обмануть всех сразу, сделав запуск DxD через rsh или ssh, чтобы IOD думал, что запускает локально, а не самом деле удаленно.

А вообще конечно жаль, что ментор не думает о том, что с одним проектом может работать несколько человек в разных программах (LM, IOD, DxD, Exp) из разных мест.

[Inpharhus]

Подскажите есть ли что-то похожее на IOD для микропроцессоров или может бывают библиотеки микропроцессоров для IOD?

[fill]

Подскажите есть ли что-то похожее на IOD для микропроцессоров или может бывают библиотеки микропроцессоров для IOD?

Готовые библиотеки врядли, а работать с ASIC уже можно - изучайте iod_asic_user.pdf

Ну я все же надеюсь, что он генерирует какой-то скрипт, который потом выполняется в DxD. Если так - то можно попытаться его, скрипт, подсунуть вручную. А если нет - то можно попытаться обмануть всех сразу, сделав запуск DxD через rsh или ssh, чтобы IOD думал, что запускает локально, а не самом деле удаленно.

А вообще конечно жаль, что ментор не думает о том, что с одним проектом может работать несколько человек в разных программах (LM, IOD, DxD, Exp) из разных мест.

При экспорте в окне консоли написано:
idxdesigner C:/MentorGraphics/IOD8.0/IODesigner/dxdesigner/rundxd.vbs C:/Demonstrations/Vidar_WG/Vidar_WG.prj FPGA_Controller_top 1

В Preferences>Paths указание где лежит DxD.

В iod_fpga_user.pdf описание TCL команд.

[Inpharhus]

работать с ASIC уже можно - изучайте iod_asic_user.pdf

А где взять?

[fill]

А где взять?

C:\MentorGraphics\IOD8.0\docs\pdfdocs\

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

"цепь INCK должна быть подключена к пинам типа PLLDIFF, а цепь IN к пинам типа DIFF," без проблем задается в Rule_Editor.
А вот обязаны быть в одном банке трудно реализуемо, т.к. правила проверяются интерактивно и тогда получается что сигналы можно будет размещать только одновременно - иначе сразу получается нарушение.
Хотя если привязать их в правиле к одному VREF, то можно в принципе и это организовать.

[Victor®]

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

Ему ("программисту", как Вы его называете) это абсолютно НЕ фиолетово. Т.к. есть куча проектов, где идет привязка
к определенным контактам. Причем, не всегда эти контакты распределяет разработчик FPGA, они могут быть сгенерированы
автоматически для удовлетворения времменых параметров (например, Xilinx Coregen формирует достаточно сложный файл ограничений дял PCI ядра, в том числе и для пинов). И Ваше общение с разработчиком должно быть итеративным. Просто может оказаться так, что из-за Вашей разводки проект в FPGA будет нерабочим... и как Вы думаете, кому дадут пинка? :-)

-- Успехов

[baken]

Вопрос к fill, есть ли возможность генерировать символы с помощью скриптов, так, как возможно в DC. Сейчас получается двойной путь, если речь идет о символе пользователя. Сначала генерируем символ из текста в slb, затем импортируется в DC, и наконец транслируется в DxD. Есть ли такая возможность сгенерировать свой символ из текста в IOD, чтобы потом перенести его в DXD. Возможно вопрос глупый, с IOD не работал, поэтому и прошу направить.

Сообщение отредактировал baken - Sep 18 2009, 13:57

[fill]

Вопрос к fill, есть ли возможность генерировать символы с помощью скриптов, так, как возможно в DC. Сейчас получается двойной путь, если речь идет о символе пользователя. Сначала генерируем символ из текста в slb, затем импортируется в DC, и наконец транслируется в DxD. Есть ли такая возможность сгенерировать свой символ из текста в IOD, чтобы потом перенести его в DXD. Возможно вопрос глупый, с IOD не работал, поэтому и прошу направить.

Более подробно что за скрипты вы используете, т.е. вы получаете на выходе символ с нужно графикой?

Вот вам предмет для изучения [attachment=36386:Symbol_Gen.7z]

[baken]

Более подробно что за скрипты вы используете, т.е. вы получаете на выходе символ с нужно графикой?
Вот вам предмет для изучения [attachment=36386:Symbol_Gen.7z]

Самописные бат файлы для генерации символов с помощью acmaker. Посмотрел видео, как все просто. Спасибо.

[Frederic]

думаю вопрос по теме IOD7.4
1.четыре листа Design1 имеют нормальный вид, для ПЛИС в Bloks - табличный.
Решение д.б. простое (раньше же был нормальный вид, но где то и что то нажал).
Как вернуть к нормальному виду ПЛИС ?

2.при экспорте ucf файла при наличие сигналов содержащих # ( AOE#; ARE#; AWE#) происходит дописывание данных сигналов в конец файла при каждом экспортирование. В хелпе не нашел запрета на использование данного знака

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

 

[fill]

думаю вопрос по теме IOD7.4
1.четыре листа Design1 имеют нормальный вид, для ПЛИС в Bloks - табличный.
Решение д.б. простое (раньше же был нормальный вид, но где то и что то нажал).
Как вернуть к нормальному виду ПЛИС ?

Мог или сделать экспорт из IOD в виде ICT или изменил внутри DxD (навигатор ПКМ>Change_to_ICT). Новый экспорт Shematic приведет в схемный вид.

[fill]

Он остался отдельным - ведь его можно использовать не только с Expedition. Просто его релизы синхронизуют теперь с текущим релизом EE, ведь внутри IOD можно создать сразу project в формате DxD и если его формат не совпадет с текущими возможностями DxD то ...

Корректировка - IOD теперь является частью EE. Т.е. новый IOD8.1 включен в текущий релиз (EE2007.7)

[baken]

Вот вам предмет для изучения [attachment=36386:Symbol_Gen.7z]

Вы будете смеяться, но символ транзистора сгенерировать не удалось. Пишет нечетное число ног.
Она даже не открывает символ транзистора из demo папки.

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

Сообщение отредактировал baken - Oct 13 2009, 17:19

[fill]

Вы будете смеяться, но символ транзистора сгенерировать не удалось. Пишет нечетное число ног.
Она даже не открывает символ транзистора из demo папки.

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

А это не пробовали http://www.pcbmatrix.com/Products/SymbolWi.../DxDesigner.asp

[Frederic]

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

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

Подводные камни на маршруте проектирования в IOD7.4 (мои бывшие проблемы из-за п.п.1, 2 и 5).
Будем рассматривать только иерархическую схему, т.е. используем один функциональный символ (т.е. один на всю ПЛИС) и работа в локальной PDB (без создания полноценного компонента в ЦБ). В фильме IOD_DxD_2007.avi очень хорошо показан принцип работы, но обычно проблемы начинаются после того как начались изменения в IOD или Ехр.

При любом изменение в IOD и передачи изменений в DxD необходимо следовать следующим советам :
1. Перед передачей изменений в DxD сохранить базу через CommonDatabaseProperties. Поставить галку на Export_PartData и точку на Write_to_Local_PDB_file. У меня галка не скидывается, но и почему то база первоначально не сохранялась. Для нормальной работы пришлось первоначально сохранить проект по дефолтному *.hkp и сразу поставить точку на Write_to_Local_PDB_file и сохранить базу. Базу следует сохранять при закрытом Ехр, иначе IOD не сможет корректно сохранить базу из-за блокировки ее Ехр, т.е. при любом действии в IOD настоятельно рекомендуется закрывать Ехр.
2. Сделанные изменения передаются в DxD через Export/Schematic_and_Symbols, а не через светофоры синхронизации.
3. При изменениях, когда изменяются имена сигналов (но без изменения расположения пина в функциональном элементе) при экспорте в DxD данный пин будет отключен от цепи в DxD. Необходимо будет подвигать цепь для подключения к пину.
4. При кардинальных изменениях, когда добавляются, удаляются или изменяются имена сигналов проще провести изменения через SimbolWizard/UpdateSimbols (не проверял) или вообще удалить в IOD символы и заново сгенерить двумя щелчками мышки и пройти путь по п.1 (так поступаю). Предварительно удалить ПЛИС в DxD на схеме, в навигаторе и в базе Symbol_View/local_symbols, сделать FA & BA. Чтобы не пропали разведенные цепи относящиеся к ПЛИС, необходимо убрать галки Trace_removal_options в FA .
5. Пины JTAG и питания (они не изменяются) выделяю в отдельные pcb символы. В этом случае сигналы JTAG необходимо добавить в IOD.
6. Перед серьезными изменениями советую закрыть DxD, Exp, IOD и сделать дамп проекта тупым копированием всего директория на архивный веник.

[baken]

А это не пробовали http://www.pcbmatrix.com/Products/SymbolWi.../DxDesigner.asp

Спасибо за наводку, попробую.

[SM]

Вот... Первая попытка работы с IOD...
Ввел сигналы, назначил, создал символы в визарде, экспортировал. Получил два блока в моем проекте - "name" и "name_top" где "name" то, как я назвал в iod. А, собственно, как мне теперь все это соединить с моей схемой? Где мне взять символ, соответствующий тому, что я описывал в IOD, чтобы его поставить в схему?

[Frederic]

Вот... Первая попытка работы с IOD...
Ввел сигналы, назначил, создал символы в визарде, экспортировал. Получил два блока в моем проекте - "name" и "name_top" где "name" то, как я назвал в iod. А, собственно, как мне теперь все это соединить с моей схемой? Где мне взять символ, соответствующий тому, что я описывал в IOD, чтобы его поставить в схему?

если без ЦБ, то из Symbols/Symbol_View/local_symbols , т.е. стандарный ввод элемента на схему

[SM]

если без ЦБ, то из Symbols/Symbol_View/local_symbols , т.е. стандарный ввод элемента на схему

Да, там такой символ есть, но этот символ уже задействован в блоке "<name>_top", сгенеренном IOD-ом. Вот это меня смущает. Т.е. как я понял в этом блоке IOD понацеплял к нему цепей, но вот что дальше делать с этим блоком, я не понимаю. И символа, который соответствует этому "топовому" блоку я не вижу.

Или этот "топ" надо переместить из блоков в схемный лист проекта? Или вообще "забить" на него и по образу и подобию как в топе все подключить там, где мне надо?

(2007.7 версия, и IOD оттуда же встроенный)

[Frederic]

Да, там такой символ есть, но этот символ уже задействован в блоке "<name>_top", сгенеренном IOD-ом. Вот это меня смущает. Т.е. как я понял в этом блоке IOD понацеплял к нему цепей, но вот что дальше делать с этим блоком, я не понимаю. И символа, который соответствует этому "топовому" блоку я не вижу.

Или этот "топ" надо переместить из блоков в схемный лист проекта? Или вообще "забить" на него и по образу и подобию как в топе все подключить там, где мне надо?

(2007.7 версия, и IOD оттуда же встроенный)

даю картинку, если не поймешь - завтра уточним
сненерил компонент из трех символов, котрорые ставим на схему :
ХС35S700_configpins.1
XC35S700_powerpins.1
XC35S700.1
и автоматом получаем еще XC35S700_pcb.1 (на схему его не ставим, это подсхема функционального символа XC35S700.1)
почему удобно использовать функциональный символ - вместо кучи проводников шины рисуем шину и она подключина к ПЛИС

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

 

[SM]

даю картинку, если не поймешь - завтра уточним

Тема... Ну в общем не совсем раскрыта. Поясните назначение того, что находится в Blocks и кончается на _top (у Вас XC35S700AN-4FGG484C_top). Все символы я нашел, но я не понял смысла этого блока с окончанием на "top" - я должен его как-то его использовать, или это образец, как подключать все символы? Лично у меня в этом блоке, кончающемся на _top, установлен как раз сгенерированный функциональный символ, распихано часть .pcb-символов с питаниями, не касающимися IO, ну и config/JTAG, и к ним подведены "обрывки" цепей с названиями, как я их указал в IOD-е.

Я тоже использую функциональный символ, но я не совсем понимаю, как правильно его использовать, и для чего мне сгенерили этот самый блок, кончающийся на "_top".

И еще - а на кой он мне генерирует кучу символов с VREF-ами (либо добавляет их в символ с конфиг-пинами, смотря какие опции split-а символов), причем вне завсисмости от галки "Add VREF pins if required by I/O Standard" визарда. Да и ни одного пина у меня нет в таком стандарте, чтобы VREF нужен был. Т.е. по идее все врефы априори обычные I/O.

[Frederic]

Тема... Ну в общем не совсем раскрыта. Поясните назначение того, что находится в Blocks и кончается на _top (у Вас XC35S700AN-4FGG484C_top). Все символы я нашел, но я не понял смысла этого блока с окончанием на "top" - я должен его как-то его использовать, или это образец, как подключать все символы? Лично у меня в этом блоке, кончающемся на _top, установлен как раз сгенерированный функциональный символ, распихано часть .pcb-символов с питаниями, не касающимися IO, config, JTAG, и к ним подведены "обрывки" цепей с названиями, как я их указал в IOD-е.

Я тоже использую функциональный символ, но я не совсем понимаю, как правильно его использовать, и для чего мне сгенерили этот самый блок, кончающийся на "_top"

то что находится в Blocks не трогай, функциональный символ и есть блок (как я понимаю) и он прописан в секции Blocks
top это верхний уровень, под ним лежит подсхема функциональ\ного символа

ты должен ставить на схему символы из Symbols/Symbol_View/local_symbols (если работаешь без ЦБ)
"подведены "обрывки" цепей с названиями, как я их указал в IOD-е." - увидеть цепи можно , если открыть функциональный символ в Blocks или выделить его на схеме и ПКМ Push_Schematic. обрывки цепей (это имена сигналов IOD) в символьном элементе превращаются в имена пинов и к ним в DxD подключить можно любую цепь или шину (если в IOD имеется шина то для DxD к функциональному символу возможно подключить шину с кол-вом сигналов прописанных в IOD или иначе не пройдешь упаковку)

"генерирует кучу символов с VREF-ами" и IOD кидает в символ ХС35S700_configpins.1 т.е. наверно считает их по функционалу JTAG, другого объяснения я не нашел, просто смирился с этим

[SM]

то что находится в Blocks не трогай, функциональный символ и есть блок (как я понимаю) и он прописан в секции Blocks
top это верхний уровень, под ним лежит подсхема функциональ\ного символа

Не-не, там похоже не все так просто. Там сгенерено два блока. Первый, который не top, это и есть то, что снаружи представлено функциональным символом. А вот именно блок "top" - ведь не спроста он сгенерирован, наверное для чего то нужен. А если в него посмотреть - там просто стоит функциональный символ, символ с питачем и символ, в котором конфиг-пины. И к ним подведены цепи с такими названиями, как я их собственно и назвал. Спрашивается, зачем? Если его, этот топ, использовать не надо, а надо ставить сразу функциональный символ в свою схему. Или же top это просто образец, как цеплять сгенеренные символы, чтобы все соответствовало? Ведь именно в том самом top на power пины подается правильное питание, прописанное IOD-ом в соответсвии с тем, как он разбросал по банкам разные пины разных IO-стандартов. И если я его не использую, то мне придется powerpins вручную подключать.

обрывки цепей (это имена сигналов IOD) в символьном элементе превращаются в имена пинов и к ним в DxD подключить можно любую цепь или шину (если в IOD имеется шина то для DxD к функциональному символу возможно подключить шину с кол-вом сигналов прописанных в IOD или иначе не пройдешь упаковку)

Это все так для того блока, который без добавки "_top". А я пытаюсь выяснить назначение "_top"-а


Вот картинка того, что у меня в top-e сгенерилось. То, что слева вверху - это уже экземпляр функционального символа! Соотв. этот блок никак не может быть "содержимым" функционального символа, если он сам в себе его содержит!



ЗЫ.
Еще засада - если не ставить галку "Generate Full PCB Symbols", то похериваются сигналы питания PLL, которые в БД по плисам почему-то имеют тип "OTHER", и даже если я их принудительно описываю в списке сигналов, то все равно они пропадают. Причем, что удивительно, земля одной из PLL попала в тип "GND", земля второй - увы... нет... Тоже Other... Так что их база данных требует не меньшей перепроверки, чем собственно изготовленные символs Ужос. Никому доверять нельзя.

ЗЗЫ. Ну а под конец он просто упал, сказав такое Так что на сегодня явно возиться хорошь....

Код

[PROLOG SYSTEM ERROR:  Thread 1
    Recursively received fatal signal 11
PROLOG STACK:
]

Action? /opt/mentor/EE2007.7/2007.7EE/SDD_HOME/IODesigner/resource/iod_env: line 15: 11184 Killed                  ${IOD_HOME}/IODesigner/iod "$@"

[SM]

В общем - конкретизирую вопрос. Как мне подключить блок "<name>_top" к схеме, чтобы все подключения цепей VCC/GND, сделанных IOD-ом, учитывались в моем проекте?

[Frederic]

В общем - конкретизирую вопрос. Как мне подключить блок "<name>_top" к схеме, чтобы все подключения цепей VCC/GND, сделанных IOD-ом, учитывались в моем проекте?

да не трогай блок "<name>_top
вставляй в схему функциональный символ и свои два pcb JTAG и питания
дай картинки в word-е как ты генерил в IOD, по символу питания вижу ты делал замену имен питания в Preferences/SymbolGeneration
выложи проект или вышли по личке

[SM]

вставляй в схему функциональный символ и свои два pcb JTAG и питания

Да как я могу вставить символ питания, когда IOD сам его должен подключать в зависимости от того, какие VCC на какой банк нужны с его точки зрения. Иначе зачем он мне все эти питачные сигналы авто-присваивает? Или мне вручную каждый раз в процессе оптимизации там питачи перекидывать?

Я не понял, как это дать картинки в ворде... Но скриншот могу:

вижу ты делал замену имен питания в Preferences/SymbolGeneration

Да, естественно, чтобы подогнать под мои стандартные названия.

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

 

[Frederic]

Да как я могу вставить символ питания, когда IOD сам его должен подключать в зависимости от того, какие VCC на какой банк нужны с его точки зрения. Иначе зачем он мне все эти питачные сигналы авто-присваивает? Или мне вручную каждый раз в процессе оптимизации там питачи перекидывать?

ты можешь пойти по нескольким путям с питанием например:
- сделать символ рсв питания без изменения имени пининия, т.е. имя пина в рсв будет как был по умолчани (типа Vdd Vcc и так далее). В схеме к кадждому пину к нему подключишь все что хочешь. Этот путь меня устраивает.
- не добавлять никуда, они попадут в pdb и станут глобальными

Я не понял, как это дать картинки в ворде... Но скриншот могу:

путь генерации в IOD

[SM]

ты можешь пойти по нескольким путям с питанием например:

Вы мне вот что скажите - а я могу просто как-то подключить тот самый блок, который на _top кончается, к проекту? Чтобы он стал одним из листов схемы. Меня бы это устроило полностью и безоговорочно...

[Frederic]

Вы мне вот что скажите - а я могу просто как-то подключить тот самый блок, который на _top кончается, к проекту? Чтобы он стал одним из листов схемы. Меня бы это устроило полностью и безоговорочно...

1.мы в нете, поэтому без вы
2."блок, который на _top" повторяю еще раз,не трогай, бери символы из локальной базы

[SM]

1.мы в нете, поэтому без вы
2."блок, который на _top" повторяю еще раз,не трогай, бери символы из локальной базы

1. Не привык я так, сорри.
2. Ну меня не устраивает из локальной базы. Ну не удобно это, когда IOD сам мне создал целый лист где все уже сам из локальной базы взял и подключил к нужным мне цепям! Зачем мне повторять всю работу, которую за меня сделали автоматом? Я просто хочу понять, как мне это использовать.

[Frederic]

1. Не привык я так, сорри.
2. Ну меня не устраивает из локальной базы. Ну не удобно это, когда IOD сам мне создал целый лист где все уже сам из локальной базы взял и подключил к нужным мне цепям! Зачем мне повторять всю работу, которую за меня сделали автоматом? Я просто хочу понять, как мне это использовать.

1.привыкай
2.он ничего не подключил. есть пин на функционально символе WP (соответственно и цепь WP нижележащей схемы), но к пину ты можешь подключить WP cхемы в DxD или любую цепь включая 0V или +3.3V и аналогично со всеми другими пинами , включая пины шин на которые подключаются шины DxD (которые могут отличаться от IOD)

[fill]

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

[Frederic]

узок круг IOДизайнеров, страшно далеки они от народа

[SM]

Вторая ( _top) для отображения "внешнего интерфейса", ее можно использовать только для копирования ее кусков на собственную схему. Если внимательно посмотрите на схему _top то увидите, что в отличие от подсхемы функционального символа на ней нет портов для связи цепей по иерархии и соответственно нет и ее символа.

Вот! Спасибо! Этого ответа я и добивался изначально. Правда я надеялся, что этот лист схемы (_top) целиком можно без копирования поставить одним из листов design-а (типа как-то перетащить его туда, сменив "родителя" в дереве), чтобы он просто если что автоматически перегенерировался IOD-ом, после чего FA, и вуаля. Как всегда, надежды на удобство в работе не оправдываются. Ну а так, в общем то, после каждой перегенерации, если она привела к изменению на этом листе, не особо велик напряг скопировать его содержимое в лист из design-а. Просто я не вижу смысла ставить символ самостоятельно, и подводить к нему цепи и шины, когда это уже сделано за меня автоматом

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

И не тащу я все пины на символы. Это отчетливо видно на скриншоте. Исключительно задействованные.

[fill]

Вот! Спасибо! Этого ответа я и добивался изначально. Правда я надеялся, что этот лист схемы (_top) целиком можно без копирования поставить одним из листов design-а (типа как-то перетащить его туда, сменив "родителя" в дереве), чтобы он просто если что автоматически перегенерировался IOD-ом, после чего FA, и вуаля. Как всегда, надежды на удобство в работе не оправдываются. Ну а так, в общем то, после каждой перегенерации, если она привела к изменению на этом листе, не особо велик напряг скопировать его содержимое в лист из design-а. Просто я не вижу смысла ставить символ самостоятельно, и подводить к нему цепи и шины, когда это уже сделано за меня автоматом

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

И не тащу я все пины на символы. Это отчетливо видно на скриншоте. Исключительно задействованные.

1. Этот лист принадлежит схеме _top. Поэтому сделать его принадлежностью другой схемы через какую-то ссылку мне представляется невозможным. Копировать лист, тоже самое что копировать кусок схемы, т.е. выигрыша никакого. Через иерархию тоже не получится т.к. _top в данном случае не "полноценен".

2. Скриншот не рассматривал, просто обратил внимание о генерировании Full_PCB_Symbols, а это как раз = тащить все пины на символ.

3. Кстати, для любителей "плоских" схем, в IOD8.0 появилась опция Export>Schematic_Update и судя по описанию

Using this flow, the pin numbers of the symbols are not swapped, as is done during typical back
annotation from Expedition PCB. Instead, the net names and net stubs that have been placed on
the schematic are swapped.

она делает как раз то что многие пкадчики так любят - переставляет на схеме цепи, а не номера пинов.

[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 не разобраться

[SM]

если выбрать "использовать" то получается символ с сигналами JTAG и vref, а я НЕ ХОЧУ его иметь на схеме и контролировать.

Во-во, меня этот вопрос тоже очень интересует. Правда я не против отдельного символа для JTAG/Config, даже за, мне хорошо его на другой лист, нежели функ. символ, но чтобы без VREF-ов!!!!

[Asb]

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

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

[fill]

1. Ваять можно непосредственно внутри IOD - для этого и существует окно Symbol
2. Естественно данные пины надо добавить как на функ. так и на pcb символ.
Взять все пины JTAG (в окне пинов или сигналов) и перетащить на символ секундное дело. Чтобы не искать их в списке достаточно включить фильтр (например щелкнув на JTAG в заголовке окна Device - в результате в окне Pins останутся только пины JTAG).

Также добавить\перераспределить пины можно в последнем шаге Symbol_Wizard - когда перед вами таблица - слева не размещенные пины, справа размещенные.

[Frederic]

1. Ваять можно непосредственно внутри IOD - для этого и существует окно Symbol

просто ленивый я, тем более не получалось никогда получить 100% схему. постоянно какие то изменения и функциональный символ плывет

2. Естественно данные пины надо добавить как на функ. так и на pcb символ.
Взять все пины JTAG (в окне пинов или сигналов) и перетащить на символ секундное дело. Чтобы не искать их в списке достаточно включить фильтр (например щелкнув на JTAG в заголовке окна Device - в результате в окне Pins останутся только пины JTAG).
Также добавить\перераспределить пины можно в последнем шаге Symbol_Wizard - когда перед вами таблица - слева не размещенные пины, справа размещенные.

эх не хватает пимпочки для автоматизации этого процесса

и самое главное не получается пройти упаковку
т.к. я не использовал отдельные символы JTAG и питания то IOD сгенерировал одну схему. нет *_top

даю картинки. т.е. как я понимаю еще требуется и схема *_top для упаковки
как это понять ?

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

 

[fill]

В подсхеме сгенерированной IOD есть порт X_DONE?

Ничего дополнительного не требуется. Я модифицировал схему с двумя ПЛИС использованную в моем видео и все работает.
- добавил пины TMS, TDI, TDO, TCK на функ. символ и символ pcb
- сделал экспорт символов и схемы
вид на топе
вид внутри первого блока

Все упаковывется и аннотируется.

[Frederic]

В подсхеме сгенерированной IOD есть порт X_DONE?

В подсхеме сгенерированной IOD порта X_DONE у меня почему то НЕТ
я вижу на "вид внутри первого блока
" у тебя для каждого сигнаа TMS, TDI, TDO, TCK имеется порт, который отсутствует у меня

Ничего дополнительного не требуется. Я модифицировал схему с двумя ПЛИС использованную в моем видео и все работает.
- добавил пины TMS, TDI, TDO, TCK на функ. символ и символ pcb
- сделал экспорт символов и схемы
Все упаковывется и аннотируется.

как обычно у fill все работает
сделал
1.пин DONE добавлен на на функ. символ и символ pcb - это видно на двух первых картинках
2.проблема только с добавлением сигнала X_DONE, т.к. без него все все упаковывется и аннотируется

[janus]

Вопрос - а как IOD сказать не перегенерировать подсхему? то есть - вручную создан лист подсхемы и на него поставлены символы _pcb, а при следующей синхронихации IOD заменяет лист на сгенеренный самостоятельно....

[fill]

Вопрос - а как IOD сказать не перегенерировать подсхему? то есть - вручную создан лист подсхемы и на него поставлены символы _pcb, а при следующей синхронихации IOD заменяет лист на сгенеренный самостоятельно....

Если делаете экспорт схемы, то естественно схема генеририруется заново.
А зачем делать вручную именно эту подсхему, сделайте подсхему под другим именем, если вы ее все равно редактируете вручную. Символы _pcb на ней обновятся автоматом после экспорта из IOD.

[janus]

Если делаете экспорт схемы, то естественно схема генеририруется заново.
А зачем делать вручную именно эту подсхему, сделайте подсхему под другим именем, если вы ее все равно редактируете вручную. Символы _pcb на ней обновятся автоматом после экспорта из IOD.

Экспот схемы не делался...делался экспорт символов, а потом синхронизация с дефолтными параметрами....Или я чего-то не понимаю, и это одно и то же?


Э.. Тогда в проекте будет две подсхемы? А мне совершенна не нужна подсхема криво сгенеренная ИОД с дефолтной форматкой А4, которую кстати, я поменятть почему-то не могу в данном проекте....=(

[fill]

В подсхеме сгенерированной IOD порта X_DONE у меня почему то НЕТ
я вижу на "вид внутри первого блока
" у тебя для каждого сигнаа TMS, TDI, TDO, TCK имеется порт, который отсутствует у меня


как обычно у fill все работает
сделал
1.пин DONE добавлен на на функ. символ и символ pcb - это видно на двух первых картинках
2.проблема только с добавлением сигнала X_DONE, т.к. без него все все упаковывется и аннотируется

Так все таки на функ. символе пин DONE или X_DONE? Чтобы не путаться назови сигнал DONE, тогда все имена станут одинаковыми и скорее всего проблема сразу исчезнет.

[janus]

Сорри, уточнение....Вручную был создан лист подсхемы с именем spartan6, на него указывал символ сгенеренный ИОД и на нем были размещены порты и _pcb...После синхронизации - в spartan6 вдруг стало два листа, причем, символы _pcb с первого листа перенеслись на второй лист....

[fill]

1. Есть несколько видов экспорта:
- Shematic_and_symbols - генерируется подсхема на которую размещаются генерируемые символы _pcb
- All_Symbols - генерируются только символы
- Selected_Symbol - генерируется только выбранный символ
- Schematic_Update - обновляется руками сделанная схема на которую были размещены символы _pcb
Так какой из них вы используете?
2. На сгенерированной IOD подсхеме ясно красными буквами написано - не модифицировать подсхему, т.к. она автоматом перерисовывается при выполнении экспорта Shematic_and_symbols
3. Если вы в проекте DxD указали используемые форматки для конкретных размеров листов (border.ini), то в IOD в Tools>Preferences>Symbol_Editor>Export будет доступна для авто размещения именно ваша форматка, выбираемая согласно размера листа заданного вами в Tools>Preferences>Symbol_Editor
4. Какой смысл заниматься "причесыванием" подсхемы на этапе первичной разработки? Когда закончите все перестановки пинов, тогда и можете привести подсхему в нужный вам вид.

[janus]

1. Использовался экспорт All_Symbols
2. Это понятно.
3. В проекте указана форматка А3. В ИОД - она не доступна. ЦБ ессно, подключена и в ЦБ эта форматка есть.
4. Тоже верно.. но - хочется все сразу =)

UPDATE: по п3 разобрался - в Preferences->Symbol Edito стоял размер листа А4 - забыл поправить...правда логика сего мне не понятно - почему размер листа выставляется в одном разделе, а форматка к этому листу в другом....ну да бог с ним, тут и почище нелогичности бывают...=)