一款基于DSP内核处理器的FPGA验证实现设计_技术

ARM通用CPU及其开发平台，是近年来较为流行的开发平台之一，而由ARM+DSP的双核体系结构，更有其独特的功能特点：由ARM完成整个体系的控制和流程 *** 作，由DSP完成具体的算法和计算处理。这样，不但可以充分地发挥ARM方便的控制优势，同时又能最大限度地发挥DSP的计算功能。这在业界已逐渐成为一种趋势。

本文的FPGA的Demo验证，是在基于一款DSP内核处理器的研发基础上，对其功能进行验证的一个小目标识别算法的实现。考虑到软件环境仿真的速度以及仿真模型的局限性，用FPGA进行硬件协同验证。这样，既能够保证仿真的真实性，又能够快速发现实际问题，减少不必要的流片次数，加快开发的进程，这对于一个大规模的SoC设计，已经成为不可或缺的手段之一，而且对节约成本也有很大好处。

1 系统体系结构

双核系统的体系结构如图1所示。

1.1 内嵌ARM内核的EPXA1芯片及其特点

图1中，包含ARM922T内核的开发平台选用的是Altera公司的excalibar系列，本验证实现选用的型号是EPXA1。EPXA1是一款带有100万门可重配置PLD的ARM Core+PLD体系结构，可以通过quartus II软件工具来灵活配置ARM Core同外部的端口连接，最大时钟频率能够达到200MHz。EPXA1的高度集成化，不仅大大加快了ARM与片内各种资源的通讯速度，而且减小了硬件电路的复杂性、体积和功耗，真正实现了SOPC［1］。

1.2 FPGA硬件平台及其特点

对于一个具体项目，FPGA芯片的选取要根据实际需求和特点来具体考虑。一般应从逻辑资源需求、易扩展能力、信号质量以及成本等因素来考虑。如图1所示，本次设计采用的两片FPGA分别为Xilinx公司的FPGA X3S5000和X2V6000，其容量分别为500万门和600万门。选用这两块芯片正是基于逻辑资源需求的考虑。FPGA X2V6000面向高端应用，存储资源更多，功能更强大，适用于性能要求较高的DSP内核，但其成本相对也较高；而FPGA X3S5000成本较低，适用于一般性能要求的模块。两片FPGA都具备三个扩展槽，可做接口扩展，同时也能作为调试测试点用。

1.3 双核体系结构设计特点

具体来讲，整个体系结构是指通过人为设计电路图，外部选用不同的FPGA器件来下载生成特定功能的外部硬件电路，在电路图上对应相应的端口标号；同时，ARM Core可以通过quartus II工具方便地连接不同的端口标号，编译运行生成相应的配置文件；ARM的启动代码中用以上的的配置文件信息来配置PLD，从而实现ARM同外部硬件电路即两片FPGA的连接［3］。FPGA X3S5000中下载固化AHBC硬件电路以及外部SRAM Memory，而FPGA X2V6000中下载固化DSP Core以及支持AMBA协议的Wrapper。

这种体系结构能够充分利用硬件资源，合理的版图位置方便了ARM和DSP对外部SRAM的访问，同时可快捷地实现ARM的控制功能，而且预留的扩展槽能够较为方便地进行功能扩展和调试。DSP Core的Wrapper能够快速响应ARM的控制请求，调动DSP Core进入不同的工作状态。

2 系统工作流程及特点

系统工作流程图如图2所示，介绍如下。

2.1 ARM负责准备阶段

ARM从Flash中运行启动代码，通过配置PLD来连接FPGA X3S5000中的AHBC，目的在于ARM通过AHBC同FPGA X2V6000中的DSP Core进行交互。

代码唤醒外部DMA通过以太网口从PC机端搬运第一帧待处理的图像数据，放到双核公用的外部SRAM memory既定的地址段中。然后，ARM Core通过AHBC控制FPGA X2V6000中的DSP Core。

这里需要说明两点：

（1） FPGA开发板的的图像传输是通过专门配置的带有LXT972芯片的以太网口与PC机的以太网口进行交互，如图3所示。图3左边的以太网子板即图1中的Ethernet模块。

（2） DSP Core顶层的wrapper是支持AMBA协议的TOP Module，其中包括一个Debug Sub-Module。ARM就是通过读写Debug Sub-Module的控制寄存器来控制DSP Core的启动、停止等工作状态的。所以说，Debug Sub-Module是整个FPGA工程最为关键的部件之一，它直接关系到ARM和DSP之间的交互。本项目中，利用Debug Sub-Module实现对DSP Core的复位、启动、暂停、断点设置、单步运行、读写内部SRAM、读DSP Core寄存器等一系列功能，大大方便了调试工作，同时也非常便捷地实现了ARM和DSP的交互运行。

2.2 DSP运行阶段

ARM写控制寄存器使DSP Core复位，并把小目标识别的程序代码写入DSP内部的SRAM0中等待DSP启动运行，由ARM控制DSP Core运行起来。DSP Core运行完程序之后，会在外部SRAM的一个地址上返回一个标志数（0x00ff00ff），同时进入idle状态，完全释放对AHBC的 *** 作。每隔一段时间，ARM检查一下相应地址上的这个标志数，如果没有，则表示程序还未运行完，ARM继续检查；如果有，则表示程序已经运行完毕，ARM将进入下一步 *** 作。

选用这种流程有两个特点：（1）ARM完全实现了控制和辅助的作用，而运行部分则完全由DSP负责，各自分工明确。（2）ARM和DSP实现了很好的交互，严谨地控制了流程的运行步骤。

2.3 ARM控制停止返回

ARM通过写控制寄存器把DSP Core停下来，从外部SRAM的既定地址段中取出DSP Core运行完所返回的小目标的坐标信息，并通过以太网口返回到PC机端，在显示界面的此帧图像上显示出小目标。图4为其中一帧图像的处理结果显示。

ARM擦除DSP Core运行完毕的标志数，同时判断当前处理完的图像是否为最后一帧，如果不是，则流程跳回DMA搬运步骤去执行下一帧图像，同时加上必要的控制，避免写程序的重复执行；如果是，则结束整个程序运行。这样循环下去，直到所有图像序列处理完毕。

这个过程充分显示了ARM在控制流程的判断跳转方面所起到的主要作用。由ARM的平台来实现对整个视频序列的最终处理控制过程，显得非常清晰便捷。

3 体系架构的调试

3.1FPGA的选取

FPGA的选取一定要合适（这里主要针对容量而言）。以本开发过程为例， Xilinx的两片FPGA（X2V6000和X3S5000）的容量分别为600万门和500万门左右，而项目的硬件代码容量却稍微超出了这个范围，所以不得不对一些模块作精简和舍弃。即便如此，两片FPGA的利用率都已大于90%。

一般来说，FPGA的利用率达到70%或多一些是比较好的，太高的利用率反而容易造成板子的不稳定。本开发过程就有一些不稳定因素，例如，因一些数据线、地址线的个别位传输值不正确，需要花大量的精力才能追查出这些存在问题的线路，然后更换Bonding连接，选用其他的通路。同时，所造成的不稳定因素也会影响下载代码的运行速度。目前经过Xilinx的软件工具ISE综合出来的FPGA可下载代码受时序约束，所能达到的速度上限为25MHz时钟频率。

容量大的FPGA的成本同样也会比较高，所以在研发需要和成本之间必须找到一个比较好的平衡点，这在整个电路设计阶段就要预测得比较好，但这不太容易做到，需要经验的积累。

3.2观测点的预留

开发板在设计电路图阶段，一定要预留出足够的观测点。这一点非常重要。因为：在后来的调试过程中，当出现问题时需要追查线路，而目前的FPGA调试软件还不成熟，并不像RTL代码前端仿真那样方便，能够把所有的信号都输出到屏幕上观看，而且FPGA调试时使用的逻辑分析仪只能够测量观测点的信号波形，如果观测点不够的话，当出现逻辑错误时，根本没办法追查下去，找不到问题的所在，或者需要做相当繁琐的重复工作，才能把估计存在问题的线路节点信号连（Bonding）到仅有的观测点上。如果经排查，估计得不正确或者需要进一步拉出更多的其他信号时，又需要重新花时间将节点新信号连到观测点。这样，会耗费非常多的时间和精力。因为对每一次新的节点生成一版新的FPGA下载代码都很烦琐。

所以，从电路的设计之初，预留出足够的观测点，尽量将更多的节点信号连到观测点上。这样将会极大地方便调试工作，加快整个研发进程。

3.3FPGA调试的原则

FPGA的调试应该按照由简入繁的步骤进行。这样可以方便研发人员快速地熟悉板子，并且容易定位问题的所在。

由于整个ARM+DSP体系结构是由ARM加上两块FPGA共同工作，相对比较复杂，相互之间交互性比较多。所以，在调试整个程序之前，可以先通过另外的小程序和硬件结构分别调通ARM对两片FPGA的交互；然后，再用较为简单的功能模块调试好三块片子的简单交互功能；最后，把整个大程序应用在上面进行尝试。这样一步步下来，出现问题时，就比较容易发现问题所在，方便调试。

例如，可以先不考虑FPGA X2V6000，单独调试ARM通过FPGA X3S5000中的AHBC对外部SRAM读写的控制，成功之后，再将FPGA X2V6000考虑进去，但先不考虑Debug模块对DSP的控制，单独将Debug模块提取出来，下载到FPGA X2V6000当中；然后再调试ARM通过FPGA X3S5000中的AHBC对于FPGA X2V6000当中的Debug模块的控制寄存器的读写情况等。

3.4软硬件协同验证

软硬件协同验证是较好的验证方式（或调试方式），二者都是为了保证系统功能和结构正确的有效手段。在整个FPGA系统实现过程中，非常有必要结合前端软件仿真波形来参照调试系统各个环节的功能运行情况，这样可以大大简化研发进程，有效地缩短调试周期。可以说，如果不结合前端软件仿真波形来协同验证的话，要想实现一个较为复杂的体系结构是非常困难的。

一般而言，对于这样一个较为复杂的体系结构需要先进行前端RTL代码的软件仿真，因为前端仿真对于纠正RTL级代码以及功能方面的错误是非常方便的，而且它所需要的验证周期和纠错难度比硬件的FPGA验证要有利得多。但是FPGA硬件验证，其真实性又是非常可靠的。所以验证波形完全调试通过之后，可以非常有效地指导FPGA的实现。当FPGA在调试某项功能时出现了问题，可以通过逻辑分析仪将可疑端口节点出来的观测点波形导出来对照软件仿真波形来查找问题，这是一种非常有效的手段。

3.5Demo演示速度的调整

目前，开发板选用的晶振频率为24MHz，稳定的演示版本速度能够达到28帧/秒，为人眼所能接受的连续视频速度，效果已经相当好。这是经过了各种调试才达到的效果。主要原因在于考虑比较周全：DMA在传输图像序列的时候，所用到的FIFO在设计之初就考虑到了FPGA的容量和利用率，认识到其容量有限，在现有的FIFO容量下，要想调整到一个DMA与PC机双方网口传输速度的精确状态不太容易，如果运行速度太快，交互同步不准确，就会有丢包的现象发生；如果为了更方便的调试和达到更好的速度性能，可以选用更大容量的FPGA，设计更大容量的FIFO，这样每一次图像传输就可以传送更多的图像数据，减少DMA搬运的次数，传输双方的交互过程较为容易控制。表1给出了从开始演示速度不理想到较为理想所做的调整过程。从表1中可以看出，单独调整晶振频率，速度提升并不明显。这说明了速度瓶颈不在硬件代码性能上，关键在于演示界面的软件代码、ARM的Cache打开与否以及图像搬运的速度三方面。同时还可以看出Cache的打开对于速度影响很大，说明ARM的取指速度受到影响。目前ARM的运行指令是放在Flash中，如果改成从SRAM中取指，估计效果会更加理想。