在低功耗特性中，軟件可能實現起來并沒有那么難，從設計到實現的時間可能并不會耗時特別長，耗時最長的是后續的商用問題定位以及對功耗的優化，這些都是建立在一定的實戰基礎上才能做的越來越好，在這里推薦幾種比較常用的優化或者定位問題的手段供大家參考，希望能給大家帶來一些幫助。

圖：低功耗軟件棧組成

19.1多子系統配置

比如某一個公共外設，如果多個子系統共用的話，在芯片設計上建議每個子系統各放置一個，這樣一可以節省系統運行過程中的訪問帶寬，二可以做好訪問隔離，盡可能的降低了芯片通路訪問的復雜性和軟件設計的復雜性。

我們通過一個例子來說明一下：比如在一個系統中，只有一個DMA，存放在公共外設區（peri），這個時候如果AP需要訪問DMA的話，那么它需要先經過自己系統的SUB BUS總線，再通過SYS BUS總線訪問到外設區的DMA；如圖19-1所示。

圖19-1 DMA部署優化前布局示意

如BP需要訪問DMA的話，那么它也需要先經過自己系統的SUB BUS總線，再通過SYS BUS總線訪問到外設區的DMA；如此這般，其他子系統都是同樣的訪問路徑。在這樣的情況下，有2個缺點：一是訪問路徑過遠增加了總線的繁忙程度，可能導致訪問延時；二是可能存在資源競爭的發生，比如AP、BP或其他子系統同時訪問的話，可能需要做仲裁處理。

那么針對這種情況，我們可以做個優化，就是把DMA在每個子系統內部的device區各放置一個，如圖19-2所示，各個CPU需要使用DMA時，只用訪問自己內部的DMA即可，這樣可以很好的化解前邊說的2個缺點。為什么說這樣設計也可以做到功耗優化呢？試想如果AP側沒有這個DMA，那么在AP側喚醒而其他子系統都睡眠的情況下，AP側如果要訪問DMA，勢必需要給其他子系統上電，從而帶來功耗的浪費，而如果AP子系統內部本身就有DMA的話就沒有必要給其他子系統上電。這個思想當然可以用在任何IP的歸置上，需要根據實際的設計場景做對應的優化。

圖19-2 DMA部署優化后布局示意

19.2并行處理

低功耗比較敏感的一個KPI是suspend和resume的時間，因為低功耗是系統中的一個常態，這一塊的處理時間當然是越短越好，這樣可以讓用戶體驗更流暢。一個好的思想是讓處理盡可能的并行起來，比如在suspend和resume的流程中，有一長段地址空間需要保存恢復，那么如果是用CPU的話，效率是十分低下的，這個時候我們可以使用DMA來搬移數據，同時CPU繼續處理低功耗處理的其他流程，在合適的點來檢查DMA的搬移狀態。我們可以通過以下例子來說明。

在suspend流程中，PD MEM中的內容我們使用CPU來做下電前的保存動作，如圖19-3所示，把內容保存到DDR中，耗時T1，其他suspend處理耗時為T，那么suspend總耗時為T+T1，T1時長與PD MEM的大小強相關，越大耗時越長。

圖19-3使用DMA搬移前

那么關于大內存保存恢復這一塊，其實我們可以做一個優化，那就是不使用CPU進行處理，我們使用DMA去做搬移，CPU去做其他的suspend動作，那么T1這個耗時就可能會省下來，總耗時為T，從而達到時長優化的目的。如圖19-4所示。

圖19-4使用DMA搬移后

前邊講了suspend流程的并行處理優化思想，對于resume流程來講，同樣適用，就不再做過多闡述。

19.3增加打點信息

因為在低功耗流程中，會涉及到關閉時鐘或者關閉電源等操作，很多debug工具是無法使用的，一個好的手段是在內存中劃分一片區域專門用來給低功耗流程打點使用，打入數據通常是系統中遞增的時間戳，這樣有2個好處：一是可以方便查看各個階段的耗時，二是可以根據時間戳的遞增特性來快速的定位到哪一步出了異常。如圖19-5所示。

審核編輯 ：李倩