ISSUE 282

Number 282
Category errata
Synopsis 4.5: sign extension and bit-length rules not clear enough
State lrmdraft
Class errata-discuss
Arrival-DateFeb 02 2003
Originator harry@verplex.com
Release 2001b: 4.5
Environment
Description
I am entering this into the ETF database because I did not
find an existing issue which already covers this satisfactorily.

It seems that the existing text needs to be substantially
reworked.

My understanding is that interpretation #2 is correct.
The LRM says that if any operand is unsigned, they all
become unsigned, according to 4.5.2(3). Furthermore, they
are all extended to the width of the largest operand, which
in this case is Z (by 4.5.2(4).
Only then does evaluation begin.

However, if such major tools differ in their interpretation,
it is a "sign" that the text is not clear enough.

Shalom

Fix
Proposal for expression signedness and sizing issues

Commentary:

This is a stab at clarifying the description of how context-determined
signedness and expression sizing works (a variety of errata). It also
covers how reals work (erratum 83), and the special behavior of compares.
It may not be adequate to resolve the issues, but it is an attempt. It
was done in a hurry, so there may be problems with it. Insert more
disclaimers here.

The new text refers to a "primary" from the grammar. For some reason,
"primary" does not include a string. Instead, strings are listed separately
as expressions. This is apparently an error in the grammar, since it
prevents the use of unary operators on strings, which should be legal. The
new text assumes that this will be fixed; otherwise it needs to say
"primary or string".

Changes:

In 4.5.2, CHANGE:

-- Coerce the type of each operand of the expression (excepting those which
are self-determined) to the type of the expression.
-- Extend the size of each operand (excepting those which are self-determined)
to the size of the expression. Perform sign extension if and only if the
operand type (after type coercion) is signed.

TO:

-- Propagate the type and size of the expression (or self-determined sub-
expression) back down to the context-determined operands of the expression.
In general, any context-determined operand of an operator is the same
type and size as the result of the operator. However, there are two
exceptions:
- If the result type of the operator is real, and it has a context-
determined operand that is not real, that operand is treated as if
it were self-determined and then converted to real just before the
operator is applied.
- The relational and equality operators have operands that are neither
fully self-determined nor fully context-determined. The operands affect
each other as if they were context-determined operands with a result
type and size (maximum of the two operand sizes) determined from them.
However, the actual result type is always 1 bit unsigned. The type
and size of the operands is independent of the rest of the expression
and vice-versa.
-- When propagation reaches a simple operand as defined in 4.2 (a primary
as defined in A.8.4), then that operand is converted to the propagated
type and size. If the operand must be extended, then it is sign-extended
only if the propagated type is signed.
Audit-Trail
From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: etf-bugs@boyd.com
Cc: harry@verplex.com, krolnik@lsil.com, cclin@verplex.com
Subject: Re: errata/282: 4.5: sign extension and bit-length rules not clear
enough
Date: Sun, 02 Feb 2003 16:14:19 +0200

Aarghh!
The darned software cut off the quoted email I was replying to!

Here it is again:

>From: "Harry Foster" <harry@verplex.com>
>To: <stuart@sutherland-hdl.com>, <cliffc@sunburst-design.com>,
> "Adam Krolnik" <krolnik@lsil.com>, <mac@verisity.com>
>Cc: "Andy Lin" <cclin@verplex.com>
>Subject: Tool inconsistencies in implementing Verilog 2001 sign

extension
>in the context of unsigned assignments
>Date: Wed, 29 Jan 2003 15:17:23 -0600
>
>Hi Guys,
>
>You are all experts in the Verilog 2001 standard, and I need
help
>understanding some inconsistencies we have observed across
multiple tools
>related to the implementation of sign extension in the context
of
unsigned
>assignment?
>
>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)"
>
>Related info in Verilog 2001 LRM, section 4.5:
> - 4.5.1 Rules for expression types:
> For non-self-determined operands the following rules apply:
> 1. if any operand is real, the result is real.
> 2. if any operand is unsigned, the result is unsigned,
regardless the
>operator;
> 3. if all operands are signed, the result will be signed,
regardless of
>operator,
> except as noted.
>
> - 4.5.2 Steps for evaluating an expression
> 1. Determine the expression size based upon the standard rules

of
>expression
> size determination.
> 2. Determine the sign of the expression using the rules
outlined
in
>Section 4.5.1
> 3. Coerce the type of each operand of the expression
(excepting
those
>which
> are self-determined) to the type of the expression.
> 4. Extend the size of each operand (excepting those which are
>self-determined)
> to the size of the expression. Perform sign extension if and
only if
>the
> operand type (after type coercion) is signed.
>
>FYI, here are the various tool results we have observed:
>
> - Design Compiler
> DC performs D = $signed(A)*$signed(B) first,
> then truncates it to C's size, denoted as value E,
> then assigns to Z: Z = $unsigned(E) + $unsigned(C);
> DC's result is different from all other tools.
>
> - Verilog-XL, Ncverilog, Ambit BuildGates
> The Ambit has the same result as Verilog-XL and Ncverilog.
> the tools do D = $unsigned(A)*$unsigned(B) first,
> then the assignment Z = $unsigned(D) + $unsigned(C);
>
> - VCS, Synplify_asic, Conformal LEC
> synplify_asic gets the same result as VCS and LEC
> The tools do D = $signed(A)*$signed(B) first,
> then the assignment Z = $signed(D) + $unsigned(C);
>
>Any help in clarifying the standard would be welcomed.
>
>Thanks,
>
>-Harry

Shalom Bresticker wrote:

> Precedence: bulk
>
> >Number: 282
> >Category: errata
> >Originator: harry@verplex.com
> >Environment:
>
> >Description:
>
> I am entering this into the ETF database because I did not
> find an existing issue which already covers this satisfactorily.
>
> It seems that the existing text needs to be substantially
> reworked.
>
> My understanding is that interpretation #2 is correct.
> The LRM says that if any operand is unsigned, they all
> become unsigned, according to 4.5.2(3). Furthermore, they
> are all extended to the width of the largest operand, which
> in this case is Z (by 4.5.2(4).
> Only then does evaluation begin.
>
> However, if such major tools differ in their interpretation,
> it is a "sign" that the text is not clear enough.
>
> Shalom

--
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: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com
Cc: harry@verplex.com, krolnik@lsil.com, cclin@verplex.com
Subject: Re: errata/282: 4.5: sign extension and bit-length rules not clear enough
Date: Mon, 3 Feb 2003 23:28:12 -0500 (EST)

>Date: Sun, 2 Feb 2003 06:20:01 -0800
>To: etf-bugs@boyd.com
>From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
>Subject: Re: errata/282: 4.5: sign extension and bit-length rules not clear
enough

I must agree that the rules are very unclear in the text. There is not a
clear distinction between two possible meanings of the term "operand". In
common usage, there are operands of an operator (e.g. the two operands of a
binary operator), which may themselves be expressions. And then there are
operands as defined in the LRM in 4.2, which refers only to the lowest
leaf-level operands such as nets, variables, parameters, literals,
bit-selects, part-selects, array words and function calls.

Generally, the definition in 4.2 is meant, but sometimes there are lapses.
For example, there are references to self-determined operands (of an
operator) which are actually self-determined expressions. Some expressions
are effectively treated like leaf operands by expressions that include them.

4.5.2 refers to the operands of the expression as in 4.2, not to operands
of a particular operator. So when it says that the type of each operand is
coerced to the type of the expression, that means all of the operands in
the expression. Then when it says that the size of each operand is extended
to the size of the expression, that also means all of the operands in the
expression. All this takes place before the actual evaluation of the
expression occurs (which really should be listed as a last step in 4.5.2,
just as assigning the value should be listed as a last step in 4.5.3).

For size extension, this is clarified by statements elsewhere. For example,
the first sentence in 4.4.2 states "During the evaluation of an expression,
interim results shall take the size of the largest operand (in case of an
assignment, this also includes the left-hand side)". This is a summary of
the result of 4.5.2. A similar summary for signedness would say that all
interim results are unsigned if any operand is unsigned.

Unfortunately, 4.5.2 would also convert all interim results to real if any
operand was real, and that isn't how Verilog actually works (and for good
reason). This adds to the confusion, but is a separate issue.

Another issue is the behavior of $signed() and $unsigned(). Based on the
behavior of Verilog-XL (which is where this signed arithmetic stuff came
from), they act differently from most system functions. Like any argument
of a system function, the type of the argument does not affect the type
of the function result and vice versa. However, the size is determined
differently from any other system function. Presumably to avoid loss of
bits in interim results during expression evaluation, the size of the
argument is considered context-determined rather than self-determined.

Note that if the system function result type doesn't match the rest of the
expression, the value is immediately coerced to the type of the expression
by the rules in 4.5.2 (a system function call is an operand, by 4.2). That
means that using $signed to convert something to signed is useless unless
everything else in the expression is signed too. The most powerful effect
of these functions is "shielding" the argument from the type of the
expression until it is converted, not the conversion itself.

The text in 4.5 implies that the sizes of the arguments to $signed() and
$unsigned() are self-determined. I'm not sure this would work much better,
but it would probably be easier to implement.

Based on all this, here are my specific comments on the testcase provided.

> > 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
> >
> >
> > (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)"

It should be very clear that this is wrong. As stated in 4.4.2, interim
results like D (and E) take the size of the largest operand, which is Z.
Truncating them to the size of C is wrong. Avoiding the loss of the
upper bits is exactly the reason for the Verilog size rules. See also
the note after Table 29, which says "NOTE Multiplication without losing
any overflow bits is still possible simply by assigning the result to
something wide enough to hold it."


> > (2) Perform "D = $unsigned(A)*$unsigned(B)" first,
> > then the assignment "Z = $unsigned(D) + $unsigned(C)"

Here is a more detailed description:

Since the right operand of the add (the $unsigned "call") is unsigned, the
entire expression is unsigned. Since the largest operand (including the
LHS of the assignment) is 10 bits, the size of the expression is 10 bits.
The arguments to $signed and $unsigned have sizes determined by context
to be 10 bits, but their signedness does not affect the signedness of the
expression and vice versa. Since operands A, B and C are not declared
signed, they are unsigned. That makes the argument types unsigned.

Operands A, B and C all get extended to the size of the expression (10 bits).
Since the operand types (after coercion) are unsigned, this will be a
zero-extension. Then A and B get converted to signed due to the effect
of $signed. The results of $signed (which are operands in the overall
expression) get coerced to the type of the overall expression, or unsigned.
Then they get multiplied, producing a 10-bit result for D. The result of
$unsigned(C) is already unsigned. The unsigned D gets added to it to get
the result.

If the arguments of $signed and $unsigned are considered to be completely
self-determined, the result would be the same. The arguments would not be
extended before the system functions were evaluated. The results of the
system functions would be operands of the overall expression, and would be
coerced to the unsigned type of the expression before being extended,
still resulting in zero-extension before the multiplication.

Note that if the desire was to do signed multiplication between A and B,
there are many ways to do it. The easiest way is to completely avoid
mixing in any unsigned quantities if you are trying to do signed arithmetic.
This avoids confusion.

1. Declare A, B and C signed and perform "Z = A * B + C;"

2. Declare A and B signed and perform "Z = A * B + $signed(C);"

Or use the "casts" for their "shielding effect" instead. It doesn't matter
which one you use for this.

3. Declare A and B signed and perform "Z = $unsigned(A*B) + C;"

4. Or declare A and B signed and perform "Z = $signed(A*B) + C;"

Note that it doesn't matter whether the addition is signed or unsigned.
It doesn't even matter whether the multiplication is signed or unsigned.
When the result of multiplication is the same width as the inputs (as in
all Verilog multiplies), there is no difference between signed and unsigned
multiplication. What gives the effect of a signed multiply is for A and B
to be sign-extended during the size extension.

If the size of the argument of $signed and $unsigned were self-determined,
as implied by the LRM, the given testcase would still not work. The
suggestions 1 and 2 above would still work. Suggestions 3 and 4 would not,
since the upper bits of the multiply would be lost. However, the expression
"Z = $signed(A) * $signed(B) + $signed(C);" would work in that case.


> > (3) Perform "D = $signed(A)*$signed(B)" first,
> > then the assignment "Z = $signed(D) + $unsigned(C)"

That is how the C language would do it, waiting until the signed values were
combined with the unsigned one before converting them to unsigned. However,
C can also lose bits from interim computations, by waiting until short values
are combined with longer ones before converting them to longer types. It
avoids some of this by converting all the short integer types up to int
immediately. The Verilog size rules preserve bits better, which is important
with hardware that may have limited bits. The Verilog signedness rules are
not pretty, but they match the size rules.

> >FYI, here are the various tool results we have observed:
> >
> > - Design Compiler
> > DC performs D = $signed(A)*$signed(B) first,
> > then truncates it to C's size, denoted as value E,
> > then assigns to Z: Z = $unsigned(E) + $unsigned(C);
> > DC's result is different from all other tools.

As noted above, this clearly violates the interim size rules.

> > - Verilog-XL, Ncverilog, Ambit BuildGates
> > The Ambit has the same result as Verilog-XL and Ncverilog.
> > the tools do D = $unsigned(A)*$unsigned(B) first,
> > then the assignment Z = $unsigned(D) + $unsigned(C);

The implementation in Verilog-XL predates Verilog-2001 and was the basis
for the proposal. NC-Verilog was based on the behavior of Verilog-XL, and
Ambit BuildGates was based on the behavior of NC-Verilog.

I assume that the chosen implementation was also backward-compatible with
the behavior of the signed integer type that already existed in Verilog-1995.


> > - VCS, Synplify_asic, Conformal LEC
> > synplify_asic gets the same result as VCS and LEC
> > The tools do D = $signed(A)*$signed(B) first,
> > then the assignment Z = $signed(D) + $unsigned(C);

These may be "descended" from the implementation in VCS, or independent
misinterpretations. There is probably a natural tendency for implementors
to assume it works like C and not look too closely at the LRM, especially
when it requires such careful reading to figure out.

This issue came up a few months ago, and several people from Synopsys are
now aware of it.

> >Any help in clarifying the standard would be welcomed.

I hope that this attempt has been helpful. We also need to modify the LRM
to make it clearer.

Steven Sharp
sharp@cadence.com


From: Shalom.Bresticker@motorola.com
To: Steven Sharp <sharp@cadence.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/282: 4.5: sign extension and bit-length rules not clear
enough
Date: Tue, 4 Feb 2003 21:44:38 +0200 (IST)

Steven,

I followed some, but not all of your explanation,
not because it was not clear, but simply because of the late hour.

Two small comments from what I did understand:

> That
> means that using $signed to convert something to signed is useless unless
> everything else in the expression is signed too. The most powerful effect
> of these functions is "shielding" the argument from the type of the
> expression until it is converted, not the conversion itself.

I think that both these statements are significant enough that they should be
stated explicitly.

> The text in 4.5 implies that the sizes of the arguments to $signed() and
> $unsigned() are self-determined. I'm not sure this would work much better,
> but it would probably be easier to implement.

I gather that there are two choices here (self-determined and
context-determined), and we have to choose one.

Shalom



From: Steven Sharp <sharp@cadence.com>
To: Cc: etf-bugs@boyd.com
Subject: Re: errata/282: 4.5: sign extension and bit-length rules not clear enough
Date: Tue, 4 Feb 2003 17:02:44 -0500 (EST)

>From: Shalom.Bresticker@motorola.com
>Date: Tue, 4 Feb 2003 21:44:38 +0200 (IST)
>
>Two small comments from what I did understand:
>
>> That
>> means that using $signed to convert something to signed is useless unless
>> everything else in the expression is signed too. The most powerful effect
>> of these functions is "shielding" the argument from the type of the
>> expression until it is converted, not the conversion itself.
>
>I think that both these statements are significant enough that they should be
>stated explicitly.

While they can be derived from the existing rules, the consequences do seem
to catch people by surprise.

The "shielding" effect is nothing different from what any self-determined
expression gets. For example, you can get the same effect as $unsigned(x)
by using {x}, since anything inside a concatenation is self-determined and
the result is always considered unsigned.

>> The text in 4.5 implies that the sizes of the arguments to $signed() and
>> $unsigned() are self-determined. I'm not sure this would work much better,
>> but it would probably be easier to implement.
>
>I gather that there are two choices here (self-determined and
>context-determined), and we have to choose one.

I was wrong about this part of the behavior of $signed and $unsigned in
Verilog-XL. I'm not sure where I got this idea. Both Verilog-XL and
NC-Verilog treat the argument of $signed and $unsigned as self-determined,
just as the LRM indicates (and like all other system functions). So there
is not an issue here. Sorry about confusing things further.

As noted in my earlier response, this does not affect the outcome in this
case. I believe that I described the details for this situation already,
but here is the essential piece again:

$signed(A) and $signed(B) are signed operands of the RHS expression.
$unsigned(C) is an unsigned operand of the RHS expression. Because there
is an unsigned operand, the RHS expression is unsigned by 4.5.1. Because
the expression is unsigned, all of its operands are coerced to unsigned by
4.5.2. This means that $signed(A) and $signed(B) are coerced to unsigned.
They get zero-extended to the size of the expression (10 bits) because their
type after coercion is unsigned, by 4.5.2. Then they get multiplied and
added.

To get signed multiplication, it is necessary to make sure that all of
the operands of the expression are signed, to prevent them from getting
converted to unsigned. This can be done with the declarations or with
explicit conversions. For example,

1. Declare A, B and C signed and perform "Z = A * B + C;"

2. Declare A and B signed and perform "Z = A * B + $signed(C);"

3. Convert everything to signed, "Z = $signed(A) * $signed(B) + $signed(C);"

Steven Sharp
sharp@cadence.com


From: Karen Pieper <Karen.Pieper@synopsys.com>
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/282
Date: Mon, 24 Mar 2003 13:50:57 -0800

>Category: errata
>Confidential: no
>Originator: Karen Pieper <Karen.Pieper@synopsys.com>
>Release: 2001b
>Class: TBD
>Description:
In addition to resolving the issue in this issue, the result of this issue
needs to also address the issues
in 96, 83, and 35.

Thanks,

K

From: Shalom.Bresticker@motorola.com
To: Alec Stanculescu <alec@fintronic.com>
Cc: harry@verplex.com, etf-bugs@boyd.com, btf-dtype@boyd.com
Subject: Re: errata/282: signing
Date: Fri, 30 Apr 2004 11:19:07 +0300 (IDT)

Alec,

Sorry, but you are mistaken on this.

As previously discussed, the correct interpretation is (2).

The word "expression" in 4.5.1 refers to the entire RHS.

Also as previously discussed, the LRM is unfortunately not clear enough.

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


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






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

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
>







From: Shalom.Bresticker@motorola.com
To: Alec Stanculescu <alec@fintronic.com>
Cc: etf-bugs@boyd.com, btf-dtype@boyd.com
Subject: Re: errata/282: signing
Date: Sat, 1 May 2004 22:13:19 +0300 (IDT)

> 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").

Alec,

Are you confusing between 4.1.5 and 4.5.1 ?

> 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.

You picked a bad example for several reasons.

One is that the text you quoted is from 1364-2001 Version B and is simply
incorrect. That was errata issue #140. The text was completely rewritten
and substantially changed.

The second reason is that, yes, the type of the first operand of the power
operator (i.e., the base) is affected by the other operands in the expression
in which it appears, i.e., it's bit-size and signedness.
(The second operand, the power, is self-determined, and not affected by other
operands.)

Thirdly, the text refers only to the two operands of this operator in order to
not complicate the text further by talking about additional operands.
Similarly, 4.1.7, for example, says that "When two operands of unequal bit
lengths are used ..., the smaller operand shall be zero filled ... to extend
to the size of the larger operand," and does not relate to other operands in
the larger expression. And the same is true of the other subsections of 4.1.

Shalom

From: Alec Stanculescu <alec@fintronic.com>
To: Shalom.Bresticker@motorola.com
Cc: etf-bugs@boyd.com, btf-dtype@boyd.com
Subject: Re: errata/282: signing
Date: Sun, 2 May 2004 22:01:26 -0700

> > 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").
>
> Alec,
>
> Are you confusing between 4.1.5 and 4.5.1 ?
>
The answer is NO. However, I do understand why you may be confused
by 4.1.5 and 4.5.1. It is because in breaking with an important
rule of how to write the LRM, writing the fix of errata 140 has
introduced a forward reference in 4.1.5 to 4.5.1.

Most forward references should be considered errata and
eliminated. That would make for a much better LRM.

> > 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.
>
> You picked a bad example for several reasons.
>
The wordings of 4.1.5 in "version B" clearly showed the intention of
the LRM to determine the type of the expression that uses the power
operator as depending only on it's two operands.

Given that this is one of the few places where the LRM showed it's intention
one way or the other regarding whether "expression" in 4.5.1 means
the entire ensemble of subexpressions, or just an expression having
one operator, makes the "original wording of the LRM" extremely
relevant. Basically, in fixing issue 140 the writer
of the LRM has erased one instance of the clear intent of the LRM with
respect to what "expression" means in 4.5.1. Also, the fix of errata 140,
is flowed in that it introduced a forward reference in 4.1.5 to 4.5.1.
Each forward reference in the LRM is basically an errata in itself!

> One is that the text you quoted is from 1364-2001 Version B and is simply
> incorrect. That was errata issue #140. The text was completely rewritten
> and substantially changed.
>
> The second reason is that, yes, the type of the first operand of the power
> operator (i.e., the base) is affected by the other operands in the
> expression
> in which it appears, i.e., it's bit-size and signedness.
> (The second operand, the power, is self-determined, and not affected by other
> operands.)
>
> Thirdly, the text refers only to the two operands of this operator in order to
> not complicate the text further by talking about additional
> operands.
This is pure speculation and cannot be considered as argument.

> Similarly, 4.1.7, for example, says that "When two operands of unequal bit
> lengths are used ..., the smaller operand shall be zero filled ... to extend
> to the size of the larger operand," and does not relate to other operands in
> the larger expression. And the same is true of the other
> subsections of 4.1.
Thank you presenting the argument for me. Indeed several subsections
in 4.1. describe the type of the expression in terms of the operands
associated to the particular operator. This is so precisely because
the type of an expression does not depend on the types of operands of
other expressions that happen to be combined into the same complex
expression with the one whose type we try to determine.

As I stated earlier the size of the expression may also depend on
context whereas the type of an expression depends only on the types of
it's operands and not on it's context (i.e. on other sub-expressions
combined in the same expression via the rules of precedence and via
open and closed parenthesis).

>
> Shalom
>
Alec

From: Michael McNamara <mac@verisity.com>
To: Alec Stanculescu <alec@fintronic.com>
Cc: Shalom.Bresticker@motorola.com, etf-bugs@boyd.com, btf-dtype@boyd.com
Subject: Re: errata/282: signing
Date: Sun, 2 May 2004 23:15:22 -0700

What about 4.5.2?

What about the BNF, where the top level production is called
"expression" (see page 58) not "complex expression"?

It is true that special things happen given certain binary expressions
with special operators (>>, **, et cetera).

However the only definition of expression is that in the BNF, and in
the case of an assignment, "expression" consists of everything on the
right hand side of an assigment (everything after the '=").

This would support the position that the generic signing and sizing
rules, when they talk about applying to an expression, in the absense
of some of these special operators, apply to everything tha Alex is
calling complex expression. Indeed the term "complex expression"
doesn't appear in the main text of the manual at all. It does appear
in the vpi section of the manual; but it is hard to take this as a
term of the language becuae of this.


-- On May 2 2004 at 22:01, Alec Stanculescu sent a message:
> To: Shalom.Bresticker@motorola.com, etf-bugs@boyd.com, btf-dtype@boyd.com
> Subject: "Re: errata/282: signing"
>
> > > 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").
> >
> > Alec,
> >
> > Are you confusing between 4.1.5 and 4.5.1 ?
> >
> The answer is NO. However, I do understand why you may be confused
> by 4.1.5 and 4.5.1. It is because in breaking with an important
> rule of how to write the LRM, writing the fix of errata 140 has
> introduced a forward reference in 4.1.5 to 4.5.1.
>
> Most forward references should be considered errata and
> eliminated. That would make for a much better LRM.
>
> > > 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.
> >
> > You picked a bad example for several reasons.
> >
> The wordings of 4.1.5 in "version B" clearly showed the intention of
> the LRM to determine the type of the expression that uses the power
> operator as depending only on it's two operands.
>
> Given that this is one of the few places where the LRM showed it's intention
> one way or the other regarding whether "expression" in 4.5.1 means
> the entire ensemble of subexpressions, or just an expression having
> one operator, makes the "original wording of the LRM" extremely
> relevant. Basically, in fixing issue 140 the writer
> of the LRM has erased one instance of the clear intent of the LRM with
> respect to what "expression" means in 4.5.1. Also, the fix of errata 140,
> is flowed in that it introduced a forward reference in 4.1.5 to 4.5.1.
> Each forward reference in the LRM is basically an errata in itself!
>
> > One is that the text you quoted is from 1364-2001 Version B and is simply
> > incorrect. That was errata issue #140. The text was completely rewritten
> > and substantially changed.
> >
> > The second reason is that, yes, the type of the first operand of the power
> > operator (i.e., the base) is affected by the other operands in the
> > expression
> > in which it appears, i.e., it's bit-size and signedness.
> > (The second operand, the power, is self-determined, and not affected by other
> > operands.)
> >
> > Thirdly, the text refers only to the two operands of this operator in order to
> > not complicate the text further by talking about additional
> > operands.
> This is pure speculation and cannot be considered as argument.
>
> > Similarly, 4.1.7, for example, says that "When two operands of unequal bit
> > lengths are used ..., the smaller operand shall be zero filled ... to extend
> > to the size of the larger operand," and does not relate to other operands in
> > the larger expression. And the same is true of the other
> > subsections of 4.1.
> Thank you presenting the argument for me. Indeed several subsections
> in 4.1. describe the type of the expression in terms of the operands
> associated to the particular operator. This is so precisely because
> the type of an expression does not depend on the types of operands of
> other expressions that happen to be combined into the same complex
> expression with the one whose type we try to determine.
>
> As I stated earlier the size of the expression may also depend on
> context whereas the type of an expression depends only on the types of
> it's operands and not on it's context (i.e. on other sub-expressions
> combined in the same expression via the rules of precedence and via
> open and closed parenthesis).
>
> >
> > Shalom
> >
> Alec

From: Alec Stanculescu <alec@fintronic.com>
To: mac@verisity.com
Cc: Shalom.Bresticker@motorola.com, etf-bugs@boyd.com, btf-dtype@boyd.com
Subject: Re: errata/282: signing
Date: Mon, 3 May 2004 08:38:13 -0700

Mac,

4.5.2 is poorly written as well. It mixes the notions of size,
property of signed/unsigned and type in some steps that are not
enumerated, it makes references to 4.5.1 when it talks about
determining the sign ( note that 4.5.1 is the section which talks
about the type of expressions) and does not reference the section
that describes how the size is determined.

The correct answer to the issue you raise is that the BNF must be
understood in terms of it's corresponding schema, under which both
one operand expressions and "complex expressions" are expressions.

Given that the code the user is writing is modified automatically
by the LRM-obiding tool (by transforming signed into unsigned) in
a way that produces results that are
different from the expected ones, I propose that such mixed
descriptions where signed and unsigned operands are encountered
shall be flagged as errors. It will force users to realize that
what they wrote is useless (according to the LRM anyways) and that
by re-writing their code at least they will have some code which
will produce expected results.

Regards,

Alec

>
> What about 4.5.2?
>
> What about the BNF, where the top level production is called
> "expression" (see page 58) not "complex expression"?
>
> It is true that special things happen given certain binary expressions
> with special operators (>>, **, et cetera).
>
> However the only definition of expression is that in the BNF, and in
> the case of an assignment, "expression" consists of everything on the
> right hand side of an assigment (everything after the '=").
>
> This would support the position that the generic signing and sizing
> rules, when they talk about applying to an expression, in the absense
> of some of these special operators, apply to everything tha Alex is
> calling complex expression. Indeed the term "complex expression"
> doesn't appear in the main text of the manual at all. It does appear
> in the vpi section of the manual; but it is hard to take this as a
> term of the language becuae of this.
>
>
> -- On May 2 2004 at 22:01, Alec Stanculescu sent a message:
> > To: Shalom.Bresticker@motorola.com, etf-bugs@boyd.com, btf-dtype@boyd.com
> > Subject: "Re: errata/282: signing"
> >
> > > > 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").
> > >
> > > Alec,
> > >
> > > Are you confusing between 4.1.5 and 4.5.1 ?
> > >
> > The answer is NO. However, I do understand why you may be confused
> > by 4.1.5 and 4.5.1. It is because in breaking with an important
> > rule of how to write the LRM, writing the fix of errata 140 has
> > introduced a forward reference in 4.1.5 to 4.5.1.
> >
> > Most forward references should be considered errata and
> > eliminated. That would make for a much better LRM.
> >
> > > > 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.
> > >
> > > You picked a bad example for several reasons.
> > >
> > The wordings of 4.1.5 in "version B" clearly showed the intention of
> > the LRM to determine the type of the expression that uses the power
> > operator as depending only on it's two operands.
> >
> > Given that this is one of the few places where the LRM showed it's intention
> > one way or the other regarding whether "expression" in 4.5.1 means
> > the entire ensemble of subexpressions, or just an expression having
> > one operator, makes the "original wording of the LRM" extremely
> > relevant. Basically, in fixing issue 140 the writer
> > of the LRM has erased one instance of the clear intent of the LRM with
> > respect to what "expression" means in 4.5.1. Also, the fix of errata 140,
> > is flowed in that it introduced a forward reference in 4.1.5 to 4.5.1.
> > Each forward reference in the LRM is basically an errata in itself!
> >
> > > One is that the text you quoted is from 1364-2001 Version B and is simply
> > > incorrect. That was errata issue #140. The text was completely rewritten
> > > and substantially changed.
> > >
> > > The second reason is that, yes, the type of the first operand of the power
> > > operator (i.e., the base) is affected by the other operands in the
> > > expression
> > > in which it appears, i.e., it's bit-size and signedness.
> > > (The second operand, the power, is self-determined, and not affected by other
> > > operands.)
> > >
> > > Thirdly, the text refers only to the two operands of this operator in order to
> > > not complicate the text further by talking about additional
> > > operands.
> > This is pure speculation and cannot be considered as argument.
> >
> > > Similarly, 4.1.7, for example, says that "When two operands of unequal bit
> > > lengths are used ..., the smaller operand shall be zero filled ... to extend
> > > to the size of the larger operand," and does not relate to other operands in
> > > the larger expression. And the same is true of the other
> > > subsections of 4.1.
> > Thank you presenting the argument for me. Indeed several subsections
> > in 4.1. describe the type of the expression in terms of the operands
> > associated to the particular operator. This is so precisely because
> > the type of an expression does not depend on the types of operands of
> > other expressions that happen to be combined into the same complex
> > expression with the one whose type we try to determine.
> >
> > As I stated earlier the size of the expression may also depend on
> > context whereas the type of an expression depends only on the types of
> > it's operands and not on it's context (i.e. on other sub-expressions
> > combined in the same expression via the rules of precedence and via
> > open and closed parenthesis).
> >
> > >
> > > Shalom
> > >
> > Alec
>

From: Stefen Boyd <stefen@boyd.com>
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/282: signing
Date: Mon, 03 May 2004 12:38:09 -0700

Sorry for the noise... just trying to work around a gnats
bug that inserts extra "Re: errata/282: " into the subject
lines.

Stefen

From: Stefen Boyd <stefen@boyd.com>
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/282: signing
Date: Mon, 03 May 2004 12:41:44 -0700

Sorry again. I'll try another variant. This time for sure...

Stefen

From: Steven Sharp <sharp@cadence.com>
To: Shalom.Bresticker@motorola.com, alec@fintronic.com
Cc: etf-bugs@boyd.com, btf-dtype@boyd.com
Subject: errata/282: signing
Date: Mon, 3 May 2004 18:52:36 -0400 (EDT)

Alec,

You cannot tell someone what they meant when they wrote something;
you can only ask them.

Have you asked the people responsible for the signed arithmetic proposal
what they meant? I have. You are trying to tell me that they meant
something different from what they say they meant. I have to conclude
that you are wrong, and that they meant what they say.

You are including the datatypes task force in the distribution of this
discussion. As a result, I wonder if your real concern is the problems
that would occur if the rules for signedness were applied to the new
type system. This concern could have arisen because the 2001 LRM uses
the term "type" when talking about signedness. It tries to roll reals
in as a type also, and claim the same rules apply, but this is wrong
since different rules apply to reals, and always have.

I agree with you that these rules probably won't work if applied to
datatypes in general. They don't even work for reals. The rules are
applied to the signedness of vector expressions, which is why they need
to work similarly to the rules for sizes of vectors. Just because the
LRM text uses the term "type" for signedness does not mean that new types
will have to follow the same rules. It just means that if they don't,
the signedness rules will have to stop using the term "type".

Note that the correct rules for reals do not convert non-real operands
to real until they are about to be combined with a real at an operator.
Subexpressions that will be implicitly converted to real this way are
treated as self-determined until that point. This behavior is similar
to most programming languages, and is what apparently seems natural to
you. When it is documented correctly, this could form a starting point
for rules for other datatypes.

Steven Sharp
sharp@cadence.com

From: Alec Stanculescu <alec@fintronic.com>
To: sharp@cadence.com
Cc: Shalom.Bresticker@motorola.com, etf-bugs@boyd.com, btf-dtype@boyd.com
Subject: Re: errata/282: signing
Date: Mon, 3 May 2004 17:50:45 -0700

Steve,

I respect very much your style of writing, especially when it provides
information relevant to the topic at hand. Simple claims that you
talked to people and know what they want are not good enough as
arguments to be taken into account.

Furthermore, I do not believe that anybody told you that what he/she
really wants is to write some Verilog, knowing without a doubt that
any LRM-complying Verilog tool will effectively change their Verilog
description into some other Verilog code, producing totally different
results from what they may expect. Such a user would be better off
being told by the tool that what he/she wrote is not legal according
to the LRM and that he/she should write it differently to begin with!
This way at least the user will have documented the exact Verilog that
will be considered by any Verilog LRM complying tool.

This is like for any semantic error the tool would produce some
arbitrary result and continue without complaining. I know that
there is some precedence for this, such as in assignments to bit
selects with indexes out of range, but this precedent does not make
this practice any more acceptable.

So, what do you say to the proposal to make illegal any complex expression
that uses both signed and unsigned. This could simplify the LRM
enormously and users would see only benefits from this, since they
would not loose any modeling capabilities they currently have, and
models would be portable across tools.

> Alec,
>
> You cannot tell someone what they meant when they wrote something;
> you can only ask them.
>
> Have you asked the people responsible for the signed arithmetic proposal
> what they meant? I have. You are trying to tell me that they meant
> something different from what they say they meant. I have to conclude
> that you are wrong, and that they meant what they say.
>
Until you tell us what they told you we cannot say anything on this
matter.

> You are including the datatypes task force in the distribution of this
> discussion. As a result, I wonder if your real concern is the problems
> that would occur if the rules for signedness were applied to the new
> type system. This concern could have arisen because the 2001 LRM uses
> the term "type" when talking about signedness. It tries to roll reals
> in as a type also, and claim the same rules apply, but this is wrong
> since different rules apply to reals, and always have.
>
Indeed, this is a concern of mine.

> I agree with you that these rules probably won't work if applied to
> datatypes in general. They don't even work for reals. The rules are
> applied to the signedness of vector expressions, which is why they need
> to work similarly to the rules for sizes of vectors.
They do work similarly, with the exception that the type depends only
on the operands and the size may also depend on the context. The
context makes it possible for the size of a sub-expression to be
influenced by the size of another sub-expression within the same
expression.

>Just because the
> LRM text uses the term "type" for signedness does not mean that new types
> will have to follow the same rules. It just means that if they don't,
> the signedness rules will have to stop using the term "type".
>
Signedness does create a different type and I would like to see the
terminology consistent. Of course sometimes there can be exceptions,
but only when exceptions are absolutely necessary.

> Note that the correct rules for reals do not convert non-real operands
> to real until they are about to be combined with a real at an operator.
> Subexpressions that will be implicitly converted to real this way are
> treated as self-determined until that point. This behavior is similar
> to most programming languages, and is what apparently seems natural to
> you. When it is documented correctly, this could form a starting point
> for rules for other datatypes.
>
> Steven Sharp
> sharp@cadence.com
>
Alec Stanculescu

From: Stefen Boyd <stefen@boyd.com>
To: Alec Stanculescu <alec@fintronic.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/282: signing
Date: Mon, 03 May 2004 22:04:27 -0700

Alec,

This has been rather heated discussion and I don't intend to stoke
the fire...
As a user, I was there during the discussions when we added signed
arithmetic. Perhaps I don't represent all of the users, but for a
portion of them I may represent, I understood the way signed
arithmetic was defined and it made sense to me. I'm not sure I'm
excited about making expressions that mix signs illegal. Having it
behave the same way as vector expansion made sense then and still
does now. As a user, I like the consistency of the two rules. They
may be weird, but since they're the same, once I've understood the
one - I understand both. I'm not opposed to rethinking the sign
rules but I'd like them to match something else in Verilog.
And, no, making it illegal rubs me the wrong way - it's not very
Verilog, so that wouldn't get me excited either.

I'm not trying to point fingers here, I'm just saying that regardless
of how well it was documented, our intent was for sign rules to
follow the vector width rules. And strange as it may seem - I liked
it that way. That's why I approved it in the standard... I'd just like
to see it cleaned up to document what we intended when we were
refining the proposal.

Stefen

At 05:40 PM 5/3/2004 -0700, Alec Stanculescu wrote:
> So, what do you say to the proposal to make illegal any complex expression
> that uses both signed and unsigned. This could simplify the LRM
> enormously and users would see only benefits from this, since they
> would not loose any modeling capabilities they currently have, and
> models would be portable across tools.

From: Alec Stanculescu <alec@fintronic.com>
To: stefen@boyd.com
Cc: etf-bugs@boyd.com
Subject: Re: errata/282: signing
Date: Tue, 4 May 2004 11:26:27 -0700

Stefen,

I agree with everything you said, with the possible exception that you
appear to be of the opinion that the writing of the LRM was
successful in making "sign rules follow vector width rules". This is
not the case because sign rules change the sign of operands (from what
they were specified by the user!) whereas vector width rules do not
affect what the user wrote, they do not change the width of any
operand. They just describe what happens to the result.

In my opinion it is better to tell the user that his/her code will have to be
changed and not change it for them. Currently, there are some rules
regarding how to fix what the user wrote in terms of signed/unsinged
and there is disagreement regarding how to interpret these rules. I am
saying that there is no need for such rules in the first place. Give
the user the chance to write correct and portable code, without taking
from the user any modeling power.

Regards,

Alec

> Alec,
>
> This has been rather heated discussion and I don't intend to stoke
> the fire...
> As a user, I was there during the discussions when we added signed
> arithmetic. Perhaps I don't represent all of the users, but for a
> portion of them I may represent, I understood the way signed
> arithmetic was defined and it made sense to me. I'm not sure I'm
> excited about making expressions that mix signs illegal. Having it
> behave the same way as vector expansion made sense then and still
> does now. As a user, I like the consistency of the two rules. They
> may be weird, but since they're the same, once I've understood the
> one - I understand both. I'm not opposed to rethinking the sign
> rules but I'd like them to match something else in Verilog.
> And, no, making it illegal rubs me the wrong way - it's not very
> Verilog, so that wouldn't get me excited either.
>
> I'm not trying to point fingers here, I'm just saying that regardless
> of how well it was documented, our intent was for sign rules to
> follow the vector width rules. And strange as it may seem - I liked
> it that way. That's why I approved it in the standard... I'd just like
> to see it cleaned up to document what we intended when we were
> refining the proposal.
>
> Stefen
>
> At 05:40 PM 5/3/2004 -0700, Alec Stanculescu wrote:
> > So, what do you say to the proposal to make illegal any complex expression
> > that uses both signed and unsigned. This could simplify the LRM
> > enormously and users would see only benefits from this, since they
> > would not loose any modeling capabilities they currently have, and
> > models would be portable across tools.
>

From: Shalom.Bresticker@freescale.com
To: Alec Stanculescu <alec@fintronic.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/282: signing
Date: Tue, 4 May 2004 22:11:24 +0300 (IDT)

Alec,

> I agree with everything you said, with the possible exception that you
> appear to be of the opinion that the writing of the LRM was
> successful in making "sign rules follow vector width rules". This is
> not the case because sign rules change the sign of operands (from what
> they were specified by the user!) whereas vector width rules do not
> affect what the user wrote, they do not change the width of any
> operand. They just describe what happens to the result.

This is not so.
Consider this case:

a is 8 bits, b is 4 bits, b = 4'b1100

If I write

a = ~b;

then b is first widened to 8 bits, giving me 8'b00001100.
When I complement it, I get a = 8'b11110011.

Whereas if I first complemented b, then widened the result,
I would get 8'b00000011.

Shalom

From: Bruce LaVigne <bruce@hp.com>
To: Shalom.Bresticker@freescale.com
Cc: etf-bugs@boyd.com
Subject: Re: errata/282: signing version=2.63
Date: Tue, 04 May 2004 13:38:01 -0700

I appologize for not following this width/sign-extension discussion fully,
but from a user point of view, I hope that the LRM clearly spells out which of
these behaviours will occur, as this would be the first place I'd look to make
sure I got a desired result from simulators & synthesis tools - neither is the
"obvious" answer to me, and in fact, another possibility would be that in
widening b, you sign-extend to get 8'b11111100, which gives a final result
identical to what Shalom points out is the wrong answer!

Of course, I would never write code like this myself (at least, not after
the linter told me I had mismatching widths ;-) ;-) ;-)

-bruce


Shalom.Bresticker@freescale.com wrote:
> The following reply was made to PR errata/282; it has been noted by GNATS.
>
> From: Shalom.Bresticker@freescale.com
> To: Alec Stanculescu <alec@fintronic.com>
> Cc: etf-bugs@boyd.com
> Subject: Re: errata/282: signing
> Date: Tue, 4 May 2004 22:11:24 +0300 (IDT)
>
> Alec,
>
> > I agree with everything you said, with the possible exception that you
> > appear to be of the opinion that the writing of the LRM was
> > successful in making "sign rules follow vector width rules". This is
> > not the case because sign rules change the sign of operands (from what
> > they were specified by the user!) whereas vector width rules do not
> > affect what the user wrote, they do not change the width of any
> > operand. They just describe what happens to the result.
>
> This is not so.
> Consider this case:
>
> a is 8 bits, b is 4 bits, b = 4'b1100
>
> If I write
>
> a = ~b;
>
> then b is first widened to 8 bits, giving me 8'b00001100.
> When I complement it, I get a = 8'b11110011.
>
> Whereas if I first complemented b, then widened the result,
> I would get 8'b00000011.
>
> Shalom
>
>
>

--
Bruce LaVigne ASIC Design Engineer
Hewlett-Packard Company ProCurve Networking Business
8000 Foothills Blvd, m/s 5672 phone: (916) 785-4194
Roseville, CA 95747-5672 email: bruce@hp.com

From: Alec Stanculescu <alec@fintronic.com>
To: Shalom.Bresticker@freescale.com
Cc: etf-bugs@boyd.com
Subject: Re: errata/282: signing
Date: Tue, 4 May 2004 15:43:02 -0700

Shalom,

You are right.

And this is exactly the same as in C/C++ as is exemplified by the
following C code:
#include <stdio.h>

int main()
{
short b;
unsigned a;
b = 12;
a = ~b;
printf("a=%x\n", a);
}

producing:

a=fffffff3

You convinced me that size and sign are two very
different things and that the mirage of trying to treat them in the
same way attracted many people, and would have attracted me as well if
I would have been involved in that decision process.

The corresponding C code for the issue 282 under discussion is:

#include <stdio.h>

int main()
{
short s;
short int a, b;
unsigned result, d;
d = 3;
a = -2;
b = 1;
result = d + a * b;
printf("result=%d\n", result);
}

which produces result = 1

Following the semantics of C/C++ whenever possible was always a big
plus for Verilog and I think that we should make efforts to keep it
this way for obvious reasons.

Therefore, the following code:

`timescale 1ns/1ns
module test;

reg signed [15:0] a,b;
reg [31:0] result, d;
integer v;
initial
begin
v = 3;
d = v;
v = -2;
a = v;
v = 1;
b = v;
result = d + a * b;
$display("a = %b,\n b = %b,\n d = %b,\n result = %b\n",a,b,d,result);
$finish;
end // initial begin

endmodule // test

should produce:
a = 1111111111111110,
b = 0000000000000001,
d = 00000000000000000000000000000011,
result = 00000000000000000000000000000001

Also, please note that

`timescale 1ns/1ns
module test;

reg [7:0] a;
reg [3:0] b;

initial
begin
b = 4'b1100;
a = {4'b0000, ~b};
$display("a = %b, b = %b",a,b);
$finish;
end // initial begin

endmodule // test
should produce the result:

a = 00000011, b = 1100

because b should not be sign-extended in this case, due to the fact
that the LHS matches the RHS in size. Therefore, the LRM does not
impose blindly the extension of all operands to the largest size as it is not
imposing to blindly coerce all operands to unsigned if one operand is
unsigned.

Alec Stanculescu

> Shalom Bresticker wrote:
> Alec,
>
> > I agree with everything you said, with the possible exception that you
> > appear to be of the opinion that the writing of the LRM was
> > successful in making "sign rules follow vector width rules". This is
> > not the case because sign rules change the sign of operands (from what
> > they were specified by the user!) whereas vector width rules do not
> > affect what the user wrote, they do not change the width of any
> > operand. They just describe what happens to the result.
>
> This is not so.
> Consider this case:
>
> a is 8 bits, b is 4 bits, b = 4'b1100
>
> If I write
>
> a = ~b;
>
> then b is first widened to 8 bits, giving me 8'b00001100.
> When I complement it, I get a = 8'b11110011.
>
> Whereas if I first complemented b, then widened the result,
> I would get 8'b00000011.
>
> Shalom
>

From: Shalom.Bresticker@freescale.com
To: Bruce LaVigne <bruce@hp.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/282: signing
Date: Wed, 5 May 2004 06:45:32 +0300 (IDT)

Bruce,

Unfortunately, the LRM is not clear enough, which is what we are trying to
fix in the discussions on the sign-related errata.

However, you would definitely not sign-extend in this case, because neither
a nor b is signed, they are both unsigned. Unsigned entities are zero-extended,
not sign-extended.

Shalom


On Tue, 4 May 2004, Bruce LaVigne wrote:

> I appologize for not following this width/sign-extension discussion fully,
> but from a user point of view, I hope that the LRM clearly spells out which of
> these behaviours will occur, as this would be the first place I'd look to make
> sure I got a desired result from simulators & synthesis tools - neither is the
> "obvious" answer to me, and in fact, another possibility would be that in
> widening b, you sign-extend to get 8'b11111100, which gives a final result
> identical to what Shalom points out is the wrong answer!

From: Shalom.Bresticker@freescale.com
To: Alec Stanculescu <alec@fintronic.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/282: signing
Date: Thu, 1 Jul 2004 18:14:48 +0300 (IDT)

I don't really wan't to start up this argument again, but I was
cleaning up my inbox and noticed the following:

On Tue, 4 May 2004, Alec Stanculescu wrote:

> Also, please note that
>
> `timescale 1ns/1ns
> module test;
>
> reg [7:0] a;
> reg [3:0] b;
>
> initial
> begin
> b = 4'b1100;
> a = {4'b0000, ~b};
> $display("a = %b, b = %b",a,b);
> $finish;
> end // initial begin
>
> endmodule // test
> should produce the result:
>
> a = 00000011, b = 1100
>
> because b should not be sign-extended in this case, due to the fact
> that the LHS matches the RHS in size. Therefore, the LRM does not
> impose blindly the extension of all operands to the largest size as it is not
> imposing to blindly coerce all operands to unsigned if one operand is
> unsigned.

All 3 simulators that I have do give this result, but the reason
is that b appears here with a concatenation operator.

The LRM explicitly says that operands of a concatenation are self-determined,
i.e., not size-extended nor type-coerced.

Shalom

--
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

[ ]Freescale Internal Use Only
[ ]Freescale Confidential Proprietary


Fix replaced by sharp@cadence.com on Mon Nov 29 01:52:14 2004

Proposal for expression signedness and sizing issues

Commentary:

This is a stab at clarifying the description of how context-determined
signedness and expression sizing works (a variety of errata). It also
covers how reals work (erratum 83), and the special behavior of compares.
It may not be adequate to resolve the issues, but it is an attempt. It
was done in a hurry, so there may be problems with it. Insert more
disclaimers here.

The new text refers to a "primary" from the grammar. For some reason,
"primary" does not include a string. Instead, strings are listed separately
as expressions. This is apparently an error in the grammar, since it
prevents the use of unary operators on strings, which should be legal. The
new text assumes that this will be fixed; otherwise it needs to say
"primary or string".

Changes:

In 4.5.2, CHANGE:

-- Coerce the type of each operand of the expression (excepting those which
are self-determined) to the type of the expression.
-- Extend the size of each operand (excepting those which are self-determined)
to the size of the expression. Perform sign extension if and only if the
operand type (after type coercion) is signed.

TO:

-- Propagate the type and size of the expression (or self-determined sub-
expression) back down to the context-determined operands of the expression.
In general, any context-determined operand of an operator is the same
type and size as the result of the operator. However, there are two
exceptions:
- If the result type of the operator is real, and it has a context-
determined operand that is not real, that operand is treated as if
it were self-determined and then converted to real just before the
operator is applied.
- The relational and equality operators have operands that are neither
fully self-determined or context-determined. The operands affect
each other as if they were context-determined operands with a result
type and size (maximum of the two operand sizes) determined from them.
However, the actual result type is always 1 bit unsigned. The type
and size of the operands is independent of the rest of the expression
and vice-versa.
-- When propagation reaches a simple operand as defined in 4.2 (a primary
as defined in A.8.4), then that operand is converted to the propagated
type and size. If the operand must be extended, then it is sign-extended
only if the propagated type is signed.



Fix replaced by Shalom.Bresticker@freescale.com on Mon Nov 29 08:42:20 2004
Proposal for expression signedness and sizing issues

Commentary:

This is a stab at clarifying the description of how context-determined
signedness and expression sizing works (a variety of errata). It also
covers how reals work (erratum 83), and the special behavior of compares.
It may not be adequate to resolve the issues, but it is an attempt. It
was done in a hurry, so there may be problems with it. Insert more
disclaimers here.

The new text refers to a "primary" from the grammar. For some reason,
"primary" does not include a string. Instead, strings are listed separately
as expressions. This is apparently an error in the grammar, since it
prevents the use of unary operators on strings, which should be legal. The
new text assumes that this will be fixed; otherwise it needs to say
"primary or string".

Changes:

In 4.5.2, CHANGE:

-- Coerce the type of each operand of the expression (excepting those which
are self-determined) to the type of the expression.
-- Extend the size of each operand (excepting those which are self-determined)
to the size of the expression. Perform sign extension if and only if the
operand type (after type coercion) is signed.

TO:

-- Propagate the type and size of the expression (or self-determined sub-
expression) back down to the context-determined operands of the expression.
In general, any context-determined operand of an operator is the same
type and size as the result of the operator. However, there are two
exceptions:
- If the result type of the operator is real, and it has a context-
determined operand that is not real, that operand is treated as if
it were self-determined and then converted to real just before the
operator is applied.
- The relational and equality operators have operands that are neither
fully self-determined nor fully context-determined. The operands affect
each other as if they were context-determined operands with a result
type and size (maximum of the two operand sizes) determined from them.
However, the actual result type is always 1 bit unsigned. The type
and size of the operands is independent of the rest of the expression
and vice-versa.
-- When propagation reaches a simple operand as defined in 4.2 (a primary
as defined in A.8.4), then that operand is converted to the propagated
type and size. If the operand must be extended, then it is sign-extended
only if the propagated type is signed.


Unformatted


>From: "Harry Foster" <harry@verplex.com>
>To: <stuart@sutherland-hdl.com>, <cliffc@sunburst-design.com>,
> "Adam Krolnik" <krolnik@lsil.com>, <mac@verisity.com>
>Cc: "Andy Lin" <cclin@verplex.com>
>Subject: Tool inconsistencies in implementing Verilog 2001 sign extension
>in the context of unsigned assignments
>Date: Wed, 29 Jan 2003 15:17:23 -0600
>
>Hi Guys,
>
>You are all experts in the Verilog 2001 standard, and I need help
>understanding some inconsistencies we have observed across multiple tools
>related to the implementation of sign extension in the context of unsigned
>assignment?
>
>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)"
>
>Related info in Verilog 2001 LRM, section 4.5:
> - 4.5.1 Rules for expression types:
> For non-self-determined operands the following rules apply:
> 1. if any operand is real, the result is real.
> 2. if any operand is unsigned, the result is unsigned, regardless the
>operator;
> 3. if all operands are signed, the result will be signed, regardless of
>operator,
> except as noted.
>
> - 4.5.2 Steps for evaluating an expression
> 1. Determine the expression size based upon the standard rules of
>expression
> size determination.
> 2. Determine the sign of the expression using the rules outlined in
>Section 4.5.1
> 3. Coerce the type of each operand of the expression (excepting those
>which
> are self-determined) to the type of the expression.
> 4. Extend the size of each operand (excepting those which are
>self-determined)
> to the size of the expression. Perform sign extension if and only if
>the
> operand type (after type coercion) is signed.
>
>FYI, here are the various tool results we have observed:
>
> - Design Compiler
> DC performs D = $signed(A)*$signed(B) first,
> then truncates it to C's size, denoted as value E,
> then assigns to Z: Z = $unsigned(E) + $unsigned(C);
> DC's result is different from all other tools.
>
> - Verilog-XL, Ncverilog, Ambit BuildGates
> The Ambit has the same result as Verilog-XL and Ncverilog.
> the tools do D = $unsigned(A)*$unsigned(B) first,
> then the assignment Z = $unsigned(D) + $unsigned(C);
>
> - VCS, Synplify_asic, Conformal LEC
> synplify_asic gets the same result as VCS and LEC
> The tools do D = $signed(A)*$signed(B) first,
> then the assignment Z = $signed(D) + $unsigned(C);
>
>Any help in clarifying the standard would be welcomed.
>
>Thanks,
>
>-Harry

Hosted by Boyd Technology