GoGoTB：把芯片验证覆盖率锚定到规格书，零人工介入实现100%建构率
GoGoTB: Agentic RTL Verification with Specification-Grounded Coverage Closure
在数字芯片的前端设计流程中，功能验证（Functional Verification）向来是最消耗工程资源的重灾区，通常占去整个研发周期超过一半的人力和时间。硬件开发有着极其严苛的物理铁律：一行软件代码写错，发布热修复补丁即可化解；但一块 RTL（寄存器传输级）芯片如果漏掉致命缺陷并一路流片（Tape-out），单次芯片重开模（Respin）的直接经济损失动辄数百万美元，更会彻底错失产品的市场窗口期。为了筑牢防线，业界构建起了极其繁琐的 UVM（通用验证方法学）体系。
ArXiv URL：https://arxiv.org/abs/2607.26181v1
近两年，大语言模型（LLM）被广泛尝试引入 EDA 领域以实现验证环境与测试用例（Testbench）的自动化搭建。然而，现有的自动化探索普遍停留在浅层。大部分方案依赖单轮独立提示词，逐个生成断言、激励驱动器或监视器，各个组件之间缺乏共享上下文与统一约束，往往在编译阶段就因接口信号不匹配而频发报错；即便侥幸跑通仿真，其所报告的覆盖率通常也仅仅是针对代码行或随机信号区间的浅层统计，根本无法说明芯片是否真正符合自然语言规格书（Specification）的设计意图。
针对这一系统性痛点，来自北京集成电路高精尖创新中心、北京大学、西南交通大学与腾讯的研究团队提出了 GoGoTB。这是一个面向数字芯片 RTL 功能验证的自主智能体（Agentic）框架。它跳出了以往仅依靠 LLM “黑盒盲写”代码的思路，首创了基于规格对齐的覆盖率收敛机制，并将确定性执行控制与动态领域知识注入深度融合。在 8 个基准 RTL 设计以及跨越 7 款主流大模型底座的严格评测中，GoGoTB 在零人工干预的前提下取得了 100% 的验证环境构建成功率，并实现了平均 98.4% 的行覆盖率与 83.2% 的规格级功能覆盖率，首次将全自动 RTL 验证推进到真正具备工程可用性的闭环阶段。
从代码覆盖到行为覆盖：芯片验证的层级断代
要理解 GoGoTB 的突破，必须先厘清芯片验证领域的“覆盖率陷阱”。长期以来，学术界与自动化工具衡量验证完备度时，习惯退守到最容易统计的维度，但这在工程实践中往往带来虚假的安全感。论文将验证覆盖率清晰地划分为四个由浅入深的层级：
第一层是代码覆盖率（L1），包括代码行（Line）、分支（Branch）和信号翻转（Toggle）。代码覆盖率仅反映 RTL 源码是否被仿真激励遍历过，却无法判断逻辑行为是否正确。一行完全跑偏的代码，只要被激励触发过，代码覆盖率就能达到 100%。第二层是基于信号区间的伪功能覆盖率（L2），这是此前 UVM2 等自动化框架所达到的上限。它通过对事务级信号的取值范围进行切片划分仓位（Bins），但本质上依然是对信号物理宽度的机械遍历，完全脱离了电路的功能语义。两个功能截然不同但输入位宽一致的模块，在 L2 级别生成的覆盖率模型毫无二致。
真正决定芯片生死的，是更高层级的验证目标。第三层是基于规格书的显式行为覆盖率（L3），它要求将每一个覆盖仓位精确锚定到规格书定义的具体功能操作、时序交互与异常处理场景；第四层则是跨维度的组合行为与Corner-case覆盖率（L4），涵盖跨协议周期的状态机跳转、异常嵌套恢复与多主设备并发仲裁。
以往 LLM 方案之所以止步于 L1 和 L2，根源在于其结构性缺陷：大模型直接从 Verilog 代码反推测试，缺乏对设计规范全局语义的理解，无法建立起从“自然语言需求”到“覆盖率监控仓位”的确定性映射链条。当仿真结果显示未覆盖时，大模型既不知道这个仓位对应规格书上的哪句话，也无法判断是因为测试激励没发到位、状态机条件未满足，还是该状态在当前设计下根本不可达。缺乏可诊断的根因，所谓的“自主修复”只能变成无头苍蝇式的随机试错，最终陷入死循环。
GoGoTB 的系统架构：三层控制与演化知识库
为了越过 L1/L2 的鸿沟并保障智能体长时间自主运行的鲁棒性，GoGoTB 放弃了脆弱的单体 Agent 设定，将整套验证工程流程重构为八个有序的流水线阶段，并由三大底层子系统提供支撑：智能体执行控制层、可演化知识系统以及规格对齐的覆盖率闭环体系。
在仿真工具栈的选择上，GoGoTB 做出了一项务实的技术取舍。工业界传统的 VCS 或 Xcelium 搭配 SystemVerilog/UVM 代码对大模型来说极不友好——LLM 生成 SystemVerilog 语法的首轮成功率显著低于通用编程语言，且工具链报出的日志晦涩冗长。GoGoTB 选用基于 Python 的开源验证框架 cocotb 与 Verilator 仿真器搭建基础运行环境。Python 拥有丰富的语法表达能力和大模型训练分布优势，而 Verilator 提供的结构化、机器可解析的报错输出，为下游的自动化诊断提供了极其坚实的数据基础。
整个验证流水线包含四大业务阶段。第一阶段是规格分析（S1–S2），智能体解析设计需求，建立模块画像，并从数据通路、控制协议、状态转移等七个维度提炼出测试点清单。第二阶段是环境构建（S3–S5），基于测试点自动化生成功能覆盖率模型、参考模型（Reference Model / Golden Oracle）与测试平台顶层。第三阶段是随机仿真与累积分析（S6–S7），通过自适应随机种子注入激励并收集数据。第四阶段则是覆盖率闭环（S8），对残余盲区进行根因分类并执行定向修补。
保障这一复杂流水线稳定运转的首要功臣，是本文提出的三层执行控制架构。智能体在没有严格边界防护时，经常发生幻觉调用工具、污染上下文、在错误方向上重复修复等系统性失常。GoGoTB 将“LLM 的发散推理”与“确定性的程序守卫”在架构上严格解耦：
-
第一层守卫在工具调用级（Tool-Call Boundary）：拦截每一次底层工具调用，强制执行参数结构化校验，过滤非法指令；
-
第二层守卫在阶段网关级（Stage Boundary）：每一阶段完成后，由确定的规则引擎运行自动化语法静态检查、编译与接口兼容性审计，只有完全通过的制品才能流转至下一节点；
-
第三层守卫在故障恢复级（Failure Recovery）：当某一阶段无法通过网关时，触发由轻至重的四级升级修复策略，自适应调整修复上下文，避免智能体陷入盲目的局部打补丁。
与执行控制并行的，是两级可演化知识系统。直接将海量的硬件接口协议或 UVM 手册一次性塞入系统 Prompt，不仅会挤爆上下文窗口，更会导致大模型被无关细节误导。GoGoTB 的知识库分为技能库（Skill Library）与参考库（Reference Library）。技能库按验证阶段静态解耦，仅在流水线到达特定任务时分发对应的格式规范与操作指南；参考库则存储经过验证的历史设计案例，通过相似度门控机制进行检索。如果新模块与库中历史模块的结构匹配度极高，系统会下发对应的完整模板；若仅有局部特征重合，则降级为风格指导；一旦没有足够相似的历史设计，系统会果断抑制检索输出，宁可让大模型依据规格书全新推演，也绝不引入带有偏差的错误历史代码。
这种边界隔离还贯彻到了关键的黄金参考模型（Golden Model）上。在 GoGoTB 的体系中，参考模型只允许根据自然语言规格书独立推导生成，对下游 RTL 源码保持绝对的代码隔离。这保证了比对基准的客观性：仿真阶段出现的任何数据不匹配，必然源自 RTL 实现中的设计缺陷，杜绝了参考模型与待测设计“同错同对”的掩蔽效应。
规格对齐的闭环：七维根因诊断与定向收敛
在解决了执行稳定性与领域知识供给后，最核心的硬骨头依然是如何将功能覆盖率真正推向收敛。GoGoTB 抛弃了“在仿真后测量覆盖率”的传统被动模式，将覆盖率质量的前置决定权放在“模型编写期”。
框架在规格分析阶段，会强制模型梳理出一份覆盖七大行为维度的测试点清单：重置行为、基本数据通路、协议握手控制、状态机跳变路径、并发处理与反压场景、边界值与错误注入、性能与延迟指标。每一个测试点在生成阶段就被分配唯一的规格语义标签，并据此构建对应的覆盖率仓位（Coverage Bin）。这种将每一个 Bin 都锚定到具体设计意图的做法，为后续闭环带来了前所未有的可解释性。
当随机仿真结束、覆盖率停滞在某一瓶颈时，S8 阶段的覆盖率收敛引擎不会简单地向大模型抛出一句“提高覆盖率”，而是对所有未命中的 Bin 执行分类溯源。GoGoTB 建立了明确的七类残余盲区根因分类学，并为每一类指定了针对性的解决通路：
-
激励不足（Stimulus Gap）：单纯因为随机测试用例的数量或参数范围未触达，解决对策是扩展驱动器的随机生成空间；
-
序列缺失（Sequence Gap）：需要多拍（Multi-cycle）特定的协议交互序列才能触发（例如特定帧间隔后的突发传输），解决对策是调度 LLM 专门编写具备时序依赖的定向测试序列；
-
交叉约束冲突（Cross-Coverage Mismatch）：交叉覆盖率定义的信号组合在物理上存在互斥，系统会自动校验约束逻辑，修正不合理的 Cross 组合；
-
状态未达（Unreached FSM State）：有限状态机深层状态未被激活，需要通过状态转移图反推前置条件并构造导引激励；
-
时序依赖条件（Timing Condition）：涉及建立保持时间、时钟分频同步或异步复位去抖等精确时钟域交互，通过专门的时序注入模块处理；
-
边缘翻转异常（Edge Transition）：特殊信号的高低电平跳变边缘丢失，通过构造翻转压力测试弥补；
-
种子采样不均（Seed Deficiency）：测试向量分布不均导致，通过调整自适应随机种子池扩展采样空间。
通过这种“定位根因—路由解法—生成定向激励—回归验证”的闭环迭代，覆盖率的补充变成了高度有章可循的工程修复过程。一旦系统检测到当前未覆盖项已无可行解法，或连续迭代不再产生有效收益，即启动停滞感知安全退出机制，输出包含完整追踪链路的审计报告。
实验与验证：全自动化实测与主流大模型泛化
为验证 GoGoTB 的真实效能，研究团队在包含 48 核 Intel Xeon 处理器、512GB 内存的高性能计算平台上展开了全面评估，涵盖从简单外设到复杂控制器的 8 组不同复杂度开源 RTL 设计。评估横跨了包括 Kimi-K2.5、GLM-5.1、Minimax-M2.7、Claude Opus 4.6、Claude Sonnet 4.6、GPT-5.4 及 DeepSeek-V3.2 在内的 7 款主流大模型底座。
在环境生成的可靠性测试（RQ1）中，GoGoTB 展现出了极高的工程韧性。传统基于 LLM 的方案在自动化生成完整验证环境时，往往由于各类工具报错与代码语法冲突，成功率极低甚至难以跑通全流程。而在 GoGoTB 的三层执行控制保障下，面对 8 个设计和 7 款底层模型构成的所有测试矩阵，环境生成成功率全部达到了 100%。即使底层大模型的代码生成质量存在起伏，中间层的动态守卫与自动降级修复机制也能强行将编译错误、仿真配置不匹配等问题逐一拦截消解。
在核心覆盖率达标率（RQ2）方面，以 Kimi-K2.5 作为主力推理底座，GoGoTB 在 8 个设计上的表现十分亮眼：平均行覆盖率达到 98.4%，分支覆盖率达到 97.2%，信号翻转覆盖率达到 97.0%。更为重要的是，在衡量真实设计意图的规格级功能覆盖率上，GoGoTB 取得了 83.2% 的平均成绩。相比之下，此前业内唯一尝试测量功能覆盖率的开源基准 UVM2，由于采用无语义的信号物理切片，无法在同等口径下生成具备规格可解释性的覆盖结果，更无法自主达成如此深度的逻辑收敛。
论文通过 UART 接口的个案分析（CS1），清晰展现了动态知识库的核心价值。在没有注入领域专业知识前，大模型生成的验证环境遭遇了三类典型的“静默失败”：协议帧格式解析缺失起始位与停止位、采样监视器未对齐到波特率周期的 $0.5\times\text{BAUD_PERIOD}$ 中点、发送与接收通道共用逻辑导致时序错乱。这三类错误并不引发编译崩溃，但导致功能覆盖率直接归零。而在 GoGoTB 注入针对性的 UART 协议契约后，功能覆盖率直接跃升至 75.3%。这一实验极其雄辩地证明：很多看似属于大模型推理能力不足的瓶颈，本质上是验证上下文中的领域专业知识供给出现了断层。
在更复杂的 I2C 总线案例（CS2）中，由于该协议涉及多主仲裁、应答（ACK/NACK）机制与时序严格的状态转移，完整涵盖了前述七类根因。GoGoTB 在该用例上通过规格对齐的根因迭代，驱动功能覆盖率从初始状态强力提升了 28 个百分点。通过分析残余的 24 个未覆盖盲区，研究团队发现激励不足与多拍序列缺失占据了绝大多数——这说明系统已经完全具备“识别该测什么”的诊断能力，但大模型直接生成极度复杂的长周期协议定向序列仍有提升空间。
总结与展望
GoGoTB 的意义不仅在于提供了一组亮眼的评测数字，更在于为 AI 辅助甚至全自动芯片设计验证确立了一套兼具严谨性与落地可行性的范式。长期以来，大模型在芯片等硬核工程领域的落地往往陷入两个极端：要么将其视为无所不能的端到端生成器，因频繁出现的幻觉与不可控性而在工业落地中碰壁；要么将其作为简单的代码补全工具，无法触及复杂系统的核心价值。
GoGoTB 的成功表明，面对容错率为零的高精尖系统，必须将大模型置于“确定性工程控制框架”的约束之下。LLM 负责发挥其在自然语言解析、逻辑语义提取与多模态代码编写上的高阶泛化能力；而编译检测、语法网关、数据流隔离与仿真执行等底层任务，必须坚决交由确定性的程序化管道进行强制收口。同时，建立“从规格书到覆盖率模型”的语义锚定，让黑盒般的覆盖率缺口具备了可追溯的白盒根因，才真正赋予了大模型智能体自我诊断与自我进化的支点。
尽管目前在超长时钟周期、深层跨时钟域状态机的极端 Corner-case 上，纯 LLM 驱动的激励生成仍需结合形式化验证（Formal Verification）等传统数学证明手段进一步增强，但 GoGoTB 展现出的端到端无干预闭环能力，已经为芯片前端验证流程的彻底重构拉开了序幕。