The Dragon processor interrupt mechanism is provided by the IFU Reschedule line. When this line is asserted, the processor takes an interrupt through some fixed location. This mechanism alone is sufficient to implement interrupts in a multiple processor system (for example by tying the Reschedule lines of all processors together and asserting this line whenever any interrupt happens), but it suffers from two drawbacks. First, it is not selective in that it always interrupts all processors; typically there is no reason to do this, and in fact doing this can be detrimental because it tends to put processors in lock step. Second, it requires devices generating interrupts to be smart in that they have to write the reason for the interrupt into shared memory so the interrupted processors can determine who generated the interrupt and take appropriate action.

These problems can be overcome by providing a more flexible way to communicate interrupts from their source to the Reschedule lines of various processors. The mechanism described here uses the DynaBus for this communication. Each small cache provides I/O registers that respond to certain IOWrite and BIOWrite transactions on the DynaBus (see the DynaBus specification [1] and implementation guidelines [2]) by asserting the Reschedule line for that cache's processor. Since there is a level of interpretation between the DynaBus transaction and the pulling of the Reschedule line, it is easy to provide the facility for handling multiple interrupt sources and the ability to handle directed and broadcast interrupts. Each interrupt source initiates a DynaBus transaction for each interrupt event. In the June 87 machine, there are (at least) three kinds of sources, SloBridge(s), display controller(s), and Dragon processors.

As used in this document, the term interrupt source is used in two ways: for a software (and processor) initiated class of interrupts, or for a device that is directly connected to the DynaBus and issues interrupt requests directly to the small caches. In this sense, the SloBridge is an interrupt source, yet devices connected to the SloBridge are not interrupt sources. The term interrupt source index denotes a compact indexing scheme that identifies index sources by a 5 bit index (with values 0 through 31).

As used in this document, the term interrupt request is used to indicate a single request for interrupt servicing that is derived from either an I/O device or a processor. It is a more generic term than interrupt source, and its meaning should be clear from context.

Various aspects of interrupt support in the IFU have been described elsewhere (see the References section), but we will summarize the description here for convenience.

The interrupt hardware in the IFU consists of a Reschedule line to signal interrupts, a Status register to record (among other things) state information about interrupts, and some logic to cause the necessary changes in the processor's control flow. Two of the bits in the Status register are relevant to interrupts: reschedule and trapsEnabled; the first bit records a pending reschedule, while the second provides the ability to mask reschedules. Thus, asserting the Reschedule line sets the reschedule bit. If trapsEnabled is set, the processor takes a reschedule trap immediately after the current instruction is completed (taking the trap is semantically equivalent to executing a procedure call). Once the IFU decides to take the trap, it clears trapsEnabled before actually taking the trap to avoid infinite regress. It is the task of the trap routine to re-enable traps.

A cache asserts the Reschedule line by pulsing it for one PhA/PhB cycle. This avoids the problem of having the IFU tell the cache when to lower the Reschedule line. The timing of Reschedule is shown below:

Small caches have two 32-bit registers, InterruptStatus and InterruptMask for interrupt support. Each bit position in the two registers corresponds to a different interrupt source; sources are treated equally as far as the hardware is concerned, but the software can implement any level structure it wants on top since it has complete freedom in choosing the servicing order. The bits in InterruptStatus correspond to pending interrupts, while those in InterruptMask allow interrupts from individual reasons to be masked (a 0 value masks). Masked interrupts are still recorded in InterruptStatus, but they do not result in a Reschedule. On reset, a cache sets the InterruptStatus and InterruptMask registers to zero to indicate no interrupts pending and all interrupts disabled.

The cache's Reschedule output will be pulsed for one Dragon cycle (signaling an interrupt to its IFU) whenever the OR of (InterruptStatus AND InterruptMask) changes from 0 to 1.

All of the operations listed below are atomic system-wide. All EU cache interrupt operations are implemented via I/O transactions, where the ID field specifies the cache, the I/O address specifies which operation is to be performed, and the I/O data (low-order 32 bits) supplies an additional parameter for operations that may modify the EU cache state. The I/O transaction can be either initiated from the Dynabus side or the processor side of the EU cache. The *Broadcast operations differ from the other operations in that a BIOWrite transaction is used instead of an IORead or IOWrite transaction. The *Self operations are meaningful only from a processor to its EU cache and allow a processor to handle its own interrupt status without knowing the DynaBus DeviceID of its EU cache.

The following summarizes the interrupt management operations available for the EU cache (refer to CacheOps.mesa [4] for an exact Cedar interface):

A processor may manipulate its interrupt status without knowing its own ID (through the *Self operations), which simplifies the software a little in some critical sections. The *Self operations above are only implemented via I/O instructions executed by the Dragon processors. As an optimization to reduce Dynabus traffic, the EU cache does not need to issue a Dynabus transaction. The *Self operations differ from their directed counterparts only in that the 24 MSB of the I/O instruction operand is 0, which is interpreted as directing the request to the connected EU cache.

Although both the IFU and EU caches support the above operations, the IFU's Reschedule line is connected only to the EU cache. Thus, it is meaningful to direct operations only to the EU cache.

The SloBridge receives a number of physical interrupt lines from the outside world and from on-chip sources. The SloBridge must provide a method for interrupt one (or all) Dragon processors to provide device service. Since the SloBridge only provides one interrupt source for all of the devices it must also provide a means to distinguish which devices are requesting service.

A SloBridge has 3 interrupt support registers: InterruptStatus, InterruptMask and InterruptAction. InterruptStatus is a read-only copy of the current state of the physical interrupt lines. InterruptMask acts as a mask on each physical interrupt line (one mask bit per interrupt line, 0 meaning masked). InterruptAction specifies what should be done to notify a cache that a SloBridge interrupt needs servicing: either a single cache or all of them may be notified, and the reason bit to be raised is programmable (more details given below).

The SloBridge contains an internal 1-bit flag (ServiceRequired) indicating that service has been required, but has not been provided. This bit is set when a new interrupt line becomes visible (because the physical line raises, or because the mask makes visible an active line previously hidden). If ServiceRequired was not previously set, an interrupt request is sent according to InterruptAction. When a processor reads InterruptStatus, ServiceRequired is cleared. This scheme ensures that a processor does not get spurious interrupts (in fact, spurious interrupts may still occur, although with a much lower probability).

All SloBridge interrupt operations are invoked via I/O instructions, where the ID field indicates which SloBridge is being selected, the I/O address specifies the operation, and the I/O data supplies an additional parameter (which is ignored for Read* operations). The following summarizes the operations available (refer to SloBridgeOps.mesa [3] for an exact Cedar interface) for each SloBridge register:

This section traces the handling performed for a single interrupt. We give the steps for a "normal" device interrupt in chronological order.

Although the hardware supports masking of interrupt sources, our current plans for interrupt handling do not use this feature. All processors are equivalent, and all interrupt sources are permitted.

In general, each interrupt request is handled by notifying a condition variable associated with each source. This notification causes a process switch to the handler, which then performs the necessary data handling and clears the interrupt request.

This description is subject to change, particularly the parts involving the software.