Re: errata/88: 9.7.2 should say that event_controls can be expressions

From: Steven Sharp (sharp@cadence.com)
Date: Thu May 01 2003 - 15:20:02 PDT

  • Next message: Michael McNamara: "IEEE 1364-2001c"

    Precedence: bulk

    The following reply was made to PR errata/88; it has been noted by GNATS.

    From: Steven Sharp <sharp@cadence.com>
    To: etf-bugs@boyd.com, Shalom.Bresticker@motorola.com
    Cc:
    Subject: Re: errata/88: 9.7.2 should say that event_controls can be expressions
    Date: Thu, 1 May 2003 18:17:34 -0400 (EDT)

    > Does the LRM say EXPLICITLY anywhere that in any of the cases where it waits
     for
    > a change in the value of an expression, then the expression is re-evaluated
     only
    > when the value of one of the operands changes, but not if only the result
     value
    > of a function changes?
     
     That is how it works, but I don't think it says so explicitly in the LRM.
     
     
    > I did not succeed in finding a clear statement that function values are not
    > continuously re-evaluated, but only when an input argument changes value.
     
     And it gets more complicated than that.
     
     It might get evaluated when an operand in an expression used as an input
     argument changes, even though the input argument value doesn't change.
     
     It might get evaluated when nothing in its input arguments changed, but it
     appears in a more complex expression with other operands that changed.
     
     It might not be evaluated even if its input argument changed, if it comes
     after an event-or with another value that changed, so that it is not
     necessary to evaluate it to know that the block has triggered. The same
     may apply to combinations with other short-circuiting operators.
     
     It might or might not get evaluated if variables in the expression changed
     values and then changed back again immediately (zero-width glitches, which
     are often created by code that tries to avoid inferring latches by assigning
     a default value at the start).
     
     It will probably get evaluated again when the event control is reached again,
     to determine the new "current value" to wait for it to change away from.
     
     It seems unlikely that any implementation evaluates the expressions unless
     at least one operand somewhere in the event control changed value at least
     temporarily, but I could be wrong.
     
     Any attempted clarification will need to be worded carefully to avoid
     invalidating existing implementations.
     
     The best way to get reliable behavior is to use functions that depend only
     on their inputs and have no side effects.
     
    > What happens when an operand which is a net changes strength, but not value?
     
     That may be implementation-dependent too.
     
      
    > The cases I thought of where all this is relevant are:
    >
    > - continuous assignment (regular, procedural, and force)
    > - @()
    > - wait statement
    > - $monitor
    > - port connections
    >
    > Are there others?
     
     Delay expressions on primitives and nets, which don't have to be constant,
     in which case they have to be re-evaluated whenever they might have changed.
     
     Steven Sharp
     sharp@cadence.com
     

    This archive was generated by hypermail 2.1.4 : Thu May 01 2003 - 15:21:05 PDT and
    sponsored by Boyd Technology, Inc.