Cell-Based IC

Scan Path Insertion and Automatic Test

Pattern Generation
This Engineering Application Note
(EAN) describes the full Scan Insertion
and the Automatic Test Pattern Generation (ATPG) flow supported by Atmel.
This Application Note contains specific
design guidelines for circuits which are
suitable for scan path insertion and
ATPG. For more general design guidelines, to ensure compliance with Atmels fabrication and test requirements,
see the document: Atmel CBIC Design
Guidelines.
Partial Scan Insertion is not covered by
this Application Note.

Input formats can be either Edif (for any

design transfer) or Verilog (for simulation only, not for final design transfer),
based on Atmel CBIC Libraries.
All steps in the flow may be executed at
the customers site. Alternatively Atmel
Technical Support Centres (TSCs) may
perform vector generation and/or scan
insertion as a service. Details are to be
agreed with the TSCs. In either case,
the checkpoints shown in the flow diagram (Figure 1) exist and are used for
accepting or rejecting the start of the
following step.

Cell-Based
IC (CBIC)
Application
Note

The flow described here is based on

the Test Compiler software tools from
Synopsys.

Scan Path Insertion and Automatic

Test Pattern Generation

WARNING! USE THE STYLE SHEET

THAT CAME WITHIN THIS DOCUMENTS DIRECTORY. CHANGE THE
TEXT OF THIS MESSAGE TO WHITE
BEFORE PRINTING, THEN REVERT
BACK TO BLACK BEFORE ARCHIVING.

0702A

7-77

Figure 1. Design Flow for Scan Path Insertion and ATPG

ATPG
Design
Rules

Design
For
Functionality

Functional
Simulation
(Functional Netlist)

Modify
Design

ATPG
Design Rules
Check
Fail
Pass
Full
Scan Path
Insertion

Incremental
Optimisation
(Optional)

Functional
Simulation
(Modified Netlist)
Fail
Pass
ATPG Vector
Generation &
Coverage Assessment

Full Timing
Simulation of
ATPG Vectors

ATPG Vector
&
Coverage Approval
Fail
Pass
Placement
and
Routing

Standard ATMEL CBIC Design Flow

7-78

Cell-Based IC

Cell-Based IC
ATPG Design Rules
The design rules listed below are automatically checked
by the Synopsys Test Compiler prior to scan path insertion and/or automatic test pattern generation:

3. Force the Megacell (including BIST) inputs to a known

state and then expect a known state on the Megacell (including BIST) outputs:
set_test_require <value> {pins list}

- Design rule warnings may cause some cells to be

treated as black boxes and will reduce the fault coverage
of the design.

is used to force a value on given pins.

- Errors and warnings must be fixed to achieve a good

fault coverage.

eg: set_test_require may be use to force 0 on the two

entries of a multiplier. The expected output is also 0.

The Scan Path Insertion/ATPG Design Rules

set_test_assume is used to set the output of the multiplier to 0.

* Clock and enable signals must be directly controllable

from top level input ports.

set_test_assume <value> {pins list}

is used specify a value on the output of black box.

* Latches:

* All sequential elements must have a scan equivalent

(SFFxx). In the case of design synthesis by Synopsys,
use libraries as defined in the Atmel Synopsys CBIC Synthesis Guide.

Latches are not supported in the combinational ATPG

used with full scan designs and are considered as black
boxes. Latches must be replaced, if possible, by D-type
flip-flops.

* All sequential elements connected to the same external

clock signal must be triggered by the same clock edge. A
separate scan chain must be defined for the sequential
elements connected to each external clock.

* Gated clock:

* No forks are allowed in a scan chain.

* A Test Mode may be defined in the design to ensure
compliance with the design rules for problems like:
- gated clock
- different clock edges
- clock used as data input
- asynchronous set and reset not controllable.
The result will be a slight loss in fault coverage but it will
allow the cells not to be considered as black-boxes.
* Megacells, analogue cells and other special cells:
Megacells, analogue cells and special cells are considered as black boxes. The internal circuitry of a Megacell
is not covered by the ATPG tool. To ensure a high coverage of the Megacell, BIST circuitry must be used.
Megacells have no logic definition in the ATPG library and
are treated as black boxes. This creates a shadow effect
in the design, produces internal X states and reduces the
total fault coverage.
Solutions (in order of preference) to avoid this problem:

The clock input of every D-type flip-flop in the design must

be directly controllable from a primary input. No clock division, no mixing with others signals is allowed. If it is not
the case in the design, a test mode must be added, to
force the control of every DFF clock pin.
* Combinational feedback loops:
Combinational feedback loops (eg. RS flip-flop) are not
directly controllable and must not be used in the design.
* Asynchronous set and reset:
Asynchronous set and reset inputs must be controllable
from the top level ports (all asynchronous pins must be
disabled simultaneously).
Additional logic must be added in the design to force, in
test mode, all the set and reset pins to be inactive
( set = 1 and reset =1) from a primary input.
* Internal tristates:
Decoding logic must be added to ensure that tristates are
in output mode when scan-enable is active, and to avoid
contention on tristate buses.
The command insert_test, with no option, may be
used to automatically insert the disable logic. However, it
is recommended that this insertion is done and tested
manually before test insertion.

1. Use a test mode to route the signals around the

Megacells and associated BIST circuitry, allowing observability of the outputs and controllability of the inputs.

* Bi-directional input/output cells:

2. Define a structural equivalent that will be used for test

vector generation. Synopsys DesignWare may be used
to generate a multiplier, a synchronous RAM, or a synchronous ROM.

Additional logic must be added in a design to force each

bi-directional scan-in port to be input and each bi-directional scan-out port to be output when scan_enable is active.

In scan path:

7-79

For data I/O:

General Design Methodology

The direction of bi-directional data pins must be controlled

by the scan_enable signal to ensure that these pins remain in input mode during scanning.

* The design must be created starting from the scan design rules. Trying to implement the design rules at the
end of the design phase may be a difficult task.

* Number of scan chains / number of element in scan

chain:

* The design must be partitioned in sub-blocks. In particular, all the circuitry driven by a common external clock
should be grouped together in the same sub-block.

Try to have multiple scan chains of equal length, with between 100 and 500 elements per chain. Note that there
must be at least one scan chain for every set of sequential
elements driven by a separate external clock.
The impact of multiplying scan chains will be to increase
the number of scan_in and scan_out ports, but will reduce
the number of test vectors. The currently supported maximum number of vectors is 256K.
* Using user-defined test patterns:
Is not possible to load user-defined test patterns before
running the vector generation. However a test protocol
may be written to initialize the circuit.
* Initializing the design:
To ensure a good interface with the tester, it is important
to have a design completely initialized (no Xs on the outputs) as soon as possible.
A test protocol may be written and/or additional logic may
be added to force the initialization of the design. If the design contains no black box, the design will be fully initialized after the longest scan chain has been fully shifted in
(n clock cycles, if n is the number of element in the longest chain).
* Existing scan chain in a design:
The scan chain in a design may have been built manually. However all the above rules still apply, and also the
following:

* Prior to work on the full design, it is highly recommended

to work on each sub-block separately:
. check test
. scan insertion
. fault coverage estimation
Note that these intermediate results from individual subblocks must not be used to assemble a full scan path
design.
* Once each sub block gives good results, scan insertion
and vector generation may be run on the full design
(made up of the original, non-scan, sub-blocks).

Scan Insertion
* Atmel only supports full Scan ATPG using multiplexed
flip-flops as scan devices:
- test methodology: full_scan
- scan style:

multiplexed flip flop

* All DFFxx components are replaced by their scan

equivalent SFFxx components.
The scan signals are routed.
SFFxx components must not be used in the functional design since no scan equivalent is defined.
Optionally tristate disable logic may be added.
* Inputs:

. Each scan chain must have unique scan-in and scan-out

port.

- structural netlist: edif format

. All scan cells in a scan chain must be connected to the

same test signal.

- scan chain definitions:

. Only SFFxx are supported as scan devices.

. All SFFs in one scan chain must have the same
scan_clock working on the same edge.
. No mixing of clock and data is allowed.
In this case the design is read, the test rules are checked,
but no scan path insertion is requested.

- number of scan chains

input, output, enable, clock
optionally sequential elements in chains and routing
order
* Outputs:
- modified structural netlist: edif format (verilog format
may be used for simulation only)
- scan chain descriptions
- check_test design report

7-80

Cell-Based IC

Cell-Based IC
Scan Insertion Procedure

. Insert scan flip-flop and route scan signals:

The instructions for scan insertion and ATPG are given

below, using the Synopsys design tools. The text to be
typed at a Synopsys prompt is prefaced by >.

> insert_test |
|
|
|
|

Non Scan Design

. Define search path and libraries:

-no_insert
|
-no_route
|
-no_disable
|
-scan_chains
|
-max_scan_chain_length <1>|

. Save the modified design:

> search_path = . es2_synopsys_kit/lib

<synopsys>/libraries/syn
> link_library = * ecpdxx_ind.db
testxx_ind.db
> target_library = * ecpdxx_ind.db
testxx_ind.db

> write -format db -output <design>.db

> write -hierarchy -format verilog -output
<design>_scan.v

. Read design:

. Read design.

> read -format edif <design>.edif

> current_design = <design>

. Define scan methodology:

Existing Scan Design

. Define search path and libraries.

> uniquify

> set_scan_style multiplexed_flip_flop

> set_test_methodology full_scan
-existing_scan

. Define scan methodology:

. Define test_clock(s):

> set_test_methodology full_scan

> set_scan_style multiplexed_flip_flop

eg:

. Create unique instances:

. Define scan signals:

> set_signal_type

|
|<port_name>
|test_clock
|-index <n>
|test_scan_clock
|
|test_scan_enable
|
|test_scan_enable_inverted |
|test_scan_in
|
|test_scan_out
|
|test_scan_out_inverted|

> create_test_clock ck1 -period 2000

-waveform {1000,2000}
> create_test_clock ck2 -period 2000
-waveform {1000,2000}

. Define other scan signals:

eg:
> set_signal_type test_scan_enable tst_ena_1
index 1
> set_signal_type test_scan_enable tst_ena_2
index 2

. Define a test mode by forcing input ports.

> set_test_hold value <port_name>

eg. Define test_clock(s):

> create_test_clock ck1 -period 2000
-waveform {1000,2000}
> create_test_clock ck2 -period 2000
-waveform {1000,2000}

. Define untestable cells:

> set_test_isolate {list of cells}

. Define scan chains elements:

> set_scan_chains <index> {cell list}

eg. Define scan_enable signals:

. Define a routing order:

> set_signal_type test_scan_enable tst_ena_1

index 1
> set_signal_type test_scan_enable tst_ena_2
index 2

> set_test_routing_order -scan_chain_index

{cell list}

. Define a test mode by forcing input ports.

> set_test_hold value <port_name>

. Invoke processing of the design without adding any

gates or nets:

. Define untestable cells:

>

> set_test_isolate

{list of cells}

. Check the test design rules:

> check_test -verbose

insert_test -no_insert -no_route

-no_disable

. Define scan chain elements:

> set_scan_chains <index> {cell list}

. Define a routing order:

> set_test_routing_order -scan_chain_index n
{cell list}

. Check the test design rules:

> check_test -verbose

7-81

Test Vector Generation

* Non scan design:
- full scan insertion must be done and checked before running vector generation.
* Existing scan design:
- number of scan chains must be defined.
- input, output, enable, clock for each scan chains must be
defined.

> create_test_pattern
-input <input_file>
-output <output_file>
-compaction_effort <effort_level>
-no_compaction
-max_total_cpu <time>
-max_cpu_per_fault <time>
-backtrack_effort <effort_level>
-max_random_pattern <limit>
-sample <n>
-random_pattern_failure_limit <limit>

- test_clock format must be defined.

- each scan chain must have unique scan-in and scan-out
port.
- all scan cells in a scan chain must be connected to the
same test signal.
* Test mode:
- By adding some additional logic and by forcing some
primary inputs the design may be configured in a such
way that design rules are checked successfully and vector
generation achieves a good coverage.
* Reporting:
- no. of detected faults
- no. of abandoned faults
- no. of tied faults
- no. of redundant faults
- no. of untested faults
- total no. of faults
- fault coverage

> report_test
-faults <design>.faults
-atpg_conflicts
-constraints
-coverage
-dont_fault
-faults
-methodology
-port
-scan_path
-testsim_timing
-trace_nets

Simulating / Verifying the Generated

Vectors
* APTG is performed with zero delay models.
* Expected results are based on the following assumptions:
- no timing hazard
- no timing dependent behaviour

- no. of test patterns

- no. of compacted patterns
- list of undetected faults
* Test pattern files: in serial Verilog format.
* Note: It is not possible to seed user-defined vectors before ATPG.
* Estimating Testability:
It is possible to estimate the coverage of a design, working
only a small sample percentage of randomly selected
faults. The following command will report the coverage
obtainable, working only on 10 percent of the possible
faults:
> create_test_pattern -output <design>.vb
-sample 10 -no_compact

Test Vector Generation Procedure

. Define a limit to fault coverage:
> set_min_fault_coverage 100

.Invoke test vector generation:

7-82

. Produce a report:

Cell-Based IC

- static timing
* Full timing simulation (min and max) is required to ensure the validity of the test vectors.
* Problems:
- large disk space requirements.
- very long simulation runtimes.
Two alternatives are possible: serial or parallel scan simulation.

Serial Scan Simulation

The vectors are applied in simulation as they are applied
on the tester.
All vectors are fully checked.
The simulation may be very long, and a large amount of
disk space is required.

Parallel Scan Simulation

A first set of vectors is provided to test the connectivity of
the scan chains. Patterns are forced on the scan inputs,

Cell-Based IC
and the existence of the same patterns on the scan outputs after shifting is checked.

Running the Full Timing Simulation with

Verilog

A second set of vectors is provided to check only the combinational part of the design.

* Create a simulation directory and copy the stimuli and

netlist files into it:

No scan-in or scan-out is done to load the circuit or to

output the results.

- <design>_scan.v

All the values are forced directly on the internal nodes:

terns)

- The inputs of each element in the scan chains are directly forced.
- One shift-in is done to load the data in the scan flip flops.
- The data propagates through the combinational gates to
the next scan element.
- The value obtained on the input of each scan element is
checked against the expected one.

- <design>.test_0.v (Full scan parallel test.)

With Parallel Scan simulation, the vectors are not fully

checked. However, the simulation runtime and disk space
required are substantially reduced.
Note also that test program generation using parallel scan
simulation vectors is not currently supported. See the
Section Creating the Test Program later for details.

Simulation Vector Generation Procedure

(netlist)

- <design>.test_schk.v (connectivity check pat-

* Insert a timescale definition on the first line of each stimuli file:

timescale 1 ns / 10 ps

* Invoke the verilog simulation with:

- connectivity check patterns
- the full scan or parallel pattern.
* In both cases the simulation should complete with the
message:
TEST COMPLETED WITH NO ERRORS

which means that the simulated output values are identical to the expected ones.

Serial Scan Test Patterns

Creating the Test Program

> write_test

* The test program generation is done using the full scan

simulation results:

-format verilog
-input_vector ./<design>.vdb
-output <design>_test
-period
2000
-strobe
1900
-bidir_delay
0
-delay
100

Two verilog stimuli files are produced:

. Scan path connectivity check:

Figure 2. Test Program Generation with Full Scan Simulation Results

Test
Compiler

<design>.test_shck.v.

Patterns are applied through the scan chains and output

values identical to input values are checked.
. Full scan path test:

Verilog Stimuli:
Full Scan Path Test

Verilog Stimuli:
Functional Vectors

<design>.test_0.v

Output values are checked against expected ones.

Parallel Scan Test Patterns
> write_test

-format verilog -parallel

-input_vector ./<design>.vdb
-output <design>_test
-period
2000
-strobe
1900
-bidir_delay
100
-delay
0

Full Verilog
Timing Simulation
Vectors are Valid

Two verilog stimuli files are produced:

. Scan path connectivity check file:

FAST

<design>.test_shck.v.

. Parallel scan path test file:

<design>.test_0.v

Test Program

7-83

Vectors are fully simulated in serial mode, and checked.

Simulations results are converted into a test program using the FAST interface.
Simulation runtime and disk space used may be very
high.
* For information: another flow, not supported yet, is possible:
Figure 3. Test Program Generation with Scan Connectivity and Parallel Scan Vectors

Test
Compiler

Verilog Stimuli
Scan Connectivity,
Parallel Scan

Vectors in Verilog:
TSSI or Synopsys
Serial Format

Verilog Stimuli:
Functional Vectors

Full Verilog
Timing Simulation

FAST

FAST

End

7-84

Vectors
are Valid

Test
Program

Cell-Based IC

Test
Program

Vectors are not fully simulated and checked.

Vectors in Verilog, TSSI WGL or Synopsys format are directly converted into a test program using the FAST interface. (The format support for this is not currently defined.)