Electronic – Verilog non-blocking file read

verilog

I would like to simulate a verilog design that is to interface (via a FiFo to USB chip) with a program running on my computer. I have set up my program to redirect all reads and writes to Linux FiFo files (man mkfifo) and am now trying to write a testbench for my verilog code that emulates the FiFo to USB chip. The idea is to read data from the Linux FiFo file and -if there is any- forward it to my DUT.

The Verilog standard names a number of system tasks to read data from a file

$fgetc (Get a byte)
$fgets (Get a string)
$fscanf (Get formatted data)
$fread (Get binary data)
$readmem* (Fill a whole memory at once)

However, these system tasks will block until there is data available or an error occurs. Even worse, they block the whole testbench even when fork'ed so something along the lines of

reg [8:0] code = 9'd0;
...
fork : fgetc_with_timeout
    begin
        code=$fgetc(input_file);
        disable fgetc_with_timeout;
    end
    begin
        #300;
        disable fgetc_with_timeout;
    end
join
if(code)
...

will not work. So, is there any way to get a nonblocking read from a file or is there a way to get the number of remaining bytes/bits/words in a file?

I am using Xilinx ISE so I am constrained to Verilog (not System Verilog), so I am looking for something that works in ISE, and I would prefer to not use PLI code for this if possible.

Best regards,
mox

p.S.> Searching for anything involving 'nonblocking' and 'verilog' lists mostly results not related to my problem, however I have found this non-answered question at the Xilinx forums: https://forums.xilinx.com/t5/Simulation-and-Verification/xsim-and-Verilog-file-IO-is-non-blocking-read-of-a-file-possible/td-p/685611

Best Answer

This cannot be done in Verilog alone. You are trying to mix a real-time system with a simulation-time system. You need to write a Verilog model that emulates the behavior of the FIFO output with random times for putting out data.

Related Solutions

Electronic – non-blocking assignment does not work as expected in Verilog

This is actually quite similar to a question I answered previously, but I will try to build up a canonical answer for this somewhat common issue.

In a zero-delay simulation like this, the test flip-flop has a setup time and a hold time of zero:

\$ T_{setup} = T_{hold} = 0 \$

What this means is that the instant the sensitive clock edge occurs, the output is updated, regardless of what happened immediately before or after that instant. This is not like real hardware which would usually have a non-zero \$ T_{setup} \$ and \$ T_{hold} \$.

I ran your testbench, and the results are pretty clear. The valid signal changes at the same time the clock signal does. You have delayed them by precisely the same amount. So at the very edge when the clock is high, the valid signal has also changed:

enter image description here

Both the input (div_valid), and the clock (gclk) go high at the same time: 220 ns. Therefore, the DFF latches this new data, and the output changes instantly since there is also 0 propagation delay. This simulation would look less confusing if we just chose a different delay value for the input to the design:

enter image description here

In this case, we update the input on the falling edge of the clock (620 ns). It is much more clear now that the next clock edge (640 ns) will be when the DFF updates its output.

Here is the testbench code so you can see exactly how it works in your own simulator. Please update the design name as it wasn't clear what yours was named.

module scratch_tb;

   reg gclk;
   reg resetn;
   reg div_valid;
   wire data;

   // instantiate design under test
   scratch scratch (gclk, resetn, div_valid, data);

   // generate stimulus
   initial begin
      gclk            = 1'b1;
      resetn          = 1'b0;
      div_valid       = 1'b0;

      #80 resetn      = 1'b1;

      // test 1: input switches on rising clock edge
      #160 div_valid   = 1'b1;
      #40 div_valid   = 1'b0;

      #160 div_valid  = 1'b0;

      // test 2: input switches on falling clock edge
      #180 div_valid  = 1'b1;
      #40 div_valid   = 1'b0;

      #2000 $finish;
   end

   always begin
      #20 gclk = ~ gclk;
   end

endmodule

Electronic – Mixed blocking & non-blocking assignment

Articles that say "nonblocking and blocking assignments do not have any effect on the synthesis, but only regards to the simulation" are incorrect. It is true there are certain cases where choosing either assignment operator has no affect on the synthesized hardware, but there are cases where it does make a difference.

One needs to realize that code you write executes in serial order within a begin/end block regardless of whether it represents a sequential or combinational circuit. Both simulation and synthesis tools need to implement the behavior you specify.

You can model both sequential and combinatorial circuits with just blocking assignments (in fact, non-blocking assignments were a later addition to the Verilog language). You can determine if the code represents a particular kind of circuit by looking at the order of assignments to the LHS variables with respect when the same variables are used in the RHS.

always @(posedge clk)begin
    ab  =  a & b & q0;  
    q0  =  ab; 
  end

Because ab appears in a blocking assignment statement before appearing on the RHS, it is considered combinational (write before read). And the value of ab gets updated immediately before executing the next statement. And since q0 appears on the RHS before appearing on the LHS, it is considered sequential (read before write).

But if we add another always block that uses ab on the RHS, that usage is considered sequential.

always @(posedge clk) begin
        c = ab;  
      end

Now ab represents sequential logic in that block because the other block executed on a clock edge, sampling the values of a and b. But now we have a simulation race condition because although the execution order within a begin/end block is serial, there is no defined ordering between different always blocks triggered by the same clock edge - you don't know if the second always block has the updated value of ab from the first always block.

The non-blocking assignment solves this race simulation race condition by delaying the LHS assignment until after everything else that was supposed to execute at the same time step. If we change the assignment to ab in the first always block to:

always @(posedge clk)begin
    ab  <=  a & b & q0; // NBA
    q0  =  ab; 
  end

Now the second always block is guaranteed to have the "old" value of ab. But this also does affect the statement that follows it in the same block. It now assigned the "old" value of ab to q0. So now it does take two clock cycles to get the value through to q0.

Best Answer

Related Solutions

Electronic – non-blocking assignment does not work as expected in Verilog

Electronic – Mixed blocking & non-blocking assignment

Related Topic