Решил я тут совсем культурно оформить варианты исполнений. А именно: сделать так, чтобы в сборочных видах Allegro и в BOM не только убирались ненужные компоненты, но также и замещались номиналы и part numbers.
Вроде как доступ к базе настроил правильно, вижу в CIS Explorer все свои компоненты, пытаюсь сделать Link Database Part. И вот тут грабли... CIS ругается и говорит, что у меня не определен Capture Symbol. Собственно, он и был не определен вначале. Потом я его определил, но это особо не помогает. Дело в том, что схему я рисовал на другой машине, куда я скачал библиотеку с компонентами с сайта ALTERA, потом я взял нужный мне символ и перерисовал его по ГОСТ, потом я поставил его в схему, потом я сделал ему местное редактирование и изменил свойства выводов, чтобы убрать ошибки DRC. И вот теперь я имею в кэше проекта символ с именем EP3C16F484_ESKD_0, которого ни в одной библиотеке нет. Более того, при связывании с базой компонента задним числом мне по-любому не нужно менять символ в схеме на тот, что в базе, а нужно оставить тот, что был в кэше. Вопрос: как сделать так, чтобы оно не ругалось и не приставало?

С другой стороны, если бы я ставил компонент с нуля, то было бы логично взять из базы название символа и попробовать найти такой в библиотеках. Но это уже не мой случай. Я даже думаю, что это не совсем удобно для сложных микросхем, для которых нет стандартных УГО для Э3, и поэтому маловероятно иметь библиотеки для них.

Создайте пустую библиотеку olb и сохраните туда все символы со схемы. Подключите её к схеме. Все компоненты которые есть в CIS должны иметь собственный символ в этой библиотеке.

И что потом, каждый раз в базе курочить записи про компоненты? Как-то это неправильно...

я при добавлении нового компонента в базу сразу создаю ему символ и футпринт (+ PDF)...зачем чтото там курочить?

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

В базе через запятую впишите варианты названия символов, при установке компонента на плату появится выпадающиё список символов.

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

ну это понятно, но это не комильфо...
Объясните, зачем нужно в базе иметь ссылки на временные библиотеки отдельных проектов с временными копиями символов?

У меня одна библиотека (база) для всех проектов которую стараюсь содержать в чистоте и порядке. Чего и Вам советую.

А если назвать их одинаково?

В OLB должны быть разные названия.

ну или надо убирать "schematic_part" из cis configuration. Больше вариантов нет. корпоративная база данных предпологает общую библиотеку.

Нет, я не в этом смысле. Что будет, если в библиотеке и в кэше будет два символа с одинаковым названием, но разным содержимым? Кэш имеет приоритет?
Я просто подобные проблемы в менторе решал примерно таким способом...

bsvc963
Вы мне какую-то ерунду советуете. Мне так не нравится.

Проще тогда отказаться вообще от хранения Capture Symbol в базе (если можно), а выбирать его руками и все в проект из CIS не переносить.

Потом еще такой случай. Есть у Альтеры такая тема - миграция проекта. В этом случае на одно посадочное место можно запаять две ПЛИС разного объема. Но особенность в том, что ПЛИС меньшего размера имеет больше I/O, а в ПЛИС большего размера часть I/O заменена пинами питания. Так как я должен нарисовать одну схему, я должен выбрать УГО какой то одной ПЛИС. Я не могу использовать два УГО. Но вот потом я хочу в part manager-e прилинковать к компоненту два разных набора прочих свойств, но УГО оставить только чей-то один. У них разные УГО, и только для варианта миграции они могут быть взаимозаменяемы (я для себя выбираю УГО меньшей ПЛИС, и часть I/O аккуратнентько подключаю к нулю и к питанию). И вот это оно тоже связывать с разными ПЛИС не дает.

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

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

vitan, для ПЛИС с большим числом переконфигурируемых выводов это нереально. Без шансов. Только некий библиотечный символ в качестве нулевого приближения и потом в схеме редактирование по месту.

Отключил вообще schematic part в конфигурации CIS. Счастье
Теперь надо придумать, как такие компоненты ставить в новую схему...

"Отключил вообще schematic part в конфигурации CIS. Счастье sm.gif
Теперь надо придумать, как такие компоненты ставить в новую схему..."
мда....

vitan прав вам в менеджер вариантов.

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

Нереально делать УГО посадочного компонента. Это по сути отказ от кучи проверок DRC, отказ от читаемости схемы, и т.п. И все это ради одного свойства CIS?

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

Да, под DRC я имел ввиду electrical rules check, с матрицей разрешенных соединений. Порой приходится по-месту править, чтобы выход с выходом не соединялся.

Пока вот у меня какая задача. Была сделана схема, в которой все свойства сделаны руками, вообще без CIS. В таком варианте максимум того, что можно до CIS добиться - это получить варианты исполнения с отсутствием отдельных компонент. Это в целом уже неплохо, но недостаточно. Сейчас возникла необходимость научиться делать замены номиналов пассивных компонентов, а также делать замену микросхем для разных температурных диапазонов, и еще разные объемы ПЛИС при миграции. Так вот, я пытаюсь теперь обновить схему таким образом, чтобы свойства компонент стали читаться из базы. Для этого я переношу в базу часть свойств из схемы, чтобы заполнить базу, а потом пытаюсь слинковать компонент с базой. И вот тут база начинает рычать, что у меня видите ли символ компонента не ищется в библиотеках.

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

А как он ищет? Вот у меня есть либа ELEMENTS, и простой конденсатор прописан как ELEMENTS\CAP,DISCRTETE\CAP NP. И оно ругается, что не видит компонента. Может, я как-то не так написал? Хотя раньше вроде работало...

PS: В 16.2 падение CIS так и не победил, решил попробовать в 16.6.

UPD: Вот сейчас решил упростить задачу максимально. Сделал отдельный простой проект с двумя компонентами. Первый компонент - поставлен без базы. Второй компонент поставлен из CIS - DISCRETE\CAP NP. Так вот, я решил компонент слегка обновить, ну только косметически вид поправил. Он сохранился в кэше с именем CAP NP_0. И все. Теперь он не хочет линковаться с базой. То есть никакого приоритета нет, просто компонент другой и "до свидания".

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


Ну дык вопрос: можно ли его там в кэше обратно переименовать в CAP NP?

Неправильно. Я хочу в менеджере вариантов указать разные записи в БД для одного позиционного обозначения. например, у меня есть ПЛИС EP3C16, идет в простом исполнении. В более сложном исполнении идет EP3C40. Аналогично можно сказать про оперативную память разного объема и т.п. Но для примера я остановлюсь только на ПЛИС. Вот я могу в Part manager-е выделить ПЛИС в отдельную группу FPGA и в ней создаю две подгруппы: EP3C16 и EP3C40. Потом я иду в группу Common и перетаскиваю компонент в группу FPGA. Потом я по очереди открываю подгруппы FPGA_EP3C16 и FPGA_EP3C40 и пытаюсь там сделать link database part, где выбрать в базе строчку с другим набором свойств. И вот тут облом. не удается прилинковать компонент, если в базе у него другой schematic part. А у ПЛИС EP3C16 и EP3C40 разные УГО. Но в случае, когда выполнены требования ALTERA по миграции, я могу ставить один на место другого! Для удобства я использовал в схеме УГО от EP3C16, хотя мог бы и EP3C40. Но беда в том, что линковать не получается.

И аналогичная фигня возникает при локальной правке символа в схеме, его символ меняет имя и не хочет совпадать с библиотекой.

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

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


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

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

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

Но главное даже не в этом. Главное в том, что CIS нарушает принцип работы с локальной копией проекта без базы. В обычном проекте без CIS я могу создать дизайн, сохранить его в файл, отдать его кому-либо, у кого нет даже моих библиотек, и там все будет нормально. Человек сможет, например, скопировать часть схемы к себе с моими УГО, или что-то изменить в моей схеме, скопировав часть моих же УГО. А CIS требует постоянно связи с правильно настроенной базой, которая у всех своя, и ICA тоже совершенно не удовлетворяет даже простейшим требованиям ЕСКД. Не говоря уже о том, что там нету деталей.

В общем, не надо было вообще завязывать исполнения на работу с базой. Исполнения должны быть сами по себе, а связь с базой сама по себе. Чтобы можно было прописать все свойства всех исполнений хоть вручную, совсем без базы. А вот базу можно подключать по желанию, чтобы сократить себе работу по прописыванию свойств. И тогда, при копировании проекта из системы, настроенной на работу с одной базой, можно было бы вообще его дальше хоть руками подправлять, если надо. И исполнения новые добавить без труда.