DMA Ack Signals ??

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi folks,

now that my NGW board is supposed to arrive during the next days, I start to have some closer looks on the AP7000 datasheet.

One thing that is puzzling me is that I don't find any DAM acknowledge signals (pins). There are DMA request pins and dma_ack is mentioned in the DMA section of the datasheet, but I seem to be unable (or too blind) to find where the acknowledges come out of the chip. Are they multiplexed to some PIO pins? Which ones?

Greetings from Berlin, Germany,
Stefan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've not used that mechanism, but ... surely once the DMA access has been performed, that suffices? It's going to do some kind of EBI address cycle to read or write a byte (or whatever) of data. That will complete, using the normal bus handshake; QED. Yes?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ummh, yes. :-)

Sometimes one seems to be stuck in "traditional thinking" expecting things to be done "as usual".

But then: to decode the access to the peripheral to take it for DMA Ack could cost a lot of extra pins on a CPLD/FPGA in future own designs (especially when the peripheral expects/has only a DACK pin).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would love some clarification as to how external DMA is supposed to work indeed as, IIRC, hard drives can only be connected in PIO mode due to exactly this lack of DMA_ACK signals available to the outside world.

Seems a silly and serious oversight if the most commonly used externally-DMA'able hardware cannot be used!

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What can I say ... I don't work with IDE, and wouldn't expect any flexible DMA mechanism to be IDE-oriented.

The handful of times I've worked with external DMA request lines, they have not needed any ack. Admittedly the chips did incorporate address bus decode logic, and their DMA request logic was explicitly "assert while ready" for another byte transfer. The tricky bits were how to make burst access modes work on that bus. That was at least clear when the data transfers were polite multiples of the bus width ... but for fractions of that width (1 byte, 3 bytes, etc), or for "short" transfers (CPU reads less than the best burst size) things got annoying.

I don't recall whether the DMA controller in the ap700x (from Synopsis) supports block requests ... e.g. the request pin signals that another 512 bytes should be read or written, vs just one more byte.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fair 'nuff, makes sense.

Given that all _internal_ dma'ness uses ACKs still seems a little bizarre not to route one or two of them to the outside world.

Just my $0.02

-S.