SPI's CPHA description in NXP's Block Guide.

[Hjldioyitsi]

Greetings again, all.

I'm a little confused about the CPHA description on the SPI Block Guide V04.01 from Motorola/NXP.
The description is the following:

"If the CPHA bit in SPI Control Register 1 is clear, odd numbered edges on the SCK input cause the data
at the serial data input pin to be latched. Even numbered edges cause the value previously latched from the
serial data input pin to shift into the LSB or MSB of the SPI shift register, depending on the LSBFE bit.

If the CPHA bit is set, even numbered edges on the SCK input cause the data at the serial data input pin
to be latched. Odd numbered edges cause the value previously latched from the serial data input pin to shift
into the LSB or MSB of the SPI shift register, depending on the LSBFE bit."

My confusion is about why using different clock edges (I am rising vs. falling or vice-versa) to latch the serial data input and to shift it into the shift register.
What does motivate this behavior? Doesn't it make a configurable master device much more complicated? Doesn't it make STA more complicated as well?
I did some sketches here and it seems to be possible to use the same clock edge to latch the serial input data and to shift it into the shift-register without any penalty...

 

[Hjldioyitsi]

 

[Aussie Susan]

It all depends on the way the slave device has been designed.
Most slave SPI devices provide a data sheet that shows the waveforms, or at least says what the CPOL and CPHA values should be. Some may also make reference to the 'SPI modes' (using nomenclature such as "0,0" for the CPHA and CPOL values).
Susan

 

[FvM]

I did some sketches here and it seems to be possible to use the same clock edge to latch the serial input data and to shift it into the shift-register without any penalty...

SPI standard operation latches data a half clock period after it has been send out, both for master and slave side. This way it achieves maximal tolerance against delay skew. Nowadays, SPI is used at clock rates up to 100 MHz where logic and connection delays become significant. At the slave side, SCK and MOSI hopefully arrive with the same delay, so latching at the "other" edge is still preferred. At the master side, MISO arrives always delayed relative to SCK. If the round trip delay approaches a half clock period, the standard SPI clock scheme doesn't work no more. The next step in extending the clock rate is to shift MISO latching to the next edge, which corresponds to your discussed operation mode. It can be configured for most microcontroller SPI interfaces.

 

[Hjldioyitsi]

SPI standard operation latches data a half clock period after it has been send out, both for master and slave side. This way it achieves maximal tolerance against delay skew. Nowadays, SPI is used at clock rates up to 100 MHz where logic and connection delays become significant. At the slave side, SCK and MOSI hopefully arrive with the same delay, so latching at the "other" edge is still preferred. At the master side, MISO arrives always delayed relative to SCK. If the round trip delay approaches a half clock period, the standard SPI clock scheme doesn't work no more. The next step in extending the clock rate is to shift MISO latching to the next edge, which corresponds to your discussed operation mode. It can be configured for most microcontroller SPI interfaces.

Thanks! It does make sense that the path delay between master and slave is the reason for that.

If the round trip delay approaches a half clock period, the standard SPI clock scheme doesn't work no more. The next step in extending the clock rate is to shift MISO latching to the next edge

Does this mean the master would need an extra 9th SCK cycle to complete an 8-bit transfer?

 

[FvM]

Does this mean the master would need an extra 9th SCK cycle to complete an 8-bit transfer?

SCK pin sends always 8 or a multiple of 8 cycles. Additional clock cycles may be spend internally between start of transmission and received data output.

 

[Hjldioyitsi]

Thanks. So in this situation where the delay between master and slave approaches half SCK cycle, the master would need internal extra clock cycles to complete the transfer, right? And probably would have to ignore the MISO data in the very first SCK edge after SS being asserted.

 

[Aussie Susan]

I'm not aware of any SPI module that adds '... internal extra clock cycles to complete the transfer...".
I do know that some SPI modules allow exchanges of other than multiples of 8 bits, but that is certainly the more usual situation.
If the clock speed is so high and the distance so long that transmission delays are causing issues, then you probably have the wrong architecture and need to either shorten the distance, slow the clock or use some other protocol that is not sensitive to the delays.
As for ignoring the first MISO data, that will simply add more problems. However this is generally not required if you look at all 4 combinations of CPHA and CPOL - generally there are 2 that can be used for any slave with the initial sample being delayed in one.
Susan

 

[FvM]

See this timing diagram from PIC24 reference manual to illustrate the clock polarity and sampling time alternatives:

The diagram is valid for 8-Bit SPI operation, the device also supports 16-Bit frames.

You see 8 clock cycles divided by dashed vertical lines. Depending on the SPI mode, SCK is not necessarily changing at the first cycle start, but SDO is always set at the cycle boundary. SDI is either sampled at the middle of cycle (SMP = 0, normal operation) or delayed at the cycle end (SMP = 1).

I see that I caused confusion by mentioning "additional internal clock cycles". They exist in fact in most microcontroller SPI interfaces, but as fast system clock cycles, not divided SCK clock cycles. In most implementations, the whole SPI interface is designed as synchronous logic operated at the system clock ("bus clock" in the NXP block diagram), but the simplified diagram abstracts from internal clock and seems to use only the baud generator output clock. If it only uses a divided clock, then it's at least 2*SCK frequency.

 

[KlausST]

Hi,

I see the 4 clock modes to make the master compatible to a lot of different slaves.
(maybe the slaves were designed before SPI was invented, like some logic shift registers, 74xx595)

Always (multiple of): 8 clock periods for 8 data bits.

Klaus

 

[Hjldioyitsi]

See this timing diagram from PIC24 reference manual to illustrate the clock polarity and sampling time alternatives:

View attachment 178944

The diagram is valid for 8-Bit SPI operation, the device also supports 16-Bit frames.

You see 8 clock cycles divided by dashed vertical lines. Depending on the SPI mode, SCK is not necessarily changing at the first cycle start, but SDO is always set at the cycle boundary. SDI is either sampled at the middle of cycle (SMP = 0, normal operation) or delayed at the cycle end (SMP = 1).

I see that I caused confusion by mentioning "additional internal clock cycles". They exist in fact in most microcontroller SPI interfaces, but as fast system clock cycles, not divided SCK clock cycles. In most implementations, the whole SPI interface is designed as synchronous logic operated at the system clock ("bus clock" in the NXP block diagram), but the simplified diagram abstracts from internal clock and seems to use only the baud generator output clock. If it only uses a divided clock, then it's at least 2*SCK frequency.

So there you have a third configuration bit (SMP), besides CPOL (CKP) and CPHA (~CKE), so it is not fully compliant with NXP standard. For instance, in mode 0, if SMP=1, both SDI and SDO are latched/captured at the "same" edge (falling). Also, SMP=1 only works for modes 0 and 2, right? I'll take a look at this datasheet. Thanks!
PS: another interesting fact is that SMP is not used at slave mode.

--- Updated Oct 7, 2022 ---

In most implementations, the whole SPI interface is designed as synchronous logic operated at the system clock ("bus clock" in the NXP block diagram), but the simplified diagram abstracts from internal clock and seems to use only the baud generator output clock. If it only uses a divided clock, then it's at least 2*SCK frequency.

Isn't it better to use the divided SCK (considering SCK is the divided fast clock) to clock the SPI interface logic (I mean shift register, bit counter, serial input sample register, etc) and the fast clock to clock the "parallel interface" and register file logic?
One question regarding the clocks: if I generate the SCK clock from the fast clock with a prescaler/divider, can they be considered synchronous clocks? Or do I have to take care of synchronization logic when crossing domains?