PCI Express – Espresso for test systems
Larry Desjardin- February 19, 2012
National Instruments recently released its 2012 Automated Test Outlook. It is interesting reading, and there are five macro trends they call out. For this blog post, I’d like to focus on Trend #3: PCI Express as an External Interface Bus. I will be using the shorthand “PCIe” when referring to PCI Express. About this trend, I recently wrote this:
The low latency, bus speed, and direct memory-mapped architecture of PCIe is what enables the speed advantages of modular instruments. Not just for PXI, AXIe has embraced PCIe too. We’re seeing PCIe added to traditional box instruments as well, though principally as a data streaming interface. Joining NI, Agilent has added PCIe I/O as part of their standard I/O library. The one impediment to PCIe becoming truly mainstream is the ease of use: it is significantly harder to configure a PCIe-based system, and many computers don’t treat the interface robustly. Solve this, and PCIe is off to the races.
Let me add more why I think PCIe is like your test system downing a dozen espresso shots.
It’s all about speed. Blazing speed. Comparisons of bus bandwidth of GP-IB or LXI (Ethernet) to PCIe don’t capture the true advantage of PCIe for functional test: radical reduction in test times due to command interpretation latency. Here’s the deal:
Functional test systems are dominated by a series of single commands and single measurements. For example, this may be the sequence for a single test out of hundreds in a manufacturing test system:
-Change one or more digital inputs
-Apply one or more new signals
-Make the measurement
-Return the measurement result and compare against expected values
In a traditional test system all those commands between the controller and the instruments are sent as SCPI commands (Standard Commands for Programmable Instruments), which are English words and ASCII numbers. Here’s the rub. Computers and instruments don’t natively understand English and ASCII. Speed-wise, it really doesn’t matter whether those commands are sent over GP-IB, LAN, or even RS-232 for that matter, the speed to execute the command is dominated by the processing time of the instrument.
Let’s look at a single measurement sequence. First, the instrument receives the English command, changes ASCII numbers to binary, and then parses the command. This takes milliseconds. It then performs the intended command by accessing internal registers and making a measurement, which may take only microseconds. The process is then reversed: The instrument converts the binary results to an ASCII number, and sends it back to the controller. More milliseconds. But the controller doesn’t understand ASCII; it changes it back to binary. More time passes. Finally, the controller compares the result to the expected value. The entire sequence takes multiple milliseconds, though the measurement itself only required microseconds.
This is where PCIe rocks the speed advantage of PCIe is most apparent. Not particularly due to the bus speed, but due to its programming paradigm. There is no SCPI. Instead of interpreting SCPI commands in real time, a call is made to a driver. The driver immediately accesses the registers due to the memory-mapped nature of PCIe, performs the measurement, and then the controller reads the result as raw binary data. The entire ASCII English command bottleneck disappears. And it’s blazingly fast.
Don’t believe me? Agilent is reporting that their PXI DMM (Digital Multimeter) interactive speed (send a command, measure, get a result) is 66 microseconds. You couldn’t even send the first command character over LAN in that time. This is approximately 50 times faster than the fastest single measurement speed for an LXI DMM. And that’s just for a DMM, imagine the speed improvements when using other instruments!
Box instruments often work around this by offering “List mode”, a method where the tests are downloaded and parsed ahead of time. The instrument sequences through the tests using hardware triggers at run time. This works for some niche applications where tests are always executed in exactly the same order, but it also limits flexibility. There are no conditional jumps, and it’s difficult to synchronize more than two instruments to the same sequence.
Don’t get me wrong. SCPI is a great instrument standard and easy to use. But you pay for it in speed. If your tests aren’t speed critical, by all means use it. It’s like drinking decaf.