| |
|
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.
References
- Chang, KC, Digital Design and Modeling with VHDL and Synthesis, IEEE
Computer Society Press.
- Green, Christian, "Analyzing and implementing
SDRAM and SGRAM controllers," EDN, Feb 2, 1998, pg 155.
|
