1.1 OMAP3530的硬件平台
　　0MAP3530的硬件平台主要由 ARM内核、DSP内核以及流量控制器(Traffic Controler，TC)组成。
　　(1)ARM内核
　　OMAP3530采用ARM Cortex-A8核，工作主频最高可达720 MHz。它包括存储器管理单元、16 KB的高速指令缓冲存储器、16 KB的数据高速缓冲存储器和256K字的二级Cache;片内有64 KB的内部SRAM，为液晶显示等应用提供了大量的数据和代码存储空间。CortexA8内核采用13级流水线、32位的RISC处理器架构。系统中的控制寄存器对MMU、Cache和读写缓存控制器进行存取操作。ARM内核具有整个系统的控制权，可以设置DSP、TC以及各种外设的时钟及其他工作参数，控制DSP的运行停止。OMAP3530平台可支持包含绘图、多媒体内容和Java程序的先进应用。
　　(2)DSP内核
　　TMS320C64X+内核具有最佳的功耗性能比，工作主频最高为520 MHz;它具有高度的并行能力，32位读写和功能强大的EMIF，双流水线的独立操作以及双MAC的运算能力。它采用3项关键的革新技术：增大的空闲省电区域、变长指令和扩大的并行机制。其结构针对多媒体应用高度优化，适合低功耗的实时语音图像处理。另外，TMS320C64X+内核增加了固化了算法的硬件加速器，来处理运动估计、8×8的DCT/IDCT和1/2像素插值，降低了视频处理的功耗。
　　(3)流量控制器
　　流量控制器TC用于控制ARM、DSP、DMA以及本地总线对OMAP3530内所有存储器(包括SRAM，SDRAM、Flash和ROM等)的访问。
　　OMAP3530具有丰富的外围接口，如液晶控制器、存储器接口、摄像机接口、空中接口、蓝牙接口、通用异步收发器、I2C主机接口、脉宽音频发生器、串行接口、主客户机USB口、安全数字多媒体卡控制器接口、键盘接口等。这些丰富的外围接口使应用OMAP的系统具有更大的灵活性和可扩展性。
1.2 OMAP3530的软件平台
　　利用OMAP可以建立两个操作系统：基于ARM的操作系统(如WinCE、Linux等)，以及基于DSP的DSP/BI OS。连接两个操作系统使用的核心技术是DSP/BIOS桥。0MAP支持多种实时多任务操作系统在ARM微处理器上工作，用来对ARM微处理器进行实时多任务调度管理，对TMS320C64X+进行控制和通信;同时，支持多种实时多任务操作系统在TMS320C64X+上工作，实现复杂的多媒体信号处理。DSP/BIOS桥包含DSP管理器、DSP管理服务器、DSP和外围接口链接驱动器。DSP/BIOS桥提供运行在Cortex-A8上的应用程序和运行TMS320C64X+上的算法之间的通信管理服务。开发者可以利用DSP/BIOS桥中的应用编程接口控制在DSP中实时任务的执行，并同DSP交换任务运行结果和状态消息。在这个环境下，开发者可以调用局部DSP网关组件来实现诸如视频、音频和语音等功能。因此，开发者不需要了解DSP和DSP/BIOS桥，就能开发新的应用软件。使用标准应用编程接口开发的应用软件，与基于0MAP的未来无线设备兼容。
2 视频编码标准与OMAP图形图像库应用
　　2.1 视频编码标准
　　从1988年开始，ISO/IEC MPEG和ITU-T针对不同的应用制订了一系列视频编码国际标准。MPEG的有MPEG-1、MPEG-2、MPEG-4标准，ITU-T的有H.261、H.263、H_263+/H.263++以及H.264标准。2001年12月，ISO和ITU-T正式成立联合视频小组(Joint Video Team，JVT)共同制定新的H.264编码标准。2002年6月，我国信息产业部制订了我国的数字音视频编码技术标准(Audio-Video Coding Standard，AVS)。AVS是我国具备自主知识产权的第二代信源编码标准。与目前比较流行的标准(如MPEG-2、MPEG-4、H.263、H.264)相比，从编码效率来看，MPEG-4是MPEG-2的1.4倍，AVS和H.264都是MPEG-2的2倍以上;从算法复杂度上来看，H.264的算法在编码端比MPEG-2复杂4～5倍，在解码端复杂2～3倍，而AVS在复杂度上比H.264有较大幅度降低，且不需要交纳高昂的专利费用。
　　目前，应用比较广泛的视频编码标准中，基本上都有如下的步骤：将图像序列编码为帧内模式和帧问模式两种，并且分别进行编码。采用帧内编码时，直接对8×8的像素块进行DCT变换，然后将量化系数进行变长编码后形成输出码流;另一路经反量化、反DCT变换后形成恢复图像，直接存入帧存储器。采用帧间编码时，对原始数据的每个块先进行运动估计，并与经运动估计后的预测图像相减，产生差分图像，接着进行DCT变换和量化，并同运动矢量数据一起编码形成码流;另一路经反量化、反DCT变换后形成恢复图像，存入帧存储器，用于下一步的运动估计。
　　不同的标准具有各自的特点，例如MPEGl与H.261采用整像素，MPEG4和H.263采用半像素，H.264与AVS采用1/4至1/8像素精度的运动估计，H.261采用单参考帧，H.264与AVS采用多参考帧等。特别是目前的H.264标准，采用整数DCT/IDCT、帧内预测、多模式运动估计、去块效应滤波器等先进技术，造成了极大的算法复杂度，对硬件实时解码提供了很高的要求。
2.2 OMAP图形图像库(IMGLIB)应用
　　针对图像与视频处理的需要，TI提供了IMGLIB库供C程序调用。库里内容主要有2部分：
　　①硬件加速部分。由汇编语言编写，但是计算由硬件的加速模块来实现，无法修改。例如DCT/IDCT都是针对8×8块进行的，变换矩阵已经固定，硬件加速指令共有16种，其中DCT/IDCT各1条，运动估计指令10条，插值指令4条。
　　②软件加速部分。用汇编语言编写，包括矩阵量化反量化、JPEG变长编码、一维/二维离散小波变换反变换及小波包变换反变换，以及图像的直方图计算、边缘检测、带移位操作的3×3掩模操作等。这些软件加速指令都提供了标准的C接口，用户可以直接调用，也可以模仿编写规则编译生成自己的库文件。

　　在视频编解码过程中，运动估计、DCT/IDCT和像素插值占据了大量的运算时间，0MAP平台提供的硬件加速单元可以高效地完成上述运算，而几乎不占用CPU时钟(这里，不占用是指运算过程，实际上数据的输入输出仍需要花费少量时间);同时，优化的软件加速单元也可以较快地完成运算。以DCT/IDCT为例，耗时情况如表1所列。

　　由表1可知，硬件DCT耗时约为软件DCT的1/7，硬件IDCT耗时约为软件IDCT的1/4.5。因此，采用硬件加速模块可以极大地提高运算速度并降低功耗。
　　对于最新的H.264以及AVS标准，需要采用OMAP3530才能发挥0MAP系列的硬件加速优势。OMAP3530的硬件加速器集成了加速模块的半像素插值，采用的整数DCT/IDCT类变换硬件加速模块，而且集成了去块效应滤波器。在通用计算机上，H.264的解码过程中各部分所需的时间如表2所列。

　　从表2中可以看出，在H.264的解码过程中，环路滤波、插值以及反变换反量化占据了超过70%的计算时间。因此，用0MAP3530来进行H.264以及AVS的解码时，如果能有效地利用0MAP3530的硬件加速资源，可以提高计算效率，实现实时解码。另外，除了硬件加速器之外，0MAP3530的体系结构比较适合于视频处理，这主要基于以下考虑：
　　①目前市场上推出的整合了ARM与 DSP的多媒体专用芯片并不多，OMAP可以使用单一芯片实现嵌入式操作系统(Linux、WinCE等)的功能，并且可以获得TI广大的第三方提供的丰富的算法支持。基于操作系统的编程更灵活方便，便于产品的软件升级。相比之下，单一的DSP无法实现操作系统的功能，若额外采用ARM构建操作系统，成本以及硬件软件复杂度无疑会大于采用OMAP平台。
　　②功耗的考虑。表3列出了OMAPl510上运行MPEG4解码时的功耗情况。

　　可以看出，在OMAPl510平台上，对于QCIF(常用的标准化图像格式)、15 fps的应用来说，功耗在9.9～28.5mW。对于常见的650 mAh时的手机电池，大概可以连续工作34～59小时，这对一般的应用来说显然是够用的。而TI的另一款专用多媒体处理芯片DM642，其功耗为1.5W，是OMAP的50～150倍。对于便携式的多媒体终端而言，由于并不需要太高的运算处理能力，采用OMAP平台既能满足需要，又可以节约电池电力。
　　③速度的考虑。TMS320C64X+最多可以并行执行8条指令，所以理论上的最大速度是4 160 MIPS(520MHz)。这一点相比目前最快的多媒体处理芯片DM642(4 800 MIPS，600 MHz)来说稍低，但两者的目标定位不同。DM642主要用于实时编码等对速度要求较高的场合，而0MAP主要用于手持设备的解码。以H.264算法的Base Profilc为例，复杂度比MPEG-4高20%～30%。对于MPEG4，在QCIF、15 fps下需要28 MIPS;对应的H.264算法的Base Profile要求40 MIPS的运算速度。

　　④程序结构的考虑。DSP的片内内存速度最快，但是非常有限，所以必须将片外的数据倒入内存。由于目前的编码方式全都是采用基于宏块的，每个宏块至多16×16，所以比较通用的办法是采用，DMA方式将要用到的数据提前倒入片内。DMA传送速度很快，所以可以并行也可以串行传送。
　　⑤软件加速的考虑。可以仿照IMGLIB的编写规则用汇编语言对耗时最多的部分进行重写，同时结合TI公司的数据手册进行C语言级以及汇编级的程序优化。由于TI公司编译器的编译效率一直在提高，从通用及可读性的角度上讲，推荐采用C语言。
　3 实时视频解码在OMAP上的软件实现
　　在OMAP上开发程序通常分为两部分：ARM端负责控制、显示等; DSP端负责数据处理。采用TI公司提供的DSP开发工具CCS在这两端分别开发，视频解码流程如图2所示。

　　ARM端：初始化整个OMAP3530芯片，包括 ARM、DSP、TC等的时钟设置，DSP的开启关闭以及复位，LCD、定时器等各个外设的初始化。在启动完成后，ARM内核就一直查询共享内存中的某一标志位，当查询到一帧解码结束时，就启动LCD专用DMA，在LCD上进行显示。
　　DSP端：负责压缩的解码。将压缩码流放置在SDRAM中。与基于PC的解码程序的主要区别在于，由于DSP的片内内存有限，所以不可能将当前帧以及参考帧都放在片内，所以以宏块为单位在SDRAM与片内内存之间进行数据传递。另外，由于在液晶屏上显示时需要转换成RGB图像，所以，在每一帧结束后都要通过YUV转RGB来实现实时显示。
4 实验结果
　　在0MAP3530平台上实现了AVS解码，表4给出了OMAP3530上的实验数据。

　结语
　　TI公司提出的0MAP体系结构开放性好，在这种体系结构下编写的程序移植方便，适合于多媒体平台的应用。越来越多的厂商选用OMAP芯片作为移动多媒体视频的载体，OMAP与流行的视频标准的结合在移动通信与多媒体信号处理方面也将有良好的应用前景。