TGViewer
позитивслэк позитивслэк @positiveslack · 992 subscribers
Post #387 1.07K

Forwarded from Arnold Enginegger

Поделюсь историей успеха на поприще ИИ-ассистированного баг-хантинга в 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 анализа. Она пыталась угадывать задержки и чинить отдельные сигналы вместо моделирования.

В общем, фатальной ошибкой было то, что после локализации бага не был сделан конкретный тест под конкретный кейс, а в вместо этого продолжали гонять огромную симуляцию всей системы. 🙂
GitHub GitHub - kleverhq/wavepeek: 🌊 CLI tool for RTL waveform (VCD/FST/FSDB) inspection 🌊 CLI tool for RTL waveform (VCD/FST/FSDB) inspection - kleverhq/wavepeek
  • 🔥 24
  • 🥱 4
More from @positiveslack
  1. Sep 18, 2026Чет я закопался в этой проблеме. Я что многого прошу? Я даже про единый формат баз данных…
  2. Aug 25, 2026Интеграция проприетарных форматов вейвформ Из предыдущего поста у меня родилось несколько…
  3. Aug 24, 2026wavepeek 3.0 С момента моего доклада прошло некоторое время и случился переход от v0.5.0 к…
  4. Aug 22, 2026Post #388
  5. Jul 17, 2026Проверка верилятора на прочность Всё началось с проверки того, а насколько реально verilat…
  6. Jul 12, 2026Yosys + SV 😎 Кстати SystemVerilog теперь в Yosys 0.67 (релиз пару дней назад): For System…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →