[vitan 2]

3. В показанных PDB распиновка делается всего один раз, только для одного символа - остальные пользуются той же таблицей автоматом. Т.е. я ввожу один раз вы 3.

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

 

- могу просто выбрать номера в списке слева (сразу все или группу) и скопом присвоить - перетащить слева направо.

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

 

Все, ну и где здесь двойная работа?

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

 

Не хотите так работать как мы, так продолжайте через нетлист, какие проблемы?

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

 

5. Опрос затеянный вами покажет только то, что большинство пользователей перешедших с DC\DV продолжают пользоваться тем же набором средств

какие у них были раньше и разбираться с дополнительными не будут - ибо проще работать так как привыкли ранее. Причем у них проблема противоположна вашей - все атрибуты внутри ЦБ и для них первоначальное создание БД является только дополнительной работой (все все атрибуты из ЦБ надо перетащить в БД).

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

 

Собственно говоря, проблема заключается только в том, что если бы кто-то заполнил им БД и на протяжении некоторого времени помог в работе с ней, то через некоторое время считали бы что без БД плохо.

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

 

vitan, плиз сделай видео желательно с голосом (минут 5....15) как у тебя протекает процесс

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

 

иначе вам с fill надо перенести беседу в другое место и с для полного взаимопонимания

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

[fill 2]

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

И при этом еще должны изменить имя файлика и т.д.

В рассмотренном варианте у нас: 3 символа и 17 PDB

У вас 51 символ и 51 файлик распиновки.

Т.е. у вас ЦБ пухнет на глазах, у нас остается компактной.

 

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

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

 

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

 

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

 

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

 

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

 

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

 

На предыдущей странице я уже приводил исчерпывающий список пунктов.

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

[vitan 2]

Т.е. у вас ЦБ пухнет на глазах, у нас остается компактной.

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

 

Запись в БД это список атрибутов, какая разница где их вводить в БД или PDB, если вводить все равно нужно?

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

 

На предыдущей странице я уже приводил исчерпывающий список пунктов.

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

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

Для Вас исходной и гланой является ЦБ, а для меня - БД. Видимо, из-за этого непонимание.

Спасибо, вопросов на эту тему больше не имею.

[SII 0]

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

 

Plow failed for net LCD_DCLK/TRACE3 on layer 4

 

 

Thru Pin ; X13-8; net LCD_HS/TRACE0; loc: (22.62, 5.54); class: (Default)

 

Minimum clearance required: 0.254mm

>>>> Routing Trace for net LCD_DCLK/TRACE3 on Layer 4; width 0.2mm >>>>

 

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

[fill 2]

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

 

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

 

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

 

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

 

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

Для Вас исходной и гланой является ЦБ, а для меня - БД. Видимо, из-за этого непонимание.

Спасибо, вопросов на эту тему больше не имею.

 

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

[Voyager 0]

попробуй попровести дорожку например GND от элемента до плейна GND через via

после этого зальется

 

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

[vitan 2]

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

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

 

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

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

 

 

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

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

 

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

[fill 2]

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

 

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

 

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

 

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

 

Итак, вернитесь назад посмотрите на рисунок и поймите что топологическому редактору нужно получить откуда-то:

1. нетлист

2. описание компонентов - PDBs

3. описание ячеек использованных в компонентах- cells

4. описание стеков площадок использованных в ячейках - padstacks

 

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

 

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

 

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

 

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

[vitan 2]

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

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

 

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

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

 

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

Да, сорри, пропустил слово "генерации". Согласен, это может быть решением проблемы. Более того, наверное, только это проблему и решит.

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

[SII 0]

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

 

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

 

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

Изменено 7 марта, 2012 пользователем SII

[fill 2]

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

 

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

 

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

 

А зачем вам вообще нужны данные типы пинов? И зачем вообще пины питания\земли вносить в логическую часть - т.е. в пины обычно присутствующие на символах схемы?

У вас же есть спец. закладка "Supply & NC" где можно просто ввести имя цепи и перечислить все ее номера пинов.

Тип пина нужен только для управления - кем станет данный пин в топологии соединений - Source, Load или Terminal - больше ни для чего.

[cioma 0]

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

 

А зачем вам вообще нужны данные типы пинов? И зачем вообще пины питания\земли вносить в логическую часть - т.е. в пины обычно присутствующие на символах схемы?

У вас же есть спец. закладка "Supply & NC" где можно просто ввести имя цепи и перечислить все ее номера пинов.

 

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

 

Тип пина нужен только для управления - кем станет данный пин в топологии соединений - Source, Load или Terminal - больше ни для чего.

 

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

[fill 2]

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

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

чтобы сформировать "сложновентильный" компонент без отрисовывания кучи символов, которые сами по себе использоваться не будут

Т.е. этих пинов на схеме все равно не будет.

 

[SII 0]

А зачем вам вообще нужны данные типы пинов? И зачем вообще пины питания\земли вносить в логическую часть - т.е. в пины обычно присутствующие на символах схемы?

 

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

 

У вас же есть спец. закладка "Supply & NC" где можно просто ввести имя цепи и перечислить все ее номера пинов.

Тип пина нужен только для управления - кем станет данный пин в топологии соединений - Source, Load или Terminal - больше ни для чего.

 

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

 

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

 

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

[SII 0]

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