JPS63308634A - Disc drive for secondary memory of data processing system - Google Patents

Abstract

(57) [Summary] This bulletin contains application data before electronic filing, so abstract data is not recorded.

Description

DETAILED DESCRIPTION OF THE INVENTION Field of the Invention This invention relates generally to data processing systems, and more particularly to secondary (or mass) storage devices used to store data in such systems. Regarding disk drives. In particular, it relates to disk drives for secondary storage using serial communication between the controller and the drive and having information transmitted over just four conductors.

Secondary storage used in conventional technology data processing systems typically consists of a storage controller and one or more drives connected to the controller, including, but not limited to, magnetic disks and magnetic bubbles. Has memory.

These secondary storage devices, especially those using magnetic disk memory devices as drives, have become very sophisticated in recent years. However, in an effort to increase efficiency, the intercommunication between controllers and drives has become more complex. One of the most significant consequences of this increased complexity is that controllers can only be used with specific drives, and drives can only be used with specific controllers. This means that it is possible. This occurs with many communications employed between controllers and drives. Therefore, when a new drive is developed, it is generally necessary to also develop a new controller for use with this drive.

Since high reliability is required and such information must be transmitted at high speeds, cable and connector costs become significant. Such costs are directly proportional to the number of conductors required in the cable. Each conductor has at least one receiver and/or receiver for making connections at both the controller and drive ends of the cable.
Or need a transmitter.

Additionally, multiple controllers and/or drives are often interconnected via time-shared communication channels called buses. Due to the nature of the time-shared configuration, each controller can generally communicate with only one drive at a time.

Accordingly, it is an object of the present invention to provide a disk drive for secondary storage, and in particular a controller in such a device, in which the complexity and cost of intercommunication of the drive with the controller is reduced compared to conventional secondary storage devices. and the drive.

Another object of the present invention is to provide a standard interconnect for future block addressable secondary storage systems that is drive agnostic, thus allowing any mix of controller and peripheral drive configurations.

Yet another object of the present invention is to provide a controller-drive interconnect that can enable communication between controllers and drives at high bit rates.

Yet another object of the present invention is to provide a disk drive for secondary storage in which the cable between the controller and the drive is physically small, uses a minimum number of conductors, and is of reasonable length. It is in.

Yet another object of the present invention is to provide flexibility in storage system interconnection through the use of hierarchical, multi-level communication protocols.

Yet another object of the present invention is to provide a multiplication post-drive radial controller drive interconnect in which all host-controller drive buses are automatically determined.

SUMMARY OF THE INVENTION According to the present invention, a radial bus employing just four conductors and special signal handling techniques are used to effect serial rather than parallel signal transfer between a controller and a drive. This can be achieved in principle by

The radial nature of the controller drive interconnection of the present invention means that separate dedicated cables are used between each controller/drive pair. All communication is therefore between a particular controller and a particular drive via a given cable. Due to the nature of the bus, there is no bus arbitrage or drive addressing, so the structure of the bus allows for two or more drives to transact simultaneously.

Each controller drive interconnect cable has exactly four conductors, each of which represents one channel of information. This reduces the cost of cables and connections.

All channels are unidirectional and all communications are bit-serial. The first channel is used to send command messages and data to be written from the controller to the drive.

The second channel carries response messages sent from the drive to the controller and data read from the drive. The third and fourth channels carry real-time signals from the controller to the drive and from the drive to the controller, respectively, for use in periodic coordinated transmissions and to indicate significant state changes.

A multi-layer protocol is employed for controller drive communications, with the first level managing the electrical transmission of messages. The formation of command messages and data operations occurring at the second and third levels are used for command and response exchange. The protocol is synchronous and supports variable length multi-byte messages delimited by specific start and end frames. Specific command/response exchanges are identified for communicating specific parametric information about the drive from the drive to the controller. The controller needs to know this information in order to be able to use the drive. These exchanges adapt the controller to the nature of the drive.

Another command/response exchange (TOPOLOG)
Y) command response) is written to determine alternative controller drive paths so that all host-to-controller drive paths are available.

Embodiments Next, the present invention will be described in more detail with reference to embodiments of the present invention based on the accompanying drawings.

FIG. 1 illustrates the physical cable channels and their meaning. The cable (bus), generally marked 10, consists of four lines 12, 14, 16 and 18, which are used to transmit logic signals between controller 20 and drive 30. All four pass lines are unidirectional high speed bit serial channels. A status signal is transmitted on line 12.18. Serialized real-time messages and serialized drive control protocol messages and data are on line 14.
16. The status signal on line 12.18 is sent repeatedly. Line 12 provides real-time drive status M (B
TDS) signals. Line 14 carries read data and response data (RRD) messages from the drive to the controller. Line 16 carries write data and command data (WCD) messages from the controller to the drives. Line 18 carries a real time controller status ('RTC3) signal from the controller to the drive to provide coordinated synchronization transmission and to indicate significant status changes.

The information transmitted via all four channels is
ter T, McLean and 0. Winston
301.193, filed September 11, 1981, entitled Frequency-Independent Self-Time Encoding Technique and Apparatus for Digital Communications, invented by Scrgeant. is preferred, but other encoding methods may be employed as long as a self-time code is used, ie, there is no need to send a separate clock signal.

Logic signals are provided to convey sector and index pulses from each drive directly to the controller, giving the controller the information necessary to keep track of disk rotational position in real time.

As mentioned above, a three-tiered drive control protocol transmits messages between the controller and the drives. Each layer has interfaces with the layers above and/or below it, and each has syntactically and semantically defined rules used to communicate over the cable. Lower levels can be implemented in hardware or software. The lowest hierarchy, "Level O", manages the electrical transmission of messages along the cable. "Level 1" frames individual messages (identifying the beginning and end of a message and detecting transmission errors) and provides a mechanism by which data manipulation is performed. "Level 2
” is the level at which the command/response exchange occurs.

At the two lower levels, the control protocols are the same or symmetrical for commands and responses. for example,
Although the command and response have different content and length, the identification of the start and end of the message and the location of the checksum are the same in both cases. "Level 2"
The protocol, however, has commands and responses and requires asymmetric translation.

Level 2 protocols impose a strict master/slave relationship on communication between controller drives.

The controller is the master and is responsible for performing all exchanges. The drive is a slave, and its operation is primarily limited to completing the exchange by providing the appropriate response. The controller is also notified of significant changes in status by the attention mechanism.

Level 2 protocols are synchronous. Each level 2 command to the drive results in a single response from the drive when the command is executed.

The essence of the response is to indicate whether the translation and execution of the command was successful or unsuccessful. This response identifies a point that is ready for another command. By convention, commands cannot proceed in a particular order because no new command is sent by the controller until a response to a previous command is received and verified as valid, and any errors resulting from the command are resolved. Guaranteed.

Although fully synchronous, the protocol allows the attention signal to be raised to a critical error condition or status change.
This is used as a means for the drive to asynchronously notify the controller that handling is required. The controller then handles the condition by initiating the synchronous exchanges necessary to determine and resolve the condition simultaneously, when the control states of both the drive and controller are known.

The protocol supports variable multi-byte messages. Each message is delimited by a unique beginning and end, and the length of the message is implicit rather than explicit.

Definitions Before proceeding, it may be useful to define certain additional terms used herein.

"Written data" refers to data recorded on the drive. "Read data" refers to data retrieved from the drive.

A ``sync character'' is a 1'2 bit binary pattern that indicates the beginning of the transmission of primary data from the serial data line. The typical pattern used here is 1
1110101100 (arranged from left to right)
, which advances on the line after an unspecified number of leading O's, the synchronization character being immediately followed by two O's, followed by the first bit of meaningful information. A description of this synchronization character is given in Lih Jy entitled Circuit for Serialization and Deserialization of Digital Data.
co-titled U.S. Patent Application No. 06/27 filed June 17, 1981 by Weng et al.
No. 4,420, the disclosure of which is hereby incorporated by reference for this description.

The synchronization pattern is an autocorrelation pattern, and the requirement for a "match" between the synchronization pattern and the received pattern is that the output of any 9 of the 12 received bits matches the corresponding part of the synchronization pattern. That's what it means. A synchronization pattern is recorded on the disk and precedes each sector's header and data. Therefore, even if up to 3 bits are in error when sent from the disk, it will be recognized by the controller. However, the synchronization character is the communications synchronization character of the interconnect bus.
When used as a controller, the controller can require strict adaptation.

"Attention state" is a term used to indicate that a change in status has occurred in an online drive, and is critical to ensuring interaction with the controller.

A "multi-unit drive" is a single drive that is connected to a controller via a single interconnect cable and has media that is divided into multiple independent subunits. Each subunit is treated as a different logical unit to the host.

A "sector" is the smallest unit in which data can be physically addressed. Each sector occupies a particular physical location on the disk relative to its index position, and has the property that it can be written to or read from once per rotation of the disk.

Sectors are hierarchically grouped for addressing purposes. First, the disk surface is divided into one or more "cylinders", then the cylinders are divided into "groups", and the groups are divided into tracks.

A "track" is a logical entity that represents a set of sectors occupying contiguous logical disk locations.

A "group" is a logical entity representing a set of tracks such that individual tracks within a group can be selected within internal sector rotation time.

Tracks within the same group are "aligned" so that the same physical sector address can be read or written to all tracks within the group simultaneously.

A "cylinder" is a logical entity that represents a collection of groups that can be selected by an operation with a rotational latency that is less than the minimum "seek" time.

From the above definitions it can be seen that the terms track, group and cylinder are independent of the physical features or structure of the drive. Tracks, groups and cylinders simply relate to each other's sectors as a function of access characteristics.

The position of the "sector number" of the physical sector address is always at the lower position. The "track number" of a particular sector's physical address is always at a position halfway between the group and sector address. For a particular sector's physical address, the "group number" is always a position midway between the cylinder and track addresses.

The "cylinder number" of the physical address of a particular sector is always at the top position of the address.

A "frame" is a 16-bit quantity that constitutes the smallest unit of control information that can be passed between a controller and a drive by the interface hardware. Every frame is conceptually divided into two 8-bit bytes.

What is “Control Message”? “Start Frame”
A set of sequentially transmitted frames starting at ``end frame'' and ending at ``end frame''. The contents of this message consist of messages that carry information between the controller and the drive. A "command" is a control message sent from the controller to the drive, and a "response" is a control message sent from the drive to the controller. An "exchange" is a pair of control messages. The first message is a command issued by the controller and the second message is a response sent by the drive.

A "command timer" and a "response timer" are mechanisms within the drive and controller, respectively, that are used to monitor subsystem operation. These timers maintain the minimum system activity necessary to ensure that both the drive and controller are still active, and indicate "inactivity" if the minimum activity is not maintained on either the controller or the drive. give a signal to inform.

"Drive offline" is a state of a drive associated with a controller. When in a "drive offline" state, the drive is not operated and cannot communicate with the controller via the drive control protocol.

"Drive Unavailable" is another state of a driver associated with a controller. In this state, the driver is in operation, transparent to, and able to communicate with the controller from time to time. However, because the drive is "drive online" to another controller, the controller cannot fully utilize the drive.

"Drive available" is another state of the drive relative to the controller. In this state, the drive is transparent to the controller and can communicate and be "drive online", but is not currently "drive online" to any particular controller. .

"Drive Online" is another state of a drive associated with a controller. In this state, the drive is dedicated to the exclusive use of a particular controller and is not available to alternate controllers.

"Generic status" is a subset of status information maintained by a drive that is independent of drive type and provides basic information necessary for normal drive operation.

The "request byte" is one of the status bytes in the generic status, and is used as a signal to request controller operation from the drive.

The "error byte" is one of the other status bytes in the generic status and is used for signal error conditions that prevent normal drive operation.

"Mode Byte" is another status in the generic status that is used by the controller to remember the current state of alternating drive operating modes.

The table in Cable Signals FIG. 2 summarizes the overall nature of the information on each of the four lines of bus 10 carrying information from a given drive to a given controller as a function of the state of the drive relative to the controller. ing.

Some comments would be helpful in clarifying and explaining Figure 2. First, an indication of rOFFJ means that there is no transmission. Second, data on the RRD line 14 in the "Drive Enabled" state is sent only to the command boat if there are multiple ports. Thirdly, “
In the ``Drive Unavailable'' state, the drive does not receive the status of the controller. Fourth, "clock" in the "Drive Offline" state means that the drive sends a status clock rather than a status byte. Fifth, RTDS line 12 is rOFFJ (ie, no transmission occurs) while the drive is initializing, fails, or the drive's port is disconnected. Sixth, in the "drive online" state, the RTDS channel is rOFFJ while topology commands (described below) are executed. Additionally, seventh, when a drive is executing a topology command, a line to a "drive-unavailable" drive temporarily assumes the same characteristics as for a "drive-enabled" drive.

The RTDS signal on line 12 is used to send six logic signals from the drive to the controller. It is required to synchronize controller/drive operations. One byte follows the zero cobyte. This two-byte pattern is sent sequentially by the drive to all possible controllers of the drive boat switch.

The RRD signal on line 14 transmits self-timed digital data from the drive to the controller, LSB first. Two types of information are sent over the RRD line. (1) Read data retrieved from the disk surface and (2) response messages from the drive to the controller.

The WCD signal on line 16 transmits self-timed digital data from the controller to the drive, LSB first. Three types of information are sent over the WCD line. (1) write data recorded on the disk surface, (2) command messages from the controller to the drive, and (3) real-time data transfer commands.

The RTC3 signal on line 18 carries four logic signals used to synchronize controller/drive operation. The RTC3 signal is a pattern of a single byte followed by a "zero" byte.

These two byte patterns must be sent repeatedly whenever a drive is selected by the controller. The controller can send this pattern continuously to the drives that are "drive online" or
It is also possible to transmit only when a drive is selected. It is the drive's responsibility to maintain the last "state" taken and assume that this state is correct until an update is taken.

When switching status transfer operations between drives, the controller completes the status word for the current drive and begins with the completion word (including preamble) for the new drive. Due to the skew that can occur in synchronization, status bits cannot be encoded. That is, the state bits must be able to change correctly independently of each other.

Synchronous detection is accomplished by detecting at least seven 0s followed by a 1.

FIG. 3 illustrates the RTC3 signal and clearly indicates the location and meaning of each bit of this signal. bit 42
is the first bit at the end of the synchronization pattern, which gives the receiver ready signal. (There are two receiver ready signals, one from the controller to the drive and the other from the drive to the controller.) It is a signal to

Both are logic signals, and declaring this signal is used to indicate that the emitting part is in command mode and ready to receive frames of messages. ) Bit 44 has the INIT signal. This signal is a logic signal from the controller to the drive and is used as a drive initialization signal. The standard sea fence used by the controller to initialize the drive is I
The NrT bit should be declared. Each time the controller is powered or reinitialized by a host or operational command, the controller generates an INIT signal to all drives to which it can be connected.

This is used to synchronize drives that wait until a controller becomes active, and does not affect drives that are "drive online" to another controller.

The leading edge of the INIT signal instructs the drive to do the following:

(2) Abort all operations within the conchext, including the transfer of any data, and if possible controllably stop all mechanical movements; do.

(3) Within a predetermined period after the controller declares the INIT signal, stop all transfers on the RRD and RTDS lines for a predetermined period.

(4) Save generic and extended status when interrupt occurs (see below).

(5) Re-initialize sea fencing and possibly perform minimum maintenance diagnostics.

(6) Upon completion of the reinitialization sea fence, load the rDFJ status bits, update another generic extension status to the appropriate current value, return to the previous state of the driver related to all controllers, and and/or claim availability. Finally, the driver declares the receiver ready and completes the initialization sea fence signal.

Bit position 46 carries the "read gate" signal.

This signal is a logic signal transmitted from the controller to the drive. During a data read operation, a read gate is declared after the header splice and before starting the data field preamble. The trailing edge of the read gate indicates to the drive that the current data transfer command is terminated.

Bit 44 has a write gate signal. This signal is a logic signal transmitted from the controller to the drive.

The end of the write gate signal indicates to the drive that the current data transfer command is finished.

The format of the RTDS frame is shown in FIG. As shown, the frame 60 includes an 8 O preamble 60A followed by a sync bit 60B of 1;
6 information bits 62-72 and parity bit 76
Consisting of

Bit 62 is the receiver ready signal. This signal is a logic signal and declaration of this signal is used to indicate that the drive is in command mode and ready to accept command frames.

Bit 64 is an attention signal. This signal is a signal from the drive that is used to inform the controller that a potentially significant status change has occurred in the drive. If it is appropriate to declare an attention for a drive in Drive Online,
An attention signal is declared regardless of whether a command is in progress. The drive continues to declare the attention signal until the drive receives the correct status acquisition command from the controller. This signal is dropped immediately after receiving the end frame.

Bit 66 carries the read/write signal. This signal is a logical signal from the drive to the controller indicating that the declared drive is capable of handling data transfers to and from the disk surface.

Bit 68 carries the sector pulse signal. This signal is a logical signal from the drive to the controller, and signals that the head is at the boundary of one of the sectors dividing the disk. The controller uses the leading edge of the sector pulse signal for rotational position detection and the trailing edge as the starting point of the sector.

The sector pulse signal must be continuous for at least 32 status bit transmissions for the embodiments presented herein.

Bit position 72 carries an index pulse, a logic signal from the drive to the controller that is declared once per revolution. Like the sector pulse signal, the index pulse signal must last for at least 32 status bit transmissions. - The controller uses the leading edge of the index pulse for rotational position detection or the trailing edge to mark the starting point of sector number 0.

Bit position 74 has an "enabled" bit. This bit is a logic signal from the drive to the controller indicating that the drive is in a "drive ready" state. This signal is declared whenever the drive enters the "Drive Enabled" state, remains asserted as long as the drive is in this state, and is pulled down when the drive leaves the "Drive Enabled" state.

Drive control protocol The following general rules govern drive control protocols.

First, only one command or operation can remain on the drive. The controller cannot initiate another command or operation until a response to the current command is received.

Second, every command from the controller to the drive initiates an exchange. After issuing a command, the controller sets a response time and enters a state in which it waits for a response to the issued command. When the response time expires, the controller assumes that the message was not acknowledged. Third, some level 2 commands may result in operations on the drive that extend beyond the completion of the exchange. In this case, completion of the drive operation is signaled in one of two ways. (1) generation of a read/write ready signal indicates successful completion; (2) reporting of error information by the attention mechanism signals unsuccessful completion. To this command the controller depends on the response itself as well as on the suspension of the entire operation. For all other commands, completion of the exchange signals the completion of the operation.

Fourth, the drive cannot transmit messages to the controller except in response to commands. This is enforced by the controller as it does not declare receiver/ready unless it is specifically waiting for a response.

Drive States Related to the Controller A drive can be in one of four states related to the controller. These states differ in the way the drive receives commands and INIT signals sent to the controller through the drive's boat, the way the drive handles panel switches, and the degree of controller transparency and control over drive operation. Referring to Figure 5, a description of the drive states and how they leave and enter is shown. There are four possible dry control states, these are "drive offline" (Li 82), r drive unusable” (Article B84),
``drive available'' (state 86) and ``drive online'' (state B82).

A "drive online" state is a state in which the controller is unable to communicate with a Level 1 or Level 2 drive. There may or may not be state transmitted from the drive. (1) A drive is forced into a "drive offline" state due to some catastrophic failure.

(2) The drive becomes unavailable to the controller due to a change in the boat select switch. (3) The unit selection mechanism is released and the drive failure indication mechanism is activated. or (4) the drive enters a "drive offline" state with respect to a particular controller whenever the drive runs out of power.

Assume that the drive is in a "drive offline" state 682. When the boat switch or unit selection mechanism is enabled, step 92, or when power is applied or a hard fault is cleared, step 94, the drive can leave the state associated with the particular controller. Step 96: Isolating the hard fault or applying power leads to reinitialization of the drive.
Enabling the boat switch or selection mechanism causes the drive to start its status byte and declare it enabled, step 98. This is also the case if initialization is successful following step 96. When on a business trip, the drive is marked H86 "-Drive available"
become.

A drive in the "Drive Unavailable" state is transparent to the controller and can communicate with the controller from time to time, but is not fully utilized by the controller because it is not "drive online" to another controller. "Drive Unavailable" If a drive cannot communicate with the controller at all, it will forward status signals to the controller, but will not respond to the controller's status signals and will not provide any clocks to the data lines. do not.

Whenever a drive enters the ``Drive Online'' state, a ``Drive Unavailable'' error occurs that pertains to all controllers except the controller for ``Drive Online.''
The drive becomes in the state.

Whenever a drive leaves the "Drive Online" state, it becomes "Drive Unavailable" for all controllers except the controller for "Drive Online".
Drive leaves the state. As shown in FIG. 5, in order to reach the "Drive Online" state 88, the drive must first be "Drive Available"86;
Then the receiver takes the correct online command. At this point, availability is removed. This is step 102. Once in the "Drive Online" state 88, I
This state can be re-entered in response to the NIT signal step 104 and the drive reinitialization success step 106. Unsuccessful initialization results in a return to the "drive offline" state 82. Hard failure step 108 similarly changes the state from "drive online" to "drive offline."

There are two possibilities for a drive to be in a state other than "drive online." First, spontaneous reinitialization returns to step 96 which starts the initialization procedure. Second
Then, expiration of the command timer or receipt of the disconnect command step 112 causes a return to step 98.

``Drive available'' status [It is not clear whether the drive in 86 can communicate. A multiple boat drive that is "drive enabled" will receive and accept INIT signals from any boat. It also receives commands from any boat. A drive in the "drive ready" state has a disk present and spinning, and may or may not have a head loaded. While in the "Drive Enabled" state, the drive responds locally to changes in drive switch settings and does not report an attention condition to the controller, but an attention signal does report that the drive is capable of starting rotation. used for.

A drive enters the "drive ready" state associated with a particular controller when:

1. The drive is in "drive offline" state,
If it is not clear that initialization was successful and that the controller can be communicated with.

2. If the drive is in a "drive offline" state because the boat is disabled by a panel switch, and the boat becomes available by changing the switch.

3. The drive is in the [Drive Oscilline] state,
When receiving a disconnect command from the controller.

4. The drive is in "drive online" state,
You determine that the controller is inoperable because the controller's command timer has expired.

5. The drive is in "drive online" state,
If it initializes spontaneously due to conditions such as a temporary power failure where continuum is lost.

A drive leaves the "drive ready" state associated with a particular controller in the following cases:

1. If the drive receives the correct online command and goes to the "Drive Online" state, 2. If the drive receives a correct online command and goes to the "drive online" state, 2. If the drive loses power or the boat becomes unusable due to a change in a panel switch or has a malfunction that prevents it from communicating with the controller. By detecting the drive
If the drive is placed in a "offline" state.

3. If reinitialization in response to an INIT signal fails and the drive is placed in a "drive offline" state.

Whenever a drive is in the "Drive Enabled" state, the drive informs the controller that the drive is "Drive Enabled" by declaring an enable signal. While the enable signal is declared, the drive receives commands or TNIT signals from all enabled controllers. A drive that is "drive available" for a particular controller will be "drive ready" for all controllers that the port switch can use at the same time.
The drive becomes ready for use. For controllers whose port switches cannot be used, "drive offline" occurs.

A drive in the "Drive Online" state is dedicated to the controller for "Drive Online" and ignores controller signals from all other boats. A drive in the "drive online" state will attempt to execute all commands received.

If the physical status is inappropriate and the command cannot be executed, respond with an appropriate error code in the status summary section of the unsuccessful response.

Live will be in "drive online" state. Any of the following cases will cause the drive to leave the "drive online" state.

1. Reception of disconnection command. This puts the drive into a "drive ready" state.

2. Occurrence of power supply outage or other failure that interferes with communication. These mark the drive as "drive offline"
state.

3. Failed to reinitialize in response to INIT signal. This puts the drive in a "drive offline" state.

4. End of command timer. This causes the drive to determine that the controller is inoperable and needs to return to a "drive ready" state.

5. Temporary reinitialization for conditions where continuum is lost.

A drive that is in a "drive online" state with respect to a particular controller simultaneously becomes a "drive unavailable" state with respect to another available controller. A drive in the "drive online" state does not change the drive status in response to a change in switch settings; rather, when the drive detects such a switch change, it uses an attention mechanism and controls the switch change. Report to. The controller determines how the drive responds. "Drive Enabled" where the controller can issue direct commands that affect a status change or locally affect a status change
Issue a disconnect command to put the drive into the state.

Although the slight time delay is normally imperceptible to the operator who moved the switch, the controller delays the action of changing the switch settings until all previous operations on the drive have been completed.

Using Attention Signals The Drive Online drive uses attention signals in four ways.

■ The drive shall be activated by declaring an attention signal whenever the command timer expires or one of the generic status bits changes and such change is not the result of correct operation of a level 2 command or an error. Induces Attention Sea Fence. In response to the attention signal, the controller initiates a status acquisition exchange to determine the new status of the drive. By comparing the obtained new status information with the previous status information, the characteristics of the attention condition are determined.

The controller eventually resolves the attention condition requiring further action by initiating the appropriate exchange at a later time.

2. Between the time the drive declares an attention signal and the correct status acquisition command issued by the controller, the drive determines that the controller has been notified and best executes the current command (if any). continue. Any other status changes that occur to the drive before the status is completed are reflected in the response to the next valid status question command.

3. Upon receipt of a correct status command following declaration of an attention signal by the drive, the drive drops the attention signal and responds with an appropriate response providing details of the current status. After the status complete command is received and verified as correct, the attention signal must be immediately dropped by the drive before the command can proceed and a response can be made.

This avoids conditions where a status change occurs and goes undetected while processing the current status completion.

4. The controller tries to act on outstanding attention signals as fast as possible. However, during attention generation and status questioning due to conditions, the driver can expect to learn of other unrelated commands. While an unserviced attention condition is not handled, the drive processes all commands normally.

If the attention condition is caused by an error, the status question and answer is accepted and the drive rejects subsequent head movement and data transfer commands until the error condition is cleared.

The command and response timer controller controls all drive command and I10
Adopt a response timer to time the operation.

Downtime is determined by the drive. Parameters specific to each disk and made known to the controller by the drive. When any frame other than a message communication or end of message is ready to be transmitted to the drive, the controller sets the timer start command and the duration of the timer according to the characteristics of the drive. The timer is reset upon receipt of a data operation response or completion message end frame.

If the timer expires, the controller "assumes" that the drive has failed and will attempt to resynchronize with the controller by issuing an INIT signal.

Correspondingly, a drive in a "drive online" or "drive ready" state clocks controller operations. Complete drive command timer operation is shown in FIG. Whenever a ``drive ready'' drive receives or receives a message start frame, the drive starts a timer. Step 122゜Message end frame from controller (Step 124
) stops the timer (step 126). If the timer expires while the attention is declared, the drive determines that the controller is "inactive" (as determined by test step 128). Similarly, the drive (1) begins transmitting a response message start frame (step 134);
(2) Declare an attention signal (step 126)
or (3) the "drive online" drive starts a timer when it is ready to complete the data transfer operation. When a message end frame of a command or a data transfer command is accepted by the drive (step 124), the timer is stopped.

Level O The format of the control propagation for each level O carrying cable 10 is illustrated in FIG. R as shown
Transmission over the RD and WCD lines uses a 32-bit transmission consisting of a 16-bit command frame followed by a 16-bit synchronization word. The synchronization word 152 is processed at level 0, and the command frame 154 is processed at level 1. All 32 bits are transmitted as a single unit and the start of 32 bit transmission is triggered by declaring a ready to receive signal. The sync word frame begins with two 0 bits, followed by a 12-bit sync character, followed by two more 0s (Level 1 frame 154 is a 16-bit control frame.

Level 18A-81 illustrates each possible Level 1 frame format. Each frame is transmitted in separate 32-bit level O transmissions. Receipt of a message start frame code 162 (shown in FIG. 8A) in the upper byte of a level 1 frame 161 indicates the start of a new control protocol message. The lower byte 164 of the transmission is interpreted to be the first byte of the message.

The receipt of the message continuation frame code 166 indicates that the lower byte of frame 165 is the next byte of the message in progress, as illustrated in FIG. 8B.

Receipt of a message end frame code 172 in FIG. 8C indicates that a full control protocol message has been transmitted and a checksum is available in the lower byte 174 of frame 171.

The checksum is the completion of all message bytes starting with the message data byte of the message start frame and ending with the message data byte of the last message continuation frame.

If the additional,operation on any term is a carry from the high order bit, the,checksum is incremented before the next term is added. The checksum is completed after all addition and increment operations for all terms are completed. A checksum error indicates an error in the transmission when a valid message end frame is received or missed. Framing codes are not included in the checksum.

Group selection frame code 176 beyond exchange range
The reception (shown in FIG. 8D) requires the drive to flag read/write ready, swapping the Ilo position for the group identified in the lower byte 178 of frame 175, and exchanging the Ilo position for the particular group. Indicates that the read/write readiness is increased when the read/write readiness can be achieved.

If the position translation operation fails, the drive remains read/write ready and reports this failure as a drive error via the attention mechanism.

Track selection and reading code beyond exchange range 1
82 or receipt of track selection and write code 188 (shown in Figures 8E and 8F), the drive should select the appropriate track identified by byte 184 or 188 (frames 181 and 185, respectively). Yes, indicating that a particular data operation will begin at the next sector or at the end of the index pulse.

Receiving track selection and index format codes 192 (shown in Figure 8G) beyond the range of exchange requires that the drive select the appropriate track identified in byte 194 of frame 191 and the rFOJ status bit is If available, certain data operations starting at the end of the next index pulse (i.e.
Indicates that sector formatting is to begin.

Receipt of a format code 196 for a sector or index beyond the range of exchange indicates that the drive should use the last selected track, and at the end of the next index or sector pulse if the "FO" status bit is enabled. Indicates that a specific data operation is to be started.

The lower byte 198 of frame 195 is undefined.

Receipt of the diagnostic echo frame code 202 shown in FIG.
(using a diagnostic echo frame code) must be transmitted to the controller. This code is used to establish line and transmission logic integrity.

The lower byte 204 is undefined.

Receipt by the drive of any framing code other than the above nine framing codes is considered a transmission error.

Receipt by the controller of a framing code other than Message Start, Message Continuation, Message End, or Diagnostic Echo is considered a transmission error. Receiving and receiving correct framing codes in an order other than the specified order is also considered a transmission error. Once the message start frame is transmitted, all frames other than message continuation frames are illegal until the message end frame is acknowledged. Receiving or receiving frames other than message continuations within the scope of the exchange is considered a transmission error.

A "transmission error" is an error detected by a level 1 mechanism. If the drive detects a transmission error, it needs to make sure that the read/write ready is taken down (taken down when it starts receiving frames, etc.). At this time, the drive becomes receiver ready and receives additional frames until the Message End Frame code is received.

At this point, the problem is reported with an unsuccessful response (using the rREJ error indicator). Depending on the reason for the transmission error,
The following cases apply:

1. Errors in Message Start or Message Continuation frames result in synchronization failure responses triggered by Message End frames. No reinitialization is required.

2. Message end frame errors cause the response timer to expire because the driver never responds.

3. If a data transfer or pharmaceutical command is miscommunicated, the controller will pause at read/write ready.

4. If a frame into a Message End frame is misdirected, both the controller and the drive wait for receiver ready for another part, and they never come, causing the response timer to expire.

If level 1 processing in the controller detects a transmission error, it must wait for a message end frame code before initiating recovery procedures. The response timer protects against malicious end frame codes. The drive does not declare an attention to report transmission errors.

Controller recovery from a transmission error consists of questioning the driver status, clearing any errors, and reissuing the erroneous command. If the message end frame is accepted and the response timer expires, the drive must be reinitialized before recovery processing. After a transmission error is detected, the controller attempts transmission again only once.

Framing code (i.e. high byte of each frame)
provides sufficient information for the receiver to accomplish selection signal bit error correction and double bit error detection.

The minimum number of level 1 frames transmitted as a result of a single transaction is the minimum number of level 1 frames transmitted as a result of a single transaction, if the transaction is a track select and read, track select and write, diagnostic echo, group select, track select and index format, or sector or index format command. If it is for one frame, it is one frame. If the transaction is for a message transmission, the minimum transmission is two frames. (i.e., message start frame and message end frame). The maximum number of Level I frames that can result from one transaction is 64 frames (i.e., Message Start frame, 62 Message Communication frames, and Message End frame). A flowchart for processing Level I frames is shown in FIG. It is shown in FIG. FIG. 9 represents the operation of the controller for level 1 transmission. Correspondingly, the operation of the drive for receiving and taking transmissions is illustrated in FIG. The drive transmits to the controller according to FIG. 11, and the controller receives the response as shown in FIG.

Level 2 Transmission The format of a Level 2 message is shown in FIG. The level 2 operation code transmitted in the first byte 402 of the level 2 message consists of 7 bits and the upper even parity bit. 404a to 404n carry operation codes and related parameters.

The minimum level 2 message size is 1 byte, ie, the operation code. The maximum level 2 message size is 63 bytes. The frame composition has already been mentioned. The number of parameters in any given message is a function of the message itself. If a message always has a fixed number of parameters, the parameters typically follow directly from the operation code. If a message has a variable number of parameters, it is expected that one of the parameter bytes will be used to indicate a count of the number of remaining parameter bytes.

Level 2 messages must be corrected before they can be activated. Level 2 information is not processed at all if a transmission error is detected at level 1.

The following conditions are treated as level 2 protocol errors. Invalid operation code, invalid or incompatible parameters or incorrect number of parameters for operation code or byte count, and correct operation code or parameter that does not match the current state or physical status of the drive.

The drive recovers from a level 2 protocol error by returning an unsuccessful response to the controller with a protocol error (rPEJ) indicated in the status summary. Conversely, the controller recovers from a level 2 protocol error by clearing the error and retrying the command after any necessary corrections. It will be retried only once.

All level 2 commands are accomplished in the controller according to FIG. Next, the process of FIG. 15 is called to send a level 2 message from the controller to the drive. The drive performs the transmission as shown in FIG. The controller then receives the level 2 response shown in FIG.

In the illustrated embodiment, command mode, controller flag conversion, diagnostics, drive resolution, error recovery, common characteristic acquisition, subunit characteristic acquisition, status acquisition, seek initiation, online, run, memory read, realignment, topology There are 16 possible controller commands for and memory writes. Only certain of these commands are important to warrant detailed explanation.

Mode conversion modes are handled by the controller as shown in FIG. 18 and by the drive as shown in FIG. The format of the command is shown in FIG. This command tells the drive to convert the drive's mode to a specific mode setting. The command operation code is included in byte 404. Byte 404b is a mask for byte 404a.

pi only on the bits in byte 2 to be operated on)
The corresponding bit in 404b is set.

Other mode bits remain unchanged.

Mode bits W1-W4 in byte 404a correspond to write protect flags. If one of these bytes is masked and its value is 1, the corresponding subunit must be write protected.

If the value of the masked bit is O, the subunit is writable. A request to enable a subunit will be rejected by the drive unless the write enable/write protect switch is in the write enable position. (A non-multi-unit drive is the same as a degenerate multi-unit drive with only one subunit.)
Permissible responses are (1) failure for the reason indicated, or (2) completion indicating that the drive is currently operating in the requested mode setting and is in write-protected status.
These responses are generic to level 2 and are returned to all commands except those for responses containing status information.

Similarly, the controller flag conversion command is a 3-byte command. FIGS. 22 and 23 show the processing of the controller and drive in response to commands, respectively. The format of the command itself is shown in FIG. This command directs the conversion of specific bits of the status of the "controller byte" to the supplied values. Byte 402 contains the operation code for the command. Byte 404b is a bitmask for byte 2. Only for bits in byte 404a that are to be acted upon will the corresponding bit in byte 404b be set. Other bits are not changed.

The functionality of the diagnostic commands is not important to the current discussion and has been omitted for clarity.

Processing of a disconnect command by the controller and drive is shown in FIGS. 24 and 25, respectively. The disconnect command instructs the "drive online" drives to enter the "drive ready" state for all active ports. The command format is shown in FIG. There, the command operation code is shown in byte 402. If the rsTJ bit in the "qualifier byte" of this command is not O, the drive will stop the disk from spinning. If the rSTJ bit is O, the drive does not change the state of the spindle. When disk rotation cannot be manipulated, the drive simply initiates a stop operation and waits until the rSRJ status bit goes to O before reporting success. The drive doesn't wait for the disk to stop. The rTTJ bit (ie, the MSB in byte 404) is used to evict the drive, allowing it to return to the online boat.

The Drive Dissolution command is not important to the current discussion, and a description of its operation has been omitted for clarity.

Error recovery commands are processed by the controller and drive as shown in FIGS. 27 and 28, respectively. This command initiates a drive specific error recovery mechanism. While drives can (and preferably do) use multiple error recovery mechanisms (ie, multiple levels), the controller does not need to know the details of those error recovery techniques, and they can vary from drive to drive. The controller knows the drive's error recovery mechanism simply by number. For example, the highest numbered mechanism has the greatest a priori probability of success. The remaining mechanisms are ranked and numbered according to decreasing probability of success. The controller starts by requesting that the drive use the first (ie, highest number) error recovery mechanism. If this fails, the controller then
etc. mechanisms are required. It is the duty of the drive designer to provide recovery mechanisms suitable for a particular drive and to arrange them most effectively. The format of this command is illustrated in FIG. The operation code of the command is transmitted in byte 402. The error recovery level is also sent in byte 404.

Initially, when the drive characteristics are returned as a response to the Get Common Characteristics command, a data error occurs that cannot be corrected by using an error correction code that indicates how many error recovery levels the drive has. At some point, the controller issues one or more error recovery commands. The top level is used first and failed operations are tried again after each level. If still unsuccessful, the next level is attempted. This continues until the operation is successful or until all possible error recovery levels (and mechanisms) are exhausted.

It should be noted that only the controller knows whether the error recovery was successful or not, and therefore only the controller can decide whether to proceed from one error recovery level to the next.

Conversely, error recovery commands are intended only for recovery from data errors detected by the controller. Other errors are handled by the drive or by retrying another command.

The common characteristic acquisition command is a 1-byte command having the format shown in 1-byte 402 in FIG.

This command is processed by the controller as shown in FIG. 31 and by the drive as shown in FIG. This command requests that the drive send a description of characteristics common to all subunits of the drive to the controller.

When the replacement is complete, the state of the drives remains unchanged for all controllers. This command has the status "
Correct when ``Error Byte'' correctly refers to all ``Drive Unusable'' drives rather than O.

The responses received for the Get Common Features Command command are (1) Unsuccessful, for the reason indicated, and (2) Get Common Features Response, the format of which is shown in FIG.

As shown in FIG. 33, the common characteristic acquisition response has a sea fence of 23 bytes. The first byte 502 indicates the nature of the response and may be encoded as shown, for example. The lower half 504a of the second byte 504 is a "short pause" representing the time used to pause operation under adverse conditions, other than for diagnosis, execution and reconditioning.
(expressed as a power of 2). This time is necessary for drive control to be attempted again.

The upper half 504 of the second byte 504 indicates the version of the communication protocol employed by the drive, ensuring controller and drive compatibility. The third byte 506 has a number proportional to the transfer rate of the drive. The lower half 508a of the fifth byte 508 has a long limit, which is the time used for diagnostic, execution, and reconditioning operations. These meat quantities are also provided with downtimes that are compatible with long ones. Upper half of byte 508 508
The "retries" entry in the field indicates the number of times the controller will retry the data transfer operation before giving up. (Of course, all errors that do not result in a data transfer are retried only once.) The next byte 510 is similarly divided, but this time into three parts. The lower half 510a of byte 510 indicates the number of copies of the format and the revecter maintained on the drive.
or) Contains information about the number of copies of the control table. (For a more complete discussion of format and revector control tables, see the aforementioned application entitled Disk Formats for Secondary Storage Systems.) The next three bits 510b
is vacant. The top bit 510c has sector size information of 0. For example, if the drive only employs 512-byte sectors, it has 0; it employs 576-byte sectors (or 576-byte sectors where only 512 bytes are used). If so, it has 1.

Byte 510 contains the number of error recovery levels available on the drive.

Byte 514 has a number representing the number of symbols in error that are considered significant enough to initiate a recovery operation.

Therefore, if this threshold is exceeded for a particular sector, as a precautionary measure this sector is replaced by a separate sector prepared for this purpose. When a sector degrades to the point that the error correction code can no longer repair the data, the data is written to isolated sectors to avoid data loss. Subsequent accesses to the bad sector are redirected to alternative sectors.

Byte 516 contains instructions for modifying the microcode running the drive.

Byte 518 is divided such that the lower seven bits 518a contain the hardware revision number.

Bytes 520-530 contain a unique drive identifier or serial number. Each drive has its own unique number in these bytes.

Byte 532 contains the drive type identifier.

Byte 534 has a number representing the rotational speed of the disk (revolutions per second), and 536-546 have error threshold information.

The subunit characteristic acquisition command is a 2-byte command having the format shown in FIG. Part-time job 4
02 is the operation code and byte 404 has the subunit mask in the upper half. The controller and drive processing of this command is shown in Figures 35 and 36, respectively. The function of this command is to request that the drive send to the controller a description of the geometrical characteristics of the subunits defined in the subunit mask. This mask, which must have exactly one bit, is placed in this command.

This pin must be one of the pins placed in the subunit mask restored by the common property command.

The response taken to the subunit characteristic command is unsuccessful for the reason indicated or is shown in FIGS. 37A and 38 and has a 39 byte format.

The first byte 602 of the response in the format shown in FIGS. 37A and 37B is preselected to have a fixed pattern as shown.

pi) 604-608 and the lower half of byte 610 6
10a indicates the size of the LBN space within the subunit within the cylinder. Next 3 bits 610 in byte 610
b represents the number of the highest cylinder. MS8610C is always 0. Byte 612 contains the number of groups per cylinder.

Byte 616 is the number of tracks per group. L
The BN space starts at the address indicated by the lower half 614a of byte 614. The lower half of this byte gives the address of the upper half at which to start joining the LBN. The starting addresses of the XBN, RBN and DBN spaces are similarly indicated by the upper half 614b of byte 614, the lower half 618a and the upper half 618b of byte 618.

Byte 620 has seven bits indicating the number of replacement blocks (ie, RBN'S) per track and an eighth bit that is not relevant to the current discussion.

As shown, there is no function assigned to byte 622. This byte is reserved for use when special bytes are needed.

The data and header preamble sizes (in words) are given in bytes 624 and 626, respectively.

The media type is written in bytes 628-634. This indication may relate to the manufacturer's drive type, for example. Bytes 636 and 638 contain an indication of the size of the copy of the Format Control Table (FCT).

When a disk drive employs one of two formats with bytes per sector, the subunit characteristic response specifies that the first group of bytes (e.g., bytes 640-654) and a second
Group bytes (eg, bytes 656-67o). These formats are, for example, 512
and 576 bytes/sector. Bytes 640 or 656 depending on the situation give the number of LBNs per track. The group offset for serial readout is indicated by byte 642 or 658. Part-time job 644-65
The content of o (lower half) or 660-666 (lower half) is the number of LBNs in the host application area. That is, the size of memory given to the host for the application.

Bytes 652 and 654 or 668 and 670 are LBN
Indicates the size of one copy of the RCT in numbers.

The size of the XBN space in the cylinder is bytes 67
2 and 674. Byte 676 contains the size of the diagnostic read area in the group. Part-time job 67
8 represents the size of the DBN space in the cylinder.

The status acquisition command is a 1-byte command having the format shown in FIG.

This command is processed by the controller as illustrated in FIG. 39 and by the drive as illustrated in FIG. 40. This command is used to request that the drive send its alive status to the controller. When the command is completed and verified as correct, the "drive online" drive drops the attention signal if declared.

Two possible responses are (1) Unsuccessful, for the reasons indicated. and (2) a status response in the format shown in FIG.

In FIG. 41, byte 682 contains the 8 least significant bits of the 12-bit unit number. The remainder of the unit number is contained within the four least significant bits of byte 684. Part-time job 68
4 (lower via) 484b includes a subunit mask.

Bytes 486-690 contain "generic status bits."

In particular, byte 686 is the "request" byte.

The least significant bit rRUJ in byte 686 indicates the status of the run/stop switch.

For example, the lower bit rP of the 0th order is 0 when the switch is not on, and 1 when the switch is not on.
sJ indicates the status of the boat switch. It is O when the switch is not on, and it is 1 when the switch is on. The fourth bit "EL" is byte 696-7
08 indicates whether or not it has useful information, "1" indicates a positive declaration, and the fifth bit rsRJ indicates whether the spindle is ready or not. For example, if the bit is O, the spindle is ready. Not ready, not up to speed. If the bit is 1, the spindle is ready. The next bit "DRJ" indicates whether diagnostics are required.

The next rRRJ bit signals whether time is needed to perform internal operations. The most important bit “OA”
” indicates the drive status. If O, the drive is ``Drive Online'' or ``Drive Available'' to the controller, and if 1, the drive is ``Drive Unavailable'' to the controller (of course, the drive is ``Drive Unavailable'' to the controller. (It may also be "online.")

Byte 688 is the "mode byte." The least significant bit of this byte, "S7", signals the sector format. For example, the controller will work with drives that employ a 512 byte sector format or a 576 byte sector format. The "S7" bit signals the controller regarding the format adopted by the drive. The second bit in this diagnostic cylinder byte is the rDBJ bit, which signals whether external access is possible. The third bit in the mode byte is the rFOJ bit, which signals whether format operations are enabled or not.

The next rDDJ bit indicates the drive enable/disable condition. It is 0 when the drive is available for use by a controller error routine or diagnostics, and 1 when the drive is not available for use by a controller error routine or diagnostics. Bits W1-W4 signal whether the write protect switch is turned on for the subunit associated with each bit. (Note that it is common practice in the industry to use "write protection" circuits to prevent unintentional writes on data that is to be saved.) Byte 690 is the "error" byte. . The first three low order bits are blank. The fourth bit rWEJ is the write lock flag and is 1 if a write is attempted to the drive while it is write locked. next bit r
DFJ signals an error in the initialization diagnosis. 6th bit r
PEJ signals a level 2 protocol error. The next bit "RE" signals a transmission error. The most important bit rDEl signals a driver error.

All focuses in the error byte are set by the appropriate drive and cleared by the controller via the drive clear command.

Byte 692 is called the "controller byte." All bits within the controller byte are changed by the controller flag conversion command and are ignored by the drive except when cleared by the drive under appropriate state conditions. C flag (Cn) and S flag (Sn)
is cleared whenever the drive is "drive offline" to all controllers. All bits within the controller byte are preserved across INIT operations.

Byte 694 contains a count of the number of retries or an error code.

Bytes 696-708 have extended status specific to the drive type for logging.

The subunit mask defines how many subunits there are in the drive. The subunit is proven to be the location of focus within the mask.

Online commands have a two-part format as shown in FIG. 42 and are processed by the controller as shown in FIG. 43 and by the drive as shown in FIG. This command puts the drive in a ``drive online'' state with respect to the signaling controller. It also supplies the drive with idle time, which is used by the command timer. When the exchange is complete,
The drive is "drive online" to the signaling controller and "drive unavailable" to all other boats.

Execution, memory read, realign and memory write commands are not important as far as the invention is concerned.

Therefore, for clarity and brevity, these commands will not be described further.

The topology command has a 1-byte format as shown in FIG. 45, the controller processing routine is shown in FIG. 46, and the drive processing routine is shown in FIG. 47. This command tells the drive that it should be able to interact with a controller on an available replacement boat.

Topology commands have one application. The purpose of this command is to have the host determine all possible paths to each drive in the system. Each host can be connected to multiple controllers. Conversely, each controller can access multiple hosts. Each drive can then be accessed by multiple controllers.

When the topology command is accepted and verified as correct, the drive ceases transmitting drive status information through the boats that are on-line and directs operation to the first available replacement boat. Leaving the actual state for all accessible controllers unchanged through this operation, the drive sends the same enable and attention signals that would be transmitted if the drive was in the "drive ready" state for the controller. Transmit it to the replacement controller and prepare to execute the command. While Attentive to a Replacement Boat, the drive operates as if it were in the "drive ready" state, except that the "OA" bit in the status summary is declared and the bit in the disconnect command is correct. Receives and executes status acquisition, common characteristic acquisition, subunit characteristic acquisition, control flag exchange, and disconnection commands.

INTT signaling and protocol errors are all handled as if the drive were in a "drive ready" state. The drive ceases to be attentive to the replacement boat when (1) a predetermined time period expires or (2) - a set of cutting operations is successfully guided to the replacement boat. (
This exchange is a signal from the replaced controller that commands are no longer coming. ) When one of the above conditions occurs, the drive clears rREJ and rPEJ in the status summary and repeats the cycle on the next available replacement boat until all replacement boats are covered. The state and data lines on the replacement boat are then returned to the "drive unavailable" state. The state bits are set as appropriate for transmission to the online controller and state transmission is resumed to the online controller. Finally, OA, RE
, the PE is resolved in the status summary and a topology response 750 (shown in Figure 48) is sent to the online controller if successful.

The topology response consists of an identifier byte 752 and a plurality of status summary bytes 754a-754n.

If the switch changes or another attention condition occurs, the appropriate status bits will change while the drive is attentive to the replacement port, but
No attention signal is raised. The online controller analyzes the conditions for completing the topology exchange. When a topology command is accepted, the controller must check the status summary to ensure that the drive is not interfering with another controller and causing an attention condition while in use.

When the replacement is complete, the drive state is not swapped for all controllers. The position of the head is not determined.

As mentioned above, there are two generic drive responses: completion and failure.

Completion response 756 is one byte long and has the format shown in FIG. This response informs the controller that the command that initiated the current exchange has completed successfully without the need for unconventional error recovery. This response ends the exchange and frees the controller to issue another command.

Failure response 758 is 15 bytes long and has the format shown in FIG. Byte 760 confirms the response. Byte 762 (11-762α0 is the same format and content as the information returned in bytes 682-708 of the response to the status acquisition command (see Figure 44). This response is the command that initiated the command exchange to the controller. will notify you that it was not executed successfully.

Information describing the general nature of the error condition is included in the status summary position of the response.

An unsuccessful response 758 terminates the exchange and the controller is free to issue another command. It is understood that because at least one error bit is set, certain commands and data transfer operations are illegal until the error is cleared.

Having described embodiments of the invention, various alterations, modifications, and improvements will become readily apparent to those skilled in the art. Such obvious changes, modifications, and improvements, although not expressly set forth above, are suggested and are within the spirit and scope of the invention. Accordingly, the foregoing description has been directed only to what is shown in the drawings and not as a limitation.

The invention is limitedly defined by the following claims and their equivalents.

[Brief explanation of drawings]

FIG. 1 is a diagram of a controller drive communication channel in a bus according to the present invention. FIG. 2 is a table summarizing the general characteristics of the information on bus IO of FIG. 1 as a function of the drive status associated with the controller. FIG. 3 illustrates the format of the RTC3 signal on line 18 of FIG. FIG. 4 illustrates the format of the RTDS signal on line 12 of FIG. FIG. 5 is a state diagram illustrating drive states and state changes associated with the controller. FIG. 6 illustrates the operation of the drive command timer. FIG. 7 illustrates a format for level 0 (ie, the lowest protocol level) control transmission according to the present invention. Figures 8A-8I illustrate the format of frames for each possible level (ie, intermediate protocol level) transmitted on bus 10. FIG. 9 is a flowchart of the operation of the controller for level 1 transmission. Figures 10A to 100 are flowcharts of the level 1 reception process of the drive. FIG. 11 is a flowchart of level 1 transmission processing of the drive. FIG. 12 is a flowchart of level 1 reception processing of the controller. FIG. 13 illustrates the format of a Level 2 (ie, highest protocol level) message. FIG. 14 is a flowchart illustrating a method for achieving level 2 command processing in a controller. FIG. 15 is a flowchart for the drive and controller level 2 message transmission process. FIG. 16 is a flowchart showing the drive's level 2 message reception (i processing). FIG. 17 is a flowchart showing the controller's level 2 message reception processing. FIG. 18 is the controller's processing of the so-called mode conversion command. FIG. 19 is a flowchart illustrating the drive processing of the mode conversion command. FIG. 20 is a flowchart illustrating the format of the mode conversion command. FIG. 21 is a flowchart illustrating the controller flag conversion command. 22 is a flowchart illustrating the drive processing of the controller flag conversion command. FIG. 23 illustrates the format of the controller flag conversion command. FIG. 24 is a so-called disconnection command by the controller. FIG. 25 is a flowchart of the processing of a disconnect command by the drive. FIG. 26 illustrates the format of the disconnect command. FIG. 27 is the controller's processing of the so-called error recovery command described below. FIG. 28 is a flowchart of the drive's processing of the error recovery command. FIG. 29 illustrates the format of the error recovery command. FIG. 30 illustrates the format of the so-called common characteristic acquisition command. Figure 31 is a flowchart of the controller's processing of the common characteristic acquisition command. Figure 32 is a flowchart of the drive's processing of the common characteristic acquisition command. Figure 33 illustrates the format of the common characteristic acquisition response. Figure 34 illustrates the format of the so-called subunit characteristic acquisition command. Figure 35 is a flowchart of the controller's processing of the subunit characteristic acquisition command. Figure 36 is a flowchart of the driver's processing of the subunit characteristic acquisition command. Figures 37A and 37B illustrate the format of a subunit characteristic acquisition response. Figure 38 illustrates the format of a so-called status acquisition command. Figure 39 is a flowchart of the controller's processing of the status acquisition command. Figure 40 is a flowchart of the driver's processing of the status acquisition command. Figure 41 illustrates the format of a response to the status acquisition command. Figure 42 illustrates the format of a so-called online command. FIG. 43 is a flowchart of online command processing by the controller. FIG. 44 is a flowchart of online command driver processing. FIG. 45 illustrates the format of a so-called topology command. FIG. 46 is a flowchart of the controller's processing of topology commands. FIG. 47 is a flowchart of drive processing of topology commands. FIG. 48 illustrates the format of a response to a topology command. FIG. 49 illustrates the format of a generic completion response. FIG. 50 illustrates the format of a generic failure response. 10...Bus, 12.14.16.18...Line, 20...
...Controller, 30...Drive. P7g, 6 x 7g
-: Ft'g, 12 M2S LSBMSB
LS8Fig, 20 Fig, /4 Fig, 2/ MSB LS8MS8
LS8MSB
LS8Fig, 2B F, 24 Fig, 27・MS8 LSBMS8
LSBFig, 34 Fig, 31 MSB LS8Fig,
35 Fig, , f7A MSB LSBRg, 3
78 MS8 LSBMS8
LSBbν, 4f Fig, 40 M2S LSBMS8
LS8Ft'1.45 Fig, "43 Rg, 46 M2RLS8 MS8 LSBMSB
LS8~. 50

Claims (1)

Claims: In a disk drive for secondary storage of a data processing system that includes a controller in communication with the drive to effectuate operations of the drive and a host computer in communication with the controller. a storage medium for a drive, and further configured to provide at least one response packet in a predetermined format containing information to the controller in response to a predetermined command from the controller; the bit transfer rate of the drive, the number of error recovery levels supported by the drive, an indication of the protocol version used by the drive, the rotational speed of the drive, and the data transfer operation that the controller should attempt before giving up on the data transfer operation involving the drive. number of format and revector control table copies maintained on the drive, the drive's error threshold for initiating revectoring, the microcode version supported by the drive, the drive's hardware version, and the selected timeout. at least one of the interval durations
A set of parameters that define several physical characteristics of the drive, including the number of replacement blocks per track, the size of the data and header preamble in each sector, the media size, media type, and the size of one copy of the format control table. , a byte and/or sector format identifier, the group offset used for spiral reads, the size of one copy of the revector control table, and the set of sectors that occupy contiguous logical disk locations through the drive's read/write heads. A group is a set of tracks that can be selected for reading or writing in the time it takes for a sector to rotate, and a cylinder is a set of groups that can be selected by an operation that has a latency shorter than the time for a set location search operation. an address space containing an LBN space directly accessible to the host computer for storing given information consisting of sectors arranged in a hierarchical configuration for logical addressing by the host computer in a hierarchy consisting of size and number of starting blocks,
External format area or XBN space, area reserved for use in place of bad sectors or RBN space, area reserved for use in diagnostics or DBN
a logical value of the drive, including a number representing at least one of the following: space, number of replacement blocks N per track, number of groups per cylinder, number of tracks per group, and number of host-accessible sectors per track; A disk drive comprising a set of parameters defining an addressing configuration.