7.2 高级功耗管理：门控、电源域与DVFS

7.2 高级功耗管理：门控、电源域与 DVFS

上一节把账本立好，本节开武器库。功耗治理武器按"省得越多、代价越重"排成四层：时钟门控、多电压域、电源门控、动态调频调压。本节逐层讲清每件武器的省电机理、结构代价与适用判断，并把全章预告过的功耗状态机完整展开。读完你应当能为一个产品画出睡眠策略蓝图，并知道每一层武器的坑在哪里。

省电的四层境界

第一层：时钟门控。动态功耗的账本里，时钟网络独占两三成——而且即使模块闲置，只要时钟还在翻转，钱就照烧。时钟门控的思路直接：闲置模块的时钟整个掐断，寄存器不翻转，开关功耗归零。它的实现是一格门控单元（锁存器加与门）把时钟与使能信号相与，综合工具能按寄存器组的共享使能自动插入（4.3 节的优化清单里有它）。门控的代价极小、省电立竿见影，是功耗治理的"义务劳动"——没有理由不做的意思。它的边界也要记住：只治动态不治静态，时钟停了漏电照漏；且门控使能的生成时机不对（掐得太晚、放得太早），省电窗口就缩水。

第二层：多电压域。利用 7.1 节的平方关系，把不同性能要求的模块放进不同电压：计算域高压跑得快，外设域低压省着跑。它比门控更进一步，但引入了新的结构问题——域间信号要过电平转换器（高压域看不懂低压信号），转换器有面积与延迟代价，所以域的划分要跟 3.1 节的时钟域协同规划，域数每加一个，转换与签核的负担同步上涨。

第三层：电源门控。治静态的重炮：给整个域串一个"睡眠晶体管"，睡眠时整域断电，漏电近乎归零。代价是三笔：状态丢失（断电域里的寄存器内容蒸发，要么事前转存、要么域内用保持寄存器，两者都是面积与流程的开销）；唤醒延迟（供电网络重新充电要时间，且唤醒瞬间电流冲击大，6.1 节的电源主干要能扛）；验证负担（断电与上电的时序、隔离与转存流程，都要进验证与签核）。所以电源门控的哲学是挑肥拣瘦：只对"睡得久、醒来慢点无所谓"的域动手，CK770 挑中的是外设域与加速器，常开域永远不睡。

第四层：动态调频调压。前四层都是"省闲钱"，这一层管"干活也省"：负载轻时降频降压，负载重时恢复。它的省电逻辑还是平方关系，但难点在决策——什么时候降、降多少、升回来的延迟会不会伤性能。这套决策机制（调度器）通常落在固件与电源管理单元（3.1 节的选型呼应点），是硬件机制与软件策略的合谋。

图：CK770 电源域规划与睡眠状态机

状态机的经济学：睡与醒的算术

功耗状态机（支柱页预告、上图右）是所有武器的调度中枢，它的每一次迁移都是一笔小账：睡眠收益等于平均功耗差乘以睡眠时长，唤醒开销等于恢复时间乘以这段时间的额外功耗（唤醒瞬间往往比活跃态更耗）加延迟的机会成本。浅睡态唤醒快、省得少；深睡态省得多、恢复慢——状态机的艺术在于让负载的时间结构匹配状态的切换成本：负载碎片化严重（频繁小任务）就该赖在浅睡态，负载有长空闲段才值得深睡。

CK770 采集与推理交替的负载画像正适合这张状态机：采集窗口间有秒级空闲，足够深睡一轮；但每个采集窗口前的唤醒要限时完成（传感器会话有超时），所以深睡的恢复路径被设计成"外设域快速上电加计算域降压维持"的折中——不是所有域都睡到最深，组合式睡眠比"全有或全无"更贴负载。

工程上还有一条容易被忽视的纪律：状态机本身要被验证。迁移条件、唤醒仲裁、误唤醒处理，都要有覆盖点（5.1 节的方法论在这里复用）——睡眠策略的 bug 表现不是功能错，是"电池寿命对不上承诺"，这类缺陷在真机上极难复现，仿真阶段不抓住，量产后就是悬案。

门控还有一个粒度选择的技术账：按寄存器位组共享使能自动插入门控单元，粒度细、省得干净，但门控单元自身占面积、且使能信号网络要布线；粒度粗（整个模块一个总门）省面积，但模块内只要有一个寄存器活跃，全模块的时钟都得开着。综合工具的默认策略是按使能信号的共享度聚类，工程上要复核的是两个极端——被聚成一门的大模块里是不是混着"闲不下来"的寄存器（混着就把门控白占了），以及孤立的几位是不是各挂一门（门控单元的开销反超收益）。

常见问题辨析

问：电源门控的域切得越多越省吗？

不是。每多一个可断电域，就多一套睡眠晶体管、隔离单元、转存逻辑与上电时序状态，面积与验证成本线性上涨，而收益按域内漏电占比递减——漏电不多的域断个电，省的钱还不够付转存的折腾。判断式很朴素：域内漏电在待机科目里占比可观、且该域的睡眠时长明显超过唤醒开销的回收线，才值得切。CK770 只切外设与加速域，把计算域留在"只降压"档，就是这道算术的结果。

问：调频调压的切换过程中，芯片还能干活吗？

分两段看。电压上行（升压再升频）期间通常可以继续跑旧频率，安全无虞；电压下行则要"先降频、稳住、再降压"，顺序反了会出现"低压跑高频"的窗口，时序当场崩溃。所以切换期间芯片能干活，但性能处于降档状态，切换的过渡时间要从性能预算里扣。工程上的对策是把切换频率压到最少——按负载段调档，而不是逐事件调档，让过渡开销被摊薄到不可见。

问：多核系统的功耗管理，究竟是硬件的活还是软件的活？

分工有一条清晰的分界线：机制在硬件，策略在软件。门控单元、睡眠晶体管、电压档位切换的时序保障，这些是硬件提供的"扳手"；什么时候拧、拧多大，是软件策略（调度器与电源管理驱动）依据负载画像做的决策。跨界的那根线是状态机：硬件保证状态迁移的原子性与安全性，软件只投递意图。职责写混的项目会出两类事故——软件绕过时序保障直接拨电源（第七章实验里的毛刺教训），或硬件自作主张深睡错过唤醒窗口。接口冻结文档里，这根线必须画得清清楚楚。

问：深睡态下的唤醒源，为什么必须来自常开域？

因为深睡时其余域的时钟与供电都已撤除，没有任何逻辑能"听见"外界——能守夜的只有常开域。这也解释了域规划里常开域的三件标配：低速时钟（不分昼夜地走）、唤醒比较器（监视中断引脚与定时器到点）、以及最精简的仲裁逻辑（判断这次唤醒值不值得把全家叫醒）。固件侧的配套责任是"睡前布岗"——把哪些事件可以唤醒、哪些事件睡后再处理的配置写进常开域寄存器，布岗漏了，该醒的醒不来，表现为设备"睡死"。

问：睡眠策略的阈值参数，流片之后还能调吗？

能调的留软件，不能调的靠余量。空闲计数的阈值、切换的迟滞窗口、调档的负载判据，这些策略参数都设计成寄存器可配，由固件按产品场景在线调优——这也是"机制在硬件、策略在软件"分工的直接好处。但唤醒时延、状态保持时间这类由电路结构决定的物理量，流片即定型，软件只能绕不能改。CK770 的经验是把两类参数在文档里分开列：可调区写清取值范围与联动关系，定型区写清实测值与置信度——客户调优时不至于在"改不动"的参数上白费功夫。

本节要点回顾

• 四层武器按代价递进：时钟门控（义务劳动，只治动态）、多电压域（治动态加静态，代价是电平转换）、电源门控（治静态重炮，代价是转存唤醒验证）、调频调压（干活也省，代价是策略复杂度）。
• 电源门控挑肥拣瘦：只对睡得久、醒得慢无所谓的域动手；状态金贵的域只降压不断电。
• 状态机每次迁移都是账：睡眠收益对唤醒开销加延迟成本；组合式睡眠比全有或全无更贴真实负载。
• 睡眠状态机自身要有覆盖点与验证计划——功耗策略的缺陷在真机上几乎不可复现。

武器都认识了吧？下一节把账本与武器合起来，在第四章那颗最小 SoC 上做一次完整实操：立账、加门控、算节余、验正确性。