Classical Problems and Mistakes

4.2.1 Skipping the State Transition Diagram

Probably the most error-prone step in the design of a circuit based on the state machine approach is to think that it is fi ne to go straight from the specifi cations to the design without sketching the state transition diagram (students sometimes believe that they can “ see ” the state diagram in their minds). With this approach, states can be missed, or, more likely, output values and state transitions may be ill specifi ed. This step is critical because any error in the state transition diagram will invalidate the whole effort, no matter how well the rest is done.

4.2.2 Wrong Architecture

Once one has been convinced that sketching the state transition diagram is indispens-able, the next step is not to draw it but fi rst to decide which type the machine archi-tecture should be used (a major mistake is to think that all machines are “ just the same ” ). A great effort has been made in this book to show that, when one is using hardware (as opposed to software) to implement an FSM, the circuit architecture can vary substantially from one problem to another. For that reason, a classifi cation into three categories, which covers any state machine, was introduced in section 3.6 (see fi gure 3.8 ), as follows: category 1 for regular state machines; category 2 for timed state machines; and category 3 for recursive state machines.

The fi rst decision is to select correctly in which of these categories the machine to be designed falls. That not only will lead to the right circuit (optimal resources usage)

74 Chapter 4

but will also immensely reduce the design effort. The second important decision is to choose between the corresponding Moore and Mealy architectures. The third and fi nal architectural decision is whether to include or not in the FSM the optional output register ( fi gure 3.2b ).

4.2.3 Incorrect State Transition Diagram Composition

As seen in section 1.3, the state diagram must obey three fundamental principles:

1) It must include all possible system states.

2) All state transition conditions must be specifi ed (unless a transition is uncondi-tional), and such conditions must be truly complementary.

3) The list of output signals must be exactly the same in all states (standard architecture).

Failing to comply with requisite 1 above will lead inevitably to an incorrect circuit.

Even though this seems an obvious step, there are situations in which subtle details are involved, such as the inclusion of wait states to hold until the data to be inspected is ready (as in fi gure 3.25, for example) or to suppress state bypass (as in fi gure 4.2 , for example).

Condition 2 above requires that the complete set of transition conditions be neither under- nor overspecifi ed; otherwise, a poor or incorrect circuit will again result. This is a relatively common error that can be avoided by following the material seen in section 1.5.

Finally, requisite 3 determines that, for hardware implementations, the list of outputs must be exactly the same in all states; otherwise, latches will be inferred, wasting resources and making the time response less predictable. Because this is by far the most common mistake, an example is provided in fi gure 4.1 . In fi gure 4.1a , y is not specifi ed in state B. If this lack of specifi cation is the result of careless analysis, an incorrect circuit will probably be implemented; otherwise, if the missing specifi cation is because y should keep in state B the same value that it had when the FSM left state A, then y = y should be entered, as depicted in fi gure 4.1b , making the list of outputs exactly the same in all states and also clarifying what is indeed wanted for y .

Figure 4.1

(a) State diagram with incomplete output specifi cations. (b) Corrected state diagram.

Design Steps and Classical Mistakes 75

4.2.4 Existence of State Bypass

The state-bypass problem occurs when the transition conditions for entering a state coincide with the transition conditions for leaving that same state, and such condi-tions are true during more than one clock cycle.

As an example, consider the car alarm of fi gure 4.2a . If the alarm is in the disarmed state and a command from the remote control ( remote = ‘ 1 ’ ) is received, the machine passes to the armed state, ready to detect any intrusions. However, if the remote = ‘ 1 ’ command lasts several clock cycles (as is generally the case) and the intrusion sensor is off ( sensor = ‘ 0 ’ ), the circuit goes back to disarmed , then returns to armed , and so on, producing a kind of state bypass (in fact, the states are not exactly bypassed, but rather, the machine remains in each state for just one clock period instead of staying there).

Note that in this example state bypass occurs even when sensor = ‘ 1 ’ .

This problem can be solved with some kind of fl ag or, more clearly, with wait states, as in fi gure 4.2b (white circles). Note that the wait1 and wait2 states wait until remote returns to zero before allowing any other action to take place.

The failure to prevent state bypass can lead to a circuit with occasional malfunc-tioning that is very diffi cult to locate later. This is especially true when the state bypass can only occur in very particular situations, which might have been overlooked in the simulations and therefore remained undetected during the design phase.

4.2.5 Lack of Reset

In the design of any FSM the need for reset must always be considered (only few cases are fi ne without an explicit reset port). Failing to do so can cause incorrect machine initialization or even deadlock. A detailed analysis on the use of reset and its conse-quences was presented in sections 3.8 and 3.9.

Figure 4.2

Car alarm (a) with and (b) without state bypass.

76 Chapter 4

4.2.6 Lack of Synchronizers

Many FSMs have asynchronous inputs, so metastability can occur if synchronizers are not employed. Failing to analyze whether asynchronous signals are involved in the design and the possible consequences of metastability to that particular application can compromise the entire project. Material on the use and construction of synchro-nizers and their consequences was presented in section 2.3.

4.2.7 Incorrect Timer Construction

Many engineering problems include timed decisions, leading to state machines with time as a transition condition (see fi gure 1.8). Because timers are just counters (therefore sequential circuits, which can then also be modeled as state machines), one might be tempted to use the FSM approach to design them. There are two main reasons for not doing so in general. The fi rst is that counters are standard circuits, easily designed without the FSM approach. The second is that a counter might have thousands of states and therefore would be impractical to represent as a regular state machine.

The recommended approach in such cases is to consider the timer (counter) as an auxiliary circuit, implemented separately and acting as an input to the (main) state machine. However, the state machine itself must be responsible for clearing the timer at the proper moments as well as for stopping it or letting it run as needed. Such fi ne details, sometimes overlooked, are fundamental to attain a correct and optimized design. Such aspects are studied in chapter 8, which deals specifi cally with timed state machines, and are reinforced in chapters 9 and 10, which show VHDL and System-Verilog implementions for timed FSMs.

4.2.8 Incomplete VHDL/SystemVerilog Code

Once the state transition diagram has been correctly and completely constructed, we can write a corresponding VHDL or SystemVerilog code to synthesize the circuit. The problem is that here too the coverage of specifi cations might not be complete, even if the state diagram is complete. Two common mistakes are described below, both related to the combinational logic section of the FSM (more precisely, related to req-uisites 2 and 3 listed in section 4.2.3).

The fi rst mistake regards incomplete output specifi cations. One might believe that when something was said in a previous state and nothing occurred there is no need to say it again. For example, consider that we are using VHDL and the case statement to implement the combinational logic section of an FSM as follows (do not worry about code details for now; they are seen in chapter 6):

--Bad: --Good:

case pr_state is case pr_state is

when A = > when A = >

Design Steps and Classical Mistakes 77

Note in the code on the left that from state A the machine can only go to state B.

If the desired value for output1 while in B is the same as that in A, one might be tempted to omit it in state B. Recall, however, that the upper section of an FSM is combinational (thus memoryless), so there is nothing to prevent its output from chang-ing when the machine leaves a state. For cases like the code above, the compiler will generally infer latches, guessing that the designer wanted the machine to keep the same value that it had in the previous state, which can produce an unsafe behavior because the timing response of latches (built with regular gates) is diffi cult to predict and is subject to race conditions.

In summary, it is important to remember what was said earlier: the list of outputs must be exactly the same in all states (so in this example it must contain output1 and output2 in all states, as shown in the code on the right).

The second mistake regards incomplete transition conditions specifi cations. For example, consider again that we are using VHDL and the case statement to implement the combinational logic section of an FSM as follows:

--Moore machine: --Mealy machine:

case pr_state is case pr_state is

Both codes above are correct. Note that in both the if statement includes an else part, which takes care of all remaining options. If this else were omitted, an

78 Chapter 4

underspecifi cation would occur, and the compiler might again infer unnecessary (and undesirable) latches.

4.2.9 Overregistered VHDL/SystemVerilog Code

This is another common mistake. It is very important to be aware of the code sections that infer registers and close such sections as soon as registers are no longer needed.

An example is shown below, using VHDL. Any signal to which a value is assigned under the if rising_edge(clk) statement will be registered, so that if must be closed as soon as possible. The code on the left is constructed correctly. Note that the only assignment under the if rising_edge(clk) statement is pr_state < = nx_state , so only the machine state gets registered. Because the case statement used for the upper section is outside that if statement, no fl ip-fl ops will be inferred for that part of the machine, resulting in a truly combinational circuit for the upper section, which is how it should be.

The code on the right, on the other hand, is an example of an error-prone design.

Note that now the case statement is inside the if rising_edge(clk) statement, so the output will also be registered. As we have already seen, there are cases in which the optional output register is needed, but that is a case-by-case decision, not a forced condition as it is in this code. Probably the worst aspect of this code is that the designer might be completely unaware of what is actually happening. (Note that pr_state has no effect in this process ’ sensitivity list.)

--Good: --Error prone:

--lower section of FSM: process (clk, pr_state)

process (clk) begin

begin if rising_edge(clk) then

if rising_edge(clk)then --lower section of FSM:

pr_state < = nx_state; pr_state < = nx_state;

Design Steps and Classical Mistakes 79