Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Part Editor
Форум разработчиков электроники ELECTRONIX.ru > Печатные платы (PCB) > Разрабатываем ПП в САПР - PCB development > Mentor-ExpeditionPCB
KostyantynT
Добрый день, всем.

Наверно, проще сменить пол и привыкнуть к новому. чем из пикада перейти в ментор ;-)
Вопрос. В символе компоненты есть имя например Vcc. В парте к нему должно быть подключено несколько выводов. например 5,6. Как в редакторе компонента это сделать. Буржуи рекомендуют не париться и рисовать все выводы. Но если я поменяю корпус. а там может быть не 2 а 3 вывода на одно имя.
decom
Если я правильно понял вопрос, Вы хотите один раз нарисовать символ и потом использовать его для 10 вариантов ячеек. Затея хорошая, но такого рода оптимизация выйдет Вам боком в будущем.
KostyantynT
Цитата(decom @ Apr 23 2013, 17:14) *
Если я правильно понял вопрос, Вы хотите один раз нарисовать символ и потом использовать его для 10 вариантов ячеек. Затея хорошая, но такого рода оптимизация выйдет Вам боком в будущем.

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

Цитата(decom @ Apr 23 2013, 17:14) *
Если я правильно понял вопрос, Вы хотите один раз нарисовать символ и потом использовать его для 10 вариантов ячеек. Затея хорошая, но такого рода оптимизация выйдет Вам боком в будущем.

Ну да, корпуса бывают разные. А в чем подвох, где бока могут вылезти?

Что там флагман плато проектирования думает на этот счет?
telix
Цитата(КонстантинТ @ Apr 23 2013, 18:19) *
Ну да, корпуса бывают разные. А в чем подвох, где бока могут вылезти?

Если дело только в корпусе, тогда вопрос решается автоматом, переназначаете номера пинов и все.
А вот если как Вы сказали "тут два VCC, а там 3 VCC" тогда, извините, и символы будут разные. И производители эти символы в даташите дают. То есть два, три разных символа на одну микруху если функционал чуть но отличается.
KostyantynT
Цитата(telix @ Apr 23 2013, 17:45) *
Если дело только в корпусе, тогда вопрос решается автоматом, переназначаете номера пинов и все.
А вот если как Вы сказали "тут два VCC, а там 3 VCC" тогда, извините, и символы будут разные. И производители эти символы в даташите дают. То есть два, три разных символа на одну микруху если функционал чуть но отличается.

Вот например есть компонент BQ24272 у него на ногу AGND для корпуса QFN заведено два пина, а дя корпуса BGA - 5. Так что, для разных корпусов рисовать разные символы? Хотелось бы использовать alternites cell.
Frederic
Цитата(КонстантинТ @ Apr 23 2013, 17:53) *
Вот например есть компонент BQ24272 у него на ногу AGND для корпуса QFN заведено два пина, а дя корпуса BGA - 5. Так что, для разных корпусов рисовать разные символы? Хотелось бы использовать alternites cell.

число ног разное в корпусах
далее в QFN нумерация цифровая, а в BGA буквенно-цифровая

заниматься переназначением - долгий и нудный путь
проще иметь символ под каждый корпус
SII
Можно ж задать ноги под землю и питания по именам в Part Editor, а потом в схемном редакторе привязать к конкретным цепять с помощью атрибута (Supply Rename вроде как).
Frederic
Цитата(SII @ Apr 23 2013, 18:32) *
Можно ж задать ноги под землю и питания по именам в Part Editor, а потом в схемном редакторе привязать к конкретным цепять с помощью атрибута (Supply Rename вроде как).

конечно можно sm.gif
так удобно делать для мелкой логики,
но для больших мелкосхем с множеством ног и разными питанием и землями лучше вынести в отдельный символ и размещать эти символы на отдельном листе в DxD.
получается очень наглядно и просто
KostyantynT
Цитата(Frederic @ Apr 23 2013, 20:34) *
конечно можно sm.gif
так удобно делать для мелкой логики,
но для больших мелкосхем с множеством ног и разными питанием и землями лучше вынести в отдельный символ и размещать эти символы на отдельном листе в DxD.
получается очень наглядно и просто

Ок понятно, будем делать два корпуса и два символа и каждый пин свой вывод на символе.
SM
Цитата(Frederic @ Apr 23 2013, 21:34) *
но для больших мелкосхем с множеством ног и разными питанием и землями лучше вынести в отдельный символ и размещать эти символы на отдельном листе в DxD.
получается очень наглядно и просто

А вот мое IMHO говорит наоборот. Получается куча лишней работы, ничего не дающей, и перегружающей схему. Один атрибут "Supply Rename = VCCA=3.0VA VCC=1.2V VIO=3.3V VREF=SDR_REF VDDL=V_DLL DGND=GND AGND=GND POWERPAD=GND" понятен, прост и всеобъемлющ, и на символах лишнего нету, все лаконично и повторно используемо. А, главное, не надо рисовать эти 18 пинов VCC и 46 штук DGND. А лишь в парт эдиторе вбить их в supply с соотв. названием, что быстро и просто. Да и ГОСТ, если что, допускает.


А еще скажу, по большому секрету, что в CELL-е можно сделать несколько падов с одним (одинаковым) пин намбером. И тогда подключение к нему ОДНОГО пина символа подключит все эти пады с таким одинаковым номером к этому пину sm.gif sm.gif Я так полевики делаю, у которых куча выводов от стока и истока, чтобы символ полевика был ГОСТовский, а не многоногий.
KostyantynT
Цитата(SM @ Apr 25 2013, 23:47) *
А вот мое IMHO говорит наоборот. Получается куча лишней работы, ничего не дающей, и перегружающей схему. Один атрибут "Supply Rename = VCCA=3.0VA VCC=1.2V VIO=3.3V VREF=SDR_REF VDDL=V_DLL DGND=GND AGND=GND POWERPAD=GND" понятен, прост и всеобъемлющ, и на символах лишнего нету, все лаконично и повторно используемо. А, главное, не надо рисовать эти 18 пинов VCC и 46 штук DGND. А лишь в парт эдиторе вбить их в supply с соотв. названием, что быстро и просто. Да и ГОСТ, если что, допускает.


А еще скажу, по большому секрету, что в CELL-е можно сделать несколько падов с одним (одинаковым) пин намбером. И тогда подключение к нему ОДНОГО пина символа подключит все эти пады с таким одинаковым номером к этому пину sm.gif sm.gif Я так полевики делаю, у которых куча выводов от стока и истока, чтобы символ полевика был ГОСТовский, а не многоногий.

Ага, яже говорил, можно сделать. Спасибо, в понедельник попробую.
decom
.
Uree
Чувствуется огромный опыт в предыдущем совете. Был случай - на схеме было больше сотни пинов земли у процессора. Один из них по ошибке бы не земля, а питание. Но размещен в символе, который содержал только земли... все, кроме одного. Итого - один пин питания посажен на землю. Отличный принцип рисования схем, однозначно... наилучший, чё уж там.
Если рисуешь сам, и рисуешь компонент, который можешь реально пару-тройку раз проверить - да, наверное. Но, тут я соглащусь с Vitan, - описательный подход минимизирует возможность ошибки в этом моменте. В графике выловить ошибку много сложнее, чем в тексте. Выводы каждый сделает сам.
vitan
Цитата(Uree @ Apr 28 2013, 03:34) *
Но, тут я соглащусь с Vitan, - описательный подход минимизирует возможность ошибки в этом моменте. В графике выловить ошибку много сложнее, чем в тексте.

Не совсем. Минимизирует ошибки не текст, а автоматизация. Она может быть применена и к графике, но тут - да, сложнее. Ошибка с одним пином питания явно возникла из-за ручного труда. И тут уже все равно, скрытые ли пины, явно заданные или еще какие-то...
Frederic
Цитата(vitan @ Apr 28 2013, 10:32) *
Не совсем. Минимизирует ошибки не текст, а автоматизация. Она может быть применена и к графике, но тут - да, сложнее. Ошибка с одним пином питания явно возникла из-за ручного труда. И тут уже все равно, скрытые ли пины, явно заданные или еще какие-то...

к сожалению без ручного труда не обойтись и фактор ошибки присутсвует в любой ветки создания символа с крытыми или явными пинами питания
обе ветки имеют право на существование, но оценивая удобство и трудозатраты каждый сам решает по какому пути идти
например в TMS320C6457 корпусе BGA у меня 8 сигнальных + 2 питания + 2 земли символов
имеются пины питания которые необходимо запитывать через LC фильтры или просто R и сответственно их не очень удобно ввести в скрытые
в проекте стоит два процессора и в процессе модификации схемы (пришлось на каждый процессор ставилось индивидуальные питатели по некоторым уровням и такие изменения были не один раз) при изменение наименования пинания не обходимо изменить скрытые имена питания в 8 символах
и в данном случае наверно удобнее иметь по листу схемы питания и земли для каждого процессора
vitan
Цитата(Frederic @ Apr 28 2013, 12:50) *
к сожалению без ручного труда не обойтись

хм, смотря как организовать, у меня ручной труд состоит разве что в нажатии ctrl-c - ctrl-v. количество 'уго' доходит до 40 на одну микросхему, и ничего, никакие пины случайно никуда не попадают.
Т.е. от таких ошибок можно избавиться, но избавление состоит именно в автоматизации, а не в выборе стиля рисования.
Frederic
Цитата(vitan @ Apr 28 2013, 16:01) *
хм, смотря как организовать, у меня ручной труд состоит разве что в нажатии ctrl-c - ctrl-v.

и если надо изменить в скрытых пинах +3V3-1 на +3V3-2 вы предлагаете 39 раз ctrl-c - ctrl-v ???
вместо трех нажатий мышки и выбора Replace Symbol
SII
А зачем менять в самих символах, когда можно менять атрибут, привязанный к символу?
Frederic
Цитата(SII @ Apr 28 2013, 19:37) *
А зачем менять в самих символах, когда можно менять атрибут, привязанный к символу?

в мелкой логике я изменяю значение SupplyRename in DxD, а тут не допонимаю sad.gif
не будем переходить в личку, может будет интересно и другим, поясните плиз подробнее - лучше дать пару картинок и будет понятно
SII
Ну, готового проекта с подобным подходом у меня пока что нет (я вообще программист, если на то пошло, и занимаюсь конструированием и разводкой из-за того, что больше некому). Но идея тут проста, так что постараюсь её описать.

Если у некоей ИС есть 5 разных напряжений питания, то при создании соответствующего компонента в Part Editor создаём пять групп ног питания с именами вроде VDD1, VDD2 и т.д. (ну или, например, AVDD и DVDD для "аналогового" и "цифрового" питаний). Если для подачи какого-то из этих напряжений используется несколько ног, то все эти ноги попадают в одну группу и, соответственно, имеют общее имя. Точно так же поступаем с земляными ногами.

Далее, когда рисуем принципиальную схему, к компоненту цепляем атрибут Supply Rename, привязывая эти группы к конкретным цепям питания/земли (типа "VCC1=+3.3V VCC2=+5V" и т.д. -- вроде там такой синтаксис). Если в схеме нам нужны несколько одинаковых ИС, причём привязка их питаний выполняется к разным цепям (например, для каждой ИС существуют свои источники питания), то значения атрибута Supply Rename для этих ИС на схеме будут разными, привязывая их группы ног питания/земли к разным цепям, ну а если все эти ИС подключаются к одним и тем же цепям, то, естественно, и Supply Rename у всех будет одинаковым.

В результате набор символов всегда один и тот же, ничего в компонентах менять не надо (создаются один раз и навсегда), нет загромождения схемы лишними символами, единственное назначение которых -- показать подачу питания. Из недостатков -- нельзя прямо по схеме посмотреть, к каким конкретно ногам какие напряжения подаются, надо заглядывать в даташит, чтобы выяснить соответствие между именами групп ног питания/земли и номерами этих ног. Но, думается, реальным этот недостаток не является, потому что к ногам BGA-корпуса всё равно не дотянешься, чтоб посмотреть, подаётся ли на них напряжение, а другой нужды в знании конкретных номеров я и не вижу...
Uree
Единственная нужда - проверить какие это ноги и понять где они в корпусе находятся. Без этого как-то не очень удобно...
KostyantynT
Тогда следующий вопрос. Про целлы и падстаки. Создаем cell согласно IPC7135. Создаю тот-же cell в LP Wizard. Там только необходимо поставить тип и размеры компонента. Сравниваем падстаки - на выходе LP Wizard они отличаются от рекомендованных IPC. Кому верить, какие лучше использовать?
SM
Цитата(КонстантинТ @ Apr 29 2013, 15:20) *
Кому верить, какие лучше использовать?


Лучше всего, если есть рекомендации производителя. Они очень часто сильно расходятся с IPC, а зато оптимизируют место, занимаемое паттерном, и уменьшают брак при пайке оплавлением (зато создают сложности для ручной пайки из-за минимализма).



Цитата(Frederic @ Apr 28 2013, 22:29) *
в мелкой логике я изменяю значение SupplyRename in DxD, а тут не допонимаю sad.gif


В крупной так же. Допустим ПЛИС (допустим IOD нету в природе). Создаем для каждого банка свой VCCIO0...VCCIOn, и VCC для core, и VCCAUX например для латисовского vccaux, и их по списку присваиваем цепям в аттрибуте Supply Rename, через пробел - VCCIO1=3.3V VCCIO2=1.8V VCCIO3=.... и т.д., а в компоненте - каждой группе пинов ассоциирован свой VCCIOn [к примеру n=7...0]. То есть аттрибут Supply Rename может содержать список соединений условных названий питаний с цепями, а не одну цепь.

А если отдельный пин (отдельные пины) надо отдельно завести через LC, и он(они), увы, назван[ы] так же, как и группа пинов, то есть аттрибут Supply Pin.

Все это освобождает разработчика как от перегрузки схемы символами питаний, так и от собственно возни по их созданию в графике.


вот пример для DDR2 SDRAM 1Gbit x16
Нажмите для просмотра прикрепленного файла

видно, что тут несколько питаний:
VDD/GND - основное питание
VDDQ/GNDQ - питание IO
VDDL/GNDDL - питание DLL
ну и SD_A14 это мой изврат, чтобы без исправления символа подключить и 2G сдрам.

Ну и аттрибут на схеме:
'Supply Rename' = 'VDD=1.8V VDDQ=1.8V VDDL=VDLL GNDQ=GND GNDDL=GND'

итого, все подключено куда мне надо без графики, и переподключить если что на "раз-два"
KostyantynT
Цитата(SM @ Apr 29 2013, 15:43) *
Лучше всего, если есть рекомендации производителя. Они очень часто сильно расходятся с IPC, а зато оптимизируют место, занимаемое паттерном, и уменьшают брак при пайке оплавлением (зато создают сложности для ручной пайки из-за минимализма).





В крупной так же. Допустим ПЛИС (допустим IOD нету в природе). Создаем для каждого банка свой VCCIO0...VCCIOn, и VCC для core, и VCCAUX например для латисовского vccaux, и их по списку присваиваем цепям в аттрибуте Supply Rename, через пробел - VCCIO1=3.3V VCCIO2=1.8V VCCIO3=.... и т.д., а в компоненте - каждой группе пинов ассоциирован свой VCCIOn [к примеру n=7...0]. То есть аттрибут Supply Rename может содержать список соединений условных названий питаний с цепями, а не одну цепь.

А если отдельный пин (отдельные пины) надо отдельно завести через LC, и он(они), увы, назван[ы] так же, как и группа пинов, то есть аттрибут Supply Pin.

Все это освобождает разработчика как от перегрузки схемы символами питаний, так и от собственно возни по их созданию в графике.


вот пример для DDR2 SDRAM 1Gbit x16
Нажмите для просмотра прикрепленного файла

видно, что тут несколько питаний:
VDD/GND - основное питание
VDDQ/GNDQ - питание IO
VDDL/GNDDL - питание DLL
ну и SD_A14 это мой изврат, чтобы без исправления символа подключить и 2G сдрам.

Ну и аттрибут на схеме:
'Supply Rename' = 'VDD=1.8V VDDQ=1.8V VDDL=VDLL GNDQ=GND GNDDL=GND'

итого, все подключено куда мне надо без графики, и переподключить если что на "раз-два"

Спасибо за развернутый ответ, я примерно так и начинал, потом засомневался и вызвал буру споров. Тогда можно и разные корпуса на один символ садить.
Frederic
Цитата(SM @ Apr 29 2013, 15:43) *
.....
Ну и аттрибут на схеме:
'Supply Rename' = 'VDD=1.8V VDDQ=1.8V VDDL=VDLL GNDQ=GND GNDDL=GND'

итого, все подключено куда мне надо без графики, и переподключить если что на "раз-два"

теперь понятны ваши слова, так и я делаю
НО как я писал выше при необходимости замены 'Supply Rename' = 'VDD=1.8V на 'Supply Rename' = 'VDD=1.8V-1 необходимо 39 раз ctrl-c - ctrl-v в DxD в каждом символе при наличие полного набора символов компанента при разбивке его на 40 символов.
или вы смогли автомотизировать данный процесс ?
SM
Цитата(Frederic @ Apr 29 2013, 17:21) *
или вы смогли автомотизировать данный процесс ?


Дык, ctrl-H и там вкладка "Replace", ну и кнопка "More" если опций не хватает.
Frederic
Цитата(SM @ Apr 29 2013, 17:23) *
Дык, ctrl-H и там вкладка "Replace", ну и кнопка "More" если опций не хватает.

да-с, как то я про поиск/замену Supply Rename не подумал
спас за выдержку и терпение biggrin.gif
vitan
Цитата(Frederic @ Apr 30 2013, 00:51) *
да-с, как то я про поиск/замену Supply Rename не подумал
спас за выдержку и терпение biggrin.gif

В особо сложных случаях можно использовать скрипты типа autohotkey или клавыиатуры/мышки с кнопками макросов. Или все вместе. sm.gif
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.