2. 代码覆盖率详解：行覆盖率、分支覆盖率、条件覆盖率、翻转覆盖率、状态机覆盖率

代码覆盖率，说白了就是验证工作的「体检报告」。你写了那么多测试用例，到底有没有把设计代码的每个角落都跑到？我见过不少团队，仿真跑了几百万次，结果一查覆盖率，关键逻辑根本没动过。嗯，今天我们就来把这五种覆盖率掰开揉碎讲清楚。

2.1 行覆盖率（Line Coverage）

行覆盖率是最基础的一种。它统计的是：每一行代码，有没有被执行到。

举个例子：

always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
        cnt <= '0;
    end else if (en) begin
        cnt <= cnt + 1;
    end
end

如果测试用例从来没让 en 拉高过，那 cnt <= cnt + 1 这一行就是 0% 覆盖率。行覆盖率的目标是 100%，但别高兴太早——它只能告诉你「这行跑了」，不能告诉你「这行跑对了」。

2.2 分支覆盖率（Branch Coverage）

分支覆盖率看的是条件判断的每个分支有没有被走到。比如 if-else、case 语句。

always_comb begin
    case (state)
        2'b00: next_state = 2'b01;
        2'b01: next_state = 2'b10;
        2'b10: next_state = 2'b00;
        default: next_state = 2'b00;
    endcase
end

这里一共有 4 个分支。如果测试用例只覆盖了 2'b00 和 2'b01，那分支覆盖率只有 50%。

2.3 条件覆盖率（Condition Coverage）

条件覆盖率比分支覆盖率更细。它看的是每个条件表达式里的子条件，有没有取到 0 和 1 两种值。

比如：

if (a && b) begin
    // do something
end

分支覆盖率只关心 a && b 整体为真或假。但条件覆盖率要求：a 必须取过 0 和 1，b 也必须取过 0 和 1。

你想想看，如果 a 一直是 1，b 一直是 0，分支覆盖率可能是 100%（因为条件为假），但条件覆盖率只有 50%。

2.4 翻转覆盖率（Toggle Coverage）

翻转覆盖率统计的是：每个信号有没有从 0 翻到 1，再从 1 翻到 0。

我个人习惯把翻转覆盖率当作「信号活跃度」的指标。如果一个信号从来没翻转，那它要么是死信号，要么是测试没跑到。

信号	0→1	1→0	覆盖率
clk	✓	✓	100%
data_valid	✓	✗	50%
error_flag	✗	✗	0%

你看，error_flag 从来没翻转过。这说明要么错误场景没测到，要么这个信号根本没用上。

2.5 状态机覆盖率（FSM Coverage）

状态机覆盖率是专门针对有限状态机的。它包含三个维度：

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

举个例子，一个简单的状态机：

IDLE → READ → WRITE → IDLE

如果测试用例只跑了 IDLE → READ → IDLE，那 WRITE 状态就没进过，转移覆盖率只有 50%。

2.6 五种覆盖率的对比与选择

这五种覆盖率不是互相替代的，而是互补的。我一般这样用：

• 行覆盖率： 快速检查，看代码有没有跑通
• 分支覆盖率： 核心指标，必须 100%
• 条件覆盖率： 复杂逻辑的深度检查
• 翻转覆盖率： 信号活跃度监控
• 状态机覆盖率： 控制逻辑的专项检查

好了，这五种覆盖率就是代码覆盖率的全部内容。实际项目中，我建议你先跑行覆盖率和分支覆盖率，把基础打牢。然后再根据设计复杂度，决定要不要加条件覆盖率和状态机覆盖率。翻转覆盖率嘛，我一般留到最后做信号完整性检查时用。