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 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.
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 |
the checksum device would be given data input of 03, 06, 04, 02. The
checksum output would be 15. The sequence of external 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, indicated by run changing from 0 back to 1. The computed checksum would accumulate as 0, 3, 9, 13, 15 (0, 3, 9, D, F in hexadecimal). In actual use, the sender's 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.
Registers - The general rule of thumb for determining what requires a register is: If a value must be maintained through multiple states, make it a register (the alternative is to set the value in each state). That includes any internal 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 (flipflop) or be set in each state (the method actually used). 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), since Sum=0 when run=0.
Multiplexers - The need for a multiplexer is determined by whether
a variable has multiple assignments. If a variable has only 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.
 |
 |
5. 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.
6. Data subsystem - Steps 3-5 produce the data registers needed to hold state information, multiplexers to select between data sources, and computational operations on the data. 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
 |
7. Control subsystem - The control subsystem consists of the implementation of the FSM corresponding to the state diagram. The state diagram can be implemented directly in a high level VHDL representation. The VHDL control subsystem component would have an interface similar to:
COMPONENT HW10ctrl PORT( clk, run, newdata : IN BIT; rMux, rSumLoad, rResultLoad, done : OUT BIT; state : OUT BIT_VECTOR(3 DOWNTO 0) ); END COMPONENT;8. System - The main system serves to connect the Data and Control subsystems, supporting the notion of modularization. The Control subsystem is concerned only with the elements of generating control signals while the Data subsystem is concerned only with operations on data. From the high-level system view diagram, the VHDL for Checksum system can be derived as (the connecting control signals between DataSubsystem and ControlSubsystem 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; |
ENTITY HW10 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 HW10; ARCHITECTURE structural OF HW10 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 HW10ctrl 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: HW10ctrl 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; |
Points of note:
Each 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:
To enter the Data input of 3, 6, 4, 2 in the WaveForm editor drag over the Data-- 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;
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:
 |
||||
Necessary Pin Definitions for HW10 component
|
It is essential that each component, Control and Data subsystems, be thoroughly 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 the FPGA requires:
.
to
remove any previously used files from programmer list.
to
list available programming files.
to add it to the Device Names. Click OK.