虛擬機(jī)和隨機(jī)調(diào)度技術(shù)簡化無線設(shè)計(jì)

虛擬機(jī)和隨機(jī)調(diào)度技術(shù)簡化無線設(shè)計(jì)

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

圖 1 傳統(tǒng)豎井方式開發(fā)采用縱向?qū)崿F(xiàn)方法，缺乏與其它棧的橫向集成。

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

圖 2 一種替代的開發(fā)方法將第一層軟件體系結(jié)構(gòu)建立在虛擬機(jī)的基礎(chǔ)上。

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

圖 3 虛擬機(jī)運(yùn)行期具有資源管理和調(diào)度功能，可將執(zhí)行元件與引擎分離開來。

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