Patent Grant
9117552
Embodiments described herein relate generally to computing systems, and memory modules and memory devices for use in computing systems.
A computing system typically employs storage media such as random access memory (RAM), for example. In contemporary computing systems, the amount of such memory utilized by the computing system may be on the order of gigabytes and terabytes.
As memory size increases, the probability of memory cells of memory devices either being manufactured defective or becoming defective during their deployment increases significantly. Correspondingly, the defective memory cells may cause the computing system to fail. This failure can potentially cause a “crash”—a termination in the current functioning of the computing system. This may result in the loss of critical information.
For a better understanding of the example embodiments described herein and to show more clearly how they may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings in which:
Known memory protection techniques exist in which memory blocks containing errors are removed from an “available memory” list. This list can be utilized by the operating system of a computing system to prevent access by applications to memory blocks with errors, which could result in a serious memory failure and a crash of the computing system.
Many of the known memory protection techniques employ a rigid criterion when evaluating memory blocks. For example, a memory block may be considered only as either bad (and is thus removed from the available memory list) or good (and is thus permitted to remain in the available memory list). There was typically no attempt to distinguish between good cells in a memory block and, for example, potentially weaker cells (e.g. cells that may have failed a certain test, but where no pattern of regular reoccurrence of the error has been identified).
One weak cell in a memory block might be insufficient to render the memory block useless for all purposes; however, if the memory block can only be classified as good or bad, the memory block would typically be automatically considered as bad and removed from the available memory list simply because an error was identified during its testing, even when the error would not represent a material risk of a memory failure if the memory block was accessed.
At least one embodiment described herein utilizes multiple grades of quality for memory blocks (i.e. more than two quality grades, not merely “good” or “bad”, for example). This may help to improve the utilization of available memory, introducing a practical compromise between the risk of potential memory failure and a desire to increase a pool of available memory.
Furthermore, in accordance with at least one embodiment described herein, there is provided a two-part method of testing memory cells. The first part entails performing a preliminary or “primary” test on a memory device for errors. The primary test is used to identify potentially defective memory cells. The second part entails performing a further, more comprehensive verification test (hereinafter referred to as a “focus” test) on the same memory device. The focus test is used to verify that a given memory cell or memory block that failed the primary test is, in fact, defective.
Memory blocks with memory cells that are identified as defective by the focus test may be subsequently removed from available memory on a computing system. However, memory blocks with, for example, transient or other non-reproducible errors (e.g. where an error with a given memory cell was identified in the primary test but could not be successfully verified in the focus test, this might suggest that the memory cell is merely “weak” but not defective) could still be made available for use.
In one broad aspect, there is provided a method of testing a memory device within a computing system, wherein a plurality of applications are executable by at least one processor of the computing system, the method comprising: performing a first memory test on the memory device; detecting, from the first memory test, at least one error in a memory unit of the memory device; in response to the detecting, performing acts to verify the at least one error comprising: preventing at least one of the plurality of applications from accessing the memory unit; performing a second memory test on the memory unit; determining, from the second memory test, whether the at least one error is successfully verified; and if the at least one error is successfully verified, identifying the memory unit as defective.
In one embodiment, the identifying comprises recording an identification of the memory unit in a persistent memory.
In one embodiment, the method further comprises: if the at least one error is successfully verified, recording, in association with the identification of the memory unit in the persistent memory, an indication of a number of errors detected in the memory unit.
In one embodiment, the memory unit comprises one of: a single memory cell of the memory device; or a memory block consisting of a plurality of memory cells of the memory device.
In one embodiment, performing the first memory test comprises applying a first number of test patterns, and performing the second memory test on the memory unit comprises applying a second number of test patterns, the second number being substantially greater than the first number.
In one embodiment, the method further comprises: performing the second memory test on one or more memory cells neighboring the memory unit; wherein the at least one error is successfully verified when a number of errors that are detected by the second memory test in the memory unit exceeds a threshold value associated with the second memory test.
In one embodiment, the method further comprises: restoring access by the at least one of the plurality of applications to the memory unit in response to determining that the at least one error is not successfully verified.
In one embodiment, the method further comprises: continuing to prevent the at least one of the plurality of applications from accessing the memory unit in response to determining that the at least one error is successfully verified.
In one embodiment, the method further comprises: generating an updated system memory map that excludes the memory unit if the memory unit is identified as defective.
In one embodiment, a threshold value is associated with the first memory test, and the acts to verify the at least one error are performed in response to determining that a number of errors that are detected by the first memory test in the memory unit exceeds the threshold value associated with the first memory test.
In one embodiment, the threshold value associated with the first memory test comprises one of: zero; or a value greater than zero.
In one embodiment, the threshold value associated with the first memory test is user-configurable.
In one embodiment, the acts to verify the at least one error further comprise: recording an identification of the memory unit in a memory pending completion of the second memory test.
In one embodiment, the method further comprises: determining a physical address associated with the memory unit, wherein the identification of the memory unit comprises the physical address.
In one embodiment, the method further comprises: recording, in association with the identification of the memory unit in the memory, an indication of a number of errors detected in the memory unit.
In one embodiment, the method further comprises: deleting the identification of the memory unit from the memory upon completion of the second memory test.
In one embodiment, the at least one error is successfully verified when a number of errors that are detected by the second memory test in the memory unit exceeds a threshold value associated with the second memory test.
In one embodiment, the method further comprises: restoring access by the at least one of the plurality of applications to the memory unit if the number of errors that are detected by the second memory test in the memory unit falls below a threshold value associated with the restoring.
In one embodiment, the threshold value associated with the second memory test comprises one of: zero; or a value greater than zero.
In one embodiment, the threshold value associated with the second memory test is user-configurable.
In one embodiment, the method is performed by a testing application, and the preventing comprises isolating the memory unit from access by any one of the plurality of applications, other than the testing application.
In one embodiment, the method is performed in response to determining that the computing system has spare resources due to an underutilization of the at least one processor.
In another broad aspect, there is provided a computing system configured to allow testing of a memory device within the computing system, the system comprising: at least one processor, wherein a plurality of applications are executable by the at least one processor; and a memory; wherein the plurality of applications comprises a testing application, comprising instructions that when executed by the at least one processor, configured the at least one processor to: perform a first memory test on the memory device; detect, from the first memory test, at least one error in a memory unit of the memory device; in response to detecting the at least one error, perform acts to verify the at least one error comprising: preventing at least one the plurality of applications from accessing the memory unit; performing a second memory test on the memory unit; determining, from the second memory test, whether the at least one error is successfully verified; and if the at least one error is successfully verified, identifying the memory unit as defective.
In another broad aspect, there is provided a computer-readable medium comprising instructions for testing a memory device within a computing system, wherein the instructions, when executed by at least one processor of the computing system, configure the at least one processor to: perform a first memory test on the memory device; detect, from the first memory test, at least one error in a memory unit of the memory device; in response to detecting the at least one error, perform acts to verify the at least one error comprising: preventing at least one the plurality of applications from accessing the memory unit; performing a second memory test on the memory unit; determining, from the second memory test, whether the at least one error is successfully verified; and if the at least one error is successfully verified, identifying the memory unit as defective.
In another broad aspect, there is provided a method of testing a memory device, the method comprising: performing a first memory test on the memory device, wherein the first memory test is performed under operating conditions that exceed specification requirements for the memory device; detecting, from the first memory test, at least one error in a memory unit of the memory device; in response to the detecting, performing acts to verify the at least one error comprising: performing a second memory test on the memory unit, wherein the second memory test is performed under operating conditions within the specification requirements for the memory device; determining, from the second memory test, whether the at least one error is successfully verified; and if the at least one error is successfully verified, identifying the memory unit as defective.
In one embodiment, the identifying comprises recording an identification of the memory unit in a persistent memory.
In one embodiment, the method further comprises: if the at least one error is successfully verified, recording, in association with the identification of the memory unit in the persistent memory, an indication of a number of errors detected in the memory unit.
In one embodiment, the memory unit comprises one of: a single memory cell of the memory device; or a memory block consisting of a plurality of memory cells of the memory device.
In one embodiment, performing the first memory test comprises applying a first number of test patterns, and performing the second memory test on the memory unit comprises applying a second number of test patterns, the second number being substantially greater than the first number.
In one embodiment, the method further comprises: performing the second memory test on one or more memory cells neighboring the memory unit; wherein the at least one error is successfully verified when a number of errors that are detected by the second memory test in the memory unit exceeds a threshold value associated with the second memory test.
In one embodiment, a threshold value is associated with the first memory test, and the acts to verify the at least one error are performed in response to determining that a number of errors that are detected by the first memory test in the memory unit exceeds the threshold value associated with the first memory test.
In one embodiment, the threshold value associated with the first memory test comprises one of: zero; or a value greater than zero.
In one embodiment, the threshold value associated with the first memory test is user-configurable.
In one embodiment, the acts to verify the at least one error further comprise: recording an identification of the memory unit in a memory pending completion of the second memory test.
In one embodiment, the method further comprises: recording, in association with the identification of the memory unit in the memory, an indication of a number of errors detected in the memory unit by the first memory test.
In one embodiment, the method further comprises: deleting the identification of the memory unit from the memory upon completion of the second memory test.
In one embodiment, the at least one error is successfully verified when a number of errors that are detected by the second memory test in the memory unit exceeds a threshold value associated with the second memory test.
In one embodiment, the threshold value associated with the second memory test comprises one of: zero; or a value greater than zero.
In one embodiment, the threshold value associated with the second memory test is user-configurable.
In one embodiment, the method is performed in a factory environment.
In another broad aspect, there is provided a testing system configured to test a memory device, the system comprising: at least one processor; and a memory; wherein the at least one processor is configured to: perform a first memory test on the memory device, wherein the first memory test is performed under operating conditions that exceed specification requirements for the memory device; detect, from the first memory test, at least one error in a memory unit of the memory device; in response to detecting the at least one error, perform acts to verify the at least one error comprising: performing a second memory test on the memory unit, wherein the second memory test is performed under operating conditions within the specification requirements for the memory device; determining, from the second memory test, whether the at least one error is successfully verified; and if the at least one error is successfully verified, identifying the memory unit as defective.
In another broad aspect, there is provided a computer-readable medium comprising instructions for testing a memory device, wherein the instructions, when executed by at least one processor of a testing system, configure the at least one processor to: perform a first memory test on the memory device, wherein the first memory test is performed under operating conditions that exceed specification requirements for the memory device; detect, from the first memory test, at least one error in a memory unit of the memory device; in response to detecting the at least one error, perform acts to verify the at least one error comprising: performing a second memory test on the memory unit, wherein the second memory test is performed under operating conditions within the specification requirements for the memory device; determining, from the second memory test, whether the at least one error is successfully verified; and if the at least one error is successfully verified, identifying the memory unit as defective.
Details on these embodiments and aspects, and other embodiments and aspects, are provided in the description herein.
Referring first to
Addressable memory space 100 comprises multiple memory components that are capable of being addressed as memory. Examples of memory components may include memory modules 120, shown as dual inline memory modules (DIMMs) in
By way of illustration, memory space 100 may be subject to a memory scanning operation that scans the memory in each memory device to analyze all addressable memory locations in succession. In
In one known system, the memory scanning operation occurs during the powering up of a computing system. The computing system may then create a memory map, which excludes defective memory locations as determined from the memory scanning operation, or as determined from prior start-up scans. Data identifying defective memory locations within a particular memory space may be stored in a persistent store on a memory module. The persistent store may be a Serial Presence Detect (SPD) device on the memory module, for example.
Continuing the example of
In at least one embodiment, multi-bit flags may be used and associated with memory blocks to facilitate a grading of the memory blocks. The grade of a given memory block may represent a quality measure of the memory block. Accordingly, a multi-bit flag may provide a more useful and precise indicator of the quality of the memory block as compared to systems in which one-bit flags are employed.
For example,
In one embodiment, the grade to be associated with a given memory block may be dependent on the number of errors identified during a particular test of the memory block. For example, if only one memory cell of the memory block was found to contain an error, and the error can be attributed to a single instance of a failed match in respect of a single test pattern (with all other tests being successfully passed), the memory block may still be considered to be of very high quality and remain suitable for use. If the grade ‘000’ represents an error-free memory block (with grade ‘111’ representing a memory block of extremely poor quality), grade ‘001’ may be used to identify a memory block of very high quality despite the fact that an error was identified during testing of that memory block.
Different criteria, including the number and/or the type of errors identified in one or more tests may be associated with each available grade. In particular, there can be flexibility in how values for the multi-bit flags are set depending on the particular implementation. However, in general, flags for blocks containing “hard failures” that would typically cause the computing system to crash, will generally be assigned the highest values.
In variant implementations, the rankings of flag values may be reversed (e.g. the blocks with hard failures may be assigned the lowest values, while error-free memory blocks may be assigned the highest values), or some other ranking methodology may be employed.
Referring now to
Typically, memory devices are tested and certified by manufacturers to ensure that signal parameters are within an allowable range set by the manufacturer or by corresponding appropriate standards. Complete testing of a memory device may include both functional testing as well as application-specific testing.
Specific to memory devices, functional testing generally tests whether or not a memory device performs particular functions properly and meets the manufacturer's specifications. For example, functional testing may test whether or not a digital value written to a cell of memory will later be retrieved without error, regardless of how the memory device is implemented. More specifically, memory devices may be subject to pattern testing, which is a method of exercising each memory device to verify its functionality with regards to certain test vector patterns.
Functional testing may also test whether or not certain critical operating characteristics of a memory device fall within an allowable range of values. Parametric tests verify critical operating characteristics, including characteristics such as, for example, power consumption, standby current, leakage current, voltage levels and access time. The allowable range may be set by the manufacturer of the memory device or by the corresponding appropriate standards.
While functional testing is generally oriented towards discovering whether or not a memory device under test is likely to fail during its intended use or application, it typically involves testing memory devices to verify how they execute a specific set of functions that are specially designed for this purpose.
Further testing of a memory device may also involve application-specific testing. During application-specific testing, memory devices may be subject to a testing of their system behavior in order to detect their behavioral failures. Behavioral failure is a type of failure that occurs when a memory device is operated within an actual application system. For example, a behavioral failure may be a failure that occurs as a result of a specific command or access sequence to a memory device that is performed during the performance of regular operations on a personal computer (PC).
Functional testing will not necessarily detect behavioral failures. With functional testing, the operation of a memory device under test does not need to be indicative of how the device will behave during its intended application. Accordingly, complete and comprehensive testing of a memory device may require application-specific testing in addition to functional testing.
Referring again to
The tester 210 may include, for example, a program memory (PM) 250, a comparator 260, a test vector pattern generator (TVPG) 280, a controller (Contr) 290, a control computer (CC) 294, and a microprocessor (mP) 295. In practice, the functions of some of the elements shown logically in FIG. 2 may be integrated into one or more physical components. Where the DUT 220 includes at least one memory device (MD) 230, the tester 210 may also include a reference memory device (RD) 270.
Only certain electrical connections between the various components of the tester 210 and of the test system 200 are illustrated, for ease of exposition. However, it will be understood by persons skilled in the art that the tester 210 and/or test system 200 may include components or connections in addition to or as an alternative to one or more of the components or connections shown in
In the example of
In
In one example implementation, the tester 210 and the handler 215 co-operate with each other during testing of the DUT 220. Each of the tester 210 and the handler 215 may be equipped with a control computer or other processing element (e.g. 294 and 216, respectively) configured, at least, to communicate test results. For example, the handler 215 may first load (by a mechanical means 217, such as for example, a robotic device) the DUT 220 into a testing unit (not shown) of the tester 210 to facilitate testing. The tester 210 performs testing on the DUT 220. Test results are processed by control computer (CC) 294. The control computer 294 in the tester may then send the test results to a control computer 216 in the handler, for example, via the interface 212. Based on the received test results, the control computer 216 in the handler may then determine where to physically move the tested memory device from the testing unit.
Some example operations of the tester 210 in relation to the DUT 220 are described in the paragraphs below. For example, testing may be performed on each individual memory cell of the memory device 230 so that if a given individual memory cell is determined to be defective (e.g. the memory cell failed a test carried out by the test system 200), then its corresponding memory location may be identified.
To perform testing on the DUT 220, the microprocessor 295 may retrieve an instruction or instructions from the program memory 250. In response, the microprocessor 295 may instruct the TVPG 280 to generate a digital representation of a test vector pattern, which is then sent by the TVPG 280 to the controller 290. The test vector pattern may be utilized in the testing process to determine defective memory locations on the DUT 220, which, in this example, is the memory device 230. Alternatively, the DUT 220 may comprise a plurality of memory devices.
Upon receipt of the test vector pattern generated by the TVPG 280, the controller 290 converts the test vector pattern into an electrical waveform. The controller 290 then outputs the electrical waveform to the DUT 220 via the communication channel 240. The TVPG 280 also sends a digital representation of the test vector pattern to the reference memory device 270 for temporary storage, to be used at a later stage in the testing procedure. In variant implementations, a reference memory module comprising multiple memory devices may be employed instead of a reference memory device 270, particularly where the DUT 220 comprises multiple memory devices, for example.
The electrical waveform is transmitted electrically across the communication channel 240 to the DUT 220 and is sampled back into digital form. At some point after the electrical waveform has been transmitted to the DUT 220 by the controller 290, the DUT 220 electrically transmits, across the communication channel 240, a response data signal containing a response bit pattern for each memory device of the DUT 220, namely the memory device 230 illustrated in
The controller 290 then converts the response data signals from the DUT 220 into digital form. The response data signals include the response data signals generated by the memory device 230 which are dependent on the test vector pattern sent by the controller 290 as an electrical waveform to the DUT 220.
The controller 290 then relays the converted response data signal from the DUT 220 to the comparator 260. At the comparator 260, the response data signal from the DUT 220 is compared with a digital form of a reference signal (i.e., a reference bit pattern, also generally referred to as an expected bit pattern), namely the signal that the controller 290 expects to receive from the DUT 220 that sent the response data signal. In one embodiment, the previously stored reference signal is transmitted to the comparator 260 by the reference memory device 270. The comparator 260 determines whether or not the response data signal is an identical match, based on a digital comparison, to the corresponding reference signal, and outputs that logical determination to the microprocessor 295.
If the comparator 260 determines a digital match between the two compared signals (i.e., between the response data signal and the corresponding reference signal), then the DUT 220 has, at least in the context of that particular test vector pattern, produced valid data. Where the DUT 220 is not determined to have undergone failure during testing and is determined to have met all required specifications, the DUT 220 may be considered a “good”, “error-free” or “defect-free” memory device.
However, if the comparator 260 determines that the two compared signals are not digitally identical, then the DUT 220 may have undergone a failure of some kind. As previously described, testing is performed on each individual memory cell on the memory device 230. Therefore, after the comparator 260 determines that the DUT 220 has undergone a failure, the one or more memory locations on the memory device where the failure occurred may be identified and those one or more memory locations may be deemed to be “defective”. Data that identifies the one or more defective memory locations on the memory device, once generated, may be stored.
For example, the data that identifies the one or more defective memory locations on the memory device may be stored in a database 205. This database 205 may reside on a computer system that may be external to, or within or coupled to the tester 210. If the database 205 is external to the tester 210, the database may be accessible via a network 207, for example.
Each entry associated with a defective memory location in the database 205 may comprise, for example, a memory device identification number, in addition to data identifying the actual memory location on the memory device. Optionally, other details describing a failure of the DUT 220 during testing (e.g. the technical characteristics of the DUT or the test pattern that caused the failure of the DUT) may also be recorded in the database 205. Further, information associated with the handler 215 may also be stored in the database 205, such as data identifying the handler used in the testing process (e.g. if multiple handlers are used) and data identifying the location in which the handler placed the memory device for testing (e.g. a test socket identifier). Also, information associated with the tester 210 may also be stored in the database 205, such as data identifying the tester used in the testing process (e.g. if multiple testers are used).
In accordance with at least one embodiment, the database 205 may be used to store, for a given memory device, data that identifies one or more defective memory locations on the memory device for subsequent recording onto a persistent store on a memory module. Other data obtained from the database 205, such as operating parameters for the memory devices (e.g. Joint Electron Devices Engineering Council (JEDEC) memory standards) and manufacturer-specific parameters or data, for example, may also be stored in the persistent store on the memory module.
The testing of memory devices can be performed within a factory testing environment with the help of a memory tester (e.g. tester 210). Furthermore, methods of testing of memory devices can also be performed “in the field”—after the memory device has been deployed and is in use in a computing system, for example—with the aid of testing software.
In accordance with at least one embodiment described herein, a two-part method may be employed to test memory cells. The first part entails performing a preliminary or “primary” test on a memory device to identify potentially defective memory cells. A defective memory cell is a memory cell that fails to operate according to memory specifications. The second part entails performing a verification or “focus” test on the same memory device to verify whether a given memory cell or memory block that failed the primary test is defective and to what degree. This technique may provide more accurate results as compared to conventional memory testing techniques where all memory cells are uniformly subject to the same routine tests.
Referring now to
In one example implementation, a testing system (e.g. tester 210 of
In at least one embodiment, a memory test under operating conditions that exceed specification requirements (e.g. as devised by either a memory manufacturer or JEDEC memory standards) for the memory device (e.g. memory device 230 of
At 310, the tightened operating parameters are initially set. At 315, the memory test on the memory device is performed (e.g. with the help of tester 210 and handler 215 of
If at least one memory error is detected in a memory unit (a memory unit may be defined as either a memory cell or a plurality of memory cells as a memory block as noted below) of the memory device at 320, then at 325, in response to detection of the at least one memory error, an identification of the memory unit is recorded in a memory store. Otherwise, the flow of method 300 will proceed directly to 330.
More specifically, at 325, the identification of the memory unit is recorded in the memory store pending the completion of a further test (see e.g.
The identification of the memory unit and potentially other associated data may be recorded in a data structure representing a questionable list (i.e. memory units having errors identified in the primary test that are to be subject to further verification) stored in a memory, including for example, local storage (on tester 210). The memory may be a volatile memory or a persistent memory (e.g. database 205 of
At 330, it is determined whether testing of the memory device is complete; if testing of the memory device is complete, the flow of method 300 proceeds to 335 marking the end of the primary test, otherwise the flow of method 300 proceeds back to 315 where testing of the memory device continues.
In at least one variant embodiment, a threshold value is associated with the primary test. If, for a given memory unit, the number of errors that are detected by the primary test exceeds the threshold value, then an error in the memory unit will be detected. However, if the number of errors that are detected for the given memory unit by the primary test fails to exceed the threshold value, then an error in the memory unit will be deemed to not have been detected, even if some failure of the memory unit had been identified in the primary test. For example, if the threshold value is set to zero, then this effectively would cause an error to be detected for the given memory unit if any error is identified; on the other hand, in some implementations, the threshold value may be set to a higher non-zero value. The threshold value associated with the primary test may be user-configurable (e.g. set by an administrator or test engineer).
The number of errors may be proportionate to the number of test patterns that the memory unit failed during the primary test, for example. In one embodiment, an indication of the number of errors detected in the memory unit by the primary test may be recorded, in association with the identification of the memory unit, in the memory. In another embodiment, a grade for the memory unit (see e.g. discussion of grades with reference to
Referring now to
Memory cell failures having patterns of regular and irregular reappearances may be treated differently since repetitive memory cell failures will typically guarantee a computing system crash, while “weaker” non-repetitive memory cell failures typically do not have such severe consequences (i.e., the non-repetitive failures may or may not cause a computing system to crash).
A verification test may be performed subsequent to the primary test (e.g.
This verification test may also be referred to as a focus test herein, and in at least one embodiment, may be performed in a factory testing environment.
In at least one example embodiment, with respect to a given memory unit (e.g. a memory cell or a memory block) for which an error was detected by the primary test, the focus test entails performing a more comprehensive test of the memory unit under normal operating parameters. The “over-the-spec” test is performed initially as a primary test to find weak cells quickly, but since the memory will actually be used under normal conditions, the focus test is performed under normal conditions.
Furthermore, in at least one example embodiment, the focus test comprises performing a memory test not only on a given memory unit, but also on one or more memory cells in the physical neighborhood of that memory unit (e.g. adjacent or otherwise in close proximity to the given memory unit). The one or more cells in the neighborhood of that memory unit may belong to different memory units. This practice recognizes that the operation of weak cells may be affected by physically neighboring cells, and in addition, that weak cells are often found in clusters. The error in the given memory unit may be considered to be successfully verified by the focus test when a number of errors that are detected, by the focus test, in the given memory unit exceed a threshold value associated with the focus test. For example, if the threshold value is set to zero, then this effectively would cause the error in the given memory unit to be successfully verified whenever any error in the given memory unit is identified by the focus test; on the other hand, in some implementations, the threshold value may be set to a higher non-zero value. The threshold value associated with the focus test may be user-configurable (e.g. set by an administrator or test engineer).
In at least one example embodiment, the focus test may involve, in addition to or alternatively to testing of memory cells within the neighborhood of memory units under test, applying a substantially greater number of tests to the memory units under test, compared to the number of tests applied during the primary test. For example, a first number of test patterns may be applied to memory units during the primary test, and a second number of test patterns may be applied to memory units during the focus test, where the second number is substantially greater than the first number. By way of illustration, a memory cell may be subject to testing using a number of test vector patterns on the order of thousands during a primary test, whereas each memory cell being tested during a focus test may be subject to testing using a number of test vector patterns on the order of millions.
The acts of method 350 begin at 355. At 360, the operating parameters that may have been tightened for the primary test are restored, such that the focus test is performed under operating conditions within the specification requirements for the memory device.
At 365, data identifying memory units that failed the primary test is read from memory. For example, a data structure representing a questionable list (e.g. with data for memory units having errors identified in the primary test that are to be subject to further verification) stored in a persistent memory (e.g. database 205 of
At 370, the comprehensive memory test on the selected memory unit is performed (e.g. with the help of tester 210 and handler 215 of
If, at 375, it is determined that a memory error in the selected memory unit is not successfully verified by the testing performed at 370, then at 385, the selected memory unit is deleted from the questionable list and the flow of method 350 proceeds to 390. On the other hand, if the memory error in the selected memory unit is successfully verified, the selected memory unit is identified as defective in 380.
At 380, identifying the selected memory unit as defective may comprise recording an identification of the memory unit and potentially other associated data in a data structure representing a permanent list (e.g. a list for memory units having errors that have been verified) stored in a memory, which may be a persistent memory (e.g. database 205 of
If the questionable list and the permanent list are implemented using different data structures, the recording of an identification of the memory unit in the permanent list may trigger or be triggered by a contemporaneous deletion of the identification of the memory unit in the questionable list (e.g. an act analogous to act 385 would also be performed before or after 380, although not explicitly shown in
However, in a variant implementation, a single data structure may be used to represent both questionable and permanent lists. An identification for each memory unit for which the primary test (
At 390, it is determined whether the questionable list identifies any more memory units to be verified; if so, the flow of method 350 proceeds back to 365 where a further memory unit is selected for testing, otherwise the flow of method 350 proceeds to 395 marking the end of the focus test.
The inventors have recognized that methods 300 and 350, when performed in combination, constitute a two-part test that greatly improves efficiency with respect to the testing of memory devices in a factory testing environment. The two-part testing methodology may generally be referred to as intelligent memory testing.
A similar two-part testing methodology may also be employed in a field testing environment, after a memory device has already been deployed and is in use within a computing system. A primary test may be performed to initially identify potentially defective memory units, and a verification test (“focus test”) may be subsequently performed to verify errors in memory units identified in the primary test.
Referring now to
Test system 400 is configured to test a memory device within a memory 415 of the computing system, with the assistance of operating system 410. A surveillance program 430 provides instructions directing one or more processors (not explicitly shown) of the computing system to continuously survey the functioning of memory 415 (somewhat analogous to known anti-virus programs which may operate in the background to provide real-time protection for a computing system).
Since the surveillance program 430 currently operates in what is known as a linear (or virtual) memory address space, if a memory unit (e.g. a memory cell or a memory block) is identified as potentially being defective by the surveillance program 430, a translation of the address of the memory unit in the virtual memory space into the physical memory address space is performed, so that the physical address associated with the memory unit can later be identified. There are special translation tables or look-up tables 420 that may be used to assist in performing a virtual-to-physical address conversion. These tables, in one example implementation, are part of the computer hardware architecture 425. Surveillance program 430 performs the virtual-to-physical address conversions with the assistance of operating system 410 by referring to the look-up tables 420.
Surveillance program 430 may also initiate a memory holding program 435 that isolates failed memory units that were identified in a primary test, and records an identification of the potentially defective memory units and other associated data in a data structure representing a list of questionable errors (e.g. questionable list 455) pending completion of the subsequent verification test to be performed. Questionable list 455 may be stored temporarily in a volatile memory or in a persistent storage device 460 (e.g. in an SPD of a memory module or on a hard drive of the computing system).
While memory units are isolated by memory holding program 435, other software applications that are executing on the computing system are prevented from accessing those memory units, in order to minimize the risks of a crash of the computing system.
The memory units identified as being potentially defective in the primary test in the questionable list 455 are subject to a further test to verify the errors previously found. The verification may be performed at the instruction of a focus test program 440, which will confirm or reject the previously recorded memory errors by performing more extensive testing of the identified memory units, and potentially testing other memory cells in the neighborhood of those identified memory units.
Memory units having verified memory errors can be identified and recorded, potentially along with other associated data, in a list of verified errors (e.g. permanent list 450) within a persistent storage device 460, in accordance with at least one embodiment. As the verification of certain memory units identified in questionable list 455 is completed, the identification of those memory units may be removed from questionable list 455.
In some embodiments, surveillance program 430 and focus test program 440 are active when the computing system is determined to have spare resources (e.g. when at least one processor of the computing system is being underutilized), to avoid significantly slowing down the performance of the computing system.
In some embodiments, some or all of the functionalities of surveillance program 430, memory holding program 435, and focus test program 440 may be integrated into a single testing application 445. Testing application 445 may be installed onto the computing system and/or configured by a user or an administrator, for example.
Test system 400 may also comprise a Unified Extensible Firmware Interface (UEFI) or Basic Input/Output Operating System (BIOS) firmware interface 465 installation, that is configured (among other things) to read data from a permanent list 450 in persistent storage 460 during power-up of the computing system for example, in order to update a system memory map and to provide this information to operating system 410. Operating system 410 can employ the updated memory map such that memory cells that have been found to be defective can be effectively quarantined and thus avoided for use by applications during operation of the computing system.
Referring now to
In one example implementation, the method 500 is performed in a field testing environment, which may comprise a computing system adapted as a test system (e.g. test system 400 of
The primary test performed in method 500, beginning at 505, comprises a surveillance test (“primary test”) of usable memory in the computing system, which is first performed in order to detect potentially defective memory cells. The memory being tested may comprise one or more memory devices. This test may be performed in response to a determination that the computing system has spare resources due to a current underutilization of the at least one processor. This may minimize the drain on processing resources of the computing system. For example, the testing application may be configured such that the primary test is performed when the at least one processor is considered to be at 20% utilization (or below). This may mark the primary test as a low priority task. For instance, if the user of the computing device is not doing anything active and the computing device is not running on battery power, then the primary test may be permitted to proceed; if the user recommences using the computing device, the primary test may be halted and the testing application may go into an idle state.
At 510, the memory test on the memory of the computing system is performed (e.g. with the help of surveillance program 430 of
With respect to act 530, the identification of the memory unit is recorded in the memory store pending the completion of a further verification test (see e.g.
Persons skilled in the art will understand the differences between logical and physical addressable memory spaces. Logically, a memory space is divided into memory blocks, which are addressable from lower to higher logical memory addresses. While a logically addressable memory space typically spans from lower to higher memory addresses, this is not necessarily true for the corresponding physical memory space. For each memory block, its logical memory address corresponds to the physical address where it can be found in the physical memory space. In order to translate from a logical address to the physical one, a computing system customarily employs a translation table when performing memory management.
In one embodiment, to facilitate recording of the identification of the memory unit in the memory store, at 525, a physical address associated with the memory unit may be determined by converting a virtual memory address of the memory unit to a physical address (e.g. with the help of virtual-to-physical address translation tables or conversion look-up tables 420, typically located inside the microprocessor and being part of the computer hardware architecture 425 of
Furthermore, in addition to recording the identification of the memory unit (for which an error was detected) in the memory store, in accordance with at least one embodiment, the memory unit is isolated from at least one other application executing on the computing device at 520 (e.g. with the help of memory holding program 435 of
In one embodiment, with respect to act 530, the identification of the memory unit and potentially other associated data may be recorded in a data structure representing a questionable list (i.e. a list for memory units having errors identified in the primary test that are to be subject to further verification, such as e.g. questionable list 455 of
At 535, it is determined whether testing of the memory is complete; if testing of the memory is complete (e.g. a user has terminated execution of the testing application or the computing system is restarted), the flow of method 500 proceeds to 540 marking the end of the primary test, otherwise the flow of method 500 proceeds back to 510 where testing of the memory continues.
In one embodiment, surveillance of the memory may be performed continuously—effectively in an endless loop until execution of the testing application terminates or the computing system is restarted. In that case, the flow of method 500 may proceed from act 535 automatically back to 510.
In at least one variant embodiment, a threshold value is associated with the primary test. If, for a given memory unit, the number of errors that are detected by the primary test exceeds the threshold value, then an error in the memory unit will be detected. However, if the number of errors that are detected for the given memory unit by the primary test fails to exceed the threshold value, then an error in the memory unit will be deemed to not have been detected, even if some failure of the memory unit had been identified in the primary test. For example, if the threshold value is set to zero, then this effectively would cause an error to be detected for the given memory unit if any error is identified; on the other hand, in some implementations, the threshold value may be set to a higher non-zero value. The threshold value associated with the primary test may be user-configurable (e.g. set by a user of the computing device or an administrator).
The number of errors may be proportionate to the number of test patterns that the memory unit failed during the primary test, for example. In one embodiment, an indication of the number of errors detected in the memory unit by the primary test may be recorded, in association with the identification of the memory unit, in the memory store. In another embodiment, a grade for the memory unit (see e.g. discussion of grades with reference to
Referring now to
Memory cell failures having patterns of regular and irregular reappearances may be treated differently since repetitive memory cell failures will typically guarantee a computing system crash, while “weaker” non-repetitive memory cell failures typically do not have such severe consequences (i.e., the non-repetitive failures may or may not cause a computing system crash).
A verification test may be performed subsequent to the primary test (e.g.
In at least one example embodiment, the focus test comprises performing a memory test not only on a given memory unit (whether it be an individual memory cell or a memory block), but also on one or more memory cells in the physical neighborhood of that memory unit (e.g. adjacent or otherwise in close proximity to the given memory unit). The one or more cells in the neighborhood of that memory unit may belong to different memory units. This practice recognizes that the operation of weak cells may be affected by physically neighboring cells, and in addition, that weak cells are often found in clusters. The error in the given memory unit may be considered to be successfully verified by the focus test when a number of errors that are detected, by the focus test, in the given memory unit exceed a threshold value associated with the focus test. For example, if the threshold value is set to zero, then this effectively would cause the error in the given memory unit to be successfully verified whenever any error in the given memory unit is identified by the focus test; on the other hand, in some implementations, the threshold value may be set to a higher non-zero value. The threshold value associated with the focus test may be user-configurable (e.g. set by a user of the computing system or an administrator).
In at least one example embodiment, the focus test may involve, in addition to or alternatively to testing of memory cells within the neighborhood of memory units under test, applying a substantially greater number of tests to the memory units under test, compared to the number of tests applied during the primary test. For example, a first number of test patterns may be applied to memory units during the primary test, and a second number of test patterns may be applied to memory units during the focus test, where the second number is substantially greater than the first number. By way of illustration, a memory cell may be subject to testing using a number of test vector patterns on the order of thousands during a primary test, whereas each memory cell being tested during a focus test may be subject to testing using a number of test vector patterns on the order of millions.
The main purpose of the primary test is to scan the whole range of memory of a computing system to check that it is in working order. This test may be done when computer is idle. For example, if the computing system is idle for one hour, the number of test patterns employed may be smaller than when the computing system has been idle for an entire day. On the other hand, the main purpose of the focus test is to test questionable memory cells in depth. These cells are tested with an extensive set of test vector patterns until they are found either to be good, or their problems are identified.
In one implementation, the focus test may be performed in response to a determination that the computing system has spare resources due to a current underutilization of the at least one processor. This may minimize the drain on processing resources of the computing system. For example, the testing application may be configured such that the focus test is performed when the at least one processor is considered to be at 20% utilization (or below). This may mark the focus test as a low priority task. For instance, if the user of the computing device is not doing anything active and the computing device is not running on battery power, then the focus test may be permitted to proceed; if the user recommences using the computing device, the focus test may be halted and the testing application may go into an idle state.
The acts of method 550 begin at 555. At 560, data identifying memory units that failed the primary test is read from memory. For example, a data structure in which memory units with memory errors have been identified (e.g. in questionable list 455 of
If the questionable list is empty, or if it is otherwise determined that there are no memory units with errors to be verified at 565, the flow of method 550 will proceed back to 560 to continue monitoring. In one embodiment, the frequency at which the questionable list is polled may be user-defined (e.g. by a user of the computing device or an administrator). Otherwise, if a memory unit is identified for which an error is to be verified, a first memory unit is then initially selected for testing, and the flow of method 550 proceeds to 570. A memory unit may be a memory cell, as illustrated in
At 570, the comprehensive memory test on the selected memory unit is performed (e.g. with the help of focus test program 440 of
If, at 575, it is determined that a memory error in the selected memory unit is not successfully verified by the testing performed at 570, then at 590, the selected memory unit is deleted from the questionable list and the flow of method 550 proceeds to 592. On the other hand, if the memory error in the selected memory unit is successfully verified, the selected memory unit is identified as defective in 580.
If the selected memory unit is identified as defective in 580, the testing application may continue to prevent access to the memory unit by another application of the computing system.
In one embodiment, at 585, if the memory error in the selected memory unit was not successfully verified, the isolated memory unit (see e.g. 520 of
At 580, identifying the selected memory unit as defective may comprise recording an identification of the memory unit and potentially other associated data in a data structure representing a permanent list (i.e. a list for memory units having errors that have been verified, such as e.g. permanent list 450 of
If the questionable list and the permanent list are implemented using different data structures, the recording of a memory unit as defective in the permanent list may trigger or be triggered by a contemporaneous deletion of the identification of the memory unit in the questionable list (e.g. an act analogous to act 590 would also be performed before or after 580, although not explicitly shown in
However, in a variant implementation, a single data structure may be used to represent both questionable and permanent lists. An identification for each memory unit for which the primary test (
At 592, it is determined whether there are more memory units identified in the questionable list to be verified; if so, the flow of method 550 proceeds back to 570 where a next memory unit is selected for testing, otherwise the flow of method 550 proceeds to 594 marking the end of the focus test.
In one embodiment, the acts of method 550 may be performed continuously—effectively in an endless loop until execution of the testing application terminates or the computing system is restarted. In that case, the flow of method 550 may proceed from act 592 automatically back to 560.
The inventors have recognized that methods 500 and 550, when performed in combination, constitute a two-part test that greatly improves efficiency with respect to the testing of memory devices in a field testing environment.
Memory units for which errors have been verified in a focus test (e.g. method 550 of
Referring now to
At 610, the computing system is powered up. Then, at 615, the UEFI/BIOS hardware (e.g. 465 of
At 620, a system memory map is generated. This version of the map has yet to be adjusted to accommodate defective memory units (e.g. memory cells and/or memory blocks) that have been identified and verified during testing in accordance with at least one of the embodiments described herein.
Accordingly, in one example embodiment, at 625, a data structure identifying defective memory units (e.g. permanent list 450 of
Moreover, in at least one embodiment, memory units that have been excluded from an updated system memory map will also be excluded from further testing (e.g. from the memory units being tested at 510 of
Acts of one or more of the methods described herein may be embodied as computer-readable instructions, stored in a non-volatile storage device, for example.
Additional embodiments include any one of the embodiments described above, where one or more of its components, functionalities or structures is interchanged with, replaced by or augmented by one or more of the components, functionalities or structures of a different embodiment described above.
It should be understood that various changes and modifications to the embodiments described herein will be apparent to those skilled in the art. Such changes and modifications can be made without departing from the spirit and scope of the present disclosure and without diminishing its intended advantages. It is therefore intended that such changes and modifications be covered by the appended claims.
Although several embodiments of the disclosure have been disclosed in the foregoing specification, it is understood by those skilled in the art that many modifications and other embodiments of the disclosure will come to mind to which the disclosure pertains, having the benefit of the teaching presented in the foregoing description and associated drawings. It is thus understood that the disclosure is not limited to the specific embodiments disclosed herein above, and that many modifications and other embodiments are intended to be included within the scope of the appended claims. Moreover, although specific terms are employed herein, as well as in the claims which follow, they are used only in a generic and descriptive sense, and not for the purposes of limiting the present disclosure, nor the claims which follow.
This application claims the benefit and priority of U.S. Provisional Patent Application Ser. No. 61/694,188, filed on Aug. 28, 2012. The entire contents of such application are hereby incorporated by reference.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4001818 | Radichel et al. | Jan 1977 | A |
| 4209846 | Seppa | Jun 1980 | A |
| 4240143 | Besemer et al. | Dec 1980 | A |
| 4379259 | Varadi et al. | Apr 1983 | A |
| 4426688 | Moxley | Jan 1984 | A |
| 4479214 | Ryan | Oct 1984 | A |
| 4484329 | Slamka et al. | Nov 1984 | A |
| 4821238 | Tatematsu | Apr 1989 | A |
| 4965799 | Green et al. | Oct 1990 | A |
| 5224107 | Mattes | Jun 1993 | A |
| 5375228 | Leary et al. | Dec 1994 | A |
| 5450576 | Kennedy | Sep 1995 | A |
| 5539697 | Kim et al. | Jul 1996 | A |
| 5588112 | Dearth et al. | Dec 1996 | A |
| 5612965 | Michaelson | Mar 1997 | A |
| 5619430 | Nolan et al. | Apr 1997 | A |
| 5619926 | Engelmann et al. | Apr 1997 | A |
| 5666482 | McClure | Sep 1997 | A |
| 5671229 | Harari et al. | Sep 1997 | A |
| 5720031 | Lindsay | Feb 1998 | A |
| 5751641 | Petrosino | May 1998 | A |
| 5758056 | Barr | May 1998 | A |
| 5764878 | Kablanian et al. | Jun 1998 | A |
| 5774647 | Raynham et al. | Jun 1998 | A |
| 5794175 | Conner | Aug 1998 | A |
| 5844913 | Hassoun et al. | Dec 1998 | A |
| 5862314 | Jeddeloh | Jan 1999 | A |
| 5867702 | Lee | Feb 1999 | A |
| 5905858 | Jeddeloh | May 1999 | A |
| 5937367 | Eckardt | Aug 1999 | A |
| 5940875 | Inagaki et al. | Aug 1999 | A |
| 5959914 | Gates et al. | Sep 1999 | A |
| 5986950 | Joseph | Nov 1999 | A |
| 5995424 | Lawrence et al. | Nov 1999 | A |
| 5995915 | Reed et al. | Nov 1999 | A |
| 5996096 | Dell et al. | Nov 1999 | A |
| 6002623 | Stave et al. | Dec 1999 | A |
| 6014759 | Manning | Jan 2000 | A |
| 6018484 | Brady | Jan 2000 | A |
| 6029262 | Medd et al. | Feb 2000 | A |
| 6035432 | Jeddeloh | Mar 2000 | A |
| 6052798 | Jeddeloh | Apr 2000 | A |
| 6055653 | LeBlanc et al. | Apr 2000 | A |
| 6055661 | Luk | Apr 2000 | A |
| 6058055 | Brunelle | May 2000 | A |
| 6085334 | Giles et al. | Jul 2000 | A |
| 6125392 | Labatte et al. | Sep 2000 | A |
| 6134690 | Ivaturi et al. | Oct 2000 | A |
| 6154851 | Sher et al. | Nov 2000 | A |
| 6158025 | Brisse et al. | Dec 2000 | A |
| 6173382 | Dell et al. | Jan 2001 | B1 |
| 6178526 | Nguyen et al. | Jan 2001 | B1 |
| 6237110 | Lin et al. | May 2001 | B1 |
| 6260127 | Olarig et al. | Jul 2001 | B1 |
| 6272588 | Johnston et al. | Aug 2001 | B1 |
| 6275962 | Fuller et al. | Aug 2001 | B1 |
| 6285607 | Sinclair | Sep 2001 | B1 |
| 6304989 | Kraus et al. | Oct 2001 | B1 |
| 6313657 | Hashimoto | Nov 2001 | B1 |
| 6324657 | Fister et al. | Nov 2001 | B1 |
| 6324665 | Fay | Nov 2001 | B1 |
| 6327556 | Geiger et al. | Dec 2001 | B1 |
| 6345372 | Dieckmann et al. | Feb 2002 | B1 |
| 6389525 | Reichert et al. | May 2002 | B1 |
| 6425095 | Yasui | Jul 2002 | B1 |
| 6430720 | Frey et al. | Aug 2002 | B1 |
| 6452411 | Miller et al. | Sep 2002 | B1 |
| 6460152 | Demidov et al. | Oct 2002 | B1 |
| 6499117 | Tanaka | Dec 2002 | B1 |
| 6499120 | Sommer | Dec 2002 | B1 |
| 6536005 | Augarten | Mar 2003 | B1 |
| 6546511 | Sim et al. | Apr 2003 | B1 |
| 6574759 | Woo et al. | Jun 2003 | B1 |
| 6600614 | Lenny et al. | Jul 2003 | B2 |
| 6601183 | Larson et al. | Jul 2003 | B1 |
| 6615379 | Tripp et al. | Sep 2003 | B1 |
| 6622286 | Ngo et al. | Sep 2003 | B1 |
| 6646936 | Hamamatsu et al. | Nov 2003 | B2 |
| 6701474 | Cooke et al. | Mar 2004 | B2 |
| 6708298 | Corbin et al. | Mar 2004 | B2 |
| 6728907 | Wang et al. | Apr 2004 | B1 |
| 6731125 | Chang | May 2004 | B2 |
| 6754117 | Jeddeloh | Jun 2004 | B2 |
| 6820224 | Lin et al. | Nov 2004 | B1 |
| 6851076 | Cook, III et al. | Feb 2005 | B1 |
| 6880118 | Chen et al. | Apr 2005 | B2 |
| 6888366 | Kim et al. | May 2005 | B2 |
| 6889305 | Adelmann | May 2005 | B2 |
| 6910146 | Dow | Jun 2005 | B2 |
| 6996749 | Bains et al. | Feb 2006 | B1 |
| 7010452 | Gomes et al. | Mar 2006 | B2 |
| 7065630 | Ledebohm et al. | Jun 2006 | B1 |
| 7085980 | Martin-de-Nicolas et al. | Aug 2006 | B2 |
| 7088122 | Hartmann et al. | Aug 2006 | B2 |
| 7092902 | Eldridge et al. | Aug 2006 | B2 |
| 7114024 | Herbst | Sep 2006 | B2 |
| 7119567 | Ma et al. | Oct 2006 | B2 |
| 7120777 | Adelmann | Oct 2006 | B2 |
| 7123051 | Lee et al. | Oct 2006 | B1 |
| 7131046 | Volkerink et al. | Oct 2006 | B2 |
| 7142003 | Kanbayashi et al. | Nov 2006 | B2 |
| 7155370 | Nejedlo | Dec 2006 | B2 |
| 7159160 | Yoh et al. | Jan 2007 | B2 |
| 7216273 | Phelps et al. | May 2007 | B2 |
| 7246269 | Hamilton | Jul 2007 | B1 |
| 7251744 | Housty | Jul 2007 | B1 |
| 7260758 | Agrawal et al. | Aug 2007 | B1 |
| 7269765 | Charlton et al. | Sep 2007 | B1 |
| 7272758 | Roohparvar | Sep 2007 | B2 |
| 7287204 | Mayer et al. | Oct 2007 | B2 |
| 7346755 | Pomaranski et al. | Mar 2008 | B2 |
| 7428687 | Klein | Sep 2008 | B2 |
| 7444564 | Anand et al. | Oct 2008 | B2 |
| 7447955 | Niijima et al. | Nov 2008 | B2 |
| 7478285 | Fouquet-Lapar | Jan 2009 | B2 |
| 7590008 | Roge et al. | Sep 2009 | B1 |
| 7603595 | Sasaki | Oct 2009 | B2 |
| 7694195 | Khatri et al. | Apr 2010 | B2 |
| 7783919 | Khatri et al. | Aug 2010 | B2 |
| 7848899 | Lai et al. | Dec 2010 | B2 |
| 7945815 | Khatri et al. | May 2011 | B2 |
| 7949913 | Norrod et al. | May 2011 | B2 |
| 8276029 | Khatri et al. | Sep 2012 | B2 |
| 8321731 | Taylor et al. | Nov 2012 | B2 |
| 8800047 | Kline et al. | Aug 2014 | B2 |
| 20010042225 | Cepulis et al. | Nov 2001 | A1 |
| 20020073353 | Fish et al. | Jun 2002 | A1 |
| 20020108072 | Beng Sim et al. | Aug 2002 | A1 |
| 20020120826 | Venkatraman et al. | Aug 2002 | A1 |
| 20020157048 | Roohparvar | Oct 2002 | A1 |
| 20020184445 | Cherabuddi | Dec 2002 | A1 |
| 20030005367 | Lam | Jan 2003 | A1 |
| 20030058711 | Benedix et al. | Mar 2003 | A1 |
| 20030095455 | Dono et al. | May 2003 | A1 |
| 20030145250 | Chin | Jul 2003 | A1 |
| 20030208654 | Krontz et al. | Nov 2003 | A1 |
| 20030226090 | Thayer | Dec 2003 | A1 |
| 20040034825 | Jeddeloh | Feb 2004 | A1 |
| 20040042293 | Ogino | Mar 2004 | A1 |
| 20040088614 | Wu | May 2004 | A1 |
| 20040186688 | Nejedlo | Sep 2004 | A1 |
| 20050022066 | Herbst | Jan 2005 | A1 |
| 20050060514 | Pomaranski et al. | Mar 2005 | A1 |
| 20050120270 | Anand et al. | Jun 2005 | A1 |
| 20050149687 | Adelmann | Jul 2005 | A1 |
| 20060004942 | Hetherington et al. | Jan 2006 | A1 |
| 20060059383 | Roohparvar | Mar 2006 | A1 |
| 20060236165 | Cepulis et al. | Oct 2006 | A1 |
| 20070061637 | Ward et al. | Mar 2007 | A1 |
| 20070101238 | Resnick et al. | May 2007 | A1 |
| 20070136385 | Abrashkevich et al. | Jun 2007 | A1 |
| 20070136625 | Niijima et al. | Jun 2007 | A1 |
| 20070140025 | Chan et al. | Jun 2007 | A1 |
| 20070147144 | Tokiwa | Jun 2007 | A1 |
| 20070150777 | Sasaki | Jun 2007 | A1 |
| 20070174718 | Fouquet-Lapar | Jul 2007 | A1 |
| 20070217559 | Stott et al. | Sep 2007 | A1 |
| 20070260828 | Swaminathan et al. | Nov 2007 | A1 |
| 20080229143 | Muraki | Sep 2008 | A1 |
| 20080235505 | Hobson et al. | Sep 2008 | A1 |
| 20080247243 | Kang et al. | Oct 2008 | A1 |
| 20080301530 | Spanel | Dec 2008 | A1 |
| 20090049257 | Khatri et al. | Feb 2009 | A1 |
| 20090254777 | Feyt et al. | Oct 2009 | A1 |
| 20090300413 | Chang et al. | Dec 2009 | A1 |
| 20100251044 | Khatri et al. | Sep 2010 | A1 |
| 20110179324 | Lai et al. | Jul 2011 | A1 |
| 20110276844 | Potter et al. | Nov 2011 | A1 |
| 20110305086 | Fujimura et al. | Dec 2011 | A1 |
| 20120075944 | Ide et al. | Mar 2012 | A1 |
| 20120291132 | Kline et al. | Nov 2012 | A1 |
| 20130135951 | Ho et al. | May 2013 | A1 |
| Number | Date | Country |
|---|---|---|
| 0704854 | Apr 1996 | EP |
| 2005234744 | Sep 2005 | JP |
| 9802816 | Jan 1998 | WO |
| 9905599 | Feb 1999 | WO |
| 9950748 | Oct 1999 | WO |
| 0229824 | Apr 2002 | WO |
| Entry |
|---|
| Hermann, AI., Diagnostic Data Comparator, IBM Technical Disclosure Bulletin, IBM Corp. New York, vol. 24, No. 5, Oct. 1981, pp. 2591-2592. |
| Co-pending U.S. Appl. No. 14/011,508, “Systems and Methods for Testing Memory”, filed Aug. 27, 2013. |
| Non-Final Office Action mailed Jun. 21, 2013 in U.S. Appl. No. 13/306,617 (US Pub. No. US-2013-0135951-A1, published May 20, 2013) Total 13 pgs. |
| Number | Date | Country | |
|---|---|---|---|
| 20140068360 A1 | Mar 2014 | US |
| Number | Date | Country | |
|---|---|---|---|
| 61694188 | Aug 2012 | US |
