4. 验证计划与需求追溯

在 PolarFire FPGA 项目中，验证计划不是一份“测试清单”，而是把产品需求逐条转化为可执行、可判定、可追溯的验证活动的工程契约。它的核心价值在于回答三个问题：每条需求由谁验证、用什么用例验证、验证到什么程度才算通过。如果缺少这条从需求到用例的映射链，项目后期极易出现“测了很多、但关键需求没覆盖”或“需求变更后用例未同步”的交付风险。

需求追溯的基本结构

可追溯性依赖唯一标识。建议在项目启动阶段就为需求分配稳定 ID，例如 PRD-FUNC-012、PRD-PERF-004、PRD-SEC-002，并保持其在整个验证周期内不变。每条需求向下映射到验证项（Verification Item），再映射到具体测试用例（Test Case），形成“需求 → 验证项 → 用例 → 结果”的四级链路。反向追溯同样重要：任何一个用例都应能回答“我为什么存在”，即它覆盖了哪条需求。

以 PolarFire 的 PCIe 端点设计为例，假设需求 PRD-FUNC-012 规定“设备须支持 Gen2 x4 链路训练，并在 100 ms 内进入 L0 状态”。这条需求不能只对应一个“跑通 PCIe”的用例，而应拆解为若干验证项：链路速率协商、通道宽度协商、LTSSM 状态迁移、L0 进入时间。每个验证项再对应具体用例，例如 TC-PCIE-021 验证速率与宽度、TC-PCIE-022 验证 LTSSM 从 Detect 到 L0 的完整迁移、TC-PCIE-023 用时间戳测量 L0 进入延迟。这样，需求、验证项、用例之间形成多对多但可追踪的映射关系。

验证计划的组织方式

一份可执行的验证计划通常包含以下要素：验证范围与不在范围、验证层级划分、需求追溯矩阵、覆盖率目标、验收标准、资源与进度、风险与应对。其中，需求追溯矩阵是计划的核心骨架。矩阵的行是需求 ID，列是验证项、用例 ID、验证方法、覆盖状态、结果。对于 PolarFire 这类包含硬核 IP 与 FPGA 逻辑的混合设计，验证方法需要区分仿真、形式验证、硬件测试和系统联调，并在矩阵中明确标注。

验证层级建议按“模块级 → 子系统级 → 系统级 → 板级/系统联调”划分。模块级关注 RTL 功能正确性，子系统级关注接口与协议交互，系统级关注数据通路与性能，板级关注真实电气环境与上电时序。不同层级对应不同的覆盖率目标：模块级追求语句与分支覆盖，系统级追求场景与需求覆盖，板级追求环境与接口覆盖。

覆盖率目标的设定原则

覆盖率目标不能拍脑袋定，而应结合需求风险等级和验证层级。高风险需求（如安全启动、密钥管理、DDR 训练）应要求 100% 需求覆盖和状态机全覆盖；一般功能需求可接受 95% 以上；性能类需求以实测数据达标为准，覆盖率作为辅助。代码覆盖率方面，PolarFire 的 FPGA 逻辑建议语句覆盖 ≥ 95%、分支覆盖 ≥ 90%、FSM 状态与迁移覆盖 100%；硬核 IP 若无法获取内部信号，则以接口覆盖和场景覆盖替代。

验收标准的定义

验收标准必须可判定、可复现。建议采用“通过条件 + 退出条件”双层定义。通过条件针对单个用例，例如“LTSSM 在 100 ms 内进入 L0，且链路速率协商为 Gen2、宽度为 x4”；退出条件针对整个验证阶段，例如“所有 P0/P1 用例通过，需求覆盖率 100%，无未关闭的严重缺陷，追溯矩阵无孤儿用例”。只有同时满足通过条件和退出条件，验证阶段才可关闭。

可追溯验证计划的示例片段

下面给出一份可直接参考的追溯矩阵片段，字段可根据项目裁剪，但需求 ID、验证项、用例 ID、验证方法、覆盖状态和结果六列建议保留。

需求变更时的追溯维护

需求变更后，追溯矩阵必须同步更新，否则验证计划会迅速失效。建议在变更流程中增加一个检查点：任何需求 ID 的新增、修改或删除，都必须触发追溯矩阵的审查，确认受影响的验证项和用例是否已更新。对于已执行但需求已变更的用例，应标记为“过期”并重新评估，而不是直接沿用旧结果。这样，验证计划才能始终与产品需求保持一致，为后续的覆盖率收敛和交付评审提供可信依据。

总结来说，可追溯的验证计划以需求 ID 为锚点，通过验证项拆解和用例映射，把抽象需求转化为可执行、可判定、可追踪的验证活动；覆盖率目标回答“验证到什么程度”，验收标准回答“什么时候可以停”。两者结合，才能让 PolarFire 项目的验证工作从“凭经验推进”转向“凭证据交付”。