看完50篇 AI for DV 论文，我觉得验证工程师暂时安全，但工作已经回不去了

芯片人-晒AI笔记 · AI for DV

约5200字 / 阅读约9分钟

Agentic EDAAI4EDAStage ContractValidator GateEDA Tool GatewayAgent HarnessDomain PackAI-Native DesignCopilot vs AgentL1-L5 AutonomyDesign State GraphSignoff

这几天，我干了一件有点笨的事。

我把 AI for Design Verification 这个方向，从2012年的早期机器学习论文，一直翻到了DVCon 2026。

一共50篇。

能找到公开版本的，我都下载了下来。找不到的，就顺着 DOI、作者主页、会议论文集继续挖。中间还踩了不少坑，有些链接看着像PDF，下载下来其实是个付费墙页面，有些论文搜索引擎能读，真正点进去却只剩一个403。

折腾完以后，完整论文拿到了42篇，另外还有一份官方演示稿和一份作者海报。

然后我开始一篇一篇看。

一开始我以为，这批论文大概会告诉我，大模型已经可以写UVM、生成SVA、自动补coverage，甚至准备把验证工程师也一起优化掉了。

毕竟最近两年的标题，一个比一个狠。

什么自动生成Testbench，什么AI Formal Verification Engineer，什么Agentic Regression，什么从Spec到Sign-off。

看着都挺吓人。

但把50篇论文连起来看完以后，我反而松了一口气。

AI当然不是不行。只是它开始有用的地方，跟很多人想的并不一样。

AI for DV 最成熟的能力：下一步做什么

现在AI for DV最成熟的能力，不是独立完成验证。

而是回答一个验证工程师每天都在回答的问题。

下一步，最值得做什么？

该跑哪批测试，哪个失败跟以前见过的很像，哪个coverage hole值得继续追，哪个formal engine更可能收敛，这条assertion缺了什么helper，眼前这个log到底应该先交给谁。

这些问题单独看都不性感，甚至有点脏活累活。

可真正在项目里待过的人都知道，验证的大量时间，恰恰就耗在这里。

测试大家都会写，难的是判断下一组最值钱的测试是什么。log也都能看，麻烦的是nightly regression一觉醒来炸出几千条失败，里面可能只有两个根因。

coverage更折磨人。最后那零点几个百分点，经常藏在一组极其别扭的约束组合里，随机跑十万次都未必撞得到。

这才是AI真正开始切进去的地方。

从 2012 到 2026：一根没怎么变的骨头

这条路其实很早就开始了。

2012年那篇关于机器学习自动化Coverage-Directed Test Generation的综述，已经把基本结构讲得很清楚了。跑一轮仿真，观察coverage，再根据反馈调整下一轮激励。

今天大家说的RL、LLM、Agent，外壳变了很多，里面那根骨头其实没怎么变。

还是一个反馈闭环。

只是以前模型改的是约束和参数，现在的Agent开始决定调用哪个工具、读取哪份规格、生成哪条属性、什么时候停下来找人。

DVCon 2020 & DAC 2023：把低价值重复劳动挤出去

我印象很深的一篇，是DVCon 2020的Machine Learning-Guided Stimulus Generation。

它没有试图把UVM推翻重写，而是研究test内部哪些transaction更值得跑。作者在自己的实验配置中报告，把模型训练和数据处理的成本也算进去，整体CPU时间仍然减少了大约70%。

这个思路很工程。它沿用原来的验证体系，只把低价值的重复劳动挤出去。

NVIDIA在DAC 2023的一篇工作更直接。 __IMG_02_DAC2023__

他们从快速功能仿真的结构覆盖数据里，用无监督学习挑出更有差异的测试。论文报告，在保持相近功能覆盖的条件下，RTL仿真时间最高可以减少约85%。其中一个GPU单元里，约4000个测试命中了全量20000个测试所覆盖点的90%。

五分之一的测试，覆盖了九成的点。

看到这个数字，我第一反应不是模型真牛。

而是我们过去到底烧掉了多少重复的仿真资源。。。

当然，这个数字不能直接搬到另一个项目里。设计规模、coverage model、测试质量、版本阶段都不一样。无监督模型认为某个测试在结构上很特别，也不代表它一定能抓到高风险bug。

但这个方向是成立的。

AI不一定比验证工程师更懂设计，它可以比人更耐心地盯着几十万次历史回归，找到那些人眼很难看出来的重复和偏差。

LLM 会写 SystemVerilog，不等于 LLM 会验证

再往后走，就到了大家更熟悉的生成式AI。

这里有一个特别容易被标题带偏的地方。

LLM会写SystemVerilog，不等于LLM会验证。

这两个能力，中间隔着一条很宽的河。

AutoBench、CorrectBench、LLM4DV、UVLLM、UVM²，这几年的论文都在尝试生成testbench、刺激、checker或者UVM环境。数字看起来也越来越漂亮。

CorrectBench在论文中报告的总pass ratio是70.13%，高于前代方法的52.18%和直接生成的33.33%。MEIC在178个RTL错误组成的数据集上，语法修复率和功能修复率分别报告到93%和78%。

这些结果已经不能再用「大模型只是玩具」来搪塞了。

它确实能干活。

可越往论文细节里看，越会发现起作用的并不是一次生成。

是编译失败以后重写。

是仿真结果不对以后继续修。

是formal engine返回counterexample以后，重新生成helper assertion。

是coverage没有增长以后，换一个约束和场景。

也就是生成、执行、反馈、再生成。模型负责提出候选，工具负责打脸。

我觉得这句话，几乎可以概括当前所有相对靠谱的AI for DV系统。

比编译错误更可怕：false pass

工具必须负责打脸，因为验证里最可怕的东西，从来不是编译错误。

编译错误摆在那儿，谁都看得见。

真正可怕的是false pass。

一个testbench跑通了，波形也挺漂亮，coverage看着也在涨，但它的scoreboard跟DUT犯了同一个错误。或者生成的assertion语法没问题，却表达错了规格。更离谱一点，模型为了让proof收敛，顺手加了一个过强的assumption，把真正的bug也一起假设没了。

整个流程一片绿色。

芯片回来以后再告诉你，绿色是假的。

所以VerifLLMBench这类工作很重要。

它不再只问testbench能不能编译，而是问这个testbench能不能把故意注入DUT的bug找出来。

这个评价方法一下就把问题拉回了验证的原点。

验证资产的价值不看它写得像不像UVM，要看它能不能对错误敏感。

SVA 与知识图谱：喂错上下文，越聪明越错

同样的事情也发生在SVA生成上。

从早期的自然语言转SVA，到Security Assertions by LLMs，再到AssertLLM、VERT、HADA和NVIDIA的AssertionForge，路线越来越清楚。

只把一段规格扔给模型，效果很有限。

真实规格里的信息太散了。接口时序在波形图里，例外条件在表格脚注里，信号真正的名字和层次又在RTL里。规格讲的是意图，assertion却必须落到真实的状态、信号和时间关系上。

AssertionForge的做法就很有意思。

它把规格和RTL一起变成知识图谱，再从不同分辨率提取上下文生成assertion。这个思路没有迷信模型参数，而是先把需求、实现和信号路径对齐。

模型再聪明，喂错上下文也没用。

甚至有时候，模型越聪明，错得越像真的。

这话听着有点刺耳，但我越来越觉得，AI for DV最后拼的可能不是谁家的模型大，而是谁家的验证知识整理得更干净。

规格条目跟哪段RTL有关。

这条property依赖了哪些assumption。

哪个coverage hole以前追过，后来为什么判定不可达。

这个failure signature归过谁，最终对应哪个bug，修复以后跑了哪些回归。

这些东西，大多数公司其实都有。

只不过散在PDF、Excel、Jira、回归数据库、波形、邮件、工程师脑子和一些已经没人敢动的脚本里。

乱得很真实。

大模型不是魔法。它面对一堆互相冲突的旧规格、失效链接和过期测试，也只会把这锅知识粥煮得更像一锅知识粥。

DVCon 2025 → 2026：从单点工具到验证操作系统

这就是我看DVCon 2025和2026时，感受最强烈的变化。

2025年，大家还在展示一个个具体用例。

NVIDIA用LLM做VIP实例化，Samsung用设计元数据提前生成coverage定义，AMD用随机森林做regression triage，Infineon用Saarthi把formal plan、SVA、proof、counterexample和formal coverage串起来。

那一年的AI，很像一个个装在验证流程旁边的外挂。

有的负责挑测试，有的负责分log，有的负责写property，有的负责补coverage。

到了DVCon 2026，词突然变了。

Spec-RAG、Knowledge Graph、GraphRAG、Memory、Multi-Agent、MCP、Agentic Sign-off、Autonomous Regression。

AI已经不满足于给某个环节打辅助了，它开始试图维护整个验证任务的状态。

Samsung公开的三层Agentic Regression Framework，把Agent分成user、block和central三层。个人层处理局部测试和日志，block层维护IP状态，中央层再解决跨block资源和风险。

这套结构挺像真实的验证组织。

一个工程师不需要知道全芯片每个角落的细节，一个block owner也不应该随便改另一个block的策略，真正跨模块的问题才升级到中央层。

Agent开始有了组织结构。

这比造一个无所不能的超级Agent靠谱多了。

因为验证从来就不是一个人的独角戏。

EDA 厂商 vs 芯片公司：谁有什么牌

回到公司这边看，三大EDA厂商的路线也很有意思。

Synopsys把VSO.ai、Verdi、Formal Advisor和AgentEngineer往一起串。Cadence把Verisium里的Manager、Debug、AutoTriage、CodeMiner、WaveMiner、SimAI、SmartProof放在同一套验证数据面上。Siemens则强调Questa引擎原生的MCP和受控Agent。

表面上大家都在讲Agent。

可它们真正有价值的资产，还是下面那些跑了很多年的仿真、形式、调试和verification management引擎。

模型可以换。

VCS、Xcelium、Questa里的工具状态，项目积累的coverage、failure、waveform和proof数据，没那么容易换。

芯片公司又是另一边。

EDA厂商有执行引擎，芯片公司有规格、历史回归、缺陷和组织经验。

NVIDIA、Samsung、Micron、AMD、Infineon、Intel公开出来的路线都不一样，因为它们最贵的验证瓶颈不一样。

Micron在NAND和DRAM验证里更关注高维参数和序列。AMD从owner和failure signature预测这种标签清楚的场景切入。Infineon把力气放在Agentic Formal上。Samsung看起来则在搭一整套内部Verification Intelligence Platform。

这里比的不是谁跟风快，而是谁手里有什么数据，又愿意先解决哪个最贵的问题。

验证工程师会被替代吗？

写到这里，可能有人会问，验证工程师到底会不会被替代？

坦率地讲，我不知道五年以后会怎样。

但只看这50篇论文和DVCon 2025、2026的公开证据，我不相信短期内会出现一个AI，独立接手生产级SoC验证，然后自己签字说可以tape-out。

现在离这一步还很远。

Saarthi的端到端形式验证框架很有启发性，但作者后续也承认初代整体效能大约只有40%。很多LLM testbench论文仍然集中在规模较小、边界清楚的设计上。工业论文里的数据又大多来自单项目和私有环境，跨IP、跨团队、跨设计代际的泛化证据并不够。

更麻烦的是，sign-off不是一道有标准答案的题。

规格可能自己就矛盾。

coverage model可能漏了场景。

一个不可达bin到底是真不可达，还是约束写错了，需要架构、设计和验证一起判断。

模型可以给建议，但最后接受风险的人还是人。

不过，如果因为AI暂时不能签字，就觉得验证工作不会变，我觉得也有点自欺欺人。

它已经在变了。

过去一个强验证工程师的价值，很大一部分是会写环境、会调约束、会看波形、会追coverage、会从几千条log里闻出那条不对劲的味道。这些能力以后仍然重要，但还会多出一层。

你能不能把自己的判断过程，变成机器可以使用的规则、数据和反馈。

你能不能定义什么可以自动执行，什么必须审批。

你能不能设计一个不会靠删测试来提高回归效率、不会靠弱化assertion来提高proof成功率、不会靠忽略corner case来制造漂亮coverage的guardrail。

你能不能让AI给出的每一步，都留下可重放的证据。

验证工程师的工作单元，可能会从「亲手完成每一个动作」，慢慢变成「定义目标、设置边界、检查证据、处理异常」。

有点像飞机上的自动驾驶。

稳定、重复、可观测的阶段，机器会接手越来越多。真正恶劣的天气、传感器冲突和超出预案的情况，还是要人回来。

而且人不能因为平时不碰操纵杆，就把判断力也一起丢了。

这才是我觉得最难的地方。

DV 团队的 AI 落地路线图

所以，如果现在让我给一个DV团队排AI落地顺序，我不会从自动生成整套UVM环境开始。

我会先做regression triage和failure clustering。

因为标签现成，风险可控，做错了也容易发现。

然后做test selection和coverage recommendation，但保留关键测试、随机探索和周期性全量回归。模型可以少跑测试，但不能自己悄悄改掉风险定义。

再往后做SVA和formal helper生成。

让LLM起草，让formal engine判定，再加vacuity、mutation和known-bug replay。

Testbench生成可以试，但评价指标不能只看compile rate。得给DUT注入bug，看看它到底能抓住几个。

至于从Spec一路自治到Sign-off的超级Agent，可以研究，可以做原型。

别急着把签字权给它。

写这篇文章的时候，我总想起验证里一个很朴素的事实。

设计工程师负责把功能做出来。

验证工程师负责证明，世界没有按我们想当然的方式运行。

AI最擅长的，偏偏也是从历史里学习最可能发生什么。

这两者放在一起，既强大，又有一点危险。

因为芯片里最贵的bug，往往藏在所有人都没想到、数据里也从来没有出现过的地方。

所以AI for DV成熟的标志，不是模型终于可以写出一万行UVM。它得在该快的时候快，在不知道的时候承认不知道，在风险越界之前把人叫回来。

我看完50篇论文，最后留下的就是这么一个有点朴素的判断。

AI不会替我们证明芯片一定正确。

它会逼着我们重新回答，什么才算证据。

而这件事一旦开始，验证工作就已经回不去了。

我是钱大爷。

芯片是视角，AI是目的地。

文中涉及的部分资料

4. Coverage-Directed Test Generation Automated by Machine Learning—A Review

4. Machine Learning-Guided Stimulus Generation for Functional Verification

4. Test Selection for RTL Coverage by Unsupervised Learning from Fast Functional Simulation

4. CorrectBench

4. MEIC

4. AssertionForge

4. VerifLLMBench

4. DVCon U.S. 2025 Program

4. DVCon U.S. 2026 Technical Sessions

4. Saarthi for AGI

4. A 3-Tiered Agentic AI Framework for Verification Regression

· · ·

「芯片人-晒AI笔记」