[fill 2]

Ах, вот оно что! Теперь все понятно. Кстати, не находите, что чересчур громкое название для компонента? :)

 

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

 

 

Я все понял, кроме этой фразы. Что же, без полноценной ЦБ при прямой аннотации компоненты, ячейки и падстеки не считываются? Т.е. Local PDB формируется на основе этих внешних файлов, а не напрямую их ЦБ? И чем это так не удобно? Тем, что в файлах проперти все не прописаны? Так мы же их из DxDataBook берем!

 

Опять вы ничего не поняли:

1. PDB+набор атрибутов это тот же компонент который вы получаете в случае DxDatabook. Просто у вас атрибуты хранятся в сторонней базе, а у большинства внутри компонента (PDB).

 

2. Полноценной подразумевает наличие этих элементов (PDBs, cells, padstacks) внутри ЦБ. Тогда они и считываются напрямую из ЦБ при прямой аннотации. Если же их нет в ЦБ то откуда должна программа аннотации их импортировать? Только из неких сторонних файлов (о которых я и упомянул). Причем делать это придется вручную через функцию импорта внешних данных, при этом загрузите кучу не нужного для этого конкретного проекта мусора или придется долго точно выбирать при импорте, какие конкретно нужны PDBs, cells, padstacks для импорта.

[vitan 2]

Хорошо, спрошу иначе.

Вот, человек работает с ЦБ и не понимает, зачем нужна БД:

Зачем реально нужна ODBC-база, если все данные по компонентам хранятся в ЦБ?

Непонимание логично, т.к. Вы сами говорите, что:

DxD-iCDB-Exp:

Весь набор PDB в ЦБ. Упаковщик использует один единственный атрибут (Part Number) для поиска нужного PDB в ЦБ и считывания из него всей информации об упаковке и доп. атрибутах. И загружает эту информацию на схему (номера пинов + доп. атрибуты).

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

 

С другой стороны я работаю через нетлист.

Вы говорите:

DxD-netlist-Exp:

Набора PDB нет в ЦБ. Т.к. файл со всеми нужными PDB создается упаковщиком из схемы и затем загружается в плату (в локальную библиотеку).

Неудобство: нужно всю упаковочную информацию с помощью набора атрибутов прописать на символах схемы.

Отлично, пусть упаковщик занимается упаковкой, а кусаю локти, понимая, что я упускаю удобный механизм работы.

 

Но затем Вы говорите:

В случае iCDB имеем два возможных варианта:

а) атрибуты внутри PDB.

б) атрибуты в сторонней базе данных.

Я думаю: отлично! У меня уже есть сторонняя БД, использую-ка я ее! Оказывается, что нужна еще и ЦБ, т.к. без неё Exp не работает.

 

Вот и получается: у кого нет БД, используют ЦБ. У кого есть БД, вынуждены вести еще и ЦБ. Зачем? Ведь Вы же сами сказали:

DxD-netlist-Exp:

Набора PDB нет в ЦБ. Т.к. файл со всеми нужными PDB создается упаковщиком из схемы и затем загружается в плату (в локальную библиотеку).

Если его нет в ЦБ и все создается само в Local PDB, зачем тогда ЦБ??? Чтобы Exp заработал? Замкнутый круг. :)

 

 

В конце концов, давайте спросим народ. Кто-нибудь работает одновременно с БД и ЦБ? В чем смысл и реальные плюсы такой работы? Какие параметры компонентов Вы храните в БД, а какие в ЦБ? Почему именно так?

[fill 2]

Еще раз повторяю:.

БД нужна только для того чтобы

- искать\проверять значения атрибутов на схеме

- подключать к компонентам datasheets

- не вводить атрибуты в PDB, а вводить их в БД (что удобнее)

- сформировать глобальную БД в рамках предприятия - т.е. ей будут пользоваться не только разработчики схем

 

Если ничего из перечисленного не надо, то она не нужна.

 

Если его нет в ЦБ и все создается само в Local PDB, зачем тогда ЦБ??? Чтобы Exp заработал? Замкнутый круг.

 

Да не все создается. Создается только PDB, а PDB не содержи в себе никакой графической информации, там только ссылки на используемые символ(ы) и ячейку(и).

[vitan 2]

- не вводить атрибуты в PDB, а вводить их в БД (что удобнее)

Уточните. Я могу вообще не открывать ЦБ, PDB, iCDB (и прочие бэ :) ), а брать и вводить атрибуты прямо в БД, что, действительно удобнее, особенно, когда есть клиент, а не таблица аксесса, прилинкованная к той же ЦБ?

Вряд ли! Иначе уже давно бы так делали. И никакого синхронизатора не надо было бы, т.к. не было бы самой ЦБ.

Т.е. ЦБ нужна. Скажите, пожалуйста, зачем?

[fill 2]

Уточните. Я могу вообще не открывать ЦБ, PDB, iCDB (и прочие бэ :) ), а брать и вводить атрибуты прямо в БД, что, действительно удобнее, особенно, когда есть клиент, а не таблица аксесса, прилинкованная к той же ЦБ?

Вряд ли! Иначе уже давно бы так делали. И никакого синхронизатора не надо было бы, т.к. не было бы самой ЦБ.

Т.е. ЦБ нужна. Скажите, пожалуйста, зачем?

 

Где по вашему хранится информация о графике посадочных мест, падстеков?

[vitan 2]

Да не все создается. Создается только PDB, а PDB не содержи в себе никакой графической информации, там только ссылки на используемые символ(ы) и ячейку(и).

НУ!!! Я же этого и хочу, пусть так и будет. Только где здесь место для ЦБ?!

 

Где по вашему хранится информация о графике посадочных мест, падстеков?

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

 

Думаю, что просто так исторически сложилось. Но это имхо - одна из серьезных проблем. Почему - потому что это двойная работа, осложненная отсутствием синхронизации.

[fill 2]

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

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

В ЦБ это все автоматически отслеживается.

Открыв ЦБ в LM я сразу вижу всю структуру данной ЦБ, сколько и каких разделов, сколько в каждом разделе элементов, как эти элементы связаны с другими элементами, сразу могу открыть их на редактирование в соответствующем редакторе и т.д. У меня может быть несколько ЦБ с разным содержанием и разными правилами.

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

[vitan 2]

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

Элементарно! Если мы используем БД для компонентов, то никаких проблем использовать ее же для падстеков и прочего. Причем, само хранение можно организовать либо в файлах на диске, либо в файлах, закачанных внутрь СУБД (т.н. BLOB). Кстати, тот же ментор спокойно делает это в DMS.

 

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

В ЦБ это все автоматически отслеживается.

Вы говорите о целостности данных. В любой СУБД это понятие гораздо более развито, чем в этой несчастной ЦБ. По сути, ЦБ в этом смысле и есть СУБД с сильно урезанной функциональностью. Поэтому снова тот же вопрос, но по-другому: зачем одновременно использовать две ипостаси одного и того же? Ладно бы сказали: либо ЦБ, либо СУБД (своя или DMS, не важно). Но нет, прикрутили дополнительно к ЦБ еще и СУБД и заставляют делать двойную работу, мотивируя удобством!

 

Вот, захочу я, допустим, использовать все мнимые преимущества CDB. И что же мне теперь заново создавать и вести всю ЦБ на тысячу компонентов? Вся информация для упаковки у меня уже есть, проектов куча разработано по старой технологии...

 

Я изменяю имя пина на символе\ячейке, а может это приведет к конфликту, т.к. этот символ\ячейка применен в других компонентах?

Да более того!

Вы говорите, что при упаковке создается эта Local PDB. Т.е. она есть принадлежность проекта. Вопрос: зачем беспокоиться о конфликтах и о том, что что-то будет удалено снаружи, кога упаковка уже прошла и мы спокойно разводим?

Я с аллегро работаю ровно так же: перед началом трассировки подгружается нетлист и компоненты (из файлов на диске, ессно). Как только они попадают в плату, они там сохраняются, и аллегро уже не шарится по библиотекам в поисках. Это логично и нормально, так работают многие программы. Exp не исключение, очевидно (т.к. есть Local PDB). Кэширование сильно облегчает жизнь, это ясно всем.

Так вот: я могу спокойно поменять в библиотеке все, что хочу, и связи в т.ч., но в моем текущем проекте все останется как было. И только, если захочу, нажму "обновить".

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

[fill 2]

Элементарно! Если мы используем БД для компонентов, то никаких проблем использовать ее же для падстеков и прочего. Причем, само хранение можно организовать либо в файлах на диске, либо в файлах, закачанных внутрь СУБД (т.н. BLOB). Кстати, тот же ментор спокойно делает это в DMS.

 

 

Вы говорите о целостности данных. В любой СУБД это понятие гораздо более развито, чем в этой несчастной ЦБ. По сути, ЦБ в этом смысле и есть СУБД с сильно урезанной функциональностью. Поэтому снова тот же вопрос, но по-другому: зачем одновременно использовать две ипостаси одного и того же? Ладно бы сказали: либо ЦБ, либо СУБД (своя или DMS, не важно). Но нет, прикрутили дополнительно к ЦБ еще и СУБД и заставляют делать двойную работу, мотивируя удобством!

 

Вот, захочу я, допустим, использовать все мнимые преимущества CDB. И что же мне теперь заново создавать и вести всю ЦБ на тысячу компонентов? Вся информация для упаковки у меня уже есть...

 

 

1. И при этом в DMS есть понятие Production Library - т.е. из DMS генерируется ЦБ которая и подключается к Exp.

2. В вашем случает проще остаться работать через нетлист.

Хотя внести PDB в ЦБ тоже не проблема, достаточно импортировать генерированный при упаковке (в варианте нетлиста) файл PDB.hkp в ЦБ. И получится что эти компоненты внесены в ЦБ (второй раз этого делать уже не надо). Ну а создавать посадочные места и падстеки в любом случае надо в ЦБ.

Зато при работе через CDB вам не придется на каждый новый символ\компонент добавлять:

DEVICE (Part Number)

#

PARTS

SIGNAL

PINSWAP

PKG_TYPE

HETERO

HETERO_SYMNAME

 

3. Вот вам простой пример, вы работаете на плате, в это время некий Вася взял и изменил номера выводов на одном из посадочных мест в общей библиотеке. При очередном изменении проекта у вас начнутся проблемы, т.к. номера обновленного посадочного места не будут совпадать с тем что вы прописали ранее.

[vitan 2]

1. И при этом в DMS есть понятие Production Library - т.е. из DMS генерируется ЦБ которая и подключается к Exp.

Это лишний раз доказывает, что просто так исторически сложилось. И хорошо, что здесь эта ЦБ генерится, а не руками ее надо создавать. Иначе люди бы уже совсем не поняли... :)

 

2. В вашем случает проще остаться работать через нетлист.

Нет уж, погодите! :) Получается, что для меня все преимущества iCDB перекрываются проблемой ведения ЦБ? Всё, тупик? :)

 

Хотя внести PDB в ЦБ тоже не проблема, достаточно импортировать генерированный при упаковке (в варианте нетлиста) файл PDB.hkp в ЦБ. И получится что эти компоненты внесены в ЦБ (второй раз этого делать уже не надо).

О, да! Только этот процесс займет еще три дня, а толку ноль: у меня и раньше было все, чтобы упаковаться и начать разводить.

 

Ну а создавать посадочные места и падстеки в любом случае надо в ЦБ.

Вы так и не ответили, почему так сделано? Почему Exp не читает непосредственно из файлов, как аллегро?

 

Зато при работе через CDB вам не придется на каждый новый символ\компонент добавлять:

DEVICE (Part Number)

#

PARTS

SIGNAL

PINSWAP

PKG_TYPE

HETERO

HETERO_SYMNAME

Да ну? А что же придется? Наматывать мышкой километры, нажимая кнопки в окошках, и вводя туда ту же информацию.

Ой, не факт, что это мне больше понравится!

[fill 2]

Вы так и не ответили, почему так сделано? Почему Exp не читает непосредственно из файлов, как аллегро?

 

Потому что считать\исправить одну ссылку гораздо проще чем сотню.

[vitan 2]

Потому что считать\исправить одну ссылку гораздо проще чем сотню.

Понятно. Вы, наверно, думаете, что, если я в аллегро поправил падстек, то мне надо шариться по всем файлам футпринтов, и вручную чего-то обновлять? Смею заверить, это не так.

В общем, все как я и думал.

Просто так вышло. Точнее, просто плохо подумали. :(

[AlexN 0]

нехило зацепили филла

лучше сначала немного доки почитать, самому попробовать, это не так сложно...

а то даже в терминах нет взаимопонимания.

 

если вам нужны только cell - ну заведите ЦБ c только cell/

абстракции можете считать, что ЦБ - это просто удобный каталог для хранения. Ну или просто оболочка для менеджирования.

гораздо удобнее простого файлового менеджера.

Там нет ничего такого кардинально лишнего, что уменьшало бы производительность труда.

 

 

[Frederic 0]

нехило зацепили филла

лучше сначала немного доки почитать, самому попробовать, это не так сложно...

а то даже в терминах нет взаимопонимания.

:bb-offtopic:

нееее, fill само спокойствие :)

 

[vitan 2]

лучше сначала немного доки почитать, самому попробовать, это не так сложно...

а то даже в терминах нет взаимопонимания.

Хм. По существу что-то можете сказать?

 

если вам нужны только cell - ну заведите ЦБ c только cell/

абстракции можете считать, что ЦБ - это просто удобный каталог для хранения. Ну или просто оболочка для менеджирования.

гораздо удобнее простого файлового менеджера.

Там нет ничего такого кардинально лишнего, что уменьшало бы производительность труда.

В том и дело, что могу, но не хочу. Понимаете, можно до бесконечности наворачивать уровни абстракции, лишь бы от этого была польза. Уже третий день пошел, а никто из прочитавших доки, в т.ч. и Сам :) fill так и не смог мне внятно ответить на простой вопрос: ЗАЧЕМ НУЖНА ЦБ? Особенно при работе с БД.

 

Ответы типа, чтобы хранить, связывать и т.п. мы уже обсудили. Считаю свои аргументы правыми просто за отсутствием иных.

Кстати, недавано в разделе про PADS был подобный разговор. Там тоже никому не удалось понять это. Только там, к счастью, оппоненты и сами все признали.