 |
Description  |
|
|
BACKGROUND OF THE INVENTION
The invention relates to data processing systems and, more particularly, to recovery from errors occurring in data processing systems employing multiple busses.
In computers and data processing systems, a bus is commonly employed to interconnect the various elements of the system. For example, a central processing unit is typically connected to memory components, input/output (I/O) devices, etc. via a
bus capable of carrying the signals associated with the operation of each element. These signals include, for example, data signals, clock signals, and other control signals. The bus must be capable of carrying such signals to all components coupled to
the bus so that the desired operation can be carried out by the computer system.
As computer systems achieve increasingly higher levels of performance, it is sometimes desirable to provide more than one bus in the computer system. For example, it may be desired to provide a high speed main system bus interconnecting
processors and high speed memory components, and to provide a separate bus interconnecting I/O devices such as disc drives and tape drives to an I/O controller.
The separate busses in a multibus computer system must be interconnected, which introduces complexities into the system. One method for interconnecting busses is to provide a bus interconnect adapter consisting of first and second adapter
modules each connected to one of the busses, and an interconnect bus connecting the two adapter modules. When data is to be transferred from one bus to the other, a transaction is initiated on the one bus, according to a predetermined set of rules,
commonly called a protocol. The adapter module connected to the bus on which the transaction is initiated obtains control of the interconnect bus and transmits data to the other adapter module over the interconnect bus. The other adapter module then
initiates a transaction on the second bus.
A non-pended bus is often employed in multibus computer systems. On such busses, control of the bus remains with the device initiating a transaction on a non-pended bus will result in control of the bus remaining with the initiating device until
the responding device has returned the requested data, tying up the bus until completion of the transaction. A WRITE transaction can be completed quicker since data only has to travel in one direction on the bus.
In order to attain higher bus performance, transactions known as "disconnected WRITE" transactions are often employed on a non-pended bus. A WRITE transaction is initiated from a device on a first bus to a device on the second bus. Immediately
upon successful reception of the transaction by the bus adapter on the first bus, an aknowledge (ACK) confirmation signal is returned on the first bus to the device which initiated the transaction. As far as the initiating device knows, the transaction
has been successfully completed, and additional transactions can occur on the first bus. However, at this point in time, the WRITE data has not yet reached its final destination on another bus. System integrity or reliability can be reduced if an error
occurs after an ACK confirmation is returned to the initiating device. For example, if a parity error occurs as a result of the transmission of data from the first bus to the second bus, completion of the WRITE transaction would result in the storage of
invalid data. Therefore, the erroneous data is not stored. However, the initiating node has already been informed that the transaction was successfully completed (via the ACK signal). The initiating node thus has no means of knowing that the data was
not stored and thus has no reason to initiate a repeat WRITE transaction. The system thus loses necessary data and must identify the error as a non-recoverable error by generating a signal to the operating system software of the computer system to
initiate a system shut-down.
This error handling technique maintains system integrity by preventing non-recoverable errors from generating invalid data or permitting lost data in the system, but also results in system shut-downs where the error would not result in invalid or
lost data. That is, an error occurring during a READ transaction would not result in the loss of data or storage of invalid data, since the requesting node may be signalled to repeat the READ transaction request. However, known prior art multibus
computer systems do not recognize that an error under such conditions is recoverable, and initiate a system shut-down for each transaction in which a parity error occurs.
SUMMARY OF THE INVENTION
It is an object of the present invention to provide a method and apparatus for error recovery in a multibus computer system that maintains system integrity while providing higher system reliability than in prior art systems.
Another object of the invention is to provide a method and apparatus for recovering from errors occurring during inter-bus READ transactions in a multibus computer system which will not result in a system shut-down yet which will produce a system
shut-down if such errors occur during inter-bus WRITE transactions.
It is yet another object of the invention to provide a method and apparatus for repeating a READ transaction when an error occurs during an inter-bus READ transaction.
Additional objects and advantages of the invention will be set forth in part in the description which follows and, in part, will be obvious from the description or may be learned by practice of the invention. The objects and advantages of the
invention will be realized and attained by means of the instrumentalities and combinations particularly pointed out in the appended claims.
To achieve the objects and in accordance with the purpose of the invention, as embodied and broadly described herein, the invention maintains system integrity by causing a system shut-down when non-recoverable errors occur during WRITE
transactions but reduces unnecessary system shut-downs caused by recoverable errors during READ transactions by initiating a repeat of the READ transaction instead of a system shut-down when an error occurs during a READ transaction.
The invention provides a control adapter module providing error recovery in a computer system including a first bus, connected to an interconnect bus through a response adapter module, and a second bus, the second bus having a plurality of data
lines and a plurality of command lines carrying command signals to initiate execution of a plurality of types of transactions on the second bus, the response module including a logic circuit asserting a RECOVERABLE ERROR signal when a parity error occurs
during a READ transaction and asserting a NON-RECOVERABLE ERROR signal when a parity error occurs during a WRITE transaction to initiate a system shut-down. The control adapter module comprises an interconnect interface circuit adapted for connection to
the interconnect bus, a bus interface circuit connected to the interconnect interface circuit and adapted for connection to the second bus decoder means connected to the bus interface circuit and responsive to command signals on the command lines for
asserting a command type signal and for supplying the command type signal to the interconnect interface circuit, and control means responsive to the RECOVERABLE ERROR signal for asserting a signal on the second bus indicating unsuccessful execution of
the current transaction on the second bus.
The accompanying drawings which are incorporated in and constitute a part of the specification, illustrate one embodiment of the invention and, together with the description, serve to explain the principals of the invention.
BRIEF
DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram of a data processing system including a plurality of busses and embodying the present invention;
FIG. 2 is a block diagram of a bus adapter shown in FIG. 1 and embodying the present invention;
FIGS. 3A and 3B are timing diagrams showing clock signals in the bus adapter of FIG. 2;
FIG. 4 is a block diagram of the bus adapter of FIG. 2, showing the signals carried by the interconnect bus;
FIG. 5 is a schematic diagram illustrating the generation of status and control signals in the bus adapter of FIG. 2;
FIGS. 6A and 6B are schematic diagrams showing the relationship between the receive and transmit register files of FIG. 2 and the interconnect bus signals shown in FIG. 4;
FIG. 7 is a detailed diagram showing the format of the receive register file shown in FIG. 2;
FIG. 8 is a detailed diagram showing the format of the transmit register file of FIG. 2;
FIG. 9 is a representative timing diagram showing signals generated by the control and sequencer logic circuit of FIG. 2 during WRITE transactions initiated from the I/O bus shown in FIG. 1;
FIG. 10 is a representative timing diagram showing signals generated by the control and sequencer logic circuit of FIG. 2 during READ transactions initiated from the I/O bus shown in FIG. 1;
FIG. 11 is a representative timing diagram showing signals generated by the control and sequencer logic circuit of FIG. 2 during WRITE transactions initiated by the system bus shown in FIG. 1;
FIG. 12 is a representative timing diagram showing signals generated by the control and sequencer logic circuit of FIG. 2 during READ transactions initiated by the system bus shown in FIG. 1.
FIGS. 13A and 13B are block diagrams, partially schematic, showing the circuitry of the I/O bus adapter module of FIG. 2;
FIGS. 14A and 14B are schematic diagrams illutrating a portion of the circuitry present in the gate array of the system bus adapter module shown in FIG. 2;
FIGS. 15A and 15B are block diagrams of error recovery circuitry in the bus adapter shown in FIG. 1;
FIG. 16 is a diagram showing the error recovery logic portion of the control logic circuit shown in FIG. 2; and
FIG. 17 is a truth table showing the status of logic signals of the error recovery logic portion shown in FIG. 16.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
Reference will now be made in detail to the presently preferred embodiment of the invention, an example of which is illustrated in the accompanying drawings. Throughout the drawings, like reference characters are used to indicate like elements.
FIG. 1 shows an example of a data processing system 20 which embodies the present invention. System 20 includes a system bus 25 which is a synchronous bus that allows communication between several processors, memory subsystems, and I/O systems.
Communications over system bus 25 occur synchronously using periodic bus cycles.
In FIG. 1, system bus 25 is coupled to two processors 31 and 35, a memory 39, one I/O interface 41 and one I/O unit 51. An I/O unit 53 is coupled to system bus 25 by way of an I/O bus 45 and I/O interface 41, which constitutes a bus adapter.
Although only one I/O unit 53 is connected to I/O bus 45 in FIG. 1, a plurality of devices, such as I/O controllers, memory modules, and processors, may be connected to I/O bus 45.
Both system bus 25 and I/O bus 45 propagate data during repetitive bus cycles respectively controlled by system bus clock signals and I/O bus clock signals. In the preferred embodiment, system bus 25 is a 64-bit pended bus having a cycle time of
64 ns. and I/O bus 45 is a 32-bit non-pended bus having a cycle time of 200 ns. The protocol for initiating transactions on system bus 25 is described more completely in U.S. patent application Ser. No. 07/044,952, entitled Method and Apparatus for
Assuring Adequate Access to System Resources by Processors in a Multiprocessor Computer System, filed May 1, 1987 by Richard B. Gillett, Jr. and Douglas D. Williams, and assigned to the assignee of this invention. The protocol for transactions
initiated on I/O bus 45 is described more completely in U.S. Pat. No. 4,661,905 issued Apr. 28, 1987 to Frank C. Bomba, et al. and assigned to the assignee of this invention. The disclosures of the aforementioned application and patent are hereby
expressly incorporated herein by reference.
A central arbiter 28 is also connected to system bus 25 in the preferred embodiment of data processing system 20. Arbiter 28 provides certain timing and bus arbitration signals directly to the other devices on system bus 25 and shares some
signals with those devices.
The implementation shown in FIG. 1 is one which is presently preferred and should not necessarily be intepreted as limiting the present invention. For example, I/O interface unit 41 may constitute a device controller and I/O bus 45 may
constitute a bus connecting the device controller to an I/O device, such as a magnetic disc drive unit.
In the nomenclature used to describe the present invention, processors 31 and 35, memory 39, bus adapter 41, and I/O devices 51 and 53 are all called nodes. A "node" is defined as a hardware device which connects to a bus.
According to the nomenclature used to describe the present invention, the terms "signals" or "lines" are used interchangeably to refer to the names of the physical wires. The terms "data" or "levels" are used to refer to the values which the
signals or lines can assume.
Nodes perform transfers with other nodes over system bus 25. A "transfer" is one or more contiguous cycles that share a common transmitter and common arbitration. For example, a READ operation initiated by one node to obtain information from
another node on system bus 25 requires a command transfer from the first to the second node followed by one or more return data transfers from the second node to the first node at some later time.
A "transaction" is defined as the complete logical task being performed on a bus and can include more than one transfer. For example, a READ operation consisting of a command transfer followed later by one or more return data transfers is one
transaction. A transaction may also be initiated from a node on one bus to a node on another bus.
In the preferred embodiment of system bus 25, the permissible transactions support the transfer of different data lengths and include READ, WRITE (masked), interlock READ, unlock WRITE, and interrupt operations. The difference between an
interlock READ and a regular or noninterlock READ is that an interlock READ to a specific location retrieves information stored at that location and restricts access to the stored information by subsequent interlock READ commands. Access restriction is
performed by setting a lock mechanism. A subsequent unlock WRITE command stores information in the specified location and restores access by other nodes to the stored information by resetting the lock mechanism at that location. Thus, the interlock
READ/unlock WRITE operations are a form of READ-MODIFY-WRITE operations.
Since system bus 25 is a "pended" bus, it fosters efficient use of bus resources by allowing other nodes to use bus cycles which otherwise would have been wasted waiting for responses. In a pended bus, after one node initiates a transaction,
other nodes can have access to the bus before that transaction is complete. Thus, the node initiating that transaction does not tie up the bus for the entire transaction time. This contrasts with non-pended I/O bus 45 in which the bus is tied up for an
entire transaction. For example in system bus 25, after a node initiates a READ transaction and makes a command transfer, the node to which that command transfer is directed may not be able to return the requested data immediately. Cycles on bus 25
would then be avaiilable between the command transfer and the return data transfer of the READ transaction. System bus 25 allows other nodes to use those cycles.
In using system bus 25, each of the nodes can assume different roles in order to effect the transfer of information. One of those roles is a "commander" which is defined as a node which has initiated a transaction currently in progress. For
example, in a WRITE or READ operation, the commander is the node that requested the WRITE or READ operation; it is not necessarily the node that sends or receives the data. In the preferred protocol for system bus 25, a node remains as the commander
throughout an entire transaction even though another node may take ownership of system bus 25 during certain cycles of the transaction. For example, although one node has control of system bus 25 during the transfer of data in response to the command
transfer of a READ transaction, that one node does not become the commander of the bus. Instead, this node is called a "responder."
A responder responds to the commander. For example, if a commander initiates a WRITE operation to write data from node A to node B, node B would be the responder. In addition, in data processing system 20 a node can simultaneously be a
commander and a responder.
Transmitters and receives are roles which the nodes assume in an individual transfer. A "transmitter" is defined as a node which is the source of information placed on system bus 25 during a transfer. A "receiver" is the complement of the
transmitter and is defined as the node which receives the information placed on system bus 25 during a transfer. During a READ transaction, for example, a command can first be a transmitter during the command transfer and then a receiving during the
return data transfer.
When a node connected to system bus 25 desired to become a transmitter on system bus 25, that node asserts one of two request lines, CMD REQ (commander request) and RES REQ (responder request), which are connected between central arbiter 28 and
that particular node. The command request lines and responder request lines are considered to be arbitration signals. As illustrated in FIG. 1, arbitration signals also include point-to-point conditional grant signals from central arbiter 28 to each
node, system bus extend signals to implement multiple bus cycle transfers, and system bus suppression signals to control the initiation of new bus transactions when, for example, a node like a memory is momentarily unable to keep up with traffic on
system bus 25.
Other types of signals which can constitute system bus 25 include information transfer signals, respond signals, control signals, console/front panel signals, and a few miscellaneous signals. Information transfer signals include data signals,
function signals which represent the function being performed on the system bus during a current cycle, identifier signals identifying the commander, and parity signals. The respond signals generally include acknowledge or confirmation signals from a
receiver to notify the transmitter of the status of the data transfer.
Control signals on system bus 25 include clock signals, warning signals, such as those identifying low line voltages or low DC voltages, reset signals used during initialization, node failure signals, default signals used during idle bus cycles,
and error signals. The console/front panel signals include signals to transmit and receive serial data to a system console, boot signals to control the behavior of a boot processor during power-up, signals to enable modification of the erasable PROM of
processors on system bus 25, a signal to control a RUN LIGHT on the front panel, and signals provided battery power to clock logic on certain nodes. The miscellaneous signals, in addition to spare signals, include identification signals which allow each
node to define its identification code.
FIG. 2 shows bus adapter 41 in greater detail. Bus adapter 41 provides an information path between system bus 25 and I/O bus 45 by functioning as a node on each bus. Transactions over bus adapter 41 can be initiated either by system bus 25 or
by I/O 45. System bus-initiated transactions will hereinafter be referred to as CPU transactions, and I/O bus-initiated transactions will be referred to as DMA transactions.
Bus adapter 41 includes a first adapter module 60 and a second adapter module 62 interconnected by an interconnect bus 64, hereinafter called IBUS 64. IBUS 64 includes four command lines I(3:0), thirty-two data lines D(31:0), a parity line P(0),
four address lines FADDR(3:0), and a plurality of control lines to be described below in greater detail. In the above notation, the numbers in parentheses respectively represent the high and low ending bit numbers of the bus field indicated by the
capital letter. For example, D(31:0) represents a thirty-two bit data field extending from low order bit number 0 to high order bit number 31.
Physically, first and second adapter modules 60 and 62 consist of printed circuit cards each inserted into cabinets respectively containing system components connected to system bus 25 and I/O bus 45. IBUS 64 consists of four cables connected at
each end to one of the first and second adapter modules 60 and 62.
First adapter module 60, hereinafter referred to as XBIA module 60, includes a first interconnect interface circuit 66 connected to the IBUS 64 and a first bus interface circuit 68 adapted for connection to system bus 25. Interconnect interface
circuit 66 includes a plurality of bus transceiver circuits for sending and receiving signals from IBUS 64, and will be described below in greater detail. Bus interface circuit 68 is described in greater detail in the aforementioned U.S. patent
application Ser. No. 07/044,952.
XBIA module 60 also includes a large scale integration (LSI) gate array circuit 70 connected to bus interface circuit 68 by a node bus 72, and to interconnect interface circuit 66 by a module data bus 74 and a module control bus 76. Gate array
70 includes a synchronization logic circuit 78, a node control logic circuit 80, and a buffer storage area 82. Buffer storage area 82 includes a receive register file 84 and a transmit register file 86.
Second adapter module 62, hereinafter referred to as XBIB module 62, includes a second interconnect interface circuit 90 connected to IBUS 64 and a second bus interface circuit 92. Interconnect interface circuit 90 includes a plurality of bus
transceiver circuits to send and receive signals over IBUS 64. Second bus interface circuit 92 is connected to a data bus 94, hereinafter referred to as a BCI bus. BCI bus 94 is connected through a register and transfer circuit 96 to second
interconnect interface circuit 90. BCI bus 94 includes parity, command, and data lines buffered from corresponding parity, command, and data lines of I/O bus 45. Register and transfer circuit 96 consists of a buffered data path implemented within a
gate array for transfer of data between data bus 94 and second interconnect interface circuit 90.
XBIB module 62 also includes master sequencer logic circuit 98 and slave sequencer logic circuit 100 which are used to control transactions transferring data between system bus 25 and I/O bus 45. Master and slave sequencer logic circuits 98 and
100 are connected to bus interface circuit 92 by control BCI lines indicated at 102 and 104, respectively. Master and slave sequencer logic circuits 98 and 100 are also connected to a synchronization logic circuit 106, which is in turn connected to
interconnect interface circuit 90.
Bus interface circuit 92 includes a bus interface integrated circuit 108, hereinafter referred to as a BIIC circuit. BIIC circuit 108 includes transceiver circuits directly connected to I/O bus 45 as well as appropriate control logic. BIIC
control 108 is described more completely in the aforementioned U.S. Pat. No. 4,614,905 and in U.S. Pat. No. 4,614,882 issued Sept. 30, 1986 to Wayne C. Parker and John W. May, and assigned to the assignee of this invention. The disclosure of U.S.
Pat. No. 4,614,882 is hereby expressly incorporated herein by reference.
Bus interface circuit 92 also includes a clock logic circuit 110. Clock logic circuit 110 includes an oscillator and appropriate circuitry for generating a clock signal which controls bus cycles on I/O bus 45. Alternatively, another node
connected to I/O bus 45 could generate the master clock signal for control of I/O bus 45, in which case clock logic circuit 110 would derive a local clock signal under control of the I/O master clock signal received from I/O bus 45. In the preferred
embodiment, the I/O bus clock signal establishes a 200 ns. bus cycle time on I/O bus 45.
XBIB module 62 includes an XBIB clock generation circuit 112 which generates a four-phase clock signal T0, T50, T100, and T150 from the I/O bus clock signal, each phase of the multiphase clock signal having a duration of 50 ns. Multiphase clock
signals T0-T150 are shown in FIG. 3B.
The essential function of bus adapter 41 is to permit nodes connected to system bus 25 to initiate transactions to transfer data to or from nodes attached to I/O bus 45 and to permit nodes attached to I/O bus 45 to initiate transactions to
transfer data to or from nodes attached to system bus 25. In each case, a transaction initiated from a node on one bus to transfer data to or from a node on another bus instituted in exactly the same way as all other transactions on the initiating bus,
using the appropriate bus protocol.
The general operation of bus adapter 41 will now be described with reference to FIG. 2. A transaction initiated on I/O bus 45 to transfer data to or from a node connected to system bus 25 will result in command/address information being received
by BIIC 108 and transferred over BCI bus 94 to data path register and transfer circuit 96. A control line BCI CLE (FIG. 13) of lines 104 is asserted by BIIC 108 to indicate that a transaction is available on I/O bus 45.
A transaction is initiated over IBUS 64 such that if appropriate status signals from XBIA module 60 are asserted (in a manner to be described in greater detail below), interconnect interface circuit 90 writes the command/address information over
IBUS 64 through interconnect interface circuit 66 for storage in register file 86 of buffer storage area 82.
Transactions initiated over IBUS 64 require transmission of a predetermined amount of data from XBIB module 62 to XBIA module 60. For example, if a node connected to I/O bus 45 desires to write four words of data to a node connected to system
bus 25, a total of five words must be transmitted from XBIB module 62 to XBIA module 60: a command/address word, and four data words. Since a transaction initiated on I/O bus 45 constitutes a DMA transaction, requiring information to be transmitted from
XBIA module 60 to system bus 25, the appropriate command/address and data words are transferred, one word at a time, and written into either DMA-A or DMA-B buffers of register file 86, depending on which DMA buffer is free. Upon transfer of the last of
the four data words, XBIB module 62 generates a control signal to XBIA module 60 (to be described below in greater detail), causing control logic 80 of XBIA module 60 to initiate a WRITE transaction transmitting command/address and data words through bus
interface circuit 68 onto system bus 25.
If a node attached to I/O bus 45 desires to read data stored in a node attached to system bus 25, the node initiates a DMA READ transaction on I/O bus 45 consisting of a single command/address word which is transferred from I/O bus 45 through
XBIB module 62 and XBIA module 60 to system bus 25 for delivery to the appropriate node on system bus 25. Since I/O bus 45 is a non-pended bus while system bus 25 is a pended bus, I/O bus 45 is tied up until such time as the requested data is
transferred from the designated system bus node over system bus 25. XBIA module 60, IBUS 64, and XBIB module 62 to I/O bus 45.
System bus 25, on the other hand, is a pended bus, which means that other transactions can occur over system bus 25 while the node designated in the READ transaction is obtaining the desired data. When the node is ready to transmit the data back
from system bus 25 to the requesting node on I/O bus 45, such node initiates a response transaction on system bus 25, in the manner described more completely in the aforementioned U.S. patent application Ser. No. 07/004,952, causing appropriate data to
be stored in the DMA receive buffer of receive register file 84 in XBIA module 60. Control logic 80 causes appropriate control signals to be asserted over IBUS 64 to XBIB module 62. Slave sequencer 100 generates appropriate control signals through
second interconnect interface circuit 90, IBUS 64, and first interconnect interface circuit 66 to read the data stored in the DMA receive register file 84, converted into a format compatible with I/O bus 45, back over IBUS 64 to data path register and
transfer circuit 96 for transmission through bus interface circuit 92 onto I/O bus 45.
FIGS. 3A and 3B show clock signals respectively generated by XBIA module 60 and XBIB module 62. As can be seen in FIG. 3A, XBIA module 60 generates six clock signal phases each having a 10.7 ns. 21.3 ns assertion time period. These phases are
derived from master clock signals carried by system bus 25 which establish a cycle time of 64 ns. for system bus 25. Similarly, FIG. 3B shows four clock signal phases each having a period of 50 ns. The phases shown in FIG. 3B are derived from master
clock signals carried by I/O bus 45 which establish a cycle time of 200 ns. for I/O bus 45.
FIG. 4 shows the signals which constitute IBUS 64. As shown therein, IBUS 64 includes a data path having a plurality of data signals represented by I(3:0) and D(31:0) and P(0). Interconnect bus 64 also includes a first control path having a
plurality of first control signals related to control of the data signals. In the preferred embodiment, the first control signals are indicated in FIG. 4 at 130. The IBUS 64 further includes a second control path having a plurality of second control
signals not related to control of the data path. In a preferred embodiment, the second control signals are indicated at 132 in FIG. 4. Signals constituting IBUS 64 are more completely described below.
IBUS BI-DIRECTIONAL SIGNALS
IB D (31:00) (IBUS Data Field)--
The IB D(31:0) field is used for the transfer of addresses and data to and from register files 84 and 86. The field is directly mapped to the BCI D(31:0) field of BIIC 108.
This field is asserted for 200 ns when the contents of register files 84 and 86 are read or written under the control of module 62.
IB I(3:0) (IBUS Instruction Field)--
The IB I(3:0) field is used for the transfer of Commands, Read status codes, and Write masks to and from the register files 84 and 86. The field is directly mapped to the BCI I(3:0) field of BIIC 108.
This field is asserted for 200 ns when the contents of the register files 84 and 86 are read or written under the control of module 62.
IB P0 (IBUS Parity)--
IB P(0) is the parity bit for the IB D(31:0) and IB I(3:0) fields. The bit is directly mapped to the BCI Parity bit of the BIIC 108. Parity is odd.
This field is asserted for 200 ns when the contents of the register files 84 and 86 are read and written under the control of the XBIB module.
XBIB TO XBIA CONTROL SIGNALS
IM FADDR(3:0) L (Reg File Address Field)--
The IM FADDR(3:0) L field is used by the XBIB Module to address any one of 16 possible locations in the register files 84 and 86 (as seen from the IBUS side).
This field is asserted for 200 ns when the contents of the register files 84 and 86 are read or written under the control of the XBIB module.
______________________________________ (AS SEEN ON THE IBUS) FADDR LOCATION READ/WRITE STATUS ______________________________________ 1111 CPU CMD/ADDR READ ONLY 1110 CPU DATA/MSK READ/WRITE 1101 RESERVED N/A 1100 DMA-A CMD/ADDR WRITE ONLY
1011 DMA-A DATA/MSK 0 READ/WRITE 1010 DMA-A DATA/MSK 1 READ/WRITE 1001 DMA-A DATA/MSK 2 READ/WRITE 1000 DMA-A DATA/MSK 3 READ/WRITE 0111 RESERVED N/A 0110 RESERVED N/A 0101 RESERVED N/A 0100 DMA-B CMD/ADDR WRITE ONLY 0011 DMA-B DATA/MSK 0 WRITE
ONLY 0010 DMA-B DATA/MSK 1 WRITE ONLY 0001 DMA B DATA/MSK 2 WRITE ONLY 0000 DMA-B DATA/MSK 3 WRITE ONLY ______________________________________ NOTE There can only be one DMA Read Transaction pending at a time. DMA Read Return data will always be
loaded into the DMAA Receive Buffer, regardles of which DMA Transmit buffer was initially used to transmit the "Read" command. Therefore, there is no need to have a DMAB Receive Buffer. This is why the DMAB Buffer in the above chart is classified as
"Write Only".
IM FILE LOAD STROBE L--
IM FILED LOAD STROBE L causes the data currently asserted on IB D(31:0), IB I(3:0) and IB P0 to be loaded into the register files 86 at the address specified by the address lines, IM FADDR(3:0) L.
The XBIB Module asserts IM FILE LOAD STROBE L 50 ns after asserting IB D(31:0), IB I(3:0), IB P0 and IM FADDR(3:0)L. The XBIB Module deasserts IM FILE LOAD STROBE L 50 ns before deasserting IB D(31:0), IB I(3:0), IB P0 and IM FADDR(3:0)L.
IM FILE READ ENABLE L--
IM FILE READ ENABLE L, when asserted, causes the contents of the register file 84 at the address specified by the address lines, IM FADDR(3:0)L to be asserted onto IB D(31:0), IB I(3:0) and IB P0 of the IBUS.
The XBIB Module asserts IM FILE READ ENABLE L for at least 200 ns when it is reading the contents of a location in the register file.
IM DMA READ CMD L--
IM DMA READ CMD L is used by the XBIA to determine if a DMA I/O bus to system bus READ transaction is in progress when the XBIA detects an IBUS parity error during the time that the XBIB is loading the I/O bus command/address data. This
information will be used by the XBIA to determine if it is necessary to issue a system crash transaction on system bus 25. If this signal is asserted, and an IBUS parity error is detected by the XBIA, and XBIA 60 decodes a READ command on I(3:0), the
XBIA should abort this trasaction and issue IR READ DATA FAULT L to the XBIB.
IM CPU XACTION DONE L--
IM CPU XACTION DONE L indicates that a CPU Command has been processed by the XBIB Module and the CPU Transaction may now be completed by the XBIB Module.
The XBIB Module asserts IM CPU XACTION DONE L for 200 ns when it has completed processing a CPU Command over the IBUS Interface. If the command was a WRITE, (does not require additional Transfers to complete) the XBIA module will release the CPU
Buffer for further transactions. If the Command was a "Read" (requires an additional Transfer for returning data to the commander) the XBIA will complete the return data transfer and then release the CPU Buffer for further transactions.
IM CPU LOC RESPONSE L--
IM CPU LOC RESPONSE L indicates that an INTERLOCKED READ CPU Command that has been issued onto the I/O bus was unable to complete due to the resource being locked on the I/O bus.
The XBIB Module asserts IM CPU LOC RESPONSE L for 200 ns along with IM CPU XACTION DONE L when it is unable to complete the requested transaction due to a locked resource on the I/O bus. The XBIB module will release the CPU Buffer for further
transactions, and will issue the LOC response onto the system bus.
IM DMAA BUF LOADED L--
IM DMAA BUF LOADED L indicates that the XBIB Module has loaded a command/data (if applicable) over the IBUS into the DMA-A Buffer. The XBIB Module asserts IM DMAA BUF LOADED L for 200 ns. When the XBIA Module senses IM DMAA BUF LOADED L it will
process the transaction over system bus 25.
If the DMA transaction was a Write, no status is returned to the XBIB and the transaction is completed by the XBIA.
If the DMA transaction was a Read (I.E., IR READ DATA AVAIL L, IR DMA LOC RESPONSE L, IR READ DATA FAULT L), Read status is returned to the XBIB Module.
IM DMAB BUF LOADED L--
IM DMAB BUF LOADED L indicates that the XBIB Module has loaded a command/data (if applicable) over the IBUS into the DMA-B Buffer. The XBIB Module asserts IM DMAB BUF LOADED L for 200 ns. When the XBIA Module senses IM DMAB BUF LOADED L it will
process the transaction over the system bus 25.
If the DMA transaction was a Write, no status is returned to the XBIB and the transaction is completed by the XBIA.
If the DMA transaction was a Read, Read status is returned to the XBIB Module (I.E., IR READ DATA AVAIL L, IR DMA LOC RESPONSE L, IR READ DATA FAULT L).
IM CLR READ STATUS L--
The XBIB Module asserts IM CLR READ STATUS L for 200 ns when it has completed processing DMA Read Status information and, therefore, wants to clear the XBIA Module's DMA Read Status Flags.
The assertion of IM CLR READ STATUS L by the XBIB Module causes the XBIA Module to clear IR READ DATA FAULT L, IR DMA LOC RESPONSE L and IR READ DATA AVAIL L.
IM XACTION FAULT L--
The XBIB Module asserts IM XACTION FAULT L for 200 ns along with IM CPU XACTION DONE L whenever it detects an error on a CPU Transaction. If the XBIA's corresponding "CPU READ CMD" flag is set the XBIA will issue an RER Response to the XMI. If
the XBIA's "CPU READ CMD" flag is not set, the XBIA will terminate the transaction and issue an IVINTR transaction with MEM WRITE ERROR set in the type field.
The XBIB Module asserts IM XACTION FAULT L for 200 ns along with IM DMAA BUF LOADED L or IM DMAB BUF LOADED L whenever it detects an error on a DMA Transaction. The XBIA will respond by ignoring any errors if may have detected during the loading
of its DMA Buffer, aborting the pending transaction, and releasing the DMA Buffer for subsequent transactions.
IM CLR INTR L--
The XBIB asserts IM CLR INTR L for 200 ns whenever IR XBIA ERR BIT SET L is asserted, and the XBIB decodes a system bus IDENT command with the IDENT LEVEL field having bit 19 set.
When the XBIA module receives IM CLR INTR L it will clear the assertion of IR XBIA ERR BIT SET L.
IM BI BAD L--
IM BI BAD L is used for reporting node failures on the I/O bus. It is directly mapped from the signal "BI BAD L" from the I/O bus.
The assertion of BI BAD L will cause the assertion of XMI BAD L.
IM XMIB POWER OK (3:0) H--
IM XBIB POWER OK (3:0) H indicates to the XBIB Module that the XBIB Module is powered on and should be capable of correctly responding to commands/data via the IBUS Protocol.
It also indicates to the XBIA module that all 4 IBUS cables are plugged into their correct slots. Each cable will have a unique IM XBIB POWER OK H signal. The signal will be placed at a different pin location on each cable. These 4 signals
ANDED together on XBIA will assert a bit in an XBIA register that will signify that the cables are plugged into both the XBIA and the XBIB, and that they are plugged into their proper location on both modules.
IM BUF BI RESET L--
IM BUF BI RESET L is a buffered version of BI RESET L which originates from the I/O BUS. When asserted the XBIA Module should assert XMI RESET L on the system Bus if IM XBIB POWER OK (3:0) H is also asserted.
IM BI AC LO L--
IM BI AC LO L is a buffered version of BI AC LO L which originates from the I/O bus. When asserted the XBIA Module will set the BCI AC LO tatus bit in the "XBIA Error Summary Register" and generate an IVINTR (system crash) to the system Bus.
XBIA TO XBIB CONTROL SIGNALS
IR DMAA BUF AVAIL L--
IR DMAA BUF AVAIL L indicates that the DMA-A Buffer in the XBIA Reg File 86 is available to be loaded by the XBIB Module with command data (if applicable).
The XBIA Module asserts IM DMAA BUF AVAIL L when it has completed processing any pending command/data in the DMA-A Buffer over the first bus interconnect interface 68, thus indicating to the XBIB Module that the DMA-A buffer is available.
The XBIA Module de-asserts IR DMAA BUF AVAIL L when IM DMAA BUF LOADED L is asserted by the XBIB Module, thus indicating that a new command/data has been loaded into the DMA-A Buffer by the XBIB Module.
IR DMAB BUF AVAIL L--
IR DMAB BUF AVAIL L indicates that the DMA-B Buffer in the XBIA Reg File 86 is available to be loaded by the XBIB Module with command and data (if applicable).
The XBIA Module asserts IM DMAB BUF AVAIL L when it has completed processing any pending command/data in the DMAB Buffer over the system bus 25, thus indicating to the XBIB Module that the DMA-B buffer is available.
The XBIA Module deasserts IR DMAB BUF AVAIL L when IM DMAB BUF LOADED L is asserted by the XBIB Module, thus indicating that a new command/data has been loaded into the DMA-B Buffer by the XBIB Module.
IR CPU BUF LOADED L--
IR CPU BUF LOADED L indicates that a CPU command has been loaded from the system bus 25 into the CPU Buffer of the XBIB Ref File 84 and is ready to be processed by the XBIB Module.
IR CPU BUF LOADED L is deasserted by the XBIA Module when it detects IM CPU XACTION DONE L or IM CPU XACTION DONE L and IM XACTION FAULT L from the XBIB Module.
IR XMI ERR BIT SET L--
IR XMI ERR BIT SET L indicates that an error bit has been set in one of the XBIA error registers. This status bit causes the XBIB Module to initiate a Vectored Interrupt (INTR) command to system bus 25.
IR READ DATA AVAIL L
IR READ DATA AVAIL L indicates that the data of a previously initiated DMA Read transaction is available in the DMA-A/B Receive Buffer of the XBIA Reg File 84 and may be read by the XBIB Module.
IR READ DATA AVAIL L is asserted by the XBIA Module when it has loaded the XBIA Reg File's DMA-A/B Receive Buffer with data from the XMI Interface 68.
IR READ DATA AVAIL L is deasserted by the XBIB Module via a "direct clear input" to the latch/flop when it asserts IM CLR READ STATUS L.
IR READ DATA FAULT L--
IR READ DATA FAULT L indicates that a previously initiated DMA Read transaction has failed due to an unrecoverable failure on first interconnect module 60.
IR READ DATA FAULT L is asserted by the XBIA Module when it has detected one of the following errors:
RER Response decoded on the XMI Function Field.
Read Sequence Error detected on the XMI Function Field.
Timeout on system bus 25
IR READ DATA FAULT L is deasserted by the XBIB Module via a "direct clear input" to the latch/flop when it asserts IM CLR READ STATUS SL.
IR DMA LOC RESPONSE L--
| | |
