4、CPF基础：通用功耗格式（CPF）介绍、与UPF的异同、低功耗意图的捕获与传递
好，咱们今天聊聊CPF。通用功耗格式，英文全称Common Power Format。说实话，我刚入行那会儿，业界主流还是UPF，CPF用得少。但后来发现，CPF在某些场景下，尤其是早期架构探索阶段，有它独特的优势。
4.1 CPF是什么？
CPF，说白了就是一种描述芯片低功耗意图的标准格式。它由Si2组织（Silicon Integration Initiative）推动，后来被Cadence收购并大力推广。你想想看，一个芯片里那么多电压域、那么多电源开关、那么多电平转换器，光靠画原理图或者写文档，根本管不过来。CPF就是把这些信息用一种结构化的文本描述出来。
我个人习惯把CPF看作一张「功耗蓝图」。它告诉后端工具：哪些模块要常开，哪些可以关掉，什么时候关，怎么恢复。嗯，这里要注意，CPF和UPF虽然目标一致，但语法和哲学有差异。
核心要点： CPF是一种基于Tcl语法的低功耗意图描述语言。它把功耗相关的约束、策略、实现要求，统一封装在一个文件中。
4.2 CPF与UPF的异同
很多工程师问我：「CPF和UPF到底选哪个？」我的回答是：看你的工具链和团队习惯。两者都是IEEE标准（UPF是IEEE 1801，CPF是Si2标准），但实现方式不同。
| 对比维度 | CPF | UPF |
|---|---|---|
| 标准化组织 | Si2（后被Cadence主导） | IEEE 1801（Accellera推动） |
| 语法基础 | Tcl风格，命令式 | 类似SDC，声明式 |
| 设计阶段 | 更偏向早期架构规划 | 更偏向RTL到GDS全流程 |
| 电源域定义 | 使用create_power_domain |
使用create_power_domain（同名但参数不同） |
| 电平转换器 | 自动推断，也可手动指定 | 需要显式声明set_level_shifter |
| 工具支持 | Cadence工具链原生支持 | Synopsys、Cadence、Siemens均支持 |
我记得有一次，一个项目组从UPF切换到CPF，结果发现CPF对电源域的层次化定义更严格。说白了，CPF要求你在顶层就把所有电源域规划好，而UPF允许你在不同层次逐步细化。这没有好坏之分，只是设计哲学不同。
我的建议： 如果你用的是Cadence的Innovus或Genus，CPF会更顺手。如果是Synopsys的Fusion Compiler或ICC2，UPF是标配。但两者可以互相转换，只是需要额外脚本。
4.3 低功耗意图的捕获与传递
低功耗意图，说白了就是「我想让芯片怎么省电」。这个意图需要从架构师传递到前端设计，再到后端实现，最后到验证团队。CPF就是这条传递链上的「通用语言」。
怎么捕获？我一般分三步走：
- 架构级定义： 先画出芯片的电源域划分图。哪些模块是常开域（always-on），哪些是关断域（power-gated），哪些是电压可调域（DVFS）。
- 策略细化： 每个电源域的工作模式。比如：正常模式1.0V，休眠模式0.6V，关断模式0V。CPF里用
set_operating_condition来描述。 - 实现约束： 电平转换器放在哪里？隔离单元用哪种？电源开关的尺寸多大？这些都可以在CPF里指定。
举个例子，一个简单的CPF片段：
# 定义电源域
create_power_domain -name PD_CORE -default_voltage 1.0
create_power_domain -name PD_IO -default_voltage 3.3
# 定义工作模式
set_operating_condition -name ACTIVE -domain PD_CORE -voltage 1.0
set_operating_condition -name SLEEP -domain PD_CORE -voltage 0.6
set_operating_condition -name OFF -domain PD_CORE -voltage 0.0
# 定义电源开关
create_power_switch -name SW_CORE -domain PD_CORE -control_signal sleep_en
# 定义隔离策略
set_isolation -domain PD_CORE -isolation_condition sleep_en -clamp_value 0这段代码，你想想看，其实就是把架构师的意图翻译成了工具能读懂的语言。我曾经在一个项目中，因为CPF里漏写了隔离策略，导致关断域恢复时出现了毛刺，差点让整个芯片复位。从那以后，我每次写完CPF都会跑一遍语法检查和一致性检查。
避坑指南： 我曾经遇到过一个案例，CPF中定义的电源域和RTL中的模块层次不匹配。工具报错说「找不到实例」。后来发现是CPF里用了绝对路径，而RTL里用了相对路径。所以，路径命名规范一定要统一。
4.4 意图传递的流程
CPF的传递，本质上是一个「写-读-验证」的循环：
- 写： 架构师或功耗工程师编写CPF文件。
- 读： 前端综合工具（如Genus）读取CPF，生成带功耗意图的门级网表。
- 验证： 仿真工具（如Xcelium）读取CPF，在仿真时检查电源域切换是否正确。
- 实现： 后端工具（如Innovus）读取CPF，自动插入电源开关、隔离单元、电平转换器。
嗯，这里要注意，CPF文件一旦写好，尽量不要在流程中手动修改。我见过有人为了赶进度，直接在CPF里改了一个电压值，结果后端工具和仿真工具读到的版本不一致，查了三天才找到原因。所以，版本控制很重要。
总结一下： CPF的核心价值在于「一次编写，多处复用」。它把低功耗意图从文档变成了可执行的标准。虽然和UPF语法不同，但目标一致。选哪个，看你的工具链和团队习惯。我个人更推荐在项目早期用CPF做快速原型验证，后期再转成UPF做全流程实现。
好了，这一章就到这里。下一章咱们聊聊CPF的高级用法，比如多电压域的动态电压频率调整（DVFS）怎么在CPF里描述。