|
1 引言 隨著(zhù)通信與信息技術(shù)的發(fā)展以及數字產(chǎn)品的普及，DSP 被越來(lái)越多地應用于各種數字系統中。作為業(yè)界領(lǐng)先的數字信號處理器供應商的美國德州儀器（TI）公司于上世紀90 年代開(kāi)發(fā)了能在其DSP 產(chǎn)品上運行的實(shí)時(shí)內核DSP/BIOS，并提出一系列DSP 軟件參考框架（Reference Framework, RF）來(lái)幫助DSP 應用開(kāi)發(fā)人員加速軟件的開(kāi)發(fā)進(jìn)程。然而，國內針對DSP 應用程序框架設計的研究還并不多且研究工作大多圍繞在如何使用現有的TI 參考框架上，鮮有對其使用局限性的討論與改進(jìn)方案。 本文首先簡(jiǎn)單介紹了由 TI 所提出的DSP 應用程序參考設計框架RF5 及其適用領(lǐng)域，然后在它的基礎上針對目前使用越來(lái)越多的多處理器系統提出了一個(gè)對RF5 改進(jìn)后的DSP 應用程序框架ERF5（Enhanced Referenced Framework Level 5），并在其中定義了一套DSP 與系統中作為核心控制單元的外部通用處理器GPP 進(jìn)行通信的良好機制，從而能夠實(shí)現DSP的任務(wù)調度與執行過(guò)程受控于GPP，使DSP 的運行狀態(tài)能夠高效地切換于多套功能獨立的數字信號處理算法。 2 RF5 應用程序框架 TI 在eXpressDSP 概念中提出了一系列DSP 應用程序參考框架以滿(mǎn)足不同應用場(chǎng)合的需要，其中包括RF1（Reference Framework Level 1）、RF3（Reference Framework Level 3）和RF5[1][2]。與RF1 和RF3 相比，RF5 是功能最強大的DSP 應用程序參考框架，它適用于多通道、多算法的高密集型DSP 應用系統，RF5 同時(shí)支持了靜態(tài)和動(dòng)態(tài)DSP/BIOS 模塊對象的創(chuàng )建，支持1－100 個(gè)數據處理通道和XDAIS 算法，支持由DSP/BIOS 任務(wù)對象TSK實(shí)現的線(xiàn)程調度機制，支持線(xiàn)程阻塞，因此被廣泛應用于音視頻信號處理等復雜數字信號處理系統當中。圖1 給出了基于RF5 的DSP 應用程序框架。 圖1 RF5 應用程序框架 TI 為RF5 應用程序參考框架定義了4 種數據處理基本元素，分別是任務(wù)（Task）、通道（Channel）、算法單元（Cell）和XDAIS 算法。RF5 框架的最高層次是任務(wù)，任務(wù)可以由單個(gè)或多個(gè)通道構成，它通過(guò)與設備驅動(dòng)程序或其它任務(wù)通信來(lái)在較高的層次控制數據的流向，每個(gè)任務(wù)體都可以歸結為“獲取數據－處理各通道中的信號－發(fā)送結果數據”的迭代過(guò)程。每個(gè)通道元素由一系列順序執行的信號處理算法單元構成，算法單元是一個(gè)XDAIS 算法的封裝，其作用是為XDAIS 算法與外部應用程序提供一套標準的接口，它必須實(shí)現ICELL接口模塊。 RF5 除了定義以上4 種數據處理元素之外，還提出了數據通信元素的概念以保證能在任務(wù)與DSP 外設之間、任務(wù)與任務(wù)之間和算法單元之間進(jìn)行高效數據通信�；贒SP/BIOS開(kāi)發(fā)的DSP 應用程序中的數據通信方式可分為任務(wù)級數據通信和算法單元級數據通信。對于任務(wù)級數據通信方式，在RF5 中采用SIO（Stream IO）對象和SCOM（SynchronizedCommunication）消息來(lái)實(shí)現。對于算法單元級數據通信，RF5 使用ICC（Inter-CellCommunication）對象和ICC 對象列表來(lái)實(shí)現。 3 改進(jìn)的DSP 應用程序框架ERF5 隨著(zhù)嵌入式系統復雜度的不斷提高，又限于DSP 不適合進(jìn)行復雜系統的流程控制，所以近年來(lái)在系統設計中往往更多地讓DSP 扮演著(zhù)協(xié)處理器的角色，將其從繁重復雜的系統控制任務(wù)中解放出來(lái)，而整個(gè)系統的流程控制則交由一個(gè)通用處理器GPP 來(lái)完成，這使得DSP 和GPP 能夠優(yōu)勢互補。然而RF5 在多機通信方面存在很大缺陷，它不適用于多處理器系統，尤其是DSP 作為多處理器系統中從設備的應用環(huán)境。另外，RF5 所實(shí)現的是單一功能的多任務(wù)系統，其多任務(wù)特性?xún)H僅表現在將一個(gè)功能單一的任務(wù)拆分成輸入－處理－輸出三個(gè)分任務(wù)而已，并沒(méi)有實(shí)現真正的多功能多任務(wù)系統，即一個(gè)任務(wù)就是一個(gè)獨立的信號處理功能。 基于上述兩個(gè)方面的分析，我們完全有必要改進(jìn) RF5 以滿(mǎn)足基于多處理器的復雜信號處理系統的要求。本文所提出的ERF5 的系統框圖如圖2 所示，任務(wù)1、任務(wù)2、任務(wù)3 是系統中定義的三個(gè)任務(wù)，它們以同等的優(yōu)先級被DSP/BIOS 任務(wù)調度器輪流調度。每個(gè)任務(wù)皆包含了輸入預處理、核心信號處理以及輸出后處理三個(gè)模塊，構成功能完整且獨立的信號處理任務(wù)，每個(gè)任務(wù)由單個(gè)或多個(gè)數據處理通道（Channel）組成，而每個(gè)通道又由一系列算法單元（Cell）構成。多處理器系統中的GPP 通過(guò)DSP 運行控制寄存器DSP_CNTL 來(lái)控制DSP 的任務(wù)執行過(guò)程，而DSP 作為響應會(huì )將其運行狀態(tài)反應在DSP 運行狀態(tài)寄存器DSP_STAT 中�？偟膩�(lái)說(shuō)，ERF5 從以下三個(gè)方面對RF5 進(jìn)行了改進(jìn)： 定義并實(shí)現了 DSP 與GPP 之間進(jìn)行通信的有效方式；給出了當 DSP 需要實(shí)現多套信號處理功能并且某一套信號處理任務(wù)的執行完全受控于GPP 時(shí)的任務(wù)實(shí)現框架；對 RF5 中不合理的任務(wù)拆分進(jìn)行了合并，減輕了由于DSP/BIOS 任務(wù)調度對系統性能的影響。 圖 2 ERF5 應用程序框架 3.1 主從通信方式 我們在DSP 的存儲空間中定義了兩個(gè)寄存器：DSP 運行控制寄存器（DSP_CNTL）和DSP 運行狀態(tài)寄存器（DSP_STAT）。在DSP_CNTL 中可以定義一系列控制字段用來(lái)表示外部主機對DSP 的各種控制操作，而在DSP_STAT 中可以定義一些與DSP_CNTL 相對應的描述DSP 當前運行狀態(tài)的字段信息。GPP 通過(guò)合理地設置DSP_CNTL 以命令DSP 執行相應的操作，而DSP 在響應了CPU 的命令后會(huì )設置好DSP_STAT 以告知CPU 目前DSP 的運行情況。 另外，為了便于 DSP 與主機進(jìn)行數據交換，ERF5 在DSP 的存儲空間中開(kāi)辟了兩塊專(zhuān)用于在DSP 與GPP 之間進(jìn)行數據交換的緩沖區，并在DSP 運行狀態(tài)寄存器DSP_STAT 中定義一個(gè)緩沖區標志位PPFLG 以告知主機當前它所能訪(fǎng)問(wèn)的乒乓緩沖區是“乒”或是“乓”，使得主機和DSP 之間的數據交互能夠彼此相對獨立地進(jìn)行。 3.2 任務(wù)實(shí)現模型 在明確了主機與DSP 的通信方式以后，下面需要解決的就是如何在應用程序框架中給出合理的任務(wù)實(shí)現模型使它既能支持主機對DSP 的有效控制又能盡可能地減小DSP/BIOS的任務(wù)調度開(kāi)銷(xiāo)。這里以我們的實(shí)際項目為例來(lái)闡述任務(wù)的實(shí)現模型。在我們的H.264 混合編解碼系統中，DM642 需要運行三個(gè)相互獨立的任務(wù)：視頻編碼任務(wù)、視頻解碼任務(wù)和視頻直通任務(wù)，在任意時(shí)刻，這三個(gè)任務(wù)線(xiàn)程的核心處理過(guò)程運行與否完全受GPP 控制。首先，出于對系統性能的考慮，我們都以靜態(tài)配置的方式在DSP/BIOS 中定義這3 個(gè)任務(wù)，這樣在系統運行時(shí)不需要花費由于任務(wù)動(dòng)態(tài)創(chuàng )建所帶來(lái)的不可避免的性能開(kāi)銷(xiāo)。顯然這3 個(gè)任務(wù)應該具有同等優(yōu)先級，否則，由于DSP/BIOS 實(shí)時(shí)內核的搶占性特征將使得某些高優(yōu)先級的任務(wù)始終搶占那些低優(yōu)先級任務(wù)的執行權即使GPP 在某些時(shí)刻并沒(méi)有啟動(dòng)那些高優(yōu)先級的任務(wù)。此外，由于DSP/BIOS 周期性地調度系統中所有處于就緒狀態(tài)下的任務(wù)，所以必須使每個(gè)任務(wù)中判斷其主體處理過(guò)程是否執行的邏輯和任務(wù)切換邏輯盡可能短小，因為這段代碼在系統執行時(shí)將被頻繁地調用。另外需要注意的是應該使用TSK_sleep(…)函數來(lái)實(shí)現任務(wù)切換邏輯以使當前沒(méi)有被GPP 命令執行的任務(wù)被阻塞一段時(shí)間（該時(shí)間間隔應該至少是系統中各個(gè)周期性任務(wù)的最大執行周期），否則DSP/BIOS 任務(wù)調度器會(huì )頻繁調度該任務(wù)以至于影響到其它任務(wù)的正常執行。下面以視頻直通任務(wù)為例給出其任務(wù)執行流程圖如圖3所示。 圖3 視頻直通任務(wù)的執行流程圖 3.3 任務(wù)拆分與合并 DSP/BIOS 實(shí)時(shí)內核能保證運行在它之上的所有任務(wù)在適當的時(shí)刻被正確地調度。在通常情況下，系統中運行的任務(wù)越多，花費在DSP/BIOS 任務(wù)調度上的時(shí)間也就越多，單任務(wù)系統花費最少的任務(wù)調度時(shí)間，因此在一個(gè)應用框架中應該合理地規定任務(wù)的規模，過(guò)細或過(guò)粗地劃分任務(wù)都將為系統性能帶來(lái)負面影響。在ERF5 中，每個(gè)功能獨立的信號處理模塊分別定義成一個(gè)任務(wù)線(xiàn)程，其中包含了與當前信號處理功能相對應的數據輸入預處理和數據輸出后處理部分，在一個(gè)獨立的任務(wù)線(xiàn)程中將可以使用EDMA 等外設模塊實(shí)現的處理算法與必須由CPU 參與運算的算法獨立開(kāi)來(lái)，并在它們之間引入雙緩沖以模擬流水線(xiàn)機理，這樣就把原先的任務(wù)線(xiàn)程之間的通信變換為在單個(gè)任務(wù)線(xiàn)程內的算法單元之間的通信，使得任務(wù)線(xiàn)程之間的通信和數據交換由于線(xiàn)程的獨立性而被最小化，從而有效避免了由于線(xiàn)程通信造成系統死鎖情況的發(fā)生。 4 性能分析 本節以 CPU 負載為指標在本文所提出的應用程序框架和RF5 之間進(jìn)行性能比較與分析。為了使實(shí)驗結果更具有說(shuō)服力，我們使用TMS320DM642 *估板中的MPEG2 編解碼例程作為RF5 框架的一個(gè)實(shí)現范例，另外，我們又采用本文所提出的ERF5 實(shí)現了MPEG2 編解碼系統，兩者使用同樣的符合XDAIS 算法標準的MPEG2 編解碼算法庫。這里我們將CPU負載定義為： 對于一個(gè)視頻信號處理系統來(lái)說(shuō)，一般要求系統能在 1 秒內處理25－30 幀圖像數據，因此不妨將其作為上述視頻編解碼系統的實(shí)時(shí)性指標，即系統對一幀圖像進(jìn)行編碼或解碼的最大周期為33－40 毫秒。根據以上計算公式作出RF5 和改進(jìn)的應用程序框架的CPU 負載圖如圖4 所示。從圖中可以看出ERF5 的CPU 占用率與RF5 基本相近，甚至要稍好于RF5，若將它應用在視頻信號處理領(lǐng)域，其CPU 占用率只有7.92%－9.50%，完全滿(mǎn)足實(shí)際應用的需要。 圖 4 MPEG2 編解碼系統中ERF5 與RF5 的CPU 負載比較圖 5 總結 本文簡(jiǎn)單介紹了 TI DSP 參考框架RF5，并提出ERF5 應用程序框架，它解決了RF5 不能被有效地應用于以DSP 作為協(xié)處理器的多處理器復雜數字信號處理系統當中的問(wèn)題，且CPU 占用率與RF5 相當。從我們的實(shí)際項目經(jīng)驗證明，RF5 適用于以TI DSP 作為主控和主處理單元的單處理器信號處理系統，并能得到良好的性能；ERF5 能對多處理器系統給予最大化的支持，并已成功應用于一個(gè)復雜的H.264 混合編解碼系統當中。 |
