errata/282: errata/282: Re: errata/282: signing

From: Steven Sharp (sharp@cadence.com)
Date: Fri Apr 30 2004 - 13:50:00 PDT

  • Next message: Alec Stanculescu: "errata/282: Re: errata/282: Re: errata/282: signing"

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

    From: Steven Sharp <sharp@cadence.com>
    To: etf-bugs@boyd.com, alec@fintronic.com
    Cc:
    Subject: errata/282: Re: errata/282: signing
    Date: Fri, 30 Apr 2004 17:06:19 -0400 (EDT)

     Alec,
     
     I agree with Shalom, that you are mistaken.
     
     This isn't just a matter of different people trying to interpret the
     text in the LRM. There is more information available than that. The
     text in the LRM is based on a proposal from Cadence, which was based
     on an implementation in Verilog-XL. As a result, I know the actual
     intent of the text, and have been making a special effort to make that
     information available to others.
     
     
    > > As previously discussed, the correct interpretation is (2).
    > >
    > That was not the conclusion of the discussion and issue 282 is still
    > open.
     
     Everyone who contributed to the discussion agreed with this, which
     makes it the conclusion of the discussion. There was no dissent in
     the discussion. The issue is still open because the wording in the
     LRM still needs clarification.
     
      
    > > 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.
     
     Please read the extensive discussion attached to the issue, and the
     other referenced issues in the database. There is plenty of wording
     to support this. It does help if you understand the intent already
     when you read the LRM.
     
     I am afraid that you have preconceived ideas about how it "should" work,
     based on your experience with how other programming languages work. Those
     other languages delay type conversions until an operation is about to be
     performed between values of different types. Verilog does not do this
     for vectors. For width, it converts all operands of the entire expression
     to the common full width of the expression before any operations are
     performed. The signedness rules do the same thing.
     
     You are letting your opinion be biased by your preconceptions, rather than
     just what the LRM says or implies. The fact that Verilog works differently
     from those other programming languages does not make it unsound. It is
     unfortunate that it works differently, because this causes people to be
     surprised, as you have been. However, the expression size rules in Verilog
     have always worked differently from the type rules in other languages, and
     the signedness rules need to work with the pre-existing type rules.
     
     It is possible that there was a better solution, but it was never possible
     to make Verilog fully match those other programming languages while
     maintaining backward compatibility with pre-existing Verilog. There would
     always be situations where it would not behave "intuitively" for people
     familiar with those other languages.
      
    > 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?
     
     This statement supports what Shalom and I have said.
     
     Expression size in Verilog is dependent on all of the operands in the
     expression, and also on the LHS of the assignment (if the expression is
     the RHS of an assignment).
     
     This statement is saying that the type (i.e. signedness) is not dependent
     on the LHS, even though it otherwise works the same way as size (i.e.
     being dependent on all the operands in the expression).
     
      
    > 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.*/"
     
     I don't see how your quote supports that. The only LHS in your first
     expression is Z. Since "$unsigned(C)" is not a LHS, the expression
     type depends on it.
     
     Your comment talks about the type of D depending only on A and B,
     while apparently acknowledging that C affects its size. But the only
     difference between the rules for the two is the exception for the
     LHS. Since C is not a LHS, it affects both signedness and size. If
     you don't acknowledge that C affects the size of the multiplication,
     then we need to clear up that confusion on your part first.
     
    > Do you really believe that the two code excerpts above should not be
    > equivalent?
     
     What matters is that the LRM says that they are not equivalent. Your
     beliefs based on preconceptions don't change the definition of the
     language. Your preconceptions might also say that
     
       parameter P = 2'b11 * 2'b11 + 4'b1;
     
     should be equivalent to
     
       parameter D = 2'b11 * 2'b11;
       parameter P = D + 4'b1;
     
     but these are not equivalent in Verilog. This should tell you that your
     preconceptions are not a valid guide for the definition of the language.
     If you don't believe that these should be equivalent, this shows that you
     have overcome your preconceptions by understanding the Verilog size rules.
     You need to do the same thing with the Verilog signedness rules.
     
     
     Steven Sharp
     sharp@cadence.com
     

    This archive was generated by hypermail 2.1.4 : Fri Apr 30 2004 - 13:50:23 PDT and
    sponsored by Boyd Technology, Inc.