Hardware design code generation & chip verification (RTL, testbenches)

Chip and FPGA projects spend roughly as much effort on verification as on design, and engineers are scarce. LLM agents now draft RTL from specifications, generate UVM testbenches and assertions, run the simulator, read logs and coverage reports and iterate. Because the EDA toolchain gives objective feedback (compile, simulate, lint, synthesise), this is one of the better-grounded agentic coding domains, but it still needs experienced engineers to review every result.

Problem & value

• Today: designers hand-write RTL from specifications; verification engineers write testbenches, constrained-random sequences, assertions and coverage models, then spend long cycles triaging failing regressions from waveforms and logs. Both disciplines are short of staff, and every respin of a chip is very expensive.
• AI value: faster first drafts of boilerplate RTL (interfaces, FSMs, register blocks, glue logic), testbench scaffolding, assertion generation from spec text, regression triage, and coverage-closure suggestions. The main gain is verification productivity, not replacing design judgement.
• Evidence: EDA vendors have announced agentic products for these tasks (Synopsys AgentEngineer, in staged rollout; Cadence ChipStack AI Super Agent, early access since February 2026; Siemens EDA AI agents) and start-ups such as ChipAgents have raised funding. Public benchmarks (VerilogEval, RTLLM, NVIDIA CVDP) show strong progress on small modules but clearly weaker results on full-scale verification tasks [1][2][3]. Vendor productivity claims are not independently audited; measure on your own designs.

Variants

• ASIC design teams: RTL and UVM generation inside commercial simulators and flows.
• FPGA teams (SMB, industrial, automotive electronics): VHDL/Verilog generation, vendor-tool scripting (Vivado, Quartus, Libero), constraints and timing-closure assistance.
• Verification-only agents: assertion, testbench and coverage generation, regression triage.
• Formal verification assistants: property (SVA) and proof-script generation for formal tools.

How it works

1. spec / IP docs (RAG over specs, protocol standards, internal coding rules)
2. LLM drafts RTL / testbench / assertions
3. lint (Verilator, Spyglass-class) + compile + simulate (VCS, Xcelium, Questa, Verilator, Icarus)
4. parse logs, waveforms, coverage
5. LLM diagnoses failures and patches code
6. loop until tests pass and coverage targets are met
7. optional: synthesis / PPA (power, performance, area) feedback
8. refine
9. human design review, formal checks, sign-off

• Model: a code or reasoning LLM, ideally fine-tuned or prompted on HDL; the base model must handle concurrency, timing and bit-width semantics that differ from software.
• Tool use: the agent calls the simulator, linter and synthesis tool via a CLI or MCP-style tool interface and reads structured results; the EDA tool, not the LLM, decides pass or fail.
• Retrieval: specs, protocol standards, house coding rules and prior IP blocks via RAG.
• Human-in-the-loop: a design engineer reviews all RTL; a verification lead owns the verification plan and coverage sign-off; formal equivalence and gate-level checks stay with the standard flow. Never let generated code reach tape-out without review.

Data preparation

Preparation is a substantial part of the work (roughly 30 to 40 percent) because the model must work with your design context. Data lives in version control (Git, Perforce), IP-XACT or IP catalogues, specification PDFs and Word files, wikis, bug trackers, regression databases and simulator logs on shared servers. Typical gaps: specifications only as scanned or diagram-heavy PDFs, undocumented house coding rules, inconsistent naming across legacy IP, no clean pairs of design and verified testbench, scattered bug-fix history, and unclear licences of reused IP.

Preparation steps: - Convert specifications and protocol documents to searchable text with tables and figures preserved (DOC-014, DOC-018, PREP-006) and index them for retrieval (PREP-013). - Write down house coding rules, naming conventions and abbreviations as short documents (PREP-015, PREP-016). - Curate a golden set of verified design/testbench pairs and past bug fixes as evaluation material (PREP-018, PREP-020). - Classify blocks by confidentiality so only permitted IP reaches a given model (PREP-024). - Make simulator logs and coverage reports parseable (structured output, stable paths). - Clear the licence status of reused IP.

See GUIDE-003 for the readiness check and PREP-005 for exporting data from legacy systems.

Implementation paths

Which path for whom

• enterprise: Path C — specifications, netlists and RTL are crown-jewel IP; open-weight models on own HW3/HW4 keep them inside, and volume across teams justifies the hardware.
• developer: Path B — custom flows around open simulators (Verilator, Icarus, GHDL) with a cloud coding model are quick to build and cheap for individual or open-source projects.
• smb: Path B — vendor EDA agents (Synopsys, Cadence, Siemens) are priced and licensed for large design organisations, and HW4 self-hosting is out of reach, so use zero-retention EU-region APIs around your existing FPGA tools and move only non-sensitive blocks.

Path A — Buy (off-the-shelf)

• EDA vendor agents: Synopsys (AgentEngineer, Synopsys.ai Copilot), Cadence (ChipStack AI Super Agent, Cerebrus, JedAI platform), Siemens EDA (Questa One with AI features and agentic workflows) [1][2]. Best fit for teams already licensing these flows, since agents run next to the simulator with licensed access to the tools.
• Start-ups: ChipAgents (verification and design agents), Bronco AI and similar verification-triage tools; check IP protection and on-prem deployment options.
• General coding assistants (GitHub Copilot, Cursor, Claude Code) are used by many FPGA teams for HDL; see CODE-001 and CODE-002.
• Choose A when: you already use commercial EDA flows and want supported, tool-integrated agents.

Path B — Build on cloud APIs (recommended for SMBs)

• Models: frontier reasoning and coding models via API (Claude, GPT, Gemini; Mistral as an EU provider, e.g. Codestral/Devstral) with EU-region hosting where offered.
• Orchestration: an agent framework (LangGraph, OpenAI Agents SDK, Claude Agent SDK) that wraps the simulator and linter as tools and sandboxes execution; log and coverage parsers feed back into prompts.
• Risk: design specifications and RTL are crown-jewel IP; use zero-retention API terms and EU regions, or move sensitive blocks to Path C.
• Choose B when: you want custom flows around open simulators (Verilator, Icarus, GHDL) or FPGA tools without buying a vendor suite.

Path C — Self-host (open source)

• Models: open-weight coding/reasoning models such as Qwen3-Coder, DeepSeek-V3/R1 family, gpt-oss, Codestral/Devstral, and research HDL models (e.g. RTLCoder, CodeV, OriGen variants and NVIDIA's open work on RTL generation) [3][4].
• Tools: Verilator, Icarus Verilog, GHDL, Yosys + nextpnr, cocotb, OpenROAD / OpenLane, Surfer or GTKWave waveform viewers; serving via vLLM or Ollama.
• Hardware: HW3 for a 30-120B coder model; HW4 for the largest open models or fine-tuning; simulation compute is CPU-bound and separate from the GPU.
• Choose C when: IP cannot leave the building (typical for chip companies and defence-adjacent electronics) and you accept lower out-of-the-box quality.

Path D — Custom training

Fine-tuning on a company's own RTL, testbenches and bug-fix history improves house-style compliance and tool-specific idioms. Requires a curated corpus (thousands of verified design/testbench pairs), licence clearance of the training data, and a regression harness for evaluation. Reinforcement learning with simulator pass/fail and coverage as rewards is an active research direction.

State of the art (2026)

• Benchmarks: VerilogEval (NVIDIA) and RTLLM measure spec-to-RTL on small modules; strong models solve a large share of these, but benchmarks are widely contaminated and unrepresentative of production IP. NVIDIA's CVDP covers broader tasks (RTL generation, testbench, debug, assertion generation, code comprehension) and reports much lower scores on the hard categories [3].
• Agentic loops with real tool feedback (compile, simulate, read waveforms) outperform single-shot generation and are the basis of the commercial products [1][2].
• Verification is the commercial sweet spot: testbench scaffolding, assertions from spec text and regression triage have a clear review path and measurable coverage.
• Limits and failure modes: wrong clock-domain crossing and reset handling, unintended latches, width mismatches, non-synthesisable constructs, hallucinated IP or tool commands, testbenches that pass trivially because they check the wrong thing, and poor PPA of generated RTL. Passing a generated testbench is weak evidence when the same model wrote both design and test.

Shared resources & combinations

• Same stack (llm-code + agent-framework + sandboxed execution): CODE-001 IDE assistants, CODE-002 coding agents, CODE-004 test generation, CODE-014 bug triage and fixing, CODE-023 GPU kernel generation (similar compile-run-profile loop).
• Adjacent domains: CODE-016 (PLC code, not hardware design), CODE-020 (embedded and safety-critical software, which shares ISO 26262 evidence needs for automotive ASICs/FPGAs), SCI-006 (mechanical and generative design).

Effort, cost & KPIs

• Path A: weeks to pilot, quarters to scale; cost is mostly EDA licence add-ons and engineer time for evaluation.
• Path B: 2-4 months for a verification-triage or testbench-generation agent on one flow.
• Path C/D: 4-9 months incl. model serving, evaluation harness and possible fine-tuning.
• Cost drivers: simulator licences and runtime per agent iteration, token usage on long logs, engineering time for review.
• KPIs: compile and lint pass rate, functional coverage achieved per engineer-week, time to triage a failing regression, bugs found by AI-generated tests, share of AI-generated code accepted after review, escaped-bug rate, PPA versus hand-written baseline.

People & change

• Involve: management and the CTO (IP policy, tool budget), the design and verification leads as process owners, the engineers as end-users, IT for licence servers and GPU hosting, IT security for IP protection and sandboxing, legal for EDA licence terms, export control and customer NDAs, and the owners of IP repositories as data owners.
• Works council: depends. The tool reads design data, not people, but agent logs and per-engineer acceptance statistics can monitor performance; then §87(1) no. 6 BetrVG applies. Announce the change in good time under §90(1) no. 3 BetrVG and keep metrics at team level.
• Data protection: mostly no personal data; engineer identifiers in commits and logs are the exception. Sign an AVV (Art. 28 GDPR) with API providers where applicable and involve the DPO briefly. A DPIA is normally not needed.
• AI literacy: support engineers with training on HDL-specific failure modes such as timing, bit-width and concurrency errors (Art. 4 AI Act as amended).
• Pilot and communication: pick one non-critical block or a testbench task with a senior reviewer; position AI as relief from repetitive verification work, not as a replacement.
• Concerns: IP leakage and quality; answer with sandboxing, zero-retention terms and simulator-gated acceptance.
• Humans in control: all RTL is reviewed; sign-off stays with the verification lead.

See GUIDE-007, GUIDE-009 and GUIDE-013.

Risks, regulation & compliance

• EU AI Act: minimal risk for the development tool itself; no Annex III category. AI literacy duty (Art. 4) applies. The chip may end up in a high-risk or safety product, but that classification attaches to the product, not to the design tool [5].
• GDPR: normally no personal data; engineer identifiers in commit logs are the exception.
• IP and confidentiality: the main risk. Specifications, netlists and RTL are trade secrets; contractually exclude training on inputs, prefer EU/on-prem hosting. Check licence terms of open-source HDL that models may reproduce.
• Functional safety: for ISO 26262 (automotive), IEC 61508 or DO-254 (avionics), AI-generated code needs tool qualification arguments and the same verification evidence as human code; see CODE-020.
• Mitigations: sandboxed tool execution, independent verification (different model or human writes the checker), formal equivalence checking, mandatory review, full audit trail.

Getting started

1. Pick a bounded task: assertions for one protocol block, or triage of nightly regression failures.
2. Build an evaluation set from your own past bugs and modules, with held-out golden answers.
3. Run Verilator or your licensed simulator as an agent tool in a sandbox; start with a frontier API on non-critical blocks or an open model on-prem for sensitive ones.
4. Measure coverage, review effort and defects against a human baseline before widening scope.
5. Define IP and data-handling rules with legal before connecting any production repository.

Sources

1. Synopsys — AgentEngineer and Synopsys.ai agentic AI for chip design — https://www.synopsys.com/ai/agentic-ai.html
2. Cadence — ChipStack AI Super Agent and AI for chip design — https://www.cadence.com/en_US/home/ai.html
3. NVIDIA research — Comprehensive Verilog Design Problems (CVDP) benchmark — https://github.com/NVlabs/cvdp_benchmark
4. NVIDIA — VerilogEval benchmark — https://github.com/NVlabs/verilog-eval
5. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
6. Verilator open-source simulator — https://www.veripool.org/verilator/
7. Yosys open synthesis suite — https://github.com/YosysHQ/yosys