Aurora link with OPAL-RT via SFP

An introduction to Aurora communication with third-party devices is available in Aurora link with third-parties via SFP. This page extends that overview by presenting a practical example of SFP communication with OPAL-RT simulators, specifically the OP4510 and OP4512.

The proposed example relies on the user application and bitstream generation scripts introduced previously, and includes a fully functional RT-LAB project for the OPAL-RT simulator.

To support a broader range of use cases, the RT-LAB project deployed on the OPAL-RT target instantiates two SFP interfaces. The first interface is managed by eHS, OPAL-RT’s FPGA-based electrical toolbox and solver, while the second interface is controlled by the simulator’s CPU.

A simple loopback configuration is used to illustrate the setup: a three-phase sine wave is transmitted from the imperix controller, multiplied by two within the OPAL-RT simulator, and then sent back to the controller.

Case study

This case study demonstrates a straightforward signal processing loop:

• The controller generates a three-phase sine wave which is transmitted to the OP4510 via the Aurora protocol.
• Upon receipt, the OP4510 applies a gain of 2 to the three signals – doubling the amplitude of the sine wave – and returns them to the controller.
• Finally, the original transmitted values and the received return signals are compared in real-time in Cockpit, showing the proper operation of the system.

Required software

• Vivado Design Suite (version 2022.1 is recommended)
  The Xilinx installation page details the installation procedure.
• FPGA sandbox template 3.10 or later.
  Available on the FPGA download page.
• C++ or ACG SDK version 2024.3 or later.
  Available on the SDK download page.

On the third-party side, this project has been tested with an OP4510, RT-LAB 2024.1.6.55 and Matlab 2022B.

Downloads

As explained in setup overview, the SFP communication with any third-party device requires the three following software parts:

• The user application, running in the imperix controller’s CPU, provided as a Simulink or PLECS script.
• The FPGA bitstream, running in the imperix controller’s FPGA, provided as generation scripts. The scripts must be launched with Vivado to create a ready-to-use project.
• The OP4510 application, provided as an RT-LAB archive.

User application	FPGA bitstream	OP4510 application
aurora_ix_template.slx aurora_ix_template.plecs	aurora_ix_opalrt_gen_scripts.zip	aurora_ix_opalrt_rtlab.zip

Further details on Aurora communication for the OP4510 and OP4512 from OPAL-RT are provided below.

OP4510 project

The OP4510 project is provided as a ZIP archive that can be imported in RT-Lab, which contains the OP4510’s model, firmware, eHS model and configuration files.

Simulink model

The Simulink model contains the two main subsystems:

• SC_Console (left) to control and monitor signals in real-time.
• SM_Controller (right) that contains the OP4510 control program.

The SM_Controller subsystem contains two SFP interfaces to access SFP either from eHS (on port SFP CH00) or from the simulator’s CPU (on port SFP CH02). These interfaces are described in the subsequent sections.

Real-time variables can be defined in the SC_Console subsystem as constants and passed to the control logic of the SM_Controller subsystem (see the to_eHS ports in the screenshots above). Although this example doesn’t use that mechanism, the related ports and blocks are kept for easier future expansion of the model.

Two SFP interfaces

To support different usage scenarios, this project provides two simultaneous SFP interfaces, enabling communication either with eHS – the FPGA-based electrical toolbox and solver from OPAL-RT – or with the simulator’s CPU. The characteristics of each interface are summarized in the table below.

Additional details on using both interfaces can be found in the OPAL-RT documentation available in the Downloads section.

Interface name	Location	Timestep	Use case(s)	SFP port
eHS	FPGA	A few FPGA cycles (depends on the simulated circuit)	Simulation of power circuits only (in eHS)	SFP CH00
CPU	CPU	CPU period	Simulation of power circuits or any other use (in Simulink)	SFP CH02

From the imperix controller perspective, the choice of interface has no impact. In both cases, the values are expected to be doubled in the OP4510.

eHS interface

The eHS circuit is designed from the Schematic Editor of OPAL-RT and directly embedded in the Simulink model, as shown in the right capture of the Simulink model section above. Double-click on the eHS ‘OpCtrl’ block to open the eHS circuit in the Schematic Editor.

In the eHS circuit, controlled voltage sources are fed by the incoming SFP values and placed in series with 0.5Ω resistors. The current flowing through the resistors is sent back to the imperix controller.

CPU interface

For the CPU-based SFP control method, the incoming values are simply manually multiplied by two. As the ‘DataOut Recv’ and ‘DataIn Send’ blocks manipulate the data as unsigned integers, a datatype conversion is applied upon reception and before transmission in the OP4510.

Import in RT-LAB

To import the project, click on File > Import. Then, in the Import window, expand RT-LAB, select Existing RT-LAB Project and click Next. In the next window, select Select archive file and navigate to the location where the archive is locally stored. Finally, press Finish.

Once the model is imported, double-click on it in the Project Explorer to open it. Navigate to Models and double-click on the model. Then, in the main panel, successively click on Build, Load and Execute.

During the loading phase, a new Simulink model is automatically created based on the SC_Console subsystem. This model is intended to be used when the code is running to control the constants and monitor data in real-time.

Open the scope when the code is running to observe the data exchanged between the imperix controller and the OP4510. Change the monitored interface (eHS or CPU-based) by setting the dedicated constant in the console.

Communication chain

Overview

The overview of the communication chain is presented in the setup overview.

The main clock domain always runs at 250 MHz, while the frequency of the Aurora clock domain varies with the configuration of the Aurora IP. In this example, the frequency is 125 MHz with the configuration presented in the Aurora parameters section.

Vivado project

The Vivado project is provided in the form of generation scripts. As explained in the Generate the bitstream section, the scripts automatically create and open the project illustrated below. The bitstream can be directly generated by simply pressing Generate Bitstream in the left navigation bar in the Vivado environment.

As provided, the driver supports the exchange of up to 32 signals in each direction and the Aurora communication is linked to the SFP 0 (UP) port of the imperix controller.

Once generated, the bitstream can be loaded onto the imperix controller using Cockpit. A reboot is required for the bitstream change to take effect.

Modules/IPs description

The Vivado project contains the following VHDL modules and IPs.

Module name	Type	Description
sbio_256_registers	VHDL module	Instantiates and provides access to SBIO bus registers in the FPGA. See this page for more details.
convert_16b_to_32b	VHDL module	Converts the 16-bit words of the SBIO bus back into the 32-bit words of the payload.
aurora_ix_opalrt_driver	VHDL module	Custom driver provided by imperix to communicate with the OP4510 from OPAL-RT ; mainly acts are a parallel-to-serial transmitter and serial-to-parallel receiver.
convert_32b_to_16b	VHDL module	Converts the 32-bit words received from the OP4510 through the driver into 16-bit words compatible with the SBIO bus.
latcher	VHDL module	Ensures data coherency by preventing the update of the SBI registers while the CPU is reading.
AXI4-Stream Data FIFO	Vivado IP (Xilinx)	Handles the clock domain crossing between the main 250 MHz domain of the imperix firmware and the Aurora clock domain ; buffers the frame in the transmission direction.
Aurora 8B10B	Vivado IP (Xilinx)	Handles the Aurora communication and interfaces with the underlying hardware logic.
Utility Vector Logic	Vivado IP (Xilinx)	Converts the active-high reset signal from the sync_pulse into an active-low reset signal for the FIFOs.

Aurora parameters

To establish communication with the OP4510, the Aurora IP must be configured with the parameters listed below. Any settings not specified here should remain at their default values.

Protocol	Aurora 8B10B	Interface	Framing
Line Width (Bytes)	4	Flow Control	None
Line Rate (Gbps)	5	Little Endian Support	Yes
Dataflow Mode	Duplex	CRC	Yes

Experimental validation

Physical setup

The physical setup is straightforward:

1. Connect both devices to the network, so that they can be configured and monitored from the PC.
2. Connect the imperix controller to the OP4510 with an SFP cable. As provided, this example considers the port SFP 0 (UP) on the controller and SFP CH00 (eHS) or SFP CH02 (CPU) on the OP4510.
3. Turn on the two devices.

Software-side setup

To experimentally validate the system:

1. Download the three software parts available in the downloads section.
2. Import the project in RT-LAB. Build, load and execute it on the OP4510, as explained in the Import in RT-LAB section above.
3. Generate the bitstream for the imperix controller.
4. Load the bitstream on the imperix controller via Cockpit.
5. Build the user application template and launch it on the imperix controller via Cockpit.
6. Use Cockpit to monitor the exchanged signals.

The whole system should now be running.

Real-time monitoring

Connect to the imperix controller with Cockpit. Add a scope in the project (from the Modules tab in the top bar) and drag-and-drop the variables of interest.

The exchanged signals can now be monitored in real-time in Cockpit. As expected, the amplitude of the transmitted signals is multiplied by two in the OP4510.

The exchanged signals can also be monitored from the OP4510, as described in the Import in RT-LAB section. If the real-time signals stay at 0, ensure that the constant in the real-time console selects the right interface (1 for eHS, 0 for CPU).