# How does Verilog deal with this snippet (procedural block order dependence)?

At the outset, I would like to say that I am not able to run this snippet at the moment but, even if I were, I hope this question would still stand as I'd like to understand why the Verilog standard implies a given interpretation of this snippet.

The snippet below is adapated from one seen in Chapter 8 of Saurabh's Introduction to VLSI Design Flow. It is written in 2001-Verilog but, I think, it works in modern simulators too.

module top();
reg a,b, clock;
initial begin
a = 1'b1;
b = 1'b0;
clock = 1'b0;
end

always clock = #10 ~clock; // clock with period 20 time units

always @(posedge clock) begin
a<= b; //a changes to 1'b0 at t=10 and 1'b1 at t=30 and so on...
b<= a; //b changes to 1'b1 at t=10 and 1'b0 at t=30 and so on...
end
endmodule



What I am confused about is the following: is this code guaranteed to work as intended given the comments below?

(1) In Verilog there is no guarantee that an initial block executes before an always block. This is up to the simulator.

(2) For intra-assignment delay (as in the clock updating always) the RHS is evaluated before the delay.

Given (1) and (2), it's not clear to me that this code is guaranteed to work. For example: if the always block is entered first, before the initial block, then, since clock has as yet not been intitialized I believe we will get clock toggled to x after 10 seconds, meaning that we do not get a positive edge of the clock at 10 seconds. On the other hand, if the initial is entered first then things work out as intended. Is this understanding correct?

Your understanding is correct. Not only are the execution order between all initial and always blocks in a design indeterminate, but the relative ordering of statements between processes is indeterminate as well. That means the first two statements inside the initial could execute and switch to the always block before the clock='b0; statement. This is exactly what might happen if the design was executing on a truly multithreaded system. Section 4.7 Nondeterminism enables this for many other kinds of optimizations.

I would NEVER use a use an assignment with an intra-assignment delay. This is left over from before non-blocking assignments were introduced into Verilog in the 1980s.

This should be written as

always #10 clock = ~clock;


or better

initial begin
clock = 1'b0
forever #10 clock = ~clock;
end

• What if we initialize the variable at the declaration time? i.e. reg clk = 0;. I assume that this will avoid any such condition in the first place. Isn't it so? Commented Mar 19 at 16:53
• Thank you so much for this very helpful answer! I now think I understand your comment that "Not only are the execution order between all initial and always blocks in a design indeterminate, , but the relative ordering of statements between processes is indeterminate as well" after reading Chapter 9 of the text (which discusses the details of simulation) but I was hoping to confirm with you if that's OK: I think my original suspicion that what matters is which procedural block was "entered first" was wrong, and what matters instead are the individual time slots in the event queue...
– EE18
Commented Mar 19 at 17:36
• ... That is, the simulator goes through all processes concurrently and sets up the event queue. Within a given time slot -- like t=0 as is under discussion here -- and in the active region the simulator may order events in any order desired, modulo that events from a given procedural block must execute in-order.
– EE18
Commented Mar 19 at 17:38
• @ImGroot Verilog-2001 added the syntax reg clk = 0; however it described its behavior as the same as reg clk; initial clk = ; SystemVerilog strengthened that behavior to say that initialization happens before any other initial or always blocks start their processes. Commented Mar 19 at 17:49

Can you share with us why you are unable to run the code snippet at the moment ?

Verilog uses event-driven simulation, so the order of execution of 'always' blocks, 'initial' blocks or 'assign' statements depends on the flow of those types of events.

Generally, signals updated in one particular block will trigger execution of all other blocks which depend on those signals.

The main difference between always blocks and initial blocks is that the latter are executed unconditionally at time 0 and usually produce some initial events, such as the generation of clocks and/or the scheduling of reset signals.

For this reason initial blocks are generally considered to be executed first and before any other blocks react to these events which are produced by them.

• My only tool for running Verilog is the online EDAPlayground and I was having issues opening the waveform viewer to actually see the results of the snippet. At any rate, thanks very much for your answer here. I am not sure though that the resolution is that initial blocks execute first; indeed, my book explicitly says they do not necessarily?
– EE18
Commented Mar 19 at 14:38
• It all depends how you define "first" and what the book means by "not necessarily" - only sometimes, occasionally or rarely ? You may want to double check the context of that statement in your book (and if you can, also make a link to it here for us...). The initial blocks will definitely execute at time t=0, and from this you can logically follow the signal flow ... Commented Mar 19 at 15:28
• As an asside, it is generally known this is the case for simulation, however for sythnesis (as you may or may not already know), the initial state of variables that you want to initialise when the machine starts up, is best served with an always @(posedge clock, negedge reset) begin if (~reset) { initialise variables} else {continue with always block logic as if already started} ... hope this might clarify the slight differences ... Commented Mar 19 at 15:33
• To clarify what I mean: certainly the initial block will execute at t=0 but what the book means I think is that if there is an always block which is also possible to execute at t =0 then it is possible that the always block is entered first. Indeed, that is the case here (again, I think): always clock = #10 ~clock; gets entered at $t = 0$ and the intra-assignment delay (please correct if wrong) schedules a clock inversion for t = 10, but does this with the value of the clock it has at the current instant?
– EE18
Commented Mar 19 at 15:41
• Incidentally, totally agreed regarding the synthesizable subset of Verilog and appreciate you mentioning it, but here I am interested in the full Verilog superset.
– EE18
Commented Mar 19 at 15:42