Method and apparatus for indicating interrupts

An interrupt mechanism is disclosed. In one embodiment an integrated circuit (IC) is coupled to a number of peripheral devices, via a bus, and includes an interface controller. The interface controller includes a bus engine circuit coupled to receive data from the various ones of the peripheral devices, wherein the data may include various requests. The bus engine circuit also includes decoding circuitry configured to decode the data to determine the nature of the requests. Responsive to determining that interrupt information is stored in one or more of the requests, the interrupt information may be written to one of a number of interrupt registers. An interrupt controller may read the interrupt registers to determine the presence of interrupts, and thus initiate the process to see that they are serviced.

BACKGROUND

Technical Field

This disclosure is directed to peripheral buses, and more particularly, to the handling of interrupt requests by devices coupled to a peripheral bus.

Description of the Related Art

Modern computer systems and devices typically include a number of peripheral devices coupled to an integrated circuit (IC), which in turn may implement one or more processor cores. Often times, these various peripheral devices may require servicing from functional circuitry on the IC (e.g., one of the processor cores). In order to obtain such servicing, the peripheral devices may assert interrupts. Additionally, in some systems, software may initiate interrupts.

Interrupts may be performed for various reasons. Such reasons include power management, a request for data, and so forth. Generally speaking, an interrupt may be asserted for any condition that requires immediate attention and cannot be handled by the asserting peripheral device.

With regard to the peripheral devices, circuitry on the IC may perform polling to determine the presence of interrupts that may have been asserted. In performing polling, circuitry on the IC may actively query the peripheral devices via a bus coupled thereto. Upon determining the presence of the interrupt through polling, servicing of the interrupt may be performed. Since the assertion of interrupts may occur asynchronously, polling for interrupts may be performed at frequent intervals.

SUMMARY

An interrupt mechanism is disclosed. In one embodiment an integrated circuit (IC) is coupled to a number of peripheral devices, via a bus, and includes an interface controller. The interface controller includes a bus engine, which is a bus interface circuit coupled to receive data from the various ones of the peripheral devices, wherein the data may include various requests. The bus engine circuit also includes decoding circuitry configured to decode the data to determine the nature of the requests. Responsive to determining that interrupt information is stored in one or more of the requests, the interrupt information may be written to one of a number of interrupt registers. An interrupt controller may read the interrupt registers to determine the presence of interrupts, and thus initiate the process to see that they are serviced.

In one embodiment, the interrupt controller may include interrupt handler circuitry to service the interrupts. Embodiments are also possible and contemplated wherein an interrupt may be handed off to another agent, e.g., from the interrupt handler to a processor core. In some embodiments, the interrupt registers may be implemented in banks, including a physical bank and virtual banks based on agents that are enabled to view interrupts in the physical bank. In such embodiments, particular interrupts may be assigned to various agents.

The method and apparatus embodiments described herein may allow the mapping of a number of interrupts into the data conveyed to the bus engine. Furthermore, by sending interrupts within data to the bus engine, the need for polling the different peripheral devices is eliminated.

Although the embodiments disclosed herein are susceptible to various modifications and alternative forms, specific embodiments are shown by way of example in the drawings and are described herein in detail. It should be understood, however, that drawings and detailed description thereto are not intended to limit the scope of the claims to the particular forms disclosed. On the contrary, this application is intended to cover all modifications, equivalents and alternatives falling within the spirit and scope of the disclosure of the present application as defined by the appended claims.

This disclosure includes references to “one embodiment,” “a particular embodiment,” “some embodiments,” “various embodiments,” or “an embodiment.” The appearances of the phrases “in one embodiment,” “in a particular embodiment,” “in some embodiments,” “in various embodiments,” or “in an embodiment” do not necessarily refer to the same embodiment. Particular features, structures, or characteristics may be combined in any suitable manner consistent with this disclosure.

In the following description, numerous specific details are set forth to provide a thorough understanding of the disclosed embodiments. One having ordinary skill in the art, however, should recognize that aspects of disclosed embodiments might be practiced without these specific details. In some instances, well-known circuits, structures, signals, computer program instruction, and techniques have not been shown in detail to avoid obscuring the disclosed embodiments.

DETAILED DESCRIPTION OF EMBODIMENTS

FIG. 1is a block diagram of one embodiment of a system including an integrated circuit (IC) and a number of peripheral devices coupled thereto. It is noted that the embodiment shown here is simplified for the sake of illustration, but is not intended to be limiting. For example, the number of peripheral devices shown here may be of a greater or lesser number that illustrated here. Any of the peripheral devices may perform functions that includes ones not explicitly discussed herein. Similarly, the number and types of functional circuit blocks of IC11may vary from what is explicitly illustrated here. It is further noted that the peripheral devices shown here, connected to IC via bus11, may not be the only peripheral devices in various embodiments of system10. Thus, embodiments are possible and contemplated in which other peripheral devices coupled by other buses

System10in the embodiment shown includes IC11, which is coupled to peripheral devices15A-15D. The peripheral devices15A-15D may each be one of a wide variety of peripheral devices. For example, one of peripheral devices15A-15D may be a radio unit that includes circuitry for transmitting and receiving radio signals, as well as other functions such as up conversion, down conversion, data formatting and so on. Similarly, another one of the peripheral devices15A-15D may perform various power management functions. In yet another example, one of peripheral devices15A-15D may be a display controller configured to perform various functions for displaying data and graphics on a display screen. These are only a few of many possible examples of peripheral devices that may be coupled to IC11.

Each of peripheral devices15A-15D is coupled to IC11by a bus18. In the embodiment shown, bus18is a shared bus. The bus may be a serial bus in one embodiment, although embodiments in which bus18is a parallel bus are also possible and contemplated. Data transfers between IC11and the peripheral devices15A-15D may be conducted over bus18, which in some embodiments may be a Serial Power Management Interface (SPMI) bus. SPMI bus18may be utilized in communications involving certain power management functions.

The processor cores are coupled to IC11at interface controller20, which may provide a number of different functions, some of which are discussed below. Interface controller20in this embodiment is coupled to two different processor cores, processor cores12and13. These processor cores may, in one embodiment, be different types of processor cores, e.g., one may be a high performance processor core while the other may be a high efficiency processor core. In another embodiment, these two processor cores may be of the same type. While shown as being directly connected to interface control20in this particular example, other connection mechanisms are possible and contemplated. For example, a switch fabric in which a number of functional circuit blocks are coupled to one another via dedicated point to point connections may be implemented in one embodiment. Embodiments implementing one or more crossbar switches are also possible and contemplated.

Although not explicitly shown here, other functional circuit blocks may also be included in IC11. For example, functional circuit blocks such as a graphics controller, a cache subsystem that is shared by the various processor cores, memory controller circuits, one or more service processors, and so forth, may be implemented on IC11. In one embodiment, IC11may implement a system-on-a-chip (SoC), and may thus include a large number and variety of functional circuit blocks.

FIG. 2is a block diagram illustrating one portion of an interface controller for one embodiment of IC10. In the embodiment shown, the processor cores (as shown inFIG. 1) are coupled to a bus interface201. The portion of interface controller20shown here may conduct various types of communications through bus interface201, including those that will be explicitly discussed herein. Bus18in the embodiment shown is coupled to a bus interface circuit, SPMI engine250, as bus18is an SPMI bus in this particular implementation. More generally, embodiments are possible and contemplated in which a bus interface engine of any type may be implemented in place of SPMI engine250, with a corresponding bus coupled thereto. Such embodiments are consider to fall within the scope of this disclosure.

The various peripheral devices may submits requests, via bus18, to SPMI engine250. The requests may be submitted in various formats. For example, in one embodiment a request may be sent in the form of a code having a certain number of bits indicating the nature of the request. SPMI engine250may include decoding circuitry251that may read the code to determine the type of request. Additionally, SPMI engine250may also include arbitration circuitry252configured to arbitrate between multiple requests when present. The arbitration scheme used may vary among different embodiments, and relative priority of requests may be considered when arbitrating.

SPMI engine250may output decoded requests to various destinations. Requests that require agents within IC10to provide an external response (e.g., respond to an agent external to IC10) may be output on the path labeled ‘External Responses’, to a demultiplexer, particularly RxDeMux218. A mapping circuit242may select one of external response queues212to which the request may be routed. The mapping circuit242may operate based on configuration information received from configuration circuit242. In one embodiment, mapping circuit242may route the request for external response to one of the external response queues212in accordance with an agent responsible for handling the request.

If the information received by SPMI engine250indicates an operational or protocol violation, the decoded request may be routed to both fault queue231and interrupt registers221. Fault queue231may log the operational or protocol violation. The interrupt registers221may store information indicative of the interrupt, which may be retrieved by a responsible agent for handling. The interrupt registers221, as will be discussed below, may include a number of separate registers. In one embodiment, the interrupt registers may be implemented in a manner to appear as multiple banks of registers such that individual agents are enabled or disabled to see certain interrupts depending on the agent responsible for handling these interrupts. The interrupt registers221may include registers to store interrupt requests submitted by any of the peripheral devices capable of asserting interrupts. Additionally, some interrupt registers may store interrupt requests that are initiated by software, e.g., such as software executing on a processor core.

Information may be read from the interrupt registers by interrupt controller222via IRO lines as shown (of which there are seven in this particular embodiment). Interrupt controller222may include interrupt handling circuitry enabling it to service some interrupts. Furthermore, interrupt controller222may hand off responsibility for servicing some interrupts that are stored in a register in one of the banks of duplicate registers. For example, responsibility for servicing certain interrupts in one case may be assigned to processor core, or another agent not explicitly shown herein. Furthermore, interrupt controller222may enable certain agents to view particular interrupts stored in interrupt registers221, while inhibiting other agents from viewing the same interrupts. For example, a particular interrupt may be assigned to be handled by processor core12. Interrupt controller222may enable processor core12to see the interrupt as stored in interrupt registers221, while inhibiting other agents (e.g., processor core13) from seeing the interrupt. In the embodiment shown, interrupt controller222may control which agents may view which interrupts through enable signals provided to the interrupt registers221. In other embodiments, interrupt controller222may provide signals to the agents themselves.

Interrupt controller222in the embodiment shown may be a part of interface controller20. However, embodiments are possible and contemplated in which interrupt controller222is implemented separate from interface controller20.

In addition to operational or protocol violations, SPMI engine250may, in the embodiment shown, output interrupt information for external to SoC master writes (e.g., a write from an external device to an agent on IC10), as well as information for requests to be completed with interrupts enabled. Embodiments in which interrupts under other categories are output by a bus engine to various interrupt registers are also possible and contemplated.

In addition to the various outputs mentioned above, SPMI engine250in the embodiment shown may also output an indication that a backlight request (e.g., associated with a display) has been completed.

Interface controller20in the embodiment shown includes a bus interface201coupled to other agents/functional circuit blocks in IC10, including processor cores12and13. At least some of the communications between agents external to IC10(e.g., peripheral devices) and agents internal thereto may be conducted through bus interface201. Requests requiring external responses may be conveyed from external response queues212, through bus interface201, to the appropriate agents within IC10.

Bus interface201in the embodiment shown is also coupled to a number of request queues211. Requests to external devices from agents within IC10may be routed through bus interface201to the request queues211. Furthermore, responses by internal agents to requests submitted from external agents may also be routed through bus interface201to request queues211. A multiplexer, TxMux217, may select a queue to route information from request queues211to SPMI engine250based on selection signals provided by arbitration circuit241. The arbitration performed by arbitration circuit241may use any suitable methodology of arbitration, and may consider the priority of information stored in various ones of the request queues. The methodology (or methodologies) of arbitration utilized by arbitration circuit241may be based at least in part on configuration information provided by configuration circuit240. The selected input of TxMux217may be routed through the multiplexer's output, to SPMI engine250. From there, SPMI engine250may convey the information onto bus18and thus to its intended destination.

The ability for peripheral devices to submit interrupt requests via the apparatus illustrated inFIG. 2may enable faster and more efficient handling of interrupts. In prior art embodiments, the presence of interrupt requests was determined by polling, e.g., by polling the peripheral devices. This polling would consume extra time, as another agent, e.g., an interrupt handler, would have to query each interrupt-capable device to determine the presence of interrupt requests. In various embodiments of the apparatus shown herein, the interrupts may be conveyed as requests to SPMI engine250and may subsequently be conveyed to the interrupt registers based on a relative priority. Thus, in lieu of a device having to wait until it is polled to convey an indication of an interrupt request, it may do so proactively in the various embodiments of the apparatus discussed herein.

FIG. 3is a block diagram illustrating interrupt registers implemented in a number of banks for one embodiment. In the embodiment shown, interrupt registers221are subdivided into four different banks, banks0-3. The number of banks may vary from one embodiment to another. Furthermore, the number of registers in each of the banks may also vary from one embodiment to the next. As noted above, the banks of interrupt registers may be duplicates of one another in one embodiment.

It is noted that, in the embodiment shown, only the registers of Bank0are actual physical registers. The registers of Banks1-3, in this embodiment may be considered views by various agents, hence the representation with dashed lines. An agent (e.g., a processor core) may have a view of interrupt stored in the physical registers if it is enabled to view them, or view a particular one of the physical interrupt registers. If a particular agent is not enabled to view the physical registers, or a particular one storing an interrupt, then as far as it is concerned there is no interrupt to be serviced. Thus, in the embodiment shown, the interrupt registers as shown here are implemented in one physical bank and multiple virtual banks, the virtual banks being based on which of the agents are allowed to view the physical registers (or portions thereof) at a given time).

The enabling of agents to view interrupt registers221may be accomplished in various ways. In one embodiment, a particular agent may be able to view the entirety of the physical interrupt registers (of Bank0) at a given time. In another embodiment, agents may be enabled to selectively view particular ones of the interrupt registers, or particular bit positions within a given register. Generally speaking, the granularity of views of the physical interrupt registers may vary from one embodiment to the next, and may further vary within a given embodiment.

FIG. 4is a flow diagram of one embodiment of a method for determining the presence of interrupts. Method400as shown herein may be performed by various embodiments of the apparatus discussed above. Furthermore, apparatus embodiments not explicitly discussed herein may also be capable of performing method400, and thus may fall within the scope of this disclosure.

Method400begins with the receiving of data from peripheral devices and/or from software (block405). The received data may be in the form of requests, which may be requests for data, general communications, interrupts, and so forth. The received data may be stored in request queues (block410). Thereafter, the data stored in the request queues may be decoded (block415). For example, using the embodiment ofFIG. 2above, a request stored in a request queue may be arbitrated and subsequently mapped to be received in an appropriate location.

If the decoding operation determines that interrupt request are present in decoded data (block420, yes), the interrupt request information may then be stored in interrupt registers (block425). Thereafter, the routing of interrupts to responsible agents and the servicing thereof may occur. If the decoded data does not include interrupts (block420, no), it may be stored or forwarded to other destinations (block430), as appropriate.

Turning next toFIG. 5, a block diagram of one embodiment of a system150is shown. In the illustrated embodiment, the system150includes at least one instance of an integrated circuit10coupled to external memory158. The integrated circuit10may include a memory controller that is coupled to the external memory158. The integrated circuit10is coupled to one or more peripherals154and the external memory158. A power supply156is also provided which supplies the supply voltages to the integrated circuit10as well as one or more supply voltages to the memory158and/or the peripherals154. In some embodiments, more than one instance of the integrated circuit10may be included (and more than one external memory158may be included as well).

The peripherals154may include any desired circuitry, depending on the type of system150. For example, in one embodiment, the system150may be a mobile device (e.g. personal digital assistant (PDA), smart phone, etc.) and the peripherals154may include devices for various types of wireless communication, such as WiFi, Bluetooth, cellular, global positioning system, etc. The peripherals154may also include additional storage, including RAM storage, solid-state storage, or disk storage. The peripherals154may include user interface devices such as a display screen, including touch display screens or multitouch display screens, keyboard or other input devices, microphones, speakers, etc. In other embodiments, the system150may be any type of computing system (e.g. desktop personal computer, laptop, workstation, tablet, etc.).

The external memory158may include any type of memory. For example, the external memory158may be SRAM, dynamic RAM (DRAM) such as synchronous DRAM (SDRAM), double data rate (DDR, DDR2, DDR3, LPDDR1, LPDDR2, etc.) SDRAM, RAMBUS DRAM, etc. The external memory158may include one or more memory modules to which the memory devices are mounted, such as single inline memory modules (SIMMs), dual inline memory modules (DIMMs), etc.