验证计划制定：如何编写验证计划，验证范围定义，功能覆盖率目标设定
做验证这么多年，我见过太多项目在验证计划上栽跟头。有人觉得计划就是走个过场，有人把计划写得比小说还厚结果没人看。说实话，验证计划这东西，写得太粗等于没写，写得太细又没人执行。今天我就聊聊，怎么把验证计划做到「刚刚好」。
一、验证计划到底长什么样？
先说说我的理解。验证计划不是文档，是地图。你想想看，一个芯片几百个功能点，几十万行代码，没有地图你怎么走？
我个人习惯把验证计划分成三个层次：
- 策略层：回答「测什么、不测什么」
- 方法层：回答「用什么方法测」
- 执行层：回答「谁、什么时候、测到什么程度」
我在项目中遇到过最典型的反面教材——有人把验证计划写成了「我们要做功能验证、时序验证、功耗验证...」这种废话。这跟没说一样。好的计划应该具体到：哪个模块用UVM，哪个场景用formal，覆盖率目标定多少。
核心原则：验证计划必须可执行、可度量、可追溯。
二、验证范围定义——别什么都往里装
很多新手容易犯一个错误：恨不得把所有功能点都写进计划。结果呢？计划厚得像砖头，最后根本执行不完。
验证范围定义，说白了就是做减法。我一般用「三圈法」：
- 必须测的圈：规格书里明确的功能、接口协议、关键路径
- 应该测的圈：边界条件、异常处理、低概率场景
- 可以测的圈：性能极限、随机压力、跨时钟域
举个例子。我之前做的一个PCIe控制器项目，团队一开始列了200多个测试点。我让他们先砍掉那些「理论上不会出问题」的场景，比如复位时序的极端情况——因为复位逻辑已经用formal验证过了。最后剩下80个核心测试点，项目反而提前了两周完成。
我的经验：验证范围不是越大越好。把80%的精力放在20%的高风险功能上，这才是聪明的做法。
三、功能覆盖率目标设定——别让数字骗了你
功能覆盖率这东西，我见过太多人把它当KPI来追。有人为了达到90%的覆盖率，拼命写covergroup，结果覆盖到了全是无关紧要的场景。这有什么意义？
设定覆盖率目标，我建议分三步走：
| 步骤 | 做什么 | 常见坑 |
|---|---|---|
| 第一步 | 识别关键功能点 | 把非关键功能也纳入统计 |
| 第二步 | 定义覆盖模型 | cross cover写得太多，组合爆炸 |
| 第三步 | 设定达标阈值 | 盲目追求100%，忽略验证效率 |
我记得有个项目，团队把覆盖率目标定在95%。结果最后两周所有人都在补覆盖率，补的全是些边角料场景。核心功能反而没时间深挖。后来我学乖了：核心功能覆盖率定100%，非核心功能80%就够了。
警告：覆盖率只是手段，不是目的。别为了好看的数字，牺牲了验证质量。
四、验证计划模板——拿来就能用
说了这么多理论，给个实际模板吧。这是我这些年打磨出来的结构：
1. 验证范围
- 模块列表（含优先级）
- 功能点清单（含风险等级）
- 不验证范围（明确说明）
2. 验证方法
- 各模块验证策略（UVM/formal/C-model）
- 测试用例分类（功能/异常/随机）
- 覆盖率模型设计
3. 执行计划
- 里程碑节点
- 资源分配
- 风险预案
4. 验收标准
- 覆盖率目标（分模块设定）
- 回归测试通过率
- 遗留问题处理规则
我曾经用这个模板帮一个团队做验证计划，原来他们写计划要花两周，现在两天就能搞定。关键不是模板本身，而是你清楚每个条目背后要回答什么问题。
五、避坑指南——我踩过的那些坑
最后分享几个我亲身经历过的教训：
- 坑一：计划写得太完美。我曾经花了一个月写了一份50页的验证计划，结果项目需求一变，全废了。现在我的计划最多10页，留出30%的弹性空间。
- 坑二：覆盖率目标一刀切。所有模块都定90%？别傻了。控制逻辑和数据处理逻辑的风险完全不一样，目标应该分开设。
- 坑三：忽略回归测试计划。很多人只关注新功能的验证，忘了回归。结果新功能没问题，老功能反而坏了。回归测试的覆盖率目标应该单独列出来。
嗯，说到这我想起来了。有一次我接手一个项目，验证计划里写了「所有模块覆盖率目标95%」。我一看，有个模块是简单的寄存器配置，根本没什么功能点。硬要凑95%的覆盖率，纯属浪费时间。后来我把那个模块的目标改成了70%，省下来的时间全用在了核心数据通路的验证上。
所以啊，验证计划这东西，灵活比完美重要。你想想看，计划是给人用的，不是用来供着的。只要能把验证工作引导到正确的方向上，这就是一份好计划。