xillybus reading data problem

Questions and discussions about the Xillybus IP core and drivers

xillybus reading data problem

Postby Guest » Thu Nov 28, 2019 9:10 am

Hi, we met a issue. When we open 2 ports in Linux host and then read data from them, data will be lost. But if we open and read one port, the data is correct.
Our xillybus IP core configuration is as following:
xillybus_read_a_16 Upstream (FPGA to host) 16 bits 100 MB/s Yes Data acquisition / playback (Maximum)
xillybus_read_a_8 Upstream(FPGA to host) 8 bits 1 MB/s Yes General purpose
xillybus_read_b_16 Upstream (FPGA to host) 16 bits 100 MB/s Yes Data acquisition / playback (Maximum)
xillybus_read_b_8 Upstream(FPGA to host) 8 bits 1 MB/s Yes General purpose

xillybus_read_a_16 and xillybus_read_b_16 are the ports that we read.

Any suggestion is appreciated.
Guest
 

Re: xillybus reading data problem

Postby support » Thu Nov 28, 2019 9:17 am

Hello,

This is not a Xillybus related problem, as the IP core as well as the driver work perfectly well with access to multiple streams at the same time.

If you're losing data, I suggest looking if the FIFOs in the FPGA get full, or if you correctly interpret the return value of the read() calls -- recall that read() may return with less data than required.

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

Re: xillybus reading data problem

Postby zinnc » Wed Dec 04, 2019 6:54 am

Thanks for reply.
My code is basiclly a modified version of the bundle example(streamread.c), and the FIFO in FPGA side is never full.
My pseudo-code is:
Code: Select all
open stream1;
open stream2;
read stream1 to local user space buffer;
write buffer data to file;

The code above leads to data lost.
But if I change the code to:
Code: Select all
open stream1;
# open stream2;
read stream1 to local user space buffer;
write buffer data to file;

Then all reading data is correct. Likewise if I swap stream1 and stream2.
Could it be that DMA of stream2/stream1 is too large to make the system instable? BTW, DMA buffer for stream1 and stream2 is 128MB(written in the README.txt of bundle file), but I found that "The total buffer allocations for all streams together shouldn't exceed 8 MBytes on a Linux system", quoted the note of "Size of each buffer" on the page of "IP Core Factory". Could this be the confict?
zinnc
 
Posts: 3
Joined: Wed Nov 27, 2019 8:48 am

Re: xillybus reading data problem

Postby support » Wed Dec 04, 2019 10:29 am

Hello,

zinnc wrote: but I found that "The total buffer allocations for all streams together shouldn't exceed 8 MBytes on a Linux system", quoted the note of "Size of each buffer" on the page of "IP Core Factory".


This is a very outdated comment in the said help window, relating to a Linux kernel driver version that vanished several years ago. The same comment continues:

The operating system may refuse to allocate more than this, leading to a failure in the driver's initialization.


so even if this was the problem, it would have been a matter of the driver not loading, not anything of the sort you're experiencing.

Thanks for the heads-up on this mistake. It has been corrected.

As for your suggestion that opening two files at the same time would confuse Xillybus in any way, well, no. The IP Core + driver combo has been tested in by far more complicated scenarios before their release, not to mention hundreds of end-users (including paid-for licensees) that actively use several streams at the same time in a huge variety of I/O patterns. All this without any problems at all.

This is why I feel confident to rule out the possibility that a two-stream situation would be the problem. I warmly suggest taking a closer look at your own logic design and computer program.

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

Re: xillybus reading data problem

Postby zinnc » Wed Dec 04, 2019 12:59 pm

Thanks. I will do more check on my project.
Meanwhiel, could you give me some tips on these questions?
1. When I configure a custom IP, I found many option in "Use": Frame Grabbing, Data acquisition, Data exchange with coprocessor, Bridge to external hardware.... etc. Do you have some user guide for these options? I found some description on <Xillybus host application programming guide for Linux>, but didn't get too much details.
2. Should I re-install the driver? I found that the version of xillybus_core.c is 1.07 in https://github.com/torvalds/linux/drivers/char/xillybus, which is older than 1.10 that provided on xillybus website. My Linux kernel is 3.16.78.
zinnc
 
Posts: 3
Joined: Wed Nov 27, 2019 8:48 am

Re: xillybus reading data problem

Postby support » Wed Dec 04, 2019 1:20 pm

Hello,

As for the "use" part in the IP Core factory. This parameter helps the autosetting of the the stream's parameters, and it has no meaning if "Autoset Internals" is turned off. It's almost always easiest to choose what matches your application best, and then review the settings in the README file for anything that might seem inadequate. Odds are that it has been done correctly.

As for the kernel driver, well, there is a slight bug fix somewhere in the region of kernel revisions. So it might be a good idea to use the driver from the website.

Almost needless to say, none of these two issues will cause anything near the problem you described.

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

Re: xillybus reading data problem

Postby zinnc » Thu Dec 05, 2019 1:41 pm

Thanks for reply.
I found a bug in my project now it get fixed.
Besides, I have to extend FIFO depth to 16,384 to make things right(16384 is not a precise boundary, it's kind of trial-and-error result, cause 8,192 didn't work). But I found some saying in <Xillybus host application programming guide for Linux>:
''While the data flow is stalled, the IP core might be busy with other activities, for example copying data on some other stream’s behalf (i.e. draining another intermediate FIFO). As a result, there might be a random delay between the deassertion of the “empty” signal by the FIFO and the resumption of fetching data from it. This delay varies, but the overall design guarantees that a FIFO of 512 words will not overflow(as long as the average rate is within limit)."
So, '16,384', the correct FIFO depth in my project, means that the average data input rate is out of PCIe limit in my design?
zinnc
 
Posts: 3
Joined: Wed Nov 27, 2019 8:48 am

Re: xillybus reading data problem

Postby support » Thu Dec 05, 2019 1:49 pm

Hello,

Generally speaking, a 512 word depth FIFO is enough. For streams above 800 MB/s, possibly 1024 words or 2048 words.

If you have a synchronous stream (as stated in the README file), data isn't emptied unless there's a read() call waiting for it on the software side. This might be the reason why you may need to have a deeper FIFO: To compensate for the time between one read() call and another.

Setting the "Use" to Data acquisition ensures that the stream is asynchronous -- or set that manually. This is the natural choice for data that just keeps streaming in (and also the setting in the demo bundles).

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


Return to Xillybus

cron