ARM project (De1, 15)
University of Cambridge, Department of Engineering
Academic year 2002-2003
Easter Term 2003
Project leader: Frank Stajano
Demonstrators: Dan Gordon, Panit Watcharawitch, Tom Kelly
This project is based on the ECAD
and Architecture workshops designed and lectured by Dr Simon Moore at the
Computer Laboratory of the University of Cambridge. Simon's
cooperation has been invaluable and is very gratefully acknowledged.
ARM project home |
Tasks (weeks): 1 |
Weekly mini-reports |
Final report |
Bonus track |
Departmental warnings |
Useful online references
This 4-week project sits at the boundary between hardware and
software. You will be designing hardware circuits and programming a
RISC processor. More specifically, you will build circuits by
programming an Altera FPGA in Verilog (a hardware description
language), and you will connect those circuits to an ARM 7 processor
that you will program in ARM assembly language.
The goal of the project is to build a mouse interface for the ARM
and write a rudimentary device driver allowing the ARM to read out the
absolute 2D position of the mouse.
This project runs in the Intel Lab (room SW11, second floor)
at the Computer Laboratory, William Gates
Building on the West Cambridge site. Follow the links for directions;
this is not on the main Engineering site.
Repeat the following pattern for 4 weeks, starting Monday 2003-05-12.
"Mandatory" means it's a timetabled session for this project. You have
to be there at those times or you will be penalized at the rate of 1
mark per hour missed. I will use some of this time to introduce you to
Verilog and ARM assembler. You will use the rest to program the
devices yourself. During these sessions you will each have access to
an individual workstation with the appropriately licensed software
tools, and you will be issued one teaching board each. Demonstrators
will be available to provide guidance and to help you using the tools
(though not to solve the assignments).
On top of the mandatory timetabled slots, you are expected to spend
about 12 more hours per week on your own on this project. You are
welcome to go to the Intel lab at any time during the opening hours of
the building and use the available facilities when it best suits
you. At those unsupervised times, however, only 6 workstations will be
equipped with teaching boards; the others will have just the software
Remember that your work for each week is assessed by a demonstrator
on the Thursday of that week, so you have no extra time to clean
things up afterwards.
In each of the four weeks of the project there is an assigned task
which requires you to program the FPGA, the processor or both. These
four subtasks build on each other.
- Electronic Dice in Verilog
- String sort in ARM assembler
- Mouse interface in Verilog
- Reading the mouse from the ARM
By the last session of every week you must submit a
mini-report; this includes giving a live demonstration of your
running hardware to one of the demonstrators. The mini-report is much
shorter than the usual "interim reports" of most other projects and
contains practically no prose. It consists of your commented
ARM/Verilog code plus brief answers to a couple of questions on that
week's task. You must submit your mini-report by the last timetabled
session of each week (Thursdays 09:00-11:00). This is a serious
deadline that nobody should miss: the penalty for late
demos/mini-reports is 3 marks per weekday (Mon-Fri), which
means you'd waste at least 6 marks since there is no session on
Fri. It is of course acceptable and laudable to submit a mini-report
ahead of time at some earlier session, although you don't get any
extra marks for this.
To submit a mini-report you must
collect three ticks in order, all before that week's deadline:
- Complete the program code (Verilog and/or ARM as appropriate)
required for that week's subtask, ensuring that it is properly
formatted and commented. Follow the format of the supplied template.
- Put answers to any questions in comments at the end of your code.
Ensure that you add the subtask's title and your name in a comment at
the top of the code. This set of source code files is your
- Show a running demonstration of your work to a demonstrator to
have it assessed. If the demonstrators points out any flaws, you are
allowed (but not obliged) to fix and resubmit, so long as it's done by
the deadline. On completion of this step, the demonstrator will give
you Tick #1.
- Email your mini-report as a file attachment to (not to my regular email address). If
your mini-report consists of more than one file, attach them all to
the same mail message. Do not zip, tar, gzip etc: just send the raw
source code (.s or .v). When I receive your correctly submitted mail,
I'll give you Tick #2.
- Hand in to any demonstrator your anonymous weekly feedback form
and, separately of course, a printed version of your mini-report with
its completed cover sheet. This gets you Tick #3.
All these steps must be completed before the end of the
corresponding Thursday session.
You must also prepare a final report of not more than 10 pages. See
the bottom of the page for
week 4 for advice on how to structure it.
To submit it:
- Email a PDF version of the final report as a file attachment to
(not to my regular email
address). Do not zip, tar, gzip etc: just send the raw PDF.
- Hand in a printed version of the final report, with your
first three mini-reports as an appendix, to the Teaching Office.
Both of these must be received by 17:00 on Friday 6th June 2003 (last
day of week 4 of the project, but not a timetabled session). This is
the most serious deadline of the project: the department will grant no
extensions to it.
Each mini-report is worth up to 15 marks, for a subtotal of 60
marks. The criteria that will be used for assessment are the
following, most important first.
- Demonstrating a live working solution
- Clearly commenting and formatting the code
- Demonstrating good programming style
- Correctly answering the questions
The final report is worth up to 20 marks and will be assessed on the
- Giving a logical and complete account of what was done
- Demonstrating a grasp of the core ideas and skills acquired during the project
- Clarity of ideas
- Clarity of language (readability and correctness of your English prose)
The total for the whole project is therefore 80 marks.
Note that this is not a team project and all work must be
carried out individually.
The time it takes people to complete the standard tasks varies
greatly. For those of you who can complete the standard tasks in much
less time than allocated, a bonus track is available. Note in passing
that completing a weekly task as soon as possible doesn't usually
yield the highest marks. It is advisable to complete the 4 tasks of
the standard track with elegance and style before devoting time to the
The main deliverable for the bonus track is a Verilog module that
simulates a two-digit LED display on a VGA monitor. You will integrate
it in your week 4 solution as a plug-in replacement for the standard
LED display hardware of the teaching board.
Unlike what happens with the standard tasks, there will be no
handholding. You will have to find out by yourself how to drive the
monitor (with care so that you don't blow it up) and all the design
choices will be your own.
To qualify for the bonus track you must also complete two auxiliary
- Verilog: implement a 2-second delay linesomething behaving
like this delay.sof. You will find useful hints in
Simon Moore's ECAD
Workshop 2. Note, however, that the "delay" module on that page,
unlike the one contained in this .sof file, does not really delay an
- ARM assembly language: implement the prime number program from ECAD
Bonus track submission
Do all of the following in order.
- Submit all 4 weekly mini-reports as usual.
- Submit (in the same sense of collecting three ticks) the source
code for the two auxiliary deliverables. Until you do this, your bonus
track deliverable won't be looked at (let alone marked).
- Submit (three ticks again) the source for the main deliverable.
- Write a report about the main deliverable, but not the auxiliary
ones, in at most 2 sides of A4 and include it as part of your final
Bonus track marking
- The two auxiliary deliverables attract no marks, but are required
- The source code and live demo for the main bonus deliverable is
worth up to 15 points and replaces, at your own risk if you submit it,
the lowest-scoring of your first three mini-reports.
- Up to 5 bonus points (yes, for a total of 85/80, later clipped to
80) may be awarded to the 2-page report about the main bonus
- For non-attendance at timetabled sessions you will lose 1 mark per
- For late submission of interim reports you will lose 3 marks per weekday.
- No extension to the final report deadline of 17:00 on Friday 6
June will be permitted.
- You will have to sign a declaration that you are submitting your own work.
- You will not receive any indication of any marks for your interim
or final reports. Your college may inform you of your final mark after
publication of the final class lists.
- Any applications for allowances for illness must be submitted by
your College Tutor to the Teaching Office as soon as possible. It must
be received by Monday 9 June.
Useful online references
- Dan Hyde's Verilog
handbook (also available as PDF)
is a fairly complete description of the language.
slides (PDF) by Donald Thomas, co-inventor of Verilog.
- The Doulos tutorial on Verilog.
- Optimagic has a small link farm of VHDL
references and tutorials.
- Peter Cockerell's excellent 1987 book ARM
Assembly Language Programming (HTML and PDF) is a useful
reference to keep around while writing code, particularly chapter 3, The
- Concise summaries can also be found in Simon Moore's Computer
Design (PDF) course notes, in lectures 3 and 4.
- I can't put a link to it from here, but the ARM developer suite
comes with a library of "Online books" about the tools and the ARM
processor itself. You can access this documentation from the Start
menu: the shortcut is in the same menu from which you launch Code
ARM/Altera teaching board
- The home
page and FAQ
for Simon Moore's ECAD and Architecture workshops at the Computer
Laboratory on which this project is based.
for the board, from an extensive list of memos
about the Altera/ARM hardware.
Related lecture course material