Use test data to diagnose failed memory

Martin Keim, Mentor Graphics
EDN (October 16, 2014)

Here's a common situation for memory designers: your RAM or flash has been fabricated, but the yield is lower than you would like. Maybe there is an odd correlation between a particular failure mode and your manufacturing process, but you'll need solid data to track down the yield limiter. The only information you get from the tester is pass/fail, so it doesn't really help you to identify the root cause.

There are many different ways to get more details from your failing memories. As usual, there are pros and cons to each of them, but overall, you want meaningful data at the lowest cost. In the test world, costs can come in several forms: on-chip hardware dedicated to testing and data collection, the volume of test patterns that must be stored on a tester, and the time it takes to execute a test. For tests applied from a tester, execution time is usually determined by the number of test patterns and the speed at which they can be applied. However, when the testing is performed using BIST (built-in self-test), determining test execution time is not straightforward, especially when you are trying to collect data during test.

The most obvious method of collecting fail data from memories is to bring all memory ports to the top level of the design, create a physical interface to the tester and collect data from there. For many reasons, this method is just not practical for large, complex SoCs (system on chips) with many deeply embedded memories. Just to name a few reasons, the high number of required paths consumes chip real estate and causes routing congestion; it also requires many I/O pins, which drives up chip cost and may even exceed the number pins available on the tester.

Another approach is to employ BIST circuitry on the chip. Memory BIST (MBIST) is, however, usually designed to provide pass/fail data only. Unless an MBIST controller is specifically designed for data collection, you won't get much useful information from it. With a purpose-built MBIST controller, both test application and data collection can be done on-chip at full operational clock speeds in the GHz range. Of course, at the end of a test pass, the data collected by the MBIST controller will be scanned back into the tester for subsequent processing.

Click here to read more ...