Error detection/correction and fault detection/recovery – Pulse or data error handling – Memory testing
Reexamination Certificate
2003-06-02
2004-03-09
Baker, Stephen M. (Department: 2133)
Error detection/correction and fault detection/recovery
Pulse or data error handling
Memory testing
C714S718000, C711S100000, C716S030000, C716S030000
Reexamination Certificate
active
06704891
ABSTRACT:
BACKGROUND OF THE INVENTION
Memory devices, including Dynamic Random Access Memories (DRAMs), are implemented as integrated circuits (ICs). The decreased size, increased storage capacity, increased operating speed, and expanded capabilities of memory device ICs have revolutionized computer systems, telecommunications equipment and consumer electronics. However, these attributes have also created a number of technical challenges. Testing is one such challenge.
Integrated circuits implementing memory devices must be reliable. Accordingly, memory devices have been tested since their first manufacture. Very early in the history of memory device testing, specialized equipment and automated test routines were developed to improve testing efficiency. As the capacity and capabilities of memory devices increased, a broad range of tests were automated. Different memory device manufacturers prescribed different testing routines. Test equipment is typically custom and memory device testing routines were written specific to the custom test equipment.
Tests for memory devices may be conveniently divided into two categories; “test vectors,” and “algorithmic patterns.” A test vector typically consists of a linear set of operations to be performed. A test vector is often written in lower level language like assembly code. Test vectors access one or more memory device components and directly test their functionality over a range of common and end cases. For example, a write buffer might be run through a series of read/write sequences to verify correct operation.
An algorithmic pattern typically consists of a program written in a higher level language which better supports looping and branching constructs for the memory device test. In many conventional implementations, algorithmic patterns are written in a language that looks like a cross between microcode and assembly language. Such “languages” provide a richer set of control commands and expressions. Unfortunately, algorithmic patterns tend to generate some quirky side-effects within the test equipment. For example, dedicated hardware registers in the test equipment may become corrupted with invalid data during the generation of complicated test patterns. Such problems not withstanding, algorithmic patterns remain a mainstay of memory device test protocols. This is not surprising given the great number of memory locations which must be tested in contemporary memory devices. The practical implementation of a test which repeatedly writes data patterns to every location in a memory device requires some sort of looping operation. A set of linear test vectors sufficient to test the full storage capacity of contemporary memory deices would be impossibly long.
A “test” consists of one or more test vectors and/or one or more algorithmic patterns. In creating a test, a test writer must define a sequence of operations which store and retrieve data to/from the memory device in accordance with certain “operating constraints.” Operating constraints take many forms including state-based and timing-based constraints, as well as other constraints which govern the proper operation of the memory device. (Attempting to CAS a bank of memory before it has been properly RASed in one example of a state-based constraint being violated. Attempting to CAS a memory bank too soon after it was RASed is an example of a timing constraint being violated). The operation of early memory devices was simple and characterized by relatively few constraints. As memory devices have increased in complexity, a greater number of operating constraints have arisen. These constraints must be observed and accounted for during the definition and creation of a test.
Contemporary memory devices allow multiple transactions to be handled simultaneously. Compared to their predecessors, contemporary memory devices have an increased number of operating constraints which must be obeyed during a sequence of memory system operations. Further, the use of packets to exchange control/address information and data greatly expands the number of constraints which must be obeyed during the definition of a memory device test protocol. Not only does the number of constraints (or rules) increase for each individual transaction defined within the test protocol, but also the number of interactions between the various rules increases as multiple concurrent transactions are performed to fully test the capabilities of the memory device.
All of the foregoing has created quite a mess. Each memory device manufacturer prescribes a set of tests which targets different aspects of their particular design. Memory device test writers currently generate test protocols without benefit of a tool which provides feedback as to whether or not a test step or test routine violates one or more memory device constraints.
Accordingly, when a memory device fails a test, it is not certain whether the memory device is truly broken, or whether the test has been improperly constructed. In such circumstances, the test writer might ask the memory device designers whether the present interpretation of memory device constraints is correct. However, even if the interpretation is correct, the constraints may not be properly expressed in the written test code. Often a memory device “known-to-be-good” is used to test the test. This method presumes that the “known-good” memory device is still good despite its repeated handling in the test facility.
The flowchart of
FIG. 1
illustrates a typical conventional process through which a memory device test is generated. Using current interpretations of memory device constraints, a test is created
2
, and run
3
on a memory device. If the memory device passes the test (
4
=yes), the test and the memory device are assumed to be good. As mentioned above, this assumption is often bolstered by the use of a “known-good” memory device during test development.
If the memory device fails the tests (
4
=no), the test writer is left in doubt as to whether the device failed on its own accord or whether the test is bad
6
. Assuming the test has violated some memory device constraint (
7
=yes), the test is changed
9
and the new test is run
3
. If the test writer has confidence in the test (
7
=no), the memory device is replaced
8
and the test is rerun
3
.
The conventional process of test generation thus relies on assumption and “trial-and-error” tactics to arrive at a test presumed to be good. Further, each new test must be verified against a number of different conditions, such as temperature, data state, power level, etc. The process of test design is lengthy and fraught with doubt. In fact, errors may enter the test design process during any one of steps
2
,
5
,
6
,
7
and
9
in the exemplary process shown in FIG.
1
.
For example, a timing constraint, such as the minimum period between RAS-to-CAS (tRCD), might be violated by a test which defines a slightly shorter period than that prescribed by the memory device specification. Using this constraint as an example, one batch of memory devices might pass the test even though the test violates the specification for the devices. As a result, the test and the batch of memory devices are assumed to be good. (Step
5
above). As it turns out, the test violates the minimum tRCD period for the memory device, but the first batch of memory devices were able to tolerate the shorter than specified period for tRCD.
Unfortunately, a subsequent batch of memory devices, while in actuality meeting specification, are not able to tolerate the shorter tRCD period defined by the test. Because the test has been assumed “good,” the later batch of memory devices will be considered out-of-specification and may be thrown out. Such an error in the test protocol may not be caught until many good parts have been discarded as bad.
This result arises because the conventional process of generating a test does not include a mechanism for verifying compliance with actual memory device constraints. Only after a number of memory devices have successfully pass
Horowitz Mark Alan
Privitera John Philip
Woo Steven Cameron
Baker Stephen M.
Britt Cynthia H
Pennie & Edmonds LLP
Rambus Inc.
LandOfFree
Method for verifying and improving run-time of a memory test does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method for verifying and improving run-time of a memory test, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method for verifying and improving run-time of a memory test will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3267656