DMA, Buffers, and streams

Questions and discussions about the Xillybus IP core and drivers

DMA, Buffers, and streams

Postby Guest »

I am using the Zybo board and am sending packets of data from the host to FPGA in bursts (an array of 32 bit numbers). I am assuming 32bit word sizes is the optimum length from the documentation of the IP Core factory, but what is the optimum burst size I should transfer at a time (fastest)? Is it 512 bytes? I know that DMA transfers handle a certain quantity of data with every transfer, but what is the maximum amount of data that can be handled per transfer across the DMA? The reason we want the largest burst possible from the host to the FPGA is to minimize host system overhead (system calls, etc = SLOW). Along with this same note, I had a few questions about DMA acceleration in the custom ip guide. Does xillybus automatically create RAM buffer space on the FPGA (8 segments of 512 bytes) to queue data blocks sent to the FPGA from the host? Also is there a way to track how many of these buffers are full (1 of 8, 2 of 8, 3 of 8, etc)?

Also, on another note, I believe I will want to use an asynchronous stream from reading the custom IP documentation because I do not care about user space processes as I intend to only be using the Zybo board to run a single C program (and nothing else). Or would you say that C program could consume enough resources that it might be better to use a synchronous stream?


To give a big idea of what is occuring on our zybo board:
Software---------------------------------------------------------->hardware
[C program creates packet] -> [Xillybus DMA transfer] -> [Xillybus automatic buffers on FPGA?] -> [FIFO] -> [serialize data onto a pin]
Guest
 

Re: DMA, Buffers, and streams

Postby support »

Hello,

32 bit width is indeed the correct choice for best throughput.

As for DMA buffers -- Xillybus maintains a set of DMA buffers which are used for the data transport. There's most likely no point to dive into the details of the underlying mechanism, as it's designed to make optimal use of the bandwidth when it's under heavy load, and being slightly inefficient under lighter load.

So from a user's point of view, just try to send as much data as you have. If you have a 1 MB buffer in user space, call write() with the entire buffer. If the return value indicates that not all was written, re-issue write() calls until it's completely written. Xillybus takes care of the optimizations.

As for synchronous vs. asynchronous streams -- this issue is discussed in the documentation, but to put it short: The only thing it determines, is if data can run across the FPGA and host between read() and write() calls, like "in the background". When the streams are used just to shuffle data, asynchronous streams are the preferred choice, but when they're used to communicate commands and status information, synchronous streams are necessary, as it matters when the data was read and when it arrived.

I hope this put things clearer.

Regards,
Eli
support
 
Posts: 802
Joined:


Return to Xillybus

cron