The Path to Test
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.
PortBridge works with Teradyne’s UltraFLEXplus and UltraFLEX testers and provides:
- Protocol Libraries for common protocols devices use today, and ones needed in the future. Usable all the way to production.
- Remote Connect, built-in support to connect EDA tools and custom bench environments to the ATE remotely. Gets the right people looking at the problem, using the tools and environment they are familiar with.
- Design File Support, which enables the use of standard design formats, like SVF, or custom formats, to eliminate conversion steps that waste time and lose valuable information
- Host Debug Tools that deliver out-of-the-box, protocol-specific tools that expose the exact details needed while developing and debugging a test program
- Production Enablement, the same protocol libraries can be used from debug to production to help with correlation, reduce overall effort and provide failure analysis with optimal test time.
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 but PortBridge can streamline this process. 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. In future posts, we’ll look at real-world use cases to show how PortBridge is being used to minimize debug time and effort.
Contact us to learn about how you can utilize Teradyne’s PortBridge tool on your UltraFLEXplus or UltraFLEX tester to simplify the path from design to test.
Richard Fanning is a lead software engineer at Teradyne, leading the PortBridge software initiative. Prior to this role, he led the software development of the HexVS instrument board and the characterization API and GUI improvement project, and architected the Protocol Aware solution in IG-XL, in addition to working on numerous other instrument and software projects for the FLEX, UltraFLEX and UltraFLEXplus platforms. Richard has worked at Teradyne since graduating from Harvey Mudd College in 2000.
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, John worked as a Field Applications Engineer in Texas.