7.3 低功耗实操：功耗预算与电源域实验
7.3 低功耗实操：功耗预算与电源域实验
账本（7.1 节）与武器（7.2 节）都备齐了，本节合起来打一仗：给第四章那颗最小 SoC 做一次完整的低功耗改造——立功耗账本、加时钟门控、模拟一个电源域的睡眠与唤醒、验证节余与正确性。全部代码在任何开源仿真器上可复现。做完本节，"功耗预算"就从一张纸变成你手上的一套动作。
实验目标：给最小 SoC 立账本
第四章的 soc_mini 有个功耗上的"毛病"：处理器桩停机后（HALTED 态），时钟照转、总线照应答，动态功耗一分不少地白烧。实验目标分四步：立账——按 7.1 节的方法给它编一张三场景账本；改造——给停机态的模块插入门控；仿真——加一个模拟的睡眠控制器，实现"空闲即浅睡、来活即唤醒"；对账——对比改造前后的翻转次数，核对节余与功能正确性。
先立账。仿真里没有真实电压电流，但动态功耗与翻转次数成正比，于是账本科目可以换成"每场景翻转次数"这个可测代理——账的格式不变（场景为行、科目为列），数字的物理意义由 7.1 节的公式换算。三场景：满载（处理器桩连续执行）、停机无门控（当前基线）、停机加门控（改造目标）。
图：改造前后各模块的翻转次数对账
动手：门控与睡眠控制器
改造分两块代码。第一块是门控单元与时钟分配——给停机态的处理器桩与总线时钟装"阀门"：
// 门控单元：锁存器加与门的标准结构（负沿锁存使能，避免毛刺） module clock_gate ( input logic clk, input logic en, // 高有效：允许时钟通过 input logic test_en, // 测试旁路（DFT 场景强制开门） output logic gclk ); logic en_latched; always_latch begin if (!clk) en_latched = en | test_en; // 时钟低电平期间采样使能 end assign gclk = clk & en_latched; endmodule
注意这段代码里的两处门道，都来自 7.2 节的坑位清单：使能在时钟低电平期间锁存（若在时钟高电平锁存，门控后的时钟可能切出半截脉冲——毛刺是门控设计的第一杀手）；test_en 旁路是可测性设计（制造测试需要全速时钟）的标配，没有它，第五章的制造测试会查不了停机逻辑。
第二块是睡眠控制器——7.2 节状态机的最小版，只有浅睡与活跃两态：
// 睡眠控制器：最小状态机（活跃与浅睡），空闲计数触发睡眠 module sleep_ctrl ( input logic clk, input logic rst_n, input logic busy, // 处理器桩报告：还在干活 output logic sleep_req, // 请求门控关断（到 clock_gate 的 en） output logic [3:0] idle_cnt ); always_ff @(posedge clk or negedge rst_n) begin if (!rst_n) idle_cnt <= 4'd0; else if (busy) idle_cnt <= 4'd0; // 有活就清零 else if (idle_cnt < 4'd15) idle_cnt <= idle_cnt + 4'd1; // 空闲计数 // 计满后保持，等待唤醒 end assign sleep_req = (idle_cnt == 4'd15); // 连续空闲即浅睡 endmodule
顶层把两者接起来：睡眠控制器的输出接门控使能，处理器桩的 HALTED 态接 busy 取反。唤醒路径用的是"总线上任何新请求立即重开时钟"的最简策略——真实的深睡唤醒要走 3.1 节的锁相环重启与 8.4 节的固件流程，这里的浅睡只演示结构。最后是测试平台的修改：让处理器桩执行完程序后空转一段，观察门控生效，再人为注入一次总线请求观察唤醒。
// 仿真日志摘录（对账的关键行） [023ns] 程序执行开始 [078ns] 输出字符 O [084ns] 输出字符 K [090ns] 处理器桩进入停机态 [168ns] 空闲计数满 浅睡生效 门控关断处理器桩与总线时钟 [169ns] 翻转计数器核对：停机段时钟树翻转由基线 78 次降至 0 次 [240ns] 注入外部请求 唤醒 门控开启 恢复应答 [241ns] 唤醒后首个应答延迟 2 拍 功能核对通过
结果与解读
对账结果对应上图的绿柱：停机段总翻转量降到基线的一成三，其中时钟树科目（7.1 节反复强调的那两三成大头）直接清零；唤醒后功能全对，代价是首个应答多等两拍——这正是 7.2 节"唤醒延迟"的最小演示。功能验证顺手补了两条覆盖点（5.1 节的纪律）：门控生效瞬间不发半截事务、唤醒瞬间无毛刺时钟。第二条在仿真里靠断言守着：门控后时钟上出现宽度不足半拍的脉冲即报警。
这个实验虽小，五脏与真实项目对齐。账本对齐：场景、科目、代理指标三要素齐全，换成真实工具后只是把翻转计数换成功耗估算工具的毫瓦数。武器对齐：门控单元的结构、使能时机、测试旁路，与真实 SoC 里的门控插入完全同构。状态机对齐：空闲计数、睡眠请求、唤醒仲裁、唤醒代价，四件套就是 7.2 节那张状态机的骨架。CK770 台账在此收拢第七章：从预算表（7.1 节）到组合拳（7.2 节）再到这个实验，功耗治理的完整闭环都过了一遍手。
变式练习留给两个方向。其一，把浅睡升级为深睡：给数据存储加"转存到保持寄存器"的模拟，体会 7.2 节说的状态代价——你会发现保持寄存器的面积开销在代码里无处可藏。其二，把唤醒改为中断驱动并统计唤醒延迟分布：当外部请求的到达间隔接近唤醒延迟时，状态机该如何退化（赖在浅睡态）？这道题想通了，7.2 节"负载时间结构匹配切换成本"的论断就从文字变成了直觉。
常见问题辨析
问：实验里的翻转计数，换成真实功耗工具后还准吗？
方向与量级仍准，绝对值要重新标定。翻转活动是功耗估算工具的核心输入，本实验数出来的相对关系（时钟树占比大头、门控后近零）在真实工具里保持；绝对毫瓦数则取决于电压、电容模型与工艺库，仿真环境一律没有。这正是 7.1 节强调"账本跨抽象层复算"的原因：RTL 级的活动分析、网表级估算、版图级提取，每一层都在修正上一层的绝对值，而科目结构与相对格局相当稳定——用实验校准直觉，用工具产出数字，两者分工明确。
问：把实验的浅睡升级成 7.2 节的深睡，具体要动哪几处？
四处。给串口与存储的电源串上睡眠晶体管并补隔离单元；睡眠前把易失状态转存（或声明放弃）；唤醒路径改为从常开域中断进入，先恢复供电再重建设置、后开时钟；测试平台补两条覆盖点——断电瞬间无半途事务、唤醒后首个访问的数据完整性。做完这四处，你会发现工作量的大头不在省电机制本身，而在"睡前收拾、醒后恢复"这套事务——这正是 7.2 节把状态代价列为深睡第一代价的用意。
本节要点回顾
- 翻转次数是动态功耗的可测代理，账本科目与场景结构不变，真实项目里换算成毫瓦即可。
- 门控单元三要素：低电平锁存使能防毛刺、测试旁路保制造测试、使能时机决定省电窗口。
- 睡眠控制器四件套——空闲计数、睡眠请求、唤醒仲裁、延迟代价——是功耗状态机的最小骨架。
- 覆盖点要补到门控行为上（无半截事务、无毛刺时钟），功耗机制的缺陷同功能缺陷一样要在仿真期拦下。
CK770 的功耗分册合卷。最后一章处理交付前的另两件事：给芯片装上信任的锚点（安全架构），并让它跑起第一段固件（软件落地）——台账的收官之章。