如何构建达芬奇的DSP Server

liyf

  
         
    德州仪器(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外设模块的驱动程序。


[table]

[tr]
[td]

[/td][/tr]
  
         
   

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算法的任务。


[table]

[tr]
[td]

[/td][/tr]
[tr]
图3：VISA create/delete流程说明图。[/td][/tr]
  
         
   

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。


[table]

[tr]
[td]

[/td][/tr]