验证计划模板：从 Spec 到覆盖率收口的一份可复制 vplan
本篇属于芯片验证方法论的中间层：上游是 IC 规格书写法（Spec 怎么写才可验证），下游是 testplan 与覆盖率映射 和 功能覆盖率收口计划（映射与收口的细节展开）。这一篇不发明新方法，只做一件事：给你一份能直接复制进项目仓库、按字段填空的验证计划模板（vplan），并把「Spec → 功能点 → 覆盖率 → 断言 → 用例」这条追踪链讲透。
很多团队的验证计划死在两个极端：要么是一份 Word 里几十页散文，评审时人人点头、执行时无人对照；要么是 Excel 里几百行功能点，字段乱到只有作者本人能看懂。两种形态的共性问题是一样的——功能点不可追踪：问「Spec 第 3.2 节的回压行为验证完了吗」，没人能在三十秒内给出覆盖率数字、对应用例和当前状态。本文的模板就是围绕「可追踪」三个字设计的。
本文要回答的问题
- 一份合格的验证计划必须包含哪几个字段，每个字段填什么、不填什么？
- 「从 Spec 到覆盖率收口」的追踪链怎么在表格里落地，而不是停留在口头？
- 功能点拆到什么粒度才算够细，又不会细到维护不动？
- 模板里的每个字段在回归执行阶段分别被谁消费？
- 拿到模板之后，前两个小时应该先做哪些动作？
一、验证计划到底在回答谁的问题
写 vplan 之前先想清楚读者是谁。一份 vplan 至少服务四类人：验证工程师自己（执行时知道该写什么用例）、验证经理（评审时判断完备性、收口时判断能不能签）、设计工程师（回答「我这条逻辑有人验吗」）、以及半年后接手维护的陌生人（可能是你自己）。四类读者的共同诉求只有一个：任意挑一条 Spec 条目，能立刻定位到它的验证证据链。
所以 vplan 的本质不是「计划」，而是一张活的追踪表。它从 Spec 出发，把每条可验证的需求拆成功能点，给每个功能点挂上三类验证手段（定向用例、随机用例、断言），再挂上覆盖率目标，最后在回归中不断回填状态，直到收口。验证签核的标准动作——对照功能点逐项确认覆盖率和用例状态——在 验证签核标准方法论 里有完整展开，本文只管把承载这些信息的模板给出来。
下面这张流程卡概括了从 Spec 到收口的四段链路，也是本文模板的四个核心分区：
读这张图注意链路的方向性：功能点是唯一入口，覆盖率、断言、用例都是从功能点长出来的分支，而不是三个各自为政的清单。很多项目的问题恰恰是三张清单分离——covergroup 写了一批但对不上功能点，断言写了一堆但没人知道覆盖了哪条 Spec。模板设计的第一原则就是让这三列永远出现在同一行里，物理上杜绝脱节。
二、模板的骨架：一张主表加三个小节
模板由一个文件头、三个固定小节、一张功能点主表组成。文件头记录版本与责任人，三个小节分别回答「验什么范围」「用什么环境」「什么叫验完」，主表承载追踪链。先给完整模板，再逐字段解释。
# vplan: <模块名>
- 版本: v0.1 ｜ 作者: <姓名> ｜ 日期: YYYY-MM-DD
- 对应 Spec: <文档名+版本号+章节基线>
- 评审记录: <评审日期 / 结论链接>
## 1. 验证范围
- In scope: <本计划覆盖的接口、模式、配置>
- Out of scope: <明确不验的内容及理由，如模拟部分、DFT 逻辑>
- 假设与依赖: <依赖的 VIP、参考模型、固件版本>
## 2. 验证环境
- 方法学: UVM 1.2 ｜ 仿真器: <VCS/Xcelium/Questa + 版本>
- 激励来源: <定向 / 约束随机 / VIP 序列>
- 检查手段: <scoreboard 比对 / SVA / 参考模型>
- 覆盖率模型: <covergroup 所在文件>
## 3. 收口标准
- 功能覆盖率: goal = 100%（豁免项需评审批准）
- 代码覆盖率: line/toggle/FSM ≥ 99%，豁免走流程
- 断言: 无未解释 fail；cover 属性命中率 100%
- 回归: 最近 N 轮全绿，无 open 的 P0/P1 bug
## 4. 功能点主表
| ID | Spec 条目 | 功能点 | 类型 | 验证手段 | 覆盖率/断言 | 用例 | 状态 |
|----|-----------|--------|------|----------|-------------|------|------|
| FP-001 | §3.2.1 | 单拍读事务基本时序 | 协议 | 定向+SVA | cov_axi_rd / asrt_ar_valid | tc_rd_basic | done |
| FP-002 | §3.2.2 | 回压下 valid 保持 | 协议 | 随机+SVA | cg_bp.cp_valid_hold / asrt_valid_stable | tc_bp_rand | doing |这份模板可以直接复制进项目的 docs/ 或验证环境根目录，用 Markdown 的好处是：纯文本可 diff、可进 git 评审、可被脚本解析（很多团队写个小脚本把主表导成 Excel 给管理层看，源数据仍留在 git 里）。
三、主表逐字段拆解
主表的八列各有明确职责，填的时候宁缺毋滥——宁可某一列留空标注「待定」，也不要填一个含糊的词糊弄评审。
| 列 | 填什么 | 常见错误 |
|---|---|---|
| ID | 全局唯一编号，建议 FP-<模块缩写>-<序号>，永远不复用已删编号 | 删除功能点后把后面的编号往前挪，历史记录全断 |
| Spec 条目 | Spec 文档的章节号（如 §3.2.1），一行对应一个章节条目 | 写「见 Spec」三个字，等于没写 |
| 功能点 | 一句可判定真伪的话：「回压期间 valid 不得拉低」 | 写「验证读通道」，无法判定验没验完 |
| 类型 | 协议 / 数据 / 异常 / 性能 / 配置，五选一 | 类型混写，后期按类型统计覆盖率时抓瞎 |
| 验证手段 | 定向 / 约束随机 / SVA / formal，可组合 | 只写「仿真」，无法判断激励来源 |
| 覆盖率/断言 | covergroup 名、coverpoint 名或断言宏名，与代码里的标识符一致 | 名字与代码不一致，覆盖率反向映射对不上 |
| 用例 | 回归套件里的用例名，可多个 | 写用例的中文描述而不是真实用例名 |
| 状态 | todo / doing / done / waived（豁免需链接评审记录） | 用「基本完成」「差不多了」这种不可机检的词 |
三个字段值得单独强调。功能点列是全表的灵魂，判定标准是「这句话要么成立要么不成立，没有中间态」——「读通道功能正确」不是功能点，「AR 握手后 R 通道在 N 拍内返回数据」才是。覆盖率/断言列必须与代码里的标识符严格一致，这是收口阶段做「vplan ↔ 覆盖率数据库」反向映射的锚点，映射的具体做法见 testplan 与覆盖率映射。状态列只允许四个枚举值，waived 必须挂豁免评审的链接，否则收口审计会打回。
四、功能点拆分的粒度与类型配比
拆功能点最容易犯的错是粒度失控。判断粒度合不合适的经验法则：一个功能点对应一到三条 coverpoint 或一到两条断言。如果拆完发现某个功能点需要挂二十个 coverpoint 才能覆盖，说明拆得太粗，该往下再拆一层；如果一个 coverpoint 被五六个功能点同时引用，说明拆得太细，合并之。
按类型配比自查也很有用。一个健康的模块级 vplan，协议类功能点通常占三到四成，数据类两到三成，异常类（错误注入、非法配置、复位中途打断）必须占到两成以上——异常类占比过低是 vplan 评审的典型红灯，说明作者只想着「正常路径走通」，没想过「坏事发生时设计怎么反应」。性能类（吞吐、延迟、反压下的最大 outstanding）和配置类（各参数组合的交叉）按需补齐。以 AXI 类接口为例，回压、乱序、窄传输、exclusive 访问这些行为在 AXI outstanding 乱序响应检查 等篇目里有逐条的功能点示范，可以直接对照着补进自己的表里。
拆分顺序建议从 Spec 目录自上而下扫，每读一节就问自己三个问题：这节有没有可观测的行为？这个行为有没有边界条件？这个行为出错时设计应该怎么反应？三个答案分别对应正常功能点、边界功能点、异常功能点。扫完一遍，主表的行数通常是 Spec 章节条数的两到三倍——如果几乎一比一，大概率漏了边界和异常。
五、从模板到收口：字段在回归阶段被谁消费
vplan 不是写完归档的文档，它每一天都在被消费。执行阶段，验证工程师按「用例」列认领任务，写完用例在回归里跑起来，状态从 todo 翻到 doing；覆盖率模型里的 covergroup 名字从「覆盖率/断言」列抄进代码，保证两边锚点一致——covergroup 的 goal、weight、at_least 这些选项怎么配，见 covergroup goal 与权重设置。回归阶段，每晚的回归结果回填「状态」列，pass 率与覆盖率合并后按功能点聚合，聚合与豁免的流程见 覆盖率合并与豁免流程。
收口阶段，经理拿主表做三件事：按状态列筛出非 done 行逐项过；按「覆盖率/断言」列反向查覆盖率数据库，确认每个功能点的 goal 达成；按 waived 行核对豁免评审记录。三件事都依赖前面字段填得规范——这就是为什么 ID 不复用、名字与代码一致、状态只许枚举值这些规矩看似繁琐，实际是收口阶段省下的全是扯皮时间。收口标准的完整讨论（覆盖率数字之外还要看什么）见 功能覆盖率收口计划。
六、上手清单：拿到模板后的前两个小时
最后给一份可以直接照做的动作清单，适合刚接手一个新模块的验证工程师：
- 对齐 Spec 基线：和设计确认 Spec 版本号，写进文件头；Spec 还在剧烈变动的章节先在范围节标注「待冻结」。
- 扫一遍 Spec 拆功能点：按第四节的三个问题法，先把功能点主表填到七八成，不求完美，求覆盖全。
- 标类型、找异常：给每行标类型，统计异常类占比，不到两成就回去补。
- 挂上已有资产：项目里已有的用例、断言、covergroup 先对上号填进表，对不上的功能点就是真正要新写的任务。
- 约一次评审：拉上设计和另一位验证同事过一遍主表，评审纪要和结论链接回填到文件头——vplan 未经评审等于不存在。
做完这五步，你手里的就不再是一张白纸，而是一份有基线、有范围、有追踪链骨架的工作计划，剩下的执行只是沿着表格逐行推进。
这一篇在知识体系里的位置
本文是「验证规划」环节的落地模板篇：上游接 IC 规格书写法（Spec 的可验证性是 vplan 能拆出好功能点的前提），同层配合 testplan 与覆盖率映射 讲映射机制，下游收口环节见 功能覆盖率收口计划 与 验证签核标准方法论。模板中用到的覆盖率模型细节可继续深入 covergroup goal 与权重设置 和 覆盖率合并与豁免流程。
一句话总结
验证计划模板的全部价值在于「可追踪」四个字：以功能点为主键，把 Spec 条目、覆盖率模型、断言、用例、状态拴在同一行里，让任何一条需求都能在三十秒内定位到它的验证证据链——本文给出的 Markdown 模板按文件头、范围、环境、收口标准、功能点主表五段组织，复制进仓库按字段填空即可用，剩下的功夫全在功能点拆得够不够细、异常类占比够不够高。