Question about arithmetic right shift with sign extension
pallav
right shift. But how does it work? I was implementing a shifter unit
as part of an ALU. I had done the following:
assign #1 rarithmetic = b >>> shiftamount;
where b and shiftamount were both input [31:0] vectors. However, the
sign extension does not occur. I had b = 0xd1200000 and the result was
0x0000d120 instead of 0xffffd120. I know there is also the "signed"
keyword but it didn't seem to have any effect when I tried "input
signed [31:0] ...". What am I doing wrong? Would synthesis results be
different if "signed" keyword is used?
In the end, I just end up coding up a variable 32 bit sign extension
shifter as shown below. Is there a better/more compact way to do the
same thing? I'd like to keep it synthesizable if possible. Thanks for
any help.
Kind regards.
/*
* 32-bit sign extend shifter
*/
module signextshifter32(/*AUTOARG*/
// Outputs
y,
// Inputs
a, shiftamt
);
input [31:0] a; // input
input [4:0] shiftamt; // shift amount
output [31:0] y; // output
assign #1 y = (shiftamt == 5'b00000) ? {a[31:0]} :
(shiftamt == 5'b00001) ? {{1{a[31]}}, a[31:1]} :
(shiftamt == 5'b00010) ? {{2{a[31]}}, a[31:2]} :
(shiftamt == 5'b00011) ? {{3{a[31]}}, a[31:3]} :
(shiftamt == 5'b00100) ? {{4{a[31]}}, a[31:4]} :
(shiftamt == 5'b00101) ? {{5{a[31]}}, a[31:5]} :
(shiftamt == 5'b00110) ? {{6{a[31]}}, a[31:6]} :
(shiftamt == 5'b00111) ? {{7{a[31]}}, a[31:7]} :
(shiftamt == 5'b01000) ? {{8{a[31]}}, a[31:8]} :
(shiftamt == 5'b01001) ? {{9{a[31]}}, a[31:9]} :
(shiftamt == 5'b01010) ? {{10{a[31]}}, a[31:10]} :
(shiftamt == 5'b01011) ? {{11{a[31]}}, a[31:11]} :
(shiftamt == 5'b01100) ? {{12{a[31]}}, a[31:12]} :
(shiftamt == 5'b01101) ? {{13{a[31]}}, a[31:13]} :
(shiftamt == 5'b01110) ? {{14{a[31]}}, a[31:14]} :
(shiftamt == 5'b01111) ? {{15{a[31]}}, a[31:15]} :
(shiftamt == 5'b10000) ? {{16{a[31]}}, a[31:16]} :
(shiftamt == 5'b10001) ? {{17{a[31]}}, a[31:17]} :
(shiftamt == 5'b10010) ? {{18{a[31]}}, a[31:18]} :
(shiftamt == 5'b10011) ? {{19{a[31]}}, a[31:19]} :
(shiftamt == 5'b10100) ? {{20{a[31]}}, a[31:20]} :
(shiftamt == 5'b10101) ? {{21{a[31]}}, a[31:21]} :
(shiftamt == 5'b10110) ? {{22{a[31]}}, a[31:22]} :
(shiftamt == 5'b10111) ? {{23{a[31]}}, a[31:23]} :
(shiftamt == 5'b11000) ? {{24{a[31]}}, a[31:24]} :
(shiftamt == 5'b11001) ? {{25{a[31]}}, a[31:25]} :
(shiftamt == 5'b11010) ? {{26{a[31]}}, a[31:26]} :
(shiftamt == 5'b11011) ? {{27{a[31]}}, a[31:27]} :
(shiftamt == 5'b11100) ? {{28{a[31]}}, a[31:28]} :
(shiftamt == 5'b11101) ? {{29{a[31]}}, a[31:29]} :
(shiftamt == 5'b11110) ? {{30{a[31]}}, a[31:30]} : {31
{a[31]}};
endmodule
Muzaffer Kal
<palla...@gmail.com> wrote:
>where b and shiftamount were both input [31:0] vectors. However, the
>sign extension does not occur. I had b = 0xd1200000 and the result was
>0x0000d120 instead of 0xffffd120. I know there is also the "signed"
>keyword but it didn't seem to have any effect when I tried "input
>signed [31:0] ...". What am I doing wrong? Would synthesis results be
>different if "signed" keyword is used?
>
>In the end, I just end up coding up a variable 32 bit sign extension
>shifter as shown below. Is there a better/more compact way to do the
>same thing? I'd like to keep it synthesizable if possible. Thanks for
>any help.
>
>Kind regards.
module signextshifter32(
input signed [31:0] a,
input [4:0] shiftamt; // shift amount
output signed [31:0] y)
assign y = a >>> shiftamnt;
endmodule
I am not sure what you're doing wrong because you don't post your code
with the signed keyword but the above should work for both simulation
and synthesis the same way.
Muzaffer Kal
DSPIA INC.
ASIC/FPGA Design Services
http://www.dspia.com
pallav
> On Wed, 29 Apr 2009 21:12:55 -0700 (PDT), pallav
>
Hi Muzaffer,
Thank you for your response. I tried the code that you posted on
two different simulators: Icarus Verilog and Synopsys VCS.
On Icarus Verilog I got the wrong answer (zero extension) while
Synopsys VCS gave the
correct answer (sign extension). So it looks like there is a bug on
Icarus Verilog
and I was trying all my experiments on that! I'll file a bug report
for that.
So it looks like my problem is solved. Thanks.
Kind regards.
jprov...@yahoo.com
I tried the code using Veritak and, after fixing a couple of typos
in the suggested module, got the expected results, ie, signed shifting
works as expected.
John Providenza
sh...@cadence.com
> I understand Verilog 2001 added the ">>>" operator for sign extension
> right shift. But how does it work?
The ">>>" operator is not specifically an arithmetic or sign-extension
shift. It is an arithmetic shift in a signed expression, and a
logical shift in an unsigned expression. It is basically what the
">>" should have been, except that ">>" had to continue always being a
logical shift for backward compatibility reasons. So if you want to
use ">>>" as a signed shift, you will need to make sure that its
operand is signed.
> I was implementing a shifter unit
> as part of an ALU. I had done the following:
>
> assign #1 rarithmetic = b >>> shiftamount;
>
> where b and shiftamount were both input [31:0] vectors.
You will have to declare b to be signed, or convert it to signed with
the $signed() function. The signedness of shiftamount doesn't matter.
> However, the
> sign extension does not occur. I had b = 0xd1200000 and the result was
> 0x0000d120 instead of 0xffffd120. I know there is also the "signed"
> keyword but it didn't seem to have any effect when I tried "input
> signed [31:0] ...".
That should work.
> What am I doing wrong?
I don't know, without a more specific example.
> Would synthesis results be
> different if "signed" keyword is used?
Yes, if the synthesis tool is correct.
> In the end, I just end up coding up a variable 32 bit sign extension
> shifter as shown below. Is there a better/more compact way to do the
> same thing? I'd like to keep it synthesizable if possible. Thanks for
> any help.
There are tricky ways to do sign extension without hardcoding all the
cases, even without an arithmetic right shift. Make a word that is 32
copies of the sign bit, then shift it left by 32-shiftamount and OR it
with your logically shifted value.