Computer Hardware User Manual

ManualsBrandsTexas Instruments ManualsComputer HardwareSPRAA56

Application Report

SPRAA56 – September 2004

DSP/BIOS Real-Time Analysis (RTA) and Debugging

Applied to a Video Application

Brian Jeff DSP Field Software Applications

Arnie Reynoso Software Development Systems

ABSTRACT

DSP/BIOS and the Reference Frameworks allow developers to non-intrusively instrument

real-time applications. The software provided with this application note applies real-time

analysis (RTA) services to a working application—a H.263 encode/decode loopback

example for the TMS320DM642 evaluation module. The software demonstrates

techniques for benchmarking and controlling video software. It also introduces a service to

programmatically measure CPU and TSK loading. Debugging and troubleshooting

techniques for real-time applications, using Code Composer Studio, is also discussed.

Contents

Important Benchmarks for Video Applications.......................................................................... 2

Base Application Overview ......................................................................................................... 3

2.1

DSP/BIOS and RF5 Components Used.................................................................................. 5

2.2

Requirements for Viewing RTA Benchmarks .......................................................................... 7

Modifications to the Base Example............................................................................................. 7

3.1

Splitting the Encode and Decode CELLs ................................................................................ 8

3.2

Adding the Control TSK and MBX Communication ................................................................. 8

3.3

Querying the H.263 Encoder for Status .................................................................................. 9

3.4

Controlling the Frame Rate................................................................................................... 10

RTA Techniques for Performance Measurement ..................................................................... 11

4.1

Measuring Function Execution Time with the UTL Module ................................................... 11

4.2

Measuring Task Scheduling Latencies ................................................................................. 12

4.3

Measuring End-to-End Latencies.......................................................................................... 12

4.4

Measuring the Frame Rate ................................................................................................... 13

4.5

Simulating High CPU Load Stress Conditions with Dummy NOP Loads............................... 14

4.6

Programmatic Measurement of Total CPU Load................................................................... 14

4.7

Memory Bus Utilization......................................................................................................... 15

4.8

Bitrate and Frame Type........................................................................................................ 17

4.9

Methods for Transmitting Measured Performance Data........................................................ 18

4.10

Application-Specific Control via GEL Scripts in CCStudio..................................................... 19

Viewing Benchmarks in the Instrumented Application ........................................................... 19

5.1

Requirements ....................................................................................................................... 19

5.2

Running the Application........................................................................................................ 20

5.3

Interpreting the Benchmarks................................................................................................. 22

5.4

Controlling the Run-Time Parameters Dynamically............................................................... 25

References.................................................................................................................................. 26

Appendix A. Performance Impact..................................................................................................... 27

A.1

Overhead of Performance Measurement Techniques........................................................... 27

A.2

RTA Effects on CPU Load .................................................................................................... 27

A.3

Memory Footprint ................................................................................................................. 28

Summary of content (29 pages)

PAGE 1
Application Report SPRAA56 – September 2004 DSP/BIOS Real-Time Analysis (RTA) and Debugging Applied to a Video Application Brian Jeff Arnie Reynoso DSP Field Software Applications Software Development Systems ABSTRACT DSP/BIOS and the Reference Frameworks allow developers to non-intrusively instrument real-time applications. The software provided with this application note applies real-time analysis (RTA) services to a working application—a H.
PAGE 2
SPRAA56 Figure 1. Figure 2. Figure 3. Figure 4. Figure 5. Figure 6. Figure 7. 1 Figures Basic Data Flow of the Video Application...................................................................... 4 Detailed Application Data Flow Showing Memory Buffers ........................................... 8 Task Partitioning in the Modified Application ............................................................... 9 CPU Load Measurement at Run-Time ................................................................
PAGE 3
SPRAA56 Quantization is the process of dividing a continuous range of input values into a finite number of subranges. Each subrange is assigned a specific output value. The Q factor, or quantization factor, describes the level of quantization used to store the frequency domain representation of the encoded image. Q factor often varies dynamically in an encoder when a constant bitrate is targeted, so it is useful to display the Q factor dynamically with the video stream.
PAGE 4
SPRAA56 Figure 1 shows a simplified view of the sequential flow of capture, processing, and display tasks in the application. Camera TSK tskInput TSK tskVideoProcess TSK tskOutput Device Driver Device Driver SCOM Figure 1. Basic Data Flow of the Video Application Before video data reaches the first stage, it must be converted to digital data, a process that is managed by the input device driver.
PAGE 5
SPRAA56 2.1 DSP/BIOS and RF5 Components Used The base application leverages various DSP/BIOS real-time analysis components to support debugging capabilities that are not intrusive to the system performance.
PAGE 6
SPRAA56 2.1.2 STS An STS object accumulates the following statistical information about an arbitrary 32-bit wide data series: count, total, and maximum. Statistics are accumulated in 32-bit variables on the target DSP and in 64-bit variables on the host PC. When the host polls the target for real-time statistics, it resets the variables on the target. This minimizes space requirements on the target, while allowing you to keep statistics for long test runs.
PAGE 7
SPRAA56 2.2 Requirements for Viewing RTA Benchmarks In order for any of the DSP/BIOS-based RTA tools to be visible, the DSP/BIOS components in Code Composer Studio version 2.30 or earlier and version 3.0 require that the application’s .cdb configuration file be accessible and consistent with the executable .out file. This requirement is easily met during development. It can also be satisfied in demonstrations or delivered test examples.
PAGE 8
SPRAA56 YAfter420 414 KB Device D river Buffer 3 fram es Y uv 4 22to 420 720x576 C bAfter420 H .263 en c scratch1 14 KB = 20 lines K ey H .263 d ec Shared Scratch C rAfter420 207 KB y 414 KB bitBuf 512 KB 6 KB 92 KB Instance m em ory Y uv 422to 420 Cr C bArrau Device Driver Buffer 3 fram es Cb 1.5 KB Instance m em ory 207 KB scratch2 14 KB Internal Mem ory DMA Read/W rite (background) External Mem ory CPU Read/W rite DSP C PU Function Figure 2.
PAGE 9
SPRAA56 if(controlVideoProc.frameRateChanged) { txMsg.cmd = FRAMERATECHANGED; txMsg.arg1 = chanNum; txMsg.arg2 = controlVideoProc.frameRateTarget; controlVideoProc.frameRateChanged = FALSE; MBX_post( &mbxProcess, &txMsg, 0 ); } While implementing control via the host PC did not specifically require a separate task in the modified application, adding a discrete control task makes the application more scalable.
PAGE 10
SPRAA56 This call returns a status structure of type IH263ENC_Status that contains the number of bits sent to the encoder, the frame type, and other data. The features implemented in the control API can vary widely from one algorithm to another. The bitrate and frame type measured by this API may not be available with all third-party video algorithms unless specifically requested.
PAGE 11
SPRAA56 4 RTA Techniques for Performance Measurement The RTA techniques described in this section are largely application-specific calls to DSP/BIOS RTA services via APIs in the run-time code. These API calls can be added to any application without modifying its logical structure.
PAGE 12
SPRAA56 4.2 Measuring Task Scheduling Latencies Scheduling latency is defined as the time between a wakeup signal (semaphore post) to a pending task and the actual start of that task's execution. DSP/BIOS provides a mechanism for measuring scheduling latency with the TSK_settime and TSK_deltatime APIs. These functions accumulate the difference in time from when a task is made ready to the time TSK_deltatime is called. The placement of the TSK_deltatime API therefore determines what is actually measured.
PAGE 13
SPRAA56 The low-resolution CLK_getltime API is used instead of the high-resolution CLK_gethtime because the range of the latency is known to be on the order of one or more frame times, where a frame time is 33.33 ms in NTSC systems. The low-resolution timing measurement provided by CLK_getltime is more cycle efficient and is in milliseconds. Since the data is displayed in milliseconds, the lower-resolution time base results in a faster measurement, with sufficient accuracy for the latency benchmark.
PAGE 14
SPRAA56 last30frame.current = CLK_getltime(); // check to see if we dropped any frames benchVid.framesDropped.current = last30frame.current - last30frame.previous; benchVid.framesDropped.current -= 1000*(frameCnt / DISPLAYRATE); benchVid.framesDropped.current /= DISPLAYRATE; last30frame.previous = last30frame.current; if (benchVid.framesDropped.current > 0 && frameRateTarget == DISPLAYRATE ) { LOG_error("Dropped %d frames", benchVid.framesDropped.
PAGE 15
SPRAA56 ‘minloop’ (in units of ~ cycles) t0 t1 t0 t1 ‘count’ is # hits of LOAD_idlefxn in the window Window = 500ms (default) 100 – IDLload gives App CPU Load 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.
PAGE 16
SPRAA56 In video applications that handle the full resolution of 720x480, each from contains about 675 KB of data. Such applications must constantly move video frames from internal working memory buffers to external frame buffers and back. This often results in several MB of memory transfers through the external bus for each frame. At 30 frames per second, the memory transfer bandwidth requirement can be a significant CPU resource requirement.
PAGE 17
SPRAA56 These estimates are fairly accurate for the color conversion functions in the input and display tasks, but the estimates are less accurate for the encoder and decoder algorithms in the processing task. Ideally, the memory bus utilization should be available in the status structure or estimated on the data sheet of an algorithm.
PAGE 18
SPRAA56 Most current encoders use three primary frame types: Intracoded frames, Predicted frames, and Bidirectional predicted frames. These are referred to as I, P, and B frames. The H.263 encoder supplied with the example application encodes I and P frames only, but you can configure the ratio of I to P frames. Often this ratio is used in the quality vs. bitrate tradeoff. The H.263 encoder has hooks to allow for monitoring or selecting the frame type.
PAGE 19
SPRAA56 The benchmarking routines send out selected benchmark data at a prescribed interval: every 30th frame, every I (Intracoded) frame, or only on a dropped frame. The interval can be selected by controlling the .rtaMode variable within the control structure. Benchmark data is transmitted to the CCStudio on the host PC via RTDX (Real-Time Data eXchange), which is used behind the scenes by the DSP/BIOS RTA tools.
PAGE 20
SPRAA56 The application supplied with this note references board support software and libraries installed with the DM642 EVM. The project options assume this software is installed in $TI_DIR$\boards\evmdm642. The project also references the H.263 encoder algorithm, which is provided as object code with the DM642 EVM’s Board Support Package. Therefore, that package and all its associated components must be installed before running or building the supplied example as delivered.
PAGE 21
SPRAA56 – Statistics View. Shows the values for STS objects used by the UTL benchmarking APIs and some TSK-specific STS objects. You may want to change the units of the STS objects to milliseconds. To do this, right-click on the Statistics View and choose Properties. You can change the units and disable/enable STS objects individually. (The IDL_busyObj is used by the CPU Load Graph, you can disable its statistics and the TSK_idle statistics.) – Message Log.
PAGE 22
SPRAA56 Figure 6. 5.3 Workspace Including RTA Windows Interpreting the Benchmarks There are a total of 20 statistics measured by the application: 16 application-specific STS objects and 4 objects created automatically with the TSKs. Figure 7 shows a sample Statistics View of all these measurements.
PAGE 23
SPRAA56 Figure 7. Statistics View Showing Benchmark Measurements Look at both the average values and the maximum values to see how the application benchmarks are performing. Note that STS objects hold 32-bit values on the target DSP. The values accumulated on the host PC are 64-bit values. The values on the target DSP are reset to zero when the host PC polls them for data.
PAGE 24
SPRAA56 In the input and output tasks, Cell0 is the color conversion routine. In the processing task, Cell0 is the encoder and Cell1 is the decoder. The expected values for color conversion routines are given as 2-5 ms, typical values for an optimized color conversion routine. Where no expected value was available, the expected value is "—". Table 1.
PAGE 25
SPRAA56 5.3.2 Expected Values Delivered to the Message Log CPU load, latency, time to process 30 frames, and bitrate are all sent to the Message Log rather than the Statistics View window. Table 2 shows the expected and measured values. Table 2. 5.
PAGE 26
SPRAA56 The value of N, which is used by modes 2 and 3, is 30 frames by default. As a result, RTA data is logged every 1 second in NTSC applications. This value can be changed using the GEL→rtaWindow slider. This slider asks for a value between 1 and 10 seconds, and multiplies the value by 30 before updating the control variable in the application. For PAL applications, change the multiplier value in the GEL file to 25. 5.4.
PAGE 27
SPRAA56 Appendix A. Performance Impact A.1 Overhead of Performance Measurement Techniques Because most of the benchmarking APIs are called once every 30 frames, the additional CPU load expected after adding the instrumentation is low. The measured performance of the benchmarking techniques is given in Table 3. A spreadsheet containing the expected and actual timing values is provided with the software distribution. Table 3.
PAGE 28
SPRAA56 A.3 Memory Footprint The total additional code size added to the application for the debugging features was 29 KB of external memory. This was calculated from the size of the .out file with benchmarking added (518 KB) and without benchmarking (491 KB).
PAGE 29
IMPORTANT NOTICE Texas Instruments Incorporated and its subsidiaries (TI) reserve the right to make corrections, modifications, enhancements, improvements, and other changes to its products and services at any time and to discontinue any product or service without notice. Customers should obtain the latest relevant information before placing orders and should verify that such information is current and complete.