數字後端基本技能之：繞線Congestion怎麼解？
最近兩三周沒怎麼更新，先向關注本專欄的讀者致歉。原因在於最近忙於搭建後端環境，flow以及Lab，為即將到來的實踐做準備。很高興告訴大家目前後端環境基本成形，flow仍在完善中，一旦準備好我會儘快準備實踐課程，屆時將有APR至signoff的全流程實踐，敬請期待~
今天想說一說，後端遇到congestion問題的時候，一般都是通過什麼手段解決的。
在此之前先普及一下congestion的概念，以防沒有基礎的同學不清楚我們在說什麼。Congestion在後端通常指繞線阻塞，即局部或者整體繞線資源不夠的現象。產生congestion的原因有很多，可能是後端的原因，也可能是前端的原因。我們將針對不同的成因說明該如何解決。
Channel Congestion：此種現象比較常見，也比較簡單，多發生於hard macro之間。如下圖所示：
上圖中，每一個灰色多邊形代表一個macro。之所以用這種形狀是因為實際設計中的某些memory會做成這種外形。黃色部分代表macro的pin，在此每個macro都只有一個方向有pin。圖中也展示了兩種典型的macro擺放方式：普通的毗連和背靠背。無論何種擺放方式，當macro之間的空隙不足以滿足需要穿過的net所需要的資源的時候，就會發生channel congestion。因此，在floorplan階段，考慮每個channel中可能穿過的net數量，配合metal layer層數和routing rule估算繞線資源是通常需要後端設計者考慮的事。遇到channel congestion時最簡單的想法當然是增大macro距離，但這並不是總是有用，尤其是channel中有邏輯cell穿過的時候，設計者需要根據design的邏輯規劃數據走向，控制channel內的邏輯數量。
PG(Power Ground)Congestion：此種情況多由於power/ground的結構不合理或者過剩導致的。如下圖所示：
上圖紅色方框中的均為PG via，我們可以看到，金屬接觸的部分全部打滿了via。在實際設計中，電源網路的密度和via的數量其實是需要比較精確的估算的，因為過於密集的PG會佔用過多的繞線資源，從而降低整體的繞通性。常用的手段是，如果在晶元局部出現繞線緊張的現象，會通過刪除部分pg via/shape來釋放一部分繞線資源。當然，這樣做的前提是電源網路足夠穩固(robust)，IR-drop和power EM不會發生很大惡化。
High Cell Density Congestion：此種congestion主要是由於局部或整體的cell過於密集導致的。下圖展示了一種比較極端的情況：
上圖中左圖為cell density map，右圖為routing congestion map。density map顏色越深意味著density越高，同理congestion map顏色越深意味著繞線資源越緊張。可以看出density越高的地方基本上congestion也越嚴重。在實際設計中，局部出現這種congestion的情況比較常見，我們可以通過很多手段來控制局部的density：placement blockage（soft hard partial), keepout margin(cell spacing constraint), cut row等。與此同時，工具也會提供一些功能來控制局部density，比如icc2的place.coarse.max_density。
High Pin Density Congestion：此種congestion多發生於多pin cell集中的區域。下圖展示了兩種常見的多pin cell：AOI(and/or/inverter)和多位選擇器(selector)。
在某些design中，如果不加控制，邏輯綜合的結果可能是幾百上千個此類cell聚集在一起從而造成某個區域的net十分密集。在place階段，儘管工具會嘗試把這些cell盡量推開，但是由於邏輯本身的限制優化空間有限。因此需要綜合階段配合，選擇合適的cell來綜合網表。例如可以禁用此類cell，使綜合工具將其邏輯進行拆分。但是這樣做的後果是可能導致design的邏輯數量增加，面積增大，功耗上升。因此需要對各方面的影響進行評估。
Logic Congestion：此類congestion可以說是最棘手的問題之一。因為在後端結果看來，可能這類congestion的區域中cell density很低，也沒有或者很少有多pin cell，周圍也沒有marco阻擋，但是congestion卻一塌糊塗。原因可能在於前端工程師為了節省面積而將某一個模塊復用多次，連接了過多的input或者output；也可能是design中存在大量的同級選擇邏輯(如幾百位的選擇器)。原因不一而足，需要後端工程師去深入分析design才能得出結論。這類問題需要向前端工程師反饋，與他們溝通能否修改RTL，而且常常以犧牲面積或者性能為代價。
以上就是後端常見的幾種congestion問題，實際設計中可能每個人針對每種問題都有自己的解決方法，但是問題的根本原因不會改變。大家在項目中還需要多一些深入分析和摸索，尋找問題背後的原因並形成解決方案。除了在prects和preroute階段盡量解決congestion，在routing之後可能仍然會出現剩餘大量short/drc的情況，但對此類問題的解決方法又是另外一個話題了，以後有機會會開篇詳談。
喜歡的話不要忘了點贊~
如果大家有任何後端技術與職業發展方面的問題，抑或關於數字後端感興趣的技術話題想要了解和探討，歡迎關注我的知乎專欄： 【數字IC後端設計工程師修鍊之路】
同時歡迎關注微信公眾號：數字後端芯講堂，一起探討技術，共同提升!
專欄其他文章：
閻浮提：獻給晶元設計新手：後端設計的基本流程是什麼？
閻浮提：數字後端基礎之：晶元的整體功耗是如何計算出來的？
閻浮提：後端Timing基本技能之：Hold Violation怎麼修？
閻浮提：後端Timing基礎概念之：為何ICG容易出現setup violation？
閻浮提：後端Timing基本技能之：Setup Violation怎麼修？閻浮提：後端Timing基礎概念之：為什麼時序電路要滿足setup和hold？
閻浮提：科普貼：工藝升級中後端的挑戰是什麼？
推薦閱讀：
※面試又被BS？數字後端面試要注意這些坑！
※如何看待微電子信息社會的基石 ？
※科普貼：工藝升級中後端的挑戰是什麼？
※今年不分紅，格力要留錢做晶元！靠譜嗎？| 半導體行業觀察