[SM 0]

um^2

Не вводите людей в заблуждение. Единицы точно те, которые указаны в библиотеке, и могут быть любыми попугаями. У меня в части библиотек микроны в квадрате, а в части - площади NAND2. В результате пришлось править часть либ с айпи-корами, приводя их к общему знаменателю (я выбрал гейты, то есть площади NAND2, так как stdcell в них была, чтобы править меньше)

[Losik 1]

Не вводите людей в заблуждение. Единицы точно те, которые указаны в библиотеке, и могут быть любыми попугаями. У меня в части библиотек микроны в квадрате, а в части - площади NAND2. В результате пришлось править часть либ с айпи-корами, приводя их к общему знаменателю (я выбрал гейты, то есть площади NAND2, так как stdcell в них была, чтобы править меньше)

>>Единицы точно те, которые указаны в библиотеке

согласен

>>в части - площади NAND2

с такими еще не сталкивался

[SM 0]

>>в части - площади NAND2

с такими еще не сталкивался

Конкретный пример - либы Libra-Visa от синопсиса. У меня 0.35-ые

[oratie 0]

В Synopsys library нет возможности указать единицу измерения площади. Так, что в каких попугаях дана площадь обычно пишут в даташите на эти либу. Соответственно, если вы используете несколько либов от разных производителей (например std. cell и memory), то нужно проверить согласуются ли они по единицам площади.

 

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

[starley 0]

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

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

[sleep 0]

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

к сожалению, для артизановских китов, с которыми работал(0.18, 0.25), все генераторы памяти поставлялись именно под Sun Solaris. приходится держать SunBlade под эти генераторы.

генераторы под нормальные процессоры и linux бывают, только у других вендоров : )

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

размер охранного кольца?

может быть ширина и металлы рингов? если речь про ринги, - то по-хорошему исходя из расчета потребляемого тока блоком памяти. можно заложиться с запасом : )

[starley 0]

Помимо DC у синопсиса есть еще синтезатор PhyC, который по их уверениям лучше. Кто-нибудь работал с ним? Действительно лучше?

 

может быть ширина и металлы рингов? если речь про ринги, - то по-хорошему исходя из расчета потребляемого тока блоком памяти. можно заложиться с запасом : )

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

[oratie 0]

PhysC это следующий, по маршруту проектирования, тул, полсе DC. Он бенет синтезированный в DC нетлист и делает размещение (placement) с последующей оптимизацией нетлиста и размещения. Вообще-то это устаревший тул, так, что если есть доступ к Synopsys IC Compiler, то лучше пользоватся сразу им. IC Comp заменяет связку PhysC и Astro (placement+routing).

 

А еще есть DC-Ultra-Topgraphical - это надстройка над просто DC - основная фича - синтез с учетом предполагаемого размещения - если есть доступ, то запускайте DC-Ultra (или даже DC-Graphical - синтез с учетом и размещения и трассировки :) )

[starley 0]

А еще есть DC-Ultra-Topgraphical - это надстройка над просто DC - основная фича - синтез с учетом предполагаемого размещения - если есть доступ, то запускайте DC-Ultra (или даже DC-Graphical - синтез с учетом и размещения и трассировки :) )

А как он запускается из DC?

[oratie 0]

compile_ultra

Performs a two-pass, high-effort compile flow on

the current design for better quality of results

(QoR).

All Modes:

int compile_ultra

[-scan]

[-no_uniquify]

[-no_boundary_optimization]

[-exact_map]

[-no_autoungroup]

 

DC Topographical Mode:

int compile_ultra

[-scan]

[-incremental]

[-no_design_rule | -only_design_rule

| -only_hold_time]

[-no_uniquify]

[-no_boundary_optimization]

[-exact_map]

[-no_autoungroup]

[-area_high_effort_script] (XG mode only)

[-timing_high_effort_script] (XG mode only)

 

Как запустить DC-Graphical не знаю, не запускал. Ultra, Topgraphical и Graphical это отдельный лицензионные фичи.

 

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

 

dc_shell -topographical_mode (run shell in Topographical mode)

[SM 0]

если есть доступ к Synopsys IC Compiler, то лучше пользоватся сразу им. IC Comp заменяет связку PhysC и Astro (placement+routing).

Вы вводите людей в заблуждение. Astro это полноценный бэкенд-тул, ему не нужны никакие PhyC. Astro берет на входе нетлист от DC, бэк-енд либы от фаба, и ничего больше ему не нужно. Astro это бывший прямой конкуррент к PhyC/IC. Бывший потому что от Avanti он. А теперь - параллельные тулы. Я бы сказал - что если есть доступ к Astro - юзайте Astro. Если нет - то можно и IC compiler, попроще-подубовее. Еще один плюс Astro - с ним проще жить, если кастомные блоки есть, сделанные в Cosmos. Например чтобы сгенерить образ блока для PAR по полной топологии блока - то без Astro вообще не обойтись (или скрипт в космосе писать). Еще плюс Astro - это опция Interactive Ultra - ручная разводка. ИМХО (но не точно) IC comp это не умеет.

 

А еще есть DC-Ultra-Topgraphical - это надстройка над просто DC - основная фича - синтез с учетом предполагаемого размещения

Не синтез с учетом размещения, а оценка таймингов не через wireload-модели а методом размещения-оценочной разводки-RC-экстракции. То есть просто более точная и реальная оценка таймингов.

[sleep 0]

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

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

да и от других вендоров компиляторы тоже как-то не слишком активничают в плане _вычислений_ конфигурации рингов питания.

да и простора для _вычислений_ компилятором рингов обычно не предоставляется - просто поля для ввода юзером.

поэтому действовать предлагается исходя из опыта и здравого смысла.

[SM 0]

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

да и от других вендоров компиляторы тоже как-то не слишком активничают в плане _вычислений_ конфигурации рингов питания.

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

[oratie 0]

>Вы вводите людей в заблуждение. Astro это полноценный бэкенд-тул, ему не нужны никакие PhyC.

 

Да, немного некорректно написал. Конечно же Astro делает сам и размещение и разводку. Привязывать к нему PhysC имеет смысл, если Astro не справляется с вытягиванием timing/power/area... Так, как в PhysC реализован более мощный (в Astro есть оптимизация, но послабее) алгоритм оптимизации логики (logic remapping) на этапе размещения. А трассировщик в PhysC совсем никакой. Поэтому я и говорю, ICC способен заменить Astro (place'n'route) + PhysC (deep in-place optimization), да еще к тому же может заменить и JupiterXT (floorplanner). Кстати, Synopsys не собирается поддерживать Astro на технологиях глубже 45нм. Только ICC.

 

>Не синтез с учетом размещения, а оценка таймингов не через wireload-модели а методом размещения-оценочной разводки-RC-экстракции.

 

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

 

 

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

 

Зачем их генерить компилятору памяти самому - мне кажется, чтобы просто помочь юзеру :)

[sleep 0]

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

чтобы компилятор памяти не предлагал генерировать ринги не встречал. что такое PAR тоже не знаю(P&R? : ) ).

afaik компиляторы памяти от Artisan и Virage Logic сейчас предлагают такую фичу.

насчет "простоты" делать индивидуальные ринги к каждому макроблоку памяти при планировке - имхо сомнительное удовольствие перерисовывать ринги к каждой памяти при изменении floorplan чипа или на новом чипе (again, не понял, что же такое "PAR").

при наличии информации о рингах в .lef, .gds на макроблок ринги "всегда с тобой", при любом инстантиировании блока ринги сразу же осознаются как instance pins.

соответственно, организовать power routing, размещение standard cells без заботы о halo блока, расчет IR-drop и др. проще. в SOCE так точно проще...