AMD-Xilinx MPSoC and Versal ACAP series have complex internal power structures, including Full Power Domain (FPD), Low Power Domain (LPD), single processor power domains, peripheral nodes, and memory power domains.
These domains can be powered on or off, optimizing the overall solution’s power consumption. They also allow for dynamic power management at runtime to achieve the lowest power consumption for current use cases. In MPSoC and Versal devices, system power management is controlled by a dedicated MicroBlaze processor, executed by the Platform Management Unit (PMU) in MPSoC devices and the Platform Management Controller (PMC) in Versal devices.
The PMU plays multiple roles in the operation of MPSoC. These roles can be summarized as platform management:
-
Initialize during boot. This process uses Sysmon to check power, initialize PLLs, run built-in tests, and check for errors before releasing the CSU.
-
Perform power management during operation. The PMU can shut down power domains or individual power islands or enter deep sleep mode. Once in deep sleep mode, the PMU also suspends. Only the PMU can receive wake-up trigger signals.
-
Monitor system errors and report these errors internally and externally via the PS_ERROR_STATUS pin on the dedicated MIO.
-
Support higher-level system management that may be required for functional safety applications. For example, users can upload their own advanced PMU software to run the Software Test Library (STL).
The power management role is interesting because processor interrupts allow power masters such as APU, RPU, or PL MicroBlaze to manage power from devices.
First, we need to create PMU firmware, which is created for the PMU processor in the new application wizard in Vitis. The block diagram is very simple, using only PS.
If we need to change the PMU firmware to ensure debugging visibility, we can use multiple flags to indicate this. These are defined on page 139 of the Zynq UltraScale+ MPSoC Software Developer’s Guide UG1137 and can be added as symbols to the PMU firmware’s C/C++ settings.
After building the PMU firmware, we need to enable the XilPM library in the board support settings.
Enabling this library in our application BSP allows the application to communicate with the PMU and its power management software. Running this software enables us to observe the state of power domains and islands and turn the power of domains/islands on and off as needed. A complete list of API calls is detailed in the operating system and library documentation set in UG643.
❝
https://docs.xilinx.com/r/en-US/oslib_rm/BSP-and-Libraries-Overview
❞
For this simple example, create an application that loops through all power islands and domains and outputs a node status report.
Here are some definitions of the terms used above:
-
Requirements – These are specific requirements for each node and differ for each node/island/domain.
-
Status – Displays the status of the island, domain, or node. For CPU nodes, the CPU status is displayed as CPU OFF (0), CPU Active (1), CPU Sleep (2), or CPU suspending (3). For power islands, it is simply either open (1) or closed (0). Nodes have three states: on (1), off (0), and reserved (2).
-
Usage – The node is currently unused (0), exclusively used by the caller (1), or the node is being used by other powers.
The application examines all 70 power islands, nodes, and domains in the Zynq MPSoC and maps to nodes through the source code pm_defs.h of the XilPM client (https://github.com/Xilinx/embeddedsw/blob/master/lib/sw_services/xilpm/src/zynqmp/client/common/pm_defs.h).
When loading the PMU firmware, there are two options for configuring memory.
-
Boot ROM load – In this case, the PMU is loaded by the Boot ROM and begins running before the FSBL. Since the device IO has not yet been configured, there will be no terminal output. However, if the PMU firmware is not found, the FSBL will report a warning.
-
Loaded by FSBL – In this case, the FSBL loads the PMU firmware, and then the PMU will be able to output its version, etc.
These loading options, whether by Boot ROM or FSBL, are controlled by how the PMU elf is marked in the boot file (bif file). If the PMU elf partition is defined as a data file sent to the PMU, it will be loaded by the FSBL.
If we set the partition type to be loaded by Boot ROM for the PMU, it will be loaded by the Boot ROM.
If we want to debug the application, we first need to ensure that the PMU is loaded and running before the FSBL, etc. This is because, without removing the security gate, the PU MicroBlaze is not visible in XSDB.
To do this, we can use XSCT and create a simple TCL script as follows. Note that the software name and path need to be edited in the application.
#Disable Security gates to view PMU MB target
targets -set -filter {name =~ "PSU"}
mwr 0xffca0038 0x1ff
after 500
#Load and run PMU FW
targets -set -filter {name =~ "MicroBlaze PMU"}
dow xpfw.elf
con
after 500
#Reset A53, load and run FSBL
targets -set -filter {name =~ "Cortex-A53 #0"}
rst -processor
dow fsbl_a53.elf
con
#Give FSBL time to run
after 5000
stop
That’s all for today’s introduction to PMU, and we will provide more detailed information about its functions later.
