Уважаемые Гуру асикостроения, посоветуйте софт по теме. Интерес - чисто ознакомительный, но охота пощупать именно живой софт, на котором можно было бы сделать какой-нибудь небольшой но реальный проект, посмотреть времянки, оценить потребление, макс. частоту и т.д., подозреваю, что в таком софте все эти параметры максимально приближены к реалии, и на них можно опираться. Понятно что софтов много, поэтому если не сложно, хотелось бы от Вас услышать плюсы/минусы софта, доступность библиотек, и т.д. и главное на каких фабах можно реализовать поекты, созданные на том или ином софте.
И еще вопрос, если ответ деликатный - то пожалуйста в личку: где бы взять софт с лицензией, "поносить"

Заранее всем благодарен!

судя потому, как часто всплывают такие темы, хотел бы присоединится к топикстартеру и выпросить у ASIC-гуру немного времени на написание соответствующего раздела FAQ в wiki electronix'a.

Судя по тому, что "посмотреть времянки, оценить потребление, макс. частоту" - нужен пока только логический синтезатор?
синопсис - DC - design compiler
кейденс - RC - RTL Compiler
Вопрос о плюсах и минусах - вопрос религиозный[или вопрос маршрута, кому как нравится] : ) Все базовые вещи выполняют оба тула.
Разработка топологии:
- IC Compiler
- SOC Encounter (EDI сейчас поставка называется)
Аттестация: DRC/LVS/...
- Hercules? - синопсис тут не юзал
- Assura
- Calibre (от MG)

По библиотекам - надо смотреть, есть ли у Вас выход на фабрику, какие проектные нормы, есть ли свободные библиотеки.
Имеет значение состав Вашего проекта, размер, будет это MPW или отдельный запуск, где будете делать шаблоны, корпусирование и прочее.

Все перечисленные тулы, судя по всему, можно взять на местном ftp.

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

Спасибо sleep!



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



А может посоветует кто литературу?

Про симулятор забыли. NC-Verilog (входит в пакет IUS) у кеденса или VCS у синопсиса.
Современные сапр умеют считать задержки после разводки топологии. Так что выгружаете файлы задержек для корнеров и с ними симулируете - если библиотека корректна, то и результаты будут соответствовать реальному поведению.

Из книг можно посоветовать ADVANCED ASIC CHIP SYNTHESIS/Himanshu Bhatnagar - по маршруту синопсиса. В сети легко найти.
Есть также на русском:
Цифровые интегральные схемы. Методология проектирования http://www.ozon.ru/context/detail/id/3427490/
Системы-на-кристалле. Проектирование и развитие http://www.ozon.ru/context/detail/id/2199762/

Такая стнаница была начата, но не дописана до конца, кто желает может её дополнить...

.../upload/BOOKS/Advanced_ASIC_chip_synthesis_-_Bhatnagar.pdf

Здорово! Столько всего! Спасибо!



А не могли бы Вы выслать на alexpu81@gmail.com? Доступа на фтп нет, запрос отправил, ждемс...

UPD: Уже нашел.

Доброго времени суток!

alexPec,
вот несколько книжек, которые рекомендовал бы просмотреть.

1.
Digital Integrated Circuit Design
From VLSI Architectures to CMOS Fabrication
Hubert Kaeslin
CAMBRIDGE UNIVERSITY PRESS

2.
Electronic Design Automation for Integrated Circuits Handbook
Edited by
Louis Scheffer, Luciano Lavagno, and Grant Martin
2006 by Taylor & Francis Group, LLC

3.
POWER DISTRIBUTION NETWORK DESIGN FOR VLSI
QING K. ZHU
2004 by John Wiley & Sons

4.
SYSTEM-ON-A-CHIP VERIFICATION
Methodology and Techniques
Prakash Rashinkar, Peter Paterson, Leena Singh
KLUWER ACADEMIC PUBLISHERS

Разумеется, у разных книжек разная специфика.
#1 - наиболее обзорная

Спасибо! Все посмотрю.

If you're looking for a free (but usable) solution, take a look at:
http://www-asim.lip6.fr/recherche/alliance/

I have read on the net that Icarus Verilog simulator is quite good, so it might be useful to you.

Libraries are always a problem, since the foundries won't give them without a signed NDA...
However, model cards can be found on the MOSIS site, and some scalable CMOS libraries can be found.

Hope this helps...

Thanks a lot! I'll try it too.

I've forgot to mention a good open source simulator:
http://qucs.sourceforge.net/

It looks like ADS

реально разведённого P&R тулом? нет конечно. но выдать примерные времянки, оценить потребление, макс. частоту может.

Про потребление - для серьезных чипов много зависит от конкретного теста, прикинуть порядки цифр в различных режимах работы схемы абсолютно реально.
Про частоту - если использовать не сильно тупые wire-load models, или топологические представления в синтезе (тут всё зависит от вендора тула), то понять максимально достижимую частоту и узкие места чипа по таймингу тоже можно.
Также современные синтезаторы могут оценить сложные места для трассировки (congestion) на реальной планировке кристалла, могут оптимизировать логику схемы, чтобы эту трассировку упростить.

For high frequency chip design a good extractor is a must.
There are many of these on the market, but I've heard that Columbus is mostly used for MMIC design.

В принципе, да, может.

Например, в том же DC у Synopsys используются режим topographical, в котором создаётся предварительное размещение и, следовательно, используются реальные задержки, а не WLM.
Кроме того, используется SPG (Physical Guidance) flow. Всё это обеспечивает неплохую корреляцию с ICC.

Не знаю, как у RC, не работал, но подозреваю, что примерно то же самое.

Попробовал найти на FTP Synopsys DC. Там куча директорий, но ни одного названия, похожего на Design Compiler. Он как-то по-другому называется? Как?
И можно ли его поставить на Ubuntu?

Да, называются по другому:
pub/EDA/_Synopsys_/syn_*

Можно.

на практике не может. это в любом случае модель, предположение

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

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

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

Разница между предположением и практикой определяется в данном случае статистическим путём.
Вот, например, разница между результатами логического и физического синтеза в графическом:
Нажмите для просмотра прикрепленного файла

и в числовом виде:
Нажмите для просмотра прикрепленного файла

До 5% (для SPG) разницы - достаточно неплохой показатель, как мне кажется.

В Синопсисе трассировать не пришлось - остановило заявление авторитетных людей, что для использования топографического режима (в котором вся прелесть) нужно и либу иметь во внутреннем формате синопсиса. А они обычно подаются в gds или oa и не привязаны. И нужен качественный plib как минимум. Кто-то подтвердит\опровергнет? Рисовать\адаптировать же свою либу - дело хлопотное, не для всякого проекта приемлемо ни по срокам, ни по стоимости.

Синопсису для топо режима, помимо обычных синопсис библиотек .lib/.db, требуется описание топологии ячеек в Milkyway формате (собственный синопсисовский формат). Этот Milkyway довольно легко делается из LEF (получается Milkyway FRAM - фантом/абстракт для трассировщика) и из GDS (получается Milkyway CEL - реальная начинка топологии).

.plib уже давно не используется - это было нужно для PhysicalCompiler, а он уже много лет как заменен IC Compilerом.

На своих проектах я получал довольно хорошую зависимость между topo синтезом в DC и последующим размещением/трассировкой в ICC.

Каким софтом вы конвертируете LEF в формат Milkyway для топо? Нужно ли что-то ещё помимо LEF-библиотеки?
Известны ли Вам данные или собственные соображения на счёт зависимости между topo синтезом в DC и размещением/трассировкой в Саdenсе SOC Encounter?

Софт Синопсиса, так и называется Milkyway. Читает и LEF и DEF (если нужно). Ещё ждя Милкивэя нужен тех. файл .tf (в своем синопсисовском формате). Я не пробовал получить его из технологического LEF файла (можно ли это сделать, я не знаю).

Про корреляцию между DCtopo и SOCencounter ничего определенного сказать не могу. Но судя по документам/презентациям от Синопсиса, DCtopo очень сильно завязан нм ICcompiler, и если вместо ICC использовать third-party tool, то результаты могут сильно отличатся.

Вставлю свои пять копеек, так сказать из практики...
При условии что Вы имеете ввиду проектирование цифрового ASIC посоветую такое:

1) "посмотреть времянки" - нет разницы с FPGA. RTL он и в африке RTL...
Mentor Model Sim - идёт безплатно к вебпакам, Xilinx ISE напр.
Cadence NC-Sim.

2) Синтез.... Ну, если FPGA тул съел, то можна и на ASIC тул перейти.
Трудностей в освоении этих тулзов нет. Можна освоить по User Guide.
Cadence RC Compiler, Synopsys DC.

Cadence лутше тем, что позволяет не чисто синхронные схемы делать, а Synopsys нет.

3) Внедрение DFT (Design For Test) - RC Compiler.
Можна освоить по User Guide.

4) Floorplane, Place & Rout - Cadence SoC Encounter.
Чисто синхронный простой учебный проект может и можно по User Guide осилить....
А вот реальный, после 2-х лет активного использования - всё есчё на й...т...м.
Без поддержки Cadence и старших товарисчей - врядли.

5) " оценить потребление, макс. частоту и т.д" - Cadence SoC Encounter.
вот только без библиотек сделанных под конкретный тул ничего не получится.....

6) ATPG (automatic Test Pattern Generation) - тест вектора для производства.
Это делает производитель FPGA, а тут прийдётся самому.
Cadence Test Encounter, TetraMax - Без поддержки производителя тулзы и старших товарисчей - врядли освоится.

Вцелом - ASIC кухня начинается с DFT , Floorplane, Place, Rout и ATPG.
Изучать эти тулзы самому - всё равно что изучать хирургию без наставника - врядли кто-то под Ваш нож лечь захочет.....

А можно пояснить этот момент поподробнее? Чего такого умеет Cadence RC чего не умеет Synopsys? Разве для синтезатора имеет значение синхронная схема или нет?

1) "азве для синтезатора имеет значение синхронная схема или нет?" - не имеет значения, т.е. для синтезатора любая схема выглядит чисто синхронной (даже асинхронный RS на 2-х гейтах).
2) Чтобы асинхронная схема работала правильно, нужно соблюсти величины задержек в разных частях.
Эти задержки имплементируються на этапе SP&R, т.е. после синтеза.
Для этого в Cadence Encounter намного больше гибкости (больше опций).

Как Вы думаете, стоит ли рассматривать вопрос синтеза ASIC с помощью Leonardo Spectrum как серьезный?
Предположим речь идет о проекте 1 миллион эквивлентных вентилей по технологии, например, TSMC 90nm.
Основная рабочая частота 100..200МГц.

Синтез можно делать в чём угодно - на выходе всё равно нетлист.
Эсли Ваша цель нетлист, а не топология то вопрос синтеза ASIC с помощью Leonardo Spectrum - серьезный.

Эсли Ваша цель топология - то одним синтезатором Leonardo Spectrum не обойтись.

Зависит от того, какой вы результат хотите получить и на сколько вы умеете пользоваться настройками DesignCompiler`а. По умолчанию леонардо делает схему лучше чем synopsys. Но возможностей по тонкой настройке у синопсиса похоже больше. Частоты у вас не очень большие, проблем особых не должно быть с синхронизацией, хотя многое зависит от особенностей вашего проекта. Ещё нужно пробовать разные версии леонардо, так как версии с 2004 по 2009 были не очень хорошими. Лучше пользоваться либо более старыми (2003), либо что-нибудь из последних.

Речь идет о выборе маршрута проектирования ASIC. И выбор синтезатора - как одного из компонентов этого маршрута.
То что Leonardo выдаст "нормальный" нетлист в заданной технологии - я почти не сомневаюсь. Но у меня есть некоторые сомнения по поводу того насколько результат синтеза будет близок к реалиям связанным с размещение компонентов на кристалле. Не прийдется ли исполнять танцы с бубном при выполнении timing closure?

Тут не совсем понятно, что вы конкретно имеете в виду под "timing closure"? И с каким другим продуктом вы сравниваете леонардо? Модели определения задержки они стандартны, и определяются в основном исходным заданием описания библиотеки (для леонардо lgen/syn, для синопсиса - либерти). Скорей всего у вас будет одинаковые описания библиотеки элементов и для леонардо и для синопсиса. Т.е. задаваться модели задержек элементов и связей будут одинаково. Исходя из этого и расчёт задержек будет идти в разных тулах одинаково, как мне кажется. Поэтому подгонка задержек под ваши требования будет не зависеть от используемого тула. Но если вы планируете использовать синтезатор, который сделает расстановку элементов и использует полученные расстояния между элементами для расчёта предполагаемой длинны шин при расчёте задержки на связях. В этом случае может получиться некоторый выигрыш от использования такого тула. Но если говорить о вашей схеме в мульён гейтов - то мне кажется сомнительным идея синтеза и размещения его целиком, это конечно быстро, но качество вызывает сомнения...

Я рассматриваю Leonardo Spectrum как единый продукт для целей прототипирования проекта в FPGA с последующей миграцией проекта в ASIC. В прошлом я сталкивался с Leonardo Spectrum наверное 2001 и с Design Сompiler 2004..2005. Я согласен с утверждением что более ранний Leonardo Spectrum давал в целом лучший результат чем Design Compiler того же периода времени. Design Compiler, о которых я упоминал, стабильно недотягивали результат синтеза для заданных параметров. Leonardo Spectrum использовался только в целях приблизительной оценки размера синтезируемого кода и быстродействия и никогда не использовался для синтеза нетлиста для реального проекта. Посему у меня и есть некие опасения на его счет.
Под "timing closure" я имею ввиду процесс "вытягивания" заданных временных характеристик проекта размещаемого и разводимого на кристалле, которые появились либо ввиду недостаточной эффективности синтезатора, либо ввиду специфики размещения элементов на кристалле, либо по какой-либо еще причине (что-то слошком много "либо" ).
По поводу одинаковых описаний библиотек для Leonardo Spectrun и для Design Compiler наверное Вы правы, и резльтат работы обоих тулзов будет близким. Но меня смущает тот факт что я пока не находил в интернете "suсcess story" использования Leonardo Spectrum в реальном ASIC проекте.

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

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

Ожидания хорошие, но важно именно насколько "success". С Лео разработано полно чипов, которые живут в аппаратуре давно.
А вот чипы-миллионники приходится разрабатывать не так уж и часто.
Это ж удел коммерческих "монстров" от электроники.
Да и то, целиком такую кучу "вывалить" не целесообразно.
Все более склонны к сборкам из более мелких модулей. И это логично.

ПС. А вот интересный вопрос - прожует ли какой синтезатор СБИС на миллиард гейтов за разумное время?

Если не секрет, какой максимальный размер чипа (в эквивалентных гейтах) Вы проектировали с помощью Лео?


Ну миллионник это вобщем-то не огромный проект. Но согласен что команда человек этак из 10 должна над ним потрудиться от 3..4 месяцев. Лишь бы процесс был бы налажен.
По текущему обсуждению я понял что сделать чип с использование Лео возможно, но вот вопрос о "весе" проекта вопрос для меня все еще остается открытым.


Ва имеете ввиду что нецелесообразно запускать синтез миллионника из RTL в Netlist да и еще без сохранение иерархии? Не могли бы Вы уточнить?

Где-то до 10-30К эквивалентных вентилей. Вообще, мне сложно представить, что может весить 1М вентилей и при этом быть единым куском, чтобы его нужно было синтезировать и размещать в топологии одним куском...

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

Может чё-то я не так понял... с Леонардо не работал но всёже...
Мне кажется Вы путаэте 2 независимые вещи: превращение RTL в нетлист (т.е. синтез) и создание топологии (т.е. Place & Route).
Все вещи связанные с timing closure выполняются на стиадии Place & Route.

1) "...насколько результат синтеза будет близок к реалиям связанным с размещение компонентов на кристалле" -
Не знаю как в Леонардо, но вот например Cadence RC Compiler может втянуть в себя fllorplane (розмер и форму будущей цифры в формате DEF) и произвести оптимизацию с учётом этого.
Поэтому, наверно лутше работать с тулзами одного производителя (чтобы они понимали друг друга)

Но при этом, розмещение он делает условное. Более того, временные модели при синтезе не точные (wire load). Грубо говоря - с учётом средней задержки на мм^2.
Поэтому вопрос " близок к реалиям связанным с размещение компонентов на кристалле" не совсем коректен.

2) О каком "timing closure" речь?
Фактически финальный "timing closure" выполняется на этапе Place & Route.
При этом понятно что синтезатор не причём...
И связывать вопрос о "timing closure" с синтезатором не коректно.

3) Чего то так рогом в синтез упираться?
Если что-то можно синтезить в FPGA то оно легко синтезится и в ASIC тулзе - типа RC Compiler.
С синтезом синхронных дизайнов - проблем нет.

Другое дело если есть необходимость встроить асинхронщину, или какие другие трюки - то это таки зависит от способностей тулзы.
Вы лутше подумайте может ли Леонардо встраивать DFT структуры. Тестировать Ваш ASIC наверно всётаки надо....

Спасибо за ответ.



Я извиняюсь что по данному вопросу, сложилось впечатление, что я рассматриваю возможность синтеза блока "весом" 1М вентилей за один проход. Это не так. Я рассматриваю возможность поблочного синтеза проекта у которого суммарная площадь блоков равна например 1М вентилей.


Синтез и P&R я не подменяю - я их связываю. Собственно вариантов синтеза я вижу уже три:
1-Синтез баз учета wire load model;
2-Синтез с учетом wire load model;
3-Синтез с учетом топологии кристалла (реально не сталкивался но на этой ветке данный вопрос обсуждался);
Думаю что последний вариант доставит минимум проблем с "timing violations" при P&R
-

Да. На этапе "timing closure" синтезатор не-причем. Но тем не менее я считаю что результат работы синтезатора связан с количеством и величиной "timing violations".


Ну речь идет о покупке лицензии на синтезатор который бы неплохо справлялся с синтезом как FPGA так и ASIC. RC Compiler считал программой "заточенной" сторого под ASIC.
Ну а с DFT у Лео все хорошо, а вот про возможность синтеза "gated clock" - пока неизвестно.

1) "Собственно вариантов синтеза я вижу уже три: " - добавте есчё 2:
- RCCompiler можно есчё и структуру клокового дерева (clock_tree.spec) подсунуть - есчё точнее.
- RCCompiler розпознаёт DFT структуры, описанные его командами

2) "покупке лицензии на синтезатор который бы неплохо справлялся с синтезом как FPGA так и ASIC"
А это зачем?
Если прототипировать ASIC в FPGA то ответ простой - синтез только в ASIC тулзах (FPGA соотв. в Xilinx ISE, который всё равно нада для P&R).

И лутше, и проблем меньше!
Я не думаю что Леонарду Вы DEF Floor-plane сможете скормить, а уж тем более clock_tree.spec подсунуть....

3) "результат работы синтезатора связан с количеством и величиной "timing violations"" - Да. Особенно с учётом возможностей п.1)

4) Ежели зачем-то надо и ASIC и FPGA, то лутше подумайте о записи тайминг констрейнтов в SDC формате.
Тогда просто будет с одного тула в другой переходить.

5) "возможность синтеза "gated clock" - пока неизвестно"
Если у вас gated clock, то какой смысл говорить об FPGA?

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

Говорят что Лео и Синплифай справляются с задачей синтеза лучше чем родной XST. Но не об этом речь. Речь идет о выборе софта с последующим приобретением официальной лицензии. В целях экономии рассматривается вариант совместного использования синтезатора как для FPGA так и для ASIC. Для "вылеченного" софта вопрос выбора синтезатора не так актуален.


Ну gated clock в ASIC а не gated clock в FPGA. Каждому свое.


Тут Вы меня немного сбиваете с толку. Разве RC Compiler не является для Вас тулзой внешнего производителя (конечно если Вы не работаете в Cadence)? Почему Вы доверяете RC Compiler и не доверяете Leonardo Spectrum?

1) "рассматривается вариант совместного использования синтезатора как для FPGA так и для ASIC" -
Как я понял, Вы хотите одни проекты как ASIC делать, а другие как FPGA. При этом, напр. XILINX ISE не подходит Вам для синтеза FPGA по какой-то причине.
При этом цель - сэкономить на тулзах, например за счёт использования одного синтезатора.
Правильно?

Цены конечно продавец тулзов каждому свои ставит, но что-то мне подсказывает, что купить все необходимые тулзы Cadence для ASIC вместе с синтезатором будет не так-то и дорого.
Да и навернека Cadence тулзы раз в 100 (я думаю гдето около 1 000 000$ год на ASIC flow) дороже Леонардов.... Смысл на спичках экономить?

Для исключения всяких ненужных проблем с совместимостью, а также для использования продвинутых возможностей оптимизации - лутше использовать тулзы одного производителя.
Есть и другие моменты, кроме тайминг оптимизации... Например ECO (Engineering change Order ) требует синтезатора, CONFORMAL тоже его хочет.... Хочеш, не хочеш - а купиш....
Placement может розпознать DFT структуры и сделать их реордеринг, а с внешне встроенным DFT - нет... А как синтезить мультиповер, мультиклок домены, а гейтыд клок компоненты для power optimization тоже Леонардо встроит? ... и.т.д.

- Я Вам крайне не советую лезть в предложенный производителем набор тулзов и flow for ASIC.
- Точно определите что Вам понадобится в flow for ASIC.
- В крайнем случае уточните все моменты с Cadence или Synopsys....

2) " Разве RC Compiler не является для Вас тулзой внешнего производителя " - у меня Cadence ASIC flow.

Да.


Это вы имели ввиду Front End и Back End тулзы? Или тольлько один из "End"?


С современным Лео не сталкивался. А с тем что сталкивался - тот power optimization не делал.



Спасибо за совет. Буду и с ними разбираться.

1) Я имелл в виду стоимость всего необходимого набора Back End: RCCompiler+SOCEncounter+ETS+EPS+Conformal+EncounterTest
Годовые лицензии реально дорогие...
Если брать лицензии поштучно и только минимальный набор (напр. без MMMC, без multiply power domain) то может дешевле...
Тут надо точно необходимые возможности представлять.... думаю грамотный выбор сэкономит на пару Леонардов....
Кстати, сколько Лео стоит?

2) power optimization любимое дело для ASIC....

Какая-то сомнительная штука. Что они там такое оптимизируют...? Самая лучшая оптимизация по потреблению - это минимизация схемы (площади), чем меньше сделаешь, тем меньше будет потребление... Хотя это уже вопрос не по теме топика...

"Самая лучшая оптимизация по потреблению - это минимизация схемы (площади), чем меньше сделаешь, тем меньше будет потребление..." - частично правильно но...
1) чем меньше площадь - тем меньше токи утечки - меньше потрибление в спящем режиме (когда клок отключен)
2) основная мощность потребления - это динамический ток, обусловленный частотой переключения тригеров и их количеством.
В реальных схемах меняет состояние только порядка 10% тригеров, а это значит что на остальные тригера фронт клока подавать не надо.
Тригер на который не подаётся фронт клока потребляет меньше, даже если не меняет состояние.
Для этого гейтыд клоки и используются.

Так как это автоматом в САПР сделать? Как автоматом определить какие части схемы отключать от синхросигнала? Я считал, что такое может делать только разработчик. Или это уже делает САПР вместо него?