Why Powered USB Is Needed, Part 3: USB 3?
This article describes a version of USB that is not related to the new USB 3 spec that Intel has released for 2010 products
I originally planned the Powered USB article as two parts, one explaining why USB took off, and another explaining why USB isn’t the best solution because it can’t power large devices plus why Powered USB isn’t the greatest solution either because it isn’t in consumer electronics yet and has the different plugs for different voltages issue as well.
What I didn’t plan on was all the Firewire fans popping up and saying I was wrong for pushing a Powered USB/USB 3 combo. For the record, I’m also a Firewire fan but haven’t gone to the fanatical levels some people have. Part 3 is for you guys.
Note: I originally intended for USB 3 and New Powered USB to be separate standards, allowing devices to use one or both (but New Powered USB would require USB 3 to negotiate for power usage). The way I will describe this possible future USB 3 in part 3 is basically folding the new data features into the New Powered USB part of the plug to remain compatible with USB 2 hosts/devices/hubs.
The problem with traditional USB is because:
- It’s slow.
- Can’t allow devices to perform the DMA-like transfer method Firewire does1.
- It’s slow.
- Uses polling to transfer data, thus eats CPU time like mad.
- It’s slow.
- Future USB specifications cannot perform interrupts to signal for the host to acquire new data, and can only use polling.
- It’s slow.
Even with these problems, I can still say future USB products look promising because the reason I chose a formalized New Powered USB specification combined with a future USB 3 specification is because almost everyone has USB ports, and it has become the ubiquitous peripheral port on all sorts of devices. Not all devices come in Firewire versions, and not all computers have Firewire ports.
The Proposed USB 3.0 Specification Checklist
USB is being held back by the fact it can’t perform interrupts. USB 3 cannot just add it in the normal USB host interface stack: USB was never designed for it, and you can’t just add it as a feature that can be negotiated between host and client. It wouldn’t work.
However, what would work is adding a second new interface that is slaved to the first: allow USB 3 devices to negotiate to use this new second interface, and allow the second interface to work independently of the original legacy interface. This secondary interface could not only perform interrupts, but be able to do anything USB 2 is missing.
There are two reasons you need the independency: one, USB 3 hubs need to be able to transfer data from both legacy USB 2 devices and USB 3 devices (all the USB 2 data will be going across the legacy bus independently of USB 3 data); and two, USB 3 devices will no longer be using the legacy interface for any data transferring once the negotiation is complete. The legacy interface will act as an out-of-band interface for non-important USB-related traffic (such as for re-negotiation, or for negotiation of/for USB 3 clients plugged into USB 3 hubs, or for just telling the host it’s still plugged in).
This second interface, since it is now independent, can virtually use any protocol it wishes. If the USB Working Group so decided, they could run Firewire unmodified over this second interface. The possibilities are endless. Most likely, it’d be some USB-IF designed Firewire clone.
There is something else I need to add to this checklist: USB 2 legacy communicaiton with USB 3 hosts and clients. As I said, USB 3 devices would have to negotiate to use the secondary interface, but what happens if either the host, client, or hub rejects this?
USB 3 clients will have to be able to do their work as standard USB 2 devices. Obviously, high bandwidth applications would run a lot slower, DV devices might not be able to be used in real-time, and Powered USB power features couldn’t be negotiated for (most likely the USB 2 client/host/hub would be using a normal USB plug in the first place). USB 3 hubs connected to USB 2 hosts would have to reject USB 3 connections as well and tell any USB 3 clients connected to the hub to run in USB 2 mode.
More pins doesn’t exactly mean a new data connector
Of course, this second interface requires more pins, yet has to stay compatible with the old USB plug. Frankly, doing what Firewire 800 did (adding a 9-pin socket/plug that requires an adapter to plug 6-pin devices/plug into 6-pin hosts) is possibly a bad idea as it requires people to have yet another small part that is easy to lose. Adapter dongles and short adapter cables suck.
The idea I’ve been playing around with is to attach these new pins to the consumer-friendly New Powered USB plug I hinted at in part 2 of this article. Just add, say, four or six pins to the outside of the plug’s inner column like how Type B USB plugs work now, while leaving the power pins on the inside of the column like the are in the original design. Remember, these pins are for data only, all three Firewire plug designs only use two pairs for data.
However the plug actually gets designed, I don’t care; it just has to be done in a way that doesn’t interfere with the legacy USB plug. Putting the new data pins in the New Powered USB half of the connector seems to be the ideal way of solving this without going Firewire’s route.
So thats it? Just clone Firewire’s features?
The two main things that Firewire has over USB at this time is the fact that Firewire devices can use interrupts (which, if you haven’t figured it out yet, is causing Firewire 400 to actually hit 400mbps, and USB2 to hit about half of it’s 480mbps), and the fact that Firewire can power devices that are more power hungy, is why, in theory, Firewire is the better bus.
But as I said before, USB is the defacto standard for peripheral communication, and Firewire is in far fewer devices, and some computers don’t even have Firewire ports. As much as I’d like to see Firewire kill USB, it is not going to happen any time soon.
So yes, what I’m saying is USB 3′s secondary interface has to either copy Firewire’s features or use Firewire directly. Firewire can’t kill USB, USB is having a hard time killing Firewire, so the only way I see this problem being solved is by allowing USB 3 to do everything Firewire does now while still remaining compatible with USB 2 devices and hosts.
: On some platforms it really does turn into a PCI DMA and allows you to read/write part or all of the system memory, such as for live debugging purposes on another machine. I’d like to see this on USB 3 as well.