Friends,

I am in the process of designing a GPL DMA controller that would operate on a Wishbone bus. I've built things long enough and often enough to know that the success of any design is dependent upon a good design. Therefore, I would like to propose the design of a wishbone DMA controller below, and open the design up for comment.

• The controller would operate on a 32-bit wishbone bus, and move 32-bit words around.
• The controller would be controlled by 4 register settings:
  1. A control/status register
  2. A length register, controlling how much data the user wanted moved in total
  3. A source register, containing the initial address to read from, and
  4. A destination register, containing the initial address to move data to.
• It would operate in one of two modes:
  1. The first would be analogous to a standard library memcpy except that by using pipelined wishbone accesses it should be able to move one word per clock.
  2. The second mode would copy memory once an external bit signaled the memory copy. This might be useful, for example, if the external bit was a data available bit--such as a serial port signaling that it had just read data, or an analog sample was available from an ADC, or some other such.
• Addresses would either increment or stay the same on every access, allowing such things as multiple reads from a single hardware port in the address space.
• The control register would have 10 bits reserved for a unique key, so that it would not start copying until issued a command with these ten bits set to that key. Reading from the register would be guaranted to return something other than the key, and the key would be posted in the spec sheet.
• It would have an input wire indicating that some other component, with priority over this one, wished to use the bus and it would relinquish the bus on such a request.

Your thoughts? Have I forgotten any important modes or features?

Thanks,

Dan

Great idea!
Would be really nice if it had a facility to walk a memory table/chain from
which to load Word-Count, From-Address, To-Address.
This can be very useful for loading data such as video rasters which may
not be in contiguous memory.

Regards,

Lee.

Hi,

You could take a look at my wb_streamer component https://github.com/olofk/wb_streamer

It's a streaming DMA that reads or writes a chunk of memory over WB and writes/reads a stream, so it's not a full DMA. The intention however is that it should be possible to turn it into a full DMA by connecting the stream ports of a reader and a writer.

It's been used quite a lot in different applications and has testbenches, so feel free to use whatever parts of it that you want

Cheers,
Olof

Lee,

Thanks for the feedback! I had seen others do something similar, but couldn't see a reason to do so. Still, I wonder if this wouldn't be a better add on to the DMA module I'm building rather than a change to the core module itself?


Olof,

Thank you for sharing! Yes, I took a look at it this morning and may take another look or two before I'm done. Having built pipeline wishbone interactions before, though, I was a little surprised that you tied the CYC and STB lines together. I have been sending STB high until my transfer length is complete (STB high and STALL low for the number of transfers I'd like), and then waiting until I had received one ACK bit per transferred item before dropping CYC. Would you know if the WB spec is specific to which approach you take?

Thanks,

Dan

Actually, I haven't used the pipelined wishbone stuff. Part of the reason is that the b4 revision of Wishbone has some problems. The people who wrote the b4 revision removed the previous copyright statements from the specification and suddenly made it illegal to use the document in many ways that was previousy allowed (such as distributing parts of the file, etc). The original Wishbone maintainer has also called for withdrawal of this revision since he wasn't at all told about the new revision. With that said, I think b4 is useful as it solves some of the problems with CDC.

So for b3 mode, I think my implementation is correct, but it would need some adaptations for pipelined mode

//Olof

Olof,

Thank you for pointing me to the B3 spec. I had seen it before, but never read or studied it before, since I figured it had been superceded by the B4 spec.

Your comments about the B3 vs B4 and copyright issues, though, have me somewhat worried. Should I be worried about the legality of using the B4 specification in any open cores work? Will these copyright issues prevent any updates to the standard/specification document? Is there any documentation I can read up on to understand the issues you just highlighted?

Further, now that I have reviewed both B3 and B4 versions, it appears as though B4 allows multiple transactions to be in flight at once while B3 only allows a single transaction on the bus at a time. I've actually used the multiple transactions in flight feature once here--it was the only way I could make the pipelined reads and writes work on my Quad Spi Flash implementation after stuffing too much logic on the bus. If you've never used pipeline WB access, I might commend it to you.

That is ... if there are no hidden legal restrictions on the B4 spec ...?

Dan

You can find my first draft of this DMA controller here. The spec has been merged into the Zip CPU spec, and spread across the Peripherals chapter and the Registers chapter.

The DMA controller is designed to be compliant with the Wishbone B4 spec, and particularly the pipelined mode of that spec found in section 3.2 (single read/write) and 3.3 (more importantly, block read/write in pipeline mode). Peripherals that do not support pipeline operation will need to adjust their STALL lines appropriately. (See the Wishbone spec sections 5.2 and 5.3 for more details.)

Although placed within (and integrated into) the Zip System, the controller is not dependent on the rest of the system. If anything, it is available for use by the rest of the system. I say that to say, if you are interested in using this controller, please feel free to pull the wbdmac.v file and try it yourself in your own project. (See the file for the traditional GPL caveats. Other licenses may be available, contact me if you need them.)

Lee,
Since part of my purpose in the Zip CPU is to be light weight, I held off on the multiple DMA stack. I still might go back and implement it, but I think if I do it will be a separate module.

Comments are always welcome,

Dan