test

Integrating Design and Test Using New Tools and Techniques TI integrates virtual test to reduce time to volume, helping the test engineers contribute more to the design team by finding more bugs. by Craig Force

At Texas Instruments' Mixed-Signal Logic Products, we've studied the challenges of mixed-signal test development for many years with an eye toward making it more concurrent with the device design process. Design and test integration reduces the overall burden of the IC development process by integrating methods, tools, and flows from both the design and test communities. It's an institution and a culture--a way of doing business.

Design and test integration can reduce product introduction cycle time, pare down the number of redesign and subsequent fabrication iterations, and facilitate concurrent development engineering. The result is really honest design model reuse as well as cross-pollination of valuable engineering resources. Perhaps more importantly, design and test integration isn't trivial to accomplish--nor is it a shrink-wrapped software package, a covert operation to make design or test engineers obsolete, nor something you can do on a lazy afternoon between meetings. It takes open minds, dedication, and rigorous up-front planning to evolve into fruitful practice.

Figure 1	New product introduction cycle
Traditional mixed-signal design and test program development occur in a rigid sequence. By employing test simulation, the test program development and design activities progress concurrently, allowing for increased awareness of testability during design and greater test coverage for first silicon.

To that end we've successfully implemented a design and test development process that flows from the discipline of top-down design methodology to test program development and debugging with new test simulation tools. Our pilot project revealed the effectiveness of test integration even under the demanding specifications of a mixed-signal environment. Though currently limited in scope, the new tools allowed us to verify the functionality of our mixed-signal combinational driver much more quickly--and with greater coverage--than with the traditional test methodology.

The old process

In the traditional test development process, the test engineer begins to develop a plan and subsequent test program for the new device as soon as the device specification becomes available. The engineer can take the test development only as far as the specification supplies useful information. Once she has exhausted the information, she puts the test development activity on hold until more detailed specification data or the actual silicon becomes available.

An analogous situation is a software developer creating an innovative, graphically intensive game. The developer is waiting for the purchasing department to procure a new video controller card and monitor before he can test his new code. How much code can he develop without testing it on the hardware before he approaches the point of diminishing returns? What happens when some of the routines central to the whole program are broken? If he has built the "onion" too large, and the core is rotten, he may spend more time peeling back layers of code than if he simply waited until the hardware was available before continuing program development.

Once silicon is available, the test development process spins up to full speed. Meanwhile, the customer pressures the design and product engineers to ship samples--it's not uncommon in the industry to see samples go out the door tested only to a rudimentary level. Sometime after the complete test program has been developed and the customer has qualified the new product, official release to production occurs. Only then can the IC manufacturer entertain thoughts of product revenue.

Figure 2	Integrated development flow
An integrated development flow that supports rigorous up-front planning and information sharing between development teams is essential. The development process relies on model and simulation data that ultimately ripple back into the device specification.

We've realized a more desirable product introduction cycle time (see Figure 1). Design and test integration methods and tools have facilitated not only concurrent design and test development but also direct feedback from the test development engineer to the design team regarding potential problems, omissions, and testability enhancements. Because the test development activity begins earlier in the product life cycle, the test code available at the delivery of first silicon is more comprehensive and less likely to contain errors that cascade into interdependent test functions. The test engineer also enjoys greater confidence in the test program and can focus on troubleshooting the test hardware and device under test itself. The time saved grants the IC manufacturer shorter time to revenue for the targeted device.

Traditional design and test process flows are highly serialized and serve different ends. The flows aren't dynamic enough to support design and test integration methodology, so we constructed a new process flow that accommodates top-down design methods and test simulation tools (see Figure 2).

A new flow

The device specification continues to be the global reference point for the entire process, aggregating all modifications made to the design by any of the individual teams. Since the device spec is also the source of all downward-flowing information, we must update the spec throughout the development process.

Simulation and model planning is critical to prosperous full-chip simulations and test program development using test simulation. Carefully considered simulation and modeling planning can mean the difference between first-pass silicon success and first silicon that is dead on arrival. The testing team must ensure that the modeling effort doesn't fragment into "design intent" versus "test intent" model sets--the latter developed solely for test development purposes but not reflecting the actual design functionality. Modeling guidelines can assist in keeping potential deviations to a minimum.

The function of test program development has changed as well. Given that DUT models are essential to test simulation, concurrent design and test engineering requires delivery of those models. Once the models are available, the test engineer is ready to begin her own circuit simulations, run directly from the test program under development. The test engineer is now in a position to analyze the simulated test results and bring questions and concerns to the design and modeling teams. The intention isn't to characterize the DUT models, but to verify the functionality of the test program while finding idiosyncrasies that may come between the device spec and the DUT models. Obviously, the earlier test development can begin, the more potential issues may be uncovered. The design team must therefore develop and deliver models to the test team as soon as possible.

Tools of the trade

Test simulation connects a tester simulator with a circuit or a behavioral design simulator, or both, passing simulation stimulus and response bidirectionally to both the design and test CAE tools. By simulating an entire mixed-signal test set for a given DUT, the technique allows the test development activity to begin before first silicon is available.

Figure 3	Simulation tool block diagram
The SaberVX tool set represents CAE tool integration on a large scale. Teradyne provides the ATE tester simulator software, tester instrumentation models, and the library functions that are compiled into the Verilog executable. Analogy supplies the Saber simulator and associated backplane connection to the Verilog simulator. All of the tools run concurrently on the host workstation.

A mixed-signal test simulation tool must provide three features:

• a circuit simulation of the targeted mixed-signal tester instrumentation, interface hardware, and DUT
• control over the simulation activity by executing the test program in the ATE tester's native development environment
• the ability to access and analyze simulation results with both the ATE tester tools and design development tools, individually or simultaneously

Test simulation promises to touch many aspects of the IC development process. However, a number of common misconceptions surround the application of test simulation at the present time. Test simulation currently addresses neither automated test pattern generation of any kind nor the Standard Test Interface Language (STIL). It's not a mature technology, nor is it just a matter of buying a license or two and away you go.

We recognized that in order for a test simulation tool to effectively serve a test development engineer, it must function as much like the actual tester hardware as possible. Such an approach minimizes the costly requirement for test engineers to be trained intensively to use design environment EDA tools. It also allows the test engineer to concentrate on developing test programs with familiar ATE tester development and debugging. Of course, the design environment tools should always be available for those who wish to increase their development and debugging tool set and skills. TI's desire for a tester-centered simulation approach led it to a close relationship with Teradyne, Inc. in Boston during the specification and development of Teradyne's new VX Test Simulation tool set (see Figure 3). As the first customers of the tools, we actively participated in the new product definition. Specifically, we used SaberVX, the version of the tool that runs in conjunction with the Saber simulator from Beaverton, Ore.­based Analogy, Inc. The Saber simulator forms an integral part of the top-down design methodology.

Teradyne's Image Exchange feature augments the standard Image tester development environment to allow for full design and test simulations sometimes referred to as "closed loop." Image Exchange passes a simulation stimulus and response across to the Verilog programming interface language. The PLI, which contains Teradyne-proprietary functions, communicates to the Saber simulator across Analogy's Veri-Sab cosimulation backplane. Circuit simulation data relevant to the test program are dynamically back-annotated into the corresponding test program variables. That information is also available to the test debugging tools. However complex the process appears, it's essentially invisible to the test engineer during test program execution. Again, a familiar development and debugging environment for the test engineer is paramount.

It's important to mention that the test program is essentially the task-master of the closed-loop simulation: Pausing at a trap or break point during test program execution results in a clutching effect in the Verilog-Saber simulation execution. The pause in simulation allows for immediate mode modifications to tester instrument parameters that are reflected in the current simulation run. Such a capability can prove extremely valuable when iteratively modifying select parameters within a test function to determine the cause of unexpected test results.

Clearly, many pieces had to be in place before we could actually begin to use the test simulation tools--indeed, software integration on a grand scale. A schematic of the complete test set, including the DUT and the Teradyne tester instrumentation, furnishes proof that such integration is possible (see Figure 4). With experience, a proficient test engineer can learn to employ the features of both the design and the test tools to her advantage during debugging sessions.

Putting simulation to the test

For our pilot project, we looked for a challenging mixed-signal device that included functionality that's typically difficult, if not impractical, to develop as part of a comprehensive test program prior to silicon. Our goal was to instantiate functional block models delivered from the modeling team directly into our test set schematics, subsequently using the effective DUT model and SaberVX test simulation tools to develop and debug complex test functions without the use of silicon.

Our search for an appropriate device led us to a new product under development for the hard-disk drive market. The design and modeling team was well into the design before our test simulation pilot project began, leaving us unable to influence the front-end planning--and adding another degree of reality to the pilot project. The device selected was a spindle and voice-coil motor combination driver. Internal functional blocks of the device include a serial register, several D/A converters of 8-, 10-, and 14-bit accuracy, a phase-locked loop and voltage-controlled oscillator, power-on/reset circuit, and a system monitor.

The design included several layers of hierarchy and contained multiple levels of model abstraction, from the transistor all the way to full behavioral representation. Top-down design allows for switching between levels of abstraction in any given instance. Whenever possible, we used the highest-abstracted model for test simulation, suppressing the time required for simulation.

Our pilot project employed two test engineers running separate test development processes. The assigned test engineer carried out the traditional process normal for a new product. The other test engineer used the new test simulation tools to develop a test program for the same device. The two exchanged information, since we didn't intend to promote a competition between them. Considering that the tool set was still in development, we couldn't place our pilot activity in the critical path of the traditional test development process.

The traditional engineer used a program largely extracted from a previous-generation product. As is typical with many mixed-signal test programs, much of the code is pieced together from other test programs and functions developed for previous projects. The engineer assigned to use the test simulation tools aggressively developed his own program, which was architecturally very different from the traditional one. The structural differences that evolved between the two programs precluded us from merging them into one cohesive test program. We decided at that point to continue separate development tracks, but to periodically run the traditional test program through SaberVX for added insurance.

After reviewing the device specification, we determined that the highest test risk would appear in the 10- and 14-bit DACs. Bearing in mind that the design was well under way, we needed to minimize any added burden on the modeling team that might have kept them from hitting the projected completion date. Thus we assigned a modeling and simulation expert from the EDA support organization to take delivery of the models and make modifications, if necessary, for use with test simulation. The test simulation pilot team decided that we would target the 10- and 14-bit DAC blocks exclusively and accept any other access to functional block models as extra credit. Design engineers are accustomed to full internal controllability of functional blocks; test engineers, in contrast, can use only external pins to control and observe internal device functions. Even though those details may seem obvious and immaterial, they make a great deal of difference when prioritizing model development and delivery to the test team.

Error correction

We took delivery of the serial register model first. Running the existing test programs against the serial register with SaberVX, we found many device specification errors, one design flaw, and one design omission. Not surprisingly, the design team stood up and took note of our ability to identify those problems before tape-out.

We also found a few problems with the traditional test engineer's program after running it through SaberVX. The code developed for the serial register identified four errors in total. Three of the errors, though subtle, could have collectively consumed one entire tester time slot. The fourth error was much more dramatic. Frequently a device requires some amount of digital preconditioning during a test setup; the resulting digital pattern repeats many times throughout the course of the test program. Test simulation identified a problem with the method by which the digital pattern was being sourced to the serial register. The error rippled through a very large number of patterns, which had to be corrected. Moreover, the serial register controls many internal functional blocks of the device; without functional serial register code, we couldn't access or observe internal blocks. The intervention saved at least one tester time slot, if not more. Amazingly, we found all of the preceding errors after just one staff week of SaberVX simulations on the serial register model and test program alone.

Figure 4	Dual displays
The tool displays simulated digital drive and expected data from both the tester and the DUT as well as the analog waveform produced by the tester's arbitrary waveform generator. For the purpose of demonstration, both the Image tester development tools (left) and Analogy's Saberscope waveform tool (right) display the simulated signals.

Once we received the DAC models (by now the design was complete and being fabricated), we began to develop and debug the DAC test code. The tester wave tool presents an output capture collected in an array by the test code. The array data are ready for postprocessing. One of our most senior test engineers developed the DAC test code and was confident that it was without flaw. We instead found many bugs that would have kept the code from functioning once on the tester with the real silicon.

Figure 5	Beautiful curves
The ultimate success of test simulation depends on how closely the simulated test set represents the physical equipment. Here, the simulations produced an impressive correlation of phase and amplitude between the simulated and physical digitized DAC output waveforms of the DUT.

Back to reality

The traditional test engineer had already debugged the ATE tester device interface board when he invited us to the test floor to investigate troubles he experienced with the DACs. At this point, we had developed 100 percent of our test program in a simulated environment, never loading it to a physical ATE tester. Needless to say, our pulses raced now that we had arrived at the day of reckoning. Because we developed code for only the serial register and two DACs, we spent a brief time ensuring that the power-up requirements of the device were satisfied.

Finally, we ran to a trap point in the 14-bit DAC test function, expecting to see a continuous digitized sine wave on the DAC output. To our displeasure, the DAC was producing a segmented waveform unfamiliar to any of us. After looking at the device spec and scratching our heads for a few minutes, it occurred to us: This DAC design included a test mode set by 2 bits in the serial register. Although we programmed the register to disable the test mode, the device specification was in error and had the bits reversed. (Later we discovered why we hadn't caught the error during simulations: The test mode description didn't appear in the device specification during model development, so the DAC model didn't include it either.) We made a 2-bit swap in the test program and the DAC promptly presented an impressive sine wave. The team had verified the functionality of the 14-bit DAC in just one hour on the ATE tester! But we were hungry for more, so we proceeded to verify the 10-bit DAC. In less than two hours on the ATE tester, we had a fully functional test suite--including signal-to-noise ratio, total harmonic distortion, integral nonlinearity, and differential nonlinearity tests--running for both DACs.

By the end of our three-hour tester time slot, we had already begun investigating noise on the output of a defective device. Those that had gathered on the test floor agreed that this was indeed an historic occasion. After our brush with reality, I compared our simulated results with those collected on the ATE tester. What I found was an almost surprisingly close correlation between simulated and real test results (see Figure 5). Our integration of virtual test turned out very real indeed.

The author wishes to thank Jim Holmes and Mark Burns of Texas Instruments' Mixed-Signal Products and Tom Austin of Teradyne for their contributions toward the development and testing of the SaberVX tool set.

Craig Force is the manager of design and test technology in the Mixed-Signal and Logic Products division of Texas Instruments, Inc. in Dallas. After 10 years of mixed-signal test engineering, in 1995 he began evaluating mixed-signal test simulation software. He is currently the project manager and a technical contributor to the test simulation development activity within TI.

To voice an opinion on this or any Integrated System Design article, please email your message to miker@isdmag.com.

integrated system design  February 1999