BTW: as an onetime verilog implementer those temporary storage locations that are made behind your back by the compiler when you use <= are potentially quite ex

BTW: as an onetime verilog implementer those temporary storage locations that are made behind your back by the compiler when you use <= are potentially quite expensive, the compiler can optimise the normal case of: always @(posedge clk) r <= v; and in some more complex cases where r is only set once in one always statement (or once in any path through an always statement) - but something like: always @(*) r <= c; is a nightmare that essentially means that r can have many changes scheduled in the same instant of time, more importantly it's a number of changes that can't be determined at compile time (could be 1000s of transitions) - resulting in code that's mallocing space to store all those changes - simulation can slow down if you use <= in a non-clocked place because the behaviour can't be determined statically Also using <= a smart compiler can merge multiple always statements: always @(posedge clk) r1 <= c1; always @(posedge clk) r2 <= c2; ...... into a single always @(posedge clk) { r1 <= c1; r2 <= c2; ...... } behind your back, effectively converting 2*N simulation events into 2 (a very good thing)