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. Но беда в том, что линковать не получается.

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

Сообщение отредактировал Hoodwin - Jul 19 2013, 16:43

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

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


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

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

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

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

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