[Uree 1]

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

А так конечно да, если сгналы совершенно разные и все пины испльзуются как IO - никаких проблем не будет.

[vitan 2]

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

Хоть убей, не могу понять, в чем трудности. Ну и что, что предопределены байт-группы, адреса и данные? Наоборот, проще рисовать УГО. Если есть несколько групп, то рисуется одно УГО на все гейты сразу и проводится своп гейтов (функций). Номера пинов меняются, но никак не ухудшают читаемость схемы, т.к. гейты эквивалентны. Обычный подход...

 

Скриншот я смотрел-смотрел, и опять не понял... Если это исходное состояние такое, то тут, имхо, что есть своп, что нет, все равно ничего ничему не соответствует. Вот первый же пин IO_L36_M3DQ9_3. На него подключен нет SRAM_Q<19>. Где тут соответствие? Общая только буква Q. :) Как это проверять?

 

Ну и вообще, зачем проверять распиновку после свопа? Если своп правильно разрешен (для действительно эквивалентных пинов), то остальное делает САПР. У меня ни разу не было каких либо ошибок. Да, мне немного не по себе после свопа, и я проверяю вручную 1-2 пина, но не более. Все-то зачем проверять?

 

Я спросил про это все просто потому, что у плисин обычно много ног, и получается сильно длинная строка PINSWAP. Думал, может, есть получше методы...

 

А в DxD тоже можно спокойно именовать цепи из файлов, списков и т.п. Я на нем и остановился в свое время из-за того, что посчитал наиболее продвинутым. Правда, в HDL недолго поработал, ни одного проекта живьем так в нем и не сделал.

[Uree 1]

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

Эээ... не понял - что значит Ваше "...остальное делает САПР"? Надеюсь не автосвап имелся в виду???

А проблем со строками PINSWAP в Кэйденс нет по определению, ввиду отсутствия таковых:) Все задается в таблице распиновки, в Парт Девелопере. Как оно записано в файле chips посмотреть можно, только незачем.

[vitan 2]

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

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

 

Эээ... не понял - что значит Ваше "...остальное делает САПР"? Надеюсь не автосвап имелся в виду???

Остальное - это сама замена номеров пинов в схеме после свопинга в плате. Не автосвап, конечно, нет. :)

 

[Uree 1]

Дело в том, что реально невозможно полностью прописать ограничения по свопу пинов. Смотрите, один банк:

- все пины IO - одна эквивалентность

- те же пины разбиты по парам _P _N - замена диффпар(худший случай менять пару на два пина с одиночными сигналами) - какая тут эквивалентность должна быть?

- те же пины поддерживают DDR - байт группы, стробы, клоки, адреса - третий вариант свапа?

- те же пины QDR - байт группы, клоки, адреса(без стробов) - наверно тот же третий, хотя не факт

- те же пины, глобальные входы/выходы клоков - четвертый?

 

А вот теперь вопрос - как все варианты собрать вместе, и как после свапа на схеме увидеть, что сигналы хотя бы примерно попали на нужные пины, если точно известно, что имя пина, в котором обозначены варианты его функциональности, с номером не совпадает? Теоретически можно прописать уникальную эквивалентность для данного проекта, НО! - приписывать ее нужно УЖЕ зная какой сигнал куда будет подключен:) В общем очень непростой на самом деле вопрос.

[vitan 2]

Я поэтому использую генерацию УГО с помощью IOD. Это, в общем-то, и есть прописывание уникальных настроек свопа для проекта. Если та же плисина будет применяться в другом проекте, то для нее будет создано свое УГО, в котором прописаны те самые строки PINSWAP.

В общем, я это делаю на уровне УГО, а как там в нативном варианте с DE-HDL не знаю, конечно. Наверно, там тоже можно что-то подобное найти...

И таких компонентов с разными УГО у меня много, причем есть не только плисины. Бывает, что и простые буферы какие-нибудь удобно то так, то эдак рисовать в зависимости от проекта, и PINSWAP на каждом УГО разный. Соответствие компонента и УГО ведется в базе данных, а не во встроенных бибилиотекарях, поэтому проблем с этим нет. Вот как-то так решена задача...

[Uree 1]

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

Но проблемы прописывания свопа по уже известной распиновке это не решает.