This is an old revision of the document!
The project For this project, we investigated the usefulness of Labview as a teaching tool for Computer Architecture (CompArch). We approached it from a feasibility and user experience perspective.
Why we did this Each of us had very different experiences with learning the CompArch concepts in parallel with learning Verilog. That being said we both struggled with it. Emily struggled with not fully understanding the computer architecture concepts enough after leaving class to turn around and implement it in an unfamiliar language. It made it very difficult for her to seek help from course assistants and Eric because what she perceived as a Verilog related issue was actually a conceptual misunderstanding. Ankeet struggled with the Verilog language not being visual enough or intuitive enough as a programmer. He found himself wondering if there was a better way and that's what led us to work on this project.
We structured the project to resemble a feasibility study. We did this because we knew if we wanted to validate our assumption that this was a easy and useful solution to our issues. We tested how easy it was for someone to learn labview to understand whether it was reasobn
This is our single cycle cpu that we made in LabView. It is a 4 bit CPU since we thought that 4 bits would be enough to demonstrate LabViews potential. If we start using more than four bits it becomes messier to create an ALU. We used clusters like nets in verilog. The CPU has a Instruction Fetch and Decoder, an 8 bit Register file, an ALU, and a 16 bit Memory File. We used a shift register as a program counter and had three different operations we could do: math, store, and load. We used case statements as muxes and only used gates to construct most of this.
We started this project by constructing a half adder. As you can see all the logic is done with gates instead of using LabView’s math tools.
We then went on to create a 4 bit Adder or subtractor using the logic below. It was really easy to create subVIs that were like modules in LabView.
We then used the adder to make an ALU. This shows the SLT we created. We used a case statement as a mux to switch between the different operations.
One of the best parts about LabView is that it’s easy to run and see exactly whats happening. The image below is the front panel of our ALU. When we first tested our ALU, we realized that we weren’t getting the correct outputs. We were able to use the lightbulb and probe tools in LabView to easily find the error in less than 10 minutes. The front panel allowed us to easily detect errors and test various cases. It is also easy to create a test bench in LabView though we didn’t do this. You would just stick your VI inside another VI that provides all the different inputs and verifies whether the output is correct.
This is our instruction fetch and decode unit. The PC shift register is used to figure out what instructions to send to all the inputs in our CPU
This is our memory file. We used an addition operator as well as branch statements in order to change things from binary into numbers so it would be easy to wire up our muxes. Other than this nothing from the math pallet was used in our CPU. We used global variables to represent our registers, though we later learned this was wrong. If we were going to redo this, we would use shift registers instead. Our register file was very similar to this except it only had 2 cases and outputted both registers.
