功能ECO與時序ECO的關系

功能ECO主要指當RTL更新后對后端APR網表做的功能方面的改動。功能ECO可以由手工或者自動化工具完成，得到ECO網表。再由后端布局布線工具（如ICC2、Innovus）讀入ECO網表，進行ECO Place和ECO Route。

時序ECO主要指為了解決后端ECO Route時的setup和hold時序違例，可以用后端工具指令、外部工具（本廠或者第三方）、人工替換Cell、優化DRC等方法完成。

從上圖可以看出，功能ECO主要是由前端工程師做，時序ECO主要是由后端工程師做。前端工程師做完一版功能ECO后，需要對ECO網表進行LEC檢查，確認ECO網表與新RTL等價，之后再把驗證無誤的ECO網表交給后端工程師。

后端工程師拿到ECO網表后，到ICC2/Innovus里做后端實現，并解決DRC、時序等問題。在PostMask ECO時，ECO網表的很小的改動都可以可能引起DRC和時序的違例，原因可能是：Cell太遠、連線太長、驅動能力不夠、繞線擁擠等。遇到時序問題，首先是利用后端工具來優化。小時序問題可以手工或者用Timing ECO工具優化過去，大時序問題就需要前端工程師進行返工。

前端工程師返工時，有哪些辦法呢？一是，挑選距離近的sparecell；二是，盡量復用現有stdcell，減少改動的連線的根數；三是，從RTL層面簡化修改方案，能不新加DFF就不加，能復用現成的信號就復用現成的信號。四是，與項目經理、產品經理、市場部一起對BUG進行排序，優先解決影響客戶使用的BUG，軟件繞不過去的BUG，放棄一些次要的BUG。

所以功能ECO常常需要迭代好幾次，才能得到一個折中的結果。當然如果必須要解決的BUG太多，或者后端無法實現，那么就只能走Full layer Tapeout，但芯片交付客戶也會多晚幾個月?，F在芯片市場競爭異常激烈，你的產品不行，別人頂上，客戶可能就沒了。

NanDigits GOF ECO的方案

我們一直在思考如何才能減少功能ECO的迭代次數，讓前端工程師在做功能ECO時就能夠提早看到時序的影響，并在功能ECO的同時就解決掉時序問題。我們嘗試、實踐、并成功開發出多個方案。

第一，是前端邏輯層面，自研了LEC（邏輯等價性）算法，利用這個算法能夠精準找到新RTL與老APR網表的差異，這會大大縮小ECO的范圍。

第二，原創了RTL Patch ECO，在APR網表里寫RTL，這種方法可以找到更精準的修改點，彌補了算法在少數案例中表現不佳的情況。

第三，自研了在APR網表中查找RTL等價net的功能。由于綜合優化、后端優化，人工在網表中查找rtl等價net是非常麻煩的事情。點一下按鈕或者一個命令，GOF ECO就會通過分析網表、兩根net做LEC等方式找到等價net。這對手工ECO網表、網表不等價debug等提供了便利。

第四，GOF ECO支持讀入DEF/LEF，從中得到每個cell的物理信息。在spare cell映射時考慮這些cell位置信息，挑選出修改點附近更合適的spare cell。當附近沒有某個cell時，會做等價變換，用附近的其它cell代替。

第五，GOF ECO實現了spare cell類型的約束，前端工程師可以根據當前spare cell的類型和數量，來指導工具實現更優化的方案。

第六，最新發布的GOF ECO實現了類似PT的report_timing的功能，這樣前端工程師在功能ECO的同時就可以評估時序，不需要等后端同事迭代，就能夠提前知道當前功能ECO結果在后端實現的難度和風險。也可以同時評估多個ECO方案，擇優提供給后端。另外，前端工程師還可以利用GOF API來提前解決一部分時序問題，不需要全部丟給后端。不但減輕了后端的壓力，還減少了ECO迭代次數，縮短了ECO時間，加速了芯片交付客戶的進度。

審核編輯：劉清