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

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.

The CORDIC High throughput functions available in LabVIEW are capable of running at high frequencies, thus allowing FPGA code to (for example) multiplex multiple demodulators without exploding device utilisation.

Unfortunately, the option to apply a Gain correction to the results does not pipeline the actual multiplication, thus artificially limiting the available speed of the CORDIC algorithms.

In my code I always deactivate the Gain compensation and do this "manually" allowing the code to compile at much higher frequencies and more efficiently utilising the FPGA device.

It would be great if it were possible to also pipeline this multiplication as part of the CORDIC High-throughput node instead of being forced to implement the multiplication separately.

View All (2)

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:

Currently, in LabVIEW you can right click a VI's icon at the top right of the front panel to find all instances including where the VI is referenced in a static reference node. Also, when you use have a "Open FPGA VI Reference" in "build specification" or "VI" mode, you can double click the node to open the referenced block diagram. Once the FPGA front panel is open, there's no easy way to get back up to the caller. It would be cool if we could extend the right-click-find-all functionality so that when you right clicked a top level FPGA VI, it would search where that VI was referenced in any "Open FPGA VI Reference" nodes. Currently, when you right click and search, it just says no instances found.

When using external ram on the FlexRIO products it would be nice to have a memory map tool built into LabVIEW FPGA.

Many traditional FPGA release processes for companies require a memory map. Currently LabVIEW only allows the user to create memory partitions, but the user has no control on where the partitions are laid out in memory.

This can cause problems during the release process because the simulation is not repeatable because the memory element being accessed may be in a different location.

This feature will not impact the functionality of LabVIEW, but will make it easier to use LabVIEW FPGA in companies where Verilog, and VHDL languages were the only options for FPGA's and the release process is hard to change.

In correlation with another general idea I have posted, I have come to the conclusion that it would be nice to run an analysis of the Xilinx log in order to give feedback over which code has been constant folded by the Xilinx compiler.

Other aspects such as specific resource utilisation would be really cool also (SRL32 vs Regsiters for Feedback nodes). This would obviously be a post-bitfile operation but could at least give some direct feedback as to what the Xilinx compiler has modified in the code (Dead code elimination, constant folding etc.).

When LabVIEW 2009 and prior, after the compilation of FPGA VI, the bitfile was automatically downloaded to EtherCAT. However, from 2010, that process became manual; after the compilation, you need to go under the Build Specification, right click on the bitfile created, and select Download. Regular cRIO does it automatically, and I don't see the point of manually downloading it.

Does anyone know the point of doing this? And if it was not intended, I like auto download a lot better. But at the same time, 2009 and prior, the bitfiles were not shown under the build specification, which bothers me also. So the conclusion is that, I think it will be better to show the bitfile under the Build Speficcation AND download it automatically to EtherCAT.

I would like to select which FPGA resources (DMA FIFOs, front-panel controls) are used by a host VI at run-time. This would make it possible to implement multiple copies of the same function on an FPGA and control them with the same driver, passing in a reference to the appropriate resources. For example, my FPGA might be communicating with several identical devices over SPI. I'd like to write one host/real-time driver, and then pass in a reference to which front-panel controls to use for that particular device.

It seems like NI has already done some work in that direction, with the FPGA Advanced Session Resources (appears to be LabVIEW 2014 only) and Software Defined Instruments (only on a limited set of boards). I'm looking for a simple interface that's available on all FPGA targets.

View All (6)

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

How can we help?

Please enter your information below and we'll be intouch soon.

This field is required

Preferred communication method

Email Phone call

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

LabVIEW FPGA Idea Exchange

Add a common part for FPGA Palette

BRAM Primitives with different Read / Write data widths

Extend Butterworth filter to allow multi-channel 32bit filters

Don't recompile if a memory or IO added for a different VI

Pipelining gain compensation in CORDIC algorithms

Wait until more than one IRQ has occured

Memory Initialization Browse Button Default

Memory Initialization VI Input

Configure Memory / FIFOs from Outside FPGA Target Scope

Save FIFOs in a library

Extend right click find all instances functionality to finding where the FPGA VI is opened

Sorted variable list for FPGA Read/Write Control.

Allow raw access to sbRIO Analog IO

memory map

More detailed Xilinx log feedback

Procedure of Downloading Bitfile to EtherCAT

run-time selection of FPGA resources

Optimized Error-Case with error-code separated cases (see LabVIEW Idea Exchange)

Array to number coercion dot when sign extending

FPGA global variables accesible through Desktop Execution Node