USB Interface to Virtex-4

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

"johnp" <johnp3+nospam@probo.com> wrote in message
news:1143913431.274974.10660@j33g2000cwa.googlegroups.com...
> 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
>

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

> 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.

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:
http://homepage.mac.com/f.bertram/usb_core.html

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

Anonymous wrote:
> 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?

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

"Andy Peters" <Bassman59a@yahoo.com> wrote in message
news:1144276764.165125.290340@z34g2000cwc.googlegroups.com...
> Anonymous wrote:
> > 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?
>
> 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
>

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

> I agree the software is complicated. (Way too complicated in my opinion.)

if "software" is referring to the firmware: this is really not too
complicated. Have a look here:
* www.usb-by-example.com
* www.lvr.com

> 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?

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

"Felix Bertram" <flx@bertram-family.com> wrote in message
news:49l64gFp3eu7U1@individual.net...
> > I agree the software is complicated. (Way too complicated in my
opinion.)
>
> if "software" is referring to the firmware: this is really not too
> complicated. Have a look here:
> * www.usb-by-example.com
> * www.lvr.com
>
> > 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?
>
> 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

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

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

Anonymous wrote:
> "Andy Peters" <Bassman59a@yahoo.com> wrote in message
> news:1144276764.165125.290340@z34g2000cwc.googlegroups.com...
> > Anonymous wrote:
> > > 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?
> >
> > 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
> >
>
> I agree the software is complicated. (Way too complicated in my opinion.)

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

> 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.

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

-a

Anonymous wrote:
> 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?

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.....

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

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

-jg