Pour la documentation en FRANÇAIS, utilisez l’outil de traduction de votre navigateur Chrome, Edge ou Safari. Voir un exemple.


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

NOTE: The current solution is not compatible with Simulink blocks from the RT-LAB IO/OPAL-RT library (such as OpCtrl or OpLnk blocks).

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 Limitations 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).

Unlike the PCIe expansion chassis, the order in which the systems are powered on or the order in which the cables are connected does not matter. Nor does it matter whether or not the systems are on at the moment when the cables are being connected.
What is important is that the system topology is set in place (i.e. all cables connected according to the simulation's requirements) before the start of the simulation, and remain connected throughout the simulation.
Changes to the topology cannot be made while the simulation is running.

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 Limitations section.

Interface Overview


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:

Chassis typeSelect the chassis used in the simulation.
Chassis IDEnter the chassis ID of the selected FPGA board in the simulation.

Use external synchronization source

When selected, the board uses an external synchronization source as opposed to its internal clock.
Operate as hardware synchronization source must be checked if the external synchronization source comes from another simulation (i.e. another model).

Type of generated synchronization signal

If the Use external synchronization source box above is unchecked, then this parameter is visible, allowing the user to choose the medium where the FPGA outputs its synchronization pulse: choices are through the optical cable or through the audio cable.

NOTE: Spartan-3 cards (OP5142) have only one type of synchronization signal, RTSI. This signal is routed to the necessary synchronization converters (audio or optical), according to the system's assembly.

Operate as a hardware synchronization source

Only visible if the Use external synchronization source checkbox above is enabled. 

  • When enabled, the FPGA is configured to use the external synchronization source received to synchronize the simulation (master-with-external-clock mode)
  • When disabled, the FPGA is configured to use the external synchronization source received but it will not qualify to drive the simulation (slave mode)
Type of expected synchronization signal

This parameter is only visible if the Use external synchronization source checkbox above is enabled. It is a drop-down menu giving the user the choice to synchronize either through copper or optical cables.

NOTE: Spartan-3 cards (OP5142) have only one type of synchronization signal, RTSI. This signal is routed to the necessary synchronization converters (audio or optical), according to the system's assembly.

Bitstream configuration locationThis field allows either searching the bitstream configuration file using the file system or selecting it from a drop-down list based on the available files in the standard OPAL-RT repositories.
Bitstream configuration file

If the bitstream configuration location is set to File system

  • A file-browsing field appears.
  • Clicking it opens a File Explorer window to navigate to the bitstream configuration file.

This file must be in the [board_type]_[file_name].extension format.

The .extension can either be .opal or .opbin. Example: VC707_Config1.opal or VC707_Config1.opbin.

If the bitstream configuration location is set to Standard repositories:
A drop-down with the available configuration files found in the standard Opal-RT repositories appears.

Once a file is selected and the interface has checked validity, the Folders section of the configuration panel updates to show the I/O capability of each slot as described in the file.

Show advanced configuration

When selected, the user can configure advanced features:
Time step factorDenotes a multiplier for the board's speed in relation to the model's timestep.
Enable FPGA register logger

For advanced debugging purposes, the driver will start a tool that will log all the FPGA register accesses during the initialization and the reset of the model. The logs will be saved in files named with the prefix "register_trace*". Those files are retrieved on the host PC after the reset of the model.

Automatic bitstream reprogramming

If selected, bitstream programming is triggered automatically at the model load.

The bitstreams should be placed at the model path and must have the name given in the configuration file used.

If the bitstream currently programmed in the board is found to be the same as the one about to be programmed, then the bitstream is reloaded into the FPGA. The field is not available if the bitstream file is not Found.

Bitstream file nameA static field showing the bitstream found based on the selected bitstream configuration file.
ForceThis option flashes the board even if it is already programmed with the same bitstream.
Disable strict hardware mismatch validationIf selected, the use of multiple I/O card types based on general compatibility rules is activated instead of exact hardware ID values.
Enable FPGA ScopeIf selected, the FPGA Scope will be available when the model is executed. The option is visible only if the feature is available in the selected bitstream configuration file.
Enable virtual modeIn virtual mode, the model can be executed even if this I/O interface is not compatible with the hardware configuration of the system. The connections between the model and the I/O interface will be done during the initialization, but the I/O interface will not do anything. The virtual mode can be used to troubleshoot problems on a system without having the required hardware, or to prepare a model with different I/O interfaces even if the final hardware platform is not available.

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

Slot Configuration

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

DescriptionElectrical characteristics of the slot.
FunctionalityType and direction of the I/Os in the slot.
I/O card typeI/O board identifier.

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.


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

I/O NameDirection
Analog InTo model
Analog OutFrom model
Digital InTo model
Digital OutFrom model
Raw Data From Board (DataOUT)To model
Raw Data To Board (DataIN)From model
Asynchronous Raw Data From Board (LoadOUT)To model
Asynchronous Raw Data To Board (LoadIN)From model

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.


A channel subgroup is a group of 8 channels. The figure shows a digital output slot with four different subgroups.

Output Limits

The following limitations exist for the outputs:

Output typeSupported connections distribution

Static digital out

Connections inside a channel subgroup can be distributed over multiple subsystems. 

For example, if we have 3 subsystems, SM_one, SS_two, SS_ three we can have those connections: 

Digital out Channels 0 -7 (Static)Connection
Analog out

PWM digital out

All channels in a subgroup must belong to the same subsystem.

It means that for example, if we have Slot 1B -Digital out → Channels 16 - 23 (Pulse width modulated), all connection points related to that module must be connected to only one subsystem.

Event generator digital out

Resolver out

Encoder out

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


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

Chassis and FPGA boardSupported
OP4500 with an MMPK7 moduleNo longer supported.
OP4510 with a TE0741 moduleYes
OP4512 with a TE0741 module
OP4520 I/O expansion box with a TE0741 module
OP4610 with a TE0741 module
OP5600 with an OP5142 board
OP5600 with an OP5143 board
OP5600 with an ML605 boardNo
OP5607 I/O expansion box with a VC707 boardYes
OP5707 with a VC707 board
OP7020 I/O expansion box with a VC707 board


OP5143 standalone PCIe cardYes

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

Chassis and FPGA boardCentralRemote
OP4500 with an MMPK7 moduleNoNo
OP4510 with a TE0741 moduleYesYes
OP4512 with a TE0741 moduleYes
OP4520 I/O expansion box with a TE0741 moduleYes, if connected via PCIe to a simulator
OP4610 with a TE0741 moduleYes
OP5600 with an OP5142 boardNoNo
OP5650 with an OP5143 boardYesYes
OP5600 with an ML605 boardNoNo
OP5607 I/O expansion box with a VC707 boardYes, if connected via PCIe to a simulatorYes
OP5700 with a VC707 boardYes
OP7020 I/O expansion box with a VC707 boardYes, if connected via PCIe to a simulator
OP5143 standaloneYesNo
  • No labels