3、签核前的数据准备：设计数据完整性检查、文件格式转换与标准化

签核前最怕什么？

我最怕半夜收到流片经理的消息：「你的GDSII少了一层金属。」

嗯，这种事发生过一次，就再也不想有第二次了。所以今天咱们聊聊签核前的数据准备——说白了，就是把你手里的设计数据收拾得干干净净，让签核工具和代工厂挑不出毛病。

3.1 设计数据完整性检查

完整性检查，我习惯叫它「查户口」。你得确保每个文件都在、每个层次都对、每个属性都填了。

3.1.1 文件清单核对

先列个清单，看看你缺了啥。我一般用脚本跑一遍：

#!/bin/bash
# 我的完整性检查脚本（简化版）
required_files=(
  "top.gds"
  "top.lvs.v"
  "top.lef"
  "top.tf"
  "top.map"
)

for file in "${required_files[@]}"; do
  if [ -f "$file" ]; then
    echo "[OK] $file 存在"
  else
    echo "[MISSING] $file 缺失！"
  fi
done

别小看这一步。我曾经有个项目，LVS网表文件名写错了大小写，结果签核工具直接报错，耽误了整整一天。

3.1.2 层次结构验证

GDSII文件里，层次结构必须完整。我见过最坑的情况是：顶层调用了底层模块，但底层模块的GDS根本没合并进来。

检查方法很简单：

用calibre -gdscheck跑一遍
或者用klayout打开看一眼
重点看：是否有悬空的instance、是否有未定义的cell

⚠️ 注意： 有些工具对层次深度有限制。比如某代工厂要求GDSII的层次不超过64层。你想想看，如果设计里嵌套了70层，签核工具直接崩溃，那画面...

3.1.3 属性与标签检查

代工厂的DRC/LVS规则里，经常要求某些层次有特定的属性。比如：

层次	要求属性	常见问题
M1	datatype=0	有人误设为datatype=1
VIA1	必须为矩形	有人画成了多边形
PAD	text标签必须存在	漏写pad name

我个人习惯写个Tcl脚本，自动扫描所有层次属性：

# 检查GDSII中所有层次的datatype
foreach layer [get_layers] {
  set datatype [get_layer_datatype $layer]
  if {$datatype != 0} {
    puts "Warning: Layer $layer has datatype=$datatype"
  }
}

3.2 文件格式转换与标准化

签核时，你手里的数据可能是GDSII、OASIS、DXF混在一起的。代工厂只认一种格式，所以必须统一。

3.2.1 GDSII → OASIS

GDSII是经典格式，但文件太大。OASIS压缩率高，传输快。我建议：

小设计（<1GB）：用GDSII就行，兼容性好
大设计（>10GB）：必须转OASIS，否则传输时间受不了

转换命令示例：

# 用klayout转换
klayout -b -r convert.gds2oasis.rb -rd input=top.gds -rd output=top.oas

# 用calibre转换
calibre -gds2oasis top.gds -o top.oas

💡 小技巧： 转换后一定要做一致性检查。我遇到过OASIS转换后丢失了某些cell的情况。用klayout打开两个文件对比一下，花不了几分钟。

3.2.2 DXF格式处理

DXF通常来自封装设计或机械设计。它和GDSII的坐标系、精度都不一样。

常见坑：

DXF的单位是mm，GDSII的单位是μm，差1000倍
DXF的圆在GDSII里会被近似成多边形，精度不够会出问题
DXF的图层命名和GDSII的layer number需要映射

我写过一张映射表，分享给你：

DXF图层名	GDSII Layer	说明
0	1/0	边框
OUTLINE	2/0	外形
METAL_TOP	10/0	顶层金属

3.2.3 标准化命名规范

文件命名也得统一。我见过最乱的命名：

top_final_v3.gds
top_真的最终版.gds
top_20240315_修改.gds

嗯，这种命名方式，签核时你自己都分不清哪个是最终版。

我建议的命名规范：

项目名_模块名_版本号_日期.gds
例如：chipA_top_v1.2_20240315.gds

3.3 版本管理与变更追踪

签核过程中，数据可能改好几版。没有版本管理，你就是在玩火。

3.3.1 使用Git管理设计数据

很多人觉得Git只适合代码，其实GDSII、LEF这些二进制文件也能用Git LFS管理。

# 初始化仓库
git init
git lfs track "*.gds"
git lfs track "*.oas"
git add .
git commit -m "Initial commit: v1.0 baseline"

每次修改后，commit信息要写清楚：

fix: 修正M1短路问题
update: 根据代工厂DRC反馈修改
feat: 添加PAD层

3.3.2 变更日志（Change Log）

我习惯在项目目录下放一个CHANGELOG.md：

# Changelog

## v1.2 (2024-03-15)
- 修复：M1层短路（DRC violation #123）
- 更新：VIA尺寸从0.2um改为0.25um
- 新增：PAD层text标签

## v1.1 (2024-03-10)
- 初始签核版本

  📌 重要： 每次变更都要记录「谁、什么时间、改了哪里、为什么改」。签核审计时，代工厂可能会问：「这个版本和上一个版本有什么区别？」你拿出Change Log，一目了然。

3.3.3 版本对比工具

GDSII文件怎么对比差异？我推荐：

klayout：自带diff功能，可以高亮显示差异区域
calibre -gdsdiff：命令行对比，适合自动化脚本
icv -compare：Cadence的工具，功能强大但贵

举个例子，用klayout对比两个版本：

klayout -b -r diff.rb -rd a=top_v1.1.gds -rd b=top_v1.2.gds -rd output=diff.gds

生成的diff.gds里，红色是删除的部分，绿色是新增的部分。嗯，这个功能救过我很多次。

3.4 本章知识体系

下面这张图，是我自己总结的签核前数据准备流程：

🔧 实战建议： 把这套流程写成自动化脚本，每次签核前跑一遍。我自己的脚本大概200行Python，能检查文件完整性、格式一致性、版本号是否正确。省下来的时间，喝杯咖啡不香吗？

📚 课程目录

3、签核前的数据准备：设计数据完整性检查、文件格式转换与标准化

3.1 设计数据完整性检查

3.1.1 文件清单核对

3.1.2 层次结构验证

3.1.3 属性与标签检查

3.2 文件格式转换与标准化

3.2.1 GDSII → OASIS

3.2.2 DXF格式处理

3.2.3 标准化命名规范

3.3 版本管理与变更追踪

3.3.1 使用Git管理设计数据

3.3.2 变更日志（Change Log）

3.3.3 版本对比工具

3.4 本章知识体系