Several questions regarding the usage of buffered out pipes



I have a design that generates 16 bit data words at non predictable intervals (but the average rate is reasonably upper bounded). I need to transfer these words the an application running on the host with a guaranteed delivery time of about 500ms (each word should arrive to the host not later than 500ms after it was generated).

The natural choice to interface with the host seems to be the BufferedPipeOut but I am not sure what is the ‘natural’ way of using the buffered FIFO’s for this purpose.

  1. The ReadFromPipe() method requires the exact length of the data to read, not an upper bound, right?

2.How can the application figure out the current size of the FIFO data so it issue a read command?

3.What happens if the application specifies in the read request the max size (representing full FIFO) while the FIFO is not full, will it be an error? Will it read just the available data and will indicate the actual size of the data read? Will it block until more data is available to satisfy the requested data size?

I can think of work arounds but none of them is clean, reliable or efficient. For example, having in the hardware a counter that increments on each word written to the FIFO and subtracted by software commands with the number of bytes read by the application.

What is the text book solution for reading from buffered output pipes?

From user perspective, it would be great if the read method would read as much data as avaialble in the fifo and return that count to the caller.

Also, my design uses a single buffered pipe so I presume that the Spartan 1500 has more memory than needed for the 2048 entries of the FIFO. Is it possible to have the BufferedPipeOut parameterized such that I can increase the FIFO depth? (either exact size or specifying x1, x2, x4 if it is easier to implement).

PS, the Verilog example in page 30 should have ep_datain instead of ep_dataout, right?




Hi Kam-

Your required latency is well within the bounds of what is possible with almost any method you choose.

For example, you could just send the data via a WireOut. You can use a TriggerOut to indicate if data is available and continually poll the device using “IsTriggered()” until data is ready, then do an UpdateWireOuts and get the data.

You could also use the PipeOut method. First, some history on the BufferedPipes. The Xilinx CORE generator was not included with the free Xilinx tools until recently. Since a Pipe/FIFO combination was useful, we modified the HDL from a Xilinx App note to suit our needs and included it as the Buffered Pipe.

Now that the Cores are available with WebPack, we highly suggest people use the FIFO Generator to create a FIFO and then couple it to the PipeIn or PipeOut. The generator produces more efficient and more flexible FIFOs than what we provide.

That said, the FIFO generator can produce a FIFO which gives you full granularity for its “fullness” – that is, you can know it to the word (or byte). You could then tie the rd_count or wr_count (buffer fullness) to a WireOut and periodically check to see how much data is sitting in the FIFO. You would then proceed to read that data out.

Underflow and Overflow conditions need to be handled by you either on the hardware end or the software end. Our experience is that every application places very different needs on the handling of these conditions. That is one reason we chose not to abstract beyond this point.

Regarding the typo: Good catch. It has been fixed. Thank you!


Thanks for the recomendation.

The WireOut approach would not work for since the events can come in fast bursts but the CoreGen FIFO has everything I need.



Oh… I missed that bit.

We have a couple image capture setups (one is low bandwidth, low latency – the other is higher bandwidth, but the latency is less of an issue). We can get up to 30 frames/sec of 320x256 data through using our standard API. CPU utilization for the capture is about 7-12%. Displaying the image takes more CPU.

On our other camera, we can capture around 120 fps in low-latency mode. The full 250 fps in with longer latency.

This should give you an idea of what sort of rates can be accomplished with polling. You’re way below these rates.