SoC Yield management: an emerging issue that could reshape the industry

In a relatively little-noted (except by EDN’s Ann Mutschler) move last week, ATE giant Verigy announced acquisition of what appears to be an entirely overlapping but much smaller company: Inovys. On the surface, this doesn’t appear to make much sense. Inovys makes small, desk-top and desk-side characterization systems—the same type of equipment for which a previous company, Integrated Measurement Systems, demonstrated there was no great market, before they were absorbed into Credence.

But there’s a very important point lurking behind the puzzle here. It’s not about Verigy’s business strategy so much as it is about the nature of yield at 65nm and beyond, and about the structure of our design and test infrastructure.

As Ann’s article points out, and as Verigy senior manager Larry Dibattista confirmed in a later interview, the underlying issue isn’t the size of test equipment. It is yield management: the process of moving from sample yield to mature yield on a new SoC.

Up until somewhere around 90nm, this was not really a design issue if you followed the design rules. Yield was primarily driven by defect density, which was only related to design in the sense that some patterns might be more defect-sensitive than others. Static tools such as critical-area analysis could deal with that. Starting at 90, however, and with increasing severity at each new process node, yield is a complex blend of design choices and process issues. You can’t just toss out failed dice any more on the assumption that they were the unlucky recipients of particle defects. You have to analyze them, determine the failure mechanism, and if the failure is recurring, modify the design or the process to reduce its probability.

Thus yield improvement isn’t about sitting back and waiting for defect densities to improve. It is, as Dibattista describes it, an iterative loop involving design, characterization, manufacturing test, and the dreaded failure-analysis lab. Today, each of these steps is almost an isolated entity: each task performed in a different group, and the groups linked tentatively together by exchanges of data files and text documents. No two of these groups, except maybe design and characterization, even use the same vocabulary, let alone the same data formats. Yet the financial success of most SoC designs hinges on this iterative yield-learning cycle occurring very quickly. Many, if not most, designs at 65nm or below will go into production at yields that don’t meet vendor cost targets.

That was the discussion Dibattista used to explain Verigy’s acquisition. Nothing about the Inovys test systems, but a talk on how Inovys’s failure-localizing software, linked back into the design data base, could work with ATE systems and software to speed yield learning. Dibattista visualizes a loop something like this: Design inserts test structures sufficiently flexible to not only provide good structural test coverage, but to be reconfigured for diagnostic purposes. “Often you have to modify scan chains to localize a defect,” he says. “And often, the failure won’t occur in the same scan chain on every die in the wafer.”

In production test, the ATE systems collect their mountains of data, including a full set on failing dice, not just enough to indicate a reject. This data then goes into a software system that localizes the defect to a particular physical location on the wafer and a particular node in the design data base. This information, in turn, gets passed to the failure analysis lab so they know what they are looking for and where to look. Their failure-mechanism data, in turn, goes back to the yield-learning team—the design and foundry engineers—so that they can craft a fix.

Close interaction between these players makes the loop go faster. One indication of this is that when asked why the relationship with Inovys needed to be an acquisition rather than a joint development, Dibattista said “We couldn’t do some of the things we needed to do in a joint development. We really needed access to the depths of each other’s intellectual property.”

The same may well be true of the design teams, ATE managers, and failure analysis labs working on the yield-learning curve for a particular SoC. Even with tools such as those that emerge from this acquisition, they may find that they need to work more closely than a traditional inter-company development will permit. Does this mean a new kind of contractual relationship, with unprecedented access to IP and experts across corporate boundaries? Or does it mean that we will gradually see reintegration of the design, test, and failure-analysis functions into real, not virtual, IDMs? The answer may change as we move from 65 to 45 to 32nm.