3、协同设计的数据交换格式：LEF/DEF、GDSII、OA数据库、OpenAccess介绍
做芯片封装协同设计，说白了就是一群人围着同一个芯片使劲。你想想看，前端设计、后端布局、封装厂、测试厂，各家用各的工具，各存各的数据。如果没有一套通用的“语言”，那协作起来简直是一场灾难。
我个人习惯把数据交换格式比作“翻译官”。今天我们就聊聊这几位“翻译官”：LEF/DEF、GDSII、OA数据库，还有OpenAccess。嗯，这里要注意，它们各有各的脾气，用错了地方，项目就得翻车。
3.1 LEF/DEF：物理库的“身份证”
LEF（Library Exchange Format）和DEF（Design Exchange Format）是Cadence公司最早推出来的一套标准。我刚开始接触封装设计时，总觉得LEF/DEF是给数字后端用的，跟封装关系不大。后来踩过坑才明白——没有LEF，你连芯片的物理边界都说不清楚。
LEF主要描述什么？
- 单元的尺寸、形状（比如一个标准单元是矩形还是L形）
- 引脚的位置、层次、方向
- 布线障碍（比如哪些区域不能走线）
- 天线效应规则、密度规则
DEF呢？
- 芯片的布局信息（每个单元放在哪里）
- 布线结果（走线路径、过孔位置）
- 电源网络结构
- 分组、区域约束
关键点：LEF是“库”的描述，DEF是“设计”的描述。两者配合使用，才能完整表达一个芯片的物理信息。
我在项目中遇到过一件事：某次做先进封装，芯片的bump排列非常密集。后端同事给的DEF文件里，bump的坐标精度只到微米级。结果封装厂一读，发现bump位置跟基板上的焊盘对不上，差了几个微米。后来我要求所有DEF文件必须保留到纳米级精度，才解决了这个问题。
避坑指南：我曾经因为LEF文件中缺少“最小间距”规则，导致封装基板上的走线间距违规，流片回来短路了。现在我的习惯是：拿到LEF后，先跑一遍规则检查，别急着往下走。
3.2 GDSII：流片的“最终答卷”
GDSII，全称是Graphic Data System II。这玩意儿年纪比我大，诞生于上世纪70年代。但你别看它老，直到今天，所有晶圆厂认的还是它。
GDSII说白了就是一个“多边形描述语言”。它用层（layer）、几何形状（boundary）、路径（path）这些基本元素，把芯片的每一层掩模版画出来。封装设计里，我们通常用GDSII来交付：
- 芯片的顶层金属层（包括bump、RDL）
- 封装基板的布线层
- 硅中介层的TSV（硅通孔）位置
- 微凸点（micro-bump）的阵列
为什么GDSII这么能打？因为它简单、稳定、没有歧义。你想想看，一个文件格式用了50年还没被淘汰，一定有它的道理。
注意：GDSII是二进制格式，不能直接用文本编辑器打开。而且它不包含任何设计规则或电气信息——它只告诉你“长什么样”，不告诉你“能不能用”。
我记得有一次，封装厂反馈说GDSII文件里有一层数据丢失了。排查了半天，发现是导出时层号映射错了。从那以后，我要求团队在导出GDSII时，必须附带一份层号对照表，白纸黑字写清楚。
3.3 OA数据库：设计的“活档案”
OpenAccess（简称OA）是Si2组织推动的一套开放式数据库标准。它跟LEF/DEF、GDSII最大的区别在于：OA是一个可读写、可查询、可增量更新的数据库，而不是一个静态文件。
我个人觉得，OA的出现是为了解决一个痛点：传统的数据交换格式（比如GDSII）只能“一次性导出”，改一点东西就得重新导一遍。而OA数据库允许你：
- 只修改某个单元的某层金属
- 查询某个网络的所有连接关系
- 增量保存设计变更
- 多工具同时访问同一份数据
说白了，OA更像是一个“活的设计档案”，而不是一张“死照片”。
下面这张图展示了OA数据库在协同设计中的核心位置：
从这张图可以看出，OA数据库处于协同设计的“枢纽”位置。它既能从LEF/DEF导入物理库信息，又能导出GDSII给晶圆厂。更重要的是，它允许协同设计工具实时读写数据——这才是“协同”二字的精髓。
3.4 OpenAccess：不止是一个数据库
很多人把OpenAccess和OA数据库混为一谈。其实严格来说，OpenAccess是一个开放标准，而OA数据库是这个标准的一个实现。
OpenAccess标准定义了：
- 数据模型（比如Cell、Net、Layer这些对象怎么组织）
- API接口（怎么读写数据）
- 扩展机制（怎么加自定义属性）
为什么OpenAccess这么重要？因为它是工具中立的。Cadence的工具用OA，Synopsys的工具也用OA（通过Si2联盟）。这意味着你可以用A工具做设计，用B工具做验证，数据不用来回转换。
实际价值：在封装协同设计中，OpenAccess让“前端设计-后端布局-封装设计”这条链路真正跑通了。以前需要手动转换格式，现在直接在同一个数据库里操作。
我曾经参与过一个项目，团队分布在三个城市，用的工具也不一样。前端用Innovus，后端用ICC2，封装用APD。如果没有OpenAccess，光数据转换就能耗掉一半的项目时间。后来我们统一用OA数据库作为数据中台，效率提升了至少30%。
3.5 四种格式怎么选？
说了这么多，你可能会问：那我到底该用哪个？
我的建议是：
| 场景 | 推荐格式 | 原因 |
|---|---|---|
| 交付给晶圆厂 | GDSII | 所有晶圆厂都认，没有歧义 |
| 数字后端与封装协同 | LEF/DEF + OA | LEF/DEF描述物理库，OA做增量更新 |
| 多工具实时协作 | OA数据库 | 支持并发读写，版本管理方便 |
| 长期存档 | GDSII + LEF | 格式稳定，几十年后还能读 |
重要提醒：不要试图用GDSII做协同设计。GDSII是“只读”的，改一点就得重导。协同设计一定要用OA这类可读写的数据库。
嗯，最后说一句。数据格式这东西，选对了事半功倍，选错了天天加班。我个人建议，如果你的团队刚开始做封装协同设计，先从LEF/DEF和GDSII入手，等流程跑顺了，再引入OA数据库。别一上来就想搞大而全，容易翻车。