代码覆盖率与功能覆盖率：line/cond/toggle/FSM 与 covergroup 收敛

更新时间：2026-09-14。本文是「集成电路大类 · 芯片设计 · 数字验证」实操序列第四篇。前三篇有了自检 TB、随机激励、断言，但还缺一个问题的答案：怎么知道测够了没有？ 覆盖率（coverage）就是验证完成度的度量，也是覆盖率驱动验证（CDV）闭环的最后一块。

本文要回答的问题

代码覆盖率和功能覆盖率量的是两件什么不同的事？
line/condition/toggle/FSM 各自能发现什么、发现不了什么？
covergroup 的 coverpoint/bins/cross 怎么定义「功能空间」？
为什么 100% 代码覆盖率也不能签核，覆盖率空洞怎么收敛？

一、两种覆盖率：实现视角 vs 规格视角

bash

代码覆盖率（code coverage）：以 RTL 代码为参照，工具自动统计
   回答「我写的代码有多少被执行/翻转/走过」
   → 度量的是【实现】，不需要人定义，但 100% 也可能漏掉规格功能

功能覆盖率（functional coverage）：以验证计划/规格为参照，人来定义
   回答「规格里的各种场景组合有没有被随机到」
   → 度量的是【意图】，能发现「代码全跑到了，但某个关键组合从没出现」

二者必须配合：代码覆盖率告诉你「有没有白写/没走到的分支」，功能覆盖率告诉你「计划要测的场景是否真发生」。只有代码覆盖率，可能漏掉规格本身；只有功能覆盖率，可能漏掉 RTL 里多写出来的冗余/死逻辑。

二、代码覆盖率的五个常见指标

工具编译时插桩，回归后自动产出，无需改 RTL：

指标	统计什么	低命中通常意味着
line（语句）	每行是否执行	某分支/异常路径从没进过
condition（条件）	布尔条件中每个原子项取过真/假	如 `a&&b` 里 b 从未为真
expression/toggle（翻转）	信号每位 0→1、1→0 是否都发生	某数据位恒为 0，高位从没用到
branch（分支）	if/case 各出口都走过	else/default 分支没测
FSM（状态机）	每个状态到达、每条合法弧走过	某状态/跳转没进过

要点：

toggle 覆盖常暴露位宽虚高、地址高位没接全、错误通路没触发；
FSM 覆盖看的是「状态 + 迁移弧」，到达某状态不等于走过所有进入/离开它的弧；
现代工具还有「有限完备覆盖」等更细指标，但这五类是签核报告标配。

三、功能覆盖率：covergroup 定义功能空间

功能覆盖率由你在 testbench/monitor 里采样「事务」并落桶（bin）统计。核心结构：

systemverilog

class fifo_cov;
  logic [7:0] data;
  typedef enum {OP_WR, OP_RD} op_t;
  op_t op;
  bit   full, empty;

  covergroup cg_fifo @(posedge vif.clk);
    cp_op:   coverpoint op;                       // 读/写两类都要出现

    cp_level: coverpoint vif.usedw {              // 水位分桶
      bins empty = {0};
      bins low   = {[1:7]};
      bins mid   = {[8:8]};
      bins high  = {[9:15]};
      bins full  = {16};
    }

    cp_data: coverpoint data {
      bins zero = {8'h00};
      bins ff   = {8'hFF};
      bins rest = default;
    }

    // 交叉：满时写、空时读这类危险组合必须被测到
    x_op_flag: cross op, full, empty;
  endgroup
endclass

关键概念：

coverpoint：对一个变量/表达式的取值空间打点；
bins：把取值划分成有名字的桶，default 兜底；
cross：多个 coverpoint 的笛卡尔积组合，专门捕捉「单字段都测过、但组合从没出现」的空洞；
illegal_bins：出现即报错（规格禁止的情形，等价于一个检查）；
ignore_bins：从统计中排除（无意义组合，避免永远无法 100%）；
option.at_least：一个桶至少命中几次才算覆盖（1 次往往太偶然）。

covergroup 通常挂在 monitor 观察到的真实事务上采样（而不是激励端「我发了什么」），因为要统计的是 DUT 实际经历的行为。

四、为什么 100% 代码覆盖率不能签核

举三个反例：

规格功能压根没写进 RTL：某状态从来不存在，代码自然 100% 执行，但缺功能——只有功能覆盖率/验证计划能发现。
数据相关 bug 没被组合击中：乘法器每一行都执行了（line 100%），但没随机到「两个输入都触发进位边界」的组合，结果错误未暴露——需要 cross / 定向边界。
覆盖的是「跑过」不是「查对」：某分支执行了，但没有 checker/scoreboard 验证其输出对错，覆盖了也白覆盖。

因此签核语言通常是：代码覆盖率达标（如 line/toggle/FSM 接近 100%，condition 有评审后的豁免）+ 功能覆盖率 100% + 断言充分且无 vacuous + 所有检查器通过，四者合起来才叫「验证收敛」。

五、覆盖率收敛（coverage closure）流程

bash

1. 先写验证计划（verification plan）：列出要测的功能点/场景/组合
2. 随机回归跑大量 seed，merge 所有 run 的覆盖率
3. 看空洞（coverage holes）：哪些 bin / cross / 分支是 0
4. 针对空洞行动：
    - 约束没随机构造成 → 调 dist/权重、加定向约束、加 scenario
    - 该场景本就不可能   → 写 ignore_bins / 排除，但要评审留档
    - RTL 死逻辑/冗余   → 提设计 issue 或删除
5. 重跑、再 merge，直到达标且剩余空洞都有书面 waiver

要点：

merge：成百上千个 seed 各产一份覆盖，必须合并成全项目视图才能判断整体进度；
waiver/exclusion 不能随便点：排除某个未覆盖分支要写明「为什么不可能/为什么不测」，经设计和验证双签，否则就是掩耳盗铃；
覆盖率是反馈给随机约束的：某 cross 总为 0，就回到 CRV 调分布，而不是硬写一堆定向用例；
覆盖率数字会随 RTL 改动变化，应进回归看板按模块跟踪趋势。

六、覆盖率检查清单

[ ] 先有验证计划，功能覆盖点可回溯到规格条款；
[ ] line/branch/condition/toggle/FSM 五类代码覆盖都开启并 merge；
[ ] coverpoint 分桶有边界值（0、满、最大、最小）而非只看 default；
[ ] 关键危险组合用 cross 覆盖（满写、空读、背靠背、反压中发数）；
[ ] 禁止情形用 illegal_bins，不可能组合用 ignore_bins 且评审；
[ ] 关键 bin 设 at_least，避免一次偶然命中算过；
[ ] 功能覆盖在 monitor 端按真实事务采样；
[ ] 未达标的空洞都有定向/约束动作或书面 waiver，无静默忽略。

总结

覆盖率分两类：代码覆盖率（line/condition/toggle/branch/FSM）由工具自动度量「RTL 实现被执行/翻转/走过多少」，功能覆盖率由验证工程师用 covergroup 的 coverpoint、bins、cross、illegal/ignore_bins 按验证计划度量「规格场景与关键组合有没有真实发生」；100% 代码覆盖既不能证明规格功能存在、也不能证明输出被查对，所以签核要靠「随机回归 → 合并覆盖率 → 分析空洞 → 反调约束/加定向/评审 waiver → 再合并」的收敛闭环，让代码覆盖、功能覆盖、断言、检查器同时达标。

入门

进阶

专家

代码覆盖率与功能覆盖率：line/cond/toggle/FSM 与 covergroup 收敛 ​

本文要回答的问题 ​

一、两种覆盖率：实现视角 vs 规格视角 ​

二、代码覆盖率的五个常见指标 ​

三、功能覆盖率：covergroup 定义功能空间 ​

四、为什么 100% 代码覆盖率不能签核 ​

五、覆盖率收敛（coverage closure）流程 ​

六、覆盖率检查清单 ​

相关与延伸 ​

总结 ​