Suppose you were given the assignment to find a basketball in the Los Angeles area—just one basketball in no particular location, but in a location where it wasn’t supposed to be. How would you begin?
Being assigned the task of finding a defect in a modern IC device can be similar to having to find that errant basketball. Are you ready for this task? Your company’s reputation for quality may depend on it.
When it comes to products for the medical or automotive markets, the quality requirements are extremely high, targeting very low to zero DPPM (defective parts per million). In many cases, the customer sets these requirements, dictating, for instance, both the specific metrics for test-coverage goals and the fault models that you must use. Test requirements also can be associated with specific industry standards, such as those from the Automotive Electronics Council, to ensure that comparative metrics are used.
Many companies have entire organizations and teams dedicated to product quality and yield enhancement, and DFT (design for test) is a key element from product planning through production. Although high test coverage is commonly used as a defining metric, it is only one piece of providing high-quality IC products. In addition to ensuring adequate test coverage, you must generate the correct test patterns, ensure they run on the specified ATE (automatic test equipment), and also ensure they work on first silicon and in production test. And when material starts to fail tests, you must be able to identify the root cause so the problem can be avoided next time. Quality doesn’t happen by accident; it must be designed into the product and process.
Planning for quality
Some wise person once said that most people don’t plan to fail; they just fail to plan. A comprehensive test plan is imperative for achieving high-quality ICs. The first step in developing a plan is to determine what the quality requirements are for the design and what elements in the design need to be tested to ensure those requirements are met. For instance, is the design all digital logic, or does it also have some analog pieces? Does the design include embedded memories or PLLs (phase-locked loops) for on-chip clock generation? Are there high-speed I/O pins or any other special interface requirements? What are the requirements for the target market?
Here are some of the main items to consider when putting together a test plan:
- For large designs or when using multiple ATPG (automatic test-pattern generation) fault models, it is common to include some on-chip test-compression technique. Does this design need test compression? If so, how much?
- Which BIST (built-in self-test) algorithms will you use to test any on-chip memory?
- Which type of ATE will you use? What are its capabilities and limitations? Will testing occur at the wafer level, at the packaged-part level, or both?
- Must tests run at system speed? How many clock domains are there, and how should testing be done between those domains?
- Will diagnostics and FA (failure analysis) be done when ICs fail during production test? How will that data be used to improve yield and quality?
- What standards need to be complied with, such as IEEE 1149.1 or 1149.6 for boundary scan?