[topor_topor 0]

Как Вы думаете, стоит ли рассматривать вопрос синтеза ASIC с помощью Leonardo Spectrum как серьезный?

Предположим речь идет о проекте 1 миллион эквивлентных вентилей по технологии, например, TSMC 90nm.

Основная рабочая частота 100..200МГц.

 

Синтез можно делать в чём угодно - на выходе всё равно нетлист.

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

 

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

 

[nikolascha 0]

Как Вы думаете, стоит ли рассматривать вопрос синтеза ASIC с помощью Leonardo Spectrum как серьезный?

Предположим речь идет о проекте 1 миллион эквивлентных вентилей по технологии, например, TSMC 90nm.

Основная рабочая частота 100..200МГц.

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

 

[madgarry 0]

Синтез можно делать в чём угодно - на выходе всё равно нетлист.

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

 

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

Речь идет о выборе маршрута проектирования ASIC. И выбор синтезатора - как одного из компонентов этого маршрута.

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

[nikolascha 0]

Но у меня есть некоторые сомнения по поводу того насколько результат синтеза будет близок к реалиям связанным с размещение компонентов на кристалле. Не придется ли исполнять танцы с бубном при выполнении timing closure?

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

[madgarry 0]

Тут не совсем понятно, что вы конкретно имеете в виду под "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 проекте.

[nikolascha 0]

Но меня смущает тот факт что я пока не находил в интернете "suсcess story" использования Leonardo Spectrum в реальном ASIC проекте.

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

 

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

[zzzzzzzz 0]

....Но меня смущает тот факт что я пока не находил в интернете "suсcess story" использования Leonardo Spectrum в реальном ASIC проекте.

Ожидания хорошие, но важно именно насколько "success". С Лео разработано полно чипов, которые живут в аппаратуре давно.

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

Это ж удел коммерческих "монстров" от электроники.

Да и то, целиком такую кучу "вывалить" не целесообразно.

Все более склонны к сборкам из более мелких модулей. И это логично.

 

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

[madgarry 0]

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

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

 

Ожидания хорошие, но важно именно насколько "success". С Лео разработано полно чипов, которые живут в аппаратуре давно.

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

Это ж удел коммерческих "монстров" от электроники.

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

По текущему обсуждению я понял что сделать чип с использование Лео возможно, но вот вопрос о "весе" проекта вопрос для меня все еще остается открытым.

 

Да и то, целиком такую кучу "вывалить" не целесообразно.

Все более склонны к сборкам из более мелких модулей. И это логично.

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

[nikolascha 0]

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

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

[zzzzzzzz 0]

...

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

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

[topor_topor 0]

Речь идет о выборе маршрута проектирования ASIC. И выбор синтезатора - как одного из компонентов этого маршрута.

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

 

Может чё-то я не так понял... с Леонардо не работал но всёже...

Мне кажется Вы путаэте 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 наверно всётаки надо....

 

 

[madgarry 0]

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

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

 

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

 

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

 

Может чё-то я не так понял... с Леонардо не работал но всёже...

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

Все вещи связанные с timing closure выполняются на стиадии Place & Route.

 

1) "...насколько результат синтеза будет близок к реалиям связанным с размещение компонентов на кристалле" -

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

Поэтому, наверно лутше работать с тулзами одного производителя (чтобы они понимали друг друга)

 

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

Поэтому вопрос " близок к реалиям связанным с размещение компонентов на кристалле" не совсем коректен.

Синтез и P&R я не подменяю - я их связываю. Собственно вариантов синтеза я вижу уже три:

1-Синтез баз учета wire load model;

2-Синтез с учетом wire load model;

3-Синтез с учетом топологии кристалла (реально не сталкивался но на этой ветке данный вопрос обсуждался);

Думаю что последний вариант доставит минимум проблем с "timing violations" при P&R

-

2) О каком "timing closure" речь?

Фактически финальный "timing closure" выполняется на этапе Place & Route.

При этом понятно что синтезатор не причём...

И связывать вопрос о "timing closure" с синтезатором не коректно.

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

 

3) Чего то так рогом в синтез упираться?

Если что-то можно синтезить в FPGA то оно легко синтезится и в ASIC тулзе - типа RC Compiler.

С синтезом синхронных дизайнов - проблем нет.

 

Другое дело если есть необходимость встроить асинхронщину, или какие другие трюки - то это таки зависит от способностей тулзы.

Вы лутше подумайте может ли Леонардо встраивать DFT структуры. Тестировать Ваш ASIC наверно всётаки надо....

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

Ну а с DFT у Лео все хорошо, а вот про возможность синтеза "gated clock" - пока неизвестно.

[topor_topor 0]

Синтез и 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 синтезаторе на худой конец....

 

Изменено 11 апреля, 2012 пользователем Torpeda

[madgarry 0]

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 подсунуть....

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

 

5) "возможность синтеза "gated clock" - пока неизвестно"

Если у вас gated clock, то какой смысл говорить об FPGA?

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

 

Как ASIC я-бы очень был-бы недоволен делать синтез в тулзе внешнего производителя, тем более заточенного под FPGA.

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

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

[topor_topor 0]

Говорят что Лео и Синплифай справляются с задачей синтеза лучше чем родной 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.

Изменено 12 апреля, 2012 пользователем Torpeda