Appendices
E
RISC-V Processor Design Project Logistics
Version:
git changeset: 170:373da60b63aa0705868d6a651c2d72842dcea0bc,
Fri Apr 10 14:52:08 2020 +0100
Figure E.1: This project
will give you firsthand
experience modifying and
evaluating an instance of
the exciting new RISC-V
processor architecture,
using the iCE40 miniature
field-programmable gate
array (FPGA).
All software eventually works;
all hardware eventually fails.
— Clod Berrera.
Hardware implementation using field-programmable gate arrays (FP-
GAs) or using custom integrated circuits provides an alternative method of
implementing computations. Software reuses a small number of primitives
(instructions) over and over again in time to implement a given computation.
The domain of computer architecture deals with designing those primitives
used by software and implementing them so that they are efficient accord-
ing to some relevant measure such as time, energy, or implementation size.
This IIA project will give you an opportunity to gain firsthand experience
in modifying a state-of-the-art computer architecture, the RV32I 32-bit inte-
ger variant of the RISC-V
1
instruction set architecture. The project assumes
1
RISC-V is pronounced
“RISC five”, not “RISC
vee”.
you are already familiar with using the Unix command line and assumes
you already have basic familiarity with git (the command-line program) and
GitHub (the website). The project will require you to first become familiar
with the concepts of processor instructions, processor state, processor mi-
4 phillip stanley-marbell
croarchitecture, and the microarchitectural technique of pipeline parallelism.
You will then explore how to implement basic hardware designs using the
Verilog hardware description language and you will use this understanding
to collaborate in a team improve the performance of the processor microar-
chitectural implementation.
E.1 Course-Level Intended Learning Outcomes
At the end of this project, you should be able to: demonstrate an understand-
ing of basic processor architecture by modifying an instance of a processor
emulator for the RISC-V architecture to add a new instruction; create new
hardware designs in the Verilog hardware description language; synthesize
Verilog hardware designs to the iCE40 FPGA using open-source FPGA tools;
use your understanding of Verilog and the iCE40 FPGA tools to modify the
Verilog design of a RISC-V processor design and evaluate it on an FPGA; re-
duce the resource usage and improve the performance of a processor design.
E.1.1 Things to look out for
Concepts people sometimes get confused by in this chapter include:
1.
E.1.2 The muddiest point
As you go through the material in this chapter, think about the following two
questions and note your responses for yourself or using the annotation tools
of the online version of the chapter. You will have the opportunity to submit
your responses to these questions at the end of the chapter:
1. What is least clear to you in this chapter? (You can simply list the section
numbers or write a few words.)
2. What is most clear to you in this chapter? (You can simply list the section
numbers or write a few words.)
E.1.3 Learning outcomes pre-assessment
Complete the following
quiz to evaluate your prior knowledge of the material
for this chapter.
E.2 Organization
Over the course of the next four weeks, you will work in a team of three to:
foundations of embedded systems 5
1. Week 1: Get started: Three team members get the processor design up
and running in the processor emulator (Sunflower) and running manually
on the iCE40 FPGA. The first interim report (individual) is due at the end
of week 1 of the project. The first report will analyze the performance,
power dissipation, and resource usage of the baseline processor design in
the FPGA and compare it to the minimal FPGA design (blink). The three
analyses (performance, power, and resource usage) will each be performed
by a different member of the team) and the interim report is worth 20
points.
2. Week 2: Modify the design: Propose methods for improving the arith-
metic/logic unit (ALU), branch predictor, and cache (each performed by a
different member of the team) and start implementing them if you can.
3. Week 3: Modify the design: Implement the methods proposed in the
previous week (each performed by a different member of the team). Re-
run the performance, power, and resource usage evaluation that you did
in week one. The second interim report (individual), due at the end of
week 3, is worth 30 points.
4. Week 4: Group demo on the final Tuesday and final (individual) report
due on the Friday of week 4, worth 30 points.
E.2.1 Content
The project will introduce you to the concepts and tools for designing and
modeling microprocessors and for implementing hardware designs in field-
programmable gate arrays and evaluating their hardware resource usage,
performance/timing, and power dissipation.
The first 15 minutes of each demonstration session will cover concepts
relevant to your tasks. In addition, there will be short videos of these and
other basic concepts posted to the course Moodle at the beginning of each
week. We will refer to these short videos as fascicles.
E.2.2 Meeting times
There are two timetabled meeting times each week covering a total of six
hours of timetabled activities per week:
• Fridays 09:00 to 11:00 and 14:00 to 16:00
• Tuesdays 11:00 to 13:00
In addition, the teaching staff will be available on Wednesday afternoons.
The demonstrators will take attendance at each session and the penalty for
missing timetabled sessions is one mark per hour. For the interim reports,
6 phillip stanley-marbell
the penalty for late reports is 3 marks per day. Having problems with your
personal computer is not an acceptable reason for late work.
E.2.3 Reports and Grading
There are two interim reports and one final report:
1. Interim report 1: In this first interim report, due at the end of the first
week of the project, you will work as a team to characterize the perfor-
mance, power, and resource usage of the baseline RISC-V processor design
provided to you and each team member will report on their component of
the characterization.
2. Interim report 2: For the second interim report, due at the end of the
third week of the project, you will describe your progress in improving the
performance of the processor design and each team member will report on
the result of their changes to the design. You will need to work together
to ensure that the changes made by one part of the design improvements
do not counteract the benefits of the other, and that all the changes go
towards improving the design in terms of the three criteria of performance,
resource usage, and power consumption.
3. Final report: For the final report, you will detail the design and implemen-
tation tradeoffs that you made as a team, to achieve the best combination
of performance, power dissipation, and resource usage for your RISC-V
processor design modification on the iCE40 FPGA.
E.3 Sessions
The project is split up into 12 sessions over four weeks.
E.3.1 Session 1 (Tuesday morning)
This is the introductory lecture. Watch the introductory lecture video and use
the provided resources to help you get to the point where you understand all
the content of the introductory video. The self-assessment quiz will help you
verify that you have understood what is required of you.
E.3.2 Session 2 (Tuesday afternoon)
The objective of this project is that you should be able to recreate everything
you do in this project, on your own, at the project’s completion. We therefore
introduce you to a set of tools that are completely open-source and we guide
you through the process of setting up the tools on a Linux system.
We have already installed all the tools on the coursework server and you
do not have to re-install them in your account on the server. You should
foundations of embedded systems 7
however clone the course tools to your account and verify that you can follow
along with the examples in the videos and notes.
An important challenge for you in this first week will be to master using
git. The appendices give a brief overview of git but you will have to invest
the time digesting how git works. By the fourth and fifth sessions, you will
need to come up with a strategy for using git to keep track of the versions
of your design. One suggestion is for you to use branches to keep track of the
different versions of your hardware and to switch between branches during
your characterization work and eventually to use merging to merge all your
versions into a single branch.
As you work in a team, you will use git to coordinate between the dif-
ferent members of your team. Consider creating a single fork of the course
repository that all your team members have write access to. You may also
need to update your fork if new material is added to the main course repos-
itory during the project. Again, the appendix gives an overview of how to
use git but you will have to invest additional time on your own to practice
updating a fork whose parent has been updated. Your homework is to read
the appendices covering git and Makefiles, and the manuals for the FPGA
tools.
E.3.3 Session 3 (Friday morning)
In this session, you will evaluate power, performance, and resource usage of
a simple design on the iCE40 FPGA. Before coming to class, please read the
manual for the iCE40 FPGA, and the user guides on clocks, DSP blocks, and
memories. Start thinking about how you would validate correctness of each
of the measurements you perform.
E.3.4 Session 4 (Friday afternoon)
Revisit your power, performance, and resource usage measurements and cre-
ate as comprehensive a characterization as you think is possible. Measure
and quantify everything that you possibly can. Think about how you will
present the properties you measure, both to your team members, as well as
in your report. Compare your measurements to the datasheet. Discuss your
characterization with your team members. Have a rough draft of your report.
Your homework is to watch the Verilog, pipelining, and performance analysis
fascicles and to read the article by Emma.
2
Do the fascicle videos give you
2
Emma
1997.
any clues for how you might begin optimizing your design for performance
power and resource usage?
8 phillip stanley-marbell
E.3.5 Session 5 (Tuesday morning)
Come up with a git versioning strategy. We recommend you have one branch
for each architectural change so you can switch between branches to test
different candidate versions. Draw up a list of your planned changes and get
feedback. Homework: watch the RISC-V ISA fascicle. Your homework is to
read the articles by Gustafson
3
and Amdahl.
4
3
Gustafson
1988.
4
Amdahl
1967.
E.3.6 Session 6 (Tuesday afternoon)
Implement your first changes. Become confident that you can switch between
your different version branches using git.
E.3.7 Session 7 (Friday morning)
Measure the effects of your first changes. Come up with a coherent plan
for combining your changes. Agree on a hypothesis for how you think your
power/perf/resource changes will interact. Jointly prepare this hypothesis
in a 150-word statement and discuss the statement with the project leader.
Homework: watch the cache fascicle.
E.3.8 Session 8 (Friday afternoon)
Implement your second (or third, or fourth) changes and start characterizing
them.
E.3.9 Session 9 (Tuesday morning)
The third week of the project is intended to be free-for m. By this point,
each of the three team members should have proposed changes that they
believe will improve their criteria (performance, power, or resource usage).
By this session you should have a clear plan for implementing your proposed
changes and you should come up with a proposal for validating correctness
of your overall implementation ahead of the competition in the following
week.
E.3.10 Session 10 (Tuesday afternoon)
The third week of the project is intended to be free-form. By the middle of
the third week you should be getting close to completing the implementation
of all your proposed designs.
E.3.11 Session 11 (Friday morning)
Use this time to finalize your implementation.
foundations of embedded systems 9
E.3.12 Session 12 (Friday afternoon)
The fourth week of the project has the competition on Wednesday afternoon
and the final report due on Friday afternoon. By Tuesday morning your
design should be essentially complete and you might want to start taking
detailed measurements for your final report.
E.3.13 Final week
The competition will take place in the final week, after Tuesday (exact day of
the week and time will be decided based on availability). In the competition,
we will provide you with a pre-compiled binary that you need to execute
correctly on your modified processor architecture. We will provide the binary
the morning of the competition so you will not have much time to tailor your
processor to the binary.
The final report is due Friday afternoon. You might need to come in to the
lab on Friday morning to perform additional measurements for your final
report.
E.4 Progress Checklist
You can use
this checklist to track a list of suggested and required tasks dur-
ing the project. You can submit your responses to the checklist incrementally
and save the URL you get in response to pace your activities and track your
progress over time.
E.5 Exercise
Complete the following
quiz to evaluate your understanding of the material
for this chapter.
10 phillip stanley-marbell
E.6 The Muddiest Point
Think about the following two questions and submit your responses through
this
link.
1. What was least clear to you in this chapter? (You can simply list the section
numbers or write a few words.)
2. What was most clear to you in this chapter? (You can simply list the
section numbers or write a few words.)
foundations of embedded systems 11
E.7 Further Reading
The following resources will be useful as you investigate methods to reduce
resource usage, improve performance, and reduce power dissipation:
1. Computer Organization and Design, The Hardware/Software Interface, RISC-V
Edition, ISBN: 978-0128122754. This book is the authoritative introductory
text on computer architecture. This particular edition is revised to provide
examples from the RISC-V ISA.
2. The RISC-V Reader, ISBN: 978-0999249116.
3. Digital Design: An Embedded Systems Approach Using Verilog, ISBN: 978-
0123695277. This book is a detailed reference on the Verilog hardware
description language and will be valuable as you investigate methods to
reduce resource usage.
4. The articles by Emma,
5
Gustafson,
6
and Amdahl
7
provide a useful frame-
5
Emma
1997.
6
Gustafson
1988.
7
Amdahl
1967.
work for you to think about performance in computing systems.
Bibliography
1. Amdahl, Gene M (1967). “Validity of the single processor approach to
achieving large scale computing capabilities”. In: Proceedings of the April
18-20, 1967, spring joint computer conference, pp. 483–485 (cit. on pp. 8, 11).
2. Emma, Philip G (1997). “Understanding some simple processor-performance
limits”. In: IBM journal of Research and Development 41.3, pp. 215–232 (cit. on
pp.
7, 11).
3. Gustafson, John L. (May 1988). “Reevaluating Amdahl’s Law”. In: Com-
mun. ACM 31.5, 532–533. issn: 0001-0782. doi: 10 . 1145 / 42411 . 42415.
url:
https://doi.org/10.1145/42411.42415 (cit. on pp. 8, 11).
