論功耗 | 測不準(zhǔn)的功耗之反思

又要碼功耗這一趴了，喜新之前先來念個(gè)舊——時(shí)到今日還經(jīng)常有小朋友跟老朋友拿著一個(gè)功耗報(bào)告問這東西是怎么算的，胖友們請(qǐng)回顧：《四月清和雨乍晴，靜態(tài)功耗亂伊心》跟 《2018 世界杯第一日，擼一遍動(dòng)態(tài)功耗計(jì)算》；數(shù)字實(shí)現(xiàn)階段常用的動(dòng)態(tài)優(yōu)化方法就那幾招不新奇不明顯，常用招數(shù)請(qǐng)回顧：《論功耗：動(dòng)態(tài)功耗優(yōu)化》；如有跟老驢一樣無知且較真的人想知道為什么 library 中 internal power 為負(fù)值，請(qǐng)回顧：《論功耗：library 中的 internal power 為何為負(fù)值？》；都 2021 年了都 0.1 nm 了你還跟我提功耗 Golden 說，是無知還是梁詠琪給你的勇氣，來一起回顧：《論功耗：淺談 Power Signoff》跟《探討 | 功耗應(yīng)該在哪個(gè) corner 看？》；比 Power Golden 說更可笑更無知的是限制了前提的 Correlation 說，請(qǐng)回顧：《論功耗 | 如何計(jì)算 toggle rate》跟《低功耗 | 從綜合到 PostRoute 功耗的 Gap 有多大》跟《低功耗 | Glitch Power 分析》；身邊總有無數(shù)多優(yōu)秀的工程師，他們尊重常識(shí)跟事實(shí)，他們有技術(shù)的堅(jiān)持不被噪音所左右，1/0 分明不睜眼說瞎話，不玄化自己暫時(shí)尚未掌握的知識(shí)跟無法解釋的結(jié)果，無官場野心不學(xué)術(shù)造假不偽造數(shù)據(jù)不自我欺騙，他們努力鉆研熱衷討論，來一起回顧：《優(yōu)秀論文 | 低功耗時(shí)鐘樹的時(shí)鐘結(jié)構(gòu)分析與優(yōu)化》跟《IC 圓桌派，第四日『低功耗』復(fù)盤》；再一次自我吹捧，世面上最好的 UPF2.1 中文編寫教程，從入門到熟練這一篇短文足以《論功耗 | 一文搞懂 UPF2.1 編寫 Power Intent》。感謝那些信任老驢胡說八道的兄弟姐妹們，但是能不能在將老驢的圖文放到自己 PPT 上時(shí)鳴謝一下！

2020 年從年頭到年尾都在跟功耗糾纏，疫情期間做的第一個(gè)項(xiàng)目是在滿足 timing 的前提下控靜態(tài)功耗控 ulvt 比率，在 ispatial 跟 Opt Effort Cell 兩大神器的助力下輕松搞定，賓主盡歡；從四月份開始一直到年底大部分精力都在糾纏于動(dòng)態(tài)功耗優(yōu)化，在 20% 逼仄的空間里上竄下跳無所不用其極，趁機(jī)擺弄了動(dòng)態(tài)功耗優(yōu)化目前可用的『十八般兵器』，期間有暗爽、有掙扎、有頓悟、有反思、有高潮、有痛癢，在純技術(shù)角度一切結(jié)果都盡如人意。幾點(diǎn)反思：

• 在新工藝節(jié)點(diǎn)跟新應(yīng)用上看，架構(gòu)跟算法對(duì)功耗的決定不止 80%；有了好的架構(gòu)跟算法之后還需要一雙巧手，能碼出漂亮的代碼，不對(duì)工具做功耗優(yōu)化設(shè)障；做動(dòng)態(tài)功耗優(yōu)化，一定要有典型場景的波形文件，但用 RTL 的波形文件去計(jì)算 PR 后網(wǎng)表的功耗只能作為評(píng)估值，至于跟實(shí)測功耗偏差有多大，大部分取決于設(shè)計(jì)特性小部分取決于工藝。RTL 波形中只有時(shí)序邏輯的 toggle 信息，所有組合邏輯的 toggle 默認(rèn)都是工具用自己內(nèi)嵌的算法估算得到的，這個(gè)估算誤差很大，為了修正該誤差當(dāng)前主流功耗計(jì)算工具都做了 replay 功能，如 Genus + Joules Replay 可以在 syn_gen, syn_map, syn_opt 每一步優(yōu)化之后做一次，以修正被優(yōu)化更改了的組合邏輯上的 toggle 值。

• 但是即便有了 replay 功能，功耗估算值跟實(shí)測值還是可能會(huì)有很大偏差，這個(gè)偏差主要源自于 Glitch power, 有些設(shè)計(jì)實(shí)測功耗中 Glitch power 可占總功耗的 80% 以上，而要在網(wǎng)表上計(jì)算 Glitch power 必須要有后仿波形文件，但是在先進(jìn)工藝 AOCV 跟 SOCV 都無法寫到 SDF 中，所以即便是后仿波形也是缺失精確度的，以至于不論如何折騰 Glitch power 都只能估算。 

• 如果再進(jìn)一步，IR-drop 對(duì) timing 的影響可以用 OCV 來 cover 但是對(duì)功耗的影響如何來 cover 到目前為止都沒有看到切實(shí)可行的辦法。Glitch power 的優(yōu)化，到目前為止業(yè)內(nèi)并無切實(shí)可行可以工程化的方法，也許 Sequential clock gating 對(duì) Glitch power 會(huì)有一些幫助，至于效果如何還是跟設(shè)計(jì)特性相關(guān)，關(guān)于 Sequential clock gating 可回顧：《combinational clock gating Vs sequential clock gating》。

PPA, Performance 跟 Area 都可以近乎精確量化，唯獨(dú) Power 總有些模棱兩可，但任何已經(jīng)工程化的東西都是可實(shí)測的，通過實(shí)測結(jié)果再反過來指導(dǎo)設(shè)計(jì)實(shí)現(xiàn)過程，這應(yīng)該是行之有效且科學(xué)的辦法，功耗它不是薛定諤的貓，別玄化。

基于常識(shí)，在功耗無法精確計(jì)算時(shí)，在 timing 滿足的前提下，實(shí)現(xiàn)過程所使用 cell 類型的比例、clock gating 的比率、clock tree 的質(zhì)量、cell 面積、transition、每層走線的長度等這些因素基本可以決定功耗的趨勢，所以在 debug 功耗問題時(shí)，可以從這些可精確量化的方面入手，亂花漸欲迷人眼，事出蹊蹺必有妖！請(qǐng)用工程師該有的素養(yǎng)跟技術(shù)堅(jiān)持降妖除魔。

什么場景的仿真波形算典型？是 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.  但對(duì)于 XPU 呢？實(shí)現(xiàn)過程用哪個(gè)場景的波形去優(yōu)化更經(jīng)濟(jì)這需要架構(gòu)算法去決策，不是拍拍腦袋就可以決定的，在做芯片時(shí)喜歡拍拍腦袋，那芯片回來后大概率該拍拍屁股滾蛋了。

RTL 功耗分析工具在整個(gè)設(shè)計(jì)過程中有多大作用？老驢覺得這需要看是誰在設(shè)計(jì)，對(duì)于高級(jí)碼農(nóng)，開碼之前電路已經(jīng)在大腦中展開變化了無數(shù)次，他清楚的知道這個(gè)東西怎么碼會(huì)得到怎樣的電路會(huì)對(duì)應(yīng)怎樣的 PPA, RTL 功耗分析工具對(duì)于他們只是用于驗(yàn)證其設(shè)想；對(duì)于菜鳥碼農(nóng)，他們以軟件的思維寫電路，碼代碼的時(shí)候腦袋里裝滿了語法沒有一個(gè)管子，他們的碼完只停留在語法編譯通過，所以他們需要依賴于工具，期望工具可以給出一鍵提升功耗的妙招，而他們忘了一條金言玉律：Garbage In Garbage Out!

自媒體的好處就是肆意妄為，肆意妄為的開始，肆意妄為的結(jié)束，肆意妄為的胡說八道。老驢胡說你們胡看，但是老驢還是要呼吁一下，作為工程師，需要有基本常識(shí)，需要有基本素養(yǎng)，需要有做技術(shù)的堅(jiān)持。不論是誰給你的勇氣，凡事三思而后言，在功耗這一點(diǎn)上，千萬別再提功耗 Golden 跟 correlation 之說，滑天下之大稽！凡事要尊重常識(shí)、尊重事實(shí)、尊重?cái)?shù)據(jù)，別信口雌黃，請(qǐng)愛惜自己的羽毛，別因?yàn)橐粫r(shí)的茍且毀了半身口碑，得對(duì)得起所有犧牲掉的頭發(fā)——要珍惜德行，卻不要成為榮譽(yù)的奴隸，因?yàn)榍罢呤怯篮愕模笳邊s很快會(huì)消失。