Народ сформулируйте пожалуйста какие улучшения (т.е того чего нехватает в данный момент) необходимо сделать на ваш взгляд в маршруте PADS. Результаты опроса будут отосланы на ментор. Для начала надо 5 пунктов сгруппированных по степени важности. Поторопитесь, данные нужны мне до пятницы включительно.
Если даже не успеете, то тоже приму к сведению, но отложу это до следующего раза.
Полная версия этой страницы: Какие улучшения нужны для PADS
Форум разработчиков электроники ELECTRONIX.ru > Печатные платы (PCB) > Разрабатываем ПП в САПР - PCB development > Mentor PADS
Однозначно прежде всего скрестить Router и Layout. В Layout невозможно разводить, в Router невозможно платы проектировать.
И добавить нормальный Zoom: Ctrl+Scroll
А то почему-то в Router он есть, а в остальных - нет.
А то почему-то в Router он есть, а в остальных - нет.
1) Поворот текста на 180 и 270 град.
2) сделать в редакторе топологии видимую надпись на КП - название цепи (как в PCAD200x).
3) Flood Over Vias - и рядом кнопочку Select - чтобы при заливке полигонов можно было бы указать, какой из типов via или КП делать с термалками и какой - без (сейчас селектируется только по форме КП)
2) сделать в редакторе топологии видимую надпись на КП - название цепи (как в PCAD200x).
3) Flood Over Vias - и рядом кнопочку Select - чтобы при заливке полигонов можно было бы указать, какой из типов via или КП делать с термалками и какой - без (сейчас селектируется только по форме КП)
Цитата(Jul @ May 18 2006, 09:58) 
2) сделать в редакторе топологии видимую надпись на КП - название цепи (как в PCAD200x).
С возможностью включить/выключить.
Цитата(Jul @ May 18 2006, 09:58)
3) Flood Over Vias - и рядом кнопочку Select - чтобы при заливке полигонов можно было бы указать, какой из типов via или КП делать с термалками и какой - без (сейчас селектируется только по форме КП)
Присоединяюсь. Не очень часто этим пользуюсь, но иногда действительно нужно.
И наверное все-таки не помешали бы регионы и правила для них. Хотя бы из раздела Clearance.
Добавление к моему предыдущему сообщению:
Я сильно сомневаюсь, что слияние Router и Layout произойдет в обозримом будущем, хотя об этом заявлено уже давно. Дело в том, что, по моим наблюдениям, разработчики САПР (Ментор не исключение) очень охотно добавляют в свой продукт новые мелкие фишки и крайне неохотно переделывают всю концепцию продукта, коей и является слияние Router и Layout.
Конечно, постоянное метание при разработке платы между двумя редакторами есть самый противный момент в PADS. Это признавали многие в этом форуме. Но поскольку, скорее всего, до слияния еще очень далеко, очень хотелось бы, чтобы хотя бы исправили наконец баг Layout, который не признает полигоны в качестве разведенных цепей Например, в моем проекте на сегодняшний день неразведенных цепей нет (и Router это подтверждает), а Layout заявляет, что таковых 259 (!!!)
Я сильно сомневаюсь, что слияние Router и Layout произойдет в обозримом будущем, хотя об этом заявлено уже давно. Дело в том, что, по моим наблюдениям, разработчики САПР (Ментор не исключение) очень охотно добавляют в свой продукт новые мелкие фишки и крайне неохотно переделывают всю концепцию продукта, коей и является слияние Router и Layout.
Конечно, постоянное метание при разработке платы между двумя редакторами есть самый противный момент в PADS. Это признавали многие в этом форуме. Но поскольку, скорее всего, до слияния еще очень далеко, очень хотелось бы, чтобы хотя бы исправили наконец баг Layout, который не признает полигоны в качестве разведенных цепей Например, в моем проекте на сегодняшний день неразведенных цепей нет (и Router это подтверждает), а Layout заявляет, что таковых 259 (!!!)
1. инструмент измерений с возможностью привязки для контроля размеров (не путать с образмеркой чертежей).
2. Честный (свой!) экспорт IPC-D-356/IPC-D-356A.
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 симуляцию по моему мнению был вне конкуренции. Очень жаль.
Как известно существуют три вида полигонов:
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 симуляцию по моему мнению был вне конкуренции. Очень жаль.
Цитата(sh007 @ May 18 2006, 23:25)
Кому нужен PADS Logic, и не пора бы его место полостью занять DxDesigner.
Очень надеюсь, что к этому пожеланию не прислушаются
Ещё хотелось бы позамиствовать из PADS Logic в DxDesigner способ обратной анотации результата перестановки пинов в редакторе PCB. (Сам не проверял, но знакомые уверяют, что в PADS Logic это реализовано так как мне хочется)
Дело в том, что в результате обратной анотации меняются номера пинов на схемном элементе, а не имена подключенных цепей. Попробую пояснить в чём проблема. У современных ПЛИС большинство выводов по основной функции (I/O) взаимозаменяемо. Однако помимо оосновной функции у выводов существуют вторая, третья и т.д. функция, с учётом которых рассматривать как взаимозаменяемые эти выводы можно только в условиях конкретного проекта (не только PCB, но и прошивки ПЛИС). Но даже сформировав специфичный для данного проекта список свапируемых пинов, в результате обратной анотации мы получим не вполне корректную схему. Например вывод #=1 имеет функцию IO/ABC, а вывод #=2 имеет функцию IO/CBA. Если для нас в данном проекте вторые функции ABC и CBA неважны, мы свапируем эти выводы, и в результате обратной анотации на схеме получаем, что вывод IO/ABC имеет #=2, а вывод IO/CBA имеет #=1. В дальнейшем, любой инженер изучающий схему, вполне спрваедливо укажет на ошибку. Если же поменять имена подключенных цепей, такой проблемы не произойдёт.
Дело в том, что в результате обратной анотации меняются номера пинов на схемном элементе, а не имена подключенных цепей. Попробую пояснить в чём проблема. У современных ПЛИС большинство выводов по основной функции (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 в Dx and обратно сделать в одной программе.
а то у PADS одна у DX другая.
бывает часто что после использования
одной другой пользоваться нет возможности.
"Forward to PCB" делается не корректно.
так же Wazard для FanOut
для BGA а то сейчас только для без корпусных BGA "DIE" очень раздражает что нет сравнения с библиотекой.
если я отредактировал DECAL в библиотеке.
то не фиксируется дата.
не мешало вы подумать о стыковке с каким либо
менедтгером версий.
Цитата(sh007 @ May 19 2006, 10:19)
Ещё хотелось бы позамиствовать из PADS Logic в DxDesigner способ обратной анотации результата перестановки пинов в редакторе PCB. (Сам не проверял, но знакомые уверяют, что в PADS Logic это реализовано так как мне хочется)
Дело в том, что в результате обратной анотации меняются номера пинов на схемном элементе, а не имена подключенных цепей. Попробую пояснить в чём проблема. У современных ПЛИС большинство выводов по основной функции (I/O) взаимозаменяемо. Однако помимо оосновной функции у выводов существуют вторая, третья и т.д. функция, с учётом которых рассматривать как взаимозаменяемые эти выводы можно только в условиях конкретного проекта (не только PCB, но и прошивки ПЛИС). Но даже сформировав специфичный для данного проекта список свапируемых пинов, в результате обратной анотации мы получим не вполне корректную схему. Например вывод #=1 имеет функцию IO/ABC, а вывод #=2 имеет функцию IO/CBA. Если для нас в данном проекте вторые функции ABC и CBA неважны, мы свапируем эти выводы, и в результате обратной анотации на схеме получаем, что вывод IO/ABC имеет #=2, а вывод IO/CBA имеет #=1. В дальнейшем, любой инженер изучающий схему, вполне спрваедливо укажет на ошибку. Если же поменять имена подключенных цепей, такой проблемы не произойдёт.
Дело в том, что в результате обратной анотации меняются номера пинов на схемном элементе, а не имена подключенных цепей. Попробую пояснить в чём проблема. У современных ПЛИС большинство выводов по основной функции (I/O) взаимозаменяемо. Однако помимо оосновной функции у выводов существуют вторая, третья и т.д. функция, с учётом которых рассматривать как взаимозаменяемые эти выводы можно только в условиях конкретного проекта (не только PCB, но и прошивки ПЛИС). Но даже сформировав специфичный для данного проекта список свапируемых пинов, в результате обратной анотации мы получим не вполне корректную схему. Например вывод #=1 имеет функцию IO/ABC, а вывод #=2 имеет функцию IO/CBA. Если для нас в данном проекте вторые функции ABC и CBA неважны, мы свапируем эти выводы, и в результате обратной анотации на схеме получаем, что вывод IO/ABC имеет #=2, а вывод IO/CBA имеет #=1. В дальнейшем, любой инженер изучающий схему, вполне спрваедливо укажет на ошибку. Если же поменять имена подключенных цепей, такой проблемы не произойдёт.
Это реализовывать наверняка не будут, т.к расходится полностью с устоявшимися процедурами во всех маршрутах (кроме PADS_Logic-PADS_Layout).
1. В данный момент везде принято менять только номера пинов, это и проще и не приводит к печальным результатам. Если менять имена цепей то представте например нарисована цепь которая разветвляется и подключается к двум пинам, у одного из них произошел swap, тогда помимо изменения имени цепи на отрезке подключенном к этому пину надо еще и отрезать этот отрезок от старой цепи. Т.е обратная аннотация приведет к тому что схему надо будет все равно править вручную дорисовывая цепи (единственный вариант когда можно более менее безболезненно менять имена цепей, это если они не прорисовываются полностью, а только короткими отрезками от пинов и соединение происходит только виртуально по именам).
2. Вы не учитываете что есть еще другие пути реализации процесса FPGA-PCB, например:
- I/O_Designer - swap можно сделать в нем и сгенерить(перегенерить) из него набор символов для схемы и Part для платы
- в I/O_Designer помимо PCB символов (где обычно имена пинов взяты из Datasheet) можно создавать Функциональные символы (где имена пинов это например имена сигналов). Рисуем верхнюю схему на функциональных символах, по ней легко понять логику работы устройства, а под функциональными символами лежат подсхемы нарисованные с применением PCB символов (причем эти подсхемы автоматом генерятся из I/O_Designer) изменение номеров пинов происходит на этом уровне, но с точки зрения понятия логики работы устройства нас это уже не затрагивает, т.к логику работы мы анализируем на уровень выше, а там ничего не меняется.
Цитата(sh007 @ May 19 2006, 00:25)
То что касается 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 симуляцию по моему мнению был вне конкуренции. Очень жаль.
Как известно существуют три вида полигонов:
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
for fill
Александр, я подготовил тестовый проект, демонстрирующий вышеописанные особенности поведения PADS. Каким образом удобнее передать его Вам для рассмотрения? (77кбайт).
То, что касается технологии свопинга пинов Вы меня практически убедили.
Возможность же указывать имя библиотеки в атрибутах DEVICE и PKG_TYPE всё же видится желательной.
Александр, я подготовил тестовый проект, демонстрирующий вышеописанные особенности поведения PADS. Каким образом удобнее передать его Вам для рассмотрения? (77кбайт).
То, что касается технологии свопинга пинов Вы меня практически убедили.
Возможность же указывать имя библиотеки в атрибутах DEVICE и PKG_TYPE всё же видится желательной.
Цитата(sh007 @ May 19 2006, 16:29)
for fill
Александр, я подготовил тестовый проект, демонстрирующий вышеописанные особенности поведения PADS. Каким образом удобнее передать его Вам для рассмотрения? (77кбайт).
То, что касается технологии свопинга пинов Вы меня практически убедили.
Возможность же указывать имя библиотеки в атрибутах DEVICE и PKG_TYPE всё же видится желательной.
Александр, я подготовил тестовый проект, демонстрирующий вышеописанные особенности поведения PADS. Каким образом удобнее передать его Вам для рассмотрения? (77кбайт).
То, что касается технологии свопинга пинов Вы меня практически убедили.
Возможность же указывать имя библиотеки в атрибутах DEVICE и PKG_TYPE всё же видится желательной.
1. файл можете послать на fill@megratec.ru
2. по поводу работы с библиотекой все в будущем для PADS может изменится т.к в планы включен пункт поддержки ОБЩЕЙ для ВСЕХ маршрутов базы данных (CDB) и библиотек
to Fill
может проинформируете каких изменений стоит ожидать от нового PADS. труд вроде был коллективный.
может проинформируете каких изменений стоит ожидать от нового PADS. труд вроде был коллективный.
DxDesigner (в частности DxDatabook) использует следующие децимирующие приставки, не соответствующие принятым в системе СИ:
Кило - "K" вместо "k"
Мега - "MEG" вместо "M"
Остальные приставки кодируются правильно.
Было бы очень удобно, если устранить указанное несоответствие.
Кило - "K" вместо "k"
Мега - "MEG" вместо "M"
Остальные приставки кодируются правильно.
Было бы очень удобно, если устранить указанное несоответствие.
Цитата(KA_ru @ May 22 2006, 17:18)
to Fill
может проинформируете каких изменений стоит ожидать от нового PADS. труд вроде был коллективный.
может проинформируете каких изменений стоит ожидать от нового PADS. труд вроде был коллективный.
Какой же это труд. Вы сформулировали то что хотели бы иметь. Ментор рассмотрит предложения и поставит их в очередь по порядку приоритетов. В данный момент европейский ментор получил около 60-ти таких пожеланий от всех европейских дистрибьюторов
. Теперь каждому из дистрибьюторов надо будет выбрать 5-ть наиболее значимых 
- в итоге и получится общий приоритет задач.
вот и хорошо!!!!!
значит от меня он уже два раза получили.
если конечно наш дистрибьютор их тоже подал.
значит от меня он уже два раза получили.
если конечно наш дистрибьютор их тоже подал.
Цитата(KA_ru @ May 24 2006, 11:28)
вот и хорошо!!!!!
значит от меня он уже два раза получили.
если конечно наш дистрибьютор их тоже подал.
значит от меня он уже два раза получили.
если конечно наш дистрибьютор их тоже подал.
Смотря к кому вы относитесь, в моем списке только :
Scandinavia, Finland, Germany, Great Britan, France, Italy, Swiss, Austria, the Czech Republic, South Africa and Russia
PS. Дублирующие запросы были исключены из списка выбора приоритетов (так что подача от нескольких VAR ничего не значит, если только эти VAR не захотят поддержать исключительно свои запросы)
.
Цитата(fill @ May 19 2006, 15:49)
2. по поводу работы с библиотекой все в будущем для PADS может изменится т.к в планы включен пункт поддержки ОБЩЕЙ для ВСЕХ маршрутов базы данных (CDB) и библиотек
Означает ли это, что схемы для Expedition PCB можно будет рисовать в Pads Logic? А то я уже начал ваять скрипт для формирования NetList.kyn из Logic...
Цитата(Vadim @ May 31 2006, 17:47)
Цитата(fill @ May 19 2006, 15:49)
2. по поводу работы с библиотекой все в будущем для PADS может изменится т.к в планы включен пункт поддержки ОБЩЕЙ для ВСЕХ маршрутов базы данных (CDB) и библиотек
Означает ли это, что схемы для Expedition PCB можно будет рисовать в Pads Logic? А то я уже начал ваять скрипт для формирования NetList.kyn из Logic...
Ну это вряд ли. Я думаю мало кому захочется работать в связке PADS_Logic-ExpeditionPCB
Цитата(fill @ May 31 2006, 17:05)
Цитата(Vadim @ May 31 2006, 17:47)
Цитата(fill @ May 19 2006, 15:49)
2. по поводу работы с библиотекой все в будущем для PADS может изменится т.к в планы включен пункт поддержки ОБЩЕЙ для ВСЕХ маршрутов базы данных (CDB) и библиотек
Означает ли это, что схемы для Expedition PCB можно будет рисовать в Pads Logic? А то я уже начал ваять скрипт для формирования NetList.kyn из Logic...
Ну это вряд ли. Я думаю мало кому захочется работать в связке PADS_Logic-ExpeditionPCB
Значит, продолжаю ваять
Цитата(fill @ May 19 2006, 12:54)
Цитата(sh007 @ May 19 2006, 10:19)
А... В дальнейшем, любой инженер изучающий схему, вполне спрваедливо укажет на ошибку. Если же поменять имена подключенных цепей, такой проблемы не произойдёт.
Это реализовывать наверняка не будут, т.к расходится полностью с устоявшимися процедурами во всех маршрутах (кроме PADS_Logic-PADS_Layout).
B....... В данный момент везде принято менять только номера пинов, это и проще и не приводит к печальным результатам. Если менять имена цепей то .......
Хоть я и опоздал со своим мнением, но здесь полностью поддерживаю точку зрения (п.В) т.е. fill.
- Грабли, реализованные по желанию sh007 (п.А) имеются в PCAD200x. Ужасная штука. После свопирования тратится довольно много времени на правку схемы(поскольку требуются дополнительные проверки) или нужно изгаляться с символами схемы - что тоже не подарок. А без правки получается "лес чудес" и "клубок нервов". в смысле читаемости схемы.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.