Method and system for transmitting interrupts from a peripheral device to another device in a computer system

[0002] The present invention concerns a computer system and method of communication of interrupts in the computer system.

[0003] In many applications there are more devices which may need interrupt capability than the processor has dedicated interrupt connections. In this case the interrupt request lines of each device may be OR-ed together and connected to a single interrupt pin belonging to the processor. When any one or more of the devices asserts an interrupt the processor interrupt line is asserted. The processor has the task of polling each device in turn. It normally does this by testing the interrupt bit of a status register of each device controller. When the identity of the interrupting device is determined, the processor can then call a routine associated with that interrupt source. This method is appropriate for slower devices or when there are few interrupting devices attached to the system.

[0004] Another existing system is generally called a vectored interrupt system. In such a system a separate device sometimes called a programmable interrupt controller (PIC) is connected to all devices which are capable of raising an interrupt. The PIC can be programmed to prioritise any interrupts it receives with respect to each other and, in some cases, with respect to the current priority of the processor. It can also contain a table which contains the association of interrupt handler routines and the interrupt source. In such a system a CPU is directed towards the routine by the PIC.

[0005] Another known interrupt system is referred to as a multi-processor interrupt system. In this example, an external device can be configured to provide vectored interrupts to multiple processors. A particular interrupt is associated with a vector and a CPU to which the interrupt request should be sent.

[0006] In the first prior art example the interrupt response can be very slow due to the fact that the processor may have to access many device registers before finding out the identity of the interrupt source. This can be slow and does not provide a mechanism for dealing with multiple processors.

[0007] The second example cannot be applied to multiple processors and multiple devices.

[0008] The third example requires the implementation of an auxiliary bus to carry interrupt signals to multiple processors. This requires extra pins or signals and extra logic to implement whatever protocol applies to the use of these signals.

[0009] Interrupts generally occur as a result of a change in state of a peripheral device, caused by some activities of the peripheral device. This change in state is generally represented by an electrical condition, such as the voltage or current level on an output wire. In the prior art, the pins and signal lines carry these state changes to whatever is responsible for dealing with the interrupts. Thus, even in the situation where there is a centralised programmable interrupt controller, there must still be dedicated lines from each peripheral device carrying the state information directly to the central controller. It is one aim of the present invention to remove this requirement for dedicated interrupt lines.

[0010] According to one aspect of the present invention there is provided a method of transmitting an interrupt represented by an electrical level of a conductor from a peripheral device to a receiving module by:

[0011] detecting the electrical level of the conductor;

[0012] constructing a message packet to transmit the interrupt when it is detected that the electrical level has changed between a logical zero level and a logical one level;

[0013] transmitting the message packet from the peripheral device to the receiving module; and

[0014] at the receiving module, handling the message packet to act on the interrupt by implementing an interrupt handling routine.

[0015] According to another aspect, the invention also provides computer system comprising at least one peripheral device and a processor in communication with the peripheral device via a routing path, wherein the peripheral device is associated with circuitry for detecting the electrical level of a conductor representing an interrupt and a packet assembler for constructing a message packet when it is detected that the electrical level of the conductor has changed between a logical zero level and a logical one level, wherein the message packet is transmitted from the peripheral device to the processor via the routing path, and wherein the processor includes a packet handler for handling the message packet to act on the interrupt by implementing an interrupt handling routine.

[0016] In one embodiment of the invention interrupts are communicated between a number of different peripheral devices and processors in a computer system using discrete event packets. A device wanting to raise an interrupt fabricates an event packet which specifies the processor which is to service the interrupt, and an indication of the origin of the interrupt. This packet is routed to the specified processor. The receiving processor is able to call the interrupt handling routine corresponding to that interrupt either directly or indirectly through a table in a conventional manner. The event packets can carry indications of the interrupt being edge-triggered or level sensitive.

[0017] Unlike the prior art, no extra connectivity is required between peripheral devices and any of the processors which can service interrupts.

[0018] In one arrangement, the message packet includes identification of the peripheral device which generated the interrupt and the receiving module includes an interrupt handling routine dependent on that identity.

[0019] In another arrangement, the message packet includes a transaction identifier which uniquely identifies one of a series of interrupts and the receiving module generates a response packet including the same transaction identifier.

[0020] For a better understanding of the present invention and to show how the same may be carried into effect, reference will now be made by way of example to the accompanying drawings.

[0021] FIG. 1 is a block diagram illustrating the fundamentals of the present invention;

[0022] FIG. 2 is one example of a single chip architecture;

[0023] FIG. 3 is a logical diagram of an interrupt source for a peripheral device;

[0024] FIG. 4 illustrates the sampling timing for the generation of level sensitive events;

[0025] FIG. 5 illustrates the sampling timing for the generation of edge sensitive events;

[0026] FIG. 6 is a diagram of an event packet;

[0027] FIG. 7 is a schematic diagram of a packet assembler; and

[0028] FIG. 8 is a block diagram of an event handling mechanism.

[0029] According to the presently described embodiment, when a peripheral device wishes to raise an interrupt, it constructs and transmits an event packet. This is referred to as generating an event. The following describes how this can be implemented in an embodiment of the invention.

[0030] FIG. 1 is a block diagram illustrating the basic fundamentals. A peripheral device 2 has a conductor 4, for example in the form of an interrupt pin or wire which carries state information representative of the activity of the peripheral device 2. That state information takes the form of a logic value V represented by the voltage or current level on the wire 4. That state information is sampled by a sampler 6 which takes the form a transition detector and is described in more detail later. Dependent on the results of the activities of the sampler 6, an event assembler 8 assembles an event packet EP which is dispatched from the event assembler 8 on a routing path 10. That routing path 10 can convey the event packet directly or via a network 12 to a CPU 14. An event handler within the CPU 14 receives the event packet EP and acts on it in an interrupt-like fashion as described in more detail in the following.

[0031] A plurality of different peripheral devices or interrupt sources can be provided. FIG. 2 illustrates one example of a single chip architecture which has a routing path 10 to which are connected a plurality of different ports, including an external interface port TDR for providing a debug link from a host to the on-chip CPU 14, two interrupt pins PIO provided at the chip boundary, an audio port AUD, a network port NET and a video port VID. Table I summarises for the particular example ports that generate level-sensitive events and those that can be programmed to generate level-sensitive events or edge events. Level-sensitive events and edge events are discussed in more detail hereinafter. Each port is equipped with an event assembler 8 to allow it to generate events packets EP.

[0032] There are a plurality of valid interrupt destinations. However, as a CPU is the normal destination for interrupts, this is assumed in the following description. However, it is noted that interrupts can also be sent to other modules which are equipped with event handlers.

[0033] The state of the interrupt wire 4 can change for a variety of different reasons. Each peripheral device 2 can be considered as an interrupt source of the type illustrated logically in FIG. 3.

[0034] A peripheral device may cause an interrupt on a CPU (i.e. generate an event targeted at a CPU) due to one of a number of reasons. An interrupt source is associated with the following:

[0035] An enable flag E that allows interrupts from that source, regardless of the reason, to be enabled or disabled.

[0036] Each reason is associated with the following:

[0037] A one bit mask flag M_ithat controls whether the value of that reason contributes to the interrupt value V on wire 4 or whether it is ignored.

[0038] A one bit reason flag R_ithat indicates the value of that reason. This flag will be read-only if the reason is derived using combinational logic from the state of the peripheral device 2. This flag will be read-write if the reason is latched. A mechanism is provided to allow software to clear the reason flag.

[0039] The above flags are combined together in a standard way to form the interrupt value V. If a peripheral device has r distinct interrupt reasons:

[0040] Value=Enable & (OR_{i in [0,r)}(Reason_i& Mask_i))

[0041] OR_{i in [0,r)}f(i) represents the boolean-or of all values of f(i), where i is in the range [0,r), and “&” represents the dyadic boolean-and operation.

[0042] A pictorial representation of this arrangement is given in FIG. 3 for a peripheral device which has one combinatorial reason (reason 2) and two latched reasons (reason 0 and reason 1). In FIG. 3, a solid square represents a flag driven from a latch, and a dashed square represents a flag driven from combinatorial logic. Reference numeral 16 denotes AND gates and reference numeral 18 an OR gate.

[0043] The representation of FIG. 3 is an exemplary arrangement. Concrete details of the various flags vary for each interrupt source and are designed appropriately.

[0044] Two different types of interrupt are discussed herein: level-sensitive and edge-triggered. A peripheral device which is configured as a level-sensitive interrupt will generate an event packet when (referring to FIG. 3) there is:

[0045] a detected change in the interrupt value V from 0 to 1—this generates a level-on event;

[0046] a detected change in the interrupt value from 1 to 0—this generates a level-off event.

[0047] The sampler 6, in the form of a transition detector, samples the continuous interrupt values in order to detect these changes. Normally a sample is taken on each clock cycle. In some practical embodiments of this invention samples may be taken less frequently than this.

[0048] After a transition has been detected it takes an implementation defined number of cycles before a subsequent transition can be detected. This delay allows an event packet EP to be generated for that transition. Such a delay causes consecutive samples to be separated by more than one clock cycle.

[0049] The transition detector detects a transition between the current sample and the previous sample. As described in the previous paragraph, these samples are not necessarily taken on consecutive clock cycles. Initially the previous sample is 0 since the initial value of the interrupt is off. This arrangement ensures that the transition detector will alternate between level-on events and level-off events, starting with a level-on.

[0050] The sampling algorithm used to turn interrupt values into events can cause interrupt level transitions to be lost. If there are zero or one transitions between sample points, then no transitions are lost. However, if there are two or more transitions between sample points, then an even number of transitions are treated as zero transitions and an odd number of transitions are treated as one transition.

[0051] The effect is that pairs of adjacent transitions are lost if they occur between sample points. However, the interrupt source guarantees that it will alternate between level-on and level-off events, and that the interrupt level is consistent with the interrupt value at sample points.

[0052] The behaviour is illustrated in FIG. 4. The top two waves in this FIG., 4aand 4b, show the clock and an example interrupt value on wire 4. The subsequent examples A, B and C show, depending on where the sample points are taken, the produced interrupt level and the generated level events for the example interrupt value.

[0053] In example A, the transition T1 is detected, the transition pair T2/T3 is lost, T4 and T5 are detected, and T6 is delayed.

[0054] In example B, T1 is detected, the pairs T2/T3 and T4,T5 are lost and T6 is delayed.

[0055] In example C, T1 is detected, T2 is delayed, the pair T3/T4 are lost, T5 is detected and T6 is delayed.

[0056] Transitions are lost only (and then always in pairs) if the interrupt value changes multiple times between sample points. This can be avoided with properly designed level-sensitive interrupt sources.

[0057] For edge-triggered events the interrupt value is sampled in exactly the same way as for a level-sensitive interrupt source. The particular transitions which are turned into edge events depend upon the precise details of the peripheral device concerned. A peripheral device might detect 0 to 1 transitions or 1 to 0 transitions or both kinds of transition. Detected transitions cause an edge event to be generated; this edge event does not indicate the direction of the transition.

[0058] There may be clock periods where samples are not taken: after a transition has been detected it will take an implementation defined number of cycles before a subsequent transition can be detected.

[0059] The sampling algorithm used to turn interrupt values into events can cause edge transitions to be lost. If there are zero or one transitions between sample points, then no transitions are lost. However, if there are two or more transitions between sample points, then an even number of transitions are treated as zero transitions and an odd number of transitions are treated as one transition. The effect is that pairs of adjacent transitions are lost of they occur between sample points.

[0060] This behaviour is illustrated in FIG. 5. The top two waves in this FIGS., 5a, 5b, show the clock and an example interrupt value V on wire 4. The subsequent example A, B and C show, depending on where the sample points are taken, the produced interrupt level and the generated edge events for the example interrupt value.

[0061] In example A, the transition T1 is detected, the transition pair T2/T3 is lost, T4 is ignored, T5 is detected, and T6 is ignored.

[0062] In example B, T1 is detected, the pairs T2/T3 and T4/T5 are lost, and T6 is ignored.

[0063] In example C, T1 is detected, T2 is ignored, the pair T3/T4 are lost, T5 is detected, and T6 is ignored.

[0064] Transitions are lost only if the interrupt value changes multiple times between sample points. This can be avoided with properly designed edge-triggered interrupt sources.

[0065] An event packet is generated by the event assembler 8, the packet having the format shown in FIG. 6. The packet is eight bytes long and comprises a header portion having a length of four bytes and denoted HEADER in FIG. 6, and opcode portion one byte in length, a transaction identifier (TID) one byte in length, a source identifier, one byte in length and a device identifier one byte in length. The source and device identifier portions do not have to be distinct and are intended to identify the originator of the event. The device identifier denotes the identity of the peripheral device generating the event packet, and the source portion can be used to denote the source of the interrupt within that peripheral device. The transaction identifier (TID) can be used in a situation where a sequence of packets may be generated in respect of different interrupts, in which case the transaction identifier TID would be incremented by one (by a counter) each time. Where desired, this can be used in a system where response packets are generated and received by the peripheral devices. In that case, the response packet would contain the same transaction identifier as that generated in the event packet. In a simpler implementation however, the transaction identifier can always be set to zero.

[0066] The opcode byte identifies the packet as an event packet and is the same for all events. This allows the receiving CPU to treat the packet as an event packet. For the purposes of the present disclosure, other packet types are not discussed, but it will be appreciated that the present invention can be used in the context of other packets conveying messages other than interrupt messages.

[0067] The header portion of the packet HEADER includes the fields identified in Table II below. Thus, it includes a priority indicator which indicates the priority level of the event at bits 0-4, identification of the type of event at bits 5-6 and the destination of the packet. In the present implementation, that destination is always defined as the on-chip CPU which in the present implementation is the only module capable of handling event packets.

[0068] The event assembler is illustrated in FIG. 7. The event assembler comprises a transaction register 60, and a 32 bit header register 62, and a 32 bit address register 61. The address register 61 holds a four byte address which predefines the address to which event packets from that peripheral device will be dispatched. The top two bytes of that address are loaded into the header register 62 when a packet is to be assembled. Bit positions 0-15 of the header register 62 have already been set with priority indicators and event types which relate to that peripheral device. Thus, these are predetermined for each peripheral device. Although it will be clear from the preceding description of Table I that the types of events can be programmed, once programmed the event types are set in the header register 62. The transaction register 60 holds the remaining four bytes of the packet as described earlier. When an event packet is to be transmitted, the complete packet is assembled in a packet buffer 64.

[0069] To launch the packet, it is transferred to a transmit buffer 66 from where it is transferred onto the routing path 10 which transmits the packet to the CPU 14.

[0070] FIG. 8 illustrates a schematic diagram of the event handler 15 which is provided at the CPU 14 for receiving event packets. A receive buffer 20 is connected to the routing path 10 to receive event packets. A signal p-en.op on line 22 is asserted from the OPCODE field to identify the packet as an event and a signal p-valid on line 26 signals that a valid packet is received in the buffer.

[0071] A signal p-ev.done on line 24 is asserted when a packet is removed from the receive buffer.

[0072] Event decode logic 28 asserts an event-type signal EV-TYPE on line 30 and an event priority signal EV-PRIORITY on line 32 to prioritisation logic 34. The event handler includes a number of control registers, including the following:

[0073] PCR.event.handler register 36;

[0074] ESW register 38;

[0075] SAVE.ESW register 40;

[0076] PCR.ENABLE register 35;

[0077] SAVE.IPTR register 37;

[0078] SAVE.TSW register 39.

[0079] These registers are connected via a control register bus 42 to a CPU pipeline 44. The PCR.event.handler register 36 generates an instruction pointer IPTR to an instruction cache 46 which supplies instructions for execution by the CPU pipeline 44. Reference numeral 48 denotes a register file forming part of the CPU 14. Reference numeral 50 denotes a transmit buffer which holds packets assembled by the CPU pipeline 44 for transmission on the routing path 10.

[0080] The prioritisation logic 34 will not be described in detail herein. It controls the order in which event packets are acted on by the CPU by determining on receipt of an event packet whether and when it will be accepted for handling. The following description assumes that an event packet which has been received by the event handler will be accepted for handling.

[0081] Two of the control registers 38,40 hold event information, as follows:

[0082] ESW Event Status Word. This defines the event state of the CPU.

[0083] SAVE.ESW Previous Event Status Word. This contains the previous event state of the CPU, and the source of the event, for use by event handlers.

[0084] Events are disabled by hardware on event acceptance. The format of the ESW and SAVE.ESW registers 38, 40 is shown in Table III.

[0085] The field ESW.PRIORITY holds the existing priority state of the CPU. When an event is accepted by the CPU 14, the content of the ESW register 38 is copied to the SAVE.ESW register 40 as defined in Table III, including the CPU priority. This allows the CPU priority to be recovered when the event has been handled. The reserved fields in the ESW are copied to the SAVE.ESW register on event acceptance, in order to provide forward compatibility. The CPU priority is set to that of the accepted event, by setting the ESW.PRIORITY bits. The PCR.ENABLE control register 35 is then cleared, disabling acceptance of another event.

[0086] When an event is accepted, the CPU 14 will be in train of executing an existing instruction thread. This will be interrupted to allow the event to be handled and so is referred to herein as the interrupted thread. Each thread is associated with an instruction pointer IPTR and thread status word TSW. The IPTR and TSW of the interrupted thread d are copied to the SAVE.IPTR and SAVE.TSW control registers 37, 39 respectively. The SAVE.IPTR points to the next unexecuted instruction of the interrupted thread and the SAVE.TSW value is consistent with this.

[0087] Then a so-called event handler is launched. An event handler is launched by the CPU commencing an interrupt service routine which is a sequence of instruction s for dealing with the e interrupt conveyed by the event packet. The correct interrupt service routine is identified from a table held in the CPU memory by the DEVICE ID and priority indicator bits of the event packet. This information is supplied along the EV-TYPE line 30.

[0088] The event handler inherits the contents of any necessary registers from the interrupted thread. Also the contents of those registers which should not be destroyed by the event handler must be saved.

[0089] The first instruction in the event handler sequence initialises the IPTR to the event handler entry point when an event is accepted.

[0090] The PCR.EVENT.HANDLER control register holds the entry point to the event handler when interrupting a kernel mode thread.

[0091] The event handler entry point for interrupting user mode threads is derived from the kernel mode entry point by clearing the least significant 8 bits. In this way, event handlers interrupting user threads must be aligned to 256 byte boundaries. The event handler for kernel threads can be up to 254 bytes after this. Often, event handler code can make some assumptions, should it be determined that the event interrupted a kernel mode thread. This mechanism provides a way for events interrupting user mode threads to cause some additional initialisation to occur. Should this separation not be required, the bottom eight bits of the control register should be set to zero, to force all event handlers to go to the same location.

[0092] The format of the PCR.EVENT.HANDLER control register is shown in Table IV.

[0093] The event handler can return control to the interrupted thread with a restart instruction. Exit code at the end of the event handler instruction sequence restores the values of the SAVE.IPTR and SAVE.TSW registers 37, 39 so that the interrupted thread can recommence.

[0094] The event handler sequence also restores the ESW register 38 to what it was before the event handler was launched. This can be done by storing the value which was in the SAVE.ESW register 40 at event handler launch.

[0095] In addition, any registers of the interrupted thread used by the event handler must be restored to their original state. If trap handlers can be interrupted before the trapped instruction state has been retrieved, then event handlers must also save and restore this state.

[0096] The possibility exists that event packets may arrive at the CPU at a faster rate than the processor is able to process them. In such a situation it is generally not possible to buffer up details of interrupts until the CPU can clear them. It is important however, to inform event handlers when there have been events raised whose details could not be stored. The ESW.SHAREDLEVEL and ESW.OVERRUN flags of the ESW register 38 (see Table II) provide facilities for this. Using these flags, the event handler software is always aware of when a single event handler launch is caused by:

[0097] i) more than one level-on event;

[0098] ii) too many level-on events;

[0099] iii) two or more edge-triggered events.

[0100] The CPU 14 also generates response packets when an event packet is received. These response packets are returned to the peripheral device which generated the event packet. If transaction identifiers are used, the response packet contains the same TID number as that in the corresponding event packet. The generation and handling of response packets. is not described further herein.