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 ?
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?
process(CLK) if (clr='1') then -- WARNING incomplete sensitivity list!! -- ERROR what the heck is "clr"? temp <= "0000"; O <= "0000"; end if ; else if (clk ='1' and clk'event) then -- ERROR due to previous end if!! --Right shift -- INFO: the synthesizer does not interpret comments -- It simply transfers the rest of the code to hardware! temp <= d; temp(2 downto 0) <= temp(3 downto 1); temp (3) <= '0'; O <= temp; end case; -- ERROR end of what case?? end if; end process;
And when I look at this code snippet I urge you to read more about the behaviour of signals in processes:
temp <= d; temp(2 downto 0) <= temp(3 downto 1); temp (3) <= '0'; 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:
O <= temp; -- the one and only assignment to O, so it could be placed anywhere -- temp <= d; -- simply delete this line. It doesn't change anything. temp(2 downto 0) <= temp(3 downto 1); -- becaue all of temp is overwritten afterwards 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.
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 .
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?
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 ?
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:
: : END IF; -- q_out <= Q; END PROCESS; q_out <= Q; 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:
LIBRARY IEEE; USE ieee.std_logic_1164.ALL; ENTITY Counter IS PORT (q_out : OUT std_logic_vector(3 DOWNTO 0); clk : IN std_logic); END ENTITY; ARCHITECTURE Behavioral OF Counter IS SIGNAL q : std_logic_vector(3 DOWNTO 0) := "0000"; BEGIN q(0) <= not q(0) when rising_edge(clk); q(1) <= not q(1) when rising_edge(q(0)); q(2) <= not q(2) when rising_edge(q(1)); q(3) <= not q(3) when rising_edge(q(2)); q_out <= q; 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.
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:
q_out <= not q;
: Edited by Moderator
Thank you very much for your detailled and well explained answers .