EmbDev.net

Forum: FPGA, VHDL & Verilog Right shift with VHDL


von Alex (Guest)


Attached files:

Rate this post
useful
not useful
So I wrote this vhdl program with the use of the Design below .I'm still 
new with VHDL and I want to have your opinions . Is what I'm writing 
correct or not ?  And I have a question about temp(3) . Should it be 0 ?

von Lothar M. (Company: Titel) (lkmiller) (Moderator)


Rate this post
useful
not useful
Alex wrote:
> So I wrote this vhdl program with the use of the Design below .
I don't see the faintest relation between the picture and your code.
The picture does not show any shift register, but instead an 
asynchronous ripple counter! Try "jk ripple counter" with google and to 
find some information.

> Is what I'm writing correct or not ?
What does the syntax checker tell about your code? What does the 
simulation show with your code? What about the clr signal? Where does it 
come from? What should happen to d with each clock? Why is there an "end 
case" midst in th code?
1
process(CLK)
2
 if (clr='1') then                      -- WARNING incomplete sensitivity list!!
3
                                        -- ERROR what the heck is "clr"?
4
    temp <= "0000";
5
    O    <= "0000";
6
  end if ;
7
 else if (clk ='1' and clk'event) then  -- ERROR due to previous end if!!
8
     --Right shift                      -- INFO: the synthesizer does not interpret comments
9
                                        -- It simply transfers the rest of the code to hardware!
10
    temp <= d;
11
    temp(2 downto 0) <= temp(3 downto 1);
12
    temp (3) <= '0';
13
    O  <= temp;
14
    end case;                           -- ERROR end of what case??
15
 end if;
16
end process;


And when I look at this code snippet I urge you to read more about the 
behaviour of signals in processes:
1
    temp <= d;
2
    temp(2 downto 0) <= temp(3 downto 1);
3
    temp (3) <= '0';
4
    O  <= temp;
That behaviour may look strange to a top-down-softeware-programmer: 
signals do NOT change their "start-values" throughout the whole process. 
And at the end of the process "the last assignment wins". So this code 
could be rearranged this way withou any chage in the result:
1
    O  <= temp;   -- the one and only assignment to O, so it could be placed anywhere
2
--    temp <= d;  -- simply delete this line. It doesn't change anything.
3
    temp(2 downto 0) <= temp(3 downto 1);   -- becaue all of temp is overwritten afterwards
4
    temp(3) <= '0';
And now the question: is that what you wanted?

> And I have a question about temp(3) . Should it be 0 ?
Maybe. Depends on the requirements.

von Alex (Guest)



Rate this post
useful
not useful
Thank you for the explanation .
So right now I think I managed to do the ripple counter but there is a 
slight problem that I didn't know the reason for .

The one with the q(3) is starting a bit later than the others and I have 
no idea why .

You can check my VHDL program and the waves below .

von Achim S. (Guest)


Attached files:

Rate this post
useful
not useful
Alex wrote:
> So right now I think I managed to do the ripple counter

So you want your ripple counter to count downwards (not upwards), don't 
you?

Alex wrote:
> The one with the q(3) is starting a bit later than the others and I have

When I simulate your code I can't see such a behaviour. Are you sure 
that the shown waveform and the shown code belong together?

von Alex (Guest)


Attached files:

Rate this post
useful
not useful
Achim S wrote:
>So you want your ripple counter to count downwards (not upwards), don't
you?

Yes and if I want to do it upwards I just switch downto to upto right ?

>When I simulate your code I can't see such a behaviour. Are you sure
that the shown waveform and the shown code belong together?

Yes I'm sure check out the screenshot . That's weird, I'm running the 
simulator on Modelsim . Which software are you using ?

von Lothar M. (Company: Titel) (lkmiller) (Moderator)


Attached files:

Rate this post
useful
not useful
Alex wrote:
> The one with the q(3) is starting a bit later than the others and I have
> no idea why .
Its not somehow "a bit later"! Its exactly at the next clk event. A 
simulator dos not do anything "a bit later", it calculates the code when 
signals change. It calculates processes when singals in the sensitivity 
list change.
And thats the trick: you are messing around with a deltacycle problem 
due to that bunch of clocks inside your process. At first glace it look 
like Q is missing in the sensitivity list, so the assignment "q_out <= 
Q;" is delaqyed until the next clk cycle, but the heck: all single bits 
of Q are in the sensitivity list. Despite that the ModeSim simulator 
stumbles badly...

Others do it better: https://www.edaplayground.com/x/23rj (see 
screenshot).

So the only solution for ModelSim may be to assign Q to q_out outside 
the process in a concurrent assignment:
1
  :
2
  :
3
        END IF;
4
--      q_out <= Q;
5
    END PROCESS;
6
7
    q_out <= Q;
8
9
END Behavioral;



What you learn from that:
never ever use multiple clocks in 1 and the same process!!!1eleven!11one
Thats ugly, bad design practice.

If I would be forced with a weapon to write such an asynchronous code 
for an FPGA (you can't convince me with money and the weapon must be a 
big and terrifying one!), then I would do that without any process:
1
LIBRARY IEEE;
2
USE ieee.std_logic_1164.ALL;
3
4
ENTITY Counter IS
5
    PORT (q_out : OUT std_logic_vector(3 DOWNTO 0);
6
          clk   : IN std_logic);
7
END ENTITY;
8
9
ARCHITECTURE Behavioral OF Counter IS
10
    SIGNAL q : std_logic_vector(3 DOWNTO 0) := "0000";
11
12
BEGIN
13
    q(0) <= not q(0) when rising_edge(clk);
14
    q(1) <= not q(1) when rising_edge(q(0));
15
    q(2) <= not q(2) when rising_edge(q(1));
16
    q(3) <= not q(3) when rising_edge(q(2));
17
    q_out <= q;
18
END Behavioral;

See https://www.edaplayground.com/x/3Hdq

BTW:
I urge you to split up your code in 2 files: a testbench module that 
generates the clock and in a counter module that simply counts.

von Lothar M. (Company: Titel) (lkmiller) (Moderator)


Rate this post
useful
not useful
Alex wrote:
> I want to do it upwards I just switch downto to upto right ?
Try it out. What happens?

I would change this to get an up counter:
1
q_out <= not q;

https://www.edaplayground.com/x/6Agh

: Edited by Moderator
von Alex (Guest)


Rate this post
useful
not useful
Thank you very much for your detailled and well explained answers .

Please log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
No account? Register here.