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 — If you want to
generate only a report and reduce memory usage, for example, during a long
All data —
Allows you to generate a report and store execution-time profiles in the base
workspace. 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.
Metrics only –– Reduces bandwidth usage for the
communication channel between Simulink® and the target application. During the simulation, the software
stores on the target hardware 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 the connectivity configuration for your target, create a timer object. This action is not required for a SIL simulation.
If you select
All data from
the Save options drop-down list, the metrics display window and
generated report display Simulation Data Inspector icons . When you click one of the icons, the software imports
simulation results into the Simulation Data Inspector. You can then plot execution times and
manage and compare plots from various simulations.
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 Blocks From Subsystems. You cannot use
CodeProfilingOverride to control profiling for a PIL block.