Technical Tidbits

Introduction

The original problem was a piece of code which looked like this: always @(posedge Clk) c = b; always @(posedge Clk) b = a;

The problem was that it was unpredictable which value c would get - the old value of b or the new value of b (a).

Here is what Dave wrote.

Thanks for all the responses. I got a lot of great answers.

To summarize:

The following Verilog code: always @(posedge Clk) c = b; always @(posedge Clk) b = a;

should not be written since the order of execution of the assignments is not specified as part of the Verilog language - as a side issue it is important to note that different vendors simulators may behave differently as a result.

Solution 1:

always @(posedge Clk)

     begin

       c = b;

       b = a;

end

Note that here order of execution is specified. This how ever forces these assignments into the same always block.

Solution 2:

Use intra assignment delays:

always @(posedge Clk) c = #1 b;

always @(posedge Clk) b = #1 a;

 

This effectively creates temp variables:

at posedge clock:

tempb = b

tempa = a

1 time unit later:

c = tempb

b = tempa

Now it doesn't matter which order the always statements execute. (You can also u se #0 if you don't want the delay)

It was also pointed out that in this simple case only a single delay is necessary on the assignment you want to exe cute last, i.e.:

always @(posedge Clk) c = b;

always @(posedge Clk) b = #0 a;

Solution 3:

Use non-blocking assignments:

always @(posedge Clk) c <= b;

always @(posedge Clk) b <= a;

 

This works because Verilog evaluates (and stores) the right hand side of each assignment before performing the assignment. Others have suggested using a delay here:

always @(posedge Clk) c <= #1 b;

always @(posedge Clk) b <= #1 a;

 This works, but is unnecessary, and may add the undesired delay. (You could use #0, to avoid the delay, but since you don't need it why put it in at all?)

Comment: My end goal is to write code to be synthesized using Synopsys. To my mind it seems 'dirty' to have to include delay statements in the Verilog to get t he behavioral code to run properly. Synopsys has no problem generating the right logic for the original hunk of code but as we all know it doesn't simulate. From the responses I've received it looks like Solution 3 is the best from the stand point of not requiring delays.

Conclusion

We can note that this problem is a variation of the general race condition problem which was discussed in the September 1992 Technical Tidbits. We can also note that all of the above solutions with the exception of the first involve creating more events than the original formulation. The first solution is the most efficient, but the least general.