CSE 141L: Introduction to Computer Architecture Lab
Instructor
|
Teaching Assistants & Tutors
|
Class Meetings
| Date | Time | Location
| Lecture
| W
| 2:00p-3:50p
Lecture and Lab Combined!
| WLH 2205
|
|---|
|
|---|
|
|
|
Office Hours
News
Course Description
From this course, you will:
- Learn correct hardware design practices suitable for FPGA and VLSI digital design.
- Learn how to write Synthesizable Verilog, and use the tools to turn it into a circuit.
- Design, Implement and Test your own processor, although way to an FPGA bitstream.
- Learn about computer architecture in the best way -- by doing.
- Work in a team, building a large, complex system using design principles that apply to both software and hardware.
- Help your classmates and exercise your creativity.
This course is taught in tandem with CSE 141. Unless you have discussed it with me, you should be enrolled in both.
Google Group
We will be using the CSE 141L Google Group for several aspects of this course,
including the class forums and announcements. As a part of your grade will depend on your participation
on the forums, it is extremely important that you are active on the CSE 141L google group.
Additionally, the archives of the group contain answers to questions that might be helpful to you this time around.
Please sign up immediately for the google group as soon as possible to ensure that you are
correctly setup to use the site. If you have any problems, please e-mail one of the TAs and describe
your situation.
Here is the address:
cse-141-lab-taylor.
Grading
In this class, we simulate a realistic, deadline driven team hardware development project. Your goal is build
a processor. If your processor doesn't work, then you have not succeeded. The grading schema for this class
reflects this. It is not on a curve, it is on an absolute standard: did you deliver?
There are two
ways to get a grade in this class. One is to implement a working processor by the end of the quarter that
executes the selected programs in an ISA of your design. If you do this, and you actively work to help other
students in the class, you will receive an "A". If your processor has issues but is basically a solid effort,
and works some or most of the time, you'll do reasonably well too. We have a well-defined schema that
will be discussed in class.
This is the grading option you should strive for; however even for the strongest student, there is always
the chance you will be unlucky -- maybe your latent Diablo addiction kicks in the last two weeks before the
deadline, or your partner decides to do a startup and takes off with the source code, or maybe you just run out of time because you
over-committed yourself this term.
This brings us to the second option: your processor basically does not work. We do an audit and compute your grade based on your performance on the individual
lab grades and your code. Since completing all of the labs means you have a working processor, and you are using the option that does not involve a working processor,
this will not be a very good grade. At best, a B-, but probably not that good, and often much worse.
If it looks like you didn't do much work, for sure you'll get an F -- there are too many people busting their butts in this class
to be generous to those that didn't.
In addition to the labs, you should be an active contributer in the class Google Group. The tools are challenging and sometimes buggy. Your classmates (in addition to the course's staff) are an excellent resource for help with the tools.
This class is about doing. You will learn almost everything you learn in this class by doing it. This means that you (or your team) must do all your own work. As long as you meet this criteria, you can consult with and discuss your project with other groups. We have structured the course so that there is no incentive to be stingy with your knowledge of the tools or in sharing your expertise with your classmates.
| Processor Design
| 86%
|
|---|
| Class, Forum, and Lab Participation
| 14%
| Being an active and positive influence in class and on the Google Group
|
|---|
START YOUR LABS AS SOON AS THEY ARE HANDED OUT.
Late turn-ins: For many of you, this project will be the most complex thing you have ever designed. Each of the labs uses the results of the last, so you cannot simply skip a lab. Worse, each lab seems hard, but seems easy in comparison to the next. If you are late on one lab, then it will have a cascading effect on future labs, and you will run out of time at the end of the class. In order to encourage timely turn-ins, we will offer "limited amnesty" for late labs, which means that the penalty applied to your grade is a function of time. The slope of the amnesty curve is set after the lab is turned in, and can be as high as 15% per day.
Tool Problems: Tool problems are part of the hardware design process. You should expect to have unexpected delays. To the extent that it is a fundamental issue with the
tools that requires real resolution by the TA, we will be more understanding if 1) you posted the issue online, 2) show clear evidence that you
actively tried to solve the problem yourself and 3) it was clear you started early on the lab.
Grading Appeal Process: If you feel there has been an error in how an assignment
was graded, you have one week from when the assignment is return to bring it to our attention.
You must submit to the appropriate TA a written description of the problem issue, what you
feel the fair resolution is, and your unmodified
coursework. We photocopy a random sampling of student work
to detect inappropriate modifications.
Note that we regrade the entire assignment; so your grade may either rise or fall after resubmission.
Should, after you appeal, you be unsatisfied with the TA's treatment of the issue, you may
resubmit the appeal to the professor.
Schedule
NOTE: Subject to skew and jitter. We reserve the right to change this.
I will post the slides for most lectures. Since the slides contain
material I am not allowed to distribute publicly, they may only
be available from UCSD network or via the proxy.
| Date | Lab | Notes |
|---|
| Wed, September 26 | Lab 1 out. No class. | slides
|
| Wed, October 03 | Lab 2A Introduction; Verilog | Lab 1 Due. slides
|
| Wed, October 10 | Lab 2B: Fetch Unit Control | Lab 2A Due. slides
|
| Wed, October 17 | | Lab 2B Beta Due
|
| Wed, October 24 | | Lab 2B Due
|
| Wed, October 31 | Lab 3A | 141 Silver Release Due
|
| Wed, November 07 | Lab 3B slides | Lab 3A Due
|
| Wed, November 14 | | Lab 3B Beta Due
|
| Wed, November 21 | Lab 4 | Lab 3B Final Due
|
| Wed, November 28 | Demos Begin | Lab 4 Due (Last Demo Day Dec 4)
|
| Wed, December 05 | Pizza Party / Lab 5 |
|
Teaming
Starting with Lab 3A, you will be working in a team of two people. For this Quarter, doing solo is
not recommended unless you are a strong student, or very good at building things. To solo, you must ask
the instructor's permission. Typically, the soloists are strong juniors
who have been aceing their classes. If you are not a strong student, help yourself and find and impress
a partner early -- don't lose out in the musical chairs of partner pairing.
I highly recommend against taking another major project class at the same time as 141L.
Pick your partner wisely, and show your partner that you are
a good candidate by doing well in the Labs 1, 2A, and 2B. It's
perfectly reasonable to ask what their grade was on the assignment
before agreeing to partner with them. You may also want to talk about
what your expectations for how aggressive a project you want to do.
If you have already taken CSE 141 in
the past, and thus are not currently enrolled, then you should start looking for a partner immediately, because it may
be harder for you to find one.
You are not allowed to join a team unless you have completed Labs 1, 2A, and 2B. It's not fair to the other
members if you do not have the basic knowledge to design hardware.
You may not switch team members. However, in extreme cases, you may elect to leave the group; you
should talk to the professor and TA in this case. With that in mind, keep your partner happy and
make sure you are pulling your weight -- if your partner leaves because you're slacking,
then you're on your own to try to catch up and finish the project.
Academic Integrity
Cheating is unacceptable. Our policy in this class is to aggressively pursue
cheaters, and to ensure that they receive the maximum penalty allowable under
the University of California academic system. If you are choosing between turning
in an assignment late, or using somebody's else work, do yourself a favor and just turn it in late.
You are facing a permanent mark on your academic record and a certainty of having to explain
it to any future employer or school that you apply to.
Initial Labs For the initial labs, you will work alone. You may post code on the Google Group
to demonstrate a question or an answer, but you may not post any part of your assignment that you plan to turn in.
Project For the labs, if they are group labs, you may obviously
work with your group members. With non-group members, you may brainstorm
about your design but you better make sure there are substantial differences between what
you and they are doing, and you must write your own code.
We will use automatic software for finding inappropriate similarities between student code, and substantial
similarities in student designs (including to
previous teachings of the class) could result in us requiring the student to redo the
assignment. In cases of code copying, we will refer the student to UCSD for cheating.
