Encoding state machines in VHDL

Question

I'm looking into creating a system in VHDL that filters an image after receiving it through an FTDI usb-to-serial device. As part of this, I believe I've identified the states that my CPLD should be in, but I have never created a complex state machine in VHDL before, so I'm questioning whether my methods are sound. Currently, the basic outline for my state machine is thus:

begin
    process(clk, reset, USB_RXFN, USB_TXEN)
    begin
        case state is
            when IDLE =>
            when NEGOTIATING =>
            when RECEIVING =>
            when FILTERING =>
            when TRANSMITTING =>
            when OTHERS  => -- this should never happen but go to IDLE
    end process;

My problem here is that every state machine tutorial I've been able to find changes state on every rising edge (or similar, but once per clock) and this device should sit in IDLE a lot and only transition to NEGOTIATING when USB_RXFN goes low, stay in NEGOTIATING until that's done, stay in RECEIVING until the entire image has been transferred etc...

Is there something fundamentally flawed in my approach? Are CPLD's simply unsuited for this purpose? Or is it possible to stay in a state for more than a single clock and the tutorials are just written that way for simplicity?

score 3 · Accepted Answer · answered May 11 '11 at 10:36

In brief, the tutorials you've read have just been written that way for simplicity.

It's perfectly ok to wait for some event in a state before moving to another. This can be expressed in many ways in VHDL, one common way is to have both State and NextState signals, something like:

architecture foo of bar is
    type StateType is (IDLE, NEGOTIATING, RECEIVING, FILTERING, TRANSMITTING);
    signal State : StateType;
    signal NextState : StateType;
begin
    FSM: process(clk, reset)
    begin
        if reset='1' then
            State <= IDLE;
        elsif clk'event and clk='1' then
            State <= NextState;
        end if;
    end process FSM;

    STATES: process(State, USB_RXFN, USB_TXEN) -- ...
    begin
        NextState <= State; -- by default, stay in the same state (avoid a latch while you're at it)
        case State is
            when IDLE =>
                if USB_RXFN='0' then
                    NextState <= NEGOTIATING;
                end if;
            -- etc
        end case;
    end process STATES;
end foo;

score 3 · Answer 2 · answered May 11 '11 at 14:50

Yes, you can wait for any amount of time and/or input combinations that you like before moving to another state. Here's a single process example. I prefer a single process (TomiJ has shown a classic 2-process state-machine, I've reused some of it - thanks TomiJ) as it's a bit shorter and avoids inadvertently inferring latches if you miss a signal out of the sensitivity list of the "non-clocked" process.

architecture foo of bar is
begin
    FSM: process(clk, reset)
        type StateType is (IDLE, NEGOTIATING, RECEIVING, FILTERING, TRANSMITTING);
        variable state, next_state : StateType;
    begin
        if reset='1' then
            state := IDLE;
            next_state := IDLE;
        elsif rising_edge(clk) then
            case state is
                when IDLE =>
                    if USB_RXFN='0' then
                        next_state := NEGOTIATING;
                    end if;
                -- etc
            end case;
            -- Perform other logic based on state or next_state here

            -- finally update state for next time
            state := next_state;
        end if;
    end process FSM;
end foo;

It seems I can't "accept" two answers so I picked the other one on the simple merit that it was posted first, but I want to thank you for contributing anyway. — shieldfoss, May 11 '11 at 18:08

Encoding state machines in VHDL

2 Answers2