EP1415233A1

EP1415233A1 - Efficient interrupt system for system on chip design

Info

Publication number: EP1415233A1
Application number: EP02745724A
Authority: EP
Inventors: Rune Jensen; Augusto De Oliveira; Thomas O'dwyer
Original assignee: Koninklijke Philips Electronics NV
Current assignee: Koninklijke Philips NV
Priority date: 2001-07-30
Filing date: 2002-07-02
Publication date: 2004-05-06
Also published as: JP2004537809A; CN1535427A; WO2003012658A1

Abstract

A method (400) and system (10) for managing interrupts in a system on a chip design that includes multiple processors (100a, 100b, ..., 100n) coupled to multiple peripheral devices (120a, 120b, ..., 120m). A plurality of interconnected interrupt controllers (110a, 110b, ..., 110n) are coupled between the processors and the peripheral devices. Interrupts generated by the peripheral devices are received by all of the interrupt controllers. In one embodiment, an interrupt controller is paired with a processor. Each interrupt controller can identify which interrupts will be passed to its respective processor. The interrupt controllers work in concert to pass each interrupt to a particular processor.

Description

Efficient interrupt system for system on chip design

TECHNICAL FIELD

The present invention generally relates to the field of integrated circuits ("chips"). More specifically, the present invention pertains to the management of interrupts in a system-on-a-chip design that includes multiple processors and multiple peripheral devices.

BACKGROUND ART

"System-on-a-chip" architectures (e.g., a microcontroller or microprocessor) are commonly used in applications including audio, wireless, handheld, data communication, Internet control, and industrial and consumer systems. The system-on-a-chip architecture provides design and manufacturing efficiencies both in the production of the chip and in the incorporation of the chip in a particular application.

For improved performance, some system-on-a-chip architectures utilize multiple central processing units (CPUs). Also, system-on-a-chip architectures may utilize multiple buses typically organized in some type of hierarchical arrangement.

Problems occur with system-on-a-chip architectures as the complexity of the chips increase. With multiple CPUs on a chip, and with multiple peripheral devices supported by the chip, management of interrupt requests generated by the peripheral devices can be cumbersome. For example, interrupt requests may be simultaneously generated by the peripheral devices. The interrupt requests need to be individually handled, and each one routed to a CPU. Each CPU handling an interrupt request must interrogate each of the peripheral devices to determine which device is the source of the interrupt request. Conflicts between interrupt requests must be arbitrated should a CPU receive multiple interrupt requests at the same time. The prior art techniques for managing interrupt requests in multiple processor architectures share one or more disadvantages. The prior art interrupt management techniques may require complicated and inefficient multi-bus designs. In addition, the prior art techniques may not permit the processors to communicate with each other regarding the handling of interrupt requests. Also, the prior art techniques may assign certain interrupt requests to a particular CPU in hardware; thus, the prior art techniques may be relatively fixed and inflexible. Furthermore, the prior art techniques may impose difficult timing and layout constraints on integrated circuit designers; thus, the time needed to design and produce integrated circuits may be increased. Accordingly, what is needed is an interrupt management system and/or method that can accommodate simpler and more efficient multi-bus designs. What is also needed is an interrupt management system and/or method that can satisfy the above need and that can allow inter-processor communication for handling interrupt requests. Also, what is needed is an interrupt management system and/or method that can satisfy the above needs and that is flexible regarding the assignment of interrupt requests to CPUs. Furthermore, what is needed is an interrupt management system and/or method that can satisfy the above needs and that can facilitate integrated circuit design by not placing unnecessarily burdensome timing and layout constraints on designers. The present invention provides a novel solution to these needs.

DISCLOSURE OF THE INVENTION

The present invention pertains to a method and system for managing interrupt requests ("interrupts") in a system-on-a-chip design that includes multiple central processing units (e.g., processors) coupled to multiple peripheral devices. The present invention provides an interrupt management system and method that can accommodate simpler and more efficient multi-bus designs. The present invention also provides an interrupt management system and method that can allow inter-processor communication for handling interrupts. In addition, the present invention provides an interrupt management system and method that are flexible regarding the assignment of interrupts to processors (e.g., central processing units). Furthermore, the present invention provides an interrupt management system and method that can facilitate integrated circuit design by not placing unnecessarily burdensome timing and layout constraints on designers.

In accordance with the present invention, in a multiple processor architecture supporting multiple peripheral devices, a plurality of interconnected interrupt controllers are coupled between the processors and the peripheral devices. The interrupt controllers work in concert to pass an interrupt to a particular processor. The interrupt controllers also can be used for inter-processor communication when needed; that is, one processor can generate an interrupt that can be communicated to another processor via the interrupt controllers. In one embodiment, the number of interrupt controllers and the number of processors are equal, and each interrupt controller is paired with a single processor (and vice versa). In one such embodiment, each interrupt controller includes an interrupt priority register (or similar memory unit) which contains a priority ranking of each of the peripheral devices. This information is specific to each of the interrupt controllers, and can be used by the interrupt controller to determine whether the interrupt will be passed to its paired processor. This information can also be used by the interrupt controller to arbitrate between interrupts when more than one interrupt is received concurrently at the interrupt controller.

Each interrupt generated by a peripheral device is received by all of the interrupt controllers. Using the information described in the preceding paragraph, the interrupt controllers each identify whether the interrupt is to be passed to its paired processor. In this manner, the interrupt controllers work in concert to pass the interrupt to a particular processor.

In one embodiment, each interrupt controller includes an interrupt priority limiter register (or similar memory unit) that is set to the value of the priority of the interrupt currently being handled. In another embodiment, each interrupt controller includes an interrupt source register (or similar memory unit) which identifies the pending interrupt with the highest priority and whose priority is greater than the value in the interrupt priority limiter register. That is, the interrupt source register identifies the interrupt that should be handled next. Upon handling this interrupt, the processor performs a single read access of this register to identify the peripheral device that generated the interrupt.

The present invention method and system for managing interrupts is scalable. Adding peripherals is straight-forward and can be controlled by changes to the Register Transfer Language descriptions of the interrupt controllers. The present invention can also be extended to include any number of processors. In addition, any number of on-chip buses is allowed.

The interrupt controllers can be programmed in software to map interrupts to any of the processors. Nested interrupts (e.g., interrupts occur simultaneously or near simultaneously) are readily handled in accordance with the present invention. The efficiency of interrupt handling is improved because, for example, a processor need perform only a single read access to identify the peripheral device that is the source of the interrupt.

Moreover, integrated circuit design and implementation are facilitated because the interrupts can be handled asynchronously, and so the handling of interrupts is not critical to establishing the timing or layout of the integrated circuit. These and other objects and advantages of the present invention will become obvious to those of ordinary skill in the art after having read the following detailed description of the preferred embodiments that are illustrated in the various drawing figures.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention:

Figure 1 is a block diagram providing an overview of an interrupt management system according to one embodiment of the present invention.

Figure 2 is a block diagram of one embodiment of an interrupt controller in accordance with the present invention.

Figure 3 is a block diagram providing additional details of the interconnects between blocks in the interrupt management system of Figure 1. Figure 4 is a flow chart of the steps in a process for managing interrupts in accordance with one embodiment of the present invention.

Figure 5A is a data flow diagram showing inter-processor communication via interrupt controllers in accordance with one embodiment of the present invention.

Figure 5B is a timing diagram for inter-processor communication such as that illustrated in Figure 5A.

BEST MODE FOR CARRYING OUT THE INVENTION

Reference will now be made in detail to the preferred embodiments of the invention, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with the preferred embodiments, it will be understood that they are not intended to limit the invention to these embodiments. On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the invention as defined by the appended claims. Furthermore, in the following detailed description of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be obvious to one of ordinary skill in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the present invention. Some portions of the detailed descriptions that follow are presented in terms of procedures, logic blocks, processing, and other symbolic representations of operations on data bits. These descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. In the present appUcation, a procedure, logic block, process, or the like, is conceived to be a self -consistent sequence of steps or instructions leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, although not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated in a computer system. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as transactions, bits, values, elements, symbols, characters, fragments, pixels, or the like.

It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussions, it is appreciated that throughout the present invention, discussions utilizing terms such as "generating," "communicating," "passing," "receiving," "routing," "storing," "identifying" or the like, refer to actions and processes (e.g., process 400 of Figure 4) of a computer system or similar electronic computing device. The computer system or similar electronic computing device manipulates and transforms data represented as physical (electronic) quantities within the computer system memories, registers or other such information storage, transmission or display devices.

Figure 1 is a block diagram providing an overview of an interrupt management system 10 according to one embodiment of the present invention. In the present embodiment, the interrupt management system 10 includes a number of processors (CPUs) lOOa-n, a number of interrupt controllers 1 lOa-n, and a number of peripherals 120a-m. In accordance with the present embodiment of the present invention, when one of the peripherals 120a-m generates an interrupt request ("interrupt"), the interrupt controllers 110a- n work in concert to direct the interrupt to a single one of the CPUs lOOa-n; additional details are provided below. As will be seen, interrupt management system 10 of the present invention is scaleable and can accommodate any number of processors, interrupt controllers and peripheral devices.

The interrupt controllers HOa-n are interconnected and can communicate with each other; refer also to Figure 3, below. Typically, the CPUs lOOa-n and the interrupt controllers HOa-n reside in an integrated circuit (e.g., they are representative of a system-on- a-chip architecture). However, it is appreciated that one or more of the CPUs lOOa-n and one or more of the interrupt controllers 1 lOa-n may instead reside outside of the integrated circuit. Similarly, some or all of the peripherals 120a-m may reside in the integrated circuit. With reference to Figure 1 , in one embodiment, the number of interrupt controllers and the number of processors are equal and, at least with regard to interrupts, communication to a CPU occurs through an interrupt controller. In this embodiment, each interrupt controller llOa-n is paired with a single CPU lOOa-n, and vice versa. That is, CPU 100a is paired with interrupt controller 110a, CPU 100b is paired with interrupt controller 110b, and so on. In this embodiment, at least with regard to interrupts, the interrupt controllers llOa-n communicate directly to their respective CPU lOOa-n, and to another CPU via the interrupt controller paired with that CPU. That is, for example, interrupt controller 110a communicates directly to CPU 100a, and interrupt controller 110a communicates to CPUs lOOb-n through the other interrupt controllers llOb-n. Note that, in the present embodiment, the interrupt controllers 1 lOa-n are not conduits for passing data to CPUs 100a- n, but are primarily for controlling the flow and distribution of interrupts to the CPUs lOOa-n.

In one embodiment, each CPU lOOa-n is able to communicate to each of the peripherals 120a-m via an on-chip bus 130. In one embodiment, the CPUs lOOa-n are coupled to a register access bus 135 that allows the CPUs to read and write to interrupt controller registers (see Figure 2, below). In one embodiment, an interrupt generated by any of the peripherals 120a-m is routed to all of the interrupt controllers llOa-n. However, in an alternative embodiment, interrupts may be selectively routed to a subset of the interrupt controllers 1 lOa-n instead of to all of the interrupt controllers.

Each interrupt controller 1 lOa-n is programmed to recognize those interrupts that should and should not be passed to its respective (paired) CPU. The interrupt controllers 1 lOa-n are programmed so that each peripheral 120a-m is accounted for. According to this programming, each interrupt controller llOa-n determines whether the interrupts it receives should be passed to the CPU it is paired with. For example, interrupt controller 110a determines whether or not an interrupt should be passed to CPU 100a and, if so, the interrupt is passed to CPU 100a; otherwise, it is not. Because all of the peripherals 120a-m are accounted for, an interrupt generated by any one of the peripheral devices will be handled by one of the interrupt controllers llOa-n and, consequently, one of the CPUs lOOa-n. Additional information is provided in conjunction with Figure 2, below. Figure 2 is a block diagram of one embodiment of an interrupt controller 110a in accordance with the present invention. In this embodiment, interrupt controller 110a is a hardware element comprising an interrupt source register 210, an interrupt priority register 220, a compare logic block 225, an interrupt priority limiter 230, an AND gate 240, and an OR gate 250. As the function of interrupt controller 110a is described in the context of these various elements, it will be understood that interrupt controller 110a is not limited to the described embodiment, and that interrupt controller 110a may be alternatively configured to accomplish the intended function.

In the present embodiment, interrupt priority register 220 is a dynamic and configurable register that includes a priority that has been assigned to each one of the peripherals 120a-m (Figure 1). Thus, in the present embodiment, each interrupt controller 1 lOa-n (Figure 1) can be programmed with a priority ranking for all of the peripherals 120a- m. The information in interrupt priority register 220 is specific to the interrupt controller 1 lOa-n. That is, the priority ranking of the peripherals 120a-m is different for each of the interrupt controllers 11 Oa-n.

In accordance with the present invention, the priority ranking is provided to each interrupt controller 1 lOa-n by software executed by one of the processors lOOa-n (Figure 1). In other words, each interrupt controller 110a is programmed with a unique priority ranking of the peripherals 120a-m. The priority ranking used by a particular interrupt controller 11 Oa-n, as well as the priority ranking assigned to each of the peripherals 120a-m, can be dynamically changed. As a result, the peripherals 120a-m can be assigned (mapped) to any of the CPUs lOOa-n, and the mapping can be changed so that a peripheral assigned to one interrupt controller (and CPU) can be assigned to a different CPU. In addition, when peripheral devices are added or removed, the interrupt management system and method of the present invention can be readily updated and, as such, is scaleable to any number of peripherals. Because the mapping of peripheral devices to CPUs is provided in software and thus can be readily changed or expanded, the present invention provides a flexible as well as scaleable system and method for managing interrupts.

With reference to Figure 2, some peripherals will have a priority ranking in interrupt priority register 220 that indicates that their interrupts are not to be passed by interrupt controller 110a to CPU 100a. For example, these peripherals may have a priority ranking of zero, or the bit (or bits) in interrupt priority register 220 that define the priority ranking may be disabled for these peripherals. In this manner, the priority ranking in interrupt priority register 220 is used to define which peripherals are assigned to interrupt controller 110a and consequently to CPU 100a.

Other peripherals will have a priority ranking in interrupt priority register 220 indicating their interrupts are to be passed by interrupt controller 110a to CPU 100a. Each such peripheral can be assigned a different priority to indicate that interrupts from some peripherals take precedence over interrupts from other peripherals. As a result, if interrupt controller 110a receives more than one interrupt 260 at or about the same time, interrupt controller 110a can automatically arbitrate between the interrupts to select and handle the interrupt with the highest priority. In the present embodiment, interrupt priority limiter 230 is a dynamic and configurable register that is set to the value of the priority of the interrupt 270 that is currently being handled by interrupt controller 110a by software. This is done so that interrupt priority limiter 230 specifies a threshold value based on the interrupt 270 currently being handled by interrupt controller 110a. In one embodiment, nested interrupts can be handled as follows. When a subsequent interrupt 260 is received by interrupt controller 110a, compare logic block 225 compares the priority ranking of the subsequent (later) interrupt to the priority ranking of the interrupt 270 currently being handled. In the present embodiment, compare block 225 provides a signal to AND gate 240 based on this comparison. If the later interrupt has a higher priority than the threshold value specified by interrupt priority limiter 230, then an enable signal (e.g., an active "1") is passed to AND gate 240, the later interrupt is passed to CPU 100a, and the interrupt priority limiter 230 is updated with the new threshold value by software. If the later interrupt has a lower priority than the threshold value specified by interrupt priority limiter 230, then the AND gate 240 will not pass the later interrupt to CPU 100a. In this manner, nested interrupts are readily handled in accordance with the present invention. Thus, in this embodiment of the present invention, the interrupt with the highest priority, rather than the interrupt that arrives first, is handled by CPU 100a. The process of determining the priority of an interrupt and comparing that priority to the threshold value is instantiated once for each interrupt 260 received by the interrupt controller 110a. In one embodiment, OR gate 250 functions to provide only a single interrupt to CPU 100a. Some CPU designs permit them to have more than one interrupt input, while other CPU designs permit only a single interrupt input. Thus, OR gate 250 allows interrupt controller 110a to be used with either type of CPU design. Continuing with reference to Figure 2, interrupt source register 210 includes information that identifies which of the peripherals 120a-m (Figure 1) generated the interrupt that should be handled next by CPU 100a. Interrupt source register 210 identifies the pending interrupt with the highest priority and whose priority is greater than the value in the interrupt priority limiter register 220. Thus, the interrupt source register 210 identifies the interrupt that should be handled next. Accordingly, CPU 100a reads interrupt source register 210 to determine which peripheral 120a-m should be handled next. Thus, instead of accessing each peripheral 120a-m to determine which one of them generated this interrupt, CPU 100a needs to perform only a single access of interrupt source register 210 to make this determination, thereby improving the efficiency of the interrupt handling process. Using on- chip bus 130 (Figure 1), CPU 100a can then access the peripheral that generated the interrupt.

Following handling of the interrupt, CPU 100a clears the interrupt in the peripheral, which results in the interrupt being de-asserted in interrupt controller 110a and in CPU 100a. It is significant that interrupt controllers llOa-n generally comprise only combinatorial logic between their interrupt inputs and their interrupt outputs. This allows the interrupts to be passed to the respective CPU lOOa-n without a clock in the interrupt controller. In accordance with the present embodiment of the present invention, interrupts can be handled asynchronously, and so the handling of interrupts is not critical to establishing the timing or layout of the integrated circuit, facilitating the design of such circuits.

Figure 3 is a block diagram providing additional details of the interconnects between blocks in the interrupt management system 10 of Figure 1. Specifically, Figure 3 shows buses allowing interrupt controllers 1 lOa-n, and hence CPUs lOOa-n, to communicate with each other according to one embodiment of the present invention. It is appreciated that other bus configurations including different numbers and types of buses can be utilized in accordance with the present invention.

In the embodiment, on-chip bus 130 allows each CPU lOOa-n to communicate to the peripherals 120a-m. In addition, in one embodiment, the CPUs lOOa-n are each coupled to a register access bus 135. Register access bus 135 allows each CPU to access the interrupt source register 210 of Figure 2, to determine in a single read access which of the peripherals 120a-m generated that should be next handled by the CPU.

In the present embodiment, interrupt request bus 330 provides a communication path for sending interrupts from one interrupt controller to another and hence from one CPU to another. Thus, each CPU can request assistance from another CPU when necessary. Interrupt request bus 330 also provides the communication path for sending interrupts from the peripherals 120a-m to the interrupt controllers 1 lOa-n. The interrupt clear bus 320 is for clearing an interrupt after it has been handled (executed).

In general, when an interrupt controller receives an interrupt request from a CPU, that interrupt request is handled is the same fashion as an interrupt request received from a peripheral device. That is, a priority is associated with the interrupt request from the CPU and the interrupt controller handles the interrupt request according to that priority. The priority can be based on the CPU that generated the interrupt or on the peripheral device that generated the interrupt that prompted the CPU to in turn generate an interrupt. The interrupt request can be passed from one interrupt controller to a next interrupt controller until an interrupt controller (and a respective CPU) is found that can handle the interrupt. The protocol for inter-processor communication is described further in conjunction with Figures 5 A and 5B, below.

Figure 4 is a flow chart of the steps in one embodiment of a process 400 for managing interrupts in accordance with the present invention. In one embodiment, process 400 is implemented by the interrupt controllers llOa-n of Figure 1. It is appreciated that the steps in process 400 may be performed in an order different that presented, and that not all of the steps in process 400 may be performed.

In step 410 of Figure 4, with reference also to Figures 1 and 2, in the present embodiment each interrupt controller 1 lOa-n receives information sufficient for identifying which interrupts are to be passed to a CPU lOOa-n associated with each interrupt controller. In one embodiment, each interrupt controller 11 Oa-n is programmed with a priority ranking of the peripherals 120a-m. The priority ranking is unique to each interrupt controller llOa-n and is used to identify, for each interrupt controller and CPU pair, the peripheral device(s) whose interrupts will be passed by the interrupt controller to the CPU.

In one embodiment, the priority ranking is stored in the interrupt priority register 220 of each interrupt controller 220. The priority ranking stored in interrupt priority register 220 can be dynamically changed should additional peripheral devices be coupled to the CPUs lOOa-n, for example, or should it be desirable to change the mapping of peripherals 120a-m to CPUs lOOa-n.

In step 420 of Figure 4 and with reference also to Figures 1 and 2, in the present embodiment, an interrupt 260 is received by all of the interrupt controllers 1 lOa-n. In one embodiment, the interrupt generated by the peripherals 120a-m is assumed to be glitch- free. In step 430 of Figure 4, in one embodiment, using the priority ranking programmed in step 410 above, each of the interrupt controllers 1 lOa-n (Figure 1) determines whether the interrupt should be passed to its respective (paired) CPU. If the interrupt is enabled (that is, the interrupt has a priority other than zero), and if the interrupt has a priority greater than the threshold value specified in the interrupt priority limiter 230 of Figure 3, then the interrupt controller passes the interrupt to the respective CPU.

In step 440 of Figure 4, in the present embodiment, information identifying the peripheral that generated the interrupt that should be handled next by the CPU is stored in the interrupt source register 210 of Figure 3. The CPU (specifically, the interrupt handler of the CPU) can read the interrupt source register 210. Based on the interrupt source, the CPU can read the interrupt status from the peripheral that generated the interrupt. The status information provides the CPU with sufficient information to handle the interrupt. Following execution of the interrupt, the CPU clears the interrupt in the peripheral, which results in the interrupt being de-asserted to the interrupt controller as well as the CPU. In step 450 of Figure 4, should a CPU be busy and require assistance from another CPU, an interrupt can be generated by the first CPU and passed to the second CPU via their respective interrupt controllers. This is described further in conjunction with Figures 5A and 5B.

Figure 5A is a data flow diagram showing inter-processor communication via interrupt controllers PIC1 (501) and PIC2 (502) in accordance with one embodiment of the present invention. For simplicity of discussion, inter-processor communication is described in the context of two processors; however, inter-processor communication can be extended to any number of processors. A plurality of signals 510 are passed between PIC1 (501) and PIC2 (502) to enable inter-processor communication. The signals 510 include interrupt request signals (e.g., Int_req[p-0] and Int_req[r-0]) and interrupt clear signals (e.g., Int_clr[p- 0] and l t_clr[r-0]). Inter-processor communication via the interrupt controllers is performed asynchronously.

Figure 5B is a timing diagram for inter-processor communication (IP C) such as that illustrated in Figure 5A. Referring to both Figure 5A and Figure 5B, CPU1 (505) writes to PIC1 (501) to set Int_reql (510a) to initiate the request for inter-processor communication. This causes PIC2 (502) to assert Int_to_cpu2 (504) (if the interrupt priority is higher than the threshold value in the interrupt priority limiter 230 of Figure 2). PIC2 (502) treats the interrupts for inter-processor communication in the same manner as the interrupts generated by peripherals 120a-m (Figure 1). Continuing with reference to Figures 5A and 5B, CPU2 (506) reads the interrupt source register 210 (Figure 2) for PIC2 (502) and executes the interrupt handler. After the interrupt handler is finished executing, the interrupt is cleared by CPU2 (506) writing to PIC2 (502). Following this write, Int_clrl (510b) is asserted, Int_to_cpu2 (504) is de-asserted, and Int_reql (510a) is de-asserted. PICl (501) is then ready to receive another write from CPU1 (505) to again set Int_reql (510a). However, writes to assert Int_reql (510a) cannot be completed while Int_clrl (510b) is asserted. This is necessary in order to ensure that the clear of the previous interrupt is complete.

Inter-processor communication in accordance with the present invention provides a number of advantages. First, it is safe and efficient. The CPU asserting the interrupt (e.g., CPU1 505) needs to perform only one write to its respective interrupt controller (e.g., PICl 501). The CPU that is interrupted (e.g., CPU2 506) reads the interrupt source register to determine the interrupt source and clears the interrupt when the handling is complete. CPU2 506 accomplishes this by reading and writing to PIC2 (502). Thus, in accordance with the present invention, long latency accesses across multiple bus systems is avoided. Second, inter-processor communication in accordance with the present invention is scaleable. Third, because inter-processor communication is asynchronous, it is not critical to establishing the timing or layout of the integrated circuit, facilitating the design of such circuits. In addition, because the interrupts for inter-processor communication are treated the same as the interrupts generated by the peripherals 120a-m (Figure 2), inter- processor communication can be readily handled in software, and in particular it can be handled with the software used to manage peripherals 120a-m.

In summary, the present invention provides an interrupt management system and method that can accommodate simpler and more efficient multi-bus designs. The present invention also provides an interrupt management system and method that can allow inter- processor communication. In addition, the present invention provides an interrupt management system and method that are flexible regarding the assignment of interrupts to processors (e.g., central processing units). Furthermore, the present invention provides an interrupt management system and method that can be designed and produced in a shorter period of time without placing burdensome timing and layout constraints on designers. The preferred embodiment of the present invention, an efficient interrupt system for system-on-a-chip design, is thus described. While the present invention has been described in particular embodiments, it should be appreciated that the present invention should not be construed as limited by such embodiments, but rather construed according to the following claims.

Claims

CLAIMS:

An interrupt management system (10) comprising: a plurality of peripheral devices (120a, 120b, ..., 120m) adapted to generate interrupts; a plurality of processors (100a, 100b, ..., lOOn) coupled in a single integrated circuit and coupled to said plurality of peripheral devices such that each processor can - communicate to all peripheral devices; and a plurality of interconnected interrupt controllers (110a, 110b, ..., 1 lOn) coupled between said plurality of processors and said plurality of peripheral devices, wherein said interrupt controllers cause an interrupt generated by one of said peripheral devices to be passed to a particular processor of said plurality of processors.

2. The interrupt management system of Claim 1 wherein said interrupt generated by said one of said peripheral devices is routed to all interrupt controllers.

3. The interrupt management system of Claim 1 wherein the number of processors and the number of interrupt controllers are equal.

4. The interrupt management system of Claim 3 wherein each interrupt controller is paired with a single processor.

5. The interrupt management system of Claim 4 wherein an interrupt controller paired with a processor is adapted to determine which interrupts generated by peripheral devices are to be passed to said processor.

6. The interrupt management system of Claim 1 wherein an interrupt controller is adapted to store information identifying a peripheral device that generated an interrupt to be passed to said particular processor.

7. The interrupt management system of Claim 6 wherein said particular processor identifies said peripheral device in a single read access.

8. The interrupt management system of Claim 1 wherein an interrupt controller is adapted to store information identifying a priority ranking of said peripheral devices.

9. The interrupt management system of Claim 1 wherein said interrupt controllers pass an interrupt generated by a processor of said plurality of processors to another processor of said plurality of processors.

10. An interrupt management system (10) comprising: an interrupt controller (110a) coupled between a processor (100a) and a plurality of peripheral devices (120a, 120b, ..., 120m), said interrupt controller comprising: a first register (220) comprising information for identifying which interrupts - generated by said peripheral devices are to be passed to said processor; and a second register (210) comprising information identifying a particular peripheral device associated with an interrupt to be passed to said processor, wherein said processor identifies said particular peripheral device in a single read access.

11. The interrupt management system of Claim 10 comprising a plurality of interconnected interrupt controllers (110a, 110b, ..., 1 lOn) coupled to said plurality of peripheral devices, wherein an interrupt generated by one of said peripheral devices is routed to all interrupt controllers.

12. The interrupt management system of Claim 11 comprising a plurality of processors (100a, 100b, ..., lOOn) in a single integrated circuit, said plurality of processors coupled to said plurality of interrupt controllers, said plurality of interrupt controllers also coupled to said plurality of peripheral devices such that each processor can communicate to all peripheral devices.

13. The interrupt management system of Claim 12 wherein said interrupt controllers pass an interrupt generated by one of said plurality of processors to another processor of said plurality of processors.

14. The interrupt management system of Claim 12 wherein the number of processors and the number of interrupt controllers are equal.

15. The interrupt management system of Claim 14 wherein each interrupt controller is paired with a single processor.

16. The interrupt management system of Claim 10 wherein said first register comprises information identifying a priority ranking of said peripheral devices.

17. A method (400) for managing interrupts comprising the steps of: a) (420) receiving at a plurality of interrupt controllers an interrupt generated by one of a plurality of peripheral devices, wherein said interrupt controllers are coupled to a plurality of processors; and b) (430) passing said interrupt to a single processor.

18. The method as recited in Claim 17 wherein the number of processors and the number of interrupt controllers are equal.

19. The method as recited in Claim 18 wherein each interrupt controller is paired with a single processor.

20. The method as recited in Claim 19 wherein said step b) comprises the step of: (410) receiving information at each interrupt controller, said information specific to an interrupt controller and sufficient for identifying which interrupts are to be passed to a processor paired with said interrupt controller.

21. The method as recited in Claim 20 wherein said information is a priority ranking of said peripheral devices.

22. The method as recited in 17 comprising the step of:

(440) storing information identifying a peripheral device that generated an interrupt, wherein said single processor identifies said peripheral device in a single read access.

23. The method as recited in Claim 17 comprising the steps of:

(450) passing an interrupt generated by one of said plurality of processors to another processor of said plurality of processors.