The contents of the low-order 32-bit word of a number are shifted
right, duplicating the sign-bit (bit 31) in the emptied
bits
@clk
reg A[31:0]= {A[31],A[31:1]}
"rekz" <adity...@gmail.com>
??????:ade3aa13-3209-4ba6...@x22g2000yqx.googlegroups.com...
Are you looking for the >>> operator? In reality there are many ways to
do this. The >>> operator only works if the value is signed. For
unsigned values you need to either cast it signed or resort to bit
manipulation like the previous poster showed.
Cary
>The >>> operator only works if the value is signed.
WHOAH! How many times have I ranted about this...?
Let's try again.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The >>> operator gives sign-extended shift only
if it is used in a signed EXPRESSION.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The signedness of its argument is not the whole
story. (Cary, I'm sure you are perfectly aware
of that. But it is a HUGE pitfall for novices
and I make no apology for raising it again.)
A few examples, in the form of a quiz -
answers later...
reg signed [7:0] S1;
reg signed [7:0] S2;
reg [7:0] U1; // unsigned
reg [7:0] U2; // unsigned
For each of the following examples, decide whether
the >>> operator does sign-extended (signed) or
zero-fill (unsigned) shifting:
initial begin
... <assume we have sensible values in the variables> ...
S2 = S1 >>> 3; // example 1
U1 = S1 >>> 3; // example 2
S2 = U1 + (S1 >>> 3); // example 3
U1 = S2 + (S1 >>> 3); // example 4
S2 = S1 >>> U1; // example 5
S2 = $signed(U1 >>> 3); // example 6
S2 = U1 + $signed(S1 >>> 3); // example 7
S2 = U1 + $unsigned(S1 >>> 3); // example 8
S2 = S1[7:0] >>> 3; // example 9
end
Answers below..........
(soon)
(just a few more lines down)
S2 = S1 >>> 3; // example 1
signed shift (all operands are signed)
U1 = S1 >>> 3; // example 2
signed shift (signing of assignment target
doesn't affect signedness of expression)
S2 = U1 + (S1 >>> 3); // example 3
UNSIGNED shift (operand U1 is unsigned, forces
the whole expression to be unsigned despite S1)
U1 = S2 + (S1 >>> 3); // example 4
signed shift (again U1 doesn't affect signing)
S2 = S1 >>> U1; // example 5
signed shift (unsigned shift count doesn't
affect the signed expression context)
S2 = $signed(U1 >>> 3); // example 6
UNSIGNED shift ($signed creates a signed
result, but does not affect the signing of its
argument expression)
S2 = U1 + $signed(S1 >>> 3); // example 7
signed shift ($signed, or ANY function, protects
its argument expression from the unsigned context)
S2 = U1 + $unsigned(S1 >>> 3); // example 8
signed shift ($unsigned does not affect the signing
of its argument expression)
S2 = S1[7:0] >>> 3; // example 9
UNSIGNED shift (a part select is invariably unsigned)
Glad we got that cleared up...
--
Jonathan Bromley
wait is there a >>> operation in verilog? lol.. didn't know about
that... that's what I've been looking for
>wait is there a >>> operation in verilog?
Yup, it's been there since 2001.
You did *read* the rest of my post, right? So you
know how >>> can rather easily turn around and
bite you in the arse? 'coz if you don't know those
things, you will end up with a very sore backside.
amicalement
--
Jonathan Bromley
Yes I did read your post... I think I'll avoid using the >>> then...
as the result needs to be stored in a signed variable right for this
to make it happen? While my result should be stored in a reg[31:0]
Result
> The signedness of its argument is not the whole
> story. (Cary, I'm sure you are perfectly aware
> of that. But it is a HUGE pitfall for novices
> and I make no apology for raising it again.)
Yes I probably should have said value/expression and yes I know exactly
how this works, I have two of them in the RTL for the chip we just
shipped. You also need to understand this was at the end of a 15 hour
day and my average days had not been that much shorter, so my thought
was probably a bit scattered.
For some more fun add the following after example 4 (concatenation).
S2 = U1 + {S1 >>> 3};
U1 = S2 + {S1 >>> 3};
Cary