Abracadabra – using Tessent magic to repair non-repairable memories

The cost for silicon at smaller modern technology nodes is inflationary to say the least. Therefore, yield, cannot just be an afterthought! It needs to be considered upfront and yield loss mitigated as much as possible.

In one of my previous webinars (Introduction to inserting Tessent Shell MBIST IP to test on-chip memories), I mentioned the fact that memories are occupying a larger portion of chip real estate and, the reality that they tend to be denser relative to standard logic also means that probabilistically, they would be the most likely source of faults.

MBIST would allow you to catch those faults during the manufacturing process but, does nothing to remedy them. Consequently, you would end up with wasted silicon – AKA, money thrown in the garbage.

BISR repair affords you the opportunity to minimize that precious silicon loss. In a conventional situation, repair is made possible by adding redundant resources and appropriate logic to the memory in order to facilitate this process.

 Here is a conceptual example of a memory with extra IO/Column and Row resources for this purpose:

For an IO repair scheme, the Muxing logic that is included in the memory would look something like the following:

If there was a fault in any one of the memory IO data bit, it could be repaired with the spare IO from the far right.

From a Tessent Repair flow perspective, those redundant resources along with ports to access them are described in the memory TCD file that it takes as a key input. That access can be done via a parallel or serial interface.

Once the TCD is demonstrated to be correct by construction, the Tessent tools can extract all the information it needs to determine what type of hardware to be added in order to perform repair. From a high level, the main components of that hardware repair solution is as follows:

That flow and hardware is well established and battle tested in 100s of thousands of designs. However, one of the main requirement is that the repairable memory needs to exist with the aforementioned redundant resource and associated control logic.

Suppose you had a “unique” situation where repairable memories are not available but, they are required, would you be dead in the water?

Fortunately, with the help of some Tessent magic, the answer to that question is “No!”. There is a functionality in the tool that is referred to as “External Repair” that allows you to repair normally non-repairable memories.

There are some limitations but, yes, this is possible! In a nutshell, as the name suggests, the repair Muxing and other logic are added outside (AKA: external to) the memory in the memory interface module. Surprisingly, there are just a few incremental steps to the normal repair flow to make it work.

The following schematic diagram shows an example of some of the logic that is added – items in red:

More details about the exact process will be presented and demonstrated next month in a Webinar.

You can check the following link for the exact dates: View and register for Expert Series webinars

With this approach, a user has access to almost all the capabilities of the conventional repair flow such as hard or soft repair. The functionality can be used for prototyping or in limited ways, for in-system repair.