1. 课程导入

在移动终端、可穿戴设备、物联网节点和车规芯片中，功耗已经和性能、面积一样，成为SoC设计的核心指标。一颗SoC即使算力再强，如果待机电流过大、唤醒响应迟缓，也无法通过整机续航与热设计约束。而在这背后，真正决定“什么时候开、什么时候关、用多大电压、跑多快时钟”的模块，正是电源管理单元（PMU，Power Management Unit）。

PMU并不是简单的“电源开关”。它是一套跨越模拟、数字、固件与系统软件的协同系统：外部有PMIC、LDO、DCDC、晶振和复位芯片；内部有电源域、隔离单元、电平转换器、保持寄存器、时钟门控和电源状态机。PMU状态机则是这套系统的“大脑”，负责在运行、空闲、睡眠、深度睡眠、关机等状态之间安全迁移。

核心原理：PMU状态机到底在管什么

从系统视角看，PMU状态机管理的是三类资源：电源域（Power Domain）、时钟域（Clock Domain）和复位/隔离信号。一个典型的低功耗SoC会划分多个电源域，例如Always-On域、CPU域、GPU域、DDR域、外设域和存储域。每个域可以独立处于ON、RET（保持）、OFF等状态。状态机的任务，就是根据软件请求、中断事件和硬件握手信号，按正确顺序打开或关闭这些域。

为什么顺序如此重要？因为如果先断电源再隔离信号，可能产生漏电通路或亚稳态；如果先关时钟再保存上下文，可能丢失关键寄存器值。因此，PMU状态机必须遵循严格的迁移序列：请求 → 握手 → 保存上下文 → 隔离 → 关时钟 → 断电源 → 确认；唤醒时则反向执行：上电 → 释放复位 → 开时钟 → 解除隔离 → 恢复上下文 → 握手完成。

方法流程：从需求到状态机实现

一个PMU状态机项目通常遵循以下流程：

1. 功耗需求分析：明确各场景的功耗目标，例如运行功耗、待机功耗、唤醒时间、电池寿命。
2. 电源域划分：根据功能模块的供电需求，划分Always-On域、可关断域和保持域。
3. 状态定义：定义RUN、IDLE、SLEEP、DEEP_SLEEP、OFF等状态及进入/退出条件。
4. 迁移条件设计：确定每个迁移的触发源，如软件寄存器写、中断、定时器、外部唤醒引脚。
5. RTL实现与验证：用Verilog/SystemVerilog实现状态机，并通过仿真验证迁移序列。
6. 低功耗签核：使用UPF/CPF描述电源意图，进行形式验证、功耗分析和时序检查。

案例/场景：一次典型的休眠唤醒

假设一颗可穿戴SoC正在运行心率监测任务。当用户静止超过30秒，系统决定进入DEEP_SLEEP。此时PMU状态机执行以下动作：

// 伪代码：进入DEEP_SLEEP
pmu_request = DEEP_SLEEP;
wait(handshake_ack);
save_context(CPU, PERI);
assert_iso(CPU_DOMAIN);
gate_clk(CPU_DOMAIN, PERI_DOMAIN);
power_off(CPU_DOMAIN, PERI_DOMAIN);
state = DEEP_SLEEP;

// 外部RTC中断唤醒
on_rtc_irq:
  power_on(CPU_DOMAIN, PERI_DOMAIN);
  release_reset(CPU_DOMAIN);
  enable_clk(CPU_DOMAIN, PERI_DOMAIN);
  deassert_iso(CPU_DOMAIN);
  restore_context(CPU, PERI);
  state = RUN;

这个过程中，任何一步顺序错误都可能导致唤醒失败、数据丢失或漏电超标。例如，如果先解除隔离再上电，隔离单元可能处于不确定状态；如果先开时钟再释放复位，寄存器可能被随机值刷新。

误区与复盘

• 误区一：PMU只是软件的事。实际上，PMU状态机大量依赖硬件握手、隔离单元和电源开关，软件只负责发起请求和配置策略。
• 误区二：状态越多越省电。状态过多会增加迁移复杂度和验证难度，甚至引入不必要的唤醒延迟。
• 误区三：忽略唤醒时间。深度睡眠虽然省电，但唤醒延迟可能影响用户体验，需要根据场景权衡。
• 误区四：不做低功耗签核。仅靠仿真无法发现漏电通路和电源域交叉问题，必须结合UPF和形式验证。