[Ant_m 0]

Не совсем так... там не приоритет работает, а ключевые свойства в 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 1]

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 2]

Насколько я понимаю тот 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 1]

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

Вы главное пробуйте, оно так лучше получается понять, что происходит.

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

[vitan 2]

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

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

 

Вы главное пробуйте, оно так лучше получается понять, что происходит.

А 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 1]

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

[Ant_m 0]

Специально попробовал создать компонент, у которого в 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 2]

Как можно быстро сделать библиотеку, имея файл .brd?

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

[vitan 2]

Не получается запустить консольные команды импорта-экспорта part developer.

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

[vitan 2]

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

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

[Uree 1]

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

 

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

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

 

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

 

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

 

[vitan 2]

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

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

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

 

При повторах в названиях целл или именах строк в PTF - выдаст ошибку и прекратит упаковку.

...

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

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

 

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

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

 

[Uree 1]

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

[vitan 2]

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

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

 

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

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

 

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

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

[Uree 1]

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

 

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

 

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

 

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

А метод может быть несколько:

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

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

- еще что-то, не знаю что, но мало ли...

 

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

 

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

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