Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

High Performance Interface Protocol

IP.com Disclosure Number: IPCOM000101724D
Original Publication Date: 1990-Aug-01
Included in the Prior Art Database: 2005-Mar-16
Document File: 3 page(s) / 123K

Publishing Venue

IBM

Related People

Frazier, GR: AUTHOR [+2]

Abstract

The protocol described here provides for sending multiple commands from a host computer to an adapter card without waiting for a "not busy" indication between commands. It also allows the command completion status for multiple commands to be sent with only a single interrupt and read operation. This eliminates multiple interrupt processing which is necessary when each command completion requires a separate interrupt. An additional capability of the protocol is that it provides a method of transferring hardware failure information simultaneously with command completion status without affecting the performance when errors are not occurring.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

High Performance Interface Protocol

       The protocol described here provides for sending multiple
commands from a host computer to an adapter card without waiting for
a "not busy" indication between commands.  It also allows the command
completion status for multiple commands to be sent with only a single
interrupt and read operation.  This eliminates multiple interrupt
processing which is necessary when each command completion requires a
separate interrupt.  An additional capability of the protocol is that
it provides a method of transferring hardware failure information
simultaneously with command completion status without affecting the
performance when errors are not occurring.

      For commands, the adapter has a region of memory which is
accessible to both the adapter processor and the host. This memory is
subdivided into (N+1) "mailboxes," each mailbox being M bytes long
(see Fig.  1).  Each mailbox is used for the transfer of command
information from the host to the adapter and is subsequently used for
the transfer of status information from the adapter to the host upon
command completion.  (The  adapter also contains an (N+1) bit
interrupt status register (ISR), which is described later.)

      In order to send a command, the host fills mailbox n with a
command block.  The bytes of the command block may be sent in any
order with the restriction that the last byte (Byte M) of any command
must be sent last.  After sending the last byte of the command, the
host must not alter the contents of the mailbox until the command
completes, at which time the mailbox may be reused.  The host may
send as many commands as desired without polling any adapter "busy"
registers so long as there are mailboxes available which do not
contain unfinished commands.

      When byte M of any mailbox has been filled by the host, the
adapter microprocessor is interrupted with a "mailbox loaded"
interrupt.  An N bit "mailbox loaded register" is provided for the
adapter microprocessor which must be read upon any "mailbox loaded"
interrupt.  Hardware is provided which sets bit n of this register as
byte M of mailbox n is filled by the host.  Therefore, when the
adapter processor reads the mailbox loaded register, the positions of
the bits which are set correspond to the mailbox numbers which
contain commands.  Hardware is also provided which clears all bits of
this register as it is read by the adapter microprocessor, thereby
deactivating the microprocessor interrupt.  After reading the mailbox
loaded register, the adapter begins execution of the commands which
have been loaded by the host.  No host actions are needed until the
adapter completes the commands.

      For transfer of status information, both the mailbo...