企业官网建设流程全解析

简介：《RedHawk User Guide》是ANSYS RedHawk 2021R1官方用户手册，面向数字后端电源完整性（power integrity）工程师及集成电路设计学习者，用于建立full-chip静态与动态电压降分析的流程认知。手册围绕RedHawk在设计流程中的应用展开，涵盖设计规划、设计开发与设计验证三个阶段，并系统介绍静态电压降分析流程、动态电压降分析流程、TCL命令用户界面以及数据准备方法，便于读者按章节理解从数据输入、命令调用到结果分析的关键环节。压缩包内为1个PDF文件，大小约11.73MB，单文档结构完整，适合作为案头参考资料随时查阅。目前已有1820人学习，既可供初学者梳理数字后端power分析的知识框架，也方便有经验的工程师在项目实践中核对流程与接口细节。

1. RedHawk 用户手册：数字后端 power 签核人员真正会翻的那几页

数字后端 power 签核里，最容易被当成摆设的就是工具手册。多数人第一次打开 RedHawk 的用户手册，看到 Full-chip Static and Dynamic Power Integrity 那一章就直接跳到 GUI 截图，结果真跑起来还是卡在数据准备——DEF 里 PG 没连通、Liberty 少了 PG pin、APL 和 lib 版本对不上，报错一行行刷屏。这份 2021R1 生产版手册（2020 年 11 月定稿）本身不是教程，更像一份参数字典加流程索引：静态压降、动态压降、EM、Early Analysis 各自成章，靠数据准备那一章串起来。它适合正在做 full-chip IR/EM 签核、手上已有一套 DEF/LEF/Liberty 却不知道先喂哪个文件的人，也适合被「仿真结果和硅上实测对不上」折腾过的熟手。翻它的正确姿势是先锁定目录结构和 GSR 关键字，再回头查具体参数。

2. 用 rh_setup.pl 搭出第一套工程目录：数据准备阶段的选型与自动化边界

数据准备在 full-chip IR 分析里占的时间，通常比跑分析本身长得多。一套 DEF/LEF/Liberty 从数字后端交到 power 签核手上，能不能一次跑通，八成取决于目录结构和文件命名有没有按工具的默认约定来。手册里那套 Recommended RedHawk Directory Structure 之所以值得照抄，不是因为它好看，而是因为 rh_setup.pl 这个脚本默认就按这个结构去找文件，换个人、换台机器，目录一拉就能复现同一套结果。这一章把目录、自动化脚本和多电源域输入三件事拆开讲。

2.1 一套 RedHawk 工程目录该长什么样

我一般不会在拿到数据的第一天就开始跑分析，而是先花二十分钟把目录摆正。手册推荐的结构大致是「一类输入一个目录，中间产物和报告各占一个」，好处是 rh_setup.pl 生成的 GSR 配置里路径是相对的，整个工程可以直接打包给别人。下面这张表是我按手册结构整理出来的实际用法，最后一列写的是「这个文件缺了会怎样」，比单纯列文件名有用。

几个容易被忽略的点：DEF 必须是带 PG pin 和 follow-pin 连接关系的那一版，综合后刚 place 完、还没做 PG 连接的 DEF 直接喂进去，工具不会报错，只会给你一张「所有 instance 电压都一样」的漂亮图，这种结果比报错更危险。LEF 要包含通孔阵列的定义，特别是自定义 via，否则抽取阶段会出现大量未建模的连接点。Liberty 除了常规的时序功耗信息，多电源域设计还必须带pg_pin组，这一点在 2.3 节展开。

提示：目录建好之后先用ls -R把结构贴进工程 README，交接时比口头说「文件都在里面」靠谱得多。

2.2 rh_setup.pl 与 gds_setup.pl：谁先谁后

手册把自动化脚本单列一节，是因为手工点 GUI 导入数据的做法在回归场景里根本不可用。rh_setup.pl 干的事是把设计名、工艺文件、库文件、DEF 路径读进去，生成一套可以直接跑的 GSR 和运行脚本；gds_setup.pl 处理的是 GDS 到 DEF 这一段，用于补 PG 形状或者算金属密度。顺序上我的习惯是先 rh_setup.pl 立骨架，再 gds_setup.pl 补形状，因为后者生成的层映射文件要写进前者的配置里。

# 第一步：按手册推荐结构建目录，名字和 rh_setup.pl 的默认搜索路径保持一致 mkdir -p redhawk_run/{def,lef,lib,apl,spef,vcd,gsr,pkg,work,reports} cd redhawk_run # 第二步：把后端交付的原始文件归位，重命名成不带版本后缀的稳定名字 cp ../delivery/top_pg_final.def def/top.def cp ../delivery/tech_5m_2tm.lef lef/tech.lef cp ../delivery/stdcells_*.lef lef/stdcells.lef cp ../delivery/tt_0p80v_25c.lib lib/tt.lib cp ../delivery/top.apl apl/top.apl

这段没什么技术含量，但重命名这一步是有讲究的：后面所有脚本里引用的是def/top.def这种稳定路径，后端每交一版新数据只需要覆盖同名文件，回归脚本一行都不用改。我见过太多工程因为文件名里带日期，每次迭代都要改十几个脚本，改漏一处就跑的是旧数据。

# rh_setup.pl：生成本工程的 GSR 配置和运行脚本骨架 perl $REDHAWK_HOME/bin/rh_setup.pl \ -design top \ -tech lef/tech.lef \ -lef lef/stdcells.lef \ -lib lib/tt.lib \ -def def/top.def \ -apl apl/top.apl \ -outdir .

参数逐个说清楚：-design是工程名，会作为输出数据库和报告的前缀；-tech指向工艺 LEF，决定金属层、电阻率、via 模型的来源；-lef可以给多个，标准单元和宏单元分开给也行；-lib同样是可重复参数，多 corner 分析时把 ss/ff 两套都列上；-def必须是带 PG 的那一份；-apl只在动态分析时需要，纯静态可以先不给；-outdir决定 GSR 文件落在哪。脚本跑完会在gsr/下生成一份带默认值的配置文件，里面的路径已经填好，剩下要改的主要是电压值和温度。

# gds_setup.pl：生成 GDS 导入用的层映射与 setup 文件 perl $REDHAWK_HOME/bin/gds_setup.pl \ -gds ../delivery/top.gds \ -layer_map ../delivery/layer.map \ -outdir gds_out

-layer_map是把 GDS 的 layer/datatype 映射到 LEF 里的金属层名，这一步错了会出现「GDS 里明明有金属，抽取出来是空的」这种玄学现象。-outdir下的输出主要是给后续金属密度计算和形状补齐用的配置文件。手册里对 gds_setup 的输出列了一张清单，实操中真正要检查的是层映射表里每一层是否都对应上了，我一般会grep一遍有没有unmapped字样。

注意：两个 setup 脚本都不会替你检查数据本身对不对，它们只负责把路径写进配置。跑完脚本不等于数据准备好了，后面还有一轮显式的导入验证。

2.3 多 Vdd/Vss 域设计：输入数据到底差在哪

单电源域设计喂进去就能跑，多域设计则处处是坑。手册在数据准备这一章专门列了 Multiple Vdd/Vss Analysis，把差异拆成 Liberty 语法、P/G arc 定义、GSR 关键字、APL 要求四块。这四块任何一块没对齐，工具都不会崩，而是安静地把某个域的电流算到另一个域头上，最后你看到的 IR drop 图是错的但看着很合理。

Liberty 这一块最容易被忽略。标准单元库里如果只写了功能，没写pg_pin与related_pg_pin，工具在计算某个 instance 的电流时会退回默认电源网络。手册里提到的 P/G Arc Definitions in Custom LIB Files 说的就是这件事：自定义库（尤其是 memory compiler 出来的宏）必须把每个电源引脚和它对应的 internal power 弧写全，否则宏单元的功耗会整块丢失。宏单元恰恰是动态压降的主要贡献者，丢了它，结果会好得离谱。

# 多域设计的 PG 网络声明：先声明网络，再声明域与网络的绑定关系 # 顺序不能反，先绑域后建网会导致域找不到供电网络 set_pg_nets -net VDD_CPU -net_type power -voltage 0.85 set_pg_nets -net VDD_GPU -net_type power -voltage 0.80 set_pg_nets -net VDD_IO -net_type power -voltage 1.80 set_pg_nets -net VSS -net_type ground -voltage 0.00 # 每个域单独指定它的电源与地，跨域单元（level shifter）要显式归属 set_power_domain -name PD_CPU -power_net VDD_CPU -ground_net VSS set_power_domain -name PD_GPU -power_net VDD_GPU -ground_net VSS set_power_domain -name PD_IO -power_net VDD_IO -ground_net VSS

这三行set_power_domain是整段脚本的核心：它决定了后面功耗计算时每个 instance 从哪个网络取电。电压值不是随便填的，要和你 Liberty 里voltage_map的标称值一致，差 50mV 在低压工艺下就是几个百分点的电流偏差。命令名在不同版本里可能略有出入，参数语义是稳定的，拿不准的时候redhawk -help或者查手册的 TCL Command Summary 一节最快。

GUI 那条路也值得提一句。手册里有 Exporting and Importing a GUI Configuration，意思是你在界面上调好的一套视图和参数可以导出成文件，下次直接导入。对偶尔跑一次的人无所谓，对要做几十个 corner 回归的团队，这套导出配置能省掉大量「上次那个颜色刻度是怎么设的」的回忆。我一般会把 GUI 配置和 GSR 一起放进版本管理，两者配套才完整。

3. 静态 IR Drop 跑通：功耗计算、PG 电阻抽取与 RedHawk-S

静态分析看起来简单——不考虑时间，只算直流压降——但它对输入参数的敏感度一点不比动态低。手册把静态流程拆成功耗计算、PG 网格电阻抽取、RedHawk-S 执行、结果评估四步，每一步都有一个「参数拍脑袋就会错一倍」的位置。这一章按执行顺序走一遍，重点是那几个必须显式钉死的参数。

3.1 Vectorless 功耗计算：四个参数必须先定

Vectorless 的意思是不给波形，靠翻转率和时钟参数推活动。手册在 Setup for Vectorless Power Calculation 下把参数分成四组：频率与时钟、instance 与 block 的开关状态、翻转率、翻转率缩放。这四组里任何一个用默认值，结果就只能当参考，不能当签核依据。

翻转率是这里面最玄学的一个。0.15 和 0.25 在纯组合逻辑上可能差出 60% 的动态功耗，而这个数字往往没人能说清是从哪来的。我的做法是：第一轮用保守值（偏高）跑，确认 PG 网络在最坏情况下不塌；第二轮拿真实仿真统计出来的翻转率再跑一次做对比，两次差距超过 30% 就说明第一轮的假设有问题，得回去查仿真激励。

# 时钟参数：先定主时钟，后面所有翻转率都挂在它上面 set_frequency -clock CLK -value 800MHz -duty_cycle 0.5 set_frequency -clock CLK_DIV -value 200MHz -duty_cycle 0.5 # 默认翻转率：未单独指定的信号统一按这个值算 set_toggle_rate -default 0.15 -scale_by_clock true # 缩放：数据通路按 0.2，控制逻辑按 0.05，比一刀切靠谱 set_toggle_rate -instance u_core/u_dp/* -value 0.20 set_toggle_rate -instance u_core/u_ctrl/* -value 0.05 # 测试与复位逻辑在功能模式下不翻转，显式关掉，否则功耗虚高 set_switching_activity -instance u_dft_wrap -state 0

-scale_by_clock true这个开关的意思是翻转率相对于时钟周期缩放，打开之后改频率不需要重设翻转率，对做多频点扫描很方便。按层次设翻转率比按 instance 一个个设现实得多，前提是后端交付的 DEF 保留了层次名， flat 掉的网表就只能靠单元类型猜了。

抽取参数也在这一步设。手册里 Setting Extraction Parameters 一节管的是金属电阻率、via 电阻、温度系数这些。默认值通常够用，但有两个地方我会手动改：一是温度，签核一般看高温（比如 125 度）下的电阻，默认 25 度会偏乐观；二是金属密度，见下一节。

3.2 PG 网格电阻抽取与金属密度

电阻抽取的输出不是给眼睛看的，是给后面的 IR 计算当输入。手册把 Metal Density Calculation 和 TCL Command R Extraction 放在一起讲，是因为金属密度直接影响有效电阻的计算——化学机械抛光之后的实际金属厚度和名义值有偏差，密度低的区域铜更薄、电阻更大。

# 金属密度：优先用 GDS 算出来的实际密度，没有 GDS 才退回按 LEF 名义值 calculate_metal_density -source gds -gds_file gds_out/top.gds # PG 网格电阻抽取，同时输出报告用于定位薄弱点 extract_pg_resistance \ -nets {VDD_CPU VDD_GPU VSS} \ -temperature 125 \ -metal_density from_gds \ -report reports/pg_resistance.rpt

-temperature 125是我加的习惯值，手册示例里常用常温，但签核场景下高温才是收敛条件。-nets要把所有域都列上，漏一个那个域的电阻就是 0，IR drop 会算得过分漂亮。报告里最该看的是每个 instance 从最近的 pad 到自身的等效电阻（Reff），以及整个网络的最大值。Reff 大的地方通常有两个原因：strap 宽度不够，或者 via 阵列数量不足。手册在 Examining Power/Ground Grid Weakness 一节给的判断方法就是拿 Reff 分布叠在版图上，找那些「孤岛」。

提示：抽取报告的文本版比图更有用，sort -k3 -n -r取前 100 行，基本就是需要加 strap 的位置清单。

3.3 跑 RedHawk-S 与结果导出

前面都是准备，真正算静态 IR 是 RedHawk-S 这一步。手册里 Running RedHawk-S 那一节的命令不长，关键在日志判读。

# 非交互执行，日志单独落盘，便于回归比对 redhawk -f run_static.tcl -log work/static_$(date +%Y%m%d).log

# run_static.tcl 核心内容 import_design -def def/top.def -lef {lef/tech.lef lef/stdcells.lef} set_pg_nets -net VDD_CPU -net_type power -voltage 0.85 set_pg_nets -net VSS -net_type ground -voltage 0.0 perform_power_calc -method vectorless analyze_static_ir -nets {VDD_CPU VSS} -report_dir reports export_db -format redhawk_db -path work/top_static.db

import_design之后第一件事不是急着往下跑，是先看日志里的 instance 数量和 DEF 里声明的对不对得上。差个几百个通常是某些 macro 没读进来。perform_power_calc完成后会打印总功耗，这个数字和综合报告里的功耗估算做一次对比，偏差超过一倍就要停下来查。analyze_static_ir才是真正解方程，输出包括每个 instance 的供电电压、每条 net 的最大压降、电流密度。export_db把结果存成二进制，后面做 GUI 查看或者和下一次迭代对比都用得上；手册专门讲了 Database Compatibility 和 Flexible Memory Caching，前者提醒你不同版本导出的库不一定能互相加载，后者是说大数据设计重新加载时可以用缓存省内存。

日志里还有一类信息容易被跳过：floating node 计数。这个数字非零说明有 instance 的电源引脚没连到任何网络，它的电压会被当成理想值，IR drop 图上看不出来，但统计最大压降时被悄悄排除。我现在的习惯是每次跑完先grep -i floating，非零就不看结果，先去修连接。

4. 动态压降分析的三条路线：Vectorless、RTL VCD 与门级 VCD 的取舍

静态分析回答的是「平均情况下电压够不够」，动态分析回答的是「时钟翻那一拍的瞬间会不会塌」。两者的输入差别主要在活动描述：静态靠翻转率推，动态要么靠工具自己造事件，要么靠真实波形。手册把动态路线分成 vectorless、RTL VCD 驱动、门级 VCD 驱动，外加一个 mixed mode 混跑。选哪条不是精度越高越好，而是取决于你手上有什么数据、要回答什么问题。

4.1 Vectorless 动态：假设、时钟门控与适用边界

Vectorless 动态分析的核心是「造一个最坏情况的活动序列」。手册的 Standard Vectorless Analysis Procedure 里，工具会基于时钟树结构、时钟门控单元的位置和翻转率假设，自动生成一组能让 PG 网络产生最大跌落的开关事件。这条路最大的优势是不需要仿真波形，RTL 刚综合完就能跑；最大的问题是它假设的「最坏」未必是你设计真实会遇到的。

时钟门控的处理是这条路线的关键分水岭。手册用 Unified Clock Gate Handling and Analysis 一整节讲这件事，默认行为是 Automatic Clock Gate Handling，工具自动识别 ICG 单元并按它们的使能状态推活动。这个默认值大多数情况下是对的，但有两种情况要手动干预：一是 ICG 的使能信号来自一个你明确知道长期关闭的模块，自动处理会假设它能打开；二是多级门控嵌套，工具的传播可能过于乐观。

# 动态分析前的准备：单元表征、功耗、抽取、封装四件事都要做完 perform_cell_characterization -apl apl/top.apl perform_power_calc -method vectorless -default_toggle 0.15 # 时钟门控：默认自动处理，个别模块手动指定使能概率 set_clock_gate_handling -mode auto set_clock_gate_handling -instance u_core/u_always_on_icg -enable_prob 0.95 # 动态分析主入口 analyze_dynamic_vcd_or_vectorless -method vectorless -cycles 200 -report_dir reports

-cycles 200是仿真窗口长度，太少可能错过最坏事件，太多跑得慢。我的经验值是先跑 100 个周期看波形形状，找到电压最低的那一段，再围绕它跑 200 到 500 个周期做精算。-enable_prob是给单个 ICG 指定使能概率，0.95 表示几乎常开，这类模块往往是动态压降的重灾区。

4.2 VCD 驱动：RTL 与门级的差别、critical cycle 怎么选

有波形就用波形，这是最直接的逻辑。但 VCD 分两种，处理方式完全不同。

RTL VCD 是从 RTL 仿真导出的，层次结构和门级网表对不上，工具需要做 state propagation——把 RTL 里的信号状态映射到门级 instance 上。手册在 Data Requirements for State Propagation 里列了前提：RTL 和门级网表的层次要有可追踪的对应关系，寄存器要能一一映射，多比特单元要特殊处理。这条路适合设计早期，此时门级仿真还跑不起来，但你已经想知道 PG 网络大概扛不扛得住。

门级 VCD 是综合后网表仿真出来的，信号和 instance 一一对应，不存在映射问题，精度最高，代价是仿真本身很贵。手册在 VCD Critical Cycle Selection 里给了一个实用思路：完整 VCD 可能几十万个周期，全喂进去跑不动，先做一遍快速扫描挑出电压跌落最严重的若干个周期，再拿这几个周期做精细分析。

# 门级 VCD 路线：先声明状态传播来源，再指定 critical cycle 选取策略 set_vcd_source -file vcd/gate_level.vcd -type gate set_state_propagation -mode gate_level # 不做全量分析，先粗扫再精选，-top_n 指定保留的最差周期数 select_critical_cycles -method scan -top_n 5 -window 20 # 多比特时序单元：VCD 里通常只记录一个引脚，需要显式展开 set_multibit_handling -mode expand -cells {u_core/u_mb_reg_*} analyze_dynamic -method vcd -cycles selected -report_dir reports/dyn_vcd

-top_n 5表示保留 5 个最差周期，-window 20是每个最差周期前后各带 20 个周期一起看，因为跌落往往是个过程而不是单点。多比特单元那一行是血泪经验：多比特触发器在 VCD 里常常只翻转一个 bit 的引脚，工具如果按单比特处理，会低估整块的开关电流，动态压降算出来偏小。-mode expand让它把多比特单元按位展开。

4.3 Mixed Mode 混跑与波形结果判读

大芯片上经常出现这种情况：CPU 核有完整的门级 VCD，某个第三方 IP 只有 vectorless 模型，剩下几个模拟模块连模型都没有。手册的 Mixed Mode VCD and Vectorless Analysis 就是为这种场景准备的，允许一部分 block 用 VCD 驱动、其余用 vectorless 生成。

# 混跑：给有波形的 block 指定 VCD，其余 block 走 vectorless set_vcd_source -file vcd/cpu_core.vcd -type gate -scope u_cpu set_analysis_mode -scope u_cpu -mode vcd set_analysis_mode -scope u_gpu -mode vectorless -toggle 0.2 set_analysis_mode -scope u_io -mode vectorless -toggle 0.05 analyze_dynamic -method mixed -cycles 300 -report_dir reports/dyn_mixed

分块设翻转率的逻辑和静态那边一样：数据通路高、控制逻辑低、IO 更低。混跑的风险在于边界——VCD 驱动的 block 和 vectorless 的 block 之间的接口活动没有真实波形，工具会按各自的假设生成，边界上的电源噪声可能被低估。我的做法是把边界 block 的翻转率上调 20% 作为余量。

结果判读上，动态输出比静态多一个维度：时间。手册在 Evaluating Results 里强调要看的是最差跌落点的位置、持续时间、以及对应的 instance。持续时间短于某个阈值的跌落通常可以放过，因为 decap 能吸收；持续几十个周期还上不来的，说明本地 decap 严重不足或者供电路径太长。噪声裕度（实际最低电压与单元最低工作电压之差）是最终判据，裕度为负的地方就是必须在流片前修的地方。

5. 避坑：五条只在日志里现形的翻车记录

下面这五条都是我自己或者身边人真实踩过的，共同点是工具不报错，结果看着合理，直到和硅上数据或者另一套工具的结果对上才发现不对。每条按现象、原因、解决写。

5.1 输入侧的三条

第一条：IR drop 图漂亮得不像话。

现象：整张图的压降都在 10mV 以内，最大值出现在 pad 附近，内部区域几乎全绿。

原因：DEF 里 PG 网络没有真正连通，大量 instance 的电源引脚是悬空的（floating node）。工具对这些引脚采用理想电压，不参与压降计算，于是图上看起来处处完美。日志里floating node count那个数字非零，但默认不显眼。

解决：每次import_design之后先grep -i "floating"日志，非零就停下来修 DEF，不要在错误的数据上继续跑。修法是回到后端确认 follow-pin 有没有做、特殊单元的 PG 引脚有没有显式连接。这条我现在已经做成脚本里的强制检查，日志里出现 floating 直接退出。

第二条：某个宏单元的功耗算出来是 0。

现象：报告里所有宏单元的功耗都是 0 或者一个极小的数，标准单元功耗正常。

原因：Liberty 里缺少pg_pin定义或者 P/G arc 没写全。工具找不到这个单元的电源引脚归属，就把它的电流丢掉了。手册在多个电源域那一节专门讲过这个语法要求，单域设计同样适用。

解决：拿grep -c pg_pin数一遍库文件里的定义数量，和单元数量对比。宏单元尤其要检查，memory compiler 出来的库经常要手动补这一段。补完之后重跑功耗计算，宏单元功耗应该和厂商 datasheet 的量级对得上。

第三条：动态波形形状不对，全是方波。

现象：动态分析的电流波形是理想方波，没有上升沿和下降沿，跌落曲线和预期差很多。

原因：APL 文件没加载或者版本和 Liberty 不匹配。没有 APL 时工具会退化成用平均电流加方波近似，这在静态分析里够用，动态分析里误差很大。手册在 Perform Cell Characterization 那一节把 APL 列为动态分析的前置条件。

解决：确认-apl参数指到了正确文件，且 APL 覆盖的单元和 Liberty 一致。检查方法是看日志里 characterization 阶段处理的单元数，应该等于库里的单元数，差很多就是版本对不上。

5.2 计算与判读侧的两条

第四条：两轮分析功耗差了一倍。

现象：同一套数据，隔了几天重跑，总功耗差了将近一倍，IR drop 结论完全不同。

原因：翻转率假设变了。第一轮用的是默认值，第二轮有人按模块调了，但没记录在脚本里，改在 GUI 上。这种改动不会进版本管理，换个人重跑就复现不出来。

解决：所有影响结果的参数只允许写在 GSR 文件或者 TCL 脚本里，GUI 上的改动一律导出成配置再合并回脚本。我的习惯是在脚本开头用注释写清楚每个翻转率假设的来源（仿真统计、经验值、还是保守估计），三个月后回来看还能说清。

第五条：动态压降比实测乐观 30mV 以上。

现象：仿真出来的最低电压比硅上实测高出一截，方向一致但幅度差很多。

原因：封装模型缺失或者只给了电阻没给电感。手册在 Defining Pad and Package Parameters 一节说得很清楚，动态分析里封装电感是关键项，L·di/dt在高速开关时贡献的压降可能比片上 IR 还大。只给 R 的模型会把这一项吃掉。

解决：封装模型至少要有 R 和 L 两项，pad 位置要和实际封装对应。没有封装数据的时候，我的做法是按经验值给一个偏保守的电感（每个电源球几 nH 量级）做敏感度扫描，看结论是否稳定。如果加上合理电感之后裕度就变负，那说明设计余量本来就不够，不能靠省略模型蒙混过去。

6. 把 Early Analysis 用起来：BPA、Decap 估算与一次回归验证

Early Analysis 这一章在手册里位置靠后，容易被跳过，但它恰恰是功率完整性分析里最省钱的一段。等版图做完再发现 PG 网络不够，改一版就是几周；在 RTL 阶段用 block 级功耗估算先把 PG 规划验证一遍，成本是几个小时。

手册给的早期流程输入比完整分析少很多：floorplan 阶段的 DEF（PG 可以只有主干）、每个 block 的功耗和电流估计（来自综合报告或 spreadsheet）、以及电源网络规划。核心动作是 Block Power and Current Assignment（BPA）——把 block 级的总电流分配到具体的电源引脚或区域上，让工具能算出一个粗略但有意义的压降分布。之后是 Early Stage Decap Estimation，工具会估算在每个区域加多少 decap 才能把动态跌落压到目标以内。

我的用法是把 Early Analysis 当成回归的第一道闸门。做法很简单：拿到新的 floorplan 之后，先用上一版的 block 功耗表跑一遍 BPA，把结果里的最差压降和上一版对比。如果恶化了超过 15%，就在进入完整分析之前先和后端对一次 PG 规划，而不是等跑完几天动态分析才发现问题。

# Early Analysis：block 级电流分配 + decap 估算 import_design -def def/top_fp.def -lef lef/tech.lef set_block_power -block u_cpu -power 1.2W -voltage 0.85 set_block_power -block u_gpu -power 0.8W -voltage 0.80 assign_block_current -method uniform -layer M7 ;# 按主干层均匀分配 analyze_early_ir -nets {VDD_CPU VDD_GPU VSS} -report_dir reports/early estimate_decap -target_drop 45mV -report reports/early/decap_est.rpt

-method uniform是最粗的分配方式，适用于还没有详细布局的阶段；有 block 内部布局时可以换成按面积或按单元密度分配。-target_drop 45mV是你要压到的目标压降，这个值来自噪声裕度预算，不是拍脑袋定的。decap 估算报告给的是每个区域的建议容值，实际插入时还要考虑漏电和面积，通常只采纳其中 60% 到 70%。

有一条经验值得单独说：Early Analysis 的绝对数值不准，但相对趋势很准。同一个设计两版 floorplan 之间比较，哪个更好一目了然；但拿它的绝对压降去和完整分析比，差 30% 都算正常。从那以后我每次拿到新 floorplan，都强制先跑一遍 BPA 再排后续的分析计划，省下的返工时间远超过跑这一步的几分钟。希望帮到你。

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