2. 验证计划制定：验证范围定义、功能覆盖率规划、资源与时间估算
好，咱们进入第二章。验证计划，说白了就是整个验证工程的“作战地图”。没有它，你就像在迷雾里开车，撞了墙才知道走错了。我见过太多团队，一上来就写代码、跑仿真，结果到项目后期发现功能点漏了，覆盖率死活拉不上去，最后只能延期。嗯，这章咱们就把这事聊透。
2.1 验证范围定义：先搞清楚“测什么”
我个人习惯，拿到设计文档后，第一件事不是看RTL代码，而是先列一个“功能清单”。这个清单，就是验证范围的起点。
验证范围，说白了就是“测什么”和“不测什么”。 你得明确边界。比如一个AI加速器，它的核心是矩阵乘法和激活函数。那DMA传输、寄存器配置、中断响应，这些算不算验证范围？算，但优先级不同。
核心原则： 验证范围 = 设计规格中所有可观测的功能行为 + 边界条件 + 错误处理路径。
我在项目中遇到过一种情况：设计文档里写“支持8位和16位精度”，但没写“混合精度运算”。结果验证团队只测了纯8位和纯16位，漏掉了混合精度场景。流片回来，AI模型跑出来的结果全是错的。所以，验证范围一定要和设计人员、架构师一起过一遍，把那些“隐含的功能”也挖出来。
具体怎么定义范围？我建议分三步走：
- 提取功能点： 从设计规格文档中，逐条列出所有功能。比如“支持AXI4-Stream接口”、“支持权重预加载”、“支持卷积核尺寸3x3/5x5”。
- 划分优先级： 用P0/P1/P2来标记。P0是核心功能，不通过芯片没法用；P1是重要功能，但可以有workaround；P2是锦上添花。
- 明确排除项： 比如“本版本不验证DFT扫描链”、“不验证功耗管理单元”。这些要白纸黑字写下来，避免后期扯皮。
我的小技巧： 用Excel或Google Sheets建一个“功能点追踪表”，每一行是一个功能点，列包括：功能描述、优先级、验证方法（仿真/形式化/FPGA）、负责人、状态。这个表会贯穿整个验证周期。
2.2 功能覆盖率规划：别让“测过”变成“测全”
功能覆盖率，是验证质量的“体检报告”。你跑了一百万个测试用例，但覆盖率只有60%，那说明还有40%的功能点你没碰到。你想想看，这多危险。
功能覆盖率 ≠ 代码覆盖率。 代码覆盖率告诉你“哪些代码被执行了”，功能覆盖率告诉你“哪些功能场景被覆盖了”。举个例子，一个加法器，代码覆盖率可能100%，但如果你只测了正数相加，没测负数相加，那功能覆盖率就是0%。
我个人习惯，在写测试用例之前，先把覆盖率模型搭好。这样写测试的时候，心里就有数了。
功能覆盖率规划，核心是定义“覆盖点”和“交叉覆盖组”。
- 覆盖点： 一个具体的功能变量。比如“操作数符号位”、“卷积核大小”、“中断类型”。
- 交叉覆盖组： 多个覆盖点的组合。比如“操作数符号位=负 & 卷积核大小=5x5 & 中断类型=完成中断”。
举个例子，一个AI芯片的矩阵乘法单元，我可能会定义这样的覆盖点：
// SystemVerilog 覆盖率模型示例
covergroup matrix_mul_cg @(posedge clk);
// 覆盖点：矩阵维度
mat_size: coverpoint mat_dim {
bins small = {[1:16]};
bins medium = {[17:64]};
bins large = {[65:256]};
}
// 覆盖点：数据类型
data_type: coverpoint dtype {
bins int8 = {0};
bins int16 = {1};
bins fp16 = {2};
}
// 交叉覆盖：维度 x 数据类型
cross mat_size, data_type;
endgroup注意： 交叉覆盖很容易产生“组合爆炸”。比如10个覆盖点，每个有10个bin，交叉起来就是100亿个组合。这显然不现实。我的经验是，只对关键功能做交叉覆盖，一般控制在2-3个覆盖点交叉就够了。
我曾经在一个项目中，因为交叉覆盖定义得太细，导致仿真跑了三周还没跑完。后来我砍掉了80%的交叉组合，只保留那些“真正有意义的组合”，两周就搞定了。嗯，这里要注意，覆盖率是手段，不是目的。
2.3 资源与时间估算：别把“理想”当“计划”
资源估算，说白了就是“需要多少人、多少机器、多少时间”。我见过最离谱的估算，是项目经理说“这个模块很简单，两周搞定”，结果验证工程师一个人干了两个月。
资源估算的核心公式： 验证工作量 = 功能点数量 × 每个功能点的平均验证时间 × 复杂度系数。
复杂度系数怎么定？我一般这么分：
| 复杂度等级 | 描述 | 系数 |
|---|---|---|
| 低 | 纯组合逻辑，无状态机，无接口协议 | 1.0 |
| 中 | 有简单状态机，标准接口（如AXI） | 1.5 |
| 高 | 复杂状态机，多接口交互，有算法 | 2.0 - 3.0 |
| 极高 | 多核交互，AI加速器，有随机性 | 3.0 - 5.0 |
举个例子，一个AI加速器有50个功能点，每个功能点平均需要2天验证，复杂度系数取3.0。那总工作量就是 50 × 2 × 3 = 300人天。如果团队有5个人，那就是60个工作日，约3个月。
我的经验： 估算时一定要留出20%-30%的“缓冲时间”。因为总会有意想不到的问题——比如仿真环境搭建比预期慢、某个bug特别难复现、或者设计改了规格。我曾经因为没留缓冲，项目后期天天加班到凌晨两点，那滋味真不好受。
时间估算上，我建议把验证周期分成几个阶段：
- 环境搭建期（20%）： 搭建验证环境、编写BFM、配置覆盖率模型。
- 冒烟测试期（10%）： 跑通基本功能，确保环境没问题。
- 功能验证期（40%）： 逐个功能点验证，收集覆盖率。
- 回归与收敛期（30%）： 跑回归测试，补覆盖率漏洞，修复bug。
你想想看，如果功能验证期拖得太长，回归期就会被压缩，最后覆盖率可能不达标。所以，我建议在项目中期就设置一个“覆盖率检查点”，如果覆盖率低于60%，就要考虑增加资源或调整计划。
总结一下： 验证计划不是写出来给领导看的，而是用来指导团队每天工作的。范围要清晰，覆盖率要可衡量，资源要留余量。做到这三点，你的验证项目就成功了一半。
好，这章就聊到这儿。下一章咱们讲讲验证环境的搭建，包括UVM框架、组件划分、还有那些“坑”怎么避开。
公众号:蓝海资料掘金营，微信deep3321