2. 验证环境故障分类与特征提取
在Cadence验证流程中，仿真、形式验证和硬件加速三类环境产生的故障表现差异极大。如果只凭“跑不过”这一笼统判断去调试，往往会在错误的方向上耗费数小时。本节的核心任务是建立一套可复用的故障分类框架，并从日志、波形、覆盖率、断言四类证据中提取稳定特征，最终形成可检索、可匹配的“故障指纹”。
一、按验证环境划分故障域
不同验证引擎的故障根因分布不同，分类的第一步是锁定故障域。
- 仿真环境（Simulation）：以Xcelium/Incisive为主，故障集中在编译期（语法、端口绑定、参数覆盖）、精化期（层次引用、generate展开）、运行期（X传播、时序违例、SVA断言失败、UVM objection超时）。
- 形式验证（Formal）：以JasperGold/Conformal为主，故障集中在约束不可满足（over-constraint）、状态空间爆炸、属性反例（counterexample）不可达、时钟域定义错误。
- 硬件加速（Emulation/Prototyping）：以Palladium/Protium为主，故障集中在时钟树失配、复位序列不同步、SDF反标延迟、DUT与TB速率不匹配、探针采样窗口偏移。
这三类环境的故障域并非完全独立。例如仿真中未暴露的X传播，在硬件加速中可能表现为随机挂死；形式验证中的约束过强，在仿真中可能表现为覆盖率长期不收敛。因此分类时必须记录“故障在哪个环境首次出现、在哪个环境复现”，这一信息本身就是指纹的一部分。
二、四类关键特征及其提取方法
故障指纹由四类特征构成，每类特征都有明确的提取位置和判读方式。
| 特征类别 | 提取来源 | 典型字段/信号 | 判读要点 |
|---|---|---|---|
| 日志特征 | sim.log / jasper.log / emu.log | 错误码、UVM_ERROR计数、时间戳、模块路径 | 首次错误时间与最后正常时间之差 |
| 波形特征 | FSDB/VCD/SHM | X态起点、复位释放沿、时钟周期抖动 | X是否在复位后第N拍出现 |
| 覆盖率特征 | cov_report / UCDB | 功能覆盖率、代码覆盖率、断言覆盖率 | 哪一类覆盖率停滞、停滞在哪个bin |
| 断言特征 | SVA/PSL日志 | 失败断言名、失败时刻、前导信号 | 断言失败是否与X态同时出现 |
提取时建议使用统一的时间基准。例如以仿真时间0为起点，记录每个特征首次出现的绝对时间，再计算相对时间差。这样即使更换环境，指纹仍可对齐比较。
三、故障指纹的构建与匹配
故障指纹不是简单罗列特征，而是将“环境+故障域+四类特征+时间关系”编码为一个可匹配的结构。下面给出一个可操作的指纹模板示例（示例数据为教学假设，非实测结果）：
fingerprint_id: SIM_XPROP_001
env: xcelium 23.09
domain: runtime
first_error_time: 1250ns
last_normal_time: 1240ns
log_key: "UVM_ERROR @ 1250ns: X detected on data_bus[7:0]"
wave_key: "data_bus[7:0] = 8'bxxxxxxxx @ 1250ns"
cov_key: "functional coverage: data_path bin=0/16"
assert_key: "assert_data_valid failed @ 1250ns"
relation: "X态与断言失败同拍出现，覆盖率在data_path停滞"
匹配时，先按env和domain缩小范围，再比对log_key和wave_key。若两条指纹的log_key相同但wave_key不同，说明根因可能不同，需要进一步区分。例如同样是“X detected on data_bus”，若X在复位后立即出现，通常是复位未初始化；若X在若干拍后出现，则可能是多驱动或未初始化寄存器。
四、从特征到根因的判读路径
特征提取的最终目的是定位根因。以下判读路径可作为调试时的检查顺序：
- 若日志中UVM_ERROR计数在短时间内激增，优先检查是否有未初始化信号导致X传播。
- 若波形中X态起点与时钟沿对齐，检查该时钟域内是否有寄存器未复位。
- 若覆盖率停滞在某个bin，检查对应激励是否被约束屏蔽或未生成。
- 若断言失败但波形无X，检查断言前导条件是否被时序违例破坏。
- 若硬件加速中故障无法在仿真复现，检查SDF反标和时钟树配置是否一致。
五、故障分类与特征提取的完整关系
下图展示了从三类验证环境出发，经过故障域划分、四类特征提取，最终汇聚为故障指纹并用于根因判读的整体关系。图中同时标出了特征之间的时间对齐关系和匹配入口。
图中左侧三类环境分别对应各自的故障域，向下汇聚到四类特征，再统一编码为故障指纹，最终进入根因判读。需要强调的是，四类特征并非孤立存在：日志中的首次错误时间、波形中的X态起点、覆盖率停滞的bin、断言失败时刻，四者必须在同一时间基准下对齐，否则指纹匹配会失效。
六、实操建议与常见误区
在实际项目中，建议按以下顺序执行特征提取：先抓日志中的首次错误时间，再在波形中定位该时刻前后的信号变化，然后检查覆盖率是否在同一时间段停滞，最后确认断言失败是否与前三者同步。这个顺序可以避免在无关时间段反复翻看波形。
另一个误区是忽略环境差异。同一故障在仿真中表现为断言失败，在硬件加速中可能表现为超时挂死。因此指纹中必须保留env字段，匹配时先按环境过滤，再比对特征。若某故障在多个环境中均出现，则应建立跨环境指纹，并标注各环境下的特征差异。
最后，指纹库需要持续维护。每次调试结束后，将本次的指纹追加到库中，并标注根因和修复方式。随着指纹库增长，新故障的匹配速度会显著提升，重复故障的定位时间可从小时级降到分钟级。这一过程本身就是验证团队知识沉淀的核心环节。