Project One Report

Project One Report
Chris Barwick
ECE 406 Section 1
March 20 th 2008
I. INTRODUCTION
As digital systems become larger and more complex, it becomes increasingly
difficult to organize, test, and debug. The development of hardware description
languages (HDL) allows one to build an entire hardware system using a relatively
simple programming language. Project one used the Verilog HDL to build a
simplified version of the LC-3 microprocessor. The project not only taught me the
Verilog language itself, but also how to deal with a complex system such as the LC-3
by using a top down design style.
The following report gives a basic overview of how I dealt with designing the
LC-3 microprocessor. Section two summarizes how to take a complex digital system,
break it up into smaller parts, and then implement those parts. Section three reviews
the most difficult part of this project, debugging. Lessons learned from this project
and conclusions are given in section five. Finally, an appendix is provided for some
statistics about the project as well as the grading breakdown.
II. DESIGN PROCESS
Since the LC-3 is a very complex system, a top down design style was used. In
this style, the first step is to define the top level module. The inputs and outputs
were determined based on system requirements. Since the LC-3 is a microprocessor,
the device has to be able to process and execute the instructions given. This was
accomplished by implementing the system as a state machine with a controller block
and registers. The system was then broken up into six different modules as
displayed in figure one.
Figure 1: Top level view of the LC‐3

ECE 406: Project One Report Barwick
Each of these modules were outlined with specific requirements. Once these
requirements were defined, they were implemented as well as tested individually.
For example, the Controller block, which keeps track of the different states of the
system, was first outlined using a state diagram and then implemented in Verilog
using a case statement and register.
III. TESTING AND DEBUGGING
Perhaps the most difficult part of this project was testing and debugging.
After each module was designed, a test bench was written for that module to
determine if the module met the requirements detailed in the design process.
Testing each individual module first rather than waiting to test the entire system
proved to be extremely helpful. It caught obvious bugs and prevented me from
feeling overwhelmed. However, it turned out that testing the modules individually
does not guarantee that the over system will function properly. Once the modules
were connected together, there were several issues some of which have been outlined
below.
a. Improper connections
When the microprocessor was first compiled, several errors were received
stemming from the top level module. The specific error was:
ncelab: *W,CUVMPW (./proj1.v,30|74): port sizes differ
in port connection.
The error resulted from not explicitly stating multiple wire labels that
connect each module. If a single wire connects the modules, such as the “clock”,
it does not need to be defined as a wire. However, if it is multiple wires, such as
“D_Data”, the label needs to be defined (ex. “wire [47:0] D_Data;”). I defined
the wires needed wires explicitly and the program complied without error.
b. Bad Fetch Module
After the system successfully compiled, the anomalous behavior shown in
figure two was observed. The system did not seem to be getting the proper
memory address, which is determined by the fetch module. The schematic for
the fetch module was reevaluated and it was determined that the “pc” signal was
not being set properly. During certain states the “pc” signal from the fetch
module needed to be high impedance due to a shared bus. A simple change in the
code within the fetch module fixed this. This obvious bug should have been
caught during the individual module testing and may have gotten through due to
poor testing.
Page | 2

ECE 406: Project One Report Barwick
Figure 2: Waveform resulting from a bad fetch module
c. Bad Decode Module
Once the Fetch module was fixed, the microprocessor functioned properly
until it hit the STI instruction. Figure three displays the behavior. Since the LDI
instruction, which is similar to STI, worked properly, the decode block was
checked to make sure the proper control signals were being set. The actual
control signals matched the control signals written down in class. After some
more debugging, I noticed that the address the memory was receiving not correct.
This address is provided by the MemAccess module, which also was receiving the
incorrect address. The execute module was not providing the proper “pcout”
address because the decode block set “PC sel 2” to choose VSR1. After talking
with fellow students, it turns out that I copied the control signals down wrong.
The decode block was corrected so that “PC sel 2” was set to npc for the STI
instruction. After this fix, the microprocessor then functioned properly.
Figure 3: Waveform resulting from a bad decode module
Page | 3

ECE 406: Project One Report Barwick
IV. LESSONS LEARNED AND CONCLUSION
This project has provided some important lessons; including writing better
individual module test benches and making sure the design requirements are
correct. While it is difficult test each module exhaustively, it is better to put the time
into debugging a single module rather than trying to find the bug once the system
has been put together. Also, before trying to implement a design, ensure that you
have the design requirements correct not only for the entire system, but for each
module. This can save a lot of headaches when testing.
This project has also provided some insight on how to deal with complex
digital systems such as the LC-3 microprocessor. Using a top down design style can
help one break up the problem into simple, manageable parts. The design technique
used in this project can be scaled to bigger and much more complicated digital
systems such as today CPUs. The techniques used are very similar to the techniques
that companies such as Intel or AMD use when designing their complex processors.
Page | 4

ECE 406: Project One Report Barwick
Appendix
ECE 406-001
Project #1 Statistics
Chris Barwick
March 20, 2008
Part 1: To be filled out by student
Points Originality
/ 4 Did you use the Controller from the HW#5 solution (yes/no)? - No
/ 3 Did you use the Fetch Block from the HW#6 solution (yes/no)? – No
/ 3 Did you use the Execute Block from the HW#6 solution (yes/no)? -No
Points Synthesis Results
/ 5 Number of logic elements: 319
/ 5 Number of registers: 178
/ 5 Number of tri-state buffers:34
/ 5 Number of memory bits: 0
/ 10 Please attach to the end of this report a print-out of all text from the Analysis and Synthesis
Messages section of your .map.rpt file. If you have warnings and/or errors, please provide
your best one- or two- sentence explanation for why each warning or error is occurring.
/ 40 Total for Originality and Design Statistics
Part 2: To be filled out by grader
Points Execution graded by:
/ 10 All modules included in proj1.v
/ 10 Correct execution of proj1.dat
/ 10 Correct execution of second program
/ 30 Total for Wolfware submission
Part 3: To be filled out by instructor
Points Element
/ 10 Technical Depth
/ 10 Readability
/ 10 Attractiveness
/ 100 Total for Project
Page | 5

ECE 406: Project One Report Barwick
+-------------------------------+
; Analysis & Synthesis Messages ;
+-------------------------------+
Info: *******************************************************************
Info: Running Quartus II Analysis & Synthesis
Info: Version 7.2 Build 203 02/05/2008 Service Pack 2 SJ Web Edition
Info: Processing started: Wed Mar 19 23:28:42 2008
Info: Command: quartus_map --read_settings_files=on --write_settings_files=off proj1 -
c proj1
Info: Found 10 design units, including 10 entities, in source file proj1.v
Info: Found entity 1: proj1
Info: Found entity 2: Execute
Info: Found entity 3: alu
Info: Found entity 4: extension
Info: Found entity 5: Controller
Info: Found entity 6: Fetch
Info: Found entity 7: MemAccess
Info: Found entity 8: Writeback
Info: Found entity 9: Decode
Info: Found entity 10: RegFile
Info: Elaborating entity "proj1" for the top level hierarchy
Info: Elaborating entity "Fetch" for hierarchy "Fetch:f"
Info: Elaborating entity "MemAccess" for hierarchy "MemAccess:memacc"
Info: Elaborating entity "Controller" for hierarchy "Controller:cont"
Info: Elaborating entity "Decode" for hierarchy "Decode:dec"
Info: Elaborating entity "RegFile" for hierarchy "Decode:dec|RegFile:regf"
/**These warnings are due to the assignment of the register, but the variable is not
read in my code. These assignments were made to see what the registers contain in
Simvision**/
Warning (10036): Verilog HDL or VHDL warning at proj1.v(532): object "R0" assigned a
value but never read
Warning (10036): Verilog HDL or VHDL warning at proj1.v(532): object "R1" assigned a
value but never read
Warning (10036): Verilog HDL or VHDL warning at proj1.v(532): object "R2" assigned a
value but never read
Warning (10036): Verilog HDL or VHDL warning at proj1.v(532): object "R3" assigned a
value but never read
Warning (10036): Verilog HDL or VHDL warning at proj1.v(532): object "R4" assigned a
value but never read
Warning (10036): Verilog HDL or VHDL warning at proj1.v(532): object "R5" assigned a
value but never read
Warning (10036): Verilog HDL or VHDL warning at proj1.v(532): object "R6" assigned a
value but never read
Warning (10036): Verilog HDL or VHDL warning at proj1.v(532): object "R7" assigned a
value but never read
Info: Elaborating entity "Writeback" for hierarchy "Writeback:write"
Info: Elaborating entity "Execute" for hierarchy "Execute:exe"
Info: Elaborating entity "extension" for hierarchy "Execute:exe|extension:u1"
Info: Elaborating entity "alu" for hierarchy "Execute:exe|alu:u2"
Info: Generated suppressed messages file
C:/Users/Chris/Desktop/PROJECT1/proj1.map.smsg
Info: Implemented 501 device resources after synthesis - the final resource count
might be different
Info: Implemented 19 input pins
Info: Implemented 33 output pins
Info: Implemented 449 logic cells
Info: Quartus II Analysis & Synthesis was successful. 0 errors, 8 warnings
Info: Allocated 163 megabytes of memory during processing
Info: Processing ended: Wed Mar 19 23:28:56 2008
Info: Elapsed time: 00:00:14
Page | 6