Разработка аппаратных ускорителей – это традиционно область, где нужен серьёзный опыт. Один неверно заданный параметр в описании схемы может стоить нескольких дней отладки. Именно поэтому любое снижение порога входа здесь имеет реальную ценность. Недавний конкурсный эксперимент показал: языковые модели способны стать полноценными партнёрами в этой работе – не заменяя инженера, но значительно ускоряя его путь.
Задача, которую поставили студенты
Речь идёт об оптимизации криптографического алгоритма HMAC-SHA-256 – широко используемого метода проверки подлинности данных. В рамках студенческого конкурса с треком на LLM-оптимизацию участники взяли за основу реализацию этого алгоритма для программируемой микросхемы (FPGA) серии UltraScale+ и попытались сделать её быстрее с помощью языковых моделей. В качестве инструментов разработки использовалась среда Vitis HLS 2025.2, а в качестве ИИ-советников – модели gpt-5-turbo и claude-sonnet-4.
Исходная реализация работала за 880 тактов при тактовой частоте около 4 нс на такт – итого примерно 3,54 микросекунды на операцию. По итогам двух недель работы команда получила ускорение в 2,22 раза и сокращение задержки на 52%. Ресурсы микросхемы при этом остались почти нетронутыми – использование логики не превысило 2% от доступного объёма.
Что вообще происходит внутри SHA-256
Если коротко: алгоритм SHA-256 берёт входные данные блоками по 512 бит и прогоняет каждый блок через три последовательных этапа. Сначала данные дополняются до нужного формата, затем из 16 исходных слов разворачивается расписание из 64 слов, и наконец запускается 64 раунда вычислений, которые превращают блок в фрагмент итогового хеша. HMAC добавляет поверх этого ещё один слой: ключ смешивается с данными особым образом, и весь процесс сжатия запускается дважды.
В исходной аппаратной реализации три этапа были соединены очередями (FIFO) и помечены как параллельные. Но здесь была архитектурная проблема: параллельность на бумаге не работала на практике. Второй этап не мог начаться, пока первый не обработал целый блок целиком, а третий – пока второй не завершил свою часть. Очереди между ними добавляли накладные расходы, не давая при этом никакого реального перекрытия по времени. Третий этап (64 раунда вычислений) занимал 58% всего времени выполнения и был очевидным узким местом.
С чего начался разговор с ИИ
Первый запрос к языковой модели был намеренно открытым. Инженер передал полный исходный код и отчёт о синтезе, а затем спросил:
"Ты – старший инженер Vitis HLS и архитектор аппаратного обеспечения. Проанализируй этот код и скажи, в каких направлениях его можно оптимизировать и насколько это реалистично."
Модель вернула структурированный анализ: указала на псевдопараллельность первых двух этапов, идентифицировала третий этап как доминирующий по задержке и предложила несколько направлений для улучшений. Ключевой момент здесь не в SHA-256 как таковом, а в том, что языковая модель, получив отчёт о синтезе вместе с кодом, способна воспроизвести ту работу по анализу узких мест, которую раньше мог выполнить только опытный инженер, вручную читая таблицы задержек.
Четыре фазы, которые работают
В ходе эксперимента сложился устойчивый рабочий паттерн, который авторы описывают как четырёхфазный цикл. Он повторяется на каждом шаге оптимизации и, судя по результатам, хорошо переносится на другие проекты – не только на SHA-256.
Загрузить контекст
Первая фаза – передать модели максимум информации о текущем состоянии проекта: исходный код, отчёт о синтезе, характеристики целевого устройства. Распространённая ошибка – просить совет по оптимизации без конкретных цифр. Без них модель переходит к общим рекомендациям вместо того, чтобы работать с реальной проблемой.
Исследовать варианты
Вторая фаза – попросить несколько стратегий с явным указанием на компромиссы. Хорошо сработавший запрос выглядел так:
"Исходя из этого отчёта о синтезе и ограничений устройства, предложи несколько стратегий оптимизации. Для каждой объясни ожидаемое улучшение задержки, стоимость по ресурсам и возможные риски."
В ответ модель предложила пять стратегий – от полного комбинационного разворачивания (максимальная производительность, нереалистична по времянке) до двухпутевого параллелизма (хороший прирост при приемлемых затратах ресурсов). Инженер выбрал второй вариант, проверив, что занятость логических ресурсов останется в пределах бюджета устройства.
Генерировать код точечно
Третья фаза – формулировать запрос на генерацию кода максимально конкретно. Хорошо работали запросы, которые называли конкретное действие, указывали цель, явно фиксировали, что нельзя трогать, и предупреждали об известных подводных камнях:
"Объедини generateMsgSchedule и PreProcessing в одну функцию для улучшения параллелизма. Сгенерируй объединённую функцию и обновлённую функцию верхнего уровня. Не модифицируй другие вызовы функций. Будь осторожен с конфликтами директив и недопустимыми соединениями."
Такой уровень конкретики стабильно давал более качественный результат, чем открытые запросы вроде «сделай это быстрее».
Проверить и вернуть обратную связь
Четвёртая фаза – запустить синтез и симуляцию, и если что-то пошло не так, превратить сообщения об ошибках в следующий запрос. Например:
"Синтез сообщает об ошибках [XFORM 203-313] и [RTGEN 206-102]. Исправь конфликты."
Модель диагностировала причины: конфликт двух директив, применённых на одном уровне иерархии, и неиспользуемый поток данных, оставшийся после слияния функций. Исправленный вариант уходил на повторный синтез, и цикл продолжался. Обычно на один шаг оптимизации уходило две-три итерации.
Где ИИ помогает, а где подводит
За три крупных итерации оптимизации картина сильных и слабых сторон языковых моделей стала отчётливой.
Модели хорошо справлялись с распознаванием архитектурных антипаттернов: увидели, что директива параллельного выполнения применена к этапам с последовательными зависимостями, и предложили убрать лишний уровень косвенности. Они также заметили, что глубина рекуррентности в генерации расписания составляет 16 слов, а не 64, и предложили использовать кольцевой буфер – технически корректное и эффективное решение, для которого нужно понимать алгоритм.
Первый вариант сгенерированного кода оказывался работоспособным примерно в 80% случаев – структурно корректным, с правильными интерфейсами и расстановкой директив. Оставшиеся 20% требовали ручной правки.
Стабильные провалы случались в трёх ситуациях. Во-первых, модели нарушали правила совместного применения директив – например, ставили директиву конвейеризации внутри функции, уже управляемой директивой параллельного потока данных, что недопустимо на одном уровне иерархии. Это задокументированное ограничение инструмента, но в обучающих данных моделей оно, судя по всему, представлено слабо. Во-вторых, после слияния функций модели оставляли мёртвый код – утилиты дублирования потоков, которые больше не имели двух потребителей и вызывали ошибки соединения. В-третьих, граничные условия в алгоритмической логике – пути дополнения данных в SHA-256 – требовали тщательной ручной проверки через тестовые векторы.
Авторы отмечают, что эти слабости не являются принципиальными ограничениями языковых моделей. Они отражают отсутствие специализированного контекста в обучающих данных. Структурированные запросы уже сокращают частоту ошибок, а дальнейшее улучшение возможно за счёт подключения специализированных агентов с базой знаний по конкретным инструментам разработки.
Что получилось в итоге
Финальная архитектура объединила два преобразования. Первое – слияние двух функций из трёх в одну: исчезла очередь между ними, три последовательных этапа сократились до двух. Второе – двухпутевой параллелизм: специальный модуль распределяет блоки данных поочерёдно между двумя идентичными вычислительными путями, каждый из которых содержит объединённый этап предобработки и собственный экземпляр функции сжатия. Ещё один модуль собирает результаты в правильном порядке.
Каждый из двух путей обрабатывает один блок за 72 + 69 тактов. Два пути работают параллельно, что вдвое сокращает эффективное время обработки. С учётом накладных расходов на распределение, сборку и обёртку HMAC итоговый прирост составил 2,22× на уровне всей операции.
Корректность проверялась на каждом этапе с помощью совместной симуляции по официальным тестовым векторам стандарта FIPS 180-4. Потребление ресурсов микросхемы осталось значительно ниже 2% от доступного объёма – ускорение достигнуто за счёт архитектурной перестройки, а не за счёт «грубой силы» дополнительного железа.
Что это говорит о будущем аппаратной разработки
Авторы оценивают вклад ИИ-взаимодействий примерно в 60% интеллектуальной работы; оставшиеся 40% – это человеческая валидация синтеза, отладка и принятие решений. Весь процесс занял около двух недель.
Предложенный четырёхфазный цикл не является специфическим для SHA-256. Это общий подход для любых аппаратных ядер, где инженер может опираться на реальные результаты синтеза и симуляции. В таком цикле языковая модель наиболее ценна как инструмент ускорения архитектурного рассуждения и генерации черновых вариантов кода, тогда как человек отвечает за окончательные решения: управление ограничениями, валидацию через инструменты разработки и сквозную корректность.
Аппаратная разработка по-прежнему требует строгой физической верификации, поэтому языковые модели расширяют возможности архитектурного исследования, но не заменяют финальную проверку. Даже на текущем уровне они уже снизили порог входа и сжали цикл оптимизации настолько, что инженеры без глубокого FPGA-опыта смогли получить результаты, которые раньше требовали многолетней специализации.
