Description

The OPAL-RT board I/O interface allows the user to configure the various OPAL-RT analog and digital I/O boards.

To access the user interface, click the I/O Interface Configuration button in the HYPERSIM ribbon options. 

In the window that appears, right-click OPAL-RT Board and select Add.

After giving a relevant name to the I/O interface, its user interface is available for use.

The I/O interface must be configured, and valid connections must be defined before the I/O interface can be initialized at simulation start.

One  I/O interface per FPGA must be used. To differentiate one from another, they must have unique names.

Bitstream Configuration

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, a valid .opal or a valid .opbin file based on the board type must be selected by 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 both a .opal file and a bitstream file.

As described 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, the user must 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.

If the Automatic bitstream reprogramming option is not available, it means 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 in the project directory.

• Close the I/O Interface Configuration.

• Re-open the I/O Interface Configuration.

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

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

Configuring Remote I/Os

Loading the bitstream configuration lets users know 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 or OP4200 systems. Thus, it allows the user to configure, connect to, and control I/Os belonging to a remote FPGA. The connection is made 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 verify if the MuSE feature is supported directly after loading a bitstream configuration file. If the feature is present, a list labeled Remote Board Configuration appears in the UI. From this point on, the system can 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 endpoints.

The remote chassis status as endpoints means that they 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 as the one used for data transfer (i.e. only one cable is required at all times between the central system and any of its remotes).

The programming of remote bitstreams is done by invoking the flashing application executed on the central system.

For more information on how to do this, please contact OPAL-RT's support team.

Please check the Remote Board Configuration section below for more information on how to set up remote systems.

Restrictions to using the Multi-System Expansion link with software architecture may apply depending on your application and software configuration.

To verify compatibility, please contact OPAL-RT's support team.

For a list of the possible chassis and board/module combinations, please consult the List of Module Compatibilities for the MuSE feature section.

Interface Overview: Configuration

Open

The I/O interface is entirely configurable via the HYPERSIM interface. Parameters available for configuration are presented in this section.

General Configuration

The following options can be configured when clicking the I/O interface main configuration page:

Slot configuration

When this section is clocked, 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, depending on the I/O board type.

Signal Configuration

This section allows the user to configure the characteristics (if any) of each of the 8 channels available in a group. The content of this panel varies based on the I/O board type defined in the slot.

For more information regarding the detailed configuration of the signals, refer to the corresponding I/O type documentation in the sections below:

Remote Board Configuration

Add remote systems to the configuration 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.

Following this, the configuration of each remote (such as chassis type, chassis ID, bitstream configuration, and so on) is done by clicking the respective remote in the interface.

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

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

When the remote system chosen is an OP4200, the user has to provide its MAC address. The MAC address can be found by running the "ifconfig" command on the remote system, or by consulting the delivery binder. 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 synchronized slaves. This can be seen through 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).

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.

Open

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 browse button 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 I/O interface has been configured, the user must connect points in the model to points in the I/O interface. This can be done using the standard HYPERSIM workflow for connections.

The I/O interface connectable points depend on its configuration, namely on the available types of I/O and the number of channels enabled for each I/O board.

For a list of the possible connectable points of each I/O type, refer to its documentation. 

Supported I/O Types

Limitations

The current version of the I/O interface has the following limitations:

• The Disable strict hardware mismatch validation feature is not available on OP5142 (OP5600).

• On all chassis, FPGA-simulated motor models are not supported at 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.

• The change detection mechanism when the bitstream configuration file is updated in only available when Bitstream configuration location is set to File system.

• For the chassis types OP4810 and OP4815, the maximum support PDI file size is 64 MiB.
  
  

List of Compatibilities

Limitations of the Multi-System Expansion Link Feature

Restrictions to using the MuSE link with the software architecture may apply depending on your application and software configuration. To verify compatibility, please contact OPAL-RT's support team.

List of Module Compatibilities for the MuSE feature

General Compatibility Rules for Multiple I/O Card Types