摘要：本文介紹了基于title="DSP">DSP/BIOS 實時內核的TI DSP 應用程序參考框架RF5。另外，面對目前越來越多的多處理器系統設計以及典型的GPP-DSP 架構，本文提出了一種改進的DSP應用程序框架ERF5 以最大化地支持這種架構。ERF5 主要從GPP-DSP 有效通信、任務線程的高效執行與調度以及任務線程顆粒度的合理化三個方面對RF5 進行了改進，并已成功應用于實際項目。

　　1 引言

　　隨著通信與信息技術的發展以及數字產品的普及，DSP 被越來越多地應用于各種數字系統中。作為業界領先的數字信號處理器供應商的美國德州儀器（TI）公司于上世紀90 年代開發了能在其DSP 產品上運行的實時內核DSP/BIOS，并提出一系列DSP 軟件參考框架（Reference Framework, RF）來幫助DSP 應用開發人員加速軟件的開發進程。然而，國內針對DSP 應用程序框架設計的研究還并不多且研究工作大多圍繞在如何使用現有的TI 參考框架上，鮮有對其使用局限性的討論與改進方案。

　　本文首先簡單介紹了由 TI 所提出的DSP 應用程序參考設計框架RF5 及其適用領域，然后在它的基礎上針對目前使用越來越多的多處理器系統提出了一個對RF5 改進后的DSP 應用程序框架ERF5（Enhanced Referenced Framework Level 5），并在其中定義了一套DSP 與系統中作為核心控制單元的外部通用處理器GPP 進行通信的良好機制，從而能夠實現DSP的任務調度與執行過程受控于GPP，使DSP 的運行狀態能夠高效地切換于多套功能獨立的數字信號處理算法。

　　2 RF5 應用程序框架

　　TI 在eXpressDSP 概念中提出了一系列DSP 應用程序參考框架以滿足不同應用場合的需要，其中包括RF1（Reference Framework Level 1）、RF3（Reference Framework Level 3）和RF5[1][2]。與RF1 和RF3 相比，RF5 是功能最強大的DSP 應用程序參考框架，它適用于多通道、多算法的高密集型DSP 應用系統，RF5 同時支持了靜態和動態DSP/BIOS 模塊對象的創建，支持1－100 個數據處理通道和XDAIS 算法，支持由DSP/BIOS 任務對象TSK實現的線程調度機制，支持線程阻塞，因此被廣泛應用于音視頻信號處理等復雜數字信號處理系統當中。圖1 給出了基于RF5 的DSP 應用程序框架。

　　圖1 RF5 應用程序框架

　　TI 為RF5 應用程序參考框架定義了4 種數據處理基本元素，分別是任務（Task）、通道（Channel）、算法單元（Cell）和XDAIS 算法。RF5 框架的最高層次是任務，任務可以由單個或多個通道構成，它通過與設備驅動程序或其它任務通信來在較高的層次控制數據的流向，每個任務體都可以歸結為“獲取數據－處理各通道中的信號－發送結果數據”的迭代過程。每個通道元素由一系列順序執行的信號處理算法單元構成，算法單元是一個XDAIS 算法的封裝，其作用是為XDAIS 算法與外部應用程序提供一套標準的接口，它必須實現ICELL接口模塊。

　　RF5 除了定義以上4 種數據處理元素之外，還提出了數據通信元素的概念以保證能在任務與DSP 外設之間、任務與任務之間和算法單元之間進行高效數據通信?；贒SP/BIOS開發的DSP 應用程序中的數據通信方式可分為任務級數據通信和算法單元級數據通信。對于任務級數據通信方式，在RF5 中采用SIO（STream IO）對象和SCOM（SynchronizedCommunication）消息來實現。對于算法單元級數據通信，RF5 使用ICC（Inter-CellCommunication）對象和ICC 對象列表來實現。

　　3 改進的DSP 應用程序框架ERF5

　　隨著嵌入式系統復雜度的不斷提高，又限于DSP 不適合進行復雜系統的流程控制，所以近年來在系統設計中往往更多地讓DSP 扮演著協處理器的角色，將其從繁重復雜的系統控制任務中解放出來，而整個系統的流程控制則交由一個通用處理器GPP 來完成，這使得DSP 和GPP 能夠優勢互補。然而RF5 在多機通信方面存在很大缺陷，它不適用于多處理器系統，尤其是DSP 作為多處理器系統中從設備的應用環境。另外，RF5 所實現的是單一功能的多任務系統，其多任務特性僅僅表現在將一個功能單一的任務拆分成輸入－處理－輸出三個分任務而已，并沒有實現真正的多功能多任務系統，即一個任務就是一個獨立的信號處理功能。

　　基于上述兩個方面的分析，我們完全有必要改進 RF5 以滿足基于多處理器的復雜信號處理系統的要求。本文所提出的ERF5 的系統框圖如圖2 所示，任務1、任務2、任務3 是系統中定義的三個任務，它們以同等的優先級被DSP/BIOS 任務調度器輪流調度。每個任務皆包含了輸入預處理、核心信號處理以及輸出后處理三個模塊，構成功能完整且獨立的信號處理任務，每個任務由單個或多個數據處理通道（Channel）組成，而每個通道又由一系列算法單元（Cell）構成。多處理器系統中的GPP 通過DSP 運行控制寄存器DSP_CNTL 來控制DSP 的任務執行過程，而DSP 作為響應會將其運行狀態反應在DSP 運行狀態寄存器DSP_STAT 中?？偟膩碚f，ERF5 從以下三個方面對RF5 進行了改進：

　　定義并實現了 DSP 與GPP 之間進行通信的有效方式；給出了當 DSP 需要實現多套信號處理功能并且某一套信號處理任務的執行完全受控于GPP 時的任務實現框架；對 RF5 中不合理的任務拆分進行了合并，減輕了由于DSP/BIOS 任務調度對系統性能的影響。

　　圖 2 ERF5 應用程序框架

　　3.1 主從通信方式

　　我們在DSP 的存儲空間中定義了兩個寄存器：DSP 運行控制寄存器（DSP_CNTL）和DSP 運行狀態寄存器（DSP_STAT）。在DSP_CNTL 中可以定義一系列控制字段用來表示外部主機對DSP 的各種控制操作，而在DSP_STAT 中可以定義一些與DSP_CNTL 相對應的描述DSP 當前運行狀態的字段信息。GPP 通過合理地設置DSP_CNTL 以命令DSP 執行相應的操作，而DSP 在響應了CPU 的命令后會設置好DSP_STAT 以告知CPU 目前DSP 的運行情況。

　　另外，為了便于 DSP 與主機進行數據交換，ERF5 在DSP 的存儲空間中開辟了兩塊專用于在DSP 與GPP 之間進行數據交換的緩沖區，并在DSP 運行狀態寄存器DSP_STAT 中定義一個緩沖區標志位PPFLG 以告知主機當前它所能訪問的乒乓緩沖區是“乒”或是“乓”，使得主機和DSP 之間的數據交互能夠彼此相對獨立地進行。

　　3.2 任務實現模型

　　在明確了主機與DSP 的通信方式以后，下面需要解決的就是如何在應用程序框架中給出合理的任務實現模型使它既能支持主機對DSP 的有效控制又能盡可能地減小DSP/BIOS的任務調度開銷。這里以我們的實際項目為例來闡述任務的實現模型。在我們的H.264 混合編解碼系統中，DM642 需要運行三個相互獨立的任務：視頻編碼任務、視頻解碼任務和視頻直通任務，在任意時刻，這三個任務線程的核心處理過程運行與否完全受GPP 控制。首先，出于對系統性能的考慮，我們都以靜態配置的方式在DSP/BIOS 中定義這3 個任務，這樣在系統運行時不需要花費由于任務動態創建所帶來的不可避免的性能開銷。顯然這3 個任務應該具有同等優先級，否則，由于DSP/BIOS 實時內核的搶占性特征將使得某些高優先級的任務始終搶占那些低優先級任務的執行權即使GPP 在某些時刻并沒有啟動那些高優先級的任務。此外，由于DSP/BIOS 周期性地調度系統中所有處于就緒狀態下的任務，所以必須使每個任務中判斷其主體處理過程是否執行的邏輯和任務切換邏輯盡可能短小，因為這段代碼在系統執行時將被頻繁地調用。另外需要注意的是應該使用TSK_sleep(…)函數來實現任務切換邏輯以使當前沒有被GPP 命令執行的任務被阻塞一段時間（該時間間隔應該至少是系統中各個周期性任務的最大執行周期），否則DSP/BIOS 任務調度器會頻繁調度該任務以至于影響到其它任務的正常執行。下面以視頻直通任務為例給出其任務執行流程圖如圖3所示。

　　圖3 視頻直通任務的執行流程圖

　　3.3 任務拆分與合并

　　DSP/BIOS 實時內核能保證運行在它之上的所有任務在適當的時刻被正確地調度。在通常情況下，系統中運行的任務越多，花費在DSP/BIOS 任務調度上的時間也就越多，單任務系統花費最少的任務調度時間，因此在一個應用框架中應該合理地規定任務的規模，過細或過粗地劃分任務都將為系統性能帶來負面影響。在ERF5 中，每個功能獨立的信號處理模塊分別定義成一個任務線程，其中包含了與當前信號處理功能相對應的數據輸入預處理和數據輸出后處理部分，在一個獨立的任務線程中將可以使用EDMA 等外設模塊實現的處理算法與必須由CPU 參與運算的算法獨立開來，并在它們之間引入雙緩沖以模擬流水線機理，這樣就把原先的任務線程之間的通信變換為在單個任務線程內的算法單元之間的通信，使得任務線程之間的通信和數據交換由于線程的獨立性而被最小化，從而有效避免了由于線程通信造成系統死鎖情況的發生。

　　4 性能分析

　　本節以 CPU 負載為指標在本文所提出的應用程序框架和RF5 之間進行性能比較與分析。為了使實驗結果更具有說服力，我們使用TMS320DM642 *估板中的MPEG2 編解碼例程作為RF5 框架的一個實現范例，另外，我們又采用本文所提出的ERF5 實現了MPEG2 編解碼系統，兩者使用同樣的符合XDAIS 算法標準的MPEG2 編解碼算法庫。這里我們將CPU負載定義為：

　　對于一個視頻信號處理系統來說，一般要求系統能在 1 秒內處理25－30 幀圖像數據，因此不妨將其作為上述視頻編解碼系統的實時性指標，即系統對一幀圖像進行編碼或解碼的最大周期為33－40 毫秒。根據以上計算公式作出RF5 和改進的應用程序框架的CPU 負載圖如圖4 所示。從圖中可以看出ERF5 的CPU 占用率與RF5 基本相近，甚至要稍好于RF5，若將它應用在視頻信號處理領域，其CPU 占用率只有7.92%－9.50%，完全滿足實際應用的需要。

　　圖 4 MPEG2 編解碼系統中ERF5 與RF5 的CPU 負載比較圖

　　5 總結

　　本文簡單介紹了 TI DSP 參考框架RF5，并提出ERF5 應用程序框架，它解決了RF5 不能被有效地應用于以DSP 作為協處理器的多處理器復雜數字信號處理系統當中的問題，且CPU 占用率與RF5 相當。從我們的實際項目經驗證明，RF5 適用于以TI DSP 作為主控和主處理單元的單處理器信號處理系統，并能得到良好的性能；ERF5 能對多處理器系統給予最大化的支持，并已成功應用于一個復雜的H.264 混合編解碼系統當中。