For this project, we built a circuit that had a predefined small set of instructions which is implemented through a state machine. This created a programmable light display, on which the three red LEDs represent input bits, which is read into the state machine, from which it decides what the output should be, which is what is represented with the 8 green LEDs. A 1 in the byte (8 bits) means the light is on, while a 0 means it is off. There are 8 possible instructions, meaning we are using 3 bit input, and the light register (LR) holds 8 bits, which hold the numbers we will manipulate using the instructions that come from the 3 former bits.
Task 1 was to create a new project in Quartus. We refer to it as "lights". Incidentally, this project is the first time we were required to do all of the work in VHDL, without any block diagram files.
Task 2 was to create the initial file with the instructions in it, referred to as "lightrom." The program needs to have two things connected to it: "addr", which counts up from 0000 to 1111, and "data", which is the output of numbers we send to the next file to be interpreted as instructions. All this file is doing is sending certain outputs for "data" based on how far up "addr" has counted. A picture is below.
Task 3 was to make "lights", the VHD file that would control what the lights do based on what instructions are received. "IRView" is the vector output that controls the 3 red LEDs, "lights" is the output for the 8 green lights, and there is also an internal clock ("clk") as well as a reset button. PC takes in the "addr" bits, which are counting up, IR is where the instructions are stored, and LR is the output for the green LEDs. For the process, we reset all of these if reset is pressed, and if not, the clock begins ticking. As the time moves up and the cases are cycled through, LR's value is decided by instructions, given through when statements. For example, if IR is 000, then LR has 00000000 loaded into it. At the end of the file, we also output IRview as the red lights and lights as the green lights. My code is shown below:
Task 4 was to make sure we were importing the lightrom into this file so the corresponding inputs and outputs could connect. We just had to add the lightrom file as a component right after the start of the architecture section, then create an instance of it before the main process begun and after the architecture statements.
Task 5 was to test the circuit in a gtkwave simulation. As we can see, the clock moves forward at certain intervals, and the lights output is changing based on what the irview is. There is a bit of a lag due to the clock timing, but one can see, for example, that lightsig is 00 at first, then when irview is 101 (the instruction to invert the bits), it becomes FF. In other words, the bits go from being all 0s to being all 1s, represented in hex in this case.
For Task 6, we had to set the code up so that it would work with a physical circuit. This was just a matter of setting up the pins, then changing the clock, for our purposes, to go 32 million times slower than the actual internal clock so we could see our results. A video of me testing my circuit is below. As we can see, the board cycles through all of the instructions we gave it in the lightrom, represented by the red LEDs, and the output is represented by the green LEDs.
In Task 7, we had to create two more VHD files with sets of instructions like in lightrom. The ones I made are shown below.
I did the first extension, too. This was to make the a longer program, which meant that "addr" would need to have (at least) another bit. So I changed the kind of vector addr was to a 4 down 0 one instead of 3 downto 0 like it was before. Everywhere that needed a change in amount of bits was changed from 4 to 5. Then, the only other adjustment was giving more instructions -- 32 in total -- to the machine to test if it worked. My test program is shown below:
Next, I did extension 2, which was to add instructions to the system. One could have made more instructions directly by giving the data (red light) 4 bits instead of 3, for example, but I decided to indirectly make branch directions by having certain inputs equal different things if a certain condition was true. If 101 was input, for instance, the branch1 variable would be true, and it would mean that the next time the execute state was entered, it would follow different rules. An input of 111 in the first branch would take us into the second branch, too. Some instructions could be used to exit each branch, as well. Looking back, I could have implemented this using different kinds of Execute states, as well, but this worked as it should have anyways, as shown below:
This project taught me a lot about VHDL, more so than any project so far, because we did everything in it without using any block diagram files like the past times. I also gained a lot of experience using Moore state machines. This project was a very intuitive one that I had little trouble following.