errata/282: Re: errata/282: signing

From: Alec Stanculescu (alec@fintronic.com)
Date: Fri Apr 30 2004 - 10:20:00 PDT

  • Next message: Steven Sharp: "errata/282: errata/282: Re: errata/282: signing"

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

    From: Alec Stanculescu <alec@fintronic.com>
    To: Shalom.Bresticker@motorola.com
    Cc: harry@verplex.com, etf-bugs@boyd.com, btf-dtype@boyd.com
    Subject: Re: errata/282: signing
    Date: Fri, 30 Apr 2004 10:34:40 -0700

     Shalom,
     
    > Alec,
    >
    > Sorry, but you are mistaken on this.
    >
     I do not think so.
     
    > As previously discussed, the correct interpretation is (2).
    >
     That was not the conclusion of the discussion and issue 282 is still
     open.
     
    > The word "expression" in 4.5.1 refers to the entire RHS.
    >
     What makes you say this? There is no LRM wording to support such a
     view, and if there were such words, those would be erroneous since
     they would lead to an "unsound" and undesirable language.
     
     
    > Also as previously discussed, the LRM is unfortunately not clear enough.
    >
     How do you interpret the meaning of
     
      "4.5.1 Expression type depends only on the operands. It does not depend
           on the LHS. " ?
        
     and further more, what is the purpose of this statement?
     
     I say that it's purpose is to have
     
      "assign Z = $signed(A) * $signed(B) + $unsigned(C)"
      
      equivalent to
       
      "assign D = $signed(A) * $signed(B);
       assign Z = $signed(D) + $unsigned(B);
      /* where the type of D depends only on A and B as stipulated in 4.5.1
       and is therefore signed, and it's size is the same as the one
       determined by the LRM for evaluating the multiplication.*/"
       
     Do you really believe that the two code excerpts above should not be
     equivalent?
     
    > There are some additional issues in the database related to signing,
    > notably 35, 83, 96, 506.
    >
    > Shalom
    >
    >
    > On Thu, 29 Apr 2004, Alec Stanculescu wrote:
    >
    > > Harry,
    > >
    > > You asked the following question which became issue 282:
    > >
    > > >Given the following Verilog 2001 case,
    > > >
    > > > module test(A,B,C,Z);
    > > > parameter AW = 4, BW = 5, CW = 7, ZW = 10;
    > > > input [AW-1:0] A; // 4 bits
    > > > input [BW-1:0] B; // 5 bits
    > > > input [CW-1:0] C; // 7 bits
    > > > output [ZW-1:0] Z; // 10 bits
    > > >
    > > > assign Z = $signed(A) * $signed(B) + $unsigned(C);
    > > > endmodule
    > > >
    > > >What we are trying to determine is which implementation of (1),
    > > > (2) or (3) below is correct according to the standard rules defined in the
    > > > LRM of Verilog 2001? >
    > > > (1) Perform "D = $signed(A)*$signed(B)" first,
    > > > then truncates it to C's size, denoted as value E,
    > > > then the assignment "Z = $unsigned(E) + $unsigned(C)"
    > > >
    > > > (2) Perform "D = $unsigned(A)*$unsigned(B)" first,
    > > > then the assignment "Z = $unsigned(D) + $unsigned(C)"
    > > >
    > > > (3) Perform "D = $signed(A)*$signed(B)" first,
    > > > then the assignment "Z = $signed(D) + $unsigned(C)"
    > > >
    > >
    > > In issue 282 the most relevant part of the LRM, which was omitted from
    > > the discussion so far, is:
    > >
    > > "4.5.1 Expression type depends only on the operands. It does not depend
    > > on the LHS. "
    > >
    > > Therefore, the first expression to evaluate is the
    > > multiplication and the type of the expression depends only on the two
    > > operands.
    > >
    > > Also, we should be happy that the LRM is very clear on this issue and
    > > that the correct interpretation is consistent with sound language
    > > design which leads the following two excerpts to be equivalent:
    > >
    > > "assign Z = $signed(A) * $signed(B) + $unsigned(C)"
    > >
    > > is equivalent to
    > >
    > > "assign D = $signed(A) * $signed(B);
    > > assign Z = $signed(D) + $unsigned(B);
    > > /* where D depends only on A and B as stipulated in 4.5.1*/"
    > >
    > > It would have been a nightmare if the LRM would have stated any
    > > different on this issue.
    > >
    > > Regards,
    > >
    > > Alec Stanculescu
    >
    > --
    > Shalom Bresticker Shalom.Bresticker @freescale.com
    > Design & Reuse Methodology Tel: +972 9 9522268
    > Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890
    > POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478
    >
    >
     Alec Stanculescu
     
     
     
     
     
     

    This archive was generated by hypermail 2.1.4 : Fri Apr 30 2004 - 10:20:22 PDT and
    sponsored by Boyd Technology, Inc.