For many engineers, using various tools become everyday job, sometimes we even

miss in those tools. In the article, the author went through one experience of solving

routing congestion in the design to l a story: a good engineer should go beyond the tools.

    對許多工程師而言，各種電子輔助設計的工具占據了日常工作的各個環節，甚至迷失于電子設計就是使用各式各樣工具。本文針對我們在工作中遇到的繞線擁擠問題，主要內容是一套總線四選一的布局與布線，這個布線始終存在繞線擁擠，在工具無法完成，甚至工具優化也難實現的情況下，zui后采用人工干預解決了繞線擁擠的問題。

    從大學畢業被電子公司聘用、工作三四年、做了四五個項目、用過五六個工具、熟悉其中一兩個，工程師似乎就這樣修煉成了。但是入門之后如何再精進，是許多工程師在職業生涯中遇到的難題。本文作者介紹了過去作為EDA工程師在設計一款路由交換芯片時遇到的具體問題，自己如何努力地思考和尋找解決方案，以及在解決問題后的一些工作感想。

    從技術目標的層次講，在芯片面積之外，時序收斂、繞線擁擠、低功耗設計算是戰略層面的技術問題；芯片的面積、時序、繞線、功耗的問題很可能決定了該芯片是否具備成本可行性、是否能達到技術目標、是否能實現技術項目、是否具有技術優勢的戰略層次抉擇。相對來說，在設計過程中遇到的信號完整性、天線效應、電壓降（IR-drop）等技術問題則是局域性、戰術層面的問題，較少會影響到整個芯片的規劃以及性能的實現。

問題的出現

    2003年我們進行一款路由交換芯片項目開發時，對于其后段設計，首先初步確定了設計工藝將為0.18um 1P6M（0.18微米、一層硅六層金屬純數字代工工藝），并立刻從前端工程師得到一個框架的初步的RTL代碼，馬上做了一個初步的低層規劃（floorplan）后，三周后定位了該項目的難度。該項目在RTL綜合后，芯片預估面積已在可接受范圍內，芯片由于電源供電從而低功耗要求不嚴，zui高頻率133MHz基本能達到，*的瓶頸是其中一個模塊網絡處理器（NP）表現有繞線擁擠問題。

    這個網絡處理器模塊大約有47萬門、50個硬核模塊、2,027個輸入輸出，圖1a是NP模塊在zui初的布局后對繞線擁擠的預估圖像。

圖1：（a）繞線擁擠的預估圖像; （b）NP模塊對繞線擁擠的預估圖像。

    具體的擁擠報告如表1所示（擁擠度指需要的繞線通道數與能提供的通道數之差值，正值表示不擁擠、負值表示擁擠）。

表1：問題解決之前的擁擠報告。

尋找解決方案

    因為zui初的規劃中，對所有的模塊都采用了80%的利用率目標，從而在遇到模塊級繞線擁擠問題后，選擇一位工程師把這個模塊作為專項來處理。首先提出了兩個方案：1. 將該模塊利用率從80%下降到70%，并優化該模塊IO布置；2. 在原來自動布局的基礎上，采用擁擠驅動布局、物理綜合以及人工干預來改善擁擠度。

    方案一已經影響到芯片總的規劃與布局，我們在對周圍模塊進行調整后，在面積上接受了該模塊利用率從80%下降到70%，而在IO布置上只接受了部分IO布置的優化。對第二方案則不斷地嘗試各種自動布局中能夠找到的參數以及手工干預，確實實現了一定程度的擁擠優化。一個月后，我們的NP模塊對繞線擁擠的預估圖像如圖1b所示。

    從得到的擁擠報告可以看出繞線擁擠改善了很多，但是擁擠現象在該模塊仍然存在，離目標還有一段的距離。項目進行到這個時候，前端的RTL代碼已經快結束了，也就是說這個NP模塊必須盡快定型，否則在該模塊上的每一天耽擱就是整個項目往延后一天。
  
    于是我們又提出了下面三個方案：1. 在項目規劃上做zui壞的打算，確定該模塊利用率必須降到多少以下才能夠解決繞線擁擠問題；2. 把繞線擁擠問題在流程中再提前，不僅僅從后端的布局布線手段來優化擁擠，提出了能否有以繞線為優先的RTL綜合方式；3. 同時要求前端設計人員寫出該模塊中的子模塊功能、數據與控制的走線等，從而希望定位模塊中問題具體點，尋找非常規解決方案。

    這三個項目執行下來，時間又進行了三個禮拜，同時項目正式在時間上已經進入設計后端是關鍵路徑了，而NP繞線擁擠則是后端項目中的關鍵路徑。時間過得越來越多，項目進度的壓力非常大，NP的繞線擁擠現在已經升級為項目成敗中關鍵路徑的關鍵點了。新三個方案的結果有憂有喜：

1. 對方案一的執行結果是，該模塊利用率即使在40%以下依然無法解決繞線擁擠問題，從而否定了通過加大模塊面積的解決方案。同時，我們在再次調整了周圍模塊的面積后，定下了NP模塊利用率zui低可以放寬到65%。

2. 對方案二的執行結果中發現目前綜合工具對解決繞線擁擠問題比較無力，我們采用了加高走線面積的預估值權重的辦法，希望綜合工具在做面積優化時，能夠選擇繞線優先的算法，這個辦法被證明依然失敗。

3. 只有方案三的執行結果帶來了一些曙光，我們在NP的幾十個子模塊中確定了其中一個子模塊繞線特別多，經仔細檢查，這個子模塊的邏輯基本上是一個1200組的四選一功能。

    第三個方案的結論解釋了為什么面積增大了而工具依然不能解決繞線擁擠的原因：NP整個模塊中只有一個子模塊特別的繞線擁擠，雖然增大面積會增加整個NP的繞線，但是對于特別擁擠的一小塊地方并不是特別大的幫助。

問題定位

    發現了問題的關鍵所在，就能制定針對這個問題的解決方法了。我們把問題局限在這主要是一個綜合工具的問題，雖然標準庫文件中有著標準的四選一子單元，但是綜合時綜合工具會把一組四選一的邏輯綜合成組合邏輯。比如對于0.18um的標準庫，下面一段簡單mux的代碼會綜合成為INV、NAND2、NOR2和AOI22四種邏輯的組合。

Module mux4to1_1200 （s,data0,data1,data2,data3,data）;

input [1:0] s;

input [1199:0] data0,data1,data2,data3;

output [1199:0] data;

reg [1199:0] data;

always@（s or data0 or data1 or data2 or data3） begin

case（s）

2'b00 begin

data=data0;

end

2'b01 begin

data=data1;

end

2'b10 begin

data=data2;

end

2'b11 begin

data=data3;

end

endcase

end

endmodule

    這段代碼如果采用直接調用mux4單元，只有6,000條繞線，而這種組合邏輯將會有9,000余條繞線。這種組合邏輯不僅帶來更多的三千多條繞線，而且在其解選擇信號s時，與調用單元的連接是隨意的，從而造成不僅線多而且繞線非常復雜。目前綜合工具基本上都沒有前瞻性的對繞線優先的綜合手段，從而在這種特殊情形下，出現了幾乎不可能只依靠工具解決的技術問題。我們一旦明確了這點，在綜合前先將這個子模塊初始化成為mx4的直接調用，馬上讓整個NP繞線的zui擁擠點消失。

本文小結

    從現在的繞線擁擠預估圖像可以看出，繞線擁擠問題已經基本解決。具體的擁擠報告如表2所示。

表2：繞線擁擠問題改善后的擁擠報告。

    回顧這個項目，zui終的完成時間還是比預期晚了一個月左右。造成這個進度延緩有多個原因：團隊人員*次做項目，需要磨合；團隊人員較少，精力分散；之前經驗偏重于時序收斂而非繞線擁擠等。但是因為人員緊缺而被迫寄希望于軟件工具來解決問題這個思維本身，可以說是項目延緩的zui根本原因。在我們之后的項目中，一發現問題立即追查問題的根源，讓自己負起責任，而不期待工具會自動解決問題，從而我們之后的芯片項目在完成質量與完成時間上都有了較大的提高。