Subject: Re: LRM 5.x: Unclear about when block refires on same event that changed
From: M Ciletti (eagle64@email.msn.com)
Date: Tue Feb 13 2001 - 11:27:07 PST
Ben - here's my 2 cents:
The "always" behavior in your example parks for 10 time steps, then complements a, but notice that the event control expression cannot see this because the activity is located at the statement where the complement is taking place. Control does not return to the event control expression until all of the sequential statements in the behaviror have completed execution. When the event control expression is finally awake, it does not see what happened in the past.
Mike Ciletti
----- Original Message -----
From: VhdlCohen@aol.com
To: vlog-synth@eda.org
Sent: Tuesday, February 13, 2001 11:39 AM
Subject: LRM 5.x: Unclear about when block refires on same event that changed
This is in reference to blocking assignment.
LRM 5.6.3 says "When the process is returned, the process performs the
assignment
to the left-hand side and enables any events based upon the update of the
left-hand side.
LRM 5.4 shows the Verilog simulation reference model, and says "while (there
are events) ".
Thus, you could argue that after ther #10, ben gets ~ben, and that generates
an "active event",
that sould be re-examined. Thus, it would seem that the "always block"
should be
invoked again. Searched LRM for more info on that, and could not find any.
Referencing Cummings SNUG presentation "Nonblocking Assignments in Verilog
Synthesis, Coding
Styles That Kill!", section 7.0 Self-triggering always blocks, and
based upon what is observed, I came up with this equivalent rule.
My defintion of "time T" is current sim time. Time T + delta is a different
time T.
Rule
"At any time T, if a block is fired because of an event on a signal in its
senstivity list, then that block will NOT
be refired in the same time T as a result of a change of the same signal.
That rule makes sense because if at any sim time, a block fires as a reselt
of an event in its sensitivity list,
it does not need to refire because of the same event.
HOWEVER, this rule is NOT in the LRM. Can soimeone explain to me, from an
LRM definition, why
a Verilog always block cannot trigger itself?
Thus,
always(@ a or @ b) // P1 block
begin
#10 a =~ a;
c = b;
end
initial // P2 block
begin
a = 1;
d = 0;
#10;
b = ~ d;
end
P1 is scheduled to fire on an event in "a" or "b"
AT time 10, if P1 fires first (P2 could fire first) then
reg (or signal) "a" changes to 0, thus an event.
But, P1 will not refire because of "a" event.
P2 fires next, and "b" changes.
P1, scheduled to fire on event "b" refires.
However, if at time 10, P2 fires first. then then P1 fires because of events
"a" and "b".
------------------------------------------------------------------------------
--------------------------------------
Ben Cohen Publisher, Trainer, Consultant (310) 721-4830
http://www.vhdlcohen.com/ vhdlcohen@aol.com
Author of following textbooks:
* Component Design by Example ... a Step-by-Step Process Using
VHDL with UART as Vehicle", 2001 isbn 0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115
------------------------------------------------------------------------------
--------------------------------------
This archive was generated by hypermail 2b28 : Tue Feb 13 2001 - 11:32:42 PST