| Embedded Target for Texas Instruments C6000 DSPs | |
When you use the Embedded Target for TI C6000 DSP to generate code that incorporates the DSP/BIOS options, you can easily profile your generated code to gauge performance and find bottlenecks. By selecting the Profile performance at atomic subsystem boundaries option in the Real-Time Workshop options, you direct Real-Time Workshop to insert statistics (STS) object instrumentation at the beginning and end of the code for each atomic subsystem in your model. (For more about statistics objects, refer to your DSP/BIOS documentation from Texas Instruments.) After your code has been running for a few moments on your target, you can retrieve the profiling results from your target back to MATLAB and display the information in a custom HTML report. For directions that explain how to use the profiling feature, refer to To Profile Your Generated Code.
To enable the profile feature for your Simulink model, choose Tools-> Real-Time Workshop -> Options from the model menu bar. Navigate to the TI C6000 code generation category, and select the Profile performance at atomic subsystem boundaries option.
Before you build your model in the Real-Time Workshop, you must convert the segments of your model to profile into subsystems using Create subsystem. Code profiling works only on atomic subsystems in your model. By designating one or more subsystems in your model as atomic, you force the subsystem to be executed all at once, that is only at a time step when all of its inputs are available. Waiting for all the subsystem inputs to be available before running the subsystem allows the subsystem code to be profiled as a contiguous segment.
Notice the STS objects that are placed into the generated code and the generated DSP/BIOS configuration in the configuration file. The Embedded Target for TI C6000 DSP inserts and configures these objects specifically for profiling your code. You do not have to make changes to the STS objects. Simply download the generated application to your board, turn on the DSP/BIOS Statistics View in Code Composer Studio, and run the board for a few seconds. You see the statistics being accumulated.
To help you to measure subsystem performance, Embedded Target for TI C6000 DSP provides a custom HTML report that analyzes and displays the profile statistics. The HTML page shows you the amount of time spent computing each subsystem, including both Outputs and Update code segments, and provides links to click that open the corresponding subsystem in the Simulink model.
To view the profiling report, use
at the MATLAB prompt, where cc is the handle to your target and Code Composer Studio and report is one of the input options for profile.
When you generate the report, Embedded Target for TI C6000 DSP stores the report in your MATLAB temporary directory, with the name profileReport.html. To locate your temporary directory, type
at the MATLAB prompt. MATLAB returns the path to your temporary directory.
You must invoke profile after your Real-Time Workshop build, without clearing MATLAB memory between operations, so that stored information about the model is still available to the report generator. If you clear your MATLAB memory, information required for the profile report gets deleted and the report does not work properly. If you have a Code Composer Studio project that was previously created with Real-Time Workshop, you must repeat the Real-Time Workshop build to see the subsystem-based profile analysis in the report.
Trace each subsystem presented in the profile report back to its corresponding subsystem in your Simulink model by clicking a link in the report. The mapping from Simulink subsystems to generated system code is complex and thus not detailed here. Inspect the generated code, particularly modelname.c, to determine where and how Simulink and Real-Time Workshop implemented particular subsystems. In some cases, Real-Time Workshop may have pruned unused data paths, causing related performance measurements to become meaningless. Reusable system code, or code reuse, where a single function is called from multiple places in the generated code, can exhibit extra measurements in the profile statistics, while the duplicate subsystem may not show valid measurements.
Although there are STS objects which measure the execution time of the entire mdlOutputs and mdlUpdate functions, those measurements can be misleading because they do not include other segments of code that execute at each interrupt. Statistics for the SWI are used when calculating the critical headroom, which does not include the small overhead required for each interrupt. To measure most accurately the overall application CPU usage, consider the DSP/BIOS IDL statistics, which measure time spent not doing application work.
The interrupt rate for a DSP/BIOS application created by the Embedded Target for TI C6000 is the fastest block execution rate in the model. The interrupt rate is usually, but not always, the same as the codec frame rate. When there is an upsampling operation or other rate-increasing operation in your model, interrupts are triggered by a timer (PRD) object at the faster rate. You can determine the effective interrupt rate of the model by inverting the interrupt interval reported by the profiler.
Nested subsystems are profiled inclusively--the execution time reported for the parent subsystem includes the time spent in any profiled child subsystems.
For models with multiple sample times, the profiling feature can be used only in single-tasking mode, because code segments must execute contiguously for the timing measurements to be correct.
| | Generated Code Without and with DSP/BIOS | Reading Your Profile Report | |