Support for the RHS Research LiteFury

[teknoman117]

LiteFury is an Artix-7 development board in the M.2 form factor for PCIe accelerator development. It's similar to the Aller but with an xc7a100t rather than an xc7a200t and no TPM module.

product site: https://rhsresearch.com/collections/rhs-public/products/litefury

As far as testing goes, I've booted into the LiteX bios via a PCIe wishbone bridge with a crossover uart. mem_test passes and the console works.

Caveats: The PCIe data width is set at 64 bits because when set to 128 bits every computer I put the board in either fails to POST (custom i7-5820k system (UEFI)) or hangs when the OS tries to load (Dell Optiplex 980 w/ i7-860 (BIOS)). I don't know where to begin debugging this. I don't have any cables for the IO breakouts on this development board so I can't setup a UART at this time. The LedChaser on the user leds works though.

I also don't have the programming cable set up because I haven't figured out how to flash the FPGA via OpenOCD with the Xilinx Platform Cable USB-II (it only supports JTAG programming until a qspi litex module is available)

[enjoy-digital]

Thanks @teknoman117, that's good to see you managed to do the port and test it successfully. The LiteFury is in fact a XC7A100T variant of the NiteFury that is also very similar to the Acorn CLE 215+ that we are already supporting:

• https://github.com/litex-hub/litex-boards/blob/master/litex_boards/platforms/acorn_cle_215.py
• https://github.com/litex-hub/litex-boards/blob/master/litex_boards/targets/acorn_cle_215.py

Happy to merge the LiteFury support, i'll just make sure in the future that share common things between Acorn CLE and Lite/NiteFury support. I could help setting up the PCIe data_width to 128-bit if you need more bandwidth. I'll do some tests on the Acorn in the next days.

[teknoman117]

As part of getting this working I bumped into what I thought might be a bug in RemoteClient in litex_client regarding base addresses, but I'm not quite sure. If I understand correctly, by default the PCIe wishbone bridge in add_pcie only maps the CSR region of the SoC memory map to be visible on BAR0. As the default address for the CSR region is 0x8200_0000, so address 0 of the PCIe BAR maps to 0x8200_0000. This is also reflected in the csr.csv file which is generated, as all of the CSR addresses are in that range. However, in RemoteClient, it adds the provided base address to whatever it finds in the CSR file, so if you say the base address is 0x8200_0000, it results in it trying to access 0x1_0400_0000 which throws an out-of-range exception since it's trying to decode the address into a 32 bit unsigned number. I flipped the operations around to subtract the base address and everything started working (I needed to do this to access the crossover uart).

[teknoman117]

Also, on the note of more bandwidth - At this point I just wanted to make sure I didn't do anything wrong. It would be nice to be able to maximize the PCIe bandwidth though. The Xilinx XDMA (proprietary) block uses a 128 bit AXI bus @ 125 MHz (16 bytes * 125 MHz = 2 GB/s) (or 64 bit @ 250 MHz) which matches the maximum data rate of PCIe 2 x4 (20 GT/s * 8/10b = 2 GB/s)

[enjoy-digital]

@teknoman117: thanks for the feedback, would you mind creating an issue with the issue you have with the PCIe wishbone bridge and the exact steps to reproduce the issue? I'll have a closer look.

Otherwise the the PCIe bandwidth, the maximum theorical bandwidth of PCIe Gen2 X4 is 16GBps (20GBps - the 8B10B encoding) without taking into account the protocol overhead. On several design I get around ~13-14GBps with LitePCIe Gen2 X4 but that's possible you'll get less with the current settings of the LiteX-Boards targets that are just enabling PCIe and try to reduce resource usage. I'll post some example code to increase the bandwidth.