FPGA Central

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

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.
http://www.plxtech.com/products/NET2000/default.asp

I'd love to see a better option!

"Brendan Illingworth" <[email protected]> wrote in message
news:[email protected]..
> 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

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


"John_H" <[email protected]> wrote in message
news:k8UWf.4376$[email protected]..
> 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. http://www.plxtech.com/products/NET2000/default.asp
>
> I'd love to see a better option!
>
> "Brendan Illingworth" <[email protected]> wrote in message
> news:[email protected]..
>> 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
>
>

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

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

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

-a

I have used USB 1 devices from http://www.ftdichip.com/ 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:
> Brendan Illingworth wrote:
> > I'd like to support full USB 2.0 transfer speeds. Example driver source
> > would be critical in the intrest of saving time.
>
> What driver you use depends on what USB Device Class you choose for
> your device.
>
> -a

On 30 Mar 2006 09:56:49 -0800, "johnp" <[email protected]> wrote:

>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

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.
http://www.quickusb.com

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

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

"Mike Harrison" <[email protected]> wrote in message
news:[email protected]..
> On 30 Mar 2006 09:56:49 -0800, "johnp" <[email protected]> wrote:
>
> >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
>
> 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.
> http://www.quickusb.com

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.

"Anonymous" <[email protected]> wrote in message
news:zraXf.56091$[email protected]..
> 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
>
> "Mike Harrison" <[email protected]> wrote in message
> news:[email protected]..
>> On 30 Mar 2006 09:56:49 -0800, "johnp" <[email protected]> wrote:
>>
>> >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
>>
>> 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.
>> http://www.quickusb.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

"johnp" <[email protected]> wrote in message
news:[email protected] ups.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" <[email protected]> wrote in message
news:[email protected] oups.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" <[email protected]> wrote in message
news:[email protected]..
> > 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" <[email protected]> wrote in message
> news:[email protected] oups.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

Austin Lesea wrote:

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

True, tho I'd say that Ethernet is moving into the same category as
you have placed USB. Not GBit ethernet, but certainly vanilla 10/100,
where there are smarter/cheaper PHY included options to choose from.

-jg

Jim,

Agreed. If you have to have a substantial core of soft logic to support
that interface in the FPGA, it had better be worth it. If the FPGA has
hardened cores for most, or part of that interface, it makes it a
slightly better proposition.

It is all systems engineering.

I admit that when I sit down to do that job (very rarely now), I pick
the components that will:

- do the best job
- cause me the least grief (both in software/coding and signal
integrity/support)
- meet the cost objectives

When all the marketing hype is said and done, the hard work is just
begun for the engineer.

Successful completion and testing of the prototype is an important step.

And then manufacturing can be another real trial.

So it ain't over till the customer is paying (and happy).

Anything that gets you to market faster is a real plus. The systems
engineer can make, or break a project by their decisions.

Austin

Jim Granville wrote:

> Austin Lesea wrote:
>
>> 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.
>
>
> True, tho I'd say that Ethernet is moving into the same category as
> you have placed USB. Not GBit ethernet, but certainly vanilla 10/100,
> where there are smarter/cheaper PHY included options to choose from.
>
> -jg
>
>

"Anonymous" <[email protected]> wrote in message
news:NvfZf.78923$%[email protected] m...
>
> "Felix Bertram" <[email protected]> wrote in message
> news:[email protected]..
> > > 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
>
>

I have to admit that I find some of the replies to what I thought was a dumb
question a little odd. It's almost like some folks take personal offense at
the notion of using a couple hundred slices and a couple block rams to
implement a USB interface inside the FPGA. (The smallest V4fx has 12,000 lcs
and 36 brams) I think most of the counterarguments could apply to any other
peripheral: Why a uart? Why ethernet? Why even a PPC core when you can get a
better processor discretely?

If I had a solution that:
1. Integrated into EDK such that it adds like any other peripheral. The IP
should contain the micro, firmware, and the interface to the CPU.
2. Integrated into the board support package so that I can build my chip,
carry a few files over to my linux source and be able to compile it into the
linux kernel.
3. Stock linux and windows driver support.
4. Netusb compatibility such that I can take my usb master port and connect
it to any other port to create a network link.
5. USB1.1 initially but eventually 2.0.

I would gladly use it over any discrete solution that I constantly have to
worry about obscolecense or other supply problems, not to mention the extra
size, cost(part plus ordering plus handling), and power. Who hasn't had a
board build delayed because of a back order on some small part like a usb
chip?

-Clark

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

That's because you are looking at a very simplified block diagram. The
logic is a bit more complicated.

> I would gladly use it over any discrete solution that I constantly have to
> worry about obscolecense or other supply problems, not to mention the
> extra
> size, cost(part plus ordering plus handling), and power. Who hasn't had a
> board build delayed because of a back order on some small part like a usb
> chip?

You would still need an external USB PHY no matter what and they are even
more prone to supply issues because of the limited demand/volume of
production.

Marc Reinig
System Solutions