Congestion意思為擁塞，一般是在后端PR階段發現布局布線比較擁擠，可能會導致布線布不過去，出問題也無法做ECO。

Congestion也分為幾種情況，和前端密切相關的是Logic Congestion（更多關于后端Congetsion問題，查看文末參考文章），主要原因是RTL設計問題導致，這種問題的現象從后端看上去就是Cell數沒多少，就是線密。

產生Congestion的主要原因

有限的面積下，電路面積過大。從一開始預估的面積與最后實際的面積有一定差距，導致該模塊面積被限定的情況下，邏輯較多，繞線嚴重。

大位寬信號做選擇邏輯。假如有一個信號定義為3萬bit，然后它還需要送到幾個模塊去做選擇器，從里面挑數，這樣就是3萬根線，連來連去，這樣的設計必然有問題。這樣驚人的設計最后怎么能用呢。只能說，工藝牛逼！

選擇器太大。選擇器的選擇項多，設計復雜的情況下，難免會有選擇器的選擇項有大幾十上百個的情況。

信號負載大。一個參數信號可能用到了很多地方，驅動數個像上面那樣的大mux，這樣的信號的負載會非常大。

組合邏輯路徑長。組合邏輯路徑長，時序比較緊的地方，工具會做一些優化增加繞線，這樣的結果會加重后端擁塞。

以上問題會出現歸根結底就是設計方案和方法的問題。

幾個無效的嘗試

怎么解決，假設一個前提，時間緊迫，如果對時序邏輯進行大的改動，需要調試的時間較長，嚴重時造成項目delay。所以只能在不改變時序的情況下，只對組合邏輯進行優化。

模塊劃分重構，目的是想減少模塊之間的耦合度，重新劃分，把耦合度強的模塊放到接近，模塊的層級調整，比如三級模塊變二級模塊。但是，從后端布線上看，其實看不出模塊邊界，關聯度高的模塊甚至會揉在一起的，工具自動按元器件關聯較近的方式布局布線，甚至會把你一個模塊分成距離很遠的兩部分。這樣修改可以減少耦合度，有效果但不明顯。

大mux拆分成小mux。將單一的大mux拆分成多級小選擇器，每一級之間用寄存器打斷。但是，如果不用寄存器打斷拆分，可能沒啥用，因為工具也是這么做的。歸納可能會省去很多多余的分支。但在不改變時序的情況下做拆分基本無收益，因為只是在RTL級別上看的大mux寫法的不同，實際上還是由眾多小mux組成的。

降低信號的負載，參數寄存器復制多份，送給不同的模塊。數據通路的寄存器也可以進行復制，減少信號的負載。但是綜合加max_fanout約束后，工具會自動插buffer和復制寄存器的操作，而且因為面積本身有限，時序的優化帶來的收益還會被寄存器的增加所抵消。

總結一下，就是忙碌了半個月的硅農師傅，白忙活了。

有效的修改優化總結

運算邏輯復用，節省面積給邏輯走線。先選后比/加/乘/模塊。

乘法器復用打拍位置調整，乘法器模塊的復用把打拍放在復用模塊的輸出，而不是傳輸到各個模塊中才打拍，節省寄存器開銷，負載的問題，前面也說了，工具會自動插buffer和復制寄存器。

重定時（retiming）技術，改變寄存器的打拍位置，節省寄存器。

打斷較復雜的組合邏輯，中間插入寄存器，時序變好，即使寄存器增多，面積（可能）反而會變小。

大于1k的寄存器組考慮用RAM替代，但用RAM讀取數據需要進行時序控制邏輯，并行度會降低。要求并行度高，可使用多個RAM。面積和速度永遠是兩個背道相馳的努力目標。所以要Trade Off（折中）

后端喜歡，深度深，位寬小的RAM，這樣最后的bit/面積的值會更大。舉例說明就是Depth128xWidth16和，Depth16xWidth128相比最后的面積大小，前者會比后者小很多。簡單來說，后端喜歡細長的，不喜歡粗短的。

RAM也可以復用，前面計算用完空閑下來的RAM，可以復用起來。

交給后端同事吧（逃）。

審核編輯 ：李倩