|
SystemVerilog [RTL] & ASIC Design Flow, За и Против |
|
|
|
Oct 28 2015, 16:34
|
Electrical Engineer
Группа: СуперМодераторы
Сообщений: 2 163
Регистрация: 4-10-04
Пользователь №: 778
|
Прошу высказаться у кого есть опыт (удачный, а в особенности - неудачный) использования поддерживаемых тулами Synopsys конструкций SystemVerilog. Прежде всего интересуют тулы: DC, Formality (по нему в гайде вообще не нашёл описание поддерживаемого подмножества конструкций), Synplify.
Ситуация: есть два лагеря (кодеры и малочисленная группа принимающих решение консерваторов), которые имеют диаметрально противоположные взгляды. Позиция RTL-кодеров такова: Кодеры понимают преимущества SV, не только для упрощения описания некоторых аспектов и сокращения объёма кода и человеческого фактора (использование интерфейсов на топ-левеле, свои типы данных), но и удобство верификации (enum, однозначное описание регистровой и комбинационной логики) и не хотели бы снижать скорость и качество кода даунгрейдом до Verilog-2001. Позиция ярых консерваторов такова: несмотря на то, что SV давно поддерживается тулами, поддержка эта только на бумаге, из-за того что этими конструкциями никто не пользуется и тул не проверен (пользователи как тестеры не репортовали о багах). В числе компаний, которые не пользуются SV для RTL: ARM, Imagination, Synopsys (IP).
PS: Доп.информация: RTL пишем для себя, на сторону не передаём, субподрядчиков нет - делаем всё сами до GDSII.
Хотелось бы услышать За и Против из личного опыта (жлательно также указать к каким версия тула опыт применителен)
Спасибо
|
|
|
|
|
Oct 28 2015, 20:14
|
ʕʘ̅͜ʘ̅ʔ
Группа: Свой
Сообщений: 1 008
Регистрация: 3-05-05
Пользователь №: 4 691
|
SV не используется. Тулчейн был и Cadence, и Synopsys.
Причина простая: чтобы иметь возможность очевидного доступа к любому элементу проекта, например для STA, нужно сильно ограничивать синтезируемое подмножество. Примерно до уровня: агрегатные типы можно, а интерфейсы, например, уже нельзя, т.к. не вполне понятно, как получить доступ к элементам, в которые они синтезировались. Аналогично с synthesized assertions.
Т.о. от всего великолепия остается совсем немного, плюс нужно настраивать LINT, чтобы за рамки этого "немного" при описании не выходить, плюс нужно покупать SV лицензию для синтезатора и LEC. Итог: объем возни превозмогает выгоду.
Отмечу, что это "немного" прекрасно есть в VHDL, при том, что там всё известно и понятно.
С другой стороны, если к синтезатору и LEC сейчас идет внятное описание, что, как и куда синтезируется, то можно попробовать.
На перечисленные вами компании, продающие IP, ориентироваться особо не стоит. Их задача - охват рынка. А также исторические аспекты.
Никто не мешает делать RTL на V2001, а верификационную оснастку на SV.
|
|
|
|
|
Oct 28 2015, 21:01
|
ʕʘ̅͜ʘ̅ʔ
Группа: Свой
Сообщений: 1 008
Регистрация: 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 основные ограничения только на использование интерфейсов?
|
|
|
|
|
Oct 29 2015, 08:12
|
Знающий
Группа: Свой
Сообщений: 680
Регистрация: 11-02-08
Из: Msk
Пользователь №: 34 950
|
Дело в том, что синтез должны делать те же люди, что и писать RTL (это называется Front-End). Предлагаю простой тест - выясните, насколько Ваши RTLщики знают STA. Ведь большинство RTL'щиков - прежде всего программеры, и в цифровой электронике совершенно безграмотны (даже если умело тычут паяльником, и лихо крутят кнопки осциллографа). И похоже, это Ваш случай - низко квалифицированные RTL'щики с кучей амбиций. В этой ситуации имеет смысл слушать тех, кто делает синтез - у них больше опыта и выше ответственность. Уверен, они и RTL напишут замечательно, если понадобится.
И еще, это должно быть политическое решение руководства, а не кворум. Ведь Вы уже сами озвучили исключительно веский аргумент - многие крупные производители IP до сих пор пишут синтезируемую часть на verilog, а SV используют только для верификации. Вашему стартапу имеет смысл идти проторенными путями и не экспериментировать, ведь в конечном счете Вы должны выстрелить работающим кремнием, а для этого надо снижать риски к минимуму.
|
|
|
|
|
Oct 29 2015, 09:50
|
Местный
Группа: Свой
Сообщений: 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 (хрен и заметиш) и силикон работать будет "странно". Почему тогда проблема перепроверять ваш код на правильность синтеза? Проверили в своём фло - синтезилось правильно - пользуйтесь Да и вообще, почему прохождение бек-энд фло не часть процеса верификации IP? Единственное что надо учитывать так это то, что не все возможности языка полно и правильно поддерживаются бек-энд тулзами. Т.е. в новых версиях IP ядро может и не синтезится как надо.... а вдругой тулзе и вообще не синтезится... Я советую использовать SV для синтеза только в той части что действительно упрощает кодинг ( использование интерфейсов на топ-левеле очень улутшает читабельность кода). Все остальные супер-програмистские навороты лутше отложить пока.... Ну и перед использованием SV для синтеза верифицировать код в бек-энде. Цитата(Shivers @ Oct 29 2015, 11:12) .....Предлагаю простой тест - выясните, насколько Ваши RTLщики знают STA. Ведь большинство RTL'щиков .... RTL'щик знающий STA (и что такое синхронный дизайн с Back-End) это такая-же редкость как и Преподаватель сопромата с обложки Playboy
|
|
|
|
|
Oct 29 2015, 11:50
|
Знающий
Группа: Свой
Сообщений: 680
Регистрация: 11-02-08
Из: Msk
Пользователь №: 34 950
|
Дело еще в том, что когда разные люди занимаются разными этапами маршрута, возникает вопрос контроля качества выходной информации на этапах маршрута. К примеру, что такое качественный синтез? Это результат (нетлист и констрейнты), оптимизированный под топологию, т.е. проведенный с учетом расстановки макроблоков, и с учетом будущих клоковых деревьев. А что такое качественный RTL? Разработчик RTL, не знакомый с тулами синтеза для ASIC, в лучшем случае попытается синтезнуть проект в квартусе или синплифае. И ему бесполезно потом говорить, что его RTL кривой, если этот код заработал в ПЛИС. Поэтому я и пишу, что синтез должен делать сам разработчик - только в этом случае качество RTL (и результата) будет высоким. А как он будет писать, использует SV или верилог - вопрос вообще второстепенный, потому что разработчик результат своего этапа контролирует. В случае, если синтез делает один человек, а RTL пишет другой, такой контроль не возможен, и лучше использовать старый проверенный верилог, imho.
|
|
|
|
|
Oct 29 2015, 12:30
|
Местный
Группа: Свой
Сообщений: 426
Регистрация: 23-02-12
Пользователь №: 70 424
|
Цитата(Shivers @ Oct 29 2015, 14:50) .... В случае, если синтез делает один человек, а RTL пишет другой, такой контроль не возможен, и лучше использовать старый проверенный верилог, imho. Написать универсальный RTL для IP пригодный для синтеза в любых технологиях и тулзах можно. Теряя на времени разработки, оптимальности по скорости\площади итп. Тут может помочь например Cadence HAL чекер - если там нет варнингов, почти наверняка нет проблем в синтезе. Остальное - упёртость RTLщика и нежилание писать под STA & Back-End - это просто неуважение к колегам. Вопрос к менеджменту а не по технике.
|
|
|
|
|
Oct 30 2015, 14:48
|
Частый гость
Группа: Свой
Сообщений: 118
Регистрация: 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, тогда зачем под него писать ?
|
|
|
|
|
Nov 2 2015, 09:04
|
Участник
Группа: Участник
Сообщений: 17
Регистрация: 2-11-15
Из: Москва, Зеленоград
Пользователь №: 89 137
|
Используйте для RTL только Verilog. SystemVerilog только в верификации(для чего собственно он и был создан). Мне кажется это оптимальное решение.
|
|
|
|
|
Jun 30 2016, 12:20
|
Участник
Группа: Участник
Сообщений: 22
Регистрация: 14-05-11
Из: Зеленоград
Пользователь №: 64 999
|
Цитата(gerbity @ Nov 2 2015, 12:04) Используйте для RTL только Verilog. SystemVerilog только в верификации(для чего собственно он и был создан). Мне кажется это оптимальное решение. Ну зачем же так консервативно? SV реально местами упрощает процесс проектирование и последующей модификации. Просто это нужно делать осторожно и не сидеть на древних версиях тулов. Я например заранее проверяю синтезом в DC конструкции, которые вызывают подозрение.
Сообщение отредактировал Djamal - Jun 30 2016, 12:21
|
|
|
|
|
Feb 19 2018, 14:22
|
Группа: Новичок
Сообщений: 3
Регистрация: 18-03-09
Пользователь №: 46 251
|
Синтезил достаточно большой проект в DC12.06. Использовались конструкции типа interface. Синтезатор их прожевывает, но в итоге компиляция завершалась с fatal error. Добавил в эти конструкции modport (указывает направление портов) и все стало компилиться без ошибок. Видимо DС не любит порты inout внутри иерархии. Более новые версии DC не имею.
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|