# SPI clock skew prevention

I have a quick question about the clock skew. Does the implementation of SPI account for clock skew? If the data is sampled at the first register and transferred at the last register, ideally when transferring the rising edge from the master to the slave device. The first register should not receive the rising edge first since the same clock signal being transferred may also be incident on the last register of the master device. Therefore there may be a delay between the appearance of the rising edge of the clock line in comparison to the data from the last register, where the clock rising edge appears first. So if you were to have the rising edge incident on the first register of the slave device, essentially you transfer a data hazard. The way i can think of solving this is to essentially provide the clock signal to the slave device shift register starting at n, n-1, n-2, n-3 and so on...

Are there any preventative measures for clock skew in practice and exactly what do they look like? Thanks

• So are you talking about skew inside the shift register? Jan 22, 2022 at 14:58

The SPI standard implicitly allows up to almost ±1/2 unit interval of skew, by virtue of the fact that, regardless of the settings for clock phase and polarity, data is always latched on the opposite clock edge from the edge on which it is driven. So, what are the sources of skew that need to be considered?

Transfers from master to slave are source-synchronous, so any skew would only be related to any path length difference between the clock and MOSI signals.

Transfers from slave to master have a total round-trip delay that includes the propagation delay of the clock from master to slave, the slave's internal delay from clock to MISO out, and the return delay of MISO from slave to master. It is this delay that puts an upper bound on the clock frequency you can use.

• Which, in short, translates to: No, SPI does not account for clock skew, the user of SPI devices that is designing the SPI bus is responsible of handling skew by keeping the clock frequency, bus length, and signal integrity within specs of the chips. Jan 22, 2022 at 15:28
• @Justme: See edit above. Jan 22, 2022 at 18:06
• 'data is always latched on the opposite clock edge from the edge on which it is driven' Explain this? Jan 22, 2022 at 19:16
• @ThreadBucks: See the timing diagrams on Wikipedia. The text description is a bit ambiguous: "On the clock edge, both master and slave shift out a bit and output it on the transmission line to the counterpart. On the next clock edge, at each receiver the bit is sampled from the transmission line and set as a new least-significant bit of the shift register." -- "the next clock edge" in this case is the opposite edge. When the data changes on the blue edges, the receivers sample on the red edges, and vice-versa. Jan 22, 2022 at 20:22
• How can the shift register transmit on the rising edge and capture on the falling edge? Isnt the clock incident on all d-flipflop's? How can you implement the shift register so that the least significant register samples on the falling edge and the most significant register transmit on the rising edge? What about the registers in between? Jan 22, 2022 at 21:14

Fortunately, the propagation delay in the register is much longer than the risetime, and the distance is short enough to neglect that skew. Thus all registers are edge clocked synchronously and latched.

Perhaps in optical computers, this is a concern. ;)

Review the datasheets for risetime minimum and threshold variations with, setup & hold times and compare with propagation delays tPLH and tPHL to verify for yourself.

When multiple chips with a race condition relative to the transfer times can occur, then multi-phase clocks are used. For example, inverted clock edges used by the original MC6800 or as in modern Video Memory (VRAM) with DDR5.