Both the AMD-Xilinx MPSoC and Versal ACAP families have complex internal power structures which consists of domains like the Full Power Domain (FPD) or Low Power Domain (LPD), Islands such as individual processors, nodes such as peripherals, and memories.
These domains and islands can be powered up or down to optimize the power dissipation of the overall solution. This allows for dynamic power management at run time and enables the most power-efficient implementation for current use cases. In both MPSoC and Versal devices, the system power management is performed by a dedicated MicroBlaze processor. It is performed by the Platform Management Unit (PMU) in MPSoC devices and the Platform Management Controller (PMC) in the Versal devices.
We’re going to take a fresh look at the PMU in the MPSoC since it’s been a while since we last reviewed.
The PMU has several roles in operation of the MPSoC. These roles can be summarized as platform management, but here they are in more detail:
Performs initialization during boot. This process uses Sysmon to check the power supplies, initialize the PLLs, run the Built in Test, and check for errors before releasing the CSU.
Performs 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 is also suspended. Only the PMU can receive a wake-up trigger.
Monitors the system for errors and is capable of reporting these both internally and externally via the PS_ERROR_STATUS pin on the dedicated MIO.
Provides support for higher-level system management as may be required for functional-safety applications. For example, it is possible for the user to upload their own more advanced PMU software to run a software test library (STL).
The power management role is interesting because the Inter Processor Interrupts allows power masters such as the APU, RPU or PL MicroBlazes to manage the power slaves.
To get started, we need to create the PMU firmware which is created in Vitis targeting the PMU processor in the new application wizard. I targeted a Digilent/Trenz TE0802 for this demonstration. The block diagram is very simple with just the PS configured for the board.
There are several build flags which can be used if we need to make any changes to the PMU firmware or ensure debugging or visibility. These are defined on page page 139 of the Zynq UltraScale+ MPSoC Software Developer Guide UG1137 and can be added into the C/C++ build setting for the PMU firmware as a symbol.
Once we have the PMU firmware built, we need to enable the XilPM library within the application board support settings.
Enabling this library within our application BSP will allow the application to communicate with the PMU and its power management software. Running this software allows us to be able to observe the state of the power domains and islands, and power down and up domains / islands as necessary. The full list of API calls is detailed within the OS and libraries documentation collection in UG643.
For this simple example, I created an application which would loop around all of the power islands and domains and output Node status which reports requirements, status and usage.
Here are some definitions to the terminology used above
Requirements – These are specific requirements for each node and will be different for each node / island / domain.
Status - Shows the status of the island, domain or node. For CPU nodes, this shows the CPU status as CPU OFF(0), CPU Active (1), CPU Sleep (2) or CPU suspending (3). For power islands, it is simply island on (1) or off (0). There are three states for nodes: On (1) Off (0) and Retention (2).
Usage – The current use of the node not used (0), used by caller exclusively (1), node is used by other power
The application looks around all 70 power islands, nodes, and domains in the Zynq MPSoC and the mapping to nodes occurs with the source code pm_defs.h for the XilPM client.
When it comes to loading the PMU firmware, there are two options from configuration memory.
Loaded by the boot ROM – In this case the PMU is loaded by the boot ROM and starts running before the FSBL. As a result, there will be no terminal outputs because the device IOs are not yet configured. The FSBL will, however, report a warning if no PMU firmware is found.
Loaded by the FSBL – In this case, the FSBL loads the PMU firmware and the PMU will then be able to output its version etc.
These selection boot ROM or FSBL load is controlled by how the PMU elf is flagged in the Boot File creation (bif file). If the PMU elf partition is defined as a datafile destined for the PMU, it will be loaded by the FSBL.
It will be loaded by the boot ROM if we set the partition type to PMU loaded by boot ROM.
If we want to debug the application, we first need to make sure the PMU is loaded in and running prior to the FSBL etc. This is because the PU MicroBlaze is not visible in XSDB without the removal of the security gate.
To do this, we can use a XSCT and create a simple TCL script as seen below. Note that you might need to edit names and paths to the SW in your 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
We will take a deeper look at the capabilities of the PMU in future blogs. The next step is to take a look at the PMC within Versal, which should be similar.
Comments