title: Verilog: compare wire values in testbench
body: <p>In testbench I was trying to do a very simple comparison, namely <code>data_a !== 32'h14</code>, which surprisingly resulted in <code>true</code>, yet in the simulation I saw clearly that <code>data_a</code> is exactly <code>32'h14</code>.</p>
  
  <p>If I compare it using <code>!=</code> then it's <code>false</code> as expected.</p>
  
  <p>The reason why I don't want to use <code>!=</code> is because it may result in <code>X</code> which will act as <code>false</code> in my test case. I have already had falsely passing tests as a result of this.</p>
  
  <p>My only guess why <code>data_a !== 32'h14</code> may be true is that <code>data_a</code> consists of <code>St0 St0 St0 ...</code> and <code>32'h14</code> of <code>0 0 0 ...</code> as you can see from the picture:
  <a href="https://i.stack.imgur.com/pu7Nd.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/pu7Nd.png" alt="Simulation data in Modelsim"></a></p>
  
  <p>My understanding was that <code>0</code> is an alias of <code>St0</code>, so not sure whether that may be the reason.</p>
  
  <p>Full code of the testbench is below:</p>
  
  <pre><code>module test_registers(clk);
      input clk;
  
      reg error = 0;
      reg write = 0;
      reg [4:0] addr_a = 0, addr_b = 0, addr_in = 0;
      reg [31:0] data_in = 0;
      wire [31:0] data_a, data_b;
  
      register_file MUT(data_a, data_b, addr_a, addr_b, addr_in, data_in, write, clk);
  
      initial begin
         $readmemh("tests/registers/reg.dat", MUT.registers);
  
         addr_a = 1;
         addr_b = 2;
         if (data_a !== 32'h14 || data_b !== 32'h40) begin
             $display("Fetch 1 failed");
             error = 1;
         end
  
      end
  endmodule
  </code></pre>
  
  <p>UPD. The answer was a race condition (read more about those in the <a href="http://vol.verilog.com/VOL/main.htm" rel="nofollow noreferrer">verilog tutorial</a>, Chapter 3)
  There was literally no time spent between setting <code>addr_a</code> and reading the result (<code>data_a</code>) - the module <code>register_file</code> updated it at the same point in time (<code>0</code>), but <em>later</em> than the read.
  A solution might be to add a delay (e.g. <code>#1</code>) between set and read, so that all the actions scheduled for the time slot <code>0</code> are guaranteed to have executed.</p>