How does a DMA controller work?

Question

From Section 5.1.4 Direct Memory Access in Modern Operating Systems by Andrew S. Tanenbaum, Herbert Bos, 2014,

To simplify the explanation, we assume that the CPU accesses all devices and memory via a single system bus that connects the CPU, the memory, and the I/O devices, as shown in Fig. 5-4.

1. To explain how DMA works, let us first look at how disk reads occur when DMA is not used.

   • First the disk controller reads the block (one or more sectors) from the drive serially, bit by bit, until the entire block is in the controller’s internal buffer.
   • Next, it computes the checksum to verify that no read errors have occurred. Then the controller causes an interrupt. When the operating system starts running, it can read the disk block from the controller’s buffer a byte or a word at a time by executing a loop, with each iteration reading one byte or word from a controller device register and storing it in main memory.

   Q: in the second step,

   • isn't the data transferred "from the controller's buffer" to the main memory? Why does it say both "from the controller’s buffer" and "from a controller device register"?

   • in the second step, can the controller transfer data from its buffer to the main memory, without interrupting to the cpu, and without involving OS again?

2. When DMA is used, the procedure is different.

   • First the CPU programs the DMA controller by setting its registers so it knows what to transfer where (step 1 in Fig. 5-4).
     It also issues a command to the disk controller telling it to read data from the disk into its internal buffer and verify the checksum.
   • When valid data are in the disk controller’s buffer, DMA can begin. The DMA controller initiates the transfer by issuing a read request over the bus to the disk controller (step 2). This read request looks like any other read request, and the disk controller does not know (or care) whether it came from the CPU or from a DMA controller. Typically, the memory address to write to is on the bus’ address lines, so when the disk controller fetches the next word from its internal buffer, it knows where to write it. The write to memory is another standard bus cycle (step 3).
   • When the write is complete, the disk controller sends an acknowledgement signal to the DMA controller, also over the bus (step 4). The DMA controller then increments the memory address to use and decrements the byte count. If the byte count is still greater than 0, steps 2 through 4 are repeated until the count reaches 0.
   • At that time, the DMA controller interrupts the CPU to let it know that the transfer is now complete. When the operating system starts up, it does not have to copy the disk block to memory; it is already there.

   Q: in the second step, the DMA controller requests the disk controller to transfer data from the disk controller's buffer to the main memory. In the first step, the CPU issues a command to the disk controller telling it to read data from the disk into its internal buffer. At the same time, can the CPU also tell the disk controller to transfer data from the disk controller's buffer to the main memory, when the disk controller finishes transfer data from the disk to the disk controller's buffer, so that there is no need for the DMA controller to tell the disk controller to transfer data from the disk controller's buffer to the main memory? (I can't understand why we need a DMA controller for data transfer between the disk and the main memory, so guess that I miss something important to understand the quote).

3. A device controller of a device controls the device and performs operations on the device. What device does a DMA controller control and perform operations on?

Thanks!

Answer 1

Q1

In the first step, we're NOT using DMA, so the content of the disk controller is read piece by piece by the processor. The processor will of course (assuming the data is actually going to be used for something, and not just being thrown away) store it in the memory of the system.

The buffer in this case is a piece of memory on the hard-disk (controller) itself, and the controller device register a control register of the hard-disk (controller) itself.

Not involving the OS (or some other software) would require some kind of DMA operation, and the section of text you are discussing in this part of your question is NOT using DMA. So, no, it won't happen like that in this case.

Q2

So, the whole point of a DMA controller is to "perform the tedious task of storing stuff from the device's internal buffer into main memory". The CPU will work with both the DMA controller and the disk device. If the disk could do this itself, there would be no need for a DMA controller.

And indeed, in modern systems, the DMA capability is typically built into the hard-disk controller itself, in the sense that the controller has "bus mastering" capabilities, which means that the controller itself IS the DMA controller for the device. However, to look at them as two separate devices makes the whole concept of DMA a little less difficult to understand.

Q3 (kind of)

If you think of the hard disk as the stack of bricks just delivered to a building site, and the processor is the bricklayer that lays the bricks to build the house. The DMA controller is the labourer that carries the bricks from the stack of bricks to where they are needed for the bricklayer, meaning that the bricklayer can concentrate on doing the actual work of laying bricks (which is skilled work, if you have ever tried it yourself), and the simple work of "fetch and carry" can be done by a less skilled worker.

Anecdotal evidence: When I first learned about DMA transfer from disk to memory was about 1997 or so when IDE controllers begun using DMA, and you needed to get a "motherboard IDE controller" driver to allow the IDE to do DMA, and at that time, reading from the hard-disk would take about 6-10% of the CPU time, where DMA in the same setup would use about 1% of the CPU time. Before that time, only fancy systems with SCSI disk controllers would use DMA.

Answer 2

This is not an answer; it is a request for clarification that's too long to fit in the comments.

Before anyone can answer this question, one has to explain clearly the computer system architecture that is being discussed. Namely:

• What are the bus systems involved in this description?

  • Most computer systems have a memory bus.
  • Most computers have other kinds of bus systems as well.

• Does the disk IO go through the memory bus also?

  • In other words, does the disk uses the address bus lines for addresses, and the data bus lines for data?

• Does the disk controller sees the memory bus as ...

  • A memory bus? That is, it thinks it is talking to a memory chip; i.e. RAS (row access strobe), CAS (column access strobe), ...
  • Very unlikely - talking to a memory chip requires one to be ultra-precise about issuing commands according to DRAM timing (latencies) - a few clock cycles too early or too late, data loss will occur.

• So ... what does the disk controller thinks the bus "actually is" ?

• In most computer systems, there is a kind of IO called "Port I/O".

  • Port I/O may either piggyback on to the memory bus, or they may have another dedicated bus.
  • The distinctive feature of Port I/O is that one can finish things in a single (or a predefined constant number of) bus cycle - no need to worry about the dangers of DRAM timings.

• In more advanced (well, since two decades ago) systems, there are newer types of bus systems. For example, ISA, PCI, AGP, PCMCIA ... SCSI, ATA, SAS, SATA, FC-AL ...

---

Now, with so many uncertainties being raised about "the computer system that is being discussed", you can understand why you won't get a clear answer for your question.

Yes, I know that it comes from a textbook. You have a copy. I don't. (Not at home - there's one in the office, though.) Therefore, if you need an answer, you will need to show some diagrams and explain what your computer's bus system looks like.

---

At the very bottom line, though:

• A DMA is a programmable device. That is, the CPU has the ultimate responsibility of telling the DMA what to do. Of course, during the time slot where the DMA takes over the system, the CPU will cooperate by letting the DMA run the show.

• Under the control of the CPU (and the OS that runs it), a DMA has the ability to take over control for one or more bus (plural) in order to facilitate the transfer of data from the disk controller to the main memory.

• During the timeframe where the DMA takes over the bus (plural), the DMA will issue commands over that bus - i.e. in place of its usual controller, i.e. the DMA pretends it is doing the CPU's work.

• If the data transfer involves two different bus, the DMA may have to do this to different bus.

• To be able to move a number of bytes (words, etc), the DMA contains a loop counter for keeping track of the remaining amount of data to be copied.

• To be able to write to the main memory, the DMA contains a memory address register, which is programmable by the CPU, so that the CPU can tell the DMA where to write the data to.

• Depending on the system's bus design, the DMA may or may not have to deal with the gruesome detail of DRAM timing cycles.

• Once upon a time, some time after DMA has been invented, some peripheral devices start to pre-package DMA onto their controllers - this is called Bus Mastering. Still, whether the DMA sits on the CPU package, the motherboard, or the I/O card, it must be ultimately under the control (programming) of the CPU, because they must somehow negotiate access to the system bus (plural), and the main memory.

• Modern computer systems have a dedicated subsystem called the DRAM Controller. If there is one, it is almost certainty that this DRAM Controller will also fulfill the functionality of DMA, that is, it looks like it's a programmable "byte copying loop", and all of the aforementioned complexity is hidden inside the silicon of the DRAM Controller.

---

If you find it very confusing - I find it confusing too - you will need diagrams. Lots of diagrams. System diagrams. Bus diagrams. Timing diagrams. State transition diagrams. etc.

---