Simplifying The Path From Design To Test

By Richard Fanning and John Rowe

Getting an integrated circuit (IC) from design to test is an arduous process that encompasses a number of steps, including:

• Design for Test (DFT): processes that ensure the chip is designed in such a way that it can be tested
• Development: the development of automated test programs (ATPs)
• Bench: evaluating the device at the bench to ensure the design is correct and meets the required specifications
• Bring up: moving the developed tests to the automated test equipment (ATE)
• Debug: debugging the tests on the ATE
• Characterization: determining the production variance; and fine-tuning performance, levels, timing, etc.
• Production release: moving the ATPs to the full production environment for volume test

This is an iterative process and can take months, so every step should be evaluated to determine if there are efficiency gains that can be realized throughout the process. Small improvements in any step can impact other steps and drastically reduce overall cycle time.

The long and arduous bring up and debug process

One area of significant inefficiency is the time it takes to move test programs from development to production, and specifically the debug process.

Design and bench engineers use one set of tools to create test sequences, which talk at a higher level of abstraction than the tests used by the test engineer. The test engineer, while working with the ATE, is typically talking at a much lower level, in levels and timing, and their vector is ones and zeros so there is a language gap between the tools used by the test engineer and those used by the design engineer that complicates debugging.

Let’s look at the process as it exists today.

Test program development takes time, a lot of time

At the highest level, design and bench engineers are using tools that can speak to the device in ways that are typically not available on an ATE. There is a gap between the language that the tools use, the device’s native environment, and the formats used on an ATE. Let us look at a specific example.

In a typical pattern flow, a simulator outputs a STIL or WGL file, for example, that gets converted to patterns by a pattern converter. These patterns are then loaded into the tester so they can be run on the ATE testing a device (the device is known as the device under test or DUT).

If an issue is encountered, the ATE only provides a pass/fail result, without any information about why it’s happening. At this point a test engineer must capture large amounts of data from the data log and pass that information over to the design or bench engineer, who is now receiving data that is in a format they are not familiar with. The data must then be converted into results that they understand so they can reproduce the issue on their simulation.

Once the issue has been identified, the design engineer can modify the code and generate a new set of inputs for the test engineer, which then must be translated back into flat patterns so the tests can be run on the ATE again to see if the issue has been resolved. Each of these conversions back and forth takes time and has the potential to introduce further issues, even regression.

Additionally, design and test engineers are not typically working at the same time, creating lag time between responses, and adding delays to an already time-consuming process. It can be weeks, or even months, to get the right set of tests.

So how do we shorten the debug time? By enabling test engineers to talk at a higher level of abstraction so test engineers and design engineers are speaking the same language.

Simplifying the process

To facilitate this streamlined flow of information, Teradyne has created PortBridge, a tool that enables design and bench engineers to communicate directly with the ATE to debug and enables test engineers to understand and diagnose failures in the flat patterns.

The diagram above shows a typical flow using PortBridge and a Serial Vector Format (SVF) file as an example. An SVF file is an industry-standard way of representing JTAG test patterns in ASCII (text) files.

The appeal of an SVF file is that it is a simplified pattern file that includes comments. Test engineers and design engineers want to work in registers, not flat patterns, where 200 commands could become 1000s and 1000s of lines of flat patterns. SVF files provide a simplified flat pattern file where comments are inline so when a failure occurs, it is easy to understand what those lines of code represent via the comments.

With PortBridge, the SVF file output by the simulator can be executed directly on the ATE, eliminating the need for ATPG. Failures can be understood and diagnosed via those inline comments and debug can occur directly on the ATE. This removes the step of translating the flat patterns to a format the design engineer can understand so they can debug, then translating the file back to flat patterns to run on the ATE. The debug tool allows setting traps and seeing real-time results along with all standard features expected in a full-feature debugger.

If a problem with the device is encountered, PortBridge enables direct communication between the ATE and EDA tools or bench scripts. Changes made on the tester are reflected in real-time, and any connected tools can see the state of the device remotely. This allows design and bench engineers to use the tools they are most familiar with but collaborate with test engineers to debug DUTs directly on the ATE. This process can save a significant amount of time compared to modifying and re-converting updated STIL or WGL files.

Conclusion

Moving from test design to production is a time-consuming process, with many steps that can introduce errors. Reducing complexity by programming and debugging at a higher level of abstraction means less translation issues and delays in communication between design, DFT, and test engineering teams. With PortBridge, debug time is reduced from months to days with a platform- and software-optimized solution.

John Rowe has held the role of Factory Applications Engineer at Teradyne for more than 20 years, where he focuses on PortBridge Software and Design/Bench/ATE integration. Prior to Teradyne Factory Applications, Rowe worked as a Field Applications Engineer in Texas.