Неужели? Я копирую файлик вместе с распиновкой (она внутри) и она точно так же по умолчанию повторяет исходную.


Пожалуй, единственное ускорение. Но и то - решаемо при обработке текста.


Как где? А создать запись в БД для данного компонента? А вести ее потом по жизни и проверять правильность введенных свойств. И, самое, главное, поддерживать соотвествие ЦБ и БД друг другу?


Я уже говорил. Я никого ни к чему не принуждаю. Я хочу понять, как мне в моей текущей ситуации безболезненно (т.е. без лишней траты времени на ЦБ) начать разводить в Exp.


Охотно верю. Более того, я сразу об этом сказал. Вот, Вы можете объяснить SII необходимость применения БД и ее преимущества? Ладно, представим, что я и есть SII, и про БД первый раз в жизни слышу.


Это чуть ли не главная мысль во всей дискуссии. Думаю, все дружно начинают поворачивать головы в сторону ментора... А в ответ - тишина...


Это для меня сложно, надо ставить рекордер, и куда-то выкладывать. У меня нет интернета на рабочем месте. Плюс, самое главное, непонятно, что снимать на видео. Как создаются символы? Ровно так же, как и при CDB. Только там на пинах надо расставить атрибуты "#", значения которых - это номера пинов в корпусе.


Пожалуй, Вы правы. Очевидно, этим путем пользуюсь я один, и это больше никому не интересно, кроме fill-а (и то не знаю, в какой мере).

И при этом еще должны изменить имя файлика и т.д.
В рассмотренном варианте у нас: 3 символа и 17 PDB
У вас 51 символ и 51 файлик распиновки.
Т.е. у вас ЦБ пухнет на глазах, у нас остается компактной.


Большинство пользователей как раз воротит от того что нужно, что-то где-то еще "допиливать".



Запись в БД это список атрибутов, какая разница где их вводить в БД или PDB, если вводить все равно нужно? Количество вводимых полей одинаково. Время введения тоже. Т.к имя Part Number как правило не изменяется в процессе работы, да и удаляют вряд ли, то что тут поддерживать, соответствие чего с чем?



Я уже расписал все возможные варианты. Начните работу и все.



На предыдущей странице я уже приводил исчерпывающий список пунктов.
Я сам долго работал без БД, и начал ей пользоваться только тогда когда потребовался более расширенный поиск по параметрам (простой и так есть в CL View), и основное - возможность подключить datasheet к компоненту чтобы щелчком мыши по символу компонента или строчке в DxDatabook вызывать файл с описанием компонента - надоело лазить по папкам в поиске документации компонентов.

У этого есть и обратная сторона. Я могу поправить УГО только для одного компонента, например, исправить ошибку, или улучшить вид, а вы - нет, будете править всё.


Правильный вопрос. Только Вы предлагаете вводить не "или-или", а "и". Об этом и речь.


Понятно. Для Вас БД - это просто некий расширитель функциональных возможностей САПР. Для меня - основное хранилище информации, на которое завязаны не только САПР, а много чего еще.
Для Вас исходной и гланой является ЦБ, а для меня - БД. Видимо, из-за этого непонимание.
Спасибо, вопросов на эту тему больше не имею.

Пытаюсь развести свою гениальнейшую схему (ручками). Размещение компонентов произвёл, в CES понастраивал ширины дорожек и интервалы между дорожками, контактными площадками и т.п. Однако при попытке разводки регулярно возникают ошибки с такими вот примерно сообщениями:



Мне непонятно, откуда Expedition берёт величину 0.254 мм. Дело в том, что я везде определил промежутки в 0,2 либо 0,4 мм. Последние -- на двух внутренних слоях, на которых только земля и питание, а разводки как таковой нет. Перерыл вроде всё, но так и не нашёл, в чём дело...

Смотря что вы собираетесь менять. Если графику, то логично предположить что изображение одинакового по функциям символа должно быть изменено во всех компонентах, но тогда как раз мы то в выигрыше, т.к. меняем в одном месте и исправляется везде. Тоже самое с именами пинов, если мы изменим имя (или номера) то ЦБ сразу это отследит и предложит что-то типа: "Символ применен в 17 PDB. Вы действительно хотите изменить тем самым все 17 PDB?" - если ответить да, то помимо самого символа изменится таблица в 17 PDB



Я уже устал повторять ИЛИ. Где вы видели И в моих ответах по данному поводу?



Ну так тогда вам надо говорить не о DxDatabook а о DMS - это абсолютно другой уровень работы с БД. И DxDatabook в данном варианте уже будет только неким дополнительным инструментом доступа к DMS.

Спасибо, все получилось.

Вы не находите, что именно эти примеры делаются в файлах путем простой замены всех файлов копированием поверх старых? Безо всяких ЦБ...


В ЦБ и в БД. Хотите сказать, что я могу просто добавить в БД (но не в ЦБ) и у меня все получится (в смысле отправить на разводку)?



Зачем это? Разве в этом случае Exp сможет обойтись без ЦБ? Разве я смогу выставить на схему компонент (хранящийся весь в DMS через DxDatabook) и отправить его в Exp без создания этой ЦБ? Или без ЦБ не получится, но она будет создана автоматом для данного проекта?

Я понимаю, что DxDatabook можно использовать для работы со схемой, компоненты для которой полностью лежат в DMS. На всякий случай говорю.

Я нахожу что вместо того чтобы просто нажать на кнопку Yes. Вы предлагаете сначала найти как-то все файлы где нужно провести замену. Затем или внести изменения внутри них, или заменить одним измененным с одновременным соответствующим изменение их имен - я понимаю что для скрипто писателя это реализуемо, но вот для простых пользователей "смерти подобно".



Идем по кругу, поэтому начнем отвечать последовательно, чтобы постепенно доходило:

Итак, вернитесь назад посмотрите на рисунок и поймите что топологическому редактору нужно получить откуда-то:
1. нетлист
2. описание компонентов - PDBs
3. описание ячеек использованных в компонентах- cells
4. описание стеков площадок использованных в ячейках - padstacks

Теперь сформулируйте что из этого вы получите из вашей БД через DxDatabook и как будете получать остальное.



Я уже говорил ранее, В DMS есть функция генерации "Производственных библиотек", т.е. ЦБ которые можно сформировать хоть под каждый проект.

Можно обойтись и просто хорошим файловым менеджером. Лично мне еще пока ни одного скрипта не потребовалось написать.


Давайте прекратим. Я не вижу способа совсем избавиться от ведения ЦБ при работе с CDB. Вы его тоже не говорите.


Да, сорри, пропустил слово "генерации". Согласен, это может быть решением проблемы. Более того, наверное, только это проблему и решит.
В принципе, если уж эти production library так нужны для Exp, то можно их и генерить. Главное, чтобы это делалось автоматически и никто не тратил времени на создание и ведение этих ЦБ. Ну а зачем нужна такая ЦБ (которую никто из людей не открывает), видимо, так и останется тайной...

Обратил внимание на такую деталь. Если компонент (Part) создаётся из символа и посадочного места, причём из первого извлекается информация о "вентилях" (Gate), то ноги земли и питания получают атрибуты типа соответственно Power и Ground. Однако, если формировать эти самые "вентили" вручную (например, чтобы сформировать "сложновентильный" компонент без отрисовывания кучи символов, которые сами по себе использоваться не будут), то выставить такие типы ног невозможно: имеются входы, выходы и всякие прочие, но никак не земля-питание. С чем это связано и можно ли как-то обойти, кроме как рисовать символы и брать информацию о "вентилях" из них?

ADD. Мне удалось обойти эту проблему следующим способом. Рисую нормальный символ (какой будет использоваться на схемах), посадочное место, создаю компонент. После этого удаляю "вентиль", содержащий логические ноги, и оставляю только "вентили", содержащие питание и землю, после чего уже вручную создаю новые "логические вентили", заполняю их ногами и т.д.

Тем не менее, остаётся в силе вопрос: а возможно ли прямо в Part Editor'е указывать для ног типы Power и Ground?

Сообщение отредактировал SII - Mar 7 2012, 03:25

А зачем вам вообще нужны данные типы пинов? И зачем вообще пины питания\земли вносить в логическую часть - т.е. в пины обычно присутствующие на символах схемы?
У вас же есть спец. закладка "Supply & NC" где можно просто ввести имя цепи и перечислить все ее номера пинов.
Тип пина нужен только для управления - кем станет данный пин в топологии соединений - Source, Load или Terminal - больше ни для чего.

Сначала надо разобраться что на самом деле означают эти типы Power и Ground. Есть подозрение, что они используются только в проверках ERC и только в специфических случаях (FPGA? IOD?). Появились эти типы недавно, и, например, я их не использую.



Многие инженеры, включая меня, предпочитают видеть все пины на схеме (explicit). Если что-то скрыто (implicit), то может быть весьма неудобно при отладке. Так что оба варианта имеют право на существование.



Согласен. Ну еще и для некоторых проверок ERC (ViewDRC), хотя для меня они вторичны.

Не внимательно читаете исходный вопрос :
Т.е. этих пинов на схеме все равно не будет.

Ну, они почти всегда бывают на символах аналоговых микросхем. Кроме того, сейчас многие цифровые МС работают при сильно разных напряжениях, и фиксировать лишь одно из них не хочется. А вариант с указанием VCC может не пойти, если используются схемы с разными напряжениями, каждое из которых формируется своим источником. В общем, хотя в основной логической части им делать нечего, зачастую всё ж нужно их отображать. (Хотя питания с фиксированным напряжением, например, 3,3 В, я прячу: нечего загромождать схему, если нет реальной нужды).



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

В общем, как понимаю, эти типы реально мне не нужны, и в будущем проблем не предвидится? В т.ч. с использованием всяких там симуляций, анализа целостности сигналов и прочая? (В обозримом будущем всем этим пользоваться ещё не буду, но процесс же идёт ).

Кстати, такой вопросик. А можно ли в символе формировать скрытые выводы? Т.е. в файле символа они есть, но не отображаются? Мне бы они были полезны для того, чтобы одному и тому же посадочному месту (конкретно -- 9-контактным разъёмам D-Sub) можно было сопоставить разные символы с разным числом видимых выводов (полный RS-232, сокращённый RS-232, RS-485, CAN, просто 9-контактный разъём). Делать разные компоненты, ИМХО, не слишком хорошо, ведь в списке комплектующих (BOM) указываются подлежащие заказу Part Number, а для всех этих случаев реально надо приобретать одно и то же, меняется лишь логическое назначение...

Закончил, наконец, разводку платы (интересно, она хотя бы частично работать будет? ) ). Но тут внезапно появился ещё один вопрос. Где-то то ли слышал, то ли читал, что для машинной сборки надо размещать на плате реперные точки. Вот хотелось бы узнать, во-первых, что они из себя должны представлять (просто кружочки металла или ещё что), во-вторых, куда и сколько их ставить (вроде бы три-четыре по краям, причём несимметрично, а также по паре у каждой крупной микросхемы, особенно BGA), а в-третьих, как их надо оформлять в Expedition?