Fast & Large block data transfer over USB - DE1/DE2 ?

Thanks re tutorial link, Dave, I will follow it up.

The transfer from the FTDI chip is essentially a 60MHz byte-stream (=480 Mbit/s), clocked straight into fpga 16bit memory.

Default USB transfer block size up to 64kByte (can be altered) .

Video 2 shows 5MWord data vectors being binned into a 2kWord x 16bit buffer, at full rate.

cheers,

Beau

--- Quote Start ---

The transfer from the FTDI chip is essentially a 60MHz byte-stream (=480 Mbit/s), clocked straight into fpga 16bit memory.

--- Quote End ---

No, its not.

The FTDI FT2232H

http://www.ftdichip.com/support/documents/datasheets/ics/ds_ft2232h.pdf

Has two FPGA interface modes:

* USB to parallel FIFO transfer data rate up to 8 Mbyte/Sec

* Single channel synchronous FIFO mode for transfers > 25 Mbytes/Sec

Since the Morph-IC-II interface uses channel 1 for programming the FPGA, that means channel 2 must be operating in FIFO mode.

At best, you can achieve a sustained transfer rate to the FPGA fabric of 8MB/s. However, once you account for the clock period and setup and hold times, you might get lower than this.

So my question is, "what sustained transfer rate did you manage to achieve?"

Tracing with SignalTap II would answer the question.

Cheers,

Dave

Yes I used synchronous FIFO mode in the FT223H for the data channel. A tricky data sheet to read, so much in it, so many modes :

3.4.2 FT2232H pins used in an FT245 Style Synchronous FIFO Interface :

ADBUS[7:0] I/O D7 to D0 bidirectional FIFO data.

I attach a cropped SignalTapII recording, being clocked at 120MHz.

clk_ftdi is a 60 MHz Clock driven from the FTDI chip.

The data being sent is counting up, the remaining byte-count counting down with each byte.

https://www.alteraforum.com/forum/attachment.php?attachmentid=5807

For short bursts SignalTapII shows the data being clocked in or out at every clock, then there is a variable gap between the bursts. How much of this is USB related and how much PC being other-wise occupied, I do not know.

https://www.alteraforum.com/forum/attachment.php?attachmentid=5808

With up-transfers of 1k word x 16 bit data (being scaled and then converted from 64bit floating-point data in an Apl interpreter), followed by a command to read the same block back, convert it to 64-bit floating point, error checked, and displayed on a graph, a 1.6GHz Windows 7 64bit lap-top (running a 32bit Apl interpreter) can do this continually every 50ms, with transfer delay jitter just starting to go up. Down at 20 ms the system is just not keeping up. The YouTube video was captured at 10 Hz frame rate, so I used 100ms repeat time for this.

--- Quote Start ---

Yes I used synchronous FIFO mode in the FT223H for the data channel.

--- Quote End ---

Nice!

--- Quote Start ---

I attach a cropped SignalTapII recording, being clocked at 120MHz.

clk_ftdi is a 60 MHz Clock driven from the FTDI chip ... For short bursts SignalTapII shows the data being clocked in or out at every clock, then there is a variable gap between the bursts.

--- Quote End ---

Very cool! Thanks for uploading the images.

The FT2232H definitely looks like the way to go for implementing a USB interface to the FPGA. I'll have to test my FT2232H mini modules :)

While you were doing these tests, did you have any conflicts with the FTDI drivers and the USB-Blaster? I've seen cases where I cannot open a COM port while I have SystemConsole with a JTAG connection open. I suspect an issue with the drivers not playing nicely (since the USB-Blaster also uses FTDI drivers).

Cheers,

Dave

--- Quote Start ---

Nice!

....

While you were doing these tests, did you have any conflicts with the FTDI drivers and the USB-Blaster? ....

Cheers,

Dave

--- Quote End ---

No, none at all. Only problem I had was, when uploading the program via the USB-Blaster, it left the system still reset by the FTDI interface. SO also had to also upload at least once by the FTDI interface. The fix should be simple, but I ran out of time then.

--- Quote Start ---

No, none at all.

--- Quote End ---

Ok, good. That just means I have a problem with my test machine. I can probably fix it by uninstalling all FTDI and Altera drivers, and then starting from scratch.

--- Quote Start ---

Only problem I had was, when uploading the program via the USB-Blaster, it left the system still reset by the FTDI interface. SO also had to also upload at least once by the FTDI interface. The fix should be simple, but I ran out of time then.

--- Quote End ---

On the Morph-IC, the reset signal for the FPGA was one of the FTDI outputs configured as a GPIO. You can use the ftd2xx DLL to setup the GPIOs, and then deassert the reset signal.

Cheers,

Dave

I was going to say more, then the forum access hung :

--- Quote Start ---

I've seen cases where I cannot open a COM port while I have SystemConsole with a JTAG connection open. I suspect an issue with the drivers not playing nicely (since the USB-Blaster also uses FTDI drivers).

--- Quote End ---

Ah, I am using the FTDI D2XX direct drivers, not the com port drivers. I can talk to the .dll that uses these direct from the Apl array manipulation program that I work in.

Actually the these drivers now also handle the com interfaces as well - it is certainly worth upgrading to the latest drivers.

I was installing a FTDI interfaced USB relay board yesterday, for high-pressure gas flow control, and noticed that having installed as com8:, when I moved it to other usb ports it remained as com8: - a considerable improvement over what used to happen with usb com ports on a PC.

--- Quote Start ---

On the Morph-IC, the reset signal for the FPGA was one of the FTDI outputs configured as a GPIO. You can use the ftd2xx DLL to setup the GPIOs, and then deassert the reset signal.

--- Quote End ---

Thanks, I think I had a quick try at something like this, but was not clear about the meaning of some of the GPIO instructions - I will have another try sometime.

I have been thinking in the meanwhile - you have really helped me with these discussions - now I have invested some months of work and also serious money in hiring a vhdl engineer to work on the state machine for this code, so I can not make this a habit, but would you like a (personal) copy of my interface firmware for the MorphicII or the FT2232H mini modules ? I will have to do some documentation.

--- Quote Start ---

I was installing a FTDI interfaced USB relay board yesterday, for high-pressure gas flow control, and noticed that having installed as com8:, when I moved it to other usb ports it remained as com8: - a considerable improvement over what used to happen with usb com ports on a PC.

--- Quote End ---

This occurs if the USB device has a unique serial number. I use the FTDI tool FT_PROG to re-write the serial numbers on most devices. Eg., the USB-Blasters on my two Stratix IV GX development kits were the same, so I reprogrammed them with serial numbers S4GXDK00 and S4GXDK01. You can do the same with your FTDI cables.

--- Quote Start ---

I have been thinking in the meanwhile - you have really helped me with these discussions - now I have invested some months of work and also serious money in hiring a vhdl engineer to work on the state machine for this code, so I can not make this a habit, but would you like a (personal) copy of my interface firmware for the MorphicII or the FT2232H mini modules ? I will have to do some documentation.

--- Quote End ---

Sure, if you don't mind me critiquing the code :)

I don't have the Morph-IC-II, so don't really care about the top-level code. But I'd be interested in your FTDI interface code.

Here's how I coded an FTDI asynchronous interface;

1) Created a bus functional model of the FTDI interface

2) Created an Avalon-ST interface to the FTDI device, i.e., an FTDI-to-Avalon-ST bridge.

3) Created an Avalon-ST to Avalon-MM master component

4) Wired them together as an FTDI-to-Avalon-MM master.

Using that interface, I can open a com port and write to an address via

w 0 12345678

or read and receive a response

r 0

12345678

I need to document that code too :)

I've also implemented a UART-to-Avalon-ST bridge, which can then be connected to the Avalon-ST to Avalon-MM master, to enable RS232 command access. Again, its in need of documentation :)

Cheers,

Dave

--- Quote Start ---

(Beau: )

I have been thinking in the meanwhile - you have really helped me with these discussions - now I have invested some months of work and also serious money in hiring a vhdl engineer to work on the state machine for this code, so I can not make this a habit, but would you like a (personal) copy of my interface firmware for the MorphicII or the FT2232H mini modules ? I will have to do some documentation.

--- Quote End ---

--- Quote Start ---

(Dave: )

Sure, if you don't mind me critiquing the code :)

--- Quote End ---

Oh I like that, helps me improve things :)

--- Quote Start ---

(Dave: )

Here's how I coded an FTDI asynchronous interface;

1) Created a bus functional model of the FTDI interface

2) Created an Avalon-ST interface to the FTDI device, i.e., an FTDI-to-Avalon-ST bridge.

3) Created an Avalon-ST to Avalon-MM master component

4) Wired them together as an FTDI-to-Avalon-MM master.

Using that interface, I can open a com port and write to an address via

w 0 12345678

or read and receive a response

r 0

12345678

I need to document that code too :)

I've also implemented a UART-to-Avalon-ST bridge, which can then be connected to the Avalon-ST to Avalon-MM master, to enable RS232 command access. Again, its in need of documentation :)

--- Quote End ---

Cool, sounds useful. I have not experimented much with Avalon yet, but need to ....

What I have done works somewhat similarly, but does not use Avalon. It is intended for interfacing to instruments :

https://www.alteraforum.com/forum/attachment.php?attachmentid=5812

The FTDI 2232H connects to the USB bus and interfaces to an fpga via the A-side octal register and 4 handshake lines (up to you if you use the B-side for programming, as in the MorphicII, but it does also go like the wind).

The first block "USB to Addressed Bus Interface" handles the protocol below, and transfers the info to three byte-wide busses : "Bank", "Address", "Data".

There can be multiple "Banks" of instruments.

Each "Instrument" within the fpga has a block of up to 256 byte-wide interface registers (that can of course be be used in groups to build wide-word registers - I have used up to 128bit words), plus the streaming byte-wide data-pipe fed at full USB2 rate. The interface registers are used for instrument configuration, control, status and low-rate data transfer.

So one can read or write single or multi-byte words to a particular instrument register/register group, in a similar way to your interface, just one has to also give an 8-bit "Bank" address as well as the register address - if one omits "Bank" the software defaults to the 1st bank.

I use Apl for talking to the firmware - it is interactive which means rapid development but the functions run fast as you can see in the YouTube videos. It talks directly to the .dll for the FTDI D2XX direct drivers, so one has full control over the USB data transfers and configuration. But you can use this firmware with any software that can talk to the .dlls ....

The "word" read/write commands are :

BnkAddrNb ezww Data ⍝ (Data as Nb byte range integers)

Res←HndlBnk ezrw AddressRange ⍝ (or list) (interprets Res as N byte word)

The data-pipe is read/write and normally would go to a memory, but in my second YouTube example it feeds a peripheral with a specific block of code that is able to eat the bytes at full USB2 rate :

BnkAddr morphic_vector_write DataVector

DataVector ←BnkAddr morphic_vector_read N ⍝ (reads N byte vector)

Where Addr is normally the block start address.

For those reading this that have missed the earlier reference to the link of the videos of this code running :

http://www.youtube.com/user/labtoolsinstruments

Hi Dave,

I have completed a GUI to drive the PC to FPGA VHDL code :

https://www.alteraforum.com/forum/attachment.php?attachmentid=5865

Also a YouTube video showing it in action :

http://youtu.be/eqljbdtovyy (http://youtu.be/eqljbdtovyy)

Even sold my first copy !

But as I say, you have given me lots of help - if you are happy to say you will use it only on a "personal, no sharing" basis, I will send you a copy with source for the VHDL and the Apl script (but Apl GUI binary).

There is a binary only free down load at :

http://www.lab-tools.com/instrumentation/download/fpga_pc_release_tf.zip (http://www.lab-tools.com/instrumentation/download/fpga_pc_release_tf.zip)

And I expect plenty of pointers as to where I could do things better ! :)

cheers,

Beau