Revision C or later of the '860 will even perform
a single-address _burst_ transfer on IDMA channel 1.
This I would love to do from our in-house designed
frame grabber to main memory. Then I could avoid
disabling all interrupts while bursting. Meaning
I could still catch run-away situations on a
time-out basis. Today things simply lock up...
The biggest complaint I hear is the performance stinks.
Which it does, since it is really a software based DMA
algorithm running on the CPM.
Possibely. But where does the manual say that the
performance stinks? It should be documented somewhere.
I *think* you mean Single-buffer burst flyby mode.
That is correct. I just quoted the subtitle of figure 20-15.
But the chapter is named Single-buffer burst flyby mode.
The following figure numbers are collected from the current
version of the MPC860UM user manual in PDF form @ motorola.
Figure 14-5: Single-Beat Cycle Basic Timing Zero Wait States
Two clock cycles per bus cycle.
Figure 14-12: Burst-Read Cycle with Zero Wait state.
Five clock cycles per four words burst cycle.
Figure 20-15: Single Buffer/Address IDMA1 Burst Timing.
/TA alternating resulting in one waitstate per
word and thus nine clock cycles per four words
burst cycle.
Figure 14-14: Burst-Read Cycle with Wait States between Beats.
Would have been identical to figure 20-15
with identical /TA pattern.
Now, the question is - what controls the /TA line?
Will I get full speed if actively driving the /TA line low for
the duration of the IDMA1 burst cycle? Or for that matter in the
Single-address/Single-cycle Fly-by transfer of figure 20-10?
The subtitles states that /TA is externally generated. What then
stops me from running the IDMA bus cycle with normal PIO mode
timing as per figure 14-5?
Figure 20-10: /SDACK timing diagram
Single-Address Peripheral write
__EXTERNALLY GENERATED /TA__
--
******************************************************
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/
From: Alan Mimms <hidden> Date: 2000-03-17 17:23:38
Regarding the "where does the manual say that the performance stinks"
comment: even though people like Richard are VERY forthcoming with
"issues" with chips (THANKS Richard), I doubt a company like MOT will
EVER admit in a manual or other official document they built something
that stinks even a little bit. See the MPC801 for an example of this
where virtually EVERYTHING about the chip stinks (including the crappy
inaccurate manual) and nothing is ever said in written form to that
effect. (For those unused to my cynical style, I love MOT and my
company has even made a bunch of money selling devices built on the
MPC801. But they are NOT perfect - as I'm sure Richard and numerous
will attest - and they will rarely admit it in writing.)
a
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
Original Message <<<<<<<<<<<<<<<<<<
On 3/17/00, 9:02:22 AM, "Geir Frode Raanes" [off-list ref]
wrote regarding Re: What is the catch with IDMA on MPC860?:
On Fri, 17 Mar 2000, Richard Hendricks wrote:
quoted
Geir Frode Raanes wrote:
quoted
Revision C or later of the '860 will even perform
a single-address _burst_ transfer on IDMA channel 1.
This I would love to do from our in-house designed
frame grabber to main memory. Then I could avoid
disabling all interrupts while bursting. Meaning
I could still catch run-away situations on a
time-out basis. Today things simply lock up...
quoted
The biggest complaint I hear is the performance stinks.
Which it does, since it is really a software based DMA
algorithm running on the CPM.
Possibely. But where does the manual say that the
performance stinks? It should be documented somewhere.
quoted
I *think* you mean Single-buffer burst flyby mode.
That is correct. I just quoted the subtitle of figure 20-15.
But the chapter is named Single-buffer burst flyby mode.
The following figure numbers are collected from the current
version of the MPC860UM user manual in PDF form @ motorola.
Figure 14-5: Single-Beat Cycle Basic Timing Zero Wait States
Two clock cycles per bus cycle.
Figure 14-12: Burst-Read Cycle with Zero Wait state.
Five clock cycles per four words burst cycle.
Figure 20-15: Single Buffer/Address IDMA1 Burst Timing.
/TA alternating resulting in one waitstate per
word and thus nine clock cycles per four words
burst cycle.
Figure 14-14: Burst-Read Cycle with Wait States between Beats.
Would have been identical to figure 20-15
with identical /TA pattern.
Now, the question is - what controls the /TA line?
Will I get full speed if actively driving the /TA line low for
the duration of the IDMA1 burst cycle? Or for that matter in the
Single-address/Single-cycle Fly-by transfer of figure 20-10?
The subtitles states that /TA is externally generated. What then
stops me from running the IDMA bus cycle with normal PIO mode
timing as per figure 14-5?
From: Dan Malek <hidden> Date: 2000-03-17 17:50:47
Alan Mimms wrote:
Regarding the "where does the manual say that the performance stinks"
That's an irrelevant question, as no one literally said "the performance
stinks", and no one should.
If you take a look at the timing diagrams and the CPM performance
worksheets, you will find the IDMA is not terribly efficient. This
is a system design choice. You can move data significantly faster
using PPC core programmed I/O operations. The other system design
considerations surround the use of the CPM. If you choose to use
the IDMA, it affects other CPM operations.
The IDMA could very well statisfy a particular system design. If
the feature wasn't there, people would be complaining for that
reason.
The 860 is a killer communication processor. When you start using
some of these other features, it significantly impacts this capability.
In the case if IDMA, control signals used for some communication
capabilities are lost, and you have to choose configuration options
that further erode the communication processing performance. Just
be aware of this.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Richard Hendricks <hidden> Date: 2000-03-17 21:20:02
Ah, but there's an assumption you're making Dan, and that's the IDMA
was added for the 860. It was really added for camera customers using
the MPC821/MPC823. That's why single buffer burst flyby was added,
and that's why it supports interlacing. In the MPC823 manual, we even
describe how to setup IDMA to interface to a CCD camera with multiple
fields.
Anyways, IDMA performance is horse that has been beaten enough here
in Motorola. The hardware DMA controller in the original 360 took
too much space, and so using the CPM to do IDMA was born. For most
situations, it is a perfect compromise.
Actually, I was remiss in my earlier statement. The biggest complaint
about IDMA is that you can't use it with Ethernet. On the latest
version of the MPC823 this is fixed. The problem comes about because
the CAM capability of the Ethernet can't be turned off. CAM was removed
from the feature list of the MPC823, but wasn't removed from the die
itself until Rev. A (I think). It caused us many a headaches as
we couldn't understand why a collegue's audio codec using
DMA would always go haywire whenever he received an Ethernet packet.
Dan Malek wrote:
Alan Mimms wrote:
quoted
Regarding the "where does the manual say that the performance stinks"
That's an irrelevant question, as no one literally said "the performance
stinks", and no one should.
If you take a look at the timing diagrams and the CPM performance
worksheets, you will find the IDMA is not terribly efficient. This
is a system design choice. You can move data significantly faster
using PPC core programmed I/O operations. The other system design
considerations surround the use of the CPM. If you choose to use
the IDMA, it affects other CPM operations.
The IDMA could very well statisfy a particular system design. If
the feature wasn't there, people would be complaining for that
reason.
The 860 is a killer communication processor. When you start using
some of these other features, it significantly impacts this capability.
In the case if IDMA, control signals used for some communication
capabilities are lost, and you have to choose configuration options
that further erode the communication processing performance. Just
be aware of this.
-- Dan
From: Dan Malek <hidden> Date: 2000-03-17 21:46:28
Richard Hendricks wrote:
Ah, but there's an assumption you're making Dan, and that's the IDMA
was added for the 860.
Geeze, I guess my couple of years of technical writing classes were
a waste of time. Where did it appear I was making an assumption?
I said:
1. The 860 is a killer communication processor
2. The IDMA is a feature that requires system design trade offs
3. If IDMA wasn't present, people would likely request it
.... It was really added for camera customers using
the MPC821/MPC823.
OK, but we weren't talking about 821 or 823. There is a wide range of
features available in the 8xx family, and unfortunately you can't
get everything all of the time. The IDMA on the 860 falls into
this category.
My original response long ago was to ensure people consider the system
design, and I attempted to include some supporting detail. This has
been turned into "performance sucks" and "Dan is making assumptions."
Neither is true.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Richard Hendricks <hidden> Date: 2000-03-17 21:11:11
Alan Mimms wrote:
Regarding the "where does the manual say that the performance stinks"
comment: even though people like Richard are VERY forthcoming with
"issues" with chips (THANKS Richard), I doubt a company like MOT will
EVER admit in a manual or other official document they built something
that stinks even a little bit. See the MPC801 for an example of this
where virtually EVERYTHING about the chip stinks (including the crappy
inaccurate manual) and nothing is ever said in written form to that
effect. (For those unused to my cynical style, I love MOT and my
company has even made a bunch of money selling devices built on the
MPC801. But they are NOT perfect - as I'm sure Richard and numerous
will attest - and they will rarely admit it in writing.)
I think this issue is covered quite well in the boilerplate at the
beginning of the MPC823 manual.
"Motorola makes no warranty, representation or guarantee regarding
the suitability of its products for any particular purpose..."
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Alan Mimms <hidden> Date: 2000-03-17 21:35:10
So THAT's why these big companies never tell us when they find their
junk sucks. They have it in the fine print at the front of every manual!
a
On Fri, 17 Mar 2000, Richard Hendricks wrote:
Alan Mimms wrote:
quoted
Regarding the "where does the manual say that the performance stinks"
comment: even though people like Richard are VERY forthcoming with
"issues" with chips (THANKS Richard), I doubt a company like MOT will
EVER admit in a manual or other official document they built something
that stinks even a little bit. See the MPC801 for an example of this
where virtually EVERYTHING about the chip stinks (including the crappy
inaccurate manual) and nothing is ever said in written form to that
effect. (For those unused to my cynical style, I love MOT and my
company has even made a bunch of money selling devices built on the
MPC801. But they are NOT perfect - as I'm sure Richard and numerous
will attest - and they will rarely admit it in writing.)
I think this issue is covered quite well in the boilerplate at the
beginning of the MPC823 manual.
"Motorola makes no warranty, representation or guarantee regarding
the suitability of its products for any particular purpose..."
--
Alan Mimms Packet Engines, Inc. Spokane, Washington [99214-0497]
USA, Earth, Sol, Milky Way, The Local Group, Virgo Supercluster, U0
Despite the cost of living, have you noticed how popular it remains?
-- Steven Wright?
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Richard Hendricks <hidden> Date: 2000-03-17 21:09:09
Geir Frode Raanes wrote:
On Fri, 17 Mar 2000, Richard Hendricks wrote:
quoted
Geir Frode Raanes wrote:
quoted
Revision C or later of the '860 will even perform
a single-address _burst_ transfer on IDMA channel 1.
This I would love to do from our in-house designed
frame grabber to main memory. Then I could avoid
disabling all interrupts while bursting. Meaning
I could still catch run-away situations on a
time-out basis. Today things simply lock up...
quoted
The biggest complaint I hear is the performance stinks.
Which it does, since it is really a software based DMA
algorithm running on the CPM.
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.
YMMV, btw. :)
quoted
I *think* you mean Single-buffer burst flyby mode.
That is correct. I just quoted the subtitle of figure 20-15.
But the chapter is named Single-buffer burst flyby mode.
The following figure numbers are collected from the current
version of the MPC860UM user manual in PDF form @ motorola.
Figure 14-5: Single-Beat Cycle Basic Timing Zero Wait States
Two clock cycles per bus cycle.
Figure 14-12: Burst-Read Cycle with Zero Wait state.
Five clock cycles per four words burst cycle.
Figure 20-15: Single Buffer/Address IDMA1 Burst Timing.
/TA alternating resulting in one waitstate per
word and thus nine clock cycles per four words
burst cycle.
Figure 14-14: Burst-Read Cycle with Wait States between Beats.
Would have been identical to figure 20-15
with identical /TA pattern.
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).
Will I get full speed if actively driving the /TA line low for
the duration of the IDMA1 burst cycle? Or for that matter in the
Single-address/Single-cycle Fly-by transfer of figure 20-10?
The subtitles states that /TA is externally generated. What then
stops me from running the IDMA bus cycle with normal PIO mode
timing as per figure 14-5?
You're limited to however fast you can interface to the
memory. If your peripheral needs extra cycles inserted in,
it could use UPWAITx to do so.
Figure 20-10: /SDACK timing diagram
Single-Address Peripheral write
__EXTERNALLY GENERATED /TA__
--
******************************************************
Never ever underestimate the power of human stupidity.
-Robert Anson Heinlein
GeirFRS@invalid.and.so.forth
******************************************************
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. 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.
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.
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.
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.
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.
quoted
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.
--
******************************************************
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/
From: Richard Hendricks <hidden> Date: 2000-03-22 16:49:54
Geir Frode Raanes wrote:
On Fri, 17 Mar 2000, Richard Hendricks wrote:
quoted
Geir Frode Raanes wrote:
quoted
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.
quoted
quoted
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
******************************************************
Would you mind telling me briefly what CPM, UART, DMA/IDMA, UPM, and SCC
are, or pointing me to a document that explains them? I see these terms
used a lot, but I don't know what they stand for and have only a general
idea of what they are. I apologize for wasting your time with a worthless
question.
<snip>
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.
<snip>
quoted
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.
<snip
quoted
quoted
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).
<snip>
Noah Misch
nmisch@erols.com
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Graham Stoney <hidden> Date: 2000-03-23 02:34:32
Hi Noad,
Noah Misch writes:
Would you mind telling me briefly what CPM, UART, DMA/IDMA, UPM, and SCC
are, or pointing me to a document that explains them? I see these terms
used a lot, but I don't know what they stand for and have only a general
idea of what they are. I apologize for wasting your time with a worthless
question.
From: Claude Robitaille <hidden> Date: 2000-03-23 13:30:02
The most authoritative reference for thoses terms is the PowerQUICC
(MPC8xx) user's manual. You can find it on the Motorola web site at:
http://www.mot.com/netcomm
Claude
On Thu, 23 Mar 2000, Graham Stoney wrote:
Hi Noad,
Noah Misch writes:
quoted
Would you mind telling me briefly what CPM, UART, DMA/IDMA, UPM, and SCC
are, or pointing me to a document that explains them? I see these terms
used a lot, but I don't know what they stand for and have only a general
idea of what they are. I apologize for wasting your time with a worthless
question.
From: Richard Hendricks <hidden> Date: 2000-03-23 22:49:02
Noah,
Everyone else pointed you to documents, but I'll give you a
nickel explaination.
CPM = Communications processor module. It's the second CPU on the
MPC8xx family that handles communication (so, say, the PowerPC CPU
doesn't need to worry about handling each byte of an ethernet packet).
It is based off the MPC68360 CPM. It has been modifed by adding
a MAC unit to do DSP, and changing the hardware DMA to software
(running on the CPM). Kinda makes the MPC8xx family "dual core", but
that may be strecthing it a bit. Programming of the CPM is restricted
to Motorola and a few key customers.
UART = Universal Asynchronous Receiver/Transmitter. A serial port,
where data is transmitted one bit at a time. Used mostly in PCs as
RS-232.
DMA/IDMA = Direct Memory Access/ Independant DMA. DMA allows memory
transactions to go on without CPU intervention. Say you have a digital
camera with a CCD. You would want the CCD's information constantly
copied to main memory. With DMA, you can do that without the CPU
having to transfer every byte itself. IDMA is just how DMA is
implemented in the MPC8xx by the CPM. Independant means
independant from the serial channels, I guess. You could also
use DMA, say, to feed an audio chip data when it requests it.
UPM = User Programmable Machine. A special state machine within
the Memory Controller for handling complex memories like DRAM and
custom user interfaces. It allows you to control the waveforms of
the various memory signals. Sorta like a microcode for a memory
controller.
SCC = Serial Communications Controller. Many serial protocols are
similar enough that a general "serial engine" can handle them. The SCC
is powerful enough to do everything from RS-232 up to Ethernet. There's
also a FCC, or Fast CC, and an SMC. An SMC is a Serial Management
Controller, which is designed for very simple serial protocols. As far
as actual nuts & bolts, the SCC can handle more bandwidth since much
of its functionality is hardware-based, while most of the SMC
functionality is controlled by software. This is why the SMC
can't handle the same amount of data bandwidth the SCC can.
Noah Misch wrote:
Would you mind telling me briefly what CPM, UART, DMA/IDMA, UPM, and SCC
are, or pointing me to a document that explains them? I see these terms
used a lot, but I don't know what they stand for and have only a general
idea of what they are. I apologize for wasting your time with a worthless
question.
<snip>
quoted
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.
<snip>
quoted
quoted
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.
<snip
quoted
quoted
quoted
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).