GDS 交付检查清单：交付包组织、版本关联与接收复验
GDS 文件能打开，只说明接收方读到了一份版图数据，不代表它属于正确版本，更不代表时序、功耗、物理验证等 signoff 结论已经成立。这份 GDS 交付检查清单关注另一件事：怎样把版图及其上下文组织成一个可核对、可复验、可长期保存的交付包。技术签核的完整项目应另行对照 芯片 signoff 30 项检查清单，两份清单不能互相替代。
本文要回答的问题：GDS 交付检查清单怎么执行
- 交付包里除了版图，还应放哪些能够确定身份与用途的文件？
- 顶层单元、层映射和 GDS/OASIS 格式选择要记录什么？
- 库、网表、约束与报告如何关联到同一条版本基线？
- 校验和、只读归档和接收方复验分别防什么错误？
- 有遗留项时，怎样交付而不把它包装成已完成验收？
一、先确认交付的是哪一份数据
交付检查从身份开始，而不是从文件大小开始。包名应能区分项目、芯片或模块、交付用途和版本；内部评审、工程样品、补充交付等用途也应明确。不要把 final、new_final 当作版本，也不要让同名文件在不同日期被悄悄替换。
图中三组信息缺一不可：对象与基线回答「交的是哪一版」，语义与关联回答「应当怎样解释」，封存与复验回答「传输后是否仍是同一份」。只有版图文件而没有后两组信息，接收方即使成功读取，也无法独立判断它是否与配套资料一致。
交付前还要冻结目录边界。临时脚本、个人工作目录、无关实验输出和凭据不得混入；必须提供的辅助资料则放入明确子目录，并在清单中登记，而不是靠口头补充。
二、顶层、层映射与格式必须写清
顶层单元名称是读取版图时的入口，应与交付方约定完全一致。还要记录数据库单位、用户单位或精度信息、坐标原点约定，以及是否包含多个顶层。若交付的是模块而不是整芯片，应写清抽象边界、层次展开要求和它与上级集成的关系。
层映射表不能只给一个下载位置。至少列出工艺层名称、GDS/OASIS 层号与 datatype、用途、映射方向和例外规则；文本层、边界层、填充层及特殊标记层也要说明是否包含。发送与接收使用不同映射表时，应分别定版，避免双方拿同名但不同内容的表解释同一份数据。
GDSII 与 OASIS 的选择由接收流程、工具兼容性和双方约定共同决定，不能只按压缩率决定。交付一种格式时，写明版本和必需读取选项；同时交付两种格式时，要声明它们是否由同一源数据库、同一批次导出，并把二者都纳入清单。不能把「另存为另一种格式」默认成语义已经等价验证。
三、配套资料要关联到同一基线
库、网表和约束的价值在于帮助接收方理解版图上下文，因此必须能追溯到对应版本。标准单元库、宏单元或存储器模型若只作为参考，应标注用途和许可边界；不需要交付的输入写「不适用」，不要留空让人猜。网表要注明是何种视图、对应哪个顶层，约束则注明模式、角和适用范围。
报告采用索引关联，不重新编造签核结论。索引可记录报告名称、对应对象、数据版本、生成来源标识和存放路径；若某项报告未提供，就写未提供及原因。报告存在也不自动扩大其结论范围，例如模块级结果不能直接写成整芯片结果。
下面是一份完整模板。尖括号均为待替换占位符；示例目录名 demo_chip 仅作虚构示意，不代表任何真实项目，也不表示已经完成流片验收或 signoff。
# GDS/OASIS 交付检查清单
## A. 交付对象与版本
- [ ] 项目/芯片/模块：`<名称>`；交付用途：`<用途>`
- [ ] 交付包版本：`<版本>`；源数据库版本或变更标识：`<标识>`
- [ ] 导出批次标识：`<标识>`；交付日期：`<YYYY-MM-DD>`
- [ ] 交付方与接收方接口人：`<角色或姓名>`；约定交付范围：`<范围>`
- [ ] 本次相对上一交付版的变更：`<变更摘要或变更记录路径>`
## B. 顶层、数据库与层映射
- [ ] 顶层单元：`<TOP>`；单顶层/多顶层：`<说明>`
- [ ] 数据库单位与精度：`<数值及单位>`；坐标原点约定：`<说明>`
- [ ] 模块交付边界与层次展开要求：`<说明或不适用>`
- [ ] 层映射表文件及版本：`<路径与版本>`
- [ ] 特殊层、文本层、边界层、填充层处理：`<逐项说明>`
## C. 格式与读取约定
- [ ] 交付格式：`<GDSII|OASIS|两者>`；格式版本：`<版本>`
- [ ] 必需读取选项、过滤或合并规则：`<说明>`
- [ ] 两种格式同时交付时，同源导出关系：`<说明>`
- [ ] 接收方已知兼容性限制：`<说明或无>`
## D. 库、网表、约束与报告关联
- [ ] 必需库/模型清单、版本与用途：`<路径、版本、用途>`
- [ ] 网表视图、顶层与版本：`<路径及对应关系>`
- [ ] 约束文件、模式、角与适用范围：`<路径及对应关系>`
- [ ] 报告索引：`<路径>`；每项均关联对象与数据版本
- [ ] 未提供或不适用项：`<逐项写明，不保留空白>`
- [ ] 许可、保密与再分发限制：`<说明>`
## E. 文件清单、校验和与目录
- [ ] 文件清单覆盖所有交付文件，含路径、字节数、用途
- [ ] 每个文件均记录校验和；算法：`<双方约定算法>`
- [ ] 校验和清单自身纳入包级版本记录，生成后不再修改内容文件
- [ ] 目录无临时文件、凭据、个人路径和范围外数据
- [ ] 虚构目录示意：`demo_chip/{layout,lib,netlist,constraints,reports,manifest}`
## F. 冻结、归档与接收复验
- [ ] 内容冻结后生成最终清单，再制作归档副本
- [ ] 归档副本设为只读；另留可写工作副本处理后续问题
- [ ] 保存位置、保留期限、访问权限和恢复责任已记录
- [ ] 接收方按同一算法重算校验和，并核对文件数量、路径与字节数
- [ ] 接收方按约定顶层、层映射和读取选项检查可读性
- [ ] 复验仅确认交付一致性与约定检查项，不替代 signoff
- [ ] 差异记录包含文件名、预期值、实际值、影响和责任人
## G. 遗留项与交付状态
- [ ] 未关闭项逐项记录：`<编号、现象、影响范围、临时措施、责任方>`
- [ ] 明确标注交付状态：`<待补充|有条件接收|完成约定复验>`
- [ ] 下一版需要替换或新增的文件已列出
- [ ] 任何遗留项均未写成已通过，未暗示已完成流片验收四、用校验和与只读归档守住同一份内容
文件清单是交付包的目录事实源，至少包含相对路径、字节数、用途和校验和。校验和算法由双方事先约定，关键是接收方能独立重算，而不是清单看起来足够长。打包、压缩或复制到另一存储位置后，都应对最终实际传输的对象复验；只校验打包前目录，无法发现归档过程造成的遗漏。
只读归档用于阻止已定版内容被就地编辑。发现差异时，不直接覆盖归档文件，而是从可写工作副本修正、提升交付版本、重新生成清单与校验和，再发起复验。访问权限与保留策略也要记录，否则「有归档」不等于以后找得到、读得回。
读这张闭环图要抓住「差异必须升版回流」：蓝色是整理与核对，绿色是接收复验，紫色是只读归档，红色和橙色分别表示差异记录与修正。绿色路径只代表约定的交付复验完成，不代表任何签核项目自动通过。
五、接收复验与遗留项决定能否关闭交付
接收方应使用交付清单独立核对，而不是只回一句「已收到」。复验至少包括文件集合一致、校验和一致、顶层可读、层映射版本匹配，以及配套资料引用路径有效。发现问题时保留原交付包，以差异单沟通，避免双方各自修改后失去共同基线。
遗留项可以随交付一起透明记录，但必须写出影响范围和处置责任。例如缺少某份参考约束，只能说明该资料待补，不能顺带宣称相关分析已经完成。交付状态建议使用「待补充」「有条件接收」「完成约定复验」等有限措辞，与 signoff 状态分开维护；后者仍按 signoff 30 项检查清单逐项确认。
这一篇在知识体系里的位置
本篇处在物理实现完成后的数据交付边界，负责交付包组织、身份关联、完整性校验和接收闭环；芯片 signoff 30 项检查清单负责签核项目是否完成及其证据范围。实际项目中两者应引用同一数据版本，却分别给出结论，避免用交付复验代替技术签核。
总结
GDS 交付检查清单的核心是让接收方拿到「同一版、读得懂、可复验」的数据包：先锁定对象与版本，再明确顶层、层映射和格式选择，把库、网表、约束与报告关联到同一基线，最后用文件清单、校验和和只读归档守住内容。接收差异应升版重交，遗留项应透明列出；GDS 文件存在、可读或校验和一致，都不等于 signoff 通过，更不等于已经完成流片验收。