Workshop In Computer Construction

Course Guidelines

Individual work policy:

Students in this course are allowed (and encouraged!) to submit homework assignments in PAIRS. We also advise you to use Pair Programming. This will help you with your codeing and will ensure you both know the material. At the same time, each pair must work on its own. If you are not sure what the difference is between cooperation and cheating, ASK!.
Please also remember that submitting someone else's code is cheating! This will be dealt with severely!!!

Contacting us:

For general (public) questions regarding the projects please use the news group.
For personal questions and appeals please email the course email address.
Please do NOT use our personal emails!!!

Programming style and rules:

Hardware Projects - The Java laguage conventions, i.e. Chips names begins with upper case character, variables with lower case character, etc.
Assembler Projects - Give meaningful names to your variables and labels. Document every few lines (usually something like "*a=42") - it will help you too.
Programming Projects - The programming projects can be done in Java, C/C++, Perl, Python, Ruby or Bash. If you want to use another language, contact us before. Although this is not Plab, points will be taken for messy, unmodular or under-documented code.
Since we require a unified interface to the program, in case of using Java you should add a small shell-script that runs the Java class file. You can take the sample script as a template.
All programming projects MUST include a Makefile (even if you submit a script file). Calling "make" should do whatever needs to be done in order to create the executable required by this project. You can refer to the sample Makefiles for: Java , C/C++ and Scripts.
Please make sure the command "make" exits successfully and that the executable has execute permission.

What to submit:

Each submission has to include:

README - file whose details are described below.
Hardware Projects - Submit the *.hdl you wrote.
Assembler Projects - Submit the *.asm you wrote.
Programming Projects - Submit only the source code of the program, as well as the Makefile.

README submission:

The README (and not README.txt nor readme...) file should include the following details:

In the first line should be the LOGIN(S) of the author(s), comma separated (and nothing else).
The personal details of the author(s) - name and ID.
The name of the project.
A list of the submitted files, with a one line description for each file.
Any remarks you have about this projecti, your implementations, etc.

You can use the sample README as template.
We will not read each README file so don't use it to pass messages to us.

How to submit:

The projects are submitted electronically. For each project create a tar file (and not rar nor zip...) called projX.tar (i.e. proj1.tar, proj2.tar, etc). The tar file should contain all the needed files without directories (unless it was in the project definition - hence the project files were under directories). Submit the tar via the course admin system that can be reached from the administratives page.
Submission time is Ross closing time for the submission day (14:00 for Fridays and 02:00 on the next day for Tuesdays).

Grading:

All projects are mandatory!
Since this is a very practical course, a big part of the grading is based on an automation system. Therefore:

All projects MUST compile & run in the university linux environment. Please test your code, README and tar file there BEFORE submitting.
Not following any of the above rules and failling the automated test because of a technical problem will cause 10 point reduction for each fault in each project!.

The news group is our tool to contact you all. It is your responsibility to read it regularly and every message send to the news group will be considered as known to all.
Clarifications or changes to the projects that will be posted until 2 days before submission date (Wendsday night for Fridays and Sunday night for Tuesdays) will be binding!

What if you can't finish the project on time?

Relax. All the projects in this course are highly modular, with incremental test files. Each hardware project consists of many chip modules (*.hdl programs), and each software project consists of many software modules (methods). It is best to treat each project as a modular "problems set", and try to work out as many problems as you can. You will get partial credit for your work.
If you feel you need an extension please email us IN ADVANCE.
In general we will not accept late submission without an approval.

What if your chip or program is not working?

It's not the end of the world. Hand in whatever you did, and explain what works and what doesn't in the README. If you want, you can also supply test files that you developed, to demonstrate working and non-working parts of your project. Instead of trying to hide the problem, be explicit and clear about it. You will get partial credit for your work.

Appeals:

1. Appeals will only be accepted within two weeks after the grades have been published.
2. The appeal should be sent by email and it's subject MUST be "Appeal - project X" (where X refers to the project number). You should send different appeal email for each project!
3. Most likely that if you lost points you have some problem in your code - please go over your code again and state what was the problem and why this should count less. We'll not upgrade your grade just because you asked nicley.
For example:

Repeating a mistake from exercise X to exercise Y is a valid reason for an appeal on exercise Y if you didn't get the grade for exercise X by the time you submitted exercise Y. (if you already got it and were aware of your mistake and didn't fix it in exercise Y don't appeal.)
Not following the guidelines (even if it's for the first time) is not a valid reason for an appeal.

5. Since we recheck your project, it is very possible that your grade after the appeal will be lower.

Interview:

Part of your grade will be an interview. The goal of the interview is to ensure that all the students understand the material and the projects they have submitted (Especially important since the submission is in pairs). The interview will be done in singles.
You will be asked about specific details from previous projects, design considerations and how you solved specific problems.
We'll expect each student to be completely familiarized with his projects.
You will also be asked general questions from the course material.