Does SPI require delay on clock line?

[asgard20032]

Based on this: https://en.wikipedia.org/wiki/Source-synchronous
And this : https://en.wikipedia.org/wiki/Media-independent_interface#Reduced_gigabit_media-independent_interface

It look like device that send data and clock to communicate need to delay clock for the setup time of the internal latch.

What bout spi? What happen if clock and data arrive at the same time? On clock rising edge it want to latch the data, but the data is also in a changing state...

[AndyC_772]

There's nothing about this problem that's specific to SPI.

Any receiving device will require a certain amount of set-up time before an active clock edge, and hold time after it. Those timings will be specified in the device's data sheet, usually in a way that's nowhere near as clear as it could be.

Usually with SPI, data is made to change on one edge, and is then sampled on the other. This alleviates the need to worry too much about the precise relationship between clock and data, provided the interface isn't running too fast. As long as [(half a clock) - (propagation delays)] > (setup time), and similarly for hold time, you can get away without doing a static timing analysis.

Paradoxically, this approach does limit the maximum speed at which the interface can run. For a given pair of devices, and if there's a choice of what edge to use for what, having data sampled on the same edge on which it's updated can be quicker. This is because the receiver gets almost a whole clock's worth of setup time, and often the hold time requirement is (or is close to) zero, so the fact that the data becomes invalid just at the time of an active clock edge isn't a problem.

In this case, though, you absolutely do need to study the setup & hold requirements of the receiver, and the clock-to-out and other parameters of the driver, in order to ensure they're compatible. You may need to include your own PCB routing delays too.

Timing analysis is something which rarely seems to get a mention on the forums these days, probably because if you're just using a microcontroller to wiggle LEDs on and off then it's something you get away without having to do... but it's an absolutely fundamental part of digital circuit design, and about as much fun as grabbing the hot end of a soldering iron, IMHO.

[ade]

Nice diagram from Motorola SPI Block Guide V03.06:



In this mode you can see that the data changes (MOSI / MISO) always happen ahead of the clock (SCK) changes, by a half-cycle.   This ensures that the SAMPLE occurs between data transitions, not as they occur.   If we sample on rising edges, then we change data on falling edges (and vice versa).

[Bruce Abbott]

What happen if clock and data arrive at the same time? On clock rising edge it want to latch the data, but the data is also in a changing state...

It depends on the device that is reading the data. If it has zero or negative setup time then it may be OK, but if it has positive setup time (data must be stable before the clock rises) then it will fail.

Since SPI is specified to change the data on one clock edge and receive it on the other, SPI devices normally expect to see stable data well before the active clock edge. However it may be that a particular device will still work with zero setup time, but not reliably. This is a common problem seen when the wrong SPI mode is chosen.