摘  要:本文在基于最新的高性能C2 CC1100处理器自行开发的嵌入式多媒体开发平台上，实现了基于D1图像分辨率的AVS视频熵解码器。主要完成工作如下：（1）通过对AVS算法特点及运算复杂性的分析，指出并行AVS解码的可行性，并分析论证其实现可行性，且针对AVS熵解码的并行算法进行重点分析；（2）研究了CC1100异构多核心媒体处理器的体系架构，重点分析其针对熵解码特殊化的协处理器ENE引擎，包括ENE引擎的结构，编程，应用以及仿真环境；（3）完成AVS算法面向CC1100平台的映射。结合AVS算法和CC1100特点，划分熵解码、MPU解码和VECTOR解码等几个并行功能模块；（4）提出基于条带层并行的熵解码模块方案，细化CC1100平台上的熵解码模块设计，完成熵解码模块控制流和输入输出数据流及其相应数据结构的设计；（5）使用C和ENE汇 编语言完成熵解码模块实现。完成Amodel模型上的仿真调试和功能验证。最后，在硬件平台上通过media framework验证时序并进行性能测试。实测并行加速比达到较好水平。

1. 绪  论

    AVS数字音视频编解码技术标准是我国具有自主知识产权的第二代信源编码的国家标准，也是IPTV视频编码的国际标准。AVS视频编码标准结合了H.264及以前一些编码标准的特点，取得了和H.264相近的性能。但要满足高分辨率图像实时应用，必须有硬件加速。
    C2公司推出的CC1100是一个异构多核心嵌入式多媒体芯片。它在MIPS核心的基础上，针对现存的混合视频编码架构的共有结构，引入熵编码引擎（ENE），搜索引擎（MEE）等视频专用核心，为视频编解码提供高效的硬件支持。这样，它即使运行在较低的频率下，也能够支持高分辨率的视频编解码应用。在CC1100上实现AVS解码器，并没有现成的例子可以参考。这对软件开发人员来说，也是一个相当大的挑战。本文研究在CC1100这样一个高性价比平台上实现基于D1分辨率的AVS解码器，有重要的研究意义和实用价值。

2. AVS编解码算法分析

    本节分析AVS解码器潜在的并行性并给出AVS视频熵解码流程。

2.1 AVS解码器并行性分析

    对于解码器，要能够进行线程级并行，需要解决两个方面的问题：（1）数据依赖性；（2）控制依赖性。
    首先，从数据流来看，对于AVS算法，我们可以知道，对于图像来说，P帧是依赖于I帧的。因为如果I帧不解码完毕，P帧没有可能正常解码。同理，B帧依赖于I帧和P帧。但是I帧与I帧，P帧与P帧，B帧与B帧之间，并没依赖关系，这样的情况下，并行是可能存在的。另外，AVS中定义了条带的概念，根据条带的要求，同一帧内两个条带之间不能互相参考。亦即，同一帧的条带与条带之间存在并行可能性。
    另外，从控制流来看，解码器的三个主要部分：熵解码、变换解码和预测解码都是基于宏块来完成的。这三个部分是串行工作的，但是从宏块的角度来看，这三个部分可以并行工作。MPEG系列和H.26x系列编解码器具有线程并行和宏块并行性，可见AVS的并行化是可行的。

2.2 AVS解码器熵解码流程

    根据AVS标准，我们可以基本划分熵解码功能和流程如图1所示。阴影部分即为熵解码流程。图中实线箭头代表控制流，虚线箭头代表数据流。

图1 AVS熵解码流程

3. C2 CC1100处理器体系结构

    本节介绍C2 CC1100平台架构，重点分析其熵解码引擎的结构、使用和仿真的软硬件环境。

3.1 C2 CC1100处理器体系结构简介

    美国C2 Microsystems公司推出的CC1100是一个异构多核心DSP SoC。它支持标准Linux操作系统和丰富的开源应用软件和通信协议栈；多处理器设能够并行运行Linux应用程序和音、视频处理算法，可以最大程度地降低软件开发成本计。CC1100不同于通用DSP，它专门针对音视频应用设计的。在CC1100单芯片上集成了RISC处理器，256位的向量处理器，ME引擎（Motion Estimation Engine，MEE）和ENE引擎（Entropy Engine，ENE）两个可编程协处理器。ME引擎和ENE引擎的编/解码效率可以达到通用DSP的2倍或更高。CC1100芯片主频仅为300MHz，低主频的芯片可以降低系统硬件设计成本。CC1100芯片支持D1分辨率的H.264主要档次（Main Profile）编码。而且CC1100可以支持不同视频编解码算法，支持任意分辨率和可变帧率。
    图2所示为CC1100体系结构框图。CC1100采用C2公司自主设计的1个RISC MPU（MIPS）和3个DSP处理器。其中MPU是精简指令集（RSIC）CPU，采用了类MIPS架构。另外3个DSP则分别针对三类编解码算法中常用运算进行优化。
这三类计算分别是：（1）运动估计（Motion Estimation，ME）：这是视频处理中最耗费时间的一类运算。在ME引擎中，块匹配和运动向量搜索都有专有的指令做运算加速；（2）熵编/解码（Entropy Encode/Decode）：这也是图像处理中使用频率很高的计算。ENE引擎为这类运算提供相应的硬件支持；（3）向量处理（Vector Processing）：图像是二维数据，对于8×8的图像块，一行像素或者一列像素都可以作为一个向量进行处理。向量运算在图像处理中使用频率非常高，另外，这部分也可以兼作音频数据的处理。
    在这三个协处理器中，除了其本身包含的加减乘除等算术和逻辑运算指令外，CC1100设计时，将上述三类运算中使用量最大的计算抽出来，设计专用的硬件。同时，提供相应的指令库。有了专用硬件的支持，软件通过调用提供的指令库封装，能够大大提高编解码效率。

 
图2 CC1100的核心架构

    ME引擎是一个可编程协处理器，其体系架构可以高效率地执行视频压缩运算中的块搜索和运动补偿算法；ENE引擎也是一个完全可编程的变长位运算处理器，其架构可以高效地解析处理MPEG-2，MPEG-4，H.264，VC-1和JPEG等位串码流数据中的语法元素，它还可以高效地运行CABAC/CAVLC等熵编码的压缩和解压缩算法；Vector子处理器支持专为音、视频处理而优化SIMD指令集，它内置64个256位的超宽向量寄存器，支持整数和浮点数运算；MPU主处理器是一个超级标量RISC处理器，采用类MIPS架构。它支持硬件超线程技术，一个指令周期最多运行4条指令，可以运行Linux操作系统；片内集成指令和数据cache；DMA HUB控制器可以在子处理器和DDR内存之间建立高速数据交换的直接通道。

3.2 C2 CC1100处理器熵编/解码引擎（ENE）模块特点及编程结构

3.2.1 ENE引擎的结构特征

    ENE引擎（ENtorpy Engine）是C2 CC1100处理器用于熵编/解码的硬件加速协处理器。它被设计于用来专门处理各类变长编码（Varible Length Codes，VLC），例如哈夫曼编码（Huffman Code），基于上下文的变长编码（Context Adaptive Variable Length Codes，CAVLC），基于上下文的二进制算数编码（Context Adaptive Binary Arithmetic Codes，CABAC）。ENE引擎是一个“比特位”处理器。传统的典型“字节”处理器需要多个周期来完成对于随机比特流的解析，包括移位，掩码和查表操作；而ENE引擎能在一个周期左右的时钟内完成相应的操作以及变长码表的解析。ENE引擎是一个动态可编程处理器。ENE引擎在处理任务前，需要将微代码和变长码表下载到ENE引擎上。从而可以适应各种动态任务调整，可以工作在解码模式或者编码模式下。ENE引擎目前能偶支持现有和将来可能出现的各种编码格式，如MPEG-1，MPEG-2，MPEG-4 Part 2（XVID），MPEG-4 Part 10/H.264，WMV9/VC-1，DV，JPEG等。ENE引擎可以和MPU工作在并行模式下，熵编/解码过程可以和其它的编解码过程并行运行。
    ENE引擎体系框图3所示。ENE引擎内部主要是一个微控制器（Micro Controller）以及由它控制的一个编/解码解析引擎（Encode/Decode Engine）。微控制器是一个16位的处理器，能完成16位算术运算（加、减、乘）和逻辑运算等功能。同时，微控制器也能完成32位运算。配置寄存器（Config Registers）提供ENE引擎的初始化信息，工作控制以及状态信息。通用寄存器（General Registers）为微控制器运行寄存器。ENE引擎内部还有有VLC、UCODE和DATA三块RAM，分别为VLC表，微代码和数据提供存储空间，大小分别为6K，16K，和2K字节。可见ENE引擎内部存储空间是相当有限的，在设计时，要充分考虑到代码大小和数据大小的影响，这个常见的多媒体软件设计时重点考虑性能有所不同，应该予以重视，后面也会相应谈到这个问题。 

图3 ENE引擎结构框图

    ENE引擎还包含4个输入DMA通道和4个输出DMA通道，分别对应于宏块信息（MBLK），运动向量信息（MVEC），残差系数（COEF）和上下文信息（CTX）。从MPU端看来，这8个DMA通道可以用作正常DMA使用，而在ENE端，这8个DMA通道的抽象模型为8个FIFO。ENE引擎并没有硬性规定每个DMA/FIFO的对应关系，开发人员有一定的自由来安排各DMA/FIFO的对应数据。
    Local Bus用来将配置寄存器映射到MPU的内存空间，这样MPU端可以通过对指定地址寄存器的读写获得ENE引擎的工作状态或者初始化、配置ENE引擎。Interrupt Singnal则被ENE用来向MPU发送任务完成的中断信号。

3.2.2 ENE引擎的编程结构

    C2公司为ENE引擎的编码开发提供了整套的framework，包括Linux底层设备驱动以及抽象的ENE Resource Manager。应用程序在使用ENE引擎资源时，均需通过ENE Resource Manager来完成。它是一个基于C++的封装，提供了对ENE硬件资源访问的高级接口。ENE Resource Manager有两个主要功能：为应用程序访问ENE硬件资源提供API；通过在后台运行的调度线程（ENE Scheduler thread）调度多个ENE任务。ENE Scheduler thread通过实现信号灯机制来保证ENE硬件使用的互斥。
    常见的ENE编解码编程结构是将编解码算法熵编码部分划分为I、P、B帧三个ENE微码程序，在需要的时候下载到ENE硬件执行。同时，ENE硬件也支持动态VLC表，可以在需要的时候，动态下载VLC表到ENE上。图4是一个典型ENE应用程序，ENE Resource Manager和ENE硬件执行示意图。

图4 ENE Resource Manager调度

3.2.3 ENE的仿真模型

    ENE微代码可以在硬件或者ENE仿真器，Amodel或者Esim上运行。图5所示为其对应的编译及运行模型框图：

 图5 CC1100仿真模型开发过程

4. AVS解码器ENE模块的实现与优化

    本节首先进行AVS解码器模块功能划分，提出AVS解码器熵解码并行化的方案，然后进行解码器向CC1100的映射，然后完成数据流、数据结构和控制流的设计，重点介绍了ENE模块的设计与实现，并对重要数据结构、函数作出说明，最后给出ENE针对解析码流专用硬件的编程以及ENE上编码所要注意的问题及解决方案。

4.1 AVS解码器在C2 CC1100上的功能划分

4.1.1 AVS解码器功能划分的基本考虑

    由第二节中的AVS解码器各个部分的运算需求和特征，结合CC1100体系结构，按照上述思路，可以把AVS解码器的各个功能部分映射到CC1100的执行部件上。表1给出了一个概要的功能划分模型，后续工作基本按照这个划分来完成。

4.1.2 AVS解码器ENE模块的实现

    本文选定条带层并行，作为AVS解码器ENE模块的实现。ENE解码的流程如图6：

 
图6 ENE引擎熵解码具体功能分解

4.2 AVS解码器熵解码ENE模块的优化

4.2.1 ENE代码优化策略

ENE代码实现时，由于硬件资源的限制，数据段和程序段存储空间都相当的小，因此在代码优化时，首先面对的是代码大小和存储空间使用优化的问题。
（1）数据段存储优化
对于数据段存储优化，主要手段就是合理合理安排全局变量和常量数据的大小，使其尽量少占用存储空间；另外，针对码流解析中占用空间较大的数据结构，比如解析残差系数的三张VLC码表等，优化其数据结构，在程序段添加相应的代码判断。这样达到程序空间换取数据空间的目的，因为相对来说，程序空间的要大，存储压力相对较小。
（2）程序段空间优化
对于程序段的优化，主要有两个方面：1.修改C语言结构，是编译器能够更好的编译紧凑的代码；2.某些编译器不能产生紧凑代码的部分，或者C语言实现比较困难的部分，使用汇编语言代替。另外，在需要的时候，还可以使用汇编来帮助提高代码效率和改善代码大小。例如，因为AVS中运动向量的计算，用到的缩放，因此有除法运算。而ENE的库函数所提供的除法函数大小相当大，因此需要用汇编来代替。div.S文件中所实现的函数，即为32位除法函数。

5. 实现结果及评估

5.1 实现环境及测试环境

    AVS解码器在自主开发的C2 CC1100开发平台上实现，相应的实现环境和测试环境如下：
实现目标平台：C2 CC1100开发板(如图7)。
开发宿主平台：PC机，安装Fedora Core 7 Linux
图8为实现平台照片。

图7 自主开发的基于CC1100处理器的开发板
 

图8 实验开发平台

目标平台主要开发软件环境：
c2-sdk-1.3_11-devtools C2 CC1100开发工具链，包括MPU和ENE编译、链接和汇编器等工具
c2-sdk-1.3_11-kernel  C2 CC1100平台linux内核
c2-sdk-1.3_11-qt-4.1.4 C2 CC1100平台界面程序开发包
c2-sdk-1.3_11-sw_media C2 CC1100平台编解码库框架及应用程序开发包
    C2提供的CC1100开发板提供的调试方式为串口方式。在宿主机的minicom程序下，通过串口通信，与目标平台交互。
    CC1100自举方式有多种，开发板上所使用的方式为从SD卡启动。Linux内核和编解码框架都存储在SD卡上。因此，AVS解码器实现完成后，只需要集成到框架程序内，存储在SD卡上，即可运行测试。
    参考实现为AVS小组提供的rm52j标准代码，测试中使用到的avs码流和avs解码中间结果均由rm52标准实现得到。测试序列为shields和stockholm序列，图像分辨率为D1（720×576像素）。

5.2 测试数据

5.2.1 ENE引擎代码大小测试

    第四节已经介绍过，CC1100的ENE引擎提供的存储空间为：2KB DATA RAM，16KB UCODE RAM和6KB VLC RAM。VLC RAM用来存放熵解码所使用的特定结构的码流解析数据。同时，它也可以用来做UCODE RAM使用，但必须满足VLC RAM用做UCODE RAM则须全部作为UCODE RAM的一部分，不能一部分用做VLC RAM另一部分用做UCODE RAM。即ENE引擎上存储空间要么为2KB数据、16KB程序、6KB VLC表或者2KB数据、22（16+6）KB程序。本文中的ENE解码模块实现没有用到VLC表解析码流数据，因此程序最终满足后者的大小约束即可：2KB数据+22KB程序指令。如果不满足该约束，程序将无法下载到ENE上运行或者运行不正常。

5.2.2 ENE引擎代码运行时间测试

    计算运行时间，CC1100开发工具包提供了GetC2CycleCount()函数，该函数能获得当前的时钟计数。通过在函数开始和结束时调用该函数，计算两次时钟计数的差值就可以得到函数运行的时间。
    测试序列采用rm52j_r1参考模型编码得到的shields码流（D1分辨率）。码流格式为IBBBBPBBBBPBBBBP，共16帧。测得数据如下：

 
    也即平均每个并行条带解码时间相对于串行解码时间减少17%左右。

6. 结  论
     从实现结果可以看出，使用C2 CC1100所提供的熵解码引擎，并行进行熵解码和MPU解码，其加速作用是相当明显的，能够达到较高的加速比。
    在整个实现过程中发现，CC1100 ENE引擎熵解码模块设计中，算法层次改动并不大，而是需要针对CC1100平台做合理的映射和功能划分。算法映射和功能划分并不是一下就能完成的工作，需要在不断熟悉硬件平台的基础上进行摸索和完善。另外，从程序实现角度来看，ENE引擎所提供的硬件资源，运算和存储资源都是相当有限的，需要精心设计和布局才能发挥应有的效果。当然，ENE引擎本身被设计为可编程的变长码解析专用处理器，在变长编码方面的硬件支持是相当丰富和高效的。整个实现过程中，最复杂的是ENE引擎输入输出数据流的设计，包括其功能验证和时序验证，都是整个开发过程中耗时耗力最多的部分。
    考虑到CC1100芯片的整体成本和能耗，以及开发的效果，可以看出，CC1100平台作为异构多核心嵌入式媒体处理器，在多媒体处理方面，有其独到的优势。通过合理和细致的设计代码，能够提供高效率的编解码支持。

参考文献

1.<<基于CC1100的AVS解码器设计与实现>>总结报告，北京大学数字媒体芯片与系统实验室，2008年。
2.<<基于CC1100高速DSP音视频处理开发板及软件开发环境设计>>报告，北京大学数字媒体芯片与系统实验室，2008年。