Bureaucrats, dave_user, Administrators
4,650
edits
Changes
→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. In principle the approach that has been adopted allows to implement different strategies related to L2 cache management. The actual configuration that has been used to conduct the tests described in [[Characterization and performance tests|this section TBD ]] assigns the whole L2 cache to the W2 world, as depicted in the following picture.
<span id="L2 cache usage"></span>
* 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. However , enabling L2 cache for W1 may improve its computational performance but, in general, reduces real time determinism as 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 usually tightly coupled to the ARM core and has , providing access performance performances that can be compared with are comparable to L2 cache. Thus This allows to leverage it can be leveraged to compensate for the unavailability of itL2 memory.
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 significantly but may waste precious L1 memory lines).
==Characterization and performance tests==
