Subject: Re: always_comb semantics
From: Gordon Vreugdenhil (gvreugde@synopsys.com)
Date: Thu Oct 03 2002 - 10:59:24 PDT
Steven Sharp wrote:
>
> >Except that the simulation semantics change!
> >
> >always_comb (for example) and @* do not give the same results
> >if there is a function call in the block.
>
> I'm sorry, but that doesn't justify adding it. If you have two
> proposals to do the same thing, with different syntax and only
> subtly different semantics, you don't accept both proposals. You
> figure out which syntax you like and which semantics are best and
> you use those.
Steven, while I essentially agree with all of your arguments below,
I disagree with the axiomatic statement above. If there are
two different semantics and both are important to the community
of language *users* you figure out how to represent both semantics
in the best way possible.
The main issue (I think) is whether we buy the argument that
SystemVerilog is making -- that the semantic difference is
important and useful.
Gord.
>
> The existing semantics for @* have several advantages:
> 1. They have already been standardized.
> 2. They exactly match continuous assignments.
> 3. They don't require threading through arbitrary levels of function calls,
> possibly including non-local ones called via hierarchical references, to
> figure out what the sensitivity is.
> 4. They allow you to deliberately hide side effects that you don't want to
> be sensitive to, like incrementing a count of the number of evaluations
> or calling $random(seed) or using an index variable in a for-loop, all of
> which change the content of a function. Otherwise different blocks that
> call the same function could wake each other up unnecessarily and go into
> an infinite simulation loop of mutual wakeups.
> 5. They don't require you to define exactly what changes in functions you
> have to be sensitive to (e.g. hierarchical references to locals, variables
> that are read but only after being written in the function (like for-loop
> indices), one call inheriting a value from a different call because it
> didn't set a static variable before using it (and since that could include
> the function return value, all function calls would have to wake up any
> always_comb that calls the function)).
> 6. You don't get different behavior between changes in a function and changes
> in a task, which always_comb apparently does.
>
> The proposed semantics for always_comb has the advantage:
> 1. It is more correct if the block calls a function that is impure.
>
> >If we do this only via attributes, are we going to *require* that
> >simulators respect the meaning of an attribute? Are you really
> >proposing that or are you saying that we should ignore this
> >completely?
>
> I'm saying we should ignore it. The attribute comment was only in regards
> to the lint checks like "single assignment to any LHS".
>
> > SystemVerilog 3.0 explicitly discusses the difference
> >since @* wasn't sufficient for real designs (in terms of simulation
> >semantics). If we drop the other forms, we end up going back
> >to requiring the users to have explicit sensitivity lists in
> >cases like that.
>
> Continuous assignments are the most common way of coding combinational
> logic. They are more likely to call functions, since that is the only
> way they can use code with for-loops or cases. They are only sensitive
> to the arguments in a function call. If this is a major issue, why
> hasn't it come up for continuous assignments?
>
> And synthesis lint checks can detect calls to functions that appear to
> be impure, whether used in a continuous assign or a combinational always.
>
> Steven Sharp
> sharp@cadence.com
-- ---------------------------------------------------------------------- Gord Vreugdenhil gvreugde@synopsys.com Staff Engineer, VCS (Verification Tech. Group) (503) 547-6054 Synopsys Inc., Beaverton OR
This archive was generated by hypermail 2b28 : Thu Oct 03 2002 - 11:00:13 PDT