verilog测试台比较原因错误

Question

I have the most peculiar problem that none of the guys in my office came across or know how to handle, maybe you guys will find where's the catch.

In my verilog testbench, I have the following compare code:

if (refFifo[7:0] != DUT.fifo[7:0] && rnd == 1) begin
  $display("Error! ref Fifo %h not equal DUT fifo %h after 1 byte", refFifo[7:0], DUT.fifo[7:0]);
  $stop;
end
else if (refFifo[15:0] != DUT.fifo[15:0] && rnd == 2) begin
  $display("Error! ref Fifo %h not equal DUT fifo %h after 2 byte", refFifo[15:0], DUT.fifo[15:0]);
  $stop;
end

... (until 5 bytes)
else
$display("Success!");
Now, the problem is that the comparison of 2 is always failing, while the rest of the comparisons pass smoothly (and this screws up with my runs):
'>Error: ref Fifo 090c not equal DUT fifo 090c after 2 byte'
I tried changing the position of the compare in the process, printing the values before the compare (in case they changed somehow during the compare), adding parenthesis, changing the compare range to [7:0] and building a new environment but nothing helped or gave some indication of what goes wrong with the compare of 2 bytes.
Did anyone ever came across such a problem? does anyone have an idea of how to solve it?
I run with ModelSim 10.1d_1 with no optimization, in case it has something to do with my enigma.
update also tried it on ModelSim 10.0d_1, but with no help.

Answer 1

I can't see anything wrong with your code. The result of the && must be 1'b1 for the $display to be executed. This means both comparisons must also have a result of 1'b1 , so there aren't any unknowns in resFifo , DUT.fifo , or rnd . You should change your comparison operators to !== and === to confirm this. ModelSim is also not printing any X's with the %h modifier. I'd change this to %b just to be sure.

Unless I've missed something obvious, I'd remove the cross-module reference ( DUT.fifo ) and try again. Get a fifo port out of the DUT, and do the comparison against the port value. This might help to track down the issue.

Answer 2

Your code looks fine to me. You may be hitting a simulator bug; if you can reproduce this in a test case you should submit it to Mentor support.

Here are are some other things to try:

• Create a 5-byte local variable for the DUT value before the if statements, and use that in the checks.
• Change the order of the checks so that you look at rnd first. This way the expression will short-circuit and avoid comparing the DUT values for cases which you don't need to check for.
• Refactor the check to use a case statement on rnd . Including a default case may help debug any problem where rnd != 2 .
• Delete the line and re-type it manually. Or copy/paste another line and change the numbers. I have seen weird cases where a hidden/bad/unicode character will compile and run but cause something to misbehave.