From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

FPGA: Is there a [easy] way to see which VIs/Methods would be compiled into a bitfile ?

Solved!
Go to solution

I am working on a reference design for reusable FPGA-side code – having Host-side objects (by value class instances) talking to their FPGA counterparts also packaged as classes.

 

On the Host side, classes (.lvclass) load all their controls and methods into memory. Regular LabVIEW Libraries (.lvlib) only load their nested libraries (.lvlib and .lvclass), which will result in loading controls and methods from all nested classes (and their parent classes), but not controls and VIs from the Library itself and regular nested libraries.

 

However, I have no idea which methods/VIs get compiled into a bitfile on FPGA side.

 

Question: Is there an easy way to get a list of methods/VIs that would be compiled into a bitfile for a specific Top Level FPGA VI ?

 

0 Kudos
Message 1 of 5
(2,595 Views)
Solution
Accepted by topic author Dmitry

There is currently no way to directly get this information. The FPGA compiler will only compile in the VIs that are actually invoked within the FPGA application. 

 

For classes, the exact derived/overriden method must be resolved at compile-time and that is the VI included in the compilation. The base class overriden VIs would not be compiled in unless the derived class function that was invoked calls the base class version using the Call Parent node or the base class method was directly invoked by an object of that type somewhere in the hierarchy.

 

You can reason about this by thinking through which class objects are flowing where, but that information is not currently made available outside the compiler.

Message 2 of 5
(2,584 Views)

Does the VI Hierarchy window get you the information you need, looking at the top-level FPGA VI?

 

Or, Save As on the top-level FPGA VI, and save the entire hierarchy to a new location? Then you could quickly traverse the created folder structure and get a list of all the VIs. With scripting, I think you could do this traversal in place on an existing VI; perhaps someone has already written a tool for it. For that matter, an FPGA is a separate target, and therefore application instance, and I think there's an application property for VIs in Memory; if so, you could just open the top-level VI and then read that property.

 

I assume you're looking for this information for reasons of packaging the VIs into the appropriate libraries? Once the FPGA VI is compiled, any association with individual subVIs is lost. During compilation the entire hierarchy is essentially flattened into a single VI. As I'm sure you know, you can only access the FPGA top-level VI and not any subVIs it might have contained prior to compilation.

0 Kudos
Message 3 of 5
(2,582 Views)

Those methods will give you a way to view all the VIs reachable from the top-level FPGA VI, but it won't filter out the VIs that aren't actually required by the application and are therefore ignored by the FPGA compiler.

 

A super-savvy user might be able to put together a VI analyzer tool that could do the same reachability analysis the FPGA compiler is doing, but if someone really needs that it would be better to request it on the FPGA Idea Exchange and try to get some backing to expose that information directly from the compiler.

0 Kudos
Message 4 of 5
(2,570 Views)

I did not use FPGA-side classes on a real life project before and I don’t know how LabVIEW FPGA Compiler does its magic. I want this list for two reasons:

 

  1. Make sure compiler does not include any methods not used by a specific Top Level VI calling other methods of a class
  2. Have a list of optimization candidate methods/VIs once I start running out of FPGA resources

LabVIEW FPGA Compiler must already have this info in its internal data structures. I don’t think it should take much effort adding a magic key to LabVIEW.ini and saving such list to a text file once it is enabled …

 

Any interest in such a feature in the Community ?

 

0 Kudos
Message 5 of 5
(2,542 Views)