SIL and PIL Limitations

About SIL and PIL Limitations

With Embedded Coder^®, you can run software-in-the-loop (SIL) and processor-in-the-loop (PIL) simulations by using:

The top-model.
Model blocks.
Blocks from subsystems.

The following sections describe modeling and code generation features that are either unsupported or partially supported by SIL and PIL simulations.

General SIL and PIL Limitations

Tunable Parameters and SIL/PIL

For Model block SIL/PIL and SIL/PIL block simulations, you can tune tunable workspace parameters but not tunable dialog box parameters. For information about tuning parameters, see Tune and Experiment with Block Parameter Values.

For a top model with tunable parameters, you can run a SIL/PIL simulation but you cannot tune the parameters during the simulation.

The software cannot define, initialize, or tune the following types of tunable workspace parameters.

Parameter description	Software response
Parameter description	Top-Model SIL/PIL	Model Block SIL/PIL	SIL/PIL Block
Parameters with storage class that applies `"static"` scope or `"const"` keyword. For example, `Custom`, `Const`, or `ConstVolatile`	Warning	Warning	Warning
Parameters with multiword, fixed-point data types	Warning	Error	Warning
Parameters with data types that have different sizes on host and target	Warning	Error	Warning

For C++ class code, SIL/PIL you can tune tunable workspace parameters when Parameter visibility is public. If Parameter visibility is private or protected, tuning is supported only if Parameter access is Method or Inlined method.

For top-model SIL/PIL and the SIL/PIL block, consider the case where all of the following conditions apply:

Code Generation > Interface > Code interface packaging is Reusable function.
Code Generation > Interface > Use dynamic memory allocation for model initialization is not selected.
Optimization > Default parameter behavior is Tunable.
In the Code Mapping Editor for the model, the default storage class for the Global parameters or Local parameters category is set to Default, and the model contains corresponding parameters that use the storage classes Auto or Model default.

If the SIL/PIL component cannot dynamically initialize tunable parameters in the rtP model parameter structure, you see an error message like the following:

Parameter Dialog:InitialOutput in 'SILTopModel/CounterTypeA/count'
is part of the imported "rtP" structure in the generated code but cannot be
initialized by SIL or PIL. To avoid this error, make sure the parameter 
corresponds to a tunable workspace variable. Alternatively, set 
"Configuration Parameters > Code Generation > Interface > Code interface packaging" 
to ''Nonreusable function'', or search for ''Use dynamic memory allocation 
for model initialization'' in the Configuration Parameters dialog box 
and select the checkbox.

If you select Code Generation > Interface > Use dynamic memory allocation for model initialization, this limitation does not apply.

For Model block SIL/PIL, if you specify Code interface to be Top model, you can tune parameters while a simulation runs. If you tune parameters between successive runs of the simulation, the software generates new code for the later run. The new code uses your latest settings as initial parameter values.

For top model or Model block SIL/PIL, if you change the value of a MATLAB^® variable or parameter object (such as Simulink.Parameter) that you store in a workspace, Simulink^® Coder™ regenerates the C code.

For Model block SIL/PIL, you can tune model workspace parameters between simulations, including when fast restart is enabled. You cannot tune the parameters during a simulation. You can use:

Model workspace parameters with imported storage classes.
Exported model workspace parameters with no data initialization.
Model workspace parameters that map to AUTOSAR shared parameters.

Automatic definition or initialization of model workspace parameters for Model block SIL/PIL is supported only for model workspace parameters at the top-level of the SIL/PIL component under test. The support is not available for model workspace parameters at a lower level in the model reference hierarchy, which can lead to a mismatch between normal and SIL/PIL simulation results.

Global and Local Data Stores

SIL/PIL supports global data stores. For components that are not export-function models, SIL/PIL block simulations that access global data stores must be single rate. Otherwise, the software produces an error.

SIL/PIL does not support local data stores.

Model block SIL/PIL does not support local Data Store Memory blocks that have these parameter settings:

Share across model instances – Selected.
Storage class – Auto or Model default.

You cannot create SIL/PIL blocks from models that use local Data Store Memory blocks with the Share across model instances parameter selected.

SIL/PIL Does Not Check Simulink Coder Error Status

SIL/PIL does not check the Simulink Coder error status of the generated code under test. This error status flags exceptional conditions during execution of the generated code.

Blocks in the model can also set the Simulink Coder error status, for example, custom blocks that you create. SIL/PIL does not check this error status and report errors.

Missing Code Interface Description File Errors

SIL/PIL requires a code interface description file, which is created during code generation for the component under test. If the code interface description file is missing, the SIL/PIL simulation cannot proceed. You see an error reporting that the file does not exist.

To Workspace Block

If you enable MAT-file logging, top-model SIL/PIL and SIL/PIL blocks support To Workspace blocks.

Model block SIL/PIL does not support To Workspace blocks.

Cannot Connect SIL/PIL Outputs to Merge Block

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

Unsupported Blocks

SIL/PIL does not support the following blocks:

Scope blocks, and all types of run-time display. For example, display of port values and signal values.
Stop blocks. SIL/PIL ignores the Stop Simulation block and continues simulating.

Multiword Fixed-Point I/O

You cannot run SIL and PIL simulations of models that have multiword, fixed-point signals across component boundaries.

Fixed-Point Data Types Wider Than 32 Bits

SIL/PIL supports fixed-point data types that are wider than 32 bits. For example:

64-bit long and long long
64-bit execution profiling timer data type
int64 and uint64 in MATLAB Coder SIL execution.

The following constraints apply:

For 64-bit data type support, the data type must be representable as long or long long on the MATLAB host and the target. Otherwise, the software uses the multiword, fixed-point approach, which SIL/PIL does not support.
The software does not support the 40-bit long data type of the TI’s C6000™ target.
Through the Configuration > Hardware Implementation pane, you can enable support for the 64-bit long long data type. For data types with widths between 33 and 40 bits (inclusive), the software implements the data types using the 40-bit long data type, which SIL/PIL does not support.

Data Type Replacement

For SIL/PIL, the data type replacement name for boolean must resolve to boolean, uint8, or int8.

`Simulink.ImageType` Data Type

SIL/PIL does not support Simulink Function and Data Store Memory blocks that require the transfer of Simulink.ImageType data between Simulink and the target application. At the interface:

For Simulink Function blocks, the data type of function arguments must not be Simulink.ImageType.
Data Store Memory blocks must not use Simulink.ImageType data.

If the Simulink Function and Data Store Memory blocks are not at the interface but inside the target application, the limitation does not apply.

Continuous Sample Times

Top-model SIL/PIL and SIL/PIL block do not support continuous sample times at the SIL or PIL component boundary. However, they support continuous sample times within the component.

Model block SIL/PIL does not support continuous sample times.

Variable-Size Signals

Model block SIL/PIL simulations support variable-size signals only if the model configuration parameter Propagate sizes of variable-size signals is During execution.

Top-model SIL/PIL and SIL/PIL block simulations treat variable-size signals at the I/O boundary of the SIL/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 SIL/PIL component.

There can be cases where no error occurs during propagation of signal sizes. In these cases, the software treats variable-size input signals as zero-size signals.

Internal Signal Logging

SIL/PIL blocks do not support signal logging. For a workaround, see Log Signals of a Component.

The following internal signal logging limitations apply to top-model and Model block SIL/PIL simulations.

Limitation	Applies To
Limitation	Top-Model SIL/PIL	Model Block SIL/PIL
Signals feeding merge blocks are not supported for logging in normal simulation but are logged in SIL/PIL mode. The logged values during SIL/PIL are the same as the logged values for the output of the merge block.	Yes	No
Top-model normal simulation logs data at a periodic rate but top-model SIL/PIL simulation logs data at a constant rate under these circumstances: Default parameter behavior is `Tunable`. A constant sample time signal from a Model block is logged in the top model. The logged signal is not directly connected to a root-level output port. To avoid this behavior and log at the constant rate in all simulation modes, set Default parameter behavior to `Inlined`.	Yes	No
Features not supported: Signal logging in Simulink Function block. Virtual signals. Virtual buses. Frame-based signals, which are logged as sample-based signals. Continuous, asynchronous, and triggered sample times. At the top-level of export-function models, you can log signals with triggered sample times. Logging of Stateflow^® states and local data.	Yes	Yes
Variable-size, function-call, and Action signals are not supported. A normal simulation produces an error. A SIL/PIL simulation produces a warning.	Yes	No
State port signals are not supported. A normal simulation produces an error. A SIL/PIL simulation does not produce a warning.	Yes	No

Custom Storage Class of Type `Other`

SIL/PIL simulations support the custom storage class where Type is set to Other. These limitations apply:

If the code fragments returned by the TLC file associated with the custom storage class are incomplete, the SIL/PIL application might fail to compile, or produce incorrect results.
Custom storage classes with Imported scope and Pointer access are supported, but you must provide code to initialize the pointer. For example, you can modify the response to DataAccess(record, "define", "", "") to provide a definition of the storage implementation, and initialize the pointer to the address of the implementation variable.
To determine whether a variable is const and therefore not tunable, the build process for the SIL/PIL application uses the memory section definition in the custom storage class. If the custom storage class defines a variable as const and is not associated with a const memory section, the target application might fail to compile, or produce an error during the simulation. In this case, associate the custom storage class with a memory section for which Is const is specified, for example, MemConst. Alternatively, if SupportSILPIL is an instance-specific parameter in the custom attributes class, for the associated signal or parameter, set CoderInfo.CustomAttributes.SupportSILPIL to false.

Unsupported Implementation Errors

If you use a data store, signal, or parameter implementation that SIL/PIL does not support, you can see errors like the following:

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

data interfaces can be global data stores, inports, outports, or parameters.

The model output port has been optimized through virtual output port 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 data type. To check the consistency of data types in the model, display Port Data Types.
Through a block that changes the signal dimensions. To check the consistency of data types in the model, display Signal Dimensions.

Hardware Implementation

PIL does not support multiword data types where the word order differs from the target byte order. The PIL simulation fails, displaying undefined behavior.

PIL requires that you configure the correct Hardware Implementation settings for the target environment, including byte ordering for targets. If you do not specify the correct byte ordering, the PIL simulation fails, displaying undefined behavior.

Bus Elements Mapped to Imported Bit-Field Definitions

If you map Simulink bus elements to bit fields through an imported header file, a SIL or PIL simulation produces a build error. For example, if your model has an Inport block connected to a bus that is a Simulink.Bus object with these properties:

Name — myBus

Bus elements — An array of Simulink.BusElement objects with these properties.

Name	DataType	Complexity	Dimensions
`bitField0`	`boolean`	`real`	`1`
`bitField1`	`boolean`	`real`	`1`
`bitField2`	`boolean`	`real`	`1`
`bitField3`	`boolean`	`real`	`1`
`bitField4`	`boolean`	`real`	`1`
`bitField5`	`boolean`	`real`	`1`

Data scope — Imported

Header file — busSpecification.h. This file contains myBus, which defines C bit-field data types for the bus elements.

typedef struct myBus 
{
   unsigned int bitField0 : 1;
   unsigned int bitField1 : 1;
   unsigned int bitField2 : 1;
   unsigned int bitField3 : 1;
   unsigned int bitField4 : 1;
   unsigned int bitField5 : 1;
} myBus;

Size Mismatch Between Simulink and Target Hardware Data Types

When a Simulink data type and the corresponding target hardware data type differ in size, a SIL or PIL simulation produces an error. This size mismatch can occur if you map a Simulink data type to the target hardware data type through definitions in an imported header file. For example, if you create a data type alias, T_BOOL, which is a Simulink.AliasType object with these properties:

Base type — boolean.
Mode — Built in, boolean.
Data scope — Imported.
Header file — myDefinitions.h. This file defines T_BOOL as an enumerated data type:
```
typedef enum _BOOL_TYPE
{
  FALSE           = 0,
  TRUE            = 1
} BOOL_TYPE;

typedef BOOL_TYPE T_BOOL;
```
In this case, the compiler for the target hardware determines the size of T_BOOL, which can differ from the size of the Simulink data type, boolean.

SIL Simulations with Target-Specific Custom Code

Target-specific custom code that is not portable for execution on your development computer can produce compilation or run-time failures during a SIL simulation.

For example, SIL does not support the use of custom code that explicitly casts pointers to integer-type variables that are smaller than the length of a pointer variable on your development computer. Consider using one of these alternatives:

Run a PIL simulation.
If you have custom code that casts pointers to a 32-bit integer type, for your development computer, set up a PIL target connectivity configuration that uses a toolchain that is configured to build a 32-bit binary application.

Sample Time Differences in Simulation Data Inspector Comparisons

If you use the Simulation Data Inspector to compare logged model outputs from normal and SIL or PIL simulations, the sample times of the outputs might differ. You can still use the Simulation Data Inspector to verify that the outputs match numerically.

Top-Model SIL/PIL Limitations

Top-Model Root-Level Logging

Top-model SIL/PIL supports signal logging for signals connected to root-level inports and outports. The C API is not required. Root-level logging has the following limitations:

The characteristics of the logged data such as data type, sample time, and dimensions must match the characteristics of the root-level inports and outports (rather than the characteristics of the connected signal).
In some cases, there can be differences in data type and dimensions between the signal being logged and the root inport or outport that the signal is connected to. Consider the following examples.
- If a signal being logged has matrix dimensions [1x5] but the outport connected to the signal has vector dimensions (5), then the data logged during a SIL or PIL simulation has vector dimensions (5).
- If a signal being logged has scalar dimensions but the outport connected to the signal has matrix dimensions [1x1], then the data logged during a SIL or PIL simulation has matrix dimensions [1x1].
Signals connected to duplicated inports are not logged during SIL/PIL simulation. No warning is issued.
During normal simulation, signals connected directly to duplicated inports are logged.
The Signal Logging Selector / DataLoggingOverride override mechanism is not supported.
Normal and SIL/PIL simulations log bus signals with names that are different when all of the following conditions apply:
- The SaveOutput or SignalLogging configuration parameter is on.
- The names of the elements in the bus signal are different from the corresponding names in the bus object. For example, when the InheritFromInputs parameter for a Bus Creator block is set to 'on'.
The software inserts the suffix _wrapper for output logging if the save format is Structure or Structure with time and you run the sim command without specifying the single-output format. The software adds _wrapper to the block name for signals in yout. If the save format is Array, the software does not add the suffix. For example:
```
>> yout.signals

ans =
        values: [11x1 double]
    dimensions: 1
         label: 'SignalLogging'
     blockName: 'sillogging_wrapper/OutputLogging'
```
To avoid this behavior, run command-line simulations with the sim command specifying the single-output format. See Run Simulations Programmatically.

Callback Support

SIL/PIL does not support the callbacks (model or block) StartFcn and StopFcn.

Note

Top-model SIL/PIL supports the callback InitFcn.

Incremental Build

When you start a top-model SIL/PIL simulation, the software regenerates code if it detects changes to your model. The software detects changes by using a checksum for the model. The software does not detect changes that you make to:

The HeaderFile property of a Simulink.AliasType object
Legacy S-functions

If you make these changes, build (Ctrl-B) your model again before starting the next PIL simulation.

Model Block SIL/PIL Limitations

Top-Model Code Testing

The following limitations apply:

Because model arguments do not apply to a top model, when the Code interface block parameter is set to Top model, the software does not support the Model arguments block parameter.
Conditional execution does not apply to a top model. If a Model block is set up to execute conditionally and the Code interface block parameter is set to 'Top model', the software produces an error when you run a SIL or PIL simulation.
For sample time independent models, you must set Configuration Parameters > Solver > Periodic sample time constraint to Ensure sample time independent.

Initialize Function Block Triggered at Non-Zero Time and Code interface is `Top model`

Consider a Model block where the referenced model contains an Initialize Function block and either of these conditions apply:

The referenced model is a multirate, rate-based model and its configuration parameter Treat each discrete rate as a separate task is cleared.
The referenced model contains a Data Store Read block that is being executed when the Initialize Function block is triggered and the corresponding data store is being written to from outside the component under test.

If the Initialize Function block is triggered at a non-zero time step, results of Model block simulations where Simulation mode is Software-in-the-loop (SIL) or Processor-in-the-loop (PIL) and Code interface is Top model might differ from results where Simulation mode is Normal or Accelerator.

For more information about rate-based models, see Create Rate-Based Model.

Conditionally Executed Subsystem

You see an error if:

You place your Model block, in either SIL or 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.
Your Model block, in either SIL or PIL simulation mode, has blocks that depend on absolute time and is conditionally executed.

Outputs with Constant Sample Time

If the block parameter Code interface is Top model, Model block SIL/PIL supports outputs with constant sample time.

Noninlined S-Functions

Model-block SIL/PIL simulations do not support noninlined S-functions.

Referenced Models That Use Same Target Connectivity Configuration

Consider a top model with two or more Model blocks that reference models that use the same target connectivity configuration. If the Model blocks are in PIL mode simultaneously, you cannot run a simulation of the top model. An error occurs.

SIL and PIL Instances of a Referenced Model

Consider a top model that contains two instances of a Model block that reference the same model. If one instance is in SIL mode and the other instance is in PIL mode, you cannot run a simulation of the top model. An error occurs.

Subsystem Block SIL/PIL Limitations

Atomic Subsystem Workflow Limitations

The workflow described in Unit Test Subsystem Code with SIL/PIL Manager does not support:

These subsystem types:
- Virtual
- Stateflow
- For Each
- Action
- Initialize Function
- Reset Function
- Terminate Function
- MATLAB Function
- Simulink Function
The 'C++ class' option for CodeInterfacePackaging if TargetLang is set to 'C++'.
The 'Compact' option for ERTFilePackagingFormat if PreserveStaticInFcnDecl is set to 'on'.
Subsystems that generate in-lined code. The subsystem block parameter RTWSystemCode must be 'Nonreusable function' or 'Reusable function' unless the subsystem is a function-call subsystem mapped to an AUTOSAR runnable.
Subsystems that contain:
- Referenced models.
- Simulink Function blocks.
- Data Store Memory, Data Store Read, and Data Store Write blocks.
The LDRA tool suite and the BullseyeCoverage tool for code coverage analysis.
Virtual buses at the subsystem interface.

The results from model and SIL or PIL simulations might differ numerically if:

The subsystem uses non-finite numbers, for example, NaN and Inf.
The subsystem and the parent model have multiple sample rates and rate transitions.
A lookup table block in the subsystem is connected to a Prelookup block across the subsystem boundary.

If the subsystem is an AUTOSAR runnable and the output port of the subsystem is connected to multiple root-level output ports or a root-level output port and one or more subsystems, the SIL or PIL simulation might produce an error. For example:

Subsystem myBlock is not supported for SIL or PIL simulation because 
outport 1 maps to multiple elements in the generated code...

To avoid the error, consider moving the signal branching inside the subsystem.

Variant Condition Propagation with Variant Source and Variant Sink Blocks

SIL/PIL block simulations do not support the propagation of variant conditions across component boundaries.

PIL Block Mux

The PIL block supports mux signals, except mixed data-type mux signals that expand into individual signals during a right-click subsystem build.

Code Coverage

SIL block simulations do not support the generation of code coverage results. PIL block support for code coverage depends on your target connectivity configuration and third-party product support.

Subsystem with Inherited Sample Time Blocks

When you create a SIL/PIL block from a subsystem that has blocks with inherited sample times, the generated code and SIL/PIL wrapper acquire the sample time of the original parent model. If you use the SIL/PIL block in a context that does not allow explicit sample times, for example, within a triggered subsystem, you see an error.

Try one of these workarounds:

Before you create the SIL/PIL block, in the parent model, set Configuration Parameters > Solver > Periodic sample time constraint to Ensure sample time independent.
Using the subsystem, create a Model block that is independent of sample time. With this block, run Model block SIL/PIL simulations.