1. 先聊聊：为什么 SoC 验证这么“磨人”
干了十几年的芯片验证，带过不少新人，也踩过无数坑。经常有刚入行的朋友问我：SoC 验证到底难在哪？不就是写写 testbench、跑跑仿真、收集一下覆盖率吗？说实话，如果只是做一个小 IP 的模块级验证，确实相对单纯。但一旦到了 SoC 级别，光是把整个芯片“跑起来”这件事，就够你喝一壶的。
SoC 之所以叫 SoC，是因为它把 CPU、总线、内存控制器、外设接口、安全模块、电源管理单元等一大堆东西集成在一颗芯片上。这意味着验证工程师面对的不再是一个简单的功能单元，而是一个有着多核、多时钟域、多电源域、复杂互连的“微缩系统”。你要验证的不只是某个模块对不对，而是这些模块组合在一起之后，系统还能不能按预期去启动、运行、响应中断、切换电源状态、处理异常。这也是为什么不管是消费级的主控 SoC，还是车规级、工业级的 SoC，验证周期往往占整个芯片开发周期的一半以上。
这篇手册，就是写给在 SoC 验证这条路上摸爬滚打的同行们看的。不管你是刚接手 SoC 级验证的新人，还是已经写过几年 UVM 平台、准备往 SoC 方向转的工程师，或者是正在做 FPGA 原型验证、需要和验证团队打交道的设计工程师，这篇文章里的内容应该都能给你一些参考。我会尽量多讲一些实操层面的东西，包括验证策略怎么定、验证环境怎么搭、常见问题怎么排查，也会聊一些书里写不到、但实际项目中一定会遇到的“潜规则”。
2. SoC 验证的全局观：策略永远比代码重要
2.1 为什么 SoC 级验证不能照搬模块级那套打法
很多人第一次做 SoC 验证的时候，会很自然地把模块级验证的那套方法搬过来：搭一个基于 UVM 的环境，把接口协议跑通，写一堆 sequence 去激励 DUT，最后收覆盖率。这套东西在 IP 层面确实没问题，但放在 SoC 层面，你会发现一个很尴尬的问题：SoC 的输入激励不应该是“你主动去驱动接口”，而应该是“让芯片自己跑起来”。
举一个很简单的例子，验证一个 SPI 控制器 IP，你可以通过 AHB 接口去配置它的寄存器，然后往 FIFO 里塞数据，观察 MOSI 输出是否符合协议。但在 SoC 层面，这一切的主体应该是 CPU。你需要让 CPU 去执行一段程序，通过总线配置 SPI 寄存器，再由 CPU 发起数据传输。也就是说，SoC 验证的激励源从“外部 testbench”变成了“内部软件”，验证的重点也从“接口时序”变成了“系统行为”。这是一个思维上的巨大转变。
所以，做 SoC 验证，首先要想清楚的不是怎么写代码，而是怎么定策略。这个策略要回答几个问题：验证的重点放哪里？不同的测试场景用什么验证手段去覆盖？跑仿真环境还是跑 FPGA 原型？软件和硬件的验证边界在哪里？这些问题想不清楚，后面的环境搭得再漂亮，也很难真正把 SoC 验证透。
2.2 分层验证策略：从 IP 到系统的三级火箭
业内比较成熟的做法，是把验证分成三个层级：IP 级验证、子系统级验证和 SoC 级验证。这三个层级各有侧重，不能互相替代。
IP 级验证大家都很熟了，重点是把单个 IP 的功能、协议、时序都验透。子系统级验证，是近几年越来越受重视的一层。所谓子系统，一般是指由多个 IP 通过总线或 NoC 组成的一个功能块，比如 GPU 子系统、ISP 子系统、显示子系统、安全子系统等。这一层的价值在于，它可以用比 SoC 级更快的仿真速度，去验证多个 IP 之间的交互逻辑，尤其是总线协议和低功耗接口的正确性。很多 SoC 级才会暴露的毛病，其实在这一层就能抓出来。
SoC 级则负责最终的系统集成和启动验证。到了这一层，仿真速度会很慢，所以测试场景必须精挑细选。一般的做法是，把启动流程、中断响应、DDR 读写、外设访问这些“大场景”放在 SoC 级去跑，而把具体的功能细节下放到 IP 级和子系统级去验证。这个思路很像写软件时的分层测试：单元测试、集成测试、系统测试各司其职，你总不能让每段代码都跑到系统测试那一层才去发现问题。
2.3 覆盖率驱动：闭合覆盖率不是终点，而是起点
覆盖率的提法是值得商榷的地方。很多团队把功能覆盖率、代码覆盖率跑到某个数字（比如 90%）当作验证的终点，好像达到这个数字就可以 sign off 了。但实际上，覆盖率只是一个手段，告诉你“哪些代码执行到了、哪些功能点被刺激到了”，它并不等于“验证通过”。
我在实际项目里见过太多这种情况：功能覆盖率数字很难看，领导很焦虑，于是大家开始写“凑覆盖率”的用例。就是在约束里稍微改一改随机种子，或者加几个反向用例，把那些没打到的仓洞给打过去。数字是好看了，但漏测的问题还是漏在那里。覆盖率的意义，是帮你发现“没想到的场景”，而不是帮你证明“测完了”。正确的做法是，每收集一轮覆盖率，都去逐条审查那些没有覆盖到的点，问一句：“为什么没覆盖到？是环境激励不够，还是这个功能根本不会在这种配置下出现？”如果答案是后者，那这个 coverage hole 是可以接受的，但你要在验证计划里写明原因。
3. 核心验证场景拆解：从启动到互连，再到低功耗
3.1 芯片启动流程验证：SoC 验证的“第一课”
SoC 验证里最基础也最重要的一个场景，就是启动流程验证。你可以把芯片启动理解成一台电脑开机：上电、复位释放、ROM 里的 BootROM 代码开始执行、初始化时钟和 DDR、从外部存储加载引导程序、跳转到应用程序。任何一个环节出问题，整个芯片就“变砖”了，所以这是所有 SoC 验证团队都会最先搭起来的一个场景。
启动验证的难点不在于代码逻辑本身，而在于你必须在仿真中准确地模拟出上电时序。现在的 SoC 通常有很多个电源域，有的域先上电，有的域后上电，期间还要经过多次复位释放和时钟切换。仿真环境里要建模这些时序，一般会用固定延时或者基于真实电源管理芯片模型的激励来驱动。我自己踩过一个坑：仿真里启动测试总是失败，查了整整两天，最后发现是复位信号释放的时间点和时钟稳定之间差了那么几个毫秒，而仿真里的时钟源没有在复位释放前完成稳定。这种问题，如果不把上电时序建模清楚，是极难定位的。
另外要提醒的是，启动验证一定要做到“自动检查”，不能用眼睛去盯波形。判断启动是否成功的标准一般有两个：一是 PC 指针是否跳转到了预期的地址空间，二是某个关键外设（比如 UART）有没有输出预期的打印信息。比较务实的做法是在 testbench 里写一个 watchdog，如果仿真时间超过某个阈值（比如 200ms 仿真时间）PC 还没有跳转到目标地址，就自动报错终止仿真。这样跑回归的时候，才能快速发现启动相关的 regressions。
3.2 系统级总线与互连验证：别让 NoC 成为“黑盒”
总线互连是 SoC 里最容易出问题、也最难排查的地方。不管是传统的 AXI/AHB 总线矩阵，还是近年来越来越流行的 NoC（片上网络），甚至是 TileLink（rocket chip/chisel 生态里常见的 SoC 互连协议）这类开源生态里常用的互连方案，它们在系统里的角色都是“快递公司”：数据包从一个主设备出发，经过若干路由节点，最终到达目标从设备。验证互连，本质上就是在验证这套快递系统在并发、拥塞、异常情况下的表现。
互连验证最核心的手段有两个：协议级断言和定向随机测试。协议级断言，就是通过 protocol checker 实时监测总线上的协议违例，比如 AXI 的 READY 和 VALID 握手规则、burst 是否跨越了边界、写响应通道有没有丢掉响应等。定向随机测试，则是通过随机生成大量不同的传输序列，覆盖不同的主从设备组合、不同的地址范围、不同的 burst 长度、不同的对齐方式，来触发总线上的竞争和仲裁条件。
这里特别想说一下 TileLink。这几年做开源 SoC 的人越来越多了，Rocket Chip、Chipyard 生态里经常能看到 TileLink 的身影。TileLink 比起 AXI 多了一些很有意思的特性，比如它支持 atomic operation 直接在总线层面广播，还支持自定义的 per-agent 权限控制。如果你在用 TileLink，断言验证的重要性会更突出，因为这个协议对一致性的要求非常严格，一旦出现两个主设备同时拿到同一块 cache line 的授权而彼此不知情，后果就很严重。
3.3 低功耗验证：不跑 UPF 的 SoC 验证是不完整的
低功耗验证是 SoC 验证里最容易被低估、也最让新人头疼的一块。我见过不少团队，功能验证跑得风生水起，一提到低功耗验证就说“我们还没有建好 UPF 环境”。但实际上，现在功耗管理基本是所有 SoC 的标配，电源域开关、DVFS、p-state 切换都是 P0 级需求。低功耗验证如果缺席，芯片回来后大概率会碰上莫名其妙的漏电流、唤醒失败、数据丢失这类的问题。
UPF（Unified Power Format）创建电源域和供电状态的过程，听起来很简单，但实际跑起来坑很多。最常见的坑是 isolation cell 的位置和使能时序不对，导致电源关断之后，模块的输出处于不确定状态，把下游的模块给带崩了。这种问题在普通功能仿真里是看不出来的，因为功能仿真默认所有信号都是上电状态。
做低功耗验证的时候，有一个小技巧很实用：在仿真开始之前，先跑一个“power-aware 检查”，把 UPF 文件里声明的每个电源域都遍历一遍，确认开关电源的宏模型都正常工作。另外，低功耗验证的用例不能贪多，关键是覆盖几个核心 scenario：上电顺序、DMS（Dynamic Memory Switch）或 Power Gating 等多种组合下的唤醒序列、以及唤醒过程中的中断响应是否正确。这些场景一旦在仿真里跑通了，芯片回来之后睡下去能醒过来，心里就踏实一大半。
3.4 时钟复位与跨时钟域验证：细枝末节里藏着的“大雷”
时钟和复位，看似是基础中的基础，但每次芯片出问题，概率很高的就是这块。SoC 里通常有几十个时钟域和几百条复位信号，而且很多复位还是异步复位、同步释放的方式。跨时钟域（CDC）这个问题，几乎每个项目都会遇到，但又几乎每个项目都容易在紧张的时间表下被轻视。
跨时钟域问题的本质是，一个信号从一个时钟域传到另一个时钟域时，目标域的触发器可能采到信号的中间态，导致亚稳态。如果这个亚稳态没有被正确同步，就会传播成逻辑错误。验证和检查 CDC 问题的思路，是“预防为主，检查为辅”。目前业内最有效的做法是用专门的 CDC 工具在 RTL 阶段做结构检查和仿真验证。简单来说，就是把所有跨时钟域的路径列出来，逐条确认有没有加同步器、同步器的类型是否合适、有没有经过单bit握手电路，等等。
跨时钟域验证有一个痛苦的地方：如果你自己去写测试用例去“逼出”亚稳态，效率极低，因为亚稳态是一个概率事件。所以我更推荐在实际项目里把重点放在工具的结构检查上，再用仿真验证去配合确认重要的数据跨时钟域路径。也就是说，CDC 验证的本质是“静态检查 + 少量定向仿真”，不要指望靠随机仿真来覆盖这一块。
4. 验证环境与工具选型：如何搭建一套跑得稳、调得快的 SoC 验证环境
4.1 仿真器选型：以团队沉淀和工具成熟度为先
SoC 验证到底选哪家仿真器，这个问题几乎每个新项目都会讨论一轮。商业仿真器像 Synopsys 的 VCS、Cadence 的 Xcelium、Siemens 的 Questa，性能和协议支持通常做得比较好；开源阵营里的 Verilator、Icarus Verilog 这几年进步也很大，特别是 Verilator 在跑大 SoC 的时候，编译出的仿真速度甚至能比部分商业工具快出不少。
我的建议是，选工具不能只看跑分，要看团队已有的验证环境、VIP、脚本流程和员工熟练度。有团队对某个工具的编译报错信息有长期积累的排查经验，换一个新工具可能一开始就能把人搞崩溃。另外，现在很多开源生态里（比如基于 chisel / spinalhdl / tlctl 的 SoC 项目），Verilator 几乎是默认标配，如果你做的是这一类芯片，起步阶段直接用 Verilator 会顺畅很多。关键是把环境提前搭好，做个简单的性能测试，比如跑一个最小的 CPU 启动程序，看看编译时间、仿真速度和 debug 体验是否符合预期。
4.2 UVM 之外：SoC 级验证的软件驱动环境怎么搭
UVM 是模块级、子系统级验证的主流方法论，这一点没什么好争论的。但在 SoC 级，纯 UVM 环境往往会显得笨重，因为你要处理的核心不是“接口激励”，而是“软件程序”。所以，SoC 级验证环境通常采用一种混合架构：用 UVM 管好外部的物理接口（比如 DDR、PCIe、USB），用“虚拟外设”或“后门访问机制”提供 CPU 运行所需的代码和数据，通过软件测试程序去驱动芯片内部逻辑。
拿 DDR 验证举个例子。SoC 里的 CPU 要执行程序，需要先把指令从 Flash 加载到 DDR，或者直接 XIP（就地执行）。仿真环境里当然可以挂一个 DDR 的模型，让 CPU 去初始化 SDRAM 控制器，再完成读写。但这样整个仿真时间会很长。更高效的做法是，用后门方式把测试程序直接写入到仿真的“伪 DDR”里，跳过延时极长的 DDR training 流程，直接让 CPU 取指执行。这一步做好，能为你每天节省好几个小时的仿真时间。
实际上，很多 SoC 验证环境里跑的不是硬件 testbench，而是一个“裸机测试程序”的集合。这些程序被交叉编译成 hex/bin，加载进仿真模型里运行，通过 UART 或者共享内存的方式回报执行结果。这本质上是“软件仿真 + 硬件模型”的 co-simulation 架构，也是现在几乎所有 SoC 验证团队都会使用的方案。如果你所在的团队还没有建立起这样的流程，建议优先考虑。
4.3 回归自动化与持续集成：让验证“无人值守”
SoC 验证用例规模通常很大，一次回归跑几千个测试都是家常便饭。如果没有一套好的回归管理和持续集成（CI）系统，验证团队的日常就会被“手动跑仿真、手动分析失败、再手动重跑”占据，效率低到爆炸。我在这次项目里就把回归系统接到了基础的 CI 平台（无论是自建的 Jenkins 还是 GitLab CI），每次代码提交后自动触发冒烟测试，定期跑全量回归，然后把结果汇总到 Dashboard 上。
做回归自动化的时候有几个细节值得留意。一是失败用例要自动归档波形和日志，这样第二天早上来，你只需要看 Dashboard 上标红的用例，直接点开波形就能定位问题。二是要做失败用例的自动分类，区分是环境挂掉、编译失败还是真正的功能失败。区分环境问题和功能问题，这个能力非常重要，因为 SoC 仿真经常会出现超时、死锁、内存耗尽这类环境问题，如果这些不稳定也统计进失败率，会严重干扰你对代码质量的判断。三是回归报告的稳定性，尽量做到“无白名单机制”，不要允许某些用例一直失败还挂在 CI 里，不然久而久之大家就对失败产生了“审美疲劳”，真正的问题反而被忽略了。
5. 问题排查技巧实录：那些浪费过我几天几夜的问题
5.1 仿真“死锁”与 CPU Hang：先查时钟，再查中断，最后查总线
SoC 仿真里最常见的现象，不是功能输出错误，而是整个仿真卡住不动了，或者在某个断点之后 CPU 不再执行新指令。遇到这种问题，我的排查顺序一般很固定：首先确认时钟还在翻转，没有因为某个门控逻辑被意外关闭导致整个模块停摆；其次确认中断状态，看看是不是有某个 pending 的中断没有被正确处理，把 CPU 困在 ISR 里了；最后再去看总线状态，有没有可能发生了死锁，比如某个 master 在等一个数据响应，而响应永远发不回来。
这里有一个非常实用的技巧：仿真环境里一定要在 CPU 的总线上挂一个“指令追踪”模块，或者至少在仿真日志里周期性地打印 PC 指针。这样 CPU 卡住的时候，你能直接从日志里看到它是停在哪个地址、哪个函数里，而不是去慢慢 debug 波形。没有这个工具的 SoC 验证环境，遇到 CPU hang 问题就是抓瞎，只能一点一点地看信号翻转到怀疑人生。
5.2 复位释放的“隐藏依赖”：为什么测试用例一拍脑袋就变慢
有一次我在验证一个带安全岛的 SoC，发现一个很诡异的现象：同一个中断测试用例，有时 10 秒仿真时间就完成了，有时 50 秒都没跑完。查了很久才发现，问题出在复位释放的“隐藏依赖”上：这个 SoC 的应用程序代码在启动时需要读取安全芯片的哈希值，而安全芯片的上电初始化比其他模块慢得多。如果测试用例在中途引入了某个异步事件，导致安全芯片的初始化晚了一段时间，后续的读操作就会陷入长时间的等待。
这种问题在 UVM 环境里很难发现，因为你需要同时跟踪“软件执行流程”和“硬件模块状态”两条线。排查下来的经验是：遇到仿真时间突然变长的情况，不要只盯着功能正确性，先去看效率——哪一段代码执行的时间异常增加了。方法就是在软件测试用例里加上时间戳打印，记录关键节点的仿真时间。有了这个，你就能一眼看出程序卡在了哪个阶段，再带着这个信息去查硬件状态，命中率高得多。
5.3 覆盖率空洞分析：别急着“凑”，先搞清楚是“不需要”还是“没想到”
功能覆盖率收集完之后，总要面对一堆覆盖空洞。新人最常见的做法是，看到某个功能点没有被覆盖，就飞快地写一个 sequence 去覆盖它。但更专业的做法是，先想清楚这个功能点在当前架构下“应该不应该”被覆盖到。
举个例子，如果 SoC 里的一个 DMA 控制器只支持 32 位寻址，但地址位宽在总线上扩展到了 40 位，那么高 8 位的地址线从来不会置 1，这个仓洞就是“本来就不需要”的情况，不用花时间去填。反过来，如果某个中断源的触发逻辑从来没能被真正触发过，那就得小心了，很可能是环境缺少一个能够真正发起该中断的外部事件模型。你需要在验证计划里注明原因，而不是默默地让覆盖率数字“变好看”。
每次覆盖率分析，我都推荐做一次“覆盖率评审会”，把 RTL 设计师、架构师和验证工程师拉在一起，把覆盖率报告逐条过一遍。这个会可能有点费时间，但价值非常高。设计师往往能一眼看出哪些仓洞是“不可能的”，也能指出哪些仓洞暴露了他们自己心里也没底的功能点。
6. 给验证新人的几句掏心窝的话
写了这么多技术细节，最后想结合自己这些年的经验，给刚入行或者准备往 SoC 验证方向转的朋友们几句建议。
第一句是：不要只做“跑仿真的人”。你要去理解架构、理解设计意图、理解软件的执行流程。很多验证工程师入行头两年，都在写 sequence、跑回归、看覆盖率，技术能力确实在进步，但对芯片整体的理解进步很慢。如果只盯着自己的 testbench，不去看 RTL 里那段难懂的状态机到底想干嘛，那十年后你还是在写 sequence。
第二句是：学会“设计验证环境”，而不仅仅是“使用验证环境”。你会用 UVM，不等于你会搭 UVM 环境。SoC 验证环境的复杂程度远超模块级，很多项目里困难的部分不是测试用例本身，而是环境里的各种组件怎么协同工作。花时间去理解 scoreboard 怎么实现自动比对、reference model 怎么建模、后门访问怎么保证数据一致性，这些能力会在你将来带项目和解决疑难杂症的时候发挥巨大作用。
第三句是：一定要培养“全局排查”的思维方式。SoC 层面的 bug，往往不是你负责的那一小块代码的问题，而是多个模块之间的交互问题。当你定位一个问题时，不要只看着某个信号在那里较劲，要试着顺着数据流去思考：这个信号从哪来？经过了什么模块？被谁消费了？有没有可能是在源头就已经错了，只是传播到这里才显现出来？这种思维习惯，是成为一个合格的 SoC 验证老兵最关键也最难跨越的一步。
最后，SoC 验证这条路确实辛苦，项目紧张的时候经常要连轴转地查 bug、跑回归。但说真的，当你在仿真里看到一个完整的系统从复位中苏醒、CPU 开始跑代码、外设开始响应中断、Linux 系统最终起来的那一刻，那种成就感也是很多其他方向的工作很难带来的。把这个验证老兵的手册整理出来，也算是对自己这些年踩坑和积累的一次回顾。如果里面的哪一段内容能让你在项目里少走几步弯路，那这功夫就没白费。
