USB interface from scratch -- what should I watch out for?

[ebastler]

So I built this replica of the LGP-30, a rather old (1956) computer. Hardware-wise, the replica is essentially an I/O shield for a cheap Spartan-6 FPGA board, the Numato Mimas. The FPGA implements the complete logic equations of the LGP-30's bit-serial CPU (which conveniently had been published in the service manual and in a scientific paper by the original designer).

My current implementation provides an RS-232 port to connect an ASCII terminal, which replaces the pre-ASCII "Flexowriter" teletype machine that came with the LGP-30. Typically, this port will end up being connected to a PC-based terminal program, via USB and an FTDI or equivalent chip. So it would be convenient to also offer a direct USB connection on my I/O board -- to lose the FTDI adapter, and also supply power via just a single cable.

I would like to drive the USB port directly from the FPGA, without any additional interface chip. (That's because (a) I'm cheap, (b) I want to avoid exotic chips, and avoid SMD components, and (c) I like a challenge. ) I have located open-source VHDL implementations for USB serial data transmission and for a USB 1.1 PHY layer, so this seems feasible.

My question refers to the electrical side of the USB interface, since I have never built one from scratch so far:

• What protection seems absolutely necessary, both on the +5V and the data lines, to limit the chance of damaging the PC or the FPGA by mishaps?
• Any recommendations for avoiding the worst EMI problems, while keeping things simple?
• Any important layout considerations? This will run at USB 1.1 speeds only, so hopefully does not pose major challenges on this front?

Please keep in mind that this is not meant to be a commercial product. But I would like to make the plans available to other hobbyists, and hence make the design robust enough to avoid headaches for others building it (and for myself, supporting it...). To make the design easy to replicate, I woud like to avoid "special" parts if possible.

Thanks for any advice you may have!
Jürgen

[Elf]

• What protection seems absolutely necessary, both on the +5V and the data lines, to limit the chance of damaging the PC or the FPGA by mishaps?
• Any recommendations for avoiding the worst EMI problems, while keeping things simple?

I have been incorporating USB interfaces into some things lately. These may count as special parts, but I now use these as standard for USB:

• Littelfuse Polyzen ZEN056V115A24LS for USB Vbus input gives overvoltage, overcurrent, and reverse polarity protection (for USB device)
• Pi network of 0.1/1uF capacitors and MPZ2012S102AT000 ferrite bead
• TI SN65220 dual TVS for ESD protection on D-/D+

For host/OTG interfaces I will have power go through a TI TPS2041B current limited switch instead of the Polyzen.

• Any important layout considerations? This will run at USB 1.1 speeds only, so hopefully does not pose major challenges on this front?

USB is supposed to be run on a 90 ohm differential pair. For USB 1.1 if you keep the connector close to the chip and keep the lines balanced (with appropriate series resistors for D+/D-), then it isn't going to be too critical that it is exactly 90 ohm.

[Leo Bodnar]

• Any recommendations for avoiding the worst EMI problems, while keeping things simple?
• Any important layout considerations? This will run at USB 1.1 speeds only, so hopefully does not pose major challenges on this front?

Are you going for LS or FS - they are both 1.1?  They have slightly different requirements for capacitive load, edge rate and maximum cables length.

LS is really easy, for non-commercial project you don't really have to worry about anything.  Folks are still using AVRs to bit-bang almost fully compliant chapter 9 devices using no more than a pull-up resistor (because you said you are cheap...)

[ebastler]

• Any recommendations for avoiding the worst EMI problems, while keeping things simple?

Are you going for LS or FS - they are both 1.1? 
LS is really easy, for non-commercial project you don't really have to worry about anything. 

Good point, thank you. To be honest, I had not even remembered that low-speed mode existed. It should certainy be fast enough though; all I want to transfer is 19.2 kBaud serial data.

I will look into the "poor man's" AVR implementation to get a data point at the other end of the spectrum vs. Elf's professional recommendations.  Guess I'm aiming for a halfway solution... 

Edit: Quote formatting fixed; not sure what happened there...
Also noted Leo's further comment below -- thanks!

[Leo Bodnar]

Good point, thank you. To be honest, I had not even remembered that low-speed mode existed. It should certainy be fast enough though; all I want to transfer is 19.2 kBaud serial data.

Sorry I just gave you a bad idea   LS USB does not support bulk transfers and as a consequence - CDC class.
Your only choice is FS and up.
Leo

[BradC]

Sorry I just gave you a bad idea   LS USB does not support bulk transfers and as a consequence - CDC class.
Your only choice is FS and up.
Leo

While technically true, BULK over low speed works on both Windows and OSX. It works on Linux if you patch out the check in the USB driver that prevents it from working. It *is* a hack though.

[Leo Bodnar]

While technically true, BULK over low speed works on both Windows and OSX. It works on Linux if you patch out the check in the USB driver that prevents it from working. It *is* a hack though.

Sure, it is a hack and only works because driver writers do not expect device to do that and don't have exhaustive checks for everything that specification forbids.  USB spec guarantees that [certified] USB device won't use bulk in LS so why check?  You can also use 1024 byte long interrupt packets in HID devices on early versions of Windows and abuse the stack in a lot of other ways. Long HID packets loophole got fixed in Vista and there were a few commercial devices that stopped working.

Jürgen's design criteria is to not have a device that needs a lot of support.

[ebastler]

Thanks, Brad and Leo! I appreciate the further insight on USB Low Speed mode, its limitations and possible hacks.

I tend to go with Leo's advice and opt for a solution that works out-of-the-box on the major operating systems. Full Speed does not seem too intimidating from the electrical perspective -- and should still be accessible for my 100 MHz scope, to get an idea of signal quality and slopes. I think I will give that a try.

Now on to convincing the family that my retro-computing gear has to accompany us on this year's summer vacation... 

[rstofer]

Opencores has something that is intended to work with the Microblaze core but it may be useful for background:
https://opencores.org/project,opb_usblite

[ebastler]

Opencores has something that is intended to work with the Microblaze core but it may be useful for background:
https://opencores.org/project,opb_usblite

Thanks rstofer, I had not spotted that one.
They also have a USB core and physical layer by Rudolf Usselmann which seem to be very mature and hopefully stable, but don't come with much documentation. (Rudolf's business model is to provide free cores, and paid consulting where needed.) The additional background from the Microblaze core might come in handy!

https://opencores.org/project,usb_phy
https://opencores.org/project,usb1_funct

[ebastler]

I have been incorporating USB interfaces into some things lately. These may count as special parts, but I now use these as standard for USB:

• Littelfuse Polyzen ZEN056V115A24LS for USB Vbus input gives overvoltage, overcurrent, and reverse polarity protection (for USB device)
• Pi network of 0.1/1uF capacitors and MPZ2012S102AT000 ferrite bead
• TI SN65220 dual TVS for ESD protection on D-/D+

Coming back to this side project of mine. In the meantime I have successfully cobbled together the USB stack for a full-speed CDC device in the FPGA, thanks to available open-source components, and have integrated it into my retro-computer simulation. For protecting the physical interface, I have decided to go with elf's recommendation and use the dual TVS for the data lines and the Polyzen to protect from Vbus mishaps.

As I don't have a Polyzen device in hand yet, I was wondering about the footprint and how it can be soldered. The Polyzens are meant for reflow soldering, but my PCB needs to be suitable for hand-soldering too (for myself and potentially other builders).

Can the -LS version of the Polyzen be hand-soldered if I make the pads a bit larger? It seems like the device itsef has solder pads on the bottom only, not at the sides, and that the specified PCB layout has pads only below the device?

Thanks for any hints you might have!

[rstofer]

I would just make the pads a little wider so that there is a bit of pad beyond the edge of the device.

I might use solder paste on the pads, place the part and then hit the exposed pad with a soldering iron.

Or, I might just put those 3 parts on the board with solder paste and reflow them.

Or, I might just cover the pads with flux paste and place a drop of solder on the iron.  Holding the tip against the exposed pad should do the trick.  Kind of like drag soldering.

All in, a non-event.

BTW, it looks like the chip pin rises up the side of the package like many other packages.  This makes it particularly easy to solder.

[ebastler]

Thanks, rstofer -- yes, I was thinking along those same lines. Probably all of these soldering methods will work if the PCB pads are wide enough to feed some heat in. What made me a bit nervous was that, from the photographs I looked at, it does not seem like the Polyzen -LS device has regular pins. Its bottom layer looks more like a mini-PCB with pads on the bottom only?

Anyway, I have already edited that standard footprint to make the pads a bit wider. Will send the PCB off for manufacturing, order parts in parallel, and figure out how to best solder them once I have everything in hand.

[Leo Bodnar]

I am very curious why you are going through all the trouble with using Polyzens?  Unlike the TVS you can't leave it out - it needs at least a short to make the board work.

What Vbus mishaps are you trying to protect against?  According to USB spec protection against Vbus shorts (about 1A in actual designs) to GND is the job of the upstream device and it has been followed by the manufacturers pretty well.  Every PC that does not have port protection has already burnt out. 

I have never seen a host with Vbus exceeding the USB spec continuously.  And proper USB TVS clamps already have transient protection for Vbus - like TPD2E001.

Cheers
Leo

[ebastler]

I am very curious why you are going through all the trouble with using Polyzens?  Unlike the TVS you can't leave it out - it needs at least a short to make the board work.

Valid question! If this were a pure USB port, I would probably be less concerned about the Vbus quality. But my little retro-computer also has a conventional RS-232 port, for those who want to use it with a vintage terminal rather than a PC and terminal program. In that case, the USB connector can be used as just a power jack, and power supplies with wrong polarity or voltage seem somewhat more likely to show up. Hence the Polyzen.

I did provide for a jumper in parallel with the the Polyzen in the PCB layout, so it is optional. 

[Leo Bodnar]

the USB connector can be used as just a power jack, and power supplies with wrong polarity or voltage seem somewhat more likely to show up. Hence the Polyzen.

OK, I see. It's a good answer!
Leo