Subject: Re: [sv-ec] Comments on updated event proposal
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Thu Mar 13 2003 - 12:28:48 PST
Jay,
My responses are interspersed below in blue.
Arturo
----- Original Message -----
From: "Jay Lawrence" <lawrence@cadence.com>
To: "sv-ec" <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 :)
-------------------------------
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.
----------------
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 '@'.
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.
===================================
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 - 12:27:05 PST