What would you like to see tested on the Raspberry Pi 4?

Oh dear, spoke much too soon.

Got the write to fpga working first and it is much slower than expected, the problem is that there are two reads of the FPGA handshake signal per cycle and the Pi's read is horribly slow.

For a quick test I added four reads to each bus cycle like this:

volatile uint32_t d

volatile uint32_t *gpio_in = mapped read address of pi input register

d = *gpio_in;

d = *gpio_in;

d = *gpio_in;

d = *gpio_in;

These reads add 600 ns to each cycle, no significant jitter, so each read takes about 150ns.

All is not completely lost, but I shall have to almost give up on the full handshake.

Currently the Pi is the bus master, to send data it sets up the data and asserts MR, the FPGA responds to MR asserted by reading the data and asserting SACK, the Pi de-asserts MR and the FPGA de-asserts SACK and we are ready to go again. If Linux on the Pi goes off for a couple of seconds to something else, at any time in the bus cycle, it doesn't matter. But this scheme needs the Pi to read twice to check that the FPGA has seen the data and is read for some more. These two reads cost about 300ns, which is alkot when I want a complete bus cycle of 100ns.

Scheme 2 relies on the FPGA never to go off watch:

The Pi sets up the data and asserts MR (simultaneously), and repeats this n (n probably = 3, might be 4), then it puts the next data word on the bus and simultaneously clears MR, and repeats this for n times. This means that during a burst of data each word will be presented for at least n cycles, which is about 10ns * n. The FPGA looks for changes in MR and uses the data which precedes the change by one FPGA clock cycle (= exactly 10ns). If the Pi goes off to do other stuff in the middle of set of n - it doesn't matter. The FPGA isn't allowed to relax and must always be ready for data. I think this will allow me to send data from Pi to FPGA at an average rate close to 10 * n (it will be a bit less because the Pi doesn't always manage three or four output cycles at the full rate.)

When the FPGA must send data to the Pi we can't help at least one Pi read per bus cycle so that's 150ns gone - but it looks as if the Pi always takes 150ns - so I can try asserting MR, then reading after p more asserts, adjusting p until the reading s are never wrong. (There is a smart way to do this which some ADCs use - you need some extra bits in the data and adjust the delay (p in our case) until  the sequence of the extra bits is error free. I'll adjust p by hand !)

So - it's harder than I hoped and I'm adjusting my target to 20Mbyte/s Pi to FPGA and 10Mbyte/s FPGA to Pi.

MK

Episode 400: The Ultimate Raspberry Pi Stress Test

Load the sucker up with a RTL-SDR dongle and set the software sample rates to extremes and let me know how it makes out.

Sean

The USB-C port? :0

I think you can read what you need to about the USB-C port here.

Sorry, I was being being facetious.

- How about delidding the CPU to see how cool it can get with a bespoke heatsink/fan when clocked? (not even sure if this is possible)

- passively cooled vs. actively cooled pi4?

Benchmarking the Raspberry Pi 4 Model B , scroll down to about "Seriously, Keep this Cool and in a Case" - what would you like to see done differently?

> How about delidding the CPU to see how cool it can get with a bespoke heatsink/fan when clocked?

I'm not sure that can even be done safely...

Very good benchmark - Only additional thing would be seeing how well the PoE HAT cools the Rpi4.

This looks 'cool' too https://thepihut.com/products/raspberry-pi-water-cooling-kit 

Half Life 3 please

the 3dprinted case in this test has the fan on a side, the performance may be different than placing the cooler right on top of the heatsink. also the heatsink was one of those small ones that have been around from previous generations, for the pi4 i've seen some much much larger heatsinks.