2. 验证基础回顾

在进入覆盖率收敛与签核的深水区之前，有必要把验证工作的“坐标系”重新校准一遍。SoC验证不是设计完成后的附属检查，而是与架构、RTL、后端并行推进、相互约束的系统工程。理解验证在流程中的位置、验证计划的来源、验证平台的层次，以及覆盖率的多重含义，是后续所有收敛策略的基础。

一、验证在SoC设计流程中的位置

一个典型的SoC项目从需求定义到流片，验证活动贯穿始终，但不同阶段的验证目标和对象差异很大。可以用“V模型”来理解：左侧是设计抽象层级逐级下降，右侧是验证层级逐级上升，验证与设计在每一层形成对应关系。

• 需求与架构阶段：验证团队参与规格评审，识别可验证性需求，制定验证策略，确定IP复用与自研边界。
• 模块级（Block Level）：针对单个IP或功能模块，验证其内部功能、接口协议和边界条件，通常由IP负责人主导。
• 子系统级（Subsystem Level）：验证多个模块集成后的数据流、时钟域交互、电源域切换和总线互连行为。
• SoC级：验证完整芯片的启动流程、软件可见行为、外设协同、低功耗序列和系统性能。
• 硅后与系统级：在FPGA原型、Emulation或硅后测试中复现真实场景，反馈修正验证盲区。

验证不是“最后一道关卡”，而是与设计同步迭代的反馈回路。越早发现规格歧义，修复成本越低；越晚暴露集成缺陷，收敛代价越高。

二、验证计划：从规格到可执行条目

验证计划（Verification Plan）是验证工作的“合同”，它把自然语言规格转化为可执行、可追踪、可度量的验证条目。一份合格的验证计划通常包含以下要素：

• 功能点列表：将规格拆解为独立可验证的功能特性，每条有唯一ID、描述、优先级和验收标准。
• 验证方法映射：每条功能点对应采用定向测试、随机约束、形式验证还是硬件加速。
• 覆盖率目标：明确代码覆盖率、功能覆盖率、断言覆盖率的量化目标及豁免条件。
• 激励与检查策略：描述如何产生激励、如何自动检查结果、如何处理预期错误。
• 回归与签核标准：定义回归通过率、覆盖率阈值、缺陷收敛趋势等签核门槛。

三、验证平台的基本层次

无论使用UVM、SystemVerilog还是其他方法学，一个可复用的验证平台通常包含以下层次。理解这些层次，有助于在覆盖率收敛时快速定位“是激励不够、检查不全，还是覆盖率模型有误”。

四、覆盖率的基本概念与常见误区

覆盖率是验证收敛的核心度量，但它不是单一指标。常见的覆盖率类型包括：

• 代码覆盖率：行覆盖、分支覆盖、条件覆盖、翻转覆盖、状态机覆盖，反映RTL被激励“触碰”的程度。
• 功能覆盖率：基于验证计划定义的功能点，通过covergroup采样，反映设计意图是否被验证。
• 断言覆盖率：断言被触发和成功/失败的情况，反映协议和属性检查的活跃度。
• 场景覆盖率：系统级场景、性能场景、低功耗场景的覆盖，通常需要跨模块联合定义。

一个典型的覆盖率收敛判断流程可以简化为：

1. 运行回归，收集所有测试的覆盖率数据库
2. 合并覆盖率，生成总体覆盖率报告
3. 分析未覆盖项：
   - 代码未覆盖 → 检查激励是否缺失或约束过紧
   - 功能未覆盖 → 检查coverpoint定义与场景映射
   - 断言未触发 → 检查断言条件与激励时序
4. 区分“可覆盖”与“不可覆盖”：
   - 不可覆盖项需记录豁免理由并评审
5. 补充定向测试或调整约束，迭代回归
6. 达到签核阈值后，冻结覆盖率模型并归档

五、案例场景：一个总线模块的验证收敛片段

假设某SoC中一个AXI总线互连模块，初始回归后代码覆盖率92%，功能覆盖率68%。分析发现：

• 未覆盖的代码集中在错误响应路径和低功耗握手状态。
• 功能覆盖未命中项主要是“同时读写冲突”和“QoS优先级反转”交叉场景。
• 断言覆盖率中，部分超时断言从未触发，说明激励未构造足够长的等待场景。

验证团队据此补充了三类定向测试：错误注入测试、并发冲突测试和低功耗序列测试，并调整了随机约束的权重。两轮回归后，代码覆盖率提升至98.5%，功能覆盖率提升至94%，剩余未覆盖项经评审确认为不可达或冗余逻辑，予以豁免。这个过程体现了覆盖率收敛的基本节奏：度量 → 分析 → 补激励 → 再度量 → 评审豁免。