1 Introduction


WCET analysis of multi-level set-associative instruction caches [1cm] Damien Hardy — Isabelle Puaut N° 6574 Juin 2008

WCET analysis of multi-level set-associative instruction caches

Damien Hardy, Isabelle Puaut

Thème COM — Systèmes communicants

Équipe-Projet CAPS

Rapport de recherche n° 6574 — Juin 2008 — ?? pages

00footnotetext: This study was partially supported by the french National Research Agency project Mascotte (ANR-05-PDIT-018-01)

Abstract: With the advent of increasingly complex hardware in real-time embedded systems (processors with performance enhancing features such as pipelines, cache hierarchy, multiple cores), many processors now have a set-associative L2 cache. Thus, there is a need for considering cache hierarchies when validating the temporal behavior of real-time systems, in particular when estimating tasks’ worst-case execution times (WCETs). To the best of our knowledge, there is only one approach for WCET estimation for systems with cache hierarchies [10], which turns out to be unsafe for set-associative caches.

In this paper, we highlight the conditions under which the approach described in [10] is unsafe. A safe static instruction cache analysis method is then presented. Contrary to [10] our method supports set-associative and fully associative caches. The proposed method is experimented on medium-size and large programs. We show that the method is most of the time tight. We further show that in all cases WCET estimations are much tighter when considering the cache hierarchy than when considering only the L1 cache. An evaluation of the analysis time is conducted, demonstrating that analysing the cache hierarchy has a reasonable computation time.

Key-words: WCET, hard real time systems, memory hierarchy, static analysis, abstract interpretation.

Analyse pire cas des hiérarchies de caches d’instruction associatifs par ensemble

Résumé : Avec l’arrivée de matériel complexe dans les systèmes temps-réel embarqués (processeurs avec des fonctions d’amélioration des performances tel que les pipelines, les hiérarchies de caches, les multi-cœurs), de nombreux processeurs ont maintenant des caches L2 associatifs par ensemble. Ainsi, considérer les hiérarchies de caches lors de la validation du comportement temporel des systèmes temps-réel, en particulier lors de l’estimation d’une borne supérieure du pire temps d’exécution des tâches s’exécutant sur le système devient nécessaire. A notre connaissance, il existe une seule approche traitant des hiérarchies de caches pour le calcul de cette borne [10], qui s’avère être non sûre pour les caches associatifs par ensemble.

Dans ce rapport, nous présentons les conditions pour lesquelles l’approche décrite dans [10] est non sûre. Une approche statique sûre est présentée pour les caches d’instruction. A l’opposé de [10], notre méthode supporte les caches associatifs par ensemble et les caches totalement associatifs. Cette méthode est expérimentée sur des programmes de test ainsi qu’une application réelle. Nous montrons que notre méthode est la plupart du temps précise et l’estimation du pire temps d’exécution est toujours plus précise en considérant la hiérarchie de cache comparativement à un seul niveau de cache. Une évaluation du temps de calcul est réalisée montrant que l’analyse de la hiérarchie de cache est effectuée en un temps raisonnable.

Mots-clés : pire temps d’exécution,, temps-réel strict, hiérarchie mémoire, analyse statique, interprétation abstraite.

1 Introduction

Cache memories have been introduced to decrease the access time to the information due to the increasing gap between fast micro-processors and relatively slower main memories. Caches are very efficient at reducing average-case memory latencies for applications with good spatial and temporal locality. Architectures with caches are now commonly used in embedded real-time systems due to the increasing demand for computing power of many embedded applications.

In real-time systems it is crucial to prove that the execution of a task meets its deadline in all execution situations, including the worst-case. This proof needs an estimation of the worst-case execution times (WCETs) of any sequential task in the system. WCET estimates have to be safe (larger than or equal to any possible execution time). Moreover, they have to be tight (as close as possible to the actual worst-case execution time) to correctly dimension the ressources required by the system.

The presence of caches in real-time systems makes the estimation of both safe and tight WCET bounds difficult due to the dynamic behavior of caches. Safely estimating WCET on architectures with caches requires a knowledge of all possible cache contents in every execution context, and requires some knowledge of the cache replacement policy.

During the last decade, many research has been undertaken to predict WCET in architecture equipped with caches. Regarding instruction caches, static cache analysis methods have been designed, based on so-called static cache simulation [20, 11] or abstract interpretation [18, 4]. Approaches for static data cache analysis have also been proposed [5, 16]. Other approaches like cache locking have been suggested when the replacement policy is hard to predict precisely [13] or for data caches [19]. The impact of multi-tasking has also been considered by approaches aiming at statically determining cache related preemption delays [12, 17].

To the best of our knowledge, only [10] deals with cache hierarchies. In this work, static cache analysis is applied to every level of the cache hierarchy. The memory reference stream considered by the analysis at level of the cache hierarchy (for example L2 cache) is a subset of the memory reference stream considered at level (for example L1 cache) when the analysis ensures that some references always hit at level . However, we show that the way references are filtered out in [10] is unsafe for set-associative caches. In this paper, we overcome this limitation through the proposal of a safe multi-level cache analysis of the cache structure for set-associative caches, whatever the degree of associativity. Our approach can be applied to caches with different replacement policies thanks to the reuse of an existing cache analysis method.

The paper presents experimental results showing that in most ot the cases the analysis is tight. Furthermore, in all cases WCET estimations are much tighter when considering the cache hierarchy than when considering the L1 cache only. An evaluation of the analysis time is also presented, demonstrating that analysing the L2 cache has a reasonable computation time.

The rest of the paper is organized as follows. Related work is surveyed in Section 2. Section 3 presents a counterexample showing that the approach presented in [10] may produce underestimated WCET estimates when analysing set-associative caches. Section 4 then details our proposal. Experimental results are given in Section 5. Finally, Section 6 concludes with a summary of the contributions of this paper, and gives directions for future work.

2 Related work

Caches in real-time systems raise timing predictability issues due to their dynamic behavior and their replacement policy. Many static analysis methods have been proposed in order to produce a safe WCET estimate on architectures with caches.

To be safe, existing static cache analysis methods determine every possible cache contents at every point in the execution, considering all execution paths altogether. Possible cache contents can be represented as sets of concrete cache states [12] or by a more compact representation called abstract cache states (ACS) [18, 4, 10, 11].

Two main classes of approaches [18, 11] exist for static WCET analysis on architectures with caches.

In [18] the approach is based on abstract interpretation [2, 3] and uses ACS. An function is defined to represent a memory access to the cache and a function is defined to merge two different ACS in case there is an uncertainty on the path to be followed at run-time (e.g. at the end of a conditional construct). In this approach, three different analyses are applied which used fixpoint computation to determine: if a memory block is always present in the cache (Must analysis), if a memory block may be present in the cache (May analysis), and if a memory block will not be evicted after it has been first loaded (Persistence analysis). A cache categorisation (e.g. always-hit, first-miss) can then be assigned to every instruction based on the results of the three analyses. This approach originally designed for LRU caches has been extended for different cache replacement policies in [6]: Pseudo-LRU, Pseudo-Round-Robin. To our knowledge, this approach has not been extended to analyze multiple levels of caches. Our multi-level cache analysis will be defined as an extension of [18], mainly because of the theoretical results applicable when using abstract interpretation.

In [9, 11], so-called static cache simulation is used to determine every possible content of the cache before each instruction. Static cache simulation computes abstract cache states using dataflow analysis. A cache categorisation (always-hit, always-miss, first-hit and first-miss) is used to classify the worst-case behavior of the cache for a given instruction. The base approach, initially designed for direct-mapped caches, was later extended to set-associative caches [20].

The cache analysis method presented in [9] has been extended to cache hierarchies in [10]. A separate analysis of each memory level is performed by first analysing the behavior of the L1 cache. The result of the analysis of the L1 cache is consequently used as an input to the analysis of L2 cache, and so on. The approach considers an access to the next level of the memory hierarchy (e.g. L2 cache) if the access is not classified as always-hit in the current level (e.g. L1 cache). As shown in Section 3, this filtering of memory accesses, although looking correct at the first glance, is unsafe for set-associative caches. Our work is based on the same principles as [10] (cache analysis for every level of the memory hierarchy, filtering of memory accesses), except that the unsafe behavior present in [10] is removed. Moreover, our paper presents an extensive evaluation of the performance of multi-level cache analysis, both in terms of tightness, and in terms of analysis time.

Figure 1: Example of limitation for 2-ways L1 and L2 caches

3 Limitation of Mueller’s approach

The multi-level cache analysis method presented by F. Mueller in [10] performs a separate analysis for each level in the memory hierarchy. The output of the analysis for level is a classification of each memory references as first-miss, first-hit, always-miss, or always-hit, and is used as an input for the analysis of level . In [10] always-hit means that the reference is guaranteed to be in the cache; always-miss is used when a reference is not guaranteed to be in the cache (but may be in the cache for some execution paths); first-hit and first-miss are used for references enclosed in loops, to distinguish the first execution from the others. All references are considered when analyzing level exept those classified as always-hit at level (or at a previous level). The implicit assumption behind this filtering of memory accesses is that when it cannot be guaranteed that a reference is a hit at level , the worst-case situation occurs when a cache access to level is performed. Unfortunately, this assumption is not safe as soon as the degree of associativity is greater than or equal to two, as shown on the counterexample depicted in Figure 1.

The figure represents possible streams of memory references on a system with a L1 2-ways associative cache and a L2 2-ways associative cache, both with a LRU replacement policy. The safety problem is observed on reference , assumed to be performed inside a function. References , , , and do not cause any safety problem (they cause misses in the L1 and L2 both at analysis time and at run-time); they are introduced only to illustrate the safety problem on reference . Let us assume that:


  • and map onto the same set as in the L1 cache and in the L2 cache.

  • and map onto the same set as in the L1 cache and map onto a different set than in the L2 cache. This frequent case may occur because the size of the L1 cache is smaller than the size of the L2 cache.

The left part of the figure presents the contents of the abstract cache states at points , , and in the reference stream (only the sets where reference is mapped are shown for the sake of conciseness), as well as the resulting classification. In the figure, means that both and may be in the cache line. The right part of the figure presents the concrete cache contents at the same points when the worst-case execution path (WCEP), which takes the right path in the conditional construct, is followed.

From the classification of reference , the analysis outcome is 2 misses in the L1 cache + 2 hits in the L2 cache. In contrast, executing the worst-case reference stream results in 1 hit in the L1 cache + 1 miss in the L1 cache + 1 miss in the L2 cache. Assuming an architecture where a miss is the worst-case and , the contribution to the WCET of the cache accesses to when executing the code is larger than the one considered in the analysis, which is not safe. This counterexample has been coded, in order to check that the counter-intuitive behavior of [10] actually occurs in practice.

The safety problem found in [10] is due to the combination of severals factors: the reference stream characteristics, considering uncertain accesses as misses, considering an access to the next level in such cases.

To further explain the reasons of the safety problem, let us define the set reuse distance between two references to the same memory block for a cache level as the position in the set (equivalent to its way) of the memory block when the second reference occurs. If the memory block is not present when the block is referenced for the second time then the set reuse distance is greater than the number of ways. For instance, the set reuse distance of on Figure 1 at point for Mueller’s analysis is in the L1 cache (greater than the number of L1 ways) and in the L2 cache (present in the second way). In contrast for the possible concrete cache this value is (not present in L1 cache) and (not present in L2 cache). In [10], uncertain accesses are always propagated to the next cache level and the analysis may underestimate the set reuse distance. This underestimation then results in more hits in the next level in the analysis than in a worst-case execution. Our approach fixes the problem by enumerating the two possible behaviors of every uncertain access (i.e. considering that the access may occur or not).

4 Multi-level set-associative instruction cache WCET analysis

After a brief overview of the structure of our multi-level cache analysis framework (§ 4.1), we define in this section the classification of memory accesses (§ 4.2), and detail the analysis and prove its termination (§ 4.3). The use of the cache analysis outputs for WCET computation is presented in § 4.4.

4.1 Overview

Our static multi-level set-associative instruction cache analysis is applied to each level of the cache hierarchy separately. The approach analyses the first cache level (L1 cache) to classify every reference according to its worst-case cache behavior (always-hit, always-miss, first-hit, first-miss and not classified, see § 4.2). This cache hit/miss classification () is not sufficient to know if an access to a memory block may occur at the next cache level (L2). Thus, a cache access classification (CAC) (Always, Never and Uncertain, see § 4.2) is introduced to capture if it can be guaranteed that the next cache level will be accessed or not.

The combination of the CHMC and the CAC at a given level is used as an input of the analysis of the next cache level in the memory hierarchy. Once all the cache levels have been analyzed, the cache classification of each level is used to estimate the WCET. This framework is illustrated in Figure 2.

Figure 2: Multi-level cache analysis framework

4.2 Cache classification

Cache hit/miss classification

Due to the semantic variation of the cache classification between static cache simulation [11] and abstract interpretation [18] approaches, we detail the cache hit/miss classification (CHMC) used in our analysis, similar to the one used in [18]:


  • always-hit (AH): the reference is guaranteed to be in cache,

  • always-miss (AM): the reference is guaranteed not to be in cache,

  • first-hit (FH): the reference is guaranteed to be in cache the first time it is accessed, but is not guaranteed afterwards,

  • first-miss (FM): the reference is not guaranteed to be in cache the first time it is accessed, but is guaranteed afterwards,

  • not-classified (NC): the reference is not guaranteed to be in cache and is not guaranteed not to be in cache.

Cache access classification

In order to know if an access to a memory block may occur at a given cache level, we introduce a cache access classification (CAC). It is used as an input of the cache analysis of each level to decide if the block has to be considered by the analysis or not. The cache access category for a reference at a cache level is defined as follows: 0pt

  • (Never): the access to is never performed at cache level ,

  • (Always): the access to is always performed at cache level ,

  • (Uncertain): it cannot be guaranteed that the access to is always performed or is never performed at level .

The cache access classification for a reference at a cache level depends on the results of the cache analysis of the reference at the level (cache hit/miss classification, and cache access classification):

The CAC for a reference at level is (never) when the cache hit/miss classification for at a previous level is always-hit (i.e. it is guaranteed that accessing will never require an access to cache level ). On the other side, the CAC for a reference at level is for the first level of the cache hierarchy, or when CHMC and CAC at level are respectively always-miss and (i.e. it is guaranteed that accessing will always require an access to cache level ). The CAC for reference at level is in all the other cases, expressing the uncertainty that the cache level is accessed. As detailed in § 4.3, the cache analysis for accesses explores the two cases where accesses cache level or not, to identify the worst-case.

Table 1 shows all the possible cases of cache access classifications for cache level depending on the results of the analysis of level (CACs and CHMCs).

Table 1: Cache access classification: level L

The table contents motivate the need of the cache access classification. Indeed, in case of an always-miss at level , determining if a reference should be considered at level requires more knowledge than the CHMC can provide: if is always referenced at level (), it should also be considered at level ; similarly, if it is unsure that is referenced at level (), the reference is still unsure at level .

Figure 3: and functions for the Must analysis with LRU replacement

It also has to be noted that in the case of a access, the cache hit/miss classification can be disregarded because the value will be ignored during the WCET computation step for the considered level.

4.3 Multi-level analysis

The proposed multi-level analysis is based on a well known cache analysis method. The analysis presented in [18] is used, due to the theoretical results of abstract interpretation [2, 3], and the support for multiple replacement policies [18, 6] (LRU, Pseudo-LRU, Pseudo-Round-Robin). Nevertheless, our analysis can also be integrated into the static cache simulation method [11].

The method detailed in [18] is based on three separate fixpoint analyses applied on the program control flow graph:


  • a Must analysis determines if a memory block is always present in the cache at a given point: if so, the block CHMC is always-hit;

  • a May analysis determines if a memory block may be in the cache at a given point: if not, the block CHMC is always-miss. Otherwise, if not present at this point in the Must analysis and in the Persistence analysis the block CHMC is not classified;

  • a Persistence analysis determines if a memory block will not be evicted after it has been loaded; the CHMC of such blocks is first-miss.

Abstract cache states are computed at every basic block. Two functions on the abstract domain, named , and are defined for each analysis: 0pt

  • Function is called for every memory reference on an ACS to compute the new ACS resulting from the memory reference. This function considers both the cache replacement policy and the semantics of the analysis.

  • Function is used to merge two different abstract cache states in the case when a basic block has two predecessors in the control flow graph, like for example at the end of a conditional construct.

Figure 3 gives an example of the (3.a) and (3.b) functions for the Must analysis for a 2-ways set-associative cache with LRU replacement policy. As in this context sets are independent from each other, only one set is depicted. A concept of age is associated with the cache block of the same set. The smaller the block age the more recent the access to the block. For the Must analysis, a memory block is stored only once in the ACS, with its maximum age. It means that its actual age at run-time will always be lower than or equal to its age in the ACS. The and functions are defined as follows for the Must analysis with LRU replacement (see Figure 3):


  • The function applied to two ACS results in an ACS containing only the references present in the two input ACS and with their maximal age.

  • The function performs an access to a memory reference using an input abstract cache state (the abstract cache state before the memory access) and produces an output abstract cache state (the abstract cache state after the memory access). The function maps onto its set with the younger age and increases the age of the other memory blocks present in the same set in . When the age of a memory block is higher than the number of ways, the memory block is evicted from .

For the other analyses (May and Persistence), the approach is similar and the function is defined as follows:


  • May analysis: union of references present in the ACS and with their minimal age;

  • Persistence analysis: union of references present in the ACS and with their maximal age.

For more details see [18] and for the other replacement policies see  [6].

Extending [18] to multi-level caches does not require any change in the original analysis framework. Only the base functions have to be modified to take into account the uncertainty of some references at a given cache level, expressed by the cache access classifications (CAC). Function needs not be modified. Function (named hereafter to distinguish our function from the original one) is defined as follows, depending on the CAC of the currently analyzed reference :

  • A (Always) access. In the case of an access the original function is used.

  • N (Never) access. In the case of a access, the analysis does not consider this access at the current cache level, so the abstract cache state stays unchanged.

  • U (Uncertain) access. In the case of an access, the analysis deals with the uncertainty of the access by considering the two possible alternative sub-cases (see figure 4 for an illustration): 0pt

    • the access is performed. The result is then the same as an access;

    • the access is not performed. The result is then the same as a access.

    To obtain the produced by an access, we merge this two different abstract cache states by the function.

Figure 4: function for U access

The original functions and produce a safe hit/miss classification of the memory references. In our case, this validity is kept for the accesses and is obvious for the accesses. As for the accesses, which are the key to ensure safety, the analyses have to keep the semantics of each analysis. For the Must and Persistence analyses, the function maintains the maximal age of each memory reference by the original function applied to the two ACS (access occurs or not). Similarly, for the May analysis, the minimal age is kept by the function. So the semantic of each analysis is maintained by the function.

4.3.1 Termination of the analysis

It is demonstrated in [18] that the domain of abstract cache states is finite and, moreover, that the and functions are monotonic. So, using ascending chains (every ascending chain is finite) proves the termination of the fixpoint computation.

In our case, the only modification to [18] is the function. Thus, to prove the termination of our analysis we have to prove that the modified function is monotonic for each type of cache access.

Proof: for an access, is identical to , so it is monotonic. For a access is the identity function, so it is monotonic. Finally, for an access, is a composition of and . As the composition of monotonic functions is monotonic, is then also monotonic. This guarantees the termination of our analysis for each type of cache access and thus for the whole analysis.    

It is important to note that our analysis terminates for any monotonic / functions. Thus, all / functions defined in [18, 6] to model different replacement policies can be directly reused.

4.4 WCET computation

The result of the multi-level analysis gives the worst-case access time of each memory reference to the memory hierarchy. In other words, this analysis produces the contribution to the WCET of each memory reference, which can be included in well-known WCET computation methods [15, 14].

In the formulae given below, the contribution to the WCET of a NC reference at level L is the latency of an access to level L+1, which is safe for architectures without timing anomalies caused by interactions between caches and pipelines, as defined in [8]. For architectures with such timing anomalies (e.g. architectures with out-of-order pipelines), more complex methods such as [7] have to be used to cope with the complex interactions between caches and pipelines.

Name Description Code size
matmult Multiplication of two 50x50 integer matrices 1200
ns Search in a multi-dimensional array 600
bs Binary search for the array of 15 integer elements 336
minver Inversion of floating point 3x3 matrix 4408
jfdctint Integer implementation of the forward DCT (Discrete Cosine Transform) 3040
adpcm Adaptive pulse code modulation algorithm 7740
task1 Confidential 12711
task2 Confidential 12395
Table 2: Benchmark characteristics

We define the following notations: constant represents the cost in cycles of a hit at level (accesses to the main memory are always hits), and to distinguish the first and the successive execution in loops, the binary variables and represent that an access to reference occurs (1) or not (0) at level . Finally, variables and give the contribution to the WCET of a reference at a given point in the program, that can be used to compute the WCET. and are computed as follows:

and are computed as follows:

5 Experimental results

In this section, we evaluate the tightness of our static multi-level cache analysis comparatively to the execution in a worst-case scenario. We also evaluate the extra computation time caused by the analysis of the cache hierarchy. We first describe the experimental conditions and then we give and analyze experimental results.

5.1 Experimental setup

Cache analysis and WCET estimation.

The experiments were conducted on MIPS R2000/R3000 binary code compiled with gcc 4.1 with flag O0. The WCETs of tasks are computed by the Heptane111Heptane is an open-source static WCET analysis tool available at http://www.irisa.fr/aces/software/software.html. timing analyzer [1], more precisely its Implicit Path Enumeration Technique (IPET). The fixpoint analysis is an implementation of the abstract interpretation approach initially proposed in [18]. The Must, May and Persistence analysis are conducted sequentially on a two-level cache hierarchy (L1 and L2 caches), both caches implementing a LRU replacement policy. The analysis is context sensitive (function are analyzed in each different calling context).

To separate the effect of the caches from those of the parts of the processor micro-architecture, WCET estimation only takes into account the contribution of caches to the WCET as presented in Section 4.4. The effects of other architectural features are not considered. In particular, we do not take into account timing anomalies caused by interactions between caches and pipelines, as defined in [8]. The cache classification not-classified is thus assumed to have the same worst-case behavior as always-miss during the WCET computation in our experiments.

The computation time measurement is realized on an Intel Pentium 4 3.6 GHz with 2 GB of RAM.

Measurement environment.

The measure of the cache activities on a worst-case execution scenario uses the Nachos educational operating system222Nachos web site, http://www.cs.washington.edu/homes/tom/nachos/, running on top of a simulated MIPS processor. We have extended Nachos with a two-level cache hierarchy with a LRU replacement policy at both levels.


The experiments were conducted on five small benchmarks and two tasks from a larger real application (see Table 2 for the application characteristics). All small benchmarks are benchmarks maintained by Mälardalen WCET research group333http://www.mrtc.mdh.se/projects/wcet/benchmarks.html. The real tasks are part of the case study provided by the automotive industrial partner of the Mascotte ANR project444http://www.projet-mascotte.org/ to the project partners.

5.2 Results

Precision of the multi-level analysis.

In order to determine the tightness of the multi-level analysis, static analysis results are compared with those obtained by executing the programs in their worse-case scenario. Due to the difficulty to identify the input data that results in the worst-case situation in complex programs, we only use the simplest benchmarks (matmult, ns, bs, minver, jfdctint) to evaluate the precision of the analysis.

Small L1 and L2 instruction caches are used in this part of the performance evaluation in order that the code of most of the benchmarks (except ns and bs) do not fit into the caches. The L1 cache is 1KB large, 4-ways associative with 32B lines. We use two different L2 caches configurations of 2KB 8-ways associative: one with 64B lines and another one with 32B lines.

Benchmark Metrics Static Analysis Measurement Static Analysis Measurement
32B - 64B lines 32B - 64B lines 32B - 32B lines 32B - 32B lines
jfdctint nb of L1 accesses 8039 8039 8039 8039
nb of L1 misses 725 723 725 723
nb of L2 misses 54 49 101 96
cache contribution to WCET
L1+L2, cycles 20689 20169 25389 24869
L1 only, cycles 87789 87789
bs nb of L1 accesses 196 196 196 196
nb of L1 misses 16 11 16 11
nb of L2 misses 15 6 16 11
cache contribution to WCET
L1+L2, cycles 1856 906 1956 1406
L1 only, cycles 1956 1956
minver nb of L1 accesses 4146 4146 4146 4146
nb of L1 misses 150 140 150 140
nb of L2 misses 108 71 150 140
cache contribution to WCET
L1+L2, cycles 16446 12646 20646 19546
L1 only, cycles 20646 20646
ns nb of L1 accesses 26428 26411 26428 26411
nb of L1 misses 23 13 23 13
nb of L2 misses 20 7 23 13
cache contribution to WCET
L1+L2, cycles 28658 27241 28958 27841
L1 only, cycles 28958 28958
matmult nb of L1 accesses 525894 525894 525894 525894
nb of L1 misses 51 41 51 41
nb of L2 misses 49 19 51 38
cache contribution to WCET
L1+L2, cycles 531304 528204 531504 530104
L1 only, cycles 531504 531504

Benchmark Metrics Static Analysis Static Analysis
32B - 64B lines 32B - 32B lines
adpcm nb of L1 accesses 187312 187312
nb of L1 misses 2891 2891
nb of L2 misses 289 297
cache contribution to WCET
L1+L2, cycles 245122 245922
L1 only, cycles 505322 505322
task1 nb of L1 accesses 1872522 1872522
nb of L1 misses 678 678
nb of L2 misses 662 678
cache contribution to WCET
L1+L2, cycles 1945502 1947102
L1 only, cycles 1947102 1947102
task2 nb of L1 accesses 6783 6493
nb of L1 misses 792 796
nb of L2 misses 718 796
cache contribution to WCET
L1+L2, cycles 86503 94053
L1 only, cycles 93903 94053
Table 3: Precision of the static multi-level n-ways analysis (4-ways L1 cache, 8-ways L2 cache. Cache sizes of 1KB/2KB in top table, 8KB/64KB in bottom table).

To evaluate the precision of our approach, the comparison of the hit ratio at the L2 level between static analysis and measurement is not appropriate. Indeed, the inherent pessimism of the static cache analysis at the L1 level introduces some accesses at the L2 level that never happen at run-time. Instead, the results are given in Table 3 using two classes of metrics:


  • The number of references and the number of misses at every level of the memory hierarchy in the worst-case execution scenario (top three lines) to show the behavior of the multi-level cache analysis.

  • The contribution of the memory accesses to the WCET (bottom 2 lines) when considering a cache hierarchy (L1+L2) and when ignoring the L2 cache (L1 only) to demonstrate the usefulness of multi-level analysis. To compute it, we use a L1 hit cost of 1 cycle, a L2 hit cost of 10 cycles and a memory latency of 100 cycles. When considering only one cache level, the memory latency is 110 cycles.

Two types of behaviors can be observed:


  • The first type of situations is when the number of L1 misses computed statically is very close to the measured value (benchmark jfdctint). In this benchmark, the base cache analysis applied to the L1 cache is very tight. As a consequence, the reference stream considered during the analysis of the L2 cache is very close to the accesses actually performed at run-time. Thus, the number of misses in the L2 is also very close to the number of L2 misses occuring during execution. In this case, the overall difference between static analysis and execution is mainly due to the pessimism introduced by considering the cache hierarchy (classification as of every access that cannot be garanteed to be or not to be in the L1).

  • The second type of situations occurs when the static cache analysis at L1 level is slightly less tight. Then, this behavior is also present at the L2 level and it is increased by the introduction of the accesses. In this case, the multi-level analysis is still tight enough. Moreover it turns out that a lot of accesses, not detected as hits by the L1 analysis, can be detected as hits by the L2 analysis. The resulting WCET is thus much smaller than if only one level of cache was considered.

Figure 5: Computation time with a 64KB and a 128KB L2 cache

For the largest codes (adpcm, task1, task2), only results of static cache analysis are given (measurements are not realized due to the difficulties to execute these tasks in their worst-case execution scenario). Since code size of these three tasks is larger than of the simple benchmarks, the cache size is now larger and more realistic than the one considered before. We use a 8KB large L1 cache and a 64KB large L2 cache with the same cache line sizes and associativity as before.

We can notice the rather low number of cache hits in the L2 with the L2 cache with 32B lines. This explains by the size of loops in the applications as compared to the L1 cache size. In all tasks but adpcm, the code of the loops entirely fits into the L1 cache and thus there is no reuse once a piece of code gets loaded into the L2 cache. When the cache line size in the L2 cache is larger, the number of hits increases significantly, due to the spatial locality of applications.

In summary, the overall tightness of the multi-level cache analysis is strongly dependent on the initial cache analysis of [18]. In all the cases: the extra pessimism caused by our multi-level analysis for the sake of safety (introduction of accesses) is reasonable, considering the cache hierarchy generally results in much lower WCETs comparatively to considering only one cache level and an access to main memory for each miss.

Computation time evaluation.

The analysis time is evaluated on a two-level cache hierarchy, using the three largest codes (adpcm, task1, and task2) and the same cache structures as before. What we wish to evaluate is the extra-cost for analysing the second level of cache comparatively to a traditionnal cache analysis of only one level. The extra-analysis time mainly depends on the number of references considered when analysing the L2 cache, which itself depends on the size of the L1 cache (the larger the L1, the higher the number of references detected as hits in the L1 and thus the lower the number of references considered in the analysis of the L2). Thus, we vary the size of the L1 (4-ways and cache lines of 32B) from 1KB to L2 cache size.

Figure 5 details the results for 64 KB (32B and 64B line) and 128 KB (32B and 64B line) L2 caches respectively. The X axis gives the L1 cache size in KB. The Y axis reports the computation time in seconds.

The shape of the curves are very similar for each used benchmark and each L2 cache size tested. The computation time for analysing the L1 cache increases with the size because of the inherent dependency of single-level cache analysis to the cache size. However, the computation time increase is not always monotonic, like for instance for benchmark adpcm. This non-monotonic behavior comes from a variation of the number of iterations in the fixpoint computation present in the single-level cache analysis. In contrast, the analysis time of the L2 cache decreases when the L1 cache is increased: as the L1 cache filters more and more memory references, the number of accesses to the L2 cache considered in the analysis are reduced (more and more accesses become access).

The proposed multi-level cache analysis introduced an extra computation cost for accesses to explore the two possible behavior of uncertain accesses. It can be observed that this extra cost is not visible because it is masked by the filtering of accesses.

When the L2 cache size is 128 KB the slope of the L2 curve is lower than for a 64 KB cache. This is due to the incompressible time needed for single-level cache analysis of the L2 cache, dependent on the L2 cache size, which masks the filtering effect of the L1 cache. Nevertheless even in this case the computation time is reasonable.

To conclude, the computation time required for the multi-level set-associative cache (L1 + L2) analysis is significant but stays reasonable on the case study application.

5.3 Discussion

The safety issue of [10] is hard to detect on existing codes because of the pessimism introduced by the cache analysis at the first cache level which masks the WCET underestimation caused by the safety issue and the difficulties to execute tasks in their worst-case condition. We have implemented the counterexample presented in Section 3 which demonstrates that this phenomenon occurs in practise.

The experiments were undertaken with a LRU replacement policy at each level of the cache hierarchy. Nevertheless, the modification of the function is done at a high level and is independent from any cache replacement policy.

Finally, experiments were conducted by considering two levels of caches. We did not present experiments with a L3 cache due to the difficulty of finding large enough publically available codes. Nevertheless, our method allows the analysis of a cache hierarchy with more than two levels.

6 Conclusion

In this paper we have shown that the previous method to analyze multi-level caches for real-time systems [10] is unsafe for set-associative caches. We have proposed a solution to produce safe WCET estimations of set-associative cache hierarchy whatever the degree of associativity and the cache replacement policy. We have proven the termination of the fixpoint analysis and the experimental results show that this method is precise in many cases, generally tighter than considering only one cache level, and has a reasonable computation time on the case study. In future research we will consider unified caches by using for instance partitioning techniques to separate instruction from data, and we will extend this approach to analyze cache hierarchies of multicore architectures.


  • [1] A. Colin and I. Puaut. A modular and retargetable framework for tree-based WCET analysis. In Proceedings of the 13th Euromicro Conference on Real-Time Systems, pages 37–44, Delft, The Netherlands, June 2001.
  • [2] P. Cousot and R. Cousot. Abstract interpretation: a unified lattice model for static analysis of programs by construction or approximation of fixpoints. In Conference Record of the Fourth Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pages 238–252, Los Angeles, California, 1977. ACM Press, New York, NY.
  • [3] P. Cousot and R. Cousot. Basic Concepts of Abstract Interpretation, pages 359–366. Kluwer Academic Publishers, 2004.
  • [4] C. Ferdinand, R. Heckmann, M. Langenbach, F. Martin, M. Schmidt, H. Theiling, S. Thesing, and R. Wilhelm. Reliable and precise WCET determination for real-life processor. In EMSOFT ’01: Proceedings of the First International Workshop on Embedded Software, volume 2211, pages 469–485, Tahoe City, CA, USA, Oct. 2001.
  • [5] S. Ghosh, M. Martonosi, and S. Malik. Cache miss equations: a compiler framework for analyzing and tuning memory behavior. ACM Trans. Program. Lang. Syst., 21(4):703–746, 1999.
  • [6] R. Heckmann, M. Langenbach, S. Thesing, and R. Wilhelm. The influence of processor architecture on the design and the results of WCET tools. Proceedings of the IEEE, vol.9, n®7, 2003.
  • [7] X. Li, A. Roychoudhury, and T. Mitra. Modeling out-of-order processors for wcet estimation. Real-Time Systems Journal, 34(3), Nov. 2006.
  • [8] T. Lundqvist and P. Stenström. Timing anomalies in dynamically scheduled microprocessors. In IEEE Real-Time Systems Symposium, pages 12–21, 1999.
  • [9] F. Mueller. Static cache simulation and its applications. PhD thesis, 1994.
  • [10] F. Mueller. Timing predictions for multi-level caches. In ACM SIGPLAN Workshop on Language, Compiler, and Tool Support for Real-Time Systems, pages 29–36, June 1997.
  • [11] F. Mueller. Timing analysis for instruction caches. Real-Time Syst., 18(2-3):217–247, 2000.
  • [12] H. S. Negi, T. Mitra, and A. Roychoudhury. Accurate estimation of cache-related preemption delay. In CODES+ISSS ’03: Proceedings of the 1st IEEE/ACM/IFIP international conference on Hardware/software codesign and system synthesis, pages 201–206, New York, NY, USA, 2003. ACM.
  • [13] I. Puaut. WCET-centric software-controlled instruction caches for hard real-time systems. In Proc. of the 18th Euromicro Conference on Real-Time Systems, Dresden, Germany, July 2006.
  • [14] P. Puschner and C. Koza. Calculating the maximum execution time of real-time programs. Real-Time Syst., 1(2):159–176, 1989.
  • [15] P. Puschner and A. V. Schedl. Computing maximum task execution times – a graph based approach. In Proceedings of IEEE Real-Time Systems Symposium, volume 13, pages 67–91, 1997.
  • [16] H. Ramaprasad and F. Mueller. Bounding worst-case data cache behavior by analytically deriving cache reference patterns. In RTAS ’05: Proceedings of the 11th IEEE Real Time on Embedded Technology and Applications Symposium, pages 148–157, Washington, DC, USA, 2005. IEEE Computer Society.
  • [17] J. Staschulat, S. Schliecker, and R. Ernst. Scheduling analysis of real-time systems with precise modeling of cache related preemption delay. In ECRTS ’05: Proceedings of the 17th Euromicro Conference on Real-Time Systems, pages 41–48, Washington, DC, USA, 2005. IEEE Computer Society.
  • [18] H. Theiling, C. Ferdinand, and R. Wilhelm. Fast and precise WCET prediction by separated cache and path analyses. Real-Time Syst., 18(2-3):157–179, 2000.
  • [19] X. Vera, B. Lisper, and J. Xue. Data caches in multitasking hard real-time systems. Cancun, Mexico, 2003.
  • [20] R. White, F. Mueller, C. Healy, D. Whalley, and M. Harmon. Timing analysis for data caches and set-associative caches. In RTAS ’97: Proceedings of the 3rd IEEE Real-Time Technology and Applications Symposium, pages 192–202, June 1997.

Comments 0
Request Comment
You are adding the first comment!
How to quickly get a good reply:
  • Give credit where it’s due by listing out the positive aspects of a paper before getting into which changes should be made.
  • Be specific in your critique, and provide supporting evidence with appropriate references to substantiate general statements.
  • Your comment should inspire ideas to flow and help the author improves the paper.

The better we are at sharing our knowledge with each other, the faster we move forward.
The feedback must be of minimum 40 characters and the title a minimum of 5 characters
Add comment
Loading ...
This is a comment super asjknd jkasnjk adsnkj
The feedback must be of minumum 40 characters
The feedback must be of minumum 40 characters

You are asking your first question!
How to quickly get a good answer:
  • Keep your question short and to the point
  • Check for grammar or spelling errors.
  • Phrase it like a question
Test description