Не получается использовать module, design reuse Опции

[vitan]

Есть схема с иерархическими блоками (в менторовском DxD).
Генерится нетлист. Импортируется в аллегро. Появляются Module Instances.
Все хорошо, но при установке этого самого Instance на плату не происходит привязка компонента из нетлиста к символу из module (пробовал несколько вариантов, сейчас мучаю модуль из одного резистора и двух иерархический пинов, для простоты).
Возникает ошибка

Код

Component not found for symbol <имя корпуса>

И далее, как следствие

Код

Logic syncronization failed. Continuig.

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

Встает вопрос. Как аллегро ищет соотвествие между символами в модулях и реальными компонентами в схеме?
По-идее, написано, что это делается через свойства REUSE_NAME и REUSE_ID. Проверял нетлист вручную, для каждого instance в нем правильно прописаны эти свойства и их значения. Т.е. для двух разных instance резисторов есть одинаковые ID и NAME, отличаются они только Refdes-ом.
Обновлял символы. Та же ошибка, только в окошке лога.

Как быть?

[vitan]

И?
Вот Ваши же слова.

REUSE_ID "потомков" все разные, если они пересекаются, то начинаются косяки...

Убрал у клонов на схеме свойство REUSE_ID, сгенерил нетлист, втянул на плату - все нормально. Посмотрел свойство компонентов на плате у всех клонов одинаковый REUSE_ID.

У Вас это не вызывает желания разобраться? Что за косяки и почему они в этот раз не возникли?

У меня на картинке как раз показан случай вложенного реюза.

А простой случай Вы не пробовали? Какие там свойства необходимы? Что-то мне подсказывает, что, имея только reuse_id у instance у Вас не получится нормально выставить модули на плату... И даже тот факт, что

Убрал у клонов на схеме свойство REUSE_ID, сгенерил нетлист, втянул на плату - все нормально. Посмотрел свойство компонентов на плате у всех клонов одинаковый REUSE_ID.

меня пока не убеждает. Вот, если бы Вы вручную поудаляли свойства на компонентах в определении модулей и в instanc-ах, то тогда был бы чистый эксперимент. Говорю потому, что сам проходил.

Прилагаю файлик где достаточно внятно расписан порядок работы при использовании design reuse. На 11 странице расписано назначение свойств, используемых при design reuse.

Спасибо, но это все я читал, и именно потому, что на самом деле все получается не так, я и создал этот топик...

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

[Old1]

У Вас это не вызывает желания разобраться? Что за косяки и почему они в этот раз не возникли?

Желание есть , разбираюсь. По поводу невозникших косяков, пока могу только предположить, что не возникли они потому что в моем проекте не было вложенных реюзов, хотя свойства были назначены как для проекта с вложенными реюзами... Если будет время вечером проверю.

А простой случай Вы не пробовали? Какие там свойства необходимы? Что-то мне подсказывает, что, имея только reuse_id у instance у Вас не получится нормально выставить модули на плату... И даже тот факт, что
меня пока не убеждает. Вот, если бы Вы вручную поудаляли свойства на компонентах в определении модулей и в instanc-ах, то тогда был бы чистый эксперимент. Говорю потому, что сам проходил.

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

Для чистоты эксперимента создал с нуля простой проект: на схеме четыре одинаковых модуля, которые ссылаются на внешний дизайн - "родителя". В родителе выполняю операцию "Generate Reuse module". В результате каждому компоненту родителя назначилось свойство REUSE_ID c уникальным значением. Затем в основном дизайне выполняю операцию "Renamber design for using reuse modules", в результате которой в редакторе свойств ничего нового не появилось, но после генерации нетлиста, в нетлисте у каждого клона появилось по три свойства:REUSE_NAME, REUSE_PID, REUSE_INSTANCE. Причем REUSE_PID у клонов имеющих общего родителя - одинаковый. Вот такие пироги...

[vitan]

Для чистоты эксперимента создал с нуля простой проект: на схеме четыре одинаковых модуля, которые ссылаются на внешний дизайн - "родителя". В родителе выполняю операцию "Generate Reuse module". В результате каждому компоненту родителя назначилось свойство REUSE_ID c уникальным значением. Затем в основном дизайне выполняю операцию "Renamber design for using reuse modules", в результате которой в редакторе свойств ничего нового не появилось, но после генерации нетлиста, в нетлисте у каждого клона появилось по три свойства:REUSE_NAME, REUSE_PID, REUSE_INSTANCE. Причем REUSE_PID у клонов имеющих общего родителя - одинаковый. Вот такие пироги...

Вот! Ровно то же, что и у меня! Reuse_id достаточно иметь только у определения блока. У экземпляров же надо проставлять reuse_pid.
Единственное отличие моих действий от Ваших в том, что я создаю определение блока в аллегро, а потом делаю backannotate в схему. Но это, очевидно, совершенно не важно.
Вот и вопрос: как после этого доверять документации? Эдак ведь можно до посинения свойства назначать, не зная, как именно надо...

[Old1]

Вот! Ровно то же, что и у меня! Reuse_id достаточно иметь только у определения блока. У экземпляров же надо проставлять reuse_pid.
Единственное отличие моих действий от Ваших в том, что я создаю определение блока в аллегро, а потом делаю backannotate в схему. Но это, очевидно, совершенно не важно.
Вот и вопрос: как после этого доверять документации? Эдак ведь можно до посинения свойства назначать, не зная, как именно надо...

Я особых противоречий в документации не наблюдаю.

REUSE_ID: This property is added to every part in a reuse design. Within a reuse design there are as many
values of this property as there are packages so that each package has a unique REUSE_ID. All parts in a
package have the same REUSE_ID value. Capture assigns these property values when you enable the
Generate Reuse Module in the Allegro Reuse tab off the Annotate dialog box.

Тут вроде все понятно. REUSE_ID назначается компонентам в дизайне, который используется как "родитель".

REUSE_PID: If a reuse module contains another reuse module as part of its external design, then the
netlister assigns a REUSE_PID value to every component in each package of the external design. The value
of the REUSE_PID is the same as the value of the component's previous REUSE_ID. A new REUSE_ ID
value is then assigned to each module. This way, occurrences of the same module will have different
REUSE_IDs on them, but the same REUSE_PIDs for corresponding components. Using REUSE_IDs,
makes it possible for Capture to propagate changes to lower levels of a reuse module.

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

Если reuse module содержит другой reuse module как часть внешнего дизайна, тогда нетлистер назначает REUSE_PID каждому компоненту у которого "родитель" во внешнем дизайне. Значение свойства REUSE_PID такое же как значение REUSE_ID "родителя".Новое значение REUSE_ID тогда присваивается каждому модулю. Таким образом occurrences одного модуля будут иметь разные REUSE_ID в нем, но один REUSE_PID для соответсвующего компонента во внешнем дизайне. Использование REUSE_ID позволяет Capture распространять изменения на низшие уровни reuse module.

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

[vitan]

Я особых противоречий в документации не наблюдаю.

Я тоже. Наблюдаю только противоречие документации и реальности.

Тут вроде все понятно. REUSE_ID назначается компонентам в дизайне, который используется как "родитель".

Согласен. Без этого не работает.

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

Да, немного неточно, но не критично. Вот мой вариант.

REUSE_ID: Это свойство добавляется к каждому компоненту в повторяемом блоке (дизайне). Внутри
блока будет столько значений этого свойства, сколько в блоке корпусов компонентов.
Все части (слоты) корпуса имеют одно и то же значение REUSE_ID. Capture назначает значения этим свойствам, когда вы включаете опцию
"Generate Reuse Module" во вкладке Allegro Reuse в окне Annotate.

REUSE_PID: Если повторно используемый блок содержит в свою очередь другой блок как часть внешнего дизайна, то упаковщик (нетлистер) назначает значение REUSE_PID каждому компоненту в каждом корпусе внешнего дизайна. Значение свойства REUSE_PID будет таким же, каким было ранее у него же значение свойства REUSE_ID.
После этого каждому модулю назначается новое значение свойства REUSE_ID. Благодаря этому экземпляры одного и того же модуля будут иметь различные REUSE_ID, но одинаковые REUSE_PID для соответсвующих компонентов. Использование REUSE_ID позволяет Capture распространять изменения вплоть до нижних уровней в таком многоуровневом модуле.

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

По документации не противоречит простому реюзу, это точно. Но у меня в жизни не получилось. получилось только с использованием reuse_pid. Вот в чем вопрос. Ну и не забываем, что вообще без reuse_id на instance (только reuse_pid) тоже все работает (!)

[Old1]

Я тоже. Наблюдаю только противоречие документации и реальности.


По документации не противоречит простому реюзу, это точно. Но у меня в жизни не получилось. получилось только с использованием reuse_pid.

Но в документации и говорится что как раз reuse_pid и должен быть назначен инстансам

...If a reuse module contains another reuse module as part of its external design, then the
netlister assigns a REUSE_PID value to every component in each package of the external design. The value
of the REUSE_PID is the same as the value of the component's previous REUSE_ID...

Здесь правда речь идет о вложенном реюзе, но при простом реюзе, можно начать так

If a schematic contains reuse module as part of its external design...

Нетлистер Capture так и делает.

...Ну и не забываем, что вообще без reuse_id на instance (только reuse_pid) тоже все работает (!)

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