SystemVerilog Interface Classes – More Useful Than You Thought

Снова воскресная рубрика tl;dr. Теперь статья про interface class.

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

Ребята из ARM как-то прокачали свое окружение для очередного Cortex-A с помощью интерфейсов и рассказали о профитах в статье.

TL;DR

◽️ interface class (далее "интерфейс") появился в SV-2012, но все основные библиотеки были написаны ранее (типа UVM), поэтому юзались макросы и иные обходы вместо них (а как бы приятны могли бы быть TLM порты)
◽️ Позволяют гибко реализовать паттерн наблюдателя (Observer/Listener) - можно динамически "подключаться", любой класс (вне зависимости от иерархии наследования) может слушать, информация не ограничена одним объектом.
▫️ Например, можно давать возможность сиквенсам слушать мониторы без костылей в виде TLM портов в сиквенсор
◽️ Позволяют эмулировать ещё одну фичу взрослых языков - "множественное наследование". Например, есть транзакция барьера DMB, есть транзакция LD, и можно элегантно сделать их гибрид LDAR, не засоряя базовый класс.
◽️ Позволяют легко генерализировать классы по какой-либо функциональности вне зависимости от дерева наследования (в статье это прикручивание фичи дампа в SQL и получения тика клока).
◽️Можно имплементировать множество интерфейсов, и имплементирован ли конкретный у объекта можно узнать через $cast этого объекта к интерфейсу

Небольшой сторонний пример.

interface class Verificator;
  pure virtual function report verify_rtl(rtl code);
endclass

class Person implements Verificator;
  virtual function report verify_rtl(rtl code);
    // implementation here
  endfunction
endclass

class Cat extends Animal implements Verificator;
  virtual function report verify_rtl(rtl code);
    // implementation here
  endfunction
endclass

...
Verificator verif = get_free_verificator(); // Person, Cat or any
report = verif.verify_rtl(code);
...

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

Ещё информация про интерфейсы: Verification Gentelman, DVTalk

#system_verilog #verification #tldr
@positiveslack

Ну и обратная сторона для баланса.

#meme
@positiveslack

Cohesion and Coupling: the difference

Просто понравились картинки из статьи про сцеплённость (cohesion) и связность (coupling). Помним, что наиболее профитно формировать логический объект (класс, модуль, пакет, whatever) из хорошо сцеплённых кусочков, а связей с соседними объектами делать по-минимуму. В общем-то универсальная база, но следовать порой тяжело, однако.

P.S. Кстати, эта статья одна из серии коротких статей про наиболее ценные концепции программирования (и не только): YAGNI, KISS, Encapsulation, DRY, Fail Fast, Explicit Assumptions.

#programming
@positiveslack

Буквально я после некоторого количества экспериментов

#meme
@positiveslack

Verilator и UVM [6]

Думал сейчас быстро возьму этот первый UVM тестбенч, запущу побольше транзакций и сравню производительность с проприетарными симами. Приключение на 20 минут, ага.

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

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

Подозреваю что я как-то криво это всё приготовил, но не вижу явного косяка.

Ну и результаты пока такие себе:
- проприетарные симы: ~15сек компиляция (1 поток), ~30сек симуляция 1М транзакций
- verilator: ~10мин (6 потоков) компиляция, ~30сек симуляция 1М транзакций (бесполезных)

Скрипты и исходники закинул в репо. Ах да, версия верилятора 5.018.

#uvm #verilator
@positiveslack

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