The Xillybus Forum

Hello,

tozkoparan wrote:While synchronous data transfer is useful for command virtual channels and logging virtual channels, asynchronous data transfer is useful for data virtual channels.

Synchronous streams towards the FPGA make sense if you don't want the write() call to return before the data has reached the FPGA. This is indeed useful for sending commands, when it matters that the command has been executed before the computer program continues.

Asynchronous streams from the FPGA has almost no use if there's a FIFO between the application logic and Xillybus' core, because the logic puts the data in the FIFO and doesn't know when it's collected anyhow. So it doesn't matter if the data is waiting in the FIFO or in a DMA buffer.

When using seekable streams, the read must be synchronous, because the read must occur after the seek() operation. But in that case there's no FIFO, and this isn't your use anyhow.

In short: Synchronous streams are the wrong choice even for logging. Actually for anything but seekable streams.

tozkoparan wrote:However, we have no idea about the errors occurring at 11:59 PM.

To me this seems to be some Windows OS service that kicks off at that hour, and steals CPU and other resources briefly. It's just the corner case situation that woke up a problem that was there all the time.

Regards,
Eli

Hello

Thank you very very much unexampled support

When we first realize the existence of Xillybus we were using it for only synchronous data transfer.
Day after day, we try to use all of the properties of Xillybus including asynchronous data transfer.
While synchronous data transfer is useful for command virtual channels and logging virtual channels, asynchronous data transfer is useful for data virtual channels.

For the second error, we will try to minimize some signal integrity issues that might cause the overflow in the FIFO feeding Xillybus Virtual channel.

However, we have no idea about the errors occurring at 11:59 PM.

best regards

Hello,

I know too little about your design to say anything definite, however it looks like the mechanism for handling overflow conditions needs some looking at. Since it's a corner-case kind of mechanism, it may have worked well in the conditions it met previously, but not the one that are thrown at it after moving to Windows 10. Not to mention that it was apparently designed based upon a misconception on what a synchronous Xillybus stream is.

Speaking of which, I don't think you really want to have a synchronous stream there. In fact, there are very few cases where it makes sense to have a synchronous stream in the FPGA to host direction. What it currently does, is to require that the host issues a read() call frequent enough to prevent the FIFO from overflowing. This is most likely unnecessarily strict. You probably want the DMA buffers to be filled "in the background" as it arrives to the FPGA's FIFO, so that the host can read it slightly later.

In fact, I won't be surprised if the problem goes away if you change that stream to asynchronous. But I wouldn't do that, because that would hide a bug in the overflow protection mechanism. And then you probably want to get rid of that Windows service.

But why does it work for hours despite all this? Well, I always say that a good debugging session begins with asking why something specific doesn't work, and ends with asking why anything worked at all.

Regards,
Eli

Hello

So in our tests, we try to get data from application FIFO in FPGA to PC using synchronous Xillybus stream on a specific Virtual Channel.
We have flow control in FPGA which guarantees that application FIFO does not overflow.
Both software and FPGA mechanisms work well for hours.

But why do we observe the second error?

best regards

Hello,

tozkoparan wrote:Hello
The software reads the data synchronously which must not return successfully if sufficient amount of data is not pumped from Xillybus Virtual Channel.

That's actually not the definition of a synchronous channel. It a read() call from a synchronous channel may very well return with less than the requested data. A synchronous Xillybus stream may however not read data from the FIFO on the FPGA unless there's a read() on the host expecting that data. That's what synchronous stream is about.

Please refer to section 2 in the programming guide for Windows:

http://xillybus.com/downloads/doc/xilly ... indows.pdf

Also note that section 3.2 in the same doc says nothing about synchronous or asynchronous streams.

So given this clarified misconception, I think we're closer to a solution.

Regards,
Eli

Hello

You are right

However, let's say that our mechanism has errors that make the overflow signal go high.
In this case, it is not possible for the software that reads Xillybus DMAs to collect fixed and known-sized data because our FPGA application pumps only fixed-sized data(not more)
The software reads the data synchronously which must not return successfully if sufficient amount of data is not pumped from Xillybus Virtual Channel.
Since Xillybus Virtual Channel is connected to a FIFO which goes to overflow how could PC software return successfully?
If our mechanism has an error then the software reading Xillybus DMA must wait forever.(This is the situation which we sometime observe while developing our system)

We are using Xillybus for quite a long time. However, we can not solve this problem sadly.

best regards

Hello,

If I got it right, you did see an overflow condition on the FIFO even though there's a mechanism that should make this impossible.

In other words, regardless of whether Xillybus' IP core reads data from the FIFO or not, your application logic should make sure the FIFO never overflows, and also that the data doesn't get messed up, I guess. And yet the LED showing that the FIFO gets overflowed, which should never lit, went on anyhow.

Am I right?

If this is indeed the case, it seems like this mechanism doesn't work. So this would be the first thing to look at. And then try to figure out why the host application gets slowed down at regular wall clock times.

Regards,
Eli

Hello

Maybe it is my fault not to declare explicitly that we have a flow control mechanism in our FPGA design for both directions (PC->VC707 and VC707->PC)
Therefore we are sure that no matter at what speed PC software collects data from Xillybus our application FIFOs connected to Xillybus virtual channels must not go to overflow since the read enable signals of our FIFOs are connected to Xillybus Virtual channels controlled by the IP and we apply flow control to write enable signals of our FIFOs at FPGA design.

Our expectation is that even if the CPU of the PC is busy and does not collect fast, the flow control in FPGA design must protect any unknown data to be present on the PC side.

best regards

Hello,

Your description is consistent with a situation where your host software was halted momentarily because the computer suddenly got busy doing something else. If your software does some disk access while running (e.g. reading or writing data), that's even more likely to happen.

I suggest following the principles outlined in section 4.4 and 4.5 in the FPGA designer’s guide:

http://xillybus.com/downloads/doc/xillybus_fpga_api.pdf

Namely, to stop the data flow from the FPGA to the host with an EOF when an overflow occurs. This allows the host software to easily detect an overflow condition, and report it as such. Also, the logic accepting data from the host should stop fetching data when it reaches an underrun condition.

Both these measures ensure that if data is transmitted, it's correct. The fact that you get garbled data is most likely due to overflow / underrun. The possibility of a core or driver bug can be ruled out quite certainly, in particular as these have a very large mileage without any issue of that sort.

Regards,
Eli

Hello

In our FPGA design on VC707, we have FIFOs connected to each write and read channel of Xillybus.
Overflow and empty signals of these FIFOs are connected to LEDs on VC707 to debug the data communication.
With these debug signals it is possible for us to understand whether the FPGA design has bugs or software collecting data from DMAs of Xillybus on PC has errors.

For the second error we mentioned before, after a couple of hour tests, suddenly,

When data(with fixed size) is read from one of the synchronous channels we are getting the data.
However, its content is not as we expected.
We are thinking that somehow software reading data from Xillybus DMAs in PC is disordering data. (Some kind of pointer problem)
Our test software stops here since the data is not as expected.
When we check our test LEDs in this situation, we observe that the FIFOs are not empty and there is overflow in the FIFOs.
This is also not correlated with our expectations.
Because even if software reading data from Xillybus DMAs makes errors our FIFOs must not go to overflow situation.
Since our FIFOs are not empty we understand that software reading data from Xillybus DMAs to PC has errors.
It does not get the correct amount of data from FPGA since the FIFOs are not empty.
This indicates a software problem. However, the overflow signal prevents us to come to a conclusion.

best regards