2. 性能验证计划制定
性能验证计划不是把架构文档里的指标抄一遍，而是把“架构规格中的性能承诺”翻译成“可执行、可判定、可追溯的验证用例集合”。这一翻译过程的核心是三件事：从架构规格中提取可测量的性能参数，沿着数据通路找出真正决定系统性能的关键路径，再把关键路径上的压力条件组织成典型场景，并为每个场景绑定明确的验收标准。缺少任何一环，验证计划都会退化成“跑一堆用例、看一堆波形、最后说不清是否达标”。
一、从架构规格提取可测量的性能参数
架构规格通常用自然语言描述性能目标，例如“支持 4K@60fps 视频解码”“DDR 带宽满足多核并发访问”“中断响应延迟低于 2μs”。这些描述不能直接作为验证目标，必须先转成带单位、带条件、带测量点的参数。转换时至少明确四个要素：指标名称、目标值、测量条件、测量点。
以“DDR 带宽满足多核并发访问”为例，可拆解为：指标名称为 DDR 有效读带宽；目标值为 ≥12.8GB/s；测量条件为 4 个 CPU 核同时执行流式读、L2 缺失率约 30%、DDR 控制器工作在 1600MHz；测量点为 DDR 控制器与 PHY 之间的 AXI 事务统计。只有写成这样，后续才能设计激励、放置探针、判定结果。若规格只给出“高带宽”，则必须回到架构团队确认量化边界，否则验证计划无法闭环。
二、沿数据通路识别关键路径
关键路径是系统中“最慢或最容易被争用”的那条通路，它决定了整体性能上限。识别关键路径不能只看模块清单，而要沿真实数据流走一遍：从发起者（CPU、DMA、加速器）出发，经过互连、缓存、内存控制器、外设，直到最终落点，记录每一跳的带宽、延迟和并发能力。
例如一个典型的 SoC 视频通路：视频解码器 → 系统总线 → DDR 控制器 → DDR 颗粒。若解码器输出 4K@60fps、每像素 1.5 字节，则原始码流带宽约为 3840×2160×60×1.5 ≈ 746MB/s；但解码过程中还存在参考帧读写、显示回读等额外流量，实际 DDR 侧压力可能是原始码流的 2～3 倍。此时关键路径不是解码器本身，而是 DDR 控制器及其仲裁策略。验证计划就应把 DDR 控制器作为重点观测对象，而不是平均用力。
三、把关键路径压力组织成典型场景
典型场景不是随机挑几个用例，而是围绕关键路径构造“最坏但合理”的并发组合。构造时遵循三个原则：覆盖真实并发、逼近资源上限、包含边界切换。
以 DDR 关键路径为例，可设计四类场景。第一类是单路 4K 解码加显示回读，验证基础通路是否达标；第二类是 4 核并发流式读叠加解码，制造仲裁争用；第三类是中断风暴场景，让多个外设同时发起中断，观察 CPU 响应延迟是否被拉长；第四类是低功耗模式切换，验证频率切换过程中带宽是否出现跌落。每个场景都要写清激励来源、并发数量、持续时间、观测窗口和预期行为。
场景设计中最容易犯的错误是“只测峰值、不测持续”。DDR 带宽在短时突发下可能达标，但在持续 10 秒以上的混合读写中，由于刷新、行切换和仲裁开销，有效带宽可能下降 20%～30%。因此验收标准必须规定统计窗口，例如“在 10 秒稳定期内，每 100ms 采样一次，取 P95 值作为判定依据”。
四、验收标准的写法与判定口径
验收标准要同时回答三个问题：看什么、看多久、怎么算通过。以中断延迟为例，不能只写“延迟低于 2μs”，而应写成：在 4 核并发、每秒 5 万次中断的条件下，连续采集 60 秒，统计从外设置位到 ISR 第一条指令执行的延迟，要求 P99 ≤ 2μs、最大值 ≤ 5μs、无丢失中断。这样才具备可判定性。
对于带宽类指标，建议同时给出平均值和 P95 值。平均值反映整体水平，P95 反映尾部抖动。若只卡平均值，可能掩盖周期性跌落；若只卡 P95，又可能忽略长期趋势。两者结合，才能既看总量又看稳定性。
| 性能参数 | 典型场景 | 验收标准（示例） | 测量点 |
|---|---|---|---|
| DDR 有效读带宽 | 4 核流式读 + 4K 解码 | 10s 窗口内均值 ≥12.8GB/s，P95 ≥11.5GB/s | DDR 控制器 AXI 事务计数器 |
| 解码帧率 | 单路 4K@60fps 解码 | 连续 60s 无丢帧，帧间隔抖动 <5% | 解码器输出帧计数器 |
| 中断响应延迟 | 中断风暴（5 万次/秒） | P99 ≤2μs，最大值 ≤5μs，无丢失 | 中断控制器时间戳寄存器 |
| 低功耗切换带宽 | 频率切换 + 并发访问 | 切换后 1ms 内恢复至 ≥90% 目标带宽 | DDR 控制器性能计数器 |
五、从计划到可执行用例的映射
完成参数提取、关键路径识别、场景构造和标准定义后，最后一步是建立映射表，把每个性能参数对应到具体用例。映射表至少包含：用例 ID、目标参数、场景描述、激励脚本、探针位置、判定条件、优先级。优先级建议按“关键路径优先、并发压力优先、边界切换优先”排序，确保有限仿真资源先覆盖最可能暴露瓶颈的部分。
例如用例 PERF-DDR-004：目标参数为 DDR 有效读带宽；场景为 4 核并发流式读叠加 4K 解码；激励脚本配置 4 个 CPU 核以 128B 步长连续读取 512MB 区域，同时启动解码器；探针放在 DDR 控制器 AXI 从端口；判定条件为 10 秒窗口内均值 ≥12.8GB/s 且 P95 ≥11.5GB/s；优先级为 P0。这样的用例可以直接交给验证工程师执行，不需要再回头猜测意图。
在实际项目中，建议把这条链固化成一份可维护的映射表，并随着架构迭代同步更新。当架构规格变更时，只需回溯受影响的参数和用例，而不必重新设计整个验证计划。这样，性能验证才能从“一次性活动”变成“可持续跟踪的工程能力”。