Перейти к содержанию
    

SystemVerilog [RTL] & ASIC Design Flow

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

Прежде всего интересуют тулы: DC, Formality (по нему в гайде вообще не нашёл описание поддерживаемого подмножества конструкций), Synplify.

 

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

Позиция RTL-кодеров такова:

Кодеры понимают преимущества SV, не только для упрощения описания некоторых аспектов и сокращения объёма кода и человеческого фактора (использование интерфейсов на топ-левеле, свои типы данных), но и удобство верификации (enum, однозначное описание регистровой и комбинационной логики) и не хотели бы снижать скорость и качество кода даунгрейдом до Verilog-2001.

 

Позиция ярых консерваторов такова:

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

В числе компаний, которые не пользуются SV для RTL: ARM, Imagination, Synopsys (IP).

 

 

PS: Доп.информация:

RTL пишем для себя, на сторону не передаём,

субподрядчиков нет - делаем всё сами до GDSII.

 

 

Хотелось бы услышать За и Против из личного опыта (жлательно также указать к каким версия тула опыт применителен)

 

Спасибо

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

SV используется вместе с Verilog.

У коллег иногда возникало желания вытащить серьезные интерфейсы и на верхний уровень, но это показало себя не очень friendly к иерархической разработке топологии.

Как я понимаю, в глубине всё это применяется.

Использовали 2014.09 релиз указанных выше вещей. Работает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

SV не используется. Тулчейн был и Cadence, и Synopsys.

 

Причина простая: чтобы иметь возможность очевидного доступа к любому элементу проекта, например для STA, нужно сильно ограничивать синтезируемое подмножество. Примерно до уровня: агрегатные типы можно, а интерфейсы, например, уже нельзя, т.к. не вполне понятно, как получить доступ к элементам, в которые они синтезировались. Аналогично с synthesized assertions.

 

Т.о. от всего великолепия остается совсем немного, плюс нужно настраивать LINT, чтобы за рамки этого "немного" при описании не выходить, плюс нужно покупать SV лицензию для синтезатора и LEC. Итог: объем возни превозмогает выгоду.

 

Отмечу, что это "немного" прекрасно есть в VHDL, при том, что там всё известно и понятно.

 

С другой стороны, если к синтезатору и LEC сейчас идет внятное описание, что, как и куда синтезируется, то можно попробовать.

 

На перечисленные вами компании, продающие IP, ориентироваться особо не стоит. Их задача - охват рынка. А также исторические аспекты.

 

Никто не мешает делать RTL на V2001, а верификационную оснастку на SV.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Fat Robot,

я так понимаю для STA основные ограничения только на использование интерфейсов?

 

по LEC пока непонятно.

 

по лицензиям (могу ошибаться - сейчас эвал юзается), но для DC/Formality фича SV входила/входит в Verilog, а вот для VCS надо уже SV отдельно докупать.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Но вот например, есть у вас в интерфейсе task. Как он синтезируется? Кому будут принадлежать элементы? Как оставить для инстанса такого интерфейса группировку при синтезе?

 

Есть книга: SystemVerilog for Design Second Edition: A Guide to Using SystemVerilog for Hardware Design and Modeling

Там худо-бедно описано, что к чему. Устроит ли она критиков SV? Готова ли компания инвестировать в освоение и проверку идей из нее? Насколько я понимаю, решение об использовании SV нужно принять "на берегу".

 

Ну и конечно идея "RTL описание - лишь 10% ресурсов" не играет на руку энтузиастам SV RTL.

 

я так понимаю для STA основные ограничения только на использование интерфейсов?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Мы тоже всё делаем для себя. Передаем только внутри организации.

Достаточно много используем SV - включая интерфейсы. Были проблемы с Conformal, но, вроде, Cadence достаточно быстро их решил. С DC и VCS - практически не было проблем.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Дело в том, что синтез должны делать те же люди, что и писать RTL (это называется Front-End). Предлагаю простой тест - выясните, насколько Ваши RTLщики знают STA. Ведь большинство RTL'щиков - прежде всего программеры, и в цифровой электронике совершенно безграмотны (даже если умело тычут паяльником, и лихо крутят кнопки осциллографа). И похоже, это Ваш случай - низко квалифицированные RTL'щики с кучей амбиций. В этой ситуации имеет смысл слушать тех, кто делает синтез - у них больше опыта и выше ответственность. Уверен, они и RTL напишут замечательно, если понадобится.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Прежде всего интересуют тулы: DC, Formality (по нему в гайде вообще не нашёл описание поддерживаемого подмножества конструкций), Synplify.

 

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

Позиция RTL-кодеров такова:

Кодеры понимают преимущества SV, не только для упрощения описания некоторых аспектов и сокращения объёма кода и человеческого фактора (использование интерфейсов на топ-левеле, свои типы данных), но и удобство верификации (enum, однозначное описание регистровой и комбинационной логики) и не хотели бы снижать скорость и качество кода даунгрейдом до Verilog-2001.

 

Позиция ярых консерваторов такова:

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

В числе компаний, которые не пользуются SV для RTL: ARM, Imagination, Synopsys (IP).

 

Позвольте и свои 5 копеек вставить...

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

2) Для RTL немного сложнее....

Могут быть ограничения из-за тупой реальности: заказчики не принимают в SV (милитари, спейс), уже всё описано на Верилоге 2001 и надо продолжать поддержку, Вы делаете миксид сигнал симуляцию и ваш симулятор не проддерживает SV...

 

Если таких ограничений нет, то конечно стоит использовать новые возможности.

Никого-ж не смущает например что Cadence Encounter от верси и к версии имеет по разному настроенное и работающее ядро для STA (хрен и заметиш) и силикон работать будет "странно".

Почему тогда проблема перепроверять ваш код на правильность синтеза? Проверили в своём фло - синтезилось правильно - пользуйтесь :)

Да и вообще, почему прохождение бек-энд фло не часть процеса верификации IP?

 

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

Т.е. в новых версиях IP ядро может и не синтезится как надо.... а вдругой тулзе и вообще не синтезится...

 

Я советую использовать SV для синтеза только в той части что действительно упрощает кодинг ( использование интерфейсов на топ-левеле очень улутшает читабельность кода).

Все остальные супер-програмистские навороты лутше отложить пока.... Ну и перед использованием SV для синтеза верифицировать код в бек-энде.

 

.....Предлагаю простой тест - выясните, насколько Ваши RTLщики знают STA. Ведь большинство RTL'щиков ....

RTL'щик знающий STA (и что такое синхронный дизайн с Back-End) это такая-же редкость как и Преподаватель сопромата с обложки Playboy :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Дело еще в том, что когда разные люди занимаются разными этапами маршрута, возникает вопрос контроля качества выходной информации на этапах маршрута. К примеру, что такое качественный синтез? Это результат (нетлист и констрейнты), оптимизированный под топологию, т.е. проведенный с учетом расстановки макроблоков, и с учетом будущих клоковых деревьев. А что такое качественный RTL? Разработчик RTL, не знакомый с тулами синтеза для ASIC, в лучшем случае попытается синтезнуть проект в квартусе или синплифае. И ему бесполезно потом говорить, что его RTL кривой, если этот код заработал в ПЛИС. Поэтому я и пишу, что синтез должен делать сам разработчик - только в этом случае качество RTL (и результата) будет высоким. А как он будет писать, использует SV или верилог - вопрос вообще второстепенный, потому что разработчик результат своего этапа контролирует. В случае, если синтез делает один человек, а RTL пишет другой, такой контроль не возможен, и лучше использовать старый проверенный верилог, imho.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

.... В случае, если синтез делает один человек, а RTL пишет другой, такой контроль не возможен, и лучше использовать старый проверенный верилог, imho.

Написать универсальный RTL для IP пригодный для синтеза в любых технологиях и тулзах можно.

Теряя на времени разработки, оптимальности по скорости\площади итп.

Тут может помочь например Cadence HAL чекер - если там нет варнингов, почти наверняка нет проблем в синтезе.

Остальное - упёртость RTLщика и нежилание писать под STA & Back-End - это просто неуважение к колегам. Вопрос к менеджменту а не по технике.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Верификация: SV, Specman.

Код только на Verilog 2001, даже не VHDL.

Design flow полностью на synopsys, кроме моделирования на ncsim.

 

В реальности и то и другое на Verilog, поскольку в работе нужна только обвязка для работы с текстовыми данными, а для того чтобы настроить настоящий рабочий enviroment потребует столько же времни, как и сам дизайн с верификацией, если не больше.

 

То что синтез прошел, абсолютно не факт что EC сойдется, иногда и DC делает косяки, причем от версии к версии это плавает.

В принципе если EC сошелся, то проблем нет, но что делать в случае ECO, есть вероятность того что на столь высоком уровне поправить это будет проблематично. flattern иногда отключаешь, чтобы без потом был шанс поправить, а тут ...

 

К правильному коду надо прийти, понять, что несмотря на все моментные преимущества, лучше делать стабильный, хоть и дубовый код. Меньше проблем, лучше понимание.

Предпочтительно если дизайнер сам пройдет хотя бы минимальный flow из lint & code coverage & DC.

 

P.S. Что есть STA, Static Analysis, тогда зачем под него писать ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Используйте для RTL только Verilog. SystemVerilog только в верификации(для чего собственно он и был создан). Мне кажется это оптимальное решение.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Используйте для RTL только Verilog. SystemVerilog только в верификации(для чего собственно он и был создан). Мне кажется это оптимальное решение.

 

Ну зачем же так консервативно? SV реально местами упрощает процесс проектирование и последующей модификации. Просто это нужно делать осторожно и не сидеть на древних версиях тулов. Я например заранее проверяю синтезом в DC конструкции, которые вызывают подозрение.

Изменено пользователем Djamal

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Синтезил достаточно большой проект в DC12.06. Использовались конструкции типа interface. Синтезатор их прожевывает, но в итоге компиляция завершалась с fatal error. Добавил в эти конструкции modport (указывает направление портов) и все стало компилиться без ошибок. Видимо DС не любит порты inout внутри иерархии. Более новые версии DC не имею.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

за лицензию SV, по-моему, дополнительных денег не берут

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...