验证计划制定：如何编写验证计划、验证范围界定、功能覆盖率定义、资源与时间估算

验证计划，说白了就是整个验证工作的“施工图纸”。没有它，你就像蒙着眼在迷宫里乱撞。我见过太多团队，一上来就写代码、跑仿真，结果到流片前才发现功能点漏了，覆盖率死活上不去。嗯，那时候再回头补，代价就大了。

我个人习惯，在项目启动的第一周，花至少三天时间把验证计划敲定。这三天看起来“浪费”，但后面能省下几周甚至几个月的时间。你想想看，方向错了，跑得再快也没用。

验证范围界定：知道测什么，更要知道不测什么

验证范围界定，是计划的第一步。很多新人容易犯一个毛病：想把所有东西都验证一遍。这不现实，也没必要。

我在项目中遇到过这样一个情况：一个AI加速器芯片，团队想把所有可能的输入组合都跑一遍。结果呢？仿真时间爆炸，项目延期两个月。后来我们重新划定了范围，只验证架构文档里定义的“合法场景”和“边界异常场景”，其他非法组合用形式化验证快速过一遍就行。

界定范围时，我一般会问自己三个问题：

• 哪些功能是芯片的核心卖点？——这些必须全覆盖，不能有死角。
• 哪些模块是复用IP？——如果IP已经在其他项目里验证过，可以只做集成验证，不做单元级重复验证。
• 哪些场景是“理论上不可能发生”的？——比如某些控制信号的组合，硬件设计上已经做了互斥保护。这些可以降低验证优先级。

功能覆盖率定义：从“测了”到“测够了”

功能覆盖率，是验证质量的“温度计”。没有它，你根本不知道自己的验证到底做完了没有。

定义功能覆盖率，我习惯从设计规格文档入手。把每个功能点拆解成“覆盖组”和“覆盖点”。举个例子，一个FIFO模块：

功能点	覆盖组	覆盖点	说明
写操作	write_cg	wr_en, wr_data, wr_addr	覆盖所有写使能组合
读操作	read_cg	rd_en, rd_data, rd_addr	覆盖所有读使能组合
满状态	full_cg	full_flag, wr_while_full	满时写操作的行为
空状态	empty_cg	empty_flag, rd_while_empty	空时读操作的行为
边界情况	boundary_cg	depth-1, depth, depth+1	FIFO深度边界

定义覆盖点时，有一个坑我踩过好几次：覆盖点太粗。比如只定义“wr_en=1”，这根本不够。你需要覆盖“wr_en=1且full=0”、“wr_en=1且full=1”、“wr_en=1且almost_full=1”等等。覆盖点越细，验证质量越高。

资源与时间估算：别太乐观，留足余量

资源估算，说白了就是算“人月”。但这里有个常见的误区：以为人月可以线性叠加。一个模块一个人做要三个月，三个人做就只要一个月？别天真了。沟通成本、代码合并成本、调试冲突成本，都会随着人数增加而指数级上升。

我一般用下面的公式做初步估算：

总工作量（人月） = Σ（每个模块的代码量 / 人均月产出） × 沟通系数

其中：
- 人均月产出：经验值，SystemVerilog/UVM验证工程师约 2000-3000行/月
- 沟通系数：1人=1.0，2人=1.2，3人=1.5，4人及以上=2.0

时间估算上，我习惯把项目分成四个阶段：

1. 环境搭建期（约20%时间）：搭建验证环境、编写基础组件、调试基本通路。
2. 功能验证期（约40%时间）：跑功能测试、收集覆盖率、修复bug。
3. 覆盖率收敛期（约25%时间）：针对未覆盖的点写定向测试，直到功能覆盖率达标。
4. 回归与签收期（约15%时间）：全量回归、形式化验证、最终签收。

验证计划的核心结构

一份完整的验证计划，我建议至少包含以下章节：

• 概述：芯片功能简介、验证目标、验收标准。
• 验证范围：明确测什么、不测什么、复用IP的处理方式。
• 验证策略：使用什么方法（仿真、形式化、FPGA原型等）、工具链、语言标准。
• 测试点分解：每个功能点的测试用例设计、覆盖组定义。
• 验证环境架构：顶层框图、组件清单、接口协议。
• 资源计划：人员分工、技能要求、培训计划。
• 时间计划：里程碑节点、交付物清单、风险缓冲期。
• 覆盖率计划：覆盖率模型、达标标准、未达标时的处理方案。

下面这张图，是我个人总结的验证计划制定流程，你可以参考一下：

最后说一句，验证计划不是写完了就锁进抽屉里的。它需要随着项目进展不断更新。比如，当你发现某个模块的bug率特别高，就需要在计划里增加额外的验证轮次。灵活调整，才是好计划。