Subject: [sv-ec] Comments on updated event proposal
From: Jay Lawrence (lawrence@cadence.com)
Date: Thu Mar 13 2003 - 05:51:19 PST
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 - 05:52:10 PST