基于视频处理的DSP系统通用设计模式及其实现
引言
目前，随着视频处理领域的不断深入发展，作为其实现的主要平台——DSP系统的设计成为了决定视频处理算法是否能高速实时运行的首要因素。
一个优秀的DSP系统框架应该至少具有功能的高效实施性和良好的软硬件扩展性。本文介绍的这种基于视频处理的DSP系统的框架正是以传统的数字信号处理方式为基础，以高效性和扩展性为目标，并且能够适应大多数的器件而提出的在硬件上和在软件上的解决方案。
可通用设计模式的思路
硬件结构
传统的数字信号处理过程是由“ADC + DSP + DAC”这种模式构成的，其中并未具体的明确指出存储器的如何使用以及ADC、DSP和DAC之间的数字逻辑电路关系如何，而这两点正是实现高效实时系统的关键所在。
以视频处理为背景，基于可通用设计模式的思路从硬件功能上将DSP系统按图1中所示的模块框图设计。从图中可以看到整个DSP系统被分为六大模块：DSP模块、ADC模块、DAC模块、存储器模块、数字逻辑电路模块和其它模块。其中，数字逻辑电路模块起到了模块间相互通信的中间“桥”作用，通常选用具有足够的可编程引脚和内部逻辑单元的CPLD或FPGA加上适当数目的开关器件来实现；而存储器模块则由针对DSP模块、ADC模块和DAC模块的三个独立且结构相同的子模块组成。
由于各存储器子模块间的地址总线、数据总线和控制总线的相互独立，通过数字逻辑电路模块可以使ADC、DSP和DAC三个模块在同一时刻拥有各自独立的存储空间从而为三者的并行无阻碍运行提供了有效的硬件保证。如图2中所示，三个存储器子模块处于循环式的流水线工作状态，它们在系统中的地位等价；其中每个存储器子模块一般都以整帧图像为存储单位，故可简称为帧存。整个系统处于ADC、DSP和DAC三个模块同步并行的工作方式，即DSP处理当前帧图像的同时ADC正采集下一帧图像而DAC正传送上一帧图像给显示设备，这样DSP只负责图像的处理过程而不涉及图像在存储空间中的简单搬移。
相应的数字逻辑电路模块按图3中所示的互相关联的各子模块来设计。其中，操作控制子模块用于实现DSP对ADC及DAC的控制(复位或下电ADC及DAC、选择标准I2C或模拟I2C进行配置、同步三者的并行等)与DSP外部中断的使能，并控制图3中其它的子模块；状态计数子模块用于产生四类状态：上电初始态和三类工作态；ADC或DAC译址及控制转化子模块用于产生ADC或DAC控制相应存储空间的逻辑；状态切换控制子模块则通过接收图3中其它子模块的信息来最终实现存储空间与ADC、DSP及DAC的相互对应。
当系统设计中不要求使用DAC或ADC时，图4中示出了图1中模块互连部分与图2的简化；由此可以看出以上基于可通用设计模式的DSP系统框架简化为了具有以乒乓式存取的双存储器子模块的情况，故基于乒乓式存取的数据系统是其特例。此外，该框架可以实现多路ADC及多路DAC的并行工作，通常选用相应数目的SDRAM作为存储器子模块来配合使用。
图5中示出了一种使用双乒乓式存储器模块的DSP系统主要部分，与图1中模块互连部分相比，此硬件结构显得冗余，实现上会使用较多的器件并使制板连线更为复杂，但性能上不会有所提升。图6中示出了一种使用FPGA以实现FIFO功能为主的DSP系统主要部分，与图1中模块互连部分相比，此硬件结构较为简单，但图像的采集和显示要配合软件上的协作予以实现从而增加了软件开发的复杂性，此外由于该存储器模块的总线结构单一至使总线复用从而在某些情况下降低了系统性能。
软件构架
TI推荐的RF5(Reference Framework Level 5)是基于DSP/BIOS和TMS320 DSP算法标准的一般性DSP软件构架要素的源代码，用户可以根据具体应用在其基础上搭建适合需求的自定义OS。基于RF5的软件构架设计大体分为三步：
1) 针对具体的硬件电路开发相应的底层驱动，对于ADC和DAC来说主要是通过I2C总线对其进行配置；
2) 借助RF5来构建不拘于底层电路的OS层代码，并嵌入相应的硬件驱动及标准的算法接口；
3) 按TMS320 DSP算法标准编制具体的视频处理算法，并通过标准的接口定义将其集成到OS层代码中。
其中，每一步的设计相对独立，这样在更改具体电路的情况下只需修改1)，在变化算法功能的情况下只需修改3)，而在扩充软件整体应用范围的情况下只需修改2)。
RF5具有良好的扩展性及高集成度特性，支持动态对象的创建和基于任务的多线程，提供了可以自定义扩充的代码要素和有效的跟踪调试工具，通过其可实现下列三方面的结构化设计从而明了OS层的数据流通路径：
1) 数据处理方面。RF5提供了四种关于数据处理方面的要素：任务、通道、外包单元和算法接口。OS层由不同的多个任务组成，每个任务可以包含一系列的通道，而每个通道又可以包含一系列的外包单元，其中一个外包单元对应一个算法接口的封装；每个算法代码都可以重复使用，通过调用不同的对象来实现一个算法的多个例程在不同通道中的使用。
2) 数据传递方面：
A. 任务级的数据传递，是基于旗语同步的。在任务与驱动之间通常采用DSP/BIOS中的SIO对象(针对音频系统)或GIO对象(针对视频系统)指明数据的位置来进行交互，而在多个任务之间则采用RF5提供的SCOM消息队列机制通过识别不同的队列名和指明相应的数据位置来互传信息。
B. 外包单元级的数据传递。每个外包单元都有其输入列表和输出列表，这些列表里存放了由RF5提供的ICC对象用于指明数据的位置，通过各列表中包含相同的ICC对象来实现各外包单元间的交互。此外，通过ICC对象可以完成任务级数据和外包单元级数据之间的交互。
3) 消息控制。对于信息少的控制消息可以采用DSP/BIOS中的邮箱机制通过搬移指令的内容单向的在任务间传递指令，而对于信息多的控制消息则可以使用SCOM消息队列机制通过识别不同的队列名和指明相应的数据位置在任务间传递指令。
图7中示出了基于视频处理与RF5的一般OS层构架示意图，可以通过增加任务来扩充其它如网络传输、音频处理等功能(需要相应的硬件和底层驱动支持)。从图中可以看到，以双通道及每通道内两外包单元的情况为例，图像数据从ADC出来后经过输入设备驱动存放在GIO对象所指的数据位置，任务tskCapture通过调用GIO对象对其所指的数据进行格式及大小等的简单变换，再将结果数据存入SCOM消息指定的位置并通过SCOM队列向任务tskProcess发送该消息；当任务tskProcess接收到该消息后，对其所指的数据按具体要求的算法进行处理，其中一个外包单元实现一个算法例程，一个通道则实现一路功能上已独立且算法间先后关联的算法组；当任务tskProcess处理数据完成后，将结果再次存入SCOM消息指定的位置并向任务tskDisplay发送消息；任务tskDisplay收到消息后会对所指数据做格式及大小等的简单变换，以便通过GIO对象发送给输出设备驱动从而在DAC后端显示；任务tskControl通过接收主机端的控制消息来对任务tskProcess的处理过程进行控制。
基于本文上述讨论的系统框架模型可通过图7定制适合其硬件结构的如图8中所示的简化的OS层构架。与图7中相比，图8中只有算法的处理和控制两个任务从而提高了DSP在算法处理上的效率，而ADC和DAC的配置则在系统上电后的初始化中完成，此后ADC和DAC不需要DSP的介入而通过CPLD/FPGA中的逻辑实现了图像数据按要求的格式和大小在存储器子模块中的存放从而在某种程度上减轻了DSP的负担。
设计思路的具体应用
依照以上的思路实现整个系统的设计主要通过下列四步的完成：
1) 根据实际需要选择适当的器件，完成整个系统硬件层次上的连接；
2) 针对具体情况定制系统中使用的可编程逻辑器件的内部逻辑；
3) 编写适合具体电路的程序代码，实现整个系统软件层次上的构架；
4) 将指定的视频处理算法嵌入在该构架中。
按上述四步，选用TVP5150A(ADC)、SAA7105(DAC)、XC95288XL(CPLD)各一片和三片IS61LV2568L(SRAM)为主要器件，在数字信号处理仿真/教学实验系统DES3200的二次开发接口上完成了基于可通用模式的DES3200图像处理子卡II的设计，如图9中左所示；并配合TMS320C6713B(DSP)子卡得到了CIF格式的视频预处理的显示结果，如图9中右所示。进而，证明该通用设计模式是可行的。
评论