AI 会写 testbench 了，但验证工程师更慌了|eda|testbench|人工智能模型|代码|寄存器|工程师|追踪

这轮 AI+EDA 的讨论里，最容易被传播的，还是生成能力。

AI 能不能写 RTL？能不能生成 testbench？能不能补 assertion？能不能读 log、看 waveform、追 coverage？

这些问题当然重要。但它们可能不是验证瓶颈的最底层。

Semiconductor Engineering 6 月 29 日发了一篇 Rethinking Chip Verification。文章把问题往前推了一层：如果规格本身不够机器可读、不够可执行、不够可追踪，那么 AI 生成再多验证资产，也很难回答一个更硬的问题：这些东西到底是不是对的？

这就是 golden specification 被重新抬上桌面的原因。

这里的 golden spec，不再是项目早期那份 PDF 规格书，也不是寄存器表、接口说明和几张时序图的集合。它更像一条语义基线：需求怎么来的，RTL 怎么实现，UVM testbench 测了什么，formal property 证明了什么，firmware 假设了什么，物理约束和封装条件又改变了什么。

如果这些关系不能被机器读取、追踪和复核，agentic verification 很容易变成一个更会写代码的助手，而不是能进入 sign-off 证据链的工程系统。

过去的问题，是“测得够不够”

传统验证当然也依赖规格。

架构师写 design intent，设计工程师写 RTL，验证工程师读 spec、拆 verification plan、搭 UVM 环境、写 assertion、跑 regression、追 coverage。这个流程大家都熟。

问题在于，很多连接关系长期靠人脑维护。

规格变了，verification plan 有没有同步？一个 coverage gap 对应哪条需求？RTL diff 影响哪些 test？firmware 对寄存器行为的假设，是否和硬件实现一致？

这些问题在小项目里还能靠核心工程师记住，在复杂 SoC 里已经很难，在 chiplet 和 3D 封装里更难。

过去行业默认可以用更多仿真、更多 formal、更多 coverage closure 去补这个洞。工具越来越强，验证方法论也越来越细。

但到了 AI 这一轮，这种补法不够了。

因为 AI 不是只消耗规格，它还会生产新的验证资产。它可以生成 testbench、assertion、coverage point、debug 假设、文档摘要，甚至参与流程编排。生成速度一旦上来，规格和证据之间的断层反而更危险。

一个人写错一条 assertion，review 还可能看出来。一个 agent 批量生成一百条 assertion，其中九十条看起来合理、十条暗藏误解，验证负责人真正头疼的不是“写得快不快”，而是“怎么证明它们没有把 design intent 理解歪”。

所以验证的底层问题正在变化：从“有没有测到足够多场景”，变成“规格是否足够明确，明确到可以被机器消费，也能被人审查”。

golden spec 不是更厚的文档

Semiconductor Engineering 原文里，Axiomise CEO Ashish Darbari 对 golden spec 的说法很直接：它应该是持续更新、机器可读、可执行的工件，能同时成为硬件、固件和软件团队的语义锚点。

这句话的重点不在“golden”这个词，而在“语义锚点”。

过去一份规格往往被不同角色重新翻译。RTL 工程师按一种方式理解，formal 工程师按一种方式理解，UVM testbench 作者按一种方式理解，firmware 团队又按另一种方式理解。每一次翻译都可能引入偏差。

SystemRDL、IP-XACT 这类格式，是往结构化方向迈的一步。但它们更多解决寄存器、接口和描述规范问题。真正的 golden spec 还要回答更高层的问题：这个需求是否完整？不同 block 的假设是否冲突？一个系统级目标有没有被正确分解到硬件、firmware 和验证资产里？规格变更后，哪些下游工件必须同步更新？

ChipAgents CEO William Wang 在原文里也提到，AI-native 设计和验证流程需要一个可被 agentic systems 消费的 ground truth，也就是统一可信的事实基线。没有这个参考，正确性本身就会变得难以定义。

这句话非常关键。

今天很多 AI+EDA demo 的隐含前提是：只要模型足够强，就能从散落的文档、代码、日志和历史记录里推理出答案。

但真实项目不是开卷考试。材料之间可能互相矛盾，文档可能过期，脚本里可能有 workaround，coverage model 可能反映的是历史妥协，不是当前需求。

如果没有一个更高层的、持续更新的规格基线，agent 读到的上下文越多，未必越可靠。它可能只是把项目里的历史噪音组织得更像一个答案。

chiplet 把规格问题放大了

十年前，很多团队说 golden spec，主要还是在单片 SoC 语境里讲功能、接口、时序和验证预期。

现在不一样了。

多 die、chiplet、3D IC 把规格从“功能文档”推成了“系统契约”。原文里 Vinci 的 Satish Radhakrishnan 提到，今天的规格还要覆盖几何、材料、堆叠结构、接口、热边界条件、机械约束、功耗图，以及热和热机械行为。

这些听起来已经不像传统 RTL 验证文档，更像系统工程。

原因很简单。chiplet 系统里，一个 die 的边界就是一个规格表面。不同 die 可能来自不同供应商，不同工艺节点，不同 IP 体系。NoC interconnect、die-to-die 协议、bring-up、发现机制、安全、遥测、错误处理、QoS，都可能影响最终系统能不能工作。

这时 validation 和 verification 的界限也会变得更尖锐。

Verification 问的是：我们是否正确实现了这个东西。Validation 问的是：我们一开始要构建的，是不是正确的东西。

在单片 SoC 时代，这两个问题也存在，但边界相对可控。到了 chiplet 和系统级集成，很多失败不是某个 test 没写好，而是系统级规格没有把真实约束说清楚。等到 integration 才发现某些行为无法一致实现，已经不是普通 coverage gap，而是规格失败。

这也是为什么原文把 golden spec 和 ultimate shift left 放在一起讲。

真正的 shift left，不是把后端检查提前一点，也不是让 AI 更早生成 testbench。更彻底的 shift left，是在项目最前面把“什么才算正确”变成可计算、可追踪、可复核的东西。

AI 让规格工程变成新岗位

Synopsys 的 Frank Schirrmeister 在原文里提到一个老问题：executable spec 这个想法并不新，几十年前就有人讲过。但过去行业更多把 RTL 作为可操作的硬件实例，然后围绕 RTL 做软件开发、验证和工具流。

现在 AI 把这个老问题重新打开了。

因为 agentic flow 想覆盖的不只是 RTL。它要读需求，拆任务，调用 EDA tool，生成候选 RTL 或验证资产，跑仿真和 formal，解释失败，更新计划，甚至把结论回写到项目管理系统。

如果每一步的输入输出都没有可追踪关系，agent 的行动就很难审计。它为什么改了这段 RTL？为什么认为这个 assertion 覆盖了那条需求？为什么判断这个 failure 是环境问题而不是设计 bug？为什么某个 coverage gap 可以豁免？

这些问题最后都会回到规格工程。

原文提到，工具还没有准备好自动连接 DOORS 这类需求系统，再向下追到 block spec、RTL、verification plan 和一致性检查。行业已经有 MBSE、需求数据库、验证管理、HLS、AI 代码和 RTL 生成器等拼图，但它们没有自然连成一条可用链路。

这也是 AI+EDA 最容易被低估的建设成本。

模型只是表面。真正难的是把企业内部的 spec、设计规范、IP 文档、review 记录、EDA flow、脚本约定、权限边界和审计机制整理成 agent 可以使用、工程师可以追责的状态。

在这个意义上，未来芯片团队里可能会出现更明确的 specification engineering 角色。它不是传统文档管理员，也不是单纯的验证工程师，而是负责把需求、设计、验证、软件和物理上下文连接成一套可执行语义系统。

这对国内团队意味着什么

国内芯片公司讨论 AI+EDA，经常会先问模型能力：能不能懂 Verilog？能不能写 testbench？能不能接入仿真器？能不能分析 log？

这些问题当然要问。但如果只问这些，很容易把 AI 当成一个更聪明的代码补全工具。

更实际的落地顺序可能相反。

第一步不是让 agent 生成更多内容，而是让企业知道自己有什么上下文。规格在哪里，版本怎么变，设计约束由谁维护，verification plan 如何映射需求，coverage report 怎么回标，bug 记录和历史 workaround 能不能被检索，哪些材料能给模型看，哪些必须隔离，哪些输出必须 review。

第二步才是让 AI 进入局部任务。比如基于 spec 生成 verification plan 草稿，基于 RTL diff 提醒相关 test 和 coverage point，基于 failure log 和 waveform 给出 debug 假设，基于需求变更列出受影响的下游资产。

第三步是把这些任务接到流程里，而不是停在聊天窗口里。真正可落地的 AI+EDA，不会只靠个人助手，而是要把专业模型、企业知识库、设计流程编排和权限治理放进同一条研发链路。对高保密研发环境来说，本地化、私有化、过程留痕和人工 review 节点，往往比单点模型能力更早决定能不能用。

这类问题很难只靠一个聊天工具解决。真正可落地的 AI+EDA，往往要把专业模型、企业知识库和设计流程编排连接起来，让 AI 能进入 spec、log、coverage 和 EDA flow，而不是停留在代码补全。

说白了，AI 在验证里的价值，不是让团队少写几页文档，而是逼团队把过去靠经验、口头约定和历史包袱维持的东西，变成可追踪的工程资产。

Rethinking Chip Verification 这篇文章有意思的地方，是它没有把 AI 验证写成一个“模型能力升级”的故事。

它真正指出的是：AI 越进入设计验证流程，规格就越不能停留在静态文档。它要变成持续更新、机器可读、可执行的工程基线。

没有这条基线，AI 生成的 RTL、testbench、assertion、coverage point 和 debug 结论，都只能算候选输出。它们可以提高效率，但很难自然进入 sign-off 证据链。

有了这条基线，agentic flow 才有可能从“会做事”走向“做得可查、可复现、可追责”。

所以，AI+EDA 的下一阶段，竞争点未必是谁的模型更会写代码。更可能是谁能先把规格、知识、流程和证据链连接起来。

芯片验证最终要回答的不是“AI 生成了什么”，而是“我们凭什么相信它生成的是对的”。

作者：麒芯

参考来源：Semiconductor Engineering, "Rethinking Chip Verification", 2026-06-29；Semiconductor Engineering, "Toward Agentic Verification", 2026-05-28；Accellera Portable Stimulus Standard。

本文为行业观察与技术分析，不构成投资建议。

加入 IC Agent 技术交流群

群里聚集了芯片设计工程师、IT/CAD 负责人和 AI+EDA 从业者，聊技术、聊工具、聊行业趋势。