CDB转OA指南：IC617老库迁移避坑与验证实战

简介：对于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 是老一代的電路資料庫，OA（OpenAccess）是 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 是顯示資源，它不參與資料轉換，但沒接好的話，打開版圖會一片空白，容易誤判成數據丟了。

我用一張表把它們的職責與缺失後果整理如下：

另外要注意，如果這個庫是 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.sh），source 完再重開一個 shell。不要試圖繞過環境直接找二進位，因為它啟動時會依賴一堆週邊變數，少了任何一個都可能報奇怪錯誤。

3. 執行 cdb2oa 轉換：命令、參數與轉換次序

3.1 最小可用命令：一次只轉一個庫

環境就緒、副本確認可讀之後，就可以跑第一個最小命令。我的習慣是在庫的工作目錄下執行，也是因為 cdb2oa 會從當前目錄讀 cds.lib：

cd /data/designs/old_lib_oa_work cdb2oa -lib old_lib -log ./cdb2oa_old_lib.log echo $?

這裡的-lib指定要轉的庫名，-log指定日誌路徑。執行完之後看echo $?的返回值，一般來說 0 表示過程完成。不過「過程完成」不等於「資料完整」，這點後面驗證章節會細說。

不同小版本的 cdb2oa 參數會有一點差異。如果你不確定當前的參數格式，最保險的做法是直接在 shell 裡裸跑一次cdb2oa，讓它自己把 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 是信號不是廢話

日誌是整個轉換過程唯一的黑匣子窗口，讀懂它才能少走彎路。常見的日誌內容大致可以分成幾類：

轉完之後，我習慣用兩條 grep 快速撈問題：

grep -i "error" cdb2oa_old_lib.log grep -i "warning" cdb2oa_old_lib.log

Error 必須清零才能繼續往後走。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 原理圖與 symbol：CDF 參數有沒有跟著走

幾何過了不代表參數過了。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 instance，LVS 通常能乾乾淨淨地跑完。

能打開只是第一步，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，三件事做完才敢說「這個庫轉好了」。黑匣子不可怕，可怕的是連日誌都不留。希望這篇筆記能幫你少走一次彎路。

本文还有配套的精品资源，点击获取