DVCon China 2021虽然已经过去，但那一届论文里暴露出来的验证痛点和技术转向，放在今天依然对得上号。如果你手头正好在做UVM验证平台、或者正在为覆盖率收敛发愁，翻一翻那届的论文清单，会发现很多问题的答案其实两年前就已经有人在工程中踩过、填过、总结过了。这篇就基于DVCon China 2021的论文和现场讨论，把验证领域最值得关注的方法学演进、工具链实践和落地经验拆开讲讲，顺便把我自己实际用下来觉得能直接抄作业的东西整理出来。
1. DVCon到底是个什么会，为什么验证工程师不能错过
很多做设计的人对DVCon的印象是“一个验证领域的会议”，但对验证工程师来说，这是全年最值得盯住的技术风向标。DVCon的全称是Design and Verification Conference，由Accellera主办，是电子设计自动化领域里少数完全聚焦于功能验证的会议。它和DAC、ICCAD这类偏学术和EDA前端设计的会议不一样，DVCon的核心议题非常垂直：验证方法学、UVM、形式验证、仿真加速、覆盖率驱动、低功耗验证、IP复用，每一个话题都直接对着流片前的验证痛点来。
DVCon China是DVCon在中国的分会场，2021年那一届虽然因为特殊情况采用了线上和线下结合的方式，但论文数量和现场讨论密度并没有缩水。翻看那年的论文列表，你会发现几个明显的主题倾向：一个是UVM方法学在复杂SoC验证中的实践已经走过了“要不要用”的阶段，进入了“怎么用得更好”的深水区；另一个是形式验证和动态仿真之间的边界在重新被划定，很多团队不再把形式验证当成高不可攀的工具，而是把它纳入到日常回归流程里；还有一个很明显的趋势是，验证效率不再单纯靠人力和工具堆砌，而是靠流程改进和指标量化来驱动。
对从业者来说，DVCon China 2021的意义不只是获取几篇PDF，它像是给验证团队做了一次大规模的“方案体检”。你踩过的坑、团队争论过的问题、老板问你为什么覆盖率还卡在80%的尴尬瞬间，在论文里都能找到对应的解决思路。而且和纯学术论文不同，DVCon的论文大多来自一线公司的真实项目，工程化程度极高，几乎每篇都能拆出几条直接落地的经验。
2. 2021年论文里的核心战场：UVM从量变到质变的关键拐点
2.1 UVM已然成为默认选项，但真正拉开差距的是“架构设计”
DVCon China 2021的论文里，UVM相关内容依然占据相当大的比例，但如果你仔细读，会发现大家讨论的已经不是“如何搭一个UVM平台”这种入门问题，而是“如何设计一套可持续演进、可复用、可量化管理的验证架构”。这个转向非常关键。
早期很多团队搭UVM平台是照猫画虎：一个uvm_test_top、几个uvm_agent、一堆sequence，能跑通就算完事。但等到验证的模块从两三个涨到二三十个，或者要支撑多个项目复用的时候，这种结构就会迅速暴露出问题。2021年论文里大量提到的一个概念是“分层可复用架构”，也就是在传统UVM层次之上再抽象出一层“场景层”和“检查层”。场景层负责把不同模块级sequence组合成系统级场景，检查层则独立于driver和monitor，集中管理参考模型和计分板。这样做的好处是，当协议版本升级时，你不需要重写大型sequence，只需要调整场景层和检查层的映射关系。
我当时在一个PCIe验证项目里试验过这种思路，说实话，前期设计多花了大概一周时间，但到了项目中期，当新的PCIE版本RA收到时，平台只需要改参考模型的关键比对逻辑，而不需要动任何driver和sequence的代码，验证收敛速度明显快过之前的模块级验证平台。这种收益，只有等你真实经历过“为架构多花的一周在后期省下一个月”之后才会有体感。
2.2 覆盖率驱动的收敛流程：不是简单加覆盖率模型
覆盖率驱动收敛是DVCon的老话题了，但2021年的论文对这个话题的讨论明显更成熟了。早期大家做覆盖率收集，最常见的做法是在验证计划里列出要覆盖的功能点，然后在代码里写一堆covergroup，等到覆盖率不达标了再回头“补洞”，大量的时间浪费在反复分析、补充约束、重新回归上。
DVCon China 2021的观点更进了一步：覆盖率模型应该在验证平台搭建之前就完成设计，而不是平台成型后再“加持”。我在实践中也是这个体会，覆盖率收集的效率不取决于covergroup写得多详细，而在于覆盖率计划的层次化分解。协议层覆盖率、模块功能覆盖率、微架构覆盖率、代码覆盖率，这四层应该构成一条明确的分解链。如果你在设计平台之前就把这条链画出来，那么后续的收敛工作会顺畅很多；如果反过来，等平台跑起来了才开始写covergroup，你大概率会发现有一些功能点根本没有观测点，需要回头改monitor，甚至改driver的接口，代价非常高。
另外，2021年论文里反复出现的一个数据点是“覆盖率收敛的边际效应”。很多团队在功能覆盖率到85%左右之后就开始出现长时间不增长的平台期，这时候无脑加随机种子、延长回归时间，收益非常低。正确的做法是停下来做“未覆盖区域分析”，把没有被触发的bin列出来，分析到底是约束没有偏置到有效空间，还是monitor的采样点选错了位置。这一步分析往往比盲目加run time有效得多。
2.3 参考模型的实现风格：事务级比对正在成为主流
UVM验证平台里，参考模型的设计风格直接决定验证平台的维护成本。2021年论文里一个很明显的变化是，越来越多的团队抛弃了cycle级精确比对，转向事务级比对。简单说，早期的参考模型会精确到每个时钟周期都产生一个期望输出，这样的好处是比对粒度细，但坏处是，对参考模型的实现要求极高，任何时序上的小偏差都会导致大量误报。
事务级比对的做法是：参考模型只对“完成一个完整事务”之后的状态进行预测，比如一次读操作完成后，给出期望的读数据和读响应；一次写操作完成后，给出期望的存储状态变化。比对点的粒度从每个时钟周期提升到每个事务级别，这样对参考模型的实现要求大大降低，也更能容忍设计中合理的流水时序差异。
我自己在AXI验证中尝试过这种思路，发现误报率能降低一个数量级。尤其是当设计里面插入流水线寄存器、或者写缓冲之后，cycle级参考模型几乎无法维护，事务级参考模型却几乎不受影响。在DVCon China 2021的论文里，这种参考模型设计思路被多次提及，说明它已经从个别团队的前沿实践变成了行业共识。
3. 形式验证与动态仿真的融合：不再是非此即彼的选择题
3.1 形式验证的边界重新被认知
DVCon China 2021的另一大热点是形式验证。前几年大家对形式验证的态度两极分化：要么觉得“太复杂，不现实”，要么觉得“能解一切问题”。2021年的论文则给出了一个更理性的判断：形式验证不是一个能替代动态仿真的工具，它是一个能在特定场景下开源节流、把验证效率提升一个量级的方法。
在2021年的论文中，形式验证最适合的应用场景大致有三类。第一类是控制密集型逻辑的等价性验证和属性验证，比如中断控制器、电源管理状态机这类逻辑，动态仿真很难覆盖到所有的状态组合，形式验证却可以做到穷尽。第二类是数据通路里的定点运算模块，这类模块的动态仿真需要大量的定向激励才能覆盖边界值，形式验证可以直接对数据范围做数学证明。第三类是寄存器配置空间，形式验证可以自动检查每个寄存器的读写属性和复位值是否符合预期。
3.2 用形式验证反哺UVM平台的激励生成
2021年论文里比较有意思的一个实践是“形式验证语义反过来指导动态仿真的激励生成”。传统UVM的随机激励经常会陷入“约束写得太宽，大量激励跑到无效空间里”的窘境。形式验证因为需要对所有可能的输入组合空间做分析，它能够帮我们找出最容易触发设计bug的输入边界条件。这些边界条件如果转化为动态仿真里的约束条件，就能让随机激励的命中率大幅提升。
举个例子，我在验证一个支持可变长度的数据包处理模块时，UVM随机发包总是集中在几个典型的长度值附近，一些极端的长度（比如刚好等于FIFO深度、或者FIFO深度加1）非常难被随机到。后来我利用一个开源的SAT求解器对数据包长度寄存器做了一轮形式化分析，拿到了一组“高危长度值”，把这些值固化到验证平台的约束里，回归几轮就发现了一个在真实场景中几乎不可能靠纯随机发现的FIFO越界问题。这个方法在DVCon China 2021论文中也有类似的描述，我所做的只是把论文里的思路落到了真实项目中，效果相当立竿见影。
4. 低功耗验证与跨域检查：DVCon China 2021被低估的价值点
4.1 低功耗验证进入深水区：UPF不是写出来就完事
低功耗验证在这两年的数字IC项目里越来越重要，DVCon China 2021也有多篇论文专门讨论UPF和低功耗验证。我以前觉得低功耗验证无非是写好UPF，然后跑一遍仿真，看看某个电源域关掉后仿真是否报错。实际上，UPF写完之后还有大量需要验证的细节：隔离单元的信号隔离策略、电源域关断之后寄存器的保留策略、以及唤醒路径上信号恢复的时序是否满足要求。这些点如果不在仿真早期覆盖，到了后端阶段再来查，成本会成倍增加。
那届会议里有一个观点我非常认同：低功耗验证不应该等UPF完全定稿之后再启动，而应该在UPF的早期草案阶段就开始搭建验证环境。因为早期UPF版本虽然不完整，但基本的电源域划分和隔离策略已经能支撑验证平台搭建了。等到UPF更新几轮之后再补充相关的检查逻辑，整个低功耗验证的收敛速度会大大加快。
4.2 跨时钟域检查融入UVM流程
CDC（跨时钟域）验证在DVCon China 2021论文里也占据了一定篇幅。过去很多团队把CDC检查完全交给专门的CDC工具去跑，动态仿真里几乎不做跨时钟域的检查。但有不少bug是专门工具查不出来的，比如多个跨时钟域信号之间的相对时序关系、或者异步FIFO的空满信号在真实场景中的竞争行为。
从2021年的论文和我的实践经验来看，比较务实的做法是：在UVM平台里建立一套轻量级的CDC检查器，专门针对设计中的异步接口，在仿真运行过程中实时监测跨时钟域信号的建立时间和稳定性。这套检查器的实现并不复杂，配合UVM的report机制，可以做到在出现跨时钟域违例时自动fail回归。我自己的项目里就是靠这种方式，在后端流程之前提前发现了一个异步FIFO的读写指针竞争问题，看起来不严重，但如果在流片后才暴露，定位成本将非常高。
5. 论文里的实践方法论：如何从技术论文中提取可复用的工程经验
5.1 不要只看结论，要看“约束条件”
技术社区的读者读论文时最容易犯的一个错误是：看到了结论，就直接跳到自己的项目里去套。但DVCon论文的作者通常会在文中隐晦地交代一些约束条件——比如“该方案适用于带缓存的AXI总线”“该方案应用于8核可配置SoC”“该方法在3nm工艺节点下验证有效”。如果你没留意这些约束，直接生搬硬套，很容易在项目里踩坑。
我推荐的做法是把论文里的“方案”和“适用边界”分开来读。先画出论文方案的流程图和关键数据结构，再问自己三个问题：这个方案的验证对象和我们的模块有什么异同？它的数据激励模型和我们的实际场景是否一致？它的指标衡量方式在我们环境里是否可复现？回答完这三个问题，论文里的经验才算真正“消化”了。DVCon China 2021里很多论文的工程细节都极其扎实，但这也意味着它们的前提假设很多，随便套用是大忌。
5.2 用论文中的指标来度量自家的验证流程
DVCon China 2021论文里提供了很多可量化的验证效率指标，比如“每千行RTL代码的bug密度”“回归测试的有效失败率”“达到目标覆盖率所需的仿真时间”等等。这些指标看起来是作者用来证明方案效果的，但更实际的价值是：你可以用这些指标来衡量自己项目的验证流程是否健康。
我建议验证团队在项目启动阶段就把“有效失败率”这个指标纳入日常监控，具体方法是，每次回归测试结束后，统计一下所有失败用例中，有多少失败是因为被测设计的新bug，有多少失败是因为测试平台自身的问题（比如比对逻辑错误、约束冲突、环境配置问题）。如果“测试平台自身问题”导致的失败占比超过30%，说明平台质量存在问题，需要暂停收敛，先修复平台问题再继续跑回归。这个方法我在看了2021年多篇论文之后开始在团队里推行，实测下来，它能在平台期出现前提前暴露环境中的底层问题，省掉不少后期排查的时间。
5.3 如何在团队里快速落地一个新方法
DVCon论文里给出的方法虽然好，但一个现实问题是：团队不是一个人，落地一个新方法往往需要说服别人。从DVCon China 2021论文中总结出来的经验来看，最容易推动落地的方法有两种：第一种是在现有验证平台做“影子验证”，也就是新方法和老方法并行运行，不急着切量，先把两者结果的差异统计分析出来，用数据说话；第二种是选择“低风险高收益”的场景先切入，比如找一个反复出bug的老模块，用新方法去重新验证，一旦验证出新问题，整个团队对方法的信任度会快速建立。
我自己在推动参考模型从cycle级到事务级迁移的过程中，就是采取“影子比对”的做法：新老参考模型并行运行了一周，收集两者的比对输出差异，逐个排查差异原因，最终把误报率降了下来，说服了团队里的老同事。这个过程虽然慢一点，但比直接强制切换要稳妥得多，也更有说服力。
6. 验证技术演进带来的角色变化，以及普通工程师如何不掉队
6.1 验证工程师的身份正在从“执行者”变为“流程设计者”
DVCon China 2021的论文传递出的另一个信号是：验证工程师的职责边界正在明显扩大。过去的验证工程师更像是“执行者”——根据验证计划写环境、写用例、收覆盖率、出报告。但如今，验证工程师越来越像一个流程设计者，需要规划整个验证流程的架构，包括工具链的选择、环境结构的分层、指标的量化管理，以及如何与设计团队更高效地协作。
这种角色转变对工程师的要求也变了。以前只要熟练掌握SystemVerilog和UVM就可以，现在还需要理解验证方法论的整体设计、能够判断不同验证方法之间的优劣、甚至需要懂一些软件工程里的CI/CD理念来优化回归流程。我在用2021年的论文内容做技术分享时，经常和大家强调一个观点：验证工程不是一个“堆用例”的活，而是一个“设计系统”的活。用例写得多不代表验证充分，真正的价值在于你是否设计了一个能够高效暴露bug的系统。
6.2 新人入行如何从论文中获得成长
对于刚入行的验证工程师，DVCon China 2021的论文可能会显得满是术语、望而生畏。我的建议是：不要一开始就去啃那些讲系统级方案的文章，先找那些聚焦于单一小问题的论文来读。比如讲某个具体设备的验证方法、讲某一类断言库的设计思路、讲某个FIFO验证场景的约束技巧，这类论文篇幅适中、内容集中，读起来更容易转化为实际技能。
读单篇论文的时候，配合自己手头的项目一起实践是最有效的方式。比如论文里讲了一个AXI总线断言检查器的写法，你就可以在自己的验证环境里试着加一个类似的检查器，跑几个回归看能不能发现问题。这种“读一篇，练一个点”的方式，成长速度远比系统性读书快。我当年就是从一篇关于AXI总线断言复用的论文开始，逐步建立起自己写断言的能力，后来甚至把那些断言整理成了一个内部可复用的库，省下了一大笔第三方IP的费用。
6.3 未来的验证流程大概率是“混合验证”
DVCon China 2021论文里看起来很分散的主题，其实都可以汇到一个方向上：未来的验证流程大概率是动态仿真、形式验证、硬件加速甚至是基于AI的激励优化的混合体。没有一个单一工具能解决所有验证问题，真正高效的做法是让多种方法并行，并且在一个统一的管理框架下协同工作。
对工程师来说，这意味着技能栈需要适度拓宽。我不建议大家贸然从头去转岗做形式验证或者软件工程，但至少要能看懂形式验证的报告，理解硬件加速的约束条件，甚至能写一点简单的Python脚本去分析回归日志。这些“跨领域的基础能力”在接下来的几年里会越来越值钱。DVCon China 2021论文是一扇窗，透过它你可以看到，验证领域正在从一个以工具为中心的时代，走向一个以方法论和流程设计为核心的时代。
我自己在实践里最深的感触是：验证的难点从来不是run test，而是想清楚为什么要run这些test，以及如何让run出来的结果高效地指导设计修改。回头再看DVCon China 2021的论文，它就像一份浓缩的行业经验图谱，技术热点会变，工具链会更新，但背后关于“如何可靠地验证复杂系统”的思考方式，放到现在依然非常值得学习。如果时间有限，优先挑关于UVM架构设计、覆盖率收敛、形式验证融合这三类主题的论文来精读，性价比是最高的。
