低功耗评审清单：开评审会时必须问出口的功耗问题
更新时间：2026-09-15。本文是「集成电路大类 · 低功耗设计与验证」入门层系统篇第 49 篇，也是 50 篇入门池的收官清单。前 48 篇给的是知识，这一篇把知识压成可以直接带进会议室的问题。评审会上最怕一片沉默：没人问功耗，等实测超标才发现续航差一倍。这份清单按评审阶段分组，每条配「不合格的典型回答」帮你识别风险。系统地图见低功耗导读，配合术语速查使用。
一、需求与预算评审（最早，最重要）
| # | 要问的问题 | 听到这种回答要警惕 | 该看的产物 |
|---|---|---|---|
| 1 | 续航/功耗目标是怎么从产品需求倒推出来的？ | 「先做着看，后面再优化」 | 功耗预算表（见预算实战） |
| 2 | 电池有效容量打折了吗（自放电/低温/截止电压）？ | 「按标称 mAh 算的」 | 容量折损假设 |
| 3 | 平均电流预算是多少、留了多少余量？ | 只有峰值没有均值 | 平均/峰值两行数字 |
| 4 | 各电源态 residency 假设是多少、谁负责达成？ | 「应该大部分时间在睡吧」 | residency 目标+责任列 |
| 5 | 温度范围与老化系数怎么进预算？ | 只给常温典型值 | corner/降额系数 |
| 6 | 常驻电流（sleep/Iq/漏电/上拉）算全了吗？ | 只算了 active 电流 | 常驻项清单 |
预算阶段的欠账，后期补不回来：架构定了再想降漏电往往只能加电源门控，代价极高。
二、架构评审
| # | 要问的问题 | 警惕的回答 | 产物 |
|---|---|---|---|
| 7 | 电源域按什么原则分（活跃度/唤醒/供电）？ | 「方便起见全用一个域」 | 域划分图 |
| 8 | 哪些是常开岛？上面放了多少东西？ | 半个 SoC 都在 AON | AON 清单与漏电估算 |
| 9 | 省电模式分几级？各级关什么、唤醒多久？ | 只有「开/关」两态 | 模式表（见待机睡眠） |
| 10 | DVFS 几档？换挡要多久、稳压怎么保证？ | 档位定了但没序列 | V/F 档位+切换序列 |
| 11 | 断电再上电的延迟，业务能接受吗？频繁开关会不会更费？ | 没算过上下电能量 | 切换能量/延迟账 |
| 12 | 存储器、PHY、时钟树这些大头怎么处理？ | 默认常开 | 存储器/外设/时钟树策略 |
三、RTL 评审
| # | 要问的问题 | 警惕的回答 | 产物 |
|---|---|---|---|
| 13 | 综合后时钟门控覆盖率多少？哪些寄存器没被门控？ | 「综合会自动处理」 | 门控覆盖率报告（见时钟门控） |
| 14 | 使能信号会不会产生毛刺？是否用 ICG？ | 手动用与门控时钟 | 门控结构 |
| 15 | 空闲时数据通路还在翻转吗？要不要操作数隔离？ | 没考虑 glitch | RTL+功耗对比 |
| 16 | 要断电模块的状态哪些需 retention、接口怎么握手？ | 「上电重新初始化就行」但业务要保状态 | 保存/恢复接口 |
| 17 | 隔离/电平转换的控制在 RTL 里留接口了吗？ | 后端再想办法 | UPF-RTL 接口约定 |
| 18 | 唤醒逻辑是否在常开域、会不会误唤醒/漏唤醒？ | 唤醒源接在可关域 | 唤醒源表（见MCU 低功耗） |
四、UPF 与低功耗单元评审
| # | 要问的问题 | 警惕的回答 | 产物 |
|---|---|---|---|
| 19 | 每个可关域的开关、保持、隔离、电平转换都齐了吗？ | 有域定义但缺 isolation rule | UPF（见 UPF/格式） |
| 20 | PST 覆盖了所有可达状态和迁移吗？不可达态确认过？ | 状态表只列了正常路径 | PST |
| 21 | 隔离 clamp 值（0/1/latch）逐个信号定了吗？ | 一律钳 0 | 隔离值表 |
| 22 | UPF 在设计和验证之间是同一份、同版本吗？ | 两边各改各的 | UPF 版本记录 |
| 23 | 上下电序、电平转换电源序有没有明确约束？ | 靠「一般先这样」 | 电源序文档 |
五、物理与电源完整性评审
| # | 要问的问题 | 警惕的回答 | 产物 |
|---|---|---|---|
| 24 | 静态/动态 IR-drop 在最坏角达标吗？ | 只看了平均电压 | IR-drop 报告（见 IR-Drop） |
| 25 | EM 有没有违例？高电流域金属够宽吗？ | 没单独查 EM | EM 报告 |
| 26 | decap 加在哪、面积代价多少？涌流时压降多少？ | 靠后端「看着加」 | decap 规划+瞬态压降 |
| 27 | 热点在哪？热-漏电正反馈评估过吗？ | 只看平均结温 | thermal map（见热耦合） |
六、验证与签核评审
| # | 要问的问题 | 警惕的回答 | 产物 |
|---|---|---|---|
| 28 | 断电时 X 会不会泄漏进活域？隔离检查清零了吗？ | 只跑了电源常开回归 | 低功耗回归（见验证） |
| 29 | 电源状态/迁移覆盖率到 100% 了吗？电源序做形式化了吗？ | 没统计电源覆盖率 | 覆盖率+形式报告 |
| 30 | 漏电在高温角、动态功耗在典型/最坏角都签了吗？ | 只在常温典型角出数 | 多 corner 功耗报告 |
| 31 | 峰值功耗/涌流 di/dt 评估了吗？和板级电源能力对过吗？ | 只报平均 | 峰值/涌流分析（见DPA） |
| 32 | 硅前功耗和预算逐行对账了吗？库版本对吗？ | 总数差不多就行 | 预算-报告对账表 |
七、固件/系统与板级实测评审
| # | 要问的问题 | 警惕的回答 | 产物 |
|---|---|---|---|
| 33 | governor/睡眠策略由谁写？实际 residency 怎么上报？ | 硬件做好就行，软件到时候再说 | PM 策略+遥测 |
| 34 | 外设有没有 runtime PM、不用时能关吗？ | 驱动一直保持上电 | runtime PM 清单 |
| 35 | 板级怎么测 µA 睡眠和 mA 峰值？仪器量程/采样率够吗？ | 万用表量了个大概 | 测量方案（见怎么测） |
| 36 | 峰值电流瞬间电池/电源压降会不会触发 BOR 复位？ | 没看过瞬态压降 | 峰值 ΔV vs BOR |
| 37 | 实测和预算不一致时，归因和砍功能顺序定了吗？ | 超了再说 | 对账与取舍预案 |
七补、把评审流程画成一张图
每道闸都应输出一份「数字 + 责任人 + 关闭条件」，而不是一句「评审通过」。特别要强调最后那条从闸⑤回到闸①的虚线闭环：这一代实测与预算的偏差，是校准下一代模型最值钱的数据。很多团队功耗能力始终上不去，不是工具不行，而是每代都从零拍脑袋、从不回写偏差，详见功耗报告怎么读和功耗异常排查的对账思路。
七补二、跨阶段最容易漏的 8 个「死角」
除了按阶段逐条过，还有一类问题不属于任何单一阶段，却最容易在交接缝里漏掉，值得单独列出来：
- 测试模式与调试模式的功耗：DFT 扫描、边界扫描、调试口常开可能引入额外电源域和漏电，量产配置是否真的关掉了它们？（可测性背景见芯片设计域 DFT 相关篇。）
- 上电/复位瞬间的默认态：所有可门控时钟在上电瞬间默认是开是关？复位期间大阵列同时翻转可能产生远超稳态的涌流。
- 未使用引脚与外设：悬空输入在噪声下反复翻转、未用 PHY 没下电，常常是几个 µA~mA 级「暗电流」的来源。
- 存储器保持策略的粒度：整个 SRAM 一起 retention，还是能按 bank 关？只需保留几十字节状态却给整块 SRAM 供电，是 IoT 设计的常见浪费，见存储器功耗。
- 时钟/PLL 的起停能量：深睡前关 PLL、唤醒重锁定要时间也要能量，若唤醒很频繁，关 PLL 反而不划算——睡眠策略要和唤醒频率一起算。
- 软件临时拉高的电源态不释放：某驱动为一次高速传输提频/开域后忘记恢复，是实测 residency 不达标的高频原因，见CPU 电源管理。
- 传感器/外设的自治与重复采样：能在睡眠中由硬件自动采存的，别为一个采样点唤醒整颗 MCU；反过来，多个传感器各采各的、唤醒多次，也应做事件聚合，见外设功耗。
- 最差 corner 与典型场景混用：预算用典型、签核用最坏，两张表从不碰头，导致「签核过了但续航不达标」或反之。必须在同一张预算表里并列 typ/worst/max 三列。
这 8 条的共同点是：它们都藏在两个模块、两个阶段或软硬件的交界处，没有任何单一 owner 会天然想到，只能靠跨阶段评审清单显式捞出来。
七补三、清单怎么用：分级、打分与留痕
一份 37 问的清单如果只是「是/否」打勾，很容易沦为形式。给一套在小团队也能落地的用法：
- 按风险分级：把每条标成 P0（不满足不许进下一阶段，如预算倒推、隔离检查清零、高温漏电签约）、P1（阶段内必须关闭，如 residency 遥测、EM 检查）、P2（可带条件放行并登记，如个别非热点模块门控覆盖率）。评审结论只围绕「有没有未关闭的 P0」展开，避免在低风险项上耗光会议时间。
- 要证据不要口头：每条必须挂一份可复查的产物——报告页码、日志、覆盖率数据库路径、实测波形截图。回答「综合会自动处理」「应该没问题」一律记为未关闭，因为它无法被下一个人复核。
- 数字留痕、偏差回写：预算值、硅前估值、实测值三列并排，偏差超过阈值（如 ±15%）必须写归因。连续几代积累后，团队会得到属于自己工艺和场景的「估算修正系数」，这比任何工具默认设置都准。
- 谁提问、谁签收：每条问题指定提问人（可以是验证、PI、固件等不同角色）和签收人（该产物的 owner），关闭需签收人确认，避免「会上都点头、事后没人认」。
一个建议的最小评审节奏：架构冻结前过第①②组并锁预算；RTL/UPF 提测前过第③④组；签核前过第⑤⑥组且 P0 全绿；样片回来后过第⑦组做实测对账并回写。对资源紧张的小团队，哪怕不做全套仪式，至少守住四个 P0 时刻——预算可倒推、意图与实现一致、最坏角签得过、实测对得上账，就能避开低功耗项目里绝大多数致命翻车。
最后提醒：这份清单是入门版「该问什么」，进阶层会把其中多条展开成「怎么做到」——例如门控覆盖率怎么分析、隔离单元插在哪一级、IR-drop 怎么建模仿真、峰值电流怎么和封装协同。先用清单建立「问题意识」，再用进阶技术填上「解决手段」，是这条学习路径的正确顺序。
八、评审会上的三条元规则
- 功耗问题必须有人当场认领。每个超标风险都要有责任列和关闭日期，否则评审一散就没人管——这正是岗位地图强调 RACI 的原因。
- 要数字，不要形容词。不接受「应该很省电」，只接受「平均电流 X µA、residency Y%、最坏角漏电 Z µW、余量 W%」。
- 越早问越便宜。需求阶段改一个 residency 假设几乎零成本，硅后改可能要改版。把这份清单的权重压在第一、二组（预算与架构），而不是压到签核阶段。
如果只能从这 37 问里记住三问，那就记：「这个数字是从哪个产品目标倒推出来的？」「在最坏 corner 和真实 residency 下还成立吗？」「出了问题谁签收、下代怎么回写？」 前两问防自欺，第三问防甩账和重复踩坑——低功耗工程的成熟度，往往就体现在有没有人认真回答这三问。
结语：入门 50 篇的收束
从为什么拼低功耗出发，入门池用 50 个选题建立了一套完整的功耗直觉：功耗从哪来（动态/漏电、αCV²f、热）、怎么省（门控/调压/电源门控/域划分/RTL/存储/外设）、怎么描述（UPF/格式）、怎么证明（验证/签核）、怎么量（DPA/板级）、放到哪些系统里（MCU/CPU/SoC/FPGA/数据中心/能量采集）、以及怎么管理人（岗位、术语、清单）。这份评审清单就是全部直觉的「操作界面」：真正的低功耗能力，不是知道多少省电技巧，而是在每个评审关口，都能把该问的问题问出口、把该要的数字要到手。
一句话收口：评审会上没人问的功耗问题，最终都会变成用户手上少掉的续航——把这 37 问走完，比任何单一省电技巧都更能守住功耗预算。 进阶层将从「时钟门控怎么设计」开始，把这些直觉变成可上手的单项技术。
总结
这份评审清单把全部入门直觉压成按需求预算、架构、RTL/UPF、物理/验证/签核、固件/实测五道闸分组的 37 个必问问题，每条配「听到就该警惕的回答」和应交付的证据；用法上要按 P0/P1/P2 风险分级、要数字和产物不要形容词、谁提问谁签收，并把预算值/硅前估值/实测值并排留痕、偏差回写下一代。若只能守住四个 P0——预算可倒推、意图与实现一致、最坏角签得过、实测对得上账——就能避开低功耗项目绝大多数致命翻车。