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

• 在新工艺节点跟新应用上看，架构跟算法对功耗的决定不止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 之说，滑天下之大稽！凡事要尊重常识、尊重事实、尊重数据，别信口雌黄，请爱惜自己的羽毛，别因为一时的苟且毁了半身口碑，得对得起所有牺牲掉的头发——要珍惜德行，却不要成为荣誉的奴隶，因为前者是永恒的，后者却很快会消失。