企业官网建设流程全解析

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 exit

layout 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 的数据库精度：

写脚本的时候我通常不在脑子里做这个换算，而是让脚本自己算，避免手抖：

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(f"layout 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 四条路线的选择对照

4. 切完不算完：切出来的 GDS 必须这样核对

我见过太多"切完直接发出去"的例子，然后在对方那边被发现是空文件、或者 top cell 名字不对、或者层全丢了。核对这一步花不了十分钟，但能挡掉绝大多数尴尬。下面这套检查是我自己固定会跑的。

4.1 五个必查项，一次过一遍

这五项里，我最看重的是第一项和最后一项。第一项出错的后果最严重，因为它会让下游流程静默地跑在错误的顶层上；最后一项是最灵敏的信号，文件大小几乎没有变化，通常意味着 clip 命令没生效、或者-box的坐标不是你以为的那四个数。

4.2 XOR 比对：用几何证明"我什么都没改"

XOR 的思路是：如果切图确实只是原图的一个子集，那么把原图在裁切范围内的部分和切图做异或，结果应该是空的。实际操作里，因为层级的存在，从原图里精确取出"裁切范围内那部分"本身就有一定的工作量，所以务实的做法是抽查关键层。

具体流程是：在 KLayout 里打开原图和切图，把两者放到同一个视图里（可以先把切图的 cell 复制进原图视图），选中原图的某一层和切图的对应层，用布尔 XOR 功能做异或。理想结果是只在裁切边界那一条线上有窄窄的差异带，内部应该干干净净。如果内部出现大片差异，说明切图过程中图形被合并、被简化、或者层号被改了。

我一般会抽查三类层：最底层的扩散/注入层、中间的多晶与金属层、以及最上面的钝化/焊盘层。这三类能覆盖绝大多数"层号错位"和"图形被合并"的问题。

4.3 把切图灌回原验证环境做交叉定位

这一步是专门为"定位式切图"准备的。你有一份完整的 DRC 结果，RVE 里标记了几百个点，现在想聚焦到某个区域。正确做法不是重新跑一遍完整的 DRC，而是：把切图单独跑一遍同一套规则，然后在 RVE 里打开新结果，比对标记点的分布。

这里有一个必须提前接受的事实：LVS 几乎一定会在边界上报错。这不是你切错了，而是切图天生就会截断器件和井区，器件识别必然失败。所以正确的判断方式是"只比 DRC，LVS 只看边界以外"。如果连远离边界的地方都开始报 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 clip+layout 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 这种阶段，这种"顺手"最好一次都不要有。

真要从我个人的经验里挑一条最想说的：切图这件事，脚本比手快重要，记录比脚本重要。一个能跑通的脚本很常见，但三个月后还能说清楚"这块图是从哪份源文件的哪个坐标切出来的、当时的精度是多少、给谁看过"，才是真正省事的能力。我自己的做法是把每次切图都当成一次小型交付来对待，源文件、坐标、版本、用途四样东西一次写全。这样做前几次会觉得啰嗦，等到项目评审有人追问某个局部版图来源的时候，你会发现翻记录比重新切一遍快了不止十倍。