企业官网建设流程全解析

简介：面向使用 Cadence Virtuoso IC617、需要处理旧工艺库兼容问题的模拟与版图工程师及学习者，内容聚焦 CDB 数据向 OA 格式迁移这一常见场景，可作为旧 PDK 在新平台复用的参考资料。压缩包内为 1 个 PDF 文件，大小约 697KB，篇幅集中，便于按主题查阅。文档围绕 cdb2oa 转换流程、Conversion Toolbox 使用、cds.lib 路径处理、转换后库的存放位置以及在 Virtuoso 中检查验证展开，并解释“OA executable on CDB data”等常见警告的成因与排查方向，帮助读者理解转换前后的数据组织差异。已有 1557 人学习，适合正在把旧工艺库迁移到 IC617 平台、希望减少兼容性误判并建立基本排错思路的读者参考。

1. 打开 virtuoso 就滚出 ddUpdateLibList 警告：先别急着重装 PDK

升级到 IC617 之后，打开 virtuoso 的第一秒，CIW 窗口就刷出一行黄字：Warning: ddUpdateLibList: It appears that you are trying to run an OA executable on CDB data。手一快的人第一反应是库损坏了，重装 PDK、删掉 cds.lib 重建、换台机器再试，折腾一整天警告照旧。它跟数据损坏没有半点关系，只是说清了一件事：你手上的库还是 CDB 格式，而 IC617 只认 OA，两边根本不是同一种语言。把 CDB 转换为 OA，是 IC514 往上迁移绕不过去的一步，步骤不算多，坑全集中在几个地方：转换入口在哪里、cds.lib 该指哪一份、转完的库往哪放、覆盖前有没有留备份。下面按“看到什么、为什么、怎么修”的顺序，把这些讲清楚。

2. 逐字拆这条 Warning：prop.xx、CDB 与 OA 到底谁在报警

2.1 三段警告原文，一句一句拆

把那条警告完整贴出来，它其实由三段拼成：

Warning: ddUpdateLibList: It appears that you are trying to run an OA executable on CDB data. Library 'ts35mm' contains '/home/xxx/tsmc35mm/prop.xx' which is CDB data. If this is an OA library, this file needs to be removed.

第一句里有两个名词值得停一下。“OA executable”指的不是别的，就是 IC617 目录下那个virtuoso可执行文件。IC617 编译时只链接了 OpenAccess 的数据访问层，二进制里没有读取 CDB 的代码路径。“CDB data”指 cds.lib 里DEFINE进来的库目录。这句话翻译成正常说法：你拿一个只认 OA 的进程，去开一堆 CDB 数据。

第二句点名叫库：Library 'ts35mm' contains .../prop.xx。prop.xx是 CDB 时代每个库根目录下的库级属性文件，记录库的属性、单位、与 techfile 的关联关系。OA 世界里没有这个文件，库级元数据放在lib.defs和 OA 自己的属性容器里。所以工具一看到prop.xx，就能确定这个库是从 CDB 时代留下来的。

第三句是最容易被误读的一句：If this is an OA library, this file needs to be removed。它是条件句，前提是“如果这真的是个 OA 库”。可你手上这个库压根不是 OA 库，删掉prop.xx只是把报警的证据抹掉，数据一个字节都不会变。很多人就是卡在这一句上，删了文件、警告消失、以为修好了，一打开 cellview 还是空的。

提示：ddUpdateLibList是 virtuoso 启动时刷新库列表的动作，读 cds.lib、逐个 DEFINE 登记库、登记时判断格式。它是“尽力而为”的过程，遇到不认识的库会跳过并继续启动，所以打出的是 Warning 不是 Error。你现在看到的警告，正常启动流程会直接忽略；真正麻烦的是那个库在库列表里点开是灰的。

2.2 为什么 IC514 上跑得好好的库，到 IC617 就打不开

版本的分水岭在 IC5141 到 IC6.1 之间。IC5141 时代用的是 CDB 数据模型，库目录里一套prop.xx、techfile.cds、每个 cell 下若干 view 目录，view 里是 CDB 自己的二进制格式。从 IC6.1 系列开始，OpenAccess 成为唯一的数据模型，IC617 属于这个序列，工具链里已经删掉了 CDB 的读写实现。

这就解释了一个很反直觉的现象：同一份 PDK，在旧机器上打开、跑仿真、跑 LVS 全都正常，拷到新机器上什么都没动，就是打不开。不是文件被改坏了，是读它的程序换了一代。旧工艺库能不能在 IC617 上用，取决于它有没有被转换过，跟库本身完整不完整无关。

还有一个连带问题：转换不是“改个后缀”这么简单。CDB 里的 CDF 参数、techfile、symbol 的引脚定义，在 OA 里都有对应的表达方式，转换器要做一次语义映射。映射做得全不全，直接决定转完之后器件能不能正常调用——这也是后面第 4 章那些“转成功了但用不了”问题的来源。

2.3 三分钟判定：手上的库到底属于 CDB 还是 OA

动手转之前先确认对象，不然容易对着一个已经是 OA 的库反复转换，白白浪费时间。不用打开图形界面，命令行两条就够：

# 看库根目录有没有 CDB 的标志性文件 # prop.xx 出现即基本可以判定是 CDB 库；techfile.cds 同理 find /path/to/pdk -maxdepth 3 \( -name "prop.xx" -o -name "techfile.cds" \) -print # 反过来找 OA 的标志：lib.defs 与 data.dm find /path/to/pdk -maxdepth 3 \( -name "lib.defs" -o -name "data.dm" \) -print

第一条命令有输出、第二条没有，就是标准的老 CDB 库；两条都有输出，说明这个目录里混着两种库，得逐个库单独判断，不能一刀切。

顺带看一眼 cds.lib 里到底 DEFINE 了几个库，这决定了后面转换器会处理多少东西：

# 只看有效行，忽略注释和空行 grep -v '^#' /path/to/pdk/cds.lib | grep -v '^$'

每一条DEFINE <库名> <路径>就是转换器要处理的一个对象。如果路径写的是相对路径，转换时的工作目录就必须和 cds.lib 所在目录一致，否则会满屏找不到库——这是第 4 章第一个报错的根源。

3. 图形化走一遍：Conversion Toolbox 把 CDB 库转成 OA

3.1 转换前把 cds.lib 复制到 home，别在原 PDK 目录里动手

转换工具会往磁盘上写东西：生成 lib.defs、生成一堆 OA 库目录、可能还会改写 cds.lib 里的 DEFINE 行。PDK 目录通常挂在共享盘上、属主是别人、权限只读，你在里面点转换，轻则中途报错，重则写了一半留下残缺目录。

所以第一步是把工作区挪到自己有写权限的地方。启动 virtuoso 之后，走Edit → Library Path，这个对话框本质就是 cds.lib 的图形编辑器；再File → Save As，把保存位置选到 home 目录下，确定。这一步做完，你就有了一份属于自己的 cds.lib 副本，后续所有写入都发生在 home 里，原 PDK 一个字节都没动。

# 等价的手工做法，比点菜单更快，效果一样 mkdir -p ~/cdb2oa_work && cd ~/cdb2oa_work cp /path/to/pdk/cds.lib ./cds.lib ls -l ./cds.lib # 确认属主是自己、有写权限

参数上没什么可调的，唯一要留意的是 cds.lib 里的路径类型。如果原来是相对路径，cd到 home 之后这些相对路径就失效了，转换器会报找不到库。稳妥做法是先把 cds.lib 里的DEFINE全部改成绝对路径再转，改完用上面那条grep复核一遍。

注意：不要在 PDK 目录下直接virtuoso &然后原地转换。转换器默认把输出写在与 cds.lib 同级的目录，PDK 目录只读的话，你会在日志里看到一串 permission denied，然后误以为是 PDK 有问题。

3.2 启动 CDB to OpenAccess Translator，路径只认 cds.lib

工作区准备好之后，在 virtuoso 里打开Tools → Conversion Toolbox，在工具列表里选CDB to OpenAccess Translator，弹出的对话框只问一件事：cds.lib 的路径。这里填你 home 下那份副本的完整路径，不要填 PDK 里那份。点 OK 之后就没有交互了，剩下的全靠等。

等待时间长是正常的。转换器要把 cds.lib 里 DEFINE 的每个库、每个 cell、每个 view 逐个读出来再按 OA 格式写回去，一个中等规模的模拟工艺库，几百上千个 cell，跑十几分钟到半小时都算正常范围。这段时间别去动输出目录，也别中途关窗口，中断会留下只转了一半的库，后面比没转还难排查。

如果手上不止一个库要转，或者要批量处理多个 PDK，图形界面就不合适了，直接上命令行：

# 在独立工作区里跑，输入输出都不碰原 PDK cd ~/cdb2oa_work # -cdslib 指定输入库列表；-log 把全过程写进文件，出问题靠它定位 cdb2oa -cdslib ./cds.lib -log ./cdb2oa.log 2>&1 | tee ./cdb2oa.console # 退出码为 0 才算跑完；非 0 就去 log 里搜 error echo "exit=$?"

参数说明：-cdslib是必须的，指向那份库列表，转换器据此知道要处理哪些库；-log把每个 cell 的处理过程和报错都落到文件里，是排查时的唯一依据；tee同时把输出留在屏幕上，方便你盯着看它是不是卡住了。不同版本的参数名可能有出入，敲之前先跑一次cdb2oa -help看清楚，别照着网上抄来的写法硬套。

3.3 转换结果怎么验，怎么回填到原 PDK

转换跑完之后，home 目录下会多出两样东西：一套 OA 格式的库目录，以及一个 lib.defs。先别急着覆盖原库，验三件事。

第一，cell 数量对不对。用ls | wc -l对比新旧目录的条目数，差太多说明中途出过问题。第二，lib.defs 里的路径是不是你期望的绝对路径，如果是转换时临时生成的相对路径，回填之后会失效。第三，随便挑一个器件，在 virtuoso 里打开它的 symbol 和 layout，看引脚、看 CDF 参数是否还在——这一步比数文件数量有用得多。

验完再回填。原文的做法是“原来的先删掉后再复制进去”，我建议改成先改名再复制，改名就是后悔药，删了就没有了：

# 1) 原库改名备份，不删 mv /path/to/pdk/ts35mm /path/to/pdk/ts35mm.cdb.bak # 2) 把转换好的 OA 库复制回去 cp -r ~/cdb2oa_work/ts35mm /path/to/pdk/ts35mm # 3) 核对两边 cell 数量，数字对不上就停下来查 log ls /path/to/pdk/ts35mm.cdb.bak | wc -l ls /path/to/pdk/ts35mm | wc -l

回填完成后，cd进 PDK 目录重新virtuoso &。这时候如果警告还在，大概率不是转换失败，而是你启动时读的还是另一份 cds.lib——virtuoso 读的是当前工作目录或环境变量指定的那份，不是你想当然的那份，这是第 5 章会展开的一个坑。

3.4 没有图形界面时：命令行 cdb2oa 的批处理写法

远程机器、无显示环境、要一次转好几个 PDK，这几种情况图形工具都使不上，得靠命令行。写个小脚本把重复动作收进去，比手敲可靠：

#!/bin/bash # 批量转换：每个 PDK 一个独立工作区，互不污染 set -e # 任何一步失败就停，别带着错误往下跑 PDK_LIST=("/path/to/pdk_a" "/path/to/pdk_b") for pdk in "${PDK_LIST[@]}"; do work=~/cdb2oa_work/$(basename "$pdk") mkdir -p "$work" cp "$pdk/cds.lib" "$work/cds.lib" # 统一改成绝对路径，避免工作目录变化导致找不到库 sed -i "s#^DEFINE \(\S*\) \./#DEFINE \1 $pdk/#" "$work/cds.lib" cdb2oa -cdslib "$work/cds.lib" -log "$work/cdb2oa.log" > "$work/console.out" 2>&1 echo "$(basename "$pdk") exit=$?" done

set -e是为了让脚本在某个 PDK 转换失败时立刻停下，而不是继续把后面几个也带着错误跑完。sed那一行把相对路径补成绝对路径，是批量场景最容易漏的一步。每个 PDK 单独一个工作区，是为了出问题时能一眼看出是哪个库的日志。跑完之后逐个看cdb2oa.log末尾有没有 error，别只看 console 最后一行。

4. 转换报错与转换后异常：五类高频问题的定位顺序

4.1 Library not found：lib.defs 生成了，路径却是死的

转换顺利跑完、lib.defs 也在，重启 virtuoso 之后库列表里那个库还是灰的，点开提示 library not found。九成是路径问题：cds.lib 里的DEFINE写的是相对路径，转换时的工作目录和启动 virtuoso 时的工作目录不是同一个，同一个相对路径解析出两个结果。

定位方法很直接，把 cds.lib 和 lib.defs 里的路径都打出来对照：

# 看库列表里登记的路径 grep -v '^#' ~/cdb2oa_work/cds.lib | grep DEFINE # 看 OA 侧 lib.defs 登记的路径 grep -E 'DEFINE|ASSIGN' ~/cdb2oa_work/lib.defs | head -20

两边的路径前缀必须一致且真实存在。修复方式是把 cds.lib 里的DEFINE全部改成绝对路径，然后重启 virtuoso 让它重新登记一次库列表。改完之后用ls -d <路径>逐条验证目录存在，别只看文字像不像。

4.2 器件 symbol 空白、CDF 参数丢失：转换只做了一半

库能打开了，器件也能拖出来，但 symbol 是个空框，或者 CDF 里的 W、L、M 这些参数全没了，仿真根本跑不起来。这类现象最容易被误判成“转换工具不行”，实际上多半是转换过程中途出过问题，或者转换器跳过了某些 view。

先翻日志找跳过记录：

# 找被跳过的 cell/view，以及转换器给出的原因 grep -iE "skip|warn|error|fail" ~/cdb2oa_work/cdb2oa.log | head -50

如果日志里出现大量 skip，通常和源库本身有关：某些 cell 的 view 类型不被支持、CDF 数据依赖外部文件、techfile 没有一并转换。解决顺序是先确认 techfile 转过来了（OA 库根目录应能看到技术文件相关条目），再对个别缺失的 cell 单独重转一次。CDF 参数丢失还有一种可能：转换时只转了库数据没转 CDF，需要确认转换选项里 CDF 迁移是开着的。

提示：判断“转没转全”最可靠的办法不是数文件，而是拿三五个关键器件逐个打开 symbol、layout、看 CDF 表单。抽样验证比全量检查快得多，也更容易发现问题。

4.3 Permission denied 与 No space left：两个最容易被忽略的前置条件

转换跑到一半突然停住，日志末尾一串Permission denied，或者更隐蔽的No space left on device。前者是输出目录没有写权限——常见于直接在 PDK 共享目录里点转换，或者 home 配额已满。后者是磁盘空间不够，OA 格式通常比 CDB 占更多空间，一个几百 MB 的 CDB 库转出来上 GB 不奇怪。

# 转换前先看一眼空间和权限，比转一半失败再回头查省事 df -h ~/cdb2oa_work test -w ~/cdb2oa_work && echo "可写" || echo "不可写" # 转完之后找大小异常（明显偏小）的库目录，往往就是被截断的那个 du -sh ~/cdb2oa_work/*/ | sort -h | head

空间不足导致的失败有个特点：转换器不一定报错退出，可能只是某个库目录写到一半就停了，日志里看到最后一行停在一个 cell 上。这种残缺库直接删掉重转，不要试图修补。

4.4 转换卡在同一行日志：怎么判断是卡死还是慢

日志停在同一个 cell 上十几分钟不动，很容易让人以为进程挂了，一 Ctrl+C 就前功尽弃。判断方法很简单，看输出目录还在不在长：

# 隔 30 秒看两次，目录大小或文件数在变就是还在干活 du -sh ~/cdb2oa_work/ts35mm sleep 30 du -sh ~/cdb2oa_work/ts35mm # 直接看进程状态，R/S 表示还在跑，Z 才是真死 ps -o pid,stat,etime,cmd -C cdb2oa

etime是已运行时长，配合目录增长一起看基本不会误判。确实卡住的情况通常和某个超大 layout view 或损坏的 CDB 文件有关，这时候从日志里找出最后处理的那个 cell，单独隔离它再重跑一次，能省下整库重转的时间。

4.5 一个 cds.lib 里混着 CDB 和 OA 库

迁移做到一半最容易出现这种局面：一部分库已经是 OA 了，另一部分还是 CDB，全挂在同一个 cds.lib 下。这时候转换器会把已经是 OA 的库也扫一遍，报一堆格式不匹配的错，或者转换结果里新旧库混在一起，路径互相覆盖。

处理办法是先分类再转换，别一把梭：

# 按库名逐个判断格式，输出 CDB / OA 两列清单 for lib in $(grep -v '^#' cds.lib | awk '/DEFINE/{print $2" "$3}'); do name=$(echo "$lib" | awk '{print $1}') path=$(echo "$lib" | awk '{print $2}') if [ -f "$path/prop.xx" ]; then echo "CDB $name $path" elif [ -f "$path/lib.defs" ]; then echo "OA $name $path" else echo "UNKNOWN $name $path"; fi done

拿到清单之后，把 CDB 的那几条单独抽出来做成一份临时 cds.lib 去转换，OA 的原样保留。转换完成再用新路径替换回主 cds.lib。这样每一步的输入都是干净的，出问题也容易定位到具体某个库。

5. 避坑清单：五个让我白干半天的细节

5.1 删掉 prop.xx 让警告消失，以为转好了

现象：把库目录下的prop.xx删掉，重启 virtuoso，那条 ddUpdateLibList 警告真的不见了，于是认为问题解决。结果一打开 cellview，里面是空的，或者库列表里点进去什么都没有。

原因：prop.xx只是 CDB 库的一个标志文件，删掉它等于把报警器拆了，库里的数据仍然是 CDB 二进制，IC617 依然读不了。警告消失只是因为工具不再认为它是 CDB 库，改成了“认不出来但也不吭声”。

解决：把删掉的文件从备份恢复回来，老老实实走转换流程。判断有没有真正修好，标准只有一个——能不能正常打开 cellview 并看到完整内容，警告消没消失不算数。

5.2 直接在只读的 PDK 目录里点转换

现象：转换工具点了 OK，进度条走一点就停，日志里满屏Permission denied，或者转换完在 home 里找不到任何输出。

原因：转换器默认把 OA 库和 lib.defs 写在与 cds.lib 同级的目录。PDK 目录通常属主是别人、权限只读，写入直接失败。更麻烦的是有些转换器在写失败时不会立刻退出，只是跳过继续，最后给你一个看起来“跑完了”的假象。

解决：先cp cds.lib ~/cdb2oa_work/，在 home 里转换，转完再复制回 PDK。转换前用test -w确认输出目录可写，这一步花不了三秒钟。

5.3 转换完直接覆盖原库，没留备份

现象：转换后的库看起来有点问题，想退回原状，发现原库已经被rm -rf删掉了，只能重新找 PDK 安装包。

原因：网上流传的步骤里写的是“原来的先删掉后再复制进去”，照着做就等于把唯一的原始数据销毁了。转换本身是有损操作，映射做不到百分之百，出了问题没有回退路径。

解决：永远用改名代替删除。mv 原库 原库.cdb.bak，验证新库一切正常之后再考虑清理备份，而且至少保留到项目跑通一轮完整流程之后。硬盘空间不够的时候，备份可以压成 tar，但别省这一步。

5.4 照着cdb2oa -i input.cdb -o output.oa敲命令

现象：命令行一敲就报参数错误，或者干脆没反应，反复怀疑是转换器没装好。

原因：-i、-o这种写法在不少网文里出现，看起来很像通用转换工具的命名习惯，但转换器实际操作的对象是库列表而不是单个文件，它的输入是 cds.lib，输出是目录，不是一对一文件转换。参数名对不上，自然跑不起来。

解决：先跑cdb2oa -help看清自己这个版本支持哪些参数，按-cdslib这类以库列表为输入的方式调用。版本之间参数会有差异，以本机 help 输出为准，不要照抄。

5.5 转换后没重开 virtuoso，看到旧警告以为失败

现象：转换跑完，回填完成，切回那个开着的 virtuoso 窗口，警告还在，于是判定转换失败，又重来一遍。

原因：库列表是在 virtuoso 启动时读取并登记的，进程运行期间不会自动重扫。你看到的警告是启动那一刻的快照，跟磁盘上现在的状态已经没关系了。

解决：任何库层面的变更之后，都完整退出 virtuoso 再重新启动。确认的方式是看 CIW 启动日志里还打不打这条 Warning，而不是看那个没关掉的旧窗口。

6. 快速定位这类问题的三步验证法

前四章讲的都是具体故障，实际操作里最耗时间的往往不是修，而是先判断这次是哪一类问题。我现在固定走三步，基本能在几分钟内把范围缩小到某一个环节。

第一步，确认格式。一条find就能分清是 CDB 还是 OA，别靠猜：

# 一眼看出库目录属于哪一代：有 prop.xx 就是 CDB，有 lib.defs 就是 OA lib=/path/to/pdk/ts35mm [ -f "$lib/prop.xx" ] && echo "CDB 库，需要转换" [ -f "$lib/lib.defs" ] && echo "OA 库，不需要转换"

第二步，确认路径。库打不开的时候，绝大多数问题出在“文件是对的，但你指错了地方”。把 cds.lib 里实际生效的DEFINE打出来，逐条ls一遍确认目录存在，再看启动 virtuoso 时的工作目录是不是你以为的那个。这一步能解决掉一半以上的 library not found。

第三步，确认内容。格式对、路径对，但器件用不了，就去日志里找 skip 和 error，再抽样打开两三个关键器件的 symbol 与 CDF 表单验证。

三步之外还有一个习惯值得养成：把每次转换的cdb2oa.log和当时的 cds.lib 一起归档，目录名带上日期。工艺库迁移这种事，同一个 PDK 往往要在不同机器上重复好几遍，有一份留底的日志，下次遇到同样的警告，翻记录比重新排查快十倍。

这份迁移排查清单我按“现象先对上、再查格式、最后看内容”的顺序整理好了，图形化和命令行两条路径都在里面，遇到 ddUpdateLibList 这类警告可以直接对照着走一遍，不必再从零摸索。

从那以后，我每次碰工艺库迁移，都会先把 cds.lib 复制到自己的目录、把原库改名备份、再开转换工具，这三个动作一次不落。绕过的弯路告诉我，真正浪费时间的从来不是转换本身，而是没留退路的那一次覆盖。希望帮到你。

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