JColvin

Is the RPi5 suitable for paring with an FPGA?

You may have noticed that the latest generation of RPi5 uses an asic, referred to
as a Southbridge, for IO. All of the IO, Ethernet, USB connectivity etc. are implemented
in the RP1 Southbridge whic is connected to the BCM2712 processor though a 4-lane PCIe
Gen2 interface. This makes it substantially different from the RPi4 or RPi3
boards. So you might be wondering if the new version can be connected to an FPGA. That
is a question that I decided to investigate for myself.

The RPi5 has a single lane PCIe Gen2 ( perhaps even a Gen 3 ) header on it that someone
will eventually create an FPGA add-on board for. Most people will want to use that interface
as a higher performance alternative to the SD card. But the RPi3 and RPi4 could always
connect to an FPGA board using a USB 2.0 bridge device like the FT2232H supporting synchronous
245 mode operation. I've done this and performance for the RPi3 and RPi4 is OK for moving
small blocks of data between the processor and the FPGA. As the amount of data being transported
increases the performance drops off considerably, unlike an x86_64 processor.

For my experiments I'm using a Genesy2 board with a FMC_UMFT601BX mezzanine board. This
allows the HDL application in the FPGA to act as a USB 3.0 endpoint with a peak data rate
of 400 MiB/s. The design of the Genesys2 application used for my tests is pretty straight-forward.
All data uploaded to the FPGA from the USB Host gets stored in DDR3 that functions as a very
deep FIFO. The USB Host can retrieve the upload data once it's been downloaded. The HDL expects
n sectors (4096 bytes/sector), to be uploaded and then downloaded. The DDR3 interface in combination
with sufficient FIFO storage can accept up to 1 GB of upload data and return it without delays.
In addition to the simple up/down data scheme the HDL has performance timers to timestamp the
important events in the tests. These are: the time that the first 32-bit word is uploaded, the
time that the last 32-bit word is uploaded; and the same events for download. Since it's a
free-running counter, I can calculate the total time that has elapsed between reading the
first 32-bit upload word from the FT601 FIFO to the last 32-bit word written to the FT601 FIFO.
This provide a much more accurate picture of the USB Host OS/Software behavior and performance
than typical software timing methods provide. It must be noted that from the perspective of the
USB Host data rate performance is more complex than just time spent in the driver filling or
emptying the FT601 FIFOs. I have my own Software application that is mostly identical for Windows
and Linux platforms. The D3XX drivers for these platforms are not the same however.

The FT601 is not the only way to connect an FPGA to the RPi5 via USB 3.0. I also tested the
XEM7320 with the Infineon FX3 bridge.

For the FT601 Test I used this setup:
- Genesys2 FPGA board
- RPi5 8 GB w/ heatsink/fan
- Raspios Bookworm 64-bit
- libftd3xx-linux-arm-v8-1.0.5
- FT601_245.cpp Host Application
- G2_FT601_TESTER.vhd

In FT601_245.cpp I do software elapsed time calculation. The test runs in this manner:
clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &start);
ftStatus = FT_WritePipe(ftHandle, 0x02, pBufOut, SectorSize*up_sectors, &BytesWritten, NULL);
clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &start);
ftStatus = FT_ReadPipe(ftHandle, 0x82, pBufIn,RxBytes,&BytesReceived, NULL);
clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &stop);

So, there is some processing between the upload and download calls to the D3XX driver.


Without further ado, here is a sampling of results for the Genesys2/FT601/RPi5 testing

Test Upload Average Download Average
Length Time Upload Time Download
Bytes Data Rate Data Rate
------- ------------ --------- ----------- ---------
16384 42.09 us 389 MiB/s 44.68 us 367 MiB/s
65536 170.66 us 384 MiB/s 196.35 us 334 MiB/s
262144 682.51 us 384 MiB/s 848.43 us 309 MiB/s
1048576 2.73021 ms 384 MiB/s 3.37639 ms 311 MiB/s
4194304 10.92282 ms 384 MiB/s 12.13967 ms 346 MiB/s
8388608 21.84317 ms 384 MiB/s 24.26676 ms 346 MiB/s

This is rather surprising that the upload data rate is consistently around 380+ MiB/s
for blocks of data ranging from 16 KB to 8 MB. Download rates were less consistent from
run to run but still near 350 MiB/s. For USB 3.0 the RP1 Southbridge performance is
outstanding. I believe that the low rates in 310 MiB/s range were outliers, but within
the range that one should expect. BTW the performance with the same setup, but using my
Ubuntu 22.04 i7-13700K box was dismal; about 44 MiB/s up and down for 1 MB test.

I also tested the RPi5 using this setup:
- XEM7320
- RPi5 8 GB w/ heatsink/fan
- Raspios Bookworm 32-bit
- FrontPanel-Raspbian10-armv7l-5.3.0
- EthAppliance.cpp Host Application
- EthAppliance_1.vhd
- Genesys2 configured with Genesys2_Eth_DUT.vhd ( Ethernet echo application )

A few months ago Opal Kelly had posted a 32-bit beta ARM driver for FrontPanel; it's
since disappeared from their download website.

I didn't try to do do a performance test with this setup. All I wanted to know was
if I could run the application on the RPi5 and see if it worked as well as on my
x86_64 Windows and Linux platforms. The application streams TX Ethernet 1 GbE packets
through a SYZYGY Ethernet pod. It stores RX packets simultaneously into a DDR3 buffer
that can be read later. I was able to run the HDL and software applications with
performance that was equal to that on x86_64 Win10 and Ubuntu 22.04 platform; that is
sustained 120+ MiB/s full-duplex Ethernet.

So, do I think that an RPi5-USB 3.0 FPGA could be interesting? Absolutely I do! The RPi5
is an impressive bit of gear with some interesting possibilities.

Hi @sand,
You'll be wanting FDwfDigitalIOOutputEnableSet and FDwfDigitalIOOutputSet which are defined in the Digital IO section (section 8) of the WaveForms SDK Reference Manual.
DigitalIO.py in the samples folder uses these two functions, enabling DIO 0 to 7 as outputs and then setting IO pins 2 and 5 as logic high.
Let me know if you have any questions (or if I misunderstood what you are wanting to do).
Thanks,
JColvin

Hi @Anthocyanina,
Thank you for the feedback; you have been heard. I will be sure to communicate this to the team for future T&M devices.
Please let me know if you have any additional feedback or questions.
Thanks,
JColvin

The female host Pmod connector on the Basys 3 (and other Digilent products) is a Sullins PPTC062LJBN-RC, with 100 mil pitch between each of the pins.
Thanks,
JColvin

Hi @jmag999,
The pins themselves are 6 mm in length, total depth from outside the plastic shell to the plastic housing on the 2x15 connector is 8.8 mm.
Let me know if you have any questions.
Thanks,
JColvin

Hi @Mohamed Kamal,
In general, you only need to calibrate the Analog Discovery device once; it will retain and use the user-determined calibration each time until you choose to manually re-calibrate it or load the factory calibration from the WaveForms Device Manager.
There is no specific timeframe for how often you should calibrate your Analog Discovery device. Personally, I only recalibrate my devices when my hardware setup has drastically changed or feel inspired to recalibrate, but when those situations occur is completely arbitrary.
Otherwise, I don't believe the calibration process is supported within the SDK API.
Let me know if you have any questions.
Thanks,
JColvin

Hi @Norm-12,
Digilent did not create the Audio Analyzer Suite; from my understanding this was created by a third party outside of the Digilent Forum:
The WaveForms software has both a Network and Spectrum Analyzer which should have most if not all of what you are looking for. The WaveForms Help tab has extensive documentation on each of the instruments.
Let me know if you have any questions.
Thanks,
JColvin

Hi @Charlotte123,
Yes, the WaveForms SDK is compatible with all of Digilent's Test and Measurement devices.
Thanks,
JColvin

Hi @Mohamed Kamal,
There are a number of examples built into the WaveForms SDK that should help get you started:
Let me know if you have any questions.
Thanks,
JColvin

Hi @mvernengo,
What revision of the Zedboard do you have? Neither the Rev D nor the Rev F of the Zedboard that I have match the silkscreen image you posted with the Mode numbering (my two versions list the MIO numbers), though the jumper numbering (JP7..11) does match. My concern is that if the jumper numbering is identical that then the Mode[X] silkscreen labels would not readily line up with the orientation listed in Table 18 of the Zedboard User Guide that Avnet created here: https://digilent.com/reference/_media/reference/programmable-logic/zedboard/zedboard_ug.pdf.
Presuming the latter situation, your setup of Mode3 and Mode2 being set high would have the device boot from Quad SPI flash memory (which is based on Mode2 high, and both Mode1 and Mode0 low), which from my understanding is not loaded or prepared by default with the Out-Of-Box material. That would be loaded through the SD card image (Boot Modes 2 and 1 set to logic high), which you can find in the Zedboard Resource Center here: https://digilent.com/reference/programmable-logic/zedboard/start#additional_resources.
I would also put Mode3 to logic low to set the device to Cascaded JTAG rather than Independent JTAG so that you can more readily access the device as per Table 22 in above linked user guide.
As for the serial terminal not responding in readable characters, my gut reaction would be to double check the baud rate (by default Zynq designs use 115200 baud, but Tera Term uses 9600 baud by default).
Let me know what you find out.
Thanks,
JColvin

Hi @thirtyy,
My understanding is that as per the Zybo Z7 Reference Manual, https://digilent.com/reference/programmable-logic/zybo-z7/reference-manual#pcam_port, Digilent implemented the MIPI connector based the guidelines described in this Xilinx Application note: https://docs.xilinx.com/v/u/en-US/xapp894-d-phy-solutions.
I have reached out to some engineers a bit more familiar with the hardware implementation for their insight into your query (though with the holiday timeframe, it may be awhile till I hear back).
Thanks,
JColvin

Hello,
It was pointed out to me that the XAPP894 mentions that if external termination is used (which the Zybo Z7 uses the style shown in Figure 11), the common mode voltage can drop to 100 mV, which is what you are measuring.
Let me know if you have any questions.
Thanks,
JColvin

While it could be argued that this violates the rules as written, I'll allow it. 😋

The pins are 0.64 mm square as cnegrea correctly indicated. You can find some more details in this thread:
I'll work on getting this detail into the Cmod A7 Resource Center for easier future reference.
Thanks,
JColvin

Hi @jfm,
When you connect to the micro USB port to your laptop, is the jumper that is next to the barrel jack set to the USB setting side (as opposed to the external power side)? The power good LED next to that same jumper should light up. If the jumper settings are correct and the LED doesn't light up, I would first recommend trying a different USB cable (especially if when you connect to your computer you are not able to find evidence of the connection in the Device Manager).
It is also worth noting that the Cora Z7 does not have any flash memory, so there is not an out-of-box demo that will load on power-up as there is not static memory to load from (presuming I remember correctly that the Cora Z7 does not ship with an SD card).
If the power LED is lighting up, you can test the Cora Z7's functionality though the Example Projects available on its Resource Center: https://digilent.com/reference/programmable-logic/cora-z7/start#example_projects.
Let me know if you have any questions.
Thanks,
JColvin

Hi @magnitudephase,
This post may be of interest to you:
From my understanding, the ADP3450 will always be at, or beyond, feature parity with the Analog Discovery 3 due to the larger Zynq device present within the ADP3450. There is not any hardware features unique to the AD3 that the ADP3450 does not have access to or won't be able to implement within its own FPGA hardware (unless you count the USB C connector on the AD3, but I would not count it as it operates at USB 2.0 speeds).
Let me know if you have any questions.
Thanks,
JColvin
P.S. Technically, the FIR filter was added to the ADP3x50 and device loopback in the 3.19.30 beta version, with IIR filter added even earlier in 3.19.21.
 

Hi @Anthocyanina,
Thank you for the feedback; I believe Attila is out of office at the moment to be give any further feedback, so I wanted to clarify that Digilent has seen the feedback.
With regards to displaying multiple traces on the same plot within Impedance, you can run an acquisition, click the green + button to "Add Trace as Reference", then re-set up your circuit to get different data and have the existing reference trace persist on the screen.

Thanks,
JColvin

Documenting that this was responded to in the other post here:
.

Hi @Anthocyanina,
Thank you for the feedback; I believe Attila is out of office at the moment to be give any further feedback, so I wanted to clarify that Digilent has seen the feedback.
With regards to displaying multiple traces on the same plot within Impedance, you can run an acquisition, click the green + button to "Add Trace as Reference", then re-set up your circuit to get different data and have the existing reference trace persist on the screen.

Thanks,
JColvin

Hi @Abhijan,
The first thing I would be checking with the 1:10 ratio would be the attenuation setting on the BNC probe. It's also worth ensuring that your two devices share the same ground connection.
Let me know if you my guess is not accurate to your situation.
Thanks,
JColvin

The tools will recognize any of the Digilent JTAG cables, whether connected to a target device or not.

As to whether you can program any Xilinx device using the Adept tools depends.
- Make sure that the cable and the JTAG interface are electrically compatible
- Make sure that the pin assignments are compatible. I've resorted to making adapters to connect HSx cables to non-compatible JTAG headers that work
- The Adept tools don't support every device ID that spans every device that Xilinx makes. Fortunately, the Adept tools are written so that you can add new device support by modifying a text file. I've also done this for using the Windows Adept Utility to program FPGA devices that Digilent doesn't support by default.

The cables, as do the asic modules that Digilent used to sell, work with any Xilinx device. It doesn't have to be a Digilent board.

When working with multiple targets I find the Adept Utility for Windows to be much easier to work with for configuration than Vivado Hardware Manager. Of course, if you want to use the ILA or VIO interface then you need to use Vivado Hardware Manager.

As far as I know, as long as you made the JTAG interface on your custom board to match the HS2 pinout, the Adept 2 should recognize the HS2 chip as the "hardware server" and you should be able to see your FPGA and configure it. I use the HS2 programmer to program boards with FPGA parts not from Digilent all the time.

Hi @vinod,
My understanding is that unless you are able to reduce your image size (Xilinx has some information on this here: https://docs.xilinx.com/r/en-US/ug1144-petalinux-tools-reference-guide/Managing-Image-Size), then the option is going to be to have the Zybo Z7-10 instead boot from an SD card. Xilinx has some information on how to do that here: https://docs.xilinx.com/r/en-US/ug1144-petalinux-tools-reference-guide/Booting-PetaLinux-Image-on-Hardware-with-an-SD-Card.
Once you have the needed images, you can put them on the SD card, insert it into the Zybo Z7-10, set jumper JP5 to SD instead of QSPI, and then power it on and connect it to a serial terminal of your choice.
Regarding your question of putting the BOOT.BIN in QSPI flash and the image.ub on the SD card, I do not think this is readily possible to do with how the bootloader finds the other files (or at least I am not able to find any information on how this partial boot from multiple locations might be done).
Thanks,
JColvin

Hi @john2022,
I have sent you a PM.
Thanks,
JColvin

Hey @JColvin,
Good to know about the V-, thank you. The Scope Channel 1 was grounded in error, I moved that channel around during troubleshooting and landed it incorrectly by a pin. I was connecting V+ to the red + rails on the breadboard. 
Thanks for your help, I will disconnect the ground from V -