【摘 要】提出了H.264/AVC 硬件编码器的一种3 级流水结构，以此来提高硬件加速电路的处理能力和利用效率。鉴于H.264 编码芯片验证的复杂性,还提出了一种基于ADSP-BF537的新型多媒体SoC 验证平台，并讨论了如何利用BF537，对H.264 编码芯片进行全面、高效的软硬件协同验证。
【关键字】H.264 编码器；硬件加速器；ADSP-BF537；软硬件协同验证；SoC

1 引言

 H.264[1]标准颁布以来, 其提供的高效的压缩率以及优质的图像质量已经得到了广泛的认可, 应用H.264 标准的各种编解码器也不断涌现, 其应用也层出不穷, 从传统的数字机顶盒、视频会议系统、可视电话到IP 视频服务、个人媒体播放器( PMP)。由于H.264编码算法复杂,必须要有强劲有力的硬件作为支持。目前，基于各种芯片的H.264解决方案相继推出，在实现H.264实时编码的芯片当中，主要有以下几种方案：基于专用芯片的结构(SoC+ASIC)；基于DSP+ARM的结构；基于x86的结构。但低成本、低功耗以及高计算能力一直是方案中互相冲突的因素，在这3个因素的相互制约下，各方案有其不同的效果。

本文采用基于专用芯片的结构，选用RISC CPU + 硬件加速电路的基本架构，在硬件编码器的流水设计上采用3 级流水设计，以32 位的MIPS 核作为芯片内部编码控制单元，以满足内部编码运算处理、图像数据存取速度以及外部通信接口等方面的高指标要求。为了解决芯片内部不同模块间的高速互连访问，采用AHB 总线将MIPS 核与硬件加速电路、存储器控制模块相连。在H.264 编码器的SoC 功能原型验证上，本文提出了利用ADSP-BF537[2]作为处理器的验证方案，通过软件和硬件的并行运行，实时监控并判断硬件的结果，能方便快捷地完成H.264 编码硬件加速器的功能原型验证和系统级验证，有效提高H.264 编码器SoC 设计验证的效率，缩短开发周期。

2 H.264硬件编码器结构划分和流水设计

 H.264 所获得的优越性能是以增加计算复杂度为代价的,据估计，H.264编码复杂度大约相当于H.263的3倍。H.264编码算法的几个特点如下：
(1) H.264的编码算法极度复杂，H.264引入了变块尺寸的运动估计，多参考帧，帧内预测[3]，CAVLC，CABAC以及去块效应滤波等一系列的新方法来提高编码效率，但这也造成了VLSI实现时关键路径过长；
(2) 整数运动估计模块有极高的计算复杂度，需要进行大量的存储器读写，它占用了整个系统将近80%的数据传输和计算量；
(3) 由于块可变尺寸估计和多帧估计，给模式判决带来了大量的串行计算；
(4) 帧间预测引入了了多种模式，这降低了数据的独立性，给并行处理和数据公用带来困难。上述的H.264编码算法的特点给H.264编码器硬件加速电路的设计带来了极大的困难，本节将讨论硬件加速电路的模块划分和流水线设计，尽可能实现并行处理和数据重用，从而满足实时处理的要求。针对以往的视频压缩算法，编码器的硬件加速电路一般采取2级流水线的设计方法，如图1所示。

 

图1 2 级流水线的硬件加速电路系统结构图

处理器负责处理宏块及更高级的控制，硬件加速模块ME(运动估计)，REC(重构)，EC(编码)和DPCM Loop(DCT/Q/IDCT/IQ)通过与总线相连来起到加快编码操作的作用。为了降低通过总线的数据量，对REC、EC 和DPCM Loop 模块的局部存储器进行共享，这几个模块又被称作BE(Block Engine)。整个流水线被分为ME 和BE 两级，其中ME 模块占用了整个系统绝大多数的计算量和带宽。在进行处理时，首先ME 模块按照光栅扫描(raster scan)顺序对宏块进行处理，在ME 对当前宏块处理完成之后，BE 模块接着对改宏块进行编码，而此时ME模块可对下一模块进行处理。

这种基于宏块的两级流水线结构应用在传统的视频编码器上又很好的表现，但它并不适合H.264 编码算法。H.264 的多帧预测和去块效应滤波算法造成了对带宽要求的急剧增加。例如在进行帧间预测时，编码芯片需要从片外存储器读取16x16 个8 比特编码数据，64x16个8 比特参考点数据以及周边4 个宏块的编码信息。每帧图像有720x576/256=1620 个宏块，每秒需要编码30 帧图像，先不考虑周边宏块的编码信息，则每秒需要读取的数据为（16x16+64x16）x1620x30 = 60Mbyte/s.采用各个硬件加速模块通过总线进行通讯的方式很难满足实时编码数据传输的要求；其次，H.264 的模式判决机制对宏块中的各个块使用串行处理的方式，这在提高编码效率的同时，也造成了相邻块数据间的非独离性，这给并行处理和流水线操作造成了极大的困难。

针对H.264 编码算法的特点，对前面讨论的结构做出了改进，提出一种新的硬件加速电路的设计结构，该结构采用采用3 级流水线结构，以此来增加硬件加速电路的处理能力和利用效率，具体的流水线结构如图2 所示。

图2 H.264 编码器3 级流水结构图

第一级为从片外存储器读取需要的数据到内部的乒乓RAM，第二级为内部编码流程，包括预测（PREDICT），残差编码（DCT/Q/IDCT/IQ），重构（REC），熵编码（EC）和滤波（DB），第三级为从内部乒乓RAM发送数据到片外存储器。

3 基于ADSP-BF537 的SoC 验证平台及验证策略

3.1 验证平台的结构组成
由于ASIC 芯片设计高昂的流片费用，为了提高一次成功率，对设计的各个环节进行全面，高效的验证至关重要。对于规模较大，复杂度高的ASIC 芯片，基于FPGA 的系统原型验证已经成为流片前不可缺少的环节。本项目设计是一款H.264 视频编码SoC 芯片，采用的验证平台是基于ADSP-BF537 的多媒体验证平台，该平台可以对音视频编解码系统进行全面高效的验证。其结构组成图如图3 所示。

图3 多媒体SoC 验证平台结构组成图

其中SDRAM 用来存储中间数据，比如图像的参考帧YcbCr 像素数据等；另外，操作系统的快速运行也需要SDRAM 的支持。Flash 用来存储音视频编解码器的输入数据；处理音视频编解码时，还需要有音视频ADC 和DAC 来实现模拟信号的采集和还原；由于音视频编解码器逻辑较大，再加上系统总线、SDRAM 控制器，以及其他外设模块，还需要一个大容量高性能的FPGA 作为芯片的原型。本设计采用Altere 的StratixII EP2S130，内部具有十万数量级的ALUT 和6 MB 的内部SRAM，以满足验证需求。

 对于BF537，直接利用其配套的EZ-KIT 开发板，通过在FPGA 验证板上设计与之兼容的插座，并将所有EZ-KIT 插座上对应的I/O 口与FPGA 的I/O 相连即可。采用的EP2S130 是1020 管脚封装，具有700 多个可配置I/O 引脚，满足连接数量的要求。基于ADSP 系列芯片以及EZ-KIT 开发板，ADI 也拥有自己的功能强大的编译调试工具VisualDSP，完全支持标准的C/C++，具有独立的汇编指令集，支持汇编与C 的嵌套编程，使ADSP 性能得到最大的发挥。VisualDSP 通过JTAG，还可以在EZ-KIT 中实现在线实时单步、断点调试，使得在ADSP 运行过程中，实现与PC 机的交互。基于ADSP 的强大处理能力和方便灵活的编译调试工具，可以利用ADSP，进行多媒体SoC 的复杂功能模块的验证。

3.2 H.264 编码器软硬件协同验证策略
 该编码器采用的是RISC CPU + 硬件加速电路的基本架构，性能要求较高的运算采用专用电路实现，通过协处理器来增加可配置特性。在整个编码器的验证过程中，软硬件协同验证才是全面、高效的验证方法[4]。H.264 编码加速器设计都是基于已经验证通过的利用C 语言实现的算法改写而成的。而基于内核主频高达600 MHz 的BF537 完全可以实现各种音视频编解码标准的软件实现，因此，利用BF537 支持的软件不但可以通过自己定义的接口函数来驱动硬件运行，还可以通过比较软件和硬件的同步数据，实现H.264 编解码加速器模块的功能验证。利用BF537 进行软硬件协同验证的原理如图4 所示。

图4 基于BF537 的软硬件协同验证原理图

 其基本思想是：基于BF537，利用C 语言已经实现的算法，将其中需硬件实现的函数，经过RTL 转为硬件后，在原始软件平台下，去除已经改写成硬件的软件部分，保持其他软件不变，而通过接口函数驱动FPGA 内的已实现的硬件算法，并通过接口函数，将硬件处理完毕的结果送回BF537 继续运行，如果最后运行的结果和纯软件运行的正确结果一致，则说明改写的函数4 的RTL 是正确的，否则，检查相应RTL 代码。

3.3 基于ADSP-BF537 验证平台的功能原型验证
 整个H.264 编码器的功能原型验证工作，都是在图3 所示的多媒体验证平台下完成的。软件部分由ADSP 来运作，硬件部分由ADSP_FPGA 完成，并由ADSP 通过自己定义的接口函数来驱动硬件运行，从而实现软硬件协同验证。对于视频验证过程中的读写激励操作，是由BF537 通过外部Memory 总线时序来建立相应的读写task 函数，并按照软件定义的接口函数顺序调用task 函数，完成BF537 对外读写AHB 的task 函数。
 对于H.264 编码器在验证板上的执行过程，首先利用软件，将编码图像的YUV 文件暂存在Flash 内。以后每次验证测试时，直接从Flash 中取出YUV 视频数据存放到SDRAM 中。然后H.264 软件编码系统开始启动，由BF537 进行软编码，将硬件编码系统中所需要的编码参数存放在SDRAM 中。接着实现编码参数从SDRAM 到H.264 硬件编码系统的传输，这个操作一般由DMA 和BF537 共同完成，大片参数数据的传输，启动系统DMA 将数据倒送到Buffer，而小片参数数据，由BF537 来完成数据传输。编码参数配置完成后，启动硬件编码系统，开始硬件编码，把编码后数据存入SDRAM。最后回到软件编码系统，进行最后的软编码，将编码后的码流存入SDRAM。上述过程中，硬件部分的系统DMA 和H.264 硬件编码系统在完成各自操作时，产生中断，并且中断信号均连接到BF537 的GPIO 口上，利用GPIO 的中断响应功能，使BF537 能接收这些中断，并执行中断服务程序。整个编码过程中，采用流水设计，软硬件并行运行。
 对于H.264 编码器的验证，可以通过设置一些标志位和读写寄存器，来完成其内部功能的验证。比如，H.264 编码器中的DCT 变换模块，为了验证该硬件模块，在BF537 上同时进行DCT 变换软件编码，当硬件完成DCT 变换编码后，通过BF537 读取编码后的输出数据，再与软件编码后的输出数据相比较，以验证和调试相应的RTL 代码。类似的方法也可以验证量化、帧内预测、帧间预测等模块的算法实现。编码器中所有模块的功能原型验证都是在此验证系统中完成的，采用的是先部分后整体的思路，先进行单个硬件模块软硬件协同验证，然后再进行系统的验证。
 基于ADSP-BF537 EZ-KIT 开发板的优良性能，利用BF537 内部的DMA，选择自动缓冲传输模式（最大传输64 k×32），还可以将最后编码得到的正确的码流数据和编码过程中的用来做参考帧的拟解码数据从SDRAM 分批读出，每批读64 k 个32 位数，在BF537 内设两个64 k×32 的乒乓Buffer。为了更直观的验证编码器的正确性，将编码处理后参考帧的数据，经过视频转换器处理后，通过VGA 或DVI 视频显示接口，可以实现编码过程中作为参考帧的拟解码数据的视频播放。

4 结论

 目前，基于ASIC、3 级流水设计的H.264 编码器，已经通过了大多数视频序列的编码测试。在ADSP-BF537的多媒体验证开发板上，工作频率最多可以达到53MHz，完全可以满足30 帧/秒CIF 格式视频实时编码；本设计最终目标是应用于视频电话系统，最大支持720×576/30P 的图像格式，即H.264/AVC 标准中的3 级(Level)及其以下级别。ASIC 实验证明：采用0.13um CMOS 生产工艺，面积10.8MM2，工作频率133MHz，可以满足该编码芯片的系统性能要求；算法的复杂度决定了硬件前期的开发周期，尤其是系统级验证[5]，本文编码器的验证采用的是基于ADSP-BF537 多媒体SoC 验证平台，有效的提高了SoC 验证效率，缩短该编码器的开发周期。实践证明，该验证方案是一种全面、高效的多媒体SoC 验证方案。

参考文献
[1] Vcodex H.264/ MEPG24 Part 10 White Paper[EB/OL].www.vcodex.com ,2004207204.
[2] Analog Device,Inc.Getting Started with ADSP-BF537 EZ-KIT Lite [EB/OL]. www.analog.com,2005.
[3] 毕厚杰.新一代视频压缩编码标准-H.264/AVC[M].北京：人民邮电出版社,2005.5.
[4] 郭鹏飞.SoC 设计中软硬件协同设计.中国电子站2005.02.11.
[5] Rashinkar P.System-On-a-Chip Verification Methodology and Techniques [M].USA：Kluwer Academic
Publishers,2001.6-10.