简介面向集成电路设计、低功耗优化与EDA分析人员的SpyGlass功耗估计与功耗降低规则参考指南重点解决早期功耗评估、热点定位及低功耗规则落地问题。压缩包内仅含1个PDF文件约9.46MB正文按功耗估计概述、规则说明、工具集成、案例研究、最佳实践和常见问题解答组织便于按主题查阅。其中功耗降低规则覆盖逻辑门级优化、时钟网络优化、寄存器文件与存储器子系统优化并说明与PrimeTime等EDA工具的协同分析方式能帮助读者把功耗约束落实到设计检查流程中。已有209人学习适合作为SpyGlass功耗分析的手边参考资料也可用于对照项目排查功耗热点与验证优化效果。1. 从一份 2016.06 的功耗规则手册说起它到底能替你省哪几步很多团队把功耗签核拖到流片前两周最后卡住的往往不是规则不会跑而是输入活动文件、网表层级和约束口径对不上。这份功耗估计与功耗降低规则参考手册价值不在教你点哪个按钮而在把工艺库、仿真数据、SDC、PVT 角、黑盒模型和门控机会串成一条可复现的检查链。它适合已经能跑基础静态检查、但功耗数字总对不上或降不下来的一线设计和签核人员。新手可以照着搭底座熟手更适合把它当规则边界表遇到某个规则报错时直接翻对应章节核对前提。我拆这类手册的习惯是先看输入清单再看规则触发条件最后看报告口径。顺序反了后面很容易被一个层级映射问题带偏白跑几轮。2. 搭起可复现的功耗估计底座库、仿真数据与 SDC 三件套2.1 先定输入边界工艺库、网表/RTL 与仿真活动功耗估计最容易翻车的地方不是某个规则没开而是输入边界没定清楚。RTL 阶段做早期估算网表阶段做签核前复核两者对工艺库、连线模型和仿真活动的依赖完全不同。我的做法是先把输入分成五类工艺库与 Vt 信息、设计对象RTL 或网表、仿真活动文件、时序约束、可选物理与电源意图信息。五类里面少一类后面的数字就只能当趋势看不能当结论用。工艺库要确认三件事库文件与设计所用单元版本是否一致、低功耗单元是否被正确映射、Vt 混合库是否带标注。常见做法是先用一个最小模块跑通读库和展开再上完整设计直接拿完整设计试错日志里会混进大量单元解析错误反而看不到真正的输入问题。设计对象要明确是 RTL 还是门级网表。RTL 阶段优势是迭代快适合做功耗探索和门控机会筛查门级网表优势是连线电容和单元延迟更接近实现适合做相关性复核。两边混用时最怕拿门级活动文件去套 RTL 层次名字对不上工具只能按启发式映射结果会偏。仿真活动文件是功耗估计的燃料。活动覆盖率不够功耗曲线会很“安静”看起来漂亮但不可信。我一般要求活动文件覆盖典型工作模式、峰值模式和低功耗模式三类场景并且每个场景都标明时间窗口。窗口里如果包含复位释放、时钟切换、存储器初始化读数会被瞬态拉高不适合直接拿平均值做签核。约束文件负责把时钟、输入延迟、输出负载、false path、case analysis 这些口径固定下来。功耗对时钟频率和负载敏感约束里一个时钟定义写错后面 switching power 会整体漂。我的习惯是先跑一次只读约束的检查确认时钟树根、生成时钟、跨时钟域路径都被识别再开功耗规则。这个顺序能省掉很多“规则误报”的排查时间。提示先做输入清单核对再跑功耗规则输入清单没有签字确认前不要拿报告做设计决策。2.2 单文件、多文件、分块仿真数据的组织方式仿真数据组织方式直接决定后面 mapping 的难度。手册里给了单文件、多文件、按 block 分文件三种路子我的经验是不要一上来追求“一个文件全包”而是按设计层级和验证场景拆开。单文件适合小设计或快速验证多文件适合多场景合并分块文件适合大设计和模块级复用。三种方式没有绝对优劣关键看活动文件里的层次名能不能和当前设计对象对上。组织方式适用场景主要风险我会加的检查单文件覆盖全设计小规模设计、快速回归文件大、窗口难切、错误定位慢先看文件头时间范围与顶层名多文件按场景拆分典型/峰值/低功耗模式场景之间窗口重叠或漏覆盖每个文件标注场景和窗口按 block 分文件大设计、模块级并行顶层胶合逻辑活动缺失检查顶层与子块覆盖率单文件方式最省事但大设计里活动文件会膨胀得很快后面想看某个模块的峰值功耗窗口一切就牵连全设计。多文件方式更适合做场景对比代价是要维护文件清单和场景标签不然回归时很容易漏掉低功耗模式。按 block 分文件对团队协作最友好模块负责人各自提供活动文件顶层只负责胶合逻辑和接口活动缺点是顶层与子块的时间窗口必须对齐否则平均功耗会被不同窗口拼接歪。可抄作业的步骤是这样第一步列出设计层级和每个层级的活动文件责任人第二步按场景给文件命名名字里带顶层名、场景名、时间窗口起止第三步先用小窗口跑一次 mapping report确认网表 net 与 RTL 信号匹配率第四步匹配率不达标时优先查层次名、信号位宽、总线拼接和时钟门控单元插入点不要直接改规则阈值。匹配报告里低匹配率的模块往往就是后面功耗异常的热点模块。分块文件的参数设置要盯住三个点块级顶层名要与设计层次一致时间单位要与仿真精度一致活动文件里的 X 态要处理掉。X 态在功耗估计里会被当成不确定活动常见表现是某些单元 internal power 异常高或异常低。我的处理方式是先在仿真侧把 X 收敛再做活动文件导出如果收敛不了就在报告里标出受影响模块不要让 X 态悄悄进入平均值。注意活动文件不是越大越好覆盖典型场景和峰值场景比堆长时间窗口更有价值。2.3 SDC 约束与 wireload 估计的先后关系SDC 约束和 wireload 估计的先后关系是 RTL 功耗估计里最容易被低估的一环。RTL 阶段没有真实布线连线电容只能靠 wireload 模型估。约束里的时钟频率、输入驱动、输出负载会直接影响单元翻转和连线翻转的估算。我的顺序是先把时钟和端口约束固定再套 wireload最后才做功耗审计。反过来的话wireload 会掩盖约束错误报告看起来有数字但口径是散的。顺序动作参数重点失败时先看什么1读入功能 SDC时钟定义、生成时钟、输入输出延迟时钟是否被识别为同一网络2设置 wireload 模式模式、自定义 wireload 文件顶层与子块是否套用同一模型3绑定活动文件场景、窗口、层次名mapping report 匹配率4跑功耗审计黑盒、多驱动、未驱动、电源意图audit 报告里的高优先级项约束片段我一般单独放文件不直接塞进主 SDC方便回退和对比。下面这段是组织方式的示意不是完整脚本# 功能约束单独入口便于按场景切换 read_sdc ./constraints/top_function.sdc # wireload 模式与自定义模型分开管理 set_wire_load_mode enclosed source ./constraints/custom_wireload.tcl # 活动文件对应的场景标签由流程变量传入 set power_scenario typical这段代码的逻辑是把“功能约束”“连线模型”“场景标签”拆成三个可替换入口。read_sdc负责时钟和端口口径set_wire_load_mode决定连线电容估算方式source引入的自定义 wireload 文件用于覆盖默认模型。实际使用时power_scenario要和活动文件命名一致不然回归时很容易拿典型场景的约束去跑峰值场景的活动文件。参数上wireload 模式不要在不同模块之间频繁切换如果必须切换就在报告里记录每个模块使用的模型名后面做相关性对比时才有依据。电容提取和套用是另一个容易混淆的点。手册里给了从网表提取电容再应用到 RTL 的步骤我的理解是先用网表设计提取实际连线电容生成自定义 wireload再把这个模型套到 RTL 设计上。这样 RTL 阶段的连线功耗不会完全靠默认模型猜。步骤上先确认网表设计的层次和单元映射完整再提取电容最后在 RTL 流程里引用自定义 wireload。失败时先看网表与 RTL 的模块边界是否一致边界不一致提取出来的电容会挂到错误层次。提示RTL 阶段用自定义 wireload 前先确认网表提取覆盖了顶层和关键子块只覆盖子块时顶层连线功耗会被低估。2.4 校准数据Vt mix、电容提取与时钟树 scavenging校准数据决定功耗数字能不能从“趋势”走到“可对比”。手册里提到的 Vt mix 处理、电容提取、时钟树信息 scavenging、cell reallocation都是为了让 RTL 估计更接近实现。我的做法是先把校准项列成表每项都写清输入、输出和失败表现避免做到一半发现某个校准源根本没准备。校准项输入输出常见失败Vt mix 分布网表、混合 Vt 库用于 RTL 的 Vt 分配约束库单元未标 Vt分布全落到默认档网表电容提取门级网表、工艺库自定义 wireload层次边界不一致电容挂错模块时钟树 scavenging时钟树信息、约束时钟树定义约束时钟根识别错门控单元没算进去cell reallocation单元分配约束RTL 单元替换建议约束条件不满足替换被静默跳过Vt mix 的步骤我一般分两步走第一步在网表上跑 Vt 分布规则生成约束文件第二步把这个约束应用到 RTL 设计。这里的关键不是规则名而是库里的单元是否带 Vt 标注。没有标注时分布结果会骗人漏电功耗会整体偏向默认档。遇到这种情况先补库标注或换带标注的库不要硬调漏电系数。电容提取的步骤也分两步先从网表设计提取电容再生成自定义 wireload 应用到 RTL。提取前要确认网表设计的电源地连接、单元映射和层次没有被优化掉。提取后不要直接全盘套用先拿一个已知模块对比默认 wireload 和自定义 wireload 的差异差异过大时查层次和端口负载。时钟树 scavenging 更适合有时钟树信息的项目步骤是生成define_clock_tree约束再应用到 RTL 设计。时钟树信息不全时门控单元的时钟负载会被低估后面 clock gating 收益看起来会虚高。set_cell_allocation这类约束有明确前提单元分配要和库、层次、替换规则对得上。手册里也写了限制条件我的经验是不要把它当成全局优化开关。先在小模块上验证替换是否发生再看替换后的功耗和时序报告。替换被静默跳过时先查约束里的单元名、层次路径和条件表达式不要先怀疑功耗引擎。注意校准项一次只动一个动完立刻做前后对比同时改 Vt、wireload 和时钟树后面出了问题很难定位是哪一项带偏的。3. 让功耗数字能对得上审计、剖面与相关性调优3.1 Power Audit 先查设计清洁度功耗数字对不上时我第一件事不是调规则而是跑 Power Audit。审计查的是设计清洁度未驱动网络、多驱动、黑盒、未映射单元、电源意图缺失、层次展开异常。这些问题在功能仿真里可能被忽略但在功耗估计里会放大成热点或空洞。审计报告里高优先级项没清掉后面的平均值和峰值都只能当参考。审计项典型现象处理动作对功耗的影响未驱动网络某些 net 活动为 0 或 X补驱动或加约束switching power 偏低多驱动同一 net 活动异常高查总线冲突和三态internal power 虚高黑盒未建模黑盒功耗为 0补黑盒模型或标 megacell整块功耗缺失电源意图缺失关断区域仍有活动补 power intent低功耗场景失真层次展开异常子块报告缺失查 ungrouping 设置模块级对比失效审计步骤不复杂但要形成习惯先跑审计按严重级别排序只修高优先级再跑一次审计确认清零最后才开功耗估计。黑盒和 megacell 要单独建表记录模型来源、功耗表版本、适用 PVT 角。黑盒不建模时报告不会报错只会安静地少一块功耗这种“黑匣子”最危险。提示审计报告里的黑盒清单要和 megacell 报告对得上对不上时先查层次展开和模型绑定。3.2 Power Profiling 与 Average/Power Over Time 的读数差异Average Power、Power Profiling、Power Over Time、Power Regression 这几个视图回答的问题不一样。Average 适合看整体是否超标Profiling 适合看模块和单元类型的热点分布Over Time 适合看峰值和瞬态Regression 适合看版本之间是否退化。拿 Average 去判断峰值场景很容易漏掉短时大电流拿 Over Time 的单点峰值去代表整体又会把复位瞬态当成常态。视图回答的问题窗口选择常见误用Average Power整体平均是否达标稳定工作窗口把复位窗口混进平均值Power Profiling哪些模块/单元类型占大头典型场景全窗口只看顶层不看子块Power Over Time峰值出现在什么时刻峰值场景细窗口用单点峰值做整体结论Power Regression新版本是否退化与基线同窗口窗口不一致还做对比我的做法是先用 Profiling 找热点模块再用 Over Time 切到热点模块的峰值窗口最后回到 Average 确认整体。Activity Browser 里看活动分布Schematic 里看单元和终端关联两个视图交叉验证。某个单元 internal power 高不一定是单元本身问题可能是输入翻转率被高估或者输出负载约束写大了。某个模块 switching power 低也不一定是优化好可能是活动文件没覆盖到。注意做版本对比时活动文件窗口、约束版本、工艺库角三者必须一致只统一其中两个回归结论会失真。3.3 Datasheet/Dashboard 指标口径与 Activity Browser 排查Datasheet 和 Dashboard 里的指标口径要拆开看Leakage、Internal、Switching、Total 四类功耗的来源不同。Leakage 受工艺角、温度、Vt 分布影响Internal 受单元内部功耗表和输入翻转影响Switching 受负载电容和翻转率影响Total 是汇总但汇总前有没有去重、有没有包含黑盒决定了它能不能和其他报告对齐。指标主要输入调参敏感点排查入口Leakage工艺角、Vt、单元状态温度、电压、Vt 分布库标注与 PVT 角Internal内部功耗表、输入活动输入翻转、外推设置单元终端活动Switching负载电容、翻转率wireload、输出负载连线与端口约束Total上述汇总黑盒、megacell、层次报告口径与审计清单Activity Browser 适合查“活动从哪来”Schematic 适合查“活动挂到哪个单元终端”。我一般先从 Dashboard 找异常模块再跳到 Schematic 看单元终端活动最后回 Activity Browser 看信号名和层次。内部功耗表的外推控制要留意表里没有的负载或电压点工具会外推外推过头时 internal power 会偏。遇到某类单元功耗异常先查表覆盖范围再查外推设置。Megacell 要单独报告功耗。手册里对 megacell 的定义和报告方式有说明我的经验是把存储器、模拟 IP、硬核这些统一标成 megacell记录模型版本和电源模式。不标 megacell 时它们容易被当成普通黑盒低功耗模式下的关断功耗会漏算。提示Datasheet 里的 Total 和模块报告加总对不上时先查黑盒、megacell 和层次展开不要先改功耗系数。3.4 相关性工具箱综合、仿真信息、寄生与电压四类旋钮相关性调优最怕“一把梭”。手册里的相关性工具箱大致分四类旋钮综合影响、仿真信息控制、寄生模型、电压调整。四类旋钮对应不同偏差来源同时动两个以上后面只能靠猜。我的顺序是先审计设计再核对仿真信息再校准寄生最后调电压。综合影响放在仿真信息之前看因为综合后的单元映射会改变活动映射关系。旋钮适用偏差调整方式验证点综合影响RTL 与网表单元结构差异对齐综合选项和单元映射单元类型分布是否接近仿真信息活动覆盖率不足或窗口错补场景、切窗口、处理 X 态mapping report 匹配率寄生模型连线电容偏差自定义 wireload 或寄生文件关键模块连线功耗电压调整工作电压与库角不一致对齐 PVT 角电压漏电与动态功耗趋势相关性 recipe 我通常写成四步第一步审计设计并清掉高优先级问题第二步用同一活动文件跑 RTL 和网表比较模块级功耗排名第三步排名差异大的模块查单元映射和寄生模型第四步最后才看电压和温度角是否一致。物理感知流程另算它依赖物理产品的输入项目文件有两种组织方式无缝集成和两步流程。无缝集成适合物理数据已经稳定、工具间接口打通的项目两步流程适合先出物理数据再回灌功耗估计的项目。无论哪种先确认物理输入的设计版本和网表版本一致不然物理感知结果会变成另一套设计的功耗。注意相关性调优一次只动一个旋钮并在报告里记录改动前后的模块排名排名稳定比总值接近更有说服力。4. 功耗降低规则怎么落地时钟门控、存储器与跨层次机会4.1 隐式时钟使能与显式时钟使能的识别功耗降低规则里时钟门控是最容易看到收益的一类也是最容易做过头的一类。手册把机会分成隐式时钟使能、增强已有时钟使能、优化显式时钟使能。隐式时钟使能是代码里本来就有使能条件但没被综合成门控增强已有门控是把弱使能条件加强显式门控优化是检查已有门控单元是否被冗余逻辑拖累。三类机会的触发条件不同报告里的优先级也不同。机会类型识别方式收益来源主要风险隐式时钟使能找使能条件与寄存器组减少无效时钟翻转使能条件跨时钟域增强已有门控查门控使能覆盖率提高门控命中率组合逻辑延迟增加显式门控优化查冗余门控和重复逻辑减少门控自身功耗测试模式冲突我的落地步骤是先跑规则列表拿到候选寄存器组再看报告里的使能条件和层级然后做选择性优化不要全盘自动替换。选择性优化有条件手册里列了使能条件、层次边界和优化范围。条件不满足时规则会跳过不会报大错所以一定要看“已优化”和“候选”数量差。优化后打开原理图视图确认门控单元插在时钟路径上而不是插在数据路径上。提示时钟门控优化后先跑功能回归和 CDC 检查再看功耗收益顺序反了后面修功能会把收益吃掉。4.2 存储器功耗降低规则的适用边界存储器功耗降低规则不是对所有 memory 都无脑生效。手册里列了支持的存储器类型和规则列表我的经验是先确认 memory 模型是否被识别再看读写窗口和使能条件。存储器功耗占大头时先做访问次数和使能优化再做存储器类型替换。类型替换涉及库和时序不是纯功耗规则能决定的。检查项目的不满足时的表现处理memory 是否被识别确认规则能作用报告里没有 memory 条目补模型或标 megacell读写使能条件找无效访问使能常开功耗不降加使能或改访问调度时钟门控是否覆盖确认 memory 时钟可关待机功耗偏高查时钟门控边界低功耗模式定义确认关断/保持模式关断场景功耗漏算补 power intent存储器规则落地时我一般先做一次 memory 清单列出类型、端口、时钟、使能、电源模式。清单不全时规则报告会漏掉一些 memory看起来“没有优化机会”实际是没识别。存储器优化后要看 Datasheet 里的 memory 分项不要只看 Total。Total 降了但 memory 没降可能是其他模块被误优化。注意存储器替换或门控改造前先确认时序和测试模式不受影响只盯功耗收益后面很可能在测试覆盖上返工。4.3 跨层次门控机会与选择性优化跨层次门控机会是最容易被层级边界挡住的一类。子块内部有使能条件但顶层没把条件传进去或者顶层有使能子块寄存器组没被覆盖。手册里提到跨层次边界识别门控机会以及选择性优化 enabled flip-flops。我的做法是先画一张使能传播表列出顶层使能、子块使能、寄存器组和时钟域再跑规则。表里空白的路径就是后面要补的约束或代码。条件检查动作选择性优化失败表现顶层使能可传到子块查端口和层次路径只优化目标寄存器组子块仍常开子块使能独立查子块内部条件限定优化范围误改其他模块跨时钟域使能查同步器和 CDC 约束加安全门控亚稳态风险测试模式使能查扫描使能覆盖排除测试路径测试覆盖下降选择性优化的好处是可控代价是要维护优化清单。我一般把候选寄存器组按模块、时钟域、使能条件三列归档每轮只优化一列。优化后看原理图确认门控单元位置和使能逻辑没有被综合改形。跨层次优化还要注意 ungrouping 设置层次被展开后报告里的模块名会变前后对比容易错位。提示跨层次门控优化前先固定层次展开策略策略一变候选清单和报告模块名会对不上。4.4 Stability/Observability Dont Care 与 CDC 安全门控Stability Condition 和 Observability Dont Care 是更进阶的门控机会。Stability 技术看信号在特定窗口内是否稳定稳定时可以把无效翻转关掉ODC 技术看输出是否被后续逻辑观测不被观测的翻转可以优化。两类技术收益明显但前提是窗口和条件定义准确。窗口定义错了功能风险比时钟门控更大。技术适用场景收益点验证重点Stability Condition数据稳定窗口长的通路减少无效翻转窗口边界与复位Observability Dont Care输出暂未被观测的逻辑关掉不可观测翻转后续逻辑唤醒条件CDC 安全门控跨时钟域使能降低跨域时钟功耗同步器与握手协议CDC 安全门控要特别小心。跨时钟域使能直接拿去做门控可能把同步器输入关掉功能问题很难在功耗报告里看出来。手册里提到 CDC 安全时钟门控我的落地顺序是先做 CDC 检查确认使能信号经过同步再做门控候选筛选最后做门控插入和功能回归。Stability 和 ODC 的优化结果要回写到约束或代码里不能只留在工具数据库否则下一轮回归会丢。注意ODC 优化后必须验证“唤醒条件”不能只看优化窗口内的功耗窗口外一旦需要观测优化就可能变成功能 bug。5. 避坑与排查六条血泪经验5.1 仿真文件给错层级现象是功耗报告里某些模块活动为 0或者顶层功耗正常、子块功耗明显偏低。原因是活动文件的层次名和当前设计对象不一致常见于 RTL 与网表混用、模块被 ungroup 后名字变化、总线被拆分或合并。解决方式是先跑 matching report按模块看匹配率匹配率低的模块查层次路径、信号位宽和名称映射必要时用约束文件做显式映射不要依赖启发式匹配。我的习惯是每换一次设计版本就重新跑一次匹配报告不拿上一版的活动文件直接套。5.2 Vt mix 未标导致漏电偏差现象是漏电功耗整体偏低或偏高动态功耗看起来正常。原因是混合 Vt 库里的单元没有 Vt 标注分布规则把大部分单元归到默认档。解决方式是先检查库单元属性补标注或换带标注的库再在网表上跑 Vt 分布规则生成约束并应用到 RTL最后对比应用前后的漏电排名。不要用统一系数硬调漏电调完一个角其他角会对不上。5.3 黑盒和 megacell 未建模现象是某个模块功耗为 0或者 Total 和子块加总差一大块。原因是黑盒没有功耗模型megacell 没有被识别报告里安静地漏算。解决方式是建黑盒清单和 megacell 清单记录模型来源、版本、适用 PVT 角审计报告里把黑盒列为高优先级每次回归对比黑盒数量。黑盒模型变更时重新跑基线不要拿旧报告做趋势对比。5.4 多 PVT 角混用现象是同一设计两次跑出来的功耗差异很大但约束和活动文件看起来一样。原因是两次用的 PVT 角不同或者电压、温度、库角没有对齐。解决方式是建一张角表列出每次回归用的库、电压、温度、Vt 分布报告文件名里带角标签对比时先确认角一致再看数值。多角分析不要混在一个平均值里按角分别出报告。5.5 物理感知流程输入不一致现象是物理感知功耗估计结果和普通流程差异很大或者模块排名完全变了。原因是物理输入的设计版本、网表版本、约束版本不一致或者无缝集成与两步流程混用。解决方式是先固定物理输入版本再确认流程模式无缝集成查接口和版本戳两步流程查中间文件生成时间和设计版本最后用同一活动文件跑一次非物理流程做对照。物理感知不是“更准”的代名词输入不一致时它只会更偏。5.6 相关性调优同时动多个旋钮现象是调完一轮后功耗接近了但不知道是哪项改动起作用换个场景又偏了。原因是综合、仿真信息、寄生、电压四类旋钮一起动偏差来源被掩盖。解决方式是做单变量对比每轮只动一个旋钮记录模块排名和总值排名稳定后再动下一个每轮保留报告和约束快照。相关性调优的后悔药就是快照没有快照后面只能重跑。6. 用一套最小回归把手册变成团队资产验证、参数化与交付清单6.1 最小回归的四个检查点手册里的规则很多团队落地时不需要一次全上。我一般先做一套最小回归四个检查点输入清单、匹配率、审计清零、报告口径。输入清单确认库、设计、活动文件、约束、PVT 角五类齐全匹配率确认活动文件与设计层次对得上审计清零确认黑盒、未驱动、多驱动、电源意图没有高优先级问题报告口径确认 Datasheet、模块报告、megacell 报告能加总对上。四个检查点都过再谈优化收益。检查点动作通过标准失败先查输入清单核对五类输入每类有版本和责任人库角、活动窗口匹配率跑 matching report关键模块匹配率达标层次名、位宽、总线审计清零跑 Power Audit高优先级项为 0黑盒、多驱动、电源意图报告口径对比 Total 与分项差异可解释megacell、层次展开6.2 参数化封装与报告归档参数化封装不是为了炫技是为了让回归可重复。我会把场景名、活动文件、约束文件、PVT 角、wireload 模型、输出目录做成一张参数表回归脚本只读表不把路径写死。报告归档按“日期-设计版本-场景-角”四段命名旁边放一份约束快照和审计摘要。这样下次有人问“这个数怎么来的”能直接翻到对应输入不用靠记忆复现。这套手册真正的用法是把它当成规则边界和检查清单而不是从头读到尾的教程。我踩过最深的坑是早期只看功耗总值不看匹配率和审计清单结果优化做了几轮最后发现活动文件根本没覆盖关键模块。从那以后我每次开功耗回归都强制先走一遍输入清单、匹配率、审计清零、报告口径四步再谈规则和收益。希望帮到你。本文还有配套的精品资源点击获取
