紫光官方其实主推的是在linux系统下开发驱动和上层软件,相应官方提供了在linux一个基于GTK+2.0的PCIE测试平台,该平台能够很好去操作官方生成的例程。需要特别注意的是,该linux系统必须是物理机,不能是虚拟机。开发使用linux系统,开发者也许可以接受,但是进一步开发提供给用户操作的软件,要考虑到用户层面的时候,无可厚非会必然选择Windows,所以在Windows开发适配的PICE驱动是最佳选择。
官方也提供了一个在Windows的驱动例程,该例程能够完成PCIE的DMA读写操作和PIO内存读写操作,但是该驱动并未完全适配IP生成的官方例程,官方提供另一份的FPGA的工程与之适配。有所不足的是,这次官方提供适配的FPGA工程并未完全公开,重要设计的Verilog文件加密了(提供适配的FPGA工程芯片型号为PG2L100H)。
驱动不匹配官方IP自带生成例程的原因,就是该驱动不能够与IP例程完成DMA握手(流程和指令不匹配),但是可以对BAR0进行PIO读写操作。
官方提供的Windows驱动的DMA操作流程如下:
但是生成IP自带的例程的DMA操作流程与之不同,IP自带例程的DMA读写流程是
(1)bar1 0x100:读写地址位宽+read/write+数据长度
(2)bar1 0x110:内存低32位地址
(3)bar1 0x120:内存高32位地址
由于流程和指令的不一致,导致了官方提供的Windows驱动未能和官方PCIE IP生成的例程DMA机制握手成功。此时,要让他们成功握手通信,两个选择,一是改FPGA端工程,二是改Windows驱动。对于刚入门的我,很明显是改驱动比改硬件简单和省时间。改驱动很简单,只有将上面的指令流程改成与IP生成例程相对应即可(特别注意这里不是说原来的驱动有问题,改动只是适配IP生成的FPGA端例程)。改动如下:
改完之后,重新生成驱动,这个编译生成我使用的是Visual Studio 2022,需要安装与版本对应的wdk库等,编译有问题基本都是环境没配置好(数字签名等等),对于软件老手都是家常便饭了,就不详细说了(毕竟我是做硬件的)。再之后,直接在bin目录进入Powershell/cmd。输入./pdma_rw.exe,打印信息可以帮助我们如何进行指令操作。
将datafile4K.bin 的1024byte数据传输给FPGA,再将FPGA的数据读回来写入datafile4K_recv.bin。
将datafile4K_recv.bin对比一下datafile4K.bin ,可以发现读回来的数据是正确的。
使用指令对BAR0进行读写,写入1234,读回来也是1234,write/read后面的0代表地址偏移量。
最后简单声明一下,更改驱动只是适配紫光IP生成的例程,把IP自带例程的DMA机制通信成功起来,当然也可以去更改IP生成例程DMA的逻辑设计来适配原来的驱动。