Reading >4 bytes via DMA is possible, correct?

[rnelsonee]

Hello all,

I am trying to stream data from a Custom IP, right now it's just a counter running at 8MHz, to a FIFO, to DMA. This is an image of the design. But the DMA and FIFO only ask (TREADY/WREADY) for data about 0.2 MHz. I'm sure it's because my code is only getting 4 bytes at a time from DMA, so even in a simple loop it's not fast enough.

My question is hopefully an easy one: with something like  

XAxiDma_SimpleTransfer(&AxiDma,(u32) RxBufferPtr, MAX_PKT_LEN, XAXIDMA_DEVICE_TO_DMA);

I should be able to have an array of size MAX_PKT_LEN ready to use (I'm just trying to send this out via UDP as fast as possible)? I'd imagine a pointer should be available to point to a 'set' of contiguous memory, correct? I only get 4 bytes from the above function.

I'm using a fairly simple program found online using XAxiDma_SimplePollExample(). In that program, it reads the first 1024 bytes just fine, and then actually the next 4 bytes, but then it starts 'dropping' data as my Custom IP keeps on going (I have the TREADY flag ignored for testing). The program output is here where you see it start to skip. And Here are the DMA settings and here are the FIFO settings.

Thank you to anyone who can help! I've been at this for over a week and it's got to be a 2-minute fix I'm sure! I appreciate *any* help, I'm very new at all this. 

[Sergiu]

Hello,

The first thing I noticed is that you are not using the TKEEP bus which I believe is necessary for the DMA.

Other than that, I noticed that you have not checked the "Allow unaligned transfers" option and because of that you will be restricted to 4 byte transfers (in case you are asking for different lengths). I recommend looking into these first since it is possible that this is causing the problems.

Also I do not understand what you mean by 0.2 Mhz. Is that some clock frequency or did you want to say 0.2 ms/us/ns ?

I would also recommend that you look at this demo project.

Here I used the DMA to transfer data more or less the same way you are trying to do it so I think it will prove useful.

Sergiu

[D@n]

@rnelsonee,

Well ... let me ask the unpleasant question: Have you considered the impact of the serial port controller on your design?

Is it possible that, after having written several items to the port, that you then get stuck for many (MANY) clocks dumping to the serial port all of the stuff you just printf'd?

Often times, if I need a log of what is happening at a high speed (such as within a design), I'll dump the log to memory and then stop the experiment/test before trying to read it out, since ... that serial port is just SO slow.

Dan

[rnelsonee]

53 minutes ago, D@n said:

@rnelsonee,

Well ... let me ask the unpleasant question: Have you considered the impact of the serial port controller on your design?

Is it possible that, after having written several items to the port, that you then get stuck for many (MANY) clocks dumping to the serial port all of the stuff you just printf'd?

Often times, if I need a log of what is happening at a high speed (such as within a design), I'll dump the log to memory and then stop the experiment/test before trying to read it out, since ... that serial port is just SO slow.

Dan

Oh, hah, I should have mentioned the printf's are just for debugging. In my real program, this all goes out on a UDP port. This program for this post is just to help me get data fast enough - once it works I'll put this code into my other code, without printf. 

Thank you for the tips - the Allow Unaligned Transfers certainly looks like it might have been the issue - I'm regenerating the bitstream now. And the 0.2Mhz was lousy terminology on my part - the signal from the DMA down to the FIFO saying it was ready happens at about 0.2MHz - it's not a clock or anything. It's just that the "I'm ready for data" signal is slower than what I need it to be.

 

And I'll play with TKEEP - I'm using AXI-S (stream), so I think TKEEP isn't used at all, just TREADY. Hopefully I don't have to use anything more complicated, I just send my data with TVALID and TLAST on high.

 

[rnelsonee]

So it looks like enabling unaligned transfers didn't solve the issue: I'm still only transferring 4 bytes at a time. I really thought that was going to be it.

Backing up a bit - is the DMA even required? Is there a way to just read the AXI data from the FIFO?

[D@n]

@rnelsonee,

Why not?

It might depend, though, on the speed of the data you are working with.  Can your program loop fast enough to read that data?  And, is your program going to be focused on and working on something else?  If your program can afford to spend 100% of its time looking for data from the FIFO, then ... the DMA may not be required at all.

Dan

[rnelsonee]

@D@n

Thanks again for continuing to reply. And yeah, I'll see if that can work. I'm taking data (1000 bytes or so), throwing a few bytes of header onto it, and sending it over Ethernet. Since I'm only getting 4 bytes per function call from DMA, there doesn't seem to be any advantage to DMA. I figured the main purpose of a DMA was to allow me to use a pointer to grab a chunk of data, but that doesn't seem to be the case - I guess it just saves some processing cycles.

 

If the FIFO can give me a few hundred bytes per function call, I'll use that. I assumed there was no way in the SDK/C code to 'pop' data out of a FIFO, but it looks like there might be a function for that.

[rnelsonee]

To anyone that sees this in the future:

My issue was with TLAST. I had it high, and my Custom IP sent out 4 bytes at a time. This limited the DMA to only give out 4 bytes at a time. By only asserting TLAST once every N bytes (you can't keep it at 0, despite the AXI-S spec saying it's optional) the DMA will read back N bytes.

This thread links to a custom IP you can use to generate TLAST for you which sits between the FIFO and the DMA so your Custom IP doesn't need to do it.

[D@n]

@rnelsonee,

Glad you found the solution!

Dan

[jpeyron]

@rnelsonee,

Happy to here you figured out the issue! Thank you for posting what you found out and how to fix the issue.

cheers,

Jon