Lib-Cell-View, вопросы по библиотекам Опции

[vitan]

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

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

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

[Uree]

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

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

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

[vitan]

Cell - это просто одна библиотечная ячейка. Чем вы ее наполните - Ваше дело. Ограничения там больше идеологические, нежели программные.

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

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

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

[Uree]

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

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

[vitan]

У меня все-таки два целла на резисторы - один на одиночные, второй на сборки. Хотя можно было и в один все собрать, но тут мы с коллегами не договорились...

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

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

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

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

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

[Uree]

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

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

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

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

[vitan]

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

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

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

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

[Uree]

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

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

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

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

[vitan]

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

[Uree]

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

[vitan]

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

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

[Uree]

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

[vitan]

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

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

[Ant_m]

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

[vitan]

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

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

[Ant_m]

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

The JEDEC_TYPE property, attached to a component, specifies the footprint to be used in the Allegro PCB Editor design for the component in the logical netlist. This property is typically placed in the body section of the chips file. Its value can be overridden by an entry in a physical part table. This is typically the case when describing components, such as resistors and capacitors, that have a large number of physical parts all sharing the same logical part.

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

[Uree]

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.

[vitan]

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

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

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

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

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

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

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

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

[Uree]

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

[vitan]

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

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

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

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

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

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

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

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

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

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

[Uree]

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

[Ant_m]

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

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

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

[vitan]

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

[vitan]

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

[vitan]

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

[Uree]

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

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

Если будет все-таки первый вариант, то можно ли как-то заставить систему понять, что для каждого проекта должна быть своя локальная библиотека и компоненты бы в них не пересекались, но были бы доступными и для проекта верхнего уровня тоже?

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

[vitan]

Нет, она попытается объединить все записи во всех PTF всех целл, доступных в либах, чтобы по ним сгенерить package.

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

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

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

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

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

[Uree]

Уточните, плз. Как это? В смысле, по какому признаку она их будет объединять? А если сулчайно резисторы объединятся с конденсаторами?

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

И что будет, если ptf нету вообще? Сейчас пока у меня именно так: каждый девайс лежит в своем целле. Имя целла равно имени девайса.

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

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

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

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

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

[vitan]

Не случайно, а очень даже целенаправленно.

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

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

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

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

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

[Uree]

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

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

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

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

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

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

[vitan]

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

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

- библиотеки под клиента, с его составом компонентов, с его набором атрибутов этих компонентов и т.д.

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

- общая либа, используемая при создании проекта и фиксация проекта в момент его завершения с набором компонентов в нем использованном

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

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

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

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

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

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

[Uree]

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

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

[vitan]

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

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

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

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

[vitan]

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

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

[Uree]

Какой из этого выход? Плодить целлы так, чтобы внутри каждого были только пэкаджи с одинаковыми пинами? В чем тогда смысл механизма с иерархией cell -package - pack_type?

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

 cnh_100s1_series.zip ( 26.96 килобайт ) Кол-во скачиваний: 121

[vitan]

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

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

[vitan]

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

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

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

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

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

[Uree]

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

[vitan]

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

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

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

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

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

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

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

[Uree]

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

[vitan]

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

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

[Uree]

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

[vitan]

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

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

[Uree]

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

[vitan]

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

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

[Uree]

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

[vitan]

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

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

[GDicegolem]

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

[Uree]

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

[vitan]

Важно знать, возможно ли это в принципе?

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

[PCBtech]

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

Можно сделать такой отчет, но вам надо будет специальным образом готовить базу компонентов,
чтобы эти аналоги были там прописаны.
Вообще это скорее функция PDM-системы, и тут уже более интересным для вас продуктом может быть ADW.

[GDicegolem]

Можно сделать такой отчет, но вам надо будет специальным образом готовить базу компонентов,

А каким образом? Прописывать PART_NUMBER аналогов в PartTable файле? Или partTable файле здесь не задействуется?

[Uree]

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

[GDicegolem]

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

Большое спасибо, буду разбираться..

[GDicegolem]

Уважаемые коллеги, не подскажете ли? Почему свойство $LOCATION, которое по идее должно указывать reference designator, в схемотехническом редакторе возвращает постоянное значение а не переменное? т.е. размещая на схеме 6 одинаковых резисторов, у каждого из них отображается одно и то же постоянное значение, которое я прописал в $LOCATION, в PartDeveloper-е.
А переменным, у компонента, является непонятное свойство PATH, которое по идее можно было бы использовать для ориентирования на схеме, но оно отображает одинаковый префикс для любых видов компонентов, т.е. и для резисторов, и для конденсаторов - это свойство выглядит как I1, I2,I3...

[vitan]

Уважаемые коллеги, не подскажете ли? Почему свойство $LOCATION, которое по идее должно указывать reference designator, в схемотехническом редакторе возвращает постоянное значение а не переменное? т.е. размещая на схеме 6 одинаковых резисторов, у каждого из них отображается одно и то же постоянное значение, которое я прописал в $LOCATION, в PartDeveloper-е.
А переменным, у компонента, является непонятное свойство PATH, которое по идее можно было бы использовать для ориентирования на схеме, но оно отображает одинаковый префикс для любых видов компонентов, т.е. и для резисторов, и для конденсаторов - это свойство выглядит как I1, I2,I3...

Видимо, схема не упакована.

[Uree]

PATH - внутренний идентификатор символа на схеме. Лучше всего вообще выключить его видимость(где-то в настройках это делается, точно уже не помню где именно).
$LOCATION будет приписан в процессе упаковки и появится на схеме, как уже написал vitan.

[GDicegolem]

Благодарю.

[GDicegolem]

Как-то странно работает фильтр в Component Browser. Вводишь условие: компоненты со значением "свойства" < 50, а фильтр возвращает 48,49, и 480 и 490, и 48000 и 49000. То же самое и на оборот. Это что, получается, сравнение в фильтре нули не учитывает? Уважаемые коллеги, может быть подскажете, как организовать поиск по номиналу здесь? Вижу что в формате номинала 4,7К он также "не ищет"

[GDicegolem]

Вообще не понятно, зачем было добавлять функцию поиска по сравнению (например резисторы >7.5k) если ей нельзя толком пользоваться. Уже и запятые все заменил на точки, и параметр этого свойства менял на string и numeric - все одно. Сравнение осуществляется только по первому разряду.

[vitan]

Как-то странно работает фильтр в Component Browser. Вводишь условие: компоненты со значением "свойства" < 50, а фильтр возвращает 48,49, и 480 и 490, и 48000 и 49000. То же самое и на оборот. Это что, получается, сравнение в фильтре нули не учитывает? Уважаемые коллеги, может быть подскажете, как организовать поиск по номиналу здесь? Вижу что в формате номинала 4,7К он также "не ищет"

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

[GDicegolem]

Вот такой селл. Это наверняка тривиальные вещи, но т.к. я пару недель назад начал изучение HDL, трудности возникают на каждом шагу. Даже в этом файле , могли бы вы мне подсказать, как отдельному package добавить отдельный свой symbol. А то либо они все добавляются, либо (если использовать разные для каждого Package) выскакивает ошибка, что пины применены только в одном Package а не во всех.

Прикрепленные файлы

 resistors_yageo.zip ( 100.69 килобайт ) Кол-во скачиваний: 27

 

[vitan]

1. Добавьте к значениям единицы изменения. Я добавил буквы Ohm в каждую строку и все заработало. В запросе тоже их надо писать (<50Ohm). Откуда столько резисторов, если не секрет?
2. Вы хотите каждому пекеджу своё УГО? Не мучайтесь, нарисуйте один резистор и забудьте. Вместо разных пекаджей (и, соответственно, разных разделов в ptf) задайте несколько PACK_TYPE внутри одного корпуса. Ваш исходный вопрос содержится в предыдущих постах топика, я в свое время тоже хотел сделать что-то подобное, но в итоге отказался от этого и не жалею.

[GDicegolem]

Прекрасно! Премного благодарен, все получилось))!! Резисторы - из даташита http://www.yageo.com/documents/recent/PYu-...51_RoHS_L_1.pdf - делаю на будущее, и опыт заодно набиваю... В дальнейшем добавлю пару колонок с аналогами.
2. Т.е. я добавляю колонку "Pack_Type" в файл ptf, прописываю там названия для "корпусов" и оставляю один гигантский PART? Допустим они как-то коррелируют с "Pack_Type", созданными в Package(Physical_Parts). А дальше я что-то опять не могу понять, каким образом сделать так, чтобы для резисторов 0,5Вт отображался один символ(с продольной чертой), а для резисторов в 1 Вт отображался другой(с поперечной чертой).

[vitan]

Прекрасно! Премного благодарен, все получилось))!! Резисторы - из даташита http://www.yageo.com/documents/recent/PYu-...51_RoHS_L_1.pdf - делаю на будущее, и опыт заодно набиваю... В дальнейшем добавлю пару колонок с аналогами.
2. Т.е. я добавляю колонку "Pack_Type" в файл ptf, прописываю там названия для "корпусов" и оставляю один гигантский PART? Допустим они как-то коррелируют с "Pack_Type", созданными в Package(Physical_Parts). А дальше я что-то опять не могу понять, каким образом сделать так, чтобы для резисторов 0,5Вт отображался один символ(с продольной чертой), а для резисторов в 1 Вт отображался другой(с поперечной чертой).

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

[GDicegolem]

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

1. Не, тут немало Эксель помог. Сначала составил ряд номиналов для e24 и для е96, манипулируя ячейками, из этого ряда вытянул список парт номеров, расположил нужные колонки(свойства для part.ptf) в нужном порядке, и перенес их в птф файл. Если есть желание, могу и по подробнее этот процесс описать.
2. Изучил прошлые посты, и селл от Uree. Для каждого пэкаджа создал по паре пинов с уникальными названиями, и подцепил к ним символы(похоже что раньше тоже такие попытки делал). Может я что-то упустил? Все равно верификацию не проходит, ошибки те же: "пины 1,2,3,4 - не представлены в корпусе 5". Хотя это не мешает посмотреть на результат через ComponentBrowser, и увидеть разные УГО для разных пэкаджей. Может эти ошибки при верификации не так и критичны?

[vitan]

1. Да нет, мне просто показалось, что это экспорт из какой-то старой базы.
2. Внимательнее изучайте. Я там писал ровно об этом же. Это было одной из причин, по которым я отказался от такой организации. Ошибки при верификации могут вылезти боком значительно позже.

[Uree]

Ну у нас они так и не вылезли Но мы таким образом делали только разъемы, остальные компоненты делались стандартным образом, без всяких хитростей. А заморачиваться так с резисторами из-за черточек в них... имхо перебор. Хотя я уже писал об этом - DE HDL как по мне вообще перебор в качестве редактора схем, все реально необходимое можно делать в Capture. А в DE HDL сложностей больше, отдачи столько же, совместимость с остальным миром практически нулевая. Не стОит оно того...

[GDicegolem]

с PAck_TYPE кое-как разобрался, возник еще один момент который просто поставил в тупик. Прочитав описание к этому маршруту, да и просто окинув взглядом project_manager, можно сделать вывод, что в него встроены инструменты для администрирования библиотеки. Кто-нибудь использовал встроенные возможности этого пакета для проверки(валидации) компонентов и библиотек?. А то создал я компонент, или библиотеку, пропустил его через ряд этих проверок (verify_rules, verify_package_flow), а это нигде не отобразилось. То есть я хочу спросить, почему можно использовать библиотеки и компоненты, которые не прошли все эти проверки, ? В мануалах я не смог найти понятное мне описание этого процесса. там написано про build и reference library, но какой смысл от этой reference-библиотеки, если она при создании сразу заполняется всяким мусором из build-библиотеки?

[GDicegolem]

Кажется начинаю понимать. Cadence задумывали так, что "простые смертные" схемотехники(designers) не могут создавать reference Library (так же как и добавлять в нее новые компоненты). А библиотекарь обладает всей полнотой власти, и самостоятельно принимает решение - добавлять новый компонент в reference library или нет, уверен он в нем просто так, или эта уверенность основана на проведении всевозможных проверок и тестов (встроенных в маршрут). Т.е. проверки и check's - не являются неотъемлемой частью маршрута, а используются библиотекарем по усмотрению, я правильно понял? Ну и пока не смог разобраться с тем, что создав build библиотеку в Library Explorer(с лицензией Librarian), она (не утвержденная и не проверенная) тут же доступна для рисования схемы в DE HDL (без лицензии Librarian). - это же не правильно

[Uree]

Вообще эти библиотеки должны быть расположены в разных местах(на диске/в сети и т.п.). И только референс-библиотека должна быть подключена к маршруту создания схем/плат, а билд-библиотека должна быть локальным рабочим местом библиотекаря.

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

Но тут процедуру можете придумать сами, таким образом, как это будет удобно в вашем процессе разработки.

[GDicegolem]

Уважаемый Uree, спасибо за пояснения. Т.е. это выглядит таким образом? На общем диске(в сети, или репозитории) лежит reference-библиотека(утвержденная). Дизайнер, начиная работу над новым проектом(при создании "нового проекта" в project_manager), руками прописывает в файле cds.lib путь к этой утвержденной библиотеке? Или проект создается в общем месте(в сети), файл cds.lib защищается от записи (и его может редактировать только библиотекарь, который опять руками прописывает в нем путь к reference-библиотеке)? как логичнее?
И еще один момент

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

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

[Uree]

Защищать cds.lib не вижу смысла, когда сами либы уже защищены. У нас описание путей к либам обходилось несколькими строками и одной переменной окружения(насколько помню...), поэтому на любом компе в любом проекте cds.lib был идентичным.

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

Не знаю, насколько это может вам подойти, но у нас было так.

[spooki]

Подниму старый вопрос по JEDEC_TYPE и PACK_TYPE.

Вопрос в общем простой. Как сделать чтобы в схематехническом редакторе Allegro Entry HDL отображался JEDEC_TYPE для компонента?

Простой пример.

Вот библиотечный символ диода.



Для него созданы несколько packages и 3 символа (ну это не важно допустим 1 символ).
Как видите из свойств кроме и NAME и $LOCATION ничего не введено.

Вот так выглядит этот символ при добавлении на схему



То есть, все прекрасно выбирается и показывает JEDEC_TYPE и PACK_TYPE.


Вот свойства символа установленного на на схему.


На схеме в свойствах видно свойство PACK_TYPE, хоть я об этом не просил но это хорошо.
Как сделать чтобы было видно свойство JEDEC_TYPE?
Сам я его указать в свойствах могу, но оно не будет переменным, оно будет как текст. Почему нельзя задать свойство символа которое автоматом бралось из chips.prt. Для PACK_TYPE он же это сделал автоматом.


Этот же вопрос, когда компонент имеет всего 1 package как задать поля JEDEC_TYPE и PACK_TYPE в свойствах символа которые будут заполняться автоматом из chips.prt. Я же задаю ему их в part developer, в чем проблема то?





Сообщение отредактировал spooki - May 1 2016, 12:26

[igor5312]

Вот такой селл. Это наверняка тривиальные вещи, но т.к. я пару недель назад начал изучение HDL, трудности возникают на каждом шагу. Даже в этом файле , могли бы вы мне подсказать, как отдельному package добавить отдельный свой symbol. А то либо они все добавляются, либо (если использовать разные для каждого Package) выскакивает ошибка, что пины применены только в одном Package а не во всех.

Добрый день.
Подскажите а чем можно открыть структуру папок подобную присланной вами? Чтобы увидеть символы, посадочные места и таблицы и редактировать их.
PCB librarian открывает только файл библиотеки *.cpm

Заранее спасибо.

[Uree]

Нужно создать библиотечную среду, поместить в нее структуру cell и тогда уже открывать ее в PCB Librarian.

[igor5312]

Нужно создать библиотечную среду, поместить в нее структуру cell и тогда уже открывать ее в PCB Librarian.

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

[Uree]

Там все несколько сложней, чем просто папки в директории, но если коротко, то да.
.СРМ это расширение файла проекта Design Entry HDL, библиотека это тоже проект, в котором нет схемы(хотя можно сделать, никто не мешает), а работа ведется с компонентами. Плюс при правильной конфигурации создается рабочая область(Build Area, с .cpm-файлом проекта) и подключается главная библиотека(Reference Area, там уже проекта нет, только структура папок с cell-ами в них). В общем небанальная система с глубокими корнями и с избыточными возможностями(и сложностями) для большинства пользователей.

Распакуйте содержимое приложенного архива в отдельный каталог, скопируйте свой cell в каталог IC и открывайте _lib_area.cpm в Part Developer. Там, думаю, разберетесь.
Хотя я бы рекомендовал забить на этот маршрут сразу...

 _lib_area.7z ( 37.14 килобайт ) Кол-во скачиваний: 17

[igor5312]

К сожалению забить не получится Заказчик работает в HDL.
Подключить в свою библиотеку и в вашу путем копирования получилось.
Но. Папка cell с резисторами Yageo из одного из постов выше корректно подключилась, а вот мои папки cell из проекта схемы (которые приехали с проектом в папке archive_libs) подключились но содержимого нет. В part developer все разделы packages, symbols и так далее пустые.

[Uree]

Так ничего не скажу, нужно смотреть на ваш archive_libs.

[igor5312]

Разобрался вроде. Надо не просто копировать папку, а еще и прописывать ее в cds.lib

Сообщение отредактировал igor5312 - Jun 30 2017, 13:17