From: Michael McNamara (mac@verisity.com)
Date: Fri Feb 01 2002 - 18:00:05 PST
Precedence: bulk
Why is this difficult to understand??
always @(*) was designed to mimic the
always @(/*AUTOSENSE*/) feature of my emacs verilog mode; this
feature was designed and contributed by Wilson Snyder
<wsnyder@world.std.com>.
Very simply the feature examines every rhs expression in the rest of
the statement, and places it in the sensitivity list of the always
block.
There are interesting cases here.
Zeroth:
Assume we have:
wire w1, [31:0] w32;
reg r1, [31:0] r32;
reg [7:0] mem8x10 [9:0];
integer a,b;
First, recognize that the procedural block begin ... end is a
statement, and hence every rhs usage inside the begin .. end pair will
be added.
Second recognize that, in the statement:
r32[b] = a;
'b' and 'a' are rhs, and are added to the sensitivity list.
Third recognize that event expressions must be either regs or nets, or
bitselects or part selects of those, or expressions invloving those
(ref 9.7.2). Entire memories are neither regs nor nets. In 1364-2001,
one can have arrays of registers and arrays of nets. A memory selct
that resolves to a net or to a reg, truly is a net or a reg, and can
hence be in an event_expression.
Further recognize that one can not refer to an entire memory in an
expression, so that the statement:
a = mem8x10;
is already illegal, and so would not appear in a procedural block.
So, given
a = mem8x10[10] + mem8x10[b];
then the sensitivity list becomes:
always @(mem8x10[10] or mem8x10[b]) begin
end
Dennis Marsa writes:
> Precedence: bulk
>
> Paul Graham wrote:
> >
> > Funny how a construct designed to make things easier just causes more
> > problems :-)
>
> Funny till one tries to implement it. ;-)
>
> > I got the impression that @* was intended as a quick and easy way to model
> > combinational logic using an always block, without having to tediously
> > verify that every signal in the block was included in the sensitivity list.
>
> Yes. Except those signals can be bit/part/array selects, and nothing is
> said about the semantics of @(*) in the presence of those kinds of signal
> references.
>
What do you assume would happen?
>
> > You might want @* to be able to represent anything which is representable by
> > an explicit sensitivity list, but I think it is better to confine @* to
> > simpler cases. For instance:
> >
> > always @(x+y)
> > z = x+y;
No, instead each item 'x' and 'y' are added to the sensitivity list.
Hence:
always @(*)
z = x+y;
would be correctly mapped to:
always @(x or y)
z = x + y;
> > is perfectly legal verilog, but I'm sure we can agree that this can't be
> > modeled using @*.
>
> Absolutely. They way I read section 9.7.5 regarding @(*), it seems pretty
> clear to me that always @(x+y) can't be modelled with @(*).
>
> > So we could make some simplifying rules. For instance, @* cannot refer to a
> > variable declared within the statement that it controls. Maybe @* should
> > cause an error if used in this situation. Again, because of the concern
> > over simulation efficiency, and other problems, @* cannot refer to an array.
>
> Yes, in the absense of any concrete guidance from the standard, I am trying to
> come up with reasonable rules for how to interpret @(*) in the presense of
> bit/part/array select operations. I'm fairly comfortable with how to proceed
> with bit/part selects, but array selects are still mystifying me.
>
> I was hoping to get some guidance from the group, but there doesn't seem to be
> a clear consensus of the best way to go.
>
> Dennis
The overriding mantra for always @(*) is to map it to a continuous
assign. Basically given
always @(*) begin
/* stuff */
end
run /* stuff */ at least as many times as you need to run it to insure
that the left hand sides of all expressions are an accurate
representation of the changing right hand sides.
another way to think of it is to replace
always @(*)
with
assign
and hence imagine that assign could take a procedural block:
assign begin
a = b;
c = d;
e[f] = g;
end
Clearly you would schedule this code whenever the vaule of b, d, f,
e[f] or g changed.
-mac
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:55:35 PDT
and
sponsored by Boyd Technology, Inc.