Hi there,
I am aiming to work with the buffered pipes.
The data I am passing is bursty but always valid on the edge of a 9MHz clock.
I assume that the clock input to the BufferedPipe’s needs to be higher than the clock rate for the data…? If so, how many clocks per data byte is needed? It should be fairly trivial for me to set up a PLL clock with suitable clock rate, just want to make sure it is suitable… 
Cheers!
Hi Phloyd-
I’m not exactly sure what you mean. On the endpoint side of the BufferedPipe, your clock and data need to be at the same rate. You use the EP_READ (BufferedPipeIn) or EP_WRITE (BufferedPipeOut) to indicate how to enable reads and writes with the FIFO built into the BufferedPipe.
9MHz will work just fine with the BufferedPipe. Remember that the BufferedPipe just provides a FIFO to the normal Pipe endpoints. It is still your responsibility to check the FIFO status before reading or writing to the FIFO. This applies on -both- sides – your endpoint side and the PC (FrontPanel API) side.
From the documentation:
EP_CLK - Input - Endpoint clock.
Because the FIFO is asynchronous, the two ports can run with
different clocks (TI_CLK for the target interface side and EP_CLK for the user-logic side).
EP_WRITE - Input - When asserted, writes the data on EP_DATAIN to
the FIFO and advances the write pointer to the next
datum.
–
Now, from this information I gather that the FIFO will latch the data on EP_DATAIN[15:0] at the next EP_CLK after EP_WRITE goes high.
My question is, how many clocks per data is needed?
Perhaps it only needs one and it is possible to latch new data on every clock cycle? (assuming that it is not full)
Also, does it latch on the rising or falling edge of the clock?
Or does the clock play no part in the latching of the data?
If it is the clock that latches the data, how much set up time is needed on EP_DATAIN[15:0] and EP_WRITE before you clock in the data?
It would be useful to have a timing diagram noting set up times and hold times as well as which signal edge actually latches the data into the FIFO…
As it stands, the documentation seems a little ambiguous.
Thanks for your attention. I think this module is great!
Cheers!
Hi-
Yes, we have left out some details in the documentation. Primarily because the block is documented in a Xilinx app note (XAPP 131). I have attached it to this post for your reference.
To answer your questions, though, the block can accept data on any rising edge of EP_CLK as long as it is not full. Setup time for EP_DATAIN will depend on your design – routing delays and other such things factor into this. The setup time for the BRAM used in the FIFO is 0.49ns according to Xilinx DS099 (Spartan-3 datasheet), table 27. Likewise, setup time for EP_WRITE varies according to the design.
For setup/hold information, it is generally easiest to use the timing analyzer tools to determine this information for a specific design. The switching characteristics of the device are detailed in the datasheet and can help give you an idea.
There are quite a few sources of information to pull from to get all this stuff.
App131 - Asyncrhonous FIFO.pdf (83.5 KB)
Phlyod / Jake,
I was reviewing the latest software releases and noticed many changes (it’s been a while).
You have a new timing diagram for the Pipe implementation where the data is valid two cycles after a READ signal is asserted. Does this apply to the buffered pipe as well? Do we still refer to the XAPP131 for this timing?
Also, do you have buffered pipes in your front panel simulation examples? I did not see any in the DES or First incarnations.
The PIPES verilog samples for version 1 differs than that of version 2. Is there a reason version 2 employs Buffered Pipes and Version 1 does not?
Thanks,
Adrian
Hi Adrian-
The BufferedPipe does use the Pipe for its implementation. In fact, the timing of the FIFO in the BufferedPipe was the primary reason for the timing fix in the Pipe. However, the “user-side” of the BufferedPipe has not changed. It’s timing is still dictated by XAPP131.
I’d also like to comment about the BufferedPipe. You can achieve the same result if you have the CORE generator – construct an asynchronous FIFO CORE and attach it to the PipeIn or PipeOut module. The CORE generator FIFO is newer and far more flexible in what you can do with it. This is therefore the preferred method of building a buffered Pipe. We include the BufferedPipe primarily for folks that do not have the CORE generator because they are using Xilinx’s free WebPack.
Regarding the v1 and v2 Pipe sample – we added a short test to PipeTest to exercise the BufferedPipe. That’s why that has been added. We just never back-ported it to v1. Aside from that, there are no samples of the buffered pipe. I think our new RAMTester includes BufferedPipes, but it has not been released quite yet.