Multi-core CPUs Reduce Interrupt Latency and Increase Software Reliability

By Paul Fischer, TenAsys Corporation

 

Multi-core processors aren’t just good for improving the performance of servers and office computers. They’re also delivering big system-level benefits for embedded computing applications. For example, multi-core Intel® processors are making it much easier to improve real-time Windows performance. For those systems that require the user-interface and enterprise connectivity of Windows—but also need deterministic real-time control—it’s possible to dedicate one or more central-processing-unit (CPU) cores to execution of real-time tasks. This approach enables real-time processes to operate unencumbered by non-real-time applications. By isolating real-time processes from general-purpose processes on different cores timer and interrupt response times are greatly improved. The result is a more reliable and higher-performance real-time system.

 

From a software point of view, making such an environment work requires the use of multiple virtual machines. In this example, a general-purpose operating system (OS), like Windows, runs unmodified on one virtual machine, and a real-time operating system (RTOS) runs on the other. A virtual-machine approach makes it very easy to host two operating systems on a dual-core CPU, as each virtual machine can be mapped directly to its own physical core (see Figure 1). One CPU core hosts the RTOS and the other hosts Windows. Intel® Core™ Duo processors provide a mechanism for fast signaling between the two cores and for directing interrupts to specific cores. As a result, real-time interrupts are always handled by the CPU core that’s hosting the RTOS.

Dual-OS virtual-machine systems exist today. The INtime RTOS for Windows, from TenAsys, is an example. It has been successfully deployed with real-time applications operating at cycle times of 250 to 1000 microseconds on single-core CPUs (uniprocessor Intel® Pentium® 4 processors running at speeds of 1 to 3 GHz) for over ten years. For real-time applications demanding even faster cycle times, rather than increase the processor speed, the optimum solution is to use a multi-core CPU and dedicate a core to real-time execution.

When two virtual machines share a CPU—as is the case with the single-core processor designs—they must maintain a full machine context in order to switch between the two operating systems. Saving and restoring these contexts compromises event-response latency and cycle times. These compromises can contribute 10 to 30 microseconds to worst-case interrupt delays, also called jitter. Over a cycle time of 1000 microseconds, 10 to 30 microseconds of worst-case interrupt latency represents a jitter variation of only a few percent.

When two virtual machines share a CPU—as is the case with the single-core processor designs—they must maintain a full machine context in order to switch between the two operating systems. Saving and restoring these contexts compromises event-response latency and cycle times. These compromises can contribute 10 to 30 microseconds to worst-case interrupt delays, also called jitter. Over a cycle time of 1000 microseconds, 10 to 30 microseconds of worst-case interrupt latency represents a jitter variation of only a few percent.

As cycle-time rates increase to the range of 50 to 200 microseconds, 10 to 30 microseconds of jitter represents a significant number. When jitter becomes a significant percentage of the cycle time, it adversely affects the stability and quality of control algorithms. This can degrade the stability margin of closed-loop control systems—especially naturally unstable systems like position- feedback motion-control loops.

Dedicated Cores

Dedicating one CPU core to the RTOS virtual machine, on a multicore platform, allows virtually 100% of that core’s CPU instruction cycles to be used for real-time threads. The CPU cycles of the remaining cores can be used exclusively by the general-purpose virtual machine(s). Contention for key processor resources, such as pipelines, cache, and the floating-point unit, are eliminated when a CPU core is dedicated to the RTOS environment.

On a real-time Windows dual-core system, real-time interrupt latencies are reduced by an order of magnitude—to 1 to 3 microseconds. Control loops with cycle times in the 50-to-200- microseconds range execute with very high precision. The net result is an order-of-magnitude improvement in quality and bandwidth for the control algorithms deployed on a dual-OS system.

With multiple virtual machines one can contain each OS to ensure that runaway processes in Windows never affect those in the RTOS, and vice versa. A virtual-machine approach also allows real-time applications to run in user mode rather than kernel mode. Because real-time processes run in separately managed memory segments, virtual machine techniques improve reliability and robustness. Distinct memory segments provide address isolation and protection between real-time processes and nondeterministic Windows code. Development and debugging is also simplified, as all processes run in protected user mode rather than unprotected kernel mode. There’s no speed penalty for this approach—only increased reliability and safety!

Single Development Platform

Even though the developer is working with multiple operating systems running in separate virtual machines, they reside on a single hardware platform. This offers the advantage of hosting a single development environment on which to develop code for both parts of the solution: the deterministic real-time part and the enterprise-level part. Modern integrated development environments (IDEs) can be used to support such an approach. For example, Microsoft Visual Studio can be used to develop Windows and INtime applications simultaneously on a single system (see Figures 2 and 3).

With the INtime development tools integrated into Visual Studio, real-time Windows applications can be edited, compiled, debugged, and maintained with the Visual Studio IDE. There’s no reason to purchase or learn to use other development tools. Using an IDE like Visual Studio, developers can debug real-time applications at full speed—avoiding the need to use a simulator or debug over a communication interface. Debugging real-time code in a simulated environment dilutes the effectiveness of one’s development effort, because a simulator is never the actual run-time environment. When using a simulator or communication link, it’s very easy to miss subtle timing-specific problems that can only be found by running directly on the real-time kernel. The INtime Visual Studio debug plug-in also captures and identifies real-time process faults caused by divide-by-zero errors, bad pointer accesses, page faults, stack faults, and other CPU exceptions.

Multi-core-processor components promise to deliver greater performance, real-time responsiveness, and lower power consumption to embedded systems. At the same time, they promise to keep system cost under control. The potential software complexity of implementing multi-core systems is eased by basing the processor usage models around a virtual-machine approach in which the real-time and general-purpose OS portions of the system can be hosted on dedicated processor execution cores. The final key is to employ integrated development environments that support design and execution on multi-core systems.

Contact Information

Radisys Corporation
1400 NW Compton Drive, #301
Beaverton, OR 97006
877-277-9189 Toll Free
503-748-4720 Telephone
503-748-4730 Fax
info@tenasys.com
www.tenasys.com