how can i have a logical shift on std_logic_vector to left or right ??

Status
Not open for further replies.
F

fahim1

Member level 4
Joined
Jun 4, 2015
Messages
75
Helped
2
Reputation
4
Reaction score
2
Trophy points
8
Activity points
517
hi
I want to shift a std_logic_vector to left for one and two bits ,how can I do this?
 

Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10

signal my_sig : std_logic_vector (31 downto  0);
 
-- left by 1:
my_sig <= my_sig(30 downto 0) & '0';
 
-- right by 1:
my_sig <= '0' & my_sig(31 downto 1);
 
-- left by 2:
my_sig <= my_sig(29 downto 0) & "00";


But there are probably some shortcuts for the ranges that I don't know about.
 
Reactions: fahim1

    F

    fahim1

    Points: 2
    Helpful Answer Positive Rating
There are shift operators in VHDL but they should not be used. See rule C_31 in this collection of mostly good coding rules:

https://www.mikrocontroller.net/attachment/21066/VHDL_Coding_eng.pdf

What is the reason for banning integer and std_ulogic for synthesizeable code?
I think integer with a range can sometimes be motivated.

I don't know why std_logic should be avoided.
std_ulogic can reduce the debugging time by detecting multiple drivers at compile time instead of simulation or synthesis.
 

std_match said:
There are shift operators in VHDL but they should not be used. See rule C_31 in this collection of mostly good coding rules:
Click to expand...
I wouldn't classify 'Rule C_31' in the category of 'good' rules.

I agree, I always use std_ulogic so I don't waste my time debugging what the compiler would catch and it also represents more closely what actual implementation will be (i.e. a singly driven signal). So that puts 'Rule_C29' in the list of rules with which I would not agree.

Perusing their list further...
C_6: It frequently muddies the waters if you insist on only std_logic/std_logic_vector types for entity ports. For the top level entity I agree (but would use ulogic), but for embedded entities I do not agree.

C_13: Not every flip flop needs to be asynchronously reset.

C_18: There is no reason to avoid use of 'buffer' mode.

C_21: Is a pointless rule. Every compliant compiler has always flagged as an error the case where an input is unconnected with no default.

C_25: I've never seen recursive code not work. It certainly doesn't come up often and sometimes the recursive version is a bit more readable, but usually that is a wash and just somebody's preference.

C_28: While their caution regarding initialization is valid, allowing use of only std_logic, std_logic_vector, signed, unsigned types will result in less readable/supportable code. Their rule is overly restrictive for preventing the described problem. Besides, they do allow for enumerated types and they will have the same issue of initializing in sim to something that might not happen in the real part.

C_30: Do not agree. It is quite good to use record types as well as arrays of types. Even rule C_9 seems to allow for record type use, just not at a top level so they are violating rule C_30 when they allow use of a record since that is a user defined type.

C_33: Do not agree, one should use variables where it is appropriate. The only drawback I see to variables and the reason that I minimize their use is that they are not wavable in a simulation after the fact. So while I can log every signal and then add any signal in the entire system to see the total history when needed to debug a problem, you can't do that with variables without restarting the sim. Without restarting, you can see only the current value of the variable, but not the history. However, this is a limitation of the tools, not anything fundamentally wrong with variables.

C_37: Nothing wrong with using procedures in RTL, but appropriate use of procedures in RTL does not come up very often.

C_39: The gymnastics required to put "x <= y and z;" inside a sequential process makes the code harder to understand, not easier.

C_40: This rule is dated. If one uses VHDL-2008, then I do not agree since you can now say 'process(all)'. If you use an earlier language revision I do agree since it is too easy to create a latch by getting the sensitivity list wrong.

C_43: Conflicts with rule C_39 and is another example of when C_39 would not be valid.

C_45: I would say one clock per architecture, not entity. But even there, the dual clock FIFO that crosses the domains needs to go 'somewhere'.

C_47: Do not agree. It depends on the protocol of the interface of the entity. Examples of interfaces that typically require a non-clocked output are the 'waitrequest' of Avalon or 'ack' of Wishbone.

So of the 54 coding rules, I would disagree with 16 of them, but would consider the list to be a fairly decent set of guidelines overall. Also, to be fair, some of these rules may have motivated by bugs with vendor tools used by ALSE...and these rules are 10 years old so even ALSE today might not necessarily agree with everything that was written at that time.

Kevin Jennings
 

Some of the quoted coding rules are, as I think, suggested by common sense like only using named association in port maps, but others end up in negating the high level features of VHDL.

I agree that the option to use abstracted behavioral code for hardware synthesis can mislead beginners, but it's an effective means to solve complex problems and I won't give it up.
 

K-J said:
C_13: Not every flip flop needs to be asynchronously reset.
Click to expand...
I hadn't noticed it at first, but actually, the basis for rule C_13 is contained in the flawed process template presented for C_12. What was presented was:
Code: 
process (Clk, Rst) -- ONLY Clk & async Rst in the sensitivity list !
begin
    if Rst='1' then
       -- <<< all regs initialized here ! >>>
    elsif rising_edge (Clk) then
       if Enable then -- Clock enable
          -- <<< Your code here >>>
       end if; -- do NOT insert code here !
    end if; -- nor here !
end process;

However, the proper template to use is the following:
Code: 
process (Clk, Rst) -- ONLY Clk & async Rst in the sensitivity list !
begin
    if rising_edge (Clk) then
       if Enable then -- Clock enable
          -- <<< Your code here >>>
       end if; -- do NOT insert code here !
    end if; -- nor here !
    if Rst='1' then
       -- <<< all regs [COLOR="#FF0000"]that happen to need an initialization[/COLOR] here ! >>>
    end if; -- nor here !
end process;

Using the template provided in C_12, yes you can have problems if you don't put every signal inside the "if Rst='1'..." branch, so you had better follow C_13's recommendation. However, no such problems exist if you simply use the proper template. In that situation, there is no reason to follow rule C_13. So add rule C_12 to the list of things that are not correct.

Kevin Jennings
 

K-J said:
C_18: There is no reason to avoid use of 'buffer' mode.
Click to expand...
Before VHDL 2002, a "buffer" output can not be connected to an "out" output at the higher level. This is painful, especially if you are writing reusable IP-blocks.

In VHDL 2008 and later, an "out" output can be read so "buffer" is not needed.

It is still common to use VHDL-93 in projects, so I never use "buffer". The safe way that works with all VHDL versions is to use "out", and having an intermediate signal if you need to read the value.

- - - Updated - - -

K-J said:
C_37: Nothing wrong with using procedures in RTL, but appropriate use of procedures in RTL does not come up very often.
Click to expand...

One problem with procedures is that they can hide the complexity of the required logic. The source code can look simple, but the required logic could be very complex (= large and/or slow). There can be a much better way to do it, with a slightly more complicated source code. I think procedures should only be used for synthesis if the designer has a very good understanding of the required logic.

Procedures are very useful in test benches.
 

Before VHDL 2002, a "buffer" output can not be connected to an "out" output at the higher level. This is painful, especially if you are writing reusable IP-blocks.
Click to expand...

This is right regarding officially agreed language specification. But the 1999/2000 draft already suggested to release the restriction. And some tools ignored it since ever.
 

Status
Not open for further replies.

Similar threads

Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…