The Xillybus Forum

Hello,

For the FPGA-to-host case, Xillybus relies on the FIFO's "empty" output. The standard behavior of a FIFO is that when this signal isn't asserted (i.e. is '0'), asserting rd_en results in valid data being present on the FIFO's data output on the following clock. Xillybus relies only on this.

It's true that different FIFOs have a different latency from the first write operation until its "empty" output is deasserted. This is however irrelevant, as Xillybus doesn't care when the data was written, only that it's available.

For the other direction, it's the same kind of argumentation on the "full" signal.

Regards,
Eli

Hello

Actually, we are using application FIFOs as shown
http://xillybus.com/doc/xilinx-pcie-pri ... -operation

Xillybus IP core does not know the latency of application FIFOs.
You can generate application FIFOs having 0,1,2.. clock cycles read latencies.
Without valid signal of application FIFOs, how can Xillybus IP core know that the data it reads is valid?

best regards

Hello,

It seems like you're connecting your logic directly to the Xillybus IP core, instead of putting a FIFO in the middle. This requires that you emulate a FIFO's behavior (the FPGA API documentation explains how to do this), which is possible and legit, but most likely the difficult way to go.

Having a FIFO in the middle keeps the application logic, simple and based upon a well-established API with standard FIFOs. I would definitely suggest considering this path.

As for the delays between the "full" or "empty" being deasserted and data traffic taking place, this is somewhat random, as it depends on the state of Xillybus' internal arbitration machine. This way or another, this delay is in terms of microseconds, and is negligible compared with the delays imposed by the operating system on the host side. And having a FIFO inbetween exempts you from dealing with this issue at all.

Regards,
Eli

Hello again

thanks for your reply

After your answer, we realized that in our FPGA design we do not use the user_w_wr_fullXillybus signal
in order to determine the throughput of data stream going from HOST to FPGA.
After we connected this signal to a relevant signal in FPGA design we observe that FPGA is determining the
throughput of the data stream going from HOST to FPGA. Thank you.

Previously, we were using user_r_rd_emptyXillybus in our design.
With this signal connected to relevant signals in our FPGA design, HOST recognizes that FPGA has data
to be transmitted to HOST. As long as we do not exceed the maximum throughput capability from FPGA
to HOST, HOST takes data at the throughput that we pumped in FPGA design.

Therefore now, we use both user_w_wr_fullXillybus and user_r_rd_emptyXillybus signals to adjust the throughput
from FPGA to HOST and from HOST to FPGA.

Even if we do not observe any error in data streams transferred in both directions we are not sure about the latencies
of user_w_wr_fullXillybus and user_r_rd_emptyXillybus signals.

For example, if user_r_rd_emptyXillybus is connected to the empty signal of a FIFO in our user FPGA design how does
Xillybus module handle the uncertainties that can occur in this signal? We do not connect any valid signal to Xillybus module.

best regards

Hello,

The size of the file is irrelevant if the storage device is fast enough to supply the data at the desired rate. Xillybus' DMA buffer doesn't need to be large enough to contain the entire file either.

And even if I needed to supply or store data faster than my physical storage is capable of, I wouldn't go for fifo.c. For example, if you're running on a Linux system, a plain RAM disk which is large enough to contain the file is all you need. Copy the file from the real disk to the RAM disk, and then use "cat" to shuffle the data towards the FPGA. Simple and elegant.

I don't quite follow the concept of constant throughput. The typical usage is that the data flow is throttled by the the pace at which the FPGA writes data to the FIFOs or reads data from them.

So let's make this easier: Could you please explain what your setting is, and what you're trying to achieve? It looks like you're a bit off track.

Regards,
Eli

Hello,

Thank you for the response

Actually, we have test files of which sizes are 5Gbit, 10Gbit..... 300Gbit.
We want to pump these files separately from HOST PC to FPGA with constant throughput.
As you see the size of data is bigger than DMA buffer size.
Is our constant throughput constraint achievable with fifo.c?

Moreover, what can we do if we want to set constant throughput while pumping data with fifo.c?
Do we need to write our own code?

best regards

Hello,

fifo.c is just a memory buffer in the PC, that comes in as an extra huge buffer from standard input to standard output. It's actually not necessary in the vast majority of cases, because Xillybus' DMA buffers are usually large enough to take the load between accesses by the user space application, and the OS' disk cache averages the disk's data flow on the other side.

So plain Linux "cat" is usually enough for a fully functional data acquisition and playback.

To answer your question directly, yes, fifo.c can be used to send data from the PC to the FPGA, but once again, it may not be necessary. Unless you want to read a lot of data beforehand into the fifo.c program, and write it in one shot to the FPGA (if the disk isn't fast enough to keep up).

Regards,
Eli

Hello,

We are using fifo.c in demoapps folder to receive continuous data streams from FPGA and write to files in HOST PC.
Is it also possible to use fifo.c in order to send continuous data streams from HOST PC to FPGA?

Best regards.