EDN Access


June 4, 1998

Registered-output FSMs synchronize outputs to state transitions

Richard A Johnson, Boeing

State machines with both registered next-state transitions and registered outputs can deliver higher performance, lower power consumption, greater silicon efficiency, easier modification, and more predictable operation than traditionally coded alternatives.

Finite-state machines (FSMs) in digital-logic design are generally either Mealy or Moore machines. The only difference between these two types of machines is that the Mealy machine forms outputs derived from the inputs and the current state, and the Moore machine forms outputs derived from just the current state. However, both machines use asynchronous combinatorial logic to form the outputs, which can cause problems.

The combinatorial logic extends valid output delays beyond the clock transitions driving the state machine. Clock skew toggles state registers at different times, and mismatched signal-path lengths vary propagation delays through output decoding logic. In either case, race conditions cause glitches on machine outputs, burning unnecessary power and potentially causing invalid logic operations. Finally, if the synthesis tool dedicates an unnecessarily large portion of the ASIC or programmable-logic de-vice to the state machine and doesn't look for resource-sharing opportunities with other design entities, silicon efficiency suffers.

You can design around all of these potential Mealy and Moore FSM problems, but this work takes time, and the resolution techniques are different for each machine application. If the design is large or it changes often, such as with soft requirements or tight schedules, then problems have an increased chance of escaping detection in your presilicon simulation and early postsilicon testing.

However, if you change the FSM architecture to a registered-output machine, all of these potential problems go away (Figure 1). Each registered-output FSM isolates itself from the rest of the chip or board at the register-output boundary, and you can structurally partition the HDL code. You define state transitions in one HDL process and outputs in another, enabling easier subsequent design modifications.

For this discussion, assume that all inputs are stable at the activating edge of the state clock and output-register clock. Otherwise, you must synchronize inputs before applying them to the machine to avoid metastability problems. Notice that the registered-output FSM architecture is not just the registering of Mealy or Moore combinatorial state-machine outputs. In this case, the machine outputs would transition one clock after their associated states.

Design example

The state-transition diagram for a simple registered-output machine, which this design example implements in VHDL, includes START and CNT16 inputs (Figure 2). The machine begins in the IDLE state from a power-on asynchronous reset (/POR) and then waits in IDLE for an active START. From IDLE, the machine moves to state INIT and then to state LOOPING and waits there until input CNT16 goes active. At this point, the machine moves to state DONE and waits for START to go inactive before moving back to IDLE.

Next, turn your attention to the outputs, defined as the actions taken at each state, which are valid from the clock edge that gets the machine into the state until the clock edge that takes the machine to another state. The bits correspond to outputs INITb and ACC_EN. Because FSM registered outputs toggle at the same clock edge that transitions the machine into the associate state, analyzing the state-transition diagram is intuitive when relating it to FSM timing or sequencing during hardware debugging or simulation.

The RTL architecture partitions into four VHDL processes (Listing 1). The next_state_comb process (lines 24 to 49) defines the conditions for transitioning from the current state to the next state. Notice that next_state_comb contains no state-action assignments (outputs). The output_comb process (lines 51 to 67) defines the output-action assignments for each state. Note that the sensitivity list for the output_comb process contains only the next_state signal, declared local to the architecture and completely determined by the next_state_comb process. Therefore, the outputs associate with states, not state transitions. If you need to change the state transitions during development, but each state's outputs don't change, then you need to modify only the next_state_comb process.

The state_flops process (lines 69 to 76) describes the state register, and the output_flops process (lines 78 to 87) describes the output register. When there are many outputs, you can insert default values after line 52 before the CASE statement, and subsequently you'd need to list only the changes from the default for each transition in the output_comb process. Notice the use of internal dummy signals, iINITb and iACC_EN, to feed back the output-register values. Alternatively, you could define INITb and ACC_EN as the more cumbersome VHDL variable type BUFFER.

Logic-synthesis comparison

The logic-synthesis result for the registered-output FSM VHDL code shows that all outputs derive directly from flip-flops, and the flip-flops change to the output value associated with a state on the same clock edge that the associated state flop changes (Figure 3).

Compare this result with logic synthesized from a VHDL-coded Moore FSM (Listing 2 and Figure 4). Notice the combinatorial decoding logic between the state flip-flops and the outputs. Variations in path delays through this logic tend to produce glitches at the output in this type of design. The impact of the glitches depends on what downstream logic the outputs control and is design- and application-dependent. When you use the registered-output machine, you know that the outputs are stable. They never glitch and are always stable for one flip-flop propagation delay after the clock, as you would expect with a synchronous design methodology.


  1. Chang, KC, Digital Design and Modeling with VHDL and Synthesis, IEEE Computer Society Press.
  2. Green, Christian, "Analyzing and implementing SDRAM and SGRAM controllers," EDN, Feb 2, 1998, pg 155.

Author's biography

Richard A Johnson is an ASIC-design and -validation engineer with Boeing Information, Space and Defense Systems (www.boeing.com). He holds a BS in electrical-engineering technology from the Devry Institute of Technology (Phoenix). Johnson's hobbies include hiking and tinkering with amateur robotics.

| EDN Access | Feedback | Table of Contents |

Copyright 1998 EDN Magazine, EDN Access. EDN is a registered trademark of Reed Properties Inc, used under license. EDN is published by Cahners Business Information, a unit of Reed Elsevier Inc.