多處理器系統的電源管理方案

2016-11-16
作者 Davorin Mista、Vojin Zivojnovic、Soren Brinkmann, Zach Pfeffer

多處理器是目前電子系統的主流,主要的優點在於處理速度更快,這主要得益於其平行執行以及改良的操作特性,例如藉由使用適當的處理器,為每一項任務實現最佳化的功耗、散熱和延遲。而這對於在處理單元之間通常具有更密集資料與時序關聯的多核心系統而言,情況也是一樣的。

從歷史上看,平行執行及其帶來的性能提升,一直受到工程界的極大關注,並為此帶來持續演進的平行軟體標準,如開放運算語言(OpenCL)、異質系統架構(HSA)以及開放多處理(OpenMP)等類似的標準。多處理器系統的操作特性,如功耗,雖然對於電子系統至關重要,但在綁定主作業系統(OS)負責控制整個系統的OS導向功率管理(OSPM)來說,它仍帶來了棘手的問題。

OSPM的第一項挑戰來自於在單處理器虛擬管理程式(hypervisor)上執行的多個客戶作業系統;接著是多作業系統、其他版本的多核心虛擬管理程式;最後還有異質多作業系統、多處理器系統等。因此,虛擬管理程式和專用核心開始接管OSPM的職責,工程師也致力於開發自家的電源API,以協調電子系統內各作業系統之間的電源控制。

延遲/功耗權衡問題

目前還沒有通用的標準可用於為異質多處理器系統管理系統電源。每一家供應商都必須重新建構API和協議以因應電源管理,還得花時間將這些API整合於系統中每一處理核心的各個程式碼基礎中。為了滿足市場需求,供應商傾向於利用目前每個核心所用軟體中的現有電源管理解決方案,然後鬆散地耦合這些核心,以產生特定的電源管理機制。這些特定的機制往往具有高延遲的電源-狀態轉換。為了解決該問題,廠商必須祭出靜態、較少更新的資料導向途徑,以權衡延遲與功耗。由於這些權衡,供應商不得不懸置功耗問題,讓用戶自行取捨。

用於異質處理器的新式電源API

解決該問題的方案之一是創建一個所有軟體供應商都能合理實現的API規格,該規格可作為底層的電源管理基礎。由於異質系統的獨特需求,使用少量的程式碼應該就能實現該API,因此,即使是最小的核心也可以參與全系統範圍的電源管理。該API還應該具有足夠的通用性,讓大部份的異質架構均可被表述;但也不能太過於普遍而使該API變得難用。最後,該API應該與現有的電源管理方案相容,如ARM的電源狀態協調介面(PSCI)。

為了滿足這些要求,Aggios和賽靈思(Xilinx)開發了新的可擴展能源管理介面(XEMI)。

XEMI類似於ARM的PSCI。但與PSCI不同的是,XEMI涵蓋異質系統,其目的在於提供一個通用API,讓所有軟體元件為核心和週邊裝置進行電源管理。在較高層級,XEMI讓使用者指定進階的電源管理目標,如暫停一個複雜的處理器叢集或一個單核心。然後,底層建置就可自行決定最佳化的節電途徑。這種方法縮短了延遲時間,因為動作請求者可以指定一個高層級的功耗目標,而不必執行電源狀態轉換的每個步驟。

訊息傳遞介面管理系統電源

XEMI API提供在異質多核心系統中管理元件功耗狀態的機制。XEMI將系統元件的功耗狀態控制交由中央能源管理層負責,讓多個獨立的處理叢集能以更具能效的方式共享可用的從屬裝置(slave device)。

XEMI設定的系統架構包括一或多個處理叢集、中央能源管理軟體(其本身可在多個核心之間分佈)以及可進入多個功耗狀態的從屬裝置(如圖1)。此外,還可能存在電源島和電源域等分層結構,讓元件組在電源島的情況下透過關閉本地電源,或在電源域時經由外部穩壓器或電源管理IC(PMIC),均可關閉其作業。

處理叢集將透過XEMI提交功耗/性能要求,並由電源管理控制器接收與處理這些要求。電源管理控制器負責管理所有從屬裝置的功耗狀態,並根據處理叢集訴求的累計功耗性能要求來選擇各功耗狀態。它也負責管理處理叢集本身的功耗狀態,這將使用XEMI而與控制器協調其暫停流程。

[20161116 XEMI TA31P1]
*圖1:XEMI系統架構*

處理叢集的暫停過程主要由執行於這些叢集上的軟體啟動與負責,而為了執行暫停程序的最後步驟,必須使用電源管理控制器。該控制器可關斷叢集所在的電源島和電源域,潛在地調整從屬裝置功耗狀態,以因應處理叢集的作業要求。

XEMI還包括用於其它處理叢集請求暫停或喚醒的API,它提供了一個標準化的機制來協調系統休眠狀態,以及管理處理叢集之間的主/從關係。

在XEMI API中傳遞的要求可以是明確的元件功能,也可能包括延遲要求,讓電源管理控制器同時為從屬裝置與處理叢集選擇最佳功耗狀態。由於實際的延遲將因平台而異、並取決於如外部PMIC等元件,XEMI讓這些延遲細節得以封包於中央控制器韌體中,而不必要求每個處理叢集上的軟體分別為這些細節進行調整。應用軟體只需知道其延遲要求;而這些要求如何被映射到各種裝置的功耗狀態,這個問題就交給電源管理控制器處理。

例如,Aggios和Xilinx攜手開發出Zynq UltraScale+MPSoC的XEMI建置方法(圖2)。該平台的可編程邏輯讓工程團隊能夠有效地探索設計空間。此外,由於該平台的整體可用性和易用性,也很適合其他研究人員繼續琢磨XEMI規格。

[20161116 XEMI TA31P2]
*圖2:Zynq UltraScale+ MPSoC架構*

Zynq UltraScale+ MPSoC由幾個可獨立作業的處理叢集組成,包括四核心ARM Cortex-A53應用處理器單元(APU)、雙核心ARM Cortex-R5即時處理器單元(RPU),以及可實現一或多個軟核心處理器的可編程邏輯資源。所有這些處理器都可以共用許多從屬裝置。此外,當APU這一類的處理器閒置時,可完全地關閉電源島以便進一步降低洩漏功耗;而關斷整個全功率域(FPD)還可進一步降低功耗。XEMI用於協調和執行這些以及其它轉換過程。

圖3的統一建模語言(UML)說明了XEMI如何用於實現典型的電源管理應用。圖中並顯示從‘完全主動’狀態過渡到深度休眠的狀態,而不至於對於FPD內的任何元件提出密集的喚醒延遲要求。在深度休眠狀態,兩個處理單元都是關斷的,但仍保留記憶體狀態,而FPD也是關閉的。

即時處理單元(RPU)透過呼叫pm_request_suspend啟動進入深度休眠狀態,接著,平台管理單元(PMU)藉由pm_init_suspend要求APU自行暫停。APU執行自動暫停並將其當時的情境架構儲存於雙數據速率(DDR)記憶體。一旦APU暫停程序完成,PMU以pm_acknowledge通知RPU。由於FPD中沒有其他裝置在使用中,也沒有密集的延遲要求,PMU隨即關閉向FPD的供電電源。

[20161116 XEMI TA31P3]
*圖3:深度休眠UML方塊圖*

現在,RPU透過PMU釋放USB裝置。PMU透過pm_release_node並啟動其暫停程序,並將即時時脈(RTC)配置為其喚醒源。由於沒有其他的電源管理活動,PMU隨即進入休眠狀態。而當喚醒事件發生時,PMU立即知道哪些裝置必須被喚醒,並根據需要處理電源域和電源島的正確上電順序。

結論

XEMI API克服了異質多處理的電源管理挑戰,而不至於像傳統OSPM途徑一樣必須有所折衷。它讓軟體供應商可自在且有效率地為其平台打造一個底層電源管理基礎。這一途徑賦予設計者掌控電源的能力,而傳統的建置方式則只得由由用戶取捨。需要許多跨系統協調的任務,例如關斷許多異質核心等,如今可透過API(如XEMI)以目標為中心的高層級策略變得更輕鬆。

(參考原文:Solving power management of multiprocessor systems with the eXtensible Energy Management Interface,by Davorin Mista, Vojin Zivojnovic, Soren Brinkmann, Zach Pfeffer)

活動簡介

人工智慧(AI)無所不在。這一波AI浪潮正重塑並徹底改變科技產業甚至整個世界的未來。如何有效利用AI協助設計與開發?如何透過AI從設計、製造到生產創造增強的體驗?如何以AI作為轉型與變革的力量?打造綠色永續未來?AI面對的風險和影響又是什麼?

AI⁺ 技術論壇聚焦人工智慧/機器學習(AI/ML)技術,涵蓋從雲端到邊緣、從硬體到軟體、從演算法到架構的AI/ML技術相關基礎設施之設計、應用與部署,協助您全面掌握AI最新技術趨勢與創新,接軌AI生態系佈局,讓機器學習更快速、更經濟、更聰明也更有效率。

贊助廠商

發表評論

訂閱EETT電子報