DFT Digest

[editors note: This post is third in a regular series of featured contributions from Stephen Pateras of LogicVision]

John provided a good overview of embedded memory repair techniques in his Memory Repair Basics post late last year. Although there’s been some limited adoption of memory repair at 90nm, at 65 and 45nm it’s a whole different story. In fact, at 45nm, it’s becoming the norm. But, like any new product, there’s a fair amount of uncertainty about when to use memory repair and how much is too much. (Yes, you can have too much of a good thing). Let’s see if I can clear up some of the confusion with a few (hopefully) helpful tips.

The first big question, of course, is whether memory repair is even needed. To answer this, ask yourself: Will the yield improvement I get by performing repair make up for the silicon costs of adding the needed memory redundancy? Answering this question depends mainly on two factors: the defect density of the process (which is directly related to its maturity) and the amount of memory on the device. In general, your foundry can give you guidelines on when to use repair based on these parameters. That said, in most 65nm processes today, you’ll probably want to use repair if you have more than a few megabits of embedded memory on your chip.

The next important question then becomes: How MUCH redundancy do I need to add? Well this, not surprisingly, also depends on defect density and the size of the memory. However, it turns out that there are some simple rules you can use to determine how many spare elements (rows and/or columns) to add to a memory. From a statistical point of view, the first spare element added to a memory provides the most yield improvement, while each additional spare element provides exponentially less value. This is because the probability of having a growing number of defects within a single memory decreases at an exponential rate. Now, couple this with the fact that each time you add a spare element, you increase the silicon cost and you can quickly see that only a very small number of spare elements per memory are ever warranted. In fact, a good rule of thumb is to add a single spare element to medium-sized memories (say between 100 Kbits and 500 Kbits) and only two spare elements to larger memories. Memories under 100 Kbits should generally not get any spares.

Finally, if electrical fuse (eFuse) based self-repair is to be used (which is typically the case these days), then another important decision has to be made. An eFuse-based self-repair approach has a centralized fuse pool where fuses are shared across all memories containing redundancy. The challenge here is to insert ENOUGH fuses to deal with all the repairs that may be needed but NOT TOO MANY so as to waste silicon area. Some complex statistical theory can again be used to figure out an optimal number. Fortunately, you can avoid the higher math and, again, employ an easy rule of thumb: You only need enough fuses to store around 10 repairs (with each repair generally needing between 8 to 10 bits of data) regardless of the number of memories or the amount of available redundant elements. Why such a small number? First, the probability of having more than a handful or two of defects on a die is pretty small. Second, and perhaps more importantly, as you get beyond a few defects on a die, the non-memory portion of the die quickly becomes the limiting factor. In other words, when you get to more than a handful of defects on a die, the probability quickly approaches 100% that you are going to hit some other portion of the device (logic, I/O, etc) that can’t be repaired thereby killing the device.

If you want to learn more about memory repair, you can click here to download a memory repair primer that discusses all aspects of memory repair including more detailed analysis of the issues discussed in this post.

[Steve Pateras is VP of marketing at LogicVision. Steve performed his graduate work in test and has spent his entire career involved in either using, defining, or marketing DFT and BIST products and technologies]