Real-Time Virtualization

Virtualization is a broad term that refers to the abstraction of computer resources. A hypervisor, also known as a virtual machine monitor (VMM), is virtualization software that allows multiple operating systems to run simultaneously on a single computer.

The NI Real-Time Hypervisor leverages VirtualLogix VLX Real-time Virtualization technology to enable both Windows XP and the NI ETS real-time operating system to run simultaneously on a supported multi-core PXI or industrial controller. Both operating systems run natively on separate CPUs using hardware-assisted Intel® Virtualization Technology (Intel® VT) to minimize CPU overhead.

The two operating systems must share a single physical hard drive controlled by Windows. RAID arrays are not supported. The shared hard drive must be partitioned as follows:

• One partition formatted with the NTFS file system running Windows XP (32-bit).
• One partition formatted with the FAT32 file system, named LABVIEW_RT, and running the NI ETS real-time operating system.

Caution  Do not mount the RT partition in Windows. Mounting the RT partition in Windows can cause file corruption due to simultaneous file access by Windows and the NI ETS real-time OS.

Caution  Because the shared hard drive must be controlled by Windows, you cannot restart Windows without also restarting the NI ETS real-time operating system. If the RT application needs to run uninterrupted for an extended period of time, avoid running unnecessary or potentially unstable applications on Windows. If Windows crashes, an RT application can continue running without hard drive access. To implement a safe shutdown procedure in the event of a Windows crash, you can check for a File I/O error in the RT application.

Restarting the RT Target Independently

When you perform a software restart of the RT target, the NI ETS real-time OS restarts independently of Windows.

Note  Because Windows needs to continue using hardware devices, the independent RT restart operation does not assert the PCI reset signal. This can leave devices controlled by unsupported device drivers in an undefined state. Refer to the National Instruments Web site for information about developing device drivers and using third party device drivers.

Resource Partitioning

To prevent jitter in real-time applications, the NI Real-Time Hypervisor implements low-level partitioning of PCI interrupt request lines (PIRQs). Therefore, you must assign each PIRQ to only one operating system. The strict resource partitioning requirements of the NI Real-Time Hypervisor prevent either OS from requesting resources in use by the other, which could affect the determinism of an RT application.

PCI Interrupt Request Lines (PIRQs)

Each device connected to a PXI chassis requires one or more PCI interrupt request lines (PIRQs). A PXI chassis includes eight PIRQs, A–H. However, PIRQs E–H are reserved for built-in devices. Additional hardware devices can use only PIRQs A–D.

Because there are more card slots than PIRQ lines, multiple cards can share a PIRQ line. However, the two operating systems in an NI Real-Time Hypervisor system cannot share a given PIRQ line. Each PIRQ line must be assigned to either Windows or Real-Time.

The PIRQ(s) used by a hardware device are determined by the physical slot in which the card is installed in the PXI chassis and by any PCI bridges included on the card.

PCI Bridges

Many hardware devices include built-in PCI bridges. A PCI bridge is a physical device that connects two PCI buses. The PIRQ line that a device uses depends on the slot location and the effect of the bridge(s) between the device and the PCI root port.

Each PCI bridge acts as a fixed PIRQ offset, as shown in the following illustration.

This illustration shows a conceptual overview of an 8-slot PXI chassis with the following cards installed.

1. Card 1—Installed in slot 2, which defaults to PIRQ D. This card does not include a bridge, so it connects Device 1 to PIRQ D.
2. Card 2—Installed in slot 4, which defaults to PIRQ B. This card includes a bridge with an offset of one, so it connects Device 2 to PIRQ C.
3. Card 3—Installed in slot 5, which defaults to PIRQ A. This multi-device card includes two devices, Device 3 and Device 4. Device 3 connects to PIRQ A and Device 4 connects through a bridge with an offset of three to PIRQ D.
4. Card 4—Installed in slot 7, which defaults to PIRQ C. This card includes a bridge with an offset of two, so it connects Device 5 to PIRQ A.

Note  You can assign each device of a multi-device card to a different OS. However, the NI Real-Time Hypervisor Manager automatically assigns each function of a multi-function card to the same OS, and you cannot assign these functions to separate operating systems. For example, if card 3 were a mult-function card instead of a multi-device card, you could not assign PIRQ A and PIRQ D to different operating systems.

The previous illustration is a conceptual representation that simplifies the underlying hardware. Each PXI slot includes four interrupt pins, int a – int d. These interrupt pins map to PIRQs differently for each slot. For example, the following illustration shows how interrupt pins map to PIRQs on Slot 8 of an 8-slot PXI chassis.

Note  The mapping of interrupt pins to PIRQs varies by chassis. However, the NI Real-Time Hypervisor Manager automatically detects and accounts for this mapping.