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