很多芯片项目在功能验证上走得很顺，却在功耗签核阶段被拦下来。问题很少是某一个工具算错了，往往是三类缺口同时存在：动态功耗的激励不真实、电源网络压降被低估、向量覆盖没有覆盖到真正的功耗峰值场景。签核不是跑一遍工具就签字，而是要证明最坏情况已经被看见。

动态功耗的第一道关是激励。基于向量无关的统计方法跑得快，但只能给出平均意义上的估计，翻转率来自经验假设，遇到数据通路突发、总线仲裁冲突这类场景就容易失真。带真实向量的方法更准，前提是向量本身要有代表性：只用功能测试向量签核功耗，等于只在平路上测油耗，爬坡段的峰值永远测不出来。

第二道关是 IR Drop，也就是电源网络上的压降。动态功耗算的是总能量，IR Drop 算的是局部供电能力。瞬时电流大的模块集中翻转时，局部电源电压会被拉低，时序裕量随之缩水，甚至出现功能上时序签核已通过、实测却偶发失效的情况。功耗签核与时序签核在这里是耦合的，分开看各自通过、合起来仍可能翻车。

第三道关是向量覆盖。功耗峰值场景常常不在常规测试里，例如多核同时唤醒、DMA 与处理器争用总线、电源状态快速切换的瞬间。签核流程需要显式地列出这些场景，并确认每一种场景的向量都进过功耗分析，而不是默认回归测试已经覆盖了它们。覆盖率在这里不是行数统计，而是场景清单的完整性。

工程上可行的收敛做法是分层处理：早期用向量无关方法快速定位热点模块，中期用代表性向量做模块级精细分析，后期在全芯片级用峰值场景向量做 IR Drop 与电迁移联合检查。每一步都要把假设写下来，例如翻转率来源、向量代表的工况、电源网络模型的简化程度，假设不清的签核报告等于没有签核。

归根结底，功耗签核翻车的根源大多不在工具，而在流程把平均功耗当成了最坏功耗，把功能向量当成了功耗向量。把峰值场景、局部压降和向量代表性这三件事在签核前逐一确认，项目后期被功耗拦住的概率会大幅下降，留给版图返工的时间也会宽裕得多。