You design communication protocols based on the particular requirements of your application. That's why there are no examples around - there are universal protocols like TCP/IP (or, just the IP part of it), but they exchange the "universal" for being generally inefficient for a given particular task. Fits all means fits none.
You should start with RPi/SPI communicating with STM32, use interrupt-driven communication in STM32, you will find examples for that in Cube. Move blocks of data to and from the RAM first. Then add communication to the FPGA, make a transparent bridge, with buffering the data. Try then adding a header to the data (one byte with some particular value, plus perhaps a couple of bytes indicating number of data bytes to follow), so that they can be distinguished that they go into/from the FPGA. Then add the I2C part.
500MHz and low consumption are mutually exclusive. The STM32H7 family is the highest performing amongst the STM32. I don't know how did you arrive at that 500MHz, but if you are sure you need that high operation frequency, you probably have to look into different solutions instead of using a microcontroller.
Maybe you could do things slightly differently - connect RPi to FPGA directly, make the "bridge" out of the FPGA, which would forward only data for I2C to a microcontroller which would then relay them through I2C. In that way, the bulk of the communication would go where it belongs - into the FPGA - and them microcontroller would handle the relatively algorithmically complex I2C. Any of the STM32 would then be able to cope with this, and it would be also a low-consumption solution in this part.
JW
