позитивслэк

Проверка верилятора на прочность

Всё началось с проверки того, а насколько реально verilator поддерживает конструкции функционального покрытия. Спойлер, хоть есть существенные ограничения, но уже довольно неплохо, кажется для cocotb уже можно отказаться от pyvsc в пользу нативных кавергруп в интерфейсе. Но любопытно больше то, что железный ещё мне и багов пачку еще принес, которые нашел в процессе.

Стало интересно, а что если поженить "публичную поверхность" верилятора (issue, pr, доки, зеленые клетки sv-tests) прямо с главами стадарта и проверить на прочность а насколько хорошо действительно поддержано заявленное.

Включил /goal в кодексе и sol-xhigh погнал. В итоге вся работа (в несколько этапов) заняла 42 часа машинного времени и довольно прилично токенов (38.9M used, 1.38B in, 5.27M out). Все главы (3-41) были проработаны одна за другой и получилась примерно такая воронка:

🔻~3.5к сниппетов кода
🔻~1.5к из них диагностировали проблемы
🔻~630 кандидатов багов, проверенных против публичной инфы, икаруса и vcs
🔻~500 багов, без известных issue/pr.

И конечно же, больше всего дефектов в sva, coverage, randomization и configurations (кто-то вообще в реальности применяет config ... endconfig конструкции?), как самых молодых областях поддержки. Тут конечно возникает вопрос об отделении "фича пока не сделана" и "фича сделана с багом", но там есть варианты буквально всех сортов:

- легальная конструкция не принимается
- нелегальная конструкция принимается
- принимается, но игнориуется
- реализовано, но работает неправильно
- краши, внутренние ошибки на компиляции
- ошибки в рантайме

Особенно опасненькими выглядят баги из 7 главы про массивы - там есть и классические off-by-1 ошибки с потерей данных, и неожиданная аллокация данных, и порча данных.

Многие знания - многие скорби💧 Что делать теперь с этим богатством? Можно конечно форкнуть верилятор и сделать slopelator через "fix all bugs, make no mistakes", но думаю нужно идти максимально скучным способом. Руками валидировать наиболее критичные проблемы, репортить и предлагать помощь по фиксу.

Да, многие критикуют вайбкоженные симуляторы (1, 2), мол, ерундой занимаются, лучше бы верилятор сделали лучше. Но проблема в том, что это кратно менее веселая исследовательская задача и уже сильно больше похожая на работу🤡 Ведь просто одним промптом зарепортить 500 багов и предложить PR тоже не выйдет - вызовут санитаров и уедешь в дурку бан навсегда.

P.S. Красивая нейропдфка с визуализацией результатов в коментах.

P.P.S. Интересная сторонняя находка в том, что оказывается sv-tests довольно слабый и поверхностный, и на самом деле слабо отражает реальную степень поддержки стандарта. Поэтому кажется логичным текущие наработки дополнить и перевести в полноценный публичный torture-suite для EDA тулов против стандарта. Но это уже в другой серии...

P.P.P.S. Еще очень раздражало что у openai постоянно тригерились cybersecurity checks в районе проверок глав 30+, и тормозили выполнение /goal (пауза, пока не прожимешь enter руками). Видно VPI/DPI это очень подозрительно и нормальные люди таким не должны заниматься🙂

#verilator #llm
@postiveslack

Какой?

#meme
@positiveslack

VeriPilot: An LLM-Powered Verilog Debugging Framework

Давненько не было рубрики tl;dr. Попалась на глаза свежая (22 июня) статья по построеннию системы структурного дебагинга верилога поверх LLM агентов (да, каждый первый-второй пост будет про иишки, времена такие, сами понимаете).

В статье довольно симпатичные картинки и уже ради них стоит полистать. Прикрепленная - это весь флоу системы наглядно.

Тезис у авторов простой - все исследователи бросают агентов в end-to-end циклы дебага и починки RTL (итерируемся по ошибкам симулятора или тестбенча), а вот мы считаем, что процесс нахождения бага и починки нужно изолировать друг от друга, и более того сам дебагинг нужно сделать более структурированным и в некотором роде приближенным к человеческому. Идея такая:

▫️у нас есть потактовая исполняемая реф-модель с внутренними состояниями, которые можно хоть как-то сопоставить с DUT (довольно релистично, ага 🤡)
▫️мы собираем трассы с dut и модели на одних и тех же входных стимулах
▫️мы находим в каком месте разъезжается dut и модель по выходу
▫️преобразуем и dut и модель в Control-Data-Flow Graphs (CDFG)
▫️начинаем детерминировано трассировать их в обратном направлении, семантически следуя по примерно одинаковым местам в обоих "мирах" (за семантическую оценку отвечает отдельный агент)
▫️находим подозрительное место, где dut и модель разъезжаются
▫️составляем детальный структурированный промпт для агента-чинителя со всеми деталями по подозрительному региону, трассе, информации CDFG и т.д.
▫️агент-чинитель должен починить RTL сильно успешнее, чем наивный цикл просмотра ошибок компилятора и тестбенча

В результате получаем некоторый фреймворк, в котором есть и вполне себе императивные рельсы и преобразования и перемежение агентами, там где появляется нечеткость и семантика. Ну и выбиваем 91% (+17% против простой LLM) на CVDP-cid16 (относительно маленьких класс задач по дебагингу RTL из CVDP бенча).

Первая ложка дегтя здесь это то, что обязательно нужна модель с достаточно полезной внутренней наблюдаемостью. Для CVDP авторам фактически пришлось расширять каждый тест в бенчмарке своими моделями на питоне и трассами внутренних переменных.

И из этого получается вторая ложка дегтя. Судя по всему, golden_model.py файлы они клали в окружение только для VeriPilot прогонов, но не для "наивных" прогонов с LLM. Что нечестно, т.е. сложно становится отделить это их фреймворк дал буст или просто само наличие голден модели бустит и все остальные усложнения не нужны.

В целом, подход интересный, и игры с семанитическим матчингом, CDFG, AST у верилога+питона, и извлечением дополнительного слоя информации довольно занятны, но не стоит забывать про "горький урок" и что все эти усложнения и фреймворк-построения скорее вссего будут не нужны (может уже не нужны), т.к. агент их сам будет делать под капотом так или иначе. Тем более что в исследовании принимали участие лишь GPT-5 (2025), GPT-4o (2024) и GPT-3.5-Turbo (2023). Последняя это вообще что-то древнее из времен триллобитов и аммонитов.

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

#tldr #llm

@positiveslack

AXI Rev L (2025)

#meme

@positiveslack

AXI Rev L (2025)

Давеча имел неосторожность заглянуть в последнюю AXI спеку и немало удивился 😲

Если ваше представление об AXI - ну там пяток параллельных каналов, с valid-ready хэндшейками и пятком сигналов c метаинфой рядом, то увы.
"Посмотрите, что они сделали с моим мальчиком" (c)

Выше на скринах полторы страницы сигналов и только для AR канала. И да, AXI теперь опционально может быть кредитным. Причем там такая увесистая кредитная система с виртуальными каналами (resource planes), обычными и шареными кредитами - оно даже в CHI проще кажется.

Они еще попытались навести порядок в номенклатуре AXI + ACE. У нас были AXI4, AXI4-Lite, ACE, ACE-Lite, ACE5, ACE5-Lite, ACE5-LiteDVM, ACE5-LiteACP, то теперь всё проще - это всё AXI5 и все ACE5-* комбинации теперь подмножество просто. Да, т.е. старого ACE нету, Lite фичи ACE теперь прямо в AXI5, а полный когерентный фарш уже в CHI. Всё просто и понятно 😬

А теперь имаджинируйте лицо стажера, в которого кинули последней AXI спекой, сказав "ну разберись, там AXI, valid-ready, пяток каналов, чего непонятного".

Нет, ну в принципе AXI всё тот же AXI, и в базе нужно совсем немного чтобы он заработал, но теперь попробуй это извлечь из текущей спеки и комбинаций из 4 страниц с таблицами properties (матрица всех фич). Ну хотя да, чего это я, гпт разберется😎

#axi

@positiveslack

Превосходство FST

Как же он хорош, как мощны его лапищи😎

На картинке один и тот же верилог тест, где полностью вся иерархия рекурсивно задамплена в разных форматах. Ну и по этим дампам я ходил с wavepeek.

FST так спроектирован, что у него практически нулевая цена холодного старта, что ты с порога можешь начинать рандомно шариться по иерархии или значениям сигналов, в отличие от его собратьев. У FSDB 3-5 секунд стабильно уходят чтобы раскочегарить бэкэнд FsdbReader библиотеки, но справедливости ради, дальше с ним тоже быстро можно работать. Ну а VCD, это просто VCD - пока не прочитаешь целиком, ничего особо не сделаешь.

Да, этот пост - байт на то, чтобы рассказать в комментах почему FST в чем-то вдруг плохо работает🧃

#waveform
@positiveslack

Verilator + coverage 🥰

К более интересным новостям. Ну вы видели, да?

#verilator
@positiveslack

No offence, guys

#meme
@positiveslack

Building an Open-Source Verilog Simulator with AI: 580K Lines in 43 Days

Тут интересный инцидент пропустил. Затравка в статье из шапки. После её прочтения единственный вопрос это "WTF сейчас происходит?"🏥 И дальше интереснее будет.

Если идти по порядку, то в начале марта некто Thomas Dybdahl Ahle заявил в посте что обнимку с ClaudeCode и Codex он (его команда?) за 43 дня написал около 580к строк кода, в которых:

▫️circt-sim - симулятор SystemVerilog/UVM поверх CIRCT, выбивает 73% на тестсьюте sv-test (Verilator 94%, Icarus 80%) и способен симулировать UVM окружения
▫️circt-bmc/circt-lec - инструменты для формальных доказательств
▫️circt-mut - инструменты для мутационного тестирования

Проходят тесты, всё красиво, но главным минусом нового симулятора конечно же была производительность. Сим заявляется как что-то на 3-4 порядка более медленное чем competitor (предположительно xcelium).

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

Мейнтейнерам это не понравилось, и они буквально за считанные дни приходят к решению, что автора нужно забанить и никакие PR и вклады от него не принимать, т.к. он жестко нарушает всё на свете. И лицензии (усмотрен реверс инженеринг Xcelium и бенчмаркинг против него), и правила разработки с ИИ, принятые в LLVM, в которых прямо говорится что весь код должен быть поревьювен и осмыслен человеками, и вообще за него надо нести ответсвенность (как и за своих агентов).

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

#llm #circt
@positiveslack