電子發燒友App
微控制器/片上系統 （MCU/SoC） 系統的能耗比較——一個基準就足夠了，還是我們需要一個參數基準？
一個產品的選擇、市場定位和成功的一個重要因素是整個系統的能耗。測量這一點的傳統方法是以微安 （μA） 或每兆赫茲微瓦 （μW/MHz） 為單位來表示效率，但這已經不夠了。儲能系統既不存儲 μA 也不存儲 μW，而是存儲焦耳，焦耳僅表示能量。因此，比較 MCU/SoC 設備的能源使用情況已成為用戶的首要關注點。
一個基準是否足以選擇 MCU、MCU 系列或整個 MCU 制造商？公開可用的技術文檔是否足夠？為您的應用選擇合適的供應商有多容易？
第 1 部分：超低功耗基準：ULPBench-Core Profile
第 2 部分：ULPBench-Core 配置文件、EEMBC 文檔和 MCU 數據表
第 3 部分：工作溫度對能耗的影響
第 4 部分：MCU 數據表：操作模式、控制位、寄存器、電流和模式傳輸參數
以前的文章著眼于供應商數據表的內容。數據表在其最新版本中可在網絡上獲得，但遺憾的是在其先前版本中沒有。在設計開始時未存儲初始修訂會在計算能耗方面產生誤導性結果。供應商在數據表中的營銷聲明有時很難用詳細數據進行驗證。如果我們想根據能效來選擇最好的MCU，我們有幾種選擇：
來自 ULPBench von EEMBC 等基準測試的結果
發表 MCU 應用測量的文章
MCU供應商提供的各類文件
技術貿易雜志、大會或論壇上的公開文章。
EEMBC 的 ULPBench 結果
ULPBench 提供有關能源消耗的基本陳述。RUN-Mode 和 RTC-Mode 在一秒內以 50 ppm 的精度執行。被測設備不需要滿足供應商的典型數據。
超出此基本定義的每個應用程序都可以提供將對 EEMark 排名產生負面影響的消費數據。以下是三個例子：
電源模式之間的切換損耗和切換所需的代碼
外設，特別是具有高數據吞吐量的數字功能和模擬功能，例如 ADC/DAC/放大器等。
限制模式之間的切換和序列的約束；可以使用從實際模式到目標模式的中間模式。
所有三個提到的條件都對 EEMBC 的第一個基準測試的結果沒有影響。
MCU 供應商為其產品提供了許多不同的文檔。我們僅限于功能描述、電氣特性數據和面向應用的文檔。軟件示例和開發工具將不在這里介紹。
在圖 1 中，總結了所有提及操作模式和更改以確保安全操作的頁面。
【圖1 | 海量數據呈現給用戶，實現節能運行。僅考慮整個產品組合中的一個 MCU 系列。］
通常，發布的功率模式不到十幾種；為任何應用功能獲得最佳電源模式應該很容易。公布的數據與少數功率模式所暗示的相反。在任何電源模式和模式更改過程中，都必須確保安全和節能的操作：
工作電壓和頻率通常覆蓋不同的區域
指令和電源模式控制位
幾個 ON/OFF 字和位；內部電源的電源門控、允許的順序和必要的時序。
時鐘生成、路由和 ON/OFF 切換。
排除所有決定以下配置、功能和操作模式的頁面：
中斷和“異常”處理
內存條件，如等待狀態、內存中的數據保留（SRAM 保留）等。
內存保護/MMU 配置等
調試模式期間的操作/電源模式
外圍功能，例如啟用/禁用、電源/性能配置和更改條件
保存和重新配置功能
大多數系統架構使用最小的公分母來表示操作條件。這意味著，例如，諸如中斷請求之類的任務的確認和執行將在相對高性能的電源模式下執行。這使用最近選擇的工作電壓和頻率。更合適的操作模式需要執行額外的軟件，這增加了對能量和執行時間的另一項要求，損失了能量和性能。
圖 1 還表明需要對現有文獻進行深入學習。時鐘和電源門控的實現需要對眾多振蕩器和工作電壓及其控制、指令和電氣特性進行全面規劃。此外，動態運行模式轉換條件很重要，并非所有能級都可以直接從實際運行模式中獲得。
【圖2 | 通過 TI SLAA657A。該圖表明從一種模式（LDO/DC-DC 和 LF128KHz）更改為另一種模式需要零個、一個或兩個中間步驟。其他條件，例如延遲，沒有提到，但在系統規劃中是必不可少的。在上圖中，僅顯示了活動模式轉換。不包括操作/低功耗模式之間的轉換。
電氣特性代表靜態條件；它們僅代表已確定的條件。數據表中沒有提到瞬態和啟動損耗。最好的情況是，您會在應用說明中找到建議。
對于 STM32L476 （EEMark=153），您可以根據數據表計算出在 1700 uA@2 us/3 V 時的喚醒能量約為 0.1 uJ。ULPBench-CP 軟件和硬件測量的能量消耗為 6.66 uJ。在一秒鐘內，您可以忽略喚醒能量。但如果工作負載分布在 100 個周期內，“喚醒”能量 （10，2uJ） 明顯大于“工作負載”能量 6.56 uJ。換句話說，當您增加循環次數時，切換操作模式的能量會成為一個重要因素。此外，節能模式和運行模式之間的頻繁變化可能會導致不同的“最佳”低功耗模式，具體取決于實際喚醒周期。SiLabs 示例顯示了這一點。
【圖3 | 通過 SiLabs，2013-11-25 - AN0027_Rev1.03；從 EM2 與 EM4 定期喚醒的功耗。該報告表明，能量模式 4 提供最低的電流消耗，沒有完全保持，因此要求設備在喚醒時經歷一個復位周期。這個復位周期比從 EM2 或 EM3 喚醒需要更長的時間。］
對于所有可用的組合，所有不同能量模式之間的轉換是不可能的。請參閱 NXP/Qualcomm 的 Kinetis-MCU 中的一個示例。
【圖4 | 通過 NXP，AN4503：Kinetis MCU 的電源管理，第 2 版，04/2015。并非每種模式都可以從其他模式到達。］
正如您在圖 4 中看到的，HSRUN 模式只能從 RUN 模式進入，通過軟件而不是通過硬件模式修改。此外，每個“低功耗”模式只能留給 RUN 模式。由于文檔中沒有提到任何例外，您可以假設每個事件或中斷都需要在 RUN 模式或“極低功耗 RUN”模式下執行，或者需要必須通過軟件選擇的不同模式。這意味著您總是返回到“耗電”的 RUN/VLPR 模式。
這些模式之間的轉換具有從納秒到微秒的時間/時鐘條件。將這些轉換時間與 ULPBench 上的執行時間進行比較是很有趣的。ULPBench 上的執行時間范圍為 0.4 到 2 毫秒。必要的時鐘周期在 10000 到 23000 的范圍內。這清楚地證實了需要一種更智能的方法來重新配置 MCU 并使更改操作模式成為無縫且快速的解決方案。
我們今天在哪里？
我們介紹了一種比較 MCU/SoC 能耗的方法。EEMBC 組織已從第一步開始：基準 ULPBench。對于能源敏感型產品，需要進行更多調查來驗證和選擇 MCU/SoC 系列。
用戶可以通過智能和密集的軟件代碼影響待機和活動運行模式下的能源需求，而不是通過半導體工藝選擇或芯片設計。與溫度相關的能耗的根源與用戶無關。最佳情況下，用戶可以與 MCU 供應商一起使用先進的方法來優化動態能耗，以管理全面的操作模式。圖 1 顯示了該行業向客戶提供了多少文件和冗長的描述來解釋最佳的能源消耗。始終選擇最佳電源模式并使系統始終處于安全運行條件下是一項挑戰。例如， 圖 2 和圖 4 中的信息顯示了改變操作模式的限制。未來的策略是縮短模式之間的切換周期，避免它們，或者使它們更容易。
Quo Vadis，我們要去哪里？
操作模式更改次數的增加是一項挑戰。我們已經看到了大量信息，并且必須了解它們的組合才能實現低能耗系統。實現最佳解決方案是一項重大的努力。更智能的操作模式管理是一種解決方案。這些解決方案存在，但需要進行調整。管理操作模式的清晰和簡單的結構將使硬件和軟件設計人員的生活更加輕松。維護、產品增強和向后兼容性是綜合操作模式的更多論據。
在這樣的安全運行和安全模式環境下，安全運行和安全模式對真正的最低能量模式提出了另一個巨大的挑戰和更強烈的需求。主要討論了基本的硬件和軟件解決方案——能源需求不是這些討論的重點。物聯網環境在許多方面都需要安全、可靠和能源優化的嵌入式系統的結合。
作者：Horst Diewald，Uwe Mengelkamp
審核編輯：郭婷
工商網監
評論