AppNote 10064

A P P N O T E S SM
DFT Flow for the Whole Chip

By: Bruce Swanson

Last Modified: 1/26/07

Copyright© 1995-2007 Mentor Graphics Corporation.

This document contains information that is proprietary to Mentor Graphics Corporation. The original recipient of this
document may duplicate this document in whole or in part for internal business purposes only, provided that this entire
notice appears in all copies. In duplicating any part of this document, the recipient agrees to make every reasonable
effort to prevent the unauthorized use and distribution of the proprietary information.
Trademarks that appear in Mentor Graphics product publications that are not owned by Mentor Graphics are trademarks
of their respective owners.

Table of Contents
Introduction ............................................................................................................................................1
Planning Process ....................................................................................................................................2
Getting Started .......................................................................................................................................3
1 Scan Insertion.....................................................................................................................................3
2 Compression Logic ............................................................................................................................5
3 Memory BIST ....................................................................................................................................8
4 Boundary Scan .................................................................................................................................12
5 ATPG ...............................................................................................................................................14
6 Diagnosis..........................................................................................................................................17
Conclusion ...........................................................................................................................................18

Introduction
Today’s electronic IC designs are complex devices and usually contain a myriad of elements that
must work together to make the device function as intended. After the design’s functionality is
verified and the device is manufactured, it needs to be tested for any defects that may be present.
Creating the test program for these devices can be complex as well. Mentor Graphics’ Design-for-
Test (DFT) tools are very powerful, quite flexible, and can work together to create a
comprehensive test solution for the whole chip.

This application note covers higher level information and some basics to consider when using the
DFT tools together on a single design to make sure everything gets tested. All the details for each

01/26/2007 Page 1 of 18
 tool are found in the respective process guides and references manuals. An example design
testcase is available that includes detailed dofiles and instructions to help you step through a
sample process of using DFTAdvisor, MBISTArchitect, BSDArchitect, TestKompress, and
YieldAssist to implement a full flow DFT test program. This testcase can be obtained from our
Design-for-Test Circuits and Solutions website found at
https://supportnet.mentor.com/reference/other-info/dft_circuits/index.cfm. A SupportNet login
account is required to access this page. The circuit name is DFT Flow for the Whole Chip.

Planning Process
There is a saying that goes something like this: people don’t plan to fail, they usually just fail to
plan. When it comes to testing a complex IC design, it is imperative that a comprehensive test
plan be created and implemented. High test quality doesn’t happen by accident; it needs to be
carefully and intentionally done to ensure the highest possible test coverage and product quality.

A good place to start is to decide which types of test methodologies make the most sense for the
design. Things to consider include:

 What type of automatic test equipment (ATE) will be used and what are its capabilities and
limitations? How many pins are available and how much memory is behind each pin?
Can it supply fast clocks?

 Are there any limitations on area overhead for test logic or for the number of I/O pins that
can be used? Can functional pins be shared with test pins?

 Is there a need to test the device within a system, or just at manufacturing time?

 Are there memories and how should they be tested? What memory test algorthms should
be used? What about small embedded memories?

 Is there an on-chip PLL (phase locked loop) or other clock generating circuitry? Will these
on-chip clocks be used in test mode?

 What types of fault models should be used? Are there certain test coverage targets that
need to be met?

 For large designs or when using at-speed test patterns it is now common to include an on-
chip compression technique to reduce test cost and test time. Does this apply to your
design? What level of compression is needed?

 Is there a need to include boundary scan logic and a Test Access Port (TAP) Controller?
Should this controller be used to control the memory built-in self test (MBIST)
controllers?

These are several important considerations, but there are certainly more. Some of these questions,
or their answers, can lead to still more questions. Besides the Mentor Graphics formal product
documentation, there are also resources available at http://mentor.com/dft such as application
notes, white papers, and technical conference papers that can help answer questions or explain
details.

01/26/2007 Page 2 of 18
Getting Started
To illustrate the DFT flow we will walk through a design example that is mostly digital logic that
has a variety of memories spread around the design. The memories should be tested with MBIST
in this case. Boundary scan is a requirement for this design and it will control the MBIST
controllers that are created to minimize the need for having extra external pins to run the memory
tests. ATPG test patterns will be created for both the stuck-at and transition fault models. Since
the number of scan channels on the tester is limited, it makes sense to use TestKompress to
minimize the number of IO pins required for test. Compressed test patterns will run more
quickly on the production test floor and require less tester memory. After running the test
patterns on the tester, any failure files that are created should be diagnosed to check for any
systematic problems that could limit the yield levels.

So we’ve already determined quite a bit of what needs to be included in the test plan. If you
consider the design flow of the DFT portions, it looks something like the flow shown in Figure 1.

Figure 1. Example Design Flow of DFT

Keep in mind that it is just an example flow that starts with a gate level netist and that other flows
are also possible. For example, some projects first create the MBIST, Boundary Scan, and
TestKompress RTL logic before doing synthesis. For this example exercise and testcase, we’ll
explain the DFT steps as shown in Figure 1.

1 Scan Insertion
Scan insertion can be done in a couple of different ways. Some people do the scan insertion as
part of the RTL-to-gates synthesis process. Others complete the synthesis process and then
perform the scan insertion as a separate step. The latter method is used in this appnote example
flow by using the tool called DFTAdvisor. DFTAdvisor is a complete testability analysis and
test insertion tool that can also analyze, identify, and help correct design testability problems in
the design netlist. A basic scan insertion flow with DFTAdvisor is shown in Figure 2.

01/26/2007 Page 3 of 18
 Figure 2: Basic Scan Insertion Flow with DFTAdvisor

After invoking the tool, the first task is to set up information about the design. This includes both
circuit details and information about the test structures that you want to insert. Mux_scan is the
most widely used scan type and is the default; other types are also supported. The next step is
typically enabling test logic insertion. The command to specify what test logic that you want to
allow the tool to insert is Set Test Logic and it has numerous options to turn on or off. This
command specifies whether or not you want to add test logic to uncontrollable signals during the
scan insertion process; most options are on by default. Test logic provides a useful solution to
handle a variety of common problems like bus contention and uncontrollable clocks.

DFTAdvisor must be aware of the circuit clocks to determine which sequential elements are
eligible for scan. DFTAdvisor considers clocks to be any signals that have the ability to alter the
state of a sequential device, such as system clocks, sets, and resets. Therefore, you need to tell
DFTAdvisor about these “clock signals” by adding them to the clock list with the Add Clocks
command. Optionally, the tool can automatically find these “clock signals” by using the
command Analyze Control Signals –Auto_fix. All test control pins like scan_enable and
test_enable must also be specified.

Prior to inserting test structures into the design, you must identify the type of test structure you
want to insert. Since this design example will use the TestKompress compression logic to
interface between the scan channels of the tester and the internal scan chains, you need to specify
how many scan channels and scan chains will be used. The effective compression will be
slightly less than the ratio between the two numbers (the chain-to-channel ratio). For example, if
the number of scan channels is 8 and you need around thirty times (30X) effective compression,
you should configure the design with more than 240 internal scan chains. For the smaller design
example found in Circuits and Solutions that goes along with this appnote, it uses 5 scan
channels and 30 internal scan chains.

01/26/2007 Page 4 of 18
 When you switch the tool from setup mode to DFT mode with the command Set System Mode
DFT, DFTAdvisor performs a model flattening, learning analysis, rules checking, and
scannability checking. If the design rules do not pass, you need to troubleshoot the rule
violations and stay in setup mode to make any necessary changes.

Once you complete the proper setup, you can simply run the identification process for any of the
test structures by using the Run command. This command issues a number of messages about
the identified structures. When all looks correct, the Insert Test Logic command can be executed
to create the test structures that were specified. It is wise to report on the test logic and scan
chains at this point to make sure things were implemented as expected. The DFTAdvisor
command sequence from the testcase is shown in Figure 3.

analyze control signals –auto_fix

// Specify pin names
setup scan insertion -sen scan_en
setup scan pins input -indexed -prefix edt_si -initial 1 -modifier 1
setup scan pins output -indexed -prefix edt_so -initial 1 -modifier 1

set system mode dft

run
// Insert scan and ensure dedicated scan output pins
insert test logic -number 30 -edge merge -clock merge -output new

report scan chains

report test logic

write netlist ../netlists/smallchip_with_scan.v -verilog –replace

write atpg setup ../edt/smallchip –replace -procfile
Figure 3: DFTAdvisor example dofile

The design netlist with the new test structures can be saved along with a dofile and test procedure
file to be used in the automatic test pattern generation (ATPG) tool, TestKompress. The dofile
has commands that specify the test logic and clock information. The test procedure file has the
necessary procedures that explain how to operate the test logic.

2 Compression Logic
EDT stands for Embedded Deterministic Test. It is the technology that is included in the
TestKompress product that enables high compression in test time and test data volume while
using deterministic ATPG patterns. This compression is achieved without any lost of test
coverage compared to standard ATPG. For more details, consult the EDT Process Guide which
provides a thorough explanation of its capabilities and how to use it. For the flow in this
application note, the next step is to create the TestKompress logic for the design. This logic will
reside on the chip and consists of two main pieces: a decompressor which takes the compressed
test patterns from the automatic test equipment (ATE) and loads the scan chains, and a compactor
which takes the scan chain outputs and compacts it for a smaller test response that is sent back to
the ATE for comparison against the expected values. Figure 4 shows a block level diagram of
the TestKompress logic on a device and how it interfaces to the ATE.
01/26/2007 Page 5 of 18
 Figure 4: TestKompress Logic and ATE Interface

The TestKompress tool is very versatile and fits into all design flows. It can be used to add
TestKompress logic in flat designs and on a block or hierarchical level. The TestKompress logic
can be created before or after the main design core or block is synthesized. For this example
testcase, the design is already synthesized and the scan chains have already been inserted with
DFTAdvisor. Only one set of TestKompress logic is required as Figure 4 illustrates. Optionally,
if the design is modular or hierarchical, TestKompress logic can be created and inserted on a
block or hierarchical level.

When starting with the TestKompress logic creation step, invoke TestKompress with the scan-
inserted netlist and the DFT library. Then you can execute the dofile that was created by
DFTAdvisor which defines the clocks and scan chains in the design core.

To configure the TestKompress logic, specify certain parameters using the Set EDT
command. The two most important parameters are the position of the TestKompress logic,
internal or external, with respect to the original netlist the tool read in, and the number of
scan channels. For a basic run to create external TestKompress logic (the default), you only
need to specify the number of channels. Other parameters are available to specify whether to
create DFF-based or latch-based TestKompress logic and whether to include bypass circuitry
in the TestKompress logic, lockup cells in the decompressor, and/or pipeline stages in the
compactor. The tool defaults for these parameters are as follows:

• DFF-based TestKompress logic

• Lockup cells in the decompressor, compactor, and bypass circuitry

• No pipeline stages in the compactor

• Generate bypass logic

The default configuration consists of pins for the EDT clock, update, and bypass inputs. There
are also two additional pins (one input and one output) for each scan channel. If you do not
01/26/2007 Page 6 of 18
 rename an EDT pin or share it with a functional pin, TestKompress assigns the pin names as
shown in Figure 5 when two scan channels are used. The bypass input is optional and is only
included when you specify bypass circuitry.

Figure 5: Example of a basic EDT pin configuration

As a comparison, Figure 6 shows how the same design could look configured with shared pins
and the EDT bypass pin named “my_bypass”.

Figure 6: Example with pin sharing

01/26/2007 Page 7 of 18
 The Set Edt Pins command is used to define and customize the pins and their connections. Once
you’ve defined everything, it is wise to perform a Report Edt Pins command to get a description
of the pins and their connections to verify that you’ve got what you intended to implement.

If you choose to include bypass circuitry when using the Set Edt command to specify parameters
for the TestKompress logic, TestKompress automatically determines the chain connections to
create each bypass chain. These interconnections are fine for most designs. However, you can
specify custom chain connections (to meet unique routing requirements, for example) using the
Set Bypass Chains command.

When all the TestKompress setup commands are entered and you’re ready to create the logic, use
the Set System Mode Atpg command to exit setup mode and perform the design rules checking
(DRC). Besides the regular rules that are shared with the other DFT tools, a class of
TestKompress-specific “K” rules are also checked to verify key items. If there are errors, make
the necessary correction(s) before running the rules check again.

Once you have completed DRC successfully, generate the TestKompress logic by issuing the
Write Edt Files command. This command writes files that describe the TestKompress logic in
either Verilog or VHDL RTL, one or more dofiles and test procedure files for use later in the
ATPG stage, and a synthesis script. The sample synthesis script is for use with Synopsys’
Design Compiler tool, but any available synthesis tool can be used. Many more details and
example synthesis scripts are provided in the EDT Process Guide. The sample dofile for the
compression logic generation phase of the testcase is shown in Figure 7.

add black box -auto

dofile ./smallchip.dofile // Dofile from DFTAdvisor
set edt -channels 5

set system mode atpg

report edt configuration
write edt files ./edt/smallchip -verilog -replace

// optionally create patterns for test coverage and pattern volume estimate
create patterns -auto -override
report statistics

report scan volume

Figure 7: TestKompress example dofile

3 Memory BIST
For the next step, MBISTArchitect is used to generate built-in self-test (BIST) controllers and
memory collar blocks for the memories of the design. The output is RTL level MBIST logic
which can be combined with the core RTL design directly or the gate level netlist. It is important
to plan how the memories will be tested. That plan should include how many MBIST controllers
are needed and which memories will be connected to which controllers. It is also important to
understand and decide which memory test algorithms to use. If these topics are new or unclear to

01/26/2007 Page 8 of 18
 you, please refer to the Built-In Self-Test Process Guide which gives an overview and
explanation of these issues.

The most basic MBISTArchitect session consists of these tasks:

1. Invoke MBISTArchitect
2. Load a Library
3. Add a Memory Model(s)
4. Run MBISTArchitect logic generation
5. Run insertion of BIST logic
6. Save the Output

The library you load is a DFT library that contains the memory models for which to add BIST
logic. After adding the memory models that you wish to use, define the BIST controllers and
select the algorithms to implement. MBISTArchitect provides a common default BIST
architecture. However, this default circuitry may not meet all of your testing requirements.
MBISTArchitect lets you customize the circuitry it generates in a number of ways.

One common variation includes using a compressor for signature analysis instead of a built-in
comparator for direct memory output comparison. To specify the compressor, use the Setup
Observation Scheme and Setup Mbist Compressor commands.

You can also add to or change the default test algorithms that MBISTArchitect uses. For
example, if you add BIST circuitry to a multiple-port memory model, you may not want to
execute the March C+ test on every write port. You may instead want to use the Unique Address
algorithm to test just the address and control circuitry for some ports. You can specify this, or
any other algorithm change, using the Add Mbist Algorithms and Setup Mbist Algorithms
commands.

Another common variation includes using a single BIST controller for multiple memory models.
You can add BIST circuitry to individual models, creating BISTed memory models, or you can
create a single BIST controller that controls and tests a number of different compatible memory
models. To specify this, use the Add Memory Models command.

At a basic level, the memories are replaced by memory collars, and the MBIST controllers are
placed in the hierarchy defined by the Add New Controller or Add Existing Controller
commands. A diagram of a memory collar and BIST controller is shown in Figure 8.

01/26/2007 Page 9 of 18
 sys_addr
sys_datain

BIST Controller Collar

bist_clk test_datain M Dout

FSM U MEM
MEM
test_addr
rst_l X
test_wen
test_h clk BYPASS

Comparator fail_h
tst_done

Figure 8: Simple BIST Controller Block with Collar

The memory collars instantiate the input muxes, the memory itself, and the memory bypass logic
(if necessary).

If the BIST controller(s) should be run from the boundary scan TAP controller, there are two
commands in MBISTArchitect that should be used. First is Set Bsdarchitect –on which generates
needed specparams/attributes and additional ports on the BIST controller for BSDArchitect
support. Then MBISTArchitect can create a dofile to be used in BSDArchitect by using the
command Save Driver Files –Bsda <file_name>.

When the Save Bist command is executed, MBISTArchitect produces a few files including the
RTL model file, the connection file, and a testbench. These files should be compiled and
simulated in a functional simulator like ModelSim to verify the correctness of the functionality.

For the testcase example that is provided with this application note, it has 32 memories that are
connected to 3 MBIST controllers. The implemention takes advantage of some of the advanced
features of MBISTArchitect like full-speed operation and diagnostic capabilities. Full-speed
means that the test and memory are run at the chip clock speed. It is important to detect defects
that are timing related instead of just stuck-at problems. Full-speed test accomplishes this and
also has the benefit of reducing the test execution time. MBISTArchitect uses a unique pipeline
approach to enable consecutive read and write operations in adjacent clock cycles during the test.

The basic MBIST test provides a pass/fail outcome. To get details as to where the defects are
located in the device, diagnostic capabilities are required. MBISTArchitect can create the
additional logic needed in the controller to allow the failure information to be stored and then
read out of the device. This information is needed to determine the location of the defects. The
example design dofile for MBISTA is shown in Figure 9. You can see that the add new
controller commands each use another BIST generation dofile that is found in the testcase.

01/26/2007 Page 10 of 18
 load library libs/memory.lib
add clock 0 clk1
add clock 0 clk2
add clock 0 clk3
add clock 0 clk4
add clock 0 ramclk

// Creating a port for the the bist clock

add new port bist_clock -direction in
add clock 0 bist_clock
add pin sharing bypass_clk clk1
add pin sharing bypass_control memory_bypass

set sys mode bist

report memory instances
add new controller picdram_multi_seq_bist_cont_inst -dofile bistgen1.do \
// list of memories for this controller
add new controller picdram_multi_conc_bist1_cont_inst -dofile bistgen2.do \
// list of memories for this controller
add new controller picdram_multi_conc_bist2_cont_inst -dofile bistgen3.do \
// list of memories for this controller
add pin mapping bist_clock /picdram_multi_seq_bist_cont_inst/bist_clk \
/picdram_multi_conc_bist1_cont_inst/bist_clk \
/picdram_multi_conc_bist2_cont_inst/bist_clk
add pin mapping scan_in_0 /picdram_multi_seq_bist_cont_inst/diag_scan_in
add pin mapping scan_in_1 /picdram_multi_conc_bist1_cont_inst/diag_scan_in
add pin mapping scan_in_2 /picdram_multi_conc_bist2_cont_inst/diag_scan_in
report pin mapping
report pin sharing
report memory instances

add concurrent group grp1 picdram_multi_conc_bist1_cont_inst \

/picdram_multi_seq_bist_cont_inst
insert bist logic
save design -directory ./mbista/ -replace
save access file top.access -replace
save driver files -logic_synthesis mbista/dc.do -verification mbista/gate_ver.do \
-bsda bsda/bsda_mbistarchitect.do -replace
// BSDA will write out a testbench that will kick off MBIST

set sys mode integration

add pattern translation -all
integrate patterns
save patterns ./mapped.v -verilog -rep
save patterns ./mapped.wgl -wgl –rep
Figure 9: MBISTArchitect example dofile

01/26/2007 Page 11 of 18
4 Boundary Scan
For the next step, BSDArchitect generates an IEEE Standard 1149.1 (JTAG) structure that can
drive all the MBIST controllers in the design through the Test Access Port (TAP). Please refer to
the Boundary Scan Process Guide if you are unfamiliar with these terms or this standard.
BSDArchitect is invoked on the MBIST inserted netlist using the dofile created by
MBISTArchitect. This dofile has commands to create an MBIST control data register
(mbist_reg), and the necessary logic to pulse the “rst_l” signal of the MBIST controllers so that
they can reset before the start of MBIST operations. The bits of the control data register are used
to drive the “test_h” signals and capture the “fail_h” and “tst_done” signals from the MBIST
controllers. The “bist_clk” of the controllers are set up to be driven from the “tck” signal through
a buffer. To control the logic, the add bscan instruction command is used to create JTAG
instructions to reset and run the MBIST controllers.

The diagram shown in Figure 10 shows the MBIST control data register and the connections
between the TAP controller and the MBIST controllers for an example design with three
memories connected to two MBIST controllers. This is a simpler configuration than the real
testcase provided with this appnote.

Mem1 Mem2 Mem3

mbist_reg_reset
updateir

MBIST MBIST
Controller 1 rst_l Controller 2
rst_l

TAP
tst_done

tst_done
test_h

test_h

Controller
fail_h

fail_h

TDI TDO
TDO
TDI
TRST
TMS
TCK

mbist_reg

Figure 10: Boundary Scan and Memory BIST Logic Integration

After setting up all the registers, instructions and connections, the Run command is executed
followed by the Save Bscan command to save the new files. The dofile from the testcase is
shown in Figure 11.

01/26/2007 Page 12 of 18
 // Create Reset register to reset before the start of MBIST operation
add bscan instruction mbist_reg_reset -reg BSCAN_BYPASS_REG

// Create MBIST register and target an instruction for the MBIST operations
add external register mbist_reg 9
add bscan instruction mbist_instr -reg mbist_reg

// Create the register interface and define testbench parameters

set external_register interface mbist_reg -capture fail_h_mgc_1 \
fail_h_mgc_2 fail_h_mgc_3 tst_done_mgc_1 tst_done_mgc_2 \
tst_done_mgc_3 -update debugz_mgc_1 debugz_mgc_2 \
debugz_mgc_3 hold_l_mgc_1 hold_l_mgc_2 hold_l_mgc_3 \
test_h_mgc_1 test_h_mgc_2 test_h_mgc_3

set testbench parameters -instr mbist_instr -shift_in 111111111 \

-shift_out 000111 - cycle 11776

// Connecting MBIST controller resets to BSDA reset

add port connection rst_l_mgc_1 "mbist_reg_reset NAND updateir"
add port connection rst_l_mgc_2 "mbist_reg_reset NAND updateir"
add port connection rst_l_mgc_3 "mbist_reg_reset NAND updateir"

// Connecting Bist clock to TCK

add port connection bist_clock "buf tck"

// Run, save and quit

run
save bscan –replace // This also saves the simulation testbench
save patterns -all jtag_patterns.wgl -format wgl -replace

Figure 11: BSDArchitect example dofile

BSDArchitect produces a boundary scan design model in VHDL or Verilog RTL. This model
contains a new level of hierarchy which instantiates and connects the boundary scan circuitry to
the core design. Following boundary scan insertion, by default, the top-level module typically
contains the following components:

• Core Logic block

• Boundary Scan Register instance(s)

• TAP Controller block

• External register (optional)

• User Code register (optional)

• I/O Buffer Block instance(s)

01/26/2007 Page 13 of 18
 Use the HDL testbench to verify that the boundary scan logic generated is correct by simulating
it in a functional simulator like ModelSim. The testbench contains vectors used as stimulus for
the boundary scan circuitry. You can choose to have BSDArchitect write these vectors into a
separate file in FlexTest table or WGL format. Optionally, FlexTest can then be used to fault
grade these vectors and utilize them as a starting point for ATPG if desired.

Once you verify that the boundary scan circuitry is compliant and simulates correctly, you can
synthesize the HDL model of the boundary scan circuitry to a gate-level model. If the circuit
contains internal scan circuitry controlled by the boundary scan circuitry, you can use
BSDArchitect to generate two ATPG setup files: a dofile for setting up scan circuitry
information, and a test procedure file for specifying the operation of the scan circuitry. For this
example, the scan circuitry is not controlled by the JTAG logic. You can re-use the HDL
testbench to verify correct operation and IEEE compliance of the synthesized design once it is
ready. The synthesis can be done with any of the standard synthesis tools available.

5 ATPG
After the synthesis is completed to integrate the MBIST, BSCAN, and TestKompress logic with
the scan-inserted design core, the result is a gate level netlist that can be used for the Automated
ATPG step of the flow.

Refering back to the beginning of this appnote, it is important to plan the ATPG process based on
the requirements and desired test quality results. TestKompress can create test patterns for a
number of different fault models. Fault models are a means of abstractly representing
manufacturing defects in the logical model of the design. The different types of models target
different defect types. Some defects can be detected by tests for multiple fault models.

Figure 12: Basic Flow for Creating Test Patterns

01/26/2007 Page 14 of 18
 The basic flow of using TestKompress for creating stuck-at test patterns is shown in Figure 12.
You can see that it uses the dofile and test procedure file that were written out by TestKompress
earlier in the logic creation phase to make the process easier.

For today’s designs of 130 nanometer processes and smaller, most people believe that including
at-speed tests is a requirement. For more information on at-speed testing and newer fault models,
please see the white paper entitled At-Speed and Advanced Fault Models for Achieving High
Quality Test found on the Mentor Graphics website mentioned in the Process Planning section.

For this example testcase flow, we will create transition and stuck-at fault test patterns with the
dofile shown in Figure 13.

// first define scan chains, edt logic, clocks

add pin constraints edt_clock C0

//Added for BSDA
add pin constraint tms C1
add pin constraint trst C1
add pin constraint memory_bypass C0

set edt -channels 5 -longest_chain_range 16 130 -ip_version 3 \

-decompressor_size 32 -injectors_per_channel 3 -scan_chains 30

// Distributed ATPG
add processor localhost:maxcpu
// nofault the EDT, BSCAN, and MBIST logic
add nofault /cpu_top_edt_top_i/cpu_top_edt_i/cpu_top_edt_decompressor_I \
-instance
add nofault /cpu_top_edt_top_i/cpu_top_edt_i/cpu_top_edt_compactor_i \
-instance
add nofault /tap_i -instance
add nofault /bsr_i1 -instance
add nofault /cpu_top_edt_top_i/picdram_multi_conc_bist1_cont_inst -instance
add nofault /cpu_top_edt_top_i/picdram_multi_conc_bist2_cont_inst -instance
add nofault /cpu_top_edt_top_i/picdram_multi_seq_bist_cont_inst -instance
add nofault mbist_reg_i -instance

set system mode atpg

set fault type transition -no_shift_launch
set transition holdpi on // if tester I/O are slow
set IO mask on // if tester I/O are slow

add faults -all

create patterns -auto
report statistics

order patterns 2
save patterns ./patterns/patterns_transition.v -verilog -replace
save patterns ./patterns/patterns_transition.ascii -ascii –replace

01/26/2007 Page 15 of 18
 // save data for use with diagnosis later
save flattened model smallchip_edt_scan_gate_mbist_jtag_transition.flat -replace

// grade transition patterns for stuck-at faults

set fault type stuck
set IO mask off
// read in the saved transition pattern set
set pattern source external ./patterns/patterns_transition.ascii -ascii
add faults -all
run // perform fault simulation
report statistics // stuck-at coverage for transition patterns

// generate additional stuck-at patterns

set fault protection on // protect detected faults
set pattern source internal
reset state // removes transition patterns from memory
create patterns -auto // top-up stuck-at patterns
report statistics
order patterns 2 // optimize pattern set
save patterns ./patterns/patterns_stuck.ascii -ascii -replace
save flattened model smallchip_edt_scan_gate_mbist_jtag.flat –replace

Figure 13: Partial TestKompress dofile example

Note that the TestKompress, BSCAN, and MBIST logic are all no-faulted. To make the test set
smaller, we began by making the transition test patterns first and then fault simulated them
against the stuck-at fault model. This is a valuable approach because the transition test patterns
also detect a significant percentage of the stuck-at faults. Additional stuck-at test patterns can
then be created to increase the test coverage for stuck-at faults. This approach allows you to get
the highest test coverage for the two fault models with the fewest number of patterns.

By using this command sequence, two pattern sets are created. One for broadside transition
patterns and one for stuck-at patterns. You can also combine them into one pattern file if desired.
TestKompress can save to many different file formats including our ASCII and binary format and
industry standards like STIL and WGL.

When the test patterns are saved, it is customary to also save a simulation testbench. This
testbench is used along with the saved patterns to verify that they work correctly with the design
by performing functional simulation in a tool like ModelSim. The typical approach is to simulate
a few of the patterns in a serial fashion and to simulate all of the parallel patterns. We also saved
flattened models of the design for later use with diagnosis. This is important because this model
contains all the tool settings that were in place when these test patterns were created.

01/26/2007 Page 16 of 18
 6 Diagnosis

Once the ATPG test patterns are created and verified, they typically are included in the test
programs and head to the manufacturing or test floor to be used on the automatic test equipment
(ATE) with the real devices. When the ATE encounters mismatches of the test pattern expected
results with actual results captured from the devices, that mismatch information is saved in fail
log files. The information contained in these log files is very valuable and can be used to help
find where in the device those potential defects are located. This process is called scan-based
diagnosis and Mentor Graphics offers a tool called YieldAssist to do this work. YieldAssist
takes as input the flattened version of the design netlist, ATPG library, test patterns, and failure
log files and determines where in the design the suspect defects are located. The process is
summarized in Figure 14.

Figure 14: YieldAssist diagnosis flow

As you can see, after consistency checks are executed to make sure the correct files are being
used, the tool performs both chain and logic diagnosis. When done with it’s analysis,
YieldAssist produces a report of it’s findings that includes the defect symptoms, types, and
scores. It narrows the defect location down to the net, cell, and pin as shown in the example
report shown in Figure 15.

01/26/2007 Page 17 of 18
 #symptoms=1 #suspects=1 CPU_time=13.87sec fail_log=failure_files/failure_file_1
#failing_patterns=220, #passing_patterns=601
#unexplained_failing_patterns=0

symptom=1 #suspects=1 #explained_patterns=220

24 59 60 72 80 88 90 100 109 111
113 115 116 130 139 142 147 148 149 154
...
747 756 758 763 782 784 792 797 810 815
suspect score fail_match pass_mismatch type value pin_pathname cell_name net_pathname
----------------------------------------------------------------------------------------------------------------------------
1 100 220 0 STUCK 1 /cpu.../ix15/Y and04 /cpu.../option
----------------------------------------------------------------------------------------------------------------------------
Figure 15: Example YieldAssist diagnostic report

The example shown here is for a stuck-at 1 type of defect on the net location specified which is
driven by the pin of the cell. YieldAssist can find and diagnose all types of defects. This
diagnosis information is very valuable as part of failure analysis in pin-pointing the actual
location of defects in the devices. The locations can be shown in either the logical view with the
DFTVisualizer tool or in the physical layout view in the Calibre layout tool. Once the defect
locations are known and analyzed, corrections can be implemented to quickly drive up product
yield.

Using YieldAssist is pretty simple, the tool does all the hard work. The main command is called
Diagnose Failures and is used with the failure file log as input and it outputs the results report
like the one shown in Figure 15. For multiple failure files, the same command is used with each
failure file. The testcase provided with this appnote contains 7 example failure files that would
come from the ATE. When used with YieldAssist with the dofile shown in Figure 16, seven
diagnosis results files are created like the one shown in Figure 15.

set pattern source external ./patterns.ascii -ascii

diagnose failure failure_files/failure_file_0 -output ./diagnosis_results/failure_file_0.diag
diagnose failure failure_files/failure_file_1 -output ./diagnosis_results/failure_file_1.diag
diagnose failure failure_files/failure_file_2 -output ./diagnosis_results/failure_file_2.diag
diagnose failure failure_files/failure_file_3 -output ./diagnosis_results/failure_file_3.diag
diagnose failure failure_files/failure_file_4 -output ./diagnosis_results/failure_file_4.diag
diagnose failure failure_files/failure_file_5 -output ./diagnosis_results/failure_file_5.diag
diagnose failure failure_files/failure_file_6 -output ./diagnosis_results/failure_file_6.diag

Figure 16: YieldAssist example dofile

Conclusion
This application note showed an example flow of using multiple DFT tools to implement a test
strategy for an example design that included memories and logic. It can’t be stressed enough that
a good test plan should be put together at the beginning to ensure that a smooth process and the
highest possible test quality can be attained. The tools are quite flexible and powerful and can
handle the tasks that you require of them. The example testcase available from our website is a
good tool to use to get familiar with the tools and their capabilities within a sample design flow.

01/26/2007 Page 18 of 18