Interrupts have a few configurable aspects to them. For one, the programmer can individually choose which interrupts to enable and which to disable. Additionally, the programmer can decide the prioritization of the ISRs by configuring a module called an arbiter. On the contrary, the program cannot change the index of each interrupt source in the vector table. Furthermore, the programmer cannot change, which interrupt sources are available since these are hard-wired connections. However, the programmer can send commands to the interrupt source to indicate that the interrupt has been serviced, subsequently deactivating the interrupt trigger.

The architecture of the interrupt mechanisms can be subdivided into three levels: the peripheral level, the interrupt controller level, and the processor level. At the peripheral level, an individual peripheral must be configured to generate an interrupt. This is a function that must be done on the peripheral side, not through the controller or the processor.

The interrupt controller itself has two parts. The first part checks whether or not an interrupt has occurred. Each interrupt source has its own AND gate, with one input tied to the source and the other tied to an enable bit (represented above by yellow blocks). By setting a peripheral’s enable bit to 1, that peripheral’s interrupt is enabled on the controller side. Similarly, setting the bit to 0 disables that peripheral’s interrupt. All of these AND gates are then tied to the input of a several-input OR gate. 

The second part of the interrupt controller contains the arbiter and the IVT. When the processor receives one or more interrupts, the arbiter chooses which interrupt to service based on priority. This value is then evaluated by the IVT, which then sends the corresponding ISR address to the processor. When working together, the first part of the controller indicates whether or not an interrupt has occurred, whereas the second part informs the processor of which ISR to execute.

Finally, at the processor level, the appropriate ISR is executed when the processor’s interrupt flag indicates that an interrupt has occurred. Before the ISR terminates, it sends a command to the respective interrupt source to clear its interrupt flag, indicating that the interrupt has been serviced. By doing so, the arbiter can then provide the processor core with a new ISR address when either a new interrupt is generated, or a lower-priority interrupt still needs to be serviced.