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

Status
Not open for further replies.
H

Hjldioyitsi

Member level 1
Joined
Mar 7, 2012
Messages
32
Helped
0
Reputation
0
Reaction score
1
Trophy points
1,288
Location
Brazil
Activity points
1,473
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:
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...
 

Sort by date Sort by votes
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
 

Upvote 0 Downvote
Lívia_Reis said:
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...
Click to expand...
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.
 
Upvote 0 Downvote
Thanks! It does make sense that the path delay between master and slave is the reason for that.

FvM said:
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
Click to expand...

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

Upvote 0 Downvote
Lívia_Reis said:
Does this mean the master would need an extra 9th SCK cycle to complete an 8-bit transfer?
Click to expand...
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.
 
Upvote 0 Downvote
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.
 

Upvote 0 Downvote
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
 
Upvote 0 Downvote
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.
 
Upvote 0 Downvote
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
 
Upvote 0 Downvote
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 ---

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?
 
Last edited:

Upvote 0 Downvote
Status
Not open for further replies.

Similar threads

Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…