一种面向H.264视频编码器的SoC验证平台※

任怀鲁，张德学

（山东科技大学 嵌入式系统与集成电路实验室，青岛 266510）

引 言

H.264编码算法复杂，其硬件实现包含众多模块。H.264编码器往往采用软硬件协同设计：在宏块级及以下，运算量巨大，用软件往往无法实现实时编码，适用于用硬件实现；而在宏块级以上，是一些图像信息打包的工作，运算量小，且随视频序列的不同而不同，为了保证编码器的通用性和灵活性往往用软件实现。软硬件协同设计技术是SoC的主要技术之一，但同时它也使SoC芯片的规模和SoC设计的复杂度大大提高。在这种情况下，仿真和验证就成为了影响项目进度的瓶颈，往往占整个芯片开发周期50%～80%的时间。为了缩短SoC验证时间，基于FPGA的原型验证（包括硬件原型和软件原型）已经成为SoC设计流程前期阶段的常用手段。

OR1200以及其他诸多的与之配套的IP核由Opencores组织负责开发和维护，功能强大，软硬件开发工具齐全，采用免费和开源的授权策略，可以自由地获取源代码，而且大多都经过了ASIC验证，已经受到学术界和工业界越来越多的关注。

为了搭建适用于H.264视频编码器的SoC验证平台，本文主要做了以下几项工作：

①采用OR1200微处理器作为SoC系统的控制核心，通过Wishbone总线互联规范将Opencores组织发布维护的相关IP核集成在目标SoC系统上，构成了最初的SoC验证平台。

②采用台湾友晶科技公司发布的500万像素图像视频采集模块，为H.264视频编码系统提供原始视频数据，并根据H.264标准的要求，在视频采集模块中加入了RGB到YUV颜色空间转换模块，以及逐行输入／任意宏块顺序输出的多端口SDRAM控制器（简称为“多端口SDRAM控制器”）模块。

③在所构建的SoC验证平台上移植了μC／OS－II系统以及μC／TCP－IP协议栈，使H.264视频编码系统生成的数据流输出到通用处理器终端，作进一步的验证。

1 相关技术简介

1.1 OR1200微处理器以及Wishbone总线

OR1200是一种32位、标量、哈佛结构、5级整数流水线的RISC处理器，支持Cache、MMU和基本的DSP功能。在300MHz时，可以提供300DMIPS和300M次32位×32位的DSP乘加操作的能力。OR1200定位于嵌入式、移动和网络应用环境。

Wishbone总线规范是一种片上系统IP核互连体系结构。它定义了一种IP核之间公共的逻辑接口，减轻了系统组件集成的难度，提高了系统组件的可重用性、可靠性和可移植性。Opencores组织经过ASIC或FPGA验证的开源IP核大多都支持Wishbone总线协议。

1.2 H.264／AVC视频编码标准

H.264／AVC标准是迄今最新的一套视频编码标准，它与以往的 MPEG2标准相比，码流节省了50%以上。H.264标准中所用的编码技术主要有：帧内预测、运动估计、整形变换和环路滤波等。

H.264标准以宏块（16×16大小的像素块）为单位进行编码。所以它的数据输入是以宏块为单位的像素块，输出是经过了预测编码、变换编码以及量化和熵编码之后的比特流数据。

1.3 TRDB－D5M图像采集模块

TRDB－D5M图像采集模块中的采用Micron公司生产的CMOS传感器MT9P031。它具有以下特性：低功耗，逐行扫描图像传感器；最高支持到2 592×1 944＠12fps；12位A／D转换器；支持摄像模式（viewfinder）和快照模式（snapshot）；曝光时间可调；双线串行接口（I2C总线接口）等。

2 SoC验证平台的总体框架

如图1所示，SoC验证平台主要包括OR1200处理器、片上RAM 控制器、SSRAM控制器、Flash控制器、UART－BOOT模块（用于启动）、UART－16550模块（用于显示信息）、GPIO模块、DM9000A控制器、图像采集模块、双端口SDRAM控制器和VGA控制器。

图1 SoC验证平台整体结构

OR1200微处理器是整个验证平台的控制核心，根据系统的需求和节约的原则，裁去了OR1200中的指令缓存器（IC）、数据缓存器（DC）和存储器管理单元（IMMU和DMMU）。SoC平台中另一个重要的模块就是片上存储器（Onchip－Memory）。片上存储器数据访问能力强，功耗低，但是容量有限，只能实现代码量比较小的特定功能（如硬件初始化、CPU启动引导等）。当完成这些操作后处理器就会跳转到主存储器SSRAM的地址空间执行代码。

在其他的外设模块中，UART－BOOT模块只带有一个Wishbone主端口，用于控制CPU的启动和程序下载，它不需要分配地址。其他模块的地址空间分配情况如表1所列。

表1 SoC系统的地址空间分配

在图1所示的IP核中，除了以下几个模块外均可从Opencores网站上免费获得：UART－BOOT模块是为了在验证过程中更加方便地更新下载软件代码和对SoC平台进行控制，需要自主设计；图像采集模块可参考友晶科技公司的参考设计，但是其采集到的数据为RGB格式，需要转换为H.264编码器所需要的YUV格式；此外，由于图像采集模块内部的MT9P031图像传感器是逐行扫描的，而 H.264编码器是以宏块顺序进行编码的，因此SDRAM的控制器需要重新进行设计，以满足逐行写入和按宏块读出的要求。

之前有很多人对构建基于嵌入式软核的SoC系统作了研究，本文重点介绍与H.264编码器验证相关的自主设计的模块上。

3 多端口SDRAM控制器

逐行输入／任意宏块顺序输出的多端口SDRAM控制器的整体结构如图2所示。

3.1 读写端口和读写仲裁器

图2中有一个读端口和一个写端口，分别用于H.264编码器读出数据和图像采集模块写入数据。其实还有一个用于VGA显示的读端口，其时序与图像采集模块的写时序相同，都是逐行扫描，在此处略去了。

图2 逐行输入／任意宏块顺序输出的多端口SDRAM控制器结构

在读＆写仲裁器（Read＆Write Arbiter）中处理来自读端口的读请求和来自写端口的写请求。写请求的优先级高于读请求的优先级。写端口由写缓存器（WE＿FIFO）和写地址生成器（WE＿Addr Generator）组成。WE＿FIFO的深度为512字（每个字32位，存一个像素），当图像采集模块在WE＿FIFO中写够256个字之后，就会发起一次写请求。写地址生成器每完成一次写请求之后便会增加256，地址增加的顺序与CMOS图像传感器的扫描顺序相同。

读端口由读缓存器（RD＿FIFO）、读地址生成器（RD＿Addr Generator）、读状态机（RD＿FSM）和行计数器（Line＿Cnt）组成。RD＿FIFO的深度为256字，载入宏块地址（addr＿load）的命令发出后，RD＿FSM 就进入了工作状态（read＿stat信号为1）。同时，读地址生成器已经根据宏块的水平位置（mb＿num＿h）和垂直位置（mb＿num＿v）计算出了宏块所在SDRAM中的基地址。当RD＿FSM处于工作状态时，读请求一直有效，如果此时写请求无效，就会发起一次长度为16的突发读传输，从SDRAM中读取16个像素数据到RD＿FIFO。当完成一次读传输之后，读地址生成器会自动加一行的长度（可配置，此处为800），也就是指向当前宏块下一行的基地址处。与此同时，Read＆Write Arbiter模块会检测写请求是否有效，如果有效则优先发起长度为256的突发写传输，等写传输完成后再完成下一次长度为16的突发读传输。如此，当完成16次突发读传输后，所读宏块的数据也就完全写入到RD＿FIFO中了，此时，RD＿FSM由工作状态转为闲置状态，等待下一次的宏块读请求。

当RD＿FIFO中的数据数量（rd＿usedw）不为零时，H.264编码器即可从RD＿FIFO中读取数据。当读完256个数据，即一个宏块的数据后，rd＿usedw的值变为零，一个宏块数据也便读完了。

3.2 SDRAM命令生成器和命令仲裁器

SDRAM命令生成器（Command Generator）主要作用是根据SDRAM的控制时序生成SDRAM接口处的控制命令，这些命令是有可能发生冲突的。命令仲裁器（Command Arbiter）的作用就是对命令生成器产生的命令进行仲裁。

SDRAM的初始化过程可分成初始化延迟、预充电、刷新、设置模式寄存器4个阶段，这4个阶段由一个初始化计数器（initial timer）控制。SDRAM命令生成器根据初始化计数器的值会产生初始化延迟（initial）命令、预充电（precharge）命令、刷新（refresh）命令和设置模式寄存器（load＿mode）命令。其中，刷新（refresh）命令也可以在SDRAM的工作过程中根据刷新计数器（refresh timer）的值产生。这是因为SDRAM的特性要求每64ms就要对SDRAM的所有行刷新一遍。由于此设计中SDRAM工作在自动预充电模式，所以说预充电命令也只会在初始化过程中出现。

命令生成器还会根据Read＆Write Arbiter传过来的读写请求产生读写（read／write）命令。读写（read／write）命令的优先级是最低的，当SDRAM控制器处于初始化过程，或者正在执行刷新命令时，命令仲裁器就会让读写请求一直等待更高优先级的命令执行完毕。此外，由于SDRAM是工作在full－page模式，需要根据写或读的突发长度产生突发终止命令。突发终止命令根据读计数器（write timer）和写计数器（read timer）的值产生，它的优先级低于刷新（refresh）命令，却高于读写（read／write）命令。

4 SoC平台的软件支持

参照参考文献［1］，设计了DM9000A的控制端口，并在所设计的SoC平台上移植了μC／OS－II实时操作系统和μC／TCP－IP协议栈。这是为了方便把H.264编码器所生成的比特流数据传送到PC机端作进一步验证。

5 实验结果

设计了一个H.264编码器模型，它主要实现的功能就是模拟H.264编码器与SDRAM控制器接口处的读时序，从SDRAM中读取数据。同时，它也带有一个 Wishbone从接口，可以把读取的数据传送给OR1200微处理器，OR1200微处理器再经过网口把图像数据传送到PC机，以验证所读取的数据是否正确。利用Wishbone总线功能模型（BFM）在ModelSim SE 6.5f环境下对所设计的模块进行了RTL级的仿真，验证方案框架图如图3所示。

图3 多端口SDRAM控制器验证方案

此外，对整个SoC系统选用Altera公司的Cyclone II系列FPGA EP2C70F896C6进行了综合，并在台湾友晶科技公司的DE2－70开发板上实现。整个平台的所占用资源为：逻辑单元10 662个，寄存器4 689个，存储器418 104位。

将图像采集模块的时钟设为25MHz，SDRAM控制器的时钟设置为100MHz，其他各个模块均运行在50 MHz。前述方法把从SDRAM控制器中以宏块为顺序采集到的YUV图像数据通过网口传输到PC机，在PC机端YUV图像数据转换成正常的图像顺序，把Y分量以灰度位图的格式显示，并与VGA显示器中所显示的图像（RGB通道都输入变换后的Y分量）进行对比。

结 语

本文基于OR1200微处理器设计了一种面向H.264视频编码器的SoC验证平台，在集成了常用的各类IP核的基础上，重点对与 H.264编码器特性相关的多端口SDRAM控制器进行了设计。经过RTL级以及FPGA验证，所设计的平台可以满足H.264编码器软硬件协同验证的各种要求，可大大缩短H.264编码器的开发时间。

编者注：本文为期刊缩略版，全文见本刊网站www.mesnet.com.cn。

［1］Lin Zuo.System－on－Chip design with Open Cores［OL］.［2011－08］.http：／／www.olivercamel.com／post／master＿thesis.html.

［2］OR1200OpenRISC Processor［OL］.［2011－08］.http：／／opencores.org／or1k／OR1200 ＿OpenRISC＿Processor.

［3］Micron.5－Megapixel，1／2.5－Inch CMOS Image Sensor for Wide FOV and Electronic Pan／Tilt Cameras［OL］.［2011－08］.http：／／download.micron. com／pdf／flyers／MT9P031%－20Flyer.pdf.

［4］张力航，林涛.软硬件协同设计技术在 H.264解码器设计中的应用［J］.电子技术应用，2006（9）.

［5］虞致国，魏敬和.基于FPGA的ARM SoC原型验证平台设计［J］.电子与封装，2007（5）.

［6］Busa N，Alkadi G.A modular，multi－board，heterogeneous multi－processor，PCI bus based prototyping framework for the validation of SoC VLSI designs［C］／／13th IEEE International Workshop onRapid System Prototyping，2002：159－165.

［7］桑圣峰，张德学.AEMB软核处理器的SoC系统验证平台［J］.单片机与嵌入式系统应用，2007（5）.

［8］徐敏，孙恺.开源软核处理器OpenRisc的SOPC设计［M］.北京：北京航空航天大学出版社，2008.

［9］孙恺，王田苗.嵌入式CPU软核综述［J］.计算机工程，2006（7）.

［10］Pei Ke，Zhang Gang.Design of Boot Loader with Multiple Communication Port［C］∥Computer Science and Software Engineering，12－14Dec.2008：169－175.

［11］Gyounghwan Hyun，Yongseok Jin.A Synchronous DRAM Controller for an H.264／AVC Encoder［C］∥SoC Design Conference，24－25Nov.2008.

［12］Zhang Yu，Ling Ming.Performance Exploration and Optimization of SDRAM－Controller Architecture on SDRAM Access［C］∥ASICON 2005，Oct.2005：203－207.

［13］Szymanski T，Kielbik R.SDRAM controller for real time digital image processing systems［C］∥CAD Systems in Microelectronics，2001：72－75.