0% found this document useful (0 votes)
126 views

Testability in EOCHL (And Beyond ) : Vladimir Zivkovic

The document discusses testability strategies for the EOCHL chip, including implementing design-for-test (DfT) techniques like adding scan chains to modules like the EOCHL and CMD blocks, as well as using a DfT compiler and ATPG tools to insert the scan infrastructure and generate test patterns to check for manufacturing defects. Wrappers will be added to isolate modules for independent scan testing, and a top-level test control block will manage module-level scan enable and test mode signals.

Uploaded by

senthilkumar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
126 views

Testability in EOCHL (And Beyond ) : Vladimir Zivkovic

The document discusses testability strategies for the EOCHL chip, including implementing design-for-test (DfT) techniques like adding scan chains to modules like the EOCHL and CMD blocks, as well as using a DfT compiler and ATPG tools to insert the scan infrastructure and generate test patterns to check for manufacturing defects. Wrappers will be added to isolate modules for independent scan testing, and a top-level test control block will manage module-level scan enable and test mode signals.

Uploaded by

senthilkumar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 24

Testability in EOCHL

(and beyond…)
Vladimir Zivkovic
National Institute for Subatomic Physics (Nikhef),
Amsterdam, The Netherlands

FEI4_A review, 2-3rd November 2009


CERN, Geneve
Outline
• Introduction
• DfT Architecture
• DfT Flow
• Back-end Test Development
• Future Work
Functional vs Structural Testing
 Functional testing verifies that a circuit fulfils the desired
spec.
 Functional testing not feasible for exhaustive tests.
 Example: 32-bit adder requires 265 ≈ 3.7*1019 test vectors
 Structural test focuses rather on the circuit structure and
can cover manufacturing defects that otherwise may not
have been detected by functional testing.
 Power or ground shorts
 Open interconnect on the die (caused by dust particles)
 Short circuited source or drain on the transistor, (caused by
metal spike through)
 

Scan Chain DfT Principle


Outline
• Introduction
• DfT Architecture
• DfT Flow
• Back-end Test Development
• Future Work
Digital Testing Framework
0110
1000 Device comparators fail flags
1011
stimuli 0001
Under Test
: (DUT)
0001
0111
response 1010
0001
:

• Stimulus and response calculated by Automatic Test


Pattern Generator (ATPG) based on fault models
• Computed on the whole device or on parts of the
design, so-called embedded IP’s (cores)
• Access to embedded terminals of the IP through
design for test (DfT) is necessary
Generic Test Access Architecture

source TestRail
TAM IP TestRail
TAM sink

wrapper

1. Test Pattern Source and Sink


2. Test Access Mechanism (TAM)
3. Core Test Wrapper

[ Zorian, Marinissen, Dey - ITC’98 ]


IP = {EOCHL, CMD, DOB, EODCL}
Wrapper Isolation Overview
Wrapper Mandatory

bypass
Wrapper cells providing function access
and test controllability + observability
at IP’s data terminals
TestRail TestRail
inputs outputs TestRail access to wrapper cells
(‘surround chains’) and IP flip flops
(‘scan chains’)
IP
function
inputs function
outputs
Optional
Bypass register for all
Wrapper Control Block
TestRail chains

Wrapper Control Block


+ anti-skew element
How does this reflect to our situation?
Insert wrappers around EOCHL, CMD and other
blocks with scan chains (DOB, EODHL)
Primary TRO_cmd[0:2] TRI_eochl[0:2]

scan chain 0 (3000 FFs) scan chain 0 (1700 FFs)


TRI_cmd[0:2] scan chain 1 (600 FFs) scan chain 1 (400 FFs) TRO_eochl[0:2]

Inputs from other


digital blocks, e.g.
EODCL, CFGMEM
Inputs from other CMD EOCHL Outputs to other
digital blocks, e.g. digital blocks, e.g.
EODCL, CFGMEM EODCL, CFGMEM

Wrapper Control Block Wrapper Control Block


Wrapper EOCHL Wrapper CMD

Top level
IC LEVEL Test Control
Wrapper + Top Level Control

• Blocks will be scan-tested independently,


i.e. in isolation of each other
• Top-level test control (scan enable, test
mode selection) have to be implemented for
each block

Courtesy of M. Garcia-Sciveres *
Wrapper Isolation Cells
Provide the application of the test stimuli at the embedded IP
inputs as well as the observability at the embedded IP outputs

T e s t S h e ll

d _ in 0 0

IP
d_out

s1 1 s2 1
IP te s t r2 in te rc o n n e c tio n r1
s tim u lu s s tim u lu s
in te rc o n n e c tio n IP te st
resp o n se resp o n se
m 1 m 2
Wrapper Cells in the Nutshell
Input isolation Output isolation

T e s t S h e ll T e s t S h e ll
sci sco

d _ in 0 IP o u tp u t 0
IP in p u t d_out
D D
s c a n _ in
FF scan_out s c a n _ in F F sca n _o u t
s tc k s tc k
scan
scan
e n a b le e n a b le

Note: Only the combinatorial


inputs require isolation
Outline
• Introduction
• DfT Architecture
• DfT Flow
• Back-end Test Development
• Future Work
Two-pass Synthesis or mapped flow
Read Netlist, Libraries
and CTL files

Create Scan Protocols,


Specify Scan Path
Violations ?
Violations ?
Pre-
ScanDfT
Check

Preview
DfT

Insert Scan Path

Post-Scan
DfT Check

Handoff Design
Synopsys DfT Compiler

Control Script Test Constraints


(.tcl) (.tcl)

Library Synopsys DfT Compiler Netlist


(.v)

Scannable Netlist
Listings (.v)
STIL/CTL Synopsys Internal
test databasel
protocol
DfT Procedures in the nutshell
• PROC_dft_insert_init
– Global setup for dft insertion
• PROC_read_design
– Reads netlists and libraries and builds the design

• PROC_create_protocol_for_test
– Invokes the test constraints and builds the test protocols
• PROC_insert_scan
– Insert scan chains (preview_dft and insert_dft)
• PROC_handoff_design
– Write result to verilog, db, and test model (STIL/CTL) files
Scan Chain reports for the EOCHL

• 1 scan chain, length= 2927


• Standard DfT signals: si, so, se
• Clocked with an additional test clock (tck) –clock
gating with functional clocks performed at the
top level of the IP
• Additional DfT signal tm (to enable the test
clock)
ATPG flow
A plan is to use Synopsys
TetraMax ATPG tool

This flow has to be executed


at the design level
containing EOCHL, CMD
and wrapper isolation
Test Patterns
The TetraMax ATPG is expected to generate the
following:
• Continuity test patterns
– To check the scan chain structures themsleves, typically
11101000 sequence is shifted through
• Scan chain patterns for stuck-at faults

Optionally:
• IDDQ patterns
• Transition/Path delay fault patterns
• Bridge patterns
Outline
• Introduction
• DfT Architecture
• DfT Flow
• Back-end Test Development
• Future Work
Test Assembly Process
The main purpose is to:
• Assemble the test patterns of the IP(s) in the IC
• Convert these patterns into the real test vectors
• Generate the test bench for the simulation with both stimuli and response
• Include the timing and wave information
period
WaveForm {
tdel tdel
Pin = inputs; waveform
Drive = NR, tdel; vector

} t
period
WaveForm { t1 t2
Pin = rzClocks; waveform

Drive = RZ, t1, t2; vector

} t
period

t1 t2 t1 t2
WaveForm {
waveform
Pin = outputs;
Expect = SB, t1, t2; vector
} t
Back-End Test Development Flow

DfT
Abstractions

Test Test test •waveform generation


patterns Assembly lib •functional test

test
netlist
bench
tester
behavior
specific
models
vectors Simulator
Test Setup

Wafer Test

DUT
ATE, Test Setup

Lab Setup
Future Work concerning the test
development flow with scan chains
• Create the Wrapper around CMD and EOCHL blocks
• Run the ATPG at this level
• Back-end test development
– Link to lab setup
– Link to tester vectors running at tester platform (Verigy?
Teradyne? Or … ?)
• Mixed-Signal Test

You might also like