1. Microsoft And Device Bay Dan Shapiro Program Manager Microsoft Corporation

2. Getting Started With Device Bay  Grant Ley, TI, Chuck Stancil, Compaq, and Krunali Patel, TI  “USB Device Bay Controller Requirements”  Jeff Wolford, Compaq  “Building the First Device Bay Platforms and Devices”

3. USB Device Bay Controller: Implementation, Software, And Power Considerations Grant Ley, Texas Instruments Chuck Stancil, Compaq Krunali Patel, Texas Instruments

4. Device Expansion/remote bay system Bay Desktopsystem Bay management 1394 data path USB data path Mobilesystem Power The Device Bay Concept

5. Device Bay Specification  Open industry specification jointly developed by Compaq, Intel, and Microsoft  www.device-bay.org  Private questions: devicebay@acmenet.com  Public: send “subscribe device_bay” to majordomo@europa.com  Supports a wide variety of devices  Mass storage (HDD, DVD/CD-ROM, tape, etc.)  Communications and connectivity (modem, LAN)  Audio and security via USB

6. Device Bay Controller  For specification of the DBC, see Section 6 of the Device Bay Spec  DBC manages all bays  Maintains bay status  Detects device insertion/removal  Enables Vid (enumeration power) to the device  Detects user removal requests via optional bay mounted push button

7. Device Bay Connector Signals  Presence detect  USBPRSN#, 1394PRSN#  Pulled to ground to indicate interface type (USB or 1394 or both)  USB data signals  1394 data signals

8. DBC Signals To The Bay  Required:  Lock enable  ID power (Vid) enable  Optional:  Removal request  Security lock status  Bay status indicator

9. USB root controller controller 1394 link controller Walk-up port 1394 PHY Device Bay controller Device Bay 0 Device Bay 1 Device Bay 2 Device Bay 3 PHY/Link interface interface PCI ACPI ACPI DBC Implementation

10.  ACPI name space and control methods describe the DBC implementation  Can reside on a bus like PCI, I 2 C, SMBus  No physical connection between DBC and PHY  DBC data structures implemented as a register set

11. USB DBC Implementation  DBC implemented as a USB function  Connected to the USB hub  Can be integrated into the hub as an embedded function  Must have simple Link controller to communicate with a 1394 PHY  Walk-up ports can be connected to the same USB hub or 1394 PHY that is connected to the bays

12. USB DBC Implementation  DBC is a self-powered or bus-powered USB device  DBC communicates with system via USB control and interrupt endpoints (pipes)  DBC descriptors contain info about  Bay control  Bay status  DBC capabilities  DBC descriptors accessed using USB DBC class-specific requests

13. USB root controller controller 1394 link controller Walk-up port USB hub controller controller 1394 PHY Device Bay controller Device Bay 0 Device Bay 1 Device Bay 2 Device Bay 3 PHY/Link interface interface PCI 1394 PHY USB DBC Implementation

14. Device Bay standard Device BayController Device Power supply 1394 PHY System Bus USB Host Ctrl 1394 Host Ctrl CPU Mgmt. S/W Mech Form Factor(s) Connector Interface signals * USB Data * USB Data * 1394 Data * 1394 Data * Bay Management * Bay Management * Power * Power Management commands and procedures Communications methods * USB Class Device Computer system Bay Bay Phy/Link I/F 1394 PHY USB HUB Phy/Link I/F  “Riser card” in desktop chassis  “Remote” expansion chassis  Monitor with Device Bay capability  “Docking Station” for mobile platforms USB-Based DBC System

15. Remote Considerations  Bus or hybrid powered USB hub  Minimum of two 1394 walk-up ports  Three recommended to support spanning  Supply 1394 bus power  Recommend minimum of 15W at 20V  Support DB32 devices  Requires 12V support

16. Remote Device Bay System RemoteDBC PowerSupply 1394OHCI USBOHCI/UHCI Monitor Windows Windows DBCClassDriver 1394 Walkup Port 0 1394 Walkup Port 1 USB Walkup Port 0 USB Walkup Port 1 Bay 0 Bay 1 HDDDVDUSBSpeaker Software stack: 1394 Bus Driver 1394 Bus Driver OHCI Port Driver OHCI Port Driver SBP2 Port Driver SBP2 Port Driver USB Bus Driver USB Bus Driver USB OHCI Port Driver USB OHCI Port Driver USB Audio Class Driver USB Audio Class Driver USB DBC Class Driver USB DBC Class Driver Host PC Remote Device Bay

17. The Software Pieces  Universal Serial Bus Driver (USBD)  USB OHCI/UHCI port driver  1394 bus driver  1394 OHCI port driver

18. The DBC Link Controller  Supports a 400 Mbps PHY/link interface  Strongly recommend P1394a compliance  Software access to PHY registers compliant with method defined by 1394 OHCI Release 1.0  Asynchronous transaction capable  Minimal CSR and Config ROM space  General ROM format required

19. The DBC Link Controller  Isochronous resource manager, cycle master, and bus manager capability not required  Maximum payload size is 1 quadlet

20. USB DBC Class Specification  Defines the USB communication channel used by the DBC to communicate with the host  Standard device descriptor  Standard configuration descriptor  Standard endpoint descriptors  Control  Interrupt  USB port power management

21. USB DBC Class Specification  Device descriptors  Class-specific device descriptors  Subsystem descriptor  Bay descriptors  Standard device descriptor

22. USB DBC Class Specification  USB requests  Standard requests  Class-specific requests  GetBayStatus  Get/SetPHYCommunicationRegister  Optional vendor-specific requests  For example, asset tracking  Set/ClearFeature requests  See www.microsoft.com/hwdev for white paper about USB DBC Spec

23. Design Considerations  Bay state machine  The LOCK_CTL and PWR_CTL relationship  Initializing “read-only” fields  Driving the bay status indicator

24. Bay State Machine Design  Behavior after reset with a device present  The state transition Bay Empty  Device Inserted (or any other state) requires software intervention  DEVSTSCHG can either be set or cleared; if set system BIOS should clear it!

25. Bay State Machine Design  Software state transitions  All software state transition requests (via BAY_STREQ field in BCERx) must be qualified with device presence by the hardware!  Software state transitions occur at the time of the write to the BAY_STREQ field (i.e., there is no queuing!); however, DBC hardware will always retain the last non- zero value written to BAY_STREQ

26. LOCK_CTL And PWR_CTL Relationship  Normal sequence of these two bits : 1. After device is inserted S/W sets LOCK_CTL 2. S/W sets PWR_CTL 3. When device is to be removed S/W clears PWR_CTL 4. S/W clears LOCK_CTL  DBC hardware MUST prevent PWR_CTL (V ID enable) from being set if LOCK_CTL is not set

27. LOCK_CTL And PWR_CTL Relationship  If both bits are set and LOCK_CTL is erroneously cleared first (by S/W) then DBC hardware must automatically clear PWR_CTL  If the software controlled interlock mechanism is overridden then DBC hardware must clear PWR_CTL

28. Initializing “Read-Only” Fields  There are fields in the DBC (registers or descriptors) that contain static information about a DB subsystem; they could be implemented as “write-once” and initialized via:  An embedded controller  OEM BIOS  A configuration EEPROM

29. Driving The Bay Status Indicator  Use of bipolar drivers allows the system designer to use a two-pin bipolar (green/yellow) LED, a three-pin LED or discrete LEDs

30.  If using bipolar drivers with a 2-pin bipolar LED watch your supply voltage!  3.3V probably isn’t high enough! V OH(min) - V OL(max) V F(LED) + V R typical case: V OH(min)  V CC - 1.0V V OL(max)  0.4V V OL(max)  0.4V V F(LED)  2.1V V F(LED)  2.1V  2.3V - 0.4V 2.1V + V R Driving The Bay Status Indicator

31.  Don’t power the LEDs from an auxiliary or standby power supply! The LEDs must be off when the system is in S3 through S5!

32. Call To Action  Use Device Bay resources:  Spec is at www.device-bay.org  Private questions: devicebay@acmenet.com  Public: send “subscribe device_bay” to majordomo@europa.com  USB DBC Spec. white paper on www.microsoft.com/hwdev  OEMs and DBC silicon providers start working together  Send your hardware to Microsoft for software development and testing

33. Device Bay, Beyond The Specification Jeff Wolford Senior Systems Architect Advanced Technology Group Compaq Computer Corporation

34. Device Bay Introduction  Open industry specification jointly developed by Compaq, Intel, and Microsoft  www.device-bay.org  Private questions: devicebay@acmenet.com  Public: send “subscribe device_bay” to majordomo@europa.com  Supports a wide variety of devices:  Mass storage (HDD, DVD/CD-ROM, tape, etc.)  Communications and connectivity (modem, LAN)  Audio and security via USB

35. Device Bay Overview  Complete architecture for adding/upgrading PC peripherals without opening the chassis  Specifies bus interfaces, form factor, mechanicals, and OS behavior for device insertion and removal  Mandatory buses  Host: USB, 1394 (400 Mbit host ports) and POWER Bus(es) Vid, Vop  Device: either USB, 1394 or both + at least Vid and Vop if > 1.5 Watt Key enablers:  USB  IEEE 1394

36. Device Bay Overview Form-factors  3 Device Bay form-factors  DB32 - 32.00 x 146.00 x 178.00 mm  Size and power optimized for desktop  DB20 - 20.00 x 130.00 x 141.50 mm  DB13 - 13.00 x 130.00 x 141.50 mm  DB20 and DB13’s size and power optimized for, but not limited to, notebook implementations

37. Device Bay Overview Retaining a connection  Retention feature:  Required to engage immediately  Software-controlled interlock  Required  Security lock  Optional  Any of the above can be combined

38. Device Bay Overview Buses  Vid power: 1.5W at 3.3V (switched by the system)  Vop power (switched by the device)  DB32 - 30W electrical, 25W thermal  DB20 and DB13 - 4W  2 serial buses (1394 and USB)  Keeps appropriate performing devices on the corresponding bus  Allows power consumption to scale with performance of the device

39. Device Bay Overview USB  USB is a medium-bandwidth bus (1.2 - 12 Mbps)  Bay requirements:  One USB port per bay  Device Bay device requirements:  Provide power requirement registers  Unique serial number  If Vop is used, must be switched with configuration complete command

40. Device Bay Overview 1394  IEEE 1394 and future extensions:  Initial transfer rate is 100 - 400 Mb/s, with P1394A and P1394B extensions to support Gbps data rates that must be backward compatible  Device Bay bay requirements:  One 1394 port per bay  Must support 400Mbps minimum

41. Device Bay Overview 1394  Device Bay device requirements:  Provide power requirement registers  If Vop is used, must be switched with start/stop unit command  Devices can use 100 - 400Mbps  Encouraged to use highest rate possible for devices to minimize equivalent bandwidth requirements

42. Device Bay Overview Connector  Open industry standard  Blind-mate connector pair  Plug in the device, receptacle in the bay  Supports power, one USB port, and one 1394 port in one connector  Pin configuration for higher speed 1394 (> 1Gb/s) and hot-plug  High durability (min 2,500 cycles)  Flexible and cable friendly

43. Device Bay Overview Device Bay Controller (DBC)  Two possible implementations:  USB  ACPI - abstracts HW I/F (PCI, I 2 C, etc.)  Required functions:  Power control  Insertion events (PRSN)  Software-controlled interlock mechanism  1394 PHY port mapping  USB port mapping

44. Device Bay Development Implementers guide  Bay mechanical design  Bay electrical design  Device Bay Controller (DBC) software requirements  Device mechanical design  Device electrical design  Power  Signal  Reset

45. Bay Mechanical Design Bay cover  A bay must be covered when no device is present to keep from “short circuiting” the air flow from other bays  Watch out for:  Devices that are hollow in the center  Hanging up on device’s retention features  Interacting with the ESD/EMI bay spring

46. Bay Mechanical Design Device alignment  Bay must provide rough device alignment  Needs to get the device to a +/-2mm connector tolerance  Needs to keep the device in tight vertical and horizontal tolerance  Allows retention and interlock features to engage and disengage properly

47. Bay Mechanical Design Retention mechanism  Needs to hold the device on the connector and not allow the device to back off (i.e., 1.46 mm minimum wipe)  Design for multiple device enclosure materials:  Steel, aluminum, plastic, and bi-material (metal over plastic) that produces two materials on the same retention face

48. Bay Electrical Design Power switching  Vid switching:  Should be ramped  Insertion resistance (FET, wire, etc.)  Vop switching:  Optional  Difficult to maintain valid voltages  Feedback from processor power, not from DB power  Must support switching of maximum power on all voltage rails

49. Bay Electrical Design Connector sets  Connector stack-up:  Two sets minimum for cable version  Easy to get three sets  Watch termination and differential routing through noisy digital logic  There may also be one set in the device for mechanical isolation or for adapters

50. Bay Controller Design DBC software  After an insertion notification, the DBC driver needs to verify several things before it turns on Vid  Verify the Bay is enabled to take devices  Verify there is 1.5W in the power budget  Wait for the device to settle down and become fully latched on the connector before enabling power

51. Device Design: Mechanical Critical dimensions  Most critical is keeping the connector square:  Connector float in the Bay and connector blind-mate features will compensate for some tolerance in the X, Y, and Z planes  But, if the connector is not square with the device, the float and blind-mate will be of little help  DB32 height is +/-0.25mm

52. Device Design: Mechanical Retention features  Critical dimension is from the retention edge to the back of the device  Required faces must be present and in tolerance  Bi-material features must have smooth transition from one material to another so as not to “snag” the bay’s retention mechanism

53. Device Design: Mechanical Device shell  Round corners and edges within spec:  Round edges reduces the drag of insertion and removal of device  Round corners help the user get the device lined up and in the bay  Round edges supports new handling models  The device “feels” better in the user’s hands

54. Device Design: Mechanical Device shell  Cosmetics no longer limited to front bezel  Users now see the entire device  Additional user models beyond upgrade need to be considered:  Casual device swapping  Taking devices on the road

55. Device Design: Electrical Power switching  Vop power switching  di/dt requirements support:  Hot plugging  Capacitance load-independent  Supports lower power consuming PC in the future  Vid - switched by the Bay (1.5W,3.3V)  Needed to power the native bus interface and allow access of identification and power registers

56. Device Design: Electrical Power switching  Vop power switching assumptions:  No more than 5uA can be drawn on Vop if Vid is not valid  When Vid is not valid, Vid is not required to be shorted to ground  Vop may or may not be valid when Vid is disabled  Vop power rails can be switched on/off in any order when Vid is not valid

57. Device Design: Power  1394: PHY’s with Links required as first connection  Provides Link to get device information, including driver and power requirements  Full power authorization via native bus driver stack:  USB: configuration complete  1394: Start Unit command  Device Bay power manager would fail the above commands to block enumeration

58. Device Design: Power  All devices are required to support ACPI states 0, 2, and 3  Support of state 1 is highly desired to support a fully power managed PC  0: device is fully on  1: reduced power consumption on Vop  2: no power consumption on Vop and, if possible, reduced power on Vid  Can be same as pre-enumeration state  3: device is fully off

59. Device Design Electrical problems  Problem: using 12V of Vop for switch voltage enhancement for V5 and V33  Vid is not valid, thus the gate might not be grounded  Vop12v is valid, thus the gate might not be pulled to 12V

60. Device Design Electrical problems  Problem: using Vid (3.3V) and Vop (5V) to drive reset circuits  Vop is only required to be valid with Vid  If Vop is used for a reset RC circuit, the reset might not be done when Vid becomes valid

61. Device Design Electrical problems  Problem: input leakage current and voltage for a device that is off  Could violate 5uA current limit  Voltage feed-through could allow this voltage to come out another pin  Requires fail-safe buffers

62. Device Design Electrical problems  Problem: tying two resets together  PHY reset RC was biased to 1.4V because of input voltage leak when the device was powered off via TPbias  PHY reset was tied to Link reset, causing the Link reset edge to start at 1.4V, causing a non-complete edge on its reset

63. Device Design Reset problems  When the 1394 bus has completed the self-ID phase, the Link must be able to respond to CSR and ROM reads; if it cannot, there are several options:  Best: be able to respond after self-ID  Second best: respond with an ack- pending and respond before the ack- pending times out

64. Device Design Reset problems  Link reads after self-ID  Third best: strap PHY to come up in link-off mode  Then when the Link is able to take commands, assert the LPS to the PHY and if the PHY does not do a reset on LPS status change, pop a 1394 bus reset  Worst, but better than none: let the initial CSR read’s ack time-out; when the Link becomes available, cause a 1394 bus reset

65. Demo: Device Insertion DB device DB connector Device Bay controller DBC driver Device Bay powermanager USBACPI PRSN V33 V5 V12 Vid PCI OHCI 1394 PHY 1394 1394 class OHCITILINKS PCI SBP-2 Disk.sys PWR FILTER PRSN -> DBC, DBC Driver Device Insertion Device Insertion Start blinking LED Start blinking LED DBC Driver -> DB PWR MGR Do we have 1.5 W ? Do we have 1.5 W ? DB PWR MGR -> DBC Driver YES YES DBC Driver -> DBC IF Vop switched, turn on Vop IF Vop switched, turn on Vop Turn on Vid Turn on Vid Turn LED on solid Turn LED on solid Wait for Native Bus to take over Wait for Native Bus to take over NATIVE BUS: Disk.sys -> SBP-2 Start Unit Start Unit SBP-2 -> PWR Filter PWR Filter -> DB PWR MGR See Start Unit See Start Unit DB PWR MGR -> 1394 Filter Read Unit Directory Power Reg Read Unit Directory Power Reg 1394 Filter -> DB PWR MGR Power Requirements Data Power Requirements Data DB PWR MGR -> 1394 Filter Pass or Fail Start Unit Pass or Fail Start Unit

66. Demo: Copy Files  Copy files from Device Bay device to another

67. DB device Demo: Device Removal DB connector Device Bay controller DBC driver Plug -n- Play manager USBACPI PRSN V33 V5 V12 Vid PCI OHCI 1394 PHY 1394 1394 class OHCITILINKS PCI SBP-2 Disk.sys PWR FILTER RemReq -> DBC Start blinking LED Start blinking LED DBC -> DBC Driver Device Removal Request Device Removal Request DBC Driver -> Plug-n-Play MGR Remove Device Request Remove Device Request Plug-n-Play MGR Close down all open file handles Close down all open file handles Send the device to D3 state Send the device to D3 state When complete, send ACK to When complete, send ACK to DBC Driver DBC Driver DBC Driver -> DBC Turn off Vid Turn off Vid Wait for device to discharge Wait for device to discharge IF Vop switched, turn off Vop IF Vop switched, turn off Vop Turn LED off Turn LED off Release software interlocks Release software interlocks DBC Driver -> DB PWR MGR Release allocated power Release allocated power RemReq

68. Demo: Moving Devices  Show movement of a Device Bay device from one machine to another

69. Demo: Swapping Devices  Remove one Device Bay device  Insert a different Device Bay device in the same bay

70. Questions And Answers