虛擬機和隨機調度技術簡化無線設計

一種新的無線設計方法使設計師們能將多種基于分組的標準融合到資源受限的手機硬件中。
　　系統設計人員有時將用戶設備手機的傳統棧開發方法稱為“基于豎井”的開發方法，因為這種開發方法在軟件和硬件之間是極端縱向集成的，而且缺乏與其它棧的橫向集成（圖 1）。在實現多種基于分組的標準時，這種豎井方法就不適用了，因為它假設協議棧開發人員“擁有”基本的硬件資源，因而能夠做出有關資源的假定，例如臨時的和永久的緩存器分配。這些可用性假設在多模式環境中是毫無意義的，因為在基本時序上相互可能“沖突”的棧都會競相獲得各種資源，例如存儲器。
　　豎井方法假設你可以在設計時配置最壞情況下的系統裝入，從而使你可以在系統設計期間，而不是在運行時分配資源。但是，這種方法基本上不適用于多通道的基于分組的系統，因為其峰值資源裝入與平均資源裝入相差很大。另外，豎井方法還假設一個設計小組對系統進行編碼，并在開發期間，標準不會發生重大變化。對于現代通信系統來說，兩種假設都可能是錯誤的。
　　基于豎井方式的開發常常會使各種功能實現方法的資源使用率、調用格式以及行為等假設泄漏到設計的其它部分中，導致許多不良的設計習慣打著效率的旗號而付諸實現。例如，由于知道各種功能要花多少時間（以周期計）來執行，又知道每種功能函數需要多大的臨時存儲器，系統設計人員就會常常編寫出靜態的臨時存儲器調度程序，從而使得時間上不重疊的多個例行程序使用一個公共緩存器，由此避免代價可能很高的對 malloc()和 free()的不確定調用。但是，這樣的設計往往是脆弱的。如果你要重新實現任何引擎，造成資源分布特性、時序兩者之一或同時變更；如果基本硬件也要改變；更糟的是，如果某個棧與另一個棧一起共享基本資源（多模式問題），則從零開始的重新設計就不可避免了。

圖 1 傳統豎井方式開發采用縱向實現方法，缺乏與其它棧的橫向集成。

　　替代方法
　　與任何極為復雜的設計問題一樣，這一問題的最佳解決方法是將問題劃分為可以自主處理的不太復雜的塊。這種替代方法的基本概念模型在本文中稱為虛擬機方法，它假設一個通信棧的第一層被分解為執行件、虛擬機（運行期內核）和引擎（圖 2）。

圖 2 一種替代的開發方法將第一層軟件體系結構建立在虛擬機的基礎上。

　　對運行中的第一層軟件的分析表明：該軟件把 80～90% 的執行時間用于與無線設備相關的計算密集的信號處理變換。這些資源消耗大的功能包括傅里葉變換、矢量乘法、FIR 濾波器和采樣抽取器。實際上，這些變換在不同的無線設備中表現出高度的共通性。這些資源消耗大、基本與應用系統無關的元件，要么用專用硬件來實現，要么用平臺高度優化的軟件來實現。推薦的體系結構用一種特殊的方式處理資源消耗大的功能，即生成“引擎”。具體地說，這種體系結構要參照與其行為上等效的產品，對一些引擎進行性能試驗，剖析其性能，實現獨特形式的資源仿真。
　　剩余的 10% 處理資源（即執行元件）本質上是一種起控制作用的狀態機，可按專門的無線標準要求進行變換。執行程序通常是極其復雜的，但其所需的處理資源卻較少。這些資源消耗小的、基本上專用的元件很少包含天生就接合到基本硬件襯底上的資源。實際上，無論它們用硬件還是用軟件來實現引擎，它們都可以移植到使用相同虛擬機運行期內核的任何其它設計中。執行功能的實例在第三代設計中有：一個數據平面的總數據流表達式、采集與跟蹤邏輯以及各平面的通道生成和刪除。
　　替代方法建立在一個以瘦虛擬機運行期內核為核心的體系結構上。這種體系結構能將執行元件與高 MIPS 引擎分開。在其最簡化的級別上，它為半導體硬件和 RTOS 提供了使用可移植基帶軟件的抽象層。這種功能并不取代 RTOS；系統仍然使用引擎位于處理器（通常是一個 DSP）中的 RTOS 服務。虛擬機運行期元件需要識別公共的線程、中斷、內存和資源管理模型，然后設計師將這些模型映射到可用的原語中，以通過運行期實現方法生成任何第三方 RTOS。虛擬機還包括復雜的資源管理功能，這些功能對于解決第一層無線開發的瓶頸是至關重要的（圖 3）。

圖 3 虛擬機運行期具有資源管理和調度功能，可將執行元件與引擎分離開來。

　　從資源調度的角度看，如果高層代碼要直接調用引擎的話，則所有這些努力都將是徒勞的。直接調用或多或少會影響基本的執行順序和線程模型，而這對于高效的實現方法來說又非常關鍵。更糟的是，調用者要負責為基本引擎建立適當的存儲器，這實際上導致顯式的資源調度。在本文所述方法中，只有一個中間件服務（即虛擬機運行期內核）可以調用一個引擎。具體來說，該運行期內核包括一個調度程序，從效果來說，這一調度程序是一個跨越所有執行過程和邏輯線程的范例。它使用一種插入式的調度策略來決定把這些任務中的哪一個提交給基本的 RTOS 去執行，決定它將使用多少 RTOS 線程，并決定采用哪種優先級和邏輯時間步長。
　　仿真是關鍵
　　盡管你必須保證你的系統是正確的，但對資源管理做出適當判斷也是同樣必要的。當然，最壞情況分析是不恰當的，在多模式設計時會給出過于悲觀的結果，因而造成浪費。但是，利用性能仿真可以揭示出各種棧在時間上互相“沖突”的相關性。當執行元件調用引擎時，虛擬機資源仿真并不運行引擎本身，而是相當簡單地更新一張“資源使用記錄表”。在周期精確的仿真期間，或者在實際硬件執行期間，你都能通過一個性能剖析過程單獨采集到各個引擎的資源使用信息。這一剖析包含了一個相應獨立變量（例如矢量大小或位寬度）在某一范圍的數值對各種類型資源（內存、周期、總線帶寬等）的使用記錄。它可以隨機地表達出引擎資源的概況，例如，某個任務需要的周期數并不簡單地是其輸入范圍的確定函數。（例如，一個渦輪式編碼器處理較不完整的輸入矢量就要花更多的周期。）一個參量表保存著每個引擎的資源成本，它是引擎元件化描述的一部分