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/22 12:16] guthrie |
2014:labview_visualizations [2015/01/02 10:16] (current) guthrie |
||
|---|---|---|---|
| Line 13: | Line 13: | ||
| 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|}} | ||
| 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|}} | ||
| We envision this module exercise could be used as the introduction to LabView's drag and drop interface as well as a tool to help students solidify their gate level understandings. This was Emily's first hands on Labview time and one thing we liked was that all the components she had to use were in the same portion of LabView's menu. Another thing she was introduced to in this step was the use of the front panel for test cases. For those of you unfamiliar with LabView, the program provides you the visual circuit and then a front panel that allows you to change inputs and monitor outputs. For the adder exercises, we both agreed it would be useful to see how overflow errors actually happened by using the front panel and that also would help us test our error catching methods. | We envision this module exercise could be used as the introduction to LabView's drag and drop interface as well as a tool to help students solidify their gate level understandings. This was Emily's first hands on Labview time and one thing we liked was that all the components she had to use were in the same portion of LabView's menu. Another thing she was introduced to in this step was the use of the front panel for test cases. For those of you unfamiliar with LabView, the program provides you the visual circuit and then a front panel that allows you to change inputs and monitor outputs. For the adder exercises, we both agreed it would be useful to see how overflow errors actually happened by using the front panel and that also would help us test our error catching methods. | ||
| 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|}} | ||
| 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|}} | ||
| 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|}} | ||
| 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.1419268581.txt.gz · Last modified: 2014/12/22 12:16 by guthrie
Page Tools
