[sv-ec] Comments on updated event proposal


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