华为内部分享||从波形中淘金：如何在看似正常的仿真结果里揪出隐藏Bug

1. 波形为王：验证工程师的终极武器

芯片验证就像一场没有硝烟的战争，而波形就是我们手中的显微镜和探测器。很多新手验证工程师拿到仿真通过的波形后，往往只看测试用例（TC）的Pass/Fail状态就万事大吉，这其实错过了发现隐藏Bug的最佳机会。我见过太多案例，明明波形里藏着明显的异常信号，却因为没人仔细检查，最终导致芯片流片失败。

记得2018年做某款网络处理器芯片验证时，所有TC都显示Pass，代码覆盖率也达到100%。但在review波形时，我发现DMA模块的burst传输中，每隔127个周期就会出现一个异常的1-cycle停顿。这个微小的时序异常最终被证明是FIFO指针计算错误导致的致命缺陷。如果当时只看TC结果，这个Bug就会漏网。

2. 从Pass波形中揪出Bug的实战技巧

2.1 必查的三大危险信号

X/Z态永远是第一排查重点。在芯片正常运行时，任何非预期的X/Z态都可能是Bug的信号。我习惯用Verdi的"Search X/Z"功能快速扫描整个波形。最近在验证一个PCIe控制器时，就是在Lane训练阶段发现了短暂的X态，最终定位到是复位同步逻辑缺陷。

时钟信号的检查需要特别耐心。要确认：

• 所有同步时钟边沿严格对齐
• 门控时钟的使能信号完全覆盖时钟脉冲
• 跨时钟域信号满足建立保持时间

数据流异常往往藏在细节里。重点关注：

• 协议违反（如AXI的valid-ready握手）
• 数据包不连续
• 计数器跳变异常
• 状态机非法跳转

2.2 波形分析的黄金四步法

1. 预判：先不看波形，根据设计文档想象理想波形
2. 对比：将实际波形与预想波形逐周期比对
3. 标记：用不同颜色标注关键信号组（建议：红色-控制信号，蓝色-数据信号）
4. 追溯：从异常点向前倒推至少20个周期找根因

// 示例：用SV断言辅助波形检查 property check_arb_priority; @(posedge clk) !grant[0] |-> ##[1:3] $stable(request); endproperty

3. 高级波形调试技巧

3.1 波形对比的妙用

Verdi的波形对比功能(WaveDiff)能快速定位设计修改前后的差异点。有次做时钟门控优化时，就是通过对比发现新版本某个时钟域丢失了使能脉冲。具体操作：

# Verdi TCL命令示例 fsdbreport -diff old.fsdb new.fsdb -o diff.rpt

3.2 后仿真的特殊检查项

后仿真波形需要额外关注：

• 时序违例导致的毛刺
• 跨电压域信号电平转换
• 复位信号撤除时序
• IO端口驱动冲突

建议建立检查清单(Checklist)：

1. 所有异步复位撤除时间 > 3个周期
2. 跨时钟域信号至少有2级同步器
3. 门控时钟使能提前1ns生效

4. 构建系统化的波形审查流程

4.1 建立波形审查标准

制定团队统一的波形标注规范：

• 信号分组命名规则（如CLK_, DAT_, CTL_前缀）
• 关键检查点书签设置
• 异常波形截图模板

4.2 自动化辅助工具链

虽然强调人工检查，但可以借助工具提高效率：

# Makefile自动化检查示例 wave_check: verdi -sv -dbg -f filelist.f -ssf wave.fsdb & python check_xz.py wave.fsdb python clock_check.py wave.fsdb

4.3 典型Bug波形图鉴

收集各类典型Bug的波形特征，形成内部案例库：

1. 亚稳态导致的脉冲展宽
2. FIFO指针回卷错误
3. 状态机死锁
4. 仲裁器优先级反转
5. 跨时钟域数据丢失

5. 验证大师的思维模式

培养"波形直觉"需要三个关键心态：

怀疑精神：永远不相信任何自动检查工具的结果，包括形式验证。有次形式验证证明某个仲裁器公平，但波形显示它其实会饿死低优先级请求。

系统视角：不仅看当前模块，还要关注上下游影响。曾经发现一个DMA波形异常，根源却是CPU的cache预取机制有问题。

极致耐心：最隐蔽的Bug往往需要追踪数十个周期。我记录是花了3天追踪一个偶现的CRC错误，最终定位到是时钟门控使能信号的毛刺导致。

在芯片验证这个行当里，波形就像考古学家的刷子，可能99%的时间都在做枯燥的清理工作，但那1%的发现往往能挽救整个项目。每次看波形时，我都想象自己是在给未来的芯片做体检——现在多发现一个问题，量产时就少一次召回风险。