极客工场

Appearance

共 1,712 字预计阅读约 6 分钟

RTL 到门级功耗分析：.lib、VCD/SAIF、报告拆解 ​

更新时间：2026-09-14。本文是低功耗进阶层正文。设计侧手段见 时钟门控 ICG、UPF 实战，DPA 的大系统活动采集见 DPA 导读 和 VCD/SAIF 格式。本篇讲功耗工具如何把「活动 × 电容/库模型」算成功率。

一、功耗工具需要三类输入 ​

bash
功耗 = 结构(网表/DEF) + 工艺功耗模型(.lib) + 活动(VCD/SAIF)
输入提供什么阶段差异
网表/结构有哪些单元、层次、实例和连接RTL 阶段靠推断，门级阶段精确
.lib 功耗模型内部功耗、开关功耗、漏电、时序/负载关系必须匹配 PVT corner
VCD/SAIF 活动0/1 翻转次数、静态概率、时间段来自 RTL、门级仿真、Emulator

没有活动文件时，工具只能用默认 toggle rate 估算，结果通常不能用于真实业务决策。

二、.lib 里的功耗模型 ​

标准单元库一般把功耗分三类：

  1. internal power：单元内部电容充放电和短路电流，常以输入翻转、输出状态/负载查表；
  2. switching power：输出驱动外部负载电容：P≈0.5·C·V²·E(tr)；
  3. leakage power：单元只要上电就有的静态漏电，随工艺角、电压、温度、cell type 改变。

因此同一个网表：跑高翻转业务、慢速 corner、高温高压，得到的动态和漏电都会不同。功耗签核必须明确 corner、电压、温度、库版本、RC corner 和活动窗口。

三、VCD 与 SAIF 怎么携带活动 ​

  • VCD（Value Change Dump）：逐事件记录信号值变化，信息全、体积大，适合短窗口精确分析；
  • SAIF（Switching Activity Interchange Format）：汇总每个节点的 toggle count、static probability，体积小，适合长回归和全芯片平均功耗；
  • 仿真器或 Emulator 可以把一段时间窗的活动导出，再反标到网表。

关键量：

bash
toggle rate = 单位时间 0→1/1→0 翻转次数
static probability P(1) = 信号为 1 的时间比例

P(1) 不是可选项：某些单元内部功耗和状态相关，只知道翻转次数不知道高电平占比，无法准确算内部功耗。

四、三个分析阶段 ​

阶段输入精度用途
RTL estimateRTL、clock、线负载/早期模型、SAIF低~中架构取舍、模块预算、门控率粗评
Gate after synthesis映射网表、.lib、活动中找高翻转模块、验证 clock gating、修设计
Post-P&R signoff真实网表/DEF、SPEF/RC、UPF、门级 SAIF/VCD高平均功耗、峰值功耗、IR-Drop/EM 输入

RTL 阶段节点名和门级节点名不同，需要 name mapping / elaboration 信息把 RTL 活动传播到门级。大规模 SoC 常从 Emulator 导出 SAIF，以获得完整软件和业务活动。

五、报告应该怎么拆 ​

只看一个总功耗数没有优化意义。建议按以下维度逐层拆：

  1. 按 hierarchy：哪个 subsystem/module 贡献最大；
  2. 按功耗类型：internal、switching、leakage 占比；
  3. 按资源：clock tree、memory、datapath、IO/PLL/PHY；
  4. 按电源域/电压域：DVFS OPP、可关断域、常开区；
  5. 按时间窗：启动、峰值推理、待机、休眠、上下电瞬间。

最常见发现：clock tree 占比过高且门控率低；memory 没进入 retention；某控制信号每拍抖动；顶层总线在 idle 仍传输 X/旧数据；平均功耗达标但某个突发窗口把 VDD 拉塌。

六、平均功耗、周期功耗与峰值功耗 ​

  • 平均功耗：适合电池续航、热设计和功耗预算；
  • 时间窗功耗：适合业务阶段对比，如 AI 推理 vs 待机；
  • 峰值/瞬态功耗：适合 IR-Drop、inrush current、电源容量检查。

电源门控上电瞬间的 rush current、多个大 memory 同时唤醒、所有 accelerator 同时启动，可能平均功耗报告不显眼，但动态压降足以使常开区复位。这类场景必须把时间窗活动交给 功耗分析与电源完整性 的 IR-Drop/EM 流程。

七、一张功耗报告应该回答的问题 ​

拿到功耗报告，先不要讨论总功耗是否超标，而按顺序回答：

  1. 这个数代表哪个业务窗口？ 启动、峰值、持续负载还是待机，时间长度多长；
  2. 活动从哪里来？ RTL 仿真、门级仿真还是 Emulator，SAIF 覆盖率多少；
  3. 钱花在什么资源上？ clock、memory、datapath、PLL/PHY、IO 各占多少；
  4. 哪些层次最异常？ 用每面积/每事务/每帧的归一化指标比较，而不是只看绝对功耗；
  5. 优化是否反映在报告里？ 门控后活动下降、retention 后漏电下降、DVFS 后电压和频率同时变化。

如果报告显示某模块功耗很高，要继续区分三种根因：模块本来就在高负载工作；时钟/数据没有空闲控制；活动映射错误导致大量节点被误标翻转。第三种最容易误判——name mapping 不完整时，工具可能把活动传播到错误网表节点，制造出不存在的热点。

八、检查清单 ​

  • [ ] 报告标注网表版本、库、PVT、电压、RC corner、活动窗口；
  • [ ] 活动来自代表性真实业务，而非默认 toggle；
  • [ ] SAIF/VCD 覆盖率可接受，未匹配节点单独统计；
  • [ ] RTL 活动到门级的 name mapping 经过抽查；
  • [ ] 按 hierarchy、资源、电源域、时间窗拆报告；
  • [ ] clock gating、memory retention、DVFS 优化前后可对比；
  • [ ] 峰值窗口单独分析并输入 IR-Drop/EM；
  • [ ] 平均功耗和峰值功耗结论分开，不互相替代。

总结 ​

功耗分析的公式是「网表结构 × .lib 单元功耗/漏电模型 × VCD/SAIF 活动」：RTL 估算适合架构预算，综合后门级分析适合找高翻转和门控问题，布局布线后结合真实 RC、UPF、门级活动才用于签核；SAIF/VCD 提供 toggle rate 和 P(1)，代表性时间窗比默认翻转率重要得多；报告必须按层次、功耗类型、资源、电源域和时间窗拆开，平均功耗回答续航，峰值与 rush current 则必须交给 IR-Drop/EM 检查。