功能验证占据了集成电路前端工程的主要工作量——一个漏到流片阶段的bug，就可能导致数百万美元的重新设计成本。腾讯、北京大学和西南交通大学联合提出了GoGoTB，一个智能体式RTL验证框架，在8个RTL设计上无需任何人工干预，实现了100%的环境生成成功率和平均98.4%的行覆盖率。此前没有工作能在相同基准上完成完整的验证环境生成。
在芯片设计流程里，验证工程师往往要花数周时间手写测试平台、约束随机激励和覆盖率模型，才能让一个模块进入可交付状态。GoGoTB把这条路径整体交给了智能体，人的角色从"编写验证环境"转向"审阅验证结果"。
从独立单轮到智能体协作
现有基于LLM的验证方法是将每个组件通过独立的单轮调用生成，缺乏共享上下文。这意味着验证环境可能根本无法编译，接口不匹配问题无法被检测，报告的覆盖率也与规范要求脱节。GoGoTB通过三个子系统解决了这个问题。
首先是智能体执行控制层。它在每个工具和阶段边界将确定性执行与LLM推理分离——LLM负责决策，确定性代码负责执行，避免LLM在工具调用中犯错导致整个流程中断。第二是可演化知识系统，按需调度方法论和设计特定的专业知识，而不是每次从头推理。第三是规范驱动的覆盖闭合框架，将每个覆盖点绑定到具体规范行为，使每个剩余缺口都有可诊断的根本原因和可针对的补救措施。
图：GoGoTB自动生成、执行并修正RTL测试台的整体流程。
8个RTL设计，零人工干预
GoGoTB在8个寄存器传输级（RTL）设计上进行了测试，覆盖了从简单模块到较复杂的设计。结果如下：
- 环境生成成功率：100% - 平均行覆盖率：98.4% - 平均分支覆盖率：97.2% - 平均翻转覆盖率：97.0% - 平均功能覆盖率：83.2%
这些数字是在没有人工介入的情况下取得的。论文指出，此前没有任何工作能在相同基准上成功生成完整的验证环境或达到有意义的覆盖率。
值得注意的是几个指标之间的落差。行覆盖率、分支覆盖率和翻转覆盖率都在97%以上，说明GoGoTB生成的激励已经能把代码路径跑得相当彻底；而功能覆盖率停在83.2%，意味着有一部分规范定义的功能场景没有被触发到。这个差距恰好对应验证工作中最难自动化的部分——理解设计意图，而不只是把代码跑遍。
图：GoGoTB的分层验证环境与质量门禁。
知识系统：把经验存下来复用
GoGoTB的可演化知识系统是一个关键设计。它包含两个层次：方法论知识（通用的验证策略和最佳实践）和设计特定知识（当前设计的接口、协议和约束）。在验证过程中，LLM可以按需查询这些知识，而不是每次都从零推理。
更关键的是，知识系统是可演化的。当验证过程中发现新的问题模式或解决方案时，系统可以更新知识库，使后续设计能从中受益。这种设计模仿了人类验证工程师的经验积累过程。
这一点在多个设计连续验证的场景下尤其重要。第一个设计上踩过的坑——比如某类总线协议的握手时序容易被忽略——会被固化进方法论层，后面的设计不必重新试错。相比每次都靠单轮提示重新推理，这种积累让智能体的行为随时间趋于稳定。
图：技能库、参考库与智能体验证流程的关系。
覆盖率不再是黑盒
GoGoTB的覆盖框架将每个覆盖点绑定到具体的规范行为。传统的覆盖率报告只告诉你"哪行代码没跑到"，而GoGoTB能告诉你"哪个规范行为没有被验证到"。每个覆盖率缺口都有明确的根因分析和针对性的修复建议。这使得验证闭环能够自动推进，直到所有规范行为都被覆盖。
覆盖率结果也暴露出当前方法的局限性。功能覆盖率83.2%明显低于其他指标，说明复杂功能场景的验证仍然是自动化最难的部分。
图：GoGoTB与多种基线在不同RTL任务上的结果对比。
从学术验证到工业落地
GoGoTB在8个RTL设计上验证了可行性，但论文也客观指出，这些设计的规模尚未达到工业级芯片的复杂度。在真实大规模芯片设计中，验证环境更加复杂，涉及更多的IP集成、协议交互和时序约束。GoGoTB能否扩展到工业级场景，还需要在更大规模的设计上进行验证。
不过，对于中等规模的RTL模块验证，GoGoTB已经展示出自动化可行性。如果这一方向持续推进，芯片验证的人力投入有望大幅降低。
