简介面向 Cadence IC617 平台的 CDB 转 OA 数据迁移指南专门解决旧版工艺库无法在 Virtuoso 中直接打开的兼容性问题。这份 PDF 以图文结合形式清晰讲解了使用 cdb2oa 工具将 CDB 格式数据转换为 OpenAccess 格式的完整流程包括命令行转换命令的用法、输出文件的保存位置以及如何在 Virtuoso 中设置 Library Path、加载转换后的库并将新生成的库复制回原 PDK 目录后正常使用。同时指南还针对这类迁移过程中常见的提示信息——尝试在 CDB 数据上运行 OA 可执行文件时出现的 WarningddUpdateLibList说明了产生原因与处理办法并强调转换完成后务必在 Virtuoso 中核查库文件的完整性和正确性避免数据丢失或调用异常。资源共一个 PDF 文件压缩包大小约 697KB内容精炼便于查阅。目前已有 1549 人学习下载适合版图设计工程师、PDK 维护人员和 Cadence 环境搭建者参考可帮助读者快速掌握迁移要点、少走弯路。1. IC617 从 CDB 到 OA一次绕不开的数据库迁移手头有个老项目工艺库还是 IC5141 时代的 CDB 格式换到 IC617 上打开 Virtuoso 一看库是空的或者直接弹出一句 database format not supported。这时候你就碰到了这个标题说的事IC617 默认读写 OpenAccessOA数据库老 CDB 格式必须经过转换才能被新版工具链识别、编辑和跑验证。别把这个 OA 理解成办公自动化这里说的是 EDA 行业的 OpenAccess 标准。转换动作本身不复杂麻烦的是转换后的完整性和参数保留。本文按实战路径理一遍为什么要转、怎么转、转完查什么、哪些坑是常态。2. 为什么 CDB 在 IC617 里“不受待见”两种库格式的本质差异与转换路径2.1 CDB 和 OA 到底差在哪CDB 全程是 Cadence Database是 Cadence 4.x 到 5.x 时代的私有数据库格式。它的物理结构是一堆二进制文件外加文本映射典型路径是 lib/cell/view 三级目录view 里再拆成多种文件碎片。这个结构在当年挺好用但问题是它绑死了 Cadence 自家工具第三方工具想读你的库得先通过 Cadence 的导出接口绕一圈。OA 全称 OpenAccess是 Si2 联盟推动的业界标准数据库。Cadence 从 IC615 开始主推到 IC617 已经是默认格式。OA 把 cellview 的存储粒度改得更细每个 view 是一个独立的 OA object带完整的属性映射和版本管理信息。更重要的是OA 是多家 EDA 厂商共同承认的中间格式Synopsys、Mentor 的工具也能直接读 OA 库。所以从 CDB 转 OA本质不是“拷贝文件换个后缀”而是一次数据库重建。原来 CDB 里靠文件路径和命名规则表达的关系到了 OA 里要重新注册成库内对象原来存在 CDF 文件里的器件参数要重新挂到 OA 的 property 上。这个重建过程由 Cadence 的 Convert CDBA to OA 工具完成但工具只保证“转得过去”不保证“转得完整”这就是后面所有坑的根源。2.2 转换路径有三条GUI、命令行、SKILL 批处理常见做法是先看库的数量。只有一个两个库用 GUI 菜单最快在 Virtuoso 里点 Tools—Conversion—Convert CDBA to OA按提示选源库、填目标库名就行。库一多GUI 就变得难以忍受每个库都要手工点一遍而且中间弹出来的 warning 对话框会打断节奏点得人暴躁。命令行方式是 convertCDBA在 IC617 安装目录的 tools/dfII/bin 下。这个命令支持指定源库路径、目标库名、覆盖策略和日志文件适合写进 shell 脚本里循环跑。SKILL 批处理则更进一步可以写一段 SKILL 脚本在 cdsinit 加载后逐个库调用转换函数还能在转换完成后自动做一轮检查。三种方式底层调的是同一套转换引擎区别只是控制粒度。提示转换前先确认 IC617 的安装包里带了 CDBA 转换工具。一些精简版安装或只装 OA 流程的许可可能不包含这个模块启动转换菜单时直接是灰的。2.3 转换前必须搞清楚的三个前置概念第一要分清库的类型。device library、reference library、design library转换行为不一样。工艺厂提供的 device library 通常是只读的转换时如果目标 OA 库名已存在要特别注意覆盖策略。design library 是你自己画版图原理图的库里面可能有大量中间状态的 cell转换前最好自己先清理一遍别把垃圾 cell 也带过去。第二要理解 view 的粒度。CDB 里一个 cell 的 schematic、layout、symbol 是三个 view转换工具会逐个 view 处理。如果某个 view 在 CDB 里已经损坏转换过程会跳过它而且 log 里可能只是黄色 warning不会报 error。等你打开 OA 库才发现这个 cell 少了 layout view那时候再回去找 CDB 原件就费劲了。第三要认清 CDF 参数的归属。CDB 时代的器件参数存在 CDF 文件里通常是 lib 目录下的 cdf 文件或者用户目录下的 .cadence 配置里。转换工具对 CDF 参数的处理并不总是完美常见情况是转完的 OA 库能打开、能连线但器件的 w、l、m 这些参数全是默认值。这个在参数验证章节细说。3. 实战转换流程从单库转换到批量脚本参数与命令逐条讲3.1 转换前的三个前置检查少一个都可能白跑先检查环境变量。IC617 的环境脚本一般是 source /opt/cadence/IC617/tools/dfII/cdsinit但不同公司安装路径不同以你机器上实际路径为准。关键是确认 PATH 里包含 tools/dfII/bin否则 convertCDBA 命令找不到。还要确认 license 里包含 CDBA 相关的 feature老一点的 license 文件可能没买这个模块命令一跑就报 license checkout failed。再检查源库。进入 CDB 库目录确认里面有 lib.defs 文件。这个文件是 CDB 库的路由表描述了库里每个 cell 的 view 类型和文件位置。lib.defs 丢了或内容损坏转换工具连库结构都读不出来。另外建议在 CDB 环境下把源库完整打开一遍跑一次 dbCheck 或者简单打开几个有代表性的 cell确认没有隐藏的损坏 view。最后做备份。虽然转换工具默认不修改源 CDB 库但有同行遇到过转换过程中把源库的 cds.lib 改掉的情况可能是 GUI 模式下它顺手改了环境配置。保险做法是转换前把整个 CDB 库目录 cp -r 一份到别的路径成本就是一点磁盘空间换来的是后悔药。注意转换动作本身不修改源库但如果你在同一个工程目录下同时建 OA 库又恰好让两个库共用同一个 cds.lib那 CDB 和 OA 混挂在同一个 Library Manager 下部分老工具打开时可能会串库。建议把源 CDB 库和转换出的 OA 库放在不同工程目录。3.2 GUI 单库转换选项怎么勾GUI 路径是 Virtuoso 菜单 Tools—Conversion—Convert CDBA to OA。打开的对话框里有几个关键选项逐个说要勾什么Source Library选 CDB 库路径注意选到 lib 一级不是 cell 一级。Destination Library填目标 OA 库名建议名字带 _oa 后缀方便和旧库区分。Overwrite existing library目标 OA 库已存在时勾选这个才会覆盖。默认不勾遇到同名库会直接报错退出。Preserve Cell/View properties勾选尽量保留属性。不勾的话转换速度会快一点但很多自定义 property 就丢了。Generate CDF info强烈建议勾选让工具尝试把 CDF 参数一并转过去。GUI 最烦人的是转换过程中弹出的 warning 框。我的习惯是不勾那个“Stop on warning”的选项让转换一口气跑完最后看 log 汇总。遇到 warning 就停下等人点确认几百个 cell 的库能把人耗死。GUI 模式下 log 会输出到 CIW 窗口建议提前把 CIW 的 log 重定向到文件方便后续 grep。3.3 命令行转换最小可用命令与参数说明命令行方式适合写脚本也适合在服务器上用 nohup 后台跑。先看单库转换的最小命令# 设置IC617环境路径以实际安装为准 source /opt/cadence/IC617/tools/dfII/cdsinit export PATH$PATH:/opt/cadence/IC617/tools/dfII/bin # 单库转换把CDB库转成OA库 convertCDBA \ -lib /data/project/analog_cdb \ -oaLib /data/project/analog_oa \ -overwrite true \ -log ./convert_analog.log这段命令里-lib 指定源 CDB 库路径-oaLib 指定目标 OA 库路径。注意 -oaLib 传的是路径不是库名工具会按这个路径创建新库目录。如果不传 -oaLib工具会在当前目录下生成一个新库名字取源库名加 _oa 后缀。-overwrite true 允许覆盖目标库第一次转换用 false 更安全避免误操作把以前转好的库冲掉。-log 指定日志文件路径这个一定要传否则转换信息只打到终端后台跑的时候什么都不留。实际转换一个中等规模的 design library大概几百个 cell包含 schematic、layout、symbol 三种 view 的完整库耗时通常在几分钟到十几分钟之间取决于磁盘 IO 和库的复杂程度。如果超过一个小时没跑完大概率是卡在某个 cell 上这时候看日志最后一行停在哪个 cell 名后面避坑章节详细讲。3.4 批量转换脚本几十个库一次跑完做项目移植时经常遇到整个工艺包下挂十几个库的情况这时候用 shell 循环把 convertCDBA 包起来#!/bin/bash # 批量转换把 projects 目录下所有 *_cdb 目录转成 *_oa 目录 for lib in /data/project/*_cdb; do # 去掉路径前缀取库名 libName$(basename $lib) # 把 cdb 后缀替换成 oa生成目标库路径 oaLib/data/project/${libName%_cdb}_oa echo converting $lib - $oaLib convertCDBA \ -lib $lib \ -oaLib $oaLib \ -overwrite false \ -log ./convert_${libName}.log # 检查命令返回码非零说明转换失败继续处理下一个库 if [ $? -ne 0 ]; then echo FAILED: $libName, see convert_${libName}.log fi done这个脚本的逻辑是遍历所有以 _cdb 结尾的目录生成对应的 _oa 目标路径逐个调用 convertCDBA。返回码检查放在这里很有必要批量任务里一个库失败了不能中断整个流程记录下来最后统一排查比卡死在第一个失败点高效。日志文件按库名分开存放排查问题时不用在一大个日志里翻找某个库的信息。-overywrite false 在这里是故意设置的如果某个库以前已经转换过一次这个脚本默认不会覆盖保留之前的结果。如果你想全部重新转换把 false 改成 true 就行。这一点要写成注释放在脚本顶部避免换人维护时踩坑。3.5 SKILL 批处理转换后立刻做自动检查shell 脚本解决“怎么转”但解决不了“转完以后到底有没有问题”。我一般会在转换完成后进 Virtuoso 里跑一段 SKILL把每个 cell 的 view 列表导出来和源 CDB 里的 view 列表做对比。下面这段 SKILL 逻辑是在新 OA 库里遍历所有 cell检查每个 cell 是否包含至少一个可读 view; 打开目标OA库遍历所有cell检查view是否可读 lib analog_oa cells ddGetObj(lib)~cells foreach( cell cells views cell~views when( views nil printf(WARNING: cell %s has no readable views\n cell~name) ) ) printf(check complete: %d cells scanned\n length(cells))这段脚本的用途是把“有没有可读 view”作为转换成功的最低标准。正常转换后每个 cell 至少有 schematic 或 layout 中的一种 view。如果某个 cell 的 views 列表为空说明转换过程出了问题值得回到源库复查。注意 ddGetObj 是 Cadence 的 Library Manager 访问接口在 CIW 里执行前要先确保目标库已经加载到 library list 中否则 ddGetObj 返回 nil脚本会把所有 cell 都报成空。4. 转换不等于收工库验证、CDF 检查与版图比对的必要步骤4.1 打开库的冒烟测试先看三类 cell 能不能编辑转换完成后别急着往前跑。先在 Library Manager 里确认新 OA 库出现在库列表中然后逐类抽查 cell原理图类 cell 要能打开、能拖器件、能保存版图类 cell 要能显示层次、能选到图形、能保存symbol 类 cell 要能打开且 pin 数量正确。注意保存这一步很关键有些转换结果只是“看起来能打开”一保存就报数据库错误说明 OA 对象没有完全建立。抽查数量不需要多每个类别抽三五个典型 cell 就够。重点选那些结构复杂的顶层原理图、带大量版图层次的底层 cell、有自定义 symbol 的 cell。如果这些 cell 能顺利打开再保存基础结构就没大问题。抽查过程中不要修改任何东西只做打开、缩放、选中、关闭、保存这一套动作目的是把数据库层的问题暴露出来而不是让你顺手改设计。4.2 CDF 参数比对器件参数有没有跟着走CDFComponent Description Format参数是最容易丢的东西。打开一个电阻 cell 的 schematic选中电阻 symbol按 q 查看属性。正常情况应该能看到 w、l、r 等参数数值和源 CDB 库里一致。如果全是默认值说明 CDF 映射出了问题。参数丢了不要慌常见处理方式是回源 CDB 库找到这个器件的 CDF 定义手工在新 OA 库的 CDF 工具里重新加载。具体路径是 Tools—CDF—Edit选择对应 cell 后手动填入参数名和类型。这个工作量大但比重新建库快因为只是参数定义丢了图形和连接关系还在。注意转换后立刻改 CDF 参数之前先确认源 CDB 库里的 CDF 文件是否完整。如果源库本身就没有 CDF 定义或者定义存放在用户目录的 .cdsenv 里那转换工具读取不到它属于源库问题不是转换工具的问题。4.3 跑一次 LVS 前后对比最硬的验证手段参数检查看的是器件的静态属性LVS 验证看的是整个电路的一致性。做法是从源 CDB 库导出一份 CDL 网表从新 OA 库再导出一份两份网表做一次 LVS 比对。如果 LVS 通过说明转换过程中没有丢失任何器件和连接关系。如果 LVS 报 mismatch先把差异项列出来看集中在哪类问题上——缺器件通常是 CDF 映射失败导致器件被跳过缺连线通常是 wire 属性或 pin 属性没转过来。这里要提醒一点LVS 比对用的规则文件必须是一致的那套。有些 PDK 同时提供 CDB 和 OA 两套规则文件转换验证时很容易拿错规则导致 LVS 报一堆虚假 error。检查方法是在两边的 LVS 命令里输出 rule file 路径肉眼核对一下是否指向同一个版本。版本号不一致就先统一版本再谈比对结果。4.4 比对清单转换验证阶段建议核对的项目以下是转换验证阶段我常用的核对清单按优先级排序检查项方法通过标准cell 完整性遍历库统计 view 数量与源库一致schematic 可编辑性打开、拖拽、保存无数据库报错layout 层次完整性打开顶层逐层查看层次数与源库一致symbol pin 数量打开 symbol统计 pin与 schematic 引脚一致CDF 参数选中器件q 查看属性数值与源库一致LVS 一致性双网表 LVS 比对mismatch 为 0这份清单不是要你每次转换都全跑一遍而是要根据设计阶段取舍。如果你转完只是为了继续画版图前四项必须过如果转完要跑后仿CDF 参数和 LVS 比对不能省。花费的时间在半小时到半天不等相比转换后带着隐患往下走值多了。5. 避坑手册转换失败的 5 个高频原因与排查思路5.1 库能打开但 cell 全部消失现象Library Manager 里能看到转换出的 OA 库但展开后没有 cell或者 cell 数量明显少于源库。原因源 CDB 库的 cellmap 信息丢失最常见的诱导因素是没有 lib.defs 或 lib.defs 里 view 类型定义不全。转换工具按 lib.defs 的路由表去扫描 cell 目录路由表缺了某一类 view 的映射对应的 cell 就被静默跳过日志里只留一行 warning。解决回到源 CDB 库确认 lib.defs 完整。对照同工艺包其他正常库的 lib.defs补全缺失的 view 类型定义后再重新转换。转换前先跑一次 dbCheck如果 dbCheck 也报错误先把损坏修掉再转换。5.2 转换报错 “Unable to find CDF data”现象转换日志里出现大量 CDF 相关 warning转完后新库器件参数为空q 查看属性全是默认值。原因CDF 数据没被转换工具识别。CDB 时代的 CDF 文件常放在 lib 目录下或用户主目录的 .cadence 配置里转换工具扫描不到自定义路径。还有一种情况是 CDF 文件里引用的 callback 函数在 IC617 里已经改名转换工具执行 callback 失败后放弃整个参数组。解决先查源库目录下有没有 cdf 文件有就把它复制到新 OA 库同级目录。然后打开 Tools—CDF—Edit 逐步确认参数组是否正确加载。callback 失效的问题比较麻烦常见做法是保留老 callback 定义在 IC617 里做一层函数名映射或直接在新库里重建 callback 逻辑规避老函数。5.3 版图层次丢失所有图形变成同一层现象layout view 能打开但层次全乱不同层级的图形堆在同一层显示颜色和线型全一样。原因CDB 的 techfile 和 OA 的 techfile 转换不完整。层名映射表没对上转换工具把不同层的图形全部写进了默认层。通常发生在老工艺库的 techfile 里用了自定义层名而 IC617 的 OA 流程只认标准层名。解决转换前先把库 attach 到新 PDK 的 techfile 上确保层名能一一对应。转换后如果已经乱了用 Create Layer 或 Techfile 工具手工重建层映射重跑一遍转换。要是工艺厂提供 OA 版本的 PDK直接在新 PDK 上重新做层映射比手动修快得多。5.4 LVS 报大量 pin missing现象原理图和版图的逻辑明明一致但 LVS 报缺 pin数量从几个到几十个不等。原因CDB 里的 pin 和 text 层在转换后没落到正确的 OA 层上。常见两种情况一是 pin 的 text 字符编码在转换过程中变成乱码LVS 工具认不出 pin 名二是 text 层的 mapping 配错pin 信息写在了一个 LVS 规则里不认的层。解决打开一个报缺 pin 的 cell看一下 pin 的 text 是否显示正常。乱码的话回到源库重新写 text 再转换。层不对的话检查 LVS 规则文件里对 pin 层的定义调整 text 层映射关系。少数几个 pin 丢失也可以直接在 OA 库里用 Create Pin 手工补上但这只是临时救火如果数量太多必须从根上修。5.5 转换卡死日志停在某个 cell 名现象转换进程不退出CPU 占用忽高忽低日志最后一行停留在某个 cell 名字上长时间没有新输出。原因这个 cell 的数据结构在 CDB 里就存在异常。最常见的是 cell 内含超大数组或非法字符OA 数据库 API 在写入时无法解析进入死循环或反复重试。也有遇到过 cell 名里带空格或特殊符号的情况OA 对命名规范更严格老库里的非法名直接导致转换失败。解决先等一小段时间确认是不是真卡死有些大 cell 转换确实慢。确认卡死后用命令行转换的 -skipCell 参数把问题 cell 跳过先完成其余部分的转换。转换结束后单独处理问题 cell重命名特殊字符、导出再导入或者手工重新创建这个 cell 并补画内容。永远不要指望卡死的转换进程自己恢复。6. 进阶技巧用批处理与 SKILL 脚本把转换做成可重复的流程转换做一次不难难的是做很多次还能保持一致。我在实际项目里养成的习惯是把转换和验证做成一整套脚本工艺库更新、项目换版本、换机器重新搭环境时跑一遍脚本就能把整个数据库体系重建出来。一个值得借鉴的流程是这样的先写一个环境检查脚本确认 IC617 环境变量、license、转换工具路径都正常再写批量转换脚本把 CDB 库列表作为输入参数逐个转换转换完成后自动跑一段 SKILL 检查脚本遍历所有 cell 统计 view 数量输出一份报告最后人工抽查几个代表性 cell确认能正常编辑保存。整个过程不需要打开 Virtuoso GUI 操作全程命令行日志留档哪里出了问题直接看对应日志。在 SKILL 脚本里还可以加一层更细的检查对每个 cell 记录 view 数量和 view 类型和源库的导出清单做 diff。这个 diff 不需要做到全自动但能把差异项单独列出来供人工复核比人肉对比快得多。我自己的习惯是每次转换做完必做三件事用 diff 对比源库和 OA 库的 cell 清单检查日志里的 ERROR 和 FAILED 关键字再挑一个复杂 cell 做完整的打开保存测试。这三件事做完转换质量基本心里有数。转换这件事做过几轮之后你会发现真正影响效率的不是转换命令本身而是源库数据质量。凡是提前清理过 cell、整理过 lib.defs 的库转换几乎是一路绿灯凡是从别人手里接过来、从没整理过的库转换过程必然抛出各种意外。所以我现在接项目的第一件事就是检查库结构质量宁可花一天时间整理库也不愿意在转换之后花三天追查数据丢失的问题。希望这些踩出来的路子能帮到你少走一段弯路。本文还有配套的精品资源点击获取