研究论文
GoGoTB：用 LLM 智能体实现端到端 RTL 验证闭合
arXiv 新论文提出 GoGoTB 框架，以智能体方式完成芯片前端功能验证，在 8 个 RTL 设计上无需人工干预取得…
2026.07.30 · 周四约 3 分钟阅读
芯片前端设计中，功能验证往往耗费最多工程资源；一个漏检 bug 一旦流片失败，就要付出昂贵的重制代价。arXiv 上新发表的论文《GoGoTB: Agentic RTL Verification with Specification-Grounded Coverage Closure》提出了一种基于大语言模型智能体的端到端验证框架，声称在多个 RTL 设计上做到几乎无需人工干预的覆盖率闭合。
现有方法的痛点
作者指出，此前基于 LLM 的验证方案通常以独立、单轮的方式生成各个验证组件，组件之间缺乏共享上下文，因此接口不匹配难以被发现；同时，报出的覆盖率数字也与规范要求脱节，无法定位剩余缺口的根因。这些问题限制了 LLM 在工程级验证任务上的可用性。
GoGoTB 的三大子系统
GoGoTB 的设计围绕三个子系统展开：
- 智能体执行控制层：在每个工具调用和阶段边界上，把"确定性强制执行"与"LLM 推理"显式分离，避免模型在关键控制点产生不确定性。
- 可演进的知识系统：按需调度方法论层面的通用经验与设计层面的特定知识，使智能体在不同项目间复用经验。
- 规范锚定的覆盖闭合框架：每一个覆盖率 bin 都绑定到一条具名规范行为，剩余缺口因此具备可诊断的根因与针对性的修复路径。
评测结果
论文在 8 个 RTL 设计上进行了零人工干预测试，报告的结果如下：
- 环境生成成功率：100%
- 行覆盖率（line coverage）：平均 98.4%
- 分支覆盖率（branch coverage）：平均 97.2%
- 翻转覆盖率（toggle coverage）：平均 97.0%
- 功能覆盖率（functional coverage）：平均 83.2%
作者同时表示，在同一组基准上，"此前的工作"既无法生成完整的验证环境，也未取得有意义的覆盖率数字，因此 GoGoTB 在对比意义上具有明显优势。
局限与待观察点
需要注意的是，该结论建立在作者自选基准与自建对比之上，评测规模（8 个设计）相对有限，且尚未公开复现包或第三方独立验证；功能覆盖率 83.2% 与结构化覆盖率的差距，也提示在更高层规范项上仍有提升空间。对于希望将该框架引入实际芯片项目的团队，可重点关注其知识系统的可移植性与控制层在多智能体协作下的稳定性。