Yosys 文件损坏或截断读入报错速查

更新时间：2026-10-23。FAQ 速查页，面向用 Yosys 做开源综合流程的读者。先建立一个正确预期：Yosys 的输入输出几乎全是文本——.v/.sv 源文件、.ys 脚本、read_json/write_json 的 .json 网表、write_ilang 的 .il 中间表示。报"文件损坏"时，坏掉的一般不是工具本身，而是某个文本产物被写了一半、混进了异物、或传丢了尾巴。这些文本都能用肉眼检查、用版本库恢复、用重跑重新生成——只要 RTL 源文件还在，任何中间产物损坏都不是大事。如果报错是源文件本身写得不对（而不是被截断/污染），方向不同，见 Yosys 语法解析报错速查。

本文要回答的问题

• read_verilog 报语法错误，但文件明明没改过，是什么情况？
• 综合中途 Ctrl-C 或断电后，下次读 .json 网表报错，还能用吗？
• .v 文件里出现 <<<<<<< 这样的怪行是什么，怎么清？
• 并行 make 时偶发读入失败，重跑又好了，病根在哪？
• 怎么快速判断一个文件是"写了一半"还是"内容错了"？
• 工程放在 Dropbox/网盘目录里，为什么文件特别容易坏？

一、典型现象：报错原文长这样

真实环境里最典型的几类报错原文（路径与行号因工程而异）：

ERROR: syntax error, unexpected TOK_ID at top.v:1847
ERROR: syntax error, unexpected $undefined at top.v:1847
ERROR: Can't open input file `build/top.json' for reading: No such file or directory
ERROR: Unexpected end of JSON data in file build/top.json
ERROR: syntax error, unexpected OP_LT at rtl/fifo.v:96

三种长相各对应不同层次：前两种是读到文件中途断掉（语法分析走到 EOF 发现语句没结束，行号往往指向文件末尾附近）；第三种是文件根本没生成出来或路径不对；第四种是 .json 网表被截断（JSON 括号没闭合）；第五种最有迷惑性——unexpected OP_LT 出现在文件中段，多半是 <<<<<<< 冲突标记的第一个 < 被当成了小于号。最后一行的行号通常就是冲突标记所在行，直接跳过去看即可。

二、原因速查表

现象	根因	快速验证	处置
Ctrl-C/断电后网表读不入	.json/.il 写了一半，尾部缺失括号	tail -c 200 build/top.json 看结尾是否为完整 }	重跑生成该产物的 Yosys 步骤，产物可再生不必修
磁盘满之后综合报奇怪错误	写产物时磁盘满，输出被截断	df -h 看空间；产物文件大小异常小	清磁盘（见磁盘写满篇）后删中间产物全量重跑
并行 make 偶发读入失败	两个任务写同一产物文件互相覆盖	看 Makefile 里多个目标是否依赖同一中间文件	给中间产物分目录命名，或加 .NOTPARALLEL
网盘目录里文件反复坏	同步客户端半截上传/双机竞争写入	看目录里是否出现 conflicted copy 副本	工程迁回本地盘，同步盘只放归档压缩包
.v 中段报 OP_LT/语法错	git 合并冲突标记 <<<<<<< 残留	grep -n '^<<<<<<<' rtl/*.v	解决冲突删除标记行，git checkout 或手工取舍
下载的库文件读入报错	传输不完整，文件尾部缺失或校验和不对	sha256sum 对比发布方给的校验值	重新下载；用压缩包传输并核对大小与哈希
报错行号在文件最末尾	任何原因导致的尾部截断通用特征	tail -5 看最后一行是否是半条语句	源文件从版本库恢复；中间产物重跑生成

三、排查决策图

修这类问题的最短路径是：先分清坏的是"源文件"还是"中间产物"——源文件要修或恢复，中间产物直接删掉重跑，两者处置完全不同。

颜色按角色区分：红色是问题入口，蓝色是两步排查动作，橙色是三类修复手段，绿色是验证通过，紫色是长期预防。读这张图抓住一条主线：先看坏的是源文件还是中间产物——中间产物（.json/.il/.blif）从来不用修，删掉让 Yosys 重新生成就行；只有 RTL 源文件和外部库文件才需要恢复或重下。

四、逐条排查

第一步，看报错行号定位损坏位置。 Yosys 的解析报错会给出文件名与行号（at top.v:1847）。行号接近文件末尾 = 典型尾部截断；行号在文件中段且报 OP_LT/OP_GT 这类运算符错误 = 高度怀疑冲突标记。先 wc -l 拿到文件总行数，和报错行号对一下，立刻能分出这两类。

第二步，检查文件尾与异物。 用 tail -5 文件名 看最后几行：正常 .v 应以 endmodule 结束，正常 .json 网表应以闭合的 } 结束；如果最后一条语句写到一半戛然而止，就是写入截断。接着搜冲突标记：grep -n '^<<<<<<<' rtl/*.v，这是 git 合并冲突没解决就保存的铁证。每一组 <<<<<<< ... ======= ... >>>>>>> 之间是两边版本的内容，人工取舍一份、删掉三行标记即可；如果冲突很多，更省事的办法是 git checkout --theirs 或 --ours 整体选一边再手工补。

第三步，分清源文件与中间产物，走不同恢复路径。 这是 Yosys 流程和 GUI 工具最大的不同：开源流程里 .json、.il、.blif、.edif 全是命令行可再生成的中间产物，坏了直接删，重跑 yosys -p "read_verilog ...; synth; write_json ..." 就回来了，一秒钟的事。真正要抢救的只有 RTL 源文件（.v/.sv）和 .ys 脚本——它们入 git 的话 git restore top.v 即刻恢复；没入版本库就翻编辑器备份或操作系统文件历史。磁盘满引起的截断，先按 Yosys 磁盘写满报错速查 清出空间再重跑，顺序别反。

第四步，怀疑缓存与并行问题时做干净重跑。 并行 make 下两个目标写同一个中间文件，是"偶发损坏、重跑就好"的头号病根：检查 Makefile，确认每个中间产物的名字只属于一个目标，必要时按模块分目录（build/fifo/、build/top/）。如果重跑后报错依旧且内容对不上预期，按 Yosys 缓存陈旧报错速查 的思路删掉全部中间产物做一次干净构建，排除读到旧文件的可能。

第五步，验证修复结果。 源文件恢复后先单独跑 yosys -p "read_verilog top.v" 确认解析通过，再跑完整综合脚本。中间产物重生成后用 ls -l 看大小是否合理、用 read_json 单独读一遍确认能载入——能读入、能综合，才算真修复。

五、防复发：四条纪律

• RTL 源文件与 .ys 脚本入版本库，中间产物全部 .gitignore。 这是最核心的一条：源文件是资产，.json/.il/build/ 目录是随时可再生的衍生物，入版本库只会制造合并冲突与污染，没有任何恢复价值。
• 合并冲突当天解决，绝不让标记过夜。 Verilog 文件冲突后先 grep -n '^<<<<<<<' 全仓搜一遍再提交——残留标记进了 .v 文件，报出来的语法错误极具迷惑性，能浪费半天排查时间。
• 工程放本地盘，网盘/同步盘只放归档。 Dropbox、各类网盘目录的半截同步与双机竞争写入是文件损坏的温床；需要跨机共享时打 tar 包传输，接收方核对大小与 sha256sum。下载第三方 IP 库同样先校验和再入库。
• Ctrl-C 或断电后第一件事是删中间产物重跑，不是继续。 综合中途被打断，build/ 里的产物大概率是半截的；带着半截产物继续跑，下一步的报错只会更看不懂。Makefile 里给综合目标加上失败时删产物的逻辑（make 的 .DELETE_ON_ERROR），让半截产物根本活不到下一次读取。Quartus 侧的同类问题（.qpf/.qsf 工程文件损坏）处置思路类似，见 Quartus 工程文件损坏速查。

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

本篇是 FPGA 工具排错速查簇中"文件完整性"节点的 Yosys 侧 FAQ 页：源文件本身写法错误导致的解析失败见 Yosys 语法解析报错速查；磁盘写满引起的截断与空间处置见 Yosys 磁盘写满报错速查；重跑后内容对不上预期的缓存问题见 Yosys 缓存陈旧报错速查；Quartus 工程文件侧的同类问题见 Quartus 工程文件损坏速查。几篇合起来覆盖"读不进去"的主要入口：文件坏了看本篇、写得不对看解析篇、空间满了看磁盘篇、新旧不分看缓存篇。

一句话总结

Yosys 文件损坏或截断，先分清坏的是源文件还是中间产物：.json/.il 等中间产物坏了直接删掉重跑综合步骤即可，从来不用修；RTL 源文件坏了用 tail 查尾部完整性、grep '^<<<<<<<' 搜冲突标记，再从 git 恢复或手工修复。六个真实病因（Ctrl-C/断电写半截、磁盘满截断、并行 make 互踩、同步盘竞争、合并冲突标记残留、下载不完整）对应四条防复发纪律：源文件入 git 产物入 gitignore、冲突标记当天清、工程放本地盘压缩包传输、中断后删产物干净重跑。