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

Поэтому есть такой концептуальный вопрос: что такое Cell?
Подскажите аналогию понятия Cell на примере моих библиотек. Сейчас у меня однотипные компоненты сгруппированы в бибилиотеки. Например, есть библиотека постоянных резисторов. Внутри нее лежат сами резисторы. Очевидно, выбор конкретного резистора в кейденсе делается из файла .ptf. При этом логично было бы понимать под Cell все резисторы в данной библиотеке.
Тем не менее, в примерах деление немного другое. Есть библиотека Discrete, внутри нее Cell-ы из резисторов и конденсаторов, ну а далее уже конкретный компонент, опсисанный в PTF. Получается, что Library - это просто некий доп. уровень группировки Cell-oв (компонентов).
Какая аналогия более правильная?

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

Cell - это просто одна библиотечная ячейка. Чем вы ее наполните - Ваше дело. Ограничения там больше идеологические, нежели программные.
Самый простой случай - одна ячейка - один элемент. Тот же резистор. Далее, внутри ячейки, возможны варианты: разные символы для резисторов(вертикальный/горизонтальный/ГОСТовский/НАТОвский, с одним-другим-третьим набором видимых атрибутов, резистор из сборки, для ГОСТовских резисторов можно графику разной мощности предусмотреть и так далее).
Далее - возможны разные упаковки, т.е. таблицы соответствия вывод символа - пин футпринта.
И сверху ко всему этому цирку PTF - таблица, в которой просто перечислены атрибуты, которые будут присвоены символу при его установке на схеме(а соответственно и компоненту в упаковке(package) при передаче на плату и генерации разной информации из этой схемы).

Поля перед знаком равно - это поля, которые попадут на схему и могут быть отображены, в терминологии кэйденс "ключевые атрибуты"(KEY PROPERTIES). Эти атрибуты обязаны быть предусмотрены в символе/символах, видимые или невидимые, в каких местах - не важно, но быть обязаны. Иначе будет ошибка при попытке установки такого символа на схему.
Атрибуты после знака равно(INJECTED PROPERTIES) на схеме не видны, никак. Они добавляются только при упаковке схемы, могут быть втянуты в РСВ(а можно их и проигнорить) и из упаковки можно генерить всякие рапорты с этими атрибутами.

А вот повтор атрибутов, насколько помню, связан с тем, что исторически они были разделены более жестко: KEY - только для схемы, INJECTED - только для упаковки и платы. Хотите видеть один и тот же атрибут и там и там - повторите описание дважды. Сейчас кажется упаковщик KEY-атрибуты включает в упаковку по умолчанию. Но не уверен, не проверял, а либы уже все созданы с повтором по обе стороны.

Мда... А как у Вас? Один целл на все резисторы, или один либ на все резисторы?



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

У меня все-таки два целла на резисторы - один на одиночные, второй на сборки. Хотя можно было и в один все собрать, но тут мы с коллегами не договорились...
Хотя разъемы например созданы иначе - там в одной целл собраны разъемы по сериям, т.е. если это 2-рядные штыри с шагом 2.54мм высотой 11мм - то все размерности(от 4-х до 80-ти пинов) заданы в этой одной целл. Просто все такие разъемы имеют общий "корень" Part_Number-a и их удобно обслуживать в рамках одной целл. Пришлось подумать, как это можно реализовать.

В одной строке атрибуты конечно одинаковые. Ну а зачем мне на схеме видеть одно значение, а в упаковку чтобы шло другое? На схеме 50В конденсатор будет, а на плате 16? А кто ответит, когда он сгорит?
На самом деле они наверное могут быть разными, в конце концов это просто значения атрибутов, но смысла в этом не вижу, разве что какие-нибудь внутренние атрибуты, не имеющие отношения к параметрам компонента.

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


Да, примерно так же и у меня... Надеюсь, переход будет не слишком геморным...


Так а почему Вы не хотите одним движением текстового редактора удалить ненужные атрибуты? Они же загромождают все... Привыкли уже?

Я не понимаю, что такое иерархия библиотек и зачем она там нужна.Если это некое деление, то у меня оно ОЧЕНЬ простое:
- разъемы
- микросхемы
- разное(переключатели-кнопки, всякие фильтры, кварцы-осцилляторы, трансформаторы-связанные катушки и т.п. Плюс куча компонентов, которые используются в конструкции, но при этом не имеют ни одного пина, а просто должны попасть в ВОМ)
- пассив
- полупроводники
- экраны
- стандард(рамки, порты, питание-земля, точка привязки и т.п.)
Более мелкая структура была признана нецелесообразной.
Но если хочется, то существует такая вещь как файлы категорий. Вот там можно наделать любую иерархию. При этом целл будут лежать линейно, в одном каталоге, а ходить по ним можно будет как по структуре. Смотрите в хэлпе "Category Files (.cat files)".



А какие именно атрибуты Вы называете ненужными? Повторяющиеся в разделе INJECTED?
Если да, то я просто не проверял, будет ли полностью вся инфа передаваться в package, включая KEY PROPERTIES.
Да и не загромождают они на самом деле ничего, все равно 99% поиска делается именно по KEY атрибутам, а что там дальше, в хвосте таблицы редко и смотрится.

Да, я видел, хотел как раз спросить про них. Но Вы их, видимо, не используете?
У меня просто как раз все наоборот, библиотек около 60 штук, и они требуют некоторого управления при таком количестве...



Ну да, injected. Придется проверять, мне не нравится такое повторение. Интересно, что делать, если без повторения не получится?

Не использую. Пробовал, получалось, но глубокого смысла не увидел.
60 библиотек... ну можно конечно и еще сильнее раздробить. Вопрос зачем остается. Хотя каждый придумывает себе свои проблемы



Если не получится - то таки повторять.

Простой вопрос: как переименовать cell?

Открыть в Part Developer и сохранить с другим именем.

Ммм... А если просто переименовать папочку, то ничего там внутри страшного не произойдет? Я попробовал, написало, что там какое-то свойство (Body_name, что ли?) не соответствует, но оно будет исправлено при следующем сохранении. Оно таки исправилось, и все работает, но вопрос, не сломается ли при этом что-нибудь еще? Просто не очень как-то удобно открывать и пересохранять, вроде... Потом же надо будет удалять старые папочки... А если они там где-нибудь используются еще?....
Короче, это штатный механизм с пересохранением?

Для меня - штатный. Особенно учитывая, что сохранение с новым именем обновляет это имя во всех местах cell, включая названия Primitive, Pack_Type, PTF-файла и PART-a в нем.
Переименование только папки меняет только Body_Name и то, только при последующем открытии cell в Part Developer. Т.е. пользоваться cell в схематике сразу после изменения названия нельзя.

Спасибо, я так примерно и подозревал...
А вот еще вопрос.
При создании package можно указывать какие-то Logical parts и physical parts. Что это такое, никак не могу понять?
Чему в реальной жизни оно соотвествует?
Я правильно понимаю, что package - это корпус?

Я сейчас пытаюсь создать целл с резистором. Я хочу, чтобы было одно УГО на резистор (точнее, пока два - одно вертикальное, второе горизонтальное) и каждому резистору назначался свой футпринт.
Я правильно понимаю, что мне надо создать целл "resistor", в нем кучу package (по числу корпусов применяемых резисторов) и потом в этих package указывать футпритны (и альтернативные футпринты при наличии)? Какую роль в этом процессе тогда играют эти странные Logical parts и Physical parts?

Нет, для такого резистора можно/нужно использовать свойство JEDEC_TYPE в part_table. При этом можно не указывать footpints вообще, его замещает jedec_type.
Хотя, кажется, можно сделать и так предлагаете вы, но нужно много манипуляций делать.

До part_table я пока не дошел.
Как я понял, это не обязательно, поэтому я решил изучать постепенно. Я планировал, что создам некую упаковываемую конструкцию из УГО и футпринтов, а потом буду навешивать на нее дополнительные атрибуты из part table.
Но Вы говорите, что можно и значения футпринта брать оттуда же. Я правильно понимаю, что они в данном случае будут иметь приоритет перед тем значением JEDEC_TYPE, которое указано в Logical parts и physical parts?
И что это все-таки такое?