The multiplication of the number of cores inside embedded systems has raised the pressure on the memory hierarchy. The cost of coherence protocol and the scalability problem of the memory hierarchy is nowadays a major issue. In this paper, a speci c data management for read-only data is investigated because these data can be duplicated in several memories without being tracked. Based on analysis of standard benchmarks for embedded systems, this analysis shows that read-only data represent 62% of all the data used by applications and 18% of all the memory accesses. A speci c data path for read-only data is then evaluated by using simulations. On the rst level of the memory hierarchy, removing read-only data of the L1 cache and placing them in another read-only cache improve the data locality of the read-write data by 30% and decrease the total energy consumption of the rst level memory by 5%.
As demands for higher performance keep growing,
multicore systems have become popular in embedded systems.
Memory system design is a critical problem for multi-core
embedded systems. With the increasing number of cores,
the cost of adopting hardware-controlled caches and
ensuring coherency in embedded systems becomes extremely high.
There are two reasons for this cost increase. Firstly, the
power overhead of automatic memory management in
memory caches is growing prohibitively. It represents almost half
of the overall energy for a single-processor [
Two basic memory models are used for the memory [
Data are used in a read-only way either for the whole application execution like input data, or for a limited scope such as a function, or a kernel. In the latter case, read-write data are in a read mode for a long time during the application's execution. The memory accesses of these data may also bene t from this speci c memory organization. A data transfer cost between the two data paths must be considered in this case.
The long term perspective is to propose an architecture where read-only data are removed from the original memory hierarchy and are managed in a di erent memory organization. This idea is similar to the one in Harvard architecture where instruction and data are handled in di erent memories. This new memory subsystem would be added in parallel to a classic memory system, and optimized for read-only data. This solution aims to be transparent for the user and generic to embedded systems. In order to use this system transparently, some steps are to be considered during compilation. The compiler has to detect read-only data, and may use some user information, such as those provided in parallel languages like OpenCL, or OpenACC.
This study considered several scenarios where read-only data are removed from the original memory organization and handled in a di erent one. The special management of read-only data is not optimized yet and will be considered in future work. Firstly, read-only data are detected and quanti ed for a whole set of applications. Secondly, by using simulation, di erent data management are tested and compared in terms of energy consumption and data locality. The rest of the paper is organized as follows: Section 2 describes a quanti cation on read-only data. In Section 3, several scenarios of memory access separation are introduced. These scenarios are compared in terms of data locality in Section 4 and in terms of energy consumption in Section 5. Finally, related works are discussed in Section 6.
The rst step of the evaluation is to show that read-only data
count for a signi cant part of the working set of applications
in embedded systems. This analysis is a trace-driven
analysis on the standard Mibench benchmark [
The generation of the trace le is achieved by Maqao [
The analysis results are shown in Fig.1. On average, 62% of used data are in a read-only state but they represent only 18% of the accesses made by the application. The proportions of read-only data and the number of accesses are very asymmetrical. It could be partially explained by the fact that the stack is not removed from the analysis. The data in the stack represent few data, but the same stack addresses are used many times. Intuitively, this asymmetry between access proportion and data proportion suggests that readonly data are not reused as much as other data and can cause some pollution in the memory systems.
This simple analysis shows that read-only data count for a signi cant proportion of data used by applications in embedded systems. It is important enough to consider some speci c memory hierarchy optimizations for these data. In the following sections, the data path separation between readonly and read-write data is studied.
In order to explore the possibility of adding speci c data path in the memory hierarchy for read-only data, memory accesses are divided in several categories. Two scenarios of memory access separation are tested on simulation and analyzes are performed for comparison between those scenarios.
For this study, memory accesses are classi ed as follows: 1) accesses to read-only data, 2) accesses to detected read areas or 3) accesses that do not belong to one of the two previous categories. Read areas are de ned as a group of read accesses which are not separated from each other by write accesses in
time and address directions. This corresponds for instance to a read access to an array region. Read areas are detected on read-write data and cannot include accesses to read-only data so an access belongs to only one of three categories de ned previously. The concept of read areas is introduced in order to place in the speci c read-only memory, readwrite data that present read-only behavior during execution. For example, read areas can be detected with intermediate results of an algorithm that are generated (written) rst and then read for the rest of the algorithm.
For a better understanding, an example of this classi cation is shown in Fig. 2. It represents the accesses made by an application during the rst time frames. The data set is composed of 7 distinct data (A, B, C, D, E, F, G). All the data are initialized (written) in the rst time frame. Then, A,B and C are only read (never written to) so they are considered as read-only data and all accesses to these A,B,C belong to the rst category. Then, the area detection algorithm is launched on the remaining accesses and one read area is detected, the accesses in the dark green area in Fig. 2 belongs to the second category. All other accesses belongs to the third category.
A minimal size for the detected area is xed for two main reasons. First, if this limit is not set, every read memory access can be considered as a read area on its own. Second, the proposed detection focuses on big areas of read access with data reuse, detecting data structures or data regions more than individual data accesses. After experimentations, read areas are kept for this study only if more than 128 memory accesses are done on this area. According to the de ned classi cation, on Mibench benchmarks, the repartition shows that on average, 17.8% of all memory accesses are accesses to read-only data and 6.9% are accesses to read areas. The remaining 75.3% of the memory accesses are not concerned by the solution.
As mentioned in the introduction, the possibility of adding a new data path along the memory hierarchy speci c for the read-only data is studied. All the other data use a classic cache hierarchy. The instructions are not considered in these simulations and are supposed to be handled in a di erent memory organization. The impact of adding this speci c memory is studied on the rst level of memory hierarchy. Fig. 3 shows three di erent scenarios studied in this anal1 2 3 4 5 6 7 8 9 10 11 12 13 14 Time7Frame CPU
- Read-write access Scenario 1 - Read-only access (Reference) - Read areas access ysis. Scenario n 1 is the reference scenario where there is no speci c management for the read-only data and all the categories of access use the classic cache memory organization. In scenario n 2, accesses to read-only data are removed from the classic way and are handled in the speci c memory. Scenario n 3 is the same as scenario n 2, but the read areas accesses are also placed in the speci c memory. Since read areas are detected on read-write data, the data in read areas take both paths depending on the timing. During simulations, the speci c memory is modeled as a simple memory cache. In order to simulate these scenarios, ve memory traces are generated, one for each memory of each scenario. The original full trace of the application is used for the scenario n 1 as a reference. For scenarios 2 and 3, partial memory traces are generated from the original trace, accesses are removed according to the data management policy, in order to form the memory access ow for each memory. If no read area is detected, scenarios 2 and 3 are the same. This case happens for 10 out of 26 benchmarks tested. The L2 cache is uni ed for all the data. For the rest of the paper, the rst level cache for read-only data will be called the RO cache and the rst level cache for read-write data will be called RW cache. In the following section, two analysis are presented, a data locality analysis and an energy consumption analysis, to compare these scenarios.
Data locality is important in order to take advantage of CPU caching. The data locality can be evaluated by the stack distance which is computed for all scenarios on all benchmarks.
The stack distance [
To allow a meaningful comparison of di erent scenarios, the average stack distances are always compared separately for read-only and read-write data. Three steps are followed for the analysis: In a rst step, for each application of Mibench, the stack distances are computed on the full memory trace of the scenario 1. Once the stack distances are computed for all accesses, the average stack distance is computed separately for accesses to read-only data and accesses to read-write data (read area accesses are included in the accesses to read-write data). For all the applications, the average stack distance of read-only data is 16 times higher than the average stack distance of read-write data. So, the di erence of locality is very signi cant, and means that read-only data are less reused and pollute the classic L1 cache.
In a second step, the values of the stack distances computed previously are compared to the stack distance of scenario 2. The variation of the stack distance for read-only data and read-write data between the scenario 1 and 2 are shown in Fig. 4. The decrease of the stack distance for scenario 2 is expected because separating data always leads to global data locality improvement. The reason is that in each way of the hierarchy, the number of accesses between two calls to a same data is reduced. For the RW cache, only 18% of the accesses are removed and the stack distance is reduced by 30% and for read-only data, 82% of the access are removed and stack distance is reduced by 38%. This is asymmetric between the number of removed accesses and the decrease of the stack distance. Separating read-only and read-write data improves signi cantly the read-write data locality. In a third step, a metric is introduced in order to compare the locality between all the scenarios. For the scenario 1, the average stack distance of the full trace is computed without data distinction. For scenario 2 and 3, a weighted sum is computed by adding average stack distances for read-only and read-write data in proportion of their respective number of accesses. It gives a comparable global stack distance for each scenario. The Fig. 5 shows the variation of the global stack distance of scenario 2 and 3 compared to scenario 1. On average, the global stack distance is improved by 19% for the scenario 2 and 30% for the scenario 3. For almost every application, the data separation improves the overall locality.
These results suggest that it is pro table to separate the read-only and read-write data in terms of data locality. The following section studies the proposition with respect to energy consumption.
The main motivation of this work is to reduce the energy consumption of the memory hierarchy. An energy model is introduced and the three scenarios are simulated to compute energy consumption. On the contrary to the stack distance, this analysis depends on the hardware.
The energy consumption of the cache is computed with a
simple energy model. The CPU is not modeled and the
study focuses only on the dynamic energy of the rst level
memories of the memory hierarchy. For each cache, the
dynamic energy consumption is determined as follow:
DynEnergyCache = energyP erAccessCache nbHitsCache
+energyM iss nbM issCache
energyM iss = energyP erAccessL2 + energyCPUStall
+energyCacheBlockFill
(1)
The underlined terms are ignored for the moment. The
energyCPUStall is the energy consummed when the CPU
is stalled while waiting for the memory system to provide
data and the energyCacheBlockFill is the energy for writing
a block into the cache. The energyPerAccessL1 and
energyPerAccessL2 are determined with Cacti v6.5 [
The energy consumption of all the applications of the Mibench benchmarks is studied. To simulate with dineroIV and Cacti the described scenarios, cache designs have to be chosen. First, the scenario 1 is explored extensively in order to determine the most e cient design of the classic cache. The cache's design that minimizes the average energy consumption on Mibench is a cache of 16KB with 2-way set associativity. The energy consumption of the scenarios 2 and 3 is compared to this reference. To do a fair comparison between scenarios, an equivalent storage size at the rst level of the memory hierarchy for each scenario has to be used. In Section 4, it has been pointed out that read-only data have a weak locality, it suggests that the RO cache must have an important size relatively to the number of memory access it will handle. The choices for the design for the RW cache and the RO cache are shown in Table 1. All the applications are simulated independently in the cache, and the energy consumption model gives the total energy consummed by each application for the rst level memories. The energy consumption of each application is then added to get the total energy consumption foFerr each scenario of all the Mibench applications.
Creating a two caches system instead of one has two consequences on the energy consumption. The resources are Variation Scenario 2 Locality Variation Scenario 3 Locality 0,20 )e 0,16 l u o (J itno 0,12 p m u sn 0,08 o C y g r en 0,04 E 0,00 RO Cache RW Cache Scenario 1 not mutualized so some of them can be underutilized leading to energy consumption increase. On the other hand, a good data separation decreases the pollution in each cache which reduces energy consumption. For each application of the Mibench benchmark, the generated memory traces are simulated through dineroIV and the energy consumption is computed for each application. Then, the energy consumption of each application is added for each scenario. As shown in Fig. 6 energy consumptions in scenarios 2 and 3 are approximately the same. There is an improvement of 6.5% of energy for scenario 2 and 5.0% for scenario 3 compared to the scenario 1. It shows that read-only data can be handled in a di erent memory without adding energy overhead. Indeed, even with conventional caches for the speci c readonly memory, there is no overhead when dividing L1-cache. For scenario 3, the cost of switching read accesses between the RW and the RO cache has been ignored for the moment so the energy consumption for scenario 3 is probably under-evaluated compared to a real situation.
Proposing special memories on the hierarchy to manage
speci c data is not new. A lot of solutions have been proposed
in literature to automatically use scratchpads memories for
speci c data management. The rest of the data, are often
accessed directly through main memory or can go through
a cache parallel to the scratchpad. Some examples could be
found for the heap [
Partitioning cache is another technique that allows speci c
data management. The solution proposed in [
The speci c data management of read-only data is not widely
studied in literature. Some solutions have been proposed
like in the Fermi and Kepler [
The paper has an analysis of the opportunity to handle in di erent caches, data that is read-only, either for the whole application or a limited amount of time. The results show that there are some optimization potentials for speci c data management for read-only data. Even if the memories where read-only data are placed do not yet exploit the read-only property, simulations show that the division between read-only and read-write data on the rst level of memory hierarchy improves the data locality (in average, 30% on Mibench benchmarks) and does not introduce energy consumption overhead. The main interest of exploiting read-only data appears in a multi-core environment, since they can be shared without being handled by a costly coherence protocol. The future work will focus on optimizing the read-only sub-hierarchy in an actual multi-core environment. Furthermore, the impact of compiler on the detection of read-only data and read areas need to be evaluated.