Re: errata/140: Section 4.1.5: Definition of power operator result type

From: Kurt Baty (kurt@wsfdb.wsfdb.com)
Date: Mon May 26 2003 - 09:00:05 PDT

  • Next message: Simon Davidmann: "Re: read unix environment variable into Verilog?"

    Precedence: bulk

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

    From: Kurt Baty <kurt@wsfdb.wsfdb.com>
    To: etf-bugs@boyd.com
    Cc: kurt@wsfdb.wsfdb.com, jam@magic.com, Shalom.Bresticker@motorola.com
    Subject: Re: errata/140: Section 4.1.5: Definition of power operator result type
    Date: Mon, 26 May 2003 10:50:35 -0500 (CDT)

    > From: "James A. Markevitch" <jam@magic.com>
    > > > How about some alternate wording:
    > > > non-real case always truncates result toward 0
    > >
    > > But that is misleading for base = 1 or -1.
    >
    > Those cases have exact integer results, so the truncation rule is still
    > accurate, but maybe misleading. How about
    >
    > non-real case truncates any fraction toward 0
     
     I like:
     
             non-real case truncates all fractions toward 0
     
     
     How does that set with the rest of you?
     
    > From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
    > Small comments:
    >
    > > NEW PROPOSAL (submitted 5/19/03):
    > >
    > > Part I:
    > >
    > > REPLACE (3rd paragraph of 4.1.5):
    > > WITH (new 3rd and 4th paragraphs of 4.1.5):
    > > If either operand of the power operator is real, then the result type
    > > shall be real.
    >
    > It is unclear what happens if base is 0 and power is 0 or negative.
     
     yes, and this is buy intent, talking to steve, verilog for the real cases
     wants "to be able" to call the c-lib pow function, which depends on which machine
     you are running on and which c-lib you have, and does not return the same answer
     on all machines and all c-libs. I thought maybe say that "the answer may depend
     on the target machine and c-lib" steve thought not, so the verilog standard
     says nothing.
     
    >
    > > If neither operand of the power operator is real, then the result type
    > > shall be determined as outlined in 4.4.1 and 4.5.1, with the second
    > > operand treated as self-determined. The result value is 'bx if
    > > the first operand is zero and the second operand is negative.
    > > The result value is 1 if the second operand is zero.
    > >
    > > op1 ** op2 where op1, op2 are not real:
    > >
    > > op1 is negative<-1 -1 zero 1 positive>1
    > > --------------------------------------------------------------------------
    > > op2 is
    > > positive int(op1 ** op2) op2 is odd -> -1 0 1 int(op1 ** op2)
    >
    > int() function not defined.
     
     good point, I was speaking mathematically the "int" function is implied.
     ie. is unnecessary any way for these spots in the grid because there are no fractions.
     op1 and op2 are not reals, so all values of op1 and op2 (op2 positive) have
     "integer" answers (math integer here) so:
     
        op1 ** op2 where op1, op2 are not real:
     
          op1 is negative<-1 -1 zero 1 positive>1
        --------------------------------------------------------------------------
        op2 is
        positive op1 ** op2 op2 is odd -> -1 0 1 op1 ** op2
     
     
     would be ok for me.
     
     feedback?
     
             kurt
     
     

    This archive was generated by hypermail 2.1.4 : Mon May 26 2003 - 09:23:13 PDT and
    sponsored by Boyd Technology, Inc.