低功耗设计 vs 低功耗验证：省电机制的「做出来」与「证明对」
更新时间：2026-09-15。本文是「集成电路大类 · 低功耗设计与验证」入门层系统篇第 47 篇。前面低功耗验证讲过断电带来的新风险，低功耗岗位地图列过两种岗位；这篇专门把设计侧和验证侧放到一张桌子上对照：同一条电源门控机制，设计的人要操心什么、验证的人要证明什么、两份工作在哪里握手。搞清楚这条分界线，你才知道一个 bug 到底该谁改，也更能判断自己喜欢「做出来」还是「证明对」。系统地图见低功耗导读。
一、一句话区分：设计回答「怎么省」，验证回答「会不会错」
- 低功耗设计的目标函数是「在满足功能、时序、面积、成本的前提下，把功耗压到预算内」。它是建设性的工作：划分电源域、决定哪里门控、选几档电压、写 UPF、安排保持/隔离、设计上下电序。它产出的是「实现」。
- 低功耗验证的目标函数是「证明这些低功耗机制在任何电源状态和状态迁移下都不破坏功能」。它是证伪性的工作：构造断电/上电/迁移场景、检查 X 有没有泄漏、隔离值对不对、状态保住没有、电源序合不合法。它产出的是「信心」。
两者共用同一份 UPF、同一个电源状态表（PST），但视角相反：设计希望机制简单可实现，验证要逼出它在边界条件下的失败。这种张力是健康的——只做设计不做低功耗验证，等于「装了刹车但从没踩过」。
二、对照表：同一个机制，两边各看什么
| 低功耗机制 | 设计侧关心（怎么省/怎么实现） | 验证侧关心（怎么证明不出错） |
|---|---|---|
| 时钟门控 CG | 门控点放哪、粒度、使能何时拉低、时序能否收敛 | 门控后状态是否保持、使能切换是否丢/重一拍、回归功能是否一致 |
| 电源门控 PG | 域怎么切、用 header 还是 footer、开关面积/Ron、上下电序 | 断电中输出是否隔离、上电后能否干净恢复、非法序是否被拦住 |
| 保持 retention | 哪些寄存器要保持、save/restore 何时触发、V_ret 供电 | 断电后该留的留没留、不该留的是否复位、save/restore 时序窗 |
| 隔离 isolation | clamp 到 0 还是 1、单元放发送端还是接收端、使能时序 | 每个跨域信号在断电时是否被正确钳位、无 X 外泄、上电后恢复 |
| 电平转换 LS | 高↔低方向、电源先后序、是否兼做隔离 | 电源未就绪时 LS 输出是否确定、跨域通信在所有序下可读 |
| DVFS | 几档 V/F、切换序列、稳压等待、临界频率 | 换挡过程中无错误采样、无越压时序、协议不丢事务 |
| 电源域划分 | 按活跃度/唤醒/供电分组，平衡收益与代价 | PST 所有可达状态/迁移覆盖、不可达组合是否真的不可达 |
三、设计侧的输入、输出与 KPI
- 输入：功耗预算与 use case（见功耗预算实战）、库（多 Vt/低功耗单元）、工艺漏电特性、时序约束。
- 关键交付：域划分与 PST、低功耗 RTL、UPF、上下电序列、DVFS 档位表。
- KPI：模块/整机功耗在预算内、门控覆盖率、漏电达标、面积与时序代价可接受。
- 典型纠结：再分一个电源域能省一点漏电，却增加隔离/保持/验证成本——这笔交易设计要拍板。
四、验证侧的输入、输出与 KPI
- 输入：RTL + 同一份 UPF + PST + 电源管理固件/驱动行为模型 + 功能验证环境。
- 要回答的四类问题：
- X 安全：断电域的不定态有没有通过未隔离路径传播进活域，污染寄存器或仲裁？
- 隔离/保持正确：clamp 值、使能时序、save/restore 在所有迁移下对不对？
- 电源序合法：上下电、DVFS 换挡、多域交错时，有没有违反「先隔离后断电、先稳压后提速」之类的顺序？
- 覆盖完整：PST 里每个状态、每条迁移、每个电源域与活域的组合是否都被激励过？
- 手段：UPF 感知的逻辑仿真（供电网络用 0/1/X/Z 建模）、电源相关断言（PSL/SVA）、低功耗 lint/规则检查、形式化穷举电源序、功耗状态功能覆盖率。详见低功耗验证。
- KPI：电源状态/迁移覆盖率 100%、隔离与保持检查全部清零、形式验证无反例、逃逸到硅上的低功耗 bug 数。
五、两边最容易打架的三个接口
- 同一份 UPF，两种读法。 设计写 UPF 是为了让综合/后端插入正确单元；验证吃 UPF 是为了在仿真里重建供电和 X。设计漏写一条 isolation rule，工具可能在实现上「恰好没问题」，但验证会看到 X 灌进活域。约定：UPF 是设计的交付物，验证负责检查它，不负责替设计补意图。
- 「是设计 bug 还是验证环境 bug？」 上电后信号是 X，可能是设计没隔离，也可能是 testbench 的电源时序/驱动没建好。判据是：把同一个场景在不带 UPF 的纯功能仿真和带 UPF 仿真里对比，并单独检查隔离使能波形——先隔离环境变量，再定责。
- 功能回归通过 ≠ 低功耗正确。 普通功能仿真里电源永远开着，永远不会自然出现「断电中途来一笔交易」「DVFS 换挡时 DMA 在传」这类场景。这些必须靠验证侧显式构造电源迁移与异步事件的交叉，不是跑功能 regression 能顺带覆盖的。
六、推荐的握手节奏
- 架构阶段：设计出域划分和 PST 初稿，验证评审「这些状态和迁移可不可验证、组合数是否可控」。越早在白板上砍掉不可达组合，后期越省力。
- RTL/UPF 阶段：设计交一版能仿真的 UPF，验证搭低功耗环境骨架，先跑通「关一个域再开」的最小闭环。
- 实现阶段：综合/后端插入真实单元后，验证确认实现网表与 UPF 意图一致（无遗漏隔离/保持/电平转换），低功耗 lint 清零。
- 签核阶段：电源状态/迁移覆盖率收敛、形式证明通过、与功耗签核（功耗分析）共用同一批场景向量，避免「验证的场景不耗电、耗电的场景没验证」。
七、验证侧的工具箱：四类手段各管一段
低功耗验证不是单一工具，而是四种互补手段，分别在不同阶段、用不同成本回答不同问题：
| 手段 | 在什么时候用 | 回答什么 | 成本/局限 |
|---|---|---|---|
| 低功耗 lint / 规则检查 | RTL+UPF 早期 | 有没有漏隔离、跨域无电平转换、电源域悬空等结构性问题 | 快、能自动跑，但只查规则不查行为 |
| UPF 感知仿真 | 主力，贯穿全程 | 具体电源迁移场景下 X、隔离值、保持、电源序对不对 | 要构造场景，覆盖率取决于激励 |
| 断言（SVA/PSL） | 与仿真并行 | 电源序、隔离使能时序等不变量是否恒成立 | 断言写漏就抓不到，需评审 |
| 形式化验证 | 关键电源序/控制 | 数学上穷举所有迁移，证明不存在非法序/隔离缺失 | 建模样、深度有限，挑关键路径做 |
经验法则：结构性问题靠 lint 先扫干净，行为问题靠仿真堆覆盖，关键不变量靠断言常驻，最要命的电源序靠形式化兜底。 只靠仿真而不做 lint，等于把大量「必错」留到漫长回归里偶然撞见；只做 lint 不做仿真，则永远发现不了特定场景下的行为错误。
八、一个案例：唤醒丢字符是怎么被两边一起定位的
一个低功耗 MCU 的真实风格案例，能说明设计与验证如何配合：
- 现象：UART 在深睡时收到数据偶尔丢第一个字节。
- 验证复现：低功耗环境里显式构造「RX 下降沿到来的同一拍，域正在从关断唤醒」，仿真复现——隔离使能还没撤、接收域电源尚未稳定，第一拍被钳位值吃掉。
- 定责：这不是环境问题，而是设计的电源序缺少「检测到唤醒源后，先保持接收使能、等域稳定再放数据」的握手；同时验证侧承认原回归没有覆盖「唤醒与到达同拍」这个交叉，补了一条电源迁移×异步事件的覆盖点。
- 修复与回归：设计在常开检测逻辑和接收域之间加握手与若干拍缓冲；验证把「唤醒源 × 数据到达时刻偏移 −2~+N 拍」参数化成一组序列，并加断言「隔离未撤销时活域不得取该数据」，形式化确认不存在更早的泄漏窗口。
这个案例浓缩了本系列多个要点：唤醒源必须在常开域（见 MCU 低功耗）、隔离会主动钳掉信号（见保持与隔离）、普通功能回归永远碰不到这种时序交叉（见低功耗验证）。更重要的是它展示了健康协作：设计改机制，验证补证明，两边都从同一个 bug 里各取一条长期防线，而不是互相追责了事。
八补、协作中高频出现的五个误区
| 误区 | 为什么危险 | 正确姿势 |
|---|---|---|
| 「功能过了低功耗自然过」 | 电源常开回归根本不会产生断电相关场景 | 单独建电源状态/迁移覆盖率，不与功能覆盖混为一谈 |
| 「UPF 让验证顺手补一下」 | 验证不掌握架构意图，补出来的规则未必是设计本意 | UPF 是设计交付物，验证只做检查和反例反馈 |
| 「隔离值一律钳 0」 | 有的活域把 0 当有效请求（如低有效 valid、写使能），钳 0 反而触发误动作 | 逐信号定义 clamp 值并评审，低有效信号往往要钳 1 |
| 「仿真里没看到 X 就安全」 | X 可能被后续逻辑吸收，也可能在特定延迟/角点才显现 | 显式做 X 传播检查 + 形式化，不依赖肉眼看波形 |
| 「低功耗是后端/验证某一方的事」 | 七成省电决策在架构/RTL，问题却常在交接处 | 按握手节奏分阶段共担，评审两边都要签字 |
还要提醒一个团队管理上的坑：低功耗 bug 的「发现时机」普遍很晚，常在系统联调甚至样片阶段才暴露，而那时定位成本最高。所以验证侧的价值不能只按「找到了多少 bug」衡量，更要看电源状态覆盖率、检查完备性和是否在架构阶段逼退了不可验证的设计——这些「没出事」的工作，恰恰是低功耗验证最大的贡献。设计侧也应把「验证提出的电源态简化建议」当成正向输入：砍掉永远不会用到的状态组合，既省验证工作量，往往也省掉了对应的隔离/保持硬件。
九、你更适合哪一边
- 选设计，如果你享受「在互相冲突的约束里做权衡」：省电要与时序、面积、成本、唤醒延迟拉扯，你要能拍板并对指标负责。
- 选验证，如果你享受「系统性地设想一切怎么会坏」：你要从状态组合、异步交叉、边界时序里构造别人想不到的场景，并把检查自动化、可量化。
- 两条路在资深处汇合：懂设计的验证工程师能在架构阶段就指出「这个域划分不可验证」；懂验证的设计工程师能写出天然好验证、少返工的电源意图。岗位地图里也强调，愿意跨到对面看一眼的人，在低功耗领域尤其值钱。
结语
设计和验证不是上下游的简单交接，而是围绕同一份电源意图的两种相反视角：设计让省电机制存在，验证让它在所有状态下都站得住。低功耗之所以专门长出验证岗位，正是因为断电、保持、隔离、调压引入了一类「电源常开时永远不会发生」的 bug——它们不会被功能仿真撞见，只会在用户手机莫名重启时出现。把 UPF 当契约、把 PST 当共同的状态空间、把覆盖率当握手语言，两边才能把「省电又不出错」这件事真正做成。
一句话收口：设计决定这颗芯片能省多少，验证决定这份省电敢不敢交付——前者是做出来的艺术，后者是证得过的工程，缺一边，低功耗都只是 PPT 上的数字。
总结
设计与验证共用同一份 UPF 和 PST 但视角相反：设计回答「怎么省」，在功能时序面积成本约束下划域、插门控、定 DVFS 和上下电序，产出实现；验证回答「会不会错」，构造断电恢复与异步交叉场景，检查 X 传播、隔离保持、电源序合法性和状态覆盖，产出信心。功能回归通过绝不等于低功耗正确，结构性问题靠 lint、行为问题靠仿真、关键序靠断言和形式化兜底，健康协作是 UPF 作为设计契约、验证只检查不替写。