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

На самом деле даже если конструктор будет использовать 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 уж очень утомительно.

Сообщение отредактировал Аргонавт - Apr 25 2016, 13:52

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

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

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


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



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