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

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

  • Next message: Shalom.Bresticker@motorola.com: "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: sharp@cadence.com
    Cc: etf-bugs@boyd.com, btf-dtype@boyd.com
    Subject: Re: errata/282: Re: errata/282: signing
    Date: Fri, 30 Apr 2004 17:39:01 -0700

     Steven,
     
     The issue at hand is what is the meaning of the word "expression" in 4.5.1,
     which states that "Expression type depends only on the operands. It
     does not depend on the LHS(if any)."
     
     Is it the expression associated to one operator or the entire complex
     expression?
     
     The precedent providing the answer to this question is present in
     4.1.5 Arithmetic operators (just a few paragraphs before the debated
     use of the word "expression").
     
     4.1.5 deals with the specific details of how the type of the
     expression is determined, and which states among other things
     that:
     
     "....
     The result of the power operator shall be real if either operand is a
     real, integer, or signed. If both operands are unsigned then the
     result shall be unsigned.
     ..."
     
     It is clear (because of the use of the word "both") that the type of
     the power-operator-expression depends only on the type of the operands
     of this particular operator and not on the operands present in a
     complex expression which may include the power operator as a
     subexpression. Also, I cannot imagine how it would be if the type of
     the power operator expression would depend on the operand on some
     other expression included in the same overall complex expression.
     
     Once we take the correct view that 4.5.1 actually states that the type of an
     expression containing one operand depends only on the types of the
     operands associated to that operator and that this rule is applied to
     all expressions within a complex expression there is nothing else to debate
     on this issue.
     
     Alec Stanculescu
     
     PS: Your comments regarding the similarity of the rules for
     establishing size vs type of expressions are incorrect. The LRM
     specifically states in 4.5.1 that "Expression type depends only on
     the operands. It does not depend on the LHS(if any)" and in 4.4.1 it
     states:
     
     "....
     The number of bits of an expression (known as the size of the
     expression shall be determined by the operands involved in the
     expression and the context in which the expression is given.
     ..."
     
     Therefore, according to the Verilog LRM, establishing the size of an
     expression is different from establishing the type of an
     expression in that the establishing the size uses the context and
     establishing the type does not.
     
     Therefore your example involving the size of expressions, as well
     as all the associated comments have as only result to cloud the issue
     regarding how the type of expressions is established, so I propose to
     leave that part out of our discussion for the time being, until we
     resolve the issue of how to establish the type of an expression.
     
    > 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).
    >
     In 4.4.1 (Rules for expression bit lengths) the LRM talks about
     context and not just LHS, because the LHS of an expression is either
     the LHS of the assignment or the temporary in which the expression is
     evaluated in case it is part of a complex expression.
     It is the type of the temporary (I called it D) that is determined
     only by A and B. It's size is dependent also on the context in which
     it is used, namely on Z, and C in addition to A and B.
     
    >
    > > 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(C);
    > > /* 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.
    >
     Only the type of the addition depends on $signed(C), as discussed at
     the beginning, and not the type of the multiplication.
     
    > 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.
    >
     Your confusion stems from the fact that you do not have 4.4.1 fresh in
     your mind. Please read it again. The type of D depends only on A and B
     but the size of D depends on the context and that does not mean just
     LHS. How it depends is another can of worms, but let us deal with
     issues one at a time. That is why I stated that D shall have the
     appropriate size indicated by a "correct" interpretation of the LRM
     (whatever that may be), and I stated that only in such case (D has the
     appropriate size) the two code excerpts must be equivalent for a
     reasonably designed language and that luckily this is the case with
     Verilog.
     
    > > 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.
    >
     The LRM does not say that they are not equivalent. Interpreting the
     LRM in such a way in which no matter what the size of D the two can
     never be equivalent would lead to ...., which luckily is not the case.
     
    > 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;
    >
     With the proper size for D (namely 4 or more in this case), as stated in my
     comment above they should be and they are equivalent, in the sense
     that P will get the same result.
     
    > 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.
     
     We agree that the wording of the existing LRM is very important and I
     believe that the wording of the current LRM supports my view
     point.
     
     We seem to disagree on the fact that if it were impossible to write
     one expression to be assigned to Z out of
     D = $signed(A) * $signed(B);
     Z = $signed(D) + $unsigned(C);
     where D is large enough, then we would have a significant problem
     language deficiency on our hands, which we luckily do not have.
     
     A poorly designed language would have grave consequences for
     synthesis, formal verification, as well as modeling and simulation.
    >
    > Steven Sharp
    > sharp@cadence.com
    >
     
     
     
     
     
     
     

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