Error detection/correction and fault detection/recovery – Pulse or data error handling – Digital logic testing
Reexamination Certificate
2000-07-10
2002-09-10
Decady, Albert (Department: 2184)
Error detection/correction and fault detection/recovery
Pulse or data error handling
Digital logic testing
C714S038110, C714S033000
Reexamination Certificate
active
06449744
ABSTRACT:
This invention relates generally to automatic test equipment, and more specifically to a software environment for facilitating the development, execution, and documentation of tests performed by automatic test equipment.
Automatic test equipment, also known as a tester, is commonly used to test both semiconductor devices and assembled printed circuit boards to determine whether the devices and boards are defective.
In general, a tester operator develops test signals and test sequences on the tester for subsequent testing of a unit under test (UUT), which may be either a semiconductor device or a printed circuit board. The tester operator then enters commands to start a test, thereby causing the tester to apply the test signals to the UUT and receive output signals produced by the UUT in response to the applied test signals. The tester then typically compares the received output signals with stored expected values. The tester also typically measures various parameters associated with the UUT, such as the amount of current drawn during various operating conditions or the frequency of various output signals, and then compares these values with other expected values. If any of the received signals or measured values do not match corresponding expected values, then the tester typically indicates that the UUT has defects.
The UUT may include just digital or analog circuitry, or both types of circuitry. A UUT that includes both types of circuitry is generally known as a mixed-signal device, and testers that test these devices are generally known as mixed-signal testers.
Such mixed-signal testers are commonly configured with a workstation and several instruments, which are connected to either nodes or primary inputs/outputs of the UUT. The workstation typically controls the instruments via a standard buss, and the instruments typically apply test signals to the UUT, acquire output signals from the UUT, and make any required measurements on the UUT. Some of the instruments may be only used for digital tests, while other instruments may be used just for analog tests. Still other instruments may be used for providing DC signals or power to the UUT. Further, the different instruments are frequently acquired from different instrument manufacturers.
FIG. 1
shows a block diagram of a tester
100
, which includes a workstation
102
that controls a plurality of instruments such as instruments
130
,
132
, and
134
through a buss
110
. Further, the instruments
130
,
132
, and
134
are coupled to nodes or primary inputs/outputs of a UUT
112
.
The workstation
102
has a typical software configuration
101
, which includes a controller module
106
, a plurality of test generation tools such as a tool
104
, and a plurality of instrument drivers
120
,
122
, and
124
. Each of the software modules in the software configuration
101
might be created using a textual programming language such as C
++
or BASIC. The software configuration
101
might alternatively be implemented using a graphical programming system such as the LabVIEW™ system sold by National Instruments Corporation, Austin, Tex., USA, or the HP VEE™ system sold by Hewlett-Packard Company, Palo Alto, Calif., USA. In this case, the controller module
106
typically implements a user interface on a display monitor (not shown), and the tester operator typically specifies tests to be performed on the UUT
112
by manipulating graphical representations on the display monitor using an input device (not shown) such as a keyboard or mouse. It is generally recognized that computer-based systems that deal with information in a graphical or visual manner are more desirable than those that rely on textual formats.
The drivers
120
,
122
, and
124
communicate with respective instruments
130
,
132
, and
134
via the buss
110
, which is generally compatible with an interface standard such as HP-IB (IEEE-488), VMEbus, or VXIbus (VMEbus Extensions for Instrumentation). Further, because the UUT
112
may include digital or analog circuitry or both, some of the instruments
130
,
132
, and
134
may be suited for transmitting/receiving digital signals while other instruments may only deal with analog signals. Still other instruments may provide any necessary DC signals or power to the UUT
112
.
During a typical test session, the tester operator uses the test generation tools for specifying digital and/or analog test signals and corresponding expected values. The digital test signals may be applied to a simulator
108
, which typically simulates the logic functionality of the UUT
112
and provides patterns of expected output data to the workstation
102
. These patterns reflect the output signals that would be produced by a properly functioning UUT in response to the digital test signals. The tester operator then typically saves the specified test signals and corresponding expected values in a database (not shown) included in the workstation
102
.
The tester operator also uses the test generation tools for specifying sequences of steps to be performed when testing the UUT
112
. For example, steps in a simplified test sequence may include first applying power to the UUT
112
. Next, various digital tests may be performed on the UUT
112
followed by analog tests, or vice versa. The final step in the test sequence may include removing power from the UUT
112
.
Although the tester
100
has been successfully used for testing semiconductor devices and printed circuit boards, it has some drawbacks. For example, it was described that it is frequently necessary to develop both analog and digital tests for mixed-signal devices or boards. This means that different sequences of steps must be followed in both the development and the execution of the analog and digital tests. Further, the increasing densities of semiconductor devices and printed circuit boards have added a high-level of complexity to the development of such test sequences.
However, the tester
100
lacks features for facilitating the development and execution of these complex test sequences. For example, it was mentioned that graphical programming systems such as LabVIEW™ and HP VEE™ might be used to implement the typical software configuration
101
. Such graphical programming systems can be used to implement both user interfaces and test sequences. In particular, the user interfaces might include graphs, drop-down lists, pop-up menus, and graphical representations of knobs, switches, and slides. Further, the test sequences might be graphically represented by block diagrams.
But, these graphical programming systems are primarily useful for specifying test sequences as lists of steps. They are not particularly useful for grouping related steps or for specifying which groups of steps are to be performed in a test. Also, they generally lack features for specifying steps or parameters that might be common to different groups of steps. Also, they generally do not clearly convey the organization of test sequences involving such groups of steps through the user interface. We have recognized that these drawbacks restrict the tester operator's ability to develop and execute tests for complex devices and boards such as those having both digital and analog circuitry.
Further, the tester
100
lacks features for facilitating the access of documentation relating to a test. Although testers designed using the LabVIEW™ and HP VEE™ graphical programming systems include features for documenting the design and structure of test sequences, they generally do not have features for easily accessing user manuals and other documentation. They also generally do not clearly convey the organization of such documentation through the user interface.
Another drawback of the tester
100
is that the software modules included in the typical software configuration
101
cannot be easily interfaced with other software modules. This is because the software modules are generally implemented with non-standard software constructs such as dynamic link libraries (DLLs). The main shortcoming of such
De'cady Albert
Lamarre Guy
Rubenstein Bruce D.
Teradyne, Inc.
LandOfFree
Flexible test environment for automatic test equipment does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Flexible test environment for automatic test equipment, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Flexible test environment for automatic test equipment will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2909634