Verdi 覆盖率豁免避坑指南

Verdi 覆盖率豁免避坑指南

今天在 Verdi 中踩了覆盖率豁免的坑，后续我计划将过往工作学习中的总结系统性整理分享，同时也会把生产端遇到的遗漏类 Bug 分享出来。如果大家有问题或建议，欢迎指正，我也希望能借此向各位同行多多学习。

1. 为什么 Waiver 会失效？

我们团队的这颗芯片体量不大，但设计同学动手特别勤快，离 tapeout 只剩几周了，RTL 还在一版一版推。前面我已经按老版本 RTL 收过一轮“正常”的覆盖率，也整理了一堆 .el(Exclusion List) 当 Waiver。结果设计一改、层次一挪，新的 coverage database 跟旧的 Waiver 就彻底对不上号了。

此时若将旧的 .el 文件套用在新数据库上，Verdi 会无法识别对应的豁免点，直接体现在 Exclusion Manager 窗口中出现一系列让人头疼的异常图标。

2.异常图标的含义与处理建议

这些图标其实是 Verdi 在解析 coverage database 和 Waiver 后发现的不一致的地方。根据新思官方的定义（其实是我翻了下 User Guide），异常的符号只有三种，其余符号是处理后的状态，咱们来理解一下这三个符号描述：

• 🟢 绿色问号 ? (Matches Signature)

  • 通俗解读：“这人我看着眼熟，但好像搬家了。”
  • 原因分析：你的逻辑没变（RTL 代码行的 Checksum 没变），但是你可能把这个模块的 Instance Name 改了，或者把模块挪到了另一个子系统里。Verdi 在原来的路径下找不到它，但在别的地方算出了同样的指纹。
  • 处理建议：如果数量不多，可以手动 Remap （即 Accept）。但更建议简单点——Reject（删掉），然后在新的路径下重新 Waive 一次。

• 🔴 红色问号 ? (Mismatch Signature)

  • 通俗解读：“查无此人，长得也不像。”
  • 原因分析：这是最惨的。代码不仅挪了位置，连里面的代码逻辑也改了，但是改动不大能识别出来有些一致性。比如你把 a && b 改成了 a || b。这时候，旧规则彻底废了。
  • 处理建议：Reject（直接删除）。

• 🔴 红色感叹号 ! (Unmappable)

  • 通俗解读：“彻底消失，灰飞烟灭。”
  • 原因分析：这种情况通常发生在设计同事删代码的时候。旧 Waiver 说“帮我豁免第 82 行”，结果现在的第 82 行是空的，或者是另一段完全无关的代码。
  • 处理建议：Reject。

3. 耗时数小时排查的 “隐形坑”

好了，如果你耐着性子把上面那些红红绿绿的问号都修好了，并又分析了一些新增的功能点覆盖率，然后重新点了一遍 Recalculate Score ，发现已经达到了100%。这时候你满怀信心地点击 Save，覆盖了之前 Waiver 文件，然后关闭覆盖率结果，等待着明天的同设计同事异同review这些内容并开心地等待项目TO。但是到了第二天，当你从服务器上拉取新的 Report... 发现覆盖率纹丝不动！ =_=！

问题根源:

在 Verdi 的 Exclusion Manager 里，当你处理完这些 Unresolved 状态（Old Waiver）后，如果直接保存覆盖原有文件，有时候它默认是尝试写回那个 只读的(Read-only) 或者 时间戳不对的 旧文件。

更鸡贼的是，界面上看起来生效了，但在文件系统里，那个 .el 文件根本没变。（但不排除跟verdi版本是否有关，我们团队使用的工具版本优点老）

避坑指南

1. 处理完所有红色、绿色的问号后。
2. 千万不要直接覆盖原文件。
3. 一定要选 "Save As..." (另存为)，存成一个新的文件名，比如 waivers_v2_fixed.el。
4. 然后在你的 Regression 脚本或者是 Makefile 里，把加载的 Waiver 文件路径指到这个新文件。
5. 除此之外，当失效Waiver数量庞大时，我们可以根据状态（Status）进行筛选，然后对同一类型的条目进行全选后统一执行“Reject”操作，能极大提升效率

我正是因反复在旧文件上 “无效修改”，误以为豁免规则已修复，最终导致覆盖率报告无变化，白白耗费了数小时排查问题。

4. 总结

• 区分异常类型：移位的（绿）可以考虑重用，但改代码的（红）必须直接重来。个人建议都直接拒绝。
• 另存优先：永远不要相信直接保存，Save As New File 才是正道。