xPC Target

Interrupt Mode

Interrupt mode is the default real-time execution mode for the xPC Target kernel. This mode provides the greatest flexibility and is the mode you should choose for any application that executes at the given base sample time without overloading the CPU.

The scheduler assures real-time single-tasking and multitasking execution of single-rate or multirate systems including asynchronous events (interrupts). Additionally, background tasks like host-target communication or updating the target screen run in parallel with the sample-time-based model tasks. This allows you to interact with the target system while the target application is executing in real time at high sample rates. This is made possible by an interrupt-driven real-time scheduler that is responsible for executing the various tasks according to their priority. The base sample time task can interrupt any other task (larger sample time tasks or background tasks) and execution of the interrupted tasks resumes as soon as the base sample time task completes operation. This gives a quasi-parallel execution scheme with consideration to the priorities of the tasks.

Latencies Introduced by Interrupt Mode

Compared to other modes, interrupt mode has more advantages. The exception is the disadvantage of introducing a constant overhead or latency, which reduces the minimal possible base sample time to a constant number. The overhead is the sum of various factors related to the interrupt-driven execution scheme and can be referred to as overall interrupt latency. The overall latency consists of the following parts, assuming that the currently executing task is not executing a critical section and has therefore not disabled any interrupt sources.

• Interrupt controller latency -- In a PC-compatible system the interrupt controller is not part of the x86-compatible CPU but part of the CPU chipset. The controller is accessed over the I/O-port address space, which introduces a read or write latency of about 1 us for each 8 bit/16 bit register access. Because the CPU has to check for the interrupt line requesting an interrupt, and the controller has to be reset after the interrupt has been serviced, a latency of about 5 us is introduced to properly handle the interrupt controller.
• CPU hardware latency -- Modern CPUs try to predict the next couple of instructions, including branches, by the use of instruction pipelines. If an interrupt occurs, the prediction fails and the pipeline has to be fully reloaded. This process introduces an additional latency. Additionally, because of interrupts, cache misses will occur.
• Interrupt handler entry and exit latency -- Because an interrupt can stop the currently executing task at any instruction and the interrupted task has to resume proper execution when the interrupting task completes execution, its state has to be saved and restored accordingly. This includes saving CPU data and address registers, including the stack pointer. In the case that the interrupted task executed floating-point unit (FPU) operations, the FPU stack has to be saved as well (108 bytes on a Pentium CPU). This introduces additionally latency.
• Interrupt handler content latency -- If a background task has been executing for a longer time, say in a loop, its needed data will be available in the cache. But as soon as an interrupt occurs and the interrupt service handler is executed, the data needed in the interrupt handler might no longer be in the cache, causing the CPU to reload it from slower RAM. This introduces additional latency. Generally, an interrupt reduces the optimal execution speed or introduces latency, because of its unpredictable nature.

The xPC Target real-time kernel in interrupt mode is close to optimal for executing code on a PC-compatible system. However, interrupt mode introduces an overall latency of about 8 us. This is a significant amount of time when considering that a 1 GHz CPU can execute thousands of instructions within 8 us. This time is equivalent to a Simulink model containing a hundred nontrivial blocks. Additionally, because lower priority tasks have to be serviced as well, a certain amount of headroom (at least 5%) is necessary, which can cause additional cache misses and therefore nonoptimal execution speed.

xPC Target Kernel Polling Mode

Polling Mode