Home > Archive > A86 Assembler > July 2007 > A simple question about DMA, please help me.
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
A simple question about DMA, please help me.
|
|
| xmllmx 2007-07-18, 6:57 pm |
| Many relevant books tell me that when DMA is working, the data bus is
held by the DMA controller and the CPU is set idle until this transfer
completes.
However, if we start a time-consuming DMA operation, say, copying a
large file, we can still do many other things at the same time, say,
playing a song or drawing a picture. In this situation, it is evident
that the CPU are not idle, that is, the CPU can still access the
memory to fetch instructions while the DMA transfer is continuing.
What text books tell me differs from what I experience, who can tell
me what the cause is?
Any help will be highly appreciated. Many thanks in advance!
| |
| Phil Carmody 2007-07-18, 6:57 pm |
| xmllmx <spamtrap@crayne.org> writes:
> Many relevant books tell me that when DMA is working, the data bus is
> held by the DMA controller and the CPU is set idle until this transfer
> completes.
>
> However, if we start a time-consuming DMA operation, say, copying a
> large file, we can still do many other things at the same time, say,
> playing a song or drawing a picture. In this situation, it is evident
> that the CPU are not idle, that is, the CPU can still access the
> memory to fetch instructions while the DMA transfer is continuing.
> What text books tell me differs from what I experience, who can tell
> me what the cause is?
>
> Any help will be highly appreciated. Many thanks in advance!
What kind of generation of DMA units and buses are we talking here?
It's perfectly possible for DMA units to share the bus
with other devices. In particular if there's a cross-bar
between the various devices. (Although I don't know if
and when cross-bars became de rigeur with x86 family
processors, but they've been pretty common in other
families for quite a while.) But even without a crossbar
the different devices can take turns in using the bus.
Phil
--
"Home taping is killing big business profits. We left this side blank
so you can help." -- Dead Kennedys, written upon the B-side of tapes of
/In God We Trust, Inc./.
| |
| Bob Masta 2007-07-19, 7:57 am |
| On Wed, 18 Jul 2007 15:36:17 -0000, xmllmx <spamtrap@crayne.org>
wrote:
>Many relevant books tell me that when DMA is working, the data bus is
>held by the DMA controller and the CPU is set idle until this transfer
>completes.
>
>However, if we start a time-consuming DMA operation, say, copying a
>large file, we can still do many other things at the same time, say,
>playing a song or drawing a picture. In this situation, it is evident
>that the CPU are not idle, that is, the CPU can still access the
>memory to fetch instructions while the DMA transfer is continuing.
>What text books tell me differs from what I experience, who can tell
>me what the cause is?
>
>Any help will be highly appreciated. Many thanks in advance!
>
I'm not sure whether DMA is involved in file transfers these
days, but the basic idea (at least on the original IBM PC/XT/AT
models and their clones) is that the DMA device asserts the DRQ
line to request the bus, the CPU relinquishes the bus at the
end of the current instruction, the DMA controller moves a byte
(word, etc) of data, and then returns the bus to the CPU. This
happens on every (byte, word, etc) transfer, so the DMA doesn't
hog the bus for the entire memory block (file, etc) to be moved.
That's why the CPU can continue to function normally; it's
only held up a tiny time slice at a time, pretty much like
conventional multi-tasking does, only more efficiently.
Best regards,
Bob Masta
D A Q A R T A
Data AcQuisition And Real-Time Analysis
www.daqarta.com
Scope, Spectrum, Spectrogram, Signal Generator
Science with your sound card!
| |
| rhyde@cs.ucr.edu 2007-07-19, 6:57 pm |
| On Jul 18, 8:36 am, xmllmx <spamt...@crayne.org> wrote:
> Many relevant books tell me that when DMA is working, the data bus is
> held by the DMA controller and the CPU is set idle until this transfer
> completes.
"CPU set idle" isn't entirely correct. The CPU cannot access the bus
during this time. However, the CPU can continue to operate out of (on-
chip) cache while the DMA is taking place.
>
> However, if we start a time-consuming DMA operation, say, copying a
> large file, we can still do many other things at the same time, say,
> playing a song or drawing a picture. In this situation, it is evident
> that the CPU are not idle, that is, the CPU can still access the
> memory to fetch instructions while the DMA transfer is continuing.
> What text books tell me differs from what I experience, who can tell
> me what the cause is?
In modern system designs, the DMA controller will hold on to the bus
for only a short period. Originally, DMA controllers could relinquish
the bus after each transfer, but as bus speeds increased the the
complexity of the bus protocol increased, grabbing and giving up the
bus became a very expensive process, so most DMA controllers can now
operate in a "burst mode" whereby they hold the bus for some number of
transfers. However, for very large transfers, the "burst size" is
almost always smaller, so the DMA controller will do some number of
transfers (to amortize the cost of acquiring and releasing the bus)
and then give up the bus to the CPU, reacquiring it shortly
thereafter. The CPU's speed may be reduced if it is doing a lot of
bus activity (which isn't that common if the cache is working as
expected), but it won't starve due to lack of bus cycles.
>
> Any help will be highly appreciated. Many thanks in advance!
Note, BTW, that having a two-CPU system (physical CPUs, not just
cores) means that the two (or more) CPUs are fighting constantly for
bus access. Fortunately, caches mitigate this problem.
hLater,
Randy Hyde
| |
| Jerry Coffin 2007-07-21, 3:57 am |
| In article <1184772977.582865.311290@m37g2000prh.googlegroups.com>,
spamtrap@crayne.org says...
> Many relevant books tell me that when DMA is working, the data bus is
> held by the DMA controller and the CPU is set idle until this transfer
> completes.
>
> However, if we start a time-consuming DMA operation, say, copying a
> large file, we can still do many other things at the same time, say,
> playing a song or drawing a picture. In this situation, it is evident
> that the CPU are not idle, that is, the CPU can still access the
> memory to fetch instructions while the DMA transfer is continuing.
> What text books tell me differs from what I experience, who can tell
> me what the cause is?
[ warning: long post ]
Copying a large file isn't a DMA operation, at least in a typical modern
computer. In fact, a typical modern computer (i.e. anything with a PCI
bus) doesn't _really_ do DMA at all!
The ISA bus on the original PC, (and in modified form in the AT) had
separate bit lines to signify what kind of transaction was going to take
place in a given cycle -- a memory read, memory write, I/O read or I/O
write. In a normal situation, only one of these lines was asserted
during a given bus cycle. The DMA controller, however, would assert two
of them -- the I/O read and memory write or the memory read and I/O
write. It would then place addresses on the bus, and you'd get (in a
_single_ bus transaction) a transfer from memory to an output port, or a
transfer from an input port to memory (since it only had a chance to
give one address, it could NOT do a memory-to-memory transfer).
The PCI bus changed that -- it eliminated the separate lines for each
type of transaction, and instead encodes the transaction type. This
means the "trick" that allowed DMA to work just doesn't work over PCI.
On PCI, you mostly have bus-mastering controllers -- each PCI device can
do its own reading or writing independently. They negotiate for control
of the bus, and keep control of it for some length of type, then release
it. A few controllers are slave-only, which means they can be targets of
transactions, but can't initiate transactions themselves. Either way,
however, you don't have a DMA transaction.
On a modern machine you also have a _huge_ disparity between the speeds
of different busses. For example, the normal PCI bus is 32 bits wide and
runs at 33 MHz. For example, a reasonably high-end machine might have
two memory channels, each 64 bits wide, and each running at a data
transfer rate of 800 MHz.
To make up that disaparity, the north bridge normally has fairly good-
sized buffers. When a PCI device requests some data from memory, the
north bridge reads the data from memory at the full memory speed, and
stores the result in its own buffers. The data is then transferred to
the PCI device at the (much) lower PCI speed -- but as soon as the data
has been transferred from the memory to the north bridge, the CPU is
free to access the memory again -- and will probably do so _many_ times
before the data finishes transferring over the PCI bus.
To put things in perspective, consider transferring 1 kilobyte over a
PCI bus. That's 256 32-bit words at 33 MHz, giving about 7.76
microseconds. For a 1 GHz P III CPU, that's enough time to execute
something like ten thousand instructions. For a current CPU (e.g. dual
core, @ ~3 GHz), figure something like fifty to sixty thousand
instructions.
Of course, that's figuring in terms of a PCI device that can handle
transfers at full PCI speed. A transfer to/from floppy disk (for one
obvious example) would be drastically worse. In theory, you could make
up for it (usually) by having a big enough cache on the CPU, but you'd
need a huge cache to do the job for the duration of a floppy disk
transfer -- it's much cheaper to buffer the data for the floppy disk
instead (and as a bonus, that memory doesn't need to be nearly as fast).
--
Later,
Jerry.
The universe is a figment of its own imagination.
| |
| Gil Hamilton 2007-07-23, 7:57 am |
| Jerry Coffin <spamtrap@crayne.org> wrote in
news:MPG.210b2dd65afa7867989938@news.sunsite.dk:
> On PCI, you mostly have bus-mastering controllers -- each PCI device can
> do its own reading or writing independently. They negotiate for control
> of the bus, and keep control of it for some length of type, then release
> it. A few controllers are slave-only, which means they can be targets of
> transactions, but can't initiate transactions themselves. Either way,
> however, you don't have a DMA transaction.
While I don't disagree with any of the detailed explanations you've given,
I do have to disagree with the statement: "you don't have a DMA
transaction". Especially when it seems to give the impression that the
concept of DMA is obsolete.
The term "DMA" simply indicates data transfer between memory and an I/O
device where the transfer is not explicitly pumped word-at-a-time by code
running on the "main" processor. So data transfer initiated by a bus-
mastering controller certainly qualifies as DMA. The data sheets of many
PCI devices also refer to such data transfers initiated by the device as
DMA. Any one of these data transfers might therefore reasonably be called
a "DMA transaction".
GH
| |
| Tim Roberts 2007-07-24, 3:57 am |
| Gil Hamilton <spamtrap@crayne.org> wrote:
>
>While I don't disagree with any of the detailed explanations you've given,
>I do have to disagree with the statement: "you don't have a DMA
>transaction". Especially when it seems to give the impression that the
>concept of DMA is obsolete.
>
>The term "DMA" simply indicates data transfer between memory and an I/O
>device where the transfer is not explicitly pumped word-at-a-time by code
>running on the "main" processor. So data transfer initiated by a bus-
>mastering controller certainly qualifies as DMA.
This is a terminology issue, certainly, but it is an important one, and one
where newbies can get easily  . The PCI spec is very careful to
call this concept "bus mastering", not "DMA". I suspect that's because the
word "DMA" in the PC world has a very specific meaning, and they wanted to
distance themselves from the disappointing performance of the PC's
motherboard DMA.
Another distinction is that a bus-mastered transaction on a PCI bus does
not actually have to involve memory at all. Board-to-board bus mastering
is also quite possible.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
| |
| Gil Hamilton 2007-07-24, 6:57 pm |
| Tim Roberts <spamtrap@crayne.org> wrote in
news:am0ba35nikq613gq0cckhcdene0juk5q8a@
4ax.com:
> Gil Hamilton <spamtrap@crayne.org> wrote:
>
> This is a terminology issue, certainly, but it is an important one,
> and one where newbies can get easily . The PCI spec is very
> careful to call this concept "bus mastering", not "DMA". I suspect
> that's because the word "DMA" in the PC world has a very specific
> meaning, and they wanted to distance themselves from the disappointing
> performance of the PC's motherboard DMA.
>
> Another distinction is that a bus-mastered transaction on a PCI bus
> does not actually have to involve memory at all. Board-to-board bus
> mastering is also quite possible.
While the term DMA may well have certain unfavorable associations in the
PC world, the concept of DMA (and I believe the the term as well) pre-
dated the PC by many years. "DMA" should be understood by the newbie as
the general term for the mechanism whereby some agent relieves the
"central processing unit" of the need to be intimately involved in every
byte of data transfer between "main memory" and other peripherals.
Pretty much every PCI data transfer that is not initiated by the CPU
qualifies as DMA in my view, arguably even a board-to-board transfer:
Consider that each device in order to be used must be assigned address
space that typically comes from the same address space used by main
memory. Post-initialization, the target is always identified by address;
the master doesn't know the difference between a device-target and main
memory.
GH
| |
| Jerry Coffin 2007-07-25, 6:57 pm |
| In article < Xns99764A748485Fgilhamiltonhotmailco@194
.177.96.78>,
spamtrap@crayne.org says...
[ ... ]
> The term "DMA" simply indicates data transfer between memory and an I/O
> device where the transfer is not explicitly pumped word-at-a-time by code
> running on the "main" processor.
I have to disagree with your use of the terminology. There is a
meaningful and useful distinction to be made between DMA and bus
mastering.
> So data transfer initiated by a bus-
> mastering controller certainly qualifies as DMA.
I disagree.
> The data sheets of many
> PCI devices also refer to such data transfers initiated by the device as
> DMA.
They shouldn't.
> Any one of these data transfers might therefore reasonably be called
> a "DMA transaction".
Calling something DMA when it's really bus mastering is about like
calling every dessert you like creme brulee' because you like creme
brulee'.
The basic structure of DMA is different from the basic structure of bus
mastering. In particular, DMA involves three items: memory, a device,
and a DMA controller to carry out a transaction between the two. By
contrast, bus mastering involves only two items: memory and a device
carrying out a transaction with memory.
DMA mostly IS obsolete as a concept. It's an attempt at simplifying each
device by creating a single bus-master that carries out all bus-
mastering transactions on behalf of all devices. When silicon was really
expensive, and systems were really simple, that made sense.
Now, the extra cost of including bus mastering capability in the
individual devices is trivial. Just for example, a generic PCI
controller from OpenCores occupies _barely_ over one square millimeter
of silicon in 180 nanometer fabrication. Most foundries make such cores
available to their customers nearly (if not absolutely) for free. Being
tailored for a specific process, they'll generally be even more
efficient.
The cost of separate controllers is low and continues to fall. A DMA
controller would need to include tremendous capabilities to satisfy the
needs not only of the devices you currently have, but of any you might
choose to add. It would be huge, expensive and cumbersome -- and every
time anybody invented a new kind of device that needed different
transactions, it would become more so (or else performance of the new
device would suffer).
--
Later,
Jerry.
The universe is a figment of its own imagination.
| |
| Jerry Coffin 2007-07-25, 6:57 pm |
| In article < Xns997761DC2E693gilhamiltonhotmailco@194
.177.96.78>,
spamtrap@crayne.org says...
[ ... ]
> While the term DMA may well have certain unfavorable associations in the
> PC world, the concept of DMA (and I believe the the term as well) pre-
> dated the PC by many years.
True, but irrelevant. It's not a question of associations -- it's a
question of accuracy and precision. Calling something DMA when it's
really bus mastering is imprecise at best and inaccurate more often.
> "DMA" should be understood by the newbie as
> the general term for the mechanism whereby some agent relieves the
> "central processing unit" of the need to be intimately involved in every
> byte of data transfer between "main memory" and other peripherals.
NO IT SHOULD NOT! DMA should be understood to mean DMA -- nothing more
and nothing less. I'll repeat: calling something DMA when it's really
bus mastering is just plain wrong. It's like calling every car a
bicycle, just because both cars and bicycles are forms of
transportation.
> Pretty much every PCI data transfer that is not initiated by the CPU
> qualifies as DMA in my view, arguably even a board-to-board transfer:
So you're willing to call something direct memory access, even if it
doesn't access memory at all?
> Consider that each device in order to be used must be assigned address
> space that typically comes from the same address space used by main
> memory.
Not so -- PCI devices _can_ provide a memory-based interface, but most
use I/O space instead.
> Post-initialization, the target is always identified by address;
> the master doesn't know the difference between a device-target and main
> memory.
This isn't true, and even if it was it wouldn't be relevant.
--
Later,
Jerry.
The universe is a figment of its own imagination.
| |
| robertwessel2@yahoo.com 2007-07-25, 6:57 pm |
| On Jul 25, 4:39 pm, Jerry Coffin <spamt...@crayne.org> wrote:
> In article <Xns99764A748485Fgilhamiltonhotmai...@194.177.96.78>,
> spamt...@crayne.org says...
>
> [ ... ]
>
>
> I have to disagree with your use of the terminology. There is a
> meaningful and useful distinction to be made between DMA and bus
> mastering.
>
>
> I disagree.
>
>
> They shouldn't.
>
>
> Calling something DMA when it's really bus mastering is about like
> calling every dessert you like creme brulee' because you like creme
> brulee'.
>
> The basic structure of DMA is different from the basic structure of bus
> mastering. In particular, DMA involves three items: memory, a device,
> and a DMA controller to carry out a transaction between the two. By
> contrast, bus mastering involves only two items: memory and a device
> carrying out a transaction with memory.
I partially (but only partially) agree. Bus mastering is not the same
as DMA, but it can (and often is) used to *implement* DMA. When I
tell my bus-mastering Fibre Channel HBA to send a frame from a certain
set of locations in memory, it more certain does DMA. The bus
mastering PCI(-E) controller is has the required logic to perform the
function of the DMA controller. A bus mastering PCI device can, of
course, do things other than DMA. For example, the random memory
accesses a processor type device might make would be hard to call DMA.
A better analogy would be a Ethernet LAN - it's not a TCP/IP network,
but certainly can be used to implement one (as well as IPX, SNA,
DECNET...).
The number and position of the DMA controllers in the system is
largely irrelevant. When they were expensive, it made sense to share
them. Now that they're cheap, they get built into other stuff.
| |
| robertwessel2@yahoo.com 2007-07-25, 6:57 pm |
| On Jul 25, 4:44 pm, Jerry Coffin <spamt...@crayne.org> wrote:
>
> Not so -- PCI devices _can_ provide a memory-based interface, but most
> use I/O space instead.
In my experience IO space allocations are rare except in devices with
a PC legacy. In any event, IO space addresses are dynamically
assigned in much the same way as memory space addresses.
| |
| Tim Roberts 2007-07-26, 3:57 am |
| Jerry Coffin <spamtrap@crayne.org> wrote:
>
>Not so -- PCI devices _can_ provide a memory-based interface, but most
>use I/O space instead.
I don't think that's really what you meant to say. Virtually no PCI
devices use I/O space unless they have to satisfy some legacy requirement.
That's because the x86 I/O instructions suck performance in the same way a
black hole sucks... well... everything.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
| |
| Jerry Coffin 2007-07-26, 9:57 pm |
| In article <u54ga35em9d4o2pbot16l95ii6fseoeraq@4ax.com>,
spamtrap@crayne.org says...
> Jerry Coffin <spamtrap@crayne.org> wrote:
>
> I don't think that's really what you meant to say. Virtually no PCI
> devices use I/O space unless they have to satisfy some legacy requirement.
> That's because the x86 I/O instructions suck performance in the same way a
> black hole sucks... well... everything.
No, it's not. I started with a longer post, and tried to edit it down to
something halfway reasonable, but in the process changed the meaning. It
was supposed to say something to the effect that they normally use
memory space in a range dedicated to I/O devices, so when/if anybody
cares, it's trivial to detect whether it's a device or normal memory.
--
Later,
Jerry.
The universe is a figment of its own imagination.
|
|
|
|
|