1. Obtain Session: Creates a new DLsc Session Object by name, or obtains a reference to an existing DLsc Session Object of that name, if it already exists.
   • By default, the Session Object reference is owned by the caller that creates it, and is destroyed when the caller stops. Likewise, hardware references are owned by the caller that first initializes them and are destroyed when the caller stops.
   • The optional Use Remote Engine behavior creates a Session Engine to own and monitor the Session Object and hardware references. Use the Remote Engine for complex applications that might spawn and destroy multiple subcomponents in an unknown order. Use Remote Engine ensures that references are not accidentally caught and destroyed by the LabVIEW auto-cleanup. The modem examples use this option to enable the modulator and demodulator to safely run as separate VIs.
2. Add Hardware: Stores parameters needed to open a dynamic FPGA reference. This method only stores the parameters, it does not create the reference. This function verifies the provided address information matches the information in the session or returns an error if the hardware alias has already been added to the session.
3. Initialize References: For any hardware parameters defined by the Add Hardware function, this opens a dynamic FPGA reference to the hardware and creates reference objects to the registers used by the DLsc context. Initialize References will not operate on hardware that has already been initialized within the session.
   • Take care to ensure that the FPGA reference is not interrupted by other sessions to the hardware, such as re-downloading the bitfile or reconfiguring the data path.
   • NI recommends that VST sessions are explicitly committed before calling Initialize References.
4. Add Link, Add Transmitter Endpoint, or Add Receiver Endpoint.
   • Add Link: Stores parameters needed to obtain register reference objects associated with the transmit and receive ends of a transceiver link. This method only stores the parameters; it does not obtain the references. If the transmitter or receiver has already been assigned to a link, this function returns an error.
   • (Advanced) Add Transmitter Endpoint: For applications operating on a link with an externally controlled receiver, you can configure the DLsc Link in single-endpoint mode by defining the transmit end of a transceiver link only. In this mode, DLsc operates normally, but with reduced features.
   • (Advanced) Add Receiver Endpoint: For applications operating on a link with an externally controlled transmitter, you can configure the DLsc Link in single-endpoint mode by defining the receive end of a transceiver link only. In this mode, DLsc operates normally, but with reduced features.
5. Commit Link(s): Performs actions to ready links for use.
   • For new links, obtains the register references for the link and validates that the link is established on both ends. This creates the link in the Disabled state.
   • For added non-default link configuration parameters, applies those parameters.
   • (Advanced) In single-endpoint mode, you can set the connection timeout parameter to 0 to disable error injection if the external endpoint is not available.
6. Enable Link(s): Enables data flow across all layers of the link. Sets the link to the Enabled state.
7. Initiate Link(s): (Optional) Readies the link to wait on an internally defined trigger.
   • Enable Link(s) implicitly includes this functionality.
   • Use this function in workflows that repeatedly Initiate and Abort an RF acquisition session that streams data to the link. Call Initiate Link(s) before the RF acquisition Initiate.
8. Abort Link(s): Aborts data flow at all RF transmit endpoints defined in the specified link(s).
   • Always call this function before aborting an RF acquisition session that streams data to the link.
9. Disable Link(s): Disables data flow across all layers of the link. Sets the link to the Disabled state.
   • (Advanced) Disable and Flush Link(s): Stops data flow into the link and flushes all data through the link before disabling data flow across all layers.
   • (Advanced) Disable and Remove Link(s): Disables data flow across all layers of the link and deletes the link object from the session. The hardware references remain intact.
10. Release Session: Releases the session object and cleans up references if no other session references exist.
    • (Optional) Forcibly destroys and cleans up all references in the session object regardless of other accessors.

Enabled—Streaming link is enabled. Data can flow from the transmit endpoint to the receive endpoint.

Aborted—Streaming link is disabled at the transmit interface. This state prevents new data from arriving but allows the remaining data to flow through the link. Data might remain in buffers while in this state, depending on the protocol packaging implementation.

Disabled—Streaming link exists but data cannot flow through any layer.

VST MGT Interface

VST MGT Interface is the native MGT streaming interface for the PXIe-5840, PXIe-5841, and PXIe-5842 VST models. The interface is comprised of two components: the VST MGT Generation and the VST MGT Acquisition. To enable use of the interface, you must load the VST driver session(s) with a VST Streaming Bitfile. Refer to VST Streaming Bitfiles for information on the supported bitfiles and how to load them.

VST MGT Generation—Acts as the bridge between the stream and the signal generator of the VST. It receives streamed U32-formatted I/Q data and queues it for the generator to use as a datapoint in an arbitrary waveform.

• The stream speed should match (or exceed) the sample rate (I/Q rate) of the generator or risk underflowing.
• Built-in handshaking with the protocol layer prevents overflowing at the interface or generator.
• To use the VST MGT Generation stream as the data source, you must initialize the NI-RFSG session using a supported streaming bitfile and configure the session for MGT streaming.

  Call the RFSG Utilities » Configure MGT Streaming function on the NI-RFSG session wire and the niRFSG Commit function before calling the DLsc Initialize Hardware function.

• The stream should be enabled before the RFSG session is initiated to prevent underflow.
• The stream allows the user to define the number of 0 datapoints to prepend to the received stream data that can be used to account for transmission delay between the transmitter and the VST MGT Generation endpoint.
  • The minimum number of zeros required corresponds to the latency of the system. Refer to NI Data Link Test Framework System Benchmarks for recommended values for several system configurations.
  • Use the Link Configuration » VST MGT » Configure Generation function to define the zero waveform length for the full system or for specific links by name.
  • With handshaking in the transmitter to prevent data overflow, the VST MGT Generation endpoint can alternatively be preloaded with data so the RFSG can immediately begin generating streamed data on initiate.
• When shutting down, abort the RFSG before disabling the DLsc link to prevent underflow.

VST MGT Acquisition—Acts as a bridge between the acquisition task and the stream. VST MGT Acquisition creates a U32-formatted copy of the I/Q data acquired by the VST and queues it for streaming. The location and rate at which the data is streamed is different for the supported VST streaming bitfiles.

• The stream speed must match or exceed the acquisition rate of the acquisition task or risk overflowing the interface.
• An overflow can cause a latching error condition that must be cleared by resetting the VST hardware through NI MAX.
• An overflow can occur if the stream receiver cannot process the data as fast as it is provided. For example, a coprocessor with a receiver loop running at 160 MHz and processing four samples per cycle can only support an acquisition sample rate of up to 640 MS/s.
• You must abort the acquisition interface before aborting the RF acquisition session or risk a timeout error when the RF acquisition session aborts.

  The acquisition interface enforces a continuous RF acquisition and provides a Done signal when aborted. The RF acquisition will not successfully complete until the Done signal is provided.

• To use the VST MGT Acquisition stream to send data to another device, you must initialize the NI-RFSA or NI-RFmx session using a supported streaming bitfile and configure the session for MGT streaming.

  Call the RFSA Utilities (or RFmx Utilities) » Configure MGT Streaming function on the NI-RFSA or RFmx session wire (depending on which is in use). Commit the acquisition session before calling the DLsc Initialize Hardware function.

Data Link System Component (DLsc)

The DLsc Host Interface provides the necessary functions to control the DLsc FPGA endpoints defined on the coprocessor. The DLsc FPGA API, included in NI Data Link Test Framework, adds an interface layer for use on PXIe-6594, PXIe-7915, and PXIe-7903 FPGA coprocessor models. For information about the DLsc Interface implementation and how to use it, refer to NI Data Link System Component FPGA API.

• The protocol driver has native flow control built in for ease of use. You can manually configure the NFC to refine the buffers and packet sizes, although the default configuration parameters are suitable for many applications.
• Data remains in the protocol’s buffers if it is not a complete packet size. Use the DLsc Disable and Flush method to manually flush the data.

You can find Endpoint Implementations.ini in the following location: <LVAddons>\dlsc\1\vi.lib\DLsc\v1\Host\Link Engine\Support

The Endpoint Implementations.ini configuration file is used during the endpoint initialization to dynamically locate and construct the specified endpoint implementation based on the registers set on the FPGA.

• <LVAddons>\niidl\1\instr.lib\_niInstr\Aurora64b66b\v1\Host\xN\Aurora64b66b xN Host.lvclass
• <LVAddons>\niidl\1\instr.lib\_niInstr\Aurora64b66b\v1\Host\Buffered\Aurora64b66b Buffered.lvclass
• <LVAddons>\niidl\1\instr.lib\_niInstr\Aurora64b66b\v1\Host\Basic\Aurora64b66b Basic.lvclass
• <LVAddons>\niidl\1\instr.lib\_niInstr\Aurora64b66b\v1\Host\Interface\Aurora64b66b.lvclass

These files must share the same destination configuration in source file settings. NI recommends using the application as the destination (default behavior). Failure to include these files in the same destination can result in runtime errors including application hangs or crashes.