11-12-2012 07:25 AM
I'm trying to set up a very simple DMA transfer to a slave module that can be expanded later once the framework is in place, but as so often happens when implementing an unfamiliar module, I'm running into some roadblocks. Maybe someone here can help shed some light on what I may be doing or not doing that's causing me problems. Thanks in advance for any advice! I'm using the 64-bit install of 14.3.
Here's what I'm doing:
-- Open XPS.
-- Add an AXI DMA controller to the design.
- In the Core Config dialog:
- DMA Common Options: Uncheck "Include Scatter Gather Engine" (for simple DMA mode)
- DMA Common Options: Check "Interface a Custom IP"
- MM2S Channel Options: Set "Maximum Memory Map Burst Size for MM2S" to 256
- S2MM Channel Options: Uncheck "Include S2MM Channel"
- Click OK.
- Select processing_system7_0, High Performance Mode. Click OK.
-- The AXI DMA should cause a new AXI bus to be added to the project.
-- Generate a custom IP that uses the AXI4-Stream bus. Add it to the project. There shouldn't be any configurable options in the Core Config dialog.
-- The custom IP has a bus called "S_AXIS". In the Bus Interfaces tab, connect the custom IP's "S_AXIS" bus to the AXI DMA's "M_AXIS_MM2S" bus.
-- In the Ports tab, connect the custom IP's ACLK port to the appropriate FCLK_CLKx .
-- Run a Design Rule Check. An error is generated because the ARUSER address bus size is not automatically handled correctly, so in Bus Interfaces, right-click on the particular AXI interconnect that is generating the error and select "Configure IP". In the "General" tab, change "Read Address User Signal Width" to 4. Click OK.
-- Run a Design Rule Check again. A warning is generated that indicates the AXI DMA reset from the AXI bus is not being driven, so the this port is driven to ground. However, this will hold the entire module in permanent reset!
When I write to the configuration registers to initiate a DMA transfer via this module, I see in ChipScope that the TVALID signal toggles high in my user IP slave module but nothing else happens. I also see that the "slave error" bit (bit 5 in reg MM2S_DMASR at offset 0x04) gets set, and that the "AXI DMA Halted" bit is also set as a result of the slave error. I think this is related to the disconnected state of the AXI DMA's ARESETN port driving the module into a reset state. How can I correctly connect this up to get a simple DMA transfer to complete? Can anyone duplicate this problem? Is my ARESETN port in the slave module connected properly to an ARESETN signal as defined in the default MPD file?
Thanks again for any help.
11-12-2012 08:57 AM
11-12-2012 09:10 AM
Well you should tie the aresetn to something meaningful (i.e. proc_sys_reset or something) (as you note, tying this off to ground will hold it in reset).
It is probably best if you just post your .mhs and chipscope shots so we can have a bit more context about the issue. Also, posting your DMA configuration software and a dump of your register writes is also very helpful.
Lastly, you might want to have a look at the CDMA example in the Zynq CTT. Though not exactly the same, much of the connectivity will be relevant.
11-12-2012 02:07 PM
There is no way to assign a value to ARESETN (which is actually port "axi_resetn") unless the AXI DMA is made local and the MPD file is edited to make axi_resetn an external reset port, which seems to get rid of that warning, but there must be a better way. Is there no reference design with this module? I looked at the Zynq CTT example, but it's a loopback design that doesn't dump any data out into a user-accessible peripheral, which is critical in my application.
Is it possible that there is a simple example out there that will illustrate how to feed data to a user peripheral over a DMA engine? Using the clues from the CTT example, I am now seeing my TREADY input get stuck high, although there is a one-clock-wide TVALID pulse, but no data follows. I've attached my .mhs file in case someone wants to try to reproduce my issue.
11-13-2012 08:03 AM
I'm not fully understanding what this means. Does that mean that my IP needs to have an additional ARESETN output to the AXI DMA that is just a copy of its own ARESETN input? Or is a different logical control necessary for the AXI DMA ARESETN? Where does this knowledge come from? Is it a quirk of the IP whose configuration comes from experience, or is there some critical app note or other documentation I'm missing?
Is there a particular piece of documentation that details the necessary connections/strobes/MM2S timing for a simple DMA transfer with this IP (AXI DMA)? The only content of the data sheet section titled "Detailed Example Design" is a line indicating "The IP does not provide any example design".
I'm willing to provide as much information as I have to in order to get help in setting up a simple DMA-to-PL application, so let me know if there's anything beyond the .mhs that would be useful or if there is a stripped-down reference design somewhere, or even if anyone can at least recreate the problem and offer some insight as where I'm going wrong.
11-13-2012 02:26 PM
Actually, let me hold off on my previous message. That might not be totally true.
Hmm, well I just ran a quick test myself and it looks like it automatically is connecting the resets when dragged into the existing system.
Can you provide your test_dma pcore so I can test with your exact setup?
04-18-2013 05:23 AM
Unfortunately not yet. It turns out that it's not quite as simple as configuring a peripheral. There is also some low-level kernel configuration of the Linux kernel device tree (.dts file) that is necessary in order to point the DMA engine to the proper peripheral. I have not gotten past that point yet but there are some DTS file format tutorials out there, including a decent starting point on the Xillybus website here. If anyone gets a complete start-to-finish howto written in the meantime, please let me know.
04-24-2013 12:17 PM
You need a simplified system similar like my attached snapshoot:
I have 4 pairs of VDMA channels, connected to AXI-Lite, AXI4, controlled by Microblaze to DMA in and out the External DDR3 DRAM via MIG IP
All VDMA buses reset signals were driven by the AXILite reset output. MM2S or S2MM buses can be connected to VDMA softreset signal controlled by Microblaze. Interrupt signals needed to connect appropriately too if you used interrupt in the design.
After configuring all VDMA, Microblaze registers, the DMA starts when an external fsync is generated to VMDA or TUSER signal etc... it depends on your application.
My design has 4 S2MM channels and 4 MM2S channels, one S2MM channel serves as a Genlock Master, the rest are Genlock Slaves, an External Frame Sync starts the operation for every frame, concurrently "DMAing" in and out for a multiple high-definition cameras (1280x720 P resolution 60 fps or 1920x1080 I resolution 30 fps) Video System application.
It's works well so far,
04-24-2013 02:13 PM
A bit information:
I'm using EXTERNAL FRAME SYNCS to initiate S2MM and MM2S operations.
09-05-2013 11:21 PM
Any luck getting this going yet?
I am trying to get a stream of data into the cpu using AXI DMA S2MM transfer. At the moment I am using a DDS core with its output stream connected to the input stream of a DMA block (later I will connect to an external ADC and some fir filter blocks). When monitoring the signals in Chipscope, I can see that the data is being written to the memory address that I specify, but from my software application the data does not change.
I am getting a dma internal error and io complete interrupt and the dma gets halted.
Is this possibly to do with TLAST signal?
09-06-2013 06:13 AM - edited 09-06-2013 06:13 AM
09-08-2013 10:23 PM
Thanks for the example.
I got it going by removing the tlast line from the axi stream bus (in .mpd file) and driving it independently.
It appears to work fine if you just pull tlast high instead of using the xps default of pulling it low...
10-30-2013 04:57 AM
04-28-2015 10:21 AM
@bwiec Thank you for sharing your project.
I'm trying to do a MM2S transfer and so your project would be of great help.
Unfortunately, I can't open the .tcl files in either Vivado 2014.4 and 2014.2. I mean, I can open them but there are a lot of errors and the block design appears empty.
I think a print screen of the block design in Vivado would be enough for me, so can anyone post or send me a printscreen?
One question though. To connect the M_AXIS_MM2S port of AXI DMA block to a custom IP block (which let's say receives an array of length 10) do I always need a FIFO or can I connect it directly to the IP nlock? I ask this because I tried without a FIFO and the results are not good (maybe because I'm a noob but I'm not sure).