Re: errata/463: 4.1.13: Zero fill in ?: even if signed or x/z

From: Brad Pierce (Brad.Pierce@synopsys.com)
Date: Fri Aug 05 2005 - 16:20:01 PDT

  • Next message: Steven Sharp: "Re: errata/463: 4.1.13: Zero fill in ?: even if signed or x/z"

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

    From: "Brad Pierce" <Brad.Pierce@synopsys.com>
    To: <etf-bugs@boyd.com>
    Cc:
    Subject: Re: errata/463: 4.1.13: Zero fill in ?: even if signed or x/z
    Date: Fri, 5 Aug 2005 16:17:12 -0700

     The LRM doesn't seem clear about *when* the legs of a ?: are signed. By
     analogy with width in ?: and with signedness determination in case
     statements, I've assumed that whenever one leg of a ?: is unsigned, then
     the other leg is unsigned. But I don't find this spelled out explicitly
     in the LRM.
     
     -- Brad
     
     -----Original Message-----
     From: owner-etf@boyd.com [mailto:owner-etf@boyd.com] On Behalf Of Steven
     Sharp
     Sent: Thursday, September 04, 2003 3:40 PM
     To: etf-bugs@boyd.com
     Subject: Re: errata/463: 4.1.13: Zero fill in ?: even if signed or x/z
     
     Precedence: bulk
     
     The following reply was made to PR errata/463; it has been noted by
     GNATS.
     
     From: Steven Sharp <sharp@cadence.com>
     To: etf-bugs@boyd.com, Brad.Pierce@synopsys.com
     Cc:
     Subject: Re: errata/463: 4.1.13: Zero fill in ?: even if signed or x/z
     Date: Thu, 4 Sep 2003 18:33:05 -0400 (EDT)
     
      Brad,
      
      You are right that this is inconsistent with the rest of Verilog. It
     is also not what was intended.
      
      It is difficult to describe the full Verilog width-extension rules in
     simple English. Covering cases like compares (whose operands need to
     match in width, but whose result is always 1 bit), and conditionals
     (where the condition is self-determined, but the selected expressions
     aren't) makes the rules harder to describe. As a result, the text in
     the 1995 LRM described some simplified rules that apply to most
     operators, and then spelled out the behavior of compares and
     conditionals separately in the descriptions of those operators.
      
      The problem is that those descriptions were written before signed
     arithmetic was added in Verilog-2001. So they describe the unsigned
     case. And when the width-extension rules were generalized to cover
     signed arithmetic, those separate descriptions didn't get updated. So
     they are now wrong. I think that Shalom already reported the
     discrepancy on compares in a different erratum.
      
      Note also that the description in 4.1.13 is simplified in a different
     way.
      It doesn't take into account the possibility that the operator appears
     in a wider expression. So it only says that the shorter operand gets
     extended to match the wider operand. In fact, both operands are
     context-determined, and get extended to the width of the expression.
     This might be the same as the width of the wider operand, but it might
     not. There is not a 2-step process of extending to the width of the
     other operand using zero-extension, followed by extending to the width
     of the expression using normal rules for the signedness of the
     expression. There is just the normal process of extending both
     operands to the width of the expression, using the normal rules for the
     signedness of the expression.
      
      Steven Sharp
      sharp@cadence.com
      
     

    This archive was generated by hypermail 2.1.4 : Fri Aug 05 2005 - 16:20:41 PDT and
    sponsored by Boyd Technology, Inc.