The creation of state machines is a mixture of art and science. A well-crafted state machine will possess a sense of elegance; it will be appealing, both functionally and visually.
Here, a very simple example is presented as an illustration of state machine design. The state diagram for the Flintstones State Machine is shown in Figure1.
The Flintstones State Machine operates as follows:
1. The State Machine has two states, State Bed and State Rock.
2. There is one output, Fred, which takes the value 0 in State Bed and 1 in State Rock.
3. A reset, caused by a low level on Reset_n, puts the State Machine into State Bed.
4. The State Machine waits in State Bed while Barney is low, and enters State Rock when Barney goes high.
5. The State Machine then waits in State Rock while Wilma is low, and returns to State Bed when Wilma goes high.
An example implementation of the Flintstones State Machine is shown below:
For the most part, the Flintstones State Machine’s operation should be clear. A few points are worth noting, however:
1. The reset signal (Sync_Reset_n) is synchronized with Clock_In before being sent to the State Machine.
2. Barney and Wilma must also be synchronous to Clock_In; at the very least, there must be an assurance that the State Machine’s state and output register’s setup and hold times are not violated.
3. This design assigns a default value to each output and to the state variable before entering the case statement. This ensures that only those signals that are not taking default (usually inactive) values need be listed in the case statement. This is optional; it is entirely reasonable to list every signal under each transition term, including inactive signals.
4. Note that the output signal Fred comes directly from a D-type flip-flop: it is not a decode of the state variable. This ensures Fred’s cleanliness (so to speak).
5. The “when others” in the case statement handles the possibility that the State Machine might end up in a dead state.