USB Interface to Virtex-4

Hello All,

I am looking for a time efficient means to add USB capability to a Virtex-4 LX80. After looking around it seems that there are several third party solutions that require minimal number of interface I/Os (a byte wide data interface and a three wire serial control interface). However, I thought it would be a good idea to see if anyone with experience might suggest parts to avoid and parts that are recommended. Ideally what I would like to find is a part that requires less than about 20 FPGA I/Os to interface to and provides example driver source implementing a transfer of a single block of continously addressed memory.

Thanks for any suggestions, Brendan

Reply to
Brendan Illingworth
Loading thread data ...

USB 2.0 at 480 Mbps? 12 Mb/s? The PLX NetChip 2272 is an okay device for 480 Mbps though I dislike the asynchronous interface. I don't know if they have driver source available.

formatting link

I'd love to see a better option!

Reply to
John_H

I'd like to support full USB 2.0 transfer speeds. Example driver source would be critical in the intrest of saving time.

Reply to
Brendan Illingworth

I've used the Cypress FX2 in the past. It has a flexible interface that can support byte or word interfaces. They used to have sample driver code, I believe they now supply only a pre-built driver, you may want to check.

It's a very flexible part, but with the flexiblity comes the need for additional design work.

You might look at ?QuickUSB? that has a canned design with the FX2, but I'm sure if it can handle full data rates sustained.

John Providenza

Reply to
johnp

What driver you use depends on what USB Device Class you choose for your device.

-a

Reply to
Andy Peters

I have used USB 1 devices from

formatting link
in the past. In terms of the FTDI PC driver the simplest route was to use their PC driver that makes the USB port look like a COM/serial port. I.e your PC application doesn't need to know anything about USB. At the USB device end the FTDI chips can present a serial or parallel IO inteface that you would attach to your FPGA. This is a very quick way to get USB into your product, but you do take the unit cost hit of the FTDI USB chip.

I'm sure the latest FTDI devices are USB 2 compliant, but I don't know if they support USB Hi-Speed(480Mbit/s) or just "USB Full Speed" (approx 8mbit/s). A USB 2 device does not have to support HiSpeed.

"I'd like to support full USB 2.0 transfer speeds" - ummm do you want to support USB 2 Full speed = 8mbit/s or do you want to support the max USB 2 speed = Hi Speed = 480 mbit/s.

Regards Andrew

Andy Peters wrote:

Reply to
Andrew FPGA

I used quickusb recently - removes the need to get involved in any of the low-level USB stuff at the PC end, and supports various IO models - 8/16 bit, internal/external addressing, with various fifo modes and UARTs plus a FPGA bitstream programming mode. Absolute minimum pin count would be 8 data +

2 control + clock, but you'd probably need at least one extra for framing/handshaking.
formatting link
Reply to
Mike Harrison

A friend of mine looked into using the QuickUSB module for a project, but had to reject it because it radiated noise at too high a level for his application. He was doing some analog signal sampling/generation and the noise from the module would have been a killer.

John Providenza

Reply to
johnp

Dumb question: Since USB is just a two wire serial interface and all the USB solutions I've seen are simple, though speedy, microcontrollers why can't the USB be inside the fpga? Seems like you can instantiate a small micro running at 50 mhz or so with code in a couple block rams to do what the fx2, for example, does. Apparently, doesn't exist so there must be some reason?

-Clark

low-level USB stuff at the

addressing, with various fifo

pin count would be 8 data +

framing/handshaking.

Reply to
Anonymous

I agree with Clark, thats why the IP cores are for. The only matter is the physical connection cause the high frequencies of the wires you have to drive inside the fpga need to be shielded from noise.

chech existing phy inteegrated chips.

Reply to
Alexis

The OP wanted a "time efficient" approach for adding USB support.

I suspect trying to embed USB IP inside a FPGA does not meet this requirement. Yes, you could add a USB core and a PHY and an embedded processor and write and debug a bunch of code....

Or you could leverage parts like the Cypress FX2 that provides several easy approaches to doing this.

Which is more "time efficient"?

John Providenza

Reply to
johnp

What's more time efficient then going to your EDK and just adding an OPB_USB peripheral? I was just asking why such a thing doesn't appear to exist. But, yes, I agree I strayed off topic.

-Clark

Reply to
Anonymous

hmm, I have created an OPB_USB peripheral a few years ago. This should answer the question if this is possible or not. In case you have special applications that utilize a lot of bandwidth, this might still be a good idea. Unfortunately, my solution was based on USB 1.1, i.e. 12Mbps. And in order to avoid any speculation on size, please refer to this site:

formatting link

Regarding USB 2.0, i.e. 480Mbps, the structure looks a little different. The PHY will already include the clock recovery (which is one of the more critical parts of a USB core), and provide parallel data to the attached devices. In case you are wondering if the higher layers of a USB 1.1 controller could be reused: USB 2.0 defines a few more tokens, so the state machines would need to be extended to support these.

Regarding firmware: To get a simple HID device recognized by Windows, you would need about 1kB of 8051 assembly code. This is not too critical, and there is plenty of good samples out there.

Best regards, Felix

--
Dipl.-Ing. Felix Bertram
http://homepage.mac.com/f.bertram
Reply to
Felix Bertram

It's a little more complex than simply two wires between two devices.

USB signalling is half-duplex differential, and high-speed signalling is different than full-speed and low-speed. Also, there are some instances where single-ended signalling is used and the driver must be capable of doing this and the receiver has to be able to detect these states.

-a

Reply to
Andy Peters

USB

can't

fx2,

reason?

I agree the software is complicated. (Way too complicated in my opinion.) But all the solutions out there seem to be built around a little 8-bit micro. You don't think it's silly to have a 10 million gate FPGA sitting next to an 8051?

There must be a real reason for it. Maybe I'll try it when I get some time.

-Clark

Reply to
Anonymous

if "software" is referring to the firmware: this is really not too complicated. Have a look here:

  • formatting link
  • formatting link

disagreed. There are two types of data to be very clearly separated:

  • asynchronous data: this is all the USB device enumeration and control stuff. This is low bandwidth, most of it happens only during device attachment, and this is quite simple. An 8051 is still too complex to handle this, there are designs out there using a simple state machine.
  • isochronous data: this is all the traffic your application requires. In case you are streaming high bandwidth data and you need to do some processing on it, an FPGA might be a good solution. You will usually not want to pass 480Mbps of data through a CPU. Think of audio or video applications, USB protocol analyzers, ...

Any comments welcome, best regards,

Felix

--
Dipl.-Ing. Felix Bertram
http://www.bertram-family.com/felix
Reply to
Felix Bertram

opinion.)

I guess my point was if you look at an fx2, for example, all I see is an

8-bit micro, a little bit of memory, and some relatively simple fifo hardware. All of this seems trivial inside a virtex-4, yet most v4 designs I've seen have the usb outside the fpga. Maybe that's so they can load the fpga at power up but it seems like if they have flash memory anyway, there's no real advantage to usb outside the fpga.

-Clark

Reply to
Anonymous

All,

When we recently did a USB interface to the FPGA, we looked at the USB interface parts that were out there, their features, and their costs.

We decided on a complete module (connector, and all) just because it was - 1. incredibly cheap, 2. useful (it has its own 8 bit uP to take care of everything we would ever need), and 3. it is done, and working (one less thing to do).

Tightly integrating the USB into the FPGA has about 0 benefit. It is not like having an ethernet port, or a 6.25 Gbs serial link, or PCI express, or any of a number of high bandwidth interfaces where tight coupling just makes sense.

I think there are some interfaces that don't qualify for inclusion in the high end FPGA families (like Virtex and its brothers). At the high end, you want the best performance for the least cost. Costs are assigned to the different categories of performance, with the most money being spent on the device(s) that deliver the biggest punch. The USB port is way down the list here.

Maybe these sorts of interfaces are more suitable in the Spartan line, where speed is relatively unimportant, and where total cost is everything.

Austin

Reply to
Austin Lesea

Where did I say anything about SOFTWARE? I pointed out that the hardware interface is more than simply two wires.

You could get a PHY and put that next to your FPGA.

-a

Reply to
Andy Peters

That depends on your mindset. If you really want a single chip "at all costs", then yes, pull the USB into the FPGA - the FPGA vendors will love you :)

but if you want a reliable, cheap, easy to fault-find system then a little distributed intelligence can be a very good thing. Keep the expensive FPGA fabric for what it best at.....

Try this : The USB uC's out there can directly, and correctly, drive the USB cable, and are proven to do so.

-jg

Reply to
Jim Granville

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.