Justifying DFT with a Hierarchical Top-Down Cost-Benefit Model

Abstract

How can we justify system level DFT? We must show that it has a positive return on investment (ROI). Existing test ROI models are manufacturing centric, do not account for the disaggregation of the product realization process, and are often focused on a specific DFT method. We propose a new, top-down, hierarchical ROI model, which starts with potential benefits and can handle entire systems more effectively than current models. IntroductionIt is well known that Design for Testability (DFT) improves quality and saves money. While DFT methods are now standard for most ICs, DFT at the system level is more problematic. One of the reasons for this is the lack of a full stream cost and benefit model, stretching from fab to field, that can help DFT proponents justify the addition of testability. There have been numerous models proposed at the IC level ( Wei [10], for instance) and models proposed at the system level, [11] but none with details on the costs and benefits at each stage of system design and integration, and none focused on the justification of DFT.The purpose of this paper is to provide such a model, but we will go about this in a slightly different way from previous efforts. These have labored to be precise and accurate. To do this, previous models are overly complex, and depend on parameters not known yet or difficult to obtain. Our model, on the other hand, has two goals:• Be detailed enough to give the DFT engineer advice on the important factors to be decided when making the decision to request DFT, and how much to propose. • Provide a convincing financial argument for the benefits of DFT. We don't believe that a manager deadset against DFT will be convinced by any model, but one in favor of it or leaning towards it will value a model to help convince upper management of the value of this effort. This means that the model must be kept simple and parameters which don't significantly affect the use/no-use decision should be dropped. There are some things considered in our model which we think have not been handled well in previous work:• Uncertainty. While Wei's model considers the uncertainty of both costs and benefits, this must be a fundamental part of any model. Understanding the benefits of DFT for an existing product and manufacturing process introduces far less uncertainty than trying to do so for a product yet to be built or designed.• The impact of disaggregation. DFT was first used by vertically integrated companies, where some additional expense at the IC level could benefit the companies bottom line at the system level. Today more systems are built from standard parts, and manufacturing has been outsourced. This limits the freedom of the DFT proponent to add DFT. • The impact of the distribution of actual field failures on the benefit analysis. While it is tough to make predictions, especially about the future, as Yogi Berra said, we want DFT to address the failures most likely to happen. Our model must take all of these factors into account. More importantly, the DFT advocate must take these...

Simplified metrics for evaluating designs for testability

“…Standard, well accepted and generally applicable metrics are needed by designers prior to design finalization, by test engineers to assess the test program development effort, by logisticians to determine support needs and costs, by manufacturers to evaluate ability to detect defects, by those procuring test equipment resources and by those who need to maintain and support a product through a long life cycle. [1,2,3,4,5,6] For DFT to be practical evaluation needs to be completed prior to design release and certainly before test development begins.…”