vhdl >> shift/rotate operator for std_logic_vector

by Marteno Rodia » Wed, 13 Jun 2007 04:49:51 GMT

I mean operators like ror, rol, sla, sra, srl, sll.
Are they overloaded for std_logic_vector type in any 'standard' package?

I use Altera Quartus 6.1, and I recieive a message:
"Error (10327): VHDL error at vector_selector.vhd(191): can't determine
definition of operator ""srl"" -- found 0 possible definitions".


vhdl >> shift/rotate operator for std_logic_vector

by Mike Treseler » Wed, 13 Jun 2007 05:24:26 GMT

Let's have a look at the source:

The shifts work differently for
signed vs unsigned. Thats also why sla and sra are
not defined. The vector type covers it.

But it's not hard to cast out the
numeric interpretation when the math is done:

my_slv <= std_logic_vector(my_uns_vec srl 1);

That the right answer. There is no srl defined for std_logic_vector.

-- Mike Treseler

Similar Threads

1. Left Shift / Right Shift Operators

2. Rotate operators

Hi all,

In xHarbour compiler there are left-shift(<<) and right-shift(>>) operators.
Very good. But in many implementations it can be usefull left-rotate and
right-rotate operators. Especially for data packing/crypting, because no
bit lossing occures.

Well known C compilers have not theese operators and users with assembler
practise in tears remember such good ROL and ROR assembler instructions.

What do you thing about this ?

With best regards,
also in tears

3. shift operator

4. Shift operator

Hi (again)!

Anyone knows how the vhdl shift operator (shr or shl) is implemented?
Ex: out_var := shr(inp_value,inp_shr);

Is it synthesized to a barrel shifter? I guess this requires a lot of
logic, anyone have a rough idea how much area/gates a 32-bit barrel
shifter needs? From the standard "triangle" layout, it looks like the
area grows with a factor 4, so that a 64-bit barrel shifter consumes 4
times as much hardware as a 32 bit. Anyone knows if this is correct?

Lots of questions... : )

Best regards,
Andreas Lundgren

5. bit mask using shift operator

6. Shift-operators and undefined behaviour

In article <5Zf5b.33$ XXXX@XXXXX.COM >,
 "j" < XXXX@XXXXX.COM > wrote:

> In c99 it states:
> ``The integer promotions are performed on each of the operands. The type of
> the result is
> that of the promoted left operand. If the value of the right operand is
> negative or is
> greater than or equal to the width of the promoted left operand, the
> behavior is undefined.''
> Why is the behaviour undefined if the value of the right operand is equal to
> the width of the left operand?
> That seems like it would be perfectly legal to do if the left operand is
> equal in width.

I suppose it is because the shift assembler instructions on all x86 
based computers won't do it. If x >> n is translated to a single 
assembler instruction on a Pentium, for example, then that instruction 
will only use the lowest five bits of n. 

Sad, isn't it?

7. small query on bitwise shift right operator

8. shift right operator

int a =100;
a = a>>32;
printf(" %d", a);

it prints "a" as 100 only....but I am expecting a = 0.....
can some one tell me the reason?