--- Quote Start ---
Hey, I'm working on a system that uses an SPI interface to set various config data (registers) to affect modes of the system, but uses a number of parallel instances of a module to do the actual processing. I'm trying to decide a good design strategy for efficiently getting data to all the modules from the single SPI protocol handlers.
So far it seems like using a lot of small dual port RAMs would be best, with one port always controlled by the SPI module and the other port connected to one of processing modules. But all this interconnecting seems to be quite inefficient and hard to set up when there are a lot of processing modules.
Is there a design pattern for doing stuff like this that is more efficient? This must be a common challenge but so far I haven't come across any suggestions for how to do it cleanly.
Any ideas would be greatly appreciated!
--- Quote End ---
In software interfacing most designers use one module (usually named ctrl_status_registers). software writes/reads to specific addresses of a a set of registers. Fpga reads/writes to same space. I think that applies to your case as well. Registers (rather than memory block is preferred as it allows parallel addressing to any register. You need to document the address space, whether it is rd/wr from both fpga perspective and software perspective and describe individual bit meanings between them.
Some registers will be writen by fpga to be read by software, other the reverse. some may be rd/clear and each should have default value documented.
Honored Contributor
