2. 验证计划与策略制定

验证计划不是设计规格的复述，而是把“设计要做什么”翻译成“我们如何证明它确实做到了”。一份可执行的验证计划，向上承接设计规格（Spec），向下驱动测试平台搭建、用例编写、覆盖率收集与签核标准。本节围绕四个核心动作展开：需求分解、覆盖率目标定义、验证方法选择、Synopsys工具映射。

一、从设计规格到验证需求分解

需求分解的目标是把自然语言描述的功能，转化为可观察、可激励、可判定的验证条目。常用做法是建立“规格条款 → 功能点 → 验证需求 → 测试用例 → 覆盖点”的追溯链。以一条典型规格为例：“当FIFO水位达到高阈值时，若写使能有效且读使能无效，则置位满标志，并在下一拍停止接收写数据。”这条描述可拆出多个验证需求：阈值比较逻辑、写读使能组合优先级、满标志置位时序、写阻塞行为、边界水位（阈值−1、阈值、阈值+1）。

分解时建议使用“功能点编号”管理，例如 FP_FIFO_003，并记录来源规格章节、验证方法、优先级、覆盖点名称。优先级可按风险划分：影响数据通路正确性、协议合规性、复位与时钟域交叉的条目为高优先级；仅影响性能统计或调试寄存器的条目可降级。分解完成后应做一次“反向检查”：每条规格是否至少对应一个验证需求，每个验证需求是否可被某个测试或断言观测。

二、覆盖率目标定义

覆盖率不是越高越好，而是“该覆盖的都覆盖，且能解释为什么”。通常分三层定义：

• 代码覆盖率：行覆盖、条件覆盖、翻转覆盖、状态机覆盖。用于发现未激活的逻辑，但不保证功能正确。
• 功能覆盖率：由验证需求提炼的覆盖点，如水位区间、读写组合、错误注入类型、协议状态跳转。
• 断言覆盖率：SVA断言被触发/成功/失败的情况，用于证明关键时序属性被实际激励过。

目标值应结合模块风险与项目阶段设定。例如，一个中等复杂度的AXI从端模块，可设定：代码行覆盖≥95%，条件覆盖≥90%，功能覆盖点100%命中，关键断言覆盖率100%。同时定义“豁免机制”：对不可达代码、冗余逻辑、测试模式专用路径，需记录豁免理由并经评审确认，避免用豁免掩盖验证漏洞。

三、验证方法选择：UVM、形式化与原型验证

三种方法并非互斥，而是按验证对象和风险分层使用。UVM适合随机约束激励、复杂协议交互、可复用验证IP的场景；形式化适合控制逻辑、仲裁器、状态机、寄存器访问权限等小规模但状态空间密集的模块；原型验证（FPGA/Emulation）适合系统级场景、软硬件协同、长序列真实流量。选择时可参考以下判断：若模块接口协议复杂且需要大量随机组合，优先UVM；若模块状态空间有限但需要穷举证明，优先形式化；若需要跑操作系统或真实外设数据流，优先原型验证。

四、Synopsys工具映射与执行闭环

方法选定后，需要落到具体工具链。UVM平台通常以VCS为仿真引擎，配合Verdi做波形调试与覆盖率分析；形式化验证使用VC Formal，将SVA属性与设计RTL一起读入，通过证明或反例定位问题；原型验证使用ZeBu或HAPS，把RTL综合到FPGA或仿真加速器上，运行真实软件负载。工具映射的关键是“同一验证需求在不同工具间可追溯”：例如功能点FP_FIFO_003在UVM中对应一个约束随机测试，在VC Formal中对应一条断言，在覆盖率数据库中对应一个覆盖点。

五、一个可参考的验证计划片段

以下以FIFO模块为例，给出验证计划中“需求—覆盖—方法—工具”的对应关系示例（参数为教学假设，非实测数据）：

这张表本身就是验证计划的骨架。后续编写测试用例时，每个用例应关联至少一个验证需求编号；运行仿真后，覆盖率报告按功能点聚合，未命中的覆盖点直接定位到对应需求，判断是激励不足、约束过紧还是设计缺陷。形式化部分则把断言与需求编号绑定，证明通过即视为该需求在形式化范围内被覆盖。

六、签核标准与迭代

验证计划不是一次性文档。随着验证推进，覆盖率数据、形式化证明结果、原型验证发现的缺陷都会反馈回来，触发需求分解的修正或覆盖目标的调整。签核标准应在计划阶段就明确：例如“所有高优先级功能点100%覆盖，代码行覆盖≥95%，关键断言全部证明通过，无未关闭的高优先级缺陷”。只有标准前置，验证团队才能在项目后期避免“覆盖率达标但风险未收敛”的被动局面。

总结来说，验证计划与策略制定的核心是建立一条从规格到签核的可追溯链路：需求分解保证“验什么”清晰，覆盖率目标保证“验到什么程度”可量化，方法选择保证“怎么验”匹配风险，工具映射保证“用什么验”可落地。四者对齐，验证工作才能从被动执行转为主动收敛。