Меня тут тоже вопрос один с DC замучал. В проекте два модуля, модуль А при помощи команды generate (VHDL) многократно вставлен в модуль B. При попытки отсинтезировать DC почему-то генерит модули A_1, A_2, A_3 и т.д.(добавляет номер к названию модуля), а потом жалуется, что не может их найти. Скрипт синтезатора выглядит в общем виде так:
analyze {A.vhd, B.vhd}
elaborate B
link
uniquify
compile...

Что я не так делаю? Пробовал -flatten сделать, не помогло.

A_0, A_i - это процесс uniquify, необходимо, чтобы на каждый instance модуля был уникальный design.
Либо это процесс вставки generic-ов из VHDL, но тогда там в названии модуля получается что-то вроде initialnameofmodule_param1val1_param2val2_...

попробуйте действовать проще:
read_file -f vhdl A.vhd
read_file -f vhdl B.vhd
read_file -f vhdl/verilog ......
current_design B ; link
uniquify


если выдает ошибку на каком-нить из read_file/current_design/link на TOP, то тогда разбирайтесь с конкретными ворнингами/ошибками.
просто так дизайны не находить он не может, либо что-то с инстантиированием в rtl, либо еще что-то с синтезом.
также посмотрите переменную hdlin_auto_save_templates.
также, если хотите что-то синтезировать иерархически, то лучше, чтобы на этих уровнях иерархии не было generic-ов.

Я бы делал так:
analyze -f vhdl A.vhd
read_vhdl B.vhd
current_design B
link
uniquify
compile....

т.е. всему, что не топ, analyze. топу - read. elaborate не надо, read всех кого надо отэлаборирует.

И еще - что в search_path? есть в ~/.synopsys_dc.setup что-то типа того:

set work_lib_path "./work"
define_design_lib WORK -path $work_lib_path
set search_path {. ~/work/lib /opt/synopsys/dc/libraries/syn ./work };

Помогла команда ungroup, добавление в link_library звездочки (*) и удаление промежуточных файлов.
Но назрел следующий вопрос.
В area репорте есть строчка: Net Interconnect Area, имеющая нехилое значение. Я думал, что разводка в ASIC, где доступно много слоев металла, идет поверх ячеек. А DC, судя по всему, так не считает и площадь разводки подсуммирует к площади ячеек. Кто из нас неправ?
Или это он эту площадь (Total Area Count) в качестве математической абстракции выдает - для сравнения вариантов. Если это так, то как тогда оценить требуемую реальную площадь?

Сообщение отредактировал starley - Jan 30 2009, 09:57

Ну во первых в разных библиотеках и в разных технологиях предусмотрены разные методики разводки - бывает разводка в специально выделенных каналах, бывает разводка поверх. Во вторых - не каждый проект можно развести, установив все целлы вплотную друг к другу. В третьих - про net interconnect area указано в библиотеке, это свойство ее моделей разводки. В четвертых - юзайте топографикал моде, сами задавая set_utilization, и забудьте все вайрлоад-модели как страшный сон и все оценки будут как минимум на порядок точнее.

Если точно знаете, что разводка поверх и целлы вплотную - то возьмите чистую площадь ячеек, и поделите на 0.7...0.8 - получите реальную площадь. Но, еще учтите, что зачастую не площадь внутренностей определяет площадь кристалла, а периметр, необходимый для размещения IO-падов.

насколько я понимаю, информация для Net Interconnect Area берется из данных в .lib файле для wireload model.
число слабо нужное и слабо удобное для работы, обычно получается очень большое. report_area генерит в том числе и более полезную информацию:
Total cell area - просто сумма всех площадей ячеек, которые указаны в .lib файле. это как если бы вы раскатали сейчас раскатали нетлист
в топологию без добавления/убирания элементов/ресайзинга и тп со 100% утилизацией.
реально 70% утилизации в топологии имхо достаточно хороший показатель, но всё зависит от дизайна и технологии, конечно.
также DC делает разбиение на sequential (памяти и триггера) и логику в этом же репорте, полезность этих данных бывает сложно переоценить.

если хочется, можно модифицировать .lib файл так, что эта net interconnect area будет нулевой и цифры в прогрессе синтеза/репорте будут более адекватные.

topographical mode - это да, это круто как бы... и синопсис и кейденс в своих синтезаторах годах так в 2005-2006 стали уходить от
подхода анализа задержек нагруженных цепей через wireload model.
у кейденс такой подход afaik называется PLE (physical layout estimation) и он появился чутка раньше topographical mode.

что не дает полноценно перейти на -topo всегда и везде, это то, что они в версиях 2007+ вроде как придумали использовать исключительно
собственный(?) формат FRAM. 2006-й DC использовал .pdb, который можно было получить из .lib + .lef.
и если вендоры ну не предоставляют библиотеки с FRAM представлением, и не рвутся что-то менять/добавлять в их библиотеках - как быть?
что должно быть в этом .FRAM не особо очевидно... вроде как этот FRAM является нативным для milkyway, но есть ли возможность конвертить стандартные представления в него пока не ясно.

Сообщение отредактировал sleep - Jan 30 2009, 19:05

Milkyway читает LEF без проблем и запросто генерит FRAM. Сами так делаем для билиотек, в которых вендоры не делают FRAMы, а дают только LEF. Так, что пользуйтесь -topo

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

А что - plib/pdb flow убрали? Не знал. Вроде бы он работает до сих пор.

Касабельно FRAM - это абстракт ячейки - грубо то же, что и в LEF. Пины и зоны, запретные для трассировки. Делается одной левой например из полной топологии в виде GDS-II или из LEF.
Формат древний как мир, его еще Apollo юзал авантовский на заре веков, и я пока не встретил фаба, который бы не дал этого формата. Вот plib/pdb - да, редкость.

Milkyway есть в Astro, есть в star-rcxt, отдельно его нет.

видимо, в разных фабах тейпаутимся : )

Да не факт... Просто... Только сообразил. У меня либы все от Avant/Synopsys. А им грех не давать свой родной формат

plib/pdb - пройденный этап. Развития нет. PhysC его по прежнему понимает, но и этот тул-то уже вчерашний день (с точки зрения Synopsys). Надо юзать IC Compiler. Как я уже писал, 65нм еще идет в Astro, а под 45нм Synopsys будет поддерживать только ICC. Имеется в виду, что если фабрика родит какую-то совершенно новую DRC норму (типа треугольного VIA ), то Synopsys не будет апдейтить Astro под эту норму.

Milkyway (FRAM) - некоторые библиотечные вендоры (не фабы) его не поставляют в своих либах. типа LEFа/GDSа достаточно, а дальше сами нагенерите че хотите (например Dolphin Tech не даёт FRAM). Да это и не проблема - легко можно сгенерить. Кстати, как говорит Synopsys, у них скоро должна выйти замена Milkyway базы данных. Будет что-то новое, да еще и откроют её для всех желающих (используйте в своих САПРах). Но это так, слухи.

По поводу либов от Avant/Synopsys - ностальгия, я к их разработке когда-то руку прикладывал. Давно это было.

Ну судя по кастом дизайнеру (а новее средства не придумать) - они OA поддержали. Типа "будем дружить с кэденсом" И вот еще что пишут...
"Custom Designer's Open Infrastructure (CDOI) is a shift in the EDA industry offering unfettered access to your design data. With no proprietary languages, databases or extensions, Custom Designer offers CAD groups deep visibility into the system's design infrastructure enabling high-performance application integration and development including access to in-memory data and runtime objects"

Топографикал это хорошо, но вот как мне ему блоки памяти, сделанные синтезатором, подсунуть?


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


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

Каждая IO-cell должна включать контактную площадку, логику и ESD-защиту. Обычно так.