We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Showing results for 
Search instead for 
Did you mean: 
Visitor mdxg
Registered: ‎11-09-2017

Using AXI DMA to read and write DDR with custom IP

Hey everyone,


I'm trying to design a system with linux and a custom IP for data processing. The linux site provides the

data and writes it to the DRAM. From there I want my IP to read directly from the DRAM with help of the AXI DMA. I wanted to create some kind of zero copy communication. My IP has the necessary AXI Stream interface and

is able to connect to the S2MM and MM2S ports. The problem is I don't exactly understand who coordinates the AXI DMA over the AXI Lite interface. My IP could possibly do that but to make that possible I need to add some kind of state machine

that does a lot of sequential register write and read. I would prefer to control the DMA from the PS site. What I read so far about the DMA implementation in linux shows that most drivers are designed to move data between the ps and custom IP

or memory and not to coordinate data flow between two instances in the PL. 


Did somebody design something similar or could you point out where I'm missing something?

Thanks for your help in advance



5 Replies
Visitor amohant4
Registered: ‎02-07-2018

Re: Using AXI DMA to read and write DDR with custom IP



Were you able to get a solution to this problem ?



0 Kudos
Visitor vineeshvs
Registered: ‎11-26-2018

Re: Using AXI DMA to read and write DDR with custom IP

Interested to know the solution.

0 Kudos
Registered: ‎02-01-2013

Re: Using AXI DMA to read and write DDR with custom IP

DMA (Direct Memory Access) is an activity. The abbreviation is often used to describe a device or entity that is capable of performing DMA. DMA refers to the action by a non-processor device of moving data into or out of memory--all by itself. That means a DMA-capable device has at least one interface that allows it to access memory, in order to perform reads or writes, or both. The DMA activity is meant to unburden a system processor from having to move data for that device. DMA is usually used to move large gobs of data, but even can be used to move a single byte.

General DMA machines are flexible devices that can be configured to move data from one place in memory to another place in memory. Most DMA devices have a special usage, however, and generally might only fetch data from memory for a particular purpose, or place newly calculated, or newly received, or newly captured data into memory.

The processor is the most flexible device in the system. The processor (or, more accurately: the software running on the processor) knows when data needs to be moved, from where it needs to be moved, to where it needs to be moved, and how much needs to be moved. The processor sets up DMA activity, flips a switch, and then whoosh--the data gets moved while the processor does something else with its cycles. Something important--like calculating pi to a few more decimal points...

The point is: it's the system designer who is the one who partitions system functionality and assigns responsibilities between the software and the hardware. It's during this partitioning stage that the need to move data is identified, and an appropriate DMA device is selected to be part of the system. The job of identifying when data needs to be moved during the operation of the system is often left to software. An interrupt event (or a successful polling event) usually initiates an activity that results in the processor determining that a data movement is required. The processor then configures the DMA device to move the data.

On the other hand, some DMA devices can be quite autonomous. I'm currently working on a system that DMA's data received from several A/D devices into system memory over a PCIe interface. All software has to do beforehand is set a control bit, and then the hardware does the rest. Of course, automation like that is rather tough: a lot of decisions must be made up front and plans to deal with hiccups and exceptions must be pre-planned.

I hope this helps.

-Joe G.


Xilinx Employee
Xilinx Employee
Registered: ‎10-04-2016

Re: Using AXI DMA to read and write DDR with custom IP

Hi @mdxg,

I'll get a little more specific about the excellent background @jg_bds provided.

As long as you provide a valid physical address to AXI DMA, its memory mapped interfaces can read or write data to that address. This can be PS DDR, PL DDR or PL BRAM, for example.

When you use the Linux driver, the A53 processor (I'm assuming you are using a Zynq MPSoC device) is responsible for configuring the AXI-Lite interface of the AXI DMA to kick off DMA transfers. 

You might find this Wiki entry helpful when developing the application that uses AXI DMA.




Don’t forget to reply, kudo, and accept as solution.
Visitor mdxg
Registered: ‎11-09-2017

Re: Using AXI DMA to read and write DDR with custom IP

Hello you all,


it been quite a while and I didn't notice there is some activity. First of all thanks for the helpful responses. In the end I finished the

project very differently to the original idea. 

The main function of my ip is a special kind of cache which is aimed towards a special access pattern. Inside the ip the storage is realized

by a bigger bram block. To transfer data between the bram and the actual dram I still use a DMA. It turned out

to be simpler to use a CDMA, which is memory mapped to memory mapped, instead of a DMA, which is mm2s and s2mm.

The name DMA here refers to the xilinx provided ip block and not the principal of the activity. 

Using the ps to activate memory transfers turned out to be too slow. Not even the actual transfer or the configuration

but more the time that passed until the ps recognized the need for a transaction, interrupt etc.. 


During system testing I did use the ps directly to start transactions. I wrote an entry in the device tree and marked the cdma as generic-uio device.

This way I could access the register space of the axi light interface. In the end all (C)DMA transaction were started either by hardware or via

c code that used the generic uio driver.


The new entry in the wiki is really good. It seems to me that the wiki really did improve a lot. For future projects I would definitely stick to the

solution described in the wiki article. Thanks @jg_bds for the explanation and @demarco for pointing to the article