企业官网建设流程全解析

在3D IC设计已经不算新闻的今天，物理验证工程师手里的活儿反而变得越来越不那么“物理”了。以前我们拿到一个GDS，所有DRC、LVS都在一个二维平面上完成，图层、边界、连接关系清清楚楚。现在呢？动不动就是两三层芯片堆叠在一起，每层有自己的版图，层与层之间靠TSV、微凸点或者混合键合来连通。这个时候，如果还在用老思路把一层一层分开验证，跨层网络的错误根本发现不了。Calibre 3Dstack就是为这种场景而生的验证流程，而在这个流程里，component是最基础、最核心的一个概念。这个“每日一个命令”系列今天讲到第2天，对应编号3-2，主题就是component：它怎么定义、怎么用、踩了哪些坑，我尽量一次讲透。

1. 为什么3D IC验证需要3DStack和component

1.1 从单层版图到堆叠芯片，验证维度发生了什么变化

传统IC验证的最大前提是“一张版图就是一个完整设计”。所有图层都在同一个坐标系里，所有连接都在二维平面内闭合。这个前提在3D IC时代被打破了。最典型的例子是TSV硅通孔：它在顶部芯片的版图里是一个孔，在底部芯片的版图里是另一个孔，实际电气连接发生在垂直方向上。如果你把两层版图分开验证，顶层看到的TSV和底层看到的TSV根本不会被认定为同一个网络，除非你建立某种跨层映射关系。

我习惯用一个类比来理解这事儿：验证一栋楼，不能每层都按独立公寓验收。楼梯、电梯井、垂直管线横跨多层，在一层看是一个洞，在另一层看又是另一个洞，但它们是同一个通道。只看单层，永远不知道通道有没有错位。3DStack做的事情就是让工具具备“跨层感知”能力，而component是这套能力的数据组织单位。没有component概念，你连“哪块图形属于哪颗芯片”都说不清楚，跨层分析就更无从谈起。

从实际工作流的角度看，3D IC验证不是简单地把两份GDS合并跑一遍。它要求在统一验证框架下保留各层的独立性，同时又能识别层间关系。这两点同时满足，二维时代的设计规则检查和版图电路对比工具做不到。所以Calibre 3DStack才单独开辟出支持多组件堆叠验证的模式。component就是在这个背景下被引入的验证对象单元，理解它，等于理解整个3D验证的入口。

1.2 component解决的三件具体的事

第一件事是坐标基准。每个参与堆叠的芯片层都有自己的原始坐标系，component配置里要明确各层的相对位置关系，比如顶层芯片相对中介层偏移了多少、旋转了多少。没有这个基准，跨层TSV对上不齐，后面所有验证结果都是错的。我见过很多新手在这个地方翻车：两层版图的数据明明都是对的，就因为ORIGIN没填或者填错，报出一堆莫名其妙的开路。

第二件事是连接识别。只有定义了component之间的关系，工具才会把不同层里的TSV孔、微凸点识别为同一个物理连接点。也就是说，component不仅是一个数据容器，它还告诉验证引擎“哪些图形在不同层之间应当被绑定在一起”。这个绑定关系一旦定义清楚，LVS才能跨层追踪网络，DRC才能跨层检查堆叠区域的物理间距规则。

第三件事是验证结果的组织与追溯。堆叠验证的报表必须能清楚告诉你：这条跨层网络涉及顶层哪几层图形、底层哪几层图形，分别合规还是违规。没有component概念，报表就只能输出一堆找不到归属的坐标点，排查效率极低。有了component分组，你能一眼看出问题出在顶芯片、底芯片还是中介层，直接定位到具体物理层上。

1.3 3DStack验证流程中的数据组织方式

理解了component要解决的事，再看3DStack的内部处理逻辑就顺了。工具处理多组件堆叠时，会把各component的版图按配置的位移、旋转关系，映射到一个统一的虚拟坐标空间里。在这个过程中，每一块geometry都会被标记上归属的component信息。这样后续标准DRC、LVS算法可以照常运行，但结果报表里额外保留了“这是哪个组件里的图形”这类上下文。

这个“打标签”的动作很关键。它让堆叠验证不只是一个二维几何运算，而是变成了一个带归属信息的结构化检查。比如跨层短路报出来，工具能告诉你短路的一端在TOP_DIE的第C4层，另一端在BOTTOM_DIE的第C4层，你直接去两层对应坐标附近查layout就行。没有component概念，这种跨层追溯根本做不出来。

我还想补充一点：component的组织方式也影响了验证效率。合理拆分component，可以让工具在层内做局部优化、在层间做必要通讯。如果把整个堆叠当成一个大component输进去，规则虽然也能跑，但失去了跨层组织的意义，报表也退化成了二维时代的样子。所以我一直提醒团队：component的划分要认真设计，不是随便分一下就行。

2. component的定义逻辑与关键配置解读

2.1 component到底对应物理世界里的什么

字面上看component是“组件”，在实际3D堆叠项目里，它对应的通常是一个独立的芯片层（die）、一个中介层（interposer），或者在某些特殊工艺下甚至是一个单独的功能块。我在实际项目里最常遇到的结构是“两颗芯片加一个中间硅中介层”，这种情况下一般定义三个component：顶部芯片、底部芯片、中介层。每层用一份独立的GDS或OASIS数据。

重要的是：component不是掩模层，也不是cell，它的粒度更大。你可以把component理解为“一个参与堆叠验证的物理逻辑单元”，它有自己的版图数据、技术文件定义，同时又有与其他component互动的关系描述。这一步理解到位了，后面配参数就不容易乱。我见过有人把component当layer来配，纠结什么“两层之间要不要写金属层定义”，其实component层面完全不涉及这些东西，那是单层规则文件里的事。

从工程管理角度看，component也是验证任务划分的基本单位。不同团队可能分别负责不同芯片层的设计，但堆叠验证需要把所有component集中起来统一管理。规则文件写得好，验证团队和设计团队的沟通成本能低很多。写不好，一个component的坐标改一处，所有相关配置全得跟着查一遍。

2.2 一个component配置的示意与参数拆解

不同版本和环境下的语法可能不同，这里给一个简化示意（以你本地安装版本的官方文档为准）：

3DSTACK COMPONENT TOP_DIE { LAYOUT "top_die.gds" ORIGIN 0 0 ROTATION 0 } 3DSTACK COMPONENT BOTTOM_DIE { LAYOUT "bottom_die.gds" ORIGIN 0 -200 ROTATION 0 } 3DSTACK CONNECT TSV BY { TOP_DIE LAYER { VIA1 } BOTTOM_DIE LAYER { VIA1 } }

每个字段的作用我挨个说一下。LAYOUT指定该组件对应的版图文件，一般用GDS或OASIS。ORIGIN定义组件坐标原点在堆叠整体坐标系里的位置。这里有个容易忽略的坑：各层版图在设计时通常各有各的零点，不可能天然对齐。你必须在ORIGIN里给出真实相对偏移，否则TSV对不上。ROTATION也是一样，有的堆叠方案里上下晶圆会旋转90度或者180度，旋转没填对，跨层网络会整个错位。

CONNECT是跨层连接的关键。它告诉验证引擎：顶层名为VIA1的层与底层名为VIA1的层，通过TSV建立真实电气连接。后续LVS才能把位于两层的TSV当成同一网络来追踪。这个关键词的粒度是“层到层”，不是“图形到图形”。图形之间的具体对应关系是工具根据几何位置自动判断的，你只需要定义哪些层之间存在连接关系。

2.3 多组件堆叠的完整配置实例

两芯片加中介层的结构更常见一些，也更能体现component之间的层级关系。我一般会这样配置：

3DSTACK COMPONENT TOP_DIE { LAYOUT "top_die.gds" ORIGIN 0 0 } 3DSTACK COMPONENT INTERPOSER { LAYOUT "interposer.gds" ORIGIN 0 50 } 3DSTACK COMPONENT BOTTOM_DIE { LAYOUT "bottom_die.gds" ORIGIN 0 100 } 3DSTACK CONNECT TSV BY { TOP_DIE LAYER { TSV_METAL } INTERPOSER LAYER { TSV_METAL } } 3DSTACK CONNECT UBMP BY { INTERPOSER LAYER { UBMP_METAL } BOTTOM_DIE LAYER { UBMP_METAL } }

这种配置直接定义了两种跨层连接：顶部芯片到中介层用TSV，中介层到底部芯片用微凸点。注意我这里的ORIGIN只是示意，实际项目里要按真实坐标换算。但结构上大体就是这样一个套路：每个component一份布局文件，组件与组件之间的连接通过CONNECT挂接。连接类型越多，越要仔细检查每一组CONNECT的层名是否来自同一个工艺文档。

为什么强调要按工艺文档查层名？因为不同工艺节点、不同代工厂对TSV、微凸点、混合键合层的命名差异非常大。有的叫TSV_METAL，有的叫TSV_CU，有的干脆叫M0VIA。上一项目用的名字，换一个新工艺可能完全不是同一个含义。这种错误光靠眼睛检查很难发现，必须跟设计规则文件交叉验证。

2.4 为什么这个系列编号叫3-2

纠正一下系列编号这个事。我写这个系列习惯按“模块-顺序”编号，3-2表示3DStack模块下的第2篇，对应day 2。这样好处是索引清晰，后面如果写了3-3、3-4，读者知道自己是在连续跟进同一个主题。day 1如果还没看，建议先回去补一下3DStack的整体流程概念，不然今天component的一些表述可能会觉得跳。这个系列每一篇都是独立的，但连着读会更有体系感。

有人可能会问：“为什么component要放到day 2？”我的回答是：3DStack验证里，component是地基。第一篇文章适合讲整体框架，第二篇就得落到底层单元上。没有component，后面的跨层DRC规则写在哪？堆叠面积检查检查的是谁和谁的关系？都没法展开。所以我把component安排在第二天，后面的内容就可以放心建立在它上面了。

3. 实操：从单层验证到跨层3D验证的完整流程

3.1 先梳理输入数据清单

拿到一个3D堆叠项目，我不会急着敲命令，而是先把输入数据列清楚。最少需要四样：各层版图文件（GDS或OASIS）、3DStack规则文件（包含component定义）、跨层连接说明（TSV/微凸点/混合键合定义）、以及一份基底单层规则文件（用于先单独验证每层）。

我习惯先建一个目录，按层和用途分好文件：

project/ data/ top_die.gds interposer.gds bottom_die.gds calibre/ stack_3d.rule drc_single_layer.rule run/

这样做的原因是：3DStack验证本来就是个多输入的流程，文件一旦多了，路径混乱会直接导致验证跑错版本。尤其是三份GDS名字相近的时候，很容易在脚本里写错一串字符，然后报出一堆莫名的错误。目录清楚，至少能排除这类低级问题。另外，每一份GDS我还会额外写一个简单的信息卡片，记录它的版本、导出时间、坐标系约定，放在对应目录下。项目时间一长，这个卡片比任何人的记忆都可靠。

3.2 定义component与跨层连接的实操步骤

第一步是搭建规则文件骨架。我会先用文本编辑器把三个component的框架写出来，只填LAYOUT和ORIGIN，先不写CONNECT。然后用一个简单的DRC规则去加载这个骨架，目的在于确认工具能正确读入每层数据、坐标转换没有报错。这一小步看起来多余，但能省掉后面排查数据路径的时间。

第二步是确认各层坐标系。具体做法是把三份GDS分别单独跑一遍简单的图层计数DRC，输出每层图形的边界框，然后跟设计文档里的预期坐标对比。如果发现某层图形整体偏移了几十微米，多半是数据导出方给的参考点不一致。这个对比操作在3D项目里几乎是必须的，我吃过几次亏之后已经养成了条件反射：任何跨层验证之前，先单独核对边界框。

第三步才是写CONNECT。连接定义要跟工艺规范对齐。TSV的话，一般把顶层和底层的对应通孔层绑在一起；混合键合则可能涉及顶层最后一块金属和底层第一块金属，用到的层级和命名需要从工艺文档里仔细抄出来。这里最忌讳想当然地使用“VIA1对VIA1”，不同工艺里同一层名字可能完全不同。写完之后，我会像核对清单一样逐条确认：连接类型、上下层名、所属component，三样都对了才进入下一步。

3.3 一个跨层坐标偏移的计算小例子

ORIGIN值不是猜的，它是可以通过几何关系算出来的。假设顶层设计里，某个TSV阵列的原点在顶层坐标系的位置是(120.5, 200.3)微米；同一阵列在底层设计坐标系里对应的位置是(90.2, 150.8)微米。要让这两个TSV在全局坐标里真正重叠，底层的原点相对顶层原点需要偏移：

(120.5 - 90.2, 200.3 - 150.8) = (30.3, 49.5)微米

也就是说，如果顶层ORIGIN设为(0, 0)，底层ORIGIN应该填(30.3, 49.5)。反过来定义也成立，只要逻辑一致。这个计算过程很简单，但很多人偷懒不算，直接凭感觉填个差不多的数，结果TSV全错位。我建议每次配置完ORIGIN，都抽一组TSV坐标做一次验证计算，误差在纳米级才算通过。

3.4 运行跨层LVS与报表解读

定义好component和CONNECT之后，就可以直接跑跨层LVS了。命令行习惯如下（示意，实际参数名以你的工具版本为准）：

calibre -lvs -3d stack_3d.rule -hier -turbo 8

跑完之后，我会先看总报告里的三个数字：总错误数、跨层网络数、未连接网络数。这三个数字能快速判断整体健康状况。如果跨层网络数为零，说明CONNECT没生效，得回头检查命名映射。如果未连接网络数特别大，可能坐标偏移算错了。这两个数字能很快把问题分成两类，排查方向完全不同。

然后进入报告正文。3DStack的报表会按component来分组列出问题，比如“TOP_DIE内的短路”“BOTTOM_DIE与INTERPOSER之间的开路”。这种分组格式其实是福利，它把二维时代需要手动对坐标的问题，直接映射到物理层归属上。排查的时候，先看涉及哪些component，再定位到具体坐标，效率高很多。每次跑完，我也习惯把报告里的跨层网络清单导出来做一次交叉检查，看它们是否和设计文档中标注的TSV阵列数量一致。数量对不上，说明数据版本或者映射关系一定有问题，早发现早处理。

4. 常见问题与排查技巧实录

4.1 我踩过的三个高频坑

第一个坑：ORIGIN坐标漏填或者填错。症状是报表里TSV错位严重，顶层和底层的通孔坐标对不上。解决办法很简单，回到上一步的边界框核对，拿两层的期望重叠坐标反推ORIGIN值。我遇到的多数“跨层开路”其实都不是真开路，而是坐标基准错乱。我自己就曾经在一个双芯片堆叠项目里漏掉了中介层的ORIGIN，导致中介层和底芯片之间全部开路，排查了整整一下午才发现是配置文件的问题。

第二个坑：连接层名字对应错误。症状是LVS报出大量“未识别连接层”，或者某些本该连通的网络报告成不同网络。这时候别怀疑工具，先回去翻工艺文档，确认TSV对应的实际层名。我见过一个case，工艺文档里写的是TSV_CU_2P，项目组里有人写成了TSV_CU_2M，就一个字母的差别，整个跨层网络全部断开。核对层名这种活看起来简单，实际比写代码更需要耐心。

第三个坑：旋转忘填。有些堆叠方案要求上方芯片相对下方芯片旋转90度，如果ORIGIN和ROTATION只填了平移，旋转没填，那么顶层TSV的位置会整体偏转，表现为所有跨层连接都“差一个固定角度”。排查这种问题有一个技巧：把顶层和底层TSV坐标导出来，在表格软件里做一轮坐标变换对比，偏差呈现同一方向旋转时，基本就可以锁定是ROTATION没配置。这种问题在纯看报表时很难发现，必须和版图交叉对比。

4.2 高频问题速查表

这里给一个我自己常用的速查表，贴在工位上那种。

这个表在实际排障里真的很能救急。我不止一次看到新手在“网络数异常多”上卡很久，最后发现只是TSV层名少写了一个数字。配置代码这种事，看着简单，细节决定成败。每次打开报表之前，先对照这张表过滤一遍现象，通常能节省半小时的盲目排查时间。

4.3 排障的几个个人习惯

我自己的排障顺序是固定的：先看数据，再看规则，最后看命令。也就是先确认每层数据本身干净、坐标无误，再检查component配置和连接定义，最后才怀疑命令行参数。这个顺序能避免90%的无谓折腾。因为3DStack跨层验证的特殊性，数据层面的问题最容易伪装成规则层面的错误，反过来规则写错了也会表现为数据异常。不动摇排查顺序，才能快速收敛。

另一个习惯是保留每次跑批的日志。3DStack跑一次往往不便宜，日志里往往有第一手线索。我会给每个验证版本按日期建目录，把规则、日志、报表归档，方便出了新问题回溯。这个方法虽然笨，但在多人协作的堆叠项目里，能省下大量沟通成本。有一次项目延期，我们复盘时全靠这些日志定位到是某次GDS更新导致坐标基准变化，如果没有归档，这个问题可能要拖更久。

4.4 从component视角理解跨层短路

最后分享一个稍微进阶的排查思路。跨层短路是3D验证里比较头疼的问题，因为它横跨多个component，定位起来不比单层短路容易。但利用component的归属信息，排查反而有迹可循。比如报表报出顶层电源网络和底层地网络在某个TSV位置发生短路，你先看这个TSV属于哪两个component，再看每一端对应的是什么设计层次。

实际操作上，我会先把报告里的短路坐标导出来，在版图工具里同时打开两个component的对应层次，半透明叠加显示。如果顶层和底层的图形都在同一位置出现了不该出现的扩展，短路基本可以确认是由某一层的走线规划错误引起的。接下来再到那一层的单层规则文件里单独跑一次DRC，看是走线间距不足还是通孔位置偏移。这样从component到单层逐级缩小范围，跨层短路很快就能定位到具体图形的具体边上。

要注意的是，跨层短路不一定是物理上真的连上了，也可能是CONNECT定义过宽导致的。比如你把整个VIA1层都绑定成了跨层连接，而设计上只有一部分TSV真正起作用，那些“不存在的连接”就会变成虚拟短路。遇到这种问题，我会先试着把CONNECT的层定义改成更具体的派生层或者加图形筛选条件，重新跑一次，看看短路是否消失。这一招在处理3D堆叠验证里屡试不爽。

5. 一些实操体会与后续方向

个人实际经验是，component这个配置初看只是“把几份GDS放到一个规则里”，但实际上它承担了坐标基准、跨层连接、结果组织三重重任，是3DStack验证的地基。地基一旦歪了，上层跑出来的任何结论都不可信。所以每次新建项目，我会专门留出半天时间做component层的核对，不核对完不往下走。这一步省下来的时间是后面排障时间的好几倍。

另外一个经验是，component的命名要稳定且语义清晰。TOP_DIE、BOTTOM_DIE、INTERPOSER这种一眼能看懂的名字，比DIE_A、DIE_B这种没语义的命名在团队协作中好用得多。命名一旦定了，尽量少改，因为很多规则文件和脚本都依赖这个名字，改一次要全局同步。我就是吃过这种亏，后来在项目启动会上就把命名规范定下来了。

Day 2把这个概念梳理清楚，后面再聊跨层DRC、堆叠面积检查之类的命令，就顺理成章了。下一期准备拆3-3，主题大约跟跨层DRC的规则写法有关，到时候见。