From: Shalom.Bresticker@motorola.com
Date: Sat Aug 03 2002 - 22:10:06 PDT
Precedence: bulk
The following reply was made to PR errata/84; it has been noted by GNATS.
From: Shalom.Bresticker@motorola.com
To: Michael McNamara <mac@verisity.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/84: Should @* include delay controls?
Date: Sun, 4 Aug 2002 08:06:41 +0300 (IDT)
Mac,
I have not managed to follow every single email on this subject, so I may have
missed something important.
But, regarding the "iterative vector indexing implicit sensitivity," at least in
the example you give, isn't that a case where i is a temporary variable assigned
before its use, where we say that it will not be included in the sensitivity
list?
And the second case is of an array (as opposed to a vector), where you could not
put it even explicitly into a sensitivity list.
I claim that we must not, if at all possible, deliberately create a situation
where a legitimate way of writing combinational logic will simulate wrong using
@*.
An array is a different case, because even today, you could not write it even
with an explicit sensitivity list. A simulator can distinguish between a vector
and an array.
I don't see causing 'erroneous' behavior as viable.
Better to delete @* entirely.
I think it is necessary to guarantee correct behavior with vectors.
Regarding arrays, it would be possible to say it should map to mem[addr] in
Mac's example. In cases where that might not be sufficient, the standard could
say that @* does not cover that case and implementations might give an error
message if they cannot map it correctly.
I also agree with the approach that it is better to give a mapping that might be
overkill but works, rather than something which is efficient but wrong. The
latter is out of the question in my mind.
Shalom
On Thu, 1 Aug 2002, Michael McNamara wrote:
> I agree; and given that Steve quite correctly point out that we can't
> have both correct iterative vector indexing implict sensitivity, and
> implicit sensitivity to with code that indexes into arrays, with what
> is currently in the standard, I would rather that we lean toward the
> later rather than the former.
>
> So, specifically, I would rather that we inject an errata to state
> that given the following definitions:
>
> integer i;
> reg [1024:0] a, b;
> reg [31:0] memdata, memory[1024*1024:0];
> reg [19:0] memaddr;
>
> the following code:
>
> always @(*)
> for (i = 0; i < 32; i = i + 1)
> a[i] = b[i];
> always @(*)
> memdata = memory[memaddr];
>
> will map to:
>
> always @(b[i]) // wrong
> for (i = 0; i < 32; i = i + 1)
> a[i] = b[i];
> always @( memory[memaddr]) // right
> memdata = memory[memaddr];
>
> rather than to:
>
> always @(b or i) // right
> for (i = 0; i < 32; i = i + 1)
> a[i] = b[i];
>
> always @(memory or memaddr) // wrong
> memdata = memory[memaddr];
>
> As I expect that the second always block (or indeed always blocks that
> do many things including differencing arrays) are much more common in
> todays and in future usage; where as bit walking through vectors is
> less common.
>
> I can see a more complicated errata that states that simulator vendors
> shall correctly handle bit walking by either mapping it
> [conservatively] to @(vector or i); and even better map it to
> [precisisely] @(vector[5:0])
>
> -mac
>
> Shalom Bresticker writes:
> > Precedence: bulk
> >
> > The following reply was made to PR errata/84; it has been noted by GNATS.
> >
> > From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
> > To: sharp@cadence.com
> > Cc: etf-bugs@boyd.com
> > Subject: Re: errata/84: Should @* include delay controls?
> > Date: Thu, 01 Aug 2002 11:35:44 +0300
> >
> > Generally, my feeling is that we should remember that the implicit
> > event_expression list is supposed to facilitate combinational logic.
> > Therefore, it should include, if at all possible, whatever is necessary
> > to simulate combinational logic correctly.
> >
> > Other stuff, such as those mentioned here, or the side-effects mentioned
> > in errata/82,
> > don't need to concern us so much. That is, we can define it as we wish,
> > and the result is whatever it is,
> > as long as combinational logic descriptions still work correctly.
> >
> > I do accept the idea that where there is a comparable continuous
> > assignment,
> > the behavior should be similar to that of the continuous assignment.
> >
> > Shalom
> >
> >
>
This archive was generated by hypermail 2.1.4
: Thu Oct 10 2002 - 09:24:27 PDT
and
sponsored by Boyd Technology, Inc.