Subject: RE: [sv-ec] Comments on updated event proposal
From: Jay Lawrence (lawrence@cadence.com)
Date: Thu Mar 13 2003 - 12:37:15 PST
Comments in fuchsia.
Jay
-----Original Message-----
From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
Sent: Thursday, March 13, 2003 3:29 PM
To: Jay Lawrence; sv-ec
Subject: Re: [sv-ec] Comments on updated event proposal
Jay,
My responses are interspersed below in blue.
Arturo
----- Original Message -----
From: "Jay Lawrence" < <mailto:lawrence@cadence.com>
lawrence@cadence.com>
To: "sv-ec" < <mailto:sv-ec@eda.org> sv-ec@eda.org>
Sent: Thursday, March 13, 2003 5:51 AM
Subject: [sv-ec] Comments on updated event proposal
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.
There is a very good reason for not using wait_order as a function.
This is a blocking construct! Allowing its use as a function opens the
door
to all the problems that caused functions to be limited to be
non-blocking.
As shown in your snipet, wait_order is a statement so can it be embedded
inside arbitrary expressions or passed as an argument.
You were not the first to think about making this a function :)
Yes this is incredibly ugly. See Stefen's comments as well. We'll have
to find something better than => however.
-------------------------------
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.
Both of those sequences would succeed (I don't like the word legal).
Examples of sequences that would fail are:
b a b c
c a b c
a c b
I believe that the ordering you seem to imply is a more strigent
variant.
Nonetheless, I can see the reason for the confusion. Will the following
change
to the defintion clarify things:
The wait_order construct suspends the calling process until all the
specified events
are triggered in the given order (left to right), or any of the
un-triggerered events is
triggered out of order and causes the construct to fail. For the
construct to succeed,
at any point in the sequence, the subsequent events --- which must be
un-triggered
at this point or the sequence would have already failed --- must be
triggered in the
prescribed order. Preceding events are not limited to occur only once,
that is, once an
event occurs in the prescribed order, it can be triggered again without
causing the
construct to fail.
I clearly remember a previous note on this topic where you stated that
wait_order(a, b, c)
was equal to
wait( a & !b & !c); wait(!a & b & !c); wait(!a & !b & c);
i.e. Once 'a' has happened then in can not happen again until 'b' and
'c' have happened.
Am I misremembering? I'll look for the old email.
----------------
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 <mailto:'@'> '@'.
The behavior of waiting on a null event is largely arbitrary. I can
envision
three plausible semantics:
1) Waiting on a null event doesn't block (current proposal). The
rational for
this is that if the event is a handle to a synchornization queue and
the
handle is null then there's no queue in which to wait.
2) Waiting on a null event blocks forever (Jay's proposal). The rational
for this
is that there is no way to trigger the event. It does imply that the
process
is blocked somewhere.
3) Waiting on a null event is undefined, and may cause a warning message
to
be issued. This in effect treats it as an error, which I avoided
doing because
Verilog is not too keen on run-time errors (i.e., divison by zero,
...).
I now believe that option (3) is the most appropriate for SystemVerilog.
I could go for #2 or #3. There was another interesting comment that this
may not wait forever under scenario #2 if E was subsequently reassigned
to something non-null, but I think we discussed this one day. @(E) is
waiting on whatever E is when the statement is evaluated, subsequent
changes have no effect. We should probably state this explicitly if it
is not already.
===================================
Jay Lawrence
Architect - Functional Verification
Cadence Design Systems, Inc.
(978) 262-6294
<mailto:lawrence@cadence.com> lawrence@cadence.com
===================================
This archive was generated by hypermail 2b28 : Thu Mar 13 2003 - 12:38:45 PST