Привет всем!

Прошу немного помочь местных гуру относительно нижеследующего:

Решил немного разобраться с ASIC. Про Линукс посредственные знания. Хочется запустить Synopsys DC и поработать с ним. Отсюда вопросы:

1. Что взять из закромов чтобы установить данный пакет. (Желательно пути до файлов)?
2. Какой комп и ОС для этого необходимы?
3. Может быть есть инструкция по инсталяции данной софтины и вообще мануалы по работе с ней?

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

Пока вроде все. Сильно ногами не пинайте если что не так. Заранее спасибо.

1.вам нужен пакет syn. в eda/_synopsys_ берите самый последний(2008.09) там же посмотрите файлик для генерации lic src-2008.09 + Efa_LicGen_0.4b
2. suse 10.1 (32-64b) Centos 4.6(32-64) это те на которых я работал
3. пакеты нужно разархивировать. читать файлик readme в корне/
документация по продуктам в пакете sold

На Debian тоже без проблем ставится. Хотя лучше всего на RedHat.

Именно с DC не работал, но думаю как для любой программы Synopsys нужно:
установить переменную LM_LICENSE_FILE = <путь_до_лиц._файла>,
переменную SYNOPSYS=<путь_до_корневой_папки с программой>
в линуксе переменную окружения $path (к существующей $path добавить путь до 'dc_shell' чтобы система его находила)

Вроде бы все. Чтобы не поиметь лишних проблем, лучше ставить REDHAT
Могу скинуть User_GUIDE на DC свеженький(сент.2008) если нужно

спасибо всем!
Буду тернить к звездам



Спасибо, если не затруднит. Мейл: amigateam(обезьяна)yandex.ru

4. Туда же разархивировать installer, взятый оттуда же, еда/сунопсус.
5. Запустить этот инсталлер из-под рута, он все сделает.

пункт 3 не обязателен, инсталлер сам умеет разархивировать пакеты. Если пакеты разархивированы вручную, то архивы стереть.
пункт 1 - для генерации кроме этого нужен еще SSS Feature Keygen. Для 2008.09 обязателен.
пункт 2 - FC4 x86_64 smp тоже без проблем. Это та, на которой я работаю.

касаемо юзер гайдов - они все есть на фтп, входят в состав пакета с названием sold. (synopsys online documentation)

Да, спасибо, ценная подсказка.

Может кто-нибудь тогда выложит курсы(лабы) от synopsys? интересны будут :
ces_astro
ces_dc
ces_ic_compiler
у меня есть, но только они неполные и за 2005

Влил весь свой запас. Сорри только, там внутри архива китайские буквы в именах есть

спасибо. а pdf-ок случайно к лабам нету? таких как Astro_StudentGuide

не, это все, что еть

залил в eda_syn лабы и pdf-ки к ним(astro ic dc). + пару тренингов по синтезу + книга
asic-synopsys_advanced.asic.chip.synthesis.using.synopsys.design.compiler.physical
если есть недокаченные файлы - сообщите.

Спасибо!
Но у меня не открывается synthesis_training/Synthesis.pdf
(скачивал два раза)

запаковал и перезалил. постоянные обрывы связи

Спасибо! теперь все нормально.

Меня тут тоже вопрос один с 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) в качестве математической абстракции выдает - для сравнения вариантов. Если это так, то как тогда оценить требуемую реальную площадь?

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

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-защиту. Обычно так.

>Топографикал это хорошо, но вот как мне ему блоки памяти, сделанные синтезатором, подсунуть?
А точно так же, как подсовываете библиотеку std cell. Есть .db файл, добавьте в link/target_library. Есть Milkyway - добавьте как reference.

> и вся разводка, по определению, поверх ячеек. Это не так?
Обычно этого не хватает. Там еще присутствует разводка земли/питания, клоковские деревья. Если std cell обычно использует внутри только первый метал, и разрешает разводку в остальных над собой, то память может использовать и 4 и 5 металлов. Да еще может запретить разводку сигнальных проводов над собой, чтобы избежать наводок (cross talk). Так, что , после синтеза (до размещения) суммарную площадь ячеек нужно умножить на два (это с запасом, потом при размещении, площадь ячеек вырастет, и core utilization будет меньше) - это и будет примерная площадь (core area). Chip area может определятся (как уже заметил SM) не только core area, но и периметром необходимым для размещения IO падов (это если Вы используете pad ring, а не flip chip pads).

> Каждая IO-cell должна включать контактную площадку, логику и ESD-защиту
Не всегда так. Если библиотека содержит так называемые staggered pads, то контактные площадки шире чем сам IO cell. В этом случае IO селы ставят впритык, а контактные площадки в шахматном порядке в два ряда. Это позволяет уменьшить периметр чипа. Если у вас обычная либа (inline pads), то приведена, скорее всего, суммарная площадь ячейки+площадки. Вам лучше посмотреть в топологическом редактора на эту площадку или повнимательнее почитать даташит, что это за площадь - ячейки с площадкой или без.

Сделанные кем? Синтезатором? Может мемори компилером? Так сделайте тем же компилером FRAM-ы, или LEF, или что он там делает для PAR.

Понятия не имею. Читать доку на либу. Смотреть глазами топологию ячеек. Других способов не знаю.

Может включать, может не включать. читайте, блин, доки на либы. Или гляньте на топологию ячейки. У меня есть одна либа, где буфера отдельно, пады отдельно, и можно их собирать как и в staggered, так и в linear. А другая - только linear, и там все включено. А по хорошему - не надо считать IO-пады в area вообще. Они как не крути займут весь периметр чипа, даже если там не все будет забито падами, придется добивать филлерами. Или наоборот, падов может оказаться столько, что внутри периметра будет куча лишнего места. Ее, площадь этого периметра, проще посчитать на обычном калькуляторе. Или у вас там флипчип?

Кабы там было написано нормальным английским языком, что включает, - не задавал бы лишних вопросов. Я думал, что спецы по площади смогут определить, включен пад или нет. Размер ячейки 245 на 40 мкм.
Из отсутствия отдельной ячейки для пада следует, что они включены?
Топологию бы посмотрел, но редактора нет, да и пользоваться им пока не умею


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

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

40 мкм... Это что, пад получается примерно 30 мкм сторона? Не маловато ли... Похоже, что не включены. Так как 2*40 получается 80, а это уже ближе к делу в случае staggered расположения. Таким образом два пада будут занимать примерно 325х80. Но может хватит гадать? Не верю, чтобы в доках на либы об этом не было.

Да. Но как-то не сходится с 40 мкм...

предположу, что единственно верным ответом о конструкции падов будет просмотр их gds )
вьюверов gds-в достаточно много, некоторые ну очень простые.
плюс всё-таки имхо соотношение сторон абстракта указывает, что bonding pad уже включен...
похоже на 018 микрон как бы...
работал с 240*50 по 018 - это уже были staggered cо включенным bonding pad. 240*70 - inline.
если 013 - то может и без bonding-а. если так - сами bonding pads дорисовываются дизайнером "ручками".
можно создать конфигурацию хоть inline, хоть staggered; понятно, что расставляются они скриптами.

насчет доступности трассировки по падам - часто делают кольца внутри падов в нескольких металлах, и выводы питания/земли в сторону core выводят в нескольких доступных металлах.
следовательно, сигнальная трассировка над падами запрещается.

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

Не поленился-таки вчера поставить Astro и посмотреть топологию. Итог - пады не включены, для них отдельная ячейка про которую в описании ни слова. Как в астро можно определить размеры этой ячейки?
Если я правильно понимаю, то примерную площадь под ИО при линейном расположении надо считать так: (ширина пада + ширина выходного буфера)*периметр. Для staggered - (2*ширина пада + ширина выходного буфера)*периметр. Правильно?



А это не сильно круто? С чего ей в два раза вырасти, не из дерева же синхросигналов? Глобальная разводка земли и питания идет в первом слое металла?

очень просто, на каждый io cell есть его 2 варианта: обозначим их условно "S" и "T", то есть "короткий" и "длинный". bonding pads уже включены в габариты, но перекрытие или "двухрядность" получаются видны только при переходе lef-gds. на .lef-представлении просто стоящие плотно друг к другу более длинные и более тонкие по сравнению с inline пады.
при нормально сделанном .lef расставляем их на стороне по очереди: STSTS... получаются staggered io.

> (ширина пада + ширина выходного буфера)*периметр. Для staggered - (2*ширина пада + ширина выходного буфера)*периметр.
Это правильно.

> С чего ей в два раза вырасти

1. разводка земли и питания должна как минимуи идти в двух слоях (вертикальном и горизонтальном). Первый метал практически весь занят std cell. Если у вас длинный ряд из этих ячеек, а подключаете питание только по краям ряда, то будут помехи по питанию. Вдобавок, пин питания памяти памяти, я думаю, не в первом металле, к ним тоже надо подключится широкой шиной. И желательно не одной, а рингом или сеткой. Да и пады земли/питания тоже выдают не в первом металле. Например мы делаем сплошную сетку земли питания (очень частую) в двух верхних металлах (и запрещаем сигнальную трассировки в них), а дальше спускаемся до первого металла через более редкую сетку. Есть специальный тулы, которые помогают оценить, достаточно ли вы сделали шин земли питания (например Astro-Rail).

2. Хоть вы и используете DC -topo, реальное размещение (сделанное, например, в Astro) будет отличатся от первоначального. Соответственно, и ячейки будут умощнятся (расти в размерах) и дополнительные буфера будут вставляться. Это из личного опыта.

3. Потом, вам, наверняка, нужно будет вставлять специальные ячейки (tap-cell) для подклячения питания к карману (если, конечно, во всех std cell не сделано это).

4. А добавлять spare cells вы будете? (это чтобы, потом после изготовления, если выявится ошибка в логике, можно было бы изменением одной маски (перекомутацией пары ячеек) исправить ошибку)

5. А после трассировки могут появится проблемы с cross talk (хотя на 0.13 они невелики), следовательно, трассировщик будет раздвигать параллельные трассы, делать shielding или еще что.

6. Да мало ли что еще потом придется добавлять. По моему опыту, если проект новый и большой, то core utilization 0.5 после синтеза это нормально. А к детальной трассировке он повысится до 0.7. Я лично не встречал серьёзных дизайнов, которые бы развелись при utilization > 0.8

Открыть FRAM или CEL view ячейки, и в астровском просмотрщике слева внизу есть жирная кнопка "Ruler". Далее интуитивно


Принцип понятен, просто не встречал такого. А в .lib указана площадь по lef/FRAM? Или по gds/CEL? А то как бы topo не начал орать, что одно с другим не сходится...

Тогда получается, что разводка питания не увеличивает требуемую площадь.


Я думал, что во всех нормальных библиотеках это сделано в ячейках.


Не будем. Во-первых, у нас еще две итерации, помимо этой, а, во-вторых, наши исполнители топологии не делают, ее буржуи делать будут.


Неужто трассировщик и перекрестные помехи учитывает? Я думал для этого специальный софт используется.


Ну 0.7 это все же не 0.5.


Спасибо, попробую.

Еще как увеличивает. Не думайте, что если там есть куча слоев, то их всех не забъет трассировщик напрочь и ему их с легкостью хватит.

А в процентах?

Я вот работаю с 4-мя металлами. Забивает в критических местах на все 100% только в путь, что приходится раздвигать. Вообще это очень сильно от проекта зависит.

в .lib на staggered пады площадь стратежно указана 0.000. в .lib и .lef на inline площадь, логично, указана и сходится.

Для конвертации LEF в FRAM в милкивее требуется указывать помимо самого конвертируемого файла еще и файлы, которых технологическая информация извлекается (Tech LEF) и файл для соответствий номеров слоев и их названий. Сразу два вопроса по этому поводу.
Нафига ему номера слоев, если при создании библиотеки он уже запрашивал tech файл, в котором эти номера уже и так есть?
Мой генератор памяти помимо самого LEF для блока генерит еще и LEF для проверки "antenna rules". Его тоже подсовывать милкивею? Зачем вообще FRAM описании эта информация нужна? Чтобы случайно не добавить лишнего металла в первом слое, вызвав нарушение оного правила?

Про соответствие слоев - это соответствие слоев в LEF (и с геометрией, и с технологией) тому, что будет во FRAM, там же не обязательно те же номера должны остаться.... Про то, что это за антенный LEF, я к сожалению не знаю.

Под "LEF для проверки "antenna rules" ", наверное имеется ввиду .lef, в котором находится информация только по ANTENNADIFFAREA и ANTENNAGATEAREA (вроде так эти параметры в .lef называются) для пинов блоков. Эти данные нужны для проверки и исправления антенного эффекта.
А в отдельном .lef вся основная информация для блоков(OBS, все полигоны и др).
Соответственно, ответ на 2 вопрос - если Вы собираетесь исправлять антенный эффект в туле, которому скармливаете FRAM, - то знание об антенных свойствах пинов блоков ему нужны и конвертировать данный .lef в FRAM необходимо.

FRAM же это чистая графика. Так что вряд-ли это получится

Получится, правда не знаю, где будет хранится эта информация (в самом FRAM или в lib), но такая инфа должна присутствовать в Milkyway db. Другой путь запихивания её в Milkyway это через clf файл (команды dbDefineAntennaRule, dbAddAntennaLayerRule, defineGateSize, defineDiodeProtection.

Если вы загрузите antenna LEF, а потом выгрузите clf, то должны увидеть какие-то из этих команд.