Create high-quality program for at-speed test

At-speed testing has been improved by a number of new capabilities, including the use of on-chip-generated functional clocks during test mode.

Many of today's designs operate at very high frequencies and contain a number of clocks. On-chip PLLs are a common way to create internal clocks. Often, multipliers, dividers and other clock control circuitry accompany the PLLs. It doesn't require much additional logic to take advantage of these functional clocks for test purposes.

Most companies use static timing analysis (STA) to check functional timing before a design moves to the layout phase. As part of the STA process, the designer specifies the design's timing constraints and timing exceptions. The output of the process is a Synopsys Design Constraints file that contains the timing information needed by the other tools in the process.

This article offers some do's and don'ts for creating a high-quality program for the at-speed test.

Do

? Use on-chip functional clocks for test purposes to achieve more-accurate results than with off-chip clocks. Make sure your automatic test program generation (ATPG) tool can incorporate the on-chip clocks and clocking logic for at-speed test patterns.

? Add transition fault model test patterns to the test set if your device's manufactured features are 130nm or smaller. The model checks for timing defects by looking for slow-to-rise or slow-to-fall transitions on every internal node.

? Use the path delay fault model for testing critical paths or for an overall device timing characterization check. Some companies also use the path delay fault model for speed binning.

? Use static timing analysis to define and specify clocks and timing relationships so setup and hold times can be checked. Slack times for paths are also calculated, revealing the most-critical paths. The paths are then sent to the ATPG tool to create path delay patterns. The timing exception paths are also specified.

? Use an ATPG tool that can automatically handle timing exceptions during pattern generation.

A sample of five industry designs using a traditional method for handling exception paths is compared with a new approach of reading in the SDC file and only adding Xs where absolutely needed.

Don't

? Spend more on sophisticated ATE for supporting high-speed clocks if those functional clocks are already available on the device. Some pin I/O pads can't handle the fast external-clock speeds anyway.

? Rely on the stuck-at fault model for designs manufactured at 130nm and smaller. As geometries shrink, defects become increasingly timing-related. Many of the problems deal with creating feature sizes and shapes on the device that are smaller than the lithography wavelength used to fabricate them.

? Create at-speed test patterns without accounting for false and multicycle paths. If they are not accounted for, the ATPG tool could create test patterns with expected values that the device cannot create, leading to simulation mismatches of the test patterns and the possibility of failing good devices on the tester.

? Just constrain timing exception path endpoints with Xs during the ATPG process. This old methodology leads to lower test coverage and more Xs in the test pattern set. It masks observation points that could be used for other at-speed test paths, and thus leaves parts of the chip untested.

- Bruce Swanson
Technical Marketing Engineer, DFT Division
Mentor Graphics Corp.