Electricity: measuring and testing – Measuring – testing – or sensing electricity – per se – With rotor
Reexamination Certificate
2000-07-12
2002-04-30
Sherry, Michael J. (Department: 2858)
Electricity: measuring and testing
Measuring, testing, or sensing electricity, per se
With rotor
Reexamination Certificate
active
06380730
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates in general to integrated circuit (IC) testers and in particular to an IC tester having a memory for recording data indicating the status of a test program being executed.
2. Description of Related Art
Failure Analysis For Program Context
A typical integrated circuit (IC) tester organizes a test of a digital IC device under test (DUT) into a succession of test cycles. During each test cycle each tester channel may send a test signal to a DUT terminal or may sample DUT output signal at a DUT terminal to determine whether it is of an expected state. The sequence of activities carried out by each tester channel is determined by a sequence of data values (vectors), each defining the actions the tester channel is to carry out during one cycle of a test. Since tests can span many millions of test cycles, a vector sequence may include many millions of vectors. Since a tester would require a very large vector memory to store such a large vector sequence, many testers use algorithmic pattern generators to produce the vector sequences as they are needed during a test. An algorithmic pattern generator includes a program memory for storing a program for generating a sequence of data. An instruction processor included in the pattern generator executes the program to produce the data sequence during a test. The data sequence can be used directly as a vector sequence or to control addressing of a vector memory that reads out vectors as needed during a test.
Vector sequences (or vector memory addressing sequences) for many tests include repetitive sections that are more efficiently represented by repeat, loop and subroutine call instructions. For example a section of a vector sequence having 1024 successive one-byte vectors of value X can be represented in an algorithmic program as an instruction such as “REPEAT 1024 X”. Depending on the manner in which it is encoded, this instruction can be represented in a program by a few bytes instead of 1024 bytes.
A entire section of a vector sequence that is repeated can be represented as an instruction loop. For example a 4096 byte section of a vector sequence in which four one-byte vector sequence W, X, Y and Z is repeated 1024 times can be represented with a relatively few bytes by the following lines of code:
LOOP 1024
W
X
Y
Z
LOOPEND
A sequence of 26 vectors A, B . . . Y, Z that is repeated at many different locations throughout a main vector sequence can be represented in a program as a single callable subroutine. In such case the 25-vector sequence need only appear once in the program; each occurrence of the 26-vector sequence may be represented in the program by a simple subroutine call instruction requiring only a few bytes.
While algorithmic pattern generators allow IC testers to avoid having to store large vector sequences, they make it more difficult for test engineers to analyze test results. The vector each tester channel receives before the start of each test cycle indicates the DUT output signal state the tester channel is to expect during the test cycle. If the DUT output signal fails to match that state, the channel asserts an output FAIL signal that is processed to provide test results data to a test engineer. In addition to learning whether a DUT has failed a test, a test engineer often wants to determine why the DUT failed the test. To do that, the test engineer would like to know both the DUT output terminal failed and the point in the test program at which the failure occurred. That last bit of information, the “program context” of a failure, tells the test engineer the conditions under which the DUT failed.
IC testers can typically tell the test engineer the test cycle in which a particular DUT output signal failed. When testing an IC, an IC tester usually maintains a count of the number of test cycles it has carried out, and when one of the tester channels asserts a fail signal during some particular test cycle, the tester produces output data indicating both the channel that detected the failure and the current test cycle count.
When we know the test cycle in which the failure occurs, it is usually possible to determine the point in the test program that caused the DUT failure. However when the test program contains many repeats, nested loops, and subroutine calls it is not easy to do that quickly. Failure analysis software designed to locate a point in a program that produced a vector for a particular test cycle typically simulates execution of the test program while keeping track of such information as the current program memory address, repeat count, loop count values, stack contents etc., until it reaches the test cycle of interest. This information can then be used to determine the particular point in the program at which the DUT failed. However it can take longer for the simulation software to find the point of interest in the test program than it did for the tester to test the DUT. What is needed is a test system that provides sufficient information to enable a test engineer to quickly determine the program context of a test failure.
Some testers permit conditional branching during a test in response to test results, and in such case the course of the test depends on how the DUT behaves during the test. When a tester program is subject to conditional branching, failure analysis software cannot determine the program context of a failure from the cycle count because it does not have access to the test results that controlled branching during the test. Thus it is not always possible for failure analysis software to correlate a test cycle to a particular point in a test program.
What is needed is an integrated circuit tester architecture that provides information that enables failure analysis software to determine the program context of a failure when a test involves conditional branching.
Failure Analysis for Spare Row/Column Replacement
Random access memories (RAMs) are typically formed as arrays of rows and columns of memory cells. The input address to a RAM identifies the particular row and column of the cell to be read or write accessed. Some RAMs include spare rows and/or columns of memory cells so that when one of the RAM's cells is defective, the RAM can be modified to replace the row or column of a defective cell with one of its spare rows or columns. As it tests such a RAM, a RAM tester stores pass/fail data indicating whether each memory cell has passed or failed the test. After the RAM has been fully tested, the cell pass/fail data is provided to failure analysis software that determines how to best allocate spare rows and columns when repairing the RAM. Conventional RAM testers employ a memory as large as the RAM being tested for storing the pass/fail data for each cell of the RAM. After the RAM has been fully tested, the entire contents of the pass/fail data memory is transferred to a host computer running the failure analysis software. It would be beneficial to provide a RAM tester architecture than can provide failure analysis software with enough information to determine how to allocate spare rows and columns without having to include a memory large enough to store pass/fail data for each cell of the RAM under test. It would also be desirable if such information were compact so that it could be transferred quickly to the host computer.
Block Failures
Some non-volatile memories are organized into blocks of memory with each block having a separate block address. Thus a particular memory cell will have a block address, a row address and a column address. Such memory can be reconfigured to avoid using blocks that may have a minimum number of defective cells. To avoid having to provide a large memory for storing pass/fail data for all cells of all blocks a memory tester typically separately tests each memory block and sends pass/fail data to a host computer after each block test. Failure analysis software in the host computer then decides how to reconfigure the RAM to avoid using failed blocks based on the number of failed c
Arkin Brian J.
Oonk John Mark
Bedell Daniel J.
Credence Systems Corporation
Kobert Russell M.
Sherry Michael J.
Smith-Hill and Bedell
LandOfFree
Integrated circuit tester having a program status memory does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Integrated circuit tester having a program status memory, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Integrated circuit tester having a program status memory will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2933412