From: Gordon Vreugdenhil (gvreugde@synopsys.com)
Date: Tue Aug 27 2002 - 14:20:09 PDT
Precedence: bulk
The following reply was made to PR errata/84; it has been noted by GNATS.
From: Gordon Vreugdenhil <gvreugde@synopsys.com>
To: Steven Sharp <sharp@cadence.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/84: Should @* include delay controls?
Date: Tue, 27 Aug 2002 14:16:19 -0700
Steven Sharp wrote:
>
> From: Steven Sharp <sharp@cadence.com>
> To: etf-bugs@boyd.com
> Cc:
> Subject: Re: errata/84: Should @* include delay controls?
> Date: Thu, 15 Aug 2002 20:24:21 -0400 (EDT)
[...]
I'm going to stay away from the computability argument <grin>, but
would like to comment on the 3 options that Steven mentions.
> We cannot define the behavior of the language in terms of an algorithm
> that does not and cannot exist. That leaves several choices:
>
> 1. Leave the sensitivity list independent of whether variables could
> get values from outside the block. That is how it is now.
> 2. Specify the exact algorithm to be used to approximate the computation
> of whether a variable can get its value from outside the block.
> 3. Specify that simulators can leave variables out of the sensitivity
> list if they can determine that they never get a value from outside
> the block, by whatever algorithm they like. This could result in
> different simulators producing different results if the block has
> side effects.
I am afraid that for option 1 (and perhaps 2), implementation divergence
will almost certainly occur unless vendors agree on "how to do it"
independent of the committee work. Given the following:
reg [7:0] m [1023:0];
always @* begin
y = m[z];
$display(y);
end
We (VCS) are *definitely* going to have customer opposition to
triggering on a change to any word of m. At the very least, we
would likely have a non-standard default behavior and support
the default behavior only under a switch (if at all).
As Steven noted, for "equivalent to combinational" blocks, we can do
the right thing anyways, but even for non-combinational blocks,
customers will expect combinational sensitivities.
This is a case where (some) customers will say "I don't care about
the LRM, do what we expect".
Realistically, I think that we should try to come up with some
sort of statement on this. It might be a guarantee only in the
presence of "equivalent to combinational" blocks or it might be
that the implicit sensitivity list would be the same as one implied
by a continuous assign formed by every RHS *expression* in the
block. In any case, if we don't try to make this close to what
a designer expects, vendors will almost certainly implement
support in inconsistent and non-compliant ways.
Gord.
--
----------------------------------------------------------------------
Gord Vreugdenhil gvreugde@synopsys.com
Staff Engineer, VCS (Verification Tech. Group) (503) 547-6054
Synopsys Inc., Beaverton OR
This archive was generated by hypermail 2.1.4
: Thu Oct 10 2002 - 09:24:28 PDT
and
sponsored by Boyd Technology, Inc.