ECO是所有版圖工程是都不能忽略的關鍵路徑，一個良好的ECO流程、策略可以加速流片的時間，反過來，可能讓整個團隊在一周內(nèi)沒有產(chǎn)出。為了讓小伙伴們可以從繁重的ECO流程里跳脫出來，基于筆者的設計經(jīng)驗，分三期給大家?guī)硪粋€系列的文章：版圖ECO的那點事，希望能引起大家的共鳴。

功能修改ECO的帶入方式

對于版圖工程師，經(jīng)常會碰到一些function ECO的需求，尤其是在沖擊最終Tape-Out的關鍵時期，會有如下的一種境地（以時序修復的過程舉例）
從上圖可以看到，為了保證數(shù)據(jù)庫有優(yōu)先級的收斂，最后的timing ECO會分為幾個主要步驟

• 功能模式的時序修復：function mode
• 存儲器自測模式的時序修復：mbist mode
• 其他測試模式的時序修復：test mode
• 芯片接口時序修復：IO mode

功能模式的重要性、工作量和難度都是最大的，需要盡早地修復。然后是其他的模式，基本上是按照步驟和優(yōu)先級完成整個芯片的時序修復的。

通常我們統(tǒng)一把改變功能的ECO，稱之為function ECO，但是實際上，這種ECO可能是針對真正的function mode的，也有可能是針對mbist 邏輯的，或者at-speed test mode的。
由于function ECO會引起潛在的timing arc的變化，帶入function ECO的時間點是有講究的。一般來講，只會在一種模式的timing 修復告一段落的時候，我們才會帶入這個模式的function ECO。
假如在時間節(jié)點Pre-B，前端準備好了一個比較大的function ECO，這個ECO是給mbist服務的。通常我們需要先驗證這個腳本的正確性，如果腳本本身沒問題，我們在這個Pre-B的時候并不帶入，因為這個時候整個mbist的時序還不夠穩(wěn)定。
等待到了Pre-C的節(jié)點，mbist 的時序修復基本完成的階段，這時可以相當自信的使用增量方式代入這個ECO。理論上講，新出來的timing violation都是由于這個腳本引起的。這里的timing violation通常有兩種類型

• 由于實現(xiàn)function ECO的時候，原先的cell被push，data上的timing變差：
  PS：APR工具一般不會去push clock path上的cell，clock的變差一般是應為re-route引起的。
• 新加入的cell帶來了新的timing arc：這些timing 需要重新核定和修復，由于已經(jīng)進入到ECO階段了，建議直接在PT里邊進行核查就好。APR里邊只需要關注physical就好。

【敲黑板劃重點】

增量設計工作模式，是ECO階段的重重之重，任何違背增量設計方案的舉動，都會造成局部損耗，甚至團滅

功能ECO的腳本生成的探究和技巧

后端的同學一般會在最終layout的節(jié)點，給前端同學分享最終layout版本的網(wǎng)表，一般為了閱讀方便，后端都是給前端同學一個不帶PG信息的netlist。前端同學在完善數(shù)據(jù)庫的過程中，同時也會對各種問題進行評估，最終給出解決方案：

• 軟件改動
• 約束用戶行為
• 硬件改動

如果有任何需要在硬件方面做的功能修改，前端的同學會先保證RTL修改、驗證完成后，對相應的final layout的網(wǎng)表進行修改。
綜上所述，一個function ECO的誕生無外乎下面的過程：前端主要是關注功能，后端主要是關注實現(xiàn)，對于下面的幾個主題的關注度，這里展示一下：

前端的同學基于final layout的網(wǎng)表，改出來一版帶function ECO的功能網(wǎng)表，基本就算大功告成了通常在后端工具里邊，工程師習慣使用腳本來處理一切，在ICC里邊，一定要會使用下面的這個命令，這樣才可以把前端工程師給入的netlist平滑過渡為腳本：

通常來講，直接使用這個命令會產(chǎn)生完整的ECO命令，如下例

open_mw_cel -lib $MW_LIB $MW_CEL
eco_netist -by_verilog_file $ECO_netlist -diff_only -output eco_change.tcl

這個命令，并不會改變數(shù)據(jù)庫的狀態(tài)，因為我們使用了diff_only選項。運行過程如下：

這些消息只是打印了一下設計的summary，并沒有ECO改變的細節(jié)，這里我們一起看一下ECO的腳本的小結

可以看到，這里的動作非常多，這難道是前端的期望？不要慌張，打開腳本一探究竟！一起來看一下ECO的腳本，eco_change.tcl

在整個ECO的前面大半部分，主要都是tie connection的準備，這里以高亮的pin舉例，操作如下：

1. 斷掉當前連接
2. 移除當前連接對應的net
3. 使用SNPS_LOGIC0 net連接高亮pin

這么多的tie 連接肯定是和ECO沒有關系的了，

【敲黑板劃重點】

- Tie connection derived from synthesis
如果在綜合網(wǎng)表里邊看到這個連接，那么它就是tie connection

在ICC里邊，就會相應的報告出來tie connection：

由于我們的ECO后的netlist里邊，上邊兩種情況并沒有被ICC工具定性為tie connection，所以ICC需要使用額外的操作來完成對應的tie connection （其實是重復和冗余的，大家知道為什么了吧？）

create_net -tie_low LOGIC_0
create_net -tie_high LOGIC_1
connect LOGIC_0 $CELL/TIE_LOW_PIN
connect LOGIC_1 $CELL/TIE_HIGH_PIN 

- SYNOPSYS_UNCONNECT的處理
如果在網(wǎng)表里邊存在下面的連接聲明

為了數(shù)據(jù)庫的完整性，ICC需要在所有沒有連接的pin上去接一個SYNOPSYS_UNCONNECT的net，這種操作經(jīng)常會出現(xiàn)在總線連接的情況下：一組總線，有部分的pin有連接，那么其他的pin就會連接到SYNOPSYS_UNCONNECT上了。這樣會產(chǎn)生大量榮譽的重新連接的命令
抓住細節(jié)，探尋本真， 合理使用命令和相關的變量，是高效合理完成工作的必要條件為了有效解決這兩個問題，這里隆重介紹兩位大俠，有了他們護法，上述的問題可以迎刃而解（前提是原始layout 網(wǎng)表里邊沒有l(wèi)eaf cell的floating input ）
這兩個變量在icc里邊，默認都是false，在進行eco_netlist的時候，需要把他們設置成true（如上圖）。

1. 變量一（eco_netlist_ignore_tie_changes）: 設置為true的時候，所有網(wǎng)表里邊帶來的tie connection，都被eco_netlist忽略，開一下這個選項打開時的ECO 命令的summary:
   
   和原始的ECO腳本相比，減少了很多connect_net的命令，create_net也減少了，最重要的是，create_net -tie 是沒有的
   
2. 變量二（eco_netlist_preprocess_for_verilog）：這個變量可以忽略網(wǎng)表里邊的SYNOPSYS_UNCONNECT，首先這些連接不會對數(shù)據(jù)庫產(chǎn)生任何影響，但是如果需要ICC處理的話，他的方法也很簡單，把連接SYNOPSYS_UNCONNECT的pin都會再（append）連接到一個新的net上，名字和這個pin一樣，
   PS：這個做法真的有意義嗎？需要問問ICC的開發(fā)人員了
   
   從上圖可以看到，eco應用以后，多連了一個net，其實是沒有任何用處的。
   所以，在把第二個變量改成true，ECO腳本的真實面貌就呈現(xiàn)出來了，其實這個ECO真的很簡單！
   

本講小結

1. 增量設計工作模式，是ECO階段的重重之重，任何違背增量這幾方案的舉動，都會造成局部損耗，甚至團滅
2. 抓住細節(jié)，探尋本真， 合理使用命令和相關的變量，是高效合理完成工作的必要條件

記住和貫徹這兩個工作準則，一定會讓同學們的工作成績突飛猛進、技術能力大大提升。