研究解读 · 小互解读

NVIDIA Research 发布 HORIZON,无人值守智能体把全套 RTL 芯片设计基准刷到 100% 通过

论文首次让智能体全程无人值守跑完全部 RTL 基准;多数题两三轮过关,最难一题却要迭代 82 轮
速览
  • NVIDIA Research 提出 HORIZON,把硬件设计当成仓库级代码演化来管理:用户只写一份 Markdown 说明书,系统自动编译成「项目包」,一个无人值守的智能体循环在隔离的 Git 工作区里反复改代码、跑仿真,验收通过才提交。
  • 在 ChipBench、RTLLM-2.0、Verilog-Eval 和 9 个 CVDP 验证类别上,HORIZON 用同一套无人值守循环把全部基准刷到 100% 通过率。
  • 智能体第一轮迭代的聚合通过率只有 47.8%,最难的 CVDP 检查器生成类别首轮仅 3.8%;同一套循环最终把所有类别磨到 100%,但有的题 1 至 2 轮就过关,有的题要迭代 82 轮。
  • 正确性饱和之后,token 成本成了真正的差异化信号:9 个 CVDP 类别用掉全部 token 的 97.1%(约 203.9M),其中约 91% 是可复用的缓存输入。
  • 作者明确不宣称「智能体硬件设计已解决」,并指出当前反馈机制存在「过度求解/奖励攻击」风险,建议未来基准把调试反馈和最终隐藏评分分开。
01NVIDIA 这篇论文说了什么

NVIDIA 这篇论文说了什么

NVIDIA Research 团队最近发布论文,提出智能体硬件设计框架 HORIZON,把芯片设计当成仓库级代码演化来管理。

给系统一份 Markdown 说明书,一个全程没人盯着的智能体就在隔离的 Git 工作区里反复改代码、跑仿真,验收通过才提交,最后把整套 RTL(寄存器传输级硬件设计,也就是用代码描述芯片里每一拍怎么动的那一层)基准全部刷到 100% 通过。

为什么值得看:据作者所知,这是第一个端到端、不需要人工干预就完成全部被评测 RTL 基准套件的智能体系统,覆盖 ChipBench、RTLLM-2.0、Verilog-Eval 和 9 个 CVDP 类别,全部拿到 100% 通过率。
HORIZON 架构总览:Markdown 说明书 → project_pack 控制面 → 无人值守智能体循环,在 Git 工作区上演化
论文 Figure 1 架构总览:用户写的 Markdown 说明书被编译成 project_pack 控制面,驱动一个无人值守的智能体循环在 Git 工作区上不断演化。来源:NVIDIA Research/marktechpost
02先搞懂:写一次 Verilog 为什么远远不够

为什么让 AI 写一次 Verilog 远远不够

Verilog 是描述芯片逻辑的硬件代码。RTL 设计是一块尖锐的试金石:一个模块对不对,取决于时钟每一拍的行为、复位怎么约定、接口怎么握手、每根信号多少位宽,还要看仿真器跑出来的反馈。所以「看起来像模像样的 Verilog」远远不够。

模型必须自己推断数据通路的位宽、状态机怎么转移、复位约定、ready-valid 握手协议、存储器怎么读写,还有那些自然语言里常常没说清的边角情况。说白了,一个语法正确的模块只是起点。真正有用的自动化,得把「写出来」接到「编译、仿真、查波形和失败轨迹、再修复」这一整条链上,跑一圈发现不对就回去改,改完再跑。

写出模块
编译
仿真
查波形/失败轨迹
修复

HORIZON 的核心想法,就是把整条链关进一个能自己转起来的循环里。

03核心设计一:一份说明书怎么变成能自己跑的项目包

一份说明书怎么变成能自己跑的项目包

用户唯一要提供的输入,是一份结构化的 Markdown 说明书,不是代码。它写清高层意图、仓库上下文、期望产物、评测标准和领域知识。领域知识尤其有用,因为它能把那些「光看文件推不出来」的不变量、工具约定和失败模式显式写出来。

一个「引导智能体」把这份说明书编译成「项目包(project pack)」,也就是整个系统的控制面。说明书有四个组件,被编译成一个五元组的运行时配置,再驱动那个无人值守的循环。

① Markdown 说明书
  • 目标/任务
  • 领域知识指引
  • 评测器规格
  • 验收判据
② 项目包(五元组)
  • π_agent 策略提示词与工具契约
  • E_p 可执行评测器(编译/仿真/覆盖率)
  • A_p 验收判据(能不能提交)
  • Γ_p 版本控制与产物策略
  • Ω_p 领域技能与仓库操作说明
③ 无人值守循环
  • 读状态
  • 编辑工作区
  • 调工具评测
  • 修复或提交
打个比方 · 项目包

项目包像给新员工的一份完整入职资料包:不光写清要做什么,还附上考核标准、工具使用说明和交接流程。员工看完这一份,就能独立开工,不用有人在旁边盯着讲。

Hero · 不绑定 RTL

关键在于,问题被定义在一个通用的 Git 工作区上,而不是某种固定的芯片仓库类型。所以这套组织方式并不专属 RTL 或 EDA:只要一个任务具备「持久的 Git 工作区 + 机器可检查的反馈 + 带版本的产物」这三个条件,就能用同一套方式来组织。换个领域,评测器那个槽位可以换成单元测试、定理证明器、性能剖析器、安全扫描器、综合工具,甚至人工评审门。

点开看一份真实说明书长什么样(论文附录 fifo_sync 骨架)

用户就写这么一份普通 Markdown,四个组件一目了然,剩下的全交给循环。

论文附录:fifo_sync 说明书骨架
# HORIZON Harness: fifo_sync

## Goal / objective
Implement a synchronous FIFO. Depth 16, 8-bit data.

## Domain-knowledge directions
- Reset is synchronous, active-high.
- full and empty must never assert together.
- Follow ready-valid handshake conventions.

## Evaluator specification
- Compile with the suite's native flow.
- Run the provided simulation testbench.
- Extract functional coverage where available.

## Acceptance predicate
- Simulation passes with zero mismatches.