JP5710712B2 - Centralized interrupt controller - Google Patents

Description

  The present invention relates to an electronic circuit for controlling interrupts or interrupts. More particularly, the present invention relates to an Advanced Programmable Interrupt Controller that is centralized for multiple processing units.

  The processing unit underlying the performance of the computer system performs several processes including control of various intermittent “services” requested by peripheral devices connected to the computer system. Input / output (I / O) peripheral devices, including computer items such as printers, scanners, display devices, etc., require the host processor to provide intermittent service to ensure proper functionality. For example, the service includes data transmission, data capture and / or control signals.

  Each peripheral device typically has a different service delivery schedule that depends not only on the device type, but also on its programmed use. The host processor multiplexes the provision of services between devices according to its own request while executing one or more background programs. At least two methods for advising the service host had to be used: polling and interrupt methods. In the former method, each peripheral device is periodically checked to confirm whether a flag indicating a service request is set. In the latter method, the device service request is forwarded to an interrupt controller capable of interrupting the host and a branch from its current program to a special interrupt service routine is executed. The interrupt method is effective because the host does not need to allocate unnecessary clock cycles for polling. It is this latter method that the present disclosure focuses on.

  With the advent of multiprocessor computer systems, interrupt management systems that dynamically distribute interrupts between processors have been realized. APIC (Advanced Programmable Interrupt Controller) is an example of a multiprocessor interrupt management system. The APIC interrupt transmission mechanism used in many multiprocessor computer systems detects an interrupt request from another processing unit or peripheral device and indicates that a specific service corresponding to the interrupt request needs to be executed. It is used to notify the above processing unit. Further details regarding the APIC interrupt transmission system are described in US Pat. No. 5,283,904, “Multiprocessor Programmable Interrupt Controller System” by Carson et al.

  Many conventional APICs are designed with a large number of hardware and therefore require a large number of gates (ie, high gate counts). In many multiprocessor systems, each core has its own dedicated APIC that is completely self-contained within the core. In other multiprocessor systems, each core is a simultaneous multithreaded core with multiple logical processors. In such a system, each logical processor is associated with an APIC, each multithreaded core has multiple APIC interrupt transmission mechanisms, each mechanism maintaining its own architectural state and generally controlling all other APICs. Realize own control logic that is the same as logic. For any type of multiprocessor system, the cost of die area and leakage power for multiple APICs can be undesirably large. Further, because of the transmission of interrupts in a multiprocessor system, the dynamic power cost associated with the operation of multiple APICs can also be desirably high.

  An object of the present invention is to provide an advanced programmable interrupt controller that is centralized for a plurality of processing units.

  In order to solve the above-described problem, an aspect of the present invention performs a priority and control function for providing an interrupt message for a plurality of processing units, and a single logic block shared by the plurality of processing units; An interrupt sequencer block connected to the logic block for scheduling interrupt events of the plurality of processing units for processing by the logic block; and a storage area for maintaining respective architecture interrupt state information of the plurality of processing units; An apparatus having one or more input message queues for receiving an input interrupt message and placing information from the message in the storage area and one or more output message queues for transmitting an output interrupt message .

  According to the present invention, an advanced programmable interrupt controller can be provided that is centralized for a plurality of processing units.

FIG. 1 is a block diagram illustrating at least one embodiment of a centralized interrupt controller that provides interrupt control for a plurality of processing units. FIG. 2 is a block diagram illustrating further details of at least one embodiment of a centralized interrupt controller. FIG. 3 is a block diagram showing various embodiments of the multi-sequencer system. FIG. 4 is a block diagram illustrating at least one embodiment of a central repository in a multiple core interrupt state. FIG. 5 is a state transition diagram illustrating at least one embodiment of the operation of the interrupt sequencer block of the centralized interrupt controller. FIG. 6 is a block diagram illustrating at least one embodiment of a computing system capable of performing the disclosed techniques.

  In the following, selected embodiments of a method, system and product for centralized APIC of a plurality of processing units are described. Each mechanism described herein is utilized by a single core or multi-core multi-thread system. In the following, numerous specific details such as processor type, multi-threaded environment, system configuration, and the number and type of sequencers in a multi-sequencer system are provided to provide a more complete understanding of the present invention. However, it will be understood by one skilled in the art that the present invention may be practiced without such specific details. Furthermore, well-known structures, circuits, etc., are not described in detail so as not to unnecessarily obscure the present invention.

  FIG. 1 is a block diagram illustrating at least one embodiment of a system 100 having a centralized interrupt controller 110. The system 100 includes a plurality of cores 104 (0) to 104 (n). The dashed lines and ellipses in FIG. 1 indicate that the system 100 can have any number n (n ≧ 2) cores. Those skilled in the art will recognize that other embodiments of the system can have a single simultaneous multi-threading (SMT) core (so that n = 1), as described below. There will be.

  FIG. 1 shows that a single centralized interrupt controller 110 is physically separated from the cores 104 (0) -104 (n). FIG. 1 also shows that each core 104 (0)-104 (n) of the system 100 is connected to a centralized interrupt controller 110 via the local interconnect 102. The centralized interrupt controller 110 interfaces with each processing core via the local interconnect 102. The high-level purpose of the centralized interrupt controller 110 is to make the operation of multiple APICs serially so that the APIC appears to the system 100 as if it were operating in parallel as in a conventional core-based APIC system. To imitate.

  A single core 104 of the system 100 can implement any of a variety of multithreading schemes including simultaneous multithreading (SMT), switch on event multithreading (SoeMT), and / or time multiplexed multithreading (TMUX). is there. If instructions from multiple hardware thread contexts (logical processors) are executed on the processor 304 at any point in time, it is called SMT. Alternatively, in a single core multithreading system, the processor pipeline is multiplexed between multiple hardware thread contexts, but only instructions from one hardware thread context are executed in the pipeline at a given time. Implement SoeMT. For SoeMT, if the thread switch event is time-based, it will be TMUX. Single cores that support SoeMT and TMUX can support multithreading, but they are referred to as “single thread” cores. This is because only instructions from one hardware thread context are executed at any given time.

  Each core 104 is a single processing unit capable of executing a single thread. Alternatively, one or more cores 104 are multi-threading cores that perform SoeMT or TMUX multi-threading so that instructions for one thread are executed only when the core 104 is present. In such an embodiment, the core 104 is referred to as a “processing unit”.

  In at least one other embodiment, each core 104 is a multi-threaded core, such as an SMT core. For the SMT core 104, each logical processor of the core 104 is referred to as a “processing unit”. As used herein, a “processing unit” is any physical or logical unit that can execute a thread. Each processing unit has next instruction pointer logic to determine the next instruction to be executed for a given thread. The processing unit is used synonymously with “sequencer”.

  For either embodiment (single thread core and multi-thread core), each processing unit is provided by a centralized interrupt controller 110 where the logic of its interrupt controller functionality is not self-contained within each processing unit. If so, it is associated with the function. If any core 104 is an SMT core, each logical processor in each core 104 is connected to a centralized interrupt controller 110 via a local interconnect 102.

  Referring to FIG. 3, as described above, a processing unit (or “sequencer”) is a logical or physical processor. In FIG. 3, the difference between the logical processing unit and the physical processing unit is shown. FIG. 3 is a block diagram illustrating selected hardware configurations of multi-sequencer system embodiments 310 and 350 capable of performing the disclosed techniques.

  FIG. 3 shows a selected hardware configuration for a single core multi-sequencer multi-threading environment 310. FIG. 3 also illustrates a selected hardware configuration of a multi-core multi-threading environment 350 where each sequencer is an independent physical processor core.

In single-core multithreading environment 310, a single physical processor 304 is made to appear as multiple logical processors that are referenced by the LP ₁ ~LP _n to the operating system and user programs (not shown). Each logical processor LP ₁ -LP _n maintains a complete set of architectural states AS ₁ -AS _n , respectively. This architectural state has most of the data registers, segment registers, control registers, debug registers and model specific registers for at least one embodiment. The logical processors LP ₁ -LP _n share most other resources of the physical processor 304 such as caches, execution units, branch predictors, control logic, and buses. However, each logical processor LP ₁ -LP _n is associated with its own APIC.

  Although multiple hardware configurations are shared, each thread context in the multithreading environment 310 can independently generate the next instruction address (and, for example, from an instruction cache, an execution instruction cache, or a trace cache, etc. Fetch can be performed). Thus, the processor 304 has a logically independent next instruction pointer fetch logic 320 that fetches the instructions of each thread context even if multiple logical sequencers can be implemented in a single physical fetch / decode unit 322. . In the single-core multithreading embodiment, the term “sequencer” includes at least some of the thread context's associated architectural state 312 along with at least the next instruction pointer fetch logic of the thread context. It should be noted that the sequencer of single core multithreading system 310 need not be symmetric. For example, two single-core multithreading sequencers of the same physical core differ in the amount of architecture state information they maintain.

  Thus, in at least one embodiment, multi-sequencer system 310 is a single core processor 304 that supports simultaneous multi-threading. For such an embodiment, each sequencer is a logical processor with the same physical processor core 304 executing all thread instructions, but with its own next instruction pointer fetch logic and its own architecture state information. For such an embodiment, a logical processor may maintain a version of its architectural state, although the execution resources of a single processor core may be shared among threads executing simultaneously.

  FIG. 3 also illustrates at least one embodiment of a multi-core multi-threading environment 350. Such an environment 350 has two or more independent physical processors 304a-304n each capable of executing different threads / shreds so that execution of at least some of the different threads / shreds can proceed simultaneously. Each processor 304a-304n has a physically independent fetch unit 322 to fetch instruction information for its own thread or shred. In an embodiment where each processor 304a-304n executes a single thread / shred, the fetch / decode unit 322 implements a single next instruction pointer fetch logic 320. However, in embodiments where each processor 304a-304n supports multiple thread contexts, fetch / decode unit 322 implements different next instruction pointer fetch logic 320 for each supported thread context. The optional nature of the additional next instruction pointer fetch logic 320 in the multiprocessor environment 350 is illustrated in FIG.

  For at least one embodiment of the multi-core system 350 shown in FIG. 3, each sequencer may be a processor core 304 having multiple cores 304a-304n in a single chip package 360. Each core 304a-304n is a single thread or multi-thread processor core. Chip package 360 is indicated by a dashed line in FIG. 3 to indicate that the illustrated single chip embodiment of multi-core system 350 is merely an example. In other embodiments, the processor cores of a multi-core system reside on separate chips. That is, the multi-core system is a multi-socket symmetric multi-processing system.

  For simplicity of explanation, the following description focuses on an embodiment of the multi-core system 350. However, this focus should not be construed as limiting in that the mechanisms described below can be executed in either multi-core or single-core multi-sequencer environments.

  Referring to FIG. 1, it can be seen that the cores 104 (0)-104 (n) of the system 100 can be connected to each other via the local interconnect 102. The local interconnect 102 provides all communication functions (cache snoop, etc.) required between cores. Each core 104 (0)-104 (n) has a relatively small interface block for sending and receiving interrupt-related messages over the local interconnect 102. In general, such an interface of the core does not maintain the architectural state for interrupt-related messages and it does not perform other related functions performed by the centralized interrupt controller 110 described herein. Or is not relatively prioritized, so it is relatively simple.

  Cores 104 (0) -104 (n) may be on a single die 150 (0). For at least one embodiment, the system 100 shown in FIG. 1 further includes an optional additional die. The optional nature of one or more additional dies (˜150 (n)) is indicated in FIG. 1 by dashed lines and ellipses. FIG. 1 shows that an interrupt message from a processing unit on the other die (150 (n)) is communicated to the first die (150 (0)) via the system interconnect. The centralized interrupt controller 110 is connected to any other die (˜150 (n)) and peripheral I / O devices 114 via the system interconnect 106.

  Those skilled in the art will recognize that the configuration of the die 150 shown in FIG. 1 is merely an example and should not be construed as limiting. In other embodiments, for example, both 150 (0) and 150 (n) elements reside in the same silicon portion and are connected to the same local interconnect 102. On the other hand, each core 104 does not necessarily have to reside on the same chip. Each core 104 (0) -104 (n) and / or local interconnect 102 is not resident on the same die 150.

  Each core 104 (0)-104 (n) of the system 100 is further connected to other system interface logic 112 via the local interconnect 102. Such logic 112 includes, for example, cache coherence logic or other interface logic that allows the sequencer to interface with other system elements via the system interconnect. Other system interface logic 112 is further connected to other system elements 116 (such as memory) via system interconnect 106.

  FIG. 2 is a block diagram illustrating further details of at least one embodiment of the centralized interrupt controller 110. In general, FIG. 2 shows that the centralized interrupt controller 110 is physically separate from the core of the system (such as cores 104 (0) -104 (n) of FIG. 1), but the centralized interrupt controller 110 indicates that the complete architectural state of each APIC instance associated with each sequencer is maintained. A centralized interrupt controller 110 manages all of the interrupt queuing and prioritization functions normally handled by a dedicated APIC per core of conventional systems. As described in detail below, the centralized interrupt controller 110 also acts as a firewall between the rest of the system connected to the system interconnect 106 and the sequencer.

  FIG. 2 shows that the centralized interrupt controller 110 has a centralized APIC state 202. The APIC state 202 includes architectural states that are typically associated with typical APIC processing. That is, APIC processing is architecturally visible to application programmers, and such an interface is not intended to be modified by the present disclosure. Regardless of whether the system has conventional APIC hardware (ie, one self-contained APIC for each processing unit) or a centralized interrupt controller as described herein, for at least one embodiment, this It is expected that such hardware design choices should be transparent to the application programmer. In this way, the area, dynamic power, and power leak costs are utilized by the system's single centralized interrupt controller 110 while simultaneously maintaining the same architectural interface expected by operating system vendors and application programmers. Can be reduced.

For this reason, the architectural state maintained as the central repository of APIC state information in block 202 is generally the state maintained for each APIC in conventional systems. For example, if there are 8 sequencers in the system, the centralized APIC state 202 includes an array of 8 entries reflecting the architectural APIC state where each entry is maintained for the sequencer of the conventional system. (The description of FIG. 4 below indicates that each entry also includes a specific microarchitecture state.)
For at least one embodiment, the centralized APIC state 202 is implemented as a single memory storage area, such as a register file or an array. The register file structure enables better area efficiency than the conventional approach that realized the core unit APIC state as random logic.

  In general, the centralized interrupt controller 110 monitors receipt of interrupt messages received via the local interconnect 102 and / or the system interconnect 106 and stores messages associated with the appropriate entries in the register file 202. In at least one embodiment, this is accomplished by monitoring the destination address of the incoming message and storing the message in the APIC instance entry associated with the destination address. Such functions are performed by the input message queues 204, 206, as will be described in detail below.

  Similarly, the centralized interrupt controller 110 monitors the generation of output interrupt messages and stores the messages in the appropriate entries in the register file 202 until such messages are serviced and transmitted. In at least one embodiment, this is accomplished by monitoring the source address of the outgoing message and storing the message in the APIC instance entry associated with the source address. Such functions are performed by the output message queues 208, 210, as described in detail below.

  In general, the interrupt sequencer block 214 of the centralized interrupt controller 110 then schedules pending interrupt messages to be reflected in the centralized APIC state 202 for service. As explained in detail below, this is accomplished according to a fairness scheme so that any pending interrupt operations of the sequencer are not repeatedly ignored. The interrupt sequencer block 214 calls the APIC interrupt providing logic 212 to execute the service.

  FIG. 2 shows that the centralized interrupt controller 110 has APIC interrupt providing logic 212. Rather than duplicating the APIC logic of each sequencer in the system (such as each logical processor in the SMT core or each single-threaded core), the centralized interrupt controller 110 services the interrupt for all sequencers in the system, so the APIC logic 212 single non-redundant copies are provided.

  For example, if a system (such as system 100 of FIG. 1) has four cores, each supporting eight simultaneous SMT threads, the system conventionally requires 32 copies of APIC logic 212. On the other hand, the centralized interrupt controller 110 shown in FIG. 2 utilizes a single copy of APIC logic 212 to provide interrupt controller services to all 32 active threads at a given time. .

  APIC logic 212 receives contention from multiple sequencers because multiple sequencers in the system may have pending interrupt operations at the same time. For this reason, the centralized interrupt controller 110 has an interrupt sequencer block 214. The interrupt sequencer block 214 sequences the services of all interrupts in the system so as to provide fair access to each sequencer of the APIC logic 212. The interrupt sequencer block 214 of the centralized interrupt controller 110 controls access to a single APIC logic block 212.

  Thus, interrupt sequencer block 214 controls sequencer access to shared APIC logic 212. This feature is in contrast to conventional APIC systems that provide a dedicated APIC logic block for each sequencer so that each sequencer has direct ad hoc access to the APIC logic. The single APIC logic block 212 provides APIC's complete architectural requirements for interrupt prioritization, such as each processing unit of the system.

  For any processing unit in the system, the source / destination of the interrupt passing through the APIC can be another processing unit or a peripheral device. Intra-die processing unit interrupts are provided by a centralized interrupt controller 110 via the local interconnect 102. Interrupts to peripheral devices or processing units on other dies are provided via the system interconnect 106.

  FIG. 2 illustrates four message queues, input system message queue 204, input local message queue 206, output local message queue 208, and output system message queue 210, for processing input / output interrupt messages via local interconnect 102 and system interconnect 106. It has shown that. Input local message queue 206 and output local message queue 208 are connected to local interconnect 102, and input system message queue 204 and output system message queue 210 are connected to system interconnect 106. Each queue 204, 206, 208, 210 is a mini-controller queue that has data storage with control logic.

  A further description of the operation of the queues 204, 206, 208, 210 will be made with reference to FIGS. FIG. 4 provides a detailed view of at least one embodiment of the centralized APIC state 202. FIG. 4 shows that the centralized APIC state 202 has both microarchitecture states 301, 303 along with architecture state 302. As described above, the architectural state 302 maintained for each sequencer 104 (0) -104 (n) reflects the APIC state associated with the sequencer. Each entry 410 in the architecture APIC state 302 is referred to herein as an “APIC instance”. For example, an APIC instance input interrupt message is stored in the entry 410 of the architecture APIC state 302 associated with the instance. For at least one embodiment, up to 240 input interrupt messages are maintained in entry 410 of the APIC instance.

  In addition to the architecture state 302, the centralized APIC state 202 has a microarchitecture state 301 for each APIC instance 410 along with a general microarchitecture state 303. The general microarchitecture state 303 determines which sequencer the interrupt sequencer block 214 (see FIG. 2) needs to access the APIC logic 212 (see FIG. 2). It has a scoreboard 305 to help. In at least one embodiment, scoreboard 305 maintains a bit for each sequencer in the system. The value of the sequencer bit indicates whether the sequencer has any pending action that is required by the APIC logic 212. In at least one embodiment, the scoreboard 305 is atomic so that the interrupt sequencer block 214 (FIG. 2) can easily and quickly determine which sequencer needs access to the APIC logic 212. Is read.

  One feature of the interrupt sequencer block 214 is that it allows fair access to the APIC logic 212, but the scoreboard 305 allows the sequencer block 214 not to simultaneously process the APIC logic 212. Allows fairness schemes to be used without requiring processing resources to be wasted. Thus, the scoreboard tracks which APIC instances have work to perform based on the input message and the current state of processing of the issued request. The interrupt sequencer block 214 reads the current state from the centralized APIC state 202 for the active APIC instance and records the current state (as recorded in both the architectural state 302 and the microarchitecture state 301 of the APIC instance 410). Then take the appropriate action, then repeat the process for the next APIC instance with pending work (as indicated by the bits on the scoreboard 305).

  When an input interrupt message is submitted to another sequencer on the same die via the local interconnect 102, the input local message queue 206 receives this message and determines its destination. The interrupt message can be targeted to one, many or all of the sequencers, or none of them. The queue 206 writes to each sequencer's architecture state entry (such as 410 in FIG. 4) to queue up the interrupt. In such a case, if the scoreboard entry has not already been set to indicate that the interrupt action is pending and the service of the single APIC logic block 212 is required for the target sequencer, the queue 206 will also Set the scoreboard entry for the target sequencer.

  However, FIG. 4 shows that some interrupts are bypassed directly from the input local message queue 206 to the output queues 208, 210 without being queued up in the centralized APIC state 202. This may occur, for example, for broadcast messages that are not specifically addressed to a particular processor. FIG. 4 shows that a similar bypass process is also performed from the input system message queue 204 (described below).

  A process similar to that described above for queue 206 is also provided by one of the sequencers 104 (0) -104 (n) where the input interrupt message is routed via system interconnect 106 (from an I / O device or sequencer on another die). This is done when a target is entered. The input system message queue 204 receives a message and determines the destination of the message. The queue 206 writes up to the architecture state entry 410 of each targeted sequencer to queue up the interrupt and update the scoreboard entry 412 of any targeted sequencer. Of course, the input message is bypassed as described above.

  One or more of the message queues 204, 206, 208, 210 may implement an input / output message firewall function. With respect to this firewall function, FIG. 2 is described together with FIG.

  For input messages, the input system message queue 204 may function as an interrupt firewall to avoid unnecessary processing of messages that are not targeted to the sequencer on the die 150 associated with the centralized interrupt controller 110. As shown in FIG. 1, the system 100 has a plurality of multi-sequencer dies 150 (0) -150 (n). Interrupts generated by a particular die's sequencer are sent to other dies via the system interconnect 106. Similarly, interrupts generated by peripheral device 114 are transmitted to the die via system interconnect 106.

  The centralized interrupt controller 110 (and input system message queue 204) of the die 150 determines whether the destination address of such a message has any sequencer (such as a core or logical processor) on the die 150. To do. If the message is not intended for any core or logical processor on the local interconnect 102 associated with the die, the input system message queue 204 refuses to forward the message to any of the sequencers on the local interconnect 102. In this way, the input system message queue simply determines that no action is required, thus avoiding the “waking” of the core / thread. This saves power and saves local interconnect 102 bandwidth. This is because it eliminates the need for each sequencer to wake up from the power saving state just to determine that the message is not intended for them.

  Even if one or more logical processors are not in a power saving state, the input system message queue 204 is currently executing by the logical processor to simply determine that the input interrupt message requires no action on their part. The firewall function is executed so that the logical processor is not interrupted from the work.

  For at least one embodiment, a firewall is also implemented for outgoing messages. This is true for output local messages as well as output system messages for at least one embodiment. For at least one embodiment, the local message firewall configuration does not require that each message on the local interconnect 102 be delivered to all sequencers, but the targeted interrupt message is provided to a particular sequencer. It is implemented only for systems having a local interconnect 102 that supports a configuration that enables this. In such a case, the output local message queue 208 transmits each interrupt message as a unicast or multicast message via the local interconnect 102 only to the sequencer targeted by the message. Thus, sequencers that are not targeted do not need to interrupt their processing to determine that their actions are not required in the interrupt message. Output system messages are similarly targeted so that they are not unnecessarily sent to entities that are not targeted.

  FIG. 2 illustrates that after an input interrupt message is placed in the APIC state 202 centralized by the input message queues 204, 206, the interrupt sequencer block 214 performs APIC processing of the system to execute the APIC logic 212 (FIG. 2). Show fair access between each sequencer of the system to one copy of (see). The interrupt sequencer block 214 actually implements this fairness scheme by traversing the APIC state 202 sequentially and providing access to the next sequence of APIC logic 212 that requires it. The fairness scheme implemented by the interrupt sequencer block 214 allows each sequencer to have equal access to the interrupt providing block.

  For at least one embodiment, the conceptual sequential stepping via the APIC state 202 entry is made more efficient by utilizing a scoreboard (see 305 in FIG. 4). Are queried atomically to determine which active sequencer next needs the APIC service. For at least one embodiment, sequential access can be controlled according to the method described in more detail below in connection with FIG.

  FIG. 5 illustrates an interrupt sequencer block 214 (to provide equitable access to each sequencer of the system to one copy of APIC logic 212 (see FIG. 2) to perform the APIC processing of the system. FIG. 3 is a state diagram illustrating a method 500 utilized by at least one embodiment of (see FIG. 2). The following description of FIG. 5 is made with reference to FIGS.

  Overall, FIG. 5 shows that the interrupt sequencer block 214 reads the current state from the centralized APIC state 2020 of the active APIC instance, takes action appropriate to the current state, and has the next APIC instance with pending work. Indicates that the process is repeated.

  FIG. 5 shows that the method 500 starts at state 502. In state 502, interrupt sequencer block 214 queries scoreboard 305 to determine which APIC instances have work to perform. As described above, there is one entry 412 in the scoreboard 305 for each APIC instance. The entry 412 is a 1-bit entry in at least one embodiment. Bit 412 is set when an incoming message is written to the centralized APIC state 202 of the APIC instance.

  Of course, those skilled in the art will recognize that the scoreboard 305 is a performance enhancement that need not be present in all embodiments. For at least one other embodiment, for example, the interrupt sequencer block 214 may query each entry in the centralized APIC state 202 in order (eg, sequential) to determine which active APIC instance requires service. Traverse.

  If none of the scoreboard 305 bits are set, no sequencer has a pending APIC event. In such a case, method 500 transitions from state 502 to 508. In state 508, method 500 powers down at least a portion of APIC logic block 212 to power savings while logic 212 is not required. Once power down is complete, method 500 transitions to state 502 to determine if a new APIC operation is detected.

  In state 502, if no new action is detected (ie, no entry in scoreboard 305 is set) and APIC logic 212 has already been powered down, method 500 waits for a new APIC action. Therefore, the state 502 is shifted to 506.

  During the wait state 506, the method 500 periodically evaluates the content of the scoreboard 305 to determine which APIC instance has acquired pending APIC work. An input APIC message as reflected in the content of the scoreboard 305 causes a transition from state 506 to 502. The above description of the input local message queue 204 and the input system message queue 206 indicates that the architecture APIC state 302 and, in at least some embodiments, that an entry in the scoreboard 305 has acquired an APIC work pending. Explain how it is updated to reflect.

  Method 500 determines that at least one APIC instance has pending APIC work to perform if any entry 412 of scoreboard 305 is set in state 502. If a plurality of such entries are set, the interrupt sequencer block 214 determines which APIC instance will receive the service next by the APIC logic 212. In at least one embodiment, interrupt sequencer block 214 performs the determination by selecting the next set scoreboard entry. In this manner, interrupt sequencer block 214 imposes a fairness scheme by sequentially selecting the next active APIC instance for access to APIC logic 212.

  Upon selecting an APIC instance in state 502, method 500 transitions from block 502 to 504. At block 504, the interrupt sequencer block 214 reads the selected virtual APIC entry 410 from the centralized APIC state 302. Thus, interrupt sequencer block 214 determines which APIC events are pending for the selected APIC instance. Multiple APIC events may be pending and are reflected in APIC entry 410. During each iteration of state 504, only one pending event is processed for the APIC instance. This maintains a round robin type sequential fairness scheme.

  In order to select from multiple pending interrupt events for the same active APIC instance, interrupt sequencer block 214 performs prioritization in state 504. Such prioritization processing emulates a prioritization scheme that is executed by a dedicated APIC of a conventional system. For example, APIC interrupts are defined to fall into each class of importance. The architecture state entry 410 (FIG. 4) for each APIC instance holds up to 240 pending interrupts per logical processor in at least one embodiment. These can belong to 16 importance classes and fall into 16 prioritized groups. Class 16-31 interrupts have higher priority than classes 32-47. The lower the interrupt class number, the higher the interrupt priority. Thus, the interrupt sequencer block 214 observes 240 bits of the APIC instance and, if multiple, sets only one event in the state 504 (based on APIC's existing architecture priority rules). In at least one embodiment, interrupt sequencer block 214 calls APIC logic 212 to perform this prioritization.

  Thereafter, the method 500 schedules or performs actions appropriate for the selected event in state 504. For example, this event is waiting for an acknowledgment for an interrupt message previously sent from one of the output message queues. Alternatively, the event is that an output interrupt message needs to be sent. Or, for one of the sequencers, an input interrupt message or acknowledgment needs to be serviced. Interrupt sequencer block 214 activates APIC logic 212 to service the event in state 504.

  If an acknowledgment is waiting, interrupt sequencer block 214 queries microarchitecture state 303 to determine that such an acknowledgment is waiting. If so, interrupt sequencer block 214 queries the appropriate entry in APIC state 202 to determine if an acknowledgment was received in state 504. Otherwise, exit from state 504 to process the next sequencer event.

  If an acknowledgment is received, the microarchitecture state 303 is updated to reflect that the acknowledgment is no longer waiting. The interrupt sequencer block 214 also clears the APIC instance scoreboard 305 entry before returning to state 502. In at least one embodiment, the scoreboard 305 entry is cleared only if the currently serviced event is the only APIIC instance pending event.

  In another example, if the event serviced in state 504 is a transmission of an interrupt message (via the local interconnect 102 or system interconnect 106), such event is serviced in state 504 as follows. The interrupt sequencer block 214 determines which output messages need to be provided from the APIC instance of the currently serviced logical processor given the above priority processing. The output message is then scheduled for transmission to the appropriate output message queue (output local message queue 208 or output system message queue 210) along with the desired destination address.

  If the outgoing message requires additional services, such as receipt of an acknowledgment, before the event is fully serviced, the centralized controller 110 indicates that additional services are required for the event. Therefore, the microarchitecture state 303 is updated. (Input acknowledgments via the local interconnect 102 or the system interconnect 106 are queued up in the input message queues 204, 206 so that they can eventually be processed in the next iteration of the associated APIC instance state 504. , Updated to the centralized APIC state 202. The method then transitions from state 504 to 502.

  FIG. 6 illustrates at least one embodiment of a multi-threaded computing system 900 capable of performing the disclosed techniques. The computing system 900 includes at least one processor core 904 (0) and a memory system 940. System 900 has an additional core (˜904 (n)) as indicated by dashed lines and ellipses.

  The memory system 940 includes a large, relatively slow memory storage 902 with one or more small, relatively fast caches such as an instruction cache 944 and / or a data cache 942. The memory storage 902 stores instructions 910 and data 912 for controlling the operation of the processor 904.

  The memory system 940 is intended as a generalized representation of memory, such as hard drives, CD-ROMs, RAM (Random Access Memory), DRAM (Dynamic RAM), SRAM (Static RAM), flash memory and related circuitry It has various types of memory. Memory system 940 stores instructions 910 and / or data 912 represented by data signals that can be executed by processor 904. Instructions 910 and / or data 912 include code and / or data for performing any or all of the techniques described herein.

  FIG. 6 shows that each processor 904 is connected to a centralized interrupt controller 110. Each processor 904 has a front end 920 that provides instruction information to the execution core 930. The fetched instruction information is buffered in the cache 225 for waiting for execution by the execution core 930. The front end 920 supplies instruction information to the execution core 930 in program order. In at least one embodiment, front end 920 includes a fetch / decode unit 322 that determines the next instruction to be executed. In at least one embodiment of system 900, fetch / decode unit 322 has a single next instruction pointer fetch logic 320. However, in embodiments where each processor 904 supports multiple thread contexts, the fetch / decode unit 322 implements different next instruction pointer fetch logic 320 for each supported thread context. The optional nature of additional next instruction pointer fetch logic 320 in a multiprocessor environment is illustrated by the dashed lines in FIG.

  Each embodiment of the method described herein may be implemented by hardware, hardware emulation software or other software, firmware, or a combination of such implementation approaches. Embodiments of the present invention can be implemented for a programmable system having at least one processor, a data storage system (including volatile and non-volatile memory and / or storage elements), at least one input device and at least one output device. It is. For this application, a processing system includes any system having a processor such as a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), or a microprocessor.

  The program may be a storage medium or device readable by a general purpose or special purpose programmable processing system (hard disk drive, floppy disk drive, ROM (Read Only Memory), CD-ROM device, flash memory device, DVD ( (Digital Versatile Disk) or other storage device). The instructions accessible to the processor of the processing system configure and execute the processing system when the storage medium or device is read by the processing system to perform the procedures described herein. Each embodiment of the present invention is also considered to be implemented as a machine-readable storage medium configured for use by a processing system, and the storage medium configured as such provides the functionality described herein to the processing system. It is executed by a specific and predetermined method for execution.

  The exemplary system 900 is available from Intel Corporation, although other systems (including other microprocessors, engineering workstations, personal digital assistants, other portable devices, set-top boxes, etc.) are also available. Pentium (R), Pentium (R) Pro, Pentium (R) II, Pentium (R) III, Pentium (R) 4, Itanium (R), Itanium (R) 2 Microprocessor, Mobile It represents a processing system based on Intel (R) Pentium (R) III Processor-M, Mobile Intel (R) Pentium (R) 4 Processor-M. In one embodiment, the exemplary system runs a version of the Windows operating system available from Microsoft Corporation, although other operating systems and graphical user interfaces are also available.

  While particular embodiments of the present invention have been illustrated and described, it would be obvious to those skilled in the art that various changes and modifications can be made without departing from the scope of the appended claims. For example, at least one embodiment of the centralized APIC state 202 includes only a single read port and a single write port. In such an embodiment, input system message queue 204, input local message queue 206, and interrupt sequencer block 214 utilize arbitration logic (not shown) to gain access to centralized APIC state 202. .

  Also, for example, at least one embodiment of the method 500 shown in FIG. Those skilled in the art will recognize that state 508 only provides performance enhancement (power saving) and is not required for the claimed invention embodiments.

  It has also been mentioned above that, for example, at least one embodiment of the centralized interrupt controller 110 described above may exclude the scoreboard 305. In such an embodiment, interrupt sequencer 214 sequentially traverses architecture APIC state 302 entry 410 to determine the next APIC instance to receive service from APIC logic 212.

  Thus, those skilled in the art will recognize that various changes and modifications can be made in the broadest aspects thereof without departing from the invention. The appended claims are intended to include within their scope all such changes and modifications as fall within the true scope of the present invention.

100 system 104 core 110 interrupt controller 359 multi-core threading environment

Claims (24)

A single logic block that performs priority and control functions for providing interrupt messages to multiple processing units;
A storage area having an array including a plurality of entries to maintain architectural interrupt state information of the plurality of processing units;
An interrupt event for the plurality of processing units connected to the storage area, querying the storage area, determining architecture interrupt status information of the plurality of processing units, connected to the logic block, and for processing by the logic block; An interrupt sequencer block, wherein each interrupt event has one of a plurality of classes of importance and is obtained from an input interrupt message;
An input interrupt message is received via one of a system interconnect connected to another system resource and a local interconnect connected to the plurality of processing units, and information from the input interrupt message is arranged in the storage area. One or more input message queues;
One or more output message queues for transmitting an output interrupt message scheduled by the interrupt sequencer block via one of the system interconnect and the local interconnect;
Having a device.   The apparatus of claim 1, wherein the single logic block comprises non-redundant circuitry that provides an interrupt for each processing unit.   The apparatus of claim 1, wherein the interrupt sequencer block schedules interrupt events for the plurality of processing units for provision according to a fairness scheme.   4. The apparatus of claim 3, wherein the interrupt sequencer block schedules interrupt events of the plurality of processing units according to a sequential traversal of the storage area.   The apparatus of claim 1, further comprising a scoreboard for maintaining data regarding which of the processing units have pending interrupt events.   The apparatus of claim 1, wherein the storage area further stores microarchitecture state information including APIC microarchitecture state information and per-instance microarchitecture APIC state information.   The apparatus of claim 1, wherein the plurality of processing units communicate via a local interconnect. The one or more input message queues include a message queue for receiving an input interrupt message via the local interconnect;
The apparatus of claim 7, wherein the one or more output message queues comprise a message queue for sending output interrupt messages over the local interconnect. The one or more input message queues include a message queue for receiving an input interrupt message via a system interconnect;
The apparatus of claim 7, wherein the one or more output message queues comprise a message queue for transmitting output interrupt messages over the system interconnect.   The apparatus of claim 1, wherein the one or more output message queues further comprise firewall logic for prohibiting one or more transmissions of the output interrupt message.   The apparatus of claim 1, wherein the one or more input message queues further comprise firewall logic for prohibiting one or more transmissions of the input interrupt message to one or more of the processing units.   The apparatus of claim 1, wherein the one or more input message queues further comprise firewall logic that prohibits the transmission of one or more of the input interrupt messages to one or more of the processing units. Querying a storage array including a plurality of entries to determine an architecture interrupt state of the plurality of processing units;
Scheduling interrupt events for the plurality of processing units for processing by non-redundant interrupt providing blocks, wherein processing by the non-redundant interrupt providing logic is prioritized for providing interrupt messages for the plurality of processing units. And performing the control function, the scheduling step comprising:
A method comprising:
The scheduling is performed according to a fairness scheme that allows each processing unit to access the interrupt providing block equally.   The method of claim 13, wherein the interrupt providing block comprises advanced programmable interrupt controller logic.   The method of claim 13, wherein the fairness scheme is a sequential round robin scheme for the processing unit having one or more pending interrupt events. A plurality of processing units executing one or more threads;
A memory connected to the processing unit;
A shared interrupt controller that provides an interrupt providing service for the plurality of processing units;
A system comprising:
The shared interrupt controller is:
A single logic block that performs prioritization and control functions for providing interrupt messages to a plurality of processing units, the single logic block being shared among the plurality of processing units;
A storage area including an array having a plurality of entries to maintain architectural interrupt state information of the plurality of processing units;
An interrupt event for the plurality of processing units connected to the storage area, querying the storage area, determining architecture interrupt status information of the plurality of processing units, connected to the logic block, and for processing by the logic block; An interrupt sequencer block for scheduling
One or more input message queues for receiving an input interrupt message and placing information from the input interrupt message in the storage area;
One or more output message queues for sending output interrupt messages;
Having a system.   The system of claim 16, wherein the shared interrupt controller further provides an APIC interrupt providing service for the plurality of processing units.   The system of claim 16, wherein the processing unit does not have self-contained APIC interrupt providing logic.   The system of claim 16, wherein the shared interrupt controller further comprises firewall logic.   The system of claim 16, further comprising a local interconnect connected to the plurality of processing units.   21. The system of claim 20, wherein the shared interrupt controller further comprises firewall logic that prohibits transmission of one or more interrupt messages over the local interconnect.   The system of claim 16, further comprising a system interconnect connected to the shared interrupt controller.   23. The system of claim 22, wherein the shared interrupt controller further comprises firewall logic that prohibits transmission of one or more interrupt messages over the system interconnect.   The system of claim 16, wherein the shared interrupt controller further schedules an interrupt serial service between the plurality of processing units.

Images