LabVIEW FPGA Idea Exchange

Post an idea

Shrink Method nodes

This might have already been asked, but I couldn't find any posts.

X-Nodes are huge in comparison to the size of a subvi or most anything else on the block diagram of code, so lets shrink them down.

Can we remove the Read/Write box? We already have the little triangle to tell us the function/direction.

Can we use the node name instead of the generic term Data/Element? It's already there.

From there we can model it after a property node using references instead of error lines or we can model it after the IO node which is a little cramped but gets the job done. Both options retain a purple/pink bar to help identify it's X-node-iness.

View All (5)

When working with alot of fixed point math (think FPGA development), unless you are content to simply let LabVIEW decide what precision you want in your fixed point data types, it is extremely cumbersome to (right click->properties->Output Configuraton->Uncheck Adapt to source......, close window, move to next function and repeat and repeat and repeat. This is especially true if you end up needing to highly optimize your code.

It would be nice to have something like a floating window that could be opened that would display the output configuration data for the selected function or control and allow editing without the need for multiple mouse clicks. The window would automatically update with the configuration of whatever function or control was currently selected.

Wouldnt it be nice if, when you build an FPGA, rather than poping up a modal window, and preventing you from doing anything usefull for 10 mins or so (or more, dependant on the FPGA vi), LabVIEW went away and generated the intermediate files in the background?

After all, the actual compilation is now performed asyncronously (and you are using the cloud compile, arent you? ), so why should we sit and watch the intermediate files being generated?

Imagine the hours you would save a week, just by being able to get on and do something else.

Differentiate Saturating Operations

On PC and RT targets, when you right click on a specific property in a property node, you can directly open the help for that property:

However, on an FPGA target, you can't open the Help for a specific property or method by right clicking:

What happens if you click on 'Help'? It takes you to a page that explains the purpose of a property node. Rarely if ever is that what I actually want. Instead, I want to know about 'Linearization Coefficient 1.' My only option is to open up the Help and search for that specific property, which may or may not be easy to find.

My suggestion is to add a direct link to the help for every FPGA property and method in the right click menu.

LabVIEW FPGA gives users the ability to prototype FPGA code before they even have the hardware. This is incredibly useful. However, this requires you to manually add your controller, chassis, fpga, and C series modules. The process of adding C Series modules could be improved. Currently, you only have the option to add one module at a time. This isn't too difficult if you only have a few modules. However, if you have a full chassis of modules and a few ethercat expansion chassis, this process can be extremely time consuming. It would be nice if you could add multiple modules at the same time like you can with compactDAQ.

Current method of adding C Series Modules. It takes a long time to add each module individually.

Current method of adding cdaq modules. You can add all of your modules from one screen.

View All (5)

This is the current situation when dealing with register creation on FPGA targets:

This is what I would like:

I am currently creating a group of classes to abstract out inter-loop communication and the ONLY thing changing between classes (aside from variations between Ragister vs FIFO vs Global and so on) is the datatype. Being able to link the Register creation to a data input (the data value of the class itself for example) would save a lot of work in such operations. If it were also possible to do the same for the Register stored within the class private data then implementing different classes int his way would be really easy.

Even without classes, the ability to autoadapt the type of registers / FIFOs in this way would be a real step towards re-usable code on FPGA.

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)

Hide Trailing zeros from context menu

Hello,

I have a LabView project which includes a Windows part and a FPGA part.

To simulate my windows part i use Conditional Disable Symbols in order to bypass the FPGA calls. ( Ex: DEBUG = TRUE/FALSE)

These project Conditional Disable Symbols are not used im my FPGA Vi's.

BUT, when i change the Conditional Disable Symbols values ... i have to rebuild my FPGA code ! This is not good !

The "Bitfile validity" check should be a little more intelligent.

The "bitfile update detection" should only take in account the Conditional Disable Symbols it uses.

Thank for reading.

Manu.

View All (3)

Allow Parallel For Loops on FPGA

When I use a FPGA Read/Write control to set a state from Windows to the FPGA target, I would like to be able to search for all the places where that is done. If I do a search-Text for the FPGA Read/Write control variable names used to set the state, they are not found. The work-around suggestion from NI was "to include the text that you are looking for with each instance of the control, one way to accomplish this could be to label the wires going into or out of each terminal with the name of the control." This would work, but it would be better in a future LabVIEW version to have the search function be able to find the variable names.

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,

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.

read clock rate from clock reference

In real time engineering usualy the clock rate is a parameter which is needed in calculations. Therefore it would be useful to be able to access that rate as integer (or float). It is clear, especially in fpga-programming that the clock (and its rate) is not a variable, that can be chosen by the application user. This idea is rather about code development in order to avoid bugs. In the current situation I am forced to define a seperate constant copying the clock rate; in the course of later code changes I risk to forget to change that constant, when changing the clock.

For the same reason it would be useful to be able to access a clock refernce of an fpga-vi (an with it its rate) form the calling vi.

Better check for Compile Server

If you try to compile while pointed to a Compile Server that is for any reason inaccessible (server is down, firewall, typo in the hostname, etc.) you must wait through the generation of intermediate files, then you receive the error message that LabVIEW FPGA was unable to contact the Compile Server at your configured hostname/IP. Generating intermediate files can be a lengthy process and it shouldn't be necessary to wait through it just to find out if you have configured your Compile Server correctly. Any of the following would be a much better experience:

Attempt to connect to the Compile Server before generating intermediate files.
If the connection to the Compile Server fails after generating intermediate files, give the option of specifying a new Compile Server hostname/IP and retrying without having to re-generate the intermediate files.
At least put a connection check in Tools >> FPGA Module Options... so the user can test the connection to the Compile Server. You wouldn't do this all of the time, but if you run into a problem at least this way you can keep trying new configurations without generating intermediate files. Right now the best way to test new configurations is to create a blank FPGA VI (to decrease the length of generating intermediate files) and keep trying to compile it.

Run-Time Dynamic Dispatch Support

The LabVIEW FPGA module has supported static dispatch of LabVIEW Class types since 2009. This essentially means all class wires must be analyzable and statically determinable at compile-time to a single type of class. However, this class can be a derived class of the original wire type which means, for instance, invoking a dynamic dispatch method can be supported since the compiler knows exactly which function will always be called.

http://zone.ni.com/reference/en-XX/help/371599H-01/lvfpgaconcepts/fpgaclassesinvis/

This is not sufficient for many applications. Implementations that require message passing or other more event oriented programming models tend to use enums and flattened bit vectors to pass different pieces of data around on the same wire. All of this packing and unpacking can automatically be handled by the compiler if we can use run-time dynamic dispatch to describe the application.

We call for the LabVIEW FPGA module to add support for true run-time dynamic dispatch to take care of this tedious, annoying, and down-right boring job of figuring out how to pack and unpack bits everywhere. Whose with me?

View All (5)

LabVIEW FPGA Idea Exchange

Shrink Method nodes

FPGA compilation results log needed (especially for source code control)

Better/Faster access to data representation configuration when working with fixed point math

FPGA controls / indicators listed in alphabetical order

Non-modal intermediate file generation

Differentiate Saturating Operations

Have a Direct Link to the Help File for FPGA Property and Invoke Nodes

Allow the Addition of Multiple C Series Modules at one Time

Sort Controls in Read / Write Control (FPGA Interface)

Ability to define datatype of Registers / FIFOs from code (without needing the configuration dialog)

NI TClk and Ultrascale FlexRIO cards documentation

Hide Trailing zeros from context menu

Conditional disable symbols should not systematically alter validity of FPGA bitfiles ...

Allow Parallel For Loops on FPGA

FPGA Read/Write Control name search

Reflect Interface Configuration in Configure FPGA VI Reference Interface

Selecting between two I/O refnums not allowed

read clock rate from clock reference

Better check for Compile Server

Run-Time Dynamic Dispatch Support