SFP Simulation Link

Description of the SFP Simulation Link protocol and its implementation in the Typhoon HIL Toolchain.

SFP Simulation Link is a bidirectional, open protocol interface than allows high bandwidth, low latency data exchange between the devices. Primary application of the interface is in PHIL applications and in heterogeneous, multi-vendor simulation setups. SFP Simulation Link characteristics are:
  • Vendor agnostic
  • Point-to-point link - with routable frames
  • Easy to implement and use:
    • Compliant with the majority of the existing real-time simulation platforms
    • Light on FPGA resources
    • Freely available reference designs / IP cores
  • High bandwidth - more than 1 million messages per second in typical applications
  • Low latency - lower than 1us
  • Reliable - built-in synchronization and safety features
SFP Simulation Link supports two modes of operation:
  • Signal processing mode - payload is periodically configured by a CPU, after which the frame is sent
  • High speed mode - values of the variables to be sent are read directly from the FPGA solver. Conversely, received variables are injected into the FPGA solver. This occurs every simulation step.

Physical Layer

As its name suggests, the physical layer is based on the Small Form-factor Pluggable (SFP) transceivers. The SFP Simulation Link uses Xilinx Aurora link-layer protocol configured in the following way:
  • Duplex dataflow
  • Framed data
  • 8b/10b encoding
  • 5 Gbps line rate
  • No Cyclic Redundancy Check (CRC) for data

Application Layer

The application layer enables variable exchange by means of multi-variable messages.

SFP Simulation Link uses Aurora UFC (User Flow Control) interface for auxiliary functions such as time synchronization and status information exchange. UFC messages are sent on every signal value change.

SFP Simulation Link can be implemented on most Xilinx FPGA and SoC devices with gigabit transceivers. Protocol endpoint reference design for Xilinx VC707 development board is available here.

Message format

The following section describes the message format used by SFP Simulation Link version 0.1. Message format might change in the upcoming versions.

Data frames consist of:
  1. Header (optional)
  2. Payload data

Frame Header

Header content is defined below. It will likely be extended in the upcoming protocol versions. It can be disabled.

Table 1. SFP Link Header format
Field name Width (bits) Description
Reserved 2 Reserved for future use
Src ID 2 Source device ID
Reserved 2 Reserved for future use
Dest ID 2 Destination device ID
Payload size 8 Payload size in words
Protocol version 8 Encoded protocol version. In case of version mismatch between the sender and the receiver the message should be discarded.
Reserved 8 Reserved for future use

Frame Payload

In signal processing mode, the maximum payload size is 250 words (4 bytes each) and each word can be assigned its own data type, be it signed/unsigned 32-bit integer or IEEE754 floating point. In high speed mode, sending and receiving are limited to 32 and 16 words of IEEE754 floating point respectively.

Typhoon HIL Implementation

Currently, SFP Simulation Link is supported by the following Typhoon HIL devices: HIL101, HIL404, HIL506 and HIL606.

The upper SFP connector on a HIL101 and HIL404 is used when SFP link components are present in the model. When no SFP Link components are present in the model, the upper SFP connector is used for device paralleling or for Egston SFP Link.

HIL506 and HIL606 have two SFP ports dedicated exclusively for SFP Simulation Link or Egston SFP Link. In HIL506 and HIL606 firmware configurations with only one SFP Simulation Link channel present, the channel will be tied to the lower SFP port on the device.

SFP Setup

The SFP Setup component is used to configure the SFP Simulation Link parameters and provide the link status. For now its functionality is limited to setting the device ID used by SFP Send and Receive components. The SFP link device ID can be defined either by the position of the rotary switch or explicitly by the component property. The output port of the SFP Setup component provides the SFP Link physical status where one (1) means that the link is up. Header readout can be done via two additional output ports which appear when the "Header output" property is checked. The first one outputs the value of the last received frame header. The second one outputs the validity of the header, where one (1) means that the received header is valid and the frame is received and data is extracted from the frame, and zero (0) indicates that the frame is received but then rerouted or discarded.

Table 2. SFP Setup
Component Component dialog Component properties

SFP Setup
  • Disable header
  • Header output
  • Override HIL device ID
  • Device ID

Component properties are described in Table 3.

Table 3. SFP Setup properties
Property name Description
Disable header Disables the frame header. Frames will be sent without a header, and received frames will be regarded as if they contain no header.
Header output Enables readout of the last received frame header.
Override HIL device ID Allows to override the device ID used by the SFP Send and Receive component. When unchecked, the HIL Device ID is defined by the rotary switch on the HIL Device backplate.
Device ID The device ID to be used instead of the HIL device ID.

In models that use multiple devices, one SFP Setup component should exist for each device that uses the SFP link.

SFP Send

The SFP Send component enables sending data through the SFP link. In signal processing mode, payload size is calculated as the sum of dimensions of all input signals in the variable configuration, whereas in high speed mode it is determined by the "Number of signals to send" property value.

Table 4. SFP Send
Component Component dialog Component property

SFP Send

(signal processing)
  • General tab
    • SFP port
    • Destination device ID
    • High speed SFP send
    • Execution rate
  • Data tab (signal processing)
    • Variable configuration
  • Data tab (high speed)
    • Number of signals to send
    • Signal selection properties

SFP Send

(high speed)

Component properties are listed in the table Table 5.

Table 5. SFP Send properties
Property name Description
SFP port Selects the SFP port through which the communication is established.
Destination device ID Endpoint Device ID.
High speed send Checkbox which enables fast signal sending.
Execution rate Signal processing execution rate. Execution rate must match with the other components in the model.
Variable configuration Defines the payload of the Send component SFP frame. For more information on how to configure the payload check the SFP Send variable configuration section.
Number of signals to send Defines number of signals that will be sent through SFP link in high speed mode.
Signal selection Selects current or voltage measurement signals which will be sent in high speed mode. They can be selected directly from the Schematic Editor, without the need to connect a signal processing input.
Ports
  • Input ports- defined by variable configuration
  • Output ports
    • dev_id_connection - present when high speed send is enabled, used only to tie the component to a device marker when needed

SFP Send variable configuration

To change the variable configuration, use the Generate configuration button in the Data tab.

Figure 1. Generate configuration options for the SFP Send component

In the configuration menu, you can customize the payload to be sent via SFP.

Table 6 contains an overview of the variable configuration menu.

Table 6. Variable configuration menu - fields explanation
Field name Description
Signal name Unique for each signal.
Data type Allowed data types are inherit (depends on the type of input signal), integer, unsigned integer or real.
Dimension Number of variables of the same data type to be sent. This value dictates the dimension of the input terminal.

SFP Receive

The SFP Receive component enables receiving data over the SFP link. In signal processing mode, the payload size is determined by the variable configuration, whereas in high speed mode it is determined by the "Number of received variables" property value.

Table 7. SFP Receive
Component Component dialog Component properties

SFP Receive

(signal processing)
  • SFP port
  • Source device ID
  • High speed SFP receive
  • Execution rate
  • Variable configuration
  • Number of received variables

SFP Receive

(high speed)

Component properties are listed in the table Table 8.

Table 8. SFP Receive properties
Property name Description
SFP port Selects the SFP port through which communication is established.
Source device ID Specifies the endpoint device ID.
High speed SFP receive Allows access to received signals through SFP Link directly by selecting them in Voltage Controlled Voltage Sources. They will be available as voltage measurements in SFP Receive component.
Execution rate Refresh rate of the outputs.
Variable configuration Defines the payload of the Receive component. For more information on how to configure the payload, check the SFP Receive variable configuration section.
Number of received variables Specifies receive variable number.
Ports
  • Power electronics ports
    • port1 - present when the high speed receive is enabled, used only to tie the component to a device marker when needed
  • Signal processing output ports- defined by variable configuration

SFP Receive variable configuration

To change variable configuration, use the Generate configuration button.

Figure 2. Generate configuration options for the SFP Receive component

In the configuration menu, you can customize the frame payload to be received via SFP.

Table 6 contains an overview of the variable configuration menu.

Table 9. Variable configuration menu - fields explanation
Field name Description
Signal name Unique for each signal.
Data type Allowed data types are integer, unsigned integer or real.
Dimension Number of variables of the same data type to be received. This value dictates the dimension of the output terminal.

Virtual HIL support

Virtual HIL currently does not support this protocol. When using a Virtual HIL environment (e.g. when running the model on a local computer), inputs to this component will be discarded and outputs from this component will be zeroed.