简介对于Cadence IC617迁移中常见的CDB与OA格式不兼容问题这份PDF文档提供了完整的转换解决思路。资源面向使用IC617或更新版本Cadence平台的模拟版图设计工程师以及需要迁移旧工艺库的团队。文档以实际遇到的启动Virtuoso报错为例针对知名Warning错误信息系统梳理了CDB转OpenAccess的完整流程包括Virtuoso中Library Path File的设置与保存、Conversion Toolbox的调用、转换后PDK文件的更新与验证等关键环节。学习后可掌握旧工艺库在IC617上正常运行的通用操作路径减少在数据格式兼容性上耗费的排查时间。资源为1个PDF文档压缩包大小697KB阅读轻量便捷。已有1551人学习下载适合刚切换至IC617平台、需要处理存量工艺库的设计工程师收藏参考。1. 先別急著動手CDB 轉 OA 到底在解決什麼接手一個舊的模擬 IP工藝庫給的是 CDB 格式IC617 卻默認吃 OA。庫管理器裡一片紅色連 cell 都打不開數據像被鎖在老盒子裡。CDB 是老一代的電路資料庫OAOpenAccess是 IC617 這一代默認的庫格式兩者的幾何存儲、屬性掛載、索引方式完全不一樣。所謂「將數據從 CDB 轉換為 OA」就是靠 cdb2oa 這類轉換工具把版圖、原理圖、符號、CDF 參數完整地「翻譯」成 OA 格式。這條路徑解決的是老庫能不能在新工具鏈裡繼續用、能不能繼續跑 DRC/LVS 的問題適合手裡還攥著舊 PDK 和舊設計庫的維護型團隊。2. 轉換前的庫體檢先搞清楚要搬什麼2.1 CDB 與 OA 的資料模型差異為什麼不能直接把資料夾改名先看一個很常見的誤解有人以為 CDB 轉 OA 就是「把 .cdb 改名成 .oa」或者把整個庫目錄複製過去讓 IC617 自己認。實際情況是CDB 的資料模型以 cell / view / instance 的檔案索引為核心cell 下面掛 maskLayout、schematic、symbol 等視圖每個視圖的幾何數據與屬性存在特定的目錄結構裡OA 則是以 library.oa 與 cell.oa 為入口的物件資料庫幾何、屬性、text、pin 資訊各自有標準的儲存欄位還帶一整套索引與快取機制。兩者只是「看起來都是庫」底層結構完全不同改副檔名根本騙不過 OA 的讀取器。cdb2oa 做的事情不是搬檔案而是把舊庫逐個物件讀出來重新寫成 OA 的資料模型然後重建索引。幾何要轉、屬性要轉、layer 編號要對映、text 要轉、symbol 的 pin order 要重排、CDF 要從老格式搬進新格式。這中間只要有一個環節對不上就會出現「能打開但參數丟了」或「能顯示但過孔不見了」這類奇怪的狀態。所以動手之前先建立一個心態這是一次資料遷移不是一次複製貼上。遷移就必須有體檢、有備份、有驗證。你的目標不是「讓工具跑完不報錯」而是「讓轉出來的庫能支撐後續設計與物理驗證」。我一開始接這種任務時也急著敲命令後來吃過幾次虧才老老實實把下面這些檢查補上。2.2 待轉庫的檔案清單cds.lib、lib.defs、techfile、display 各管什麼體檢第一件事是進到庫目錄把家底看清楚。一個典型的 CDB 庫目錄裡大概會有這些東西我先用 ls 掃一遍cd /data/designs/old_lib_oa_work ls -la # 一個典型 CDB 庫目錄會看到 # cds.lib - 庫入口IC617 啟動與 cdb2oa 都會讀 # lib.defs - 記錄 tech library 與 reference library # techfile.tf - 工藝定義layer、via、design rule # display.drf - 顯示資源控制顏色與花紋 # cell/ - CDB 的 cell 資料夾裡面才是真正內容這幾個檔案各自管什麼直接決定了轉換會不會半路翻車。cds.lib 是入口IC617 啟動時靠它找庫cdb2oa 也一樣它必須在工作目錄下能讀到。lib.defs 負責定義技術庫與引用庫沒有它的話OA 庫生成之後 layer purpose 的對映會亂掉。techfile.tf 提供 layer、via、design rule 的定義轉換時如果讀不到之後打開版圖會常見「過孔丟失」或「層次全變成一層」。display.drf 是顯示資源它不參與資料轉換但沒接好的話打開版圖會一片空白容易誤判成數據丟了。我用一張表把它們的職責與缺失後果整理如下檔案轉換中的角色缺失的後果cds.lib讓工具找到庫、找到 reference轉換器連庫都打不開lib.defs定義 tech library 與引用順序layer purpose 對映亂techfile.tf提供 layer、via、rule 定義過孔丟失、mapping 錯display.drf顯示資源不參與轉換看起來空白資料沒丟cell/資料本體真正要轉的內容沒這個就不用轉了另外要注意如果這個庫是 PDK 帶來的pcell 的 skill 腳本通常不在庫目錄內而在 PDK 根目錄下。轉換之前得先確認這條 skill 路徑有被 .cdsinit 或啟動腳本載入。否則後面轉出來的 pcell 實例會退化成普通多邊形這是最常見的「轉完了但不能用」的原因之一。2.3 備份與環境留好後悔藥再動轉換體檢完成後下一步不是急著轉而是先複製一份副本。我一直以來的做法是源庫永遠不動轉換只在副本上做。這樣最壞的情況下你還有完整的 CDB 可以退回不用重新跟別人要資料。cd /data/designs cp -r old_lib old_lib_oa_work cd old_lib_oa_work # 轉換前先確認這個副本能被 IC617 正常讀取複製完之後先啟動 IC617 讓它讀一次這個副本確認庫本身沒壞、techfile 能載入、cell view 能開。如果源庫本身就壞了那轉換只是把壞數據搬到新格式後面再修只會更痛苦。這個「先讀一次」的動作花不了幾分鐘但能省掉一大輪排查。環境方面cdb2oa 通常跟 IC617 裝在同一個安裝樹裡一般在 tools/dfII/bin 下。如果 shell 裡直接敲 cdb2oa 提示找不到指令那就是安裝環境沒 source 好或者是 PATH 沒把這個目錄加進來。常見做法是去安裝目錄下找環境設定檔多數是 .cshrc 或 setup.shsource 完再重開一個 shell。不要試圖繞過環境直接找二進位因為它啟動時會依賴一堆週邊變數少了任何一個都可能報奇怪錯誤。3. 執行 cdb2oa 轉換命令、參數與轉換次序3.1 最小可用命令一次只轉一個庫環境就緒、副本確認可讀之後就可以跑第一個最小命令。我的習慣是在庫的工作目錄下執行也是因為 cdb2oa 會從當前目錄讀 cds.libcd /data/designs/old_lib_oa_work cdb2oa -lib old_lib -log ./cdb2oa_old_lib.log echo $?這裡的-lib指定要轉的庫名-log指定日誌路徑。執行完之後看echo $?的返回值一般來說 0 表示過程完成。不過「過程完成」不等於「資料完整」這點後面驗證章節會細說。不同小版本的 cdb2oa 參數會有一點差異。如果你不確定當前的參數格式最保險的做法是直接在 shell 裡裸跑一次cdb2oa讓它自己把 usage 打出來。以本機的輸出為準不要照背網絡上其他版本的參數我見過有人硬套舊參數導致轉到一半中斷的狀況。參數作用何時使用-lib指定要轉換的庫名每次必帶-log指定日誌檔案路徑建議必帶方便事後排查無參數顯示 usage 與版本資訊不確定選項時先跑一次另外在 virtuoso 的 CIW 或 Library Manager 裡通常也有 CDB to OA 的轉換入口菜單位置在不同小版本之間會有差異。我習慣用命令列因為它可以重複執行、可以留日誌、可以寫進批次腳本對後續維運比較友好。3.2 先轉 Reference Library再轉設計庫轉換次序比多數人想像的重要。設計庫裡的 instance本質上是對另一個庫裡某個 cell 的「引用」。如果被引用的庫還沒轉成 OA設計庫先轉過去之後那些 instance 的 master 指向會懸空打開原理圖就會出現一堆 missing master版圖裡則可能出現「框還在但內容沒了」的怪象。所以我一般會按這樣的順序跑cdb2oa -lib pdk_base_lib -log ./log_pdk_base.log cdb2oa -lib analog_ref_lib -log ./log_analog_ref.log cdb2oa -lib my_design_lib -log ./log_my_design.log先轉工藝庫pdk_base_lib再轉模擬基本庫analog_ref_lib最後轉真正的設計庫my_design_lib。一次只轉一個庫每轉完一個就去看一眼日誌確認沒有 Error 再繼續下一個。不要貪快一次把所有庫塞進同一條命令。我之前看過有人一口氣轉三個庫設計庫先轉完、引用庫還沒轉結果回頭打開原理圖滿屏 missing master最後只能砍掉重來。那個下午我記得很清楚。批次與腳本化是後期熟練之後的事第一次做就老老實實按順序來。3.3 轉換日誌怎麼讀Warning 是信號不是廢話日誌是整個轉換過程唯一的黑匣子窗口讀懂它才能少走彎路。常見的日誌內容大致可以分成幾類日誌片段含義處置方式Converting cell xxx進度資訊正常不需要處理Warning: view xxx not converted某個 view 類型轉換器不支援記下來轉完手動確認Error: cannot open library xxx庫打不開檢查 cds.lib 與路徑Warning: instance xxx references missing cell引用的 master 不存在先轉 reference 庫再重轉轉完之後我習慣用兩條 grep 快速撈問題grep -i error cdb2oa_old_lib.log grep -i warning cdb2oa_old_lib.logError 必須清零才能繼續往後走。Warning 則要看具體內容有些是「這個 view 本來就不需要轉」例如老庫裡一些 netlist 格式的視圖這類可以忽略但「references missing cell」這類必須追因為它代表引用鏈斷了。日誌留著別刪後續發現任何轉換後遺症第一件事就是回頭對時間戳找日誌紀錄。3.4 轉換後的 cds.lib 與 lib.defs 更新轉換執行完庫目錄下會生成 OA 的入口檔案最直觀的是出現 library.oa 這個目錄。但 IC617 還不知道你的新庫在哪裡它仍然照 cds.lib 的內容去尋找。這一步常常被人漏掉結果是「明明轉完了一打開還是找不到庫」。最簡單的做法是把 cds.lib 裡的 DEFINE 路徑指向轉換後的 OA 工作目錄# cds.lib DEFINE old_lib_oa ./old_lib_oa_work DEFINE pdk_base_lib ./pdk_base_lib_oa_work不要讓舊 CDB 路徑和新 OA 路徑同時出現在同一份 cds.lib 裡也不要用同名庫名覆蓋定義否則 IC617 會抓到其中的一份你根本分不清自己在看新庫還是舊庫。這個問題我遇到過不止一次最後都是靠把 cds.lib 改乾淨才解決。lib.defs 方面要確認它有沒有正確定義 tech library 的 layer purpose pair。如果發現技術庫資訊缺失常見的做法是把原工藝庫的 techfile.tf 複製到 OA 庫目錄下再讓 cds.lib 指向它cp /data/designs/original_pdk/techfile.tf ./old_lib_oa_work/techfile.tf這裡要注意一個前提先確認 techfile 的版本跟 IC617 的 OA 版本相容不然複製過去之後仍可能讀不到 layer mapping。如果原 PDK 本身有提供 OA 版本的 techfile優先使用 PDK 附的那一份。4. 轉換後的驗證哪些東西最容易轉丟4.1 版圖驗證幾何、邊界與 label轉換完成後第一步永遠是「打開一個中等複雜度的 cell不是最小的 test cell」。最小的 cell 往往只有一兩個 shape問題藏不住也看不出來中等複雜度的單元才看得出 layer、label、instance 有沒有一起過來。打開版圖後我先檢查幾件事boundary 和 prBoundary 是否還在原位這是後續 DRC 能不能跑的基礎其次看 text label 的內容是否保留字體大小變了不算大問題但內容不見了就是資料丟失最後把層次開關全部打開逐層看一下幾何有沒有明顯位移或消失。這裡有一個很容易誤判的點如果 display.drf 沒有載入整張版圖會看起來一片空白。這種情況不要直接下結論說數據丟了先確認顯示資源有沒有掛上。加載 display 之後再重開一次往往一切正常。顯示層的顏色花紋只是「看起來」的問題不是資料本體的問題。如果還是不放心幾何完整性我常用的笨辦法是導 GDS。轉換前用 CIW 的 File → Export → Stream 導一份 GDS轉換後再導一份然後用支援版圖比對的工具跑一遍 layout vs layout。這種做法不能直接證明 CDF 等屬性正確但能保證幾何層面基本一致是成本最低的幾何完整性檢驗。4.2 原理圖與 symbolCDF 參數有沒有跟著走幾何過了不代表參數過了。CDF 參數是模擬庫的命脈電阻的阻值、電晶體的 W/L、m multiplier這些東西要是轉丢了原理圖看起來一切正常一仿真就全錯。我會挑三個不同複雜度的 cell分別打開 schematic點開 instance 的屬性表單逐一比對轉換前的參數值。重點看兩類屬性一類是基本 instance property例如 name、cellName、這個通常不會丟另一類是 CDF 定義的參數例如電阻 model 與 width/length。後者一旦丟失表單會直接空白。symbol 方面最容易陰損的是 pin order。CDB 裡 pin order 存在特定屬性內OA 則有自己的一套 pin order 列表轉換工具在部分情況下不會維持原本的次序。表面上看 LVS 能過等到後面做自動布局或 schematic driven layout接線順序突然全亂了那才叫麻煩。我的習慣是轉換前先把關鍵 symbol 的 pin order 導出一份存檔轉換後再打開 symbol editor 核對一次。不要覺得這是小事pin order 錯位是所有「轉換成功但後續用不了」的案例裡最難排查的一類。4.3 跑一個最小 DRC/LVS 驗證鏈路到目前為止的驗證都還是「看得見」的層面。真正讓庫接受考驗的是拿它跑一次實打實的物理驗證。我會做一個最小驗證單元例如一個反相器用轉換後的工藝庫畫一個小版圖再畫對應的 schematic然後跑 DRC 和 LVS。DRC 的結果要特別留意錯誤類型。如果錯誤全部集中在同一層而且看起來像整片區域都被標記那大概率是 layer mapping 沒轉好不是設計真的有違反。這種情況回去檢查 techfile 和 lib.defs 的關聯。LVS 的結果則要留意 property mismatch。如果 LVS 跑出來只報「property mismatch」而且數值對不上例如 W/L 顯示成預設值那基本可以鎖定 CDF 參數在轉換過程中丟了。如果 CDF 正常、幾何正常、無 missing instanceLVS 通常能乾乾淨淨地跑完。能打開只是第一步DRC/LVS 能跑完才是這個庫「能用」的門檻。我的標準很簡單這個最小單元能完整走完設計鏈路我才會把庫交給其他人使用否則寧可回頭重轉也不要讓下游接手一個沒驗證過的庫。5. CDB 轉 OA 常見問題與避坑5 個高頻翻車現場5.1 過孔消失或變成一塊矩形現象轉換後打開版圖原本的 via 全部不見或者變成一大塊矩形DRC 一片亂。原因via 的定義存在 techfile 裡。轉換時 techfile 沒有被正確關聯進來OA 環境裡找不到對應的 via master於是原本的 via 實例就變成普通幾何形狀甚至直接丟失。解決轉換前先確認 techfile.tf 能正常載入並在 virtuso 裡手動檢查一次 via definition 是否可被讀取。如果轉完之後才發現問題先把 via 所在的 cell 單獨導出再重新導入或在新庫中重新補上 via master 定義。總之這類問題越早改成本越低。5.2 Pcell 變成普通多邊形不能參數化編輯現象轉換後 pcell 實例還能顯示但點開屬性表單發現無法修改參數一旦編輯它就退化成普通多邊形再也回不去。原因pcell 本質上是 skill 程式生成的結果cdb2oa 轉換的是幾何結果不見得保留了 pcell 與 skill 程式之間的關聯。如果後續打開時找不到對應的 pcell 定義它就會被當成普通 shape。解決轉換前確認 PDK 的 skill 腳本路徑有被 .cdsinit 載入轉換後在 CIW 裡手動 regenerate 一次 pcell。如果 PDK 廠商另外提供了專用的 OA 遷移腳本優先使用官方腳本而不是拿通用 cdb2oa 硬轉。5.3 原理圖的 pin order 悄悄變了現象LVS 能過schematic 看起來也正常但之後做自動布局時接線順序全亂原本該接在 pin 1 的訊號跑到 pin 3。原因CDB 的 pin order 存在特定屬性裡OA 則有獨立的 pin order 列表。部分轉換條件下轉換器不會維持原本的排序尤其是經過多次編輯的老 symbol。解決轉換前把關鍵 symbol 的 pin order 匯出存檔轉換後逐一打開 symbol editor 核對。發現不一致時手動調整不要試圖靠後續流程自動修正那只會讓問題更難追。5.4 CDF 參數表單是空的現象打開 instance 屬性只能看到 cellName 和 instanceName其他參數全部空白。原因CDF 資訊在 CDB 時代存在 .cdf 檔案或 cell 的 property 中。轉換工具沒有把它遷移到 OA 的 component description 時屬性表單就會是空的。解決轉完先看日誌裡有沒有 CDF 相關的 warning如果確實丟了把舊 .cdf 檔案手動搬進新庫或用 skill 重新載入 CDF 定義。這一步沒有捷徑只能老老實實對照原始資料補回來。5.5 轉完庫還是打不開報 invalid library現象轉換過程看起來完成了但 IC617 載入庫時報 invalid library 或 cannot open library。原因最常見的是 cds.lib 裡的 DEFINE 路徑還指向舊 CDB 目錄或者是 OA 目錄下根本沒有生成 library.oa。也有可能是 lib.defs 裡 techLibName 沒有定義導致 OA 讀不到技術庫資訊。解決先打開 cds.lib 確認 DEFINE 指向轉換後的工作目錄再用 ls 檢查該目錄下有沒有 library.oa 這個資料夾最後確認 lib.defs 內容缺 techfile 就複製過去並註冊。這三件事按順序查通常能涵蓋八成的 invalid library 原因。這五個翻車現場都是我碰過或看過的類型不算冷門幾乎每個庫轉換團隊遲早會遇到其中一兩個。應對原則只有一條不要迷信「轉換成功」四個字成功只代表程式跑完不代表資料完整。庫轉完之後寧可多花半天驗證也不要直接把它交給下游。6. 進階技巧把批次轉換與自動化體檢做成一條指令6.1 批次轉換與轉後檢查腳本庫多起來之後逐個手敲命令就不現實了。我後來把轉換流程收斂成一個批次腳本固定放在工作目錄下每次遷移直接跑跑完自動檢查 OA 輸出#!/bin/bash # cdb2oa_batch.sh - 批次轉換 cds.lib 裡列出的庫並檢查 OA 輸出 # 用法: ./cdb2oa_batch.sh [工作目錄] cd ${1:-.} grep ^DEFINE cds.lib | while read -r def name path; do echo 轉換庫: $name ($path) cdb2oa -lib $name -log ./cdb2oa_${name}.log \ echo 轉換完成: $name \ || echo 轉換失敗: $name done # 轉完之後檢查每個 DEFINE 路徑是否生成了 OA 入口 echo 檢查 OA 輸出 while read -r def name path; do if [ -d $path/library.oa ]; then echo OK: $name - $path/library.oa else echo MISSING: $name 沒有 library.oa請檢查日誌 fi done (grep ^DEFINE cds.lib)腳本的邏輯很直白先把 cds.lib 裡所有DEFINE行拆出庫名與路徑逐庫呼叫 cdb2oa並用和||判斷單一庫是否執行成功全部跑完之後再用-d判斷每個路徑下是否生成了library.oa目錄。要注意library.oa是目錄不是檔案所以用-d而不是-f。這個腳本只做到「檔案級體檢」它能告訴你庫有沒有轉出 OA 入口但不能告訴你幾何、CDF、pin order 是否完好。所以跑完腳本之後我仍然會手動抽查三個 cell 的版圖與原理圖。批次腳本的作用是節省重複勞動不是取代人工驗證。我現在養成的習慣是轉庫前先複製、轉庫時只轉一個、轉完立刻看日誌和打開一個 cell三件事做完才敢說「這個庫轉好了」。黑匣子不可怕可怕的是連日誌都不留。希望這篇筆記能幫你少走一次彎路。本文还有配套的精品资源点击获取