USB data serializer

[0002] The invention relates to data Input/Output (I/O) interfaces, and particularly the invention relates to the Universal Serial Bus (USB) and utilizing data intended for USB devices with non-USB devices.

[0003] The Universal Serial Bus (USB) is a well-known standard in the computer design and related industries. The USB bus is designed to be a user-friendly interface used to connect a personal computer (PC), including a laptop and like devices, to various external peripherals, e.g., a speaker, mouse, or keyboard. USB allows users to “hot-plug” (or “hot-swap”) a device into a USB connector and be assured that the device will be recognized by the Operating System (OS) of the PC without conflict with other devices. More specific information regarding the USB standard is available in the Universal Serial Bus Specification, Rev. 1.0 (Jan. 15, 1996), available on the World Wide Web at www.usb.org and incorporated herein by reference.

[0004] An example of a system 100 that may utilize the USB standard is shown in the functional block diagram of FIG. 1. FIG. 1 shows a processor 102 coupled to a host bus 106, and a memory 104, e.g., RAM, coupled to a memory bus 107. The host bus 106 and memory bus 107 are each in turn coupled to a system controller 108. In some systems, the system controller is referred to as a “chipset.” The system controller 108 interfaces the processor to various peripheral devices in the system. The peripheral devices in the system are coupled to one or more “system buses.” For instance, some peripherals 112, 114, such as a disk drive controller, may reside on an ISA bus 109 (an Industry Standard Bus). Other peripherals 118, 120 reside on the PCI bus 110, which is a newer and generally the more favored standard system bus compared to ISA. Both the ISA standard and PCI standard are well-known in the art. A USB interface controller 124 is also coupled to the PCI bus 110. The USB interface controller 124 is couplable to a USB peripheral device 132, which is typically detachable from the USB interface 124.

[0005] A more detailed example of a USB interface controller unit 124 is shown in the block diagram of FIG. 2. USB interface controller 124 includes a host controller 140 coupled to the PCI or other system bus 110. The host controller 140 interfaces unit 124 to system bus 110, communicating data to and from a host system memory (e.g., memory 104) and controlling the flow of that data through USB interface controller 124. The host controller 140 transmits data to serial interface engine (SIE) 142. SIE 142 converts the data received in parallel format into a serial format and also formats the data, including any necessary framing, in accordance with the USB specification.

[0006] Once serialized and formatted, data is passed to a port 146 or 148. As shown, a USB interface controller may have multiple ports, e.g., 146, 148.

[0007] When serial data is received by ports 146 or 148 from a USB peripheral device, the data is passed to SIE 142, which decodes the data, i.e., extracts the raw data, and converts the raw data into a parallel format. SIE 142 then transmits the raw data to host controller 140, which ultimately communicates the data to host system 100.

[0008] As indicated on ports 146, 148 the USB interface controller 124 utilizes a two-wire differential signaling technique. Each port produces a positive signal 150 and a related negative signal 152, both of which are transmitted to a connected USB peripheral device 132. Because of this differential signaling technique as well as the long cables often utilized with USB peripheral devices (e.g., up to 5 meters), the ports on both the USB interface controller and USB peripheral devices are complex and expensive, requiring complex analog circuits with programmable drive strength and rise/fall characteristics. Such complex ports also tend to be physically large, consuming considerable die space compared with ports used with other buses and/or bus standards.

[0009] An example of a USB peripheral device 132 is shown in the block diagram of FIG. 3 as a USB speaker. Of course other USB peripheral devices are available, and a USB speaker is utilized for illustrative purposes only. The USB peripheral device 132 includes a differential port 160 and a Serial Interface Engine (SIE) 162. The port 160 and SIE 162 are similar to those found on the USB interface controller 124 on host system 100 and will be found in almost all types of USB peripheral devices. Once received, the SIE 162 decodes the signal and outputs raw data to CODEC 164, which performs analog conversion and otherwise prepares the data for transmission to speaker 166.

[0010] Although the USB standard includes the benefit of being user-friendly, supporting the USB standard consumes not only considerable real estate, e.g., to support the USB data formatting protocol as well as differential signaling, but also consumes considerable power, where both factors contribute to escalating PC costs. In the laptop market, where devices must not only be physically small, but must also consume relatively small amounts of power and still remain at a competitive price, these factors are significant obstacles.

[0011] Moreover, many vendors and consumers are demanding that PCs and PC-like devices support various amenities such as sound. For these reasons, various operating system and software developers are developing the software, including device drivers, to support USB peripheral devices and are demanding of PC and PC-like device manufacturers that a “user-friendly” USB interface controller be in place to provide an easy-to-use environment for end-users. A system that attempts to save power, real estate, and/or ultimate cost by sacrificing the USB interface controller will be at a disadvantage in that various vendors software will not be operable with or permitted to be operated with such systems.

[0012] Therefore, it is desirable to develop a method of utilizing the USB bus interface to the host system, but minimizing the costs of doing so in terms of real estate, power, and expense. To do so, a system and method is disclosed that emulates a USB peripheral device. Such a system is referred to herein as a USB Data Serializer (UDS) and interacts with the host system bus in a manner similar to that done by a host controller in a conventional USB interface controller. In other words, the UDS utilizes a system bus interface that appears to the host identical to a conventional USB system bus interface to communicate with the host. Instead of being couplable to a USB peripheral device, however, the UDS is couplable to non-USB devices, such as TTL devices for example. The UDS further includes a data formatter, which in many embodiments is programmable. The data formatter formats, or translates, data received from the host system bus via the system bus interface into a format usable by the non-USB device. Such format can be virtually any format and is determined only by which non-USB device is intended to be coupled to the system.

[0013] The UDS further includes a stored USB device identifier. This identifier is programmable in some embodiments. The USB device identifier is provided to the host system. The host system responds by configuring the system to operate with the identified USB device. The host system then communicates with the UDS in the same way it communicates with a USB interface controller, i.e., software that is used with USB devices in the host is still used. The UDS then formats the information received for use by the non-USB device. Likewise, when the UDS receives information from the non-USB peripheral device, the UDS de-formats the data and provides it through the system bus interface to the host system.

[0014] Thus, by use of a system and method in accordance with the invention, non-USB peripheral devices can be used with systems designed to interact with USB peripherals. Such a system will demand less real estate, less power, and will cost less than its USB counterpart, making such a system particularly useful in laptop and portable PC and PC-like devices.

[0015] The invention will be described with respect to particular embodiments thereof, and reference will be made to the drawings in which like numbers designate like parts and in which:

[0016] FIG. 1 is a functional block diagram of a system designed for interaction with USB peripheral devices;

[0017] FIG. 2 is a functional block diagram of a USB interface control unit 124;

[0018] FIG. 3 is a functional block diagram of a USB peripheral device;

[0019] FIG. 4 is a functional block diagram of a USB interface control unit, shown in more detail than FIG. 2;

[0020] FIG. 5 is a functional block diagram of one embodiment of a system in accordance with the invention;

[0021] FIG. 6 is a functional block diagram of a second embodiment of a system in accordance with the invention;

[0022] FIG. 7 is a functional block diagram of a third embodiment of a system in accordance with the invention; and

[0023] FIGS. 8A-8C are functional block diagrams of various ways to implement a speaker, including a non-USB, non-UDS method, a USB method, and a UDS method in accordance with the invention.

[0024] To overcome the disadvantages discussed above, the invention takes advantage of the USB software interface, such as that developed by Intel (UHCI) or Compaq (OHCI), but does not require use of the relatively high-cost differential signaling interface of USB. A system in accordance with the invention, is often referred to herein as a USB Data Serializer (UDS), and is designed to emulate a USB device. By emulating a USB device, the UDS can support various non-USB devices, but the OS interacts with the UDS as if a USB peripheral device were in fact coupled to the system.

[0025] Before getting into the details of a UDS system in accordance with the invention, reference is first made to FIG. 4 and a particular implementation of a USB interface controller unit, such as USB interface controller unit 124 shown in FIG. 1. FIG. 4 is similar in many respects to FIG. 2, however host controller 140 is set out more specifically and other details are shown. Hence the system shown in FIG. 4 is referenced by 124′.

[0026] As shown in FIG. 4, PCI bus 110 (or other system bus) is coupled to bus master 170. Bus master 170 is used to aid in arbitration for and gain access to PCI bus 110. Bus master 170 can engage in DMA transfers over the PCI bus, obtaining various information from host system memory as well as delivering various information to be stored in host system memory (e.g., memory 104).

[0027] Bus master 170 is coupled to list processor 172. List processor 172 processes a linked list of the memory locations of the data that is to be transferred or where received data is to be placed and instructs the bus master 170 as to which address needs to be accessed.

[0028] Bus master 170 is further coupled to data buffer engine 174. Upon retrieving information from system memory, bus master 170 communicates that information to data buffer engine 174. Data buffer engine 174 is somewhat like a FIFO device, however it further includes flow control, so as to control the rate at which data is transferred to the USB SIE device 142. Likewise, data buffer engine 174 receives data from SIE 142 and acts as a FIFO and flow control device in the opposing direction, passing data to bus master 170, which ultimately arbitrates for PCI bus 110 access and delivers the information to system memory 104.

[0029] SIE 142 takes the raw data received in parallel from data buffer engine 174 and serializes that data. In addition, SIE formats the data into proper USB protocol format, including placing the data in appropriate frames with the appropriate flags inserted. More information with respect to the format of data in USB devices can be found in the USB specification discussed previously.

[0030] Once serialized and formatted, data is transferred from SIE 142 to a port, e.g., Port 1146. As shown in FIG. 4, USB interface controller unit 124′ can have one or more ports, and two ports 146 and 148 are shown in FIG. 4 for illustrative purposes. It is to be understood that more or fewer ports may be included in various implementations of USB interface controller units. Each port outputs the encoded serial data in a differential signal format having a positive line 150 and a negative line 152.

[0031] In addition, root hub control unit 176 is used to control the respective ports 146 and 148. Root hub control 176 may enable or disable each respective port and/or control the direction of data flow from the respective ports, among other functions.

[0032] USB interface device 124′ also includes several register banks. These register banks include PCI configuration registers 180, used to configure the device for use on a PCI bus in accordance with the PCI standard. As known in the art, PCI configuration registers are typically accessed once and include information about the device including whether it requires I/O or memory space and how much. Additionally, HC memory mapped registers 178 are included and are used to store various information and instructions required of the USB interface controller unit, such as the start and end addresses of the linked list of messages. The HC memory mapped registers appear to device 124′ as system memory, although access will be faster.

[0033] In operation upon power-up or upon “hot-plug” of a USB peripheral device, the host system sends a query to the USB peripheral device (not shown in FIG. 4), via the USB interface controller 124′, requesting device identification information. The USB peripheral device sends the information back through the USB interface device 124′ to the host system. When the host system receives the identifying information, it configures the system for operation with the respective peripheral by loading various device drivers and relaying other configuration information to the USB peripheral device via the USB interface device 124′. In this manner, when an end-user adds a USB peripheral device to his or her system, the end-user does not have to engage in any system configuration, making USB a user-friendly system.

[0034] However, as discussed previously, the differential ports 146, 148 in the USB devices are complex, requiring considerable die space as well as consuming considerable power. Therefore, it is desirable to eliminate the differential ports, especially for smaller PC systems such as laptops, and especially when both the USB controller 124 and USB peripheral device 132 are mounted on the same printed circuit board (PCB). However, because of vendor and end-user demand, it is still desirable to maintain compatibility with USB software, e.g., device drivers, on the host system.

[0035] To meet these desires, one embodiment of a system in accordance with the invention is shown in FIG. 5. FIG. 5 shows a Universal Data Serializer (UDS) 224, which can be used to replace USB interface controller 124 shown in FIG. 1. As seen in FIG. 5, many of the elements in UDS 224 are similar to those shown for USB device 124′ in FIG. 4, including bus master 170, list processor 172, data buffer engine 174, HC memory mapped registers 178, and PCI configuration registers 180. Although this and other embodiments of the invention are described as interacting with a PCI bus, it is to be understood that a PCI bus is used for illustrative purposes only and that an embodiment in accordance with the invention can interoperate with other types of system busses.

[0036] In addition, UDS 224 includes SIE 142, which is much the same as that shown in FIG. 4. Instead of SIE 142 being coupled to differential ports, however, SIE 142 is coupled to SIE 182. SIE 182 is generally similar to the SIE typically found in a USB peripheral device. Here, USB host side SIE 142 receives raw parallel data and then serializes and formats the data as would be done in a conventional USB system. The serialized and formatted data is transmitted to USB peripheral side SIE 182, which decodes the data, i.e., takes the data out of USB format. The raw serial data is communicated to programmable USB Emulation Unit 184. In one embodiment, both SIEs reside on the same logic device with no intervening differential circuitry.

[0037] The UDS 224 supports non-USB serial devices. These non-USB devices will generally not require differential signals and may be digital, e.g., TTL, devices. For instance, a UDS may be coupled to a TTL keyboard controller, a UART, or a CODEC. The UDS, therefore, in its programmable USB Emulation Unit 184, includes a data formatter 185. The data formatter 185 can place data into any programmed format, and is not limited to the USB protocol of passing data. One format, for example, could be that required for an AC97 CODEC. Another format would be that required for a non-USB mouse. In addition, the data formatter in many embodiments will convert data, if received in a parallel format, to a serial format. Some embodiments, however, will allow data to remain in a parallel format.

[0038] The data formatted by the programmable USB emulation unit 184 is conveyed to the port 188. In some embodiments, port 188 may simply be a buffer or one or more conductors if the non-USB device is on the same board as UDS 224. Alternatively, port 188 may be a connector for use with off-board devices.

[0039] Since the format required by the non-USB device could be almost any format known currently or in the future, on system power-up, programmable USB emulation unit 184 is programmed, for instance with a serial ROM device or by other methods, to be able to perform the formatting functions required. Programmable USB emulation unit could even be programmed to place data into the format specified by the USB specification.

[0040] In addition, in order to fully emulate a USB device, the host system needs to be able to query for and receive a valid USB identifier. To accomplish this task, UDS registers 186 are included in UDS 224 and are also programmed at power-up. These registers store a USB device identifier. For instance, if the non-USB device 190 is to be a mouse device, then UDS registers 186 are programmed with an identifier that corresponds to a USB mouse device. Hence, when the host operating system queries via device 224 for a USB device identifier, programmable USB emulation unit 184 intercepts the query and is designed and/or programmed to access UDS registers 186. Programmable USB emulation unit 184 retrieves the USB device identifier from UDS registers 186 and then transmits the identifier to the host system in the normal USB fashion. The host system loads the various device drivers which correspond to that USB identifier, e.g., USB mouse, and engages in any other tasks required for configuring the system for operation with (what the host “believes” to be) the identified USB device. When information is sent from the host system directed to the “USB mouse,” programmable interface 184 receives that information and formats the information in the appropriate format for the non-USB device, e.g., a non-USB mouse.

[0041] In this manner, the UDS device 224, emulates the presence of a USB peripheral device. By doing so, current USB software, including device drivers, do not have to be rewritten, but can be used with other non-USB devices, making a system without USB devices compatible with those operating systems designed to be used with USB devices. Moreover, because the operating system of the host system typically interacts with the UDS in the same manner as it would a USB interface controller 124, utilizing the same or similar registers (e.g., HC memory mapped registers and PCI configuration registers) and the same or similar host controller, no additional code needs to be used at the host system to support the interaction of the host system with the UDS other than what already exists to support USB. Further, the system of FIG. 5 eliminates the differential ports required by USB systems, minimizing real estate taken by such ports as well as power consumption. Still, as shown in FIG. 6, real estate consumption can be reduced still further by use of another embodiment of a system in accordance with the invention.

[0042] As shown in FIG. 6 this second embodiment of a UDS, designated 224′, utilizes most of the same elements as that shown in FIG. 5, however, the USB SIE units 142 and 182 have been eliminated. Hence, data received from data buffer engine 174 is provided directly to programmable USB emulation unit 184. Programmable USB emulation unit 184 includes a data formatter 185, which can be implemented in hardware, software, or firmware. Programmable USB emulation unit 184 formats the data, including any necessary serialization, into the appropriate format with formatter 185, typically not a USB format. The formatted data is passed to port 188, which ultimately conveys the information to non-USB device 190.

[0043] As in FIG. 5, port 188 in FIG. 6 may be a buffer, one or more conductors, and/or a connector. Further, although FIGS. 5 and 6 illustrate a UDS having only one port 188, it is to be understood that each of these devices can have one or more ports and that only one port is shown for purposes of illustration.

[0044] The system of FIG. 6 will act in much the same way as that in FIG. 5, except that the data will not be converted to the USB format unnecessarily. Such an implementation reduces the die space necessary for such a device, as well as minimizes power consumption. When the host system queries for the USB peripheral device identification, programmable USB emulation unit 184 is designed and/or programmed to retrieve such information from registers 186, which have been previously programmed or otherwise configured to include, among other things, a USB peripheral device identifier. Programmable USB emulation unit 184 will transmit the retrieved identifier back to the host system. The operating system will then load the device drivers that correspond to the USB device identifying information. For instance, if the identifying information is for a USB mouse the operating system will load a mouse driver. Or, if the identifying information is for USB speaker, a speaker driver will be loaded.

[0045] Upon receipt of information from the host intended for the identified USB device, the programmable USB emulation unit 184 formats the data into a format acceptable for the respective non-USB device coupled to it through port 188. Hence, the host system, upon querying the UDS 224 or 224′, will “see” a USB peripheral device. In fact, in accordance with one embodiment of the invention, the UDS interfaces to the PCI bus and host system in the same manner as would the host controller in a conventional USB interface controller (see FIGS. 1 and 2).

[0046] Therefore, using a UDS system, a variety of non-USB devices can be utilized. These devices may be legacy devices or may simply be lower in power than other available devices. Moreover, the USB device drivers can be utilized to support a considerable number of these non-USB devices.

[0047] Although not shown in FIGS. 5 and 6, a UDS in accordance with the invention can be designed, in some embodiments, to have multiple ports, and thus be couplable to multiple non-USB devices simultaneously. These non-USB devices may each demand data in a different format. In such situations, programmable USB emulation units may be designed in various embodiments to include multiple data formatters, each programmed to translate data into a different format. Multiple stored USB device identifiers will also be included. When the host sends information destined for a particular “USB device,” the programmable USB emulation unit will route the incoming data to the appropriate formatter.

[0048] Still another embodiment of the invention is shown in FIG. 7. The embodiment of the UDS device shown in FIG. 7 is a modification of the embodiment of FIG. 5, including bus master 170, list processor 172, and data buffer engine 174 (shown collectively in FIG. 7 as host controller logic 702), USB host side SIE 142, USB peripheral side SIE 182, programmable USB emulation unit 184, and non-USB port 188. In addition, UDS device 224″ includes one or more differential USB ports 704, 706 coupled to USB host side SIE 142 as well as one or more differential USB ports 708 coupled to the USB peripheral side SIE 182.

[0049] Ports 704, 706 coupled to USB host side SIE 142 allow device 224″ to additionally support USB peripheral devices in the conventional manner as described with respect to FIGS. 2.

[0050] Port 708 coupled to USB peripheral side SIE 182 allows peripheral devices to be coupled to the device 224′ in a manner such that these devices appear connected to the USB host controller of another system. For instance, as shown in FIG. 7, a second host system B includes a standard USB controller 124 including host controller logic 140, host side SIE 142, and differential ports 146 and 148, and is similar to that illustrated in FIG. 2. System B is connected to system A with a cable 710 capable of carrying differential signals. System B can now access non-USB devices attached to the UDS 224″ of system A, via USB peripheral side SIE 182 and programmable USB emulation unit 184.

[0051] Some of the advantages of a system in accordance with the invention are now described with respect to audio speaker support. FIG. 8A shows a conventional non-USB audio system. Audio controller 302 retrieves packed audio data from system memory 104 and/or from a long term storage device, such as a CD, via controller 108. The audio controller 302 unpacks the data and transmits it to a CODEC 304, which processes the data, including digital-to-analog conversion, for output to speaker 306. Generally, audio controllers 302 are expensive and consume considerable power, and are therefore undesirable in laptop systems. In addition, because of the industry move toward standardization and user-friendly systems many hardware vendors are suggesting that amenities, such as audio, be supported as USB devices.

[0052] FIG. 8B demonstrates support for a USB speaker. In FIG. 8b, packed audio data is retrieved, unpacked, and placed in memory 104 by processor 102. The unpacked data is fetched, via system controller 108, by USB interface controller unit 124. Using the SIE and differential port, the USB interface controller unit 124 places the data into USB serial format and sends it, via differential signaling, to USB speaker 308. The USB speaker receives and decodes the data with a differential port and an SIE 310. SIE 310 outputs the raw data to CODEC 312, which performs analog conversion and otherwise places the data in appropriate format for speaker 314. This USB method involves costly and complex components, both on the host side and device side, and usurps a considerable amount of system power, and is therefor also undesirable in laptop systems.

[0053] FIG. 8C demonstrates support for audio speakers using a UDS system in accordance with the present invention. Processor 106 retrieves and unpacks audio data and places the unpacked audio data in memory 104. The unpacked data is then transmitted, via system controller 108, to UDS 224. In UDS 224, programmable USB emulation unit 184, has previously been programmed (e.g., on power-up) to place data in a format appropriate for the particular audio application. UDS 224 serializes the data and formats it into the appropriate programmed format and then transmits the data to CODEC 316. CODEC 316, which in one embodiment is in accordance with the AC97 standard, processes the data and transmits it to speaker 318. Thus, the system is simple compared to USB, power consumption is minimized by avoiding use of audio controllers and by eliminating a differential signaling interface, while at the same time available real estate is maximized. The cost of systems utilizing UDS will also be minimized over the alternatives demonstrated in FIGS. 8A and 8B.

[0054] It is to be understood by those of skill in the art that the programmable USB emulation units and other aspects of a system in accordance with the invention illustrated and discussed with respect to FIGS. 5-7 can be implemented in hardware, software, firmware, or any combination thereof.

[0055] It should be understood that the particular embodiments described above are only illustrative of the principles of the present invention, and various modifications could be made by those skilled in the art without departing from the scope and spirit of the invention. Thus, the scope of the present invention is limited only by the claims that follow.