覆盖率迭代思路

需要注意：不仅RTL中可能有bug，自己写的TB代码可能也有bug
覆盖率反馈路径，本质上是一个 “仿真 -> 测量 -> 分析 -> 修正” 的闭环迭代过程。它的目的不是跑完测试就结束，而是利用覆盖率数据来指导我们下一步的验证工作。

其迭代流程通常包含以下四个核心阶段：

1. 运行仿真 (Simulate)

运行你的测试用例集（包括定向测试和受约束的随机测试）。需要注意的是，对于随机测试，通常会用多个不同的随机种子（seed）来运行，因为每个种子探索的输入空间都不同。

• 在VCS等工具中，编译和仿真时需要加上收集覆盖率的选项，如 -cm line+cond+tgl+branch+fsm。

2. 测量与合并覆盖率 (Measure & Merge)

仿真结束后，工具会生成覆盖率数据库文件（如VCS的 .vdb 文件）。由于单个测试用例通常只覆盖芯片的部分功能，因此需要将所有测试用例的覆盖率数据合并（Merge） 起来，才能看到整体的覆盖情况。

• 合并后，通过工具（如VCS的URG、Verdi）生成详细的覆盖率报告。

3. 分析覆盖率缺口 (Analyze Gaps)

这是整个流程中最关键的一步：解读覆盖率报告，找出“覆盖率空洞（Coverage Holes）” 。

你需要分析的缺口主要有两类：

• 代码覆盖率缺口：从未被执行到的RTL代码，如某条if语句的else分支、某个case的选项、从未翻转的寄存器位等。
• 功能覆盖率缺口：从未被采样到的功能点，即你关心的场景没有被测试到。

分析时要警惕几种情况，例如“行覆盖率高但翻转覆盖率低”可能意味着信号虽被执行但未完成完整翻转，或是工具统计上的“隐含分支”未覆盖。

4. 添加或修改激励 (Add Stimulus)

根据缺口分析的结果，采取相应的行动：

• 调整约束或增加种子：如果覆盖率增长停滞，可以尝试放宽或增加随机约束。更简单的，是先用更多的随机种子运行现有测试，看是否能覆盖到新的区域。
• 编写定向测试：当随机测试很难命中某些极其特定的场景时，就需要编写有针对性的定向测试来精确命中。
• 排除不可达代码：如果分析确认某些代码在功能上永远无法被执行（死代码），可以在覆盖率报告中将其标记为“排除”（waive），不再计入统计。

完成这一步后，整个流程会重新回到第一步（运行仿真），形成一个不断循环的“反馈闭环”。这个过程会一直持续，直到所有覆盖率指标达到项目要求的签核（Signoff）目标。

简单来说，整个流程就是不断重复“跑测试 -> 看报告 -> 找漏洞 -> 补测试”这一循环。刚开始阶段，补种子的效果会比较显著；当覆盖率增长放缓或停滞时，就需要更深入地去调整约束或编写定向测试了。