覆盖率收敛流程：覆盖率收集、合并、空洞分析与 sign-off
更新时间：2026-09-24。验证进阶。覆盖率两个基本类型见 代码/功能覆盖率，约束随机的写法见 约束随机验证 CRV，断言的写法见 SVA 断言实践，自动化跑 seed 的基础设施见 回归测试自动化。
一个中规模模块的验证环境里，每晚回归可能跑出几百到几千个 seed，每个 seed 各自吐一份覆盖率数据库。这么多数据堆在一起，不代表验证在收敛——只有当你能回答「现在还缺什么场景、为什么缺、下一条激励该怎么补」，覆盖率才真正变成了导航工具。覆盖率收敛流程（coverage closure）就是把「跑回归」变成「定向消灭缺口」的一整套循环动作：收集、合并、找空洞（coverage hole）、补测试、评审，直到达到 sign-off 判据。
本文要回答的问题
- code、functional、assertion 三类覆盖率分别回答什么问题，为什么三类都要有？
- 成百上千个 seed 的覆盖率数据库怎么收集与 merge，合并时哪些坑会让数字失真？
- 找到未命中的 bin 之后，怎么判断空洞是「没跑到」「不可达」还是「采样写错了」？
- 按覆盖缺口补测试时，调随机约束、写定向用例、用 coverage rank，各自用在什么场合？
- 覆盖率评审看什么，sign-off 的判据是什么，waiver 怎么留才算合规？
- 数字刷到 100% 为什么仍然可能漏 bug，怎么避免「刷覆盖率」？
一、先认清三类覆盖率
收敛之前先要知道自己在合并什么。业界把覆盖率分成三大族，各自度量不同的东西，任何一族都不能单独代表验证完备性。
| 覆盖率类型 | 归属 | 回答的问题 | 典型空洞 | 能证明正确性吗 |
|---|---|---|---|---|
| line（行） | code | RTL 这行执行过没有 | 复位分支、错误处理分支没跑过 | 否，只证明跑过 |
| toggle（翻转） | code | 每个信号 0→1、1→0 都发生过没有 | 配置位固定没动过、恒值总线 | 否 |
| condition（条件） | code | 布尔表达式里每个操作数取过真/假没有 | a && b 中 b 从未为假 | 否 |
| branch（分支） | code | if/case 的每条出路走过没有 | else 分支、case default 缺失 | 否 |
| FSM（状态机） | code | 每个状态、每条状态迁移走过没有 | 异常态、错误恢复迁移没走 | 否 |
| functional（covergroup/bin/cross） | functional | 规格关心的场景和组合发生过没有 | 关键 cross 组合、边界值缺 bin | 否 |
| assertion（assert/cover property） | assertion | 规定的性质被挑战/覆盖过没有 | 性质 vacuous pass、antecedent 从未成立 | assert 能查错，cover 只证明跑过 |
读这张表有两个要点。第一，code coverage 是实现视角——它以 RTL 代码为标尺，代码没写的功能它永远测不出「缺失」；functional coverage 是规格视角——covergroup 里的 bin 和 cross 是验证工程师按协议、按微架构结构人为定义的，规格理解错了，bin 定义错了，100% 也毫无意义。第二，assertion 里要区分 assert property 和 cover property：前者是 checker，违例直接报错；后者只统计时序场景是否发生，本质上是一份写在 SVA 里的功能覆盖率。还必须警惕 vacuous pass（空过）：蕴含算子 a |-> b 在 antecedent a 从未成立时永远算通过——性质没被真正挑战过，这本身就是空洞。
二、收集与合并：从单个 seed 到全模块视图
每个 seed 的仿真在结束时把命中信息写进自己的覆盖率数据库（代码覆盖由仿真器插桩自动产出，功能覆盖来自 covergroup 采样，断言覆盖来自 SVA 引擎）。单看任何一份都没有意义：随机激励下 seed 之间差异很大，某个 bin 可能在第 317 号 seed 才第一次命中。收敛流程的第一步是把全回归的数据库 merge 成一份全模块、可逐层下钻的合并视图：模块级 → 文件/实例 → covergroup/cross → 具体 bin，每一层都能列出命中次数与未命中项。
合并有几个工程细节必须做对，否则后面分析的全是假数据：
- 版本对齐：合入的数据库必须来自同一版 RTL 和同一版验证环境。RTL 改了行号、covergroup 增删了 bin，旧库与新库的 merge 结果会错位或被静默丢弃，所以通常以某次回归的统一 build 为合并边界；
- 种子去重与分层：冒烟、夜间全量、周回归各有合并视图，日常看增量视图，评审看累积视图，避免被几千个低价值 seed 的噪声淹没；
- test-specific 覆盖隔离：某些定向测试只服务于特定场景，混在主视图里会掩盖随机回归的真实盲区，需要按 test 打标签分别统计。
合并完成后，整个收敛闭环就可以转起来了。下图画出从回归到 sign-off 的完整回路。
读图抓住那条回头线：补完激励不是终点，必须回到回归重新跑、重新 merge，确认目标 bin 真的被命中、且没有破坏既有覆盖，回路才算闭合一次。向右的分支是给「逻辑上不可达」的空洞走豁免评审用的——豁免被驳回，同样回到补激励环节。现实中这个回路通常要转五六轮到十几轮。
三、coverage hole 分析：空洞只有三种成因
拿到未命中清单后，最忌讳的反应是立刻加 seed、加用例。先对每一个空洞问一句「它为什么没被命中」。答案只有三类。
| 成因 | 现象 | 判据 | 处理动作 |
|---|---|---|---|
| 激励没探到 | 场景合法，但随机分布没取到或概率极低 | 读约束与 dist，理论可达但期望命中次数极低 | 调 dist 权重/加约束、写定向用例 |
| 设计不可达 | 该路径在当前配置/架构下逻辑上不可能 | 结合 RTL 与规格推导，其他配置位互锁 | 写明理由，exclusion/waiver 双签 |
| 采样/checker 错 | 场景明明发生却没采到，或根本没发生却显示命中 | 波形里事件存在但 bin 未增 | 修 covergroup 采样事件与触发条件 |
第一种最常见。典型例子：一个 4 位长度字段配合一个 back-to-back 连续传输使能位，长度=15 且连续传输的组合合法，但长度均匀随机时期望值是 1/16、使能位又只有 50% 概率打开，组合概率 1/32，跑 50 个 seed 都可能一次不出现。这不是 bug，是激励分布的问题。
第二种要特别小心。有些代码行确实不可达——比如某配置为该型号芯片硬连关闭后，对应的配置分支永远不会进；复位值互锁的两个状态之间也不存在迁移。但「看起来不可达」和「证明不可达」是两回事：必须翻 RTL、查参数、必要时请设计者确认，留下推导依据。随手 waiver 是漏测最常见的出口。
第三种是验证环境自身的 bug。比如 covergroup 的采样事件挂在了 @(posedge clk) 而不是协议规定的响应握手沿，事件确实在波形上发生，bin 却一动不动；反过来，采样条件写得比规格宽，也会出现「场景没真正发生却计了命中」的假达标。所以分析空洞时波形和 bin 计数必须对得上，对不上先修环境，不要去补激励。
再举一个 FSM 空洞的真实样子。某协议模块有 IDLE、REQ、DATA、RESP、ERROR 五个状态，code coverage 报告状态迁移表里唯独缺 ERROR → IDLE。波形翻遍回归也找不到：随机激励里错误响应出现过，状态也进了 ERROR，但之后总是带着新请求直接转去 REQ。读 RTL 才发现，ERROR → IDLE 要求错误响应后总线连续两个周期空闲，而默认序列在错误后立刻补发请求，这个恢复窗口从来没出现过。它既不是不可达，也不是采样错，就是激励的时序习惯把洞挡住了——一条「错误后强制空闲两拍」的约束即可补上。这类空洞在单维覆盖率里完全隐身，只有 FSM 迁移表和 cross 能把它照出来。
分析时还有个优先级原则：先看高价值空洞——关键 cross（如突发类型 × 响应类型 × 是否连续）、边界 bin（长度 0、最大长度）、异常与恢复路径（错误态 → 正常态的迁移）；整体百分比最后看。整体 98% 但缺的是唯一一组会触发死锁的组合，和缺一个无关紧要的状态迁移，价值完全不同。排优先级时可以粗算一笔账：每个空洞需要多少工作量（改一行权重还是写三天定向序列）、覆盖后能带动多少相关 bin 一起命中、对应的设计路径风险有多高，先做「成本低、带动大、风险高」交集里的洞，尾部零散低风险点留到平台期统一收尾。
四、按缺口补测试：调约束、定向与 coverage rank
确定空洞是「没探到」之后，补法也分三档，按成本从低到高选。
第一档：调随机分布与约束。 能用 CRV 解决的不要写定向——定向用例只覆盖一条固定路径，而调好的约束在后续每个 seed 里持续生效。典型操作是给边界值加权：length dist {0 := 20, [1:14] := 1, 15 := 20}，让两端值的出现概率抬到和整个中段相当；或者把相关字段约束成配套出现（使能连续传输时强制长度取边界值）。改完约束要留意副作用：权重过度倾斜会让中段场景被饿死，所以约束变更前后都要看整体 bin 分布，而不是只盯目标 bin。
第二档：定向用例（directed test）。 适合需要精确多步序列、随机几乎不可能自然拼出的场景——比如「填满 FIFO 后连续收到三次错误响应再恢复」。定向用例的价值是确定命中，缺点是不产生探索性，且维护成本高，所以只用来补随机激励的死角。
第三档：coverage rank（覆盖排名/反推激励）。 高级覆盖率工具可以针对某个未覆盖点，结合 RTL 的可达性分析反推出「命中它所需的最短激励条件」，甚至直接生成建议的种子或序列。当剩余空洞只剩几十个、且分散在深控制逻辑里时，手工推导前置条件很慢，coverage rank 能把补点从「猜序列」变成「按方抓药」，是收敛末期提效最明显的手段。但它给的是入口条件，场景的正确性仍然要靠 checker 兜底。
无论哪一档，补完都必须回到第二节的闭环：重跑、merge、确认目标 bin 命中、确认没有覆盖率回退。
五、收敛曲线、评审与 sign-off 判据
把每一轮回归的累积覆盖率画出来，形状几乎总是同一条曲线：开头陡升，中间靠补洞一阶一阶抬，尾部进入平台期。读懂这条曲线比记住数字更重要。
这张图对应一个重要判据：进入平台期后，新增 seed 的边际收益趋近于零，此时该做的是逐块分析剩余项，而不是继续堆机器时间。阶段 A 靠加 seed，阶段 B 靠分析，阶段 C 靠评审和决策——三个阶段用错动作，项目就会在尾部无限拖延。
覆盖率评审（coverage review）通常由验证负责人主持、设计者参加，逐模块过四件事：
- 目标核对：functional coverage 对可达 bin 一般要求 100%；code coverage 按项目定门槛（line/branch 常见 95%~99%，FSM 迁移、关键条件更严），且看的是分模块数字而非全芯片平均值；
- 剩余空洞过堂：每一个未命中项现场归类，难达场景决定补定向还是调约束，不可达项决定是否豁免；
- waiver 双签：每条豁免必须写明具体项、不可达的推导依据、影响评估，由设计和验证双方签字并记录在案， waiver 有有效期，严禁「先豁免以后再看」；
- checker 复核：确认已覆盖场景同时有 scoreboard、assertion 或参考模型在检查结果，而不只是有激励跑过。
闸门全绿才算 sign-off：目标达到、豁免全部双签留痕、关键协议性质无 vacuous pass、无未关闭的 checker 漏洞。覆盖率数据库和 waiver 清单本身也是交付物，流片后出问题时要回溯「这个场景当时到底测没测」。
六、避免刷覆盖率：覆盖率只证明「跑过」
最后一节讲收敛流程最容易走偏的地方。覆盖率是观测「有没有跑到」的工具，它从来不检查「跑到的结果对不对」。一个没有 scoreboard、没有有效断言的环境，照样可以刷到 100%——所有 bin 都命中了，设计把数据算错也没人拦。因此「覆盖率高」只是签核的必要条件，正确性仍然由 checker 体系保证。
实践中几种典型的刷法都要在评审中识破：
- 为命中而命中：写一堆只翻动信号、不走真实数据流的用例，数字好看但不验证任何规格；
- 放宽 bin 定义：把 cross 拆成单维 coverpoint、把边界 bin 并进大区间，用「改分母」制造达标；
- ** waiver 放水**：不经可达性分析整批豁免，把未知风险直接带进流片；
- 只盯总数：全芯片平均 97%，某个关键子模块只有 80%，被平均值掩盖；
- 忽视 checker 缺口：bin 命中了，但该路径上没有任何检查，等于闭着眼睛跑了一遍。
反过来，健康的收敛文化有三个标志：每个未命中项都有人能说清成因；覆盖率模型和规格、checker 一起评审、一起演进；补激励的动作总是由具体空洞驱动，而不是由「还差几个点」驱动。
这一篇在知识体系里的位置
本篇属于验证进阶的「度量与签核」环节，回答「怎么知道验证快做完了、怎么证明做完了」。前置基础是 代码/功能覆盖率 的概念与 covergroup 写法，激励侧依赖 约束随机验证 CRV，性质检查依赖 SVA 断言实践 与 bind 与覆盖方法；回路里的每一轮都跑在 回归测试自动化 之上。同主题还可对照 UVM 视角的 UVM 覆盖率收敛与签核，lint 领域「违例分级 + waiver 双签」的处理哲学见 lint 检查与 waiver 签核。再往后走，就是形式验证补随机死角、门级仿真确认网覆盖，以及 emulation 上的系统级场景覆盖。
总结
一句话总结：覆盖率收敛流程是「多 seed 回归收集 code/functional/assertion 三类覆盖 → 按统一 build merge 成可下钻视图 → 逐 bin 定位 coverage hole 并按『没探到/不可达/采样错』三类归因 → 分别用调 dist 约束、写定向用例、coverage rank 或修采样点处理，不可达项走双签 waiver → 重跑回归确认命中」的闭合循环；读收敛曲线要分清陡升期靠加 seed、攻坚期靠分析、平台期靠评审，sign-off 必须同时满足覆盖率目标、豁免全部留痕和 checker 完备；最重要的一条红线是覆盖率只证明「跑过」、不证明「跑对」，为数字而写用例、改 bin 定义、批量 waiver 都是刷覆盖率，真正驱动收敛的永远是具体空洞而不是差几个百分点。