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

“Building the First Device Bay
Platforms and Devices”
USB Device Bay Controller:
Implementation, Software,
And Power Considerations
Grant Ley, Texas Instruments
Chuck Stancil, Compaq
Krunali Patel, Texas Instruments
The Device Bay Concept
Expansion/remote
bay system
Desktop
system
Bay
USB data path
1394 data path
Bay management
Power
Device
Mobile
system
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
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
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
DBC Signals To The Bay

Required:



Lock enable
ID power (Vid) enable
Optional:



Removal request
Security lock status
Bay status indicator
ACPI DBC Implementation
PCI
USB root
controller
1394 link
controller
ACPI
Device Bay
controller
Walk-up port
1394 PHY
Device
Device
Device
Device
Bay 0
Bay 1
Bay 2
Bay 3
PHY/Link
interface
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
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
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
USB DBC Implementation
PCI
USB root
controller
1394 link
controller
1394 PHY
USB hub
controller
Device Bay
controller
PHY/Link
interface
1394 PHY
Device
Device
Device
Device
Bay 0
Bay 1
Bay 2
Bay 3
Walk-up port
USB-Based DBC System
Device Bay standard
Communications
methods
* USB Class Device
Management
commands and
procedures
Computer system
Interface signals
* USB Data
* 1394 Data
* Bay Management
* Power
Connector
Mech Form
Factor(s)
System Bus
Bay
USB
HUB
USB
Host
Ctrl
CPU
Mgmt.
S/W
Device
Bay
Controller
Phy/Link
I/F
1394
Host
Ctrl
1394
PHY
Bay
1394
PHY
Device
Phy/Link
I/F




“Riser card” in desktop chassis
“Remote” expansion chassis
Monitor with Device Bay capability
“Docking Station” for mobile platforms
Power
supply
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
Remote Device Bay System
Host PC
Windows
DBC
Class
Driver
Remote Device Bay
1394
OHCI
Power
Supply
1394 Walkup Port 0
1394 Walkup Port 1
Remote
DBC
USB
OHCI/UHCI
USB Walkup Port 0
USB Walkup Port 1
Monitor
Bay 0 Bay 1
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
The Software Pieces




Universal Serial Bus Driver (USBD)
USB OHCI/UHCI port driver
1394 bus driver
1394 OHCI port driver
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
The DBC Link Controller


Isochronous resource manager, cycle
master, and bus manager capability
not required
Maximum payload size is 1 quadlet
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
USB DBC Class Specification

Device descriptors


Class-specific device descriptors
 Subsystem descriptor
 Bay descriptors
Standard device descriptor
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
Design Considerations




Bay state machine
The LOCK_CTL and
PWR_CTL relationship
Initializing “read-only” fields
Driving the bay status indicator
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!
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 nonzero value written to BAY_STREQ
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
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
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
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
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
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!
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
Device Bay,
Beyond The Specification
Jeff Wolford
Senior Systems Architect
Advanced Technology Group
Compaq Computer Corporation
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
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
Key enablers:
 USB
 IEEE 1394
 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
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
Device Bay Overview
Retaining a connection

Retention feature:


Software-controlled interlock


Required
Security lock


Required to engage immediately
Optional
Any of the above can be combined
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Device Design: Power

All devices are required to support
ACPI states 0, 2, and 3




0: device is fully on
1: reduced power consumption on Vop
2: no power consumption on Vop and,
if possible, reduced power on Vid


Support of state 1 is highly desired to
support a fully power managed PC
Can be same as pre-enumeration state
3: device is fully off
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
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
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
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
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 ackpending and respond before the ackpending times out
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
Demo: Device Insertion
Disk.sys
SBP-2
PWR FILTER
Device Bay
power
manager
1394 class
OHCI
TI
LINKS
DBC driver
USB
PCI
ACPI
PRSN
V33
V5
V12
Vid
Device Bay
controller
DB connector
DB device
PCI OHCI
1394 PHY
1394
PRSN -> DBC, DBC Driver
Device Insertion
Start blinking LED
DBC Driver -> DB PWR MGR
Do we have 1.5 W ?
DB PWR MGR -> DBC Driver
YES
DBC Driver -> DBC
IF Vop switched, turn on Vop
Turn on Vid
Turn LED on solid
Wait for Native Bus to take over
NATIVE BUS:
Disk.sys -> SBP-2
Start Unit
SBP-2 -> PWR Filter
PWR Filter -> DB PWR MGR
See Start Unit
DB PWR MGR -> 1394 Filter
Read Unit Directory Power Reg
1394 Filter -> DB PWR MGR
Power Requirements Data
DB PWR MGR -> 1394 Filter
Pass or Fail Start Unit
Demo: Copy Files

Copy files from Device Bay
device to another
Demo: Device Removal
Disk.sys
SBP-2
PWR FILTER
Plug -n- Play
manager
1394 class
OHCI
TI
LINKS
DBC driver
USB
PRSN
V33
V5
V12
Device Bay
controller
Vid
RemReq
PCI
ACPI
DB connector
DB device
PCI OHCI
1394 PHY
1394
RemReq -> DBC
Start blinking LED
DBC -> DBC Driver
Device Removal Request
DBC Driver -> Plug-n-Play MGR
Remove Device Request
Plug-n-Play MGR
Close down all open file handles
Send the device to D3 state
When complete, send ACK to
DBC Driver
DBC Driver -> DBC
Turn off Vid
Wait for device to discharge
IF Vop switched, turn off Vop
Turn LED off
Release software interlocks
DBC Driver -> DB PWR MGR
Release allocated power
Demo: Moving Devices

Show movement of a Device Bay
device from one machine to another
Demo: Swapping Devices


Remove one Device Bay device
Insert a different Device Bay
device in the same bay
Questions And Answers