Host Architecture Options

There are two options for using the class in a custom RTG + Coprocessor application. The selection determines how the host API is used.

Keeping the Base Class Separate—Use base class as top-level class for interacting with RTG and create a separate set of code to control all Coprocessor custom configurations.

In this architecture there are two independent code modules.

• The existing base class starts the Coprocessor FPGA, connects it to the RTG, and closes the Coprocessor FPGA at the end.
• A separate code module performs any custom actions required.

Calling the base class’s Get Coprocessor Refnum VI returns a handle to the FPGA that can be used to communicate with it. The handle is a dynamic FPGA reference that should be cast to the specific data type. The separate code module should not start, stop, reset, or redownload the bitfile to the FPGA because it will interfere with the RTG API’s interaction with the Coprocessor.

When using this architecture, you can call Create Coprocessor VI from the RTG Coprocessor Link Interface class library. You must store the bitfile path in the INI file, as described in INI File.

Extending the Base Class—Extend the base class to include custom functionality.

The method allows single class to provide all Coprocessor interaction. There is no reason to override functionality already in the base class unless there is a need.

When using this architecture, you must use the base class Initialize VI to create a class. This does not support reading from the INI file. You must provide all configuration parameters to the Initialize VI call.