LabVIEW FPGA Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Dragis

Run-Time Dynamic Dispatch Support

Status: New

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?

3 Comments
crossrulz
Knight of NI

I see this as a major undertaking for NI.  But I know many applications that would benefit from it.  You got my Kudos.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Intaris
Proven Zealot

So we would have a pool of possible child classes known at compile time which would then be automatically folded into the code (with a selector presumably).

 

I would love this also for Real-Time since DD calls there are expensive for me (running at 20kHz).

Dragis
Active Participant

@Intaris, yes, that's essentially the idea. The data paths would be "widened" to make room for any classes that might flow on the wire. I put widened in quotation because there are tricks that can be done in some cases to not require a full-width data path but those are just implemenation details.

 

If the class wire is a top-level control or indicator, or any other value accessible from outside the FPGA, there would need to be a way e.g. from the Build Specification to list the allowed set of derived classes for the compilation.