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

>>>If one side of the port connection
>>>is a variable, then there is no collapsing.
>>
>>I would agree with this interpretation.
>
>[Shalom: ] If so, does this decrease the efficiency of the simulation?

Possibly.

Note that a simulator would still be free to "collapse" a variable port
connection (i.e. treat it like a reference port instead of inserting
an implicit continuous assignment) as long as there were no visible
effects that violated the language definition.

This is not quite the same thing as requiring that it have no visible
effects.  For example, it might affect the event ordering in ways that
the LRM says are nondeterministic already.  So you might be able to
see different behavior, but the optimized behavior would still be legal.

So simulators may be able to get much of the advantage of collapsing
variable ports anyway.  They can potentially do better with nets, because
the LRM allows collapsing even if it changes the behavior in a way that 
could never happen without it.

For example, if you have an input port, and the value is forced on the
inside of the module, the force should not be visible outside the module.
If it is a variable port, it cannot be collapsed, since that would make
the force visible outside the module.  A net port could still be collapsed,
even though that would make the force visible, because it is explicitly
allowed by the LRM.


>>Personally, I think that sort of check should be left to
>>synthesis
>>tools, which can define this as combinational logic as long as
>>they
>>can synthesize it as such.
>
>[Shalom: ] I think it should be well enough defined, so that different
>tools do not interpret it differently.

Well, it is already undefined because the text says that a tool "can"
do this check.  So even if you defined what the check was, different
tools could give different results.

And I don't think that it is appropriate for the LRM to be defining
what is considered combinational logic or latches or flip-flops, since
that depends on the features of a particular synthesis tool.  The LRM
defines the language semantics, which are the simulation semantics.

If this statement in the LRM was intended to allow synthesis tools to
do this check, then I don't see the point.  Synthesis tools already
violate the language definition in so many ways, I don't see why they
need special permission in this one situation.

Steven Sharp
sharp@cadence.com