design for test

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 ad-hoc 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 = customer toshipped parts #

parts defectivenon #

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

Confidential 1


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

Yield %

20000

40000

60000

100000

80000

120000

10.0 20.0 30.0 40.0 50.0 60.0 70.0 80.0 90.0

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

TC=95%

TC=97%

TC=99%

DL=1-Y DL=Defect Level (PPM)Y=Process Yield TC=Test Coverage

(1-TC)

Confidential 2


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.

Voltage test (functional + Scan ATPG)

Iddq test

At-speed test

Burn-In / Life tests

100 %

# Vectors

# Faults

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 3


1.5.1 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 4


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 5


Cores & Blocks

Mem

ory

Arr

ays

Ran

dom

Log

ic

Logi

c

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

Scan Bist

JTAG

Logi

c

Logi

c

Logic BIST

Confidential 6


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

combinational block

combinational block

P r i m a r y I n p u t s

P r i m a r y O u t 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 7


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.

Read/Write Amplifier malfunctions. Stuck-at of Read/Write command. Stuck-at, open, shorts of Data bus.

Confidential 8


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 9


MUX

MUX

MUX

MUX

4Kx16

4Kx16

4Kx8

4Kx8

MUX

MUX

from design

from design

from design

from design

from primary inputs

16

16

16

to p

rimar

y ou

tput

s

34

16

16

8

8

DM

T

DM

T1

DM

T2

Confidential 10


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


JTAG INSTRUCTION BINARYCODE

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 s c a n p a t h * B y p a s s e s b l a c k b o x e s , P L L s . . .

SCAN-IDDQ TEST MODE 01011 * D i s a b l e s DC- P a t h s , Pu l l U p s . .

BIST MODE 01001 l a u n c h e s a l l B I S T s * o u t p u t s a g l o b a l s t a t u s * o u t p u t s a l l t h e B f a i l s i g n a l f o r d e b u g

BURNIN TEST MODE 01010 * l a u n c h e s B I S T s i n l o o p t h r o u g h t h e B u r n I n c o n t r o l l e r * o u t p u t s a g l o b a l s t a t u s

DMT MODE 11010 * E n a b l e s t o a c c e s s d i r e c t M e m o r y T e s t ( D M T ) f r o m p r i m a r y I O s

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 f o r b l o c k - b y - b l o c k f u n c t i o n a l t e s t i ng

Confidential 12


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:

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.

2.2 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


Design SYNTHESIS

ATPG Fault Simulation

Memory BIST Insertion

Burnin BIST Controller

DFT rules checking

Scan Chain Insertion

DFT rules checking

FC Target

Patterns Simulation

ATPG IDDQ

FC Target

IDDQ PatternsVerification

TAP controllerinsertion

Netlist Preparation

Test Preparation

To

UTILE System

Netlist

Vectors

Vectors

EDIF Utile

Gate

Gate level

Confidential 14


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

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).

Design SETUP

EDIF Verilog

RandomLogic M

emor

y M

emor

y

Mem

ory

Confidential 15


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


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

BIST


Design SETUP

Random Logic

Mem

ory

Memory BIST Generation

Memory Definition

BIST

Mem

ory

BIST

Mem

ory

BIST Ctrl BIST Diagnostic

Confidential 17


3.3 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.


Confidential 18


4.2 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.

BIST


Design SETUP

Random Logic

Mem

ory

Memory BIST

Memory BIST

insertion

Memory BIST

generation

BIST

Mem

ory

BIST

Mem

ory


Confidential 19


4.3 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

MEMORY

MEMORY

BIST BIST

Confidential 20


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

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).

Engine 1

Engine 2

Confidential 21


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 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 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



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.

Methodology Definition

BIST

Design

Design SETUP

RandomLogic

Mem

ory

Memory BIST

BIST

Mem

ory

BIST

Mem

ory

Memory Definition


Design Rules Check

SCAN Insertion

SCAN Ctrl

SCAN Out

SCAN Out

Confidential 23


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


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.


Confidential 25


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.

BIST

RandomLogic

Mem

ory

BIST

Mem

ory

BIST

Mem

ory

BIST Ctrl

SCAN Out

SCAN Out

TAP

SCAN Ctrl

Confidential 26


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


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


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

design for test

Documents