Subject: Re: always_comb semantics
From: Steven Sharp (sharp@cadence.com)
Date: Wed Oct 02 2002 - 17:53:00 PDT
>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.
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
This archive was generated by hypermail 2b28 : Thu Oct 03 2002 - 10:48:55 PDT