Substatemachine

Question

I have a FSM with 5 states. 3 of them are designed via sub-FSM(UML Pattern). For implementation in VHDL there are 2 ways, imho, to do that:

1. Summarize them into one, so I have a documentation with sub-FSM's and a product with one big FSM.

2. Build one FSM with all states. For every state which have a sub-FSM build a standalone FSM with enable signals from the big one.

This is no question about what's better, I think both ways have their advantages and disadvantages. But which way is more "clean" for VHDL implementation?

type my_big_one is (ONE,TWO_one, TWO_two, THREE_one, THREE_two, FOUR,FIVE);

vs.

type my_one is (ONE, TWO, THREE, FOUR, FIVE);
type two_fsm is (TWO_one, TWO_two);
type three_fsm is (THREE_one, THREE_two);

Answer 1

Hierarchical FSMs are also a workable solution; for example

type main_state is (ONE, TWO, THREE, FOUR, FIVE);
type inner_state is (inner_one, inner_two);
signal main  : main_state;
signal inner : inner_state;

...
case main is
when ONE => something_simple;
            main <= TWO;
            inner <= inner_one; -- reset inner SM
when TWO => case inner is
            when inner_one => ...
            when inner_two => ...
            end case;
when THREE => case inner is ...

Taken to extremes this becomes unmanageable. But if the inner state machines are relatively simple, this can be clearer and less cluttered than three separate state machines along with their handshaking, which serves no purpose other than synchronisation.

I sometimes use this pattern where for example the SM has to send a sequence of messages to a UART, and the "inner" state deals with the details of driving the UART (perhaps with a counter for characters in the message).

I wouldn't be dogmatic about which is a better solution overall, that depends on the context...

Answer 2

One good solution is to build 2 FSMs:
- the main FSM and
- the sub-FSM(s).

Both FSMs communicate via a handshake protocol.

For example the main FSM enters state TWO. While doing so, the sub-FSM starts its processing, triggered by a signal from main-FSM. When FSM TWO completes, it triggers an signal back to the main FSM, which goes to state TREE.

Using this "pattern" allows you to connect as many FSMs as needed. Some tasks like waiting or address counting can be outsourced into counters, which are just special FSMs.