System and method for USB controllers
Summary by NHIP
USB Controller with Dual Buffers
The method transfers information between a host system and a USB device using a controller with shared logic channels and dataports. It partitions local memory into two buffers programmed by the host to hold specific packet counts, writing to the first buffer until full before transferring data while simultaneously writing to the second buffer.
Claim Score by NHIP
Abstract
A USB controller is provided with multiple logic channels that share same physical address and data bus at an interface between the host system and the USB Host Controller; and dataports used by the host system to read and/or write data to the USB Host Controller. Also provided is a data packet format for transferring data, which comprises of an Endpoint Transfer Descriptor (“ETD”) that includes an EndPoint Descriptor and a Transfer Descriptor, wherein the host system programs the parameters of a communication channel for a particular Endpoint. Also included is a technique for partitioning a memory storage device into a first memory buffer and a second memory buffer; wherein the size of the first and second memory buffer may be programmed by the host system and the first and/or second memory buffer may contain more than one USB packet.

Term
Term ended
Expired 31 August 2022, 4.1 years ago.
- Priority
- Filed
- Granted
- Expired
- Today
9 claims: 3 independent, 6 dependent
- 1A method for transferring information between a host system and a Universal Bus System (USB) device via a USB Host Controller, comprising:creating an endpoint and transfer descriptor (“ETD”) data structure, wherein an endpoint descriptor and a transfer descriptor are placed in an ETD table located in an ETD memory in a local memory accessible to the USB Host Controller, and a host system processing unit sets up the ETD table and downloads ETDs from a host system memory to the local memory;assigning a buffer memory in the local memory for each ETD;partitioning the buffer memory into a first memory buffer and a second memory buffer, wherein the first memory buffer size and the second memory buffer size is programmed by the host system processing unit to hold a certain number of packets, wherein the number of packets depend on a size and type of a transaction descriptor;writing data packets in the first memory buffer until the first memory buffer is full;transferring data packets from the first memory buffer after the first memory buffer is full;writing data packets in the second memory buffer, while data packets are being read from the first memory buffer;wherein during a direct memory access (DMA) mode, the host system processing unit enables an ETD and the USB Host Controller maintains a data byte counter whose count indicates a byte count and a packet count for packets that have been written to local memory and a DMA control logic in the Host Controller by setting a bit indicates when the first memory buffer and the second memory buffer are filled.
- 8A system for transferring information between a host system and a Universal Serial Bus (“USB”) device via a USB Host Controller, comprising:a host central processing unit (“CPU”) for setting up an endpoint and transfer descriptor (“ETD”) data structure in an ETD table, wherein the CPU sets up the ETD table and downloads ETDs from a host system memory to a local memory;wherein each ETD is assigned a memory buffer by the CPU such that the memory buffer can hold certain number of packets and the memory buffer space is partitioned into a first memory buffer and a second memory buffer, wherein the size of the first memory buffer and the second memory buffer is programmed by the CPU depending on a size and type of a transaction descriptor, and data packets are written in the first memory buffer until the first memory buffer is full, and data packets are written in the second memory buffer, while data packets are being read from the first memory buffer after the first memory buffer is full;and in a programmable input/output (“PIO”) mode, the CPU keeps track of the data written in the memory buffer and after the first memory buffer and/or the second memory buffer are full, the CPU allows the USB Host Controller to switch between the first memory buffer and the second memory buffer to read and write data packets;logic for maintaining a first pointer based on which an address from where data is to be read can be determined, and a second pointer based on which an address where data is to be written can be determined;and logic that updates the first and second pointer such that data is read/written in a specified sequence.
- 9Broadest claimClaim Score 27, narrow(NHIP)An apparatus for transferring information between a host system and a Universal Serial Bus (“USB”) device via a USB Host Controller, comprising:a host central processing unit (“CPU”) for setting up an endpoint and transfer descriptor (“ETD”) data structure in an ETD table, wherein the CPU sets up the ETD table and downloads ETDs from a host system memory to a local memory;wherein each ETD is assigned a memory buffer by the CPU such that the memory buffer can hold certain number of packets, and the memory buffer is partitioned into a first memory buffer and a second memory buffer, wherein the size of the first memory buffer and the second memory buffer is programmed by the CPU depending on a size and type of a transaction descriptor, and data packets are written in the first memory buffer until the first memory buffer is full;and data packets are written in the second memory buffer, while data packets are being read from the first memory buffer after the first memory buffer is full: and in a programmable input/output (“PIO”) mode, the CPU keeps track of the data written in the memory buffer and after the first memory buffer and/or the second memory buffer are full, the CPU allows the USB Host Controller to switch between the first memory buffer and the second memory buffer to read and write data packets;logic for maintaining a first pointer based on which an address from where data is to be read can be determined, and a second pointer based on which an address where data is to be written can be determined;and logic that updates the first and second pointer such that data is read/written in a specified sequence.
Independent claims3
397 paragraphs in 6 sections, as filed
CROSS REFERENCE TO RELATED APPLICATIONS
This application is related to the provisional U.S. patent application entitled, “METHOD FOR A MICROPROCESSOR TO COMMUNICATE WITH A PERIPHERAL CONTROLLER AND TRANSFER-LEVEL USB HOST CONTROLLER”, Ser. No. 60/277,093, filing date, Mar. 19, 2001, the disclosure of which is incorporated herein by reference, in its entirety.
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to peripheral device controllers, and more particularly, to controllers used in a universal serial bus (“USB”) system.
2. Background
The USB system provides a unitary interface that allows various devices to be connected to a computer system (also referred to as a host system). USB enables a wide variety of peripherals to be connected in a tree-like fashion through a physical connector at the host side. USB systems comply with the USB specification, version 2.0, published Apr. 27, 2000, which is incorporated herein by reference in its entirety.
USB systems are implemented by a register level interface standard referred to as the “Open Host Controller Interface (“OHCI”), developed by a consortium of computer industry manufacturers. The OHCI allows multiple Host Controllers to be used with a common software driver. The OHCI specification, version 1.0a, entitled “Open HCI Host Controller Interface Specification for USB, published by Compaq, Microsoft, and National Semiconductor, Jan. 22, 1997, is incorporated herein by reference in its entirety.
Yet another standard that is used by USB systems is the Universal Host Controller Interface (“UHCI”) that implements a USB Host Controller. The UHCI provides hardware and software interface between a Host Controller software driver and the Host Controller. UHCI standard published by Intel Corporation, Revision 1.1, March 1996, is incorporated herein by reference in its entirety.
USB enables bi-directional isochronous and asynchronous data transfer making it possible to couple plural peripheral devices to a computing device via a single Host Controller and a USB hub. A USB hub is an intelligent wiring connector, coupled to a computing device or another hub, and which allows, attachment for peripheral devices.
USB systems allow automatic identification and configuration of external and/or internal peripheral devices. Typically, a USB host controller maintains a data structure that identifies every connected peripheral device and includes entries for communicating with the individual devices. The data structure manages four types of data transfers, between a host controller and peripheral units, namely, interrupt, isochronous, control and bulk transfers.
Interrupt transfers include small data transfers used to communicate information from a USB device to a client software at the host system. Isochronous transfers include periodic data transfers at a constant rate. Data transfer is correlated in time between a sender and receiver.
Control transfers are non-periodic data transfers used to communicate configuration/command/status information between client software and a USB device. Bulk transfers are non-periodic data transfers used to transfer large amounts of information between client software and a USB device.
USB systems use a microcontroller (also referred to as a host controller or USB controller), or an embedded microcontroller, uniquely suited on to a monolithic semiconductor substrate (chip) to interface between host systems and USB devices. The USB controller includes various features within a single chip, complying with the foregoing standards.
USB systems use Endpoint Descriptors (ED) and Transfer Descriptors (TD) for communication. Typically, a Host Controller Driver assigns an ED to each peripheral device (also referred to herein as an “endpoint”) in the USB system. The ED includes information necessary for the host controller to communicate with the endpoint. The fields include maximum packet size, endpoint address, and speed of the endpoint and direction of data flow. A queue of TDs is linked to the ED for a specific endpoint. The TD includes information necessary to describe the data packets to be transferred. Each TD contains information that describes one or more data packets.
Section 4 of the OHCI specification describes the use of endpoint and transfer descriptors. Typically, a ED is a 16-byte, memory resident structure. A host controller traverses lists of EDs and if there are TDs linked to an ED, the host controller performs the indicated transfer.
Current USB controllers have various drawbacks. For example for bulk transfers, a host system builds a bulk transfer list structure in system memory which includes EDs and TDs. Under OHCI's bulk list structure, a host controller must queue and en-queue EDs and TDs depending upon whether they are active or inactive.
If Host Controller has to send bulk data, host controller must access the ED in system memory, compute the ED, access the TD, compute the TD and then transfer data according to the command. This requires elaborate bus mastering which is complex and slows the host system.
For isochronous transfer, conventional OHCI controllers require frequent access to the system bus. Isochronous transfer monopolizes system bus resources and hence overall system performance is affected.
Another drawback of conventional USB systems is that memory buffers are either under-run or over-run, and hence used inefficiently.
Therefore, there is a need for a host controller that allows efficient data transfer without monopolizing system bus resources.
There is also a need for an ED and TD format that does not require elaborate and complex bus mastering.
Also, there is a need for a buffering mechanism that efficiently utilizes the buffer resources.
SUMMARY OF THE INVENTION
In one aspect, the present invention provides a method for transferring information between a host system and a USB Host Controller in a USB system. The method includes partitioning a memory storage device into a first memory buffer and a second memory buffer; writing information in the second memory buffer, while information is read from the first memory buffer; wherein the size of the first and second memory buffer may be programmed by the host system and the first and/or second memory buffer may contain more than one USB packet. The first memory buffer and the second memory buffer may be equal or unequal in size.
The method includes a first pointer based on which an address from where data is read can be determined; and a second pointer based on which an address to where data is written can be determined. The USB Host Controller may read the first memory buffer and the second memory buffer may be written by the host system. Also, the first memory buffer may be read by the host system and the USB Host Controller may write the second memory buffer.
In another aspect, the present invention provides a system for transferring information between a host system and a USB Host Controller. The system includes a memory storage space that can be partitioned into a first memory buffer and a second memory buffer, wherein the size of the first and second memory buffer may be programmed by the host system and the and the first and/or second memory buffer may contain more than one USB packet; logic for maintaining a first pointer based on which the address of information to be read can be determined, and for a second pointer based on which the address of where data is to be written can be determined; and logic that updates the first and second pointer such that data is read/written in a specified sequence.
In yet another aspect, the present invention provides an apparatus for transferring information between a host system and a USB Host Controller. The apparatus includes a memory storage space that can be partitioned into a first memory buffer and a second memory buffer, wherein the size of the first and second memory buffer may be programmed by the host system and the and the first and/or second memory buffer may contain more than one USB packet; logic for maintaining a first pointer based on which the address of information to be read can be determined, and for a second pointer based on which the address of where data is to be written can be determined; and logic that updates the first and second pointer such that data is read/written in a specified sequence.
In yet another aspect the invention provides a USB Host Controller comprising of interface to a host system with control logic used for transferring data from the host system to the USB Host Controller is provided. The USB Host Controller includes memory storage space for storing at least one ETD containing information regarding a USB transfer; a link for determining a location in the memory storage space associated with the transfer specified by the ETD; and logic that executes ETDs in a specified priority order.
In another aspect, the USB Host Controller includes plural logic channels that share the same physical address and data bus at an interface between the host system and the USB Host Controller; and dataports used by the host system to address the logic channels to read and/or write data from/to the USB Host Controller, wherein the logic channels may be interleaved in plural ways.
In yet another aspect, the present invention provides a data packet format for USB systems for transferring data between a host system and a USB Host Controller coupled to plural devices. The format comprises of an ETD that includes an EndPoint Descriptor and a Transfer Descriptor, wherein the host system programs the parameters of a communication channel for a particular endpoint. The ETD includes plural transfer descriptors that may be a part of a single transaction. The host system sets up ETDs for plural endpoints and the USB Host Controller executes the ETDs.
In yet another aspect the present invention provides a system for transferring information between the host system and USB Host Controller. The system includes an ETD table that is setup by the host at a memory storage space in the USB Host Controller. The USB Host Controller enables the ETD using at least one operational register and includes a scheduler that scans the ETD table for executing ETDs.
In yet another aspect, the present invention provides a method for transferring data between a host system and a USB Host Controller. The method includes setting up an ETD table, wherein the ETD table is set up by the host system, enabled by at least one operational register and then loaded into a memory storage device at the USB Host Controller; scanning all ETDs at a start of frame; and executing the ETDs in a priority order.
In yet another aspect of the present invention, each ETD may be individually programmed for DMA or PIO mode. When an ETD is removed, the associated DMA channel is also dissolved. When the ETD is put on a DoneQueue, the corresponding working mode bit is also cleared. This means that the DMA channel association exists at the ETD (transfer) level. The freed DMA channel can be used for the next ETD of the same endpoint, or for another ETD. Hence, DMA channels are efficiently used to transfer data.
In yet another aspect of the present invention, the foregoing buffering techniques has advantages because it allows Host Controller to transfer data efficiently. For an endpoint working in the PIO mode, very few interrupts are required. For isochronous endpoint, packet size varies, and the adaptive nature of the present invention allows varying the size of number of packet per buffer and the size of the foregoing mega-buffers.
In yet another aspect of the present invention, local memory buffers may be programmed based on packet size and hence overrun and underrun situation can be handled efficiently.
In yet another aspect of the present invention, The ED format is the same for all endpoints, while the TDs may be different and packets are programmed accordingly. This reduces overhead between the host and Host Controller.
In yet another aspect of the present invention, since ETDs are written into local memory at the Host controller level, no special bus mastering is required. Also, only active ETDs are placed in local memory and hence they can be executed efficiently.
In yet another aspect of the present invention, since ETDs are transferred from local memory, system bus resources are used for other functions.
In yet another aspect of the present invention, the system is scalable based on local memory size and hence less taxing on address buses.
This brief summary has been provided so that the nature of the invention may be understood quickly. A more complete understanding of the invention can be obtained by reference to the following detailed description of the preferred embodiments thereof, in connection with the attached drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
<figref idref="DRAWINGS">FIG. 1</figref> shows a block diagram of a host system, according to one aspect of the present invention.
<figref idref="DRAWINGS">FIG. 2A</figref> shows a block diagram of various components of <figref idref="DRAWINGS">FIG. 1</figref>, according to one aspect of the present invention.
<figref idref="DRAWINGS">FIG. 2B</figref> shows a block diagram of an OHCI driver, according to one aspect of the present invention.
<figref idref="DRAWINGS">FIG. 2C</figref> shows a block diagram of an interface driver, according to one aspect of the present invention.
<figref idref="DRAWINGS">FIG. 2D</figref> is a timing chart showing execution of endpoint and transfer descriptors, according to one aspect of the present invention.
<figref idref="DRAWINGS">FIG. 2E</figref> is a block diagram showing execution of endpoint and transfer descriptors, according to one aspect of the present invention.
<figref idref="DRAWINGS">FIG. 3</figref> shows a block diagram of a USB Host Controller, according to one aspect of the present invention.
<figref idref="DRAWINGS">FIG. 4A</figref> shows the format of an Endpoint descriptor, according to one aspect of the present invention.
<figref idref="DRAWINGS">FIG. 4B</figref> shows a table describing the various fields shown in <figref idref="DRAWINGS">FIG. 4A</figref>, according to one aspect of the present invention.
<figref idref="DRAWINGS">FIG. 4C</figref> shows a data structure, according to one aspect of the present invention.
<figref idref="DRAWINGS">FIG. 4D</figref> shows bandwidth allocation according to one aspect of the present invention.
<figref idref="DRAWINGS">FIG. 4E</figref> shows an example of a Control/Bulk Transfer descriptor, according to one aspect of the present invention.
<figref idref="DRAWINGS">FIG. 4F</figref> shows an example of an interrupt Transfer descriptor, according to one aspect of the present invention.
<figref idref="DRAWINGS">FIG. 4G</figref> describes the various fields illustrated in <figref idref="DRAWINGS">FIGS. 4E and 4F</figref>, according to one aspect of the present invention.
<figref idref="DRAWINGS">FIG. 4H</figref> shows an example of an isochronous Transfer descriptor, according to one aspect of the present invention.
<figref idref="DRAWINGS">FIG. 4I</figref> describes the various fields illustrated in <figref idref="DRAWINGS">FIG. 4H</figref>, according to one aspect of the present invention.
<figref idref="DRAWINGS">FIG. 4J</figref> shows an example of buffer length calculation, according to one aspect of the present invention.
<figref idref="DRAWINGS">FIG. 4K</figref> shows an example of an overrun buffer values.
<figref idref="DRAWINGS">FIG. 4L</figref> shows an example of a packet status, according to one aspect of the present invention.
<figref idref="DRAWINGS">FIG. 4M</figref> describes the various <figref idref="DRAWINGS">FIG. 4L</figref> fields, according to one aspect of the present invention.
<figref idref="DRAWINGS">FIG. 4N</figref> shows examples of completion codes, according to one aspect of the present invention.
<figref idref="DRAWINGS">FIG. 4O</figref> shows an example of an ETD table, according to one aspect of the present invention.
<figref idref="DRAWINGS">FIG. 5A</figref> shows various USB states of a USB Host Controller, according to one aspect of the present invention.
<figref idref="DRAWINGS">FIG. 5B</figref> shows a start of frame timing chart, according to one aspect of the present invention.
<figref idref="DRAWINGS">FIG. 5C</figref> is a block diagram showing control bulk service ratio, according to one aspect of the present invention.
<figref idref="DRAWINGS">FIG. 5D</figref> is a flow diagram showing executable process steps for setting up ETD priorities, according to one aspect of the present invention.
<figref idref="DRAWINGS">FIG. 5E</figref> is a flow diagram showing executable steps for processing ETDs, according to one aspect of the present.
<figref idref="DRAWINGS">FIG. 6A</figref> is a diagram of a mega-buffer, according to one aspect of the present invention.
<figref idref="DRAWINGS">FIG. 6B</figref> is a flow diagram of executable steps showing the use of mega-buffers when data is sent out to an endpoint, according to one aspect of the present invention.
<figref idref="DRAWINGS">FIG. 7</figref> is a flow diagram of executable steps showing the use of mega-buffers when data is sent from an endpoint, according to one aspect of the present invention.
<figref idref="DRAWINGS">FIG. 8A</figref> shows a list of various operational registers used in the various adaptive aspects of the present invention.
<figref idref="DRAWINGS">FIGS. 8B–8Z</figref> show plural fields used by the registers of <figref idref="DRAWINGS">FIG. 8A</figref> and the tables showing associated field descriptions, according to one aspect of the present invention.
<figref idref="DRAWINGS">FIGS. 9A–9C</figref> show plural fields used by the registers of <figref idref="DRAWINGS">FIG. 8A</figref> and the tables showing the associated field descriptions, according to one aspect of the present invention.
Features appearing in multiple figures with the same reference numeral are the same unless otherwise indicated.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
Definitions: The following definitions are used in various aspects of the present invention and with respect to the USB specification (but not exclusively):
“ACK”: Handshake packet indicating positive acknowledgement.
“Active device”: A device that is powered and is not in the Suspend State.
“Babble”: Unexpected bus activity that persists beyond a specific point in a frame.
“Bit”: A unit of information used by digital computers and represents the smallest piece of addressable memory. Typically represented by a value of one (1) or zero (o).
“Bit Stuffing”: Insertion of a “0” bit into a data stream to cause an electrical transition on the data wires.
“CRC”: Cyclic redundancy check performed on data to see if an error occurred during transmission.
“Device”: A logical or physical entity that performs a function.
“Device Address”: A seven bit value under USB that represents the unique address of a device.
“DMA”: Direct Memory Access
“DWORD”: Double word, i.e., a data element that is two words in size.
“Endpoint”: A uniquely addressable portion of a USB device that is the source or sink of information in a communication flow between a host and the device.
“Endpoint Address”: Combination of an endpoint number and endpoint direction on a USB device.
“Endpoint Descriptor” (“ED”): Data structure with information necessary for communication between a Host Controller and an endpoint.
“Endpoint Transfer descriptor” (“ETD”): Combined Data structure with ED and TD.
“Endpoint Direction”: The direction of data transfer, i.e., either “IN” to the host, OR “OUT” from the host.
“EOF”: End of Frame
“EOP”: End of packet
“Host Controller” (“HC”): Host USB interface.
“Host Controller Driver” (“HCD”) USB software layer that abstracts Host Controller hardware.
“Hub”: A USB device that provides additional connection to USB.
“LSb”: Least significant bit.
“LSB”: Least significant byte.
“MSb”: Most significant bit.
“MSB”: Most significant byte.
“NAK”: Handshake packet indicating a negative acknowledgement.
“Packet”: A bundle of data organized in-groups for transmission that contains information regarding control, data to be transferred, and error detection and correction bits.
“PIO”: Programmable Input/Output
“PID”: Field in a USB packet that indicates the type of packet.
“PLL”: Phase locked loop.
“Polling”: Asking multiple devices if they have any data to transmit.
“Queue”: A linked list of TDs
“Root Hub”: A USB hub directly coupled to the Host Controller.
“RPP”: Relative Polling Position
“SOF”: Start of Frame that allows endpoints to identify the start of a frame and synchronize internal endpoint checks to the host.
“Token Packet”: A type of packet that identifies the type of transaction that is to be performed.
“Transfer”: The delivery of service to an endpoint that includes a token packet, data packet and optional handshake packet.
“Transfer Descriptor” (“TD”): Data structure linked to an endpoint descriptor with transfer information.
“USB”: Universal Serial Bus
“Word”: A data element that is two bytes in size.
<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram of a USB system <b>100</b> with host system <b>100</b>A connected to plural USB enabled peripheral devices via USB bus <b>111</b>. Host system <b>100</b>A may be a personal computer and, although not described in detail, includes a central processing unit (CPU) <b>101</b>, that may be a Pentium class microprocessor, manufactured by Intel Corp. microprocessor or any other processor, and further includes volatile and non-volatile storage and input/output devices etc. Host system <b>100</b>A is provided with a USB controller (Host Controller) <b>103</b> for controlling data transfers through bus <b>111</b>.
All or any part of the foregoing units can be implemented as a computer program including instructions, which are stored on a digital data storage medium such as a magnetic disk or CD-ROM for distribution to end-users in accordance with the present invention. Further, any part of these units can be wholly or partially implemented in volatile memory, non-volatile memory or any combination thereof, prior and during operation.
Plural peripheral units, e.g., printer <b>105</b>, modem <b>106</b>, mouse <b>107</b>, keyboard <b>108</b> and monitor <b>109</b> may be coupled to host system <b>100</b>A via USB Root Hub <b>104</b>.
USB controller <b>103</b> communicates with the peripheral units via USB bus <b>111</b> using four types of data transfers described above, namely interrupt, control, isochronous, and bulk transfers that are described above. USB bus <b>111</b> includes hub <b>110</b> coupled with line <b>112</b>.
Host system <b>100</b>A includes direct memory access (“DMA”) controller <b>113</b> that allows access to DMA channels, as discussed below.
DMA controller units are used to perform transfers between memory locations, or between memory locations and an input/output port. DMA controller <b>113</b> functions without involving the microprocessor (CPU <b>101</b>), by initializing control registers in the DMA unit with transfer control information. The transfer control information generally includes source address (the address of the beginning of a block of data to be transferred), the destination address, and the size of the data block. DMA controller <b>113</b> provides address and bus control signals to and from a storage device for a read and/or writes cycle.
Specific channels are implemented in a DMA controller <b>113</b> to allow storage devices to transfer data directly to and from memory storage devices. A channel can be activated by a DMA request signal (DREQ) from a storage device or Host Controller <b>103</b> (or <b>301</b>). DMA controller <b>113</b> receives the DREQ, provides a DMA acknowledged signal (DACK), and transfers the data over the channel to or from the storage device.
<figref idref="DRAWINGS">FIG. 2A</figref> shows another aspect of USB system <b>100</b> that uses the various components of <figref idref="DRAWINGS">FIG. 1</figref>. <figref idref="DRAWINGS">FIG. 2A</figref> shows Host Controller Driver <b>202</b> and Host Controller <b>103</b> that operate in tandem to transfer data between client software <b>201</b> and a USB device <b>203</b> (which may be any of the USB devices discussed above and shown in <figref idref="DRAWINGS">FIG. 1</figref>). The present system is adaptive, for example, if OHCI/UHCI compliance is required, then Host Controller Driver <b>202</b> includes an OHCI/UHCI driver <b>204</b> and an interface driver <b>205</b>. If OHCI/UHCI compliance is not needed, a stand alone Host Controller Driver <b>202</b> may be used.
If Host Controller Driver <b>202</b> includes OHCI (or UHCI) driver with interface driver <b>205</b>, then there is no direct communication between OHCI driver <b>204</b> and Host Controller <b>103</b>. Interface driver <b>205</b> mediates all communications between the two.
OHCI (or UHCI) driver <b>204</b> and interface driver <b>205</b> have plural communication channels. One such channel uses a set of standard OHCI/UHCI operational registers <b>207</b> as shown in <figref idref="DRAWINGS">FIG. 2B</figref>. The operational registers contain control, status and a list pointer registers. OHCI (or UHCI) driver <b>204</b> is the master of the first channel. Within the operational register set is a pointer to a location in system memory <b>102</b>, which is designated as Interface Driver Communications Area (“IDCA”) <b>208</b>.
IDCA <b>208</b> is the second communication channel, where Interface Driver <b>205</b> is the master of the second channel. IDCA <b>208</b> includes head pointers to interrupt ED lists, the head pointer to a “done queue”, and status information associated with start-of-frame (“SOF”) processing.
Communication between Interface Driver <b>204</b> and Host Controller <b>103</b> (<figref idref="DRAWINGS">FIG. 2C</figref>): Plural communication channels are available for communication between interface driver <b>205</b> and Host Controller <b>103</b>. One of the channels uses a set of operational registers located at Host Controller <b>103</b> (or <b>301</b>, as shown in <figref idref="DRAWINGS">FIG. 3</figref>). The operational registers <b>207</b> contain control, status and pointers. The second communication channel is an ETD communication area <b>209</b>, consisting of a list of ETDs constructed by interface driver <b>205</b> based on list structures located in ETD memory <b>308</b>A, as described below.
OHCI enumerates each newly connected peripheral device; schedules appropriate service for each endpoint and put the schedule into memory <b>103</b>. Interface driver <b>205</b> evaluates the schedule, constructs ETDs, and writes them into ETD tables located at ETD memory <b>308</b>A for execution. Interface driver <b>205</b> is the master of the foregoing two channels. Each ETD contains sufficient information for Host Controller <b>103</b> (or <b>301</b>) to operate at the appropriate time.
<figref idref="DRAWINGS">FIGS. 2D and 2E</figref> show an example of servicing ETDs, according to one aspect of the present invention. Vertical axis represents the time. Each ETD is setup in local memory <b>308</b> before it is executed. A TD can support more than one packet. When one TD is retired, it is put in the “Donequeue” described below, and a time deferred or immediate interrupt is generated. CPU <b>101</b> reads out status information, and writes the next TD. The vertical distance between two TDs represents the number of executed frames.
<figref idref="DRAWINGS">FIG. 3</figref> is a top-level block diagram of the architecture of system <b>300</b> according to one aspect of the present invention. <figref idref="DRAWINGS">FIG. 3</figref> includes a top-level controller <b>304</b> with plural modules, <b>304</b>A through <b>304</b>F that have various functions. Module <b>304</b>B is a controller that controls Host Controller <b>301</b> (similar to Host controller <b>103</b>) and function controller <b>302</b>.
<figref idref="DRAWINGS">FIG. 3</figref> also shows a local memory module <b>308</b> with ETD memory <b>308</b>A, memory arbiter <b>308</b>B and data memory <b>308</b>C. ETD memory <b>308</b>A includes ETD table lists (<figref idref="DRAWINGS">FIG. 4O</figref>). Memory arbiter <b>308</b>B includes an arbitration module that arbitrates DMA access for any endpoint execution.
Also shown in system <b>300</b> is a microprocessor interface <b>307</b> that interfaces Host Controller <b>301</b> with CPU <b>101</b>. This includes a DMA slayer <b>307</b>A, memory arbiter <b>307</b>B and a programmable input/output (“PIO”) interface <b>307</b>C.
Host controller <b>301</b> has plural logical communication channel interface with CPU <b>101</b> through interface <b>307</b>, including one parallel I/O channel and “n’ number of DMA channels. Each logic channel has a data port, which is mapped to a memory mapped I/O. The memory mapped I/O are accessed by plural operational registers described below. The logic channels may be interleaved and the data ports may be implemented with a pipeline resulting in a higher throughput. This allows word for word and burst access consisting of one address phase and multiple data phase.
In one aspect of the present invention plural logic channels are used between CPU <b>101</b> and Host Controller <b>301</b>, including memory-mapped Input/Output channel for direct access, DMA channel 0 and DMA channel 1(not shown) through interface <b>307</b>. The three logic channels share the same address and data bus and may be interleaved. During the data phase, CPU <b>101</b> reads/writes from system memory to Host Controller <b>301</b> through a Dataport register (described below), and DMA channel 0 transfers data between system memory <b>102</b> and local memory <b>308</b> using DataPort0(1) register <b>851</b>, described below in
System <b>300</b> includes ETD handler <b>301</b>A in Host Controller <b>301</b>, which maintains an updated list of ETD transactions. Host registers <b>301</b>D maintain plural fields as discussed below. Schedule <b>301</b>C uses memory arbiter <b>307</b>B and <b>308</b>B, to schedule ETD executions. Host Controller <b>301</b> is coupled to root hub <b>309</b>A (similar to Root Hub <b>104</b>) to which plural devices may be coupled.
Data Structures
In one aspect of the present invention, a data structure is provided that allows efficient communication between host system <b>100</b>A and a USB device (e.g. device <b>203</b>). The data structure is referred to as Endpoint and Transfer Descriptor (“ETD”) that allows communication between Host Controller Driver <b>202</b> and Host Controller <b>103</b>. Host Controller Driver <b>202</b> assigns a ED to each endpoint (or a device) in system <b>100</b>. The ED includes information relating to maximum data packet size, endpoint address, endpoint speed, and direction of data flow. EDs together with Transfer descriptors are placed in an ETD table (<figref idref="DRAWINGS">FIG. 4O</figref>) located at ETD memory <b>308</b>A.
Host Controller Driver <b>202</b> manages operation of Host Controller <b>301</b> by communicating with various operational registers <b>301</b>D, described below, builds and downloads ETDs from system memory <b>102</b> into local memory <b>308</b> for execution.
As discussed in detail below, data transfer requires Host Controller Driver <b>202</b> to write appropriate data into memory <b>308</b> and then data is sent to an endpoint as addressed by the ED. When data is received from an endpoint, it is stored in memory <b>308</b> and then transferred into system memory <b>102</b> or any other storage device.
CPU <b>101</b> sets up ETD lists and enables the ETD. Communication between CPU <b>101</b> and Host Controller <b>301</b> takes place through an address bus, data bus, Start register and data port register. To start a new ETD <b>301</b>, CPU <b>101</b> writes the starting physical address in the StartAddress register <b>818</b> (<figref idref="DRAWINGS">FIG. 8L</figref>) and then the ETD is written into the DataPort register <b>851</b> (<figref idref="DRAWINGS">FIG. 9C</figref>) and then transferred to ETD memory <b>308</b>A. The size of the data packet that is sent to an endpoint is typically less than the smaller of “maximumPacketSize” and specified by the ETD.
In one aspect of the present invention, a ED may be a 4-byte structure. An example of a ED format is given in <figref idref="DRAWINGS">FIG. 4A</figref> and the plural fields are defined in <figref idref="DRAWINGS">FIG. 4B</figref>. It is noteworthy that the ED <b>404</b> of <figref idref="DRAWINGS">FIG. 4A</figref> includes a field that signifies the type of transfer, namely, interrupt, control, bulk or isochronous.
A TD is a local memory <b>308</b> structure used by Host Controller <b>301</b> to define data that is moved to and/or from an endpoint. Transfer Descriptors are linked to a ED for a specific endpoint. A TD contains data toggle information, local memory <b>308</b> location and completion codes. Each TD describes one or more packets. <figref idref="DRAWINGS">FIG. 4C</figref> shows a list structure of EDs and TDs as a part of the ETD structure <b>400</b>.
TDs may be designated for Isochronous, Interrupt or Control/bulk data transfer.
An isochronous TD handles isochronous transfers i.e. transaction is associated with a defined frame number, one packet per frame, and each packet may have a different length. An Interrupt TD is used at a pre-defined time interval, at a given relative polling position within that interval and if not acknowledged (NAKed), retried at the next interval.
A Bulk/Control TD uses a similar format. <figref idref="DRAWINGS">FIG. 4E</figref> shows an example of a Control/Bulk TD format. <figref idref="DRAWINGS">FIG. 4F</figref> shows an example of an Interrupt TD format.
<figref idref="DRAWINGS">FIG. 4G</figref> describes the various fields shown in <figref idref="DRAWINGS">FIGS. 4E and 4F</figref> for Bulk, Control and Interrupt TD.
Sequence Bits
The USB protocol uses data PID sequencing to ensure that data packets are received in the correct order. The sequencing requires that a data transmitter continue to send the same data packet with the same data PID (e.g., DATA0 or DATA1) until it has determined that the data packet has been successfully received and accepted. Reception and acceptance are indicated when the transmitter receives an ACK packet after sending a data packet. In order to ensure that data packets are not lost, Host Controller <b>301</b> and the endpoint have “data toggle synchronization”.
Data toggle synchronization is established at endpoint initialization with the nominal value for the first packet to/from an endpoint using DATA0 value. On each successive successful packet transmission/reception, the data toggle value changes.
Data toggle value is maintained within a Control/Bulk and Interrupt TD by alternating the least significant bit (“LSb”) of the “dataToggle” field. When the data toggle value must be carried between two TDs, the “toggleCarry” bit in the ED is used to propagate the correct value to the next TD.
When the most significant bit (“MSb”) of the dataToggle field is a certain value, e.g., 0, the value of the data toggle is obtained from the togglecarry bit in the ED and the LSb of the dataToggle field is ignored. When the MSb of the dataToggle field is a certain value, e.g., 1, then the LSb of the dataToggle field contains the value that is used for the data toggle.
For bulk and interrupt endpoints, most TDs are queued with a certain dataToggle value, e.g., 00b. This allows data toggle to be carried across multiple TDs with the ED containing the value to be used for the first data packet in each transfer. After the first data packet is successfully transferred, the MSb of dataToggle value is set to indicate that. For the remainder of the transfer, the dataToggle field determines the data toggle value and the LSb is set to indicate the next toggle value. When the TD is retired, the togglecarry bit in the ED is updated to indicate the data toggle value that will be used on the next packet for the endpoint.
For control endpoints, USB specification requires that a “Setup packet” use a data PID of DATA0, the first data packet uses a data PID of DATA1, and the Status packet uses a data PID of DATA1. Since this sequence does not rely on any previous data toggle history, the Setup, data, and status packets are queued with a certain MSb of the dataToggle field value, e.g., 1, and the LSb of each TD is set appropriately (e.g., Setup=0; Status=1; and first data, if any, =1). Although Host Controller <b>301</b> updates the togglecarry bit in the ED whenever a TD is retired, the TD determines the data toggle value.
The data toggle field of a TD is advanced after every successful data packet transaction with the endpoint, including the last. As long as an ACK packet is sent (IN) or received (OUT or Setup), the data toggle will advance, even if other error conditions are encountered. It is noteworthy that the invention is not limited to the foregoing “data toggle” values, other values may be used to implement the various adaptive features of the invention.
Transfer completion
To access data, CPU <b>101</b> first writes the starting address of local memory <b>308</b> into the StartAddress register <b>818</b>, and then data is transferred via data port register <b>851</b> to system memory <b>102</b>.
“CompletionCode” (<figref idref="DRAWINGS">FIG. 4N</figref>) field of a Control/Bulk and Interrupt TD is updated after every attempted transaction, whether successful or not. If the transaction is successful, then the CompletionCode field is set to “NOERROR”, otherwise, it is set according to the error type.
A data transfer is also complete when a data packet from an endpoint does not have a size less than the Maximum Packet Size bytes in length. In this case, “LastPacketSize” field is updated to reflect the number of bytes effectively received. Then, if the “bufferRounding” bit in the TD is set, then this condition is treated as normal completion and Host Controller <b>301</b> sets the CompletionCode field to “NOERROR” and puts the TD in a “Done Queue”. If the bufferRounding bit in the TD is not set, then this condition is treated as an error and the Host Controller <b>301</b> sets the CompletionCode field to D<smallcaps>ATA</smallcaps>U<smallcaps>NDERRUN </smallcaps>and the Halted bit of the ED is set as the TD is retired.
Transfer Errors for Control/Bulk/Interrupt TDs
Transfer errors occur during packet transmission over USB wires (bus <b>111</b>), and include “CRC errors”, “B<smallcaps>IT</smallcaps>S<smallcaps>TUFFING </smallcaps>errors”, “D<smallcaps>EVICE</smallcaps>N<smallcaps>OT</smallcaps>R<smallcaps>ESPONDING</smallcaps>” errors. Sequence errors occur when the number of data bytes received do not match the number of bytes expected from an endpoint. System errors occur when Host Controller <b>301</b> has a problem resulting with its environment that cannot otherwise be attributed to USB. The following describes how the three types of errors are handled, according to one aspect of the present invention:
Transmission Errors
For errors in this category, USB requires that a transaction be terminated after the transfer fails three times. Host Controller <b>301</b> supports this requirement with the ErrorCount field. Host Controller Driver <b>202</b> initializes this field to a certain value, e.g., 0, when a TD is queued. This field is updated after each transaction attempt. If there is no transmission error, the field is written to 0. If, however, there is a transmission error, the field is incremented. If the ErrorCount field reaches a certain value, e.g., 2 (10b), and another transmission error occurs (the third error in a row), the TD is removed to the “Done Queue” and the endpoint is halted.
Data toggle mismatches on input data are counted as transmission errors. The cause of a data toggle mismatch is either failure of the endpoint to receive an ACK packet or a device problem. Data received when the data toggle mismatches is discarded and never written to local memory <b>308</b>.
An error in the PID check field is counted as a transmission error and is reported with a CompletionCode of PIDC<smallcaps>HECK</smallcaps>F<smallcaps>AILURE. </smallcaps>
Sequence Errors
Sequence errors occur when data is transferred from an endpoint to Host Controller <b>301</b>. There are two types of sequence errors: data overrun and data underrun. When either of these error conditions are encountered, the CompletionCode field is set accordingly, the TD is removed, and the endpoint is halted.
A data overrun error occurs when the number of bytes received from an endpoint exceeds “Maximum Packet Size”. In the case of an overrun condition, Host Controller <b>301</b> writes to local memory <b>308</b> all the data received up to the point where the data overrun condition occurred and the TD is removed with overrun error.
System Error
Host Controller <b>301</b> receives data from an endpoint (device <b>203</b>) if there is sufficient buffer space within memory <b>308</b> to accept a data packet of Maximum Packet Size from the endpoint. Similarly, Host Controller <b>301</b> does not issue an “OUT” or “SETUP” token unless data is downloaded to memory <b>308</b> and a whole packet of data that is sent to the endpoint in the data phase.
Special Handling
Not Acknowledged (“NAK”):
During normal working mode, the “StopOnNak” bit is set to a certain value, e.g., 0. When an endpoint returns a NAK packet, all TD fields remain the same after the transaction, as they were when the transaction began. Host Controller <b>301</b> makes no changes. The StopOnNak bit is set to a certain value, e.g., 1, when an endpoint returns a NAK packet, and the ETD is removed from the ETD list.
Stall:
If an endpoint returns a STALL PID, Host Controller <b>301</b> removes the TD with the CompletionCode set to STALL and halts the endpoint. The ErrorCount, and dataToggle fields retain the values that they had at the start of the transaction.
Isochronous TD
An Isochronous TD is used exclusively for isochronous endpoints. <figref idref="DRAWINGS">FIG. 4H</figref> shows an example of an isochronous TD, according to one aspect of the present invention, while the various fields of <figref idref="DRAWINGS">FIG. 4H</figref> are described in <figref idref="DRAWINGS">FIG. 4I</figref>.
An Isochronous TD describes data packets that are sent to or received from an isochronous endpoint. The data packets in an Isochronous TD have a time component associated with them such that a data packet is transferred only in the specific frame to which it has been assigned. An Isochronous TD may contain buffers for consecutive frames of data (FrameCount+1) with the first (0th) data packet of an Isochronous TD sent in the frame for which the low bits (e.g. 16 bits) of HcFmNumber match the StartingFrame field of the Isochronous TD.
Host Controller <b>301</b> does an unsigned subtraction of StartingFrame from the 16 bits of HcFmNumber to arrive at a signed value for a relative frame number (frame R). If the relative frame number is negative, then the current frame is earlier than the 0th frame of the Isochronous TD and Host Controller <b>301</b> advances to the next ED. If the relative frame number is greater than FrameCount, then the Isochronous TD expires and an error condition exists.
If the relative frame number is between 0 and FrameCount, then Host Controller <b>301</b> issues a token to the endpoint and attempts a data transfer using the buffer described by the Isochronous TD. When the last data packet of an Isochronous TD is transferred, the Isochronous TD is removed to the DoneQueue.
Buffer Addressing:
Local buffer <b>308</b> address for an isochronous data packet is determined by using the BufferStartAddress field and LengthN field of the buffers. For physical buffer 0, its start address is BufferStartAddress and its size (packet size) is Length0. For physical buffer 1, its start address is BufferStartAddress+Length0 and its size is Length1 etc. <figref idref="DRAWINGS">FIG. 4J</figref> shows an example of calculating the buffer length for an isochronous TD.
Data Packet Size:
Each data packet has a size indicated by the Length field. For example, if Length=0, then a zero-length packet is indicated. For a zero-length “OUT packet”, Host Controller <b>301</b> issues a token and sends a zero length data packet. For a zero-length “IN” packet, Host Controller <b>301</b> issues a token and accepts a zero-length data packet from the endpoint.
Status:
After each data packet transfer, the corresponding Length is replaced with a value that indicates the status of the data packet transaction. For example, the upper 4 bits of the value may be the “CompletionCode” for the transaction. For an incoming data packet from a USB device (<b>203</b>), the lower bits (e.g. 12 bits) indicates the actual number of bytes written to local memory <b>308</b>. In the absence of errors, this is also the number of bytes received from the endpoint. For outgoing data packet(s), in the absence of transaction errors, the size field may be set to 0. Together, these two fields (CompletionCode and Size) constitute the Packet Status Word (PacketStatusWord).
Transfer Completion:
An Isochronous TD is completed when all “FrameCount+1” data packets have been transferred. This counting is done with the help of an internal counter. In the frame when R=FrameCount, after the data transaction is complete and the LengthR is updated, the “CompletionCode” of the Isochronous TD is set to N<smallcaps>O</smallcaps>E<smallcaps>RROR </smallcaps>and the Isochronous TD is removed to the Done Queue
Transfer Errors for Isochronous Endpoints:
Transfer errors for isochronous endpoints fall into four categories, namely, transmission, sequence, time and system.
Transmission Errors:
Since there is no handshake (acknowledgement) for isochronous transfers, Host Controller <b>301</b> can detect transmission errors for data transfers from an endpoint to host <b>10</b>A. The error may be a CRC, a B<smallcaps>IT</smallcaps>S<smallcaps>TUFFING</smallcaps>, or a D<smallcaps>EVICE</smallcaps>N<smallcaps>OT</smallcaps>R<smallcaps>ESPONDING </smallcaps>error. If any of these errors occur during the transfer, the CompletionCode of PacketStatusWord[R] is set accordingly and the size field reflects the number of bytes received (up to the size of the buffer defined for the frame) and placed in the local memory buffer <b>308</b>. For a bit stuffing error, Host Controller <b>301</b> writes up to the last byte received before the “BitStuffing error” is detected.
If a transmission error is detected along with a sequence or system error, the transmission error is the one that is reported in the CompletionCode. A PID check error in the PID from an endpoint is reported with a CompletionCode of PIDC<smallcaps>HECK</smallcaps>F<smallcaps>AILURE </smallcaps>
Sequence Errors:
A sequence error occurs when an endpoint sends more or less data than is expected and a transmission error is not present. If the endpoint sends more data than will fit in a specified buffer, the CompletionCode for the PacketStatusWord is set to “D<smallcaps>ATA</smallcaps>O<smallcaps>VERRUN</smallcaps>” and the size field is set to the size of the buffer. Host Controller <b>301</b> writes received data to local memory <b>308</b> up to the limit of the buffer defined for the frame. If the endpoint sends less data than defined by the buffer, the CompletionCode for the PacketStatusWord is set to “D<smallcaps>ATA</smallcaps>U<smallcaps>NDERRUN”. </smallcaps>
Time Errors:
Each data packet has a specific frame in which it is transferred. If Host Controller <b>301</b> cannot start or complete the transfer within the specified frames two types of error occur: “skipped packets” and “late retirement” of an Isochronous TD.
Skipped packet error occurs if Host Controller <b>301</b> does not process an Isochronous TD in a frame for which the Isochronous TD has data. A skipped packet is indicated when a Length/PacketStatusWord is set to “N<smallcaps>OT </smallcaps>A<smallcaps>CCESSED</smallcaps>” after the Isochronous TD is removed. This indicates that Host Controller <b>301</b> did not process the Isochronous TD for the frame and therefore did not change the Length to a PacketStatusWord.
If the last packet of an Isochronous TD was not processed in the frame in which it should have been processed and in which the TD should have been retired, the Isochronous TD remains in Host Controller <b>301</b>. In such cases, Host Controller <b>301</b> sets the CompletionCode for the Isochronous TD to “D<smallcaps>ATA</smallcaps>O<smallcaps>VERRUN</smallcaps>” and removes the Isochronous TD (it does not, however, set the Halted bit in the ED). Host Controller <b>301</b> then accesses the next Isochronous TD for the same ED and processes it.
Setting D<smallcaps>ATA</smallcaps>O<smallcaps>VERRUN </smallcaps>in the CompletionCode for the Isochronous TD rather than the PacketStatusWord indicates a time overrun. The same code in a PacketStatusWord indicates a true data buffer overrun.
System Errors:
System errors occur for isochronous transfers if there is underrun or overflow/overrun of local data memory buffers <b>308</b>. An Isochronous endpoint may have a certain MaxPacketSize, e.g., up to 1023 bytes. The intra-packet overflow will not occur because each endpoint is at least single buffered in local memory <b>308</b>. When an underrun error occurs, Host Controller <b>301</b> sets the CompletionCode of data packet's PacketStatusWord to B<smallcaps>UFFER</smallcaps>U<smallcaps>NDERRUN </smallcaps>and the size field is set to zero. This underrun condition is signaled on USB wires by Host Controller <b>301</b> forcing a “bit-stuffing” violation with the recommendation that the bit stuff violation last a certain time, e.g., 16 bit times without a transition.
When an overrun condition occurs, Host Controller <b>301</b> sets the CompletionCode of the data packet's PacketStatusWord to B<smallcaps>UFFER</smallcaps>U<smallcaps>NDERRUN </smallcaps>and writes the size field to indicate the last byte successfully received from the endpoint before the overrun condition occurred. All data received from the endpoint before the overrun condition occurred are stored in local memory <b>308</b>. If, after detecting an overrun condition, Host Controller <b>301</b> detects a transmission error, then the transmission error is recorded in the PacketStatusWord instead of the overrun error.
<figref idref="DRAWINGS">FIG. 4L</figref> shows an example of a PacketStatusWord format, according to one aspect of the present invention and <figref idref="DRAWINGS">FIG. 4M</figref> describes the field definitions of <figref idref="DRAWINGS">FIG. 4L</figref>.
<figref idref="DRAWINGS">FIG. 4N</figref> provides a listing of various completion codes, used in the various adaptive features of the present invention. For Control/Bulk and Interrupt TDs, the Completion Codes are used only if the TD is on the Done Queue. For CRC, B<smallcaps>IT</smallcaps>S<smallcaps>TUFFING</smallcaps>, and D<smallcaps>EVICE</smallcaps>N<smallcaps>OT</smallcaps>R<smallcaps>ESPONDING </smallcaps>errors, the TD is not moved to the Done Queue unless errors are encountered in three successive attempts (error does not have to be the same in all three attempts.)
For STALL, D<smallcaps>ATA</smallcaps>O<smallcaps>VERRUN</smallcaps>, or D<smallcaps>ATA</smallcaps>U<smallcaps>NDERRUN</smallcaps>, the TD is moved to the done queue on the first occurrence of the error. B<smallcaps>UFFER</smallcaps>O<smallcaps>VERRUN </smallcaps>or B<smallcaps>UFFER</smallcaps>U<smallcaps>NDERRUN </smallcaps>may not be used for Non-Isochronous TDs.
When a Non-Isochronous TD is moved to the done queue with the CompletionCode set to other than N<smallcaps>O</smallcaps>E<smallcaps>RROR</smallcaps>, the Halted bit in the ED for the endpoint is set to halt processing of the TDs.
For an Isochronous TD, Completion Codes appear in two places: in CompletionCode of “Dword0” and in each of the Length/PacketStatusWords. For each data packet processed, Host Controller <b>301</b> converts LengthR into “PSWR” by setting the CompletionCode field. All Completion Codes are valid for a PacketStatusWord. The CompletionCode in Dword0 of the Isochronous TD is set when the TD is moved to the done queue. The Isochronous TD can be moved to the done queue when the last data packet is transferred (in which case the CompletionCode will be N<smallcaps>O</smallcaps>E<smallcaps>RROR</smallcaps>) or due to the frame for the last data packet having passed (in which case the CompletionCode will be D<smallcaps>ATA</smallcaps>O<smallcaps>VERRUN</smallcaps>.) Host Controller <b>301</b> does not set the Halted bit in the ED for an Isochronous TD. An Isochronous TD with a N<smallcaps>O</smallcaps>E<smallcaps>RROR </smallcaps>CompletionCode may contain PacketStatusWords with CompletionCodes other than N<smallcaps>O</smallcaps>E<smallcaps>RROR. </smallcaps>
ETD Communications Area
ETD Communications Area <b>308</b>A is a defined structure of local memory <b>308</b> that is used by Host Controller Driver <b>202</b> to send and receive specific control and status information to and from Host Controller <b>301</b>. Host Controller Driver <b>202</b> must write this structure in an ETD table, shown in <figref idref="DRAWINGS">FIG. 4O</figref>. Host Controller <b>301</b> uses these ETDs to perform the transfer. Host Controller Driver <b>202</b> reads values from this structure that was written by Host Controller <b>301</b>.
In one aspect of the present invention, an ETD table may be composed of certain number of blocks, e.g., 16 blocks of 8 Dwords. Before Host Controller Driver <b>202</b> reads/writes an ETD, it first writes appropriate parameters into HcAccessStartAddress register <b>818</b>, described below, which specifies the memory space (ETD memory <b>308</b>A), the physical address to start with, and the read/write direction. For each new endpoint, its ED is first written into an ETD holder(not shown). Then its first TD is written below the ED. Each TD defines one or several transactions as described before. When the TD is removed, it is sent to the DoneQueue and a time deferred or immediate interrupt is generated. Host processor <b>101</b> reads out the retired TD and writes the next TD of the endpoint to the same position, or writes a new ETD to replace the finished ETD.
In one aspect of the present invention, each ETD takes 8 Dwords space in ETD memory <b>308</b>A. Each ETD has an associated bit in the HcETDEnableStatus register <b>829</b>, indicating if the ETD is enabled. The HcETDEnable status register has certain number of bits, e.g., 16 bits associated with each ETD. Host Controller <b>301</b> knows if an ETD is isochronous by checking the format field of the ED. This is a dynamic table that changes when a new endpoint is added or an existing endpoint is removed from the ETD table <b>308</b>D.
<figref idref="DRAWINGS">FIG. 4O</figref> shows an ETD table <b>308</b>D with control signals, according to one aspect of the present invention. The following describes the various ETDs (ETD<b>01</b>–ETD<b>15</b>) in <figref idref="DRAWINGS">FIG. 4O</figref>.
ETD <b>1</b> is a non-isochronous ETD. It is enabled, and not on the Done Queue, meaning that it is active and must be served.
ETD <b>2</b> is another isochronous ETD. It is enabled, and is not on the Done Queue.
ETD <b>3</b> is a non-isochronous ETD. It is enabled, and not on the Done Queue.
ETD <b>4</b> is a non-isochronous ETD. It is enabled, but it is on the Done Queue, meaning that it has retired. It works in DMA mode.
ETD <b>5</b> is a non-isochronous ETD. It is not enabled, meaning the Host Controller <b>301</b> ignores it.
ETD <b>6</b> to <b>13</b>, are invalid, because the enable bit is 0.
ETD <b>14</b> is non-isochronous. It is enabled, active and operates in non-DMA mode.
ETD <b>15</b> is another isochronous ETD. It is enabled, and is not on the Done Queue.thus active and operates in DMA mode.
An ETD is enabled or disabled through the HcETDSetEnable register <b>829</b> or HcETDClearEnable register <b>827</b>.
ETD DoneQueue
Register <b>835</b>, as shown in <figref idref="DRAWINGS">FIG. 8U</figref> indicates if a TD is retired (with or without an error). A bit is asserted at the same time as the CompletionCode update in the completed TD. From time to time, the deferred interrupt count is zero and an interrupt is generated. Host software <b>201</b> can check the retired TDs by reading HcDoneQueue register <b>835</b>. It can then decide to read out all the retired TDs and process them.
ETD Mode:
When an ETD is set up in ETD table <b>308</b>D, its default working mode may be set as the “PIO” mode, or in DMA mode where DMA controller <b>113</b> may be used to automate data transfer between system memory <b>102</b> and local memory <b>308</b>.
Each ETD may be individually programmed for DMA or PIO mode. When an ETD is removed, the associated DMA channel is also dissolved. When the ETD is put on the DoneQueue, the corresponding working mode bit is also cleared. This means that the DMA channel association exists at the ETD (transfer) level. The freed DMA channel can be used for the next ETD of the same endpoint, or for another ETD. Hence, in one aspect of the present invention, DMA channels are efficiently used to transfer data.
Host Controller <b>301</b> Operation in USB States
Host Controller <b>301</b> can operate in four USB states, namely, U<smallcaps>SB</smallcaps>O<smallcaps>PERATIONAL</smallcaps>, U<smallcaps>SB</smallcaps>R<smallcaps>ESET</smallcaps>, U<smallcaps>SB</smallcaps>S<smallcaps>USPEND</smallcaps>, and U<smallcaps>SB</smallcaps>R<smallcaps>ESUME</smallcaps>. These states define Host Controller <b>301</b> responsibilities relating to USB signaling and bus states.
USB states are reflected in HostControllerFunctionalState field of the HcControl registers <b>802</b> (<figref idref="DRAWINGS">FIG. 8C</figref>). Host Controller Driver <b>202</b> performs the USB state transitions shown in <figref idref="DRAWINGS">FIG. 5A</figref>.
USB Operational State:
When in the U<smallcaps>SB</smallcaps>O<smallcaps>PERATIONAL </smallcaps>state, Host Controller <b>301</b> may process lists and generate Start of Frame (“SOF”) tokens. The U<smallcaps>SB</smallcaps>O<smallcaps>PERATIONAL </smallcaps>state may be entered from the U<smallcaps>SB</smallcaps>R<smallcaps>ESUME </smallcaps>or U<smallcaps>SB</smallcaps>R<smallcaps>ESET </smallcaps>states. It may be exited to the U<smallcaps>SB</smallcaps>R<smallcaps>ESET </smallcaps>or U<smallcaps>SB</smallcaps>S<smallcaps>USPEND </smallcaps>states.
When transitioning from U<smallcaps>SB</smallcaps>R<smallcaps>ESET </smallcaps>or U<smallcaps>SB</smallcaps>R<smallcaps>ESUME </smallcaps>to U<smallcaps>SB</smallcaps>O<smallcaps>PERATIONAL</smallcaps>, Host Controller <b>301</b> terminates the USB reset or resume signaling as defined in the USB Specification prior to sending a token.
A transition to the U<smallcaps>SB</smallcaps>O<smallcaps>PERATIONAL </smallcaps>state affects the frame management registers of Host Controller <b>301</b>. Simultaneously with Host Controller <b>301</b>'s state transition to U<smallcaps>SB</smallcaps>O<smallcaps>PERATIONAL</smallcaps>, the FrameRemaining field of HcFmRemaining register <b>839</b> is loaded with the value of the FrameInterval field in HcFmInterval register <b>335</b>. There is no SOF Token sent at this initial load of the FrameRemaining field. The first SOF Token sent after entering the U<smallcaps>SB</smallcaps>O<smallcaps>PERATIONAL </smallcaps>state is sent following the next frame boundary when FrameRemaining transitions from 0 to FrameInterval. The FrameNumber field of HcFmNumber register <b>841</b> is incremented on a transition to U<smallcaps>SB</smallcaps>O<smallcaps>PERATIONAL </smallcaps>state.
USB Reset:
When in the U<smallcaps>SB</smallcaps>R<smallcaps>ESET </smallcaps>state, Host Controller <b>301</b> forces reset signaling on bus <b>202</b>. Host Controller <b>301</b> list processing and SOF Token generation are disabled while in the U<smallcaps>SB</smallcaps>R<smallcaps>ESET STATE</smallcaps>. In addition, the FrameNumber field of HcFmNumber register <b>841</b> does not increment while Host Controller <b>301</b> is in the U<smallcaps>SB</smallcaps>R<smallcaps>ESET </smallcaps>state. U<smallcaps>SB</smallcaps>R<smallcaps>ESET </smallcaps>state can be entered from any state at any time. Host Controller <b>301</b> defaults to the U<smallcaps>SB</smallcaps>R<smallcaps>ESET </smallcaps>state following a hardware reset. Host Controller Driver <b>202</b> is responsible for satisfying USB Reset signaling timing defined by the USB Specification.
USBSUSPEND:
IN U<smallcaps>SB</smallcaps>S<smallcaps>USPEND </smallcaps>state, Host Controller <b>301</b>'s list processing and SOF Token generation are disabled. However, the Host Controller <b>301</b>'s remote wakeup logic monitors USB wakeup activity. The FrameNumber field of HcFmNumber does not increment while Host Controller <b>301</b> is in the U<smallcaps>SB</smallcaps>S<smallcaps>USPEND </smallcaps>state. U<smallcaps>SB</smallcaps>S<smallcaps>USPEND </smallcaps>state is entered following a reset or from the U<smallcaps>SB</smallcaps>O<smallcaps>PERATIONAL </smallcaps>state, on command from Host Controller Driver <b>202</b>.
While in U<smallcaps>SB</smallcaps>S<smallcaps>USPEND</smallcaps>, Host Controller <b>301</b> may force a transition to the U<smallcaps>SB</smallcaps>R<smallcaps>ESUME </smallcaps>State due to a remote wakeup condition. This transition may conflict with Host Controller Driver <b>202</b> initiating a transition to the U<smallcaps>SB</smallcaps>R<smallcaps>ESET </smallcaps>State. If this situation occurs, Host Controlled Driver <b>202</b> initiated transition to U<smallcaps>SB</smallcaps>R<smallcaps>ESET </smallcaps>has priority. Host Controller Driver <b>202</b> must wait a certain time period after transitioning to U<smallcaps>SB</smallcaps>S<smallcaps>USPEND </smallcaps>and before transitioning to the U<smallcaps>SB</smallcaps>R<smallcaps>ESUME </smallcaps>State. Likewise, Root Hub <b>104</b> must wait after Host Controller <b>301</b> enters U<smallcaps>SB</smallcaps>S<smallcaps>USPEND </smallcaps>before generating a local wakeup event and forcing a transition to U<smallcaps>SB</smallcaps>R<smallcaps>ESUME</smallcaps>. Following a software reset, Host Controller Driver <b>202</b> may cause a transition to U<smallcaps>SB</smallcaps>O<smallcaps>PERATIONAL </smallcaps>if the transition occurs not more than 1 ms from the transition into U<smallcaps>SB</smallcaps>S<smallcaps>USPEND</smallcaps>. If the 1-ms period is violated, it is possible that the device(s) (<b>203</b>) on the USB bus <b>111</b> may go into Suspend.
USB Resume:
When in the U<smallcaps>SB</smallcaps>R<smallcaps>ESUME </smallcaps>state, Host Controller <b>301</b> forces resume signaling on bus <b>111</b>. While in U<smallcaps>SB</smallcaps>R<smallcaps>ESUME </smallcaps>state, Root Hub <b>104</b> propagates the USB Resume signal to downstream ports as specified in the USB Specification. Host Controller <b>301</b>'s list processing and SOF Token generation are disabled while in U<smallcaps>SB</smallcaps>R<smallcaps>ESUME </smallcaps>state. In addition, the FrameNumber field of HcFmNumber register <b>841</b> does not increment while Host Controller <b>301</b> is in the U<smallcaps>SB</smallcaps>R<smallcaps>ESUME </smallcaps>state.
U<smallcaps>SB</smallcaps>R<smallcaps>ESUME </smallcaps>is entered from U<smallcaps>SB</smallcaps>S<smallcaps>USPEND</smallcaps>. The transition to U<smallcaps>SB</smallcaps>R<smallcaps>ESUME </smallcaps>can be initiated by Host Controller Driver <b>202</b> or by a USB remote wakeup signal from Root Hub <b>104</b>. Host Controller <b>301</b> is responsible for resolving state transition conflicts between the hardware wakeup and Host Controller Driver initiated state transitions. Host Controller Driver <b>202</b> is responsible for USB Resume signal timing as defined by the USB Specification.
HCSuspend:
HCSuspend state is entered upon command from the Host Controller Driver <b>202</b>. The clock system of the Host Controller <b>301</b> is turned off. Only the single-ended receivers of downstream port(s) of the Root-Hub <b>104</b> remain on, to monitor the remote wakeup signaling from a device. When Host Controller <b>301</b> asynchronously detects a remote wakeup signaling, it generates a request to the clock circuitry of the Host Controller <b>301</b> so that the clock signal is turned on.
Frame Management:
Host Controller <b>301</b> is responsible for managing all aspects of “framing” for the USB. These responsibilities include the sending of SOF Tokens on bus <b>111</b> and communicating with Host Controller Driver <b>202</b> on frame-specific information.
Frame Timing:
Host Controller <b>301</b> uses registers to perform the frame timing and information reporting tasks of frame management. Host Controller <b>301</b> as a reference number for the current frame keeps the FrameNumber field, which may be 16 bits (<figref idref="DRAWINGS">FIG. 4D</figref>), of the HcFmNumber register <b>841</b>. This frame number is sent over USB bus <b>111</b> as the Frame Number field in SOF Tokens and is reported by Host Controller <b>301</b> for use by Host Controller Driver <b>202</b>. The FrameInterval field of HcFmInterval register <b>837</b> and the FrameRemaining field of HcFmRemaining register <b>839</b> are used to define frame boundaries.
The FrameInterval field stores the length of a USB frame in bit times, e.g., 12-MHz bit times. Specifically, the FrameInterval field corresponds to (Frame Length—1) bit times. FrameInterval is loaded with a default value, e.g., a value of 0×2EDF (11,999 decimal) at reset. This value produces a USB frame consisting of certain bit times, e.g., 12,000 bit times. Host Controller Driver <b>202</b> may vary the value of FrameInterval at any time.
An example of frame format is provided in <figref idref="DRAWINGS">FIG. 4D</figref>. Each frame begins with a SOF and is sent by Host Controller <b>301</b> to bus <b>111</b>. This is followed by Host controller <b>301</b> servicing isochronous ETDs and interrupt ETDs. After the periodic transfers are complete, any remaining time in the frame is consumed by servicing non-periodic transfers.
The FrameRemaining field functions as a counter, e.g., as a 14-bit frame counter. When operating, the register value decrements once per USB bit time. When FrameRemaining reaches a certain value, e.g., 0, it is loaded with the value of the FrameInterval field at the next bit-time boundary. The frame boundary is the bit boundary on which the value of FrameRemaining transitions from 0 to FrameInterval (a J to K transition is seen on the USB at this boundary signifying the first bit of the sync field of an SOF Token). In other words, the last bit time for a frame is defined as the bit time in which the value of FrameRemaining is 0. The first bit time for a frame is defined as the bit time in which the value of FrameRemaining is equal to FrameInterval.
HcFmNumber register <b>841</b> holds the current frame number in the FrameNumber field. This field is incremented by Host Controller <b>301</b> at each frame boundary. FrameNumber is incremented when the FrameRemaining field transitions from 0 to FrameInterval. Host Controller Driver <b>202</b> in the construction of a larger resolution frame number may use the FrameNumber field. Host Controller Driver <b>202</b> has access to the FrameNumber field to HcFrameNumber at any time. Immediately following the increment of the FrameNumber, the Host Controller <b>301</b> sets the StartOfFrame bit in the HcInterruptStatus register <b>806</b> to signify a StartOfFrame interrupt event.
SOF Token Generation:
When in the U<smallcaps>SB</smallcaps>O<smallcaps>PERATIONAL </smallcaps>state Host Controller <b>301</b> generates an SOF Token at the beginning of each frame period. There are no SOF Tokens generated when the Host Controller <b>301</b> is in a state other than U<smallcaps>SB</smallcaps>O<smallcaps>PERATIONAL. </smallcaps>
Host Controller <b>301</b> must be exact in its delivery of the SOF token to the USB. Host Controller <b>301</b> sends the first bit of the SOF Token “SYNC” field during the first bit time of the frame. The timing chart of SOF Token on bus <b>111</b> is shown in <figref idref="DRAWINGS">FIG. 5B</figref>.
ETD Table Processing
Priority
In one aspect of the present invention, Host Controller <b>301</b> processes endpoints whose ETDs are written to ETD table <b>308</b>D in ETD memory <b>308</b>A. Among the four types of ETDs (Control, Bulk, Isochronous, and Interrupt), the Isochronous ETDs are processed first, Interrupt ETDs second, and then the Control and Bulk ETDs are processed. Control Endpoints are given equal or more preference over Bulk Endpoints for processing. More specifically, N Control Endpoints are given access to the bus <b>101</b>A for every 1 Bulk Endpoint.
Host Controller Driver <b>202</b> can program the Control Bulk Service Ratio via the ControlBulkServiceRatio field of the HcControl Register <b>802</b>. Control Bulk Service Ratios may be from 1:1 to 4:1. An example of a 4:1 Control/Bulk Service Ratio is shown in <figref idref="DRAWINGS">FIG. 5C</figref>.
Within a given type, the ETD whose index is lowest is processed first. Host Controller Driver <b>202</b> allocates a certain percentage of processing time for Isochronous, Interrupt, Bulk and Control ETDs.
When Host Controller <b>301</b> reaches the last ETD for Control or Bulk, it starts again with the first ETD of Control or Bulk endpoint. Servicing an ED is defined as making a single transaction attempt based on the TD. Once a transaction attempt is made, whether successful or not, and the appropriate actions are taken to complete that transaction, Host Controller <b>301</b> services the next endpoint rather than make a second transaction attempt on the current endpoint.
In system memory <b>102</b>, the priority TDs are on a queue under an ED for an endpoint. Only one of them is written into ETD table <b>308</b>D in ETD memory <b>308</b>A for one endpoint. When one TD is retired, it is first read out and the next TD is written into ETD table <b>308</b>D for processing.
In one aspect, the foregoing system is scalable to local memory <b>308</b> size. CPU <b>101</b> writes the start address of an ETD in a register, as discussed below and data is written into local memory <b>308</b>, which is accessible on word basis and/or word burst basis. Hence, the address bus (<figref idref="DRAWINGS">FIG. 3</figref>) size does not require any changes
ETD Service Flow:
<figref idref="DRAWINGS">FIG. 5D</figref> shows executable process steps for processing ETDs according to one aspect of the present invention.
In step S<b>500</b>, Scheduler <b>301</b>C starts. Typically this starts for each SOF and the rising edge of the ETDenable register <b>825</b> bit.
In step S<b>501</b>, Host Controller <b>301</b> checks ETD type and ETDenable register <b>825</b> values for the all the four types of ETDs.
In step S<b>502</b>A, if the ETDEnable register value is enabled, for example, 1, and the ETD type is isochronous, then in step S<b>502</b>B, the ETD is added to the isochronous list in ETD table <b>308</b>D in ETD memory <b>308</b>A.
In step S<b>503</b>A, if the ETDEnable register value is enabled, for example, 1, and if the ETD type is interrupt, then in step S<b>503</b>B, the ETD is added to the interrupt list in the ETD table <b>308</b>D in ETD memory <b>308</b>A.
In step S<b>504</b>A, if the ETDEnable register value is enabled, for example, 1, and the ETD type is Control, then in step S<b>503</b>B, the ETD is added to the control list in the ETD table <b>308</b>D in ETD memory <b>308</b>A.
In step S<b>505</b>A, if the ETDEnable register value is enabled, for example, 1 and if the ETD type is bulk, then in step S<b>505</b>B, the ETD is added to the interrupt list in the ETD table in ETD memory <b>308</b>A.
After the ETD table is populated and the lists are updated, in step S<b>506</b>, ETD handler <b>301</b>B is started to process the ETDs as discussed below with respect to <figref idref="DRAWINGS">FIG. 5E</figref>.
In step S<b>507</b>A, ETD handler <b>301</b>B determines if there are remaining isochronous ETDs. Then in step <b>507</b>A, ETD handler <b>301</b>A loads the ETDs into cache (not shown), executes the ETD in step S<b>507</b>B, and then updates the ETD table <b>308</b>Din step S<b>507</b>C.
When processing an Isochronous TD, Host Controller <b>301</b> calculates the relative frame number. This calculation determines which, if any, packet will be sent during a current frame.
Host Controller <b>301</b> updates the Length[R] field after packet transmission using the Packet Status Word. For an “OUT packet”, the Size field is set to a certain value, e.g., 0, if there is no error. For an IN packet, the Size field reflects the actual number of bytes written to local memory buffer <b>308</b>. Regardless of transfer direction, the CompletionCode field is updated to reflect the outcome of transmission.
In step S<b>508</b>, ETD handler <b>301</b>B determines if there are remaining interrupt ETDS. Then in step <b>508</b>A, ETD handler <b>301</b>A loads the ETDs into cache (not shown), executes the ETD in step S<b>508</b>B and then updates the ETD table in step S<b>508</b>C.
When processing an Interrupt TD, the relative polling position may be used to determine if an endpoint should be served in a particular frame. Host Controller Driver <b>202</b> programs the initial value of “RPP” when the TD is written from system memory <b>102</b>. This value then decrements by one for every frame time. When RPP reaches a certain value, e.g., 0, this TD is served, after which RPP is re-loaded with its initial value. Once an ETD is written into ETD table <b>308</b>D and it is enabled, the first interrupt transaction is attempted and after that an interrupt transaction is attempted every polling interval frame.
In step S<b>509</b>, ETD handler <b>301</b>B determines if there are remaining bulk ETDs. Then in step <b>509</b>A, ETD handler <b>301</b>A loads the ETDs into cache (not shown), executes the ETD in step S<b>509</b>B and then updates the ETD table in step S<b>509</b>C.
In step S<b>510</b>, ETD handler <b>301</b>B determines that there are remaining control ETDs, then in step <b>510</b>A, ETD handler <b>301</b>A loads the ETDs into cache (not shown), executes the ETD in step S<b>510</b>B and then updates the ETD table in step S<b>510</b>C.
Control/Bulk and Interrupt ETDs are updated after every attempted transaction. The CompletionCode field, the DataToggle field, the PacketCount field, and occasionally the ErrorCount field are updated after a transaction attempt.
The DataToggle field is updated to reflect the data toggle value for the next transfer. If the packet transmission is complete, Host Controller <b>301</b> sets the MSb and toggles the LSb of DataToggleControl field to reflect a new value for the next packet. If the current packet did not complete with a proper ACK or NAK packet, the field is not be changed.
The PacketCount is updated to reflect the data transferred in the current packet if the transmission ended with a proper ACK. For an IN endpoint, if Host Controller <b>301</b> received a packet with an incorrect data toggle, the PacketCount is not updated because the packet is discarded. For an OUT endpoint, if the Host Controller <b>301</b> received a NAK packet, the PacketCount may not be updated because Host Controller <b>301</b> retries the current packet.
If there is an error in packet transmission, the ErrorCount field is incremented. If the ErrorCount is 2 and another error occurs, the ETD is retired with the error code reflected in the CompletionCode field.
The CompletionCode field of a Control/Bulk and Interrupt Transfer Descriptor is updated after every attempted transaction whether successful or not. If the transaction is successful, the CompletionCode field is set to “No Error”, otherwise, it is set according to the error type.
When an endpoint returns a NAK packet for a transmission, all Control/Bulk and Interrupt Transfer Descriptor fields are the same after the transaction as they were before the transaction. Host Controller <b>301</b> does not need to make any changes, except the case where StopOnNak is enabled.
In step S<b>511</b>, ETD handling is terminated.
Once Host Controller <b>301</b> determines a packet's size, it must check to see if packet transmission can occur over USB before the end of the frame. This is determined by comparing the bit times remaining before the end of the frame with the bit time requirement of the packet to be transmitted. If the bit time requirement of the packet is larger than the bit times remaining in the frame, the transaction may not be initiated. This ensures that Host Controller <b>301</b> is not responsible for causing a “babble” condition on the bus. For full speed transactions, Host Controller <b>301</b> uses the Largest Data Packet Counter to determine if a given packet can be transferred.
For low speed transactions, regardless of data size, Host Controller <b>301</b> compares the current value of the FrameRemaining field of HcFmRemaining register <b>839</b> with the value of the LSThreshold field of the HcLSThreshold register <b>843</b>. If FrameRemaining is less than LSThreshold, the low speed transaction is not started.
At each frame boundary, the Largest Data Packet Counter is loaded with the value of the FSLargestDataPacket field in HcFmInterval register <b>837</b> (at the same time FrameRemaining is loaded with the value of FrameInterval).
When Host Controller <b>301</b> loads a ETD, the worst case number of bit times for the data transfer is known. This value is the byte count multiplied by a certain number, e.g., 8, using the MaximumPacketSize byte count for reads (the transaction overhead and the frame overhead are accounted for in the initial value of the counter). If the bit count required is greater than the remaining bit count in the Largest Data Packet Counter, the transfer is not started. When the transfer is not started, there is no status writeback to the ETD.
When an ETD is complete (all data sent/received) or an error condition occurs, the ETD is retired. Several actions are required to retire an ETD. Host Controller <b>301</b> sets the corresponding bit in the HcDoneQueue register <b>835</b>. Host Controller <b>301</b> updates the ETD to reflect the changes to the DataToggleCarry field, and potentially the Halt field. The retired ETD is effectively dequeued. Host Controller driver <b>202</b> can then write into ETD table <b>308</b>D the next ETD on the TD queue of the endpoint.
Host Controller <b>301</b> also updates the DataToggleCarry field of the ETD. The DataToggleCarry field reflects the last data toggle value from the retired ETD. If the ETD is being retired because of an error, Host Controller <b>301</b> updates the Halt bit of the ETD.
To complete ETD retirement, Host Controller <b>301</b> updates the DoneQueue Interrupt Counter located at host registers <b>301</b>D, described below. The InterruptDelay field of the ETD specifies the maximum number of SOFs that occurs before Host Controller <b>301</b> generates an interrupt. If the value of the InterruptDelay field is a certain value, e.g., 111b, Host Controller Driver <b>202</b> does not require an interrupt for the ETD and the DoneQueue Interrupt Counter is left unchanged.
If the value of the InterruptDelay field is not 111b (or some other value), but is greater than or equal to the current value of the DoneQueue Interrupt Counter, the counter is also left unchanged. In this case, another ETD already on the DoneQueue requires an interrupt earlier than the ETD being retired.
If the value of the InterruptDelay field is not 111b, but is less than the current value of the DoneQueue Interrupt Counter, the counter is loaded with the value of the InterruptDelay field. In this case, the ETD being retired requires an interrupt earlier than all of the ETDs currently on the DoneQueue. If the ETD is being retired with an error, then the DoneQueue Interrupt Counter is cleared as if the InterruptDelay field were zero.
Host Controller <b>301</b> maintains a counter (e.g., a 3-bit counter) that is used to determine how often the HcDoneQueue register <b>835</b> value must be read out by system software <b>201</b>. The counter is initialized with a value, e.g., 111b, at software reset, hardware reset, and updated when the Host Controller <b>301</b> transitions to the U<smallcaps>SB</smallcaps>O<smallcaps>PERATIONAL </smallcaps>state.
The counter functions when Host Controller <b>301</b> is in the U<smallcaps>SB</smallcaps>O<smallcaps>PERATIONAL </smallcaps>state by decrementing at every frame boundary simultaneous with the incrementing the FrameNumber field in HcFmNumber registered <b>841</b> if the current value of the counter is other than 111b or 0. If the current value of the counter is other than a certain value (111b or 0), the counter is effectively disabled and does not decrement.
Host Controller <b>301</b> checks the value of the counter during the last bit time of every frame when in the U<smallcaps>SB</smallcaps>O<smallcaps>PERATIONAL </smallcaps>state. If the value of the counter is 0 at that time, and the DoneQueue is not empty, then an interrupt is generated.
Mega Buffering:
<figref idref="DRAWINGS">FIG. 6A</figref> shows an example of how a memory buffer in local memory <b>308</b> may be used to transfer data between host system <b>101</b>A and a USB device. In one aspect the present invention uses a write pointer, a read pointer and plural filled flags (Xbufferfilled and Ybufferfilled, described below) to read and write data. The write side sets the XBufferfilled or Ybufferfilled flag when a memory buffer is full and the read side clears the flag when data is read out.
Buffer <b>600</b> is divided into two parts, X buffer <b>601</b> and Y buffer <b>602</b>. Write pointer <b>603</b> and read pointer <b>604</b> are used to read and write data, as described below. X-buffer <b>601</b> and Y-buffer <b>602</b> may not be contiguous.
Size of the buffers is based on the type and size of TDs. Packet count filed (PC) defines the number of packets in a TD. For example, for isochronous TD, CPU <b>101</b> needs to set up and enable a TD before the actual frame number reaches the Starting Frame. For all types of endpoints, different packet sizes are used and that is one of the factors in varying the buffer size. Hence each mega-buffer (e.g. X-buffer <b>601</b> and Y-buffer <b>602</b>) can be programmed by CPU <b>101</b> to hold NP (number of packets per buffer) packets.
Host Controller Driver <b>202</b> can schedule a certain number of packets for each TDs indicated by Packetcount. However, CPU <b>101</b> may allocate a smaller size for a particular endpoint. Each ETD is allocated a double mega-buffer (<figref idref="DRAWINGS">FIG. 6A</figref>) which can hold NP packets of data. CPU <b>101</b> sets up an ETD and enables it. Communication between CPU <b>101</b> and Host Controller <b>301</b> is through address bus, data bus, StartAddress register <b>818</b> and Dataport register <b>851</b>. ETD memory <b>308</b>A and data memory <b>308</b>C use separate addresses.
To write an ETD into Host Controller <b>301</b> memory <b>308</b>, CPU <b>101</b> writes the starting physical address of the ETD into StartAddress register <b>818</b> and the writes the ETD word by word to the DataPort register <b>851</b>. Internal logic keeps an address count of ETD memory, transfers ETD elements from DataPort register <b>851</b> to ETD memory <b>308</b>A. ETD and data phase are indicated by a “T” bit of StartAccess register <b>818</b> (<figref idref="DRAWINGS">FIG. 8L</figref>). CPU <b>101</b> has access to every element of an ETD by the memory address of StartAddress register <b>818</b>. Burst access is obtained by specifying the start address of the burst through StartAddress register <b>818</b> and then through DataPort register <b>851</b>.
<figref idref="DRAWINGS">FIG. 6B</figref> shows a process flow diagram of executable process steps for using local memory <b>308</b>, according to one aspect of the present invention. In one aspect, the process prevents under utilization of memory <b>308</b> because Host Controller <b>301</b> is not allowed to send data until one segment of data buffer (e.g., X-buffer <b>601</b>, as shown in <figref idref="DRAWINGS">FIG. 6A</figref>) is full. Data from system memory <b>102</b> is first transferred to X-buffer <b>601</b>. When X-buffer <b>601</b> is full, Host Controller <b>301</b> may transfer data from X-buffer <b>601</b>.
X-buffer <b>601</b> may hold up to NP packets. Host Controller <b>301</b> segments data into individual packets for reading.
When X-buffer <b>601</b> is being read, another buffer, Y-buffer <b>602</b> is filled. X-buffer <b>601</b> and Y-buffer <b>602</b> are used circularly, for example, when Y-buffer <b>602</b> is filled and less than PacketCount packets have been written from system memory <b>102</b>, then incoming packets are routed to X-buffer <b>601</b>, if it is available. The process continues until all data is written in local memory <b>308</b>.
Turning now in detail to <figref idref="DRAWINGS">FIG. 6B</figref>, in step S<b>601</b>, CPU <b>101</b> first writes the starting physical address into Start Address Register <b>818</b> located at <b>301</b>D.
In step S<b>602</b>, based upon the ETD, data is written from system memory <b>102</b> to local memory <b>308</b>. Data is first written to X buffer <b>601</b>. When buffer X-buffer <b>601</b> is full, it is indicated by the Xbuffer Filled register <b>820</b>. Once X-buffer <b>601</b> is filled, it may be read in step S<b>602</b>A. While data is read from X-buffer <b>601</b> in step S<b>602</b>A, in step S<b>603</b>, data is written to Y-buffer <b>602</b>. X-buffer <b>601</b> and Y-buffer <b>602</b> are used in a circular fashion, as discussed above.
In step S<b>604</b>, Y-buffer <b>602</b> is filled and then read in step S<b>604</b>A. This process continues, namely, X-Buffer <b>601</b> is filled in step S<b>605</b> and the process waits until X-buffer is read in step S<b>605</b>A.
Various interrupts are generated during this process, e.g., in step S<b>602</b>C and S<b>604</b>B and are described below.
A handshake (or acknowledgement) is used during the data transfer between system memory <b>102</b> and local buffers <b>308</b>. This handshake takes different forms depending on how data transfer is done, i.e. through DMA controller <b>113</b> or through a PIO.
In the DMA mode, the microprocessor <b>101</b> sets up and enables an ETD. ETD scheduler <b>301</b>C detects this new ETD and finds out that there is data available for sending out to the USB bus <b>111</b>, and will accordingly generate an internal DMA request. The DMA interface handler <b>307</b>A will first read out the necessary parameters from the ETD, like MaximumPacketSize, and then propagate the internal DMA request to the external DMA controller <b>113</b>.
Host Controller <b>301</b> keeps an internal data byte counter, and packet counter to indicate the byte count and the packet count that the DMA controller has already written to the local memory <b>308</b>.
When NP packets have been transferred from the system memory <b>102</b> to the local memory <b>308</b>, the DMA control logic of the Host Controller <b>301</b> validates this mega-buffer (X or Y) through a bit in the XbufferFilled or YbufferFilled register <b>818</b>. At the end of a transfer, system memory <b>102</b> may have less than NP packets to write to local memory <b>308</b>.
When all packets have been written, the DMA control logic will validate the mega-buffer (X or Y) through XbufferFilled or YbufferFilled register <b>818</b>. The read side of local memory <b>308</b> detects this special case with the help of PacketCount and the LastPacketSize. The last packet may be a short packet, as determined by LastPacketSize. For an OUT endpoint, if PacketCount is one and the LastPacketSize is zero, a zero-length packet is sent for this TD. When all packets have been sent out to the device endpoint, the Host Controller <b>301</b> will generate a deferred interrupt according to DI (DelayInterrupt).
In the PIO mode, in order to start the data phase, CPU <b>101</b> first writes the physical start address of the local data memory into StartAddress register <b>818</b>. CPU <b>101</b> keeps track of data written.
When NP packets of data have been written, the microprocessor validates the mega-buffer (X or Y) through XbufferFilled or YbufferFilled register, for transmission to USB bus <b>111</b>. Within the same mega-buffer, Host Controller <b>301</b> increments its memory pointer. When one mega-buffer (X <b>601</b> or Y <b>602</b>) is full, CPU <b>101</b> allows Host Controller to switch to the mega-buffer (Y or X), by first writing the starting address of that mega-buffer to the StartAddress register <b>818</b>.
At the end of a transfer, CPU <b>101</b> may have less than NP packets to write to local memory <b>308</b>. When all packets have been written, CPU <b>101</b> validates the mega-buffer (X or Y) through XbufferFilled or YbufferFilled register. The read side of the local memory <b>308</b> detects this special case with the help of PacketCount and the LastPacketSize. If the LastPacketSize is zero, a zero-length packet will be sent.
In another aspect of the present invention the mega-buffers of <figref idref="DRAWINGS">FIG. 6A</figref> are used in a circular fashion. For example, when Y-Buffer <b>602</b> is full and less than PacketCount packets have been written from system memory <b>102</b>, then the next incoming packet is routed into X-Buffer <b>601</b>. This process continues until all packets have been written.
Host Controller <b>301</b> will generate an interrupt when it has read out and successfully sent all the packets in a mega-buffer, and clear the XbufferFilled or YbufferFilled register, and generate appropriate interrupt to microprocessor All other mechanisms are the same as in DMA mode.
<figref idref="DRAWINGS">FIG. 7</figref> shows executable process steps when data is sent IN to host system <b>100</b>A.
Turning now in detail to <figref idref="DRAWINGS">FIG. 7</figref>, in step S<b>701</b>, CPU <b>101</b> writes the starting physical address into the Start Address Register <b>818</b> located at <b>301</b>D.
In step S<b>702</b>, based upon the ETD, data is written to memory <b>308</b>. Data is first written to X buffer <b>601</b>. When X-buffer <b>601</b> is full in step S<b>702</b>, it is indicated by the Xbuffer Filled register <b>820</b> in step S<b>703</b>. Once X-buffer <b>601</b> is filled, it may be read in step S<b>702</b>A. While data is read from X-buffer <b>601</b> in step S<b>702</b>A, in step S<b>704</b>, data is written to Y-buffer <b>602</b>. X-buffer <b>601</b> and Y-buffer <b>602</b> are used in a circular fashion, as discussed above.
In step S<b>705</b>, Y-buffer <b>602</b> is filled and then read in step S<b>704</b>A. This process continues, namely, X-Buffer <b>601</b> is filled in step S<b>706</b> and the process waits until X-buffer is read in step S<b>706</b>A.
Interrupts are generated in steps S<b>703</b> and <b>705</b>A and are described above with respect to <figref idref="DRAWINGS">FIG. 6B</figref>.
The foregoing buffering techniques has advantages because it allows Host Controller <b>301</b> to transfer data efficiently. For an endpoint working in the PIO mode, very few interrupts are required. For example, if a bulk/control/interrupt endpoint is 64 bytes and NP is chosen as 1023 910 bits) 10 bits, then only one interrupt is retired because 1024*64=64K bytes of data. CPU <b>101</b> may scale the interrupt frequency based on the value of NP, and actual size of memory <b>308</b>.
For isochronous endpoint, packet size varies, and the adaptive nature of the present invention allows varying the size of NP and the size of the foregoing mega-buffers.
Operational Registers
<figref idref="DRAWINGS">FIG. 8A</figref> provides a list of plural operational registers that are used by Host Controller <b>301</b>, in one aspect of the present invention. Among other functions, the registers are used for Control and Status, Memory Pointers, Frame Counters and Root Hub. Dwords are used to write and read the registers. To ensure interoperability, Host Controller Driver <b>202</b> does not use a reserved field and should not assume that the reserved field contains 0. Furthermore, Host Controller Driver <b>202</b> preserves the value(s) of the reserved field.
When a read/write register is modified, Host Controller Driver <b>202</b> first reads the register, modifies the bits desired, then writes the register with the reserved bits still containing the read value. Alternatively, Host Controller Driver <b>202</b> may maintain an in-memory copy of previously written values that can be modified and then written to Host Controller <b>301</b> registers.
<figref idref="DRAWINGS">FIG. 8B</figref> shows register <b>800</b> that controls revision level of the systems according to one aspect of the invention. Table <b>801</b>, provides a description of the field “REV”.
<figref idref="DRAWINGS">FIG. 8C</figref> shows the HcControl register <b>802</b> that defines the operating modes for Host Controller <b>301</b>. Host Controller Driver <b>202</b> can modify most of the fields, except, Host ControllerFunctionalState field, which is modified by Host Controller <b>301</b>. The various fields in register <b>802</b> are described in Table <b>803</b>.
<figref idref="DRAWINGS">FIG. 8D</figref> shows HcCommandStatus register <b>804</b> that is used by Host Controller <b>301</b> to receive commands issued by Host Controller Driver <b>202</b>, as well as reflecting the current status of Host Controller <b>301</b>. To Host Controller Driver <b>202</b>, HcCommandStatus register <b>804</b> appears to be a “write to set” register. Host Controller <b>301</b> ensures that bits written, e.g., as ‘1’ become set in the register while bits written as others, e.g., ‘0’ remain unchanged in the register. Host Controller Driver <b>202</b> may issue multiple distinct commands to Host Controller <b>301</b> without concern for corrupting previously issued commands. Host Controller Driver <b>202</b> has normal read access to all bits.
The plural fields in register <b>804</b> are explained in table <b>805</b>. For example, the SchedulingOverrunCount field indicates the number of overrun frames detected by Host Controller <b>301</b>. This occurs when either isochronous or interrupt list do not complete before end of frame (EOF). When a scheduling overrun error is detected, Host Controller <b>301</b> increments the counter and sets the SchedulingOverrun field in the HcInterruptStatus register <b>804</b>.
HcSystemInterruptStatus Register
<figref idref="DRAWINGS">FIG. 8E</figref> shows the HcSystemInterruptStatus register <b>806</b> fields that are described in table <b>807</b>. This register provides the status on various system level events that cause hardware interrupts. When a system level event occurs, Host Controller <b>301</b> sets the corresponding bit in this register. When a bit becomes set, a hardware interrupt is generated if the interrupt is enabled in the HcSystemInterruptEnable register <b>808</b> and the MasterSystemInterruptEnable bit is set. Host Controller Driver <b>202</b> may clear specific bits in this register by writing, e.g., ‘1’ to bit positions.
HcSystemInterruptEnable Register
<figref idref="DRAWINGS">FIG. 8F</figref> shows a HcSystemInterruptEnable register <b>808</b> field that are described in Table <b>809</b>, according to one aspect of the present invention. Each enable bit in the HcSystemInterruptEnable register <b>808</b> corresponds to an associated interrupt bit in the HcSystemInterruptStatus register <b>806</b>. The HcSystemInterruptEnable register <b>808</b> is used to control which system level events generate a hardware interrupt. When a bit is set in the HcSystemInterruptStatus register <b>808</b> and the corresponding bit in the HcSystemInterruptEnable register <b>808</b> is set and the MasterSystemInterruptEnable bit is set, then a hardware interrupt is generated on the host bus <b>101</b>A.
Writing a ‘1’ to a bit in this register sets the corresponding bit, whereas writing a ‘0’ to a bit in this register leaves the corresponding bit unchanged. On read, the current value of this register is returned.
HcSystemInterruptDisable Register”
<figref idref="DRAWINGS">FIG. 8G</figref> shows HcSystemInterruptDisable Register <b>810</b>, according to one aspect of the present invention. Each disable bit in the HcSystemInterruptDisable register <b>810</b> corresponds to an associated interrupt bit in the HcSystemInterruptStatus register <b>806</b>. HcSystemInterruptDisable register <b>810</b> is coupled with the HcSystemInterruptEnable register <b>808</b>. Thus, writing, e.g., a ‘1’ to a bit in this register clears the corresponding bit in the HcSystemInterruptEnable register <b>808</b>, whereas writing a ‘0’ to a bit in this register leaves the corresponding bit in the HcSystemInterruptEnable register <b>808</b> unchanged. On read, the current value of the HcSystemInterruptEnable register <b>808</b> is returned. Table <b>811</b> describes the various fields of register <b>810</b>.
HcETDInterruptStatus Register:
<figref idref="DRAWINGS">FIG. 8H</figref> shows the HcETDInterruptStatus register <b>812</b> fields that are described in table <b>813</b>, according to one aspect of the present invention. This register provides status on various ETD level events that cause hardware interrupts. When an ETD level event occurs, Host Controller <b>301</b> sets the corresponding bit in this register <b>812</b>. When a bit becomes set, a hardware interrupt is generated if the interrupt is enabled in the HcETDInterruptEnable register <b>814</b> and the INTH bit of ChipInterruptEnable is set. Host Controller Driver <b>201</b> may clear specific bits in this register by writing, e.g., ‘1’ to bit positions to be cleared. Host Controller Driver <b>201</b> may not set any of these bits.
HcETDInterruptEnable Register:
<figref idref="DRAWINGS">FIG. 8I</figref> shows HcETDInterruptEnable Register <b>814</b> and the various fields of HcETDInterruptEnable Register <b>814</b> are described in table <b>815</b>. Each enable bit in the HcETDInterruptEnable register <b>814</b> corresponds to an associated interrupt bit in the HcETDInterruptStatus register <b>814</b>. HcETDInterruptEnable register <b>814</b> is used to control ETD events and generate hardware interrupts. When a bit is set in HcETDInterruptStatus register <b>812</b> and HcETDInterruptEnable register <b>814</b>, a hardware interrupt is generated on the host bus.
Writing e.g., a ‘1’ to a bit in register <b>814</b> sets the corresponding bit, whereas writing a ‘0’ to a bit in this register leaves the corresponding bit unchanged. On read, the current value of this register is returned.
HcETDInterruptDisable Register:
<figref idref="DRAWINGS">FIG. 8K</figref> shows HcETDInterruptDisable register <b>816</b> with a description of various field in table <b>817</b>. Each disable bit in HcETDInterruptDisable register <b>816</b> corresponds to an associated interrupt bit in the HcETDInterruptStatus register <b>814</b>. HcETDInterruptDisable register <b>816</b> is coupled to HcETDInterruptEnable register <b>814</b>. Thus, writing e.g., a ‘1’ to a bit in this register <b>816</b> clears the corresponding bit in the HcETDInterruptEnable register <b>814</b>, whereas writing a ‘0’ to a bit leaves the corresponding bit in the HcETDInterruptEnable register <b>814</b> unchanged. On read, the current value of the HcETDInterruptEnable register <b>816</b> is returned.
HcAccessStartAddress Register:
HcAccessStartAddress register <b>818</b> as shown in <figref idref="DRAWINGS">FIG. 8L</figref> specifies the physical start address of local memory <b>308</b> (ETD memory <b>308</b>A or Data <b>308</b>A) that processor <b>101</b> accesses. Table <b>819</b> describes the plural fields shown for register <b>818</b>.
HcXYBufferFilledStatus Register:
<figref idref="DRAWINGS">FIG. 8M</figref> shows HcXYBufferFilledSet register <b>820</b> and table <b>821</b> describes the various fields. HcXYBufferFilledSet register <b>820</b> value indicates the current status (filled or not) of X/Y buffer (<figref idref="DRAWINGS">FIG. 6A</figref>) of an endpoint. When data is transferred from system memory <b>102</b>, in the PIO mode, microprocessor <b>101</b> sets FnX (FnY) by writing e.g., a ‘1’ into the FSnX (FSnY) bit of the HcXYBufferFilledSet register <b>820</b>, when the X (Y) mega-buffer is full. In the DMA mode, Host Controller <b>301</b> sets FnX (FnY) when the X (Y) buffer is full. Host Controller <b>301</b> clears FnX (FnY) when all the packets in the buffer have been sent on the USB bus.
For incoming data from a USB device, Host Controller <b>301</b> sets FnX (FnY) when it has received NP packets from the USB bus and saved them into the X (Y) buffer. FnX (FnY) is cleared by microprocessor (PIO mode)<b>101</b> by writing a ‘1’ into the FCnX (FCnY) bit of the HcXYBufferFilledClear register <b>824</b>, or Host Controller <b>301</b> clears the register when all the packets inside the buffer have been transferred to the system memory.
HcXYBufferFilledSet Register:
<figref idref="DRAWINGS">FIG. 8N</figref> shows HcXYBufferFilledSet register <b>822</b> and table <b>823</b> describes the various fields associated therewith. Host Controller Driver <b>202</b> uses this register to set the FnX (FnY) bit of an OUT endpoint when the X (Y) buffer is full. In DMA mode, Host Controller <b>301</b> sets FnX (FnY) when the X (Y) buffer is full. For an OUT endpoint, writing e.g., a ‘1’ to FSnX (or FSnY) sets the corresponding bit in HcXYBufferFilled register <b>822</b>. Writing a ‘0’ has no effect.
HcXYBufferFilledClear Register:
<figref idref="DRAWINGS">FIG. 80</figref> shows HcXYBufferFilledClear register <b>824</b>, while table <b>824</b>A describes the various associated fields. Host Controller Driver <b>202</b> uses this register to clear the FnX (FnY) bit of an IN endpoint when the X (Y) buffer has been read. In DMA mode, the Host Controller <b>301</b> clears the FnX (FnY) value when the X (Y) buffer has been read. Writing a ‘1’ to FCnX (or FCnY) clears the corresponding bit in HcXYBufferFilled register <b>820</b>, for an IN endpoint. Writing a ‘0’ has no effect. For an OUT endpoint, this register has no influence on the HcXYBufferFilled register <b>820</b>.
HcETDEnableSet Register:
<figref idref="DRAWINGS">FIG. 8P</figref> shows HcETDEnableSet register <b>825</b> and table <b>826</b> describes the various associated fields. HcETDEnableSet register <b>825</b> individually enables one or several ETDs, by writing a ‘1’ into the corresponding bit of the ETDs to be enabled.
HcETDEnableClear Register:
<figref idref="DRAWINGS">FIG. 8Q</figref> shows the various fields in HcETDEnableClear register <b>827</b> and table <b>828</b> describes those fields. HcETDEnableClear register <b>827</b> individually disables one or several ETDs, by writing e.g., a ‘1’ into the corresponding bit of these ETDs to be disabled. Host Controller Driver <b>202</b> can use this register to stop the execution of an ETD before the ETD is retired. However, if a transaction is in process it will be finished. The clearing of this bit takes effect at the latest at the next SOF.
HcETDEnableStatus Register:
<figref idref="DRAWINGS">FIG. 8R</figref> shows the various fields of HcETDEnableStatus register <b>829</b> that are described in table <b>830</b>. HcETDEnableStatus register <b>829</b> is a read-only register and indicates the enabled ETDs. An ETD is enabled when its corresponding bit in HcSetEnableETD register is e.g., ‘1’. An ETD is disabled when its corresponding bit in HcSetEnableETD register <b>825</b> is ‘0’.
HcDirectRouting Register:
<figref idref="DRAWINGS">FIG. 8S</figref> shows the various fields of HcDirectRouting Register <b>831</b> which are described in table <b>832</b>. If two devices are connected to host <b>100</b>A, and one has an IN endpoint and the other has an OUT endpoint of same size, then the data from the IN endpoint can be directly routed to the OUT endpoint, through local memory <b>308</b>. Data does not need to go to the system memory <b>102</b>. The direct-routing is done by programming two TDs with the same location, and linking the HcXYFilled registers <b>822</b>.
HcXY Filled register:
Source: X|Yfilled is set by Host Controller <b>301</b> when full. It is cleared on the falling edge of the X|Yfilled of the sink.
Sink: X|Yfilled is set by Host Controller <b>301</b> on the rising edge of X|Yfilled of the source. When the X|Y buffer is consumed, X|Yfilled is cleared by Host Controller <b>301</b>.
HcmmediateInterruptETDs Register:
<figref idref="DRAWINGS">FIG. 8T</figref> shows the various fields of HcImmediateInterruptETD register <b>833</b>, and the fields are described in table <b>834</b>. HcImmediateInterruptETD register <b>833</b> contains identification of ETDs. The retirement of ETDs triggers an interrupt to the CPU <b>101</b>, regardless its original DelayInterrupt setting, and the interrupt counter.
One example is to set the control endpoint Setup ETD as the ImmediateInterruptEnabler. When it is retired, an immediate interrupt is generated, so that the system processor <b>101</b> can enable the Data phase or the Status phase of the control endpoint immediately, instead of having to wait until next frame.
HcDoneQueue Register:
<figref idref="DRAWINGS">FIG. 8U</figref> shows the various fields of HcDoneQueue register <b>835</b> and table <b>836</b> describes those fields. HcDoneQueue register <b>835</b> contains identification of all TDs completed since the last DI induced interrupt.
HcFmInterval Register:
<figref idref="DRAWINGS">FIG. 8V</figref> shows the various fields of HcFmInterval register <b>837</b> and table <b>838</b> describes those fields. HcFmInterval register <b>837</b> contains a certain vaue, e.g., a 14-bit value which indicates the bit time interval in a Frame, (i.e., between two consecutive SOFs), and a 15-bit value indicating the Full Speed maximum packet size that Host Controller <b>301</b> may transmit or receive without causing scheduling overrun. Host Controller Driver <b>202</b> may carry out minor adjustment on the FrameInterval by writing a new value over the present one at each SOF. This allows Host Controller <b>301</b> to synchronize with an external clocking resource and to adjust any unknown local clock offset.
HcFmRemaining Register:
<figref idref="DRAWINGS">FIG. 8W</figref> shows the various fields of HcFmRemaining register <b>839</b> and table <b>840</b> describes those fields. HcFmRemaining register <b>839</b> is a 14-bit down counter showing the bit time remaining in a current Frame.
HcFmNumber Register:
<figref idref="DRAWINGS">FIG. 8X</figref> shows the various fields of HcFmNumber register <b>841</b> and table <b>842</b> describes those fields. HcFmNumber register <b>841</b> includes a counter, e.g., a 16-bit counter. It provides a timing reference among events happening in Host Controller <b>301</b> and Host Controller Driver <b>202</b>. Host Controller Driver <b>202</b> may use the 16-bit value specified in this register and generate, e.g., a 32-bit frame number without requiring frequent access to the register.
HcLSThreshold Register:
<figref idref="DRAWINGS">FIG. 8Y</figref> HcLSThreshold register <b>843</b> contains e.g., a 11-bit value used by the Host Controller to determine whether to commit to the transfer of a maximum LS packet before EOF (<figref idref="DRAWINGS">FIG. 2</figref>).
Root Hub Partition:
All the foregoing are dedicated to USB Root Hub <b>309</b> (or <b>104</b>) which is an integral part of the Host Controller though still a functionally separate entity. Host Controller Driver <b>202</b> emulates USB device accesses to the Root Hub via a register interface. Host Controller Driver <b>202</b> maintains many USB-defined hub features which are not required to be supported in hardware. For example, the Hub's Device, Configuration, Interface, and Endpoint Descriptors are maintained only in the Host Controller Driver <b>202</b> as well as some static fields of the Class Descriptor. Host Controller Driver <b>202</b> also maintains and decodes the Root Hub's device address as well as other trivial operations which are better suited to software than hardware.
Root Hub register interface is developed to maintain similarity of bit organization and operation to typical hubs that are found in the system. Below are four register definitions: HcRhDescriptorA, HcRhDescriptorB, HcRhStatus, and HcRhPortStatus[1:NDP]. Each register is read and written as a Dword. These registers are only written during initialization to correspond with the system implementation. The HcRhDescriptorA and HcRhDescriptorB registers are implemented such that they are writeable regardless of the HC USB state. HcRhStatus and HcRhPortStatus must be writeable during the U<smallcaps>SB</smallcaps>O<smallcaps>PERATIONAL </smallcaps>state.
HcRhDescriptorA Register:
<figref idref="DRAWINGS">FIG. 8Z</figref> describes the various fields of HcRhDescriptorA register <b>845</b> and table <b>846</b> describes those fields. HcRhDescriptorA register <b>845</b> is the first register of describing the characteristics of Root Hub <b>309</b>A or <b>104</b>. Reset values are implementation-specific. The descriptor length (11), descriptor type, and hub controller current (0) fields of the hub Class Descriptor are emulated by host driver <b>202</b>. All other fields are located in the HcRhDescriptorA <b>845</b> and HcRhDescriptorB <b>847</b> registers.
HcRhDescriptorB Register:
<figref idref="DRAWINGS">FIG. 9A</figref> describes the various fields of HcRhDescriptorB register <b>847</b> and table <b>848</b> describes those fields. HcRhDescriptorB register <b>847</b> is the second register describing the characteristics of the Root Hub. These fields are written during initialization to correspond with the system implementation. Reset values are implementation-specific.
HcRhStatus Register:
<figref idref="DRAWINGS">FIG. 9B</figref> describes the various fields of HcRhStatus register <b>849</b> and table <b>850</b> describes those fields. HcRhStatus register <b>849</b> is divided into two parts. The lower word of a Dword represents the Hub Status field and the upper word represents the Hub Status Change field. Reserved bits should always be written ‘0’.
HcRhPortStatus[0:NDP] Register
<figref idref="DRAWINGS">FIG. 9C</figref> describes the various fields of HcRhPortStatus[1:NDP] register <b>851</b> and table <b>852</b> describes those fields. HcRhPortStatus[1:NDP] register <b>851</b> is used to control and report port events on a per-port basis. NumberDownstreamPorts represents the number of HcRhPortStatus registers <b>851</b> that are implemented. The lower word is used to reflect the port status, whereas the upper word reflects the status change bits. Some status bits are implemented with special write behavior. If a transaction (token through handshake) is in progress when a write to change port status occurs, the resulting port status change must be postponed until the transaction completes. Reserved bits should always be written ‘0’.
In yet another aspect, the present invention provides a method for transferring data between a host system and a USB Host Controller, comprising of setting up an ETD table, wherein the ETD table is set up by the host system and then loaded into a memory storage device at the USB Host Controller; scanning all ETDs at a start of frame of the ETD to determine isochronous endpoints; and executing the ETDs for isochronous endpoints.
In yet another aspect of the present invention, each ETD may be individually programmed for DMA or PIO mode. When an ETD is removed, the associated DMA channel is also dissolved. When the ETD is put on a DoneQueue, the corresponding working mode bit is also cleared. This means that the DMA channel association exists at the ETD (transfer) level. The freed DMA channel can be used for the next ETD of the same endpoint, or for another ETD. Hence, DMA channels are efficiently used to transfer data.
In yet another aspect of the present invention, the foregoing buffering techniques has advantages because it allows Host Controller to transfer data efficiently. For an endpoint working in the PIO mode, very few interrupts are required. For isochronous endpoint, packet size varies, and the adaptive nature of the present invention allows varying the size of number of packet per buffer and the size of the foregoing mega-buffers.
In yet another aspect of the present invention, local memory buffers may be programmed based on packet size and hence overrun and underrun situation can be handled efficiently.
In yet another aspect of the present invention, The ED format is the same for all endpoints, while the TDs may be different and packets are programmed accordingly. This reduces overhead between the host and Host Controller.
In yet another aspect of the present invention, since ETDs are written into local memory at the Host controller level, no special bus mastering is required. Also, only active ETDs are placed in local memory and hence they can be executed efficiently.
In yet another aspect of the present invention, since ETDs are transferred from local memory, system bus resources are used for other functions.
In yet another aspect of the present invention, the system is scalable based on local memory size and hence less taxing on address buses.
While the present invention is described above with respect to what is currently considered its preferred embodiments, it is to be understood that the invention is not limited to that described above. To the contrary, the invention is intended to cover various modifications and equivalent arrangements within the spirit and scope of the appended claims.
Contents6
46 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15 Sheet 16 Sheet 17 Sheet 18 Sheet 19 Sheet 20 Sheet 21 Sheet 22 Sheet 23 Sheet 24 Sheet 25 Sheet 26 Sheet 27 Sheet 28 Sheet 29 Sheet 30 Sheet 31 Sheet 32 Sheet 33 Sheet 34 Sheet 35 Sheet 36 Sheet 37 Sheet 38 Sheet 39 Sheet 40 Sheet 41 Sheet 42 Sheet 43 Sheet 44 Sheet 45 Sheet 46
Every citation, both waysCites: the store holds 5 of 6
| Document | Relation | Office | Cited during |
|---|---|---|---|
| US2006184708A1 | Cited by | United States of America | Pre-grant |
| US2016224493A1 | Cited by | United States of America | Pre-grant |
| US7849210B2 | Cited by | United States of America | Search report |
| US2015127859A1 | Cited by | United States of America | Pre-grant |
| US2004073697A1 | Cited by | United States of America | Pre-grant |
| US2004181601A1 | Cited by | United States of America | Pre-grant |
| US2007233908A1 | Cited by | United States of America | Pre-grant |
| US8904062B2 | Cited by | United States of America | Applicant |
| US7349973B2 | Cited by | United States of America | Search report |
| US2009254685A1 | Cited by | United States of America | Pre-grant |
| US2008159157A1 | Cited by | United States of America | Pre-grant |
| US2007011386A1 | Cited by | United States of America | Pre-grant |
| US8626963B2 | Cited by | United States of America | Applicant |
| US7562165B2 | Cited by | United States of America | Search report |
| GB2618707A | Cited by | United Kingdom | Search report |
| US2003200360A1 | Cited by | United States of America | Pre-grant |
| US2007022204A1 | Cited by | United States of America | Pre-grant |
| US2015127859A1 | Cited by | United States of America | Search report |
| US2008162753A1 | Cited by | United States of America | Pre-grant |
| CN112261117A | Cited by | China | Search report |
| WO2013002839A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| US2005135062A1 | Cited by | United States of America | Pre-grant |
| WO2023142301A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| US12461874B2 | Cited by | United States of America | Search report |
| US7747808B2 | Cited by | United States of America | Search report |
| US7281074B2 | Cited by | United States of America | Search report |
| US2024045819A1 | Cited by | United States of America | Search report |
| US7987302B2 | Cited by | United States of America | Search report |
| US7631097B2 | Cited by | United States of America | Search report |
| US2009259786A1 | Cited by | United States of America | Pre-grant |
| CN114265806A | Cited by | China | Search report |
| US2009100201A1 | Cited by | United States of America | Pre-grant |
| US2008133823A1 | Cited by | United States of America | Pre-grant |
| US10929332B2 | Cited by | United States of America | Search report |
| US2005267998A1 | Cited by | United States of America | Pre-grant |
| US7581072B2 | Cited by | United States of America | Search report |
| US2008288669A1 | Cited by | United States of America | Pre-grant |
| US2008162737A1 | Cited by | United States of America | Pre-grant |
| CN112514332A | Cited by | China | Search report |
| GB2618707B | Cited by | United Kingdom | Search report |
| US2007005859A1 | Cited by | United States of America | Pre-grant |
| CN111290983A | Cited by | China | Search report |
| CN111797052A | Cited by | China | Search report |
| US10331594B2 | Cited by | United States of America | Search report |
| US2008163012A1 | Cited by | United States of America | Pre-grant |
| US2006282619A1 | Cited by | United States of America | Pre-grant |
| US7469304B2 | Cited by | United States of America | Search report |
| US7802034B2 | Cited by | United States of America | Applicant |
| US6047339A | Cites | United States of America | Search report |
| US6421770B1 | Cites | United States of America | Search report |
| US6553460B1 | Cites | United States of America | Search report |
| US6643755B1 | Cites | United States of America | Search report |
| US6718445B1 | Cites | United States of America | Search report |
| USB Specification 2.0, Apr. 27, 2000, pp. 58-65. | Non-patent | – | Search report |
| USB Specification 2.0, Apr. 27, 2000, pp. 58-65. | Non-patent | – | Search report |
2 members in 1 office
Priority claims6
| Document | Office | Kind | Date |
|---|---|---|---|
| 27709301 | United States of America | P | |
| 27709301 | United States of America | P | |
| 10048202 | United States of America | A | |
| 60277093 | – | – | – |
| US20010277093P | – | – | – |
| US20020100482 | – | – | – |
Members2
| Document | Office | Kind | |
|---|---|---|---|
| US7035948B1This record | United States of America | B1 | |
| US7409476B1 | United States of America | B1 |
44 transactions on the USPTO file
Allowed after 1 non-final rejection, 1 final rejection and 1 RCE.
- Non-final rejections
- 1
- Final rejections
- 1
- RCEs
- 1
- Appeals
- 0
Over time
Point at a mark for the transactionTransactions
| Event | Code | |
|---|---|---|
| Entity status set to undiscounted (initial default setting or status change) | – | |
| Entity Status Set To Undiscounted (Initial Default Setting or Status Change)BIG. | BIG. | |
| Expire PatentEXP. | EXP. | |
| Correspondence Address ChangeC.ADB | C.ADB | |
| Recordation of Patent Grant MailedPGM/ | PGM/ | |
| Patent Issue Date Used in PTA CalculationAllowedPTAC | PTAC | |
| Issue Notification MailedAllowedWPIR | WPIR | |
| Dispatch to FDCD1935 | D1935 | |
| Application Is Considered Ready for IssuePILS | PILS | |
| Issue Fee Payment VerifiedN084 | N084 | |
| Issue Fee Payment ReceivedIFEE | IFEE | |
| Workflow - Drawings FinishedDRWF | DRWF | |
| Mail Notice of AllowanceAllowedMN/=. | MN/=. | |
| Notice of Allowance Data Verification CompletedAllowedN/=. | N/=. | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Date Forwarded to Examiner | – | |
| Date Forwarded to Examiner | – | |
| Disposal for a RCE / CPA / R129AbandonedABN9 | ABN9 | |
| Request for Continued Examination (RCE)RCEX | RCEX | |
| Request for Extension of Time - GrantedXT/G | XT/G | |
| Workflow - Request for RCE - BeginBRCE | BRCE | |
| Mail Final Rejection (PTOL - 326)Final rejectionMCTFR | MCTFR | |
| Final RejectionFinal rejectionCTFR | CTFR | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Non-Final ActionA... | A... | |
| Mail Notice of Informal or Non-Responsive AmendmentNINA | NINA | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Informal or Non-Responsive Amendment after Examiner ActionA.I. | A.I. | |
| Response after Non-Final ActionA... | A... | |
| Request for Extension of Time - GrantedXT/G | XT/G | |
| Mail Examiner Interview Summary (PTOL - 413)MEXIN | MEXIN | |
| Interview Summary RecordEXIN | EXIN | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| IFW TSS Processing by Tech Center CompleteTSSCOMP | TSSCOMP | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Correspondence Address ChangeC.AD | C.AD | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Application Dispatched from OIPEOIPE | OIPE | |
| Application Is Now CompleteCOMP | COMP | |
| IFW Scan & PACR Auto Security Review | – | |
| Initial Exam Team nnIEXX | IEXX |
12 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Lapsed due to failure to pay maintenance feeLapsedFP | FP | |
| Information on status: patent discontinuationPATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362STCH | STCH | |
| Information on status: patent discontinuationPATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362STCH | STCH | |
| Lapse for failure to pay maintenance feesLapsedLAPS | LAPS | |
| Fee payment procedurePAT HOLDER NO LONGER CLAIMS SMALL ENTITY STATUS, ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: STOL); ENTITY STATUS OF PATENT OWNER: LARGE ENTITYFEPP | FEPP | |
| Maintenance fee reminder mailedREMI | REMI | |
| AssignmentAS | AS | |
| Fee paymentFPAY | FPAY | |
| Surcharge for late paymentSULP | SULP | |
| Maintenance fee reminder mailedREMI | REMI | |
| AssignmentAS | AS | |
| AssignmentAS | AS |
Numbers
- Publication
- 07035948
- Publication, DOCDB
- 7035948
- Publication, EPODOC
- US7035948
- Application
- 10100482
- Application, DOCDB
- 10048202
- Application, EPODOC
- US20020100482
Titles
- English
- System and method for USB controllers
Patent term adjustment
- A delay
- +408 daysthe office missed an examination deadline
- Applicant delay
- −242 days
- Net adjustment
- 166 days
Classification
- CPC, 2
- G06F13/28
- G06F13/385
- IPC, 1
- G06F3 00
- USPC, 4
- 710056000
- 710052000
- 710053000
- 710310000