简介：《SpyGlass Power Estimation and SpyGlass Power Reduction Rules Reference Guide》是面向集成电路低功耗设计、静态功耗分析与EDA工具使用者的原厂参考指南，可用于在项目早期评估芯片功耗、定位功耗热点，并查阅降功耗规则的适用场景与约束。压缩包仅含1个PDF文件，大小约9.46MB，版本信息与规则章节完整，适合作为设计流程中的案头查阅资料与团队内部分享素材。文档围绕功耗估计与功耗降低两条主线展开：前者说明动态功耗、漏电流估计的配置与执行方式，以及如何分析各模块功耗贡献、验证设计规范；后者系统梳理逻辑门级、时钟网络、寄存器文件与存储器子系统等优化规则。文中还涉及与PrimeTime等EDA工具的集成、案例研究和最佳实践，并附常见问题解答，便于读者把规则映射到实际设计检查中。已有209人学习，适合需要快速建立SpyGlass功耗分析框架的工程师与高年级学生参考。

1. 版本对不上的经历：SpyGlass Power Estimation 与 Power Reduction 规则参考手册该放进哪个目录

前阵子帮人收拾一台去年装好的 EDA 机器，环境变量里指着的还是上一年的工具版本，手边却是 SpyGlass L-2016.06 的《Power Estimation and Power Reduction Rules Reference Guide》。工程一跑，power_est_average起的 goal 能过，出来的数却和综合那边差了近三成，回头查才发现手册里的规则名、参数名跟二进制里对不上——文档版本和工具版本错一个字母，读起来就是两个世界。这套环境在数字后端圈里太常见了：SpyGlass 装在共享盘、license 走公司服务器、功耗估计和降耗规则又是 RTL 阶段最早要交付的东西，装不好就是整个团队拿假数做决策。这篇按“装环境、挂手册、配流程、验证跑通”走一遍，适合刚接手环境、想把功耗估计流程落地的人。

2. 装前清点：SpyGlass L-2016.06 的系统依赖、磁盘与 license 槽位

功耗估计这条流程对机器的要求和单纯跑 lint 完全不是一个量级。lint 只读 RTL，功耗估计要读工艺库、读波形、读 SDC，还要在内存里维护一份带活动率的网表，配置不够的时候表现往往不是报错，而是跑到一半被系统杀掉，日志里只有一行Killed，这种坑最难查。所以先把家底盘清楚再动手，比装完再回头补更省事。

2.1 系统与依赖库对照：新发行版不一定能直接装

这类老版本 EDA 工具对系统库的依赖很深，太新的发行版经常在图形界面和 Motif 库上卡住。下面的对照表是我这几年反复验证过的一套组合，实际部署时按最右列的顺序逐项确认。

先跑一遍动态库依赖检查，看工具的主程序能不能把库全找到，缺库会在启动阶段就暴露，而不是等到跑 goal 时才炸：

# 检查主程序动态库依赖，重点看 "not found" 的行 ldd $SPYGLASS_HOME/bin/spyglass | grep -i "not found" # 老版本常缺的 32 位兼容库和 Motif 库 rpm -qa | grep -Ei "libXm|libXt|compat-libstdc|ksh|glibc" # 顺手确认下栈和句柄，两个都得放开 ulimit -s unlimited ulimit -n 8192

ldd输出的not found就是缺库清单，装上对应的兼容包再重跑一次，直到一行不剩。ulimit -s unlimited这条别偷懒跳过，我见过太多次网表稍大一点就Segmentation fault，日志里没有任何线索，最后发现就是栈只有 8 MB。ulimit -n则是波形文件多开时的保险，一次读十几个 VCD 的时候句柄不够会读到一半失败。

2.2 环境变量三件套：安装路径、PATH、license

环境变量写错是这套环境最高频的“装完了但用不了”。常见做法是在用户 home 下单独放一个 env 文件，每次开终端 source 一下，而不是往/etc/profile里堆——多版本共存时集中管理更省心：

# ~/.spyglass_env —— 每个新终端 source 一次 export SPYGLASS_HOME=/opt/eda/spyglass/L-2016.06 export PATH=$SPYGLASS_HOME/bin:$PATH # license：端口@主机，主备之间用冒号分隔 export LM_LICENSE_FILE=27020@lic-host-a:27020@lic-host-b # 临时目录放本地盘，千万别放网络盘 export SPYGLASS_TMP=/scratch/$USER/sg_tmp export TMPDIR=$SPYGLASS_TMP mkdir -p $SPYGLASS_TMP

三个变量各有各的坑。SPYGLASS_HOME必须指到版本目录这一层，指到上一级会出现“找得到可执行文件但找不到库”的怪现象；PATH要放在前面，机器上装了两三个版本时，谁在前面就用谁，这一点不做显式控制几乎必然出事；LM_LICENSE_FILE里主备用冒号分隔，端口号写错的表现是等三十秒后超时，很多人误以为是 license 服务器挂了。

SPYGLASS_TMP单独拎出来是我踩过坑之后的习惯。工具默认往/tmp写中间文件，而/tmp在很多机器上是内存盘或者已经被别的任务塞满，一个多 G 的中间文件写不进去，报错信息却指向别处。指到本地 scratch 盘，空间够，读写还快。

2.3 挂手册与版本自检：让参考手册和二进制对上号

这份SpyGlass-PowerEstimate-And-SpyGlass-PowerReduceRules-Reference是随安装目录一起交付的参考手册，L-2016.06 版对应 2016 年 6 月那个工具版本。落地方做法是把它放进工具自己的文档目录，跟其他参考手册并列，而不是丢在某个人桌面或者共享盘的“资料”文件夹里：

# 工具自报家门，确认版本号 $SPYGLASS_HOME/bin/spyglass -version # 手册挂到工具文档目录下，按产品线分文件夹 mkdir -p $SPYGLASS_HOME/doc/power cp SpyGlass-PowerEstimate-And-SpyGlass-PowerReduceRules-Reference.pdf \ $SPYGLASS_HOME/doc/power/ # 建个软链方便查，也可以直接写进团队 wiki 的路径 ln -sf $SPYGLASS_HOME/doc/power/SpyGlass-PowerEstimate-And-SpyGlass-PowerReduceRules-Reference.pdf \ ~/ref/spyglass_power_ref.pdf

-version的输出里重点是主版本号那一段，必须和手册封面的 L-2016.06 对得上。版本不一致时的处理方式不是“凑合看”，而是把手册换成跟工具同期的版本——功耗估计里规则名和参数名在不同版本之间改动不算小，照旧版手册配出来的参数，工具不认识的时候一般不会硬报错，而是静默忽略，最后数字不对还查不出原因，这是最耗时间的一类问题。

提示：如果机器上同时装了多个版本，给每个版本配一份独立的 env 文件，用别名切换，别指望一套环境变量通吃。

3. 配功耗估计流程：从工艺库、仿真数据到 SDC 的完整工程文件

环境装好了不代表能出数。功耗估计这条流程的输入有四类：工艺库、设计源文件、时序约束、仿真波形，缺任何一类，工具都会给出一个“能跑完但没意义”的结果。工程文件（.prj）就是把这四类输入串起来的地方，下面按实际配置顺序走一遍。

3.1 工艺库与 wireload：先让工具认识每一个单元

工艺库读不全的表现特别隐蔽：工具不会说“库不够”，而是把找不到的单元按黑盒处理，漏电和内功耗直接按 0 算，最后总功耗偏低。所以第一件事是把标准单元库和存储器宏库一次性读全，并且开启预编译，避免每次都重新解析几十兆的库文件：

# power_est.prj —— 平均功耗估计的最小可用工程骨架 set_option projectwdir ./sgwork set_option language_mode mixed set_option enableSV yes set_option top soc_top set_option enable_precompile_vlog yes # 工艺库：标准单元 + 存储器宏，少一个都会算出偏低的数 read_file -type gateslib ./lib/std_cell_tt.v read_file -type gateslib ./lib/sram_macro_tt.v # RTL 用文件列表读，几千个文件手写不现实 read_file -type sourcelist ./rtl/filelist.f # 时序约束与功率意图 read_file -type sdc ./constraints/soc_top_func.sdc read_file -type sgdc ./constraints/power_intent.sgdc current_goal Power/power_est_average run_goal

enable_precompile_vlog打开后，第一次读库慢，后面每次跑 goal 都快，长期用下来差别很大。read_file -type gateslib这一行要给的是带功耗信息的库文件，有些流程里只给了时序库，语法能过，功耗表却是空的，出来的内功耗全是 0——这种情况建议在工程文件里显式加一条自检，跑之前先看库的加载报告里 cell 数量和实际工艺对得上不对得上。

wireload 这一项 RTL 阶段经常被忽略。RTL 阶段没有真实连线，工具只能按统计模型估线电容，估得不准，开关功耗就飘。常见做法是从一个已经布过线或者至少综合过的网表里把线负载提出来，再用set_wireload套回 RTL：

# 把网表里提取出来的线负载模型套到 RTL 上 set_wireload -name wl_from_netlist -file ./work/wireload_netlist.txt set_wireload_mode wl_from_netlist

-name是给这套模型起的标识，后面报告里会带出来，方便回溯这份数据是哪天从哪个网表提的；-file指向提取结果。这一步做完，RTL 阶段的线电容估算能贴近真实值，功耗数字才敢拿去和综合那边对标。参数名在不同版本之间会有出入，以工具 Parameters 面板里显示的为准，别硬套别人的脚本。

3.2 仿真数据喂法：单文件、多文件、分块三选一

功耗估计和 lint 最大的区别就在这一步——没有活动率，就没有动态功耗。仿真数据的组织方式有三种，选哪种取决于手上波形是怎么导出的：

# 方式一：整个设计一份波形，适合规模不大、一次性跑完的仿真 read_file -type vcd ./sim/soc_top_full.vcd # 方式二：按时间片切成多份，工具按读入顺序拼接 read_file -type vcd ./sim/soc_top_part0.vcd read_file -type vcd ./sim/soc_top_part1.vcd # 方式三：每个 block 一份波形，靠层次名对齐到设计 read_file -type vcd ./sim/blk_a.vcd read_file -type vcd ./sim/blk_b.vcd

方式一最省心，缺点是文件太大，几十 G 的 VCD 读进去要很久，中途失败还得从头再来。方式二本质上是把长仿真切段，只统计其中一段有代表性的窗口，这时候要注意切的是同一段激励里连续的时间片，否则统计出来的活动率没意义。方式三适合模块级分别验证的团队，麻烦在于层次名必须和 RTL 严格对上，对不上时工具只会提示“部分信号未匹配”，不会中断，于是你拿到一份只有一半信号有活动率的结果，功耗自然偏低。

不管用哪种方式，跑完先看匹配报告，关注两件事：有没有大量未匹配的信号，以及顶层时钟和复位这些关键信号是否拿到了翻转率。这两项不对，后面所有数字都不用看。

3.3 SDC 与多 PVT 角：约束进不去，功耗数字就是假的

功耗对电压极其敏感，动态功耗跟电压平方成正比，漏电跟温度是指数关系。所以做功耗估计必须明确在哪个 PVT 角上算，多角一起跑的时候更要一组参数一个角，别混着来：

# 多 PVT 角：一个角一组参数，别在一个 goal 里混算 set_option pvt_corner_list {tt_0p9v_25c ff_1p0v_125c ss_0p8v_m40c} # 功能模式和扫描模式的约束分开读，不要合并 read_file -type sdc ./constraints/soc_top_func.sdc read_file -type sdc ./constraints/soc_top_scan.sdc

pvt_corner_list里的每个名字是自己起的，关键是名字里把工艺档、电压、温度都带上，报告出来一眼能看懂。这三个角代表三种典型场景：典型角看日常功耗，快角看动态功耗上限，慢角加低温看漏电。功能模式和扫描模式的约束分开读，是因为扫描模式下时钟翻转率远高于功能模式，混在一起统计会得到一个谁都不认识的数。

电压阈值混合（Vt mix）的库在 RTL 阶段还有一层麻烦：RTL 里没有具体的单元实例，工具不知道该按哪种 Vt 档去算。手册里给的做法是先在网表上跑一遍分布统计规则，把结果生成一份约束文件，再套到 RTL 上：

# 第一步：在网表上统计 Vt 分布 current_goal Power/power_est_vt_dist run_goal # 第二步：把生成的 SGDC 套回 RTL 工程 read_file -type sgdc ./work/vt_dist_generated.sgdc

这一步的价值在于，RTL 阶段的功耗估计如果不考虑 Vt 混合，漏电会系统性偏低。我一般会在流程脚本里固定加这一步，哪怕多花十几分钟，也比后面被问“为什么和 signoff 差这么多”强。

3.4 黑盒与 megacell：别让一个空盒子吃掉三成功耗

设计里只要有 IP、存储器、模拟模块，就一定会遇到黑盒。黑盒默认不贡献功耗，一个占面积三成的 SRAM 子系统被当黑盒，总功耗直接少三成，这种数字拿去做架构决策是要出事的。处理方式有两种：有功耗模型的，用模型文件建库；没有模型的，用 megacell 的方式显式声明并给个估算值：

# 有模型的：直接读带功耗表的库 read_file -type gateslib ./lib/sram_1024x64_tt.v # 没模型的：按 megacell 声明，手工给面积和功耗量级 define_megacell -name u_ddr_phy -power 12.5 -area 0.42

-power的单位以工程设置里的功耗单位为准，写之前先确认一遍，单位错了差一千倍都有可能。megacell 的用法要点是在报告里能被单独列出来，这样审阅的人一眼能看到哪些数是估的、哪些是模型给的，而不是把所有东西混进一个总数里。

还有一类容易漏的情况：库里有电源地引脚定义的单元，如果没打开对应选项，工具会把它们算成普通单元，漏电统计口径就错了。手册里专门有一节讲这类库的处理，配置时建议把这项打开，代价很小。

4. 开功耗降低规则：时钟门控、存储器优化与跨时钟域安全

估计是“看清楚”，降耗是“动刀子”。SpyGlass 的功耗降低规则本质上是在 RTL 上找可以插门控、可以省翻转的机会。这一步比估计更容易翻车，因为它会给出具体的修改建议，建议错了后面综合和形式验证都要返工。

4.1 隐式时钟使能：从“一个都没找到”到“找到一大片”

第一次跑时钟门控规则，最常见的结果是一条机会都没有。原因通常不是设计真的没机会，而是使能逻辑写得太散，工具按单一模式匹配不上。做法是把跨层次的使能识别打开，让它顺着层次往上找：

current_goal Power/power_reduce_clock_gating # 跨层次找使能，默认关闭，不开就只能看到同层的 set_option enable_gating_across_hierarchy yes # 优化已有使能的触发器，而不只是找新的 set_option opt_enabled_ff yes run_goal write_report moresimple > ./reports/clock_gating_summary.rpt

enable_gating_across_hierarchy打开之后，工具会把子模块里的使能条件提到父层去看能不能合并，能合并的会给出建议。代价是运行时间变长，大设计上可能要跑一两个小时，我一般放在夜间批处理里跑。opt_enabled_ff是对已经带使能的触发器做二次优化，很多时候设计里已经有门控，但门控条件冗余，合并一下还能再省一部分。

这里有个取舍：跨层次合并出来的门控会改变模块边界上的接口，如果团队对模块接口有严格约定，就不能无脑采纳，得逐条看建议。我的做法是先只开识别不开采纳，出一份机会清单，评审之后再决定哪些落地。

4.2 存储器降耗规则：先确认支持哪些 memory 类型

存储器功耗在 SoC 里占比经常过半，但存储器降耗规则的适用范围比想象中窄，因为它依赖于能识别出存储器的访问模式。跑之前先确认设计里的存储器类型在支持范围内，不然跑完是空报告：

current_goal Power/power_reduce_memory # 只对显式例化的存储器宏生效，综合出来的寄存器堆不算 set_option memory_reduce_enable yes set_option memory_reduce_report_mode detailed run_goal

memory_reduce_report_mode设成detailed之后，报告里会列出每个存储器实例的访问次数、使能利用率，以及建议的改法（比如加读使能、合并访问、调整 bank 划分）。这些建议的价值在于能落到 RTL 上，但要注意：只对显式例化的存储器宏生效，用寄存器堆出来的“伪存储器”不在规则覆盖范围里，这类结构要靠时钟门控去省。

我的习惯是先只跑 detailed 报告不出修改建议，把这几十条机会按节省量排序，取前若干条和设计负责人过一遍，确认不会影响功能之后再要求落地。存储器访问时序改动牵扯面大，一次性全采纳几乎必然引入功能 bug。

4.3 显式时钟使能的筛选与跨时钟域安全门控

时钟门控最大的风险不在省不省电，而在改完还能不能正确工作。跨时钟域的那部分尤其危险，工具看到的是一个逻辑上的可门控点，实际电路中这个门控可能引入新的亚稳态路径。所以手册里单独讲了 CDC 安全时钟门控和跨时钟域机会的处理方式：

# 跨时钟域机会单独处理，默认是保守的 set_option power_reduce_cdc_safe_gating yes set_option power_reduce_clock_domain_aware yes # 先出清单不落地，评审后再决定 set_option power_reduce_apply_changes no

cdc_safe_gating打开后，工具会在建议里标注哪些机会跨了时钟域，需要额外确认。clock_domain_aware让工具在合并门控时按时钟域分组，避免把两个不同时钟域下的使能条件错误地合并到一起。apply_changes设成no是我的默认值——先看清单，再决定改哪些，别让工具直接改设计。

另外还有两个技术值得了解一下：稳态条件（Stability Condition）和可观测无关项（Observability Don't Care）。前者是在信号稳定之后才允许门控，后者是利用下游不关心某些取值的特性去省翻转。这两个技术给出的机会往往更激进，节省量也更大，但对验证覆盖要求更高。我的态度是：新项目第一版不用，等 CDC 和形式验证流程成熟了再逐步放开。

4.4 报告与参数保存：DashBoard、DataSheet、Spreadsheet 三处怎么看

跑完不算完，报告的组织方式决定了这些数据能不能被用起来。三处输出各有分工，混着看容易乱：

DashBoard 适合看趋势，DataSheet 适合抠细节，Spreadsheet Viewer 则是把机会清单导出来分派给别人。我一般要求团队把 DataSheet 的数值和 DashBoard 的总量做一次交叉核对，两个对不上就说明有模块没被统计进去，这种问题在早期发现比在流片前发现便宜太多。

参数层面，功耗降低的 goal 里有一整组参数控制优化力度和代价。保守的做法是先用默认参数跑一遍拿到基线，再逐项调，每调一项记录一次结果。直接上激进参数，跑出来节省 25% 看着很爽，但后面综合面积涨了 8%，这个账要一起算。

5. 排查清单：装完跑不动、报错、数字离谱的 5 个现场

按“现象 → 原因 → 解决”记几条真实遇到过的，都是装完环境第一次跑流程时最容易撞上的。

一、启动就退，日志里只有一个Killed。现象是命令行回车后几秒钟进程消失，没有任何堆栈。原因是内存不够，工具在加载工艺库阶段就被系统 OOM 杀掉了，而日志还没来得及刷盘。解决办法是先看dmesg | tail里有没有 OOM 记录，确认之后把工作区挪到大内存节点，或者先用小设计的库跑通流程再换全库。栈限制没放开也会有类似表现，两个都要查。

二、spyglass -version正常，跑 goal 报找不到 licence。现象是启动阶段一切正常，run_goal时才报 licence 超时。原因是功耗估计和功耗降低属于不同的 licence 特性，lint 的 licence 不等于功耗的 licence，一套环境跑得通不代表这套流程跑得通。解决办法是拿 licence 服务器上的特性清单对一遍，确认功耗相关特性有可用槽位，别在生产高峰时段排队。

三、跑完功耗数字比预期低一大截。现象是报告能出，总量却明显偏低。原因通常是两类：工艺库只读了标准单元没读存储器宏，或者仿真数据和设计层次名没对齐、大量信号活动率是 0。解决办法是回头看库加载报告里的 cell 数量，再看仿真匹配报告里的未匹配信号比例，两个数有一个不对就先修输入，别急着调参数。

四、同一个设计两次跑结果不一样。现象是同样的工程文件，隔一天跑出来差几个百分点。原因是仿真数据用了不同的时间窗口，或者多 PVT 角跑的时候没固定角列表，工具按默认顺序取了不同的角。解决办法是把角列表和时间窗口写死在工程文件里，工程文件进版本管理，任何人跑都用同一份。

五、功耗降低建议有几百条，采纳后功能挂了。现象是照着报告改完 RTL，形式验证过不了。原因是部分建议涉及跨时钟域或者改变了复位路径上的逻辑，工具只从功耗角度判断可行，不保证功能等价。解决办法是把建议分级：同层、同域、不碰复位路径的先做；跨域的一律人工评审，评审不过就不做。

注意：这五条里有三条根因都在输入数据而不在工具配置，排查顺序永远是先查输入、再查配置、最后才怀疑工具本身。

6. 验证跑通：用审计 goal 加 DataSheet 报告做一次闭环自检

环境装完、流程配完，最后一件事是证明这套东西真的能出可信的数。我的做法是拿一个小规模的已知设计跑完整的审计链路，从设计审计到功耗估计再到报告输出，一次走通，把每一步的输出都留档，作为这台机器这套环境的基线。

# 1) 设计审计：先看设计本身有没有明显问题 current_goal Power/power_est_audit run_goal # 2) 平均功耗估计 current_goal Power/power_est_average run_goal # 3) 输出明细报告，留档做基线 write_report datasheet > ./reports/baseline_datasheet.rpt write_report moresimple > ./reports/baseline_summary.rpt

power_est_audit这一步很多人跳过，其实它最值钱：它检查的是设计侧的问题，比如有没有未驱动的输入、有没有悬空的输出、黑盒比例是不是过高、时钟有没有正确传播到所有触发器。审计报告干净了，后面的功耗数字才有解释力。审计里如果有告警，逐条确认是设计问题还是环境问题，别一股脑忽略。

write_report datasheet输出的明细是基线，重点核对三件事：总功耗的量级是否和同类设计的经验值接近、各模块占比是否和架构预期一致、漏电和动态功耗的比例是否合理。三项都对得上，说明这套环境是可信的。有一项对不上，就回头查对应的输入。

如果是物理感知的功耗估计流程，验证时还要多走一步：确认从物理侧传过来的输入（寄生参数、布局信息）确实被读进去了，报告里能看到来源标识。这一步没确认，等于用 RTL 的估算方法在跑物理流程，白费时间还容易得出错误结论。

从那以后我每次搭新机器，都会先拿这个小设计把这套审计链路强制走一遍，把三份报告存进一个叫env_baseline的目录，后面任何人报“数字不对”，第一件事就是拿他的报告和基线比，比完基本就知道是环境漂了还是设计变了。这套习惯帮我省下的排查时间，比装环境本身多得多。希望帮到你。

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