5.1 功能验证：testbench、覆盖率与断言

5.1 功能验证：testbench、覆盖率与断言

第四章的代码要在本章接受拷问，第一轮是功能验证：证明 RTL 在所有约定场景下行为与规格一致。本节讲三件事——测试平台怎么搭、随机激励怎么受控、收敛怎么度量——并以 CK770 抓获"八位计数器溢出"的全过程做实战演示。读完本节，你应当能为一个模块或一颗芯片写出验证计划，并知道"验证做完了"这句话拿什么数字支撑。

验证是工程里的检察系统

先立观念：验证的目标不是"找几个 bug"，而是产生"符合规格"的证据。设计代码是被告，规格是法条，测试平台是检察机关——它要主动构造场景、收集证据、并在结案报告里给出可核查的数字。立场摆对，很多决策自然清晰：为什么覆盖率比"测了多久"重要？因为证据要看覆盖面，不看工时；为什么随机激励比手写序列强？因为检察官不该只查自己想到的罪行。

测试平台的骨架是一圈"围绕设计的替身系统"：激励生成器冒充外界（总线主设备、传感器、对端接口），监视器旁观设计的一切对外行为，记分板对照规格逐拍核对响应，覆盖率收集器记录"哪些场景被测过"。这套结构本身不难，难的是三个仪表的用法。

受控随机：激励由约束随机生成，约束把随机性框在合法空间里——地址必须落在映射窗口、事务长度必须符合协议、异常场景按权重注入。纯手写序列测广度不足，纯随机会浪费在无效空间，受控随机两者兼顾。断言：把规格里的不变量写成随时站岗的机器可检查命题——"写请求发出后，未收到应答前不得发出第二个请求"。断言的妙处是全天候：不依赖某个用例"恰好"经过，任何激励踩到违规瞬间报警。覆盖率：把"测够了没有"量化成代码覆盖率（每一行、每一个分支执行过没有）与功能覆盖率（规格定义的场景空间被踩过多少）两类，收敛就是让两个数字到线。

图：功能验证的闭环与两个收敛仪表

这张闭环图的精髓在"反哺"那条线：覆盖率没到线，动作不是"再跑久一点"，而是回头改约束、补场景——让随机性去够没踩过的角落。机械地跑同一个环境等天数凑数，是覆盖率驱动方法最常见的误用。

方法框架的工程化理解

UVM 这类通用验证方法学，剥开术语后是三句话：用面向对象把测试平台做成可继承的部件库（换配置不改骨架）；用工厂机制让用例可以在运行期替换部件（同一环境跑千百种场景）；用相位机制统一平台的生命周期（建环境、复位、跑激励、收报告各就各位）。工程判断因此可以朴素化：UVM 的价值随被测对象的规模与复用需求增长。单模块验证，轻量平台加断言常常更快；芯片级与多项目复用的环境，UVM 的结构投资才回本。CK770 的选择是模块级轻量、系统级 UVM，两侧各得其所——"全都要上重型框架"和"框架无用论"都是没算账的说法。

断言之外，形式验证值得一提：对状态机等价、协议不变量、安全启动这类"有限状态、逻辑严密"的目标，数学证明可以给出穷举级的结论。它的适用面窄（状态空间会爆炸），但在窄适用面内是无敌的——第八章的安全启动链就是它的主场。仿真与形式不是竞争关系，是不同案卷用不同侦破手段。

案例复盘：八位计数器的落网记录

背景：4.2 节埋的那颗雷在此收网。CK770 的采集模块里有一个八位帧计数器，编码评审时位宽纪律的遗漏没被抓住，功能验证初期也一片绿——采集负载低，帧数远远到不了二百五十六的上限。

操作。 收敛阶段，验证工程师按规格写功能覆盖率点：帧计数"达到上限、回卷、清零"三个场景被列为必测点。约束随机把采集压力调到持续满载后，计数器在一分多钟的仿真时间里自然回卷——记分板当场抓到异常：回卷后的帧序号与下游核对值错位，且错位幅度随时间扩大。接着定位根因：计数器位宽八位，而规格要求的帧序号空间是十位。修复动作有两层：位宽扩到十位并参数化（4.2 节位宽显式纪律的补课），同时给"回卷行为"补了一条断言——序号必须单调递增、清零必须发生在复位或显式命令时，让这类问题今后在任何用例里都当场报警。

结果。 修复后满载压力跑通，三个覆盖点全绿。复盘时团队核对了一条冷数据：这个缺陷从编码引入到落网，间隔了三周——期间它通过了功能冒烟、单元自测与两轮集成测试。它最终落网的功臣不是某个聪明用例，而是把规格里的边界条件翻译成了覆盖点这个机械动作。

解读。 这单案例是覆盖率价值的最佳注脚：缺陷不在"跑得多的地方"，在"规格的角落里"。三周潜伏期还说明另一件事——验证的绿不等于对，只等于"已测场景下对"；没有覆盖点度量场景空间的广度，绿就只是错觉。给实践者的清单式建议：把每条规格的边界值、每个状态机的每条转移边、每个计数器的回卷行为，逐一翻译成覆盖点——这份翻译工作枯燥，却是验证计划里含金量最高的部分。

变式。若缺陷藏在多模块交互里（计数器本身没错，错在下游对序号的假设），覆盖点就要升维到事务级：定义"序号交接"这个跨模块场景的覆盖点，而不是各自模块的局部覆盖。若系统的状态空间大到覆盖点也列不全（网络协议类），该切换到形式验证守不变量加随机仿真探广度的双轨制——手段升级的信号永远是"场景空间的结构变了"。

常见问题辨析

问：代码覆盖率已经百分之百了，为什么功能覆盖率还差得远？

两类覆盖率度量的空间不同。代码覆盖率保证"每一行可执行代码被某条路径执行过"，但一行代码在错误场景下执行与在正确场景下执行，得分相同——它度量不了"场景的意图空间"。功能覆盖率是按规格定义的场景清单（状态组合、事务类型、边界条件）逐项打勾，它才回答"该测的行为空间测了多少"。实践中的正确姿势是双表对照：功能覆盖点驱动场景设计，代码覆盖率兜底查漏——功能表里漏写的规格角落，常能从"代码被执行过但功能点未覆盖"的错位里挖出来。

问：断言铺得太多，会不会把仿真拖到跑不动？

会，所以断言也有预算管理。断言的开销差异极大：简单的寄存器关系检查近乎免费，跨周期时窗、全总线扫描类的重断言可能吃掉可观性能。工程做法是分级——模块级验证开全量断言（仿真短，吃得起）；系统级与回归只留轻量级与历史出过事的重点断言，重断言在夜间专项轮次集中跑。CK770 的经验数字是断言集合控制在仿真时间的百分之十开销以内，超线即评估合并或降级。断言的收益是"违例瞬时报警"，为了这点收益把回归拖成过夜跑不完，就得不偿失了。

本节要点回顾

• 验证的目标是产生符合规格的证据，覆盖率是证据的度量，"测了多久"不是。
• 测试平台四件套——激励、监视、记分板、覆盖收集——加上断言全天候站岗，构成验证闭环。
• 覆盖率没到线的正确动作是反哺约束与场景，不是延长运行时间。
• UVM 的价值随规模与复用需求增长，按项目算账选择轻重；有限状态的目标可交给形式验证穷举。

功能证据到位后，还有两道坎：仿真速度撑不起全流程验证时怎么办，以及门级网表要不要再验一遍。下一节给出平台谱系的完整答案。