This technical note aims to replace the traditional inner-loop discrete PI current regulator with a lightweight feedforward neural network (FNN), a form of supervised machine learning. The FNN is designed to accurately reproduce the voltage-reference mapping within a standard grid-following current control structure. Finally, this approach is validated by implementing the ANN-based controller on a physical TPI8032 programmable inverter.

Classification of ANNs

Depending on the learning task, ANNs are generally categorized into two main groups: classification and regression. Classification is used for discrete decisions, while regression handles continuous predictions. In power electronics, this distinction aligns perfectly with how the ANN drives the converter:

• Direct control (Classification): The ANN directly generates the discrete gate signals (e.g., ON/OFF) for the semiconductor switches. As the outputs are discrete states, this is formulated as a classification problem.
• Indirect control (Regression): The ANN calculates a continuous control variable, such as the voltage reference or duty cycle, which is then fed into a modulator. As the output is a continuous numerical value, this requires a regression model.

In this technical note, the ANN replaces a standard discrete PI current controller, meaning it needs to map a continuous voltage reference. Therefore, an indirect control strategy based on a regression ANN is implemented.

Beyond their learning task, ANNs can also be classified by their internal topology into feedforward and recurrent architectures. Feedforward neural networks (FNNs) process data strictly in one direction (see Fig. 1). As static, memoryless systems, FNNs lack an internal state and require past samples to be explicitly included in the input vector to account for historical data. Standard feedforward models include Multilayer Perceptrons, Radial Basis Function networks, and Convolutional Neural Networks. In contrast, recurrent networks, including LSTMs and GRUs, incorporate feedback loops that retain an internal memory of past inputs (see Fig. 2). This makes them highly effective for modeling dynamic, time-dependent systems [3].

From all of these available ANN architectures, the Multilayer Perceptron (MLP) FNN is frequently adopted as a baseline due to its simplicity and implementation efficiency and is widely used in industrial applications [1]. Therefore, for this technical note, the MLP-FNN is selected for its strictly feedforward architecture, which ensures deterministic, low-latency execution required for a high-bandwidth controller. Additionally, its capability as a universal function approximator allows it to accurately reproduce the PI controller’s input-output mapping with minimal computational overhead.

MLP-FNN architecture

An MLP-FNN architecture typically comprises an input layer, one or more hidden layers, and an output layer, each containing one or multiple interconnected neurons, as illustrated in Fig. 1. Within each neuron, incoming signals are multiplied by their respective connection weights (\(w\)), which represent the strength of the input, summed together, and then shifted by a bias term (\(b\)). Finally, the aggregated value is passed through an activation function to generate the neuron’s output signal. This function is a mathematical operation that can include non-linearity, allowing the network to learn and model complex patterns beyond simple linear relationships. By iteratively adjusting the weights and biases during the training phase, the FNN encodes the learned relationships, enabling it to generalize accurately across its intended operating region [3].

Important concepts related to ANNs in general, and FNNs in particular, are detailed below:

Mathematical representation of FNN

Referring to Fig. 1, let the input vector be $x=[x_1​​⋯​x_m​​]^⊤∈R^m$, and the output vector be $y=[y_1​​⋯​y_n​​]^⊤∈R^n.$

A typical mathematical expression for the output of neuron $j$ in layer $l$:

where $w_{ji}$ is the weight connecting neuron $i$ in layer $l-1$ to neuron $j$ in layer $l$, $b_j$ is an offset, $n_{l-1}$ is the number of neurons in the preceding layer, and $N_{(l)}$( ⋅ ) is the activation function of layer $\ell$.

Activation functions

To enable the network to learn complex non-linear mappings, the neurons must utilize non-linear activation functions. For the network to be compatible with standard network training algorithms, these activation functions must be differentiable or piecewise differentiable. Among the various options available, the Rectified Linear Unit (ReLU) is the most commonly used due to its computational efficiency and effectiveness in mitigating gradient-related issues during training [4]. Fig. 3 illustrates some important activation functions commonly used in ANNs.

Network topology and design flexibility

FNN offers a significant degree of design flexibility. While the dimensionality of the input and output layers is typically determined by the physical system, the internal structure is largely user-defined. Key design choices include the number of hidden layers (depth), the number of neurons per layer (width), and the connectivity scheme (e.g., all-to-all vs. sparsified connections). Specifically, increasing the network’s depth enables it to learn highly complex, hierarchical abstractions of the data, while expanding its width allows it to capture a broader array of features at each processing stage. However, a model with excessive depth or width risks overfitting and needlessly inflating the execution time. Ultimately, this architectural freedom allows the user to carefully balance model learning capacity against the strict computational constraints of the physical application [4].

Training algorithms

The training algorithm used to calculate the network’s weight matrix depends on the architecture’s complexity. For simple, single-layer networks with linear input-output relationships, analytical methods such as the Pseudo-inverse or LASSO can be used for the direct optimization of the weights and biases. However, for multi-layer ANNs utilizing non-linear activation functions, iterative optimization methods are required.

Central to this iterative process is the loss function, which quantifies the error between the model’s predictions and the actual target values. Its primary function is to guide the optimization process, which iteratively adjusts the network’s weights and bias to minimize the error and improve the model’s accuracy.

The process of minimizing the loss in MLP-FNNs relies on two complementary phases: calculating the error gradients and updating the network weights and biases:

• Backpropagation is a computational algorithm that calculates the gradients of the loss function with respect to each weight by propagating the error information backward through the layers using the chain rule.
• Optimization algorithms use those calculated gradients to update the network parameters. While Stochastic Gradient Descent is a common first-order optimizer that takes steps in the direction of the steepest descent, second-order methods like the Levenberg-Marquardt algorithm are also widely used. Levenberg-Marquardt dynamically blends gradient descent with Gauss-Newton optimization, allowing for much faster convergence on moderate-sized problems.

Together, these mechanisms enable the network to learn from data. However, the speed and stability of this convergence are heavily influenced by the chosen hyperparameters. These hyperparameters are external configuration variables set before the training process begins, as opposed to parameters (weights and biases), which are learned during training. They govern the network’s structure (e.g., number of layers, number of neurons) and the learning process (e.g., learning rate, batch size) to optimize performance.

Data partitioning and validation

To ensure the model generalizes effectively to unseen operating conditions, the dataset is typically partitioned into three distinct subsets: training, validation, and testing. The training data is used directly by the algorithm to update the network’s weights and biases. While hyperparameters must be fixed before a training run begins, the validation data is used to evaluate the model’s performance under those specific settings, allowing the designer to iteratively tune the configuration across multiple independent runs. Finally, the test set provides a completely independent, unbiased evaluation of the final model to confirm its true performance on strictly unseen data.

During optimization, the training algorithm iterates through the data over several epochs, continuously adjusting the weights and biases to minimize the prediction error. This training process typically continues until the error on the validation set reaches a threshold and begins to increase. Halting the process at this exact point, a technique known as early stopping, is crucial to prevent the network from overfitting, thereby ensuring robust performance when deployed [4].

Challenges of ANN-based control

Implementing ANN-based control in converter applications presents several specific challenges:

• Data dependencies: The controller’s performance is intrinsically tied to the quality and breadth of the training dataset. Obtaining large, well-balanced datasets that cover the entire operating region, including rare events like faults, is often costly and time-consuming. Underrepresentation of these edge cases can lead to poor generalization.
• Design trade-offs and overfitting: Selecting the network architecture requires balancing accuracy against robustness. While increasing network depth and width enhances representational capacity, it raises computational costs and increases the risk of overfitting (learning noise rather than system dynamics). Cross-validation is essential to mitigate this risk [4].
• Verification and interpretability: Unlike standard linear controllers, ANNs often function as “black boxes” lacking analytical stability proofs. Consequently, safety-critical deployment typically requires auxiliary safety mechanisms, such as output saturations, runtime monitors, and fallback logic.

Experimental implementation of an ANN-based control

As an application example, an indirect MLP-FNN is implemented to regulate the output current of a three-phase grid-following converter. This example replaces the inner-loop PI current regulator with an offline-trained MLP-FNN. The deployment of the indirect FNN is performed at the controller interface, as shown in Fig. 4. The PLL synchronization, modulation (SVM), and protections remain unchanged, while the FNN reproduces the PI controller’s voltage-reference generation behavior.

Structure of FNN

Instead of learning the full converter dynamics, the FNN is trained to emulate the mapping performed by the discrete PI current controller. At each control step $k$, the FNN receives a set of controller-relevant input signals, and it outputs the corresponding voltage reference in dq coordinates. The input vector is constructed such that it captures the useful information that could be helpful for FNN in mapping the input vector to the output vector.

• Inputs (5 inputs): $x(k)=[\sum{K_i e_d(k)}, \sum{K_i e_q​(k)},e_d (k),e _q (k), ω(k)]$, where the first two terms are the PI integrator states, $e _d ​ (k),e _q ​ (k)$ are the error terms used by the discrete PI controller, and $\omega(k)$ is the measured grid angular frequency.
• Hidden layers: two layers, containing 32 and 16 neurons, respectively.
• Outputs (2 regression outputs): $y(k)=[E_{g,d} ​ (k),E_{g,q} ​ (k)]$.
• Activation function: tansig is used in hidden layers and pure linear is used in the output layer (see Fig. 3).

This structure ensures that the FNN can act as a replacement for the PI controller. It receives the same internal control signals as a discrete PI controller would receive, and produces the same voltage reference quantities.

Data collection and preprocessing

Training data is generated using a vector current control scheme by simulating the grid-following converter in Simulink across a range of operating conditions and reference variations, e.g., different profiles for $i_d^{ref}$and $i_q^{ref}$, different DC-link voltage, and grid voltage magnitudes. Training data should be gathered by manipulating the variables in such a way as to cover the desired solutionspace. For each simulation run, signals are logged and consolidated into a measurements array.

All experiments are concatenated into a single supervised dataset by stacking time samples from each run. In this case, the total number of samples in the training dataset is 345,632. After that, invalid samples are removed. This step is important when concatenating logs from many simulation runs, especially when protections may cause undefined values during transients or failed runs. To stabilize training and keep signals in comparable numeric ranges, fixed scaling factors are applied. This normalization is part of the controller definition: the same scaling must be reproduced in Simulink at inference time, and FNN outputs must be de-scaled back before being used.

Training and deployment

The Levenberg-Marquardt optimization algorithm is selected to train the FNN, as it is effective when the network is moderate in size, and it also converges relatively fast for small to moderate multi-layer perceptron regression problems. Additionally, Mean Squared Error (MSE) is chosen as the loss function. Some of the key implemented hyperparameters are:

• Maximum epochs (2000): The absolute limit on training iterations if the network does not reach convergence earlier.
• Performance goal (1e-7): The target MSE; training halts successfully if the loss falls below this threshold.
• Initial learning rate (1e-3): The starting step size used by the optimizer to update the network weights.
• Minimum gradient (1e-8): The threshold at which weight updates become numerically insignificant. If the gradient drops below this value, the optimizer has reached a flat region and training stops.
• Validation early stopping (max_fail = 20): The number of consecutive epochs the validation loss is permitted to worsen before training is terminated. This prevents overfitting while allowing for typical, temporary fluctuations in the loss curve.)

The data is divided into a standard 70/15/15 split (training/validation/test) to ensure robust learning and unbiased performance evaluation. Training yields a final network with optimized weights and biases. For deployment, the trained model can be integrated into Simulink by generating a callable MATLAB function with genFunction().

Tips to improve the ANN performance

• It is recommended to excite the system with reference steps and parameter variations that span the full expected operating condition (grid strength, $V_{dc}$​ , $V_g$​, frequency drift, etc.). It is important to include the transients and not only the steady state.
• Use fixed scaling (per-unit or rated values). Try to analyze the data before training. Look for extreme outliers and remove them before scaling to avoid training dominated by rare events or spikes.
• Choose an input vector carefully that reflects control causality and avoid inputs that add noise without information.
• Increasing the number of fully connected layers and the number of neurons might increase the model’s performance, but it also increases the chances of overfitting.
• During training, try to monitor your validation loss. If it stops improving for a set number of epochs, training can be manually stopped to avoid overfitting the training set.
• If your loss isn’t moving at all, check your learning rate first. It’s usually either way too high, causing exploding gradients, or too low, making progress invisible.

Implementation of FNN-based controller

Experimental setup

The setup (see Fig. 5) used to validate the proposed ANN-based control of the output current of the converter includes the following imperix products:

• TPI8032, 22kW all-in-one programmable inverter
• ACG SDK toolbox for automated generation of the controller code from Simulink

and additional components :

• 1x DC power supply
• Three-phase grid connection or three-phase power amplifier

Downloads

The full Simulink model, as shown in Fig. 6, with a trained neural network whose parameters are saved as nn_parameters.mat, is available for download using the link below:

Experimental results

To experimentally validate the performance of the FNN-based controller, it is implemented side-by-side with the vector current controller in the Simulink model, as shown in Fig. 7.

The experimental performance of the TPI8032 was evaluated at a switching and control frequency of 20 kHz with a line-to-neutral grid voltage of 230 V at the point of common coupling (PCC). To assess control robustness, a dynamic test scenario was configured in which the DC link voltage is programmed to drop from approximately 700 V to 600 V, right after the application of a step-input of 30A in the d-axis current reference. This DC link voltage drop, therefore, coincides with a step change in the d-axis output current reference ($I_{g,d}^{\ast }$​) from 0 A to 30 A at t =5ms.

As illustrated in the results shown in Fig. 8, the FNN-based controller demonstrates a tracking performance similar to a PI controller. Despite the varying DC link voltage, a dynamic condition that was notably excluded from the training dataset, the FNN response (blue trace) closely tracks the reference and exhibits a transient response that nearly replicates the conventional PI-based vector current control scheme (dashed orange trace). This confirms that the FNN has successfully generalized its learning to respond to unseen operating conditions. Furthermore, the implementation proves to be computationally efficient; the execution of the FNN algorithm on the B-Board PRO embedded platform of TPI8032 consumes between 35% and 45% of the available cycle time at 20 kHz, ensuring the computational load remains well within the CPU’s capacity limits.

Conclusion

The example implementation demonstrates that a shallow ANN can effectively emulate the mapping of a discrete PI current controller in a grid-following converter while maintaining the deterministic, low-latency execution required for a real-time embedded target. However, the success of the approach is strictly dependent on the quality and breadth of the training dataset. While the ANN-based controller showed an ability to generalize to conditions like varying DC-link voltages not explicitly included in training, insufficient data coverage or limited training time remains a primary factor that can lead to subpar performance during unexpected transients. Rigorous cross-validation and the implementation of auxiliary safety mechanisms are essential to mitigate the risk of instability. Contrary to the assumption that ANN requires heavy computing power, this implementation proves that shallow ANNs can be effective and sufficient for power electronics control applications.

References

[1] M. R. G. Meireles, P. E. M. Almeida and M. G. Simoes, “A comprehensive review for industrial applicability of artificial neural networks,” in IEEE Transactions on Industrial Electronics, vol. 50, no. 3, pp. 585-601, June 2003.

[2] S. Zhao, F. Blaabjerg and H. Wang, “An Overview of Artificial Intelligence Applications for Power Electronics,” in IEEE Transactions on Power Electronics, April 2021.

[3] B. K. Bose, “Neural Network Applications in Power Electronics and Motor Drives—An Introduction and Perspective,” in IEEE Transactions on Industrial Electronics, Feb. 2007.

[4] S. Brunton, and J. Nathan Kutz, “Data-driven science and engineering: Machine learning, dynamical systems, and control“, Cambridge University Press, 2022.

To go further from here…

More information on the control of TPI8032 as a grid-forming inverter can be found in TN167. The following are some of the other notes that can be useful:

PN190: Getting started with th TPI8032
TN166: Active front end (AFE)

The post ANN-based control of a three-phase inverter appeared first on imperix.

The following sections provide an overview on how to configure both types of settings on different imperix controllers.

Hardware configuration

Hardware settings vary by controller model. Configuration is performed via the front-panel interface (screen and button) or Cockpit, depending on device compatibility. The table below summarizes the possible analog I/O hardware configuration methods and provides references for each controller.

A detailed comparison of imperix controllers, highlighting their hardware differences, is available in the article about How to choose between imperix controllers.

Software configuration

Software settings are configured from the user code and are compatible across controllers, with minor hardware-specific variations. In Simulink and PLECS, these settings are configured using the ADC block (for B-Box/-Board controllers) or the TPI ADC block (for the TPI8032). The main software settings are described below.

Addressing

• The Device ID defines which device is addressed when a multi-device configuration is implemented. With a single controller, the default ID must be used, which is 0.
• The Channel number (B-Box/-Board only) selects from which physical input data is read. The vector notation (e.g. [0:2]) can be used if multiple channels are desired to be configured identically.
• The Measurement (TPI8032 only) offer the same selection mechanism, but as a function of the measured variable. The sensor type is also set automatically. The hardware resources mapping is given in SD200.

Sensor specifications

• A list of imperix Sensors is provided to facilitate the configuration. Chosing a sensor automatically sets the corresponding sensitivity. This information is used so that the raw ADC value – a 16 bits integer – is transformed into a meaningful floating-point quantity (e.g. 230.6V) before processing in the CPU. If necessary, an offset can also be indicated, and compensated for during the same conversion.
• On the TPI 8032, the sensor type is automatically selected once the Measurement is chosen.

Input full scale

• The Input full scale only applies to B-Box/-Board controllers. Two options can be selected: Maximum (device-dependent) and Programmable (B-Box RCP 3.0 only). The device-dependent setting automatically accounts for the controller model. If the Programmable setting is selected for the B-Box RCP 3.0, the same gain must also be manually configured at the hardware level using the front panel (see PN105).

Sampling

All imperix controllers always sample across all channels and devices simultaneously. For this reason, the Sampling frequency and phase is a common setting located within the CONFIG block. On the other hand, filtering or down-sampling strategies are configured on a per-channel basis. The available options are:

• Synchronous averaging. This computes the average of multiple samples over one or two PWM periods. This technique is the default recommended strategy. It is available for all controller models.
• Low-pass filter (B-Box 3 and 4 only). This is a software parameter on the B-Box 4 (configured inside the model), but a hardware parameter on the B-Box 3 (configured using the front panel).
• Data history. This provides a vector containing the N most recent ADC samples. This generally makes most sense when used with a Postscaler between the effective sampling and CPU execution rates.

If none of the above options are selected, regular synchronous sampling is used.

Going further

Detailed information about the analog I/O configuration for each controller can be found in:

• Analog I/O configuration on B-Box 4
• Analog front-end configuration on B-Box RCP 3.0
• Analog inputs configuration on B-Box Micro
• Getting started with the TPI 8032

For the software settings, the next pages provide more information about the ADC and TPI ADC blocks:

• ADC block
• TPI ADC block

Finally, more information about the operating and programming principles of imperix controllers are provided in the next page:

• Programming and operating imperix controllers

The post Analog I/O configuration for imperix controllers appeared first on imperix.

Modules may also be housed within an open rack (type A). This configuration offers greater flexibility, allowing different types of modules to be mixed and easily swapped.

What is inside a closed rack?

A closed rack is a complete metallic enclosure designed to house six or eight power modules. It consists of:

• Six or eight slots equipped with plastic mounting rails to hold power modules
• An LCD screen displaying status information
• Integrated enclosure-level variable-speed cooling fans
• An auxiliary power supply for the power modules, screen, and fans

Two types of closed racks exist, which differ by their front-side openings as well as the number of terminals on their rear side.

The compatible products with the Type C racks are listed in the table below.

Type D racks are however exclusively designed to host PEN modules.

Auxiliary power supply

A dual-output power supply energizes the auxiliary circuits for all modules, as illustrated below. The +12V output is dedicated to the fan and gate drivers, while the +5V output powers all remaining components. For racks containing eight modules, two additional connectors are included.

Closed racks were originally equipped with a Delta Electronics PMT-D1V100W1AA power supply. In early 2026, this was upgraded to a Mean Well ADS-15512 to accommodate the higher power requirements of the PEB-800-40 modules. The specifications of both models are summarized in the following table:

The AC inlet includes two 2A / 250V ceramic fuses (Bel 5HT 2-R) in a tray, as shown below. The left fuse is connected in series with the AC input to protect the auxiliary power supply, while the right fuse is a spare unit.

Wiring the power modules

Type C racks

Wiring is required on both the power and control sides. For that, the following connections are provided:

• The switching node (AC)
• The positive (DC+) and negative (DC-) DC bus terminals
• Two analog outputs for the on-board sensors I_AC and V_DC (RJ-45 sockets)
• Two optical inputs for the high (H) and low (L) PWM gating signals
• An optical fault output

The integrated sensors do not utilize the Ethernet protocol for data transmission; rather, RJ-45 cables are capable of conveying analog signals due to their shielding and twisted-pair construction. A dedicated ±15V external supply is required for each onboard sensor, delivered through the RJ-45 cable. B-Box controllers provide this voltage. However, third-party controllers may necessitate an independent power source.

Gating signals are sent through standard 650 nm Plastic Optical Fibers (POF) or Plastic Clad Silica (PCS) fibers. No special coding is required: light ‘ON’ applies a positive voltage on the gate; light ‘OFF’ applies a negative one. Similarly, the optical fault output is in the light ‘OFF’ state to indicate a fault condition. This signal can be retrieved by B-Box controllers using an optical expansion board.

Type D racks

Type D racks provide a slightly different connectivity:

• The DC-bus midpoint terminal is also available (N).
• Four optical inputs for the PWM gating signals are available instead of two.

PEN modules use a single RJ45 connector to output the voltage of either the upper or lower DC half-bus, selectable via an internal jumper. Because this jumper cannot be accessed once installed in a closed rack, the modules are configured alternately from the leftmost slot to the rightmost slot, starting with the upper voltage. Further details on this jumper configuration can be found in the guide about open racks.

Status information and fault signaling

Modules are internally interconnected in a daisy-chain configuration via ribbon cables to enable global fault propagation and centralized fault clearance. This communication bus also transmits real-time status information to the LCD screen, informing the user about fan speeds, temperatures, and fault flags.

Booting and normal operation

When a closed rack is turned on, the LCD displays a booting message for 1 second:

After the boot, the screen displays the following information:

• The temperature inside the rack [°C]
• The highest fan speed of the three enclosure fans [rpm]
• The highest temperature among all the power modules [°C]
• The highest fan speed of all the power modules [rpm]

As long as there are no faults, the screen is refreshed every second.

Behavior under fault

Each module can generate any of the following local faults, immediately blocking the gating signals:

Detailed fault diagnostics are available on the LCD screen, and error messages will cycle continuously until the fault condition is resolved:

• A first message indicating the source of the fault. The possible sources are:
  • “POWER MODULE FAULT” if the fault comes from one of the modules,
  • “RACK COOLING ERROR” if there is an issue with the enclosure fans or internal temperature probes.

• Subsequently, the system displays a sequence of six or eight status messages (one per module) to identify local faults. If a fault is detected, the specific error type is reported. If the module is functioning correctly, the display provides real-time operating temperature and fan speed metrics.

• The last message displays the highest temperatures and fan speeds, as during normal operation:

The modules’ logic generates a fault flag, which is made available via an optical output (see below) and propagated to the other modules. The fault can be cleared by pressing the dedicated button located below the screen. Clearance is only successful if the underlying fault condition is no longer present.

Going further with the closed rack…

A fully functional converter requires a controller, such as the B-Box 4, in addition to power modules. The following articles provide guidance to build a complete converter within a closed rack.

• B-Box 4 – Quick start guide (PN254)
• PEB-800-40 – Quick start guide (PN210)
• How to build a three-phase converter (PN170)
• Neutral Point Clamped Inverter (NPC) (TN135)

The post Closed rack – Quick start guide appeared first on imperix.

Modules may also be housed in a closed rack (Type C or D), offering enhanced safety and facilitating tool-free manupulation thanks to banana connectors.

What is inside an open rack?

An open rack is a metallic frame that can hold up to eight imperix power modules. It consists of:

• Eight sets of plastic mounting rails to slide power modules into.
• An auxiliary power supply that delivers +12V/5V to the modules.

Each slot is fully independent, though all share a common auxiliary power supply. Consequently, users may populate any slot and combine different types of power modules as required. Compatible Imperix products are listed in the table below.

Auxiliary power supply

Each of the eight modules utilizes a dual-output power supply for its auxiliary circuitry. The +12V output is dedicated to the fan and gate drivers, while the +5V output powers all remaining components.

The open rack utilizes a Delta Electronics PMT-D1V100W1AA power supply. This unit features a manual 115/230 VAC selector switch that must be configured to match the local grid voltage prior to operation.

In early 2026, the power supply was upgraded to the Mean Well ADS-15512 to support the increased power demands of PEB-800-40 modules. Unlike the previous model, this unit features a universal input range compatible with 115/230 VAC and does not require a manual selector switch.

The specifications of both models are summarized in the following table:

Inserting power modules into an open rack

PEB modules

All PEB modules share the same connectivity, as presented in the PEB-800-40 quick start guide:

• The switching node (AC)
• The DC bus positive (DC+), negative (DC-), and mid-point (N) terminals
• Two analog outputs for the on-board sensors I_AC and V_DC (RJ-45 sockets)
• Two optical inputs for the high (H) and low (L) PWM gating signals
• An optical fault output

The integrated sensors do not utilize the Ethernet protocol for data transmission. Instead, RJ-45 cables are capable of conveying analog signals due to their shielding and twisted-pair construction. A dedicated ±15V external supply is required for each onboard sensor, delivered through the RJ-45 cable. B-Box controllers provide this voltage. However, third-party controllers may necessitate an independent power source.

Gating signals are sent through standard 650 nm Plastic Optical Fibers (POF) or Plastic Clad Silica (PCS) fibers. No special coding is required: light ‘ON’ applies a positive voltage on the gate; light ‘OFF’ applies a negative one. Similarly, the optical fault output is in the light ‘OFF’ state to indicate a fault condition.

Due to restricted access following installation, the AC and N terminals must be wired prior to mounting the module inside the rack. Connections should be secured using an M4 screw. Using an anti-loosening washer, and a suitable ring terminal (e.g., RND 465-00635) is recommended.

The next step is to slide the module into the rails and connect the auxiliary power supply, as shown below. The connector is keyed to ensure correct orientation and prevent the reversal of the +12V and +5V supplies.

In case fault-related information must be shared accross the modules, flat ribbon cables (TE connectivity 2205065-2) can be used in a daisy-chain configuration. More information is given in the Fault signalling section below.

Finally, the DC bus terminals can be wired using either ring terminals or bus bars (sold separately).

PEN modules

The installation of PEN modules follows the same procedure as for PEB modules, except for the onboard voltage sensor configuration. PEN modules use two sensors to monitor either the upper or lower DC half-bus, depending on the position of two jumpers. As these jumpers are difficult to access once installed, the desired measurement output must be configured before sliding the module into the rack.

PEH modules

In contrast to PEB and PEN modules, PEH power terminals are mounted on the top side. Also, fault sharing using the flat cables is not available. The installation is therefore simplified as follows:

1. Slide PEH modules into the rack.
2. Connect the auxiliary power supply (+12V/+5V).
3. Wire the power stage using M4 fork terminals (e.g., Phoenix Contact 3240042).

Fault signaling

Six red LEDs located on the front side of the module (under the mezzanine board) indicate the origin of the fault, when applicable. The corresponding flags categorize the possible causes, as indicated in the table below.

When a fault occurs, the system remains in a fault state until manually cleared or the whole rack is power-cycled. The fault can be cleared by pressing the dedicated button located on the mezzanine. Clearance is only successful if the underlying fault condition is no longer present.

Fault sharing

The onboard logic generates a global fault flag, which can be fed back to the controller (if needed) via the optical output (see images above). This signal is inverted so that the absence of light signals a fault. When using B-Box controllers, this signal can be retrieved using an optical expansion board.

Faults can also be shared across PEB or PEN modules using daisy-chained flat cables (see assembly instructions above). This mechanism ensures that the global fault flag and clear signal propagate across all modules.

Coordinated tripping may be useful for faults that cannot be seen by the controller, such as cooling, desaturation, and power supply faults. However, for over-current or over-voltage faults, it is preferable not to rely on module-to-module fault sharing for the following reasons:

• The protections inside imperix controllers can be set to lower thresholds and offer faster response times.
• If an over-limit condition is detected by an imperix controller, the PWM signals are blocked even before the fault-sharing information is carried to all modules.
• Keeping the controller “blind” to power stage faults is generally not recommended, as the fault condition may require specific control actions.

Going further with the open rack…

A fully functional converter requires a controller, such as the B-Box 4, in addition to power modules. The following articles provide guidance to build a complete converter within an open rack.

• B-Box 4 – Quick start guide (PN254)
• PEB-800-40 – Quick start guide (PN210)
• How to build a buck converter (PN119)

The post Open rack – Quick start guide appeared first on imperix.

Introduction to HIL simulation

Hardware-in-the-loop (HIL) simulation is generally defined as a validation technique where a real physical controller interacts with a simulated plant instead of the actual physical plant. The controller is therefore the hardware inside the (control) loop involving an emulated system, the latter being often implemented using dedicated real-time simulation equipment. A HIL test bench typically consists of:

• Real-time simulator: executes the plant model, often with a fixed time step.
• Controller: runs the control algorithm on the real control hardware.
• I/O interface layer: connects the controller with the simulator.

This configuration is often referred to as controller-HIL (or C-HIL), because the controller is the device under test (DUT) inside the loop. Other configurations of “hardware inside the loop” are also possible, for instance involving an emulated controller connected to a real plant (opposite configuration), although this is usually not designated as a HIL setup. In the same line of ideas, the configurations that involve real power exchanges are rather designated as Power HIL (or PHIL) scenarios, so that they are clearly distinguished from those that only exchange signals or information. In this case, a power amplifier (or equivalent) is required between the simulator and the DUT.

HIL and PHIL simulation are widely used in domains such as power electronics, automotive, aerospace, microgrids, and power systems. Their typical benefits are to help accelerate development and improve safety, notably by shifting risky or hard-to-reproduce scenarios into a secure, controlled environment.

In a typical C-HIL configuration, illustrated in Fig. 1, the simulator computes the plant response in real-time and emulates the corresponding physical sensor signals (such as voltages and currents) that the controller would otherwise receive in an actual deployment. These signals are exchanged through a physical I/O interface, creating a closed loop. On the other side of the interface, the controller sees the simulator through the same analog and digital interfaces, “believing” that it is connected to the real system.

Offline vs. real-time simulation

In order to compute the plant response in real time, the simulator must be able to solve the corresponding differential equations within a pre-determined latency. For this reason, the model must be compatible and optimized for fixed-step execution. Iterative solvers are typically avoided. Additionally, the model fidelity must be chosen as a trade-off, so that the simulator can reliably finish computation before the next time step. Over-runs are generally considered as a real-time violation.

Due to the above constraints, discrepancies between offline and real-time simulation can often happen. Some typical situations are mentioned below:

• Offline simulation might be using a solver type and configuration (i.e., variable-step or fixed-step) that resolves switching and fast dynamics differently than the real-time solver being used by the simulator.
• Real-time simulation forces a compromise between time step and model complexity, which can result in changes in high-frequency behavior and transient performance.
• The controller generates PWM edges almost continuously in time, but the real-time simulator sees them through a discrete-time capture interface. If edges don’t align exactly with the real-time step, edge timing quantization happens, which significantly distorts the duty-cycle estimation, especially for high switching frequencies. All HIL vendors implement techniques to minimize this effect, with different pros and cons.

Imperix interfaces for HIL simulation hardware

Imperix offers different rapid control prototyping (RCP) controllers, power modules and sensors, enabling users to perform experimental validation of control algorithms. For HIL simulation scenarios, the B-Board PRO (e.g. mounted on its Eval-Board) can easily be interfaced with third-party HIL simulators using appropriate cables, such as a DB-37 pigtail cable. Conversely, for the family of B-Box controllers, imperix provides dedicated simulator interfaces that serve as a physical bridge between the controller and the simulator. These interfaces ensure electrical and signal-level compatibility for both analog and digital signals:

• Analog outputs of the simulator are converted to RJ45 connectivity for the B-Box controllers.
• Optical PWM signals from B-Box controllers are converted to electrical signals for the simulator.

Imperix currently provides the following simulator interfaces that allow the connection to the respective HIL simulation platforms:

• OPAL-RT Simulator Interface, refer to TN180 for further details on simulation with OPAL-RT simulators.
• Typhoon HIL Simulator Interface
• Plexim RT Box Simulator Interface
• Speedgoat Simulator Interface

Benefits and limitations of HIL simulation

In a typical development process, HIL simulation can serve as the bridge between simulation and hardware testing, as illustrated in Fig. 2. It is an optional step that can help validate controller algorithms early in the development process, typically when a hardware prototype is not yet available or when offline simulations are inconveniently long to execute.

HIL simulation is particularly useful when testing involves difficult or destructive scenarios that are unsafe, costly, or impractical to reproduce on physical prototypes (e.g., fault injection, AC grid disturbances, over-current events, etc). More generally, HIL simulation also brings increased realism compared to offline simulation by:

• Forcing the incorporation of real-world challenges such as measurement noise, quantization phenomena, discrete control execution, hardware-specific limitations (e.g. memory usage, stack overflows), etc. inside the simulation.
• Offering support for testing random interactions such as perturbations, communication exchanges, etc.

On the other hand, HIL simulation also possesses some inherent limitations, such as:

• Dynamics close to the discretization step size are difficult to model or cannot be modeled with sufficient accuracy. While this is obvious for very fast phenomena (e.g., semiconductor ringing), this often also applies to medium-frequency dynamics (e.g. DAB or LLC waveforms), at least without highly dedicated FPGA-based solvers (which generally offer only limited user flexibility or observability).
• Evaluating system efficiency is generally not feasible, because any efficiency results merely reflect the assumptions of the underlying models (rather than validating actual physical hardware losses).
• Phenomena related to the common-mode behavior of the system are generally ignored (due to the associated computational burden, incompatible with real-time execution), imposing limited visibility on the possible issues associated to filters, circulating and leakage currents, etc.
• More generally, any aspect that is not anticipated and, therefore, included in the simulation model cannot be faced or tested. This prevents HIL simulation from being able to expose unforeseen challenges or problems.

In light of the above, the value of HIL simulation lies not so much in improving the plant model fidelity, but rather in offering what offline simulation lacks, i.e.:

• Testing opportunity for the real control hardware along with the embedded software or firmware.
• Offering support for faster simulations with faster iteration cycles, as they run in real-time on dedicated hardware.

In practice, HIL simulation is generally cost-effective when it prevents expensive prototype iterations by catching integration- and control-related issues early, while prototyping is attractive and necessary when the dominant risks are related to the power stage, or involve efficiency- and EMC-related concerns.

C-HIL simulation example

This example uses the imperix B-Board PRO and Plexim’s RT Box 2. The real-time simulation of a DC-DC buck converter is used to demonstrate the workflow using PLECS. TN100 outlines the implemented output voltage control and is used as a reference. The simulation model is built using the imperix Power library.

In this example, a single PLECS model is used to generate C++ code for both the control side and the plant side, which are subsequently deployed to the  B-Board PRO and Plexim RT Box, respectively. Specific settings may differ for other real-time simulators, but the underlying concepts remain the same. The following articles address the corresponding steps and are recommended for further reading:

• PN134 for getting started with imperix ACG SDK
• PN137 for understanding simulation essentials with PLECS
• PN151 for other PLECS examples with different plants available for download
• AN006 for a similar implementation of HIL simulation using the B-Box RCP 3.0 and Plexim’s RT Box 2

Downloads

A PLECS model containing the closed-loop output current control of the DC-DC buck converter is provided. The imperix power library requires ACG SDK 2024.2 or a later version.

Experimental setup

The experimental setup is shown in the Fig. 3. An exploded DB-37 cable is used to connect the B-Board PRO development kit with the front side of the RT Box. While in this note, this specific setup is featured, other imperix controllers can also be utilized in conjunction with their corresponding simulator interfaces.

Hardware and software requirements

The following list includes imperix products, plus additional components required for this example:

• Imperix products
  • 1x B-Board PRO development kit
  • Imperix Control development tools for Simulink and PLECS (ACG SDK) that includes Cockpit
• Additional software
  • PLECS standalone with PLECS coder
• Additional hardware
  • Plexim RT Box (can be any variant)
  • 2x exploded DB-37 cable
  • 1x DB-37 gender changer
  • 12V DC adapter for powering the B-Board PRO

Setting up HIL simulation

The setup of HIL simulation involves several steps. A similar procedure can be followed for setting up a HIL simulation with any other control implementation or plant model.

Model implementation

A buck converter example is built in PLECS using the default template file provided by imperix. The controller and the plant are modelled in seperate subsystem as shown in Fig. 4.

PLECS model preparation and settings

Effective data exchange between the RT Box and the B-Board PRO relies on several key blocks from the PLECS RT Box library (italicized below) and the imperix library (in bold red below). Below are the critical considerations for their implementation:

• PWM capture blocks must be used for receiving the PWM signals (as opposed to regular digital input blocks) so that sub-cycle averaging is possible. The offline behavior in the PWM capture block should be selected as sub-cycle average to properly mimic the real-time behavior. Nanostep is only compatible with Nanostep-compatible models from the PLECS library.
• As the model will be deployed in the RT Box, the subsystem containing the plant side must be enabled for code generation. For that, right-click on the plant subsystem and select subsystem–> execution. Then check “enable code generation”, as shown in Fig. 9.
• Analog output blocks on the RT Box should be used to provide the plant measurements to the imperix ADC blocks. To reflect the physical scaling of the real-world hardware, it is recommended to scale these signals according to the actual sensor sensitivity by probing its “Sensor output [V]” signal (see Fig. 5). On the controller side, the ADC must be configured with the corresponding sensor parameters (Fig. 6) to ensure the scaling matches. This configuration can be validated during offline simulation by enabling the “Simulate sensor sensitivity” option within the ADC block settings.
• The recommended settings for the CB-PWM block are shown in Fig. 7. As both PWM signals are generated and transmitted to the simulator, reverse conduction is implemented in the lower MOSFET.

The following are some optional interfaces included for the sake of completeness. They can be used, for example, when control logic or relaying is required:

• Digital In can be used for general-purpose output signals (GPO) coming from the B-Board PRO.
• General-purpose input signals (GPI) from the B-Board can be connected to the Digital Out of the RT Box.
• DAC channels can be used to output analog signals from the B-Board PRO. The imperix DAC block and the corresponding Analog In of the RT Box library can be used.

Wiring of the B-Board and RT Box

The system is wired as follows, which is illustrated in Fig. 9:

• The PWM outputs of the B-Board PRO are wired to the RT Box digital inputs. An exploded DB-37 cable can be used to wire them together as shown in Fig. 3.
• The analog outputs of the RT Box are wired to the analog inputs of the B-Board PRO.

Deployment of the plant model

The step-by-step procedure to compile and load the plant model on the RT Box is as follows:

• If not already, code generation must be enabled for the subsystem containing the plant side. Right-click on the plant subsystem and select subsystem–> execution. Then check “enable code generation”, as shown in Fig. 8.
• In the PLECS environment, go to Coder→ Coder options. Select “plant” in the left area (under the model file name).
• The “General” tab can keep the default settings.
• In the “Target” tab:
  • Select the RT Box variant being used. In this example, PLECS RT Box 2 is selected.
  • Select the analog output voltage range to “-5V … 5V” as B-Board PRO’s input voltage range is ±5V.
  • Select HIL for the simulation mode. All the settings for the “Target” tab are shown in Fig. 10.
• In the “External mode” tab of the coder options menu:
  • Select the target device by entering the hostname or IP address. Other settings are shown in Fig. 11.
  • Click “Build” to generate and upload the code directly to the RT Box.
  • When everything is rightly done, a blue LED next to “Running” on the front interface of RT Box 1 will light up. For other RT Box variants (e.g., RT Box 2 used here), the LCD will display the name of the subsystem being simulated in addition to the current CPU cores’ processing time.

Deployment of the control implementation

The following steps outline how to compile and load the control algorithms onto the B-Board PRO. More information on how to program and operate imperix controllers is provided in PN138:

• The subsystem containing the control side must also be enabled for code generation. Right-click on the controller subsystem and select subsystem–> execution. Then check “enable code generation”, as shown in Fig. 8.
• Open Coder → Coder Options, then choose “imperix controller” from the panel on the left (under the model name).
• The “General” tab can keep the default settings.
• Go to the “Target” tab and select “Imperix Gen 3 Controller”. In case B-Box 4 is used, then “Imperix Gen 4 Controller” should be selected.
• Go to the ” Scheduling” tab:
  • Select “single-tasking” under Tasking mode
  • The discretization step size must be set equal to the control time period, as shown in Fig. 12.
• Click “Build”. Imperix Cockpit should open up automatically.

Testing and validation

The results of offline simulation in PLECS as well as HIL simulation are captured and presented in Fig. 13. In this example, the switching frequency of the buck converter is set to 10kHz. With a fixed discrete time step of 2µs, the RT Box executes the model at 500 kHz (f_s), which is sufficient to resolve dynamics around the buck’s switching frequency. However, it cannot represent any dynamics above the Nyquist limit of 250 kHz. In practice, the usable frequency range is typically much lower, in the order of 50 kHz (≈ f_s/10). As a result, phenomena faster than this are not captured realistically.

The following can be observed:

• By keeping the electrical and control parameters identical in both offline and HIL simulations, and by accurately modeling delays in the offline model, both results show an essentially identical response to a step change in the output current reference. The offline and real-time HIL waveforms align closely, as also seen in the zoomed settling-time view.
• The reference step is applied at 10ms and, as expected, the controller response is visible at the next interrupt execution (i.e., after 100µs). This behavior is consistent for both offline and HIL simulations, as shown in Fig. 14. Sampling, actuation, and response timing are all observed to be coherent.

If the model is complex and overruns occur during real-time deployment, iterative adjustments to plant fidelity and time steps may be necessary to balance real-time constraints with test objectives.

Getting-started recommendations

Conclusion

The workflow utilizing the imperix B-Board PRO and Plexim’s RT Box demonstrates seamless compatibility between the controller and the real-time simulator. Comparative results reveal equivalent delays and dynamic responses across both offline and HIL simulation environments, confirming the correct interaction between the devices.

These findings suggest that HIL simulation can be an attractive alternative to offline simulation, offering increased realism, when the perspective is set on the control hardware testing. In such a case, the ability to conduct testing early along the development cycle provides benefits that outweigh the limited accuracy of the model (such as a restricted frequency range or disregarded common-mode behavior). That said, more generally, HIL shall rather be seen as a complement than a replacement to offline simulation. Notably, HIL should not be considered blindly as a method for achieving higher modelling accuracy, which it isn’t.

When opposed to experimental prototyping, HIL simulation is an excellent framework for executing tests that are either hazardous or difficult to replicate in a laboratory setting. It is also often faster and less cumbersome than physical testing. However, thermal and EMI-related phenomena typically remain outside the scope of current HIL capabilities. Additionally, the cost-effectiveness of HIL versus full-scale prototyping remains a subject for further debate.

To go further from here…

The next step could be to implement the buck converter physically and test the controller’s performance. Refer to PN119 to understand how to build a buck converter from scratch using imperix half-bridge modules and sensors. The following resources can also be helpful:

• TN100: Step-down buck converter
• TN180: C-HIL simulation scenario with OPAL-RT simulators
• TN122: Interleaved buck converter current control
• TN102: Buck-boost converter
• PN151: Basic examples for ACG SDK on PLECS

The post HIL simulation using a B-Board PRO appeared first on imperix.

B-Board PRO: The Embedded Control Platform

The B-Board PRO functions as the embedded controller for the converter system, enabling implementation of control algorithms in C/C++ or model‑based development via Simulink and PLECS. Typical applications for which B-Board PRO is optimized include industrial inverters and rectifiers, motor drives, multi-level inverters, and distributed control systems. Its high‑performance computational resources support control loop frequencies up to 200 kHz while preserving full firmware flexibility. The PWM outputs of the B-Board PRO have a resolution of 4 ns, which provides precision in controlling gate drivers. In addition, the imperix ACG SDK toolchain and the board’s firmware building blocks simplify implementation and reduce development time. This is achieved through features such as preconfigured PWM-modulation blocks, synchronous averaging, sampling aligned to the PWM carrier, fault management, and built‑in dead‑time handling. Pre-deployment verification can be performed in simulation and, if required, via hardware‑in‑the‑loop (HIL) testing before deploying the solution on the target power hardware.

Overall, B-Board PRO shortens the development cycle from initial design to experimental validation and, therefore, is an ideal choice as an embedded controller.

SINAMICS S120 Active Line Module

The SINAMICS S120 active line module from Siemens is a 16 kVA, three-phase, two-level, bidirectional converter, supplied in the booksize form factor. It is designed to operate as a regulated active front end, supporting both infeed operation (AC-to-DC) and regenerative feedback (DC-to-AC). For the customized variant used in this technical note, the power stage is driven by six gate signals (two per phase leg), which are available for external control. For feedback, the module provides four internal measurement channels. The main system specifications of the S120 are summarized in Table 1.

Interfacing B-Board PRO with SINAMICS S120

A customized carrier board was designed to interface the SINAMICS S120 converter with the B-Board PRO. This design leverages the principles detailed in PN201: Custom carrier board design for B-Board PRO. All control, protection, and digital measurement signals are routed between the converter and the B-Board PRO via the custom carrier board.

Custom carrier board design

The interface connector of SINAMICS S120 exposes a set of control-related signals, including six PWM gate-driver signals, four measurement signals, precharge relay/ fan control, and temperature feedback for power-module monitoring. These signals are routed to the B-Board PRO through a connector on the integrated carrier board. An overview of the signals available on the box connector is provided in Table 2. The hardware setup is shown in Figure 1, where the B-Board PRO is mounted on a custom carrier board and assembled with SINAMICS S120.

The assembled custom carrier board is shown in Figure 2. The following are the important interfaces on the carrier board:

• S120 interface (Yellow): A box connector connects directly to the modified S120 control port (signals are detailed in Table 2).
• External sensor interface (Green): RJ-45 connectors are routed to the eight ADC channels on the B-Board PRO. These sensor interfaces provide ±15V power to external imperix voltage/current sensors and route the analog signals back to the ADC.
• Power supply (Purple): The board requires a 12V input for the B-Board PRO and an external ±15V supply for the external imperix sensors.
• Mounting (Red): The B-Board PRO mounts on top of the carrier board via two high-speed 180-pin connectors (JX1 & JX2) and a 60-pin connector (JX3). For more information, please refer to the B-Board PRO datasheet.

Customized FPGA firmware design

The SINAMICS S120 system measures electrical quantities using delta-sigma (ΔΣ) ADCs. In this approach, each analog signal is processed by a ΔΣ modulator that generates a high-frequency 1-bit data stream. The measurement principle is based on oversampling and noise shaping, which shifts quantization noise to higher frequencies so that the low-frequency signal of interest can be recovered using a digital decimation filter, typically implemented as a sinc or cascaded integrator-comb (CIC) filter. Four embedded ΔΣ ADC modulators are used to measure the three output phase currents and the DC-link voltage. Further details on the operation of the delta-sigma modulator can be found here.

To make these ΔΣ measurements usable for control loops and protection functions, dedicated processing logic is implemented on the FPGA of the B-Board PRO. This platform is well suited for the application because its USR pins support data rates of up to 400 Mbps, enabling reliable acquisition and real-time decoding of the ΔΣ bitstreams with low latency, which is essential for fast hardware-based protection.

Delta-sigma decoding and data paths

The bitstreams of ΔΣ ADC measurements must be continuously filtered and decimated to a well-defined update rate synchronized to the PWM carrier. Because this requires processing tens of megabits per second across four ADC channels, too fast to handle directly on the CPU, the B‑Board PRO implements dedicated FPGA logic to perform the ΔΣ decoding and deliver time-aligned digital samples to the CPU, while also providing a deterministic data path and low-latency protection path independent of CPU execution time.

Each measured quantity from the S120 is transmitted as a pair of digital signals: a clock and a single-bit data stream. Four asynchronous delta-sigma decoder instances were integrated into the imperix FPGA firmware sandbox area using the Xilinx Vivado. The complete overview of the customized design is shown in Figure 3. Each decoder captures the data bitstream and performs digital filtering and decimation to generate scaled measurement samples. The decimated values are streamed to the CPU for control, while a parallel low-latency filter path exposes flag signals to the FLT for protection against faults. TN149 details the design and implementation of an FPGA-based decoder for a delta-sigma modulator. Each channel includes:

• A delta-sigma decoder based on cascaded sinc filters.
• A decimation stage that converts the high-rate bitstream into lower-rate sampled data.

More information on how the FPGA of the B-Board PRO can be customized for different applications is provided in PN169.

Protection logic

To satisfy both control accuracy and fast fault reaction time, the FPGA logic processes the measurements through two parallel paths:

• High-Precision path (control): optimized for accuracy with moderate latency. This path has stronger filtering/decimation for control and monitoring.
• Low-Latency path (protection): optimized for minimum delay to support fast shutdown. This path has minimal filtering to detect threshold violations and trigger a rapid shutdown independent of CPU execution time.

Thresholds for overcurrent, overvoltage, and overtemperature are configurable at runtime via the imperix CPU↔FPGA data exchange interface (SBO for CPU→FPGA and SBI for FPGA→CPU). This allows protection limit adjustment from imperix Cockpit without FPGA recompilation. When a threshold is exceeded, the low-latecy path triggers the imperix fault management logic, which disables PWM and forces the outputs into a defined safe FAULT state.

Control of the grid-following converter

In this application example, the SINAMICS S120 is operated as a grid-following voltage source converter connected to a stiff distribution grid. Detailed analysis of the operation and control of a grid-following converter is provided in TN167. In this mode, the converter relies on the grid to set voltage and frequency and regulates only the exchange of active and reactive power. Synchronization with the grid voltage is achieved by estimating its phase and frequency, using a synchronous reference frame PLL. Therefore, the grid-following converter acts as a controlled current source. In this implementation, active and reactive power flow is directly controlled by the current references: \(i_\mathrm{g,d}\) (\(i_\mathrm{g,d} \propto P\)) and \(i_\mathrm{g,q}\) (\(i_\mathrm{g,q} \propto Q\)), using the vector current control in the dq reference domain.

As shown in Figure 4, the design of the current controller requires a total of seven measurement signals. Additionally, the SINAMICS S120 features precharge resistors that enable the safe charging of DC link capacitors during startup, thereby limiting inrush currents. The DC link precharge relay is used to bypass the precharge resistors. Further details on DC link precharging principles and implementation are provided in TN131.

Software Implementation

The control algorithm for the control of SINAMICS S120 as a grid-following converter has been designed, simulated, and tested using MATLAB Simulink and imperix ACG SDK, as shown in Figure 5. The SINAMICS S120, the LC filter, and the grid were modelled in Simulink using blocks from Simscape for offline simulation and verification of the controller’s operation. The code was generated automatically using imperix ACG SDK toolchain. In this note, a PWM enabling mechanism and a protection mechanism have also been implemented.

PWM enabling mechanism

The software verifies the following conditions before enabling PWM signals:

1. The precharge resistor for DC link precharging has been bypassed.
2. Three-phase voltage levels at PCC exceed the minimum grid voltage​ to verify the presence of grid, \(V_\mathrm{g,min}\) , set by the user. \(V_\mathrm{g,min}\) can be selected as 20% of the nominal grid phase voltage.
3. The grid angular frequency lies within the permissible range, \([\omega_\mathrm{min},\omega_\mathrm{max}]\). The typical values for \([\omega_\mathrm{min},\omega_\mathrm{max}]\) can be set as ±5% of the nominal grid angular frequency.

If any of these conditions is not satisfied, PWM remains blocked, and the state machine transitions to the BLOCKED state.

Two-layer protection mechanism

The designed converter system employs a two-layer protection mechanism to ensure safe operation under fault conditions. When a fault condition is detected, regardless of CPU activity, the following happens:

• PWM outputs are immediately disabled at the hardware level.
• The system is forced into a safe FAULT state.
• A corresponding fault signal is asserted.

1- Software protection

The first protection layer is implemented in software and operates at the CPU control frequency. It is realized in the C-code automatically generated from Simulink (see Figure 6). If any of the following parameters: DC link voltage, the three output phase voltages, and the three output phase currents of the S120 converter, violate the user-defined limits, the software triggers a “User Fault,” transitioning the state machine to FAULT state and blocking PWM. This protects against steady-state violations or slow thermal drifts.

2- FPGA protection

The second protection layer is implemented directly in the FPGA firmware, enabling faster fault detection and reaction independent of the control software or CPU. It provides critical protection against short circuits or high di/dt overcurrents. It utilizes the low-latency data path described in Section 4. If the delta-sigma decoder output exceeds the hardware threshold, the imperix fault logic disables the PWM signals within microseconds. Activation of this hardware protection is configured via FLT block in the control software, as shown in Figure 7, while the fault detection and reaction itself remain fully hardware-based.

Experimental Results

The experimental setup is shown in Figure 8, which consists of two SINAMICS S120 converters tied to a common DC link, effectively doubling the DC link capacitance. Each converter connects to the PCC through an LC filter, which is schematically represented in Figure 9. The experiments validate correct synchronization, current control performance, and parallel operation capability (e.g., master-master or master-slave ) via imperix RealSync.

In this case, both converters used the same grid-following current controller design and gains, configured as a master–slave system, with the two B-Board PROs interconnected via a high-speed SFP link. This link synchronizes the PWM time bases, ensuring simultaneous switching events with a 4 ns PWM timing resolution, which is essential for avoiding circulating currents and achieving stable current sharing when operating converters in parallel.

In this configuration, the DC voltage is supplied by an external DC source of \(750 V\), and the switching frequency is set to 8 kHz. The controller is tuned for a fast dynamic response. The measured results for converters #1 and #2 (Figure 10 and Figure 11) confirm stable operation: the three-phase grid currents are well balanced without any sudden jumps, and the d-axis and q-axis currents closely follow their references, exhibiting comparable dynamics on both converters. A dedicated Cockpit GUI was developed for coordinated operation and monitoring of both converters, as shown in Figure 12.

General tips for B-Board PRO interfacing

When interfacing the B-Board PRO with third-party power converters or power modules, careful attention must be paid to signal compatibility, protection integration, and timing requirements.

• Logic-level compatibility of PWM, enable, and fault signals should be verified, and appropriate level shifting or signal conditioning must be added on the carrier board if required.
• The B-Board PRO outputs PWM signals assuming active-high logic (a high level turns on the semiconductor). It is therefore essential to confirm whether the target gate driver or power module expects active-high or active-low PWM inputs. External pull-ups or pull-downs may be required on some pins to enforce a known default condition before the PWM becomes active.
• Fast protection signals from the power module, such as overcurrent, should be routed directly to the imperix firmware IP fault inputs inside the FPGA design to ensure fast shutdown independent of CPU execution.
• ADC input channels of B-Board PRO must be adapted to the analog sensor output, with particular care taken to match the voltage range, bandwidth, and isolation requirements of current and voltage feedback signals.
• Thermal and voltage/power derating limits should be enforced at the control level. Even if the power module includes internal protection, implementing software-level limits improves robustness.
• Proper grounding and isolation should be ensured to avoid noise coupling and ensure reliable operation when the B-Board PRO is integrated with the converter hardware.

Conclusion

This technical note demonstrates the utility of using imperix B-Board PRO embedded control platform with an industrial-grade SINAMICS S120 converter. Any industrial or reference design converter can be interfaced with B-Board PRO if access to the gate signals, fault signals, and embedded sensors is provided through an interface. It has been shown that:

It can be concluded that using imperix ACG SDK with model-based workflows (Simulink/PLECS) significantly shortens the path from controller design concept to real-time implementation and experiments on hardware.

Acknowledgements

The author would like to thank the Institute of Power Electronics and Control of Drives (LEA) at the Technical University of Darmstadt, Siemens AG, and imperix for their continued support throughout the successful completion of this project. This work was funded by the German Federal Ministry of Education and Research (BMBF).

To go further from here:

Please check out PN205 for the detailed custom design of the carrier board for hosting B-Board PRO. Furthermore, the following resources might also be interesting for the control of grid-connected converters:

TN167: Grid-following Converter
TN168: Grid-forming Converter
TN166: Active Front End (AFE)

The post Control of a SINAMICS S120 using a B-Board PRO appeared first on imperix.

For new users, it is recommended to read the following articles beforehand to get started with the imperix software development kits (SDKs) and the Cockpit monitoring software:

• Programming and operating imperix controllers
• Cockpit – User guide

XY Plot basics

The XY plot module allows for visualizing the relationship between two variables by plotting one against the other in a two-dimensional plane. This is particularly useful for analysing current trajectories in motor control, Maximum Power Point Tracking (MPPT) characteristics, or phase-current relationships in multilevel converters.

The sampling frequency of the XY plot can range from 10Hz up to the CPU control task frequency. The maximal amount of the recorded data depends on this value and the number of acquired variables. Once the allocated memory buffer fills up, the oldest acquired points are automatically disregarded.

XY Plot interface

XY Plot tips and tricks

• To add a curve to the XY plot, open the user variable section of the project pane. Variables can be added one by one: the first variable will create a new curve and be assigned as the X value, and the second variable will complete the curve by being assigned as the Y value. Alternatively, multiple variables can be added at once by holding Ctrl while clicking to select individual variables, or by holding Shift to select a range of variables. The first selected variable becomes X and the second becomes Y. If more than two variables are selected, multiple curves will be created following the same logic (3rd and 4th variables create a second curve, etc.). The bottom bar can also be used to change the X and Y axis variables directly for each curve.
• To inspect specific data points, pause or stop the acquisition and move the cursor along the time axis in the X or Y time plots. A marker on the XY plot will follow, indicating the corresponding position on the curve.
• To zoom in and out, place the mouse cursor where to zoom. Then, use the mouse wheel to zoom in or out around the mouse cursor. Both axes are zoomed simultaneously.
• To zoom on a specific area, click and drag to draw a blue rectangle over the zoom area. When Keep aspect ratio is enabled, the zoom may not perfectly match the selected area, but will approximate it as closely as possible while maintaining the configured ratio.
• To achieve a horizontal autoscale, right-click and drag horizontally. A light grey horizontal strip will appear. Release the mouse button to perform the horizontal autoscale.
• To achieve a vertical autoscale, right-click and drag vertically. A light grey vertical strip will appear. Release the mouse button to perform the vertical autoscale.
• Many of the XY plot functionalities can also be accessed through context menus by right-clicking on a plotted curve or on the empty space in the plots.

XY Plot application examples

The following examples illustrate typical use cases of the XY Plot module:

• Stator current trajectory during a motor homing sequence. The pattern shows the current vector as the rotor position is aligned by the control. Further details are provided in Field-Oriented Control of PMSM.

• Power-voltage (P-V) characteristic of a photovoltaic string. The curve shows the MPPT algorithm reaching the maximum power point. Further details are provided in Maximum Power Point Tracking (MPPT).

• Current trajectory of an MMC inverter with low fundamental frequency and harmonic current injection. The X and Y time plots show the evolution of the αβ-axis circulating currents.

The post XY Plot Module appeared first on imperix.

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.

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.

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

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.

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

The post Aurora link with OPAL-RT via SFP appeared first on imperix.

This level of access enables a wide range of applications, including direct control of the controller transceivers and the implementation of Aurora communication over the physical SFP ports. Such flexibility makes it well suited to accommodate the diverse Aurora configurations used by major simulator vendors, such as OPAL-RT, Plexim and RTDS.

This page explains how to set up this communication by combining a user application running on the CPU with additional logic in the FPGA bitstream. For a quick and straightforward integration, a ready-to-use user application template is provided, along with generation scripts to easily generate the bitstreams for several vendors.

SFP, Aurora and imperix

With three Small Form-factor Pluggable (SFP) ports, the imperix controllers are naturally built for multi-device topologies, such as wide multi-master and master-slave RealSync networks.

To fully leverage these high-speed SFP connections, the Aurora protocol from Xilinx provides a lightweight, high-throughput protocol. By using native transceivers with minimal overhead, Aurora delivers low latency and near line-rate performance without the complexity of protocols like Ethernet, making it an efficient and practical choice for high-bandwidth, point-to-point links.

Although simple, Aurora requires identical configurations at both ends of the link. This usually makes interoperability between devices from different vendors challenging.

Through the sandbox, its FPGA development environment, imperix provides unrestricted access to the SFP ports of its controllers. This allows to instantiate a configurable Aurora IP and implement the required logic to match the configuration and frame structure of any third-party manufacturer.

For a quick start, synthesis-ready Vivado projects are provided for several vendors such as Plexim, OPAL-RT and RTDS. These projects implement the FPGA logic depicted in the next section, including an Aurora IP with the same configuration as the targeted third-party simulator, a driver to encode and decode the Aurora frames, and SBI/SBO registers to exchange data with the user application running in the CPU.

Setup overview

The setup considered to exchange data with a third-party device is depicted below. It is composed of three main parts: the user application, the FPGA bitstream and the third-party application.

The user application is running in the CPU of the imperix controller and contains the code designed by the user, typically a control algorithm. This application has no special requirements, except that it contains SBO blocks to send data to the driver and SBI blocks to access incoming data from the SFP connection.

The FPGA bitstream defines the logic executed on the imperix controller’s FPGA. Together with the controller firmware, it implements the functionality required for Aurora communication. The core components of this communication are the driver, FIFOs and the Xilinx Aurora IP:

• The driver receives the outgoing data from the user application through the SBO blocks, packages it into frames compatible with the third-party simulator and transfers the frames to the Aurora IP. In parallel, it receives incoming frames from the Aurora IP, decodes them and makes the values available to the user application via SBI blocks.
• The FIFOs are essential for the clock domain crossing. They bridge the main clock domain of imperix controllers, running at 250 MHz, to the clock domain of the Aurora IP. The frequency of the Aurora IP depends on the configuration of the Aurora channel and is therefore different for each vendor.
• The Aurora IP is provided by Xilinx. As explained in the presentation page, the IP enables easy implementation of transceivers while providing a light-weight user interface on top of which designers can build a serial link.

Because major market vendors use different Aurora channel configurations and, in some cases, specific frame structures, the bitstream is vendor-specific and must be generated using the corresponding generation scripts.

Finally, the third-party application runs on a third-party device and is not directly related to imperix products. In this example, it is required that the application enables an Aurora communication on an SFP port of the third-party simulator.

Supported devices

The supported devices are listed below. Devices marked in bold have been expressly tested and validated.

(*) The communication chain, driver and address mapping implemented in this page are very specific in order to match the frame structure expected by the MMC model running on the GTSOC V2.

The Aurora configuration applied by each vendor is summarized in the following table.

User application template

As mentioned, the user application has no special requirements, except that it contains SBO and SBI blocks to communicate with the driver running in the FPGA.

For a quick start, a user application template, either in Simulink or PLECS, that sends and receives three signals via SFP is provided below:

The communication between the CPU and the FPGA is handled by the SBIO bus. Thanks to the related SBI and SBO blocks, the CPU generates read and write requests on the SBIO bus and interacts with the registers located in the FPGA.

As the SBIO bus is intended to carry 16-bit data, the 32-bit values are split into two 16-bit words to be transferred over the bus. The conversion is handled by the single2sbo and sbi2single Matlab/C-Script functions.

To build the user application, make sure that the Automated Code Generation mode is selected in the CONFIG block and press Ctrl+B (Simulink) or Ctrl+Alt+B and then Build (PLECS).

Bitstream generation

To generate the bitstream running in the imperix controller, please follow the steps outlined below:

1. Install the Vivado Design Suite (version 2022.1 is recommended). The step-by-step installation procedure is detailed in Installation of AMD Xilinx Vivado Design Suite.
2. Download the imperix source files (version 3.10 Rev. 0 or later is mandatory). The source files are available for free at Download of the imperix firmware IP for FPGA sandbox.
3. Download the generation scripts corresponding to the targeted vendor in the table below and follow this procedure to generate the bitstream from the scripts.

Startup procedure

To start using the setup and exchange data with the third-party device:

1. Connect the imperix controller to the third-party simulator with an SFP cable. By default, the Aurora communication is connected to the port SFP 0 (UP) on the controller.
2. Generate the bitstream, as explained in the dedicated section above.
3. Load the bitstream on the imperix controller via Cockpit.
4. Download the user application template in Simulink or PLECS (or use your own model). If you use your own model, it is recommended to add probes on the exchanged signals as in the provided user application.
5. Build the model and launch it on the imperix controller via Cockpit.
6. Compile/build the code for the third-party simulator and launch it.
   Applications are provided for several vendors in the pages listed in the Supported devices section above. Refer to the vendor’s documentation for advanced guidance and details.
7. Use Cockpit to monitor the exchanged signals.

Address mapping

As introduced in the setup overview, the internal CPU-FPGA communication in imperix controllers is managed by the SBIO bus.

Since they correspond to 16-bit words, SBI and SBO addresses are grouped by two to transfer the 32-bit words of the payload, starting at address 0. For instance, the first word to be transmitted must be written in the SBO 1 (MSB) and SBO 0 (LSB), and the first word received from the simulator is available in SBI 1 (MSB) and SBI 0 (LSB).

The number of signals to transmit to the third-party device must be specified in SBO 255. Similarly, the number of received signals is available in SBI 255.

To go further

How to exchange more signals

The current implementation supports the exchange of 32 signals in each direction. This section describes how to extend the number of signals.

1. Change the number of ports of the provided VHDL driver.
   The driver is located in <folder>/hdl/sfp_aurora_rtbox.vhd and the instructions are clearly indicated at the top of the file. These changes basically consist in adding more ports, inserting them into the interfaces, and linking their values to the two internal arrays.
2. Adapt the surrounding modules.
   Make sure that the surrounding modules support the desired number of signals, namely the sbio_256_registers, convert_16b_to_32b and convert_32b_to_16b modules. Do not forget to extend the length of the axis_data_fifo_0 FIFO.
3. Regenerate the bitstream.
4. Adapt the Simulink model.
   Add the corresponding SBI and SBO blocks in the Simulink model.
5. Make sure that the third-party device is configured accordingly.

How to assign a different SFP port

In the provided implementation, the communication with the RT-Box is configured on the SFP port 0 (UP). To assign the SFP communication to another SFP port (e.g., SFP 1 (DOWN0)):

1. Open the Vivado project.
2. Change the enabled SFP port.
   Double-click on the IX IP block in the block diagram to open the configuration panel. Once opened, in the Using SFP from sandbox tab, check the entry of the desired SFP port and uncheck the entry for SFP 0.
   This will re-enable RealSync on port 0 (UP)and disable it on the selected port, removing the txn_0, txp_0, rxn_0, rxp_0 ports of the imperix firmware IP and exposing the ports of the selected SFP port instead.

3. Connect the ports.
   Connect the four ports exposed during step 3 to the Aurora IP, as illustrated below.

4. Regenerate the bitstream.

The post SFP communication with third-party devices appeared first on imperix.

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

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 RT-Box 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 RT-Box via the Aurora protocol.
• Upon receipt, the RT-Box 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.

This project has been tested with a Plexim RT-Box 1 and PLECS 4.5.9.

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 RT-Box application, provided as a simple PLECS model.

RT-Box application

The application running in the RT-Box simply reads the values from the imperix controller, multiplies them by a gain of 2, and sends them back to the imperix controller. A scope is added to enable the real-time control of the setup via the External Mode of the RT-Box.

The SFP In block is configured to read 3 signals from the SFP A port of the RT-Box. The SFP Out block is also configured on SFP A.

To build and load the model on the RT-Box, press Ctrl+Alt+B to open the Coder Options menu. In the Target tab, configure the target type and IP, and enable the External Mode via the checkbox. Then, navigate to the External Mode tab and press Build.

To launch the acquisition using the External Mode of the RT-Box, wait for the code to be built and loaded, then press Connect and Activate autotriggering.

The code should now be running in the RT-Box and the scope acquisition started (showing only zeroes if the imperix controller is not yet configured).

Communication chain

Overview

The overview of the communication chain is presented in the setup overview. However, for Plexim, the logic is slightly different: a proprietary IP is added in the design, between the FIFOs and the Aurora IP. This IP implements an additional layer of encapsulation to comply with the frame structure expected by the RT-Box.

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

Aurora parameters

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

Plexim-specific notes

• Received frames with an invalid checksum are dropped by the Plexim IP. This behavior can be changed manually by double-clicking the rtbox_aurora_adapter Plexim IP in Vivado and unchecking the Drop packages with invalid checksum checkbox.
• An additional rx_CRC_check_ok signal is available at the output of the driver. This output is updated simultaneously with rx_vld and indicates if the frame has a valid CRC. If invalid frames are dropped by the Plexim IP (see previous item), the CRC_check_ok is expected to be always high.

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 RT-Box with an SFP cable. As provided, this example considers the port SFP 0 (UP) on the controller and SFP A on the RT-Box.
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. Build and load the RT-Box application on the RT-Box.
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 RT-Box.

The exchanged signals can also be monitored from the RT-Box, using the External Mode, as described in the RT-Box application section.

The post Aurora link with Plexim via SFP appeared first on imperix.