Asynchronous Testing Increases Throughput

Asynchronous Testing

But if you carefully examine your functional-test requirements, you might find that you can significantly improve throughput by performing asynchronous testing with your existing test hardware. In many test scenarios, different types of parametric tests require different types of test resources. Therefore, during any given instant using the traditional single or parallel synchronous test methodology, certain test hardware will be idle.

Asynchronous testing techniques let you use your test resources more efficiently, and they can help increase test speed in two scenarios:

• when you test several DUTs at the same time, making different types of measurements on each using independent instruments. For example, POTS-related analog tests and bit-error-rate (BER) datacom tests require separate instruments, which you can independently and simultaneously apply to two ADSL modems under test.

• when you test one DUT at a time but make different, independent measurements simultaneously. For example, you could use different sets of instruments to simultaneously test the POTS and BER performance of a single ADSL modem under test.

In the first scenario, you handle DUTs independently; instrumentation availability alone determines which measurements can run at a particular time. For the second scenario, measurement dependencies within the DUT itself can influence test (for example, if the DUT’s analog tests require some digital setup, you might not be able to cleanly divorce the operation of analog and digital instrumentation).

Figure 1 shows a hypothetical test scenario in which four groups of tests use four different sets of hardware or other resources. For this example, you can develop a fixture to connect four different DUTs to the system hardware. Using synchronous testing, the test hardware for tests B, C, and D remains idle when test A executes, the test hardware for tests A, C, and D remains idle when the B tests execute, and so on.

Figure 1. In this example, measurements A, B, C, and D require separate sets of instruments in a functional-test system. In a synchronous test approach, three sets of instruments lie idle while the other set performs a measurement. In asynchronous testing, the four instrument sets can operate simultaneously.

Figure 2. The fourfold throughput improvement suggested by Figure 1 is rarely achievable in practice, because test sets require different amounts of time, and the time required for a given measurement may vary depending on DUT response. This illustration provides a more realistic indication of throughput increases than does Figure 1’s ideal representation.

Using asynchronous testing in this example more efficiently uses the available test hardware. In fact, only during the initial test start up is there any idle test hardware. In the example shown in Figure 1, for the period from t₀ to t₁, asynchronous testing affords two and a half times better throughput than synchronous testing with essentially the same test hardware. The actual throughput advantage could improve to almost four times depending upon the amount of time you continuously run the test system.

Of course in the real world, the test groups are never perfectly symmetrical (Fig. 2). A given test group never takes the same amount of time as the others, and that time may vary depending on the response from the DUT.

As you can see in Figure 2, some idle periods exist when one DUT may not be finished with a set of test resources at the time another DUT is ready for those same resources. For example, the test system first allocates the necessary resources for performing test A to DUT 1, followed by allocation to DUT 1 of the resources necessary for test B. When DUT 1 no longer requires the test A resources, the system allocates those resources to DUT 2.

Similarly, when DUT 1 finishes with the test B resources, the system allocates those resources to DUT 2. Note, however, that because test A requires less time than test B, DUT 2, having undergone test A, is ready for test B resources before DUT 1 is finished with them. Therefore, DUT 2 must wait for DUT 1 to finish with the hardware for B.

This example assumes that each DUT position shares the test equipment used for tests A, B, C, and D. A combination of shared (“critical”) and DUT-specific (“noncritical”) instruments can help to minimize the test gaps. Critical resources generally include expensive instruments that you don’t want to duplicate for each DUT position. But when determining which test resources should be shared and which should be dedicated, base your decision on more than just test-hardware costs. Try to allocate your equipment so there is little or no test gap for any DUT and little or no idle time for any test resource.

Formulating an Approach

Implementing an asynchronous testing scheme requires a different approach in certain processes from the one used in typical synchronous or parallel test strategies. For asynchronous testing, you must

• generate a separate test report for each DUT. Standard test reports typically contain a jumble of results for all DUTs. By creating a separate report for each DUT, you can group the information into an easy-to-read and easy-to-evaluate format.

• store the common outputs for each measurement in a common location, in addition to generating a separate report for each DUT. Because the idea is to test hundreds or thousands of DUTs and not just the number of DUT test positions available to the tester, logging each DUT position directly from the separate test reports would provide multiple logs of measurement results. To obtain a complete test history of all DUTs tested, the information will have to be combined into a common database.

• synchronize the DUTs’ requests for the instrumentation. With the appropriate synchronization, more than one DUT cannot access the same critical instrumentation at the same time. To synchronize the use of the equipment, you must assign a global semaphore flag to each instrument.

• devise a straightforward strategy for initializing and controlling the different measurement tasks (threads). A multithreaded environment is ideal for this task; when testing multiple DUTs, the main thread executes the main sequence, and then the main sequence spawns a new thread for each measurement channel.

• design a creative switching scheme and independent DUT-control mechanism. When designing the switching algorithm for test strategies that either use a common set of instrumentation to asynchronously test multiple DUTs or use multiple types of instrumentation to asynchronously test a single DUT, the switching must account for all possible simultaneous connections. A well-placed switching algorithm ensures complete test coverage with no gaps in testing due to switching.

Sequence Control Flow for Testing Multiple DUTs

As each DUT executes a critical test group, the test group is locked and then unlocked when the test group either completes or a time-out occurs because of an error. Once a critical test group locks, no other DUT can access those tests until the locking DUT unlocks the test group. Figure 3 illustrates how a multithreaded environment can support asynchronous testing of multiple DUTs.

In Figure 3, the main sequence, also called the parent process, loads and then spawns subsequences, which are also called child processes. When you are testing several DUTs at the same time with independent instruments, the main sequence (or parent process) executes the test on a DUT-by-DUT basis. Each DUT undergoes tests A through D. For this example, all the subtests defined by test A use the same set of test equipment for all DUTs; all of the subtests defined by test B use a different set of resources for all DUTs; and so on.

To synchronize the usage of the system instrumentation, use the semaphore flag you assigned to each instrument. A semaphore flag is a program object that limits the number of processes that have access to a shared resource at the same time. This flag indicates the status of the instrument: either “in use” or “not in use.” For each instrument, the test checks the flag before using the instrument. If the flag indicates “instrument in use” status, the test waits until the flag indicates “instrument not in use” status. Then, the test can get access to the instrument.

Sequence Control Flow for Testing One DUT

Ed Mazza is the marketing manager at Wandel & Goltermann A.T.E. Systems. E-mail: ed.mazza@acterna.com.  

Using a Test Executive for Asynchronous Testing Figure A. This ATE system asynchronously tests four OC-3 DLC cards using National Instruments’ TestStand test executive. The system shown in Figure A asynchronously tests four OC-3 digital line cards (DLCs) using National Instruments’ TestStand test executive. The resources for this test system include both critical and noncritical components. The critical components include a power meter, optical switches, a frequency counter, and a DMM. The noncritical components include optical transmitters and receivers and an actuator that loads and connects the DUTs into each test position as instructed by the test sequence. Figure B shows the main TestStand sequence. The main sequence spawns four subsequences: one for each DUT. Each subsequence is a continuous loop and starts by instructing the user to load a new DUT into position. If the user does not load a new DUT, then the program cancels testing in that DUT position. In addition, each DUT’s subsequences then run the identical set of tests consisting of critical and noncritical components. Once the user cancels testing a DUT, the main sequence goes to the Wait DUTn step that waits for the corresponding RUNSEQDUTn step to complete. Once this subsequence completes, the program frees the resources used by that DUT. —Ed Mazza Figure B. A test executive establishes the sequence of tests required for an asynchronous test technique.