I’m very seriously thinking of buying one of your XEM3001 boards, but I’d like to know something first:
What is the maxiumum sustained throughput you have gotten (with real code) in each direction (XEM -> PC and PC -> XEM)?
I’m investigating your product for use in a new high speed logic analyzer/AWG (arbitrary waveform generator) and one of my key design questions is the throughput in each direction.
Thanks!
Sincerely,
*Brian
Hi Brian-
Sustained throughput without any negotiation is about 12.5 MB/s (to FPGA) and 7 MB/s (from FPGA). These are numbers achieved with our “PipeTest” application running on a Windows XP (SP2) machine with USB 2.0.
This rate will decrease if you need to do any negotiation. That is, if you need to query the FPGA to see if data needs to be transferred. One example of this negotiation is polling to FPGA to determine the level of a FIFO. The amount of decrease depends, of course, on the rate at which you do this polling.
Cheers,
Jake
Jake,
Thanks for the info! That’s exactly what I needed.
I'm curious - are you using the FIFO interface of the USB chip? From Cypress, it looks like you can transfer around 96MBytes/sec. Can you talk a little bit about how the data gets from the FPGA to the USB chip? Like what mode you're using (if you are using the FIFO - Maser or Slave, etc.)
I've never used the Cypres FX2 chip before, so some of these questions might be very nieve in nature. Do you provide the source code for the code running on the FX2?
Thanks!
*Brian
OK, so I read Cypres’ “Measuring Delivered USB 2.0 Bandwidth with an EZ-USB FX2 Development Board” app note, and it looks like with an ideal system, about 40MB/s is what to expect theoritically out of the USB chip, with 20 being more realistic. So your 12 and 7 seem pretty good. What’s the limiting factor?
*Brian
One limiting factor is that the XEM is designed to abstract the USB interface from the user. In the interest of providing several available channels between the PC and the FPGA chip (called Pipes in our nomenclature), some speed hit is taken. i.e. there is some overhead involved.
USB itself is a shared bus, so much depends on what other devices are consuming bandwidth.
In dedicated, bursty transfers of moderate length (say a few seconds), I’ve seen pretty good rates. I have a system that integrates with Matlab and sends several channels of audio samples through the XEM and I can do better than real time in many cases. If your transfers start to tax the PC, though, transfers will slow down. An example is when there is other work being done on the PC and it starts to swap.
I have a firmware upgrade that should increase the read rate (FPGA to PC), but it isn’t available quite yet. It certainly won’t be any faster than the 12 MB/s. We are also planning another board that will include on-board RAM and higher transfer speeds – probably closer to the 20 MB/s range.
Jake
P.S. I missed your other post… The FIFO can do high transfer rates, but the question is – where does it get the data. The USB bus at full-tilt will only provide -half- that rate and that doesn’t include any of the USB overhead. So, you can expect high-speed bursty stuff for the length of the onchip (FX2) FIFOs, but that’s about it.
Regarding source code – we don’t provide the source code to the FX2 except under license. If you want licensing information, you can email [email protected].
37258.jpg (15.5 KB)
Ahh, OK. I’m understanding things more clearly now. So you lock your customers into either buying your boards (which include the software) or if a customer wants to build his own boards, he’d have to licence the underlying code (on the XEM and PC side). That makes total sense - we do that where I work (Logic Product Development) as well to make sure people buy our boards. (and we recoup the development costs)
The reason I’m interested in the XEM is to build a tool like I said before. But I want to make an open-source hardware and software project for engineers - I don’t want to build a comercial product. I just want a little box on my desk that will be a 2 channel 100 MSample digital Oscope, 16 channel digital logic analyzer, arbitrary waveform generator, and some other optional modules (JTAG, serial/I2C/SPI analyzer, variable power supply, etc). My dream is to publish plans for anyone to make their own, including the communications spec and API for the data going through the USB so anyone can write their own PC front end. I have one of the BitScope (
www.bitscope.com
) units and I just love it, but it has been changed from an open design (as it was origionally) to more of a commercial product. The protocol is still open, so people can still build their own front ends, but the hardware has gotten expensive, and they don’t provide FPGA (CPLD) or microntroller source, so you can’t add your own features to the hardware. That’s what I’d like to do. Build a better BitScope, and the XEM looks like a good way to do the origional R and D.
I am still interested in your XEM as a starting point for developing the project, however, so I may buy one. I’m just not sure if I want to get too locked into using your software. Something for me to think about anyway.
Thanks for all of the info -
*Brian
Has the pipe test been run with Python? What throughtput was observed?
We have yet to test the Python throughput, but I would expect similar results – the thing that hurts is any overhead for performing negotiation with the sender.
If things are setup properly (buffered a lot), then the overhead is less a factor.