|
|
|
Guidelines
|
- Individual Work Policy
- Students in this course are allowed (and encouraged!) to submit homework
assignments in PAIRS. 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.
- 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. Put a documentation every few lines (usually something like "*a=42") - it
will help you too
- Proggramming Projects - The programming exercises can be done in Java
or C/C++. If you want to use other language, contact the TA before. Although this
is not plab, points will be taken for messy, unmodular or under-documented code.
Since we require a unified inteface 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. Don't forget to "chmod 755" it in
order to make it an executable.
All programming exercise must include a makefile. Calling "make all" should compile
the sources and create the requried executable. You can refer to the sample makefiles
for Java and C/C++.
- What to submit
- Each submission has to include a plain text README file whose details are described below.
- Hardware Projects - Submit the *.hdl you wrote.
- Assembler Projects - Submit the *.asm you wrote.
- Proggramming Projects - Submit only the source code of the program, as
well as the makefile.
- How to submit
- The exercises are submitted electronically. For each project create a tar file
called projX.tar (i.e. proj1.tar, proj2.tar, etc). Submit is using the
course admin system that can be reached from the administratives
page.
- README submission
- The 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).
- The name of the exercise.
- A list of the submitted files, with a one line dexcription for each file.
- Any remarks you have about special cases, implementations, additional features
or anything else you think the checker should know.
You can use the sample README as template.
- 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.
- 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. 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 send by mail to the course email. The subject of the mail should be "Appeal - project X"
3. Since we recheck every file you submit, it is very possible that your grade after the appeal will be lower.
- Interviews:
-
This year we will hold interviews with all students. There goal of these
interviews is ensure the students understand the material and the exercise they
have submitted (Especially important since the submission is in pairs). The interviews will be done in singles.
You will be asked about specific details from previous exercises, design
considerations and how you solved specific problems.
Remember, the exercise grade is part of your total course grade, and should be
taken seriously.
There will be 2 interviews throughout the course.
|
|