I carefully went through your documentation (XEM3001) but I didn’t found reference about which kind of transfers you are implementing (bulck/isochronus).
Again I didn’t found any reference values for the maximum read/write data rate reachable with your solution.
I’m currently working on an application where a continuous data transfer rate up to 20 Mbytes/sec is required (for both read and write). I just need to know:
what are the maximal continuous data transfer rate that I’ve to expect ?
did you implement isochronous transfers ?
Thanks in advance, JOBRE.
P.S. I erroneously sent this thread to the “announcement†list. Please remove it if possible.
Transfers are done using USB bulk mode. We currently see maximum transfer speeds (using FrontPanel 1.3.0 which is due this week) of 33MB/s to the FPGA and 19MB/s from the FPGA. Note that these are maximum transfers and assume that no handshaking is required between the PC and FPGA. The addition of handshaking will slow things down – the amount of lost performance is related to how often handshaking queries need to be performed.
I assume that no handshaking is needed for continuous data stream transfer. Once the up/down stream transfer is activated the whole handshaking process is already done by the FPGA FIFO empty/full status signal. Am I wrong ?
With which setup you reached the “33MB/s to the FPGA and 19MB/s from the FPGA” data throughput ? Did you used the memory expansion board ?
I’m planning to design a custom expansion PCB provided with a high speed 18bit X 64K KWord (128 KB) synchronous FIFO used as data buffer, did you think that this will be enough to guarantee 19 MB/s up/down bandwidth ?
I’m sorry but I need to be absolutely sure that with the XEM30001 I’ll meet the final target spec. of my application (real time, high speed data capture & replay). I’ve actually built a such a system using a USB2FPGA dev. board of one of your competitors and the system is working but, the lack of support and the size of the final system makes the result not useful for the production.
The FIFO full/empty flags do -not- perform handshaking automatically. These flags must be read separately. Generally, the API works best if you know how much you want to transfer and the FPGA is in a situation where it can provide it without issue. I’ll give you two scenarios.
You implement a FIFO (either internal or external) and you also provide a buffer status word that indicates how many words are in the FIFO. You periodically read this and transfer that much data. Therefore, you guarantee you will not overrun or underrun because you know how much to read/write. It is the periodic checking of the buffer status that slows you down.
In our sample SDRAM controller (for the RAM3001), we provide a stream-capable SDRAM controller that works like this: The SDRAM controller is very simple – it only handles refreshes and page (512-word) transfers to/from SDRAM with auto-increment of the row address. On the FPGA, we have two asynchronous FIFOs – one for each direction, to SDRAM, from SDRAM.
When a page is available for write to SDRAM, a page write occurs. When there is room in the FIFO for a page read from SDRAM, a page read occurs. The Host Interface (USB) runs at 48 MHz and the SDRAM runs at about 100 MHz. Therefore, the SDRAM can always keep up with the host interface.
This simple cache-like design allows us to stream a block of data directly to the SDRAM or from the SDRAM at full speed. We have used this design several times in data processing, audio streaming, and image capture.
I have the same question. So Im interested in this topic.
I do not understand something. Why do you habe a bandwith of 33MB in a way and only 20Mb in the other way.
The full bandwith of usb 2.0 is 460Mbits and 460Mbits~33MB+20MB. Is the bandwith of the usb 2.0 intrinsically separated between upload and dowload ? Is it your own choice of implementation ?
Well, the signaling rate of USB 2.0 is 480 Mbps. This is, of course, not realizable in any implementation because it does not consider any of the USB protocol (headers, error correction, link-layer restrictions, and so on).
Our implementation is slower than what is possible, however, and this is partly due to the abstraction we provide. That is, the convenience of having multiple pipe in / pipe out connections as well as wire and trigger capability provides considerable convenience, if at some sacrifice in performance.
That is, the convenience of having multiple pipe in / pipe out connections as well as wire and trigger capability provides considerable convenience, if at some sacrifice in performance
Do you plan to create a mode where the triggers are desactivated and where there is a single pipe (in or out) going at maximum speed ? I plan to use an ADC 16bits@10Mhz(~160Mbits) and I want to store its record on the HD of a PC. I have to find a board that can such a bandwith. You seem to be very near from that performance ?
Do you think that you can add a specific fonction that enables this rafale transfer mode. I see many people using such board to control HD, video. For myself, I do vibration analysis. I should use such boards for interfacing each probe to the pc.
Perhaps, you haven’t thaught to such applications when you designed the board. For two months I look at all the boards on the market around the www. I have studied the full web site of national instrument
. The sole usable peripheral they propose is a parallel port of 32bits@20Mhz. The price 2000$, and you have to plug it in a pci port, I mean you can not use this board with you laptop. A wonder when you have to make measurements outside of your lab
Your board is an entirely new solution for me. And for other like joebre I think. The fpga allows to manage the transmission, create packet and easyly manage the usb transfer. When I have other chipset (amplificator, clock generator) I can use the other wire to program them… It is very handy AND cheap
2000$, and you have to plug it in a pci port, I mean you can not use this board with you laptop. A wonder when you have to make measurements outside of your lab 