Electrical computers and digital data processing systems: input/ – Intrasystem connection – Bus interface architecture
Reexamination Certificate
2000-09-27
2003-09-09
Dharia, Rupal (Department: 2189)
Electrical computers and digital data processing systems: input/
Intrasystem connection
Bus interface architecture
C710S022000, C710S035000
Reexamination Certificate
active
06618788
ABSTRACT:
FIELD OF THE INVENTION
This present invention relates to ATA (Advanced Technology Attachment) device control, and more particularly to systems and methods for interfacing a host with an ATA device using an intervening packet data channel.
BACKGROUND OF THE INVENTION
An “ATA” device is a data device that complies with an ANSI (American National Standards Institute) ATA standard, for instance the standard “AT Attachment with Packet Interface Extension—(ATA/ATAPI-4)” or one of its predecessors. Future ATA standards are also currently contemplated; devices compliant with these standards will also be “ATA devices”. Most personal computers have built-in ATA device support, and most of these come equipped with ATA internal hard drives.
The ATA standards define the physical, electrical, transport, and command protocols for the internal attachment of devices to computers via an ATA bus. Referring to
FIG. 1
, a typical configuration for a computer
20
capable of using one or more ATA data devices is shown. A host processor
22
communicates with main memory
24
(e.g., a memory controller attached to one or more memory modules via a memory bus) over a frontside bus
28
. Host processor
22
(and main memory
24
) can also communicate with a variety of other system peripherals through PCI (Peripheral Component Interconnect) bridge
26
and PCI local bus
30
.
The bandwidth on PCI local bus
30
can be shared by a variety of computer components, some of which are depicted in FIG.
1
. For instance, internal PCI-compliant devices such as modems, sound cards, video cards, etc. can be attached to computer
20
via PCI card slots
32
and
34
(the number of available slots varies from computer model to computer model) on the computer motherboard. In addition, USB (Universal Serial Bus) interface
36
provides a number of USB ports
38
for the attachment of a wide variety of external devices, such as a mouse, a keyboard, a digital camera, audio devices, printers, etc. And ATA host adapter
40
performs signal conversion between PCI local bus
30
and yet another bus, ATA bus
42
.
ATA bus
42
is typically implemented as a multi-drop bus using a flexible 40-conductor cable having three 40-pin connectors, each of which can mate to a corresponding socket on the computer's motherboard or on an ATA device (the ATA devices themselves mount within the computer case). Up to two ATA devices (e.g., devices
44
and
46
on
FIG. 1
) can share ATA bus
42
. The primary device is known as device
0
, or the “master” when two devices are present. The secondary device is known as device
1
, or the “slave”. For most ATA operations, only one of devices
44
and
46
will respond to the host's commands, that device being the one corresponding to the state of the “DEV” bit in the Device/Head Register (to be discussed shortly).
FIG. 2
illustrates several concepts related to ATA communication between an ATA host and an ATA device. ATA bus
42
uses an asynchronous interface protocol. Bus
42
comprises a 16-bit data bus
52
, used to transfer storage data and register values to and from ATA device
44
. Five-bit register addressing bus
54
is used by the host to tell device
44
which register's contents are to be accessed. Device signals
56
and host signals
58
are used to indicate when bus contents are valid, to indicate whether a register access is a read or a write, to synchronize transfers, and to perform device resets.
All communications with a traditional ATA device
44
take place via register-delivered commands. Within device
44
, a device controller
50
maintains a set of registers. In
FIG. 2
, this set of registers has been arranged in three groups: write-only registers
60
(registers that can only be written by the host); read-only registers
62
(registers that can only be written by the device); and read/write registers
64
. A register-delivered command is executed whenever the host writes to the Command register. For instance, the READ MULTIPLE command causes multiple sectors to be read from the device in PIO data-in mode (Programmed Input/Output mode data transfers are performed by the host processor utilizing programmed register accesses to the Data register). To perform a READ MULTIPLE command, the host places the number of data sectors to be transferred in the Sector Count register, the starting sector number in the Sector Number register, the starting cylinder number in the Cylinder High/Cylinder Low registers, and the device number and starting head number in the Device/Head register. The READ MULTIPLE command code (C4h) is then written to the Command register, causing ATA device
44
to evaluate the other register's contents and perform the requested read.
Device
44
indicates the status of the command using the bit fields of the Status register. If an error occurs, device
44
will report on the error using the Error register and several other registers. Note that it is the host's job to read the registers and ascertain the status of the device.
The ATA standard includes an alternative to register-delivered commands that is better suited to devices such as CD-ROM and tape devices. The ATAPI (ATA Packet Interface) specifies a method for controlling a storage device over an ATA bus using packet-delivered commands. Although an ATAPI device and an ATA device can share an ATA bus, a single device cannot identify itself simultaneously as both an ATA device and as an ATAPI device. An ATAPI device supports a very small subset of the traditional ATA command set—for most of its functions, an ATAPI device receives ATAPI packet-delivered transport protocol commands. An ATAPI packet is received by the device as data upon receipt by the device of the ATA ATAPI-specific PACKET command in the Command register.
The ATAPI transport protocol, like traditional ATA, was designed for use with internally-mounted drives and with a host that places ATAPI packets directly on the ATA bus. But because most functions of an ATAPI device can be exercised using ATAPI packets, methods have now been devised to use an intermediate transport protocol and a different physical transport media—those provided by USB—to allow external connection of an ATAPI device to a host computer. This method relies only on the packet-delivered commands of ATAPI to communicate with an ATAPI device.
FIG. 3
illustrates a communication stack
70
that operates according to such a method.
In
FIG. 3
, a physical device
90
, which includes an ATAPI device
100
, physically connects to a host
80
via a USB PHY connection
99
, e.g., a USB cable or an intervening USB hub. When host
80
desires to execute an ATAPI function on ATAPI device
100
, host
80
calls ATAPI driver
82
. ATAPI driver
82
sends an appropriate ATAPI transport protocol command, along with an indication as to the amount of data (if any) that is expected to be transferred and an indication of the “Logical Unit” that is to be addressed, to MSC (Mass Storage Class) driver
84
.
Logically, MSC driver
84
communicates with MSC logical device
96
on physical device
90
to transport the ATAPI command packet and data between host
80
and physical device
90
. Together, driver
84
and logical device
96
operate according to the specification “Universal Serial Bus Mass Storage Class—Bulk-Only Transport”, Rev. 1.0, USB Implementers Forum, Sep. 31, 1999. According to this specification, two USB logical pipes (Bulk-In Pipe
110
and Bulk-Out Pipe
112
) are established between the two USB endpoints (in addition to the Default Pipe
114
that exists between USB driver
86
and USB logical device
94
). The two devices pass MSC-formatted command and data packets over these two logical pipes. Physically, driver
84
and logical device
96
communicate via the USB PHY
99
that is established between USB host controller
88
(on host
80
) and USB bus interface
92
(on device
90
).
ATAPI command execution proceeds in three MSC steps, as shown in flowchart
120
of FIG.
4
. The ATAPI transport protocol packet is encapsulated in an MSC-valid
Cypress Semiconductor, Inc.
Dharia Rupal
Marger Johnson & McCollom
LandOfFree
ATA device control via a packet-based interface does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with ATA device control via a packet-based interface, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and ATA device control via a packet-based interface will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3068215