Simulation essentials with Simulink

This note provides in-depth content for an accurate and efficient offline simulation of an imperix controller and the corresponding plant model using ACG SDK on Simulink. Because the underlying mechanisms are identical to those used in real-time operation, this content is also valuable for understanding the controller’s behavior during real-time execution. While run-time behavior and hardware-level functioning are detailed in PN259, the current page focuses specifically on the simulation mode.

Recommended articles related to the ACG workflow are shown below. A series of video tutorials is also available with similar content.

Offline simulation overview

As explained in PN134, offline simulation is an optional but highly valuable step in control code development that enables the validation of control logic directly on a PC before deployment. This process relies on simulation models of both the Controller and the Plant that faithfully reproduce real-world behavior using specialized blocks from the Control and Power libraries included in the ACG SDK.

The same Simulink model serves both simulation and code generation purposes, with the following differences, as further explained in PN138:

• In offline simulation mode, both the Control and Plant subsystems are simulated.
• In code generation mode, only the Control subsystem is compiled, and the Plant subsystem is ignored.

Fundamental concepts

To model control and plant variables, the following fundamental concepts are used:

• Plant modeling (continuous domain): Plant quantities are generally modelled with continuous signals (labelled Cont or FiM in the illustration below), as it is usually more efficient to simulate physical systems with wide-ranging dynamics. To support this, the model must be simulated using a variable-step solver.
• Control modeling (discrete domain): The control algorithm is modeled using discrete signals (labelled D1 in the illustration below), sampled at the hardware's interrupt frequency and shifted by the sampling phase.
  • This requires an algorithm implemented in the discrete domain (in \(z\) domain).
  • This is modeled accurately with the variable-step solver, as it is forced to take a major step at each execution of the interrupt.

While the imperix blocksets are designed to handle these concepts automatically, certain user-implemented code may require extra caution to remain coherent with the rest of the model. For this reason, it is crucial to have a clear comprehension of how these simulation models function "under the hood."

Control modeling

An accurate representation of the physical controller is ensured through careful modeling of the parameters integrated into the simulation models of the peripheral blocks, as presented in the next section. These parameters include the interrupt frequency, sampling phases, execution delays, and driver latencies. Specifically, the following features are modeled:

• Sampling (CONFIG and ADC blocks): Both the sampling frequency and the sampling phases are accounted for. These parameters are defined in the CONFIG block.
• Algorithm execution (CONFIG block): The delay induced by the execution of the control algorithm is modeled, ensuring that the overall controller delay is correctly represented. This value can be specified in the CONFIG block. To determine the actual execution time of a specific algorithm, the code should be executed on a controller; the execution time corresponds to the Cycle delay displayed in the Timings tab of Cockpit.
• PWM generation (PWM block): The frequency, phase, and shape of the PWM carrier are accurately modeled, along with the update instants for duty-cycle and phase parameters (occurring at the carrier’s zero and/or maximum). Optionally, dead-time can also be simulated.

Plant modeling

To test the developed control logic during offline simulation, a simulation model of the controlled plant is required. This model can be built using any standard toolbox or even through direct implementation of physical equations. To assist customers in deriving a model of their imperix power hardware, the Power library provides models for all imperix power products. The supported toolboxes for implementing these electrical circuits in the Simulink environment are:

• Simscape Specialized Power Systems (SPS)*
• Simscape Electrical (blue blocks)
• PLECS Blockset for Simulink

Solver configuration

The variable-step solver can be configured to manage time-step calculations and simulation accuracy. These parameters are accessible via the Solver tab in the model's Configuration Parameters (Ctrl+E) or through the Simulation > Solver tab of the CONFIG block.

In most cases, the default values are sufficient. However, in some rare scenarios, manual adjustments may be necessary for the following reasons:

• Capturing fast transients: If rapid switching events are missed, lowering the Relative tolerance or the Max step size will force the solver to use higher precision and reduce the step size.
• Optimizing simulation speed: For long-duration simulations where high precision is less critical, increasing the Relative tolerance allows the solver to take larger steps, thereby reducing total simulation time. Obviously, this must be done carefully, as it may cause the solver to skip over critical high-frequency dynamics (e.g., PWM switching instants), resulting in significant inaccuracies in the simulated behavior.

Detailed information about variable-step solvers in Simulink can be found at https://www.mathworks.com/help/simulink/ug/variable-step-solvers-in-simulink-1.html

Working principle of the main peripheral blocks

The three fundamental library blocks are the CONFIG, ADC, and PWM blocks. Most applications can work with only those three, as in the standard configuration shown below:

Configuration block

The Config block configures the main global parameters of the model, such as:

• The model execution purpose (offline simulation or code generation for a real-time target).
• The frequency of the base clock \(F_{\text{CLK0}}\), which defines the sampling frequency and serves as time basis for triggering the control interrupt. CLK0 can also serve as time base for PWM modulation.
• The sampling phase \(\phi_s\), which shifts the sampling instant within the CLK0 period.
• Optionally, the interrupt postscaler, which decimates the interrupt execution by a factor \(k_{\text{post}}\).
• The cycle delay, which represents the computation time of the control algorithm. In most cases, the default value of 0.2 interrupt periods is sufficient. For higher simulation fidelity, the actual value can be measured from the Timings tab of Cockpit while the code is running in real-time.

These configuration parameters define the following hardware-level parameters, as further detailed in PN259:

• The sampling clock, with frequency \(F_{\text{SCLK}} = F_{\text{CLK0}}\) and sampling phase \(\phi_s\)
• The CPU interrupt, triggered at a frequency \(F_{\text{CPU}} = F_{\text{CLK0}}/k_{\text{post}}\) and a phase of \(\phi_s\)

In terms of simulation model implementation, the Config block contains a CLK block that generates a sawtooth signal with frequency \( F_{\text{CLK0}}\)​ and zero phase. This clock signal is then passed through a subsystem that generates the sampling clock with a relative phase shift \(\phi_s\)​, as illustrated below:

The Config block also defines the value of the CTRLPERIOD global variable. This variable can be used throughout the Simulink model as the sample time for any block (e.g. discrete transfer functions), ensuring its execution at the designated control rate. This provides an explicit alternative to using the inherited sample time (-1), which is particularly useful in complex models where Simulink’s automatic rate resolution differs from the user's intent (see Mastering the sample time section). CTRLPERIOD is defined as a vector that incorporates both the interrupt (i.e. control) period and the sampling phase \(\phi_s\):

$${\small\texttt{CTRLPERIOD}} = \left[ k_{\text{post}}\cdot T_{\text{CLK0}}, \phi_s \cdot T_{\text{CLK0}}\right]$$

The interrupt execution period is therefore available with the variable \({\small\texttt{CTRLPERIOD(1)}}\).

ADC block

The ADC block retrieves the sampled value of a given ADC channel and converts it into a value expressed in physical units, using the sensitivity and offset parameters specified in the block's configuration dialog.

The simulation model simply sample-and-holds the input signal ② on the rising edges of the sampling clock ①. The input signal is typically a continuous signal from the plant model representing a measured value. The sample time of the output signal ③ is set to CTRLPERIOD, allowing it to be automatically propagated to other connected blocks.

PWM block

Various types of pulse-width modulators are available in the imperix blockset. Among them, the carrier-based PWM modulator (CB PWM block) is the most widely used option. It configures the corresponding FPGA peripheral and generates PWM signals according to the specified duty-cycle and phase parameters.

In the simulation model, the clock signal ① at the clock input serves as the time reference for generating the carrier signal ②. In parallel, the duty-cycle value ③ is delayed by the algorithm execution time specified in the CONFIG block, and sampled once or twice per switching period (depending on the update-rate parameter). It is then compared to the carrier to produce the output PWM signal ⑤. If Simulate dead time is checked in the mask parameter, a dead time is inserted between the complementary signals.

Mastering the sample times

Mastering the sample time (essentially the execution rate) of each block is key for an accurate and efficient simulation of discrete control algorithms in Simulink, as well as the generation of proper run-time code. In particular, the execution rates must comply with the fundamental concepts listed above and be clearly identified by the Simulink engine, namely:

• The plant (i.e. physical) signals are represented by continuous signals
• The control signals (i.e. those computed during the controller main interrupt) are represented by discrete signals with a sampling rate and phase corresponding to the configuration of the main interrupt. Their sample time is, therefore, the vector CTRLPERIOD.

The blocks of the imperix blockset are built in such a way that they comply with these concepts. The user is only recommended to make sure that his/her control implementation is executed at the proper rate. In some situations, the CTRLPERIOD may not be propagated automatically to the whole control model (see the example of the step block below).

Verifying the sample times

In Simulink, the sample time of each signal can be conveniently displayed by right-clicking a blank area of the model and choosing Sample Time Display > All. The controller model should have the following colors in Simulation mode:

The color legend can be displayed by pressing Ctrl+J (see below).

The expected sample times are as follows:

• Continuous: Applied to the base clock signal and signals originating from the plant model.
• Fixed in Minor Step (FiM): An optimized version of "Continuous" applicable when a signal's value remains constant between the solver's major steps. This typically applies to switched signals (e.g. sampling clock and PWM), which do not vary between switching events.
• Variable 1, 2, 3: Assigned to specific clock signals internal to the CONFIG block.
• Discrete (D1): Used for all signals within the control implementation (the logic residing between the ADC and PWM blocks). D1 is a vector equal to CTRLPERIOD, which accounts for both the control execution period and the sampling phase (if non-zero).
• Multirate: Found in peripheral blocks. Because these blocks bridge continuous plant signals and discrete control logic, they inherently incorporate multiple sample times.

To ensure the simulation accurately represents a feasible real-time execution, the following two conditions must be met:

1. The control implementation (all blocks between the ADC and PWM peripheral blocks) must consist exclusively of discrete signals.
2. The red signals (D1) must have a sample time equal to CTRLPERIOD. This ensures that no part of the controller attempts to execute faster than the hardware interrupt, which is physically impossible. Other discrete signals may be present if they are integer multiples of the D1 rate. In such cases, these signals necessarily appear in colors other than red. For more information on multi-rate control, please refer to PN145.

Correcting the sample times

If these conditions are not satisfied, the sample time of the problematic block(s) must be set to CTRLPERIOD. In many cases, an inherited sample time (-1) is also effective, as it will typically resolve to CTRLPERIOD during model initialization.

The following example illustrates a problematic configuration where the Sine Wave block defaults to continuous behavior. In this scenario, both conditions are unmet: the control path contains a continuous signal, and Simulink has resolved the fastest discrete sample time (red - D1) to something different than CTRLPERIOD.

To resolve this issue, the sample time of the Sine Wave block must be set to -1 or CTRLPERIOD. Once the model is updated (Ctrl+D), the entire control path will resolve to a red discrete rate, equal to CTRLPERIOD.

In cases where the source of the rate conflict is difficult to identify or a block's sample time cannot be modified, a Signal Specification block set to CTRLPERIOD can be used. This helps the Simulink engine resolve the sample times correctly throughout the signal path.

Further readings

• Programming and operating imperix controllers (PN138) is a guide for deploying code onto imperix controllers
• Cockpit user guide (PN300) gives an overview of the tools provided by Cockpit and how to use them
• Speeding up simulation with Simulink (PN131) gives practical tips and tricks to speed up Simulink simulation