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 | ||
---|---|---|---|
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 classesAuto
orModel 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.
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
orModel 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
andlong long
64-bit execution profiling timer data type
int64
anduint64
in MATLAB Coder SIL execution.
The following constraints apply:
For 64-bit data type support, the data type must be representable as
long
orlong 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-bitlong
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 | |
---|---|---|
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:
To avoid this behavior and log at the
constant rate in all
simulation modes, set Default parameter
behavior to
| Yes | No |
Features not supported:
| 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 andPointer
access are supported, but you must provide code to initialize the pointer. For example, you can modify the response toDataAccess(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 asconst
and is not associated with aconst
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 whichIs const
is specified, for example,MemConst
. Alternatively, ifSupportSILPIL
is an instance-specific parameter in the custom attributes class, for the associated signal or parameter, setCoderInfo.CustomAttributes.SupportSILPIL
tofalse
.
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 containsmyBus
, 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 definesT_BOOL
as an enumerated data type:In this case, the compiler for the target hardware determines the size oftypedef enum _BOOL_TYPE { FALSE = 0, TRUE = 1 } BOOL_TYPE; typedef BOOL_TYPE T_BOOL;
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
orSignalLogging
configuration parameter ison
.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 isStructure
orStructure with time
and you run thesim
command without specifying the single-output format. The software adds_wrapper
to the block name for signals inyout
. If the save format isArray
, 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 aSimulink.AliasType
objectLegacy 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 forCodeInterfacePackaging
ifTargetLang
is set to'C++'
.The
'Compact'
option forERTFilePackagingFormat
ifPreserveStaticInFcnDecl
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
andInf
.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...
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.