Primetime电压缩放实现：DVFS、MMMC与UPF流程解析

1. 搞清楚voltage scaling到底在做什么

1.1 为什么要做电压缩放：功耗公式里的二次项

做后端物理实现和签核的工程师对功耗公式都不会陌生：动态功耗 P = αCV²f，其中 α 是翻转率，C 是负载电容，V 是供电电压，f 是工作频率。这个公式里最有意思的地方在于电压是二次项——电压从 1.0V 降到 0.7V，动态功耗不是降低 30%，而是直接打了五折还多。相比之下，调频率是线性的，调翻转率又受限于实际业务负载，都不如电压来得立竿见影。

所以无论做手机芯片、AI加速器还是物联网MCU，只要对续航或者散热有要求，voltage scaling（电压缩放）都是必选项。我在实际项目里见过不少团队，前前后后把架构、时钟、综合策略都优化了一遍，功耗还是压不下去，最后痛下决心引入DVFS，电压一降，整颗芯片的功耗直接降了一个量级。这就是为什么现在主流SoC几乎没有不做多电压域和动态电压频率调节的。

但是这里有个绕不开的矛盾：电压降下来，晶体管的驱动能力变弱，cell delay 变大，时序越来越差。同一个设计，0.72V 下可能轻松收敛，0.65V 下 setup 就全线飘红。更麻烦的是，拿 0.72V 跑出来的时序结果不能代表 0.65V 的情况，也不能代表 0.9V 的情况。每个电压点都是一个独立的 PVT 角，都需要单独跑静态时序分析。

Primetime 做 voltage scaling，说白了就是解决一个问题：在多个电压点同时存在、甚至同一个模块电压动态变化的情况下，怎么把时序约束和分析做全，确保芯片在最差条件下能开机、在最好条件下不会因为 hold 违规而跑飞。

1.2 静态缩放和动态缩放（DVFS）两条路线

Voltage scaling 在实际工程里分两种做法，对应的分析策略完全不同。

第一种是静态电压缩放，也叫多电压域（MSV）。设计里划分出几个电压域，比如 CPU 核跑 0.8V，GPU 跑 0.9V，IO 和模拟模块固定 1.8V。每个域的工作电压在设计阶段就定死了，流片后不再改变。这种场景相对简单，每个电压域看成一个独立的 operating condition，电压域之间通过 level shifter 隔开，分析时把不同域的电压分别设置好，检查跨域路径时要额外考虑 level shifter 的延迟。

第二种是动态电压频率缩放（DVFS），这个才是真正考验功夫的地方。一个CPU核的运行电压不是固定的，它在负载高的时候跑到 1.0V/2.0GHz，负载一般时降到 0.85V/1.5GHz，进入待机再降到 0.7V/800MHz。系统运行过程中，电压和频率是成对切换的。这种情况下，分析工具不能只看一个静态电压点，必须覆盖所有可能的电压-频率组合，并且还要考虑切换瞬间的稳定性。如果某个组合没覆盖到，芯片在真实运行时就可能在这个点翻车。

Primetime 对这两条路线都支持：静态多电压域用多 corner 多模式分析（MMMC）就行；DVFS 则需要在 MMMC 基础上再加 UPF power state 的描述，把每个电压-频率组合映射成独立的 scenario，跑完整组合矩阵。

1.3 Primetime在整个流程里扮演什么角色

业界做时序签核的主流工具就是 Primetime，它对 voltage scaling 的支持相比其他工具要成熟得多，主要体现在几个方面。

第一，它能识别 UPF 描述的电源网络和电压域结构，知道哪条路径在哪个电压域内。第二，它可以通过 MMMC 机制同时读入多个电压点下的库文件和约束，一次运行覆盖所有组合。第三，它对 LVF（Liberty Variation Format）库模型的支持比较完善，延迟和转换时间的计算精度能满足签核要求。第四，它可以输出每个 scenario 的时序报告，方便定位是哪个电压-频率组合出了问题。

很多刚入门的工程师容易有一个误区：以为 voltage scaling 就是多建几个 corner，把不同的 lib 填进去就行。实际没这么简单，库的电压点选取、IR drop 的余量分配、跨域路径的处理、DVFS 切换时的时序验证，每一环都有坑。这篇文章我把整个流程拆开讲，从库建模、corner 设置、scenario 组合到问题排查，带你把 Primetime 的 voltage scaling 流程完整走一遍。

2. Primetime里建模电压变化的三种核心手段

2.1 operating condition：最基础的电压描述方式

接触过 Primetime 的人应该都用过set_operating_conditions，这是最传统的电压描述方式。它通过指定 PVT 参数告诉工具当前分析的是哪个工艺角、哪个电压、哪个温度，唯一的缺点是它只能描述一个静态电压点。

实际操作中，如果你用老的.lib库，set_operating_conditions通常这样写：

set_operating_conditions -analysis_type on_chip_variation \ -library {ss_0p72v_125c_lib} \ -voltage 0.72 \ -temperature 125 \ -process 1.0

-library指定当前要用的库文件集合，-voltage指定工作电压。这里有个容易忽略的问题：-voltage指定的值必须和.lib库特征的电压一致，否则工具会警告，并且延迟查表结果可能不符合预期。常见做法是库文件名直接带上电压，比如ss_0p72v.lib、ff_0p90v.lib，这样不容易搞混。

对静态多电压域设计，set_operating_conditions够用，但对 DVFS 设计就不行了。原因很简单：DVFS 设计里一个模块有多个可用电压，你不能在一个 analysis view 里给同一个模块同时设 0.72V 和 0.9V。必须把每个电压点拆成独立的 operating condition，然后塞进不同的 corner 和 scenario 里并行分析。

这就是 MMMC 的用武之地。MMMC 允许你定义多个 corner，每个 corner 绑定自己的 library set 和 operating condition，再把 corner 和 mode 组合成 scenario。Primetime 运行一次就能把所有电压点的时序结果都报出来，不需要像老流程那样每个电压点单独跑一遍。

2.2 多电压点库与LVF模型：让延迟跟着电压变

谈到 voltage scaling 的时序分析，核心依赖还是库文件。每个电压点的.lib文件，本质上就是一个经过特征化（characterization）的 PVT 角下的延迟数据表。

我常用的库结构是这样的：同一个标准单元库，在 0.72V、0.8V、0.9V、1.0V 四个电压点分别做特征化，得到四套.lib。它们的 cell 名称、引脚定义、功能模型完全一样，但延迟、转换时间、时序约束数值不同。电压越低，同样的 input transition 和 output load 下延迟越大，库里的cell_fall、cell_rise查表数值就越大。

如果你的库支持 LVF 模型，除了延迟和转换时间的主表，还会有额外的归一化延迟和归一化转换时间表格，用来描述随机变化（random variation）。这种库在低电压下格外重要，因为低电压下工艺波动对延迟的影响更敏感，传统的统一 derate 往往不够准。使用 LVF 库时，Primetime 的统计时序分析（STA with OCV/SSTA）会直接读这些变化表格来计算时序裕量。

在 Primetime 里用 MMMC 方式挂库的脚本大致如下：

# 定义库文件集合，0.72V 电压点 create_library_set -name libset_ss_0p72v \ -timing {ss_0p72v_125c.lib io_0p72v.lib sram_0p72v.lib} # 创建 operating condition create_operating_condition -name oc_ss_0p72v \ -library_set libset_ss_0p72v \ -voltage 0.72 -temperature 125 -process 1.0 # 创建 corner create_corner -name corner_ss_0p72v \ -operating_condition oc_ss_0p72v

0.9V 的 corner 就再重复一遍，把库换成ff_0p90v.lib对应的一组文件即可。写脚本的时候我一般用一个循环把电压点列表、库列表、corner 名称都定义为数组，后面增删电压点只需要改一处，比复制粘贴整个脚本段要省心得多。

需要注意，不同电压点的库之间不能混用。比如把 0.72V 的布局网表和 0.9V 的时序库组合在一起跑，出来结果没有物理意义。这个错我见过有人犯，跑完报告发现 setup 全是负的，折腾了半天才发现是库挂错了。

2.3 set_voltage与UPF协同：电压域和power state的处理

前面两种方式处理的是“多电压点”的问题，但实际设计里我们还面临“电压怎么变、什么时候变”的问题。这就需要 UPF（Unified Power Format）参与进来。

Primetime 支持完整读入 UPF。通过 UPF，你可以在设计里定义电源域（power domain）、电源网络（supply net）、电源端口（supply port），然后用set_voltage给每个电源网络指定电压值。这样做的意义在于：工具能知道某条时序路径的起点在哪个电压域、终点在哪个电压域，跨域路径是否存在电压不匹配。

看一个简单的 UPF 片段：

create_power_domain PD_CORE -elements {core_inst} create_supply_net VDD_CORE -domain PD_CORE create_supply_port VDD_CORE_PIN -domain PD_CORE -direction in connect_supply_net VDD_CORE -ports VDD_CORE_PIN set_voltage 0.72 -object {VDD_CORE_PIN}

配合 Primetime 的load_upf命令加载后，工具会建立电压域和电源网络之间的关系。接下来用 power state 描述电压的动态变化。create_pst命令可以定义 power state table，列出所有可能的电压状态组合：

create_pst pst_core -supplies {VDD_CORE} add_pst_state st_0p72v -pst pst_core -state {0.72} add_pst_state st_0p90v -pst pst_core -state {0.90}

有了 power state，Primetime 可以按照每个状态自动生成对应的 scenario，这就是 DVFS 完整流程的基础。我实际跑过的设计里，CPU 域和 GPU 域各有两个电压点，组合出来 4 个 power state，工具自动创建 4 个 scenario，不用手动挨个建。如果设计里还有不同频率的模式（比如 CPU 低频待机模式、高性能模式），再把 mode 维度加进去，scenario 数量等于 mode 数量和 power state 数量的乘积。

3. 实操：多corner多模式流程完整走一遍

3.1 建库和corner：一个电压点一组库

从我最近负责的一个 AVS（Adaptive Voltage Scaling）项目说起。这个项目的主控逻辑要求动态调整供电电压来降低平均功耗，电压点在 0.65V 到 0.95V 之间按 50mV 步进调节。经过和库厂商讨论，最终特征化了 0.65V、0.70V、0.75V、0.80V、0.85V、0.90V、0.95V 共 7 组库。

听起来库很多，但操作上并不复杂。我在 MMMC 脚本里把电压点、库名、corner 名做了几个列表：

set voltage_list {0.65 0.70 0.75 0.80 0.85 0.90 0.95} set corner_list {} foreach v $voltage_list { set libset_name "libset_ss_${v}v" set lib_files [list \ "stdcell_ss_${v}v_125c.lib" \ "io_ss_${v}v_125c.lib" \ "sram_ss_${v}v_125c.lib" \ "phy_ss_${v}v_125c.lib"] create_library_set -name $libset_name -timing $lib_files set oc_name "oc_ss_${v}v" create_operating_condition -name $oc_name \ -library_set $libset_name \ -voltage $v -temperature 125 -process 1.0 set corner_name "corner_ss_${v}v" create_corner -name $corner_name \ -operating_condition $oc_name lappend corner_list $corner_name }

这样 7 个电压点的 corner 就建好了。如果你还要兼顾 fast corner，可以把ss换成ff，温度设为-40或0，电压值相同再跑一组。注意 fast corner 的库不是简单把 ss 库换成 ff 库就完事，还要确保特征化时用的电压/温度条件与 signoff 要求一致。

这里有一个我踩过的坑：库里面有些 IP（比如 PLL、IO、SRAM）支持的电压范围可能和标准单元不同，不能简单用同一个$v去套。我的做法是对不同库文件分别检查数据手册，确认该电压点是否在支持范围内，不在范围内的就换固定电压库或排除掉。如果硬挂上去，Primetime 不会报错，但查表结果可能落在外推区，时序数字失真。

3.2 建mode和scenario：把电压和约束组合起来

Corner 只解决了 PVT 的问题，scenario 还要叠加功能模式。对 DVFS 设计，典型模式至少包括：高性能模式（高频高压）、平衡模式（中频中压）、低功耗模式（低频低压）和待机模式（超低频超低压）。

我习惯用create_mode把不同功能的约束文件分开：

# 高性能模式 create_mode -name mode_perf set_mode mode_perf # 加载高性能模式的时钟和时序约束 source constraints/sdc_perf.sdc # 回到根环境 set_mode -none # 低功耗模式 create_mode -name mode_lp set_mode mode_lp source constraints/sdc_lp.sdc set_mode -none

不同模式下的时钟频率、约束松紧可能完全不同。高性能模式下时钟频率高，约束紧；低功耗模式下频率低，约束松。这些都要在各自的 SDC 里体现。

然后创建 scenario，把 mode 和 corner 组合起来。如果 design 有 7 个电压点和 2 个 mode，最完整的情况要建 14 个 scenario，但实际不需要全部穷举。高性能模式只可能跑在高压点，低功耗模式只跑在低压点，中间模式对应中间电压。我会做一个映射表，只创建物理上真实存在的组合：

# mode_perf 只用 0.90 和 0.95 两个电压点 create_scenario -name scenario_perf_0p90v \ -mode mode_perf -corner {corner_ss_0p90v} create_scenario -name scenario_perf_0p95v \ -mode mode_perf -corner {corner_ss_0p95v} # mode_balance 用 0.80 和 0.85 create_scenario -name scenario_balance_0p80v \ -mode mode_balance -corner {corner_ss_0p80v} create_scenario -name scenario_balance_0p85v \ -mode mode_balance -corner {corner_ss_0p85v} # mode_lp 用 0.65 到 0.75 create_scenario -name scenario_lp_0p65v \ -mode mode_lp -corner {corner_ss_0p65v} create_scenario -name scenario_lp_0p70v \ -mode mode_lp -corner {corner_ss_0p70v} create_scenario -name scenario_lp_0p75v \ -mode mode_lp -corner {corner_ss_0p75v}

这样既覆盖了所有可能的运行状态，又不至于让 scenario 数量爆炸。以后想加组合，只需要在映射表里加一行。

3.3 跑STA与报告解读：setup/hold分别看哪个电压

Scenario 建好后，直接report_timing就行。但报告出来怎么解读，这里有很多讲究。

默认情况下，Primetime 会对所有 scenario 做分析，report_timing报的是 worst case。如果 setup 违例，通常来自最低电压、最高温度、最差工艺的组合——因为电压越低 cell delay 越大，数据路径延迟越大，setup 就越紧。所以低电压 corner 的 setup 检查是最关键的。

Hold 违例则相反，通常出现在最高电压、最低温度的 fast corner。电压高时 cell delay 小，数据路径延迟小，容易导致数据到达时间早于保持时间要求，hold 就崩了。如果 hold 在 fast corner 下能收敛，在 slow corner 下一般不会出问题。所以做一个检查矩阵是比较稳妥的：

实际跑的时候，我一般是先在全场景模式下跑一遍 coverage，看哪些 scenario 没过，再针对出问题的 scenario 深挖路径。

有一个数字工程师容易忽视的点：电压缩放时，setup 的最差情况不是简单的“最低电压”，因为频率也是联合调节的。比如低功耗模式虽然电压低，但频率也低了很多，留给时序的周期反而长。真正危险的是某个中间状态，电压降了但频率没怎么降——比如从 0.9V/1.6GHz 切到 0.85V/1.5GHz，电压降了 5.6%，频率只降了 6.25%，时序裕量并没有释放多少，但 cell delay 增大了。这种组合才是需要重点盯防的。

我的做法是跑完之后，用report_analysis_coverage -summary把每个 scenario 的时序违反情况汇总在一张表里，再对比各 scenario 的 WNS 和 TNS。这样可以快速找出风险最高的电压频率组合点，而不是等 signoff 阶段才发现问题。

3.4 动态缩放场景的处理技巧

DVFS 设计里，除了分析各个稳态工作点，还要考虑电压切换过程。电压从 0.9V 降到 0.7V 不是瞬间完成的，中间要经过一长串瞬态过程，开关频率在此期间也会动态调整。Primetime 本身是静态分析方法，不仿真瞬态，但我们可以通过构造边界 scenario 来近似覆盖。

一种常见的做法是：在电压切换过程中，强制让时钟停在安全频率，等电压稳定后再恢复满频。这需要 DC 和综合阶段在架构上支持，时序上则单独建一个“切换模式”的 constraint，频率取切换期间最差的真实值，电压取切换路径上可能经过的中间电压。比如从 0.9V 切到 0.7V，把中间态 0.8V 也建一个 corner，频率按切换期间实际运行的时钟设，跑一遍确保不挂。

另外，电压切换时会产生短暂的不稳定，PLL 可能需要重新锁定，时钟可能暂时丢失。这些行为不是 STA 能覆盖的，需要配合形式化验证和硬件验证。但从 Primetime 的角度，我们能做的是把电压切换涉及的所有中间电压点都纳入分析范围，确保任何瞬时组合都有时序依据。

我在实际项目里还用过一种技巧：对 DVFS 切换路径上的 cell 单独设更紧的 derate。比如整体时序 derate 是 5%，对电压切换频繁的那条路径加到 8%，给自己多留余量。这样虽然保守一点，但能明显降低流片后切电压时挂掉的概率。

4. 常见问题与排查技巧实录

4.1 电压点对不上库：工具报错的定位思路

这是用 Primetime 做多电压分析时最容易遇到的问题。症状通常是：跑了一堆 scenario，个别 scenario 的 timing report 出现大量INCR为零、延迟数值非单调递增、或者警告提示operating condition not found。

这种问题八成是库里搜不到当前电压点对应的查表条目。很多.lib内部有operating_conditions声明，指定了默认电压和温度，如果工具加载库后发现 corner 设置的电压和库声明不一致，就会告警并有可能退回到附近电压外推。外推本身不是不能用，但外推范围太大时结果不可信。

定位方法很直接，用report_operating_conditions看当前每个 scenario 实际生效的 operating condition 是什么：

foreach_in_collection scen [get_scenarios] { current_scenario $scen report_operating_conditions }

我建议每个项目签核前都跑一遍这个命令，把每个 voltage corner 的生效库、电压值、温度值都核对一遍。不要嫌麻烦，这个动作能提前发现很多库版本不匹配的问题。

另一个可能的原因是 UPF 里的set_voltage和 corner 里的电压不一致。比如 UPF 里PD_CORE的电压设的是 0.72V，而create_operating_condition用的库是 0.70V 特征的，工具会以哪个为准取决于具体版本的优先级设置。这种不一致往往不会直接报错，只会在报告中体现为延迟异常。排查方法是在 UPF flow 下用report_power_domain和report_voltage确认电源域电压、再和 corner 对比。

4.2 setup和hold在不同电压下的博弈

多电压设计里最让人头疼的事：setup 和 hold 在不同电压下会打架。

我之前做过一个 SRAM 接口的收敛。0.80V 角下，接口路径 setup 有 80ps 的余量，hold 也正常。但切到 0.85V 角下，setup 裕量反而变差了。一开始我以为是库有问题，后来仔细分析发现，问题出在组合逻辑和数据、时钟路径对电压变化的敏感度不同。有些路径大部分是延迟较大的高阈值电压器件，有些路径是低阈值器件，电压变化时它们延迟变化的比例不一样，导致原先在低压下看起来不错的平衡，在高压下就错位了。

这种情况没法靠单一电压点优化解决。我把所有 voltage corner 的 WNS 摆在一起看，找到比例失调的路径后，重点在综合阶段对这些路径做逻辑重构或插 buffer，让它们在多个电压点下都有余量。如果实在无法同时满足，就检查约束是不是太紧，给接口路径单独设置set_multicycle_path或调整时钟相位。

记住一句经验：多电压时序收敛不是找一个电压点的最优解，而是找所有电压点都满足的可行解。有些路径在低压下好、高压下差，有些反过来，你需要接受“每个电压点都不差”而不是“某一个电压点特别好”。

4.3 与IR drop分析衔接：压降余量的处理

Voltage scaling 和 IR drop 是孪生兄弟。你设定模块电压 0.72V，但实际到达 cell 引脚上的电压还要扣除电源网络上的 IR drop。封装上焊线电阻、片内电源网格电阻、通孔电阻，叠加起来电压损失可能有 10mV 到 50mV，在低电压角下这个比例相当可观。

Primetime 做 voltage scaling 时，可以配合 RedHawk/Voltus 等工具做 IR drop 分析，把每个 cell 上的实际压降以 derate 方式反标回来。如果没有专门的 IR 分析结果，我的变通做法是在低电压 corner 上直接多压 1% 到 3% 的裕量。

具体实现方式有两种。一种是在set_operating_conditions里把电压值人为调低：

# 0.72V 的设计，预留 20mV 的 IR drop，实际按 0.70V 分析 set_voltage 0.70 -object [get_supply_nets VDD_CORE]

另一种是给时钟和数据路径分别设set_timing_derate。时钟路径和数据路径对 IR drop 的敏感度不一样，分开设比统一设更接近真实情况。一般来说数据路径的 derate 要大于时钟路径，因为数据路径经过的组合逻辑更深，累积 IR drop 更大。

我个人经验是，低电压角下 IR drop 的影响会被放大。同样是 20mV 的压降，1.0V 下只占 2%，0.65V 下就占了 3%。所以如果项目有 AVS 功能，务必让后端电源网格设计在最低电压点下也能满足 IR drop 目标，否则时序余量再多也扛不住真实芯片上的电压跌落。

4.4 工程经验速查表

最后整理一份我在多个项目里验证过的经验清单，放在手边当速查表用。

另外再补充一条容易被忽略的：多电压分析时会话文件很大，建议跑完后用write_session保存，方便后续定位问题。我见过有人每次都在内存里直接查报告，过两天发现场景不对又得重跑整个流程，白白浪费机时。

Primetime 做 voltage scaling 并不是一个需要背命令的技巧活，核心是理解“每个电压点都是一个独立的时序世界”，然后用 MMMC 和 UPF 把所有这些世界有序地组织起来。多跑几次、多对比不同 scenario 的数据，慢慢就能摸清其中的规律。我在项目里反复验证下来，最值得花时间的环节反而不是建脚本，而是前期确认库的电压覆盖范围和后期核对各类报告的数据一致性，这两步做扎实了，后面的收敛只是时间问题。