cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
hubaokun
Visitor
Visitor
5,153 Views
Registered: ‎11-08-2017

Axi dma S2MM receive data are not all perfectly normal.

Jump to solution

Hi, anybody

 

     It seems that I succeeded in receiving data in cycling axi dma mode. In the meanwhile, I also met some problems, because the data received are not all perfectly normal.

 

    Here,  I send a series of data from 0 to 2047 according to the s2mm_tdata.

 

xilinx4.PNG

 

XILINX1.PNG

 

then , I found such a problem in the sdk memory debug window.

 

0x01001000 is the first buffer starting address,  the buffer length is 2048,  and 0x01003000 is next description buffer starting address.....

 

xilinx9.PNG

 

 

 

xilinx2.PNG

 

In the above pictures, the s2mm_data lost 5 numbers (4、5、6、7、8)  behind (0、1、2、3),and  after the last number 2047, there are 5 empty spaces...... The same situation is also suitable for the following description buffer.  Why is it?

 

Here is my block desgin.

 

xilinx5.PNG

I don't know why . Who can tell me where the problem is?   Thank you so much.

0 Kudos
1 Solution

Accepted Solutions
ronnywebers
Advisor
Advisor
5,972 Views
Registered: ‎10-10-2014

@hubaokun, I think it's indeed unavoidable that the DMA controller takes in a few words. It has some pipelining registers at the input (and output). They just caputere the very first incoming data words until the pipeline is filled up (then TREADY goes low). 

 

 

Isn't it only your very first frame that shows strange data? Doesn't it become ok in the 2nd frame?

 

I remember having a similar issue, and I added an 'enable' on my incoming datastream (using a AXI GPIO pin, but you might do it with an AXI Lite reg too), to hold it off until DMA was setup completely and ready to receive data. So my datasource did not set TVALID permanently to '1', only after it was enabled, so I had time to setup my DMA.  Also I added an AXI stream fifo to have better throughput. 

 

I did put an ILA on the AXI stream and AXI control bus, to better understand what was happening. you can then see effectively what happens on the interface (trigger on reset, or DMA enable, ..).

** kudo if the answer was helpful. Accept as solution if your question is answered **

View solution in original post

14 Replies
hubaokun
Visitor
Visitor
5,120 Views
Registered: ‎11-08-2017

xilinx.PNG

 

Maybe that's the cause of the problem. In cyclic mode, perhaps it is still impossible to avoid this case.

ronnywebers
Advisor
Advisor
5,108 Views
Registered: ‎10-10-2014

any idea why the TLAST line in your simulation window has a red color? That looks like a driving conflict ?

 

The axi stream that goes to your DMA, is it coming from an external source which we don't see in the block diagram?

** kudo if the answer was helpful. Accept as solution if your question is answered **
0 Kudos
hubaokun
Visitor
Visitor
5,096 Views
Registered: ‎11-08-2017

hi, @ronnywebers

    Glad to see your reply, it's a pity, there is an obvious negligence in s2mm_last(red line),  after I fixed this mistake, that's still the case .

    Here , the axi stream comes from fft's index (from 0 to 2047) , in fact, the s2mm_count is also from the same  fft's index ( s2mm_tdata is just half  a cycle slower than s2mm_count by inverting the clock). 

0 Kudos
ronnywebers
Advisor
Advisor
5,973 Views
Registered: ‎10-10-2014

@hubaokun, I think it's indeed unavoidable that the DMA controller takes in a few words. It has some pipelining registers at the input (and output). They just caputere the very first incoming data words until the pipeline is filled up (then TREADY goes low). 

 

 

Isn't it only your very first frame that shows strange data? Doesn't it become ok in the 2nd frame?

 

I remember having a similar issue, and I added an 'enable' on my incoming datastream (using a AXI GPIO pin, but you might do it with an AXI Lite reg too), to hold it off until DMA was setup completely and ready to receive data. So my datasource did not set TVALID permanently to '1', only after it was enabled, so I had time to setup my DMA.  Also I added an AXI stream fifo to have better throughput. 

 

I did put an ILA on the AXI stream and AXI control bus, to better understand what was happening. you can then see effectively what happens on the interface (trigger on reset, or DMA enable, ..).

** kudo if the answer was helpful. Accept as solution if your question is answered **

View solution in original post

hubaokun
Visitor
Visitor
5,075 Views
Registered: ‎11-08-2017

hi, @ronnywebers

 

   Thank you so much for your advice. Yes, not only the first frame shows strange data , the following frames show the same problem. I use the axi dma in SG cyclicing mode.

   I agree with your opinion, so maybe I should add an 'enable' signal  before the dma engine is set up , and the axi stream fifo is also interesting, I'll try it later. Thanks again for your support.

0 Kudos
2,991 Views
Registered: ‎03-26-2019

hallo,

I have the same problem. 

has anyone found a solution to this problem?

 

 

0 Kudos
ronnywebers
Advisor
Advisor
2,967 Views
Registered: ‎10-10-2014

roberto.mendicino@unitn.it 

If the data in your stream is corrupt, there can be a few causes:

1) your DMA looses data if it cannot transfer it quickly enough to memory: in the block design shown, there is no (AXI4 stream data) FIFO (at least it's not visible, it could be part of the data source, but I don't think it is). In general a fifo is desired/needed as an elasticity buffer, i.e. because the DMA will need to compete with other controllers (like the APU, ...) that want to access the same memory, or share the same AXI interconnect, and so on. You should use an AXI4S Data stream buffer for that. The size of this fifo depends on many factors (like speed of your data source, how many other devices are competing for the same AXI interface or DDR memory, but also DMA transfer size, how much latency is allowed, and so on ...). To see if you have such 'performance' issue, you could try to start with a low data source rate.

2) you don't enable your AXI4 data stream correctly : before you start sending data to the DMA controller, it must be completely setup and ready to transfer data to memory (so configured, descriptor(s) read, interrupts intialized, ...). Only after that, you should enable your data source (check TREADY/TVALID/TLAST signals in the ARM AXI4S spec to learn about how these work). 

3) if you need 'precise control' on the data stream, you must take into account that each IP with an AXI4S stream has in general some 'pipeline registers', in case of the DMA it's like 4 or 5 registers, I don't know this precisely. I already described this in the accepted solution, make sure to read that again.

The easiest way to understand all this, and to find out your exact problem, is to use an ILA, and see what happens on all the interfaces of the DMA (AXI4 stream of your data, AXI Lite of the DMA, SG, ...) just hook them all up to the ILA, make the memory buffer large enough, and set your trigger condition. You'll learn a lot from this, as you'll truly understand from the snapshots what realy happens on all these busses, and how this timing looks like. The best trigger is probably on the very first access to the DMA register, so you can even see all the init commands etc. Pay special attention to the TREADY/TVALID and TLAST signals, and put an incrementing counter in your data source.

 

** kudo if the answer was helpful. Accept as solution if your question is answered **
jensrenner
Contributor
Contributor
2,501 Views
Registered: ‎02-20-2014

Same problem here.

Maybe I'm getting it wrong, but: Why is the IP accepting data in the first place before it is armed or even configured? And if I can't rely on TREADY to indicate that the IP is actually ready to accept more than 4 samples, there seems to be no other way to tell the upstream source when this is the case (i.e. no signal that the S2MM is up & running).

I can't believe I have to use a GPIO that get's triggered by SW to tell the data source to start the transfer ...

Is there really no better solution??

0 Kudos
ronnywebers
Advisor
Advisor
2,494 Views
Registered: ‎10-10-2014

@jensrenner with IP I asume you mean the DMA IP? 

Most AXI streaming IP have a few input and even output pipeline registers, to ensure a high throughput. These registers are not necessarily 'disabled' until the DMA IP is 'enabled/configured' through software.

It is common - imho - unless somebody tells me different - to 'enable' and 'disable' a data source or even data sink, until you have setup your software, interrupt handlers, and so on. You do the same i.e. when you initialize a uart in a microcontroller : you set everything ready in software : baud-rate, rx buffers, tx buffers, irq handlers, ... and at the very final moment, you 'enable' tx and rx ...

The same goes for an AXI data source and sink : add a simple enable. The quick & dirty way is an AXI GPIO, the often better way in case you have a more complex IP that requires other configuration, is to add a 'control' AXI registes to your IP,  which has a 'stream enable/disable' bit.

you only need to 'hold off' the source, not the complete chain, as this TREADY / TVALID ripples through the chain. It's not that hard to do.

** kudo if the answer was helpful. Accept as solution if your question is answered **
dgisselq
Scholar
Scholar
2,486 Views
Registered: ‎05-21-2015

@jensrenner,

> Is there no better solution?

I suppose you could always use a 3rd party AXI S2MM module.  This one in particular can be configured to keep TREADY low until it's ready to accept data.

Dan

jensrenner
Contributor
Contributor
2,481 Views
Registered: ‎02-20-2014

@ronnywebers Appreciate your answer ... Yes, I am talking about the AXI DMA IP and I mostly agree.

Actually, I have such GPIOs and AXI configuration registers in place. But it means, adding the register or GPIO to my DTS and related infrastructure to my kernel driver etc. I was just wondering why TREADY is not ANDed with the armed S2MM channel status, or why there is no other separate indication. Because the IP is supposed to know when it's running and ready to process data and could enable the upstream source. That would get me rid of any additional SW intervention and would be much simpler and more intuitive.

Plus I expect this issue to appear whenever I stop and restart the S2MM channel, not only when it is 'unconfigured' at the very beginning. For most other HW (e.g. UARTs), I can simply flush the pipeline or rely on signals reflecting 'readiness'.

jensrenner
Contributor
Contributor
2,479 Views
Registered: ‎02-20-2014

@dgisselq Thanks Dan. In fact that's exactly the behaviour I would expect ...

0 Kudos
ronnywebers
Advisor
Advisor
2,477 Views
Registered: ‎10-10-2014

@jensrenner  one could indeed ask why the pipeline regs aren't implemented that way ... it would be great if someone from Xilinx could shed some light on this ...

I haven't done this in linux (yet), only bare-metal ... but I'll soon have to do this in a project .. I was thinking to control this enable/disable datasource from user-space through uio-drivers ...? So talk to the axi registers in the datasource IP over uio? No need to do anything in the kernel - I think ?

 

** kudo if the answer was helpful. Accept as solution if your question is answered **
0 Kudos
gilles007
Visitor
Visitor
2,195 Views
Registered: ‎12-11-2018
@ronnywebers
Have you implemented the DMA into Linux and if so do you have a reference on how you completed this?
0 Kudos