IC617 加载 CDB 旧库报错？cdb2oa 完整迁移指南

简介面向使用 Cadence IC617 的芯片设计者与版图工程师这份 PDF 专门解决旧有 CDB 格式工艺库或数据无法直接被 IC617 识别的问题特别是在从 IC514 等早期版本升级到 IC617 时尤为常见。IC617 默认采用 OA 数据库而许多老工艺库仍基于 CDB 格式两者不兼容时 Virtuoso 加载库常会弹出 ddUpdateLibList 警告提示正在对 CDB 数据运行 OA 可执行文件导致设计流程中断。文档围绕这一真实场景系统整理了从 CDB 转换到 OA 的完整思路既说明 cdb2oa 命令的基本含义也介绍在 Virtuoso 的 Edit 菜单中打开 Library Path 并保存到 home 目录、再通过 CDB to OpenAccess Translator 选择 PDK 里的 cds.lib 完成转换的流程命令行与图形界面两种方式均有覆盖同时强调转换完成后需检查生成的库并建议复制回原 PDK 目录必要时先删除旧库避免再次出现加载异常。资源还对常见报错给出排查思路帮助读者判断是库格式问题还是路径设置问题压缩包仅包含 1 个 PDF 文件约 697KB内容精炼便于离线查阅。目前已有 1548 人学习适合需要将旧工艺库迁移至 IC617 的 Cadence 用户也适合初次接触 OA 转换流程的版图工程师与芯片设计初学者作为参考。1. IC617 跑不了 CDB 旧库问题不在工具链而在数据格式代差用 IC617 打开老 PDK 时报ddUpdateLibList: It appears that you are trying to run an OA executable on CDB data基本可以断定你正被 CDB 到 OA 的存储代差卡住。IC514 及更早版本默认用 CDBCell Design Basics格式管理单元库而 IC617 的 virtuoso 是 OAOpenAccess原生的OA 可执行文件直接读 CDB 目录会找不到合法的数据描述于是 virtuoso 用这条 Warning 拒绝加载整个库。网上不少帖子一上来就让人改环境变量实际多数情况根本不用动 .bashrc真正要做的是把工艺库的数据描述层整体从 CDB 平移成 OA也就是跑 Cadence 官方给的 cdb2oa 流程。这个流程对模拟版图工程师、PDK 维护人员和学生项目组最实用尤其是还在用手工建库老工艺节点的团队。下面这套步骤我在 tsmc035、smic18 这类老 PDK 上都跑通过跟着做完virtuoso 里能正常打开 lib、能进版图、能跑 DRC。2. CDB 与 OA 的存储差异为什么不能直接 Copy 库目录2.1 CDB 的 prop.xx 与 OA 的 database 目录到底差在哪CDB 库的最外层特征就是每个 library 目录下有个prop.xx文件它记录了这个库的设备、层次、显示信息等一串老格式的属性而 OA 库里数据是按 OpenAccess 的层级结构组织的顶层入口是lib.defs每个 cell 下按OA的目录树展开。IC617 加载库时优先按 OA 规则去解析一旦在库目录里扫描到prop.xx它就认定这是 CDB 数据出于安全直接拒绝继续执行不是你代码写错是数据描述层不兼容。这个判断机制在 virtuoso 启动阶段就会触发所以你会看到库管理器里那个库是灰色不可展开的。解决思路也很直接把 CDB 的物理属性翻译成 OA 的对象属性重建出 icon、device 这些 mapping并重新生成一个有效的 OA 目录结构。cdb2oa 做的就是这件事它不是一个简单的文件格式转换而是会逐个 cell、逐个 view 重建数据同时迁移 CDFComponent Description Format参数与 property 信息。2.2 转库前的环境检查清单先确认你是 64 位安装和可写目录动手之前先把环境条件核一遍免得转一半报权限错误。第一确认你的 virtuoso 是 IC617 或更高版本老版本 IC615 以前不带完整的 CDB 转换支持命令工具路径都可能没有。第二确认 CDB 库对应的 cds.lib 文件可读并且你能拿到它的写权限——转换过程中会在库所在目录旁生成临时文件最后还会要求你把转换好的 OA 库覆盖回原路径。第三建议在 home 目录下先建一个工作目录比如$HOME/cdb2oa_work把 cds.lib 复制一份进去在这个副本上做转换原因后面会说。第四用df -h看一眼磁盘剩余空间转换过程和最终 OA 库体积通常会是 CDB 原库的两倍左右磁盘不够时会卡很久然后报No space left。我一般还会顺手记一下当前$CDS_INST_DIR指向哪个版本防止系统里装了两套 Cadence工具版本不一致导致转换产物有兼容性隐患。2.3 备份策略转换前必须做的三件无聊但保命的事转库本质上是覆盖性操作尤其是官方推荐的流程最后要求“删掉原库再复制回来”一旦转换结果有缺陷原库又被删了后悔药都找不到。所以我会在转换前强制做三件备份第一把原 PDK 目录完整复制一份到别的位置保留目录结构命令是cp -rf tsmc35mm tsmc35mm_cdb_backup这步慢但值得第二单独备份原cds.lib因为它里面可能写了不止一个库的路径映射转换过程会按它逐个处理备份为cds.lib.bak_cdb第三把工艺文件里那些独立的模型文件、calibre 规则文件、spectre 模型等单独打包因为这些只能在 virtuoso 外部引用不归 cdb2oa 管但后面验证时要用。这三件事做完剩下的流程哪怕翻车也能安全回滚。3. 完整转换流程保存 lib.defs、启动 Conversion Toolbox、加载 cds.lib3.1 第一步在 Virtuoso 里保存一份自己的 Library Path File转换前先打开 IC617 的 virtuoso此时它大概率会弹警告说检测到 CDB 数据一般不影响操作界面。接着走菜单Edit - Library Path File打开 Library Path File 编辑器看到中间列出的所有库路径后直接Save As保存到$HOME下文件名建议沿用cds.lib。这一步很多人不理解会觉得“原 PDK 里本来就有 cds.lib为什么要再存一份”原因是转换工具读取的是当前 virtuoso 进程使用的 lib 路径文件而不是 PDK 目录下那个原始的 lib 文件。如果你直接手工改 PDK 里的 cds.lib某些版本的 Conversion Toolbox 反而读不到更新后的内容因为它持有的是启动时加载的路径快照。保存到 home 下还能避开后续覆盖操作后面转换完我们把新库复制回 PDK 目录时原始 cds.lib 会被替换但你 home 下这份还留着初始路径记录方便排查路径冲突。保存完这步virtuoso 的内存里仍然知道这些库的原路径转换工具才能定位到数据源。3.2 第二步从 Tools 菜单启动 Conversion Toolbox选 CDB to OpenAccess Translator在 virtuoso 主窗口的菜单栏进Tools - Conversion Toolbox打开后选择CDB to OpenAccess Translator这个入口在部分版本里显示为CDB to OA Translator。点开后需要你手动 browse 选择cds.lib——这里要选刚才保存到 home 目录下那一份不要选 PDK 里面的原始文件。选完ok转换器就进入执行状态。此时你会看到终端或日志窗口不断滚动输出内容一般包括Reading cds.lib、Processing library xxx、Translating cell yyy等。这里的关键观察点是每个库处理时是否出现ERROR或WARN字样特别是WARN: layer purpose not found这类不影响主流程但会影响显示而ERROR: unable to open CDB database则说明路径配置有问题后面 5.1 节会展开讲。整个转换时长取决于库的规模小 PDK 几分钟大的像包含多套 pcell 的库可能二三十分钟。这段时间不要关窗口宁可让它安静跑完也不要中途打断——我见过有人看日志不动就 CtrlC 强杀结果库目录留下半个写了一半的 OA 结构后续怎么修都别扭。3.3 第三步转换产物的输出位置与两种复制回 PDK 的方式转换完成后回到 shell 或文件管理器查看 home 目录会看到转换生成了以原库名命名的 OA 格式库目录比如原库tsmc35mm会在 home 下生成tsmc35mm新目录里面是完整的 OA 结构。此时官方推荐的做法是进原 PDK 目录把旧 CDB 库删掉再把 home 下新生成的库复制回去。实际操作我分层处理# 进入 PDK 根目录先确认要删的对象确实还是 CDB 库 cd $PDK_ROOT/tsmc35mm # 用库标志文件确认类型见到 prop.xx 就是 CDB 库 ls -la | grep prop.xx # 删除旧 CDB 库建议用 mv 而不是 rm等于留个后悔药 mv tsmc35mm tsmc35mm_cdb_deleted # 把 home 下转换好的 OA 库复制回 PDK 根目录 cp -rf $HOME/tsmc35mm . # 复制后确认没有遗留 prop.xx如果还有说明复制的是旧文件 ls tsmc35mm | grep prop.xx这里用mv代替rm是血泪换来的习惯。万一新库有问题你能立刻mv回来整个环境恢复耗时不到一分钟。复制完成后关键检查是prop.xx不能再出现同时要能看到lib.defs或oa子目录。很多新人栽在这一步明明转换成功但把旧库一删一复制后依然报同样的 CDB 警告一查发现是cp -rf时把残留的 CDB 文件一起带过去了或者把原库路径下别的 CDB 库也牵连了。之后再从 PDK 目录启动 virtuoso加载的库路径指向新 OA 库警告自然消失。3.4 转换完成后的第一轮加载测试不只打开库还要看 cellview库复制回去后别急着跑仿真第一轮加载测试应该是确认 virtuoso 能展开每个 cell 的 view。从 PDK 目录启动 virtuoso打开 Library Manager找到刚才转好的库双击展开 cell逐个看有无symbol、layout、schematic视图。这里有个常见情况只有部分 view 被转出来尤其老库中那些作为 CDF 回调函数用的参数化单元转换时如果 pcell 代码是 skill 写的而工具没解析到对应环境layout 视图可能转不出来。判断标准很简单如果layout视图存在但打开是空的一定是 pcell 没重建如果layout视图存在且能显示图形但报undefined function的 skill 错误那就是 pcell 代码路径没配对这个放到后面 5.2 节专门说排查。第一轮加载测试里还应该顺手打开一个简单 cell 的 layout 进版图编辑器确认能正常显示层次和器件再随便放一个 instanz看属性能不能读出来——这步能验证 OA 的 property 数据是否完整而不仅仅是目录结构对不对。4. 命令行路线run oa exec 与 cdb2oa 的适用场景4.1 什么时候必须用命令行而不是 GUI 流程GUI 流程适合单机单库、PDK 数量少、需要盯着看日志的场景。但碰到这几种情况GUI 就容易让人难受需要批量转换十几个库机器上没有开图形界面权限只能 SSH 进去干活或者转换过程中 virtuoso 频繁崩溃——比如老 PDK 里带大量非法字符命名的 cellGUI 会卡死。这时候就应该用 IC617 自带的命令行转换入口Cadence 官方给了一组执行引擎的切换命令其中和 CDB 转 OA 最直接的就是通过cdb2oa调用。在 IC617 的安装路径下tools/dfII/bin目录里有对应可执行文件并且 virtuoso 安装时一般也注册了 shell 级别的快捷调用方式。不过直接裸敲cdb2oa -i input.cdb -o output.oa这种写法在 IC617 环境里不通用那是 OpenAccess 社区通用的抽象语法Cadence 的封装还带自己的参数选项下面给出实际可用的调用形式。4.2 用 run oa exec 进入 OpenAccess 执行环境IC617 里的标准做法是先进入 OA 执行环境再调用转换命令。交互式场景下virtuoso 命令窗口里可以直接执行run oa exec进入 OA exec 环境后提示符会变化此时加载你的 cds.lib 路径然后执行转换cdb2oa -libname tsmc35mm -cdslibpath $HOME/cds.lib -q参数说明-libname指定要转换的单个库名一次只转一个-cdslibpath指向包含该库路径声明的 cds.lib 文件-q是静默模式降低日志输出等级适合批处理脚本里调用。不加-libname时工具会按 cds.lib 里所有声明库全部转换所以批量需求直接省略即可但前提是你已经确认 cds.lib 里没有指向垃圾路径的已损坏库。逻辑上run oa exec的作用是重新初始化一套 OA 运行库环境让 cdb2oa 拿到正确的数据库驱动相当于在命令行里复刻了 GUI 里 Conversion Toolbox 的初始化过程。实际项目里我一般用脚本方式跑因为要日志留痕和异常重跑直接交互式敲容易漏参数。脚本化写法大概这样#!/bin/bash # 批量转换 CDB 库到 OA 库 # 用法./conv_lib.sh /path/to/cds.lib CDS_LIB$1 WORK_DIR$(dirname $CDS_LIB) # 进入 OA exec 环境并执行转换日志写文件便于排错 run oa exec cdb2oa -cdslibpath $CDS_LIB -log $WORK_DIR/cdb2oa_run.log 21 # 转换结束后检查日志中的 ERROR 计数 grep -c ERROR $WORK_DIR/cdb2oa_run.log脚本里第 5 行是核心run oa exec后直接跟命令就不用先进交互再敲了。-log参数把输出落到文件避免终端滚动刷屏导致前文日志丢失。跑完grep -c ERROR是为了快速统计失败条目数如果数字不是 0再打开日志逐个看。我习惯每转完一个库就grep一次而不是全部转完再查因为一旦某个库卡死整体脚本也跟着停早发现早处理。4.3 命令行模式下容易忽视的符号链接问题命令行路径与 GUI 最大的不同是它默认不帮你处理 PDK 目录下那些符号链接。老 PDK 里常见结构是tsmc35mm目录下有一堆指向上游文件路径的软链比如models - /home/share/pdk/tsmc35/models或calibre - /home/share/pdk/tsmc35/calibre。GUI 的 Conversion Toolbox 会顺着这些软链读取内容但命令行模式下如果直接对 cds.lib 里的库路径做转换工具扫描目录时遇到软链的处理行为有时很隐晦可能出现库转完后软链断了——因为在目标目录生成时它创建了同名实体目录覆盖了软链。稳妥做法是在写脚本前先检查一下库目录里的链接情况# 列出所有符号链接确认哪些指向外部目录 find $PDK_ROOT/tsmc35mm -type l -exec ls -l {} \;如果发现类似results - ../../../user_data/results这样的链接建议转换时显式对配置文件做一下处理把链接目标位置在转换后的目录里重新建一遍相同相对路径。我一般不会删掉软链再转因为那样会让某些引用关系彻底丢失正确姿势是转换完成后进新库目录检查哪些软链变了再逐个补上。命令行下还有个常见问题是cds.lib文件里路径用了环境变量比如DEFINE tsmc35mm $PDK_ROOT/tsmc35mm而你的脚本环境没导出PDK_ROOT导致工具解析$PDK_ROOT时空字符串库找不到。解决办法是脚本开头export PDK_ROOT/实际路径或者在调用前用env检查一遍关键变量是否都在。5. 避坑清单cdb2oa 转换中最容易翻车的五个细节5.1 报错It appears that you are trying to run an OA executable on CDB data现象virtuoso 启动后库管理器里某库灰显且 CIW 日志直接打这条 Warning库打不开。原因库目录里还留着prop.xxvirtuoso 判定这是一个 CDB 库。这个报错最容易在刚转换完复制文件时出现——你只把 home 下新库目录复制回去了但老库根目录还有个没删干净的prop.xx残留或者你复制的目标目录里混着新旧两套文件。解决按 3.3 节的检查命令进库目录ls确认prop.xx确实不存在了如果有就先删除再让 virtuoso 重新扫描同时确认lib.defs文件存在。如果删完prop.xx还是报同样错检查是不是有二级子目录里还藏着prop.xx用find . -name prop.xx全库扫一遍一网打尽。5.2 转换成功但单元库 layout 打不开报 skill callback 函数缺失现象库能展开cell 也有 layout 视图但打开 layout 时 CIW 报*Error* eval: undefined function - xxxCallBack之类或者 layout 打开是一片空白。原因老 CDB 库里的参数化单元pcell是用 skill 写的回调函数实现的cdb2oa 转换数据格式的时候并不会重新编译 pcell 代码它只是把 pcell 的调用关系和参数映射写了进去当 virtuoso 加载这个 cell 时需要到 skill 函数库里找到对应的回调找不到就自然报错。解决先从 PDK 安装目录找找有没有skill或pcell子目录把这些 skill 文件的路径补到.cdsinit或site配置里如果 PDK 自带的是编译后的.ile文件确认 IC617 的版本位数一致32 位编译的 pcell 在 64 位 virtuoso 下也可能加载失败。补完配置后重启 virtuoso再次打开 layout 验证。5.3 转换后少了部分 cellview尤其缺 hdl 或 spectre 视图现象Library Manager 里 cell 下面的 view 列表比原 CDB 库少比如原来有config、hspiceD转换后只剩schematic和layout。原因cdb2oa 默认按设计数据库视图集转换部分文本类视图或第三方工具关联视图不在它的转换清单里比如 hspice 的网表视图本质上是文本它不会主动迁移另外一些用特殊名字命名的视图转换器不识别就跳过了。解决转换前先记录原库的 view 清单转换后用差异对比列出丢失项对于纯文本类视图如hspiceD直接从旧库目录复制内容到新库对应路径再在新库的 cellview 列表里手动补注册。注意这个操作要在库结构里操作别直接在文件管理器里扔文件要用 virtuoso 的File菜单或直接改内部文件否则新库的 view 索引不会自动更新。5.4 转换过程卡在某个 cell 或日志反复刷同一行不是死机而是 pcell 重建慢现象转换日志停在同一行比如Processing cell inv持续 20 分钟不动看起来像卡死。原因CDB 里的复杂 pcell——尤其是带大量参数运算的——在 OA 重建时需要对每个参数实例做一次完整的属性计算与映射数量大时计算量很可观有些库单个 pcell 的实例数量上万转换慢是正常的。解决先看日志文件大小是不是还在增长有增长就说明还在跑耐心等如果文件大小完全不变超过 30 分钟再用ps -ef | grep cdb2oa确认进程还活着进程正常就继续等进程异常就记录当前 cell 名然后用-libname逐个库转或跳过出问题的单元。别用 CtrlC 硬停否则残留半开的 OA 库结构更麻烦。5.5 转换完成后PDK 里的仿真模型路径全失效现象virtuoso 版图能开了但跑仿真时模型文件找不到或者报 calibre 的规则文件路径无效。原因cdb2oa 只搬迁库的数据描述不负责更新库的中文本网表或配置文件里写死的绝对路径老 PDK 里很多模型路径写的是当年建库时的绝对路径换了机器或换了目录层级路径自然全废。解决转换完成后统一检查 PDK 根目录下的.scs模型文件、calibre 的.rule文件、以及 cds.lib 里DEFINE的路径逐个确认存在性路径失配的用sed批量替换或直接改 cds.lib 里的路径声明。最常见的是DEFINE xxx /home/CHEN/...这种写死 home 路径的情况改成当前机器真实路径。这步不做好库转得再漂亮也跑不了真活。6. 验证闭环用 DRC 和 LVS 跑通一块测试版图再谈库可交付转换完成且能打开 cell只是数据格式迁移成功要证明工艺库真正可用必须拿真实设计跑一遍验证流程。我的习惯做法是在转换后的库里新建一个最小测试单元画一个最小尺寸的 MOS 管尺寸就按你 PDK 的设计规则最小值写比如 W/L 0.35u/0.35u然后把这个器件阵列排成几十个再用一条金属线把它们串起来。这个结构足够简单但覆盖了器件调用、层次实例、金属连接三层数据能有效暴露属性映射问题。接着跑 DRC验证用 Calibre 还是 Assura 取决于 PDK 配套但注意跑之前先确认规则文件路径按 5.5 节修过了。如果 DRC 报告里出现类似device density之类异常先不用怀疑规则回头查一下这个器件在 OA 里的 CDF 参数是否被正确转换很多时候报错的根源是参数值没有传过来。然后跑 LVS这里有个容易误导人的点转库后版图上器件的坐标和连线层可能看起来没问题但 LVS 提取的网表和源原理图不一致常见原因是schematic视图里的 CDF 参数是旧的而 layout 里已经迁移成了新值。我一般会把 LVS 的厄报错截图存下来和转换日志对照看能准确定位是不是 pcell 参数映射的问题。验证通过后还有两个收尾细节第一在 virtuoso 的Library Manager里右键库选属性确认 OA 版本号大于 21.0部分老 PDK 转换后显示 OA 版本过低会导致后续某些脚本 API 不可用这时要用 OA 的工具升级版本号但不用重新转换数据。第二把转换后的库目录打个 tar 包留档里面顺便放一份本次转换的命令参数和日志下次同事遇到同样的库时直接复用参数省得重新摸一遍。我自己后来每次转库都强制把备份、cds.lib保存路径、转换日志、验证 DRC 结果这四样东西放进一个带日期的目录再往下走下一个库。从那以后基本没再因为转换返工过希望帮到你。本文还有配套的精品资源点击获取