USB Power Delivery v2.0 Specification Finalized - USB Gains Alternate Modesby Brett Howse on September 17, 2014 8:00 AM EST
The last while has been a busy time for the USB 3.0 Promoters Group, with the new USB 3.1 Type-C Connector detailed last month. Joshua was able to get a hands on with the new connector at IDF last week. With support for up to 10 Gbps, a new reversible Type-C connector, and up to 100 watts of power delivery, the USB group is trying to expand the already universal connector to be able to do much more than is possible with the current specification. To fulfill this mandate, they have now finalized the USB Power Delivery v2.0 spec, and the Billboard Device Class v1.0 spec.
When USB was first introduced, the thought was that it would be primarily a data interface, with a limited amount of power delivery which was generally used to power the electronics of certain devices. The initial specification for USB only had provisions for 0.75 watts of power – 150 mA at 5 V. USB 2.0 bumped that to 500 mA, or 2.5 watts, and USB 3.0 specified 900 mA at 5 V, or 4.5 watts. All of these specifications allow for power as well as data transmission at the same time. In addition, there was also a Battery Charging specification which allows up to 1.5 A at 5 V for a maximum of 7.5 watts of power but with no data transmission available. The jump from 7.5 watts to 100 watts of the new specification is a huge increase, and one that cannot be done with just an amperage increase on the system as was done in the previous versions of USB. Version 3.1 now supports 5 V, 12 V, and 20 V on the pins to allow the higher power output without excessive current, but even the current has been increased to a maximum of 5 A which is much higher than before.
The inelegant USB 3.0 Micro-B connector
USB Power Delivery is designed to increase the flexibility of USB, by providing enough power for many more devices, while at the same time still allowing data delivery. It is also even more flexible, due to a couple of changes. First, the direction of power delivery is no longer fixed. Imagine a tablet with a keyboard attached. The keyboard can have a battery, and the battery can be charged through the data connection, but when the tablet is unplugged from its charger, the power flow can reverse and the tablet can now be powered by the keyboard. Another example is a laptop with six USB ports. The USB ports can be used for peripherals, or, a USB charger can be connected to any port to charge the laptop. Dedicated charging connectors will no longer be required.
The reversible USB 3.1 Type-C connector
Another change is that all devices must now negotiate the amount of power required, and that can be renegotiated if another devices requires additional power. A good scenario would be if you have a laptop, and you are charging your phone on one of the USB ports. The phone would be pulling the maximum amount of power it can in order to charge quickly. If you then plug in a USB RAID array, it will need additional power at the start in order to get all of the disks spinning, but then can be lowered to a steady state. The system can lower the power delivery to the phone, provide it to the RAID array, and then move it back to the phone when the power is available.
The final key is that the Power Delivery specification is not just for power, nor is it just for USB. The Power Delivery Specification allows Alternate Modes to be defined, and the system can negotiate to enable these modes, enter them, and exit them. These modes will be defined outside the scope of USB-IF specifications using Structured Vendor Defined Messages. This allows the ability to reconfigure some of the pins a USB Type-C connector exposes and will allow the cable to be used for many different purposes rather than just for USB.
This leads us to the second specification – the Billboard Device Class. This specification outlines the methods used to communicate the Alternate Modes supported by the Device Container to a host system. It includes descriptors which can be used to provide support details in a human-readable format. What it does not contain is the methodology to switch to the Alternate Mode – that is done in the Power Delivery specification itself. The Billboard Device Class will allow a device which supports an Alternate Mode to connect to a host which does not support that mode, and then inform the user why it does not work without having silent failures, and for this reason all Billboard Devices must support USB 2.0 as a minimum.
This new framework could open the ubiquitous USB cable up to an entirely new array of devices and functions. One possibility that the USB-IF mentions in the specification is a theoretical means for PCI-E over USB. I’ve already given the example of a tablet with a battery in the keyboard, but a laptop could be connected to a monitor which can also charge the laptop. Much more power hungry devices can be connected to a USB port as well, including printers and high speed storage. All of this was defined with a graceful fail as well, so the user is not stuck wondering why his device is not functioning any longer.
The new Alternate Modes have quite a potential, and with the increased power capabilities of USB 3.1 and the Power Delivery Specification, it will be very interesting to see how these capabilities are taken advantage of in future devices.
Post Your CommentPlease log in or sign up to comment.
View All Comments
SirKnobsworth - Thursday, September 18, 2014 - linkThe host controller needs to be able to communicate in order to configure the alternate signaling modes, yes. Though I suspect this will often be done outside the USB controller itself.
tuxRoller - Monday, September 22, 2014 - linkSo the xhci (3.1?) will need to support a diverse signalling regime (all potential protocols?!!), but what does "will often be done outside the USB controller itself" mean? Are you referring to an adjacent component to the controller which would be responsible for handling the non-usb traffic (everything related to specific line protocol that the component was designed to handle), and then simply pass on the precessed data to the (dumb)controller? Something like that makes more sense than handling this in the driver.
repoman27 - Thursday, September 18, 2014 - linkThe port can operate in multiple different signaling modes. While it is unlikely that we'll see the xHCI controllers themselves adopt alternate modes, controllers for the current crop of multi-mode serial I/O interfaces such as DockPort or Thunderbolt are prime candidates. It appears that Intel will be including a USB 3.0 signaling mode in the next generation Alpine Ridge Thunderbolt controllers and will be switching to a new connector. Hmmm... Type-C perhaps?
Really all you need is a simple mux / switch to steer the appropriate signals from any of several different host controllers to the port based on the capabilities advertised by the device via USB PD 2.0 and the Billboard Device Class. I think what they're getting at here is that you could essentially connect a couple PCIe lanes directly to the high speed signaling lines of a USB Type-C cable using this trick.
tuxRoller - Monday, September 22, 2014 - linkThis makes sense. So the host controllers don't actually support the protocols themselves, but simply handle the negotiations for adjacent (presumably) controllers.
They better find some way to make it CLEAR to consumers what it is that each port can handle.
Thanks for the explanation!
email@example.com - Friday, September 19, 2014 - linkA home that runs only on DC power (Harvested from PV panels), Can this technology take us closer to that?
Ethos Evoss - Thursday, September 25, 2014 - linkcoomeooon just relleaseee iiiit alreadyyyyy .. CANT WAIT on smartphones !! FCUK the weird lightning ,or storm or thunderbolt whatever - weather called cable !!