Research Explainer · XiaoHu Explains

NVIDIA Research releases HORIZON, an unsupervised agent that pushes every RTL chip-design benchmark to a 100% pass rate

The paper is the first to run an agent completely unsupervised through an entire RTL benchmark suite; most problems clear in two or three rounds, but the hardest one takes 82 iterations
Quick Take
  • NVIDIA Research proposes HORIZON, which treats hardware design as repository-level code evolution: the user writes a single Markdown spec, the system compiles it into a "project pack," and an unsupervised agent loop repeatedly edits code and runs simulations inside an isolated Git workspace, committing only once verification passes.
  • Across ChipBench, RTLLM-2.0, Verilog-Eval, and 9 CVDP verification categories, HORIZON drives every benchmark to a 100% pass rate using the same unsupervised loop.
  • The agent's aggregate pass rate at the first iteration is only 47.8%, and the hardest category — CVDP checker generation — starts at just 3.8% on the first pass; the same loop eventually grinds every category to 100%, but some problems clear in 1–2 rounds while others need up to 82 rounds.
  • Once correctness saturates, token cost becomes the real differentiating signal — the 9 CVDP categories consume 97.1% of all tokens (about 203.9M), roughly 91% of which is reusable cached input.
  • The authors explicitly do not claim that "agentic hardware design is solved," and they flag a risk of "over-fitting to the reward / reward hacking" in the current feedback setup, recommending that future benchmarks separate debugging feedback from final hidden scoring.
01What this NVIDIA paper actually says

What this NVIDIA paper actually says

NVIDIA Research recently published a paper proposing HORIZON, an agentic hardware-design framework that treats chip design as repository-level code evolution.

Give the system a Markdown spec, and a fully unsupervised agent repeatedly edits code and runs simulations inside an isolated Git workspace, committing only once verification passes — ultimately pushing the entire RTL (register-transfer level — the layer of code describing exactly how every clock tick moves inside a chip) benchmark suite to a 100% pass rate.

⚑
Why it matters: As far as the authors know, this is the first end-to-end agentic system that completes an entire evaluated RTL benchmark suite without human intervention — covering ChipBench, RTLLM-2.0, Verilog-Eval, and 9 CVDP categories — all at a 100% pass rate.
HORIZON architecture overview: Markdown spec → project_pack control plane → unsupervised agent loop, evolving on a Git workspace
Figure 1 from the paper — architecture overview. The user's Markdown spec is compiled into a project_pack control plane, which drives an unsupervised agent loop continuously evolving on a Git workspace. Source: NVIDIA Research／marktechpost
02First, understand why writing Verilog once is nowhere near enough

Why one-shot Verilog from an AI falls far short

Verilog is the hardware code used to describe chip logic. RTL design is a sharp touchstone: whether a module is correct depends on the exact behavior at every clock tick, the reset convention, how the interfaces handshake, the bit-width of every signal, and the feedback from an actual simulator run. So "Verilog that looks plausible" is nowhere near enough.

A model has to infer the datapath bit widths on its own, how the state machine transitions, the reset convention, the ready-valid handshake protocol, how memory is read and written, and all the edge cases that natural language often leaves unstated. Put simply, a syntactically correct module is just the starting point. Useful automation has to connect "writing it" all the way through to "compile, simulate, inspect waveforms and failure traces, then fix" — running the loop, finding what's wrong, going back to fix it, and running again.

Write module
→
Compile
→
Simulate
→
Inspect waveform／failure trace
→
Fix
↺

HORIZON's core idea is to lock this entire chain inside a loop that runs itself.

03Core design one: how a spec becomes a self-running project pack

How a spec becomes a self-running project pack

The only input the user has to provide is a structured Markdown spec — not code. It states the high-level intent, repository context, expected artifacts, evaluation criteria, and domain knowledge. Domain knowledge is especially useful, since it can make explicit the invariants, tooling conventions, and failure modes that simply can't be inferred from the files alone.

A "bootstrap agent" compiles this spec into a "project pack" — the control plane for the entire system. The spec has four components, which get compiled into a five-element runtime configuration that drives the unsupervised loop.

① Markdown spec
  • Goal / task
  • Domain-knowledge directions
  • Evaluator specification
  • Acceptance predicate
→
② Project pack (five elements)
  • π_agent policy prompt and tool contract
  • E_p executable evaluator (compile／simulate／coverage)
  • A_p acceptance predicate (can it be committed?)
  • Γ_p version-control and artifact policy
  • Ω_p domain skills and repo operating instructions
→
③ Unsupervised loop
  • Read state
  • Edit workspace
  • Invoke evaluation tools
  • Fix or commit
An analogy · project pack

A project pack is like a complete onboarding packet for a new hire: it doesn't just say what to do, it also comes with the grading rubric, the tool instructions, and the handover process. The new hire reads it once and can work independently, with nobody standing over their shoulder.

Hero · not tied to RTL

Crucially, the problem is defined on a generic Git workspace, not on some fixed type of chip repository. So this way of organizing work isn't exclusive to RTL or EDA: as long as a task has "a persistent Git workspace + machine-checkable feedback + versioned artifacts," it can be organized the same way. Swap domains, and the evaluator slot can become unit tests, a theorem prover, a performance profiler, a security scanner, a synthesis tool, or even a human-review gate.