论功耗 | 测不准的功耗之反思

又要码功耗这一趴了，喜新之前先来念个旧——时到今日还经常有小朋友跟老朋友拿着一个功耗报告问这东西是怎么算的，胖友们请回顾：《四月清和雨乍晴，静态功耗乱伊心》跟 《2018 世界杯第一日，撸一遍动态功耗计算》；数字实现阶段常用的动态优化方法就那几招不新奇不明显，常用招数请回顾：《论功耗：动态功耗优化》；如有跟老驴一样无知且较真的人想知道为什么 library 中 internal power 为负值，请回顾：《论功耗：library 中的 internal power 为何为负值？》；都 2021 年了都 0.1 nm 了你还跟我提功耗 Golden 说，是无知还是梁咏琪给你的勇气，来一起回顾：《论功耗：浅谈 Power Signoff》跟《探讨 | 功耗应该在哪个 corner 看？》；比 Power Golden 说更可笑更无知的是限制了前提的 Correlation 说，请回顾：《论功耗 | 如何计算 toggle rate》跟《低功耗 | 从综合到 PostRoute 功耗的 Gap 有多大》跟《低功耗 | Glitch Power 分析》；身边总有无数多优秀的工程师，他们尊重常识跟事实，他们有技术的坚持不被噪音所左右，1/0 分明不睁眼说瞎话，不玄化自己暂时尚未掌握的知识跟无法解释的结果，无官场野心不学术造假不伪造数据不自我欺骗，他们努力钻研热衷讨论，来一起回顾：《优秀论文 | 低功耗时钟树的时钟结构分析与优化》跟《IC 圆桌派，第四日『低功耗』复盘》；再一次自我吹捧，世面上最好的 UPF2.1 中文编写教程，从入门到熟练这一篇短文足以《论功耗 | 一文搞懂 UPF2.1 编写 Power Intent》。感谢那些信任老驴胡说八道的兄弟姐妹们，但是能不能在将老驴的图文放到自己 PPT 上时鸣谢一下！

2020 年从年头到年尾都在跟功耗纠缠，疫情期间做的第一个项目是在满足 timing 的前提下控静态功耗控 ulvt 比率，在 ispatial 跟 Opt Effort Cell 两大神器的助力下轻松搞定，宾主尽欢；从四月份开始一直到年底大部分精力都在纠缠于动态功耗优化，在 20% 逼仄的空间里上窜下跳无所不用其极，趁机摆弄了动态功耗优化目前可用的『十八般兵器』，期间有暗爽、有挣扎、有顿悟、有反思、有高潮、有痛痒，在纯技术角度一切结果都尽如人意。几点反思：

• 在新工艺节点跟新应用上看，架构跟算法对功耗的决定不止 80%；有了好的架构跟算法之后还需要一双巧手，能码出漂亮的代码，不对工具做功耗优化设障；做动态功耗优化，一定要有典型场景的波形文件，但用 RTL 的波形文件去计算 PR 后网表的功耗只能作为评估值，至于跟实测功耗偏差有多大，大部分取决于设计特性小部分取决于工艺。RTL 波形中只有时序逻辑的 toggle 信息，所有组合逻辑的 toggle 默认都是工具用自己内嵌的算法估算得到的，这个估算误差很大，为了修正该误差当前主流功耗计算工具都做了 replay 功能，如 Genus + Joules Replay 可以在 syn_gen, syn_map, syn_opt 每一步优化之后做一次，以修正被优化更改了的组合逻辑上的 toggle 值。

• 但是即便有了 replay 功能，功耗估算值跟实测值还是可能会有很大偏差，这个偏差主要源自于 Glitch power, 有些设计实测功耗中 Glitch power 可占总功耗的 80% 以上，而要在网表上计算 Glitch power 必须要有后仿波形文件，但是在先进工艺 AOCV 跟 SOCV 都无法写到 SDF 中，所以即便是后仿波形也是缺失精确度的，以至于不论如何折腾 Glitch power 都只能估算。 

• 如果再进一步，IR-drop 对 timing 的影响可以用 OCV 来 cover 但是对功耗的影响如何来 cover 到目前为止都没有看到切实可行的办法。Glitch power 的优化，到目前为止业内并无切实可行可以工程化的方法，也许 Sequential clock gating 对 Glitch power 会有一些帮助，至于效果如何还是跟设计特性相关，关于 Sequential clock gating 可回顾：《combinational clock gating Vs sequential clock gating》。

PPA, Performance 跟 Area 都可以近乎精确量化，唯独 Power 总有些模棱两可，但任何已经工程化的东西都是可实测的，通过实测结果再反过来指导设计实现过程，这应该是行之有效且科学的办法，功耗它不是薛定谔的猫，别玄化。

基于常识，在功耗无法精确计算时，在 timing 满足的前提下，实现过程所使用 cell 类型的比例、clock gating 的比率、clock tree 的质量、cell 面积、transition、每层走线的长度等这些因素基本可以决定功耗的趋势，所以在 debug 功耗问题时，可以从这些可精确量化的方面入手，乱花渐欲迷人眼，事出蹊跷必有妖！请用工程师该有的素养跟技术坚持降妖除魔。

什么场景的仿真波形算典型？是 Max power 场景呢？还是 Average power 场景呢？目前 GPGPU, CPU, SOC 都有一些典型场景如：GPU: Manhattan, 3DMark, Power benchmark frame; CPU: Performance benchmark, Dhrystone, Antutu-CPU; SOC: Performance suite, Geekbench, full Antutu.  但对于 XPU 呢？实现过程用哪个场景的波形去优化更经济这需要架构算法去决策，不是拍拍脑袋就可以决定的，在做芯片时喜欢拍拍脑袋，那芯片回来后大概率该拍拍屁股滚蛋了。

RTL 功耗分析工具在整个设计过程中有多大作用？老驴觉得这需要看是谁在设计，对于高级码农，开码之前电路已经在大脑中展开变化了无数次，他清楚的知道这个东西怎么码会得到怎样的电路会对应怎样的 PPA, RTL 功耗分析工具对于他们只是用于验证其设想；对于菜鸟码农，他们以软件的思维写电路，码代码的时候脑袋里装满了语法没有一个管子，他们的码完只停留在语法编译通过，所以他们需要依赖于工具，期望工具可以给出一键提升功耗的妙招，而他们忘了一条金言玉律：Garbage In Garbage Out!

自媒体的好处就是肆意妄为，肆意妄为的开始，肆意妄为的结束，肆意妄为的胡说八道。老驴胡说你们胡看，但是老驴还是要呼吁一下，作为工程师，需要有基本常识，需要有基本素养，需要有做技术的坚持。不论是谁给你的勇气，凡事三思而后言，在功耗这一点上，千万别再提功耗 Golden 跟 correlation 之说，滑天下之大稽！凡事要尊重常识、尊重事实、尊重数据，别信口雌黄，请爱惜自己的羽毛，别因为一时的苟且毁了半身口碑，得对得起所有牺牲掉的头发——要珍惜德行，却不要成为荣誉的奴隶，因为前者是永恒的，后者却很快会消失。