WIN 10 Xillybus driver

[tozkoparan]

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

[support]

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

[tozkoparan]

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

[support]

Hello,

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

[tozkoparan]

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

[support]

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

[tozkoparan]

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

[support]

Hello,

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.

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