4. 验证策略与测试计划制定
TI 智能汽车计算平台的验证工作，不能简单照搬通用芯片或通用软件的测试流程。TDA4VM、AM62A 这类 SoC 同时包含 Cortex-A72 应用核、Cortex-R5F 实时安全核、C7x/MMA 深度学习加速器、ISP、MCU 域、安全岛以及大量车规外设，DV（Design Verification，设计验证）与 PV（Production Validation，量产验证）必须围绕这些真实硬件资源来划分范围。本节要解决的核心问题是：如何基于 TI 平台特性定义 DV/PV 的测试范围、测试层级、进入退出准则，并把资源与排期组织成一份可执行的验证计划。
一、先分清 DV 与 PV 的边界
在 TI 平台上，DV 面向“设计是否做对了”，主要覆盖 IP 级、子系统级和 SoC 级功能正确性，通常在 RTL/仿真、FPGA 原型或早期硅片上完成；PV 面向“量产件是否稳定一致”，关注工艺角、温度、电压、批次差异以及长期可靠性，必须在真实量产硅片和真实板级环境下完成。两者不是先后替代关系，而是有交叠的并行活动。
以 TDA4VM 为例，DV 阶段重点验证：Cortex-R5F 锁步（lockstep）比较逻辑、MCU 域安全岛的自检与错误注入、C7x 与 MMA 的矩阵运算吞吐、CSI-2 多路摄像头输入、PCIe/USB/以太网等高速接口的协议一致性。PV 阶段则重点验证：全温度范围（-40℃~125℃ 结温）下的功能保持、电压拉偏（如 0.8V 核心电压 ±5%）、老化（HTOL）后的参数漂移、以及不同批次之间的性能分布。把这两类目标混在一张测试表里，会导致 DV 阶段被 PV 的样本量拖慢，或 PV 阶段遗漏设计缺陷。
二、测试层级与 TI 平台资源的对应
建议把验证层级划分为五层，并与 TI 提供的工具链和硬件资源一一对应：
- IP 级：针对单个 IP（如 R5F、C7x、DDR 控制器）的寄存器与功能验证，使用 TI 提供的 IP 验证套件和 UVM 环境。
- 子系统级：如 MCU 域、视觉预处理子系统（VPAC）、深度学习子系统，验证跨 IP 的数据流与中断/事件联动。
- SoC 级：在 TI EVM（如 J721E EVM）上运行完整固件，验证启动流程、电源管理、时钟树、安全启动链。
- 板级/系统级：接入真实传感器、执行器、车载网络，验证端到端时延与功能安全机制。
- 量产级：在量产板与量产硅片上执行 PV 项，覆盖温度、电压、批次与老化。
层级之间不是简单叠加，而是“下层通过才允许进入上层”的准入关系。例如 SoC 级启动验证未通过前，不应把资源投入到板级端到端测试，否则问题定位会被传感器和线束噪声掩盖。
三、进入与退出准则的量化定义
准则必须可量化、可判定，否则计划无法执行。以下给出一个可参考的示例定义（参数为教学示例，实际项目需按产品等级调整）：
| 阶段 | 进入准则 | 退出准则 |
|---|---|---|
| IP 级 DV | RTL 冻结、验证环境编译通过 | 功能覆盖率 ≥ 95%，代码覆盖率 ≥ 90%，无 P0 缺陷 |
| 子系统级 DV | 相关 IP 级退出、子系统集成完成 | 跨 IP 数据流用例全部通过，中断/事件联动无异常 |
| SoC 级 DV | 子系统级退出、EVM 板可用 | 启动链、电源管理、安全启动全部通过，P0/P1 缺陷清零 |
| 板级/系统级 | SoC 级退出、传感器与线束就绪 | 端到端时延满足指标，功能安全机制触发正确 |
| PV | DV 全部退出、量产硅片与量产板到位 | 全温区/电压拉偏用例通过率 100%，批次分布收敛 |
注意“通过率 100%”只针对 P0/P1 用例，P2/P3 允许有条件的遗留，但必须记录并评估风险。进入准则中的“测试环境与量产配置一致”尤其关键：如果 DV 阶段用的是工程样片而 PV 用量产片，时钟树和电源行为可能不同，必须重新确认配置基线。
四、资源与排期的组织方式
TI 平台验证的资源主要包括：EVM 板与量产板、仿真/FPGA 原型、示波器与协议分析仪、温箱与老化设备、以及具备 TI 工具链（CCS、SysConfig、PDK）经验的验证工程师。排期建议采用“关键路径 + 并行支路”的方式：
- 关键路径：IP 级 → 子系统级 → SoC 级 → 板级 → PV，这条链决定项目最短周期，资源优先保障。
- 并行支路：PV 的温箱与老化测试可在 SoC 级 DV 后期提前启动，因为其样本准备周期长；安全机制的错误注入可与功能测试并行。
- 缓冲：每个层级预留 15%~20% 的时间缓冲，用于缺陷修复后的回归。
以一个 12 个月的验证周期为例（示例排期）：IP 级 DV 第 1~3 月，子系统级第 3~5 月，SoC 级第 5~8 月，板级第 7~10 月，PV 第 9~12 月。其中第 7~8 月是板级与 SoC 级的重叠期，需要明确资源分配，避免同一批工程师被两条线同时占用。
五、可执行的验证计划输出
验证计划最终要落到一份可跟踪的文档，建议至少包含以下字段：验证项编号、所属层级、对应 TI 资源（IP/子系统/接口）、测试类型（功能/性能/安全/可靠性）、进入条件、退出条件、所需设备、责任人、计划开始与结束时间、当前状态。下面给出一个可直接参考的示例片段：
验证项: DV-SOC-012
层级: SoC 级
对象: Cortex-R5F 锁步比较逻辑
测试类型: 功能安全
进入条件: 子系统级 DV 退出，EVM 板启动正常
测试方法: 通过 CCS 注入 R5F 比较错误，观察 ESM 是否触发
退出条件: 错误注入 100 次全部被捕获，无漏报
设备: J721E EVM、CCS、调试探针
责任人: 张工
计划: 第 6 月第 2 周 ~ 第 6 月第 4 周
状态: 未开始
这份计划的价值在于：每个验证项都能追溯到具体的 TI 硬件对象和可判定的退出条件，而不是停留在“完成 R5F 验证”这种无法验收的描述。排期时把 PV 的温箱与老化资源提前锁定，往往比压缩 DV 时间更能保证整体交付节奏。