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.

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.

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.

* 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).

With the system configured as described above, we run some basic test to verify if and how the non real-time world may influences the real-time world. We did the following tests:* About Linux side, two load conditions have been considered:** idle** Google stressapptest (SAT for short) <ref name="SAT">https://code.google.com/p/stressapptest/"</ref>, stressing running to stress SDRAM memory and SD I/O.* About RTOS side:** idle** memory intensive task; two subcases, in turn, have been considered to evaluate the impact of the L2 cache unavailability.

The RTOS memory task access an array in main memory of two different sizesizes:

* the larger is 4 times the L1 size(128KiB)

* program programs PS TTC timer as freerun, triggering an interrupt on overflow* inside the overflow ISR it read the TTC counteris read: this counter reports the number of ticks passed elapsed between the event (overflow) and the handler itself, in other words our the interrupt latency* after a while the TTC is reprogrammed and interrupt is enabled again, to trigger another event* those ''latency countercounters'' are collected into an array* the Linux-side application, by default after 10 seconds, stop stops the RTOS task which sends the array data over RPMSRPMsg* the Linux-side application collect collects the data and display the mininum, maximum and average latency measured

The following table summarize the test results(all timing are given in ''ns'')

! rowspan="2"| Lantecy !! Linux idle<br/>RTOS idle !! Linux SAT<br/>RTOS idle !! Linux SAT<br/>RTOS 16k !! colspan="3" | Linux SAT<br/>RTOS 128k

[[FileThe following conclusions can be drawn from the test results:TBD.png|thumb|center|200px|caption]]===Isolation vs performances===This work confirmed the need to find a trade* Real-off between two requirements that often push in opposite directions: isolation and performances. On one hand isolation should be pushed to the maximum possible extent to preserve the integrity timeness of W1 worldrealm is preserved in any condition, since Linux activity on CPU/memory/SD virtually has no influence on RTOS latency. On the other hand, overall systems performances have not to be affected so much that the product gets unusable* Moderate RTOS activity has no impact on latency. Generally speaking* As expected, strong isolation negatively impacts performancesin case intensive memory activity is performed on RTOS side, so finding the optimal balancing is not trivial. A "one size fits all" solution does not exist and system designer is responsible to choose which direction this knob has to be moved. This analysis naturally has to take into account application-specific requirementsdata/instruction cache misses increase significantly resulting in higher latency.

[[FileFuture work will first focus on an additional feature that has not been included in the requirement list but that is undoubtedly useful in several applications. We are referring to the possibility of performing a complete reboot of the GPOS under the control of the RTOS, while this keeps operating normally. For instance this can be exploited when the RTOS needs to work as software watchdog for W2 activity:TBDin case no activity is detected for a certain period of time, GPOS can be shutdown and rebooted.png|thumb|center|200px|caption]]