在經(jīng)歷了前面的place、cts和一些優(yōu)化以后，工具進(jìn)入到了route階段，這也是apr里邊的重要的auto-route步驟。

工具在這里很聰明，使用了化繁為簡的策咯來實現(xiàn)繞線。生活中也有一個類似的問題，大家可以思考一下，如何把一個雜亂無章的毛線球快速的理順？

通常的做法是，先解決主要問題，然后再是次要問題，最終是逐步修正細(xì)節(jié)。ICC的繞線很好的體現(xiàn)了這個化繁為簡的策咯。

由于數(shù)據(jù)庫的復(fù)雜程度不同，工具要想解決非常復(fù)雜的場景，那么就一定要將各種場景進(jìn)行歸一化，這種歸一化的過程就是簡化問題。為此，ICC工具構(gòu)建了下面的一些名詞和步驟來完成繞線：

· Glink

· gCell

· GRCs

· Overflow

· Global-route

· Track/layer

· Track-assignment

· Detail-route

· Verify route

喝口咖啡，一個個的來梳理下：

• Glink：Global link，

這是一個標(biāo)準(zhǔn)的曼哈頓距離模型：通過Glink任何連線都只有水平和豎直兩種方向，這也是給后期做routingcongestion核算的一個重要參考信息。數(shù)據(jù)庫里所有的連接關(guān)系都會以Glink的形式存在。作為真實route的起點信息。如下圖所示：

• gCell: grid Cell ,

這個是工具在數(shù)據(jù)庫里創(chuàng)建的虛擬格點cell，這是一個非常高效的處理。每一個die的形狀大小都不一樣，為了更好的進(jìn)行繞線，工具基于工藝的信息，把die分割成無數(shù)個gCell的小邊框。通常這個gCell的大小，是一個基于工藝site_row的數(shù)值的一個正方形。由于繞線都是基于繞線layer的，所以在每一個繞線層，die就被分割成了無數(shù)個小正方形，整個數(shù)據(jù)庫包含的gCell的總數(shù)量計算公式是：

gCell_rount = layer_count * die_area/ (site_row_width * site_row_width)

如圖所示

在上邊的示例圖里，如果考慮到有n層layer，那么數(shù)據(jù)庫里就會有

gCells_count=  n * 254

而后，工具在每一個gCell的邊界上核算穿過每個gCell邊界上的Glink連接的需求，從而計算真實的routingcongestion

• GRCs：Global Routing Cells

這個就是將gCells分割回每層的一個信息，由于實際的繞線是通盤考慮的，gCells會更加的真實，就是支持繞線跳層，而GRCs是基于每層的計算，這個更適用于評估當(dāng)前層次的routingcongestion。

• Overflow:

工具會對每一層的GRCs進(jìn)行評估，所有穿過這個虛擬cell邊界的需求和供給之間的差，公式如下

Overflow  = requirement – demand

工具會對可以看到，這個值可正：需求大于供給；可零：需求等于共計；可負(fù)：需求小于供給。對于后兩種，繞線資源都是足夠的，不是問題。如果為正值，這個就是真正意義上的congestion了。如下圖：overflow為3的一個示例：

這里有24個水平方向的穿線（glink）需求，但是實際上只能提供21個資源，在所有的水平繞線稍層上（m2/m4/m6/m8），所以這里的overflow就是3

由于GRCs和overflow的評估是基于單個繞線層的，就水平方向而言，如果通過打開不同的layer，在同樣數(shù)據(jù)庫里overflow的結(jié)果是會發(fā)生變化的。視圖里的overflow是所有打開版層overflow的總和，所以，開的層越多，數(shù)值大overflow的數(shù)量就越多，例如下圖，注意看一下overflow3在打開不同版層時的細(xì)微變化：

• Global-route

這個是工具在繞線初始階段，所使用的一個主命令，它的目的就是化繁為簡，在經(jīng)歷過這個命令后，數(shù)據(jù)庫里就會保存到Glink、gCell、GRCs和overflow的信息，并且在globalrouting 的結(jié)束，都會輸出如下圖的信息：

這是一個信息量很大的report，一起來梳理一下它的具體含義。

首先，工具將繞線的資源分為了兩個方向，在一些工藝?yán)镞?，允許板層的prefer-routing和none-prefer-routing并存，但是有些工藝不允許這么做，簡單起見，假設(shè)當(dāng)下的工藝是不允許none-prefer-routing的，那么，所有的繞線資源就是，這個層做對應(yīng)的繞線方向的所有track數(shù)量的總和。

這個report里邊，Both direction的數(shù)量，就是水平和豎直數(shù)量的總和，比如overflow的數(shù)值

Overflow:  4697  (Both) = 4606 (H)  + 91  (V)

Max，這個好理解，就是兩個方向里邊最大的GRCs overflow 的值。

GRCs   : 這里邊有兩個GRCs的地方。如下圖：

第一個GRCs （GRCs = 21），是指所有overflow是2（Max）的GRCs的數(shù)量。

第二個GRCs （GRCs =  5681），是指所有overflow的GRCs的數(shù)量綜合，（0< overflow <=Max）,在這個例子里，Max為2，所以細(xì)節(jié)就是，overflow 為2的GRCs是21個，overflow為1的GRCs是5660個，

在上圖的最后一列有一個百分比，0.06%，這是說，在這個方向（版層）下，所有帶來overflow的GRCs占所有當(dāng)前方向（版層）整個GRCs的百分比，所以可以反推出來，當(dāng)前方向（版層）的GRCs大概就是

9468333=5681 / 0.06%

這個數(shù)值對理解設(shè)計的數(shù)據(jù)有一定的幫助。

再看一下下圖GRCs的report圖例

對于兩個方向的GRCs總和的計算公式如下：

5822  (Both) = 5681 (H) + 141 (V)

• Track/layer

Track是一個在floorplan里邊出現(xiàn)的概念，是指當(dāng)前繞線層的繞線可以使用的“軌道”信息。layer就是常說的繞線版層。由于工藝制作的區(qū)別，在某些工藝下，在不同的layer，所有track都是一樣的，在近些年來的更為高級的工藝下，track開始在不同的layer出現(xiàn)了區(qū)別，layer越低，track之間的pitch就越小，layer越高則反之。

這個track就是前邊核算overflow的供給。

基于上述理論，在規(guī)定的長度內(nèi)（site_row），每一層的供給是可以不同的，如下如所示：在單位長度內(nèi)M2和M4的track供給數(shù)量的區(qū)別很明顯

• track assignment

有了global routing的信息，track assignment就簡單了，穿過這個GRCs的glink連接被實現(xiàn)到了每層的對應(yīng)的track上，但是，要注意一點，工具為了簡化這一步驟，只是做了簡單的track  assignment，所以，實現(xiàn)的速度很快，但是會有很多net shape都是overlap的結(jié)果，類似下圖的結(jié)果

在這個有3個overflow的區(qū)域，這里有一個占用同一個track的兩個net shape，這就是典型的short的繞線。

到這里為止，可以感覺到overflow對真實繞線的影響了吧。固然，一般的設(shè)計都不可能保證GRCs overflow是零（如果是零，理論上，在trackassignment之后，就不會有任何的short出現(xiàn)了，那樣的數(shù)據(jù)庫就真厲害了！），但是工具之所以這樣做，只是為了簡化track的步驟，后面還有大招，來修復(fù)細(xì)節(jié)問題。這就是下面要說到的。Detailroute

• Detail-route

能看到這里的同學(xué)都是好同學(xué)J

講了半天，這里的detail route其實才是大家通常最先接觸到的真實的router，在老一點的icc版本里邊，就是就route_detail，由于新的工藝的要求，icc推出了一個route_zrt_detail的命令，來滿足更復(fù)雜的工藝需求，原先的繞線就稱為了classicrouter?，F(xiàn)今，進(jìn)入了icc2的時代，這個命令，又變成了route_detail，但本質(zhì)上其實就是route_zrt_detail的演化版本。歷史捋清楚了，下面就來看一下，這個命令的厲害。

書接上文，在track assignment結(jié)束后，由于工具的策咯不同，雖然所有的netshape都被創(chuàng)建了，但是由于GRCsoverflow的影響和繞線細(xì)節(jié)等問題，會出現(xiàn)大量的DRC問題。例如下例：

可以看到，這里會有非常多的DRC和short，基于前面的理論，這個現(xiàn)象其實也沒有超出預(yù)期太多

所以，icc這個時候就會調(diào)用detail route來對這些DRC進(jìn)行精修。這個就是detailroute要干的事情。

本質(zhì)上來講，如果繞線資源不夠，short是不能被修復(fù)的，因為就單個GRC  cell而言，供給是一定的，需求也是死的，這兩個是的差異是天生的，不能被克服的。

有趣的是，工具在將一切分割后的節(jié)點（track assignment），它又可以經(jīng)寂靜分隔開的GRCs進(jìn)行二次、三次等重排。言下之意就是，在當(dāng)前GRCcell出現(xiàn)問題的地方，可以去周邊的GRC尋找出路，這其實就是典型的面積換short：迂回（detour），如下圖的short演進(jìn)過程：

這個從ICC的命令log可以清楚地看到這個動作的影響，如下例

可以明顯的看到，數(shù)據(jù)庫的總線長在不斷的增加，但是對應(yīng)的short實在不斷地減少，如下圖：

Detail  route之后再來看一下那兩根short的繞線，如下圖：

工具通過跳層。和迂回有效地解決了short。

這個GRCs的重組和的策咯看似簡單，但是非常高效，通過借道和迂回可以有效地解決short。當(dāng)然，天下沒有免費的午餐，任何的detour都會增加timing的問題，這個時候，就需要postroute的優(yōu)化，和PT的timing ECO了。但整體上來說，這個代價是值得的，通常都可以保證physical和timing同步收斂。

由于工具對GRCs的重組是有一定范圍的，加上timing driven的需求，并非所有的short都可以被解決，尤其是在某些local short 數(shù)量很多的區(qū)域，工具是無能為力的。例如，如果要在一個非常密集的區(qū)域里，需要解決很多short，就要迂回繞線非常多的net，可以想象，要完全躲開這個高密度區(qū)域，才能解決這些short，這對于timing是很不利的。簡而言之：沒有解不掉的short，只有修不干凈的timing。

除過對于short的修復(fù)，Detail route黑可以修復(fù)各種各樣類型的DRC問題。簡單的一個類型列表如下

• Verify_route

在detail route完成后，用戶就可以使用verifyroute來檢查繞線質(zhì)量了，通過觀察這個結(jié)果，來整體評估數(shù)據(jù)庫的繞線質(zhì)量，主要的關(guān)注點，還是那句老話：控制short。當(dāng)然，別的類型也有注意，尤其是數(shù)量巨大的時候，有時候，由于某些配置的不合理，會導(dǎo)致在某些層的繞線質(zhì)量顯著增加，甚至?xí)霈F(xiàn)open，這個時候就要去好好的debug了。