How to handle in FP a continuous data streaming from fpga?

@O-K
It was made clear in the manual that
“FrontPanel does not support USB isochronous transfers.”

However, in my data acquisition applications, the data needs to be continuous streamed out to the host pc. In the past, I had been using a “forever loop” sort of procedure to handle this;

  1. FPGA starts the ADC, and fill up a data buffer, and when that is done
  2. FPGA issues a TrigOut for the host, and then goes back to step 1 and starts over again

On the host side, FP captures the data by

  1. continuously monitors with updatetriggerouts call, and upon detecting a trigger
  2. reads out the fpga data buffer with readfromblockpipeout call, and then goes back to step 1, starts over again

That works fine, as long as my application could tolerate the time that the trigger monitoring takes between two readfromblockpipeouts. The trigger monitoring is time consuming, and thus limits the rate of executing readfromblockpipeout calls.

In my new application, I need to improve the efficiency of that data transmission. What I want now is to skip the trigger monitoring, and continuously do readfromblockpipeout. Is there a way (or mechanism) of flow control that allows me to continuously “pipeout” the data frames in fpga buffer, and to handle the incoming continuous pipeout data blocks in FP, without having to check triggers ? Thanks :slight_smile:

In other words,
if the fpga sends out of frame of data with okPipeOut on its own, what methods a host application should use to be aware of the incoming data block, and to handling ?

And what in the case that the fpga continuously issues okPipeouts on its own ?
What methods in FP to use to handle this kind of data transmission in which the fpga acts as the master :confused:

It has been a few years since last time I used FP. I might have forgotten some of the important limitations with it. Under FP, the fpga can never initiate any transactions, specially pipes, by itself. The FPGA is always a slave.

But:confused: the question remains, how to continuously stream data with FP ?:confused:

As you said, the host always initiates a transfer. Just as with any master/slave protocol, you “continuously stream” data by continually initiating transfers.

No matter what the underlying protocol, somewhere, someone, somehow needs to be aware of the start of frame (SOF) and end of frame (EOF) in such a situation.

One way to accomplish this sort of thing with FrontPanel is illustrated in our EVB1005 / EVB100X-DEV evaluation kit that includes the sources for this. We essentially stream video in this fashion, but incur some overhead as we wait for a frame to become available. The key is to use longer frame sizes to read out 256kB or 1MB of data each time and the overhead becomes insignificant. An alternative to the TriggerOut method is to send out the amount of data you have in the buffer on a WireOut, then read this amount.

NOTE: A notable exception to this is protocols that have a built-in overhead to provide additional characters. For example, 8b/10b encoding has a 25% overhead, but is able to stream data without SOF/EOF by using idle or comma characters. You could emulate this functionality by encoding the data thrown into the pipe with overhead per byte. That overhead would ride alongside the data and indicate when a particular word or byte is valid. The cost of doing so is similar to the 8b/10b issue – you have an overhead per unit of data. This overhead is far more expensive than the SOF/EOF overhead. With 8b/10b, you get it “for free” because you presumably need the overhead for physical layer implementation anyhow.

Thanks for the discussion. Sending you an email for more.