For your reference, this circuits simulates a set of traffic lights that cycle through a sequence of Red, Red+Amber, Green, Amber, as illustrated in the first example of the ECAD lecture notes.
This will open an editor window in which you can view (and edit!) the verilog file.
If it doesn't, check that the title bar of the MAX+Plus
window indicates the right project name - it should be the same as the path to
tlights.v, without the .v
extension - mine says
z:\lab1-tlights\tlights
. If it isn't, you didn't do step 1 above right.
Otherwise, you may not have downloaded the tlights.acf
file, which is where the assignments should come from - close the
Assign | Device... dialogue box and start
again.
When you assign pins in the future, you'll need to make sure you've assigned the right sort of device beforehand.
We can now compile the project. Open the Compiler by choosing
MAX+Plus II | Compiler, or clicking on the
shortcut button, which looks like this: . Switch off the slightly unstable Quartus Fitter by selecting Processing | Fitter Settings and unchecking Use Quartus Fitter for FLEX 10K and ACEX 1K Devices. Then click on Start.
Once the Quartus Fitter option has been set for a project it does not need to be set again. A quicker way to start a compilation is to choose File | Project | Save & Compile,
or click on its shortcut button, which looks like this: .
The software should now compile the design. It may bring up a messages window to complain about the fact we have made pin assignments. You can ignore this.
In compiling, it will generate many files, of which some are useful, and some aren't! At present we are interested in tlights.sof, which is the file used to program the FLEX chip.
In the case there are three boards. The one on the left is the Altera board, which we are using for this lab; the one on the right is the ARM board, and the board underneath links them together and provides a power supply.
The Altera board has two Programmable Logic Devices; the rearmost one is the one we shall be using, and is called the FLEX; its programmable element is an SRAM, meaning it must be reprogrammed whenever it is first turned on.
The frontmost device is the much less powerful MAX. Its programmable element is an EEPROM, meaning it retains its configuration even when powered off. It has been programmed to protect the ARM when both boards are being used, since it would otherwise be possible to short out the ARM's pins. All signals between the FLEX and the ARM pass first through a resistor, and then the MAX. If the MAX detects that a short has occurred, it turns off all its outputs and displays "Er" (for error) in the LED segments. There is also a switch to separate the two boards - it is the very first switch, on the right of the board. It should be switched up for this lab, to separate the boards. Check this is the case.
The board is programmed via an interface called JTAG. This is very flexible, but we shall only be using it to program the FLEX chip. Check that the jumpers are set correctly for this: from the back, they should be to the left, left, right and right.
The data for the JTAG interface comes down the ribbon cable going to the connector on the back of the box. This short bit of cable is called the ByteBlaster, and it converts parallel data from the computer into the JTAG format. Of course, both the parallel cable and the power cable have to be connected to your computer before anything will work!
At last we can program the chip. This is done as follows:
Next, we'll investigate the use of the simulator, and some of the difficulties associated with using it.
First open the Waveform Editor, using MAX+plus II | Waveform Editor. This produces a blank .scf (simulator control file), which is where we enter the waveforms for the inputs to the simulation, and specify the outputs we wish to monitor.
First of all you need a clock input. To create this, select Node | Enter Nodes from SNF... (the SNF is a file created during compilation - it stands for Simulator Netlist File). Ensure that Inputs is ticked (since we wish to find an input), and that Node/Group contains "*". Click on List. This will produce a list of nodes and groups of the given types and matching the given name ("*" matches anything). We want "ck", so select this from the list and click => to transfer it to the list of nodes to be added to the .scf. The dialogue box should now look like this:
Finally, click on OK. This will add a waveform for the
clock input, but it is assigned a logic zero by default. Reselect the
waveform by clicking on it in the Name or Value
columns. The blue icons on the toolbar on the far left allow you to
assign a value to the selected bit of waveform. We want the clock
button, which looks like this: .
In the resulting dialogue box, enter a Clock period of 40ns and a multiplier of 1, before clicking OK. If the period field is greyed out, turn off Options | Snap to Grid
Go back to the Enter Nodes form SNF dialogue box (note that you can also open this from the menu produced by right-clicking in the Waveform Editor Window); in a similar way to before, add "|clockdiv:clockdivA|counter", "ledsA0", "ledsA3" and "ledsA6" to the SCF (some of these are outputs, and some groups, so you must turn on these options in the dialogue box to find them). The waveform window should now look like this:
Now save the Waveform file as tlights.scf. Open the
simulator by clicking this button: . Click on Start to start the
simulation - this will update the waveform window to show what has
happened. Note that the counter counts correctly, but the LED outputs
are stuck at 1.
Note that you can click on the waveforms - this should give a vertical blue bar (if you get a small black section, the editor thought you were dragging to make a selection - try again, being careful to click quickly and keep the mouse still.) The Value column gives the values of the signals at the blue bar. You can move the bar between events using the arrow keys or the arrows next to the Ref box.
You will notice that the LED outputs are stuck at 1 in the simulation. Why is that? How can you modify the Verilog so that you can exercise the traffic light sequencer?
Once you've done that, check the values. Is the circuit self-starting? Can it enter a dangerous sequence? Can you produce one that never will? (There are no extra marks for attempting this optional task, and the corresponding code must not be submitted. The journey is the reward.)
Now we'll take the Verilog one stage further - in this project, you should end up with a working electronic die; however, it is up to you exactly what form the system will take.
You should aim for a working project that produces a random number, between 1 and 6, each time a button is pressed. You may want to blank the display while the button is being pressed, but that is not necessary. The usual approach to this is to implement a counter which is clocked faster than the eye can see. While the button is pressed, the counter counts, and when the button is released, the current value of the counter is frozen, and appears on the display. As long as the counter is clocked at a sufficiently high speed, the effect should be that of randomness.
If you find this easy and have time to spare, you will learn something useful by designing a circuit that will roll two independent dice instead of just one. (There are no extra marks for attempting this, and the corresponding code must not be submitted. The journey is the reward.)
Before we begin, we need to set up the FLEX chip. Download the file dice.acf - this contains many useful settings, like pin assignments. Make a new directory called "lab1-dice", and place this file inside.
To start a new project, load the Max+PLUS II software, and select the menu option File | New. In the dialog box, select Text Editor File. You should be presented with an empty editor window. Enter the following template for the top level module (the inputs and outputs mirror the definitions in the .acf file):
module dice(ck, button1, leda, ledb); input ck; input button1; output [7:0] leda; output [7:0] ledb; endmodule
You will also need the HexToLEDs.v file. Download this into your project directory. It provides a module with the signature module HexToLEDs( datain, ledA, ledB ); where datain is an 8-bit input, and ledA and ledB are the bottom 7 bits of the outputs to the digit displays.
Undoubtedly, you will want to write a module that counts from 1 to 6. It should take two inputs - the clock, and an input telling it whether to advance or not. Combining this into one input is generally not safe practice - it is not a good idea to gate a clock, as it causes problems with propagation. The module should output a binary value on a three or four-bit data bus. (As a module designer, why would you choose one over the other? Can you see the merits of both choices?)
You can output this counter to bits 0-2 or 0-3 of the HexToLEDs. You can assign the remaining bits of the HexToLEDs input to zero.
Save all your code in a file called "dice.v" in the new lab1-dice directory. Your top-level module must have the same name as the filename (without the ".v"). Compile, download, and run the program.
To obtain additional debugging from the synthesis tool turn on the Design Doctor by opening a compiler window and then use Processing | Design Doctor. Under Processing | Design Doctor Settings... select the FLEX Rules option.
How good a random-number generator do you think this is? And would your answer be the same if you were rolling two independent dice?
W1-Q2: Is there any need to debounce the push button switches?
Submit the following to one of the demonstrators before the end of the last session of this week on Thursday morning.
////////////////////////////////////////////////////////////////////////////// // ARM Project - Week 1 // // Your name // Your college // date //////////////////////////////////////////////////////////////////////////////
The best way to learn something is to have fun doing it. Andrew Stock obviously enjoyed solving this week's assignment, as you can see for yourself by trying out fun.sof on your teaching board. The procedure for downloading a .sof file to the board is described in the "Test your mouse hardware" section on page 3.
If you have already completed this week's task but are stuck here because it's a timetabled session, why not trying to reimplement delay.sof and learn something about timing problems? Simon Moore's ECAD Workshop 2 will guide you along the way. Note, however, that the "delay" module on that page, unlike the one contained in this .sof file, does not really delay an entire waveform. (This work will not be marked and must not be submitted. You should only attempt it if you enjoy doing so.)