Powerful Software Tools and Methods to Accelerate Test Program Development A Test Systems Strategies, Inc. (TSSI) White Paper Abstract Test costs have now risen to as much as 50 percent of the total manufacturing cost for many of today s most advanced ICs and system-on-chip (SoC) devices. A major component of total test cost is the time and resources required for test program development. While test development tools currently exist for translating a device s functional events and scan patterns into test programs for target ATE, today s growing device complexity and new manufacturing requirements have presented new challenges. For example, identification and specification of critical timing parameters that require conversion into cycle-based ATE formats have become an increasing cost factor. This can also significantly impact test accuracy. Only a few years ago, timing specifications from microprocessor and IP cores, multiple bus types, and other device components could often be established through published timing specifications and by a manageable, iterative process between design and test engineering. Automatic test pattern generation (ATPG) tools in the structural testing arena deal with simple timing, and hence, are able to generate cycle-based timing, but today s complex SoCs may consist of over 60 IP cores, while scan chains and scan depth have dramatically increased with Moore s law. In addition, as device performance grew, the timing impact from logic simulators increasingly needed to be factored into test program translation. Further complicating test program development is the need for compatibility with multiple ATE platforms to accommodate global manufacturing strategies. Next-generation design-to-test tools have to address these and other factors to help reduce the growing cost-of-test. Tools must support standard industry test languages, support both functional events and scan patterns, as well as validate outputs across multiple ATE platforms. Automating the timing discovery process and correction for simulation biases are also required. This paper will provide an overview of the state of automated test program generation and discuss the latest tools and techniques that are available to help speed complex devices to market. The paper will also identify the current areas where continued work is required. --o-- Time has changed. One thing is constant: Consumers are more and more demanding on product capabilities, quality, performance, and especially, competitive pricing. Packing more features into a shrinking chip geometry requires innovative technology and manufacturing process that are, not only enabling, but also cost effective. Testing these new devices, therefore, must also require breakthrough test tools and techniques that could anticipate the exponentially increasing functionality of a chip but lessoning accessibility to its embedded cores. Traditional testing techniques are becoming too timing consuming, costly, or even impossible to achieve adequate coverage. Today s advanced ICs and system-on-chip (SoC) devices are experiencing test costs at as much as 50 percent of total manufacturing cost. Many research and development effort are underway to address the cost containment. One major component of total test cost is the time and resources required for test program development. This paper describes the advancement in test program development acceleration with new test tools and methodologies.
Design-to-Test is Often Perceived as a Straight-Forward Process For many years, devices are tested on automated test equipment (ATE) with functional pattern sets. These pattern sets are either hand generated, or translated from functional simulation log files. De-Facto standards have been established in processes as well as test languages to transform free-form simulation print-on-change events into timing and pattern sets used by the highly synchronized world of cycle-based ATE systems, a process known as cyclization. Plus, ATE specific programming syntax and rules must be conformed in order to produce the same waveform that reflects the behavior of the device under test (DUT). The ATE program assigns ATE pins, formats, voltage, timing, pattern, and other tester resources to fully exercise the DUT for functional test coverage. This process is well understood and can be performed by many point tools, scripts, and low-cost software packages. Multiple ATE Re-targeting Consideration The cyclization process becomes more complicated when test teams needed to target a design on more than one ATE platforms because some testers are more suitable for testing a particular SoC device than the other. This can due to several major reasons: tester capabilities, cost, and in the old good days, availability. Test development tools now need to provide selection flexibility by having robust ATE re-targeting capability. Whether the test department is a single-person organization, is outsourced, or comprises teams of specialists and owns multiple testers, it is crucial that the time and money invested in the test program development should not be duplicated due to ATE selection because the cyclization step, when done write, should not be tester dependent, and need not be repeated. ATE re-targeting is now a very simple vector translation process. Various EDA formats Support On the other hand, the simulation source could be in various formats, especially in an SoC scenario where multiple cores could have been produced by Cadence NC-Sim, ModelSim, Synopsys VCD, Mentor Fastscan, Synopsys Tetramax, TI-TDL, Mentor Quicksim, and by many other EDA tools. Design-to-test process should start with a normalization step before cyclizing, thereby, modularizing language parsing from the cyclization step, which no longer depends on simulator formats. Multi-Cored SoCs Complicate Design-to-Test Processes Optimize Device Timing Across Multiple Cores Intellectual Property (IP) cores can be implemented with different test strategies. Some come with test patterns. But most come with multiple functional simulation outputs that require cyclization optimized for ATE test resource and production test time because multi-cored SoC devices can easily approach or exceed the ATE physical limitation. Optimization requires timing accumulation among hundreds of functional simulations for one core, and among hundreds from other cores of the same SoC. Manual processing is no longer feasible to construct quality timing. Pattern Compression to Fit ATE Pattern Memory Recent device patterns are increasing in sizes due to two factors: patterns from multiple cores as mentioned above; and BIST patterns that are approaching gigabytes in size but mostly contain idling cycles waiting for the embedded circuitry to finish its operations. Two types of pattern compressions are needed in data transfer/storage of these large files and in reducing pattern processing time.
Most tools are recently enhanced with standard file compression algorithm such as Gnu Zip or WinZip. Large BIST or ATPG output files can be compressed by one of these tools before transfer to test department. Test tools will then need to be able to read these compressed files for design-to-test analysis and ATE outputs. The second type of compression is the traditionally known as repeats, loops, and subroutines pattern compression techniques implemented by the ATE vendors themselves. Repeat compression is simply a pattern row with ATE specific micro-code to indicates the number of repetition the tester must apply the pattern row to the DUT. This is often used to compress the idling cycles in the BIST patterns. Similarly, Loop compression repeats a number of pattern rows a number of times. Finally, Subroutine compression is a technique ATE vendors used to store a block of patterns that performs a particular functionality is a separate ATE memory, which interleaves with the tester s standard memory each time the subroutine is invoked via the ATE specific subroutine micro-code. These pattern compression techniques should be supported automatically in design-totest tools for processing large volume of data for most SoC applications in the market today. Handle Test Strategies from High-Speed and Mixed-Signal Applications Most telecommunication and networking devices have high-speed pins exceeding 2GHz range that few ATE models reach. While logic Built-in-self-test (BIST) technology alleviates some of the at-speed demands, analog BIST technology allows digital testers to test analog components such as Phase-Lock-Loops (PLL) and Converters (ADCs and DACs). This helps contain the cost of expensive high performance mixed-signal ATEs, but test development process must now have tools to integrate patterns from these logic and analog BIST simulations, which often produce large volume of data and cause issues associated with large physical file sizes exceeding 32-bit OS file system boundary (2 Gigabytes) and bogs down processing time to an excruciating pace. So with the quest for the latest methodology in test development to keep pace with the demanding designs and consumer ICs, new design-to-test automation software tools must address all of the needs mentioned above. New techniques for design-to-test process acceleration and quality Developing tests for a single functional core is simple and straightforward. A clock is a clock is a clock. Tester has a format just for that. The simple translation process, therefore, has been automated in various forms, whenever and by whomever capable in the test department. Many sharewares are even available for downloads via the web. Applications with simple timing can be translated on a cycle-by-cycle basis without the possibility of exceeding tester timing resource, and optimization is not necessary. Figure 1 shows how mis-aligned transactions that are insignificant in logic simulation can consume ATE precious timeset resource unnecessarily.
Figure 1. Misaligned Transitions Consumes Precious ATE TimeSets Therefore, the key is to first, transform a multi-functional core problem into a single functional core problem. This technique is an advancement based on the need to break up the design-to-test development process into two sequential steps: cyclization and ATE targeting. New Cyclization Techniques Automate Timing Entry and Accumulate Timing across Multiple Cores Cyclization often starts by post-processing a simulation log file. The main objective is to get the device timing and pattern that are ready for ATE consumption. Test engineers usually face with three situations: 1) The timing is known; 2) The timing is unknown; or 3) The timing is partially known. When the timing is known, the test engineer will need to specify the timing so that the cyclization tool can use to find, or match, the timing behavior in the simulation file, and extract the pattern information required by the tester. When the timing is unknown, the test engineer must either obtain the timing from the designer, guess the timing, or rely on the cyclization tool to discover the timing. Advanced cyclization techniques will automate the timing process for all three situations mentioned above, and also, able to accumulate timing across multiple cores so that the final timing set presenting to the ATE targeting step is the single-functional-core problem to solve. Auto Timing Discovery Test engineers should not have to re-enter device timing that is already available in the designers simulation output files. o For even a typical 200-400 pin device, it is time-consuming and error prone. Recent techniques auto discover timing from simulation files intuitively presenting the timing selection to the test engineers for final test timing generation. All edge transitions with proximities within a user specified tolerance will be automatically combined; thereby, optimizing timeset usage. All primitive waveforms are combined into more complex representative waveforms; thereby, optimizing format usage.
This is possible when an analytical process is performed on the entire simulation file. Each waveform behavior of the device within a cycle is stored into a hash table for fast access and a reduction algorithm is applied with respect to a target ATE s shape and timing rules, if an ATE is specified by the user. Partial Timing Discovery When device datasheet timing is available for critical signals such as those described in the simple Read Cycle (Figure 1), users can make a replica of the datasheet timing via intuitive timing editor or spreadsheet timing expressions. The tool will read the timing diagram, fill in the rest of the device signal behavior referencing the waveform hash table, and convert all waveforms to ATE programming statements that would reproduce the device behavior. The advantages of the Automatic and Partial Timing Discovery capabilities are: - Not having to re-capture timing which is already there, and thereby, avoid duplicate work and potential human errors - Users can visualize any simulation artifacts that could violates test rules - Users can visualize any variation between simulation outputs and true device timing specification - Users can select the correct timing, or refine the timing to spec in a minimal effort for ATE targeting - If timing specification is desired, users only need to specify the important device signals often find in the design datasheet, and the test development tool will fill in the rest by discovery the unspecified signal timing from the input simulation file - Shape Promotion is possible when all compatible waveform shapes in the hash table are combined whenever possible to optimize ATE resource usage, thereby, getting the best test time and fits bigger tests onto a physically resource limited ATE. - Progressive Timing Refinement. When working with multiple simulation output files of the same device, the cyclization step incrementally accumulates timing so that common timing are reused across functional patterns, or pattern bursts. Simulation groups with drifting edges can be automated aligned as long as they are within a user-specified tolerance. ATE Targeting and Re-targeting As mentioned above, when the test development process is broken up to two steps: the cyclization step to transform simulation events into ATE neutral cycle-based data with multiple-core timing correlated, the second step is a simple vector translation process. ATE targeting is now a simple waveform to tester format mapping. ATE re-targeting no longer needs to start from the simulation event file, but at the cycled-based stage. Bridging BIST test strategies with ATE
Most BIST techniques seen going to test development today require functional simulations that often result in huge simulation cycles waiting for BIST circuitry to complete its operations. File compression and ATE pattern compression techniques are seen used in recent design-to-test tools. Furthermore, software memory management techniques are used in the tools to work around 32-bit physical file size limitation imposed by the operation system that the software runs on. What seems to work best are the BIST designs that utilize IEEE 1149.1 standard interface. Through this interface, test development software can support any kinds of BISTs: logic, memory, and analog. Plus, this enables external access to BIST circuitry in an SoC via as little as 5 ATE digital pins (Figure 2). Figure 2. Test patterns generated from simulation of BIST tests via IEEE 1149.1 Interface Future Work Validation must be in an integral part of this flow. Otherwise, inevitable designto-test defects will surface during expensive ATE testing, or worse yet, in the field. Feedback loop Failure analysis becomes simple when design-to-test tools record relevant design information as it converts design data to test. Mixed-signal Most M/S patterns are generated by hand. The challenge remains in an automation of instrument initialization, setup, and synchronization with digital subsystems. # # # Copyright 1979-2006. Test Systems Strategies, Inc. All rights reserved.