xPC Target

Polling Mode

The polling mode for the xPC Target real-time kernel does not have the 8 us of latency that is with the interrupt mode. This is because the kernel does not allow interrupts at all, so the CPU can use this extra time for executing model code.

Polling mode is sometimes seen as a "primitive" or "brute force" real-time execution scheme. Nevertheless, when a real-time application executes at a given base sample time in interrupt mode and overloads the CPU, switching to polling mode is often the only alternative to getting the application executing at the required sample time.

Polling means that the kernel waits in an empty while loop until the time at which the next model step has to be executed is reached. Then the next model step is executed. For this at least a counter implemented in hardware has to be accessible by the kernel in order to get a base reference for when the next model step execution has to commence. The kernel polls this hardware counter. If this hardware counter must be outside the CPU, say in the chipset or even on an ISA or PCI board, the counter value can only be retrieved by an I/O or memory access cycle that again introduces latency. This latency usually eats up the freed-up time of polling mode. Fortunately, since the introduction of the Pentium CPU family from Intel, the CPU is equipped with a 64 bit counter on the CPU substrate itself, which commences counting at power-up time and counts up driven by the actual clock rate of the CPU. Even a highly clocked CPU is not likely to lead to an overflow of a 64 bit counter (2^64 * 1e-9 (1 GHz CPU) = 584 years). All in all the Pentium counter comes with the following features:

• Accurate measurements -- Because the counter counts up with the CPU clock rate (~1 GHz nowadays), the accuracy of time measurements even in the microsecond range is very high, therefore leading to very small absolute real-time errors.
• No overflow -- Because the counter is 64 bits wide, in a practical application and overflow does not occur, which makes a CPU time expensive overflow handler unnecessary.
• No latency -- The counter resides on the CPU. Reading the counter value can be done within one CPU cycle, introducing almost no latency.

The polling execution scheme is not dependent on any interrupt source to notify the code to continue calculating the next model step. While this frees up the CPU, it means that any code that is part of the exclusively running polling loop is executed in real time, even components, which have so far been executed in background tasks. Because these background tasks are usually non-real-time tasks and can use a lot of CPU time, there is only one solution: Do not execute them. And this is the big disadvantage of polling mode: In order to be efficient, only the target application's relevant parts should be executed, and this is, in the case of xPC Target, the code representing the Simulink model itself. Therefore, host-target communication and target display updating are disabled. Because polling mode reduces the commonly known features of xPC Target to a minimum, you should choose it only as the last possible alternative to reach the required base sample time for a given model. Therefore, the following should be assured before you consider polling mode.

• The model is optimal concerning execution speed -- First, you should run the model through the Simulink profiler to find any possible speed optimizations using alternative blocks. If the model contains continuous states, the discretization of these states will reduce model complexity significantly, because a costly fixed-step integration algorithm can be avoided. If continuous states cannot be discretized, the integration algorithm with the lowest order that still produces correct numerical results should be used.
• Use the fastest available computer hardware -- Ensure that the CPU with the highest clock rate available is used for a given PC form factor. For the desktop form factor, this would mean a clock rate above 1 GHz; for a mobile application, say using the PC/104 form factor, this would mean a clock rate above 400 MHz. Most of the time, you should use a desktop PC, because the highest clocked CPUs are available for this form factor only. Executing xpcbench at the MATLAB command prompt gives an understanding about the best performing CPUs for xPC Target applications.
• Use the lowest latency I/O hardware and drivers available -- Many xPC Target applications communicate with hardware through I/O hardware over either an ISA or PCI bus. Because each register access to such I/O hardware introduces a comparably high latency time (~1 us), the use of the lowest latency hardware/driver technology available is crucial.
• The base sample time is about 50 us or less -- The time additionally assigned to model code execution in polling mode is only about 8 us. If the given base sample time of the target application exceeds about 50 us, the possible percentage gain is rather small. Other optimization technologies might have a bigger impact on increasing performance.

Interrupt Mode

Setting the Polling Mode