2. 覆盖率类型详解：代码覆盖率与功能覆盖率

覆盖率这东西，说白了就是一把尺子。量一量你的验证到底走了多远。很多刚入行的朋友一上来就盯着“覆盖率到没到90%”这个数字，却忽略了最重要的问题——你量对了吗？

我个人习惯把覆盖率分成两大类：代码覆盖率和功能覆盖率。这两者就像开车时的仪表盘和后视镜，缺一不可。今天我们就来把它们掰开揉碎了讲清楚。

2.1 代码覆盖率——EDA工具白送的福利

代码覆盖率是EDA工具自动帮你统计的。你不需要写任何额外的代码，跑完仿真，工具就给你一张报表。听起来很爽对吧？但这里有个坑——代码覆盖率100%不代表你的验证就做完了。

我记得有一次，一个项目的代码覆盖率到了98%，团队都觉得可以tape out了。结果我仔细一看，那个没覆盖到的分支是一个异常处理路径。偏偏就是那个路径，在芯片回来之后被触发了，整批芯片直接报废。嗯，从那以后我再也不敢只看代码覆盖率就拍板了。

2.1.1 行覆盖率

行覆盖率是最基础的。它统计的是：每一行RTL代码有没有被至少执行一次。

// 示例：行覆盖率
always_ff @(posedge clk or negedge rst_n) begin
  if (!rst_n) begin
    cnt <= 0;          // 行1：复位路径
  end else if (en) begin
    cnt <= cnt + 1;    // 行2：使能路径
  end
end
// 如果en从未被拉高，行2的行覆盖率就是0%

2.1.2 分支覆盖率

分支覆盖率看的是if-else、case语句的每个分支有没有被走到。这个比行覆盖率更有价值一些。

// 示例：分支覆盖率
always_comb begin
  case (state)
    2'b00: next_state = 2'b01;   // 分支1
    2'b01: next_state = 2'b10;   // 分支2
    2'b10: next_state = 2'b00;   // 分支3
    default: next_state = 2'b00; // 分支4
  endcase
end
// 如果state从未进入2'b10，分支3的覆盖率就是0%

你想想看，如果case语句有default分支，但你的测试向量从来没触发过default，那说明什么？要么你的设计逻辑有冗余，要么你的测试没覆盖到异常情况。我个人建议，分支覆盖率至少要达到95%以上，剩下的5%要逐条分析原因。

2.1.3 条件覆盖率

条件覆盖率比分支覆盖率更细。它看的是：组合逻辑中每个条件的真/假值有没有都被覆盖到。

// 示例：条件覆盖率
assign ready = valid_a && valid_b && !full;
// 条件覆盖率会统计：
//   valid_a = 0 和 valid_a = 1 是否都出现过
//   valid_b = 0 和 valid_b = 1 是否都出现过
//   full   = 0 和 full   = 1 是否都出现过

这里有个常见的误区。很多人以为分支覆盖率到了，条件覆盖率自然就到了。其实不一定。比如上面的例子，如果valid_a和valid_b始终同时为1，分支覆盖率可能已经100%了，但条件覆盖率中valid_a=0和valid_b=0这两个条件从未被覆盖。

2.1.4 状态机覆盖率

状态机覆盖率是专门针对FSM的。它统计三件事：

• 状态覆盖率：每个状态有没有进入过
• 转移覆盖率：每个状态转移有没有发生过
• 序列覆盖率：连续的状态转移序列有没有出现过

我个人觉得，状态机覆盖率是代码覆盖率中最有价值的一个。为什么？因为状态机往往是设计的核心控制逻辑，一旦状态机跑偏，整个芯片的行为就全乱了。

2.2 功能覆盖率——验证工程师的“自定义尺子”

代码覆盖率是工具白送的，但功能覆盖率得你自己写。说白了，功能覆盖率就是把你脑子里的“设计意图”翻译成机器能理解的语言。

为什么要搞功能覆盖率？我给你讲个真实案例。有一次我验证一个AXI总线桥接模块，代码覆盖率到了99%，但功能覆盖率只有40%。为什么？因为代码覆盖率只关心“代码有没有跑过”，不关心“地址范围、数据对齐、burst长度这些关键参数有没有组合覆盖到”。结果呢？芯片回来后，某个特定的地址对齐+burst长度组合出了问题，直接导致DDR控制器挂死。

2.2.1 covergroup 与 coverpoint

在SystemVerilog里，功能覆盖率通过covergroup和coverpoint来实现。

// 示例：功能覆盖率定义
covergroup fifo_cg @(posedge clk);
  wr_en_cp: coverpoint wr_en;
  rd_en_cp: coverpoint rd_en;
  fifo_level_cp: coverpoint fifo_level {
    bins low    = {[0:15]};    // 低水位
    bins medium = {[16:31]};   // 中水位
    bins high   = {[32:47]};   // 高水位
    bins full   = {48};        // 满
  }
endgroup

fifo_cg cg_inst = new();

你想想看，上面的代码里，fifo_level_cp把FIFO深度分成了4个区间。如果仿真跑完，full这个bin的覆盖率是0%，那就说明你的测试从来没让FIFO满过。这合理吗？如果FIFO满是一个关键边界条件，那你就得补用例。

2.2.2 cross coverage——组合覆盖的利器

单个coverpoint只能看一个信号。但很多bug是多个信号组合在一起才触发的。这时候就需要cross coverage。

// 示例：cross coverage
covergroup axi_cg;
  addr_cp: coverpoint addr_range {
    bins low  = {[0:1_000]};
    bins high = {[1_001:2_000]};
  }
  burst_cp: coverpoint burst_len {
    bins single = {1};
    bins incr4  = {4};
    bins incr8  = {8};
  }
  addr_x_burst: cross addr_cp, burst_cp;
endgroup

这个cross会生成2×3=6个交叉bin。如果某个交叉bin（比如addr=high + burst=incr8）从未被覆盖，那你就得问自己：这个组合在实际场景中会不会出现？如果会，为什么没测到？

2.2.3 transition bins——时序相关的覆盖

有些场景下，你不仅关心某个信号的值，还关心它的变化过程。比如，状态机从IDLE跳到WAIT，再跳到DONE，这个序列有没有出现过？

// 示例：transition bins
coverpoint state {
  bins idle_to_wait = (IDLE => WAIT);
  bins wait_to_done = (WAIT => DONE);
  bins done_to_idle = (DONE => IDLE);
  bins illegal_seq  = (IDLE => DONE); // 非法跳转
}

transition bins特别适合用来验证协议时序。比如AHB总线的传输序列、握手信号的assert/deassert顺序等等。我曾经用transition bins抓到一个很隐蔽的bug——DMA控制器在特定条件下会跳过中间状态，直接进入完成状态。这个bug在代码覆盖率里完全看不出来，因为每个状态都跑过，但转移序列错了。

2.3 代码覆盖率 vs 功能覆盖率——怎么配合？

很多团队喜欢定一个硬性指标：代码覆盖率≥90%，功能覆盖率≥95%。但我觉得，数字是死的，逻辑是活的。关键不是数字，而是未覆盖的原因分析。

我一般这样操作：

1. 先跑代码覆盖率，快速定位“哪些代码从来没被执行过”。
2. 分析未覆盖原因：是测试用例没写？还是代码是冗余的？还是设计有dead code？
3. 再跑功能覆盖率，看“设计意图有没有被完整覆盖”。
4. 交叉对比：功能覆盖率低的地方，代码覆盖率往往也不高。反过来，代码覆盖率高的地方，功能覆盖率不一定高。

好了，这一章的内容就到这里。记住：代码覆盖率是基础，功能覆盖率是灵魂。两者配合使用，才能让你的验证真正“覆盖到位”。