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. Only a subset of source code variables can be directly traced to a Simulink block. The Go to Model options is available for such a variable. For more details on which variables in generated code can be traced to Simulink blocks, see Trace Simulink Model Elements in Generated Code (Embedded Coder).
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 to the model in response to a Polyspace result, annotate the relevant blocks. After you annotate a block, code
operations generated from the block show results that are 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. See
In code generated by using Embedded Coder, there are known deviations from MISRA C®:2012. See Deviations Rationale for MISRA C:2012 Compliance (Embedded Coder). Justify these known issues by annotating blocks.
Annotations in Simulink blocks or in generated code do not take the history of the analysis into account. If you update your model, the Polyspace results might change while the annotations do not. Updating the model might render the existing annotations outdated. Check your annotations when you update your model or generated code.
If you use Embedded Coder to generate code, you can annotate Simulink blocks directly through the Polyspace User Interface. Locate the issue that you want to annotate, and then enter review information by adding Severity, Status, and optional notes in the Result Details pane. For instance, in the Polyspace User Interface:
Set the Status of the issue to
Set the Comment for the issue to
Might Impact "Module"
In the source code, right-click the variable showing the issue and from the context menu, select Annotate Block.
The review information carries over to the Simulink Editor as block annotation where the annotated block is highlighted.
To see this annotation in the Simulink Editor, select the highlighted component and click Edit Annotation. The Polyspace annotation dialog box appears prepopulated with the review information.
Polyspace uses the user-provided information to prepopulate the annotations in Simulink. Comments that are set in the Polyspace User Interface appear within double quotes in the Comment field in Simulink. If you have double quotes in the comment in Polyspace User interface, those are replaced by single quotes in Simulink.
The option Annotate Block is available for code elements that can be traced to a Simulink block. For more information see Trace Simulink Model Elements in Generated Code (Embedded Coder).
To annotate a block in the Simulink Editor, select the block and on the Polyspace tab, select Add Annotation. Enter :
Comma-separated list of result acronyms. To justify only the type of result, select Only 1 check.
Status, severity, and comment to assign to the results.
Sometimes operations in the generated code cause orange checks in Code Prover. Suppose an operation potentially overflows. 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 justify these checks through code comments, specify the configuration parameter Operator annotations (Embedded Coder).
When you copy an annotated block and then use it in a different model or in a different position in the same model, the changed context can render the annotation incorrect.
Polyspace does not allow annotation in blocks inside libraries and nonatomic subsystems because these blocks are reused in many different contexts. For instance, you cannot annotate a block inside a library block and justify results on all instances of the library block.
Simulink does not retain Polyspace annotations in blocks that are copied to a different model or in a different position in the same model.