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?
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;