Итог (начало в предыдущем посте):

По скорости написания кода ИИ хорош, но чтобы получить хороший (или даже рабочий) код, нужно очень подробное задание. Настолько подробное, что это может быть 80% работы. В качестве задания может быть обычное ТЗ, спецификация или тесты. Или всё вместе и с планом работы. Но и с этим ИИ может сильно помочь - составление планов и написание спецификаций у него получается очень хорошо.

По эффективности очевидно ИИ мне проиграл. Достаточно простой модуль был протестирован функционально и формально, но одна ошибка обнаружена не была. Я нашел её за пол часа - за это время были написаны базовые проверки. При этом, в коде формальных тестов от ИИ я увидел пару интересных приёмов, которые раньше нигде не встречал. Взял на заметку, польза от эксперимента таки есть 🤔.

Вывод таков. ИИ хорош, местами прям пугающе хорош. Результат его работы выглядит супер правдоподобно, и даже с доказательствами, но на деле за этим может скрываться откровенный булшит. Распознать это бывает непросто, особенно учитывая какое-то априорное доверие к компьютеру. Мы ведь привыкли, что компьютер детерминирован, и всегда на 2+2 отвечает 4. А тут, оказывается, он может ответить 5, да ещё и красноречиво это доказать.

Ещё сильнее доверие подкрепляет его умение жонглировать терминами. Иногда кажется, что по ту сторону экрана такой любящий дядя Гуру, терпеливо объясняющий очевидные вещи и готовый за тебя сделать всю работу (картинка в первом посте про это). Просто давит интеллектом.

И хотя это всего лишь очень искусный имитатор правдоподобности, у него иногда (а последнее время часто) действительно получается правда. И это страшно.

От теории к практике: готов проверить свои силы в проектировании систем на кристалле?

В этом году проходит пятый юбилейный сезон Соревнований по проектированию систем на кристалле от YADRO и МИЭТ.

Для студентов технических направлений – это возможность попробовать свои силы в проектировании и верификации СнК, а также поработать над задачами, максимально приближенными к реальной инженерной практике.

Ты можешь выбрать одно из направлений:
⏺ UVM-верификация
⏺ Системная верификация СнК
⏺ RTL-проектирование
⏺ Топологическое проектирование
⏺ DFT

📍 24–26 апреля, МИЭТ. Для иногородних студентов будет организован бесплатный проезд до Москвы и проживание на время проведения соревнования!

Подавай заявку, если ты хочешь проверить свои знания в деле. Регистрация открыта до 18 марта — подробности по ссылке.

Если хочешь узнать больше подробностей и получить ответы на вопросы от команды организаторов в прямом эфире – регистрируйся на вебинар на сайте и подключайся к трансляции 5 марта в 17:00.

Обсуждали тут в чатике возможность автоматического перевода очередной книжки Денииса Тейлора из серии "Вселенная Боба" с помощью ИИ. Попробовали на предыдущих сериях - получается вполне неплохо, особенно если немного постараться с подготовкой контекста - стиль сохраняется, имена и специфичные термины тоже. В общем, тема рабочая.

А тут ещё новость про деда, который продаёт на Амазоне нейрокнижки.

В общем, стало интересно, осилит ли ИИ написание небольшого фантастического рассказа с нуля. Причём, ИИ, который живёт у меня в сарае - локальный Qwen3.6-27B.

Поскольку я ленив, то не стал изобретать сложный промпт, а просто попросил его придумать несколько тем для рассказа про "будущее, космос и роботов". Из предложенных вариантов выбрал более-менее пригодный, и сказал "работай".

Первая итерация получилась так себе, по этому было сделано несколько ревью этой же моделью. Можно было ещё улучшить, но честно сказать мне надоело перечитывать одно и то же в пятый раз, и я остановился.

Иллюстрации генерила локальная модель Z-Image-Turbo, промпты для которой делал Qwen. Темы для картинок тоже он предложил.

Верстка так же дело "рук" ИИ - всё сделано в typst, я только сказал название шрифта. Были небольшие проблемы с форматированием, но они решились после того, как я напомнил Квену, что он имеет зрение и может посмотреть на результат вёрстки.

В общем, итог в приложении. Моя рука не прикасалась к этому произведению, по этому все претензии к Порфирию Сарайному. 😏

Кстати, почему "куратор" я хз, название тоже ИИ придумал.

PS: При желании весь процесс можно полностью автоматизировать. А это значит, что после прихода БП будет чем занять себя сидя в бункере. ☕️

Попросил Сола (GPT 5.6 Sol) сделать рецензию, а потом переписать рассказ на свой вкус. Вот что получилось (epub в комменах). Сам ещё не читал 👨‍💻

UPD: Версия с иллюстрациями от GPT в комментах.
UPD2: Прочитал, мощно 🍿

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

В общем, фатальной ошибкой было то, что после локализации бага не был сделан конкретный тест под конкретный кейс, а в вместо этого продолжали гонять огромную симуляцию всей системы. 🙂