Interface between a pair of processors, such as host and peripheral-controlling processors in data processing systems

An interface mechanism (10) between two processors, such as a host processor (70) and a processor (31) in an intelligent controller (30) for mass storage devices (40), and utilizing a set of data structures employing a dedicated communications region (80A) in host memory (80). Interprocessor commands and responses are communicated as packets over an I/O bus (60) of the host (70), to and from the communication region (80A), through a pair of ring-type queues (80D) and (80E). The entry of each ring location (e.g., 132, 134, 136, 138) points to another location in the communications region where a command or response is placed. The filling and emptying of ring entries (132-138) is controlled through the use of an `ownership` byte or bit (278) associated with each entry. The ownership bit (278) is placed in a first state when the message source (70 or 31) has filled the entry and in a second state when the entry has been emptied. Each processor keeps track of the rings' status, to prevent the sending of more messages than the rings can hold. These rings permit each processor to operate at its own speed, without creating race conditions and obviate the need for hardware interlock capability on the I/O bus (60).

CROSS-REFERENCE TO RELATED APPLICATIONS 
This application relates to a data processing system, other aspects of 
which are described in the following commonly assigned applications filed 
on even date herewith, the disclosures of which are incorporated by 
reference herein to clarify the environment, intended use and explanation 
of the present invention: 
Ser. No. 308,771, titled Disk Format for Secondary Storage System and Ser. 
No. 308,593, titled Secondary Storage Facility Employing Serial 
Communication Between Drive and Controller. 
FIELD OF THE INVENTION 
This invention relates to the field of data processing systems and, in 
particular to an interface between a host processor and a controlling 
processor for a storage facility or other peripheral device or subsystem 
in such systems. 
BACKGROUND OF THE INVENTION 
In data processing systems utilizing secondary storage facilities, 
communication between the host processor, or main frame, and secondary 
storage facilities has a considerable impact on system performance. 
Secondary storage facilities comprise elements which are not an integral 
part of a central processing unit and its random access memory element 
(i.e., together termed the host), but which are directly connected to and 
controlled by the central processing unit or other elements in the system. 
These facilities are also known as "mass storage" elements or subsystems 
and include, among other possibilities, disk-type or tape-type memory 
units (also called drives). 
In modern data processing systems, a secondary storage facility includes a 
controller and one or more drives connected thereto. The controller 
operates in response to signals from the host, usually on an input/output 
bus which connects together various elements in the system including the 
central processing unit. A drive contains the recording medium (e.g., a 
rotating magnetic disk), the mechanism for moving the medium, and 
electronic circuitry to read data from or store data on the medium and 
also to convert the data transferred between the medium and the controller 
to and from the proper format. 
The controller appears to the rest of the system as simply an element on 
the input/output bus. It receives commands over the bus; these commands 
include information about the operation to be performed, the drive to be 
used, the size of the transfer and perhaps the starting address on the 
drive for the transfer and the starting address on some other system 
element, such as the random access memory unit of the host. The controller 
converts all this command information into the necessary signals to effect 
the transfer between the appropriate drive and other system elements. 
During the transfer itself, the controller routes the data to or from the 
appropriate drive and to or from the input/output bus or a memory bus. 
Controllers have been constructed with varying levels of intelligence. 
Basically, the more intelligent the controller, the less detailed the 
commands which the central processing unit must issue to it and the less 
dependent the controller is on the host CPU for step-by-step instructions. 
Typically, controllers communicate with a host CPU at least partially by 
means of an interrupt mechanism. That is, when one of a predetermined 
number of significant events occurs, the controller generates an interrupt 
request signal which the host sees a short time later; in response, the 
host stops what it is doing and conducts some dialogue with the controller 
to service the controller's operation. Every interrupt request signal 
generated by the controller gives rise to a delay in the operation of the 
central processor. It is an object of the present invention to reduce that 
delay by reducing the frequency and number of interrupt requests. 
When an intelligent controller is employed, a further problem is to 
interlock or synchronize the operation of the processor in the controller 
with the operation of the processor in the host, so that in sending 
commands and responses back and forth, the proper sequence of operation is 
maintained, race conditions are avoided, etc. Normally this is 
accomplished by using a communications mechanism (i.e., bus) which is 
provided with a hardware interlock capability, so that each processor can 
prevent the other from transmitting out of turn or at the wrong time. 
Modern controllers for secondary storage facilities are usually so-called 
"intelligent" devices, containing one or more processors of their own, 
allowing them to perform sophisticated tasks with some degree of 
independence. Sometimes, a processor and a controller will share a 
resource with another processor, such as the host's central processor 
unit. One resource which may be shared is a memory unit. 
It is well known that when two independent processors share a common 
resource (such as a memory through which the processors and the processes 
they execute may communicate with each other), the operation of the two 
processors (i.e., the execution of processes or tasks by them) must be 
"interlocked" or "synchronized," so that in accessing the shared resource, 
a defined sequence of operations is maintained and so-called "race" 
conditions are avoided. That is, once a first processor starts using the 
shared resource, no other processor may be allowed to access that resource 
until the first processor has finished operating upon it. Operations which 
otherwise might have occurred concurrently must be constrained to take 
place seriatim, in sequence. Otherwise, information may be lost, a 
processor may act upon erroneous information, and system operation will be 
unreliable. To prevent this from happening, the communications mechanism 
(i.e., bus) which links together the processors and a shared resource 
typically is provided with a hardware "interlock" or synchronization 
capability, by means of which each processor is prevented from operating 
on the shared resource in other than a predefined sequence. 
In the prior art, three interlock mechanisms are widely known for 
synchronizing processors within an operating system, to avoid race 
conditions. One author calls these mechanisms (1) the test-and-set 
instruction mechanism, (2) the wait and signal mechanism and (3) the P and 
V operations mechanism. S. Madnick and J. Donovan, Operating Systems, 
4-5.2 at 251-55 (McGraw Hill, Inc., 1974). That text is hereby 
incorporated by reference for a description and discussion of those 
mechanisms. Another author refers to three techniques for insuring correct 
synchronization when multiple processors communicate through a shared 
memory as (1) process synchronization by semaphores, (2) process 
synchronization by monitors and (3) process synchronization by monitors 
without mutual exclusion. C. Weitzman, Distributed Micro/Mini Computer 
Systems: Structure, Implementation and Application, 3.2 at 103-14 
(Prentice Hall, Inc., 1980). That text is hereby incorporated by reference 
for a description and discussion of those techniques. When applied to 
multiple processors which communicate with a shared resource by a bus, 
such mechanisms impose limitations on bus characteristics; they require, 
for example, that certain compound bus operations be indivisible, such as 
an operation which can both test and set a so-called "semaphore" or 
monitor without being interrupted while doing so. These become part of the 
bus description and specifications. 
If the testing of a semaphore were done during one bus cycle and the 
setting during a different bus cycle, two or more processors which want to 
use a shared resource might test its semaphore at nearly the same time. If 
the semaphore is not set, the processors all will see the shared resource 
as available. They will then try to access it; but only one can succeed in 
setting the semaphore and getting access; each of the other processors, 
though, having already tested and found the resource available, would go 
through the motions of setting the semaphore and reading or writing data 
without knowing it had not succeeded in setting the semaphore and 
accessing the resource. The data thus read will be erroneous and the data 
thus written could be lost. 
Not all buses, though, are designed to allow implementation of such 
indivisible operations, since some buses were not designed with the idea 
of connecting multiple processors via shared resources. Consequently, such 
buses are not or have not been provided with hardware interlock 
mechanisms. 
When a bus does not have such a capability, resort frequently has been made 
to use of processor interrupts to control the secondary storage facility, 
or some combination of semaphores and interrupts (as in the 
Carnegie-Mellon University C.mpp multi-minicomputer system described at 
pages 27-29 and 110-111 of the above-identified book by Weitzman), but 
those approaches have their drawbacks. If multiple processors on such a 
bus operate at different rates and have different operations to perform, 
at least one processor frequently may have to wait for the other. This 
aggrevates the slowdown in processing already inherent in the use of 
interrupt control with a single processor. 
A further characteristic of prior secondary storage facilities is that when 
a host initially connects to a controller, it usually assumes, but cannot 
verify, that the controller is operating correctly. 
Therefore, it is an object of this invention to improve the operation of a 
secondary storage facility including a controller and a drive. 
A further object of this invention is to provide such a facility with an 
improved method for handling host-controller communications over a bus 
lacking a hardware interlock capability, whereby the processor in the host 
and controller can operate at different rates with minimal interrupts and 
avoidance of race conditions. 
Another object of this invention is to provide a communications mechanism 
for operation between controller and host which permits the host to verify 
correct operation of the controller at the time of initialization. 
Still another object of the invention is to provide a communications 
mechanism which minimizes the generation of host interrupts by the 
controller during peak input/output loads. 
Still another object of this invention is to provide an interface between 
host and controller which allows for parallel operation of multiple 
devices attached to an individual controller, with full duplexing of 
operation initiation and completion signals. 
SUMMARY OF THE INVENTION 
In accordance with this invention, the host-controller interconnection is 
accomplished through an interface which includes a set of data structures 
employing a dedicated communications region in host memory. This 
communications region is operated on by both the host and the peripheral 
controller in accordance with a set of rules discussed below. Basically, 
this interface has two layers: (1) a transport mechanism, which is the 
physical machinery for the bi-directional transmission of words and 
control signals between the host and the controller and (2) a port, which 
is both hardware for accomplishing exchanges via the transport mechanism 
and a process implementing a set of rules and procedures governing those 
exchanges. This port "resides" partly in the host and partly in the 
controller and has the purposes of facilitating the exchange of control 
messages (i.e., commands and responses) and verifying the correct 
operation of the transport mechanism. 
Commands and responses are transmitted between the host and a peripheral 
controller as packets, over an input/output bus of the host, via transfers 
which do not require processor interruption. These transfers occur to and 
from the dedicated communication region in the host memory. The port polls 
this region for commands and the host polls it for responses. A portion of 
this communication region comprises a command (i.e., transmission) list 
and another portion comprises a response (i.e., receiving) list. An 
input/output operation begins when the host deposits a command in the 
command list. The operation is seen as complete when the corresponding 
response packet is removed by the host from the response list. 
More specifically, the communications region of host memory consists of two 
sections: (1) a header section and (2) a variable-length section. The 
header section contains interrupt identification words. The 
variable-length section contains the response and command lists, organized 
into "rings". A "ring" is a group of memory locations which is addressable 
in rotational (i.e., modulo) sequence, such that when an incrementing 
counter (modulo-buffer-size) is used for addressing the buffer, the 
address of the last location is the sequence is followed next by the 
address of the first location. Each buffer entry, termed a descriptor, 
includes (1) an address where a command may be found for transmission or 
where a response is written, as appropriate, and (2) a so-called 
"ownership" byte (which in its most elementary form reduces to a sigle 
ownership bit) which is used by the processors to controll access to the 
entry. 
Because of properties which will be outlined below, the port may be 
considered to be effectively integral with the controller; all necessary 
connections between the host and peripheral can be established by the 
port/controller when it is initialized. 
The port can itself generate processor interrupts; this happens at the 
option of the host only when the command ring makes a transition from a 
full to a not-full condition or when the response ring makes the converse 
transition from empty to non-empty. Thus, the rings buffer the 
asynchronous occurrence of command and response packets, so that under 
favorable conditions long strings of commands, responses and exchanges can 
be passed without having to interrupt the host processor. 
An input/output operation begins when the host deposits a command into the 
command list. The operation is seen as complete when the corresponding 
response is removed by the host from the response list. Only the host 
writes into the command ring (i.e., list) and only the controller writes 
into the response ring. The "ownership" bit for each ring entry is set to 
a first state by the processor which writes the ring entry and is cleared 
from that state by the other processor only after the command has been 
sent or the response read. In addition, after writing an entry, the same 
processor cannot alter it until the other processor has cleared that 
entry's ownership bit. 
By organizing the command and response lists into rings and controlling 
their operation through a rigid sequential protocol which includes an 
ownership byte (or bit) for each ring entry and rules for setting and 
clearing the ownership byte, the host and controller processors are 
allowed to operate at their own rates and the need for a hardware bus 
interlock in avoided. This allows the system to utilize, for example, the 
UNIBUS communication interconnection of Digital Equipment Corp., Maynard, 
Mass., which is an exemplary bus lacking a hardware interlock feature. 
These and other features, advantages and objects of the present invention 
will become more readily apparent from the following detailed description, 
which should be read in conjunction with the accompanying drawings.

DETAILED DESCRIPTION OF AN ILLUSTRATIVE EMBODIMENT 
The present invention sees particular utility in a data processing system 
having an architectural configuration designed to enhance development of 
future mass storage systems, at reduced cost. Such a system is shown in 
FIG. 1. In this system, a high level protocol (indicated at 1A) is 
employed for communications between a host computer 1 and intelligent mass 
storage controller to. Such a high level protocol is intended to free the 
host from having to deal with peripheral device-dependent requirements 
(such as disk geometry and error recovery strategies). This is 
accomplished in part through the use of a communications hierachy in which 
the host communicates with only one or two peripheral device "class" 
drivers, such as a driver 4 instead of a different I/O driver for each 
model of peripheral device. For example, there may be one driver for all 
disk class devices and another for all tape class devices. 
Each class driver, in turn, communicates with a device controller (e.g., 2) 
through an interface mechanism 10. Much of the interface mechanism 10 is 
bus-specific. Therfore, when it is desired to connect a new mass storage 
device to the system, there is no need to change the host's input/output 
processes or operating system, which are costly (in time, as well as 
money) to develop. Only the controller need be modified to any substantial 
degree, which is far less expensive. And much of that cost can be averted 
if the controller and host are made self-adaptive to certain of the 
storage device's characteristics, as explained in the above-identified 
commonly assigned applications. 
Device classes are determined by their storage and transfer 
characteristics. For example a so-called "disk class" is characterized by 
a fixed block length, individual block update capability, and random 
access. Similarly a so-called "tape class" is characterized by a variable 
block length, lack of block update capability, and sequential access. 
Thus, the terms "disk" and "tape" as used herein refer to devices with 
such characteristics, rather than to the physical form of the storage 
medium. 
Within the framework of this discussion, a system comprises a plurality of 
subsystems interconnected by a communications mechanism (i.e. a bus and 
associated hardware). Each subsystem contains a port driver, (4 or 5) 
which interfaces the subsystem to the communications mechanism. The 
communications mechanism contains a port (8 or 9) for each subsystem; the 
port is simply that portion of the communications mechanism to which a 
port driver interfaces directly. 
FIG. 1 illustrates an exemplary system comprising a host 1 and an 
intelligent mass storage controller 2. Host 1 includes a peripheral class 
driver 3 and a port driver 4. Controller 2, in turn, includes a 
counterpart port driver 5 and an associated high-level protocol server 2. 
A communications mechanism 7 connects the host to the controller, and 
vice-versa. The communications mechanism includes a port (i.e., interface 
mechanism) (8,9) for each port driver. 
The port drivers 4 and 5 provide a standard set of communications services 
to the processes within their subsystems; port drivers cooperate with each 
other and with the communications mechanism to provide these services. In 
addition, the port drivers shield the physical characteristics of the 
communications mechanism from processes that use the communications 
services. 
Class driver 3 is a process which executes within host 1. Typically, a host 
class I/O driver 3 communicates with a counterpart in the controller 2, 
called a high-level protocol server, 6. 
The high-level protocol server 6 processes host commands, passes commands 
to device-specific modules within the controller, and sends responses to 
host commands back to the issuing class driver. 
In actual implementation, it is also possible for the functions of the 
controller-side port driver 5 and port 9 to be performed physically at the 
host side of the communications mechanism 7. This is shown in the example 
described below. Nevertheless, the diagram of FIG. 1 still explains the 
architectural concepts involved. 
Note also that for purposes of the further explanation which follows, it is 
generally unnecessary to distinguish between the port and its port driver. 
Therefore, unless the context indicates otherwise, when the word "port" is 
used below, it presumes and refers to the inclusion of a port driver, 
also. 
Referring now to FIG. 2, there is shown a system level block diagram of a 
data processing system utilizing the present invention. A host computer 1 
(including an interface mechanism 10) employs a secondary storage 
subsystem 20 comprising a controller 30, a disk drive 40 and a 
controller-drive interconnection cable 50. The host 1 communicates with 
the secondary storage subsystem 20 over an input/output bus 60. 
FIG. 3A expands the system definition to further explain the structure of 
the host 1, controller 30 and their interface. As illustrated there, the 
host 1 comprises four primary subunits: a central processor unit (CPU) 70, 
a main memory 80, a system bus 90 and a bus adapter 110. 
A portion 80A of memory 80 is dedicated to service as a communications 
region for accessing the remainder of memory 80. As shown in FIG. 3A, 
communications area 80A comprises four sub-regions, or areas. Areas 80B 
and 80C together form the above-indicated header section of the 
communications area. Area 80B is used for implementing the bus adapter 
purge function and area 80C holds the ring transition interrupt indicators 
used by the port. The variable-length section of the communications region 
comprises the response list area 80D and the command list area 80E. The 
lists in areas 80D and 80E are organized into rings. Each entry, in each 
ring, in turn, contains a descriptor (see FIG. 10) pointing to a memory 
area of sufficient size to accommodate a command or response message 
packet of predetermined maximum length, in bytes. 
Host 1 may, for example, be a Model VAX-11/780 or PDP 11 computer system, 
marketed by Digital Equipment Corporation of Maynard, Mass. 
System bus 90 is a bi-directional information path and communications 
protocol for data exchange between the CPU 70, memory 80 and other host 
elements which are not shown (so as not to detract from the clarity of 
this explanation). The system bus provides checked parallel information 
exchanges synchronous with a common system clock. A bus adapter 110 
translates and transfers signals between the system bus 90 and the host's 
input/output (I/O) bus 60. For example, the I/O bus 60 may be the UNIBUS 
I/O connection, the system bus may be the syncronous backlane 
interconnection (SBI) of the VAX-11/780 computer, and the bus adapter 110 
may be the Model DW780 UNIBUS Adapter, all Digital Equipment Corporation 
products. 
Controller 30 includes several elements which are used specifically for 
communicating with the host 1. There are pointers 32 and 34, a command 
buffer 36 and a pair of registers, 37 and 38. Pointers 32 and 34 keep 
track of the current host command ring entry and the host response ring 
entry, respectively. Command buffers 36 provide temporary storage for 
commands awaiting processing by the controller and a pair of registers 37 
and 38. Register 37, termed the "IP" register, is used for initialization 
and polling. Register 38, termed the "SA" register, is used for storing 
status and address information. 
A processor 31 is the "heart" of the controller 30; it executes commands 
from buffer 36 and does all the housekeeping to keep communications 
flowing between the host 1 and the drive 40. 
The physical realization of the transport mechanism includes the UNIBUS 
interconnection (or a suitable counterpart) 60, system bus 90 and any 
association host and/or controller-based logic for adapting to same, 
including memory-bus interface 82, bus adapter 110, and bus-controller 
interface 120. 
The operation of the rings may be better understood by referring to FIGS. 
3B and 3C, where an exemplary four entry ring 130 is depicted. This ring 
may be either a command ring or a response ring, since only their 
application differs. Assume the ring 130 has been operating for some time 
and we have started to observe it at an arbitrarily selected moment, 
indicated in FIG. 3B. There are four ring entry positions 132-138, with 
consecutive addresses RB, RB+1, RB+4, respectively. Each ring entry has 
associated with it an ownership bit (133, 135, 137, 139) which is used to 
indicate its status. A write pointer (WP), 142, points to the most recent 
write entry; correspondingly, a read pointer (RP), 144, points to the most 
recent read entry. In, FIG. 3B, it will be seen that entry 138 has been 
read, as indicated by the position of RP 144 and the state of ownership 
bit 139. By convention, the ownership bit is set to 1 when a location has 
been filled (i.e., written) and to 0 when it has been emptied (i.e., 
read). The next entry to be read is 132. Its ownership bit 133 is set to 
1, indicating that it already has been written. Once entry 132 is read, 
its ownership bit is cleared, to 0, as indicated in FIG. 3C. This 
completely empties the ring 130. The next entry 134 cannot be read until 
it is written and the state of ownership bit 135 is changed. Nor can entry 
132 be re-read accidentally, since its ownership bit has been cleared, 
indicating that it already has been read. 
Having thus provided a block diagram explanation of the invention, further 
understanding of this interface will require a brief digression to explain 
packet communications over the system. 
The port is a communications mechanism in which communications take place 
between pairs of processes resident in separate subsystems. (As used 
herein, the term "subsystems" include the host computers and device 
controllers; the corresponding processes are host-resident class drivers 
and controller-resident protocol servers.) 
Communications between the pair of processes take place over a "connection" 
which is a soft communications path through the port; a single port 
typically will implement several connections concurrently. Once a 
connection has been established, the following three services are 
available across that connection: (1) sequential message; (2) datagram; 
and (3) block data transfer. 
When a connection is terminated, all outstanding communications on that 
connection are discarded; that is, the receiver "throws away" all 
unacknowledge messages and the sender "forgets" that such messages have 
been sent. 
The implementation of this communications scheme on the UNIBUS 
interconnection 60 has the following characteristics: (1) communications 
are always point-to-point between exactly two subsystems, one of which is 
always the host; (2) the port need not be aware of mapping or memory 
management, since buffers are identified with a UNIBUS address and are 
contiguous within the virtual buss address space; and (3) the host need 
never directly initiate a block data transfer. 
The port effectively is integral with the controller, even though not full 
localized there. This result happens by virtue of the point-to-point 
property and the fact that the device controller knows the class of device 
(e.g., disk drive) which it controls; all necessary connections, 
therefore, can be established by the port/controller when it is 
initialized. 
The Sequential Message service guarantees that all messages sent over a 
given connection are transmitted sequentially in the order originated, 
duplicate-free, and that they are delivered. That is, messages are 
received by the receiving process in the exact order in which the sending 
process queued them for transmission. If these guarantees cease to be met, 
or if a message cannot be delivered for any reason, the port enters the 
so-called "fatal error" state (described below) and all port connections 
are terminated. 
The Datagram service does not quarantee reception, sequential reception of 
duplicate-free reception of datagrams, though the probability of failure 
may be required to be very low. The port itself can never be the cause of 
such failures; thus, if the using processes do make such guarantees for 
datagrams, then the datagram service over the port becomes equivalent to 
the Sequential Message service. 
The Block Data Transfer service is used to move data between named buffers 
in host memory and a peripheral device controller. In order to allow the 
port to be unaware of mapping or memory management, the "Name" of a buffer 
is merely the bus address of the first byte of the buffer. Since the host 
never directly initiates a block data transfer, there is no need for the 
host to be aware of controller buffering. 
Since the communicating processes are asynchronous, flow control is needed 
if a sending process is to be prevented from producing congestion or 
deadlock in a receiving process (i.e., by sending messages more quickly 
than the receiver can capture them). Flow control simply guarantees that 
the receiving process has buffers in which to place incoming messages; if 
all such buffers are full, the sending process is forced to defer 
transmission until the condition changes. Datagram service does not use 
flow control. Consequently, if the receiving process does not have an 
available buffer, the datagram is either processed immediately or 
discarded, which possibility explicitly is permitted by the rules of that 
service. By contrast, the Sequential Message service does use flow 
control. Each potential receiving process reserves, or pre-allocates, some 
number of buffers into which messages may be received over its connection. 
This number is therefore the maximum number of messages which the sender 
may have outstanding and unprocessed at the receiver, and it is 
communicated to the sender by the receiver in the form of a "credit" for 
the connection. When a sender has used up its available credit, it must 
wait for the receiver to empty and make available one of its buffers. The 
message credits machinery for the port of the present invention is 
described in detail below. 
The host-resident driver and the controller provides transport mechanism 
control facilities for dealing with: (1) transmission of commands and 
responses; (2) sequential delivery of commands; (3) asynchronous 
commication; (4) unsolicited responses; (5) full duplex communication; and 
(6) port failure recovery. That is, commands, their responses and 
unsolicited "responses" (i.e., controller-to-host messages) which are not 
responsive to a command may occur at any time; full duplex communication 
is necessary to handle the bi-directional flow without introducing the 
delays and further buffering needs which would be associated with simplex 
communications. It is axiomatic that the host issues commands in some 
sequence. They must be fetched by the controller in the order in which 
they were queued to the transport mechanism, even if not executed in that 
sequence. Responses, however, do not necessarily occur in the same order 
as the initiating commands; and unsolicited messages can occur at any 
time. Therefore, asynchronous communications are used in order to allow a 
response or controller-to-host message to be sent whenever it is ready. 
Finally, as to port failure recovery, the host's port driver places a 
timer on the port, and reinitializes the port in the event the port times 
out. 
This machinery must allow repeated access to the same host memory location, 
whether for reads, writes, or any mixture of the two. 
The SA and IP registers (37 and 38) are in the I/O page of the host address 
space, but in controller hardware. They are used for controlling a number 
of facets of port operation. These registers are always read as words. The 
register pair begins on a longword boundary. Both have predefined 
addresses. The IP register has two functions: first, when written with any 
value, it causes a "hard" initialization of the port and the device 
controller; second, when read while the port is operating, it causes the 
controller to initiate polling of the command ring, as discussed below. 
The SA register 38 has four functions: first, when read by the host during 
initialization, it communicates data and error information relating to the 
initialization process; second, when written by the host during 
initialization, it communicates certain host-specific parameters to the 
port; third, when read by the host during normal operation, it 
communicates status information including port- and controller-detected 
fatal errors; and fourth, when zeroed by the host during initialization 
and normal operation, it signals the port that the host has successfully 
completed a bus adapter purge in response to a port-initiated purge 
request. 
The port driver in the host's operating system examines the SA register 
regularly to verify normal port/controller operation. A self-detected 
port/controller fatal error is reported in the SA register as discussed 
below. 
Transmission of Commands and Responses-Overview 
When the controller desires to send a response to the host, a several step 
operational sequence takes place. This sequence is illustrated in FIGS. 4A 
and 4B. Initially, the controller looks at the current entry in the 
response ring indicated by the response ring pointer 34 and determines 
whether that entry is available to it (by using the "ownership" bit). 
(Step 202.) If not, the controller continues to monitor the status of the 
current entry until it becomes available. Once the controller has access 
to the current ring entry, it writes the response into a response buffer 
in host memory, pointed to by that ring entry, and indicates that the host 
now "owns" that ring entry by clearing and "Ownership" bit; it also sets a 
"FLAG" bit, the function of which is discussed below. (Step 204.) 
Next, the port determines whether the ring has gone from an empty to a 
non-empty transition (step 206); if so, a potentially interruptable 
condition has occurred. Before an interrupt request is generated, however, 
the port checks to ensure that the "FLAG" bit is a 1 (step 208); an 
interrupt request is signalled only on an affirmative indication (Step 
210). 
Upon receipt of the interrupt request, the host, when it is able to service 
the interrupt, looks at the current entry in the response ring and 
determines whether it is "owned" by the host or controller (i.e., whether 
it has yet been read by that host). (Step 212.) If it is owned by the 
controller, the interrupt request is dismissed as spurious. Otherwise, the 
interrupt request is treated as valid, so the host processes the response 
(Step 214) and then updates its ring pointer (Step 216). 
Similar actions take place when the host wants to send a command, as 
indicated in FIG. 5. To start the sequence, the host looks at the current 
command ring entry and determines whether that ring entry is owned by the 
host or controller. (Step 218.) If it is owned by the controller, the host 
starts a timer (Step 220.) (provided that is the first time it is looking 
at that ring entry), if the timer is not stopped (by the command ring 
entry becoming available to the host) and is allowed to time out, a 
failure is indicated; the port is the reinitialized. (Step 222.) If the 
host owns the ring entry, however, it puts the packet address of the 
command in the current ring entry. (Step 224.) If a command ring transfer 
interrupt is desired (step 226), the FLAG bit is set=1 to so indicate 
(step 228). The host then sets the "ownership" bit=1 the ring entry to 
indicate that there is a command in that ring entry to be acted upon. 
(Step 230.) The port is then told to "poll" the ring (i.e., the host reads 
the IP register, which action is interpreted by the port as a notification 
that the ring contains one or more commands awaiting transmission; in 
response, the port steps through the ring entries one by one until all 
entries awaiting transmission have been sent. (Step 232.) 
The host next determines whether it has additional commands to send. (Step 
233.) If so, the process is repeated; otherwise, it is terminated. 
In responding to the issuance of a command (see FIG. 6), the port first 
detects the instruction to poll (i.e., the read operation to the IP 
register). (Step 234.) Upon detecting that signal, the port must determine 
whether there is a buffer available to receive a command. (Step 236.) It 
waits until the buffer is available and then reads the current ring entry 
to determine whether that ring entry is owned by the port or host. (Step 
238.) If owned by the port, the command packet is read into a buffer. 
(Step 240.) The FLAG bit is then set and the "ownership" bit in the ring 
entry is changed to indicate host ownership. (Step 242.) If not owned by 
the port, polling terminates. 
A test is then performed for interrupt generation. First the port 
determines whether the command ring has undergone a full to not-full 
transition. (Step 244.) If so, the port next determines whether the host 
had the FLAG bit set. (Step 246.) If the FLAG bit was set, an interrupt 
request is generated. (Step 248.) The ring pointer is then incremented. 
(Step 250.) 
Response packets continue to be removed after the one causing an interrupt 
and, likewise, command packets continue to be removed by the port after a 
poll. 
The Communications Area 
The communications area is aligned on a 16-bit word boundary whose layout 
is shown in FIG. 7. Addresses for the words of the rings are identified 
relative to a "ringbase" address 252. The words in regions 80B, 80C whose 
addresses are ringbase-3, ringbase-2 and ringbase-1 (hereinafter 
designated by the shorthand [ringbase-3], etc., where the brackets should 
be read as the location "whose address is") are used as indicators which 
are set to zero by the host and which are set non-zero by the port when 
the port interrupts the host, to indicate the reason for the interrupt. 
Word [ringbase-3] indicates whether the port is requesting a bus adapter 
purge; the non-zero value is the adapter channel number contained in the 
high-order byte 254 and derived from the triggering command. (The host 
responds by performing the purge. Purge completion is signalled by writing 
zeros to the SA register). 
Word 256 [ringbase-2] signals that the command queue has transitioned from 
full to not-full. Its non-zero value is predetermined, such as one. 
Similarly, word 258 [ringbase-19 indicates that the response queue has 
transitioned from empty to not-empty. Its non-zero value also is 
predetermined (e.g., one). 
Each of the command and response lists is organized into a ring whose 
entries are 32-bit descriptors. Therefore, for each list, after the last 
location in the list has been addressed, the next location in sequence to 
be addressed is the first location in the list. That is, each list may be 
addressed by a modulo-N counter, where N is the number of entries in the 
ring. The length of each ring is determined by the relative speeds with 
which the host and the port/controller generate and process messages; it 
is unrelated to the controller command limit. At initialization time, the 
host sets the ring lenghts. 
Each ring entry, or formatted descriptor, has the layout indicated in FIG. 
8. In the low-order 16-bit (260), the least significant bit, 262, is zero; 
that is, the envelope address [text+0] is word-aligned. The remaining 
low-order bits are unspecified and vary with the data. In the high-order 
portion 264 of the descriptor, the letter "U" in bits 266 and 268 
represent a bit in the high-order portion of an 18-bit UNIBUS (or other 
bus) address. Bits 270-276, labelled "Q", are available for extending the 
high-order bus address; they are zero for UNIBUS systems. The most 
significant bit, 278, contains the "ownership" bit ("0") referred to 
above; it indicates whether the descriptor is owned by the host (0=1), and 
acts as an interlock protecting the descriptor against premature access by 
either the host or the port. The next lower bit, 280, is a "FLAG" bit 
(labelled "F") whose meaning varies depending on the state of the 
descriptor. When the port returns a descriptor to the host, it sets F=1, 
indicating that the descriptor is full and points to response. On the 
other hand, when the controller acquires a descriptor from the host, F=1 
indicates that the host wants a ring transition interrupt due to this 
slot. It assumes that transition interrupts were enabled during 
initialization and that this particular slot triggers the ring transition. 
F=0 means that the host does not want a transition host interrupt, even if 
interrupts were enabled during initialization. The port always sets F=1 
when returning a descriptor to the host; therefore, a host desiring to 
override ring transition interrupts must always clear the FLAG bit when 
passing ownership of a descriptor to the port. 
Message Envelopes 
As stated above, messages are sent as packets, with an envelope address 
pointing to word [text+0] of a 16-bit, word-aligned message envelope 
formatted as shown in FIG. 9. 
The MSG LENGTH field 282 indicates the length of the message text, in 
bytes. For commands, the length equals the size of the command, starting 
with [text+0]. For responses, the host sets the length equal to the size 
of the response buffer, in bytes, starting with [text+0]. By design, the 
minimum acceptable size is 60 bytes of message text (i.e., 64 bytes 
overall). 
The message length field 282 is read by the port before the actual 
transmission of a response. The port may wish to send a response longer 
than the host can accept, as indicated by the message length field. In 
that event, it will have to break up the message into a plurality of 
packets of acceptable size. Therefore, having read the message length 
field, the controller then sends a response whose length is either the 
host-specified message length or the length of the controller's response, 
if smaller. The resulting value is set into the message length field and 
sent to the host with the message packet. Therefore, the host must 
re-initialize the value of that field for each proposed response. 
The message text is contained in bytes 284a-284m, labelled MBj. The 
"connection id" field 286 identifies the connection serving as source of, 
or destination for, the message in question. The "credits" field 288 gives 
the credit value associated with the message, which is discussed more 
fully below. The "msgtyp" field 290 indicates the message type. For 
example, a zero may be used to indicate a sequential message, wherein the 
credits and message length fields are valid. A one may indicate a 
datagram, wherein the credits field must be zero, but message length is 
valid. Similarly, a two may indicate a credit notification, with the 
credits field valid and the message length field zero. 
Message Credits 
A credit-based message limit mechanism is employed for command and response 
flow control. The credits field 288 of the message envelope supports 
credit-accounting algorithm. The controller 30 has a buffer 36 for holding 
up to M commands awaiting execution. In its first response, the controller 
will return in the credits field the number, M, of commands its buffer can 
hold. This number is one more than the controller's acceptance limit for 
non-immediate commands; the "extra" slot is provided to allow the host 
always to be able to issue an immediate-class command. If the credit 
account has a value of one, then the class driver may issue only an 
immediate-type command. If the account balance is zero, the class driver 
may not issue any commands at all. 
The class driver remembers the number M in its "credit account". Each time 
the class driver queues a command, it decrements the credit account 
balance by one. Conversely, each time the class driver receives a 
response, it increments the credit account balance by the value contained 
in the credits field of that response. For unsolicited responses, this 
value will be zero, since no command was executed to evoke the response; 
for solicited responses, it normally will be one, since one command 
generally gives one to one response. 
For a controller having M greater than 15, responses beyond the first will 
have credits greater than one, allowing the controller to "walk" the class 
driver's credit balance up to the correct value. For a well-behaved class 
driver, enlarging the command ring beyond the value M+1 provides no 
performance benefits; in this situation command ring transition interrupts 
will not occur since the class driver will never fill the command ring. 
The Ownership Bit 
The ownership bit 278 in each ring entry is like the flag on an 
old-fashioned mailbox. The postman raised the flag to indicate that a 
letter had been put in the box. When the box was emptied, the owner would 
lower the flag. Similarly, the ownership bit indicates that a message has 
been deposited in a ring entry, and whether or not the ring entry (i.e., 
mailbox) has been emptied. Once a message is written to a ring entry, that 
message must be emptied before a second message can be written over the 
first. 
For a command descriptor, the ownership bit "0" is changed from zero to one 
when the host has filled the descriptor and is releasing it to the port. 
Conversely, once the port has emptied the command descriptor and is 
returning the empty slot to the host, the ownership bit is changed from 
one to zero. That is, to send a command the host sets the ownership bit to 
one; the port clears it when the command has been received, and returns 
the empty slot to the host. 
To guarantee that the port/controller sees each command in a timely 
fashion, whenever the host inserts a command in the command ring, it must 
read the IP register. This forces the port to poll if it was not already 
polling. 
For a response descriptor, when the ownership bit 0 undergoes a transition 
from one to zero, that means that the port has filled the descriptor and 
is releasing it to the host. The reverse transition means that the host 
has emptied the response descriptor and is returning the empty slot to the 
port. Thus, to send a response the port clears the ownership bit, while 
and the host sets it when the response has been received, and returns the 
empty slot to the port. 
Just as the port must poll for commands, the host must poll for responses, 
particularly because of the possibility of unsolicited responses. 
Interrupts 
The transmission of a message will result in a host interrupt if and only 
if interrupts were armed (i.e., enabled) suitably during initialization 
and one of the following three conditions has been met: (1) the message 
was a command with flag 280 equal to one (i.e., F=1), and the fetching of 
the command by the port caused the command ring to undergo a transition 
from full to not-full; (2) if the message was a response with F=1 and the 
depositing of the message by the port caused the response ring to make a 
transition from empty to not-empty; or (3) the port is interfaced to the 
host via a bus adapter and a command required the port/controller to 
re-access a given location during data transfer. (The latter interrupt 
means that the port/controller is requesting the host to purge the 
indicated channel of the bus adapter.) 
Port Polling 
The reading of the IP register by the host causes the port/controller to 
poll for commands. The port/controller begins reading commands out of host 
memory; if the controller has an internal command buffering capability, it 
will write commands into the buffer if they can't be executed immediately. 
The port continues to poll for full command slots until the command ring 
is found to be empty, at which time it will cease polling. The port will 
resume polling either when the controller delivers a response to the host, 
or when the host reads the IP register. 
Correspondingly, response polling for empty slots continues until all 
commands buffered within the controller have been completed and the 
associated responses have been sent to the host. 
Host Polling 
Since unsolicited responses are possible, the host cannot cease polling for 
responses when all outstanding commands have been acknowledged, though. If 
it did, an accumulation of unsolicited messages would first saturate the 
response ring and then any controller internal message buffers, blocking 
the controller and preventing it from processing additional commands. 
Thus, the host must at least occassionally scan the response ring, even 
when not expecting a response. One way to accomplish this is by using the 
ring transition interrupt facility described above; the host also should 
remove in sequence from the response ring as many responses as it finds 
there. 
Data Transmission 
Data transmission details are controller-dependent. There are certain 
generic characteristics, however. 
Data transfer commands are assumed to contain buffer descriptors and byte 
or word counts. The buffers serve as sources or sinks for the actual data 
transfers, which are effected by the port as non-processor (NPR or DMA) 
transfers under command-derived count control to or from the specified 
buffers. A buffer descriptor begins at the first word allocated for this 
purpose in the formats of higher-level commands. When used with the UNIBUS 
interconnection, the port employs a two-word buffer descriptor format as 
illustrated in FIG. 10. As shown wherein, the bits in the low-order buffer 
address 292 are message-dependent. The bits labelled "U" (294, 296) in the 
high-order portion 298 of the buffer descriptor are the high-order bits of 
an 18-bit UNIBUS address. The bits 300-306, labelled "Q", are usable as an 
extension to the high-order UNIBUS address, and are zero for UNIBUS 
systems. 
Repeated access to host memory locations must be allowed for both read and 
write operations, in random sequence, if the interfaces are to support 
higher-level protocol functions such as transfer restarts, compares, and 
so forth. In systems with buffered bus adapters, which require a rigid 
sequencing this necessitates purging of the relevant adapter channel prior 
to changing from read to write, or vice versa, and prior to breaking an 
addressing sequence. Active cooperation of the host CPU is required for 
this action. The port signals its desire for an adapter channel purge, as 
indicated above under the heading "The Communications Area". The host 
performs the purge and writes zeroes to the SA register 38 to signal 
completion. 
Transmission Errors 
Four classes of transmission errors have been considered in the design of 
this interface: (1) failure to become bus master; (2) failure to become 
interrupt master; (3) bus data timeout error; and (4) bus parity error. 
When the port (controller) attempts to access host memory, it must first 
become the "master" of bus 60. To deal cleanly with the possibility of 
this exercise failing, the port sets up a corresponding "last fail" 
response packet (see below) before actually requesting bus access. Bus 
access is then requested and if the port timer expires, the host will 
reinitialize the port/controller. The port will then report the error via 
the "last fail" response packet (assuming such packets were eneable during 
the reinitialization). 
A failure to become interrupt master occurs whenever the port attempts to 
interrupt the host and an acknowledgement is not forthcoming. It is 
treated and reported the same as a failure to become bus master, although 
the contents of its last fail response will, of course, be different. 
Bus data timeout errors involve failure to complete the transfer of control 
or data messages. If the controller retires a transfer after it has failed 
once, and a second try also fails, then action is taken responsive to the 
detection of a persistent error. If the unsuccessful operation was a 
control transfer, the port writes a failure code into the SA register and 
then terminates the connection with the host. Naturally, the controller 
will have to be reinitialized. On the other hand, if the unsuccessful 
operation was a data transfer, the port/controller stays online to the 
host and the failure is reported to the host in the response packet for 
the involved operation. Bus parity errors are handled the same as bus data 
timeout errors. 
Fatal Errors 
Various fatal errors may be self-detected by the port or controller. Some 
of these may also arise while the controller is operating its attached 
peripheral device(s). In the event of a fatal error, the port sets in the 
SA register a one in its most significant bit, to indicate the existence 
of a fatal error, and a fatal error code in bits 10-0. 
Interrupt Generation Rate 
Under steady state conditions, at most one ring interrupt will be generated 
for each operation (i.e., command or response transmission). Under 
conditions of low I/O rate, this will be due to response ring transitions 
from empty to not-empty; with high I/O rate, it will be due to command 
ring transitions from full to not-full. If the operation rate fluctuates 
considerably, the ratio of interrupts to operations can be caused to 
decline from one-to-one. For example, an initially low but rising 
operation rate will eventually cause both the command and response rings 
to be partially occupied, at which point interrupts will cease and will 
not resume until the command ring fills and begins to make full to 
not-full transitions. This point can be staved off by increasing the 
permissible depth of the command ring. Generally, the permissible depth of 
the response ring will have to be increased also, since saturation of the 
response ring will eventually cause the controller to be unwilling to 
fetch additional commands. At that point, the command queue will saturate 
and each fetch will generate an interrupt. 
Moreover, a full condition in either ring implies that the source of that 
ring's entries is temporarily choked off. Consequently, ring sizes should 
be large enough to keep the incidence of full rings small. For the command 
ring, the optimal size depends on the latency in the polling of the ring 
by the controller. For the response ring, the optimal size is a function 
of the latency in the ring-emptying software. 
Initialization 
A special initialization procedure serves to (1) identify the parameters of 
the host-resident communications region to the port; (2) provide a 
confidence check on port/controller integrity; and (3) bring the 
port/controller online to the host. 
The initialization process starts with a "hard" initialization during which 
the port/controller runs some preliminary diagnostics. Upon successful 
completion of those diagnostics, there is a four step procedure which 
takes place. First, the host tells the controller the lengths of the 
rings, whether initialization interrupts are to be armed (i.e., enabled) 
and the address(es) of the interrupt vector(s). The port/controller then 
runs a complete internal integrity check and signals either success or 
failure. Second, the controller echos the ring lengths, and the host sends 
the low-order portion of the ringbase address and indicates whether the 
host is one which requires purge interrupts. Third, the controller sends 
an echo of the interrupt vector address(es) and the initialization 
interrupt arming signal. The host then replies with the high-order portion 
of the ringbase address, along with a signal which conditionally triggers 
an immediate test of the polling and adapter purge functions of the port. 
Fourth, the port tests the ability of the input/output bus to perform 
nonprocessor (NPR) transfers. If successful, the port zeroes the entire 
communications area and signals the host that initialization is complete. 
The port then awaits a signal from the host that the controller should 
begin normal operation. 
At each step, the port informs the host of either success or failure. 
Success leads to the next initialization step and failure causes a restart 
of the initialization sequence. The echoing of information to the host is 
used to check all bit positions in the transport mechanism and the IP and 
SA registers. 
The SA register is heavily used during initialization. The detailed format 
and meaning of its contents depend on the initialization step involved and 
whether information is being read from or written into the register. When 
being read, certain aspects of the SA format are constant and apply to all 
steps. This constant SA read format is indicated in FIG. 11. As seen 
there, the meaning of bits 15-11 of SA register 38 is constant but the 
interpretation of bits 10-0 varies. The S4-S1 bits, 316-310, are set 
separately by the port to indicate the initialization step number which 
the port is ready to perform or is performing. The S1 bit 310 is set for 
initialization step 1; the S2 bit 312, for initialization step 2, etc. If 
the host detects more than one of the S1-S4 bits 316-310 set at any time, 
it restarts the initialization of the port/controller; the second time 
this happens, the port/controller is presumed to be malfunctioning. The SA 
register's most significant bit 318, labelled ER, normally is zero; if it 
takes on the value of 1, then either a port/controllerbased diagnostic 
test has failed, or there has been a fatal error. In the event of such a 
failure or error, bits 10-0 comprise a field 320 into which an error code 
is written; the error code may be either port-generic or 
controller-dependent. Consequently, the host can determine not only the 
nature of an error but also the step of the initialization during which it 
occurred. If no step bit is set but ER=1, a fatal error was detected 
during hard initialization, prior to the start of initialization step 1. 
The occurrence of an initialization error causes the port driver to retry 
the initialization sequence at least once. 
Reference will now be made to FIGS. 12A-12D, wherein the details of the 
initialization process are illustrated. 
The host begins the initialization sequence either by performing a hard 
initialization of the controller (this is done either by issuing a bus 
initialization (INIT) command (Step 322) or by writing zeroes to the IP 
register. The port guarantees that the host reads zeroes in the SA 
register on the next bus cycle. The controller, upon sensing the 
initialization order, runs a predetermined set of diagnostic routines 
intended to ensure the minimum integrity necessary to rely on the rest of 
the sequence. (Step 324.) Initialization then sequences through the four 
above-listed steps. 
At the beginning of each initialization step n, the port clears bit 
S.sub.n-1 before setting bit S.sub.n ; thus, the host will never see bits 
S.sub.n-1 and S.sub.n set simultaneously. From the viewpoint of the host, 
step n begins when reading the SA register results in the transition of 
bit S.sub.n from 0 to 1. Each step ends when the next step begins, and an 
interrupt may accompany the step change if interrupts are enabled. 
Each of initialization steps 1-3 is timed and if any of those steps fails 
to complete within the alloted time, that situation is treated as a 
host-detected fatal error. By contrast, there is no explicit signal for 
the completion of initialization step 4; rather, the host observes either 
that controller operation has begun or that a higher-level 
protocol-dependent timer has expired. 
The controller starts initialization step 1 by writing to the SA register 
38 the pattern indicated in FIG. 12A. (Step 326.) Bits 338-332 are 
controller-dependent. The "NV" bit, 332, indicates whether the port 
supports a host-settable interrupt vector address; a bit value of 1 
provides a negative answer. The "QB" bit, 330, indicates whether the port 
supports a 22-bit host bus address; a 1 indicates an affirmative answer. 
The "DI", bit 328, indicates whether the port implements enhanced 
diagnostics, such as wrap-around, purge and poll test; an affirmative 
answer is indicated by a bit value of 1. 
The host senses the setting of bit 310, the S1 bit, and reads the SA 
register. (Step 334.) It then responds by writing into the SA register the 
pattern shown in step 336. The most significant bit 338 in the SA register 
38 is set to a 1, to guarantee that the port does not interpret the 
pattern as a host "adapter purge ccomplete" response (after a spontaneous 
reinitialization). The WR bit, 340, indicates whether the port should 
enter a diagnostic wrap mode wherein it will echo messages sent to it; a 
bit value of 1 will cause the port to enter that mode. The port will 
ignore the WR bit if DI=0 at the beginning of initialization step 1. Field 
342, commprising bits 13-11 and labelled "C RNG LNG," indicates the number 
of entries or slots in the command ring, expressed as a power of 2. 
Similarily, field 344, comprising bits 10-8 and labelled "R RNG LNG", 
represents the number of response ring slots, also expressed as a power of 
2. Bit 346, the number 7 bit in the register, labelled "IE", indicates 
whether the host is arming interrupts at the completion of each of steps 
1-3. An affirmative answer is indicated by a 1. Finally, field 348, 
comprising register bits 6-0, labelled "INT Vector", contains the address 
of the vector to which all interrupts will be directed, divided by 4. If 
this address is 0, then port interrupts will not be generated under any 
circumstances. If this field is non-zero the controller will generate 
initialization interrupts (if IE is set) and purge interrupts (if PI is 
set), and ring transition interrupts depending on the FLAG bit setting of 
the ring entry causing the transition. 
The port/controller reads the SA register after it has been written by the 
host and then begins to run its full integrity check diagnostics; when 
finished, it conditionally interrupts the host as described above. (Step 
350.) 
This completes step 1 of the initalization process. Next, the controller 
writes a pattern to the SA register as indicated in FIG. 12B. (Step 352.) 
As shown there, bits 7-0 of the SA register echo bits 15-8 in step 336. 
The response and command ring lengths are echoed in fields 354 and 356, 
respectively; bit 358 echoes the host's WR bit and bit 360 echoes the 
host's bit 15. The port type is indicated in field 362, register bits 
10-8, and bit 12 is set to a 1 to indicate the beginning of step 2. 
The host reads the SA register and validates the echo when it sees bit S2 
change state. (Step 364.) If everything matches up, the host then responds 
by writing into the SA register the pattern indicated in step 366. Field 
368, comprising SA register bits 15-1, labelled "ringbase lo addres", 
represents the low-order portion of the address of the word [ringbase+0] 
in the communications area. While this is a 16-bit byte address, its 
lowest order bit is 0, implicitly. The lowest order bit of the SA 
register, 370, indicated as "PI", when set equal to 1, means that the host 
is requesting adapter purge interrupts. 
The controller reads the low ringbase address (Step 372) and then writes 
into the SA register the pattern indicated in step 374, which starts 
initialization step 3 by causing bit 376, the S3 bit, to undergo a 
transition from 0 to 1. The interrupt vector field 348 and interrupt 
enabling bit 346 from step 336 are echoed in SA register bits 7-0. 
Next, the host reads the SA register and validates the echo; if the echo 
did not operate properly, an error is signalled. (Step 378). Assuming the 
echo was valid, the host then writes to the SA register the pattern 
indicated in step 380. Bit 382, the most significant bit, labelled "PP", 
is written with an indication of whether the host is requesting execution 
of "purge" and "poll" tests (described elsewhere); an affirmative answer 
is signaled by a 1. The port will ignore the PP bit if the DI bit 328 was 
zero at the beginning of step 1. The "ringbase hi address" field 384, 
comprising SA register bits 14-0, is the high-order portion of the address 
[ringbase+0]. 
The port then reads the SA register; if the PP bit has been set, the port 
writes zeroes into the SA register, to signal its readiness for the test. 
(Step 386.) The host detects that action and itself writes zeroes (or 
anything else) to the SA register, to simulate a "purge completed" host 
action. (Step 388.) After the port verifies that the host has written to 
the SA register (Step 390.), the host reads, and then disregards, the IP 
register. (Step 392.) This simulates a "start polling" command from the 
host to the port. The port verifies that the IP register was read, step 
394, before the sequence continues. The host is given a predetermined time 
from the time the SA register was first written during initialization step 
3 within which to complete these actions. (Step 396) If it fails to do so, 
initialization stops. The host may then restart the initialization 
sequence from the beginning. 
Upon successful completion of intialization step 3, the transition to 
intialization step 4 is effectuated when the controller writes to the SA 
register the pattern indicated in step 398. Field 400, comprising bits 7-0 
of the SA register, contains the version number of the port/controller 
microcode. In a microprogrammed controller, the functionality of the 
controller can be altered by changing the programming. It is therefore 
important that the functionality of the host and controller be compatible. 
The system designer can equip the host with the ability to recognize which 
versions of the controller microcode are compatible with the host and 
which are not. Therefore, the host checks the controller microcode version 
in field 400 and confirms that the level of functionality is appropriate 
to that particular host. (Step 402.) The host responds by writing into the 
SA register the pattern indicated in step 404. It is read by the 
controller in step 405 and 406 and the operational microcode is then 
started. 
The "burst" field in bits 7-2 of the SA register is one less than the 
maximum number of longwords the host is willing to allow per NPR 
(nonprocessor involved) transfer. The port uses a default burst count if 
this field is zero. The values of both the default and the maximum the 
port will accept are controller-dependent. If the "LF" bit 408 is set 
equal to 1, that indicates that the host wants a "last fail" response 
packet when initialization is completed. The state of the LF bit 408 does 
not have any effect on the enabling/disabling of unsolicited responses. 
The meaning of "last fail" is explained below. The "GO" bit 410 indicates 
whether the controller should enter its functional microcode as soon as 
initialization completes. If GO=0, when initialization completes, the port 
will continue to read the SA register until the host forces bit 0 of that 
register to make the transition from 0 to 1. 
At the end of initialization step 4, there is no explicit interrupt 
request. Instead, if interrupts were enabled, the next interrupt will be 
due to a ring transition or to an adapter purge request. 
Diagnostic Wrap Mode 
Diagnostic Wrap Mode (DWM) provides host-based diagnostics with the means 
for the lowest levels of host-controller communication via the port. In 
DWM, the port attempts to echo in the SA register 38 any data written to 
that register by the host. DWM is a special path through initialization 
step 1; initialization steps 2-4 are suppressed and the port/controller is 
left disconnected from the host. A hard initialization terminates DWM and, 
if the results of DWM are satisfactory, it is then bypassed on the next 
initialization sequence. 
Last Fail 
"Last fail" is the name given to a unique response packet which is sent if 
the port/controller detected an error during a previous "run" and the LF 
bit 405 was set in step 404 of the current initialization sequence. It is 
sent when initialization completes. The format of this packet is indicated 
in FIG. 3. The packet starts with 64 bits of zeros in a pair of 32 bit 
words 420. Next there is a 32 bit word 422 consisting of a lower-order 
byte 422A and a higher-order byte 422B, each of which has a unique 
numerical contents. Word 422 is followed by a double word 424 which 
contains a controller identifier. The packet is concluded by a single word 
426. The higher-order byte 426A of word 426 contains an error code. The 
lower half of word 426 is broken into a pair of 8 bit fields 426B and 
426C. Field 426B contains the controller's hardware revision number. Field 
426C contains the controller's software, firmware or microcode revision 
number. 
Submitted as Appendix A hereto is a listing of a disk class and port driver 
which runs under the VMS operating system of Digital Equipment Corp. on a 
VAX-11/780 computer system, and which is compatible with a secondary 
storage subsystem according to the present invention. 
Recap 
It should be apparent from the foregoing description that the present 
invention provides a versatile and powerful interface between host 
computers and peripheral devices, particularly secondary mass storage 
subsystems. This interface supports asynchronous packet type command and 
response exchanges, while obviating the need for a hardware-interlocked 
bus and greatly reducing the interrupt load on the host processor. The 
efficiency of both input/output and processor operation are thereby 
enhanced. 
A pair of registers in the controller are used to transfer certain status, 
command and parametric information between the peripheral controller and 
host. These registers are exercised heavily during a four step 
initialization process. The meanings of the bits of these registers change 
according to the step involved. By the completion of the initialization 
sequence, every bit of the two registers has been checked and its proper 
operation confirmed. Also, necessary parametric information has been 
exchanged (such as ring lenths) to allow the host and controller to 
communicate commands and responses. 
Although the host-peripheral communications interface of the invention 
comprises a port which, effectively, is controller-based, it nevertheless 
is largely localized at the host. Host-side port elements include: the 
command and response rings; the ring transition indicators; and, if 
employed, bus adapter purge control. At the controller, the port elements 
include: command and response buffers, host command and response ring 
pointers, and the SA and IP registers. 
Having thus described the present invention, it will now be apparent that 
various alterations, modifications and improvements will readily occur to 
those skilled in the art. This disclosure is intended to embrace such 
obvious alterations, modifications and improvements; it is exemplary, and 
not limiting. This invention is limited only as required by the claims 
which follow the Appendix. 
APPENDIX 
Notes: 
1. The mass storage controllers is referred to in this Appendix as "UDA"; 
thus, the IP register will appear as UDAIP, for example. 
2. The term "MSCP" in this Appendix refers to the high-level I/O 
communication protocol. 
##SPC1## 
##SPC2## 
##SPC3## 
##SPC4##