10
\$\begingroup\$

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?

\$\endgroup\$
6
  • \$\begingroup\$ Owe, good question! It seems depending on who calls theirs standard. I found a Wikipedia article, Intel claims their standard is: "This standard supports standard memory cycles with lengths of 1 byte to 4 kilobytes of data." I am not sure why not 4 bits to 1 M bytes. \$\endgroup\$
    – jay
    Nov 9, 2021 at 17:05
  • \$\begingroup\$ @jay what do you mean by 'memory cycles'? I understand that they say you can send from 1 byte to 4 KB of data, yet I still don't see how many clock cycles should be sent in total. \$\endgroup\$
    – Martel
    Nov 9, 2021 at 17:10
  • 5
    \$\begingroup\$ SPI clocks one each for a data bit, so a byte takes 8 clocks. Thus, 4KB x 8 = 32K clock cycles. \$\endgroup\$
    – jay
    Nov 9, 2021 at 17:16
  • 2
    \$\begingroup\$ You need to look at the datasheet of the device you're trying to drive. It has all the rules. In general: follow the protocol as defined in the device's datasheet. Typically the SPI transaction "resets" when the master transitions the slave select from inactive to active, and then a specific number of clocks is sent, according to the datasheet. \$\endgroup\$ Nov 9, 2021 at 20:56
  • 1
    \$\begingroup\$ "this means that the master implementer needs to know the impl. details of the slave (and all the potential slaves)" -- well, yes, and no. E.g. the SPI hardware on a microcontroller doesn't need to know about all possible slaves, it's usually enough to just have a hardware function for clocking a byte on the wire. (plus buffering for speed maybe) Software can then deal with the particulars of the specific slaves used in the device, it already needs device-specific knowledge of what the data is, so knowing if e.g. a dummy byte needs to be sent is not a huge burden. \$\endgroup\$
    – ilkkachu
    Nov 10, 2021 at 18:57

4 Answers 4

18
\$\begingroup\$

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.

\$\endgroup\$
6
  • 3
    \$\begingroup\$ An SD card in SPI mode uses framing bytes. You get a certain repeating byte, then the frame byte, then data bytes. It's not that terrible a model. \$\endgroup\$
    – Joshua
    Nov 10, 2021 at 2:42
  • 1
    \$\begingroup\$ I wonder why relatively few SPI devices provide a means of resetting the "frame" state machine while holding CS low, such as by sending three consecutive rising edges on MOSI while CLK sits low? For applications that only one need a single SPI peripheral, that would save an I/O pin on the controlling MCU. \$\endgroup\$
    – supercat
    Nov 10, 2021 at 21:02
  • \$\begingroup\$ @supercat, cheaper to just tie CS to the reset lines of some components than to implement a counter? \$\endgroup\$
    – ilkkachu
    Nov 10, 2021 at 22:37
  • \$\begingroup\$ @supercat - possibly because that would impose extra processing requirements on simple shift-register style slaves. \$\endgroup\$
    – brhans
    Nov 10, 2021 at 22:54
  • 1
    \$\begingroup\$ @Martel In my experience, SPI slave clocking depends on how many extra clocks (if any) the device needs to do its thing internally. If it only needs a few extra clocks in addition to those which were needed to transfer data then the 'dummy bytes' method is often used where a couple of extra bytes are transferred with meaningless data just to provide those clocks. If the slave needs a lot of extra clocks (or continuous clocking) then it'll either have its own internal clock or an additional clock pin. \$\endgroup\$
    – brhans
    Nov 12, 2021 at 15:10
17
\$\begingroup\$

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.

\$\endgroup\$
7
\$\begingroup\$

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.

\$\endgroup\$
1
\$\begingroup\$

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).

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.