I have a data capture design on a ZEM4310 and have not been able to get the USB 3 ~300MB/s advertised performance from a non-blocked okFilePipe. Using a blocked okFilePipe (and okBTPipeOut) I get a little over 50MBytes/s. Changing to a non-blocked okFilePipe (and a okPipeOut) yields the same data rate. FP is reporting SuperSpeed. I’ve tried both a Win8 and Win7 PC and get the same results. I then created a Verilog file with only the okPipeOut and a FP with only a non-blocked okFilePipe and get the same results. OK tech support haven’t come up with any ideas or suggestions yet. I’m looking at the read signal on a pin on the FPGA with a scope and see a burst read of 164us, followed by around 900us of no reads (around 15% utilization).
Since I’m using the XML non-blocked okFilePipe instead of the API, I don’t expect to get 300MB/s rates, but as stated in the FP manual I do expect to get improved data rate over my blocked pipe 50MB/s. Any ideas on what’s going wrong or things to try? Thanks for any help!
Please try our PipeTest sample. The source is included with the samples, so you can see there isn’t any trickery going on here. We regularly see 340+ MiB/s on all our USB 3.0 devices to Windows PCs and Macs alike.
Also note that performance may vary depending on computer. We recommend starting with PipeTest to see what you end up with (use the “bench” command line argument to benchmark).
Also note that the published numbers are based on the C++ API. We have not benchmarked the okFilePipe.
BBertrand – 100 MB/s is pretty dismal performance. Typically, you should expect to see 300+ MB/s. And on good systems (modern PC / Mac hardware), 340 MB/s or more.
What transfer size per pipe call? To get good performance, you will want to be upwards of 4 MB per call.