The primary component in implementing the system-wide isolation is the AMBA3 AXI compliant bus matrix, which connects all of the system components together. ARM provides this in the PrimeCell High-Performance Matrix product, PL301.
To support the requirements placed on modern SoC infrastructure, the AXI bus generator is complemented by a range of support components. Register slices for timing isolation, width scaling downsizers for reducing bus width to low bandwidth SoC regions, and synchronous or asynchronous bridges for linking clock domains are all available:
PrimeCell Infrastructure AMBA3 AXI Register Slice - BP130
PrimeCell Infrastructure AMBA3 AXI Downsizer - BP131
PrimeCell Infrastructure AMBA3 AXI to AXI Bridges - BP132-4
In a typical ARM system most peripherals are connected to the APB bus. APB is a simpler, lower power, bus than the main AXI bus. The APB protocol does not carry the bits related to the TrustZone security state of the bus transactions. This makes it possible for existing peripheral designs to used on the AMBA3 APB bus, and places responsibility for managing the security state onto the AXI-to-APB Bridge that provides the interface between the high-speed AXI domain and the low-power APB domain.
Each AXI-to-APB bridge provides an AXI slave interface and can mediate accesses for up to 16 peripherals on its local APB bus. The bridge contains address decode logic that generates the APB peripheral select based on the incoming AXI transaction. The bridge includes a single TZPCDECPROT input signal for each peripheral that is located on the bus. This signal is used to determine if the peripheral is configured as Secure or Non-secure; the bridge will reject Non-secure transactions to Secure peripheral address ranges.
These bridge input signals can be tied persistently at synthesis time or can be dynamically controlled via a trusted peripheral, such as the TrustZone Protection Controller (TZPC), to allow dynamic switching of security state at run-time.
Figure 4.1 shows an AXI-to-APB bridge controlling 4 peripherals. The TZPC is configured as always Secure, the Timers and Real-Time Clock (RTC) as always Non-secure, and the Keyboard and Mouse Interface (KMI) has a programmable security state under software control. Secure world software can program the TZPC at run-time to change the signal input to the AXI-to-APB bridge to switch the KMI from Secure to Non-secure or visa versa.
Shaded blocks in the diagram represent Secure peripherals, and blocks with a shaded corner represent peripherals which may be switched from Secure to Non-secure.
This design allows peripherals to exist in the Normal world for most of the time, but lets them be temporarily switched into the Secure world for a short duration. The KMI peripheral is a good example; it will commonly be used as the general purpose Normal world keypad, but might be switched to become a Secure input device for a short period to allow the entry of a user password in a safe environment. As this figure also shows, the addition of the TZPC allows other signals on the SoC to be controlled dynamically, for example the SPIDEN debug control input to the ARM core.
The AXI-to-AHB and AHB-to-AXI bridges allow two subsystems which implement the AMBA3 and AMBA2 specifications to be joined together. A separate bridge is needed for each direction of communication; the AXI-to-AHB bridge allows an AXI transaction to master on the AHB bus, and the AHB-to-AXI bridge allows an AHB transaction to master on the AXI bus.
The AHB bus does not provide any mechanism to carry the security state of the memory transactions that pass across it, so all of the security implementation must be managed in the bridge itself.
The AXI-to-AHB bridge allows the whole of the AHB slave domain to be made either Secure or Non-secure.
The AHB-to-AXI bridge allows the whole of the AHB master domain to be made either Secure or Non-secure.
If a design requires a mixture of Secure and Non-secure AHB masters and slaves it is recommended that Secure components and Non-secure components are never placed behind the same bridge.
The security within the AHB domain is managed entirely by the AHB configuration and is outside of the scope of the Security Extensions.