This page provides an overview of unsupervised AMP configurations for both =
Zynq-7000 and Zynq UltraScale+ MPSoC.
Table of Contents
Unsupervised AMP
Unsupervise=
d AMP refers to a concept where multiple operating systems or bare-metal ap=
plications run on individual CPU cores within a CPU-core cluster without an=
underlying hypervisor. Additional description can be found at
OpenAMP GIT
Developers hope that these unsupervised solutions will be easier to impleme=
nt, provide higher performance and more flexibility than solutions which re=
ly on hypervisors. However, as we'll discuss below; these perceptions are c=
losely dependent on the hardware capabilities of the host processor.
Unsupervised AMP on=
Arm Cortex A9
The level of support and documentation for unsupervised =
AMP by ARM, Xilinx, and other silicon vendors varies as described below.
Arm (Cortex A9)
As shown by the excerpts below from the
ARM Reference Manu=
al for Cortex A9 some capabilities were incorporated within Cortex A9 I=
P in anticipation of unsupervised AMP configurations. Although the IP has b=
een incorporated, the only Arm posting that we've been able to find on this=
subject can be found here:
ARM F=
orum on Cortex A9 AMP
Xilinx (Cortex A9)
The Xili=
nx bare-metal application flow is fully supported by Xilinx-provided driver=
s and libraries as well as our development tools and a significant percenta=
ge of our customers deploy systems with bare-metal applications on Zynq-700=
0 based designs. In response to those customers who wanted AMP capabilities=
, we provided the 2013 application notes linked below:
From 2016 until present, Xilinx has extended our solutions to leverage the =
OpenAMP framework which leverages existing Linux software and services for =
both life-cycle management and communications between the two Zynq-7000 cor=
es. These details may be found within the
UG1186 Zynq OpenAMP Getting Sta=
rted Guide
Other Silicon Vend=
ors (Cortex A9)
In approximately 2014=
, a company named Embest offered an AMP solution for a subset of =
commercially available SoCs based on Cortex A9 that was very similar to the=
application notes provided by Xilinx. The engineer who did that AMP work r=
ecently communicated to us that he is available to do similar work from his=
current company Sihid Technology for Xilinx Zynq-7000 devices (see the pag=
e in Chinese or the English Translation from Google<=
span data-colorid=3D"z6d5e8objo"> )
Unsupervised AMP on C=
ortex A53
Summary: Unsupervised AMP on Cortex A53 is n=
either recommended nor supported.
Arm (Cortex A53)
Although sec=
tion 14.1.5 of the
ARM Cortex-A Series Programmer=E2=80=99s Guide for ARMv8-A does =
indicate that unsupervised AMP is a valid system configuration, we are unaw=
are of any other publicly accessible documentation, forums or information w=
hich addresses how such an AMP configuration might be designed or implement=
ed. In addition, unlike the
ARM Cortex A9 reference manual (excerpted above), the t=
erm "AMP" does not appear anywhere within the 6500 pages of the
ARM v8-A Reference Manu=
al . Finally, we are not aware of any public forums or posts regarding =
unsupervised AMP on ARM v8 SoCs.
Xilinx (Cortex A53)
While =
we know from our customer's experience that it is technically possible to r=
un AMP on individual cores of the Cortex A53 cluster for their very tightly=
-constrained use-cases. However, such configurations face difficult and req=
uirement/design-specific challenges. Because the variability is so high mak=
ing a general-purpose, unsupervised AMP configuration impossible, Xilinx is=
unable to directly support customers who wish to deploy unsupervised AMP c=
onfigurations across the Zynq UltraScale+ MPSoC APU. The following points e=
laborate on this topic:
- The R5 cores of the Zynq UltraScale+ MPSoC are designed for independent=
or lockstep operation
- The Cortex-A53 cluster does not have such proven capability
- Xilinx supports the standard ARM v8-A programming model where a fully f=
eatured OS such as Linux is expected to run at EL1 on ARM Trusted Firmware =
(ATF) at EL3.
- Xilinx has not done any work on unsupervised AMP configurations
- All bare-metal applications are tested and supported by Xilinx on the A=
PU to run only on a single A53 CPU and directly at EL3 (e.g. without ATF).<=
/li>
- Xilinx has not tested the execution of EL1 bare-metal applications dire=
ctly on top of ATF
- There are many possible pitfalls running multiple bare-metal applicatio=
ns directly on the A53 cores (cache trashing, cache operations, starvation,=
deadlocks, livelocks, etc)
We believe that ready access to hypervisors (See:
3rd Party Software Ecosystem) and the availability of the ARM v8-=
A hardware virtualization extensions address these same challenges much mor=
e simply and elegantly while bringing additional benefits related to platfo=
rm maintenance as well as isolation and security.
See
UG1228 UltraFast Embedded Design Methodology Guidefor=
additional details.
AMP Considerations (Cortex A53)
In recognition =
that some customers may
still be interested to develop their own i=
n-house, unsupervised AMP configurations, below we have highlighted some ke=
y considerations and questions that Xilinx has considered to come to our de=
cisions above. These may assist developers to better understand the challen=
ges and to define the shortest path to a viable system architecture.
- Interrupts
- What interrupt(s) are used by each application?
- Interrupt response latency
- I/O latency
- Determinism
- Interrupt Controller managment
- Which application/OS will initialize and manage the interrupt controlle=
r?
- Cache
- Is cache coherency between applications/OS required?
- What flush, invalidate modifications do the individual applications/Ope=
rating systems make to the cache controller?
- What interactions between application/OS instances will affect cache?=
li>
- MMU
- How does each application use the MMU?
- Does this application change TLB attributes?
- Power Management
- Does any application make changes to the power state of the device?
- Clocking
- Does any application make changes to the clocking in the device?
- Peripherals
- Which peripherals are dedicated to each application/OS?
- Include PS, PL, and CPU-specific IP such as timers
- Are there any shared peripherals?
- Interrupt controller, timers, clocks, MMU, etc.
- Cross Application/OS Communications
- Does any application/OS communicate with another application/OS?
- Device or cache-able memory?
- DMA
- Does any application use DMA?
- System Reset(s)
- Does any application/OS need to reset anything?
- Dynamic Operations
- Does the application/OS need to bring up and down the CPU
- Even while another CPU continues to run?