# Does a CPU completely freeze when using a DMA?

I have pretty straightforward question, but I couldn't find an answer to it anywhere.

On a Von-Neumann system where code and data live in the same RAM, the CPU must fetch all its instructions from memory. Now, in order to move large amounts of data between computer components, there is a Direct Memory Access controller that allows peripherals to have access to main system RAM.

My question is this: if the DMA is allowing a (possibly very long) data transfer between, say, the hard disk and RAM, doesn't that mean that the CPU cannot use RAM and therefore can't fetch its next instruction?

In brief, the DMA is meant to replace the processor arbitrating all I/O reads and writes, in order to free up the processor to do other things. However, if it can't fetch its instructions from RAM, then it hasn't been freed up anyway.

Is there some detail that I'm missing here?

Thanks

• Yes. The DMA rarely runs at the full bandwidth of the memory. It just steals a cycle (or a burst of cycles) every now and then, controlled by the rate of the I/O device. – Dave Tweed Jan 19 '16 at 16:39
• The Amiga home computer got around this by observing that the CPU used actually only accessed the bus two cycles, then stayed off the bus for two cycles, when still running at the full speed. The DMA-based peripherals (graphics, audio, disk) used the cycles in between. Not an answer to your question since the question is hypothetical and computers are always ruined by practical details. :) – pipe Jan 19 '16 at 17:41
• @pipe: That doesn't sound right. The Amiga used an M68K CPU, which has a completely asynchronous bus. You might be thinking of the Apple II, which took advantage of the fact that its 6502 CPU only uses the bus for half of each clock cycle, and used the other half for the video output, which also served to keep the DRAM refreshed. – Dave Tweed Jan 20 '16 at 3:29
• Modern CPU's have caches that on average resolve 95% of memory accesses. As long as the CPU doesn't need RAM, DMA isn't interfering anyway. – MSalters Jan 20 '16 at 8:16
• @DaveTweed Nope. If you look at the bus timings for the 68000, each "bus cycle" (read or write) is divided into 8 states, taking a minimum of 4 actual clock cycles, of which only some of them drives the data bus. This multiplexing does require some extra hardware though, because it drives the address bus all the time. – pipe Jan 20 '16 at 9:42

You are correct that the CPU cannot be accessing the memory during a DMA transfer. However there are two factors which in combination allow apparent parallel memory access by the CPU and the device performing the DMA transfer:

• The CPU takes multiple clock cycles to execute an instruction. Once it has fetched the instruction, which takes maybe one or two cycles, it can often execute the entire instruction without further memory access (unless it is an instruction which itself access memory, such as a mov instruction with an indirect operand).
• The device performing the DMA transfer is significantly slower than the CPU speed, so the CPU will not need to halt on every instruction but just occasionally when the DMA device is accessing the memory.

In combination, these two factors mean that the device performing the DMA transfer will have little impact on the CPU speed.

EDIT: Forgot to mention that there's also the factor of CPU cache, which as long as the code that the CPU is executing is in the cache then it won't need to access real memory to fetch instructions, so a DMA transfer is not going to get in the way (although if the instruction needs to access memory then obviously a real memory access will take place - potentially having to wait for a break in the DMA device's use of the memory).

• As an additional approach, some systems may offer multiple channels to access memory. The CPU may be allowed to use one channel while the DMA engine works on the other – Cort Ammon Jan 20 '16 at 0:58
• @CortAmmon I believe that dual-channel memory is usually spread across the physical address space, so for example if you have 2GB of RAM then the lower 1GB is on the first channel and the upper 1GB is on the second channel. In that case, if both the CPU and the DMA want to access the same 1GB area of memory, they will be on the same channel and thus potentially conflict. – Micheal Johnson Jan 20 '16 at 8:38
• I'm not sure if many real systems ever used a true VNM architecture. The bottleneck was just too narrow. It really was a theoretical device used in CS. Closest I can think of was a 1970's Texas 16 bit device that had its registers in RAM. I'm thinking of a graphics card where dual ported RAM is used. Chips like ARM esp the high end ones accomplish the same on the many internal busses (AHP, APB, Stacks). futureelectronics.com/en/memory/dual-ports.aspx idt.com/products/memory-logic/multi-port-memory/… – ChrisR Jan 20 '16 at 9:01
• I didn't think that the question was asking about a strict Von-Neumann CPU but rather a practical one, like the x86 or ARM, which are loosely Von-Neumann. In the case of a strict Von-Neumann, without any internal registers, the ability for the CPU to keep running during DMA comes down to my second point in my answer, that the DMA is not using the entire memory bandwidth. – Micheal Johnson Jan 20 '16 at 14:38

If there is a single memory interface, there would be hardware to arbitrate between requests. Typically a processor would be given priority over I/O without starving I/O, but even with I/O always having priority the processor would have some opportunities to access memory because I/O tends to have lower bandwidth demands and to be intermittent.

In addition, there is typically more than one interface to memory. Higher performance processors typically have caches (if DMA is not coherent, the caches do not even have to be snooped; even with snooping, overhead would generally be small because of the bandwidth difference between cache and main memory or (when the DMA transfers to L3 cache) between L3 cache and L1 cache), providing a separate interface to access memory. Microcontrollers will often access instructions from a separate flash-based memory, allowing fetch to proceed during DMA to on-chip memory, and often have tightly coupled memory with an independent interface (allowing many data accesses to avoid DMA conflicts).

Even with a single memory interface, the peak bandwidth will generally be higher than the bandwidth typically used. (For instruction fetch, even a small buffer with wider than average fetch loading from memory would allow instruction fetch from the buffer while another agent is using the memory interface, exploiting the tendency of code not to branch.)

Also note that because a processor accesses data, if there is a single memory interface, there must be a mechanism for arbitration between data accesses and instruction accesses.

If the processor (with a single memory interface) was forced to implement a copy from an I/O device buffer to main memory, it would also have to fetch instructions to perform the copy. This could mean two memory accesses per word transferred even in an ISA with memory-memory operations (a load-store ISA could require three memory accesses or more if post-increment memory addressing is not provided); that is in addition to the I/O access which in old systems might share the same interface as main memory. A DMA engine does not access instructions in memory, and so avoids this overhead.

Since there is only one bus system, which is blocked by the memory access of the DMA, the CPU can not work whilest the DMA is moving data and is therefore halted.

The idea behind this is the following:

If you want to copy consecutive data from memory, then the CPU would have to do something like that:

Whereas the DMA does the calculation of the new address in parallel (depending on mode) and is therefore faster. So the DMA can work at full bus throughput (theoretically).

• "since there is only a single bus system" ... not a safe assumption to make with modern computers that have their memory and peripheral buses running on different speed, and with protocol translation happening between them. – rackandboneman Jan 19 '16 at 20:52
• On older computers: There was a design oversight in the Apple II (or some predecessor/prototype of it?), in that they literally halted the CPU. The registers in a 6502 are implemented as dynamic memory. The way they halted the CPU stopped the refresh dead. Maximum DMA length ended up very, very machine dependent. – rackandboneman Jan 19 '16 at 21:03
• Since the question was about von neumann architecture and DMA this sounds more like a question concerning microcontrollers (then again harddisks are mentioned in the example). Also as Paul A. Clayton points out it gets even more complicated when you consider multilevel cache. One could also think about a cpu where multiple opcodes are contained in a word and are executed after another or cpus with own cache, where there would be code the cpu could execute, but the output had to be buffered... so yes you are right there are endless possibilities. – NeinDochOah Jan 19 '16 at 21:58

Generally speaking, no.

In most system architectures, all requests for memory access have a priority assigned to them. When there are more simultaneous requests for memory than the system can handle at a time, requests with a higher priority are serviced first. Memory requests initiated by the CPU are usually given the highest possible priority.

In general no.

Some systems sure, only one master at a time. A bit of an older design if that is the case (even old designs often had parallel solutions). A modern type of bus though each bus (address, write data, read data) operate independently and have a tag or id per clock cycle to show what transaction that one clock cycle is associated with. So you can have many/lots of transactions in flight at the same time in both directions, with different transactions shuffled together on the read or write data busses. Who gets to go next would be priority based, there is no rule that the transactions on the bus would have to go out in the order that the software instructions are laid out, the processor may determine it can start some earlier than others, and naturally responses are going to come back in different orders as well depending on how near and fast the target is. Likewise fetches are not in order, branch prediction fires off random looking fetches whenever it feels like.

A large dma transaction would require a lot more bus bandwidth sure, but to say that the processor stalls, not necessarily the case, also depends on the architecture and the code. The code may have an instruction that say stall until this end of transfer signal/event happens, and then sure the processor will finish up what it can do in the pipe and then stall. But that or some architectures may not require you to stall, not really wise to stall anyway, so much wasted bandwidth. What would be the point of dma anyway if it doesnt operate in parallel, just code the transfer in a loop, fetches add some cycles maybe depending on the architecture they are not as costly as the dma logic overhead, power, etc. Understand how the dma works for the particular architecture and system you are on and the decide if it is even worth using, sometimes it saves a few clocks even if it does stall you, often if well designed it slows down your main software a little but fills in all the wasted bus cycles that you werent doing anything and is more free than costly.

There is no generic answer for how dma works, it is heavily dependent on the system design and all the components within the system.