Understanding DMA

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
What I understand about DMA is that the CPU is idle during DMA cycles.
If this is true whats the use of DMA. I cant find the advantage of
'offloading' the data transfer to the DMA controller if the CPU cant
use that time to do something else . My 2nd question is : Lets assume
that the CPU is not idle during DMA cycles. In that case, the cpu cant
access memory so it cant fetch instructions/data so how does it do
useful work?
thanks


Re: Understanding DMA
Quoted text here. Click to load it

OK, let's assume we're comparing a DMA
transfer verses a programmed I/O transfer.
To transfer a byte with DMA, the only
bus cycles we need are to put a source
address on the bus, latch the source data
put a destination address on the bus, and
strobe the data into it.  4 cycles, ignoring
any wait states or syncronization issues.
The transfer count register needs to be
incremented, but that doesn't need a bus
transfer (unless, of course, it's an ancient
class of minicomputer).

Compare that to a programmed I/O tranfer.
Each instruction in the tranfer program
loop needs to fetch an opcode.  In an I/O
to memory transfer, the I/O address would
likely have to be fetched inside the loop
as well.  Cycles would also be needed to
keep the transfer count, and a conditional
jump (usually a huge cycle eater) would
have to be executed at the end of the loop.

A good block transfer instruction will
negate many of these cycles, but you'll
still be stuck with the latency time to
start the block transfer.

DMA really shines is in applications where
a *block* of data must be read/written with
very low latency at indeterminite times.


Re: Understanding DMA

Quoted text here. Click to load it


Your understanding is only partly true.  The CPU doesn't necessarily have
to be idle during DMA cycles, just not contending for the bus.  And this
doesn't happen for the entire data block, just byte by byte (or word by
word, or whatever burst your system uses).

Typically DMA cycles fit "in between" CPU memory access cycles.  CPUs do
other things besides reading and writing to memory, particularly ones
with onboard cache (although this raises other issues about mem. access).

Of course, if you are the system designer, you design memory access in
pages,
such that you are DMA-ing into one page while the processor code runs in
another, and avoid conflicts completely.

DMA does also not necessarily run at processor speed.  You could have a
device that is delivering, say, 1 byte per microsecond, while your cpu
is on a 100ns clock.  You may get several instructions between DMA
accesses.  Use this time for "useful" work.

You can google for more info.

Rufus



Re: Understanding DMA
Quoted text here. Click to load it

Depends on the CPU.  The CPU might be running out of cache, in which
case the DMA doesn't affect it.  The DMA ties up the bus, but not
necessarily the processor.

Quoted text here. Click to load it

Many DMA controllers can transfer a full word of data from a peripheral
to a memory location in a single memory cycle, or perhaps two memory
cycles.  The CPU would usually take more cycles than that because it
would also have to fetch the instruction(s) used for the transfer.
Also the CPU would either be tied up for the duration of a transfer
"busywaiting", or it would have to take interrupts to transfer each
word (or group of words).  The interrupt overhead would be non-trivial.

Re: Understanding DMA

Quoted text here. Click to load it

There may also be more than one bus on some systems.

--
Darin Johnson
    The opinions expressed are not necessarily those of the
We've slightly trimmed the long signature. Click to see the full one.
Re: Understanding DMA
Quoted text here. Click to load it

DMA cycle: straight from source to destination (device->memory say). One
operation, the processor can be in a completely unrelated part of the
program.

Non DMA: Processor fetches from source, then writes to destination
(unless your processor is something like a Texas 9900 with memory- to-
memory instructions). 2 operations. Also requires you to be executing
the relevant bit of the program - so if it has to take place at a
certain time or in response to a trigger, there's also the overhead of
an interrupt.

Quoted text here. Click to load it

If it needs to access the bus, it has to wait, or the DMA transfer has
to be suspended. Same with any other multi- master bus.

On old fashioned, slow buses like the 6809, there were parts of the
processor cycle when it was guaranteed that the processor would not be
accessing the bus, and DMA made good use of those dead cycles.

Paul Burke

Re: Understanding DMA
Quoted text here. Click to load it

All the Motorola 8 bit micros from 6800 up to 6809 at least all used a
synchronous bus and themicro only ever accessed memory during one half
cycle of the E clock. In the other half cycle you could DMA if you wanted
to without affecting the processors operations at all. Don't know if they
retained it in the 68K and upwards but it was a really powerful technique.

Ian
--
Ian Bell

Site Timeline