在3D IC设计已经不算新闻的今天物理验证工程师手里的活儿反而变得越来越不那么“物理”了。以前我们拿到一个GDS所有DRC、LVS都在一个二维平面上完成图层、边界、连接关系清清楚楚。现在呢动不动就是两三层芯片堆叠在一起每层有自己的版图层与层之间靠TSV、微凸点或者混合键合来连通。这个时候如果还在用老思路把一层一层分开验证跨层网络的错误根本发现不了。Calibre 3Dstack就是为这种场景而生的验证流程而在这个流程里component是最基础、最核心的一个概念。这个“每日一个命令”系列今天讲到第2天对应编号3-2主题就是component它怎么定义、怎么用、踩了哪些坑我尽量一次讲透。1. 为什么3D IC验证需要3DStack和component1.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全部报开路ORIGIN或ROTATION配置错误单独核对各层bounding box网络数异常多CONNECT层名错误或不完整比对工艺文档中的TSV层名报错仅出现在单一component该层数据本身有问题单独跑一遍单层DRC/LVS报表坐标对不上版图数据单位不一致确认GDS单位与规则单位统一运行3D模式报选项错误版本不支持或开关名不对查当前版本命令行手册这个表在实际排障里真的很能救急。我不止一次看到新手在“网络数异常多”上卡很久最后发现只是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的规则写法有关到时候见。