📚 课程目录第1章覆盖率基础概念

1. 覆盖率基础概念：什么是覆盖率？为什么需要覆盖率？覆盖率在验证流程中的位置。

各位同学，咱们今天聊点实在的。做芯片验证这么多年，我见过太多人一上来就闷头写 testbench、跑仿真，结果项目快结束了才发现——某个关键功能压根没测到。嗯，这就是典型的「验证盲区」。

覆盖率，说白了就是一把尺子。它告诉你：你的验证工作到底做够了没有？

覆盖率，是衡量验证完备性的量化指标。它回答一个核心问题：设计中的哪些行为已经被我们验证过了？

我个人习惯把覆盖率分成两大类：

类别	定义	典型指标
代码覆盖率	衡量 RTL 代码被仿真执行的程度	行覆盖率、分支覆盖率、条件覆盖率、状态机覆盖率
功能覆盖率	衡量设计功能点被覆盖的程度	断言覆盖率、功能覆盖组覆盖率

举个例子，你写了一段 if-else 逻辑：

if (a > b) begin
    data_out = data_a;
end else begin
    data_out = data_b;
end

如果仿真时 a 永远大于 b，那 else 分支就从来没执行过。行覆盖率会告诉你：这行代码没跑到。但功能覆盖率呢？它可能关心的是「当 a 和 b 相等时，输出是否正确」——这个场景代码覆盖率是看不出来的。

核心观点：代码覆盖率告诉你「代码跑了多少」，功能覆盖率告诉你「功能测了多少」。两者缺一不可。

你想想看，一个 SoC 芯片动辄几百万门，靠人肉检查能查得过来吗？显然不能。覆盖率就是你的「验证进度条」。

我总结了一下，覆盖率有三大价值：

我曾经在一个 PCIe 控制器项目里，功能覆盖率做到 95% 了，但代码覆盖率只有 60%。一查，发现有个 error 处理路径的 RTL 代码从来没被触发过。后来补了一个定向测试，果然挖出一个 bug。你说，如果没有覆盖率，这个 bug 是不是就流片出去了？

避坑指南：我曾经见过有人把覆盖率当成「KPI 数字游戏」——为了凑 100% 行覆盖率，写一堆无意义的测试向量。记住：覆盖率是手段，不是目的。真正的目标是找到 bug，不是刷数字。

覆盖率不是验证的终点，而是验证的「导航仪」。下面这张图，是我多年验证经验的总结：

从这张图可以看出，覆盖率不是最后才看的。它贯穿整个验证流程：

个人经验：我建议在项目启动时就定好覆盖率「红线」。比如行覆盖率低于 80% 不允许提交代码，功能覆盖率低于 90% 不允许 tape-out。这样整个团队才有明确的目标感。

做验证这些年，我见过不少「翻车」案例。这里列几个常见误区，大家引以为戒：

避坑指南：我曾经在一个 AI 加速器项目里，团队把行覆盖率刷到 98%，但功能覆盖率只有 40%。结果流片回来，一个 corner case 导致整个芯片无法启动。从那以后，我坚持「功能覆盖率优先，代码覆盖率兜底」的原则。

好了，这一章的内容就这些。总结一下：