Re: errata/344: Case Statements with Real Expressions

From: Michael McNamara (mac@verisity.com)
Date: Thu May 08 2003 - 16:30:06 PDT

  • Next message: Stephen Williams: "Re: errata/344: Case Statements with Real Expressions"

    Precedence: bulk

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

    From: Michael McNamara <mac@verisity.com>
    To: Steven Sharp <sharp@cadence.com>
    Cc: etf-bugs@boyd.com
    Subject: Re: errata/344: Case Statements with Real Expressions
    Date: Thu, 8 May 2003 16:24:01 -0700

     Steven Sharp writes:
    > Precedence: bulk
    >
    > The following reply was made to PR errata/344; it has been noted by GNATS.
    >
    > From: Steven Sharp <sharp@cadence.com>
    > To: etf-bugs@boyd.com, steve@icarus.com
    > Cc:
    > Subject: Re: errata/344: Case Statements with Real Expressions
    > Date: Thu, 8 May 2003 19:04:30 -0400 (EDT)
    >
    > The standard is not specific on this. However, Verilog-XL allows it,
    > and NC-Verilog follows suit.
    >
    > The behavior seems to follow naturally from normal case statements. If
    > any of the case item expressions or case expression are real, then all
    > get converted to real. The case expression is compared to each of the
    > case item expressions in turn, using "==" since "===" doesn't apply to
    > reals.
    >
    > There might indeed be issues with roundoff errors causing failure to
    > match if the expressions involve floating point operations. However,
    > there are situations where this is not an issue and where this kind of
    > case statement would be useful. For example, if there is a predefined
    > set of real values that a variable could be set to (e.g. a choice of
    > different input clock frequencies), the case could determine which one
    > it had been set to. The input conversion of inexactly represented constants
    > such as 1.1 should be the same in all places, so the compare should work.
    >
    > Since this is allowed by Verilog-XL, and probably most other simulators,
    > and there are situations where it could be handy, I don't see any reason
    > not to allow it and document it.
    >
    > I also tested casex and casez in XL and NC, and reals are allowed there
    > too. Since any X or Z bits disappear during conversion to real, this
    > behaves exactly as if case had been used instead. Since it doesn't add
    > any capabilities beyond case, there is less argument in favor of allowing
    > reals with casex and casez.
    >
    > Steven Sharp
    > sharp@cadence.com
    >
     
     Table 11 (page 42) specifically disallows using === and !== with
     reals; from which one could conclude that case.. endcase can not
     include reals; however 4.5.2 does have one coercing the type of each
     operand to the type of the expression, which for case comparision, is
     an unsigned integer.
     
     

    This archive was generated by hypermail 2.1.4 : Thu May 08 2003 - 16:30:50 PDT and
    sponsored by Boyd Technology, Inc.