一种ARM+DSP协作架构的FPGA验证实现

3 体系架构的调试

3.1 FPGA的选取

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.3 FPGA调试的原则

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.5 Demo演示速度的调整

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



从以上分析可见，ARM在整个设计中所起的主要作用是控制图像的输入输出，以及循环控制DSP Core的运行停止等状态；DSP Core的主要作用是处理运算应用程序，计算小目标识别程序。这样既分工又合作，能够充分发挥ARM的控制功能以及DSP Core的数字运算处理功能。

与此同时，由于ARM在整个设计当中主要起到一些辅助的控制作用，ARM922T的一些扩展DSP运算功能没有用到，如果综合考虑到成本和性价比等因素，可以考虑采用ARM7硬核、NIOS 或其他形式的软核替代。