From: Clifford E. Cummings (cliffc@europa.com)
Date: Fri May 02 1997 - 09:07:55 PDT
Subject: BTF - B19- Cadence signed arithmetic proposal
Behavioral Task Force - Enhancement Request
Assigned Enhancement Request Number: B19
Enhancement Name (Description): Cadence signed arithmetic proposal
Date Submitted: 970409
Requestor: tfitz@cadence.com (Tom Fitzpatrick)
Status: RO
Is enhancement intended to be synthesizable?: Yes
Subject: Proposal for Signed Wires and Regs in Verilog
Signed Arithmetic in Verilog
A Proposal to the IEEE 1364 Committee
Tom Fitzpatrick
Cadence Design Systems
1.0 Problem Statement:
The Verilog-HDL does not currently support signed arithmetic for
arbitrarily sized regs and wires. This functionality would be extremely
useful for hardware designers to be able to model complex mathematical
operations, and we at Cadence feel that the IEEE 1364 Committee should
consider adding this functionality to the language.
One of the primary requirements for the committee, in extending the Verilog
language, is to preserve the current functionality of the language, which
for the most part is defined by the behavior of the Verilog-XL
simulator. To this end, we have done an extensive investigation to
understand how Verilog-XL treats the only existing signed construct in the
language: the integer. The rules proposed here are an extension of current
rules used by Verilog-XL to handle integer operations, as well as mixtures
of integers and regs, which should be applicable to the general case of
regs and wires.
2.0 Solution:
Add support for arbitrarily signed sized objects to Verilog-HDL and VPI.
3.0 Verilog-HDL changes:
The elements that need to support being typed as signed are:
nets
registers
memories
HDL functions
User system functions (VPI)
io decls.
Except for User system functions, the object can be typed as being signed
by using the keyword "signed" in the definition of the object. The
functionality of the VPI interface will be enhanced to deal with the new
typed objects, the PLI 1.0 interface will not.
The only influence typing a net as signed will have is when the net is used
in an expression. Then the value of the entire net will be treated as a
signed value. The individual bits (if any) of the net will still be
derived from the resolved value of all of the net's drivers.
The signed attribute will not cross hierarchy. If a user wants the signed
type to cross hierarchy they will have to add the signed keyword to the
objects declaration at the different levels of hierarchy. Any expressions
on a port will be treated as any other expression in an assignment. It
will be typed, sized, evaluated and the resulting value assigned to the
object on the other side of the port using the same rules as an assignment.
A based constant can be typed as being signed by preceding the base type
with an "s". If the base type is not preceded with an "s" the constant
will be unsigned.
Two new arithmetic operator will be added to the language:
arithmetic shift right ASR ">>>"
arithmetic shift left ASL "<<<"
Two new systems functions will be added to handle type casting on
expressions $signed() and $unsigned(). These functions will evaluate the
input expression and return a value with the same size and value of the
input expression and the type defined by the function:
$signed -- signed
$unsigned -- unsigned
examples:
wire signed [3:0] signed_wire; // range -8 <-> +7
reg signed [3:0] signed_reg; // range -8 <-> +7
reg signed [3:0] signed_mem [99:0]; // 100 words range -8 <-> +7
function signed [3:0] signed_func; // range -8 <-> +7
out = in <<< 1;
tmp = tmp >>> 1;
4'd1 // 4 bit unsigned decimal 1
-4'd1 // 4 bit unsigned decimal -1
4'sd1 // 4 bit signed decimal 1
-4'sd1 // 4 bit signed decimal -1
The signed keyword may be included in an input, output or inout
declaration; however, if there is also a secondary declaration of the wire
or register aside from that of the I/O declaration, then the sign of the
secondary declaration must match that of the I/O declaration.
For example, the following are legal:
input signed signed_input;
wire signed signed_input;
input unsigned_input;
wire unsigned_input;
input signed another_signed_input;
And the following are illegal:
input signed signed_input;
wire signed_input;
input signed_input;
wire signed signed_input;
3.1 Determining the resultant type of an expression:
The value of signed quantities will be represented with two's complement
notation. The following are the rules for determining the resulting type
of an expression:
1. Expression type depends only on the operands. It does not depend on the
LHS (if any).
2. Decimal numbers are signed.
3. Based_numbers are unsigned.
4. Parameters are signed if and only if the RHS expression assigned to the
parameter is signed
5. Bit_sel results are unsigned, regardless of the operands.
6. Part_sel results are unsigned, regardless of the operands.
7. Concatenate results are unsigned, regardless of the operands.
8. Comparison results (1, 0) are unsigned, regardless of the operands.
9. Reals converted to integers by type coercion are signed
10. The sign and size of any self-determined operand is determined by the
operand itself and independent of the remainder of the expression.
11. For non-self-determined operands the following rules apply:
if any operand is real, the result is real.
elseif any operand is unsigned, the result is unsigned, regardless
of the operator
elseif all operands are signed, the result will be signed,
regardless of operator, except as noted.
3.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 3.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.
3.3 Steps for evaluating an assignment
1. Determine the size of the RHS by the standard assignment size determination
rules (the greater of the sizes of the LHS and RHS).
2. If needed, extend the size of the RHS, performing sign extension if and
only if the type of the RHS is signed.
3.4 Arithmetic shift operators:
The ASR preserves the sign bit if the operand is signed, while the ASL does
not, ASL is identical to a logical left shift. These operators are legal
wherever the logical shift operators are and have the same precedence as
the logical shift operators.
3.5 Dealing with "X" or "Z":
If a signed operand is to be resized to a larger signed width and the value
of the sign bit is "X", the resulting value will be bit filled with
"X"s. If the sign bit of the value is "Z", then the resulting value will be
bit filled with "Z"'s. If any bit of a signed value is "X" or "Z" then any
non logical operation involving the value will result in the entire
resultant value being an "X" and the type consistent with the expressions
type.
4.0 VPI
To register a function as being signed the user will set the sysfunctype
field of the t_vpi_systf_data structure to the value of
vpiSysFuncSignedSized.
Calling vpi_get() with the property vpiSigned will return TRUE on the
following objects if they have the signed attribute:
vpiIODecl, any object in the expression class.
Two new expression properties need to be added to the VPI include file for
the two new operators:
ASL vpiArithLShiftOp
ASR vpiArithRShiftOp
Date: Wed, 09 Apr 1997 15:04:04 -0400
From: Elliot Mednick <elliot@wellspring.com>
I have some fundamental objections to this proposal. This is similar to one
that was brought up in the OVI Language Committee a few years ago. A
modified version (which met with my approval, though it was still marginal)
made it into OVI LRM 2.0 and was then cut for IEEE-1364, which was just as well.
I will argue my case in the correct forum. I just wanted to let The List
know that this won't go through uncontested.
Date: Wed, 9 Apr 1997 18:08:47 -0700 (PDT)
From: <mac@silicon-sorcery.com>
I as well, have some serious detailed questions about the proposal as is.
And while some of my objections may be shared with Elliot's, likely he will
disagree with me about some as well.... I guess thats why it's called a
committee!
Date: Thu, 10 Apr 1997 10:20:51 -0400
From: Elliot Mednick <elliot@wellspring.com>
I would be happy to share my objections. I sent a quick private email to
Tom outlining my arguments. Someone tell me if 1364core is the right list
to do this, or tell me which list to use, and I will comment in detail.
//********************************************************************//
// Cliff Cummings E-mail: cliffc@europa.com //
// Sunburst Design Phone: 503-579-6362 / FAX: 503-579-7631 //
// 15870 SW Breccia Dr., Beaverton, OR 97007 //
// //
// Verilog & Synthesis Training / On-Site Training //
// Verilog, VHDL, Synopsys, LMG, FPGA, Consulting and Contracting //
//********************************************************************//
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:40 PDT
and
sponsored by Boyd Technology, Inc.