2026 年 7 月 28 日，腾讯、北京大学集成电路学院和西南交通大学的一支联合团队把一篇论文挂上 arXiv，题目是《GoGoTB: Agentic RTL Verification with Specification-Grounded Coverage Closure》。论文已被 IEEE/ACM ICCAD 2026 录用，会期定在 11 月的圣何塞。
它要解决的问题不算新。功能验证吃掉芯片前端的大部分工程量，一个漏到流片的 bug，可能换来一次昂贵的重流片。新鲜的是它给的答案：把这一整条链路交给一组智能体，人退到后面审结果。
八个 RTL 设计，零人工干预，环境生成成功率 100%，平均行覆盖率 98.4%、分支覆盖率 97.2%、翻转覆盖率 97.0%。其中五个设计的行覆盖率不低于 99%，全部设计的分支覆盖率都在 91% 以上。
整篇论文里真正值得停下来看的，是另外两个数字：83.2% 和 0%。
83.2% 是它的平均功能覆盖率。行覆盖率 98.4% 对上功能覆盖率 83.2%，中间那 16.8% 才是这篇论文真正想说的东西。0% 则是它在同一批设计上复现前作 UVM2 时，拿到的环境生成成功率。
一篇论文的口径，通常就藏在它选择跟谁比、以及怎么比里。要读懂 GoGoTB，得先弄清这三个数字各自是怎么来的。
先把这篇论文做的事说清楚
GoGoTB 的输入有三样：RTL 源码、自然语言写的规格说明，以及一个参考模型。输出是一整套验证环境和一份签核报告。流程分四段、八个阶段：规格分析、环境构建、随机仿真、覆盖率收敛。
撑起这套编排的是三个子系统。
第一个是执行控制层，设计原则一句话能说清：把确定性执行和大模型推理在架构上分开。工具调用之前有一道 Guard 校验（护栏校验），原始编译器和仿真器的输出会被转成结构化诊断再喂给模型，会话边界上还有一层产物校验。三层各管一类失败——工具调用、阶段边界、失败恢复。论文写得很直白：可靠性来自控制架构这一层，跟具体用了哪个模型关系不大。
第二个是可演化知识系统，管的是"什么时候把什么知识塞进上下文"。方法论知识按阶段确定性分发，设计特定的历史经验按相似性门控分发。这里有个值得记下的设计：相似度低到一定程度，参考条目直接不进上下文。论文的原话是，宁可让模型什么都拿不到，也不给它一份会把方向带偏的参考。
第三个是覆盖率怎么处理，全文的重点在这里。论文把规格拆成七个行为维度——数据边界、控制流、时序约束、FSM 状态转移、协议合规、错误注入、微架构交互——从这些维度往下推导测试点（testpoint），最后让每一个覆盖点（coverage bin）都挂到一条有名字的规格行为上。按论文的说法，这一步把覆盖率模型从"信号值划分"换成了"一组行为断言"。
100% 对 0%，这笔账不能只看表面
论文里最抓眼球的对比，是它自己在八个设计上拿到 100% 环境生成成功率，而 UVM2 是 0%。
先说 100% 到底是什么。论文定义的成功率（SRG）要同时满足三件事：零错误编译、无死锁仿真、覆盖率非零。三者缺一，这个设计就算失败。按这个判据，GoGoTB 在八个设计、七个骨干大模型上全部拿到 100%，构建时间从 5 分 30 秒到 48 分 10 秒。
UVM2 那一侧的 0%，论文也交代了原因：团队克隆了它的仓库，每个设计跑了四到六次。UVM2 靠单次调用生成每个组件，没有共享上下文，没有生成、调试、迭代的循环，编译失败和仿真死锁只会不断累积。论文把这归为架构性失败，跟某个具体模型的能力高低没关系。
这里有一处边界必须说清楚。UVM2 在自己 2025 年那篇 ICCAD 论文里，报的是平均 89.70% 的生成成功率、87.44% 的代码覆盖率、89.58% 的功能覆盖率。两套数字并不冲突，因为分母完全不是一回事：benchmark 不一样，UVM2 用自建套件、400 到 1600 行，GoGoTB 用八个设计、291 到 1424 行；成功判据不一样；功能覆盖率的定义也不一样。所以 0/8 的正确读法是"在 GoGoTB 的基准和判据下"，不能读成"UVM2 放哪儿都是 0"。
边界划清之后，这个对比仍然有分量。七个骨干模型跑出同一个 100%，说明循环能不能收敛，主要由编排层决定。翻译一下：在这批设计上，模型能力已经不是那个卡点。
真正难的是剩下那 16.8%
行、分支、翻转三项覆盖率都在 97% 以上，功能覆盖率停在 83.2%。论文自己解释了这个落差：让代码跑到某一行，比命中一个需要多个信号同时满足特定条件的覆盖点，要容易得多。
I2C 那个案例把过程完整摊开了。初始回归跑完，功能覆盖率 56.0%，分母是 132 个从规格派生的覆盖点。第一轮补测试之后升到 71.6%。多轮迭代，最终收敛在 84.1%，一共加了 28 个百分点。
然后论文做了一件很实在的事：把循环终止后剩下的 24 个覆盖点逐个归因。16 个属于激励缺口和序列缺口，5 个属于交叉空洞和状态未达，剩下 3 个是时序相关、状态转移和种子不足。
这个分布说明的事很关键。激励缺口和序列缺口的含义是，系统已经知道哪个覆盖点没打到、也知道需要什么样的激励，但智能体就是写不出能命中那个条件的测试。用论文的话说，覆盖率模型本身不是瓶颈。
一个设计的功能覆盖率上不去，原因常常在覆盖率模型本身——它一开始就没建成能反映设计意图的样子，仿真跑再久也补不回来。
覆盖率质量在建模时就定下了，等到测量再想补救已经晚了。
覆盖率是建出来的
把 GoGoTB 和它批评的做法摆在一起，差别正好差一级。
传统做法从 RTL 信号出发建覆盖模型。哪个信号取了什么值、几条信号之间出现过哪些组合，这些都能自动从代码里抽出来。代价是，端口列表相同的两个设计会得到同一个覆盖率模型，哪怕它们实际要干的事差得很远。
GoGoTB 反着来：先读规格，把规格里的行为一条条列出来、命名，再让每个覆盖点挂到某一条上。论文举的例子是 key shape（密钥形态）、NIST anchor hit（标准锚点命中）、plaintext change（明文变化）这类有名字的行为；UVM2 的覆盖点则是原始信号上的数值区间。
两种模型都能报出一个百分比，但它们回答的问题不一样。前者回答"代码被跑到了多少"，后者回答"规格里写的行为被验证了多少"。只有后者能撑起一件事：拿一份签核报告，说清每个已覆盖的点有什么证据，每个没覆盖的缺口是什么原因。
论文说它的签核报告会给每个已覆盖的覆盖点记录证据，给每个残余缺口记录根因处置，没有任何缺口被静默丢弃。这句话看着平淡，指向的却是验证工作的验收本质。
覆盖率数字再高，只要没人能说清剩下那些没覆盖的到底是什么，这份报告就签不下去。
按这个标准，覆盖能力能排成三级台阶。第一级，把信号值划成区间，报一个百分比；第二级，给每个覆盖点绑上一条有名字的规格行为；第三级，让每一个缺口都落到一张根因表上，并且给出对应的补救动作。GoGoTB 站上的是第三级。
三个缺口，谁是瓶颈
论文还留了一个很有价值的消融实验，值得单独说。
在 UART 这个设计上，团队把知识系统关掉，其他子系统照常工作。结果环境能编译、能仿真、不报任何错，功能覆盖率却所有覆盖点都是 0%。论文列出三个静默失败：激励没有按 UART 协议成帧，DUT 压根没见过一个合法帧；观察者异步采样，没对齐到 START_BIT 边界，采到的数据全是比特偏移的；一份参考模型同时给发送和接收两条路径用，DUT 响应正确，期望值却是错的。
接着他们补了三条领域约定：协议成帧规则、观察者对齐到 0.5 倍波特率周期处的中间采样点、发送和接收分别建模。功能覆盖率从 0% 升到 75.3%。
这个实验里唯一的变量就是知识系统。所以论文的结论是，那次失败来自知识缺口，跟模型能力无关。
把第一个研究问题（RQ1）和这个消融放在一起，更完整的图就出来了。智能体验证做不好，原因至少压着三层：编排层没把循环管住，知识层没把隐含约定写下来，能力层确实还写不出复杂多步协议的定向激励。三层的解法完全不同，混在一起谈，工程问题就会被误判成模型问题。
对做落地的人来说，第二层尤其值得警惕。testbench 里那些"大家都懂"的约定——采样点在哪、参考模型怎么隔离、帧怎么成、错误怎么回——平时只写在工程师脑子里，不在任何文档里。模型拿不到它们，就只剩猜。猜错的时候环境照样编译、照样仿真、照样吐出一份漂亮的覆盖报告，只是覆盖率为零。也正因为这样，真正可落地的 AI+EDA，通常要把知识怎么沉淀、流程怎么编排、权限边界怎么划这几件事一并解决，这些往往比模型选型更早。
这套方法还没解决的边界
论文交代的边界，有几条得逐条记下。
最直接的一条：所有实验都提供了一个参考模型作为输入。也就是说，它验证的是"参考模型在手"的场景，跟工业界常见的那种没有可信 golden reference、要边验边建期望值的场景，不是一回事。
规模也有限。八个设计的 RTL 在 291 到 1424 行、1 到 9 个模块之间，属于模块级验证，够不着 SoC 级。仿真栈用的是 Verilator 5.024 加 cocotb 2.0.1，不是商用 UVM 仿真器——论文也解释了这个选择，跟模型写 SystemVerilog 的首次通过率偏低有关。
功能覆盖率那一侧本来就还差一口气。论文把主要局限写成"复杂多步协议场景的定向测试生成"，并把集成形式化方法列进未来方向。换句话说，结构上难以到达的状态，这套流程眼下也解决不了。
还有一条容易被忽略：框架和评测基准目前都还没开源。论文写的是"稍后开源"，没有时间表。今天看到的这些数字，暂时还轮不到第三方独立复现。
结语
这篇论文真正的分量，不在 100% 这个数字上，而在它示范了一件更朴素的事：把覆盖率从一个跑出来的数字，变成一个建出来的结构。
对我们做 AI+EDA 落地的人来说，它留下的判断习惯比结论更管用。以后再看任何"AI 自动完成验证、覆盖率达到多少"的说法，不妨先问三句：这个覆盖率的分母是什么，信号区间还是规格行为？这个数字是在谁家的 benchmark、什么判据下测出来的？剩下没覆盖的那部分，有没有落到根因上，还是一条被拉平的漂亮曲线？
这三个问题，比任何一个百分比都更能说明一项工作走到了哪一步。
作者：麒芯
免责声明：本文基于公开论文、开源项目公开资料与行业研究整理，文中性能数据均为论文口径，不代表同类方法的普遍效果，不构成任何投资建议。
参考资料：
1. arXiv：《GoGoTB: Agentic RTL Verification with Specification-Grounded Coverage Closure》，arXiv:2607.26181v1，2026-07-28
2. arXiv：《From Concept to Practice: an Automated LLM-aided UVM Machine for RTL Verification》，arXiv:2504.19959，ICCAD 2025
3. IEEE/ACM ICCAD 2026 会议官网：会期与征稿信息
4. Verilator 官方开源项目：《开源 Verilog/SystemVerilog 仿真器》
5. cocotb 官方开源项目：《基于 Python 的协同仿真验证框架》
热门跟贴