Laboratory 11 and Homework 11
Microprogrammed Controller

Laboratory 11

The goal of the laboratory and homework is to implement a microprogrammed controller to replace the controller of Homework 10, no other changes should be necessary. The controller architecture of state machines can be implemented in several approaches. Homework 10 was implemented as a hardwired controller in the sense that it consisted of a fixed state transition and output definition and any changes to the controller behavior required modifying state transitions or output definitions. A more general approach is to implement the controller as a microprogrammed device, one that has a fixed state transition and output definition part but its actions are programmed much like a regular computer CPU.  To review the overall architecture, the system part connects the data and controller parts. The data part maintains the values of data manipulated by the machine using registers to hold the data value and multiplexers when more than one input to the register is possible. The controller computes the controls to the data part multiplexers and registers. A general architecture diagram is at right. Note that the System has external inputs and outputs that connect to either of the two internal Data or Control subsystems. The main purpose of the System is to connect the Data and Control subsystems.

The following laboratory again focuses on the design of a data checksum device such as that used by Internet protocols to ensure that data is correctly received. The homework assignment is to complete the analysis and design and implement the checksum device. It will be tested by inputting data and outputting the running sum of data input.


Analysis and Design - The design methodology generally is similar to earlier approach excepting Steps 3 and 4:
  1. State problem to be solved.
  2. Determine the inputs and outputs.
  3. Define states and transition conditions in a state diagram.
  4. Define the outputs of each state (the outputs would include device outputs and state control outputs).
  5. Determine computational device required.
  6. Diagram data subsystem device connections.
1. State problem to be solved - This step is generally part of the analysis phase and requires that the problem be clearly defined.

The checksum device is to maintain a running sum of data received over a communication line. Normally the data is sent as a packet of data bytes followed by the computed checksum from the sender. The checksum device sums all new data presented to it. To synchronize its operation with the outside world, the checksum device would be set to run, given a data byte, and notified that there was new data to sum. For example, if the data packet contained:
 

03 06 04 02 Checksum = 15

the checksum device would be given data input of 03, 06, 04, 02. The sequence of data and control given to the checksum device would follow from steps 1-8 as:
 


Data
run
newdata		 Checksum 
Result
done
1. 03 0 0 00 1
2. 03 1 0 00 0
3. 03 1 1 03 0
4. 06 1 1 09 0
5. 04 1 1 13 0
6. 02 1 1 15 0
7. 02 1 0 15 0
8. 02 0 0 15 1
9. 07 1 0 15 0
10. 07 1 1 07 0

Note that step 9 begins a new data packet. The computed checksum would accumulate as 0, 3, 9, 13, 15 (0, 3, 9, D, F in hexadecimal). The senders checksum and the computed checksum would then be compared to determine whether the data packet had been correctly received. The checksum device must indicate when the checksum has been computed (it is done) so that an external comparator can compare the computed and the received checksum for equality. In the example, if both the computed and received checksum is 15 the received packet is assumed correct.

2. Determine the inputs and outputs - From the problem statement it should be possible to determine what inputs and outputs are required. It is often useful to diagram these as connecting a black-box to the outside world. For the checksum device the inputs and outputs would likely be: as in the following where Data and checksum Result are n-bit inputs and outputs, run, newdata, and done are single-bit control signals.

3. Define states and transitions/4. Define outputs of each state - The state diagram (Mealy or Moore) is useful to help determine high-level states and transition conditions. The following diagrams illustrate first the high-level operations necessary (on left). These high-level operations are decomposed to control outputs of multiplexers and registers.

Registers - The general rule of thumb for determining what requires a register is: If a value must be maintained (state) make it a register. That includes any internal state values and outputs. For the checksum device, there is Sum, Result, and done that must be maintained. Sum and Result must be in n-bit registers, done in a single-bit register or flipflop. In practice to simplify the design, only the n-bit values (Sum and Result) will be formally treated as registers rSum and rResult. When to assign the rSum register a value is controlled by the rSumLoad, if 1 the register value changes on the clock edge. The same is true for rResult. The purpose of rResult is to hold the Result after the checksum is computed and the run=0 (checksum'ing is stopped).

Multiplexers - The need for a multiplexer is determined by whether a variable has multiple assignments. If a variable has on one assignment, no multiplexer is required. If two assignments, a two-input mux is required. three to four assignments  requires a four input mux, etc. The checksum device has one variable Sum
with two assignments (Sum=0, and Sum=Sum+Data). The multiplexer selects the input that the rSum register will receive, when the control signal muxSum is 0 the input of "00000000" is selected, when 1 the input Sum+Data is selected.

Moore State Diagram for Checksum Device - High-level (left side) Multiplexer/Register-level (right-side)

5. Controller subsystem - The controller system would normally be designed based upon the data subsystem. Since we already have the data subsystem from Homework 10 and the state diagram is handy, the microcontroller will be designed now.

Determine Controller Input and Output Signals - From the state diagram:

Inputs - run, newdata
Outputs - done, muxSum, rSumLoad, rResultLoad
Design Microinstruction Format - The instruction format can be of two forms, branching or control.  The sequencing form contains fields for:
Branching Instruction Format
Mode - Defines whether branching or control instruction. One bit is sufficient.
Condition code - Defines the condition inputs to be tested (run or newdata). Two bits is sufficient to define either of the two conditions to be tested and an unconditional branch code also. Pick 00 = run condition, 01 = newdata, 10 = unconditional branch.
Condition value - The value of the condition to be true ( 0 or 1). One bit is sufficient.
Address - The address to branch when the condition is true. The size of the address field depends upon the number of instructions needed for the microprogram.

The branching format assuming a program of up to 32 instruction require an address size of 5 bits and appears as: 

Format    Mode|Condition|Value|Address 
Bit          8|       76|    5|  43210
Control Instruction Format
Mode - Defines whether branching or control instruction. One bit is sufficient, pick 1 for branching and 0 for control.
Outputs - Defines the output values for done, muxSum, rSumLoad, rResultLoad. Four bits required.

The control format appears as: 

Format    Mode|    |done|muxSum|rSumLoad|rResultLoad 
Bit          8|7654|   3|     2|       1|          0
Since the size of the branching and control instruction must be the same, the larger branching instruction format determines the final size. Any extra control fields can be filled with any value.
Design microprogram - Based upon the state diagram a set of pseudocode instructions can be defined to perform the necessary operations. Program instructions for state S1 could be:
State S1
3. done=0; muxSum=1; rSumLoad=0; rResultLoad=0      -- A control instruction.
4. if !run goto 0                                                                 -- Assuming that address 0 implements state S0
5. if !newdata goto 4                                                         -- Wait for newdata
Translate Pseudocode to Microcode - For the microinstruction specified above, the translation of state S1 is:
State S1
                                                Format    Mode|    |done|muxSum|rSumLoad|rResultLoad 
                                                   Bit       0|0000|   0|     1|       0|          0
3. done=0; muxSum=1; rSumLoad=0; rResultLoad=0    
                                                Format    Mode|Condition|Value|Address 
                                                   Bit       1|       00|    0|  00000
4. if !run goto 0                        
                                                Format    Mode|Condition|Value|Address 
                                                   Bit       1|       01|    0|  00100
5. if !newdata goto 4
The VHDL control subsystem component would also remain the same:

        COMPONENT HW11ctrl
            PORT(                 clk, run, newdata  : IN BIT;
                  rMux, rSumLoad, rResultLoad, done  : OUT BIT;
                                              state  : OUT BIT_VECTOR(3 DOWNTO 0)  );
        END COMPONENT;

6. Determine computational devices - The checksum requires the operation of Sum+Data which can be implemented using the Arithmetic Unit designed earlier as a homework exercise.

7. Data subsystem - The data subsystem does not change. A diagram of the devices and connections as below at right can help visualize data subsystem architecture. The Data subsystem receives three Control subsystem inputs and the Data input, outputting the Result. The data subsystem component in VHDL would have an interface similar to: 

        COMPONENT HW10data
            PORT(                           clk : IN BIT; 
                  muxSum, rSumLoad, rResultLoad : IN BIT;
                                           Data : IN BIT_VECTOR(7 DOWNTO 0);
                                         Result : OUT BIT_VECTOR(7 DOWNTO 0));
        END COMPONENT;
 
High-level system view

 

View as Data and Control subsystems

View of Data subsystem details

8. System - The main system serves to connect the Data and Control subsystems, supporting the notion of modularization. It does not change from Homework 10. From the high-level system view diagram, the VHDL for Checksum system can be derived as (the connecting control signals are in bold):
  

ENTITY Checksum IS 
        PORT(   clk, PB1, PB2 : IN BIT;
                        Data  : IN BIT_VECTOR(7 DOWNTO 0);
                        done  : OUT BIT;
                      Result  : OUT BIT_VECTOR(7 DOWNTO 0));
END Checksum; 

ARCHITECTURE structural OF Checksum IS

        COMPONENT DataSubsystem
            PORT(                           clk : IN BIT; 
                  muxSum, rSumLoad, rResultLoad : IN BIT;
                                           Data : IN BIT_VECTOR(7 DOWNTO 0);
                                         Result : OUT BIT_VECTOR(7 DOWNTO 0));
        END COMPONENT;

        COMPONENT ControlSubsystem 
            PORT(                 clk, run, newdata  : IN BIT; 
                  muxSum, rSumLoad, rResultLoad, done  : OUT BIT );
        END COMPONENT;

        SIGNAL  muxSum, rSumLoad, rResultLoad : BIT;

BEGIN
        U0: DataSubsystem PORT MAP (clk, muxSum, rSumLoad, rResultLoad, Data, Result);
        U1: ControlSubsystem PORT MAP (clk, run, newdata, muxSum, rSumLoad, rResultLoad, done);

END structural;

Homework 11

Assignment - Implement the Control subsystem for a checksum device. The system component to connect the two subsystems is given below. It has been modified somewhat for use on the UP1 hardware. The changes from the earlier system implementation is:
  1. Input
  2. Output
  3. Clock
Homework 11 System VHDL 
ENTITY HW11 IS 
        PORT(   systemClk, PB1, PB2 : IN BIT;
                              Data  : IN BIT_VECTOR(7 DOWNTO 0);
                              done  : OUT BIT;
        a1, b1, c1, d1, e1, f1, g1  : OUT BIT;
        a2, b2, c2, d2, e2, f2, g2  : OUT BIT);
END HW11; 

ARCHITECTURE structural OF HW11 IS

        COMPONENT HW10data
            PORT(                           clk : IN BIT; 
                  muxSum, rSumLoad, rResultLoad : IN BIT;
                                           Data : IN BIT_VECTOR(7 DOWNTO 0);
                                         Result : OUT BIT_VECTOR(7 DOWNTO 0));
        END COMPONENT;

        COMPONENT HW11ctrl 
            PORT(                   clk, run, newdata  : IN BIT; 
                  muxSum, rSumLoad, rResultLoad, done  : OUT BIT;
                                                state  : OUT BIT_VECTOR(3 DOWNTO 0)  );
        END COMPONENT;

        COMPONENT segment7 
                PORT(              x : IN BIT_VECTOR(3 DOWNTO 0);
                      a,b,c,d,e,f,g  : OUT BIT);
        END COMPONENT;
    
        COMPONENT slowCLK 
                GENERIC( FREQUENCY : INTEGER RANGE 0 TO 12587500 := 12587500);  
                     PORT( clockIN : IN       BIT;  
                          clockOUT : OUT   BIT);  
        END COMPONENT;  

        COMPONENT debounce 
                PORT (  systemCLK, bounce : IN  BIT ; 
                                debounced : OUT BIT);
        END COMPONENT; 

        SIGNAL              run, newdata, clk : BIT;
        SIGNAL                         Result : BIT_VECTOR(7 DOWNTO 0);
        SIGNAL  muxSum, rSumLoad, rResultLoad : BIT;
        SIGNAL                          state : BIT_VECTOR(3 DOWNTO 0);

BEGIN
        DB1: debounce PORT MAP (systemClk, PB1, run);
        DB2: debounce PORT MAP (SystemClk, PB2, newdata);

        CLK0: slowCLK GENERIC MAP (1)  
                          PORT MAP(systemCLK, clk);       -- Slow down system clock to 1 Hz.  

        U0: HW10data PORT MAP (clk, muxSum, rSumLoad, rResultLoad, Data, Result);
        U1: HW11ctrl PORT MAP (clk, run, newdata, muxSum, rSumLoad, rResultLoad, done, state);
        U2: segment7 PORT MAP (Result(3 DOWNTO 0), a1, b1, c1, d1, e1, f1, g1);
        U3: segment7 PORT MAP (state, a2, b2, c2, d2, e2, f2, g2);

END structural;
Turn In
  1. Cover Page - Your name, date, and Homework 11. Staple all pages together.
  2. Simulation of:
  3. VHDL listing of the Control and Data subsystems component.
  4. Demonstrate to instructor.
Implementation

Points of note:

Compiling Simulation

The Control subsystem can be simulated independently. Simulation of the entire system will require commenting out the debouncing and slow clock components in the system component and directly connecting clk, run, and newdata as below: 

--      DB1: debounce PORT MAP (systemClk, PB1, run);
--      DB2: debounce PORT MAP (SystemClk, PB2, newdata);

--      CLK0: slowCLK GENERIC MAP (1)  
--                        PORT MAP(systemCLK, clk);  -- Slow down system clock to 1 Hz.  

        clk     <= systemClk;
        run     <= PB1;
        newdata <= PB2;
To enter the Data input of 3, 6, 4, 2 in the WaveForm editor drag over the Data  click , enter the input of 3 with a Increment of 0. Repeat for 6, 4, and 2. The final simulation should look similar to the following. Note:
 
Pin Connections
Necessary Pin Definitions for HW11 component
  
systemClk - 91          
PB1       - 28
PB2       - 29
 
LED 1
a1 - 6     
b1 - 7
c1 - 8
d1 - 9
e1 - 11
f1 - 12
g1 - 13
 
LED 2
a2 - 17   
b2 - 18
c2 - 19
d2 - 20
e2 - 21
f2 - 23
g2 - 24
 
SWITCH
Data0 - 41
Data1 - 40
Data2 - 39
Data3 - 38
Data4 - 36
Data5 - 35
Data6 - 34
Data7 - 38
 
Pin Assignments for HW11 Component on FLEX FPGA
Debugging and Testing

It is essential that each component, Control and Data subsystems, be carefully debugged before attempting to test the complete system. Once the all component operation has been verified through simulation, the following debugging steps are appropriate with the UP1.


Programming

Programming the FPGA requires:

Document last modified: