Marc E. Levitt

Designing UltraSparc for testability

With a focus on a short time to volume production, the UltraSparc microprocessor design incorporated innovative features that optimize test, debug and manufacture. The following areas are discussed: goals; cost-benefit analysis; scan design; decoded multiplexer; test generation flow; custom circuit blocks; boundary cell design; embedded array testing; and clock control features.

ASIC testing upgraded

Nontraditional test methods being developed in response to the demand for quality parts in short development times are described. The need for a complete economic model that includes the time-to-market and quality costs associated with testing along with the usual test pattern generation and test hardware costs is discussed. The limitations of current approaches are identified, and three new methods-scan (in a variety of forms), built-in-self-test, and massive observability-are examined, and their advantages and drawbacks are considered.<<ETX>>

A fault diagnosis methodology for the UltraSPARC/sup TM/-I microprocessor

In this paper we study the use of precomputed fault dictionaries to diagnose stuck-at and bridging defects in the UltraSPARC/sup TM/-I processor. In constructing the dictionary we analyze the effect of the dictionary format on parameters such as memory size, computational effort, and diagnostic resolution. The dictionary is built based on modeled stuck-at faults. However to effectively diagnose both stuck-at and bridging faults, we employ a novel procedure that combines dictionary information with potential bridge defects extracted from layout. Experiments with failing devices show excellent correlation of predicted errors with actual defects.

Microprocessor testing (panel): which technique is best?

Microprocessors, in some sense, symbolize the universe in design techniques. Virtually all general and special test techniques are applicable to some section of a microprocessor. What are some of the key companies doing for microprocessor testing today? Is there really a difference between verification and testing of a microprocessor? How much of testing can we afford to do? How do the various fault models really stack up against actual failures? What is an adequate coverage number? How effective are built-in self-test (BIST) techniques? Can we really tolerate the performance hit from BIST techniques? Is there a convergence of ideas on how to do BIST? What are the major companies doing for fault simulation, test pattern generation? Is tester performance keeping up with the advances in design? How severe is the pin count problem of the testers? What are the future challenges?