README revision 77e515715b61e28fcf0c3f30936492888cecfd8b
#
# CDDL HEADER START
#
# The contents of this file are subject to the terms of the
# Common Development and Distribution License (the "License").
# You may not use this file except in compliance with the License.
#
# You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
# See the License for the specific language governing permissions
# and limitations under the License.
#
# When distributing Covered Code, include this CDDL HEADER in each
# file and include the License file at usr/src/OPENSOLARIS.LICENSE.
# If applicable, add the following below this CDDL HEADER, with the
# fields enclosed by brackets "[]" replaced with your own identifying
# information: Portions Copyright [yyyy] [name of copyright owner]
#
# CDDL HEADER END
#
/*
* Copyright 2008 Sun Microsystems, Inc. All rights reserved.
* Use is subject to license terms.
*/
SOLARIS USB BANDWIDTH ANALYSIS
This document discuss the USB bandwidth allocation scheme, and the protocol
overheads used for both full and high speed host controller drivers. This
information is derived from the USB 2.0 specification, the "Bandwidth Analysis
Whitepaper" which is posted on www.usb.org, and other resources.
The target audience for this whitepaper are USB software & hardware designers
and engineers, and other interested people. The reader should be familiar with
the Universal Serial Bus Specification version 2.0, the OpenHCI Specification
1.0a and the Enhanced HCI Specification 1.0.
2.Full speed bus
The following overheads, formulas and scheme are applicable both to full speed
host controllers and also to high speed hub Transaction Translators (TT),
which perform full/low speed transactions.
o Timing and data rate calculations
- Timing calculations
1 sec 1000 ms or 1000000000 ns
1 ms 1 frame
- Data rate calculations
1 ms 1500 bytes or 12000 bits (per frame)
668 ns 1 byte or 8 bits
1 full speed bit time 83.54 ns
o Protocol Overheads and Bandwidth numbers
- Protocol Overheads
(Refer 5.11.3 section of USB2.0 specification & page 2 of USB Bandwidth
Analysis document)
Non Isochronous 9107 ns 14 bytes
Isochronous Output 6265 ns 10 bytes
Isochronous Input 7268 ns 11 bytes
Low-speed overhead 64060 ns 97 bytes
Hub LS overhead* 668 ns 1 byte
SOF 4010 ns 6 bytes
EOF 2673 ns 4 bytes
Host Delay* Specific to hardware 18 bytes
Low-Speed clock* Slower than Full speed 8
- Bandwidth numbers
(Refer 7.3.5 section of OHCI specification 1.0a & page 2 of USB Bandwidth
Analysis document)
Maximum bandwidth available 1500 bytes/frame
Maximum Non Periodic bandwidth 197 bytes/frame
Maximum Periodic bandwidth 1293 bytes/frame
NOTE:
1.Hub specific low speed overhead
The time provided by the Host Controller for hubs to enable Low Speed
ports. The minimum of 4 full speed bit time.
overhead = 2 x Hub_LS_Setup
= 2 x (4 x 83.54) = 668.32 Nano seconds = 1 byte.
2.Host delay will be specific to particular hardware. The following host
delay is for RIO USB OHCI host controller (Provided by Ken Ward - RIO
USB hardware person). The following is just an example how to calculate
"host delay" for given USB host controller implementation.
Ex: Assuming ED (Endpoint Descriptor)/TD's (Transfer Descriptor) are not
streaming in Schizo (PCI bridge) and no cache hits for an ED or TD:
To read an ED or TD or data:
PCI_ARB_DELAY + PCI_ADDRESS + SCHIZO_RETRY
PCI_ARB_DELAY + PCI_ADDRESS + SCHIZO_TRDY +
DATA + Core_overhead
Where,
PCI_ARB_DELAY = 2000ns
PCI_ADDRESS = 30ns
SCHIZO RETRY = 60ns
SCHIZO TRDY = 60ns
DATA = 240ns (Always read 64 bytes ...)
Core Overhead =240 + 30 * (MPS/4) + 83.54 * (MPS/4) + 4 * 83.54
= ~3400ns
now multiply by 3 for ED+TD+DATA = 10200ns = ~128 bits or 16 bytes.
This is probably on the optimistic side, only using 2us for the
PCI_ARB_DELAY.
If there is a USB cache hit, the time it takes for an ED or TD is:
CORE SYNC DELAY + CACHE_HIT CHECK + 30 * (MPS/4) + CORE OVERHEAD
240 + 30 + 120 + 1000ns ~ 1400ns , or ~ 2 bytes
Total Host delay will be 18 bytes.
the full speed.
4.For non-periodic transfers, reserve for at least one low-speed device
transaction per frame. According to the USB Bandwidth Analysis white
paper and also as per OHCI Specification 1.0a, section 7.3.5, page 123,
one low-speed transaction takes 0x628h full speed bits (197 bytes),
which comes to around 13% of USB frame time.
5. Maximum Periodic bandwidth is calculated using the following formula
Maximum Periodic bandwidth = Maximum bandwidth available
- SOF - EOF - Maximum Non Periodic bandwidth.
o Bus Transaction Formulas
(Refer 5.11.3 section of USB2.0 specification)
- Full-Speed:
Protocol overhead + ((MaxPacketSize * 7) / 6 ) + Host_Delay
- Low-Speed:
Protocol overhead + Hub LS overhead +
(Low-Speed clock * ((MaxPacketSize * 7) / 6 )) + Host_Delay
o Periodic Schedule
The figure 5.5 in OHCI specification 1.0a gives you information on periodic
scheduling, different polling intervals that are supported, & other details
for the OHCI host controller.
- The host controller processes one interrupt endpoint descriptor list every
frame. The lower five bits of the current frame number us used as an
index into an array of 32 interrupt endpoint descriptor lists or periodic
frame lists found in the HCCA (Host controller communication area). This
means each list is revisited once every 32ms. The host controller driver
sets up the interrupt lists to visit any given endpoint descriptor in as
many lists as necessary to provide the interrupt granularity required for
that endpoint. See figure 5.5 in OHCI specification 1.0a.
- Isochronous endpoint descriptors are added at the end of 1ms interrupt
endpoint descriptors.
- The host controller driver maintains an array of 32 frame bandwidth lists
to save bandwidth allocated in each USB frame.
Please refer section 5.2.7.2 of OHCI specification 1.0a, page 61 for more
details.
o Bandwidth Allocation Scheme
The OHCI host controller driver will go through the following steps to
allocate bandwidth needed for an interrupt or isochronous endpoint as
follows
- Calculate the bandwidth required for the given endpoint using the bus
transaction formula and protocol overhead calculations mentioned in
previous section.
- Compare the bandwidth available in the least allocated frame list out of
the 32 frame bandwidth lists, against the bandwidth required by this
endpoint. If this exceeds the limit, then, an return error.
- Find out the static node to which the given endpoint needs to be linked
so that it will be polled as per the required polling interval. This value
varies based on polling interval and current bandwidth load on this
schedule. See figure 5.5 in OHCI specification 1.0a.
Ex: If a polling interval is 4ms, then, the endpoint will be linked to one
of the four static nodes (range 3-6) in the 4ms column of figure 5.5
in OHCI specification 1.0a.
- Depending on the polling interval, we need to add the above calculated
bandwidth to one or more frame bandwidth lists. Before adding, we need to
double check the availability of bandwidth in those respective lists. If
this exceeds the limit, then, return an error. Add this bandwidth to all
the required frame bandwidth lists.
Ex: Assume a give polling interval of 4 and a static node value of 3.
In this case, we need to add required bandwidth to 0,4,8,12,16,20,24,
28 frame bandwidth lists.
3.High speed bus
o Timing and data rate calculations
- Timing calculations
1 sec 1000 ms
125 us 1 uframe
1 ms 1 frame or 8 uframes
- Data rate calculations
125 us 7500 bytes (per uframe)
16.66 ns 1 byte or 8 bits
1 high speed bit time 2.083 ns
o Protocol Overheads and Bandwidth numbers
- Protocol Overheads
(Refer 5.11.3, 8.4.2.2 and 8.4.2.3 sections of USB2.0 specification)
Non Isochronous 917 ns 55 bytes
Isochronous 634 ns 38 bytes
Start split overhead 67 ns 4 bytes
Complete split overhead 67 ns 4 bytes
SOF 200 ns 12 bytes
EOF 1667 ns 70 bytes
Host Delay* Specific to hardware 18 bytes
- Bandwidth numbers
(Refer 5.5.4 section of USB2.0 specification)
Maximum bandwidth available 7500 bytes/uframe
Maximum Non Periodic bandwidth* 1500 bytes/uframe
Maximum Periodic bandwidth* 5918 bytes/uframe
NOTE:
1.Host delay will be specific to particular hardware.
2.As per USB 2.0 specification section 5.5.4, 20% of bus time is reserved
for the non-periodic high-speed transfers, where as periodic high-speed
transfers will get 80% of the bus time. In one micro-frame or 125us, we
can transfer 7500 bytes or 60,000 bits. So 20% of 7500 is 1500 bytes.
3.Maximum Periodic bandwidth is calculated using the following formula
Maximum Periodic bandwidth = Maximum bandwidth available
- SOF - EOF - Maximum Non Periodic bandwidth.
o Bus Transaction Formulas
(Refer 5.11.3 8.4.2.2 and 8.4.2.3 sections of USB2.0 specification)
- High-Speed (Non-Split transactions):
(Protocol overhead + ((MaxPacketSize * 7) / 6 ) +
Host_Delay) x Number of transactions per micro-frame
- High-Speed (Split transaction - Device to Host):
Start Split transaction:
Protocol overhead + Host_Delay + Start split overhead
Complete Split transaction:
Protocol overhead + ((MaxPacketSize * 7) / 6 ) +
Host_Delay + Complete split overhead
- High-Speed (Split transaction - Host to Device):
Start Split transaction:
Protocol overhead + ((MaxPacketSize * 7) / 6 ) +
Host_Delay) + Start split overhead
Complete Split transaction:
Protocol overhead + Host_Delay + Complete split overhead
o Interrupt schedule or Start and Complete split masks
(Refer 3.6.2 & 4.12.2 sections of EHCI 1.0 specification)
- Interrupt schedule or Start split mask
This field is used for for high, full and low speed usb device interrupt
and isochronous endpoints. This will tell the host controller which micro-
frame of a given usb frame to initiate a high speed interrupt and
isochronous transaction. For full/low speed devices, it will tell when to
initiate a "start split" transaction.
ehci_start_split_mask[15] = /* One byte field */
/*
* For all low/full speed devices, and for high speed devices with
* a polling interval greater than or equal to 8us (125us).
*/
{0x01, /* 00000001 */
0x02, /* 00000010 */
0x04, /* 00000100 */
0x08, /* 00001000 */
0x10, /* 00010000 */
0x20, /* 00100000 */
0x40, /* 01000000 */
0x80, /* 10000000 */
/* For high speed devices with a polling interval of 4us. */
0x11, /* 00010001 */
0x22, /* 00100010 */
0x44, /* 01000100 */
0x88, /* 10001000 */
/* For high speed devices with a polling interval of 2us. */
0x55, /* 01010101 */
0xaa, /* 10101010 */
/* For high speed devices with a polling interval of 1us. */
0xff }; /* 11111111 */
- Complete split mask
This field is used only for full/low speed usb device interrupt and
isochronous endpoints. It will tell the host controller which micro frame
to initiate a "complete split" transaction. Complete split transactions
can to be retried for up to 3 times. So bandwidth for complete split
transaction is reserved in 3 consecutive micro frames
ehci_complete_split_mask[8] = /* One byte field */
/* Only full/low speed devices */
{0x0e, /* 00001110 */
0x1c, /* 00011100 */
0x38, /* 00111000 */
0x70, /* 01110000 */
0xe0, /* 11100000 */
Reserved , /* Need FSTN feature */
Reserved , /* Need FSTN feature */
Reserved}; /* Need FSTN feature */
o Periodic Schedule
The figure 4.8 in EHCI specification gives you information on periodic
scheduling, different polling intervals that are supported, and other
details for the EHCI host controller.
- The high speed host controller can support 256, 512 or 1024 periodic frame
lists. By default all host controllers will support 1024 frame lists. In
our implementation, we support 1024 frame lists and we do this by first
constructing 32 periodic frame lists and duplicating the same periodic
frame lists for a total of 32 times. See figure 4.8 in EHCI specification.
- The host controller traverses the periodic schedule by constructing an
array offset reference from the PERIODICLISTBASE & the FRINDEX registers.
It fetches the element and begins traversing the graph of linked schedule
data structure. See fig 4.8 in EHCI specification.
- The host controller processes one interrupt endpoint descriptor list every
micro frame (125us). This means same list is revisited 8 times in a frame.
- The host controller driver sets up the interrupt lists to visit any given
endpoint descriptor in as many lists as necessary to provide the interrupt
granularity required for that endpoint.
- For isochronous transfers, we use only transfer descriptors but no
endpoint descriptors as in OHCI. Transfer descriptors are added at the
beginning of the periodic schedule.
- For EHCI, the bandwidth requirement is depends on the usb device speed
For a high speed usb device, you only need high speed bandwidth. For a
full/low speed device connected through a high speed hub, you need both
high speed bandwidth and TT (transaction translator) bandwidth.
High speed bandwidth information is saved in an EHCI data structure and TT
bandwidth is saved in the high speed hub's usb device data structure. Each
TT acts as a full speed host controller & its bandwidth allocation scheme
overhead calculations and other details are similar to those of a full
speed host controller. Refer to the "Full speed bus" section for more
details.
- The EHCI host controller driver maintains an array of 32 frame lists to
store high speed bandwidth allocated in each frame and also each frame
list has eight micro frame lists, which saves bandwidth allocated in each
micro frame of that particular frame.
o Bandwidth Allocation Scheme
(Refer 3.6.2 & 4.12.2 sections of EHCI 1.0 specification)
High speed Non Split Transaction (for High speed devices only):
For a given high speed interrupt or isochronous endpoint, the EHCI host
controller driver will go through the following steps to allocate
bandwidth needed for this endpoint.
- Calculate the bandwidth required for given endpoint using the formula and
overhead calculations mentioned in previous section.
- Compare the bandwidth available in the least allocated frame list out of
the 32 frame lists against the bandwidth required by this endpoint. If
this exceeds the limit, then, return an error.
- Map a given high speed endpoint's polling interval in micro seconds to an
interrupt list path based on a millisecond value. For example, an endpoint
with a polling interval of 16us will map to an interrupt list path of 2ms.
- Find out the static node to which the given endpoint needs to be linked
so that it will be polled at its required polling interval. This varies
based on polling interval and current bandwidth load on this schedule.
Ex: If a polling interval is 32us and its corresponding frame polling
interval will be 4ms, then the endpoint will be linked to one of the
four static nodes (range 3-6) in the 4ms column of figure 4.8 in EHCI
specification.
- Depending on the polling interval, we need to add the above calculated
bandwidth to one or more frame bandwidth lists, and also to one or more
micro frame bandwidth lists for that particular frame bandwidth list.
Before adding, we need to double check the availability of bandwidth in
those respective lists. If needed bandwidth is not available, then,
return an error. Otherwise add this bandwidth to all the required frame
and micro frame lists.
Ex: Assume given endpoint's polling interval is 32us and static node value
is 3. In this case, we need to add required bandwidth to 0,4,8,12,16,
20,24,28 frame bandwidth lists and micro bandwidth information is
saved using ehci_start_split_masks matrix. For this example, we need
to use any one of the 15 entries to save micro frame bandwidth.
High speed split transactions (for full and low speed devices only):
For a given full/low speed interrupt or isochronous endpoint, we need both
high speed and TT bandwidths. The TT bandwidth allocation is same as full
speed bus bandwidth allocation. Please refer to the "full speed bus"
bandwidth allocation section for more details.
The EHCI driver will go through the following steps to allocate high speed
bandwidth needed for this full/low speed endpoint.
- Calculate the bandwidth required for a given endpoint using the formula
and overhead calculations mentioned in previous section. In this case,
we need to calculate bandwidth needed both for Start and Complete start
transactions separately.
- Compare the bandwidth available in the least allocated frame list out of
32 frame lists against the bandwidth required by this endpoint. If this
exceeds the limit, then, return an error.
- Find out the static node to which the given endpoint needs to be linked
so that it will be polled as per the required polling interval. This
value varies based on polling interval and current bandwidth load on
this schedule.
Ex: If a polling interval is 4ms, then the endpoint will be linked to
one of the four static nodes (range 3-6) in the 4ms column of figure
4.8 in EHCI specification.
- Depending on the polling interval, we need to add the above calculated
Start and Complete split transactions bandwidth to one or more frame
bandwidth lists and also to one or more micro frame bandwidth lists for
that particular frame bandwidth list. In this case, the Start split
transaction needs bandwidth in one micro frame, where as the Complete
split transaction needs bandwidth in next three subsequent micro frames
of that particular frame or next frame. Before adding, we need to double
check the availability of bandwidth in those respective lists. If needed
bandwidth is not available, then, return an error. Otherwise add this
bandwidth to all the required lists.
Ex: Assume give polling interval is 4ms and static node value is 3. In
this case, we need to add required Start and Complete split
bandwidth to the 0,4,8,12,16,20,24,28 frame bandwidth lists. The
micro frame bandwidth lists is stored using ehci_start_split_mask &
ehci_complete_split_mask matrices. In this case, we need to use any
of the first 8 entries to save micro frame bandwidth.
Assume we found that the following micro frame bandwidth lists of
0,4,8,12,16,20,24,28 frame lists can be used for this endpoint.
It means, we need to initiate "start split transaction" in first
micro frame of 0,4,8,12,16,20,24,28 frames.
Start split mask = 0x01, /* 00000001 */
For this "start split mask", the "complete split mask" should be
Complete split mask = 0x0e, /* 00001110 */
It means try "complete split transactions" in second, third or
fourth micro frames of 0,4,8,12,16,20,24,28 frames.
- USB2.0, OHCI and EHCI Specifications
- USB bandwidth analysis from Intel