CDL网表导入导出与Virtuoso LVS实战：高频翻车点排查

简介：这是一份面向数字电路测试与EDA初学者的CDL电路描述语言教学PPT，围绕C17基准电路讲解如何用CDL描述电路结构、连接关系与逻辑功能，适合需要掌握结构化电路建模与仿真验证的读者。包体为1个PPT演示文稿，压缩包大小仅196KB，内容精炼，便于快速通读。已有758人学习浏览。内容覆盖CDL语法规则，包含函数/连接语句、说明语句、继续语句三类；逐一讲解AND、OR、NAND、NOR、XOR、NOT、FOUT、IN、OUT、VCC、GND及END语句的书写格式，并通过C17电路给出从IN到END的完整描述实例；还介绍了日本奈良大学用C语言编写的CDL编译器流程、编译输出与内部电路表结构，说明元素表ELST中name、type、nfi、fil、nfo、fol等字段如何索引前驱后继关系。按此学习可掌握CDL语法要点、读懂电路描述源码并理解编译器生成内部结构表的机制，为后续电路仿真与测试向量生成打基础。

1. 电路描述语言CDL：版图连通性的文本地基，值得你花一小时彻底搞懂

模拟版图工程师多半经历过这一幕：版图画完了，LVS跑到一半报“instance missing”，打开对比文件一看，问题根本不在版图，出在导入的CDL网表少了一整段子电路。CDL（Circuit Description Language）就是那张用来描述电路连接关系的文本网表，Cadence Virtuoso 工具链对它的依赖贯穿原理图导出、版图导入与LVS比对全流程。把原理图“翻译”成 CDL、再把外部 CDL 导进 Virtuoso，是模拟后端绕不开的一步。这篇内容想解决的正是“CDL到底怎么写、Virtuoso导入CDL文件要配哪些参数、哪些位置最容易翻车”。适合模拟IC设计工程师、版图工程师，也适合刚接触 PDK 与LVS流程的研究生。

2. CDL网表的结构与选型：为什么仿真网表不能直接当LVS输入

2.1 从一段最小CDL网表看懂整体写法

CDL 本质上是一份纯文本网表，不具备图形界面，也没有编译过程。工具拿到它以后按行解析，遇到*开头的行当作注释，遇到.SUBCKT开始读取一个子电路，遇到.ENDS结束这个子电路。下面是一个最小反相器例子，我在后端培训时要讲CDL格式，最喜欢拿它开场：

* cdl file for INV_1X .SUBCKT INV_1X VDD GND IN OUT MP0 OUT IN VDD VDD pch W=1.2u L=0.6u M=1 MN0 OUT IN GND GND nch W=0.6u L=0.6u M=1 .ENDS INV_1X

第一行的*是注释；.SUBCKT INV_1X VDD GND IN OUT声明模块名是 INV_1X，四个端口按顺序写，顺序本身是有意义的，后面导入工具会拿这个顺序去匹配 symbol pin；MP0、MN0 两行是器件实例行，M 开头代表 MOS 管，后面依次是实例名、漏端、栅端、源端、衬底、model 名、参数；最后.ENDS收尾。注意这里漏端和源端哪个在前，不同工艺库习惯不完全一样，但CDL里位置一旦写错，LVS会把源漏认反，那就不只是翻车了，是直接全盘重来。

CDL 里的参数单位通常用u、n、p、f这种缩写字尾，W=1.2u就是 1.2 微米。这里有一个容易忽视的细节：CDL 本身不做单位换算，它只是把数值传给下游工具。R、C 、L 等器件也遵循同样的行格式，只是前缀不同，R 开头是电阻，C 开头是电容，X 开头是子电路调用。理解了这个结构，再看复杂的 CDL 文件就不会被几百行的网表吓住，无非是多个.SUBCKT块嵌套。

2.2 CDL与SPICE、Verilog网表的差异：用在哪一步最合适

不少新手会把 CDL 和 SPICE 网表混为一谈，实际上它们服务于不同阶段，文本长得像但用途差别很大。SPICE 网表服务的是仿真，里面可以有.TRAN、.DC、.MODEL、激励源和测量语句，工具拿到它要算波形；Verilog 门级网表服务的是数字后端，里面是标准单元实例和 wire 连接；CDL 服务的是版图验证，它只关心拓扑、器件尺寸和层级关系。

我遇到过团队里有人直接把 Hspice 仿真网表拿去跑 LVS，结果工具把.OPTIONS、.IC当成非法语句直接跳过，最后比对出的缺失一大堆。原因是仿真网表里那些“控制类”语句对 LVS 工具毫无意义，反而干扰解析。所以各代工厂 PDK 都会在 LVS 目录下单独提供 CDL 版本网表，专业做法是跑 LVS 用 CDL 专用输出，仿真用 SPICE 网表，两个文件并行维护。

2.3 CDL命名习惯：器件前缀、端口大小写与单位缩写

CDL 文件有一套约定俗成的命名规则。实例名前缀和器件类型强相关，M 对应 MOS、B 对应 BJT、D 对应二极管、R 对应电阻、C 对应电容、L 对应电感、X 对应子电路引用。子电路引用行格外重要，例如XT1 A B C subckt_name，前面三个节点是外部连接，最后一个名字是子电路模块名。解析工具看到 X 开头，就知道要去文件里找同名.SUBCKT。

大小写在 Virtuoso 默认配置里是敏感的。VDD和vdd会被当成两个不同的节点，这个问题在高版本工具里可以通过-case allUpper或-case preserve这类开关控制，但不能默认依赖它，导入前先确认文件里的大小写风格是否统一。单位缩写方面，CDL 一般只接受 ASCII 字符，1u能正确解析，1µ这种带希腊字母的写法很容易乱码。如果从 Windows 环境弄来的 CDL 文件，还要注意行尾是 CRLF 还是 LF，Virtuoso 在 Linux 上解析 CRLF 有时会报奇怪的错误，先dos2unix处理一下更踏实。这些规则看似琐碎，却是后面导入失败最常指向的根因。

3. 从Virtuoso导出CDL：命令行批处理与cdl.out配置

3.1 导出前先配好cdl.out：把模型路径固定下来

很多人第一次导出 CDL 是直接在 Schematic Editor 里点 File → Export → CDL，界面操作确实能出文件，但可复现性差。同一个设计今天导出的网表和三个月后导出的网表可能因为环境变量不同产生差异，LVS 时很难追溯。我一般会准备一个 cdl.out 环境文件，把模型路径和必要的 include 信息固定在里面，命令行走一遍，日志留档。

常见的 cdl.out 内容大致如下：

# cdl.out —— CDL 导出环境文件 simulator=spectre incdir=/foundry/pdk/models/spectre include /foundry/pdk/models/spectre/nch.scs section=cdl include /foundry/pdk/models/spectre/pch.scs section=cdl

simulator=spectre告诉导出器按 Spectre 兼容的语法生成器件语句；incdir是模型文件搜索路径；include加section=cdl表示只读取模型文件里标注为 CDL 的片段，而不是把整个模型定义都倒进来。PDK 厂商通常会在模型文件里用* SECTION=cdl这样的注释区分段落，导出工具只关心这一段，因为 LVS 不需要管模型参数细节，只需要知道这个 model 叫nch、pch，能对上库里的 pcell 就行。

这一步不配置会出现什么现象？导出本身不报错，生成的 CDL 里 model 名变成空字符串，等导入 Virtuoso 时器件映射全部失败。很多工程师在导入这一步花一整天排查，最后发现是导出环境文件没配好，源头就脏了。

3.2 用si -batch完成导出：一条命令走完整个流程

真正跑导出时，我不建议每次开 GUI。命令行方式适合回归、适合脚本化，也适合把多个 cell 一次性导出。不同 Cadence 版本的si工具参数略有差异，下面是我常用的写法，新版本基本兼容，老版本可能需要去掉个别开关。

cd $EDA_PROJ/lvs si -batch \ -cdl \ -library analog_lib \ -cell inv_1x \ -view schematic \ -output /home/icuser/netlists/inv_1x.cdl \ -log /home/icuser/logs/cdl_export.log

-batch表示不启动图形界面，适合服务器环境跑批处理；-cdl让工具进入 CDL 导出模式，有些版本写成-runMode=cdl，作用一样；-library、-cell、-view三个参数指定要导出的对象，明确到具体 cell 的 schematic view。如果不指定-view，工具默认抓当前库里的顶层 view，容易被 symbol view 干扰，导出来的文件可能只有端口没有器件。-output指定输出文件路径，-log保存日志。

参数选型上有一个容易忽略的点：如果设计里有多个 config view 或者 hierarchy 编辑器里打开了多个 cell，最好在命令行里显式列出每个要导出的 cell。批量导出时我会写一个循环，把-cell参数换成变量，日志文件名也按 cell 命名，这样哪个 cell 导失败一目了然。

跑完后立刻看日志，不要直接拿网表去用。日志里出现warning: instance map failed或者unable to open CDF parameter这类信息，说明某个器件属性没有被完整写入 CDL，常见的后果是导出的 CDL 里缺了 W、L 参数，LVS 后面肯定会报尺寸不匹配。

3.3 导出后自检：用文本统计判断网表完整性

导出完成不意味着万事大吉。我的习惯是先做一轮快速的文本级检查，用 grep 统计器件数量，和原理图里的数量对照。

grep -E '^M' inv_1x.cdl | wc -l grep -E '^R' inv_1x.cdl | wc -l grep -E '^C' inv_1x.cdl | wc -l grep -E '^\.SUBCKT' inv_1x.cdl | wc -l

grep -E '^M'匹配以 M 开头的行，统计 MOS 管数量；^R、^C同理；.SUBCKT统计子电路块数量。如果原理图里有 24 个管子，CDL 里只数出 20 个，先别急着怀疑 grep 数据，而是回原理图查查有没有 cell 被 exclude 掉。

常见原因是某些器件所在的子模块被标记成了Do Not Import或者属性里加了simInfo = off，还有的是 CDF 参数里W、L为空导致导出器认为该器件无效。另外要注意 grep 的^M也会匹配到注释行里的 M，但一般注释行以*开头，不会影响结果。这条自检路径虽然简单，但能拦下相当一部分“导出成功但内容不对”的问题。

4. 用Virtuoso导入外部CDL：三处校验点与参数映射

4.1 搞清楚工具边界：CDL In 与 SI 的关系

Virtuoso 导入 CDL 文件是热搜词里最常被搜到的诉求，但很多人一上来就点 “Import→CDL”，然后弹出一个黑漆漆的工具窗口，跑完以后库里多了个 schematic view 就以为成功了。实际上导入工具分两类：一类叫 CDL In，专门处理 CDL 网表；另一类是 SI（Schematic Import），它支持更多网表格式，但 CDL 解析逻辑不完全相同。选哪个取决于你的输入文件是纯 CDL 还是混合了其他格式。

纯 CDL 文件我一般倾向走 CDL In，它对.SUBCKT、.ENDS、M/X 前缀的处理更严格，遇到非法语法给的报错信息更直白。SI 更适合处理已经混入了 SPICE 语句或者需要做语法兼容的网表，但对 CDL 的某些特殊写法支持反而保守。

命令行工具有的版本叫cdlIn，有的版本通过si -cdlin进入，不同 PDK 提供的入口不一样。最稳妥的办法是先看 PDK 文档里推荐哪个入口，不要自己凭感觉猜。如果你所在的项目组已经有成熟的导入脚本，优先复用脚本而不是新建一条命令，因为环境变量、license、库路径这些因素都已经被前人踩平了。

4.2 导入命令与映射文件：网表里的model名对不上pcell怎么办

导入外部 CDL 时，文件里写的 model 名通常是 foundry 定义的，比如n33、p33，而你的 Virtuoso 库里 pcell 可能叫nch、pch。如果不做映射，工具找不到对应 pcell，生成的 schematic 里器件全变红，属性也丢失。解决办法是准备一个设备映射文件/home/icuser/config/cdl_device.map：

# cdl_device.map —— 网表model名到库内pcell的映射 n33 nch p33 pch rnpo rnpo_2t

每行两列，左边是 CDL 里的 model 名，右边是 Virtuoso 库里的 pcell 名。映射文件匹配时按从左到右逐行查，第一个匹配到的生效。要注意右边 pcell 名必须精确匹配库里的名字，大小写对不上照样失败。映射写好后，导入命令大致如下：

si -cdlin \ -library analog_lib \ -cell inv_1x \ -view schematic \ -netlist /home/icuser/netlists/inv_1x.cdl \ -deviceMapFile /home/icuser/config/cdl_device.map \ -log /home/icuser/logs/cdl_in.log

-library、-cell、-view指定生成的目标库、cell 和视图；-netlist指向要导入的 CDL 文件；-deviceMapFile指向映射文件；-log保存导入日志。第一次跑通后，日志里会列出每个实例映射到的 pcell 名，逐个核对一遍，别偷懒。我见过有工程师映射文件里把n33写成nch_33，工具没报错只是匹配不上，结果所有 n33 器件都变成了 unknown，LVS 直接崩。

4.3 导入后的三处校验：实例数、端口数、层级数

导入完成以后，有三处校验必须做。第一是实例数，把原始 CDL 里的器件行数和生成的 schematic 里 instance 数量对比。第二是端口数，特别是顶层 SUBCKT 的端口，端口的数量、顺序、名字要和 symbol 对齐。第三是层级数，复杂设计里可能有多层.SUBCKT嵌套，导入后每一层应该对应一个 cellview。

实例数可以用文本统计：

grep -E '^M|^R|^C|^X' inv_1x.cdl | wc -l

^M|^R|^C|^X匹配以 M/R/C/X 开头的器件行，wc -l统计总行数。注意 X 开头的子电路调用也会被统计进去，所以这个数字是器件实例加子电路调用的总和，和 schematic 里的 instance 总数对得上才算正常。

端口数直接看.SUBCKT行：

grep '^\.SUBCKT' inv_1x.cdl

输出里每一行都列出了该子电路的端口列表，拿这份列表去对照 schematic 的 pin，重点看顺序。导入工具一般按名字匹配，不会自动给你重新排序，一旦顺序不匹配，上层调用这个 cell 时连错的就是电源和地。

层级数可以通过统计.SUBCKT和.ENDS配对情况来确认，后面避坑章节会专门讲这个问题。校验时我还会在 Virtuoso 里打开生成的 schematic，执行 Check and Save，CIW 窗口里有任何 error 都先解决再继续。跑完 LVS 之前，最好用生成的 schematic 反向再导出一份 CDL，与原始 CDL 做 diff，一致才说明导入链路没有信息丢失。

5. CDL处理避坑：5个高频翻车点与排查路径

5.1 器件批量变红：model名对不上pcell

现象：导入生成的 schematic 里，某类器件全部显示成红色，点开属性发现 model 名是空的或者带unknown字样。原因：CDL 里写的 model 名与库里的 pcell 名不一致，又没有提供有效的 deviceMapFile。解决：先打开导入日志，搜索map或model关键字，看哪些实例映射失败；再检查 cdl_device.map 文件里的左右列是否反了；最后确认 pcell 名在库里真实存在。这三步走完，90% 的批量变红问题都解决了。剩下的情况是 CDF 参数缺失，器件虽然映射成功但 W、L 没导进来，也会显示成红色警告。

5.2 引脚顺序全乱：SUBCKT行就是契约

现象：导入后 schematic 的引脚名字是对的，但顺序和原始网表不一致，调用层一旦使用XA B C D subckt这种位置传参，信号就连错。原因：工具导入时按SUBCKT行端口顺序生成 pin，如果符号库里的 symbol 的 pin 顺序与 CDL 顺序不同，工具默认按名称匹配，匹配不上就按位置硬填，结果就是名字对、顺序错。解决：打开原始 CDL 的.SUBCKT行，把端口顺序记下来，再到 Virtuoso 里手动调整 symbol view 的 pin 顺序。这个操作没有后悔药，改完以后重新 Check and Save，同时把调用层也重新生成一遍，否则调用关系不会自动更新。

5.3 子电路嵌套丢失：SUBCKT与ENDS配对不齐

现象：导入后顶层 schematic 里只有部分电路，底层 cell 完全没生成。原因：CDL 文件里.SUBCKT与.ENDS数量不配对，或者某个子电路块中间缺了.ENDS导致解析器提前截断。解决：先用 grep 统计配对情况。

grep -c '^\.SUBCKT' inv_1x.cdl grep -c '^\.ENDS' inv_1x.cdl

两个数字不一致时，用文本编辑器打开文件，按顺序逐行数括号。常见原因是有人手工编辑 CDL 时删了某个.ENDS，或者合并文件时把两个子电路块黏在了一起。另一个隐蔽原因是文件最后多了空行或者非法字符，可以用tail -20 inv_1x.cdl看结尾是否有残留。把配对修好再重新导入，层级就回来了。

5.4 导入后LVS尺寸差十倍：单位换算没设对

现象：LVS 报告里所有管子 W、L 都偏了 1000 倍，或者差 100 倍，而且规律统一。原因：CDL 里W=2.2u这种带单位后缀的写法可以被正确解析，但有的 CDL 文件为了压缩体积省略了单位，写成W=2.2，工具按默认单位处理，默认单位可能是微米也可能是纳米，不匹配就整体偏移。解决：在导入命令里显式设置单位开关，比如-scale或-sToSI参数，把裸数值乘以或除以 1000 再映射到 CDF 参数。改完以后立刻看一个已知尺寸的器件确认，不要等到 LVS 出报告再回头。还有的 CDL 里把容值写成50f，工具把它当成 50 飞秒而不是 50 飞法，这种情况需要看工具的单位体系，飞法默认单位通常没问题，但皮法和纳法要特别当心。

5.5 特殊字符把节点弄丢：斜杠、反斜杠和星号

现象：导入后某些连线缺失，节点名检查时发现名字和 CDL 里不一样。原因：CDL 节点名里如果带了/或者\，Virtuoso 内部对这些字符的合法性检查很严格，有时会把它换算成合法字符，换算规则不同版本不一样，导致节点名悄悄变化。另一个常见元凶是节点名里带了*号，比如某些网表用BUS<7>*这种写法，CDL 解析器会把*当成注释开头，整行后面内容全被丢弃。解决：在导入前用脚本把节点名里的非法字符替换成下划线或者合法字符。替换时注意全局统一，并在替换完成后 grep 一遍确认没有遗漏。这类问题在顶层节点特别多的大模块里高发，越早清洗越省事。

6. 进阶技巧：用Python清洗CDL，把导入失败率降下来

外部 CDL 文件绝大多数不是工具直接导出的，而是经过人手编辑、脚本拼接、跨平台传送，里面多少会混入一些让 Virtuoso 导入器皱眉的东西。与其在 GUI 里跟 black box 较劲，不如在导入前用脚本来一次确定性清洗。这里分享一个我常年使用的预处理思路：只做文本级替换，不碰拓扑。

#!/usr/bin/env python3 # pre_cdl.py: 对CDL做导入前的文本级清洗 import re import sys src, dst = sys.argv[1], sys.argv[2] with open(src) as f: lines = f.readlines() out = [] for line in lines: if line.lstrip().startswith('*'): out.append(line) continue line = line.replace('\r\n', '\n') line = re.sub(r'\bVDD\b', 'VDD!', line) # 节点名统一命名 line = re.sub(r'\bVSS\b', 'VSS!', line) # 按项目规则替换关键节点 line = line.replace('n33', 'nch') # model名映射 out.append(line) with open(dst, 'w') as f: f.writelines(out) print('preprocess done: %s -> %s' % (src, dst))

第一段先保留所有以*开头的注释行，因为注释行里很可能提到旧节点名，全局替换容易误伤注释内容；第二段统一换行符，Windows 来的 CRLF 转成 LF；第三段用正则做节点名替换；第四段做 model 名映射。执行方式和 Perl 脚本类似：

python3 pre_cdl.py raw.cdl clean.cdl

raw.cdl是原始文件，clean.cdl是清洗后的导入文件。逻辑说明：所有操作都是行级文本处理，不检查电路连通性，所以脚本本身不会引入拓扑错误，但也不会修复.SUBCKT/.ENDS配对。清洗时如果替换次数和预期不符，比如n33只出现了 3 次但网表里明明有 20 个n33器件，说明大小写或者字符串格式有变体，先去检查匹配模式。

这条技巧平时不起眼，但在处理三五万行的大型 CDL 时价值很大。我现在接手任何外部 CDL，第一件事永远是复制原文件、跑一遍清洗脚本、统计替换次数，确认没有异常再导入。版本迁移、工艺库切换这类场景下，CDL 作为“中间语言”的转移能力也要靠这套干净的清洗流程兜底。希望这套思路能帮你在 virtuoso 导入 CDL 文件时少踩几个坑。

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