This post has been republished via RSS; it originally appeared at: Microsoft USB Blog articles.
First published on MSDN on Sep 22, 2010
Hello,
My name is Jane Lawrence and I am a program manager for USB Compatibility and USB Windows Logo Kit. In today’s blog post, I’ll be covering companion controllers. This content is targeted primarily towards hardware designers and chipset manufacturers. If you work with firmware or software, like devices and drivers, you are welcome to continue reading; however, you might not find the content as applicable to your designs.
Companion controller is defined as multiple USB host controllers (XHCI/EHCI/OHCI/UHCI) that are wired to the same physical connector such that a device, depending on some characteristic like speed, will be connected to a different controller even when plugged into the same connector. Here is what a high level companion controller design would look like for EHCI and XHCI:
Companion controllers may seem appealing as mitigation to compatibility concerns with older devices. In the past Microsoft supported vendors that used companion controllers when USB 2 specification first came out so that all systems can work with USB 1.0, 1.1 and 2.0 seamlessly.
Even though the USB 2 spec actually included support for full and low speed devices, the EHCI spec did not provide compatibility with full/low speed devices. To offer compatibility in EHCI there were two options: include a USB 2.0 hub for rate matching or add companion controllers so that EHCI/OHCI/UHCI controllers were wired to the same physical USB 2 ports. Many vendors chose the companion controller route. After a decade of dealing with companion controller issues and overly complicated designs, the Windows USB team have come to a conclusion that companion controllers introduce more problems than they solve and tend to lead to poor user experience. As such we urge our partners to avoid wiring XHCI and EHCI to the same physical connectors when designing their USB 3 solutions due to the following reasons:
1. No load order guarantees or power up ordering guarantees. Either controller could be started before the other, potentially leading to devices connecting to the wrong host. This may become worse if one of the driver stacks is disabled (maybe due to updating the driver).
2. If a device changes speeds, there would be no synchronization between the drivers for the different controllers, possibly resulting in multiple device instances with identical instance id being reported to PnP which may result in a bugcheck, enumeration failure, or other issue. This is particularly bad for USB 3.0 since users have seen where due to mechanical design issues with the connectors, some devices may enumerate over USB 2.0 first and then jump to USB 3.0 later. This quick speed switch is likely to result in hitting this situation, which will result in significant user experience and stability issues.
3. Having more controllers in the system impacts performance (boot, suspend, resume, shutdown), power consumption (the old controllers are notoriously bad on platform power), etc.
4. A single USB 3 hub contains both 3.0 and 2.0 IP to enable connectivity to USB 3 and legacy devices. These two pieces of IP enumerate independently on the bus, but they are not truly independent as they share resources such as port power and indicators. Often controller drivers need to coordinate between the two chipsets of the hub for things like overcurrent recovery, port power control, port indicators, etc. Since the two parts of the hubs will be enumerated by different controllers running different driver stacks, there is no ability for sharing the information and coordination of status.
To help enforce our design guidelines even further we have introduced a logo requirement which we believe will lead the emerging USB 3 ecosystem in the right direction and prevent systems with companion controllers appearing on the market.
As of December 1, 2010, a new Windows Logo requirement will be in effect to ensure that the port routing is done correctly: SYSFUND-0025: Systems which have xHCI controllers, must route the USB3.0 (SuperSpeed) and 2.0 port corresponding to each connector to the same xHCI controller. Once the logo requirement is in effect, all systems with companion controllers will not be able to get a Windows logo.
We are all in support of compatible device experience and would like to see all devices work when plugged into USB 3.0 ports just as they do when plugged into USB 2.0 ports. The xHCI specification is backwards compatible, which means new 3.0 ports can accept legacy connectors so when users connect their old devices into a USB 3 port, the devices will work at High/Full/Low Speed. Once in a while there are rare nuances in the design of the legacy devices that might not work the same when connected to the new USB 3.0 ports. This is expected since initial hardware and software implementation may not achieve 100% compatibility. The simplest and least problematic way to offer compatibility is to keep USB 2.0 ports on the system in addition to 3.0 ports (mixed port solution), so at times when the device does not work correctly when plugged into 3.0 port, the user can manually switch to USB 2.0 port. Here is what a high level mixed port design would look like for EHCI and XHCI:
In mixed port solutions, the non-SuperSpeed connectors are wired to an EHCI controller, and are completely independent from XHCI controller and SuperSpeed ports so they don’t exhibit the previously discussed issues.