Choosing the ideal number of devices to test in parallel is depends upon the time allocation of the current test plan. As an example, consider a traditional configuration for testing a single device at a time and where the RF instrument is active half of the time. Then, ideally, one can use this instrument during its idle time to test another device. This way, things like the first DUT booting can happen whilst the second device is measured and vice versa. Typical setups handle between two and ten devices. The exact number and how much more test throughput one can achieve may only be evident after careful inspection of the test procedures. For example, one should identify bottlenecks in the setup and software in terms of data bandwidth and the possibility of parallelizing individual test steps. Let us consider this next.
Writing and running multi-DUT tests
In order to efficiently pipeline a manufacturing test plan, one must carefully examine dependencies between individual steps that may use the same instrument. For example, the test procedure may use a vector signal analyzer for calibration as well as for transmitter testing. Then, if the test executive software performs transmitter tests on the first DUT, it must delay calibration procedures for a second DUT until the tests on the first device conclude. Modern test executives such as TestStand can handle such dependencies but rely on test designers to modularize their test code appropriately. The basic structure should be along the broad general test phases identified earlier: DUT loading and start-up, calibration, and RF verification. Within each phase, the designer should break up the code further to identify all instrument calls. Some examples are the steps of signal generation, capturing RF data on an analyzer instrument and subsequent processing on a computation unit. Structured accordingly, the test code consists of several sections that can run in parallel and several sections for which execution – that is, access to the measurement instrument – must be scheduled in sequential order.
The test executive software itself – which controls the test flow – is another important element of optimizing test time. For multi-DUT testing, one will likely require the possibility for multi-threaded sequence execution. This is useful in instances where the actual acquisition of measurement data by the instrument is much faster than the subsequent analysis on a processing node. In such cases, the analysis phases of multiple tests, if run subsequently one-by-one, would limit the test throughput and cause the instrument to run idle unnecessarily. Parallelization of these processing phases avoids this bottleneck because data acquisition can proceed while the analysis of previously taken samples still runs on. Multi-threading allows test designers to write simple code for individual test steps such as measurement acquisition and subsequent analysis, and allows the test executive to handle parallel processing of multiple measurements. Naturally, parallelization also requires multi-core computing resources like those available with state-of-the-art PXI controllers.
Auto-scheduling is another feature of advanced test executives. The software itself changes the order of execution of self-contained tests or test steps to maximize instrument utilization and throughput (Figure 4).
The widely adopted NI TestStand has all these powerful features. As off-the-shelf test management software, it allows test designers to easily update test sequences and enables them to re-use test code for future DUTs.