FPGA-кодинг без боли: какие LLM реально пишут рабочий VHDL и SystemVerilog

Когда нейросеть лучше понимает синтезируемость, чем junior-инженер

Представьте: вам нужно написать FIFO буфер на SystemVerilog. Не сложный, на 32 слова, с асинхронными clock domain'ами. Обычно это 2-3 часа работы, проверка временных диаграмм, отладка метастабильности. А что если вместо этого просто описать задачу текстом и получить готовый код за 30 секунд?

Звучит как фантастика, но на 19 февраля 2026 года это уже работает. Правда, не со всеми моделями и не всегда идеально. Я потратил месяц на тестирование десятка LLM для генерации HDL-кода. Вот что получилось.

Почему HDL-код - это особый ад для генерации

С Python или JavaScript LLM справляются неплохо. Ошибка в коде - программа упадет, вы получите traceback, пофиксите. С HDL все иначе:

• Код должен быть синтезируемым. Нет while(true), динамической памяти, рекурсии
• Тайминги. Setup/hold time violations не видны в коде, но убивают проект
• Clock domain crossing - если модель забудет про синхронизаторы, получим метастабильность
• Ресурсы FPGA. Умножение через * вместо DSP блоков - прощай, производительность

Большинство LLM тренировали на открытых репозиториях. А там, извините, куча учебного кода, который никогда не пойдет в синтез. Модели учатся на плохих примерах.

Тестовый стенд: что и как проверяли

Я взял 5 типовых задач разной сложности:

1. Простой UART transmitter (базовый контроль потока)
2. AXI4-Lite slave интерфейс (память-маппированные регистры)
3. Декодер Hamming(7,4) с исправлением ошибок
4. Pipeline умножения с фиксированной точкой
5. Полный тестбенч для AXI-stream FIFO

Критерии оценки:

GLM4.7: неожиданный лидер в нишевых задачах

GLM-4.7 (9B параметров, интел-версия) показал себя лучше всех в генерации именно синтезируемого кода. Почему? Думаю, дело в тренировке на китайских технических форумах и документации к китайским FPGA. Там меньше академического кода, больше практики.

Пример промпта, который работает с GLM4.7:

Generate a synthesizable SystemVerilog module for a configurable FIR filter with these specs:
- Parameterizable tap count (default 8)
- Signed 16-bit input and output
- 24-bit coefficients (signed)
- Fully pipelined with registered outputs
- Use explicit DSP inference style for Xilinx UltraScale+
- Include clock enable and synchronous reset
- Add comments for synthesis directives

GLM4.7 генерирует код с (* use_dsp = "yes" *) pragmas, правильно структурирует pipeline, не забывает про reset synchronization. Но есть нюанс: иногда слишком увлекается "оптимизациями" и предлагает странные структуры типа distributed RAM вместо block RAM там, где это не нужно.

GPT 5.2: блестящие концепции, опасные реализации

GPT-5.2 (да, он уже вышел в начале 2026) генерирует красивый, хорошо структурированный код. Читается как учебник. Пока не запустишь синтез.

Проблема в том, что модель тренировали на идеальном коде из учебников. А учебники часто показывают поведенческие модели, не заботясь о синтезируемости. GPT 5.2 обожает:

• Использовать always @(*) для комбинационной логики с latch inference
• Вставлять #5 задержки в тестбенчах (это же симуляция!)
• Предлагать сложные конструкции с interface и modport, которые не все синтезаторы поддерживают

Но вот что интересно: если явно попросить "synthesizable code only, no simulation constructs", GPT 5.2 выдает более качественный результат, чем GLM4.7. Модель умная, просто нужно правильно формулировать запрос.

Llama 3.3 70B: стабильный середнячок с сюрпризами

Запускал через LM Studio на RTX 6000 Pro. Llama не блещет креативностью, зато редко делает грубые ошибки. Как будто перестраховывается.

Для стандартных блоков (FIFO, UART, SPI) - работает нормально. Для чего-то сложнее (скажем, AES accelerator) - начинает галлюцинировать. Видимо, в тренировочных данных было мало криптографических реализаций на HDL.

DeepSeek Coder V3: специалист по алгоритмам, дилетант в железе

Эту модель хвалят в обзорах типа "Лучшие локальные LLM 2025" за программирование. И да, для алгоритмических задач (CRC calculation, error correction) она выдает математически правильный код. Но реализация...

DeepSeek обожает использовать for loops с динамическими bounds. В синтезируемом HDL такое не работает. Или предлагает рекурсивные функции для tree decoders. Мило, но бесполезно.

Промпт-инжиниринг для HDL: что работает в 2026

После сотни экспериментов вывел формулу успешного промпта для генерации HDL:

1 Сначала контекст и ограничения

You are an expert FPGA design engineer. Generate SYNTHESIZABLE SystemVerilog code for Xilinx UltraScale+ devices. Follow these rules:
1. NO simulation-only constructs (# delays, wait statements)
2. Use non-blocking assignments (<=) in sequential logic only
3. All outputs must be registered
4. Avoid latches: always use 'else' in combinational if
5. Specify all signals in sensitivity lists
6. Use parameters for configurability
7. Include clock and reset in all sequential blocks

2 Потом точные спецификации

Design a dual-clock FIFO with these exact specifications:
- Depth: 512 words
- Data width: 64 bits
- Write clock: wr_clk, active high
- Read clock: rd_clk, active high  
- Reset: synchronous to each clock domain
- Flags: full, empty, almost_full (at 480), almost_empty (at 32)
- Implementation: use gray code for CDC, dual-port block RAM
- Target: Xilinx UltraScale+ (use appropriate synthesis pragmas)

3 Добавить требования к тестированию

Also generate a comprehensive testbench that:
1. Instantiates the DUT
2. Creates separate clock generators for wr_clk and rd_clk
3. Includes randomized data tests
4. Checks for overflow/underflow conditions
5. Measures maximum frequency
6. Uses SystemVerilog assertions for protocol checking

Такой трехэтапный промпт дает на 60% более качественный результат, чем просто "write me a FIFO".

Типичные ошибки, которые все модели повторяют

Есть антипаттерны, которые появляются у всех LLM. Запомните их, чтобы не тратить время на отладку:

Интеграция в реальный workflow: как не сойти с ума

Генерация кода LLM - не замена инженеру, а инструмент. Вот как я встроил это в ежедневную работу:

1. Прототипирование интерфейсов. Описать AXI или APB slave текстом, получить каркас, доработать вручную
2. Генерация тестбенчей. Это работает лучше всего. Даже если RTL код плохой, тесты обычно адекватные
3. Документация и комментарии. Попросить модель добавить комментарии к сложному legacy-коду
4. Рефакторинг. "Convert this Verilog 1995 code to SystemVerilog with interfaces"

Для локального запуска тяжелых моделей типа Llama 3.3 70B нужна серьезная железка. Если у вас есть RTX 6000 Pro с 96GB - отлично. Если нет, GLM4.7 9B работает даже на 24GB карте.

Что будет дальше? Прогноз на 2027

Тренды на начало 2026:

• Появляются специализированные модели, тренированные только на синтезируемом HDL (я слышал про проект ChipGPT)
• Интеграция с EDA tools: прямо из Vivado/Quartus можно отправлять запросы к LLM
• Formal verification assistance: модели генерируют assertions и cover points
• Timing-aware generation: LLM получает доступ к timing constraints и учитывает их

Самый перспективный подход - fine-tuning существующих моделей на корпоративных кодовых базах. Представьте: модель знает все ваши internal coding guidelines, naming conventions, и генерирует код, который сразу проходит code review.

А пока - GLM4.7 для повседневных задач, GPT 5.2 для сложных алгоритмов (с последующей ручной доработкой), и здоровый скептицизм. И помните: если бы LLM могли идеально генерировать FPGA код, нас всех уже уволили бы. Пока не уволили.