Welcome, Guest. Please login or register.

Author Topic: question about DMA  (Read 4847 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline billtTopic starter

  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 910
    • Show all replies
    • http://www.billtoner.net
question about DMA
« on: September 09, 2011, 04:17:56 PM »
Hi all, I'm taking a graduate class in microprocessor systems, and last night's discussion included DMA. And in particular, something about DMA that seems different than what I've always assumed DMA to be or do. We all know that DMA has the peripheral, a serial port, a SCSI drive, whatever, talk direct to memory, so the processor s not involved with that data transfer.

Now, I've always assumed that this means the processor can go off and do something else productive.

But last nights discussion defined DMA as an operation that does a data transfer faster than the processor can, because the processor needs to read from source into a register and then write it back to destination, increment a transfer size counter, do a compare to know if it's finished before moving on to the next unit. The DMA can do the counter and compare in hardware pretty much instantaneously on each transfer unit, compared to the processor needing to use instructions and thus instruction time to do the same thing. And this discussion said that while the DMA controller is doing this, the CPU is idle, waiting for DMA to complete. The processor is not off doing something productive at all. This is partly because that it would at least be colliding with each other on bus usage, as apparently things are expected to be on the same bus.

OK, thinking in terms of Amiga Classics, we have the split between chip and fast memory. Can the chipset do DMA in chip mem whlie CPU does stuff in fast mem, all at the same time? Or do they need to interleave and share the bus, so no one is really going at full speed on any bus?

Also thinking about the ARM chips I'm involved with at work, I'm not sure you would consider that to be a single bus. The AHB goes through a "matrix", and things go through huge multiplexors leaving me to believe that any AHB master can get to a different slave. So one master takes a different route through the matrix to it's slave than another master does, and thus they are not competing for the same bus, and thus each master can go full speed.

It also seems like this processor waiting for the CPU could be a waste in that I know our ARM has DMA capable serial ports, which seem rather slow to me. It seems that even if all things were on the same bus, the CPU could be doing useful stuff on the bus in between serial port DMA cycles on the bus.

I just was surprised about some of these details, and wanted to see some discussion from Amiga gurus that know how this stuff works elsewhere.
Bill T
All Glory to the Hypnotoad!
 

Offline billtTopic starter

  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 910
    • Show all replies
    • http://www.billtoner.net
Re: question about DMA
« Reply #1 on: September 12, 2011, 09:17:21 PM »
Well, prof says that it's a general definition that the CPU goes idle until DMA completes. He did say that additional circuitry could be added to be smart about sharing bus cycles, but that such added complexity may not be worth while, and is often not done. But, a couple of references:

Section 4.1.2 of Wolf's book Computers as Components (not required for the class but is suggested reading) suggests that the CPU could be doing things independently until it needs the bus again

And section 4.6 of Microprocessor Theory and Applications with 68000/68020 and Pentium which I found while searching, suggests a few methods to divvy up bus cycles with the CPU rather than completely take it over. (cycle stealing and interleaved)
Bill T
All Glory to the Hypnotoad!
 

Offline billtTopic starter

  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 910
    • Show all replies
    • http://www.billtoner.net
Re: question about DMA
« Reply #2 on: September 13, 2011, 07:29:08 PM »
This course is more about embedded computers than desktops, and perhaps there's a bit of context influencing things in that distinction, I'm not sure. For the class lab assignments we're programming a Rabbit 3000 board, 8-bit stuff. But still, I just had to try and find some information about these things.

One of the examples I think of is the DMA on two serial ports in our ARM chip at work, which we're designing into an SOC. It seems the ARM goes a lot faster than serial ports, at least the serial ports when I had a modem, and I do realize that speeds have increased there far beyond what I ever used.

But, with a serial port doing DMA, it seems the CPU could have a few bus cycles between each serial port DMA bus cycle to do something else. Even with two serial ports each doing its own DMA, it would seem the CPU could have some free bus cycles to make use of. And that's ignoring internal caches.

Perhaps there's things that do saturate the bus for DMA, I suppose a big Gb ethernet or SATA transfer might be capable of that, or USB3. And that I can accept, that some things really do not leave any free cycles for the CPU until DMA is finished. But it seems like some things can be slow enough that sharing the bus (each for its own cycles of course) is possible, and in my/our minds, worth doing.

And I don't think that it makes sense to DMA no matter what. There is some overhead involved in configuring the DMA controller, telling it where to read from, where to write to, and how many times, to increment or not (If you're reading from a serial port for example, you're probably only reading from a single register every time, memory of course would increment to next address for every cycle). A single cycle DMA probably won't make any sense to do. It would need to be a transfer larger than your overhead cycles to begin being worth it I think.

For the very little DMA software I've written or looked at recently, the CPU does wait for DMA to complete. But this is a case of simulating the chip RTL before silicon, to make sure we have the DMA controller hooked up correctly inside the chip. There's nothing else to do but wait for the test results. There's no applications, no GUI to update, no OS, nothing else at all. I don't consider that a normal situation in writing software around a DMA controller.

I was just really surprised that I was the only one surprised by this detail in class that day. Thank you for making me feel like I'm on the sane side of this debate. :)
Bill T
All Glory to the Hypnotoad!