基于DSP/BIOS 的TI DSP 應用程序框架設計

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

　　1 引言

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

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

　　2 RF5 應用程序框架

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

　　圖1 RF5 應用程序框架

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

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

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

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

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

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

　　圖 2 ERF5 應用程序框架[!--empirenews.page--]

　　3.1 主從通信方式

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

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

　　3.2 任務實現(xiàn)模型

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

　　圖3 視頻直通任務的執(zhí)行流程圖[!--empirenews.page--]

　　3.3 任務拆分與合并

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

　　4 性能分析

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

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

　　圖 4 MPEG2 編解碼系統(tǒng)中ERF5 與RF5 的CPU 負載比較圖

　　5 總結(jié)

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