Some types of conventional computer systems are used to manage hardware resources to perform particular tasks. Example hardware resources include stimulus resources and measurement resources. Stimulus resources apply stimuli to one or more devices. For example, a stimulus resource can apply a voltage or a current to a device, such as a circuit, switch or relay. In turn, the device can direct a voltage or a current to a particular site, or direct pneumatic or hydraulic fluid to move mechanical arms. Measurement resources sense or measure a response from a device. For example, a measurement resource can include a sensing circuit that provides precise voltage or current measurement values, or bits of information that indicate the location of an arm.
Generally, the computer system sets stimulus resource values prior to calling a measurement resource. Often, the computer system must delay performing the measurement operation while waiting for the stimulus to settle to a stable value or state. This delay time is referred to as a settling time delay. Multiple stimulus resources introduce multiple delay values that must be managed to optimize the time it takes to perform a particular task or series of tasks.
In one type of computer system, referred to as a circuit test system, stimulus resources apply stimuli to an integrated circuit and measurement resources measure the circuit's response. Stimulus resources provide stimuli in the form of logic levels or analog voltages and currents. Measurement resources take measurements of logic levels, analog voltages and currents, and timing values.
Circuit test systems perform tests on a circuit, referred to as a device under test (DUT). Example types of tests performed by a circuit test system include DC parametric tests, functional tests, and AC propagation delay tests. Parametric tests check DC voltage and current handling characteristics of inputs and outputs. Functional tests check DUT functionality using test vectors, which preferably exercise all functional aspects of the DUT. Propagation delay tests check the time it takes for a signal to propagate through the DUT, referred to as the AC characteristics. Often, each test type is performed multiple times under different conditions. Hardware resources are typically changed for each test.
A user, such as a test engineer, typically supplies a test program to test a DUT in a particular test sequence. The test program includes instructions that change hardware resources to accomplish testing. This test program is loaded onto the test system and executed to alter hardware resources and test a DUT. In one example sequence, the test program first supplies instructions to power the DUT at a selected source voltage. Source current is measured and checked against limits to detect shorts and opens on the power line. After a DUT has passed this test, DC parametric tests are performed to check the integrity of each input and output. The DC parametric tests are performed by applying selected voltages and currents to particular input and output pins. Test vectors are often employed to obtain proper testing states at the output pins. The test system measures current and voltage values from selected pins.
After DC parametric tests, functional tests are performed. Functional tests can include stepping through a set of test vectors where selected logic levels are applied to input pins, and output pins are checked against expected logic states. A functional test can be performed multiple times with different voltages on the power pin. Next, propagation delay tests are performed to ensure the DUT operates up to speed. Often, when hardware resources are altered, the test system must wait for the voltage or current to settle before taking a measurement. Waiting for the voltage or current to settle helps to ensure an accurate measurement, but increases test time and raises device cost.
Test engineers write test programs to optimize the balance between testing accuracy and speed. Test system manufacturers publish tables of hardware resource settling time delay values. These settling time delay values are usually worst case settling times for hardware resources. In one optimization method, test engineers write test programs to provide a delay after each resource change, which results in long test times. In order to reduce these test times, test engineers typically measure settling times and use measured delay values instead of published delay values. Using the measured delay values ensures accurate measurements and reduces test time.
In another method, test engineers change multiple resources before providing one delay value for all changed resource settling times. In this method, test engineers use the longest settling time for all changed resources. This settling time is taken from a published table or, to reduce test time further, the test engineer measures settling times for all changed resources and chooses the longest measured settling time. However, measuring settling times can be a time consuming and frustrating task, especially, if settling times change from one test system to another. In each of these methods, test program instructions are not executed while the resources settle. Also, the burden of optimizing the test program is placed on the test engineer.
In an effort to reduce the burden on the test engineer, test system manufacturers typically include a settling time delay at the end of each function that changes a hardware resource. However, this causes the test system to incur a settling time delay for each hardware resource change. To allow for multiple resource changes before a single delay, test system manufacturers provide test engineers with a switch to shut off the delay for a particular resource change. Using the switch, the test engineer can set one delay for a group of resource changes. However, the burden is still on the test engineer to figure out which delay or group of delays to use. Also, the test system cannot process instructions while the hardware resources settle.
For reasons stated above and for other reasons presented in the description of the preferred embodiments section of the present specification, an improved delay management system is desired that does not have the above problems associated with using published tables of settling time delay values, measuring settling times, and/or placing the optimization burden on the test engineer.