🚀 go-pugleaf

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

To summarize:

(Please let me know if I've screwed this up)

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:

I described:

    always @(posedge Clk)
      begin 
        c = b;
        b = a;
      end

Note that here order of execution is specified.
This however 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 use #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 execute last, ie:

    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 the 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
standpoint of not requiring delays.

Thanks again,

dave
manley@optilink.com