---
title: 'LLM4RTL: Automating RTL with Large Language Models'
url: https://www.emergentmind.com/topics/llm4rtl
type: topic
---

# LLM4RTL: Automating RTL with Large Language Models

LLM4RTL denotes the use of large language models 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))$ [2308.05345]. 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 [2505.13479], [2506.05566].

## 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 [2308.05345]. 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 [2606.15500]. 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 [2512.00045].

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 [2308.05345]. 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 [2605.17892], [2507.02226].

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 [2506.05566]. 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 [2506.15697]. 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 [2308.05345]. 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 [2503.15112]. 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 [2506.05566].

| 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 [2308.05345]. 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 [2503.15112].

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 [2512.00045]. 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 [2312.08617]. 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 [2503.15112].

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 [2503.15112]. 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 [2606.15500].

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 [2506.05566]. 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 [2506.15697].

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 [2606.15500]. 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 [2606.15500].

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 [2505.13479]. 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 [2505.13479].

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 [2605.17892]. 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 [2605.17892].

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 [2507.02226]. 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 [2601.13015].

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 [2606.08944]. 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 [2606.08944].

## 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 [2506.15697]. 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 [2506.15697]. 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 [2503.15112]. 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 [2512.00045]. 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 [2512.00045].

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 [2506.05566]. 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 [2506.05566].

## 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 [2312.08617]; LLM4RTL reported performance comparable to GPT-4o using a much smaller model when combined with dataset refinement and tools [2606.15500]; and MeltRTL improved a fixed base model substantially without any fine-tuning by intervening on internal activations [2601.13015]. 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 [2308.05345]. 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 [2507.02226], [2512.00045]. 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 [2507.16808]. 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 [2606.08944]. Similarly, CPPL’s success suggests that some of the problem may be shifted from unconstrained generation to statically checkable intermediate forms, but not eliminated [2605.17892].

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 [2511.01423], [2503.15112], [2606.08944]. 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.

Source: https://www.emergentmind.com/topics/llm4rtl