IC-CAD Methodology企業實戰之inhouse-tool開發示例

    Inhouse-tool開發是IC-CAD工做的一個重要內容之一。在大型IC公司，因爲設計工藝的先進性和設計邏輯的複雜性，IC設計流程中具備更多special的需求是通用EDA工具所不能覆蓋的，這種狀況下Inhouse-tool開發 的需求在所不免。據悉某超大型IC公司內部inhouse-tool開發部門的研發隊伍就有近百人，堪以比肩中小型的EDA公司。

    Inhouse-tool也區分難易程度，據可靠消息，某IC公司曾經組織過近十人的研發隊伍嘗試開發相似於Cadence liberate_mx相似的memory characterization工具，效果尤未可知，可是從代碼量和邏輯複雜程度而言，這種inhouse-tool徹底能夠比擬EDA工具了。本文提到的inhouse-tool主要指那些邏輯功能和圖形界面並不算過於複雜，單人能夠完成的普通inhouse-tool開發示例（主要緣由是我沒有參加過大型inhouse-tool的開發，慚愧慚愧），這樣的工具在企業內研應用中數量是最大的。

    下圖是一個普通inhouse-tool（帶圖形界面）的開發流程。

圖一 inhouse-tool 開發流程

    開發流程中須要注意的幾個關鍵點以下。

1. 獲取開發需求要不厭其煩，窮根問底，務求瞭解需求細節。

    因爲不少時候ICer自己只有一個相對模糊的需求，而且這個需求自己還多是不肯定的，變更的，若是不在一開始儘可能瞭解需求細節，以及考慮到需求的變數以儘可能作到功能兼容和擴展，開發出來之後再改動耗費的工做量極大。

    若是需求來自多個ICer，則必定要你們統一需求，最好是你們能作到一塊兒討論一次，造成文字性的共識。

    用戶需求的最終方案最好留有文字性的說明，這樣作的好處在於，若是後期用戶告訴你他的需求稍微調整了一下（變成了一個徹底不同的需求），只須要更改一下代碼就能夠了（徹底從新寫一個工具才能實現），那麼拿出他最初的需求文檔來就讓他帶着滾（滾得越遠越好）。

2. 代碼書寫要考慮到「可擴展性」，「可維護性」

    「可擴展性」是指代碼已於更改擴展。初始的需求通常來講都是很難作到絕對精確的，後續的需求改動和新需求增長也是很正常的，若是邏輯功能不考慮可擴展性，後面的任何改動都會舉步維艱。因此須要儘可能採用模塊化開發思路，邏輯功能塊要儘可能小，頂層邏輯功能要採用插拔式設計，利於增長，刪除和修改。

    「可維護性」則涉及到代碼風格，主要是爲了後續維護方便，包括但不限於如下內容。

    * 開發完成後要有基礎文檔，包括當初的需求來源，需求內容，頂層框架設計方案，模塊組成，工具使用方式，使用效果，最好配上demo。

    * 代碼中關鍵部位要有註釋說明，方便後面的人瞭解關鍵代碼。

    * 注意邏輯代碼和圖形代碼分開，相互調用邏輯清晰。

    * 注意代碼編寫風格務求清晰易讀（儘可能避免晦澀的寫法），注意縮進和變量命名規範，注意代碼複用。

3. 注意可測試性

    爲了保證開發的工具可以知足需求，最好在設計之初就考慮好測試場景和測試項目，開發過程當中完成相關功能便可展開測試，以保證每一部分代碼都乾淨可靠。

 

    上面說的很抽象，下面以一個真實的inhouse-tool開發流程來作一下說明。

 

需求

    華大九天有一款EDA工具叫qualib，可以查看liberty格式的library文件中單個cell的timing/internal_power信息，樣子以下。

圖二 qualib library cell timing信息圖形化展現

   我司ICer提出了一個需求，須要圖形化對比不一樣cell的timing/internal_power信息。咱們諮詢了華大九天的AE「qualib是否可以實現這個功能」，答「不能」。因而咱們只好本身開發。

    我同ICer反覆溝通作此，書面定製了需求以下。

    1. 查看一個cell的area, leakage_power, timing, internal_power的信息。

    2. 查看多個不一樣cell的area, leakage_power, timing, internal_power變化趨勢。

        每一個cell只有一個area值，繪製一個cell-area的二位曲線沒有問題。可是每一個cell有多個leakage_power值，有多個timing，internal_power遍，甚至每一個表都有多個值，這種狀況況則經過提供一些列約束條件（pin/related_pin/related_pg_pin ... /index_1/index2等）來限定每一個cell僅提取一個值，而後繪製二位變化曲線。

    實際上工具開發完成後，又接收到了新的需求。

    1. 當顯示單個cell的timing, inter_power的時候，能夠選擇顯示整個表格爲三維網狀圖，也能夠進選擇表格中的一行或者一列繪製一個二位曲線。

 

頂層框架設計

    有了需求，咱們開始設計工做。

    第一步，嗯，不是頂層框架設計，是起名字，我給這個工具起名字叫作cellCompare，意思是用來作cell compare的，由於最開始的需求就是多個cell數據的圖形化比較。

    下一步纔是設計頂層框架。

    工具使用的邏輯流程以下。

    讀取library file（圖形界面）  >>>  解析library file  >>>  選取cell（圖形界面）  >>>  選取約束選項（圖形界面） >>>  從library數據中抽取約束所圈定的數據  >>> 信息展現（圖形界面）

    主要代碼部分分爲邏輯和圖形兩部分。

    邏輯部分包括：

    * library parser，抽取library數據並存儲到必定的數據結構。

    * 從數據結構中抽取可用的約束條件（並以參數選項的形式展現在圖形界面中）。

    * 根據約束條件從數據結構中提取數據。

    圖形部分包括：

    * 總體圖形設計（用筆在草紙上畫就行，樣子最好讓ICer確認，否則他們嫌樣子醜也是不會用這個工具的）。

圖三 總體圖形設計

    * 圖形細節設計及實現函數選型。

        好比，cell列表採用層級複選框，超長列表則帶橫向和縱向滾動條。

        約束條件部分採用下拉菜單。

        數據展現部分採用表格。

        圖表展現部分採用二維/三維圖像直接填充。

    * 圖形和邏輯功能的映射關係。

        定義全部的映射關係，好比圖形界面中加載library file則自動執行parser進行解析，並存儲爲必定的數據結構。

        選中左側邊欄的cell後，根據數據結構讀取到相應tab全部的約束條件可選值，並自動更新圖形界面的下拉菜單選項。

        選擇下拉菜單選項後，自動更新下面數據表格和圖表部分。

 

邏輯部分

    邏輯部分分爲兩大塊，library parser和cellCompare的邏輯功能。

    library parser

    第一部分爲library parser，這個功能相對獨立，就是解析liberty格式的library file，提取相關信息並保存爲必定的數據結構。

    本着儘可能不本身造輪子，儘可能複用的 觀點，咱們首先從網上找開源的parser，還真找到了一個（咱們開發用python，github上找到了一個開源的python的liberty parser 「lib_parser」），而後套到咱們TSMC 7 nm的library file上一試，parser crash了，這就是代碼設計不健壯的一個反面典型啊。沒辦法，我只能本身造一個輪子，並且應該是個好用而且健壯的輪子。

    咱們設計的library parser ... ... 此處省略652行

    cellCompare邏輯功能

    考慮到這個inhouse-tool的總體代碼量不大（最總代碼量不到2000行），邏輯功能和圖形界面聯繫比較緊密，並無大量的獨立邏輯代碼，因此咱們直接把邏輯代碼和圖形代碼放到一個文件中，以類內函數的形式散立存在。（若是總體代碼量大，邏輯代碼相對獨立，最好是把邏輯代碼單獨拆分到獨立文件中，至少是獨立的類/函數中，更加容易維護）

    對於示例中這種邏輯代碼不獨立的狀況，開發過程當中不是獨立開發邏輯代碼，而是在書寫圖形代碼的時候，在寫到邏輯調用關係的時候再書寫邏輯代碼，這樣能夠完成一個模塊就測試一個模塊。

    對於複雜邏輯必定要提早想清楚再寫，多花點時間在思考上必定比多花時間在修改上省力氣，此處坑不少，很少說了。

 

圖形部分

    咱們採用python的pyqt庫進行圖形功能開發，簡單易用容易上手。

    圖形總體框架須要提早想好（手繪便可），而後向搭積木同樣先把總體框架搭好，而後往裏面填內容。分爲三部曲：

    1. 搭總體框架，看看樣式對不對，有沒有數據展現塊的遺漏。

    2. 填充細節，往裏面填充標籤，文本行，複選框，下拉菜單，按鈕，表格，圖表...

    3. 書寫圖形調用邏輯的調用關係。

    具體內容 ... ... 此處省略1700行

 

功能測試和用戶確認

    開發完成後首先要本身測試可否完成預約的需求。

    須要本身設計測試用例，簡單的測試而言通常須要關注如下兩類：

    1. 經常使用狀況測試。

        測試經常使用功能正常操做的狀況。

        測試經常使用的規範的輸入文件。

    2. corner case的測試

        測試不經常使用功能，遍歷全部的圖形操做組合（甚至是亂點也能夠），保證各類異常操做都能返回準確的反饋信息，不能crash。

        測試不經常使用的不規範的輸入文件。

 

    本身確認inhourse-tool基本功能無誤，可以知足最初需求後，須要書寫較爲詳細的使用發發說明，提通使用demo，請需求方ICer試用並提出反饋意見，及時更改誤解需求，及時添加新增需求（時間長了再改說不定就看不懂代碼啦）。

    通常來講開發完成後的修改是在所不免的，因此自我測試和用戶試用反饋也是一個迭代的過程。

 

效果展現

    cellCompare完成後效果以下。

    展現單個cell信息，其中三維圖形能夠拖拽和旋轉，便於查看數據單調性和變化趨勢。

圖四 單個cell timing數據三位網狀圖展現

    多個cell數據對比展現。

圖五 多個cell timing數據二位曲線展現

 

    本文僅做爲一個簡單（單人）開發流程的示例，複雜inhouse-tool（尤爲是多人協做）的實際流程則複雜的多，開源工具類的則要更加註意軟件組織架構規範和書寫格式，以便於多人協同開發便利性。