From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW FPGA Idea Exchange

Post an idea

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.

Xilinx supports BRAM primitives (FIFO and normal BRAM) with certain varying width read and write ports. For some applications, the ability to write 2x 16 bit values to a FIFO in one loop and read 1x 16 bit value from the FIFO at double clock rate in another loop can be very useful.

As it stands, the IPCore for such BRAM primitives, although present in LabVIEW FPGA, cannot be used without a CLIP (essentially making this aspect of the IPCore useless).

It would be cool if LV would expose the ability to have differing read and write port widths for BRAM.

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

Malleable FPGA VIs import into the Desktop Execution Node with the same datatype as the FPGA VI's "malleable terminal". The Desktop Execution Node does not mutate the input type to match the "malleable terminal" of the FPGA VI. As a result, host VI test benches cannot iterate Type Specialization Structure cases in the malleable FPGA VI.

The "anything" input to this Assert Structural Type Match node is an I16, which breaks this case against an I16, which is the "malleable terminal" of this VI.

The Desktop Execution Node only sees the I16, and coerces other datatypes.

IMO the compiled Type Specialization Structure case is a critical unit test, which depends on the data type of the control wired to the "malleable terminal", so this is a critical limitation of the Desktop Execution Node.

I think the intended use-case for the DEN is to hook into an FPGA VI that's in a loop, and if so, the inputs to the malleable VI are selected by the calling VI. So, maybe this isn't a limitation of the DEN itself, but of the DEN workflow.

Thanks for your consideration,

Steve K

View All (1)

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.