Understanding DMA

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.

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

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.

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.

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.

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

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

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