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.

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.

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