Jump to content

    

sleep

Свой
  • Content Count

    77
  • Joined

  • Last visited

Everything posted by sleep


  1. предположу, что единственно верным ответом о конструкции падов будет просмотр их gds ) вьюверов gds-в достаточно много, некоторые ну очень простые. плюс всё-таки имхо соотношение сторон абстракта указывает, что bonding pad уже включен... похоже на 018 микрон как бы... работал с 240*50 по 018 - это уже были staggered cо включенным bonding pad. 240*70 - inline. если 013 - то может и без bonding-а. если так - сами bonding pads дорисовываются дизайнером "ручками". можно создать конфигурацию хоть inline, хоть staggered; понятно, что расставляются они скриптами. насчет доступности трассировки по падам - часто делают кольца внутри падов в нескольких металлах, и выводы питания/земли в сторону core выводят в нескольких доступных металлах. следовательно, сигнальная трассировка над падами запрещается.
  2. Цитата(SM @ Jan 30 2009, 23:30) А что - plib/pdb flow убрали? Не знал. Вроде бы он работает до сих пор. Касабельно FRAM - это абстракт ячейки - грубо то же, что и в LEF. Пины и зоны, запретные для трассировки. Делается одной левой например из полной топологии в виде GDS-II или из LEF. Формат древний как мир, его еще Apollo юзал авантовский на заре веков, и я пока не встретил фаба, который бы не дал этого формата. Вот plib/pdb - да, редкость. Milkyway есть в Astro, есть в star-rcxt, отдельно его нет. видимо, в разных фабах тейпаутимся : )
  3. oratie, спасибо за информацию. насколько осведомлен, закрома не богаты милкивеем? у меня вроде была какая-то бородатая версия 2005 что ли года, не работаю с данной софтинкой по маршруту, так что опыта нет, что там у нее с жадностью к фичам и тп. попробую этого зверя пощупать.
  4. насколько я понимаю, информация для 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, но есть ли возможность конвертить стандартные представления в него пока не ясно.
  5. Цитата(starley @ Jan 29 2009, 17:54) Меня тут тоже вопрос один с 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-ов.
  6. Цитата(SM @ Jan 27 2009, 20:46) А на кой эти ринги вообще компилятору памяти генерировать? Их куда проще при PAR сформировать. Собственно юзаю сейчас компилер от синопсиса-аванта, там, как по логике и следовало бы ожидать, ни слова о рингах вообще. чтобы компилятор памяти не предлагал генерировать ринги не встречал. что такое PAR тоже не знаю(P&R? : ) ). afaik компиляторы памяти от Artisan и Virage Logic сейчас предлагают такую фичу. насчет "простоты" делать индивидуальные ринги к каждому макроблоку памяти при планировке - имхо сомнительное удовольствие перерисовывать ринги к каждой памяти при изменении floorplan чипа или на новом чипе (again, не понял, что же такое "PAR"). при наличии информации о рингах в .lef, .gds на макроблок ринги "всегда с тобой", при любом инстантиировании блока ринги сразу же осознаются как instance pins. соответственно, организовать power routing, размещение standard cells без заботы о halo блока, расчет IR-drop и др. проще. в SOCE так точно проще...
  7. Цитата(starley @ Jan 27 2009, 14:57) Может и про ринги. В таком случае разве синтезатор сам не может определить их размер, исходя из потребления тока? те компиляторы памяти от артизан, с которыми я работал, не могли. да и от других вендоров компиляторы тоже как-то не слишком активничают в плане _вычислений_ конфигурации рингов питания. да и простора для _вычислений_ компилятором рингов обычно не предоставляется - просто поля для ввода юзером. поэтому действовать предлагается исходя из опыта и здравого смысла.
  8. Цитата(starley @ Jan 24 2009, 22:51) Вот еще вопрос созрел. В артизановском дизайн ките синтезатор памяти только для Spark. А бывают ли эти синтезаторы под нормальные процессоры, вроде х86 . А то на единственном нашем спарке какая-то древняя соляра стоит, а ставить новую только из-за синтезатора не хочется. к сожалению, для артизановских китов, с которыми работал(0.18, 0.25), все генераторы памяти поставлялись именно под Sun Solaris. приходится держать SunBlade под эти генераторы. генераторы под нормальные процессоры и linux бывают, только у других вендоров : ) Цитата(starley @ Jan 24 2009, 22:51) И еще. В параметрах синтезатора задается размер охранного кольца для памяти. Из каких соображений его надо выбирать? По умолчанию предлагается 2 мкм. размер охранного кольца? может быть ширина и металлы рингов? если речь про ринги, - то по-хорошему исходя из расчета потребляемого тока блоком памяти. можно заложиться с запасом : )
  9. замечал улучшение slack на 5-10% максимум в блоках ~600k gates, насыщенных DW после ungroup DW улучшение slack сильно реже. также получается использовать ultra для того, чтобы "перетряхнуть" дизайн, сдвинуть его с локально пойманного минимума.