企业官网建设流程全解析

Calibre是全球封装和芯片物理验证领域的标准工具，这几年3D IC堆叠设计越来越多，3DSTACK这个选项从被忽视到逐渐变成高频使用项，我自己的项目里也踩了不少坑。这篇文章不聊理论，就围绕"检查文本覆盖注释（3-32）"这个具体需求，把我在实际项目中配置Calibre 3DSTACK、处理文本类检查规则的完整过程拆开讲清楚。如果你正在做多die堆叠的DRC/LVS验证，或者被跨die文本覆盖一类的问题卡住，这篇文章应该能省你不少折腾时间。

1. 3DSTACK到底是什么：不是简单的多层DRC，而是"跨die坐标换算"

先说一个很容易混淆的点：Calibre里做3D堆叠检查，并不是把多个die的GDS简单叠在一起再跑一遍DRC就完事。真正的3DSTACK操作，是在保持每个die物理层定义不变的前提下，通过一个额外的坐标偏移基准，把不同die的版图数据映射到同一个参考坐标系里，然后在这个统一坐标系中执行跨die约束检查。

我最初接手3D项目时，下意识的想法是"把所有GDS merge成一个文件，再跑普通DRC"，结果出来的文本覆盖检查结果完全不可用——原因在于merge之后的层号会冲突，不同die上同名的TEXT层被当成同一层处理，而3D规则关心的恰恰是"die A上的文本标记和die B上的文本标记在堆叠之后的空间位置关系"。

3DSTACK模式的核心理念是层次化调度：它不修改你的原始版图数据，而是在规则文件里用一个STACK的布局描述，告诉Calibre"这些die分别在什么位置、以什么方向堆叠"。这样一来：

• 同一个die可以被复用多次，比如interposer上有两个HBM die，不需要复制两份GDS；
• 每一层文本注释仍然归属各自的die，不会因为merge而丢失归属信息；
• 检查报告可以精确指向"哪个die的哪个文本对象"，定位效率大幅提升。

文本覆盖注释（text coverage annotation），在这个语境下指的是版图中用于标识pin名、net名、器件名的text标签。在3D堆叠场景里，这些文本标签会被用来做LVS的跨die连通性判断，也会被DRC规则用来约束"文本标注范围必须覆盖对应焊盘区域"。如果文本覆盖范围不对，轻则LVS报出无法匹配的连接，重则顶层封装DRC直接报错，流片回来才发现问题就晚了。

3-32这个编号，我遇到的多数情况是顶层金属或重分布层（RDL）的层号范围。也就是说，这条检查约束的是"第3层到第32层之间所有文本对象的覆盖注释行为"。不同工艺厂的规则文件定义会有差异，但逻辑一致：当你看到一个带数字范围的3DSTACK检查项时，先别急着跑，一定要先去规则文件里确认这个范围对应的是哪些物理层、哪些die。

提示：在项目初期，建立一份"层号-物理层-die归属"的映射表非常有必要。不要指望只看报告能看出层号含义，3D项目里的层号几乎都是经过映射的虚拟层号。

2. 为什么文本覆盖注释在3D堆叠里特别容易出问题

在普通2D版图里，文本覆盖注释的检查逻辑相对简单：检查text标注框是否落在目标图形范围内，比如pin的金属区域。到了3D IC堆叠中，问题复杂了一个维度。

先看这次要处理的检查项，它要求的是一个die上的文本标注要覆盖到另一个die的对应区域。最典型的场景是混合键合（hybrid bonding）或micro-bump连接：die A最顶层金属有一个焊盘区域，die B最底层金属也有一个对应焊盘区域，两个die堆叠后需要靠text标签的覆盖关系来完成电气连接映射。文本覆盖注释检查在这里扮演的角色，就是确认"die A上的pin名文本标注框，在堆叠坐标系下能够准确覆盖到die B对应焊盘范围"。

为什么这个检查会在3D设计里高频报错？我把实际遇到的原因归纳为四类：

第一，坐标基准不一致。每个die在独立设计时，原点位置是各自定的。堆叠时如果Chip-on-Wafer（CoW）或WoW的坐标便宜没配好，A die上的（0,0）在整体坐标系里可能是（100,200），B die上的（0,0）是（250,120）。文本标注是基于原始die坐标做的，偏移之后很可能整体偏离到焊盘区域之外。

第二，旋转方向没对齐。3D堆叠里经常有die旋转90度或者180度的情况。CDL（连接描述）里定义的文本标注框，旋转后覆盖区域与实际需要覆盖的金属区域错位。这种错位在数值上往往不大，但足以触发"文本未覆盖"的错误。

第三，文本层与金属层的依附关系被忽略。Calibre里文本注释通常带一个依附层（associated layer），检查"文本覆盖"时实质是检查"文本所在坐标是否在依附层图形内"。3DSTACK模式下，如果依附层没有正确映射到堆叠后的统一层号，检查就会失效或者误报。

第四，die厚度方向上的"穿透覆盖"。3D堆叠是Z方向上的物理堆叠，但版图检查是在XY平面上做的。当两个die的焊盘在XY平面投影完全重合时，文本覆盖检查通过，但这并不意味着Z方向上真正连接——还需要结合CDL或BOM描述确认到底部die和顶部die之间是否存在实际键合关系。文本覆盖注释检查本身只管XY，这是它的边界，也是新人最容易误读的地方。

3. 完整实操：如何配置3DSTACK检查文本覆盖注释

3.1 准备输入文件与环境检查

在执行3DSTACK文本覆盖检查前，需要确认五类文件就位且版本匹配：

环境准备阶段，我推荐先在命令行里跑一次calibre -3dstack_check或对应的图形界面流程，用最小的测试die验证检查框架本身能跑通，再上全量数据。这一步能节省大量后续排查时间。

3.2 堆叠描述文件编写要点

堆叠描述文件是3DSTACK检查的核心输入。以我常用的写法为例，它通常包含如下关键信息：

// 定义die基本信息 DIE die_A { LAYERMAP : layermap_1.map GDS : die_A.gds } DIE die_B { LAYERMAP : layermap_2.map GDS : die_B.gds } // 定义堆叠关系 STACK 3D_CFG { DIE die_A { POSITION : 0 0 0 ROTATION : R0 } DIE die_B { POSITION : 0 0 0 ROTATION : R180 } }

注意几个关键点：

• POSITION定义的是die参考点在堆叠整体坐标中的位置，通常以µm为单位，坐标精度建议至少保留到nm级别，因为文本覆盖检查的容差往往是百纳米量级，坐标舍入误差可能直接导致假错；
• ROTATION用R0/R90/R180/R270加上可能的镜像标志M表示，必须和实际封装图一致；
• 每个die用独立的LAYERMAP，因为不同die可能来自不同工艺节点，层号差异很大。

3.3 文本覆盖注释检查规则的实现

这次的核心检查项，我把它理解为一个自动化的"文本附着正确性检查"。具体规则逻辑可以拆解为：

1. 在堆叠后的统一坐标系中，选取第3层到第32层范围内的文本对象；
2. 对每个文本对象，提取其边界框和依附层信息；
3. 检查边界框是否完全覆盖了依附层上对应的目标金属图形（通常是焊盘、凸点下金属UBM、RDL线段等）；
4. 如果覆盖不足或完全未覆盖，输出DRC错误报告，并在报告中标注die归属和原始坐标。

在SVRF规则文件里，这段检查的大致逻辑如下（示意）：

// 定义文本层并关联附属金属层 LAYER text_all = TEXT_LAYER_A + TEXT_LAYER_B LAYER metal_sel = M1_TOP_A + M1_TOP_B ... // 文本覆盖检查 TEXT_COVER { @ 检查文本注释是否覆盖对应金属区域 EXTENT text_all COVER metal_sel }

实际项目中，我通常不会只用一条简单的COVER语句，而是会用CHECK语句配合DEPTH/HEIGHT等Z方向参数，把文本覆盖检查精确约束到跨die键合界面的金属层上。3-32这个层号范围如果覆盖了中间路线层（interposer routing），规则表达式需要相应调整。

3.4 跑完检查之后的文本覆盖报告解读

检查完成后，Calibre会生成RVE报告或文本报告。3DSTACK模式下，报告里每个错误都会带额外的坐标信息和die归属信息。我拿到报告后的阅读顺序是：

1. 先看die归属列：确认错误发生在哪个die，这决定我接下来是回版图编辑器改这个die，还是调整堆叠描述文件；
2. 再看坐标位置：用堆叠后的坐标反推回原始die坐标，在版图编辑器里定位到实际对象；
3. 最后看文本内容和依附层：判断是文本框太小、位置偏移，还是依附层映射错误。

还有一个非常实用的技巧：用Calibre RVE里的"highlight in source layout"功能，直接联动打开对应die的版图窗口。因为3D项目的目标是多个版图，RVE默认打开的可能是第一个die的版图，需要通过手动指定GDS路径来正确联动，这点很多人开始没注意到。

3.5 一个常被忽略的检查：文本通配符干扰

文本覆盖注释检查里，通配符问题比普通DRC更隐蔽。比如die A的pin名叫"VDD"，die B上也可能有"VDD"，但两者在堆叠后的坐标位置可能靠得很近。Calibre做文本匹配时，如果规则里用了通配符（*VDD*），极可能把两个die上的文本误判为同一个对象，导致覆盖检查结果异常。

我的建议是：在3DSTACK文本检查的规则里，务必显式指定die限定条件，让文本匹配只在特定die的层内发生，或者至少在报告里保留die信息以便追溯。在规则文件层面，用DIE_LAYER语法指定归属结构：

TEXT_COVER_TOP { EXTENT die_A_text COVER metal_sel }

4. "3-32"这个层号范围背后的映射逻辑

很多人拿到检查项，第一反应是去版图里找第3层到第32层是什么。这个思路在2D项目里适用，在3DSTACK项目里可能直接落空，因为这个层号范围往往是规则文件内部的虚拟层号，而不是某个die GDS里的实际层号。

我以一个具体案例来说明。某3D项目里，die A是65nm工艺的逻辑die，die B是40nm的interposer，两者GDS层号定义完全不同。3DSTACK规则文件里通过两份独立的layer map，把它们的金属层统一映射到一套虚拟层号里：

• 虚拟层号3-8对应die A的顶层金属（可能是die A GDS的第50层）；
• 虚拟层号9-20对应die B的RDL层（可能是die B GDS的第80、81层）；
• 虚拟层号21-32对应die B的凸点层和UBM层。

"3-32"这个范围，从逻辑上看覆盖了die A顶层到die B底层的所有信号传输相关层，文本覆盖注释检查在这个范围内执行，正好能完整验证堆叠界面两侧的文本与金属覆盖关系。

验证方式也有一个标准做法：在规则文件里插入一条临时的输出语句，把这31层逐一输出到单独的文本文件里，跟layer map交叉核对，确认每一层的die归属和原始层号。

实操建议：如果在规则文件里看到"3-32"这样的层号范围，先找LAYER MAP段落，把每个虚拟层号对应到具体die、具体原始层号。别盲猜，别凭经验拍脑袋，尤其在3D项目里，层号错一位，检查结果全盘失真。

5. 从报错到修复：一个真实文本覆盖问题的排查链路

下面复盘一次真实的排查过程。项目背景：两个die通过硅通孔（TSV）和micro-bump堆叠，需要验证die A的TSV顶层文本是否能正确覆盖到die B的micro-bump层。跑完检查后，报告里冒出几十条TEXT COVER错误，全部集中在虚拟层号7和25上。

我的排查步骤：

第一步，排除坐标偏移问题。随机挑了两个错误，在RVE里看报错坐标，再去堆叠描述文件里比对die A和die B的POSITION定义。坐标没问题，偏移量和封装图一致。

第二步，检查文本数据的准确位置。返回到die A的原始GDS，找到报错的文本对象，发现它确实存在，坐标也在预期位置。但放大之后发现，文本的边界框比对应焊盘图形小了约0.8µm。也就是说，文本注释本身就没有完整覆盖金属区域，这是版图设计阶段就存在的问题，只是2D检查时没有人用跨die规则约束它。

第三步，定位为什么2D检查没发现。原因很简单：2D检查时，die A的文本只检查是否覆盖die A自己的金属，而die A自己的金属范围比stack后与die B对接的区域大不少。堆叠之后，实际上对覆盖范围起约束作用的是die B那边更小的焊盘区域。文本盖住了die A的金属，却没盖住die B对应的金属边界。

第四步，修复方案。在版图编辑器里把错误文本的标注框扩大，使其完整覆盖对接焊盘区域，同时保留与原金属的位置对应关系。因为文本标注框本身不是光刻图形，扩大不会影响物理层，只需保证后续LVS仍能正确匹配net名。

第五步，重新跑3DSTACK检查，验证结果。错误数量从几十条降到个位数，剩余错误经确认是另外两个pin的设计命名问题，修掉后全部清零。

这次排查花了大半天时间，但价值很大。它让我意识到一个关键经验：3DSTACK文本覆盖检查报出来的错误，往往不是3D堆叠本身的问题，而是2D设计阶段没被检查出来的"隐藏债"。3D检查只是帮助我们把账翻了出来。

6. 常见误报场景与规则条件精调技巧

文本覆盖注释检查在3DSTACK模式下有几个典型的"误报高发区"，处理不好极容易在项目组里引起对检查结果的信任危机。

6.1 文本框尺寸小于焊盘

封装设计里，pin名文本通常放在焊盘侧边的空白区，不直接覆盖焊盘。但文本覆盖检查要求文本框覆盖焊盘本身。二种需求冲突直接导致误报。

解决思路是区分"文本位置约束"和"文本覆盖约束"两类规则。如果3-32范围内的文本本来就不应该覆盖焊盘，建议使用EXTENT+ENCLOSE类的检查替代简单覆盖检查，或者给规则加一个INVISIBLE层来排除特定文本。这些调整都要和工艺厂规则编写者确认，不能随意删规则。

6.2 文本跨die镜像后坐标偏移

die B如果被设置为R180旋转，文本坐标在堆叠坐标系里会做镜像变换。文本对象的边界框中心点可以正确变换，但当文本框本身不是规则矩形时，旋转后覆盖范围会变化，容易在边缘位置报错。

处理办法：把文本统一改为最小包围矩形（MBR），放弃对非规则文本形状的精确匹配。对于文本注释检查来说，用MBR做覆盖判断精度足够，还能避免大量由坐标旋转小数位引起的噪声错误。

6.3 规则文件中文本层定义重复

当同一个文本层在die A和die B中都有定义，但在规则文件里只声明了一次，Calibre默认把它当作一个集合。此时位于不同die的文本对象之间的覆盖判断也变得没有意义。

正确做法是分别定义：

TEXT_A = LAYER die_A 31 TEXT // die A的文本 TEXT_B = LAYER die_B 15 TEXT // die B的文本

再做跨die覆盖检查时，明确指定A对B的关系。在3DSTACK的SVRF语法里，用LAYER die_A 31这样的写法可以精确选取指定die内的某个层，这是解决跨die文本归属判定的关键指令。

6.4 检查范围过宽导致性能瓶颈

文本覆盖检查如果对第3层到第32层的所有文本对象做全覆盖检查，在die面积较大时性能会显著劣化。我一个40nm interposer项目里，一条全chip文本覆盖检查跑了将近9小时。后来把检查拆成两条：第一条只检查die A顶层对die B底层键合界面，第二条检查die B的RDL各层文本覆盖，总耗时降到2小时以内。

拆分规则还有一个额外收益：报告针对性更强，不同阶段的错误可以分流处理，不需要全体EDA用户去翻同一个巨大的错误报告。

7. 从"跑通检查"到"管好检查"：我的几条经验总结

3DSTACK文本覆盖注释检查，说到底只是3D物理验证链条上的一环。但这一环管不好，后续的LVS和顶层ERC都会连带遭殃。经过几个项目的磨合，我把文本覆盖检查的管理经验沉淀成下面几条：

经验一：文本命名规范要从设计源头抓起。文本覆盖检查报错的大部分根因是文本框位置和大小不满足约束，而非规则本身的问题。项目启动时，就应该在版图设计规范里明确"顶层对接pin的文本框必须完整覆盖焊盘且额外外扩至少0.5µm"。这个规范写清楚，后端工程师画版图时就会注意，远比事后修DRC高效。

经验二：尽早跑3DSTACK文本检查，不要等全chip完成。3D堆叠项目的数据量大，设计周期长。建议在interposer版图完成50%左右时，就引入3DSTACK检查框架，哪怕只验证两个die的局部模块，也可以提前暴露堆叠描述文件、层映射、文本覆盖配置的问题。等到全chip数据齐备再跑第一次3D检查，通常会一次性面对大量叠加问题，排错成本极高。

经验三：版本管理要覆盖"规则文件+堆叠描述+层映射"三元组。3DSTACK检查的结果严重依赖这三者的组合。工艺厂更新规则文件后，即使堆叠没变，检查结果可能完全不同。我所在的项目组后来规定：每次运行3DSTACK检查，必须在日志里记录这三份文件的版本哈希值。这样无论结果如何变化，都能精确定位是哪一项发生了变更。

经验四：不要神化自动修复，文本覆盖问题多半要改版图。有些DRC工具提供自动修复功能，但文本覆盖检查的修复往往涉及版图设计者的设计意图——文本放在哪里，不只是为了满足规则，还关系到后续LVS的识别和可制造性。自动扩文本边框可能解决一时DRC，却可能掩盖了pin标注位置不合理的老大难问题。遇到文本覆盖错误，我的原则是：先理解文本为什么会在这，再决定要不要改。规则的目的不是把文本框改大，而是让版图的文本注释真正能服务于后续所有验证和检查。

经验五：关注"检查的检查"。3DSTACK模式本身也可能有工具层面的缺陷或者规则文件语义不清晰导致的问题。如果发现某条检查结果与人工审查结论明显矛盾，不要把时间耗在硬调规则上。先确认检查定义本身的合理性，比如"文本覆盖注释"里"覆盖"是要求完全包含还是中心落在范围内，这个语义差异会直接决定大量的报错与否。确认清楚再决定改规则还是改版图。

最后说一个我被坑过的地方：跑3DSTACK检查时，一定要确认顶层脚本里指定的Calibre版本和工具许可（license）支持3DSTACK特性。有些功能在某个版本里默认关闭，或者需要额外的授权选项。我第一次跑这类检查时，因为license缺了3D堆叠相关特性，检查结果里所有文本覆盖错误全是空集——不是没有问题，而是检查根本没生效。这个坑排查了很久，希望后来者避过。