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

Кодер/декодер JSON на SV [1]

Ну и чтобы два раза не вставать, немного об инфраструктуре этого проекта.

По поводу симуляции и тестирования. Работать с верилятором не то чтобы просто - часто вместо дебага своей логики ты дебажишь верилятор. В итоге, в вериляторе было заведено дюжина багов (большинство пофикшено), и даже починена его совместимость с SVUnit, как я писал выше. В итоге, почти пятая часть ченджлога для 5.024 зарепорчена мной. "It ain't much, but it's honest work".
В любом случае, вдумайтесь - верилятор уже сносно работает с довольно абстрактным ООП кодом!

По поводу документации. Я очень люблю asciidoc, и с самого начала искал способы как бы поднять github pages на нём. Благо нашёлся проект Antora, причём похоже единственный в своём роде. Все остальные генераторы сайтов и документации, либо не поддерживают asciidoc, либо поддерживают через дополнительные плагины и телодвижения. Правда стандартный UI Antora имеет некоторые недостатки (например, нет подсветки SV в документации), но всё поправимо.

По поводу линтов и форматирования. Самое слабое место, т.к. ничего почти не настроено. Основной план - использовать максимально строгую компиляцию разных симуляторов как линты. Дополнительно можно попробовать что-то из отдельных линтеров прикрутить. Всё собирался в который раз попробывать форматтер Verible. Но раньше он всё время крашился на нетривиальном ООП коде.

По поводу автоматизации. Всё описанное выше положено на "бумагу" в виде Github Actions и просто делает "вжух" по новым PR и пушам в мастер. Да кстати, там кроме верилятора я поднял и модельсим (версия от альтеры) - это единственный коммерческий симулятор, который можно скачать по прямой ссылке и запускать без отдельной лицензии.

В итоге, надо еще немного дожать, и будет по инфраструктуре почти то, что доступно в больших ЯП из коробки и никаких трудностей не вызывает.

Ну и да, как бы то ни было, положительный сайд-эффект в виде ставших чуть лучше опенсорсных тулов уже оправдывает всю затею на 100%.

https://github.com/esynr3z/svjson

#system_verilog #json
@positiveslack

Писать VIPы весело

"А давайте напишем универсальный VIP, который будет работать во всех основных симуляторах"

◽️Делаем красивые и подробные сообщения. Что напечатает код?

initial begin
    $display({"Hello", "from %s!"}, "testbench");
end

Правильно:
- одна половина симуляторов: Hello from testbench!
- другая: Hello from %s!testbench

◽️Пытаемся писать lint-free код.
Используешь $sampled в сообщении SVA - плохо, не используешь - тоже. Да что тебе надо то? Пример для VCS здесь.

◽️Хм? Сколько раз будет напечатано сообщение?

int unsigned num = '1;
repeat (num) begin
    $display("Hello!");
end

В Xcelium например ни одного, т.к. num скастуется внутри к int и получится отрицательное число для которого repeat не положены. И это будет отличаться от брата VCS, где честно будет напечатно всё.

И это только мелочи из недавнего. Есть примеры? Накидывайте.

#verification #vip #eda
@positiveslack

Next Level Testbenches: Design Patterns in SystemVerilog and UVM
By Mark Glasser

Тут недавно новая книга вышла, о которой мне лента линкедина любезно рассказала раз десять кряду.

Выглядит довольно интересно. Тема паттернов/шаблонов проектирования в SV ООП в интернетах представлена слабо, но является важной на мой взгляд. Т.к. верификация - это по сути написание программ, пускай и специфичных, а поэтому верификатор - программист, которому неплохо было бы знать и классические типовые подходы решения типовых проблем.

Я даже начал собирать информацию по теме, и писать некоторое количество заметок, в надежде сделать лонгриды, но теперь как будто уже не надо, т.к. там информации уже в разы больше.

Попадёт ли эта книга в must-read список верификатора? Кто знает. Осталось лишь дождаться пока приедет. Пока можно лишь изучить примеры из книги, лежащие на гитхабе
https://github.com/mxg/topaz

#system_verilog #book
@positiveslack