cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
tamas.kiss
Contributor
Contributor
815 Views
Registered: ‎04-30-2019

AXI DMA wrong length, internal error

Jump to solution

Hi!

I'm trying to use the AXI DMA core to transfer data to the PS on the ZCU102 board.

Long story short, my module's TVALID is deasserted until the DMA is configured, and TLAST is asserted exactly when the DMA transfer should end. I have verified this with an ILA. Although the DMA length register (0x58) is set to 1024, the TVALID signal stays active for 4 extra cycles after TLAST is asserted at the 256th transfer.

Everything is fine on the first run, but the consecutive transfers report an internal error (0x04[4]). Which keeps writing this to the PetaLinux log:

 

 

 

xilinx-vdma a0000000.dma: Channel 00000000fcc6ebc5 has errors 10, cdr 0 tdr 0

 

 

 

 

The PS is running PetaLinux and a kernel module based on the attached code. (I got it from the forum, but now I can't find the thread.) My module basically uses the S2MM part of this. It worked fine, until there was only a simple packet generator attached to the DMA.

Now my design looks like this. 

 

 

 

Packet generator -> FIFO -> TLAST generator -> DMA

 

 

 

My custom TLAST generator module joins multiple packets, so they can be copied by the DMA in one big transfer. This is done by counting tready&tvalid and asserting TLAST when a programmed length is reached. This module can also be enabled by the PS, so I can enable it when the DMA is initialized.

Do you have any tips to solve this issue?

Tags (4)
0 Kudos
1 Solution

Accepted Solutions
dgisselq
Scholar
Scholar
661 Views
Registered: ‎05-21-2015

@tamas.kiss ,

From what you've written alone, it's hard to be certain what's causing your problem.  This statement, however, concerns me:

Although the DMA length register (0x58) is set to 1024, the TVALID signal stays active for 4 extra cycles after TLAST is asserted at the 256th transfer.

Every beat with TVALID && TREADY should get transferred.  Xilinx's design has a bug that will cause it to hang if it receives a TVALID when it hasn't yet been configured.  Further, TVALID && TREADY && TLAST will terminate any transfer.  Further TVALID's will be interpreted as part of the next burst.  This may be a problem if the core hasn't (yet) been configured for a new transfer.

As a piece of background tho, I've never used Xilinx's S2MM DMA.  My only claim to any knowledge here is as one who has built their own, and then listened to comments others have made about Xilinx's S2MM .

Dan

View solution in original post

5 Replies
dgisselq
Scholar
Scholar
662 Views
Registered: ‎05-21-2015

@tamas.kiss ,

From what you've written alone, it's hard to be certain what's causing your problem.  This statement, however, concerns me:

Although the DMA length register (0x58) is set to 1024, the TVALID signal stays active for 4 extra cycles after TLAST is asserted at the 256th transfer.

Every beat with TVALID && TREADY should get transferred.  Xilinx's design has a bug that will cause it to hang if it receives a TVALID when it hasn't yet been configured.  Further, TVALID && TREADY && TLAST will terminate any transfer.  Further TVALID's will be interpreted as part of the next burst.  This may be a problem if the core hasn't (yet) been configured for a new transfer.

As a piece of background tho, I've never used Xilinx's S2MM DMA.  My only claim to any knowledge here is as one who has built their own, and then listened to comments others have made about Xilinx's S2MM .

Dan

View solution in original post

joancab
Teacher
Teacher
656 Views
Registered: ‎05-11-2015

"Xilinx's design has a bug that will cause it..."

Is there a place where these bugs are documented?

0 Kudos
dgisselq
Scholar
Scholar
647 Views
Registered: ‎05-21-2015

@joancab ,

No.  I think Xilinx's official position on it is that it isn't a bug or some such.  Everything is documented in, and follows according to the specification is what I've been told.  If that's the case, the specification describes something I wouldn't expect.  I know I've told them about this, and posted about it (see links above), but I don't know of any official errata discussing it.

Dan

0 Kudos
tamas.kiss
Contributor
Contributor
618 Views
Registered: ‎04-30-2019

Sorry, I mixed the signals up in my original post. Actually TREADY stays asserted for 4 extra cycles.

Selection_076.png

 

 

 

 

 

Further TVALID's will be interpreted as part of the next burst. 

Now that sounds interesting. This would explain why I had no issues when the DMA was directly connected to the packet generator. I'll try to cut TVALID after TLAST.

Thanks for the tips. I'll try this and get back with the results.

0 Kudos
tamas.kiss
Contributor
Contributor
587 Views
Registered: ‎04-30-2019

Well, that was it. Now I made sure that TVALID is deasserted after TLAST until the DMA is configured for the next run.

Thank you very much @dgisselq for your help.

0 Kudos