Using Timing Constraints For Generating At-Speed Test Patterns

Handling timing exception paths in ATPG tools while creating at-speed patterns has always been a tough and tricky task.

It is well understood that at-speed testing is a requirement for modern electronic designs. The high clock speeds and small geometry sizes found in today�s integrated circuits have led to an increase of speed-related defects.

Fortunately, effective scan-based at-speed test techniques are available in leading ATPG tools.1 The most common at-speed tests to check for manufacturing defects and process variations include test patterns created for the transition and path-delay fault models.

The basic methodologies for creating at-speed test patterns are covered in numerous sources.2 While creating at-speed test patterns, it is important to account for timing exceptions and constraints such as false and multicycle paths. If these paths are not handled correctly during scan-based at-speed test pattern generation, it can lead to lower test quality and failing good chips on the tester, which reduce product yield.

Terminology
Performing static timing analysis (STA) is a common practice in today�s design flows to ensure that a circuit design is free of timing violations.3 The term false path is commonly used by STA users to verify timing performance of a design. A false path in a circuit is never activated because of the circuit functionality and delay values of the circuit components.4 However, a scan-in operation during scan-based at-speed test can load in nonfunctional states, which may sensitize these paths.

Before running timing analysis, the STA user loads the design into the tool, specifies the clocks and timing constraints, and adds the timing exceptions. These timing exceptions are used to override the default single-cycle clock constraints and can be applied to any timing path.

In PrimeTime, a widely used STA tool from Synopsys, the command to specify false-path timing exceptions is set_false_path. It has a number of command options including -from, -to, and -through. These options are followed by one or more design locations such as input and output ports or internal pin names.

By specifying false paths, the user is defining paths that the STA tool should not evaluate for timing. This is a key step to enable the design to meet timing closure while doing logic synthesis and physical place and route.

Here are a few examples of using the set_false_path command to specify false path timing exceptions.
> set_false_path -from CLK1 -to U5/D
> set_false_path -from CLK1 -to CLK2
> set_false_path -through G5/out

These examples can be used inside a tool command language (Tcl) script, and the resulting Tcl script can serve as an input to various design and test tools including synthesis, timing analysis, place and route, and test generation. The arguments of the set_false_path command are commonly specified with the design-object access functions:
1. get_pins for accessing an instance pin
2. get_clocks for accessing a clock
3. get_ports for accessing a port
4. get_nets for accessing a net

The following example shows the usage of design object access functions get_clocks and get_pins with the set_false_path command:
> set_false_path -from [get_clocks {CLK1}] -to [get_pins {U5/D}]

An alternate command to specify false-path timing exceptions is set_disable_timing. It can be used to improve STA runtime performance.

Multicycle paths are similar to false paths because they need to be defined as timing exceptions in the STA tool. A path is considered to be multicycle if the combined time delay through the path is greater than the single cycle clock period.

Figure 1 shows path P1 that starts at flip-flop U1, goes through gates G1, G3, G5, and G6, and ends at flip-flop U5. This path has a total propagation delay longer than the clock period for CLK1. To specify this timing exception in STA, use the set_multicycle_path command which has similar -from, -to, and –through
> set_multicycle_path -from U1 -to U5
switches. For this example, it would look like this:

Figure 1. Multicycle Path Example

Or to be more explicit in the definition of the multicycle path, the through gates could also be specified in the timing exception.

When specifying these timing exceptions, be specific and accurate. For example, Figure 2 illustrates the result when the following command is used:
> set_false_path -from U3

Figure 2. Effect Cone

This diagram shows that if only the -from or source node is specified, the effects of that definition propagate out through the design in an effect cone. This may be correct and intended, but if not, can lead to incorrect timing specifications and lower test coverage.

Once the STA process is completed, the write_sdc command should be used to produce a file in the Synopsys Design Constraints (SDC) format. This is an industry-standard format used by many design tools, and the file contains all the timing constraint and exception information.

When creating at-speed or near at-speed test patterns in an ATPG tool, it is very important to provide the tool with this same timing exception information that was used by the STA tool. It doesn�t make sense to try to test paths at-speed if they are not designed to operate that way in the first place.

Failing to account for these timing exceptions while creating at-speed test patterns can lead to pattern simulation mismatches or incorrect fails when the patterns are run on the ATE with the silicon.

To get accurate results, the timing exception information should be entered into the ATPG tool before creating at-speed test patterns. With this information, the tool can do some analysis and determine the correct expected results for each test pattern. This is very important to produce accurate test coverage numbers and should eliminate simulation mismatches when the completed at-speed test patterns are replicated with timing in a functional simulator.

Traditional Methods
Most existing methods for handling timing exception paths in the ATPG tools while creating at-speed patterns have relied on the addition of some type of constraint or the application of pattern masks. The common approach was to analyze the paths so that appropriate cell constraints, such as forcing to an X value, could be specified for source and sink cell locations on the false and multicycle paths.5

This method is rudimentary and masks those locations for all test patterns, which lowers the test coverage and quality. By adding extra X values to the test pattern set, this method also has a negative effect on the test-compression techniques and results.

The New Method
To overcome the pessimism and other drawbacks of the existing methodologies, a patent-pending method was developed to handle false and multicycle paths more effectively during at-speed pattern generation.6 The new method removes the pessimism by considering complete path information along with the test patterns. It eliminates the tedious manual steps for generating cell constraints and pattern masks.

The correctness of the generated at-speed patterns is guaranteed, and these patterns will not fail on the tester. The automated methodology is composed of the following steps:

1. Entering the Timing Exception Paths
The timing exception paths are read into the ATPG tool from one or multiple SDC files. The false path information is extracted from the SDC commands set_false_path and set_disable_timing. The multicycle path information is extracted from the SDC command set_multicycle_path. The tool also automatically handles the SDC commands set_case_analysis, create_generated_clock, create_clock, and set_hierarchy_separator.

Alternatively, if an SDC file is not available for the design, the user can enter the timing path exceptions with the ATPG tool commands add false path and add multicycle path.

2. Marking the Path Cone
After reading in the timing exception paths and marking them inside the circuit, this information is used during at-speed pattern generation. Here the complete set of gates belonging to a timing exception path is identified. This involves multiple forward and backward traversals of the path cones defining the timing exception paths.

3. Checking Path Sensitization
The logic values at the start points of a timing exception path are examined. If an at-speed transition is found at a start point, the original logic value is stored, and logic value X, an unknown value, is injected.

The effects of the injected Xs are propagated forward through the gates that define the complete timing exception path by performing event-driven logic simulation. During the event-driven simulation, the original logic value at a gate is stored if logic value X is propagated through this gate.

At the end of the simulation, the end points of the timing exception path are examined, and the end points with logic value X are stored in a data structure called X-mask list. If all the end points have logic value X, the timing exception path is fully sensitized. If logic value X is found at a subset of the end points, the timing exception path is partially sensitized.

If none of the end points have logic value X, the timing exception path is not sensitized. Once the sensitization check is done, the original state of the circuit is restored.

4. Identifying the Unknown States
During the generation of each at-speed test pattern, the effects of the timing exception paths are considered. There are multiple time frames in a given at-speed test pattern. The unknown states due to sensitization of these timing exception paths are identified for each of these time frames.

As described in step 3, the sensitization checks of the timing exception paths are performed, and the X-mask list is populated for each time frame. After populating the X-mask list, the original circuit state is restored. The logic value X then is injected at the circuit nodes belonging to the X-mask list, and the effect of these unknown states is propagated forward by performing logic simulation.

5. Sustaining the Effect of Past Transitions
Sustaining the effect of past transitions at the input of the timing exception paths needs to be considered for each time frame in a given at-speed test pattern. Suppose the current time frame is t and the false path P1 had an at-speed transition at its input at a time frame less than t. Even though there is no current at-speed transition at the input of the false path P1, a sensitization check is performed for this path at the current time frame t.

This is done because the delay along a false path is unknown. If the sensitization condition of the false path P1 is satisfied, the affected end points are assigned the unknown logic value at the current time frame, and the effect of these unknown states is propagated forward by performing a conventional logic simulation. Slow events such as scan load/unload operations and slow clock events clear the past transitions for future consideration.

For multicycle paths with propagation delay d, any previous at-speed transitions at the inputs in time frames less than t and greater than (t – d) are considered for sensitization check. The sensitized multicycle paths are handled according to the same rules as explained for false paths.

These new methods can handle sensitization of timing exception paths due to glitches. Consider a timing exception path through an AND gate G. The gate G has output Z and inputs A and B. If the input A has a rising transition (0�1) and the input B a falling transition (1�0), then the output Z can have a potential glitch (0�1�0).

In this case, while checking path sensitization, the logic value X is injected at both inputs A and B, and the gate G is simulated. This will result in logic value X at the output Z, and the path will be inferred as sensitized due to potential glitches. Similarly, it can handle the situation when the input A has a falling transition (1�0) and the input B a rising transition (0�1).

Some Experimental Results
The new methodology for efficiently handling false and multicycle paths was used and extensively tested on a number of different size and style industry designs with good results. Table 1 shows a sample of these results.

Table 1. Test Case Results

There was improvement in test coverage by 1% to more than 16% compared to the old method. This is significant because any improvement in test coverage increases test quality and product yield.

Although there were a similar number of patterns in the new method compared to the old, the number of unknowns (Xs) was reduced in the test pattern set with the new method, sometimes dramatically. This allows for much better test compression.

Conclusions
At-speed scan-based ATPG patterns have become critically important to ensure high test quality of today�s nanometer designs. To get the best possible at-speed test patterns requires the inclusion of the effects of timing exception paths in the circuit. Finding and specifying these paths are common practices in the design flow as part of static timing analysis.

In the past, people creating ATPG scan patterns were limited to rudimentary means of handling these exception paths. This usually meant adding cell constraints to mask the start and end points of the paths during test pattern generation. This solution has some drawbacks, is overly pessimistic, and can lead to poor quality of test.

The technique described here is a better solution for handling timing exception paths while creating at-speed scan patterns. Test-case results based on many industry designs have shown some large improvements in test quality.

By using the information in the SDC file for the design, the ATPG tool can automatically analyze the paths and patterns and only mask capture locations where needed. This solution is easier to use, more accurate, and less pessimistic and provides the best possible quality of test. This new methodology uses the SDC file to bridge the gap between the design and test functions.

References
1. Lin, X., Press, R., Rajski, J., Reuter, P., Rinderknecht, T., Swanson, B., and Tamarapalli, N., �High-Frequency, At-Speed Scan Testing,� IEEE Design & Test of Computers, September-October 2003, pp. 17-25.
2. Tendolkar, N., Raina, R., Woltenberg, R., Lin, X., Swanson, B., and Aldrich, G., �Novel Techniques for Achieving High At-Speed Transition Fault Test Coverage for Motorola�s Microprocessors Based on PowerPC Instruction Set Architecture,� Proceedings IEEE VLSI Test Symposium, April-May 2002, pp. 3-8.
3. Zeng, J., Abadir, M., and Abraham, J., �False Timing Path Identification Using ATPG Techniques and Delay-Based Information,� Proceedings Design Automation Conference, June 2002, pp. 562-565.
4. Higuchi, H. and Matsunaga, Y., �Enhancing the Performance of Multi-Cycle Path Analysis in an Industrial Setting,� Proceedings Asia and South Pacific-DAC, January 2004, pp. 192-197.
5. Saxena, J., Butler, K., Gatt, J., Raghuraman, R., Kumar, S., Basu, S., Campbell, D., and Berech, J., �Scan-Based Transition Fault Testing�Implementation and Low-Cost Test Challenges,� Proceedings International Test Conference, October 2002, pp. 1120-1129.
6. Goswami, D., Tsai, K-H., Kassab, M., and Rajski, J., Generating Test Responses in Presence of Timing Exception Paths, U.S. Patent Application.

About the Authors
Bruce Swanson is a technical marketing engineer in the Design-for-Test Division at Mentor Graphics. He received an M.S. in applied information management from the University of Oregon and a B.S. in computer engineering from North Dakota State University. 503-685-4802, e-mail: [email protected]

Dhiraj Goswami is a research engineer developing design-for-test tools and solutions at Mentor Graphics. He earned an M.S. in electrical engineering from University of Southern California and a B.S. in electrical engineering from Indian Institute of Technology, Kanpur. Before joining Mentor in 2003, Mr. Goswami worked as a CAD engineer for Intel and Synopsys. 503-685-0706, e-mail: [email protected]

Mentor Graphics, 8005 SW Boeckman Rd., Wilsonville, OR 97070

October 2006

Comments

To join the conversation, and become an exclusive member of Electronic Design, create an account today!