Multiprocessor interrupt controller with remote reading of interrupt control registers

Description Submit all comments and votes

FIELD OF THE INVENTION

This invention relates to the management of interrupt request messages in a multiprocessor system.

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.

Multiprocessor systems, often a set of networked computers having common peripheral devices, create a challenge in the design of interrupt control methods. For instance, 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 pre selected (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 (PICs), 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: Control Logic 20 coordinates the overall operations of the other internal blocks within the same PIC, activates the host input interrupt (INT) line 21 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 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;

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

3) static as well as dynamic multiprocessor interrupt management;

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

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

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

7) 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.

Also, a clustered hierarchical interrupt control system comprising multiple MPIC systems interconnected by a cluster manager is disclosed for use when the basic MPIC capacity for interrupt message sources and destinations is exceeded.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention may be understood more fully from the derailed 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 use of a Cluster Manager for interconnecting up to 15 MPIC systems.

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

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

FIG. 13 shows the IAU Local Vector Table bit assignment layout.

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

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

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

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

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

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

FIG. 20 shows the IAU Remote Register.

FIG. 21 shows the IAU Version Register bit assignment.

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

FIG. 23 shows the short message format.

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

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

FIG. 26 shows the Remote Read message format.

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

FIG. 28 shows the Divide Configuration Register bit assignment.

FIG. 29 shows the IAU Times Vector Table format.

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 an 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 processors. This implies the ability to broadcast interrupt service requests to the pertinent group of processors 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 DU 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 IAU, and arbitration procedure is invoked between competing units. The IAU 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 Send/Receive Unit 202 for sending and receiving interrupt control related messages from Interrupt Bus 115. The Redirection Table has a Destination (DEST) mode, and a 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 4bit 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. Successfully transmitted 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<n<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 the message has been accepted by the destination(s) specified in the destination field. Only then will the source IDU be able to recognize a new edge on that interrupt input pin. That new edge will only result in a new invocation of the handler if its acceptance by the destination IAU causes an Interrupt Request Register (IRR) bit to go from zero to 1. (In other words, if the interrupt wasn't already pending at the destination.)

The minimum number of entries in the Redirection Table in the IDU implementation should be 16. The I/O Version Register contains the number of entries in that IDU's redirection table. The layout of an entry in the Redirection Table 201 is as shown in FIG. 7.

Each redirection table entry is a 64-bit string defined as follows:

VECTOR[0:7]: The Vector field is an 8-bit field containing the interrupt vector for this interrupt. Vector values range between 10 and FE (hex).

DELIVERY MODE[8:10]: The Delivery Mode is a 3-bit field that: specifies how the IAUs listed in the destination field should act upon reception of this signal. Note that certain Delivery Modes will only operate as intended when used in conjunction with a specific Trigger Mode. These restrictions are indicated in the table below for each Delivery Mode.

000 (Fixed): means deliver the signal to the INTR (maskable interrupt) input of all processor cores listed in the destination. Trigger Mode for "fixed" Delivery Mode can be edge or level.

001 (Lowest Priority): means deliver the signal to the INTR input of the processor core that is executing at the lowest priority among all the processors listed in the specified destination. Trigger Mode for "lowest priority" Delivery Mode can be edge or level.

010 (SMI): means System Management Interrupt. A delivery mode equal to "SMI" requires an "edge" Trigger Mode. The Vector information is ignored but should be programmed to all zeroes.

100 (NMI): means deliver the signal to the NMI (nonmaskable interrupt) input of all processor cores listed in the destination, vector information is ignored. "NMI" is treated as an "edge" triggered interrupt even if it is programme