Code Generating Metrics for code generation

Hi,

we are compiling Simulink models for an FPGA Cyclone V board and want to read from the metrics whether the code will run stably on the ARM part of the SoC or not.

Can you point me in the right direction please.

Thank you very much and with best regards,

Lars

[Lars Lindner]

Hello MathWorks,

nobody can point me in the right direction?

With regards, Lars

Answer 1

[Harsh]

Hi @Lars Lindner,

I understand that you want to determine whether the generated code from your Simulink model will run reliably on the ARM Cortex-A (HPS) side of a Cyclone V SoC, you can use Embedded Coder’s built-in reports and instrumentation features to assess memory usage, execution time, and CPU load.

The following reports can be used to evaluate stability:

1. Generate Static Code Metrics

After code generation, open the HTML Code Generation Report and navigate to Static Code Metrics.

• Global Data Footprint: Shows total memory used by global/static variables.
• Per-function Stack Usage: Includes self and accumulated stack sizes.
• Cyclomatic Complexity: Helps identify complex functions that may need optimization.
• Call Tree Depth: Indicates potential deep call stacks that could risk stack overflow.

Use this to:

1. Add up the maximum accumulated stack sizes of your real-time entry-point functions.
2. Add the total global data size.
3. Ensure the total is ≤ 80% of available HPS RAM.

2. Enable Code Instrumentation for Timing

From R2023a, In Simulink, go to "Configuration Parameters" → "Code Generation" → "Verfication" and ensure the following settings are configured:

Code Execution Time Profiling

• Measure task execution time: Checked
• Measure function execution times: Set to All (not Off)
• Save options: Set to "All data"

Code Stack Profiling

• Measure task stack usage: Checked

After enabling the appropriate instrumentation settings, run a PIL simulation or deploy the generated code to the Cyclone V board using representative input data. During execution, collect profiling data including:

• Execution time per function: minimum, mean, and maximum values
• Total CPU cycles per time step
• Estimated CPU load, calculated as: CPU load = max execution time / sample period

Use this to:

• Ensure: Worst Case Execution Time (WCET) + OS jitter + context switch overhead ≤ sample time
• Keep CPU load ≤ 70–80% to allow sufficient headroom for interrupts, DMA, and other OS-level tasks.

For detailed guidance on profiling and optimizing on the ARM Cortex‑A HPS refer to the following page: https://www.mathworks.com/help/ecoder/performance-armcortexa.html

Please find the Documentation links

• Static Code Metrics Report: https://www.mathworks.com/help/releases/R2021b/plccoder/ug/generate-static-code-metrics-report.html
• Code Profiling & Instrumentation: https://www.mathworks.com/help/releases/R2021b/ecoder/code-execution-profiling.html
• Performance: https://www.mathworks.com/help/ecoder/profiling.html