Swap Опции

[G_A_S]

Столкнулся с проблемой сваппирования пинов, дифференциальных пар, прямой и обратной аннотациями при сваппировании. Чтобы не задавать глупых вопросов, подскажите, пожалуйста, где можно почитать об основах работы с этой тематикой. Важна любая информация. Заранее благодарен.

[G_A_S]

Есть ли возможность менять имена цепей в схеме при сваппировании, а не номера пинов. Иначе в гейте происходит путаница: номера пинов меняются местами, а соответствующие им имена пинов остаются на прежних местах... Подскажите, если знаете! Начальный этап освоения пакета самый сложный...

И хотя бы в двух словах о своппинге диф пар.

И хотя бы в двух словах о своппинге диф пар.

[fill]

Символ являет библиотечным элементом, имя пина прописано на уровне символа и изменяется только в библиотеке, на схеме оно не изменяется. Это кстати полностью согласно стандартов - изображение символа примененного внутри одной схемы должно быть одинаковым.
Диф. пары - если речь о ExpeditionPCB - переставлять надо не пины, а вентили, т.е. создаете PDB, где каждая пара пинов это вентиль.
Если работаете с ПЛИС то лучше делать своп в I/O_Designer - он понимает что нужно переставлять пару пинов, если они дифференциальные. Также символы для схемы можно перегенерить исходя из перестановок пинов. PDB он тоже генерит автоматически.

[G_A_S]

Спасибо за ответ! Я понимаю, что имя пина прописано и изменить его в схеме нельзя, но я не понимаю почему при сваппировании прыгают по символу номера пинов. Это неприятно и символ после этого перестает быть корректным (в качестве PinNumber - номер ножки ПЛИС, в качестве PinName - ее функцинальное назначение по ПДФ).
А если я создал элемент не прибегая к помощи ИО-Дезайнера, а вручную... Где именно определяются вентили? ПЛИС большая: Virtex4.

[fill]

Топологический редактор имеет дело с нетлистом в котором фигурируют номера пинов (а не их имена). Поэтому и при обратной аннотации, на схеме изменяются только номера пинов (так сделано в большинстве САПР).

Определение вентилей посмотрите в тренинге по ExpeditionPCB (раздел 4) http://electronix.ru/forum/index.php?showtopic=36292.

[G_A_S]

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

[gray.k]

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

[G_A_S]

Вопрос в том, какой алгоритм проектирования должен быть, когда используется большое количество плисин с переставляемыми ножками. Ведь в ГОСТовских схемах мы делим их на определенные группы (гейты в Менторе). При своппинге в разводке и обратной аннотации меняются местами номера пинов, но не соответствующие им имена пинов (которые определяются в ПДФ, и которые должны присутствовать на схеме).

И еще вопрос! Есть ли документация на русском языке по I/O Designer?

[Vadim]

При своппинге в разводке и обратной аннотации меняются местами номера пинов, но не соответствующие им имена пинов (которые определяются в ПДФ, и которые должны присутствовать на схеме).

Я конечно, извиняюсь, но где в ГОСТах написано, что имена пинов, определяемые в пдф, должны присутствовать на схеме?

[G_A_S]

Я конечно, извиняюсь, но где в ГОСТах написано, что имена пинов, определяемые в пдф, должны присутствовать на схеме?

Не обязательно именно то, что в ПДФ... Но хотя бы любая информация, описывающая эту ножку! Ведь получается полный каламбур на схеме после первого же своппинга... По кайне мере у меня и в Менторе... В Протеле было по другому: При своппинге менялись именно имена цепей, а Пины на схеме оставались на тех же местах (ну и их аттрибуты соответственно). Ментор необходим!!!!! Поэтому я пытаюсь разобраться, как делают проэкты другие разработчики, чтобы делать так же, а не заведомо неправильно! Подскажите, если есть время )

А кто Вам сказал, что эти имена обязательно должны присутсвовать на схеме? ЕСКД такого не требует. Имена выводов I/O в ПЛИС могут иметь различные имена, в зависимости от их использования. Такие выводы можно все именовать одним именем (например IO). Кроме того при разбивке ПЛИС на секции возникает проблема обмена эквивалентных выводов, находящихся в разных секциях. Я решаю эту проблему так: создается несколько секций (символов) с конфигурационными выводами и питания (например Power, GND, GNDA JTAG, CLK и т.д.) и одна секция (символ) вывода типа IO. Далее в PDB создается неоднородный компонент из этих секций. Компонент конечно содержит много секций, за счет количества секций вывов IO (каждая секция - один вывод). При таком подходе в схеме я могу "собрать" любую комбинацию секций и сделать любую разбивку их на группы. Достоинства способа в том, что Вы один раз создаете универсальный компонент ПЛИС и можете использовать его в различных проектах.

Спасибо за ответ! А такой подход можно использовать с помощью IOD?

[gray.k]

Не обязательно именно то, что в ПДФ... Но хотя бы любая информация, описывающая эту ножку! Ведь получается полный каламбур на схеме после первого же своппинга... По кайне мере у меня и в Менторе... В Протеле было по другому: При своппинге менялись именно имена цепей, а Пины на схеме оставались на тех же местах (ну и их аттрибуты соответственно). Ментор необходим!!!!! Поэтому я пытаюсь разобраться, как делают проэкты другие разработчики, чтобы делать так же, а не заведомо неправильно! Подскажите, если есть время )
Спасибо за ответ! А такой подход можно использовать с помощью IOD?

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

По поводу изменения имен здесь я с Вами не согласен. Я считаю, что используемый в Mentor подход справедлив (http://www.megratec.ru/forum/1/?theme=2494&)

[G_A_S]

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

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

[gray.k]

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

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

[G_A_S]

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

Я именно инженер-конструктор по трассировке ПП. Но Задание от разработчика дается в виде: вот плисина, вот несколько кристаллов памяти, вот входные и выходные разъемы (к примеру). Почитай ПДФ на микросхемы, накидай кондеров, учти волновое сопротивление, набежки и разведи.

На самом деле даже если конструктор будет использовать IOD только для перестановки выводов, то IOD не даст ему назначить выводы не в те ноги, конечно при условии, что он не будет менять тип сигнала в таблице сигналов (это прерогатива разработчика). Попробуйте в IOD переставить сигнал типа IO в пин типа Config (или CLK и т.д) и вы увидите что это невозможно.

Вот именно! И помимо этих правил существуют и другие, например, в Xilinx для выходных сигналов LVDS нельзя использовать ножки LC_CC. Можно ли задать IOD дополнительные правила?

[fill]

Можно ли задать IOD дополнительные правила?

Можно. Можно даже создать свой компонент, со своими правилами.