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.

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.

[1]: 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.

Voltage isn’t the problem in USB devices, it’s amperage. USB devices simply need to provide more amps at the interface to allow for more powerful devices to run without the need for an external power source.

While some devices use external power supplies, this is usually because the amperage over the USB interface is not enough to power the device entirely. The reason the external power supply may be 12v instead of 5v is simply because they are going to make it whatever most convenient to them.

12 volts requires very little in the way of insulation. I just tested a USB cable which had been cut it in half, by applying 120VAC between every possible pair of exposed conductors. No problems; no sparks. It wasn’t a thin cable, just the ordinary thickness, but if an ordinary cable can handle 120VAC (170V peak), then pretty much any cable in existence can handle 12VDC. And if one doesn’t, so what? The power supplied by the port should be current-limited anyway. If there’s a short, the device will just not work; and as part of normal troubleshooting the cable should be suspected and replaced.

Patrick, does the usb specification include a minimum voltage the insulation has to suitable for?

Raising the voltage allows much higher wattages, but it does increase the component count on the powered device, as it will need to step the voltage down, and the current up, to meet the requirements of the devices. Although the device would probably already contain a voltage controller to handle any voltage drop due to the resistance of the cable.

Using USB2’s 1.5 amp cables and 100v would give 150w theoretical and not require anymore connectors. The raise in voltage would be negotiated just like everything else, to ensure nothing was electrocuted.

Up to 120VDC is classed as ‘extra low voltage’ and so would not require any significant differences than using 12v, so long as the insulation was sufficient.

USB does have an interrupt system. The host controller is a PCI device and, at the very lease, is connected to one of the PCI IRQ lines. There is also another interrupt system used by BIOS, but not available to the OS called SMI. My point is simply that the comment on polling is not architecturally correct.

The CPU time usage comes from USB host controller being set up to be minimal in terms of hardware to make software pick up the slack to ensure maximum flexibility for the interface. The software running the host controller could be run on another CPU in a multicore system, or even a dedicated microcontroller if the hardware designer was so inclined, but that comes with its own issues.

With that off my chest, onto the issue! The problem it seems you with to address is that we have no standard for an external DC power system. We have the de facto standards of 12V, 5V, and 3.3V inside a PC case, but none for the outside. Computer modders have thrown themselves at this problem but none of the solutions are truly what it seems you are suggesting. The idea is for power management to the device as well as monitoring and overcurrent protection. Maybe the dice could take the power from firewire 
I think this could be done and still fit in the standard USB connector. How this would work is that the device connects to USB as normal and the host controller reads the power requirements from the appropriate descriptor as normal. When the device requests ‘powered USB’ support, the controller signals a power controller to connect the device to the larger power source. If the device is connected to a hub that supports powered USB, the host controller would send a command to the hub (though an extended hub class) and the hub would manage its local power circuitry. If the hub can’t support powered USB, it would report back and the user could be informed that hub is not powered USB compatible.

The last thing that bothers me is your proposal for ‘USB 3’. At is currently stands, USB 2.0 is based on an EHCI which does not support USB 1.1, UHCIs or OHCIs do that now. When you plug in a device, one of the first things it does is negotiate to connect to the EHCI, or stay on the OHCI/UHCI. The ‘beauty’ of the system was keeping the same software stack. This is important to the OS developers. Ask them to start from scratch and they will refuse. Another example of this is PCIe. If you look at PCIe vs Infiniband, they look a lot alike. What made the industry come down on the side of PCIe is that it uses the PCI software specification. As odd as it seems, it is easier to change the hardware than the software.

Ted You do realize that 500mA, aka 0.5A, is not a lot of power? Read the math in part 2 of this article.

What hinders USB3 is that standard USB 1.1 compliant cables can only carry 0.5A, and USB 2 cables are only supposed to carry 1.5A max (and most probably fail that test).

USB3 simply cannot support asking for more than around 1.0A without putting users and other devices in danger.

Also, yes, it does look like a normal USB connector. Its a dual section plug, the top half is a normal everyday USB plug and accepts both regular USB plugs and New Powered USB plugs. See the image I included in part 2 of this article for a standard Powered USB plug (not the New kind because they don’t exist (yet)).

about power-needs, “initially, a device is only allowed to draw 100 mA. It may request more current from the upstream device in units of 100 mA up to a maximum of 500 mA”
what hinders that the USB3 device is allowed to ask for more than 500mA? there is no need for new connectors.

(if it don’t look like an normal usb connector it isn’t really “usb”…. the world is ugly as it is with a/b/mini/micro)

Power over Ethernet (PoE) is another interesting contender, it provides 1mbps and 13 watts. Obviously the 1mbps is only theoretical, I don’t know how much is lost to headers, tails, lost packets and error correction.

So far it sounds like PoE isn’t a strong contender but it has one feature that USB and Firewire don’t supply, device sharing. There is also less of a problem with mixing different speed devices, all switches can handle mixed speeds 10k,100k,1m.

Price is a problem though, rj45 connectors are much more complex to manufacture than USB.

The sharing abilities do cause problems though, the keyboard and mouse would need to be on a seperate bus or ‘paired’ in some manour with the computer.

joseph daniel zukiger: Not quite. Powered USB already exists, I’m just combining the need with standardizing on a single voltage plug with the need for a couple more pins.

And no, I don’t think its right to have high and low bandwidth devices segregated by using different busses. Look at how I solved that with USB 3, USB 2 devices will use the legacy interface all to themselves, while USB 3 devices will use the new interface all by themselves.

So you fix USB by making USB 3.0 into a firewire with a new formfactor?

Adaptors may be a bad idea, but so is putting a second set of connectors on. That’s going to be an easy plug to break when it gets built cheaply and somebody’s grandfather starts pulling it out by the wire.

However, you’re missing another important feature of Firewire that USB misses. (Look carefully at the communications protocol.)

Anyway, I personally think that, if we’re going to have to invent another plug, why invent a USB 3 when Firewire already does the job? If you figure Firewire has made too many enemies or some such thing, there is always serial SCSI.

Low speed devices and high speed devices should be on separate hubs, and that means it is _correct_ to have USB and Firewire as separate interface standards.

Don’t understand why? I have a Mac Mini, it has two USB ports, I hang a USB2 hub off one to plug in my cheap PC keyboard and mouse. With those plugged in, my USB2 2.5 inch HD can’t operate as a USB2 device, and falls back to USB1 speeds and protocols. Does that help explain why universal is not the answer to everything?

I know iNTEL would love to have it’s own devices be the universal solution, but that kind of behavior leads to the kind of silliness they pulled with UWB. The Motorola solution was better, lower power, less interfering. Motorola offered it free. iNTEL turned their corporate nose up at it. You could have gotten rid of all your data wires entirely, without leaking your data to anything sniffing nearby.

Give USB a rest. It does keyboards, mice, cheap printers, wacom style tablets, scanners, and such just fine. (Well, the tablets, mice, and keyboards, anyway.) Disks really belong on Firewire or better.