Multiprocessor programmable interrupt controller system adapted to functional redundancy checking processor systems

What is claimed is:

1. A multiprocessor programmable interrupt controller system for operation in a multiprocessor system having a common system bus, at least one I/O peripheral subsystem with a set of interrupt request signal lines, and at least two processor units, one processor unit being a functional redundancy checking (FRC) unit having a master processor and a checker processor operating with common core and CPU bus clocks, the multiprocessor programmable interrupt controller system comprising:

a) an interrupt bus synchronizing clock signal with a rate that is less than one half the common core clock rate;

b) a synchronous interrupt bus for transmitting the interrupt bus synchronizing clock signal, for interrupt request data communication, and for arbitration messages for control of the interrupt bus;

c) an interrupt delivery unit (IDU) connected to the interrupt bus comprising:

i) a set of interrupt request signal input pins for accepting interrupt request signals from a set of I/O peripheral interrupt request lines, an interrupt request signal indicated by activating a corresponding input pin,

ii) a redirection table, coupled to the interrupt request signal input lines, for selecting an interrupt request message corresponding to the active input lines, the interrupt request message comprising an interrupt vector containing interrupt priority level, servicing mode, and processor selection information,

iii) means, coupled to the redirection table and to the interrupt bus, for broadcasting the redirection table interrupt message on the interrupt bus, and

iv) means, coupled to the interrupt bus, for arbitrating for control of the interrupt bus; and

d) an interrupt acceptance unit (IAU) connected to the interrupt bus and to an associated processor unit comprising:

i) means for receiving interrupt request messages that have been broadcast on the interrupt bus,

ii) means for accepting interrupt requests for which the associated processor is eligible to service,

iii) means for pending accepted interrupt request messages until the associated processor is available to service the interrupt request,

iv) means for broadcasting interrupt request messages from its associated processor unit on the interrupt bus,

v) means for arbitrating control of the interrupt bus connected to the interrupt bus,

vi) means for lowest priority mode arbitration on the interrupt bus between IAUs eligible to service a given interrupt request, wherein an IAU associated with an eligible processor operating on a task of lowest priority relative to all other eligible processors is selected to service the given interrupt request, and

vii) means for synchronizing IAU-accepted interrupt request messages with the associated processor core clock.

2. The controller of claim 1 wherein the synchronous interrupt bus comprises three wires, one wire for transmitting the interrupt bus synchronizing clock signal, a first and second data wire for interrupt request communication, the first data wire also used for single-wire arbitration messages.

3. The controller system of claim 2 wherein the IDU means and the IAU means for interrupt bus arbitration are each logically-OR connected to the interrupt bus for arbitration of the control of the interrupt bus, each IAU and IDU having a preassigned unique, fixed length, binary coded arbitration identification number assigned from a set of N integers, where N is the total number of IDUs and IAUs, hereinafter referred to as agents, the agents using a method of arbitration comprising the following steps:

a) each agent desiring control of the interrupt bus at a given instant of time arbitrates, by serially driving the first data wire with its arbitration identification number, one bit per bus cycle in descending order of bit significance;

b) each agent of step (a) monitoring the first data wire during each interrupt bus cycle of the arbitration procedure so that, if the first data wire is in a logically asserted state in any given arbitration cycle when its corresponding bit of its arbitration identification is not logically asserted, a non-asserting agent loses and drops out of the arbitration; and

c) repeating steps (a) and (b) until all bits of the arbitration identification number have been exhausted so that an agent remaining after the last bit is applied wins the arbitration and control of the interrupt bus.

4. The controller system of claim 3 wherein the arbitration is followed by a procedure for adjusting the arbitration identification numbers of each agent in order to distribute assignment of interrupt request assignment amongst all eligible processors, the adjusting procedure comprising the following steps:

a) the winning agent is assigned an arbitration identification number of zero;

b) incrementing by one the arbitration identification number of all other agents except the agent with arbitration identification number N-1; and

c) assigning the arbitration identification of the winning agent to the agent with arbitration identification of N-1.

5. The controller system of claim 3 wherein the agents are electrically open-drain connected to the interrupt bus for reduced loading on the interrupt bus when not driven by an agent.

6. The controller system of claim 2 wherein the means for lowest priority mode arbitration for finding an eligible processor with the current lowest priority task further comprises means for:

a) assigning to each IAU a lowest priority task number corresponding to each IAU associated processor a current processor task priority;

b) forming a logical complement of each lowest priority task number;

c) each eligible IAU sequentially driving the first data wire with its complemented lowest priority task number beginning with its most significant bit in descending bit order, one bit at a time for each interrupt bus clock cycle;

d) each eligible IAU monitoring the first data wire for each interrupt bus clock cycle so that, if the first data wire is logically asserted when a given IAUs corresponding bit is not asserted, the given IAU drops out of the lowest priority mode arbitration and all other eligible processors continue arbitration; and

e) repeating steps (c) and (d) until all bits of the complemented lowest priority task number has been used and a single IAU remains, the remaining IAU being the lowest priority mode arbitration winner.

7. The controller system of claim 6 further comprising means for appending to each IAU lowest priority task number, each IAU's arbitration identification number as a field of lower order bits for the purpose of selecting a lowest priority mode winner when more than one eligible processor's task is of equal lowest priority.

8. The controller system of claim 1 wherein the IAU further comprises remote read means for an IAU to request reading the contents of a register with a preassigned address in a target IAU, each IAU having a preassigned binary coded identification number, each of the remote read means comprising means for:

a) selecting a physical destination mode of interrupt bus message delivery;

b) specifying the target IAU identification number as the address of the destination;

c) placing a number corresponding to the address of the register whose contents are to be read and causing the target IAU to place the contents of the addressed register on the interrupt bus; and

d) reading of the register contents on the interrupt bus by the IAU requesting the remote IAU register read.

9. The controller system of claim 1 wherein the IAU is associated with the master CPU and further comprises a second IAU associated with, and coupled to, the checker CPU for bidirectional transfer of interrupt-related messages, and unidirectionally coupled to the interrupt bus solely for receiving messages broadcast on the interrupt bus.

10. The controller system of claim 1 further comprising a clock generator coupled to the FRC unit, for generating FRC CPU bus and core clock signals, each FRC CPU bus and clock signals being an integer harmonic of the interrupt bus synchronizing clock signal.

11. The controller system of claim 10 wherein the clock generator further comprises means for generating an interrupt bus synchronizing clock signal, coupled to the interrupt bus for transmitting the interrupt bus synchronizing clock signal.

12. The controller system of claim 1 wherein the IAU synchronizing means comprises means for synchronizing IAU-accepted interrupted request messages with the associated processor CPU bus clock.

13. The controller system of claim 1 wherein the IAU synchronizing means comprises a first stage synchronizer and second stage synchronizer, the first stage synchronizer for synchronizing IAU-accepted interrupt request messages with the associated processor CPU bus clock, and the second stage synchronizer for synchronizing the first stage synchronizer output with the associated processor core clock.

14. The controller system of claim 13 wherein the second stage synchronizing means further comprises:

a) gate means for gating the fast stage synchronizing means output; and

b) a state machine for generating a gate control signal for controlling the gate means output on and off, turning the gate output on for a prescribed interval whenever the first stage synchronizer output transitions from low to high and a low to high transition of the associated core clock occurs within a core clock period interval of the first stage synchronizer output low to high transition.

15. The controller system of claim 14 wherein the prescribed gate on interval is at least one core clock period.

Description Submit all comments and votes

FIELD OF THE INVENTION

This invention relates to the management of interrupt request messages in a multiprocessor system that incorporates at least one functional redundancy checking processor unit.

BACKGROUND OF THE INVENTION

Input/output peripheral equipment, including such computer items as printers, scanners, and display devices, require intermittent servicing by a host processor in order to ensure proper functioning. Services, for example, may include data delivery, data capture, and/or control signals. Each peripheral will typically have a different servicing schedule that is not only dependent on the type of device but also on its programmed usage. The host processor is required to multiplex its servicing activity amongst these devices in accordance with their individual needs while running one or more background programs. Two methods for advising the host of a service need have been used: polled device and device interrupt methods. In the former method, each peripheral device is periodically checked to see if a flag has been set indicating a service request, while, in the latter method, the device service request is routed to an interrupt controller that can interrupt the host, forcing a branch from its current program to a special interrupt service routine. The interrupt method is advantageous because the host does not have to devote unnecessary clock cycles for polling. It is this latter method that the present invention addresses. The specific problem addressed by the current invention is the management of interrupts in a multiprocessor system environment that includes at least one functional redundancy checking (FRC) unit.

FRC units present a unique synchronization problem because each FRC unit has two processor (CPUs): a master CPU and a checker CPU. The checker CPU tracks the master CPU following the same program instruction and receiving the same data. The checker CPU does not drive data on any system bus but monitors what the master CPU drives and compares what is driven with what it would have driven had it been the master CPU. Any discrepancy creates a system error. Because interrupts are asynchronous to the CPU clocks, there is the possibility that the master and checker CPUs recognize an interrupt in different clock cycles and consequently, but erroneously, declare a system error.

In the case of a computer network servicing a number of users, it would be highly desirable to distribute the interrupt handling load in some optimum fashion. Processors that are processing high priority jobs should be relieved of this obligation when processors with lower priority jobs are available. Processors operating at the lowest priority should be uniformly burdened by the interrupt servicing requests. Also, special circumstances may require that a particular I/O device be serviced exclusively by a preselected (or focus) processor. Thus, the current invention addresses the problem of optimum dynamic and static interrupt servicing in multiprocessor systems.

Prior art, exemplified by Intel's 82C59A and 82380 programmable interrupt controllers (PlCs), are designed to accept a number of external interrupt request inputs. The essential structure of such controllers, shown in FIG. 1, consists of six major blocks:

IRR: Interrupt Request Register 11 stores all interrupt levels (IRQx) on lines 16 requesting service;

ISR: Interrupt Service Register 12 stores all interrupt levels which are being serviced, status being updated upon receipt of an end-of-interrupt (EOI);

IMR: Interrupt Mask Register 13 stores the bits indicating which IRQ lines 16 are to be masked or disabled by operating on IRR11;

VR: Vector Registers 19, a set of registers, one for each IRQ line 16, stores the preprogrammed interrupt vector number supplied to the host processor on data bus 17, containing all the necessary information for the host to service the request;

PR: Priority Resolver 15, a logic block that determines the priority of the bits set in IRR11, the highest priority is selected and strobed into the corresponding bit of ISR12 during an interrupt acknowledge cycle (INTA) from the host processor,

Control Logic: Coordinates the overall operations of the other internal blocks within the same PIC, activates the host input internapt (INT) line 19 when one or more bits of IRR11 are active, enables VR19 to drive the interrupt vector onto data bus 17 during an INTA cycle, and inhibits all interrupts with priority equal or lower than that being currently serviced.

Several different methods have been used to assign priority to the various IRQ lines 16, including:

1) fully nested mode,

2) automatic rotation--equal priority devices, made and

3) specific rotation--specific priority mode.

The fully nested mode, supports a multilevel interrupt structure in which all of the IRQ input lines 16 are arranged from highest to lowest priority: typically IRQ0 is assigned the highest priority, while IRQ7 is the lowest.

Automatic rotation of priorities when the interrupting devices are of equal priority is accomplished by rotating (circular shifting) the assigned priorities so that the most recently served IRQ line is assigned the lowest priority. In this way, accessibility to interrupt service tends to be statistically leveled for each of the competing devices.

The specific rotation method gives the user versatility by allowing the user to select which IRQ line is to receive the lowest priority, all other IRQ lines are then assigned sequentially (circularly) higher priorities.

From the foregoing description, it may be seen that PIC structures of the type described accommodate uniprocessor systems with multiple peripheral devices but do not accommodate multiprocessor systems with multiple shared peripheral devices to which the present invention is addressed.

SUMMARY OF THE INVENTION

It is the object of the current invention to provide a multiprocessor programmable interrupt controller (MPIC) system including, but not limited to, the following capabilities:

1) a means for properly synchronizing interrupt requests to FRC units;

2) a separate Interrupt Bus, distinct from the memory (or system) bus, for communication of interrupt request (IRQ) and IRQ receipt acknowledgment signals, and for IRQ service arbitration between eligible servers;

3) interrupt servicing of multiple I/O peripheral subsystems, each with its own set of interrupt lines;

4) static as well as dynamic multiprocessor interrupt management;

5) programmable interrupt vector and steering information for each IRQ pin;

6) interprocessor interrupts allowing any processor to interrupt any other for dynamic reallocation of interrupt tasks;

7) operating system defined programmable reallocation of interrupt tasks; and

8) support of system-wide functions related to nonmaskable interrupt (NMIs), processor reset, and system debugging.

The present invention achieves these capabilities by means of a MPIC system structure that includes three major subsystem components:

1) an Interrupt Bus, separate and distinct from the memory (system) bus;

2) an I/O Interrupt Delivery Unit (IDU) connected to the Interrupt Bus and to a set of IRQ pins, having a Redirection Table for processor selection and interrupt priority and vector information; and

3) a processor associated Interrupt Acceptance Unit (IAU) connected to the Interrupt Bus for managing interrupt requests for a specific system processor including acceptance acknowledgment, IRQ pending, nesting and masking operations, and interprocessor interrupt management.

More specifically, the present invention uses a three-wire synchronous bus, two wires for data, one wire for the clock, and one of the two data wires for bus and lowest priority arbitration.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention may be understood more fully from the detailed description given below and from the accompanying drawings of the preferred embodiments of the invention which, however, should not be taken to limit the invention to the specific embodiment but are for explanation and understanding only.

FIG. 1 depicts a block diagram of a common prior art uniprocessor programmable interrupt controller.

FIG. 2 is a block diagram of the preferred Multiprocessor Programmable Interrupt Controller (MPIC) system.

FIG. 3 shows the architecture of an Interrupt Delivery Unit (IDU).

FIG. 4 shows the I/O Select Register bit assignment.

FIG. 5 shows the I/O ID Register bit assignment.

FIG. 6 shows the I/O Version Register bit assignment.

FIG. 7 shows the Redirection Table Entry bit assignment layout.

FIG. 8 shows the architecture of an Interrupt Acceptance Unit (IAU).

FIG. 9 shows the IAU ID Register bit assignment.

FIG. 10 shows the IAU Destination Format Register bit assignment.

FIG. 11 shows the IAU Logical Destination Register bit assignment.

FIG. 12 shows the IAU Logical Vector Table bit assignment layout.

FIG. 13 shows the IAU Interrupt Command Register bit assignment layout.

FIG. 14 shows the IRR, ISR, and TMR bit assignment.

FIG. 15 is a flow diagram of the IAU interrupt acceptance process.

FIG. 16 shows the IAU Task Priority Register bit assignment.

FIG. 17 shows the IAU Spurious Interrupt Vector Register bit assignment.

FIG. 18 shows the IAU End-of-Interrupt register bit assignment.

FIG. 19 shows the IAU Remote Register.

FIG. 20 shows the IAU Version Register bit assignment.

FIG. 21 shows the EOI priority message format for level-triggered interrupts.

FIG. 22 shows the short message format.

FIG. 23 shows the IAU Interrupt Bus Status cycles decoding.

FIG. 24 shows the lowest priority without focus processor message format.

FIG. 25 shows the Remote Read message format.

FIG. 26 shows the IAU Error Status Register bit assignment.

FIG. 27 shows the Divide Configuration Register bit assignment.

FIG. 28 shows the IAU Times Vector Table format.

FIG. 29 is a block diagram of an IAU I-BUS-CLK to CPU-BUS-CLK synchronizer.

FIG. 30 shows the FRC synchronizer waveforms of master and checker CPUs.

FIG. 31 shows a an MPIC system that includes FRC unit and the means for synchronizing an interrupt to the FRC unit.

FIG. 32 shows the relationship between an FRC CPU clock signal and the interrupt bus clock signal.

FIG. 33 shows a clock generator suitable for an MPIC system with multiple FRC units operating at different clock rates.

FIG. 34 shows an alternative FRC implementation in an MPIC system.

FIG. 35 shows synchronizing apparatus when CPU-BUS-CLK and I-BUS-CLK are not harmonically related.

FIG. 36 shows waveforms resulting when CPU-BUS-CLK and I-BUS-CLK are not harmonically related.

FIG. 37 shows an external clock generator circuit.

FIG. 38 is a phase-locked-loop for generating a CPU-CORE-CLK that is a harmonic of CPU-BUS-CLK.

FIG. 39 shows an FRC synchronizer wherein the CPU-BUS-CLK and CPU-CORE-CLK rates are related by a proper fraction N/M.

FIG. 40 shows a two-stage synchronizing apparatus with CPU-BUS CLK signal conditioning and CPU-CORE-CLK derived from CPU-BUS CLK.

FIG. 41 is an example of waveforms in a two-stage synchronizer when CPU-CORE-CLK and CPU-BUS-CLK rates are ,related by a proper fraction.

FIG. 42 is another example of two-stage synchronizer waveforms when the CPU-BUS-CLK and CPU-CORE-CLOCK rates are related by a proper fraction.

FIG. 43 is still another example of two-stage synchronizer waveforms when the CPU-BUS-CLK and CPU-CORE-CLK rates are related by a proper fraction.

DESCRIPTION OF THE PREFERRED EMBODIMENT(S)

A Multiprocessor Programmable Interrupt Controller (MPIC) is described. In the following description, numerous specific details are set forth, in order to provide a thorough understanding of the preferred embodiment of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced without these specific details. Also, well-known circuits have not been shown in detail, or have been shown in block diagram form, in order to avoid unnecessarily obscuring the present invention.

Additionally, in describing the present invention, reference is made to signal names peculiar to the currently preferred embodiment. Reference to these specific names should not be construed as a limitation on the spirit or scope of the present invention.

A. Overview of the Architecture

The Multiprocessor Programmable Interrupt Controller (MPIC) system is designed to accommodate interrupt servicing in a multiprocessor environment. Current practice is mainly concerned with uniprocessor systems in which the interrupt of a number of peripheral units are serviced by a single processor aided by a programmable interrupt controller (PIC). In a multiprocessor, it is often desirable to share the burden of interrupt servicing among the group of similar processes. This implies the ability to broadcast interrupt service requests to the pertinent group of processes and a mechanism for determining the equitable assignment of the tasks amongst the processors. The uniprocessor design problem is significantly simpler: the PIC dedicated to the processor assigns a priority to each interrupt request (IRQ) line, orders the request according to the assigned priorities and delivers the necessary information to the processor to timely initiate the appropriate servicing subroutine.

The MPIC system provides both static and dynamic interrupt task assignment to the various processors. When operating in a purely static mode, it functions much as a PIC in a uniprocessor system assigning each interrupt according to a prescribed schedule.

When operating in a dynamic mode, the MPIC manages interrupt task assignments by taking into consideration the relative task priority between the processors.

It is expected that more typical usage would entail elements of both static and dynamic interrupt management. Static assignment might be made, for example, when licensing considerations preclude the shared use of servicing software. Under other circumstances, it may be desirable to restrict the interrupt servicing task to a subset of processors that share a common peripheral subsystem. In the extreme case, all processors are subject to interrupt requests from all peripheral subsystems.

FIG. 2 is a block diagram of the preferred MPIC system 100. It consists of four major parts: a Memory (or System) Bus 110; an Interrupt Bus 115 which is distinct from Memory Bus 110; a multiplicity of processor units (CPUs) 112 interfaced to Memory Bus 110 by Memory Bus Interface (MBI/F) 117 and to Interrupt Bus 115 by Interrupt Acceptance Units (IAUs) 114; and at least one I/O Subsystem 116 interfaced to Memory Bus 110 by Memory Bus Interface (MBI/F) 118 and to Interrupt Bus 115 by Interrupt Delivery Unit (IDU) 113.

I/O subsystem 116 may be a single device with multiple interrupt request (IRQ) lines connecting to IDU 113 or a collection of devices, each with one or more IRQ lines 119. In the preferred embodiment, each IDU 113 may accommodate up to 16 IRQ input lines. Consequently, MBI/F 118 may be a single or multiple interface unit for coupling I/O Subsystems 116 to Memory Bus 110.

In the preferred embodiment, IAU 114 is resident on the CPU 112 chip for more efficient signal coupling. Also, MBI/F 117 may be unnecessary if the CPU Bus 120 protocol is compatible with that of Memory Bus 110.

It is important to recognize that the architecture of FIG. 2 provides Interrupt Bus 115 for routing of interrupt-related control messages between system elements, thus reducing the traffic that must be carried by Memory Bus 110. Memory Bus 110 is only used for the actual servicing of the IRQ and is not required for IRQ arbitration, assignment, and acceptance acknowledgment.

Each IDU accepts up to 16 IRQs on input lines 119 and broadcasts to all IAUs 114 over Interrupt Bus 115 an appropriately formatted IRQ message for each active IRQ input line. The IRQ message contains all necessary information for identifying the IRQ source and its priority.

Each IAU 114 examines the broadcast message and decides whether to accept it. If the IRQ message is tentatively accepted by more than one EAU, and arbitration procedure is invoked between competing units. The EAU with the lowest priority wins the arbitration and accepts the IRQ, pending delivery to its associated CPU. Also, IAU 114 provides nesting and masking of interrupts and handles all interactions with its local processor including the CPU protocol for interrupt request (INTR), interrupt acknowledge (INTA), and end of interrupt (EOI).

IAU 114 not only accepts IRQs broadcast on Interrupt Bus 114 but can generate interprocessor interrupts. It further provides a timer to its associated CPU.

B. Interrupt Control

The interrupt control function of all IDUs 113 and IAUs 114 is collectively responsible for delivering interrupts from interrupt sources to interrupt destinations in the multiprocessor system. An interrupt is an event that indicates that a certain condition somewhere in the system requires the attention of one or more processors in order to deal with this condition. The action taken by a processor in response to an interrupt is referred to as servicing the interrupt or handling the interrupt.

Each interrupt in the system has an identity that distinguishes the interrupt from other interrupts in the system. This identity is commonly referred to as the vector of the interrupt. The vector allows the processor to find the right handler for the interrupt. When a processor accepts an interrupt, it uses the vector to locate the entry point of the handler in its interrupt table. The architecture supports 240 distinct vectors with values in the range 16 to 255.

Each interrupt has an interrupt priority that determines the timeliness with which the interrupt should be serviced relative to the other activities of the processors. The architecture allows for 16 possible interrupt priorities: zero being the lowest priority and 15 being the highest. A value of 15 in Task Priority Register (TPR) will mask off all interrupts which require interrupt vectors. Priority of interrupt A "is higher than" the priority of interrupt B if servicing A is more urgent than servicing B. An interrupt's priority is implied by its vector; namely, priority=Vector/16.

Sixteen different interrupt vectors can share a single interrupt priority.

Because each IAU 114 can only keep pending two interrupts in a given priority class, it is preferred that the number of interrupts in a class be limited to two when only a single CPU is operating. However, for a multiprocessor processor operation with a number, N, of CPUs functioning, the preferred number of pended interrupts per class is N/2.

Typically, a priority model would organize the interrupt priorities from high (15) to low (0) as follows:

______________________________________ Type of Interrupt Priority Class 1 Class 2 ______________________________________ 15 System Event System Event 14 Interprocessor Interprocessor 13 Local CPU Local CPU 12 Timer Timer 11-2 I/O I/O 1 Application Procedure Call Delayed Procedure Call 0 Reserved Reserved ______________________________________

Thus, system events requiring urgent attention, such as power failure, etc.) have the highest priority, followed by interprocessor (CPU) interrupts, local CPU related interrupts, IAU timer interrupts, I/O interrupts, and procedure call related interrupts. In this example, priority 0 is not used.

IRQs are generated by a number of sources within the multiprocessor system including: external (I/O) devices, local (to CPU) devices, IAU 114 timers, and CPUs. IRQs from I/O or devices local to a CPU may activate their Interrupt Lines 119 by using either signal edge transitions or signal levels. IAU timers generate an on-chip internal interrupt. A CPU may interrupt another CPU or sets of CPUs in support of software self-interrupts, preemptive scheduling, Table Look-aside Buffer (TLB) flushing, and interrupt forwarding. A processor generates interrupts by writing to the Interrupt Command Register (ICR) in its local IAU.

C. IDU Structure

IDU 113, shown in FIG. 3, consists of a set of IRQ pins for accepting I/O Interrupt Lines 119, an Interrupt Redirection Table 201, and a Message Unit 202 for sending and receiving interrupt control related messages from Interrupt Bus 115. The Redirection Table has a Destination (DEST) mode, and vector entry for each of the 16 I/O interrupt lines. Activating an Interrupt Line selects the corresponding table entry and delivers it to Send/Receive Unit 202 for formatting an appropriate IRQ message for broadcast on Interrupt Bus 115. The contents of Redirection Table 201 is under software control. Each table entry register is 64 bits wide. All registers are accessed using 32-bit reads and stores. Each IDU 113 is located at a unique address.

In addition, each IDU 113 has five 32-bit I/O Registers (203-207).

Select Register 204 selects which I/O register's contents is to appear in Window Register 203 by a software write to the lower 8 bits (bits 0-7), as shown in FIG. 4. This permits software manipulation of the contents of the other four I/O Registers.

Window Register 203 is mapped onto the register selected by Select Register 204.

ID Register 205 contains the IDU 4-bit identification code which serves as the physical name of the IDU. Each IDU is assigned a unique name (ID). The bit assignment is shown in FIG. 5. At power-up, it is reset to zero. Its contents must be supplied by software before use.

Arbitration Register 206 contains the bus arbitration priority for the IDU. Its initial contents are derived from the ID in ID Register 205. A rotating priority scheme is used for Interrupt Bus arbitration wherein the winner of the arbitration becomes the lowest priority agent and assumes an arbitration ID of zero. All other bus agents, except the agent whose arbitration ID is 15, increment their ID by one. The agent with ID=15 takes the winner's ID and increments it by one. Arbitration IDs are adjusted only for messages that are transmitted successfully. "Transmitted successfully" means no CS error or acceptance error was reported for that message. Arbitration Register 206 is loaded with contents of ID Register 205 during a level-triggered INIT with deassert message.

Version Register 207 identifies implementation versions of the IDU. The register bit map of FIG. 6 shows that bits 0-7 are assigned to the version number and are hardwired, read-only. Bits 16-23 represent the maximum assigned vector index value, n.sub.max, of redirection table 201. Each IDU can accept up to 16 interrupt lines, and each MPIC system can accommodate 240 interrupt vectors (0.ltoreq.n.ltoreq.239) so that, for a full capacity system with 15 IDUs, n.sub.max =15, 31, 47, 63, . . . , 224, 239 with one n.sub.max assigned to each IDU's Version Register 207.

The Redirection Table 201 has a dedicated entry for each interrupt input pin. The notion of interrupt priority is completely unrelated to the position of the physical interrupt input pin on the IDU. Instead, software can decide for each pin individually what it wants the vector (and therefore the priority) of the corresponding interrupt to be. For each individual pin, the operating system can also specify the signal polarity (low active or high active), whether the interrupt is signaled as edges or levels, as well as the destination and delivery mode of the interrupt. The information in the Redirection Table is used to translate the interrupt manifestation on the corresponding interrupt pin into a MPIC system message.

In order for a signal on edge-sensitive Interrupt Input Lines 119 to be recognized as a valid edge (and not a glitch), the input level on the pin must remain asserted until IDU 113 broadcasts the corresponding message over the Interrupt Bus and th