Another BTF error - Section 5.5 "Race conditions"

From: Daryl Stewart (Daryl.Stewart@cl.cam.ac.uk)
Date: Mon Sep 29 1997 - 07:23:42 PDT


module EXP_143;
   reg q;
   // comment out only one of the following two lines:
   wire p; assign p=q;
   // wire p=q;
   
   
   initial begin
      #1 $display("1st simulation cycle: q",q," p",p);
      #0 $display("2nd simulation cycle: q",q," p",p);
   end // initial #1
   
   
   initial begin // this code based on that on p5-4, Oct P1364
      q=1;
      #1 q=0;
      $display("1st: q",q," p",p);
      #0 $display("2nd: q",q," p",p);
   end // initial begin
   
   initial begin
      #1 $display("1st simulation cycle: q",q," p",p);
      #0 $display("2nd simulation cycle: q",q," p",p);
   end // initial begin
   
   
endmodule // EXP_143

/*
 
 With wire p=q; only commented out
 $verilog -q experiment.143.cv
 1st simulation cycle: q1 p1
 1st: q0 p1
 1st simulation cycle: q0 p1
 2nd simulation cycle: q0 p1 (p is still 1)
 2nd: q0 p0
 2nd simulation cycle: q0 p0
 
 The example code in section 5.5 "Race conditions" is at fault.
 It states that the display immediately following the q=0
 assignment could show p as either 1 or 0.
 This code shows that in fact, p does not become 0 until
 partway through the 2nd simulation cycle in the same timestep,
 hence it is impossible for the first display to see p=0.
 This is because of the implicit #0 net delay.

 With wire p; assign p=q; only commented out
 $verilog -q experiment.143.cv
 1st simulation cycle: q1 p1
 1st: q0 p0
 1st simulation cycle: q0 p0 (p is already 0)
 2nd simulation cycle: q0 p0
 2nd: q0 p0
 2nd simulation cycle: q0 p0
 
 Here, without the implicit #0 net delay, p becomes 0
 within the 1st simulation cycle.
 
 */



This archive was generated by hypermail 2.1.4 : Mon Jul 08 2002 - 12:54:42 PDT and
sponsored by Boyd Technology, Inc.