From: Daryl Stewart (Daryl.Stewart@cl.cam.ac.uk)
Date: Wed Feb 14 2001 - 03:56:15 PST
Precedence: bulk
Ben,
The relevant statements are
Section 5.2:
Every change in value of a net or variable in the circuit being simulated, as
well as the named event, is considered an
update event.
Processes are sensitive to update events. When an update event is executed,
all the processes that are sensitive to that
event are evaluated in an arbitrary order. The evaluation of a process is also
an event, known as an evaluation event.
Section 5.4
{..snip..}
E = any active event;
if (E is an update event) {
update the modified object;
add evaluation events for sensitive processes to event queue;
} else { /* shall be an evaluation event */
evaluate the process;
add update events to the event queue;
}
<p>Notice that the sensitive processes are added immediately after an update
event occurs. Since your examples have blocking assignments, at the exact time
when a is modified by block P1, it is not actually sensitive to events on a -
it's somewhere at PointA. (If you'd used a nonblocking assign (a <= #10 ~a) or
(a <= ~a) instead it would be a different matter and the block would trigger
again because it would execute the @ before the update event occurred ...)
<p>always(@ a or @ b) // P1 block
begin
#10 a =~ a; // PointA
c = b;
end
initial // P2 block
begin
a = 1;
d = 0;
#10;
b = ~ d;
end
<p>> From the above two statements, it would seem that at time 10, "a" becomes an
> updated event.
You mean that the assignment to "a" is an update event which triggers all
processes that are sensitive to that event. Block P1 is not sensitive to that
event at the moment the update event occurs. I suspect you're confusing
verilog's always@ form with vhdls sensitivity lists?
Although section 5 is a bit weak, it seems to cover the behaviour you describe.
Feel free to email me direct for more discussion...
cheers
Daryl
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:39 PDT
and
sponsored by Boyd Technology, Inc.