RuChip design flow, Dec 2012

DFT

DESIGN FOR TEST

1.1 Testability and Design For Test (DFT)

The testability is a design parameter that deals with the creation of an "easily testable" design:
a design for which test patterns can be generated with a reduced cost, by making the internal
nodes controllable and observable. Before we ship a design to customers, it has to be tested
using several techniques. The better is the coverage of the pattern we apply, the better is the
level of quality that we ship to customers. Applying test vectors and achieving high coverage
levels is more and more complicated as along as the complexity of the devices is increasing,
and require well defined Design For Testability (DFT) methodologies to be though of from the
very beginning of the device.
Design For Testability techniques can be classified into two categories:
structured techniques: based on a set of design rules that must be used at the design level and
on design automation. This includes Scan techniques, Built-In Self Test (BIST), JTAG
Boundary Scan, Automatic Test Pattern Generation (ATPG), etc.
ad-hoc techniques: specific design changes in order to ensure better controllability and
observability of internal nodes by implementing a set of specific techniques like: adding extra
control pins, breaking feedback loops, adding specific test mode, observing through XOR
clouds, testing design parts with embedded software...
Because Time to Market becomes a key issue in the industry, we cannot afford to rely on adhoc techniques because they are not automated, are more design-dependent and therefore
require the designer's expertise. So, we highly recommend the use of automated DFT insertion
tools: the consequence is a specific set of design rules for this methodology that are to be
obeyed.

1.2 Test Coverage

The Test Coverage is a figure that measures the test quality. It measures the percentage of tested
faults among all the possible faults, it is given by the figure:

Test Coverage =

# non defective parts

# parts shipped to customer

The question is how to evaluate the Test Coverage as it is still based on Customer Return? We
Confidential

RuChip design flow, Dec 2012

DFT

need to evaluate an image of the Test Coverage before shipping the pieces to the customer.

1.3 Minimising Customer returns

The Browne-Williams formula give a relation between Process Yield, Defect Level (in PPM Part Per Million) and Test Coverage (as defined above).

DL
120000

(1-TC)
DL=1-Y

100000

DL=Defect Level (PPM)

TC=95%

Y=Process Yield

80000

TC=Test Coverage
TC=97%

60000
TC=99%
40000

20000

10.0

20.0

30.0

40.0

50.0

60.0

70.0

80.0

90.0

Yield %

The formula shows well that if you have a poor process yield (new technology), you should
have an excellent Test Coverage in order to trust the "good" parts (the parts tested as good).

1.4 How to reach a good Test Coverage

We can reach a good Test Coverage by attempting to test all possible "defects", these defects
being modelled using "fault models". Therefore, the complete fault list is related to many
Confidential

RuChip design flow, Dec 2012

DFT

possible defects and the Test Coverage includes the contribution of many factors: the
functionality coverage, the Single Stuck at fault coverage (provided by scan ATPG), the Iddq
fault coverage (based on pseudo stuck-at fault model or bridging fault model), the at-speed test
coverage (based on the transition Fault or the Path Delay fault models), etc.

# Faults

100 %
Burn-In / Life tests

At-speed test

Iddq test

Voltage test (functional + Scan ATPG)

# Vectors

In order to reach a good test coverage, different test techniques need to be used. Each technique
covers a specific aspect, linked to some specific "defects". See the figure below that highlights
how the faulty devices are classified depending on the test involved.

1.5 Understanding Tester constraints

The designer needs to be aware of the way in which the tester works, and the things that have
to be taken into consideration to ensure that vectors can be ported easily, to ensure that the
vectors actually produce a meaningful test on the tester.

Confidential

RuChip design flow, Dec 2012

1.5.1

DFT

Probe Test

Probe test is used to screen out the good and bad die. It can be an expensive mistake to package
devices which might fail at final test, due to the cost of packaging. As the electrical environment
is a little less controlled, the program is usually run with relaxed voltage levels and timings. The
test patterns would be the same as those used in the final test program.

1.5.2

Final Test

Final test is used to screen out parts damaged by the packaging process and parts which do not
meet the full specifications of the datasheet. This is where a combination of structural and
functional tests ensure the integrity of the device. DC specifications such as power supply
current consumption, leakage, and output drive capability are tested. AC specifications such as
speed grading and datasheet parameters are verified. The functional test patterns would
effectively run real code in real time on the device, while at the same time verifying that the
response of the device does not deviate from the expected (stored) response. The test patterns
used for AC verification are usually more complex in the way that the timings are defined, and
a number of "edge sets" may need to be employed.

1.5.3

Characterisation

Required to establish how well the device works in relation to the preliminary datasheet. Both
the DC and AC parameters are measured. Compare this to final test where the same (or a subset)
of these parameters are tested go/nogo. Characterisation is required to generate reports which
allow the device to reach ML20 and ML30. A set of functional patterns are run in order to
determine the FMAX (maximum operating frequency) of specific parts of the device to ensure
that the device can operate at the specified frequency.

1.5.4

Device Debug

Once a specific device problem or bug has been identified, the tester can be a very flexible way
of controlling the device in order to determine the cause of the problem.

1.5.5

Test Vector Issues

Test vector memory is very precious. Normally one clock cycle in the simulation will translate
to one test vectors worth of data, however the J971 (in common with many other testers) allows
the data from one test vector to be repeated for a specified number of cycles. If for example in
a simulation there was no activity on the device pins for say ten cycles before the next read or
write, this could be compressed in to a single line of test vector data with a "rep 9" opcode.
Confidential

RuChip design flow, Dec 2012

DFT

In fact it is quite common for the data in one cycle to be the same as the next, and this results
in a significant saving of test vector memory. It can be seen that for a given number of clock
cycles in the pattern as a whole, then the less activity on the device pins the more the vectors
can be reduced by means of using repeat opcodes. However should there be a signal which
changes every few cycles, then the actual number of test vectors used will not be too different
from the total number of cycles.
Note that a clock (generated by using RTZ format) actually has vector data which determines
whether it is on or off, and it is the formatting which determines the shape of the signal. If the
clock is on in every cycle in the pattern, then the vector data for this pin will always be ', and
therefore is compressible using repeat opcodes. The goal is to have only one Edgeset used for
the whole pattern.

1.6 Functional test

The design functionality needs to be exhaustively verified. A block-by-block approach can help
to validate the different design functionalities: it relies on the design partitioning in order to
isolate design blocks and fully control and observe their Inputs and Outputs. Specific test
modes need to be defined in order to access the design blocks, and simulations should be run
to verify these modes.

1.7

At speed test

A functional test cannot always be ran at system speed on the tester because most of the times
the tester is slower than the system. This is why a set of patterns need to be given in order to
check that the device will still be functional when used "at-speed".

1.8

Manufacturing test

The functional tests verify that the design matches his specifications. The Structural tests verify
that the design is well manufactured. For example, a design can be functional and contain
manufacturing defects: it will be rejected because of quality standards. A device that contains
manufacturing defects has great chances to have a breakdown during his life (this means: it will
be no more functional).
Manufacturing defects might remain undetected by functional testing yet cause undesirable
behaviour during circuit operation. To provide the highest-quality products, development
teams must prevent devices with manufacturing defects from reaching the customers.
The structural testing can be split into two parts: the test of the random logic (full custom,
synthesized logic) and the test of regular structures (RAMs, ROMS, FIFOs, PLAs... requiring
specific test algorithms).

Confidential

Scan

DFT

Bist

Logic

Logic

Cores & Blocks

Logic

Memory Arrays

Random Logic

RuChip design flow, Dec 2012

Logic BIST

JTAG

1.9 Structural tests of random logic

The random logic (mostly synthesized logic in semi-custom devices) needs to be tested for
manufacturing defects: it implies many fault models that are complementary approaches.

1.9.1

The Single Stuck At fault model

The Single Stuck-At fault model is the most common used fault model in the industry. It models
that a node is permanently put to the level 0 (stuck-at zero) or to the level 1 (stuck-at one).
In order to detect stuck-at zero on a node of a circuit, we need to control the state 1 on this node,
and then observe that we have "zero instead of one" on this node. This task can be automatized
in order to generate automatically Test Patterns using an Automatic Test Pattern Generator
(ATPG).

1.9.2

Full Scan and ATPG

The Full scan methodology creates a partition in the design by chaining all the Flip Flops into
a big shift register. This method adds control ability and observability of all internal states of
Confidential

RuChip design flow, Dec 2012

DFT

the design.
The goal of scan design is to make a difficult-to-test sequential circuit behave (during the
testing process) like an easier-to-test combinational circuit. Achieving this goal involves
replacing sequential elements with scannable sequential elements (scan cells) and then
stitching the scan cells together into scan registers, or scan chains.
Among all the test techniques, Full Scan methodology is highly recommended (Partial scan
techniques are more difficult to use and to validate, and they require the designer experience).
Full scan is the easiest, the fastest and the most robust way to generate automatically Test
Patterns that cover the stuck-at faults, because a combinational ATPG can be used.
Full scan has many benefits: highly automated, predictable, easy to use... It is the best way to
achieve the test coverage target (100% for stuck-at faults). See the scan representation below:

SCAN CHAIN
P
r
i
m
a
r
y

combinational
block

combinational
block

P
r
i
m
a
r
y
O
u
t
p
u
t
s

I
n
p
u
t
s

For full scan, please follow these basic recommendations:

The scan style should be Multiplexed Flip Flop.

Dedicated scan_out Scan Flip Flops must be used in the design netlist for ALL Flip Flops.
This will ease the Front End to Back End flow and allow easy scan-reordering. Those Flip
Flops are available in the libraries with the "T" suffix.

The number of scan chains should be maximised accordingly with the number of inputs
and outputs available in the circuit. This is to reduce the test time.

Confidential

RuChip design flow, Dec 2012

DFT

1.9.3 IDDQ coverage

The IDDQ test consists in measuring Quiescent current when the circuit is in a Stand-by mode.
If the current is above a certain limit, then the circuit FAILS the IDDQ test and is rejected. This
enables to detect some defects that are not covered by other forms of test (such as bridging
faults, leakages...)
The IDDQ vectors can be automatically generated using an ATPG which will control the circuit
state by controlling the state of all the sequential elements (through scan) and the observation
is done through a current measure. This technique is also called Scan-Iddq and is highly
automated when full-scan is used. The figures given by the ATPG deal with the coverage of
these IDDQ test patterns: the computation is often based on the PSEUDO STUCK-AT fault
model.
The second step is then to simulate the vectors generated by the ATPG using a tool that can
help to select the best candidates for IDDQ coverage (e.g: PowerFault)

1.10 Structural tests of regular structures

The regular structures (like RAMs, ROMs, PLAs...) require a more exhaustive test than only
Stuck-at fault testing. Other kinds of faults (such as coupling faults) may occur and require
specific test patterns

1.10.1 Single Stuck At fault coverage, coupling faults.

If we take the example of a RAM, many faults must be tested. The most widely used test
algorithms are "March" algorithms. For instance, the March algorithm called "Marinescu 17N"
will detect the following faults in the RAM structure:

Stuck at of Cells - a particular location is fixed at logic one or logic zero.

Stuck open - a cell is disconnected to the data line.

Cell Coupling - writing to one location writes the same or inverse value to
one or more other locations.

Address decoder malfunction. Decoder does not address the correct cell but
possibly some other cells, or the Decoder addresses several cells including
the correct one.

Confidential

Read/Write Amplifier malfunctions. Stuck-at of Read/Write command.

Stuck-at, open, shorts of Data bus.
8

RuChip design flow, Dec 2012

DFT

The test algorithm can be applied from an external tester (Direct Memory Test - or DMT) or
from an embedded design block (Built In Self Test - or BIST).

1.10.2 Built In Self Test (BIST)

The BIST is a design block that implements a test algorithm in order to test the embedded
memories. A single BIST can be used for each RAM (or the same BIST can be shared to test
several RAMs). The BISTs can be launched from the standard JTAG TAP controller
instruction called RUNBIST.
The BIST generates a status to tell if the test was successful or not, which can be brought out
of the circuit using the JTAG interface.
The BIST can be tested using scan techniques (as it becomes part of the Random logic). A
specific input from the BIST is used in scan test mode in order to Bypass the memories to avoid
the propagation of unknown states in the circuit during scan operations.
The advantages of BIST are to run at-speed testing of the memory, to protect intellectual
property, to enable Test re-use, to help gain test time on the tester. The drawbacks are some
delays introduced on the functional paths and some silicon area.

1.10.3 Direct Memory Test (DMT)

If a Bitmap analysis is requested or if the test algorithm is not mature enough to be implemented
in a BIST, the DMT (Direct Memory Test) is an efficient solution. It is often used at an early
technology phase.
The DMT consists in isolating the Memory in order to be able to apply any test pattern. The
most classical approach is the MUX isolation as shown below:

Confidential

RuChip design flow, Dec 2012

DFT

34

from primary inputs

from design

MUX

4Kx16

16

MUX
16

from design

4Kx16

16

to primary outputs

MUX

MUX
16
MUX
from design

16

4Kx8

4Kx8

DMT2

MUX

DMT

from design

DMT1

Confidential

10

RuChip design flow, Dec 2012

DFT

1.10.4 BURN IN testing

Life Test consists in tracking defects that appear after some time of usage of the circuit. It
consists mainly in using the BurnIn technique: the circuit is put in an oven and tested after some
time. Two techniques are used for Burn In:
Static Life Test: the chip is only powered but not running
Dynamic Life Test: the chip is running and has activity in
most of its internal nodes.
For the purpose of Dynamic Life Test, a BurnIn controller can be used in order to launch BIST
test cycles in loop, and therefore activate the memories of the complete design (creating internal
nodes activity).

1.11 Test Modes definition and management

A top level test-controller is often needed in order to drive the different Test Modes (scan,
BIST, Iddq, Core Isolation, etc.). This test controller could be obtained using a TAP controller,
as well as a user defined test controller.

1.11.1 JTAG TAP controller

Once the scan-netlist is certified to have a good Single-Stuck-At fault coverage, a good Iddq
fault coverage, BIST and BurnIn controller inserted, the JTAG TAP controller can be inserted
in the design in order to drive the different test modes.
JTAG can be used for TEST controller management, but also for Boundary Scan insertion
(useful for core isolation, board level testing, etc.).

1.11.2 Defining the different test modes

See an example of different test modes that can be defined for a given circuit below. Of
course, there can be many other instructions defined depending on the tested design.

Confidential

11

RuChip design flow, Dec 2012

JTAG INSTRUCTION

DFT

BINARY
CODE

EFFECT ON THE DESIGN

BYPASS

11111 m a n d a t o r y i n s t r u c t i o n

EXTEST

00000 m a n d a t o r y i n s t r u c t i o n

SAMPLE/PRELOAD

00001 m a n d a t o r y i n s t r u c t i o n

IDCODE

00010 r e t u r n s t h e c h i p ID

SCAN TEST MODE

01000 * c o n f i g u r e s m u x e d I O s f o r
scan path
* Bypasses b l a c k b o x e s ,
PLLs...

SCAN-IDDQ TEST MODE

01011 * D i s a b l e s DC- P a t h s , Pu l l
Ups..

BIST MODE

01001 l a u n c h e s a l l B I S T s
*outputs a global status
*outputs all the Bfail signal
f o r debug

BURNIN TEST MODE

01010 * l a u n c h e s B I S T s i n l o o p
through the BurnIn controller
*outputs a global status

DMT MODE

11010 * E n a b l e s t o a c c e s s d i r e c t
Memory Test (DMT) f r o m
p r i m a r y IOs

CORE ISOLATION MODE

11011 * E n a b l e s t o i s o l a t e t h e c o r e s
for block-by-block functional
t e s t i ng

Confidential

12

RuChip design flow, Dec 2012

DFT

2- DFTKIT OVERVIEW
2.1

Purpose of the DftKit

Many tasks are needed to be run in order to obtain good Test Coverage, and most of them can
be automated in a Design Flow. The goals of DftKit are various:

2.2

to create a Frame Work for DFT insertion in a design

to automate repetitive design phases in order to let the designer focus

on real design for test issues. Defining a common Design For Test
methodology that can be re-used by other design teams

to recommend standard DFT flows for Test Coverage improvement.

DftKit flow overview

The DFT methodology defined with the DftKit is as much as possible independent from the
tools that will be run (internal or external tools).
Many tasks are needed to be run in order to obtain good Test Coverage, and most of them can
be automated in a Design Flow. DftKit can be used to:

define a DFT flow composed of different tasks

change or delete the flow tasks

save the flow sequence in a dofile

execute the flow

The figure below shows the tasks that are integrated in DftKit.

Confidential

13

RuChip design flow, Dec 2012

DFT

Design
SYNTHESIS
ATPG

Fault
Simulation

Gate level
Vectors

Memory BIST
Insertion

TAP controller
insertion
FC Target

Netlist
Netlist
Preparation

Gate
Burnin
BIST Controller

DFT rules
checking

Patterns
Simulation

EDIF
Utile

Test
Preparation
ATPG IDDQ

Vectors

Scan Chain
Insertion

DFT rules
checking

Confidential

FC Target

To
UTILE
System

IDDQ Patterns
Verification

14

RuChip design flow, Dec 2012

DFT

2.3 Design Setup Phase

The DftKit flow will ran on a complete design database that is verified in the first phase. This
database is created after the Design_Setup phase.
Methodology
Definition

Design
EDIF
Verilog

Memory

Memory

Memory

Design SETUP

Random
Logic

2.4 Design Setup Phase Overview

The Design Setup phase of the DftKit can be detailed in the following sub-tasks

Check Netlist: The netlist is verified against the Library

Library verification
- Verilog views
- DFT Views (e.g: Sunrise, SNPS, TetraMAX, Formality,...).

Automatic memory identification: the memories are automatically identified

and traced into a file for later automatic BIST and BurnIn insertion

Automatic translation of the netlist into VERILOG in case of a different input

netlist format (in this case, SNPS views are needed).

Confidential

15

RuChip design flow, Dec 2012

DFT

3 - MEMORY BIST GENERATION

3.1 Built In Self Test generation strategy
There is one corresponding BIST for each memory. If several different memories exist in the
design, several different BISTs should be generated.
The memory BIST generation task is optional. It allows to generate automatically each memory
BIST and run its synthesis.
In case the BISTs are already generated and synthesised, you can skip this task. But please
verify that the database generated is compliant with DftKit (consistent ".net" files should exist).
See the design below:

Confidential

16

RuChip design flow, Dec 2012

Methodology
Definition

DFT

Memory
Definition

Design

Memory BIST
Generation

BIST

BIST

Memory

Memory

Memory

Design SETUP

Random
Logic

BIST

BIST Ctrl

BIST Diagnostic

3.2 BIST generation task overview

The BIST generation task of DftKit can be detailed in the following sub-tasks

Generate the BIST for one memory

Generates .synopsys_dc.setup file automatically

Run the BIST synthesis including the scan insertion

Confidential

17

RuChip design flow, Dec 2012

3.3

DFT

DftKit analysis

DftKit analyses during the setup phase the design and recognize automatically all memories.
That allows to preset some parameters for the BIST generation step: number of words, of bits
for the memory, memory type, BIST name...

3.4

BIST generation

There are different ways to generate one BIST for a memory. These ways are defined by a set
of option. For example, you can generate a BIST which includes or not the bitmap capability.
The main option capabilities are:
scan collar (diagnostic capabilities)
burnin (life test capability if asked by the customer)
mask bit (in case if the memory include a mask bit)
redundancy (in case Design For Manufacturing asks for redundancy on memories)
bypass (capability to choose the bypass type)
tristate output (capability to choose the tristate management)
shared BIST (capability to share one BIST machine between many identical
memories)
reset (capability to choose the reset type)
bitmap (capability to include inside the BIST a bitmapping engine)

4- MEMORY BIST INSERTION

4.1 Built In Self Test insertion strategy
The memory BIST insertion strategy consists in replacing a non-BISTed memory by a BISTed
memory, in a transparent way to the user.
See the design below:

Confidential

18

RuChip design flow, Dec 2012

Methodology
Definition

DFT

Memory
BIST
generation

Design

Memory BIST

BIST

Memory

Memory

Memory

Design SETUP

BIST

Memory
BIST
insertion

Random
Logic

BIST

BIST Ctrl

4.2

BIST Diagnostic

BIST insertion task overview

The proposed solution consists of a DftKit environment evolution allowing to support various
memory BIST architectures.
The emphasis will be on the integration and the automatic BIST generation and connection
(assumes that BIST algorithms and BIST techniques are known).
However, a common framework for the existing BIST approach(s) will be very helpful and will
provides an "approach-independent" solution.

Confidential

19

RuChip design flow, Dec 2012

4.3

DFT

Common Framework

By common BIST insertion framework, we mean the following:

Common DFT environment for memory BIST insertion and connection
Support various BIST architectures in a transparent way. The framework should
be open to support additional and new BIST solutions.
Support coherent BIST generation structure. Library approach is supported,
however, the system will allow "on-the-fly" BIST generation (previous DftKit task)

4.4 BIST architectures

In order to achieve a common BIST framework, the DFT environment will be based on BIST
architectures rather than BIST generators.
In the first step, 2 architectures are identified:
Architecture Type 1

We define the architecture of type 1 as follows:

MEMORY

BIST

Confidential

MEMORY

MEMORY

BIST

20

RuChip design flow, Dec 2012

DFT

In this architecture, BIST consists of generator and comparator in the same block. The BIST is
interfacing with the rest of the design. The BIST could be used one memory or shared between
many memories.
Architecture Type 2 This architecture implements collared memories and separate engine.

MEMORY

MEMORY

MEMORY

Collar

Collar

Collar

Engine 1

Engine 2

The engine consists of the pattern generation part of the BIST. It drives the memory collars and
manages the BIST responses. The engine could drive one or many memory collars.
The memory BIST components are defined as a library-based structure. BIST HW blocks are
generated during the Memory cut generation, accordingly with the desired BIST architecture.

4.5 BIST components generation

BIST components can be pre-generated at memory generation level using a "library data
structure" approach.
"On-the-fly" BIST generation will be possible as describe in the previous task (BIST
generation).

Confidential

21

RuChip design flow, Dec 2012

DFT

4.6 BIST connection (Wire-up step)

4.6.1

BIST connection overview

In order to perform the proper wiring-up, the BIST insertion tool requires a <.net> file.
This file mainly defines the BIST connection signals, the pins to be added for BIST operation,
the scan pins (if necessary), the way to put the BIST in functional mode.
There are two kinds of signals:

signals that will be connected automatically (address bus, in and out

data bus, wen ,csn, clock(s)...)
BIST control and status signals (RBACT, TM, BEND...). There are
many ways to manage these signals: from design top level, from a
TAP controller, from a specific test controller. The user can defined
that. The default is to connect these signals to design top level. But
the user can give any point defined by its hierarchy and pin name.

The <.net> file is created during the BIST generation step.

The BIST signal wiring-up can be performed at different levels.

4.6.2

Wire up error detection

For all bits of type 2 (control and status signals), the user can define any connection. In order
to avoid mistakes, some error sources are tracked by DftKit:

consistency between .net file and the memory module inside the design

by default, outputs can not be connected to more than one net

pin names consistency are check at all hierarchy level, with automatic
renaming if needed

5- DRC
5.1 Design Rule Checking strategy
The DRC strategy consists in verifying that you can replace a non-scanned design by a full scan
design, in a transparent way to the user, without changing the functionalities. That means
change flip flops into scan flip flops, add signals and pins for scan control...

Confidential

22

RuChip design flow, Dec 2012

DFT

See the design below:

Methodology
Definition

Memory
Definition

Design

Memory
BIST

BIST

BIST

Design
Rules
Check

SCAN
Insertion

Random
Logic

Memory

Memory

Memory

Design SETUP

BIST

SCAN Out

SCAN Out

SCAN Ctrl

BIST Ctrl

BIST Diagnostic

5.2 DRC task overview

The DRC task of the DftKit can be detailed in the following sub-tasks:

Generates.synopsys_dc.setup automatically

Runs the DRC for testability and reports the errors if any. The DRC
checked are for scanability, and testability.

Confidential

23

RuChip design flow, Dec 2012

DFT

6 - SCAN INSERTION & DRC

6.1 Scan Insertion strategy
The memory SCAN insertion strategy consists in replacing a non-scanned design by a full scan
design, in a transparent way to the user. The signals added by the SCAN insertion tool are wired
up to the primary inputs and outputs of the design.

6.2 SCAN insertion task overview

The scan insertion task of the DftKit can be detailed in the following sub-tasks :

Generates .synopsys_dc.setup automatically

Inserts the scan chains and save the protocol file and netlist with scan for
later usage with various ATPGs

7 - ATPG INTEGRATION
7.1

ATPG strategy

An ATPG is a tool that automatically generates TEST PATTERNS for a design. It can be based
on different type of fault models, such as Stuck-At, transition.
The ATPG strategy consists in running the ATPG on a full-scan netlist and reporting the fault
coverage.

7.2

ATPG task overview

The ATPG task of the DftKit can be detailed in the following sub-tasks :

Select a faultlist OR create a new one (insert stuck at faults on the netlist).

Generate Test Patterns for this faultlist and the corresponding report.

Save the testbench in Verilog format or / and the patterns in WGL or

STIL
format (optional).

Save the faultlist (optional).

report the Untested faults.

Confidential

24

RuChip design flow, Dec 2012

DFT

8- ATPG-IDDQ INTEGRATION
8.1

ATPG IDDQ strategy

An ATPG is a tool that automatically generates IDDQ TEST PATTERNS for a design. It can
be based on different type of fault models, such as Pseudo Stuck-At or Toggle.
The ATPG strategy consists in running the ATPG on a full-scan netlist and reporting the fault
coverage. Specific check is done by the tool to verify the Iddq compliance.

8.2

ATPG IDDQ task overview

The ATPG IDDQ task of the DftKit can be detailed in the following sub-tasks :

Insert Pseudo Stuck at faults on the netlist.

Generate Test Patterns for this faultlist and the corresponding report.

Save the testbench in Verilog format or / and the patterns in WGL or

STIL
format (optional).

Save the faultlist (optional).

report the Untested faults.

9 - TAP CONTROLLER INSERTION

9.1 TAP controller insertion strategy
The TAP controller can be used to drive the different Test Modes of the design, and test the
interconnection with the pads. It can be automatically generated by commercial tools. The TAP
insertion strategy consists in inserting the TAP controller on top of the netlist with DFT inserted
and connect the TAP modes to the mode control signals.
See the design below:

Confidential

25

BIST

DFT

Random
Logic

Memory

BIST

Memory

Memory

RuChip design flow, Dec 2012

BIST

SCAN Out

SCAN Out

SCAN Ctrl

TAP

BIST Ctrl

9.2 TAP controller task overview

The TAP controller task of the DftKit can be detailed in the following sub-tasks :

Define the Test Modes as instructions for the TAP controller.

Generates the JTAG TAP controller and inserts it into the netlist.

Automatically connect the TAP controller test modes pins to the control
signals of the design test modes (scan, BIST, BurnIn, etc.).

report the values to program in order to switch to the test modes.

Confidential

26

RuChip design flow, Dec 2012

DFT

10 - IDDQ VALIDATION INTEGRATION

10.1 IDDQ Validation strategy
The target of this task is to achieve two main parts. The first one is a verification of Iddq
patterns: Iddq rules checking and classical simulation verification due to a simulator linked
with an Iddq tool (compiled PLI). The second one is a selection of the best candidates for the
best Iddq coverage. Please, note that at this moment the second part is not yet implemented,
even if the complete database is generated.
The Iddq Validation strategy consists in running a verilog simulator on a full-scan netlist with
the patterns coming from the ATPG IDDQ task.

10.2 IDDQ Validation task overview

The IDDQ Validation task of the DftKit can be detailed in the following sub-tasks :

Purpose a time scale.

Read and compile the libraries and netlist(s).

Initialize the Iddq header file.

Managed the SDF (back end annotation file) automatically (optional).

Load the simulation testbench (stimuli).

Run the simulation.

Create a VCD file (optional).

11 - FAULT SIMULATION INTEGRATION

11.1 Fault simulation strategy
A Fault Simulator is a tool that calculates the test coverage and fault coverage of a design for a
set of patterns.
The fault simulation strategy consists in running the fault simulator on a netlist and reporting
the fault coverage of the corresponding patterns.
The inputs are the netlist, the corresponding libraries, the set of patterns to fault simulate.
Optionally, you can give the fault list (list of fault which are injected in the design). If you do
not put any fault list, the tool will create a new one by injecting faults on all the inputs / outputs
of all the gates for the netlist.
The output is a report which gives the fault and test coverage, the class of faults, the number of
Confidential

27

RuChip design flow, Dec 2012

DFT

patterns... Optionally, you can write the resulting fault list in order to go in an incremental mode
(run an ATPG or a new fault simulation after).

11.2 Fault simulation overview

The fault simulation task of the DftKit can be detailed in the following sub-tasks :

Select the patterns which will be fault simulated (from a previous task of
DftKit (ATPG for example) or functional ones in WGL or VCD format).

Select the fault list OR create a new one (with the stuck at faults model).

Simulate the pattern to verify that the expected values are the obtained
ones.

Fault simulate the patterns to obtain the report.

write the report and optionally the resulting fault list.

User can load in the same task many different patterns files (in the same format). This is called
the multi pattern mode. In this case, only the simulation and fault simulation is repeated for each
file. The libraries and netlist(s) reading and compiling step is done only once.

12 - SIMULATION INTEGRATION
12.1 Simulation strategy
The target of this task is to verify the patterns generated by a DftKit ATPG previous task. It can
also be used for the simulation of any external stimuli.
The simulation strategy consists in running a verilog simulator with the patterns chosen by the
user.

12.2 Simulation task overview

The simulation task of the DftKit can be detailed in the following sub-tasks :

Purpose a time scale.

Read and compile the libraries and netlist(s).

Managed the SDF (back end annotation file) automatically (optional).

Load the simulation testbench (stimuli).

Run the simulation.

Create a VCD file (optional).

Confidential

28

RuChip design flow, Dec 2012

DFT

13 - EDIF OUT INTEGRATION

13.1 Edif out strategy
The target of this task is to generate an Edif netlist ready for the back end. It also get the scan
chain file.
The edif out strategy consists in running a a tool which can translate the verilog netlist into an
Edif one.

13.2 EDIF out task overview

The Edif out task of the DftKit can be detailed in the following sub-tasks :

Read the verilog netlist.

Create the links between the different blocks.

Write the netlist in Edif format.

Create a link to get the scan chain file.

Confidential

29