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

Cliff,

>First - I don't remember there being any discussion about
>deprecating @*

[Shalom: ] Steven Sharp already related to this.


>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!!
>:-)

[Shalom: ] Whether three-states are best written as continuous
assignments depends, among other things, on the complexity of the logic
driving the data and enable, and whether it is registered or not.

The case I have been describing is indeed of one driver in one module.
However, you may have several different blocks driving the same common
bus. For example, peripherals connected to a common data bus. This is
very common. In this case, you can't put the different drivers in the
same module.


>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.

[Shalom: ] You of course mean "Do NOT make ...".



>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.

[Shalom: ] I don't think so. Whether or not my logic is synthesized or
not, for verification or for design, I certainly 
have in mind a model of whether it remembers its last value or not.

Shalom