ECE 352 Digital System Fundamentals Introduction to Complex FSMs This video introduces complex state machines, where we use a state diagram to express system behavior that includes register transfer operations.

Complex FSM Design We use the term “complex FSM” to describe a state machine containing a control unit and a datapath Datapath: the registers and logic that process the data The design of the machine’s state diagram is done at a higher level of abstraction The diagram only shows the states required for the control unit; it does not show the state of the datapath registers State diagram “outputs” can include register operations e.g. “reset count”, “A  A − B”, etc. State diagram “inputs” can include the results of register ops e.g. “A < B”, “count == 0”, etc. Low-level designs of the control unit and the datapath are done independently after the high-level design is complete When working with the design of complex machines, we often need break down the problem into a set of smaller pieces that are easier to work with. One common way to partition a design is to break it into a datapath and a control unit. We will refer to a state machine that contains a datapath and control unit as a “complex FSM”. Be aware that this is not a universally accepted term, but it is what we will use to describe this type of machine. The whole point of the “complex FSM” is that we want to design at a higher level of abstraction that still encompasses the behavior of the complete machine. Although registers have state—the contents of their flip-flops—we usually think about how they behave in terms of register transfer operations, not state transitions. So we only show the states required for the control unit, not the datapath. Yet it is not simply a state diagram for the control unit, since we will still represent the register operations on it. A complex state machine may include output signals like we’ve seen, but it also may include register operations that need to happen at specific times. In other words, we represent what we want to occur, but not necessarily the exact control unit output values that will cause it to occur. That’s part of a later step. Similarly, the inputs on the diagram can be more abstract than a specific input value signal, and can instead represent a condition related to the contents or status of the datapath registers. It is very useful to think about a high-level design in terms of the register transfers that the control unit will command, and what type of information the control unit needs to get from the datapath—but without thinking about exactly how that information will be transmitted in each direction. In the end, the control unit and datapath will have to communicate using signals, not abstract concepts. So after we complete the high-level design, we create the interface between the datapath and control. Finally, based on the interface, the low-level designs can be completed separately.

Designing a Complex Circuit Describe the circuit’s behavior with a state diagram that may include register operations and comparisons Determine the required registers and functionality, including any status outputs needed by the FSM Define the register control signal inputs Design the registers (datapath) based on the needed functionality and the defined control signals Design the controller FSM Redraw the FSM to describe only the controller behavior, replacing all register operations and comparisons with the corresponding control and status signals Create the controller FSM using normal FSM design methods These next two steps can be done in either order… Let’s look at a procedure that we can use to organize the design of a complex FSM. First, we draw a state diagram that may include register transfers and their results as outputs and inputs. From that, we can see how many registers are required, and what capabilities and status outputs each register requires. Based on the required operations, we can define the control signals for each register. At this point, we have enough information to design both the control unit and the datapath, and so we can do these in either order. When we design the datapath, we design all of the required registers, and then connect them as required to process the data. When we design the control unit, we modify the complex FSM state diagram by replacing each register transfer operation with the appropriate control signals that will cause that operation to occur, and replacing the register transfer results with the appropriate status signals coming from the datapath. Once that’s done, we can design the control unit using normal FSM design methods.

Register Transfer Operations Examples: Load one register from the contents of another Add two register contents and store the result Decrement the contents of a register The control unit generates signals that tell the datapath which register transfer operations to perform and when to perform them The controller may need information from the datapath in order to determine this… Some examples of the type of register transfer operations that a control unit might command the datapath to perform are listed here. Fundamentally, the control unit’s job is to tell the datapath which transfers to perform, and when to perform them. The control unit uses register status information from the datapath, possibly in addition to circuit input values, to determine what the datapath should do based on what has occurred previously.

A “Simple” Complex FSM Example Suppose we want a machine that will count how many times a button B is pressed. When the 3-bit count A reaches 5, do not count any higher. Describe the circuit’s behavior with a state diagram that may include register operations and comparisons. Let’s look at a simple example to illustrate the complex FSM design procedure we just discussed. We would like to design a machine that counts how many times a button has been pressed, up to 5 presses, at which point the count is no longer incremented. Let’s assume the button is active-high. The first step is to develop a state diagram for the machine, but we can include register transfers and results in the diagram. Let’s assume we start in a state S0, which represents that the previous value of the button was “not pressed”. We stay in this state as long as the button is not pressed, regardless of the current count of button presses. If the count is less than 5 and the button is pressed, we need to increment the count, and go to a state S1 which represents that the previous value of the button was “pressed”. If the count is 5 and the button is pressed, we can either go to S1 but not increment the count, or we could simply remain in S0. We’ll choose to go to S1 because that will simplify the next state logic. If we are in state S1, we should remain there until the button is released, at which point we return to state S0. Note that in state S1, we do not increment A when B is 1. The button has not yet been released, so it’s still the same button press. not pressed pressed

A “Simple” Complex FSM Example 3-bit register A with increment and hold capability Assume asynchronous clear to 0 Single status output MAX for value ≥ 5 Single control input INC to increment Determine the required registers and functionality, including any status outputs needed by the FSM. Define the register control signal inputs. Design the registers based on the needed functionality and the defined control signals. Once we have the state diagram completed, we determine the specific registers that we need. We need to keep a 3-bit count, so we specify a register named A that will have increment and hold capability. For simplicity, we’ll use an asynchronous clear to force the count to 0 when the machine starts operating. We also need to know when the count reaches 5, so the register will have a status output MAX that should be 1 when the register’s stored value is greater than or equal to 5. Next we define the control signals. In this case, only a single control signal is needed. Now, we can design the register itself based on the specification shown here. We won’t look at the register design in detail, but it will have this symbol.

A “Simple” Complex FSM Example Redraw FSM to describe only the controller behavior, replacing register operations/comparisons with corresponding control and status signals. pressed not pressed Create the controller FSM using normal FSM design methods. Now we turn our attention to the control unit. First, we replace all register transfer notation in the state diagram with the corresponding signals. This gives us a state diagram like the ones we’ve seen before. Since we have multiple inputs, we do need to include a legend that identifies the order of the input signals on the diagram. Note that we’ve also done state assignment for a minimum flip-flop implementation technique. Now we can design the control unit, using the techniques we’ve already studied. In this case, the control unit is basically a modified edge detector that detects the 0-to-1 transition, but only allows its output to be 1 when MAX is zero, which will be the case when the register’s count has not yet reached 5.

A “Simple” Complex FSM Example Finally, connect the control unit to the datapath to implement the complete machine MAX CONTROL DATAPATH INC Once we have completed the register and the control unit designs, we connect them together to create the completed machine. The structure on the left is the control unit, and the structure on the right is the datapath, which in this case contains a single register. They are connected by the MAX signal, which is a status output of the register, but an input to the control FSM, and the INC signal, which is a control input of the register, but an output of the control FSM. These two signals represent the interface between the datapath and the control, which allows the two separately-designed components to successfully communicate with one another.

ECE 352 Digital System Fundamentals Introduction to Complex FSMs This was a very simple example intended to help illustrate the complex FSM design methodology. In the next video, we’ll take a look at a more complicated machine.