Re: What is the catch with IDMA on MPC860?

["Richard Hendricks" <ra6353@email.sps.mot.com>]

Geir Frode Raanes wrote:
>
> On Fri, 17 Mar 2000, Richard Hendricks wrote:
>
> > Geir Frode Raanes wrote:
> > >
> > > Possibely. But where does the manual say that the
> > > performance stinks? It should be documented somewhere.
> >
> > Of course!  It's documented in the Serial Communications
> > Performance chapter.  Something like 3-4 pages at the very
> > end.  At 25 MHz (the values scale linearly with frequency,
> > more or less), and with no other loading on the CPM,
> > Memory to Memory burst IDMA transactions top out at 10.4 MB/sec,
> > or, at a more reasonable speed like 66 MHz, 27.45 MB/sec.
>
> Ah. RTFM. The paper version - Appendix B - that is.
> Can still not find it in the PDF version. Funny.
> Thank you anyway. Those where the timing diagrams I
> were looking for.

Ah, I am support for the MPC823/MPC823, so everything is
tinged with MPC82x colored glasses.  I don't happen to have
an MPC860 manual handy anymore.

> I am just moving up from the world
> of microcontrollers and FPGA to microprocessors.
> Can't say I am all that thrilled about IF-THEN-ELSE
> soft timing datasheets. But I'll manage.

Such is life in the high end world ;)

> And 27.45 MBytes per sec gives me a reasonable headroom
> from the 20 MBytes per second requirement of the grabber,
> and still allow me to leave interrupts enabeled.
> And yes, it is in fact a CCD camera grabber without
> much local buffering.

Just be sure you don't overtax your CPM.  20/27.45 = 73%,
but if you start adding in UARTs, etc, you might be getting
close to the edge.

> What I was really asking was what the "inefficient"
> label on IDMA was all about. More specifically, if that
> meant that IDMA wasted bus clock cycles - i.e. hogging
> the bus while setting up the transfer or requiring
> wait states irrespectible of the source/target speed.
> Considering the timing diagrams in Appendix B and given
> the Motorola "will then perform a fast back-to-back
> transfer" statement this does not seem to be the case.

Oh yes, you're right.  The CPM does all the staging internally,
and it doesn't need to "hold" the bus for the cycles while
it is packing/unpacking data.  It only takes the bus
when it is actively transferring data.

> I can live with the fact that IDMA can not utilize the
> bus 100% of the time as long as it __relinquish the bus__
> at all times it does not perform __full speed__ data
> movements. Actually I prefer it does just that.

And that's just what it does.  Sorry about the misunderstanding.

> The other use of these IDMA channels is for soft
> PCI interface. There is specified a limit of 8 PCI
> clocks on target latency. That rules out any interrupt
> based interface handling. But IDMA to configuration
> space and memory space respectively in combination
> with an interrupt migth do the trick.
>
> > > Now, the question is - what controls the /TA line?
> >
> > Er, you're doing DMA to/from a memory.  The timing of that
> > memory controls /TA.  If you're using your DRAM with one
> > of the UPMs, and you're targeting that DRAM with IDMA, it
> > uses the UPM to control the DRAM. (For a flyby-mode transaction).
>
> I am aware of that. What I was really asking was what is the
> upper boundary on the timing. Like for instance the timing
> of the TMP68303 microcontroller from Toshiba wich stated that
> the _slower_ of the internally generated /DTACK and externally
> applied is used for DMA transfers.

The timing is controlled by either the UPM or GPCM currently in
control of the transaction.  If you want finer scale timings,
then you can check out the timing spreadsheets (for the MPC821/MPC823
anyways).

> --
>   ******************************************************
>   Never ever underestimate the power of human stupidity.
>   -Robert Anson Heinlein
>
>                 GeirFRS@invalid.and.so.forth
>   ******************************************************

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/