очень круто
Однако, в линейке PADS, до сих пор (начиная с 2007) не работает "HETERO" с длинными атрибутами. Т.е. использвать продукт в сколь-либо серьёзных схемах не представляется возможным.
Ну и нахрена козе баян?

Для меня ограничение длины значения параметра в 255 знаков не является непреодолимым препятствием при разработке - можно использовать и короткие имена символов.

Я Вас не понял
Есть, например, микросхема XC4VSX55-11FFG1148CS2
При создании символов очень логично разбить на банки ввода/вывода
XC4VSX55-FG1148_00
XC4VSX55-FG1148_01
XC4VSX55-FG1148_02
XC4VSX55-FG1148_03
XC4VSX55-FG1148_04
XC4VSX55-FG1148_05
XC4VSX55-FG1148_06
XC4VSX55-FG1148_07
XC4VSX55-FG1148_08
XC4VSX55-FG1148_09
XC4VSX55-FG1148_10
XC4VSX55-FG1148_11
XC4VSX55-FG1148_12
Итого: HETRO=(XC4VSX55-FG1148_00),(XC4VSX55-FG1148_01),(XC4VSX55-FG1148_02),(XC4VSX55-FG1148_03),(XC4VSX55-FG1148_04),(XC4VSX55-FG1148_05),(XC4VSX55-FG1142_06),(XC4VSX55-FG1148_07),(XC4VSX55-FG1148_08),(XC4VSX55-FG1148_09),(XC4VSX55-FG1148_10),(XC4VSX55-FG1148_11),(XC4VSX55-FG1148_12)
У меня получилось 272 символовола, а есть микросхемы и покрупнее.

Да, поддерживаю! Когда появился 2007 я сразу спросил про это, но мне тогда никто не ответил...
У меня проблема возникла на шаг раньше: при отправке в разводку символа, на котором был атрибут PINSWAP большой длины. В 2005 это работало, а теперь не знаю что и делать. Это пока один из моментов, из-за которых я так и не перешел на 2007.
PS. Конкретно для HETERO можно попытаться удалить скобочки... Но в общем виде, конечно это проблему не решает.

У нас с вами разная логика. Я не называю символы номерами микросхем + посадочное место, все равно они у меня одноразовые - генерятся через IOD, под каждый проект свой набор - использую короткое логическое\функциональное имя. Перестановки пинов тоже делаю в IOD. Атрибут PINSWAP можно разместить на символе много раз.

Такой подход точно не подойдёт.
Единожды продуманный и тщательно проверенный символ должен храниться в библиотеке и быть единым для всех проектов, его использующих.
При этом, наименования самих символов и их выводов должно быть максимально информативным.

Почему же? Если сделать статический единожды продуманный символ для плисины, то становится невозможно использовать все преимущества IOD. Вот это, как раз, точно не подойдет.
Однако, еще надо не забыть про символы для каких-нибудь больших процессоров. Их тоже может быть очень много. Т.к. IOD здесь не используется, то проблема, в общем-то, есть. Я в таких случаях вынужден сокращать длину имени в символе, иногда до очень маленькой. Не информативно и т.п.
fill
Спасибо за подсказку, я как-то раз видел, что PINSWAP генерится несколько раз, но не придал этому значения. Маленький вопрос: а не будет при этом создаваться несколько групп пинов по количеству PINSWAP? Т.е. будут ли строки из нескольких PINSWAP объединяться в одну при отправке в плату?

Согласен что иногда может быть не очень удобно.

К сожалению переноса строк нет, т.е каждое PINSWAP создает свою группу свопирования.
В принципе можно ведь определить свопируемость и внутри компонента в библиотеке. Т.е. на символе в схеме иметь только обязательные атрибуты для упаковки, а свопируемость задать в таблице Part-а (для PADS), я так понимаю скорее всего и в Allegro можно сделать также.

Нет, не получается. Дело в том, что при работе DxD c аллегро нет этой библиотеки, а вместо нее DxD генерит т.н. девайс-файлы, в которых вся информация и содержится. Берет он ее из схемы. Это можно либо отключить, либо создавать свой девайс-файл вручную, либо постоянно подменять PINSWAP в уже сгенеренном девайс-файле, но все эти варианты плохие, не буду расписывать почему, уверен, Вам это и так ясно. Отдельный вопрос по поводу Вашего варианта для PADS: при этом обратная аннотация как будет работать?
Вот так, по мелочам и накапливается... А про менеджер вариантов ничего не скажете? Будет он для нетлиста?

Ну обратная аннотация здесь никак не зависит. Ведь в обмене маршрута у нас всегда есть несколько (не)используемых файлов:
- нетлист
- файл компонентов
- файл обратной аннотации
Соответственно получается если в топологию загружаем нетлист, то в нем указано что используется компонент такой-то (Part_Number или DEVICE). Информацию по нему можно загрузить как из библиотеки топологического редактора, так и из файла генерированного из DxD - на ваш выбор. И она нам нужна только для того чтобы:
- узнать имя посадочного места
- прочитать информацию о свопируемости
- считать доп. атрибуты (если они есть) типа Высота и т.п.
При обратной аннотации генерируется файл с изменениями RefDes и # (номеров пинов) - типа, было DD1 стало DD9 (или был пин DD2.1 стал DD2.5). Которая и размещается на схеме, т.е. ищется на схеме компонент с номером DD1 и заменяется на DD9, тоже самое с пинами.

По поводу вариантов пока нет времени разбираться. Тем более что для PADS все может сильно поменяться в ближайшее время из-за появления ЦБ-PADS, по аналогии с ЦБ-Expedition. На разборки со старыми релизами тем более не хочется тратить свободное время (которого и так не много).

Свежее видео от зукена

http://www.youtube.com/watch?v=xZ8Iet4SqzU...player_embedded

Ммм... Хотите сказать, что, если я в схеме не задам PINSWAP для одной конкретной микросхемы, а задам его в библиотеке, то при обратной аннотации не будет попытки воссоздать этот атрибут (что приведет к ошибке из-за длины)? Ведь он прописан в секции AttPassList, и, следовательно, отслеживается при движениях и туда и обратно.


Дык я разве про старое спрашиваю?.. Я же про 7.9, вроде...
Видимо, если уже и в PADS появляется ЦБ, то нетлист скоро совсем загнется. Наверно, надо будет с DxD уходить. Не хотелось бы, отличный редактор же!


Сомнительно... Далеко в 3D не проведешь, ибо не видно, куда вести. А про две руки вообще непонятно на кого рассчитана реклама. Можно купить хоть 20 мышей и тачпадов и настроить себе кнопки на разные функции. И это будет работать с любыми программами, не только даже с САПР. А Zuken тут уж точно ни при чем!

Он не присутствует в группе
|BeginOatAtts
COM REFDES
COM $OBJNAME
PIN #
NET $OBJNAME
|EndOatAtts

Про 7.9 ответил в исходной ветке вопроса - VM есть и для нетлиста.

Ммм.. Не очевидно. Причем тут OAT? А если я вообще не буду OAT использовать в схеме?
Я не проверял сам, я просто спрашиваю на будущее.

Собственно говоря это значения присвоенные на уровне экземпляра. Т.е. например на начальном уровне в схеме стоит R?, после упаковки появилось значение R3. Которое записано в файле oat подключенному к проекту. Если включено oat, то видим R3, если не включено то R?
По аналогии в DxD7.хх есть значения:
Symbol - начальное
Block - блоковое
Instance - текущее реальное с платы

Кстати в конфиг. файле также есть ключевое слово


Что тоже решает задачу, по запрету аннотации на схему атрибута PINSWAP