LabVIEW FPGA Idea Exchange

Post an idea

When setting up a custom VI to use as a simulation test bench, you are currently limited to setting a constant path. If you move your VI, send it to another user, change the name, or otherwise change the path of the custom VI, you must enter the FPGA target settings and modify the path. That is, if you moved the project below from user1's desktop to user2's desktop, you would have to enter the properties and change the location. This makes code sharing somewhat tedious.

Using a relative path or a project item would make this feature easier to use.

Improved documentation for FPGA memory

When setting up memory in LV FPGA these seems to be one important setting missing....description.

Good programming practice defines that we should have descriptions in our code, similar to the VI description of a global variable. This would also help out immensely when using bit packed memory blocks to define status bytes and such as the description of the individual bit meanings could be added to the description and not having to be dropped as block diagram comments everywhere one of the nodes is used.

INLINE VI'S for FPGA ...

Hello,

In Labview 2010, the implementation of INLINE VIs has been improved. But this feature is not aivalable in Labview FPGA.

When you are looking for ticks/space you have to replace the VI calls by their content ... and then the FPGA VIs becames rapidly unreadable.

I think that inline VI could be very interresting in FPGA because ...

Ability to create userfriendly / updatable / readable / clear FPGA diagrams
Optimize the time/space needed to call a real VI

By default, FPGA VIs should all be "Inline" VIs !

Manu.

View All (2)

RT Node

View All (1)

It would be nice if this code:

Case Structure version

could be replaced by this code:

Select version

but doing so gives an edit-time error specifying that "Select: Possiblity of Dynamic Refnum not supported for current target".

Is there a fundamental reason this can't be allowed? The behaviour is presumably the same in each case, and the references are from the same place in both cases. In the case structure, the exact same references that are passed to the Select node are used, with the same True/False choice.

It's not a huge issue, but it would be a nice usability/readability improvement.

Boolean array to FXP

When parsing message packets in my FPGA code I'm often using a custom packing method with multiple individual datasets being packed into a single U64 (for example) for transport.

With the introduction of Malleable VIs, I would love to be able to create my own packing and unpacking Malleable VIs but don't yet see how. Problem is that the "Boolean array to Number" does not allow attaching a datatype like the "To FXP" does. I would like to marry these two functions into a "Boolean array to FXP" node where I can wire in my input datatype and have the output datatype automatically maintained in a malleable VI.

Improve Compile Retrieval Process

Long compile times are a necessary evil of FPGA code. Even with the vast improvements of Vivado, compile time still ranks as the biggest killer of large project efficiency. As compile times approach 3-4 hours, their successful completion becomes paramount. All too often I find that the Xilinx compiler running on the compile worker has completed successfully however some small communication glitch either between my development machine and the farmer or the farmer and the worker has caused the compile to be lost. It is quite frustrating to know you have a completed bitfile from Xilinx but the NI tools will not perform the final processing steps required to create the lvbitx file. The only solution is to restart the compile costing another 3-4 hours of productivity.

Typical workflow in our company for these large projects is to spend mornings testing and stressing the compile(s) from overnight. Then make any bug fixes and incremental feature improvements and try to start a compile by mid-morning. By mid-afternoon when the compile is complete do the process again so that you can process another build for overnight. If one of the compiles fails because of timing or resource problems, there's nothing that can be done. But if it fails because of glitches in NI's compile wrapper code, that becomes a waste of a half of a day of productivity.

I propose that the current methods for compiling bitfiles be modified. The goal is to improve user productivity. Some of my suggestions include:

For a given build specification, give it the ability to re-attempt to retrieve the last completed compile. This option would be available even if the VI's that created that compile had been modified.
If a compile was completed previously for this build specification and there has yet to be a successful lvbitx generation, prompt the user before doing anything that would destroy the ability to retrieve it.
Make sure that all of this still works when changing connections to the worker. For example if I start my compile at work then take my laptop home and want to login to my VPN at night to check on my compile
Don't remove any chance to get a compile if there was a communication error. Right now when I get the communication error, I see a red X in the compilation status and my only option is to remove it from the list.

View All (2)

More FPGA Vision examples

View All (1)

Presently, the Xilinx Compile Tools do not appear in the MAX technical report or NI License Manager. As a result, to determine the version, users must go to Add/Remove Programs in the control panel to determine which versions they have installed. It would be great for troubleshooting if the Xilinx Version could be implemented into the MAX technical report.

In addition, the Compile Worker states that the version of Xilinx used is 12.4, regardless of whether you are using 12.4 or 12.4 SP1. It would be useful for the compile worker to note which version it is using. Specifically, often the compilation chooses the compile tools based on what it was compiled with previously. When upgrading to 12.4 SP1, the user may think the compiler automatically uses the new compile tools and has no visual cue to verify the compile tools version used.

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)

Add a common part for FPGA Palette

Both resource and timing reports can be hard to read.

Timing shows clocks that may not appear as SCTLs.

Resources show items which are not easy to trace back the resources on the FPGA itself.

This varies based on the target being compiled, for say 7976 (Kintex-7), 5785 (Ultrascale), and x410 (RFSoC).

There could be a knowledgebase article on "How to understanding LabVIEW FPGA compile results"

I know that for more detailed compile results we have exported to Vivado but for new users this can be very intimidating and a big distraction.

View All (1)

Derived clock instantiation

I don't like static resource definitions FIFOs, Block RAMs or DMAs in my projects. I prefer to have the code declare such entities as they are required because this makes scalability much easier to achieve.

For FIFOs, BlockRAM and so this is no problem, but there are two things we currently cannot instantiate in code:

DMA Channels

Derived clocks

To deal with the seond option: Why is it currently not possible to create a derived clock in code. The ability to automatically have one piece of code accept a single clock reference and let one loop run at a multiple of the speed is something I've wanted to be able to do in the past but it is currently impossible in LabVIEW.

Please let us configure / define derived clocks in LV code.

View All (3)

LabVIEW FPGA Idea Exchange

Ability to save module settings, under FPGA target or other, so it can be imported to another target

Use relative paths or project items for custom test bench VIs

Improved documentation for FPGA memory

INLINE VI'S for FPGA ...

Configurable timout input unit for Wait on ... I/O method.

RT Node

Create single FPGA I/O node instead of multiple

Selecting between two I/O refnums not allowed

Boolean array to FXP

Improve Compile Retrieval Process

More FPGA Vision examples

Reference Inputs to Module Property Nodes

Make It Easier to Determine Current Xilinx Compile Tools Version, and Distinguish Between Xilinx 12.4 and Xilinx 12.4 SP1

Multiplexed inputs/outsputs to High-Throughput math functions to conserve resources on FPGA

Consider supporting a driver for Spartan-3E-1600KGate Development Board

Logic operators and Fixed Point numbers

Add a common part for FPGA Palette

LabVIEW FPGA Compile Report can be unclear

Derived clock instantiation

"Adapt to Source" in "FPGA VI Reference" indicator