623
又要碼功耗這一趴了，喜新之前先來念個舊——時到今日還經(jīng)常有小朋友跟老朋友拿著一個功耗報告問這東西是怎么算的，胖友們請回顧：《四月清和雨乍晴，靜態(tài)功耗亂伊心》跟 《2018 世界杯第一日，擼一遍動態(tài)功耗計算》；數(shù)字實現(xiàn)階段常用的動態(tài)優(yōu)化方法就那幾招不新奇不明顯，常用招數(shù)請回顧：《論功耗：動態(tài)功耗優(yōu)化》；如有跟老驢一樣無知且較真的人想知道為什么 library 中 internal power 為負(fù)值，請回顧：《論功耗：library 中的 internal power 為何為負(fù)值？》；都 2021 年了都 0.1 nm 了你還跟我提功耗 Golden 說，是無知還是梁詠琪給你的勇氣，來一起回顧：《論功耗：淺談 Power Signoff》跟《探討 | 功耗應(yīng)該在哪個 corner 看？》；比 Power Golden 說更可笑更無知的是限制了前提的 Correlation 說，請回顧：《論功耗 | 如何計算 toggle rate》跟《低功耗 | 從綜合到 PostRoute 功耗的 Gap 有多大》跟《低功耗 | Glitch Power 分析》；身邊總有無數(shù)多優(yōu)秀的工程師，他們尊重常識跟事實，他們有技術(shù)的堅持不被噪音所左右，1/0 分明不睜眼說瞎話，不玄化自己暫時尚未掌握的知識跟無法解釋的結(jié)果，無官場野心不學(xué)術(shù)造假不偽造數(shù)據(jù)不自我欺騙，他們努力鉆研熱衷討論，來一起回顧：《優(yōu)秀論文 | 低功耗時鐘樹的時鐘結(jié)構(gòu)分析與優(yōu)化》跟《IC 圓桌派，第四日『低功耗』復(fù)盤》；再一次自我吹捧，世面上最好的 UPF2.1 中文編寫教程，從入門到熟練這一篇短文足以《論功耗 | 一文搞懂 UPF2.1 編寫 Power Intent》。感謝那些信任老驢胡說八道的兄弟姐妹們，但是能不能在將老驢的圖文放到自己 PPT 上時鳴謝一下！
2020 年從年頭到年尾都在跟功耗糾纏，疫情期間做的第一個項目是在滿足 timing 的前提下控靜態(tài)功耗控 ulvt 比率，在 ispatial 跟 Opt Effort Cell 兩大神器的助力下輕松搞定，賓主盡歡；從四月份開始一直到年底大部分精力都在糾纏于動態(tài)功耗優(yōu)化，在 20% 逼仄的空間里上竄下跳無所不用其極，趁機(jī)擺弄了動態(tài)功耗優(yōu)化目前可用的『十八般兵器』，期間有暗爽、有掙扎、有頓悟、有反思、有高潮、有痛癢，在純技術(shù)角度一切結(jié)果都盡如人意。幾點反思：
- 在新工藝節(jié)點跟新應(yīng)用上看，架構(gòu)跟算法對功耗的決定不止 80%；有了好的架構(gòu)跟算法之后還需要一雙巧手，能碼出漂亮的代碼，不對工具做功耗優(yōu)化設(shè)障；做動態(tài)功耗優(yōu)化，一定要有典型場景的波形文件，但用 RTL 的波形文件去計算 PR 后網(wǎng)表的功耗只能作為評估值，至于跟實測功耗偏差有多大，大部分取決于設(shè)計特性小部分取決于工藝。RTL 波形中只有時序邏輯的 toggle 信息，所有組合邏輯的 toggle 默認(rèn)都是工具用自己內(nèi)嵌的算法估算得到的，這個估算誤差很大，為了修正該誤差當(dāng)前主流功耗計算工具都做了 replay 功能，如 Genus + Joules Replay 可以在 syn_gen, syn_map, syn_opt 每一步優(yōu)化之后做一次，以修正被優(yōu)化更改了的組合邏輯上的 toggle 值。
- 但是即便有了 replay 功能，功耗估算值跟實測值還是可能會有很大偏差，這個偏差主要源自于 Glitch power, 有些設(shè)計實測功耗中 Glitch power 可占總功耗的 80% 以上，而要在網(wǎng)表上計算 Glitch power 必須要有后仿波形文件，但是在先進(jìn)工藝 AOCV 跟 SOCV 都無法寫到 SDF 中，所以即便是后仿波形也是缺失精確度的，以至于不論如何折騰 Glitch power 都只能估算。
- 如果再進(jìn)一步，IR-drop 對 timing 的影響可以用 OCV 來 cover 但是對功耗的影響如何來 cover 到目前為止都沒有看到切實可行的辦法。Glitch power 的優(yōu)化，到目前為止業(yè)內(nèi)并無切實可行可以工程化的方法，也許 Sequential clock gating 對 Glitch power 會有一些幫助，至于效果如何還是跟設(shè)計特性相關(guān)，關(guān)于 Sequential clock gating 可回顧：《combinational clock gating Vs sequential clock gating》。
PPA, Performance 跟 Area 都可以近乎精確量化，唯獨 Power 總有些模棱兩可，但任何已經(jīng)工程化的東西都是可實測的，通過實測結(jié)果再反過來指導(dǎo)設(shè)計實現(xiàn)過程，這應(yīng)該是行之有效且科學(xué)的辦法，功耗它不是薛定諤的貓，別玄化。
基于常識，在功耗無法精確計算時，在 timing 滿足的前提下，實現(xiàn)過程所使用 cell 類型的比例、clock gating 的比率、clock tree 的質(zhì)量、cell 面積、transition、每層走線的長度等這些因素基本可以決定功耗的趨勢，所以在 debug 功耗問題時，可以從這些可精確量化的方面入手，亂花漸欲迷人眼，事出蹊蹺必有妖！請用工程師該有的素養(yǎng)跟技術(shù)堅持降妖除魔。
什么場景的仿真波形算典型？是 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 呢？實現(xiàn)過程用哪個場景的波形去優(yōu)化更經(jīng)濟(jì)這需要架構(gòu)算法去決策，不是拍拍腦袋就可以決定的，在做芯片時喜歡拍拍腦袋，那芯片回來后大概率該拍拍屁股滾蛋了。
RTL 功耗分析工具在整個設(shè)計過程中有多大作用？老驢覺得這需要看是誰在設(shè)計，對于高級碼農(nóng)，開碼之前電路已經(jīng)在大腦中展開變化了無數(shù)次，他清楚的知道這個東西怎么碼會得到怎樣的電路會對應(yīng)怎樣的 PPA, RTL 功耗分析工具對于他們只是用于驗證其設(shè)想；對于菜鳥碼農(nóng)，他們以軟件的思維寫電路，碼代碼的時候腦袋里裝滿了語法沒有一個管子，他們的碼完只停留在語法編譯通過，所以他們需要依賴于工具，期望工具可以給出一鍵提升功耗的妙招，而他們忘了一條金言玉律：Garbage In Garbage Out!
自媒體的好處就是肆意妄為，肆意妄為的開始，肆意妄為的結(jié)束，肆意妄為的胡說八道。老驢胡說你們胡看，但是老驢還是要呼吁一下，作為工程師，需要有基本常識，需要有基本素養(yǎng)，需要有做技術(shù)的堅持。不論是誰給你的勇氣，凡事三思而后言，在功耗這一點上，千萬別再提功耗 Golden 跟 correlation 之說，滑天下之大稽！凡事要尊重常識、尊重事實、尊重數(shù)據(jù)，別信口雌黃，請愛惜自己的羽毛，別因為一時的茍且毀了半身口碑，得對得起所有犧牲掉的頭發(fā)——要珍惜德行，卻不要成為榮譽(yù)的奴隸，因為前者是永恒的，后者卻很快會消失。
