From: Michael McNamara (mac@verisity.com)
Date: Thu Aug 01 2002 - 18:40:03 PDT
Precedence: bulk
The following reply was made to PR errata/84; it has been noted by GNATS.
From: Michael McNamara <mac@verisity.com>
To: Shalom Bresticker <Shalom.Bresticker@motorola.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/84: Should @* include delay controls?
Date: Thu, 1 Aug 2002 18:39:11 -0700
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.