Slack-Based Test of Multi-Cycle Paths with a Physical View of

Results

Howard Lu, Semtech

Don Skinner, Synopsys

Semtech
Ottawa, Canada

www.semtech.com

ABSTRACT

Modern system-on-chip (SOC) devices rely on a variety of tests to ensure their quality prior to
delivery. At-speed test has become a standard component of these tests, and slack-based ATPG
(automated test pattern generation) has further enhanced this approach. This paper improves the
current solution to slack-based ATPG for transition delay test by including coverage of known
multi-cycle paths that are still timing critical. On-chip PLL clocks are used to ensure accurate at-
speed timing, in conjunction with on-chip clocking (OCC) controllers. Further, a technique to
visualize the quality of slack-based coverage in relation to the physical design is explored using
links between TetraMAX and physical design information.
Table of Contents
Slack-Based Test of Multi-Cycle Paths with a Physical View of Results ...................................... 1
1. Introduction ........................................................................................................................... 4
2. Design ................................................................................................................................... 4
3. Slack-Based ATPG ............................................................................................................... 6
4. Multi-Cycle Paths in a Slack-Based ATPG Environment .................................................... 7
4.1 TRADITIONAL AT-SPEED TRANSITION FAULT TESTING OF MULTI-CYCLE PATHS ................. 7
4.2 BASIC ON-CHIP CLOCKING CONTROLLER OVERVIEW ........................................................... 9
4.3 AN ENHANCED OCC CONTROLLER FOR AT-SPEED TESTING OF MULTI-CYCLE PATHS ....... 11
4.4 SLACK-BASED ATPG TECHNIQUES TO TARGET MULTI-CYCLE PATHS ............................... 13
4.4.1 Preparing STIL Procedure FILE (SPF) for TetraMAX ............................................... 13
4.4.2 Getting Slack Data from PrimeTime ............................................................................ 14
4.4.3 Preparing SDC files for TetraMAX ATPG ................................................................... 15
4.4.4 Two Step ATPG flow .................................................................................................... 15
4.4.5 Sample TetraMAX Script for Slack-Based ATPG on design with multi-cycle paths ... 17
5. Physical View of Slack Based Coverage ............................................................................ 19
6. Results ................................................................................................................................. 20
7. Conclusions ......................................................................................................................... 25
8. References ........................................................................................................................... 26

Table of Figures
Figure 1. Floorplan of the presented design................................................................................... 5
Figure 2. Transition delay fault detection ...................................................................................... 6
Figure 3. Slack based transition delay fault detection ................................................................... 7
Figure 4. On Chip Clocking (OCC) controller .............................................................................. 9
Figure 5. Integrating OCC Controller in a design........................................................................ 10
Figure 6. OCC Timing Diagram (When OCC_TEST_MODE = 1) ............................................ 10
Figure 7. OCC Timing Diagram (When OCC_TEST_MODE = 0, mission mode) .................... 11
Figure 8. OCC controller with four clock bits ............................................................................. 11
Figure 9. OCC Timing Diagram for multi-cycle paths (with clock bits 4'b0101) ....................... 12
Figure 10. Flow for generating delay effectiveness heat map ..................................................... 19
Figure 11. Timing Slacks (Tmgn) vs. Faults distribution ........................................................... 20
Figure 12. Timing of Detection (Tdet) vs. Detected Faults distribution ..................................... 21
Figure 13. Delta (= Tdet – Tmgn) vs. Detected Faults distribution........................................... 22
Figure 14. Delta (= Tdet - Tmgn) vs. Detected Faults distribution (only for the faults with
negative Tmgn) ............................................................................................................................. 22

SNUG 2014 2 Slack-Based Test of Multi-Cycle Paths with a Physical View of Results
Figure 15. Heat map of delay effectiveness without multi-cycle coverage ................................. 23
Figure 16. Heat map of delay effectiveness with multi-cycle coverage ...................................... 24
Figure 17. Heat map of multi-cycle coverage only...................................................................... 25

SNUG 2014 3 Slack-Based Test of Multi-Cycle Paths with a Physical View of Results
1. Introduction
Large size and demanding quality requirements continue to push the DFT (design for test)
requirements on modern designs. A number of new fault models have become available in the
last several years to address this issue. Slack-based ATPG is a modification to the traditional
TDF (transition delay fault) at-speed test technique. This approach uses timing slack data
generated by PrimeTime to guide TetraMAX ATPG towards using the critical path to test at-
speed faults. By doing this, faults are tested at or close to their functional frequency.

Slack-based ATPG has been successfully used on many designs; however it has focussed on
single cycle paths. In many designs, there exist multi-cycle paths that are also critical paths.
These longer paths provide an opportunity to further stress the delays on potential transition
delay faults. This paper, using a recent design as an example, explores a technique to provide
‘top-off’ patterns to cover these extra faults. In addition, a new technique to visualize the quality
of the slack-based coverage on the physical design was used to show the overall slack-based
coverage, as well as the improvement gained by exploiting the multi-cycle paths.

In this paper, section 2 will describe the design that was used to demonstrate this new approach.
Section 3, will provide some background on slack-based ATPG. Section 4, will show the
approach to test multi-cycle paths in a slack-based ATPG environment, and section 5 will
describe the technique used to get a physical view of the coverage. Finally, section 6 will detail
the results on the sample design, and Section 7 will provide a summary.

2. Design

The design presented in this paper is a multi-lane signal retimer with adaptive equalization and
transmit de-emphasis designed for 5Gb/s to 12.8Gb/s full rate operation. It is also designed for
half-rate and quarter-rate operation to retime down to 1.25Gb/s, Ethernet, Infiniband and Fiber
Channel applications. It consists of twelve Clock and Data Recovery (CDR) circuits and supports
up to 12 lanes. The typical applications include:
 > nX10G Backplanes
 10G/40G/100G Line cards
 Cross point Switching
 10G-KR
 40G-KR4
 40G-CR4
 CPRI

The device is implemented with TSMC 40nm technology. The picture below shows the floorplan
of this design.

SNUG 2014 4 Slack-Based Test of Multi-Cycle Paths with a Physical View of Results
 Figure 1. Floorplan of the presented design

The device is a mixed signal ASIC and has a very complex clock structure. There is a significant
amount of logic in digital domain runs at very high frequency. To run at-speed test, we ultilized
On-Chip Clocking (OCC) technigue. There are 3 OCC controllers in this design. One of them is
allocated for the core_clock domain and the other two are ultilized for rest of clock domains. The
functional clocks that drive the OCC controllers originate from internal PLLs.

This device supports 1149.1 DC boundary scan (for digital I/Os), 1149.6 AC boundary scan (for
analog I/Os), memory RAM/ROM and Register File BIST and scan based test (stuck-at ATPG,
at-speed transition fault ATPG and scan compression with DFTMAX).

This design is a good candidate for Slack-Based Transition Fault ATPG due to very tight timing
margin on some paths. On top of that, some timing paths at core_clock domain are multi-cycle
paths (more specifically they are all two cycle paths, i.e. paths with timing exceptions of
“set_multicycle_path –setup 2” and “set_multicycle_path –hold 1”).

This paper will demonstrate an enhanced approach to run Slack-Based Transition Fault ATPG to
target these multi-cycle paths.

SNUG 2014 5 Slack-Based Test of Multi-Cycle Paths with a Physical View of Results
3. Slack-Based ATPG

At-speed test using transition delay faults has been a regular part of ASIC test for several years.
The addition of slack-based ATPG further enhances this approach by including real timing data
in the pattern generation process. Transition delay fault ATPG works by placing a slow to rise or
slow to fall fault on every pin in the circuit. The patterns generated use at least two clocks, one
to launch a transition on a fault, and another to observe if the transition completed in time. This
process can be seen in Figure 2.

Figure 2. Transition delay fault detection

The sensitization and observation of the faults during transition delay ATPG use the optimal path
for the least number of patterns, and the highest coverage. ATPG algorithms are highly
optimized around this goal. In general, this causes these faults to be detected over short paths,
since detecting them along longer paths would involve more complex patterns. Slack-based
ATPG still detects the same slow to rise and slow to fall faults as transition delay, however the
algorithm uses timing data generated by PrimeTime to guide the sensitization and observation of
the fault toward the longest timing path. In this way faults can be detected at, or close, to their
critical timing. This can be seen in Figure 3.

SNUG 2014 6 Slack-Based Test of Multi-Cycle Paths with a Physical View of Results
 Figure 3. Slack based transition delay fault detection

Silicon studies have shown that using slack-based ATPG detects faults that would otherwise be
undetectable using traditional transition fault ATPG [1].

4. Multi-Cycle Paths in a Slack-Based ATPG Environment

As designs getting faster and geometry getting smaller, slack-based ATPG is becoming more and
more important. In many designs, timing in some multi-cycle paths can still be very tight. Using
slack-based ATPG to target these multi-cycle paths is highly desirable to improve the QoR of the
test.

This chapter presents a generic and scalable approach to target slack-based transition faults for
designs with multi-cycle paths. This approach utilizes on-chip clocking [2] and the Slack-Based
ATPG feature supported by TetraMAX [3].

4.1 Traditional At-Speed Transition Fault Testing of Multi-Cycle Paths

To properly guide TetraMAX to generate timing aware transition fault ATPG patterns, we can
read the SDC (Synopsys Design Constraints) file(s) into TetraMAX. TetraMAX takes the timing
exceptions in the SDC files and acts accordingly, e.g., applies masks to the vectors which
sensitize timing exception paths. In other words, multi-cycle paths are not covered during typical
transition fault ATPG with one launch pulse and one capture pulse.

SNUG 2014 7 Slack-Based Test of Multi-Cycle Paths with a Physical View of Results
There are a few options to have these multi-cycle paths covered for transition fault ATPG.

 Option 1: Using a multi-step ATPG and applying different launch/capture clock

frequencies in each step
o running transition fault ATPG by reading the regular SDC files (including all the
multi-cycle paths). The launch/capture clocks run at the full at-speed rate.
o generating extra patterns just to target the multi-cycle paths. The SDC files read
during ATPG shall exclude the multi-cycle paths from the timing exceptions. The
launch/capture clocks run at a divided down rate (such as: half rate).

As designs getting faster, On-Chip Clocking (OCC) is becoming more popular for at-speed
testing due to the speed limitation of testers. The at-speed launch-capture clock pulses are
provided by the OCC controller and the at-speed clock rate is dependent on the real time
functional clocks which are normally generated by internal PLL(s).

The problem with this approach is that in the case of designs with on-chip clocking (OCC)
controllers, when running the extra set of patterns (to targets multi-cycle paths) on tester,
users will have to reprogram the internal PLL to generate a divided down launch/capture
clocks. To reprogram the internal PLL in order to test multi-cycle paths will introduce extra
test time and complexity.

 Option 2: Adding some extra clock divider(s) in test mode to provide divided down clocks
for the launch/capture.

This approach requires extra clock circuit(s) and likely complicates the clock structures.
Futhermore this approach is not scalable and varies from design to design.

 Option 3: Running transition fault APTG with the SDC file(s) that multi-cycle paths
removed from the timing exceptions. This will allow TetraMAX to generate patterns to
cover transition faults along the multi-cycle paths. In other words, this option simply treats
multi-cycle paths as single cycle path during ATPG. However users have to run gate level
simulation with the SDF files in all possible worst corners and mask the vectors that fail
the simulation due to the timing violations on multi-cycle paths.

The idea behind this approach is based on the fact that regular transition fault ATPG likely
targets easy/short paths to generate patterns. By excluding the multi-cycle paths from
SDC, we hope TetraMAX can generate patterns for the multi-cycle paths by using the
short paths and many vectors will be valid (or without timing violations) as a single-cycle
path.

But there are two big issues with this approach: (1) it won’t works for slack-based
transition fault ATPG. In slack-based ATPG, TetraMAX tries to generate patterns to target
the longest path. (2) Unlike Static Timing Analysis (STA), the SDF gate simulations won’t
take on-chip variation (OCV) into account. The simulation might be more optimistic than
STA especailly when a multi-cycle path crosses a long span in the physical layout.

SNUG 2014 8 Slack-Based Test of Multi-Cycle Paths with a Physical View of Results
This paper presents an more efficient approach for testing multi-cycle paths with slack-based
ATPG. It uses minimum logic overhead with little compromise of QoR. It is generic, scalable
and fits well in designs with on-chip clocking structures.

4.2 Basic On-Chip Clocking Controller Overview

The approach demonstrated in this paper is based on the On-Chip Clocking (OCC) structure and
the OCC controllers in the sample design are implemented in RTL by following Synopsys
“Guidelines for designing an on-chip-clocking (OCC) controller” [2].

Figure 4. On Chip Clocking (OCC) controller

The schematic above shows a typical OCC controller. It contains two clock bits for generating
the clock pulses during scan capture. The first clock bit is for the launch and the second clock bit
is for the capture. The launch and capture pulse runs at the at-speed fast_clk.

Figure 5 below shows an example of integrating OCC controllers into a design. Instead of using
PLL_CLK to drive internal flops directly, the PLL_CLK feeds into an OCC controller first.
The OCC controller generates the INT_CLK to drive the internal flops. The output INT_CLK
from the OCC controller is controlled by TEST_SE, OCC_TEST_MODE and the clock bits. The
clock bits are hooked into the scan chains.

Figure 6 and Figure 7 show the OCC controller timing diagrams when OCC_TEST_mode = 1
and OCC_TEST_MODE = 0 respectively.

SNUG 2014 9 Slack-Based Test of Multi-Cycle Paths with a Physical View of Results
 Hooked to scan chain,
controlled by Tetramax

OCC_SO
OCC_SI Clock bits

REF_CLK1
PLL
CLK
PLL_CLK
GEN
REF_CLK2 PLL
INT_CLK
OCC FSM & INTERNAL
Control logic FFs
ATE_CLK (SLOW_CLK)

TEST_SE (SCAN_EN)

OCC_TEST_MODE

OCC Controller

Figure 5. Integrating OCC Controller in a design

When OCC_TEST_MODE = 1

ATE_CLK (SLOW_CLK)

TEST_SE (SCAN_EN)

PLL CLK (FAST_CLK)

INT_CLK

Figure 6. OCC Timing Diagram (When OCC_TEST_MODE = 1)

SNUG 2014 10 Slack-Based Test of Multi-Cycle Paths with a Physical View of Results
 When OCC_TEST_MODE = 0

ATE_CLK (SLOW_CLK)

DON’’T
CARE

TEST_SE (SCAN_EN)

PLL CLK (FAST_CLK)

INT_CLK

Figure 7. OCC Timing Diagram (When OCC_TEST_MODE = 0, mission mode)

4.3 An Enhanced OCC Controller for At-Speed Testing of Multi-Cycle Paths

A basic OCC controller with 2 clock bits works well for at speed testing of single clock cycle
paths but not for at-speed testing of multi-cycle paths.

In the design presented in this paper, there is a group of logic constrained as multi-cycle paths
and these multi-cycle paths are all 2 clock cycle paths. To support at-speed testing for these
multi-cycle paths, we first increased the number of clock bits to 4 bits (See Figure 8).

Figure 8. OCC controller with four clock bits

SNUG 2014 11 Slack-Based Test of Multi-Cycle Paths with a Physical View of Results
We then constrained the clock bits to the pattern 4’b0101 during capture to target these multi-
cycle paths (See Figure 9). Further if there were 3 clock cycle paths in the design, we could even
configure the clock bits to 4’b1001 to target the 3 clock cycle paths.

When OCC_TEST_MODE = 1

ATE_CLK (SLOW_CLK)

TEST_SE (SCAN_EN)

PLL CLK (FAST_CLK)

INT_CLK
Clock_bits = 4'b0101

Clock_bits = 4'b1111

Figure 9. OCC Timing Diagram for multi-cycle paths (with clock bits 4'b0101)

Since the clock bits are very cheap, to avoid resynthesizing the design in a late stage just to cover
a few unexpected multi-cycle paths for at-speed testing, it would be better to just add a few extra
clock bits at the beginning.

In general, we can cover the multi-cycle paths in at-speed ATPG by manipulating the patterns in
the clock bits of the OCC controller. The number of clock bits is dependant on the maximum
clock cycles of the multicycle paths. The minimum number of clock bits is the maximum clock
cycles of the multicycle paths plus 1.

In addition to clock bits, another important component in OCC is the shift registers, which have
two functions. A few flip-flops at front are designated as the retiming flops to handover test_se
from the slow_clk (scan_clk) domain to the fast_clk (pll_clk) domain. The rest of flops of the
shift registers generate the fast_clk_en_pre signal that feeds the D pin of fast_clk_en_reg (See
Figure 8). The fast_clk_en_reg then gates the fast_clk during the capture cycles. The number of
flops inside the shift registers used to generate fast_clk_en_pre is the number of clock bits plus 1.
The logic to generate fast_clk_en_pre can generally be written as:

// - CLOCK_BITS: the number of clock bits inside OCC

// - TEST_SE_SHIFT_LEN: the size of the shift register

logic [CLOCK_BITS-1:0] clock_bits;

logic [CLOCK_BITS-1:0] clock_bit_en;

SNUG 2014 12 Slack-Based Test of Multi-Cycle Paths with a Physical View of Results
logic fast_clk_en_pre;

always_comb begin
for (int i=0; i<=CLOCK_BITS-1; i++) begin
clock_bit_en[i] = ~test_se_reg[TEST_SE_SHIFT_LEN - CLOCK_BITS - 1 + i] &
test_se_reg[TEST_SE_SHIFT_LEN - CLOCK_BITS + i];
end
end

assign fast_clk_en_pre = | (clock_bits & clock_bit_en);

4.4 Slack-Based ATPG Techniques to Target Multi-Cycle Paths

For simplication purposes, without explicit specification we assume all the multi-cycle paths
discussed in this section are two cycle paths.

4.4.1 Preparing STIL Procedure FILE (SPF) for TetraMAX

The internal clocks that are generated from the on-chip clocking (OCC) controllers can be
defined in a STIL Procedure file or a SPF file.

The following is an example showing the corresponding definitions in an SPF ClockStructures

block:

ClockStructures ScanCompression_mode {
PLLStructures "PLL_STRUCT_0" {
PLLCycles 4;
Clocks {
"your_PLL_CLK_0" PLL {
OffState 0;
}
"your_INT_CLK_0" Internal {
OffState 0;
PLLSource "your_PLL_CLK_0";
Cycle 0 "your_occ_inst/clock_bit_reg_reg_0/Q" 1;
Cycle 1 " your_occ_inst/clock_bit_reg_reg_1/Q" 1;
Cycle 2 " your_occ_inst/clock_bit_reg_reg_2/Q" 1;
Cycle 3 " your_occ_inst/clock_bit_reg_reg_3/Q" 1;
}
"your_REF_CLK_0" Reference;
}
}
PLLStructures "PLL_STRUCT_1" {
... ... ...
}
... ... ...
}

SNUG 2014 13 Slack-Based Test of Multi-Cycle Paths with a Physical View of Results
PLLCycles specifies the maximum sequential depth supported by the clock controller.
The Clocks construct defines the PLL/Internal/Reference clocks in the PLLStructures block.
The PLLSource construct is used to identify the PLL clock source that generates the internal
clock. The Cycle construct identifies the corresponding the clock bits.

4.4.2 Getting Slack Data from PrimeTime

TetraMAX enables slack-based transition fault ATPG when a set of slack timing data is read into
TetraMAX, i.e.:

> read_timing global_slack_file

The timing data from the slack file is interpreted by TetraMAX as the minimum slack (timing
margin) for each faultable pin in the design. This information is used by TetraMAX during slack-
based transition fault ATPG.

The timing slack used by TetraMAX can be written out from PrimeTime. The example below
shows a set of PrimeTime commands for extracting the slack data:

pt_shell > set timing_save_pin_arrival_and_slack TRUE

pt_shell > update_timing
pt_shell > report_global_slack –max –nosplit > your_global_slack.rpt

To run slack-based ATPG on a design with multi-cycle paths, it is preferred to extract two sets of
slack timing reports.

The first slack report is extracted from PrimeTime with the original timing constraints that the
timing closure is based upon. In other words, the timing constraints include all the multi-cycle
timing exceptions. For a timing clean design, the extracted slack timing report should only
contain non-negative timing slacks. Here is an example to extract such a slack report:
# loading the original constraint file includes all the multi-cycle exceptions
pt_shell > source timing_constraint.mp_exceptions.tcl
pt_shell > update_timing
pt_shell > report_global_slack –max –nosplit > your_global_slack.mp_exceptions.rpt

The second slack report is extracted from PrimeTime with the timing constraints derived from
the original ones by removing two cycle timing exceptions. For a timing clean design, the
negative slacks in this extracted slack report are due to the removal of the multi-cycle timing
exceptions from the timing constriants. Later in this paper we will show how this slack report
can be helpful to configure TetraMAX to run ATPG with a focus on the multi-cycle paths. The
following is an example to extract such a slack report:

# loading a modified timing constraint file with removal of two-cycle exceptions

SNUG 2014 14 Slack-Based Test of Multi-Cycle Paths with a Physical View of Results
 pt_shell > source modified_timing_constraint.no_mp_exceptions.tcl
pt_shell > update_timing
pt_shell > report_global_slack –max –nosplit > your_global_slack.no_mp_exceptions.rpt

In the case of existing multi-cycle paths other than two cycle paths, extra slack timing reports
shall be extracted. For example, a design with both two cycle paths and three cycle paths needs
another slack report extracted by loading modified timing constraints with removal of all the
three cycle timing exceptions from the original constraints.

4.4.3 Preparing SDC files for TetraMAX ATPG

TetraMAX can read timing exceptions directly from an SDC (Synopsys Design Constraint) file
that is written out by PrimeTime.

Similar to slack reports, two sets of SDC files are needed for this multi-cycle path slack-based
ATPG approach.

The first SDC file is written out from PrimeTime with the original timing constraints including
all the multi-cycle timing exceptions. It is possible that some editing may be required for this
SDC file. In some cases, we find that some of the timing paths that are specified as multi-cycle
paths in the PrimeTime timing constraints may actually be timing closed in a single clock cycle
in physical design. These timing paths are not real multi-cycle paths any more.

This (the first) SDC shall only include the real multi-cycle paths that would otherwise be timing
violated in a single clock cycle. To find the real multi-cycle paths, we can (1) load the timing
clean design; (2) load a set of timing constraints that are derived from the orignal timing
constraints by removing multi-cycle timing exceptions; (3) use “report_constraints –all_violators
–max_delay ” to find the real multi-cycle paths.

The second SDC file is derived from the first SDC file by removing all two cycle timing
exceptions.

The usage of these two SDC files will be discussed in the following sections.

In the case of existing multi-cycle paths other than two cycle paths, extra SDC files shall be
prepared. For example, a design with both two cycle paths and three cycle paths need another
SDC file by removing all the three cycle timing exceptions from the original SDC file.

4.4.4 Two Step ATPG flow

For a design with only two cycle paths as multi-cycle paths, a two steps of slack-based ATPG
can be applied. The first step is to run slack-based ATPG on all the single cycle paths. The
second step is to run slack-based ATPG to target multi-cycle paths. The patterns generated in the
first step are topped up with the patterns generated in the second step. The internal functional

SNUG 2014 15 Slack-Based Test of Multi-Cycle Paths with a Physical View of Results
clocks run at the same rate in both patterns and unlike the traditional approach (see section 4,
option 1) there is no need to reprogram any PLL(s).

Below are some key points at the first step and the second step:

In the first ATPG step,

 Reading the original SDC file that includes the multi-cycle path timing exceptions:

> read_sdc timing_exception.mp_exceptions.sdc

 Reading the global timing slack file which is written out by PrimeTime with the original
timing constraints including the multi-cycle path timing exceptions:

> read_timing tf_global_slack.mp_exceptions.rpt

Note: for a design closed with clean timing, you should not see any negative slacks in the
above timing slack file.

In the second ATPG step,

 Constrain the corresponding clock bits to 0 in order to get a multi-cycle clock pulse. For
example, assume the multi-cycle paths are 2 clock cycle paths and we have 4 clock bits
in the OCC controller, then we can constraint the 2nd and 4th clock bits to 0 in order to
generate the pattern 4’b0101 on the clock bits:

> add_cell_constraint 0 your_occ_inst/clock_bit_reg_reg_1

> add_cell_constraint 0 your_occ_inst/clock_bit_reg_reg_3

 Reading the sdc files that excludes the two-cycle path timing exceptions:

> read_sdc timing_exception.no_mp_exceptions.sdc

 Reading the global timing slack file which is written out by PrimeTime with the timing
constraints with the removal of the two-cycle timing exceptions:

> read_timing tf_global_slack.no_mp_exceptions.rpt

Note: for a design closed with clean timing, all the negative slacks appears in the above
timing slack file should be all related to the multi-cycle paths.

 Configuring TetraMAX to focus on multi-cycle paths in this round of slack-based ATPG:

> set_delay –max_tmgn 0

In the case of existing multi-cycle paths other than two cycle paths, extra steps similar to step 2
can be added to target the additional multi-cycle paths. For example, a design with both two
cycle paths and three cycle paths can use an additional step to target the three cycle paths.

SNUG 2014 16 Slack-Based Test of Multi-Cycle Paths with a Physical View of Results
4.4.5 Sample TetraMAX Script for Slack-Based ATPG on design with multi-cycle paths

###########################################################################
# Assume all multi-cycple paths are 2 clock cycle paths and there are 4 clock bits in OCC
###########################################################################

# load libs
foreach your_lib $your_libs {
read_netlist $your_lib
}

# load netlist
read_netlist $top_netlist

# build model
run_build $top_module

# maintains fault lists for all supported fault models in both DRC and TEST modes.
set_faults -persistent_fault_models

#####################################################
# Step 1: slacked_based ATPG with exclusion of multi-cycle paths
#####################################################

# config transition fault testing

set_delay -launch_cycle system_clock -common_launch_capture_clock
set_delay -nopi_changes
add_po_masks -all
set_sdc -setup –hold
# read sdc file with multi-cycle timing exceptions
read_sdc timing_exception.mp_exceptions.sdc

# DRC
run_drc drc.spf -patternexec ScanCompression_mode

# read timing slack file (written from PrimeTime with multi-cycle path timing exceptions)
read_timing tf_global_slack.mp_exceptions.rpt

# set faults, etc

set_faults -model trans
add_fault –all
……
add_slow_bidis –all
set_atpg -capture 2

# run atpg
run_atpg –opt
write_faults …
write_pattern …

# report slack effectiveness, etc

report_faults -slack effectiveness

SNUG 2014 17 Slack-Based Test of Multi-Cycle Paths with a Physical View of Results
 report_faults -slack Tmgn
report_faults -slack Tdet
……

#############################################
#Step 2: slack_based ATPG target two-cycle paths
#############################################

drc -force
remove_pi_constraint -all
remove_clocks -all
remove_sdc –all

# configure the clock bits with pattern 4’b0101

add_cell_constraint 0 your_occ_inst/clock_bit_reg_reg_1
add_cell_constraint 0 your_occ_inst/clock_bit_reg_reg_3

# config transition fault testing

set_delay -launch_cycle system_clock -common_launch_capture_clock
set_delay -nopi_changes
add_po_masks -all
set_sdc -setup –hold
# read sdc file without two-cycle timing exceptions
read_sdc timing_exception.no_mp_exceptions.sdc

# DRC
run_drc drc.spf -patternexec ScanCompression_mode

# read timing slack info (dumped without two-cycle path exceptions)

read_timing tf_global_slack.no_mp_exceptions.rpt

add_slow_bidis –all
set_atpg -capture 2

# set max_tmgn to 0 to focus on two-cycle paths

set_delay –max_tmgn 0.0

# run atpg
run_atpg –opt
write_faults …
write_pattern …

# report slack effectiveness, etc

set_delay -max_tmgn 100%
report_faults -slack effectiveness
report_faults -slack Tmgn
report_faults -slack Tdet
……

############################################################
# other optional steps, such as: adjust max_tmgn setting to get more top-up
############################################################
………

SNUG 2014 18 Slack-Based Test of Multi-Cycle Paths with a Physical View of Results
5. Physical View of Slack Based Coverage

The metrics used to measure coverage in a scan environment typically revolve around a single
coverage number known as test coverage or fault coverage. When slack-based patterns are also
used other metrics need to be provided to give a measure of the quality of the patterns.
TetraMAX ATPG provides a value known as delay effectiveness. This value is essentially the
ratio of the slack at which faults are detected to their critical slack. While this metric is useful in
determining the value of a pattern set, it does not give a sense of where the coverage is on a
device.

In order to get a better view of the quality of the coverage for the device a script was used to
visualize the coverage across the layout of the device. To do this the layout DEF for the device
and its sub chips was cross referenced with the fault information from the slack-based ATPG
run. The basic flow can be seen in Figure 10.

Figure 10. Flow for generating delay effectiveness heat map

SNUG 2014 19 Slack-Based Test of Multi-Cycle Paths with a Physical View of Results
The script itself is an external Perl script, and is not built into any Synopsys tool. All graphs are
produced using gnuplot. The values are then plotted in a heat map over the layout. The value
that is plotted is the average delay effectiveness for a given region of the layout.

6. Results

Figure 11 shows the design Faults/Timing_Slacks (Tmgn) distribution based on

tf_global_slack.no_mp_exceptions.rpt. The tf_global_slack.no_mp_exceptions.rpt is the slack
timing report extracted from PrimeTime with the multi-cycle timing exceptions removed from
the original constraints. All the negative slacks (which are highlighted as red in Figure 11) are
related to the multi-cycle paths. The negative slacks are due to the fact that multi-cycle timing
exceptions are removed from the timing constraints.

Figure 11. Timing Slacks (Tmgn) vs. Faults distribution

Figure 12 shows the distribution of timing of detection vs. detected faults after ATPG. All
negative detected timing (highlighted as red in Figure 12) is related to the detected faults on

SNUG 2014 20 Slack-Based Test of Multi-Cycle Paths with a Physical View of Results
multi-cycle paths. Timing of detection is the slack data for the actual detected path. For a fault
point with Tdet equal to Tmgn means the test pattern utilizes a longest path to test the transition
fault at this fault.

The closer number of detected faults in each column (bin) in Figure 12 to the number of faults in
the corresponding column (bin) in Figure 11, the better coverage of the slack-based ATPG.

Figure 12. Timing of Detection (Tdet) vs. Detected Faults distribution

Figure 13 shows the histogram of the difference between the timing of detection (Tdet) and
minimum slack (Tmgn). The distribution of the Delta (Delta = Tdet – Tmgn) more skewed
toward the left end of the historgram, the better quality of Slack-Based ATPG would be, i.e., the
generated patterns would be better to detect small delay defects. From Figure 13, we can see
majority of detected faults have the Tdet no more 0.9ns than their Tmgn.

SNUG 2014 21 Slack-Based Test of Multi-Cycle Paths with a Physical View of Results
 Figure 13. Delta (= Tdet – Tmgn) vs. Detected Faults distribution

Figure 13 shows us the overall slack-based ATPG quality including both single cycle paths and
multi-cycle paths. Figure 14 shows the histogram of the difference between Tdet and Tmgn on
only the faults with negative Tmgn. Since all the negative slacks (Tmgn) are contributed by the
multi-cycle paths, Figure 14 gives us an indication of the slack-based ATPG quality on the multi-
cycle paths in the sample design.

Figure 14. Delta (= Tdet - Tmgn) vs. Detected Faults distribution (only for the faults with negative Tmgn)

SNUG 2014 22 Slack-Based Test of Multi-Cycle Paths with a Physical View of Results
The heatmap of both before and after the multi-cycle paths were included as part of the test are
shown in Figure 15 and Figure 16.

Figure 15. Heat map of delay effectiveness without multi-cycle coverage

SNUG 2014 23 Slack-Based Test of Multi-Cycle Paths with a Physical View of Results
 Figure 16. Heat map of delay effectiveness with multi-cycle coverage

The blue sections of the image show areas where the slack-based coverage is not as close to the
critical timing. The yellow sections show areas where faults are being detected close to their
critical slack. This does not mean that there is low transition coverage in that area, only that the
slack-based coverage is not as close to the critical slack. As an example if a fault has a critical
slack of 100ps, and is detected with a slack of 100ps, then it will be hot yellow. If the same fault
is detected at 200ps, then it will be red, and at 400ps it will start to turn blue. The areas that are
predominantly blue may still have very high transition delay fault covergae, but low slack-based
detection.

As can be seen the images in Figure 15 and Figure 16 appear almost identical. The incremental
coverage added does change the image, but it is difficult to see side by side. The floorplan is
rotated to that shown in Figure 1, however the same features can be clearly seen. The design
shows good quality slack-based results in all of the standard logic areas. In order to get an idea
of where the multi-cycle path is improving coverage, the difference between the two fault reports
was plotted instead. This can be seen in Figure 17.

SNUG 2014 24 Slack-Based Test of Multi-Cycle Paths with a Physical View of Results
 Figure 17. Heat map of multi-cycle coverage only

The multi-cycle path coverage improvement covers a significant portion of the design. Many of
these faults show very good quality slack-based detection. With the outlined techniques these
faults on multi-cycle paths not only are effectively covered in slack-based ATPG, but also can be
tested on tester without any reprogramming of internal PLL(s). It is hoped that this kind of
improvement will have an impact on the overall quality of the final product.

7. Conclusions

At-speed test techniques have become a standard component of scan based test for modern
devices. The introduction of slack-based ATPG enhanced that approach by testing faults using a
timing-aware approach. The technique in this paper brings further improvements to the quality
of slack-based ATPG by providing an efficient way to gain coverage on multi-cycle paths. Not
only are faults along these paths now covered using an at-speed fault model, but they are also
tested as close to their critical path as possible.

SNUG 2014 25 Slack-Based Test of Multi-Cycle Paths with a Physical View of Results
The physical view of the coverage on this device provides further insight into what regions of the
device are benefitting most from slack-based ATPG. This visualization of results also clearly
shows what improvements have been made by incorporating multi-cycle path test.

8. References

[1] R Mattiuzzo, S Graniello, S Talluto, A Conte, A Cron, Small Delay Defect Testing Presentation,
Europe SNUG, 2007
[2] Synopsys, Guidelines for designing an on-chip-clocking (OCC) controller, 2005.09-SP3
[3] Synopsys, Slack-Based Transition Fault Testing, TetraMAX ATPG User Guide, Version I-2013.12-
SP4, June 2014

SNUG 2014 26 Slack-Based Test of Multi-Cycle Paths with a Physical View of Results