CDB转OA实战：IC617下cdb2oa工艺库迁移与避坑

简介：这份PDF面向使用Cadence Virtuoso的模拟与版图设计工程师、版图库维护人员及需要做版本迁移的IC设计者，聚焦IC617环境下旧CDB格式工艺库无法直接运行、需要转为OpenAccess（OA）数据的问题，帮助读者建立从旧库识别、格式转换到新平台复用的整体认知。压缩包内共1个PDF文件，约697KB，围绕cdb2oa转换场景整理，涉及转换工具入口、Library Path保存位置、Conversion Toolbox与CDB to OpenAccess Translator的用途说明，并对ddUpdateLibList等典型警告给出排查方向。已有1557人学习，显示该迁移主题在IC617升级中关注度较高。读者可获得一份轻量的速查参考，用于快速定位CDB与OA数据不兼容的常见表现，把握转换后库的检查、验证与复用重点，减少旧PDK在新平台迁移时的反复试错，适合需要处理历史工艺库迁移、补充版本升级排错思路的初中级设计人员查阅。

1. 一条 ddUpdateLibList 警告，把老工艺库挡在了 IC617 门外

把 IC514 时代留下来的工艺库搬到 IC617 上，virtuoso 一启动就抛出一行Warning: ddUpdateLibList: It appears that you are trying to run an OA executable on CDB data，库列表里库名还在，点开却是空的，版图打不开，schematic 也读不出来。这不是库损坏了，而是格式代际问题：IC617 只认 OpenAccess（OA）数据模型，老库还是 CDB。把数据从 CDB 转换为 OA，靠的就是随 virtuoso 一起装上的 cdb2oa，也就是 Conversion Toolbox 里的 CDB to OpenAccess Translator。这篇按我自己走通一遍的顺序来拆：目录结构怎么辨认、转换器从哪里起、参数怎么填、产物怎么核对，以及几个不看报错根本想不到的坑。手上压着老库、又必须在 IC617 上跑仿真和版图的人，可以照着走。

2. CDB 与 OA 差在哪：先把转换对象弄清楚再动手

很多人第一次遇到那个警告，第一反应是去改 cds.lib、改库路径、甚至重装 PDK，折腾半天没效果。问题不在路径，而在数据模型。cdb2oa 做的事情是把磁盘上一整套 CDB 目录结构读出来，按 OA 的接口重新写一份，中间涉及库定义、cellview 组织、techfile 关联、layer map 映射，任何一环信息缺失，转出来的库都是“能看见、不能用”。所以动手之前，先花十分钟把两边的目录结构和依赖关系看明白，比直接点转换按钮省事得多。

2.1 一个 CDB 库目录里有什么

CDB 库在磁盘上就是一个普通目录，cds.lib 里用DEFINE 库名 路径指过去。进入库根目录，通常能看到cdsinfo.tag这类标记文件，以及一个个以 cell 名命名的子目录。每个 cell 目录下再按 view 分：schematic、symbol、layout、abstract、extracted等等，view 目录里放的是data.dm、master.tag加具体数据文件。工艺相关的信息则散落在prop.xx、techfile、layer map 这些文件里。

这套结构的好处是直白，用ls就能看个大概；坏处是它是 Cadence 早期私有格式，跨版本、跨工具的兼容性全凭当年那套约定。判断一个库是不是 CDB，最省事的办法不是看后缀，而是看库根目录有没有prop.xx、cell 下面是不是data.dm这一套。确认了再谈转换，别把已经是 OA 的库又转一遍，那是另一种翻车。

2.2 OA 换的不只是后缀，是整套存储模型

OA（OpenAccess）是一套公开的数据库 API 和磁盘格式，库、cell、cellview、view 之间的关系由库定义文件统一描述，不再依赖每个 cell 目录里散落的标记文件。转换之后，库根目录下会出现 OA 自己的库定义文件和各 view 的数据文件，cellview 的继承关系、参数化单元（pcell）的绑定、techfile 的 attach 都由数据库维护。

这个差异直接决定了转换不是“改个扩展名”那么简单。CDB 里那些隐式约定——比如某个 view 默认继承哪个 techfile、某个 pcell 的 superMaster 指向谁——在 OA 里必须显式建立。转完打不开，八成是这些关联没建起来，而不是数据丢了。理解这一点，后面看日志、查报错就有方向了：先看库定义，再看 view 关联，最后才怀疑数据本体。

另一层差异是版本。IC617 配套的是 OA 那一代较新的数据模型，而老 PDK 可能是十几年前在 IC514 上做的，中间隔着好几代格式变化。cdb2oa 只能保证“按当前安装版本支持的规则”去转，遇到特别老的语法，它会跳过并写进日志，不会硬报错停下。所以日志不是可选项，是必读项。

2.3 动手前的三项确认：工具、空间、只读权限

正式转之前，我会固定做三件事：确认 cdb2oa 在 PATH 里、确认磁盘够、确认 PDK 目录可写或者已经复制出来。这三项任意一项出问题，转换都会以很难看懂的方式失败。先跑下面几条命令把底摸清。

# 1. 确认转换工具能被找到，找不到就查 virtuoso 安装目录下的 bin which cdb2oa # 2. 看版本，确认和当前 IC617 安装匹配 cdb2oa -help | head -20 # 3. 看目标盘剩余空间，转换相当于复制一份，留 2 到 3 倍余量 df -h /proj/pdk # 4. 确认老库目录当前用户是否有写权限 ls -ld /proj/pdk/lib035

which cdb2oa返回空，说明工具没进 PATH，常见做法是source一下 virtuoso 的环境脚本，或者直接用绝对路径调用。cdb2oa -help那一步不要省，不同安装版本的选项名有细微差别，照着 help 里的写法填参数最稳。df -h看的是转换输出所在分区，不是输入分区，因为 OA 库通常要写到另一个位置。最后一条ls -ld看的是权限位，如果属主是别的账号、当前用户只有读权限，转换器会在写目标库时失败，而且报错位置往往很靠后，容易误判成数据问题。

提示：PDK 目录如果是共享只读挂载，不要试图原地转换，先cp -a一份到自己的工作目录，转完再决定要不要回填。

3. 用 Conversion Toolbox 走一遍：从 cds.lib 到新库的完整操作

GUI 这条路是原文里走的流程，也是大多数人第一次转库会用的方式，因为它把选项都摆在你面前，不容易漏。整个链路是：先让 virtuoso 认识老库（cds.lib 里的 Library Path File 保存好），再起 Conversion Toolbox，选 CDB to OpenAccess Translator，指定 cds.lib，等它跑完，最后把产物回填到 PDK 目录。下面把每一步拆开，包括命令行批量转的写法。

3.1 先备份，再处理 cds.lib

备份这一步千万别省。转换器会往目标目录写新文件，如果目标路径和原库路径重叠，出问题时原库可能已经被改动。我一般打成 tar 包放在同级的 backup 目录，顺手把 cds.lib 也复制一份，因为后面要改它。

# 进入 PDK 所在目录，先整体打包备份，文件名带日期便于回滚 cd /proj/pdk tar czf lib035_cdb_backup_$(date +%Y%m%d).tar.gz lib035 cds.lib # 复制一份工作用的 cds.lib，后续所有改动只在副本上做 cp cds.lib cds_convert.lib # 看一眼当前 cds.lib 里这个库是怎么定义的，记下路径和库名 grep -n "lib035" cds.lib

tar czf那条把库目录和 cds.lib 一起打包，出问题一条tar xzf就能回到原点，这是我认为最值钱的一步。cp cds.lib cds_convert.lib的目的不是洁癖，而是让转换过程只读原始配置、只写副本，避免中途改坏全局库列表导致所有工程都打不开。grep是为了确认库名和路径的对应关系，后面在转换器里选 cds.lib 时，它会按这个文件里登记的库逐个处理，路径写错一个字符就会漏转。

3.2 启动 CDB to OpenAccess Translator

先起 virtuoso，进入 CIW 之后按原文的路径操作：Edit → Library Path File，在弹窗里确认 cds.lib 指向的是刚复制出来的cds_convert.lib，然后Save As保存到自己的 home 目录下。这一步的作用是给转换器一个明确的库列表入口，避免它去读全局默认配置。

接着在 CIW 菜单里找Tools → Conversion Toolbox，打开工具箱窗口，里面会列出若干转换器，选CDB to OpenAccess Translator。在弹出的对话框里，路径选 PDK 目录下的cds.lib（或刚保存的那份），点 OK 开始转换。转换期间 CIW 会滚动输出每个库、每个 cell 的处理信息，别急着关窗口，等它自己结束。

这里有两个容易忽略的细节。第一，转换器的输入是 cds.lib，不是库目录本身，所以 cds.lib 里必须真的登记了你要转的那个库，路径还要能被当前机器访问到。第二，转换输出默认写到哪，取决于工具配置和库定义，转完先去日志里找输出路径，不要想当然认为它原地覆盖。GUI 方式的好处是每一步都有提示，坏处是批量转多个库时点得手酸，所以库多的时候我改用命令行。

3.3 命令行批量转：一次处理多个库

命令行调用 cdb2oa 的核心是把“输入库列表、日志、输出位置”讲清楚。不同版本参数名略有差异，下面的写法以本机cdb2oa -help输出为准，先小范围试一个库，确认产物没问题再批量跑。

# 切到工作目录，保证 cds.lib 里的相对路径能解析 cd /proj/pdk # 单个库试转：指定 cds.lib、库名、日志文件 # -cdslib 指定库列表，-lib 指定只转这一个库，-log 把过程写进文件 cdb2oa -cdslib ./cds_convert.lib -lib lib035 -log ./cdb2oa_lib035.log # 确认单库没问题后，批量处理列表里的多个库 for LIB in lib035 lib018 io_cell_lib; do echo "== converting $LIB ==" cdb2oa -cdslib ./cds_convert.lib -lib "$LIB" -log "./cdb2oa_${LIB}.log" done

单库那条命令里，-cdslib指向的是副本而不是原始 cds.lib，这样转换器读到的库列表是我们筛选过的；-lib把范围锁死在一个库上，第一次跑强烈建议这么做，因为一旦某个库有异常数据，批量跑会把问题混在一起，日志都难对。-log指定日志文件后，终端输出会少很多，排查时直接grep -i "error\|warning\|skip"日志就行。

批量那个for循环是我自己的习惯写法，把库名列表写死在循环里，每个库一份独立日志，出问题能精确定位是哪个库哪一步。循环里加echo是为了在终端留一条时间线，配合日志时间戳能看出哪个库耗时异常。注意不要把这个循环直接丢到后台跑一晚上，转换过程要看日志，出了问题越早发现越好。

注意：如果 help 里没有-lib这个选项，说明当前版本只支持整份 cds.lib 一起转，那就把不想转的库先从副本里注释掉，再执行转换。

3.4 产物核对与回填 PDK

转换结束后，先别急着替换原库。到输出目录看一眼结构，确认新库里 cell 目录、view 文件、库定义文件都在，再和原库做个数量对照。

# 对比老库和新库的 cell 目录数量，粗筛有没有大面积漏转 echo "CDB cells:"; find /proj/pdk/lib035 -maxdepth 1 -mindepth 1 -type d | wc -l echo "OA cells:"; find /proj/pdk/lib035_oa -maxdepth 1 -mindepth 1 -type d | wc -l # 抽查一个关键 cell 的 view 是否齐全 ls /proj/pdk/lib035_oa/<cell_name>/ # 确认新库里没有残留的 CDB 标记文件，有就说明没转干净 find /proj/pdk/lib035_oa -name "prop.xx" -o -name "data.dm" | head

前两条find | wc -l是粗对照，数量差几个可能是空 cell 或临时目录，差几十个就要回头看日志了。ls抽查 cell 目录，重点看schematic、layout、symbol三个常用 view 在不在。最后那条find是关键：OA 库里如果还能搜到prop.xx或data.dm，说明这个目录其实是 CDB 残留，要么转换没覆盖到，要么输出路径搞错了，这种库拿回去用，virtuoso 还是会报原来那条警告。

核对没问题再回填：把原 PDK 里的老库目录改名留底，把新库复制进去，改回原来的库名，重开 virtuoso 验证。原文里的做法是删掉原来的再复制进去，我更倾向先改名而不是直接删，多留一步后悔药。

# 原库改名留底，不要直接 rm mv /proj/pdk/lib035 /proj/pdk/lib035_cdb_old # 新库复制到原位置，保持 cds.lib 里的路径不变 cp -a /proj/pdk/lib035_oa /proj/pdk/lib035

mv而不是rm，是给自己留退路；cp -a保留权限和时间戳，避免 PDK 里某些脚本按时间戳判断文件新旧。回填后 cds.lib 一行都不用改，因为库名和路径都没变，这也是为什么要先复制再改名，而不是直接在新路径上改 cds.lib。

4. 参数与目录映射：cdb2oa 的几个关键选项

参数这一块最容易被忽略，因为 GUI 把大部分选项藏起来了，默认值能跑通就没人深究。但一旦遇到“转完了但缺东西”“库名对不上”“techfile 没跟过去”，就得回到参数层面找原因。下面按我实际用到的几类整理，参数名以本机 help 为准，语义是通用的。

4.1 常用参数与默认行为

这张表里真正要强调的是-cdslib和-replace。前者决定转换器“看见哪些库”，后者决定它“敢不敢动已有目录”。-replace在有历史产物的目录上跑，会直接覆盖，如果你之前手工修过转出来的库，覆盖后就白改了。我一般的做法是不加这个参数，让它因为目标已存在而停下，然后手工确认是删是留。

4.2 库名、techfile 与 attach 关系

转换后库名默认沿用 CDB 里的库名，路径则按输出配置走。这里有个坑：cds.lib 里如果同一个库被DEFINE了两次，或者通过INCLUDE间接引了另一份列表，转换器可能按其中一条解析，转出来的库路径和你以为的不一致。处理办法是转换前把 cds.lib 里跟目标库相关的行单独拎出来看一遍，确认只有一条定义。

techfile 的 attach 是另一个重点。CDB 时代工艺信息可能挂在库级，也可能挂在 view 级，转换后 OA 要求明确 attach 到库上。转完如果发现能打开 schematic 但画不了版图、layer 列表是空的，先查 techfile 有没有 attach 上，而不是怀疑数据丢了。常见做法是在 virtuoso 里用Technology → Attach手工挂一次，或者检查库定义文件里 techfile 的指向。

# 查看新库的库定义，确认库名和 techfile 指向 grep -n "libName\|techFile\|techfile" /proj/pdk/lib035/lib.defs 2>/dev/null | head

这条命令只是快速定位，不同版本库定义文件名可能不同，搜不到就换个文件名再试。重点看库名是不是原库名、techfile 路径是不是指向 PDK 里真实存在的那个文件。路径指错的情况很常见，尤其是转换时 PDK 挂载点和转换后不一致的时候。

4.3 日志里必须盯住的三类行

日志文件很长，逐行看是浪费时间，我一般只搜三类关键词。第一类是error，这类通常是硬失败，必须处理；第二类是warning，多数可忽略，但要留意重复出现的同一条；第三类是skip或ignor，这类最危险，因为它意味着转换器悄悄跳过了某些 cell 或 view，不报错但数据缺了。

# 三类关键行分开统计，先看数量再看内容 grep -ci "error" cdb2oa_lib035.log grep -ci "warning" cdb2oa_lib035.log grep -ci "skip" cdb2oa_lib035.log # 把跳过的条目单独拉出来，人工判断影响范围 grep -i "skip" cdb2oa_lib035.log | head -20

先统计数量是为了判断严重程度：error为 0、skip也为 0，基本可以放心；skip有几十条，就得逐条看是空 cell 还是真有内容。grep | head只看前 20 条，是因为跳过原因往往高度重复，看几条就能归纳出模式。这套动作我每次转库都会跑一遍，比凭感觉判断靠谱。

5. 避坑：五条现场踩出来的经验

转换流程本身不复杂，真正耗时间的是各种“看起来成功了其实没成功”的情况。下面五条是我和自己带的人实际遇到过的，每条按现象、原因、解决写，遇到对应症状直接对号入座。

5.1 prop.xx 还在，转换器直接跳过整个库

现象：转换日志里几乎没内容，几秒钟就结束，输出目录里只有零星几个文件，virtuoso 打开新库仍然报 OA executable on CDB data。

原因：库根目录还留着prop.xx这类 CDB 标记文件，转换器据此判断“这已经是 OA 库”或者“格式不匹配”，直接跳过。原文那条警告里也明确写了，如果这是 OA 库，这个文件需要被移除。

解决：确认备份已经打好之后，把待转库里的 CDB 标记文件移走或改名，再重新执行转换。移走之前一定确认备份包能正常解开，别把唯一的副本弄丢。

5.2 PDK 目录只读，转换到一半报写入失败

现象：日志前半段正常，转到某个 cell 时突然出现一串写入失败，进程退出，输出目录里是一个不完整的库。

原因：PDK 目录挂在共享存储上，当前账号只有读权限，或者磁盘配额已满。转换器写目标库时权限不足，但它不会在开始前统一检查，而是写到哪报哪。

解决：转换前用ls -ld和df -h确认权限与空间，只读目录先cp -a到本地工作盘再转。已经产生半成品目录的，整个删掉重来，不要在残缺产物上续转。

5.3 转换中断留下半成品，重跑又报库已存在

现象：上次转换被 Ctrl+C 或断连打断，重新执行时报目标库已存在，加上覆盖参数又担心把之前手工改的东西冲掉。

原因：转换器对目标目录的存在性检查比较严格，半成品目录会被当成有效目标。

解决：先确认半成品里没有需要保留的手工修改，然后整个目录删掉重转；如果有手工修改，先备份再删。我的习惯是每次转换输出到带时间戳的新目录，成功后再决定是否覆盖正式位置，从根本上避免这个问题。

5.4 符号视图和 techfile 没跟过去，schematic 能开但画不了

现象：新库里 schematic 能正常打开，symbol 缺失或者显示异常，新建版图时 layer 列表为空，画不了线。

原因：CDB 里 symbol 和 techfile 的关联是隐式的，转换时如果源库缺少对应文件，或者 attach 关系没建立，OA 侧就是空的。日志里通常只有 warning，不会报 error。

解决：先回日志搜 symbol 和 techfile 相关 warning，确认是漏转还是关联丢失；漏转的从备份里单独补，关联丢失的在 virtuoso 里手工 attach 一次 techfile。补完之后把库关掉重开，确认状态持久化。

5.5 一个 cds.lib 里混了多个工艺库，转完互相打架

现象：同时转了好几个库，转完发现库名冲突，或者 A 库的 cell 出现在 B 库里，virtuoso 加载时报重复定义。

原因：cds.lib 里多个库指向了相同或嵌套的路径，转换器按路径展开时把内容写串了；也可能是两个库同名但路径不同。

解决：转换前把 cds.lib 里所有DEFINE行拉出来去重检查，同名库只保留一条，嵌套路径的库分开转。批量转的时候一个库一个输出目录，不要共用输出位置。

6. 转换完怎么验：两个对照检查和一个回归习惯

转换跑完、日志也看了，还不算结束。我见过太多次“日志干净、打开正常，但一跑仿真就发现某个 cell 的参数丢了”的情况。所以最后这一步验证，我固定做两个对照加一个回归。

第一个对照是数量对照，cell 数、view 数、关键文件数，老库和新库各统计一遍，差异超过个位数就回去查日志。

# cell 数量对照 find /proj/pdk/lib035_cdb_old -maxdepth 1 -mindepth 1 -type d | wc -l find /proj/pdk/lib035 -maxdepth 1 -mindepth 1 -type d | wc -l # view 数量对照，重点看 schematic / layout / symbol 三类 for V in schematic layout symbol; do echo -n "$V old: "; find /proj/pdk/lib035_cdb_old -type d -name "$V" | wc -l echo -n "$V new: "; find /proj/pdk/lib035 -type d -name "$V" | wc -l done

这三行循环是我每次必跑的，因为它能快速暴露“某一类 view 整体没转过去”的问题，比逐个 cell 点开看高效得多。数量一致不代表内容一定对，但数量差得多一定有问题，先用它筛掉大部分低级错误。

第二个对照是抽样打开。数量对上了，再从每个库挑三到五个有代表性的 cell，在 virtuoso 里打开 schematic 和 layout，看器件符号、参数、layer 是否正常。抽样要覆盖不同类型：纯器件 cell、带参数的 pcell、带层次结构的电路，各挑一个。这一步花不了几分钟，但能发现数量对照发现不了的内容缺失。

回归习惯是最后一道关。转完的库先别急着宣布可用，拿一个之前跑通过的仿真或 DRC 用例，用新库重跑一遍，对比结果。结果一致，这个库才算真正交付。我自己的教训是早年间图省事，转完看能打开就直接通知同事用，结果人家跑到一半发现某个模型的参数默认值变了，回头查是转换时某个属性没带过来，白白浪费半天。

从那以后我每次转库，都强制走一遍“备份打包、单库试转、日志三类关键词、数量对照、抽样打开、用例回归”这六步，一步不跳。库越老、年份越久，越不能凭“能打开”下结论。希望这套流程能帮你少走几个弯路，顺利把数据从 CDB 转换为 OA。

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