看完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. DVCon U.S. 2026 Technical Sessions
4. A 3-Tiered Agentic AI Framework for Verification Regression
· · ·
「芯片人-晒AI笔记」
openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目,面向数字基础设施四大核心场景(服务器、云计算、边缘计算、嵌入式),全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构
更多推荐


所有评论(0)