Re: [sv-bc] @* vs. always_comb

>From: "Clifford E. Cummings" <cliffc@sunburst-design.com>
>
>First - I don't remember there being any discussion about deprecating @* 
>(after all, this isn't defparam!! :-)

When I became aware of always_comb, I believe that I suggested that we
eliminate @* before it started being used too widely.  Both constructs
were created independently to solve the same problem, and I don't see a
need to have both of them.  However, since nothing was done at that time,
by now @* has become more widely used and would be difficult to eliminate.


>Others have already mentioned that multiple always_comb assignments that 
>are driven onto a common net at an upper level of hierarchy is resolved and 
>legal (it is now a net at the higher level).

Well, it will be a net in Verilog.  It might be a variable in SystemVerilog,
depending on how it is declared.  In fact, if it is an output port of the
higher-level module and has a datatype and is not explicitly declared to be
a net, it will be a variable.  I think that this is bad, but that is how it
is defined to work.

If it is a variable in the higher-level module, you still won't directly
get an error because of a variable being assigned by multiple always_comb
constructs.  It will be a different variable in the different modules.
What you will get instead is an error in the higher-level module where the
two instances are driving the same variable, due to the rule that a variable
can only be driven by one continuous assignment.  The result is still the
same, that you can't have multiple drivers on a variable.  In this case,
you will have to go back and change the variable to be a net in that
module.

> If the ports were ref-ports, I 
>believe this now fails using always_comb.

I assume so.


>One semi-important difference with always @* is that at this time it 
>appears to be a nice construct in a testbench when a verification engineer 
>does not care about what would be synthesized from the testbench code.
>
>Since always @* can be used to model RTL combinational logic and latches, 
>the verification engineer might not want to think about whether their 
>procedural code has combinational or latch-based behavior - "just do what I 
>have coded!"
>
>In theory, a tool "may warn" the user if always_comb would not build 
>combinational logic and always_latch may not build latch based logic, but 
>the verification engineer often does not care.

If this is really an important consideration, it calls for a new kind of
always_comb_or_latch_whichever_comes_out construct, rather than using @*.
Or just ignoring the messages saying that your always_comb turned out to
contain latches or your always_latch turned out not to.

Steven Sharp
sharp@cadence.com