позитивслэк

Поделюсь историей успеха на поприще ИИ-ассистированного баг-хантинга в RTL. А точнее, прорекламирую замечательную прогу для работы с дампами вейформ от нашего товарища positiveslack. Прога сделана специально для ИИ-агентов, чтобы им было удобно (и дёшево) анализировать дампы. Суть такова. Есть проект SoC на базе софтпроца с разнообразной периферией. Есть тестбенч, где два таких SoC работают навстречу через PCIe. И есть проблема - на каком-то этапе процессор вываливается в trap. Симуляция медленная, дамп большой, ковыряться в нём крайне неприятно - нужно держать в голове большой контекст из проводов и кода. Решил попробовать отдать это всё ИИ и попросить сделать хорошо, предварительно установив программу Wavepeek и скилл из её комплекта. Первым пошёл локальный Qwen3.6-27b. 16 вызовов wavepeek, 300к/100к токенов входа/выхода, и вывод: переполнение стека. Переполнения, конечно же, никакого не было (с). По его рекомендации был увеличен объём памяти данных и перезапущена симуляция, результат которой ожидаемо оказался тем же самым, о чём было сообщено агенту. Следующей был выдвинута теория о том, что компилятор неправильно оптимизировал хвостовой вызов, из-за чего процессор переходил не в то место. Это предположение было сразу отвергнуто как очевидно некорректное. Это было видно и по ассемблерному коду. Вторым заходом был запущен GLM-5.2 через облачную Ollama. На вход ему был подан тот же простой промпт, плюс отчёт с предыдущей попытки, чтобы модель не пошла по заведомо ложному пути. Всего 7 вызовов wavepeek и 76к выходных токенов и баг был найден: неправильная работа контроллера памяти с шиной AHB при определённых условиях. Поиск и исправление заняли минут 15. Для чистоты эксперимента третий подход с снаряду снова сделал Qwen. На этот раз он получил такие же вводные, что и GLM - промпт и свой предыдущий отчёт. Удивительно, но через 4 вызова wavepeek он тоже нашел ошибку. Точнее, локализовал место, где она возникает. Причины бага он так и не смог найти. Сначала я подумал, что дело в недостаточном знании шины AHB. Но после подсовывания ему спецификации, дело не сильно сдвинулось - два часа и три перезапуска агента не дали результата, баг так и не был исправлен. Почему-то Qwen не очень хорошо ориентируется в третьем измерении RTL - latency. Итог таков. ИИ может сильно помочь в поиске багов в RTL. Wavepeek сильно помог с парсингом вейвформ - он это делает быстро и понятно для модели. Топовая локальная модель пока не очень хороша в RTL (но я работаю над этим). PS: Дал лог работы Qwen на анализ GPT-5.6-Sol. Вот его вывод: Модель обладала достаточной информацией, но ей не хватило дисциплины синхронного cycle-by-cycle анализа. Она пыталась угадывать задержки и чинить отдельные сигналы вместо моделирования. В общем, фатальной ошибкой было то, что после локализации бага не был сделан конкретный тест под конкретный кейс, а в вместо этого продолжали гонять огромную симуляцию всей системы. 🙂

Проверка верилятора на прочность Всё началось с проверки того, а насколько реально 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

Yosys + SV 😎 Кстати SystemVerilog теперь в Yosys 0.67 (релиз пару дней назад): For SystemVerilog support now using sv-elab, built on top of slang library. Ну точнее как, нативный read_verilog -sv там уже и так какое-то время, но добавился read_slang из плагина yosys-slang. Последний как раз в этом релизе переименовали в sv-elab и сделали частью мейнлайна йосиса. По тому насколько хороша поддержка SV - сам slang способен разобрать весь язык, но sv-elab может синтезировать только некоторое подмножество (довольно широкое). Кстати про этот плагин и в целом про проблемы того как определить что есть "синтезируемое подмножество" было у @m_kudinov в докладе. Рекомендую глянуть, если пропустили: https://youtu.be/42HmSG2MyKw #yosys @positiveslack

Какой? #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

В 29 выпуске «Битовых масок» к Алине Галичиной и Антону Афанасьеву присоединился Богдан Колбов — ведущий инженер по модульной верификации YADRO, специалист с широким опытом на разных инженерных позициях в индустрии. Начав разговор с верификации кеша в многоядерных системах, собеседники перешли к сложностям для верификаторов в разных компаниях. Вспомнили о воспроизводимости багов и других рабочих проблемах, балансе энтерпрайза и open source в индустрии. Оценили успехи AI в RTL-разработке, а также обсудили его сбалансированное использование в личных проектах. Среди более узких тем подкаста: в чем основная головная боль при построении чекеров кеша, чем false sharing отличается от true sharing в верификации, почему в верификации сложно разделить само тестирование и его автоматизацию, как верификаторы в крупных компаниях оказываются «меж трех огней», в чем заключается «проклятие воспроизводимости», чего не хватает современным инструментам верификации и ее автоматизации, уступают ли open source инструменты верификации проприетарным, какие проблемы создают «закрытые клубы» в индустрии ПО для аппаратной разработки. Полезные ссылки: open source инструмент Corsair для построения карт регистров, позитивслэк — канал Богдана об аппаратной разработке с уклоном в верификацию. Смотреть или слушать RUTUBE VK YOUTUBE Истовый Инженер Слушать в Я.Музыка

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

Xe-Xe EDA Ah shit, here we go again😁 Я нашел ещё один симулятор SV2017: https://github.com/aionhw/xezim Как он работает против sv-tests неизвестно, но simulator.rs на 32к строк и свой фронтенд sv (SV->AST) внушают. Решил проверить что он действительно работает - простые helloworld и тестбенч с axi ram (с доделками) действительно бегают. Тестбенчи типа scr1 и simbench компилируются, но валятся в рантайме (дальше было лень разбираться). Но на самом деле я нашел сначала xevdb - это штука, которая в некотором роде включает в себя wavepeek и другие запланированные мной тулы подобного рода. Базовая идея такая: а давайте все артефакты симуляции, компиляции и исходники запихаем в одну бд, и дадим к ней cli. Ну типа и по вейвам ходить, и по иерархии, и драйверы определять, и иксы трассировать, и по cобытиям uvm лога шариться, и еще как то сразу в ИИ встраивать. Но там как-то всё несколько сумбурно и куча фич навалено в свалку, есть сомнения насчёт протестированности и производительности. Но это в принципе норма сейчас для вайбкод проектов😎 Я тоже глобально решаю аналогичную задачу и wavepeek первый кирпичик в тулчейне. Но в моем unix-way представлении это должно решаться отдельными сфокусированными инструментами с совместимыми форматами и интероперабельностью, а не god-cli с бд всех артефактов под капотом. Но кто знает, возможно я сам потом к супераппу скачусь☕️ P.S. а вообще забавно как поднялся уровень пет-проектов, так что люди теперь вполне себе симуляторы игрушечные делают, а не просто n+1 фреймворк по автоматизации. Дождемся вайбкод синтезаторов и бэкэнд тулов? @positiveslack

Превосходство FST Как же он хорош, как мощны его лапищи😎 На картинке один и тот же верилог тест, где полностью вся иерархия рекурсивно задамплена в разных форматах. Ну и по этим дампам я ходил с wavepeek. FST так спроектирован, что у него практически нулевая цена холодного старта, что ты с порога можешь начинать рандомно шариться по иерархии или значениям сигналов, в отличие от его собратьев. У FSDB 3-5 секунд стабильно уходят чтобы раскочегарить бэкэнд FsdbReader библиотеки, но справедливости ради, дальше с ним тоже быстро можно работать. Ну а VCD, это просто VCD - пока не прочитаешь целиком, ничего особо не сделаешь. Да, этот пост - байт на то, чтобы рассказать в комментах почему FST в чем-то вдруг плохо работает🧃 #waveform @positiveslack

Verilator + coverage 🥰 К более интересным новостям. Ну вы видели, да? #verilator @positiveslack

AMIQ License Key Generation Привлек внимание пост от Тома. Если заголовок привлек вас тоже, то возможно разочарую - речь не про AMIQ как вендора EDA софта, а про реверс инжиниринг одноименного старого генератора сигналов. Ну что в общем-то тоже интересно. По пути там забавное. Пасхалки в коде, типа имени джуна, который увековечил себя😎 И даже ответил на письмо Тома, о том что пасхалка нашлась. Удивились бы вы, если бы вам кто-то написал по поводу кода, что вы создали 30 лет назад? И ещё из забавного был деактивированный мастер-ключ, подозрительно похожий на телефон штаб-квартиры Rohde & Schwarz в Мюнхене. Ну и да, какой пост нынче без ллм. Интересно что Тому помогал codex. А ведь эти облачные модели довольно сильно капризные в этом плане и легко уходят в отказ. В отличие от каких-нибудь abliterated моделей от huihui (да, думаю так и читается), у которых моральный компас хирургически удален. Но видимо правильные заклинания и дозированный контекст делают своё дело. Ну и да, похоже в реверсе тоже все эксперты рано или поздно вымрут, т.к. ллм делает это бодрее и быстрее, с чем и поздравляю🥳 But after trying the LLM approach a few months later, I don’t think that matters anymore: any protection scheme that doesn’t use some kind of secure boot and advanced authentication algorithms is now fundamentally broken and literally anyone can break them. All you need is the executable, an LLM, and a single prompt. @positiveslack

Мысли по кодингу с агентами Тут репо перешагнуло порог в 70к строк (код+тесты+бенчи+скрипты+доки) и надо чего-то думать что с ростом энтропии делать. Садишься делать ревизию (тщательнее чем обычно), и видишь какие-то скрипты, какие-то дикие if-else защитные навороты, которые пытаются учесть всё на свете вплоть до тепловой смерти вселенной. Иногда там где нужны были "пару батареек" агент вкорячил работающую АЭС, просто потому что ну на всякий случай, смотри как всё абстрактно, защищено и стабильно работает. И кажется тупо сказать keep it simple stupid не хватает, нужен процесс, который либо мог бы делать аналогичное ревью и резать левые нагромождения, или что-то такое. Пока конечно всё упирается в меня, мою насмотренность и возможность сказать "нам это нахер не нужно здесь", но чет это плохо масштабируется, и зависит от моего ресурса и фокуса на ревью💧 А агентные ревью хоть и ловят реальные проблемы, но иногда раздувают из мухи слона, и в целом особо этому накоплению техдолга не препятствуют. Начинаешь детальнее разбираться, и оп, оказывается вот эти файлы можно удалить, вот эти 500 строк схлопнуть в 20 и так далее. И всё потому, что там где я опустил детали, или не промптил явно, оно само выбрало "дефолтные решения", а они видимо в среднем тяготеют к оверинжинирингу и over-defense-programming, которые являются обычными штуками в энтерпрайзных копролитах, живущих десятилетия (главный обучающий материал для иишки). Но с другой стороны оно ведь работает, и может это и норм. И оно даже способно код поддерживать и впиливать новые фичи. Тут правда интересно где будет тот предел, когда энтропия разрастется настолько, что всё начнет рассыпаться🤡 Можно еще конечно просто начать вычитывать весь код, заставлять делать супер мелкие PR и в целом замедлить весь процесс кодинга до того уровня, в котором можно одному мясному мешку с нехваткой времени и фокуса всё переваривать. Но не, чет бред какой-то😷 #llm @positiveslack

No offence, guys #meme @positiveslack

Там антропики как раз сегодня новую модель релизнули видимо под это 🍿 У меня один вопрос у посту выше - а что гугл групс ещё существуют?

Я сегодня решил начать монетизировать свою критику ИИ и предложил спор на $1000 энтузиасту программы Claude. Энтузиаст запостил в одной из моих групп (295 членов) ссылку на свой сгенеренную Claude репозиторий, утверждая что Claude сгенерил для него ускоритель симуляции верилога, который работает в 1000 раз быстрее чем верилятор, с помощью расбрасывания вычислений на массив RISC-V ядер, синтезированных на Xilinx FPGA. Я предложил ему запустить на этой слоистой конструкции простой тест, которые исполняется в банальном икарусе за 4 минуты на старом Dell и за 2 минуты на новом Маке. Если то что родил клауд сможет выполнить этот тест на его плате за менее чем 10 секунд, и не будет никакой фигни (скажем оно не будет просто печатать правдоподобный ожидаемый результат), и это произойдет до Дня Независимости 4 июля 2026 года, то я плачу ему тысячу долларов. А если нет - то он мне. Как вы думаете - товарищ примет спор? Это инженер-американец с 40-летним опытом, который работал над симуляцией аналоговой версии верилога еще в 1990-х. UPD: Спор был принят. Можете наблюдать за спором в реальном времени: https://groups.google.com/g/meetsv

Мечтают ли ИИ-агенты об анализе вейвформ? Мероприятие прошло. Было очень круто 🎧 Спасибо всем кто пришел, и с кем удалось пообщаться! Если вдруг упустили, то я рассказывал про CLI инструмент для анализа и работы с вейвформами, написанный специально для "рук" LLM-агентов. https://github.com/kleverhq/wavepeek Слайды в первом коменте к посту, ну а выступление есть на YouTube Жажду получить любую обратную связь, особенно отзывы по использованию в реальных задачах. Любая движуха приветствуется, кроме нейрослоп-PR конечно 😎 #llm #tools @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