Memtrace Details

The performance analysis with memtrace is carried out in three steps, the initialization, the memory access / timing analysis and the postprocessing of the results.

Initialization

During initialization memtrace extracts the names of all functions and variables of the application. During this process user variables and functions are separated from the ones of the C library, such as printf() or malloc(). This is achieved by comparing the functions and global variables of the executable (axf-file) with the ones of the user library and object files. The results are written to a file, which servers as configuration file for the following steps.

The configuration file can be edited by the user, e.g. for adding user-defined memory areas, such as the stack and heap variables, for additional analysis. Furthermore the user can define a so called "split function", which instructs memtrace to produce snapshot results, each time the "split function" is called. This can be used e.g. in video processing for generating separate profiling results for each processed frame. Additionally the user can control if the analysis results, e.g. clock cycles, of a function should include the results of a called function (accumulated) or if it should only reflect the function's own results (self). Typically auxiliary functions, e.g. C library functions or simple arithmetic functions, are accumulated to the calling functions.

Memory Access and Timing Analysis

In the second step the performance analysis is carried out. The previously generated configuration file defines the functions and variables to be analyzed. Additionally the system parameters, such as the processor and memory architecture, can be specified. Memtrace connects to the ARMulator for the simulation of the user application and writes the analysis results for the functions and variables to files. If a "split function" has been specified, these files include tables for each call of the "split function". The output files serve as a database for the third step, where user-defined data is extracted from these tables.

Memtrace communicates with the Instruction Set Simulator ARMulator via the memtrace ARMulator extension. The extension is implemented as dynamic link library (DLL), which provides four entry functions that are called by the ARMulator. Memtrace can be retargeted to other processor platforms, if Instruction Set Simulators exist for these platforms, which provide the required tracing information about the processor state and the memory accesses.

The functions are:

• init() is called once when the ARMulator is started and initializes the memtrace profiling. It creates a list of all functions and marks the user and split functions found in the configuration file. For each function a data structure is created, which contains the function's start address and variables for collecting the analysis results. Finally two pointers, called currentFunction and evaluatedFunction, are initialized. The first pointer indicates the currently executed function and, if this function should not be evaluated, the second pointer indicates the calling function, to which the result of the current function should be added.
• nextInstruction() is called by the ARMulator each time the program counter changes. It checks, if the program execution has changed from one function to another. If so, the cycle count of the evaluatedFunction is recalculated and the call count of the currentFunction is incremented. Finally the pointers to the currentFunction and evaluatedFunction are updated. If currentFunction is a split functions, the differential results from the last call of the split functions up to the current call are printed to the result files.
• memoryAccess() is called each time a memory access occurs and increments the memory access counts of the evaluatedFunction. Depending on the information provided by the ARMulator, it is decided, if a load or store access was performed, and which bitwidth (8/16 or 32 bit) was used. Furthermore the ARMulator indicates if a cache miss occurred. Page hits and misses are calculated by comparing the address of the current with the previous memory access and incorporating the page structure of the memory.
• finish() is called by the ARMulator when the simulation has terminated. It updates the results of the last evaluatedFunction and prints the results of the last call of the split function and the accumulated results to the result file.

In the third step a postprocessing of the results can be performed, as depicted in Fig. 4. Memtrace allows the generation of user-defined tables, which contain specific results of the analysis, e.g. the load memory accesses for each function. Furthermore the results of several functions can be accumulated in groups for comparing the results of entire application modules. The user-defined tables are written to files in a tab-separated format. Thus they can be edited by spreadsheet programs for creating diagrams or further postprocessing.

Several case studies have been carried out in order to verify the usability of the analysis results for performance optimizations. As an exemplary embedded application a software-based H.264 video decoder has been chosen. The embedded system architecture uses a processor (ARM946E-S) and a memory hierarchy, which contains an instruction and a data cache (4 kByte each), a fast internal memory (up to 32 kByte of SRAM) and a slow external memory (DRAM).

The data cache decreases the number of memory accesses, especially for accessing the stack, and the fast internal memory can be used to speed-up memory accesses to frequently accessed data, which cannot be stored efficiently in the cache, such as randomly accessed data areas. As the H.264 decoder requires about 1.1 MByte of data memory (@ CIF resolution), only small parts of the data memory (less than 3% with 32 kByte of SRAM) can be stored in the internal SRAM. Therefore, it is required to profile the memory accesses to each data area of the decoder in order to find an optimal partitioning of data areas to SRAM and DRAM. Since a data cache is used, accesses to the memory only occur if data is not available in the cache, i.e. cache misses occur. Therefore, the cache misses for each relocatable data area need to be profiled, which includes global and heap variables and the stack.
 
The table below shows the profiling results for these data areas. The results are presented as a ratio between the cache misses and the size (in byte) of each data area, which can be considered as cache miss density. Thus the cache miss density reflects a benefit-cost ratio between the expected performance gain due to cache miss reduction and the required SRAM size. The highest cache miss density occurs when accessing the clipping table pointers (clipZero, clipTable) and the variable length code (VLC) tables (ZerosXX, Trail1sXX, RunXX, ...).
 
In order to achieve the optimal partitioning, those data areas with the highest cache miss density should be stored in the SRAM. The range of data areas for 8, 16 and 32 kByte of SRAM are marked in the table. When using 32 kByte of internal SRAM with an optimal partitioning, the decoding time is reduced by more than 20%.