达芬奇论文
《Davinci技术原理及应用》课程论文
题目: 基于达芬奇技术的智能交通图像SDK设计
姓 名 xxx
学 号 xxx
系 别 信息与通信工程
班 级 xxx
指导教师 xxx
完成时间 2014年11月20日
1 绪论 .................................................. 3
1.1 研究背景和意义 .................................... 3
1.2 论文主要完成的工作 ................................ 3
2 系统总体设计 .......................................... 3
2.1 Codec Engine ...................................... 4
2.2 DSP Codec设计 ..................................... 5
2.3 DSP Codec Server设计 .............................. 6
2.4图像处理SDK设计 ................................... 7
2.5 XDM多媒体数据接口 ................................. 7
2.6 内存管理 .......................................... 7
3 DSP算法优化 ........................................... 8
4 结语 .................................................. 9
1 绪论
1.1 研究背景和意义
随着智能交通行业的飞速发展,大量多媒体技术不断被采用,当今高淸时代对系统的图像、视频处理能力不仅提出了更高效、更快速的要求,还对系统功耗和稳定性提出更髙的要求,是基于SOC处理器的嵌人式系统在整个行业得到了广泛应用。
TMS320DM6467是一款11公司推出的功能强大的多媒体处理芯片,集成 了ARM + DSP的髙性能双核架构,ARM926EJ- S时钟为最高364.5 M,搭配Linux操作系统,用来实现数据管理和任务流程管理;DSP C64x时钟为最高729 M,用于进行算法的执行。特别适用于智能交通领域的图像编解码、图像转码、图像识别等算法的运行。
本系统支持JPEG编解码、H264编解码、图像格式转码、车牌识别、OSD叠加等多种算法,通过Linux动态库的形式被顶层应用系统调用。本系统设计的目的是简化顶层开发人员对DSP端算法谰用的复杂度,使其专注于业务逻辑的开发。
1.2 论文主要完成的工作
本文介绍基于TMS320DM6467达芬奇处理器的智能交通专用图像处理SDK软件系统的设计与实现。并通过算法SDK开发流程,系统内存管理,DSP 算法优化几方面对SDK软件系统的设计进行描述。
2 系统总体设计
本系统在ARM端运行Linux操作系统,在DSP端运行DSP Bios操作系统,ARM和DSP间通过CMEM 和DSPLink交互,CMEM的工具库可以让用户在应用程序空间内申请连续物理内存。DSPIink是DVSDK开发包提供的一个为内部GPP- DSP各处理器提供通信机制的一个基础软件包,它提供了通用的API将 GPP和DSP
间的物理链接抽象到用户应用程序中,省去用户从零开始开发物理链接通信机制。另外DSP Bios操作系统实现了 DSP下复杂的寄存器配置和多任务创建与管理。
本软件系统以Linux动态库的形式为用户提供可使用标准C调用的API函数接口,动态库名称为ItsImageSDK.so。
用户程序是在ARM端运行的Linux系统下调用相应算法API的,而算法实际上在DSP处理器中运行。我们面临的问题是,如何实现ARM和DSP的通信和协同工作。而TI的数字视频软件开发包(DVSDK)提供了Codec Engine这样一个软件模块来实现ARM和 DSP或协处理器的协同工作。系统软件框架见图
1
图1系统软件框架
2.1 Codec Engine
Codec Engine是连接ARM和DSP或协处理器的桥梁,是介于应用层(ARM侧的应用程序)和信号处理层(DSP侧的算法)之间的软件模块。ARM应用程序调用 Codec Engine的VISA( Video,Image,Speech,Au-dio)API,如图2中 VIDENC_process(a,b,e )。
Codec Engine包括两部分编解码引擎Codec En-gine和服务器Codec Sever。两者之间的关系可以比作客户机和应用服务器之间的关系,本质上是远过程调用(RPC)思想在双核上的实现。调用过程见图3。
图2 Codec Engine软件结构框图
图3 RPC调用
2.2 DSP Codec设计
我开发的算法在被Codec Engine使用的时候统一是以“包"的形式被调用的,毎个包有其统一的名称来反映它的路径。
编程中用到一些函数,其中YUV420P2422ILE_TI_ process函数为Codec算法的核心处理部分,该部分的主要工作就是将YUV420P图像转换为YUV422ILE图像,首先要明确两个图像的差别,即YUV分量在元数据中的存放位置,如图4所示:
图4 两个图像数据存放位置
YUV420P的TUV的分量如上所示,其中Y:U:V数量为4:1:1,而且YUV三个分量是依次存放;
YUV422ILE的YUV分量如上所示,其中Y:U:V 数量为4:2:2,而且YUV三个分量的交替存放;
Codec的process函数中对YUV420P的文件进行依此读取,按照YUV422ILE的YUV分量存放顺序进行重新排列,然后在YUV422ILE中适当填充UV分量,便实现的YUV422ILE的转码。
2.3 DSP Codec Server设计
Codec Server与Codec中的算法必须一一对应,才能保证当Codec Engine在调用算法时DSP端能够正确地执行,这些都和算法对应的函数指针 YUV420P2422ILE_TI_YUV420P2422ILEM有关,从刚开始建立算法Codec开始时,该指针就是调用算法函数的唯一方式。
该函数指针必须在YUV420P_2_422ILE.xdc文件中进行指定,以便吿诉Codec Server该算法的调用方式(函数指针)。
接下来,Codec Server的创建需要调用CERuntime Init()函数,然后将算法包加入到cfg配置文件之中。
在完成上述工作后,还需要对Codec Server的配置文件用XDC进行编译,为了一次能够编译完成,这里我们修改makefile,在其中增加XDC编译的部分。
2.4图像处理SDK设计
通常在调用Codec Server端算法的时候,需要建立单独的Codec Engine Client来访问远端DSP Codec Server,利用Control和Process函数进行参数读取和数据运算处理,但是Davinci架构的分角色开发模式比较复杂,往往会给应用层的开发工程师带来诸多不便,故我需要进行封装SDK,目的是为了能够在用户应用软件平台提供良好的API服务,使业务层可以脱离底层的复杂图像处理过程和DSP操作,从而大大简化软件架构而便于后期维护。
Codec Engine Client作为ARM端的算法客户端,主要作用是读取算法参数、设置算法参数和传输元数据,传输完成后,DSP端就开始执行算法,并返回结果。 本文所封装的SDK中对Codec Engine也作了整体设计,JPEG编解码、YUV砖码和车牌识别这四种算法各创建一个Codec Engine。
在SDK的源文件的编码过程中也要增加“Engine”模块,并先初始化所有驱动模块和所有内存模块,然后根据需要运行的Engine的数量进行Engine创建。
2.5 XDM多媒体数据接口
前面介绍的关于YUV转码的Codec、Codec Server 和Codec Engine,在其中的数据格式、数据传输和数据 转换都采用了Ti DVSDK中统一定义的多媒体数据接口标准XDM,它很好地统一了多媒体数据的共同特点,将所有的多媒体要素结合为一个可识别、可操作的整体,这样极大地方便了用户编程和移植。
2.6 内存管理
ARM和DSP进行数据(BUF)共享主要是靠 CMEM来完成,CMEM主要用来管理和申请物理地址连续的一段或者多段内存,从而达到在用户空间操作物理地址的目的,一般是在ARM端申请共享内存的,ARM端Linux操作系统在上电后加载CMEM.ko文件,完成CMEM驱动的加载。
将CMEM内存管理部分封装在SDK之中,能很好地实现内存管理的一致性和统一性,可以更有效地利用嵌人式系统有限的内存资源,使业务软件开发部分不用关心底层的内存设计。
内存管理相关代码封装在SDK中各算法的init函数和destroy函数部分。 3 DSP算法优化
本系统主要用于高清图像的实时处理,支持的图像分辨率高达200万像素,对各箅法累计处理时间要求不超过500ms,因此DSP算法优化工作也是本软件系统开发中关键的一环。
TMS320C64X +内部有8个独立的功能单元,所以在一个周期内最多可以并行执行8条指令。然而指令与功能单元之间特殊的映射关系、每一条指令执行时间的不相同、每一条指令的数据通路的不相同和指令间搡作数的相关性等因素,致使一个周期内实际能并行执行的指令数达不到8条,从而降低了 DSP的性能,因此,必须采用合理的开发和优化流程,尽可能地对代码进行优化,从而提高指令执行的并行度
工作流程一般分为三个阶段。
第一阶段:直接按照需要用C语言实现功能。在实际的DSP应用中,许多算法都是非常复杂,直接用汇编代码编写,虽然优化效率很髙,可是实现的难度却很大,所以一般都先采用C语言来实现,然后编译运行,利用C64X开发环境的profile clock工具测试程序运行时间,若不能满足要求,则进行第二阶段。
第二阶段:C语言级的优化。选择C64X开发环境提供的优化方式以及充分运用其他技巧,优化C代码,若还不能满足效率要求,则进行第三阶段。
第三阶段:汇编级的优化。将上一阶段C程序中 优化效率较低的部分提出来,用线性汇编语言编写,利用汇编优化器进行优化。汇编优化器的作用是让开发人员在不考虑C64X流水线结构和分配其内部寄存器的情况下,编写线形汇编语言程序,然后汇编优化器通过分配寄存器和循环优化将汇编语言程序转化为利用流水线方式的高速并行汇编程序。
下边是一些常用的优化策略:
1)选用C编译器提供的优化选项;
2)减小存储器相关性;
3)使用内联函数(intrinsics);
4)short型数据的int处理;
5)尽量减少函数调用;
6)尽量使用逻辑运算代替乘除运算;
7)软件流水线技术的使用。
本系统的算法开发过程中,综合运用多种优化策略,最终达到了很好的效果。 4 结语
智能交通图像处理SDK充分利用达芬奇处理器的双核架构,使用户业务逻辑和图像算法分别运行在ARM和DSP处理器核心上,提高系统并行处理能力。同时简化用户系统的开发流程,使用户致力于业务系统的开发,提高用户开发效率。在本系统基袖上完成多套智能交通前端系统的开发,带来极高的经济效益。
参考文献:
[1]马晶,富勇,涂国强等.基于DSP的图像处理在车牌识别中的应用[J].微计算机信息,2009,25(27):133-135.
[2]孙刚波.达芬奇技术在视频处理上的应用[J].硅谷,2012.5(20):127-128.
[3]彭启琮.达芬奇技术——数字图像/视频信号处理新平台[M].北京:电子工业出版社,2008.
[4]韩文俊,任国强.基于达芬奇平台的H.264视频编码器设计[J].微计算机信息,2009,25(29) :9 -10.
[5] 张起贵, 张胜,张刚. 最新DSP技术—达芬奇系统、框架和组件[M]. 国防工业出版社,2009.