You can use certain aspects of LabVIEW object-oriented programming techniques when creating FPGA VIs.
Supported LabVIEW Class Features
- Class constants, controls, and indicators
- Class methods
- Use of all FPGA supported data types within classes
- Classes contained in the private data of other classes
||Note You cannot use LabVIEW classes on the front panel of a top-level FPGA VI because LabVIEW must be able to resolve all classes at compile time.
Guidelines for Inheritance and Compile-Time Resolution of Classes
In LabVIEW object-oriented programming, the type of the object at run time can be the same or a descendant of the type of the wire. When you compile an FPGA VI into a bitfile, data routing is fixed, meaning that the compiler cannot dynamically call multiple implementations of code. This restriction means that the compiler must be able to statically determine which type is actually on the wire at run time. Use the following type guidelines as you create FPGA VIs:
- You can wire a child class terminal to a parent class terminal.
- Compared to any other subVI call, there is no additional overhead with dynamic dispatching in an FPGA VI because the override to invoke is determined at compile time.
- If an FPGA VI has a LabVIEW class input and is not reentrant, you can call that VI in multiple places in your VI hierarchy and wire it with different wire types at various locations. However, when the compiler analyzes your VI hierarchy, the wire type must resolve to the same class at all locations. This applies to both static dispatch and dynamic dispatch VIs.
- When you have local variables of the class type, ensure that all writes match in class type, as described in the following list:
- If you have a LabVIEW class control and associated write locals, ensure that all wires connected to the write locals are of the same class type. If the control is on the connector pane, you must ensure that the wire connected to the terminal, which corresponds to the control, is of the same class type as well.
- If you have a LabVIEW class indicator and associated write locals, ensure that all wires connected to the write locals and the indicator are of the same class type.
When you have local variables of a class type and some of them are readers, ensure that all writes match the default class type, as described in the following list:
- If you have read locals associated with a control or local variables associated with a wired control, you must ensure that all wires connected to the write locals, if any, are of the default type, unless the control is on the connector pane and you wire the terminal corresponding to the control.
- If you have read locals associated with an indicator, you must ensure that all wires connected to the indicator and the write locals, if any, are of the default type.
- All objects in an array must resolve to the same class.
- Case structure tunnels in all frames must resolve to the same class.
- The compiler resolves the class for shift registers and Feedback Nodes at the initialization terminal and then uses that type for the rest of the loop. Uninitialized shift registers and Feedback Nodes resolve to the class of the wire. If you introduce a child class within the loop, the compile fails. In the following figure, the FPGA VI compiles only if DynDisp.vi always returns the same type at its output that appears at its input.