Subject: Re: [sv-ec] Comments on updated event proposal
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Thu Mar 13 2003 - 17:52:22 PST
MessageMy comments in green.
We have to settle this or we'll run out of colors :)
New proposal that incorporates all the feedback is attached.
Arturo
----- Original Message -----
From: Jay Lawrence
To: Arturo Salz ; sv-ec
Sent: Thursday, March 13, 2003 12:37 PM
Subject: RE: [sv-ec] Comments on updated event proposal
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" <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 :)
Yes this is incredibly ugly. See Stefen's comments as well. We'll have to find something better than => however.
I don't think this is incredibly ugly. If I did I wouldn't have proposed it. The idea fro this syntax
came from a horizontal mirror reversal of the NBA version: from A <= B to B => A.
In any event, there are alternatives to this. One is Stefen's suggestion of using pass/fail
statements similar to the ones used in assertions. The other is to overload the wait_order
construct to return the completion status of its last use. For example, when wait_order is
used as an expression (i.e. function) with no arguments:
wait_order( a, b, c );
if( wait_order ) // evaluates to 1 if last operation was successful
-------------------------------
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.
We discussed this in another exchange.
----------------
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.
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.
I've made the corresponding changes to support option (3). The attached proposal reflects that.
===================================
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 - 17:51:46 PST