Calibre 输入文件损坏或截断：GDS/OASIS/网表读入失败速查
更新时间：2026-10-22。FAQ 速查页，属于 EDA 工具排错系列。Calibre（Siemens EDA 的物理验证工具，DRC/LVS/PEX 三件套）本身不产生版图，它消费的每一份输入都是接力来的：设计端导出 GDSII 或 OASIS、电路侧出 CDL/SPICE 网表、PDK 维护 SVRF rule deck。文件在导出、压缩、跨机传输、版本库拉取任何一环被写残，报错都在 calibre 读入阶段才爆出来——读者报错、写者生病。与启动配置问题不同，这类故障的特征是：文件在、也能打开，但内容是残的。runset 与环境变量问题见 Calibre 配置解析失败速查，流程全貌见 Calibre 物理验证实操，全簇索引在 开源/EDA 工具报错排查总览。
本文要回答的问题
- calibre 报
Premature end of file、Unexpected EOF，是 deck 写错了还是输入文件残了？ - GDSII 报
Bad record type、OASIS 报invalid byte，文件还有救吗，怎么确认坏在哪一段？ - 网表在最后一行 parse fail、缺
.ENDS，怎么判断是写中断还是本来就没导出全？ - 同一份 GDS，同事机器能读、我这台读不了，源坏了还是传输坏了？
- 版本库里拉下来的 GDS 只有几百字节，是什么东西？
一、报错原文与现象
Calibre 侧的典型文案（工程名用占位符代替）：
***** ERROR: Premature end of file encountered while reading
GDSII file "/proj/demo/layouts/top.gds".
***** ERROR: Unable to read layout primary cell "TOP".***** ERROR: Bad record type (0x00) encountered in GDS stream
at file offset 1835008.
***** ERROR: OASIS reader: invalid byte 0xFF in CBLOCK compressed data.***** ERROR: Unexpected end of file while parsing netlist near line 92140
of "/proj/demo/netlist/top.cdl".
Expected .ENDS or .ENDSUBCKT before EOF.$ ls -l layouts/top.gds layouts/top.gds.gz
-rw-r--r-- 1 demo demo 326 Oct 22 09:10 layouts/top.gds
-rw-r--r-- 1 demo demo 8.3M Oct 22 09:12 layouts/top.gds.gz四种形态要分开看。版图二进制截断（GDSII/OASIS）报 Premature end of file 或记录类型非法，文件通常停在一串结构记录的中间；GDSII 是定长记录流，任何 2 字节 record header 对不上合法表就是 Bad record type，OASIS 的压缩块（CBLOCK）少一个字节都会 invalid byte。文本网表截断（CDL/SPICE/Verilog 网表）报 parse fail 且行号约等于文件总行数，结尾撞上半个子电路定义。rule deck 截断则是 INCLUDE 链中某个被包含文件 0 字节或尾部缺失，报的是规则文件内的语法错，方向别搞反。规律只有一条：报错位置越靠近文件尾，截断的嫌疑越大；头部第一屏就挂，更像格式或版本问题。 最后那个 ls 是最扎眼的形态：明文 .gds 只有 326 字节而压缩包有 8.3MB——小文件多半是版本库 LFS 指针没拉下来，内容是一行指针文本而非版图。
二、三类输入的原因速查表
| 输入类型 | 报错现象 | 可能原因 | 处置 |
|---|---|---|---|
| GDSII 二进制 | Premature end of file | 导出/传输中途中断，尾部 endlib 记录缺失 | 从设计端重新导出并重传 |
| GDSII 二进制 | Bad record type at offset | ASCII 模式 FTP/错误解码污染字节，或写到一半 | binary 模式重传，md5 对拍 |
| OASIS 二进制 | invalid byte / CBLOCK 错 | .gz 解压不完整、OASIS 写出端崩溃 | gzip -t 验包，重新解压或重导 |
| GDS/OASIS | 文件只有几百字节、头部是文本 | git LFS 指针未拉取（smudge 失败） | git lfs pull 重新拉取 |
| CDL/SPICE 网表 | parse fail near 最后一行 | 缺 .ENDS/.ENDSUBCKT，括号不闭合 | 查导出日志，重新导出网表 |
| Verilog 网表 | Unexpected EOF，少 endmodule | 网表写出被 kill、磁盘满截断 | 先清空间，再重跑导出 |
| rule deck | INCLUDE 文件内语法错/0 字节 | deck 同步半截、NFS 读到中间态 | 重新同步 PDK deck，对拍校验和 |
| 全部类型 | 偶发，重跑又好 | NFS 写读竞争、两个作业同写一路径 | 作业依赖 + 临时名原子改名 |
| 全部类型 | 大小正常但 md5 不符 | rsync/scp 传输半截或污染 | 重新传输并比对校验和 |
三、逐条排查展开
第一刀：先定位是哪个输入文件，再验本体，别动 deck。 calibre 一次 run 会消费版图、网表、INCLUDE 链上的一堆规则文件，报错信息里的路径就是断点；若只给了 cell 名没给路径，回 runset 看 LAYOUT PATH 与 SOURCE PATH（LVS 场景）分别指向哪个文件。定性命令一分钟跑完：
ls -l path/top.gds # 大小与修改时间，该几个 GB 的只剩几 MB 即实锤
file path/top.gds # 二进制应报 GDS II stream；报 ASCII text 就不是版图
tail -c 120 netlist/top.cdl # 文本网表看结尾是否 .ENDS 收尾
gzip -t path/top.oasis.gz # 压缩包完整性，echo $? 为 0 才完好三类输入各有更对口的校验工具（具体命令名以本单位安装的 Calibre 版本为准）：GDSII 可用 calibredrv 的 Tcl 接口打开并遍历层级，或用流片套件附带的 strmin/strmclip（GDS 读入/裁剪工具）尝试读入，读到哪个 offset 报错就说明残在什么位置；OASIS 同理走 calibredrv 打开校验。文本网表直接 tail 与 wc -l：SPICE 子电路以 .SUBCKT 开头、.ENDS 收尾，括号与 continue 行（+ 续行）成对出现，结尾停在半个器件行就是写中断；CDL 网表是 LVS 器件识别的输入，残缺会直接牵连 LVS 器件识别与提取。rule deck 则沿 INCLUDE 链逐个 ls -l，第一个 0 字节或修改时间异常的文件就是断点；deck 五段结构参见 Calibre SVRF rule deck 解剖。
第二刀：区分「源坏了」还是「传输坏了」。 这是跨机流程最关键的分叉，靠校验和说话：
md5sum path/top.gds # calibre 侧
md5sum /proj/tapeout/out/top.gds # 源端，同一条命令对拍两边不一致 = 传输环节坏了，重新传输即可，源文件不用动；两边一致且都坏 = 源就是残的，找上游重新导出。跨机损坏有几个固定剧本：FTP 用 ASCII 模式传二进制，换行字节被改写，GDS 必报 Bad record type；NFS 上写一半被读，导出作业还没结束 calibre 就启动，读到中间态；磁盘满或配额超限，写出端静默截断，只留头完整的文件；.gz 下载不完整，gzip -t 直接非零；git LFS 指针未拉取，文件头是一行 version https://git-lfs...，git lfs pull 即可。处置不是重跑碰运气，而是传输一律 binary 模式、带校验和对拍，作业衔接用调度器依赖而不是 sleep 30。
读这张图抓住蓝色分诊三步与中间的分叉：红色入口是读入即报错，先定位文件并给本体定性，再按版图二进制、文本网表、rule deck 三类分流，然后用 md5 对拍决定走哪条橙色支线——传坏只重传（含重新解压、LFS pull），源坏才惊动上游重新导出。紫色收尾是用 calibredrv 或最小配置复跑确认完整读入。不要跳过对拍直接让设计端重导全芯片 GDS，那是用最贵的方式修最便宜的故障。
恢复按文件身份分三类，不要试图手修半截二进制。 版图（GDS/OASIS）与网表都是派生物，首选重新导出：从版本库取回设计数据，让导出作业重跑并检查其日志结尾——导出端被调度系统限时杀掉、OOM、机器重启时，进程连报错的机会都没有，只留下残文件。rule deck 是 PDK 交付物，以发布方校验和为准，对不上就重新同步或向 PDK 厂重发，手工补 tail 几乎必然改掉检查语义，签核流程不允许。若残缺输入已经被消费并产出 DRC/LVS 报告，报告一并作废，从读入阶段起重跑——基于半截版图的「clean」比没有结论更危险。calibre 进程自身崩溃也会留下半截写出物，那种形态见 Calibre 段错误崩溃速查。
四、预防与纪律
- 写出走「临时名 + 原子改名」：上游先写
top.gds.tmp，写完自检通过再mv成正式名；改名是原子的，calibre 永远只会看到完整文件或看不到文件。 - 传输强制 binary 模式并附带校验和：产出端
md5sum > top.gds.md5，接收端md5sum -c验完再提交 run；FTP/共享目录交接同样执行。 - 压缩文件先
gzip -t：流程脚本对所有.gz输入先跑完整性测试，非零直接 fail-fast，别等 OASIS reader 在 run 里报错。 - LFS 与磁盘前置检查：克隆/更新后跑
git lfs pull并核对大文件字节数；提交节点的磁盘水位纳入作业前置检查，写满导致的截断占这类故障的大头。 - 中间文件不共享：每个 run 用独立工作目录，禁止两个作业同写一个 GDS 或网表；上下游用调度器依赖同步。
这一篇在知识体系里的位置
本篇是 EDA 排错速查簇中「Calibre 输入完整性」节点的 FAQ 页，按失败阶段与姊妹篇分工：文件能读但启动配置（runset、变量、模式、版本）失败见 Calibre 配置解析失败速查，run 中途进程消失见 Calibre 段错误崩溃速查。背景机制见 Calibre 物理验证实操、Calibre SVRF rule deck 解剖 与 LVS 器件识别与提取，全簇索引见 开源/EDA 工具报错排查总览。
一句话总结
Calibre 输入文件损坏或截断时，先按报错路径定位是版图二进制、文本网表还是 rule deck，用 ls、file、tail、gzip -t 与 calibredrv/strmin 给文件本体定性，再用两端 md5 对拍区分「传坏」与「写坏」：传坏走 binary 重传、重新解压或 git lfs pull，写坏让上游查导出日志后重新导出，残缺输入产出的报告一律作废重跑；防复发靠临时名原子改名、传输带校验和、压缩包先测完整性、LFS 与磁盘前置检查四条护栏。