Texas Instruments SPRAA56 appendix Memory Bus Utilization, CPU Load Measurement at Run-Time

Page 15

SPRAA56

‘minloop’ (in units of ~ cycles)

t0 t1 t0 t1

‘count’ is # hits of LOAD_idlefxn in the window

100 – IDLload gives App CPU Load

Window = 500ms (default)

IDL load

cpuload = (100 - ((100 * (count * minloop)) / total))

Figure 4. CPU Load Measurement at Run-Time

The LOAD module relies on an IDL thread to be inserted in an application to calibrate the amount of time needed to run a single iteration of the DSP/BIOS idle loop. It estimates the CPU load by dividing the idled time by the time elapsed and subtracting the result from 1. The load is multiplied by 100 and reported as a percentage.

To use the LOAD module in a project, follow these steps:

1.Configure an IDL function that calls LOAD_idlefxn. This routine runs in the background to measure the time spent in the CPU’s IDL (background) loop and compares it with the time spent outside the background loop to calculate a CPU load. The following Tconf statements configure such an object.

var CpuLoadCheck = tibios.IDL.create("CpuLoadCheck"); CpuLoadCheck.fxn = prog.extern("LOAD_idlefxn");

2.Include load.c and load.h in the project.

3.Call LOAD_getcpuload as needed within your application:

thrProcRta.cpuLoad = LOAD_getcpuload();

The project keeps track of the number of times the idle loop is entered over a time period specified by the “window” variable in load.c. The CPU load reported by LOAD_getcpuload is the load during the previous window period. You can modify the value of the "window" variable to suit the variability of the CPU load in your application.

Because the LOAD_idlfxn routine is only called during the background loop, while all other tasks in the system are presumably blocked or not ready, the only load introduced by this module is the execution time of the call to LOAD_getcpuload, which is approximately 1200 instruction cycles.

4.7Memory Bus Utilization

Processor utilization is a measurement of the DSP resources consumed by a given task, algorithm, or function. It is more than just MIPS consumption, however, since memory bus utilization is an important component of processor utilization, particularly when working with high-resolution video (greater than 720x480).

DSP/BIOS Real-Time Analysis (RTA) and Debugging Applied to a Video Application

15

Image 15
Contents References Appendix A. Performance Impact Modifications to the Base ExampleRTA Techniques for Performance Measurement Viewing Benchmarks in the Instrumented ApplicationFigures Important Benchmarks for Video ApplicationsSPRAA56 Base Application OverviewTskInput 1 LOG DSP/BIOS and RF5 Components Used2 STS 3 TRC4 UTL Requirements for Viewing RTA Benchmarks Modifications to the Base ExampleAdding the Control TSK and MBX Communication Splitting the Encode and Decode CELLsQuerying the H.263 Encoder for Status TskInputTskO utput Controlling the Frame Rate Measuring Function Execution Time with the UTL Module RTA Techniques for Performance MeasurementMeasuring End-to-End Latencies Measuring Task Scheduling LatenciesMeasuring the Frame Rate Programmatic Measurement of Total CPU Load Memory Bus Utilization External memory 720*480 = 345,600 B86,400 B 14,400 BBitrate and Frame Type Methods for Transmitting Measured Performance Data Viewing Benchmarks in the Instrumented Application Application-Specific Control via GEL Scripts in CCStudioRequirements Load the h263loopbackrta.out program Running the ApplicationSPRAA56 Interpreting the Benchmarks Expected Values for the STS Objects Expected and Measured STS Benchmarks Expected and Measured Logged Benchmarks Debug ModeExpected Values Delivered to the Message Log Controlling the Run-Time Parameters DynamicallyCapture and Display Task Benchmarking ReferencesMeasured Performance of Benchmarking Techniques Appendix A. Performance ImpactOverhead of Performance Measurement Techniques RTA Effects on CPU LoadMemory Footprint Details Memory FootprintImportant Notice