Доверяй, но проверяй: Почему ИИ-тестбенч находит ошибки, но пропускает катастрофы

Введение: Эксперимент, который обнадежил и насторожил

Представьте: вы даете ИИ техническое задание на DMA-контроллер, и через несколько минут он выдает готовый RTL-код, UVM-тестбенч, скорборд, мониторы и пять тестов. Всё компилируется. Все тесты проходят «зеленым». Симуляция – чиста.

Именно это сделал Викаш Кумар, старший архитектор по верификации в Arm. Он скормил системе Claude Code спецификацию на двухканальный AHB-Lite DMA-контроллер – классический «кирпичик» для систем-на-кристалле (SoC) в периферийном ИИ. Результат впечатлял: ИИ выполнил работу, на которую у джуниора ушло бы 2–3 недели.

Но когда Кумар копнул глубже, выяснилось страшное: тестбенч не проверял то, что действительно важно. И это проблема не ИИ, а… спецификации.

Главный парадокс: Аппаратура работает, система мертва

ИИ блестяще справился с созданием аппаратного механизма. Он разложил сигналы по полочкам, настроил каналы, построил UVM-иерархию. Но он не смоделировал протокол взаимодействия с прошивкой.

В чем суть? У дескрипторных устройств есть негласный протокол:

1. Настроить канал.
2. Отправить дескриптор.
3. Аппаратура пересылает данные.
4. Аппаратура пишет статус «Готово».
5. Прошивка должна прочитать статус.
6. Прошивка ОБЯЗАНА сбросить флаг прерывания (IRQ_CLEAR).

Если программист забыл шаг №6, аппаратура отработает идеально, данные придут, скорборд крикнет «PASSED!», но канал DMA намертво заблокируется. Навсегда. Обычный тестбенч этого никогда не заметит, потому что он смотрит на сигналы, а не на логику прошивки.

Метрика №1: PMC (44.1%) – ЧТО именно протестировал ИИ?

Кумар ввел метрику Покрытия модели программирования (PMC, Programming Model Coverage). Это доля поведений устройства, которые ИИ реально протестировал.

Результаты шокируют своей неравномерностью:

• Использование каналов, обработка запросов не по порядку, сценарии ошибок: 100% (ИИ умеет то, для чего его просили).
• Коды статуса завершения: 20% (из 10 возможных кодов ошибок ИИ использовал только 2: «Успех» и «Нет ошибки»).
• Значения полей дескриптора: 34.5%.

Вывод: ИИ гениален в тестировании «позитивных сценариев». Но как только нужно проверить, что случится при редкой ошибке шины или неправильном выравнивании – он пасует. Он не умеет «сомневаться» в железе.

Метрика №2: CVL (Бесконечность) — Как ДОЛГО тестбенч не замечает беды?

Латентность нарушения контракта (CVL) – это время от появления ошибки до ее обнаружения.

• Стандартная ошибка (зависание шины): Без монитора – 1 мс, с монитором — 595 нс. Отлично.
• Фатальный пробел (F3, путь IRQ): Тестбенч ИИ подал сигнал прерывания (IRQ_EN), но так и не подал сигнал сброса (IRQ_CLEAR). Скорборд видел, что данные переданы, и сказал PASS. Аппаратный канал при этом ушел в состояние ST_IRQ (завис навсегда).

CVL в этом случае равна БЕСКОНЕЧНОСТИ. Проблема не в том, что тестбенч медленный. Проблема в том, что в нем нет механизма, который вообще способен увидеть эту проблему. Глобальный таймаут не поможет.

Метрика №3: DFS (52.4%) — Генерация без верификации

Оценка точности дескриптора (DFS) смотрит на три вещи: умеет ли ИИ генерировать поле, умеет ли проверять результат и тестирует ли границы.

Результаты разложили по полочкам:

• Генерация (Стимулы): 100% (ИИ знает, как устроен дескриптор).
• Проверка (Результаты): 43% (ИИ проверяет только то, что ему явно сказали).
• Границы (Краевые случаи): 14% (ИИ не умеет пытать железо экстремальными значениями – ноль байт, максимум длины, невыровненные адреса).

Яркий пример – поле FLAGS: ИИ сгенерировал код, который включает прерывание (IRQ_EN=1), но забыл сгенерировать код, который это прерывание сбрасывает (IRQ_CLEAR). Он создал путь в коде, но не создал проверку для этого пути.

Светлая сторона: 6 реальных ошибок, которые ИИ ВСЁ ЖЕ нашел

Несмотря на провал в покрытии (44%), тестбенч Кумара нашел 6 реальных багов в сгенерированном RTL. Как? За счет наблюдаемости, а не покрытия.

Вот примеры «железных» проблем, которые ИИ выявил:

1. Проблема области видимости: ИИ размазал классы по 15 файлам, забыв про пакет SystemVerilog. Одна вставка import вылечила 27 ошибок компиляции.
2. Гонка конвейера: Из-за неверного тайминга AHB-Lite данные из Канала 1 подмешивались в Канал 0. Классическое состояние гонки.
3. Зависание конвейера: Из-за сдвига фаз адрес/данные контроллер впадал в ступор на 256 тактов.

«Эти ошибки были найдены потому, что скорборд считал завершения, а мониторы непрерывно следили за состоянием конечного автомата (FSM),»

– пишет Кумар. Инфраструктура наблюдаемости ловит баги на первом же прогоне. Покрытие нужно, чтобы ловить остатки потом.

Корень зла: Не ИИ плох, а спецификация бедна

Кумар делает ключевое заявление: PMC в 44% – это провал не нейросети, а инженера, который писал спецификацию.

• Исходный документ гласит: «софт должен очистить прерывание, записав IRQ_CLEAR».
• ИИ прочитал это как: «регистр существует». А не как: «создай тест, который запишет в этот регистр, проверь сброс флага и убедись, что канал вернулся в IDLE».

Автор предлагает структурную схему:
Вместо этого писать жесткие требования:

text

irq_contract:
trigger: transfer_complete AND irq_en=1
response_required: irq_clear_write
violation_class: firmware_contract

С такой схемой ИИ уже сможет вывести нужный монитор и проверки.

Что делать инженерам? 4 жестких совета

1. Для оценщиков инструментов: Не смотрите на общий DFS. Спрашивайте три подоценки: Generate (100%?) vs Check (43%?) vs Boundary (14%?).
2. Для верификаторов: Считайте CVL по каждому классу ошибок. CVL = ∞ означает, что у вас нет детектора для целого класса проблем.
3. Для авторов спецификаций: Кодируйте контракты прошивки и граничные значения в виде структурированных схем, а не текста.
4. Для строителей тестбенчей: Сначала стройте инфраструктуру наблюдаемости (UID-трекеры, мониторы состояний), а потом пишите тесты. Наблюдаемость ловит баги мгновенно.

Заключение: Холодный душ для энтузиастов ИИ

На сегодняшний день LLM (вроде Claude Code) – это фантастический джуниор-кодер, который работает в 100 раз быстрее человека. Он напишет связный UVM и находит реальные RTL-баги.

Но он не верификатор. Он не понимает намерений. Он не знает, что такое «очистить прерывание» с точки зрения тестирования.

«Разрыв конкретен. А значит, его можно исправить. Лучшими спецификациями и метриками, которые отличают генерацию от верификации», — резюмирует Кумар.

Экспериментальные данные, RTL и тестбенч автора выложены на GitHub: https://github.com/vksabnima/dma_ai_verification_metrics

Ссылка на первоисточник: https://www.embedded.com/hardware-verification-what-ai-gets-right-when-it-generates-your-testbench-and-what-it-misses

Вас также могут заинтересовать: