In the past 10 years, major improvements have streamlined design cycle time in the electronic design automation industry. But little, if any, headway has been made in making the post-silicon test-development cycle time more efficient.
Developing IC test programs for ATE still is a time-intensive task that occurs near the end of the design cycle, after first silicon. Although test engineers can automatically translate design simulation data into test patterns tailored for the target tester, this translation process usually generates errors that only are discovered after first silicon. As a result, days or even weeks are spent debugging test patterns, consuming valuable ATE time and delaying the overall IC development process.
To minimize the time and resources needed to debug and verify test vectors, a new approach has been developed that creates a virtual test environment. Now, test engineers can fully debug test vectors before first silicon, minimizing the need for ATE during debug and substantially improving an IC’s time-to-market.
Level One Communications provides mixed-signal ICs for high-speed telecommunications and networking applications. Recently, we evaluated this new approach and were quite impressed with the results.
Test-Vector Challenge
VLSI design tools typically contain a fault simulator that enables the designer to generate a set of test vectors, guaranteeing a high degree of fault coverage. Unfortunately, these vectors are not in the form required for most commercial testers. As a result, translation software, more than likely developed internally, reformats the test vectors.
Translation often creates subtle errors in the vectors that a test engineer must track down and correct. In many cases, the test vectors contain errors such as missing pin functions, wrong strobe timing, simulation errors, translation errors, initialization errors, I/O contention errors, and timing errors.
Sometimes, errors in the test vectors are not created during translation, but stem from the actual pattern data created on the designer’s test bench. In these cases, the test engineer must convince the design engineer that the pattern data is fundamentally incorrect—an unappealing task that strains the relationship between design and test.
Until recently, all test engineers had to wait for first silicon to debug and verify the translated vectors. Every error had to be found and resolved by running the vectors through the prototype IC using expensive ATE.
Quite frequently, it took days or even weeks to fully debug test patterns. Obviously, this has a negative impact on a company’s time-to-profit for the device and diverts valuable ATE resources from revenue-generating products. What’s more, this adds up to needless delays in the product development cycle, diverting valuable time and resources from more productive efforts.
An Application
A new approach based on virtual testers can help test engineers streamline test-vector debug and verification. Test engineers can perform IC test development in a fault-free, virtual test environment prior to silicon fabrication.
Although the test development time remains the same, the overall product development cycle is shortened because test development and verification now can occur in parallel with design, layout, and fabrication. And test engineers no longer have to divert precious ATE time for debugging vectors.
At Level One Communications, we are very interested in exploring different ways to reduce the time and cost of test development and agreed to evaluate the Digital VirtualTester™ (DVT) from Integrated Measurement Systems (IMS). DVT uses a virtual tester to provide methodology and tools for verifying test patterns and timing prior to silicon arrival.
For the evaluation, we used a DVT Verilog model of our Hewlett-Packard 9490 ATE and test vectors for one of our devices that had just gone to silicon. Using an actual device enabled us to directly compare the effectiveness of virtual testing the vector test vs actual testing on ATE.
The device was our LXT370, a T1/E1 data transmitter/receiver mixed-signal design that contains 70k digital gates as well as memory and analog circuitry (Figure 1). We focused the evaluation on debugging test vectors for the digital portion of the design.
The LXT370 device had both functional and scan vectors to be verified. The functional vectors contained 300k vectors divided into 15 sets, with an additional 1.2M vectors to complete the scan testing defined for the device. Since the format for the scan vectors is different from functional vectors, a different translator was used, increasing the chances of translation errors.
Locating Errors
Four categories of problems were uncovered using the virtual tester: test bench omissions, timing errors, bus contention issues, and nonfunctional patterns.
When the virtual tester simulated the translated test vectors on the tester model, it uncovered several errors that were traced back to the designer’s test bench. For example, the test bench included vectors the designer needed during design but forgot to take out when sending the vectors over to test.
By running the vectors on the virtual tester, our test engineers quickly isolated the problems in the test setup from those in the design vector set. Design then was able to directly compare the test simulation results with design simulation results and identify the differences, in some cases by just looking at certain pins and making the corrections immediately. Without the virtual tester, it would have taken weeks to track down these test bench errors and most likely would have resulted in finger-pointing between design and test.
Timing issues comprised the second group of problems. While we could not identify all timing errors because of the ideal model for the HP 9490, we did find clock sequencing errors. Additional errors were identified due to device initialization pattern differences between the test bench and the patterns generated by the HP 9490.
The third group of problems centered on bus contention issues. This type of error typically occurs when a device I/O pin is expected to be an output but the tester’s driver is still enabled. But using the virtual tester output, our test engineers tracked down the contention error and made modifications to the vector set to prevent the contention from occurring.
The fourth group of problems concerned simply bad vectors and their simulation errors or translation errors. By examining the virtual tester simulation output, we traced the error back to the first location where it occurred and compared the pattern with the pretranslated vector. If they matched, then the designer could trace the error location and identify the problem.
Results
After evaluating the device with the virtual tester, the design team examined the results and agreed that the functional errors found in the scan tests were logic design problems. This strong correlation indicated that using a virtual tester before silicon could have saved us a significant amount of time in test vector debug. In addition, using a virtual tester also simplified the interaction between design and test, helping them to work together more as a team to resolve test problems.
As we become more confident in the virtual test environment, we expect that the post-silicon test development cycle can be cut in half. With the addition of more accurate models, this reduction could be even more dramatic. We also are confident that the cost savings from reduced use of valuable tester time will more than cover the cost of the software, reducing the overall cost of our product development.
About the Author
Nat Reeves is a
staff product/test development engineer
at Level One Communications. In addition to 23 years of experience, Mr. Reeves holds a B.A. degree in math and an M.S.C.S. degree from San Jose State and is a Ph.D. candidate in computer engineering at UC Santa Cruz. Level One Communications, 9750 Goethe Rd., Sacramento, CA 95827, (916) 855-5177.
Copyright 1998 Nelson Publishing Inc.
July 1998
|
|