ConfiBench：让大模型写 Testbench，先学会怀疑自己

基于 ACM TODAES 2026 论文的技术解读

原论文作者：Ruidi Qiu、Grace Li Zhang、Rolf Drechsler、Tsungyi Ho、Ulf Schlichtmann、Bing Li

硬件验证里，写 RTL 只是开始。真正消耗工程时间的，是让设计在足够多的场景下跑起来，并且知道输出到底错在哪里。Testbench 承担这件事，它要驱动输入、记录输出、判断结果，既像实验脚本，也像裁判。

大模型已经能写不少 Verilog，也能照着自然语言规格生成测试代码。问题在于，能写不等于写对。ConfiBench 这篇文章关心的正是这个缝隙：当大模型生成的 Testbench 也可能出错时，系统能不能自己发现、自己修、再把多个不完美版本组合成更可靠的验证工具。

1. Testbench 自动化难在哪里

仿真驱动的功能验证是数字硬件设计早期最常用的验证手段之一。工程师写好 DUT 后，需要一个 Testbench 把各种输入场景送进去，再检查输出是否符合规格。对小模块来说，这件事看起来只是写几段脚本。设计一复杂，场景数量、状态转移、边界条件和时序关系都会迅速膨胀。

传统自动化方法在前半段做得较多。它们可以生成测试激励，也可以按模板拼出 Verilog Testbench 骨架。难点落在后半段：输出是否正确，需要理解设计意图。一个选择器、计数器或者状态机的正确行为，常常写在自然语言规格里，或者散落在工程师脑子里的约束里。只会随机输入而不会判断输出，验证就只完成了一半。

LLM 给这个问题带来新机会。模型能读自然语言规格，也能生成代码，于是 AutoBench 这类框架开始尝试让模型同时生成 Verilog driver 和 Python checker。driver 负责驱动 DUT，checker 负责产生参考结果并比较输出。这个方向很有吸引力，因为输入只需要 RTL 规格，理论上能把前端刺激生成和后端结果判断串起来。

可大模型的随机性也会进入 Testbench。它可能漏掉边界条件，可能误解某个控制信号，也可能在 Python checker 里写错参考逻辑。AutoBench 有语法层面的自增强和调试，但语法正确不能保证功能正确。一个 checker 若把错误答案当成标准答案，仿真跑得越顺，误判反而越隐蔽。ConfiBench 的出发点就是补上这层功能自检。

2. 从 AutoBench 到 CorrectBench，再到 ConfiBench

论文把三层框架放在同一张流程图里。AutoBench 是生成器，负责从自然语言规格产生初始 Testbench。CorrectBench 在它后面增加 validator、corrector 和 action agent。ConfiBench 再往后接上置信度掩码和 Testbench 池，让多个经过筛选的 Testbench 共同承担最终验证。

图 1：ConfiBench 在 AutoBench 与 CorrectBench 之上增加场景置信度、掩码和测试平台集成。

来源：原论文 Figure 1，本文用于论文解读和学术交流。

CorrectBench 的动作逻辑很直接。生成器先产出一个 raw TB。validator 检查这个 Testbench 在不同场景下是否可信，并把正确、错误和不确定的场景编号交给 action agent。如果发现功能错误，agent 会优先调用 corrector 修复；修复次数超过上限后，系统重启生成流程；重启次数也超过上限后，流程停止并返回当前可用结果。论文实验中，修复迭代上限设为 3，重启上限设为 10。

这一层改动的重点不是再让模型多写几次，而是让系统获得一种功能层面的反馈。原来的框架只知道代码能不能编译、能不能跑。CorrectBench 想知道的是，Testbench 对某些场景的判断有没有错。如果错了，错误可能集中在哪些场景，后续修复要盯着哪里。

ConfiBench 接着处理另一个现实问题。validator 找到的错误信息并不总是非黑即白。有些 Testbench 大部分场景可信，只是在少数高风险场景上不稳。直接丢弃会浪费已经生成的有效部分，直接接受又会把错误带入最终验证。ConfiBench 的答案是给场景打分，把风险高的场景屏蔽掉，再用多个 Testbench 弥补单个 Testbench 的覆盖损失。

3. 用一批不完美 RTL 反过来审 Testbench

自校验最棘手的地方，是系统手里没有黄金 RTL。只有自然语言规格时，怎么判断一个 Testbench 生成的参考输出对不对？论文选择了一个有些反直觉的做法：让 LLM 生成一组不完美 RTL，把它们当成统计意义上的参照物。

这些 RTL 不保证全部正确。它们的价值来自差异性。若同一个规格下生成 20 个 RTL，它们未必会在同一个场景犯同样的错。把这些 RTL 与 Testbench 的多个测试场景交叉仿真，就能得到一个 RTL-Scenario matrix，简称 RS matrix。矩阵中的行对应 RTL，列对应场景。绿色代表 Testbench 对该 RTL 在该场景的报告是正确，红色代表报告不一致。

图 2：RS 矩阵把多个由大模型生成的 RTL 与多个测试场景交叉起来，用颜色暴露可疑场景。

来源：原论文 Figure 3，本文用于论文解读和学术交流。

看矩阵时，列比行更像问题探针。如果某一列大面积变红，说明多个 RTL 在同一个测试场景下都和 Testbench 的判断冲突。虽然这些 RTL 本身也可能有错，但大量独立样本同时冲突，会提高该场景参考逻辑有问题的概率。

论文比较了三种判定标准。最保守的 100%-wrong 要求一列全红才判错，这会漏掉不少坏 Testbench。更激进的 50%-wrong 容易把好 Testbench 误伤。最终采用的 70%-wrong 标准把列规则和行规则结合起来：若某个场景中 70% 的 RTL 都与 Testbench 冲突，就标记该场景可疑；若超过 25% 的 RTL 在所有场景上都完全匹配 Testbench，则直接认为这个 Testbench 可信。

这套 validator 在 1560 个来自 AutoBench 结果的 Testbench 上做了验证。论文报告的全局验证准确率为 88.85%，并且在完整框架实验中，70%-wrong 的整体表现优于 100%-wrong 和 50%-wrong。这个数字不能理解成已经找到理论最优阈值。作者也说明，阈值来自有限范围的搜索，未来可以用更自适应的办法继续优化。

4. 自校验之后，还要能定位和修复

只有验证器还不够。发现某些场景错了，系统还需要把这个信息变成可操作的修复提示。CorrectBench 的 corrector 分成两个对话阶段。第一个阶段由 LLM-Diagnoser 分析失败场景，回答为什么错、错在代码哪里、应该怎样修。第二个阶段由 LLM-Fixer 根据诊断结果修改 Python checker。

论文给出的例子来自 shift18 算术移位任务。失败场景指向右移时符号位处理不对。诊断器把问题定位到 arithmetic right shift 逻辑，指出高位符号扩展没有保持。修复器随后修改 Python checker，让它在右移后补上正确的符号位。这个例子说明，场景编号不是附属信息，它能把大模型的修复范围从整段代码收缩到更小的逻辑区域。

实验也支持这一点。CorrectBench 相对 AutoBench 的 Eval2 平均通过任务数增加 28.0 个，其中 validator 相关的任务数为 26.8 个，corrector 相关的任务数为 9.2 个。论文把 9.2 除以 26.8，得到 corrector 对这部分提升的贡献比例为 34.33%。顺序电路比组合电路更依赖修复，因为状态更新、时钟边沿和历史值让错误更难靠重启自然消失。

这段设计对工程读者有一个现实提醒。LLM 生成代码的后处理，不应只停留在编译错误和格式修复。真正影响验证质量的往往是功能语义，尤其是 checker 的参考模型。一旦参考模型错了，Testbench 就会以很自信的方式给出错误裁决。

5. ConfiBench 的核心动作：给场景打置信度

CorrectBench 解决的是坏 Testbench 怎么发现和修复。ConfiBench 继续往前走一步：如果 Testbench 只是局部有风险，能不能保留它的可靠部分？这就需要把 validator 的定性判断变成连续分数。

ConfiBench 给每个测试场景计算一个 0 到 1 之间的 confidence score。分数来自两个方向。列规则提供惩罚：某一列里不匹配 RTL 越多，该场景的风险越高，惩罚按指数形式增长。行规则提供奖励：完全匹配 Testbench 的 RTL 越多，说明整体 Testbench 更可信，奖励按对数形式增长。论文实验中，惩罚系数设为 1.0，奖励系数设为 0.1。

只看绝对分数还不够。一个场景在某个 Testbench 中拿到 0.8，可能已经是低分，也可能是高分，取决于其他场景分数如何。于是 ConfiBench 又引入 rank score。系统先对同一个 Testbench 内的场景置信度排序，再把排序结果归一化。最终掩码决策同时参考 confidence 和 rank。

图 3：置信度生成器把 RS 矩阵转换为场景级置信度、排序和掩码决策。

来源：原论文 Figure 5，本文用于论文解读和学术交流。

掩码的含义很具体：某个 Testbench 在某个场景上被禁用，该场景的报告不再影响最终判断。低置信度场景会被直接屏蔽，高置信度场景会直接保留，中间区域则由分数和排序共同决定。论文主实验中，掩码参数 T 设为 0.1，指数增长率 K 设为 10。

这个设计的微妙之处在于，它承认 LLM 生成物可以局部可靠。过去的流程更像二选一：要么这个 Testbench 通过，要么整个作废。ConfiBench 把判断粒度降到场景级，保留绿色区域，屏蔽红色风险，让不完美结果也能贡献一部分验证价值。

6. 掩码会损失覆盖率，所以要集成多个 Testbench

屏蔽风险场景带来一个副作用。单个 Testbench 的覆盖范围变小了。一个只在安全场景上发声的 Testbench 当然更稳，但它也更容易漏报。ConfiBench 用多 Testbench ensemble 来补这个洞。

系统把 Testbench 代码和对应的 scenario mask 放入 Testbench pool。每个 Testbench 有一个 valid ratio，也就是掩码中保留下来的场景比例。action agent 不会在拿到一个可用 Testbench 后立刻停下，而是持续重启生成流程，直到池中 Testbench 数量超过设定阈值，并且 valid ratio 总和达到要求。论文实验中，池大小阈值设为 2，有效比例总和阈值设为 0.8。

图 4：多个带掩码的单 Testbench 被放入池中，再按 valid ratio 组成最终集成。

来源：原论文 Figure 6，本文用于论文解读和学术交流。

选择器随后按 valid ratio 对池中 Testbench 排序，依次加入最终 ensemble，直到总 valid ratio 超过 Tr。实验中 Tr 也设为 0.8。最终使用时，只要 ensemble 中任何一个单 Testbench 在未被屏蔽的场景上报告错误，DUT 就会被判为有问题；如果所有保留场景都没有错误报告，DUT 才被判为正确。

这相当于把多个局部可信的裁判合成一个联合裁判。场景掩码负责减少错误裁判的发声机会，ensemble 负责补回被屏蔽后丢掉的覆盖面。两者如果拆开看，效果会变形。只用掩码，Eval1 可能看起来更好，因为错误报告变少了；Eval2 反而可能下降，因为覆盖不足。只用 ensemble 而不屏蔽，坏 Testbench 会把错误带进集成，风险会叠加。

7. 实验如何评价：Eval2 才是关键指标

论文使用 AutoEval 评价 Testbench。Eval0 检查代码有没有语法错误。Eval1 要求代码通过 Eval0，并且在 golden RTL 作为 DUT 时报告通过。Eval2 更严格，它使用 10 个 golden RTL 的 mutant 作为 DUT，把 Testbench 的报告与 golden testbench 的报告比较。若 80% 的 mutant 上报告一致，就认为 Eval2 通过。

数据集来自 AutoBench 使用的数据，扩展自 VerilogEval-Human，包含 HDLBits 的 156 个 Verilog 问题，其中组合电路 81 个，顺序电路 75 个。实验环境采用 Icarus Verilog 作为仿真器，Python 版本为 3.12.4，主要实验模型是 gpt-4o-2024-08-06。作者还在 claude-3-5-sonnet-20240620 和 gpt-4o-mini-2024-07-18 上验证了 CorrectBench 的兼容性。

主实验把 ConfiBench、CorrectBench、AutoBench 和直接让 LLM 生成 Testbench 的 baseline 放在一起比较。ConfiBench 实验重复 3 次，其他方法重复 5 次。作者说明由于 ConfiBench 成本更高，没有做正式统计显著性检验，但不同运行中的趋势稳定。

图 5：在 156 个 HDLBits 任务上，ConfiBench 的 Eval2 总体通过率达到 72.22%。

来源：原论文 Table 2，本文用于论文解读和学术交流。

总任务上，ConfiBench 的 Eval2 通过率是 72.22%，平均通过任务数为 112.7。CorrectBench 是 70.13%，AutoBench 是 52.18%，baseline 是 33.33%。也就是说，ConfiBench 比 AutoBench 高 20.04 个百分点，比 baseline 高 38.89 个百分点。

组合电路上，ConfiBench 的 Eval2 通过率为 85.60%，AutoBench 为 69.14%，baseline 为 53.58%。顺序电路上，差距更明显。ConfiBench 达到 57.78%，AutoBench 为 33.87%，baseline 只有 11.47%。论文强调，顺序电路一直是 LLM 生成 Testbench 的难点，因为状态历史和时序逻辑会放大 checker 的参考错误。

8. 结果真正说明了什么

如果只看总 Eval2，ConfiBench 相比 CorrectBench 的提升是 2.09 个百分点，似乎不算大。可这个数字背后有两个细节。第一个细节是 Eval1，特别是顺序电路 Eval1。ConfiBench 在顺序电路上的 Eval1 达到 90.67%，CorrectBench 为 71.73%，提升 18.94 个百分点。这说明场景掩码对减少 golden RTL 上的误报有明显帮助。

第二个细节是小模型。GPT-4o 上，ConfiBench 的 Eval2 为 72.22%，CorrectBench 为 70.13%，提升 2.09 个百分点。GPT-4o-mini 上，ConfiBench 的 Eval2 为 55.56%，CorrectBench 为 47.86%，提升 7.70 个百分点。小模型更容易在不同场景中出现局部错误，场景级掩码能过滤掉更多高风险判断，因此收益更大。

图 6：小模型上的增益和消融结果显示，场景掩码与多 Testbench 集成需要配套使用。

来源：原论文 Table 4，本文用于论文解读和学术交流。

消融实验把两个模块的耦合关系讲得更清楚。GPT-4o 上，去掉 multi-TB ensemble 后 Eval2 从 72.22% 降到 70.09%；去掉 scenario mask 后 Eval2 降到 67.31%。GPT-4o-mini 上，去掉 ensemble 后 Eval2 为 54.06%，去掉 mask 后为 50.00%。mask 对小模型更关键，ensemble 则负责把 mask 带来的覆盖损失补回来。

论文还统计了 final ensemble 中单 Testbench 的 valid ratio 和数量分布。多数通过 Eval2 的单 Testbench valid ratio 靠近 1，说明 CorrectBench 后的单体已经较可靠。也有一些低 valid ratio 的 Testbench 最终仍能贡献成功结果，因为它们在低可信场景被屏蔽后，保留下来的部分仍然有价值。

9. 代价并不小，适合用在可靠性优先的环节

ConfiBench 不是免费午餐。论文在 GPT-4o 上比较了四种方法的平均成本。ConfiBench 每个任务平均输入 token 为 68493，输出 token 为 25785，运行时间为 747.70 秒。CorrectBench 分别为 52665、19167 和 328.37 秒。AutoBench 为 9223、5236 和 77.69 秒。baseline 的输入输出 token 只有 401 和 524，运行时间为 61.88 秒。

这组数字说明，ConfiBench 更像高可靠性模式，而不是轻量草稿模式。若目标只是快速得到一个能跑的 Testbench，AutoBench 或 CorrectBench 可能更合适。若目标是减少功能误判，尤其面对顺序电路、复杂状态机或高风险设计模块，额外的 validator、corrector、mask 和 ensemble 才有工程价值。

从 EDA 工具角度看，这篇文章的意义不只在于把通过率拉高。它展示了一个 LLM 工程化思路：不要把模型输出当成一次性答案，而是把多个模型生成物放进一个可验证、可筛选、可组合的闭环。自然语言规格、仿真结果、错误场景、置信度、代码修复，它们共同形成反馈系统。

这种思路也能迁移到其他自动化任务。大模型写代码、写约束、写形式化属性、写脚本时，都可能局部正确、局部错误。工程系统需要的不是单次生成的漂亮文本，而是能利用不完美输出的机制。ConfiBench 的贡献正在这里：它没有要求每个 Testbench 都完美，而是让系统知道哪些场景更可信，哪些结果应该暂时沉默。

10. 还没有解决的边界

论文也留下了几个边界。RS matrix 的可靠性依赖生成 RTL 的行为差异。如果这些 RTL 有高度相似的系统性错误，validator 可能会被误导。作者用较高 temperature 生成 RTL，并用较严格阈值降低风险，但这并不能彻底消除不确定性。

参数也还带有经验色彩。惩罚系数、奖励系数、mask 阈值、valid ratio 阈值都来自有限实验。Table 6 显示，不同参数组合会影响 Eval2、Eval1 和 Eval0，主文设置在测试范围内表现最好，但这不代表换模型、换数据集、换设计类型后仍然最优。

作者把未来方向指向强化学习式的置信度优化。思路是把参数选择或掩码决策看成策略动作，把下游验证结果作为奖励，让系统自动寻找更合适的策略。难点也很清楚：每次策略评估都要跑完整流程，成本高，奖励稀疏，训练稳定性也不容易保证。

还有一个现实问题值得工程团队自己评估。论文没有做正式统计显著性检验，且 ConfiBench 因成本原因重复次数少于其他方法。文中的趋势很稳定，数字也有吸引力，但在落到企业内部设计流之前，仍需要用自己的模块、规格质量和模型接口复测。

结语：让生成工具先接受验证

ConfiBench 最有意思的地方，是把大模型生成 Testbench 的问题从写出来推进到写出来后怎么相信。它没有假设 LLM 会突然变成可靠工程师，而是围绕不可靠性搭了一个工作流：用不完美 RTL 建 RS 矩阵，用 validator 找功能错误，用 corrector 修 checker，用 confidence mask 屏蔽高风险场景，再用 ensemble 补回覆盖。

最终 72.22% 的 Eval2 通过率不是单个提示词带来的胜利，而是验证闭环带来的收益。对硬件验证来说，这个方向比单纯追求更强模型更接近工程现实。模型会继续进步，但验证系统仍然需要怀疑、校验、筛选和组合。ConfiBench 给出的答案很朴素：让大模型写 Testbench 之前，先让它学会接受检查。

参考资料

图片和表格均截取或整理自原论文 ConfiBench: Automatic Testbench Generation with Confidence-Based Scenario Mask and Testbench Ensemble using LLMs for HDL Design，仅用于论文解读和学术交流。文中方法、实验设置、数据和结论均以 PDF 原文为依据。