2.3.1. Interrupt types

This section describes the different types of interrupt that the GIC-500 handles.

SGIs

SGIs are inter-processor interrupts, that is, interrupts generated from one core and sent to other cores. Activating an SGI on one core does not affect the same interrupt ID on another core. Therefore when an SGI is sent to all cores it is handled independently on each core. The settings for each SGI are also independent between cores.

You can generate SGIs using System registers in the generating core, or, in legacy software, by writing to the Software Generated Interrupt Register, GICD_SGIR. There are 16 independent SGIs, ID0-ID15, that are recorded separately for every target core. In backwards compatibility mode, the number of the generating core is also recorded.

PPIs

PPIs are typically used for peripherals that are tightly-coupled to a particular core. Interrupts connected to the PPI inputs associated with one core are only sent to that core. Activating a PPI on one core does not affect the same interrupt ID on another core. The settings for each PPI are also independent between cores.

A PPI is an interrupt that is specific to a single core and is generated by a wire input. PPI signals are active-LOW level-sensitive, by default, but can also be programmed to be triggered on a rising edge.

SPIs

SPIs are typically used for peripherals that are not tightly-coupled to a specific core. You can program each SPI to target either a particular core or any core. Activating an SPI on one core activates the SPI for all cores. That is, the GIC-500 allows at most one core to activate an SPI. The settings for each SPIs are also shared between all cores.

SPIs can be generated either by wire inputs or by writes to the AXI4 slave programming interface. The GIC-500 can support up to 960 SPIs corresponding to the external spi[991:32] signal. The number of SPIs available depends on the implemented configuration. The permitted values are 32-960, in steps of 32. The first SPI has an ID number of 32. You can configure whether each SPI is triggered on a rising edge or is active-HIGH level-sensitive.

Note

All signals, including SPIs, must be synchronous to the clock. Therefore, you must synchronize any interrupt signals from an asynchronous source before they are connected to the GIC-500.

LPIs

LPIs are typically used for peripherals that produce message-based interrupts. An LPI targets only one core at a given time. LPIs are generated when the peripheral writes to the ITS, which also holds the registers to control the generation and maintenance of LPIs. The ITS provides interrupt ID translation, allowing peripherals to be owned directly by a virtual machine if a System MMU is also present for those peripherals.

Note

The interrupt ID translation in the ITS only allows interrupts from these peripherals to be translated to the ID space of the hypervisor, not sent directly to the virtual machine.

In the GIC-500, you can only generate LPIs by writing to the ITS using the AXI4 slave programming interface. The GIC-500 always supports up to 57344 LPIs, but has a cache that holds the settings for the most frequent interrupts. The settings for the ITS and LPIs are stored in main memory, so a cache miss might result in up to three round trips to memory. The first LPI has an ID number of 8192.

You can debug problems with LPI interrupt generation in the ITS using the LPI tracking registers. These allow you to set a trigger to capture information about the next interrupt that the ITS processes. This allows you to determine what happened to that interrupt and what translation was applied. See Implementation defined test registers in the GITS control page summary for more information.

For the most efficient caching of LPIs, ARM recommends that you allocate input interrupt IDs sequentially. You can measure the performance of the cache the input interrupt ID affects using the GITS_TRKICR register. See Debug ITE Cache Statistics for more information. The other LPI cache is only affected by the distribution of LPI physical IDs (PIDs). Therefore, if possible, ARM recommends that for best caching, PIDs are also sequentially allocated. The performance of that cache can be monitored using the GITS_TRKLCR register. See Debug LPI Cache Statistics for more information.

Choosing between LPIs and SPIs

You can use both LPIs and SPIs for message-based interrupts. Your decision about whether to use an LPI or SPI for an interrupt can potentially be made by software, providing there are spare SPIs and the GIC-500 is integrated with ITS support. This can be achieved by either making the peripheral write to a different GIC-500 address, or by changing the address translation for the interrupt write in the System MMU. Changing only the System MMU is possible because the two registers for Non-secure message-based interrupts, GICD_SETSPI_NSR and GITS_TRANSLATER, are at the same address offset in different pages. The following factors can help you to decide which type of interrupts is most appropriate:

  • Only the ITS provides interrupt ID translation and therefore LPIs are preferable for peripherals owned by a virtual machine. This is because the hypervisor can let the virtual machine program the peripheral directly, and let the ITS convert its interrupts from the IDs used by the virtual machine to unique physical IDs.

  • LPIs are always Group 1 Non-secure, so message-based interrupts that target Secure software must use SPIs.

  • Only SPIs provide the ability to target all cores, which means the GIC-500 attempts to automatically balance the interrupt load to cores that are active but not handling other interrupts.

  • The GIC-500 can provide a far larger number of LPIs than SPIs for the same area. The marginal area increase for each additional LPI is much less than for an SPI because the LPI settings are only cached, not stored, in the GIC-500. This means that the lowest area can often be achieved by using LPIs where possible rather than SPIs.

  • In a small system where the features of the ITS are not required and there are few message-based interrupts, you might decide not to include the ITS and LPI support.

  • SPIs usually have a better worst-case interrupt latency than LPIs. This is because SPIs have all their settings stored internally to the GIC-500, whereas LPIs that are not cached require external memory accesses. The cache hit rate is expected to be higher for the LPIs that occur more frequently. Therefore ARM recommends that SPIs are used for any latency sensitive interrupts that are expected to occur infrequently.

Copyright © 2014 ARM. All rights reserved.ARM DDI 0516B
Non-ConfidentialID060914