Good State Machine Design Books on high-level design languages(HDLs)expound at great length on the construction of state machines. The results are frequently disappointing. If you define your state machine in an HDL and run your design through a synthesizer, you may find spaghetti logic that no self-respecting designer would ever put together. What's Wrong with Mealy/ Figure 2 shows that the outputs of both the mealy and Moore forms of state Moore? machine are combinatorial decodes of the current state and, in the Mealy form the inputs. While this is fine in principle, there are pitfalls here waiting to trap the The outputs of the state machine may include the following types of function Latch enables(low-or high-going pulses to open or close latches) Tristate enables(signals to turn on and off drivers onto on-chip or off-chip Register enables(enables to synchronously clocked registers) Other general control signals, such as counter enables, flags, and so on Most of these signals have one characteristic in common-glitches are abso lutely unacceptable at any time. As the state registers and inputs of the Mealy or Moore state machines transition and settle, the combinatorial gates are quite capable of generating glitches as a consequence of the varying gate propaga- tion delays. These transitory glitches may well contain enough energy to open latches, clock registers, and other highly undesirable effects Wouldn't Gray Code Fix the We all learn at an early age that gray code counters are wonderful since only one bit changes at a time When fed to an asynchronous decoder, theory sug- gests that the outputs should settle to their new state without noise. Your author is suspicious of this when the implementation is created by synthesized logic unclocked feed-forward paths might well negate the advantage of gray code There is, however, a greater challenge to the use of gray code. The sequence of transitions taken by a state machine as it does its stuff is likely to be quite elab- rate: many state machines are very complex with many branches between the possible states. Since gray code-driven decodes are only glitch free when a sin gle bit changes at each clock edge, the designer must assure that all possible state transitions result in only a single bit change of the state variable. This is practical in only the simplest of state machines A Much Better State Machine Figure 3 shows a much better design for a state machine. By adding an output register(with cleanly clocked D-type flip-flops) that is reloaded at each clock edge, the outputs of the state machine are guaranteed to be always glitch-free The Ten Commandments of Excellent DesignGood State Machine Design 6 The Ten Commandments of Excellent Design Books on high-level design languages (HDLs) expound at great length on the construction of state machines. The results are frequently disappointing. If you define your state machine in an HDL and run your design through a synthesizer, you may find spaghetti logic that no self-respecting designer would ever put together. What’s Wrong with Mealy/ Moore? Figure 2 shows that the outputs of both the Mealy and Moore forms of state machine are combinatorial decodes of the current state and, in the Mealy form, the inputs. While this is fine in principle, there are pitfalls here waiting to trap the unwary. The outputs of the state machine may include the following types of function: • Latch enables (low- or high-going pulses to open or close latches) • Tristate enables (signals to turn on and off drivers onto on-chip or off-chip buses) • Register enables (enables to synchronously clocked registers) • Other general control signals, such as counter enables, flags, and so on. Most of these signals have one characteristic in common—glitches are abso￾lutely unacceptable at any time. As the state registers and inputs of the Mealy or Moore state machines transition and settle, the combinatorial gates are quite capable of generating glitches as a consequence of the varying gate propaga￾tion delays. These transitory glitches may well contain enough energy to open latches, clock registers, and other highly undesirable effects. Wouldn’t Gray Code Fix the Problem? We all learn at an early age that gray code counters are wonderful since only one bit changes at a time. When fed to an asynchronous decoder, theory sug￾gests that the outputs should settle to their new state without noise. Your author is suspicious of this when the implementation is created by synthesized logic; unclocked feed-forward paths might well negate the advantage of gray code. There is, however, a greater challenge to the use of gray code. The sequence of transitions taken by a state machine as it does its stuff is likely to be quite elab￾orate; many state machines are very complex with many branches between the possible states. Since gray code-driven decodes are only glitch free when a sin￾gle bit changes at each clock edge, the designer must assure that all possible state transitions result in only a single bit change of the state variable. This is practical in only the simplest of state machines. A Much Better State Machine Figure 3 shows a much better design for a state machine. By adding an output register (with cleanly clocked D-type flip-flops) that is reloaded at each clock edge, the outputs of the state machine are guaranteed to be always glitch-free