LLM4RTL: Automating RTL with Large Language Models

• LLM4RTL is a methodology that employs large language models to translate natural language design descriptions into synthesizable RTL, addressing unique hardware constraints.
• It integrates structured data, reasoning traces, and tool-assisted preprocessing to handle concurrent, event-driven, and timing-sensitive aspects beyond typical software code generation.
• Recent benchmarks and pipelines demonstrate that optimal RTL generation hinges on data quality, verification feedback, and reasoning supervision more than model size alone.

LLM4RTL denotes the use of LLMs for register-transfer level design automation, most prominently the generation of Verilog or SystemVerilog from functional descriptions, but also optimization, verification, retrieval, specification generation, and compiler-mediated design entry. In the literature, the canonical formulation is a mapping from a natural-language design description $\mathcal{L}$ to generated RTL $\mathcal{V}$, written as $\mathcal{V}=F(\mathcal{L})$, with prompt transformation and optional human post-processing modeled as $\mathcal{V}=F(\mathcal{L}_P)$, $\mathcal{L}_P=P(\mathcal{L})$, and $\mathcal{V}=H(F(\mathcal{L}_P))$ (Lu et al., 2023). The field treats RTL generation as substantially harder than ordinary software code generation because RTL is concurrent, event-driven, timing-sensitive, width-constrained, and evaluated under synthesizability and functional-correctness requirements rather than surface-level textual plausibility (Akyash et al., 11 May 2025, Deng et al., 5 Jun 2025).

1. Scope and task formulations

Early benchmark work framed LLM4RTL primarily as natural-language-to-RTL generation: a model receives a design description containing the module name, I/O names and widths, and functionality, and must emit synthesizable RTL consistent with the specification (Lu et al., 2023). Subsequent work broadened the input space to include truth tables, waveforms, Karnaugh maps, and sequential timing information, arguing that many hard VerilogEval-Human tasks require explicit logical inference over structured, non-prose artifacts rather than free-form text alone (Jin et al., 13 Jun 2026). The task has also expanded in the reverse direction, with RTL-to-specification generation defined as producing a human-readable functional specification that captures module name, port list and bit-widths, functional intent, control flow, data flow, timing behavior, and sequential behavior such as FSM transitions, clocks, and resets (Huang et al., 17 Nov 2025).

A recurring distinction in the literature is between syntax, semantics, and design quality. RTLLM formalized three progressive goals: syntax goal, functionality goal, and design quality goal, with the quality stage measured using post-synthesis area, power, and timing reported as worst negative slack (Lu et al., 2023). Later papers preserved this separation and treated it as foundational: CPPL argued that direct RTL generation entangles behavior, widths, structure, and corner cases into one unconstrained text-generation problem, while DecoRTL argued that decoding policies designed for natural language fail because RTL has syntax-critical regions and design-critical regions that should not be sampled identically (Yin et al., 18 May 2026, Akyash et al., 3 Jul 2025).

A second core formulation concerns the role of reasoning. ScaleRTL explicitly characterized accurate RTL generation as a reasoning problem involving timing, state transitions, signal widths, and hardware-specific constraints, rather than a conventional text-to-code task (Deng et al., 5 Jun 2025). DeepRTL2 extended the scope further by treating RTL as both a generative and an embedding domain, covering code generation, code understanding, natural-language code search, functionality equivalence checking, and early performance prediction (Liu et al., 28 May 2025). This suggests that LLM4RTL is best understood not as a single generation benchmark, but as a broader RTL intelligence stack.

2. Benchmarks and evaluation methodology

The field’s development has been tightly coupled to open benchmarks. RTLLM introduced an automatically evaluable benchmark with 30 designs—11 arithmetic and 19 logic—together with natural-language specifications, testbenches, and human-crafted reference RTLs (Lu et al., 2023). OpenLLM-RTL later expanded this line through RTLLM 2.0, increasing the benchmark to 50 hand-crafted designs and organizing them into arithmetic, memory, control, and miscellaneous modules (Liu et al., 19 Mar 2025). VerilogEval remained the dominant external benchmark for pass@k reporting, with VerilogEval-Machine and VerilogEval-Human frequently used in fine-tuning and inference-time studies (Deng et al., 5 Jun 2025).

Benchmark	Primary task	Reported evaluation focus
RTLLM	Design RTL generation	Syntax, functionality, design quality
RTLLM 2.0	Design RTL generation	Syntax correctness, functional correctness, quality goal
AssertEval	Assertion generation for RTL verification	Syntax, FPV pass/fail, COI coverage
VerilogEval / VerilogEval-V2	RTL generation and reverse RTL-to-spec workflows	pass@k, reconstruction-based correctness

RTLLM’s main methodological contribution was to make syntax, correctness, and quality separable. Syntax success required successful synthesis; functionality required passing the supplied testbench; and quality compared synthesized area, power, and timing against a human reference design (Lu et al., 2023). This design was important because prior work often reported only whether code compiled or passed a small number of tests. OpenLLM-RTL carried the same philosophy into verification with AssertEval, an 18-design benchmark for assertion generation that evaluates syntax, formal-property-verification pass/fail, and cone-of-influence coverage (Liu et al., 19 Mar 2025).

Later work introduced more hardware-aware metrics for non-generation tasks. In RTL-to-specification generation, text metrics such as BLEU, ROUGE-L, BERTScore-R, and SentenceBERT cosine similarity were judged insufficient because they correlate weakly with behavioral fidelity. The proposed GPT-RTL Score averages five aspect scores—design intent, ports, logical functionality, state transition and clock-cycle behavior, and data/control flow—while the RTL-Reconstruction Score reconstructs RTL from the generated specification and measures pass@1 against the benchmark testbench (Huang et al., 17 Nov 2025). A common misconception in the area is therefore that syntactic validity or semantic similarity is an adequate proxy for design correctness; the benchmark literature consistently rejects that position.

3. Data construction, curation, and post-training

A central theme of LLM4RTL is that data scarcity and data quality are first-order determinants of performance. RTLCoder addressed this by constructing more than 27,000 labeled instruction-code pairs through keyword preparation, instruction generation, mutation-based augmentation, and GPT-generated candidate filtering with Pyverilog syntax checking, and combined standard maximum-likelihood training with a code-quality-aware ranking loss (Liu et al., 2023). OpenLLM-RTL later scaled open training data further with RTLCoder-Data, releasing an 80K raw instruction-code dataset and a 7K verified high-quality subset produced by assertion generation and formal-checking-based filtering (Liu et al., 19 Mar 2025).

Several papers showed that verified or refined data can outperform larger but noisier corpora. OpenLLM-RTL reported that DeepSeek-Direct trained on the 7K verified set outperformed the same model trained on 27K raw samples and in many cases surpassed the 50K raw-data model, while using less than 20% of the training time of the 50K model (Liu et al., 19 Mar 2025). The 2026 LLM4RTL system made the same point through its JRCRC pipeline—judge-renew-check-renew-check—applied to the OriGen dataset. Starting from 222,075 aligned text-description/RTL pairs and retaining only samples shorter than 1,024 tokens, it used DeepSeek-V3 as a judge and first-round rewriter, GPT-5 for hard cases, and compiler/testbench checking to refine the corpus; the resulting datasets became smaller, from 174,971 to 165,916 samples, while VerilogEval-Human performance improved from PASS@1/PASS@5 of 0.4952/0.5712 to 0.5279/0.5971 (Jin et al., 13 Jun 2026).

ScaleRTL pushed the data-centric program further by treating reasoning traces as the key training signal. It filtered 5 million raw RTL snippets totaling over 189B tokens down to 62K high-quality scripts, then used DeepSeek-R1 to produce triples $\langle x,r,y\rangle$ of specification, chain-of-thought reasoning, and final RTL, yielding 62K samples with an average of 56K tokens and a total of 3.5B tokens (Deng et al., 5 Jun 2025). The model was then fine-tuned from DeepSeek-R1-Distill-Qwen-32B with a supervised objective that explicitly learns both the reasoning trace and the final code. DeepRTL2 followed a different but related route: a first-stage curriculum for line-level and module-level generation/understanding, followed by a second stage that unifies generation and embedding tasks via GRIT-style multi-task tuning and contrastive learning (Liu et al., 28 May 2025).

Across these papers, the repeated empirical result is that dataset organization, verification, and reasoning supervision are not auxiliary concerns. They constitute much of the method.

4. Structural, tool-assisted, and inference-time methods

One branch of LLM4RTL reduces generation difficulty by introducing structure or tools between the prompt and the model. The 2026 LLM4RTL system combined refined training data with preprocessing tools that parse tables, waveforms, and Karnaugh maps, derive Boolean relations, infer state variables for sequential outputs, and concatenate the extracted logic back into the prompt before Verilog generation (Jin et al., 13 Jun 2026). On VerilogEval-Human, the refined dataset alone reached 0.5279 PASS@1 and 0.5971 PASS@5; adding tools raised this to 0.6003 and 0.6632, and tools plus iterative syntax-error-driven inference reached 0.6080 and 0.6673, compared with 0.6022 and 0.6605 for GPT-4O in the same table (Jin et al., 13 Jun 2026).

RTL++ injected structure during data generation and instruction tuning by textualizing control flow graphs and data flow graphs rather than using raw code alone. Each RTL sample was flattened, converted into high-level CFG and DFG representations with node attributes and temporal behavior, and used to synthesize richer instruction-code pairs for fine-tuning CodeLlama-7B-Instruct (Akyash et al., 11 May 2025). The reported ablation on a 5K dataset showed that textualized graph representations improved pass@10 from 25.6 to 30.7 at temperature 0.7, and the paper stated that the gain reaches 18% at 100K (Akyash et al., 11 May 2025).

CPPL reframed the problem more radically by replacing direct RTL or direct CIRCT IR generation with a compiler-mediated frontend. Its Python DSL fixes module interfaces through typed function signatures such as In[w] and Out[w], lowers the design into a JSON-based CPPL IR, validates legality, widths, hierarchy, and bindings, and deterministically lowers the result to CIRCT and then to synthesizable Verilog (Yin et al., 18 May 2026). On RTLLM, CPPL improved functional pass@1 over both direct Verilog and direct CIRCT IR generation; the paper reported pass@1 values of 0.800 for Claude-opus-4.6, 0.782 for GPT-5.3-codex, and 0.768 for Qwen-3.6-plus, and also reported a 16.3% reduction in geometric-average post-aigmap AIG node counts when CIRCT optimization was enabled (Yin et al., 18 May 2026).

A second branch improves outputs without retraining. DecoRTL treated decoding as an RTL-specific problem, combining contrastive self-consistency sampling with syntax-aware temperature adaptation. Using top-$K$ candidate re-ranking in embedding space and per-token temperature control, it improved both synthesizability and functional correctness on VerilogEval-Human across CodeLlama-7B, QwenCoder-2.5-14B, and CodeV, while increasing average decoding time per token on QwenCoder-2.5-14B only from 0.1383 s to 0.1413 s (Akyash et al., 3 Jul 2025). MeltRTL likewise operated entirely at inference time, but intervened inside the model: it trained probes on attention-head activations from 200 instruction-code pairs, categorized designs into combinational, sequential/datapath, and FSM/controller experts, and applied additive steering to probe-selected heads. On VerilogEval, the multi-expert variant improved QwenCoder2.5-14B from 85.33% to 96.00% synthesizability and from 45.33% to 60.00% functional correctness, with 27% runtime overhead (Mashnoor et al., 19 Jan 2026).

Long-context optimization raised an additional structural challenge. LongRTL addressed industrial-scale, monolithic RTL by combining a Partition Agent that uses AST graph similarity and Tree-DP to partition a design into semantically meaningful subtrees, an Optimization Agent with AST+RTL multimodal retrieval and MCTS-based prompt exploration, and a Reconstruction Agent using logic-aware ordering and Graph-RAG prompting (Ye et al., 8 Jun 2026). On its single-module long-context benchmark, LongRTL reported 100% functional equivalence and average delay/area/power ratios of 0.72/0.73/0.76 relative to the original RTL (Ye et al., 8 Jun 2026).

5. Beyond direct generation: verification, understanding, and reverse synthesis

The field has progressively moved beyond one-shot RTL emission. DeepRTL2 explicitly positioned itself as a versatile RTL model family rather than a pure generator, covering code generation, code understanding, natural-language code search, functionality equivalence checking, and performance prediction (Liu et al., 28 May 2025). Its reported results included pass@1 syntax/function scores of 71.60%/38.50% for the DeepSeek variant on RTLLM v2.0 generation, F1 of 0.463 for natural-language code search with the Llama variant, average precision of 0.667 for functionality equivalence checking with the Llama variant, and $r2\_score$ values of 0.773 for area and 0.772 for delay with the DeepSeek variant (Liu et al., 28 May 2025). This broadened the meaning of LLM4RTL from “generate RTL from English” to “produce RTL-native representations useful throughout the EDA workflow.”

Verification-oriented work made a parallel move. OpenLLM-RTL’s AssertEval benchmark treated assertion generation as a first-class LLM task, using bug-free golden RTL, formal property verification, and COI coverage rather than only text comparison (Liu et al., 19 Mar 2025). In a different direction, the specification-generation study reversed the standard pipeline and asked whether an LLM can produce a faithful natural-language specification from RTL. Under a multi-step reasoning prompt, GPT-5-Codex achieved an RTL-Reconstruction Score of 98.7% on VerilogEval and 76% on RTLLM, while Qwen3-Coder-480B achieved 80.1% and 66% respectively (Huang et al., 17 Nov 2025). The weak observed correlation between GPT-RTL Score and RR Score, reported as 0.28, underscored again that textual plausibility is not equivalent to reconstructable hardware semantics (Huang et al., 17 Nov 2025).

Reasoning-centered RTL generation also matured. ScaleRTL demonstrated that explicit long reasoning traces plus test-time reflection and self-correction can materially improve benchmark performance. ScaleRTL-32B achieved 80.0/88.3 pass@1/pass@5 on VerilogEval-Machine, 76.3/88.4 on VerilogEval-Human, and 55.5/75.4 on RTLLM v1.1; the test-time scaling variant ScaleRTL$^\dagger$-32B improved these to 83.2/89.1, 80.4/90.8, and 60.7/78.5 respectively (Deng et al., 5 Jun 2025). The paper’s analysis that accuracy rises with reasoning length and resembles a logarithmic scaling law provides a technical basis for treating hardware generation as a long-horizon reasoning problem rather than a short-form completion task (Deng et al., 5 Jun 2025).

6. Limitations, misconceptions, and open directions

The literature is unusually explicit about its failure modes. A persistent misconception is that larger models alone solve RTL generation. Several papers dispute this directly: RTLCoder argued that a 7B open model with domain-specific data and objective design can beat GPT-3.5 and exceed GPT-4 on VerilogEval EvalMachine pass@1 (Liu et al., 2023); LLM4RTL reported performance comparable to GPT-4o using a much smaller model when combined with dataset refinement and tools (Jin et al., 13 Jun 2026); and MeltRTL improved a fixed base model substantially without any fine-tuning by intervening on internal activations (Mashnoor et al., 19 Jan 2026). The broader implication is that data quality, structure, decoding, and verifier feedback are often more decisive than parameter count.

A second misconception is that syntax-valid RTL is nearly correct RTL. RTLLM’s separation of syntax, functionality, and design quality already showed otherwise (Lu et al., 2023). DecoRTL documented repetitive, hallucinated, or structurally invalid outputs under conventional decoding, and specification-generation work showed cases where an apparently high-quality textual specification still reconstructed to failing RTL because of subtle reset or timing errors (Akyash et al., 3 Jul 2025, Huang et al., 17 Nov 2025). The benchmark ecosystem therefore treats simulation, synthesis, PPA, formal checking, or reconstruction as indispensable.

The hardest unresolved issue is temporal and structural reasoning. The metamorphosis study on RTL optimization reported that LLM-based methods can effectively optimize logic operations and outperform existing compiler-based methods, but do not perform better than compiler-based methods on complex timing logic, particularly timing control flow optimization and clock domain optimization (Xu et al., 22 Jul 2025). The paper attributed this to weak understanding of FSM state duration, timing chains, clock cycles, inter-cycle dependencies, and CDC structure. LongRTL addressed one part of this problem by decomposing large entangled designs, but its AST-centric approach still assumes that graph structure is a sufficient proxy for deeper semantics (Ye et al., 8 Jun 2026). Similarly, CPPL’s success suggests that some of the problem may be shifted from unconstrained generation to statically checkable intermediate forms, but not eliminated (Yin et al., 18 May 2026).

Open directions repeatedly proposed across the literature include larger and more heterogeneous real-world datasets, stronger open-source models for reproducibility, richer multimodal interfaces, automated consistency checks, formal-verification or theorem-proving feedback loops, and better treatment of long-context industrial codebases (He et al., 3 Nov 2025, Liu et al., 19 Mar 2025, Ye et al., 8 Jun 2026). Taken together, these works suggest that the mature form of LLM4RTL is unlikely to be a single prompt-to-Verilog model. A more plausible trajectory is a hybrid stack in which curated data, structured intermediate representations, graph or tool-based preprocessing, verifier-backed search, and inference-time control all act as co-equal components of RTL design automation.