Hardware Reference
In-Depth Information
Hardware- versus Software-Implemented State Machines
Designing and implementing correct state machines in hardware is generally (much)
more complex than doing it in software. Some of the reasons for that are listed below.
1) It is physically impossible for the clock signal to arrive at all chip locations at
exactly the same time (this is called clock skew), so some l ip-l ops will be activated
before others, a concern that simply does not exist in software.
2) A naive design in hardware might lead to the inference of latches, which impair
the time response. It might also lead to the other extreme, which consists of reregister-
ing one or more signals, causing unwanted latency.
3) In hardware, signals might be subject to glitches, another concern that does not
occur in software.
4) Contrary to software, hardware allows no abstraction. For example, if a state
machine must produce in the next state the same output value produced in the current
state, in software we can simply omit the corresponding expression; or if it requires
an incrementer, we can simply write
x
=
x
+ 1. In either case, an explicit expression
would be required in hardware (
x
=
x
or
x
=
x
+ 1), which can only be evaluated if the
value of
x
is available, so the machine itself must provide a means for storing (and
properly retrieving)
x
.
5) In hardware, signals represent physical wires, so we cannot assign a signal source
to an interconnection now and simply assign another later.
6) Many machines have asynchronous inputs, so the use of synchronizers (to avoid
l ip-l op metastability) must be considered, another concern that does not occur in
software-implemented FSMs.
7) Some circuits need a special clock, obtained by “gating” the main clock. Depending
on how it is done, the resulting clock might be subject to glitches, another issue that
simply does not exist in software.
8) Several other concerns, such as “reset generation,” “capturing the i rst bit,” “keeping
the i nal result stable,” and “stretching the decision pulse”, are also not a problem in
software-implemented machines.
1.3 State Transition Diagrams
The
state transition diagram
(or simply
state diagram
) of a sequential circuit is a graphi-
cal representation of its functional specii cations. Such a diagram must obey three
fundamental principles:
1) It must include all possible system states.
2) All state transition conditions must be specii ed (unless a transition is uncondi-
tional) and must be truly complementary.
3) The list of output signals must be exactly the same in all states (for a standard
architecture implementation).
