You can configure a software-in-the-loop (SIL) or processor-in-the-loop (PIL) simulation to produce execution-time metrics for tasks and functions in your generated code. The software calculates execution times from data that is obtained through code instrumentation added to the SIL or PIL application or the generated code under test. You can use the execution-time metrics to determine whether the generated code meets the requirements for real-time deployment on your target hardware.
For example, you can perform the following analysis:
Identify tasks that require the most time. Tasks are main entry points into the
generated code. For example, the step function for a sample rate or the
In these tasks, investigate code sections that require the most time.
Identify variations in execution time over time steps.
If you are trying to reduce execution times, the analysis results help you to focus on the most critical code sections. To observe performance changes for an updated model, rerun the SIL or PIL simulation and compare the new metrics against previous metrics.
Execution-time measurements depend greatly on the hardware that you use. For reliable results, collect execution-time metrics using hardware on which you plan to deploy the generated code, that is, run PIL simulations that execute code on your target hardware. SIL simulations, which execute code on your host computer, might not produce representative metrics.
When the SIL or PIL simulation is complete, you can:
View execution-time metrics through a display window or report.
Use the Simulation Data Inspector to view and compare the variation of execution times over a simulation.
Analyze the measurements within the MATLAB® environment.
To configure code execution profiling for a SIL or PIL simulation:
In your top model, open the Configuration Parameters dialog box, and select the Code Generation > Verification pane.
Select the Measure task execution time check box.
For function execution times, from the Measure function execution times drop-down list, select one of these options:
Coarse (referenced models and subsystems only) ––
if you want to analyse generated function code for the main model
Detailed (all function call
sites) –– if you want to analyse generated function code for
all blocks in the model.
In the Workspace variable field, specify a name. When you
run the simulation, the software generates a variable with this name in the
MATLAB base workspace. The variable contains the execution-time measurements,
and is an object of type
If the Data Import/Export > Single simulation output check box is selected, the software creates the variable in the
Simulink.SimulationOutput object that you specify.
From the Save options drop-down list, select one of these options:
Summary data only — Stream execution times
to the Simulation Data Inspector during the simulation. Store minimal
information at the end of the simulation. Use this option if you want to
generate only a report and reduce memory usage, for example, in a long
All data —
Stream execution times to the Simulation Data Inspector during the simulation.
Store execution-time profiles in the base workspace and generate a report. After
the simulation, you can use methods from the
coder.profile.ExecutionTimeSection classes to retrieve
execution-time measurements for every call to each profiled section of code that
occurs during the simulation.
If you select this option, the metrics display window and generated report display the Simulation Data Inspector icon . When you click the icon, the software imports simulation results into the Simulation Data Inspector. You can then plot execution times and manage and compare plots from various simulations.
Metrics only –– Reduces bandwidth usage for the
communication channel between Simulink® and the target application. During the simulation, the software
does not stream execution times to the Simulation Data Inspector. On the target
hardware, the software stores maximum execution times, average execution times,
and number of calls. At the end of the simulation, Simulink uploads the data from the target hardware to your development
For a PIL simulation:
You must configure a hardware-specific timer. When you set up target connectivity, create a timer object. This action is not required for a SIL simulation. For more information, see Set Up PIL Connectivity by Using target Package or Create PIL Target Connectivity Configuration for Simulink.
You can remove instrumentation overheads from execution times. For more information, see Remove Instrumentation Overheads from Execution Time Measurements.
You can control the granularity of execution-time profiling, that is, prevent the addition of code instrumentation to specific function-call sites. Through the control of profiling granularity, you can:
Focus on the performance of model components that require improvement. For example, after an initial run, disable profiling for blocks that require little processing time. This action reduces the number of items displayed by the profiling report.
Reduce the code instrumentation overhead. For example, for simple functions, the code instrumentation overhead can be greater than the execution time of the function code.
To generate execution-time metrics for tasks only, on the Code Generation > Verification pane of the Configuration Parameters dialog box, select the Measure
task execution time check box and set Measure function execution
To generate function execution data for referenced models and atomic subsystems in the
top model, on the Code Generation > Verification pane, select the Measure task execution time check box
and set Measure function execution times to
(referenced models and subsystems only).
The generation of function execution data requires the insertion of measurement probes
into the generated code. The software inserts measurement probes for an atomic subsystem
only if you set the Function packaging field (on the Code
Generation tab of the Function Block Parameters dialog box) to either
Nonreusable function or
function. If the field is set to
Auto, then the
insertion of probes depends on the packaging choice that results from the
Auto setting. If the field is set to
Inline, the software does not insert probes.
In the generated code, the software wraps each function call with measurement probes except when:
The call site cannot be wrapped because of expression folding (see Minimize Computations and Storage for Intermediate Results at Block Outputs).
The call site is located in the shared utility code (see Sharing Utility Code).
To generate function execution times for model reference hierarchies:
In the top model, open the Configuration Parameters dialog box, and select the Code Generation > Verification pane.
Select the Measure task execution time check box
For each Model block that you want to profile, specify Measure function execution times only at the reference level for which you require function execution times.
For example, consider a top model that has Model block A, which in turn contains Model block B.
If you want to generate execution times for functions from model B, select Measure task execution time for the top model and specify Measure function execution times for model B.
These parameters of the top model override the corresponding parameters of referenced models:
Measure task execution time. If you disable this parameter for the top model, you also disable function profiling for referenced models.
To control code execution profiling for a block in a model, for example, a subsystem
block, use the
CodeProfilingOverride block parameter:
In the Simulink Editor, select the block.
In the Command Window, run:
set_param(gcb, 'CodeProfilingOverride', blockParameterValue)
'off' –– Disables profiling for the block.
'on' –– Enables profiling for the block if profiling is
enabled for the parent model.
'inherit' (default) –– Applies profiling settings of
Changing the block profiling configuration does not cause the regeneration of production code.
If your top model has a PIL block, the execution profiling settings that apply to the
PIL block are the settings from the original model that you used to create the PIL block.
See Simulation with Subsystem Blocks. You cannot use
CodeProfilingOverride to control profiling for a PIL block.