Forward 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. Вот его вывод:
В общем, фатальной ошибкой было то, что после локализации бага не был сделан конкретный тест под конкретный кейс, а в вместо этого продолжали гонять огромную симуляцию всей системы. 🙂
Суть такова. Есть проект 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 анализа. Она пыталась угадывать задержки и чинить отдельные сигналы вместо моделирования.
В общем, фатальной ошибкой было то, что после локализации бага не был сделан конкретный тест под конкретный кейс, а в вместо этого продолжали гонять огромную симуляцию всей системы. 🙂