一种面向H.264视频编码器的SoC验证平台
扫描二维码
随时随地手机看文章
摘要:构建了面向H.264视频编码器的SoC验证平台,采用FPGA原型系统完成H.264编码器验证。采用Wishbone总线连接32位微处理器OR120 0以及其他的必要IP核构建基本SoC平台,并在此基础上集成H.264硬件编码模块;根据H.264编码器的数据流要求,设计了逐行输入/宏块顺序输出的多端口SDRAM控制器;移植了μC/OS-II实时操作系统和μC/TCP-IP协议栈,用于输出编码后比特流。
关键词:SoC;H.264;OR1200;SDRAM控制器;MT9P031;EP2C70F896C6
引言
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功能。在300 MHz时,可以提供300 DMIPS和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标准以宏块(16x16大小的像素块)为单位进行编码。所以它的数据输入是以宏块为单位的像素块,输出是经过了预测编码、变换编码以及量化和熵编码之后的比特流数据。
1.3 TRDB-D5M图像采集模块
TRDB-D5M图像采集模块中的采用Micron公司生产的CMOS传感器MT9P031。它具有以下特性:低功耗,逐行扫描图像传感器;最高支持到2 592×1944@12fps;12位A/D转换器;支持摄像模式(viewfinder)和快照模式(snapshot);曝光时间可调;双线串行接口(I2C总线接口)等。
2 SoC验证平台的总体框架
如图1所示,SoC验证平台主要包括OR1200处理器、片上RAM控制器、SSRAM控制器、Flash控制器、UART-BOOT模块(用于启动)、UART-16550模块(用于显示信息)、GPIO模块、DM9000A控制器、图像采集模块、双端口SDRAM控制器和VGA控制器。
[!--empirenews.page--]
OR1200微处理器是整个验证平台的控制核心,根据系统的需求和节约的原则,裁去了OR1200中的指令缓存器(IC)、数据缓存器(DC)和存储器管理单元(IMMU和DMMU)。SoC平台中另一个重要的模块就是片上存储器(Onchip-Memory)。片上存储器数据访问能力强,功耗低,但是容量有限,只能实现代码量比较小的特定功能(如硬件初始化、CPU启动引导等)。当完成这些操作后处理器就会跳转到主存储器SSRAM的地址空间执行代码。
在其他的外设模块中,UART-BOOT模块只带有一个Wishbone主端口,用于控制CPU的启动和程序下载,它不需要分配地址。其他模块的地址空间分配情况如表1所列。
在图1所示的IP核中,除了以下几个模块外均可从Opencores网站上免费获得:UART-BOOT模块是为了在验证过程中更加方便地更新下载软件代码和对SoC平台进行控制,需要自主设计;图像采集模块可参考友晶科技公司的参考设计,但是其采集到的数据为RGB格式,需要转换为H.264编码器所需要的YUV格式;此外,由于图像采集模块内部的MT9P031图像传感器是逐行扫描的,而H.264编码器是以宏块顺序进行编码的,因此SDRAM的控制器需要重新进行设计,以满足逐行写入和按宏块读出的要求。
之前有很多人对构建基于嵌入式软核的SoC系统作了研究,本文重点介绍与H.264编码器验证相关的自主设计的模块上。
3 多端口SDRAM控制器
逐行输入/任意宏块顺序输出的多端口SDRAM控制器的整体结构如图2所示。
[!--empirenews.page--]
3.1 读写端口和读写仲裁器
图2中有一个读端口和一个写端口,分别用于H.264编码器读出数据和图像采集模块写入数据。其实还有一个用于VGA显示的读端口,其时序与图像采集模块的写时序相同,都是逐行扫描,在此处略去了。
在读&写仲裁器(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_u sedw的值变为零,一个宏块数据也便读完了。
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的特性要求每64 ms就要对SDRAM的所有行刷新一遍。由于此设计中SDRAM工作在自动预充电模式,所以说预充电命令也只会在初始化过程中出现。
命令生成器还会根据Read&Write Arbiter传过来的读写请求产生读写(read/write)命令。读写(read/write)命令的优先级是最低的,当SDRAM控制器处于初始化过程,或者正在执行刷新命令时,命令仲裁器就会让读写请求一直等待更高优先级的命令执行完毕。此外,由于SDRAM是工作在full-page模式,需要根据写或读的突发长度产生突发终止命令。突发终止命令根据读计数器(write timer)和写计数器(read timer)的值产生,它的优先级低于刷新(refresh)命令,却高于读写(read/write)命令。
4 SoC平台的软件支持
参照参考文献,设计了DM9000A的控制端口,并在所设计的SoC平台上移植了μC/OS-II实时操作系统和μC/TCP-IP协议栈。这是为了方便把H.264编码器所生成的比特流数据传送到PC机端作进一步验证。
5 实验结果
设计了一个H.264编码器模型,它主要实现的功能就是模拟H.264编码器与SDRAM控制器接口处的读时序,从SDRAM中读取数据。同时,它也带有一个Wish-bone从接口,可以把读取的数据传送给OR1200微处理器,OR1200微处理器再经过网口把图像数据传送到PC机,以验证所读取的数据是否正确。利用Wishbone总线功能模型(BFM)在ModelSim SE 6.5f环境下对所设计的模块进行了RTL级的仿真,验证方案框架图如图3所示。
此外,对整个SoC系统选用Altera公司的Cyclone II系列FPGA EP2C70F896C6进行了综合,并在台湾友晶科技公司的DE2-70开发板上实现。整个平台的所占用资源为:逻辑单元10 662个,寄存器4 689个,存储器418104位。
将图像采集模块的时钟设为25 MHz,SDRAM控制器的时钟设置为100 MHz,其他各个模块均运行在50MHz。前述方法把从SDRAM控制器中以宏块为顺序采集到的YUV图像数据通过网口传输到PC机,在PC机端YUV图像数据转换成正常的图像顺序,把Y分量以灰度位图的格式显示,并与VGA显示器中所显示的图像(RGB通道都输入变换后的Y分量)进行对比。
结语
本文基于OR1200微处理器设计了一种面向H.264视频编码器的SoC验证平台,在集成了常用的各类IP核的基础上,重点对与H.264编码器特性相关的多端口SDRAM控制器进行了设计。经过RTL级以及FPGA验证,所设计的平台可以满足H.264编码器软硬件协同验证的各种要求,可大大缩短H.264编码器的开发时间。