Есть что-нибудь, кроме Alliance? А то он какой-то несерьезный. Насколько реально найти ломаный Synopsys или Cadence? В нете мне их найти не удалось Суть проблемы в том, что мы заказали одной отечественной конторе перевод проекта для ПЛИС на ASIC, и мне хотелось бы контролировать их работу.

Cadence в режиме read-only запускается и без лицензии (т.е. бесплатно).
Если хочется контролировать работу, то есть смысл сьездить в командировку - пусть все покажут и расскажут - указать такой пункт в договоре.
Или чтобы по договору были страшные санкции за ненадлежащее исполнение.

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

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

А зачем для этого синтезатор? Для этого необходимо и достаточно наличие sign-off симулятора и STA. Т.е. например PrimeTime + IUS - а они обязаны предоставлять нетлисты с SDFами и после синтеза, и после PAR. Командировки - лишнее. Даже с исполнителями в тайване можно без командировок это легко сделать (пройденный этап, back-end они мне делали), несмотря на жуткий языковой барьер. А уж с нашими-то...

Мне не столько интересно убедиться в том, что они все правильно сделали, сколько, что называется, "определить границы". Например, мы планируем делать по 0.18, а у меня есть подозрение, что хватит и 0.25, а может и больше. Кроме этого, хотелось бы проверить их оценки площади, определить максимальную рабочую частоту и т.п. Это первый ASIC для нашей конторы и первый проект такого уровня сложности для них, так что вопросов и поводов для беспокойства предостаточно.

А у вас есть все технологические либы на все технологии того фаба, где печь будете? Чтобы вот так выбирать и пробовать? Нам например каждую отдельно взятую либу давали под свой NDA. Найти синопсис дц никакой проблемы не составляет.

ну, согласно http://ru.wikipedia.org/wiki/GNU_Compiler_Collection , есть поддержка VHDL

Ну кое-какие либы есть, что-то найду. Для оценки порядка величин, надеюсь, хватит. Оценить-то надо будет только 0.18 и 0.25.

Кстати, есть и OpenSource библиотеки, например, на www.vlsitechnology.org. Кто-нибудь смотрел их? В чем они уступают коммерческим аналогам?

вы же собираетесь изготавливать свой ASIC на конкретном заводе, а не на абстрактной фабрике. в этом и отличие.

В том, что они годятся для образовательных целей, ну в крайнем случае как база для изготовления своей техлибы. Но делать на ней асик, и даже оценивать по ней что-то, риск слишком велик. Что касается "коммерческих" - все технологические либы я пока что получал от фабрики совершенно бесплатно. Только под NDA. Коммерческие - это что нибудь "из ряда вон" - типа rad hard или ultra low power.

В общем, я так понял, что с open source дела иметь не стоит
Установил Синопсис ДК, теперь, как и предсказывал SM, проблема с библиотеками. На фтп только 0.13 и 0.09. Может ли кто-нибудь поделиться библиотеками для 0.18 и 0.25?

Какой фаб?

Желательно TSMC. Но для примерной оценки, я думаю, и любой другой пойдет.

TSMCs
TSMC library for 0.13 micron:
http://rapidshare.com/files/132830739/Tsmc_013.Tar.gz
or
http://ifile.it/g1ywh3e

I have these files too:
Size Name

317,423,304 - 0.18um TSMC Artisan Design Kit updated-fixed 02-2008.rar
Part1
Part2

1,421,312 - rebuilt.Tsmc-0.18Um Lib.rar = http://ifile.it/dmgqy7n

104,588,266 - Tsmc 0.35 Library.zip = http://ifile.it/foex37h

230,830,080 - Tsmc 013 standardcell.Tar
Part1 = http://ifile.it/45itswa
Part2 = http://ifile.it/cjha1iu

83,830,557 - TSMC_018.tar.gz = http://ifile.it/pcxn1jg

188,067,840 - Tsmc 018 Standardcell.tar
http://ifile.it/xskpafn/tsmc_018_standardcell.tar

10,044,882 - TSMC-0.18um LIB.rar = http://ifile.it/f8l0uew

626,666,845 - TSMC.90.tar.bz2 83,830,557 TSMC_018.tar.gz
Part1 = http://ifile.it/0y3qic2
Part2 = http://ifile.it/d3z76ew
Part3 = http://ifile.it/mazj715
Part4 = http://ifile.it/8d06hur
Part5 = http://ifile.it/wqmy7dg

взято с http://atryna.blogspot.com

Большое спасибо. Я думаю при такой взаимной поддержке у нас есть все шансы не только нефтью и газом начать торговать.
А почему есть несколько вариантов библиотек для 0.18? И чем DesignKit от библиотеки отличается?

В личку или мыло черканите. Может чем и помогу. В диапазоне от 0.18 до 0.5. Сюда лить не буду, либы не левые.

пару ссылок получились битыми. вот прямая ссылка на пост http://atryna.blogspot.com/2008/07/tsmc-013u.html
>>несколько вариантов библиотек для 0.18
0.18 я не качал. скорее всего это просто разные релизы, обновления.
TSMC90 аж за 2005 год. полное старье. может служить только в ознакомительных целях.

С библиотеками базовых ячеек понятно. Теперь вопрос с ячейками ввода/вывода. В базовые библиотеки входят только самые простые. А как насчет более интересных, например, SSTL для DDR. Есть специальные библиотеки для ячеек ввода/вывода?
Второй вопрос, реально ли найти в нете такие вещи как PLL и SERDES? Или хотя бы доки на них?

Это все обычно IP cores сторонних разработчиков, которые доступны за дополнительную плату. Ну или как вариант самому разрабатывать, выдрав защиту из стандартной либы, ибо это самый геморрой, а все остальное туда свое.

А зачем выдирать защиту из стандартной либы - чтобы туда свои ячейки вставить?

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


ХМ. Кажется дошло Я говорю про ESD-защиту падов.... А Вы?

А что тогда самому делать? Размеры транзисторов под требуемое выходное сопротивление подгонять?
Тут вот еще вопрос возник. Либы имеют расширение .db и .lib. DC использует .db. А кому тогда нужен lib?

Все остальное. А почему именно размеры транзисторов? А не изваять например резюк из поликремния? Или помудрить с источниками тока... Или... Ну собственно смотря что делать и что технология позволяет


А вот программы имеют расширение .exe, .c, .cpp. Windows использует exe. А кому тогда нужны .c и .сpp ?

Это смотря кто и как делает. Сколько видел стандартных, выдающихся под NDA либ - все полное г.
Делал свои - никаких катастроф. Типа, везет?
Очень важно DRC придерживаться, и тонкости стандартных процессов знать.
Короче, не стоит этого бояться! Надо доки читать просто.

А что, можно умудриться не придерживаться? Дык обругают, поди даже матом.

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

То есть .lib - это типа исходников?
Еще вопрос, а какие единицы в отчете, формируемом командой DC report_area?

um^2

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

>тобы компилятор памяти не предлагал генерировать ринги не встречал
Действительно, старые компиляторы памяти от Avant!/Synopsys не предлагали сгенерить ринги. Ну так жизнь не стоит на месте. Более того, наиболее продвинутая методология (как мне кажется), это вместо ринов генерить сетку над памятью (power mesh), как, например, предлагает Dolphin Technology в своих компиляторах. Питание с сетки сразу идет внутрь банка памяти.

par это place and route. backend короче. Касабельно рингов - а я вот люблю сделать ринги над памятью, а не вокруг, если мне металлов хватает... И нахрена оно мне тогда, сгенеренное компилером? А сделать ринги вокруг блока в том же астро один тычок.