Problem with lab10 of Tutorial HDL Design with Vivado

[daniel1]

Dear all,

i despair on excersice 1.1 of lab10 from the Tutorial HDL Design using Vivado.
I have to design a sequence detector with a Mealy state machine.
Without the state machine the design works exactly like the solution (timing diagram), but with the state machine the output is always one clock period to late. The other problem is, that i have to use three process.
Can somebody please post a possible solution?
Thank you in advance.

The lab is in the attachment.

With best regards
Daniel

[dgisselq]

@daniel1 ,

That's a lot of spam across several subforums for one request.  It will be difficult to keep track of all the responses  and threads associated with your request as a result.

I have no desire to do your homework for you.  Can you instead post your (non-working) design, and perhaps someone might review it for you?

Dan

[daniel1]

I received an error message, when i made my initial post.
Because of this i tried it several times, but despite the error message the post worked.
In the mean time i deleted the others posts.

Here is my non working design in comparision to the timing diagram at the lab10 exericse pdf.

Thank you.

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.numeric_std.all;
use IEEE.std_logic_unsigned.all;
-- Uncomment the following library declaration if using
-- arithmetic functions with Signed or Unsigned values
--use IEEE.NUMERIC_STD.ALL;

-- Uncomment the following library declaration if instantiating
-- any Xilinx leaf cells in this code.
--library UNISIM;
--use UNISIM.VComponents.all;

entity fsm is
    Port ( clk : in STD_LOGIC;
           reset : in STD_LOGIC;
           ain : in  STD_LOGIC;
           LED : out STD_LOGIC_VECTOR (3 downto 0);
           LED0 : out STD_LOGIC);
end fsm;

architecture Behavioral of fsm is


type state_type is (S0,S1);
signal state, next_state : state_type;
signal wr_en : std_logic;
signal count : std_logic_vector (3 downto 0);

begin


FSM_REGISTER : process(clk, reset)

    begin
        if reset = '1' then
            count <= "0000";
            state <= S0;
            LED0 <= '0';
        elsif rising_edge(clk) then
            state <= next_state;
                
                if count = "0000" then
                    LED0 <= '1';
                elsif count = "0011" then
                    LED0 <= '1';
                elsif count = "0110" then
                    LED0 <= '1';
                elsif count = "1001" then
                    LED0 <= '1';
                elsif count = "1100" then
                    LED0 <= '1';
                elsif count = "1111" then
                    LED0 <= '1';
                else
                    LED0 <= '0';
                end if;
            
                
            if wr_en = '1' then
                if count = "1111" then
                    count <= "0000";
                else
                    count <= count + '1';
                end if;
            end if;
        end if;
        
       
end process FSM_REGISTER;

FSM_COMB : process(all)
    begin
        
               
        case state is
       
            when  S0 =>
                if ain = '1' then
                    next_state <= S1;
                else
                    wr_en <= '0';
                end if;
            
                
            when S1 =>
                if ain = '1' then
                    wr_en <= '1';
                else
                    next_state <= S0;
                end if;
                   
         end case;
end process FSM_COMB;

LED <= count;

end Behavioral;

[richardhead]

And what specifically is the problem? Your code is legal, but I can see latches will be generated for wr_en and next_state signals. These are not recommended and should be avoided.

[daniel1]

Hi,

the problem is that my output signals are delayed by one clock cycle.

Most likely this delay is based on the latches.

Can you please give me a hint how to avoid these latches?

thanks Daniel

[richardhead]

to avoid latches, ensure all signals are assigned in all branches of a non-clocked process.

[drjohnsmith]

latches are the Ban in all designs, 

  They will be warning about them in the synthesis report , 

      along with a load of other ones that are less useful.

My advise is 

a) Never do a two process state machine

b) simulate ( if you had done you would have noticed this earlier, with more ability of finding out where )

c) get a good book on VHDL  and read it.

    a free one http://freerangefactory.org/pdf/df344hdh4h8kjfh3500ft2/free_range_vhdl.pdf

[daniel1]

Hi, thank you for your answer.

You write "never do a two process state machine".

Do you mean i should do a three process state machine?

In the most books, there are shown two process state machines.

with best regards
Daniel

[richardhead]

One process state machine is the style many now recommend, as it removes the possibility of generating latches.

[drjohnsmith]

Three process is even more akin to causing errors than a two process, which is more likely to create errors than a one process.

Have you read through the book we linked to above ?

[daniel1]

Hi,

the book you linked above is very useful and there are a lot of examples regarding the state machine.

Anyway all the examples use two processes.

Now i have found a solution, which matches with the timing diagramm in the exercise.

However i have needed 16 States for the exercise, which seems a lot to me.

Thank you for your help

Daniel

[drjohnsmith · Accepted solution]

My apologies @daniel1

My memory was that book encouraged single process state machines,

An observation,

When you simulated, you did simulate ? , did you notice the counter and state chnaged in sync ?

QED, one is redundant,

I'd hope the tools will remove the redundancy, but it would be a good exercise to make it a single 

I've done a version with a single process , 

    have a look, I have not been able to test it,  as I'm on the tablet ,

There are many ways to do this exercise, 

    Id probably just used a counter and a decode, 

       but as a state machine, this is one way

[daniel1]

Hi,

thank you for your patience with me.

I have noticed that the counter and state changed in sync, but i have used 3 states because in the lab 3 states where requested.

I have looked at your version with one process and now i understand it.

I had to do a small correction, then the counter only counts up if the the input "ain" = '1', therefore i moved the "state = " in the if statement.

But i think for this lab the version with one process doesn´t work to receive exact the timing diagramm as shown in the lab10 exercise.

Because the process is only dependent of the clock, the counter will count up one clock cycle later than in the process which is dependent of the state.

But now i understand much more about FSM.

Thank you all for your help

Daniel