Subsystem Power Management - 2023.1 English

Zynq UltraScale+ MPSoC Software Developer Guide (UG1137)

Document ID
UG1137
Release Date
2023-08-04
Version
2023.1 English

Isolation Configuration

The Zynq UltraScale+ MPSoC can be partitioned into sub-systems, so that they can be managed independently by the power management framework. For example, you can define a Linux sub-system and a Real-time sub-system. The Linux sub-system may include the APU (as the PM master) and a number of peripherals (as the PM slaves). The Real-time sub-system may include the RPU and a number of other peripherals. Each sub-system can be powered up, powered down, restarted or suspended without affecting the other sub-systems. A sub-system has only one PM Master, and may include both FPD and LPD peripherals.

You can create your own sub-systems using the AMD Vivado™ PCW tool. The following figure shows the PCW screen shots of a valid configuration, which contains only an APU sub-system and no RPU sub-systems.

Figure 1. PCW Configuration
Figure 2. PCW Configuration Contd
Figure 3. PCW Configuration Contd
Note: The PCW tool is also used to isolate some peripherals from each other for security purposes. See Zynq UltraScale+ MPSoC: Embedded Design Tutorial (UG1209) and Zynq UltraScale+ MPSoC Processing System LogiCORE IP Product Guide (PG201) for details on how to set up isolation between peripherals.

Configuration Object

The sub-system configuration is captured in a Configuration Object, which is generated by the Vivado and PetaLinux toolchain. The Configuration Object contains:

  • The PM Masters that are present in the system (APU and/or RPU). Any PM Master not specified in the Configuration Object will be powered down by the PMU.
  • Configurable permissions for each PM Master, such as:
    • Which PM Master can use which PM Slave (A PM Master can use all the PM Slaves that belong in the same sub-system.)
    • Access to MMIO address regions.
    • Access to peripheral reset lines.
  • Pre-allocated PM Slaves. The PM Master can use these PM Slaves without requesting for them first. These PM Slaves are needed by the PM Master in order to boot. The toolchain makes sure that the APU can access the L2 cache and DDR banks without first requesting for them. The same is true for the RPU accessing all the TCM banks.
During boot, the Configuration Object is passed from the FSBL to the PMU firmware. For more details, see the Configuration Object.
Note: Isolation is not required for the Configuration Object to be created. You can create subsystems to customize the Configuration Object and then uncheck the isolation checkbox.

Power Management Initialization

Power management is disabled during boot and all the peripherals are powered up at this time. That is because it is often necessary to allow for possible, and temporary, inter-dependencies between peripherals during boot and initialization. When FSBL is finished with initializing the peripherals and loading the application binaries, it passes the Configuration Object to the PMU. The PMU is now aware of all the sub-systems and their associated PM Masters and PM Slaves. PM Masters and PM Slaves that are not included in the Configuration Object are never used, and are powered down by the PMU.

A PM Master is not likely to use all the PM Slaves at all times. Therefore, a PM Slave should be powered up only when it is being used. The PM Master must notify the PMU before and after using a PM Slave. This functionality is implemented in the PetaLinux kernel. This requirement hinders developers starting with a new RPU application, when the focus is on functionality and not power optimization. Therefore, it is convenient for the PMU to also support PM-incapable Masters that do not provide notifications when they are using the PM Slaves. This is done by keeping all the PM Slaves in the sub-system powered up until the PM Master sends the PmInitFinalize request to the PMU. A PM-incapable Master will never send this request, which means that its PM Slaves will remain powered up at all times or until this PM Master itself is powered down.

A PM-capable Master sends this request after initializing the sub-system. The PMU then begins powering down the PM Slaves in this sub-system whenever they are not being used.

As a result, when there is an RPU master present in the system but it is not running any application, the PMU firmware will consider it as a PM incapable master and hence will never power down the RPU and its slaves. From the 2018.3 release and onwards, this behavior is fixed and allows you to power down unused RPUs. This change is protected by the compilation flag ENABLE_UNUSED_RPU_PWR_DWN and is enabled by default. When this flag is enabled, the unused RPU and allocated slaves will be powered down if not in use.

Table 1. Power Management Initialization
Boot Mode APU Image RPU Image RPU Mode ENABLE_UNUSED_RPU_PWR_DWN_VAL RPU0/TCM0 State RPU1/ TCM1 State
JTAG Don’t Care Don’t Care Don’t Care Don’t Care ON ON
Non-JTAG Boot modes Don’t Care Don’t Care Don’t Care 0 ON ON
Linux or PM aware app that calls PM_INIT_FINALIZE RPU app in boot image Lock step mode 1 ON OFF
RPU0 app in boot image Split mode 1 ON OFF
RPU1 app in boot image Split mode 1 OFF ON
Both RPU apps in boot image Split mode 1 ON ON
RPU app not in boot image   1 OFF OFF
Bare Metal app that does not call PM_INIT_FINALIZE Don’t Care Don’t Care Don’t Care ON ON
Note: If you do not want to power down RPU/TCM by default, set the ENABLE_UNUSED_RPU_PWR_DWN flag to 0 while compiling the PMU firmware. For the JTAG boot mode there is no impact on behavior change even though ENABLE_UNUSED_RPU_PWR_DWN flag is 1.
Note: Sub-systems may overlap each other. This means that some PM Slaves may belong to more than one sub-system (for example, DDR, OCM, and so on). If a PM Slave is in more than one sub-system, the PMU does not power down this PM Slave until it has been released by all its PM Masters, or until all these PM Masters have powered down themselves.

Default Configuration

By default, Isolation Configuration is disabled, and the tool chain generates a configuration with three sub-systems. Each has a PM Master: APU, R5-0 and R5-1. All three sub-systems contain all the PM Slaves (meaning that the sub-systems completely overlap each other.) This is the default configuration generated by PCW when the “Enable Isolation” box is unchecked. The default PetaLinux kernel configuration is PM-capable, but R5-0 and R5-1 must be also running “PM-capable” applications, or be powered down. Otherwise, the PMU will not power down any PM Slaves.

Note: You can create a configuration that does not allow the processors to boot and run. If you are a beginner, use the APU-only configuration as described in Isolation Configuration section and customize it as necessary.

RPU Lock-step vs. Split Mode

The toolchain infers the RPU run modes from the PCW Isolation Configuration as follows:

  • No RPU present in any subsystem: Configuration Object contains no RPU.
  • Only R5-0 present in subsystem(s): Configuration Object contains R5-0 running in lock-step mode.
  • Both R5-0 and R5-1 in subsystems: Configuration Object contains R5-0 and R5-1 running in split mode.
  • Only R5-1 present in subsystem(s): Configuration Object contains R5-1 running in split mode.

The default Configuration Object contains two RPU PM Masters: R5-0 and R5-1, and the PMU assumes that the R5-0 and R5-1 are running in split mode. However, the boot image actually determines whether the RPU runs in lock-step or split mode at boot time. The RPU run mode from the boot image must match the number of RPU PM Masters in the Configuration Object. Otherwise, the power management framework will not work properly.

Note: If you intend to use the R5 in lock-step mode, you need to ensure that the Isolation Configuration is enabled in PCW, and only R5-0 (not R5-1) is present in a subsystem.