From: Michael McNamara (mac@verisity.com)
Date: Thu Feb 07 2002 - 10:02:31 PST
Precedence: bulk
Dennis Marsa writes:
> Michael McNamara wrote:
> >
> > Precedence: bulk
> >
> > Dennis Marsa writes:
> > > Jayaram Bhasker wrote:
> > > >
> > > > Mac:
> > > >
> > > > > > So, if any element of mem8x10 other the element 10 changes,
> > > > > > this statement would not be re-evaluated. Is that the
> > > > > > proper interpretation of @(*) in this context?
> > > >
> > > > >Yes.
> > > >
> > > > There is something not right here. Given this interpretation, there can be
> > > > mismatches between the implied hardware and the simulation behavior. For ex, if
> > > > mem8x10[7] changes, the always stmt will not execute, but the implied hardware will
> > > > execute and "a" will get a new value.
> > > >
> > > > My interpretation would be that since a variable index is being used on a memory(mem8x10[b]),
> > > > the entire memory (mem8x10) needs to be part of the event list to keep the
> > > > semantics of the implied hardware and simulation to match. In other words, my interpretation
> > > > of @* would be:
> > > >
> > > > always @(mem8x10[10] or mem8x10[0] or mem8x10[1] or mem8x10[2] or mem8x10[3] or ....<list with all
> > > > index values>)
> > >
> > > This is the way I would prefer to interpret it as well.
> > >
> > > One could shorten it to @(mem8x10[10] or mem8x10) if one
> > > defines the event mem8x10 to mean exactly as you show above:
> > >
> > > mem8x10[0] or mem8x10[1] or mem8x10[2] or ...
> > >
> > > This makes the semantics of array selects in a @(*) consistent
> > > with vector selects; i.e. if a variable index is used, then we
> > > are sensitive to the entire array (or vector).
> > >
> > > Dennis Marsa
> > > Xilinx, Inc.
> > >
> >
> > OK, I now understand that the subject is code like:
> >
> > reg [31:0] a,b, mem8x10[1024:0];
> > assign a = mem8x10[b]; // statment 1
> >
> > or eqivalently
> >
> > reg [31:0] a,b, mem8x10[1024:0];
> > always @(*) a = mem8x10[b]; // statement 2
> >
> > And still I sumbit that correct behaviour can be achieved by
> >
> > reg [31:0] a,b, mem8x10[1024:0];
> > always @(mem8x10[b]) a = mem8x10[b]; // statement 3
>
> This is fine. I agree.
>
> The example I have in mind is different. It involves b being
> defined in lower scope, so that b is either not defined at the
> point of the @(*), or would be a reference to a different
> b.
>
> reg [31:0] a, mem8x10[1024:0]; // no b defined here
> always @(*) // b not visible from here
> begin : named
> reg [31:0] b; // b defined here
> b = <something>;
> a = mem8x10[b];
> end
>
> This would seem to expand to something like:
>
> always @(<events from something> or <event involving mem8x10>)
> begin : named
> reg [31:0] b;
> b = <something>;
> a = mem8x10[b];
> end
>
> But what is <event involving mem8x10>? Saying it is mem8x10[b] seems
> suspect to me since the b used to index mem8x10 is not visible from
> there.
>
> Dennis
>
The key bit is what is in the expression <something>.
Again, you show everything in <something> getting moved up to the
sensitivity list; as well as any change to any cell of the memory.
This would certainly result in the correct simulation; but is
conservative.
For most efficient simulation (assuming the size of mem8x10 is large,
and the expression <something> is small) this code would expand to:
always @(mem8x10[<something>])
begin : named
reg [31:0] b;
b = <something>;
a = mem8x10[b];
end
To implement this simulators would need to preform reaching definition
analysis; which is well defined [Chapter 14 of Principles of Compiler
Design, Aho & Ullman, 1977 ISBN 0-201-00022-9, for one].
-mac
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:55:35 PDT
and
sponsored by Boyd Technology, Inc.