Compiler-decided dynamic memory allocation for scratch-pad based embedded systems

Abstract

In this research we propose a highly predictable, low overhead and yet dynamic, memory allocation strategy for embedded systems with scratch-pad memory. A scratch-pad is a fast compiler-managed SRAM memory that replaces the hardwaremanaged cache. It is motivated by its better real-time guarantees vs cache and by its significantly lower overheads in energy consumption, area and overall runtime, even with a simple allocation scheme. Scratch-pad allocation methods primarily are of two types. First, softwarecaching schemes emulate the workings of a hardware cache in software. Instructions are inserted before each load/store to check the software-maintained cache tags.Such methods incur large overheads in runtime, code size, energy consumption and SRAM space for tags and deliver poor real-time guarantees, just like hardware caches. A second category of algorithms partitions variables at compile-time into the two banks. However, a drawback of such static allocation schemes is that they do not account for dynamic program behavior.We propose a dynamic allocation methodology for global and stack data and program code that (i) accounts for changing program requirements at runtime (ii) has no software-caching tags (iii) requires no run-time checks (iv) has extremely low overheads, and (v) yields 100% predictable memory access times. In this method data that is about to be accessed frequently is copied into the scratch-pad using compiler-inserted code at fixed and infrequent points in the program. Earlier data is evicted if necessary. When compared to an existing static allocation scheme, results show that our scheme reduces runtime by up to 39.8% and energy by up to 31.3% on average for our benchmarks, depending on the SRAM size used. The actual gain depends on the SRAM size, but our results show that close to the maximum benefit in run-time and energy is achieved for a substantial range of small SRAM sizes commonly found in embedded systems. Our comparison with a direct mapped cache shows that our method performs roughly as well as a cached architecture in runtime and energy while delivering better real-time benefits. Albert SchweitzerWith these thoughts in mind, I embark on this humble duty to acknowledge different people who have contributed to that light in their own ways.First and foremost, I acknowledge my parents, my brother and my sister-inlaw whose concern for my health and wellbeing, always drives me to work harder towards my goals.I would also like to acknowledge those who have helped me to complete this dissertation. My advisor, Dr. Rajeev Barua, has been an outstanding motivator.

Instruction cache locking for multi-task real-time embedded systems

“…The task of allocating code/data memory to the scratchpad memory requires compiler or programmer support. Kandemir et al (2001), Udayakumaran and Barua (2003) aim at reducing ACET of programs through memory access profiles. In Puaut and Pais (2007), the authors propose an algorithm for off-line contents selection of on-chip memories, supporting both locked caches and scratchpad memories.…”

Compiler-Based Performance Evaluation of an SIMD Processor with a Multi-Bank Memory Unit

“…In order to obtain a satisfactory performance with the on-chip memory, a careful management method is needed. Several management algorithms for the on-chip memory have been studied in [15][16][17][18][19]. Especially, the reduction of the external memory access overhead becomes desperate for SIMD processors since the portion of memory access overhead increases as the number of execution cycles decreases due to SIMD programming.…”

Using FORAY Models to Enable MPSoC Memory Optimizations

“…Some of the approaches (15)(16)(17) divide all the data used by a program into data objects and profile the application to determine how often and when these data objects are accessed. The most frequently used ones are relocated to scratch pad memory.…”

“…In our experiments we used the values of 20 and 10 correspondingly to eliminate small arrays that can fit in the scratch pad completely (and thus can be handled by other techniques like (15)(16)(17) with less overhead) and to eliminate references which do not exhibit a lot of reuse.…”

“…One of the architecture approaches to this problem is the use of scratch pad memories for building customized memory subsystems. (8,11,12,(15)(16)(17) Scratch pad memories have lower power consumption than caches (1) and have predictable latency, which is important for real time applications.…”