Changing Requirements - 2020.2 English

Versal ACAP System Software Developers Guide (UG1304)

Document ID
UG1304
Release Date
2020-11-24
Version
2020.2 English

When a subsystem is using a PM slave, its requirement on the capability of the slave can change. For example, an interface port might go into a low power state, or even be completely powered off, if the interface is not being used. The subsystem can use XPm_SetRequirement to change the capability requirement of the PM slave. Typically, the subsystem would not release the PM slave if it will be changing the requirement again in the future.

The following example call changes the requirement for the node argument so it is powered up and accessible to the PM master.

XPm_SetRequirement(node, PM_CAP_ACCESS, 0, REQUEST_ACK_NO);
Important: Setting the requirements of a node to zero is not equivalent to releasing the PM slave. By releasing the PM slave, a subsystem might be allowing other subsystems to use the device exclusively.

When multiple subsystems share a PM slave (this applies mostly to memories), the PMC selects a power state of the PM slave that satisfies all requirements of the requesting subsystems.

The requirements on a PM slave include capability as well as latency requirements. Capability requirements may include a top capability state, some intermediate capability states, an inactive state (but with the configuration retained), and the off state. Latency requirement specifies the maximum time allowed for the PM slave to switch to the top capability state from any other state. If this time limit cannot be met, the PMC will leave the PM slave in the top capability state regardless of other capability requirements.

For more information about XPM_SetRequirement, see OS and Libraries Document Collection (UG643).