论文部分内容阅读
uClinux上C2H加速的JPEG压缩
按JPEG标准进行的图像压缩大小为640x400。libjpeg的前向式DCT函数被加速器取代；该加速器使用C2H编译器开发而成，可以在uClinux环境中进行访问。将C2H加速器与uClinux结合非常重要，因为它要与其它任务同时运行。对libjpeg(标准库)进行加速使我们可以无需增加额外的DSP片或任何常见的软件就能获得性能的提升。使用libjpeg的应用程序可以通过重新编译提高压缩性能，而不必修改任何代码。
自定义的OBD-Ⅱ接口
车辆都有一个用于进行系统管理的发动机控制单元(ECU)。警用车辆上也有这样的设备。对于新近制造的车辆来说，ECU是一个非常重要的组件，其作用是将发动机与各种电子控制部件结合起来。OBD-Ⅱ是一个接口，可以将计算机或诊断工具连接到ECU以便进行车辆维护，它可以实现设备间的通信。
OBD标准有很多种，具体取决于车辆的制造商。本项目采用的是IS09141-2国际标准。通过OBD-Ⅱ，可以了解车辆的行驶速度、燃油状态和车辆的故障情况。其初始化过程为5波特，通信速度为10.4k波特。对于接收到的信息部分字节，必须进行补充并将其发送到ECU进行通信。在SoPC平台上使用的是UART组件，因为它与串行通信类似。
性能参数
表1列出了在图像处理模块上发送控制信号，到步进马达上接收初始操作信号之间的时间间隔。该时间间隔是通过示波器测量得出的。通过GPIO接口启动步进马达后，在软件程序控制器中，Nios处理器会接收中断信号，并生成操作信号。
汽车跟踪摄像头的速度主要取决于图像处理性能。表2显示了基于不同平台的每种跟踪算法的测试帧速率。实际上，DE2的帧速率接近60帧／秒，因为图像处理模块以隔行扫描模式运行；但是，我们根据有效帧的数量将其标记为29帧／秒。
另一个结果是，C2H加速的libjpeg的DCT函数可以实现JPEG的快速压缩。640×400的24位位图经过了20倍强压缩以实现精确的测量。使用C2H编译所显示出来的性能比这种没有加速器设计的性能要差。要解决此问题，我们更改了缓冲区管理方法。在修改了DCT函数后，性能提升了4倍。
我们在设计该系统时，考虑了在uClinux系统上使用USB调制解调器时的性能下降问题。然而事实显示，网络性能与在PC环境中运行的性能几乎相同。
设计的体系结构
整个系统由uClinux操作系统控制。包括图像处理模块在内的摄像头控制系统和子系统由完整的FPGA组成。
标准JPEG库libjpeg的DCT函数被更改为C2H加速器。图像处理模块、VGA控制器和步进马达控制器被组合成一个单独的SoPC组件。总共消耗了31000LE。
设计描述
组合uClinux和C2H
使用操作系统可以灵活地在复杂的多设备环境系统中进行开发。uClinux内核是适合于非MMU处理器的操作系统内核。由于uClinux系统中没有内存管理单元，因此可以极大地简化基于Nios处理器对定制的硬件加速器进行访问的应用程序的使用。
在Nios IDE环境中编写的代码经过很少的更改或无需更改即可在uClinux下的多任务环境中运行，因为在uClinux中对内存映射地址的写操作没有限制。
我们可以通过常用的技术在uClinux上使用C2H加速器。将C2H加速器从NiosIDE移到uClinux上所需步骤如下：
第一步是生成一个临时项目。然后，在Nios IDE中编译并生成加速器。现在，我们可以在Debug目录中看到加速器的打包函数。将这些头文件(Header file)和打包函数复制到uClinux开发目录中。如果您尚未对FPGA编程，则进行该项编程。
下一步是使用Nios的gcc工具和elf2flt选项编译经过加速的应用程序。确保必需的头文件(如system.h或io.h)存在。在完成此步骤后，将生成的执行文件复制到单片机上。在大多数情况下，它的速度会比仅使用软件的系统要快。
可惜的是，我们在将libjpegDCT函数转换成加速器时面临着性能方面的问题。我们将在接下来的部分介绍针对性能问题的解决方案。
优化C2H编译器的JPEG库
一般情况下，开发人员会考虑使用DSP进行JPEG压缩，但DSP需要有自己的软件程序来提供支持。选择可以加速libjpeg的C2H编译器是一个正确的决定，因为许多现有应用程序都使用作为JPEG标准库的libjpeg。
但是，在使用C2H编译器转换原始的DCT函数时，它所显示的性能比仅使用软件设计的性能低。从结构上来说，对数据高速缓存的刷新是一个问题，它的数据处理工作是以64个字节为单位进行的。我们设计了适合于C2H编译器的经过优化的缓冲区管理系统。这个管理器实现了4倍的性能提升。
创建自定义的SoPC组件
每个部件都由VerilogHDL单独设计，并作为一个组件添加到SoPC中。图像处理模块、VGA控制器和步进马达控制器被组合成—个单独的SoPC组件，因为这些部件相互之间都有密切的关联。这些组件作为Avalon Master的组件在SRAM上写入图像数据。
使用自定义指令对MPEG音频进行解码
在使用NiosⅡ处理器和uClinux的环境中播放MPEG音频存在三个主要问题：处理器性能、FIFO的大小以及在uClinux中用于输出的设备驱动程序。
我们发现，100 MHz Nios Ⅱ处理器在CydoneⅡ芯片上对立体声128Kbps 44.1KHzMP3音频进行解码时会有性能损失。如果FIFO足够大，则可以在该系统中播放单声道音频，但CPU会一直分配用于播放音频的性能。
我们在Nios处理器上添加了使用自定义指令的64位乘法器以实现64位乘法计算；这种运算方法在Libmad库中经常用到。播放的性能提升了大约2.5倍，用于计算的时钟使用率有所降低。
还有其它一些原因使音频播放质量不佳。首先是采样率不好，其次是缓冲区大小不足，最后是多任务处理环境。音频将参考使用17MHz的时钟。
按JPEG标准进行的图像压缩大小为640x400。libjpeg的前向式DCT函数被加速器取代；该加速器使用C2H编译器开发而成，可以在uClinux环境中进行访问。将C2H加速器与uClinux结合非常重要，因为它要与其它任务同时运行。对libjpeg(标准库)进行加速使我们可以无需增加额外的DSP片或任何常见的软件就能获得性能的提升。使用libjpeg的应用程序可以通过重新编译提高压缩性能，而不必修改任何代码。
自定义的OBD-Ⅱ接口
车辆都有一个用于进行系统管理的发动机控制单元(ECU)。警用车辆上也有这样的设备。对于新近制造的车辆来说，ECU是一个非常重要的组件，其作用是将发动机与各种电子控制部件结合起来。OBD-Ⅱ是一个接口，可以将计算机或诊断工具连接到ECU以便进行车辆维护，它可以实现设备间的通信。
OBD标准有很多种，具体取决于车辆的制造商。本项目采用的是IS09141-2国际标准。通过OBD-Ⅱ，可以了解车辆的行驶速度、燃油状态和车辆的故障情况。其初始化过程为5波特，通信速度为10.4k波特。对于接收到的信息部分字节，必须进行补充并将其发送到ECU进行通信。在SoPC平台上使用的是UART组件，因为它与串行通信类似。
性能参数
表1列出了在图像处理模块上发送控制信号，到步进马达上接收初始操作信号之间的时间间隔。该时间间隔是通过示波器测量得出的。通过GPIO接口启动步进马达后，在软件程序控制器中，Nios处理器会接收中断信号，并生成操作信号。
汽车跟踪摄像头的速度主要取决于图像处理性能。表2显示了基于不同平台的每种跟踪算法的测试帧速率。实际上，DE2的帧速率接近60帧／秒，因为图像处理模块以隔行扫描模式运行；但是，我们根据有效帧的数量将其标记为29帧／秒。
另一个结果是，C2H加速的libjpeg的DCT函数可以实现JPEG的快速压缩。640×400的24位位图经过了20倍强压缩以实现精确的测量。使用C2H编译所显示出来的性能比这种没有加速器设计的性能要差。要解决此问题，我们更改了缓冲区管理方法。在修改了DCT函数后，性能提升了4倍。
我们在设计该系统时，考虑了在uClinux系统上使用USB调制解调器时的性能下降问题。然而事实显示，网络性能与在PC环境中运行的性能几乎相同。
设计的体系结构
整个系统由uClinux操作系统控制。包括图像处理模块在内的摄像头控制系统和子系统由完整的FPGA组成。
标准JPEG库libjpeg的DCT函数被更改为C2H加速器。图像处理模块、VGA控制器和步进马达控制器被组合成一个单独的SoPC组件。总共消耗了31000LE。
设计描述
组合uClinux和C2H
使用操作系统可以灵活地在复杂的多设备环境系统中进行开发。uClinux内核是适合于非MMU处理器的操作系统内核。由于uClinux系统中没有内存管理单元，因此可以极大地简化基于Nios处理器对定制的硬件加速器进行访问的应用程序的使用。
在Nios IDE环境中编写的代码经过很少的更改或无需更改即可在uClinux下的多任务环境中运行，因为在uClinux中对内存映射地址的写操作没有限制。
我们可以通过常用的技术在uClinux上使用C2H加速器。将C2H加速器从NiosIDE移到uClinux上所需步骤如下：
第一步是生成一个临时项目。然后，在Nios IDE中编译并生成加速器。现在，我们可以在Debug目录中看到加速器的打包函数。将这些头文件(Header file)和打包函数复制到uClinux开发目录中。如果您尚未对FPGA编程，则进行该项编程。
下一步是使用Nios的gcc工具和elf2flt选项编译经过加速的应用程序。确保必需的头文件(如system.h或io.h)存在。在完成此步骤后，将生成的执行文件复制到单片机上。在大多数情况下，它的速度会比仅使用软件的系统要快。
可惜的是，我们在将libjpegDCT函数转换成加速器时面临着性能方面的问题。我们将在接下来的部分介绍针对性能问题的解决方案。
优化C2H编译器的JPEG库
一般情况下，开发人员会考虑使用DSP进行JPEG压缩，但DSP需要有自己的软件程序来提供支持。选择可以加速libjpeg的C2H编译器是一个正确的决定，因为许多现有应用程序都使用作为JPEG标准库的libjpeg。
但是，在使用C2H编译器转换原始的DCT函数时，它所显示的性能比仅使用软件设计的性能低。从结构上来说，对数据高速缓存的刷新是一个问题，它的数据处理工作是以64个字节为单位进行的。我们设计了适合于C2H编译器的经过优化的缓冲区管理系统。这个管理器实现了4倍的性能提升。
创建自定义的SoPC组件
每个部件都由VerilogHDL单独设计，并作为一个组件添加到SoPC中。图像处理模块、VGA控制器和步进马达控制器被组合成—个单独的SoPC组件，因为这些部件相互之间都有密切的关联。这些组件作为Avalon Master的组件在SRAM上写入图像数据。
使用自定义指令对MPEG音频进行解码
在使用NiosⅡ处理器和uClinux的环境中播放MPEG音频存在三个主要问题：处理器性能、FIFO的大小以及在uClinux中用于输出的设备驱动程序。
我们发现，100 MHz Nios Ⅱ处理器在CydoneⅡ芯片上对立体声128Kbps 44.1KHzMP3音频进行解码时会有性能损失。如果FIFO足够大，则可以在该系统中播放单声道音频，但CPU会一直分配用于播放音频的性能。
我们在Nios处理器上添加了使用自定义指令的64位乘法器以实现64位乘法计算；这种运算方法在Libmad库中经常用到。播放的性能提升了大约2.5倍，用于计算的时钟使用率有所降低。
还有其它一些原因使音频播放质量不佳。首先是采样率不好，其次是缓冲区大小不足，最后是多任务处理环境。音频将参考使用17MHz的时钟。