Full Text: Download PDF
Developers across the wide spectrum of embedded computing applications can benefit greatly from the latest advances in multicore processor technology. Multicore processors fulfill the need to incorporate new features with legacy code and combine multiple operating environments on the same system. A highly integrated system can be constructed with real-time software components and human-directed elements running on separate cores.
Virtual machine management
Initially implemented on mainframes decades ago to help administrators avoid wasting expensive processing power, virtualization technology is used widely in servers today. However, virtualization is not as readily embraced in embedded, real-time computing environments because these environments have different needs than those of servers and desktops.
Historically, virtual machine management software has emulated the entire underlying machine, including all the I/O devices, giving each guest operating environment what it thinks is complete control over the hardware. A Virtual Machine Manager (VMM) decides which guest OS should have access to the I/O at any instant, and the VMM handles all the I/O transactions on the guest’s behalf.
One problem with this approach is that the VMM must evolve quickly to offer the same functionality as what is available on the latest hardware platforms. New I/O devices are being developed all the time, and emulating the latest features of a high-performance I/O device is a tall order for even the most talented virtual device driver developer.
Even if a VMM can support all the features of contemporary I/O interfaces, using a completely virtualized machine imposes a performance penalty that the guest OS would not have if it interacted directly with the hardware. For example, graphic-intensive applications need access to real hardware for maximum performance. A virtual frame buffer is too slow and inadequate in features for an application that renders 3D moving images. This poses a major problem for applications such as medical imaging systems or robotic assembly machines. In these systems, the guest OS that renders the images needs direct access to the physical frame buffer and its control I/O.
Therefore, developers need a different approach to virtual machine management to support the latest I/O hardware enhancements and yield maximum performance in deterministic processing environments. Addressing this problem requires a VMM that assigns specific devices directly to the I/O tasks that control them, as illustrated in Figure 1.
|
|
|
Figure 1 (click graphic to zoom by 2.2x) |
In this system, the VMM emulates the underlying machine’s shared devices, not its entire I/O interface. For all other devices, it controls access to the device by guaranteeing that only authorized operating environments can access specific performance-critical I/O. For example, as shown in the diagram, the VMM ensures that the main operator display is only accessible to the General-Purpose OS (GPOS), in this case, Windows.
Assigning I/O exclusively to a specific virtual machine is also essential to guaranteeing real-time responsiveness. Without exclusive physical I/O assignment, developers run the risk of waiting indeterminately for access to key devices. If another virtual machine has access to an I/O device, the wait can be significant because the I/O is multiplexed. Even if only one guest OS ever accesses a specific I/O device, a VMM that virtualizes that I/O must translate the request by the virtual machine into a real I/O access to the physical hardware, an unnecessary and time-consuming process.
Thus, real-time response-critical hardware can only be accessed by the Real-Time Operating System (RTOS) that controls that hardware, and legacy I/O interfaces can only be accessed by the corresponding legacy application software.
Application examples
Consider an application involving a computer numeric control machine tools manufacturer that has spent more than 10 years developing real-time machine control software on QNX and no longer employs many of the original engineers that developed the software. The machine manufacturer wants to add a modern human interface to the system without risking changes to the real-time control software.
To accomplish this, the manufacturer can run the legacy real-time software on one core in a multicore processor and implement the new user interface functionality on the remaining cores. The VMM in this case partitions the processor’s I/O, memory, and other resources to ensure that only the machine control software has direct access to the motion control hardware and that it operates on a dedicated CPU core. This creates a separation between the real-time OS and the user interface software, avoiding interference between the two OSs and thereby protecting the timing loops the legacy real-time software manages from being violated by operations the new human interface software performs.
In another application, a robotic material handling system manufacturer wants to upgrade an older product built around multiple hardware computing platforms – an industrial PC using Windows and custom Power Architecture processor-based boards running vision and motion control software on VxWorks. Because the vision and motion software use a set of library functions also available for Intel Architecture (IA) processors, the machine vision subsystem can be recompiled and reconfigured to run as an application core on one of the cores in an IA multicore processor while the motion system and operator interface run on their own dedicated cores in the same processor. Thus, the expensive, loosely coupled system comprised of multiple discrete hardware boards can be transformed into a single, highly integrated hardware platform, saving substantial hardware costs.
IA processors support virtualization
The most popular multicore processors are those that support the Intel processor architecture because platforms using this architecture are the most prevalent in the market. IA processors support four distinct privilege levels of application execution, named rings 0 through 3. Ring 0 executes at the highest privilege level and ring 3 at the lowest. In typical practice, only the outermost levels are ever used: rings 0 and 3, referred to as supervisor mode and user mode, respectively.
OSs that utilize these execution modes are referred to as protected mode OSs; the OS executes its instructions in supervisor mode and its applications execute in user mode. Drivers might execute either in supervisor or user mode, depending on the OS architecture and the nature of the driver.
Protected mode guest OSs expect to run in supervisor mode with full access to the underlying CPU registers and processor data structures. As a result, a VMM must perform two difficult jobs: intercept guest OS instructions that modify supervisor mode registers and processor data structures and simulate the impact of those instructions inside the virtual machine on which the guest OS is running.
Intel introduced hardware support for solving this problem when it incorporated Intel Virtualization Technology (Intel VT) into its most recent array of multicore processors. This hardware support for virtualization added an overarching execution mode to the CPU, called VMX root, where VMM software executes with ultimate control over the CPU hardware. Using Intel VT, a VMM can intercept key supervisor mode operations executed by any software operating outside of VMX root without requiring a priori knowledge of the guest OS binaries or internals. Using this hardware assist for virtualization, developers can build a VMM that hosts protected mode OSs executing in ring 0 without giving up control of key CPU resources.
Intel VT also provides a way for the VMM to implement virtual interrupts, an essential feature for hosting a real-time guest OS. The Intel VT hardware in an Intel multicore CPU provides the VMM with the ability to see a hardware interrupt even if it has been masked by a guest OS. This means the VMM can field hardware interrupts and ensure that interrupts for a real-time virtual machine will always be serviced without delay. The ability to monitor interrupts at all times regardless of the state of their mask bits guarantees that real-time interrupt latencies are minimized and that virtual machines cannot interfere with each other.
Low interrupt latency, direct access to specialized I/O, and the assurance that a VMM won’t "virtualize away" real-time task determinism and priority are all key requirements for a real-time virtual machine. Combining multicore CPUs and Intel VT forms an ideal platform on which to consolidate multiple hardware platforms into one, allowing a GPOS to coexist with a real-time OS on a single PC-compatible system.
A real-time VMM
In 1997, TenAsys Corporation introduced INtime, an RTOS that runs deterministically alongside 32-bit and 64-bit versions of Microsoft Windows on a single IA hardware platform. A unique form of virtualization makes this possible, allowing Windows to run unmodified as the lowest-priority task (namely, the idle task) in the INtime real-time task list. This dual-OS, single-platform arrangement gives developers a means to build deterministic embedded Windows systems that can reliably control critical machine functions and simultaneously present high-level interfaces for system monitoring, enterprise connectivity, and complex user interaction.
Recently, TenAsys introduced eVM, a VMM capable of supporting an RTOS’s demands while simultaneously hosting a GPOS such as Windows or Linux in an embedded system. By leveraging Intel VT, this VMM allows legacy RTOS environments to be hosted easily on a multicore processor. This has useful implications for applications that need to preserve legacy real-time code, as shown in Figure 2.
|
|
|
Figure 2 (click graphic to zoom by 2.2x) |
Running an RTOS in a virtual, real-time machine on its own processor core enables legacy real-time applications to be migrated from obsolete hardware to modern embedded platforms. Because I/O can be virtualized, developers can simulate old hardware devices and minimize rewriting proven software. For example, a VMEbus system can be converted to a less expensive SBC system by intercepting I/O requests to legacy VMEbus I/O and redirecting it to equivalent onboard I/O devices.
This virtualization software distinguishes resources that can be multiplexed by the VMM from those that must be exclusive to a virtual machine. For example, devices like an enterprise Ethernet interface can be multiplexed and shared between all virtual machines. However, when determinism and performance are more important than equal access, eVM isolates resources for use by a specific virtual machine and its guest OS. Hardware specific to a real-time control application, such as a Video capture card, fieldbus interface, or network interface card used as a real-time Ethernet master should not be multiplexed between virtual machines. Specialized real-time I/O must be dedicated to its real-time virtual machine so the guest RTOS and application using that I/O can maintain real-time determinism and control.
Other benefits of using multicore IA CPUs
In addition to having tools and application software support, PC-compatible hardware can run the development software environment directly on the target hardware, conserving development time and effort compared to using separate development workstations. Also, using IA hardware platforms and software technology can save costs and provide access to the latest industry-standard hardware resources, including up-to-date interfaces for communication and I/O such as USB. Additional advantages include the ability to incorporate new communication protocols for interaction with external systems and to adapt more sophisticated data reporting methods.
Because a multicore chip can host multiple operating environments, systems that previously required multiple discrete computing modules can now be combined into a single hardware environment, saving design, manufacturing, and maintenance costs.
Virtual gains
Using virtualization technology on Intel multicore processor platforms can assist developers by eliminating redundant computer and communication hardware, providing faster communication and coordination between RTOS and GPOS subsystems, improving reliability and robustness, reusing proven legacy applications, and simplifying development and debugging. IES
TenAsys
503-748-4720
info@tenasys.com
www.tenasys.com
