by support »
Hello,
Technically speaking, if the DMA buffers get full, the Xillybus IP core at the FPGA stops transporting data from the FPGA's FIFO into these buffer, and soon the FPGA overflows. Once the host starts reading the data from the device file, DMA buffers are made vacant, and the IP core resumes transporting data, taking the FPGA's FIFO out of the overflow condition. But as a result, the data that arrives to the host will not be continuous.
The question is what the nature of the trigger is. If it's an event taking place at the host, you may simply open the device file when on the trigger event and start reading data from that moment on. The FIFO's reset input should be connected to the respective Xillybus stream's inverted open signal, so when the device file is closed, the FIFO is held reset. This gives a clean start.
If the trigger event can be detected on the FPGA, it's also possible to begin pushing data into the FIFO only after the trigger has occurred.
However if the trigger is known only in retrospect, and you need the data before the trigger, then you should read the data continuously, keep it in a large RAM buffer in the application program, and then fetch the pre-trigger data from that RAM buffer once the trigger is detected. Reading data directly into a RAM buffer is a low-CPU task, so there's no significant penalty for this solution, even at the highest bandwidths. The fifo.c example code, which comes along with the example programs (which is also explained in Xillybus' programming guides), can be used as a starting point for implementing such a RAM buffer (but it needs some modification, of course).
Regards,
Eli