cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
sebastian_z
Explorer
Explorer
7,928 Views
Registered: ‎04-01-2016

AXI DMA - TREADY goes low permanently

Jump to solution

Hi all,

 

again I do have a problem with an AXI DMA. I think one part of the solution is the following post:

AXI DMA TREADY goes low

 

So far I do the following: in my PL is an AXIS master which itself gets data from a camera and this camera starts immediatly after power up. So after programming the PL, the AXI DMA also gets data immediatly before the whole interrupt system in software is configured.

 

If this (as I assume) is the problem, I could do the following:

Adding a port in my custom IP core which I assert if the interrupt system is up and ready and then starts transmitting the data to the AXI DMA.

 

For me, a second solution would be better: can I reset the AXI DMA in software before or after setting the interrupts to make it working again? The camera could then send data and they are disregarded until the software is up.

 

What is the solution preferred by Xilinx?

 

Kind regards

Sebastian

Tags (5)
0 Kudos
1 Solution

Accepted Solutions
sebastian_z
Explorer
Explorer
13,235 Views
Registered: ‎04-01-2016

Hi,

 

I finally made it. Unfortunately my simulation results are different from my implementation results as I could see with an ILA core. I think I modelled the device which is responsible for the AXI transactions wrong, that means the interface between the device and the Zynq.

I will search this mismatch now.

 

The signal which is responsible for TLAST is one clock cycle too late (the mismatch) and so TLAST never goes HIGH. I fixed that now and will have a look at the difference. :)

 

Another hint for all designing with the AXI DMA core: in the IP Core there is a setting for the width of the length register. In the datasheet I saw that it has a bit width of 23 and then I realized that I only have 14 bits in hardware so far. This was another fault. Perhaps the hint can be helpful for anyone designing with the core.

 

Kind regards

Sebastian

View solution in original post

0 Kudos
5 Replies
bwiec
Xilinx Employee
Xilinx Employee
7,908 Views
Registered: ‎08-02-2011

Hi Sebastian,

 

I would use the first method.

 

The problem is (this always catches people by surprise...) that the DMA accepts 4 beats of data on the stream side as soon as it comes out of reset, even if the DMA isn't configured yet. So even if you hit a software reset, the core will come up and accept 4 beats before you configure it to transfer the data. So if your hardware can't handle this properly, then the DMA will have 4 stale bytes by the time you tell it to start transferring data some time later.

 

So if it were me, I'd have my software setup such that it first kicks off my DMA transfers then hits a GPIO to tell your custom IP to 'start.' The custom IP would not assert tvalid until it sees the 'start' signal.

 

For streaming data, it's going to get more complicated if you can't throttle the stream because tready from the DMA is going to go low when you finish one transfer while you setup the next. So you will want to use a FIFO that's big enough to store samples while your processor is doing its thing, use SG mode (which queues up buffer descriptors in a pipelined fashion to minimize downtime), etc.

 

Also, have you looked at the Video DMA core (AXI VDMA) instead of the AXI DMA??

www.xilinx.com
billel
Observer
Observer
7,855 Views
Registered: ‎05-02-2015
Hi bwiec, Recently, I have got my Zybo board and I try to build Zynq-based FFT co-processor using the AXI DMA proposed in the link below: https://www.xilinx.com/support/answers/58582.html The project is created under the 2016.2 version of vivado. When I run the project on the board I can get the correct menu and I have calculate the FFT until 2048 points, but for more then 2048 point the project stop working and I can't set again the board to the previous state. Is there any suggestion on how to solve this problem? Thanks.
0 Kudos
sebastian_z
Explorer
Explorer
7,824 Views
Registered: ‎04-01-2016

@bwiec

 

Hi Brian,

 

thank you very much for helping. I can transmit some data now before TREADY goes LOW permanently. After that I read the status register and I get a 0x11. The datasheet says about Bit 4: Internal error. With Google I found the following post:

 

AXI DMA => TKEEP

 

There I noticed that I haven't set TKEEP and this gave me hope :) . But after setting TKEEP to "1111" and rebuilding the bitfile TREADY again goes LOW and never returns. It is possible to transmit circa 600 Words (I inserted an ILA core to my module). I verify the correctness of my AXI transactions with the AXIS Protocol Checker in Modelsim and I don't get an error. So the bus transactions should be fine.

 

I'm glad for any hints on this issue.

 

Kind regards

Sebastian

0 Kudos
sebastian_z
Explorer
Explorer
13,236 Views
Registered: ‎04-01-2016

Hi,

 

I finally made it. Unfortunately my simulation results are different from my implementation results as I could see with an ILA core. I think I modelled the device which is responsible for the AXI transactions wrong, that means the interface between the device and the Zynq.

I will search this mismatch now.

 

The signal which is responsible for TLAST is one clock cycle too late (the mismatch) and so TLAST never goes HIGH. I fixed that now and will have a look at the difference. :)

 

Another hint for all designing with the AXI DMA core: in the IP Core there is a setting for the width of the length register. In the datasheet I saw that it has a bit width of 23 and then I realized that I only have 14 bits in hardware so far. This was another fault. Perhaps the hint can be helpful for anyone designing with the core.

 

Kind regards

Sebastian

View solution in original post

0 Kudos
bwiec
Xilinx Employee
Xilinx Employee
7,781 Views
Registered: ‎08-02-2011

Hi Sebastian,

 

Glad you were able to figure it out!

 

Yeah, tkeep has a 'default tieoff' in IP Integrator. So if you use it in a BD, tkeep will automatically be tied to all 1's unless something drives it to something else. This is the case for all our relevant DMAs as well.

 

Hi bwiec, Recently, I have got my Zybo board and I try to build Zynq-based FFT co-processor using the
AXI DMA proposed in the link below: https://www.xilinx.com/support/answers/58582.html The project
is created under the 2016.2 version of vivado. When I run the project on the board I can get the
correct menu and I have calculate the FFT until 2048 points, but for more then 2048 point the
project stop working and I can't set again the board to the previous state. Is there any suggestion
on how to solve this problem? Thanks.

Hello,

 

Hmm, I seem to recall a limitation for the design, but I can't remember exactly why. Check a few things in the hardware:

- 'Width of Buffer Length Register' setting as Sebastian pointed out

- Max length setting of the FFT

- Number of bits actually going to the config channel. There's some kind of edge detection circuit on a GPIO that eventually drives the config channel of the FFT. That might be limited in bits.

www.xilinx.com
0 Kudos