In SystemVerilog, we would prefer that you use always_comb begin...end instead of always @*.
The big drawback with always@* is that when some of your combinatorial logic involves constants, the always @* may not trigger at time 0, it needs to see a signal change to trigger. always_comb guarantees to trigger at time 0 at least once.
Another benefit of always_comb is that it in-lines function calls. If you call a function, and the body of the function references a signal not passed as an argument, always @* will not be sensitive to that signal.
It's just a shortcut for listing all of the wires that the always block depends on. Those wires are the "sensitivity list". One advantage of using it is that synthesized code is unlikely to care what you put in the sensitivity list (other than posedge and negedge) because the wires will be "physically" connected together. A simulator might rely on the list to choose which events should cause the block to execute. If you change the block and forget to update the list your simulation might diverge from the actual synthesized behavior.
@Ben Jackson answered correctly. The answer to the second part is there are no possible side effects; I consider this a recommended practice for combinatorial logic.
In SystemVerilog, we would prefer that you use always_comb begin...end instead of always @*.
The big drawback with always@* is that when some of your combinatorial logic involves constants, the always @* may not trigger at time 0, it needs to see a signal change to trigger. always_comb guarantees to trigger at time 0 at least once.
Another benefit of always_comb is that it in-lines function calls. If you call a function, and the body of the function references a signal not passed as an argument, always @* will not be sensitive to that signal.
It's just a shortcut for listing all of the wires that the
always
block depends on. Those wires are the "sensitivity list". One advantage of using it is that synthesized code is unlikely to care what you put in the sensitivity list (other thanposedge
andnegedge
) because the wires will be "physically" connected together. A simulator might rely on the list to choose which events should cause the block to execute. If you change the block and forget to update the list your simulation might diverge from the actual synthesized behavior.@Ben Jackson answered correctly. The answer to the second part is there are no possible side effects; I consider this a recommended practice for combinatorial logic.