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";
I wouldn't classify 'Rule C_31' in the category of 'good' rules.There are shift operators in VHDL but they should not be used. See rule C_31 in this collection of mostly good coding 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.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.
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:C_13: Not every flip flop needs to be asynchronously reset.
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;
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;
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.C_18: There is no reason to avoid use of 'buffer' mode.
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.C_37: Nothing wrong with using procedures in RTL, but appropriate use of procedures in RTL does not come up very often.
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.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.