How Xillybus IP achieve IP<--> DRAM or PL's SRAM transfer ?

Questions and discussions about the Xillybus IP core and drivers

How Xillybus IP achieve IP<--> DRAM or PL's SRAM transfer ?

Postby Guest » Tue May 01, 2018 8:50 pm

Hi, dear support

I'm new to Xillybus IP and would like ask the following basic questions which is the use case of my design.

Spec : Develop a FFT IP on ZYBO FPGA with Ubuntu Linux
Use case 1 Functional mode : FFT fetches the data from either DRAM or SRAM in PL for input and then write back to either DRAM or SRAM in PL after processing

Use case 2 Self-Test mode : Host writes data to FFT's buffer for input. After processing, FFT write back to either DRAM or PL's sram and notify Host to read back or CPU pools if FFT is done.

Question : For use case 1, FFT needs the capability of DMA to read/write memory-mapped regions. Can Xillybus IP fulfill the DMA requirement when integrated with my FFT IP core ? If yes, are there any example or doc of Xillybus IP demo example to trace ?

Thanks
Guest
 

Re: How Xillybus IP achieve IP<--> DRAM or PL's SRAM transfe

Postby support » Tue May 01, 2018 9:03 pm

Hello,

Xillybus supplies data streams between the host and the FPGA. Memory mapping of these streams is not supported. If you want to access the host's RAM directly, you'll need to do so directly (via a separate AXI interface connected directly to your logic).

As a side note, there is probably enough FPGA RAM to hold the FFT data, so odds are that the simplest solution is to use Xillybus to send the data for processing to the PL part and to get back after the FFT has been performed.

It's also considerably faster, in particular since both the AXI interface and DDR memories are designed for throughput and not latency: You get good performance on long bursts of data, not when requesting a single word and waiting for it to arrive.

As a result, each memory operation takes much longer than a FPGA RAM (which has a latency of a single clock).

Regards,
Eli
support
 
Posts: 582
Joined: Tue Apr 24, 2012 3:46 pm

Re: How Xillybus IP achieve IP<--> DRAM or PL's SRAM transfe

Postby Guest » Wed May 02, 2018 7:44 am

Hi, Eli,

Thanks for your comment.

I'm interested in what you mentioned on "the simplest solution is to use Xillybus to send the data for processing to the PL part and to get back after the FFT has been performed." What we often be requested is the issue that how to minimize the overhead of host processor and it is therefore we try to reduce the task of data movement carried out by host processor. After the FFT IP, we will port over image processing IP. Thus, I have the following further questions for you.

Q1: The original data is stored in DRAM. It implies that the flow will be the host cpu will fetch data from DRAM and then write to Xillybus to send data to FFT IP. It seems that host CPU needs to fetch data from DRAM each time e.g. every ms etc.. From your experience, is it worth to use host CPU for such task ?

Maybe it's easier for you to illustrate the example you have like our use case 1 but using Xillybus IP as solution and then we can imagine the difference to persuade others in teams. Thanks
Guest
 

Re: How Xillybus IP achieve IP<--> DRAM or PL's SRAM transfe

Postby support » Wed May 02, 2018 9:16 am

Hello,

The communication with Xillybus is done with DMA, so there's no waste of CPU cycles for the actual I/O. The data is however copied into DMA buffers by the processor by the write() call, and vice versa with read(). As memory copying is a very common task for processors, it's also well optimized. The overhead for this is usually negligible in the context of an algorithm that does something useful.

The alternative, which Xillybus doesn't offer, is to make the PL logic fetch the data directly from the array used by the software (and same in the other direction). This makes the software considerably more complicated and hardware specific, as it needs to manage the physical memory pages directly. This is common in graphics API for GPUs, as there's a lot of data (image maps etc.) that is shuffled back and forth.

And since we're at it, I'd mentioned that there's a section in the docs related to coprocessing with Xillybus: Xillybus host application programming guide for Linux, section 6.6 ( http://xillybus.com/downloads/doc/xilly ... _linux.pdf ).

Regards,
Eli
support
 
Posts: 582
Joined: Tue Apr 24, 2012 3:46 pm


Return to Xillybus

cron