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-WaferCoW或WoW的坐标便宜没配好A die上的0,0在整体坐标系里可能是100,200B 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文本覆盖检查前需要确认五类文件就位且版本匹配文件类型说明易错点各die的GDS/OASIS版图参与堆叠的die版图确保导出时没有flatten保留层次结构各die的CDL网表用于LVS一致性文本标注需与CDL端口一一对应堆叠描述文件STACK描述定义die的相对坐标、旋转、镜像坐标系方向约定必须全组统一Calibre规则文件SVRF/TVF包含3DSTACK检查和文本覆盖规则确认规则文件版本支持3DSTACK指令工艺映射文件layer map各die层号到虚拟层号的映射3-32层范围需在这里核对环境准备阶段我推荐先在命令行里跑一次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 文本覆盖注释检查规则的实现这次的核心检查项我把它理解为一个自动化的文本附着正确性检查。具体规则逻辑可以拆解为在堆叠后的统一坐标系中选取第3层到第32层范围内的文本对象对每个文本对象提取其边界框和依附层信息检查边界框是否完全覆盖了依附层上对应的目标金属图形通常是焊盘、凸点下金属UBM、RDL线段等如果覆盖不足或完全未覆盖输出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归属信息。我拿到报告后的阅读顺序是先看die归属列确认错误发生在哪个die这决定我接下来是回版图编辑器改这个die还是调整堆叠描述文件再看坐标位置用堆叠后的坐标反推回原始die坐标在版图编辑器里定位到实际对象最后看文本内容和依附层判断是文本框太小、位置偏移还是依附层映射错误。还有一个非常实用的技巧用Calibre RVE里的highlight in source layout功能直接联动打开对应die的版图窗口。因为3D项目的目标是多个版图RVE默认打开的可能是第一个die的版图需要通过手动指定GDS路径来正确联动这点很多人开始没注意到。3.5 一个常被忽略的检查文本通配符干扰文本覆盖注释检查里通配符问题比普通DRC更隐蔽。比如die A的pin名叫VDDdie 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工艺的逻辑diedie 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范围内的文本本来就不应该覆盖焊盘建议使用EXTENTENCLOSE类的检查替代简单覆盖检查或者给规则加一个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堆叠相关特性检查结果里所有文本覆盖错误全是空集——不是没有问题而是检查根本没生效。这个坑排查了很久希望后来者避过。