March 25, 2022
Editor’s Note: This content is republished from the MicroZed Chronicles, with permission from the author.
Both the 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:
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 application, 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.
The meaning of these is as follows:
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.
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 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.