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, 2 nd ed., C. Roth.) Let’s draw an SM chart for our stopwatch.

Dice Game

  • Upload
    duy-le

  • View
    263

  • Download
    1

Embed Size (px)

Citation preview

Page 1: Dice Game

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.)

Let’s draw an SM chart for our stopwatch.

Page 2: Dice Game

2

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.)

Page 3: Dice Game

3

SM Chart for Dice Game Control Unit

((Figure 5-13, p. 270, Digital Systems Design, 2nd

ed., C. Roth.)

Page 4: Dice Game

4

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.

Page 5: Dice Game

5

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)

begin

if CLK = '1' and CLK'event then

A <= DA; B <= DB; C <= DC;

if Sp = '1' then Point <= Sum; end if;

end if;

end process;

Win <= B and not C;

Lose <= B and C;

Roll <= not B and C and Rb;

Sp <= not A and not B and C and not Rb and not D7 11 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 D 711 and not D2312)

or (A and not C) or (A and Rb) or (A and no t D7 and not Eq);

DB <= ((not A and not B and C and not Rb) and (D7 11 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 a nd not D711 and D2312) or

(B and C and not Reset) or (A and C and D7 and not Eq);

end Dice_Eq;

The process statement models the

D flip-flop state register and the

point register.

The combinational part of the circuit is given here, using

Boolean functions. Or, one could give the transition table

using a select statement.

Page 6: Dice Game

6

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 to—similar 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

Page 7: Dice Game

7

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 can’t 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.

Page 8: Dice Game

8

(Figure 5-13, p. 270, Digital Systems Design, 2nd

ed., C. Roth.)

Page 9: Dice Game

9

(Figure 5-36, p. 293, Digital Systems Design, 2nd

ed., C. Roth.)

Page 10: Dice Game

10

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.)

Page 11: Dice Game

11

.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. Let’s 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.)

Page 12: Dice Game

12

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 X-

state.

Page 13: Dice Game

13

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 two-

address 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.)

Page 14: Dice Game

14

(Figure 5-38, p. 295, Digital Systems Design, 2nd

ed., C. Roth.)

Page 15: Dice Game

15

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!

Let’s examine how the authors set up their process so that this doesn’t 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.

Page 16: Dice Game

16

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; en d if;

The first process contains the

if-then statements that decide

the next state.

Page 17: Dice Game

17

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 Ne xtstate <= 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; en d 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.