Interrupt controller - Seminar Report

INTERRUPT CONTROLLER

The interrupt controller is a device commonly found in computer system (both sing and multi processor), which deals with the interrupt generated by the peripherals and processors, handle the interrupt priorities and delegates the execution of the processors.

Interrupt controller architecture

The high level block diagram of the interrupt architecture is shown in the Fig.1.8. It is composed by two main components: the first one is the (OPB interface) block which interfaces the core with the main bus of the system, the second one (int core) implements the true logic of the controller.

Interface

The interface is based on the On-chip peripheral Bus (OPB) specification to allow memory mapped access from the processor. The interface sends the following sings to the control logic:

• Reg_Addr: the register address where the processor wants to write to or read from
• Valid_rd: read operation from the register specified by Reg_Addr
• Valid_wr: write operation towards the register specified by Reg_addr
• Data_in:the data to write
• Data_out: the data to read
• Proc_id: the identification of the processor accessing the controller

The last signal allows associating the each event to and from the multiprocessor Interrupt controller with the corresponding source processor.

Controller logic

The second component Int Core, implement the core logic of the controller. As the picture shows, it is composed by three subcomponents, each one with specific processor:

The register block provides a useful support for all the main facilities of our Interrupt controller. It allows handling of the Interrupt priorities; decide ding which Interrupt can be handled and managing of the interrupt acknowledge signals. To allow each processor to respond only to the interrupt generated by a specific ips (booking) and to allow broadcasting of interrupts to all the processors in the system.

Our design implements the following registers:

• Interrupt Status Register (ISR) stores the active interrupts
• Interrupt Pending Register(IPR) stores the interrupts that are both active and enabled
• Interrupt Enable Register (IER) keeps track of which interrupts are allowed to be handled
• Interrupt Acknowledge Register (IAR) is a support for disabling interrupts that receive the corresponding acknowledgment signal
• Set Interrupt Enable (SIE) is a support for writing into IER
• Clear Interrupt Enable (CIE) is a support for deleting from IER
• Interrupt Vector Register (IVR) contains the identification of the next interrupt that must be served.
• Master Enable Register (MER) is used for enabling our Interrupt Controller to manage interrupts
• Device Processor Waiting (DPW) is a support to store which interrupts have been booked
• Broadcast (BRO) is a support to store which interrupts have to be handled in broadcast way
• Edge Interrupt Detection detects interrupts coming from the IPs of the system and activates the logic which communicates pending requests to the connected processors. In particular, it monitors the signals vector Int Inputs composed of all interrupt lines coming from the cores, and rises the Enabled-Ints signal according to the arriving signals.

Irq Generator contains the generation logic of the interrupt signals toward processors. It is composed of two main sub-blocks. Broadcast Interrupt Generator generates signals in case of interrupts that need to be propagated to all processors. Standard Interrupt Generator handles all the other kinds of interrupt.

Each of the two modules is active in mutual exclusion. The signal Broadcast logic Enable is active until all processors complete the handling of the broadcast interrupt requests. This means that broadcast events have the highest priority in our design. In our opinion, this could be a reasonable design choice for real-time system. In fact, it is fair to suppose that a broadcast event implies that all processors have to answer to this event as fast as possible. If the system handled other interrupts during a broadcast event, some processors would never receive the broadcast interrupt. The block Standard Interrupt Generator is composed of:

• Number of Interrupts Detector useful to count the interrupts that still have to be handled
• Timeout Manager manages delays of incoming acknowledge signals. In order to dynamically allocate the handling of the interrupts to all available processors and allow real time responsiveness, if a processor is not able to acknowledge an interrupt before a pre-determined deadline, the Multiprocessor Interrupt Controller will forward the signal to another processor.
• Enable Specific Output allows a processor to wait for interrupt from a specific device
• Signal Generator forwards the interrupt signals to the processors

A Simple Example

  With the purpose to better understand the behavior of the proposed architecture, it is useful to introduce a simple example which is shown Fig.1.10, which shows how the component reacts to the arrival of multiple interrupts in a short time interval.

• Two application specific cores connected to the Interrupt Controller generate interrupts in the same time interval. Interrupt management for these two cores has been
• Previously enabled by writing on the IER register
• The interrupts are detected by the Edge Interrupt Detection module
• The Edge Interrupt Detection Module stores the arrival of the interrupts in ISR register. Writing on ISR also influences the content of the IPR register
• IRQ Generation raises two outputs toward two free processors (not handling other interrupts)
• The Interrupt Controller waits for acknowledgment
• The first processor which detects the interrupt request chooses the active interrupt with the highest priority and sends the related acknowledgment.
• The first processor starts executing the handler associated to the selected interrupt.
• The second processor which detects the interrupt request chooses the second active interrupt and sends the related acknowledgment.
• The second processor starts executing the handler associated to the selected interrupt.
• From now on, the two processors will concurrently handle the two generated interrupts.

SOFTWARE LAYER

The software layer is composed by a driver and a generic interrupt handler. The driver exposes the Interrupt Controller features to the processors. It contains three main functions to implement booking, broadcasting, and inter-processor communication. The next section discusses the detailed behavior of our architecture when dealing with these features. The generic interrupt handler is called DeviceInterruptHandler and executes whenever a processor receives an interrupt request. This routine chooses which is the interrupt to handle by reading the Interrupt Controller registers, acknowledges the Interrupt Controller and launches the specific interrupt handler to manage the event. If it is an interrupt from a peripheral, the handler included in the peripheral driver is executed. If it is an inter-processor interrupt, an appropriate handler is launched. Notice that the accesses to the Interrupt Controller from multiple processors must be exclusive. This is ensured by the generic handler which properly uses lock-protected critical sections to correctly perform the access to the Interrupt Controller registers. In addition all software (handler and driver) I s shared, thus residing in the same memory segment. It is fetched to the local caches when needed. On the other hand, the local data stack grows in the local data memories. The CerberO architecture, to which the Multiprocessor Interrupt Controller is targeted, provides full, seamless support for these aspects.