Tapeout 前最后一周最容易被卡住的往往不是 DRC 报了多少个错而是旁边工位的同事走过来问一句能不能把某块区域的版图单独给我一份你手上躺着的是整颗芯片的 GDS几十 GB里面既有第三方的 IP也有不该随便外发的模块整包发出去既不现实也不合适而对方可能只是想把这个 DRC 报错点周围一百微米的范围在 Calibre 里单独打开反复看几眼、跑几个小实验。这时候真正管用的能力只有一个在 Calibre 环境里从完整 GDS 中精确切出指定区域的版图同时保证切出来的几何和原图一比一一致。这篇内容就围绕这件事展开。我会把为什么要切、切之前要想清楚什么、calibredrv 里怎么用 Tcl 精确切、切完怎么验证、以及我自己踩过的那几个坑完整讲一遍。适合的人群很明确做版图的、做 CAD 支撑的、跑物理验证的以及任何需要在 Tapeout 前拿一块局部版图去做 review 的人。不管你之前有没有写过 Calibre 的 Tcl 脚本读完之后都能照着把第一块区域切出来。1. 先想清楚切一块版图到底要解决什么再动手很多人拿到这个需求第一反应是打开工具、框一个矩形、另存为。这个动作本身没错但在按下按钮之前如果不把给谁用、用来干什么想清楚切出来的东西十有八九是要返工的。我在项目上见过太多次这种情况脚本跑了二十分钟结果对方打开一看说这不是我要的那块。1.1 三种典型场景对切图的要求完全不同第一种是交付式切图。你把某一块区域或某个模块的版图交给别人——可能是内部另一个团队可能是 IP 供应商确认问题也可能是外部的合作方做分析。这种场景的核心诉求是保真层号要全、标签要在、层级关系要能对上最好连单位的定义都不能变。因为你不知道对方会用什么工具打开、会拿它跑什么流程任何顺手优化都可能变成对方的噩梦。第二种是局部定位。典型画面是DRC 或 LVS 在某一个坐标点报了一条你怎么看都看不明白的错你想把那个点周围一小片单独提出来在里面反复跑规则、试参数、做对比实验。这种场景诉求是快和可控拍平无所谓只留相关几层也无所谓甚至只关心一层也行关键是要能快速迭代改个框重跑一次不能超过几分钟。第三种是可视化 review。Tapeout 前的评审材料里需要一张局部版图的截图或者需要一张整颗芯片的缩略概览图给人快速定位。这种场景其实不一定要真出 GDS很多时候出一张位图就够了——Calibre DESIGNrev 里如果带位图输出相关的命令有些版本是layout bom一类可以先生成缩略图确认位置比在 GUI 里一层层缩放快得多。这三种场景的差别直接决定了后面脚本里的每一个选项。我一般的做法是交付式切图走最保守的路径宁可文件大一点、层级多一点也不要省那几步定位式切图才允许上各种激进手段。1.2 框一个矩形为什么不是一件小事GDS 这个格式看起来简单实际上有一堆细节会在切图时冒出来。第一个是层级GDS 里的图形不是平铺的一个标准单元可能在几十个地方被引用切图工具要决定是保留这种引用关系还是把被引用到的部分展开。第二个是阵列引用AREF 是 GDS 里表达规则阵列的方式一个阵列跨在边界上处理方式不同会产生完全不同的结果——有的工具把它打散成一堆单独的引用文件里 cell 数量瞬间翻好几倍。第三个是坐标单位。GDS 内部存的是整数单位是数据库单位dbu常见的 0.001 µm 精度意味着 1 µm 等于 1000 个 dbu。而你在版图工具里量出来的坐标绝大多数时候是微米为单位的浮点数。这两个数之间差 1000 倍填错一位就是切到完全不相干的区域去了。第四个是标签和文本GDS 的 TEXT 元素同样带坐标有些切图路径默认不动文本结果就是图形切对了、pin 名字对不上。第五个也是我认为最容易被忽略的边界上的工艺层会被截断。比如一个 N 井跨过了你定的边界切完之后它就只剩一半一个 MOS 管正好卡在边线上切完就只剩半个器件。这在几何上完全正确但会让后续任何依赖器件识别的流程尤其是 LVS直接报一堆错。搞清楚这一点后面那节关于切图像素级正确但 LVS 全红的坑你就能提前躲开了。2. calibredrv 里用 Tcl 精确切出指定区域Calibre 的版图查看器叫 DESIGNrev命令行入口是calibredrv它内置了一个 Tcl 解释器。这意味着所有手工能点的操作理论上都能写成脚本而脚本意味着可复现、可版本管理、可交给别人跑。对于 Tapeout 前这种每一步都要能追溯到的阶段脚本化的价值远大于 GUI 操作带来的那点便利。提示DESIGNrev 的 Tcl 命令在不同 Calibre 版本之间确实有增删和改名。下面给的命令与选项是常见写法正式落地之前先花两分钟用-shell模式敲一遍、或者用对应的help命令确认能省掉一晚上的返工。2.1 批处理模式与交互模式先用后者探路calibredrv常见有几种用法。直接敲calibredrv是打开图形界面calibredrv -a script.tcl是批处理执行一段 Tcl 然后退出这是脚本化的主力calibredrv -shell会进入一个交互式的 Tcl 环境你可以一行一行敲命令立刻看到结果另外还有calibredrv -m a.gds b.gds这类用于合并多个版图的调用方式。我的固定习惯是先在-shell里把命令敲一遍。打开目标文件、查一下 top cell、试着 clip 一次、看一下输出结果整个流程走通了再把这几行命令原样抄进.tcl文件里丢给批处理。多花的那五分钟换来的是不用在深夜盯着一个跑错参数的脚本发呆。2.2 核心三步打开、裁切、另存切图这件事在 calibredrv 里基本就是三行命令的事set src /proj/chip/gds/top.gds set out /proj/chip/gds/clip/top_review.gds set x1 120000 ; set y1 80000 set x2 160000 ; set y2 120000 layout create $src puts topcell [layout topcell] layout clip -box $x1 $y1 $x2 $y2 layout write -new $out exitlayout create既用于新建也用于打开已有的版图文件。layout clip是裁切的核心-box接受四个数顺序是左下角 x、左下角 y、右上角 x、右上角 y。layout write -new把当前内容写成一个新文件——注意是新文件这样不会把源文件覆盖掉。这几行里有三个地方值得专门说。一是puts那句把当前 top cell 名字打印出来看起来很土但它是防止切错文件最便宜的一道保险。你打开了一份被误传的旧版本 GDS脚本照样跑得欢只有这行打印能提醒你。二是-box里的四个数是整数 dbu不是浮点微米下一节专门讲。三是layout write的选项在不同版本里可能叫法不同有的写法需要指定-new有的版本可能直接跟文件名落地前确认一下。2.3 坐标与单位切错位置十次有八次是这里假设你在 Virtuoso 或者 KLayout 里量出来想看的区域是 (123.456, 78.900) 到 (156.789, 110.234)单位微米。直接把这四个数填进-box会怎样工具会理解成 (123, 78) 到 (156, 110) 个 dbu也就是大约 0.12 µm × 0.08 µm 的一个点。你会切出一个空文件而且大概率还会怀疑是工具坏了。换算关系其实很简单假设工艺用的是 0.001 µm 的数据库精度概念数值说明数据库精度0.001 µm常见值也可能是 0.005 µm1 µm 等于多少 dbu10001 / 0.001123.456 µm123456 dbu乘法不是除法边界建议留白5 ~ 20 µm合 5000 ~ 20000 dbu写脚本的时候我通常不在脑子里做这个换算而是让脚本自己算避免手抖PREC 0.001 # µm per dbu必须和源文件的精度一致 def um2dbu(v): return int(round(v / PREC)) x1, y1 um2dbu(123.456), um2dbu(78.900) x2, y2 um2dbu(156.789), um2dbu(110.234) print(flayout clip -box \{x1} {y1} {x2} {y2}\)这里有一个必须提醒的点PREC一定要和源 GDS 的实际精度一致。有些工艺是 0.005 µm有些老库甚至是 0.01 µm。确认方法很简单看 GDS 头的 UNITS 信息或者在 DESIGNrev 里看版图的单位设置。精度搞错了虽然不会差 1000 倍那么离谱但会差几倍切出来的框会明显偏。关于留白我的经验值是四周各留 5 到 20 µm。原因很实际大部分值得单独拎出来看的现象——DRC 报错、密度异常、奇怪的图形交叠——都和周边环境有关贴着报错点切只能看到孤零零一个图形看不出上下文。当然留白也不是越大越好后面第 6 节会讲框开太大可能把相邻的、不该外发的模块一起框进来。2.4 层级保留还是拍平以及顺序上的讲究layout clip处理层级的方式直接决定了下游能不能用。保留层级的好处是文件小、结构清晰、和原图结构一致代价是边界附近的引用可能被拆开而且下游工具必须能正确处理层级。拍平的好处是简单粗暴任何工具打开都是一堆多边形代价是文件可能膨胀几十倍还可能因为图形在边界上重叠而出现自相交。真正需要注意的是操作顺序。一个自然而然的想法是先把整个版图layout flatten拍平再 clip 出我要的那块。这个顺序在小图上没问题在整颗芯片的 GDS 上就是灾难——拍平的瞬间内存就爆了因为拍平是对全图生效的。正确的顺序是先 clip再 flatten先把范围缩小到几百微米见方这时候再拍平内存占用和文件大小都是可以接受的数量级。另外还有一个细节clip 之后的 top cell 名字。有的版本会保留原 top 名有的会生成一个新名字这两种情况我都遇到过。这件事之所以重要是因为下游如果在跑 LVS规则文件里的LAYOUT PRIMARY是写死的。切图后 top 名变了、LAYOUT PRIMARY没跟着改报出来的错会非常难懂。养成习惯切完立刻查一次 top cell 名并记录下来交付的时候一起写给对方。3. 命令行之外的几条备选路线Calibre 的脚本化路径是主力但不是唯一选择。有些场合——比如手上暂时没有 Calibre 环境、或者需要做交叉验证——用别的工具反而更顺手。这一节把几条常见路线摆出来包括它们的适用边界。3.1 DESIGNrev 图形界面一次性任务的最快路径GUI 的价值在于我现在就要看一眼。打开 GDS在 Cells 面板里选中顶层 cell用鼠标拖出需要看的区域注意看状态栏或坐标读数确认范围之后用另存/导出的方式把这块区域写出去。不同版本菜单路径不一样有的在 File 菜单下有的在专门的导出对话框里找不到就直接切到-shell敲命令。GUI 的短板也很明显不可复现。今天框了一个 (120, 80) 到 (160, 120) 的框明天有人问你是按什么坐标切的你只能说大概吧。所以我的原则是GUI 只用来确认识别和取坐标真正执行切图动作一律走脚本。取坐标这件事还有个更靠谱的做法——在 GUI 里量到微米值之后用 2.3 节那段换算函数转一遍把 dbu 写进脚本而不是凭读数记忆。3.2 KLayout免费替补也是最好用的交叉验证工具KLayout 免费、跨平台、脚本能力强做切图和做比对都很合适。它的 Ruby 脚本接口用来做按框裁切思路是读入源版图构造一个代表裁切框的区域把每一层图形与这个区域求交集再写进一个新版图。骨架大概是这样ly RBA::Layout.new ly.read(top.gds) box RBA::Box.new(120000, 80000, 160000, 120000) clip RBA::Region.new(box) out RBA::Layout.new out.dbu ly.dbu # 关键单位必须继承否则整体缩放错 top out.create_cell(CLIP_TOP) (0..ly.layers - 1).each do |li| next unless ly.is_valid_layer?(li) info ly.get_info(li) next if info.is_text? # 文本单独处理 r RBA::Region.new(ly.begin_shapes_rec(li)) r r clip next if r.is_empty? oli out.layer(info.layer, info.datatype) top.shapes(oli).insert(r) end out.write(clip.gds)这段脚本里有两点值得强调。第一是out.dbu ly.dbu这一行很多人第一次写会漏掉结果切出来的图形整体比例不对看着像是被缩放了几倍——本质就是新版图用了默认精度而源版图是另一个精度。第二是info.is_text?那行跳过文本元素需要单独写处理逻辑如果你切图的目的是看文字比如 pin 名这一步不能省。KLayout 真正无可替代的地方是布尔运算和 XOR 比对。把原图和切图放进同一个视图对关心的层做异或理想结果是除了边界外那一圈差异为零。这是目前我手上最省事的证明我没改图形的手段。3.3 源头在 Virtuoso 的场合为什么不推荐从源头切如果这块版图本来就是在 Virtuoso 里画的很自然的想法是从源头 Stream Out 的时候就限制输出范围一次到位。这条路能不能走通取决于你的版本提供了什么选项而且有几个绕不开的麻烦Stream Out 本身慢占 license对层级和 cluster 的处理方式不一定符合你的预期而且还要先保证那个 library 是可读的、view 是最新的。我自己的选择是源头全量导出切图交给 calibredrv。理由有三条。一是职责清晰源头工具只负责把设计完整地导出来切图是后处理任何一次参数调整都不用回源头重跑。二是可复现脚本加坐标就是全部信息别人拿着脚本就能复现出同一个文件。三是保真度高calibredrv 对 GDS 的处理足够底层不会在你不知道的地方做优化。3.4 四条路线的选择对照路线适用场景主要优点主要风险calibredrv Tcl批处理、交付式切图保真、可复现、可版本管理依赖 Calibre license命令有版本差异calibredrv GUI一次性查看、取坐标直观、上手快不可复现容易记错坐标KLayout 脚本无 Calibre 环境、交叉验证免费、XOR 方便大图性能一般API 随版本变动Virtuoso Stream Out源头就在 Virtuoso不用额外工具慢、选项受版本限制、处理方式不可控4. 切完不算完切出来的 GDS 必须这样核对我见过太多切完直接发出去的例子然后在对方那边被发现是空文件、或者 top cell 名字不对、或者层全丢了。核对这一步花不了十分钟但能挡掉绝大多数尴尬。下面这套检查是我自己固定会跑的。4.1 五个必查项一次过一遍检查项怎么查期望结果top cell 名layout topcell或 GUI 查看与预期一致且下游LAYOUT PRIMARY能对上范围 bboxGUI 量取或命令查询略大于你给的框因为边界图形层列表layout lpp一类命令与源图在裁切范围内的层一致cell 数量layout hierarchy统计不应比源图多出离谱的量文件大小ls -lh明显小于源图若几乎相当说明根本没切成功这五项里我最看重的是第一项和最后一项。第一项出错的后果最严重因为它会让下游流程静默地跑在错误的顶层上最后一项是最灵敏的信号文件大小几乎没有变化通常意味着 clip 命令没生效、或者-box的坐标不是你以为的那四个数。4.2 XOR 比对用几何证明我什么都没改XOR 的思路是如果切图确实只是原图的一个子集那么把原图在裁切范围内的部分和切图做异或结果应该是空的。实际操作里因为层级的存在从原图里精确取出裁切范围内那部分本身就有一定的工作量所以务实的做法是抽查关键层。具体流程是在 KLayout 里打开原图和切图把两者放到同一个视图里可以先把切图的 cell 复制进原图视图选中原图的某一层和切图的对应层用布尔 XOR 功能做异或。理想结果是只在裁切边界那一条线上有窄窄的差异带内部应该干干净净。如果内部出现大片差异说明切图过程中图形被合并、被简化、或者层号被改了。我一般会抽查三类层最底层的扩散/注入层、中间的多晶与金属层、以及最上面的钝化/焊盘层。这三类能覆盖绝大多数层号错位和图形被合并的问题。4.3 把切图灌回原验证环境做交叉定位这一步是专门为定位式切图准备的。你有一份完整的 DRC 结果RVE 里标记了几百个点现在想聚焦到某个区域。正确做法不是重新跑一遍完整的 DRC而是把切图单独跑一遍同一套规则然后在 RVE 里打开新结果比对标记点的分布。这里有一个必须提前接受的事实LVS 几乎一定会在边界上报错。这不是你切错了而是切图天生就会截断器件和井区器件识别必然失败。所以正确的判断方式是只比 DRCLVS 只看边界以外。如果连远离边界的地方都开始报 LVS 错那才是切图过程真的改动了什么。我在做这类比对时会先在原图结果里统计落在目标区域内的 marker 数量记在纸上切图跑完之后拿两个数对比。5. 踩过的坑切图过程中最容易翻车的几件事下面这几个坑我或者我身边的人至少各踩过一次写出来是为了让你少走一遍。注意这几个问题的共同特点工具不会报错文件正常生成只有到下游才暴露。5.1 边界切断器件导致 LVS 全红这是最高频的一个。表现是切图在几何上完全正确XOR 也过了但拿它跑 LVS 得到满屏错误。原因前面提过MOS 管被边界切成两半识别不出井区被截断衬底连接丢失保护环断成开口闩锁相关检查失效。应对方式有三条。第一定框的时候避开完整的器件优先沿着模块边界、保护环外沿、或者电源走线的空隙切宁可框大一点。第二明确切图的用途切图是用来看和定位的不是用来跑完整 LVS 的。如果确实需要对某块区域跑 LVS正确做法是把那个模块整块导出而不是从全图里切矩形。第三如果非要在切图上跑 LVS 排查局部问题就把边界附近一定范围内的报错全部标注为边界假错只看远离边界的部分。5.2 层号没带过去对方打开一片空白GDS 里的层是 (layer, datatype) 这样一对数字本身不带名字。你在自己的环境里之所以能看到 POLY、M1、M2 这些名字是因为加载了 layer map 文件。把切图交给别人如果不带 map对方打开看到的就只是 (1/0)、(2/0)、(3/0) 这类数字组合完全不知道哪层是哪层如果对方的工具颜色方案是默认的甚至可能出现看起来一片空白的效果——因为图形都落在暗色层上。所以交付的时候一定把配套的 layer map 一起给。反过来也要注意如果源文件是 OASIS 格式层是可以带名字的一旦转成 GDS名字就丢了只剩数字这时候 layer map 就更不能少。5.3 阵列被裁之后的表现很反直觉规则阵列在边界上被裁不同工具的处理差异很大。有的会把整个阵列打散成一个个单独的引用结果就是 cell 数量暴涨、文件反而变大有的会保留阵列但只保留一部分元素看起来像是图形缺了一块。判断方法很直接切图前后统计一下 cell 数量如果翻了好几倍基本就是阵列被打散了。处理思路是接受它或者提前把阵列局部展开。我更倾向于接受——因为阵列被打散只影响文件结构和大小不影响几何正确性而为了好看去手工干预反而引入了改动几何的风险。真要控制文件大小可以在切完之后用 KLayout 重新写一遍文件未引用的空 cell 会被顺手清掉。5.4 文本与标签的丢失或漂移前面提过一次这里再说透一点。文本元素在 GDS 里是独立一类很多切图路径默认只处理多边形不处理文本。结果是 pin 名字、标注、注释全都不见了或者坐标漂移到了切图之外。这种问题特别隐蔽因为图形看起来完全正常只有当你需要核对某个 net 名字的时候才会发现。检查方法很土但有效单独把文本层显示出来和原图并排看。如果你是交付式切图我建议把文本一起切出来并且单独验一遍因为文本丢失在现场解释起来非常费劲。5.5 大文件的内存与时间代价整颗芯片的 GDS 打开一次内存占用是实打实的。有几个经验值得记住只做 clip 和 write不要顺手做全图 flatten、全图 merge 这类操作-shell模式下可以一边敲一边观察进程的内存增长比批处理模式下盲跑安全在服务器上跑而不是本机同时留意一下进程的资源限制有的集群默认 ulimit 会卡住大内存进程。另外如果你需要切的区域不止一块比如要切十几个窗口做评审不要在同一个会话里反复打开同一个大文件。更好的做法是写一个脚本一次layout create之后连续做多次layout cliplayout write但要注意每次 clip 都会改变当前内存里的内容所以正确的模式是每切一块之前重新打开一次源文件。这看起来效率低但实际上比改坏了之后重来划算得多。6. Tapeout 前 GDS Review 的一份切图清单这一节全是能直接抄的东西。我把自己每次切图都会走的流程整理成脚本模板和检查清单你可以按项目的实际情况改。6.1 可直接改用的脚本模板#!/bin/bash # clip_one.sh usage: ./clip_one.sh x1 y1 x2 y2 单位dbu SRC/proj/chip/gds/top.gds OUTDIR/proj/chip/gds/clip/$(date %Y%m%d) mkdir -p $OUTDIR OUT$OUTDIR/top_clip_${1}_${2}_${3}_${4}.gds cat /tmp/clip_$$.tcl EOF layout create $SRC puts SRC topcell [layout topcell] layout clip -box $1 $2 $3 $4 layout write -new $OUT exit EOF calibredrv -a /tmp/clip_$$.tcl || exit 1 rm -f /tmp/clip_$$.tcl md5sum $SRC | awk {print $1} $OUT.src.md5 ls -lh $SRC $OUT这个脚本有三个我自己很在意的设计。输出目录带日期避免不同轮次的切图互相覆盖。输出文件名里带了四个坐标三个月后有人问你这块是从哪切的看文件名就知道。源文件的 md5 单独存一份这是为了在任何时候都能回答我到底是从哪个版本的源切的——在 Tapeout 这种节点上这个问题一定会被问到。6.2 命名、目录与配套说明命名规范这件事做的时候觉得麻烦用的时候觉得值。我的格式是chip_module_x1_y1_x2_y2_revision.gds目录按日期分层同一天的不同轮次再按用途分子目录比如review_drc、ip_handoff、debug_well。每个切图旁边放一个README.md内容固定这几项源 GDS 的完整路径与 md5、裁切框的微米值和 dbu 值两个都写因为不同人习惯不同、所用 Calibre 版本、配套 layer map 的文件名、切图时间、以及一句这块是给谁看的、看什么。最后这一句看起来多余但实际上它是最有用的一项。一周之后你自己都记不清当时为什么切了这块。6.3 发出去之前的最后一分钟自检源 GDS 的 md5 已经记录了吗裁切框的 µm 与 dbu 两种表示都写进 README 了吗切图的 top cell 名确认过了吗下游LAYOUT PRIMARY能对上吗层列表和源图在裁切范围内对得上吗在 KLayout 里打开看过一眼吗不是一片空白吧文件大小合理吗是否明显小于源图layer map 一起打包了吗框有没有开太大把相邻的、不该外发的模块一起框进来了最后这一条我想多说一句。切图这个动作本身是有边界属性的你框的框越大带进去的无关信息越多。交付式的切图框应该贴着需求走四周留白控制在必要范围内就够。我见过因为顺手多留一点把隔壁模块的特殊结构一起发出去的情况虽然没造成什么后果但在 Tapeout 这种阶段这种顺手最好一次都不要有。真要从我个人的经验里挑一条最想说的切图这件事脚本比手快重要记录比脚本重要。一个能跑通的脚本很常见但三个月后还能说清楚这块图是从哪份源文件的哪个坐标切出来的、当时的精度是多少、给谁看过才是真正省事的能力。我自己的做法是把每次切图都当成一次小型交付来对待源文件、坐标、版本、用途四样东西一次写全。这样做前几次会觉得啰嗦等到项目评审有人追问某个局部版图来源的时候你会发现翻记录比重新切一遍快了不止十倍。