From: mac@silicon-sorcery.com
Date: Wed May 07 1997 - 10:10:42 PDT
Thomas Fitzpatrick writes:
> There were a few issues that came up at Monday's discussion of this
> proposal, and I'd like to address some of them now.
> ...
> What to do with "-4'd1": Mac mentioned that Verilog-XL has always treated
> this as if the unary "-" operation is applied to the constant "4'd1". That's
> not quite true. According to the 1364 spec (p 30), "an integer with a base
> specifier shall be interpreted as an unsigned value." Therefore, where the
> proposal lists
> -4'd1 // 4 bit unsigned decimal -1
>
> if this were assigned to an integer, or a signed reg of more than 4
> bits, the value should be zero-extended. Because based numbers are
> interpreted as unsigned, we proposed the -4'sd1 // 4 bit signed
> decimal -1 notation to be able to specify a signed, based number.
>
In 1364 Verilog, The 4'd1 is treated as an unsigned value.
The EXPRESSION -4'd1 applies the operator UNARY_MINUS to the
unsigned value 4'b0001.
The expression bit length rules are then applied:
1) examine the rhs expression, as a tree, starting at the
root. Determine the width of the result of the expression, based on
the width of the operands to the expressions, and the operators
applied to them, consulting the operator width table. Here we have
UNARY_MINUS(4'd1);
according to the table, the unary minus operator passes along
the width of it's operand, which in this case is 4 bits.
2) determine the width of the lhs expression. Here we see a 32
bit container, and no operators.
3) increase the size of each operand and expression to the
maximum of the size of the left hand side and right hand side
expressions. (again, subject to the operator width table's exceptions)
Therefore we increase 4'd1 to 32'd1, and yes, ZERO EXTENDING, as 4'd1
is an unsigned number.
After sizing is complete, then THEN the expression is
evaluated, and hence the unary minus operator is applied, converting
32'b0000_0000_0000_0000_0000_0000_0000_0001 into
32'b1111_1111_1111_1111_1111_1111_1111_1110
My understanding (which could be wrong) of the proposal is
that the proposed change would make the '-' part of the constant 4'd1,
and hence the rhs expression is simply the constant 4'd15, which after
sizing, gets zero extened to 32'd15, and then is simply assigned to
the RegA and the IntA, each which get 15.
Run this example on XL:
module one;
integer IntA;
reg [31:0] RegA;
initial begin
IntA = -4'd1;
RegA = -4'd1;
$display("IntA %d",IntA);
$display("RegA %d",RegA);
end // initial begin
endmodule // one
I get:
Highest module (one)
IntA -1
RegA 4294967295
<p> So, my point is with the proposed change, we would be making
the behavior of existing simulators incorrect, which is a big step,
one which needs a lot of justification, none of which I have seen.
Moreover, my understanding is there is no proposal to change
the behavior of the following, which leaves us with a non useful
inconsistancy:
module one;
integer IntA;
reg [31:0] RegA;
reg [3:0] a;
initial begin
a = 4'd1;
IntA = -a;
RegA = -a;
$display("IntA %d",IntA);
$display("RegA %d",RegA);
end // initial begin
endmodule // one
The above, of course currently behaves exactly as does the
previous code:
IntA -1
RegA 4294967295
The proposed change where -4'd1 is treated as 4'hf, leaves
this expression alone, the old rules apply, and hence my understanding
is that the proposal would have the first program printing
IntA 15
RegA 4294967295
and the second printing:
IntA -1
RegA 4294967295
-mac
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:40 PDT
and
sponsored by Boyd Technology, Inc.