LabVIEW FPGA Idea Exchange

Post an idea

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).

http://forums.ni.com/t5/LabVIEW/Multiplexed-multiply-to-conserve-resources-on-FPGA/m-p/1668138/highlight/true#M595294

View All (1)

I often work with the FPGA in hybrid mode because the Scan Interface covers most of the project requirements 90% of the time. When NI added support for the SGL datatype to the FPGA module in 2012 (?), they overlooked user-defined variables. There is currently no built-in support for typecasting a SGL to U32, so passing SGL data back to the host requires FP controls or using custom typecasting solutions (see SGL typecast) on both the FPGA and host layers.

Please add SGL as an option for user-defined variables.

View All (4)

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.

View All (1)

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 VI Input

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:

As part of my quest to solve problems arising from over-cautious Register transfers HERE I found a solution which WOULD have worked if I was able to force multiple clocks derived from the same source to be have synchronised start points (so that the iteration counters of the loops are known relative to each other). It seems that clocks derived from the same base clock do not neccessarily all start with Iteration zero at the same time.

My suggestion would be to either

Give some option to force such loops to have synchronous starts (also when using external clocks) -or-
Allow loops with external clocks to terminate so that we can put together out own synchronisation method

Shane

Better support for multi-clock IP Cores

There are several functions of Xilinx IPCores which are not natively exposed in their LV counterparts. FIFOs for example, in certain configurations, allow for asymmetric read and write port widths. For multiplexing or serialisation / deserialisation this can be really useful.

However, if we try to create sometihng like this in LabVIEW we end up in a weird situationw here the IPCore offers the functionality, but the graphical context of G prevents us from really using it.

In this image, I have generated an asymmetric FIFO. The node created as a result has TWO clock inputs, one for the read port (shown in blue) and one for the write port (in green). We can't place a single node in LabVIEW in two different clock domains at the same time. When finishing up the IPCore config, we are asked for a single clock (which is then valid for ALL of the inputs and outputs). What we would essentially need is the ability to define multiple groups of I/O and the associated clocks for them. In addition, allowing access to these via a scheme similar to I/O nodes or CLIP references, we could then easily distribute the individual signals to the appropriate places for operation.

The I/O nodes below the IPCore show how this can be used. Most likely it would be a clock constraint so that ALL I/O of a given port (read or write in the FIFO example) are required to be used in the same clock domain. This is theoretically all do-able via a wrapper user CLIP, but if LV could just automate it for us, that would be great.

Simulation mode for CLIP

View All (1)

Floating point FXD

I find that I'm using large bit FXD to handle the dynamic range, but I only have 8 or 16 bit significant bits. I have an I2S input of 24bit numbers that I store in memory as U16 with the following incoding Number = A*2^(B), where A is a FXD(+/-11,9) and B is a FXD(+/-5,5). A and B are bit spliced array that form the U16. This allows me a 33% memory reduction covering a greater dynamic range by trading off resolution. Here the I2S input allows the counting of leading zeros or ones to create the number B and conversion back to 24bits is easy. Three items would make this a great help: 1. a typedef, 2. a quick forward convertor from standard form to FP FXD, and 3. gain inputs on math elements such as FFT if they canhandle FP values.