★ FEATURED ARTICLE 简介《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 库上卡住。下面的对照表是我这几年反复验证过的一套组合实际部署时按最右列的顺序逐项确认。项目推荐配置上限/下限说明怎么查操作系统RHEL/CentOS 6.x 系列7.x 可跑但需补旧版 libXm、libXtcat /etc/redhat-releaseShelltcsh / csh 为主bash 下部分启动脚本会丢变量echo $SHELL栈大小unlimited小栈跑大网表直接段错误ulimit -s文件句柄8192 以上波形文件多开时容易超ulimit -n磁盘安装815 GB含文档与示例工程df -h /opt磁盘工作区20 GB 起VCD 动辄几个 G别放系统盘df -h /scratch内存16 GB 起大设计 64 GB低于 8 GB 建议只跑 lintfree -g先跑一遍动态库依赖检查看工具的主程序能不能把库全找到缺库会在启动阶段就暴露而不是等到跑 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 8192ldd输出的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_FILE27020lic-host-a:27020lic-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_goalenable_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.sdcpvt_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.rptenable_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_goalmemory_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 nocdc_safe_gating打开后工具会在建议里标注哪些机会跨了时钟域需要额外确认。clock_domain_aware让工具在合并门控时按时钟域分组避免把两个不同时钟域下的使能条件错误地合并到一起。apply_changes设成no是我的默认值——先看清单再决定改哪些别让工具直接改设计。另外还有两个技术值得了解一下稳态条件Stability Condition和可观测无关项Observability Dont Care。前者是在信号稳定之后才允许门控后者是利用下游不关心某些取值的特性去省翻转。这两个技术给出的机会往往更激进节省量也更大但对验证覆盖要求更高。我的态度是新项目第一版不用等 CDC 和形式验证流程成熟了再逐步放开。4.4 报告与参数保存DashBoard、DataSheet、Spreadsheet 三处怎么看跑完不算完报告的组织方式决定了这些数据能不能被用起来。三处输出各有分工混着看容易乱输出位置主要看什么适用场景DashBoard总体功耗构成、各模块占比架构评审、跨版本对比DataSheet逐模块逐指标的明细数值定位功耗热点、写报告Spreadsheet Viewer门控机会、存储器机会的清单逐条评审、分配任务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.rptpower_est_audit这一步很多人跳过其实它最值钱它检查的是设计侧的问题比如有没有未驱动的输入、有没有悬空的输出、黑盒比例是不是过高、时钟有没有正确传播到所有触发器。审计报告干净了后面的功耗数字才有解释力。审计里如果有告警逐条确认是设计问题还是环境问题别一股脑忽略。write_report datasheet输出的明细是基线重点核对三件事总功耗的量级是否和同类设计的经验值接近、各模块占比是否和架构预期一致、漏电和动态功耗的比例是否合理。三项都对得上说明这套环境是可信的。有一项对不上就回头查对应的输入。如果是物理感知的功耗估计流程验证时还要多走一步确认从物理侧传过来的输入寄生参数、布局信息确实被读进去了报告里能看到来源标识。这一步没确认等于用 RTL 的估算方法在跑物理流程白费时间还容易得出错误结论。从那以后我每次搭新机器都会先拿这个小设计把这套审计链路强制走一遍把三份报告存进一个叫env_baseline的目录后面任何人报“数字不对”第一件事就是拿他的报告和基线比比完基本就知道是环境漂了还是设计变了。这套习惯帮我省下的排查时间比装环境本身多得多。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
