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 Run Polyspace Analysis on 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):
autosar.tlc. If you derive target
ert.tlc, you can also
Code-to-model (Embedded 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.
Output folder: Specify a dedicated
folder for results. The default analysis saves the
results in a folder
in the current working folder.
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
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 Work with Signal Ranges in Blocks (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
tables instead of using annotations.
To annotate a block, select the block and on the Polyspace tab, select Add Annotation. Enter the following:
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 (Embedded Coder).
When you reuse an annotated block in a different position or model, the changed context can render the annotation incorrect. To avoid incorrect annotations:
Polyspace does not allow annotation in blocks inside libraries and non-atomic subsystems because these blocks are reused in many different contexts. You cannot annotate a block inside a library and justify results on all instances of the block.
Simulink does not retain Polyspace annotations in blocks that are copied to a different position or model.