2014:labview_visualizations
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
2014:labview_visualizations [2014/12/27 17:30] guthrie |
2014:labview_visualizations [2015/01/02 10:16] (current) guthrie |
||
|---|---|---|---|
| Line 14: | Line 14: | ||
| We used clusters like nets in verilog. 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 used clusters like nets in verilog. 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. | ||
| {{:2014:cpu.png|}} | {{:2014:cpu.png|}} | ||
| + | |||
| 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 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. | ||
| {{:2014:halfadder.png|}} | {{:2014:halfadder.png|}} | ||
| Line 20: | Line 21: | ||
| 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 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. | ||
| - | {{:2014:addersubt.png?200|}} | + | {{:2014:addersubt.png|}} |
| We used clusters to represent the 4 bit inputs and outputs which are comparable to nets in Verilog. This also exposed us to the port mapping that LabView uses for sub VIs. When on the front panel, you can map what components you want to be inputs and what components should be outputs. These are color coded by their types which means it's almost impossible to hook up a mismatched type to a certain operation. This is one spot where LabView outperforms Verilog because it displays readable errors and has error prevention for the issue of hooking up paths incorrectly. | We used clusters to represent the 4 bit inputs and outputs which are comparable to nets in Verilog. This also exposed us to the port mapping that LabView uses for sub VIs. When on the front panel, you can map what components you want to be inputs and what components should be outputs. These are color coded by their types which means it's almost impossible to hook up a mismatched type to a certain operation. This is one spot where LabView outperforms Verilog because it displays readable errors and has error prevention for the issue of hooking up paths incorrectly. | ||
| 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. | 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. | ||
| - | {{:2014:alu.png?200|}} | + | {{:2014:alu.png|}} |
| One of the best parts about LabView is that it’s easy to run and see the data flow. 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 light bulb and probe tools in LabView to easily find the error in less than 10 minutes. These tools help you to look at a subvi and identify what inputs and outputs it has as well as observe the value of a wire over the test. Similar to an oscilloscope, it can help you back track to where the data becomes invalid. 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. | One of the best parts about LabView is that it’s easy to run and see the data flow. 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 light bulb and probe tools in LabView to easily find the error in less than 10 minutes. These tools help you to look at a subvi and identify what inputs and outputs it has as well as observe the value of a wire over the test. Similar to an oscilloscope, it can help you back track to where the data becomes invalid. 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 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 | ||
| - | {{:2014:instructionfetch.png?200|}} | + | {{:2014:instructionfetch.png|}} |
| This unit introduced us to a few of the drawbacks we found. The first is that case statements as we used them to represent Mux's don't quite visually represent the process of using an address to select from many inputs. The process of constructing the mux equivalent involved hooking up each input to the output when the case state was that inputs address. This process could be avoided if people were provided with a library of muxs with different input numbers, but that too seemed a little weird. | This unit introduced us to a few of the drawbacks we found. The first is that case statements as we used them to represent Mux's don't quite visually represent the process of using an address to select from many inputs. The process of constructing the mux equivalent involved hooking up each input to the output when the case state was that inputs address. This process could be avoided if people were provided with a library of muxs with different input numbers, but that too seemed a little weird. | ||
| + | {{ :2014:regfile.png |}} | ||
| 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. | 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. | ||
| - | + | **How you can help** | |
| + | The project can be extended by testing the vi's with more people of varying levels of LabView experience. Our VI's included in the zip folder, could be built upon and revised into a partially completed state for exercises. Also in the zip folder is the writeup of what components are comparable to what so that you could make a set of vi's yourself. By either using and documenting your experience with the VIs or building your own you could help further test the usability of LabView as a teaching tool. | ||
| + | {{:2014:finalproject.7z|}} | ||
2014/labview_visualizations.1419719442.txt.gz · Last modified: 2014/12/27 17:30 by guthrie
Page Tools
