If you generate code from a Simulink® model by using Embedded Coder® or TargetLink®, you can analyze the generated code for bugs or run-time errors with Polyspace® from within the Simulink environment. You do not have to manually set up a Polyspace project.
This topic uses Embedded Coder for code generation. For analysis of TargetLink-generated code, see Run Polyspace Analysis on Code Generated with TargetLink.
For a tutorial with a specific model, see Analyze Code Generated from Simulink Model.
Before you run Polyspace from Simulink, you must link your Polyspace and MATLAB® installations. See Integrate Polyspace with MATLAB and Simulink.
To configure code generation and generate code from a model, do one of the following:
On the Apps tab, select Embedded Coder. Then, on the C Code tab, select Quick Start. Follow the on-screen instructions.
On the C Code tab, click Settings and configure code generation through Simulink configuration parameters. The chief parameters to set are:
Type (Simulink): Select Fixed-step.
Solver (Simulink): Select auto (Automatic solver selection) or Discrete (no continuous states).
System target file (Simulink Coder):
Enter ert.tlc
or
autosar.tlc
. If you derive target
files from ert.tlc
, you can also
specify them.
Code-to-model (Simulink Coder): Select this option to enable links from code to model.
For the full list of parameters to set, see Recommended Model Configuration Parameters for Polyspace Analysis.
Alternatively, run the Code Generation Advisor with the objective Polyspace and see if the required parameters are already set. See Configure Model for Code Generation Objectives by Using Code Generation Advisor (Embedded Coder).
To generate code from the model, on the C Code tab, select Generate Code. You can follow the progress of code generation in the Diagnostic Viewer.
On the Apps tab, select Polyspace Code Verifier. On the Polyspace tab:
Select the product to run: Bug Finder or Code Prover.
Select Settings. If needed, change default values of these options.
Settings from: Enable checking of MISRA® coding rules in addition to the default checks specified in the project configuration. The default Bug Finder checks look for bugs. The default Code Prover checks look for run-time errors.
Input, Tunable parameters and Output: Constrain inputs, tunable parameters, or outputs for a more precise Code Prover analysis.
Output folder: Specify a dedicated
folder for results. The default analysis saves the
results in a folder
results_
in the current working folder.modelName
For the full list of options to set, see Polyspace Analysis in Simulink.
To analyze the code generated from the model, click anywhere on the canvas. The Analyze Code from field shows the model name. Select Run Analysis.
If the current model is referenced in another model and you want to verify the generated code in the context where the model is referenced, instead of Code Generated as Top Model, use Code Generated as Model Reference.
You can follow the progress of the analysis in the MATLAB Command Window.
The results open automatically unless explicitly disabled. By default, the
results are saved in a folder
results_
in the
current folder. Each new run overwrites previous results. You can change the
default folders or save the results to a Simulink project. To make these changes, on the
Polyspace tab, select
Settings.ModelName
If you have closed the results and want to open them later, on the Polyspace tab, select Analysis Results. To open a result prior to the last run, select Open Earlier Results and navigate to the folder containing the previous results.
The results appear in the Polyspace user interface on the Results List pane. Click each result to see the source code on the Source pane and details on the Result Details pane. See also:
Links in code comments show blocks that generate the subsequent lines of code. To see the blocks in the model, click the block names in the links. If you encounter issues, see Troubleshoot Navigation from Code to Model.
Alternatively, you can right-click a variable name and select Go to Model. This option is not available for all variables.
Investigate whether the issues in your code are related to design flaws in the model.
Design flaws in the model can lead to issues in the generated code. For instance:
The generated code might be free of specific run-time errors only for a certain range of a block parameter. To fix this issue, you can change the storage class of that block parameter or use calibration data for the analysis by using the configuration parameter Tunable parameters.
The generated code might be free of specific run-time errors only for a certain range of inputs. To determine this error-free range, you can specify a minimum and maximum value for the Inport block signals. The Polyspace analysis uses this constrained range. See Specify Ranges for Signals (Simulink).
Certain transitions in Stateflow® charts can be unreachable.
If you include handwritten C/C++ code in S-Function blocks, the Polyspace analysis can reveal possible integration issues between the handwritten and generated code. You can also analyze the handwritten code in isolation. See Run Polyspace Analysis on S-Function Code.
If you do not want to make changes in response to a Polyspace result, annotate the relevant blocks. After you annotate a block,
code operations generated from the block show results prepopulated with your
comments. If you annotate a subsystem block or a block that leads to a function
call, code operations generated from the block do not show your comments in the
analysis results. If the block is a Lookup Table, enable the Stub lookup
tables
instead of using annotations.
To annotate a block, select the block and on the Polyspace tab, select Add Annotation. Enter the following:
Comma-separated list of result acronyms. To justify only the type of result, select Only 1 check.
See:
Short Names of Bug Finder Defect Checkers (Polyspace Bug Finder)
Status, severity, and comment to be assigned to the results.
Sometimes operations in the generated code are known to cause orange checks in Code Prover. Suppose an operation is known to possibly overflow. The generated code protects against the overflow by following the operation with a saturation. Polyspace still flags the possible overflow as an orange check. To automatically justify these checks through code comments, specify the configuration parameter Operator annotations (Simulink Coder).