极客工场

Appearance

共 2,405 字预计阅读约 8 分钟

PrimeTime 文件损坏/截断：SPEF/SDC/网表读入失败速查 ​

更新时间：2026-10-22。FAQ 速查页，属于 EDA 工具排错系列。PrimeTime（简称 PT，Synopsys 的静态时序分析与签收工具，交互壳是 pt_shell）是签收流程的终点，但它消费的每一份输入都来自别的环节：RC 提取工具写 SPEF、DC 写门级网表、约束工程师维护 SDC、功耗分析带 VCD/SAIF。文件在接力中损坏或截断，报错却在 read_parasitics、read_sdc、read_vcd 这里爆出来——读者报错、写者生病，是这类问题最容易跑偏的地方。签收流程背景见 静态时序分析与 PrimeTime 签收，综合侧同款问题见 Design Compiler 文件损坏截断，全簇索引在 开源/EDA 工具报错排查总览。

本文要回答的问题 ​

  • pt_shell 报 unexpected EOF、parse error near EOF，是文件坏了还是 SDC 写错了？
  • .spef.gz 读不进，怎么判断是 gzip 压缩包坏了还是 SPEF 内容坏了？
  • 同一份文件，上游机器能读、PT 这台读不了，源坏了还是传输坏了？
  • 损坏的 SPEF/网表能修吗，什么情况下必须重跑上游签收流程？
  • 怎么让写一半的中间文件永远不被 read_parasitics 读到？

一、报错原文与现象 ​

PrimeTime 侧的典型文案（工程名用占位符代替）：

text
pt_shell> read_parasitics inputs/top.max.spef.gz
Error: Unexpected end of file while reading 'inputs/top.max.spef.gz'. (PARASITIC-25)
Error: Failed to read SPEF file. (PARASITIC-7)
text
pt_shell> read_sdc inputs/top.pt.sdc
Error: parse error near EOF at line 4182 of 'inputs/top.pt.sdc'. (SDC-20)
bash
$ zcat inputs/top.max.spef.gz | tail
gzip: inputs/top.max.spef.gz: unexpected end of file

三种形态要分开看：压缩流截断（unexpected end of file 来自 gzip 层，文件尾部缺失，与 PT 无关，zcat 在 shell 里同样报错）；文本内容截断（SDC、SPEF、Verilog 读到最后一行撞上半个语句，parse error near EOF 的行号约等于文件总行数）；头部就报格式错（第一屏就挂，更像版本不匹配或文件格式不对，方向转 PrimeTime 版本不匹配）。规律只有一条：报错位置越靠近文件尾，截断的嫌疑越大。 顺带注意，读不进也可能是文件压根不在或没有权限，那两类见 PrimeTime 路径/文件不存在 与 PrimeTime 权限被拒，本文只管「在、也能读，但内容是残的」。

二、可能原因速查表 ​

报错现象可能原因处置
gzip 报 unexpected end of fileSPEF/SAIF 压缩写入中途被 kill上游重新提取并压缩，重传
parse error near EOF，行号接近总行数SDC/网表写中断，尾部语句残缺查生成日志，重新生成
文件大小明显偏小（该几百 MB 只剩几 MB）磁盘满/配额超限导致写失败先清空间，见磁盘满专篇
大小正常但 md5 与源端不符rsync/scp/NFS 传输半截或污染重新传输并比对校验和
偶发，重跑一次又好了NFS 缓存延迟或并发同写一个文件加作业依赖，输出路径隔离
解压后 SPEF 头部正常、尾部缺失tar/zip 包下载不完整校验包完整性后重新解压
VCD/SAIF 读到一半报 premature end仿真 dump 中途结束或被截断重跑仿真或让仿真侧重新导出
所有同事都读不进、源端也读不进源文件本身就是坏的回滚版本库或重跑上游 STA 流程

三、逐条排查展开 ​

第一刀：先验文件本体，别动 PT。 四条命令一分钟定性：

bash
ls -l inputs/top.max.spef.gz
stat inputs/top.pt.sdc          # 大小与修改时间
tail -c 200 inputs/top.pt.sdc   # 文本文件看结尾
gzip -t inputs/top.max.spef.gz  # 压缩包完整性测试，echo $? 为 0 才完好

该有几百 MB 的 SPEF 只剩几 MB，截断实锤；SDC 正常以完整命令行收尾，结尾停在半个 set_clock_groups 中间，就是写中断；gzip -t 非零说明坏在压缩流本身，不用进 pt_shell 再试一遍。stat 里的修改时间还要和上游作业的结束时间对——时间戳早于作业结束，文件是上一次运行的残留。功耗分析带进来的 VCD/SAIF 同理：这两类文件有明确的收尾标志（VCD 以 $enddefinitions 开头、以 $dumpoff 之后的结束段收尾，SAIF 以配对的括号闭合），tail 看不到正常收尾就是仿真 dump 中途断了，用 wc -l 和上一次成功运行的行数对比，差一个数量级即可直接判残，不必进 PX 流程再试。

第二刀：区分「源坏了」还是「传输坏了」。 这是跨机流程最关键的分叉，靠校验和说话，不靠感觉：

bash
md5sum inputs/top.max.spef.gz                 # PT 侧
# 到生成文件的机器上跑同一条命令，两边对拍
md5sum /proj/rcx/out/top.max.spef.gz          # 源端

两边 md5 不一致 = 传输环节坏了（rsync 半截、NFS 断连、磁盘满了还在拷），重新传输即可，源文件不用动；两边 md5 一致且都坏 = 源就是残的，找上游重生成。顺手翻上游日志的结尾：RC 提取或仿真作业若被 LSF 限时杀掉、机器重启、OOM，进程连报错的机会都没有，只留下一个头完整、尾残缺的文件——PT 自身崩溃也会留下半截写出物，见 PrimeTime 段错误崩溃。磁盘与配额是写中断最常见的「合法」理由，专篇处理见 PrimeTime 磁盘满/配额超限。

第三刀：偶发问题查 NFS 与并发。 一台机器写、另一台立刻读，可能撞上网络文件系统的客户端缓存，读到中间态；两个作业写同一路径则互相覆盖。特征是不可稳定复现、文件时间戳每次看都在变。处置不是重跑碰运气，而是流程衔接处加调度器作业依赖（不是 sleep 30），每个任务写独立临时路径，完成后再原子改名到位。

eda/ts-primetime-file-corrupt-truncated.md D2 示意图

读图抓住中间那个分叉：蓝色两步是分诊，先给文件本体定性，再用 md5 对拍决定走哪条橙色支线——文件本体残缺往上游日志走（写中断、磁盘、NFS、并发），文件完好但与源端不符只重传、不惊动上游。两条支线最后都汇到紫色收尾：校验通过后才允许重新读入 PT。不要跳过对拍直接重跑整个签收流程，那是用最贵的方式修最便宜的故障。

恢复按文件身份分三类，不要试图手修半截文件。 SPEF、网表、VCD/SAIF 都是派生物，首选重跑生成环节（重新 RC 提取、重新导出、重跑仿真 dump）；手写 SDC 和 Tcl 脚本是源头文件，残了只能靠版本库找回上一个好版本（git log -p <file> 看历史、git checkout -- <file> 回退），这也是约束必须入库、中间产物不该入库的原因；第三方交付的库或包则以发布方校验和为准，对不上就重下或找交付方重发。若损坏文件已经被签收脚本消费并产出时序报告，报告一并作废，从 read_parasitics 起重跑上游 STA signoff 流程——基于残缺寄生参数的时序结论比没有结论更危险。

四、预防与纪律 ​

  • 写出走「临时名 + 原子改名」：先写 top.max.spef.gz.tmp，写完 gzip -t 自检通过再 mv 成正式名；改名是原子的，PT 永远只会看到完整文件或看不到文件。
  • 生成即算校验和：上游产出后立刻 md5sum > top.max.spef.gz.md5，PT 侧 md5sum -c 验完再读，跨机传输环节同样执行。
  • 压缩文件带完整性自检：流程脚本里对所有 .gz 输入先跑 gzip -t，非零直接 fail-fast，别等 parse error 在 pt_shell 里出现。
  • 不共享中间文件：每个作业、每个 corner 用独立输出目录，禁止两个任务同写一个 SPEF/SDC；作业衔接用调度器依赖同步，不用 sleep。
  • 源头文件入库、派生物不入库：边界守住后，恢复就只剩「重跑上游」和「版本库回滚」两个机械动作。

这一篇在知识体系里的位置 ​

本篇是 EDA 排错速查簇中「PrimeTime 文件完整性」节点的 FAQ 页，与 PrimeTime 路径/文件不存在（文件在不在）、PrimeTime 权限被拒（能不能读）构成文件问题三分面；写中断的上游病因深入见 PrimeTime 磁盘满/配额超限 与 PrimeTime 段错误崩溃，读入报错若落在文件头部则转 PrimeTime 版本不匹配。综合侧的对应篇是 Design Compiler 文件损坏截断，全簇索引见 开源/EDA 工具报错排查总览。

一句话总结 ​

PrimeTime 读到损坏或截断文件时，先用 ls、tail、gzip -t 给文件本体定性，再用两端 md5 对拍区分「写坏」与「传坏」：传坏只重传，写坏就顺上游日志查 kill、磁盘满、NFS 与并发覆盖；恢复只走派生物重跑、源头文件版本库回滚、交付包重下三条路，已被污染的时序结论一律从 read_parasitics 起重跑；防复发靠临时名加原子改名、生成即算校验和、压缩包先 gzip -t、中间文件不共享四条护栏。