#901 iverilog miscompile

v0.9
closed-invalid
nobody
5
2012-08-10
2012-08-08
Steel1.0
No

Attached test shows a miscompile in the test. To confirm the error I checked the output on other simulators. ModelSim and GPL Cver confirm that iverilog has a miscompile. I tried other versions of iverilog and in all cases (include git trunk) I saw the same error.

test.v is a test for miscompile.
To compile it I simply used command 'iverilog test.v'. I believe that the execution of assignment ''mem_p_addr0 <= in_data; //bug" is not correct. Picture wave.jpg shows that error.
File data.txt contains input data. File expected-result.txt contains correct output for the test.
File test-description.c describes the behavior of the state-machine in test_module. It will be helpful if you would like to understand the control flow of the state-machine in order to fix bug.

Discussion

  • Steel1.0
    Steel1.0
    2012-08-08

    Archive with test and additional files

     
    Attachments
  • This is a timing race in your testbench. In your fifo_out module you have:

    always @(posedge clk)
    begin
    if (read) begin
    res = $fscanf(stream, "%x\n", dataout);
    ...

    where dataout is directly connected to in_data. So if the always block that reads the data from the file executes before the always block that samples in_data, the sampled value will be the newly read value, otherwise it will be the previously read value.

    The reason you see mem_p_addr0 pick up every second value of in_data is that the Icarus scheduler uses a last-in first-out queue for threads waiting on an event. Most other simulators execute the threads in a fixed order (normally the order they appear in the source file).

    You can fix your testbench like this:

    reg [31:0] temp;

    always @(posedge clk)
    begin
    if (read) begin
    res = $fscanf(stream, "%x\n", temp);
    data_out <= temp;
    ...

    I'm marking this report as invalid, but will leave it open for a little while in case you have any further questions.

     
    • status: open --> open-invalid
     
  • Steel1.0
    Steel1.0
    2012-08-10

    Thank you! I think I mistaken because I poorly understand the behavior of scanf function. I hope that my report didn't take you a lot of time!

     
  • That's OK. This was very similar to another recent bug report, so I recognised the symptoms and it didn't take long to find the cause. I'll close this report now.

     
    • status: open-invalid --> closed-invalid