by support »
Hello,
The sample utilities, with fifo.c included, can be downloaded from the site's main download page:
http://xillybus.com/downloads/xillybus.tar.gzfifo.c can be found under xillybus/demoapps. I should mention however that in the vast majority of cases, it has no practical use, because Xillybus' DMA buffers can usually be configured (at the IP Core Factory) to be large enough for most purposes.
If you intend to use synchronous streams, I'd suggest using the Linux driver on that bundle as well, if your Linux happens to run on a kernel between v3.17 and v4.6 (v3.17 included, v4.6 excluded). Unfortunately, a bug sneaked into the driver while adapting it to Linux' coding standard, but was never in the driver available for download at the website. This bug essentially makes an synchronous stream asynchronous.
As for maintaining 4-byte alignment: The guidelines for proper I/O are given in section 3 of the Programming Guide,
http://xillybus.com/downloads/doc/xilly ... _linux.pdf . For the experienced UNIX programmer, there is really nothing new in that section: It's just the common practice for robust I/O on a UNIX system. Also, the allwrite() function in the demo application implements these guidelines.
But even without proper interrupt handling and such, there is no way that a read() or write() call will break the stream's natural alignment as long as the number of bytes requested are a multiple of the stream's width. In other words, if you request 1024 bytes on a 4-byte stream, you might get 1020, but not 1021 (unless the alignment has been messed up on a previous read/write call).
As for your third question, synchronous streams do nothing in favor of or against keeping the 32-bit alignment (which isn't an issue anyhow, as said above). It merely makes sure that the data is consumed at the FPGA side only when requested by the host's program, and not prefetched. So it's indeed the correct thing for obtaining "live" data.
The FPGA's logic doesn't need to be aware of the nature of the stream it's connected to. But the FIFO-in-the-middle method might not be the right way for "live" data, as the data in the FIFO has to be fetched at some earlier time. For just sampling a 32-bit GPIO word at the FPGA, consider connecting the wires for sampling directly to the Xillybus core's data wires, and tie the respective "empty" port low. If the stream is synchronous, a plain read() call of 4 bytes will fetch an updated sample of the word each time. Just don't forget that the data presented to the Xillybus core (as well as all other signals) must be clocked with bus_clk.
Synchronous streams are explained in section 2 of the Programming Guide. If you want to understand the underlying mechanism, Appendix A describes the under-the-hood part. In particular, note the remark on synchronous streams at the end of section A.3.3. That's all there is to it. Reading the Appendix is however suggested only out of curiosity: To get it working right, following the guidelines is enough.
Regards,
Eli
Hello,
The sample utilities, with fifo.c included, can be downloaded from the site's main download page: http://xillybus.com/downloads/xillybus.tar.gz
fifo.c can be found under xillybus/demoapps. I should mention however that in the vast majority of cases, it has no practical use, because Xillybus' DMA buffers can usually be configured (at the IP Core Factory) to be large enough for most purposes.
If you intend to use synchronous streams, I'd suggest using the Linux driver on that bundle as well, if your Linux happens to run on a kernel between v3.17 and v4.6 (v3.17 included, v4.6 excluded). Unfortunately, a bug sneaked into the driver while adapting it to Linux' coding standard, but was never in the driver available for download at the website. This bug essentially makes an synchronous stream asynchronous.
As for maintaining 4-byte alignment: The guidelines for proper I/O are given in section 3 of the Programming Guide, http://xillybus.com/downloads/doc/xillybus_host_programming_guide_linux.pdf . For the experienced UNIX programmer, there is really nothing new in that section: It's just the common practice for robust I/O on a UNIX system. Also, the allwrite() function in the demo application implements these guidelines.
But even without proper interrupt handling and such, there is no way that a read() or write() call will break the stream's natural alignment as long as the number of bytes requested are a multiple of the stream's width. In other words, if you request 1024 bytes on a 4-byte stream, you might get 1020, but not 1021 (unless the alignment has been messed up on a previous read/write call).
As for your third question, synchronous streams do nothing in favor of or against keeping the 32-bit alignment (which isn't an issue anyhow, as said above). It merely makes sure that the data is consumed at the FPGA side only when requested by the host's program, and not prefetched. So it's indeed the correct thing for obtaining "live" data.
The FPGA's logic doesn't need to be aware of the nature of the stream it's connected to. But the FIFO-in-the-middle method might not be the right way for "live" data, as the data in the FIFO has to be fetched at some earlier time. For just sampling a 32-bit GPIO word at the FPGA, consider connecting the wires for sampling directly to the Xillybus core's data wires, and tie the respective "empty" port low. If the stream is synchronous, a plain read() call of 4 bytes will fetch an updated sample of the word each time. Just don't forget that the data presented to the Xillybus core (as well as all other signals) must be clocked with bus_clk.
Synchronous streams are explained in section 2 of the Programming Guide. If you want to understand the underlying mechanism, Appendix A describes the under-the-hood part. In particular, note the remark on synchronous streams at the end of section A.3.3. That's all there is to it. Reading the Appendix is however suggested only out of curiosity: To get it working right, following the guidelines is enough.
Regards,
Eli