Publications on WCET-Aware Compilation
[176970] |
Title: Compile-Time Decided Instruction Cache Locking Using Worst-Case Execution Paths. <em>In Proceedings of the International Conference on Hardware/Software Codesign and System Synthesis (CODES+ISSS)</em> |
Written by: Heiko Falk, Sascha Plazar and Henrik Theiling |
in: September (2007). |
Volume: Number: |
on pages: 143-148 |
Chapter: |
Editor: |
Publisher: |
Series: 20071002-codes_isss-falk-plazar.pdf |
Address: Salzburg / Austria |
Edition: |
ISBN: 10.1145/1289816.1289853 |
how published: 07-40 FPT07 CODES+ISSS |
Organization: |
School: |
Institution: |
Type: |
DOI: |
URL: |
ARXIVID: |
PMID: |
Note: hfalk, ESD, WCC
Abstract: Caches are notorious for their unpredictability. It is difficult or even impossible to predict if a memory access results in a definite cache hit or miss. This unpredictability is highly undesired for real-time systems. The Worst-Case Execution Time (WCET) of a software running on an embedded processor is one of the most important metrics during real-time system design. The WCET depends to a large extent on the total amount of time spent for memory accesses. In the presence of caches, WCET analysis must always assume a memory access to be a cache miss if it can not be guaranteed that it is a hit. Hence, WCETs for cached systems are imprecise due to the overestimation caused by the caches.<br /> Modern caches can be controlled by software. The software can load parts of its code or of its data into the cache and lock the cache afterwards. Cache locking prevents the cache's contents from being flushed by deactivating the replacement. A locked cache is highly predictable and leads to very precise WCET estimates, because the uncertainty caused by the replacement strategy is eliminated completely.<br /> This paper presents techniques exploring the lockdown of instruction caches at compile-time to minimize WCETs. In contrast to the current state of the art in the area of cache locking, our techniques explicitly take the worst-case execution path into account during each step of the optimization procedure. This way, we can make sure that always those parts of the code are locked in the I-cache that lead to the highest WCET reduction. The results demonstrate that WCET reductions from 54% up to 73% can be achieved with an acceptable amount of CPU seconds required for the optimization and WCET analyses themselves.