By Rohit Goyal, Rahul Agrawal, Ashish Banga (Freescale India Pvt. Ltd.)
Core (or Processor) is heart of any SoC which controls all the operations of modern day chip. In order to extract the maximum performance out of it, generally Interrupt Based Software is written. But for any core, the number of interrupt lines available is always limited, so Pin Multiplexing technique is generally used in design and multiple events are mapped onto a single Interrupt.
This technique do serve the purpose, but at the same time imposes a restriction that ISR (Interrupt Service Routine) should be generic enough as a single ISR needs to be executed for multiple events. In a system where the different processes (individual tasks) are interdependent, there is also a need to ensure that interrupts are getting received in expected order.
This can be done by maintaining a list of global variables in software which will hold the values for the expected pending interrupts, but it adds a lot of overhead on the ISR as it needs to check for values of all such global variables, and it is always an expectation that ISR should be kept as small as possible.
The paper discusses about a Queue Based Interrupt Service Protocol, which eliminates the possible limitations faced by global variable interrupt service protocol and helps in extracting maximum performance out of system software.
Pin Multiplexing for Interrupts is a general design practice in any SoC. In cases where software code is such that the events/interrupts, mapped onto single interrupt line has the interdependency, generic ISRs can’t be used, and there needs an Interrupt Service Protocol which not only helps in error detection, but at the same time helps in extracting maximum software performance.
In coming sections, An Interrupt Service Protocol using Global Variables is discussed first along with its limitations, followed by the proposed Queue Based Interrupt Service Protocol.
2. Global Variable Based Interrupt Service Protocol:
Let’s consider a system, where we have two tasks to perform (Task 1 & Task 2) and Task 1 is expected to be finished first.
In such a case, if we go by the global variable scheme, ISR can be written in two possible ways, one in which checker has been implemented in ISR and other with checker in the main code. Both these coding schemes are shown below in Fig.1 and Fig.2 respectively.
Fig.1: Software Style 1 (Checker in ISR)
Fig.2: Software Style 2 (Checker in Main Code)
As the intent is always to keep ISR as small as possible, Style 2 is more commonly used. This works fine as long as the number of tasks to be executed are limited, but as the number of tasks increases, checker becomes complex. Software code for N such tasks is shown below in Fig.3.
Fig.3: Software Style 2 (For N Tasks)
Because of this complexity, as the number of tasks increases, software performance goes down and hence, there is a need for an alternate approach which can extract better performance out of the software.
3. Queue Based Interrupt Service Protocol:
A Queue (First In First Out) buffer can be implemented in memory to hold the values of the expected interrupts along with the information that whether the interrupts need to be serviced in order or out of order fashion. (Only in-order is considered for this article)
Whenever an interrupt is received, the current value can be compared against the value first pushed in queue. If correct value is received, Interrupt will be serviced with an indication to core that a correct/expected interrupt has been serviced or else with an error signature.
Such queue based interrupt service protocol is shown below in Fig.4
Fig.4: Queue Based Interrupt Service protocol
Again let’s consider a system, where we have two tasks to perform (Task 1 & Task 2) and Task 1 is expected to be finished first.
Coding scheme for such a system using queue based approach is shown below in Fig.5
Fig.5: Software Scheme Using Queue Based Interrupt Service Protocol
Fig.6 shows the coding scheme using queue based approach for a system with N Tasks.
Fig.6: Software Scheme Using Queue Based Interrupt Service Protocol (N Tasks)
As it is clear, that in case of queue based interrupt service protocol, complexity of the checker is independent of the number of tasks, so it helps is extracting maximum performance out of the system software.
Fig.7 shows the complete implementation of system software using the proposed protocol.
Fig.7: Software Implementation Using Queue Based Interrupt Service Protocol
Based on the above description and comparison, it is clear that the presented Queue Based Interrupt Service Protocol not only just helps in detection of possible software/hardware errors but at the same time helps in extracting maximum performance out of the system software.
 Interrupt aware queue implementation for energy efficient multitasking systems based on Cortex-M3 architecture.
 Coding ISRs By Jack Ganssle
If you wish to download a copy of this white paper, click here