Solving power management of multiprocessor systems with the eXtensible Energy Management Interface
Message-Passing Interface Masters System Power
The XEMI API provides the mechanisms for managing power states of components in heterogeneous multi-core systems. By delegating power state control of system components to a central energy management layer, XEMI enables multiple independent processing clusters to share available slave devices in an energy efficient manner.
XEMI assumes a system architecture consisting of one or more processing clusters, central energy management software (which itself can be distributed across multiple cores), as well as slave devices that can enter multiple power states (Figure 1). Furthermore, there may be a hierarchy of power islands and power domains, allowing groups of components to be turned off by either switching off the power locally in case of a power island or for power domains via an external regulator or power management IC (PMIC).
Figure 2. XEMI System Architecture
The processing clusters will submit power/performance requests via XEMI. These requests are received and processed by the power- management controller. The power-management controller is responsible for managing the power state of all slave devices, which it chooses based on the cumulative power performance requirements asserted by the processing clusters. It also is responsible for managing the power state of the processing clusters themselves, which will use XEMI to coordinate their own suspend procedures with the controller.
The suspend procedure of processing clusters is mostly initiated and conducted by the software running on those clusters, while the power- management controller is required in order to perform the final steps of the suspend procedure. The controller is powering down the power islands and power domains the clusters reside in and by potentially adjusting the power state of slave devices the processing clusters are required to operate.
XEMI also includes APIs for requesting the suspend or wake-up of other processing clusters, providing a standardized mechanism to coordinate system sleep states as well as manage master/slave relationships between processing clusters.
The requirements passed in the XEMI APIs can either refer to explicit component capabilities, or include latency requirements, allowing the power management controller to choose the optimum power state for both slave devices as well as the processing clusters. Given that actual latencies will be platform specific, depending on components like external PMICs, XEMI allows these latency details to be encapsulated in the central controller firmware, rather than requiring the software on each of the processing clusters to be adjusted with such details. Application software just needs to know its latency requirements; how these requirements map to states of the various devices is left up to the power management controller.