Computer Architecture 2022-23
Assessed Exercise 1
— State Machine Circuit —
Introduction
The purposes of this exercise are to learn how to design a simple synchronous
digital circuit that implements a state machine, how to specify it in a hardware
description language, and how to test it via simulation. The specification and
simulation will use Hydra, a functional computer hardware description language.
The exercise
Design and implement
• Two circuits, as described below, which should all be in a file Traffi-
cLight.hs. • A simulation driver for each circuit; both of these should be in a file named
TrafficLightRun.hs
• Suitable test data that demonstrates the correct functioning of each cir cuit, which should be included in TrafficLightRun.hs. • There should be a main function in TrafficLightRun.hs that runs all of
your test cases.
Informal specification of the circuit
The circuits are traffic light controllers. There are two versions.
Version 1
The circuit controller1 has one input, a bit called reset. This would be connected
to a pushbutton. The reset button should be pushed once to start the circuit,
and then in normal use it would never be pressed again. We model this by
defining the value of the reset input bit to be 1 during the first clock cycle, and
0 thereafter.
There are three outputs, each of which is a bit. The outputs correspond to
green, amber, and red, and they determine whether the corresponding traffic
light is on. At all times (after reset has been pressed and the circuit is running)
one of the three output bits should be 1, indicating that the corresponding traffic
light should be on, and the other two bits should be 0. The outputs should run
through a fixed sequence: green, green, green, amber, red, red, red, red, amber,
and then it repeats.
1
Version 2
The second version, controller2, is intended for a pedestrian crossing. There
are three lights for traffic (green, amber, and red) and also two lights for the
pedestrian (wait and walk). There are two input bits: a reset pushbutton, and
a walkRequest which is 1 when a pedestrian presses the Walk pushbutton.
Normally the outputs indicate green/wait. However, when the walkRequest
button is pressed, the traffic light changes to amber, and then the traffic light
changes to red and the pedestrian light turns to walk for three clock cycles. Then
the system displays amber/wait and then returns to its normal state green/wait.
Furthermore, the traffic engineers want to know how often the walkRequest
button is pressed. To measure this, there is a 16-bit counter walkCount. When
the Reset button is pressed, the value of WalkCount is set to 0 at the next
clock tick. When the walkRequest button is pressed, walkCount should be
incremented at the next clock tick.
To summarise, the inputs are: reset (a pushbutton) and walkRequest (a
pushbutton). The outputs are: green, amber, red, wait, walk (each is 1 bit),
and walkCount (a 16-bit binary integer).
You may notice that the specification of the problem doesn’t say what to do
in a few subtle situations. For example, what should happen if the walkRequest
button is pressed when the system is in the red/walk state? You may adopt
any reasonable policy you like for these situations. In the real world, you (the
engineer) might go back to the customer to discuss what to do. It is common
for the requirements of a project to evolve during the implementation. Actually,
that’s one of the reasons that good engineering includes making your solution
maintainable as well as correct.
The point of this exercise is to gain some experience with a simple control
circuit, and to use some of the building block circuits. The exercise as described
doesn’t account for some real world issues, which you can ignore:
• In the real world, the reset button and the walkCount display would be
hidden inside the box containing the electronics, while the walkRequest
button would be out where a pedestrian could see and press it, and the
various light outputs would control the actual light bulbs.
• In the real world the clock cycles would be too short, so each light would
be held for a larger number of clock cycles. For example, the amber phase
might last for a million cycles and green/red would be correspondingly
longer.
Work in small groups
This assessed exercise should be carried out in a small group consisting of two
to three students. Any amount of discussion and shared work within the group
is fine, and the product you hand in counts fully for each member of the group.
One member of the group should submit the exercise on Moodle. As stated
below, the submission must identify all the members of the group, not just the
one who submitted it.
To get started, talk to fellow members of the course, and organise your group.
Please email the lecturer with the names and matriculation numbers of everyone
2
in your group. Use CA group members as the email subject line. When you
are finished, the file should be submitted by just one member of the group; it
doesn’t matter which one.
Handin
Submit your solution via the Moodle page; see the page for detailed instructions
on submission.
Your group’s submission should consist of a single file named either Exer cise1.tgz or Exercise1.zip. Other formats, such as rar, are not acceptable. This
file defines a directory named Exercise1. It is good practice that unpacking your
file should produce a directory — it is unprofessional and bad style just to dump
a lot of files into the user’s directory. The directory Exercise1 should contain
the following files:
• StatusReport.txt — a text file that gives the name and matriculation num ber of each member of the group, as well as your status report
• TrafficLight.hs — the circuit definition file, containing the two circuit
specifications
• TrafficLightRun.hs — definition of the simulation drivers as well as suit able test data. This should define main :: IO () so that running main will
execute your tests for both circuits.
The status report, StatusReport.txt, should be a plain text file. The opening
lines should follow a key-value format, where each keyword is followed by a
colon : and a space, and then the value is just text. You should define the keys
that are illustrated in the following example of a status report. There should be
one author line for each member of your group; the author line contains your
name, followed by a comma, followed by your matriculation number. Here’s an
example of the format:
course: CA
exercise: 1
date: 2022-12-11
After these opening lines, the status report should describe the status of your
solution. It should say whether each part of the exercise has been completed.
Does it compile? Does it appear to work correctly? How did you test it? Are
there any aspects that appear to be not quite right? Are there any especially
good aspects you would like to highlight?
If your status report contains several paragraphs, separate them with a blank
line. You can explain your approach to solving the problem in the status report,
or you can include your documentation as comments in the source program.
3
Assessment
The exercise will be marked out of 100 marks, and it counts for 10% of the CA
assessment. The two exercises together are worth 20% of the assessment, while
the examination is the other 80%.
On this exercise, Version 1 and Version 2 have equal weight (each is worth 50
marks). Assessment will be based on (1) handing something in; (2) a reasonable
approach to the problem; (3) a correct solution; (4) good style in the circuit
design; (5) a working simulation driver; (6) suitable test data.