Enhanced ATA channel command structure for automatic polling, hot swapping and extending coupled peripheral devices

[0002] This application claims benefit of U.S. provisional 60/108,465, filed Nov. 14, 1998.

[0003] The present invention is directed to the control of mass storage devices and, more particularly, to an enhanced ATA channel protocol which supports enhanced device connectivity and functionality.

[0004] The ATA channel has traditionally been implemented as a set of registers, addressed by a simple decode of a host computer's internal bus. As shown in the exemplary embodiment of FIG. 1, a standard ATA channel configuration includes a host or ATA adapter 10 coupled between a host bus 12 and an ATA bus 14 (implemented as an ATA cable) to which up to two peripheral devices 16 and 18 might be connected. Originally, host or ATA adapters allowed many of the original ISA signals to be passed onto the ATA cable along with decoded peripheral device address lines. At best, only a few of the original ISA signals were buffered.

[0005] The address registers that were being addressed resided within the peripheral devices. Accordingly, the channel consisted of the ATA bus which defined the electrical characteristics and a timing protocol, and an API (Applications Programming Interface) which defined registers and commands. Because the ATA bus was a simple decode of the ISA bus, the protocols and timings were necessarily those of the ISA bus.

[0006] As time progressed, there has developed a need to increase performance and functionality of the ATA bus; thus the timings and protocols have changed. Because these protocols no longer reflect those of the host bus, the ATA adapter has become more sophisticated and now represents a bridge between the host bus and the ATA bus. Functioning as a bridge, the ATA adapter must convert between the electrical interfaces as well as convert between signal protocols.

[0007] However, there is an additional need to provide more functionality to the channel, particularly functionality beyond that of mere performance and protocol conversion.

[0008] One of the main elements of the success of the ATA Standard has been the effort made to ensure compatibility. This compatibility has been extended across physical connectivity, electrical characteristics and most importantly, in the API. Utilizing a standard API has meant that host software investments have been protected and that any software written for any legacy-type devices will also work on more modern devices.

[0009] The ATA API consists of a set of 8-bit registers that have been modeled on the original WD1002 disk controller adapter. In the X86-PC world the I/O address of these registers have become a defacto standard. These registers are used for both commands and the transfer of PIO data. This compatibility has been rigorously maintained to the present day, even in the case of PCI adapters. The need for enhanced performance has necessitated the use of DMA protocols and adapters. There has evolved a defacto standard for the registers used to control PCI Bus Mastering Adapters, but no standard has been developed for their configuration. Unfortunately, the current generation PCI adapter API does not allow for variable length data transfer while the ATA protocol does.

[0010] Accordingly, there exists a need for an expanded ATA channel which incorporates the functionality of the present ATA channel but also incorporates enhanced functionality.

[0011] The enhanced ATA channel functions, in accordance with the invention, provide a number of non device-specific features such as extending the number of devices on a channel, automatic polling of queued devices and the ability to hot swap devices. These functions are controlled by a set of channel commands that are interpreted by the channel and which are not passed on to any connected peripheral device. Any unrecognized command reaching the device will cause it to create an interrupt and write to its status register.

[0012] In accordance with the invention, it is desirable to isolate peripheral devices from-the channel during implementation of channel commands. This can be accomplished in a number of ways. However, some methods will result in signal timings being extended. For those methods that do cause signal timing delays, the Reflective Timing Principles of the HotPort™ External Device are used.

[0013] These and other features, aspects and advantages of the present invention will be more fully understood when considered with respect to the detailed description, appended claims and accompanying drawings, wherein:

[0014] FIG. 1 is a simplified, semi-schematic block diagram illustrating a conventional ATA channel;

[0015] FIG. 2 is a simplified, semi-schematic block diagram of an enhanced ATA channel incorporating additional functionality, in accordance with the practice of principles of the present invention.

[0016] Prior to entering into a detailed description of the invention, it will be useful to enter into some discussion regarding certain definitions of terms used herein. In particular, the term ATA-4 is used to define the published standard for the control and protocols found in ATA devices. The ATA Standard is updated over time and, thus, ATA-4 is meant to convey the current published standard. It should be understood by those having skill in the art that this is only the most current standard and that the concepts of the present invention are intended to extend to ATA-5, ATA-6 and beyond. An ATA Adapter functions as a basic host adapter which provides for the decoding-of host bus addresses and controlling the flow of data between a host computer and the ATA bus. An ATA adapter could be implemented as a simple decoder and buffer (as in ISI implementations) or implemented as a PCI bus-master device.

[0017] A HotAdapter™ provides control of the external device interface and allows the host to connect to external IDE/ATA/ATAPI devices. A HotBox™ refers to an enclosure for receiving an external device which includes a HotBox™ adapter allowing power-on coupling and decoupling of external devices to the bus.

[0018] Control functions for power-on docking and undocking of devices is provided by a HotBridge™ arbiter which performs the functions needed to control access to the ATA channel. The HotBridge™, HotBox™, and HotAdapter™ are all considered part of a HotPort™ interface, manufactured and distributed by GSI Technology of Irvine, Calif.

[0019] A RAID array refers to a random array of independent drives. A RAID system looks, to the host, like a device, in that it responds to the device API. However, the RAID array does need to communicate certain asynchronous critical events to the host and thus, has a need to assert unexpected interrupts. Device protocols do not support unexpected interrupts; even interrupts from overlap devices are not truly unexpected. Since the enhanced channel features, in accordance with the invention, are able to deal with unexpected interrupts, the RAID array is now able to be efficiently implemented on the enhanced ATA Channel.

[0020] Because of the demonstrated need for additional channel functionality, in view of the inadequacies of the current PCI API, the present invention is directed to details of several new functions available on an ATA channel, the commands to control them, as well as extending the API. All of these commands take the form of ATA commands and are thus host independent. In addition, care has been taken in order to ensure backward compatibility with legacy devices. The following description of an enhanced ATA channel system makes certain hardware implementation assumptions. Any implementation should ensure that the described ATA channel functionality is followed no matter how the channel is physically implemented.

[0021] FIG. 2 is a simplified, semi-schematic block diagram representation of a particular definition of an ATA channel in accordance with the present invention. It should be understood that some or all of the illustrated features may be present. In addition, by disabling all of the enhanced features (indicated by asterisks in the exemplary embodiment of FIG. 2) the channel reverts back to a basic ATA channel, thereby preserving backward compatibility. It should be understood by those having skill in the art that the enhanced features and functions may be implemented in one or more physical embodiments. The mixture of functions and implementations is described in greater detail below. In the exemplary embodiment of FIG. 2, an ATA adapter 20 in accordance with the invention, is coupled between a host bus 12 and a plurality of non device-specific channel related functional blocks. These non device-specific channel related functional blocks suitably include HotAdapter™ circuitry 22, HotBox™ circuitry 26, an AutoPole circuit 24 and a sub-channel circuit 28, which functions to allow more than one cable (exemplified by cable 14 and cable 13) to be implemented in the system. A plurality of peripheral devices, 16 and 18 are coupled to ATA cable 14 through HotDock™ circuit blocks 32 and 34, so as to allow the peripheral devices 16 and 18 to communicate with the host bus 12 over ATA adapter 20.

[0022] It should further be understood that the non device-specific channel related functional blocks illustrated in the exemplary embodiment of FIG. 2 are not necessarily inclusive of all the additional functionality that might be implemented in accordance with the invention. Specifically, the exemplary embodiment of FIG. 2, does not include a RAID controller, but its incorporation is certainly within contemplation of the present invention.

[0023] The channel hardware has to monitor or “snoop” commands appearing on the bus. In some cases, there may be several instances of hardware snooping on the same bus. This snooping must not adversely affect the electrical characteristics of the bus and, in certain cases, the bus may need to be buffered. Any buffering imposes certain propagation delays and since the ATA protocols are mainly asynchronous, these propagation delays can adversely affect data integrity and performance. The HotPort™ external device interface standards use reflective timing signals in order to accommodate propagation delays. Accordingly, the channel features in accordance with the invention, collectively use reflective timing in order to compensate for any imposed propagation delays.

[0024] It should further be understood that certain of the non device-specific channel related functional blocks are able to be combined into a single functional unit. For example, the ATA adapter 20 and HotAdapter™ 22 functions or the ATA adapter 20 and RAID array functions might be combined into a single functional block implemented on a single integrated circuit card. Similarly, the HotBox™ functions and RAID array functions might be so combined on a single integrated circuit card. It should further be understood that because of propagation delays and the likelihood that a multiplicity of devices will be connected to the channel, a certain degree of ordering needs to be established. In this regard, one might consider channel functions to be divided into two channel functional groups; those channel functions that impose propagation delays and, those channel functions that do not. The second category is somewhat of a misnomer as there will always be delays of some form or another, but nevertheless the delay for this category is specific to PIO and will be discussed in greater detail further.

[0025] Channel order is defined as being from the host interface to the device interface. The device interface is conceptually the header that a peripheral device is connected to the ATA cable through. The device cable is the standard ATA cable with one or two peripheral devices attached thereto. Thus, references to device-ward or host-ward means any channel function or device that is farther from, or nearer to respectively, the host then the function in question. In this regard, all delay groups must be adjacent. So long as the adjacency requirement is satisfied for delay groups, non-delay group functions can be either device-ward or host-ward, or both, of the delay group functions. The delay groups will pass through the reflective timing signals to allow the reflective timing to represent the total delay imposed. A function that would otherwise be considered non-delay but is implemented within the delay groups must accommodate the reflective timing signals of the delay group.

[0026] There are a number of commands that are not intended for use by peripheral devices on an ATA channel, but are rather meant for the controlling elements of that channel. These particular commands are termed channel commands. These commands are sent to the channel using the same register set as defined for the peripheral devices on the channel. Where the use differs between the device and the channel, the names have been changed, while the decode values remain the same. Table 1 illustrates the device/channel register definitions with regard to the state of address decode lines.

[0027] The channel commands consist of the CHANNEL-COMMAND code written to the command register and a sub-command code written to the sub-command register. In addition, parameters can be written to the parameter registers. Parameter registers will only be implemented by functions that require their use. The CHANNEL-COMMAND command shares the same command code as the device NOP command. The sub-commands are any value in the sub-command register except 00h. If the device receives a command code, it will interpret it as an NOP command and respond appropriately in accordance with the ATA-4 protocol.

[0028] It is possible that the channel intercepts all commands and only passes on those commands that are intended for receipt by peripheral devices coupled to the channel. However, this would introduce delays into every transfer to or from registers on the channel and would thereby adversely effect performance. Consequently, it is expected that a peripheral device will detect some of the CCS commands. To allow for this, the peripheral device will respond to the CCS commands by setting an error bit and INTRQ, in the appropriate registers, while not aborting any outstanding commands or queues it may have. The sub-command 00h is not part of the CCS command set and is reserved for use by a peripheral device; sub-command 00h has the effect of aborting any outstanding queue in the device.

[0029] Channel commands are given to the channel and not to a peripheral device. In general, this means that the channel functions will respond to commands no matter which device (channel functional block) is selected. In some configurations, a device might be a sub channel controller (28 of FIG. 2) and will occupy a particular physical device address. One such example might be a sub-channel controller in the context of an array controller. Physically the sub-controller might be a box with several peripheral devices coupled to it, some of those devices forming a RAID system which looks like a single device; the rest might be individually addressable and reside on a sub-channel.

[0030] Some of the functions supported by the sub-commands can occur asynchronously on the channel. They are best served by the ability to send unsolicited interrupt to the host. This is accomplished on the HotPort™ external device interface cable but not on the regular 40 pin ATA cable. Compliance systems will use pin 20 on the ATA cable as the unsolicited interrupt signal line. Pin 20 is not connected on legacy devices and may therefore be connected on newer devices wishing to cause an unsolicited interrupt. Since the equipment must work on older systems, this standard provides a methodology for this type of operation, although not at optimum performance levels.

[0031] The channel commands typically obey the basic ATA-4 command protocols. The host may not issue a channel command if BUSY or DRQ is set in the channel status/ALT-status register. There are two protocol views to issue a channel command; anonymous and signature. The anonymous protocol is seen by all channel functions and peripheral devices. Signatured protocols are only seen by those devices or groups of devices that match the signature.

[0032] The case of the anonymous protocol, the particular operational sequence is as follows: a) the anonymous signature is written to the sub-command register, b) the sub-command is next written to the sub-command register, c) parameters (if any) are written to the parameter registers, d) followed by the CHANNEL command to the command register. This particular sequence allows the command to be passed through to a peripheral device. The device interprets the CHANNEL command as an NOP command and may respond with an interrupt. All channel devices respond to the anonymous channel command. There will be no status response from the channel devices.

[0033] The signatured protocol operates in accordance with the following sequence: a) an anonymous signature is written to the sub-command register, b) a sub-command is next written to the sub-command register, c) parameters (if any) are written to the parameter register and d) the CHANNEL command is written to the command register. Channel hardware will recognize the signature and prevent the command from being propagated further upstream towards a peripheral device. Accordingly, the peripheral device will not receive the command and will not cause an interrupt to issue. If no channel devices exist, or the command is invalid for those that are present, the device may then interrupt with the ERROR that set to I in the status register.

[0034] If the channel hardware recognizes the command, and the command is valid, the BUSY bit may be set briefly and, when it is cleared, the ERROR bit in the status register will be cleared to zero. The resulting data (if any) resides in the result registers until the status register is read or any other register is written. The alt-status register is also valid. All channel commands are executed immediately and no interrupt is provided. If commands initiate a process that takes a prolonged period of time, the command is issued in two phases, the initialization phase and the completion phase. Upon completion, the channel function will cause an unsolicited interrupt. The host is then able to issue an inquiry command in order to determine the cause of the interrupt. The nature of the inquiry command is specific to each command.

[0035] Each channel function is given a unique signature. The following Table 2 provides a list of exemplary signatures for a number of exemplary types of functions that might be implemented in an enhanced ATA Channel according to the invention. The list of Table 2 is not an exhaustive list.

[0036] Channel functions will reset to their default values in the event of a power or hardware reset. The anonymous reset command will reset the channel functions to their defaults.

[0037] In most X86 systems, the processor does not continue to process instructions while an I/O request is in progress. With the ever-increasing speed of processors, the time taken to read or write I/O registers is become insignificant. Accordingly, it will be possible to require that all commands are executed off-line and are terminated with an interrupt. However, the typical operating systems (OS) used on X86 platforms use a large amount of resources in order to service an interrupt. Consequently, channel command should be executed “immediately” and not terminated by an interrupt, or should be executed offline and terminated with an unsolicited interrupt. In the case of immediate commands, the host issues the command and then polls the alt-status register. The commands should be completed within a few clock periods.

[0038] Any command that initiates a process that will complete in an indeterminate or long period of time will operate “offline”. To achieve this, the process accepts the command and returns with a good reply code. When the process is complete, it will signal the host by asserting an unsolicited interrupt. The constitution of a “long period of time” is a matter of design choice and includes a judgement call as to the balance between host polling time and interrupt service overhead. When an unsolicited interrupt occurs, the host will make an inquiry to determine the process status. Host systems that cannot service an unsolicited interrupt will have to poll the system for status; such polling can be controlled through a system timer. Register access to the channel may or may not result in an off-line command being terminated. If the command is terminated it will generate an unsolicited interrupt (UI).

[0039] When an channel function indicates that it needs servicing, it will send a message to the host. It indicates this by asserting an unsolicited interrupt. The host will then make a message inquiry to the channel functions that are active and which are permitted to send unsolicited interrupts. In this manner, the host is in control of how it services the interrupts. The message system between host and function is a specific command sequence and thus follows the same channel command protocol as any other command sequence.

[0040] The channel command protocol is described in the following manner. This description uses pseudo code roughly based on conventional structured programming languages. This section further outlines the pseudo code conventions used.

[0041] WHILE STATEMENT

[0042] The “WHILE” statement signals the start of a process loop, functions from the start of a WHILE loop to the end of the loop or to the next WHILE or clock statement occurrence either simultaneously or in the sequence written. Later functions never precede an earlier function. The WHILE loop is initiated by a clock edge.

[0043] “CLOCK STATEMENT”

[0044] The “CLOCK” statement causes the process to pause until the next CLOCK edge. The CLOCK statements in the following description indicate where the implementation shall synchronize to a CLOCK edge. The implementation may need to insert more CLOCK edges to meet its own timing requirements. It must be borne in mind that the overall timing must meet those specified in ATA-4 for command register accesses. The implementation may need to use the assertion of IORDY to pause the host in places not indicated in the description.

[0045] “CONTINUE” STATEMENT

[0046] A “CONTINUE” statement causes the process to revert to the start of the current WHILE loop.

[0047] “BREAK” STATEMENT

[0048] A “BREAK” statement causes the process to BREAK out of the current WHILE loop. The process continues at the next statement following the current WHILE loop on the next CLOCK edge.

[0049] “IF” STATEMENT

[0050] “IF”(condition) true-function else false-function.

[0051] The channel command description uses a number of independent processes that communicate via flags. The intention is to enable the design to be implemented in a simple state machine. It is assumed that software in the host and the state machine in the channel implement the channel command protocol. The host may implement some or all of the protocol using a state machine. The protocol defines a strict sequence in which all registers are written or read by the host. If the sequence is broken, the state machine will revert to the idle state. It is recommended that the host disable host interrupts during any channel command sequence.

[0052] One of the independent processes is a device monitoring function . Those channel functions that are device dependent will have a function that continually monitors the device bit in the device register. This is a continuous function. If the device register is accessed during a command sequence, it is treated as any other register and will cause the sequence to be aborted. Note that the description includes the monitoring of the device bit and the device register. For those channel functions that are device independent, the assumption is that device monitoring is not implemented and the implied device ID is always valid. A further independent process is the command flow function. This process determines if there is a command sequence in progress and controls the initialization of appropriate processes through flags. The description of the channel command protocol uses a number of flags. These flags are defined below, followed by exemplary code illustrating the command flow.

[0053] The invention therefore provides a backward compatible method to expand the control elements of ATA-based device systems. A standard protocol is described that can be universally applied irrespective of the host hardware.