怎样去设计一种TI DSP应用程序框架？

　　1 引言
　　随着通信与信息技术的发展以及数字产品的普及，DSP 被越来越多地应用于各种数字系统中。作为业界领先的数字信号处理器供应商的美国德州仪器（TI）公司于上世纪90 年代开发了能在其DSP 产品上运行的实时内核DSP/BIOS，并提出一系列DSP 软件参考框架（Reference Framework， RF）来帮助DSP 应用开发人员加速软件的开发进程。然而，国内针对DSP 应用程序框架设计的研究还并不多且研究工作大多围绕在如何使用现有的TI 参考框架上，鲜有对其使用局限性的讨论与改进方案。
　　本文首先简单介绍了由 TI 所提出的DSP 应用程序参考设计框架RF5 及其适用领域，然后在它的基础上针对目前使用越来越多的多处理器系统提出了一个对RF5 改进后的DSP 应用程序框架ERF5（Enhanced Referenced Framework Level 5），并在其中定义了一套DSP 与系统中作为核心控制单元的外部通用处理器GPP 进行通信的良好机制，从而能够实现DSP的任务调度与执行过程受控于GPP，使DSP 的运行状态能够高效地切换于多套功能独立的数字信号处理算法。
　　2 RF5 应用程序框架
　　TI 在eXpressDSP 概念中提出了一系列DSP 应用程序参考框架以满足不同应用场合的需要，其中包括RF1（Reference Framework Level 1）、RF3（Reference Framework Level 3）和RF5［1］［2］。与RF1 和RF3 相比，RF5 是功能最强大的DSP 应用程序参考框架，它适用于多通道、多算法的高密集型DSP 应用系统，RF5 同时支持了静态和动态DSP/BIOS 模块对象的创建，支持1－100 个数据处理通道和XDAIS 算法，支持由DSP/BIOS 任务对象TSK实现的线程调度机制，支持线程阻塞，因此被广泛应用于音视频信号处理等复杂数字信号处理系统当中。图1 给出了基于RF5 的DSP 应用程序框架。
　　
　　图1 RF5 应用程序框架
　　TI 为RF5 应用程序参考框架定义了4 种数据处理基本元素，分别是任务（Task）、通道（Channel）、算法单元（Cell）和XDAIS 算法。RF5 框架的最高层次是任务，任务可以由单个或多个通道构成，它通过与设备驱动程序或其它任务通信来在较高的层次控制数据的流向，每个任务体都可以归结为“获取数据－处理各通道中的信号－发送结果数据”的迭代过程。每个通道元素由一系列顺序执行的信号处理算法单元构成，算法单元是一个XDAIS 算法的封装，其作用是为XDAIS 算法与外部应用程序提供一套标准的接口，它必须实现ICELL接口模块。
　　RF5 除了定义以上4 种数据处理元素之外，还提出了数据通信元素的概念以保证能在任务与DSP 外设之间、任务与任务之间和算法单元之间进行高效数据通信。基于DSP/BIOS开发的DSP 应用程序中的数据通信方式可分为任务级数据通信和算法单元级数据通信。对于任务级数据通信方式，在RF5 中采用SIO（Stream IO）对象和SCOM（SynchronizedCommunication）消息来实现。对于算法单元级数据通信，RF5 使用ICC（Inter-CellCommunication）对象和ICC 对象列表来实现。
　　3 改进的DSP 应用程序框架ERF5
　　随着嵌入式系统复杂度的不断提高，又限于DSP 不适合进行复杂系统的流程控制，所以近年来在系统设计中往往更多地让DSP 扮演着协处理器的角色，将其从繁重复杂的系统控制任务中解放出来，而整个系统的流程控制则交由一个通用处理器GPP 来完成，这使得DSP 和GPP 能够优势互补。然而RF5 在多机通信方面存在很大缺陷，它不适用于多处理器系统，尤其是DSP 作为多处理器系统中从设备的应用环境。另外，RF5 所实现的是单一功能的多任务系统，其多任务特性仅仅表现在将一个功能单一的任务拆分成输入－处理－输出三个分任务而已，并没有实现真正的多功能多任务系统，即一个任务就是一个独立的信号处理功能。
　　基于上述两个方面的分析，我们完全有必要改进 RF5 以满足基于多处理器的复杂信号处理系统的要求。本文所提出的ERF5 的系统框图如图2 所示，任务1、任务2、任务3 是系统中定义的三个任务，它们以同等的优先级被DSP/BIOS 任务调度器轮流调度。每个任务皆包含了输入预处理、核心信号处理以及输出后处理三个模块，构成功能完整且独立的信号处理任务，每个任务由单个或多个数据处理通道（Channel）组成，而每个通道又由一系列算法单元（Cell）构成。多处理器系统中的GPP 通过DSP 运行控制寄存器DSP_CNTL 来控制DSP 的任务执行过程，而DSP 作为响应会将其运行状态反应在DSP 运行状态寄存器DSP_STAT 中。总的来说，ERF5 从以下三个方面对RF5 进行了改进：
　　定义并实现了 DSP 与GPP 之间进行通信的有效方式；给出了当 DSP 需要实现多套信号处理功能并且某一套信号处理任务的执行完全受控于GPP 时的任务实现框架；对 RF5 中不合理的任务拆分进行了合并，减轻了由于DSP/BIOS 任务调度对系统性能的影响。
　　
　　图 2 ERF5 应用程序框架
　　3.1 主从通信方式
　　我们在DSP 的存储空间中定义了两个寄存器：DSP 运行控制寄存器（DSP_CNTL）和DSP 运行状态寄存器（DSP_STAT）。在DSP_CNTL 中可以定义一系列控制字段用来表示外部主机对DSP 的各种控制操作，而在DSP_STAT 中可以定义一些与DSP_CNTL 相对应的描述DSP 当前运行状态的字段信息。GPP 通过合理地设置DSP_CNTL 以命令DSP 执行相应的操作，而DSP 在响应了CPU 的命令后会设置好DSP_STAT 以告知CPU 目前DSP 的运行情况。
　　另外，为了便于 DSP 与主机进行数据交换，ERF5 在DSP 的存储空间中开辟了两块专用于在DSP 与GPP 之间进行数据交换的缓冲区，并在DSP 运行状态寄存器DSP_STAT 中定义一个缓冲区标志位PPFLG 以告知主机当前它所能访问的乒乓缓冲区是“乒”或是“乓”，使得主机和DSP 之间的数据交互能够彼此相对独立地进行。
　　3.2 任务实现模型
　　在明确了主机与DSP 的通信方式以后，下面需要解决的就是如何在应用程序框架中给出合理的任务实现模型使它既能支持主机对DSP 的有效控制又能尽可能地减小DSP/BIOS的任务调度开销。这里以我们的实际项目为例来阐述任务的实现模型。在我们的H.264 混合编解码系统中，DM642 需要运行三个相互独立的任务：视频编码任务、视频解码任务和视频直通任务，在任意时刻，这三个任务线程的核心处理过程运行与否完全受GPP 控制。首先，出于对系统性能的考虑，我们都以静态配置的方式在DSP/BIOS 中定义这3 个任务，这样在系统运行时不需要花费由于任务动态创建所带来的不可避免的性能开销。显然这3 个任务应该具有同等优先级，否则，由于DSP/BIOS 实时内核的抢占性特征将使得某些高优先级的任务始终抢占那些低优先级任务的执行权即使GPP 在某些时刻并没有启动那些高优先级的任务。此外，由于DSP/BIOS 周期性地调度系统中所有处于就绪状态下的任务，所以必须使每个任务中判断其主体处理过程是否执行的逻辑和任务切换逻辑尽可能短小，因为这段代码在系统执行时将被频繁地调用。另外需要注意的是应该使用TSK_sleep（…）函数来实现任务切换逻辑以使当前没有被GPP 命令执行的任务被阻塞一段时间（该时间间隔应该至少是系统中各个周期性任务的最大执行周期），否则DSP/BIOS 任务调度器会频繁调度该任务以至于影响到其它任务的正常执行。下面以视频直通任务为例给出其任务执行流程图如图3所示。
　　
　　图3 视频直通任务的执行流程图
　　3.3 任务拆分与合并
　　DSP/BIOS 实时内核能保证运行在它之上的所有任务在适当的时刻被正确地调度。在通常情况下，系统中运行的任务越多，花费在DSP/BIOS 任务调度上的时间也就越多，单任务系统花费最少的任务调度时间，因此在一个应用框架中应该合理地规定任务的规模，过细或过粗地划分任务都将为系统性能带来负面影响。在ERF5 中，每个功能独立的信号处理模块分别定义成一个任务线程，其中包含了与当前信号处理功能相对应的数据输入预处理和数据输出后处理部分，在一个独立的任务线程中将可以使用EDMA 等外设模块实现的处理算法与必须由CPU 参与运算的算法独立开来，并在它们之间引入双缓冲以模拟流水线机理，这样就把原先的任务线程之间的通信变换为在单个任务线程内的算法单元之间的通信，使得任务线程之间的通信和数据交换由于线程的独立性而被最小化，从而有效避免了由于线程通信造成系统死锁情况的发生。
　　4 性能分析
　　本节以 CPU 负载为指标在本文所提出的应用程序框架和RF5 之间进行性能比较与分析。为了使实验结果更具有说服力，我们使用TMS320DM642 *估板中的MPEG2 编解码例程作为RF5 框架的一个实现范例，另外，我们又采用本文所提出的ERF5 实现了MPEG2 编解码系统，两者使用同样的符合XDAIS 算法标准的MPEG2 编解码算法库。这里我们将CPU负载定义为：
　　
　　对于一个视频信号处理系统来说，一般要求系统能在 1 秒内处理25－30 帧图像数据，因此不妨将其作为上述视频编解码系统的实时性指标，即系统对一帧图像进行编码或解码的最大周期为33－40 毫秒。根据以上计算公式作出RF5 和改进的应用程序框架的CPU 负载图如图4 所示。从图中可以看出ERF5 的CPU 占用率与RF5 基本相近，甚至要稍好于RF5，若将它应用在视频信号处理领域，其CPU 占用率只有7.92%－9.50%，完全满足实际应用的需要。
　　
　　图 4 MPEG2 编解码系统中ERF5 与RF5 的CPU 负载比较图
　　5 总结
　　本文简单介绍了 TI DSP 参考框架RF5，并提出ERF5 应用程序框架，它解决了RF5 不能被有效地应用于以DSP 作为协处理器的多处理器复杂数字信号处理系统当中的问题，且CPU 占用率与RF5 相当。从我们的实际项目经验证明，RF5 适用于以TI DSP 作为主控和主处理单元的单处理器信号处理系统，并能得到良好的性能；ERF5 能对多处理器系统给予最大化的支持，并已成功应用于一个复杂的H.264 混合编解码系统当中。

1