Can AI Write Verilog? A Real-World Test by an FPGA Developer

While everyone is discussing AI writing JavaScript, Python, and Rust, an overlooked question surfaces: can large language models understand hardware description languages? Parallel execution in Verilog, timing constraints, FPGA vendor-specific primitives — are these too unfamiliar for LLMs?

A developer who works on both full-stack web development and FPGA/Verilog programming spent the past month conducting systematic tests with Claude, GPT-4, and Cursor on real FPGA projects. His conclusions are both encouraging and sobering.

Why Hardware Description Languages Are Especially Difficult for AI

The author admits he was initially skeptical. Hardware description languages are fundamentally different from software:

• Parallel execution: All logic happens simultaneously, not step by step
• Timing is critical: A bug invisible in simulation can surface at 100MHz
• Resource constraints: FPGAs have a fixed number of LUTs, flip-flops, and DSP blocks
• Toolchain differences: Xilinx, Intel, and Lattice each have their own quirks

These characteristics make verifying the correctness of Verilog code far more complex than software — passing simulation doesn't mean the hardware will work.

Blocking vs. non-blocking assignments are the most error-prone syntax details in Verilog. Blocking assignments (=) execute immediately in the order written within a sequential block, similar to variable assignment in software; non-blocking assignments (<=) update uniformly at the end of a time step, used to describe flip-flop behavior in sequential logic. Misusing blocking assignments in an always @(posedge clk) block causes simulation results to diverge from post-synthesis hardware behavior — simulation may pass, but the synthesis tool will issue warnings or even produce faulty circuits. This distinction stems from Verilog serving dual roles of simulation modeling and hardware synthesis, a typical characteristic that sets hardware description languages apart from software languages.

Setup time violations are a core concept in digital circuit timing analysis. Setup time refers to the minimum time data must remain stable before a flip-flop's clock edge arrives. When a signal's path delay through combinational logic is too long, data arrives at the flip-flop later than the setup window of the clock edge, causing a setup time violation. At 100MHz, each cycle is only 10 nanoseconds, leaving an extremely tight delay budget for combinational logic. Fixes include inserting pipeline registers (splitting long combinational paths into multiple stages), logic retiming, and using dedicated hardware resources (such as DSP blocks or block RAM) instead of general logic. This is precisely why AI can only offer generic advice but cannot replace an engineer in examining timing reports for precise path analysis.

Metastability is one of the most dangerous hazards in clock domain crossing design. When an asynchronous signal enters the current clock domain, if its transition happens to fall within a flip-flop's setup/hold window, the flip-flop output may remain in an uncertain state — neither 0 nor 1 — for some time, which is metastability. This state randomly propagates to downstream logic, causing intermittent, hard-to-reproduce functional failures. The standard solution is to use a two-flop synchronizer (sampling the asynchronous input twice in succession), and for multi-bit signals, handshake protocols or asynchronous FIFOs are needed. Metastability issues are usually invisible in simulation because simulators don't model real timing violations — they only surface when running on hardware at specific frequencies.

Vendor-specific primitives are unavoidable low-level resources in FPGA development. Xilinx's DSP48E2, Intel's DSP Block, Lattice's sysDSP, and others are proprietary hard-core compute units, each with different primitive names, port naming, parameter configurations, and cascading methods. For example, DSP48E2 has a three-stage structure of pre-adder, multiplier, and accumulator, finely controlled through parameters like INMODE, OPMODE, and ALUMODE. Information about these primitives is relatively scarce in public code repositories, and differences between device generations are significant, so LLMs often generate plausible-sounding but nonexistent primitive names or incorrect port connections.

Five Tests: From Simple Modules to Vendor Primitives

Test 1: Basic Module — UART Transmitter

The author asked Claude to write a UART transmitter with 115200 baud rate, 8N1 format, and 50MHz clock. The results were satisfactory: baud rate generator, shift register, start/stop bit logic were all present, and even an optional parity bit was added. The baud rate divisor calculation (50MHz/115200≈434) was correct.

Conclusion: Standard interface modules like UART, SPI, I2C, and PWM perform well.

Test 2: State Machine — SPI Master Controller

A more complex test: an SPI master controller with a configurable register file. The AI correctly implemented SPI mode 0 timing (CPOL=0, CPHA=0), the state machine, and chip select logic. But a classic error appeared — using blocking assignments (=) instead of non-blocking assignments (<=) in a sequential block. This kind of error may not be flagged in simulation, but synthesis tools will reject it.

Conclusion: Well-structured, but beware of subtle Verilog syntax pitfalls.

Test 3: Timing Constraints — AI's Blind Spot

When the author asked how to fix a setup time violation at 100MHz, the AI gave standard advice: add pipeline registers, retime logic, use RAM blocks, check for combinational loops. The advice itself wasn't wrong, but it was too generic — AI cannot read specific timing reports to locate problem paths.

Conclusion: Theoretical advice is acceptable, but it cannot analyze specific timing reports.

Test 4: Debugging Ability — Simple and Effective, Limited for Complex Issues

The AI found an obvious MOSI/MISO signal swap bug within seconds. But when faced with a metastability issue — the author forgot to double-synchronize an asynchronous input — the AI could only give directional advice and couldn't pinpoint the problem because it couldn't see the complete design.

Conclusion: Good at finding obvious bugs, struggles with subtle timing/metastability issues.

Test 5: Vendor-Specific Knowledge — A Clear Weakness

When asked to implement a FIR filter using Xilinx DSP48E2 primitives, the AI used generic names instead of actual Xilinx primitive names. AI frequently makes errors with vendor-specific primitive names, ports, and parameters.

Conclusion: Generic logic is fine, vendor-specific primitives require manual correction.

Testbench is specialized code for verifying the functional correctness of Verilog modules. It does not participate in synthesis and is used only in simulation environments. A testbench instantiates the module under test (DUT), applies stimulus signals, and observes whether outputs match expectations. Typical structure includes: clock generation, reset sequence, stimulus vector driving, output monitoring, and assertion checking. Compared to RTL design code, testbenches are closer to software programming style — heavily using initial blocks, task/function, file I/O, and randomization constraints, without the restrictions of the synthesizable subset. This happens to fall within LLMs' comfort zone: flexible syntax, highly pattern-based, and no hardware resource considerations. Therefore, AI's accuracy and usefulness in generating testbenches is far higher than in generating RTL code, making it one of the most pleasantly surprising use cases for FPGA developers using AI.

Where AI Actually Saves Time

After a month of practice, the author summarized the four most valuable scenarios for AI in FPGA development:

1. Boilerplate code and common interfaces: Standard modules like UART, SPI, I2C, PWM, and I2S — AI writes them correctly about 90% of the time
2. Testbenches: This is where AI is most surprisingly effective — the tedious work of writing testbenches can be largely automated
3. Explaining existing code: Paste unfamiliar Verilog into Claude and it can quickly reverse-engineer what the code does
4. Debugging obvious bugs: Syntax errors, port direction errors, missing endmodule — instantly identified

Areas AI Still Can't Handle

• Timing closure: Cannot read timing reports and precisely locate critical paths
• Resource optimization: Cannot actually run synthesis tools to see real resource usage
• Vendor toolchains: Differences in Tcl scripts and constraint formats across Vivado, Quartus, and iCEcube2
• Subtle hardware bugs: Metastability, race conditions, glitches — invisible in simulation but fatal in hardware

Practical Workflow: AI Is a Co-Pilot, Not the Pilot

The author's current workflow reflects a pragmatic human-machine division of labor:

1. Design phase: Draw block diagrams yourself; AI doesn't make architectural decisions
2. Implementation phase: Let AI write boilerplate modules
3. Integration phase: Manually connect modules
4. Testbench: Written by AI
5. Debugging phase: Paste code and ask AI for help when simulation fails
6. Synthesis phase: Run tools yourself; AI doesn't touch timing constraints

The core logic of this division is: AI handles the tedious parts, humans handle architecture and thorny problems.

Should FPGA Developers Use AI?

The author's answer is yes, but with important caveats.

Think of AI as a junior engineer — it can produce working code for well-defined tasks, but you still need to review carefully. For the hard problems of timing, resources, and architecture, you're still the one at the helm.

Hardware design is too subtle, too deeply tied to specific hardware, and too dependent on real measurements for AI to replace FPGA engineers anytime soon. But it can genuinely boost productivity — UART and SPI modules that used to take hours to write can now be completed in minutes. The time saved can be invested in what really matters: architecture design, optimization, and testing.

If you haven't started using AI in FPGA development yet, the author's view is straightforward: you're spending too much time writing UART and SPI modules from scratch.

One-line Summary

FPGA developer tests AI writing Verilog: standard modules about 90% correct, timing closure and vendor primitives remain blind spots.

Paragraph Summary

An engineer with both full-stack web and FPGA development experience conducted a month-long systematic test using Claude, GPT-4, and Cursor to evaluate AI's practical ability to write Verilog. The tests covered five dimensions: UART transmitter, SPI master controller, timing constraints, debugging, and vendor primitives. Conclusions show that AI can generate correct code about 90% of the time for standard interface modules like UART, SPI, and I2C, and performs particularly well at writing testbenches and explaining existing code; however, it exhibits typical pitfalls such as blocking/non-blocking assignment confusion and incorrect Xilinx primitive names, and cannot read timing reports to locate critical paths, analyze metastability issues, or optimize resource usage. The author proposes a pragmatic co-pilot workflow: AI handles boilerplate code and testbenches, while humans handle architectural decisions, module integration, timing constraints, and hardware debugging. AI won't replace FPGA engineers in the short term, but it can significantly boost productivity.