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
MultiThreadCoSim parameter. For example:
tic; sim('sfunction_components'); toc
Elapsed time is 2.323264 seconds.
ans = 'on'
tic; sim('sfunction_components'); toc
Elapsed time is 4.112674 seconds.
For an example of running co-simulation components on multiple cores, see the
You can specify that an entire model run on multiple threads, or specify that particular
blocks run on multiple threads, using the
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.
(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.
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
For FMU blocks, leave the
dependencies attribute in the FMU
model description file for the FMU
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
Multithreading does not allow solver reset checks, and therefore skips over any use of
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
|Single or Multithread|
|—||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
Cannot have continuous states — In
ssSetNumContStates(SimStruct *S, int_T
n must be
Must have no direct feedthrough ports — In
ssSetInputPortDirectFeedThrough(SimStruct *S, int_T port, int_T
dirFeed must be
0 for each
Must be thread safe — In
val must be
Must be exception-free — In
ssSetOptions(SimStruct *S, uint_T
options must include
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,
Debug logging redirect is set to File — For example,
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.