Improving FPGA code

[brokenpotatoes]

Hey to start with i would like to say that you did great work making this project. And congrats on getting featured in Hackaday. I would like to defend your choice of using an FPGA as they're great for doing things like reducing the number of pins. I would implement the code a little bit differently. I decided to hop on EDAPlayground to make a quick prototype of what i had in mind. I made an SPI "Multiplexer" it should allow to have slow slaves communicate with a fast master. It basically shifts data in from the slaves like a shift register. The biggest advantage of that would be the possibility of running the SPI to the FPGA at the maximum speed of rp2040(around 60mhz) and communicate with slaves at 1/32rd of that frequency. I made a very crude implementation along with a testbench here: https://edaplayground.com/x/aRCP. I made a testbench for 2 slaves but it the number of slaves is adjustable using a constant. It has one quirk tho the first [Insert the number of slaves here] bits received are junk. Adapting it to your board shouldn't be a problem. It would require sabotaging the FPGA_CDONE and replacing it with a new SPI clock line cause the IMU_CLK would run at 1/32 of the new SPI clock. I didn't file an issue since i wanna probe if you're interested in that idea. If you're confused about what this thing is doing i can send you my notes with annotated waveforms. If you're interested i can make some better testbenches and try to make something that could be tested on a real board. Cheers from France, Bogdan

[will127534]

Thank you so much on the kind words!

FPGA on this project for me is mostly to mitigate the risk, the reason being that this board is going straight to PCBA services and I want as much flexibility as I can so later on I have the options to decide even after the board is back. So I will say that is why some might ask why not using it on a MCU, because they think (rightfully so) that the functional aspect for this FPGA in this project can be replaced with MCU directly.

For the FPGA code let me explain my current way of doing this:
Reading IMU with MCU -> FPGA capture the register read cmd and load the data to its internal memory -> MCU request the data from FPGA.

It might be easier to read the code in https://github.com/will127534/IMU_Array/blob/main/MicroPythonCode/ICM42688P.py

So you can see that it is somewhat similar with your route, I think the performance bottleneck and difficulty is on the async SPI core. After I move the clock from ICE40 internal 48Mhz osc to async SPI core, the maximum reliable speed I can get from FPGA is about 20Mhz, IMUs on the other hand can get all the way to 24Mhz.

You can also checkout the waveform under /images, I didn't attach those to any readme in the repo so that might not be noticable.