Anda di halaman 1dari 17

Topic 4 SM Charts and the Dice Game Alternatives for Control Unit Code: Dataflow, Microprogram, Behavioral SM Charts

An SM (state machine) chart is a flowchart-like description of a sequential circuit.

(Figure 5-1, p. 261, Digital Systems Design, 2nd ed., C. Roth.) Lets draw an SM chart for our stopwatch.

Dice Game We will use the dice game popularly known as craps to demonstrate how to come up with an SM chart, translate it to VHDL, and come up with several alternative control unit implementations. Two six-sided dice are used in the game. The player rolls the dice and wins or loses based on the sum of the numbers on the dice. On the first roll, o a sum of 7 or 11 results in a win, o a sum of 2, 3, or 12 results in a loss, o any other sum results in further rolls to determine win or loss. The sum on this first roll is called the point, and will be needed to determine win or loss on subsequent rolls. On subsequent rolls, o a sum equal to the point results in a win, o a sum of 7 results in a loss, o any other sum results in another roll.

The textbook uses the following hardware setup for implementation of the game:

(Figure 5-11, p. 267, Digital Systems Design, 2nd ed., C. Roth.)

SM Chart for Dice Game Control Unit

((Figure 5-13, p. 270, Digital Systems Design, 2nd ed., C. Roth.)

Dataflow VHDL Model for State Machine The SM chart can be translated into VHDL code in a systematic way. Following what we learned in EE 2901, we could represent each state with a binary number (using straight binary encoding or one-hot encoding), and create a table that shows, for each combination of inputs and current state, what the outputs and next state should be. We would then come up with Boolean functions for each next state bit and each output, (or we could enter the table directly into VHDL, which is essentially the microcode approach we will discuss later), to create a combinational circuit as shown below. The current state would be saved in a register. As we discussed in previous topics, we separate the combinational logic from the sequential elements, and keep the process statement as clean as possible.

. (Figure 5-23, p. 279, Digital Systems Design, 2nd ed., C. Roth.) Section 5.4 of the textbook contains the details of the combinational circuit/register implementation of the dice game controller. The Boolean functions are provided on page 281.

Dataflow VHDL Code When we use this approach to create a state machine in VHDL, the result is called a dataflow model. This is in contrast to our VHDL code involving if-then statements, which does not use hardware models such as flip-flops and Boolean functions. Here is a dataflow VHDL model for the dice game, given on page 282 of the textbook.
entity DiceGame is port(Rb, Reset, CLK: in bit; Sum: in integer range 2 to 12; Roll, Win, Lose: out bit); end DiceGame; architecture Dice_Eq of DiceGame is signal Sp,Eq,D7,D711,D2312: bit:='0'; signal DA,DB,DC,A,B,C :bit:='0'; signal Point: integer range 2 to 12; begin process(CLK) The process statement models the begin D flip-flop state register and the if CLK = '1' and CLK'event then point register. A <= DA; B <= DB; C <= DC; if Sp = '1' then Point <= Sum; end if; end if; end process; The combinational part of the circuit is given here, using Win <= B and not C; Boolean functions. Or, one could give the transition table Lose <= B and C; using a select statement. Roll <= not B and C and Rb; Sp <= not A and not B and C and not Rb and not D711 and not D2312; D7 <= '1' when Sum = 7 else '0'; D711 <= '1' when (Sum = 11) or (Sum = 7) else '0'; D2312 <= '1' when (Sum = 2) or (Sum = 3) or (Sum = 12) else '0'; Eq <= '1' when Point=Sum else '0'; DA <= (not A and not B and C and not Rb and not D711 and not D2312) or (A and not C) or (A and Rb) or (A and not D7 and not Eq); DB <= ((not A and not B and C and not Rb) and (D711 or D2312)) or (B and not Reset) or ((A and C and not Rb) and (Eq or D7));
DC <= (not B and Rb) or (not A and not B and C and not D711 and D2312) or (B and C and not Reset) or (A and C and D7 and not Eq);

end Dice_Eq;

Microprogrammed VHDL Model for State Machine When using VHDL, it is not absolutely necessary to come up with Boolean functions to compute the next state and outputs in a state machine, because the state transition truth table can be entered directly using selective signal assignment (a select statement). This is the basic idea behind a microprogrammed control unit. The microprogramming method uses a ROM that contains microcode. Each state has an associated line of microcode that contains the two possible next states, and the test condition that decides which state to go tosimilar to a truth table, but organized in a way that takes up less space in a ROM. Microprogramming Hardware Setup

(Figure 5-29, p. 286, Digital Systems Design, 2nd ed., C. Roth.) The hardware setup for a microprogrammed state machine typically consists of the following parts: Register, which holds the current state A MUX to multiplex condition signals. Instead of having a separate column for each input, like a normal transition table, the microprogramming method saves space in the ROM by having a TEST field that specifies which of the inputs will be used to make the decision about which state is next. For example, the dice game has six signals that could determine the next state: Rb, D711, D2312, Eq, D7, and Reset. The TEST field is the code number of the signal that is the criterion

for this next state decision. We will discuss the role of the TEST field and the MUX in detail in the pages to follow. A MUX to multiplex the two possibilities for the next state. The condition signal output by the previous MUX decides which next state address passes through. The NSF (next state false) address passes through if the condition is false (logic 0) , and the NST (next state true) passes through if the condition is true (logic 1). Microprogram ROM, which stores the microcode. The lines of microcode in the ROM are addressed by the state number. So, the register which holds the current state is attached to the address input of the ROM, which makes the microcode line associated with that state appear at the ROM output. Each line of microcode contains the fields TEST, NSF, NST, and OUTPUT, which is the output associated with the current state. Note that this implies we are working with a Moore machine, where the output depends only on the current state.

Modifications to SM Chart for Microprogramming In order to microprogram a state machine using this setup, we must convert the Mealy state machine already given for the dice game to a Moore machine. A Mealy machine will have conditional outputs that appear on a path (not in a state). To convert the Mealy machine to Moore, we take each conditional output and replace it with an extra state, whose only purpose is to produce that output. The next modification that needs to be made in order to adapt the SM chart to microprogramming has to do with the decision boxes. Recall that we have a special TEST field that chooses one decision condition which will determine our next state either NSF, if that one condition is false, or NST, if it is true. So, we need to modify the paths between states which have more than one decision box, since we cant make multiple decisions and have three or more possible next states. To fix this problem, all we need to do is insert a new state between decision boxes. To illustrate both of these modifications, here are the SM charts for the Dice Game, before and after modification.

(Figure 5-13, p. 270, Digital Systems Design, 2nd ed., C. Roth.)

(Figure 5-36, p. 293, Digital Systems Design, 2nd ed., C. Roth.)

State Assignment Each state has to have a state numbeR. The states can be numbered any way you like, as long as each state has a unique address. The previous figure has addresses assigned to the states. (Note that there is a special type of microprogramming called single-address microprogramming, which places more restrictions on the numbering of states. We will discuss this later in this packet.) Test Condition Encoding Before we write the microcode, we need to set up the MUX that will allow the TEST field to select the test condition signal. To do this, we look at all the decision boxes in our SM chart, and make a list of the signals inside the boxes. This will tell us how large our MUX needs to be. For our example, there are 6 condition signals, so an 8-to-1 MUX will suffice. This also tells us that the TEST field will have 3 bits (the size of the MUX select).

zz (Figure 5-37, p. 294, Digital Systems Design, 2nd ed., C. Roth.)

.Writing the Microcode To create the line of microcode for a state, we need to list the test conditions, next state addresses, and outputs associated with that state. Lets write the line for the first state, 0000. We refer to the SM chart to get the information. Address = 0000 The state box indicates that none of the outputs are turned on. The condition signal that determines our next state is Rb. We need to look at the MUX to see which line Rb is on. Rb is on line 1, so TEST = 001. We go to state 0000 if Rb is false, and state 0001 if Rb is true. So, the following line of microcode is stored in the ROM at address 0000: TEST NSF NST OUTPUT (Roll, Sp, Win, Lose) 001 0000 0001 0 0 0 0 This procedure can be repeated to come up with the entire microprogram:

(Table 5-6, p. 294, Digital Systems Design, 2nd ed., C. Roth.)

Output Encoding The OUTPUT field of the microcode sets the output signal for that state. We currently have the OUTPUT field connected directly to the output signals. In this situation, our OUTPUT field would have to be large enough to set every output bit. If we have one-hot outputs (i.e., only one output is turned on at a time), encoding the outputs may save space in the ROM. The OUTPUT field would then be attached to a combinational circuit that decodes the output. In the dice game example, there are four outputs, Win, Lose, Roll, and Sp. We could think about encoding the output, since only one of the outputs is turned on at any given time. It is also possible that none of the outputs are turned on. This gives 5 possibilities for the output. We would need 3 bits to represent all the possibilities. Since this saves us only 1 bit, it might not be worth it to add the extra decoding hardware. Single-Address Microprogramming We can save some space in the ROM by encoding the states such that the NSF (next state if false) is always the next line in the ROM. Then, the controller will jump to the NST state if the test condition is true, and otherwise, it will just move to the next line. The NSF field is not needed. This is a popular microprogramming system; each instruction executes a branch if equal command. In order to accomplish this, more modifications need to be done to the SM chart. We need to change the encoding so that when we follow the 0 paths of the decision boxes, we are incrementing the state number by 1. We can do this by giving the first state the address zero, and then follow the 0 paths to assign state addresses in sequence. We run into trouble when we backtrack, that is, when the 0 path leads us to a state that already has a number. One option is to complement the condition signal, so we backtrack on a 1 path, which is legal. However, if both the 0 and 1 paths backtrack to states that already have numbers, we have a problem. In this case, we need to insert a state, called an X-state. Then we can backtrack using the 1 path from the original state, and the 1 path from the Xstate.

For more details on this method, consult Section 5.5 of the textbook. In lab, we will implement the dice game using microprogramming. You may use the ordinary twoaddress microprogramming, or single address microprogramming. If you wish to use single-address microprogramming, here are the modified microinstructions and SM chart.

(Figure 5-39 and Table 5-7, p. 296, Digital Systems Design, 2nd ed., C. Roth.)


(Figure 5-38, p. 295, Digital Systems Design, 2nd ed., C. Roth.)


Behavioral VHDL Model for State Machine Behavioral VHDL describes the operation of a circuit using high-level language, and the compiler translates the requirements into hardware. The following example, from pages 271-272 in the textbook, uses two separate processes: one clean process to describe the writing of the state into memory, and another process to set up the next state and output. Watch Out for Inferred Latches The textbook authors are very careful when they create the process that sets up the next state and output. Every signal and output that comes from combinational logic must be explicitly assigned a value every time the process runs. If you have a signal or output that does not get a new value during a run of the process, then that signal or output is assumed to have memory, which is bad if that is not what you intended. When this happens, the compiler typically gives you an inferred latch warning, so be on the lookout for these! Lets examine how the authors set up their process so that this doesnt happen. The only things that should be saved in the dice game are the current state and the point value. These are given by State and Point in the code that follows. Note that those values are written in the clean process that is only responsible for writing these new values on the clock edge. This process represents the memory portion. The other signals and outputs, Roll, Win, Lose, Nextstate, and Sp should not have memory. We want the first process, the one that determines their values, to be purely combinational. To do this, we need to make sure that all of these variables are explicitly assigned new values every time the process runs. Note that the code assigns default values to Roll, Win, Lose, and Sp right after the begin statement. The authors then use a case statement to determine what the value of Nextstate should be. In every case, Nextstate is given a value. You can see that the case statement works pretty much the same as it does in any other structured programming language; the statement begins with case State is which means that State will determine which of the following when clause gets executed.

As long as you are careful about the unintended memory, this method of coding state machines can be easy and intuitive. Once you have created the SM chart, you can put it directly into a case statement as follows: 1) Before the beginning of the case statement, give default values to all of the signals and outputs that should not have memory. 2) Determine how many states there are. The State signal can be an integer with range 0 to n-1, where n is the number of states. (It is best to start with zero, since that is probably the power-on value of the state register.) Begin the case statement. 3) Create a when clause for each state, which will assign the output values and next state. You can use if-then-else statements. Make sure the nextstate is assigned. You can use this code as a template for your state machine until you get comfortable with this type of coding. Behavioral VHDL Code entity DiceGame is port(Rb, Reset, CLK: in bit; Sum: in integer range 2 to 12; Roll, Win, Lose: out bit); end DiceGame; architecture DiceBehave of DiceGame is signal State, Nextstate: integer range 0 to 5; signal Point: integer range 2 to 12; signal Sp: bit; begin process(Rb, Reset, Sum, State) begin Sp <= '0'; Roll <= '0'; Win <= '0'; Lose <= '0'; case State is when 0 => if Rb = '1' then Nextstate <= 1; end if; The first process contains the if-then statements that decide the next state.

when 1 => if Rb = '1' then Roll <= '1'; elsif Sum = 7 or Sum = 11 then Nextstate <= 2; elsif Sum = 2 or Sum = 3 or Sum =12 then Nextstate <= 3; else Sp <= '1'; Nextstate <= 4; end if; when 2 => Win <= '1'; if Reset = '1' then Nextstate <= 0; end if; when 3 => Lose <= '1'; if Reset = '1' then Nextstate <= 0; end if; when 4 => if Rb = '1' then Nextstate <= 5; end if; when 5 => if Rb = '1' then Roll <= '1'; elsif Sum = Point then Nextstate <= 2; elsif Sum = 7 then Nextstate <= 3; else Nextstate <= 4; end if; end case; end process; process(CLK) begin if CLK'event and CLK = '1' then State <= Nextstate; if Sp = '1' then Point <= Sum; end if; end if; end process; end DiceBehave;

The second process actually makes the transition occur in synchrony with the clock edge.