Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Агенты создают более быстрые FPGA-ускорители, если не заставлять их сразу писать низкоуровневое описание схемы. В работе UCLA смешанный маршрут AHRR дал ускорение в 2,6 раза относительно прямой генерации на уровне регистровых передач (RTL), хотя препринт не рецензирован и все числа получили сами авторы. Для команд, которые автоматизируют проектирование микросхем, это меняет порядок работы: сначала архитектурные решения на C++, затем точечная правка готовой схемы.
Почему HLS упрощает агенту архитектурные решения
При прямой работе с RTL агент сам задаёт тракт данных, конвейер, память, управляющие автоматы и синхронизацию. Ошибка в любом из этих решений влияет не только на скорость, но и на корректность всей схемы.
Высокоуровневый синтез (HLS) переносит часть этой работы в компилятор. Агент пишет C++ и указывает, какие циклы нужно распараллелить, как разбить массивы по банкам памяти и где построить конвейер. Vitis HLS превращает эти указания в Verilog с портами памяти, деревьями сравнений и регистрами между стадиями.
Так HLS ограничивает пространство вариантов, но оставляет в нём архитектуры, которые уже соответствуют правилам аппаратного проектирования. Агенту не приходится заново выводить низкоуровневую реализацию параллельного цикла: достаточно выразить требуемую структуру через код и директивы компилятора.
Это особенно заметно в задаче подавления пересекающихся рамок из компьютерного зрения. Через HLS агент запросил широкую параллельную обработку, а компилятор построил нужную память и дерево сравнений. При прямой генерации Verilog тот же агент выбрал заметно более узкий тракт данных: описание получилось компактнее, но ускоритель обрабатывал работу дольше.
AHRR соединяет преимущества обоих уровней. Сначала агент проектирует и оптимизирует HLS C++, затем Vitis HLS выпускает RTL, после чего агент ищет уже в нём длинные критические пути, лишние арифметические блоки и неудачно выбранную память. Низкий уровень здесь служит не исходной точкой, а последним слоем оптимизации.
Как сравнивали маршруты и где появилась прибавка
Проверка охватила 11 задач из обработки LLM, робототехники, поиска по памяти и матричных вычислений. Gemini и GPT работали через одинакового программного агента, получали фиксированный бюджет итераций и проходили скрытые тесты. Эксперименты выполняли на AMD Alveo U55C; результат принимали, только если схема сохраняла корректность, проходила размещение и трассировку и укладывалась в лимит ресурсов.
Скорость считали по времени работы ускорителя: число тактов умножали на период после трассировки. Это отличает оценку от проверки одного лишь качества кода — улучшение должно было сохраниться в реально собранной FPGA-схеме.
Генерация через HLS дала геометрическое среднее ускорение в 2,31 раза относительно прямого RTL. Последующая правка сгенерированного RTL добавила ещё 1,17 раза относительно исходной HLS-схемы. Основную прибавку обеспечил высокий уровень, а низкоуровневый этап чаще давал локальные улучшения.
На свёртке из StreamHLS агент заменил четыре полных промежуточных массива общим объёмом 405 000 значений на строчные буферы и небольшое окно из 1 842 значений. Он также удалил отдельную стадию заполнения дополненного массива. Это пример задачи для HLS-уровня: изменение структуры хранения сокращает весь объём работы, а не полирует отдельный сигнал в готовом RTL.
RTL оставался полезен там, где нужное преобразование становилось видно только после синтеза. Агенты заменяли умножение с постоянным операндом таблицей, переносили выбор значения перед умножителем и переписывали эквивалентные сравнения так, чтобы убрать вычитатель из критического пути. Большинство успешных изменений были небольшими; крупный прирост требовал полной переработки модуля.
Меняет ли AHRR планы команды
Работа даёт основание поменять порядок экспериментов, но не отказаться от RTL. Если агент сейчас начинает с текстовой спецификации и сразу пишет Verilog, разумнее дать ему HLS C++ как основной уровень поиска архитектуры. RTL стоит подключать после синтеза — для проверки критических путей, распределения памяти и арифметических блоков.
Для маленьких ядер прямой RTL по-прежнему может выиграть. Когда всё состояние помещается в регистры, агент способен сразу построить специализированную схему без ограничений HLS-компилятора. Поэтому маршрут лучше выбирать по характеру блока: циклы, массивы и широкий параллелизм отдавать HLS, а компактную управляющую логику оставлять кандидатом на прямую реализацию.
Готовый предметный компилятор тоже можно использовать как стартовую точку. В таком варианте он сначала создаёт HLS-код по заложенным разработчиками шаблонам, агент исправляет решения, которые плохо подошли конкретной задаче, а затем проверяет выпущенный RTL. Это позволяет не просить модель заново открывать архитектуру, которую уже умеет строить специализированный инструмент.
Проверка ограничена FPGA, выбранным набором вычислительных ядер и конкретной связкой агентов с Vitis HLS; каждый эксперимент выполняли однократно. Поэтому результат скорее обосновывает пилот AHRR рядом с существующим маршрутом, чем немедленную замену промышленного процесса. В таком пилоте нужно сохранить скрытые тесты, полный синтез, размещение и трассировку: без них агент сможет улучшать оценку компилятора, не улучшая итоговую схему.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
