Controller for ATAPI mode operation and ATAPI driven universal serial bus mode operation and methods for making the same

[0002] 1. Field of the Invention

[0003] This invention relates generally to computer systems, and more particularly to circuitry for interfacing and controlling data transfers between computer systems and peripheral devices.

[0004] 2. Description of the Related Art

[0005] In recent years, computer manufacturers have been designing systems that provide users the ability to customize system features to match more closely their particular use requirements. Primarily, such customization has been made possible by the ease of connecting peripheral devices to a system. As is well known, a basic system typically includes a motherboard, a processor, random access memory (RAM), a hard drive, a floppy drive, a compact disc read-only memory (CD-ROM), a power supply and other miscellaneous circuitry. To enable users to further customize a system, the motherboard generally includes a number of connectors, such as, parallel port connectors, IDE connectors, and PCI connectors. Typically, IDE and PCI connectors are used to connect internal peripheral devices, and the parallel port connectors are used to connect external peripheral devices to the system. Generally, connections made by way of a parallel port connector are considered to be low-end connections which have significant performance limitations. On the other hand, connections made by way of PCI connectors utilize host adapter cards or controllers, which can provide communication using a higher-end SCSI protocol.

[0006] Although IDE and SCSI connections are commonly used for peripheral devices, a relatively new universal serial bus (USB) protocol has been gaining in popularity. Its popularity is particularly strong with casual computer users because the USB protocol is designed to more closely resemble a plug-and-play standard. That is, once a peripheral device is connected to a USB connector, that device will be ready for use without the typical setup and loading of drivers required for peripheral devices connected by way of other standards.

[0007] In response to USB's popularity, peripheral device manufacturers have been developing USB capable devices which meet the requirements set by the USB standard. The Universal Serial Bus Specification, revision 1.1 (1998), is hereby incorporated by reference. To meet the requirements of USB however, manufacturers have essentially been forced to redesign the logic circuitry of many of their existing peripheral devices. In essence, the advent of USB is requiring manufacturers to separately design peripheral devices which are able to function in parallel port mode, IDE/ATAPI mode, SCSI mode, and USB mode.

[0008] For ease of discussion, FIG. 1 illustrates a system diagram 10 including a computer system 12 and associated peripheral devices. The computer system 12 can have a number of peripheral devices, including an internal peripheral device 16aand connections to external peripheral devices, such as 16b. When the external peripheral device 16bis implemented, an external cable 14 is used to connect up to the computer system 12. Typically, the external cable 14 supports either a parallel port connection or a SCSI connection. As mentioned above, most internal peripheral devices are connected to the motherboard (now shown) of the computer system 12 by way of an IDE connector. Internal SCSI peripheral devices can also be used in the computer system 12, however, internal SCSI peripheral devices are typically more expensive and are generally only used in higher-end systems.

[0009] Accordingly, manufacturers of peripheral devices, such as optical disc-type peripheral recordable (CD-RW) devices), are required to specially design logic circuitry that is compatible with each specific data transfer protocol. As a result, each peripheral device, depending upon whether it is an internal device or an external device, needs to be uniquely designed to carry out the functions for the particular implementation.

[0010] To meet the specification requirements of USB, manufacturers of such peripheral devices are now integrating additional circuitry into peripheral devices that meet all of the required functionality and memory buffering necessary for USB data transfers. Although the design of specialized USB circuitry for those external peripheral devices is well known, when the manufacturer of peripheral devices design the circuitry for an external peripheral device, the internal peripheral device will have distinct logic circuitry to complete transfers using a different protocol, such as the IDE/ATAPI protocol. Consequently, the manufacturer of peripheral devices has now been driven to separately design, maintain, and revise the circuitry for USB external peripheral and internal IDE/ATAPI peripheral devices. As a result, the cost to the peripheral device manufacturer is substantially increased because the circuitry used for one protocol can not be used or shared by another protocol.

[0011] In view of the foregoing, there is a need for circuitry that can shared between different data transfer protocols, and can be enabled to operate in a selected protocol. There is also a need for logic circuitry that will enable one logic circuit design to be used interchangeably in internal peripheral device applications and external peripheral device applications.

[0012] Broadly speaking, the present invention describes peripheral device circuitry, and more particularly, controller circuitry that enables communication of peripheral devices using more than one communication protocol. In one embodiment, the controller circuitry is intelligently designed to implement communication in either an IDE/ATAPI mode or in a USB mode, and the controller circuitry utilized for USB mode operation is configured to share control circuitry used for IDE/ATAPI mode communication. It should be appreciated that the present invention can be implemented in numerous ways, including as a process, an apparatus, a system, a device, a method, or a computer readable medium. Several inventive embodiments of the present invention are described below.

[0013] In one embodiment, a controller for use in a mass storage peripheral device is disclosed. The controller includes a block decoder/encoder for processing data to and from a media of the mass storage peripheral device. Further included is an interface that is configured to process data and control signals for selectively communicating data to and from the mass storage peripheral device during operation in a first mode. Logic that is configured to process data and control signals for selectively communicating data to and from the mass storage peripheral device during operation in a second mode is also included. The logic is preferably configured to utilize data transfer control logic implemented by the interface.

[0014] In another embodiment, a controller for use in a compact disc peripheral device is disclosed. The controller includes a block decoder/encoder for processing data to and from a media of the compact disc peripheral device. An ATAPI interface is also provided and is configured to process data and control signals for selectively communicating data to and from the compact disc peripheral device during operation in an ATAPI mode. Universal serial bus (USB) logic is configured to process data and control signals for selectively communicating data to and from the compact disc peripheral device during operation in a USB mode. The USB logic is configured to utilize data transfer control logic implemented by the ATAPI interface. Accordingly, one controller can be integrated into either an external peripheral device that communicates over a USB connection in the USB mode, or into an internal peripheral device that communicates over an IDE connection in the ATAPI mode.

[0015] In yet another embodiment, a method for making a controller for use in a peripheral device is disclosed. The controller is capable to operating the peripheral device in one of an ATAPI mode and a universal serial bus (USB) mode. The method includes: (a) integrating an ATAPI interface to the controller, the ATAPI interface is configured to control data transfers to and from the peripheral device in the ATAPI mode; and (b) integrating a USB logic block to the controller, the USB logic block is configured to facilitate data transfers to and from the peripheral device in the USB mode, the USB logic block being configured to share data transfer control from the ATAPI interface to complete the data transfers in the USB mode.

[0016] In still another embodiment, a controller for use in a compact disc rewritable (CD-RW) peripheral device is disclosed. The controller includes a block decoder/encoder for processing data to and from a media of the CD-RW peripheral device. An ATAPI interface that is configured to process data and to control signals for selectively communicating data to and from the CD-RW peripheral device during operation in an ATAPI mode is also included. Universal serial bus (USB) logic is further provided to process data and control signals for selectively communicating data to and from the CD-RW peripheral device during operation in a USB mode. The USB logic is configured to utilize data transfer control logic implemented by the ATAPI interface. Preferably, the USB logic includes a USB pad cell that provides connection to and from a USB cable and the ATAPI interface. Part of the USB logic includes USB core logic that is in communication with the USB pad cell, the ATAPI interface, and a microprocessor interface.

[0017] In another embodiment, a controller for use in an optical storage device is provided. The controller includes a block decoder/encoder for processing data to and from a media of the optical storage device. An ATAPI interface is also provided and is configured to process data and control signals for selectively communicating data to and from the optical storage device during operation in an ATAPI mode. Universal serial bus (USB) logic is configured to process data and control signals for selectively communicating data to and from the optical storage device during operation in a USB mode. The USB logic is configured to utilize data transfer control logic implemented by the ATAPI interface. Accordingly, one controller can be integrated into either an external peripheral device that communicates over a USB connection in the USB mode, or into an internal peripheral device that communicates over an IDE connection in the ATAPI mode. The optical storage device can be any type of optical storage device, such as, for example a CD-RW, a CD-ROM, a CD-R, a DVD, and the like. Further, the optical storage device can be in the form of an internal or external peripheral device.

[0018] Other aspects and advantages of the invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, illustrating by way of example the principles of the invention.

[0019] The present invention will be readily understood by the following detailed description in conjunction with the accompanying drawings, in which like reference numerals designate like structural elements.

[0020] FIG. 1 illustrates a conventional system diagram including a computer system and associated peripheral devices.

[0021] FIG. 2 shows a block diagram of controller circuitry that is capable of being operated in either an IDE/ATAPI mode or a USB mode, in accordance with one embodiment of the present invention.

[0022] FIG. 3 illustrates in more detail the circuitry implemented by the block decoder/encoder, in accordance with one embodiment of the present invention.

[0023] FIG. 4 illustrates a more detailed block diagram of the application data transfer interface and the universal serial bus logic, in accordance with one embodiment of the present invention.

[0024] FIG. 5 illustrates a more detailed block diagram of the USB core logic of FIG. 4, in accordance with one embodiment of the present invention.

[0025] FIG. 6 illustrates how control signals of the ATAPI interface are selectively used to enable USB mode data transfers, in accordance with one embodiment of the present invention.

[0026] FIG. 7 illustrates a more detailed block diagram of the smart FIFO of FIG. 5, in accordance with one embodiment of the present invention.

[0027] An invention is described for peripheral device circuitry, and more particularly, controller circuitry that enables communication of peripheral devices using more than one communication protocol. In one embodiment, the controller circuitry is intelligently designed to implement communication in either an IDE/ATAPI mode or in a USB mode, and the controller circuitry utilized for USB mode operation is configured to share control circuitry used for IDE/ATAPI mode communication. It will be obvious, however, to one skilled in the art, that the present invention may be practiced without some or all of these specific details. In other instances, well known process operations have not been described in detail in order not to unnecessarily obscure the present invention.

[0028] FIG. 2 shows a block diagram of controller circuitry 100 that is capable of being operated in either an IDE/ATAPI mode or a USB mode, in accordance with one embodiment of the present invention. The controller circuitry 100 includes a block decoder/encoder 102 that is configured to communicate data to and from an optical storage media 18. The block decoder/encoder 102 is also configured to communicate with an application data transfer interface 104, a universal serial bus (USB) logic block 106, and a microprocessor interface 108. As used herein, the application data transfer interface 104 will also be referred to as an “ATAPI interface.”

[0029] The application data transfer interface 104 is configured to provide connection to an IDE/ATAPI connection 100a, and the universal serial bus logic 106 is configured to provide connection to a USB connection 100b. As will be described in greater detail below, the circuitry implemented to carry out the data transfers in a USB mode will share logic circuitry that is typically only used for IDE/ATAPI data transfers in prior art systems. Accordingly, the USB logic 106 is a more compact design because less USB dedicated circuitry will be needed to carry out the USB data transfers. This will also enable the fabrication of smaller controller chips, which has the direct benefit of lowering manufacturing costs. In addition, because one controller chip is capable of being used in either an IDE/ATAPI mode and a USB mode, there will be fewer controller chip designs to support and update by a peripheral device manufacturer. Further yet, optical storage devices can be made smaller, and also be more easily embodied in portable devices, while reducing cost of design and manufacturing.

[0030] Accordingly, the controller chip 100 is capable of either operating in accordance with an IDE/ATAPI data transfer mode or the USB mode. Thus, the controller chip 100 can be implemented in either internal peripheral devices such as compact disc recordables (CD-RW), as well as external peripheral devices. By way of example, when the controller chip 100 is integrated into an internal peripheral device, the controller chip 100 can be made to operate in the IDE/ATAPI mode. Although specific examples provided herein are with reference to CD-RW devices, it should be understood that the controller chip 100 can be integrated into any optical storage device. Examples of such optical storage devices can also include, but are not limited to, CD-ROMs, CD-Rs, digital video discs (DVDs), and the like.

[0031] When the controller chip 100 is integrated into an external peripheral device, the controller chip 100 can be enabled to communicate in the USB mode, and the communication in the USB mode will be performed utilizing data transfer logic that is standard to the IDE/ATAPI circuitry. As such, the USB logic 106 is very compact logic circuitry that borrows logic from the ATAPI logic to perform the USB data transfers. As will be appreciated by those skilled in the art, the ability to have a controller chip 100 that can be integrated into either external and internal peripheral devices, while at the same time limiting the amount of USB-only dedicated circuitry in the controller chip, will provide for substantial cost savings to peripheral device manufacturers. This cost saving is primarily due to the compact nature of the circuitry implemented in the controller chip 100 and the fact that the same controller chip 100 can be integrated into either external or internal peripheral devices, even when they implement different data transfer protocols.

[0032] FIG. 3 illustrates in more detail the circuitry implemented by the block decoder/encoder 102, in accordance with one embodiment of the present invention. As shown, a digital signal processor (DSP) of a decoder and an encoder, 112 and 126 respectively, are in communication with a plurality of pins 110. The plurality of pins 110 then communicate to analog circuitry that is configured to couple to a laser of the peripheral device for reading and writing data to and from the compact disc media. As mentioned above, the present disclosure provides specific examples related to optical disc peripheral devices (e.g., such as CD-RWs). However, it should be understood that the controller chip can be modified to work with any peripheral device to enable the shared logic advantages of the present invention.

[0033] In a specific example, during a read operation from an optical storage media 18, a decoder DSP 112 is configured to receive signals 110 and receive clock signals from an internal clock generator, such as a distal phase lock loop(DPLL) 114. The decoder DSP 112 then couples to a 4K RAM 116 that provides work space for error correction operations.

[0034] Block CIRC 118 is implemented for error correction and is suited for processing interleave data and code word generation. By way of example, CIRC 118 is configured to work on code words that consist of groups of 8 bits. The RAM 116 is coupled to a subcode interface 120 that has side-band information for the read path and decodes the subcode information coming off of the disc media.

[0035] The subcode interface 120 is also implemented during a writing operation. The subcode interface 120 is shown coupled to a buffer manager 122 that contains registers that have work space for the associated logic of the block decoder/encoder 102. The buffer manager 122 is also configured to communicate with a DRAM interface 160 which has external pins 162. The buffer manager 122 is also coupled to a phase lock loop (PLL) circuit 156. The buffer manager is in communication with a sector processor 134 that is configured to perform error correction and wrapping of raw data blocks. The sector processor is also configured to create or decode information for compact disc data (CD-DA) level information. A CD-DA interface 124 is configured to decode CD-ROM level information, such as user data or, if the disc has an executable program, perform the necessary decoding.

[0036] The CD-DA interface 124 is shown coupled to a 4K RAM 128. The RAM 128 is in communication with a CIRC 130 that provides codeword generation for the writing of data that is transferred to an encoder DSP 126, and then transferred to the laser for writing to the CD media. The encoder DSP 126 is also provided with a PLL 127. An audio block 132 is provided with pins 136 to communicate audio data to the peripheral device. The audio data of the peripheral device may be accessed by way of an audio jack on an external portion of a peripheral device. A user can then plug-in head phones for listening to audio data from the peripheral device.

[0037] A multiplexer 158 is provided to receive a path 117 from RAM 116 of audio data being decoded from the CD media. Also provided is a signal from the buffer manager 122 and a select signal (NXSYNC bit). When audio data is provided through path 117, the audio data is directed out to the audio block 132 at a 1×/2× speed. Alternatively, if audio data is provided from the buffer manager, the audio data is converted from nX to 1X and is then provided to the multiplexer 158 for output to the audio block 132 when appropriate.

[0038] An ATIP demodulator block 140 is also provided having a pin 138. The ATIP demodulator block 140 is configured to perform pre-groove demodulation, which enables reading of low-level encoding on an unrecorded disc media. The ATIP demodulator block 140 is in communication with the encoder DSP 126 and the spindle motor controller 146. The spindle motor controller 146 is configured to communicate with pins 148. Pins 148 therefore communicate with the motor that enables the spinning of the optical storage media 18. The spindle motor controller 146 communicates with the multiplexer 150 having a disc motor servo output (DMO) pin 151, and the CD servo unit 152 (i.e., spindle/focus/tracking/sled) also communicates with the multiplexer 150. The CD servo unit 152 communicates by way of pins 154 that control the movement of the laser. The decoder/encoder block 102 also includes a microprocessor interface 108 that has interconnection pins 109. Also shown is the buffer manager 122 in communication with the application data transfer interface 104. The application transfer interface 104 will be discussed in greater detail with respect to FIGS. 4 and 5 below.

[0039] To provide a more complete understanding of the respective signals shown in FIG. 3, reference can be made to Tables A through J, which are provided below. It should be understood however, that these signals are only exemplary and other signals may be added, subtracted, referenced by other conventions, or combined. However, the description of the signals will provide one of ordinary skill in the art with a more complete understanding of the functionality of the decoder/encoder block 102.

[0040] Table L below provides the pin type definitions for the pins described with reference to Tables A-K.

[0041] Referring now to FIG. 4, a more detailed block diagram of the Application Data 10 Transfer Interface 104 (i.e., ATAPI interface) is provided along with the universal serial bus logic 106. In this embodiment, the ATAPI interface 104 is shown in communication with the buffer manager 122 of FIG. 3. The ATAPI interface 104 also includes a plurality of pins which are configured to connect up to an IDE cable for transferring data to and from a host computer system. As shown, the pins include HDASP#, HA2, HA1, HA0, HPDIAG#, IOCS16#, HRRQ, DMACK#, HIORDY, HRD#, HWR#, HDRQ, HD[15:0], HRST#, ARST#, CS3FX#, and CS1FX#. These signals are defined in more detail in Table K.

[0042] As mentioned above, the USB logic 106 is configured to provide the controller 100 of FIG. 2 with the ability to function in either an IDE/ATAPI mode, or in a USB mode, depending upon what type of peripheral device the controller 100 is integrated with. The ATAPI interface 104 is shown in communication with a USB pad cell 202 by way of communication lines 223 and 225. Communication lines 223 and 225 connect to pins CS1FX# and CS3FX#, respectively. The USB pad cell 202 of the USB logic 106 is configured to provide an interface to a USB cable, for example, for providing data to and from a host computer system when in USB mode.

[0043] By way of example, the USB pad cell 202 has connections 212 and 214 for providing data to and from a host computer system by way of a USB cable. Connection 212 is shown for use with USB data+(DP) and is also part of pin CS3FX#. Connection 214 is configured for USB data−(DM) and is also configured to provide connection to CS1FX#. The USB pad cell 202 is also shown in communication with USB core logic 204. The communication with USB core logic 204 is by way of a bus 208 and a bus 210. In one embodiment, bus 208 is a 3-bit data bus that is configured to provide data received from a host computer through the USB cable to the USB core logic 204. The USB core logic 204 also communicates back to the USB pad cell by way of bus 210, which, in one embodiment, is also a 3-bit bus. The ATAPI interface 104 is also in communication with the USB core logic 204 by way of a bus 206.

[0044] When in USB mode, bus 206 is configured to provide a plurality of control signals from the ATAPI interface 104 to the USB core logic 204. Accordingly, bus 206 borrows signal circuitry from a plurality of the pins used in the ATAPI interface 104. These control signals 206 are therefore implemented by the USB logic 106 to perform data transfers during USB mode operation. Accordingly, the USB logic 106 is in essence, borrowing control signals from the ATAPI interface 104 to perform the USB data transfers without requiring additional USB-only logic circuitry in the USB logic 106.

[0045] Also shown is a bi-directional data bus 216, which is coupled between the ATAPI interface 104 and the USB core logic 204. The bus 216 is, in one embodiment, an 8-bit bus [0:7] that couples to a 16-bit data bus that is in communication with the ATAPI interface 104. The USB core logic 204 also makes use of the HDRQ signal 232 that is provided by the ATAPI interface 104. HDRQ signal 232 will inform the USB core logic 204 when data is available for a particular data transfer.

[0046] When the controller 100 is in the USB mode, the HA0 signal will provide the USB core logic with a 48 MHz clock input. Also, the CS3FX# pin and the CS1FX# will become USB Data+/− signals. At a higher level, the microprocessor controlling the controller 100 can provide a signal to switch the controller 100 to either be in an IDE/ATAPI mode or in the USB mode. The USB core logic 204 is also shown communicating with the ATAPI interface by way of a signals 230. In this embodiment, the signals 230 are those identified in FIG. 6, as the ATAPI PADS, which are part of the ATAPI interface 104. When in the ATAPI mode, these signals are driven in a normal ATAPI manner, however, when in the USB mode these ATAPI signals are modified for use in the USB mode. Finally, the USB core logic 204 is also configured to communicate with the microprocessor interface 108, by way of a bi-directional bus 220, control signals 222, and an interrupt signal 224. Signal 220 is a bus, which in this embodiment is an 8 bit wide bus that communicates with the microprocessor interface 108. Signal 222 on the other hand can be a microprocessor interface read/write signal.

[0047] FIG. 5 illustrates a more detailed block diagram of the USB core logic 204 of FIG. 4, in accordance with one embodiment of the present invention. The USB core logic 204 is configured to include a smart FIFO 250, an I/O select 252, an application 254, and a USB device controller (UDC) 256. In this embodiment, the smart FIFO 250 is in communication with the ATAPI interface 104 by way of data bus 216, which was described above to be an 8-bit bus. The ATAPI interface 104 is configured to communicate signal 232 HDRQ to the smart FIFO 250. The smart FIFO 250 is in communication with the I/O select 252 by way of control signals 268. Control signals 268 are configured to provide read/write control to the I/O select. The read/write control is initially transferred through the application 254 to the smart FIFO 250 by way of control signals 253.

[0048] The smart FIFO 250 is also in communication with the application 254 by way of an 8-bit bus illustrated as 258 and 260. The application 254 will include an enable register (ER) 274 that will signal to line 270 when the controller 100 should be placed into the USB mode. The I/O select will then appropriately set the circuitry to be in either the ATAPI mode or the USB mode depending upon the setting of the enable register within the application 254. The ER 274 will be set by a microprocessor that interfaces through the microprocessor 108. The application 254 is also in communication with the UDC 256 that is configured to perform packetizing and de-packetizing (e.g., otherwise known as de-serializing and serializing) of data that is being either transferred in or out by way of the USB pad cell 202. This packetizing is thus performed in accordance with the requirements of the USB specification.

[0049] When data is being transferred in through the USB pad cell 202, the data is passed through a 3-bit bus that is identified as lines 208a, 208b, and 208c, which are provided to the I/O select 252. Data that is provided by the USB pad cell 202 through the I/O select 252 is transferred to the UDC 256 by way of bus 266, that is also a 3-bit bus, in one embodiment. Data transferred out of the packetizer and to the USB pad cell 202 is transferred over bus 210, which is a 3-bit bus in this embodiment. Signal 267 is configured to inform the smart FIFO 250 when a packet has, in fact, been successfully transferred. Until a packet is successfully transferred, the data stored in the smart FIFO 250 will not be erased, thus being maintained in case a re-send or re-receive of a failed transfer is required.

[0050] The application 254 is in communication with the microprocessor 108 by way of signals 220, 222, and 224 as described above. As mentioned earlier, the ATAPI interface 104 provides control signals 206 to the USB core logic 204 by way of the I/O select 252. Accordingly, when the controller chip 100 is functioning in the USB mode, the USB core logic 204 will implement and borrow control signals from the ATAPI interface 104. These signals being borrowed from the ATAPI interface 104 are signals that would otherwise have to be custom integrated into standalone USB logic.

[0051] However, embodiments of the present invention enable the shared integration of such control signals implemented for ATAPI data transfers. The USB pad cell 202 is shown having connections 212 and 214 which provide connection to a USB cable 261. The USB cable 261 is configured to communicate with a host computer 203. The host computer can then request to write data to a CD media, or read data from the CD media by way of the same USB cable 261. It should be borne in mind that the present invention is applicable to peripheral devices other than CD media-type devices.

[0052] If the controller chip 100 is implemented to function in the IDE/ATAPI mode, then the ATAPI interface 104 will provide connection to, for example, an IDE cable 263 that can communicate to the host computer 203. In either event, the enable register (ER) that is part of the application 254 can be placed in an OFF state when ATAPI mode operation is desired. As described in greater detail in Appendix A, the enable register (R) is identified as “USBENBL.” When set to 1, the USB mode is enabled for a USB data transfer through the USB core logic 204. When set to 0, the ATAPI mode is enabled and USBCLK4X is disabled in the application 254. The default state of the enable register (ER) is 0 following hardware reset. Enable register (ER) determines which signals are driven off the chip on the common USB/ATAPI pins. The enable register also selects the ATAPI input pins or the USB logic data outputs to be driven to the block decoder/encoder 102. For more information on the enable register, reference should be made to the USB Control 2 Register, which is defined in Appendix A.

[0053] Once the enable register is set, a signal 270 is transferred from the application 254 to the I/O select 252. Reference is now made to FIG. 6, wherein selected control signals of the ATAPI interface 104 are selectively used to enable USB mode data transfers. The control signals 206 are also shown in FIG. 4. In this exemplary embodiment, HA2, HA1, and HA0 are set to logic level zero, which selects the data port. Signals DMACK#, HRD#, and HWR#, are set by way of smart FIFO 250. In this manner, these signals control data transfers for USB mode using ATAPI logic. In essence, signals DMACK#, HRD#, and HWR# fool the ATAPI logic into believing that it is performing an ATAPI data transfer, when in fact, the transfer is a USB data transfer. To complete USB mode operation, signal HRST# is set to a logic one, which places the signal inactive. Signals CS3FX# and CS1FX# are set to logic one and zero, respectively. Signals CS3FX# and CS1FX# therefore choose the data port.

[0054] In another embodiment of the present invention, verilog code is implemented to functionally define the setting of the controller 100 in either the USB mode or the ATAPI mode. Table L provides exemplary verilog code, which defines the setting of the controller 100 in the desired mode. It should be understood that the following code is only exemplary, and other suitable code may also be implemented to carry out the setting of the controller 100. In general, the settings are communicated by way of signals 206, which shows communication of such signals 206 to the I/O select 252 of FIG. 5.

[0055] FIG. 7 illustrates a more detailed block diagram of the smart FIFO 250, in accordance with one embodiment of the present invention. The smart FIFO 250 includes storage 302, which in this embodiment is a 64-by-8-bit addressable buffer. Of course, other suitable buffer types and sizes may also work. The storage 302 is in communication with a retry control 304, which contains pointer logic and counters for accessing the storage 302. As mentioned above, signal 267 is provided by the UDC 256 of FIG. 5 and is configured to inform the retry control when a packet has been successfully transferred. If the packet has not been successfully transferred, signal 267 will inform the retry control 304 which will then re-send or re-receive the packet that is stored in the storage 302. The retry control is also coupled to a sequencer 306, which coordinates the sequencing of packet data being transferred by way of the storage 302.

[0056] For discussion purposes, the block diagram of FIG. 7 will now be discussed with reference to performing writing of data to an optical storage media or reading data from the optical storage media. In general, a host computer system 203 can communicate to the USB pad cell 202 by way of a USB cable 261. When a write of data from the host computer 203 is desired, the data is transferred over the USB cable 261 and to the USB pad cell 202 by way of connections 212 and 214. Connections 212 and 214, which operate as Data+and Data−, are defined in greater detail in Chapter 7 of the USB Specification, which was incorporated by reference herein. The USB pad cell will then transfer the data by way of bus 208 that is, in this embodiment, a 3-bit bus. The data is transferred to the UDC 256 where the data is packetized (e.g., de-serialized) and transferred through line 264. The data is then transferred from the application 254 to the storage 302 by way of bus 258.

[0057] The data can then be transferred from the storage 302 implementing the retry control 304 and sequencer 306 to the ATAPI interface 104. Once the data is transferred to the ATAPI interface 104, the ATAPI interface 104 can then transmit the data to DRAM (not shown) by way of the DRAM interface 160 of FIG. 3, which is then transferred from the DRAM to the laser for writing.

[0058] When a read is requested by the host computer 203, the request is transferred through the USB cable 261 and transmitted to the USB pad cell 202. The data is then read from the CD media using the laser and then transferred to DRAM by way of DRAM interface 106 of the controller 100. The data is then transferred to the ATAPI interface 104 which is communicated to the storage 302 by way of bus 216. Once the data is stored in the storage 302, the data is transferred to the application 254 by way of bus 260. From the application 254, the data is transferred to bus 262 and then to the UDC 256 where the data is de-packetized (e.g., serialized) and sent to the USB pad cell 202. From the USB pad cell 202, the data is transferred over the USB bus 261 to the host computer 203.

[0059] It is again emphasized that the embodiments of the present invention, namely the ability of USB logic to share IDE/ATAPI logic to complete USB data transfer tasks is not limited to optical disc applications that include CD-R devices, CD-ROM devices, CD-RW devices, and the like. To the contrary, the embodiments claimed herein can apply to any USB device, which can be embodied in any number of peripheral devices, either internal or external.

[0060] Appendix A provides a more detailed description of registers implemented in the Application 254 of the USB core logic 204, in accordance with one embodiment of the present invention. The registers that define the functionality of the application 254 are, in this embodiment, triggered by a microprocessor that communicates with the controller 100 by way of microprocessor interface 108.

[0061] MICROPROCESSOR REGISTERS

[0062] Address space for the USB block microprocessor registers begin at 0A0h, and has 16 locations of which 14 are defined.

[0063] Each bit in this register provides a unique interrupt reason for USB transactions, as defined for a Mass Storage Class device. The USB Mass Storage Class, Bulk-Only Transport Specification, Revision 1.0 (1999), is hereby incorporated by reference.

[0064] For each interrupt bit in this register, there is a corresponding mask bit in USBINTEN0 (0A2h) that disables this bit from driving USBUINT0B or USBUINT1B on the microprocessor interface 108. An interrupt is cleared by writing a 0 to the bit. This register is initialized by hardware reset or setting USB Reset in the CMDCODE field of the USBCNTL1 Register (0A6h).

[0065] Bit 7 (R)—STALLED

[0066] This bit is set when CNTLSTALLED, BULKINSTALLED or BULKOUTSTALLED bits are set in the USBERR Register (0A5h). Reset when these bits are not set.

[0067] Bit 7 (W)—Reserved

[0068] Bit 6 (R/W)—BLKXFRERR—Block Transfer Error

[0069] This bit is set when the USB Block sets a XFRLGTHERR, FIFOERR, or BULKDIRERR in the USBERR Register (0A5h).

[0070] 1: Interrupt

[0071] 0: No Interrupt

[0072] Bit 5 (R/W)—CNTLXFRERR—Control Transfer Error

[0073] This bit is set when the USB Block sets a FIFOERR in the USBERR Register (0A5h) during a Control-In transfer.

[0074] 1: Interrupt

[0075] 0: No Interrupt

[0076] Bit 4 (R/W)—Reserved

[0077] Bit 3 (R/W)—MSBORST—Mass Storage Class Bulk-Only Reset

[0078] The USB block has received a Mass Storage Class Bulk-Only reset.

[0079] 1: Interrupt

[0080] 0: No Interrupt

[0081] Bit 2 (R/W)—CSWCMPLT—CSW Complete

[0082] When CSW is set in the CMDCODE field of the USBCNTL1 Register (0A6h.4 to 0A6h.0), this bit is set after the USB Block has finished sending the CSW packet on Bulk-In pipe and receiving the associated ACK packet from the host.

[0083] 1: Interrupt

[0084] 0: No Interrupt

[0085] Bit 1 (R/W)—XFRCMPLT—Transfer Complete

[0086] This bit is set when the USB Block has finished sending or receiving data for the current Bulk-In, Bulk-Out, or Control-In transfer. In Bulk-In or Control-In transfer, all packets are eventually acknowledged by the host. In Bulk-Out tranfers, all packets are eventually received correctly, acknowledge handshakes sent to the host, and all data transferred to the Block Decoder.

[0087] 1: Interrupt

[0088] 0: No Interrupt

[0089] Bit 0 (R/W)—CBWRCVD—CBW Packet Received

[0090] While in the “Wait for CBW” state, the USB block has received a CBW packet on the Bulk-Out endpoint, as set by firmware in the CMDCODE bits of the USBCNTL1 Register (0A6h.4 to 0A6h.0).

[0091] 1: Interrupt

[0092] 0: No Interrupt

[0093] Each bit in this register provides a unique interrupt reason for certain USB transactions and events. For each interrupt bit in this register, there is a corresponding mask bit in USBINTEN1 (0A3h) that disables this bit from driving USBUINT0B or USBUINT1B on the microprocessor interface. An interrupt is cleared by writing a 0 to the bit.

[0094] This register is initialized by hardware reset or setting USB Reset in the CMDCODE field of the USBCNTL1 Register (0A6h.4 to 0A6h. 1).

[0095] Bits 7,6, & 5 (R/W)—Reserved

[0096] Bit 4 (R/W)—UDCNACK—UDCN Acknowledge

[0097] This bit is set when a USB transfer is active 0A6.A=1) and the data transfer has started and the current packet has a transfer error. This interrupt can be used to count retries on the USB bus.

[0098] 1: Interrupt

[0099] 0: No Interrupt

[0100] Bit 3 (R/W)—USBGETDEV—USB Get Device Descriptor

[0101] The USB block has received a Get Device Descriptor standard command from the USB.

[0102] 1: Interrupt

[0103] 0: No Interrupt

[0104] Bit 2 (R/W)—USBGETCFG—USB Get Configuration Descriptor

[0105] The USB block has received a Get Configuration Descriptor standard command from the USB.

[0106] 1: Interrupt

[0107] 0: No Interrupt

[0108] Bit 1 (R/W)—USBGETSTR—USB Get String Descriptor

[0109] The USB block has received a Get String Descriptor standard command from the USB. The target string descriptor is indicated by the STRINDEX bits in the USBSTAT Register (0A4h.3,2).

[0110] 1: Interrupt

[0111] 0: No Interrupt

[0112] Bit 0 (R/W)—USBSUSP—USB Suspend

[0113] USB block has detected an idle state or suspend on the USB.

[0114] 1: Interrupt

[0115] 0: No Interrupt

[0116] This register enables corresponding bits in the USBINT0 Register (0A0h) to assert USBUINT0B or USBUINT1B on the microprocessor interface 108. Each bit enables the corresponding defined bit position in the USBINT0 from asserting the interrupt. These bits do not enable or disable the interrupt reason bit from being set in the USBINT0 Register (0A0h). Preferably, this register is initialized by hardware reset or setting USB Reset in the CMDCODE field of the USBCNTL1 Register (0A6h.4 to 0A6h.0). *Bit 4, in this embodiment, should be set to 0.

[0117] Bits 7 through 0 (R/W)—USBINTEN0—USB Interrupt Enable 0

[0118] 1: Enable

[0119] 0: Disable

[0120] This register enables corresponding bits in the USBINT1 Register (0A1h) to assert USBUINT0B or USBUINT1B on the microprocessor interface 108. Each bit enables the corresponding defined bit position in the USBINT1 Register to assert the interrupt. These bits do not enable or disable the interrupt reason bit from being set in the USBINT1 Register.

[0121] This register is initialized by hardware reset or setting USB Reset, in the CMDCODE field of the USBCNTL1 Register (0A6h.4 to 0A6h.0).

[0122] Bits 7,6, & 5 (R/W)—Reserved

[0123] Bits 4,3,2, 1, & 0 (R/W)—USBINTEN1—USB Interrupt Enable 1

[0124] 1: Enables

[0125] 0: Disables

[0126] This register provides real time status for certain events associated with USB transactions. This register is initialized by hardware reset or setting USB Reset in the CMDCODE field of the USBCNTL1 Register (0A6h.4 to 0A6h.0). This register is read/clear.

[0127] Bit 7 (R/W)—CBWLEQ0—CBW Length Equals 0

[0128] When “Wait for CBW” is set in the CMDCODE field of the USBCNTL1 Register (0A6h.4 to 0A6h.0), this bit is set if the USB Block detects that the CBWDATATRANSFERLENGTH field in the CBW (received from the USB) is equal to 0.

[0129] 1: Condition occurred

[0130] 0: Condition did not occur

[0131] Bit 6 (R/W)—CBWDIR—CBW Direction Transfer

[0132] When “Wait for CBW” is set in the CMDCODE field of the USBCNTL1 Register (0A6h.4 to 0A6h.0), this bit is set if bit 7 in the CBWFLAGS field of the CBW is set to 1, indicating a data-in transfer (device to host). This bit is reset, if bit 7 in the CBWFLAGS field is set to 0, indicating a data-out transfer (host to device).

[0133] 1: Condition occurred

[0134] 0: Condition did not occur

[0135] Bit 5 (R/W)—UDCNACK—UDCN Acknowledge

[0136] This bit is set when any USB transaction or stage has resulted in the UDC block asserting UDCXFRNACK on the UDC/Application interface, internal to the USB block. Reset when the next transfer begins on this interface (UDCAS asserted). Note that this bit can be active when the UDCNACKI bit (0A1h.4) is inactive.

[0137] 1: Condition occurred

[0138] 0: Condition did not occur

[0139] Bit 4 (R/W)—UDCACK—UDC Acknowledge

[0140] This bit is set when a USB transaction or stage has resulted in the UDC block asserting UDCXFRACK, on the UDC/Application interface, internal to the USB block. Reset when the next transfer begins on this interface (UDCAS asserted).

[0141] 1: Condition occurred

[0142] 0: Condition did not occur

[0143] Bits 3 & 2 (R/W)—STRINDEX—String Index

[0144] These bits contain string number (0-3) associated with the USBGETSTR bit set in the USBINT1 Register (0A1h.1). A value of 0 points to String Index 0, 1 points to the Manufacturer String, and so on.

[0145] 11: String 3

[0146] 10: String 2

[0147] 01: String 1

[0148] 00: String 0

[0149] Bits 1 & 0 (R/W)—EPNUM—Endpoint Number

[0150] This field indicates the endpoint number, if any, associated with the most recent USB token phase.

[0151] 11: Unused

[0152] 10: Endpoint 2—Bulk-Out

[0153] 1: Endpoint 1—Bulk In

[0154] 00: Endpoint 0—Control

[0155] This register provides real time error status for certain events associaated with USB transactions.

[0156] Bit 7 (R)—CNTLSTLD—Control Stalled

[0157] The USB Block detected a condition that caused it to stall the USB Control endpoint. This bit sets the STALLED bit, in the USBINT0 Register (0A0h.7).

[0158] The write port for this bit exists in the USBCBL Register (0A8h.7).

[0159] Bit 6 (R)—BLKINSTLD—Bulk-In Stalled

[0160] The USB Block detected a condition that caused it to stall the USB Bulk-In endpoint. This bit sets the STALLED bit, in the USBINT0 Register (0A0h.7).

[0161] The write port for this bit exists in the USBCBL Register (0A8h.6).

[0162] Bit 5 (R)—BLKOUTSTLD—Bulk-Out Stalled

[0163] The USB Block detected a condition that caused it to stall the USB Bulk-Out endpoint. This bit sets the STALLED bit, in the USBINT0 Register (0A0h.7).

[0164] The write port for this bit exists in the USBCBL Register (0A8h.5).

[0165] Bits 7,6, & 5 (W)—Reserved

[0166] Bit 4 (R/W)—BLKDIRERR—Bulk Direction Error

[0167] This bit is set during a Bulk-In or Bulk-Out data transfer, when the USB sends a token indicating the opposite direction of bulk transfer. This bit sets the BLKXFRERR bit, in the USBINT0 Register (0A0h.6).

[0168] Bit 3 (R/W)—CBWLERR—CBW Length Error

[0169] When “Wait for CBW” is set in the CMDCODE field of the USBCNTL1 Register (0A6h.4 to 0A6h.0), this bit is set if the USB Block detects that the CBW received from the USB is not equal to 31 bytes in length. This bit sets the BLKXFRERR bit, in the USBINT0 Register (0A0h.6).

[0170] Bit 2 (R/W)—FIFOERR—FIFO Error

[0171] A Block Decoder FIFO under/overrun occurred during Bulk-In, Bulk-Out, or Control-In data transfer. This bit sets the BLKXFRERR and CNTLXFRERR bits in the USBINT0 Register (0A0h.6) and (0A0h.5).

[0172] Bit 1 (R/W)—XFRLERR—Transfer Length Error

[0173] This bit is set during a Bulk-In or Bulk-Out data transfer, when the USB transfers one more byte than the number of bytes specified in the CBWDATATRANSFERLENGTH field, in the CBW. This bit sets the BLKXFRERR bit, in the USBINT0 Register (0A6h.0).

[0174] Bit 0 (R/W)—CBWSIGERR—CBW Signature Error

[0175] When “Wait for CBW” is set in the CMDCODE field of the USBCNTL1 Register (0A6h.4 to 0A6h.1), this bit is set if the USB Block detects that the CBWSIGNATURE field in the CBW (received from the USB) is not equal to “43 42 53 55”h. This bit sets the BLKXFRERR bit in the USBINT0 Register (0A0h.6).

[0176] This register provides the firmware interface for setting Mass Storage Class tasks along with certain USB and other controls to the USB block.

[0177] This register is initialized by hardware reset or setting USB Reset in the CMDCODE field of the USBCNTL1 Register (0A6h.4 to 0A6h.0).

[0178] Bit 7 (R/W)—RDDESPRM—Read Descriptor Parameters

[0179] When set to 1, the USBWL1-3 Registers are used to read parameters for the GET DESCRIPTOR request from the USB host. These Registers should be read when servicing an interrupt for the USBGETDEV, USBGETCFG, and USBGETSTR bits in the USBINT1 Register (0A1h.3,2,1).

[0180] The LSByte of WLENGTH is read in USBCBWL1.

[0181] The LSByte of LANGID is read in USBCBWL2.

[0182] The MSByte of LANGID is read in USBCBWL3.

[0183] Bit 6 (R/W)—CSWDTRES—CSW Data Residue

[0184] When set to 1, the USB Block returns the value received as the CBWDATATRANSFERLENGTH field in the last CBW as the CSWDATARESIDUE field of all CSWs. This bit should always be set to 1 when the USB Block is set to actively wait for a CBW (“Wait for CBW” is set in the CMDCODE field, and START is set in the USBCNTL1 Register [0A6h.4-0]). If there is an error associated with the CBW received, the CSWDATARESIDUE field will contain the CBWDATATRANSFERLENGTH field, per the USB Mass Storage Class Bulk-Only Transport specification. When set to 0, the USB Block residual value (number of bytes remaining to be transferred) of its internal DTXFRCNT Register as the CSWDATARESIDUE field of all CSWs.

[0185] Bit 5 (R/W)—NODATA—No Data

[0186] When set to 1, the Application Block responds to all USB requests received from the UDC for Bulk-In and Control-In endpoints, with a zero length data packet, that will work for the Bulk-In or Control-In types of transfer.

[0187] 1: Sends a zero length data packet

[0188] 0: Sends a normal data packet

[0189] Bit 4 (R/W)—START—Start USB Transfer

[0190] Setting this bit initiates the USB transfer or task specified by the CMDCODE bits. This bit is reset once the current task set has completed (with or without error).

[0191] 1: Enable

[0192] 0: Disable

[0193] Bits 3, 2, 1 & 0 (R/W)—CMDCODE—CMD Code

[0194] Setting the START bit, enables the following bits to provide the task or transfer type.

[0195] This register provides the firmware interface for setting global function controls and parameters in the USB Block.

[0196] This register is initialized by hardware reset or setting USB Reset in the CMDCODE field of the USBCNTL1 Register (0A6h.4 to 0A6h.0).

[0197] Bit 7 (R/W)—Reserved

[0198] Bit 6 (R/W)—STLPKT—Stall Current Packet

[0199] When set to 1, the logic will attempt to send a stall PID as soon as possible when the USB is set to cause a stall (USBCNTL2 Register bit 5, 4, or 3 [0A7h.5,4,3]=1) and the logic detects a condition that would cause a stall.

[0200] Bit 5 (R/W)—STLDIRERR—Stall Direction Error

[0201] When set to 1, the USB Block is allowed to set a stall condition to the USB as a result of the BLKDIRERR bit set in the USBERR Register (0A5h.4). The DEVSTALLED signal is set on the UDC/Application interface for the next USB transaction. The STALLED bit, in the USBINT0 Register (0A0h.7,R), and the appropriate BLKINSTLD or BLKOUTSTLD bit, in the USBERR Register (0A5h.6,5), are set at the end of the transaction in which this error was detected.

[0202] Bit 4 (R/W)—STLFIFOERR—Stall FIFO Error

[0203] When set to 1, the USB Block is allowed to set a stall condition to the USB as a result of the FIFOERR bit being set in the USBERR Register (0A5.2). The DEVSTALLD signal is set on the UDC/Application interface for the next USB transaction. The STALLED bit, in the USBINT0 Register (0A0h.7,R), and the appropriate BLKINSTLD or BLKOUTSTLD bit, in the USBERR Register (0A5h.6,5), are set at the end of the transaction in which this error was detected.

[0204] Bit 3 (R/W)—STLXFRLERR—Stall Transfer Error

[0205] When set to 1, the USB Block is allowed to set a stall condition to the USB as a result of the XFRLERR bit set in the USBERR Register (0A5h.1). The DEVSTALLED signal is set on the UDC/Application interface for the next USB transaction. The STALLED bit, in the USBINT0 Register (0A0h.7,R), and the appropriate BLKINSTLD or BLKOUTSTLD bit, in the USBERR Register (0A5h.6,5), are set at the end of the transaction in which this error was detected.

[0206] Bit 2 (R/W)—CONTXFR

[0207] When set to 1, if the USB logic encounters a FIFO underrun condition, it will send NACK handshakes on the USB wire until the condition that caused the FIFO overrunis rectified. This bit is used for allowing multiple block decoder transfers to satisfy a single CBW transfer request. USB NACKS, between the multiple block decoder transfers, are used for flow control on the USB Bus. After the last block decoder transfer is triggered—intended to end the CBW transfer—this bit should be set to 0.

[0208] Bit 1 (R/W)—INT0/1—Interrupt 0/1

[0209] When set to 1, this bit enables the USB Block interrupt, resulting from bits set in the USBINT Registers, to be driven on USBINT1. When set to 0, this bit enables the USB Block interrupt, resulting from bits set in the USBINT Registers, to be driven on USBINT0.

[0210] Bit 0 (R/W)—USBENBL—USB Enable

[0211] When set to 1, the USB mode is enabled for the USB data transfer through the USB Block. When set to 0, the ATAPI mode is enabled and USBCLK4X is disabled in the Application Block. The default state of this bit is 0 following hardware reset. This bit determines which signals are driven off the chip on the common USB/ATAPI pins. It also selects the ATAPI input pins or the USB Block Application Data Transfer outputs to be driven to the block decoder.

[0212] When “Wait for CBW” is set in the CMDCODE field of the USBCNTL1 Register (0A6h.4 to 0A6h.0), the USB Block loads bits A-0 of this register with the CBWCBLENGTH field of the CBW, as it is received from the USB.

[0213] This register is initialized by hardware reset or setting USB Reset in the CMDCODE field of the USBCNTL1 Register.

[0214] Bits 7, 6, & 5 (R)—Reserved

[0215] Bit 7 (W)—CNTLSTL—Control Stalled

[0216] The USB Block detected a condition that caused it to stall the USB Control endpoint. This bit sets the STALLED bit, in the USBINT0 Register (0A0h.7).

[0217] The read port for this bit exists in the USBERR Register (0A5h.7).

[0218] Bit 6 (W)—BLKINSTL—Bulk-In Stalled

[0219] The USB Block detected a condition that caused it to stall the USB Bulk-In endpoint. This bit sets the STALLED bit, in the USBINT0 Register (0A0h.7).

[0220] The read port for this bit exists in the USBERR Register (0A5h.6).

[0221] Bit 5 (W)—BLKOUTSTL—Bulk-Out Stalled

[0222] The USB Block detected a condition that caused it to stall the USB Bulk-Out endpoint. This bit sets the STALLED bit, in the USBINT0 Register (0A0h.7).

[0223] The read port for this bit exists in the USBERR Register (0A5h.5).

[0224] Bits 4, 3, 2, 1, & 0 (R/W)—USBCBLENGTH—USB Command Block Length

[0225] These bits hold the BCB length field from the last CBW received.

[0226] Bits 7, 6, 5, 4, & 3 (R/W)—Reserved

[0227] Bit 2 (R/W)—USBCKSEL—USB Clock Select

[0228] 1: Uses external 48 MHz—Pin HA0

[0229] 0: Uses internal 48 MHz—PLLC0/PLLC1 must be programmed to 96 MHz

[0230] Bits 1 & 0 (R/W)—UDECCK1-0)—USB Decoder Clock Select 1 & 0

[0231] In the USB mode, the PLL is programmed to 96 MHz, which is also the clock for the block decoder. These two bits allow division of the 96 MHz clock by 1, 2, 3, or 4 before being used by the block decoder.

[0232] 00: PLLC0/PLLC1 (1FDh, 1FEh)—96 MHz

[0233] 01: PLLC0/PLLC1 (1FDh, 1FEh)/2—48 MHz

[0234] 10: PLLC0/PLLC1 (1FDh, 1FEh)/3—32 MHz

[0235] 11: PLLC0/PLLC1 (1FDh, 1FEh)/4—24 MHz

[0236] In USB, PLLC0 and PLLC1 must be programmed to provide 96 MHz.

[0237] When “Wait for CBW” is set in the CMDCODE field of the USBCNTL1 Register (0A6h.4 to 0A6h.0), the USB Block loads this register with bits 7-0 of the CDBDATATRANSFERLENGTH field of the CBW, as it is received from the USB.

[0238] This register is initialized by hardware reset or setting USB Reset in the CMDCODE field of the USBCNTL1 Register.

[0239] When “Wait for CBW” is set in the CMDCODE field of the USBCNTL1 Register (0A6h.4 to 0A6h.0), the USB Block loads this register with bits 15-8 of the CBWDATATRANSFERLENGTH field of the CBW, as it is received from the USB. If the RDDESPRM bit in the USBCNTL1 Register (0A6h.7)=1, read WLength for GET DESCRIPTOR. This register is initialized by hardware reset or setting USB Reset in the CMDCODE field of the USBCNTL1 Register. If USBCNTL1 bit 7=1, this read address will return the LSByte of WLENGTH.

[0240] When “Wait for CBW” is set in the CMDCODE field of the USBCNTL1 Register (0A6h.4 to 0A6h.0), the USB Block loads this register with bits 23-16 of the CBWDATATRANSFERLENGTH field of the CBW, as it is received from the USB. If the RDDESPRM bit in the USBCNTL1 Register (0A6h.7)=1, read LSByte of LANGID for GET DESCRIPTOR. This register is initialized by hardware reset or setting USB Reset in the CMDCODE field of the USBCNTL1 Register. If USBCNTL1 bit 7=1, this read address will return the LSByte of LANGID.

[0241] When “Wait for CBW” is set in the CMDCODE field of the USBCNTL1 Register (0A6h.4 to 0A6h.0), the USB Block loads this register with bits 31-24 of the CBWDATATRANSFERLENGTH field of the CBW, as it is received from the USB. If the RDDESPRM bit in the USBCNTL1 Register (0A6h.7)=1, read MSByte of LANGID for GET DESCRIPTOR. This register is initialized by hardware reset or setting USB Reset in the CMDCODE field of the USBCNTL1 Register. If USBCNTL1 bit 7=1 this read address will return the MSByte of LANGID.

[0242] N. DESCRIPTORS

[0243] A description is now provided of the sizes and relative locations of the Descriptor Table elements required for implementing a USB Serial Bus node compliant with the USB Mass Storage Class Bulk-Only Transport specification, which was incorporated by reference herein. The Manufacturer and Product strings are not required by the USB Mass Storage Class Bulk-Only Transport specification but are supported by the embodiments of the USB logic.

[0244] System DRAM is used to provide actual storage of the descriptors that are accessed through hardware. The actual DRAM addresses of the Descriptor Table elements are firmware dependent. However, the Configuration, Interface, Bulk-In, and Bulk-Out descriptors should, in this embodiment, be located contiguous in memory and in the order shown below, in the Descriptor Table Memory Map.

[0245] O. DESCRIPTOR TABLE FORMAT

[0246] The values given for the blength field are shown below as an offset address from a given base address (Base Address=XX00h).

[0247] By way of example, if the Base Address=0100h, when the Descriptor location=Base Address+Offset Address, then Device=0100h to 0111h

[0248] Configuration=012h to 011Bh

[0249] String Index 0=0133h to 0224h, n=250 bytes

[0250] Of course, the implementation details of the present invention can be modified as the Mass Storage Class Bulk-Only Transfer specification is modified.

[0251] P. USB DATA TRANSFER

[0252] The USB Block transfers control information and data to and from the DRAM under control of the Buffer Manager. When control frames are received, the USB Block generates an interrupt to the microprocessor, with the type of frame set in the USBINT1 Register (0A1h). The microprocessor then writes data for the response frame to the DRAM. Data transfers use the DRAM pages utilized by the encoder and decoder blocks.

[0253] The present invention may be implemented using any type of integrated circuit logic, state machines, or software driven computer-implemented operations. By way of example, a hardware description language (HDL) based design and synthesis program may be used to design the silicon-level circuitry necessary to appropriately perform the data and control operations in accordance with one embodiment of the present invention. By way of example, a Verilog hardware description language available from Cadence Design of San Jose, Calif., may be used to design an appropriate silicon-level layout.

[0254] The invention may employ various computer-implemented operations involving data stored in computer systems to drive computer peripheral devices (i.e., in the form of software drivers). These operations are those requiring physical manipulation of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. Further, the manipulations performed are often referred to in terms, such as producing, identifying, determining, or comparing.

[0255] Any of the operations described herein that form part of the invention are useful machine operations. The invention also relates to a device or an apparatus for performing these operations. The apparatus may be specially constructed for the required purposes, or it may be a general purpose computer selectively activated or configured by a computer program stored in the computer. In particular, various general purpose machines may be used with computer programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required operations.

[0256] Although the foregoing invention has been described in some detail for purposes of clarity of understanding, it will be apparent that certain changes and modifications may be practiced within the scope of the appended claims. Accordingly, the present embodiments are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.