Re: [sv-ec] Comments on updated event proposal


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