AnsweredAssumed Answered

How do I optimize a testplan for speed?

Question asked by SweeChye on Nov 5, 2008
The following techniques can dramatically reduce execution time of a testplan:

1. Use the profiler to determine which actions are taking the most time, either because one action is being called a lot, or because it takes a lot of time to execute. Concentrate on working your way down the pareto chart until no further substantive improvements are possible.

2. Group things that only need to be executed once into a "first-run" scenario. Typically, this will consist of arb downloads, instrument resets and serial initialization. Use the System.RunCount symbol table value to determine when to execute these (and be sure to reset it to 1 in the Error Sequence).

3. Minimize instrument setup changes. For example, keep the voltmeter on the 64 volt range for all tests that don't require high accuracy (you'll still have about 20mV of accuracy).

4. Minimize power supply cycling. They typically take on the order of one second to settle.

5. Do a global reset only inside the first run initializations. Use the watch window to track the ending state of the switching and instrumentation and then make sure your testplan ends in a quiescent state that is as close as possible to a global reset.

6. If using serial communications, use the highest baud rate possible. If using a protocol converter, the baud rate to the DUT may be out of your control, but make sure the baud rate from the PC to the converter is at least 115Kbaud. The Rocketport card supports even higher baud rates.

7. Use the highest speed aperture on the voltmeter. The 10 us aperture, which is used in the "High Speed, Low Accuracy" setting of the dmmMeasureDCV action, still gives adequate accuracy in most cases. Start with that one and change it during debugging if the readings prove to need more accuracy or noise immunity.

8. Use delays judiciously. It is easy to insert a 50 or 100 ms delay into a testplan when a measurement problem occurs. Sometimes this just masks other problems! Revisit every delay to see if it can be reduced or eliminated. If a long delay is needed, see if you can figure out a better measurement method for the test. Instead of hardcoding the delay time, consider using a symbol table value that will allow you to change all delays at once.

9. Collect as many path setups using loadcards as possible in one Switching statement. Each switching statement incurs the 13 ms overhead of relay closures (and again in openings if applicable). Paralleling these is desirable, but remember that separate switching statements will be required if break before make action is desired.

10. Be careful with the digitizer. Don't take more samples than you need.

11. Don't let the operator interface cause events on each test. This incurs an overhead that can really slow down the test.

12. Minimize report window activity. Set the sequencer to report only failures.

13. Improve DUT handling time by using a dual well fixture.  

Outcomes