基于FMC手機的低功耗設計方案

　　圖2：融合手機第一代平臺架構。（來源：恩智浦半導體）

　　第二代融合手機

　　由于越來越多的用戶使用藍牙耳機，第二代融合手機一般都集成了藍牙（BT）功能。這類手機集成了三個射頻系統，并在它們之間進行協調：由于采用協同工作濾波器，GSM與BT以及GSM與WLAN可以一起工作。BT/WLAN共用同一頻段，彼此之間干擾嚴重，因此需要復雜的射頻接入協調，特別是BT和WLANIC之間進行緊密協調。

　　圖3：融合手機第二代平臺（來源：恩智浦半導體）

　　除此以外，第三個系統（BT）在空閑（掃描）和通話（即在使用耳機模式）時也需要額外功耗。因此BT子系統本身與所在的整個系統架構都需要具備很好的能效。

　　WLAN專用PMU，進一步改善系統能耗。采用專用于WLAN和/或BT平臺的PMU，可以避免因LDO（線性穩壓器）造成的損耗，從而達到進一步改善能耗的目標。

　　功耗需求的變化

　　功耗需求在過去的兩年里發生了相當大的變化。用戶剛開始還能接受一些解釋：手機內置WLAN，這會損耗一些電量，待機時間只有GSM的一半。不久以后，要求WLAN待機時間達到數天則成為主要目標。但這依然沒有滿足消費者的期望：電池即便在支持相同的待機時間基礎上還要能夠通話一段時間（如3個小時）。此目標運營商們保持了一段時間。

　　第一批消費者的反饋表明融合手機必須具備與普通GSM手機相同的性能。消費者不希望因采用FMC技術而帶來任何明顯的差異，因此，運營商不但不會宣傳，甚至會對用戶進行隱藏該項技術。“普通”GSM手機的另一個市場推動力是Razr的成功，以及隨之不斷增長的對超薄手機的需求。現在，相同功能和性能的GSM手機（也包括FMC手機）一般都采用650mAh電池，而不是1000mAh，因此所有手機元件（包括WLAN）需要節約30%的能耗。圖5是功耗要求的典型演化圖，隨后將討論實現這一目標的解決方案。

　　圖4：融合手機第三代平臺。（來源：恩智浦半導體公司）

　　關鍵系統設計

　　整體設計

　　作為獨立的子系統，WLAN子系統需要擁有自己的時鐘、電壓控制、省電模式管理，以及必要時激活主機的能力。必須避免在空閑時間內兩個系統并行工作：如果可以使用首選系統（WLAN），則另一個系統（GSM）需要進入睡眠狀態。為了取得良好的關鍵性能和用戶體驗，某些偏差也可以接受（例如，在通話期間）。使處理器之間的通信最小化。WLAN只有在收到相關數據時才激活主機。RSSI（電平）測量應在WLAN子系統內局部進行—只有測量值超出給定極限才激活主機。

　　圖5：UMA 手機功耗的演變過程。

　　協議分層及例外

　　嵌入軟件通常按照OSI模型進行分層：物理層在專門的硬件/DSP/CPU上運行（尤其是BT、WLAN、GSM、UMTS）；低功耗在硬件和軟件中都采用“內置設計”（即通過時鐘/電壓等級、省電模式等）；較高層將在功耗更高的主CPU（或應用CPU）上運行；通常涉及到不同組織、路線圖、團隊、軟件語言、OS、工具和限制等。

　　作為通用規則系統架構應按照時間域布置軟件層：GSM中，每一幀的處理應在DSP上完成而不是主CPU（以前情況并非如此，通常項目預算也不允許完全重新設計），不過協議工作應在主CPU上完成。

　　以下例外情況如果可以實現，則將大大降低待機功耗：

　　GSM中：協議每0.5秒檢查用戶收到的信息是否為呼叫，這項工作可以轉交DSP，使主CPU有更長的睡眠時間。

　　WLAN中：每0.1秒—0.5秒進行一次RSSI和其它測量，但只有當動態下載極限超出上、下值并將產生動作時，才應激活主處理器。

　　惰性范式

　　一般情況下，所有算法設計時都考慮最差狀態下的最佳性能。如果有足夠的可用電源，這種方法不會產生任何問題，但通常情況下這一要求會過高，從而需要根據實際情況進行調整。

　　－每0.5秒查看鄰近小區可以產生良好的切換性能，而在空閑狀態下此動作可以被簡化。

　　－使用外部電源工作時（充電器、USB電纜），可以選擇最高性能的算法，而使用電池時則減少此類操作。

　　－只要用戶進行操作（如按鍵）就應激活高性能算法，但在一段時間內沒有任何操作，則應使用電池優化算法。

　　－軟件只應做必需的事情（在限制功耗狀態下），只在必要時刷新緩存，而不是采用自動定時刷新的方式。

　　－手機要考慮到環境的變化，如檢測“全天同一位置”與“不斷移動”的情況，以釋放網絡掃描等請求。

　　-高級節能措施還需要考慮電池狀態的變化：如果電池電量下降，則移動切換速度、TX功率、屏幕刷新等性能也需要進一步降低。

　　－系統范式需要全局接口以及應用于整個系統的單一設計，如“使用電池”與“使用電源”狀態或活動指示等。所有算法都需要這些信息。

　　關鍵軟件設計

　　替換“Do…While”循環

　　嵌入軟件一般具有很多以并行邏輯運行的RTK任務。多數情況下，軟件需要等待某個條件為真，如“AP已關聯”、“IP地址已分配”和“呼叫已建立”等。最初采用一種簡單的方案（經常用于“C”語言），即在一個任務中使用“Do…while”命令，并用循環輪詢來獲得較低優先級任務的結果（如IP協議棧）。

　　此時，CPU保持運行直至條件成立，這將導致高功耗。實際例子：等待顯示器完成刷新。

　　較好的方案是啟動RTK定時器，然后進入一段睡眠時間，過后再次檢索條件。這種方法原理上仍是一種“輪詢”，但減少了對功耗的影響，并可以采用不同的睡眠間隔度，動態地適應不同的性能需求。

　　更好的方案是采用RTK消息與中斷，當最終達到條件時激活主機。這樣能夠最大程度地降低功耗，不過中斷是一種稀有資源，而系統架構必須在設計時就考慮最高效功耗。不幸的是，功耗問題一般在產品生產后期才被發現，因此需要進行重新設計，但很少有人會重新設計。

　　定時器管理是關鍵

　　嵌入軟件經常需要從幾毫秒到數天的定時范圍，特別是硬件處理、軟件輪詢，或由標準給定（IP、電信等）。定時器到時需要激活CPU并運行RTK/OS程序。退出省電模式后需要一段時間來達到系統穩定，而返回省電模式也需要一些時間來準備下一次的正確激活。CPU激活一般非常快（在微秒范圍），但主時鐘仍需運行，這樣只節省了少量功耗。全系統的睡眠（包括主時鐘）可能需要5至20毫秒的激活時間，但只有這種方法才能提供最大的節能效果。

　　應盡可能避免出現定時器頻繁過期情況。給定900毫秒的定時器可以通過900x1毫秒、90x10毫秒、9x100毫秒的tick（時鐘計時單元）來實現，這樣做對功耗有著全然不同的影響。操作系統應使用最大tick長度。這意味著為獲得最大節能效果，必須盡可能放松對定時器精度的要求，例如不采用900毫秒（此時操作系統tick的時間間隔為100毫秒），實際應用中“1秒”可能已經足夠。手機擁有與實際空中接口物理層相關的系統tick。使用這些tick而不是人工的毫秒/秒單位，就可以減少激活的次數。GSM每幀4.615毫秒，使用這個時長為一個“tick”成為自然的選擇。語音采用多個20毫秒做為時間間隔，需要不同的tick。WLAN信標基于100毫秒的自然tick間隔。

　　功耗問題將永遠存在

　　手機行業屬于快速變化的行業，每年都會在新款手機上增添很多新功能，而用戶期望的使用時間卻與上一代手機一致，甚至更長。即使在更大屏幕尺寸、更大畫面尺寸、更多可存儲音樂，以及更多的接入網方式（用戶甚至經常看不到）的情況下，用戶對電池使用時間的預期依然不變。鑒于提高電池容量