Christophe Suzor in France

To maximize the return on investment in enterprise Yield management software and resources, the choice of an optimal IT hardware configuration is essential.

The factors to consider are essentially: user access modes, data security, application performance, existing environment, and others.

The current push towards centralized applications on remotely accessed hosts, often conflicts with goals of customizability and high performance for advanced users. Centralized data storage presents risks of unauthorized access, despite efforts to enforce user security. Analysis of complex problems often requires extensive data manipulation and correlation, but delays in GUI or data transfers reduces usability and productivity. Re-using existing infrastructure appears attractive but is rarely aligned with recommend high performance requirements.

Local infrastructure configurations are typical for existing applications, but also have significant drawbacks: data and resource duplication, complex correlation of data spread across sites, unmanaged version differences, diverging usecase requirements.

The optimal solution is to centralize logically by group, and distribute physically by region, and ensure that cross-references and compatibility are maintained. Applications must be multi-site enabled, but a high ratio of analyses will use local data only. Deploying application servers close to end users ensures excellent responsiveness and provide excellent performance, with significant RAM and fast disk and multi-CPU availability, as long as the number of concurrent users is set appropriately.

The hardare requirements evolve over time, so servers which are multi-purpose ensure the most flexibility to reconfigure and adapt quickly.

For the last 15 years, software companies have developed standard software packages for Semiconductor companies, with good success.

We are now at a turning point with companies, this industry has matured, yield analysis and reporting requires an ever increasing number of variables, so the data flows are now so complex, that data management solutions must be highly customized, and analyses must be rewritten to include custom data types. Large customers cannot accept to replace existing infrastructure, or replace existing systems, to add new Yield mgt functionality; the new solutions must be integrated into the existing landscape. Smaller customers without significant existing infrastructure are still willing to adapt to new infrastructure, but the current revenue from these is marginal.

The successful companies in the next years must adopt a services model, by providing field customizable software that can be configured into a true solution by competent field services teams working directly with each customer. This model is well known to the industry in other areas, such as employee management (Peoplesoft by Oracle) or financial management (SAP) or factory automation (Applied Materials), but it is still in infancy for Yield mgt.

As always, times are changing, and those who can adapt will be successful.

The transfer of test results from testers to analysis tools can be complex, and the king of the standard file formats is STDF.
Originally a Teradyne spec, it has become an industry standard, to be owned by SEMI, and has been remodelled to adapt to different tester companies and users of test results. In addition to the standard v4 spec, new specs exist for scan fail data, memory fail data, custom field and record definitions, and rules for merging results. Enough to keep thousands of engineers busy to maintain and build tools to create, modify, convert, and analyze STDF.

Modern SOC (system on chip) include embedded memories, sometimes tens or hundreds of small memories. Testing these memories for quality involves triggering BIST (buit in self test), and collecting the result, as a pass/fail or as a list of failing adresses.

With Yield loss on the embedded memories increasing to unacceptable levels, engineers need visibility into the failures, with signature analysis to quickly estimate the failure mechanisms, and export of exact locations for physical failure analysis.

Typical failure mechanisms include design errors, voltage or power problems, patterning or related process problems, random defects, electrical variability, and others.

Traditionally reserved for Failure Analysis investigations, Diagnostics has become essential for understanding low yield on sub-65nm logic and mixed-signal products. Diagnostics identifies failure candidates within the design, with probabilistic scoring of the candidates. The true failures are often mixed with equivalent failures, and similar failures also with a high probability score.

Volume Diagnostics is the methodology to use these failure candidates from a large population, as least several wafers of data, to identify patterns and commonality, to identify the likely true failures. Design-Aware Volume Diagnostics adds design and verification data to the analysis, to optimize the identification of the true failures. Statistics enable the Yield engineer to focus on the most important failures, in terms of their impact on Yield or Performance. Total Volume Diagnostics adds other Test results and Fab/Process data, to enable the Yield engineer to determine the root cause of the failures, and thus provide guidance for Test program or Fab/Process modifications.