使用 Systemverilog 读取然后打印二进制文件。第一个字节读取和打印正常，遇到问题\w 字节在 ms 位位置包含 1

Question

下面的 Systemverilog 代码是一个单文件测试平台，它使用 $fread 将二进制文件读入内存，然后打印内存内容。二进制文件是 16 字节，它的视图包含在下面（这是我希望 Systemverilog 代码打印的内容）。

打印的输出与我对前 6 (0-5) 个字节的预期相符。那时预期的输出是 0x80，但是打印的输出是一个 3 字节的序列，以 0xef 开头，它们不在激励文件中。在这 3 个字节之后，输出再次与刺激匹配。似乎当二进制字节读取的第 7 位为 1 时，就会发生错误。几乎好像数据被视为已签名，但事实并非如此，其二进制数据打印为十六进制。内存被定义为无符号类型逻辑。

这类似于本文中的问题/答案： Read binary file data in Verilog into 2D Array。 但是我的代码在 $fopen 语句中没有相同的问题（我使用“rb”），所以 解决方案不适用于此问题。

Systemverilog 规范 1800-2012 在第 21.3.4.4 节读取二进制数据中指出 $fread 可用于读取二进制文件，并继续说明如何。我相信这个例子符合该部分的规定。

代码发布在 EDA Playground 上，以便用户查看和运行。 https://www.edaplayground.com/x/5wzA 您需要登录才能运行和下载。登录是免费的。它提供 访问基于云的完整版本的行业标准工具，用于 HDL 仿真。

还尝试在 EDA Playground 上运行 3 个不同的模拟器。它们都产生相同的结果。

已尝试重新排列 stim.bin 文件，使 0x80 值出现在文件的开头而不是中间。在这种情况下，错误也会发生在测试台打印输出的开头。

也许 Systemverilog 代码没问题，问题出在二进制文件上？我提供了 emacs hexl 模式为其内容显示的屏幕截图。还查看了另一个查看器，它看起来一样。您可以在 EDA Playground 上运行时下载它以在另一个编辑器中检查它。二进制文件由 GNU Octave 生成​​。

希望有一个使用 Systemverilog $fread 而不是其他东西的解决方案来调试原始文件而不是解决它（学习）。这将被开发成一个 Systemverilog 测试平台，它将从 Octave/Matlab 中生成的二进制文件读取的激励应用到 Systemverilog DUT。由于文件访问速度，首选二进制文件IO。

为什么 Systemverilog 测试平台为 mem[6] 打印 0xef 而不是 0x80？

module tb();

  // file descriptors
  int       read_file_descriptor;
  // memory
  logic [7:0] mem [15:0];


  // ---------------------------------------------------------------------------
  // Open the file
  // ---------------------------------------------------------------------------
  task open_file();
    $display("Opening file");
    read_file_descriptor=$fopen("stim.bin","rb");
  endtask

  // ---------------------------------------------------------------------------
  // Read the contents of file descriptor
  // ---------------------------------------------------------------------------
  task readBinFile2Mem ();
    int n_Temp;
    n_Temp = $fread(mem, read_file_descriptor);
    $display("n_Temp = %0d",n_Temp);
  endtask
  
  // ---------------------------------------------------------------------------
  // Close the file
  // ---------------------------------------------------------------------------
  task close_file();
    $display("Closing the file");
    $fclose(read_file_descriptor);
  endtask

  // ---------------------------------------------------------------------------
  // Shut down testbench
  // ---------------------------------------------------------------------------
  task shut_down();
    $stop;
  endtask
  
  // ---------------------------------------------------------------------------
  // Print memory contents
  // ---------------------------------------------------------------------------  
  task printMem();
    foreach(mem[i])
      $display("mem[%0d] = %h",i,mem[i]);
  endtask
    
  // ---------------------------------------------------------------------------
  // Main execution loop
  // ---------------------------------------------------------------------------
  initial
    begin :initial_block
      open_file;
      readBinFile2Mem;
      close_file;
      printMem;
      shut_down;
    end :initial_block

endmodule

二进制刺激文件：

实际输出：

Opening file
n_Temp = 16
Closing the file
mem[15] = 01
mem[14] = 00
mem[13] = 50
mem[12] = 60
mem[11] = 71
mem[10] = 72
mem[9] = 73
mem[8] = bd
mem[7] = bf
mem[6] = ef
mem[5] = 73
mem[4] = 72
mem[3] = 71
mem[2] = 60
mem[1] = 50
mem[0] = 00

更新： 为了测试二进制文件在上传到 EDA Playground 的过程中可能会被修改，运行了一个实验。这些步骤不涉及 Systemverilog 代码，只是文件上传/下载。

步骤： （使用https://hexed.it/创建并查看二进制文件）

1. 使用十六进制模式 80 00 80 00 80 00 80 00 创建/保存二进制文件
2. 创建新游乐场
3. 将新创建的二进制文件上传到新 Playground
4. 选中操场上的“运行后下载文件”框
5. 拯救游乐场
6. 跑操场
7. 保存/解压缩 Playground 运行的结果
8. 查看二进制文件，在我的例子中，它在处理过程中被修改过 上传下载。结果的屏幕截图如下所示：

本实验在两个不同的 Windows 工作站上进行。 基于这些结果和 cmets，我将关闭这个问题，并认为这不是 Systemverilog 问题，而是与将二进制文件上传/下载到 EDA 游乐场有关。感谢评论的人。

Answer 1

测试台产生的意外输出是由于二进制激励文件在上传到 EDA 操场期间/之后发生的修改。 Systemverilog 测试台按预期执行以打印二进制文件的内容。

此结论基于更新问题末尾提供的社区 cmets 和实验结果。给出了详细的程序，以便其他人可以重复实验。