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

>>Единицы точно те, которые указаны в библиотеке
согласен
>>в части - площади NAND2
с такими еще не сталкивался

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

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

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

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

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

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

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


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

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

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

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

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)

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


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

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

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

>Вы вводите людей в заблуждение. 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).


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

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

чтобы компилятор памяти не предлагал генерировать ринги не встречал. что такое PAR тоже не знаю(P&R? : ) ).
afaik компиляторы памяти от Artisan и Virage Logic сейчас предлагают такую фичу.
насчет "простоты" делать индивидуальные ринги к каждому макроблоку памяти при планировке - имхо сомнительное удовольствие перерисовывать ринги к каждой памяти при изменении floorplan чипа или на новом чипе (again, не понял, что же такое "PAR").
при наличии информации о рингах в .lef, .gds на макроблок ринги "всегда с тобой", при любом инстантиировании блока ринги сразу же осознаются как instance pins.
соответственно, организовать power routing, размещение standard cells без заботы о halo блока, расчет IR-drop и др. проще. в SOCE так точно проще...