1. 低功耗SoC验证全景与Xcelium定位

移动终端、边缘计算与车载电子的共同约束，把功耗从"设计后期优化项"推到了架构定义阶段。一颗典型的多核SoC里，CPU簇、GPU、NPU、ISP、DDR控制器、显示子系统各自拥有独立的电源域，域内又按功能切成若干电源门控分区，配合多档电压与频率组合形成DVFS工作点。硬件上，这些能力由电源开关、隔离单元、电平转换器、保持寄存器、电源管理控制器（PMC）共同实现；软件上，则由固件与操作系统按场景请求切换。验证要回答的核心问题不是"功能对不对"，而是"在任意合法的电源状态迁移序列下，功能是否仍然正确，且没有出现漏电、误唤醒、状态丢失或电平冲突"。

低功耗验证到底在验什么

把功耗验证拆开看，它至少包含四类彼此耦合的目标。第一类是电源状态机正确性：每个电源域只能沿UPF定义的合法路径迁移，非法请求必须被拒绝或屏蔽。第二类是跨域信号完整性：关断域输出到常开域的信号必须经隔离单元钳位到确定值，否则常开域会收到浮空电平。第三类是状态保持与恢复：进入保留态时哪些寄存器必须保持、退出后能否恢复，直接影响唤醒后的功能一致性。第四类是低功耗结构本身的功耗意图：电源开关是否真的断开、隔离是否真的生效、时钟门控是否按预期关闭，这些在RTL仿真中表现为可观测的信号与状态，而不是版图后的电流数值。

需要特别说明的是，RTL阶段的低功耗验证并不直接测量功耗，它验证的是"功耗意图是否被正确实现"。真正的功耗数值要等到门级或物理实现后才有意义。因此本课程中所有关于功耗的讨论，都落在结构、状态与控制逻辑层面。

Xcelium在功耗验证中的角色

Xcelium是Cadence的并行仿真引擎，在低功耗验证流程中承担动态仿真与功耗意图检查的执行核心。它与UPF/CPF的配合方式可以概括为：UPF描述"电源架构应该是什么样"，Xcelium在仿真中把这份描述实例化为可执行的电源状态模型，并在每个仿真时刻检查设计行为是否与模型一致。

具体来说，Xcelium的低功耗能力体现在几个层面。它支持UPF 2.0/2.1/3.0与CPF 1.0/2.0，能够解析电源域、电源开关、隔离、电平转换、保持寄存器等命令；它提供-upf、-lowpower等编译选项，把UPF中的电源域映射到RTL层次；它支持电源状态相关的覆盖率收集，包括电源域状态覆盖、隔离使能覆盖、电源开关控制覆盖；它还支持与形式验证工具协同，把仿真中难以穷举的电源状态迁移交给形式化方法补充。

与纯功能仿真相比，低功耗仿真会引入额外的运行时开销：电源状态模型需要在每个时间步评估域状态，隔离与保持逻辑需要动态插入检查点。因此在实际项目中，通常会把低功耗验证分成两阶段——先用小规模定向用例验证电源状态机与隔离逻辑，再用较大规模场景验证跨域交互与唤醒路径。

UPF与CPF：两种标准，一个目标

UPF（Unified Power Format，IEEE 1801）与CPF（Common Power Format，Cadence主导）都用于描述电源意图，但语法风格与抽象层次不同。UPF更贴近"从电源域出发"的建模方式，核心命令包括create_power_domain、create_supply_port、create_supply_net、set_domain_supply_net、create_power_switch、set_isolation、set_retention、set_level_shifter。CPF则更强调"从电源网络出发"，用create_power_domain、create_power_switch、create_isolation_rule、create_retention_rule等命令组织。两者在概念上可以互相映射，但具体语义细节存在差异，例如隔离钳位值的默认行为、保持寄存器的控制信号来源等。

本课程以UPF为主线，原因是它在IEEE标准化后获得了更广泛的工具支持，且与Xcelium的集成路径更直接。在需要对照CPF时，会明确标注差异点。一个典型的UPF片段如下：

create_power_domain PD_CPU -elements {u_cpu_cluster}
create_supply_port VDD_CPU
create_supply_net VDD_CPU -domain PD_CPU
create_power_switch sw_cpu \
  -domain PD_CPU \
  -input_supply_port {vin VDD_SOC} \
  -output_supply_port {vout VDD_CPU} \
  -control_port {sleep ctrl_sleep} \
  -on_state {on vin {!sleep}} \
  -off_state {off {sleep}}
set_isolation iso_cpu \
  -domain PD_CPU \
  -isolation_power_net VDD_SOC \
  -clamp_value 0 \
  -applies_to outputs
set_retention ret_cpu \
  -domain PD_CPU \
  -retention_power_net VDD_SOC \
  -elements {u_cpu_cluster/reg_bank}

这段描述定义了CPU簇的电源域、电源开关、输出隔离与保持寄存器。在Xcelium中加载后，仿真器会据此建立电源状态模型，并在ctrl_sleep有效时检查隔离单元是否把输出钳位到0、保持寄存器是否维持原值。

课程项目场景与验证切入点

后续章节将围绕一个多核SoC电源管理子系统展开。该场景包含五个电源域：CPU簇与GPU可完全关断，NPU支持保留态，DDR控制器在自刷新期间保持，PMC与唤醒逻辑始终常开。验证工作从三个切入点推进：第一，用定向用例覆盖每个电源域的合法迁移路径与非法迁移拒绝；第二，用跨域场景验证隔离、电平转换与保持逻辑在真实交互中的行为；第三，用覆盖率驱动补齐电源状态组合与唤醒源组合。

理解Xcelium在其中的位置，可以这样把握：它不发明电源规则，而是执行UPF定义的规则，并把执行过程中观察到的偏差暴露为断言失败、覆盖率缺口或波形异常。验证工程师的工作，是把"电源意图"翻译成可观测的检查点，再让仿真器在足够多的场景下反复触发这些检查点。