Facilitating At‐speed Test at the

Register Transfer Level

Dr. Ralph Marlett

Kiran Vittal

Atrenta Inc.

White Paper
Atrenta, Inc.
2077 Gateway Place
Suite 300
San Jose, California 95110
1‐866‐ATRENTA (1‐866‐287‐3682)
atrenta.com

Table of Contents

1 Introduction ............................................................................................................ 3

© Atrenta Inc, 2010, All rights reserved

 Facilitating At‐speed Test at RTL

2 Design-for-test at RTL ........................................................................................... 3

3 Problems with at-speed testing............................................................................ 3

4 Defect models and manufacturing test techniques............................................ 4

5 At-speed test methods .......................................................................................... 6

6 At-speed clocks ..................................................................................................... 8

7 Atrenta’s solution for at-speed test ..................................................................... 8

8 At-speed timing closure rules .............................................................................. 9

9 At-speed coverage vs. stuck-at coverage ......................................................... 12

10 At-speed coverage calculation overview........................................................... 14

11 Causes for low at-speed coverage..................................................................... 15

12 Summary............................................................................................................... 17

© Copyright Atrenta Inc., 2010 Page 2 of 17

 Facilitating At‐speed Test at RTL

1 INTRODUCTION

Production testing for complex chips usually involves multiple test methods. Scan‐based automatic
test pattern generation (ATPG) for the stuck‐at defect model has been the standard for many years,
but experience as well as a number of theoretical analyses have shown that the stuck‐at fault model
is incomplete. Many devices pass very high coverage stuck‐at tests and still fail to operate in system
mode.

Analysis of the defective chips often reveals that speed or timing problems are the culprits. At 90 nm
and smaller processes, the percentage of timing related defects is so high that static testing is no
longer considered sufficient. Functional tests have been used to check for at‐speed operation. But
generating functional at‐speed test patterns is difficult and running this volume of tests on the
automatic test equipment (ATE) is expensive. As an alternative, scan test has been adapted to detect
timing‐related defects. Like standard stuck‐at scan tests, high coverage at‐speed scan test vectors can
be automatically generated by ATPG tools. Manufacturing testing of deep submicron designs now
routinely includes “at‐speed” tests along with stuck‐at tests.

Little has been done so far to make front end designers aware of at‐speed test solutions at the
register transfer language (RTL) level of abstraction. This document is intended to present basic
concepts and issues for at‐speed testing, as well as demonstrate the at‐speed coverage estimation
and diagnosis capability built‐in to the SpyGlass®‐DFT DSM product for RTL designers and test
engineers.

2 DESIGN­FOR­TEST AT RTL

There has been an enormous push for design‐for‐test (DFT) at the register transfer level for the past
several years. RTL designers are now faced with requirements to comply with strict DFT guidelines
to meet ever‐tighter design schedules, even though the designer may not understand all the
complexities of defect models and testability techniques. SpyGlass‐DFT provides the platform and
ease of use to RTL designers to quickly identify and fix testability issues without having to become a
test expert.

Leading chip makers realize the importance of looking at the manufacturing test readiness of their
SoCs early in the design phase to prevent design iterations motivated by improved test coverage.
However, most of this effort has been focused on achieving high stuck‐at fault coverage for designs
with feature sizes of 130nm and above. As the industry moves towards deep submicron technologies
of 90nm and below, speed‐related defects are becoming common and gaining more attention.
Transition fault coverage and path delay fault coverage have become equally important and are an
integral part of any robust DFT strategy today.

3 PROBLEMS WITH AT­SPEED TESTING

The test clocks in traditional stuck‐at testing are designed to run on test equipment at frequencies
lower than the system speed. At‐speed testing requires test clocks to be generated at the system
speed and these clocks are often shared with functional clocks from a phase locked loop (PLL) clock

© Copyright Atrenta Inc., 2010 Page 3 of 17

 Facilitating At‐speed Test at RTL

source. Any additional test clocking circuitry affects functional clock skew and thus the timing
closure of the design. SpyGlass‐DFT DSM is designed to specifically address the problems associated
with timing closure due to at‐speed DFT.

At‐speed tests often result in lower than required fault coverage, even with full‐scan and high
(>99%) stuck‐at coverage. Identifying reasons for low at‐speed coverage at the ATPG stage is too late
to make changes to the design and affects schedules significantly. SpyGlass‐DFT DSM identifies
causes of low at‐speed coverage at RTL and helps achieve quick turnaround times for today’s
aggressive design schedules and time‐to‐market challenges.

4 DEFECT MODELS AND MANUFACTURING TEST TECHNIQUES

4.1 Stuck­at fault

A stuck‐at fault is a fault that holds a device pin at a fixed value (stuck at 0 or stuck at 1). If the pin is
a device output, then the pin and all device inputs connected to the net driven by that pin have the
stuck‐at value. If the pin is a device input, then that device is affected by the stuck‐at condition but
the net connected to that input pin is not stuck.

4.2 Stuck­at tests

When testing for a pin stuck at 0 or stuck at 1, it is generally sufficient for circuits designed with full
scan to apply a single test vector. This vector not only exercises the fault by driving the “faulty pin” to
the complement of the fault condition, but also sensitizes a path from the faulty pin to the data pin of
a scannable flip‐flop. Such vectors or tests are applied by a single scan vector. The test result is
captured by a single clock pulse as illustrated in Figure 1. This is effective because the fault condition
(a pin stuck at a particular value) does not depend on test application speed. Scan shifting and
response capturing is conducted at 10Mhz to 100Mhz which is within the capability of manufacturing
test equipment.

Figure 1: Stuck­at test

4.3 At­speed fault

An at‐speed fault is a fault that causes signal propagation delay. The industry defines both a slow‐to‐
rise and a slow‐to‐fall at‐speed fault.

© Copyright Atrenta Inc., 2010 Page 4 of 17

 Facilitating At‐speed Test at RTL

Figure 2 illustrates a 1 to 0 transition on the AND gate input that propagates through the OR to the
flip‐flop D‐pin. If the 0 value reaches the D‐pin sufficiently before the system clock then the test
passes.

Destination
Flop
0
1 1 ‐> 0
D Q
1 ‐> 0 1 ‐> 0
system
clock

Figure 2: At­speed fault example

4.3.1 Path delay at­speed fault

A path delay fault is a fault associated with a specific combinational path from the Q‐pin of one flip‐
flop to the D‐pin of a flip‐flop (possibly the same flip‐flop) where the two flip‐flops are in the same
test clock domain. Two faults are considered for each path:
• the slow to rise transition on the first node of the path
• the slow to fall transition on the first node of the path

Therefore, the number of possible path delay faults is twice the number of paths.

Since path delay faults are path‐specific (from a source point to a destination point) they are usually
defined by critical paths from a static timing analysis (STA) tool.

Figure 3: Path delay fault example

4.3.2 Transition at­speed fault

A transition fault is a fault associated with an input or an output pin on a specific instance of a device.
The AND gate in Figure 4, for example, has 3 pins and therefore has six transition faults.

Note that a test for a transition fault necessarily involves a test for some path fault and a test for a
path fault necessarily involves one or more transition faults.

© Copyright Atrenta Inc., 2010 Page 5 of 17

 Facilitating At‐speed Test at RTL

Figure 4: Example for transition faults

5 AT­SPEED TEST METHODS

There are two commonly used methods for applying at‐speed tests. In both cases, scan based designs
are assumed.

Unlike stuck‐at faults, at‐speed tests depend on timing and therefore two or more capture clocks are
required. The first clock initiates or launches a transition at the output of a flip‐flop. The second
clock, fired at system speed with respect to the first clock, is intended to capture the test result.

Two techniques are used to apply at‐speed tests.

5.1 Launch on last shift

Launch on last shift uses the scan chain to generate the launching transition. Launch occurs during
the last shift while loading the scan chain. Immediately following the last shift, the circuit is placed
into functional/capture mode and an at‐speed functional clock is pulsed.

Suppose that in the example of Figure 5, flip‐flops U1a, U1b, U1c, U2a, U2b and U3 are on the same
scan chain and stitched in this order.

In order to use the last shift method, the scan in state before the last scan shift must be as illustrated
in Figure 5. The last shift will cause U2a to change 0=> 1 (the launch event), U2b to remain at 0 and
U3 to go to 0. The scan enable is then changed to system mode and one capture clock is fired at high
speed with respect to the last shift clock. Note that careful timing is required for the scan enable in
order to use the “last shift” method which is one reason why this technique is difficult and not
commonly used.

Consider the 0=>1 test for top input to the OR gate. The last scan in must have U2a = 1 and U2b = 0
so that on the last shift U2b will transition 0=>1. In order for the off path input to the OR to be at a
non‐controlling value, U2a must be 0 which means that U2a is necessarily changing from 1=>0 as
U2b changes 0=>1. If there is no transition fault then U3 should continue to capture a 1.

© Copyright Atrenta Inc., 2010 Page 6 of 17

 Facilitating At‐speed Test at RTL

Figure 5: Design example for at­speed test methods

5.2 Launch at first capture

Launch at first capture is the most commonly used technique for transition fault testing. This uses the
waveform as shown in Figure 6. In this case, the first “capture pulse” starts (launches) a transition
and the second pulse captures the result in the scan FF U3.

Since all flip‐flops in the example in Figure 5 are scanned, they can be initialized to either 0 or 1
through scan shifting. The scan shift clock may be fired at slow speed but the two capture clocks are
fired at system speed. Launched transitions for the OR gate eventually arrive at the d‐input of U3. If
the desired transitions do not arrive at the capture FF (U2) then an incorrect data is captured. The
purpose of at‐speed testing is to verify whether or not correct data or corrupted due to transition
delays.

If a 0 => 1 transition is launched at flip‐flop U2a, then a 0 is scanned into U2a and a 1 is scanned into
both U1a and U1b so that the next state function for U2a is a 1. The first capture clock causes U2a to
change state from 0 to 1. A 0 can also be scanned into U1c so that the OR gate off‐axis input is set to a
non‐controlling value after the first capture clock. The second capture clock will store the value
produced by the OR gate into U3.

© Copyright Atrenta Inc., 2010 Page 7 of 17

 Facilitating At‐speed Test at RTL

Figure 6: Launch on first capture

6 AT­SPEED CLOCKS

At‐speed testing critically depends on the application of the capture clocks. If the two clocks
illustrated in the timing diagram shown in Figure 6 are too far apart, then the extra time allows slow
paths through the logic to pass. If the clocks occur too close together, then properly working paths
may fail. This issue influences which faults are candidates for at‐speed testing and how clocks are
generated.

6.1 At­speed clock generation

Typical designs use PLLs to generate the system and test clocks.

Figure 7 illustrates use of a PLL and special clock logic to generate the two system speed clocks that
are necessary for at speed testing.

ext. clk pll_clk

PLL clk clock
CLK domains
scan_clk MUX

scan_en MUX
contro
lle
scan_clk r
scan_en

pll_clk

clk
shift launch/capture shift
in/
Figure 7: PLL clock timing diagram for at­speed test in/
out out
© Copyright Atrenta Inc., 2010 Page 8 of 17
 Facilitating At‐speed Test at RTL

7 ATRENTA’S SOLUTION FOR AT­SPEED TEST

As discussed, the SpyGlass‐DFT DSM product introduces advanced timing closure analysis and RTL
testability improvement for deep submicron (DSM) defects associated with at‐speed testing. It
provides accurate RTL fault coverage estimation for transition delay testing, together with
diagnostics for low fault coverage, early in the design flow, to achieve high test quality with minimum
design iterations.

The overall flow for Atrenta’s complete RTL testability solution is shown in Figure 8.

Figure 8: Complete RTL analysis solution for stuck­at and at­speed testing

8 AT­SPEED TIMING CLOSURE RULES

© Copyright Atrenta Inc., 2010 Page 9 of 18

 Facilitating At‐speed Test at RTL

Here are some examples of at‐speed rules. These rules identify issues caused by clocks used in at‐
speed tests for timing closure as well as low coverage.

8.1 PLL clock rule

This rule verifies that the PLL reference clock can be controlled from root level ports. Compliance
with this rule is required to simplify PLL control during at‐speed test mode. The example below
would be flagged as a violation.

Figure 9: PLL clock source rule

8.2 PLL reset rule

This rule verifies that the PLL control inputs can be controlled from root level ports. Compliance with
this rule is required to simplify PLL control during at‐speed test mode. The example below for a PLL
reset would be flagged as a violation.

Figure 10: PLL reset rule

8.3 PLL clock connection rule

All flip‐flops must be PLL controlled in at‐speed test mode. The flip‐flop shown below would be
flagged as a violation. Compliance with this rule maximizes the at‐speed coverage.

© Copyright Atrenta Inc., 2010 Page 10 of 18

 Facilitating At‐speed Test at RTL

Figure 11: PLL clock connection rule

8.4 Asynchronous logic in the functional mode should not interact

synchronously in the test mode
In the example below in Figure 12, any paths that cross the clock domains Clk1 and Clk2 will be
treated as if they were legitimate at‐speed candidates when, if fact, they are asynchronous in system
mode. Configuring this logic with a single test clock could result in decreased yield.

Figure 12: Asynchronous clocks rule

8.5 Synchronous logic in the functional mode should not interact

asynchronously in the test mode
If this rule is not followed then some at‐speed faults will be considered as untestable which can result
in passing chips that will not operate properly at system speed. In Figure 13, all paths between
Logic1 and Logic2 would not be tested.

© Copyright Atrenta Inc., 2010 Page 11 of 18

 Facilitating At‐speed Test at RTL

Figure 13: Synchronous clocks rule

8.6 Required frequencies must be achieved

Constraints for PLL logic provide for specifying frequencies and frequency multipliers. In the
example below in Figure 14, if the user has specified the required frequencies at internal nodes, then
this rule will verify that it can be achieved.

Figure 14: Required frequencies for at­speed test must be achieved

9 AT­SPEED COVERAGE VS. STUCK­AT COVERAGE

© Copyright Atrenta Inc., 2010 Page 12 of 18

 Facilitating At‐speed Test at RTL

9.1 At­speed fault selection

The strict clocking requirement for at‐speed testing implies that the launching clock and the
capturing clock be synchronous. Transition faults on the path illustrated in red in Figure 15 are
launched by Clk1 but captured on Clk2. If Clk1 and Clk2 are not synchronous then the relative timing
between them cannot be guaranteed. The conclusion is that the candidates for at speed tests must be
in the same clock domain. Skew management within a domain ensures that two clock tests can be
reliably performed within the domain.

Notice that transition faults along the path marked in green in Figure 16. are launched and captured
on the same clock and therefore are at‐speed testable.

Figure 15: Clock domain crossing – Red path indicates invalid faults

Figure 16: Mixed domains – Green path indicates valid faults

Stuck‐at coverage depends on the amount of scan in the design. Ignoring such factors as latch
transparency or black boxes, if all flip‐flops are scannable, then nearly 100% test coverage is a
reasonable expectation since tests for stuck‐at faults requires that the fault be controlled and
observed. As scan is added to a circuit, the fraction of logic that can be controlled and observed
increases and therefore test coverage for stuck‐at faults increases. SpyGlass‐DFT treats the Q‐pins of
scannable flip‐flops as controllable and D‐pins as observable so, as the scan‐ability increases, the
estimated test coverage increases.

In launch by first capture at‐speed tests, not only must control and observe of the transition pin be
satisfied (similar to stuck‐at testing) but a third condition is also necessary to have control on the D‐
pin of the scan flop. Scan‐ability of the logic combinationally connected to the transition pin provides
the necessary control and observe so that the first two conditions are satisfied.

© Copyright Atrenta Inc., 2010 Page 13 of 18

 Facilitating At‐speed Test at RTL

The next state of the launch flip‐flop must be controlled to the complement of the scan‐in state. A
rising edge event requires the scan‐in of 0 and a next state on the D‐pin of the launch flip‐flop to be a
1. A falling edge event requires the scan‐in of 1 and a next state on the D‐pin of the launch flip‐flop to
be a 0.

If some flip‐flops in the D‐pin fan‐in cone of a launch flip‐flop are not scannable, then the next state
function of that flip‐flop may not be controllable. Such uncontrollable next state functions prevent
flip‐flops from launching dynamic events. The result is that coverage of at‐speed tests, using the
launch on first capture method, is generally less than the stuck‐at coverage. A fundamental reason is
that the output controllability of scan flip‐flops becomes dependent on the system mode
controllability of their D‐pins.

ASIC vendors have reported that even when the stuck‐at coverage is in the high 90’s, it is often the
case that the at‐speed coverage is much less. Vendors also report that none of their current software
tools give any clue as to how to fix the problem or are even able to predict this coverage drop at the
RTL stage. Test engineers must run at‐speed ATPG to determine coverage. Effort to fix low coverage
during ATPG affects design schedules, or designers compromise on test quality if it is too late to make
design changes.

10 AT­SPEED COVERAGE CALCULATION OVERVIEW

10.1 Launch events

Any scannable flip‐flop, whose D‐pin has incomplete controllability in system mode, will jeopardize
at‐speed coverage for logic fed by this flip‐flop. For example, if the D‐pin cannot be controlled to
either 0 or 1 then no dynamic events can be launched from this flip‐flop. If the D‐pin can be
controlled to 0 but not 1, then 1 => 0 events can be launched but not 0 => 1 events. Finally, if the D‐
pin can be controlled to 1 but not 0 then only 0 => 1 event can be launched.

10.2 Clock domains

At‐speed tests require the launch clock and the capture clock to be the same clock. This means that
only paths that begin and end on flip‐flops on the same test clock are candidates for at‐speed testing.
If this is not the case, clock timing is not guaranteed and therefore at‐speed testing would not
produce reliable results.

10.3 False paths and multi­cycle paths

Faults on false paths can be excluded from the test coverage calculation but will be included in the
fault coverage.

Faults on multi‐cycle paths will be included in test coverage if the number of registers on a multi‐
cycle path is less than or is equal to the number of capture clocks. Otherwise, such faults will not be
included in test coverage.

10.4 Diagnostics
As described in section 9, an important reason for low of at‐speed coverage is uncontrollability for
the next state functions. The testability analysis of SpyGlass‐DFT DSM determines which flip‐flops
have uncontrollable D‐pins. The fan‐in cones for these D‐pins are then analyzed to identify the cause
of uncontrollability such as non‐scanned flip‐flop, black box, non‐transparent latch or X‐generator.
Figure 17 shows a sample testability report from SpyGlass‐DFT DSM.

© Copyright Atrenta Inc., 2010 Page 14 of 18

 Facilitating At‐speed Test at RTL

Figure 17: SpyGlass­DFT DSM Info_transitionCoverage rule and Diagnostics

11 CAUSES FOR LOW AT­SPEED COVERAGE

11.1 Uncontrollability
As discussed in section 9, incomplete controllability for next state functions in system mode is a
cause for decreased at‐speed coverage. Such cases prevent launch events and thereby prevent
generation of specific tests even though such transitions may be possible in normal functions.

This uncontrollability may be caused by flip‐flops that are not scanned, by black boxes that are not
scanned wrapped or other types of X‐generators.

The flip‐flop colored in red in Figure 18 is not controllable because of the X‐source in its fan‐in cone.

© Copyright Atrenta Inc., 2010 Page 15 of 17

 Facilitating At‐speed Test at RTL

Figure 18: D­pin uncontrollable in at­speed mode

11.2 Blocked paths

Test mode signals may block functional paths so that faults along these paths cannot be at‐speed
tested. An example of this is shown in Figure 19,

1 ­> 0 event
cannot be
launched by
this flip­flop

At­speed faults in
this logic cone
cannot be tested

Figure 19: Blocked at­speed faults

© Copyright Atrenta Inc., 2010 Page 16 of 17

 Facilitating At‐speed Test at RTL

12 SUMMARY
This White Paper discusses at‐speed testing challenges and discusses a solution for facilitating at‐
speed test at the register‐transfer level. The RTL approach is important because designers and test
engineers usually verify the test coverage only at the gate level during the final ATPG stage. This RTL
solution thus saves weeks of effort by fixing potential issues up‐front.

The SpyGlass‐DFT DSM solution is the industry’s first tool which will accelerate design turnaround
times by identifying timing closure issues caused by at‐speed testing – early at RTL. It provides
accurate RTL fault coverage estimation for transition delay testing, together with diagnostics for low
fault coverage early in the design flow, to achieve high test quality with minimum design iterations.

End of Document

© Copyright Atrenta Inc., 2010 Page 17 of 17