University of Portland School of Engineering Phone 503 943 7314 5000 N. Willamette Blvd. Fax 503 943 7316 Portland, OR 97203-5798 Final Report Project Steelhead: A CMOS 4-bit x 4-bit Multiplier Contributors: Ross Yoshioka Scott Sato Approvals Name Date Name Date Dr. Osterberg Dr. Lillevik UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ROSS YOSHIOKA
28
Embed
Final Report - University of Portlandteaching.up.edu/.../documents/steelhead_finalReport095.doc · Web viewUniversity of Portland School of Engineering Phone 503 943 7314 5000 N.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
University of Portland School of Engineering Phone 503 943 73145000 N. Willamette Blvd. Fax 503 943 7316Portland, OR 97203-5798
Final Report
Project Steelhead: A CMOS 4-bit x 4-bit Multiplier
Contributors:
Ross Yoshioka
Scott Sato
ApprovalsName Date Name Date
Dr. Osterberg Dr. LillevikInsert checkmark (√) next to name when approved.
UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ROSS YOSHIOKA
.........
FINAL REPORT REV. 0.95 PAGE IIPROJECT STEELHEAD UP-EE-TR-04-02
Revision HistoryRev. Date Author Reason for Changes
0.9 04/16/04 R. Yoshioka & S. Sato
Initial draft
0.95 04/20/04 R. Yoshioka & S. Sato
Updated budget table, inserted Block diagram in “Results”
UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ROSS YOSHIOKA
.........
FINAL REPORT REV. 0.95 PAGE IIIPROJECT STEELHEAD UP-EE-TR-04-02
Acknowledgements- Dr. Peter M. Osterberg:
First, thank you for giving us the idea of creating a 4-bit x 4-bit multiplier. Thanks also for teaching us how to break down our design into different levels (Top-Level Schematic, Chip Block Diagram, Output Decoder Diagram, B²Logic Simulation, TPR file, etc.) This helped a lot in our monthly Program Reviews. Thanks also for teaching us how to use the correct wording in all of our documents.
- Dr. Sigurd L. Lillevik
Thank you for teaching us how to properly document our ideas. We truly were able to narrow down our ideas from such document as the Functional Specifications and the Project Plan. The documentation brought the professional aspect of designing a project in the real working world to our project.
- Mr. Michael M. DeSmith
Thank you for helping us to break down the step by step process of what the user will see when he or she uses of device. Thanks also for your advice on our 8-bit binary to BCD conversion.
- Sandra A. Ressel
Thank you for your willingness to always get us the parts that we needed.
- Dr. Wayne Lu
Thank you for your advice on using the rotary devices instead of the keypad. Thanks also for your help on designing our GAL’s (Gate Array Logic) chips.
UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ROSS YOSHIOKA
.........
FINAL REPORT REV. 0.95 PAGE IVPROJECT STEELHEAD UP-EE-TR-04-02
Table of ContentsSummary..............................................................................................................1
Number Deliverable Date1 Chip Design and Simulation 10/28/032 Chip tpr file completed 11/11/033 Macro Model 3/23/044 I/O system 4/01/045 Prototype Assembly and
debugging with Macro Model 4/01/04
6 Receive MOSIS chip and Plug-In 4/01/04
7 Build Display Unit 4/3/048 Final Functional Prototype
Demonstration (Founder’s Day)
4/13/04
Chip Design and Simulation
This involved breaking Project Steelhead’s Multiplier Chip into smaller blocks of logic. Each block was then designed and simulated in B2Logic using only the standard cells provided in the L-Edit Suite.
Chip tpr file completed
Completed tpr file (checked, re-checked, and re-re-checked) for the chip in order to be programmed by L-Edit’s Place and Route software.
Macro Model
Built a Macro Model of the Project Steelhead Multiplier Chip as a backup for the MOSIS CMOS chip.
I/O System
Built and tested the I/O system for Project Steelhead.
Prototype Assembly and Debugging
Put together all pieces of Project Steelhead and test for functionality. Project worked perfectly with Macro Model in place of chip.
UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ROSS YOSHIOKA
Table 2 lists Project Steelhead’s key milestones. The first milestone, Product
Approval, has already been completed. The Project Plan Approval has already been
approved from both our advisor and Industry Representative. We completed the creation
of our tpr file. We got our Design Release approved. This marked the end to Fall
Semester.
Spring Semester opened far more relaxed, with most design milestones well spaced
out. The completion of the Macro Model was the first milestone of the semester. The
second milestone was the Approval Meeting for the “Theory of Operation” document. The
next milestone, Prototype functional with Macro Model, was another important design UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ROSS YOSHIOKA
The most critical work came in the month of November. This was when the design of the entire project came together to create a stable design for the MOSIS Chip. Once this was done, the project’s timeline eased up somewhat. The building of the Macro Model and I/O section of the project was by far more stressful in comparison to the design of the MOSIS chip and I/O sections since many problems arose.
Critical Path
The critical path included the design and simulation of the chip in the Fall Semester. It also included the creation of the tpr file. The ordering of parts, along with the necessary lead time to receive them was the next item on the critical path. In the spring semester, the creation of the macro model, along with the building of the I/O section of the Project was the next items located on the critical path. After this, the delivery of the MOSIS Chip was the next item on the critical path. After the Chip was received, testing also needed to be done before the final Prototype Release was completed.
UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ROSS YOSHIOKA
Scott Sato: Team Leader for Fall Semester; Design and Simulation of Chip in B2Logic, writing of tpr file, website, build macro model, testing.
Ross Yoshioka: Team Leader for Spring Semester; Verification of tpr file, Choosing parts, B2Logic simulation of I/O section, build system model, testing.
Budget
Table 3. Overall Steelhead budget.
Equipment
Power Supply: Used to power the Chip / Macro Model, I/O Section, and Display. Salvaged from a past Senior Design Prototype.
Ribbon Cables: Used to connect the various parts of the project.
Prototyping Board: Used to put the bulk of the project together.
Wire: Used to connect discrete components of the project.
Wire Wrapping Gun: Used to connect pins and wires in Macro Model and Overall Project. Provided by the University of Portland.
Logic Gates: Used to build Macro Model and Combinational Logic for I/O Section.
UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ROSS YOSHIOKA
Resistors: Used to regulate voltage in project (I/O section).
Seven-Segment LED Displays: Used to create an attractive display for the User.
Push Buttons: Used for the “Clear” and “Equal” keys.
Rotary Devices: Used to send out the input in BCD form.
Case Material: Used to build an attractive and appropriate case for display.
Facilities
The University of Portland, School of Engineering Electrical Circuits laboratory, ENG 2001 was primarily used when constructing and testing Project Steelhead.
UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ROSS YOSHIOKA
This is a diagram breaks down our top level diagram, figure 1. It covers the same scope as figure 1., but goes into more detail regarding what each block is comprised of.
UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ROSS YOSHIOKA
This diagram shows the algorithm employed in our Chip and Macro Model. It is a “Shift and Add” type of multiplier. In short, this block diagram shows what the “MOSIS Chip” block is made of (in figure 3.).
This diagram shows the method we employed to convert from the 8-bit binary output from the Chip/Macro Model to the three digit decimal number the user would see. Since no 8-
UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ROSS YOSHIOKA
bit binary to BCD decoders were readily available commercially, we decided to implement this decoding using Gate Array Logic, or GALs for short.
Process
The first step we took in designing our prototype was to gather our thoughts and try to come up with a design on paper. We used knowledge from various classes we have taken to do this. The next step was to simulate this design in B2Logic. Figure 6. shows the simulation for our Chip/Macro Model.
Figure 6. Project Steelhead B2Logic Simulation
After this simulation was tested exhaustively, the next step was to take this simulation and create a tpr file. This tpr file is a net list used by L-EDIT’s Place and Route software. A snippet of this code is shown in figure 7. After fabrication, it was discovered that an error was made in the creation of the tpr file. Through due diligence/error analysis, we were able to find the exact location of the error within the file.
UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ROSS YOSHIOKA
The TPR file, which turned out to be nearly six pages long, was then sent to Dr. Osterberg who ran it through the L-EDIT software to get our chip layout which is shown in figure 8.
UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ROSS YOSHIOKA
One major assumption we made was that we understood how the keypad we intended to use operated. We did not have a backup plan in the event this assumption proved wrong. Instead, we were forced to create a solution “on the fly”. Luckily, a solution even more practical than our original one presented itself. Another assumption we made that proved to be false was the assumption that our MOSIS Chip would work. However, the other two assumptions we made did prove to be true. They were: (1) assuming our multiplier design was valid; (2) and also assuming we would be able to get all the parts we needed.
There were a few instances where we did fall behind the dates projected in our milestones table. One major instance of this was in the event labeled “Prototype Working with Macro Model.” This also caused us to fall behind on our next milestone, which was to receive and test our MOSIS Chip. Because both of these events were located along the critical path of our plan, they did have some affect on our timeline. However, since there was some extra time built into the schedule, the delays did not affect our ability to complete our prototype in time for Founder’s Day.
One risk which proved risky was the risk of our MOSIS Chip not working. Although there was a backup plan (the Macro Model), there is no real substitute for having the chip actually working. That backup plan ended up being the savior of our project, since without it, we would not have a functioning prototype. Another risk we considered that ended up manifesting itself was the risk of a keypad failure. Although a failure did not happen in the usual sense of the word, our failure to correctly assess the workings of the keypad was a cause for worry when the problem arose. Luckily, a good solution was found. The final risk we mentioned was the “Prototype not functioning properly.” Although we listed
UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ROSS YOSHIOKA
this as a medium risk, the outfall of such a failure would be tremendous. Luckily, we did not have the misfortune of experiencing the fallout of this risk.
As mentioned earlier in the discussion of our Milestones table, the time required to build and debug our Macro Model and System Model were underestimated. Having never worked on a project of this scope before, this was probably just a function of not knowing was to expect. Our budget, equipment, and facilities proved adequate. Our advising resources proved to be excellent. Without the help of all those listed in our acknowledgment section, we would have surely struggled, possibly even failed.
In the section of contingency plans, the contingency plan for the MOSIS Chip not working was invoked, the reasons for which are self-explanatory. There was also a secondary contingency plan for the keypad not working properly. This was the actualization of our “Input Interface” using rotary keys. This contingency plan was not included in our Project Plan because we were not aware of such a possibility at that time.
There was one change request made during the design sequence. This was the request to change our design from using a keypad to two rotary switches as discussed above. It was submitted on April 4, 2004.
UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ROSS YOSHIOKA