Input/output system for multiprocessors.

BACKGROUND OF THE INVENTION

0001The present invention relates generally to commun­ication between a plurality of digital processors in a multiprocessor-based computer system and peripheral devices, such as disk drives and tape drives, which operate at disparate speeds. More particularly the invention relates to an architecture for communicating between two indepen­dently-operating ports and peripheral devices coupled to a version of the Small Computer System Interface (SCSI).

0002Several classes of digital computer systems use a plurality of independent processors to perform computer operations. Examples include fault-tolerant, modular and parallel processing systems. These processors, herein referred to as host processors, require digital data ex­change (input and output) with other devices, known as peripherals.

0003Typically data is exchanged via a system bus under the supervision of a bus controller. Information exchanged with the peripheral devices is typically under the supervi­sion of an input/output subsystem called a device control­ler.

0004In one example of a multiprocessor-based fault-tolerant computing system disclosed in U.S. Patent No. 4,228,496 to Katzman et al., a device controller is provided which facilitates exchange of high speed, essentially synchronously-communicated data with relative low-speed, essentially asynchronous peripheral devices. The device controller is constructed to insure that no single host processor failure can impair system operation. The Katzman et al. patent is incorporated herein by reference and made a part hereof, since a specific embodiment of the present invention is intended to improve upon the device controller disclosed in the Katzman et al. patent.

0005The device controller in the Katzman et al. patent is constructed with the intention of handling exchange of data at relatively high data rates as far as the host processor is concerned in order to minimize interference with programs running in the host processors. The device controller is an interrupt-driven system and provides an input/output program interrupt (IO interrupt) only upon completion of a data transfer in order to relieve the host processor of the burden of being dedicated to the peripheral device during data transfer. The device controller has multiple ports, each of which is logically and physically independent of all other ports so that each device control­ler can be connected for access to at least two different host processors.

0006To accomplish its tasks, the device controller of the computing system disclosed in the Katzman et al. patent empIoys a microprocessor which is dedicated to input/output operations (I/O MPU). The I/O MPU controls an input/output bus structure internal to the device controller (device controller bus structure) over which is carried all data from any requesting host processor and any responding peripheral device as well as data intended solely for its own operation and control of commands. It is through this internal bus structure that the host processor informs the I/O MPU of data transfer type, requested peripheral device, data block size, priority and the like. It is also through the I/O MPU and the device controller bus structure that "ownership" of the operation of the device controller is effected.

0007Experience with the device controller in accor­dance with the patent has uncovered a number of shortcom­ings. For example one shortcoming is within the device controller itseIf. It has been discovered that, despite the advantage of independent control of the input/output func­tions by a dedicated microprocessor, such an arrangement does not make the most efficient usage of the valuable time of the host processor. It has been found that even the fastest microprocessors still require a finite time to interpret commands (e.g., input/output requests), which does not make efficient use of time on both the device controller bus structure and on the system bus in the relatively complex environment of a multiprocessor system.

0008Moreover, in the device controller of the Katzman et al. patent, the device controller is constructed to grant "sole ownership" to onIy one host processor at a time through a switching scheme which selects among ports of the device controller. Conventionally, there are only two ports and only one ownership latch which grants ownership to either a first port or a second port and hence only one channel I/O bus. Hence, even though there are in theory multiple paths to a peripheral device through a device controller, only one peripheral can be used by a host processor, and only one host processor can have access to any peripheral through the device controller when but a single port is in use and in the process of exchanging data. Access to the device controller from other host processors must thereafter be made through the host processor having ownership of the device controller. This represents a serious shortcoming when several peripheral devices are coupled through a single device controller and several host processors desire access to those peripheral devices.

0009Another shortcoming of the device controller in accordance with the invention disclosed in the Katzman et al. patent is the limited ability to connect the device controller with large numbers of peripheral devices or peripheral devices having an interconnection structure of selected types which have been widely accepted as standards. With the proliferation of peripheral device types, it is no longer feasible to construct a dedicated interface for each type or brand of peripheral device, each with its unique requirements and characteristics. This is particularly true at the growing "low end" of the computer market, where systems once costing hundreds of thousands of dollars are being superseded by system costing only a fraction of its predecessor. One reason has been standardization, which creates economies of scale.

0010However, there has been little done to merge fault-tolerant computing systems with their advantages with the various standard input/output interfaces or buses. One emerging peripheral device input/output interface is the SCSI bus, which is now widely accepted for many personal computer applications. As a consequence, many low-cost yet high-quality peripheral devices are now available.

0011What is needed is a device controller which is not subject to these shortcomings.

SUMMARY OF THE INVENTION

0012According to the invention, in a digital computer system which employs a plurality of host processors, at least two system buses and a plurality of peripheral in­put/output ports an input/output system is provided whereby ownership of the input/output channels is shared. The device controller includes a first port controller having a first ownership latch, a second port controller having a second ownership latch, a first bus, a dedicated micropro­cessor having control over the first bus (the MPU bus), a second, higher-speed bus, a multiple-channel direct memory access (DMA) controller which is an extremely fast state machine, which controls the second bus (the data buffer bus) and access to the input-output ports, a bus switch whereby data communicated between devices on the MPU bus and devices on the data buffer bus are exchanged efficiently, a multiple port peripheral device interface, such as a Small Computer System Interface (SCSI), and at least provision for inter­face with data communication equipment (DCEs) or data terminal equipment (DTEs). The data buffer bus operates in a synchronous manner. The DMA provides dynamic arbitration of the use of channels of the DMA. The DMA allocates alternate bus clock cycles in response to requests to exchange data. The microprocessor is allowed access to the data buffer bus only if the data buffer bus is not in use for data transfer.

0013In a specific embodiment, the data buffer bus has coupled to it all input/output ports to the system bus, the DMA controller, a high-speed buffer memory, the bus switch, and a multipIexed SCSI controller, and the MPU bus has coupled to it a microprocessor, program memory, data memory, command registers, communications devices (such as interfac­es for data terminal equipment and data communication equipment), and the bus switch. All data is routed through the data buffer bus. The microprocessor configures the SCSI controller and the DMA controller for the type of data exchange. The latches associated with each port grant ownership to either port or all ports allowing data exchange between addressed peripheral devices and requesting ports. Ownership is not surrendered so long as a host processor has need of a device controller.

0014The invention will be better understood by refer­ence to the following detailed descriptions taken in con­junction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

0015<ul id="ul0001" list-style="none"><li>Figure 1 is a block diagram view of a multiproces­sor system constructed in accordance with one embodiment of the present invention, including a plurality of dual-port device controllers sharing peripheral devices coupled to Small Computer System Interface buses.</li><li>Figure 2 is a simplified block diagram of one embodiment of a device controller according to the invention illustrating a direct memory access controller, a data buffer bus, a microprocessor bus, a bus switch and two SCSI buses.</li><li>Figure 3 is a simplified block diagram one embodiment of a dual-channel DMA controller.</li><li>Figure 4 is simplified state diagram of operation of one embodiment of a dual-channel DMA controller.</li><li>Figure 5 is block diagram of the architecture of a specific embodiment of a dual-channel DMA controller.</li><li>Figure 6 is a timing diagram illustrating one type of operation of a specific embodiment of a dual-channel DMA controller.</li><li>Figure 7 is a block diagram of a specific embodi­ment of two peripheral port controllers according to a specific embodiment of the invention.</li><li>Figure 8 is a block diagram of a specific embodi­ment of a Small Computer System Interface controller accord­ing to the invention.</li><li>Figure 9 is a block diagram illustrating a specif-­ic embodiment of the relationship between software modules according to the invention.</li><li>Figure 10 is a block diagram illustrating a specific embodiment of calling protocols between software modules according to the invention.</li><li>Figure 11 is a block diagram of a bus switch in accordance with a specific embodiment of the invention.</li></ul>

DESCRIPTION OF SPECIFIC EMBODIMENTS

0016Reference is made to Figure 1 for an overview of a specific embodiment of the invention. In Figure 1, several processor modules, hereinafter host processors 33 (also designated 33-0 and 33-1), are connected by dual interprocessor buses (IPBs) 35, an X bus (IPB-X) and a Y bus (IPB-Y). Each bus 35 is controlled by a bus controller 37. Each host processor 33 is provided with an input/output channel (I/O channel) 109 (designated 109-0 and 109-1) coupled to a channel I/O bus (CIO bus) 39 (designated 39-0 and 39-1).

0017Figure 1 also shows a plurality of device control­lers 41 (designated 41-0 and 41-1) connected in accordance with the invention. The CIO bus 39 of each host processor 33 is coupled to preferably at least one port of each device controller 41, and more specifically, first CIO bus 39-0 is connected to a first peripheral port controller (PPC-0) 43-0 of each device controller 41-0 and 41-1 and second CIO bus 39-1 is coupled to a second peripheral port controller (PPC-1) 43-1 of a each device controller 41-0 and 41-1.

0018The device controller 41 is provided with a protocol controller (SPC) 44 for two peripheral device buses 111 of a standardized configuration known as the Small Computer System Interface (SCSI), designated herein SCSI-0 111-0 and SCSI-1 111-1. The SCSI standard has been de­scribed in publications by the American National Standards Institute as ANSI Standard X3.131-1986, and commercial component parts are available for implementing functions of the SCSI bus. For example, in a specific embodiment of the invention, the SCSI interface is implemented by a type MB87030 chip made by Fujitsu and available from Fujitsu America of Santa Clara, California.

0019The primary function of the SCSI buses 111 is to provide port connections for standard SCSI peripherals, such as a tape drive 49 (with internal SCSI controllers) and disk drives 45 (with internal SCSI controllers). The SCSI bus is of a type which allows more than one device controller to be connected thereto. (For example, up to eight units or devices, including device controllers, can be connected to a single SCSI bus.) Hence, both the first device controller 41-0 and the second device controller 41-1 are connected to the first SCSI bus 111-0, the first SCSI bus 111-0 having connected thereto a first set of SCSI peripheral devices 45 and 49. In addition, the first device controller 41-0 and the second device controller 41-1 are also connected to the second SCSI bus 111-1, the second SCSI bus 111-1 having connected thereto a second set of SCSI peripheral devices 45. Thus each CIO bus 39 has at least two paths to each SCSI device 45 or 49, and each host processor has at least four paths (two through another host processor via an IPB 35) to each SCSI device 45 or 49. This configuration substantially enhances the reliability of the overall computer system and permits the temporary removal for example of one device controller without compromising access to any other of the SCSI devices.

0020As a further feature, the device controllers 41 may also provide for access to or from the host processors 33 for asynchronous terminals 47 and packetized communica­tion links 347 including links conforming to the ANSI protocol standards X.25 or X.21.

0021The configuration and computer architecture represented by Figure 1 is a new type of system representing a departure and enhancement over the structure disclosed in the Katzman et al. patent, incorporated herein by reference.

0022Referring now to Figure 2, there is shown a block diagram of the device controller 41 in accordance with a specific embodiment of the invention. According to the invention, there is provided in combination a data buffer bus (DB bus) 100 and a microprocessor bus (MPU bus) 102 coupled to one another by means of a first bus switch (DBBS) 104. In accordance with the invention, the DB bus 100 is a synchronous bus whose operational clock rate is a substan­tially different rate than he MPU bus 102, and the DBBS 104 is a bus switch which buffers transfers of data and commands between the DB bus 100 and the MPU bus 102 to assure timely transfer of data and commands between the buses operating at disparate clock rates.

0023Coupled to the DB bus 100 are a data buffer direct memory access controller (DB DMA) 106, the first PPC 43-0, the second PPC 43-1, the SPC 44 and a high speed read/write random access memory (DB MEM) 108 for temporary storage of all data-type information transferred over the DB bus 100.

0024CoupIed to the MPU bus 102 is a microprocessor (MPU) 119 (such as a type 68010 microprocessor made by or under license to Motorola), instruction memory such as Electronically Erasable Read Only Memory (EEROM) 110 in the amount of 16 KB, random access memory (MEM) 112 in the amount of 512 KB, a conventional direct memory access controller (DMA) 114 such as a type 68450 DMA device made by, e.g., Hitachi (part HD68450), and a standard serial communication chip device (SCC) 116 (such as a Zilog Z8030 serial communication chip) supporting both X.25 bit-oriented packet protocol and X.21 byte-oriented packet protocol, at least one standard dual universal asynchronous receiver-transmitter (DUART) 118-1 and 118-2 such as a Signetics type 2861 chip made by Signetics. The external configuration of the SCC 116 and the DUARTs 118 are device dependent and so require no further explanation.

0025The DMA 114 is used to transfer data to and from the SCC 116 or the DUARTs 118 and the MEM 112 on the MPU bus. It cooperates closely with the MPU 119. DMA 114 channels can be programmed to move large data blocks and generate an interrupt signal to the MPU 119 at the end of a transmission.

0026The SPC 44 has two ports 144-0 and 44-1 for SCSI buses 111-0 and 111-1. The SCSI buses are multiplexed. In addition, as explained hereinafter, an SPC bus 120 is provided as part of the SPC configuration together with SPC bus switch 122, which provides bi-directional command and control coupling between the MPU bus 102 and the SPC bus 120.

0027The device controller 41 generates or responds to a plurality of interrupts on interrupt lines (not shown for clarity). The interrupts are generated by I/O channels through the PPCs 43, by I/O devices through the SPC 44, by DMA channels from the DB DMA l06 or DMA 114, by communica­tion interfaces such as the SCC 116 and the DUARTs 118, by timeouts and by hardware errors. Of primary interest is the interrupt issued by the PPCs 43 in response to an EIO from a host processor.

0028With reference to Figure 3, the DB DMA 106 is a very fast state machine whose function is to control access to the DB bus 100. The DB DMA 106 employs a technique known as dynamic arbitration to allocate time for data transfer on the DB bus 100 between the PPCs 43 and the peripheral devices through the SPC 44. To this end, the DB DMA 106 includes arbitration logic 200 for allocating time on the DB bus 100 (Figure 2) between two channels of data transfer functions as well as device controller management functions carried out under control of the MPU 119, all of which require usage of the DB bus 100. The DB DMA 106 is a dual channel device which is capable of concurrent support for two channels of data, of being reprogrammed to support chaining of consecutive frames of data without having to repeat an interrupt cycle for each frame of data, and of being reprogrammed to support data transfer at twice the standard rate by use of both channeIs for a single task.

0029Referring to Figure 3, Figure 4 and Figure 6 together, the arbitration logic is responsive to the follow­ing requests: Request for Channel 0 (REQ0*) (the * is used to denote logic LOW is TRUE), Request for Channel 1 (REQ1*), and bus request for the MPU 119 (BREQ*). The DB DMA issues at least the following interrupts: Acknowledge availability of Channel 0 (ACK0*), Acknowledge availability of Channel 1 (ACK1*), Bus usage granted in response to BREQ* (BGNT*). A sample of the relative timing of each of these interrupts is shown in Figure 6 in relation to a system clock (SYSCLK) and two-channel data transfer (XFR0 and XFR1). Figure 6 illustrate operation of the DB DMA 106 if all request signals are asserted simultaneously. First a three-way confωict is illustrated and then a two-way con­flict between channels is illustrated. Data transfer via a single channel is permitted to occur no more often than one-half of the available time. However, the DB DMA 106 via the arbitration logic 200 exercises such control over the DB bus 100 that virtually no clock cycle is wasted if there is data to be transferred or a command to be processed. The maximum latency (210 Figure 6) from DMA Request to DMA Acknowledge is two clock cycles for either channel of the DB bus 100. (The latency time for a bus request depends on the load on the channels. There may be a timeout provided for example. In the extreme, the latency time can be no longer than the time required to exhaust the queue of outstanding channel requests, since all channel requests are generated by the MPU 119.)

0030Referring again to Figure 3 and Figure 4, the arbitration logic is in communication with three substan­tially identical state machines, a channel 0 state machine (CH0 SM) 202, a channel 1 state machine (CH1 SM) 204 and a bus request/bus grant state machine (BREQ/BGNT SM) 206. Each of the state machines 202, 204, 206 is substantially identical in that each has four states S0, S1, S2, S3 as represented in Figure 4. State S0 is the idle state; state S1 is the acknowledge state following any request made (REQ0, REQ1, BREQ) during the idle state; state 2 is a data transfer state; and state 3 is the error state. When either or both data transfer channels are inactive (CH0 SM 202 and/or CH1 SM 204 are in the idle state S0) and the BREQ* signal is asserted, then the DB bus 100 is relinquished to the MPU 119 for one transfer period (e.g, BXFR 212 Figure 6). When any of the state machines 202, 204, 206 is in the idle state S0, assertion of a Request signal (REQ*) causes transition to state S1. When the state machine is in state S1, the DB DMA 106 is computing the address to be used by the DB MEM 108 as well as address parity for the next address. State S1 is the Acknowledge state, meaning that the state machine expects a certain sequence of signals following issuance of an acknowledgement to the requesting element. Specifically, continued assertion of a Request signal (REQ*) and transfer of data is expected following state S1; otherwise an error condition is indicated (state S3). The state machine transitions between state S1 and state S2 until all data transfer is complete and the Request signal is withdrawn (REQ* disasserted). When in state S1 REQ* is disasserted, the state machine transitions to the Error state S3. It remains in the "Error" state until assertion of the Reset signal. When the Reset* signal is asserted in the Error state, the state machine is restored to the Idle state S0. When the state S2 is invoked, data transfer takes place; hence its designation as the Data transfer state (DXFR). If the request signal (REQ*) remains disasserted, the state machine reverts to state S1. If no new Request signal is asserted before a Reset signal (RE­SET*) is asserted, the state machine returns to the Idle state S0. If however in state S2 the request signal REQ* is disasserted, the state machine also returns to the Idle state S0.

0031Each of the channels for data transfer (XFR0 and XFR1 of Figure 6 referring to CH0 and CH1, respectively) operate independently of one another but of course cannot, during the same bus cycle, transfer data between the same peripheral device through the SPC 44 and the same requesting port PPC-0 43-0 or PPC-1 43-1. Every normal data transfer is written to or read out of a memory location in the DB MEM 108 which has been designated by the memory address output (MADRS) 224 of the DB DMA (Figure 5).

0032Referring to Figure 5, there is shown a diagram of the architecture of the DB DMA 106. A key feature of the architecture is a fast adder or more specifically a two level Carry Look Ahead (CLA) adder which is capabIe of doing add and subtract operations for the channel address genera­tion in less than one clock period. The contents of channel 0 and channel 1 address registers 216 and 218 are provided as one input to the CLA adder 214 via an address multiplexer ADRS MUX 220. The augend address (ADRS AUGEND) 222 is provided as the other input to CLA adder 214, the output of which is the memory address (MADRS) in the DB MEM 108 to or from which the data on the DB bus 100 is written or read.

0033The DB DMA 108 is capable of chaining related data in a block for continuous transfer of priority data at the designated standard data transfer rate. This is a function which would normally be carried out by the MPU 119 (Figure 2) and would require that an interrupt cycle be repeated for each frame of data. However, the DB DMA 106 according to the invention is instead employed for this purpose. The result is a substantial increase in speed of selected data transfer operations of the device controller 41.

0034Referring to Figure 5, a Master Control register 260, a Channel 0 control register 262, and a Channel 1 control register 264 are coupled to receive input data via a register bus 266 from a data input/output port 268 and further to provide output to a the register bus 266 and the data input/output port 268 via a register multiplexer 270. Further as shown in Figure 5, and now referring to the mode of operation as well as the architecture, a Channel 0 chain pointer register CH0 CHAIN PTR REG 226 is coupled to Channel 0 address multiplexer 228 to the Channel 0 address register CH0 ADR REG 216, and Channel 1 chain pointer register CH1 CHAIN PTR REG 230 is coupled to Channel 1 address multiplexer 232 to the Channel 1 address register CH1 ADR REG 218. The chaining function is enabled by placement of a suitable command word in the channel control register 262. Once chaining has been enabled, the respective channel address registers 216 and 218 of the enabled channel are loaded from the corresponding channel chain pointer register 226 or 228, so that chained sequencing is started. Chained sequencing continues until chain parameters are fetched from memory; thereafter regular channel operation resumes. The ability to reprogram a channel of DB DMA 106 for chaining operations while supporting normal functions on other channels represents a departure from known technology in this field.

0035In order to check for completion of each transfer, a comparator 250 is provided for comparing the content of the active channel address register 216 or 218 via the address MUX 220 with the content of the corresponding end pointer register 254 or 256 via an end address multiplexer (END-ADRS-MUX) 258. The output of the comparator 250 is either an Equal or NOT Equal value, which is used to control data transfer.

0036Another feature of the invention is the use of address parity prediction to assure that the system is operating properly. More specifically, address parity of the next scheduled address is predicted and compared with actual parity to assure that data is actually being progres­sively transferred to and from the proper memory locations. To this end a conventional parity generator 270 is provided having as its input the output of the CLA adder 214, a parity predictor 272 having as its input the output of the channel address register 216 or 218 via the output of the address multiplexer 220 and as its other input selected control bits of the corresponding channel control register 262 and 264 via the multiplexer 270 through register bus 266. The outputs of the parity generator 270 and the parity predictor 272 are coupled to a comparator 274. The channel control register 262, 264 contains information regarding the type of transfer and the address increment for each channel. The channel address register 216, 218 contains the current address of each channel. The parity predictor 272 comprises means for combining the address increment and the current address to obtain a predicted parity. The output of the comparator 274 is thus an indication of whether the current parity and the parity predicted from the previous address. Inequality is an error condition.

0037Figure 7 is a block diagram of a specific embodi­ment of two peripheral port controllers (PPCs) 43-0 and 43-1 according to a specific embodiment of the invention. According to the invention there is associated with or incorporated into each PPC 43 an independently operated PPC latch 300 (PPC-0 has PPC latch 300-0 and PPC-1 has PPC latch 300-1). Each PPC latch 300 operates independently so that two I/O channels can have ownership set simultaneously. In a specific embodiment as shown in Figure 7, each PPC 43-0, 43-1 includes a port chip 302-0, 302-1 coupled to a data buffer 303-0, 303-1 whereby EIOs issued on the CIOs 39-0, 30-1 cause interrupts and set the PPC latches 300-0, 300-1. The port chips 302-0, 302-1 also provide limited data buffering between the CIOs 39-0, 39-1 and the DB bus 100. Each PPC 43 has the following registers for receiving EIOs and data buffering: Buffer_A: a data buffer Buffer_B: a data buffer Buffer_C: a data buffer RAC: register for storage of the Read Address and Command word of a reconnect sequence RIC: register for storage of the Read Interrupt Cause word of an interrupt sequence RIST: register for storage of the Read Interrupt STatus word of an interrupt sequence LAC: register for storage of the Load Address and Command word of an EIO sequence LPRM: register for storage of the Load PaRameter word of an EIO sequence Status: three registers providing access by the MPU 119 to status signals within the PPC Flag Control: register whereby the MPU 119 can set and clear various flags in the PPC Burst Length: register controlling the maximum number of word in a single reconnect burst (maximum 128).

0038The DB DMA 106 has direct access to the three Buffers A, B and C for both read access and write access. These buffers are word-wide registers configured in a bidirectional queue. These registers are clocked by the system clock (SYS_CLK) (associated with the host processors) during transfers in from the DB bus 100 to the CIO 39. During out transfers they are clocked by the CIO 39 channel handshake signal SVO (see the Katzman et al. patent for further explanation of the CIO 39). Two three-bit circular shift registers are used as pointers. The first pointer is clocked by SYS_CLK, and the shift is enabled by the DMA_ACK signal from DB DMA 106 (Figure 6). The second pointer is clocked by SVO, and shift is enabled by an IN or OUT TBUS command through the CIO 39. The two pointers keep track of the next register (Buffer A, B, or C) to be loaded with data or unloaded. A two-bit synchronous counter keeps track of the number of words in the buffers A, B, and C. The synchronous count is used to determine when the DMA_REQ* signal must be asserted, and it is available to the MPU 119 via the status registers.

0039In the idle state the PPC latches 300 do not assert a "Port Own" signal (PO_OWN* by PPC latch 300-0 and P1_OWN* by PPC latch 300-1). However, whenever the appro­priate EIO is received by the PPC chip 302, a "take owner­ship" interrupt signal is asserted (Takeown*) by the PPC chip 302 to the PPC latch 300 via signal line 304. Each PPC port 41 is properly identified via comparators 306 and appropriate switches 308. The addressed PPC latch 300 asserts port ownership (PO_OWN* and P1_OWN*) as interrupts to the MPU 119. It is thereafter the task of the MPU 119 to interpret the EIO, to designate which of the ports is to have which data channel of the DB bus 100 and to configure the DB DMA 108 to so allocate the two data channels CH0 and CH1 of the DB bus 100 to one or both of the designated ports. Because of dual ownership through the PPC latches 300 and dual channel operation of the DB DMA 106, the device controller can handle all of the protocols and data trans­fers to and from peripheral devices within a common time frame and as far as the CIO buses 39 are concerned, simulta­neously. Each PPC 43 is capable of essentially simultaneous operation. In simultaneous operation, a first PPC 43-0 can actively transfer data and commands while the second PPC 43-1 can also actively transfer information; however such transfer is limited to commands.

0040All of this is done without direct data transfer via the MPU 119, which represents a substantial departure from other device controllers known in this field, i.e., device controllers which can be reconfigured in accordance with the type of data transfer desired.

0041In the process of receiving an EIO, the DB DMA 106 must grant bus access to the MPU 119. To this end, the MPU 119 responds to the appropriate interrupt issued by the PPC 43 by issuing a BRQT signal to the DB DMA 106 via the bus switch 104.

0042Referring to Figure 11, there is shown one embodi­ment of the bus switch 104. The bus switch 104 comprises a three-state buffer 400, a delay means 402 and a latch 404. The output enable terminal of the three state buffer 400 is controlled from the DB DMA 106 (a clock line synchronized with the channel in use) through the delay means 402 whose function is to enable the three-state buffer 400 after sufficient time has elapsed following a prior transfer of data to minimize interference between consecutive data blocks from the MPU bus 102 to be transferred to the higher speed DB DMA bus 100. The delay means 402 typically pro­vides a 20 ns delay and therefore a 20 ns window between data transfers between data transfers operating on a 200 ns clock. The bus switch 104 further comprises a latch 404 which is coupled to receive data from the higher speed DB bus 100. It operates to latch the received data for use by the slower MPU bus 102. The latch 404 is also a three state device wherein the output enable terminal is under control of the MPU 119, since the MPU 119 decides when to read the contents of the latch 404. Significantly, operational control of the bus switch 104 resides in the DB DMA 106, and more particularly is part of the arbitration logic 200 and Bus Request/Bus Grant protocol of the BREQ/BGNT state machine 206 for communication with MPU 119 and any other element coupled to the MPU bus 102. (Most data transfer for example is via the memory 112 under control of the 68450 DMA 114.) Operation of the bus switch 104 in conjunction with the MPU 119 is illustrated by the following example.

0043The transfer of the EIO to the MPU 119 is from the PPC 43 through the bus switch 104 to the MPU 119. The PPC 43 issues an interrupt to the MPU 119 which in turn initi­ates a Bus Request to the DB DMA 106. The DB DMA 106 then issues a Bus Grant to the MPU 119. The MPU 119 then cap­tures the EIO from the PPC 43 via the DB bus 100 and the bus switch 104. The MPU 119 then interprets the command structure while the DB DMA 106 controls other data transfers on the DB bus 100. Once the MPU 119 has completed interpretation of the EIO it again requests a bus cycle of the DB bus to access the DB DMA 106 to instruct it regarding the port and form of data transfer. Once a Bus Grant is given the MPU 119 transfers instructions to the registers of the DB DMA 106 via the bus switch 104.

0044One of the significant advantages of the multiple-bus architecture of the invention wherein the synchronous buses are coupled by bus switches which comprises buffers and latches is that different speed devices can be interfaced very easily and even changed if necessary. For example, if it is desired to substitute a faster microprocessor chip in the position of MPU 119, it becomes the relatively trivial task of exchanging components and boosting MPU bus clock speed. The speed and operation of the DB bus 100 is not affected.

0045The MPU 119 accesses the SPC 44 via the SPC bus switch 122 and SPC bus 120 in order to configure the SPC 44 for the data transfer designated by the EIO and related vectors.

0046Referring to Figure 8, there is shown the SPC 44 in accordance with the invention. The SPC 44 is built around a SCSI Protocol Controller Chip (SPC Chip) 402 which in a specific embodiment may be a type MB87030 supplied by Fujitsu. The SPC Chip 44 is coupled indirectly to the DB bus 100 and directly to the SPC bus 120. Coupled between the DB bus 100 and the SPC chip 402 is a byte assembly register 404 on the DB bus 100, which assembles the data bytes for the SPC Chip 402 to be passed via lines 403, and a parity register 406 which creates odd parity for data in the byte assembly register 404 to provide compatibility with the parity expected by the SPC Chip 402.

0047The SPC bus switch 122 comprises a latch 410 and a buffer 412. It is coupled between the MPU bus 102 and the SPC bus 120 to provide bi-directional command and control coupling between the MPU bus 102 and the SPC bus 120. The SPC bus switch 122 is enabled by a signal on interrupt line 408 from the MPU 119 to latch 410 and buffer 412.

0048Since the SPC Chip 402 has only one SCSI port, provision must be made according to the invention to connect two SCSI buses 111-0 and 111-1. Therefore SPC Chip 4?2 provides a set of driver lines 414 and receiver lines 416 to a multiplexer set 418. In the illustrated embodiment, the multiplexer set 418 for the SPC Chip 402 itself comprises first and second sets of dual input open collector output NAND gates 420-0 and 420-1 which are functional as enablable drivers for SCSI bus 0 111-0 and SCSI bus 1 111-1, respec­tively, and corresponding first and second sets of inverters 420-0 and 420-1, which are functional as three-state receiv­ers for SCSI bus 0 111-0 and SCSI bus 1 111-1, respectively. In addition third and fourth inverter sets 424-0 and 424-1 are coupled as receivers from the respective SCSI buses 111-0 and 111-1 and supplied to SCSI interrupt logic means 426, which is coupled to the SPC bus 120 and which has interrupt line 428 which is coupled to the MPU 119. Still further, a bus select register 430 is provided on the SPC bus 120 which has as outputs an Enable Bus 0 line 432 and an Enable Bus 1 line 434. Enable Bus 0 line 432 is coupled to drivers 420-0 and receivers 422-0 associated with SCSI bus 0 111-0, and Enable Bus 1 line 434 is coupled to drivers 420-1 and receivers 422-1 associated with SCSI bus 1 111-1.

0049The SPC 41 can respond to programming commands from the MPU 119 via the SPC bus 102 directed to the SPC Chip 402, can pass data (read and write) to/from the DB bus 100 from/to either SCSI bus 111-0 or 111-1 as selected by a command from the MPU 119 via the bus select register means 432, or it can interrupt the MPU 119 via interrupt line 428 from the SCSI interrupt logic means responsive to signals from peripheral devices on either SCSI bus 111-0 or 111-1. Hence, the device controller 41 permits multiple access from multiple channels to multiple devices on selectable SCSI buses within the same operational cycle, during two or more overlapping commands.

0050To facilitate odd byte transfers on the DB bus 100 to/from the SPC Chip 402, the byte assembly register 404 can be read and written in word mode by the MPU 119 via the DB bus 100. This facilitates data transfer between an eight bit device (the SPC Chip 402) and a high speed sixteen bit bus (DB bus 100). Specifically, during IN mode transfers from the SPC Chip 402, the first byte to the DB bus 100 is stored in the most significant byte side of the byte assembly register 404 and when the second byte is ready, the first byte is passed from the byte assembly register 404 to the most significant byte side of the DB bus 100 while the least significant byte is passed via three state driver 405 to the least significant byte side of the DB bus 100. During OUT mode transfers to the SPC Chip 402, the least significant byte of the DB bus 100 is transferred to the least significant byte side of the byte assembly register 404 as the most significant byte of the DB bus 100 is transferred directly to the the SPC through three state driver 407. The next byte transferred to the SPC Chip 402 is the least significant byte from the byte assembly register 404.

0051The SCSI interrupt logic means 426 is a logic device which controls three conditions loosely referred to as interrupts from each of the two SCSI buses 111 thereby providing an interrupt on interrupt line 428 to the MPU 119 under six possible conditions. The conditions are: 1) SCSI Bus was Reset; 2) SCSI Bus was Free; 3) Device Controller is being Reselected on the SCSI bus. All six conditions are "OR"ed together so that any one of the conditions will cause the interrupt to issue via interrupt line 428 to the MPU 119.

0052The six conditions to cause the interrupt can be individually enabled, read and cleared from the MPU 119 by means of six lines to read/write/control port 429 coupled to registers within the SCSI interrupt logic means 426. In addition a master interrupt enable may be provided via a seventh line to read/write/control port 429. These inter­rupts monitor both of the SCSI buses 111 independently of the SPC Chip 402 and of the multiplexer 418 by means of receivers 424-0 and 424-1. Even if the interrupt line 428 is not enabled, the status of the interrupt registers can be polled by the MPU 119 via the SPC bus 120.

0053The MPU 119 is used for performing the programming of the SPC 44. More specifically, the MPU 119 sets up queues of instructions for the ports and for individual devices in memory MEM 112 which are communicated to the SPC 44 in order of request. The MPU 119 can be handling several tasks at the same time, such as a read of one device which requires a seek before data can be transferred. The MPU 119 can proceed to execute the instruction queue of another device task for another device while awaiting completion of the seek on the first device. In this manner, the process­ing power of the MPU 119 is used more efficiently.

0054Referring to Figure 9, there is shown a block diagram illustrating a specific embodiment of the software structure 900 according to the invention. The software structure 900 is divided into modules according to function, including supervision, device drivers and input/output tasks. The software structure 900 comprises a kernel 910 or operating system, a peripheral port control driver module (PPC driver) 912, a port task 914 logically coupled between the PPC driver and all other tasks, including but not necessarily limited to a task 916 and closely-related utilities, a tape task 918, packet communication (using X.25 protocol) (X.25) tasks 920, asynchronous communication (async) tasks 922, and remote maintenance interface (RMI) tasks 924.

0055The disk task 916 and the tape task 918 are logically couple to an SCSI peripheral control (SPC) driver 926. The X.25 tasks 920 are logically coupled to a serial communication control (SCC) driver 928. The async tasks 922 are logically coupled to an async driver 930. The RMI tasks are coupled to a maintenance-diagnostics bus (MDB) driver 932. As it is not necessary to an appreciation of the invention to understand the details of the specific drivers or tasks, only selected drivers or tasks are discussed hereinafter for illustration purposes. It is sufficient to one of ordinary skill in the art to know that remote mainte­nance is provided via the MDB driver which provides device control to a maintenance-diagnostics bus, that the SCC driver 928 controls a standard SCC chip such as a Zilog Z8030 serial communication chip supporting both X.25 bit-oriented packet protocol and X.21 byte-oriented packet protocol, and that the async driver 930 controls standard dual universal asynchronous receiver-transmitters (DUARTs) such as a Signetics 2861 chip.

0056The kernel 910 is a standard operating system available as a commercial product for the 68000 family of microprocessors. (The 68000 family is made by or under license from Motorola, Inc.) A specific example of a kernel 910 is the T8120 common kernel software module used with Tandem brand computer systems made by Tandem Computers, Inc., of Cupertino, California.

0057Referring to Figure 10, and using as an example a communications between one host processor (not shown, see Figure 1) via the PPC driver 912 and one associated port (not shown, see Figure 1) and a peripheral device (not shown, see Figure 1) on the SCSI bus (not shown, see Figure 1) accessible via the SPC driver 926 and associated hard­ware, the function of the drivers is to respond to hardware-generated interrupts (such as an interrupt associ­ated with an Execute Input Output command) (EIO) issued by a host processor (not shown see Figure 1) in order to engage a port task 914 to pass messages (including messages associ­ated with the EIO) to another task such as a disk task 916, instructing the other task 916 to carry out a desired action, such as to call a "read data" or "write data" subroutine, to communicate to the peripheral device (not shown) via a driver, such as the SPC driver 926. In re­sponse, when the read or write task is done, in the exempla­ry embodiment, the peripheral device (not shown) generates another hardware interrupt which is received and interpreted at the SPC driver 926 to generate a signal indicating that the command has been completed. The signal CMD COMPLETE or its equivalent is communicated to the disk task 916, which in turn conveys a message to the port task to issue a reconnect or an interrupt. The port task then makes a subroutine call to the PPC driver 912 to issue the reconnect or the interrupt to the host processor.

0058Thus, communication between the host processor and the device controller is by means of an EIO addressed to a peripheral device under control of a device controller, and the device controller responds to the host processor by a reconnect burst or an interrupt.

0059The port task 914 and related software have the following characteristics of interest:

0060The port task 914 sends the EIO Request message it receives to the device task 916 based on the controller address. If the host processor 33 issues multiple EIOs to the same controller address, the port task 914 will send multiple messages to the same device task.

0061The port task 914 does not associate EIOs with reconnects or interrupts. All decisions to reconnect and interrupt are made by the device tasks.

0062The port task 914 does not have the concept of ownership. If an ownership concept is necessary, it is provided by the host processor. As far as the device controller itself, the device controller can be owned by both channels simultaneously. Thus all EIOs having the same controller address from either channel are directed to the same device task.

0063The port task 914 receives the address of each data block from the device tasks and then breaks the data block into bursts to be sent or receive. If the address of the data block is in the memory MEM 112, it will move the data between MEM 112 and DB MEM 108 by using one of two reserved 256 data buffers in the DB MEM 108, moving data into one buffer while reconnecting to the host processor via the PPC on the other buffer.

0064The port task 914 times the reconnect and inter­rupt requests. If the PPC 43 does not complete in time, the port task 914 resets the PPC 43 and returns to the the device task with an error status.

0065Events such as Takeown EIO, Kill EIO and Channel Reset are reported as status to Reconnect, Interrupt and Read_Status and are not sent as messages or broadcast to the device tasks. Channel Reset causes the device controller 41 to reset to its idle state. Takeown EIO requires no action but indicates that a transfer has been aborted.

0066The port usage operates within the following constraints:

0067EIOs will be accepted from either port at all times.

0068A host processor interrupt will be issued only when a port is not in the reconnect condition.

0069Data for the main memory of the host processor is sent or received subject to availability of memory space in the DMA data buffer (DMA DB MEM 108).

0070An exemplary listing of device tasks and drivers used in accordance with the invention is provided in Appen­dix A accompanying this application. However, the operation of the invention would be clear to one of ordinary skill in this art from the foregoing description.

0071The invention has been explained with reference to specific embodiments. Other embodiments will be apparent to those of ordinary skill in this art in light of this disclo­sure. It is therefore not intended that this invention be limited except as indicated by the appended claims.