應用背景笨方法最佳方法關于RAM單元的替換思路

應用背景

IC項目，要求工藝從90nm移植到45nm環境。但是有一些模塊，只有門級代碼描述，而非RTL代碼描述。

笨方法

針對門級代碼，替換單元名稱，替換單元的端口信號。

最佳方法

以DC綜合為例，利用綜合工具，實現門級代碼的工藝庫移植。 1. DC綜合，吃庫文件的時候，有link_library和target_library，分別對應源代碼轉換為DC綜合庫過程、以及DC綜合庫轉換為最終目標庫過程。 2. link_library吃90nm的標準單元庫； 3. target_library吃45nm的標準單元庫； 4. 由此實現應用要求。優勢是沒有人為改動，節省大量工作量。可以看做是完美移植，基本無需驗證。 5. 最終用LEC，即形式化驗證工具，比較90nm門級網表和45nm門級網表，達到完美驗證效果。這一步驟是必要的，因為即便RTL綜合，也需要做LEC，因為不能相信綜合過程沒有錯誤。 6. 如果有RAM單元，還需要RAM替換。這一步只能手動，因為RAM是不可綜合的。

關于RAM單元的替換思路

假設有100種（共計200個實例化單元）RAM單元，實際類型肯定只有1r/1r1w/1rw/2r2w等4~5種。 最普遍的做法是，100種RAM單元，建立100個module。 還有一種做法是，利用參數不同，和verilog generate用法；只需要4~5個module聲明。但是實例化部分就要修改200個實例化的名稱。

綜上所述，上述兩種做法，沒有太多區別。不過，個人仍然喜歡第二種做法，因為修改代碼量會少很多；這樣驗證關心的內容也相應減少了。

另外，做RAM替換這樣的行為，建議每一步驟，均使用shell或者perl腳本實現；這樣可以提供一種驗證軟思路，用于多次檢查代碼修改的質量。 還有一點，做這種大量替換行為，一定要做好代碼版本管理，利用svn或者git；git本地代碼版本管理，相對svn，更方便一些。