Note: The Isolation feature in PCW is supported for parts with ES2 and above. PCW does not support isolation for parts with ES1.
Zynq UltraScale+ MPSoC can simultaneously run multiple processors. You can physically and logically isolate these subsystems from one another and at times allow them to carefully exchange/communicate information in a controlled manner. Zynq UltraScale+ MPSoC IP enables you to capture these subsystems in several ways to suit your needs. You can partition your application using AXI transaction based inhibitors as well as physically isolated ones by not sharing any logic (e.g. utilizing the fabric to create truly isolated systems at signal level i.e. no signal connections between two or more subsystems). The Isolation Configuration tab of PCW focuses on enabling you to define these subsystems utilizing AXI transaction Inhibitors in addition to the Arm® Trustzone infrastructure. For Zynq UltraScale+ MPSoC, these AXI transaction inhibitors take the form of XMPU (Xilinx Memory Protection Unit) and XPPU (Xilinx Peripheral Protection Unit) to block transactions between AXI Masters and Slaves. These two physical blocks are interspersed throughout the Zynq UltraScale+ MPSoC to allow you finer control of your access policy needs between subsystems. See Zynq UltraScale All Programmable MPSoC Technical Reference Manual (UG1085) [Ref 1] and Isolation Methods in Zynq UltraScale+ MPSoCs (XAPP1320) [Ref 11] for more information on XMPU and XPPU. The basic block diagrams of XPPU and XMPU are shown in the following figures.
|
X-Ref Target - Figure 4-18 
|
|
X-Ref Target - Figure 4-19 
|
The isolation settings are disabled by default. If you manually configure any isolation settings, they can affect your design flow as many embedded runtime components in the interface might rely on these settings. See the relevant quick take videos on how to use these settings to define your subsystems.
The PS Configuration Wizard (PCW) in the Vivado design tools allows you to configure Isolation Configuration under the Isolation configuration pane, which is part of the advanced configurations as shown in This Figure .
The security and protection of each peripheral or any memory is achieved by creating subsystems (a subsystem is a group of slaves and masters). and adding required slaves (Peripherals, memory regions, control and status registers) and masters (debug, DMA, Processors and System management masters) that can access the specified slaves under subsystems.
PCW has a subsystem concept, where a design can be categorized as different groups (subsystems). These subsystems are conceptual in nature, and allows you to configure security settings in an easy manner.
PCW allows you to protect and isolate the memories/peripherals, which are configured in the Isolation area of the Vivado design tools. The rest of the memories and peripherals are open to all masters.
PCW provides the following:
• Memory partitioning and protection (DDR with 1 MB address alignment and OCM with 4 KB address alignment).
• TrustZone settings like Non Secure and Secure.
• Access settings like Read/Write, Read-only, and Write-Only. For LPD peripherals the Write-Only option is not available
• Secure Debug
• TZ settings for masters
• Lock Unprotected Address space
The following steps create security/protection settings:
1. Create a subsystem with any meaningful name using the "+" button as shown in This Figure .
2. To configure Isolation, enable the Isolation feature using Enable Isolation button as shown in This Figure .
3. Click Add New Subsystem and enter any name, for example, APU_RPU Subsystem and press Enter .
|
X-Ref Target - Figure 4-22 
|
4. Right-click APU_RPU Subsystem to add any peripheral, Memory, and Masters.
Example: Isolation settings to protect the following:
• Secure 4 MB of DDR memory from 0x00000000 with TZ as secure and Access settings as Read only to APU and RPU0
• Secure 12 KB of OCM memory from 0xFFFC0000 with TZ as secure and Access settings as Write only to APU and RPU0
• LPD peripherals UART 0, UART 1 with TZ as secure and Access settings as Read/Write only to APU and RPU0
• LPD peripherals SPI0, and SPI1 with TZ as secure and Access settings as Read-Only to APU and RPU0
Perform the following steps in the PCW to create the previously described system:
1. Open the PS Configuration Wizard (PCW), go to Isolation pane under Advanced Mode
2. Click on + button and click Add new Subsystem , Enter APU subsystems and then Enter.
3. Right-click APU_RPU Subsystem and then click Add Master. Select APU , RPU0 from processors category as shown in This Figure .
4. Right-click APU_RPU Subsystem and then click Add Slaves. Select DDR_LOW from Memory category.
|
X-Ref Target - Figure 4-24 
|
5. Enter the Start Address and size of the regions, that is 0x00000000 and 4 MB.
6. Set TZ as Secure from the TZ Settings drop-down list.
|
X-Ref Target - Figure 4-25 
|
7. Right-click APU_RPU Subsystem and then click Add Slaves. Select OCM from Memory category.
8. Right-click APU_RPU Subsystem and then click Add Slaves. Select SPI0 , SPI1 , UART0 and UART1 from Peripherals category.
Note: SPI0, SPI1, UART0 and UART1 must be enabled in the I/O Configuration page so that they will appear on the LPD slaveslist.
|
X-Ref Target - Figure 4-27 
|
9. For UART 0 , UART 1 , set TZ as Secure and Access Settings as Read/Write .
10. For SPI0 , SPI1 , set TZ as secure and Access Settings as Read-Only .
|
X-Ref Target - Figure 4-28 
|
Secure Debug : By default, Secure Debug is enabled. It means that DAP and CoreSight™ should be added as master in all the subsystems so that debugging is allowed. For the design that is based on the release version, Secure Debug should be disabled.
Lock Unprotected Address Space : Select this option to protect all the slaves/memory segments, control and status registers which are not mentioned or not part of any subsystems from masters. If a slave/memory segment, control and status register is not mentioned in Isolation, it cannot be accessed by any master.
PMU Firmware : By default, the PMU FW subsystem is added to Isolation configuration. You can modify/delete this subsystem as per your requirement.
You can create the PMU FW subsystem to achieve the following objectives:
1. Make PMU as a centralized processor to monitor any violations.
2. Give SLCR and control registers from all the masters and provide access to PMU only.
3. Protect XMPU and XPPU configuration registers from all other masters and provide access to PMU only.
Note: If you have your own schema to address all the above scenarios, you can have your own subsystems and can remove the PMU FW subsystem.