Building Sample under 2020.2+

[wxsatman]

litefury2021mcs.zip Some of you out there may have built the sample in this GIT under Vivado 2020.2 which has been the latest version for past 6 months and then tested it to find that the XDMA driver/module refused to load properly, specifically it loaded but could not find the needed Config BAR and therefore did not create any device nodes and was useless.

I recently wrote RHS Research about this to find that XDMA under Vivado 2020.2 was a known issue. Indeed upon doing a bit of research it appears that the Vivado 2020.2 XDMA IP supplied by Xilinx (RHS research has nothing to do with this) is simply broken at least for all 7 series devices with includes the xc7a100t used on the Lite Fury.

The XDMA IP seems fine up through Vivado 2020.1 and I did indeed create and build an operational project using XDMA for the Lite Fury under 2019.2 that I happened to have on my system. However the provided sample in this GIT is for 2020.1 and refused to build properly under the older 2019.2.

To date it appears that Xilinx has not fixed the XDMA IP for Vivado 2020.2 although they seem to acknowledge back in March in the Xilinx way that there is a problem!

However Vivado 2021.1 was just released so I installed it (Ubuntu 20.04 is officially supported) and attempted to build the sample under it.

The build mostly went fine. Make sure you upgrade the IP and allow Vivado to use the new directory structure it will ask about these when open your clone of this GIT project. The only real issue I had is upon initial build it had 15 critical warnings this was because it was very confused about the GTP transceiver placement for PCIe that is specialized for the Lite/Nite Fury!

This is a complex issue that mostly involves the order it processes two different constraint files. If it is processing in the intended order you should end up with 3 critical warnings and the GTP mapping should be X0Y7 on pipe_lane[3], X0Y6 on pipe_lane[0], X0Y5 on pipe_lane[2], and X0Y4 on pipe_lane[1]. The critical warnings should indicate the above mapping, read these carefully.

Anyway upon initial build it was using the constraints in wrong order resulting in 15 critical warnings. I found (at least in my case) that if you edit the XDMA IP in block diagram (I changed the PCI ID from 0x7011 to 0x7012) and save block design. Then rebuild the XDMA IP and then the whole project (takes a while) and I ended up with the proper 3 critical warnings and the proper GTP mapping. However I will critically (to Xilinx) warn that I am not sure if this trick is consistent or why it works!

Anyway upon successful build I put the MCS file into flash on a Lite Fury power cycled the victim computer and tested with “Xilinx XDMA Reference Driver xdma v2020.1.8” which as of July 7th is the latest XDMA driver from Xilinx. At least the key DMA transfers to the Lite Fury RAM seemed to work fine. I did not test the other peripherals in the sample project build but will next week and report if there are issues.

I have attached the mcs file I built with Vivado 2021.1 for Lite Fury once programmed AND power cycled lspci should show Lite Fury as 10EE:7012.

[RHSResearchLLC]

Wow thanks for thi! @wxsatman !

[RHSResearchLLC]

Latest release now updated for Vivado 2022.1, which seems to work