德州儀器(TI)的達芬奇(DaVinci)數字媒體技術平臺包括四大部分：芯片(處理器)、開發工具或開發套件、軟件及技術支持。其中軟件開發涉及到操作系統、音視頻編解碼算法及ARM和DSP之間的分工協作，讓很多工程師感到比較複雜。爲此TI推出了一系列軟件模塊和工具來建立Davinci軟件開發的框架，方便工程師在此基礎上快速的開發自己的產品。這些軟件模塊和工具包含在TI的基於達芬奇技術的數字視頻評估板的軟件開發包中。
一般的視頻應用系統中，Davinci的ARM負責操作系統應用，DSP負責運行音視頻codec算法處理，ARM通過TI的Codec Engine機制調用DSP側的codec。那麼怎樣把不同的codec算法集成到一個DSP可執行程序(稱爲DSP Server)中，又保證它們佔用的資源不衝突？本文從Davinci軟件結構入手，介紹如何構建DSP Server，及如何通過DSP Server的配置文件配置FC(Framework Component)，以便通過FC管理DSP的資源。
達芬奇DMSoC軟件概述
一般來講，軟件系統分爲應用層、信號處理層和I/O層三部分，TI提供的達芬奇參考軟件框架就是基於這樣的結構，如圖1所示。Davinci的應用工程師可以在系統的用戶空間在系統功能性上添加和發揮自己的特色。信號處理層通常都運行在DSP一側負責信號處理，包括音視頻編解碼算法、Codec Engine、DSP的實時操作系統DSP/BIOS及和ARM通信的模塊。I/O層就是我們通常所說的驅動，是針對Davinci外設模塊的驅動程序。
![]()
其中應用層通過Codec Engine的VISA(Video, Image, Speech, Audio)API來調用DSP側的算法，通過EPSI(Easy Peripheral Software Interface)API來訪問和操作Davinci的外設。這三個部分通常對應三個Davinci軟件開發小組。當然還需要一個系統集成工程師把這三個部分集成起來，不過VISA API和EPSI API的存在已經大大簡化了集成工作的複雜程度。
如圖2所示，DaVinci的軟件開發通常需要四個步驟(本文以codec運行在DSP爲例)：
![]()
第一步，工程師需要基於DSP利用CCS開發自己的音視頻編解碼算法，編譯生成一個編解碼算法的庫文件*.lib(等同於Linux環境下的*.a64P，直接在Linux環境下修改文件後綴名即可)。如果要通過Codec Engine調用這個庫文件中的算法函數，那麼這些算法實現需要符合xDM(xDAIS(eXpress DSP Algorithm Interface Standard) for Digital Media)標準；Codec Engine機制下不符合xDM標準的算法實現需要創建算法自己的Stub和Skeleton(具體請參考spraae7.pdf)。
第二步，生成一個在DSP上運行的可執行程序*.x64P(即.out文件)，也就是DSP Server。本文將詳細介紹這一步。
第三步，根據DSP Server的名字及其中包含的具體的音視頻編解碼算法創建Codec Engine的配置文件*.cfg。這個文件定義Engine的不同配置，包括Engine的名字、每個Engine裏包括的codecs及每個codec運行在ARM還是DSP側等等(具體說明，請參考sprue67.pdf的第5章Integrating an Engine)。
最後，應用工程師收到不同的codec包、DSP Server和Engine配置文件*.cfg，把自己的應用程序通過編譯、鏈接，最終生成ARM側可執行文件。
Codec Engine概述
前面我們提到，應用工程師通過調用Codec Engine的API來調用和運行符合xDAIS的算法(關於API的具體信息，請參考sprue67.pdf第4章)。在Davinci軟件中，符合 xDAIS的音視頻編解碼算法(即xDM算法)的調用是通過Codec Engine的VISA API完成的。Codec Engine通過這套API爲算法的執行提供了一個標準的軟件架構和接口，體現在以下幾個方面：
1. 通過Codec Engine API調用的算法可以運行在本地(ARM側)或者遠端(DSP側)；
2. Codec Engine可以基於ARM＋DSP、DSP或ARM上運行；
3. 無論Codec Engine運行在ARM還是DSP上，對應的Codec Engine API都是完全一致的；
4. Codec Engine的API與操作系統無關。比如Linux、VxWorks和WinCE環境下的Codec Engine API都是完全一致的。
Codec Engine是介於應用程序和具體算法之間的軟件模塊，其中的VISA API通過stub和skeleton訪問Engine SPI最終調用具體的算法。因此，Codec Engine的工作是通過完成VISA API的任務來體現的。VISA API分爲四部分VISA create/control/process/delete，我們以codec算法運行在DSP爲例，通過VISA API的執行過程瞭解Codec Engine的工作原理。
在調用VISA API之前需要在應用程序中通過Engine_open()這個Engine API把DSP的可執行程序加載到DSP的memory，同時把DSP從復位狀態釋放，這時DSP開始運行DSP Server的初始化程序在DSP側創建一個優先級最低的任務RMS(Remote Management Server)，RMS負責管理和維護對應到具體codec算法的Instances。如圖3所示，應用程序調用VISA create API，相應的VISA create函數到Engine SPI中的Codec table中查到這個codec運行在遠端DSP側。接着Engine SPI通過OSAL(Operating System Abstraction Layer)、DSP Link把VISA create的命令傳到DSP側的RMS。RMS通過DSP側Engine SPI的codec table找到要調用的codec算法後，就會在RMS中創建一個相應的Instance(即一個DSP/BIOS 系統中的任務)。VISA create會返回一個Instance的Handle，以便於給這個Instance做後續的VISA control/process/delete提供信息。VISA delete和VISA create原理類似，只是RMS刪除掉相應的codec算法的Instance和執行codec算法的任務。
![]()
概括來說，VISA control用來動態的修改codec instance的屬性，VISA process用來對算法的輸入數據流做處理並返回一個輸出數據流。如圖4所示，應用程序在調用VISA process/control時會通過xDM Stub把傳遞給codec算法的參數收集起來，並且轉換成DSP可以識別的物理地址。Stub把這些參數和相關的命令通過Engine SPI、OSAL和DSP Link傳遞到DSP側的Instance。Instance再通過Skeleton把傳遞過來的參數和命令解析出來，通過DSP側VISA control/process對codec算法執行control/process。
對Codec Engine有了基本工作原理的瞭解之後，我們就會更清楚的理解DSP的軟件怎樣配合應用程序工作及DSP Server中除算法之外還應該包括哪些內容。
創建DSP Server
對達芬奇的軟件來說，DSP Server也叫Codec Server。其中“codec”是一組算法。從圖3和4可以看到，除算法之外，DSP Server還集成了其他的軟件模塊(如DSP/BIOS、DSP Link、Codec Engine等)。
![]()
1. xDC簡介
達芬奇的軟件開發環境中，有一個DSP工程師比較陌生的工具xDC(Express DSP Component)。和gmake類似，xDC根據一套build指令build生成可執行文件。xDC同時也會build依賴文件，並且可以一次build多個目標對象的可執行文件(如圖5中的hello.x64P是DSP的可執行文件，hello.x470MV是ARM的可執行文件)。xDC的源文件可以是C程序、C++程序、彙編程序和庫文件等。
如圖5所示，xDC按照build指令，對DSP Server的源文件進行build(類似於make)生成DSP Server .x64P文件。這個過程可以分爲三部分：創建DSP Server的源文件；設置xDC的配置文件；執行“make”生成可執行文件。
![]()
2. DSP Server的源文件
以Codec Engine_1_02中的video_copy爲例，如圖6我們可以看到video_copy的DSP Server中包括和圖5對應的源文件main.c、video_copy.tcf和link.cmd。圖5中的packages是指圖3和圖4中的 codecs、RMS、Engine SPI和OSAL。接下來，我們可以通過xDC的配置文件看到如何把packages添加到Server中。
要構建DSP Server首先就需要創建main.c和server的DSP BIOS配置文件.tcf及link.cmd。我們提到engine_open會把DSP從復位狀態釋放，DSP Server程序開始運行初始化等等。這個初始化就是DSP Server main.c(見圖7)中的CERuntime_init()。除此之外在main.c中還可以打開Codec Engine的trace功能，讀取或更改main函數的參數等。
![]()
![]()
DSP BIOS的配置文件.tcf中定義DSP的memory map、設置DSP的復位/中斷向量表並且創建和初始化BIOS程序需要的各種數據對象(如圖8的.tcf)。在.tcf中我們只能定義編譯器默認的 sections(如.text和.bss等)。但是，我們可以在link.cmd中定義自己的sections(如圖8 link.cmd中.tables和.csl_vect等)。
![]()
3. xDC文件
在Linux中我們用make命令根據makefile來生成可執行文件，xDC也有類似的生成腳本文件(我們統稱爲xDC文件)。如圖6所示，其中package.bld、package.xdc和video_copy.cfg三個文件就是提供給xDC build DSP Server的xDC文件。
在package.xdc中聲明DSP Server的名字、它的路徑及Server的依賴文件。Package.bld文件的功能類似於Linux中的makefile，它會告訴xDC怎麼樣build DSP Server的源文件。如圖9所示在package.bld中定義target是C64P DSP、要生成針對target的可執行程序，其中配置腳本文件是video_copy.tcf(與圖8中的.tcf類似)、鏈接選項是鏈接link.cmd(與圖8中的link.cmd類似)文件，同時還要生成main.c的目標代碼。
![]()
xDC的強大之處還在於它提供給系統集成工程師一個強大的工具，這個工具可以用來把各種各樣的代碼模塊組合成自己的最終產品。其中xDC的配置文件就是DSP Server中的.cfg(例如圖5中的video_copy.cfg)負責系統級的管理。請注意這裏的.cfg文件不同於第一章提到的Codec Engine的.cfg文件(例如CE_INSTALL_DIR/examples/apps/video_copy/dualcpu /ceapp.cfg)，下文中提到的.cfg都是指DSP Server的.cfg文件。
xDC會根據以上提到的配置文件生成package.mak(類似於makefile)，並最終運行它來生成圖5所示的包括可執行文件的package。我們可以打開查看package.mak，但不能修改。因爲重新運行xDC之後會生成新的package.mak。
4. 設置xDC的配置文件
既然.cfg文件負責系統級的管理，我們需要先了解什麼需要管理？當然是DSP的資源，無非就是CPU cycles、memory及DMA。針對Davinci上DSP的軟件開發，TI提供了Framework Components來方便DSP軟件工程師使用DSP的 memory和DMA資源。xDM和xDAIS算法的Instance都向FC提出自己的資源請求，比如請求1KByte的memory或一個DMA通道。FC中的DSKT2和DMAN3就通過標準的、可以配置的方法給算法的instances分配資源(包括instances之間可以共享的資源)。舉例來說，有了DSKT2負責不同算法開發的工程師就不必擔心自己要用的某一段memory是否已經被別的算法佔用等一系列問題，因爲每一個算法的 memory都是由DSKT2分配的。
a. DSKT2 Framework
DSKT2負責管理系統中所有xDAIS算法的memory需求，它和應用層的接口非常簡單“Create, Execute, Delete”。系統集成工程師需要用所有可以利用的memory初始化DSKT2模塊。DSKT2模塊包括兩種類型的memory，永久性的 memory(只要這個算法存在，它就會佔用的memory)和scratch memory(算法之間可以共享的memory)。當一個算法被創建的時候，永久性memory纔會被DSKT2分配給這個算法，在算法被刪除的時候，這段memory被返回到heap。當一個算法申請scratch memory時，會被分配一個memory 'pool'，這個pool被擁有同一個scratch pool ID的其它算法共享。也就是說，共享scratch memory的算法屬於同一個優先級，不能中斷對方。
b. 配置DSP Server的.cfg文件
在.cfg文件中可以做以下三個部分的配置。
(1) Codec配置：每一個codec都被包含在各自的線程中； 配置每一個codec線程的屬性(線程優先級、堆棧大小和堆棧的memory資源)。具體請參考CE_INSTALL_DIR/xdoc/index.html。
(2) DSKT2配置： 把所有的IALG memory類型結合到可用的DSP memory；定義缺省的scratch組的memory大小。
(3) DMAN3配置：定義DMAN3可以管理的DMA通道號；定義DMAN3可以提供給算法的TCC號。
以video_copy.cfg爲例，對應到圖4所示的DSP Server部分，.cfg文件中對OSAL和codecs模塊做了聲明和定義。我們可以看到video_copy的server中包括VIDDEC_COPY和VIDENC_COPY兩個codec。
![]()
接着對server進行配置，包括各個線程的屬性配置。Codec engine將自動匹配算法的scratch memory ID和算法線程的優先級，保證安全操作。
![]()
對DSKT2的配置，參看下面的例子。需要注意的是這裏的每一個scratch memory pool的大小通過數組的形式定義，數組的第一個元素對應scratch pool ID0，第二個元素對應scratch pool ID2，依次類推。
![]()
以下是DMAN3的配置例子。因爲DMA需要memory存放PARAM和其他的通道配置，所以在DMAN3分配有heap(分爲internal heap和external heap)。DMAN3的PARAM是通過它自己的base index和數量分配的，本例分配給DMAN3 48個PARAM。從這個例子中我們還可以看到DMAN3有8個可用的QDMA通道，tcc是通過bit mask來分配的。
![]()
5. xDC的build 過程
xDC的調用是通過執行命令 XDC完成的。在此之前，我們需要做以下幾步：
a. 在config.bld中定義平臺(ARM或DSP)，config.bld所在路徑由xdcbuildcfg定義；
b. 在package.xdc中定義package，package.xdc在當前路徑下(如圖6的video_copy示例)；
c. 在package.bld中定義要build的可執行文件和庫文件，package.bld在當前路徑下(如圖6的video_copy示例)；
d. 按照前面的介紹根據自己的應用修改server的.cfg文件。
執行XDC後先產生package.mak，XDC再運行package.mak生成包含可執行文件的package。
本文小結
以上的介紹基於工程師在實際開發過程中遇到的一些問題。我們希望通過這篇文章可以先理清思路，然後工程師可以有針對性的進一步研究和學習。要想了解更多的構建DSP Server的細節還請大家參考sprued5.pdf及文中提到的用戶手冊和應用文檔
原帖地址http://www.devdiv.net/viewthread.php?tid=3912&highlight=DSP%2Bvincent
一般的視頻應用系統中，Davinci的ARM負責操作系統應用，DSP負責運行音視頻codec算法處理，ARM通過TI的Codec Engine機制調用DSP側的codec。那麼怎樣把不同的codec算法集成到一個DSP可執行程序(稱爲DSP Server)中，又保證它們佔用的資源不衝突？本文從Davinci軟件結構入手，介紹如何構建DSP Server，及如何通過DSP Server的配置文件配置FC(Framework Component)，以便通過FC管理DSP的資源。
達芬奇DMSoC軟件概述
一般來講，軟件系統分爲應用層、信號處理層和I/O層三部分，TI提供的達芬奇參考軟件框架就是基於這樣的結構，如圖1所示。Davinci的應用工程師可以在系統的用戶空間在系統功能性上添加和發揮自己的特色。信號處理層通常都運行在DSP一側負責信號處理，包括音視頻編解碼算法、Codec Engine、DSP的實時操作系統DSP/BIOS及和ARM通信的模塊。I/O層就是我們通常所說的驅動，是針對Davinci外設模塊的驅動程序。
其中應用層通過Codec Engine的VISA(Video, Image, Speech, Audio)API來調用DSP側的算法，通過EPSI(Easy Peripheral Software Interface)API來訪問和操作Davinci的外設。這三個部分通常對應三個Davinci軟件開發小組。當然還需要一個系統集成工程師把這三個部分集成起來，不過VISA API和EPSI API的存在已經大大簡化了集成工作的複雜程度。
如圖2所示，DaVinci的軟件開發通常需要四個步驟(本文以codec運行在DSP爲例)：
第一步，工程師需要基於DSP利用CCS開發自己的音視頻編解碼算法，編譯生成一個編解碼算法的庫文件*.lib(等同於Linux環境下的*.a64P，直接在Linux環境下修改文件後綴名即可)。如果要通過Codec Engine調用這個庫文件中的算法函數，那麼這些算法實現需要符合xDM(xDAIS(eXpress DSP Algorithm Interface Standard) for Digital Media)標準；Codec Engine機制下不符合xDM標準的算法實現需要創建算法自己的Stub和Skeleton(具體請參考spraae7.pdf)。
第二步，生成一個在DSP上運行的可執行程序*.x64P(即.out文件)，也就是DSP Server。本文將詳細介紹這一步。
第三步，根據DSP Server的名字及其中包含的具體的音視頻編解碼算法創建Codec Engine的配置文件*.cfg。這個文件定義Engine的不同配置，包括Engine的名字、每個Engine裏包括的codecs及每個codec運行在ARM還是DSP側等等(具體說明，請參考sprue67.pdf的第5章Integrating an Engine)。
最後，應用工程師收到不同的codec包、DSP Server和Engine配置文件*.cfg，把自己的應用程序通過編譯、鏈接，最終生成ARM側可執行文件。
Codec Engine概述
前面我們提到，應用工程師通過調用Codec Engine的API來調用和運行符合xDAIS的算法(關於API的具體信息，請參考sprue67.pdf第4章)。在Davinci軟件中，符合 xDAIS的音視頻編解碼算法(即xDM算法)的調用是通過Codec Engine的VISA API完成的。Codec Engine通過這套API爲算法的執行提供了一個標準的軟件架構和接口，體現在以下幾個方面：
1. 通過Codec Engine API調用的算法可以運行在本地(ARM側)或者遠端(DSP側)；
2. Codec Engine可以基於ARM＋DSP、DSP或ARM上運行；
3. 無論Codec Engine運行在ARM還是DSP上，對應的Codec Engine API都是完全一致的；
4. Codec Engine的API與操作系統無關。比如Linux、VxWorks和WinCE環境下的Codec Engine API都是完全一致的。
Codec Engine是介於應用程序和具體算法之間的軟件模塊，其中的VISA API通過stub和skeleton訪問Engine SPI最終調用具體的算法。因此，Codec Engine的工作是通過完成VISA API的任務來體現的。VISA API分爲四部分VISA create/control/process/delete，我們以codec算法運行在DSP爲例，通過VISA API的執行過程瞭解Codec Engine的工作原理。
在調用VISA API之前需要在應用程序中通過Engine_open()這個Engine API把DSP的可執行程序加載到DSP的memory，同時把DSP從復位狀態釋放，這時DSP開始運行DSP Server的初始化程序在DSP側創建一個優先級最低的任務RMS(Remote Management Server)，RMS負責管理和維護對應到具體codec算法的Instances。如圖3所示，應用程序調用VISA create API，相應的VISA create函數到Engine SPI中的Codec table中查到這個codec運行在遠端DSP側。接着Engine SPI通過OSAL(Operating System Abstraction Layer)、DSP Link把VISA create的命令傳到DSP側的RMS。RMS通過DSP側Engine SPI的codec table找到要調用的codec算法後，就會在RMS中創建一個相應的Instance(即一個DSP/BIOS 系統中的任務)。VISA create會返回一個Instance的Handle，以便於給這個Instance做後續的VISA control/process/delete提供信息。VISA delete和VISA create原理類似，只是RMS刪除掉相應的codec算法的Instance和執行codec算法的任務。
概括來說，VISA control用來動態的修改codec instance的屬性，VISA process用來對算法的輸入數據流做處理並返回一個輸出數據流。如圖4所示，應用程序在調用VISA process/control時會通過xDM Stub把傳遞給codec算法的參數收集起來，並且轉換成DSP可以識別的物理地址。Stub把這些參數和相關的命令通過Engine SPI、OSAL和DSP Link傳遞到DSP側的Instance。Instance再通過Skeleton把傳遞過來的參數和命令解析出來，通過DSP側VISA control/process對codec算法執行control/process。
對Codec Engine有了基本工作原理的瞭解之後，我們就會更清楚的理解DSP的軟件怎樣配合應用程序工作及DSP Server中除算法之外還應該包括哪些內容。
創建DSP Server
對達芬奇的軟件來說，DSP Server也叫Codec Server。其中“codec”是一組算法。從圖3和4可以看到，除算法之外，DSP Server還集成了其他的軟件模塊(如DSP/BIOS、DSP Link、Codec Engine等)。
1. xDC簡介
達芬奇的軟件開發環境中，有一個DSP工程師比較陌生的工具xDC(Express DSP Component)。和gmake類似，xDC根據一套build指令build生成可執行文件。xDC同時也會build依賴文件，並且可以一次build多個目標對象的可執行文件(如圖5中的hello.x64P是DSP的可執行文件，hello.x470MV是ARM的可執行文件)。xDC的源文件可以是C程序、C++程序、彙編程序和庫文件等。
如圖5所示，xDC按照build指令，對DSP Server的源文件進行build(類似於make)生成DSP Server .x64P文件。這個過程可以分爲三部分：創建DSP Server的源文件；設置xDC的配置文件；執行“make”生成可執行文件。
2. DSP Server的源文件
以Codec Engine_1_02中的video_copy爲例，如圖6我們可以看到video_copy的DSP Server中包括和圖5對應的源文件main.c、video_copy.tcf和link.cmd。圖5中的packages是指圖3和圖4中的 codecs、RMS、Engine SPI和OSAL。接下來，我們可以通過xDC的配置文件看到如何把packages添加到Server中。
要構建DSP Server首先就需要創建main.c和server的DSP BIOS配置文件.tcf及link.cmd。我們提到engine_open會把DSP從復位狀態釋放，DSP Server程序開始運行初始化等等。這個初始化就是DSP Server main.c(見圖7)中的CERuntime_init()。除此之外在main.c中還可以打開Codec Engine的trace功能，讀取或更改main函數的參數等。
DSP BIOS的配置文件.tcf中定義DSP的memory map、設置DSP的復位/中斷向量表並且創建和初始化BIOS程序需要的各種數據對象(如圖8的.tcf)。在.tcf中我們只能定義編譯器默認的 sections(如.text和.bss等)。但是，我們可以在link.cmd中定義自己的sections(如圖8 link.cmd中.tables和.csl_vect等)。
3. xDC文件
在Linux中我們用make命令根據makefile來生成可執行文件，xDC也有類似的生成腳本文件(我們統稱爲xDC文件)。如圖6所示，其中package.bld、package.xdc和video_copy.cfg三個文件就是提供給xDC build DSP Server的xDC文件。
在package.xdc中聲明DSP Server的名字、它的路徑及Server的依賴文件。Package.bld文件的功能類似於Linux中的makefile，它會告訴xDC怎麼樣build DSP Server的源文件。如圖9所示在package.bld中定義target是C64P DSP、要生成針對target的可執行程序，其中配置腳本文件是video_copy.tcf(與圖8中的.tcf類似)、鏈接選項是鏈接link.cmd(與圖8中的link.cmd類似)文件，同時還要生成main.c的目標代碼。
xDC的強大之處還在於它提供給系統集成工程師一個強大的工具，這個工具可以用來把各種各樣的代碼模塊組合成自己的最終產品。其中xDC的配置文件就是DSP Server中的.cfg(例如圖5中的video_copy.cfg)負責系統級的管理。請注意這裏的.cfg文件不同於第一章提到的Codec Engine的.cfg文件(例如CE_INSTALL_DIR/examples/apps/video_copy/dualcpu /ceapp.cfg)，下文中提到的.cfg都是指DSP Server的.cfg文件。
xDC會根據以上提到的配置文件生成package.mak(類似於makefile)，並最終運行它來生成圖5所示的包括可執行文件的package。我們可以打開查看package.mak，但不能修改。因爲重新運行xDC之後會生成新的package.mak。
4. 設置xDC的配置文件
既然.cfg文件負責系統級的管理，我們需要先了解什麼需要管理？當然是DSP的資源，無非就是CPU cycles、memory及DMA。針對Davinci上DSP的軟件開發，TI提供了Framework Components來方便DSP軟件工程師使用DSP的 memory和DMA資源。xDM和xDAIS算法的Instance都向FC提出自己的資源請求，比如請求1KByte的memory或一個DMA通道。FC中的DSKT2和DMAN3就通過標準的、可以配置的方法給算法的instances分配資源(包括instances之間可以共享的資源)。舉例來說，有了DSKT2負責不同算法開發的工程師就不必擔心自己要用的某一段memory是否已經被別的算法佔用等一系列問題，因爲每一個算法的 memory都是由DSKT2分配的。
a. DSKT2 Framework
DSKT2負責管理系統中所有xDAIS算法的memory需求，它和應用層的接口非常簡單“Create, Execute, Delete”。系統集成工程師需要用所有可以利用的memory初始化DSKT2模塊。DSKT2模塊包括兩種類型的memory，永久性的 memory(只要這個算法存在，它就會佔用的memory)和scratch memory(算法之間可以共享的memory)。當一個算法被創建的時候，永久性memory纔會被DSKT2分配給這個算法，在算法被刪除的時候，這段memory被返回到heap。當一個算法申請scratch memory時，會被分配一個memory 'pool'，這個pool被擁有同一個scratch pool ID的其它算法共享。也就是說，共享scratch memory的算法屬於同一個優先級，不能中斷對方。
b. 配置DSP Server的.cfg文件
在.cfg文件中可以做以下三個部分的配置。
(1) Codec配置：每一個codec都被包含在各自的線程中； 配置每一個codec線程的屬性(線程優先級、堆棧大小和堆棧的memory資源)。具體請參考CE_INSTALL_DIR/xdoc/index.html。
(2) DSKT2配置： 把所有的IALG memory類型結合到可用的DSP memory；定義缺省的scratch組的memory大小。
(3) DMAN3配置：定義DMAN3可以管理的DMA通道號；定義DMAN3可以提供給算法的TCC號。
以video_copy.cfg爲例，對應到圖4所示的DSP Server部分，.cfg文件中對OSAL和codecs模塊做了聲明和定義。我們可以看到video_copy的server中包括VIDDEC_COPY和VIDENC_COPY兩個codec。
接着對server進行配置，包括各個線程的屬性配置。Codec engine將自動匹配算法的scratch memory ID和算法線程的優先級，保證安全操作。
對DSKT2的配置，參看下面的例子。需要注意的是這裏的每一個scratch memory pool的大小通過數組的形式定義，數組的第一個元素對應scratch pool ID0，第二個元素對應scratch pool ID2，依次類推。
以下是DMAN3的配置例子。因爲DMA需要memory存放PARAM和其他的通道配置，所以在DMAN3分配有heap(分爲internal heap和external heap)。DMAN3的PARAM是通過它自己的base index和數量分配的，本例分配給DMAN3 48個PARAM。從這個例子中我們還可以看到DMAN3有8個可用的QDMA通道，tcc是通過bit mask來分配的。
5. xDC的build 過程
xDC的調用是通過執行命令 XDC完成的。在此之前，我們需要做以下幾步：
a. 在config.bld中定義平臺(ARM或DSP)，config.bld所在路徑由xdcbuildcfg定義；
b. 在package.xdc中定義package，package.xdc在當前路徑下(如圖6的video_copy示例)；
c. 在package.bld中定義要build的可執行文件和庫文件，package.bld在當前路徑下(如圖6的video_copy示例)；
d. 按照前面的介紹根據自己的應用修改server的.cfg文件。
執行XDC後先產生package.mak，XDC再運行package.mak生成包含可執行文件的package。
本文小結
以上的介紹基於工程師在實際開發過程中遇到的一些問題。我們希望通過這篇文章可以先理清思路，然後工程師可以有針對性的進一步研究和學習。要想了解更多的構建DSP Server的細節還請大家參考sprued5.pdf及文中提到的用戶手冊和應用文檔
原帖地址http://www.devdiv.net/viewthread.php?tid=3912&highlight=DSP%2Bvincent
