2017 IEEE 26th Asian Test Symposium
Test Coverage Analysis for Designs with Timing Exceptions
Kun-Han Tsai
Mentor, A Siemens Business
Wilsonville, OR 97070, USA
Email: hans_tsai@mentor.com
Abstract —Timing exceptions (e.g. false and multicycle paths)
are commonly applied to optimize the performance and meet
timing requirements. These timing exceptions are presented as
extra constraints during test generation to ensure the
correctness of the pattern set. Without considering the impact
on test quality, timing exceptions often result in unpredictable
test coverage impact. This paper proposes a systematic
approach involving both the design and test phases to
achieving high test quality while meeting the design timing
requirements.
I. INTRODUCTION
Achieving high test coverage, including static and at-speed
test quickly is a key test objective for any modern high-
performance IC design with a short development cycle. One of
the main challenges for achieving such goal is the handling of
the complex design constraints.
Multiple scan test modes with different timing constraints
are commonly seen today to achieve the test quality
requirements and meet the design timing constraints. When
generating scan tests, the automated test pattern generation
(ATPG) tool must avoid false failures on the tester caused by
exercising paths that are not designed to propagate logic values
within a single clock cycle[7][8][9]. These paths are known as
timing exceptions, and they can include false paths, multicycle
paths, asynchronous clock groups, set_disable_timing and
set_case_analysis described in SDC files. False paths are often
not exercisable in the functional mode but may be exercisable
during scan test. Multicycle paths are designed such that
expected values are only available at the destination after some
specified number of cycles. They allow the timing optimization
tools to better optimize a design by relaxing timing
requirements and overriding the default single-cycle clock
constraint. Considering timing exceptions is essential to
generating both static and at-speed test patterns that achieve
high quality and avoid yield loss.
In order to ensure correct operation of sequential circuit
elements, data and control inputs are held constant for specified
time periods before and after any clock events. In this context,
the time period before the clock event is called setup time, and
the time period after the clock event is called hold time. A
setup-type timing exception does not meet the setup time
requirements. A hold-type timing exception does not meet the
hold time requirements. Setup-type timing exceptions may
affect test response of at-speed test patterns, whereas hold-type
timing exceptions may affect test response of any test patterns.
A path-oriented approach to handling timing exceptions
during at-speed scan pattern generation has been proposed in
[2] to handle the setup timing exceptions. In [4], the case
2377-5386/17 $31.00 © 2017 IEEE
DOI 10.1109/ATS.2017.41
Srinivasan Gopalakrishnan
Qualcomm India Private Limited
Chennai, Tamil Nadu 600096, India
Email: srgopala@qti.qualcomm.com
studies on various types of timing exceptions in SDC are
illustrated. In [1] the methodology is further enhanced for both
hold time and setup time exception paths to handle any fault
models, e.g. the stuck-at, transition, path delay and user-defined
fault models. The method directly reads in the timing
exceptions provided in the standard SDC format and uses this
information to generate correct-by-construction test patterns.
This method minimizes the number of unknowns by accurately
analyzing the sensitization of timing exceptions in each test
pattern during its creation. Based on the similar approach as [1],
an enhanced at-speed solution is proposed to test both single
and multicycle paths while preventing any simulation
mismatches due to timing exceptions [5].
It has been observed in many industrial designs that the
timing exceptions can significantly reduce the test coverage of
both stuck-at and transition faults. Since the timing exceptions
are created during the design optimization phase, there is no
effective method today to evaluate the test coverage impact
before the ATPG phase. Consequently, the design may suffer
from low test coverage and require extreme effort to achieve
the required test quality. In [3], a novel approach was proposed
to analyze the timing exceptions and collect the X-statistics as
a guidance to debug the low-test coverage due to timing
exceptions. However, the approach introduced in [3] does not
take the timing slack information into account and may identify
the timing exceptions that are hard to eliminate in the design
phase. In this paper, a systematic approach is proposed to
enable cooperation between the design and test generation
phases to optimize the test coverage so the design can obtain
high test coverage while meeting timing requirements. In
addition, to identifing the problematic paths as described in [3],
the proposed approach further analyzes the critical part of the
path that most impacts the test coverage. Such detailed analysis
is important because a timing exception path can include
hundreds or thousands of –through points and often just a small
number of them impact the test coverage most.
There are two main contributions for this paper. First, the
accurate handling of the hold time exceptions including
multicycle paths is proposed. The accurate hold time exception
handling is one of the key steps to achieving the high-quality
static and at-speed tests. Accurate handling of the hold time
exceptions without under-masking or over-masking is a non-
trivial problem due to different clock skews and potential glitch
across multiple timing exceptions. In addition, multiple cycle
hold time exceptions further complicate the situation. The
paper explains the details of the hold time exceptions that are
not yet covered by any publications. Combing the proposed
hold time and existing setup time exceptions handling makes
the complete solution. Second, a systematic test coverage
analysis is proposed to enable cooperation between the timing
164
analyzer and the ATPG tool to improve the test coverage under
the necessary timing constraints.
The paper is organized as follows. In Section II, the
previously published works used by the paper are described.
The hold time exceptions covered by previous publications are
explained in Section III. In section IV, a systematic approach
to analyzing millions of timing exceptions and provide
feedback to improve the test coverage is proposed. The
experimental results on some industrial designs are shown in
Section V followed by conclusion in Section VI.
II. PRELIMINARIES
This section briefly explains the previously published works
on the timing exception handling. First, the static timing
exception analysis is described. Second, the masking of cross
clock domain transitions based on a per-pattern false path
simulation method is explained.
A. Static Timing Exception Analysis
The timing exceptions are statically analyzed to identify
the timing exception intersection cone, denoted as Iex, and the
timing exception effect cone, denoted as Eex [1] as shown by
an example in Figure 1. Iex is the combinational cone between
-from points and –to points of all timing exceptions. Iex is
combinational fanout cone of the –to points of all timing
exceptions. This analysis is implemented by static forward and
backward traversal of the netlist for every defined path, which
is linear time complexity to the netlist gate count and the
number of timing exceptions. The –from and –to points are
associated with each path, but Iex and Eex include the union of
all paths. These analysis cones are used later during pattern
simulation to effectively mask unreliable transitions.
set_false_path –from [get_clocks {clk1}] –through [get_pin {G3/A}]
U1
Intersection
cone Iex
-from
1
D Q 0→ 1
A
G1
-to
A 0 X
B 1→ X G3
CK
B
ck1 True paths
U2 A
G2
1→ 0
1 1 1
→
D Q
B
ck2 CK
Figure 1. A Timing Exception Example
B. The Dynamic Per-Pattern Analysis
The dynamic analysis is done for each ATPG pattern
utilizing the information from the static analysis. The logic
values at the –from points of a timing exception are examined.
If an at-speed transition is found at a –from point, the original
logic value is stored and the logic value X (representing
unknown logic value) is injected. The logic value X is also
injected at a –from point if there was a past at-speed transition
at that point in the given pattern. This is done because the delay
along a timing exception may not be known. Once Xs are
injected at the –from points, their effects are simulated forward
in the Iex cone. If logic value X is propagated at –to points, the
corresponding timing exception is sensitized and the X will be
further propagated to the Eex cone. The X injected in Iex will be
restored before the masking effect simulated in Eex because
there may be true paths through the Iex cone which should not
be impacted (e.g. U1/Q to G2/A path in Figure 1).
At-speed test patterns are sequential in nature and they have
multiple capture cycles. The sensitization checks for the timing
exceptions are performed for each time frame in a given test
pattern as described above. While checking path sensitization,
the affected end points are identified before restoring the
original circuit state. Xs are then injected at the affected end
points. The test responses are computed by propagating
forward the effects of these injected Xs.
The impact of timing exceptions to the capture value of
downstream flops depends on the exception type. A setup-type
exception will impact a flop’s capture value at the next cycle
after an unreliable transition is launched. In contrast, a hold-
type exception will impact a flop’s capture value at the cycle in
which an unreliable transition is launched. To illustrate the
difference, consider the circuit in Figure 1 where flop U1/Q
launches a rising transition at cycle-1 and propagates to U3/D
through a false path. The setup-type exception implies that the
false path can be longer than one cycle and will impact the
capture value of flop U3 when ck2 is pulsed at cycle-2. The
timing diagram of setup-type exception is shown at the left side
of Figure 2, which indicates that U3 will capture X at cycle-2.
The right side of Figure 2 shows the hold-type exception impact
when both ck1 and ck2 are pulsed at cycle-1.
Setup-type exception impact Hold-type exception impact
cycle-1 cycle-2 cycle-1
ck1 ck1
U1/Q U3/D
U3/D ck2
U3/CK
ck2
U3/Q U3/Q
Effect cone
Figure 2. Setup vs. Hold Type Exception Impact to U3/Q in Fig. 1
Eex U3 This example reflects one real scenario when ck1 and ck2
0→ X ?
→ f D Q are not skew balanced, but the clock skew is still within one
A
1→ 1
B
G4 CK cycle. So the hold-type exception only masks the capture value
ck2
U4
of the same cycle. If the clock skew of ck1 and ck2 is larger than
0→ X A 0→ 0 D Q 1
one cycle (which can happen for total asynchronous clocks),
0→ 0
B
G5
the masking effect of the hold-time exception would need to be
CK
ck2
considered for the clock waveform shown at the left side of
Figure 2. More considerations are required for the accurate
handling of the hold time exceptions as explained in section III.
III. THE HOLD TIME EXCEPTIONS
There are three main problems to be conquered for the hold
time exception beyond the basic masking effect described in
earlier publications. The first issue is the maximum clock skew
in term of the capture cycles. Section III.A describes the
algorithm to handle hold time across asynchronous clock paths
where the multiple cycle clock skews can happen. The second
issue, referred to as the cascaded hold time effect, happens
when an unreliable transition shoots through multiple hold time
exceptions. Without correct handling, this situation will result
in under-masking as explained in section III.B. Finally, hold
time exceptions in multiple cycle paths must be tightly
165
correlated with the static timing analysis tool to obtain the To handle the cascaded hold time effect properly, the
accurate masking effect as illustrated in section III.C. dynamic per-pattern analysis described in section II.B is
enhanced to iterate the simulation until the values are all
A. Multiple Cycle Clock Skew stabilized.
There are different assumptions of the maximum clock C. Multiple Cycle Path Hold Time Effect
skew range for the hold time exceptions and they must be
The multicycle hold edge is related to the setup edge of the
considered properly to obtain the accurate masking. Figure 3
same path. To accurately handle multicycle hold time, it is
summarizes the possible assumptions by using the clock
necessary to pair up the multicycle setup path with the
waveform to illustrate the difference. When the clock skew
corresponding hold time path to determine the accurate hold
between source and sink flops is arbitrary, the masking effect
time exception.
must look through all cycles to determine the sink flop value.
If a multicycle of “n –setup” is specified and the same path
Case a) shows the hold time assumption of half-cycle
of “m –hold” is specified, the hold time check edge, eh, is (n-m-
maximum skew so the skew can happen only within the same
1). Only if eh is less than zero, the hold time masking will
clock edge. The leading edge event will not cause hold time
happen. In typical multicycle paths, m is equal to (n-1) so eh is
masking effect to impact the downstream trailing edge event.
equal to 0 and no hold time masking is required. Note that this
Case b) is one-cycle maximum skew that the hold time masking
check must pair up hold time and setup time of the same
can impact within the same cycle of any edges. Under case b),
multicycle paths together. A hash table using multicycle path
a trailing edge flop can capture an unreliable value of an
definition points is utilized here to handle such pair-up
upstream leading edge flop. However, the hold time effect does
efficiently.
not propagate further to next cycle.
a). half-cycle effect b). one-cycle effect c). multiple-cycle effect
cycle-1 cycle-1 cycle-1 cycle-2 IV. THE CONSTRAINT-ORIENTED TEST COVERAGE
ck1 ck1 ck1 ANALYZER
U3/D U4/D U1/Q
In this section, we present the proposed algorithm to
ck2
ck2 ck2 systematically identify the timing exceptions with the most
U4/CK U4/CK
U3/CK impact to the test coverage. The goal of this analysis is to
U3/Q U4/Q U3/Q identify a small number of timing exceptions causing most of
Figure 3. Hold-type Exception Impact with Different Cycle the test coverage drop so they can be reviewed by designer to
Assumption to U4/Q in Fig. 1 eliminate these constraints to improve the test quality. In
addition, an exact test coverage gain achieved by eliminating
The last case c) is the most conservative assumption with the identified timing exceptions will be derived as part of the
multiple-cycles maximum skew. This assumption typically analysis so it help users to justify the benefit. In many highly
applies on asynchronous clock domains, which can have reliable designs, such qualitied test coverage improvement is
arbitrary clock skew. The user could force the tool to pulse crucial for the DPPM reduction.
those asynchronous clocks together to reduce the pattern count
There are a couple of measurement steps described first.
where the false path cross domains are added to mask the
Section A explains the SDC X-Statistic analysis to order the
unreliable transition across clock domains [6].
timing exceptions that will be analyzed by ATPG. The fault-
oriented analysis to improve the X-Statistics ranking accuracy
B. Cascaded Hold Time Effect
is described in section B. The timing consideration to better
The hold time exceptions must be handled within the same integrate with a static timing analyzer is given in Section C
edge between the source and sink flops. Sometimes, the sink followed by the overall algorithm in section D.
flop of a false path is also a source flop of another false path,
A. The SDC X-Statistic Analysis
which creates a cascaded hold time effect. Figure 4 shows an
example of the cascaded hold time effect. A transition on U1/Q There can be millions of timing exception paths in a real
will shoot through U2,causing U3 to be unstable. If there are design, but only a few of them have nontrivial impact to the test
other hold time false path from U3, the cascaded effect will need coverage. Finding the top timing exceptions that contribute to
to be propagated further down the same clock edge. lost test coverage will help test engineers to improve the test
coverage. The SDC X-Statistics analysis is the proposed
set_false_path –from [get_clocks {clk1}] –to [get_clocks {clk2}] heuristic to accomplish this goal. The SDC X-Statistics analysis
set_false_path –from [get_clocks {clk2}] –to [get_clocks {clk3}] is embedded as part of the dynamic per-pattern analysis to
collect the number of unreliable transitions obtained at –to
U1
111
-from
A
-to
100
U2 -from
-to U3
points in each timing exception. It records the number of
111
ck1
D Q 011
B
G1 D Q A
G4
111
D Q
011 pattern bits that timing exceptions are actually masking. The
111 B
CK ck2 CK 111
CK
heuristic is based on an observation that a timing exception path
ck3
-hold false path1 -hold false path2 with more Xs seen at –to points often cause more test coverage
drop. By tracking the Xs of each timing exception and sorting
paths according to X counts, the paths with the largest number
Figure 4. A Cascaded Hold Time Exception Example

166
of Xs can be considered as the ones that cause the most test
coverage drop.
B. The Fault-Oriented X-Statistics Analysis
The SDC X-statistics described in the previous section is a
fault independent analysis, which makes it run time efficient.
However, some masking bits may not be related to the fault
detection. To improve the accuracy of the X-statistics analysis,
a fault-oriented cone marking is performed to eliminate the
masking bits that are unrelated to the target faults. The analysis
starts with a given set of faults, Ftarget, that are undetected due
to the SDC timing exceptions. For example, in Figure 5 the
timing exception cone, Cex, (defined as Iex+Eex), is marked as a
green cone. There are 7 scan cells, c1 to c7, in the cone and will
be counted by SDC X-statistics. Let Ftarget be {f1, f2}, the fault-
oriented analysis marks the fault cone, Cf, and identifies the
scan cells that are both in the inputs of Cex and Cf as the relevant
masking PI cell list, Rpi = {c1, c2 c3, c5, c6, c7}. It also identifies
the scan cells that are both in the outputs of Cex and Cf, as
relevant masking PO cell list, Rpo = {c2, c6}. The union of Rpi
and Rpo is the relevant masking cell set (referred as Rex) which
SDC X-statistics should be monitored. Rex is {c1, c2 c3, c5, c6,
c7} for this example. The other cells outside Rex does not need
to be monitored.
Figure 5. A Fault-oriented X-Statistics Example
The fault-oriented SDC X-statistics only accumulates the
masking bits on the targeted fault list so it can more accurately
reflect the masking effect of the timing exceptions to the
relevant fault list Ftarget. Ftarget can be derived by running ATPG
with and without SDC constraints separately and finding the
difference of the detected faults, which are the faults undetected
due to SDC timing exceptions.
C. The Slack-Guided Analysis
Once the test coverage goal is achievable with the
identified timing exceptions, the revised SDC file with the
reduced timing exceptions needs to be read into the static
timing analyzer to ensure the timing verification passes. If the
timing verification does not pass, the physical design may need
to be optimized to get rid of the new timing violations. Without
using timing information, the constraint-oriented test coverage
167
analysis could result in excluding the timing exceptions with
large negative slack, which cannot be easily fixed. So it is
important to collect the timing information as part of the
analysis. However, there could be a huge number of timing
paths included in a design with millions of timing exceptions
and the analysis effort to get all slack information of the timing
exceptions can be large. To reduce the effort, the SDC X-
statistics can be performed first to identify the timing
exceptions that can cause major masking during ATPG.
Typically, only a small percentage of timing exceptions can
create a masking effect of 1% or more as shown in Table 1 of
section IV. Only the timing exceptions with such non-trivial
masking effect need to be taken to the timing analyzer to collect
the detailed slack data for the SDC test coverage analysis.
During the slack analysis, it is also important for the design
team to review the timing exceptions and decide the maximum
slack paths that could possibly be fixed. For the timing
exceptions that are too costly to be fixed, they will be marked
as hard timing constraints and will not be removed in the SDC
test coverage.
D. SDC Test Coverage Analyzer – Overall Algorithm
The user can disable the top timing exceptions paths and run
incremental ATPG to evaluate the test coverage improvement.
This process, as summarized in Figure 6, is done until the test
coverage goal, Tgoal, is achieved and the return set, Pret, contains
the timing exceptions to be disabled. The routine also stops
when the number of disabled timing exceptions reaches the
user-specified threshold, maxp.
SDC_Test_Coverage_Analyzer(float Tgoal, int maxp){
1. Run ATPG with timing exceptions to obtain the base-line test
coverage Tini and the detected fault list Fini.
2. Run ATPG without timing exceptions to obtain the best test
coverage Tbest and the detected fault list Fbest.
3. Identify the target fault list Ftarget = (Fbest – Fini)
4. Performing fault cone analysis and extract the hard timing
exception paths that are in the fault cones, P(Ftarget)
5. Run ATPG targeting Ftarget with timing exceptions P(Ftarget) -
Pret and record X-Statistics of each path in P(Ftarget) - Pret, and
obtain the revised test coverage T. Also drop detected faults
from Ftarget. If (T > Tgoal) or (T == Tbest) goto step 8
6. Move the path with the largest number of Xs but not a hard
constraint from P(Fex) to Pret
7. If (|Pret | < maxp) go to step 5 else go to step 8
8. return Pret
}
Figure 6. The SDC Test Coverage Analyzer to Find the Top
Timing Exceptions to Achieve the Test Coverage Goal
The high-level analysis which combines ATPG and a Static
Timing Analyzer is shown in Figure 7. This analysis is fault
type independent and can be applied to both static and at-speed
fault types. However, the timing constraints can be different
between the static and at-speed faults due to the different test
clock source and speed. For example, the setup false paths may
not be required for the stuck-at fault because of slow speed.
Since timing exceptions in the static test will most likely to be
presented in at-speed test, it is recommended to apply this
 analysis in the static fault type first. The test coverage
improvement by analyzing the static type will also benefit at-
speed test. The at-speed fault type analysis (e.g. the transition
fault type) can then be applied and focus on the setup timing
exceptions.
Figure 7. High-Level Test Coverage Analysis Flow with A
Static Timing Analyzer
Utilizing fault-based X-statistics analysis with ATPG is a
good way to evaluate the test coverage impact of the top timing
exceptions. The algorithm identifies the minimum number of
paths with largest test coverage impact. The output allows test
engineers to report the timing exceptions causing low test
coverage to the design team for further optimization.
E. Detail Analysis for Low Coverage Paths
Often a timing exception contains many paths and affected
flops. The main test coverage impact may be just on some
partial path, instead of the complete path. A detailed analysis
will give the designer better guidance to further analyze which
affected flops are most important to fix. If only fixing partial
path is sufficient to achieve the test coverage goal while
meeting the timing constraint from the SDC file, the timing
exception can be partitioned into multiple paths and only the
paths with major test coverage impact need to be removed. For
example, Figure 8 illustrates an example of a timing exception
path p1, “set_false_path –through G1/Z” that can be revised to
p1’, “set_false_path –through G1/Z –to c3/D c6/D c7/D” to
eliminate the major coverage impact and still meet the timing
requirement.
Figure 8. An Example of A Timing Exception that is Revised
with X-statistics and Slack Information
168
IV. EXPERIMENTAL RESULTS
The proposed methods are applied to six industrial circuits
with the design size range from 304K to 14.5M flat gate count.
The characteristics of the circuits are summarized in Table 1.
The second and third columns list the number of gate count
(|G|), and the number of timing exceptions (|Pex|). The fourth
column shows the percentage of timing exceptions that contain
masking bits more than 1% of the worst case masking path (%
|Pm|). The result indicates that a very small percentage of timing
exceptions will result in major coverage impact. So only these
few timing exceptions with large masking effect need to be
analyzed by a static timing analyzer to derive the slack data.
The last two columns depict the percentage of the timing
exception intersection cone (%|Iex|) and effect cone (%|Eex|).
The data indicates that the timing exception cones cover over
95% of the design for D1. It helps to explain the large test
coverage impact for D1 (64.1%). Such a design certainly
deserves further investigation to understand the root cause of
the test coverage drop. Design D2 to D4 represent more
common cases where the Iex and Eex cones range from 4% to
32%. The data shows that a larger size of such cones does not
necessary result in a bigger test coverage drop. The test
coverage impact depends on the number of the transitions
sensitized in the timing exception cones which mask the faulty
effect. Such masking effect can only be measured by the
dynamic per-pattern analysis. It is also worth mention that a
fewer number of timing exceptions does not imply smaller Iex
and Eex. This is because each timing exception can include
multiple –from and/or –to points and represent a group of paths.
Thus a small number of timing exceptions still can create large
Iex and Eex.
Table 1 Design Timing Exception Characteristics
|G| |Pex| % |Pm| %|Iex| %|Eex|
D1 304K 351 2.85% 95.31% 88.74%
D2 2.4M 6.7K 0.39% 31.35% 22.70%
D3 4.7M 647K <0.01% 4.11% 16.29%
D4 11M 58K 0.07% 6.27% 11.67%
D5 14.5M 39K 0.10% 18.21% 1.73%
D6 20.0M 7K 1.0% 12.00% 40.00%
|G|: # of gates, |Pex|: # of timing exceptions
% |Pm|: % of timing exceptions with masking effect larger than 1%
%|Iex|: % of timing exception intersection cone
%|Eex|: % of timing exception effect cone
The SDC test coverage analysis is performed on these six
designs and the results are summarized in Table 2. The first
five designs show the test coverage analysis of the transition
fault model and the last design applies the analysis on the stuck-
at fault model. The second column records the best test
coverage that can be achieved (Tbest), which is ATPG without
any SDC timing exceptions. These faults are removed from the
ATPG target fault list to improve the performance. It is also
removed from the at-speed test coverage calculation as they
will not impact the correctness of the at-speed operation. The
initial test coverages by considering all of the timing exceptions
are shown in the third column (Tini) and the user-specified
target test coverages (Tgoal) are depicted in the fourth column.
The threshold maxp is set to 20 in our experiment and is not
been reached for all cases. The numbers of top timing Note that the experiment does not perform the static timing
exceptions to be disabled to obtain the target test coverage are analysis to identify the hard timing exceptions due to the lack
given in the last column. The result indicates that by just of timing file to run slack analysis for these cases.
excluding very few timing exceptions (two to five paths), the
target test coverages can be achieved for all four cases. For V. CONCLUSION
example, design D4 contains 58K timing exceptions and obtains Test generation to handle the timing exceptions is a
56.48% test coverage initially when all timing exceptions are necessity for many of the modern designs with complex timing
applied. By performing the proposed analysis in Figure 6, it can closure and multiple test modes. In this paper, we present a
reach the target test coverage 90.5% by just disabling four false systematic approach to help automatically debug the test
paths. The initial test coverage (Tini) for D1 is unusually low coverage issues caused by a large number of timing exceptions.
(19.54%). The proposed analysis identifies two main Once the timing exceptions are loaded (typically using SDC
problematic paths on the test clock domain which should not be file), the proposed method efficiently identifies the top timing
false paths in the test mode. These paths were given to the exception paths causing most of the test coverage drop. With
ATPG tool incorrectly by using the functional mode SDC files. the incremental ATPG run, the test coverage gain can be
The proposed analysis allows the user to identify these accurately calculated. By sharing the timing exception slack
problematic paths effectively without requiring any design information between timing optimization and test pattern
changes. Without the proposed method, it will take major effort generation steps, the proposed methodology allows users to
to spot the problem manually. improve the test coverage with minimum design changes. Six
Table 2 Result of the SDC Test Coverage Analysis randomly pick designs shown in the paper demonstrate that by
Tbest Tini Tgoal | Pret | fixing a few timing exception paths, the test coverage can be
D1 97.44% 19.54% 92.0% 4
improved significantly. In addition, several hold time exception
D2 82.89% 59.72% 80.5% 5 issues such as cascaded hold time paths and multicycle paths
D3 87.66% 84.52% 86.5% 5 are presented and explained for the accurate timing exception
D4 93.87% 56.48% 90.5% 4 handling.
D5 76.85% 73.74% 76.0% 2
D6 97.00% 93.50% 94.5% 5
Tbest: test coverage without timing exceptions
Tini: initial test coverage with all timing exceptions
Tgoal: target test coverage REFERENCES
|Pret|: # of removed timing exceptions to achieve the target test coverage
[1] D. Goswami, K.-H. Tsai, M. Kassab, T. Kobayashi, J. Rajski,
“Test Generation in the Presence of Timing Exceptions and
To further analyze the top timing exceptions and the impact Constraints”, Design Automation Conference 2007, pp. 688-693.
to the test coverage, the X-statistics data and the incremental
[2] V. Vorisek, B. Swanson, K.-H. Tsai, D. Goswami, “Improved
test coverage gain of the first 10 paths for design D4 is depicted
Handling of False and Multicycle Paths in ATPG”, Proc. IEEE
in Figure 9. Initially, the test coverage is only 56.48%. By VLSI Test Symposium, 2006, pp. 160-165
disabling the first timing exception (which eliminates over
[3] K.-H. Tsai, “Test Coverage Debugging for Designs with Timing
270M Xs), the test coverage jump up to 89.18%. The test Exception Paths”, VLSI-DAT 2016
coverage further goes up to 89.85% and 90.24% respectively
[4] D. Goswani, K-H Tsai, M. Kassab, T. Kobayashi, J. Rajski,
when disabling the second and third timing exception. The
B. Swanson, D, Walters, Y. Sato, T. Asaka, T. Aikyo, “At-
incremental test coverage gain starts to saturate after a few Speed Testing with Timing Exceptions and Constraints-Case
paths are disabled while the number of Xs due to the Studies”, ATS 2006, pp153-162
corresponding paths is decreasing dramatically.
[5] K.-H. Tsai, X. Lin, “Multicycle-Aware At-speed Test
Methodology”, ATS 2013, pp 49-55
͓Ǧ•‘ˆ–‘’ǦͳͲ–‹‹‰‡š…‡’–‹‘• [6] K.-H. Tsai, J. Rajski, “Clock Domain-Aware Test for Improving
Test Coverage Pattern Compression”, VLSI-DAT 2015, pp 1-4
͵ͲͲͲͲͲͲͲͲ 90%
[7] B. Cory, R. Kapur, B. Underwood, “Speed Binning with Path
ʹͷͲͲͲͲͲͲͲ 80%
Delay Test in 150-nm Technology”, IEEE Design & Test of
ʹͲͲͲͲͲͲͲͲ 70% Computers, Sept.-Oct. 2003, pp. 41-45.
ͳͷͲͲͲͲͲͲͲ 60% [8] K. S. Kim, S. Mitra, P. G. Ryan “Delay Defect Characteristics
ͳͲͲͲͲͲͲͲͲ 50% and Testing Strategies”, IEEE Design & Test of Computers,
ͷͲͲͲͲͲͲͲ 40% Sept.-Oct. 2003, pp. 8-16.
Ͳ [9] J. Saxena, K. Butler, J. Gatt, R. Raghuraman, S. Kumar, S. Basu,
D. Campbell, J. Berech, “Scan-Based Transition Fault Testing –
Implementation and Low Cost Test Challenges”, Proc.
International Test Conference, 2002, pp. 1120-1129.

Figure 9. The Top-10 X-Statistics Timing Exceptions and

Impact to Test Coverage for Design D4

169