JP2004537809A - Efficient interrupt system for system-on-chip design - Google Patents

Abstract

A method and system for managing interrupt requests ("interrupts") in a system-on-a-chip design that can accommodate simpler and more efficient multi-bus designs and handle interrupts. To provide an interrupt management system and method that is capable of communicating between processors and is flexible in assigning interrupts to processors, and that facilitates integrated circuit design.
A method for managing interrupts in a system-on-chip design including a plurality of processors (100a, 100b, ..., 100n) coupled to a plurality of peripheral devices (120a, 120b, ..., 120m). The method (400) and the system (10). A plurality of interconnected interrupt controllers (110a, 110b, ..., 110n) are coupled between the processor and peripheral devices. Interrupts generated by peripheral devices are received by all interrupt controllers. In one embodiment, the interrupt controller is paired with the processor. Each interrupt controller can identify which interrupt to pass to its processor. The interrupt controllers work together to pass each interrupt to a particular processor.
[Selection diagram] Fig. 1

Description

[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates generally to the field of integrated circuits ("chips"). More specifically, the present invention relates to managing interrupts in a system-on-a-chip design that includes multiple processors and multiple peripheral devices.
[0002]
[Prior art]
"System-on-a-chip" architectures (eg, microcontrollers, microprocessors) are commonly used in applications such as audio systems, wireless systems, portable systems, data communication systems, Internet control systems, industrial / consumer systems, and the like. . System-on-a-chip architectures increase the efficiency of design and manufacturing, both for chip production and chip integration for specific applications.
[0003]
Some system-on-chip architectures utilize multiple CPUs (Central Processing Units) to improve performance. In the system-on-chip architecture, a plurality of buses typically arranged in a hierarchical arrangement can be used.
[0004]
In a system-on-a-chip architecture, the more complex the chip, the more problems arise. When there are a plurality of CPUs on a chip and a plurality of peripheral devices are supported by the chip, management of interrupt requests generated by the peripheral devices may be complicated. For example, an interrupt request may be generated simultaneously by a peripheral device. Interrupt requests must be processed individually and each request is sent to the CPU. Each CPU that processes an interrupt request needs to make an inquiry to each peripheral device in order to determine the device that generated the interrupt request. When the CPU receives a plurality of interrupt requests at the same time, it is necessary to arbitrate the conflict between the interrupt requests.
[0005]
Prior art approaches to managing interrupt requests in a multiple processor architecture have common drawbacks. Prior art interrupt management approaches may require complex and inefficient multi-bus designs. Further, in prior art approaches, processors may not be able to communicate with each other with respect to servicing interrupt requests. Also, in the prior art approach, certain interrupt requests may be assigned to a particular CPU in hardware, and thus the prior art approach is relatively fixed and less flexible. Further, prior art approaches may impose difficult timing and layout constraints on integrated circuit designers, and thus may increase the time required to design and produce integrated circuits.
[0006]
Therefore, there is a need for an interrupt management system and / or method that can accommodate simpler and more efficient multi-bus designs. There is also a need for an interrupt management system and / or method that can meet this requirement and that can communicate between processors to service interrupt requests. There is also a need for an interrupt management system and / or method that can meet this requirement and that is flexible with respect to assigning interrupt requests to CPUs. Further, there is also a need for an interrupt management system and / or method that can meet this requirement and facilitate the design of integrated circuits by not imposing unnecessarily heavy timing and layout constraints on the designer. Have been. The present invention provides a novel solution to these needs.
[0007]
[Means for Solving the Problems]
The present invention relates to a method and system for managing interrupt requests ("interrupts") in a system-on-chip design that includes multiple CPUs (eg, processors) coupled to multiple peripheral devices. The present invention provides an interrupt management system and / or method that can accommodate simpler and more efficient multi-bus designs. The present invention also provides an interrupt management system and method that can communicate between processors to handle interrupts. Further, the present invention provides a flexible interrupt management system and method for assigning interrupts to processors. Further, the present invention provides an interrupt management system and method that can facilitate integrated circuit design by not imposing unnecessarily heavy constraints on timing and layout on a designer.
[0008]
In accordance with the present invention, in a multiple processor architecture supporting multiple peripheral devices, multiple interconnected interrupt controllers are coupled between the processor and the peripheral device. Interrupt controllers operate in concert to pass interrupts to a particular processor. The interrupt controller can also be used for interprocessor communication if needed. That is, an interrupt generated by one processor can be transmitted to another processor via an interrupt controller.
[0009]
In one embodiment, the number of interrupt controllers is equal to the number of processors, and each interrupt controller is paired with one processor and vice versa. In such an embodiment, each interrupt controller includes an interrupt priority register (or similar memory device) that contains the priority of each of the peripheral devices. This information is unique to each interrupt controller, and the interrupt controller can use this information to determine whether or not to pass an interrupt to itself and a paired processor. The interrupt controller can also use this information to arbitrate between interrupts when two or more interrupts are received by the interrupt controller simultaneously.
[0010]
Each interrupt generated by a peripheral device is received by all interrupt controllers. Each interrupt controller uses the information described in the previous paragraph to identify whether to pass an interrupt to its paired processor. In this way, the interrupt controllers work cooperatively to pass interrupts to a particular processor.
[0011]
In one embodiment, each interrupt controller includes an interrupt priority limiter register (or similar memory device), which is set to the priority value of the interrupt currently being serviced. . In another embodiment, each interrupt controller includes an interrupt source register (or similar memory device), which has the highest priority and has a priority in the interrupt priority limiter register. Identify outstanding interrupts greater than the value. That is, the interrupt source register identifies the interrupt to be processed next. When processing this interrupt, the processor performs one read access to this register to identify the peripheral device that generated the interrupt.
[0012]
The inventive method and system for managing interrupts is scalable. It is easy to add a peripheral device, and it can be controlled by changing the description of the register transfer language (RTL) of the interrupt controller. Also, the present invention can be extended to include any number of processors. Further, any number of on-chip buses can be used.
[0013]
The interrupt controller can be programmed in software to map the interrupt to any processor. According to the present invention, nested interrupts (e.g., interrupts occur simultaneously or nearly simultaneously) are easily handled. For example, the processor only needs to perform one read access to identify the peripheral device from which the interrupt was generated, thereby improving the efficiency of interrupt processing.
[0014]
In addition, interrupts can be handled asynchronously, which facilitates the design and implementation of integrated circuits because the handling of interrupts is not critical in establishing the timing or layout of the integrated circuit.
[0015]
The above and other objects and advantages of the present invention will become apparent to those skilled in the art from a reading of the following detailed description of the preferred embodiment, as illustrated in the accompanying drawings.
[0016]
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.
[0017]
BEST MODE FOR CARRYING OUT THE INVENTION
Preferred embodiments of the present invention will be described in detail below. These embodiments are illustrated in the accompanying drawings. Although the present invention has been described with reference to preferred embodiments, it will be understood that these embodiments are not limiting of the invention. On the contrary, the invention is intended to cover alternatives, modifications, and equivalents, which are 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 apparent to one skilled in the art that the present invention may be practiced without these specific details. Well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the present invention.
[0018]
Some of the detailed descriptions that follow are presented using procedures, logic blocks, operations, 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 this application, a procedure, logic block, process, or the like, is understood to be an internally consistent sequence of steps or instructions leading to the required result. The step in this case is a step that requires physical manipulation of a physical quantity. Usually (but not always), these quantities take the form of electrical or magnetic signals that can be stored, transferred, combined, compared, and otherwise manipulated in a computer system. In some cases, it has proven convenient to refer to these signals as transactions, bits, values, elements, symbols, characters, fragments, pixels, etc., because they are commonly used.
[0019]
It should be noted, however, that all of these and similar terms relate to the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless otherwise indicated in the following description, “generate,” “communicate,” “pass,” “receive,” “send,” “store,” “identify,” or similar throughout the present invention. The description using the term refers to the operation and process of a computer system or similar electronic computing device (eg, process 400 of FIG. 4). A computer system or similar electronic computing device manipulates and represents data represented as physical (electronic) quantities in computer system memory, registers, or such other information storage, transmission or display devices. Deform.
[0020]
FIG. 1 is a block diagram showing an outline of an interrupt management system 10 according to one embodiment of the present invention. In this embodiment, interrupt management system 10 includes multiple processors (CPUs) 100a-n, multiple interrupt controllers 110a-n, and multiple peripheral devices 120a-m. According to this embodiment of the present invention, when one of the peripheral devices 120a-m generates an interrupt request ("interrupt"), the interrupt controller 110a-n issues this interrupt to one of the CPUs 100a-n. Work cooperatively to send. A more detailed description will be given later. As will become apparent, the interrupt management system 10 of the present invention is scalable and can accommodate any number of processors, interrupt controllers, and peripheral devices.
[0021]
The interrupt controllers 110a-n are interconnected and can communicate with each other (see also FIG. 3). Generally, CPUs 100a-n and interrupt controllers 110a-n reside within an integrated circuit (eg, they are representative elements of a system-on-chip architecture). However, it will be appreciated that some of the CPUs 100a-n and some of the interrupt controllers 110a-n may reside outside of the integrated circuit. Similarly, some or all of the peripheral devices 120a-m belong to an integrated circuit.
[0022]
Referring to FIG. 1, in one embodiment, the number of interrupt controllers is equal to the number of processors, and at least for interrupts, communication with the CPU is through the interrupt controller. In this embodiment, each interrupt controller 110a-n is paired with one CPU 100a-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 respect to interrupts, the interrupt controllers 110a-n communicate directly with each pair of CPUs 100a-n and communicate with another CPU via the paired interrupt controller with that CPU. I do. That is, for example, the interrupt controller 110a communicates directly with the CPU 100a, and communicates with the CPU 100b-n through another interrupt controller 110b-n. It should be noted that in this embodiment, the interrupt controllers 110a-n mainly control the flow and distribution of interrupts to the CPUs 100a-n, rather than the path for passing data to the CPUs 100a-n. Purpose.
[0023]
In one embodiment, each CPU 100a-n can communicate with each of the peripheral devices 120a-m via the on-chip bus 130. In one embodiment, CPUs 100a-n are coupled to register access bus 135 (see FIG. 2), which allows the CPU to read from and write to the interrupt controller registers. In one embodiment, interrupts generated by any of the peripheral devices 120a-m are sent to all interrupt controllers 110a-n. However, in alternate embodiments, instead of sending interrupts to all interrupt controllers, interrupts can be selectively sent to a subset of interrupt controllers 110a-n.
[0024]
Each interrupt controller 110a-n is programmed to recognize which interrupts should be passed to the respective (paired) CPU and which interrupts should not. The interrupt controllers 110a-n are programmed so that each of the peripheral devices 120a-m is to be processed. According to this programming, each interrupt controller 110a-n determines whether the interrupt received by itself should be passed to the paired CPU. For example, the interrupt controller 110a determines whether to pass an interrupt to the CPU 100a, and if so, the interrupt is passed to the CPU 100a; otherwise, it is not passed. Since all peripheral devices 120a-m are to be processed, interrupts generated by any one of the peripheral devices are processed by one of the interrupt controllers 110a-n and thus one of the CPUs 100a-n. Next, a supplementary explanation will be given with reference to FIG.
[0025]
FIG. 2 is a block diagram of one embodiment of the interrupt controller 110a according to the present invention. In this embodiment, the interrupt controller 110a includes a hardware having an interrupt source register 210, an interrupt priority register 220, a comparison logic block 225, an interrupt priority limiter 230, an AND gate 240, and an OR gate 250. Element. Because the function of the interrupt controller 110a is described in the context of these various elements, the interrupt controller 110a is not limited to the described embodiment, and may otherwise be modified to achieve the intended function. It will be appreciated that it can be configured.
[0026]
In this embodiment, the interrupt priority register 220 is a dynamic and configurable register that includes the priority assigned to each of the peripheral devices 120a-m (FIG. 1). Thus, in this embodiment, each interrupt controller 110a-n (FIG. 1) can be programmed using all priorities of the peripheral devices 120a-m. The information in the interrupt priority register 220 is specific to the interrupt controllers 110a-n. That is, the priority order of the peripheral devices 120a-m differs among the interrupt controllers 110a-n.
[0027]
According to the present invention, the priority order is provided to each interrupt controller 110a-n by software executed by one of the processors 100a-n (FIG. 1). In other words, each interrupt controller 110a is programmed using the unique priority order of peripheral devices 120a-m. The priority order used by a particular interrupt controller 110a-n and the priority order assigned to each of the peripheral devices 120a-m can be dynamically changed. As a result, the peripheral devices 120a-m can be assigned (mapped) to an arbitrary CPU 100a-n. By changing the mapping, the peripheral devices assigned to one interrupt controller (and CPU) can be assigned. It can be assigned to another CPU. Further, when peripheral devices are added or removed, the interrupt management system and method of the present invention can be easily updated, and thus the interrupt management system and method of the present invention can be scaled to any number of peripheral devices. It is. The present invention provides a flexible and scalable system and method for managing interrupts, since the mapping from peripheral devices to the CPU is provided in software and thus can be easily changed or extended.
[0028]
Referring to FIG. 2, for some peripheral devices, a priority order indicating that an interrupt of the peripheral device is not passed to the CPU 100a by the interrupt controller 110a is held in the interrupt priority register 220. For example, the priority of these peripheral devices held in the priority register 220 may be 0, or one or more bits defining that the priority of these peripheral devices may be overridden. is there. Thus, the priority order in the interrupt priority register 220 is used to define which peripheral device is assigned to the interrupt controller 110a and thus to the CPU 100a.
[0029]
For other peripheral devices, the priority order indicating that those interrupts are passed to the CPU 100a by the interrupt controller 110a is held in the interrupt priority register 220. By assigning different priorities to such peripheral devices, it is possible to indicate that interrupts from some peripheral devices take precedence over interrupts from other peripheral devices. As a result, when the interrupt controller 110a receives a plurality of interrupts 260 simultaneously or nearly simultaneously, the interrupt controller 110a may automatically arbitrate between the interrupts to select and process the highest priority interrupt. it can.
[0030]
In this embodiment, interrupt priority limiter 230 is a dynamic and configurable register that is set by software to the priority value of interrupt 270 currently being processed by interrupt controller 110a. With this setting, the interrupt priority limiter 230 specifies a threshold based on the interrupt 270 currently being processed by the interrupt controller 110a.
[0031]
In one embodiment, nested interrupts can be handled as follows. When the next interrupt 260 is received by the interrupt controller 110a, the comparison logic block 225 compares the priority of the next (later) interrupt with the priority of the interrupt 270 currently being serviced. In this embodiment, comparison block 225 provides a signal to AND gate 240 based on the comparison. If the priority of the later interrupt is higher than the threshold specified by the interrupt priority limiter 230, an enable signal (eg, active "1") is passed to the AND gate 240 and the later interrupt is sent to the CPU. Passed to 100a, the interrupt priority limiter 230 is updated by software with the new threshold. If the priority of the later interrupt is lower than the threshold specified by the interrupt priority limiter 230, the later interrupt will not be passed to the CPU 100a. Thus, according to the present invention, nested interrupts are easily handled. Therefore, in this embodiment of the present invention, the interrupt with the highest priority, not necessarily the interrupt that arrived first, is processed by the CPU 100a. The process of examining the priority of the interrupt and comparing the priority to a threshold is performed once for each interrupt 260 received by the interrupt controller 110a.
[0032]
In one embodiment, OR gate 250 functions to provide only one interrupt to CPU 100a. Depending on the design of the CPU, there are cases where a plurality of interrupt inputs are possible and cases where only one interrupt input is possible. Thus, OR gate 250 allows interrupt controller 110a to be used with any type of CPU design.
[0033]
With further reference to FIG. 2, interrupt source register 210 includes information identifying the peripheral device 120a-m (FIG. 1) that generated the next interrupt to be processed by CPU 100a. Interrupt source register 210 identifies the pending interrupt having the highest priority and a priority greater than the value in interrupt priority limiter register 220. Thus, interrupt source register 210 identifies the next interrupt to be serviced. Therefore, the CPU 100a reads the interrupt source register 210 and determines the peripheral devices 120a-m to be processed next. Therefore, instead of accessing each of the peripheral devices 120a-m, the CPU 100a can make this determination only by accessing the interrupt source register 210 once instead of accessing each of the peripheral devices 120a-m. This improves the efficiency of the interrupt processing process. The CPU 100a can access the peripheral device that generated the interrupt using the on-chip bus 130 (FIG. 1).
[0034]
After servicing the interrupt, CPU 100a clears the interrupt in the peripheral device. As a result, the interrupt is deasserted in interrupt controller 110a and CPU 100a.
[0035]
Importantly, interrupt controllers 110a-n generally have only combinational logic between interrupt inputs and interrupt outputs. This allows an interrupt to be passed to each CPU 100a-n without a clock in the interrupt controller. In accordance with this embodiment of the present invention, interrupts can be handled asynchronously, thus facilitating the design of such circuits because the handling of interrupts is not critical in establishing the timing or layout of the integrated circuit. .
[0036]
FIG. 3 is a block diagram in which details of interconnection between blocks in the interrupt management system 10 of FIG. 1 are added. Specifically, FIG. 3 illustrates a bus that allows interrupt controllers 110a-n, and thus CPUs 100a-n, to communicate with one another in accordance with one embodiment of the present invention. However, it will be appreciated that other bus configurations having different numbers and types of buses may be utilized in accordance with the present invention.
[0037]
In this embodiment, on-chip bus 130 allows each CPU 100a-n to communicate with peripheral devices 120a-m. Further, in one embodiment, CPUs 100a-n are each coupled to a register access bus 135. The register access bus 135 allows each CPU to access the interrupt source register 210 of FIG. Accordingly, each CPU can determine the peripheral device 120a-m that has generated the interrupt to be processed next in one read access.
[0038]
In this embodiment, interrupt request bus 330 provides a communication path for transmitting interrupts from one interrupt controller to another interrupt controller, and thus from one CPU to another. Therefore, each CPU can request the support of another CPU when necessary. Interrupt request bus 330 also provides a communication path for transmitting interrupts from peripheral devices 120a-m to interrupt controllers 110a-n. The interrupt clear bus 320 is a bus for clearing an interrupt after it has been processed (executed).
[0039]
Generally, when an interrupt controller receives an interrupt request from a CPU, the interrupt request is processed in the same manner as an interrupt request received from a peripheral device. That is, the priority is associated with the interrupt request from the CPU, and the interrupt controller processes the interrupt request according to the priority. The priority can be based on the CPU that generated the interrupt or on the peripheral device that generated the interrupt requesting the CPU to generate the interrupt. Interrupt requests can be passed from one interrupt controller to the next until an interrupt controller (and its CPU) that can handle the interrupt is found. The protocol for inter-processor communication will be further described later with reference to FIGS. 5A and 5B.
[0040]
FIG. 4 is a flowchart of the steps in one embodiment of a process 400 for managing interrupts according to the present invention. In one embodiment, process 400 is performed by interrupt controllers 110a-n in FIG. It will be understood that the steps in process 400 can be performed in a different order than that presented in this figure, and that not all steps in process 400 need be performed.
[0041]
In step 410 of FIG. 4, with reference also to FIGS. 1 and 2, in this embodiment, each interrupt controller 110a-n identifies an interrupt to pass to the CPU 100a-n associated with each interrupt controller. To receive enough information. In one embodiment, each interrupt controller 110a-n is programmed using the priority order of peripheral devices 120a-m. The priority order is unique to each interrupt controller 110a-n and is used by each interrupt controller and CPU pair to identify the peripheral device whose interrupt is passed to the CPU by the interrupt controller.
[0042]
In one embodiment, the priority order is stored in the interrupt priority register 220 of each interrupt controller 220. The priority order stored in the interrupt priority register 220 may be, for example, when additional peripheral devices are coupled to the CPUs 100a-n or changing the mapping from the peripheral devices 120a-m to the CPUs 100a-n. Can be changed dynamically if desired.
[0043]
In step 420 of FIG. 4, and with reference also to FIGS. 1 and 2, in this embodiment, an interrupt 260 is received by all of the interrupt controllers 110a-n. In one embodiment, it is assumed that the interrupts generated by peripheral devices 120a-m will not fail.
[0044]
In step 430 of FIG. 4, in one embodiment, each of the interrupt controllers 110a-n (FIG. 1) uses the priority order programmed in step 410 above to interrupt the respective (paired) CPU. To determine if it should be passed. If the interrupt is enabled (i.e., the priority of the interrupt is other than 0) and the priority of the interrupt is greater than the threshold specified in the interrupt priority limiter 230 of FIG. The controller passes an interrupt to the paired CPU.
[0045]
At step 440 in FIG. 4, in this embodiment, information identifying the peripheral device that has generated the interrupt to be processed next by the CPU is stored in the interrupt source register 210 of FIG. The CPU (specifically, the CPU's interrupt handler) can read the interrupt source register 210. The CPU can read the status of the interrupt from the peripheral device that generated the interrupt based on the interrupt source register. The status information provides the CPU with enough information to handle the interrupt. After executing the interrupt, the CPU clears the interrupt in the peripheral device, and as a result, the interrupt is deasserted to the interrupt controller and the CPU.
[0046]
In step 450 of FIG. 4, if the CPU is busy and needs assistance from another CPU, an interrupt is generated by the first CPU and the interrupt is sent to the second CPU via the respective interrupt controller. You can pass. This is further explained below with reference to FIGS. 5A and 5B.
[0047]
FIG. 5A is a data flow diagram illustrating inter-processor communication via interrupt controllers PIC1 (501) and PIC2 (502) according to one embodiment of the present invention. For simplicity, interprocessor communication is described in the context of two processors. However, interprocessor communication can be extended to any number of processors. A plurality of signals 510 are passed between the interrupt controllers PIC1 (501) and PIC2 (502) to enable inter-processor communication. The signal 510 includes an interrupt request signal (eg, Int_req [p-0] and Int_req [r-0]) and an interrupt clear signal (eg, Int_clr [p-0] and Int_clr [r-0]). Communication between processors via the interrupt controller is performed asynchronously.
[0048]
FIG. 5B is a timing diagram for inter-processor communication (IPC), such as that illustrated in FIG. 5A. Referring to both FIG. 5A and FIG. 5B, CPU1 (505) sets Int_req1 (510a) by writing to interrupt controller PIC1 (501) to start a request for interprocessor communication. This causes the interrupt controller PIC2 (502) to assert Int_to_cpu2 (504) (if the interrupt priority is higher than the threshold in the interrupt priority limiter 230 of FIG. 2). PIC2 (502) handles interprocessor communication interrupts in the same manner as interrupts generated by peripheral devices 120a-m (FIG. 1).
[0049]
5A and 5B, CPU2 (506) reads the interrupt source register 210 (FIG. 2) of PIC2 (502) and executes the interrupt handler. After the execution of the interrupt handler is completed, the interrupt is cleared by CPU2 (506) writing to PIC2 (502). After this write, Int_clr1 (510b) is asserted, Int_to_cpu2 (504) is deasserted, and Int_req1 (510a) is deasserted. At this point, PIC1 (501) is ready to receive another write from CPU1 (505) to set Int_req1 (510a) again. However, the writing for asserting Int_req1 (510a) cannot be completed while Int_clr1 (510b) is asserted. This is necessary to ensure that the clearing of the previous interrupt has been completed.
[0050]
Inter-processor communication according to the present invention provides a number of advantages. First, this interprocessor communication is secure and efficient. The CPU asserting the interrupt (eg, CPU1 505) need only execute one write to each interrupt controller (eg, PIC1 501). The interrupting CPU (eg, CPU2 506) reads the interrupt source register to determine the source of the interrupt, and clears the interrupt when the processing is completed. CPU2 506 accomplishes this by reading and writing to PIC2 (502). Therefore, according to the present invention, access with a long waiting time via the multi-bus system is avoided. Second, interprocessor communication according to the present invention is scalable. Third, the inter-processor communication is asynchronous and thus is not critical in establishing the timing or layout of the integrated circuit, facilitating the design of such circuits.
[0051]
Further, interprocessor communication interrupts are handled in the same manner as interrupts generated by peripheral devices 120a-m (FIG. 2), so that interprocessor communication can be easily handled in software, and in particular, peripheral devices 120a-m. Can be handled by the software used to manage it.
[0052]
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 capable of performing interprocessor communication. In addition, the present invention provides a flexible interrupt management system and method for assigning interrupts to processors (eg, CPUs). Further, the present invention provides an interrupt management system and method that can be designed and manufactured in a shorter time without imposing heavy timing and layout constraints on a designer.
[0053]
The above is a description of a preferred embodiment of the present invention (an efficient interrupt system for system-on-chip design). Although the invention has been described in particular embodiments, the invention is not limited to such embodiments, but is to be construed in accordance with the appended claims.
[Brief description of the drawings]
FIG. 1 is a block diagram showing an outline of an interrupt management system according to an embodiment of the present invention.
FIG. 2 is a block diagram of one embodiment of an interrupt controller according to the present invention.
FIG. 3 is a block diagram with additional details of interconnection between blocks in the interrupt management system of FIG. 1;
FIG. 4 is a flowchart of steps in a process for managing interrupts, according to one embodiment of the present invention.
FIG. 5A is a data flow diagram illustrating inter-processor communication via an interrupt controller, according to one embodiment of the present invention.
FIG. 5B is a timing diagram of inter-processor communication, such as that illustrated in FIG. 5A.
[Explanation of symbols]
10 Interrupt management system
100a-n processor
110a-n interrupt controller
120am peripheral device
130, 135 bus
210 Interrupt source register
220 Interrupt Priority Register
225 Comparison logic block
230 Interrupt priority limiter
240 AND gate
250 OR gate
260, 270 interrupt
320 Clear interrupt bus
330 Interrupt request bus
400 process
410, 420, 430, 440, 450 steps
510 signal

Claims (23)

An interrupt management system, wherein the system comprises:
-A plurality of peripheral devices adapted to generate interrupts;
-A plurality of processors coupled within one integrated circuit and coupled to the plurality of peripheral devices so that each processor can communicate with all peripheral devices;
Interconnected interrupt controllers coupled between the processors and the peripheral devices, the interrupts being generated by one of the peripheral devices by processing of the interrupt controllers; And an interrupt controller, which is passed to a specific processor among the plurality of processors. The interrupt management system of claim 1, wherein an interrupt generated by the one of the peripheral devices is sent to all interrupt controllers. 2. The interrupt management system according to claim 1, wherein the number of said processors is equal to the number of said interrupt controllers. 4. The interrupt management system of claim 3, wherein each interrupt controller is paired with one processor. 5. The interrupt management system of claim 4, wherein the interrupt controller paired with the processor is adapted to determine which interrupt generated by the peripheral device to pass to the processor. The interrupt management system of claim 1, wherein the interrupt controller is adapted to store information identifying a peripheral device that generated the interrupt to pass to the particular processor. 7. The interrupt management system of claim 6, wherein the particular processor identifies the peripheral device in a single read access. The interrupt management system of claim 1, wherein the interrupt controller is adapted to store information identifying a priority of the peripheral device. The interrupt management system according to claim 1, wherein the interrupt controller passes an interrupt generated by one of the plurality of processors to another of the plurality of processors. An interrupt management system, wherein the system comprises:
An interrupt controller coupled between the processor and the plurality of peripheral devices, the interrupt controller comprising:
-A first register having information for identifying which interrupt generated by the peripheral device is to be passed to the processor;
A second register having information identifying a particular peripheral device associated with the interrupt to be passed to the processor, wherein the processor identifies the particular peripheral device in a single read access; When,
An interrupt management system having an interrupt controller. 11. The interrupt management system of claim 10, comprising a plurality of interconnected interrupt controllers coupled to the plurality of peripheral devices, wherein an interrupt generated by the peripheral device is sent to all interrupt controllers. 12. The interrupt management system of claim 11, comprising a plurality of processors in a single integrated circuit, wherein the plurality of processors are coupled to the plurality of interrupt controllers, and wherein the plurality of interrupt controllers are configured such that each processor has all peripherals. An interrupt management system coupled to the plurality of peripheral devices so as to communicate with the device. 13. The interrupt management system of claim 12, wherein the interrupt controller passes an interrupt generated by one of the plurality of processors to another of the plurality of processors. 13. The interrupt management system according to claim 12, wherein the number of said processors is equal to the number of said interrupt controllers. 15. The interrupt management system of claim 14, wherein each interrupt controller is paired with one processor. The interrupt management system of claim 10, wherein the first register has information identifying a priority order of the peripheral device. A method for managing interrupts, the method comprising:
a) receiving an interrupt generated by one of the plurality of peripheral devices at a plurality of interrupt controllers coupled to the plurality of processors, the interrupt controller being coupled to the plurality of processors; , Steps and
b) passing the interrupt to one processor;
A method comprising: 18. The method of claim 17, wherein the number of processors and the number of interrupt controllers are equal. 19. The method of claim 18, wherein each interrupt controller is paired with one processor. Step b) is
Receiving information at each interrupt controller, the information being specific to the interrupt controller and being sufficient to identify which interrupt to pass to the processor paired with the interrupt controller; 20. The method of claim 19, comprising the steps of: 21. The method of claim 20, wherein the information is a priority order of the peripheral device. 18. The method of claim 17, wherein the method comprises:
Storing information identifying the peripheral device that generated the interrupt, wherein the one processor identifies the peripheral device in a single read access;
A method comprising: 18. The method of claim 17, wherein the method comprises:
-Passing the interrupt generated by one of said plurality of processors to another of said plurality of processors.

Images