3. 低功耗架构探索与验证规划

低功耗验证最容易犯的错误，是拿到 RTL 之后直接开始跑仿真，看到电流波形“看起来有变化”就认为验证过了。真正有效的做法是反向推导：先把系统级功耗目标拆解成可验证的架构假设，再把这些假设翻译成具体的电源管理场景，最后才落到验证计划。本节的核心任务，就是建立这条从“功耗目标”到“验证用例”的推导链路。

一、系统级功耗目标如何拆解为架构约束

系统级功耗目标通常以整机或芯片级指标给出，例如“典型使用场景下平均功耗不超过 800mW”“待机功耗低于 5mW”“峰值电流不超过 1.2A”。这些数字本身无法直接验证，必须拆解为架构层面的可观测约束。拆解的基本维度有三个：电源域划分、电压/频率工作点、状态切换时序。

以一个典型的 SoC 为例：CPU 子系统、GPU、视频编解码、显示控制器、常开域（AON）分别处于不同电源域。假设系统目标为“视频播放场景平均功耗 ≤ 900mW”，架构探索阶段需要回答：CPU 在视频播放时是否可降至 0.8V/800MHz？GPU 是否完全关断？DDR 是否进入自刷新？这些问题的答案决定了电源域的数量、隔离策略和状态机复杂度。

架构探索的输出不是一张功耗数字表，而是一组可验证的架构假设。例如：“视频播放时 GPU 电源域应处于关断状态，其输出隔离使能，时钟门控关闭，漏电低于 200μW”。这条假设包含了电源状态、隔离信号、时钟状态和可测量的漏电边界，已经具备转化为验证用例的条件。

二、电源管理关键场景的识别方法

电源管理场景不是简单罗列“开、关、休眠”，而是围绕状态迁移和并发事件来识别。推荐从以下四个维度展开：

• 状态维度：每个电源域有哪些合法状态（ON、RET、OFF、ISO 等），状态之间的迁移条件是什么。
• 事件维度：哪些外部事件会触发状态迁移（中断、DMA 完成、看门狗、温度传感器、软件写寄存器）。
• 并发维度：多个电源域同时迁移时，是否存在顺序依赖或竞争条件。
• 异常维度：迁移过程中出现电源未就绪、PLL 未锁定、隔离未生效时，系统如何响应。

以“CPU 从 RUN 进入 RET”为例，一个完整的场景描述应包含：软件写 PMU 寄存器触发 → 时钟分频切换 → 电压调节器降压 → 电源门控使能 → 隔离信号拉高 → 状态机进入 RET。每一步都有对应的可观测信号和预期时序窗口。验证计划中，这个场景至少需要覆盖正常迁移、迁移中收到唤醒中断、电压未稳定时强制迁移三类用例。

三、从场景到验证计划的映射

识别出关键场景之后，下一步是将其映射为验证计划中的具体条目。一个可执行的验证计划条目应包含四个要素：激励条件、预期状态序列、可观测检查点、覆盖率目标。

以“CPU 从 RUN 进入 RET 后收到唤醒中断”为例：激励条件为软件写 PMU 寄存器触发 RET 迁移，并在电压下降过程中注入唤醒中断；预期状态序列为 RUN → 时钟分频 → 电压下降中 → 中断到达 → 迁移中止 → 恢复 RUN；可观测检查点包括隔离信号是否在中断到达前已拉高、电压调节器是否收到中止命令、状态机是否回到 RUN 且时钟恢复；覆盖率目标为“迁移中止”状态被覆盖，且中断到达时间点覆盖电压下降的至少三个不同阶段。

这里有一个容易被忽略的细节：检查点的可观测性必须在验证计划阶段确认。如果隔离信号没有引出到顶层端口，或者电源状态机没有状态输出，那么再好的场景也无法验证。架构探索阶段就应推动设计团队增加必要的观测点，例如电源状态寄存器、隔离使能回读、电压调节器就绪标志等。

四、验证规划的优先级与收敛策略

电源管理场景数量可能很多，但验证资源有限。建议按风险 × 发生概率排序：高风险高概率的场景优先覆盖，例如正常迁移路径和常见唤醒事件；高风险低概率的场景（如电压未稳强制迁移）至少要有定向用例；低风险场景可以通过随机约束或形式验证补充。

收敛策略上，建议将覆盖率分为三层：状态覆盖率（每个电源域的每个状态是否到达）、迁移覆盖率（每对合法迁移是否执行）、并发覆盖率（多个域同时迁移的组合是否覆盖）。三层覆盖率全部收敛，才能认为电源管理验证基本充分。对于异常场景，可以采用故障注入的方式，在仿真中强制拉低电源就绪信号或延迟隔离使能，观察系统是否能安全恢复或进入预设的安全状态。

最后需要强调：低功耗架构探索与验证规划不是一次性活动。随着 RTL 实现细节的明确，架构假设可能需要修正，验证计划也应同步更新。建议在项目里程碑节点重新审视功耗目标和场景列表，确保验证计划始终对准真实的系统级功耗风险。