How I Learned UVM Verification: A Resource Guide

Примерно год назад я набросал список материалов по которым я бы учил SV и UVM, если бы делал это заново.
Сейчас я бы его оставил таким же, разве что стандарт на SV поместил бы в фоновый режим, т.е. всегда на столе — всегда почитываем.

Я к чему. Тут набрел на еще один верификаторский блог verification-explorer.com. И вот там последний пост как раз про то же самое - ресурсы для изучения. Добротная коллекция. Думаю она покрывает большинство значимых источников информации по верификации, которые существуют в вебе. Рекомендую.

#verification #system_verilog #uvm
@positiveslack

Пожалуйста, не повторяйте дома (да и на работе тоже)

#meme
@positiveslack

Constant Reference in SystemVerilog: Is It Really Constant?

Когда надо показать что в функцию аргумент передается по ссылке, и при этом внутри его никто не собирается модифицировать, то его можно пометить как const ref. Но какие на самом деле гарантии неизменяемости даёт симулятор?

Я провел микро-исследование в 5 симуляторах, и вполне ожидаемо получил следующее:

◽️Степень защиты от изменения сильно разнится от симулятора к симулятору. Особенно когда речь про класс и его члены.
◽️Можно намеренно или случайно написать код, непереносимый между симуляторами.
◽️В итоге, const ref хорош в основном только как хинт, чтобы выразить свои намерения другому программисту, хотя и даёт некоторые безусловные гарантии.

#system_verilog
@positiveslack

VCDrom

Огненный плагин к VSCode от Алексея Чепыженко (автор wavedrom), чтобы смотреть VCD вейвы прямо в IDE.

Демо на ютубе

#vscode
@positiveslack

Использование pip для менеджмента HDL компонентов

Внимание, сейчас пойдет пропаганда нетрадиционной разработки. Расслабьтесь и отбросьте все предрассудки.

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

Концепт
Справедливости ради, уже есть довольно известные попытки решить эту проблему, построив свою систему с нуля, например, FuseSoc.
Но что если взять пакетный менеджер от любого популярного ЯП и приспособить его к HDL? Я выбрал питоний pip для эксперимента, потому что питон очень прочно и быстро закрепляется в HDL мире, pip есть примерно везде, пакеты очень легко создавать, публиковать и вкладывать в них что угодно, а еще потому что я так захотел.

Прототип
В принципе, ничего не нужно для того чтобы распространять HDL через pip. Просто запаковал и опубликовал любым удобным способом в локальное или глобальное хранилище. Однако, потом для компиляции захочется получить путь до исходников или путь до файллиста, или что-то ещё. Поэтому я подобный и иной бойлерплейт скрыл внутри пакета pip-hdl. В итоге, чтобы собрать пакет с HDL нужно всего два экстра файла на 5-10 строк. Да и те можно сгенерировать автоматически.
Вот мой proof-of-concept: гитхаб, детальный гайд и примеры.

Итог
В результате быстро и дёшево имеем всю мощь pip для какого-нибудь UVM агента или иного компонента с понятным контролем зависимостей, версионированием и способом доставки на машину. Разве это не прекрасно?

#python #automation
@positiveslack

Verilator + SVUnit [2]

FYI, тут не всё так однозначно. Сам SVUnit тестировался на Verilator v5.012, и как показывает практика работает и на v5.014, v5.016.
Но на v5.018, v5.020, v5.022 уже не работает.

Хорошая новость в том, что я зарепортил баг в верилятор, и он был почти мгновенно починен. Так что с +v5.023 всё снова должно работать.
Здоровья и долгих лет жизни мистеру Снайдеру.

#verilator #svunit
@positiveslack

Ну и в догонку найденное в тикетах SVUnit. То самое чувство, когда любишь опенсорс и верификацию, но времени хватает только на то, чтобы контрибьютить со смартфона в туалете.
Это не было бы так смешно, если бы не было так жизненно🙈

#meme
@positiveslack

1800-2023 - IEEE Standard for SystemVerilog

SV-2023 in da house! На этой неделе на DVCon 2024 презентовали новый стандарт.

Дейв отписался в блоге Siemens, что он свободно доступен через IEEE Get Program. Однако, нужна регистрация чтобы его скачать. Товарищи, может кто-то сможет помочь?

#system_verilog
@positiveslack

IEEE Standard for SystemVerilog 2023

#system_verilog
@positivelsack

Ну и как без мемеса на тему
#meme
@positiveslack

Considering SystemVerilog Tagged Unions

Хотел бы стряхнуть пыль с похоже всеми забытой фичи, которая вместе с нами аж с SV-05 - tagged union. Тут нашлась неплохая статья на эту тему с размышлениями из разряда "а как бы мы могли это юзать, если бы оно нормально поддерживалось".

На первый взгляд, суть фичи может показаться несколько странной, но на самом деле это вполне себе каноничный "sum type" или тип-сумма из теории типов. Он позволяет выразить структуру данных, хранящую значения разных типов (одно за раз) и метку о текущем типе. В SV завезли даже немного сопоставления с образцом (pattern matching), чтобы с этими тип-суммами удобнее работать. В общем, добавили каплю ФП в море SVшного ООП.

И эта штука - как раз те самые enum в Rust, типа Result<T, E>, Option<T>, которые в общем-то весомую роль во всей ржавой парадигме играют. Те кто поискушенее могут вспомнить Haskell или иной из десятка языков, где подобное есть в наличии.

Использование того же Result<T, E> мне довольно зашло для обработки и распространения ошибок, что в своем очередном пет-проекте на SV я даже начал эмулировать этот тип и сопоставление с образцом через классы. А тут оказывается что оно уже есть из коробки в SV.

И тут самое неприятное - tagged union плохо поддерживается даже big3 симуляторами, не говоря уже про какой-нибудь верилятор. Оно имеет несколько странноватый и многословный синтаксис относительно подобного в других языках. И будто бы совсем не развивалось и не менялось за почти 20 лет развития стандарта. В сумме это даёт то, что в "дикой природе" это практически не встречается, и в среднем если инженер что-то и слышал про такой union, то про pattern matching и его возможности не особо в курсе.

Что касается статьи, то там автор ещё спекулирует по поводу нескольких дополнительных возможных применений в классах, но на мой взгляд именно организация консистентного возврата и распространения ошибки/результата аля Result/Option в Rust была бы наиболее приятным применением. Но увы, видимо не суждено.

P.s. ещё интересный факт, что похоже эта фича корнями уходит в Bluespec, и вообще в первую очередь предлагалась как синтезируемая фича. А текущие синтезаторы в курсе (риторический вопрос)?

P.p.s. возможно я заблуждаюсь, и оно вполне себе юзается у кого-то в проде каждый день, и вообще всем всячески рекомендуется? Я бы послушал про это.

#system_verilog
@positiveslack

Цифровой синтез: RISC-V

Неожиданно затесался в приложение книги "Цифровой синтез: RISC-V".
Штош, теперь, хочешь не хочешь, надо брать. Спасибо Вождю!

P.s. кстати топовые каналы, рекомендую подписаться =)

#book
@postivelsack

Ну и как без иронии
#meme
@positivelsack

А что если scoped enum в SV?

А что если не использовать чистые енумы, а оборачивать енум в класс?

У конструкции enum в SV есть один фатальный недостаток - он не определяет область видимости и варианты перечисления "проваливаются" в родительскую область видимости. Это обычно называется unscoped enum. В итоге, например, все варианты перечислений внутри пакета лежат в самом пакете. Это открывает некоторый простор для конфликтов как внутри, так и с внешними пакетами.

Есть разные подходы к решению такой проблемы: забить, обязать не использовать ::* импорты, обязать использовать суффиксы/префиксы для вариантов перечисления. Из этого самый пуленепробиваемый вариант - использовать имя пакета как префикс в имени енума, и имя енума как префикс каждого варианта в перечислении. Ну типа foo_pkg, а в нём foo_err_e, а в нём FOO_ERR_UNKNOWN, FOO_ERR_NOT_IMPLEMENTED. Очевидно, имена обычно не трехбуквенные, и состоят бывает не из одного слова, поэтому недостатки у такого подхода тоже есть.

Но если создавать понятный скоуп самому через абстактный класс?

virtual class foo_err;
  typedef enum {
    UNKNOWN,
    NOT_IMPLEMENTED
  } enum_t;
endclass

И тогда любые действия с типом енума или его вариантами осуществляются через ::, например, foo_err::UNKNOWN, или foo_err::enum_t var

▫️К перечислениям больше не нужно добавлять никаких перфиксов/суффиксов
▫️Гарантировано не будет никаких конфликтов
▫️Чтобы внести в область видимости енум и его варианты надо лишь импортировать один класс

И на самом деле подобные scoped енумы есть в C++, Python, и т.д., поэтому идея в общем-то банальная. Но на практике не видел чтобы она массово применялась в SV. Ну точнее как, локальные енумы в классах не редкость, а вот умышленная обёртка-класс - не встречал особо.

#system_verilog
@positiveslack

Про сложность SVA

> SV Assertions появляются в стандарте
> Сложно. Люди пишут статьи, делают презентации.
> Всё ещё сложно. Эксперты пишут книги с детальным анализом.
> Слооожнааа. Эксперты пишут статьи, о том как читать их книги.
>>> Вы находитесь здесь <<<
> Что дальше?

Просто тут в линкедине Ben Cohen, автор довольно популярной книги "SystemVerilog Assertions Handbook", выложил pdf с ответом на вопрос как лучше всего читать его книгу чтобы быстрее въехать в SVA. Саму pdf прикладываю в комментах.

#system_verilog #sva
@positiveslack

Waveform Analysis Language

https://wal-lang.org
https://github.com/ics-jku/wal

Неожиданно набрёл на язык для обработки дампов вейвформ.
Насколько понимаю это академичекий проект, который живёт и развивается уже пару лет.

Можно итерироваться по иерархии сигналов, инспектировать их, ходить по временным шагам, сравнивать, смотреть, вычислять и создавать дополнительные сигналы. Т.е. потенциальные применения это дебаг, вычисление статистики, применения дополнительных проверок и поиска в готовых дампах.

Всё это в синтаксисе S-выражений (есть тут лисперы 😏?) через REPL в динамике, либо через запуск скрипта.

#tool
@positiveslack

Command Line Interface Guidelines

https://clig.dev

Шикарный гайд о том как организовывать CLI для своих программ. Начинается с общих рассуждений, и дальше покрывает все основные аспекты с примерами и ссылками на дополнительные ресурсы.

Минутка саморефлексии. Я очень люблю автоматизировать и писать прикладные инструменты/скрипты. Иногда даже больше чем решать непосредственно задачу с помощью этих инструментов.
И 9/10 из таких тулов обладают CLI. И это было непросто узнавать как правильно и удобно его организовывать. Всё методом проб и ошибок, гугления, чтения StackOverflow и подсмотра "как у взрослых сделано". Очень не хватало подобного единого гайда или чеклиста с лучшими практиками. Сейчас, конечно, многое из того что там очевидно, но всё равно находятся интересные места.
Не пожалейте полчаса на прочтение.

#cli #guide
@positiveslack

Рандомизация в Verilator

Тут оказывается у верилятора сподвижки в рандомизации случились.

Если сжать всю историю до нескольких предложений, то

▫️ Первым заходом в рандомизацию было использование API-вызовов библиотеки CRAVE. Решение как оказалось было не совсем подходящим - слишком громоздкий и универсальный инструмент, который сильно усложняет сборку самого верилятора.
▫️Далее пошел заход через SMT-LIB2 - SV констрейны конвертируются в Lisp-подобное описание, которое идёт в рантайме на вход любому (почти) из популярных SMT-решателей, установленных в системе. Далее остается лишь забрать выхлоп и разложить по переменным.

Именно последний подход начали пиарить в недавних статье и докладе про текущие дела верилятора. Хотя PR на Github находился еще в работе, да и судя по комментариям мистер Снайдер похоже не сильно был воодушевлен таким подходом.

Однако, работу довели до мержа в мастер, и теперь по умолчанию верилятор пытается использовать z3, как бэкэнд для рандомизации.

Рандомизация работает, я проверил. Однако надо убедиться что решатель есть в системе, иначе в рантайме будет сюрприз

%Warning: Subprocess command `z3 --in' failed: exit status 127

Но сама рандомизация пока еще довольно слабая - можно глянуть в оригинальном PR, что ограничений пока довольно много.

#verilator
@positiveslack

Кодер/декодер JSON на SV

ШОК!!! Программисты скрывали этот формат от верификаторов годами! Нужен всего лишь...

Короче говоря, я решил что существует недостаточно полноценных JSON кодеров/декодеров на SystemVerilog.

Почему JSON? Потому что он достаточно простой и хорошо формализированный чтобы его несложно было грузить и дампить, поддерживаемый всюду, а также всё ещё человекочитаемый. В общем, идеальный "великий уравнитель" если вдруг мы хотим гонять через IO данные, конфигурации, метрики, трассы, транзакции и прочее между симуляцией и внешним миром.

И вот он github репо. Без UVM, DPI и внешних зависимостей - на чистом SV. Практически полная поддержка спецификации (юникод не стал полноценно поддерживать, уж простите). И даже немного больше - есть некоторые SV-специфичные фичи.

Можно читать json, можно дампить, можно инспектировать, изменять и создавать дерево объектов руками. Можно даже имплементировать специальный интерфейс-класс в своём любом классе, и получить возможность дампа этого класса в json. Есть прозрачный механизм сигнализации об ошибках декодирования. В общем все то, что можно встретить на нормальных языках.

Для тестирования и разработки использовал SVUnit и Verilator. Тесты как свои, так и с использованием внешнего набора JSONTestSuite. Отмечу, что ни на одном коммерческом симуляторе пока не запускал, а с учётом того, что верилятор позволяет некоторые вольности, то высока вероятность что не заработает из коробки.

Документация доступна на сайте.

https://github.com/esynr3z/svjson

#system_verilog #json
@positiveslack