LabVIEW FPGA Idea Exchange

Post an idea

Relative Paths for Xilinx IP

When using the Xilinx IP nodes in LabVIEW FPGA it becomes very difficult to support source code control and branching. The biggest issue is the fact that the "Folder for Support Files" entry is absolute. So when we need to branch the code to isolate new feature development from the main trunk the relative path is now wrong. Please make this and all other paths relative to support a more robust development environment.

When debugging, I find it useful to have Graphs on my FPs. Mostly for running in simulation mode but sometimes I want to verify that the compiled code behaves the same way.

I currently have to replace all of my Graphs (fed with fixed size arrays) with Arrays since I can't define the FP element to be a fixed size, unlike arrays. This makes debugging a bit more of a pain than it needs to be.

Is it possible to gbet the option to define a Graph as being a fixed size so that this replacement step is unneccessary?

Add a common part for FPGA Palette

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.

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:

Save FIFOs in a library

View All (2)

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.

memory map

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.

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.

Allow raw access to sbRIO Analog IO

More detailed Xilinx log feedback

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

LabVIEW FPGA Idea Exchange

Time unit converter for Laview FPGA ...

Check for Invalid Use of Global Variables in LabVIEW and Alert User Before Compiling

Relative Paths for Xilinx IP

Do Not Compile Sequence Structures Inside Single-Cycle Timed Loops

Fixed size Graphs for Debugging (similar to fixed size Arrays)

Add a common part for FPGA Palette

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

Extend Butterworth filter to allow multi-channel 32bit filters

Pipelining gain compensation in CORDIC algorithms

Memory Initialization Browse Button Default

Memory Initialization VI Input

Configure Memory / FIFOs from Outside FPGA Target Scope

Save FIFOs in a library

Wait until more than one IRQ has occured

Sorted variable list for FPGA Read/Write Control.

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

memory map

Procedure of Downloading Bitfile to EtherCAT

Allow raw access to sbRIO Analog IO

More detailed Xilinx log feedback