Embedded Target for Texas Instruments C6000 DSPs

Reading Your Profile Report

After you have the report from your generated code, you need to interpret the results. This section provides a link to sample report from a model and explains each entry in the report.

Sample of a Profile Report

When you click Sample Profile Report, the sample report opens in a new Help browser window. We open a new window so you can read the report and the descriptions of the report contents at the same time. Running the model c6711dskwdnoisf with DSP/BIOS included generated the sample report shown accessed by the link. The next sections explain the headings in the report--whatthey mean and how they are measured (where that applies).

Report Heading Information

At the beginning of the report, profiling includes the name of the model you profiled, the target you used, and the date of the report. Since the report changes each time you run it, the date can be an important means of tracking model development.

Note    Each time you run the profiling process, Embedded Target for TI C6000 DSP replaces your existing report with a newer version. To save earlier reports, rename the report before you generate a new one, or change your destination temporary directory in MATLAB, since MATLAB stores the report in your MATLAB temporary directory.

Report Subsections and Contents

Within the body of your profile report, sections report the overall performance of your generated code and the performance of each atomic subsystem.

Report Heading	Description
Overall CPU Statistics	Show you how your code ran from when you started program execution to when you stopped execution to gather the statistics.
Summary of Subsystem Profiling	Lists the name of each subsystem and the performance of the code in the subsystem.
Profiled Simulink Subsystems	Presents the statistics for each profiled subsystem separately, by subsystem. Each listing include the STS object name or names that instrument the subsystem.
STS Objects	Lists every STS object in the generated code and the statistics for each. In particular, notice the IDL_busyObj entry. DSP/BIOS uses this to determine the CPU load statistics. For more information about this object, refer to your DSP/BIOS documentation from TI.

STS timing objects that are associated with subsystem profiling are configured for host operation at 4*x, reflecting the numerical relationshop between CPU clock cycles and high-resolution timer clicks. STS Average, Max, and Total measurements return counts in instructions or CPU clock cycles.

Critical Headroom

The measured amount of time the CPU spent in idle during the worst-case interrupt cycle, when all rates in the code coincide and the code exhibits the maximum measured number of clock cycles spent in idle mode (time spent waiting to process information). When Critical headroom approaches zero, your code is at risk for overrunning. Interpret Critical headroom as a portion of the time between interrupts.

Time Between Interrupts

Time in microseconds between interrupts, where the interrupt is generated either by the ADC block or by a PRD timer.

Number of Interrupts Counted

The number of interrupts that occurred between start model execution and the moment the statistics were obtained.

CPU Clock Speed

The instruction cycle speed of your digital signal processor. On the C6701 EVM, you can adjust this speed externally to MATLAB. If you change the speed to something other than the default setting of 100 MHz, you must specify the new speed in the Real-Time Workshop options using the Current C6701EVM CPU clock rate option on the TIC6000 runtime pane.

Set at a fixed 150 MHz, the CPU clock rate on the C6711 DSK cannot be changed. You do not need to report the setting in the Real-Time Workshop options.

CPU Load

The average CPU usage computed by CCS. Note that the actual load in any particular interrupt cycle may vary greatly from this average, especially in multirate applications.

Maximum Time Spent in This Subsystem per Interrupt (Max Time)

The amount of time spent in the code segment corresponding to the indicated subsystem in the worst case. Over all the iterations measured, the maximum time that occurs is reported here. Since the profiler only supports single-tasking solver mode, no calculation can be preempted by a new interrupt. All calculations for all subsystems must complete within one interrupt cycle, even for subsystems that execute less often than the fastest rate.

Maximum Percent of Interrupt Interval (Max %)

The worst-case execution time of the indicated subsystem, reported as a percentage of the time between interrupts.

STS Objects

Profiling uses STS objects to measure the execution time of each atomic subsystem. STS objects are a feature of the DSP/BIOS Run-time Analysis tools, and one STS object can be used to profile exactly one segment of code. Depending on how Real-Time Workshop generates code for each subsystem, there may be one or two segments of code for the subsystem; the computation of outputs and the updating of states can be combined or separate. Each subsystem is assigned a unique index, i. The correspondence between subsystem and STS object can be determined from the names of the objects. Each STS object has a name of the form

• stsSysi_segment
  

where i is the subsystem index and segment is one of Output, Update, or OutputUpdate.

Profiling Generated Code

To Profile Your Generated Code