原创 图片显示速度测试报告

图片显示速度测试报告

1 测试硬件平台：

CPU：32位NIOS/e  50MHz

RAM：片上存储器  50MHz

2 测试软件程序：

    for(y=0;y<480;y++)

    {

         for(x=0;x<800;x++)

            {

//送显示数据

IOWR_16DIRECT(MCULCD_CTRL_0_BASE,((y<<11)+(x<<1)), 0x001f);     

            }

}

3 测试接口时序：

一次IOWR_16DIRECT()函数产生的时序波形如图1所示。Clk即CPU得时钟周期50MHz，也就是20ns，那么从图1推断一次液晶显示数据的写入时间大约为6*20ns=120ns。

图1

4 测试结果分析：

下面是实际示波器采集到的被专门拉出来观察的LCD写入片选信号cs_n的波形。图2是单次选通的波形，大约120ns，和前面的时序图（图1）是一致的。

    而图3是多次（波形中有3次）连续的液晶写入操作产生的片选信号cs_n的波形。让人感到意外的是，即便只是简单的x<800和x++以及(y<<11)+(x<<1))程序的执行，竟然占到了大约1500ns的执行时间。仔细想想，这是软件，虽然CPU的时钟达到50MHz，但是一条指令的执行（我们姑且认为指令周期能够达到40ns），不仅仅包括执行这条语句本身，还有一个变量的读写需要访问存储器（RAM）额外的时间开销，这些东西一算下来，1500ns也就不足为怪了。

图2

图3

    有了上面的这组数据，我们可以做一个简单的预算。对于特权同学的这个液晶控制器，单纯写数据显示一满屏的色彩数据（分辨率800*600，写入的色彩固定），需要的时间是：

    120ns*800*480 = 46.08ms

    对于通常来说，如果一幅图片的显示切换能够达到这个速度，换算成1s的频率是1s/46.08ms=21Hz（通常显示器刷新率是60Hz）。基本上这个切换是很不错的性能，人眼也是完全可以接受的。

    而对于一个CPU，它要显示一幅图片，不可能只是一味的做前面的简单写时序，还还需要一些坐标计数，一些变量存储器的读写。而对于这个测试中，只是一个简单的清屏函数，它也是考核CPU性能的一个方式，如果这样数据简单的搬运所需要的时间过长，以致无法让人眼接受（切换时间过长），那么说明软件送图片到液晶控制器然后切换显示的方案不是很可行。下面可以算算目前的平台下，软件送一个屏的数据大约需要的时间：

    1500ns*800*480 = 576ms

    这个数据可以说是当前软硬件平台上，真正软件送图片不可逾越的速度瓶颈了。但是，这个时间也只是客户勉强可以接受的切换图片的效果。对于图片需要预存储在FLASH或SD卡等非易失存储器中的应用，软件一般是先从这些非易失存储器中读取数据，然后再送给液晶控制器，而如此一来，一幅图片切换的时间要远远大于576ms了，2倍甚至3倍都不足为怪。

5 优化尝试与考虑：

1.       提升CPU的性能

提高CPU的时钟，提高CPU读写RAM存储器的速度，这个代价比较高，不仅关系到成本，而且需要开发人员换一个处理器和软件开发环境，相应的开发时间会受到很大影响。

2.       纯硬件加速

由FPGA底层逻辑来控制非易失存储器（图片存储器，如FLASH）的读写。用FPGA来控制这些非易失存储器的读写开发灵活性较低，对图片的管理和地址的分配都不够灵活。而且速度的瓶颈在于非易失存储器的读速度。

3.       软硬件协同加速

这种考虑是在FPGA显存中开辟一大块图片预存储空间，上电后CPU做的第一件事就是不断的搬运数据，把需要显示的数据预先从非易失存储器中读出来，并送给显存。这可能在系统刚上电过程中有一段较长的boot时间，但是boot结束后，软件需要切换显示画面时，只要发出一些定制指令，那么FPGA内部逻辑自动实现两块显存的数据映射（从不显示存储区搬数据到显示区）。这种现实方式相较于前两种优化方案是最可行的，而且切换画面的速度也是最快的。