Subject: Re: [sv-ec] Comments on updated event proposal
From: Francoise Martinolle (fm@cadence.com)
Date: Thu Mar 13 2003 - 13:31:38 PST
Some comments and questions:
1. wait_order
I agree with Jay we should define wait_order as a task or function so that
a success/failure state can be optionally checked. But it needs to be
$wait_order to refer to a built-in task or function.
initial @(a, b, c)
$wait_order (a, b, c); // blocks until the sequence of events completes
or fails
end
initial @(a, b, c)
if (!$wait_order(a, b, c))
display (" events out of order\n");
end
can we also do wait_order(a.triggered, b.triggered, c.triggered)?
2) assigning event variables
In the example below, the process T1 blocks forever since the synchronization
event E2 has been lost.
fork
T1: while(1) @ E2;
T2: while(1) @ E1;
T3: begin
E2 = E1;
while(1) -> E2;
end
join
what about if T1 was coded as:
T1: while(1) wait(E2.triggered);
does E2.triggered now refers to E1.triggered? or does the process T1 still
blocks
forever?
I don't like the fact you can assign an event variable to be another
synchronization handle and
processes which were sensitive on the original variables now block forever
with no
more opportunity to wake up again.
What is the purpose for assigning an event variable to another one? I don't
see an advantage.
Example:
T1: while(1) @ E2;
T2: while(1) @ E1;
T3: begin
E2 = E1;
while(1) -> E2;
end
join
In this example, I lost the process T1.
I can trigger either E1 or E2 (they point to the same synchronization
object) but only T2
will wake up.
Moreover, it depends on when the event variable assignment is done. That
means that we will
have the sensitivity lists on concurrent processes can change depending on
these event
variable assignments.
Example:
always ( @e2)
e2 = e1;
always (@e1, @e2)
-> e2
In this example, the 2 always are both sensitive to e2. Depending which one
execute first,
you will have different behaviour (another race condition). The bad thing
about the event variable
assignments is that the sensitivity of a concurrent process can be
procedurally changed.
Illustration follows:
-Assume e2 occurs, the second always executes, triggers e2 again
then the first always executes, and assigns e1 to e2, First always will
block forever because
it is sensitive to the old synchronization event e2.
-Assume the e2 occurs but the first always executes first, assign e1 to e2,
second always executes and triggers e2 which is the same as e1. That means
that in this case
the first always is equivalent to always (@e1) and will continue waking up.
I would really like to know what these event variable assignments are
trying to solve.
They can be assigned to other event variables, or assigned to null to cause
static
processes to block forever. What is the modelling purpose of this?
Francoise
'
At 08:51 AM 3/13/2003 -0500, Jay Lawrence wrote:
>A few comments, we are making progress on this.
>
>--------------------------
>Return value of wait_order
>--------------------------
>
>I think we should treat wait_order the same way we treated $cast. It is
>either a function or a task depending on how it is called. If used as a
>task then it prints an error. If used as a function it returns a status.
>So rather than inventing a new use for => you could just say.
>
> success = wait_order(a, b, c);
>Or
> success <= wait_order(a, b, c);
>
>Using existing assignment operators.
>
>
>-------------------------------
>Clarify multiple triggers issue
>-------------------------------
>
>The paragraph beginning with "Events are not limited to occur only once
>..." is unclear. Given:
>
> event a, b, c;
> wait_order(a, b, c);
>
>Which is legal
>
> a, a, a, b, b, c
>
>Or
>
> a, a, b, b, a, c
>
>Given our discussions I believe only the first sequence is legal, but
>this is unclear from the text.
>
>----------------
>Disabling events
>----------------
>
>I don't like introducing a case where @ does not block. @ always blocks.
>
>I would say that
>
> event E;
>
> E = null;
> @(E);
>
>Blocks forever because the event will never trigger. We could define.
>
> E = null;
> wait(E);
>
>To not block and continue (i.e. a null event always has E.triggered ==
>TRUE).
>
>This implies that if you are using persistent events you should use
>'wait' and 'wait.triggered' to get what you want and we just don't
>change '@'.
>
>
>
>===================================
>Jay Lawrence
>Architect - Functional Verification
>Cadence Design Systems, Inc.
>(978) 262-6294
>lawrence@cadence.com
>===================================
This archive was generated by hypermail 2b28 : Thu Mar 13 2003 - 13:33:34 PST