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

Как быть?

REUSE_ID - у instance-в должны быть разные.

REUSE_ID
The REUSE_ID property, automatically attached to a component, allows for the correct assignment of logic within a module instance. The REUSE_ID property is a number that uniquely identifies each symbol and component within a module. It is used to reconnect reference designators when a module is used in a design, thus allowing for the correct assignment of logic within a module instance. The property is stored within the module file and the Allegro PCB Editor or Allegro Package Designer design file that represents the module information, and is backannotated to the schematic that represents the module's logic.

Note: Because this property is for Cadence internal use only, you must not edit it.


REUSE_INSTANCE
The REUSE_INSTANCE property, assigned on the reuse block when instantiating it in Allegro Design Entry HDL, uniquely identifies the instance of the reuse block. The PCB Editor uses the REUSE_INSTANCE property to differentiate among multiple instances of a reuse module. Unlike other schematic properties, the REUSE_INSTANCE property, defined on the topmost block, wins in the case of nested blocks

Как же так?
Вот цитата:

Reuse_id мне создает сам pcb editor, когда я выполняю команду create module. Далее делается backannotate, и reuse_id без изменений попадает в схему. Там я назначаю вручную на каждую instance своё instance_name и снова отправляю в плату. Получаю столько instance, сколько и указал, с теми же именами. Но без компонентов (при установке появляются только символы). Более того, компоненты тоже есть, и их моно выставить вручную, и они даже помечены буквой M на иконках. И если их выставить рядом с модулем, а потом сделать show element, поставив галочку groups, то выделяется весь модуль (с "пустым" символом) и этот компонент (!).
Какой-то бред...

Вы не могли бы привести кусок нетлиста, в котором точно работают модули?

Спасибо за наводку. Компоненты встали. Только как-то странно.
Пришлось на схеме проставить компонентам свойство reuse_pid (не reuse_id, как рекомендовано). После этого я ради эксперимента вообще удалил со схемы свойства reuse_id. И что бы Вы думали? Они и без этого свойства отлично встают!
Вот как это понять? Это получается какой-то глобальный косяк. Причем, т.к. схема у меня в менторе, я читал документацию и от ментора тоже. И там тоже написано про именно reuse_id (слово reuse_pid там вообще не встречается).

Я так понял, что по задумке свойство reuse_pid должно использоваться в модулях, которые имеют в своем составе другие модули. Типа, чтобы понять, какой ID был у предка на предыдущем уровне (видимо, "p" означает parent). У меня reuse_id, таким образом, осталось только в компонентах в определении модуля (.mdd).

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

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

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

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

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

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

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

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

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

Для чистоты эксперимента создал с нуля простой проект: на схеме четыре одинаковых модуля, которые ссылаются на внешний дизайн - "родителя". В родителе выполняю операцию "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 в схему. Но это, очевидно, совершенно не важно.
Вот и вопрос: как после этого доверять документации? Эдак ведь можно до посинения свойства назначать, не зная, как именно надо...

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_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.

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

Тут вроде все понятно. 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.

...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...

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