PIL Simulation Support and Limitations :: Verifying Compiled Object Code with Processor-in-the-Loop Simulation (Real-Time Workshop® Embedded Coder™)

Learn more about Real-Time Workshop Embedded Coder

PIL Simulation Support and Limitations

On this page…
PIL Simulation Support Code Source Support Block Support Configuration Parameters Support I/O Support Hardware Implementation Support Other Feature Support PIL Block Limitations

On this page…

PIL Simulation Support

Code Source Support

Block Support

Configuration Parameters Support

I/O Support

Hardware Implementation Support

Other Feature Support

PIL Block Limitations

PIL Simulation Support

Top-model and Model block processor-in-the-loop (PIL) simulation modes are Real-Time Workshop Embedded Coder features. You can also use top-model and Model block PIL with Embedded IDE Link software specific to AltiumTASKING.

The PIL block works with the general Embedded IDE Link product. For more details on the differences between top-model PIL, Model block PIL and the PIL block, see Choosing a PIL Simulation Approach.

The following tables describe feature support for top-model PIL, Model block PIL and the PIL block. "Yes" indicates a supported feature.

This is not a complete list of supported features, but provides information on selected features of interest for PIL, especially unsupported features and limitations.

Feature Support	Top-Model PIL	Model Block PIL Mode	PIL Block
Testing of deployment object code	Yes	Yes	Yes
Target Connectivity API	Yes	Yes	No

Code Source Support

Code Source	Code Interface	Top-Model PIL	Model Block PIL Mode	PIL Block
Top model	Standalone	Yes	No	Yes
Atomic subsystem	Standalone	No	No	Yes
Virtual subsystem	Standalone	No	No	Yes, but recommend atomic subsystem. See Algebraic Loop Issues.
Model block	Model reference Real-Time Workshop target	No, but you can include Model blocks inside your top model.	Yes. See Cannot Use Multirate Model Block PIL Inside Conditionally Executed Subsystem	No, but you can include Model blocks inside your model.
Enabled/ Triggered subsystem	Standalone	No	No	Yes
Export Functions subsystem	Export Functions	No	No	No
Legacy code	Custom	See Custom Code Interfaces.	See Custom Code Interfaces.	See Custom Code Interfaces.
Embedded MATLAB Coder	Embedded MATLAB Coder	See Custom Code Interfaces.	See Custom Code Interfaces.	See Custom Code Interfaces.

For more information on code interfaces, see PIL Code Interfaces.

Custom Code Interfaces

The MathWorks does not provide direct PIL support for code interfaces such as legacy code and Embedded MATLAB Coder. However, you can incorporate these interfaces into Simulink as an S-function (for example, using the Legacy Code Tool, S-Function Builder, or hand-written code), and then verify them using PIL.

PIL Does Not Check Real-Time Workshop Error Status

PIL does not check the Real-Time Workshop error status of the generated code under test. This error status flags exceptional conditions during execution of the generated code.

The Real-Time Workshop error status can also be set by blocks in the model (for example, custom blocks developed by a user). It is a limitation that PIL cannot check this error status and report back errors.

Cannot Use Multirate Model Block PIL Inside Conditionally Executed Subsystem

You see an error if you place your Model block (in processor-in-the-loop (PIL) simulation mode) in a conditionally executed subsystem and the referenced model is multirate (that is, has multiple sample times). Single rate referenced models (with only a single sample time) are not affected.

Block Support

Blocks	Top-Model PIL	Model Block PIL Mode	PIL Block
Model block	Yes, you can include Model blocks inside your top model.	Yes	Yes, you can include Model blocks inside your subsystem or model.
Signal Processing Blockset	Yes	Yes	Yes
Video and Image Processing Blockset™	Yes	Yes	Yes
Embedded MATLAB block	Yes	Yes	Yes
Driver blocks	Yes, but not recommended.	Yes, but not recommended.	Yes, but not recommended.
To File blocks	No	No	No
To Workspace blocks	No	No	No
Merge blocks	Yes.	Yes. Cannot connect PIL outputs to Merge blocks. See Merge Block Issue.	Yes. Cannot connect PIL outputs to Merge blocks. See Merge Block Issue.
Stop block	No. PIL ignores the Stop Simulation block and continues simulating.	No. PIL ignores the Stop Simulation block and continues simulating.	No. PIL ignores the Stop Simulation block and continues simulating.

Run-Time Display Limitation

Scope blocks, and all types of run-time display, such as the display of port values and signal values, have no effect when you specify them in models executing in PIL mode. The result during simulation is the same as if the constructs did not exist.

Merge Block Issue

If you connect PIL outputs to a Merge block, you see an error because S-function memory is not reusable.

The signal from 'mpil_enabled/Subsystem' output port 1 is
required to be persistent, hence this signal cannot be
connected to a Merge block.

Other Top-Model PIL Limitations

PIL does not support Callbacks (model or block ) InitFcn, StartFcn, StopFcn.

Configuration Parameters Support

Configuration Parameters	Top-Model PIL	Model Block PIL Mode	PIL Block
ERT-based system target file	Yes	Yes	Yes
AUTOSAR system target file	No	Yes, but see AUTOSAR Support.	No
GRT-based system target file	No	No	No
GRT compatible call interface	No; see Missing Code Interface Description File Errors.	No; see Missing Code Interface Description File Errors.	No; see Missing Code Interface Description File Errors.
Function Prototype Control	Yes	Yes	Yes
Reusable code format	Yes, but see the special cases in Imported Data Definitions.	N/A	Yes, but see the special cases in Imported Data Definitions.
Target Function Library	Yes	Yes	Yes
C++	No; see Missing Code Interface Description File Errors.	No; see Missing Code Interface Description File Errors.	No; see Missing Code Interface Description File Errors.
Generate ASAP2 file	Yes	Yes	Yes
Generate example main	N/A	N/A	N/A
MAT-file logging	No	No	No
Signal logging	Yes, but only for signals connected to root-level inports and outports.	No, but see Verifying Signals with PIL Testing.	No, but see Verifying Signals with PIL Testing.
'Simplified' model initialization	Yes	No	Yes
Single output/update	Yes, but see Algebraic Loop Issues.	Yes, but see Algebraic Loop Issues.	Yes, but see Algebraic Loop Issues.
Configuration set reference	Yes	Yes	Depends on the use of the Embedded IDE Link product.

Missing Code Interface Description File Errors

PIL requires a code interface description file, which is generated during the code generation process for the component under test. If the code interface description file is missing, PIL simulation cannot proceed and you see an error reporting that the file does not exist. This error can occur if you select these unsupported options in your configuration parameters:

GRT compatible call interface
Target Language option C++ encapsulated

Make sure that you have not selected these options.

AUTOSAR Support

PIL does supports testing components of AUTOSAR models that are modeled as model reference components. These model reference components are implemented as standard model reference Real-Time Workshop targets and do not contain any special AUTOSAR behavior.

For example, you can simulate a top-level AUTOSAR model containing PIL components, or you can create a second top-level model for testing of individual components.

Algebraic Loop Issues

For more information on algebraic loops, see:

Algebraic Loops in the Simulink documentation.
The Algebraic Loops section in Simulation Considerations That Affect Code Generation in the Real-Time Workshop documentation.
The Introduction section in Creating Subsystems in the Real-Time Workshop documentation.

There are three ways that PIL simulation can introduce algebraic loops that do not exist for a normal simulation:

Algebraic Loops Caused by Code Generation for a Virtual Subsystem. If you generate code for a virtual subsystem, the Real-Time Workshop software treats the subsystem as atomic and generates the code accordingly. The resulting code can change the execution behavior of your model, for example, by applying algebraic loops, and introduce inconsistencies to the simulation behavior.

Declare virtual subsystems as atomic subsystems to ensure consistent simulation and execution behavior for your model.

See Creating Subsystems in the Real-Time Workshop documentation.

Algebraic Loops Caused by "Single output/update function". The "single output/update function" in Real-Time Workshop optimization can introduce algebraic loops because it introduces direct feedthrough via a combined output and update function.

This option is not compatible with the Minimize algebraic loop occurrences option (in the Subsystem Parameters dialog box and Model Referencing pane of the Configuration Parameters dialog box). This option allows Real-Time Workshop to remove algebraic loops by partitioning generated code appropriately between output and update functions to avoid direct feedthrough.

Algebraic Loops Caused by PIL Scheduling Limitations. The S-function scheduling mechanism that the software uses to execute the PIL component has the following limitations:

Direct feedthrough is always set to true.
Separate output and update functions in the PIL component are always executed from the mdlOutputs S-function callback.

These limitations mean that PIL can introduce algebraic loops that do not exist in normal simulation, and you might get incorrect results. If this happens, you see a warning or error about the introduced algebraic loop and PIL results may differ from simulation results. You will not see or warning or error if the algebraic loop setting is "none" in the Configuration Parameters dialog box (under Diagnostics on the Solver pane).

A workaround is to break the algebraic loop by inserting a Unit Delay block so that the algebraic loop does not occur. Then, you can use PIL successfully.

I/O Support

I/O	Top-Model PIL	Model Block PIL Mode	PIL Block
Tunable parameters (Model reference arguments)	N/A	Yes, except for tunable structure parameters. See Tunable Parameters and PIL.	N/A
Tunable parameters (Workspace variables)	No	Yes, except for tunable structure parameters. See Tunable Parameters and PIL.	No
Virtual buses	No	Yes	Yes, but some limitations at PIL component boundary; see PIL Block Virtual Bus Support Limitations.
Nonvirtual buses	Yes, but see Top-Model PIL Bus Limitations.	Yes	Yes
MUX/DEMUX	No	Yes	Yes, but see PIL Block MUX Support Limitations.
Vector/2D/ Multidimensional	Yes	Yes	Yes
Complex data	Yes	Yes	Yes
Fixed-point data	Yes	Yes	Yes
Complex fixed-point data	Yes	Yes	Yes
Fixed-point data type override	Not at PIL component boundary. See Fixed-Point Tool Data Type Override	Not at PIL component boundary. See Fixed-Point Tool Data Type Override.	Not at PIL component boundary. See Fixed-Point Tool Data Type Override.
Goto/From I/O	N/A	N/A	Goto / From blocks must not cross the PIL component boundary. You can use Goto / From blocks to route buried signals up to top-level Inports and Outports inside the PIL component.
Global data store I/O	Yes. See Global Data Store Support and Imported Data Definitions.	Yes. See Global Data Store Support and Imported Data Definitions.	Yes. See Global Data Store Support and Imported Data Definitions.
Local data store I/O	No. See Imported Data Definitions.	No. See Imported Data Definitions.	No. See Imported Data Definitions.
Non-port-based sample times	Yes	Yes	Yes
Continuous sample times	Not at PIL component boundary.	No	Not at PIL component boundary.
Outputs with constant sample time	Yes	No	Yes
Non-auto-storage classes for data (such as signals, parameters, data stores)	Yes. See Imported Data Definitions.	Yes. See Imported Data Definitions.	Yes. See Imported Data Definitions.
Simulink data objects	Yes	Yes	Yes
Simulink numeric type and alias type	Yes	Yes	Yes
Simulink enumerated data	Yes	Yes	Yes
Custom storage classes	Yes, but see Imported Data Definitions, and Unsupported Custom Storage Classes.	Yes, but see Imported Data Definitions, and Unsupported Custom Storage Classes.	Yes, but see Imported Data Definitions, and Unsupported Custom Storage Classes.
Variable-size signals	No. See Variable-Size Signals and PIL.	No. See Variable-Size Signals and PIL.	No. See Variable-Size Signals and PIL.

Tunable Parameters and PIL

You can tune parameters during a Model block PIL mode simulation exactly as you do in Normal simulation mode.

For more information, see Global Tunable Parameters and Using Model Arguments in the Simulink model reference documentation.

Tunable Parameters Limitation. You cannot tune parameters during PIL simulation if the parameters have an associated storage class that applies "static" scope or the "const" keyword (for example, Custom, Const, or ConstVolatile). Parameter changes are ignored.

If the storage class also specifies that the parameter is imported, then you must manually define and initialize the value of the parameter. See Imported Data Definitions).

Global Data Store Support

PIL supports global data stores. PIL components that access global data stores must be single rate. You see an error if your PIL component has multiple sample times and accesses global data stores. To avoid the error, either remove accesses to global data stores or make the component single rate.

Imported Data Definitions

You can use signals, parameters, data stores, etc., that specify storage classes with imported data definitions.

Model Block PIL. The PIL application automatically defines storage for imported data associated with:

Signals at the root level of the component (on the I/O boundary)
Parameters, except data with "const" type qualifier
Global data stores

A PIL limitation is that PIL does not define storage for other imported data storage. You must define the storage through custom code included by the component under test or through the PIL rtw.pil.RtIOStreamApplicationFramework API. For example, the PIL application does not define imported data storage for data associated with:

Internal signals (not on the I/O boundary)
Local data stores
Parameters (data with "const" type qualifier)

Top-Model PIL and PIL Block.

The PIL application automatically defines storage for imported data associated with:

Signals at the root level of the component (on the I/O boundary)
Global data stores

A PIL limitation is that it does not define storage for other imported data storage. You must define the storage through custom code included by the component under test or through the PIL rtw.pil.RtIOStreamApplicationFramework API. For example, the PIL application does not define imported data storage for data associated with:

Internal signals (not on the I/O boundary)
Local data stores
Parameters; you must define and initialize parameters

Top-Model PIL and the PIL block can produce errors if you select the Real-Time Workshop option Generate reusable code, and either:

You have not selected Inline parameters and the model contains parameters, or
You have selected Inline parameters and the model contains parameters with SimulinkGlobal storage class.

If either of these conditions are met then PIL produces an error similar to the following:

Parameter "t_pil_lib_alg/t_pil_lib_alg/Unit Delay:Dialog:X0"
is not defined in the code associated with the PIL component,
and is therefore not supported for PIL.
Please change the parameter's storage class and / or the 
code generation configuration settings so that the parameter
becomes defined in the code associated with the PIL component.

Unsupported Custom Storage Classes

PIL does not support the following non-addressable custom storage classes:

BitField
GetSet

PIL also does not support signals and parameters with imported grouped custom storage classes.

Unsupported Implementation Errors

You may see errors like the following if you are using a signal or parameter implementation that PIL does not support:

The following data interfaces have 
implementations that are not supported by PIL.

data interfaces may be inports, outports or parameters.

This error message has the following possible causes:

The signal or parameter specifies an unsupported custom storage class. See Unsupported Custom Storage Classes.
The model's output port has been optimized through virtual output port optimization. See Using Virtualized Output Ports Optimization. The error occurs because the properties (for example, data type, dimensions) of the signal or signals entering the virtual root output port have been modified by routing the signals in one of the following ways:
- Through a Mux block
- Through a block that changes the signal's data type. To check the consistency of data types in the model, display Port Data Types by selecting Format > Port/Signal Displays > Port Data Types.
- Through a block that changes the signal dimensions. To check the consistency of data types in the model, display dimensions by selecting Format > Port/Signal Displays > Signal Dimensions.

The following example illustrates a model that causes this error due to changing the output port signal's data type.

Variable-Size Signals and PIL

PIL treats variable-size signals at the I/O boundary of the PIL component as fixed-size signals which can lead to errors during propagation of signal sizes. To avoid such errors, use only fixed-size signals at the I/O boundary of the PIL component.

Fixed-Point Tool Data Type Override

PIL does not support signals with data types overridden by the Fixed-Point Tool Data type override parameter at the PIL component boundary.

You may see an exception message like the following:

Simulink.DataType object 'real_T' is not in scope
from 'mpil_mtrig_no_ic_preread/TmpSFcnForModelReference_unitInTopMdl'.
 This error message is related to a hidden S-Function block.

There is no resolution for this issue.

Top-Model PIL Bus Limitations

The software does not support grounded or unconnected signals at the outputs of a top model.

You must enable the strict bus mode for top-model PIL:

In the model window, select Simulation > Configuration Parameters > Diagnostics > Connectivity.
Set Mux blocks used to create bus signals to error.

PIL Block Virtual Bus Support Limitations

The PIL block supports virtual buses except for the following cases:

You see an error if the PIL component is a top model with a root level outport that is configured to output a virtual bus. A root level outport will output a virtual bus, regardless of the type of the bus that drives it, if it specifies a bus object and the Output as nonvirtual bus in parent model check box is not selected.
You see an error if a right-click subsystem build expands the bus into individual signals.
For right-click subsystem builds only, the PIL block changes the output of outports driven by virtual buses (with associated bus objects) into nonvirtual buses. You do not see an error message in this case.

To avoid these limitations, use nonvirtual buses at the PIL component boundary.

PIL Block MUX Support Limitations

The PIL block supports mux signals, except mixed data-type mux signals that expand into individual signals during a right-click subsystem build. You see an error for unsupported cases.

Hardware Implementation Support

Hardware Implementation	Real-Time Workshop Embedded Coder	Embedded IDE Link
Different host and target data-type size	Not at PIL component boundary. See Hardware Implementation Settings.	Not at PIL component boundary. See Hardware Implementation Settings.
Word-addressable targets	No	Yes
Multiword data type word order different to target byte order	No	Yes
Multiword	No	No
Size of target `'long'` > 32 bits	No	No

Hardware Implementation Settings

PIL requires that, in the Simulink Configuration Parameters dialog box, you correctly configure the Hardware Implementation settings for the target environment.

Specify byte ordering for non-8-bit targets.

For more information, see the following sections:

Host/Target Data Type Size Mismatch. PIL supports only data types that have the same size on the host and the target at the PIL I/O boundary.

The data types used at the PIL I/O boundary are restricted based on the following rule: PIL supports the data type only if the data-type size on the host (Simulink) is the same as the data-type size on the target.

For boolean, uint8, and int8, the size is 8-bits.
For uint16 and int16, the size is 16-bits.
For uint32 and int32, the size is 32-bits.
For single, the size is 32-bits.
For double, the size is 64-bits.

Examples of unsupported data types are:

single and double on targets with 24-bit floating-point types
double on targets with 32-bit double, that is, the same size as single

Warning PIL does not always detect unsupported data types (see Data Type Size Mismatch Issues (Real-Time Workshop Embedded Coder) and Data Type Size Mismatch Issues (Embedded IDE Link)). In such cases, data transfer between host and target is incorrect and unexpected data transfer errors occur during the PIL simulation.

To resolve issues with Simulink data types that have different sizes on the host and target, do not use them at the PIL I/O boundary. Instead, use a Simulink data type that maps directly onto a target data type. This resolution is more efficient.

Data Type Size Mismatch Issues (Real-Time Workshop Embedded Coder). PIL mode makes the following assumptions about the target environment:

The target is byte addressable.
Sizes of data types on the host and target match.
Word order of multiword data types on the target is the same as the target byte order.

Warning PIL does not detect violations of these assumptions. If the settings for the target environment violate any of these assumptions, unexpected data transfer errors occur during the PIL simulation.

Some known violations with predefined hardware implementation settings are:

Unsupported word addressable targets: TI's C2000™, Freescale™ DSP563xx
Unsupported data types owing to word order: TASKING Infineon^® C166^® (single and double have reversed word order)
Unsupported data types owing to size mismatch: TASKING 8051 (double > is only 4 bytes)

Data Type Size Mismatch Issues (Embedded IDE Link). The Embedded IDE Link product registers the following information about the target environment to Simulink:

Whether the target is byte addressable.
The sizes of data types on the target.
The word order of multiword data types on the target.

This allows PIL to support target environments with unusual hardware characteristics.

PIL can detect data types used at the PIL component boundary that have a host/target data type size mismatch. In such cases, an error indicates that an unsupported data type is being used. This avoids unexpected data transfer errors during simulation.

Some target compilers allow the sizes of target data types to be changed from their default size. For example, an IEEE double data type is most likely 8 bytes by default, but an optimization option may be provided to treat it as a 4 byte IEEE single precision type instead. The registration of target data type sizes done by the Embedded IDE Link product is typically statically defined to match the compiler's default data type size, and therefore does not support changing the data type size from that default size.

Warning If you use a nondefault compiler configuration, the target data type sizes registered by the Embedded IDE Link product and the actual target data type sizes may differ. In such cases, data transfer between host and target is incorrect and unexpected data transfer errors occur during the PIL simulation.

To resolve this issue, either:

Do not use compiler options that change the default size of target data types.
Use the single data type in Simulink rather than double, if your aim is to treat double-precision floating-point types (8 bytes) as single-precision floating-point types (4 bytes).

Other Feature Support

Other Features	Top-Model PIL	Model Block PIL Mode	PIL Block
Multiplatform support (such as Linux^®)	Yes	Yes	Depends on the use of the Embedded IDE Link product.
Execution profiling	Depends on PIL configuration.	Depends on PIL configuration.	Yes (if Embedded IDE Link product support)
Stack profiling	Depends on PIL configuration.	Depends on PIL configuration.	Yes (if Embedded IDE Link product support)
C code coverage report	Depends on PIL configuration.	Depends on PIL configuration.	Yes (if Embedded IDE Link product support)

PIL Block Limitations

Out of Date PIL Application

The PIL block indicates that the PIL application executable is out of date only when the PIL block detects that new code has been generated for the PIL algorithm under test.

No indication that the PIL application executable is out of date is given under the following circumstances:

A component of the PIL application executable, such as a C library, is updated after generating code for the PIL algorithm. In this case, click the PIL block Build button to bring the PIL application executable up to date. You do not need to regenerate code for the PIL algorithm.
A model referenced by the PIL algorithm is rebuilt after generating code for the PIL algorithm. In this case, regenerate code for the PIL algorithm and then click the PIL block Build button to bring the PIL application executable up to date.

Creating a Connectivity Configuration for a Target

Verifying Numerical Equivalence of Results with Code Generation Verification

Related Products & Applications

Get Simulink trial software

Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.

Get this Simulink Kit