Прошу немного помощи по Synopsys DC Опции

[Jools]

Привет всем!

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

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

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

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

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

[Losik]

Привет всем!

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

Решил немного разобраться с 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

[starley]

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

[designner]

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

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

[Jools]

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

Могу скинуть User_GUIDE на DC свеженький(сент.2008) если нужно

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

[SM]

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 в корне/

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

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

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

[Jools]

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

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

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

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

[Losik]

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

[SM]

у меня есть, но только они неполные и за 2005

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

[Losik]

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

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

[SM]

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

[Losik]

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

[Кнкн]

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

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

[Losik]

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

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

[Кнкн]

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

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

[starley]

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

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

[sleep]

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

[SM]

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

Я бы делал так:
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 };

[starley]

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

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

[SM]

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

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

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

[sleep]

насколько я понимаю, информация для 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

[oratie]

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

[sleep]

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

[SM]

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

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

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

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

[sleep]

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

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

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

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

[SM]

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

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

[oratie]

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 - ностальгия, я к их разработке когда-то руку прикладывал. Давно это было.

[SM]

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

Ну судя по кастом дизайнеру (а новее средства не придумать) - они 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"

[starley]

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

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

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

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

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

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

[psygash]

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

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

[oratie]

>Топографикал это хорошо, но вот как мне ему блоки памяти, сделанные синтезатором, подсунуть?
А точно так же, как подсовываете библиотеку 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), то приведена, скорее всего, суммарная площадь ячейки+площадки. Вам лучше посмотреть в топологическом редактора на эту площадку или повнимательнее почитать даташит, что это за площадь - ячейки с площадкой или без.

[SM]

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

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

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

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

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

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

[starley]

Может включать, может не включать. читайте, блин, доки на либы.

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

Или у вас там флипчип?

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

Сообщение отредактировал starley - Feb 2 2009, 20:51

[SM]

Топология стандартной ячейки занимает не больше 2-3 слоев металла. Доступно 6. С какого бодуна разводка может идти не поверх ячеек? При чем тут библиотека и доки на нее?

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

Размер ячейки 245 на 40 мкм.

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

Из отсутствия отдельной ячейки для пада следует, что они включены?

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

[sleep]

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

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

[SM]

работал с 240*50 по 018 - это уже были staggered cо включенным bonding pad.

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

[starley]

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

суммарную площадь ячеек нужно умножить на два

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

[sleep]

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

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

[oratie]

> (ширина пада + ширина выходного буфера)*периметр. Для 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

[SM]

Как в астро можно определить размеры этой ячейки?

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

но перекрытие или "двухрядность" получаются видны только при переходе lef-gds. на .lef-представлении просто стоящие плотно друг к другу более длинные и более тонкие по сравнению с inline пады.

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

[starley]

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

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

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

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

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

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

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

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

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

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

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

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

[SM]

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

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

[starley]

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

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

[SM]

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

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

[sleep]

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

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

[starley]

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

[SM]

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

[sleep]

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

[SM]

то знание об антенных свойствах пинов блоков ему нужны и конвертировать данный .lef в FRAM необходимо.

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

[oratie]

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

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

[grigorik]

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

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

Если вы загрузите antenna LEF, antenna info будет хранится в самом FRAM.
Tochno, Если вы потом выгрузите antenna clf то должны увидеть какие-то из этих команд.
Eto zavisit eshyo iz versii Milkyway. Est takie kommandi v LEF chto starie versii Milkyway ne poderjivayut.

[starley]

Есть несколько проблем при синтезе в топографическом режиме. DC в логе выдает несколько сообщений о том, что не может выполнить констрэйны на макроблоке. При этом в тайминг репорте никаких проблем не обнаруживается. Кроме этого, есть сообщение о таймауте выполнения размещения элементов. Хотя несколько других проходов завершены нормально. Что это с ним? И вообще интересно как он размещает автоматически макроблоки?
Еще сложилось впечатление, что без плана кристалла (floorplan), синтез в топографическом режиме вещь несколько отвлеченная. В чем лучше его делать в Юпитере или в Астро?

[grigorik]

Kogda vi govorite макроблок vi imeite vvidu hard macro ? vi dali .db v link_libarary ? U vas est FRAM dlya makro block?
Dlya makroblokov vi mojete dat koordinati sami po komande set_cell_location.
Chtobi ponyat problemu davaite log syuda posmotrim (esli eto vi xotite konechno).
Floorplan mojno i sdelat v DC topographical. Budet xorosho esli vi dadite DC topo tot floorplan kotori budete ispolzovat vo vremya okonchatelnogo P&R.

JupiterXT eto dlya hierarchich designs.
Astro dlya flat designs.
Tak chto zavisit iz vashego designa.

Udachi

[starley]

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

Сообщение отредактировал starley - Feb 28 2009, 20:29

[grigorik]

DC topo umeyet i mojet raspolagt makro bloki. No kak vi znayte vi ne smojete uznat kuda DC topo postavil macro block, i drugie celli.
Pro ierarxhicheki design vi pravi, dobavlyu v Jupitere mojete sozdat floorplan top designa i potom Jupiter iz floorplana topa poluchit floorplani vsex child design ov. Eshyo Jupiter is constraintov top -a poluchit constrainti child blokov kotorie vi budete ispolzovat dlya otdelnix blockov.
Tak chto esli u vas malenki block i ne nujno sdelat vishe skazannoe to vi smojete sdelat floorplan v Astro.

[starley]

DC topo umeyet i mojet raspolagt makro bloki. No kak vi znayte vi ne smojete uznat kuda DC topo postavil macro block, i drugie celli.

Похоже, вы правы. А Physical Compiler умел PDEF писать. Тогда получается, что от умения ДЦ расставлять макроблоки толку почти никакого. А из каких же тогда соображений расставлять макроблоки вручную - почти от балды что-ли?
И вообще, мне тогда не понятен смысл топографического синтеза. Получается, что задержки вычисляются и дизайн оптимизируется для одного расположения ячеек, а после бэк-энд расположение будет совсем другим. Понятно, что это лучше чем wireload, но почему нельзя было сделать возможность выгрузки хотя бы координат макроблоков?

Pro ierarxhicheki design vi pravi, dobavlyu v Jupitere mojete sozdat floorplan top designa i potom Jupiter iz floorplana topa poluchit floorplani vsex child design ov. Eshyo Jupiter is constraintov top -a poluchit constrainti child blokov kotorie vi budete ispolzovat dlya otdelnix blockov.

Стало быть придется еще и с Юпитером разбираться

[starley]

Вот фрагмент лога, который меня смущает. Ослабление временных констрейнов не помогает. Констрейны на размещение пока никакие не задавал.

CODE

Information: Running stand-alone coarse placer in a separate process (PSYN-605)
Information: Executable name is '/usr/synopsys/Z-2007.03-SP1/linux/syn/bin/rpsa_exec'. (PSYN-877)
...25%...
Warning: Placer unable to satisfy constraints on macro cell fc_apb_unit_i/EmptyBuffers_FIFO_I/dp_memory32x1024_i1. (PSYN-362)

Warning: Placer unable to satisfy constraints on macro cell RxData_FIFO_I/dp_memory32x2048_i1. (PSYN-362)

Warning: Placer unable to satisfy constraints on macro cell axi_slave_write_channel_i/TX_Messages_FIFO_I/dp_memory64x512_i. (PSYN-362)

Warning: Placer unable to satisfy constraints on macro cell FC_Sequences_Controller_i/transmitting_sequences_i/abts_performer_i/abts_context_memory_i/Context_Memory_i/U2. (PSYN-362)

Warning: Placer unable to satisfy constraints on macro cell TxData_FIFO_I1/dp_memory32x1024_i1. (PSYN-362)

Warning: Placer unable to satisfy constraints on macro cell TxData_FIFO_I/dp_memory32x1024_i1. (PSYN-362)
50%...75%...100% done.
Information: Running stand-alone coarse placer in a separate process (PSYN-605)
Information: Executable name is '/usr/synopsys/Z-2007.03-SP1/linux/syn/bin/rpsa_exec'. (PSYN-877)
...13%...25%...
Warning: Placer unable to satisfy constraints on macro cell fc_apb_unit_i/ReadyBuffers_FIFO_1_I/dp_memory32x1024_i1. (PSYN-362)

Warning: Placer unable to satisfy constraints on macro cell fc_apb_unit_i/Ports_Table_LSW_I/mem. (PSYN-362)

Warning: Placer unable to satisfy constraints on macro cell axi_slave_write_channel_i/TX_Messages_FIFO_I1/dp_memory64x512_i. (PSYN-362)

Warning: Placer unable to satisfy constraints on macro cell axi_slave_write_channel_i/TX_Messages_FIFO_I/dp_memory64x512_i. (PSYN-362)

Warning: Placer unable to satisfy constraints on macro cell LS_TxData_FIFO_I/dp_memory32x512_i1. (PSYN-362)

Warning: Placer unable to satisfy constraints on macro cell TxData_FIFO_I/dp_memory32x1024_i1. (PSYN-362)
38%...50%...63%...75%...88%...100% done.

[SM]

Возможно, слишком большая утилизация (set_utilization) стоит, и оно не может все правильно разместить с таким требованием к утилизации.

[starley]

Возможно, слишком большая утилизация (set_utilization) стоит, и оно не может все правильно разместить с таким требованием к утилизации.

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

[grigorik]

Похоже, вы правы. А Physical Compiler умел PDEF писать. Тогда получается, что от умения ДЦ расставлять макроблоки толку почти никакого. А из каких же тогда соображений расставлять макроблоки вручную - почти от балды что-ли?
И вообще, мне тогда не понятен смысл топографического синтеза. Получается, что задержки вычисляются и дизайн оптимизируется для одного расположения ячеек, а после бэк-энд расположение будет совсем другим. Понятно, что это лучше чем wireload, но почему нельзя было сделать возможность выгрузки хотя бы координат макроблоков?


Стало быть придется еще и с Юпитером разбираться

Voobshe-to zavisit ot kolichestvo makro blokov. Esli ix u vas slishkom mnogo i vi ne smojete naiti optimalnie mesta dlay makro blokov vruchnuyu to ya bi posovetoval takoe
Iteration: #1 synthesis v DC topo bez constrantov na macro blocki i avtomaticheski sdelat macro placement v back end tool(Astro ili ICC). Posle chego vi smojete uznat priblizitelnie coordinati macro blockov. Iteration: #2 Vospolzuites etimi coordinatami v DC topo i sdelaite eshyo odin synthesis. Vospolzuites tem je coordinatami macro blockov v back end i sdelaite place and route.

смысл топографического синтеза sostoit v tom chto resultati ICC placement i DC topo placemnt korrelirovani (mojed i daje odno i samoe ya ne uveren na 100%). Vot i eto privodit k tomu chto back end raspolojenie ne budet dast drugie resultati.
Pro etot vopros: но почему нельзя было сделать возможность выгрузки хотя бы координат макроблоков? Sprosite synopsys -a.
U synopsysa daje est novinka DC dlya congestion optimization vo vreamya RTL synthesis. Eto kakoi to enhancement v DC topo daje est greficheski vozmojnosti v DC vi mojete uvidet congested mesta.

Udachi.

[starley]

Iteration: #1 synthesis v DC topo bez constrantov na macro blocki i avtomaticheski sdelat macro placement v back end tool(Astro ili ICC). Posle chego vi smojete uznat priblizitelnie coordinati macro blockov. Iteration: #2 Vospolzuites etimi coordinatami v DC topo i sdelaite eshyo odin synthesis. Vospolzuites tem je coordinatami macro blockov v back end i sdelaite place and route.

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

[SM]

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

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

[oratie]

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

[SM]

А вот интересно, DC Graphical это отдельная приблуда, или просто фича обычного DC Topo?

[starley]

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

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

[grigorik]

А вот интересно, DC Graphical это отдельная приблуда, или просто фича обычного DC Topo?

Eto kakoi add on na sushestvuyushii DC topo. Kak ya ponyal licenzia nujna.

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

Da eto ojidayemi resultat. poskolku tooli ne silni dlya macro placementa. Luchshe samim posmotret leyaout i postavit tak chtobi dlina routinga bila naskolko vozmojna korotkoi.

[SM]

Eto kakoi add on na sushestvuyushii DC topo. Kak ya ponyal licenzia nujna.

Лицензия не вопрос. Главное - это отдельно устанавливаемый пакет, или оно уже включено в пакет syn ?

[grigorik]

Лицензия не вопрос. Главное - это отдельно устанавливаемый пакет, или оно уже включено в пакет syn ?

оно уже включено в пакет syn, topographical shell (dc_shell-topo).

[SM]

оно уже включено в пакет syn, topographical shell (dc_shell-topo).

Хм. А доки на этот режим есть? Хотелось бы узнать, как им пользоваться, но sold у меня всего лишь 2007.09, и там ни слова.

[grigorik]

Хм. А доки на этот режим есть? Хотелось бы узнать, как им пользоваться, но sold у меня всего лишь 2007.09, и там ни слова.

doka netu. sorry.
sam ne proboval ya prosto sleju za novosyam u synopsysa vot tut
http://www.synopsys.com/Tools/Implementati...rGraphical.aspx

[Losik]

Хм. А доки на этот режим есть? Хотелось бы узнать, как им пользоваться, но sold у меня всего лишь 2007.09, и там ни слова.

DC-topo Synthesis Training

Прикрепленные файлы

 DC_ultra.pdf ( 1.95 мегабайт ) Кол-во скачиваний: 57

 

[SM]

DC-topo Synthesis Training

Пожалуйста, будьте внимательнее. Я не просил документации и тренинга по topographical, я в нем работаю уже года полтора.

[starley]

Назрел тут еще один вопрос.
А как правильно определять DRC констрейны, в смысле, исходя из каких соображений? Например, в доках рекомендуется задавать либо max_fanout и max_transition, либо max_fanout и max_capacitance. Какой вариант лучше и как выбрать значения? Или можно положиться на заданные в библиотеке значения?
Что делает DC при обнаружении нарушения DRC?
Еще непонятно в чем смысл приоритетов этих констрейнов. Например, max_transition имеет приоритет над max_fanout. По смыслу ведь все констрейны должны быть выполнены, какие тут могут быть приоритеты?

Сообщение отредактировал starley - Mar 20 2009, 07:23

[oratie]

Если max_tran не определён в либе, то DC использует max tran из индексов для LUT. То, есть тот диапазон, в котором была отхарактеризована ячейка (то же самое и для max_cap).

Какой ставить max_tran
- обычно характеризуют ячейку на больший диапазон, поэтому полагаться на max tran из LUT индекса не стоит, ставить на поменьше. Чем меньше ставите, тем меньше проблем будет с cross-talk, но взамен увеличивается мощность, площадь и т.д. Строгих рекомендаций, какой ставить max_tran нет. Для начала возьмите половинку от max tran из индекса.

Какой ставить max_fanout
- посмотрите в библиотеке, прописаны ли там fanout_load для входных пинов (или только capacitance) - если нет, то надо использовать max_capacitance. Если есть, то используйте max_fanout из либы. Если и его нет - тогда вопрос (я использую 30 для внутренних цепей)

Какой ставить max_cap
- можно оставить, тот какой есть в либе (если его нет, то тул сам поставит его равным max cap из LUT индекса).

Подводя итог:
- max_cap и max_tran не могут быть большо чем max индексы для LUT
- никаких методик по определению этих констрэйнтов я не встречал - ставьте их исходя из своего дизайна - он у вас high-speed либо low power либо ещё чего.

[SM]

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

И про max_tran - все это почти так... Но... Если не дай бог этот сигнал идет на клоковый вход кого либо, то и max_tran должен быть жестко соблюден исходя из требований этого клоковхода. Ну или если строятся всякие хитрые конструкции из логики с обратными связями, типа PFD например.

[starley]

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

[oratie]

> Можно ли как-нибудь определить какой именно DRC констрейн нарушен и где?

report_constraint -all_violators

> А насколько обычно далеки результаты синтеза в топографическом режиме DC

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

[SM]

То есть действуем тут методом подбора до тех пор пока не удастся развестись на нужную частоту и нулевую сумму DRC.

В общем - да. Экспериментируем с разными там set_flatten, set_structure, set hdlin_xxxxx = ???, set compile_xxxxx = ?, ну и т.д. Так же правим исходники по результатам отчетов по критическим путям...

Что означает, если эта сумма после процесса оптимизации ненулевая - задачка решения не имеет? Можно ли как-нибудь определить какой именно DRC констрейн нарушен и где?

Это все в общем прикидки. Решение рассматривается исключительно после разводки - там в графике все будет видно как на ладони, где и что нарушилось, и там же in-place чаще всего можно их и пофиксить. А на небольшие нарушения рулезов при синтезе можно просто забить.
Какой где нарушен - report_cons -all_v

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

А по опыту с lattice - то после synplify тайминги +-10%, А после прецижена - хуже раза в три, чем он предсказал. Этот опыт совершенно не о чем.

А насколько обычно далеки результаты синтеза в топографическом режиме DC от того, что будет получено после разводки?

плюс минус процентов 10. Причем вот три разные итерации, в двух улучшение от предсказанного, в одной ухудшение.

[starley]

Временные констрейны начинают выполняться только при установке max_trans и max_cap в районе их минимально допустимых значений. Это чревато еще чем-нибудь, кроме увеличения площади, потребляемой мощности и возможных проблем с наводками?
Небольшие нарушения рулезов это порядка нескольких процентов или как?
И еще вопрос (извиняйте если глупый) может ли transition_time для клока внутри микросхемы быть меньше фронта синхроимпульса подаваемого на ее вход?

[SM]

Временные констрейны начинают выполняться только при установке max_trans и max_cap в районе их минимально допустимых значений. Это чревато еще чем-нибудь, кроме увеличения площади, потребляемой мощности и возможных проблем с наводками?

совершенно не понял вопроса. И вообще - все эти рулезы описаны в либе, обычно их крутить не надо. С какой целью Вы туда сунулись?

Небольшие нарушения рулезов это порядка нескольких процентов или как?

Ну как-то так... Замкнутый круг... Такие, которые можно при PAR пофиксить

И еще вопрос (извиняйте если глупый) может ли transition_time для клока внутри микросхемы быть меньше фронта синхроимпульса подаваемого на ее вход?

Легко. Особенно если IO-пад с триггером шмитта воткнуть. Так тогда вообще на вход ей можно будет синус полать.

[starley]

совершенно не понял вопроса. И вообще - все эти рулезы описаны в либе, обычно их крутить не надо. С какой целью Вы туда сунулись?

Приехали... Я ж про эти констрейны и спрашивал, надо ли их менять и из каких соображений. Из док и объяснений oratie я понял, что эти констрейны можно менять в сторону ужесточения. В моем случае это положительно влияет на тайминги. На самом деле так не надо делать?

У меня DC topo делает последние 3 шага оптимизации (Timing, DRC, Area) 2 раза с запуском расстановщика перед каждым шагом. Второй шаг начинается с площадью, полученной по результатам первого шага, но с другими задержками и DRC стоимостью. Это он влияние межсоединений посчитал или что-то другое?
В доках пока не нашел описания процесса оптимизации для топографического режима

Сообщение отредактировал starley - Mar 23 2009, 16:21

[SM]

Приехали... Я ж про эти констрейны и спрашивал, надо ли их менять и из каких соображений. Из док и объяснений oratie я понял, что эти констрейны можно менять в сторону ужесточения. В моем случае это положительно влияет на тайминги. На самом деле так не надо делать?

Да, можно, конечно, но я еще не встречал, чтобы это было реально нужно. Он же сам умеет за счет area улучшить timing в процессе оптимизации, что автоматом может уменьшить емкостную нагрузку в критическом пути. А влияния этого параметра на потребляемую мощность я особо не вижу, так как увеличивая емкость растягиваем переходной процесс, но при этом и уменьшаем количество драйверов (на один драйвер даем больше нагрузки), а в сумме-то те же яйца.

Это он влияние межсоединений посчитал или что-то другое?

Да.

[starley]

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

Ну, например, за счет тока кз - оба транзистора дольше открыты при более длинном переходном процессе. Но это так - домыслы...

[SM]

Ну, например, за счет тока кз - оба транзистора дольше открыты при более длинном переходном процессе. Но это так - домыслы...

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

[starley]

Убедили

[starley]

Кстати о птичках. А из каких соображений выставляется transition_time для клока? В смысле какое значение задавать в команде set_clock_transition.

[SM]

Кстати о птичках. А из каких соображений выставляется transition_time для клока? В смысле какое значение задавать в команде set_clock_transition.

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

[starley]

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

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

[grigorik]

Vo vremya syntesa set_clock_transition zadayut chtobi modelirovat tranzition time kotoroe budet posle clock tree syntesis (CTS).
Transition time vo vremya CTS vi sami mojete upravlayt zadavaya constrainti.

Kak vibirat tranzition time ? Transition time eto takoe chto zavisit ot texnologi. Transition time Clocka ne doljen bit blizok k verxnemu predelu potomu chto bolshie transitioni na klocke privedut k tomu chto
1. Clock budet slab k Xtalk u. A eto potom mojet privesti funkcionalnim problememam, naprimer DFF mogut izmenyat sostoyani iz-za glicthov kotorie induciruyutsya na clock.
2. Zadavat malenki transition time constraint na clock privedyot k tomu chto CTS engin dobavit mnogo bufferov(invertrov) eto privedyot k bolshim delay-am na clock tree, i bolshemu upotrebleniyu moshnoti Poskolku clock eto signal v sxeme kotori menayert sostoyanie bolshe chem drugie.

Iz-za vishe skazannago mojno naprimer brat constraint ot 60-80% verxnego predela library.
Nu voobshe postoroites vsegda bit v predelax transiton i cpapcitance kotorie naxoditysa v library, potomuschto kogda budete vne etogo diapazona resultati timing analysa budut ne vernimi.
Eshyo nado uchtit chto est 5% nevernost v raschyotax (v toolax) i postoraites v konce proekta imet design gde transiton i max cap bili mali chem 95% predelov.

Luchse vsegdo ostavit max cap/transition fiksirovat vo vremya P&R.


Vsyo vishe skazannoe eto prosto misli iz moego opita yesli kto-to ne soglasen ya budu rad obsudid so vsemi.

Udachi.

[starley]

grigorik, спасибо за обстоятельный ответ.

Назрело еще несколько вопросов.
- Как работать правильно с ИО буферами? С одной стороны их удобно добавить в ХДЛ код, но для клока и ресета это не прокатит. Когда же тогда добавлять последние? Ручками в отсинтезированный нетлист?
- Как правильно синтезировать ресет? На клок ставится dont_touch и на этапе реализации генерируется дерево буферов. А для ресета?
- Какие особенности синтеза дизайна с двумя независимыми доменами синхронизации? Вроде как по логике достаточно определить клоки, задержки входных и выходных сигналов для соответствующего клока, ну и констрейны на асинхронные пути между доменами. Но, судя по документации, как-то все не так просто.

[Doka]

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

думаю гуру согласятся с тем, что это лучшее что есть по теме CDC
 Clock.Domain.Crossing.Design.and.Verification.Techniques.pdf ( 566.49 килобайт ) Кол-во скачиваний: 932

[starley]

2Doka спасибо за доку.

И все-таки, как правильно работать с ИО буферами? Куда и когда их добавлять? В ХДЛ код или в отсинтезированный нетлист?

Сообщение отредактировал starley - Apr 13 2009, 13:00

[SM]

И все-таки, как правильно работать с ИО буферами? Куда и когда их добавлять? В ХДЛ код или в отсинтезированный нетлист?

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

[starley]

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

Вот и я так думал. Но тогда загвоздка с синхросигналами и ресетом получается. DC при выполнении STA берет drive ио буфера и рассчитывает исходя из него, например, transition time для клока, Значение, разумеется, получается охрененно большим. Какой тут обходной путь предполагается?

[grigorik]

Вот и я так думал. Но тогда загвоздка с синхросигналами и ресетом получается. DC при выполнении STA берет drive ио буфера и рассчитывает исходя из него, например, transition time для клока, Значение, разумеется, получается охрененно большим. Какой тут обходной путь предполагается?

starley mojet set_ideal_network na vixode IO bufera pomojet?

[SM]

Вот и я так думал. Но тогда загвоздка с синхросигналами и ресетом получается. DC при выполнении STA берет drive ио буфера и рассчитывает исходя из него, например, transition time для клока, Значение, разумеется, получается охрененно большим. Какой тут обходной путь предполагается?

Ну во первых - возможно вы всунули клоковый буфер. Который вовсе не I/O, а специальный клокодрайвер сверхмощный. Так как драйв у обычных буферов как правило соответствует драйву обычного элемента логики.

[starley]

Ну во первых - возможно вы всунули клоковый буфер. Который вовсе не I/O, а специальный клокодрайвер сверхмощный. Так как драйв у обычных буферов как правило соответствует драйву обычного элемента логики.

Нет, совершенно точно обычный ио буфер.

[grigorik]

Нет, совершенно точно обычный ио буфер.

ubedites chto u vas v constraintax net set_propagated_clock komandi.

[SM]

Нет, совершенно точно обычный ио буфер.

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

[starley]

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

Ну раз пошли такие варианты... Сreate_clock надо делать для входа или для выхода ИО буфера клока?
Если я вас правильно понимаю, - то для входа, а у DC достаточно сообразительности, что бы проигнорировать в расчетах ИО буфер клока и при расчетах использовать то значение transition_time, которое я установил в set_clock_transition?
А как тогда быть с ресетом? Дерево буферов для него обычно генерится на этапе реализации или в DC?

ubedites chto u vas v constraintax net set_propagated_clock komandi.

Точно нет, вместо него set_clock_latency и set_clock_uncertainty.