Simulink® supports co-simulation between components using local solvers or that involves simulation tools. For example, co-simulation can involve an S-function implemented as a co-simulation gateway between Simulink and third-party tools or custom code. It can also involve an FMU in co-simulation mode imported to Simulink.
To improve performance, consider running models that contain co-simulation blocks (components) on multiple threads if:
You are integrating multiple co-simulation components
Integration at the component level is computationally intense
This topic assumes that you are familiar with multithreaded programming and concepts.
Simulink lets you run C MEX S-functions and Co-Simulation FMU blocks on multiple threads if they satisfy these requirements:
The block is nondirect feedthrough.
The block is threadsafe, that is, the block can work with multiple threads accessing shared data, resources, and objects without any conflicts.
Multithreaded co-simulation for Level-2 MATLAB S-Function blocks is not supported.
By default, Simulink configures all models to run on multiple threads. However, not all models have co-simulation components that can run on multiple threads, and not all models benefit from running on multiple threads. To see if a model has co-simulation components that can benefit from running on multiple threads, follow these steps:
Open your model.
Start the Performance Advisor tool (on the Debug tab, click Performance Advisor).
Select Simulation > Checks that Require Simulation to Run > Select multi-thread co-simulation setting on or off.
This check verifies that the model or block is optimally configured to take advantage of multithreaded or singlethreaded processing. If the configuration is not optimal, Performance Advisor shows the current setting and warns you that the model is not a good candidate to run on multiple threads.
Run the selected check.
Alternatively, you can manually measure the simulation of the model before and after
changing the MultiThreadCoSim
parameter. For example:
tic; sim('sfunction_components'); toc
Elapsed time is 2.323264 seconds.
get_param(gcs,'MultiThreadCoSim')
ans = 'on'
set_param(gcs,'MultiThreadCoSim','off')
tic; sim('sfunction_components'); toc
Elapsed time is 4.112674 seconds.
For an example of running co-simulation components on multiple cores, see the
slexCoSimPrimeExample
model.
MultiThreadCoSim
ParameterYou can specify that an entire model run on multiple threads, or specify that particular
blocks run on multiple threads, using the MultiThreadCoSim
parameter.
Specify that an entire model run on multiple threads if all the co-simulation blocks in the
model are nondirect feedthrough and threadsafe. If some, but not all blocks, are nondirect
feedthrough and threadsafe, identify only those blocks to run on multiple threads. The model
and blocks use the MultiThreadCoSim
parameter as follows.
Setting | Model | Block | Description |
---|---|---|---|
| (Default) Model can run on multiple threads. | ||
| Disable the block or model from running on multiple threads. | ||
| (Default) Let Simulink decide if the block can run on multiple threads. |
Enabling the MultiThreadCoSim
parameter does not mean that the block
or model simulates on multiple threads. Simulation on multiple threads occurs when
MultiThreadCoSim
is enabled and:
The block and/or model operate at a single rate.
The block and/or model are threadsafe. (For example, they do not use static or global data).
The block and/or model are nondirect feedthrough.
For S-function blocks, use the ssSetInputPortDirectFeedThrough
function.
For FMU blocks, leave the dependencies
attribute in the FMU
model description file for the FMU ModelStructure/Outputs
and
ModelStructure/InitialUnknowns
field as empty. This attribute
must be (" "
).
The block and/or model is exception-free. For S-function blocks, use the ssSetOptions
function to set
SS_OPTION_EXCEPTION_FREE_CODE
.
Multithreading does not allow solver reset checks, and therefore skips over any use of
the ssSetSolverNeedsReset
and
ssBlockStateForSolverChangedAtMajorStep
functions. Conversely, in
accelerator mode, if these functions are used or there are continuous states, multithreading
is automatically turned off.
Whether an S-function block runs single or multithreaded depends on the
MultiThreadCoSim
parameter value and the ssSetRuntimeThreadSafetyCompliance
function.
MultiThreadCoSim Setting | ssSetRuntimeThreadSafetyCompliance Setting | Single or Multithread |
---|---|---|
'auto' | RUNTIME_THREAD_SAFETY_COMPLIANCE_UNKNOWN | Single thread |
'auto' | RUNTIME_THREAD_SAFETY_COMPLIANCE_TRUE | Multithread |
'auto' | RUNTIME_THREAD_SAFETY_COMPLIANCE_FALSE | Single thread |
'off' | — | The setting is ignored and the S-function block runs singlethreaded |
The simulation runs on a single thread for accelerator and rapid accelerator modes.
There is no code generation for co-simulation components.
When the FMU block has these settings, it does not support co-simulation:
Must have a single rate — ssSetSampleTime(SimStruct *S, int_T st_index,
time_T period)
must be called to register only one discrete rate.
Must have a fixed sample time — In time_T ssSetSampleTime(SimStruct *S,
int_T st_index, time_T period)
, period
cannot be
VARIABLE_SAMPLE_TIME
.
Cannot have continuous states — In ssSetNumContStates(SimStruct *S, int_T
n)
, n
must be 0
.
Must have no direct feedthrough ports — In
ssSetInputPortDirectFeedThrough(SimStruct *S, int_T port, int_T
dirFeed)
, dirFeed
must be 0
for each
input port.
Must be thread safe — In ssSetRuntimeThreadSafetyCompliance(SimStruct *S,
int_T val)
, val
must be
RUNTIME_THREAD_SAFETY_COMPLIANCE_TRUE
.
Must be exception-free — In ssSetOptions(SimStruct *S, uint_T
options)
, options
must include
SS_OPTION_EXCEPTION_FREE_CODE
.
Has to be in co-simulation mode.
Has to be thread-safe, that is, multiple FMUs must not access the same file at the same time.
Debug logging must be disabled — For example,
set_param(block1,'FMUDebugLogging','on')
Debug logging redirect is set to File — For example,
set_param(block1,'FMUDebugLoggingRedirect','File')
Cannot expose any IRT ports for scheduling.
Cannot be inside a for-each subsystem.
Must be in accelerator mode.
Has to have single rate.
Cannot use blocks with variable sample time.
Cannot have continuous states.
Cannot have direct feedthrough on any input port.
Must have a fixed-step solver.
Cannot access any global data stores.
Cannot use any Simulink functions or caller blocks.
Cannot contain To/From File blocks.
FMU | S-Function | ssGetRuntimeThreadSafetyCompliance
| ssSetRuntimeThreadSafetyCompliance