System Design

Simulating Mixed-Signal Tests to Reduce Time-to-Market

A virtual tester paves the way for the real thing.

by Nash Khouzam

To speed up the test-development process, we at National Semiconductor Corp. (Santa Clara, CA) are making radical changes in the way we develop tests for complex mixed-signal and analog ICs. We have to do this because for many devices, time-to-market or time-to-volume is of increasing importance. For these types of parts, many of which go into personal computers or other products with a short product life cycle, customers will not wait. If we cannot ship the parts, the customers will get them from another supplier.

To reduce test-development times, we gave our engineers new test-development tools. These virtual test tools are workstation-based productivity tools for test engineers that allow test development to be accomplished off-line or without a device. Specifically, our initial focus has been on test debug by simulating the tester itself, the test fixture, the test program, and the device. In other words, we simulated the entire test process.

While the tools are important, they are only one element of our new procedures. Along with new tools, we have also put into place a new test-development methodology: one that allows test development to occur concurrently with the design and fabrication processes.

Figure 1. Most of the test-development work typically occurs after receipt of silicon and is slowed by the limited amount of tester time allocated to test development.

Issues with the old approach The major problem with the old method of developing tests for mixed-signal devices was there was little that test engineers could do without live parts. They could write the program, check the program's syntax, and layout the test fixture, but that only accounted for 20 to 40 percent of the job. Characterizing a device and debugging the test program and test fixture consumed 60 to 80 percent of the total test-development time. Typically, test engineers had to wait until they received first parts before they could begin this task. So, as shown in Figure 1, there was considerable unproductive time in the schedule, which caused delays in time-to-market.

Another challenge was that the test development and debug process was complicated by multiple unknowns. For example, if a test engineer ran a new test program on an actual tester, and the test failed, the problem could have been due to one of several factors: a misunderstanding of how the device was supposed to behave, an error in the test program, an error or fault on the test fixture, hardware failure in the tester, a design problem, or a fault in the device.

Due to these complications, it was very difficult to make an accurate estimate of how long it would take to debug a mixed-signal test program. One of our goals was to improve the predictability of the process by gaining a better understanding of the device as well as getting the test program correct so that there were fewer sources of error to consider.

Figure 2. Test Process Simulation simulates the entire test environment to verify that the test program will run correctly.

Tester-based test debug was expensive because it tied up equipment that could have been used to produce production parts. Because production testing was generally the highest priority for these testers, only a limited amount of tester time was allocated to test development. When a test engineer had only a few hours of tester time each week, test development occurred sporadically, lengthening the test-development cycle. We wanted to move to a test-development process that allowed more work to be done without requiring access to a tester.

Design revisions were another factor. If a problem was found in a device, it could take two or more months to revise the design and fabricate new parts, resulting in a major increase in time-to-market. By implementing the right test-development process, we were looking for opportunities for the test group to help reduce the requirement for revisions.

One of the most important effects of all of the above was that test development lengthens time-to-market. This can contribute to a new device missing the optimum market window, resulting in lower profits for the company. After considering all of the issues, NSC management decided to invest in a new test-development process based on the potential time-to-market reduction we believed could be achieved.

The new approach--Test Process Simulation To address the challenges, it was imperative for us to not only give our test engineers new tools but to create a new test-development process for our mixed-signal devices. We wanted to implement changes that would allow test development to occur concurrently with the design and fabrication processes. To accomplish this, we used a set of virtual test tools that were provided by Integrated Measurement Systems Inc. (IMS), Cadence Design Systems Inc., and Teradyne Inc.

With these test-development tools, we can actually design and simulate all the elements of a test, including the tester and the test fixture. By using simulation models of the device, the fixture, and the tester itself, we are able to run test programs in a simulated environment. This allows us to verify that the program works even though we are not using any actual silicon or even a tester. Because we represent everything in the test process--the device, the fixture, the tester, and even the tester operating software--in a simulation, we refer to this as Test Process Simulation.

Test Process Simulation is described graphically in Figure 2. The test program functions in the tester's operating system and connects through a software bridge to the test-event simulator. This environment allows a test program to be compiled and run on a workstation. However, instead of driving a tester, the test-event simulator generates simulation events that represent the signals that will be sent to the device during the test. Those simulation events are passed through the ATE line interface (a part of the Dantes product from IMS), which provides the interfacing into the mixed-signal simulation tools (the Artist environment from Cadence). In the simulation environment, the tester instrument and fixture models pass test events to the device model. Simulated device responses are relayed through the fixture and instrument models back to the test-event simulator. Based on the device response, the test program then continues to run.

The pilot project We decided to conduct a pilot project to evaluate the Test Process Simulation concept. We assigned a test engineer to the project full time, and we selected one of our high-performance devices--the LM 9800. The LM 9800 signal processor/digitizer for linear charge-coupled device (CCD) image scanners performs the entire process, including correlated double sampling for black-level and offset compensation, pixel-by-pixel gain adjust, and 8-bit analog-to-digital conversion for a variety of CCD sensors. The part contains control logic, a correlated double sampler, an offset digital-to-analog converter, a 7-bit programmable-gain amplifier, and an 8-bit analog-to-digital converter.

Figure 3. The Dantes test schematic shows how instruments are connected to device pins.

The LM 9800 is a device for which we already had a test program for the target Teradyne tester. The idea was to use a device that would allow us to focus on simulating the program, not on writing the program.

Once we selected the device, we went through the following steps:

1. Assigned a full-time test engineer to the project.

2. Trained the test engineer in Dantes, IMAGE ExChange, behavioral analog modeling, and mixed-signal simulation.

3. Created a behavioral model of the device.

4. Captured test schematics that showed how instruments connected to the device for each test.

5. Interfaced the test schematics with the test-event simulator.

6. Simulated the running of the test program.

Modeling is key After the assigned test engineer was trained, his first task was to develop a mixed-signal behavioral model of the LM 9800 from the design specifications. We were able to use the Verilog model created by the design group for the digital portion of the device, but we could not use the Spice-level model of the analog portion of the device. To simulate a test, we need to perform a complete device simulation. Simulating a complete, mixed-signal device is not practical from a performance point of view if the analog portion is modeled in Spice. To accommodate the performance process, we used the Cadence Spectra HDL behavioral modeling language to model analog functions.

It is possible to use a hybrid approach, simulating some parts of the system with Spice models and other parts of the system with behavioral models. For example, we used behavioral models to simulate the main functions of an ATE instrument. We used Spice models to simulate the behavior of the device under test (DUT) board. This hybrid approach allowed us to keep simulation time down, but it still allowed us to obtain useful results.

Test schematics show instrument connections Next, we used Dantes from IMS, a graphical test-design environment, to create schematics that show how the DUT will connect to the tester instruments for each test in a test program. Figure 3 shows an example of a test schematic. After all the test schematics have been developed, Dantes checks to make sure that the test engineer does not use instruments not found in the tester. It can do this because it has access to a database containing a list of the instruments found in specific testers. This eliminates the possibility of trying to use an instrument not present in a tester. Under our old test-development method, chances were that we would not have found this problem until the debug phase, which was rather late in the process.

Once the test schematics were captured, we were able to start test debug through Test Process Simulation. Dantes and IMAGE ExChange provided the integration that allowed the test program, through IMAGE ExChange, to send and receive events from the test schematics. The test program would then respond just as it would to actual measurements from a DUT.

Results The biggest advantage of test simulation is that it takes much of the dead time out of the schedule and allows the test engineer to begin debugging the test long before silicon is ready. Since there is no need to wait for silicon, test engineers can begin debugging the program as soon as the models of the part under test and the test fixture are ready and the test program is available. This will take test development out of the critical path of time-to-market.

By beginning test development earlier, the test engineer has time to develop a more effective test. We expect this to result in improved test completeness and quality.

Our test engineers will spend less time performing test debug with expensive ATE testers, and they will spend more time on production test--which generates revenue for the company.

Test Process Simulation allows a different set of eyes--the test engineer's--to take a different view of the design. This helps protect against subtle design flaws finding their way into silicon. Test Process Simulation also helps the test engineer gain a better understanding of the device early in the process. We expect a better understanding of the device to result in better, more complete test programs.

Next steps Now that our group has discovered the benefits of test process simulation, in the future we plan to evaluate additional virtual test capabilities. A key step will be to incorporate parasitic effects into the test schematics to represent real-world characteristics of fixture contactors and fixture-board layouts. We also plan to explore the benefits of using code-generation tools to generate the test program automatically.

As improvements in design tools and methodologies help companies compress the design segment of the product-development cycle, test engineering must continue to improve test methodologies. Test software tools that help implement test development concurrent with design are creating new opportunities for development-cycle reduction. To be competitive in the 21st century, we at National are convinced that tools such as Test Process Simulation must be a part of the answer.

References
Xia, Austin, and Khouzam, "Dynamic Test Emulation for EDA-Based Mixed-Signal Test Development Automation," Proceedings of the 1995 International Test Conference, 1995. IEEE, Piscataway, NJ pp. 761-770.

Nash Khouzam is the senior test development manager for the Linear Division of National Semiconductor Corp. (Santa Clara, CA).

To voice an opinion on this or any Integrated System Design article, please e-mail your message to michael@isdmag.com.

integrated system design  April 1997