Application Note Mentor

DFT
At-speed ATPG testing using
FastScan and TestKompress

1.0 Introduction

As the manufacturing technology for ICs allow smaller and smaller geometries, there are
more speed related defects occurring. The defects can be caused by manufacturing
process anomalies, material impurities and any kind of dirt. For the fastest chips, even
the smallest delay defects affect the rated frequency at which a chip can operate. For
these reasons, at-speed testing has become critical for fast VLSI chips. It is important to
note that these speed related defects are not just limited to the high-end multi- gigahertz
type of designs like microprocessors. These timing related defects also need to be
checked in slower frequency designs.

The purpose of a delay test is to verify that a design operates correctly at a specified
clock rate. A delay test can be created to check for either a transition delay or a path
delay. There are many things to consider when a design is to include at-speed testing.
Some of these include: timing of scan chains, shift clocks, scan control, power
consumption, and tester capabilities. Because these topics are covered well in many
publications, this application note will not try to explain all the details of at-speed, or
delay testing, but rather will explain more about the newer enhancements made to
FastScan and TestKompress to help address the testing of ICs for speed related defects.

2.0 Acronym Definitions

ATPG Automatic Test Pattern Generation

DFF D-type Flip Flop
DRC Design Rules Checking
IC Integrated Circuit
IO Input/Output
LSSD Level-Sensitive Scan Design
MUX Multiplexer
PI Primary Input
PO Primary Output
PLL Phase Locked Loop
VLSI Very Large Scale Integration

Mentor Graphics Confidential 1

3.0 General Flow

Figure 1 shows a general flow of the steps you might take to create an at-speed pattern set
using FastScan or TestKompress. The step for defining capture procedures is optional.

Choose Fault Type

Define Capture Procedures

Create Patterns

Analyze Coverage

Figure 1. Flow

Your process may be different, and it may involve re-iterating through some of the steps
based on your design and coverage goals. This application note is laid out by section
topics that correspond to this general flow.

Sections 4.0 and 5.0 explain characteristics of the at-speed fault types to help you decide
which fault type(s) and patterns to use. Timing for at-speed test issues is covered in
section 6.0. Sections 7.0 and 8.0 explain more about the capture procedures and the
support of using on-chip PLLs for your at-speed clocking. This is followed by more
examples in section 9.0 with more details on transition fault issues. In addition, there is
an appendix at the very end for those interested in creating pattern sets that contain
coverage for multiple fault models.

4.0 Transition and Path Delay Faults

To test for speed related defects in manufactured parts, it is essential to create high
coverage test patterns using the transition and/or path delay fault models. Virtually
everyone uses the stuck-at fault model for their logic testing measure. But with speed
related defects becoming a common problem, more people are using fault models that test
for speed related defects as well. Stuck-at and at-speed fault models catch many types of
defects like bridges, opens, doping, etc.

Transition faults model gross delays on gate terminals (or nodes), so each terminal can be
tested for slow-to-rise or slow-to-fall behavior. The defects these represent may include
things like partially conducting transistors or interconnections.

Mentor Graphics Confidential 2

 Figure 2. Transition Delay

If you examine Figure 2, you’ll see that for a simple AND gate, there are 6 potential
transition faults. Those are slow-to-rise and slow-to-fall for each of the 3 terminals.
Because these tests determine the speed at which a device can operate (or fail), this
requires a two cycle test. First, all the conditions for the test are set. In this example, A
and B are 0 and 1 respectively. Then a change is launched on A, which should cause a
change on Y within a pre-determined time. At that point a circuit response capture is
performed and the value on Y is measured. Y might not be stuck at a 0 value, but if Y is
still a 0 when the measurement is taken (the capture point), the device is considered
faulty. The ATPG tool automatically chooses the launch and capture scan cells.

The path delay fault model is another speed-related model and it is somewhat similar to
the transition fault. The difference is that for path delay, a test is generated for testing the
combined delay through a specific path that is defined by the user. Path delay patterns
also use two at-speed cycles for the launch and capture events. See Figure 3 for an
example of a robust path delay test.

Figure 3. Path Delay

Mentor Graphics Confidential 3

Typically, both the launch and capture occur at scan cells. There are a limited number of
faults and paths between PIs and scan cells and scan cells and POs. The timing and tester
capabilities for testing around the chip IO are usually not as precise as clocks used for
scan cell to scan cell tests. Therefore, the body of this application note is focused on scan
cell to scan cell testing. Some guidelines to generate additional tests around IO are
included in section 9.0.

FastScan or TestKompress automatically determines the scan cell values needed to

sensitize all the gates within the path such that any change at the start of the path can
propagate to the end of the path. To create path delay patterns in FastScan or
TestKompress, you would use a sequence of commands like those shown in Figure 4.

SETUP > Add Pin Constraint scan_en c0 // force for launch and capture
SETUP > Set Output Masks on // don’t observe primary outputs
SETUP > Add Nofaults <x, y, z> // ignore non-functional logic
// like boundary scan, etc.
…
ATPG > Set Simulation Mode Combinational –Depth 2 // depth is design dependent
ATPG > Set Fault Type Path_delay
ATPG > Load Paths <filename> // specify the path file
ATPG > Add Faults –All
ATPG > Create Patterns

Figure 4. Dofile Example for Path Delay

The main difference in the two at-speed fault models is that for path delay, the paths to
test are defined by the user (usually after using a static timing analysis tool). When using
transition faults, FastScan or TestKompress can choose any path to use that includes the
gate terminal to be tested. Once the two test pattern types are generated, they look
virtually the same to the tester.

5.0 Broadside and Launch Off Last Shift

For at-speed tests using transition faults, the ATPG engine default is to try to generate a
clock sequential pattern that launches in some cycle after shift is completed. This is
commonly referred to as a broadside pattern and the timing diagram may look something
like the one in Figure 5 where SE stands for scan enable.

Mentor Graphics Confidential 4

 Capture
Launch
...
CLK

...
SE
SHIFT SHIFT Dead SHIFT
cycle

Figure 5. Broadside

Failing that, the ATPG engine tries to generate a pattern that uses the last shift as the
launch event. This uses the combinational ATPG engine, and produces what looks like a
basic pattern with an extra force PI before the last shift. This pattern type is commonly
called a launch off shift transition pattern and its basic timing is shown in Figure 6.

Capture
Launch

...
CLK

...
SE
SHIFT SHIFT LAST Capture SHIFT
SHIFT

Figure 6. Launch Off Shift

The both broadside and launch off shift can improve fault coverage. However, launch off
shift requires that the scan enable for MUX scan designs must be globally routed to allow
changing from shift to capture mode at-speed. Therefore, launch off shift has significant
impact on scan enable timing and it has to be timed and routed similar to a clock.

Because a lot of designs can’t support the restrictions required by launch off shift, it is
often desirable to suppress the attempt to create a launch off last shift pattern if the clock
sequential engine fails to generate a broadside pattern. An option called - no_shift_launch,
can be issued with the Set Fault Type Transition command to prevent any ATPG attempts
to create launch off last shift patterns.

Mentor Graphics Confidential 5

Note that use of this option does not prevent the sequential engine from asserting scan
enable during at-speed tests. Other means, like a scan_enable pin constraint or a changed
capture procedure, must be used to also prevent inappropriate assertion of scan enable
during the at-speed part of a multiple cycle sequential transition fault test. The
no_shift_launch option of the Set Fault Type command only prevents the launch off last
shift form of test from being created when the sequential engine fails to generate a
broadside test pattern. This new option is required unless scan enable can somehow be
toggled at-speed, which is seldom the case at today’s design frequencies.

The Set Fault Type command for FastScan and TestKompress has the syntax shown
below:

SET FAult Type Stuck | Iddq | TOggle | { TRansition [ -no_shift_launch ] } |

{Path_delay [-Mask_nonobservation_points]}

Figure 7 shows an example of how you could use this new option at the command line or
in a dofile with a few other commands to generate broadside transition patterns.

SETUP > Add Pin Constraint scan_en c0 // force for launch and capture
SETUP > Set Output Masks on // don’t observe primary outputs
SETUP > Set Transition Holdpi on // freeze primary input values
SETUP > Add Nofaults <x, y, z> // ignore non-functional logic
// like boundary scan, etc.
…
ATPG > Set Fault Type Transition -no_shift_launch // Prohibit launch off last shift
ATPG > Set Simulation Mode Combinational –Depth 2 // Depth is design dependent
ATPG > Create Patterns

Figure 7. Broadside Transition Dofile

If you want to create transition patterns with launch off last shift, you could use a
sequence of commands like those shown in Figure 8.

SETUP > Set Output Masks on // don’t observe primary outputs

SETUP > Add Nofaults <x, y, z> // ignore non-functional logic
// like boundary scan, etc.
…
ATPG > Set Fault Type Transition
ATPG > Set Simulation Mode Combinational –Depth 0 // prevents broadside patterns
ATPG > Create Patterns

Figure 8. Launch Off Shift Dofile

Mentor Graphics Confidential 6

6.0 Timing for At-Speed Test

Now that we’ve explained the different fault models and broadside versus launch off
shift, let’s go into more detail on how the timing works for these at-speed tests. The
timing information that is used with the patterns is supplied by the user in a test
procedure file. This file describes the scan circuitry operation within a design and is
created by the user or by DFTAdvisor after it inserts scan circuitry into a design. So the
test procedure file contains cycle-based procedures and timing definitions that tell the
ATPG tool how to operate the scan structures within a design. For detailed information
on test procedure files, consult chapter 9 of the Design-For-Test Common Resources
Manual. The examples in this application note will not show all the different types of
procedures, like setup, shift, and load/unload.

Within the test procedure file, timeplates are used to define tester cycles and specify
where all event edges are placed in each cycle. As was shown in Figure 5 for broadside
testing, there are two main cycle types; a slow cycle for shifting (or load/unload) and fast
cycles for the launch and capture cycles. If we now look at an example that includes
some timing, it would look something like Figure 9. This diagram shows 400
nanosecond periods for the slow shift cycles defined in a timeplate called tp_slow and 40
nanosecond periods for the fast launch and capture cycles defined in a timeplate called
tp_fast. Parts of the test procedure file for this example are shown in Figure 10.

400 ns 400 ns 40 ns 40 ns

tp_slow tp_slow
tp_fast

tp_fast

Figure 9. Broadside Timing

Mentor Graphics Confidential 7

 timeplate tp_slow = Pulse clock timeplate tp_fast =
force_pi 0; high at 200 ns force_pi 0;
measure_po 100; for 100 ns. measure_po 10;
pulse clock 200 100; pulse clock 20 10;
period 400; period 40;
end; end;

procedure load_unload = procedure clock_sequential =

scan_group grp1; timeplate tp_fast;
timeplate tp_slow; Specify which cycle =
cycle = timeplate to use. force_pi;
force clock 0; pulse_capture_clock;
force scan_en 1; pulse_read_clock;
end; pulse_write_clock;
apply shift 127; Longest scan end;
end; chain length. end;

procedure shift = procedure capture =

timeplate tp_slow; timeplate tp_fast;
cycle = cycle =
force_sci; force_pi;
measure_sco; measure_po;
pulse clock; pulse_capture_clock;
end; end;
end; end;

Figure 10. Broadside Test Procedure File

As you can see from this example, there is a 40 nanosecond time between the launch and
capture clocks. If you want to create this same timing between launch and capture events
but all your clock cycles have the same period, you can achieve this by skewing the clock
pulses within their cycle periods if your tester can provide this capability. Figure 11
shows how this timing might look and is followed by an example test procedure file in
Figure 12 that includes timeplate definitions called tp_late and tp_early.

capture
100 ns 100 ns 40 ns 100 ns

tp_late tp_late tp_early

Figure 11. Skewed Clock Timing

Mentor Graphics Confidential 8

 timeplate tp_late = timeplate tp_early =
force_pi 0; force_pi 0;
measure_po 10; measure_po 10;
pulse clock 80 10; pulse clock 20 10;
period 100; period 100;
end; end;

procedure load_unload = procedure capture =

scan_group grp1; timeplate tp_early;
timeplate tp_late; cycle =
cycle = force_pi;
force clock 0; measure_po;
force scan_en 1; pulse_capture_clock;
end; end;
apply shift 68; end;
end;

Figure 12. Skewed Clock Timing Procedure File

By moving the clock pulse later in the period for the load_unload and shift cycles and
earlier in the period for the capture cycle, the 40 nanosecond time between the launch and
capture clocks is achieved. For brevity reasons, the contents of the test procedure file
examples shown in figures 10 and 12 are not complete. Normally, they would also
include more items like shift and setup procedures.

7.0 User Selected Capture Procedure

In order to create at-speed test patterns for designs with complicated clocking schemes, it
is sometimes necessary to allow the designer to specify the actual launch and capture
clocking sequences or procedures. For example, in an LSSD type design with master and
slave clocks, the number and order, or sequence of clocks, might need to be done in a
specific way.

The new Set Capture Procedure command introduces the concept of multiple named
capture procedures in the test procedure file used with FastScan and TestKompress. The
old behavior is still supported in that the user can have one un-named capture procedure
that still conforms to the same rules as it always had. This un-named procedure is the
default capture procedure. The user is now allowed to specify additional named capture
procedures, each having a unique name. The sequences of events in these additional
named capture procedures are passed on to the DRC and the ATPG kernel and influence
how the ATPG engine generates patterns. It is important to know that named capture
procedures can be used for stuck-at, path delay, and broadside transition patterns, but
launch off shift transition patterns are not supported.

Mentor Graphics Confidential 9

When several named capture procedures are defined, it is sometimes desirable to use a
subset of those capture procedures for certain types of faults since the other capture
procedures may not be able to detect that type of fault during test generation. A command
was added to allow the user to enable or disable a capture procedure that is used to
generate test patterns during test generation only. That is, if there are existing test patterns
that were generated before by using the capture procedure disabled by the command, the
fault simulation will still simulate these test patterns.

By default, all capture procedures defined in the test procedure file are allowed to be used
by ATPG except the capture procedures that fail to pass DRC checking. When all named
capture procedures are disabled by the command, ATPG is run as if there is no capture
procedure defined in the test procedure file or if a general (un-named) capture procedure
is present, it is used.

The Set Capture Procedure command for FastScan and TestKompress has the syntax
shown below:

SET CApture Procedure [ON | OFf] [-All | <capture_procedure_name>...]

Where the arguments mean:

ON: A switch to enable the use of the capture procedures specified during test
generation.
OFf: A switch to disable the use of the capture procedures specified during test
generation.
-All: A switch that specifies all capture procedures.
<capture_procedure_name>: A repeatable string that specifies a capture
procedure name.

Figure 13 shows an example of how you could use this command at the command line or
as part of a dofile.

ATPG > Load Faults clock1_fault_list // load a specific fault list

ATPG > Set Capture Procedure off –all // turn off all capture procedures
ATPG > Set Capture Procedure on c1_capture // turn on just the capture procedure
// named c1_capture
ATPG> Create Patterns

Figure 13. Set Capture Procedure Command Usage

8.0 Support for On-Chip Clocks (PLLs)

A great way to use the named capture procedures is for the support of on-chip or internal
clocks. These are clocks generated on-chip by a PLL or other clock generating circuitry

Mentor Graphics Confidential 10

as depicted in Figure 14.. In addition, an example timing diagram for this circuit is shown
in Figure 15. In this situation there are only certain clock waveforms that a PLL can
generate and there needs to be a mechanism to specify the allowed set of clock
waveforms to the ATPG tool. In this case, if there are multiple named capture
procedures, the ATPG engine will use these instead of assuming the default capture
behavior.

Figure 14. PLL on Chip

Figure 15. PLL Example Timing

In addition to the new named capture procedures, a new definition called “mode” is
added to the test procedure file syntax for named capture procedures. There are two mode
blocks available, one called “internal” and one called “external”. They must be used
together. If mode definitions are used, all cycles in a procedure must be defined within

Mentor Graphics Confidential 11

the mode definitions. The mode definitions are analogous to having two procedure
definitions in one procedure. Refer to Figure 16 for an example test procedure file that
uses these modes in a named capture procedure with the timing shown in Figure 15.

The internal mode is used to describe what happens on the internal side of the on-chip
PLL control logic, while the external mode is used to describe what happens on the
external side of the on-chip PLL. Figure 14 shows how this may look. The internal
mode uses the internal clocks (/pll/clk1 & /pll/clk2) and signals while the external mode
uses the external clocks (system_clk) and signals (begin_ac & scan_en). If any external
clocks or signals go to both the PLL and to other internal chip circuitry (scan_en), their
behavior needs to be specified in both modes and needs to match. The number of cycles
used and the timeplates used can be different between the two modes, as long as the total
period of both modes is the same. Also, the non-clock events should be in the exact same
order and happen at the same time within the total period. This is for things like force_pi,
measure_po, and other signal forces. Other requirements include:

• If used, a measure_po statement can only appear in the last cycle of the external or
internal mode.
• If no measure_po statement is used, a warning is issued that the primary outputs will
not be observed.
• The external mode cannot pulse any internal clocks or force any internal control
signals.
• A force_pi statement needs to exist in the first cycle of both modes and be before the
first pulse of a clock.
• If an external clock only goes to the PLL and not to any other internal circuitry, a C2
DRC violation will not be issued.

The “pulse_capture_clock” statement is not used in the named capture procedure, instead
the specific clocks used are explicitly pulsed by name. In addition to the other statements
supported by the default capture procedure, the “condition” statement is allowed at the
beginning of the named capture procedure to specify what internal conditions need to be
met at certain scan cells in order to enable this clock sequence. Also, a new
“observe_method” statement has been added to allow a specific observe method to be
defined for each named capture procedure.

Finally, an optional type can be added to the cycle definition. The only type defined now
is the “slow” type. A slow cycle is one in which detection of at-speed faults cannot be
credited. This is important for accurate fault coverage simulation numbers.

Mentor Graphics Confidential 12

 timeplate tp_cap_clk1_slow = end;
force_pi 0; // launch cycle
pulse /pll/clk1 20 20; cycle =
pulse /pll/clk2 40 20; timeplate tp_cap_clk1_fast;
period 80; pulse /pll/clk1;
end; end;
// capture cycle
timeplate tp_cap_clk1_fast = cycle =
force_pi 0; timeplate tp_cap_clk1_fast;
pulse /pll/clk1 10 10; pulse /pll/clk1;
pulse /pll/clk2 20 10; end;
period 40; cycle slow =
end; timeplate tp_cap_clk1_slow;
pulse /pll/clk2;
timeplate tp_ext = end;
force_pi 0; end;
measure_po 10;
force begin_ac 60; mode external =
pulse system_clk 0 60; cycle =
period 120; timeplate tp_ext;
end; force scan_en 0;
force_pi;
procedure capture clk1 = force begin_ac 1;
observe_method master; pulse system_clk;
condition sdff1/q 1; end;
mode internal = cycle =
cycle slow = force begin_ac 0;
timeplate tp_cap_clk1_slow; pulse system_clk;
force scan_en 0; end;
force_pi; end;
force /pll/clk1 0; end;
force /pll/clk2 0;
pulse /pll/clk2;

Figure 16. Named Capture Procedure

The updated DRC takes all of the allowed waveforms into consideration during state
stability analysis. This reduces the pessimism of DRC, and among other things allows
sequential ATPG to be used on designs where scan is controlled by an 1149.1 test access
port (Boundary Scan). DRC analysis is responsible for breaking each test procedure into
a sequence of cycles that map onto the ATPG’s natural event order (force pi, measure po,
pulse clock). It is an error to use both named capture procedures and clock procedures in
a single ATPG session.

Random pattern ATPG will cycle through all of the capture procedures defined unless the
user issues the Set Capture Procedure command to specify a certain procedure(s).

Because all the clocks specified in the capture procedures are not applied in at-speed
cycles, at-speed fault simulation was implemented to collect fault coverage information
accurately. During at-speed fault simulation, at-speed related faults should not be

Mentor Graphics Confidential 13

activated when slow clock sequences are fault simulated even if a transition occurs in two
consecutive cycles.

8.1 Internal Signals and Clocks

To define the internal signals and clocks for use in ATPG, a –internal switch has been
added to the Add Clocks and Add Primary Inputs commands. These are used for clocks
and signals that come out of the PLL or clock generating circuitry and are not available at
the real IO interface of the design.

The enhanced syntax for these two commands now looks like this:

ADD CLocks off_state primary_input_pin … [-Internal]

ADD PRimary Inputs net_pathname … [-Cut | -Internal] [-Module]

For example, when creating ATPG patterns for the example used in section 8.0, you
would issue this command to define the internal clocks:

ADD Clocks 0 /pll/clk1 /pll/clk2 –Internal

Then the two PLL clocks are available to the ATPG engine for pattern creation.

8.2 Saving Internal and External Patterns

By default, FastScan and TestKompress work with the primary input clocks when
creating test patterns. If named capture procedures are used with internal clocks and
signals, then those are used for pattern creation and simulation purposes. If you save
patterns in the ASCII format, it saves the information using these internal clocks and
signals.

In order to get pattern sets that can run on tester equipment, you need to save patterns that
only contain the true primary inputs to the chip. These are the clocks and signals used in
the external mode of the named capture procedures, not the internal mode. To
accomplish this, an optional –mode_external switch has been added to the Save Patterns
command. When you use this –mode_external switch when issuing your regular Save
Patterns command with your desired pattern format, FastScan or TestKompress uses the
information from the named capture procedures to map the internal signals and clocks
back to the external signals and clocks which are available as IO on the device.

If the Save Patterns command is used without the –mode_external switch, the saved
patterns will contain the internal signals and clocks by default.

Mentor Graphics Confidential 14

9.0 Mux-DFF Example and More Transition Fault Issues and Suggestions

In a full scan design, the vast majority of transition faults are between scan cells (or cell
to cell) in the design. There are also some faults between the PI to cells and cells to the
PO. Targeting these latter faults can be more complicated, mostly because running these
test patterns on the tester can be challenging. For example, the tester performance or
timing resolution at regular IO pins may not be as good as that for clock pins. This
section shows a mux-DFF type scan design example and covers some of the issues
regarding creating transition patterns for the faults in these three areas.

Figure 17 shows an example chip. There are two clocks in this mux-DFF design, so that
increases the possible number of launch and capture combinations in creating transition
patterns. For example, depending on how the design is actually put together, there might
be faults that require these launch and capture combinations : C1-C1, C2-C2, C1-C2, and
C2-C1. The clocks may be either external or are created by some on-chip clock generator
circuitry or PLL.

Figure 17. Mux-DFF Example Design

Section 6.0 showed the basic waveforms and partial test procedure files for creating
broadside and launch off shift transition patterns. For this example, named capture
procedures are used to specify the timing and sequence of events. This example also
focuses on broadside patterns and shows only some of the possible named capture
procedures that might be used in this kind of design. For cell to cell broadside transition
faults that are launched by clock C1 and captured by clock C2, examine Figure 18 for a

Mentor Graphics Confidential 15

timing diagram and Figure 19 for a matching test procedure file which includes a named
capture procedure to accomplish this clocking sequence. Other clocking combinations
would be handled with additional named capture procedures that pulse the clocks in the
correct sequences.

Figure 18. Mux-DFF Broadside Timing, Cell to Cell

timeplate tp1 = force c2 0;

force_pi 0; force scan_en 1;
measure_po 10; end;
pulse scan_clk 50 20; apply shift 255;
period 120; end;
end;
procedure shift =
timeplate tp2 = timeplate tp1;
force_pi 0; cycle =
pulse c1 10 10; force_sci;
pulse c2 10 10; measure_sco;
measure_po 30; pulse scan_clk;
period 40; end;
end; end;

timeplate tp3 = procedure capture launch_c1_cap_c2 =

force_pi 0; cycle =
pulse c1 50 10; timeplate tp3;
pulse c2 50 10; force_pi; // force scan_en to 0
period 80; pulse c1; // launch clock
end; end;
cycle =
procedure load_unload = timeplate tp2;
timeplate tp1; pulse c2; // capture clock
cycle = end;
force c1 0; end;

Figure 19. C1 to C2 Named Capture Procedure

Mentor Graphics Confidential 16

Keep in mind that this is just one example and your implementation may vary depending
on your design and tester. For example, if your design can turn off scan_en quickly and
have it settle before the launch clock is pulsed, you may be able to shorten the launch
cycle to use a shorter period, i.e. the first cycle in the launch_c1_cap_c2 capture
procedure could be switched from using timeplate tp3 to using timeplate tp2. Another
way to make sure scan enable is turned off well before the launch clock is to add a cycle
to the load_unload procedure right after the “apply shift” line. This cycle would only
need to include the statement “force scan_en 0;”. Also, when creating patterns for the
cell to cell faults or PI to cell faults, remember to use the Add Output Masks command in
FastScan or TestKompress to mask off the outputs as allowable observation points.

If you want to try to create transition patterns for faults between the scan cells and the
primary outputs, make sure your tester can accurately measure the PO pins with adequate
resolution. In this scenario, it looks a lot like Figure 18, but there is no capture clock. If
you examine Figures 20 and 21, you’ll see the timing diagram and additional capture
procedure that is required for these cell to PO patterns. Of course, you’ll need a separate
named capture procedure for each clock in the design that can cause a launch event. The
timeplates referred to in this example are from Figure 19.

Figure 20. Mux-DFF Cell to PO Timing

procedure capture launch_c1_meas_PO =

cycle =
timeplate tp3;
force_pi; // force scan_en to 0
pulse c1; // launch clock
end;
cycle =
timeplate tp2;
measure_po; // measure PO values
end;
end;

Figure 21. Cell to PO Named Capture Procedure

Mentor Graphics Confidential 17

For named capture procedures, what you specify is what you get. As you can see in the
named capture procedures in Figures 19 and 21, both of these procedures used two cycles
with timeplate tp3 followed by timeplate tp2. The difference is that in the first case (cell
to cell), the second cycle only performed a pulse of c2 while in the second case (cell to
PO) a measure_po was performed. So even though both cycles used the same timeplate,
they only used a subset of what was specified in the timeplate.

To create effective transition patterns for faults between the PI and scan cells, you also
may have restrictions due to tester performance and tolerance. One way to create these
patterns can be found in the example timing diagram in Figure 22 and the corresponding
procedure file in Figure 23.

Figure 22. Mux-DFF PI to Cell Timing

procedure capture launch_PI_cap_C2 =

cycle =
timeplate tp2;
force_pi; // force initial values
end;
cycle =
timeplate tp3;
force_pi; // force updated values
pulse c2; // capture clock
end;
end;

Figure 23. PI to Cell Named Capture Procedure

As before, you would need other named capture procedures for capturing with other
clocks in the design. This example shows the very basic PI to cell situation where you
first setup the initial PI values with a force, then in the next cycle force changed values on
the PI and quickly capture them into the scan cells with a capture clock.

Mentor Graphics Confidential 18

One other important thing to point out is that you don’t need to do at-speed testing for all
the possible faults in the design. You can eliminate things like the boundary scan logic,
memory BIST, and the scan shift path by using the Add Nofaults command in FastScan
or TestKompress.

Appendix A: Multiple Fault Model Flow

If you plan to use multiple fault models in your flow for test pattern generation, you
should know that you can fault grade one pattern type against different fault models. For
example, if you want to create path delay, transition, and stuck-at patterns, the
recommended approach is to do so in the order shown in Figure 24.

Figure 24. Multiple Pattern Flow

As you can see, the general flow is to first generate your critical path patterns and save
them to disk. Then fault grade those path delay patterns for transition fault coverage and
generate additional transition fault patterns for the remaining faults and save those to
disk. Follow a similar sequence to fault grade the transition and path delay patterns for
stuck-at fault coverage and then create the additional stuck-at patterns for the remaining
stuck faults and save them.

Mentor Graphics Confidential 19

By following this process, you end up with a much better overall test program that covers
more fault types with potentially fewer patterns in total. As part of your process, we
recommend optimizing each fault model pattern set with the Order Patterns command
before saving them to the disk.

As an example, here is part of a FastScan dofile that shows one way to accomplish the
pattern creation flow as shown in Figure 24:

//-----------------------------------------------
// example dofile for fault model hierarchy
//-----------------------------------------------
// setup commands for defining things like clocks,
// constraints, and scan chains
set system mode atpg

//------------- Path delay pattern generation -------------

// enable two functional pulses (launch and capture)
set simulation mode combinational -depth 2
set fault type path
load path pathfile
report path path0
//----- option to display a path in DFTInsight -----
// set gate level primitive
// add display path -delay_path path0
//--------------------------------------------------

add faults -all

create patterns //create patterns for paths
report statistics

// save path delay patterns

save patterns pathpat.ascii -ascii -replace

//------ grade for broadside transition fault coverage -----

set fault type transition -no_shift_launch
// read in path delay patterns
set pattern source external pathpat.ascii
add faults -all
run
report statistics
//---------------------------------------------------------

//----- generate additional transition fault patterns -----

set pattern source internal
set atpg compression on
create patterns
report statistics
order patterns 3 // optimize pattern set
save patterns transipat.ascii -ascii -rep
//---------------------------------------------------------

Mentor Graphics Confidential 20

//------- grade existing patterns for stuck faults -------
set fault type stuck
// it is best here to use the full set of patterns
set pattern source external transipat.ascii
add fault -all
run
report statistics
//---------------------------------------------------------

//--------- generate additional stuck-at patterns ---------

set pattern source internal
create patterns
report statistics
order patterns 3 // optimize pattern set
save patterns stuckpat.ascii -ascii -rep
//---------------------------------------------------------

//------- choose ten most effective Iddq patterns ---------

set fault type iddq
add faults -all
set pattern source external allpats.ascii
set iddq checks -all
set iddq strobe -all

select iddq patterns -max 10 -noeliminate

report statistics // patterns automatically ordered
save patterns testpat_iddq.ascii -ascii -rep
//---------------------------------------------------------

Mentor Graphics Confidential 21