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

    

SystemVerilog [RTL] & ASIC Design Flow

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

 

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

У синопсиса не берут.

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


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

Офигеть активный форум :)))

Итак, прошло три года со времени моего последнего поста...

Пишу на SV. Интерфейсы нравятся.... да и тулзы всё отлично поддерживают.

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


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

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

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


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

Как-то до дебага нетлиста ни разу не доходили.... 

Если есть причини симулить нетлист (какие?) то тест бенчи пишутся с минимальным подключением к внутренним сигналам и с ограниченными проверками

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


Ссылка на сообщение
Поделиться на другие сайты
6 hours ago, topor_topor said:

Если есть причини симулить нетлист (какие?)

Статический (STA) и временной (timing simulation) анализ, это два близких подхода, имеющие как пересечения, так и эксклюзивные области. В чем эксклюзив временной верификации - выявляет ошибки в констрейнтах интерфейсов, и ошибки в коде - там, где есть CDC. Т.е. покрытие у тестов дожно быть в областях CDC и интерфейсов, причем один набор тестов для проверок setup, второй для Hold. Cимуляцию надо пускать сразу после CTS, с исправленным холдами - выявление багов на раннем этапе. Ну и пост-лейаут симуляция, разумеется. Так что STA отнюдь не достаточно для timing SignOFF.

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


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

Согласен с вышеуказанным, проверка нетлиста. В дополнение добавлю power estimation, pda симуляция для оценки мощности.

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


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

Для ошибок CDC рекомендую статический анализ в Conformal или SpyGlass CDC. timing simulation  не всё увидиш.

Особенно когда приходится иметь дело с сопровождением большого проекта, или стороннего проекта и особенно когда в CDC накручено и нет внятного описания что и зачем накручено (для ревью). Эти тулзи красиво показывают часть схемы с проблемами.

 

timing simulation на нетлисте с SDF позволяет "верифицировать" констрейны из SDC (и-то частично), посмотреть времянки с задержками (например тайминги на памяти, внешнем интерфейсе). 

Подтвердить сетап\холды можно частично потому, что SDF обычно делают на ворст-типикал-бест корнеры, а силикон может не работать в  каком-то промежуточном корнере (это из практики).

Нетлист используется для "точного" расчёта рассеиваемой мощности. Примерный можна и при синтезе получить.

 

----

Если CDC просто и прозрачно сделано, когда нет трюков с SDC, и точно мощность считать не надо - то можно и не симулить нетлисты. Особенно в следующей версии дизайна.

 

 

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


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

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

- симулировать необходимо ровно те же корнеры, что являются mandatory для STA SignOff. Их бывает до двух десятков. Как уже писал, STA не заменяет, а дополняет симуляцию, это касается и корнеров.

- оценка потребления на синтезе имеет точность +/-50%, по очевидным причинам. И никогда не сравнится с анализом post-CTS базы с реальным вектором из симуляции. Векторная оценка потребления - обязательна уже на 65нм.

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

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


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

Симуляция обязательна для лакировки таймингов.

Потребление оценивается для худшего и стандартного сценария в составе всего SoC. Информация из синтеза как некий сферический конь в вакууме и практически никому не нужна.

 

Spyglass  позволяет сделать кросс проверку результатов синтеза, а также позволяет проверить весь чип в составе разных блоков. 100% доверия тут нет, ошибаются все.

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


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

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти