Does the SPI protocol specify how many clock pulses a master device should send to the slave?

Question

I'm trying to implement an SPI device in Verilog. I'm having a lot of problems for coordinating master and slave, since sometimes (with my current impl.) the SPI master device doesn't send enough clock pulses to the slave so it can finish its processing.

For instance, this can occur if the slave is implemented so that its state machine has more states, and it stops receiving clock pulses before it finishes completing its cycle.

I could modify my implementation to make these two devices to be coordinated in terms of clock pulses, however, this means that the master implementer needs to know the impl. details of the slave (and all the potential slaves). This doesn't seem right to me at all.

Does the SPI protocol specify exactly how many pulses the master must provide to the slave when sending, for instance, one byte? If not, how is that any SPI master device is compatible with any slave? Would it be ok to send a ton of pulses (e.g.: 64 pulses for 1 byte) to the slave just in case?

Answer 1

The SPI master is not responsible for making sure that the slave's internal state machine gets 'enough' clock pulses. All the master is responsible for is one clock pulse per bit transferred to or from the slave - that's it.

If your slave needs additional clocking then it's up to you to manage your implementation in a way which supports this - maybe you specify some minimum number of bytes must be transferred (even if some of them are 'dummy' bytes), or maybe you have to provide an external clock to the slave in addition to the SPI clock.

A well-behaved SPI slave should reset its SPI state machine when its slave-select input is deactivated so that whatever the master does in one round of comms doesn't necessarily break the next round due to something being in an incomplete state.

Answer 2

The answer to any question about the SPI protocol is: there is no SPI protocol! It's the simplest possible way to transfer serial data, essentially just a shift register. Have a look at a typical SPI module in an MCU, and you'll see the problems associated with the fact there isn't a standard (for example, which edge to capture).

You need a method to keep the SPI receiver receiving a local clock, and not rely on the SPI source providing a clock to do anything other than clock in serial data. You can use the shared SPI clock to transfer data, but use a local clock to maintain your state machine.

Answer 3

SPI is not a protocol in that sense which you mean.

It is only an interface to transfer bits automatically in serial fashion, most commonly in multiples of eight to transfer bytes between devices.

Sure, it is a protocol in the sense that all parties must agree how to send data, including things like clock phase to know on which edge the data is loaded in and what is the idle clock polarity.

And on top of that it is up to the devices to use a protocol of bits or bytes, to know what the bits and bytes mean.

Basically, if your SPI receiver needs certain amount of bits, then the SPI transmitter must transfer that amount of bits, no more and no less. It is up to you what those bits contain, and how your SPI receiver works if the correct amount of bits is not transmitted.

Answer 4

The reaction by the slave to a MOSI transfer is entirely up to you since you're designing the slave behavior.

If the transfer is the only time (when the frame is active), for the slave to respond it either has to adjust it's behavior to finish during the frame OR it has to implement and describe that behavior so that a master using that capability is clocking MOSI data long enough (filler data) to let the slave complete.

That's the crux of it.

An example of where I've seen this is in the Microsemi SmartFusion 2 (MS2090) part:

It's not that strange or unusual actually. The Microsemi M2S090 has a similiar condition when polling for HW_STATUS. The MOSI sends 0xFF, and while clocking the command the MISO data contains the response. In the same frame while clocking in the command MOSI not after 0xFF is clocked to slave.

Compare contrast to other commands where after the payload is clocked MOSI, the master keeps the frame active, clocks more data MOSI so that the slave can respond per some requirement. The master is what keeps the frame active and while it's active it keeps the clock running.

It's your design and therefore your requirements.

What I did to investigate for a comparison was run some Arduino boards M/S and scope the behavior. I used this scenario to validate an expectation of the Slave to react to what the MOSI command/data was.

EDIT: On second thought, this isn't entirely up to you. In fact there are standards that third party vendors build around. If you are entirely sure that your walled garden of FPGA and SPI usage is isolated, do what you want. But if any third party device is intended to connect and transact with your master then some care needs to be made for the conduct of the master during a frame of SPI transfer. (I'm thinking here of Mode, and there are articles on wikipedia etc.. on this as well as your datasheet of your silicon would even better place to look).