第3章 验证计划与验证策略制定：核心概念、原理机制、实战要点
3.1 问题背景
在芯片开发周期中，验证往往占用 60%～70% 的总工时。缺少清晰验证计划的项目，通常会在验证中期陷入“盲测”——测试用例零散、覆盖率指标模糊、回归失败无从判断优先级。验证计划是连接设计规格与验证活动的“工程契约”，它回答三个核心问题：验证什么（功能点）、怎么验证（策略与方法学）、何时算完成（退出准则）。
验证计划不是文档负担，而是提前识别风险、量化验证收敛路径的决策工具。
3.2 核心概念
- 验证计划（Verification Plan）：描述验证对象、验证方式、资源安排与完成标准的工程文档。
- 验证策略（Verification Strategy）：在风险与成本约束下，对验证层次、方法学、工具链和流程的整体选择。
- 功能点（Feature Point）：从设计规格中提取的最小可验证行为单元，是覆盖建模的基础。
- 覆盖模型（Coverage Model）：功能覆盖点、交叉覆盖与断言的集合，用于量化验证充分度。
- 验证收敛（Closure）：当覆盖率、缺陷率、风险评估达到既定指标时，验证终止的条件。
验证计划与策略制定的核心流程可概括为五步：
3.3 原理机制
验证计划制定的底层机制是“目标分解 → 策略映射 → 度量闭环”：
- 目标分解：将设计规格中的功能描述拆解为独立的可测功能点。
- 策略映射：每个功能点至少映射一种验证手段——定向测试、约束随机、断言或硬件加速。
- 度量闭环：功能覆盖率反映“测了多少功能”，代码覆盖率反映“代码执行了多少”，二者共同驱动回归补充，直到满足退出准则。
3.4 流程步骤
- 解读设计规格：阅读设计文档、接口协议、时序图，列出待澄清问题。
- 提取功能点：拆解为可验证行为单元，标注优先级与风险等级。
- 确定验证层次：规划 IP 级、SoC 级、系统级的验证范围与复用关系。
- 制定验证策略：选择约束随机、断言、故障注入等方法的组合。
- 设计覆盖模型：定义功能覆盖点、交叉覆盖与断言覆盖。
- 编写并评审计划：输出计划基线，作为回归测试的准入依据。
3.5 案例说明：UART 控制器验证计划
以 UART 控制器 IP 为例，从规格中提取典型功能点，并映射验证策略与覆盖方式：
| 编号 | 功能点 | 验证策略 | 覆盖方式 |
|---|---|---|---|
| FP-01 | 波特率分频配置 | 约束随机 + 定向 | 功能覆盖点 |
| FP-02 | 8/9 位数据帧收发 | 定向测试 | 断言覆盖 |
| FP-03 | FIFO 上溢保护 | 异常注入 | 功能覆盖点 |
| FP-04 | 流控线 CTS/RTS | 断言 + 定向 | 交叉覆盖 |
| FP-05 | 中断状态清除 | 随机序列 + 定向 | 代码覆盖 + 功能覆盖 |
3.6 表格总结：验证计划关键要素
| 要素 | 作用 | 关键产出 |
|---|---|---|
| 功能点列表 | 明确验证对象 | 可追踪功能矩阵 |
| 验证层次选择 | 确定验证粒度 | 层次与模块归属表 |
| 覆盖模型 | 量化验证进展 | 覆盖率报告 |
| 回归策略 | 保障持续集成 | 回归通过标准 |
| 退出准则 | 判定验证完成 | 签核报告 |
3.7 误区提醒
- 计划没有优先级：所有功能点平均用力，导致高风险路径未被充分验证。
- 被覆盖率绑架：只追求 100% 代码覆盖率，却遗漏关键功能覆盖点，发现不了协议级缺陷。
- 忽略异常注入：仅验证正常路径，FIFO 上溢、同步失败、配置冲突等异常场景覆盖不足。
- 回归策略缺失：没有种子管理和统一回归脚本，环境变更后无法快速判断是否引入新问题。
3.8 实践清单
- 验证计划基线是否在 RTL 全面开发前建立？
- 每个功能点是否映射到至少一种验证手段？
- 覆盖率目标是否同时包含功能覆盖与代码覆盖？
- 回归脚本是否支持随机种子可重复执行？
- 退出准则是否经过设计、验证、架构三方评审确认？
回归脚本建议统一管理随机种子：例如使用
+seed=100 固定复现问题，使用 +seed=$random 扩展随机空间。# 回归脚本示例（简化）
vsim -c top_tb -do "run -all; coverage save cov.ucdb" +seed=100
vcover merge regression.ucdb cov.ucdb
vcover report -details regression.ucdb