简介针对采用旧版CDB格式工艺库的团队在升级到IC617后遇到工艺库数据与OA格式不兼容、打开Virtuoso时出现ddUpdateLibList警告的典型问题这份PDF整理了一套端到端的转换操作手册。内容从识别启动时的英文提示入手分步演示在用户主目录下保存Library Path、启动CDB到OpenAccess转换器、选择工艺库中的cds.lib文件并执行转换再到将生成的数据复制回原工艺库路径完成替换。对于转换中可能出现的库列表更新异常、数据不完整等错误也给出了检查与验证方法。整份指南共1个PDF文件压缩包仅697KB文字精炼且步骤之间配有截图说明以问题导向组织可快速定位到转换前准备、执行转换和转换后验证三个阶段能够帮助版图设计工程师与PDK维护人员减少试错。目前已有1548人学习浏览适合正在从IC514迁移至IC617或需要兼容多种PDK版本的Cadence使用者直接对照操作。1. CDB转OAIC617升级时躲不掉的数据迁移手里十几个模拟库还锁在CDB格式里新到的IC617环境默认用OpenAccess签核PDK也只提供OA版本——这种新旧格式中间的过渡期几乎每个模拟团队都撞上过。标题里这行字其实就是一件事把Virtuoso老版本积累的CDB库整体搬到OA让它们能被IC617Virtuoso IC 6.1.7正常读写和继续做物理验证。本文会把转换工具Conversion Toolbox中的CDB to OpenAccess Translator的完整流程、关键参数和翻车点讲透适合正在做库迁移的版图工程师、CAD以及带项目的老工程师。2. CDB和OA到底差在哪为什么不能直接改个后缀就算转完2.1 两种数据库的组织方式CDB 是目录树OA 是对象库很多第一次接触转换的人会问不就是把文件复制过去换个格式名吗还真不是。CDBCadence Database时代一个 cellview 不是一个文件而是一堆目录和文件。比如说老库里一个运算放大器的 schematic在文件系统里长这样opamp/schematic/ sch.1 sch.cfg sch.cdb symbol/ symbol.1这类的结构在 cp -r 的时候经常漏掉隐藏文件而且不同小版本生成的文件名后缀还不太一样。CDB 库靠 cds.lib 里的 DEFINE 语句指路靠 lib.defs 定义层次关系和 techfile 路径一旦某个路径写的是相对路径整个库换一台机器就崩了。OAOpenAccess是完全另一套思路。它把 cellview 当成数据库里的对象来管理层次、属性、约束、连接关系都写进统一的 schema文件边界被数据库引擎接管。你在目录里看到的是一组数据库文件而不是sch.1、symbol.1这种碎片。因为对象有明确的类型定义IC617 这种新版本工具不需要靠猜测去解析老文件这也是 OA 能成为行业标准库格式的原因——Cadence、Synopsys 的工具都认它。这一节的本质差异用一个表格能看得很清楚对比项CDBOA基本存储单位cellview 目录 碎片文件数据库对象库结构描述cds.lib lib.defs库内 schema 属性定义property 存放散在各 view 文件里统一在对象属性表工具兼容性仅 Cadence 老版本Cadence / Synopsys 通用并行访问弱容易锁库支持多会话2.2 转换工具到底在做什么不是搬运是对象映射Cadence 提供的转换工具箱Conversion Toolbox里的 CDB to OpenAccess Translator正式名称里写的也是 Translator转译器而不是 Copier。转译的意思是它把 CDB 里每个 cellview 读出来再按照 OA 的 schema 重建一个 cellview。同样的名字在 OA 里存的 property 类型、层次关系表达、techfile 挂接方式都不一样所以不能逐字节复制。以最常见的模拟库为例CDB 里一个 layout view 会包含边界层、金属层、通孔层的信息这些信息分散在 display.drf、techfile 和各层文件中OA 则把这些层定义集中到技术数据库里cellview 只是引用。转换的时候工具会去解析技术文件把层次映射成 OA 的 layer/purpose 对再逐条写回。层级多了以后这种映射出错概率并不低这也是为什么后面要专门讲参数和验证。有一点可以提前说转换时的 log 文件里保留了详细的映射记录出问题后它是排查的第一依据千万别转完就把 log 删了。2.3 转换的边界在哪里哪些能搬哪些得手工补转换工具能可靠搬运的是cellview 的基本图形与结构、常规 property、schematic 的连通性、symbol 的几何形状、基本的 CDF 参数。这些是 CDB 里最通用的部分。搬不动或者经常搬歪的是三类东西。第一类是自定义 property 和回调函数老库如果自己用 skill 写过 property 回调OA 里没有对应的 schema 定义转换时这些字段会直接消失不会报错。第二类是 PCell尤其是依赖外部 skill 代码的参数化单元如果那个 skill 文件没有在新环境里注册PCell 转完之后会变成一滩平的图形。第三类是仿真数据像 psf、awd 后缀的结果文件本来就不归数据库管工具更不会替你搬但很多人默认它会。这三个坑后面第 5 章会展开怎么查。提示转库前先给源库做一份完整的目录清单记录 cellview 数量和几个典型 cell 的属性。没有基线数据转换后即使缺东西你也发现不了。3. 用 Conversion Toolbox 跑通第一次全库转换3.1 转库前的环境检查先确认三件事我第一次转库的时候犯过一个很低级的错误花了一个小时配命令结果发现 shell 里根本没有 cdb2oa 这个可执行文件。Virtuoso 的转换工具不是单独安装的而是跟着 IC617 主程序打包放在安装目录下的 tools/dfII/bin 里同时要求环境变量 CDS_INST_DIR 指到正确的安装根目录。所以动手前先做三件事。第一确认工具在不在 PATH 里which cdb2oa如果没找到先检查 CDS_INST_DIR 是否设置正确echo $CDS_INST_DIR ls $CDS_INST_DIR/tools/dfII/bin | grep cdb第二确认 OpenAccess 版本。IC617 一般自带 OA但你的环境里可能被别的流程覆盖了 OA_HOME版本不匹配转换出来的库会打不开。看当前生效的 OA 路径echo $OA_HOME如果 OA_HOME 指向的不是 IC617 配套的 OA建议在转库的 shell 里把它强制指回来避免后续 Virtuoso 启库时报 schema 版本错误。第三确认源库是只读还是可写以及磁盘空间够不够。转换期间源库不应该有任何 Virtuoso 会话打开否则文件锁会引发不可预期的中断。目标磁盘要留出源库 1.5 倍以上的空间OA 数据库有额外索引通常会比 CDB 目录大一圈。3.2 单库转换的标准命令一条命令拆开讲参数环境没问题后先挑一个不常用的库做单库转换。常见做法是命令行直接调 cdb2oa不用打开 Virtuoso GUI# 单库转换把 /data/old_cdb/opamp 转成 /data/oa_lib/opamp_oa # -lib 指定源库路径 # -oalib 指定转换后 OA 库的存放路径 # -cdslib 指定源库所属的 cds.lib转换时用它解析库间引用 # -log 日志文件路径排查问题第一步看这里 cdb2oa \ -lib /data/old_cdb/opamp \ -oalib /data/oa_lib/opamp_oa \ -cdslib /data/old_cdb/cds.lib \ -log ./logs/opamp_conv.log这里面的关键在于 -cdslib。很多教程只提 -lib 和 -oalib不提它但实际转库时源库里的 cell 经常跨库引用比如 opamp 的 schematic 里放了 analogLib 的器件或者调了另一个基础库的 layout。没有 cds.lib工具无法解析这些跨库实例最后转出来的顶层库打开全是空的或红叉。为了防止歧义我一般会把源库路径写成绝对路径日志也放到单独目录如果目标库转失败清理后重新转时日志目录里还能保留上一次的记录。命令执行完先看返回码再打开 log 文件搜关键字grep -iE error|warning|fail ./logs/opamp_conv.log | head -50log 里 error 级别的行基本可以对应到后面第 5 章要讲的那几类问题。如果 log 显示正常但你不放心就启动 Virtuoso用 CIW 里的 Library Manager 打开目标库随机挑几个 cellview 点开看看。3.3 批量转换整个项目的脚本把十几二十个库一次搬完实际项目里不会只有一个库。用户通常的做法是写一个批量脚本逐行解析 cds.lib 里的 DEFINE 定义对每个库调用一次 cdb2oa。下面这个脚本在我的环境里一直能用#!/bin/bash # 批量将 cds.lib 中列出的 CDB 老库转换为 OA # 用法: ./cdb2oa_batch.sh /data/old_cdb/cds.lib /data/oa_lib CDSLIB$1 DEST_DIR$2 LOG_DIR${DEST_DIR}/logs mkdir -p $LOG_DIR # 跳过注释和空行只处理 DEFINE 开头的库声明 grep -E ^DEFINE $CDSLIB | while read -r _name _path; do libName$_name libPath$_path echo converting ${libName} from ${libPath} cdb2oa \ -lib ${libPath} \ -oalib ${DEST_DIR}/${libName} \ -cdslib ${CDSLIB} \ -log ${LOG_DIR}/${libName}.log if [ $? -ne 0 ]; then echo [WARN] ${libName} 转换失败看 ${LOG_DIR}/${libName}.log fi done脚本的逻辑很简单用 grep 只挑 DEFINE 行避免把注释和 INCLUDE 语句当库路径每行拆出库名和路径转完一个检查一次返回码。它在实际项目中能省掉大量重复劳动但有两点要提醒。第一cds.lib 里的 DEFINE 路径可能是相对的脚本不会帮你做路径归一化建议先 cd 到 cds.lib 所在目录再跑或者提前把 DEFINE 改成绝对路径。第二这个脚本默认所有库平级转换如果项目里有层次化的库引用顶层库引用子库转完库名必须保持一致且目标目录的结构要和 cds.lib 里期望的结构对齐否则顶层库打开时还是会找不到子库。注意转换期间不要手工去动目标目录里的文件。OA 的写入不是原子的转一半去清理或者中断很容易留下一个半成品库下次转换时工具会报已有 OA 数据的错。宁可让它自然跑完再统一处理。4. IC617 转库时的 4 个关键参数与配置项4.1 -cdslib 与 -lib 的组合库引用解析的正确姿势第 3 章的命令里-cdslib 已经出现过一次但它的作用在批量场景里容易被低估。cdb2oa 解析源库时不仅读当前库的 cellview还要解析它对其他库的引用。如果引用的库也被这个 cds.lib 声明工具会直接使用声明里的路径如果没有声明工具可能把实例当成本地 cell 处理造成转换结果张冠李戴。常见的坑是源 cds.lib 里 DEFINE 的是旧路径但那个路径在新机器上不存在工具解析失败后会在 log 里写一条 warning然后跳过这个引用。结果就是转完的 schematic 里元件还在但点开属性看不到库名。所以转批量项目时先把源 cds.lib 花十分钟整理一遍确保每个 DEFINE 路径都存在且可读。路径很多时可以考虑用脚本批量检查# 检查 cds.lib 中 DEFINE 的路径是否存在 awk /^DEFINE/{print $3} /data/old_cdb/cds.lib | while read p; do [ -d $p ] || echo missing: $p done4.2 -overwrite 与转换模式什么时候能放心覆盖cdb2oa 在目标库已存在时的默认行为是报错退出而不是覆盖。这个设计原本是防止误伤已有 OA 库但在批量转换场景里第二次重跑就变得很麻烦。需要重跑时常见做法是加 -overwrite 参数命令会强制清理目标库再转cdb2oa -lib /data/old_cdb/opamp \ -oalib /data/oa_lib/opamp_oa \ -cdslib /data/old_cdb/cds.lib \ -overwrite \ -log ./logs/opamp_conv.log能不加就先别加。因为 -overwrite 在某些小版本里会把整个目标目录删掉重建如果目标目录里还有别的 OA 库文件会一起被清掉。更稳妥的做法是重跑前手动把目标目录改名保留一份现场再下一次转换时指向全新目录。这样即使转换又失败至少能看到第一次的现场。这里还要区分转换模式的另一个含义转换时源库是只读复制还是转换完成后直接改源库。默认是复制源库保持原样。有些团队为了省磁盘会选搬迁模式源库转完自动删除——这是血泪教训高发区除非确认源库有备份否则不要选。4.3 层次与 PCell 的处理选项flatten 还是保持层次对于包含大量 IP 复用和层次引用的库转换时要明确层次策略。cdb2oa 默认保持层次也就是每个 cellview 独立转换cell 之间的引用关系靠库名和 cellname 重连。这通常是正确的因为转完上层 library 后schematic 和 layout 的层次还在后续 LVS 也更好排查。但有一种场景需要 flatten源库里的底层 cell 是 CDB 时代的老 PCell新环境里对应的 skill 代码已经找不到了转换后这些 PCell 无法参数化再生。如果这些 cell 在顶层被大量实例化且参数不需要再修改可以干脆把它们展平掉避免转出十几个变形的 PCell。flatten 会显著增加数据量而且会丢掉可编辑性所以我的建议是只对确认不会再编辑的老 IP用主力模拟库保持层次。判断当前库有没有隐患 PCell可以在转换前先扫描一遍 cellview 类型# 统计源库里所有 cell 的 view 类型 find /data/old_cdb/opamp -maxdepth 2 -type d | awk -F/ {print $NF} | sort | uniq -c看到大量 pcell 类型的 view 时转换前要确认对应 skill 文件在新环境能加载。加载不上的提前决定是放弃这些 cell 还是 flatten。4.4 环境变量配置CDS_Netlisting_Mode 和 64 位进程转换工具和后续仿真共用环境变量最容易被忽略的是 CDS_Netlisting_Mode。这个变量控制 netlister 的输出对象格式老流程里经常被设成 CDBA。转库后如果还保持 CDBAIC617 里跑 Spectre 或 LVS 时netlister 会尝试按老格式处理 OA 库轻则告警重则把 OA 特有属性丢光。转库和转库后的日常使用都建议显式设置export CDS_Netlisting_ModeOA另一个环境相关的问题是 32 位 vs 64 位。IC617 在 Linux 上默认可能是 32 位进程但 OA 数据库的索引和缓存策略在 64 位下表现更稳大库转换尤其明显。设置方式一般是启动 Virtuoso 时带 -64 参数或者提前导出 CDS_AUTO_64BIT。转换大批量库时用 64 位进程能明显减少内存不足导致的半途退出。还有一个容易被忽略的配置多核并行。cdb2oa 本身在部分版本支持并发转换多个 cell但并发数不是越高越好。它的瓶颈通常在磁盘 IO 和 OA 内部的 schema 锁我实际使用下来 4 并发比较稳再高 log 里会出现大量 retry。如果转大批量库可以分几批并行每批之间留一点时间间隔让锁释放干净。5. 转换翻车现场5 个常见坑和排查对策第 3 章、第 4 章讲的是正常怎么做这一章全是血泪经验。转换工具有个特点它不会把所有问题都写进 error很多数据丢失是以 warning 甚至悄无声息的方式发生的。所以排查的第一步永远是先看 log再看表现。下面五条是我和同事在转换过程中真实踩过的按出现频率排。5.1 重跑时报已有 OA 数据目标库成了半成品现象第一次转换中途因为磁盘满或超时中断第二次重跑时 cdb2oa 直接报错说目标库已存在 OA 数据拒绝继续。翻 log 看不到明确的 error 位置。原因OA 转换不是原子操作cellview 是先建骨架再回填内容。中断会留下只有骨架没有内容的半成品 cell工具检测到这些残留认为目标库状态不合法拒绝覆盖。这个设计是为了防止误覆盖完整库但也挡住了正常的重跑。解决目标库目录整体改名留作现场再新建一个空目录作为目标重新转换。别直接删半成品库有时候还能手工挽救里面几个完整的 cell直接删了就没有后悔药了。5.2 PCell 转完变成一滩平图形参数编辑就崩现象转完库layout 里器件还在但双击器件想改 W、L图形不发生任何变化甚至直接报错。再看 CDF 参数里面对应的 callback 已经失效。原因CDB 时代 PCell 的参数化行为靠 skill 回调驱动这些回调函数注册在外面某个 skill 文件里。转换工具只搬了 PCell 的图形和参数值没搬回调代码。目标环境没有加载对应 skill 文件PCell 就退化成普通图形参数改了也不驱动版图。解决转换前先在新环境加载一遍老库配套的 PCell skill 文件确认加载无报错再转。如果 skill 文件确实找不到了就把这些 cell 从应保持层次的名单里拿掉改用 flatten 流程至少保证顶层图形是完整的。5.3 自定义 property 静默消失现象转完后打开 property editor源库里能看到的一堆 user property 没了也没报任何错误。有的 property 还在但值变成了默认值。原因这些 property 是当年用 skill 的 dbCreateProp 或类似接口写进去的类型和名字只存在于源库的 schema 里。OA 的 schema 不认识这些字段转换工具又不负责猜测字段含义所以直接跳过。跳过是静默的log 里只有 info 级记录不仔细看根本发现不了。解决转换前先用 skill 脚本把源库所有 cellview 的 property 清单导成文件转换后在 OA 库里跑一段恢复脚本用 dbCreateProp 重新写回。恢复脚本要按 property 类型匹配别把 string 类型写进 int 字段。这个工作量不小所以导清单这一步必须做而且要保留到项目结束。5.4 顶层库实例全红子库路径引用失效现象顶层 schematic 转完能打开但里面的底层实例显示成红叉点进去看属性库名是乱的或者提示找不到 library。原因cds.lib 里 DEFINE 用的是相对路径转换时工具按照当时的工作目录解析了子库路径转换后目标库放在了另一个根目录下引用关系就断了。另一种情况是子库和目标库不在同一个 cds.lib 声明里转换时子库没被解析。解决批量转换前统一规划目标目录树所有库放在同一个目标根下库名保持不变。转换后检查两件事目标库所在目录有没有一份正确的 cds.lib顶层库的 instance 属性里库名是否和 DEFINE 一致。不一致就用文本编辑把 cds.lib 里的路径改成新环境下的实际路径让 Virtuoso 重新解析。5.5 schematic 的 pin 顺序变了后仿 netlist 对不上现象转换完成后跑 LVS 和后仿器件没少但 netlist 里的 pin 顺序和转换前不一样导致部分节点接错LVS 报一堆莫名 mismatch。原因CDB 里 pin 顺序部分依赖 symbol 里的图形顺序OA 里 pin 是独立的 term 对象顺序不再由图形决定。cdb2oa 在转换时会把 pin 按名字重新组织如果老流程脚本是按第 3 个 pin 必须是 VDD这种约定写的转换后就全乱了。解决转完库后挑一个代表性 schematic 导出 pin list和转换前的 pin list 做文本 diff。不一致时问题不在转换参数而在老流程脚本的编码约定需要把流程脚本改成按 pin name 取 pin而不是按顺序取。类似的约定在 skill 脚本、CDF callback 里都可能埋雷排查范围不要只盯着转换工具。6. 转换完怎么验证数据没坏复查清单与对比脚本转换工具跑完只是开始验证才是让团队敢继续用的关键。我的做法是不看 log 的 exit code而是先做一轮机械对比源库和目标库的 cellview 数量必须一致缺失的 view 再回头查 log。下面这个脚本可以快速数数量# 统计源库和目标库的 cell/view 数量 src_count$(find /data/old_cdb/opamp -mindepth 1 -maxdepth 1 -type d | wc -l) dst_count$(find /data/oa_lib/opamp_oa -mindepth 1 -maxdepth 1 -type d | wc -l) echo src: $src_count dst: $dst_count数量对完之后再开 Virtuoso 做三件事随机打开 3 到 5 个 schematic 和 layout逐个检查 instance 的库名和参数对核心模块跑一次 LVS不要跑全芯片抽一个中等规模 block 就够用 CDF 工具导出一份转换前后的参数表做 diff。三件事都过了这批库才敢进主线流程。我自己的习惯是转库永远选在项目空档期先转一个非主力库试水把 cell 数、PCell 数、自定义 property 数记成基线下一批转主力库时对着基线逐项核对。这个过程看起来笨但比事后在 LVS 阶段抓 mismatch 省太多时间。希望帮到你。本文还有配套的精品资源点击获取