| Number | 140
|
| Category | errata
|
| Synopsis | Section 4.1.5: Definition of power operator result type
|
| State | lrmdraft
|
| Class | errata-discuss
|
| Arrival-Date | Oct 02 2002
|
| Originator | Dennis Marsa
|
| Release | 2001b: 4.1.5
|
| Environment |
|
| Description |
The 3rd paragraph of Section 4.1.5 attempts to define the result type of the power operator. The following BTF thread discusses several issues with this definition. http://boydtechinc.com/btf/archive/btf_2002/1776.html Submitting for consideration by the ETF. |
| Fix |
Part I: REPLACE (3rd paragraph of 4.1.5): 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. The result of the power operator is unspecified if the first operand is zero and the second operand is non-positive, or if the first operand is negative and the second operand is not an integral value. WITH (new 3rd and 4th paragraphs of 4.1.5): In all cases the second operand shall be treated as self-determined. If either operand of the power operator is real then: The result type shall be real. The result of the power operator is unspecified if the first operand is zero and the second operand is non-positive, or if the first operand is negative and the second operand is not an integral value. 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 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. These statements are illustrated in the following table 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
op2 is even -> 1
zero 1 1 1 1 1
negative 0 op2 is odd -> -1 'bx 1 0
op2 is even -> 1
------------------------------------------------------------------------ Part II: REPLACE (Title of Table 15 in 4.1.5): Examples of modulus operators WITH (new Title of Table 15 in 4.1.5): Examples of modulus and power operators ------------------------------------------------------------------------ Part III: REPLACE (The sentence immediately prior to Table 15): Table 15 gives examples of modulus operations. WITH Table 15 gives examples of some modulus and power operations. ------------------------------------------------------------------------ Part IV: REPLACE (heading of first column in Table 15): Modulus expression WITH (new heading of first column in Table 15): Expression ------------------------------------------------------------------------ Part V: Append the following power operator examples to Table 15:
Expression Result Comments
3**2 9 3*3
2**3 8 2*2*2
2**0 1 anything to the zero exponent is 1
0**0 1 zero to the zero exponent is also 1
2.0**-3'sb1 0.5 2.0 is real, giving real reciprocal
2**-3'sb1 0 2**-1 = 1/2 Integer division truncates to zero
0**-1 'bx 0**-1 = 1/0 Integer division by zero is 'bx
9**0.5 3.0 Real square root
9.0**(1/2) 1.0 Integer division truncates exponent to zero
-3.0**2.0 9.0 Defined, because real 2.0 is still integral value
|
| Audit-Trail |
From: Stefen Boyd <stefen@boyd.com> To: etf-bugs@boyd.com Cc: kurt@wsfdb.wsfdb.com Subject: errata/140: negative exponents Date: Mon, 05 May 2003 12:00:46 -0700 resend of Kurts email so it goes into database ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Charset: us-ascii X-Sun-Content-Lines: 15 x ** -(numbers) some test code and results: included source file "fphdl64_real_functions.inc" included source file "fphdl64_real_functions_base.inc" can be found at: http://www.eda.org/fphdl/ ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: ieee_etf_140_test.v X-Sun-Charset: us-ascii X-Sun-Content-Lines: 29 module ieee_etf_140_test; `include "fphdl64_real_functions.inc" parameter limit = 4; integer x,y,answer; real x_real,answer_real; reg [63:0] x_bits,answer_bits; initial begin x_real = 0.5; x = x_real; $display("x = %0d = x_real =",x,x_real); $display; for(y=limit;y>=-limit;y=y-1) begin for(x=limit;x>=-limit;x=x-1) begin x_real = x; x_bits = $realtobits(x_real); answer_bits = pow(x_bits,y); answer_real = $bitstoreal(answer_bits); answer = answer_real; $display("%0d ** %0d = %0d = ",x,y,answer,answer_real); end end end endmodule ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: verilog.log X-Sun-Charset: us-ascii X-Sun-Content-Lines: 128 Host command: /data/verilog/cadence/LDV_4.0/tools/verilog/bin/verilog.exe Command arguments: ieee_etf_140_test.v VERILOG-XL 4.00.s003 log file created May 5, 2003 13:10:00 VERILOG-XL 4.00.s003 May 5, 2003 13:10:00 Copyright (c) 1995 Cadence Design Systems, Inc. All Rights Reserved. Unpublished -- rights reserved under the copyright laws of the United States. Copyright (c) 1995 UNIX Systems Laboratories, Inc. Reproduced with Permission. THIS SOFTWARE AND ON-LINE DOCUMENTATION CONTAIN CONFIDENTIAL INFORMATION AND TRADE SECRETS OF CADENCE DESIGN SYSTEMS, INC. USE, DISCLOSURE, OR REPRODUCTION IS PROHIBITED WITHOUT THE PRIOR EXPRESS WRITTEN PERMISSION OF CADENCE DESIGN SYSTEMS, INC. RESTRICTED RIGHTS LEGEND Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 or subparagraphs (c)(1) and (2) of Commercial Computer Software -- Restricted Rights at 48 CFR 52.227-19, as applicable. Cadence Design Systems, Inc. 555 River Oaks Parkway San Jose, California 95134 For technical assistance please contact the Cadence Response Center at 1-877-CDS-4911 or send email to support@cadence.com For more information on Cadence's Verilog-XL product line send email to talkv@cadence.com Compiling source file "ieee_etf_140_test.v" Compiling included source file "fphdl64_real_functions.inc" Compiling included source file "fphdl64_real_functions_base.inc" Continuing compilation of source file "fphdl64_real_functions.inc" Continuing compilation of source file "ieee_etf_140_test.v" Highest level modules: ieee_etf_140_test x = 1 = x_real =0.5 4 ** 4 = 256 = 256 3 ** 4 = 81 = 81.00000000000001 2 ** 4 = 16 = 16 1 ** 4 = 1 = 1 0 ** 4 = 0 = 0 -1 ** 4 = 1 = 1 -2 ** 4 = 16 = 16 -3 ** 4 = 81 = 81.00000000000001 -4 ** 4 = 256 = 256 4 ** 3 = 64 = 64 3 ** 3 = 27 = 27.00000000000001 2 ** 3 = 8 = 8 1 ** 3 = 1 = 1 0 ** 3 = 0 = 0 -1 ** 3 = -1 = -1 -2 ** 3 = -8 = -8 -3 ** 3 = -27 = -27.00000000000001 -4 ** 3 = -64 = -64 4 ** 2 = 16 = 16 3 ** 2 = 9 = 9 2 ** 2 = 4 = 4 1 ** 2 = 1 = 1 0 ** 2 = 0 = 0 -1 ** 2 = 1 = 1 -2 ** 2 = 4 = 4 -3 ** 2 = 9 = 9 -4 ** 2 = 16 = 16 4 ** 1 = 4 = 4 3 ** 1 = 3 = 3 2 ** 1 = 2 = 2 1 ** 1 = 1 = 1 0 ** 1 = 0 = 0 -1 ** 1 = -1 = -1 -2 ** 1 = -2 = -2 -3 ** 1 = -3 = -3 -4 ** 1 = -4 = -4 4 ** 0 = 1 = 1 3 ** 0 = 1 = 1 2 ** 0 = 1 = 1 1 ** 0 = 1 = 1 0 ** 0 = 0 = 0 -1 ** 0 = 1 = 1 -2 ** 0 = 1 = 1 -3 ** 0 = 1 = 1 -4 ** 0 = 1 = 1 4 ** -1 = 0 = 0.25 3 ** -1 = 0 = 0.3333333333333333 2 ** -1 = 1 = 0.5 1 ** -1 = 1 = 1 0 ** -1 = 0 = 0 -1 ** -1 = -1 = -1 -2 ** -1 = -1 = -0.5 -3 ** -1 = 0 = -0.3333333333333333 -4 ** -1 = 0 = -0.25 4 ** -2 = 0 = 0.0625 3 ** -2 = 0 = 0.1111111111111111 2 ** -2 = 0 = 0.25 1 ** -2 = 1 = 1 0 ** -2 = 0 = 0 -1 ** -2 = 1 = 1 -2 ** -2 = 0 = 0.25 -3 ** -2 = 0 = 0.1111111111111111 -4 ** -2 = 0 = 0.0625 4 ** -3 = 0 = 0.015625 3 ** -3 = 0 = 0.03703703703703701 2 ** -3 = 0 = 0.125 1 ** -3 = 1 = 1 0 ** -3 = 0 = 0 -1 ** -3 = -1 = -1 -2 ** -3 = 0 = -0.125 -3 ** -3 = 0 = -0.03703703703703701 -4 ** -3 = 0 = -0.015625 4 ** -4 = 0 = 0.00390625 3 ** -4 = 0 = 0.01234567901234567 2 ** -4 = 0 = 0.0625 1 ** -4 = 1 = 1 0 ** -4 = 0 = 0 -1 ** -4 = 1 = 1 -2 ** -4 = 0 = 0.0625 -3 ** -4 = 0 = 0.01234567901234567 -4 ** -4 = 0 = 0.00390625 0 simulation events (use +profile or +listcounts option to count) CPU time: 0.4 secs to compile + 0.2 secs to link + 0.2 secs in simulation End of VERILOG-XL 4.00.s003 May 5, 2003 13:10:01 -------------------- Stefen Boyd Boyd Technology, Inc. stefen@BoydTechInc.com (408)739-BOYD www.BoydTechInc.com (408)739-1402 (fax) From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: Kurt Baty <kurt@wsfdb.wsfdb.com> Cc: etf-bugs@boyd.com Subject: Re: errata/140: negative exponents Date: Thu, 08 May 2003 12:38:23 +0300 This is a multi-part message in MIME format. --------------480D76C05C8459E635332507 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kurt, I ran your code through VCS 6.2 and got the attached results. Shalom > x ** y where x, y are integers: > > x is positive zero negative > --------------------------------------------------- > y is > > positive x ** y 0 x ** y > > zero 1 0 1 > > negative x = 1 -> 1 0 x = -1 and > x = 2 and y is odd -> -1 > y = -1 -> 1 x = -1 and > else 0 y is even -> 1 > x = -2 and > y = -1 -> -1 > else 0 > > maybe someone could run the same thing in C, > and maybe VCS also? -- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 --------------480D76C05C8459E635332507 Content-Type: text/plain; charset=us-ascii; name="vcs.log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="vcs.log" Chronologic VCS simulator copyright 1991-2002 Contains Synopsys proprietary information. Compiler version 6.2R10; Runtime version 6.2R10; May 8 12:29 2003 x = 1 = x_real =0.5 4 ** 4 = 256 = 256 3 ** 4 = 81 = 81 2 ** 4 = 16 = 16 1 ** 4 = 1 = 1 0 ** 4 = 0 = 0 -1 ** 4 = 1 = 1 -2 ** 4 = 16 = 16 -3 ** 4 = 81 = 81 -4 ** 4 = 256 = 256 4 ** 3 = 64 = 64 3 ** 3 = 27 = 27 2 ** 3 = 8 = 8 1 ** 3 = 1 = 1 0 ** 3 = 0 = 0 -1 ** 3 = -1 = -1 -2 ** 3 = -8 = -8 -3 ** 3 = -27 = -27 -4 ** 3 = -64 = -64 4 ** 2 = 16 = 16 3 ** 2 = 9 = 9 2 ** 2 = 4 = 4 1 ** 2 = 1 = 1 0 ** 2 = 0 = 0 -1 ** 2 = 1 = 1 -2 ** 2 = 4 = 4 -3 ** 2 = 9 = 9 -4 ** 2 = 16 = 16 4 ** 1 = 4 = 4 3 ** 1 = 3 = 3 2 ** 1 = 2 = 2 1 ** 1 = 1 = 1 0 ** 1 = 0 = 0 -1 ** 1 = -1 = -1 -2 ** 1 = -2 = -2 -3 ** 1 = -3 = -3 -4 ** 1 = -4 = -4 4 ** 0 = 1 = 1 3 ** 0 = 1 = 1 2 ** 0 = 1 = 1 1 ** 0 = 1 = 1 0 ** 0 = 0 = 0 -1 ** 0 = 1 = 1 -2 ** 0 = 1 = 1 -3 ** 0 = 1 = 1 -4 ** 0 = 1 = 1 4 ** -1 = 0 = Inf 3 ** -1 = 0 = Inf 2 ** -1 = 0 = Inf 1 ** -1 = 1 = 1 0 ** -1 = 0 = 0 -1 ** -1 = 0 = NaN -2 ** -1 = 0 = NaN -3 ** -1 = 0 = NaN -4 ** -1 = 0 = NaN 4 ** -2 = 0 = Inf 3 ** -2 = 0 = Inf 2 ** -2 = 0 = Inf 1 ** -2 = 1 = 1 0 ** -2 = 0 = 0 -1 ** -2 = 0 = NaN -2 ** -2 = 0 = NaN -3 ** -2 = 0 = NaN -4 ** -2 = 0 = NaN 4 ** -3 = 0 = Inf 3 ** -3 = 0 = Inf 2 ** -3 = 0 = Inf 1 ** -3 = 1 = 1 0 ** -3 = 0 = 0 -1 ** -3 = 0 = NaN -2 ** -3 = 0 = NaN -3 ** -3 = 0 = NaN -4 ** -3 = 0 = NaN 4 ** -4 = 0 = Inf 3 ** -4 = 0 = Inf 2 ** -4 = 0 = Inf 1 ** -4 = 1 = 1 0 ** -4 = 0 = 0 -1 ** -4 = 0 = NaN -2 ** -4 = 0 = NaN -3 ** -4 = 0 = NaN -4 ** -4 = 0 = NaN V C S S i m u l a t i o n R e p o r t Time: 0 CPU Time: 0.040 seconds; Data structure size: 0.0Mb Thu May 8 12:29:43 2003 --------------480D76C05C8459E635332507-- From: Kurt Baty <kurt@wsfdb.wsfdb.com> To: etf-bugs@boyd.com Cc: kurt@wsfdb.wsfdb.com Subject: Re: errata/140 "**" as an integer trucated operator try2 Date: Mon, 19 May 2003 13:38:24 -0500 (CDT) >Category: errata >Confidential: no >Originator: Kurt Baty <kurt@wsfdb.wsfdb.com> >Release: 2001b >Submitter-Id: etf >Class: TBD >Description: Description The 3rd paragraph of Section 4.1.5 attempts to define the result type of the power operator. The following BTF thread discusses several issues with this definition. http://boydtechinc.com/btf/archive/btf_2002/1776.html Submitting for consideration by the ETF. Fix Part I: REPLACE (3rd paragraph of 4.1.5): 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. The result of the power operator is unspecified if the first operand is zero and the second operand is non-positive, or if the first operand is negative and the second operand is not an integral value. 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. 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. remove-> The result value is 1 if the first operand is zero. 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 1 0 1 int(op1 ** op2) op2 is even -> 1 zero 1 1 1 1 1 negative 0 op2 is odd -> -1 'bx 1 0 op2 is even -> 1 'bx ------------------------------------------------------------------------ Part II: REPLACE (Title of Table 15 in 4.1.5): Examples of modulus operators WITH (new Title of Table 15 in 4.1.5): Examples of modulus and power operators ------------------------------------------------------------------------ Part III: REPLACE (The sentence immediately prior to Table 15): Table 15 gives examples of modulus operations. WITH Table 15 gives examples of some modulus and power operations. ------------------------------------------------------------------------ Part IV: REPLACE (heading of first column in Table 15): Modulus expression WITH (new heading of first column in Table 15): Expression ------------------------------------------------------------------------ Part V: Append the following power operator examples to Table 15: Expression Result Comments 3**2 9 3*3 2**3 8 2*2*2, same result as 1<<3 2**0 1 By definition, and same result as 1<<0 2**-3'sb1 0 -3'sb1 treated as unsigned 7, same as 1<<-3'sb1 2.0**-3'sb1 0.5 -3'sb1 coerced to -1.0, giving real reciprocal 0**-1 'bx Integer division by zero is 'bx 9**0.5 3.0 Real square root 9.0**(1/2) 1.0 Integer division truncates exponent to zero -3.0**2.0 9.0 Defined, because real 2.0 is still integral value 2**(-3'so4/3'so2) 0 Exponent is -3'so2, = 1/4, Integer division truncates 0 ----- Begin Included Message ----- >From kurt Tue May 13 10:30:51 2003 Date: Tue, 13 May 2003 10:30:46 -0500 (CDT) >From: Kurt Baty <kurt> To: etf@boyd.com Subject: Re: errata/140 "**" as an integer trucated operator Cc: kurt OK how about this: integer x ** y results table in the form of the integer number plane | x values -> | -4 -3 -2 -1 0 1 2 3 4 y values -v | ----------------+------------------------------------------------------------------------------- | 4 | 256 81 16 1 0 1 16 81 256 | 3 | -64 -27 -8 -1 0 1 8 27 64 | 2 | 16 9 4 1 0 1 4 9 16 | 1 | -4 -3 -2 -1 0 1 2 3 4 | 0 | 1 1 1 1 1 1 1 1 1 | | -1/4 -1/3 -1/2 Inf 1/2 1/3 1/4 -1 | = 0 = 0 = 0 -1 = x 1 = 0 = 0 = 0 | | 1/16 1/9 1/4 Inf 1/4 1/9 1/16 -2 | = 0 = 0 = 0 1 = x 1 = 0 = 0 = 0 | | -1/64 -1/27 -1/8 Inf 1/8 1/27 1/64 -3 | = 0 = 0 = 0 -1 = x 1 = 0 = 0 = 0 | | 1/256 1/81 1/16 Inf 1/16 1/81 1/256 -4 | = 0 = 0 = 0 1 = x 1 = 0 = 0 = 0 | or going up the x = 4 column ... 1/256 1/64 1/16 1/4 1 4 16 64 256 = 0 = 0 = 0 = 0 or: x ** y where x, y are integers: x is negative zero positive --------------------------------------------------- y is positive int(x ** y) 0 int(x ** y) zero 1 1 1 negative x = -1 and x x = 1 -> 1 y is odd -> -1 else 0 x = -1 and y is even -> 1 else 0 two things not to like: 1) 0 ** 0 = 1 ? but: Summary of Algebraic Rules for Powers Rule for Multiplication: x ** n × x ** m = x ** (m+n) Rule for Division: x ** n ÷ x ** m = x ** (n-m) Rule for Raising a Power to a Power: (x ** n) ** m = x ** (n * m) Negative Exponents: A negative exponent indicates that the power is in the denominator: x ** -n = 1 / x ** n Identity Rule: Any nonzero number raised to the power of zero is equal to 1, x ** 0 = 1 (x not zero). where 0 ** 0 is explicit called out as not = 1 however: The discussion of 0^0 is very old. Euler argues for 0^0 = 1 since a^0 = 1 for a not equal to 0 . The controversy raged throughout the nineteenth century, but was mainly conducted in the pages of the lesser journals: Grunert's Archiv and Schlomilch's Zeitshrift. Consensus has recently been built around setting the value of 0^0 = 1 . read http://mathforum.org/dr.math/faq/faq.0.to.0.power.html 2) 0 ** negative = x ? If we follow the way verilog does the "/" for integers then 1 / 0 = x feedback? kurt ----- Begin Included Message ----- >From kurt Tue May 13 08:26:19 2003 Date: Tue, 13 May 2003 08:26:18 -0500 (CDT) >From: Kurt Baty <kurt> To: etf@boyd.com Subject: Re: errata/140 and errata/192: real values vs integer values Cc: kurt, Shalom.Bresticker@motorola.com > From Shalom.Bresticker@motorola.com Tue May 13 08:09:55 2003 > I ran this in VCS. Results attached. some quick editing of the log files shows that the results are all in agreement for an integer "/" with trucation. should the integer results of "**" be as if the last step (in the negetive exponent cases) was an integer "/" with trucation? so that 2 ** -1 = 0 not 1? kurt wsfdb% diff vxl_results vcs_results 1c1 < VERILOG-XL 4.00.s003 log file created May 13, 2003 07:19:19 --- > Compiler version 6.2R10; Runtime version 6.2R10; May 13 16:13 2003 14c14 < 4 / 3 as int = 1 as real = 1 = 1.333333333333333 --- > 4 / 3 as int = 1 as real = 1 = 1.33333 16,17c16,17 < 2 / 3 as int = 0 as real = 1 = 0.6666666666666666 < 1 / 3 as int = 0 as real = 0 = 0.3333333333333333 --- > 2 / 3 as int = 0 as real = 1 = 0.666667 > 1 / 3 as int = 0 as real = 0 = 0.333333 19,20c19,20 < -1 / 3 as int = 0 as real = 0 = -0.3333333333333333 < -2 / 3 as int = 0 as real = -1 = -0.6666666666666666 --- > -1 / 3 as int = 0 as real = 0 = -0.333333 > -2 / 3 as int = 0 as real = -1 = -0.666667 22c22 < -4 / 3 as int = -1 as real = -1 = -1.333333333333333 --- > -4 / 3 as int = -1 as real = -1 = -1.33333 41,44c41,44 < 4 / 0 as int = x as real = 0 = Infinity < 3 / 0 as int = x as real = 0 = Infinity < 2 / 0 as int = x as real = 0 = Infinity < 1 / 0 as int = x as real = 0 = Infinity --- > 4 / 0 as int = x as real = 0 = Inf > 3 / 0 as int = x as real = 0 = Inf > 2 / 0 as int = x as real = 0 = Inf > 1 / 0 as int = x as real = 0 = Inf 46,49c46,49 < -1 / 0 as int = x as real = 0 = -Infinity < -2 / 0 as int = x as real = 0 = -Infinity < -3 / 0 as int = x as real = 0 = -Infinity < -4 / 0 as int = x as real = 0 = -Infinity --- > -1 / 0 as int = x as real = 0 = -Inf > -2 / 0 as int = x as real = 0 = -Inf > -3 / 0 as int = x as real = 0 = -Inf > -4 / 0 as int = x as real = 0 = -Inf 68c68 < 4 / -3 as int = -1 as real = -1 = -1.333333333333333 --- > 4 / -3 as int = -1 as real = -1 = -1.33333 70,71c70,71 < 2 / -3 as int = 0 as real = -1 = -0.6666666666666666 < 1 / -3 as int = 0 as real = 0 = -0.3333333333333333 --- > 2 / -3 as int = 0 as real = -1 = -0.666667 > 1 / -3 as int = 0 as real = 0 = -0.333333 73,74c73,74 < -1 / -3 as int = 0 as real = 0 = 0.3333333333333333 < -2 / -3 as int = 0 as real = 1 = 0.6666666666666666 --- > -1 / -3 as int = 0 as real = 0 = 0.333333 > -2 / -3 as int = 0 as real = 1 = 0.666667 76c76 < -4 / -3 as int = 1 as real = 1 = 1.333333333333333 --- > -4 / -3 as int = 1 as real = 1 = 1.33333 86c86 < End of VERILOG-XL 4.00.s003 May 13, 2003 07:19:21 --- > V C S S i m u l a t i o n R e p o r t wsfdb% ----- End Included Message ----- ----- Begin Included Message ----- >From kurt Tue May 13 07:36:27 2003 Date: Tue, 13 May 2003 07:36:26 -0500 (CDT) >From: Kurt Baty <kurt> To: etf@boyd.com Subject: errata/140 and errata/192: real values vs integer values Cc: kurt I am wondering if the integer "/" in verilog should be a guide, the correct result in the "**" case? what is the group thinking? re: > If you applied this methodology to integer division, what result would > you get for 1 / 2? > if the real typed, answer = 0.5 and verilog converts real to integer by rounding then, 1 if integer division is truncated by definition then integer = truncate(real typed, answer) then 0 also: > 1. Make it inconsistent with all other operators in the Verilog language. so I rewrote the little test program: wsfdb% more ieee_etf_140_test.v module ieee_etf_140_test; `include "fphdl64_real_functions.inc" parameter limit = 4; integer x,y,answer,int_answer; real x_real,answer_real; reg [63:0] x_bits,answer_bits; initial begin x_real = 0.5; x = x_real; $display("x = %0d = x_real =",x,x_real); $display; for(y=limit;y>=-limit;y=y-1) begin for(x=limit;x>=-limit;x=x-1) begin x_real = x; // x_bits = $realtobits(x_real); // answer_bits = pow(x_bits,y); // answer_real = $bitstoreal(answer_bits); answer_real = x_real / y; int_answer = x / y; answer = answer_real; // $display("%0d ** %0d = %0d = ",x,y,answer,answer_real); $display("%0d / %0d as int = %0d as real = %0d = ",x,y,int_answer,answer,answer_real); end end end endmodule wsfdb% results: wsfdb% verilog ieee_etf_140_test.v VERILOG-XL 4.00.s003 May 13, 2003 07:19:19 Copyright (c) 1995 Cadence Design Systems, Inc. All Rights Reserved. Unpublished -- rights reserved under the copyright laws of the United States. Copyright (c) 1995 UNIX Systems Laboratories, Inc. Reproduced with Permission. THIS SOFTWARE AND ON-LINE DOCUMENTATION CONTAIN CONFIDENTIAL INFORMATION AND TRADE SECRETS OF CADENCE DESIGN SYSTEMS, INC. USE, DISCLOSURE, OR REPRODUCTION IS PROHIBITED WITHOUT THE PRIOR EXPRESS WRITTEN PERMISSION OF CADENCE DESIGN SYSTEMS, INC. RESTRICTED RIGHTS LEGEND Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 or subparagraphs (c)(1) and (2) of Commercial Computer Software -- Restricted Rights at 48 CFR 52.227-19, as applicable. Cadence Design Systems, Inc. 555 River Oaks Parkway San Jose, California 95134 For technical assistance please contact the Cadence Response Center at 1-877-CDS-4911 or send email to support@cadence.com For more information on Cadence's Verilog-XL product line send email to talkv@cadence.com Compiling source file "ieee_etf_140_test.v" Compiling included source file "fphdl64_real_functions.inc" Compiling included source file "fphdl64_real_functions_base.inc" Continuing compilation of source file "fphdl64_real_functions.inc" Continuing compilation of source file "ieee_etf_140_test.v" Highest level modules: ieee_etf_140_test x = 1 = x_real =0.5 4 / 4 as int = 1 as real = 1 = 1 3 / 4 as int = 0 as real = 1 = 0.75 2 / 4 as int = 0 as real = 1 = 0.5 1 / 4 as int = 0 as real = 0 = 0.25 0 / 4 as int = 0 as real = 0 = 0 -1 / 4 as int = 0 as real = 0 = -0.25 -2 / 4 as int = 0 as real = -1 = -0.5 -3 / 4 as int = 0 as real = -1 = -0.75 -4 / 4 as int = -1 as real = -1 = -1 4 / 3 as int = 1 as real = 1 = 1.333333333333333 3 / 3 as int = 1 as real = 1 = 1 2 / 3 as int = 0 as real = 1 = 0.6666666666666666 1 / 3 as int = 0 as real = 0 = 0.3333333333333333 0 / 3 as int = 0 as real = 0 = 0 -1 / 3 as int = 0 as real = 0 = -0.3333333333333333 -2 / 3 as int = 0 as real = -1 = -0.6666666666666666 -3 / 3 as int = -1 as real = -1 = -1 -4 / 3 as int = -1 as real = -1 = -1.333333333333333 4 / 2 as int = 2 as real = 2 = 2 3 / 2 as int = 1 as real = 2 = 1.5 2 / 2 as int = 1 as real = 1 = 1 1 / 2 as int = 0 as real = 1 = 0.5 0 / 2 as int = 0 as real = 0 = 0 -1 / 2 as int = 0 as real = -1 = -0.5 -2 / 2 as int = -1 as real = -1 = -1 -3 / 2 as int = -1 as real = -2 = -1.5 -4 / 2 as int = -2 as real = -2 = -2 4 / 1 as int = 4 as real = 4 = 4 3 / 1 as int = 3 as real = 3 = 3 2 / 1 as int = 2 as real = 2 = 2 1 / 1 as int = 1 as real = 1 = 1 0 / 1 as int = 0 as real = 0 = 0 -1 / 1 as int = -1 as real = -1 = -1 -2 / 1 as int = -2 as real = -2 = -2 -3 / 1 as int = -3 as real = -3 = -3 -4 / 1 as int = -4 as real = -4 = -4 4 / 0 as int = x as real = 0 = Infinity 3 / 0 as int = x as real = 0 = Infinity 2 / 0 as int = x as real = 0 = Infinity 1 / 0 as int = x as real = 0 = Infinity 0 / 0 as int = x as real = 0 = NaN -1 / 0 as int = x as real = 0 = -Infinity -2 / 0 as int = x as real = 0 = -Infinity -3 / 0 as int = x as real = 0 = -Infinity -4 / 0 as int = x as real = 0 = -Infinity 4 / -1 as int = -4 as real = -4 = -4 3 / -1 as int = -3 as real = -3 = -3 2 / -1 as int = -2 as real = -2 = -2 1 / -1 as int = -1 as real = -1 = -1 0 / -1 as int = 0 as real = 0 = -0 -1 / -1 as int = 1 as real = 1 = 1 -2 / -1 as int = 2 as real = 2 = 2 -3 / -1 as int = 3 as real = 3 = 3 -4 / -1 as int = 4 as real = 4 = 4 4 / -2 as int = -2 as real = -2 = -2 3 / -2 as int = -1 as real = -2 = -1.5 2 / -2 as int = -1 as real = -1 = -1 1 / -2 as int = 0 as real = -1 = -0.5 0 / -2 as int = 0 as real = 0 = -0 -1 / -2 as int = 0 as real = 1 = 0.5 -2 / -2 as int = 1 as real = 1 = 1 -3 / -2 as int = 1 as real = 2 = 1.5 -4 / -2 as int = 2 as real = 2 = 2 4 / -3 as int = -1 as real = -1 = -1.333333333333333 3 / -3 as int = -1 as real = -1 = -1 2 / -3 as int = 0 as real = -1 = -0.6666666666666666 1 / -3 as int = 0 as real = 0 = -0.3333333333333333 0 / -3 as int = 0 as real = 0 = -0 -1 / -3 as int = 0 as real = 0 = 0.3333333333333333 -2 / -3 as int = 0 as real = 1 = 0.6666666666666666 -3 / -3 as int = 1 as real = 1 = 1 -4 / -3 as int = 1 as real = 1 = 1.333333333333333 4 / -4 as int = -1 as real = -1 = -1 3 / -4 as int = 0 as real = -1 = -0.75 2 / -4 as int = 0 as real = -1 = -0.5 1 / -4 as int = 0 as real = 0 = -0.25 0 / -4 as int = 0 as real = 0 = -0 -1 / -4 as int = 0 as real = 0 = 0.25 -2 / -4 as int = 0 as real = 1 = 0.5 -3 / -4 as int = 0 as real = 1 = 0.75 -4 / -4 as int = 1 as real = 1 = 1 0 simulation events (use +profile or +listcounts option to count) CPU time: 0.3 secs to compile + 0.2 secs to link + 0.1 secs in simulation End of VERILOG-XL 4.00.s003 May 13, 2003 07:19:21 wsfdb% > >From: Steven Sharp <sharp@cadence.com> > > The advantage of allowing real values for ranges is that it allows the > > power operator to always return a real, which simplifies implementation. > > I suppose that making the power operator always return a real might save > some time for a few simulator implementors. It is hardly a convincing > argument. We could make the same argument about eliminating integer > addition, subtraction, multiplication, division and comparison operations, > and just producing reals for those too. I don't think users would be > happy about that. > > Making the power operator produce reals from integer inputs would > 1. Make it inconsistent with all other operators in the Verilog language. > 2. Make it impossible to get a correct value for integral results larger > than 56 bits. > 3. Call for the use of expensive floating point operations instead of > cheaper integer operations. > 4. Make synthesis of any expression with a power operator problematic. > > Steven Sharp > sharp@cadence.com > > From drm@xilinx.com Mon May 5 14:04:03 2003 > Date: Mon, 05 May 2003 13:11:00 -0600 > From: Dennis Marsa <drm@xilinx.com> > X-Accept-Language: en > MIME-Version: 1.0 > To: Kurt Baty <kurt@wsfdb.wsfdb.com> > Cc: etf@boyd.com > Subject: Re: 1364 issue 140 and negative exponents > Content-Transfer-Encoding: 7bit > X-BigFish: v > > Kurt Baty wrote: > > > > Precedence: bulk > > > > > From drm@xilinx.com Mon May 5 13:41:55 2003 > > > > > > > 2 ** -1 = 1 = 0.5 > > > > -2 ** -1 = -1 = -0.5 > > > > > > > please note that: > > > > initial > > begin > > x_real = 0.5; > > x = x_real; > > $display("x = %0d = x_real =",x,x_real); > > $display; > > for(y=limit;y>=-limit;y=y-1) begin > > > > displays: > > > > Highest level modules: > > ieee_etf_140_test > > > > x = 1 = x_real =0.5 > > I am not sure what you are trying to convey with that > first $display statement before the main loop in your > test program. > > Are you trying to show that reals are being rounded > to nearest as opposed to being rounded towards zero? > > I had figured the results > > 2 ** -1 = 1 > -2 ** -1 = -1 > > were a result of rounding to nearest. > > But, my specific question is, are these the results you are > advocating for these particular operands? > > >From James' email today and from the discussion this morning, I had > thought the desired results would be: > > 2 ** -1 = 0 > -2 ** -1 = 0 > > Dennis > > > From kurt Mon May 5 14:55:03 2003 > Date: Mon, 5 May 2003 14:55:02 -0500 (CDT) > From: Kurt Baty <kurt> > To: drm@xilinx.com > Subject: Re: 1364 issue 140 and negative exponents > Cc: kurt > > > I am not sure what you are trying to convey with that > > first $display statement before the main loop in your > > test program. > > Yes, I to noticed the > > > 2 ** -1 = 1 > > -2 ** -1 = -1 > > rounding cases so the extra display statement shows that > verilog-XL does in fact round the real value 0.5 > to the integer value 1 > > > > > Are you trying to show that reals are being rounded > > to nearest as opposed to being rounded towards zero? > > > > I had figured the results > > > > 2 ** -1 = 1 > > -2 ** -1 = -1 > > > > were a result of rounding to nearest. > > > > Actually, this rounding is not "round nearest" > this is "round up" (I say "round away-from-zero" > so as to not be confused in negative numbers). > 0.5 would round to 0 in "round nearest". > > > But, my specific question is, are these the results you are > > advocating for these particular operands? > > yes, to took x ** y where x,y are integers and converted > x (integer -> real -> bits(ieee 64 floating point)) > > did a x_bits ** y using the pow function > > function [63:0] pow; // l**r, where l is fp64 and r is integer > > converted answer_bits (bits(ieee 64 floating point) -> real -> integer) > > and I make the claim that this is the most "math correct answer". > > > > > >From James' email today and from the discussion this morning, I had > > thought the desired results would be: > > > > 2 ** -1 = 0 > > -2 ** -1 = 0 > > > > I too was taken in!! (fished-in?!) > > kurt > > > > Kurt Baty wrote: > > > > > > Precedence: bulk > > > > > > > From drm@xilinx.com Mon May 5 13:41:55 2003 > > > > > > > > > 2 ** -1 = 1 = 0.5 > > > > > -2 ** -1 = -1 = -0.5 > > > > > > > > > > please note that: > > > > > > initial > > > begin > > > x_real = 0.5; > > > x = x_real; > > > $display("x = %0d = x_real =",x,x_real); > > > $display; > > > for(y=limit;y>=-limit;y=y-1) begin > > > > > > displays: > > > > > > Highest level modules: > > > ieee_etf_140_test > > > > > > From owner-etf@boyd.com Mon May 5 15:12:57 2003 > X-Authentication-Warning: max.boyd.com: majordomo set sender to owner-etf@boyd.com using -f > Date: Mon, 5 May 2003 15:12:02 -0500 (CDT) > From: Kurt Baty <kurt@wsfdb.wsfdb.com> > To: etf@boyd.com > Subject: Re: 1364 issue 140 and negative exponents > Cc: kurt@wsfdb.wsfdb.com > > Precedence: bulk > > x ** y where x, y are integers: > > x is positive zero negative > --------------------------------------------------- > y is > > positive x ** y 0 x ** y > > zero 1 0 1 > > negative x = 1 -> 1 0 x = -1 and > x = 2 and y is odd -> -1 > y = -1 -> 1 x = -1 and > else 0 y is even -> 1 > x = -2 and > y = -1 -> -1 > else 0 > > > maybe someone could run the same thing in C, > and maybe VCS also? > > > kurt > > > > From drm@xilinx.com Mon May 5 15:36:01 2003 > Date: Mon, 05 May 2003 14:43:07 -0600 > From: Dennis Marsa <drm@xilinx.com> > X-Accept-Language: en > MIME-Version: 1.0 > To: Kurt Baty <kurt@wsfdb.wsfdb.com> > Cc: etf@boyd.com > Subject: Re: 1364 issue 140 and negative exponents > Content-Transfer-Encoding: 7bit > X-BigFish: v > > Kurt Baty wrote: > > > > > I had figured the results > > > > > > 2 ** -1 = 1 > > > -2 ** -1 = -1 > > > > > > were a result of rounding to nearest. > > > > > > > Actually, this rounding is not "round nearest" > > this is "round up" (I say "round away-from-zero" > > so as to not be confused in negative numbers). > > 0.5 would round to 0 in "round nearest". > > Then I'm confused. If the rounding was "away from zero", > then wouldn't all of the combinations whose real result > is in the range (0.0,1.0) round to an integer result of 1, > and likewise results in the range (-1.0,0.0) would round to > a integer result of -1? Your test program results don't > indicate this. > > In case it isn't already obvious, I am not a floating point > expert. > > > > But, my specific question is, are these the results you are > > > advocating for these particular operands? > > > > yes, to took x ** y where x,y are integers and converted > > x (integer -> real -> bits(ieee 64 floating point)) > > > > did a x_bits ** y using the pow function > > > > function [63:0] pow; // l**r, where l is fp64 and r is integer > > > > converted answer_bits (bits(ieee 64 floating point) -> real -> integer) > > > > and I make the claim that this is the most "math correct answer". > > If you applied this methodology to integer division, what result would > you get for 1 / 2? > > Dennis > > > From kurt Mon May 5 16:01:57 2003 > Date: Mon, 5 May 2003 16:01:56 -0500 (CDT) > From: Kurt Baty <kurt> > To: etf@boyd.com > Subject: Re: 1364 issue 140 and negative exponents > Cc: kurt > > > > > > > > I had figured the results > > > > > > > > 2 ** -1 = 1 > > > > -2 ** -1 = -1 > > > > > > > > were a result of rounding to nearest. > > > > > > > > > > Actually, this rounding is not "round nearest" > > > this is "round up" (I say "round away-from-zero" > > > so as to not be confused in negative numbers). > > > 0.5 would round to 0 in "round nearest". > > > > Then I'm confused. If the rounding was "away from zero", > > then wouldn't all of the combinations whose real result > > is in the range (0.0,1.0) round to an integer result of 1, > > and likewise results in the range (-1.0,0.0) would round to > > a integer result of -1? Your test program results don't > > indicate this. > > some functions: > > truncate -> real result in the range (0.0 <= fract < 1.0) > goes to 0 > ceiling -> real result in the range (0.0 < fract <= 1.0) > goes to 1 > round -> real result in the range (0.0 < fract < 0.50) > goes to 0 > real result in the range (0.5 < fract <= 1.0) > goes to 1 > real result is exactly (fract = 0.5) > case(rounding mode) > up: goes to 1 (round "away from zero") > down: goes to 0 (round "towards zero") > nearest: if(low bit of abs(integer) part is: > zero: goes to 0 > one: goes to 1 > > does this help? > > > > > In case it isn't already obvious, I am not a floating point > > expert. > > I must be. > > > > > > > But, my specific question is, are these the results you are > > > > advocating for these particular operands? > > > > > > yes, to took x ** y where x,y are integers and converted > > > x (integer -> real -> bits(ieee 64 floating point)) > > > > > > did a x_bits ** y using the pow function > > > > > > function [63:0] pow; // l**r, where l is fp64 and r is integer > > > > > > converted answer_bits (bits(ieee 64 floating point) -> real -> integer) > > > > > > and I make the claim that this is the most "math correct answer". > > > > If you applied this methodology to integer division, what result would > > you get for 1 / 2? > > > > if the real typed, answer = 0.5 > and verilog converts real to integer by rounding then, 1 > > if integer division is truncated by definition then > integer = truncate(real typed, answer) then 0 > > > kurt > > > > From kurt Mon May 5 16:32:47 2003 > Date: Mon, 5 May 2003 16:32:46 -0500 (CDT) > From: Kurt Baty <kurt> > To: etf@boyd.com > Subject: Re: 1364 issue 140 and negative exponents > Cc: kurt > > > > > > > In case it isn't already obvious, I am not a floating point > > > expert. > > > > I must be. > > > In 1997 I was luck enough to hear Dr. Leo Mildenberg talk at Havard University > he was billed as the "world's greatest expert on ancient greek coins". > In the Q&A at the end of his talk, he was asked how he got to be > the "world's greatest expert", his answer was "All the real experts have died!" > Dr. Mildenberg passed away in 2001. > > He may have figured out where all experts come from! > > > kurt > > > ----- End Included Message ----- ----- End Included Message ----- ----- End Included Message ----- From: Steven Sharp <sharp@cadence.com> To: etf-bugs@boyd.com, drm@xilinx.com Cc: Subject: Re: errata/140: Section 4.1.5: Definition of power operator result type Date: Fri, 23 May 2003 17:14:52 -0400 (EDT) > 2**(-3'so4/3'so2) 0 Exponent is -2, Integer division truncates to zero This line in the revised example is now confusing. The reference to integer division will be misunderstood to mean the actual division operation in the example, but that division doesn't truncate to zero. It is not apparent that it is talking about the effective division implied by the negative power. This line from the examples can probably be removed from this version of the proposal anyway. Shalom added it to show that having the power operator interpret the exponent bits as an unsigned value did not change the actual type of the expression. This is not relevant to this version of the proposal. Steven Sharp sharp@cadence.com From: Kurt Baty <kurt@wsfdb.wsfdb.com> To: etf-bugs@boyd.com Cc: kurt@wsfdb.wsfdb.com, sharp@cadence.com Subject: Re: errata/140: Section 4.1.5: Definition of power operator result type Date: Sun, 25 May 2003 09:44:30 -0500 (CDT) > >From: Steven Sharp <sharp@cadence.com> > To: etf-bugs@boyd.com, drm@xilinx.com > Cc: > Subject: Re: errata/140: Section 4.1.5: Definition of power operator result type > Date: Fri, 23 May 2003 17:14:52 -0400 (EDT) > > > 2**(-3'so4/3'so2) 0 Exponent is -2, Integer division truncates > to zero > > This line in the revised example is now confusing. The reference to integer > division will be misunderstood to mean the actual division operation in the > example, but that division doesn't truncate to zero. It is not apparent > that it is talking about the effective division implied by the negative > power. > > This line from the examples can probably be removed from this version of > the proposal anyway. Shalom added it to show that having the power operator > interpret the exponent bits as an unsigned value did not change the actual > type of the expression. This is not relevant to this version of the proposal. > OK I agree that "This line in the revised example is now confusing." so I will remove it. however I would below this line: 2.0**-3'sb1 0.5 -3'sb1 coerced to -1.0, giving real reciprocal add: 2**-3'sb1 0 non-real case and less than one reciprocal truncates to zero (I am not totally happy with this wording ^^^^^^ ) to clearly show that the 0.5(s) are not rounded up. thanks kurt From: Shalom.Bresticker@motorola.com To: Kurt Baty <kurt@wsfdb.wsfdb.com> Cc: etf-bugs@boyd.com Subject: Re: errata/140: Section 4.1.5: Definition of power operator result type Date: Sun, 25 May 2003 21:08:09 +0300 (IDT) > 2**-3'sb1 0 non-real case and less than one reciprocal truncates to zero > > (I am not totally happy with this wording ^^^^^^ ) How about simply, "Non-real reciprocal. Truncates to 0"? From: "James A. Markevitch" <jam@magic.com> To: etf-bugs@boyd.com, kurt@wsfdb.wsfdb.com Cc: Subject: Re: errata/140: Section 4.1.5: Definition of power operator result type Date: Sun, 25 May 2003 15:02:10 -0700 (PDT) > 2**-3'sb1 0 non-real case and less than one reciprocal truncates to zero > > (I am not totally happy with this wording ^^^^^^ ) > > to clearly show that the 0.5(s) are not rounded up. How about some alternate wording: non-real case always truncates result toward 0 James Markevitch From: Shalom.Bresticker@motorola.com To: "James A. Markevitch" <jam@magic.com> Cc: etf-bugs@boyd.com Subject: Re: errata/140: Section 4.1.5: Definition of power operator result type Date: Mon, 26 May 2003 05:46:36 +0300 (IDT) > How about some alternate wording: > non-real case always truncates result toward 0 But that is misleading for base = 1 or -1. From: "James A. Markevitch" <jam@magic.com> To: etf-bugs@boyd.com, Shalom.Bresticker@motorola.com Cc: Subject: Re: errata/140: Section 4.1.5: Definition of power operator result type Date: Mon, 26 May 2003 06:48:35 -0700 (PDT) > > 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 James Markevitch From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: etf-bugs@boyd.com Cc: Subject: Re: errata/140: PROPOSAL - Section 4.1.5: Definition of power operator result type Date: Mon, 26 May 2003 16:55:34 +0300 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. > 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. -- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 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 From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: Kurt Baty <kurt@wsfdb.wsfdb.com> Cc: etf-bugs@boyd.com Subject: Re: errata/140: Section 4.1.5: Definition of power operator result type Date: Tue, 27 May 2003 13:07:39 +0300 > I like: > > non-real case truncates all fractions toward 0 OK > > > 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 by 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. Then you should say it is "undefined", as in the previous proposal: "The result value is undefined if the first operand is zero and the second operand is non-positive, or if the first operand is negative and the second operand is not an integral value." > op1 is negative<-1 -1 zero 1 positive>1 > -------------------------------------------------------------------------- > op2 is > positive op1 ** op2 op2 is odd -> -1 0 1 op1 ** op2 OK. From: Shalom.Bresticker@motorola.com To: Kurt Baty <kurt@wsfdb.wsfdb.com> Cc: etf-bugs@boyd.com, 1364@accellera.org Subject: Re: errata/140: PROPOSAL - Section 4.1.5: Definition of power operator result type Date: Thu, 18 Dec 2003 10:47:46 +0200 (IST) I have a problem with the text of the first part of the changes for errata/140. In 4.1.5, the second paragraph, which precedes the discussion of the power operator, talks about the division and modulo operators. Then, currently, the third paragraph, starts with "The result of the power operator ...", which tells you that the subject is now the power operator. In the passed changes, the third paragraph will now begin, "In all cases the second operand shall be treated as self-determined." There will be no indication that it is talking about the power operator. Please revise the text. Thanks, Shalom On Mon, 14 Jul 2003, Kurt Baty wrote: > Part I: > > > REPLACE (3rd paragraph of 4.1.5): > 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. The result of the power operator is > unspecified if the first operand is zero and the second operand is > non-positive, or if the first operand is negative and the second > operand is not an integral value. > > > WITH (new 3rd and 4th paragraphs of 4.1.5): > In all cases the second operand shall be treated as self-determined. > If either operand of the power operator is real then: > The result type shall be real. The result of the power operator is > unspecified if the first operand is zero and the second operand is > non-positive, or if the first operand is negative and the second > operand is not an integral value. > 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 > 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. -- Shalom Bresticker Shalom.Bresticker@motorola.com Design, Verification & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 From: Shalom.Bresticker@motorola.com To: Kurt Baty <kurt@wsfdb.wsfdb.com> Cc: etf-bugs@boyd.com, 1364@accellera.org Subject: Re: errata/140: PROPOSAL - Section 4.1.5: Definition of power operator result type Date: Thu, 1 Jan 2004 15:28:33 +0200 (IST) What I have done with with this is to move the first sentence, "In all cases the second operand shall be treated as self-determined." to after the following paragraphs, "If either operand of the power operator is real then:" and "If neither operand of the power operator is real then:" and before "These statements are illustrated in the following table." Shalom On Thu, 18 Dec 2003 Shalom.Bresticker@motorola.com wrote: > I have a problem with the text of the first part of the changes for errata/140. > > In 4.1.5, the second paragraph, which precedes the discussion of the power > operator, talks about the division and modulo operators. > > Then, currently, the third paragraph, starts with "The result of the power > operator ...", which tells you that the subject is now the power operator. > > In the passed changes, the third paragraph will now begin, > "In all cases the second operand shall be treated as self-determined." > There will be no indication that it is talking about the power operator. > > Please revise the text. > > Thanks, > Shalom > > > On Mon, 14 Jul 2003, Kurt Baty wrote: > > > Part I: > > > > > > REPLACE (3rd paragraph of 4.1.5): > > 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. The result of the power operator is > > unspecified if the first operand is zero and the second operand is > > non-positive, or if the first operand is negative and the second > > operand is not an integral value. > > > > > > WITH (new 3rd and 4th paragraphs of 4.1.5): > > In all cases the second operand shall be treated as self-determined. > > If either operand of the power operator is real then: > > The result type shall be real. The result of the power operator is > > unspecified if the first operand is zero and the second operand is > > non-positive, or if the first operand is negative and the second > > operand is not an integral value. > > 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 > > 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. > > -- Shalom Bresticker Shalom.Bresticker@motorola.com Design, Verification & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 |
| Unformatted |
|
Hosted by Boyd Technology