数字后端电源签核：RedHawk静态IR、动态压降与GSR配置

简介：《RedHawk User Guide》是ANSYS RedHawk的官方用户手册，面向从事数字后端电源完整性分析的工程师和进阶学习者，用于解决全芯片静态、动态功耗完整性评估与优化中的工具使用与流程理解问题。手册围绕RedHawk在设计流程中的角色展开，依次说明设计规划、设计开发与设计验证阶段的应用方式，并覆盖静态电压降分析流程、动态电压降分析流程、TCL命令用户界面及数据准备等关键章节，读者可据此建立从分析目标设定、数据组织到结果判读的完整知识框架，也便于在实际项目中对照命令与流程排查问题。资源包内为1个PDF文件，压缩包约11.73MB，文档结构完整、章节层级清晰，适合按主题检索或通读研习。目前已有1822人学习下载，对需要系统查阅RedHawk用法、补充电源完整性分析思路的数字后端从业者具有较高参考价值。

1. 数字后端 power 签核最难受的那一段：报告出来了，但你不敢签字

版图收尾前两个月，静态 IR 报告里某个 block 的 worst instance 掉到标称电压的 91%，动态压降只给出一个孤零零的百分比，Foundry 的签核清单摊在桌上，而你手上躺着十几个来源不明的 GSR 文件，谁也不敢确定哪个关键字管的是哪件事。这份 RedHawk User Manual（Software Release 2021R1）解决的正是这个时刻的问题——它不讲 power integrity 的理论推导，讲的是数据怎么进工具、参数在哪个界面设、报告里每个数字是从哪一步算出来的。它适合已经跑过一轮静态 IR、准备接手动态压降和 EM 签核的数字后端工程师；完全没碰过 PI 分析的人拿它入门会被劝退，但当成一本随时翻的操作手册，价值远高于任何一份二手笔记。

2. 先定位再翻书：静态与动态两条 flow 的分界线在哪

2.1 一条 R 网络，两种电流假设

静态分析和动态分析共用同一套电源网格提取结果，差别全在电流怎么灌进去。静态流程把每个 instance 的电流当成一个不随时间变化的常量，灌进 PG 网格解一次线性方程组，结果只对两件事敏感：金属电阻和电流幅值。动态流程则要求电流带时间维度——每条 cell 内部开关产生的电流波形、decap 在某个时间窗口里能放出多少电荷、package 电感在 di/dt 上的压降，全部进入方程，解的是时域响应。

这个差别直接决定了输入清单。静态流程有 DEF、LEF、Liberty、APL、tech file 就能开跑，动态流程还额外需要 cell 的电流波形表征（在 APL 里体现）、decap 的分布和容值、以及 package 的 R/L 模型。手册把数据准备单独放在第 3 章，把静态放在第 4 章、动态放在第 5 章，这个结构不是随意排的——第 3 章产出的东西两条 flow 共用，第 4 章算出来的 vectorless 功耗结果，也是第 5 章动态分析的输入。

所以顺序上不能跳：先按第 3 章把文件凑齐、GSR 写对，再按第 4 章把功耗和 R 提取跑通，动态才是最后一步。很多翻车案例是把动态流程当成一个独立工具，直接拿一份别人的 GSR 改改就开跑，功耗那一层是错的，后面所有波形都在放大这个错误。

2.2 按症状查手册，别按目录顺序读

这本手册七百多页，从头读到尾是最低效的用法。下面这张表是我自己贴在工位上的索引，左边是你手上的具体症状，右边是手册里对应的节。

这张表的价值在于把“查手册”从翻阅变成定位。手册里真正的方法论密度很高的章节，其实是第 4 章讲功耗计算设置的那几十页，以及第 5 章讲 VCD 周期选择的那几页，其余大量篇幅是界面说明和菜单项罗列，扫一眼知道在哪即可。

2.3 开工前必须凑齐的数据清单

在打开工具之前，先把下面这张表里的东西对齐。缺任何一项，工具未必报错，但结果的可信度会打折——这是最危险的一类问题，因为它不会让你停下来。

表格里最容易被忽略的是 tech file 和 package 模型。前者很多团队直接用工具默认工艺，后者干脆不建，理由是“先看看片上”。片上 IR 和封装压降是两个量级不同的东西，混在一起看会得出完全相反的结论。

3. 数据准备与多电源域：rh_setup.pl、gds_setup.pl 和那些必须先对齐的文件

3.1 目录结构与 rh_setup.pl：先让文件各就各位

手册推荐的目录结构不是形式主义。当一个设计要跑静态、动态、早期分析、多工艺角，同一个文件名出现在五个地方是常态，没有固定结构就无法回答“这份结果是哪版 DEF 跑的”。我一般按下面这个骨架搭，和手册的 Recommended RedHawk Directory Structure 保持同构，换机器时整个目录打包就能复现。

# 一个够用的工作目录骨架，与手册推荐结构保持同构 mkdir -p redhawk_run/{lef,def,lib,apl,tech,gsr,vcd,reports,db} # 设计数据按版本命名，不要把新 DEF 直接覆盖到旧目录上 cp ./release/top_v3.def redhawk_run/def/top.def cp ./release/top_v3.lef redhawk_run/lef/top.lef # rh_setup.pl 负责生成 GSR 模板并检查输入完整性 # 各版本参数名有出入，先跑 -help 看本机支持哪些开关 rh_setup.pl -help rh_setup.pl -design top \ -lef ./lef \ -def ./def/top.def \ -lib ./lib \ -apl ./apl \ -workdir ./ \ -out ./gsr/top.gsr

这段脚本做三件事：建目录、按版本落文件、用脚本生成一份 GSR 骨架。参数里-design是设计名，会写进 GSR 和后续报告的文件名前缀；-lef、-lib、-apl传的是目录而不是单文件，脚本会把目录下所有库都挂进去，所以目录里不要放无关的旧版本库，否则会出现两个同名 cell 定义打架；-out指定生成的 GSR 路径。

要强调的是，rh_setup.pl 生成的是骨架，不是答案。它会填好路径类和结构类关键字，但供电网络名、功耗计算方法、toggle rate 这些跟设计强相关的项，仍然要人工写。生成之后第一件事是打开 GSR 把 power/ground net 的名字核对一遍，这一步省下来，后面会以“所有 instance 电流为 0”的形式还给你。

3.2 GDS2DEF：gds_setup.pl 的 layer map 是事故高发区

拿到的是 GDS 而不是 DEF 时，手册给的路是 gds_setup.pl。这个脚本的本质是“用 LEF 的层定义去解释 GDS 的几何”，所以它能做对的前提是 layer map 写对。

# 用 LEF 的层定义解释 GDS 几何，输出可直接被 RedHawk 读取的 DEF gds_setup.pl -gds ./gds/top.gds \ -lef ./lef/top.lef \ -layer_map ./tech/layer.map \ -out ./def/top_from_gds.def

-layer_map是唯一需要手工维护的输入，格式是把 GDS 的层号/数据类型映射到 LEF 的层名，手册的 Outputs 一节给了输出文件清单和检查方法。这里最常见的翻车是电源网格的顶层金属没有映射上——脚本不报错，DEF 也能生成，但那一层金属在 DEF 里根本不存在，提取出来的 PG 网格电阻凭空大了几倍，IR 结果看起来“特别差”，你会花两天去怀疑供电方案，其实问题在 map 文件少了一行。

判断方法很直接：生成 DEF 之后，逐层统计金属图形的数量和总面积，和 GDS 里对应层比一遍。数量级对不上就是映射错了。这一步花十分钟，能省两天。

提示：手动导入这条路手册也留着，命令行的 Command Line Data Import 和 GUI 的 GUI Data Loading 两条都行。批量跑用命令行，第一次调数据用 GUI，因为 GUI 加载时会实时把几何画出来，缺层一眼就能看见。

3.3 多 Vdd/Vss 域：Liberty 语法差异、APL 与 AVM

单电源域的设计照默认流程走就行，一旦有两个以上电压域，Liberty 的写法、APL 的组织、GSR 的声明三处必须同时对。手册专门用 Liberty Library Syntax Differences for Multiple Vdd/Vss Domains 和 APL Requirements for Multi-Vdd Designs 两节讲这件事，原因就是这里错一点，结果全歪。

核心机制是：每个 cell 在 Liberty 里通过 pg_pin 组声明自己挂在哪个电源/地网络上，再通过 related_power_pin、related_ground_pin 这样的属性把信号 pin 关联到对应的供电 pin。工具读库时按这个关系把 instance 分配到域。如果库里没写，工具只能按全局默认网络分配，于是本该接 VDD_CPU 的 instance 被算到 VDD_IO 上，那个域的电流虚高，另一个域电流为 0。

验证方法很笨但有效：跑完功耗，打开 power report，看每个域下的 instance 数量和总电流。任何一个域是 0，或者数量和网表对不上，先别往下走，回头查 Liberty 的 pg_pin。这个检查我一般做成脚本，每次换库都跑一遍。

3.4 GSR 文件与 vectorless 功耗计算的四个旋钮

GSR 是整套流程的配置真相，但它不是黑匣子——手册的 TCL Command Summary 一节列了关键字和对应命令，GSR 里的每一项都能在 TCL 命令行里找到等价写法。理解这一点之后，GSR 就变成了一份可 diff、可版本管理的文本配置，而不是“别人给的、不敢动的东西”。

vectorless 功耗计算有四个必须显式设置的旋钮，这四项决定了动态分析的天花板，因为动态流程的电流源头就是这里算出来的功耗：

toggle rate 这一项最容易被当成“填个 0.1 就行”。实际上它应该来自模块级的活动率估算或者上一版 VCD 的统计，频率和时钟参数则要和 SDC 对齐。手册里还提到 clock 与 signal 两种 toggle rate 同时生效时的处理方式（Using both clock and signal toggle rates in power calculation），这条在多时钟设计里必须读，否则会出现时钟网络被重复计一次或者完全漏掉。

功耗计算方法的选择（Selecting Power Calculation Methodology）、供电网络声明（Specifying Supply Nets）、总线与层次分隔符（Setting Bus and Hierarchy Delimiter Keywords）这三项在同一个章节里，属于一次设好、长期不变的部分。分隔符看着无关紧要，但报告里的 instance 名字带不带层次路径，直接决定了你能不能按模块聚合结果——这个坑我在第一次做模块级 IR 汇总时踩过，报告里全是扁平名字，只能靠正则硬匹配。

3.5 R 提取、pad/package 与一次完整的静态跑

把前面几步串起来，一次完整的静态分析是这样走的：先做 R 提取，再做 pad/package 建模，然后跑 RedHawk-S，最后导出数据库和报告。

R 提取这一步里有一个容易被跳过的子步骤：metal density calculation。金属密度影响化学机械抛光后的实际金属厚度，进而影响电阻。手册把 Metal Density Calculation 单独列出来，就是因为默认不算是常见做法，而算与不算的 IR 差异可以到百分之十以上。提取本身有两条入口，TCL 命令行的 R Extraction 和 GUI 的 GUI Extraction，批量跑用前者，调参数用后者。

pad 和 package 建模同样有两条路，命令行和 GUI 各一套流程，另外还有一个 Package Compiler Utility 专门用来从封装参数生成模型。这里要设的是每个 pad 的位置、数量、以及封装侧的 R 和 L。片上 IR 只关心 die 内的金属，动态分析时的 L·di/dt 则完全来自封装，不建这一块，动态结果会系统性偏乐观。

跑 RedHawk-S 之前建议先做一次电源网格弱点检查（Examining Power/Ground Grid Weakness）。这一步不产生最终报告，但会用很低的成本告诉你哪些区域的网格密度不足、哪些 via 阵列电流密度偏高。先看这个再跑全量 IR，能避免“跑完之后发现热点在一个根本没布够金属的区域”这种返工。

跑完之后，结果可以导出到设计数据库，也可以导入回来做版本对比。手册里 Flexible Memory Caching for Database Reloading 这一节对大型设计很实用——重复加载同一个数据库时缓存能显著缩短时间，前提是数据库没被改动过。

4. 从功耗到动态压降：vectorless、RTL VCD、门级 VCD 三条路怎么选

4.1 三条路径的输入与假设对比

动态压降分析的输入精度决定了结果的可信度，手册给了四个层次的方法，从粗到细的代价差异很大。选哪条不是精度越高越好，而是看当前阶段能拿到什么数据。

Vectorless 是默认起点，它的准确性完全压在 toggle rate 上，前面第 3 章那四个旋钮设得准，vectorless 的结果就有参考价值；设得糊弄，后面三条路都救不回来。纯 VCD 分析最准，但代价是仿真时间长、VCD 文件大，一个大设计跑几个周期就可能是几个 GB，全跑完不现实，所以才有了周期选择的问题。

4.2 clock gate 与 RTL VCD：状态传播这一步不能省

时钟门控是动态分析里最容易被低估的机制。门控关断的时钟子树不翻转，那部分电流本该是零，但如果工具不知道门控关系，会按全翻转算，动态压降直接虚高。手册里 Unified Clock Gate Handling and Analysis 一节讲了两种处理方式：默认的自动门控处理，以及需要显式指定的模式。

自动处理在大多数设计上够用，它从库里识别集成时钟门控单元，按使能信号推断开关状态。但对于用自定义逻辑搭的门控、或者跨层次的门控链，自动识别会漏。判断是否漏了，看报告里被标记为 clock gate 的单元数量，和网表里实际的 ICG 数量对一遍，差得多就说明识别不全。

RTL VCD 这条路的核心难点是状态传播——RTL 级的翻转要映射到门级 instance 上，中间隔着综合、时钟树、以及各种优化。手册在 Data Requirements for State Propagation 和 GSR Keywords to Support RTL VCD Flow 两节里说明了需要哪些数据、哪些关键字要打开，以及 RTL VCD Reports 里能看到什么。这条路的价值在于：RTL 仿真通常比门级快一到两个数量级，在门级网表刚出来、还没跑完长仿真的时候，用 RTL VCD 先做一轮动态评估，可以把明显的供电问题提前暴露。

4.3 VCD 关键周期选择与 mixed mode

纯 VCD 分析绕不开一个问题：几百万个周期，跑哪几个。手册的 VCD Critical Cycle Selection 一节给的就是这个答案——不是随便截一段，而是按电流峰值或者功耗窗口对周期排序，挑最差的若干个。

我一般的做法是：先对整个 VCD 做一次轻量的功耗扫描，得到逐周期的总电流曲线，按峰值排序取前 5 到 10 个周期，每个周期前后各留一点裕量作为分析窗口。这样跑出来的动态压降才有代表性。曾经有一次图省事，从 VCD 中间截了一段“看起来挺热闹”的波形跑，结果报告显示压降只有 4%，而后来按峰值选周期跑出来是 11%——差别就在于截的那段正好是某个模块休眠期。

两个特殊情况的处理也在这一节附近：多比特时序单元（Multi-Bit Sequential Cell Handling in VCD Analysis）在 VCD 里的翻转记录方式和单比特不同，处理不当会漏算翻转；混合模式（Mixed Mode VCD and Vectorless Analysis）允许一部分模块用 VCD 驱动、其余用 vectorless 补，这在只有部分模块有激励的情况下很实用。

4.4 动态结果怎么读：decap、package L 与静态对照

动态压降报告里最该看的不是最大值，而是最大值出现的位置和时刻，以及它和静态结果的比例关系。一个健康的趋势是：动态压降的最差点通常出现在时钟沿之后的一小段窗口内，且明显大于同一点的静态压降。如果动态结果比静态还小，先别高兴，八成是 decap 被算进去了但电荷量不对，或者电流波形的时间窗口没对齐。

decap 的贡献要看它的位置和到热点之间的电阻路径。放在热点旁边的 decap 能提供的电荷远多于放在远处的同等容量。package 电感的影响则体现在电流变化率大的时刻，表现为 die 边缘区域的压降比中心更严重。这两个机制在报告里不容易直接区分，方法是做一次敏感性对比：把 package 的 L 设为零再跑一遍，两次结果之差就是封装贡献。

5. 五个把分析跑成“玄学”的常见问题

5.1 静态 IR 结果比预期好一大截

现象：最差 instance 的压降只有 3%，和同工艺同规模的历史项目差了三四倍，团队开始怀疑是不是供电做得特别好。

原因：R 提取用了默认金属电阻率，metal density 没算，实际厚度偏薄的那几层被当成标称厚度，电阻偏小。

解决：打开 Metal Density Calculation 重跑提取；再用 Resistivity Sensitivity 做一次电阻率正负百分之十的敏感度分析，看 IR 结果变化多少。如果敏感度超过预期，签核裕度就要按最差电阻率留。手册里 Example Procedure to Fix IR Drop Problems 那一节给了一个完整的算例，包括改 pad 数量、加 Metal6 strap 之后 IR 怎么变，值得照着走一遍建立量级直觉。

5.2 动态压降只有 3%，和同规模项目差太多

现象：动态分析跑完，最差压降点和静态差不多，报告看起来“很健康”。

原因：vectorless 的 toggle rate 用了默认值，时钟网络没标频率，时钟门控没识别，导致电流源头就偏小一个量级。

解决：回到功耗计算那一节，逐项检查频率与时钟参数、switching state、toggle rate 和缩放参数；再确认 clock gate handling 的识别数量是否和网表一致。校验方法是拿一段已知结果的 VCD 做对比，看 vectorless 算出的平均电流和 VCD 驱动的结果差多少，差得超过 30% 就说明 vectorless 的设置还不能用来做结论。

5.3 某个电源域的电流全是 0

现象：多域设计的功耗报告里，有一个域的 instance 数是零，或者有 instance 但总电流为零。

原因：Liberty 里缺 pg_pin 定义或 related_power_pin 属性，APL 没有按域提供表征，GSR 里也没声明这个域的网络名。三者任意一个缺失都会导致同样的现象。

解决：按手册的 Liberty 语法差异那一节补 pg_pin；检查 APL 的域覆盖；在 GSR 里逐个声明供电网络。改完之后重新读库，看每个域的 instance 数是否和网表统计一致——这个数字对不上，后面所有分析都不用看。

5.4 动态跑了八小时，最差周期不在这段 VCD 里

现象：报告显示压降很低，但和团队对这块设计的经验判断不符。

原因：截取的 VCD 窗口是随意的，没做关键周期选择，正好落在低活动区。

解决：按 VCD Critical Cycle Selection 的方法先做一遍逐周期电流概括，按峰值排序挑周期，再跑分析。同时用 Mixed Mode 把窗口外的模块用 vectorless 补上，避免因为窗口截断引入边界误差。

5.5 GDS 转出来的 DEF 少一层电源金属

现象：IR 结果异常差，检查 DEF 发现顶层金属层完全没有图形。

原因：gds_setup.pl 的 layer map 文件漏了这一层的映射，脚本不报错。

解决：对照 LEF 的层定义逐条核对 map 文件，特别是电源专用的顶层厚金属；生成 DEF 后逐层统计图形数量和面积，和 GDS 对比。这个检查应该固化成脚本，每次导入都跑。

6. 把分析往前挪：Early Analysis 的块级预算与两次交叉验证

等布局布线全部完成再跑分析，问题暴露得太晚，改一版要重来一轮。手册第 4 章的 Early Analysis 就是给这个阶段用的：没有完整 DEF 的时候，用块级的功耗和电流预算先把供电网络和 decap 估一遍。

它需要的输入很少——各 block 的面积、预估功耗、供电网络的基本拓扑，就能跑出块级电流分配（Block Power and Current Assignment）。在 BPA 阶段还可以直接生成 decap 单元（Creating Decap Cells During BPA），再做一次早期 decap 估算（Early Stage Decap Estimation），产出的报告能回答“按现在的供电规划，哪个块注定要出问题”。

本文还有配套的精品资源，点击获取