MATLAB Examples

Evaluate Performance of the Generated Code

Learn how characteristics of generated code and RAM/ROM data affect the RAM/ROM metric.

For information about the example model and other examples in this series, see docid:ecoder_examples.example-rtwdemo_pcgd_stage_1_p1_script.

Contents

Code Evaluation

You can evaluate the generated code based on two primary metrics: execution speed and memory usage. In some cases, improvement in one metric implies a sacrifice in the other metric. For example, you can often gain faster execution by consuming more memory.

You can further classify memory usage as ROM (read-only memory) and RAM (random access memory).

  • Accessing data from RAM is faster than accessing data from ROM.
  • Executables and data must be stored on ROM because RAM does not maintain data between power cycles.

This example evaluates memory requirements and divides the memory usage into function and data components. The example does not evaluate execution speed.

Compiler Information

This evaluation uses the Freescale™ CodeWarrior® compiler.

  • Compiler: Freescale™ CodeWarrior®
  • Version: 5.5.1.1430
  • Target Processor: Power PC 565

View Code Metrics

As described in docid:ecoder_examples.example-rtwdemo_pcgd_stage_5_p1_script and docid:ecoder_examples.example-rtwdemo_pcgd_stage_6_p1_script, the generated code can require the use of utility functions. The utility functions incur a one-time, fixed cost of memory. Due to this fixed overhead, the data in this example show memory usage for:

  • Algorithms: The C code generated from the Simulink® block diagrams plus the data definition functions
  • Utilities: Functions that are part of the Simulink® Coder™ library source
  • Full: The sum of both the algorithm and utilities

Build Options Configuration

The three evaluations in this example use the same build configuration. Freescale™ CodeWarrior® was configured to minimize memory usage and apply all applicable optimizations.

Configuration 1: Reusable Functions with Data Type Double

  • Source files: PCG_Eval_File_1.zip
  • Data Type: All doubles
  • Included Data: The project includes all data that the build requires (including data declared as extern: pos_rqst, fbk_1, and fbk_2)
  • Main Function: A modified version of example_main from docid:ecoder_examples.example-rtwdemo_pcgd_stage_5_p1_script
  • Function Call Method: Reusable functions for the PI controllers

Memory Usage

            Function    Data
Algorithms  1172 bytes  549 bytes
Utilities   592 bytes   40 bytes
Full        1764 bytes  589 bytes

Configuration 2: Reusable Functions with Data Type Single

In this configuration, the model data use a single-precision floating-point data type instead of double precision.

Model Configuration

  • Source files: PCG_Eval_File_2.zip
  • Data Type: All singles
  • Included Data: The project includes all data that the build requires (including data declared as extern: pos_rqst, fbk_1, and fbk_2)
  • Main Function: A modified version of example_main from docid:ecoder_examples.example-rtwdemo_pcgd_stage_5_p1_script
  • Function Call Method: Reusable functions for the PI controllers

Memory Usage

            Function    Data
Algorithms  800 bytes   308 bytes
Utilities   592 bytes   40 bytes
Full        1392 bytes  348 bytes

This configuration uses only 56% of the data memory from the first configuration: 308 bytes instead of 549 bytes. This configuration also uses 68% of the function memory: 800 bytes instead of 1172 bytes. For this system, using single precision instead of double precision does not affect the accuracy of the control algorithm, so you can use this configuration to achieve more efficient code.

Configuration 3: Nonreusable Functions with Data Type Single

  • Source files: PCG_Eval_File_3.zip
  • Data Type: All singles
  • Included Data: The project includes all data that the build requires (including data declared as extern: pos_rqst, fbk_1, and fbk_2)
  • Main Function: A modified version of example_main from docid:ecoder_examples.example-rtwdemo_pcgd_stage_5_p1_script
  • Function Call Method: The function interface is void void so data exchange occurs through global variables

Memory Usage

            Function    Data
Algorithms  948 bytes   348 bytes
Utilities   592 bytes   40 bytes
Full        1540 bytes  388 bytes

This configuration consumes more data and function memory than the previous configuration.