紫光官方其实主推的是在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的逻辑设计来适配原来的驱动。