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

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% доверия тут нет, ошибаются все.

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


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

Из практики могу сказать, что в "дизайн фло" нету ничего "обязательного"

Тут не аероспейс где без освещения файнал тест протонов не проходит :)

Можна и нужно понимать зачем что делается и когда можно что исключить и с каким риском.

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


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

Для ASIC как раз прогонка с огневый тестом обязательна. Слишком дорого стоит допустить ошибку, если кто-то другой не доделал свою работу. Особенно это относится к таймингам. Иногда проще поправить функцию мелкого блока в новой ревизии, чем фиксить тайминги.

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

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


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

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

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

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

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

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

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

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

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

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