

Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community for help and clear up your study doubts
Discover the best universities in your country according to Docsity users
Free resources
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
The process of building a simple computer processing unit (cpu) as part of the cs350 course at illinois institute of technology. It includes a detailed description of the components used, the problems encountered, and the lessons learned during the implementation of the iiter project.
Typology: Study Guides, Projects, Research
1 / 3
This page cannot be seen from the preview
Don't miss anything!
The Illinois Institute of Technology Computer Science and Computer Engineering courses are filled with many projects designed to enhance our understanding of the computing realm. Through these hands on experience projects, all students begin to fully appreciate the basic logic hidden under the façade of all complex computer hardware. One such project, which I believe epitomizes this concept, is the CS350-Illinois Institute of Technology Eight-Bit Reduced Instruction Set Computer (IITER) Project. In layman’s terms the purpose of the IITER project is to build a simple Computer Processing Unit (CPU). As anyone who is even slightly computer literate understands is the so called “brain” of any computer. I will, in the following paragraphs, attempt to convey the design schematics we implemented, as well as, some of the problems we encountered and how we solved them. This will then be followed by what our team believes is of utmost importance: what we learned from this implementation. I would like to first and foremost begin with a detailed description of the components used to build a fully functional 8-bit CPU. This CPU is designed to be able to perform such functions as adding, subtracting, and and/or comparisons. One of the first things that we learned was that the heart of any CPU is the Arithmetic Logic Unit (ALU). The ALU we implemented was derived from eight one-bit adders, which all have the capability to be inverted making subtraction possible. The 8-bit ALU also contains an output with a constant value of zero allowing branching instructions to be possible. The other major components of our CPU are briefly described below: Read Only Memory: The ROM is used to download the .mif file, which is produced by our assembler program: this instruction file is stored in memory. Program Counter (PC): The PC stores the current 8-bit address and increments it by one each time an instruction is read, that is unless the instruction is a branch. If this is the case the PC loads the new address into the ROM. Instruction Register (IR): The IR is used to hold the current instruction being processed within our CPU. Random Access Memory (RAM): The RAM is used to store data in the memory and has the capability to output the stored data or change the values within the memory. Register File (RF): The RF stores values into four registers which we implemented, all arithmetic must be done using these four registers. Hence our RF decodes which register should be written to or read from. Decoder (DEC): The DEC is the component, which controls all the dataflow. The ability to control all multiplexors allows the DEC to decide which data in the 16-bit instruction is to be used as sources, destinations, or if an immediate value is to be taken into consideration.
It should be noted that the ROM, RAM, and a clock (used for the timing) were given to us by our generous instructors. The other components described above were fully implemented by our project team. Along with these components there was also a need to build an assembler from a high level language. We decided to use Visual C++ as our platform. The assembler is simply feed a program written in assembly language, the assembler then produces a .mif file which contains instructions: all 16-bits in size. Along with this we also had to produce what is known as a seven-segment decoder, which is used to display the registers in an LED when it is downloaded to a board (containing a actual chip). Unfortunately, because of time restrictions our team was unable to see our seven-segment decoder in action, but it is included in our project hardcopies. As the implantation phase slowly started to com to an end, my team really began to appreciate the work we had done. We had started with nothing more than 8-bit ALU, which we had implemented during our last lab, but in the end we had a fully functional CPU. The experience of this project went even further than just the technical aspect; my team members and I had to learn to think like a team. Without the combined teamwork none of this could have been possible. And I think this was one of the most important lessons we all learned. Everyone comes in with a certain degree of knowledge but when minds are combined, even complex projects like the IITER are possible. However, our team learned that working with different members is not always easy. Everyone is different and most of the time everyone believes his/her implementation is better and should be used. This was one of problem our team faced early on. The situation was resolved quickly by using the division of labor technique instead of working on everything together. By having different members complete different components and simply going through the simulations together as a team for testing and debugging. Towards the end of our project we did learn to see the other people’s point of view, which helped us get through the final steps of the project. As the CPU design started to come to its finale, our team was very excited to attempt to download our design to an actual chip. This feeling of joy was abruptly destroyed by our lab instructor when we discovered that we had to have an assembler to attempt the download. We were all initially upset that our instructor had left us feeling so ignorant, but it turned out to be a good learning experience. Our team got together that night, as well as the following night, and finished the assembler program in C++. We had to rush and we knew our chip would never be downloaded but we still had a feeling of accomplishment instilled within us. This proved to be the most difficult problem our team encountered. By exceedingly emphasizing the theory and logic behind this project, our team was able to avoid any serious problems related to the CPU design itself. There were a few challenges such as the ordering of the multiplexor inputs is opposite of that in the book. However, simple investigations lead us to the false logic. Other small problems such as these are listed in the archive section of our project website at www.zhangyu@iit.edu/cs. While visiting the website be sure to look out at our final implementation schematics, as well as, our team members’ descriptions and contributions to this project. In conclusion, our team really did learn a lot about the schematics and logic of any complex computer system. We not only learned about each component involved, but we also learned how to implement them. We learned that all computers have a complex alphabet such as the ASCII Table. However, computer hardware could only recognize a simple alphabet of 0 and