我給大家講一個有關功耗的bug。
那是我在前東家所參與的第一個重點的芯片設計專案。那個專案之初的設計目標就是低功耗，當時市面上競爭對手的最低休眠功耗在1.1V電壓下可以做到1uA，但是他們用了較為舊的工藝，所以芯片面積大。而我們選擇了更新的工藝，面積可以減小一半多，但是由於新工藝的漏電流較大，經過初期的估算，我們的目標是接近1uA。最後在前端設計完成後，用PTPX後仿真的結果就是1.5uA。老大覺得達到了預期，於是就送出去流片了。
芯片回來後bring up，在基本功能正常, 無線收發的指標都達到預期之後，組裏的老板，director，甚至部門的VP就關心一個東西：休眠狀態下的靜態功耗。當我們滿懷期待地接上電流表之後，電流表穩定在了6uA，是預期值的整整4倍，足足大了4.5uA！換了5塊板子，都是這個數，換了socket 板子，再測了三四顆芯片，都沒有比6uA低的。這可要了命了，我們的芯片主打就是面積小低功耗，現在這功耗簡直被競爭對手吊打啊，director下了死命令，必須在下一次流片之前把問題找出來，而下一次流片就是量產流片了。
組裏所有人開始行動起來開始找原因。我並不是always on模組的設計者，但是是我跑的PTPX仿真，我於是先又跑了一遍仿真，重新檢查了各種設定，沒有發現任何問題，仿真就是告訴我是1.5uA。同時跑其他非休眠狀態的仿真，仿真功耗值和實測值可以對得上，證明設定是正確的，工藝庫的值也是準確的。
接下來懷疑是板子上哪裏有漏電或者是板子設計的問題，但是經過將近一周的重新排查，PCB板設計並沒有問題，那麽就是芯片內部的問題了。
always on模組的設計者也和大家重新review了design，各種猜想被提出，但是又各種被實測否定。比如說，猜測某個isolation cell沒有插入對，於是我們和模擬團隊坐在一起，把上千個訊號又一起review了一遍，最後發現都是正確的。類似這樣的頭腦風暴幾乎每天都在進行，每次大家滿懷希望以為找到一個合理解釋，但是最終都是失望而歸。
這裏要和大家講述一下silicon debug的難度。 軟件debug通常有日誌，有偵錯程式的幫助，單步執行足以找出絕大多數bug。但是小小的芯片就難了，封裝好的芯片還沒有小拇指甲蓋大，上面的引腳比頭發絲也粗不了多少，GPIO一共也就二三十個，每個IO後面能mux出來的訊號也是有限的幾個，要是動態的訊號好歹可以利用示波器和邏輯分析儀看波形，但是這種靜態功耗的debug，示波器和邏輯分析儀也只能抓瞎。我們測算過，4.5uA說大也大，說小也很小，一個transistor短路就足以引起這麽大的short circuit current，可是小小芯片裏面幾千萬上億個transistor，找出這個無異於大海撈針。
大海撈針也得撈啊，在我們大家都想不出其他解釋之後，老大批準了給芯片照熱成像和FIB。給芯片照熱成像是啥意思，因為芯片在執行的時候是有功耗，那麽在有電流流過的地方就會有功耗，那麽相應的溫度就比周邊稍稍高一點點，這個時候用專用的熱成像儀照一個照片，只要看到哪一個地方比其他地方紅一些，那麽就大概可以定位出功耗大的區域，然後再在layout上找到那片區域對應的模組。
但是照回來的結果是，熱成像分布非常均勻，完全看不出有哪個地方過熱。想想也是，4.5uA的電流，換算成功率也就是幾uW，太難了。
然後又在幾個懷疑的點做了FIB，簡單說就是把封裝開啟，在die上面重新用儀器去把metal wire斷開，這個因為難度高，做一次就要好幾千美金，我們前後做了好幾次，每次都是沒有效果，上萬美金就這樣打了水漂。真是心疼啊，我們幾個年終獎加起來也不到這個數。
這樣大概折騰了2個月，下至工程師，上至director，我們都覺得要放棄了。只能猜測是廠家工藝的原因，隨著量產芯片tape out日期的臨近，我們只能寄希望於下一批次回來的芯片能夠功耗第一些。
直到有一天，我和另一個專案的後端工程師一起開會，review placement 和 critical timing path時，他給我們看了當前的placement， 我發現standard cell之間還有一些空位，就像下面這個圖， 所有的單元應該是按行擺放，但是中間會有空位。
於是問他們這些空位要怎麽處理，他們說要放decap cell 和filler cell. 我之前知道filler cell是用來填滿空隙的, 可以去平衡metal density，可是decap cell是個什麽東東？這玩意有功耗嗎？開完會立馬開啟lib檔一查，我擦，decap cell這玩意居然是有leakge power的！而且x2, x4, x8 (就是不同大小）的功耗也是不一樣。 我隱約覺得自己發現金礦了！
於是檢查後端給我們的netlist, 沒有filler cell, 沒有decap cell！難怪前端功耗仿真偏小，因為這些cell壓根就不存在。在後端給前端返回netlist的時候，因為decap cell和filler cell屬於沒有任何功能，沒有任何connection的cell, 他們通常的做法是在寫出netlist的時候不包括這些cell。 於是我們重新讓後端寫出帶這些cell的netlist, 再跑功耗仿真，非常準的6uA, 問題解決！
進一步分析表明，絕大多數的decap cell被放置在了always on的區域。這裏面插一句，現代SoC低功耗設計的一個常用方法是將芯片劃分成不同的power domain，有的power domain可以開可以關。在關閉的時候連power都關掉，這樣連漏電流就都沒有了，是最省功耗的做法。但是芯片睡眠後必須有一部份電路還是工作的，準備隨時喚醒整個芯片，這一部份always on的電路因為power rail不同，在版圖上通常是劃定一個特定的區域。我們的芯片由於always on邏輯很少，這片區域function cell比較稀疏，而後端在放置decap cell的時候是全域鋪放，當tool看見這部份空位比較多的時候，將大部份的decap cell都放在了always on區域裏，這樣引入了多余的4.5uA功耗。
這個bug坑的地方在於，前端拿到的netlist裏沒有decap cell，而我們前期也壓根沒有往這方面想，花了大量時間去檢檢視function上是不是有問題。
