Innovation on IO Timings with the Test chips—Tales from the Intel I/O Test Road Map

Our investigative work into the true nature of IO timing failures informed us of the current state of the art testing and the likely source of defects. The challenge to test the timings without using the traditional ATE approach was on. We even had an approach- stressing the timings on the die and self-compare. To prepare for our product intercept, Willamette, we looked to use test chips to build confidence in our approach.

As I reflected upon the usage of test chips I’m reminded of this lyric from a Rolling Stones song:

“You can’t always get what you want,

But if you try sometime you find,

You get what you need.”

Basically,  you work with what you can and learn what you can from it, no matter that it isn’t the final implementation. With new technology you focus on reducing risk by learning as much as you can with what you can get.

Test chips are semiconductor experiments and never sold as product. They have same expense as products though; hence, manager reluctantly spend the money. They would rather have revenue product. You present the case for risk reduction; sometimes they pay. Mike Tripp made the case and mangers granted us a couple chances to try out and refine the ideas.

Our first chance came with the process learning vehicle, essentially an SRAM test chip used to bring up a new semiconductor process. It offers a very regular structure which pushes the design rules. This is a risk you want to reduce- you want a healthy process for which a high yield is the goal. Much easier to add features to a test chip already planned. The X1, process test chip for P858 (35 nm), gave us our first opportunity. The year was 1997.

Working with the SRAM vehicle design team Mike wanted to get enough design hooks in the IO design to enable a demonstration of the methodology. We had limited time to intercept the design and we didn’t fully know what we wanted an implementation to look like. To demonstrate the methodology, he needed an engineer who could develop the test program on the Automatic Test Equipment (ATE). Arash Kia signed on for this task.

With several products worth of test development experience Arash came with the perspective that if you wanted a test engineer to use this in manufacturing you will need to make it easy. As we had only a few DFT hooks it didn’t look pretty from an ease of use perspective in any sense of the word.

The proposed test method had to stress, shorten the timing path, from the output circuit to the input circuit. With the circuit hooks, Mike envisioned using the tester to change where the data would be sampled. We could then compare that measurement to the traditional way to measure timings.  Mike thought it would be good enough to learn from. Arash pointed out it wouldn’t be easy enough to convince a test engineer to do use it.

Data collected and our confidence grew.  At internal conferences we shared the need to move in this direction and we shared the results from the SRAM vehicles. The two papers had the following very descriptive titles:

  • 1998 “AC I/O Loopback Test Method Analysis: X1 Case Study”
  • 1999 “Implementation and Analysis of the X1c AC IO Loopback for Screening Defective IO”

The IO’s on the X1 were common clock, and the product intercept for ACIO loopback would have source synchronous interfaces as well as common clock. Source synchronous was also knew for the microprocessor design team and for interface design spec teams.  They too created a test chip called Timpanogas.  We got to try out some AC IO loopback DFT there as well. By this time working with the microprocessor design team we had more fully developed a basic implementation.

However as often happens with test chips we never fully got the data we intended to collect.  The test engineers left who were supporting the program so we were without a captain. We took what we learned from implementing a silicon design and moved on to making it happened on a product, on something we would sell.

Have a productive day,

Anne Meixner

Dear Reader, What memory or question does this piece spark in you? What’s your point of view of on developing a solution? Please share your comments or stories below. You too can write for the Engineers’ Daughter- See Contribute for more Information.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.