Why do you cry, Willy? [2]

Довольно редкие, но всё же грабли.

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

class test;
   typedef struct {
      int          foo;
      string       bar;
      int unsigned index;
    } item_fail_t;

  task test_fail();
      item_fail_t example_item = '{foo:42, bar:"HELLO!", index:1};
      item_fail_t item_q [$];
      int res_q[$];

      item_q.push_back(example_item);

      res_q = item_q.find_first_index() with (item.index == example_item.index);
      if (res_q.size() == 0) begin // WHYYY
        $error("WTF! res_q.size() has to be 1!");
      end
    endtask : test_fail
endclass

В данном примере некоторые симуляторы выведут указанное сообщение об ошибке. Другие отработают противоположным образом.

В чем проблема?

P.S. Ого как красиво стал код рендерится в постах!

#system_verilog
@positiveslack

Очень локальный мем
#meme
@positiveslack

On SystemVerilog Interface Polymorphism and Extendability

Статья про то, что обычно называется "полиморфные интерфейсы", на примере стандартного APB агента.

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

TL;DR

◽️Интерфейсы нельзя наследовать, поэтому логики в них должно быть минимум, чтобы избегать копипасты. Т.е. когда много логики уезжает из драйвера в интерфейс (BFM), то это сильно бьёт по возможной кастомизации в будущем.

◽️Классический интерфейс и передача ссылки него в класс через virtual interface может мешать кастомизации агента. Например, заменить и/или расширить интерфейс и драйвер.

◽️Альтернатива - использовать Proxy паттерн + Abstract/Concrete class подход, как было описано сначала в этой, а потом в этой статье. Вместо интерфейса в агент приходит прокси объект, через методы которого можно контролировать/мониторить интерфейс.

◽️Удобно получается когда прокси класс даёт API в виде простых геттеров/сеттеров на сигналы и пачку тасок на контроль клока/ресета. Вся остальная логика - в драйвере.

◽️Недостаток подхода лишь в чуть большем количестве кода в краткосроке, взамен получаем большую гибкость в долгосроке.

🏆 В фонд цитат и выражений:

Clipboard-based inheritance at its finest!

#system_verilog #verification #tldr
@positiveslack

Switchboard by ZeroAsic

Интересную тут штуку заопенсорсили на днях.

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

Пока не придумал где лично мне бы пригодилось, но может натолкнет кого-то на идею.

Github

#framework
@positiveslack

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