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

vitan, у меня версия 16,3. Ели еще интересно, вот схема:
Нажмите для просмотра прикрепленного файла
Вот verilog.v:


Проект-Нажмите для просмотра прикрепленного файла

Но, ИМХО, делать/писать электрические схемы на верилог это плохая затея...

Насчет плохости затеи Vitan должен быть в курсе, ему об этом уже писали
Vitan, я не буду подробно расписывать изменения, где и какие произошли. Писать много, а толку чуть. Старой версии Вы не знаете, новой тоже. С точки зрения обычного пользователя изменения положительные, работать со схематиком стало проще, теперь все лежит в одном месте и убраны непонятные режимы работы со схемой(expand, property edit или как он там назывался...) а что конкретно они там внутри изменили можно и не копаться. Хотя копаться не обязательно, достаточно взять проект в предыдущей версии и открыть с обновлением в текущей. Потом сравнить исходный каталог с обновленным - и все сразу видно.
По теме: в схематике есть визард генерации иерархических символов. Вот ему на вход можно подсовывать как каталог с деревом иерархии, так и верилог файл. Правда потом этот символ все равно должен оказаться _на_схеме_, и уже с этой схемы будет генерится пэкейдж, передаваемый в РСВ. Но как вариант - может быть.

Спасибо!

Эти все проблемы меня уже очень сильно достают. Хоть свой САПР пиши.

А что скажете на мой первый вопрос?


И еще вопрос по 16.5. Ладно, пускай концепт не генерит верилог. Но упаковщик-то понимает его (если вручную написать)?


Че-то не припоминаю... Ткните-ка пальцем.


Это - да, но это не то, к сожалению.

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

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



Vitan, некогда искать, но с этой идеей Вы уже высказывались и комменты по этому поводу уже были. Достаточно давно, несколько месяцев, а то и с год тому назад, но было, не помню точно когда.

Меня вот другой момент интересует, о котором я тогда писал и сейчас вновь хочу поднять.
Понятное дело, что схема более удобочитаема, нежели просто текст. По крайней мере схема, в которой присутствует чуть больше элементов, чем только несколько цифровых чипов связанных между собой шинами/сигналами и питания к ним без стабилизаторов, развязок/фильтров и прочего. Схему всегда можно открыть(в том числе в бумажном виде), посмотреть и быстро понять, что там и как. Со текстом на несколько десятков страниц так не выйдет, через 3-6 месяцев даже свои собственные исходники выглядят не очень ясно, что уж о чужих говорить.
Дальше Вы Vitan мощно боретесь за удобство в читаемости схем/плат, с разделением на зоны, их описанием, указанием этих зон в перечне и т.п, чтобы легко находить требуемые компоненты и т.д.
И тут я перестаю Вас понимать - с одной стороны боретесь за читаемость всего и вся, с другой стороны хотите сделать исходники РСВ нечитаемыми в принципе. Где логика?

Этот вариант меня устраивает. Вот бы он еще и работал бы... Будем проверять.


А... Это я помню. Вы тогда сказали "ну-ну" и дальше тема не развилась. Вы еще, правда, усомнились в возможности описания цепей питания, на что я Вам ответил, что эти цепи ничем от других не отличаются. Дальше разговор не пошел.


Хотите обсудить удобство? Это же вещь субъективная. Меня при этом не волнует даже то, что большинство народу вокруг меня мне постоянно говорит, что это не удобно. Раз удобно мне, я буду так делать, ибо я разрабатываю сей девайс. И не надо мне рассказывать, что схемой пользуется помимо меня еще куча народу. Я не первый год их рисую, и знаю, что схема просто не нужна никому. Даже мне самому.



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

Комментарии, метки... которые нужны, чтобы прокомменитровать то, что видно в схеме? Смысла не вижу, но если Вы делаете что-то исключительно для себя, то почему бы и нет. В принципе можно вообще только РСВ рисовать, без предварительной работы в схеме/тексте/чем-то еще... Вопрос удобства, как Вы уже сказали.

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

Между прочим, правильный вопрос (если забыть о "бумажке"). Уже не первый раз этот вопрос встает. Вопрос о будущем схематика. Не буду говорить об аналогиях в мире FPGA\ASIC и моделирования, там, как известно, нынче схема - чуть ли не дурной тон.
Лично я думаю, что платы до сих пор рисуют в схематике только потому, что уровень сложности большинства проектов позволяет рисовать их именно так, т.е. не задействовать HDL. Даже самые сложные платы состоят пока только лишь из сотен компонентов, максимум - тысяч. И ничто не предвещает изменений, ибо степень интеграции компонентов повышается, а это ведет к уменьшению их количества на плате.
Но, как только их становится много (а у каждого порог свой, меня уже, к примеру, напрягаяет любое количество больше 1 ), либо когда нужна развитая иерархия и реюз, то тут HDL вне конкуренции. Я сам рисую достаточно некислые иерархические схемы с кучей каналов и т.п., но все равно чувствуется, что это не то. А вот HDL - это то. Это просто мои ощущения, подкрепленные опытом разработки для ПЛИС, кстати.

А про то, "что дальше делать" у меня встречный вопрос. А что Вы хотели бы такого сделать? И что Вы обычно такого делаете, что Вам так сильно нужна схема? За много лет мне внятного ответа никто не дал. Можете попробовать, но у меня найдется ответ на любой Ваш аргумент, по крайней мере до сих пор в аналогичных спорах с другими людьми на эту тему находилось. Готовы?

Я передаю схему в производство и техподдержу, высылаю их для ревью частей схемы в сторонние фирмы(обычно к производителям чипов) и т.п. Т.е. они не остаются у меня на компе в архиве, а расходятся в разные стороны мира разным людям. Если Вы думаете, что они обрадуются небольшому томику с распечаткой "схемы" в виде текста - Вы сильно ошибаетесь... Я уж не говорю о передаче полного пакета документации стороннему заказчику или попытке провести такую документацию по системе ISO900x или российскому ГОСТу - тут вообще весело будет.
Хотя, опять же, если делать самому и для себя - можно все, что угодно. Правда вопрос "зачем" встает еще выше.

Ну что ж, пройдемся.
В производство. Можно поинтересоваться, зачем (С) она там?
В техподдержку. Вопрос тот же. Что они там с ней делают? Разбираются, как устройство работает? Хотите сказать, что без схемы это невозможно?
В сторонние фирмы. Опять же, какая цель? Если просто соответствовать привычным стандартам, то все понятно. Но что там в этих схемах они хотят увидеть? Если их об этом спросить, то они снова не смогут четко ответить.
Все упрется в привычку и личные предпочтения. А они среди тех, кто делает платы не меняются, выше уже написал почему. Но меня привычки большинства моих соседей никогда не останавливали.
Зачем? Чтобы быстрее и качественнее создавать платы и устройства, вот и все. Поверьте, в больших проектах это имеет смысл. Вы сами пробовали когда-нибудь? С ПЛИС дело имели?

Vitan, ну Вы в самом деле, как никогда и никуда кроме небольшой мастерской не заглядывали...

Производство, в лице ODM-a, схемы подстраивает и оптимизирует для более выгодной продукции устройства. Есть ключевые места/компоненты, есть рядовые. Первые трогать нельзя, вторые можно. Мысль ясна? Они схемы ЧИТАЮТ и редактируют с целью оптимизации.

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

Сторонние фирмы проверяют дизайн на предмет его "хорошести", с точки зрения людей, которые проектируют чипы, в нем используемые. Вот Вы лично насколько глубоко знаете как устроен какой-нибудь DC-DC преобразователь на 5-10А с частотой работы в районе 1.5МГц фирмы MPS и каковы особенности его работы и тонкости дизайна, особенно когда таких преобразователей 7 штук на плате довольно плотно стоит? Вы эксперт в силовой импульсной электронике? У нас есть пара экспертов, но финальный вариант дизайна еще и просматривается и анализируется разработчиками чипа фирмы-производителя. Можно конечно отменить этап ревью, но чревато лишними итерациями и потерями времени. Что Вы там говорили насчет сокращения сроков проектирования? Рисование схемы - это еще не вся работа, в проекте.

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

ЗЫ Да, ПЛИС я не проектировал, только проектирвал дизайны с ними. Правда не больше 3 ПЛИС при общем кол-ве компонентов до 5+ тысяч. Но дизайны на 12-ти ПЛИС видел, Вы не поверите - схемы нарисованы.

Оптимизируют. Это типа, меняют резисторы 5% на 1%, если проще достать последние, да? Или у обнаружили, что на севере девайсу нужны одни параметры, а на юге - другие, и меняют номиналы в зависимости от условий? Вы сами говорите, что они их ЧИТАЮТ. Отличное слово. Только читают обычно текст, а на схемы СМОТРЯТ и ВОСПРИНИМАЮТ. Опять все скатывается к привычке.
Допустим, какие-то компоненты трогать нельзя, а какие-то можно. Никаких проблем отразить это в тексте, верно?
Схема и HDL эквивалентны, просто это разные представления одного и того же. Выбор определяется только привычкой. Ну и текущими возможностями САПР.


Да, не нужна. При ремонте нужен т.н. сервис-мануал, а не схема. Там обычно пишут типовые неисправности и способы устранения. Все, никаких схем! Зачем (с) ему видеть схему? Чтобы понять, куда проводочек идет? Вместо этого делается поиск в тексте, и то - только если сильно надо и типовые рекомендации не помогают. Думаете, ремонтникам заняться больше нечем, как изучать все принципы функционирования изделия? Им чинить надо, они этим деньги зарабатывают. И как можно быстрее. Т.е. опять вопрос привычки.


Опять же, что будет, если Вы им скажете, что отныне Вы им присылаете не схему, а нетлист? Чем они смогут аргументировать отказ? Только тем, что у них все специалисты привыкли работать с графикой, и для них так лучше. Других аргументов быть не может, ибо, опять же, схема и нетлист эквивалентны.


Согласен, в этом основная проблема. В том, что пока это никому окромя нескольких сумасшедших не надо. В том, что ради этих мифических остальных этапов проекта затормаживается один из самых главных - собственно создание схемы\нетлиста. Т.к. за этот этап отвечаю я, то я и выбираю себе средства.


Нет уж. Неважно, что схема иерархическая? Неужели? А то, что иерархию надо разворачивать при распечатывании для прочтения вне САПР, это как, нормально? Получается офигенных размеров схема с бешеным количеством листов, на которых Ваш ремонтник\проверяющий\еще-кто-то-там будет искать свой несчастный R123 и идущий от него через все уровни иерархии проводочек? Какой смысл видеть это в графике, когда можно спокойно найти все текстовым поиском без всякого разворачивания иерархии?

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


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

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

Меня с института учили "читать" схемы, Вас видимо "воспринимать".

С чего Вы взяли, что понять принцип работы схемы удобнее из текста, а не из графического представления? Весь мир(кроме нескольких сумасшедших(С)) считает по другому...

Сервис-мануалы - это хорошо, только это доп. время/люди/деньги, на их создание. А сейчас деньги считать хорошо умеют.Так что схемы-платы-ВОМы и вперед...

Vitan, Вам вместо зарплаты, дадут бумажки с нарисованными цифрами. Чем Вы аргументируете требование все-таки выдать ее общепринятыми купюрами?

Этап по созданию схемы далеко не самый важный, как это ни прискорбно. Творческий - да, нужен - само собой, но не такой уж важный.

А вот тут уж, простите, взаимоисключающие параграфы(С). Т.е. распечатывать схему на пару-тройку десятков листов - проблема. А искать текстовым поиском в распечатанном тексте вообще не проблема? А если не распечатывать схему, то в графике поиск точно так же работает, как и в тексте.
Кстати об иерархии - я так понимаю, Вы хотите вс.ю схему описывать в одном файле? Никакого деления, никаких инклудов, дефайнов, переходов и вызовов? Т.е. те же несколько десятков страниц(как и в схеме) описалова резистор-кондер-диод-м/с и цепь NET001/002 и т.д.? И в чем глубокая ценность такого текста?

Обижаете... Я Вам на каждый пункт отвечаю, а не толдычу одно и то же, ничего не слушая. Где я Вас не выслушал и не принял в расчет?


Хорошо, что Вы кавычки все-таки поставили. Т.е. у Вас еще свое восприятие не убито окончательно. Вы же отлично поняли, что я имел ввиду, не цепляйтесь.


Где я говорил, что удобнее понимать по тексту? Я говорил только, что мне удобнее создавать в тексте. При этом я отлично понимаю, что большинству удобнее в графике. Только меня мнение большинства слабо волнует. Я хочу выполнять свою работу, а не работать на соседей и на следующие этапы. Я понимаю, что я одно из звеньев в цепочке, но не считаю своей обязанностью управлять этой цепочкой и связывать ее. При этом я по доброте своей все-таки предлагаю решение для соседей в виде генератора-визуализатора. Что не так в моей позиции?


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


Именно так. Вариантов два: распечатывание на бумаге и работа с компьютерным исходником.
При бумажном поиске, надеюсь, Вы согласитесь, что трудоемкость поиска фактически одинакова.
При работе на компе поиск компонентов по схеме и в тексте будет длиться одинаково, ибо и там и там они встречаются в одинаковом количестве. А вот с цепями проблема в графике. Чтобы найти, куда идет цепь на схеме, нужно глазами проследить весь ее путь, который может быть весьма разветвленным, учитывая еще и иерархию. А вот поиск в тексте занимает 3 секунды. Я, например, пользуюсь менеджером FAR, но это не суть. Нажимаю alt+F7 в каталоге с исходниками, пишу искомое название и оно выводит список всех файлов. Далее внутри файла поиск по пробелу с циклическим перебором. Файловый менеджер может быть любым, это понятно, думаю.


1. В скорости создания. Мышкой двигать зело долго.
2. В независимости от САПР. Если это будет не экзотика типа той, что я привел выше, а какой-нибудь стандартный верилог или вхдл.
3. В наличии кучи всевозможных вспомогательных средств начиная от контроля версий и форматирования под корпоративные стандарты и кончая системами моделирования.
4. В конечном счете, в унификации процесса разработки железа и софта. Больше однотипной документации (исходники) - проще автоматизировать процесс повышения качества.
Не достаточно?

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



А зачем соседям участник общей игры, который не принимает ее правила? Я уже в который раз напишу - самому для себя можно делать как угодно. Хотите менять правила - надо управлять процессом. А пока Вы работаете "на людей" - принимайте общие правила.

А затем, что других кандидатов нету. Кроме меня просто такую схему никто не нарисует в обозримом радиусе. Вот я и пользуюсь, и совесть меня нифига не мучит.
Я делаю продукт, а не разглагольствую. Т.е. результаты - мои. Да, я могу быть опасен для работодателя. Но я добрый. Гы.

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

Да я и сейчас не против обсудить этот вопрос. Только зачем (с) мне становиться заменяемым? Только для этого?

Ладно, оставим флуд, скажите лучше, упаковщик может генерить "схему" как это делает ментор (как я выше описывал)?

И еще, кто-нибудь знает, как запускать упаковщик из командной строки? Какие там должны быть ключи и что они означают? В хелпе пока нашел очень мало на эту тему (плохо смотрел?). Плюс, в проекте который выложил Ant_m я нашел файлик, в котором упаковщик запускается с ключами, которых вообще нету в хелпе...

В этом проекте довольно много файлов помимо верилога, которые можно спокойно интерпретировать как нетлист. Зачем (вот ведь зацепились ) там их столько? Может, там уже половина не нужна для 16.5?...

Uree, Вы не могли бы выложить подобный проект в 16.5 (ну или тот, что на скриншотах), чтобы мне понять, какие там файлы за что отвечают, и что ожидает меня в 16.5?

Чтобы ответить на этот вопрос нужно знать архитектуру САПРа "изнутри". А в хелпе нарисован только внешний каркас...
Проблема в том что там нет одного_большого_файла_в_котором_есть_все. Есть куча маленьких, которые каким то образом, с помощью утилит-интрументов между собой взаимодействуют. Без знаний этих связей вся эта работа мартышкин труд, перспективнее свой САПР сделать.
Помнится у меня было желание переименовать цепи в схеме, естественно не руками. Написал скриптик на sed - "найти это и заменить на это". Прогнал все файлы через скрипт - а вот фиг! Схема оказалась в итоге не рабочей. И пришлось руками это все делать

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


О, да... С этого я и начал, собственно...


Я верю, вот только непонятно, нафига им было такое чудить. Точнее, даже не это, а почему они такие серьезные изменения нигде не отразили. Вот ментор, когда сделал свой новый схематик версии 2007 все четко расписал, что, мол, теперь новая архитектура, она позволит то-то и то-то. Вопрос второй, что не всем это понравилось (и мне в т.ч.), но ведь написали же. А тут...

Кстати, Ant_m, Ваша попытка переименовать все в тексте - имхо зачатки перехода на HDL. Велкам!

Ant_m, а почему не воспользовались штатным средством? Есть же инструмент Global Property Change, меняет все и вся, повзоялет задать где менять, а где нет, поддерживает маски в наименованиях... бери да пользуйся. А в файлах не получится по одной просто причине - их не так много и большая часть из них текстовая, но есть и бинарники, причем для каждой страницы схемы. А в них просто замену текста уже не сделаешь.

В общем, вот что.

Файлы верилога в 16.5 действительно больше не генерятся. Вместо них генерятся некие XML. Они это чем-то невнятно мотивируют в хелпе, но до конца я не понял, зачем это им надо было.
Упаковщик использует на входе не верилог, как раньше, а этот XML.

Однако, мечта идиота может сбыться.
Оказывается, есть замечательный софт под названием SCM. И он-то способен (как и менторовский конкурент, кстати) на создание описания схемы в табличном виде. При этом отдельные блоки он может импортировать на верилоге. Итого для полного счастья мне надо описать на верилоге каждый блок и импортировать его в SCM.

Поддерживается прямой и обратный переход в\из PCB, своп пинов и констрейны.
Отдельно генерится схема, причем возможности настройки (на первый взгляд) превосходят менторовские.

Кроме того, возможности импорта-экспорта библиотеки УГО и партов присутствуют (ввели меня в заблуждение вначале), причем весьма неплохие.

Я очень рад. Кто-нибудь использует эту штуку в работе?

Потому что штатное средство слишком ограниченно.
Нужно было сделать что-то вроде: NETABC1, NETABC2, NETABC3 и т.д заменить на NET_ABC1, NET_ABC2... И таких цепей под сотню.
Вообщем то, что на regexp пишется в 5 символов, а в HDL Editor выливается в десятки тыканий мышкой по менюшке Global replace.
Меня вообще дико удивляет почему в cadence нет поддержки regexp? Ведь вроде в unix/linux это почти что базовая возможность!
p/s Методику, как можно применять regexp для цепей я все таки нашел, и писал об этом в своем каком то древнем посте...




А сцылку можно? А то гугл банит всякими Supply chain management.

Зачем гугл? Ищите в хелпе.

Да ну? Оно ограничено только тем, что само не вбивает за Вас название.
Я же писал, - поддерживает маски и шаблоны. Любые варианты "NETABC1, NETABC2, NETABC3 и т.д заменить на NET_ABC1, NET_ABC2" реализуются в один заход.

Наверное я привел неудачный пример.
Но вот, допустим, имеется 16 каналов. В каждом канале 4 сигнала: CH1_TX+; CH1_TX-;CH1_RX+; CH1_RX-; соответсвенно в последнем канале CH16_TX+ и т.д.
А нужно сделать замену символов CH на слово CHANNEL во всех сигналах и по всем каналам. Как сделать такую замену?
На regexp, для notepad++, это поиск по "(CH)([1-9].*)" и замена на "/1ANNEL/2".

Ок, понял, я тоже нотпадом пользовался:

Нажмите для просмотра прикрепленного файла

Выбираем редактирование имен во внешнем редакторе:

Нажмите для просмотра прикрепленного файла

Результат:

Нажмите для просмотра прикрепленного файла

На все про все - пол минуты.

Вот и я также делаю. Сейчас, когда уже знаю, а тогда пришлось руками это править...
p/s. схему можно полностью хранить в текстовых файлах, нужно только опцию генерации csb отключить. Не знаю, помогло ли бы это тогда - при замене с помощью sed или нет, а сейчас уже лениво эксперименты ставить.

Я когда-то экспериментировал с сохранением только в ASCII. Не помню точно какие, но точно помню, что были проблемы. То ли паковать не хотело при отсутствии бинарников, то ли еще что-то... В общем опция выключения записи тех файлов есть, но зачем и кому она нужна - не знаю. У меня только при наличии всех 4-х файлов все корректно работает.

Вопрос по Variant Editor.
Я могу оперировать в нем не отдельными компонентами, а блоками из иерархии проекта? Например, хочу не устанавливать в одном из вариантов какой-то блок (и все его подблоки тоже).
Можно ли также заменить блок на другой?

Еще вопрос по part manager.
Почему-то при открытии схемы, у которой view называется не sch_1, а например, docsch_1 (такое название генерит SCM), part manager не видит компонентов.
Если переименовать view в sch_1, то все работает.
Можно ли где-то настроить, из какого view он читает компоненты, чтобы не переименовывать вручную и не влезать нештатным образом в проект?

При импорте из EDIF значения номеров выводов на компонентах и другие атрибуты съезжают относительно их оригинального положения, причем сильно далеко в угол листа. Есть ли какая-нибудь команда, которая возвращает их обратно, как например команда Reposition symbol attributes в менторовском DxD?

Видимо это команда section дважды (или sec в консоли). Но есть одна подлость - команда работает с единичными сиволами. Т.е выделить всё и сделать section не получится. (Вообще эта команда делается автоматом при экспорте из схемы в плату, и обычно не нужна).
Можно еще попробовать replace symbol, она точно вернет атрибуты к состоянию библиотечного символа. Но, несмотря на то что ее можно применить ко всему выделеннуму, тут тоже будет нужен "индивидуальный" подход и куча времени...

p/s section назначает соответствие между физ. выводами и выводами символа. На другие атрибуты она не влияет...

Понимает и еще как ... По крайней мере при создании компонента, схемотехнического, создается каталог с его Вериложным или вехадеэльным определением
Там есть маршрут для FPGA - дизайна ...

Подскажите, есть ли тут некое окошко, в котором можно увидеть все компоненты с их рефдесами и другими свойствами? Чтобы клацнуть на компонент, и схема на нем открылась...
Part manager как-то не подходит. Кстати, зачем он нужен, что в нем можно делать?
UPD. Похоже, им таки можно пользоваться, проглядел менюшку.

А тогда такой вопрос. Что делать, если variant editor пишет при открытии, что failed to create the design view of <имя_проекта> ?
Ищу какой-нибудь лог, чтобы понять, что за ошибка, и не нахожу...

Мда. Предыдущий вопрос решился полной переупаковкой. В чем дело было, так и не удалось понять.

Теперь новая напасть. Пытаюсь в редакторе вариантов добавить альтернативные компоненты командой change value. Работает, но не для всех компонентов. Как назло не работает на резисторах и конденсаторах, хотя с резисторными сборками все нормально. Возникающее окошко с выбором альтернативных компонентов пустое, в строке статуса надпись:
Part RES-CHIP_0603 not found in PPT files. Уж чего только не делал, не могу понять, по какому критерию он их ищет, и почему не отображает в окошке...
0603 у меня - это PACK_TYPE. Есть другие компоненты с таким же по сути набором свойств, и PACK_TYPE тоже есть, и эти компоненты работают.
Что это может быть, никто не знает?