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

Hi, Shalom -

There have been some good responses to this question so far. Let me add my 
notes and observations:

First - I don't remember there being any discussion about deprecating @* 
(after all, this isn't defparam!! :-)

I do think there was discussion about deprecating @* inside of an always 
block (would deprecate the usage shown in the middle of Example 4 of 
section 9.7.5). I thought some vendors had mentioned that this usage was 
either problematic or inefficient and I still can't think of a good reason 
to use this coding style.

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). If the ports were ref-ports, I 
believe this now fails using always_comb.

Tri-state drivers are best implemented as continuous assignments as has 
been noted by multiple responders. Always-block implementations almost 
never work because of last-assignment-wins behavior in a block and they 
cannot be used to directly drive an inout port. You can use an always block 
to implement ONE tri-state driver in one module and instantiate the module 
multiple times, which would generally be easier to implement as multiple 
continuous assignments in a single module. In general, the use of tri-state 
drivers means you either want resolution or a bi-directional bus (years ago 
I worked with a contractor who suggested turning off clock signals with a 
tri-state driver  ...  he did not last long at our company!!   :-)

Always_comb and always_latch offer protections that I have recommended for 
years as Guideline #6 - "Do make assignments to the same variable from more 
than one always block" and synthesis tools now enforce this guideline and 
flag errors when an engineer makes this mistake. It is nice to have this 
checking now done by the simulation compiler.

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.

In summary, I don't think there are any proposals to deprecate always @*, 
but there has been some discussion to remove it from the internal 
statements within an always block.

Regards - Cliff

At 11:38 PM 12/3/2005, Bresticker, Shalom wrote:
>I bet you though this issue was dead, didn't you?
>
>I recently came across the claim that there is a standard situation where 
>neither always_comb nor always_latch is appropriate, but @* does work. If 
>this is really so, then we can't just deprecate @* and say to use 
>always_comb instead. We'll have to make sure that @* works properly.
>
>
>The situation is of modeling a three-state bus.
>
>In this case, we get statements like
>
>
>always @* sig = cond1 ? in1 : 1'bz ;
>
>always @* sig = cond2 ? in2 : 1'bz ;
>
>etc.
>
>
>The catch is that these statements will be found in different modules and 
>the three-state outputs are wired together at a higher level in the 
>hierarchy, thus violating the always_comb condition in 11.2 that "the 
>variables written on the left-hand side of assignments shall not be 
>written to by any other process."
>
>
>Comments? I do not remember seeing this noted elsewhere. Maybe it was and 
>I just don't remember.
>
>
>Thanks,
>Shalom

----------------------------------------------------
Cliff Cummings - Sunburst Design, Inc.
14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
Phone: 503-641-8446 / FAX: 503-641-8486
cliffc@sunburst-design.com / www.sunburst-design.com
Expert Verilog, SystemVerilog, Synthesis and Verification Training