PXI Express Chassis Selection for Efficient Data Movement and Throughput​

​​When building a test and measurement system, a key factor to take into consideration is how quickly and reliably data can move through the system. Poor planning can lead to missed measurements, slower test throughput, or unexpected and costly redesigns later in the project.

​PXI systems stand apart because they integrate data movement into the chassis backplane using PCI Express (PCIe) technology, enabling high-speed, low-latency communication. This differentiator makes PXI especially well-suited for complex, data-intensive applications compared to stand-alone instruments connected using LAN, USB, or GPIB, as shown in Figure 1. 

^{​Figure 1: Theoretical Bandwidths versus Latencies of Mainstream T&M Buses}

​​For system designers, chassis bandwidth is a defining requirement that impacts overall performance and scalability. Most data in a PXI Express system flows through the chassis, so selecting one that meets current demands while providing room for future growth is one of the most impactful decisions in system design.

​Every PXI Express chassis uses a PCI Express interface to transfer data between the system controller and the PXI modules in each slot. This interface determines how fast data can move to or from each module, defined by two key specifications: generation and lane width.  

​To understand how this interface defines your system’s bandwidth, it’s important to be familiar with the following key concepts, which are depicted in Figure 2:

• Per-slot bandwidth—The maximum data transfer rate between an individual module and the PXI chassis backplane, determined by the PCI Express generation and lane width of that slot.
• ​PXIe segments—Groups of PXI slots managed by dedicated PCI Express switches that distribute data traffic and prevent bandwidth bottlenecks across the chassis and controller.
• ​Maximum system bandwidth—The total data throughput capacity of the chassis backplane to transfer data between all modules or segments and the system controller simultaneously.
• ​Link speed—The data rate of the PCI Express interface connection between two elements of the system defining how fast data can move.

​Figure 2: PXI Express Backplane Architecture: Per-Slot, Segment, and System Bandwidth

​To fully grasp how PXI chassis bandwidth impacts performance, the next section will follow the path of data from the module to the controller, illustrating each stage of the journey and how the backplane facilitates high-speed communication. This perspective shows why bandwidth matters and how it influences overall system efficiency.

Per-Slot Bandwidth

Per-slot bandwidth defines how much data a single module can transfer through its PCI Express connection. Depending on the chassis design, per-slot bandwidth can range from 250 MB/s up to 8 GB/s in each direction, as shown in Table 1. 

^{Table 1: Maximum Per-Slot Bandwidth in NI PXIe Chassis Based on Generation and Lane Width}

Note: The values shown represent theoretical PCI Express maximum per-slot bandwidth. In practice, Gen 1 and Gen 2 typically sustain closer to ~200 MB/s per lane due to encoding overhead, while Gen 3 operates much nearer to its rated limits.

However, most test systems require multiple modules streaming data at once. When this happens, overall throughput is no longer limited only by individual slot performance; it also depends on the aggregate bandwidth across the chassis backplane.

Understanding the typical data rates of different instrument types helps illustrate why aggregate bandwidth matters. As modules operate together, their combined data flow can quickly approach or exceed the backplane’s capacity. Table 2 provides a reference for common instrument data rates.

^{Table 2: Bandwidth Lens per Module}

It is important to note that older, hybrid-compatible PXI modules operate on the original parallel PCI bus rather than PCI Express. Although the theoretical limit of this bus is 132 MB/s, sustained throughput is typically closer to ~100–110 MB/s, no matter the chassis they’re in; because PCI is a shared bus, all modules on the same PXI segment share that bandwidth. 

Some PXI Express chassis, normally with higher slot count, divide the PCI Express backplane into two or more segments, each managed by its own PCI Express switch. This multisegment architecture increases overall data throughput by distributing PCI Express lanes across separate switches, as depicted in Figure 3.

^{Figure 3: PXI Express Backplane Architecture: Per-Slot, Aggregated, and Segment-to-Segment Bandwidth}

The NI Peer-to-Peer (NI-P2P) driver can create high-speed data paths between supported devices within a single segment without taxing system resources outside of the segment, such as using up bandwidth to the system controller slot. Refer to the following Peer-to-Peer section for more information.

Understanding how these segments share and allocate bandwidth is essential for designing systems that sustain high-speed streaming and scalable performance as more instruments operate in parallel.

System Bandwidth

​​In addition to the per-slot bandwidth, another key specification for PXI Express chassis is the maximum system bandwidth. This specification refers to the total sum of all the PCI Express lanes that are connected from the chassis to the system controller and how fast those lanes can move data together. 

​You can find this information in several ways:

• ​If you know how much system bandwidth you need but don’t know which PXI chassis model is the best fit, visit the PXI Chassis category page and filter by Maximum System Bandwidth; an example of filtered results is provided in Figure 4. 

^{​Figure 4: PXIe Chassis Portfolio Filtered by Maximum System Bandwidth}

• ​If you know the NI PXI Express chassis model you have but are unsure where to find its maximum system bandwidth, review its main product page. An example is shown in Figure 5. 

^{​Figure 5: NI PXIe-1088 Product Page}

​If you want to view the complete PXI chassis portfolio for comparison, we recommend reviewing the PXI Chassis brochure.​

Controller Bandwidth Impact

​​For data moving to or from the instruments in the chassis and through the backplane, the system controller slot can become a potential bottleneck. This situation occurs because the maximum system bandwidth sets the upper limit on how much data can get in and out of the host PC, which is where the host memory is and therefore where the application software of the system is running. It’s important that the chassis is not only suitable for each individual I/O module and the amount of data it is going to be streaming through the backplane, but it must also be suitable for how much total data needs to go back and forth through the system controller slot (typically a PXI Express controller, but could be a remote controller communicating using MXI Express) from all of the instruments combined at their peak usage.

​The system controller itself is also a key element in getting data in and out of the host memory where the application code commonly executes, as shown in Figure 6. Therefore, it’s a good idea to apply similar selection criteria to the PXI Express controller as to the PXI Express chassis. Careful planning will ensure that you have the necessary bandwidth everywhere it is needed. For how to select the right controller for your application, read Maximizing PXI System Performance: How to Choose the Right PXI Embedded Controller​. 

^{​Figure 6: PXIe Backplane Architecture: Data Flow Between System Controller and PXIe Chassis Segments​}

Backplane​​ Architecture and Bandwidth Panning

Various PXI Express chassis have different numbers of slots, different slot-to-chassis PCI Express connection speeds, different segment to slot associations, intersegment connection speeds, and differing and even asymmetrical speeds between the system controller slot and the different chassis segments. Take time to understand how much bandwidth you will need at each leg of the system and choose a chassis that gives you plenty of extra margin—both to make it easier to overcome the overhead of protocols and to make it easier to adapt to changing conditions later in the life of the system. We recommend planning for two to three times more bandwidth than you know you need.

​To find detailed information about a chassis backplane:

1. ​Go to the main product page.
2. ​Navigate to Documentation > General and Usage > User Manual. 
3. ​In the User Manual, open the Table of Contents and go to Backplane Overview > Hybrid Peripheral Slots.

^{​​Figure 7: PXIe-1088 PCI Express Backplane Diagram Example}

​The diagram in Figure 7 shows that slots 4, 6, and 8 all have their own separate x4 links to the system controller slot, while slots 2, 3, 5, 7, and 9 each have a x1 link to a PCI Express switch and then share a x4 link to the system controller. In addition, for hybrid modules which utilize PCI, slots 2–5 share a link to the PCI Express switch through PCIe-to-PCI Bridge #1, while slots 6–9 share a link to the PCI Express switch through PCIe-to-PCI Bridge #2.​

​​If it’s not feasible or desirable to push all the data through the system controller, there are alternative ways to reduce the data movement demand on the system. Different techniques have various advantages and disadvantages, but they are important tools to consider when dealing with high data rate applications. Let’s explore some of the techniques.​

Load Balancing Between PXI Express Segments

​​When a system calls for more bandwidth than a single bus can comfortably handle at one time, consider separating the high-bandwidth I/O devices between the segments so the data movement needs are balanced between the segments. 

​The first step to designing around the segments is to look in the user manual for the chassis and find out what the segments are and how much bandwidth is allocated to the controller from each segment. For example, the NI PXIe-1092 manual’s Backplane Overview section provides the diagram in Figure 8, showing the link generation and lane count from the peripheral slots (slots 2–9) to the system controller slot (slot 1):

^{​Figure 8: PXIe-1092 PCI Express Backplane Diagram}

​Figure 8 shows that each slot has a Gen 3 x8 connection to a switch and that the system controller has a Gen3 x8 connection to the first segment (Virtual Switch 0, which covers slots 2–4) and a Gen 3 x16 connection to the second segment (Virtual Switch 1, which covers slots 5–9). Here’s a quick summary of some relevant specifications from the manuals for several PXI Express chassis:

^{​Table 3: Data Movement Comparison of NI PXIe Chassis​}

On-Instrument Data Processing

​​Many NI instruments feature configurable onboard logic such as NI FlexRIO as well as reconfigurable devices that can do FFTs or other forms of intelligent data processing before moving the data across the PCI Express bus. This preprocessing can greatly reduce the necessary bandwidth demanded from chassis and controller.​

Peer-to-Peer Streaming

​​Many of the higher-speed NI instruments support data streaming directly between instruments without going through host memory or even leaving their PXI Express bus segment through an API called NI-P2P. Using NI-P2P can be very helpful when you need to do a large amount of data processing in real time and the data is coming from multiple instruments—or when the I/O instrument doesn’t have sufficient onboard processing itself, but an NI PXI Express coprocessor, such as PXIe-7903 or PXIe-7915, does. When NI-P2P is a good solution for the system, it’s helpful to keep the instruments that need to share data with each other in the same segment of the same chassis since it reduces the burden on neighboring bus segments and incurs lower overhead from the PCI Express switches. See An Introduction to Peer-to-Peer Streaming for more information.​

DMA FIFOs to Host Memory

​​For devices that support direct memory access (DMA) to host memory, DMA can be a very helpful way to avoid burdening the host processor to manage all the memory I/O in real time. Normally the host would directly manage all of the writes and reads to the memory, but DMA allows the host to establish a direct link between an assigned portion of memory and the device that needs to stream, so the burden on the host looks more like a one-time configuration step rather than a continuous memory management operation. This strategy can have a profound performance improvement by decoupling the application software execution from a large portion of the data movement overhead. ​

In this section, we’ll review some test systems examples along with the rationale for the products selected for each. 

Mixed Signal and DAQ Selection Example

​​Let’s look at an example test system and see how we might start with I/O choices and move from there to chassis selection and finally to slot choices for the I/O devices that will be in the selected chassis.

​First, let’s make a list of the I/O devices in our example system along with their theoretical data throughput needs. 

​The max data rate for a module is given by: 

​We’ll choose some arbitrary channel counts and rates in Table 4 for the sake of the example.

^{​Table 4: Mixed Signal and DAQ PXI Modules} 

​Note that the rates and channel counts are based on the system designer’s choice in the application, but the data width and the onboard buffer size (we’ll get to this in the next step) are specifications of the module and/or driver. 

​For example, the PXIe-5423 specs declare that the DAC resolution is 16 bits.

^{​Figure 9: PXIe-5423 Analog Output Specifications} 

​Note: By default, DAQ modules, such as PXIe-6396, pad samples up to either 16 bits or 32 bits for latency and overhead performance. So even though the PXIe-6396 has 18-bit resolution samples, it uses 32 bits on the bus unless you enable onboard compression, which can affect sample latency. 

​For another example, the PXIe-5172 specifications state the onboard memory (used as a buffer for samples) is 1.5 GB for the 8-channel version.

^{​Figure 10: PXIe-5172 Onboard Memory Specifications} 

​Since some of these I/O devices could potentially generate large amounts of throughput (upwards of 4 GB/s), we know that data rates are potentially large enough to put hard requirements on our chassis selection. This requirement means we’ll need to dig deeper before resolving which chassis are a good fit. We’ll want to have two to three times more bandwidth than the max throughput that the system will require (if possible) so that we can easily overcome bus overhead and future upgrades without having to rearchitect the system.

​The next step in understanding the data movement needs of this application is to find out if any of these devices are going to need to stream data in this application. Generally, this is resolved in two parts: first, by considering if the length of acquisition/generation will exceed the onboard buffer size of the instrument, and second, by resolving whether the application requires streaming data between instruments with any particular latency requirements.

​To calculate how large of a buffer is needed, we take how long the longest duration acquisition or generation will need to be and multiply by the max data rate to determine the size of the data stream. Then we compare the size of that data stream to the size of the onboard buffer on the device. For example, if we are using PXIe-6569 for brief sessions of 10 ms at a time, then for the rates we calculated above, we would use 0.010s × 5 GB/s = 50 MB for the output buffer and 0.010s × 4 GB/s = 40 MB for the input buffer. That totals 90 MB. The PXIe-6569 has 4 GB of onboard DRAM, so at these rates and channel counts and for a duration of 10 ms, the onboard memory is sufficient in size to serve as a buffer without needing to worry about the PCI Express bus bandwidth. Essentially, the output data will be pre-loaded or generated in the FPGA of that device and the input data can be transferred off the device whenever the acquisition is complete without overrunning the onboard buffer. In other words, the backplane doesn’t need to be as fast as the instrument since it can move the data before for write data or afterward for read data. However, if the duration of the acquisition/generation exceeds the onboard buffer capacity, then we know our backplane will need to stream data at rates to keep up with the instrument. 

​As previously described, we also need to consider latency. Does the application have a need to transfer data to the host or to another instrument with any specific latency requirements? If there is a latency requirement, there’s a good chance that we need to stream data in real time between the host and our instrument. That would also be a reason why the backplane’s bandwidth will need to keep up with the instrument—even if we have sufficient buffer capacity that we wouldn’t have been concerned about streaming bandwidth.

​For the sake of this example, let’s say we’ve assessed the design and figured out which of these instruments relies on streaming across the backplane in real time. 

^{​Table 5: Streaming Requirements for Mixed-Signal and DAQ PXI Modules}

​Additionally, we should understand if these streams are simultaneous with each other. For the sake of this example, let’s say they do need to be simultaneous. 

​At this point, we know enough to place requirements on our chassis selection. We need a chassis that can support at least 2.9 GB/s in and 2.5 GB/s out simultaneously. Since input and output are largely independent in bus utilization (there is some difference in bus overhead, but we’ll neglect it in this example) we can focus our requirement on the more demanding rate of 2.9 GB/s in. This means ideally, we’d use a chassis with two to three times that maximum slot and system bandwidth which would be ~6–9 GB/s. Therefore, we are looking for a chassis with Gen 3 x8 (which is 8 GB/s) connection to a slot. This criteria refines our list of options to the PXIe-1085, PXIe-1092, and PXIe-1095 chassis.  

​Since our application requires 10 slots of instrumentation, that further excludes the PXIe-1092, which only has eight slots for instruments. So, we’d choose between the PXIe-1085 and PXIe-1095.

​If the application did not require streaming at these rates from the PXIe-6593, that could expand our list of suitable chassis to include the PXIe-1084 or PXIe-1086—which would be enough for the 336 MB/s of the PXIe-6396. 

​If the system instead had additional simultaneous streaming needs, such as three units of the PXIe-6593 from this example instead of just one. They would individually fit within PCIe Gen 3 x8 per slot but added together exceed the capability of a Gen 3 x8 link from the segment to the controller. We’d have to consider how to distribute those data-stream intensive modules across multiple segments and ensure that we have enough total bandwidth to the system controller. In that case, we would need a PXIe-1085 or PXIe-1095 chassis and we’d put a PXIe-6593 in the segment that has a Gen 3 x8 link to the system controller. The other two would go into the segment that has the Gen 3 x16 link to the system controller.​

DAQ Example

​​For another example, let’s look at a HIL-focused DAQ system centered around the NI PXIe-6357. For this example, we’ll say that we need 2,000 channels of analog input, 10 channels of analog output, and 120 channels of static digital input and 80 channels of digital output. We’ll also say that our application runs around a 1 ms loop rate. So, we will want to sample at 1,000 Hz.

^{​Table 6: HIL-Focused DAQ System Channel Counts and Data Rates}

​In this example system, there is a large channel count, but not a massive data throughput need. All the inputs added together total 4.15 MB/s and all the outputs total just 0.12 MB/s. This is a low enough throughput that it could be done with any NI PXIe chassis. 

​However, since we are using the PXIe-6357 with the need for 2,000 channels of analog input, we will need at least 10 units of PXIe-6357, which would push us toward a chassis with at least 10 slots available for instrumentation.

​Based on that requirement, we can choose between the PXIe-1081, PXIe-1084, PXIe-1085, PXIe-1086, and PXIe-1095 chassis and be confident that we can resolve the data movement needs of the application with any of those chassis models.​

Choosing a chassis is a key element of modular test system design. For PXI, this can affect everything from size, power available per slot, and timing and sync capabilities, to PXI-hybrid module support, operating conditions, and data movement capabilities. Efficient data movement within the chassis is fundamental to achieving reliable performance in PXI-based test systems. 

Selecting the right PXI Express chassis for data movement requires considering both individual modules in the system as well as total system throughput. Engineers should evaluate per-slot bandwidth needs, understand segment distribution, and ensure sufficient system bandwidth to support all instruments that will operate simultaneously. Equally important is choosing a PXI Express controller that matches the chassis capabilities.

To avoid data movement bottlenecks, NI provides several strategies such as load balancing across PXI Express segments, using peer-to-peer (P2P) streaming for direct instrument communication, and leveraging onboard or FPGA-based processing to offload data handling from the host.

When properly planned, PXI systems built on the NI modular platform provide a robust foundation for scalable, high-throughput test applications. 

To select the right NI PXI chassis for your application:

• Use the PXI Chassis shop page to filter by Maximum System Bandwidth.
• For a complete comparison across PXI Chassis portfolio, download the PXI Chassis brochure.
• If you already know the chassis model, review its Product page.
• For detailed backplane diagrams and bandwidth specifications, review the chassis model’s User Manual. Access it through the model’s main Product Page > Documentation > General and Usage > User Manual > Backplane Overview > Hybrid Peripheral Slots.

We offer a full portfolio of NI PXI Express chassis, controllers, and modules, along with expert support to help you design systems that meet today’s demands and scale for tomorrow. Explore our resources or connect with an NI engineer to get started.

• PXI Advisor
• Learn more about NI PXI Chassis Design Advantages
• Learn more NI PXI Timing and Synchronization Design Advantages
• Accelerate Validation Workflows with a Flexible, Modular Lab​