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

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

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

这类似于本文中的一个问题/答案： . 但是，我的代码在$fopen语句中没有相同的问题（我使用“rb”），因此 解决方案不适用于此问题

Systemverilog spec 1800-2012在第21.3.4.4节读取二进制数据中指出，$fread可用于读取二进制文件，并继续说明如何读取二进制文件。我相信这个例子符合那一节所述

代码发布在EDA游乐场上，以便用户可以看到并运行它。 您需要登录才能运行并下载。登录是免费的。它提供 访问HDL模拟行业标准工具的完整基于云的版本

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

尝试重新安排STIM.BIN文件，以便0x80值出现在文件的开始而不是在中间。在这种情况下，错误也发生在测试台打印输出的开始

也许Systemverilog代码很好，问题是二进制文件？我提供了一个屏幕截图，显示了emacs hexl mode为其内容显示的内容。另外一个观众也看到了它，它看起来是一样的。您可以在EDA操场上运行时下载它，以便在另一个编辑器中检查它。二进制文件由GNUOctave生成

希望有一个使用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游乐场的过程中二进制文件可能会被修改，进行了一个实验。这些步骤中没有Systemverilog代码，只是一个文件上传/下载

步骤： （用于创建和查看二进制文件）

创建/保存十六进制模式为80 00 80 00 80 00 80 00的二进制文件

创建新的游乐场

将新创建的二进制文件上载到新游乐场

检查操场上的“跑步后下载文件”框

拯救游乐场

跑场

保存/解压缩操场跑步的结果

查看二进制文件，在我的例子中，它在 上传/下载。结果的屏幕截图如下所示：

这个实验是在两个不同的Windows工作站上进行的。

---

基于这些结果和评论，我将结束这个问题，我认为这不是Systemverilog问题，而是与将二进制文件上传/下载到EDA有关。感谢那些发表评论的人。

测试台产生的意外输出是由于在上传到EDA过程中/之后对二进制刺激文件进行了修改。Systemverilog测试台的功能与打印二进制文件内容的功能相同

---

这一结论基于社区意见和实验结果，这些意见和实验结果在更新后的问题末尾提供。给出了一个详细的过程，以便其他人可以重复该实验。

我猜您的二进制文件有问题，可能与eda有关。我用我自己的二进制文件进行了尝试，结果正如预期的那样。我同意@Serge，我认为你的代码很好，你的二进制文件可能不包含你认为的内容。你的二进制文件不包含你认为的内容-你可以通过选择EDA操场上的“运行后下载文件”选项看到这一点。为什么呢？不知道，我得调查一下。我将把它作为一个bug添加到待办事项列表中。在两个平台上工作-家庭和工作。文件已创建并从家推送到EDA游乐场。从工作中下载，我看到二进制文件并不像预期的那样（与从家里看到的emacs屏幕截图不一样）。今天晚些时候，我们将尝试在home端重复相同的实验。基本上，任何大于等于128的字符都将转换为Unicode版本。