2. 覆盖率类型与建模基础

在Cadence验证覆盖率闭环工程中，覆盖率不是单一指标，而是一组从不同角度回答“验证是否充分”的度量体系。代码覆盖率回答“RTL的哪些结构被仿真触发过”，功能覆盖率回答“设计规格中的场景是否被激励命中”，断言覆盖率回答“关键时序与协议约束是否被检查过”，FSM覆盖率回答“状态机的状态与跳转是否被遍历”。四者采集对象、采集方式、适用场景各不相同，混用会导致覆盖率数字虚高或漏判。

一、四类覆盖率的本质差异

代码覆盖率由仿真器在编译与运行时自动插桩产生，属于“白盒结构度量”。在Cadence Xcelium中，通过-coverage all或分项开关（如-coverage bcesft）启用，仿真结束后由IMC（Integrated Metrics Center）合并.ucd数据库并生成报告。它包含行覆盖、分支覆盖、条件覆盖、翻转覆盖、状态机覆盖等子项，反映的是RTL代码被激活的广度，但无法判断激励是否符合设计意图。

功能覆盖率由验证工程师手工建模，属于“黑盒意图度量”。在SystemVerilog中通过covergroup、coverpoint、cross定义采样点与仓（bin），在Cadence Xcelium中随仿真运行采样，结果同样汇入IMC。它直接对应验证计划中的场景，例如“AXI突发长度覆盖4/8/16/32”“读写通道同时活跃”等，是判断验证是否收敛的核心依据。

断言覆盖率来自SVA（SystemVerilog Assertion）或PSL断言。Cadence Xcelium支持在仿真中统计每条断言的尝试次数、成功次数、失败次数与未覆盖情况。它既包含“断言是否被触发”的覆盖信息，也包含“断言是否通过”的检查信息，因此兼具覆盖与检查双重属性。在IMC中，断言覆盖率通常与功能覆盖率合并查看，用于确认协议检查器确实被激励激活。

FSM覆盖率是代码覆盖率的子类，但因其重要性常单独讨论。Xcelium可自动提取RTL中的状态机，统计每个状态是否进入、每条状态转移是否发生、状态编码是否翻转。对于控制密集型设计（如仲裁器、协议控制器），FSM覆盖率能暴露“状态可达但跳转未走”的盲区，这是普通行覆盖无法发现的。

二、在Cadence环境中的采集方式

四类覆盖率在Xcelium中的启用方式不同。代码覆盖率与FSM覆盖率通过编译/仿真选项开启，典型命令如下：

xrun -coverage all -covfile cov.ccf \
     -f filelist.f \
     -top tb_top \
     +define+COV_ENABLE

其中-coverage all等价于-coverage bcesft，分别对应分支、条件、表达式、语句、翻转、FSM。若只需FSM覆盖率，可写-coverage f。覆盖率配置文件cov.ccf可指定只采集特定模块，避免全芯片插桩导致仿真变慢。

功能覆盖率不需要额外编译选项，只要在SystemVerilog中定义covergroup并在采样事件中调用sample()即可。例如：

covergroup cg_axi_burst @(posedge clk);
  cp_len: coverpoint burst_len {
    bins len4  = {4};
    bins len8  = {8};
    bins len16 = {16};
    bins len32 = {32};
  }
  cp_rw: coverpoint axi_rw;
  x_rw_len: cross cp_rw, cp_len;
endgroup

断言覆盖率同样无需额外开关，SVA在仿真中自动统计。但需注意，若断言位于未例化的模块中，或assert property被条件禁用，则不会产生覆盖数据。IMC中可通过“Assertion Coverage”视图查看每条断言的尝试次数，若某条断言尝试次数为0，说明激励从未触发该检查点。

三、建模基础与常见误区

功能覆盖率建模的核心是“从验证计划到coverpoint的映射”。一个可操作的建模流程是：先列出验证计划中的场景条目，再为每个场景确定采样信号、采样时机和仓划分。例如验证AXI写通道的“写响应乱序”场景，采样信号应选bvalid与bid，采样时机为bready && bvalid，仓划分可按bid与前一拍bid的关系定义“同ID连续”“不同ID交错”等。

常见误区有三类。第一，用代码覆盖率替代功能覆盖率：代码覆盖率100%不代表所有场景都验证过，例如一个加法器所有行都执行了，但未验证溢出场景。第二，功能覆盖率仓划分过粗：只定义bins len = {[4:32]}，无法区分4和32是否都命中，应拆分为具体值或合理区间。第三，断言覆盖率只看“通过率”不看“触发率”：一条断言从未被触发，通过率显示为100%是假象，必须确认尝试次数大于0。

四、四类覆盖率的协同使用

实际项目中，四类覆盖率应形成互补闭环。代码覆盖率用于发现“未激活的RTL结构”，功能覆盖率用于确认“验证计划场景已命中”，断言覆盖率用于确认“协议检查器已激活且无失败”，FSM覆盖率用于确认“控制路径已遍历”。当功能覆盖率达到100%但代码覆盖率仍有未覆盖行时，需分析该行是否属于冗余逻辑或不可达分支；当断言尝试次数为0时，需补充激励或检查断言绑定是否正确。

在Cadence闭环流程中，通常先以功能覆盖率为收敛主指标，代码覆盖率与FSM覆盖率作为辅助排查手段，断言覆盖率作为协议检查的激活证明。四者数据统一汇入IMC，通过覆盖率合并、分析与回归迭代，最终形成可签核的覆盖率报告。