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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

В www.megratec.ru\data\ftp\exp_movie\new\IOD2006_Multi-FPGA_2X.avi показано как перестановка выводов ПЛИС может производится внутри IOD на основе текущего размещения на плате.

Теперь уже легче IO1...ION для свопируемых выводов подойдет?

В библиотеке я не делаю эквивалентными выводы двойного назначения. При рисовании схемы по умолчанию их не задействую. В случае, если возникает необходимость их использования (не хватает обычных выводов или для облегчения разводки)...ничего не попишешь, разгребаю врукопашную головоломку схема-плата. Не так уж это страшно.
Раньше, когда работал в PCAD, использовал способ, описанный выше gray.k(один вывод - один вентиль), когда перешел на PADS, нарвался на ограничение по количеству вентилей в компоненте(100 для PadsLogic). IODesigner не использую. Я в него не въезжаю.
Если интересуетесь советами, даю - смиритесь с тем, что меняются номера пинов, а не имена цепей или имена пинов. Я при переходе на Expedition тоже вначале вставал на дыбы, хотелось, чтобы пины тупо менялись местами, как в PadsLogic. Однако, смирившись и поработав в таких условиях, понял, что способ обмена номерами дает гораздо больше практических преимуществ, чем недостатков, которые у него, несомненно,есть(имхо).

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

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

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



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

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

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

По моему, тоже. Поэтому пины и гейты я своплю не через ... ИОД

Расскажите, пожалуйста поподробнее. Если Вы не делаете эти выводы эквивалентными, и назрела необходимость их поменять местами в разводчике они же не поменяются. Какая у Вас структура символов?

См. видео по работе в теме http://electronix.ru/forum/index.php?showt...mp;#entry354417
где ничего не "ломается".

Может я и туплю, но никак не могу понять, как вставить картинку в сообщение
-----------------------------------------------------------------------------------------------------
Вообще-то даже и не знаю, что тут рассказывать. Если очень надо поменять две цепи с неэквивалентными выводами местами - идем в DC, ручками меняем, упаковываем, и - Forward Annotation в PCB. Но, повторюсь, я предпочитаю выводы двойного назначения использовать только по их основному назначению.
Прикрепленный рисунок - часть схемы "спасенного" мной проекта из PCAD4.5. Это к вопросу о структуре символа. Пускай "столбики" D1.1 и D1.3 Вас не вводят в заблуждение - это один символ.

Все же проблема которую затронул G_A_S для меня остается не решенной.

Подскажите пожалуйста, каким образом можно корректно работать с проектом если у нас в схеме не FPGA а к примеру STM32F?
Вручную перетаскивать десятки названий цепей xDX Designer уж очень утомительно.

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

На самом деле меня больше смущает что в среде Altium Designer такая возможность была предусмотрена.
А именно два режима обратной аннотации:
1. Изменение УГО с номерами и именами пинов (что не совсем корректно)
2. Изменение названий цепей подключенных к микросхеме.
В Altium-e на трассировку шины у меня уходило на прядок меньше времени чем сейчас и схема была оформлена по ГОСТу.
Я потратил кучу времени (без толку) в попытках хоть как-то облегчить себе работу.
Мне непонятно почему разработчики MG об этом не задумываются.

В свое время придумал костыль для решения этой проблемы - актуально для микроконтроллеров. Символ должен быть создан по определенным правилам:
Каждый сваппируемый вывод порта имеет пользовательские аттрибуты:
NAME - имя, которое будет отображаться на символе
NUM_NAME - соответствие номера и имени
Отображение пользовательского атрибута NAME включено, отображение системного атрибута Pin Name выключено:


После свопа и бэканнотэйта запускаем скрипт, который апдейтит атрибуты NAME. На выходе соответствие номеров выводов и отображаемого имени:



Сам скрипт я выкладывал в теме про скрипты