4、协同规则检查框架：协同检查的整体架构、数据交换格式、规则统一管理策略
各位工程师朋友，这一节我们来聊聊协同规则检查框架。说实话，这个框架是我在实际项目中一点点摸索出来的。刚开始做封装协同的时候，我天真地以为只要把版图文件和规则文件丢给工具，它就能自动搞定一切。结果呢？第一次流片回来，封装厂那边反馈说我们的版图跟他们的基板对不上，焊盘位置偏了十几微米。嗯，从那以后我就明白了——协同检查不是工具的事，是架构的事。
4.1 协同检查的整体架构
我个人习惯把协同检查框架分成三层：数据层、规则层和执行层。你想想看，这三层各司其职，缺一不可。
核心架构三层模型：
- 数据层：负责管理芯片版图数据、封装基板数据、以及两者之间的互连信息。说白了，就是让芯片和封装能“说上话”。
- 规则层：统一管理所有检查规则，包括芯片内部的 DRC 规则、封装基板的规则、以及芯片与封装之间的协同规则。
- 执行层：调用检查引擎，按规则对数据进行验证，输出检查结果。
我在项目中遇到过一种情况：芯片团队和封装团队各自维护自己的规则文件，结果芯片侧改了焊盘尺寸，封装侧不知道，最后对不上。所以，我建议把规则层单独拎出来，作为统一管理的核心。
下面这张图是我自己画的协同检查框架流程图，你可以看看整体逻辑：
4.2 数据交换格式：LEF/DEF、GDSII、OASIS
数据交换格式这块，我踩过的坑最多。你想想看，芯片团队用 GDSII，封装团队可能用 OASIS，中间还要交换抽象信息。格式对不上，一切白搭。
4.2.1 LEF/DEF 格式
LEF 和 DEF 是 Cadence 体系下的标准交换格式。我个人习惯用 LEF 来描述芯片的抽象视图——说白了，就是告诉封装团队：“我的芯片长什么样，哪些地方可以走线，哪些地方不能碰。”
小技巧： 我在项目中通常只提取芯片顶层金属和焊盘层的 LEF，内部细节全部屏蔽。这样既保护了 IP，又满足了封装协同的需求。
DEF 则用来描述芯片的实例化信息和互连关系。举个例子，芯片有 200 个焊盘，每个焊盘对应哪个信号，DEF 里写得清清楚楚。
// LEF 示例：定义芯片的焊盘
MACRO BGA_PAD
CLASS PAD ;
FOREIGN BGA_PAD ;
ORIGIN 0 0 ;
SIZE 100 BY 100 ;
SYMMETRY X Y R90 ;
PIN pad
DIRECTION INOUT ;
PORT
LAYER metal1 ;
RECT 0 0 100 100 ;
END
END pad
END BGA_PAD4.2.2 GDSII 格式
GDSII 是半导体行业的“老大哥”，几乎所有 EDA 工具都支持。但它有个毛病——二进制格式，可读性差。我记得有一次，封装厂那边用 GDSII 查看我们的版图，结果因为单位换算问题，焊盘位置偏了 0.1 微米。嗯，这种问题排查起来特别痛苦。
注意： GDSII 的单位是微米，但不同工具可能用不同的数据库单位（如 1 nm 或 0.1 nm）。交换数据时，一定要确认单位换算关系。我曾经因为单位没对齐，多花了三天时间排查。
4.2.3 OASIS 格式
OASIS 是 GDSII 的替代者，压缩率更高，解析速度更快。我个人更推荐在大型项目中使用 OASIS，尤其是当芯片规模超过 1 亿个多边形时，GDSII 文件动辄几十 GB，而 OASIS 能压缩到原来的 1/5 到 1/10。
不过，OASIS 也有缺点——不是所有老工具都支持。如果你合作的封装厂还在用十几年前的 EDA 工具，那还是老老实实用 GDSII 吧。
| 格式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| LEF/DEF | 抽象层次高，适合信息交换 | 无法描述完整版图细节 | 芯片-封装协同设计 |
| GDSII | 行业标准，兼容性最好 | 文件大，解析慢 | 传统流程、小规模芯片 |
| OASIS | 压缩率高，解析快 | 部分老工具不支持 | 大规模芯片、先进工艺 |
4.3 规则统一管理策略
规则统一管理，说白了就是让芯片团队和封装团队用同一套规则说话。我见过太多项目，芯片侧用 Calibre 规则，封装侧用 Allegro 规则，两边各查各的，最后对不上。
我建议的做法是：建立一个中央规则库，所有规则以标准格式（如 TCL 或 SKILL）存储，通过版本控制工具（如 Git）管理。每次规则变更，都要走审批流程。
规则统一管理的三个关键点：
- 规则分类：将规则分为芯片内部规则、封装基板规则、协同规则三大类。协同规则又细分为间距规则、对准规则、电气规则等。
- 规则版本化：每次规则变更都要记录版本号、变更人、变更原因。我习惯在规则文件头部加注释块，记录变更历史。
- 规则自动化检查：将规则集成到 CI/CD 流程中，每次提交版图数据时自动触发检查。这样可以尽早发现问题，而不是等到流片前才手忙脚乱。
举个例子，我曾经参与过一个项目，芯片团队和封装团队分布在两个城市。我们建立了一个共享的规则库，每天自动同步。芯片团队改了焊盘尺寸，封装团队第二天就能看到更新后的规则。这样一来，再也没有出现过“焊盘对不上”的尴尬情况。
避坑指南： 我曾经犯过一个错误——把芯片内部的 DRC 规则直接拿给封装团队用。结果封装团队发现规则太严，很多基板走线都报错。后来我才意识到，芯片内部的规则是针对晶圆工艺的，封装基板的规则应该更宽松一些。所以，规则一定要分类管理，不能一刀切。
好了，这一节的内容就到这里。协同规则检查框架的核心就是三层架构、三种数据格式、一套统一规则。你只要把这三点理清楚，协同检查就不会出大问题。