Вопрос по структуре библиотеки, Описание внутри Опции

[xCooLLer]

Такая ситуация.
На данный момент имеется библиотека РЭ, построенная следующим образом - разбита по фирмам-производителям, и в каждой папке лежат библиотечные компоненты. пример analog_device\ad8042\
в cds.lib прописано следующее: Define "имя фирмы" "путь"

Собственно вопрос.
Рассматриваю вариант "функция-фирма-компоненты"
Т.е. Первый уровень - папки с названиями функций (Diodes, Transistors, Microschemes и т.п.)
Второй уровень - подпапки с фирмами (Microschemes\Russians, Microschemes\Analog_device и т.п.)
Третий уровень - собственно компоненты (полный путь - Microschemes\analog_device\ad8042\"а здесь папки компонента - chips,entity,sym_1" )
Т.е. в схемном редакторе сначала выбрать функцию,далее фирму, и только потом компонент, который уже располагаю на схеме.
Как это можно реализовать?

Прописываю в cds.lib первом уровне - define "функция" "путь",
однако в схемном редакторе нет возможности просматривать подпапки.
Если создать файл cds.lib на втором уровне - не вариант, впоследствии компоненты будут в одной куче.

[Hoodwin]

а зачем вообще так сложно?

[xCooLLer]

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

[Hoodwin]

Так это ж сколько труда надо, чтобы наполнить библиотеки такие? Нереально почти. Если еще учесть, что со временем меняется понимание, как правильно оформлять библиотечные данные.

Кроме того, есть довольно много компонентов, на которые распространяются отраслевые стандарты. например, резисторы 0603 могут изготавливаться десятком разных фирм. Предлагается их закапывать в три уровня и многократно копировать одни и те же УГО и футпринты? Другой (более сложный) пример - оперативная динамическая память. Стандарты JEDEC определяют формы и размеры корпусов, а также распиновку. А делают такие микросхемы десятки фирм. А символы все одинаковые.

Даже операционник, приведенный Вами, не блещет какими-то уникальными особенностями по части УГО и футпринта. Все эти особенности нужны скорее для BOM, нежели для проектирования ПП.

[Uree]

Почитайте внимательней об организации библиотек - это первое.
Почитайте о категориях - это второе.
А потом скомбинируйте это все с помощью атрибутов.

Хотя подход напрочь неудобный. Сколько фирм - столько транзисторов, каждый с папкой символа, пинов и т.п. Полгода - и вы утонете в тысячах файлов(не забываем, один компонент - это минимум пять подкаталогов и полтора десятка файлов).

[xCooLLer]

to Uree
Возможно и неудобный,но если такая возможность вообще?
ЧТож,остается только внимательней читать..

to Hoodwin
Футпринты и padstacks хранятся в отдельной папке, их имена уникальные

Похоже,что плохая идея

[Uree]

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

[vitan]

Вы ведь используте Concept?
А не хотите использовать CIS?
В этом случае компоненты будут в базе, которую можно будет структурировать любым способом, в т.ч. и тем, которым Вы хотите. Вот, для примера, моя структура на картинках. И там нет никаких тысяч файлов.
А с Concept-ом я выхода не вижу...

[xCooLLer]

Вы ведь используте Concept?
А не хотите использовать CIS?
В этом случае компоненты будут в базе, которую можно будет структурировать любым способом, в т.ч. и тем, которым Вы хотите. Вот, для примера, моя структура на картинках. И там нет никаких тысяч файлов.
А с Concept-ом я выхода не вижу...

Да,Concept.
CIS в моем случае врядли получится использовать.
Посмотрел ваши скриншоты, очень интересный вариант

[Uree]

На самом деле за мелкими отличиями функциональность CIS/HDL идентична.

[vitan]

На самом деле за мелкими отличиями функциональность CIS/HDL идентична.

Я бы с удовольствием тоже рисовал в Concept, но без базы данных жизни не представляю.
Давно не смотрел на Concept, последний раз, когда его видел, базы там не было. Это уже не так?

[Uree]

Ее там и нет. Нам пока возможностей конфигурации с помощью PTF-файлов хватает.

ЗЫ О, нашел Vitan, раз Вы используете базу в связке со схематиком CIS, расскажите насколько хватит времени/терпения, что, где и в каком виде там должно быть. Что в библиотеках должно быть и как лучше их разделить. Как Вы пользуетесь БД и как она у Вас организована. А то я идею вроде бы понял, но концепция в голове еще не улеглась и как правильно организовать систему библиотека-БД еще не уверен. А времени чтобы попробовать варианты как обычно...

[vitan]

Ее там и нет.

Понятно, я так и думал.

ЗЫ О, нашел Vitan, раз Вы используете базу в связке со схематиком CIS, расскажите насколько хватит времени/терпения, что, где и в каком виде там должно быть.

Ну, я в данный момент для схем юзаю все-таки не CIS, а ментор, но это ничего не меняет.
В принципе, довольно подробно я свои идеи излагал в том топике, где я показал картинки.
Лично у меня ушло какое-то время на упорядочивание всего этого и понимание, чего именно мне надо. Около двух недель, наверное. Результат на картинке.

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

[Hoodwin]

Интересно, а в каком виде база? У меня до сих пор библиотеки лежат в виде файлов, которые кладутся в perforce. Собственно, упорядочены они а) по функционалу для совместимых компонентов, применяемых по типономиналу и б) по названию фирмы-изготовителя. Аналогично упорядочены футпринты. Благодаря наличию системы контроля версий можно оперативно разворачивать базу на новом рабочем месте, а также в случае чего из архива доставать более древние экземпляры библиотек или проектов. Сейчас вот очень достает отличие форматов 16.2 и 16.3, очень муторно сохранять в 16.3 файлы в старом формате 16.2, особенно для футпринтов. Сделаешь, DRA в 16.2, так обязательно потом окажется, что psm в 16.3 остался, или padstack-и от него. Но в целом, процесс идет.

[vitan]

Интересно, а в каком виде база?

База под MS SQ LSERVER 2005.
Библиотеки УГО и футпринтов имеют плоскую структуру. УГО делятся на папки по префиксам рефдесов, футпринты - по первым буквам имени IPC7351. Библиотеки под CVS.