|
|||||||||||||
Old Title: FPGA Case Structure Needs To Display Enum Values
In LabVIEW the case structure can show enum values, while the FPGA case only shows the numeric value. Would like to see the below example capable in FPGA.
Now that most numeric operators have the ability to saturate it would be nice to be able to differentiate these operations. I know that the majority of the time you can determine this information easily with the context help but this would make it much easier to spot. I tend to copy operators that are already being used in my vis than to grab a new one off the pallet. This would let me know which type of operator I'm copying.
The loop timer express VI is very useful to time a loop to an exact rate, however... if you want to be sure the loop is meeting the rate requested... you also have to put in tic count VIs like this:
Since the loop timer express VI already is calculating how long it needs to wait in order to achieve the desired loop time, I would prefer it if at least output a bool that indicated it failed to achieve the timing required.
It would be best if it output the actual tics it waited in like I16 form so it could go negative (indicating the # of tics it failed to achieve timing by.
I posted this suggestion in the forums, but it is something I would like to see improved and included in the FPGA library. The idea is to multiplex multiple inputs/outputs to a single high-throughput math function. If someone has to do a lot of fixed point math on the FPGA, the resources are used up quickly. The multiply block is primarily what I would like to see this implemented for, but I think it would be useful with all of the high-throughput math functions.
In one project I quickly ran out of DSP48E's on my FPGA, and since I had many fixed-point multiplies with the same data type configuration, I created a state machine to step through the inputs, allowing me to replace 4 high-throughput multiplies with one multiply block for multiple operations. Sequential operations are possible by feeding the output of one operation into the input of another (I didn't implement that in the forum post below, but it can be done). I think Labview could improve pipelining of the multiplexed function, ease of setting the number of inputs/outputs and data-type, hand-shaking logic for operation in SCTL, etc. LabVIEW could also show separate schematic figures for each of the multiplexed functions (example: a PCB layout software such as Eagle shows separate blocks on the schematic for each opamp on a chip containing multiple opamps).
At present, if you are trying to simulate your FPGA's actual logic, using a custom VI like this:
Then you know that your custom VI test bench only has one case for methods (just a general method case, not a case for each method available). There are ways to get around this problem--for example, this example emulates a node and suggests using a different timeout value for wait on rising edge, wait on falling edge, etc, but one still has to write the code for the different methods.
My suggestion is as simple as this: make test benches easier to use by handling all of the methods and properties with a set behavior. That way, all one has to set up when creating a test bench is the input and output on each I/O read/write line. At the very least, it would be nice to have the ability to read what method is being called, so the appropriate code can be set up without complicated case structures.
Memory initialization is one of the more tedious aspects of LVFPGA coding. A lot of my LVFPGA vis have multiple memory elements that I need to access simultaneously for a given operation. I've tried to streamline the initialization process by making all memory initialization vis read from an init values file and populate the array indicator. However now I have to have multiple initialization vis reading from different points in the same init values file. If I could somehow get a parameter into the memory initialization vi, I could programmatically select from where in the init values file to read. Here is how this could work:
My Profile | Privacy |
Legal |
Contact NI
© 2011 National Instruments Corporation. All rights reserved. | E-Mail this Page
|
||

E-Mail this Page