Description

The OPAL-RT Board driver is the user interface required for the configuration of the connectivity features of the various proprietary OPAL-RT boards.

To add the driver to a project

To add the driver to a project, right-click the I/O section of the RT-LAB project and select New > New I/O to open the New I/O wizard.

The I/O interface must be configured and valid connections must be defined (using the Configuration section of the RT-LAB project) before the driver is launched at simulation start.

Multiple OPAL-RT Board drivers can be added to one project, as long as they control different FPGAs.

Bitstream Configuration

Every bitstream file (.bin) programmed into an FPGA interfaced with the OPAL-RT Board driver must have an associated configuration file. The driver requires a description of the hardware installed in the simulator to correctly interface with it.

Via the standard Opal-RT repositories option, OPAL-RT Board allows users to navigate through the bitstream configuration files available in the installed version of RT-LAB and eFPGASIM. Alternately, the user can browse to a bitstream configuration file using the Windows File Explorer with the file system option.

A bitstream configuration file describes all the functionalities of its associated programmable file.

The configuration contains information about the I/O communication and the presence and configurability of other logic blocks (such as electric solvers) in the RT-XSG model used to generate the programmable file.

To configure the OPAL-RT Board interface

To configure the OPAL-RT Board interface, a valid .opal or a valid .opbin file based on the board type is selected through the Bitstream configuration file option. A .opbin file is a package that manages several files needed to configure and load an Opal-RT Board simulation. A minimal .opbin file contains the information available in a .opal file and in a bitstream file.

As above, these files can be selected with the Windows File Explorer or within the proposed files located in the standard OPAL-RT repositories.

Before selecting a .opal file within the File Explorer, ensure that the associated bitstream file (.bin) is in the same folder. (This issue is managed automatically when using a .opbin file or using the standard Opal-RT repositories.)

Before executing the model, the user must verify the Automatic bitstream reprogramming option. With this option enabled, the bitstream is flashed automatically at each load of the model. If the same bitstream is detected, then it is reloaded in the FPGA. To bypass any programming/reload, the option must be disabled. To force the programming regardless of the bitstream being the same, the Force checkbox must be enabled.

NOTE: If the Automatic bitstream reprogramming option is not available, the bitstream file was not found.

To overcome this issue, follow these steps:

• Make sure the .opal file given by the field Bitstream configuration file exists
• If it doesn't exist, find it and copy it in the project directory
• Copy the .bin file to the project directory
• Close the project
• Re-open the project

Users can also program the bitstream using RT-LAB's flash utility (see Flash bitstream wizard in RT-LAB Help files).

The OPAL-RT Board interface shows the name of the expected bitstream file when the configuration file (.opal or .opbin) has been correctly imported.

For a list of the possible chassis and board/module combinations, consult the list of compatibilities in the 45897174 section.

See the General Configuration section below for more details on changing and loading configurations.

Configuring Remote I/Os

Loading the bitstream configuration reveals if the MuSE (Multi-System Expansion link) feature is supported. This feature expands the I/O capability of the simulator by enabling the connection to multiple FPGA-based I/O expansion chassis. Therefore, the user can configure, connect to and control I/Os belonging to a remote FPGA. The connection is done through high-speed optical fiber cables and SFP transceivers, using the SFP sockets available at the front or the left side of the chassis.

The user can see if the MuSE feature is supported right after loading a bitstream configuration file. If the feature is present, a list named Remote Boards Configuration appears in the interface. The system can, from that point on, be referred to as a central system. A central system is an FPGA whose bitstream gives it the capability of connecting to one or multiple remote FPGAs.

One remote chassis can be connected to each SFP socket of the central. The network of central and remote chassis is thus a star topology, with the central system in the center and the remotes as its leaves.
The remote chassis (as end-points) cannot be used as central systems (daisy-chaining of remotes is not supported), so a bitstream file prepared for a remote chassis cannot be used for a central system.
Hardware synchronization of the systems is achieved through the same high-speed link used for data transfer (i.e. only one cable is required at all times between the central system and any of its remotes).

Programming the remote systems is also done by using RT-LAB's flash utility or with the Automatic bitstream reprogramming option available in each remote's configuration view.

Check the Remote boards configuration section below for more information about how to set up remote systems.
Restrictions on using the Multi-System Expansion link with the OPAL-RT Board software architecture may apply depending on your application and software configuration. Contact your sales representative or field application engineer to verify compatibility.

For a list of the possible remote chassis and board/module combinations, consult the list of compatibilities in the 45897174 section.

Interface Overview

Configuration

The driver is entirely configurable via the RT-LAB interface. The parameters available for configuration are presented in this section.

General Configuration

The following options can be configured through the General section:

For more information, contact OPAL-RT's Support team.

Slot Configuration

When clicking this section, the fields provide the following information to the user:

Other parameters may appear here, depending on the I/O board type.

Channel Group Configuration

A group contains eight channels, with the following configurable options:

• Enable: Enables data transmission/reception of the specified channel group.

Other parameters may appear here if the current slot type is digital and the bitstream supports the use of selectable digital types. Refer to the Digital Out or Digital In the documentation for more information.

Signals Configuration

This section configures the characteristics (if any) of each of the eight channels available in a group. The content of this panel varies based on the I/O type present in the slot.

For more information regarding the detailed configuration of the signals, refer to the corresponding I/O type documentation.

Remote Board Configuration

Adding remote systems to the configuration is done by clicking the Insert button in the Remote Board Configuration list.

This list is only visible if the MuSE feature is available in the current bitstream configuration. The name of each remote can be changed in the remote list view of the interface.

Then, users can change the configuration of each remote (such as chassis type, chassis ID, bitstream configuration, and so on) by clicking the respective remote in the interface.

The view that appears is the same as the one for the central system. The user can refer to the beginning of the current section, starting with General Configuration for more information.

Similar to central systems, bitstream configuration files describing bitstreams for central (or standard, non-MuSE) FPGAs cannot be loaded for remote systems.

The format expected is XX:XX:XX:XX:XX:XX, where 'X' is a hexadecimal digit (0-9, A-F).

Currently, remote systems are forced to be synchronization slaves. This can be seen by the Use external synchronization source checkbox being selected but grayed out. Remote systems must be synchronized with the central system (i.e. they cannot use any other synchronization source).

The physical synchronization between central and remote systems is done through the same optical cable used for the data transfer (i.e. only one cable is needed between a central and any remote).

Other Logic Blocks' Configuration

If there are any other user-configurable logic blocks in the bitstream configuration file, they appear at the same level as the General section of the configuration tree.

The content of these panels varies based on the blocks present in the bitstream.

Currently, only the eHS block is supported; eHS is an electric solver created by OPAL-RT.

Chassis Type Update

The scenarios below show the different possible options when changing the chassis type.

1. When changing the chassis type, a warning will be displayed to notify the user that the bitstream configuration file might need to be changed. Regardless of the user input, the existing configuration is maintained.

If the bitstream configuration file does not match the new chassis type, the configuration can not be saved. The user will have to update the bitstream configuration file to one that is compatible with the chassis type chosen.

2. A central board's configuration can be reset at any time by changing the chassis type to Select a valid chassis type.

Bitstream Configuration File Update

When the bitstream configuration file is changed (whether to re-upload the same file whose contents might have been modified or to change the file entirely), a change detection mechanism will help the user make an informed decision about whether or not to continue with the update.

Bitstream configuration file change workflow

The following steps explain the workflow:

1. Select a bitstream configuration file (the same or different) from the drop-down containing available configuration files when Bitstream configuration location equals to Standard repositories or by clicking on the Bitstream configuration file value when Bitstream configuration location equals to File system. This will bring up the refresh menu, asking how to proceed with the configuration's editable parameters that originated from the initial file. The parameters affected by this choice are the ones marked as keep or reset in the table below, in the Common elements update section.

2. Select the type of refresh and click OK. A pop-up window will appear, listing all the changes and requesting user input on whether or not to apply them.

3. Click Yes then OK to apply the changes. 

4. The configuration can be reset when Bitstream configuration location equals Standard repositories. To do so, choose the option < Select your file > from the drop-down menu containing the available configurations

Detecting changes in the bitstream configuration file

When updating a bitstream configuration file, a slot is considered common between the old and new .opal files if the slot name is the same and the supported IO card type is compatible; channel groups within these slots are considered common if their names are the same.
A raw data item (as an example an element of the list Data to board or Load from board) is considered common if the same port is used in both files; this applies even if the maximum allowed DWORD count is not the same (the minimum of the two is kept). 
The Remote Boards Configuration is considered common if both files specify support of the MuSE functionality.

These concepts are illustrated in the examples below:

Example 1: 

The old bitstream configuration file defines a digital in card (OP5351) in Slot1A, an analog out card (OP5330-1) in Slot1B and a digital out card in Slot2A.

The new bitstream configuration file defines a digital in card (OP5367-5) in Slot1A, an analog out card (OP5330-3) in Slot1B and an analog in card in Slot2B.

Only Slot1B slot is considered in common :

• Slot1A : the slot name is the same however the digital in cards in the new and old bitstream configuration files are not compatible (refer to section General Compatibility Rules for Multiple I/O Card Types). When the new bitstream configuration file is applied, the information and configuration of Slot1A will be reset to the values contained in the new .opal.
• Slot1B : the slot name is the same and the analog out cards in the new and old bitstream configuration files are compatible (refer to section General Compatibility Rules for Multiple I/O Card Types). When the new bitstream configuration file is applied, the Slot1B IO card type is reset to the card type in the new file (OP5330-3), however the user configurations applied on the associated common channel groups will be kept.
• Slot2A : only available in the old bitstream and will be removed when the new bitstream configuration file is applied.
• Slot2B : only available in the new bitstream configuration file and will be added to the configuration when the file is applied.

Example 2: 

The old bitstream configuration file contains 2 Data from board items, using ports 0 and 1. Port 0 has a maximum DWORD count of 250, out which the user has configured 4.

The new bitstream configuration file contains 2 Data from board items, using ports 0 and 2. Port 0 has a maximum DWORD count of 2.

The port 0 is in common :

• Port 0: kept, but only the first 2 previously configured DWORDS remain, as the new maximum DWORD count has changed to 2.
• Port 1: removed due to not being defined in the new configuration file
• Port 2: added according to the new file

Example 3: 

Both old and new bitstream configuration files specify support of the MuSE feature; the remote boards configured by the user will be kept when loading the new file.

Common elements update

The parameters of the elements that were deemed common to both files according to the constraints explained above can be divided into 3 categories:

• keep: applies to parameters that did not originate from a bitstream configuration file, such as remote configuration parameters. The values of these parameters will remain unaltered during bitstream configuration file changes.
• reset: applies to read-only parameters that did originate from a bitstream configuration file, such as the slot description. Their value will be reset to the value found in the new bitstream configuration file.
• keep or reset: applies to editable parameters that did originate from a bitstream configuration file such as the high and low values for the threshold or the digital channel direction. Their value can be either kept or reset, depending on the user preference.

Connections

Once the driver has been configured, the user connects points in the model to points in the driver by using the designated Configuration section of the active project in RT-LAB's interface. This connection panel shows all driver- and model-connectable points.

Once the model has been compiled, users can also make connections with LabVIEW panels.

The driver's connectable points depend on its configuration, namely on the available types of I/Os (along with the number of channels enabled for each I/O)and available raw data transfer ports.

To get a list of the possible connectable points for each functionality, refer to its documentation.

Supported I/O Types

Multiple Subsystems

Opal-RT Board supports the distribution of connections over multiple subsystems. This can be useful to reduce the timestep of a model. To do this, users need to compile a model using multiple subsystems and dispatch the connections of the driver over these subsystems. As usual, each subsystem must be assigned to a dedicated core. The input channels of a subgroup can be distributed between all subsystems.

Output Limits

The following limitations exist for the outputs:

These connections can also be distributed over multi-rate subsystems and with an OPAL-RT Board with an external synchronization source.

Limitations

The current version of the OPAL-RT Board driver has the following limitations:

• This driver must be run in Hardware Synchronized mode.
• Only XHP mode is supported.
• The disable strict hardware mismatch validation feature is not available on OP5142.
• Each FPGA must have connections with at least one subsystem running at the model's timestep (in the context of multi-rate subsystems).
• A configuration having multi-rate subsystems associated with a slave FPGA board does not support the action of Pause/Execute during the simulation.
• On all chassis, the motor models are not supported for the moment.
• Chassis type OP5143 standalone is supported only for MuSE as central with four remotes. Using it as MuSE remote is not supported . It does not support any I/Os.

List of Compatibilities

Limitations of the Multi-System Expansion link feature

Restrictions to using the MuSE link with the OPAL-RT Board software architecture may apply depending on your application and software configuration. Contact your sales representative or field application engineer to verify compatibility

List of Module Compatibilities for the MuSE Feature