[vitan 2]

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

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

 

 

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

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

 

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

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

 

 

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

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

 

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

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

 

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

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

[Uree 1]

Ведение библиотек под клиента - самый простой вариант разделения библиотек. Проще всего прописать системные переменные и через них указывать пути к либам в проекте.

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

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

 

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

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

[vitan 2]

Ведение библиотек под клиента - самый простой вариант разделения библиотек. Проще всего прописать системные переменные и через них указывать пути к либам в проекте.

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

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

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

 

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

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

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

 

[vitan 2]

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

 

Вопрос теперь такой. Допустим, есть похожие компоненты, но с разным количеством ног (и их названиями). Например, микросхемы памяти. У более емких больше пинов адреса. Или, например, транзисторы. У более мощных несколько пинов стока-истока.

Как организовать такие компоненты?

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

Т.е. получается, например, DDR3 (cell) - 1Gb (package) - K4B1G1646G (pack_type).

Все красиво, и даже получается создать и сохранить, но при запуске проверки (tools - verify - view verification) возникают ошибки, что в некоторых пэкаджах отсутствуют пины.

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

[Uree 1]

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

 

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

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

 

cnh_100s1_series.zip

[vitan 2]

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

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

Не могу найти отличий от своего случая. Все то же самое, но появляются ошибки, как только сгенерил УГО.

Т.е. сгенерил УГО для одного пэкаджа - появились ошибки, что в остальных нет пинов, которые есть в сгенеренном только что. Если сгенерить еще одно УГО, то количество ошибок возрастет.

В чем же дело-то???

UPD. Нашел отличия. В Вашем случае пины просто добавляются-убираются, а в моем еще и переименовываются. При этом переименованные пины в разных пэкаджах попадают на одни и те же пины футпринта, который общий. Очевидно, дело в этом.

Как быть в такой ситуации?

UPD. Таки смысл именно в уникальности названий пинов для каждого пэкаджа.

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

[vitan 2]

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

 

Например, микроконтроллер. У него один пин может иметь кучу разных назначений и названий.

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

 

По идее, можно развить тему с пэкаджами и для каждой конфигурации создавать свой пэкадж, как приведено в примере с CNH_100.

Но возникает сложность с тем, что микросхема описывается несколькими УГО, в отличие от разъема. Количество может доходить до 50 и более.

 

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

 

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

[Uree 1]

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

[vitan 2]

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

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

 

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

 

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

 

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

 

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

 

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

[Uree 1]

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

[vitan 2]

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

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

[Uree 1]

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

[vitan 2]

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

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

[Uree 1]

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

[vitan 2]

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

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