Electrical computers and digital data processing systems: input/ – Intrasystem connection – Bus interface architecture
Reexamination Certificate
2000-07-20
2004-03-16
Ray, Gopal C. (Department: 2181)
Electrical computers and digital data processing systems: input/
Intrasystem connection
Bus interface architecture
C710S063000, C710S300000
Reexamination Certificate
active
06708247
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates generally to computer systems equipped with a universal serial bus (or “USB”) for coupling peripheral devices thereto and, more particularly, to a technique which extends the distance at which the USB may operate.
2. Description of the Related Art
The Universal Serial Bus (USB) provides a method of coupling peripheral devices to a computer system. USB was developed by Intel Corporation as a general purpose port, with the intention of eliminating jumpers, IRQ settings, DMA channels, and I/O addresses. USB is a serial cable bus that supports data exchange between a host computer and a wide range of simultaneously accessible devices. The attached devices share USB bandwidth through a token scheduled protocol. The bus allows peripherals to be attached, configured, used, and detached while the host is in operation. The USB allows many (e.g., up to 127) devices to be daisy-chained with a single standard connector. USB supports devices that transfer data from 1.5 Mbps to 12 Mbps, and is expected to support transfer rates up to 480 Mbps under the USB 2.0 Protocol Specification. By continually polling the bus for devices, users may “hot-plug” peripherals into the system and use them without rebooting.
The USB technology may greatly simplify the complex cabling that typically spills out from the back of personal computers. USB peripherals may include keyboard, mouse, monitor, phone/answering machine, printer, scanner, fax/modem, ISDN, tablet, game controller, light pen, digital audio, and any other USB compliant device. The USB protocol assumes a short bi-directional connection between the local and remote ends of the USB network. The consequently short latencies for packet transmission allow the USB to be transaction oriented (e.g. token, data, and handshake are all completed before the next transaction begins) with very little performance loss.
The USB cable is a four wire cable, and the maximum cable length is about 5 meters. There are typically two connector types, and no cross-over cables and adapters are needed. The maximum USB cable length of about 5 meters results from the fact that the a USB Controller considers any transmission return time greater than a characteristic threshold value to be in error. USB cable lengths greater than about 5 meters may generate longer return times than the specified threshold value, and thus 5 meters is the maximum USB cable length. This 5 meter constraint may severely restrict the manner in which USB is used, especially given the fact that peripherals may be chained together sequentially. For example, in some situations it may be desirable to operate a USB and associated USB peripherals at a remote location from the associated host computer.
FIG.
1
: A Host Computer With USB Peripherals
FIG. 1
illustrates a USB system. As
FIG. 1
shows, a host computer system
108
may be coupled to various USB compliant peripherals, such as a keyboard
110
A, a mouse
110
B, and a monitor
110
C through a Universal Serial Bus (USB)
220
.
FIG.
2
: A Block Diagram Of A Host Computer With USB Peripherals
FIG. 2
is a block diagram of a host computer coupled to a variety of peripheral devices through a USB. As
FIG. 2
shows, the host computer system
108
may be coupled to USB compliant peripherals, including keyboard
110
A, mouse
110
B, and monitor
110
C through Universal Serial Bus (USB)
220
. Host computer
108
may include a USB Controller
230
for coupling to USB communication medium
220
. Host computer
108
may be operable to send and receive data to and from the USB peripherals shown through USB Controller
230
. Host computer
108
may include USB driver software
240
which interfaces to the USB Controller
230
and facilitates communication with the USB peripheral devices. As mentioned above, there is a requirement that the total USB cable length not exceed 5 meters.
FIG.
3
A: USB System Software Architecture
FIG. 3A
is a block diagram of the software architecture of a USB system. As
FIG. 3A
shows, the top layer of the software architecture is application software
302
. The application software
302
may be any software program which may be operable to provide an interface for control of or communication with a USB peripheral device. A USB driver program
240
may be below the application software
302
. The next software layer may be OHCI driver software
306
, which interfaces with the relevant hardware; i.e., the USB Controller hardware
230
. The USB Controller hardware
230
communicates through USB bus
102
to various USB peripherals
110
.
FIG.
3
B: USB System Software/Hardware Architecture
As
FIG. 3B
shows, system software
310
may include software modules that effect USB operation including client driver software
311
(which may be used by application software
302
), USB driver
240
, and a Universal Host Controller Driver (HCD)
306
. As
FIG. 3B
also indicates, a hardware implementation of the system is shown in hardware
230
, including Universal Host Controller (HC)
230
and USB device
110
, which may be coupled by USB
102
. The timing issues which result in the cable length problem exist in the host controller
230
, which relies on timely acknowledgements from USB devices
110
as described in the USB specification. The host controller
312
is specified in the USB standard as having a temporal window of valid reception after each transmission between any two USB devices (controller, hubs, user devices, etc.). This period of time is 70 nanoseconds, 30 nanoseconds of which may be committed to electronic processing time in the USB Controller hardware and the other 40 nanoseconds represents the maximum time-of-flight of the data through the connecting cable. This 40 nanosecond time-of-flight issue influences the cable length limit. This timing issue is endemic to the USB process and cannot be altered. Such timing issues are described in detail below with reference to FIG.
5
.
FIG.
4
: USB Data Delivery Packets
The USB is a polled bus, which means the host controller initiates all data transfers. Most bus transactions involve the transmission of up to three packets.
FIG. 4
is a block diagram of a typical bus transaction. Each transaction begins when the host controller, on a scheduled basis, sends a USB packet
402
describing the type and direction of transaction
410
, the USB device address
412
, and endpoint number
414
. This packet may be referred to as the “token packet.” The USB device that is addressed selects itself by decoding the appropriate address fields.
In a given transaction, data may be transferred either from the host to a device or from a device to the host. The direction of data transfer may be specified in the token packet
402
. As
FIG. 4
shows, the source of the transaction then sends a data packet
404
containing the data to be transferred
416
or indicates it has no data to transfer. The destination, in general, responds with a handshake packet
408
indicating whether the transfer was successful
418
.
Some bus transactions between host controllers and hubs involve the transmission of four packets. These types of transactions may be used to manage the data transfers between the host and full-/low- speed devices. The USB data transfer model between a source or destination on the host and an endpoint on a device may be referred to as a pipe. There are generally two types of pipes: stream and message. Stream data has no USB-defined structure, while message data does. Additionally, pipes have associations of data bandwidth, transfer service type, and endpoint characteristics like directionality and buffer sizes. Most pipes come into existence when a USB device is configured. One message pipe, the Default Control Pipe, always exists once a device is powered, in order to provide access to the device's configuration, status, and control information. The transaction schedule allows flow control for some stream pipes. At the hardware level, this prevents buffers from underrun or overrun situations by
Barret Dan
Barron Mike
Heller Andrew
ClearCube Technology, Inc.
Hood Jeffrey C.
Meyertons Hood Kivlin Kowert & Goetzel P.C.
Ray Gopal C.
LandOfFree
Extending universal serial bus to allow communication with... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Extending universal serial bus to allow communication with..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Extending universal serial bus to allow communication with... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3198961