RTL generation looks deceptively close to software generation. Both begin with a textual requirement and end with code. The similarity ends when correctness is evaluated. Software can often recover from an incorrect branch at runtime; an RTL mistake becomes replicated logic, a protocol deadlock, an unreset state, or a timing path that persists through every downstream stage. Syntax is the cheapest part of the problem.
Four recent papers clarify what has to surround the model. Spec2RTL-Agent decomposes long specifications and lets multiple agents plan, implement, and inspect high-level synthesis code[2]. ScaleRTL trains on long reasoning trajectories and spends additional inference compute on self-reflection[3]. StepPRM-RTL assigns rewards to intermediate reasoning steps rather than judging only the final module[1]. ASPEN goes beyond functional generation and searches equivalent RTL datapaths with theorem checking and PPA feedback[4]. Read together, these projects describe a control loop, not an autocomplete system.
The real output is an evidence trail
An RTL module has several definitions of “correct.” It must parse and elaborate. A simulator must produce expected outputs for representative and adversarial sequences. Formal properties must hold for every reachable behavior within their scope. Synthesis must preserve function while meeting a technology-dependent objective. Integration must also respect clocks, resets, interfaces, and latency contracts that a unit test may never exercise.
A one-shot model sees most of this evidence only after it has committed to an implementation. The useful automation loop instead exposes the intermediate choices: how the specification was divided, which state variables were introduced, why a handshake advances, what assertion failed, and which rewrite changed area or delay. This makes a bad result diagnosable and gives the system a location from which to repair it.
This distinction matters for deployment. An engineer can review a state transition and an assertion more efficiently than an opaque claim that the complete module is likely correct. The trace also supports governance: a team can record which simulator, testbench, synthesis library, and model version produced each revision. Without those artifacts, a higher benchmark score does not create a reproducible design process.
Spec2RTL-Agent moves planning ahead of code
Complex specifications are not organized as executable modules. They mix requirements, exceptions, diagrams, timing rules, register descriptions, and prose written for different readers. Spec2RTL-Agent addresses that gap with cooperating agents that interpret the document, form an implementation plan, generate synthesizable C++, and inspect the result before high-level synthesis produces RTL[2]. The reported experiments cover three specification documents and reduce human interventions by as much as 75%.
The choice of C++ and HLS is important. It narrows the task from unrestricted RTL authoring to a representation whose control and dataflow can be lowered by an existing compiler. That can improve productivity for algorithmic blocks, but it also moves several decisions into the HLS tool: scheduling, resource sharing, pipelining, and interface realization. The agent is therefore automating a specification-to-implementation workflow, not proving that direct hand-written RTL is unnecessary.
The result also identifies where human work remains valuable. Interventions tend to appear when a requirement is ambiguous, a document omits an integration condition, or the generated design disagrees with the intended microarchitecture. Those are not merely model failures. They are points where the source specification lacks an executable contract. A production system should preserve these questions and their answers because the clarification may be more valuable than the initial code.
ScaleRTL spends compute on reasoning and correction
ScaleRTL takes a different route. Its contribution is a 3.5-billion-token corpus with reasoning traces that average roughly 56,000 tokens, combined with test-time self-reflection[3]. On the reported benchmarks, it improves VerilogEval by up to 18.4% and RTLLM by up to 12.7% over a set of 18 baselines. The result suggests that RTL generation benefits from longer internal work: interpreting constraints, constructing a candidate, checking it, and revising it.
The percentage should not be read as an 18.4% productivity gain for a chip team. VerilogEval and RTLLM contain bounded tasks with testbench-defined success. A production block adds undocumented interactions, CDC behavior, reset sequencing, low-power intent, verification coverage, and style rules. Test-time compute is useful only when it is attached to an evaluator that represents those conditions.
This leads to a practical architecture. The model should not be allowed to reflect indefinitely on its own prose. Each round should call a simulator, linter, elaborator, formal engine, or synthesis tool, then transform the structured result into the next repair task. Reasoning tokens are not evidence; tool observations are. The model earns additional compute when the next experiment can separate plausible causes.
StepPRM-RTL rewards the path, not only the answer
Most generation training gives a reward at the end: the module passes or it does not. That signal is sparse. A failed design may contain a correct interpretation, a sound state decomposition, and one wrong transition, but the final label cannot distinguish them. StepPRM-RTL trains a process reward model on stepwise trajectories and uses reward-aware fine-tuning and tree search to prefer better reasoning paths[1]. IBM reports more than a 10% improvement in functional correctness and reasoning fidelity over the best prior system in its comparison.
Process supervision is especially relevant to hardware because early structural decisions constrain every later repair. Choosing a counter when the specification requires a queued transaction model can make local patches useless. A reward model that recognizes a sound interface interpretation can keep that portion while exploring another state machine. In principle, this reduces destructive rewriting and makes the search tree correspond to engineering choices.
The difficult part is the reward source. If intermediate labels are generated from shallow tests, the model learns the testbench’s blind spots. If labels come from another language model, stylistic confidence can replace circuit correctness. A strong process reward should combine tool results with structured judgments: parse success, property coverage, counterexample locality, synthesis feasibility, and the consistency of each step with the explicit specification.
ASPEN makes equivalence the boundary for optimization
Functional generation is only the first half of RTL work. Two equivalent expressions can synthesize into very different circuits. ASPEN represents datapaths in an equality graph, uses an LLM to propose rewrite opportunities, checks transformations with a theorem prover, and closes the loop with PPA results from a commercial EDA flow[4]. Against previous e-graph approaches, it reports that area improves by 16.51% on average, while delay improves by 6.65%.
The theorem prover changes the risk profile. The model can suggest a non-obvious algebraic transformation without receiving authority to change behavior. Equivalence defines the permissible region, while synthesis feedback ranks candidates inside it. This division of labor is more credible than asking one model to optimize and certify its own output.
It also shows why “LLM for RTL” is too broad a category. Spec2RTL-Agent expands a document into an implementation. ScaleRTL and StepPRM-RTL improve functional reasoning. ASPEN searches a function-preserving optimization space. Their metrics measure different boundaries and cannot be combined into one score.
A production stack needs three independent loops
The first loop is functional. It converts requirements into properties and tests, runs candidates, localizes failures, and records the repair. Passing examples alone are insufficient; assertions must cover protocol invariants, illegal states, ordering, and reset behavior. Coverage should decide whether the system may stop.
The second loop is structural. It checks synthesizability, clock and reset conventions, CDC boundaries, lint rules, and integration constraints. A functionally correct module can still be unusable because it infers unintended storage, creates a combinational loop, or violates the project’s interface discipline. These rules should be machine-readable and versioned with the block.
The third loop is physical. Synthesis and early timing estimate the cost of the selected structure. For well-bounded transformations, equivalence checking can protect function while the optimizer explores PPA. For larger architectural changes, the system must return to the functional loop because latency and resource sharing may alter visible behavior.
Keeping the loops separate has an operational advantage. A team can assign different release criteria and tool budgets to each one. Cheap lint and simulation run on every candidate. Formal checks run when properties or state structure change. Full synthesis runs only for candidates that survive earlier gates. This makes agentic RTL generation an orchestration problem as much as a modeling problem.
Benchmarks need failure taxonomy, not one pass rate
A single pass rate hides whether a model fails on arithmetic width, temporal behavior, interfaces, or ambiguous requirements. These categories have different repair costs. A missing bit extension may be corrected locally; a wrong transaction model can invalidate the block. Reporting the failure distribution would show whether a higher score removes expensive errors or only easy syntax mistakes.
Evaluation should also separate familiar templates from novel compositions. Models can reproduce counters, FIFOs, and arbiters from abundant public examples. The harder test combines a new protocol rule, parameterized widths, backpressure, multiple clocks, and a precise recovery sequence. Leakage-resistant splits and specification mutation tests are necessary if benchmark progress is meant to predict engineering value.
Lastly, PPA comparisons require a common flow. Library, clock constraint, synthesis effort, and downstream physical assumptions can dominate the result. An RTL optimizer should report equivalence status and tool configuration beside area and delay. Otherwise the number cannot be reproduced or compared across projects.
The adoption decision
The near-term opportunity is not autonomous ownership of a large subsystem. It is accelerating bounded work with an explicit oracle: register blocks, protocol adapters, arithmetic datapaths, testbench expansion, assertion generation, and function-preserving rewrites. These tasks have interfaces that can be stated and feedback that can be returned quickly.
The deployment unit should include the specification slice, generated properties, tool versions, candidate history, counterexamples, and synthesis reports. An engineer approves the contract and the final trade-off, while the system searches and repairs inside that boundary. This arrangement converts model variability into logged alternatives rather than undocumented changes.
The four papers point to the same conclusion from different directions. Better RTL automation comes from giving the model more structured work and less unchecked authority. Planning makes requirements explicit. Test-time compute explores alternatives. Process rewards protect good intermediate decisions. Formal equivalence constrains optimization. The code is a product of that loop, but the loop is the system a chip team can trust.
Source and copyright notice
This article is an independent editorial analysis of the four cited papers and their official publication records. Technical claims and reported values were restated in our own words. No source sentence, table, benchmark layout, or figure is reproduced. Both explanatory figures were created specifically for this article. The cited conference papers are copyright their respective publishers and authors.