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

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

產(chǎn)生Congestion的主要原因

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

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

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

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

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

以上問題會出現(xiàn)歸根結(jié)底就是設(shè)計方案和方法的問題。

幾個無效的嘗試

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

模塊劃分重構(gòu)，目的是想減少模塊之間的耦合度，重新劃分，把耦合度強的模塊放到接近，模塊的層級調(diào)整，比如三級模塊變二級模塊。但是，從后端布線上看，其實看不出模塊邊界，關(guān)聯(lián)度高的模塊甚至?xí)嘣谝黄鸬模ぞ咦詣影?a target="_blank">元器件關(guān)聯(lián)較近的方式布局布線，甚至?xí)涯阋粋€模塊分成距離很遠(yuǎn)的兩部分。這樣修改可以減少耦合度，有效果但不明顯。

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

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

總結(jié)一下，就是忙碌了半個月的硅農(nóng)師傅，白忙活了。

有效的修改優(yōu)化總結(jié)

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

乘法器復(fù)用打拍位置調(diào)整，乘法器模塊的復(fù)用把打拍放在復(fù)用模塊的輸出，而不是傳輸?shù)礁鱾€模塊中才打拍，節(jié)省寄存器開銷，負(fù)載的問題，前面也說了，工具會自動插buffer和復(fù)制寄存器。

重定時（retiming）技術(shù)，改變寄存器的打拍位置，節(jié)省寄存器。

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

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

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

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

交給后端同事吧（逃）。

審核編輯 ：李倩