From: Gordon Vreugdenhil (gvreugde@synopsys.com)
Date: Wed Jul 31 2002 - 08:10:02 PDT
Precedence: bulk
The following reply was made to PR errata/82; 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/82: Section 9.7.5: Description of @*, @(*) incomplete
Date: Wed, 31 Jul 2002 08:08:13 -0700
Steven Sharp wrote:
>
> Precedence: bulk
>
> The following reply was made to PR errata/82; it has been noted by GNATS.
>
> From: Steven Sharp <sharp@cadence.com>
> To: sharp@cadence.com, mac@verisity.com
> Cc: etf-bugs@boyd.com
> Subject: RE: errata/82: Section 9.7.5: Description of @*, @(*) incomplete
> Date: Tue, 30 Jul 2002 21:20:55 -0400 (EDT)
>
> > > Furthermore, as I have pointed out before, there are situations that
> > > will not behave properly with @(vector[i]). They require @(vector or i)
> > > in order to act like combinational logic. So not only does the letter
> > > of the standard require it, so does the intent.
> >
> >This I do not understand.
> >
> >combinatorial logic, as specified by
> >
> >assign out = vector[j]; will make it so out always has the value of
> >the expression vector[j];
> >
> >It is a waste of simulator resources to reassign to out the value of
> >vector[j] if that is the same as the current value of out.
>
> All the efficiency in the world is of no use if you don't get the
> right answer. If you really don't mind wrong results, I can give
> you a simulator that is as fast as you like.
>
> My earlier description of this situation appears at
>
> http://boydtechinc.com/btf/archive/btf_2002/1825.html
>
> but I will give another example here. Start with
>
> always @*
> out = vector[j];
>
> This will work with @(vector[j]). It will also work with @(vector or j).
> It will not work with @(vector).
Assuming that "j" has an unknown value, I agree. However, if j
is a genvar or similar, one may be able to optimize this and
requiring events on any change to vector is *very* expensive.
Consider something like:
always @*
out = big_mem[genvar1][genvar2][i];
Do you really want to be sensitive to any change on big_mem?
This area is very touchy -- if we *require* simulators to be sensitive
to the entire memory, some very reasonable design methodologies will
end up being unusable due to performance issues.
> Now try
>
> always @*
> for (j = 0; j < WIDTH; j = j + 1)
> out[j] = vector[j];
>
> This will not work with @(vector[j]). It must wait on all of vector,
> since out depends on all of vector. It will work with @(vector).
> It will also work with @(vector or j).
>
> To make both situations work, @* must expand a reference to vector[j]
> into @(vector or j). There is nothing else it can be expanded to that
> will work in all situations.
>
> An implementation would be free to optimize this as long as the results
> are equivalent to using @(vector or j). It is not the job of the standard
> to dictate exactly how it must be implemented, only how it must behave.
Yes and no. There are clearly implementation implications in dictating
behavior. In some cases, a simulator may be able to optimize away
certain sensitivities if it can determine that "skipping" some events would
not be a visible change, but I still don't like this in the context of
pli calls etc which can not be analyzed in this way.
I would prefer to have the standard include language that explicitly gives
the "optimization" as an acceptable behavior. Something like:
If an implementation can determine that only some portion of a memory
or vector can not be read in the related statement, the simulator may
choose to ignore changes to the unread portion of the vector or memory.
This is a "visible" behavior change in the context of pli calls and
things such as $display, but if we don't explicitly allow such behavior,
we are going to significantly curtain the adoption of this feature.
As a side note, this will be even more of an issue once the SystemVerilog
always_comb, etc. come into play.
> For the case of a reference to vector[j], @* needs to be equivalent to
> @(vector or j), so that is what the standard should specify.
I agree that this is the "cleanest" solution in terms of an easy
semantic statement, but I do not think that it is a viable solution
in terms of giving designers what they really need. If anything,
we should *require* behavior that does the analysis I mention since
the user could more easily add the "identifiers" to an explicit
sensitivity list.
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:27 PDT
and
sponsored by Boyd Technology, Inc.