[PBO 1]

Just now, SM said:

Ну это я уже объяснял - так, это потому, что проект был уже сделан для reuse block-а, развести топологию это же не раз-два, это  не самая простая работа

Ну это уже нюансы о которых никто кроме вас не знал

сути это не меняет , не важно как был сделан проект, перегнать его в self managed block довольно просто если внимательно слушать что вам подсказывают и документацию читать 

[SM 0]

On 11/14/2022 at 8:40 PM, PBO said:

перегнать его в self managed block довольно просто если внимательно слушать что вам подсказываю

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

А еще я попробовал удалить плату (Board) в проекте схемы, вся схематика сама при этом превратилась в иерархический блок. Потом я создал там новую плату, с пустой схемой, и разместил там этот блок. И все платы-схемы переименовал так, чтобы оно соответствовало топологии.  Но как я потом не изголялся, не получилось притянуть к этому топологию, она ругалась разными страшными ошибками при аннотациях. Вот тут я убил немало времени впустую.

 

Ну, в общем, это уже все не о чем

 

[PBO 1]

5 minutes ago, SM said:

Ну так вот и не подсказал же никто, что надо сделать новый проект, перекопировать туда по очереди сначала схематику в иерархический блок, а потом топологию через circuit clipboard

Об этом вопрос и не стоял ) 

стоял вопрос какой метод использовать и что есть для этого а как копировать что то пользоваться copy circuit и еще миллион мелочей которые нудно учесть , вы мне предлагали тут описать ?) 

в документации все это есть

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

В итоге получается что вы все правильно делали а те кто вам все подсказал изначально так делать - неправы потому что они не думали так как думали вы ?) 

Еще раз : 

вы думаете я тут трачу свое время чтобы спорить с вами или давать советы которые не работают, чтобы потом опять читать все и решать проблемы  снова ?) 

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

[SM 0]

Я очень прямо спрашивал, как преобразовать проект, уже сделанный для reuse block без иерархического блока, в проект для managed block с иерархическим блоком. Цитата чуть выше была. Вот прямее некуда. Этот вопрос, главный на тот момент, остался без ответа вообще. Я не знал в тот момент, надо ли для этого копировать топологию, или есть иные пути, или вообще путей нет таких, и делать топологию заново. Поэтому и упирался в reuse block, предполагая, что преобразовать проект reuse block-а будет крайне трудоемко. Оказалось, что можно и скопировать топологию, и иной путь тоже есть через откат к старой версии, вообще простой до элементарности. И может это еще не все пути.

[PBO 1]

Just now, SM said:

Я очень прямо спрашивал, как преобразовать проект, уже сделанный для reuse block без иерархического блока, в проект для managed block с иерархическим блоком. Цитата чуть выше была. Вот прямее некуда. Этот вопрос, главный на тот момент, остался без ответа вообще. Я не знал в тот момент, надо ли для этого копировать топологию, или есть иные пути, или вообще путей нет таких, и делать топологию заново. Поэтому и упирался в reuse block, предполагая, что преобразовать проект reuse block-а будет крайне трудоемко. Оказалось, что можно и скопировать топологию, и иной путь тоже есть через откат к старой версии, вообще простой до элементарности. И может это еще не все пути.

Можно было еще вручную создать директории reuseblock внутри каталогов бибмломтеки как Александр упомянул , тогда бы у вас стали активными блоки reuse в VX2.12, но блин сам вендор уже как 7 релизов не рекомендует их использовать и использовать managed block. 
в общем самое главное что проблема решена и теперь стало понятно куда двигаться 

хорошего вечера

[SM 0]

Я вот с новыми проблемами с блоками столкнулся. При разработке блока я использовал глобальные сигналы, ну как обычно, земли, питания. Но они должны быть глобальными только между страниц схемы блока, но не вне блока. По сути - все блоки гальваноразвязаны и внутри них свои земли и свои питания. "Remap globals" не дает переименовать их руками, там только выбор из списка имен цепей. На что надо поменять "глобальные" специальные символы типа POWER/GROUND, чтобы они давали имена связанным с ними цепям, соединяли их по всем листам схемы блока, но не делали их глобальными вне блока? Или как это разрулить иначе? Может быть оставить тип символа тем же, то есть POWER/GROUND, но убрать из символа свойство "Global signal name" (вроде так нельзя)? Я не хочу опять что-сделать не так.

 

Еще я использовал внутри блока шину. Там тоже самое, remap buses не дает просто назначить новое имя шине, свое для каждого экземпляра блока. Как правильно поступать с шинами? Надо в хост-проекте понаделать пачку шин в настройках bus contents указав в них разные имена цепей и сделать каждому блоку remap bus на разные шины? Или это как-то можно автоматизировать? Ведь шины изначально не глобальные предметы по логике, они то уж с гарантией внутри каждого блока свои, локальные.

 

 

UPD:

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

А вот вторая часть пока не решена.

 

[fill 2]

В 14.11.2022 в 13:49, makc сказал:

Т.е., если я правильно понимаю, то RB неудобнее в сопровождении с точки зрения внесения изменений? А MRB позволяет это делать быстрее и удобнее?

Не совсем так. Есть также разница в идеологии применения:
RB
- создали проект со схемой и топологией,
- полностью его закончили
- импортировали как проект в ЦБ
- теперь можем размещать символ этого RB в других проектах, в которых появится его подсхема (не редактируемая) и топология
- если захочется изменить схему RB, то придется изменить ее в исходном проекте и затем импортировать в ЦБ в виде НОВОГО RB.
MRB
- создаем общий большой проект, в котором MRB это всего лишь часть проекта (иерархический символ с подсхемой под ним)
- публикуем MRB в ЦБ
- размещаем символ MRB в других проектах
- одновременно разрабатываем как основные проекты, так и вносим по ходу изменения в MRB

[SM 0]

On 11/15/2022 at 2:53 PM, fill said:

в которых появится его подсхема (не редактируемая)

Ему можно сделать "dissolve" и все станет редактируемым, таким образом, если надо поправить такой блок под нужды другого проекта, то в общем-то нет никаких проблем. И потом из него же можно собрать уже MB, если надо. Главное, да, что он не привязан к исходному проекту никак, и в этом его полезность - он "перемещается" вместе с ЦБ, и не надо за ней таскать еще и исходные проекты блоков.

Но в RB есть зачем-то сделанная мелкая пакость - нельзя в топологии применять MVO (а что в них такого то хитрого?), о чем прямо сказано в документации. А куда без них то? Их надо заменять на отдельные via (хотя вроде еще есть via array, но я ими не пользовался). А в MB вроде как с MVO вопросов пока нет.

Что касается публикации изменений и в RB, и в MB - после их изменений в проекте-источнике надо и тот и этот публиковать в ЦБ, просто разными способами, первый в LM, а второй в Exp, разница в этом ИМХО не велика, на сколько я пока понял. Хотя меня конечно прельщает RB хранением в ЦБ целиком, но я все же перевел все в MB ради MVO.

 

[fill 2]

"Dissolve" превращает RB просто в подсхему проекта.

[SM 0]

On 11/16/2022 at 10:33 AM, fill said:

"Dissolve" превращает RB просто в подсхему проекта.

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

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

[PBO 1]

22 hours ago, SM said:

Но в RB есть зачем-то сделанная мелкая пакость - нельзя в топологии применять MVO (а что в них такого то хитрого?), о чем прямо сказано в документации. А куда без них то? Их надо заменять на отдельные via (хотя вроде еще есть via array, но я ими не пользовался).

Можно заменить их на complex via , но не уверен что они тоже поддерживаются в RB. Ну и это конечно не очень удобно именно для целей MVO

[SM 0]

Я вот еще с неприятностью столкнулся. Внутри манагед блока питания подключены к пинам некоторых компонентов при помощи Supply Rename. Цепи этих питаний не глобальные, так как блоки гальваноразвязанные, и эти питания делаются внутри блока, для каждого блока свои. В результате, при размещении блоков в основной схеме, эти пины отваливаются от нужных внутриблочных цепей, которые внутри блоков переименовываются автоматически, и образуют новые цепи с именами, заданным в этих Supply rename, которые соединяют их между всех блоков. Такое ощущение, что система забывает переименовать цепи в этом аттрибуте. Эти цепи при этом не являются глобальными, и в списке для "remap globals" экземпляра манагед блока их нет. Самостоятельно справиться с проблемой не получается... Есть ли решение этой проблемы?

[PBO 1]

Лучше наоборот использовать Глобальные сигналы а при заведении сигнала в блок делать его локальным путём переназначения порта

[SM 0]

On 11/29/2022 at 12:47 AM, PBO said:

а при заведении сигнала в блок делать

А эти сигналы (питания) никуда из блока не выводятся наружу, и в блок также снаружи не заводятся, они живут строго внутри него, в нем генерируются, и им же одним и потребляются, и на порты не заведены, и не должны быть заведены.

 

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

 

PS

Кстати, Supply rename на локальную цепь блока и в исходном проекте блока глючит. Как пример - есть локальная цепь Vint внутри блока без портов на этой цепи. Блок называется MYBLK. В Layout в проекте-исходнике эта цепь попадает как Vint_MYBLK. Если при этом внутри блока в Supply rename назначить кому нибудь питание на "Vint" - то в Layout образуется новая цепь "Vint", отличная от "Vint_MYBLK". Таким образом, чтобы все верно соединилось, надо внутри блока писать Supply rename на "Vint_MYBLK", а в блоке-то такой цепи как бы и нет. Это уже явный косяк - кто-то типа паковщика (или не знаю кого) не анализирует Supply rename на предмет их глобальности или локальности - считает их априори глобальными, хотя это совсем не так в общем. Ведь для того этот rename и придуман, чтобы где-то переназначать питания на какие-то местные цепи.

[PBO 1]

31 minutes ago, SM said:

Ну я пока решил вопрос переделкой компонентов так, чтобы вместо Supply rename у них стал отдельный гейт с питаниями

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

вообще supply rename это свойство работает ТОЛЬКО для глобальных сигналов и во вне managed block 

The Xpedition Designer tool defines supply nets (Power and Ground) as global nets. Typically, the component global net pins do not display on the symbol, and do not connect to the global power and ground nets in the schematic.