Changes

Jump to: navigation, search
L2 cache management
<ref name="XAPP1078"> John McDougall, ''XAPP1078 (v1.0) Simple AMP Running Linux and Bare-Metal System on Both Zynq SoC Processors'', 14th February 2013</ref> and
<ref name="XAPP1079">John McDougall, ''XAPP1079 (v1.0.1) Simple AMP: Bare-Metal System Running on Both Cortex-A9 Processors'', 24th January 2014</ref>,
L2 cache - in contrast to L1 - is a shared resource in Zynq implementation. As such, in case both cores have to use it, specific techniques have to be implemented to handle it properly in dual-OS AMP configuration. The solution here described In principle the approach that has been adopted allows to flexibly enable and configure implement different strategies related to L2cache management.  By carefully configuring MMU and The actual configuration that has been used to conduct the tests described in section TBD assigns the whole L2 cache initialization, is possible to use it in the W2 onlyworld, the final setup is described as depicted in the following picture.
<span id="L2 cache usage"></span>
[[File:Bora-wp001 01 v2-L2cache.png|thumb|center|400px|L2 cache usage]]
In this wayThis configuration has been chosen for several reasons:
* Linux performance are not affected by this dual-OS solution when accessing it's private memory
* FreeRTOS determinism is granted, because is using only non-shared resources (excluding the SOC L3 bus)
* access to shared memory is uncached or only L1 cached (the latter forces SCU SMP mode usage).For sake of completeness, it is recalled that it is also possible to enable L2 cache in W1 too, without breaking [[#REQ5|REQ5]] because ARM PL310 L2 cache controller support the TrustZone technology and does not allow the non-trusted OS (W2) to access trusted OS (W1) cached data. Enabling However enabling L2 cache for W1, highly may improve its computational performance but also reduce , in general, reduces real time determinismas well. In case L2 cache unavailability on W1 side is unacceptable, on-chip memory (OCM) can come to help to mitigate this kind of issue
====Leveraging OCM====
The use of L1 and L2 is strictly related to performance of ARM cores. There's also another precious resource that can increase core performance without affecting determinism, which is the OCM.
In SOCs, usually OCM is placed very close to the ARM core and has access performance that can be compared with L2 cache. Thus it can be leveraged to compensate for the unavailability of it.
The most common scenario is to:
* restrict OCM access to W1 only (again, this can be done with TrustZone)
* move the most ''latency sensitive'' code{{efn|usually vectors and ISRs}} inside its memory ranges
* prevent this memory range to be L1-cached (because this usually does not increase the performance so much and waste precious L1 memory lines).
==Characterization and performance tests==
4,650
edits

Navigation menu