okBTPipeOut

Hello.

I haven’t yet acquired an XEM3001 board, so forgive me for asking a question that may seem relatively simple.

I am developing a high-bandwidth data acquisition device (~26 to ~100 Mbps depending on what we can get), and I want to stream it in real time to the PC over USB2.

I see the HDL module “okBTPipeOut” which has a “ready” signal to indicate whether there is data ready to be sent over USB to the host. I was thinking I could use this to keep the FPGA from transmitting data when there is none to be transmitted.

I will be using the FrontPanel C++ API to acquire data from this board. From the FrontPanel documentation, it understand that if I call the ReadFromPipeOut() method and EP_READY is not asserted, the call may simply fail with a timeout. I assume this means that the pipe will be polled for some time to see if data becomes available.

Will I see a major performance drop if this method is used? If the FIFO is empty when I first call ReadFromPipeOut(), what is the polling period? Will it wait for only a few microseconds and check again, or will it wait for some number of milliseconds before checking EP_READY again? A millisecond may overflow my FIFO’s.

If I were to guess, I would guess that SetBTPipePollingInterval() sets the interval at which the pipe will be polled, and SetTimeout() sets the interval which would cause a timeout. But since SetBTPipePollingInterval() takes an argument in milliseconds, I think this may be too long.

Was the okBTPipeOut module designed to be used this way? Can I achieve a transfer rate of at least 100 Mbps while using it? Adding a large FIFO is an option but I would like to avoid it if possible.

Sorry if anything is obvious or unclear - I don’t have too much experience with the XEM3001 or USB transfers in general.

Thanks,
Josh

Josh–

As with any communication protocol, buffering improves throughput at the expense of latency.

The XEM3001 has limited memory for buffering, so if the PC gets busy and cannot respond immediately to a request, data will be building up on the FPGA and have nowhere to go. Eventually, this will lead to an overflow. Neither Windows nor USB will guarantee that nothing will take higher priority.

For DAQ or streaming or buffering applications such as yours, we recommend using larger buffers that can be made to absorb the data for a little while. Our XEM3005 or XEM3010 are better suited for this because they include an SDRAM onboard that can easily be setup as an elastic buffer.

Thanks for the response - actually we’ve already ordered the XEM3001 and the 4Mbit SRAM expansion board so I would like to use those if possible.

Assuming I used a large buffer to prevent FIFO overflow due to OS/USB holdups, would using the okBTPipeOut provide support for the bandwidth I need?

The reason I ask is that a common issue on these forums seems to involve USB timing and transfers that shift data out faster than it comes into the FIFO, which I think could occur in my situation since you’ve tested transfer rates much higher than 100Mbps, which would be the highest rate at which we would sample. I thought perhaps using this HDL module would be a decent way to combat that, but I need to know what kind of polling period to expect, so I can plan my buffers accordingly.

By my calculations, at 100 Mbps, using the 4MBit expansion board, I could handle an approximate ~40ms “lapse” in transmission. Upon your past experience, would the software API be able to poll the okBTPipeOut at a faster rate than this? In normal operation, would WinXP ever lapse for a period longer than this?

Thanks,
Josh

We are FPGA amateurs…our experience is based upon modifying pipetest.

We can keep up 30MBytes/sec… BUT. On XP sp3 the usb freezes for upto 500ms from time to time.
On Linux(fedora core 7 )we haven’t seen a large hole, but small holes. just big enough to overflow the largest fifo we can make on the spartan.

We need the SDRAM to help us over that “lump” (hence why we have just ordered a couple) We couldn’t use the SRAM card as we need lots of pins.

We realised the transfer rate table in the docs and the dependence of transfer rate on transfer size, it is the key to going quickly.

Paul

Right. To be clear, Windows XP is not a real-time operating system. As such, it makes absolutely no guarantees for how long it can or will lapse.

The key is to build in enough FIFO to make yourself confident it won’t affect you.