Search code examples
memoryfpga

Sending 256 bits via spi from MCU through FPGA to the DUT

I have designed a program that receives 32 bits from MCU (with SPI protocol) and the FPGA gets these 32 bits and stores them in a register(32 bits) then sends them to the DUT.

Now, I am wondering, do we have any limitations when we use registers????

For example, now I need to send and receive 256 bits of data between the MCU and the FPGA (By SPI protocol).

Can I simply save them in a register with a length of 256?? or should I divide this by 256 and save them in different registers??

Also, is it always need to be the multiplication of 32,64,128......??? or can I only receive for example 40 bits from the MCU ???.

So mainly, I want to know what kind of limitation we have when we receive data and store them in FPGA via registers.

Thank you in advance.

Solution

  • The SPI protocol commonly works with 8-bit values, but it is not limited in general. So, yes, you can send and receive values of 256 bits width.

    However, specific implementations in hardware or software put additional limits on the width. Common SPI hardware blocks in MCU use specific word width, for example 8 bits.

    In that case you can transfer multiple words to transfer 256 bits. The synchronization could be done via the select signal, for example.

    If you have a width that is not an integer multiple of the transferred word, you can transfer more and ignore the padding bits. For example, if your MCU's SPI hardware can only transfer 32-bit words and your requirement is 40 bits, transfer 2 words of 32 bits and ignore 24 of them. Which bits are ignored is up to your specification.

    How you realize this in your FPGA, it also up to you, and it depends on your "protocol layer" above SPI. If your DUT needs to be accessed with 256 bits, the FPGA will use 256 bit registers. But whether you organize them in multiple registers of the transferred width or as a single register, is your choice.

    Bottom line: The SPI protocol is a quite simple protocol, mainly a clocked synchronous serial transfer with select lines, potentially full-duplex. You can use it with great freedom to build your own protocol on top of it.