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

时间：06-05 来源：互联网点击：

3多端口SDRAM控制器

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

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

3.1　读写端口和读写仲裁器

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

　　在读写仲裁器（ReadWrite 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），也就是指向当前宏块下一行的基地址处。与此同时，ReadWrite 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的特性要求每64 ms就要对SDRAM的所有行刷新一遍。由于此设计中SDRAM工作在自动预充电模式，所以说预充电命令也只会在初始化过程中出现。

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

4　SoC平台的软件支持

　　参照参考文献[1]，设计了DM9000A的控制端口，并在所设计的SoC平台上移植了μC/OSII实时操作系统和μC/TCPIP协议栈。这是为了方便把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进行了综合，并在台湾友晶科技公司的DE270开发板上实现。整个平台的所占用资源为：逻辑单元10 662个，寄存器4 689个，存储器418 104位。

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

上一篇：基于FPGA的嵌入式图像采集系统设计
下一篇：基于FPGA的数字温度测量仪设计

H 264 视频编码 SoC验证平台软硬件协同仿真相关文章：

栏目分类