使用fgetc读取文件时末尾被追加8'hFF的问题排查请求

嘿，看你的代码片段和问题描述，这大概率是**$feof与$fgetc的配合逻辑踩坑**，再加上可能的偏移量或文件操作问题，咱们一步步捋：

1. 先揪出循环逻辑的核心问题 #

Verilog里的$feof和$fgetc触发时机很容易搞反：

• $fgetc到达文件末尾时，会返回EOF（通常对应十进制-1，转成8位就是8'hFF）；
• 但$feof是在你尝试读取过EOF之后才会置位，不是提前预判文件末尾。

你的循环是先判断!$feof(fd)再读，流程是这样的：

读到第6个有效字节 → $feof还是假 → 循环继续执行 → 调用$fgetc读取到EOF（返回8'hFF） → 此时$feof才置位 → 循环退出。

这就直接多出来那个讨厌的8'hFF！
修复的正确逻辑应该是先读再判断：

file_char = $fgetc(fd);
while (file_char != `EOF) begin
    captured_data = file_char[7:0];
    // 这里写你的数据处理/写入逻辑
    $fwrite(fd1, "%c", captured_data); // 示例写入操作
    file_char = $fgetc(fd); // 提前读取下一个字节
end

2. 验证$fseek的偏移和返回值处理 #

你代码里的assert(status)逻辑完全反了！

• $fseek成功时返回0，失败返回非0；
• Verilog的assert(expr)是当expr为假时触发错误，所以你现在的代码是**$fseek成功反而触发assert报错**，可能导致后续代码没按预期执行（比如从文件开头读而不是1872偏移），这也会导致读取到多余字节。

正确的偏移检查应该是：

status = $fseek(fd, 1872, 0);
if (status != 0) begin
    $error("Failed to seek to offset 1872!");
    $finish;
end

另外，用工具直接查文件原始内容：比如Linux下用od -t x1 input_file | sed -n 1873p（因为偏移从0开始，1872是第1873个字节），确认从这个位置开始到底有多少有效字节，是不是真的只有6个。

3. 检查文件打开模式的干扰 #

你用了"rb"（二进制模式）是对的，但如果是在Windows环境下，不小心用了"r"（文本模式），会自动把\r\n转换成\n，导致文件实际偏移和你计算的不一致，可能读到多余的内容。确保打开文件时始终用"rb"避免格式转换干扰。

4. 打印每个读取的字节确认来源 #

在循环里加一句打印，直接看每个字节的来源和偏移：

$display("Read byte at offset %0d: %h", $ftell(fd)-1, captured_data);

如果第7个字节是8'hFF，且$ftell显示的偏移已经超出文件实际大小，那就是循环逻辑的问题；如果文件里真的在偏移1872+6的位置有8'hFF，那就是输入文件本身的问题。

内容的提问来源于stack exchange，提问作者coding_gal