DMCA
Memory allocation for embedded systems with a compile-time-unknown scratch-pad size (2005)
Cached
Download Links
| Venue: | the ACM Transactions on Embedded Computing Systems (TECS |
| Citations: | 27 - 1 self |
BibTeX
@INPROCEEDINGS{Nguyen05memoryallocation,
author = {Nghi Nguyen and Angel Dominguez and Rajeev Barua},
title = {Memory allocation for embedded systems with a compile-time-unknown scratch-pad size},
booktitle = {the ACM Transactions on Embedded Computing Systems (TECS},
year = {2005},
pages = {115--125}
}
Share
 |
 |
 |
 |
||
OpenURL
Abstract
ABSTRACT This paper presents the first memory allocation scheme for embedded systems having scratch-pad memory whose size is unknown at compile time. A scratch-pad memory (SPM) is a fast compiler-managed SRAM that replaces the hardware-managed cache. Its uses are motivated by its better real-time guarantees as compared to cache and by its significantly lower overheads in energy consumption, area and access time. Existing data allocation schemes for SPM all require that the SPM size be known at compile-time. Unfortunately, the resulting executable is tied to that size of SPM and is not portable to processor implementations having a different SPM size. Such portability would be valuable in situations where programs for an embedded system are not burned into the system at the time of manufacture, but rather are downloaded onto it during deployment, either using a network or portable media such as memory sticks. Such postdeployment code updates are common in distributed networks and in personal hand-held devices. The presence of different SPM sizes in different devices is common because of the evolution in VLSI technology across years. The result is that SPM cannot be used in such situations with downloaded code. To overcome this limitation, this work presents a compiler method whose resulting executable is portable across SPMs of any size. The executable at run-time places frequently used objects in SPM; it considers code, global variables and stack variables for placement in SPM. The allocation is decided by modified loader software before the program is first run and once the SPM size can be discovered. The loader then modifies the program binary based on the decided allocation. To keep the overhead low, much of the pre-processing for the allocation is done at compile-time. Results show that our benchmarks average a 36 % speed increase versus an all-DRAM allocation, while the optimal static allocation scheme, which knows the SPM size at compile-time and is thus an un-achievable upper-bound, is only slightly faster (41 % faster than all-DRAM). Results also show that the overhead from our embedded loader averages about 1 % in both code-size and run-time of our benchmarks.
Keyphrases
embedded system spm size compile-time-unknown scratch-pad size memory allocation scratch-pad memory energy consumption loader average hardware-managed cache first run fast compiler-managed sram portable medium optimal static allocation scheme different spm speed increase un-achievable upper-bound compiler method decided allocation first memory allocation scheme global variable run-time place compile time program binary different spm size postdeployment code update modified loader software access time vlsi technology downloaded code different device all-dram allocation spm cannot real-time guarantee memory stick stack variable personal hand-held device data allocation scheme distributed network
