Christophe Suzor in France my personal blog, a place to speak out in public


Humans understand results, computers just handle data

In my work I often deal with, or I help others deal with, significant volumes of data, with the goal of identifying trends or correlations or to validate a hypothesis.

Too often, there is a tendency to let the automated software find a result, and then trust that result as a mathematical fact and the solution to the problem, which is neither well defined nor sufficiently bounded. In the wrong hands, sophisticated analysis tools lead to the wrong conclusions. It's like teaching a kid how to use a calculator before teaching the 4 basic math operations. Or teaching a teenager the formula for standard deviation without explaining the principles behind a normal distribution.

When a computer produces a result that the human driving that computer, as the owner of the data, does not fully understand, the result is probably junk for the problem the human is trying to solve.

The corollary is that the correct result should be understood by the human that owns the data and posed the problem to be solved by the computer. Fundamental stuff worth remembering.


The challenges at work

After a brief summer vacation, the stress caused by external expectations at work is a little more difficult to handle. We've all been through periods of intense external pressure at work, and despite efforts to deliver according to expectations, the results are not entirely satisfactory for the recipients.

A recent difficulty involves a parser for an industry standard format, where the objective is to enable a key differentiator in our commercial product. The parser meets the requirements of most users, but fails to satisfy those who planned to extend the use cases beyond the original product intentions.

Another situation concerns customization of the product, using the built-in tools to provide the automation for special use cases, creating an application with high added value. The initial requirements are met, but users always desire new functionality as their experience grows and they face new challenges.

This type of situation is often encountered for those providing products and services with high added value, and can lead to a never ending list of remaining tasks and a growing set of deliverables. My advice is:

- Set and agree on the correct expectations early in the project, and remind everyone of this agreement as often as needed.

- Create the appropriate environment and business model to cope with an increased specification or list of deliverables.

Creating a win-win scenario between the user or buyer, and the supplier, requires both of the above conditions, and will avoid frustrations on both sides as is typically seen with complex projects. The difficulty in implementing such a situation often comes from the involvement of multiple persons, with individual goals, and the end result is a loop that is not closed.

Enough procrastination, time for action!


Getting better performance

All new software projects go through a phase where performance, defined as the number of tasks and the volume of data handled, divided by the time required to achieve the desired result, is much less than originally planned. When this performance shortfall impacts overall project success, solutions must be found, and it's not always easy to retrofit them.

A common software programming approach is to build complex multi-purpose objects, and give those objects many properties and methods. This leads to significant overhead, creating performance issues when dealing with huge data sources and/or situations where the methods are too generic and not optimized.

A complementary approach is to create numerous reusable building blocks, each with limited functionality, and then sequence many of these together to create an application, commonly known as a workflow. This leads to significant inter-process data transfer, which is typically limited to one way transfers. There is significant overhead associated with managing each block, and performance decreases significantly as the workflow becomes more complex with a large number of blocks.

The data structures used can also represent a significant usability and/or performance constraint, such as choosing flat data representations when hierarchy exists, or sequentially accessed data files when random access is required, or when data compression schemes interfere with optimal data access (such as column compression when row access is required from tables).

The highest performance can only be achieved with software that enables the use case in the most direct way, with the least number of unused options and the smallest number of building blocks. In complex environments, this can lead to a large number of use case specific software, and a balance has to be found with other techniques.

My advice is to carefully align the software approach with the expected use cases, and to accept fundamental changes to correct early wrong assumptions, instead of implementing workarounds which inevitably lead to less performance. And when ultimate performance is required, specific development can circumvent existing methods and objects to "get the job done fast".


my software: simple, reusable and adaptable

There are some ideas in life that summarize the approach we each have in everyday situations.

For work, where we provide software to analyze and solve complex industrial problems, my approach is: simple, reusable and adaptable.

Simple: this leads to the fastest solution, least time spent on specification, and less rework when the requirements change.

Reusable: software solutions are assemblies of individual building blocks, and with reusable blocks new solutions can be competed faster.

Adaptable: the details of the requirement are never fully understood until the solution is in use in real situations, so it is essential to adapt deliverables in the field to achieve success.

More than a philosophy, these concepts are part of my daily activity.


Enterprise Yield mgt IT infrastructure

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.

Filed under: Work Comments Off

Yield mgt is a custom project

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.

Filed under: Work Comments Off

STDF for test results

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.

Filed under: Work Comments Off

Memory BIST analysis

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.

Filed under: Work Comments Off

Diagnostics for Yield mgt

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.

Filed under: Work Comments Off

my first post

Hello. This is my 1st post.
Creating my blog was one of my 2010 goals.
There are 2 categories, personal and work.

I will post some major events in my life in "personal".

As product manager at Synopsys in Yield management, I will begin a series of regular posts on the major topics in this space, in "work".

Comments and emails are welcome.

Filed under: Personal, Work No Comments