Народ сформулируйте пожалуйста какие улучшения (т.е того чего нехватает в данный момент) необходимо сделать на ваш взгляд в маршруте PADS. Результаты опроса будут отосланы на ментор. Для начала надо 5 пунктов сгруппированных по степени важности. Поторопитесь, данные нужны мне до пятницы включительно.
Если даже не успеете, то тоже приму к сведению, но отложу это до следующего раза.

Однозначно прежде всего скрестить Router и Layout. В Layout невозможно разводить, в Router невозможно платы проектировать.

И добавить нормальный Zoom: Ctrl+Scroll
А то почему-то в Router он есть, а в остальных - нет.

1) Поворот текста на 180 и 270 град.
2) сделать в редакторе топологии видимую надпись на КП - название цепи (как в PCAD200x).
3) Flood Over Vias - и рядом кнопочку Select - чтобы при заливке полигонов можно было бы указать, какой из типов via или КП делать с термалками и какой - без (сейчас селектируется только по форме КП)

С возможностью включить/выключить.



Присоединяюсь. Не очень часто этим пользуюсь, но иногда действительно нужно.

И наверное все-таки не помешали бы регионы и правила для них. Хотя бы из раздела Clearance.

Добавление к моему предыдущему сообщению:
Я сильно сомневаюсь, что слияние Router и Layout произойдет в обозримом будущем, хотя об этом заявлено уже давно. Дело в том, что, по моим наблюдениям, разработчики САПР (Ментор не исключение) очень охотно добавляют в свой продукт новые мелкие фишки и крайне неохотно переделывают всю концепцию продукта, коей и является слияние Router и Layout.
Конечно, постоянное метание при разработке платы между двумя редакторами есть самый противный момент в PADS. Это признавали многие в этом форуме. Но поскольку, скорее всего, до слияния еще очень далеко, очень хотелось бы, чтобы хотя бы исправили наконец баг Layout, который не признает полигоны в качестве разведенных цепей Например, в моем проекте на сегодняшний день неразведенных цепей нет (и Router это подтверждает), а Layout заявляет, что таковых 259 (!!!)

1. инструмент измерений с возможностью привязки для контроля размеров (не путать с образмеркой чертежей).
2. Честный (свой!) экспорт IPC-D-356/IPC-D-356A.

То что касается PADS, то в первую очередь работа с полигонами
Как известно существуют три вида полигонов:
1. CAM Plane
2. Plane
3. Flood

1. CAM Plane.
В своё время была замечена следующая ошибка. Слотовый вывод, несмотря на то, что правильно формируется в самой системе PADS, при трансляции в CAM350, в слое CAM Plane преобразуется в круглую контактную площадку.

2. Plane.
У элементов имеющих одновременно планарные и штыревые выводы (например, планарные микросхемы имеющие PowerPAD подключенный к земленому плану сквозными отверстиями), планарные выводы соединённые с землёй, при трансляции в CAM350 преобазуются в круглые контактные площадки, хотя в самой системе PADS и даже в CAM Preview отрисовываются корректно. (Если будет интересно, то могу предоставить тестовый пример).

3. Flood.
Зазоры между контактными площадками и областью заливки формируются в соответствии с требованиями Design Rules, а не в соответстии с описанием thermals и antipad из pad staсks. Возможно в этом можно и найти некоторую логику. Но мне, как правило, приходится объяснять её другим людям с большим трудом в усвоении.

Если уж вместе с PADS идёт DxDesigner. Кому нужен PADS Logic, и не пора бы его место полостью занять DxDesigner.
Я имею ввиду интеграцию библиотек.
Далее несколько пожеланий по поводу DxDesigner.

1. При работе с современными большими микросхемами задание и редактирование сверхдлинных атрибутов (SIGNAL,NC,PINSWAP) стало крайне неудобным. Ситуация усугубляется ещё и тем, что всё это большое количество сверхдлинных атрибутов должно присутствовать у каждой секции элемента. В своё время проблему частично решили, позволив формировать файлы *.pin и *.ppn. На мой взгляд, вполне логично было бы позволить формировать файл <device_name>.att, содержащий все атрибуты.

2. При указании в атрибуте DEVICE=<COMP_NAME> имени компонета, нет возможности указать имя библиотеки. Это нехорошо, т.к. не допускает иметь компоненты с одинаковыми именами в разных библиотеках. То же самое касается и атрибута PKG_TYPE. Более логичным было бы указание DEVICE=<LIBNAME>:<COMP_NAME>. У самого DxDesigner подобная симантека нормально работает в DxDatabook при указании символьного элемента и в пр. условиях.

3. Есть очень серьёзное сожаление, что прекратилось развитие симуляторов. Fusion, объединявший Gate, VHDL, VERILOG и SPICE симуляцию по моему мнению был вне конкуренции. Очень жаль.

Очень надеюсь, что к этому пожеланию не прислушаются

Ещё хотелось бы позамиствовать из PADS Logic в DxDesigner способ обратной анотации результата перестановки пинов в редакторе PCB. (Сам не проверял, но знакомые уверяют, что в PADS Logic это реализовано так как мне хочется)
Дело в том, что в результате обратной анотации меняются номера пинов на схемном элементе, а не имена подключенных цепей. Попробую пояснить в чём проблема. У современных ПЛИС большинство выводов по основной функции (I/O) взаимозаменяемо. Однако помимо оосновной функции у выводов существуют вторая, третья и т.д. функция, с учётом которых рассматривать как взаимозаменяемые эти выводы можно только в условиях конкретного проекта (не только PCB, но и прошивки ПЛИС). Но даже сформировав специфичный для данного проекта список свапируемых пинов, в результате обратной анотации мы получим не вполне корректную схему. Например вывод #=1 имеет функцию IO/ABC, а вывод #=2 имеет функцию IO/CBA. Если для нас в данном проекте вторые функции ABC и CBA неважны, мы свапируем эти выводы, и в результате обратной анотации на схеме получаем, что вывод IO/ABC имеет #=2, а вывод IO/CBA имеет #=1. В дальнейшем, любой инженер изучающий схему, вполне спрваедливо укажет на ошибку. Если же поменять имена подключенных цепей, такой проблемы не произойдёт.

было бы не плохо задавать правила для полигонов.
и областей. а то сейчас надо делать всякие извороты.

стыковку из PADS в Dx and обратно сделать в одной программе.
а то у PADS одна у DX другая.

бывает часто что после использования
одной другой пользоваться нет возможности.
"Forward to PCB" делается не корректно.

так же Wazard для FanOut для BGA а то сейчас только для без корпусных BGA "DIE"

очень раздражает что нет сравнения с библиотекой.
если я отредактировал DECAL в библиотеке.
то не фиксируется дата.

не мешало вы подумать о стыковке с каким либо
менедтгером версий.

Это реализовывать наверняка не будут, т.к расходится полностью с устоявшимися процедурами во всех маршрутах (кроме PADS_Logic-PADS_Layout).
1. В данный момент везде принято менять только номера пинов, это и проще и не приводит к печальным результатам. Если менять имена цепей то представте например нарисована цепь которая разветвляется и подключается к двум пинам, у одного из них произошел swap, тогда помимо изменения имени цепи на отрезке подключенном к этому пину надо еще и отрезать этот отрезок от старой цепи. Т.е обратная аннотация приведет к тому что схему надо будет все равно править вручную дорисовывая цепи (единственный вариант когда можно более менее безболезненно менять имена цепей, это если они не прорисовываются полностью, а только короткими отрезками от пинов и соединение происходит только виртуально по именам).
2. Вы не учитываете что есть еще другие пути реализации процесса FPGA-PCB, например:
- I/O_Designer - swap можно сделать в нем и сгенерить(перегенерить) из него набор символов для схемы и Part для платы
- в I/O_Designer помимо PCB символов (где обычно имена пинов взяты из Datasheet) можно создавать Функциональные символы (где имена пинов это например имена сигналов). Рисуем верхнюю схему на функциональных символах, по ней легко понять логику работы устройства, а под функциональными символами лежат подсхемы нарисованные с применением PCB символов (причем эти подсхемы автоматом генерятся из I/O_Designer) изменение номеров пинов происходит на этом уровне, но с точки зрения понятия логики работы устройства нас это уже не затрагивает, т.к логику работы мы анализируем на уровень выше, а там ничего не меняется.

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

По поводу моделирования - через месяц должен появиться релиз для пользователей в котором будет новое окружение - DxSim:
Complete board-level simulation environment
—Digital simulation based on ModelSim
��Includes back annotation of simulation values to schematic
—DxSim
��High-performance analog simulation based on Eldo
—IC-strength performance and capacity
��Mixed A/D simulation based on ADMS
—Industry leading mixed signal simulation
—Full support for SPICE, Verilog-A(MS), VHDL-AMS, C, Verilog, VHDL

for fill
Александр, я подготовил тестовый проект, демонстрирующий вышеописанные особенности поведения PADS. Каким образом удобнее передать его Вам для рассмотрения? (77кбайт).

То, что касается технологии свопинга пинов Вы меня практически убедили.

Возможность же указывать имя библиотеки в атрибутах DEVICE и PKG_TYPE всё же видится желательной.

1. файл можете послать на fill@megratec.ru
2. по поводу работы с библиотекой все в будущем для PADS может изменится т.к в планы включен пункт поддержки ОБЩЕЙ для ВСЕХ маршрутов базы данных (CDB) и библиотек