Using Systemverilog to read then print binary file. First bytes read & print ok, trouble\w byte containing a 1 in the ms bit position encountered

Question

The Systemverilog code below is a single file testbench which reads a binary file into a memory using $fread then prints the memory contents. The binary file is 16 bytes and a view of it is included below (this is what I expect the Systemverilog code to print).

The output printed matches what I expect for the first 6 (0-5) bytes. At that point the expected output is 0x80, however the printed output is a sequence of 3 bytes starting with 0xef which are not in the stimulus file. After those 3 bytes the output matches the stimulus again. It seems as if when bit 7 of the binary byte read is 1, then the error occurs. It almost as if the data is being treated as signed, but it is not, its binary data printed as hex. The memory is defined as type logic which is unsigned.

This is similar to a question/answer in this post: Read binary file data in Verilog into 2D Array. However my code does not have the same issue (I use "rb") in the $fopen statement, so that solution does not apply to this issue.

The Systemverilog spec 1800-2012 states in section 21.3.4.4 Reading binary data that $fread can be used to read a binary file and goes on to say how. I believe this example is compliant to what is stated in that section.

The code is posted on EDA Playground so that users can see it and run it. https://www.edaplayground.com/x/5wzA You need a login to run it and download. The login is free. It provides access to full cloud-based versions of the industry standard tools for HDL simulation.

Also tried running 3 different simulators on EDA Playground. They all produce the same result.

Have tried re-arranging the stim.bin file so that the 0x80 value occurs at the beginning of the file rather than in the middle. In that case the error also occurs at the beginning of the testbench printing output.

Maybe the Systemverilog code is fine and the problem is the binary file? I have provided a screenshot of what emacs hexl mode shows for it's contents. Also viewed it another viewer and it looked the same. You can download it when running on EDA Playground to examine it in another editor. The binary file was generated by GNU Octave.

Would prefer to have a solution which uses Systemverilog $fread rather than something else in order to debug the original rather than work around it (learning). This will be developed into a Systemverilog testbench which applies stimulus read from a binary file generated in Octave/Matlab to a Systemverilog DUT. Binary fileIO is prefered because of the file access speed.

Why does the Systemverilog testbench print 0xef rather than 0x80 for mem[6]?

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

Binary Stimulus File:

Actual output:

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

Update: An experiment was run in order to test that the binary file may be getting modified during the process of uploading to EDA playground. There is no Systemverilog code involved in these steps, it's just a file upload/download.

Steps: (Used https://hexed.it/ to create and view the binary file)

1. Create/save binary file with the hex pattern 80 00 80 00 80 00 80 00
2. Create new playground
3. Upload new created binary file to the new playground
4. Check the 'download files after run' box on the playground
5. Save playground
6. Run playground
7. Save/unzip the results from the playground run
8. View the binary file, in my case it has been modified during the process of upload/download. A screenshot of the result is shown below:

This experiment was conducted on two different Windows workstations. Based on these results and the comments I am going to close this issue, with the disposition that this is not a Systemverilog issue, but is related to upload/dowload of binary files to EDA playground. Thanks to those who commented.

Answer 1

The unexpected output produced by the testbench is due to modifications that occur to the binary stimulus file during/after upload to EDA playground. The Systemverilog testbench performs as intended to print the contents of the binary file.

This conclusion is based on community comments and experimental results which are provided at the end of the updated question. A detailed procedure is given so that others can repeat the experiment.