SystemVerilog [RTL] & ASIC Design Flow, За и Против Опции

[Doka]

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

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

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

Позиция ярых консерваторов такова:
несмотря на то, что SV давно поддерживается тулами, поддержка эта только на бумаге, из-за того что этими конструкциями никто не пользуется и тул не проверен (пользователи как тестеры не репортовали о багах).
В числе компаний, которые не пользуются SV для RTL: ARM, Imagination, Synopsys (IP).


PS: Доп.информация:
RTL пишем для себя, на сторону не передаём,
субподрядчиков нет - делаем всё сами до GDSII.


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

Спасибо

[sleep]

Доброго времени суток!
В нашем случае, получается, для новых дизайнов побеждают (в этой терминологии) прогрессивные RTL-кодеры.
SV используется вместе с Verilog.
У коллег иногда возникало желания вытащить серьезные интерфейсы и на верхний уровень, но это показало себя не очень friendly к иерархической разработке топологии.
Как я понимаю, в глубине всё это применяется.
Использовали 2014.09 релиз указанных выше вещей. Работает.

[Fat Robot]

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

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

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

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

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

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

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

[Doka]

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

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

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

[Fat Robot]

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

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

Есть книга: SystemVerilog for Design Second Edition: A Guide to Using SystemVerilog for Hardware Design and Modeling
Там худо-бедно описано, что к чему. Устроит ли она критиков SV? Готова ли компания инвестировать в освоение и проверку идей из нее? Насколько я понимаю, решение об использовании SV нужно принять "на берегу".

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

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

[masics]

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

[Shivers]

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

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

[Torpeda]

Прошу высказаться у кого есть опыт (удачный, а в особенности - неудачный) использования поддерживаемых тулами 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

[Shivers]

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

[Torpeda]

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

Написать универсальный RTL для IP пригодный для синтеза в любых технологиях и тулзах можно.
Теряя на времени разработки, оптимальности по скорости\площади итп.
Тут может помочь например Cadence HAL чекер - если там нет варнингов, почти наверняка нет проблем в синтезе.
Остальное - упёртость RTLщика и нежилание писать под STA & Back-End - это просто неуважение к колегам. Вопрос к менеджменту а не по технике.

[lexx]

Верификация: 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, тогда зачем под него писать ?

[gerbity]

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

[Djamal]

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

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

Сообщение отредактировал Djamal - Jun 30 2016, 12:21

[cega]

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

[yes]

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

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