ECAD and Architecture Practical Classes
Introduction
The ECAD and Architecture Laboratory sessions are a companion to the Introduction to Computer Architecture course. The objective is to provide experience of hardware design including use of a small embedded processor. It covers hardware design in SystemVerilog and embedded software design in RISC-V assembly.
Prerequisites
This course assumes familiarity with the material from Part IA Digital Electronics, although we will use automated tools to perform many of the steps you might have done there by hand (for example, logic minimisation).
We will be using a Linux command-line environment to complete the ticks. We provide scripts and guidance on what you need, however you may find it useful to review Unix Tools, in particular basic navigation such as ls, cd, mkdir, cp, mv. We'll be using the GCC toolchain to assemble your code, and Makefiles to automate builds. You may well wish to use git for version control and backing up your work.
Practicalities
The course runs over the 8 weeks of Michaelmas term. The course has been designed so you can do most of the work at home or at any time you wish. Moodle VPL is used to submit and assess your work. While you can edit and debug your solutions on the Moodle system for the first three ticks, you'll probably find it easier to debug the code first before submitting to Moodle. Moreover, the last tick requires that you collect simulation results that are then submitted to Moodle. See the Setup tab for options to run the tools.
You will see that there is an online tutorial component to these practicals. The first four tutorials cover more details about programming in SystemVerilog, the hardware description language very commonly used in industry and for the hardware design work in these practicals. Ticks 1 and 2 are exercises in SystemVerilog. For Tick 3 you need to write some RISC-V assembler and run it on an instruction set simulator. In tick 4 you will run your code on a small RISC-V called Clarvi written in SystemVerilog. You will simulate this hardware design running your code in order to obtain cycle-accurate performance measures of your code running.
Assessment
In a similar way to other practical courses, this course carries four 'ticks' with submission via Moodle. Everyone should expect to receive these ticks, and those who do not should expect to lose marks on their final exams.
Ticks 1-3 are automatically assessed via Moodle. Tick 4 is submitted via Moodle but requires a short report that will be assessed in person and will typically require an short in-person or online meeting to discuss your solution and check what you have learnt. See the Moodle pages for tick deadlines.
Scheduling
Timetabled laboratory sessions: Fridays and Tuesdays 2-5pm in Michaelmas term.
Tick deadlines: see the ECAD+Arch Moodle pages for deadlines.
Moodle submission: see the Moodle tab.
We encourage you to complete ticks early so that if you do need a bit of help you can ask a demonstrator during the Tuesday or Friday afternoon sessions. We will not typically offer help outside of these sessions unless we are informed by your Director of Studies that extra help is warranted. For example, hospitalisation is a good reason, but being disorganised is not!
Help from demonstrators
We're running the course in a hybrid mode. We will provide online help sessions via Microsoft Teams as well as in-person lab sessions on Fridays and Tuesdays 2-5pm during term. You are encouraged to attend the in-person sessions so that you can easily get help from demonstrators and your colleagues.
If you are having difficulty accessing both Moodle and Teams, or find bugs in these practicals, please email the course lead: simon.moore at cl.cam.ac.uk.
Please note that the practical sessions were revised over the summer of 2025. The course lead and some of the demonstrators have tested the setup. However, as experienced hardware hackers, they may overlooked missing information that will not be obvious to you as a beginner. So please work with us to improve the practicals!
Collaboration
When we have done these labs in person, we have often found they worked well when doing them collaboratively. While your work must be your own, students can work together and help each other, and demonstrators contribute advice and experience with the tools. But we do expect that you thoroughly understand the work you have submitted, which can really only come from having completed the work yourself.
Feedback
We revise the course each year, which may cause new bugs in the code or the notes. The creators Simon Moore and Theo Markettos appreciate constructive feedback.
Credits
This course was written by Simon Moore and Theo Markettos, with portions developed by Robert Eady, Jonas Fiala, Paul Fox, Vlad Gavrila, Brian Jones and Roy Spliet. We would like to thank Altera, Intel and Terasic for funding and other contributions.