UPF 是什么：低功耗意图为什么要单独用一种语言描述
更新时间：2026-09-15。本文是「集成电路大类 · 低功耗设计与验证」入门层系统篇第 08 篇。前几篇我们用自然语言说了一堆「这个域可以断电、断电时输出要钳 0、那组寄存器要保持、跨域要加电平转换」。问题来了：这些决定要写在哪儿，综合器、仿真器、物理实现工具才能都照着做？ 直接塞进 RTL 吗？业界给出的答案是一份独立的「电源意图」描述——UPF（Unified Power Format，统一电源格式，IEEE 1801 标准）。深入篇见《低功耗设计与 UPF》，地图见低功耗导读。
本文要回答的问题
- 已经有 Verilog/SystemVerilog 了，为什么低功耗结构不直接写进 RTL？
- 「电源意图（power intent）」到底指哪些东西？
- UPF 这份文件大致描述了哪几类对象？
- 没有 UPF，低功耗仿真和验证会出什么问题？
- UPF 在整个流程里被哪些环节共用，和 CPF 是什么关系？
一、核心矛盾：低功耗是「横切关注点」，不属于任何一个功能
RTL 描述的是功能：这个模块算什么、状态机怎么转、数据怎么流。而电源域划分、哪个域能断电、断电时信号怎么处理——这些是供电策略，有两个鲜明特点：
- 横切（cross-cutting）：一条电源策略会同时影响许多功能模块，却不属于其中任何一个模块的本职行为。「USB 空闲时整块断电」不是 USB 控制寄存器行为的一部分。
- 随实现而变、需要复用：同一份 RTL IP，在低功耗版本的芯片里要可断电、在廉价版本里可能常供电；换一个工艺，电源开关、隔离单元的具体实现也不同。把这些写死在 RTL 里，功能代码就被某种供电方案和某家工艺绑死了。
如果硬把电源开关、隔离判断写进 always 块，会污染功能代码、增加出错面，还会让纯功能仿真和 power-aware 仿真纠缠不清。业界的解法是经典的关注点分离：
功能写在 RTL 里，供电策略写在一份独立的电源意图文件里，两者并行、在工具里合并。 这份电源意图的标准语言就是 UPF。
二、UPF 大致声明了哪几类对象
UPF 是 Tcl 语法的命令集（早期也叫 Unified Power Format，现归 IEEE 1801）。入门阶段不必记命令，先知道它描述的就是前几篇出现过的那些概念：
| UPF 描述的对象 | 对应的直觉（前序篇目） |
|---|---|
电源域 create_power_domain | 哪些逻辑属于一个可独立供电/断电的组（第 07 篇） |
| 电源网 / 电源端口 supply net、supply port | 域由哪条 VDD/GND 供电、电压多少 |
| 电源开关 power switch | 域与电源轨之间的 header/footer 开关（第 05 篇） |
| 隔离规则 isolation | 断电域的输出在边界钳成什么固定值（0/1/锁存） |
| 保持策略 retention | 哪些寄存器在下电前保存、上电后恢复 |
| 电平转换 level shifter | 不同电压域之间在哪插转换单元 |
| 电源状态表 PST | 各域上下电/电压的合法组合与先后次序 |
可以看出，UPF 不是新的低功耗技术，而是把已经讲过的电源域、门控、隔离、保持、电平转换「声明」出来，供整条流程链统一读取的载体。 具体命令和实战写法在进阶层《UPF 编写实战》展开。
三、为什么没有它，低功耗验证几乎没法做
这是 UPF 最不可替代的价值。普通逻辑仿真器只懂 RTL 描述的电源——而 RTL 里根本没有「电源」这个量。于是当某模块被电源门控断电时：
- 不加电源信息，仿真器仍天真地让那块逻辑「在供电、在翻转」，断电这件事在仿真里根本没发生，自然测不到断电引发的 bug；
- 断电域的输出在真实硅上会变成不确定/悬空，跨到还在工作的域可能导致乱跳甚至直通电流。仿真器需要知道「这条信号的驱动域已断电」，才能把它正确地置成隔离值或未知态 X，并检查下游有没有被正确隔离。
带上 UPF 做 power-aware 仿真（低功耗感知仿真） 时，工具按电源意图给每个域建模供电状态：域断电后其输出按隔离规则处理、保持寄存器按 save/restore 动作走、电源开关和上下电时序都能被激励和检查。这样才能在流片前发现典型低功耗 bug：忘记隔离导致 X 传播、断电时误关了还要用的状态、上电次序错误、跨电压域漏插 level shifter 等。UPF 检查与低功耗验证的更多内容见后续低功耗验证直觉篇与《低功耗设计与 UPF》。
四、一份意图，全流程共用：为什么这种解耦划算
把电源意图独立成 UPF 后，同一份文件被设计链条上的多个环节读取，各自取用需要的部分：
- 综合（synthesis）：按 UPF 在正确位置插入时钟门控、电源开关、隔离、保持、电平转换等特殊单元，并连接它们的控制信号；
- 等价性检查（LEC）：确认插入低功耗结构后，功能与原 RTL 等价，没有被改坏；
- power-aware 仿真/验证：按域供电状态驱动 X 传播、隔离值与 save/restore，检查上下电序列；
- 物理实现（布局布线/电源网络）：按域铺电源轨、布开关网络、把特殊单元放在边界、做电压感知的时序分析；
- 多团队/多工艺复用：功能团队维护 RTL，低功耗/电源团队维护 UPF，同一份 IP 换一个供电方案只改 UPF、不动功能代码。
这正是「关注点分离」的工程收益：功能行为唯一地写在 RTL，供电策略可独立演进、独立评审、独立复用。 这也和软件里「业务逻辑与配置分离」是同一种思想。
五、UPF 与 CPF、以及入门阶段要记住的边界
- **CPF（Common Power Format）**是另一套早年由厂商推动的电源意图格式，思路与 UPF 类似（声明域、隔离、保持、开关）。业界今天以标准化的 UPF/IEEE 1801 为主流，入门只需知道「有过 CPF 这个同类格式、概念相通」即可，不必深究语法差异。
- UPF 描述意图，不等于低功耗结构本身：UPF 说「这个域可关断、那条跨域信号要隔离」，但开关、隔离单元最终是综合/物理工具按 UPF 插入真实电路的；UPF 写得对不对、插得全不全，还要靠 power-aware 仿真和检查来保证。
- 入门层的目标是读懂：看到 UPF 里的 power domain、isolation、retention、level shifter、PST 能对应回本系列前几篇的物理直觉。命令细节、状态表、retention 供电写法放到进阶层《UPF 编写实战》。
这一篇在知识体系里的位置
- 先有「域」才有意图可写 → 第 07 篇《电源域是什么》；
- UPF 里 isolation/retention/switch 的物理来历 → 第 05 篇《电源门控》；
- 电源意图驱动的验证为什么必要 → 第 09 篇《功耗分析是什么》、后续低功耗验证直觉；
- 想看完整深篇（命令与 power-aware 仿真）→ 《低功耗设计与 UPF》；
- UPF/CPF/SAIF/VCD/.lib/SDF 一堆格式如何区分 → 后续《低功耗相关格式速览》篇。
总结
一句话总结：UPF（Unified Power Format，IEEE 1801）之所以必要，是因为电源域、电源开关、隔离、保持、电平转换这些低功耗结构是横切关注点——它们横跨许多功能模块却不属于任何一个模块的本职行为，且随芯片版本和工艺而变，若写死进 RTL 会污染功能代码、把 IP 绑死在某种供电方案上，因此业界用关注点分离把「功能」留在 Verilog/SystemVerilog、把「供电策略」写进一份独立的电源意图文件 UPF；它用 Tcl 风格命令声明有哪些电源域、各自由哪条电源网供电及电压、哪个域由电源开关关断、断电域输出如何隔离、哪些寄存器要 retention、跨电压域在哪插 level shifter、以及各域上下电合法组合的电源状态表 PST；它最不可替代的价值在验证——普通仿真器只认 RTL 里隐含的单一电源、根本不知道某块被断电了，带上 UPF 做 power-aware 仿真才能把断电域输出按隔离规则置成安全值或 X、让保持寄存器走 save/restore、检查上下电时序，从而在流片前抓到忘隔离导致 X 传播、误关仍需用的状态、上电次序错、漏插电平转换等典型低功耗 bug；同一份 UPF 还被综合、等价性检查、power-aware 仿真、物理实现电源网络等环节共用，使功能团队与电源团队解耦、同一 RTL 换供电方案只改 UPF；入门只需能把 UPF 对象对应回电源域/门控/隔离/保持的物理直觉即可，命令细节留待进阶，CPF 则是概念相通的同类早期格式、现以 UPF 为主流。