LabVIEW FPGA Idea Exchange

Post an idea

Support malleable VIs in FPGA targets

I work with malleable VIs a lot on desktop. They can save a lot of boilerplate code. From my understanding, the entire feature has no effect once code is compiled: the VI is converted to an "instance" VI with the proper data types and inlined into the caller. This doesn't seem like it should be problematic to use on an FPGA target.

Here are a few FPGA-specific wins that I think VIM support would deliver:

Array size adaptation
- One can imagine writing a "parallel for loop" VIM that simply expands out N parallel iterations for array sizes 0-N
Fixed point configuration adaptation
- Without VIM, if you write a VI that operates on fixed point numbers, it will auto-coerce to the configuration on the controls of the VI

It would be nice to have control of clock.-independent assignments of signals from I/O nodes (without synchronising registers) without having to specifically having to use a clock for the connection.

Image says it all.

We have tried using a static assignment on the top-level diagram, without using a SCTL but it appears that does not work. The example links within a single CLIP, but the idea is aimed at actually doing some connections between multiple different CLIPs without the need for a specific VHDL wrapper for each individual configuration.

Visually detecting the presence of CDC (Clock Domain Crossing) in LV code is only semi-intuitive. It is required to check the set clock of the SCTL and / or follow the wire to the clock constant / control in order to understand in which clock domain the code is running.

I suggest having the option to automatically colour the background of the SCTL according to the clock being used.

Obviously, this won't work well over VI borders, but at least the option to have it vivible on the same diagram is already a nice step towards better visibility of this really important part of LabVIEW FPGA programming.

An option to actually couple a colour with any given clock constant / control for SCTLs would be an addition I personally would very much appreciate.

Yes, these colours are probably a bit extreme, but given the fact that I'm dealing with so many individual processes, it is preferable to having to constantly follow all the wires or investigate all of the SCTL settings.

View All (1)

Hello,

I recently have issue configuring FPGA Vis to be run seemlessy by the same host code, because of incompatible interface between VIs. Here is the Configure FPGA VI Reference Interface :

Configure FPGA VI Reference Interface

And here are two (differents) interface, fore FPGA 1.vi and FPGA 2.vi respectively, as seen in the context help. I just duplicate the VI for the example and get the tab order modified - see under Registers :

Context Help for FPVA 1.viContext Help for FPVA 2.vi

I think it could be more consistent to have the same kind of display in the configure dialog, with the same control order. It's quite confusing not seeing any difference when configuring a reference to discover that something is wrong at run-time (controls and indicators are separated, and then sorted alphabetically - I only set controls in my example code, no indicators). The context help over the dynamic reference finally helps me to figure out what was wrong but it tokk me a while...

Please note that the FPGA FIFOs have to be define if the same order from one bitfile to an other (if there is differents targets, or differents projects). This is correctly reflected by the configuration window.

So I suggest having a more coherent display of control and indicators interfaces, that correspond to the effective interface (just like the context help does), i.e. the tab order of the controls under Registers.

Best regards,

As somewhat an opposite request to this idea

https://forums.ni.com/t5/LabVIEW-FPGA-Idea-Exchange/Ability-to-define-datatype-of-Registers-FIFOs-from-code-without/idi-p/3123936

I would like to show some pertinent information to the configuration of certain primitives in FPGA code.

The ability to turn this display on and off just like a label would be very welcome indeed. I'd always have it visible.

I just spent two days tracking down a bug which ended up being an under-dimensioned Block RAM instantiation (and how BRAM indexing works, just throwing bits away instead of coercing the read/write index), something whose configuration is completely hidden from view. Why can't we have some visible elements to show the size of a Block RAM and the Datatype (FXP would do for any given FXP type). Same goes for FIFOs, whether a FIFO is 16 elements or 8192 elements deep is a very important piece of information. And of course I mean only the primitives which instantiate the resources, not FP references for these items, even though the datatype of these would also be a very welcome addition.

View All (2)

View All (1)

NI 5785 MGT interfacing example

View All (1)

Working with the NI 5785 our team had a hard time understanding how to use TClk without all of the extra (e.g. streaming) code that comes with the example.

Through support we were eventually put in touch with R&D and they told us how to initiate TClk by setting some of the FPGA controls. This was helpful but not intuitive.

TClk helps support beamforming applications shown in the NI Marketing but without this usability it is very difficult (impossible) to develop applications promised.

TClk also has other lower level features such as the delay correction. No info is posted on this either but it is a property we can read.

View All (1)

LabVIEW FPGA Host Interface

View All (1)

FPGA compile automation tools

View All (1)

LabVIEW NXG had the ability to create a resource file. Though I cannot find the help reference for this I will describe the functionality below:

Right now the Target Scoped FIFO, P2P, DMA-FIFO, Memory, Handshake Items, Registers, Clocks, etc are all stored as part of LabVIEW Project (lvproj) file.

If want to port to a new project file or target I have to copy/paste. This is not a big deal and works well. However if I update one project's configuration I have to re-copy/paste. From a configuration management perspective I cannot ensure the configurations are always the same. With larger, multi-FPGA projects this becomes critical.

It would be great to have a file that holds all of these resources to allow for easier portability and configuration management.

View All (1)

When we try to compile timing critical FPGA application, if might be failed because of timing violation.

But if it missed only a few nanoseconds, recompiling might resolve the error as below.

Resolving Timing Violations on the FPGA

If your failed compilation misses the required throughput time by only a few nanoseconds, try rebuilding your bitfile. Each build of a bitfile does not always produce identical results on the FPGA, so rebuilding sometimes resolves minor timing violations.

In most case, compilation might require much time and it's difficult to take quick action after they found the aborted compilation result.

It would be great there is an option which allow automated recompile like below.

Of course the compilation completed, it wouldn't try recompile. Only failed, try to compile again.

** -------------------------------------------------------------------- **

Enable Auto Recompile [ * ] Number of Retry [ 4 ]

** -------------------------------------------------------------------- **

View All (1)

Unified Functions Palettes

View All (1)

Hello,

Is there any possibility to use a dedicated file to change the Number of Synchronizing Register

Today we need to right click on the DIO + Propriety + Advanced Code Generation + Select Nb of register.

On a SBRIO 9607 I have to do it 96 times and if I change something with the CLIP generator I need to do it again.

In my design I use VHDL IP so the synchonisation is already done on the VHDL and I don't need extra clock.

I try to edit with Notepad++ the .lvproj file and change the NumberOfSyncRegistersForReadInProject or NumberOfSyncRegistersForOutputData but it's not clean...

If you have an idea it will save a lot of click.

Thanks

Perhaps there's already a good way to do this, but some structures/nodes are allowed in a Single-Cycle Timed Loop but their behaviour is significantly changed, perhaps breaking your VI.

It would be good to be able to mark VIs in some way as unsuitable for use within a SCTL.

An example is the flat sequence structure - you can place this in a SCTL and it can pass intermediate file generation, but the behaviour is as if there was no sequence structure.

Assuming that it isn't always superfluous, this probably indicates invalid behaviour but is not necessarily obvious to detect (e.g. with broken compilation or intermediate files).

Some specific node that could be placed on a block diagram and indicate that a VI cannot be placed inside a SCTL would be useful.

Something like a Divide can be used for this, but not trivially easily - you need to actually use the output of the Divide or else the dead-code elimination allows the intermediate files to be happily generated. It took me quite a few goes to get a failure even with SGL precision divide in a SCTL... wiring to a structure or an indicator is not enough, it must be something that actually uses the value.

Select in SCTL

Initially I looked around for my previous idea here: Selecting between two I/O refnums not allowed because I thought it was the same and intended to post a comment to that, but I see that was a bit more specific.

This seems like a more allowable case - why is A forbidden and B perfectly ok?

Select node in SCTL

Case Structure to choose between two values based on boolean input

Here A is forbidden (at Intermediate file generation - so perhaps this would help: Unsupported nodes inside for loop within SCTL should result in a broken VI (NXG != Already Implemented really...)) but B is compiled with no problem. I really don't see why Select of two integers is different to a Case Structure with two integers input, a boolean case selector, and an integer output from the two inputs...

As an idea rather than a rant, I'd like A to be possible.

LabVIEW FPGA Idea Exchange

Support malleable VIs in FPGA targets

Concurrent assignments on the LV top-level diagram

Option to colour-code SCTL backgrounds according to Clock selections

Create single FPGA I/O node instead of multiple

Reflect Interface Configuration in Configure FPGA VI Reference Interface

Show some important resource data on FPGA items (Block RAM, FIFO etc.)

Instruction Framework simulation mode support

NI 5785 MGT interfacing example

NI TClk and Ultrascale FlexRIO cards documentation

LabVIEW FPGA Host Interface

FPGA compile automation tools

Instruction Framework examples for modular development

Add ability to have resource files in LabVIEW FPGA

Enable "Automatically retry the compilation if Timing Violation Error occured" option

Change Default Interface of FIFOs to Handshaking

Unified Functions Palettes

RMC Socket Number of Synchronizing Register

Provide a no-op method to forbid compilation in a SCTL

Select in SCTL

Colour coding for Estimated and Final timings