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

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

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

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

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

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

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

# 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.

循环怎么跑：Git 仓库既是操作台，也是经验库

用户把初始说明书交出去之后，循环就完全无人值守了：引导、生成、评测、验收、记录、下一轮迭代，全部自动跑。一个「战役」可以连着跑很多轮，中间不再需要人插手。每一轮，智能体读当前状态、规划一个目标、编辑工作区、调用工具、读懂失败，然后要么修复要么提交。验收判据只决定一件事：把新版本提交（commit），还是把这次失败记进日志（log）。

Git 在这里是循环的基底，不是顺手记个账。四个普通的 git 操作，分别扮演四个角色：

git diff --cached                        # 检查暂存的候选改动
git commit -m "iter 7: fix full/empty overlap"
git notes add -m "pass=1 mismatches=0"   # 附上评测证据
git log --oneline                        # 回放搜索轨迹

进化的是代码，模型全程没动

「自我演化」这个词容易让人以为 HORIZON 在偷偷训练模型。不是。演化的是 Git 仓库里的设计产物，不是模型权重。骨干模型 GPT-5.3 在整个战役里权重固定不变，既不训练也不更新任何强化学习策略。

论文确实借用了「半马尔可夫决策过程（semi-MDP）」这个词，但说穿了，它只是给记录下来的对象起个精确、可回放的名字：「状态」就是仓库的一个带版本快照（一个记账用的检查点），「选项」就是两个检查点之间的一整段情节。它不是行为假设，也不是优化假设。

成本靠会话复用压下来：HORIZON 跨迭代保持一个持久的模型会话，让说明书、项目包、稳定的源文件、累积的调试上下文都从服务商的提示词缓存里取，而不是每轮重发一遍。于是真正新计费的 token，主要就是当前的 diff、最新的评测输出和智能体的回复。这也是为什么后面会看到，累计 token 里绝大部分是缓存输入。

HORIZON 站在谁的肩膀上

HORIZON 延续了一条「仓库尺度自我演化」的血脉。这条谱系的共同原则只有一条：一个候选改动，只有当可执行的证据支持它时，才被接纳。区别在于「演化的对象」，前面几个演化的是工程师「运行」的软件，HORIZON 演化的是工程师「创造」的硬件产物。

全套基准 100% 通过，但走到终点的路天差地别

作为一个单一的无人值守智能体循环跑，HORIZON 把每一个基准套件都刷到 100% 通过率。唯一残留的没过项，是 ChipBench 里的一道题，作者把它追溯到原基准里一个「规格与说明书」不匹配的缺陷，而不是智能体的失败，算作已解决就是 100%。所以各套件之间变化的，不是终点，而是到达终点的路。

这里的 iter 0 不是独立的单次生成成功率。它反映的是智能体演化第一步之后仓库的状态，而且全程用一样的提示策略。智能体完全可以故意把大量探索、调试、修复推迟到后面的迭代，而不是去最大化第一次就成功。这个聚合值还被 Verilog-Eval-v2 抬高了（它 iter 0 就有 86.2%），单看 CVDP 子集，iter 0 只有 23.9%。

顺带一提，这 9 个 CVDP 验证类别（测试台生成、检查器生成、断言生成）此前正是 AI 最吃力的任务。CVDP 论文自己就指出，最先进的单次模型在这类验证任务上尤其吃力，如今同一套循环能把它们收敛到 100%。

点选一个基准，看它从首轮爬到 100% 的收敛曲线：

把所有 12 个类别的首轮通过率并排看，落差一目了然：从 Verilog-Eval 的 86.2% 一直到 CID 007 的 0.0%。而它们最后统统收敛到了 100%。

条形＝首轮（iter 0）通过率；每一类最终都收敛到 100%。

正确性打平之后，token 才是真正的较量

一旦正确性饱和，token 消耗就成了更有信息量的信号，它暴露谁难谁容易。作者按「到达最优迭代为止的累计 token」来衡量。三个传统套件加起来只用 6.0M，9 个 CVDP 类别却用了 203.9M，占总量的 97.1%。全部跑完约 209.9M。

把 209.9M 按类别铺开，代码补全（CID 002）、规格转 RTL（CID 003）、激励生成（CID 012）三类就占掉了大半，传统基准挤在最左边细细一条：

耐人寻味的是 CID 013：它首轮通过率全场最低（3.8%），却只用 14.2M token 就收敛，印证了那条平稳无平台期的轨迹。真正拖高成本的，是 CID 002 那种「少数几个顽固设计的长尾」。

还有关键一句：约 91% 的 token 是缓存输入，这大幅降低了 API 成本。所以作者明确表态，他们把「token 效率」而不是「最终通过率」，看成最需要改进的指标。虽然 HORIZON 清掉了每一个套件，但最难类别上最后那几个百分点，吸掉了不成比例的预算。

覆盖率是顺便量出来的；作者自己划的红线

验证生成类别值得细看，因为它暴露了 HORIZON 在优化什么、不在优化什么。HORIZON 的验收门是 CVDP 的「通过条件」，不是「覆盖率目标」。循环被驱动着让基准的说明书通过，一旦某个设计通过，门就满足了，循环就停止再优化它。所以覆盖率在这里是一个次要的、观测性的信号。

最直接的证据：CID 012 在第 32 轮达到 100% 通过率，但那时它的平均逐设计覆盖率只有 97.9%，不是 100%。这个缺口是验收门的直接后果，每个设计一旦让说明书通过就停手，覆盖率只反映「足够通过的测试」，而非「能达到的最大值」。

逐设计看，循环是把一条「低覆盖率尾巴」抬起来，好几个从 20% 至 40% 覆盖率起步的设计被拉向满覆盖，而不是只轻推那些本就很高的。CID 014 是反面，一开始就在 98% 附近，立刻饱和。作者强调，他们没有试图把覆盖率逼到 100%，这里的覆盖率是一个「生成的测试确有实质内容」的诊断，不是「穷尽验证」的声明。

论文第 5 节是最诚实的部分，作者主动划了两条红线。

红线一：过度求解／奖励攻击

当前设置里，智能体能看到每轮评测的详细输出（仿真器消息、评测日志、失败轨迹）。这像真实的调试工作流，工程师本就会查日志和反例。但完全访问这些信号也带来一种失败模式：智能体可能把生成的 RTL 定制得刚好匹配观察到的失败、确定性的测试、或评测器的怪癖，而不是稳健地实现设计的本意。于是一个「通过」的结果，可能意味着「在暴露的轨迹下满足了可见的说明书」，而不是「在所有合理测试下满足了规格」。

作者据此建议未来的智能体硬件设计基准采用两级协议：修复期间暴露有用的诊断反馈，但把隐藏的随机测试、独立参考模型、形式等价性检查、性质套件或留出的仿真器配置，保留给最终评分。这与软件工程基准 SWE-bench 的「结构性测试保留」思路一致。

红线二：反馈周转时间

本文的 RTL 通过／失败基准相对友好，因为大多数评测跑得够快，能支撑迭代修复。但在更广的芯片设计里，奖励评测可能慢得多，PPA（性能／功耗／面积）优化、EDA 工具演化的奖励可能需要综合、布局、布线、时序分析、功耗估计或大型回归套件。作者提到 SATLUTION 已经展示过代价：即便约 800 个节点并行，评测整个 SAT 竞赛基准也要约两小时周转；而 RTL 的 PPA 优化，周转可能长到几天甚至几周。长延迟奖励从根本上改变了问题，朴素的「编辑、评测、修复」循环会变得太慢，智能体必须在延迟、稀疏、昂贵的反馈下推理。解决「长周转奖励」因此是智能体芯片设计的一个关键研究挑战。

HORIZON 的答案：用户只写一份 Markdown 说明书（目标、领域知识、怎么算过关），系统自动把它编译成一个「项目包」，再交给一个无人值守（全程没人管）的循环，反复改代码、跑仿真，验收通过才提交。在四套公开芯片设计考卷、共 12 个类别上，这一套循环把每一项都刷到了 100% 通过。

但同一套循环，有的题两三版就过，有的题要磨很久，差别到底在哪？先看它怎么转。

秘诀不在更聪明的模型，而在把 Git 代码仓库（程序员存代码、留每一步历史的工具）当成大脑。每改一版就跑一次仿真：通过，就 git commit 存成一个绿色检查点，主线往前走；没过，就 git log 记下来当反面教材。仓库这条历史，本身就成了 AI 的经验库。

全套 12 项考卷全部 100%，此前从没有无人值守 AI 做到过。但「100%」背后，题和题的难度天差地别，最能体感的标尺是「改了多少版才通过」。

以上数字全部出自 NVIDIA 自己的论文测试，暂无第三方独立复现；作者还提醒，AI 能看到每轮评测的细节，有可能在「应付考卷」而不是真把芯片做对。