Решил-таки освоить новый "фронтенд" для 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?
И что это все-таки такое?

Не совсем так... там не приоритет работает, а ключевые свойства в part_table. При упаковке по ним должен однозначно определиться корпус компонента. Насколько я понимаю тот Jedec type, который указывается в Logical & physical parts, это некое свойство по умолчанию используемое, если в part_table не указан конкретный jedec_type.



Посмотрите документы Part Developer Tutorial, Part Developer User Guide, Part Developer FAQ.

Logical parts - грубо говоря компонент, в PTF-e будет описан как PART. В одной cell может быть не один Logical part. Например можете попробовать в одну целл запихнуть резистор и конденсатор. В итоге получите две Logical parts.
Physical parts - привязка логического к корпусу посредством таблицы маппинга пинов. Таблиц маппинга тоже может быть несколько для каждой Logical part.

Смысла создавать разные Physical Parts для компонентов, которые отличаются только корпусом, но имеют то же кол-во пинов и одинаковый их маппинг - нет никакого. Это делается проще:

Нажмите для просмотра прикрепленного файла

Нажмите для просмотра прикрепленного файла

В одной Physical Parts(фактически - таблице маппинга пинов) прописывается несколько названий упаковки. На соответствующее название указывает атрибут PACK_TYPE из PTF-файла, и там же, в PTF, для каждого Part_Number указан свой JEDEC_TYPE.

Ну то бишь приоритет? Все-таки же написано, что "can be overriden"...


Бррр....
Голова пухнет.
Я понял следующее.
Logical part - схемный компонент. Т.е. по ГОСТу - элемент схемы. Так? Он может быть нарисован одним или несколькими УГО. Таких компонентов может быть несколько в пределах целла, как мы выяснили ранее, целл - просто некий доп. уровень абстракции, позволяющий лучше манипулировать данными. Правильно?
Physical part - варианты упаковки схемного компонента. Сохраняются в файл chips.prt. Да?
Part table помогает дополнять logical part-ы значениями из таблицы. Так? При этом можно указывать и значение футпринта, чтобы иметь возможность им управлять из этой таблицы, и каждый раз не трогать опрпделение logical part через part developer. Так?


Хорошо, таким образом, PACK_TYPE в файле PTF примеяняется на этапе выбора logical part, и как только он появился на схемном компоненте, он начинает связывать своим значением схемный компонент с вариантом упаковки? Так? А потом уже, т.е. только после этого из варианта упаковки выбирается футпринт? Правильно?

И что такое PART_NUMBER?
---
PS. Жесть...

Как-то где-то так... Если писать подробнее, то получится полный хэлп + туториал. В общем немного шире формата форума
Вы главное пробуйте, оно так лучше получается понять, что происходит.
А PTF я бы не оставлял на потом - это же прямая замена БД в других системах, без него все становится немного бессмысленным...

Дык я собссно на форум и вылез, ибо хелпы с туториалами не помогают...


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

А PART_NUMBER - что это?
Я могу его использовать в PTF для указания названия компонента? Т.е. будет ли он потом отображаться при построении бома? Это его штатное назначение?
Если нет, то какое свойство соответствует названию компонента в боме? Просто в хелпе все это туманно как-то...


Специально попробовал создать компонент, у которого в part table не указан JEDEC_TYPE, но указан PACK_TYPE. Думал, что значение футпринта должно взяться из physical part, прописал его туда... Нифига! При просмотре браузером компонентов говорит, что футпринт не определен. Работает только, если принудительно прописать в PTF значение JEDEC_TYPE. Не понимаю, почему и зачем???

Выходит, что это мое предположение

неправильное?

Да, действительно не показывает корпус при выборе компонента в схематике. Не знаю почему, я без PTF с JEDEC_TYPE либами считай и не пользовался никогда. Только в паре проектов такие либы были и то не мои.

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

PART_NUMBER это строчка из документа на компонент. Полное наименование компонента для bom.
Я пишу его part_table, но думаю ничего не мешает его присвоить и в свойствах символа sym_1.

Как можно быстро сделать библиотеку, имея файл .brd?
В импорте в part developer есть импорт из футпринта, но этого не достаточно, не прописываются названия пинов. Вот если бы бы был импорт из девайс-файлов, сгенеренных командой export-libraries... Или он таки есть, но не там?

Не получается запустить консольные команды импорта-экспорта part developer.
Синтаксис соблюден. В таскменеджере видно, что процесс запускается, но тут же прекращается. Никаких сообщений, ничего нет. Даже перенаправление ввода-вывода в текстовый файл не помогает, ничего в этом файле нет. В чем может быть дело? Кто-нибудь пользуется консольным экспортом-импортом?

Есть два проекта со схемами, каждый со своей библиотекой. Некоторые целлы в обоих библиотеках имеют одно и то же название. Что будет, если оба эти проекта попытаться использовать в третьем проекте более высокого уровня? Система будет искать компоненты по имени целла в соответствии с иерархией путей поиска и будет останавливаться, как только найдет подходящее имя (что приведет к ошибкам при упаковке другого подпроекта, ибо в нем содержимое этого целла иное в общем случае) или система будет пытаться найти соответствие целла для каждого проекта по-отдельности, пользуясь путями поиска, настроенными внутри каждого подпроекта?
Если будет все-таки первый вариант, то можно ли как-то заставить систему понять, что для каждого проекта должна быть своя локальная библиотека и компоненты бы в них не пересекались, но были бы доступными и для проекта верхнего уровня тоже? Например, есть ли какие-нибудь префиксы в названиях компонентов, определяющие его библиотеку? Или еще что-нибудь похожее?

Нет, она попытается объединить все записи во всех PTF всех целл, доступных в либах, чтобы по ним сгенерить package. При повторах в названиях целл или именах строк в PTF - выдаст ошибку и прекратит упаковку.
Хотя на самом деле эта проблема вылезает еще раньше, при попытке открыть схему с несоответствующими ей библиотеками. Потому как Design HDL это единственная известная мне система, которая не содержит в схематике схемных компонент, а содержит только ссылки на них в библиотеке.



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

Уточните, плз. Как это? В смысле, по какому признаку она их будет объединять? А если сулчайно резисторы объединятся с конденсаторами?
И что будет, если ptf нету вообще? Сейчас пока у меня именно так: каждый девайс лежит в своем целле. Имя целла равно имени девайса.


Жаль. Что же делать-то? Вести одну единую библиотеку на все проекты? Это ж повеситься можно! Я привык к локальным библиотекам в каждом проекте, это очень удобно, изменения не касаются старых проектов, ничего не надо постоянно проверять и тратить время на ведение центральной библиотеки. Хотя она у меня тоже есть. Но она используется как эталонная, например, когда надо обновить какой-нибудь проект, или новый создать. Но не принудительно! Неужели так здесь невозможно?


Да нет, ну почему? Тот же DxD работает ровно так же. Хотя описанную проблему там я даже не пытался решать, просто не довелось. Но ощущение, что там тоже будет проблема упаковки разных компонентов с одним названием... Эх... Грустно все это.

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



Не знаю, не пробовал без PTF.



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



Там тоже в схеме нет компонентов, а только их имена как ссылки и при открытии схемы они извлекаются из ЦБ? Потому как в Design HDL при открытии схемы с неподключенными либами на местах компонентов будет пусто, только название целл-источника будет написано.

А какая же цель? Минимум корпусов?


А какова такая метода? Я специально попробовал сейчас сделать два целла в разных либах под одним именем. Не получается! Т.е. создать-то можно, но при выборе повторяющиеся целлы не видны и возникает варнинг типа "убедитесь, что во всех либах имена целлов не повторяются". Т.е. даже вставить компонент невозможно, не говоря уж об остальном. О какой методе Вы говорите?


Да, так точно. Только там к каждому УГО еще можно добавить префикс с именем библиотеки и двоеточием, типа "Resistors:". Тут я видел, почти тоже самое, но через точку. Но почему такое ограничение, чтобы все целлы были уникальными?? Зачем тогда нужен вообще уровень "library"? Чисто чтобы по диску можно было перемещать? Ну это же фигня какая-то! Компоненты рассортированы по библиотекам, но должны быть уникальными... Может, есть какая-то настройка, чтобы это отключить?

Это вопрос к программерам Кэйденс. Но имхо логично - чтобы упаковать проект нужно прошерстить либы вытягивая инфу по всем компонентам.



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



На самом деле здесь уровень всего один - целл. Остальное чисто логически-дисковая организация удобного хранения-доступа к этим целл, не более того. Поэтому очень понятно, что двух целл с одним именем быть не может.
Я вот только понять не могу зачем Вам разные целл под одним именем и почему нельзя этого сделать в рамках одной целл, дабы не городить огород. А то потом будет песня - есть пяток чипов MxL251 в разных либах и вопрос - чем отличаются? Какой вариант ставить в создаваемый проект? Какая версия и почему была использована в проекте, который делался 3 года назад? Что с такими вопросами делать будем?

Странная логика. Зачем чего-то шерстить, если уже в данной конкретной либе всё уже и так лежит?



Похоже, что так и будет. Жалко...


Фиксация - это чем? Контролем версий? Или просто копированием в отдельную папочку в нужный момент?



Мда. Печально. Как бы то, что уровень всего один, нифига не очевидно по докам, согласитесь.


Правильные вопросы. Буду пытаться искать ответы. За исключением того, что искать и вспоминать через три года ничего не надо будет, т.к. библиотека будет исключительно локальной, "одноразовой", только для конкретного проекта.

Поэтому меня интересует пока такой вопрос: как вывести в бом два целла с разными (теперь будут уже разные - сделаю это принудительной заменой) именами как один компонент. Это пока при отсутствии ptf. При наличии, видимо, будет по-другому, но мне надо пока при отсутствии.
Зачем все это? Да просто я генерю библиотеку для реюза поступающей мне платы, а в ней компоненты могут называться как угодно, ибо делал их не я. Могут и пересечься с моими. Поэтому пока решил добавлять к ним искусственный префикс и делать принудительную замену в плате, и только потом уже заимствовать. Но вот сидеть и выискивать, какие там компоненты таки реально пересекаются, и в чем там отличия, чтобы потом объединить их в один целл в центральной либе я как-то не готов...

Ведение библиотек под клиента - самый простой вариант разделения библиотек. Проще всего прописать системные переменные и через них указывать пути к либам в проекте.
В процессе создания схемы и работы над проектом используется такая либа, редактируемая и обновляемая.
По завершению проекта делаетсяего архивация(в Project Manager меню Tools -> Archive - > New archive). Этот архиватор шерстит проект по компонентам, копирует использованные целл внутрь проекта и переписывает файл cds.lib меняя пути к либам с глобальных на локальные относительные. В итоге такой архив проекта можно открыть в любое время на любом компе без наличия либ.

А с реюзом мы делаем несколько иначе. Оно конечно не совсем реюз, но старт ускоряет: фактически как основа нового проекта испольуется только плата, а схема при этом рисуется с нуля сразу нашими либами. Единственное, что нужно соблюсти - рефдезы. Тогда при переносе инфы в РСВ вносятся все изменения еще и апдейтятся корпуса на наши из библиотеки.
Несколько раз делали трансляцию схемы из Оркада в Design HDL. В этом случае помогал инструмент Part Manager, позволяющий быстренько увидеть каких именно компонентов использованных в проекте нет в либах и так же быстренько сделать им замену на что-то из имеющегося. Т.е. фактически ни в одном проекте чужих компонентов не использовали, все переводили на свои.

Да, это стандартное поведение, я к такому привык и в менторе тоже.


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

Никак не складывается целостная картина в голове.

Вопрос теперь такой. Допустим, есть похожие компоненты, но с разным количеством ног (и их названиями). Например, микросхемы памяти. У более емких больше пинов адреса. Или, например, транзисторы. У более мощных несколько пинов стока-истока.
Как организовать такие компоненты?
По идее, очень хочется выделить для одного типа один целл, и внутри него плодить пэкаджи. Внутри пэкаджей можно дальше плодить PACK_TYPE, чтобы потом каждому из них сопоставлять футпринты через ptf.
Т.е. получается, например, DDR3 (cell) - 1Gb (package) - K4B1G1646G (pack_type).
Все красиво, и даже получается создать и сохранить, но при запуске проверки (tools - verify - view verification) возникают ошибки, что в некоторых пэкаджах отсутствуют пины.
Какой из этого выход? Плодить целлы так, чтобы внутри каждого были только пэкаджи с одинаковыми пинами? В чем тогда смысл механизма с иерархией cell -package - pack_type?

Наоборот. Плодить пэкеджи с уникальными именами пинов в каждом из них.
Посмотрите в приложенной целл как сделано. С ней проблем при проверках не возникает.

Нажмите для просмотра прикрепленного файла

Не могу найти отличий от своего случая. Все то же самое, но появляются ошибки, как только сгенерил УГО.
Т.е. сгенерил УГО для одного пэкаджа - появились ошибки, что в остальных нет пинов, которые есть в сгенеренном только что. Если сгенерить еще одно УГО, то количество ошибок возрастет.
В чем же дело-то???
UPD. Нашел отличия. В Вашем случае пины просто добавляются-убираются, а в моем еще и переименовываются. При этом переименованные пины в разных пэкаджах попадают на одни и те же пины футпринта, который общий. Очевидно, дело в этом.
Как быть в такой ситуации?
UPD. Таки смысл именно в уникальности названий пинов для каждого пэкаджа.
Не нравится мне это... Ну зачем я буду в каждом пэкадже называть пины, скажем, адреса, в микросхеме памяти по-разному? Других вариантов нету?

Как быть с микросхемами, у которых названия выводов и количество УГО меняются в зависимости от ее настроек?

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

По идее, можно развить тему с пэкаджами и для каждой конфигурации создавать свой пэкадж, как приведено в примере с CNH_100.
Но возникает сложность с тем, что микросхема описывается несколькими УГО, в отличие от разъема. Количество может доходить до 50 и более.

import eco не помогает, ибо невозможно выбрать пэкадж, в который надо импортировать. Если же начать импорт поверх старого, то возникают конфликты УГО, что естественно. При этом попытки просто добавить новые УГО не проходят, т.к. возникает ошибка, мол, при импорте номера символов должны начинаться с 1.

Пока что вижу только один выход - делать для каждой конфигурации микросхемы новый целл. Это единственный вариант?

А смысл? GPIO он и есть GPIO. Зачем ему каждый раз задавать новое имя? Функция и по имени цепи подключенной к пину можно определить.

Я привык имена цепей давать, глядя на название пина, причем в 99% случаев давать путем копирования одного в другое.

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

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

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

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

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

Бессмысленная затея, но раз Вам так нравится, то успехов.

Дык а правильно-то как?

Видимо "правильно" у каждого свое, а мое я уже озвучил - многофункциональный пин, это GPIO, и какая именно в данный момент на нем функция меня не волнует. Вы считаете иначе - Ваше право.

Как Вы понимаете, какая у конкретного пина функция в данном проекте, если все подобные пины называются однообразно (рискну предположить, что "GPIOxxx"). Держите в памяти или во вспомогательных записях?

Многофункциональный пин контроллера/процессора/ПЛИС подключен, как правило, не к другому такому же пину, а к конечному устройству/микросхеме, со строго определенной функцией. Вот по этому пину однозначно и определяется функция пина GPIO. По крайней мере я так всегда считаю. Иногда бывает иначе, в случае шин между ПЛИС, но там по большому счету вообще нет разницы как называть пин-цепь, потому как функцию можно изменить в любой момент и даже в процессе работы устройства.

В том и дело, что перед тем, как сделать подключение, нужно понимать, куда именно подводить провод. Как Вы это понимаете?

Доки никак не помогут?

Обычно помогают, но в этом случае плохо. Могу еще раз привести пример.

Прошу прощения, я совсем недавно начал знакомиться с entry HDL, и рассматриваю этот пакет как основу для работы компании. а есть ли возможность в Allegro Entry HDL реализовать следующее?:
После построения схемы из дискретных компонентов, надо получить какие-то данные для формирования спецификации. Можно ли как-то настроить упаковщик(Packager), или свойства компонентов в ptf, чтобы на выходе, при упаковке схемы, для каждого дискретного компонента создавался небольшой список аналогов (других фирм, других размеров, другой стоимости)? Просто читая мануалы, сложилось впечатление, что этого можно достичь. Важно знать, возможно ли это в принципе?

Не очень понятно... на входе РСВ получить список аналогов или как? Для РСВ имеет значение только корпус(в вашем списке это размер). И его определить можно еще на этапе библиотеки(так сразу не вспомню, надо смотреть в доки на Alternate Footprint).
А аналоги для ВОМ-а или другой документации можно на любой вкус генерить - что пропишешь в библиотеках, то можно потом в рапорты и вытягивать.
Но имея некоторый опыт работы с DE HDL я бы советовал смотреть на Capture CIS. Для связки схема-плата самое то, Entry HDL избыточен(а в некоторых местах недостаточен) и куда менее дружественнен к пользователю.

Думаю, да. Посмотрите подробнее мануал про менеджер вариантов, там есть возможность задавать альтернативные детали, при этом в процессе генерации бома, емнип, есть возможность выводить для компонентов, имеющих заданные альтернативы, все значения (каждое в новой строке).
Обратите внимание на настройку шаблона бома во вкладке variant settings, Alternates -> include