D@n

I wrote about asynchronous FIFO's here.  Not sure if you already have that information or not.  The design I wrote about has a throughput equal to one value per the speed of the slower of the two clocks.  Latency is a bit more difficult to quantify.  You'll need to use some probability to do so.

Dan

Well, let me start at my own experience.  I have little experience designing for the FTDI chip--I've just used designs from other people that can tell me nothing about their designs.    I have never used the Cypress chip. 

On one design I was a part of, the "end-point" controller you mention was a fully capable ARM.  This ARM then connected to the FPGA, but still provided the USB host with some useful interfaces: block device and serial port among them.  The FPGA itself was very small, providing just enough functionality for the mission of this board.  I enjoyed working with this design.

The more recent design that I have insight into is the XuLA2 design.  This design connects the USB to the device JTAG, and offers little to no high speed transfer capability--just a really slow JTAG.  If you wish to communicate with the S6 on the XuLA board, you are limited to using the user command in JTAG--not very useful.  Further, the XuLA uses a PIC to implement its communication protocol across the USB.  As a final touch, the XuLA2 has a single LED on board that is controlled from the PIC, not the FPGA.  This has its plusses and ... minuses.

I've tried to coach someone through using this XuLA JTAG interface.  He wants to do image processing with his FPGA.  However, the JTAG interface was dominating any speedup he might've received via the FPGA.  Sure, he could go to an FMC connector ... but that would require a full hardware redesign for him, and he's hoping to do with what he has.  His latest approach has him connecting XuLA I/O to a RPi--but I'm getting off topic.

My thought was simply this: expand upon this OpenSource capability, with a bigger PIC.  Provide USB endpoints for serial, SPI, some bit-banging, and ... who knows, maybe some other things as well--but whatever you do don't cripple the interface as the XuLA's is currently.  Further, the goal was to make this as generic and opensource as possible, so that other end point functions could be built as necessary.

At the same time, if your view is that trying to stuff more functionality into an endpoint controller is useless, then ... either I need to drop my approach (which would mean an end to the discussion--save only to ask what approach might be better), or you are not interested in it (again an end to the discussion), or ... well, I'm not sure where to go next.  As I mentioned, I have no experience with the FTDI chip to press the discussion in that direction.

Thoughts?

Dan

I wasn't certain where to go next with it.  Let me reread it again.

Dan

Yes, you were right, my post was getting off topic.  Hence my thoughts for another venue ...

So my idea is not driven by some top down requirement, but rather from the bottom up: ManyFPGA boards interface with a computer via USB and a microcontroller of some type.  I've seen many, many designs now of this type.  At a minimum, the USB interface provides access to the JTAG port of the FPGA in order to configure it.  I've seen other designs where the USB interface also provides access to a serial port, and even one that offers access to a parallel port (CMod-S6).  In all of these designs, however, I have yet to see the USB interface used to its maximum potential--both in terms of speed communicating between the FPGA and the host, as well as in the richness (and openness) of how such communication is done.

My thought was to use a stronger microcontroller, and see how fast the USB interface could be made to be. 

At a minimum, the interface must support a JTAG for loading configurations to the FPGA, through the microcontroller, from the host.  Even this, though, might be made faster by placing the JTAG smarts in the microcontroller, and only sending a compressed file over the USB.

At a next level, the interface could/should support a serial port to the FPGA, and perhaps even a second one to the microcontroller.  The faster this interface can be made to work, the better.

Beyond that, the FPGA should be able to communicate with the PIC in a rich manner: A SPI port for example, or even a parallel master port, or perhaps just GPIO between the two.  Each of these could also be USB endpoints ...  Indeed, a SPI port could be used to control a mass storage device (such as an SD card, or something pretending to look like an SD card), so the interaction need not be limited to serial port protocols.  Indeed, a mass storage protocol might make sense when trying to read/write flash or RAM memory on the FPGA from the host.

Again, though, what am I trying to do?  I'm tryinng to ask the bottom up question, if you have a PC connected to a USB connected to a microcontroller, connected to an FPGA--just how far can you push that interface, and build generic features, for a ... more fully featured board.

That's my thoughts.

What do you think?

Dan

"smapper"?  Yeesh.  I meant "spammer".  Looks like it's been cleaned up by now.