Our example SoC requires an external Generic Interrupt Controller (GIC). Both the GIC-400 and GIC-500 are external. This SoC benefits from the inclusion of a GIC-500, which is based on a later architecture than the GIC-400 and provides more advanced interrupt options.
The GIC-500 is based on the GICv3 architecture. The GIC-500 receives interrupts from, for example, a GPIO, UART, or a peripheral. Depending on how the GIC-500 is configured, the interrupts are managed and distributed to up to 32 clusters in an SoC. Each cluster can have up to eight cores. The GIC-500 interfaces with clusters rather than cores. Interrupts are, however, directed to specific cores, and the GIC-500 receives notification when a core activates them.
The GIC-500 can support 960 Shared Peripheral Interrupts (SPIs). These SPIs reach the GIC-500 from peripherals through physical inputs on standard interrupt lines.
The GIC-500 can receive up to 16 Software Generated Interrupts (SGIs). These SGIs are received through the programmable slave interface of the GIC-500.
The GIC-500 also supports Locality-specific Peripheral Interrupts (LPIs), which are typically used for peripherals that produce message-based interrupts. Compared with SPIs, you can have a far larger number of LPIs than SPIs for the same area on the silicon die. This is because LPIs are only cached and not stored in the GIC-500. LPIs are generated when peripherals write to the Interrupt Translation Service (ITS) through the programmable slave interface. The ITS also provides interrupt ID translation that allows the possibility of a virtual machine directly owning a peripheral.
You can configure the following on a GIC-500:
- The number of supported clusters
- The number of supported cores within a cluster
- The number of supported SPIs
- Whether LPIs are supported
- Whether legacy mode is supported
Therefore, you can limit the size of the GIC-500 in your SoC by excluding functionality that you do not require. For example, if you know that you only need 32 SPIs, you can save space by specifying this amount.
The following table describes the interfaces available on the GIC-500:
|Physical interrupt signals||An interface that allows physical interrupts to be received. The interrupts originate from peripherals and other IP on the SoC.|
|Stream protocol master||One of a pair of AXI-Stream interfaces. The GIC-500 uses these interfaces to send interrupts to a core and receive notifications from a core. Packets are sent through the master interface to a specific core within the cluster.|
|Stream protocol slave||One of a pair of AXI-Stream interfaces. The GIC-500 uses these interfaces to send interrupts to a core and receive notifications from a core. The slave interface receives notification when a core activates an interrupt.|
|AXI slave||A slave AXI interface allowing software to program and configure the GIC-500. Software can also generate SGIs using this interface. Peripherals can use it to generate LPIs.|
|Master||A master AXI interface allowing the GIC-500 to access the main memory on the SoC. This interface is available if the ITS is present and LPIs are supported. In these cases, the GIC-500 must access information in the form of tables that are held in memory. Because you can have thousands of LPIs, storing LPI-related information requires the use of the main memory.|