极客工场

Appearance

共 1,694 字预计阅读约 6 分钟

功能覆盖率矩阵模板：把特性点、覆盖组和达成判据连成一行 ​

这份功能覆盖率矩阵模板是 芯片验证 入门阶段的一张执行表：把需求里的行为拆成特性点，再说明由哪个覆盖组观察、哪个用例触发、满足什么条件才算完成。它承接 验证计划模板：从 Spec 到覆盖率收口，但把注意力集中在“一行能否追踪到底”，不展开完整验证环境。

矩阵不是把几个名词并排抄进表格。好的矩阵能回答：需求删改会影响哪些覆盖点，覆盖率空洞应该补哪个用例，以及某项功能为何可以签收。下面给出可直接复制的 Markdown 模板和同步 FIFO 填写示范。

本文要回答的问题 ​

  1. 需求条目、特性点、covergroup 和测试用例应该怎样对应？
  2. 一行矩阵需要哪些字段，哪些内容不该塞进去？
  3. 同步 FIFO 的空、满、同时读写怎样转成覆盖点和达成判据？
  4. 文档矩阵与仿真器覆盖率报告分别承担什么职责？

一、先固定五类对象的追踪关系 ​

矩阵以特性点为枢纽。需求说明设计必须做到什么；特性点把要求改写成可观察行为；覆盖模型定义需要看到的场景；用例负责制造场景；达成判据把“场景出现”和“行为正确”合成完成条件。五者不是一一对应：一个需求可拆出多个特性点，一个用例也可服务多个覆盖点。

功能覆盖率矩阵以特性点为追踪枢纽

读这张图要抓住分工：覆盖点只证明某场景发生过，不自动证明设计做对了。例如“满时写请求”这个 bin 命中，只能说明激励到达了边界；是否拒绝写入、数据是否保持，仍要由 scoreboard 或断言检查。因此达成判据不能只写“覆盖到”，还要挂接行为检查。

二、可直接复制的 Markdown 矩阵 ​

把下面整块复制到项目文档。覆盖模型尚未实现时也先写规划名称，后续保持名称与代码一致；不需要覆盖率兜底的定向特性点，在覆盖组栏写“—”，不要硬造无价值的 coverpoint。

markdown
# <模块名>功能覆盖率矩阵

- 需求版本：<版本或基线>
- 覆盖模型版本：<文件或版本>
- 通用判据 G1：关联用例通过，scoreboard 与断言无未解释错误
- 通用判据 G2：本行列出的有效 bins 全部命中；排除项有书面理由

| 需求 ID | 特性点 ID | 可观察行为 | covergroup | coverpoint / bins | 测试用例 | 达成判据 | 状态 |
|---|---|---|---|---|---|---|---|
| <REQ-01> | <F-01> | <条件 + 动作 + 结果> | <cg_name 或 —> | <cp_name / bin 列表或 —> | <test_name> | <G1、G2 或专项检查> | 未执行 |

## 覆盖率空洞登记

| 特性点 ID | 未命中 bin | 原因分类 | 处置 | 结论 |
|---|---|---|---|---|
| <F-01> | <bin 名> | 激励不足 / 模型错误 / 合理不可达 | 补用例 / 修模型 / 申请排除 | <待处理> |

字段最容易填错的有三处。可观察行为要写成“满时收到写请求，写使能不被接受且存储内容不变”，不能只写“验证满状态”。coverpoint / bins要列目标场景，不必粘贴完整 SystemVerilog 实现。状态只填未执行、待补、已达成或已批准排除，不能在矩阵里预写覆盖率百分比。

三、同步 FIFO 示例：先约定边界行为 ​

示例 FIFO 深度为 8，读写共用时钟，采用高有效同步复位。非满时可以写，非空时可以读；满时同拍读写只接受读，空时同拍读写只接受写。后两条是示例的明确接口约定，实际项目若允许旁路或同时接受，必须同步修改特性点与 bins，不能照搬。

chip-design/beginner/tpl-coverage-matrix.md D2 示意图

图中“空”和“满”是验证必须专门触发的边界，不是随机流量自然会出现就足够的附属状态。中间到满的那一次写对应 to_full，中间到空的那一次读对应 to_empty；满时同拍请求和空时同拍请求则另设 cross，避免普通读写 bin 命中掩盖边界组合缺失。

四、填写示范：特性点乘覆盖组落到同一行 ​

下面是示例矩阵，状态均保持“待执行”，因为它只表达验证计划，不代表任何仿真结果。

markdown
| 需求 ID | 特性点 ID | 可观察行为 | covergroup | coverpoint / bins | 测试用例 | 达成判据 | 状态 |
|---|---|---|---|---|---|---|---|
| REQ-RST | F-RST-01 | 同步复位后读空、写未满，存储指针回初值 | — | — | fifo_reset_test | G1；复位后专项检查通过 | 待执行 |
| REQ-DATA | F-DATA-01 | 非满写入且非空读出，数据保持先入先出 | cg_fifo_io | cp_op / write、read | fifo_random_test | G1 + G2 | 待执行 |
| REQ-FULL | F-FULL-01 | 满时写请求被拒绝，地址与内容不变 | cg_fifo_boundary | cp_full_write / reject | fifo_full_test | G1 + G2 | 待执行 |
| REQ-EMPTY | F-EMPTY-01 | 空时读请求被拒绝，不产生有效读数据 | cg_fifo_boundary | cp_empty_read / reject | fifo_empty_test | G1 + G2 | 待执行 |
| REQ-FLAG | F-FLAG-01 | 最后一项写入置满，最后一项读出置空 | cg_fifo_transition | cp_transition / to_full、to_empty | fifo_boundary_test | G1 + G2 | 待执行 |
| REQ-SIM | F-SIM-01 | 同拍请求按空、满、中间状态的约定接受 | cg_fifo_simultaneous | cross cp_state、cp_req / empty_rw、middle_rw、full_rw | fifo_simultaneous_test | G1 + G2 | 待执行 |

F-SIM-01 的 cross 只保留三个有意义的组合，不要把读、写单独请求与所有状态机械笛卡尔相乘。F-RST-01 则展示另一种合理情况：复位行为由定向用例和检查器验证，不为了表格整齐而增加覆盖组。覆盖模型的命名、采样时机与 cross 设计可继续参考 testplan 与覆盖率映射。

五、达成判据与报告边界 ​

矩阵里的 G2 是计划目标，不是结果。执行后应从仿真器报告核对 bins，再把状态改为已达成或登记空洞；报告里的总体百分比不能替代逐特性点判断，因为高平均值仍可能遮住一个关键的 full_rw 空洞。

对比项文档矩阵仿真器覆盖率报告
回答的问题要覆盖什么、为何覆盖、由谁触发实际命中了哪些 bins
主要内容需求、特性点、模型、用例、判据覆盖点、命中次数、覆盖率与空洞
更新时机需求或模型变化时维护每次仿真或合并结果后生成
能否替代对方不能证明已执行不能解释需求意图与豁免理由

发现空洞时，先区分激励不足、覆盖模型写错和合理不可达。激励不足就补约束或用例；模型写错就修 bins 并重跑；合理不可达要记录设计依据和批准结论。具体收敛动作可接 功能覆盖率收口计划，不要把未命中项直接改成“已覆盖”。

这一篇在知识体系里的位置 ​

验证计划模板：从 Spec 到覆盖率收口 负责建立完整验证计划，本篇负责其中的追踪表；功能覆盖率收口计划 负责处理执行后的空洞。需要细化 covergroup、coverpoint 和 cross 时，再阅读 testplan 与覆盖率映射。

总结 ​

功能覆盖率矩阵模板的核心是一行追踪到底：需求 ID 找到来源，特性点写清可观察行为，covergroup 与 bins 定义目标场景，测试用例负责触发，达成判据同时要求场景命中和行为正确。同步 FIFO 示例说明空、满、最后读写和同拍请求都应显式映射；文档只维护计划与结论，真实覆盖率和命中情况始终以仿真器报告为准。