by support »
Hello,
I suppose this is a follow-up on this post:
viewtopic.php?f=4&t=464I would, again, suggest to work with FIFOs as I suggested in the previous post. In order to keep control on the latency, I would suggest maintaining a counter of the number of
samples (not chunks) that have been consumed by the FPGA, and keep reading that one instead. This way, the software can compare how much it has sent vs. how much has been consumed, and always have a view on how much is buffered. Needless to say, this counter must be reset when the respective stream is closed (easily done using the *_open ports exposed by Xillybus).
The easy way is to connect this counter to a 32-bit stream's data input port, tie that port's "empty" line to zero, and ignore all other ports. Making sure the stream is synchronous (setting the use to e.g. "Short message transport"), when 4 bytes are read from the stream, they reflect the current situation of the counter. I suppose this is what you did.
Now all the software needs to do, is to read the counter's value, and write the number of samples that maintain the desired buffering amount.
As for avoiding delays in the PC-to-FPGA stream, make sure it's asynchronous, and use zero-write calls to push the data towards the FPGA. See
http://xillybus.com/doc/xillybus-latencyWhen done this way, the only possible reason for drop-outs is CPU starvation on your C program. If you're running it on a fullblown Linux system, there are all kind of things that can happen that may halt your execution. Even silly things, such as status messages on the console for debugging, which are prevented from being written because they go to a console window, which is in turn frozen by some desktop graphics effect being stuck for a short while.
Regards,
Eli
Hello,
I suppose this is a follow-up on this post:
http://forum.xillybus.com/viewtopic.php?f=4&t=464
I would, again, suggest to work with FIFOs as I suggested in the previous post. In order to keep control on the latency, I would suggest maintaining a counter of the number of [b]samples[/b] (not chunks) that have been consumed by the FPGA, and keep reading that one instead. This way, the software can compare how much it has sent vs. how much has been consumed, and always have a view on how much is buffered. Needless to say, this counter must be reset when the respective stream is closed (easily done using the *_open ports exposed by Xillybus).
The easy way is to connect this counter to a 32-bit stream's data input port, tie that port's "empty" line to zero, and ignore all other ports. Making sure the stream is synchronous (setting the use to e.g. "Short message transport"), when 4 bytes are read from the stream, they reflect the current situation of the counter. I suppose this is what you did.
Now all the software needs to do, is to read the counter's value, and write the number of samples that maintain the desired buffering amount.
As for avoiding delays in the PC-to-FPGA stream, make sure it's asynchronous, and use zero-write calls to push the data towards the FPGA. See http://xillybus.com/doc/xillybus-latency
When done this way, the only possible reason for drop-outs is CPU starvation on your C program. If you're running it on a fullblown Linux system, there are all kind of things that can happen that may halt your execution. Even silly things, such as status messages on the console for debugging, which are prevented from being written because they go to a console window, which is in turn frozen by some desktop graphics effect being stuck for a short while.
Regards,
Eli