📚 课程目录第2章验证计划与测试用例规划

2. 验证计划与测试用例规划

验证计划不是把规格书翻译成任务清单，而是把“设计必须做什么”转化为“我们如何证明它做到了”。在 Xcelium 平台上，验证计划最终要落到三类可执行对象上：验证特性（feature）、覆盖率模型（covergroup/coverpoint/cross）和测试用例（testcase）。三者之间必须建立双向可追溯关系，否则覆盖率数字再高也无法回答“这个特性到底测没测”。

一、从 SoC 规格提取验证特性

规格提取的核心动作是“拆边界、找状态、定激励”。以一颗含 AXI4 主端口、APB 配置接口和中断控制器的 SoC 子系统为例，规格中“支持 4 路外部中断，可配置上升沿/高电平触发，支持屏蔽与优先级”这句话，至少可拆出以下验证特性：

F-INT-01：4 路中断源可独立使能/屏蔽；
F-INT-02：每路触发方式可配置为上升沿或高电平；
F-INT-03：优先级仲裁结果符合配置；
F-INT-04：中断挂起、清除、嵌套行为符合时序图；
F-INT-05：APB 寄存器读写与复位默认值正确。

提取时建议同步记录“特性来源”和“验证方法”。来源指向规格章节号，方法标注为定向测试、随机约束或形式验证。对于跨模块特性，例如“DMA 搬运完成后触发中断并更新状态寄存器”，应单独列为集成级特性，避免被拆散到各模块后无人负责整体时序。

验证特性应满足可观测、可激励、可判定三个条件。若一条特性无法写出对应的检查点或覆盖率点，说明它还需要继续拆分。

二、覆盖率驱动规划

覆盖率驱动不是先写测试再补覆盖率，而是在测试之前先定义“测到什么算够”。在 Xcelium 中通常使用 SystemVerilog 的 covergroup 描述功能覆盖率，用代码覆盖率（行、条件、翻转、FSM）作为补充。规划时按“特性 → 覆盖点 → 仓（bin）→ 交叉”逐层展开。

以 F-INT-02 为例，可定义如下覆盖结构：

covergroup cg_int_cfg @(posedge clk);
  cp_trig: coverpoint int_ctrl.trig_mode[3:0] {
    bins edge = {4'b0000};
    bins level = {4'b1111};
    bins mixed = default;
  }
  cp_mask: coverpoint int_ctrl.mask[3:0] {
    bins all_on  = {4'b1111};
    bins all_off = {4'b0000};
    bins one_hot[] = {4'b0001,4'b0010,4'b0100,4'b1000};
  }
  x_trig_mask: cross cp_trig, cp_mask;
endgroup

这里 one_hot[] 自动展开为 4 个仓，cross 生成 3×6=18 个交叉仓。规划阶段就要估算仓数量：若某个 cross 产生数百个仓而激励很难覆盖，应改用 binsof 或 ignore_bins 收敛，而不是等回归跑完再删。覆盖率目标建议分层设定：模块级功能覆盖率 100%，子系统级交叉覆盖率 ≥95%，代码覆盖率中条件覆盖率 ≥90%，翻转覆盖率对关键总线信号单独要求。

三、测试用例映射

测试用例与验证特性之间应建立映射矩阵，确保每条特性至少有一个用例，每个用例至少服务一条特性。映射关系可用下表组织（示例）：

用例名	覆盖特性	激励方式	检查点
int_smoke_test	F-INT-01/05	定向 APB 写读	寄存器回读一致
int_trig_rand_test	F-INT-02	随机 trig_mode	cg_int_cfg.cp_trig
int_prio_test	F-INT-03	定向多源同发	仲裁输出比对
int_nest_test	F-INT-04	场景序列	时序断言
dma_int_integration	集成特性	DMA+中断联合	状态寄存器与中断同拍

映射时要注意“一特性多用例”和“一用例多特性”都正常，但不应出现无特性归属的用例，也不应出现无用例覆盖的特性。Xcelium 的 xrun -cov_merge 可在回归后合并覆盖率数据库，配合 xcr 查看哪些仓未命中，再反向定位缺失的用例或约束。

四、回归策略设计

回归不是把所有用例重复跑一遍，而是按风险和成本分层。建议分为三层：冒烟回归（每次提交，5~10 分钟，覆盖时钟复位、寄存器访问、基本中断）、每日回归（全功能用例 + 随机种子扩展，1~2 小时）、周回归（长随机、跨模块集成、低概率场景，数小时至过夜）。

随机种子管理是回归策略的关键。Xcelium 中可用 xrun -sv_seed random 让每次运行不同，也可用 -sv_seed 12345 复现失败。建议每日回归固定一组基础种子保证可比性，同时追加若干随机种子扩大探索；失败用例记录种子号并纳入回归黑名单，修复后再放回。

回归结果判读要区分“失败”和“未覆盖”。失败用例需定位是设计缺陷、激励错误还是检查器误报；未覆盖仓则要判断是约束不足、场景不可达还是覆盖率模型定义过宽。对于确实不可达的仓，应在覆盖率模型中用 ignore_bins 显式排除并注明理由，而不是放任数字停在 98%。

不要把回归通过率当作唯一指标。一个全部通过但覆盖率长期不涨的回归，说明激励空间已经饱和，需要重新审视约束或补充新的验证特性。

最后，验证计划应作为活文档维护。每当规格变更、发现新缺陷或覆盖率分析暴露盲区，都要回写特性列表、覆盖率模型和用例映射表。Xcelium 的覆盖率数据库可按用例、按种子、按层次合并，配合版本管理，使每一轮回归都能回答“相比上一轮，新增覆盖了哪些特性、哪些仓仍未命中”。这样，验证计划才真正成为驱动验证收敛的工程依据，而不是一份写完就归档的文档。