реклама на сайте
подробности

 
 
2 страниц V   1 2 >  
Reply to this topicStart new topic
> SystemVerilog [RTL] & ASIC Design Flow, За и Против
Doka
сообщение Oct 28 2015, 16:34
Сообщение #1


Electrical Engineer
******

Группа: СуперМодераторы
Сообщений: 2 160
Регистрация: 4-10-04
Пользователь №: 778



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

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

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

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


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


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

Спасибо
Go to the top of the page
 
+Quote Post
sleep
сообщение Oct 28 2015, 16:44
Сообщение #2


Частый гость
**

Группа: Свой
Сообщений: 77
Регистрация: 21-09-06
Из: msk
Пользователь №: 20 563



Доброго времени суток!
В нашем случае, получается, для новых дизайнов побеждают (в этой терминологии) прогрессивные RTL-кодеры.
SV используется вместе с Verilog.
У коллег иногда возникало желания вытащить серьезные интерфейсы и на верхний уровень, но это показало себя не очень friendly к иерархической разработке топологии.
Как я понимаю, в глубине всё это применяется.
Использовали 2014.09 релиз указанных выше вещей. Работает.
Go to the top of the page
 
+Quote Post
Fat Robot
сообщение Oct 28 2015, 20:14
Сообщение #3


ʕʘ̅͜ʘ̅ʔ
*****

Группа: Свой
Сообщений: 1 005
Регистрация: 3-05-05
Пользователь №: 4 691



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

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

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

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

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

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

Никто не мешает делать RTL на V2001, а верификационную оснастку на SV.
Go to the top of the page
 
+Quote Post
Doka
сообщение Oct 28 2015, 20:27
Сообщение #4


Electrical Engineer
******

Группа: СуперМодераторы
Сообщений: 2 160
Регистрация: 4-10-04
Пользователь №: 778



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

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

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



--------------------
Блог iDoka.ru
CV linkedin.com/in/iDoka
Sources github.com/iDoka


Never stop thinking...........................
Go to the top of the page
 
+Quote Post
Fat Robot
сообщение Oct 28 2015, 21:01
Сообщение #5


ʕʘ̅͜ʘ̅ʔ
*****

Группа: Свой
Сообщений: 1 005
Регистрация: 3-05-05
Пользователь №: 4 691



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

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

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

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

Цитата(Doka @ Oct 28 2015, 21:27) *
я так понимаю для STA основные ограничения только на использование интерфейсов?
Go to the top of the page
 
+Quote Post
masics
сообщение Oct 28 2015, 21:05
Сообщение #6


Местный
***

Группа: Свой
Сообщений: 399
Регистрация: 21-02-05
Из: Melbourne, Australia
Пользователь №: 2 779



Мы тоже всё делаем для себя. Передаем только внутри организации.
Достаточно много используем SV - включая интерфейсы. Были проблемы с Conformal, но, вроде, Cadence достаточно быстро их решил. С DC и VCS - практически не было проблем.
Go to the top of the page
 
+Quote Post
Shivers
сообщение Oct 29 2015, 08:12
Сообщение #7


Знающий
****

Группа: Свой
Сообщений: 680
Регистрация: 11-02-08
Из: Msk
Пользователь №: 34 950



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

И еще, это должно быть политическое решение руководства, а не кворум. Ведь Вы уже сами озвучили исключительно веский аргумент - многие крупные производители IP до сих пор пишут синтезируемую часть на verilog, а SV используют только для верификации. Вашему стартапу имеет смысл идти проторенными путями и не экспериментировать, ведь в конечном счете Вы должны выстрелить работающим кремнием, а для этого надо снижать риски к минимуму.
Go to the top of the page
 
+Quote Post
Torpeda
сообщение Oct 29 2015, 09:50
Сообщение #8


Местный
***

Группа: Свой
Сообщений: 426
Регистрация: 23-02-12
Пользователь №: 70 424



Цитата(Doka @ Oct 28 2015, 19:34) *
Прошу высказаться у кого есть опыт (удачный, а в особенности - неудачный) использования поддерживаемых тулами 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 (хрен и заметиш) и силикон работать будет "странно".
Почему тогда проблема перепроверять ваш код на правильность синтеза? Проверили в своём фло - синтезилось правильно - пользуйтесь sm.gif
Да и вообще, почему прохождение бек-энд фло не часть процеса верификации IP?

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

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

Цитата(Shivers @ Oct 29 2015, 11:12) *
.....Предлагаю простой тест - выясните, насколько Ваши RTLщики знают STA. Ведь большинство RTL'щиков ....

RTL'щик знающий STA (и что такое синхронный дизайн с Back-End) это такая-же редкость как и Преподаватель сопромата с обложки Playboy sm.gif
Go to the top of the page
 
+Quote Post
Shivers
сообщение Oct 29 2015, 11:50
Сообщение #9


Знающий
****

Группа: Свой
Сообщений: 680
Регистрация: 11-02-08
Из: Msk
Пользователь №: 34 950



Дело еще в том, что когда разные люди занимаются разными этапами маршрута, возникает вопрос контроля качества выходной информации на этапах маршрута. К примеру, что такое качественный синтез? Это результат (нетлист и констрейнты), оптимизированный под топологию, т.е. проведенный с учетом расстановки макроблоков, и с учетом будущих клоковых деревьев. А что такое качественный RTL? Разработчик RTL, не знакомый с тулами синтеза для ASIC, в лучшем случае попытается синтезнуть проект в квартусе или синплифае. И ему бесполезно потом говорить, что его RTL кривой, если этот код заработал в ПЛИС. Поэтому я и пишу, что синтез должен делать сам разработчик - только в этом случае качество RTL (и результата) будет высоким. А как он будет писать, использует SV или верилог - вопрос вообще второстепенный, потому что разработчик результат своего этапа контролирует. В случае, если синтез делает один человек, а RTL пишет другой, такой контроль не возможен, и лучше использовать старый проверенный верилог, imho.
Go to the top of the page
 
+Quote Post
Torpeda
сообщение Oct 29 2015, 12:30
Сообщение #10


Местный
***

Группа: Свой
Сообщений: 426
Регистрация: 23-02-12
Пользователь №: 70 424



Цитата(Shivers @ Oct 29 2015, 14:50) *
.... В случае, если синтез делает один человек, а RTL пишет другой, такой контроль не возможен, и лучше использовать старый проверенный верилог, imho.

Написать универсальный RTL для IP пригодный для синтеза в любых технологиях и тулзах можно.
Теряя на времени разработки, оптимальности по скорости\площади итп.
Тут может помочь например Cadence HAL чекер - если там нет варнингов, почти наверняка нет проблем в синтезе.
Остальное - упёртость RTLщика и нежилание писать под STA & Back-End - это просто неуважение к колегам. Вопрос к менеджменту а не по технике.
Go to the top of the page
 
+Quote Post
lexx
сообщение Oct 30 2015, 14:48
Сообщение #11


Частый гость
**

Группа: Свой
Сообщений: 117
Регистрация: 25-06-04
Пользователь №: 186



Верификация: 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, тогда зачем под него писать ?
Go to the top of the page
 
+Quote Post
gerbity
сообщение Nov 2 2015, 09:04
Сообщение #12


Участник
*

Группа: Участник
Сообщений: 17
Регистрация: 2-11-15
Из: Москва, Зеленоград
Пользователь №: 89 137



Используйте для RTL только Verilog. SystemVerilog только в верификации(для чего собственно он и был создан). Мне кажется это оптимальное решение.
Go to the top of the page
 
+Quote Post
Djamal
сообщение Jun 30 2016, 12:20
Сообщение #13


Участник
*

Группа: Участник
Сообщений: 22
Регистрация: 14-05-11
Из: Зеленоград
Пользователь №: 64 999



Цитата(gerbity @ Nov 2 2015, 12:04) *
Используйте для RTL только Verilog. SystemVerilog только в верификации(для чего собственно он и был создан). Мне кажется это оптимальное решение.


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

Сообщение отредактировал Djamal - Jun 30 2016, 12:21
Go to the top of the page
 
+Quote Post
cega
сообщение Feb 19 2018, 14:22
Сообщение #14





Группа: Новичок
Сообщений: 3
Регистрация: 18-03-09
Пользователь №: 46 251



Синтезил достаточно большой проект в DC12.06. Использовались конструкции типа interface. Синтезатор их прожевывает, но в итоге компиляция завершалась с fatal error. Добавил в эти конструкции modport (указывает направление портов) и все стало компилиться без ошибок. Видимо DС не любит порты inout внутри иерархии. Более новые версии DC не имею.
Go to the top of the page
 
+Quote Post
yes
сообщение Feb 19 2018, 15:11
Сообщение #15


Гуру
******

Группа: Свой
Сообщений: 2 184
Регистрация: 23-12-04
Пользователь №: 1 640



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

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

Go to the top of the page
 
+Quote Post

2 страниц V   1 2 >
Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 18th September 2018 - 20:18
Рейтинг@Mail.ru


Страница сгенерированна за 0.02037 секунд с 7
ELECTRONIX ©2004-2016