1 / 70

Microsoft And Device Bay Dan Shapiro Program Manager Microsoft Corporation

Microsoft And Device Bay Dan Shapiro Program Manager Microsoft Corporation. Getting Started With Device Bay. Grant Ley, TI, Chuck Stancil, Compaq, and Krunali Patel, TI “USB Device Bay Controller Requirements” Jeff Wolford, Compaq

lala
Download Presentation

Microsoft And Device Bay Dan Shapiro Program Manager Microsoft Corporation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Microsoft And Device BayDan ShapiroProgram ManagerMicrosoft 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 ConsiderationsGrant Ley, Texas InstrumentsChuck Stancil, Compaq Krunali Patel, Texas Instruments

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

  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. ACPI DBC Implementation PCI ACPI USB root controller 1394 link controller PHY/Link interface Device Bay controller Walk-up port 1394 PHY Device Bay 0 Device Bay 1 Device Bay 2 Device Bay 3

  10. ACPI DBC Implementation • ACPI name space and control methods describe the DBC implementation • Can reside on a bus like PCI, I2C, 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 DBC Implementation PCI USB root controller 1394 link controller 1394 PHY Device Bay controller PHY/Link interface Walk-up port USB hub controller 1394 PHY Device Bay 0 Device Bay 1 Device Bay 2 Device Bay 3

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

  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 Host PC Remote Device Bay Power Supply 1394 OHCI Windows 1394 Walkup Port 0 Remote DBC 1394 Walkup Port 1 DBC Class Driver USB OHCI/UHCI USB Walkup Port 0 USB Walkup Port 1 Monitor Bay 1 Bay 0 Software stack: 1394 Bus Driver OHCI Port Driver SBP2 Port Driver USB Bus Driver USB OHCI Port Driver USB Audio Class Driver USB DBC Class Driver HDD DVD USB Speaker

  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 (VID 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. Driving The Bay Status Indicator • If using bipolar drivers with a 2-pin bipolar LED watch your supply voltage! • 3.3V probably isn’t high enough! • VOH(min) - VOL(max) VF(LED) + VR • typical case: VOH(min) VCC- 1.0V • VOL(max) 0.4V • VF(LED) 2.1V •  2.3V - 0.4V 2.1V + VR

  31. Driving The Bay Status Indicator • 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 SpecificationJeff WolfordSenior Systems ArchitectAdvanced Technology GroupCompaq 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 OverviewForm-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 OverviewRetaining 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, I2C, etc.) • Required functions: • Power control • Insertion events (PRSN) • Software-controlled interlock mechanism • 1394 PHY port mapping • USB port mapping

  44. Device Bay DevelopmentImplementers 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 DesignBay 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 DesignDevice 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 DesignRetention 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 DesignPower 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 DesignDBC 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

More Related