Какие улучшения нужны для PADS, Опрос Опции

[fill]

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

[sh007]

То что касается 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 симуляцию по моему мнению был вне конкуренции. Очень жаль.

[fill]

То что касается 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 симуляцию по моему мнению был вне конкуренции. Очень жаль.

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