Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

how to do signed arithmetic

268 views
Skip to first unread message

john...@my-deja.com

unread,
Jun 29, 2000, 3:00:00 AM6/29/00
to
Hi, I wonder how to do signed arithmetic in verilog. Suppose if my
inputs are in 2's complement binary format, how to tell verilog that
they are signed numbers? In VHDL, the IEEE signed package is really
handy in
this respect. Look forward to hearing from you.

John


Sent via Deja.com http://www.deja.com/
Before you buy.

Muzaffer Kal

unread,
Jun 29, 2000, 3:00:00 AM6/29/00
to
I am assuming by signed-arithmetic you mean twos complement signed
arithmetic. If so, you are OK with addition and subtraction, IOW
4'b1111+4'b0001 = 0000 just as you would want but multiplication
doesn't work quite right. You can get around this by defining your own
multipliers by booth or doing sign correction yourself.

Jason Rosinski - mrd

unread,
Jun 30, 2000, 3:00:00 AM6/30/00
to
As far as I've been able to tell, all numbers in verilog are unsigned.  For two's complement addition this is no problem, just add them like normal.  But for multiplication you have to build a 2's complement multiplier.

john...@my-deja.com wrote:

Hi, I wonder how to do signed arithmetic in verilog. Suppose if my
inputs are in 2's complement binary format, how to tell verilog that
they are signed numbers? In VHDL, the IEEE signed package is really
handy in
this respect. Look forward to hearing from you.

John

Sent via Deja.com http://www.deja.com/
Before you buy.

-- 
Jason Rosinski
ext. 6737
Mitel Semiconductor
 

taniwha

unread,
Jun 30, 2000, 3:00:00 AM6/30/00
to
john...@my-deja.com wrote:
>
> Hi, I wonder how to do signed arithmetic in verilog. Suppose if my
> inputs are in 2's complement binary format, how to tell verilog that
> they are signed numbers? In VHDL, the IEEE signed package is really
> handy in
> this respect. Look forward to hearing from you.

Well you have to do it yourself (untill the signed stuff
gets incorporated into all the tools)

Signed addition/subtraction/mag comparison is
relatively easy - just make sure you sign-extend the
stuff you are adding to the right size, for example to
add an 8 and 16-bit value:

res = bit16+{{8{bit8[7]}}, bit8};

multiplication is harder - basicly you have to
do the xor of the signs your self - but look in your
synthesis library first - you may find a block you
can instantiate

Paul Campbell

Gilbert H. Herbeck

unread,
Jun 30, 2000, 3:00:00 AM6/30/00
to
taniwha wrote:

Don't hold your breath waiting for the new standard. From what I
have heard, verilog 2000 is *arithmetically incorrect* for many
important expressions. If signed and unsigned mix, the answer is
not what you would expect. I have not personally seen the new
standard. But this is what I've heard....

wire signed [ 7:0] A8s;
wire signed [15:0] B16s;
wire [15:0] B16u;
wire signed [16:0] X16s = B16s + A8s; // A8s is treated as signed - correct
wire signed [16:0] Y16s = B16u + A8s; // A8s is treated as unsigned -
incorrect!

It's just a stupid example, but you get the idea. This is what I have heard.
*Please* correct me if I am wrong. I hope that I am (wrong).

Gil

Willy Gonnason

unread,
Jul 2, 2000, 3:00:00 AM7/2/00
to
taniwha wrote:
> > Hi, I wonder how to do signed arithmetic in verilog. Suppose if my
> > inputs are in 2's complement binary format, how to tell verilog that
> > they are signed numbers? In VHDL, the IEEE signed package is really
> > handy in
> > this respect. Look forward to hearing from you.

In Exemplar's Leonardo, there USED to be a synthesis directive of the
form `signed that could be applied to a multiplier operation to force it
to synthesize a signed two's complement operator. It may still be
there. The believe the syntax went something like:

x <= y `signed * z;

However, I recall trying to use it a year or two ago, and if I recall
correctly, it did NOT generate exactly what I intended. Another
unfortunate problem is that I don't believe the `signed directive was
supported under some simulators. I believe Cadence XL supported it (but
I could be wrong!) but NOT ModelTech, since "It's not part of the
Verilog standard".

Your mileage may vary!

Willy G.

---------------------------------------------------------------------------
Email : wgon...@att.net | Sorry. Nice
try.
Phone/Fax : 719-548-1251
|

Gilbert H. Herbeck

unread,
Jul 3, 2000, 3:00:00 AM7/3/00
to
This posting from Steven Sharp never reached the NG.
Steven speaks with some authority about the new standard.
--------------------------------------


Date: Fri, 30 Jun 2000 23:18:36 -0400 (EDT)
From: Steven Sharp <sh...@cadence.com>
To: gilhe...@home.com (Gilbert H. Herbeck)
Subject: Re: how to do signed arithmetic
Newsgroups: comp.lang.verilog

In article <395CD0F4...@home.com> you wrote:
:
: Don't hold your breath waiting for the new standard. From what I


: have heard, verilog 2000 is *arithmetically incorrect* for many
: important expressions.

Ummm, I don't think the phrase "arithmetically incorrect" has any
meaning here. There are no natural laws of mathematics for mixed
signed and unsigned arithmetic. Any set of rules you come up with
is correct by definition as long as it is self-consistent. From
the viewpoint of language design, you can add the requirement that
it be able to express any desired combination of signed and unsigned
conversions and operations.

: If signed and unsigned mix, the answer is not what you would expect.

This is probably true for most people. In particular, the rules are
different from those used in C. Most designers used to C will find
them unexpected. If there are any unsigned operands in a Verilog
expression, all operands will be converted to unsigned before any
operations are done. Most people would probably expect signed operands
to be combined with each other using signed operations, and only get
converted to unsigned when they meet the unsigned subexpression.

However, this rule is consistent with the width extension rules in
Verilog. All operands are converted to the expression width before
any operations are done. They do not wait until they actually combine
with a subexpression that is wider than they are. This rule is also
different from the rules in C, but is important to avoid the loss of
any digits during intermediate computations.

The rules produce counterintuitive results in many situations, but
they are backward compatible with existing Verilog. They also provide
explicit type conversion to get any desired computation.

: wire signed [16:0] Y16s = B16u + A8s; // A8s is treated as unsigned -
: incorrect!

It is not clear to me that this is incorrect. It is not clear at all
what was desired. C would also convert to unsigned here. You can
easily modify it to give your desired result, as follows:

wire signed [16:0] Y16s = $signed(B16u) + A8s;

Now if you want a really counterintuitive example, try:

wire signed [16:0] Y16s = (A8s * A8s) + B16u; // A8s treated as unsigned
// and multiplication is unsigned

Again, there are ways of getting whatever other results you wanted. If
you want a signed multiply and an unsigned add, use

wire signed [16:0] Y16s = $unsigned(A8s * A8s) + B16u;

If you want a signed add, use

wire signed [16:0] Y16s = (A8s * A8s) + $signed(B16u);

One thing I find very counterintuitive is that the $signed and $unsigned
conversions are more useful for shielding their arguments from the effects
of outside operands than for their conversion properties.

For example, it didn't matter that I used $unsigned in my example above.
You also get a signed multiply and an unsigned add from

wire signed [16:0] Y16s = $signed(A8s * A8s) + B16u;

Converting to signed doesn't do anything different here because the
unsigned B16u causes the result to be converted back to unsigned before
any further operations are performed. But the fact that the multiply is
inside the $signed makes its signedness self-determined so that B16u does
not affect it.

: It's just a stupid example, but you get the idea. This is what I have heard.


: *Please* correct me if I am wrong. I hope that I am (wrong).

Nope, it is probably at least as bad as you think. However, it does give
you the capability to do any signed or unsigned operations you want, which
didn't exist before.

Steven Sharp
sh...@cadence.com

0 new messages