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 specifification and simulation will use Hydra, a functional computer hardware description language.
Design and implement
- Two circuits, as described below, which should all be in a fifile Traffiffiffi- cLight.hs.
- A simulation driver for each circuit; both of these should be in a fifile named TraffiffifficLightRun.hs
- Suitable test data that demonstrates the correct functioning of each circuit, which should be included in TraffiffifficLightRun.hs.
- There should be a main function in TraffiffifficLightRun.hs that runs all of your test cases.
Informal specifification of the circuit
The circuits are traffiffiffic light controllers. There are two versions.
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 defifining the value of the reset input bit to be 1 during the fifirst 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 traffiffiffic 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 traffiffiffic light should be on, and the other two bits should be 0. The outputs should run through a fifixed sequence: green, green, green, amber, red, red, red, red, amber,and then it repeats.
The second version, controller2, is intended for a pedestrian crossing. There are three lights for traffiffiffic (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 traffiffiffic light changes to amber, and then the traffiffiffic 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 traffiffiffic 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 specifification 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 fifine, 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 in your group. Use CA group members as the email subject line. When you are fifinished, the fifile should be submitted by just one member of the group; it doesn’t matter which one.
Submit your solution via the Moodle page; see the page for detailed instructions on submission.
Your group’s submission should consist of a single fifile named either Exercise1.tgz or Exercise1.zip. Other formats, such as rar, are not acceptable. This fifile defifines a directory named Exercise1. It is good practice that unpacking your fifile should produce a directory — it is unprofessional and bad style just to dump a lot of fifiles into the user’s directory. The directory Exercise1 should contain the following fifiles:
- StatusReport.txt — a text fifile that gives the name and matriculation number of each member of the group, as well as your status report
- TraffiffifficLight.hs — the circuit defifinition fifile, containing the two circuit specififications
- TraffiffifficLightRun.hs — defifinition of the simulation drivers as well as suitable test data. This should defifine main :: IO () so that running main will execute your tests for both circuits.
The status report, StatusReport.txt, should be a plain text fifile. 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 defifine 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:
author: Jane Doe, 9875434
author: John Smith, 12345678
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.
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.