PowerPC 8272 SPI

I was wondering if anyone had experience with the powerpc 8272 involving
the use of the SPI port. I was reading in the manual and I quote the
following in chapter 35 on the SPI hardware:

"The maximum sustained data rate that the SPI supports is SYSTEMCLK/50.
However, the SPI can transfer a single character at much higher
rates—SYSTEMCLK/4 in master mode and SYSTEMCLK/2 in slave
mode. Gaps should be inserted between multiple characters to keep from
exceeding the maximum sustained data rate."

This would indicate that with a 100MHz system clock you could at most
support 2MHz sustained transfers. The manual doesn't describe very well
what this means. The beginning of this chapter mentions speeds of slave
mode up to 50MHz with the SPI and this seems a bit misleading. Can anyone
explain what it means by "sustained" and why this limit exists. I can't
figure it out from the manual and I was hoping someone with experience
with this processor might have a quick explanation

On Sat, 03 Feb 2007 21:00:42 +0000, Don wrote:

> This would indicate that with a 100MHz system clock you could at most
> support 2MHz sustained transfers. The manual doesn't describe very well
> what this means. The beginning of this chapter mentions speeds of slave
> mode up to 50MHz with the SPI and this seems a bit misleading. Can anyone
> explain what it means by "sustained" and why this limit exists. I can't
> figure it out from the manual and I was hoping someone with experience
> with this processor might have a quick explanation

The FIFO buffers in the SPI (receive and transmit) are only two characters
in depth.  The SPI uses RX and TX buffers in the 16 Kbyte dual-port RAM to
fill or empty the FIFOs.  The SPI contends with a number of other
peripherals for access to the dual-port RAM.  

Chapter 13 of the Reference Manual explains the Communications Processor
Module (CPM) and shows the relationship between it and the ten
communications controllers, one of which is the SPI.


     ~Dave~

On Sat, 03 Feb 2007 20:11:15 -0500, Dave wrote:

> On Sat, 03 Feb 2007 21:00:42 +0000, Don wrote:
> 
>> This would indicate that with a 100MHz system clock you could at most
>> support 2MHz sustained transfers. The manual doesn't describe very well
>> what this means. The beginning of this chapter mentions speeds of slave
>> mode up to 50MHz with the SPI and this seems a bit misleading. Can
>> anyone explain what it means by "sustained" and why this limit exists.
>> I can't figure it out from the manual and I was hoping someone with
>> experience with this processor might have a quick explanation
> 
> The FIFO buffers in the SPI (receive and transmit) are only two
> characters in depth.  The SPI uses RX and TX buffers in the 16 Kbyte
> dual-port RAM to fill or empty the FIFOs.  The SPI contends with a
> number of other peripherals for access to the dual-port RAM.
> 
> Chapter 13 of the Reference Manual explains the Communications Processor
> Module (CPM) and shows the relationship between it and the ten
> communications controllers, one of which is the SPI.
> 
> 
>      ~Dave~

I understand the character buffering is only two deep but since it uses
the dual port RAM to buffer these incoming characters, I don't understand
the limit imposed (aka the "sustained" comment) as long as you can clean
out the circular buffers in the dual port RAM quickly enough. We won't be
sharing the SPI bus with any of the other CPM hardware (ethernet, I2C,
etc). I guess it just leaves the possibility of actually coding and
empirical study, rather than being lucky enough for someone here having
experienced this problem. The manual is vague as to this limit, I would
have thought they (freescale) would have mentioned the limitations of
their own device, rather than putting up some (almost) useless burst speed
information. It's kind of like when speaker manufacturers highlight peak
power and hide the RMS in small print.

Thanks for your comment!

On Sun, 04 Feb 2007 18:22:19 +0000, Don wrote:

> On Sat, 03 Feb 2007 20:11:15 -0500, Dave wrote:
> 
>> The FIFO buffers in the SPI (receive and transmit) are only two
>> characters in depth.  The SPI uses RX and TX buffers in the 16 Kbyte
>> dual-port RAM to fill or empty the FIFOs.  The SPI contends with a
>> number of other peripherals for access to the dual-port RAM.
> 
> I understand the character buffering is only two deep but since it uses
> the dual port RAM to buffer these incoming characters, I don't understand
> the limit imposed (aka the "sustained" comment) as long as you can clean
> out the circular buffers in the dual port RAM quickly enough. We won't be
> sharing the SPI bus with any of the other CPM hardware (ethernet, I2C,
> etc). 

A long time ago in a galaxy far, far away .. there was this 68360 ...

<Sorry, one of the cable channels had Star Wars IV on earlier and I
couldn't resist.   ;-)  >

The problem isn't "sharing the SPI bus with any of the other CPM
hardware."  The problem is sharing the resources of the CPM (e.g.,
dual-port RAM, peripheral bus, SDMA) with the other controllers and
the CP.  For instance, there are only two physical SDMA channels which
provide two virtual channels for each communications controller.  That's
twenty virtual channels for the communications controllers alone sharing
two physical channels on one bus.  The I2C controller is very similar
to the SPI controller in the CPM.  The Ref Manual shows a CP utilization
of 25% at a max frequency just over 2 MHz for it.  What do you suppose the
CP utilization is to sustain the SPI controller at 25 or 50 MHz?

If you are determined that you must run the SPI at a sustained rate equal
to its burst rate, then test it.  I2C and the RISC timers are lower
priority to the CP than SPI.  Load all of your comms controllers to the
max rates you expect them to support and see if a RISC timer diverges from
a hardware timer.  If it doesn't, you're home free (at least until the
customer asks for "one little change"!).  If it does diverge, then you
have to throttle something back.  Since SPI and I2C are "local", they are
the logical choices.  


     ~Dave~