Tmax 2017.09 SG

ng
CUSTOMER EDUCATION SERVICES
ni
ai
Tr
ip
TetraMAX
ch
Workshop
ro
ic
Student Guide
30-I-021-SSG-017
lM 2017.09
na
er
nt
rI
Fo
se
U
ed
Synopsys Customer Education Services

690 E. Middlefield Road
ct
Mountain View, California 94043

tri
Workshop Registration: http://training.synopsys.com

es
www.synopsys.com
R
For Internal Microchip Training Purposes Only

Copyright Notice and Proprietary Information
 2018 Synopsys, Inc. All rights reserved. This software and documentation contain confidential and
proprietary information that is the property of Synopsys, Inc. The software and documentation are furnished
under a license agreement and may be used or copied only in accordance with the terms of the license
agreement. No part of the software and documentation may be reproduced, transmitted, or translated, in any
form or by any means, electronic, mechanical, manual, optical, or otherwise, without prior written permission
ng
of Synopsys, Inc., or as expressly provided by the license agreement.
Destination Control Statement
ni
All technical data contained in this publication is subject to the export control laws of the United States of
America. Disclosure to nationals of other countries contrary to United States law is prohibited. It is the
ai
reader's responsibility to determine the applicable regulations and to comply with them.
Tr
Disclaimer
SYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
ip
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
ch
Trademarks
Synopsys and certain Synopsys product names are trademarks of Synopsys, as set forth at
ro
http://www.synopsys.com/Company/Pages/Trademarks.aspx.
All other product or company names may be trademarks of their respective owners.
ic
Third-Party Links
lM
Any links to third-party websites included in this document are for your convenience only. Synopsys does
not endorse and is not responsible for such websites and their practices, including privacy practices,
availability, and content.
na
Synopsys, Inc.
er
690 E. Middlefield Road

Mountain View, CA 94043
nt
www.synopsys.com
rI
Document Order Number: 30-I-021-SSG-017

Fo
TetraMAX Student Guide

se
U
ed
ct
tri
es
R

Table of Contents
Unit i: Introduction & Overview

Facilities ............................................................................................................................ i-2
Workshop Overview ......................................................................................................... i-3
ng
Target Audience ................................................................................................................ i-4
Workshop Prerequisite Knowledge .................................................................................. i-5
ni
Introductions ..................................................................................................................... i-6
ai
Agenda .............................................................................................................................. i-7
Agenda .............................................................................................................................. i-8
Tr
Agenda .............................................................................................................................. i-9
Icons Used in this Workshop .......................................................................................... i-10
ip
ch
Unit 1: Introduction to Test and TetraMAX
ro
Agenda ............................................................................................................................. 1-1
ic
Unit Objectives ................................................................................................................ 1-2
lM
Manufacturing Test Programs.......................................................................................... 1-3
Stuck-At Fault Model ...................................................................................................... 1-4
Rules for Detecting a Stuck-At Fault ............................................................................... 1-5
na
Combinational Logic: Stuck-At Testing .......................................................................... 1-6
Activate the SA0 Fault (1/4) ........................................................................................... 1-7
er
Propagate Fault Effect (2/4) ............................................................................................ 1-8

Anatomy of a Test Pattern (3/4) ...................................................................................... 1-9
nt
Record the Test Pattern (4/4) ........................................................................................ 1-10

rI
Testing Sequential Designs ............................................................................................ 1-11

Scannable Equivalent Flip-Flop..................................................................................... 1-12
Fo
The Full Scan Strategy ................................................................................................... 1-13

Scan Testing Protocol .................................................................................................... 1-14
se
Test Patterns Overlap .................................................................................................... 1-15

TetraMAX Overview ..................................................................................................... 1-16
U
TetraMAX Interfaces ..................................................................................................... 1-17

ATPG Flow in TetraMAX ............................................................................................. 1-18
ed
Launching TetraMAX .................................................................................................... 1-19

Example TetraMAX Script ........................................................................................... 1-20
ct
Tcl API Commands........................................................................................................ 1-21

Using Collections and Filters ......................................................................................... 1-22
tri
Retrieving Attributes Values.......................................................................................... 1-23

es
Tcl API Example............................................................................................................ 1-24

TetraMAX On-Line Help (OLH)................................................................................... 1-25
R
Getting Help - SolvNet Resources ................................................................................. 1-26

Unit Objectives Summary .............................................................................................. 1-27
Command Summary (Lecture, Lab) .............................................................................. 1-28
Synopsys 30-I-021-SSG-017 i TetraMAX Workshop

Table of Contents
Unit 2: Building ATPG Models

Agenda ............................................................................................................................. 2-1
Unit Objectives ................................................................................................................ 2-2
BUILD Mode in TetraMAX ............................................................................................ 2-3
ng
Reading the Library Files................................................................................................. 2-4
Cell Models Derived from Simulation Library ................................................................ 2-5
ni
ATPG Model Derivation.................................................................................................. 2-6
Expect Warnings if Library not “Validated” ................................................................... 2-7
ai
Duplicate Module Definitions.......................................................................................... 2-8
Tr
Read Design Netlist ......................................................................................................... 2-9
Build the ATPG Design Model...................................................................................... 2-10
ip
Missing Modules Discovered During Build .................................................................. 2-11
How Many Modules Are Missing? ................................................................................ 2-12
ch
Read ATPG Memory Models, If Available ................................................................... 2-13
Define Black Boxes If No ATPG Model Exists ............................................................ 2-14
ro
Empty Boxes Versus Black Boxes ................................................................................ 2-15
ic
Mode is DRC…Ignore those Build Violations? ............................................................ 2-16
Investigate Each N and B Warning ................................................................................ 2-17
lM
Did All of the Cells Translate Properly?........................................................................ 2-18
Graphical Schematic Viewer (GSV) .............................................................................. 2-19
na
Design View vs. Primitive View In GSV ...................................................................... 2-20
Prefer to Debug ATPG Models Graphically? ................................................................ 2-21
er
Investigating Models Graphically .................................................................................. 2-22

What If ATPG Models Cannot Be Derived? ................................................................. 2-23
nt
ATPG Modeling Primitives: Partial List ....................................................................... 2-24

rI
ATPG Modeling Primitives: Examples ......................................................................... 2-25

Testability of Embedded Memory ................................................................................. 2-26
Fo
Memory DFT Strategies ................................................................................................ 2-27

Black Box or Bypass Mode ........................................................................................... 2-28
TetraMAX Memory Model............................................................................................ 2-29
se
Clock Stable and Load Stable ........................................................................................ 2-30

RAM/ROM Modeling.................................................................................................... 2-31
U
RAM Modeling: Basic Example .................................................................................... 2-32

ROM Model: Basic Example ......................................................................................... 2-33
ed
Utility to Generate TetraMAX Memory Models ........................................................... 2-34

Want to Quickly Return to DRC Mode? ....................................................................... 2-35
ct

tri

es
R
Unit 3: Running DRC

Agenda ............................................................................................................................. 3-1
Unit Objectives ................................................................................................................ 3-2
ATPG Flow in TetraMAX ............................................................................................... 3-3
Synopsys 30-I-021-SSG-017 ii TetraMAX Workshop

Table of Contents
Controlling ATPG: Agenda ............................................................................................. 3-4

How Does TetraMAX Perform Design Rule Checks (DRC)? ........................................ 3-5
Partial STIL Protocol File ................................................................................................ 3-6
Different Ways to Create a STIL Protocol File ............................................................... 3-7
Writing Out the STIL Protocol File ................................................................................. 3-8
ng
Using Quick STIL Commands......................................................................................... 3-9
Defining PI Constraints.................................................................................................. 3-10
ni
Defining PI Equivalences .............................................................................................. 3-11
ai
SPF: PI Constraints and PI Equivalences ...................................................................... 3-12
Defining Clocks ............................................................................................................. 3-13
Tr
Defining Asynchronous Set/Reset ................................................................................. 3-14
SPF: Capture Procedures ............................................................................................... 3-15
ip
SPF: Defining Scan Chains & Scan Enable ................................................................... 3-16
SPF: Controlling Test Mode .......................................................................................... 3-17
ch
Where Does TetraMAX Get Timing Info? .................................................................... 3-18
ro
Default WaveformTable (_default_WFT) ..................................................................... 3-19
Pre-clock Measure vs. End-of-cycle Measure ............................................................... 3-20
ic
Pre-clock Measure ......................................................................................................... 3-21
lM
TetraMAX Design Rule Checks .................................................................................... 3-22
Performing Scan Design Rule Checks ........................................................................... 3-23
Results of Design Rule Checks ...................................................................................... 3-24
na
Controlling ATPG: Agenda ........................................................................................... 3-25
Debugging DRC Violations ........................................................................................... 3-26
er
Debugging an S1 Violation ............................................................................................ 3-27

Debug S1 Violations Graphically in the GSV ............................................................... 3-28
nt
Change Pindata to test_setup to Debug Initialization Issues ......................................... 3-29

rI
Stability Patterns ............................................................................................................ 3-30

Simulation Waveform Viewer (SWV)........................................................................... 3-31
Fo
Using the SWV .............................................................................................................. 3-32

Supported Pindata Types with SWV ............................................................................. 3-33
se
Want to Quickly Return to TEST Mode? ...................................................................... 3-34

U
Fault Classes .................................................................................................................. 3-36

Scan Path Faults are Detected by Implication ............................................................... 3-37
ed
Faults Classifications Right After DRC ......................................................................... 3-38

PT - Possibly Detected Faults ........................................................................................ 3-39
ct
Unused FF Output Pins become UU Faults ................................................................... 3-40

Actual Tie-offs in Netlist Become UT Faults ................................................................ 3-41
tri
Undetectable Redundant (UR) Fault .............................................................................. 3-42

es
Constraints Can Create AU Faults ................................................................................. 3-43

Fault Progression from NC to DS .................................................................................. 3-44
R
Defining Nofaults........................................................................................................... 3-45

Creating a Fault List with Nofaults ................................................................................ 3-46
Fault Interface File Format ............................................................................................ 3-47
Equivalent Faults .......................................................................................................... 3-48
Fault Collapsing ............................................................................................................. 3-49
Synopsys 30-I-021-SSG-017 iii TetraMAX Workshop

Table of Contents
Fault List After Collapsing ........................................................................................... 3-50

Equivalent Faults in the Fault File ................................................................................ 3-51
Collapsed vs. Uncollapsed Faults .................................................................................. 3-52
Calculating Test and Fault Coverage ............................................................................. 3-53
How to Report Fault Coverage ...................................................................................... 3-54
ng
Adding Faults / Saving Faults ........................................................................................ 3-55
ni
ai
Tr
Unit 4: Controlling ATPG
ip
Agenda ............................................................................................................................. 4-1
ch
Unit Objectives ................................................................................................................ 4-2
ro
Controlling ATPG: Agenda ............................................................................................. 4-4
Running ATPG ................................................................................................................ 4-5
ic
ATPG: Select TetraMAX Engine(s) ................................................................................ 4-6
lM
Results after Basic-Scan ATPG ....................................................................................... 4-7
AU: Untestable under Current ATPG Settings ................................................................ 4-8
ATPG: Basic-Scan versus Fast-Sequential ...................................................................... 4-9
na
Loadable Nonscan Cells ................................................................................................ 4-10
Using Loadable Nonscan Cells ...................................................................................... 4-11
er
Enabling Fast-Sequential ATPG .................................................................................... 4-12

How to Determine –capture_cycles ............................................................................... 4-13
nt
When Can Fast-Sequential ATPG Help? ....................................................................... 4-14

rI
Results after Fast-Sequential ATPG .............................................................................. 4-15

How to Enable Full-Sequential Engine.......................................................................... 4-16
Fo
ATPG Guidelines ........................................................................................................... 4-17

Multicore Support in TetraMAX ................................................................................... 4-18
se
Enabling Multicore Support ........................................................................................... 4-19

Multicore Script Examples ............................................................................................ 4-20
U
Multicore run_atpg Output ............................................................................................ 4-21

ed
Post-ATPG: Reducing ND Faults .................................................................................. 4-23

Post-ATPG: Results with Higher Abort Limit............................................................... 4-24
ct
Post-ATPG: Final Abort Limit Results.......................................................................... 4-25

Low Coverage: Review PI Constraints .......................................................................... 4-26
tri
Low Coverage: Analyze the Clocks .............................................................................. 4-27

es
Are All Expected Flops Scannable? .............................................................................. 4-28

DRC Rules Affecting Coverage..................................................................................... 4-29
R
Hierarchical Test Coverage............................................................................................ 4-30

Isolate the Impact of the AU Faults ............................................................................... 4-31
Running Analysis of AU Faults ..................................................................................... 4-32
Report More Details of AU Faults ................................................................................. 4-33
Fault Analysis Source Points ......................................................................................... 4-34
Synopsys 30-I-021-SSG-017 iv TetraMAX Workshop

Table of Contents
Analyze a Particular AU Fault ....................................................................................... 4-35

Analyze a Particular AU Fault ....................................................................................... 4-36
Hierarchy Browser ......................................................................................................... 4-37
Tips for Improving Test Coverage ................................................................................. 4-38
Functional Pattern Fault Simulation .............................................................................. 4-39
ng
Want to Quickly Return Post-ATPG?............................................................................ 4-40
Interrupting a Long Process ........................................................................................... 4-41
ni
ai
TetraMAX II .................................................................................................................. 4-43
Running TetraMAX II ................................................................................................... 4-44
Tr
TetraMAX II Specific Command Options ..................................................................... 4-45
When is Threading Used With TetraMAX II ................................................................ 4-46
ip
TetraMAX II Messages: Ignored Settings ..................................................................... 4-47
TetraMAX II Simulation................................................................................................ 4-48
ch
Other Behavior Differences with TetraMAX II ............................................................. 4-49
ro
TetraMAX II Limitations ............................................................................................... 4-50
ic
Command Summary ..................................................................................................... 4-52
lM
Appendix ........................................................................................................................ 4-53
Test Point Analysis ........................................................................................................ 4-54
Options: analyze_test_points (1/3) ................................................................................ 4-55
na
er
Test Point Analysis Flow ............................................................................................... 4-58

nt
rI
Unit 5: Minimizing ATPG Patterns

Fo
Agenda ............................................................................................................................. 5-1

Unit Objectives ................................................................................................................ 5-2
se
Benefits of Compact Vector Sets ..................................................................................... 5-3

What is Dynamic Pattern Compression? ......................................................................... 5-4
U
Controlling Dynamic Pattern Compression ..................................................................... 5-5

Minimum Detects ATPG Option ..................................................................................... 5-6
ed
Avoiding Patterns that Detect Too Few Faults ................................................................ 5-7

Using run_atpg -optimize_patterns .................................................................................. 5-8
ct
Dynamic Clock Grouping ................................................................................................ 5-9

Dynamic Clock Grouping: Parallel ................................................................................ 5-10
tri
Dynamic Clock Group: Disturbed ................................................................................. 5-11

es
Analyze Clock Grouping and Disturbances ................................................................... 5-12

Clock Grouping for Each Pattern ................................................................................... 5-13
R
Adding Fault Models Increases Test Cost ..................................................................... 5-14

How Compression Works .............................................................................................. 5-15
Test Compression Concepts ........................................................................................... 5-16
Test Cycle Savings ......................................................................................................... 5-17
Test Modes Created During Insertion ............................................................................ 5-18
Synopsys 30-I-021-SSG-017 v TetraMAX Workshop

Table of Contents
Passing Compression Information to TetraMAX .......................................................... 5-19

ATPG – Scan Compression Flow .................................................................................. 5-20
Explore Compression in TetraMAX .............................................................................. 5-21
Using analyze_compressors Example............................................................................ 5-22
DFTMAX Ultra and ATPG ........................................................................................... 5-23
ng
Updating DFTMAX Ultra Patterns ................................................................................ 5-24
DFTMAX Ultra Padding Patterns ................................................................................. 5-25
ni
ai
Tr
Unit 6: Pattern Validation
ip
ch
Agenda ............................................................................................................................. 6-1
Unit Objectives ................................................................................................................ 6-2
ro
ATPG Pattern Validation: Agenda .................................................................................. 6-4
ic
ASIC Vendor: Specific Considerations ........................................................................... 6-5
lM
Options for Writing Patterns ............................................................................................ 6-6
Unified STIL Flow vs. Dual STIL Flow .......................................................................... 6-7
General Guidelines for Saving Patterns ........................................................................... 6-8
na
Scan Chain Test ............................................................................................................... 6-9
Set Chain Test Bit Sequence before ATPG ................................................................... 6-10
er
DFTMAX Ultra Chain Test Patterns ............................................................................. 6-11

Splitting Up Large Pattern Sets...................................................................................... 6-12
nt
Generate Reports Now for Later Debugging ................................................................. 6-13

rI
ATPG Pattern Validation: Agenda ................................................................................ 6-14

The Challenge of Verifying Scan Designs..................................................................... 6-15
Fo
Verilog Pattern Validation ............................................................................................. 6-16

What is MAX Testbench? .............................................................................................. 6-17
se
Using MAX Testbench .................................................................................................. 6-18

Configuration File Overview ......................................................................................... 6-19
U
Parallel vs. Serial Load During Simulation ................................................................... 6-20

Flexible Simulation: Serial Vs. Parallel ......................................................................... 6-21
ed
Serial Load Simulate Which Patterns? .......................................................................... 6-22

Selecting Serial Patterns by Capture Clock ................................................................... 6-23
ct
Write Only Those Selected Patterns .............................................................................. 6-24

Handling Split Patterns With MAX Testbench ............................................................. 6-25
tri
Runtime Programmability .............................................................................................. 6-26

es
Runtime Programmability for Patterns .......................................................................... 6-27

Recommended Simulation Strategy ............................................................................... 6-28
R
Verilog Simulation ......................................................................................................... 6-29

Recognize Common Mismatch Causes ......................................................................... 6-31
Begin Debugging the First Failure ................................................................................. 6-32
Failure Log Formats ....................................................................................................... 6-33
Synopsys 30-I-021-SSG-017 vi TetraMAX Workshop

Table of Contents
Regular Scan Mode Failure Log Formats ...................................................................... 6-34

Regular Scan Mode Failure Log Formats with Cell Names .......................................... 6-35
Compression Mode Failure Log Formats (Unified STIL Flow) .................................... 6-36
Compression Mode Failure Log Formats (Dual STIL Flow) ........................................ 6-37
Combined Pattern Validation (CPV) ............................................................................. 6-38
ng
Generating a PSD File ................................................................................................... 6-39
Compression Mode Failure Log Formats with PSD ...................................................... 6-40
ni
Post Process Fail Log to Show Failing Cell Names ..................................................... 6-41
ai
Flow to Post Process Fail Log and Show Failing Cell Names ...................................... 6-42
Useful Debugging Signals ............................................................................................. 6-43
Tr
What is Parallel Testbench Doing? ................................................................................ 6-44
Simulation Waveforms .................................................................................................. 6-45
ip
Comparing Waves to TetraMAX ................................................................................... 6-46
Some Causes of Simulation Mismatches ....................................................................... 6-47
ch
ro
Still Have Failures in Simulation or on ATE? ............................................................... 6-49
Masking Simulation Failures ......................................................................................... 6-50
ic
Defining Input or Output Masks .................................................................................... 6-51
lM
Scan Cell Constraints ..................................................................................................... 6-52
Non-Scan Cell Masks .................................................................................................... 6-53
Per-cycle Pattern Masking ............................................................................................. 6-54
na
Fail Data File Support From Simulation ........................................................................ 6-55
Failure Data File Formats From Simulation .................................................................. 6-56
er
DFTMAX Ultra chain masking ..................................................................................... 6-57

DFTMAX Ultra chain masking: Examples ................................................................... 6-58
nt

rI

Fo
Unit 7: Fault Models and At-Speed Testing

se
Agenda ............................................................................................................................. 7-1

U
Unit Objective .................................................................................................................. 7-2

New Defect Types with New Technologies .................................................................... 7-3
ed
Sources of Test Escapes ................................................................................................... 7-4

Delay Testing Introduction: Agenda ................................................................................ 7-5
ct
Fault Models .................................................................................................................... 7-6

At-Speed Defect ............................................................................................................... 7-7
tri
Why Chips Fail “At-Speed”? ........................................................................................... 7-8

es
Methodologies for At-Speed Defect Testing ................................................................... 7-9

Which Methodology Detects Most Defects? ................................................................. 7-10
R
Transition Delay Fault Model ....................................................................................... 7-11

Detection Path : Does it Matter? ................................................................................... 7-12
Detecting a Small Delay Defect ..................................................................................... 7-13
How Are Delay Defects Distributed? ............................................................................ 7-14
TetraMAX Slack-Based Transition ATPG .................................................................... 7-15
Synopsys 30-I-021-SSG-017 vii TetraMAX Workshop

Table of Contents
Cell-Aware Test ............................................................................................................. 7-16

Slack-Based Cell-Aware Test ........................................................................................ 7-17
Z01X Cell-Aware Fault Simulation ............................................................................... 7-18
Path Delay Fault Model ................................................................................................. 7-19
Bridging Fault Models ................................................................................................... 7-20
ng
Delay Testing Introduction: Agenda .............................................................................. 7-21
At-Speed Fault Models .................................................................................................. 7-22
ni
Structured At-Speed Fault Testing................................................................................. 7-23
ai
At-Speed Launch Methods ............................................................................................ 7-24
Transition Launch Methods ........................................................................................... 7-25
Tr
system_clock Launch (Default) ..................................................................................... 7-26
system_clock Launch: Example .................................................................................... 7-27
ip
system_clock Launch: Details ....................................................................................... 7-28
Additional Delay Test Cycles ........................................................................................ 7-29
ch
last_shift Launch ........................................................................................................... 7-30
ro
last_shift Launch: Example............................................................................................ 7-31
last_shift Launch: Details .............................................................................................. 7-32
ic
extra_shift Launch: Details ............................................................................................ 7-33
lM
Pipelined ScanEnable..................................................................................................... 7-34
Delay Testing Introduction: Agenda .............................................................................. 7-35
STIL Protocol File Timing............................................................................................. 7-36
na
Allclock Capture Procedures ......................................................................................... 7-37
allclock_*{} Procedures Example ................................................................................. 7-38
er
WFTs for External System Clock Launch ..................................................................... 7-39

WFTs for External Clock Last Shift Launch ................................................................. 7-40
nt
Preambles and Postambles ............................................................................................ 7-41

rI

Fo
se
Unit 8: At-Speed Constraints

U
Agenda ............................................................................................................................. 8-1

Unit Objective ................................................................................................................. 8-2
ed
At-Speed Constraints ....................................................................................................... 8-3

At-Speed Constraints: Agenda ......................................................................................... 8-4
ct
Timing Exceptions ........................................................................................................... 8-5

Slow Ports ........................................................................................................................ 8-6
tri
Slow Cells ........................................................................................................................ 8-7

es
At-Speed Constraints: Agenda ......................................................................................... 8-8

Timing Exceptions with an SDC file ............................................................................... 8-9
R
Exception Types............................................................................................................. 8-10

Simulation of Timing Exception During ATPG ............................................................ 8-11
Reading SDC ................................................................................................................ 8-12
Supported SDC Clock Constructs .................................................................................. 8-13
Supported SDC Exceptions............................................................................................ 8-14
Synopsys 30-I-021-SSG-017 viii TetraMAX Workshop

Table of Contents
Controlling Clock Propagation ...................................................................................... 8-15

SDC Timing Exception Example .................................................................................. 8-16
Functional Mode Vs Test Mode ................................................................................... 8-17
Test Mode Timing.......................................................................................................... 8-18
Timing Violations in Test Mode .................................................................................... 8-19
ng
Timing Exceptions From Violations Flow .................................................................... 8-20
Fine Tuning the SDC Flow ............................................................................................ 8-21
ni
Report SDC Exceptions ................................................................................................. 8-22
ai
Identifying AU Faults Caused by SDC Timing Exceptions .......................................... 8-23
At-Speed Constraints: Agenda ....................................................................................... 8-24
Tr
Scan Testing is Power-Hungry ...................................................................................... 8-25
Power Problems During Shift Mode .............................................................................. 8-26
ip
Low-Power (i.e. Adjacent) Fill ...................................................................................... 8-27
Shift Power Effort and Budget ....................................................................................... 8-28
ch
Power Problems During Capture Mode ......................................................................... 8-29
ro
Excessive Power During Scan Capture.......................................................................... 8-30
Capture Power with Standard ATPG ............................................................................. 8-31
ic
Capture Power with Power-Aware ATPG ..................................................................... 8-32
lM
Power-Aware ATPG Commands ................................................................................... 8-33
Clock Gating Report ...................................................................................................... 8-34
Power-Aware Pattern Reporting .................................................................................... 8-35
na
Power-Aware ATPG Script Example ............................................................................ 8-36
er

nt
rI
Unit 9: Transition Delay Testing

Fo
Agenda ............................................................................................................................. 9-1

Unit Objective ................................................................................................................. 9-2
se
Transition Delay: Agenda ................................................................................................ 9-3

Step-by-Step Transition ATPG ....................................................................................... 9-4
U
Transition Delay ATPG Script ........................................................................................ 9-5

Adding Transition Delay Faults ...................................................................................... 9-6
ed
Optimized Transition Delay ATPG Engine ..................................................................... 9-7

Design Guidelines for Transition Testing ........................................................................ 9-8
ct
Requirements for Transition ATPG ................................................................................. 9-9

Transition Delay Flow Considerations .......................................................................... 9-10
tri
Inter-Clock Domain Paths.............................................................................................. 9-11

es
Common Launch Capture ............................................................................................. 9-12

Transition Delay: Agenda .............................................................................................. 9-13
R
Testing for Small Delay Defects .................................................................................... 9-14

Slack-Based ATPG Flow ............................................................................................... 9-15
Slack Data Generation : PrimeTime Flow ..................................................................... 9-16
Reading Slack Data ....................................................................................................... 9-17
Slack on Red Path .......................................................................................................... 9-18
Synopsys 30-I-021-SSG-017 ix TetraMAX Workshop

Table of Contents
Slack on Green Path ....................................................................................................... 9-19

Slack on Blue Path ......................................................................................................... 9-20
Lowest Slacks On Each Pin ........................................................................................... 9-21
Slack-Based ATPG Terminology .................................................................................. 9-22
Illustration of Tmgn Tdet and Delta ............................................................................. 9-23
ng
Test For Understanding (Ex. 1) ..................................................................................... 9-24
ni
ai
Negative and Infinite Slack ............................................................................................ 9-27
Tr
Setting Standard for Targeted Faults ............................................................................. 9-29
Minimizing Pattern Count Inflation ............................................................................... 9-30
ip
Setting max_tmgn – Default ∞ – Too Many ................................................................. 9-31
Setting a Reasonable max_tmgn .................................................................................... 9-32
ch
Setting Standard for Full Detection ............................................................................... 9-33
ro
Setting max_delta_per_fault .......................................................................................... 9-34
Partially Detected Faults : TP ....................................................................................... 9-35
ic
Fault Report with Slack Data ......................................................................................... 9-36
lM
Fault Report: report_faults –slack tmgn ........................................................................ 9-37
Fault Report: report_faults –slack tdet ........................................................................... 9-38
Fault Report: report_faults –slack delta ......................................................................... 9-39
na
Metric: Delay Effectiveness ........................................................................................... 9-40
Slack-Based ATPG Flow ............................................................................................... 9-41
er
Slack-Based Test Does a Better Job .............................................................................. 9-42

Improved Pattern Quality ............................................................................................... 9-43
nt

rI
Persistent Fault Models .................................................................................................. 9-45

Persistent Fault Model Flow .......................................................................................... 9-46
Fo
Direct Credit .................................................................................................................. 9-47

Combined Coverage with Persistent Fault Models ........................................................ 9-48
se

U
ed
Unit 10: On-Chip Clocking Support

ct
Agenda ........................................................................................................................... 10-1

Unit Objective ............................................................................................................... 10-2
tri
At-Speed Clocking ......................................................................................................... 10-3

es
Issues Testing At-Speed with External Clocks .............................................................. 10-4

Requirements for Using Existing PLL Clocks............................................................... 10-5
R
On Chip Clock (OCC) Controller .................................................................................. 10-6

Fundaments of OCC ...................................................................................................... 10-7
OCC IP Operation .......................................................................................................... 10-8
OCC Flows in ATPG ..................................................................................................... 10-9
DFT Compiler and TetraMAX OCC Flows ................................................................ 10-10
Synopsys 30-I-021-SSG-017 x TetraMAX Workshop

Table of Contents
TetraMAX Flow: SPF Available ............................................................................... 10-11

TetraMAX Flow: SPF Not Available ......................................................................... 10-12
OCC QUICK STIL Flow (1/2) ................................................................................... 10-13
OCC QUICK STIL Flow (2/2) .................................................................................... 10-14
Black Box Requirement for DRC ................................................................................ 10-15
ng
DRC Violations ............................................................................................................ 10-16
Reporting Internal and PLL Clocks ............................................................................ 10-17
ni
Asynchronous Reference Clocks ................................................................................. 10-18
ai
Reference Clock and Pattern Formats.......................................................................... 10-19
ATE Cycles During Scan Capture ............................................................................... 10-20
Tr
Issue: Capture Window Too Small .............................................................................. 10-21
Solution: Increase the Number of ATE Cycles............................................................ 10-22
ip
Capture Cycles with OCC ............................................................................................ 10-23
PLL Clocks in Capture Cycle ...................................................................................... 10-24
ch
Clock Grouping with OCC .......................................................................................... 10-25
ro
Multiple OCC Controller Usage During ATPG .......................................................... 10-26
Report OCC Clocking .................................................................................................. 10-27
ic
Verification of On-Chip Clocking ............................................................................... 10-28
lM
Inter-Clock Domain Test with Synchronous OCC ...................................................... 10-29
Synchronous Multi-Frequency Clocks ........................................................................ 10-30
Internal Clocking Procedures (ICP) ............................................................................. 10-31
na
SPF Example With ICP ............................................................................................... 10-32
ICP Setup and Commands ........................................................................................... 10-33
er
ICP Reporting Examples.............................................................................................. 10-34

Clocking Procedures Pattern Grouping ....................................................................... 10-35
nt
Unit Objectives Summary ............................................................................................ 10-36

rI
Command Summary (Lecture, Lab) ............................................................................ 10-37

Appendix ...................................................................................................................... 10-38
Fo
OCC Controller Waveforms ........................................................................................ 10-39

Avoid Unified ATE Clock ........................................................................................... 10-40
se
Avoid Using Reference Clock as Shift Clock.............................................................. 10-41

Avoid Using Reference Clock for Capture or in test_setup ........................................ 10-42
U
Clock Bits Must Hold State ......................................................................................... 10-43

Very Slow De-assertion of Scan Enable ...................................................................... 10-44
ed
Solution: Add load_unload Postamble* ...................................................................... 10-45

Very Slow Assertion of Scan Enable ........................................................................... 10-46
ct
Solution: Add load_unload preamble * ....................................................................... 10-47

tri
es
Unit 11: Path Delay Testing

R
Agenda ........................................................................................................................... 11-1

Unit Objective ............................................................................................................... 11-2
Automated Links for At-Speed Tests ............................................................................ 11-3
Path Delay Flow ............................................................................................................. 11-4
Main write_delay_paths Options ................................................................................... 11-5
Synopsys 30-I-021-SSG-017 xi TetraMAX Workshop

Table of Contents
Path Delay Fault Models and ATPG Engines............................................................... 11-6

Path Delay ATPG : Setup Check ................................................................................... 11-7
Path Delay ATPG : Hold Check .................................................................................... 11-8
Hold Time Path Delay Flow Details .............................................................................. 11-9
ATPG Script Examples ................................................................................................ 11-10
ng
Path Delay Hold Time ATPG Script ........................................................................... 11-11
Managing Faults........................................................................................................... 11-12
ni
Path File ....................................................................................................................... 11-13
ai
Path Syntax ................................................................................................................. 11-14
Path Example ............................................................................................................... 11-15
Tr
Untestable Paths ........................................................................................................... 11-16
On Path Vs. Off Path Inputs ........................................................................................ 11-17
ip
Hazards Can Impact Path Delay Tests ......................................................................... 11-18
Hazard-Free Path Delay Test Example ........................................................................ 11-19
ch
Robust Path Delay Test ................................................................................................ 11-20
ro
Robust Path Delay Test Example ................................................................................ 11-21
Non-Robust Path Delay Tests ...................................................................................... 11-22
ic
Non-Robust Path Delay Test Example ........................................................................ 11-23
lM
Summary of Path Delay Fault Detections .................................................................... 11-24
Characterization Tests .................................................................................................. 11-25
Fault Classification ...................................................................................................... 11-26
na
Launch Cycle ............................................................................................................... 11-27
Simulating Hazards ...................................................................................................... 11-28
er
Reconvergent Path ....................................................................................................... 11-29

Multi-Cycle Paths ........................................................................................................ 11-30
nt
Multi-Cycle ATPG Flow ............................................................................................. 11-31

rI
Analyze Fault ............................................................................................................... 11-32

Analysis Report ............................................................................................................ 11-33
Fo
GSV Debug of Delay Path Violations ......................................................................... 11-34

se

U
Unit 12: Diagnosis

ed
Agenda ........................................................................................................................... 12-1

ct
Unit Objectives .............................................................................................................. 12-2

Purpose of Failure Diagnosis ......................................................................................... 12-3
tri
Yield Enhancement Process ........................................................................................... 12-4

es
High Level View ............................................................................................................ 12-5

Volume Diagnostics Flow.............................................................................................. 12-6
R
TetraMAX Diagnosis ..................................................................................................... 12-7

TetraMAX Diagnosis Features ...................................................................................... 12-8
TetraMAX Diagnosis Flow............................................................................................ 12-9
Requirements For Diagnosis ........................................................................................ 12-10
Diagnosis Commands .................................................................................................. 12-11
Synopsys 30-I-021-SSG-017 xii TetraMAX Workshop

Table of Contents
Diagnosis Flow Using Binary Image ........................................................................... 12-12

Advantages of Binary Image File ............................................................................... 12-13
Secure Image ................................................................................................................ 12-14
Secure Image Commands ............................................................................................ 12-15
Sample Scripts With Secure Image.............................................................................. 12-16
ng
Tester Failure Data File ............................................................................................... 12-17
Pattern-based Failure Data Format .............................................................................. 12-18
ni
Cycle-based Failure Data Format ................................................................................ 12-19
ai
Checking Expected Data in Failure Data File.............................................................. 12-20
Truncated Failure Data File ......................................................................................... 12-21
Tr
TetraMAX Diagnosis Engines ..................................................................................... 12-22
Functional Logic Diagnosis ......................................................................................... 12-23
ip
Chain Diagnosis Overview .......................................................................................... 12-24
Chain Diagnosis Principle............................................................................................ 12-25
ch
Chain Diagnosis Output ............................................................................................... 12-26
ro
Sample Output: Diagnosis Summary ........................................................................... 12-27
Sample Output: Fault Candidate .................................................................................. 12-28
ic
What is the Match Score? ............................................................................................ 12-29
lM
Computing the Match Score ........................................................................................ 12-30
Terminology: Explaining Patterns ............................................................................... 12-31
GSV Output ................................................................................................................. 12-32
na
N-Detect: Better Precision ........................................................................................... 12-33
N-Detect Flow Example .............................................................................................. 12-34
er
Physical Data Improves Diagnostics ........................................................................... 12-35

High-Capacity Physical Database ................................................................................ 12-36
nt
PHDS Creation in TetraMAX ...................................................................................... 12-37

rI
PHDS Data Access Process (DAP) Server Setup in TetraMAX ................................. 12-38
TetraMAX PHDS Usage.............................................................................................. 12-39
Fo
Sample Output: Physical Diagnosis Summary ............................................................ 12-40

Physical Diagnosis: Subnets ........................................................................................ 12-41
se
Physical Diagnosis: Bridge Extraction ........................................................................ 12-42

U

ed
Unit 13: Conclusion

ct
Agenda ........................................................................................................................... 13-1

tri
After Units 1-4, You Can Now ...................................................................................... 13-2

es
After Unit 5-8, You Can Now........................................................................................ 13-3

After Units 9-12, You Can Now .................................................................................... 13-4
R
On Demand Training ..................................................................................................... 13-5

Documentation on SolvNet ............................................................................................ 13-6
Reference Methodology Scripts ..................................................................................... 13-7
SolvNet: TetraMAX Reference Methodology ............................................................... 13-8
Course Evaluation .......................................................................................................... 13-9
Synopsys 30-I-021-SSG-017 xiii TetraMAX Workshop

Table of Contents
Thank You! .................................................................................................................. 13-10

Appendix ...................................................................................................................... 13-11
How to Download Lab Files (1/2) ............................................................................... 13-12
How to Download Lab Files (2/2) ............................................................................... 13-13
ng
ni
ai
Tr
ip
ch
ro
ic
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Synopsys 30-I-021-SSG-017 xiv TetraMAX Workshop

TetraMAX
ng
ni
2017.09
ai
Tr
ip
ch
ro
ic
lM
© 2018 Synopsys, Inc. All Rights Reserved Synopsys 30-I-021-SSG-017
Synopsys 30-I-021-SSG-016
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Introduction & Overview ©2018 Synopsys, Inc. All Rights Reserved. i-1
TetraMAX Workshop For Internal Microchip Training Purposes Only
Facilities
Building Hours Meals
ng
ni
Emergency EXIT Smoking
ai
Tr
Restrooms Recycling
ip
ch
ro
Please turn off or silence your cell phone
ic
i- 2
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Workshop Overview
ng
ni
 This workshop will cover the entire ATPG flow
ai
 Includes the following steps:
Tr
 Generate test patterns given a scan gate-level design created by DFT
Compiler or other tools
ip
 Debug DRC and Stuck-At coverage problems using the GUI
ch
 Save and validate test patterns in simulation
ro
 Generate and validate At-Speed patterns using OCC
ic
 Diagnose failures on the ATE
i- 3
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Target Audience
ng
DFT and Test engineers who perform ATPG
for ASIC or SoC designs
ni
ai
Tr
ip
ch
ro
ic
i- 4
lM
na
SoC System On a Chip

er
DFT Design for Test

nt
RTL Register Transfer Level, for example, VHDL and

rI
Verilog
ATPG Automatic Test Pattern Generation
Fo
P&R Place and Route, also known as layout

se
U
ed
ct
tri
es
R
Workshop Prerequisite Knowledge
 Knowledge of Design For Test, scan insertion flows, and/or ATPG is

helpful but not necessary for this workshop
 Basic design concepts and terms are assumed:
ng
 Verilog or VHDL
ni
 UNIX environment for lab work
ai
Tr
ip
ch
ro
ic
i- 5
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Introductions
 Name
 Company
ng
 Job Responsibilities
Relevant Experience
ni

ai
 Main Goal(s) and Expectations for this Course
Tr
ip
ch
ro
ic
i- 6
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Agenda
DAY
1
i Introduction
ng
ni
1 Introduction to Test and TetraMAX
ai
Tr
2 Building ATPG Models
ip
3 Running DRC
ch
ro
4 Controlling ATPG
ic
i- 7
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Agenda
DAY
2
5 Minimizing ATPG Patterns
ng
ni
6 Pattern Validation
ai
Tr
7 Fault Models and At-Speed Testing
ip
8 At-Speed Constraints
ch
ro
ic
i- 8
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Agenda
DAY
3
9 Transition Delay Testing
ng
ni
10 On-Chip Clocking (OCC)
ai
Tr
11 Path Delay Testing
ip
12 Diagnosis
ch
ro
13 Conclusion
ic
i- 9
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Icons Used in this Workshop
Caution.
Recommendation
Non-intuitive tool behavior
ng
ni
ai
Question Avoid
Tr
ip
Lab Exercise Group Exercise
ch
ro
ic
i- 10
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Agenda
DAY
1
i Introduction
ng
ni
ai
Tr
ip
3 Running DRC
ch
ro
4 Controlling ATPG
ic
1- 1
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Introduction to Test and TetraMAX ©2018 Synopsys, Inc. All Rights Reserved. 1-1
Unit Objectives
ng
After completing this unit, you should be able to:
ni
 Understand the D-algorithm fault model
ai
 Enter commands to obtain the TetraMAX Stuck-At coverage for a
Tr
full-scan design
 Obtain TetraMAX reference material from the command help, on-
ip
line manual pages or the User Guide
ch
ro
ic
1- 2
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Manufacturing Test Programs
STIL 1.0;




Test



Program

Packaged 

IC Chips
ng
Pass
ni
ATE
ai
Tr
Fail
 Packaged IC chips tested on ATE
ip
 Pass/fail testing proposition
ch
 Looks for chips with physical defects
ro
 Chip is discarded if test fails
ic
 Passing chips go to end user 1- 3
lM
na
Today, automatic test-pattern generation (ATPG) tools generate most test programs; thus, the logic
designer can be increasingly involved in test-program development.
er
nt
ATE: Automated Test Equipment

rI
Fo
se
U
ed
ct
tri
es
R
Stuck-At Fault Model
Fault Model:
A logical model representing the effects of a physical defect
U0/A Stuck-At 1 Fault (SA1):
ng
SA1
Due to a defect, input pin A
A
of U0 acts as if stuck high,
ni
U0 Y
B independent of input signal
ai
Defect at Input
Tr
U1/Y
ip
Stuck-At 0 Fault (SA0): A SA0
ch
Due to defect, output pin Y U1 Y
of U1 acts as if stuck low, B
ro
independent of the inputs
ic
Defect at Output
1- 4
lM
na
The stuck-at fault (SAF) model is still the most prevalent fault model in use today.
Defects land at random locations on a wafer in a semiconductor processing plant.
er
It can therefore be assumed that stuck-at faults can occur anywhere in the logic on a chip.
nt
Any pin on a CMOS gate or flip-flop can be the site of a potential SA0 or SA1 fault.
rI
Chip complexity prevents us from considering stuck-at faults at the transistor level.
Other fault models exist, but a key advantage of the stuck-at model is its simplicity.
Fo
It significantly reduces the complexity of CPU-intensive ATPG algorithms.

se
Technical Reference:
Timoc, Buehler, et al., Logical Models of Physical Failures [Proc. ITC (Oct.1983)], p.546
U
ed
ct
tri
es
R
Rules for Detecting a Stuck-At Fault
Internal Probing
of IC Not Possible!
ng
ni
ai
Tr
ip
Rules of the Game:
ch
Tester access to the device-under-test (DUT)
ro
is only allowed through its primary I/O ports
ic
1- 5
lM
na
Primary port means an I/O port that is directly accessible to external ATE hardware.
This corresponds to a package pin on a chip that has already gone through packaging; thus the ATE
er
can:
nt
Individually drive—or control—the DUT’s primary inputs (PIs).

rI
Individually strobe—or observe—the DUT’s primary outputs (POs).

Fo
se
U
ed
ct
tri
es
R
Combinational Logic: Stuck-At Testing
A
Network N 1
SA0
B U1
Primary
ng
Inputs Z
C
Primary
ni
D
Output
ai
Tr
If this SA0 fault is not present,
Else SA0 fault is present,
ip
then node can be driven to 1.
and U1/Y remains at 0.
ch
ro
This if / else behavior can be exploited to
detect the fault using the D algorithm
ic
1- 6
lM
na
Technical Reference (D algorithm):
er
J. P. Roth, Diagnosis of Automata Failures,

IBM Journal Res. & Dev., Vol. 10, No. 4,
nt
p. 278, July 1966

rI
Fo
se
U
ed
ct
tri
es
R
Activate the SA0 Fault (1/4)
A
U3
Network N 1
1/0
0 B U1
Input
U4
ng
Stimulus
C
ni
U2
D
ai
Tr
Fault-Free
D Algorithm:
ip
Faulty Value
1. Target a specific stuck-at fault.
ch
2. Drive fault site to opposite value. 1/ 0 Legend
(continued)
ro
ic
1- 7
lM
na
Presented now is the classic algorithm for detecting almost any stuck-at fault.
This automated procedure, from IBM in the Sixties, is known as the D algorithm.
er
It detects a stuck-at fault anywhere in combinational logic—yet requires no internal probing.

nt
Since the original 1966 paper, many spin-offs of the D algorithm have been published.
rI
Its fundamental concepts are still essential to understanding most ATPG tools.
Fo
The D algorithm detects one stuck-at fault at a time, making it very CPU-intensive.
The D algorithm creates a discrepancy between the fault-free and the faulty values.
se
The composite logic value 1/0 is often symbolized by D.

The D (for Discrepancy) gives the algorithm its name.
U
ed
ct
tri
es
R
Propagate Fault Effect (2/4)
1 A Observable
0/1 Discrepancy
1/0 U3
0 B U1
1/0
U4
ng
0 C 0
ni
U2
0 D
ai
Enabling Input
Tr
D Algorithm:
ip
The 1/0 is inverted,
1. Target a specific stuck-at fault. but the discrepancy is
ch
2. Drive fault site to opposite value. still easy to measure
3. Propagate error to primary output.
ro
(continued)
ic
1- 8
lM
na
The ATE then strobes this primary output port at a specific time in the test program.
If the ATE sees the expected fault-free response, then the fault is assumed not present.
er
The ATE continues to execute the rest of the test program, targeting other faults.
nt
If it sees the faulty response, the SA0 fault is assumed present, and a failure is logged.
rI
Justification:
Fo
Activating a fault site, and propagating the fault effect, often require justification.
To justify a node means to force a 0 or 1 onto that node, from the primary inputs.
se
In N 1, the OR gate output was justified to 0 by applying 0s to the ports C and D.

U
ed
ct
tri
es
R
Anatomy of a Test Pattern (3/4)
Test Pattern
(U1/Y SA0)
Input
Stimulus Expected
Response
ng
ni
Vector {ALL = 1000 1;}
ai
Tr
Test Pattern:
ip
A sequence of one or more vectors that applies a stimulus
ch
and checks for an expected response to detect a target fault.
ro
ic
1- 9
lM
na
The pattern is shown in STIL syntax as a single vector statement, requiring one cycle.
The alias ALL represents an ordered list of DUT ports, including all the PIs and POs.
er
nt
This test pattern only has one vector; in general, many vectors will be required.
rI
In this workshop, the term test pattern is used just as it is defined in the STIL spec.
A test pattern is a series of one or more vectors comprising a test for a target Stuck-At fault.
Fo
In this workshop, a vector will always correspond to exactly one tester clock cycle.
se
U
ed
ct
tri
es
R
Record the Test Pattern (4/4)
STIL 1.0;
•
•
This pattern detects Pattern "N1_Burst" {
Vector {}
the fault U1/Y SA0 Vector {}
ng
Vector {}
Vector {} Test
Vector {ALL=1000 1;} Program
ni
Vector {} for N 1
Vector {}
ai
Vector {}
Vector {}
Tr
}
D Algorithm:
ip
1. Target a specific stuck-at fault.
Classic
ch
2. Drive fault site to opposite value. “D”
3. Propagate error to primary output. Algorithm
ro
4. Record pattern; drop detected fault.
ic
1- 10
lM
na
The fourth step in the D algorithm is just bookkeeping. The successful test pattern is recorded in
memory, and the detected fault is dropped from the list of target faults.
er
The algorithm is repeated for all the remaining faults, resulting in a test program.
nt
A test program is a series of test patterns that detects all possible faults in the DUT.
rI
Fo
se
U
ed
ct
tri
es
R
Testing Sequential Designs
Can the D algorithm handle flip-flops?
Pre-Scan
Target
Design
Fault
Embedded
1 Network N 1
ng
1/0
0
ni
0
ai
0
Tr
 Still need to activate the fault and propagate its effect
ip
 Require the same ability to control and observe that was available in the
ch
purely combination circuit
ro
 Replace each flop with a testable flip-flop
ic
 This replacement allows serial loading/unloading of bits
1- 11
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Scannable Equivalent Flip-Flop
D 0
Scannable SI D Q Q/SO Multiplexed
1
Equivalent Flip-Flop
for Ordinary SE
Scan Style
D Flip-Flop CLK
ng
CLK
ni
D D Q D Q D Q D Q D Q SO
ai
SI SI SI SI SI SI
SE SE SE SE SE SE
Tr
ip
 The scan equivalent has a serial path from pin SI to SO
ch
 This path is enabled only during testing, by asserting SE
ro
 Scannable equivalent FF’s will be connected SO->SI to form a shift
register also known as a scan chain
ic
1- 12
lM
na
When a normal flip-flop is replaced with a testable flip-flop that is called scan replacement.
The testable flip-flop has two modes:
er
Normal mode—where the ASIC is operating as it was functionally designed to operate.

nt
Test mode—where the ASIC is undergoing manufacturing test.

rI
When the ASIC is undergoing manufacturing test the flip-flips will be connected together just like a
shift register—this configuration is called a scan-chain.
Fo
The scan-chain will be used to serially shift in test patterns to parts of the design which are not
directly accessible to the primary input ports.
se
The compile –scan command in Design Compiler causes the normal flops to be scan-replaced
U
during the synthesis process.

ed
The vast majority of ASICs use a multiplexed flip-flop as the scan-replacement for normal flip-
ct
flops.
tri
es
R
The Full Scan Strategy
Serially preload registers Then capture the fault
with the stimulus, 1000 effect (1/0) into this register
PI1
SI
ng
PI2 PO1
0 1/0
1/0 PO2
ni
SO
PI3
PI4 0
ai
0
Tr
SE
CLK
Serially unload fault effect at SO
ip
ch
A serial path is stitched through all the scan flops, enabling
ro
the ATE to preload registers and capture responses!
ic
1- 13
lM
na
A Full Scan design is one in which all of the flip-flops in the design have been scan replaced and
will be included in the scan-chain.
er
nt
This slide shows the results of stitching a scan-chain (see the red path, starting at the SI port and
rI
ending at the SO port).

Fo
Notice there are three additional ports now: SI (Scan In), SO (Scan Out), and SE (Scan Enable).
The DFT Compiler command to stitch the scan chains is: insert_dft.
se
U
ed
ct
tri
es
R
Scan Testing Protocol

PI1
SI
Targeted
1 SA0 fault


PI2 PO1
0 1/ 0


1/ 0 
PO2
SO
ng
PI3 
 0 
PI4
ni
0
ai
SE
CLK
Tr
C a p tu r e
S c a n S h ift S c a n S h ift
ip
SE
ch
CLK
ro
SI   0 0 0 1  N e x t T e s t P a tte r n
ic
SO R e s u lts F ro m P re v io u s T e s t P a tte r n  1      
1- 14
lM
na
The theta symbol (“”) represents a don’t-care (0 or 1) on an input or output port. The port can be a
either a 0 or a 1 on the ATE. In either case, the value will not affect the ability to detect the
er
currently targeted fault(s).

nt
rI
Fo
se
U
ed
ct
tri
es
R
Test Patterns Overlap
Capture Capture
Scan Shift
ng
... ...
ni
ai
Pattern (n -1)
Tr
Pattern n
ip
ch
 The scan load for a given pattern overlaps the scan unload of the
ro
previous pattern
ic
1- 15
lM
na
Note:
The load of the first pattern does not overlap with an unload since there is was no previous pattern.
er
Likewise, the unload of the last pattern does not overlap a load operation.
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Overview
Common Graphical User Interface
ng
Unified ATPG Engines
Graphical
Basic-Scan Fault
Debugging
ni
Fast-Sequential Simulator
Environment
Full-Sequential
ai
Tr
Stuck-At / Transition
Slack-Based Transition / Path Delay
Parallel Bridging & IDDQ Fault
ip
Processing Diagnosis
Scan Compression
ch
Power-Aware / Cell-Aware
ro
Innovative Library Support
ic
1- 16
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Interfaces
Test
DFT Compiler Procedure STIL
File
Verilog
VHDL
Verilog
EDIF
ng
IC Compiler Netlist Library PrimeTime
ni
ai
SDC,
LEF/DEF Layout Data Slack Data
Tr
EVCD
Functional
Tcl Script TetraMAX Patterns
WGL
ip
STIL
PHDS
Bridging Pairs
ch
ro
Yield Explorer STIL Star-RCXT
Reports
Reports Test Patterns WGL
Vendor Specific
ic
1- 17
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
ATPG Flow in TetraMAX
BUILD
Mode
Verilog sim Read Library Prepare Save
Library Modules ATPG Patterns
TEST
ng
Mode
Gate-level Read Run
Test Patterns
Netlist Netlist ATPG
ni
ai
Tr
Build Review
ATPG Model Coverage Verify
ip
Patterns
ch
DRC
Mode Incremental
ro
STIL Test Check
ATPG
Protocol DFT Rules
(if needed)
ic
1- 18
lM
na
The diagram shown above illustrates the basic test pattern generation flow. The three operation
modes of TetraMAX are shown by different colors. During build mode the design and libraries are
er
read in, and the ATPG model of the design is built. If the build step was successful, TetraMAX will
nt
automatically enter into DRC (design rules checking) mode. If DRC was successful, TetraMAX
rI
will enter Test mode. In Test mode, ATPG settings are adjusted, TetraMAX can start pattern
generation, run incremental ATPG (if required) and save the patterns to disk.
Fo
se
U
ed
ct
tri
es
R
Launching TetraMAX
 To launch TetraMAX
unix% tmax [<command_file>]
The command file is optional - TetraMAX uses Tcl as its command
ng

interface language
ni
 TetraMAX support two execution modes: “GUI mode” (default) and
ai
“shell mode”
Tr
unix% tmax –shell [<command_file>]
In GUI mode, setup a TetraMAX log with the set_messages command
ip

set_messages –log tmax.log –replace
ch
 In shell mode, use the UNIX tee command to create a log
ro
unix% tmax –shell [<command_file>] | tee tmax.log
ic
1- 19
lM
na
TetraMAX also has a legacy command interface mode termed as “native mode”. To launch TetraMAX in “native
mode”:
er
unix% tmax –notcl [<command_file>]

nt
Note: Command and filename completion is supported in Tcl GUI mode only
rI
Note: when in Tcl mode, command options that take more than one argument must be provided with a Tcl list. A
Fo
Tcl list can be denoted by the Tcl “list” command or by curly brackets “{ ... }”. For example:
set_build –black_box {PLL CLKMUL}
se
Or ...
set_build –black_box [list PLL CLKMUL]
U
Note: you can control the general level of message reporting in the TetraMAX logfile with set_messages -
ed
level <expert | standard>. The default is standard level. With the level set to expert, more information
is displayed for many commands.
ct
tri
es
R
Example TetraMAX Script
# Save TetraMAX transcript to log file
set_messages –log lab1.log –replace
# Reading libraries and design

read_netlist ../libs/libs_tmax.v.gz
read_netlist ../libs/rams.v
read_netlist ../design_data/orca_final.v
ng
# Run Build
run_build_model
ni
# Perform Scan Design Rules Check
ai
run_drc ../design_data/orca_final.spf
Tr
# Setup and run ATPG
add_faults -all
# Run ATPG engine(s)
ip
run_atpg -auto
ch
# Review Test Coverage
report_summaries
ro
analyze_faults -class au
report_patterns -summary
ic
# Save Test Patterns
write_patterns all_pats.stil -format stil -replace 1- 20
lM
na
Note: The set_messages command can be used to specify a logfile for the TetraMAX run.
er
In the command file, command names can be shortened as long as they remain “unique”. For
nt
example, read_netlist could be shortened to read_ne. However, it’s recommended to stick

rI
with the full command names for the sake of readability.

Fo
In TetraMAX, at the command prompt, TetraMAX supports command completion by starting a

command and then hitting the TAB key.
se
U
ed
ct
tri
es
R
Tcl API Commands
 Tcl API (Application Programming Interface) commands are used to

access the TetraMAX data structures in Tcl Mode
 Each command returns a collection (not a Tcl list!) of objects with
ng
specific class type
ni
 Classes available are
ai
 Clock, ScanChains, Cell, Pin, Port, Modules, Instances, Timings, Settings, Faults,
Tr
Patterns, Candidates
 Example commands: get_cells, get_pins, get_scan_chains,
ip
get_faults
ch
 The Tcl API can be used to automatic common tasks and/or produce
ro
custom reports
ic
1- 21
lM
na
Limitation:
Tcl API commands are disabled when reading a secure image file. It is not possible for the secure
er
image writer to enable these command as secure

nt
rI
To get Tcl API Introduction

Fundamental Concepts  An Introduction to the TetraMAX Tcl API
Fo
To get to a list of Tcl API commands and links

Commands by Group  Tcl API Commands
se
U
ed
ct
tri
es
R
Using Collections and Filters
 There are several commands to manage collections of objects

TEST-T> help -verbose *collection*
Some examples are:
ng

 foreach_in_collection
ni
 sizeof_collection
ai
 copy_collection
Tr
 Some commands have filtering options to manipulate the collection of
ip
objects returned based on “attributes” – Examples:
ch
TEST-T> set collection_cand [get_candidates -filter "pinpath=~*Z*"]
TEST-T> set collection_cell [get_cells -filter {chain_name == ch1} \
ro
–filter {scan_position == 4}]
ic
TEST-T> set collection_cell [get_cells {[A-U]12} –regexp]
1- 22
lM
na
Tcl documentation on SolvNet:
https://solvnet.synopsys.com/dow_retrieve/B-2011.09/tclug/tclug.html
er
(See section “Working With Collections”)

nt
rI
Fo
se
U
ed
ct
tri
es
R
Retrieving Attributes Values
 List of attributes available per object class can be printed using the
list_attributes command:
list_attributes –class <CLASS_NAME>
ng
 For instance, the attributes for the ScanChains object class are:
TEST-T> list_attributes –class scanchain
ni
Attribute Name Object Type Properties Constraints
---------------------------------------------------------------------
ai
chain_name ScanChains string U
clock_names ScanChains string U
Tr
group_name ScanChains string U
input_pin ScanChains string U
length ScanChains int U
ip
object_class ScanChains string U
ch
output_pin ScanChains string U
 To access a particular attribute, use the get_attribute Tcl command
ro
ic
1- 23
lM
na
Example use of get_attribute – to query the ScanDataIn for a particular scanchain
class object:
er
nt
get_attribute $chain input_pin

rI
Where $chain contains a scanchain object returned by a get_scan_chains command.

Fo
se
U
ed
ct
tri
es
R
Tcl API Example
 Defining a Tcl procedure that returns the longest scan chain length
Declare the procedure
Create collection
ng
of all ScanChains
proc report_scan_chain_max {} {
set max_length 0
ni
foreach_in_collection chain [get_scan_chains -all] {
if { [get_attribute $chain length] > $max_length } {
ai
set max_length [get_attribute $chain length]
Tr
}
}
return $max_length
ip
}
ch
Access the “length” attribute
ro
Return the chain length
of each ScanChain object
ic
1- 24
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX On-Line Help (OLH)
 Command-line help and man

help –v read_netlist
ng
man S22
ni
 GUI On-Line Help Menu
ai
HELP  Table Of Contents  Violations  S22
Tr
 Standalone OLH (will not check out a license):
ip
UNIX: tmax –man &
ch
Browser: OLH is HTML based and can be run from most
ro
standard web browsers
ic
1- 25
lM
na
SolvNet Article ID: 024551 – How to Set Up Browser-Based TetraMAX Online Help in
Windows
er
nt
SolvNet Article ID: 027105 – TetraMAX Help in CHM Format

rI
If TetraMAX can’t locate your browser for launching the OLH, you can provide a path with an
Fo
UNIX environment variable. For example, specify the following environment variable to use
Firefox as your default browser for running Online Help:
se
unix> setenv USER_HELP_BROWSER /usr/bin/firefox

U
ed
ct
tri
es
R
Getting Help - SolvNet Resources
Browse
Docs
Manage
Support Reference
ng
Methodology
ni
Training
ai
Resources
Tr
Search
Docs/Articles
ip
ch
Open a Support
Center Case
ro
ic
1- 26
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Unit Objectives Summary
You should now be able to:

 Understand the D-algorithm fault model
ng
 Enter commands to obtain the TetraMAX Stuck-At
coverage for a full-scan design
ni
 Obtain TetraMAX reference material from the
ai
command help, on-line manual pages or the User
Tr
Guide
ip
ch
ro
ic
1- 27
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Command Summary (Lecture, Lab)
%tmax Invokes the TetraMAX graphical user interface (Tcl mode)

%tmax –shell lab.tcl Invokes the TetraMAX command line interface (Tcl mode)
add_faults -all Create a faultlist with all faults
help -v Terse command help
ng
man Detailed on-line manual pages
read_netlist lab_1.v Reads in libraries and design netlists
ni
report_settings Reports current (ATPG, DRC, etc.) settings
ai
report_summaries Reports current fault statistics
Tr
reset_state Resets all non-AU faults to ND
run_build_model Builds ATPG model of design
ip
run_drc lab_1.spf Performs test design rule checks
run_atpg Runs ATPG with current settings
ch
run_atpg -auto Automatic mode of ATPG
ro
set_atpg –merge {high high} Enables ATPG dynamic compaction
ic
1- 28
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Agenda
DAY
1
i Introduction
ng
ni
ai
Tr
ip
3 Running DRC
ch
ro
4 Controlling ATPG
ic
2- 1
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Building ATPG Models ©2018 Synopsys, Inc. All Rights Reserved. 2-1
Unit Objectives
ng
 Describe 2 methods for dealing with missing modules
ni
 Debug a library modeling issue and develop a simple
ai
workaround using TetraMAX modeling primitives
Tr
ip
ch
ro
ic
2- 2
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
BUILD Mode in TetraMAX
BUILD
Mode
TEST
ng
Mode
Gate-level Read Run
Test Patterns
ni
ai
Tr
Build Review
ip
Patterns
ch
DRC
Mode Incremental
ro
STIL Test Check
ATPG
Protocol DFT Rules
(If needed)
ic
2- 3
lM
na
The diagram illustrates the basic test pattern generation flow.
During build mode the design and libraries are read in, and the ATPG model of the design is built. If
er
the build step was successful, TetraMAX will then enter DRC (design rules checking) mode.
nt
rI
Fo
se
U
ed
ct
tri
es
R
Reading the Library Files
 Use NETLIST button or read_netlist command:

BUILD-T> read_netlist mylibrary.v
Example:
ng
BUILD-T> read_netlist /libs/0.18u/*/??DFF*.v
ni
 In case of module duplication when reading in netlists, the default
ai
behavior is to keep the last module definition encountered
Tr
ip
ch
ro
ic
2- 4
lM
na
Netlist type (Verilog, EDIF, VHDL) is automatically detected.
Netlist compression (none, GZIP, proprietary binary) is automatically detected.
er
A single file may have one or more modules

nt
A single read command may use wildcards to match multiple files using the ‘?’ and ‘*’ characters
rI
Fo
se
U
ed
ct
tri
es
R
Cell Models Derived from Simulation Library
TetraMAX Library Support
Synthesis Implementation
Library
ng
ATPG
ni
Simulation
ai
Library
Tr
Simulation
ip
 TetraMAX directly reads structural Verilog libraries
ch
 Eliminates the need for a special set of ATPG libraries
ro
ic
2- 5
lM
na
Structural Verilog libraries are gate-level simulation libraries that use Verilog gate-level modeling
primitives (and, or) and UDPs (User Defined Primitives).
er
TetraMAX does not read in RTL or behavioral simulation libraries, except for memory modeling
nt
which used a limited behavioral-like syntax.

rI
Fo
se
U
ed
ct
tri
es
R
ATPG Model Derivation
 ATPG models are created directly from the structural/functional portion

of simulation models supplied in Verilog (including UDPs)
 Verilog language compiler directives understood:
ng
 `define
ni
 ìfdef
ai
 ìfndef
Tr
 ìnclude
 `celldefine
ip
 `suppress_faults
ch
 ènable_portfaults, etc.
ro
 Behavioral models are not understood by TetraMAX and lead to
modules being treated as black boxes
ic
2- 6
lM
na
TetraMAX reads Verilog simulation libraries. UDPs are an integral part of the Verilog language.
They are essential for describing particular library cells. The TetraMAX library reader therefore
er
supports UDPs.
nt
rI
TetraMAX does not support behavioral models, except for memories. A very limited behavioral
syntax is used to model memories for TetraMAX.
Fo
se
U
ed
ct
tri
es
R
Expect Warnings if Library not “Validated”
DRC warnings reported

during read_netlist
ng
command
ni
ai
Get details on DRC
Tr
warning messages
ip
ch
ro
ic
2- 7
lM
na
A “validated” library is one that is compatible with TetraMAX (i.e. contains only structural
primitives and/or UDPs).
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Duplicate Module Definitions
ng
ni
 By default, if a module definition already exists and a second module with the
ai
same name is read, this will replace the first definition: An N5 violation
Tr
(severity warning) will be issued
 This behavior is adjusted with the set_netlist command or dialog box to
ip
change the redefined_module selection
ch
set_netlist –redefined_module <last | first>
ro
 To prevent module redefinition of any kind, set the N5 rule to severity error:
ic
set_rules n5 error
2- 8
lM
na
By default, when DRC violation’s severity is set to “error”, TetraMAX will abort execution of the
run script when the first error is encountered. This default behavior can be changed with the
er
following command:
nt
rI
set_commands [abort | noabort | exit]

Fo
se
U
ed
ct
tri
es
R
Read Design Netlist
 Use NETLIST GUI button or read_netlist command:

BUILD-T> read_netlist my_asic.v
 The same read_netlist command is used to read both libraries and
ng
design netlist files
ni
 Designs may be described using forms of:
ai
 Verilog structural netlists
Tr
 EDIF structural netlists
 VHDL structural netlists
ip
 Mixtures of the above -- note: beware of naming convention restrictions of each
ch
language
ro
 Netlists may be either flat or hierarchical
Netlists may exist as a single file or multiple files
ic

2- 9
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Build the ATPG Design Model
read_netlist libs/*.v; read_netlist my_asic.v
ng
ATPG Primitive
Model of my_asic
my_asic
ni
run_build_model my_asic
ai
my_asic
_DFF
Tr
nand2
top = my_asic _XOR
FD1
_NOR
ip
EO1
ch
NR2
ro
ic
2- 10
lM
na
The build process is used to choose the top-level module and to build the in-memory design image
necessary for the ATPG algorithm. The build process can also be done at any intermediate level.
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Missing Modules Discovered During Build
Default severity of a B5
DRC violation is “Error”
ng
ni
ai
Tr
ip
ch
ro
ic
2- 11
lM
na
By default the build process will abort when the first B5 violation is encountered. If there are
multiple B5 violations, only the first B5 violation will be reported.
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
How Many Modules Are Missing?
ng
Use report_modules to
find all undefined designs
ni
ai
Tr
ip
ch
ro
ic
2- 12
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Read ATPG Memory Models, If Available
ng
ni
ai
Read any libraries that
Tr
were missed the first time
ip
ch
ro
ic
2- 13
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Define Black Boxes If No ATPG Model Exists
Black boxes are defined

for modules that cannot
be modeled for ATPG
ng
ni
ai
Tr
ip
If Build is successful,
TetraMAX moves to
ch
DRC mode
ro
ic
2- 14
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Empty Boxes Versus Black Boxes
Black Box Empty Box
X Z
X Z
ng
X Z
ni
set_build -reset_boxes; # Clears black & empty box list
ai
set_build –black_box RAM32x8
set_build -empty_box BUS_SWITCH
Tr
# Use Tcl list for multiple black box modules:
set_build –black_box [list RAM32x8 RAM64X8]
ip
# Report all black box modules:
ch
report_modules –black_box
Even when a black-box is declared, it’s best to also read an “empty
ro

shell” (i.e., just port declarations) model so that TetraMAX does not
ic
need to infer the port directions of the black boxed module 2- 15
lM
na
An “empty box” is similar to a black box with the exception that its output pins are not driven (i.e.
TIEZ). These can be used to model a module with tristate-able outputs.
er
nt
Specify an empty box module only if its outputs are actually at Z state during test. The empty box
rI
can be helpful if multiple modules are connected to a bus, but the module outputs are all at Z state.
Using black boxes in this case would result in bus contention.
Fo
Two additional types of ‘box’ models are supported:

se
To make TetraMAX treat a module as a library cell, use the –design_box option. TetraMAX
U
will then add faults to just the ports of this module, but not inside
ed
To maintain the port connections of a level of hierarchy, use the –portfault_box option.
ct
tri
es
R
Mode is DRC…Ignore those Build Violations?
Even though the build

step was successful,
violations reported may
ng
need further investigation
ni
ai
Tr
ip
ch
ro
ic
2- 16
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Investigate Each N and B Warning
ng
ni
ai
Tr
ip
ch
ro
ic
2- 17
lM
na
Check the “What’s Next” section in the TetraMAX On-Line Help man page for a DRC violation, to
learn more about what to do if that violation is encountered.
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Did All of the Cells Translate Properly?
 To quickly answer this question, use the report_modules –summary

command
 Look for unsupported behavioral and errors
ng
These indicate that an ATPG model may not be correct
ni
DRC-T> report_modules –summary
ai
Modules: #UNKNOWN_FORMAT=2 #STRUCT_VERILOG=654
(#unsupported_beh=97) #BEH_VERILOG=3 #COMB_UDP=42 #SEQ_UDP=334
Tr
ip
DRC-T> report_modules –errors
ch
ro
ic
2- 18
lM
na
Although TetraMAX attempts to translate vendor cell descriptions into ATPG gate equivalent
models, this automatic translation is not always successful. For example, it is quite common to
er
experience “N” rule violations when reading libraries.

nt
rI
In general, this topic is important for library developers, as they have to deliver certified libraries.
TetraMAX users should always look for library problems to make sure TetraMAX does not
Fo
generate wrong patterns due to library issues. It is beneficial for TetraMAX users to have at least a
basic idea of how to debug library issues, just in case.
se
The important question is: Did all of the cells translate properly? Use the -summary option of the
U
report_modules command and look for any X detectors or Errors indicated, either of which
ed
will indicate an ATPG model that may not be suitable for use.
ct
To review specific modules on which errors were encountered use the -error option of
report_modules. Once a module which had an error or other problem such as N13 or N24 is
tri
identified, the connectivity information of the module can be reported as one way to reveal how the
es
module was translated.

R
The Verilog parser attempts to classify each module read as structural (STRUCT_VERILOG) or
behavioral (BEH_VERILOG). If it can’t tell, the module is classified as UNKNOWN_FORMAT.
Graphical Schematic Viewer (GSV)
Open/Close GSV
Toolbar
Buttons
Cell
ng
Name
ni
ai
Tr
ip
Primitive ID
ch
ro
ic
Net Fanout
Gate Info (RMB->”Display Gate Info”)
Point
2- 19
lM
na
Items displayed in the GSV can be controlled via the command line as well. See the man pages of
the following commands for more information:
er
nt
add_display_gates
rI
remove_display_gates
report_display_gates
Fo
Information about a particular primitive can be reported by the report_primitives command.

se
U
ed
ct
tri
es
R
Design View vs. Primitive View In GSV
Scan Flip-Flop in Design View (vendor cell fdmf1a3)
ng
ni
ai
Tr
Scan Flip-Flop in Primitive View (TetraMAX DFF and MUX)
ip
ch
ro
ic
2- 20
lM
na
When determining the “design” level, by default, TetraMAX will look for `celldefine compile
directives when the library was read into TetraMAX.
er
nt
If `celldefine statements are not in the library, TetraMAX will set the design level at any module
rI
that only contains Verilog primitive or UDPs. Or if read_netlist –library is used, then
any module defined in that netlist will be considered a design level cell (i.e. a library cell).
Fo
The “design” level can also be referred to as the “standard cell” level or the “leaf cell” level.
se
The symbol for a gate primitive and primitive ID can sometimes be seen even in the “design view”.
U
This is normally the case for simple gates such as buffers or inverters.
ed
ct
tri
es
R
Prefer to Debug ATPG Models Graphically?
The run_build_model
command can be run at any
level, not just the top-level
run_build_model PROBLEM_CELL
ng
ni
Open GSV, SETUP = Primitive
ai
Tr
Show All
ip
ch
Review Model Accuracy
ro
ic
2- 21
lM
na
Perhaps the easiest technique for reviewing the derived ATPG model is to look at the model
graphically.
er
Do this by:
nt
• Performing run_build_model on the specific module by name

rI
• Opening the GSV viewer and selecting SETUP = primitive

• Clicking on the SHOW button in the GSV toolbar, and from the pop-up menu, select ALL
Fo
The resulting graphical schematic will present the ATPG model in terms of the tool’s ATPG
primitives.
se
Review the functionality defined by the schematic to help determine if the translation was accurate.
U
ed
ct
tri
es
R
Investigating Models Graphically
 P_LATCH model had an N14 reported during read

 In the GSV it is easy to see the problems with
ng
this model:
 D and SB inputs are floating
ni
 DATA and SET pins are tied to 1
ai
 To see all N14 rule violations:
Tr
report_violations n14
ip
ch
ro
ic
2- 22
lM
na
N14 – “Illegal UDP” : The UDP contains an entry that is not allowed.
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
What If ATPG Models Cannot Be Derived?
 Direct access to ATPG modeling primitives is available for “difficult”

models such as cells with only a behavioral model available
 Model functionality is described by connecting ATPG primitives via a
ng
structural netlist
ni
 Use the TETRAMAX define as a compiler directive in an Verilog
simulation library cell, e.g.:
ai
Tr
ìfdef TETRAMAX
<TetraMAX model>
ip
èlse
ch
<behavioral model>
èndif
ro
ic
2- 23
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
ATPG Modeling Primitives: Partial List
AND ( in1, ..., inN, out );
BUF ( in, out );  A sampling of ATPG modeling
BUS ( in1, ..., inN, out );
BUSK01 inout ; // bus keeper
primitives
 Most primitives take a variable
DFF ( set,rst, clk1,d1, [clkN,dN,]... , out );
ng
DLAT ( set,rst, clk1,d1, [clkN,dN,]... , out );
INV ( in, out ); number of inputs but always have a
single output
ni
MUX ( sel, d0, d1, out );
NAND ( in1, ..., inN, out );
ai
NOR ( in1, ..., inN, out );
 For a complete list, see the on-line
OR ( in1, ..., inN, out );
help topic of “ATPG modeling”
Tr
SW ( control, in, out ); // switch
TIE0 ( [in1, ..., inN,] out );
ip
TIE1 ( [in1, ..., inN,] out );
TIEX ( [in1, ..., inN,] out );
ch
TIEZ ( [in1, ..., inN,] out );
TSD ( ena, in, out );
ro
WIRE ( in1, ..., inN, out );
XNOR ( in1, ..., inN, out );
ic
XOR ( in1, ..., inN, out );
2- 24
lM
na
It may be necessary to create custom ATPG models.
This may be done by instantiating ATPG modeling primitives in a Verilog, EDIF, or VHDL netlist.
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
ATPG Modeling Primitives: Examples
module SCAN_FLOP (SE, D, SDI, CLK, SET, RSTB, Q, QN, SDO);
input SE,D,SDI,CLK,SET,RSTB;
output Q,QN,SDO;
_MUX u1 (SE,D,SDI, din);  Verilog netlists referencing ATPG
_DFF u2 (SET, !RSTB, CLK, din, Q);
_BUF u3 (Q, SDO);
modeling primitives to define ATPG
models
ng
_INV u4 (Q, QN);
endmodule
module buskeep (X);  When used in Verilog, ATPG primitives
ni
inout X;
_BUSK01 X;
must have an underscore (“_”) prefix
ai
endmodule
module dual_latch (RB, G1,D1, G2,D2, QN);
Tr
input RB, G1, D1, G2, D2;
output QN;
ip
_DLAT reg (1’b0,!RB,G1,D1,G2,D2, q);
_INV u2 (q, QN);
ch
endmodule
module grey_box (in1, in2, in3, out1, out2);
input in1, in2, in3;
ro
output out1, out2;
_TIEX u1 (in1, in2, in3, out1);
ic
_TIE0 u2 (out2);
2- 25
endmodule
lM
na
When used in a Verilog netlist, the primitive names must have an underscore prefix, as in “_AND”
When used in an EDIF netlist, the primitive names must have a “&_” prefix, as in “&_AND”.
er
When used in a VHDL netlist, no prefix is needed. Be aware, that a component named “AND” will
nt
have precedence over a primitive named “AND”.

rI
Read in the custom ATPG primitives after the original library has been read.
Fo
Use:
set_netlist –redefined_module last
se
read_netlist mylib.v
read_netlist myprimitives.v
U
ed
ct
tri
es
R
Testability of Embedded Memory
More Silicon
SoC with for Memory
Embedded
Memory
ng
Deeply
uP Core
Embedded
Limited
ni
RAM Memory
Direct
ai
Access Cache
Tr
Logic ROM
Very Dense
ip
Transistor
ch
Implementation
ro
Embedded (on-chip) memory blocks pose SOC test challenges!
ic
2- 26
lM
na
The growing use of embedded, distributed memory blocks on ICs creates testability issues:
Limited Direct Access:
er
Testers can’t control or observe embedded memory blocks directly from the package pins.
nt
Deeply embedded memory (e.g., L1 cache inside a microprocessor core) is even harder to access
rI
for test.
Fo
More Silicon for Memory:

Embedded memory has begun to take up more silicon area than the application logic.
se
The probability of a physical defect landing on or near a memory array is thus higher.
An effective DFT strategy for memory blocks and the surrounding logic is thus crucial.
U
ed
Dense Transistor Implementation:

Vendor SRAM, DRAM, E2PROM and ROM blocks are implemented at the transistor level.
ct
Market forces drive vendors to fabricate memory arrays at the highest density possible.
tri
Gate-level single stuck-at fault models and related algorithms are inadequate at this density.
Memory testing must target multiple stuck-at and bridging faults at the transistor level.
es
R
Memory DFT Strategies
 Testing RAM/ROM for internal faults

 The transistor-level fabric of a RAM/ROM can’t be tested by gate-level stuck-at fault
techniques
 Memory BIST (such as STAR Memory System - SMS) is typically used to test internal
ng
memory faults
 Shadow logic is combinational logic around a RAM/ROM cell
ni
ai
 Testing RAM/ROM shadow logic in ATPG
Tr
1. Applying a black box model:
If there’s no ATPG model for a RAM/ROM cell, it’s often modeled as a black box.
ip
2. Using a bypass mode for Basic-Scan ATPG:
ch
If the memory supports a bypass mode, it can be used to obtain some coverage on the shadow logic.
ro
3. Writing functional models for Sequential ATPG:
Testability of shadow logic can be maximized by replacing the black box RAM/ROM cell with a user
ic
supplied functional Verilog model. 2- 27
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Black Box or Bypass Mode
untestable via Basic-Scan ATPG
 Non-scan sequential cells, including testable via Basic-Scan ATPG
memories, can cause DFT blockages

A RAM
and test coverage issues especially if DO
ng
DI
the cell is modeled as a black box empty
shell
CS
ni
 Bypass Mode: OE
WE
ai
 Bypass the RAM so that some logic around
RAM can be tested with Basic-Scan ATPG
Tr
TM
 Memory IP may support a bypass mode(s).
RAM
If not, a manual RTL fix needed to
ip
A DO
DI
implement the bypass mode
ch
empty
 Memory bypass modes may be CS shell
ro
OE
combinational (shown) or WE
sequential/synchronous
ic
2- 28
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Memory Model
 Using a TetraMAX model untestable via Fast-Sequential ATPG

 Enables Fast-Sequential ATPG to test
testable via Fast-Sequential ATPG
“through” the memory
ng
 Bring write control signal to top-level A RAM DO
ni
ports to: DI TMAX
ai
 Control writes during sequential cycles CS
Model
of RAM
Tr
 Need to control the clock for synchronous OE
WE
memory or WE for a level-sensitive memory
ip
 Protect memory contents during scan shift mem_clk
ch
ro
ic
2- 29
lM
na
The example above is an asynchronous memory, therefore, the write control signal is a
WriteEnable (WE). For synchronous memories, the write control signal would be a WriteClock.
er
In both cases, the write control signal will be defined as a “clock” at the top-level
nt
rI
The write enable/clock doesn’t need to be controlled with a dedicated signal at the top-level. The
memory control/clock can be shared with a functional/scan clock.
Fo
se
U
ed
ct
tri
es
R
Clock Stable and Load Stable
 A memory is “clock stable” if its contents are stable when all clocks are
in their “off state”
 A memory must be clock stable to be usable by ATPG1
ng
 A memory is “load stable” if its contents are stable during scan shift
ni
 Often achieved by gating the WriteEnable or ChipSelect signal of the memory
ai
with ScanEnable
Tr
 Allows ATPG to be more effective by using multiple loads to test faults around the
memory
ip
 Also has the benefit of reducing power during scan shift
ch
 To report the attributes of the memories:
report_memory –all -verbose
ro
ic
2- 30
lM
na
TEST-T> report memory -all -verbose
#ports width address stable off
er
type ID wrt/rd addr/data min/max clk/load val instance_type

nt
---- --- ------ --------- -------- -------- --- ---------

rI
RAM 146 1 1 10 8 0 1023 yes yes X ram1024x8

RAM 149 1 1 9 8 0 499 yes yes X ram512x8
Fo
RAM 150 1 1 6 8 0 63 yes yes X ram64x8

ROM 147 0 1 4 16 0 15 yes yes X rom16x16
se
ROM 148 0 1 5 16 2 31 yes yes X rom32x16

U
1Clock stable is a requirement for the memory to be usable by Fast-Sequential ATPG. Full-
ed
sequential ATPG can also support clock unstable memories.

ct
tri
es
R
RAM/ROM Modeling
 RAMs/ROMs are modeled using a limited Verilog behavioral description

 Memory modeling features supported include:
Multiple read or write ports
ng

 Common or separate address bus
ni
 Common or separate data bus
ai
 Edge or level sensitive read/write controls
Tr
 One qualifier on the write control
 Read off state can hold or return data to 0/1/X/Z
ip
 Asynchronous set and/or reset capability
ch
 Memory initialization files
ro
 A ROM is created by defining a RAM without a write port and is required
ic
to have an initialization file
2- 31
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
RAM Modeling: Basic Example
module MY_ATPG_RAM ( read, write, data_in,

data_out, read_addr, write_addr );  A basic example for a RAM
input read, write;
input [7:0] data_in; // 8 bit data width using limited syntax
input [3:0] read_addr; // 16 words
input [3:0] write_addr; // 16 words behavioral Verilog
ng
output [7:0] data_out; // 8 bit data width
reg [7:0] data_out; // output holding reg
ni
reg [7:0] memory [0:15]; // memory storage  The RAM in this example has
event WRITE_OP; // event for write-thru
level sensitive write and read
ai
// Write port
ports
Tr
always @ (write or write_addr or data_in)
if (write) begin
memory[write_addr] = data_in;
ip
#0; ->WRITE_OP;
end
// Read port
ch
always @ (read or read_addr or WRITE_OP)
if (read) data_out = memory[read_addr];
ro
endmodule
ic
2- 32
lM
na
The port list may vary as more complicated RAMS or ROMS with multiple ports are defined, but
the template is essentially the same.
er
nt
Note that the ATPG modeling of RAMs requires that bussed ports be used.
rI
Fo
se
U
ed
ct
tri
es
R
ROM Model: Basic Example
ROM_8x4.v:
ROM_8x4 module ROM_8x4(ADDR,SINE); Initialization File

input [2:0] ADDR; (Required for ROMs)
output [3:0] SINE;
ng
reg [3:0] SINE; ROM_8x4.dat:
ROM reg [3:0] ROM [0:7];
ni
//Sine Decimal
Submodule initial 0000 // 0.000
$readmemb("ROM_8x4.dat",
ai
0011 // 0.195
ROM ); 0110 // 0.383
Tr
1001 // 0.555
always @( ADDR )
1011 // 0.707
if (ADDR <=7)
1110 // 0.831
SINE = ROM[ ADDR ]; 1111 // 0.924
ip
endmodule 1111 // 0.981
ch
File opened for reading by
Functional Verilog
ro
$readmemb system task
Per TetraMAX Template
ic
2- 33
lM
na
TetraMAX understands a wide variety of RAM/ROM modeling features.
er
Modeling Limitations:
nt
TetraMAX accepts a limited Verilog behavioral syntax for modeling RAM or ROM blocks.
rI
The Verilog code shown above is based on a template copied from TetraMAX on-line help.
For example, the if statement is part of the required template code, and cannot be left out.
Fo
Many types of memories are supported, including RAMs with multiple read/write ports, and
asynchronous set/reset inputs; common or separate address/data buses, with edge- or level-
se
sensitive read/write enables; and memory “read-off” states, with Z outputs.

U
For More Information:

ed
Access TetraMAX Help, under index entries RAM Modeling and ROM Modeling.
For examples of RAM/ROM data initialization, see Memory Initialization Files.
ct
See Appendix for more examples of Memory models in TetraMAX.

tri
es
R
Utility to Generate TetraMAX Memory Models
A Tcl based utility called

# Source the memgen.tcl script “memgen” can be used
source memgen.tcl to generate TetraMAX
memory models
ng
# Declare the Memory signals
set_memgen_signal -port a[9:0] -type MemoryAddress
ni
set_memgen_signal -port wclk -type WriteClock
set_memgen_signal -port rclk -type ReadClock
ai
set_memgen_signal -port din[7:0] -type WriteData
Tr
set_memgen_signal -port dout[7:0] -type ReadData
ip
# Generate the memory model
ch
memgen -output mem.v
ro
SolvNet Article: TCL Script for Generating TetraMAX Memory Models
https://solvnet.synopsys.com/retrieve/018490.html
ic
2- 34
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Want to Quickly Return to DRC Mode?
 First session:
BUILD-T> read_netlist . . .
BUILD-T> run_build_model
ng
DRC-T> write_image pass1.image.gz \
ni
–compress gzip -replace
ai
 A later session:
Tr
BUILD-T> read_image pass1.image.gz
DRC-T> # Ready to resume in DRC mode
ip
ch
ro
ic
2- 35
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

 Describe 2 methods for dealing with missing
modules
ng
 Debug a library modeling issue and develop a
ni
simple workaround using TetraMAX modeling
ai
primitives
Tr
ip
ch
Begin Lab 2: Handling Designs & Libraries
ro
ic
2- 36
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
add_net_connections Alter the behavior of nets or other design aspects
set_scan_ability on non_scan_ff Treats a non-scan flop as a scan flip-flop
build –force Returns to BUILD mode
report_feedback_paths –all Reports all combinational feedback paths
report_modules -errors Detailed on-line manual pages
ng
report_modules -summary Reports summary statistics for modules
report_modules -undefined Reports all modules which are not defined
ni
report_violations n14 -all Reports all n14 violations
ai
set_atpg -merge Enables dynamic ATPG pattern compression
Tr
set_build -black_box Specifies a module to be a black box
set_build -empty_box Specifies a module to be an empty box
ip
set_build -nodelete_unused_gates Keeps unused gates in the ATPG model
ch
set_build -reset_boxes Removes all black, empty, etc. box definitions
set_faults -fault_coverage Report fault coverage in addition to test coverage
ro
set_rules n5 error Raises severity of n5 violation to Error
write_netlist libs_tmax.v.gz Save all library modules in one file
ic
write_patterns Save ATPG patterns to disk
2- 37
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
This page was intentionally left blank.
ng
ni
ai
Tr
ip
ch
ro
ic
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Agenda
DAY
1
i Introduction
ng
ni
ai
Tr
ip
3 Running DRC
ch
ro
4 Controlling ATPG
ic
3- 1
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Running DRC ©2018 Synopsys, Inc. All Rights Reserved. 3-1

Unit Objectives
ng
 List 3 methods of creating an SPF file
ni
 Describe 2 ways of defining timing in TetraMAX
ai
 Name 2 types of procedures used by ATPG
Tr
 Name the 5 high level fault classes
ip
ch
ro
ic
3- 2
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

BUILD
Mode
TEST
ng
Mode
Gate-level Read Run
ni
Verify
ai
Patterns
Tr
Build Review
ATPG Model Coverage
ip
ch
DRC
Mode Incremental
ro
STIL Test Check
ATPG
Protocol DFT Rules
(if needed)
ic
3- 3
lM
na
In DRC mode, all information needed by the TetraMAX to configure the design for test is
specified. The STIL test protocol file (STIL = Standard Test Interface Language) is read in. If DRC
er
was successful, TetraMAX enters TEST mode.

nt
rI
Fo
se
U
ed
ct
tri
es
R

Controlling ATPG: Agenda
DRC Setup
ng
ni
Debugging DRC Violations
ai
Tr
ip
ch
Managing Faults
ro
ic
3- 4
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

How Does TetraMAX Perform Design Rule Checks (DRC)?
 TetraMAX learns information about the design

read_netlist, run_build_model
TetraMAX will automatically perform the N and B rule checks
Questions that need to be answered for TetraMAX:
ng

 What are the Scan Chain Pins?
ni
 How is scan mode enabled for the design?
ai
 What is the initialization sequence for the design?
Tr
 What are the clocks?
 Which clocks are used for shift and capture?
ip
 What is the timing for all the device pins?
ch
 And more questions
 These answers are provided via a STIL Protocol File or by using
ro
TetraMAX Quick STIL commands
ic
3- 5
lM
na
The term “Quick STIL” refers to TetraMAX commands that define aspects of the Test protocol. If
TetraMAX commands are not used to define the Test protocol, then the Test protocol is defined by
er
passing a STIL protocol File (SPF) to TetraMAX.

nt
rI
Fo
se
U
ed
ct
tri
es
R

Partial STIL Protocol File
STIL;
ScanStructures {
ScanChain "chain1" { ScanIn “SDI[1]”; ScanOut SDO[1]; }
ScanChain "chain2" { ScanIn “SDI[2]”; ScanOut SDO[2]; }
}
Procedures {
ng
“multiclock_capture" { W "_default_WFT_";
F { TEST_MODE = 1; }
V { "_pi"=\r 12 #; #: Placeholder for values
"_po"=\r 8 #; }
supplied later during ATPG
ni
}
"load_unload" {
ai
// clocks & resets off; enable scan
V { CLOCK = 0; RSTB = 1; SCAN_EN = 1; TEST_MODE = 1; }
Tr
Shift {
V { _si=##; _so=##; CLOCK=P;} // pulse shift clock
}
ip
}
}
ch
MacroDefs {
"test_setup" {
ro
V {TEST_MODE = 1; CLOCK = 0; RSTB = 1;}
}
ic
} V: Vector Statement – one
ATE clock cycle 3- 6
lM
na
The simplest STIL Protocol File consists of the STIL header, a ScanStructures block, and a
Procedures block containing the load_unload procedure and Shift statement.
er
nt
The load_unload procedure defines test cycles to apply, which will enable the scan chain shift
rI
path. It also defines the ‘Shift’ statement and where within the load_unload it is applied.
The load_unload procedure should: place all clocks at their off states, enable scan chain
Fo
shifting, and disable bidirectional port drivers (if possible).

se
There is usually one top-level port such as “SCAN_EN” which will enable the shifting of scan
chains. The port should be set appropriately inside the load_unload procedure.
U
ed
The Shift statement defines how to shift the scan chains by one bit position. In the Shift statement,
the ‘#’ is a special placeholder which takes on a value from the scan input or scan output data
ct
vector. The example above is from a design with two scan chains so two #’s are used.
tri
The test_setup macro is optional but may be needed to initialize a particular design for test
es
mode.
R

Different Ways to Create a STIL Protocol File
 In order of increasing effort to create:

 Have DFT Compiler create the SPF
 Use Quick STIL commands or the TetraMAX GUI
ng
 Create the SPF manually
ni
 If an SPF is available, to run DRC:
ai
run_drc <spf_file>
Or ...
Tr
set_drc <spf_file>
run_drc
ip
 If using Quick STIL commands only, to run DRC:
ch
run_drc
ro
ic
3- 7
lM
na
If commands are used to define the Test protocol file but a test_setup initialization sequence is
required to enter scan mode, the test_setup sequence can be included in an SPF file and
er
“appended” to the existing protocol with the following command:

nt
rI
run_drc design.spf –append

Fo
Where design.spf contains a MacroDefs (with test_setup) and/or Procedures section.

All other sections of the provided SPF will be ignored.
se
Check the man page of the run_drc command for details on how TetraMAX handles potential
U
conflicts when protocol information is provided with both TetraMAX command and an SPF.
ed
SolvNet Article: 900846 – TetraMAX and STIL

ct
tri
es
R

Writing Out the STIL Protocol File
 In DRC or TEST modes, the SPF file can be written with the command:
write_drc_file <file> [-replace]
ng
 Protocol information provided via Quick STIL commands will be reflected
in protocol file written out with the write_drc_file command
ni
 Quick STIL commands that will increase the protocol information include:
ai
add_clocks
Tr
add_pi_constraints
add_pi_equivalences
ip
add_scan_chains
ch
add_scan_enables
run_drc
ro
ic
3- 8
lM
na
Remember, the preferred method is to have DFT Compiler to automatically create the STIL
protocol file.
er
nt
The default timing produced will be written to be compatible with single-cycle capture.
rI
Fo
se
U
ed
ct
tri
es
R

Using Quick STIL Commands
add_pi_constraints
add_clocks add_scan_chains add_scan_enables
add_pi_equivalences
ng
write_drc_file
ni
Manual SPF Editing
ai
Other Adjust
Tr
load_unload Shift test_setup
Procedures Timing
ip
ch
run_drc
ro
ic
Passing DRC
3- 9
lM
na
The easiest way to generate the STIL protocol file (SPF) from scratch is to specify as much
information as possible, while in DRC mode. Then write out an initial SPF for further editing.
er
The SPF contains:

nt
•Names of scan inputs and outputs

rI
•Which pins act as “clocks”

•Timing definitions for pins, clocks, and measures
Fo
•Constrained ports and equivalence relationships

•Test setup sequence, the test_setup macro
se
•Scan enable sequence, the load_unload procedure

•Scan shift sequence, the Shift procedure
U
•Other design dependent procedures: master_observe, shadow_observe

ed
The more SPF related information that is known at the time of the write_drc_file command
ct
then the more information that can be written into the SPF template.
tri
es
R

Defining PI Constraints
 To hold a port constant during the entire test program, define a PI

(primary input) constraint:
add_pi_constraints 1 ASIC_TEST
ng
 To review the existing list of PI constraints use:
ni
report_pi_constraints
ai
 To review a list of input, output, inout, or all ports use:
Tr
report_primitives [ -pis | -pos | -pios | -ports]
ip
ch
ro
ic
3- 10
lM
na
Constraints can also be defined in the SPF file.
er
Note: If a PI constraint is used along with an SPF, then the PI constraint is only applied to the
nt
capture procedures. Values in other procedures like load_unload are controlled by the states
rI
provided in the SPF.

Fo
Constraints of Z can only be defined for bidirectional or tri-stateable outputs.

se
If DRC checks are going to be run using an SPF file and an add_pi_constraints command is
used, the constraint is applied to the capture procedures only.
U
ed
If DRC checks are going to be run only using Quick STIL commands and an
add_pi_constraints command is run, the constraint is applied to the capture procedures and
ct
the load_unload (Shift) procedure.

tri
es
R

Defining PI Equivalences
 PI equivalences on ports:
add_pi_equivalences [list P1 P2 P3]
ng
add_pi_equivalences ENA_P -invert ENA_N
ni
Defining differential Clocks:
ai

add_clocks 0 CLKP –shift
Tr
add_clocks 1 CLKN -shift
ip
add_pi_equivalences CLKP –differential CLKN
ch
 To review the existing list of PI equivalences use:
ro
report_pi_equivalences
ic
3- 11
lM
na
This command is commonly used to define the relationship of differential inputs.
TetraMAX supports differential inputs for clocks and data ports.
er
However, special consideration is required for differential scan chain inputs.

nt
See TetraMAX Online Help for details.

rI
Fo
se
U
ed
ct
tri
es
R

SPF: PI Constraints and PI Equivalences
STIL;
“W” Statement
ScanStructures { Selects The
ScanChain "c1" { ScanIn SDI2; ScanOut SDO2; } WaveFormTable
ScanChain "c2" { ScanIn SDI1; ScanOut D1; }
} (WFT) Timing
“E” Statement For Procedures {
"load_unload" {
Pin Equivalences W "_default_WFT_";
ng
V { RESETB = 1; SCAN_ENABLE = 1; ASIC_TEST = 1;
CLKP = 0; CLKN = 1; }
Shift { W "_default_WFT_";
ni
V { _si=##; _so=##;
CLKP=P; CLKN=P; } }
“F” Statement For }
ai
“multiclock_capture" { W "_multiclock_capture_WFT_";
PI Constraints E CLKP \m CLKN; // \m reference WFCMap
E P1 P2 P3;
Tr
E ENA_P \m ENA_N; \m references a WFCMap
F {ASIC_TEST=1;} statement in the Signals section:
V { "_pi"=\r 12 #;
"_po"=\r 8 #; } “ENA_N" In { WFCMap { 0->1; 1->0; } }
ip
“\r <n>” Repeat the next }
}
character “n” times
ch
MacroDefs { “#” Placeholder for
test_setup { W "_default_WFT_";
V { ASIC_TEST=1; CLKP=0; CLKN=1; RESET=0; } } value provided by ATPG
}
ro
ic
3- 12
lM
na
PI Equivalences can be defined in the SPF file by use of the “Equivalent” statement or “E” for
short.
er
nt
To define a PI equivalence, every capture procedure, i.e. multiclock_capture, as well as

rI
the load_unload procedure must contain identical E statements in order to imply a PI

equivalence condition.
Fo
A PI constraint translates into a fixed port value during the application of the capture procedures of
se
the STIL protocol file.

U
A PI constraint is also placed on the defined pin during procedures such as the test_setup,
ed
load_unload, and Shift unless explicitly overridden using an assignment statement in the
procedure.
ct
tri
When long strings of assigned values are specified, the repeat syntax can shorten the strings:
\r<count> string_to_repeat<space>
es
R

Defining Clocks
 Defining clocks may be done manually using:

add_clocks <off_state> <port_name> -shift \
-timing <[list period leading trailing strobe]>
ng
Examples:
add_clocks 0 [list clk1 clk2] \
ni
–timing [list 100 45 55 40] –shift
ai
Tr
add_clocks 1 RSTB \
–timing [list 100 45 55 40]
ip
 The –shift option causes the clock to be pulsed in the load_unload
procedure during scan shift
ch
ro
ic
3- 13
lM
na
To check on the list of defined clocks defined either manually or by a STIL protocol file referenced
by a run_drc command use report_clocks.
er
nt
add_clocks . . . -timing {<period> <t1> <t2> <measure_time>}

rI
This option is used to define the test cycle period associated with the clock:
Fo
• t1 is the time of the leading edge of the clock, while

• t2 is the time of the trailing edge of the clock
se
The measure time specifies the time within the test cycle at which the design's output pins will be
U
measured.
ed
If measure_time < t1, then a pre-clock measure protocol is implied.

If measure_time > t2, then an end-of-cycle measure protocol is implied.
ct
tri
The default for timing is: period 100, t1=50, t2=70, measure_time=40.
es
R

Defining Asynchronous Set/Reset
 TetraMAX requires that all ports which affect the stored state of
sequential devices and require a pulsing action within the tester cycle,
be defined as “clocks”
ng
 TetraMAX clocks include:
ni
 Traditional clocks
ai
 Asynchronous set and reset controls of flip-flops and latches
Reset Line gated
Tr
 Read/write controls of RAMS with a ScanEnable
signal (TEST_SE)
ASIC_TEST
TEST_SE
Exception: resets that are used as both
D Q D Q
 F2 F3
...
ip
SE SE
synchronous and asynchronous should Reset
ch
Synchronizer
not be defined as clocks D Q D Q

SE
F0
SE
F1 Internal Reset Line
ro
 Use the following drc option: Inactive During Shift
ic
RSTn
set_drc –allow_unstable_set_reset
3- 14
lM
na
From the TetraMAX OLH for the set_drc command:
er
-allow_unstable_set_resets | -noallow_unstable_set_resets
nt
rI
Specifies whether DFF/DLAT devices with unstable sets or resets are considered DRC violations.
An unstable set/reset condition exists when the control net is internally generated. The default is to
Fo
consider an unstable set/reset a DRC violation. Using the -allow_unstable_set_resets

option allows the presence of internally generated set/resets and allows Fast-Sequential ATPG to
se
use these set/reset-unstable nonscan cells to further improve test coverage. This is especially useful
in at least two situations:
U
ed
1) when a primary input is used as both a synchronous and asynchronous set or reset, and
2) when the scan-enable line is used to gate internal set/reset lines during scan load.
ct
tri
In either case, for better test coverage, the scan-enable input and the primary input acting as both
asynchronous and synchronous reset should not be defined as clocks.
es
R

SPF: Capture Procedures
 Generic capture procedure
"multiclock_capture" { W “_multiclock_capture_WFT_";
F { “TEST_MODE"=1; }
V { "_pi"= \r169 #; "_po"= \r164 #; }}
ng
 Capture procedures for Delay fault patterns that use external clocks
with system_clock launch
ni
"allclock_launch" { W “_allclock__launch_WFT_";
ai
Tr
V { "_pi"= \r169 #; "_po"= \r164 #; }}
"allclock_capture" { W “_allclock_capture_WFT_";
F { “TEST_MODE”=1; }
ip
V { "_pi"= \r169 #; "_po"= \r164 #; }}
ch
"allclock_launch_capture" { W “_allclock_launch_capture_WFT_";
ro
V { "_pi"= \r169 #; "_po"= \r164 #; }}
ic
 The _pi signal group controls the clocks that pulse in each pattern 3- 15
lM
na
For a given capture procedure, the order of events is determined by the Waveform Table Timing
(WFT) referenced by the capture procedure.
er
nt
The “\r” syntax in the SPF means to repeat the next state character <n> times. I.e., “\r169 #”
rI
means to repeat the # state character 169 times. The # character is a placeholder for state values that
will be later provided by ATPG.
Fo
se
U
ed
ct
tri
es
R

SPF: Defining Scan Chains & Scan Enable
 Quick STIL Syntax:

add_scan_chains chain1 SDI1 SDO1 add_scan_chains
reflected in
ng
add_scan_chains chain2 SDI2 SDO2 ScanStructures
add_scan_enables 1 SCAN_EN
ni
add_scan_enables Z BIDI
ai
ScanStructures {
Tr
ScanChain "chain1" { ScanIn SDI1; ScanOut SDO1; }
ScanChain ”chain2" { ScanIn SDI2; ScanOut SDO2; }
}
ip
Procedures { add_scan_enables
"load_unload" { reflected in
ch
V { CLOCK = 0; BIDI = Z; SCAN_EN = 1; } load_unload
Shift {
ro
V { _si=##; _so=##; CLOCK=P;} // pulse shift clock
}
ic
}
}
3- 16
lM
na
STIL keywords must be exactly entered as shown. Keywords on this slide include
ScanStructures, ScanChain, ScanIn and ScanOut.
er
nt
STIL keywords can easily be identified because they are not surrounded by double-quotes and they
rI
have mixed upper- and lower-case letters. For example: STIL will not recognize SCANIN, scanin,
or scanIN as the keyword ScanIn
Fo
The Shift statement defines how to shift the scan chains by one bit position. The ‘#’ is a special
se
placeholder which takes on a value from the scan input or scan output data vector during ATPG.
U
TetraMAX has some predefined signal groups such as “_si” for scan inputs and “_so” for scan
ed
outputs as a shorthand way to reference all scan input and output ports.
ct
When long strings of assigned values are specified, the repeat syntax can shorten the strings:
\r<count> string_to_repeat<space>
tri
For example, in a design with 16 scan chains, Shift statement might be defined as:
es
Shift {
V { _si=\r16 # ; _so=\r16 # ; CLOCK=P;} // pulse shift clock
R

SPF: Controlling Test Mode
 In the simple case, placing the design into ATPG test mode involves
holding a specific top-level port to a constant value:
 Define a PI constraint on the port
 Assign the port to its constrained value in the load_unload and capture procedures
ng
 More complex designs may require multiple pins and/or a specific
initialization sequence:
ni
ai
 Add the test_setup macro procedure to the SPF file
Tr
ASIC_TEST = 1 MacroDefs { STIL state
Status Bits
“test_setup” {
assignments
CONFIG are persistent
ip
V {CONF = 1; CONF_ENABLE = 1; CLK = P;}
V {CONF = 0; } // CLK=P again, CONF_ENABLE still 1
ch
101 1 0 1 V {CONF = 1; }
CONF
F1 F2 F3 V {CONF_ENABLE = 0; CLK = 0;}
ro
CONF_ENABLE 1 }
CLK off at end
}
ic
CLK
3- 17
lM
na
There is no Quick STIL equivalent for test_setup sequences. If Quick STIL commands are
used to define the Test protocol file but a test_setup initialization sequence is required to enter
er
scan mode, the test_setup sequence can be included in an SPF file and “appended” to the
nt
existing protocol with the following command:

rI
run_drc design.spf –append

Fo
Where design.spf contains a MacroDefs (with test_setup) and/or Procedures section.

se
All other sections of the provided SPF will be ignored.

U
Check the man page of the run_drc command for details on how TetraMAX handles potential
ed
conflicts when protocol information is provided with both TetraMAX command and an SPF.
ct
In this example design, ASIC_TEST is not a primary input; therefore, add_pi_constraints

tri
can’t be used alone. This is the case for pin-limited designs, where there is not an pi available for an
ASIC_TEST pin. Existing configuration logic is used here to generate an on-chip ASIC_TEST
es
signal. Bits serially clocked into flip-flops F1, F2, F3 are decoded to generate status signals.
Assume one serial bit pattern is unused in normal operation; then it can be used for test.
R
The penalty is that the configuration register must be initialized before scan shift.
Therefore, a custom initialization sequence must be added to the test protocol.

Where Does TetraMAX Get Timing Info?
 TetraMAX uses a cycle based simulator for DRC analysis

 The simulator does not have timing per-se, but events happen in a specific order
and are applied at specific times on the tester
ng
 The event order and timing come from the test protocol which can
come from several places
ni
 A SPF file written out from DFTC
ai
 Timing specified with Quick STIL commands
Tr
 Default timing in TetraMAX
Timing entered manually into the SPF
ip

ch
 What does TetraMAX do with the timing during?
 DRC: uses the timing values and event order for DRC checks
ro
 ATPG and Fault Sim: timing information is not used
ic
 Pattern Formatting: timing is associated with the output vectors 3- 18
lM
na
The timing in an existing SPF can be modified within TetraMAX by using read_drc and the
update_* commands in the following flow:
er
nt
read_drc <original_SPF_file>
rI
update_wft –wft <name> -period <d> -force <d> –strobe <d>

Fo
update_clock –wft <name> -clock <name> -pulse {<le> <te>}

se
update_scale –wft <name> -unit <ns|ps>

write_drc_file <new_SPF_file>
U
...
ed
run_drc <new_SPF_file>
ct
tri
Note: After specifying the timing modification commands, it is required that you use the
write_drc_file command to write out the modified data. It is also required that you specify
es
the run_drc command with this newly produced file in order to incorporate these changes.
R

Default WaveformTable (_default_WFT)
 Timing defined in DFTC or TetraMAX Quick STIL is saved as waveform

tables in the STIL file
Timing {
WaveformTable "_default_WFT_" {
Period '100ns';
ng
Waveforms {
"_default_In_Timing_" { 01ZN { '0ns' D/U/Z/N; } }
"_default_Clk0_Timing_" { P { '0ns' D; ‘45ns' U; ‘55ns' D; } }
ni
"_default_Out_Timing_" { X { '0ns' X; } }
"_default_Out_Timing_" { HTL { '0ns' X; '40ns' H/T/L; } }
ai
}
}
Tr
}
 STIL uses signal groups to save space
ip
SignalGroups {
ch
"_default_Clk1_Timing_" = '"prst_n"';
"_default_Clk0_Timing_" = '"sdr_clk" + "sys_clk"';
"_default_In_Timing_" = '"pframe_n" + ... "pad[0]"';
ro
"_default_Out_Timing_" = '"pframe_n" + ... "pad[0]"';
"_si" = '"pad[0]" + ... "pad[5]"' { ScanIn; };
ic
"_so" = '"sd_A[0]" + ... "sd_A[5]"' { ScanOut; };
}
3- 19
lM
na
Timing in the STIL protocol file comes from the following DFT-Compiler variables:
er
Variable Name Default Value

nt
test_default_period 100
rI
test_default_delay 0
test_default_bidir_delay 0
Fo
test_default_strobe 40
se
Clock edges are defined as follows:

set_dft_signal –view existing_dft –type ScanClock –timing {45 55}
U
ed
ct
tri
es
R

Pre-clock Measure vs. End-of-cycle Measure
 Two types of timing configurations used on testers

 Pre-clock Measure
Default timing used by TetraMAX and DFTC (recommended)
ng

Force PI’s or SI’s
ni
Measure PO’s M
ai
Pulse clocks
Tr
 End-of-cycle Measure
ip
Alternate timing sometimes used by older testers
ch

Force PI’s or SI’s
ro
Pulse clocks
Measure PO’s
ic
M
3- 20
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

Pre-clock Measure
 When the default pre-clock timing is used, the capture procedure can use
a single vector
"multiclock_capture" {
W “_multiclock_capture_WFT_";
ng
V {"_po" = \r168 #; "_pi" = \r179 #;}
}
ni
Single Vector Capture
ai
test_setup Load Capture Load/Unload Capture
Tr
Shift Shift Shift Shift Shift Shift
PI’s
ip
scan_se
ch
M M M M M M M M
Measure PO’s
ro
clk
ic
3- 21
lM
na
Note: a single vector capture procedure is required for At-Speed ATPG using external clocks
er
Measures (“M”) during Shift will detect faults captured by scan FF’s. The measure during the
nt
Capture procedure will detect faults that fanout to a PO.

rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Design Rule Checks
 Checked during read_netlist, run_build_model:

 N rules (netlist) and B rules (build)
 Checked during run_drc:
ng
 S rules (scan chain or shift)
ni
 C rules (clocks or capture)
ai
 Z rules (internal tristate buses and bidirectional pins)
Tr
 X rules (combinational feedback loops)
 V rules (vector statements in the SPF)
ip
 Other rule categories:
ch
 P rules (Path delay checks)
D rules (Pre-DFT violations)
ro

 R rules (Scan Compression violations)
ic
3- 22
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

Performing Scan Design Rule Checks
Run DRC Checks
ng
ni
ai
Tr
ip
Scan Chain Tracing
ch
ro
ic
3- 23
lM
na
scan design rule checking - This indicates the beginning of the scan design rule checking process.
reading test protocol file - Read the test protocol file and indicate the parsing of the file was successful with
er
no errors
nt
Bus/Wire contention ability checking - Summary the types of bus gates that are used in the circuit. This
includes the total number of bus gates, the number of bidirectional bus gates, the number of weak bus gates
rI
(only weak drivers), the number of pull bus gates (a mixture of strong and weak drivers), and the number of
Fo
bus gates which have a bus keeper.

simulating test protocol procedures - The simulation is used to determine state elements that have a
constant state behavior and those that attain a set value after the scan chain load.
se
scan chain operation checking - The results of the previous simulation are used to verify the operation of
the scan chains and identify the associated scan cells. As each scan chain is successfully verified, a message
U
is given indicating its completion with its name and length.

ed
clock rules checking - During this process many clock rules are checked and messages are given when
violations occur.
ct
nonscan rules checking - The objective of this checking is to determine the appropriate behavior for all non
scan state elements. This includes the nonscan DFFs, nonscan DLATs, and the transparent latch usage. The
tri
next message gives a summary of the calculated nonscan behaviors. DRC dependent learning - Using the
es
behaviors learned during DRC, analyses are performed to determine control ability, observe ability,
constraint effects, and blockages due to constraint effects for all gates in the circuit.
R
contention prevention rules checking – Rules and design behavior affecting contention.
DRC Summary Report - For each rule that had at least one violation, a summary message for that rule is
given indicating the number of times it was violated. The next message indicates the total number of rule
violations that occurred during the DRC process.

Results of Design Rule Checks
 If DRC passes, a DRC Summary

Report will be shown
 When running DRC, if a violation
ng
with a severity of Error is
ni
encountered, DRC fails and the
DRC run is aborted at that point
ai
Tr
ip
ch
ro
ic
3- 24
lM
na
Some DRC rules can be downgraded from an Error to a Warning with the set_rules
command. However, some rules like S1 cannot be downgraded.
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

DRC Setup
ng
ni
ai
Tr
ip
ch
Managing Faults
ro
ic
3- 25
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

 Report violations with report_violations command

report_violations <vio_id|rule_id|rule_type|-all> \
[-instance <name | id>] [-max d]
ng
 Example: report all S-rule violations
ni
report_violations s
ai
 Debug violations with analyze_violation command
Tr
 Example: debug first S1 violation
analyze_violation s1-1
ip
GSV will display gates associated with the violation
ch

 Not all DRC violations support analysis with GSV
ro
ic
3- 26
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

Debugging an S1 Violation
 The S1 DRC uses the event sequence of the simulated shift procedure
 Each scan chain output is traced backwards through combinational and
sequential gates until the scan input is reached
ng
ni
Name of scan chain TetraMAX Gate ID Violation ID
ai
Tr
Error: Chain c1 blocked at DFF gate out_reg (8) after tracing 0 cells. (S1-1)
ip
Position in the scan chain (0
Scan cell
closest to ScanOut)
ch
 So “after tracing 0 cells” means that the violation occured at the
ro
last scan cell in the chain
ic
3- 27
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

Debug S1 Violations Graphically in the GSV
Cannot trace symbolic value “S”

 At the reported scan cell through scan cell to its SI
watch out for:
 Clock signal pulsing?
ng
 ScanEnable active state?
ni
 Set/Reset inactive state?
ai
The reset pin (CDN) is
“X” during shift. Why? Trace path
Tr
ip
In this case, rst was not specified in the SPF file
ch
Define “rst” as clock (best solution):
add_clocks 1 {rst} -timing {100 50 80 40}
ro
ic
3- 28
lM
na
The shift character specified by “set_pindata –shift_character S” (default is “S”) is
used to distinguish valid scan data (SSS) from unconstrained nets (XXX) when viewing the “Shift”
er
pindata in the GSV.

nt
rI
Fo
se
U
ed
ct
tri
es
R

Change Pindata to test_setup to Debug Initialization Issues
Test clock clk not propagated Scan chain blocked because
through multiplexer because of invalid clock signal
select signal is “X”
The default pindata when
analyzing an S1 violation is
shift (best for most situations).
ng
ni
Test mode register has lost its
ai
state after test_setup. Why? By default, the test_setup
pindata only shows the final
Tr
simulated state. To show the
entire test_setup sequence:
ip
set_drc –store_setup
set_pindata –test_setup
ch
ro
In the test_setup the test mode register is
ic
initialized correctly. But does it hold its state
during load_unload and capture? 3- 29
lM
na
Using set_drc –store-setup will increase run time and memory consumption during DRC.
You can control which bits are stored with set_pindata –setup_cycles {n1 n2}
er
Otherwise the GSV may be overcrowded and hard to see for long sequences.
nt
rI
Can also use report_primitives to display the test_setup pindata on the gate primitive
in the Transcript instead of using GSV
Fo
TEST-T> report_prim 55
flop1 (55) DFF (FD1S)
se
--- I () (TIE_0)
--- I () (TIE_0)
U
--- I (0101010) 21-

ed
--- I (XXXXXXX) 22-

--- O (XXXXXXX) 23-
ct
scan_behavior: MASTER(LE/-) chain=c1 cell_id=6 invert_data=NI obs=noproc

tri
set_reset_usage: set=no, reset=no, unstable_flag=no, set_dominance=none,

reset_dominance=none
es
R

Stability Patterns
 To further investigate why the initialized value did not hold its state in
load_unload and capture, look at the stability_patterns pindata
 To view the stability pattern, it also needs to have been stored during
ng
run_drc with the following command:
ni
set_drc –store_stability_patterns
ai
Tr
ip
ch
Required value of 1 loaded The 1 loaded during test_setup
ro
during test_setup is not maintained during capture
ic
Root cause in this case was a missing constraint
that was supposed to recirculate the data 3- 30
lM
na
There are two types of stability patterns
er
T/S/CCC (stability pattern with three sections)

nt
LLLLLS/CCC (stability pattern with two sections)

rI
1) The stability pattern with 3-sections is seen when there is no V statement in load_unload
Fo
before the Shift procedure. I.e., there is no pre-shift vector in load_unload procedure. Where:
se
T is the value on the pin after last cycle in test_setup procedure (you will only see 1 character
here, independent of the number of events in test_setup procedure)
U
S is the value on the pin in shift procedure (1 character only)

ed
CCC is the value on the pin in three different states in capture procedure (3 characters)
ct
2) You will see stability pattern with 2-sections when there are some vectors in the load_unload
tri
procedure prior to Shift. I.e., there are some pre-shift vectors. Where:
es
LLLLLS : here LLLL denote the events in pre-shift vectors (the number of L's depends upon the
number of events before Shift). And the last character in this first section is S, which is the value
R
after final shift.

CCC is the value on the pin in three different states in capture procedure (3 characters)

Simulation Waveform Viewer (SWV)
 Enables faster debugging of DRC test_setup issues
ng
ni
ai
Tr
ip
ch
ro
ic
3- 31
lM
na
TetraMAX’s waveform viewer helps designers quickly isolate and correct the causes of DFT
problems that tend to create project bottlenecks.
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

Using the SWV
 GUI Enabling Commands
set_drc –store_setup // Must store the test_setup to view in GSV/SWV
set_pindata -test_setup // Pindata type is test_setup
 Add gates of interest in GSV  Select a net and add it to waveform
ng
ni
ai
Tr
ip
ch
SWV commands:
ro

add_waveform_signals <pin_pathname | gate_id | -all>
ic
remove_waveform_signals <pin_pathname | gate_id | -all> 3- 32
lM
na
Another way to limit the pindata characters displayed in the GSV is to use:
set_environment_viewer -max_pindata_length d
er
nt
Specifies the length of the simulation string centered around the current wave cursor reference
rI
point. When the value is set to 0, all available simulation pindata values are displayed. Note that the
pindata length count includes all "information" characters displayed between the waveform
Fo
characters. An ellipsis (…) is added to the annotation to signify that only a partial value is
displayed.
se
When you use this with the waveform viewer moving the cursor in the waveform will move the
U
selected pin range around the cursor

ed
ct
tri
es
R

Supported Pindata Types with SWV
 test_setup
 Debug an initialization sequence
 sequential_sim_data
ng
 Look at the results of a
ni
TetraMAX sequential
ai
simulation of pattern data
Tr
 debug_sim_data
 View pattern simulation data an/d
ip
or VCD data from another simulator
ch
ro
ic
3- 33
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

Want to Quickly Return to TEST Mode?
 First Session:
ng
DRC-T> run_drc DUT.spf
TEST-T> write_image pass1.image.gz \
ni
–compress gzip –replace –violations
ai
 A Later Session:
Tr
TEST-T> # Ready to resume in TEST mode
ip
ch
ro
ic
3- 34
lM
na
An image file can be password protected and it’s net name and instances can be “garbled” for extra
security. Furthermore, the user can control which commands can be executed when an image file is
er
read. Image files are covered in more detail in the Diagnosis unit.
nt
rI
Fo
se
U
ed
ct
tri
es
R

DRC Setup
ng
ni
ai
Tr
ip
ch
Managing Faults
ro
ic
3- 35
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

Fault Classes
 DT – Detected: High Level

Fault Class
 DS - detected by simulation
 DI - detected by implication
 PT – Possibly Detected:
ng
 AP - ATPG untestable, possibly detected
Low-level
 NP - not analyzed, possibly detected
Fault Classes
ni
 UD – Undetectable:
UU - undetectable unused
ai

 UO - undetectable unobservable
Tr
 UT - undetectable tied
 UB - undetectable blocked
 UR - undetectable redundant
ip
 AU – ATPG Untestable:
ch
 AN - ATPG untestable, not-detected Use set_faults –summary verbose to see
Low-level fault classes in fault summary reports
 ND – Not Detected:
ro
 NC - not controlled
NO - not observed
ic

3- 36
lM
na
Fault sub classes that are related to loadable nonscan cells
er
D2 - Detected clock fault with loadable nonscan cell faulty value of 0 and 1 (sub class of DT)
nt
P0 - Detected clock fault and loadable nonscan cell faulty value is 0 (sub class of PT)
rI
P1 - Detected clock fault and loadable nonscan cell faulty value is 1 (sub class of PT)
Fo
Fault sub classes that are related to delay testing:

se
DR - robustly detected delay fault (sub class of DT for path delay testing)
TP - Transition Partially-detected (sub class of DT for Slack-Based Transition
U
testing)
ed
AX - ATPG untestable timing exceptions (sub class of AN indicating faults that are
untestable due to timing exceptions)
ct
tri
es
R

Scan Path Faults are Detected by Implication
Chain test applies from SI The pattern expects

a 0011 pattern for all chains to observe the same
0011 pattern on SO
ng
ni
ai
Tr
ip
ch
DRC traces the scan chains through all the scan flops.
The faults on the scan clock, scan enable and scan path
ro
are “detected by implication” (DI) before ATPG
ic
3- 37
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

Faults Classifications Right After DRC
TEST> add_faults –all
88326 faults were added to fault list.
TEST> report_summaries Complete fault list
Uncollapsed Stuck Fault Summary Report
----------------------------------------------- Must be faults on scan chains
ng
fault class code #faults
------------------------------ ---- ---------
Caused by design topology
ni
Detected DT 14666
ai
Possibly detected PT 0
Undetectable UD 44 PI/ATPG constraints,
Tr
ATPG untestable AU 5383 Not 100% Full-Scan,
Not detected ND 68233 and/or need Seq ATPG
ip
-----------------------------------------------
ch
total faults 88326 Most faults start here
test coverage 16.61%
ro
-----------------------------------------------
Have not yet run ATPG
ic
Pattern Summary Report
#internal patterns 0 3- 38
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

PT - Possibly Detected Faults
 A fault is classified as PT when the ATPG Example PT Fault

pattern that detects a fault results in the faulty D Q
machine simulating an X while the good SI
F1
ng
machine simulates a 1 or 0 SE
Cannot
predict
ni
 AP (ATPG untestable, Possibly 0
value of
1 F2/Q
detected): If this driver
ai
D1 U1 Therefore
is disabled to U0/E SA0
An analysis has proven that this fault cannot be test U0
Tr
 is PT
detected under current ATPG settings (this does not D Q
SI 0/Z 0/X
rule out non-ATPG methods)
ip
F0 D Q
SE SI
F2
ch
 NP (Not analyzed, Possibly detected): And this 1/0
SE
enable pin
 An analysis to prove that the fault cannot be 0
ro
has a SA0
D0 U0
detected was not conclusive
ic
 One possible cause is that the abort limit is too low
3- 39
lM
na
Credit may be given for possibly detected faults in the Test Coverage calculation.
The default credit is 50% and may be changed using set_faults -pt_credit 0, for
er
example.
nt
rI
Fo
se
U
ed
ct
tri
es
R

Unused FF Output Pins become UU Faults
D D D
SI Q SI Q D Q SI Q
...0011 ...0011 ...0011 ...0011 ...0011
ng
SE SE SE
1111111 UU UU UU UO
CLK QN CLK QN EN QN CLK QN
F2 F3 LD F4
ni
UU
ai
CLK_1
CLK_2
Tr
Given that all the QN pins are unconnected or unused
ip

ch
 Both the stuck-at-0 and stuck-at-1 faults on the QN pins are classified
as UU
ro
 Unconnected/unused faults with fanout are UO faults
ic
3- 40
lM
na
The UO (undetectable unobservable) class is similar to the UU (Undetectable Unused) class, except
that the UO fault class specifically includes faults on unused gates with fanout (i.e., gates connected
er
to other unused gates). Faults on unused gates without fanout are identified as UU faults.
nt
rI
Fo
se
U
ed
ct
tri
es
R

Actual Tie-offs in Netlist Become UT Faults
ASIC_TEST D Q D Q
F2 F3
SE SE
...
Reset
ng
Tied Pin has Synchronizer
a UT fault
ni
D Q D Q
0
ai
SE SE
F0 F1
1
Tr
Internal Reset Line
RSTn Inactive During Scan
ip
The F0/D pin stuck-at-1 is classified as UT
ch

ro
 It can never be controlled to 0 since it is tied off to 1
ic
3- 41
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

Undetectable Redundant (UR) Fault
Redundant
U2 Gate U1
B
1/0
ng
A U1 U0 Y
ni
C
Undetectable
ai
U3 Stuck-At Fault
Tr
 To avoid an output glitch, designer has added gate U1 but the added
gate does not alter the function Y, and is thus redundant
ip
ch
 Since U1 has no effect, the stuck-at-0 fault is UR
The majority of UR faults are identified during run_atpg
ro

ic
3- 42
lM
na
There are 4 UR faults in this small example. All are stuck-at-0 faults.
U1/Z
er
U1/A
nt
U1/B
rI
U0/B
Fo
se
U
ed
ct
tri
es
R

Constraints Can Create AU Faults
ASIC_TEST is constrained to logic 1 during scan

testing which allows ATE control of the scan clocks.
However, this creates ATPG Untestable faults
ng
ASIC_TEST
ni
D Q D Q
ai
Clock F0 F1
Divider 0 SE SE
Tr
1
CLK
ip
ch
 Both stuck-at-0 and stuck-at-1 on the MUX D0 pin are AU
ro
 Stuck-at-1 for ASIC_TEST is not a tie-off, so it is an AU, not a UT
ic
3- 43
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

Fault Progression from NC to DS
 NC (Not Controlled):
 The starting classification for most faults prior to ATPG
 A way in which to control the fault location to the value opposite the stuck-at value
ng
has not yet been found
ni
 NO (Not Observed):
ai
 Once ATPG controls the NC fault site, it becomes NO
Tr
 The fault site could be controlled but a way to propagate the fault effect to an
observe point, either a scan cell or primary output, has not yet been found
ip
 Ideally, an “NO” fault will become a “DS” fault during ATPG
ch
ro
ic
3- 44
lM
na
A fault site that is always X is also classified as NC since it can never be controlled to a 1 or 0.
Faults can remain NC or NO after ATPG if they are very difficult to control or observe or the ATPG
er
settings are not directing TetraMAX to work long enough.

nt
rI
Fo
se
U
ed
ct
tri
es
R

Defining Nofaults
 The addition of faults to the fault list can be inhibited by defining a set
of faults as “nofaults” prior to adding faults
 Nofaults can be defined with add_nofaults by:
ng
 Pin pathname
ni
 Primitive instance pathname
ai
 Hierarchical instance pathname
Tr
 Module name
 Nofaults can also be defined by placing the fault locations in a Fault
ip
Interface File Format and reading the file:
ch
read_nofaults filename
ro
ic
3- 45
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

Creating a Fault List with Nofaults
 After successfully completing DFT rules checking, declare any
nofaults, then populate the fault list:
Example: Exclude faults in A2D converter and JTAG block
add_nofaults /ANALOG2DIGITAL
ng
12456 faults were added to nofault list.
add_nofaults /ORCA_JTAG_BSR_top_inst
ni
2434 faults were added to nofault list.
add_faults –all
ai
 When the fault list is populated with add_faults, the faults identified
Tr
with add_nofaults will not be added to the fault list
ip
 TetraMAX supports a sampled or partial seeding of faults by using the
ch
-retain_sample option of the remove_faults command:
TEST-T> add_faults -all
ro
87098 faults were added to fault list.
TEST-T> remove_faults -retain 5
ic
Fault sampling finished: #faults reduced from 87098 to 4308
3- 46
lM
na
The commands add_nofaults and add_faults have similar options. Specify nofaults first,
then add the faults.
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

Fault Interface File Format
Type of Fault Site Pin Pathname
Fault Class Other Text - Comments
sa0 DI /CLK ; comments here

sa1 DI /CLK
ng
sa1 DI /RSTB
sa0 DS /RSTB
ni
sa1 AN /i22/mux2/A
ai
sa1 UT /i22/reg2/lat1/SB
Tr
sa0 UR /i22/mux0/MUX2_UDP_1/A
sa0 UR /i22/mux0/A
ip
sa0 DS /i22/reg1/MX1/D
sa0 DS /i22/mux1/X
ch
sa0 DS /i22/mux1/MUX2_UDP_1/Q
ro
sa1 DI /i22/reg2/r/CK
sa0 AP /i22/out0/EN
ic
sa1 AP /i22/out0/EN
3- 47
lM
na
Fault lists can be exported from and imported into TetraMAX.
er
Column 1 - Type of fault site, {sa0, sa1, str, stf}

nt
rI
Column 2 - Class of fault, “--” indicates the fault is equivalent to the last line before it which has
other than “--”
Fo
Column 3 - Pin pathname to the fault site

se
Other text - Treated as comments

U
ed
ct
tri
es
R

Equivalent Faults
Fanout-free net Network N 1

A
B U1
ng
U1/A SA1  U1/Y SA0 Z
ni
C
ai
D
Tr
Equivalent Faults:
ip
A set of faults whose effects cannot be distinguished
ch
at the ATE are equivalent to one another. No test can
be created to tell them apart from one another.
ro
ic
3- 48
lM
na
Intuitively, some faults in network N 1 would seem to be identical in their effects:
er
Functional Equivalence:
Functionally equivalent faults in a network produce the same truth-table output.
nt
Two arbitrary faults are functionally equivalent if no test exists to tell them apart.
rI
Proving this is an NP-complete problem—as CPU-intensive as ATPG itself!

Fo
 Fortunately, many functionally equivalent faults are also structurally equivalent.

se
Structural Equivalence:
U
 Structurally equivalent faults are intuitively equivalent based on local structure.

ed
 A trivial example is the two corresponding faults at the ends of a fanout-free net; thus,
an stuck-at-0 fault at port A is equivalent to the stuck-at-0 at the NAND input pin A.
ct
 Another equivalence is the stuck-at-1 at inverter pin U1/A and the stuck-at-0 at pin U1/Y.
tri
es
Conclusion:
This slide shows how ATPG begins traversing the logic, thinning out the faults.
R
 Only one fault per equivalent fault set is retained—reducing test pattern count.

Fault Collapsing
Nf = 2 ( Ninputs + 1 )
Before
= 6 Collapsing
ng
Nf = ( Ninputs + 2 ) After
ni
= 4
Collapsing
ai
Tr
 The effect of a NAND input stuck-at-0 (SA0) is identical to the output
stuck-at-1 (SA1)
ip
ch
 The fault set { A SA0, B SA0, Y SA1 } is thus an equivalent set
Only one of the equivalent faults needs to be included
ro

Example: Y SA1
ic
3- 49
lM
na
This slide examines structurally equivalent faults for a typical logic gate, a NAND.
It demonstrates that ATPG need consider only four faults out of the original six.
er
This is because a 0 input value to a NAND is controlling—it forces the output to 1.

nt
Intuitively, there exists no test that can distinguish an input stuck-at0 and the output stuck-at-1.
rI
On the slide, the two input stuck-at-0 faults (gold diamonds) have thus been eliminated.
A similar structural equivalence analysis can be applied to any other N-input gate.
Fo
se
U
ed
ct
tri
es
R

Fault List After Collapsing
A Network N 1
ng
Z
ni
C
ai
D After collapsing, only
8 of 32 faults left
Tr
ip
Fault Collapsing:
ch
By testing for only one fault per equivalence set, the fault
ro
population is reduced (or collapsed) which means fewer patterns
ic
3- 50
lM
na
Thinning out all but one fault per equivalent fault set is called fault collapsing.
This slide reveals that, after collapsing, only 8 faults remain in N1 out of 32.
er
Fault collapsing significantly reduces ATPG run time and test-pattern count.
nt
This is one of the techniques TetraMAX uses to efficiently generate test programs.
rI
TetraMAX ATPG uses a mixture of techniques to determine equivalent faults:

Fo
Quickly identifies structurally equivalent faults, using local analysis.

Selectively tries to prove functional equivalence between critical faults; thus TetraMAX
se
rapidly thins a large fault population to a relatively lean one.

U
ed
ct
tri
es
R

Equivalent Faults in the Fault File
sa1 DS A
sa1 -- u_nand/A
sa1 DS u_inv/Z
sa0 -- u_inv/A
sa0 -- B
ng
sa1 -- u_nand/B
sa0 DS u_nand/Z
ni
sa0 -- u_norz/A
sa0 DS Z
ai
sa0 -- u_norz/Z
sa1 -- u_norz/A Equivalent
Tr
sa1 -- u_norz/B Faults
sa1 -- u_nand/Z
ip
sa0 -- u_nand/A
... .. ...
ch
ro
 By default, faults equivalent to the previously listed fault code are
indicated by --
ic
3- 51
lM
na
This slide is a report derived from the fault list that TetraMAX maintains for a DUT.
The legend -- indicates that a fault is equivalent to the previous reported fault.
er
On the slide, faults belonging to an equivalent set are highlighted in the same color.
nt
The fault code DS means that ATPG successfully generated a pattern for that fault.
rI
Code DS stands for detected by simulation.

Fo
set_faults -equiv_code <code_name> | -noequiv_code

Selects the equivalence code to use when reporting uncollapsed faults. The default is to use a
se
double dash "--". Use of -noequiv_code suppresses the use of this character string and uses instead
the fault class of the fault to which this fault is equivalent.
U
ed
ct
tri
es
R

Collapsed vs. Uncollapsed Faults
 The uncollapsed fault list contain faults on ALL faultable pins
 The collapsed fault list contains only “primary” faults (i.e. one fault per
ng
set of equivalent faults)
 TetraMAX processes the collapsed fault list during ATPG but keeps
ni
track of both the collapsed and uncollapsed faults
ai
Tr
 Test Coverage can be reported using either collapsed or uncollapsed
numbers
ip
set_faults -report [-collapsed | -uncollapsed ]
ch
 Fault lists can be saved to files and reported in either the collapsed or
ro
uncollapsed form
write_faults <file> -all [-collapsed | -uncollapsed]
ic
3- 52
lM
na
To improve performance, most ATPG tools identify all equivalent faults and use only a single
member of each fault equivalence class. For example, a stuck-at-0 fault on the input pin of a BUF
er
gate is equivalent to the stuck-at-0 fault on the output pin of the same gate. The collapsed fault list
nt
would contain only one of those faults which is termed the "primary" fault. For a given set of
rI
equivalent faults, the choice of which one is the primary fault is controlled by the equivalency
analysis and is not predictable.
Fo
se
U
ed
ct
tri
es
R

Calculating Test and Fault Coverage
 Test Coverage is defined as the percentage of detected faults divided

by the ATPG detectable faults
ng
DT + (PT * posdet_credit)
Test Coverage =
all faults - (UD + (AU * au_credit))
ni
ai
 Fault Coverage calculation also includes UD faults, which do not
Tr
change the static behavior of the design
ip
DT + (PT * posdet_credit)
Fault Coverage =
ch
all faults
ro
posdet_credit = 50% by default
ic
au_credit = 0% by default
3- 53
lM
na
To consider only hard detected faults, use :
set_faults -pt_credit 0
er
nt
There is also a set_faults option to give credit to AX faults:

rI
set_faults -ax_credit <d>

Where <d> defines the percentage of credit given to AX (ATPG Untestable Timing Exceptions)
Fo
faults. The default is 0.

se
The Test Coverage calculations can be further controlled by the –test_coverage_include

and –test_coverage_exclude options of the set_faults command. See the man page
U
for details.
ed
ct
tri
es
R

How to Report Fault Coverage
BUILD-T> set_build –nodelete_unused_gates

. . .
TEST-T> set_faults –fault_coverage
TEST-T> report_summaries
ng
-----------------------------------------------
ni
------------------------------ ---- ---------
ai
Detected DT 82596
Reports Uncollapsed Possibly detected PT 24
Undetectable UD 279
Faults by Default
Tr
ATPG untestable AU 5458
Not detected ND 145
-----------------------------------------------
ip
total faults 88502
fault coverage 93.34%
ch
-----------------------------------------------
-----------------------------------------------
ro
#internal patterns 784
#basic_scan patterns 784
ic
-----------------------------------------------
3- 54
lM
na
By default, TetraMAX only outputs the test coverage percentage whose value does not change
based on “set_build –delete_unused_gates”.
er
nt
If “set_build –nodelete_unused_gates” is specified, the following warning is reported:

rI
Warning: Unused gate deletion affects fault coverage calculation (M245)

Fo
se
U
ed
ct
tri
es
R

Adding Faults / Saving Faults
 Fault sites locations of a given fault model can be added to the fault
list for all locations (-all), specific pin pathnames, specific instance
names, or module names
ng
add_faults <pin_path | inst_name | -module <name> | -all>
ni
 Faults can also be defined by placing the fault locations in a Fault
Interface File Format and reading the file:
ai
read_faults filename
Tr
 Once faults are populated, save all faults or just specific classes:
ip
write_faults my_asic_all.flt –replace –all
ch
write_faults my_asic_au_nd.flt –replace –class {au nd}
ro
 Fault files for SoC designs can be huge:
ic
write_faults my_asic_all.flt.gz –all –compress gzip
3- 55
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R


 List 3 methods of creating an SPF file
ng
 Describe 2 ways of defining timing in TetraMAX
Name 2 types of procedures used by ATPG
ni

ai
 Name the 5 high level fault classes
Tr
ip
ch
Begin Lab 3: Running DRC
ro
ic
3- 56
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

add_clocks Defines a clock, set/reset or RAM control

add_pi_constraints Defines a constrained value for a PI
ng
add_pi_equivalences Defines an equal/opposite relation for Pis
add_scan_chains Declares the scan PI/PO for a chain
ni
add_scan_enables Defines a constrained value for a PI to enable shift
ai
report_pi_constraints Reports currently defined PI with constraints
Tr
report_primitives Reports all primary inputs, outputs, etc.
run_drc DUT.spf Performs design rule checks using a STIL file
ip
source commands.tcl Executes the commands store in a file
write_drc_file my.spf Creates on disk the test protocol in STIL format
ch
ro
ic
3- 57
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

ng
ni
ai
Tr
ip
ch
ro
ic
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

Agenda
DAY
1
i Introduction
ng
ni
ai
Tr
ip
3 Running DRC
ch
ro
4 Controlling ATPG
ic
4- 1
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Controlling ATPG ©2018 Synopsys, Inc. All Rights Reserved. 4-1

TetraMAX Workshop
Unit Objectives
ng
 Describe when and how to use -abort limit
 Describe when and how to use -capture_cycles
ni
ai
 Debug Low Fault Coverage
Tr
 Name some differences between TetraMAX and TetraMAX II
ip
ch
ro
ic
4- 2
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
BUILD
Mode
TEST
ng
Mode
Gate-level Read Run
ni
Verify
ai
Patterns
Tr
Build Review
ATPG Model Coverage
ip
ch
DRC
Mode Incremental
ro
STIL Test Check
ATPG
Protocol DFT Rules
(if needed)
ic
4- 3
lM
na
TEST Mode is entered if DRC was successful. In TEST mode, the following operations are typical:
adjust settings for ATPG, start pattern generation, run an incremental ATPG if needed, and save the
er
patterns to disk.
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Running ATPG
ng
ni
Post-ATPG Analysis
ai
Tr
ip
ch
TetraMAX II
ro
ic
4- 4
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Running ATPG
 The command to configure various run options for ATPG is set_atpg

 The set_atpg command includes dozens of command options – some
of the more commonly used ones are:
ng
-abort_limit, -capture_cycles, -num_processes,
ni
-num_threads, -parallel_strobe_data_file, -patterns,
-power_budget, -verbose
ai
Tr
 The command to run ATPG is run_atpg
 Best starting point for tradeoff of coverage, pattern count, and runtime
ip
run_atpg –auto_compression
ch
 Some other commonly used command options are:
ro
-nodisturb_clock_grouping, -only_chain_test,
ic
-only_chain_diagnosis, -optimize_patterns
4- 5
lM
na
More info on the set_atpg command options mentioned above:
-abort_limit <n> - Specifies the maximum number of remade decisions before terminating a test
er
generation effort during the Basic-Scan and Fast-Sequential ATPG algorithms.

nt
-capture_cycles <n> - Sets the Fast-Sequential ATPG algorithm effort level.

-num_processes <n>- Specifies the number of slave processes to be used for multicore ATPG.
rI
-num_threads <n> - Specifies the number of threads for multithreading with TetraMAX II.
Fo
-parallel_strobe_data_file [psd_file] - Generates a parallel strobe data (PSD) file used for
debugging parallel simulation failures.
-patterns max_patterns - Specifies the termination of the ATPG effort when the pattern count
se
equals or exceeds the specified value.

-power_budget <n> - Sets a power (switching) budget for the Power Aware ATPG feature.
U
-verbose - Extra messages are displayed during the pattern merge operation.
ed
More info on the run_atpg command options mentioned above:

ct
-auto_compression - Selects an algorithm that automatically produces compact patterns and high test
coverage using minimal CPU time.
tri
-nodisturb_clock_grouping - Runs ATPG without disturb clock grouping.

es
-only_chain_test - Specifies ATPG to generate chain test patterns only.

-only_chain_diagnosis - Specifies ATPG to generate only X-tolerant chain test and capture
R
patterns.
-optimize_patterns - Selects an algorithm designed to produce a very compact pattern set with high
test coverage. The trade-off is that this optimization increases the run time by dynamically adjusting the
internal settings, such as abort limits, minimum detects, and merge limits during ATPG.

TetraMAX Workshop
ATPG: Select TetraMAX Engine(s)
 Basic-Scan: very fast, excellent coverage for full-scan

 Fast-Sequential: higher coverage for near-full-scan designs; good for
shadow logic around memories, limited non-scan
ng
 Full-Sequential: powerful engine supporting more complex designs
ni
ai
Tr
ip
ch
ro
ic
4- 6
lM
na
TetraMAX’s integrated ATPG engines provide the highest Stuck-At test coverage. Synopsys recommends
starting with Basic-Scan (combinational) ATPG, followed by Fast-Sequential (up to 10 capture cycles) and
er
then Full-Sequential (unlimited capture cycles) if necessary. Full-Sequential is a powerful algorithm, but it
nt
takes longer to run. Run it only on the undetected faults after doing Basic-Scan/Fast-Sequential ATPG. All
these ATPG algorithms are available in a single tool, with a single user-interface.
rI
Basic-Scan (combinational mode) for fast coverage:

Fo
Good for “full-scan”/“near-full-scan” designs.

Requires control of clocks during scan and shift non-transparent latches, memories are
se
black boxed.
Fast-Sequential for increasing coverage on designs and supports (i.e.: can deterministically propagate faults
U
through) load unstable nonscan cells as long as they are stable (in capture cycle) when all clocks are in their
off-state:
ed
Good for designs with Shadow Logic around Embedded Memories.

ct
Note: Limit of 10 “capture cycles”.

Full-Sequential for increasing coverage on designs and fully supporting load unstable nonscan cells.
tri
Note: No limit to the number of “capture cycles”.

es
R

TetraMAX Workshop
Results after Basic-Scan ATPG
TEST> run_atpg –auto
Most NDs are now DTs
. . .
because of ATPG
-----------------------------------------------
ng
------------------------------ ---- ---------
Detected DT 82669
Slight Increase in Number of
ni
Possibly detected PT 23 PTs, UDs and AUs after ATPG
ai
Undetectable UD 103
Tr
Not detected ND 93
-----------------------------------------------
ip
Very Few NDs Remain
total faults 88326
ch
-----------------------------------------------
ro
Pattern Summary Report Have only run Basic-Scan ATPG
ic
-----------------------------------------------
#basic_scan patterns 191 4- 7
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
AU: Untestable under Current ATPG Settings
 The ATPG untestable (AU) fault class includes faults which can neither
be hard detected under the current ATPG conditions nor proved
redundant
ng
 When calculating test coverage, these faults are considered the same
ni
as untested faults because they have the potential to cause failures
ai
 Primary reasons for faults in this classification include:
Tr
 Fault untestable due to a PI, ATPG, or cell constraint which is in effect
 Fault requires sequential patterns for detection
ip
 Fault untestable due to a masked cell or PO
ch
ro
ic
4- 8
lM
na
Faults around non-scan elements (non-scan flip-flops, latches, bus keepers, RAMs) are AU for
Basic-Scan ATPG
er
nt
AX is a sub-class of AU containing faults that are untestable due to timing exceptions.

rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
ATPG: Basic-Scan versus Fast-Sequential
 Basic-Scan: full scan, single capture clock pulse

Faults Between
Scan Registers are
Detectable By
ng
Basic Scan ATPG
SI SO
ni
Scan Registers
ai
 Fast-Sequential: limited amount of non-scan (non-
scan flip-flops, latches, bus keepers, RAMs), multiple
Tr
capture clock pulses possible
ip
Faults Around
If a Nonscan Register
Nonscan
ch
is “Loadable”, it can
Registers Require
be controlled with
Sequential ATPG
Basic-Scan as well
ro
ic
SI Nonscan Registers SO
4- 9
lM
na
Basic-Scan means that there is exactly one capture cycle, i. e. test cycle with active clock and scan
enable set to normal operation mode.
er
nt
Fast-Sequential means there may be from 2 to 10 capture cycles between scan load and unload. By
rI
supporting multiple capture cycles TetraMAX allows full testing of circuitry between non-scan
registers, which would be untestable using Basic-Scan ATPG.
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Loadable Nonscan Cells
 Loadable nonscan cells are nonscan flip-flops or latches that capture

known values during the last shift cycle(s)
 ATPG can control a loadable nonscan cell up to a sequential depth of 1
ng
 Control of loadable nonscan cells is supported by the Basic-Scan and
ni
two-clock ATPG engines
ai
 The additional control allows the more efficient Basic-Scan ATPG
Tr
engine to obtain higher Test Coverage
ip
 Logic and fault simulation can simulate these load values for depths up
to the length of the longest scan chain (max of 10)
ch
 Simulation of loadable nonscan cells is also supported during Fast-
ro
Sequential ATPG
ic
4- 10
lM
na
By control to a sequential depth of 1, this means that ATPG knows it can load a particular value
(0/1) in a nonscan cell that is one level of sequential depth away from a scan cell. This value loaded
er
in the nonscan cell can be used by ATPG to create a pattern to test a targeted fault.
nt
rI
By simulation of loadable nonscan cells, this mean that ATPG can simulate the last n (max of 10)
cycles of scan load to see if any additional nonscan cells will resolve to known values. This allows
Fo
nonscan registers greater than one level of sequential depth away from a scan register to be loaded
with a known value. ATPG is not able to use these values when creating a pattern to target a fault.
se
However, it can use these additional known values to pickup additional detections from an existing
pattern during fault simulation.
U
ed
Note: Full-Sequential ATPG does not support loadable nonscan cells.

ct
tri
es
R

TetraMAX Workshop
Using Loadable Nonscan Cells
 To enable loadable nonscan cells support

set_drc -load_nonscan_cells
Need to also set the number of cycles to simulate when determining
ng

nonscan cell load values
ni
set_simulation -shift_cycles <n>
ai
 Where 1 < n < 10 (and less than longest chain)
Tr
 Reporting nonscan cells
report_nonscan_cells [ load | nonx_load ]
ip
 load: Loadable nonscan cells
ch
 nonx_load: Loadable nonscan cells which always have a non-X value (i.e.,
ro
0 or 1) during the random pattern based analysis performed during run_drc
ic
 Use analyze_nonscan_loading for analysis
4- 11
lM
na
New section printed during run_drc when set_drc –load_nonscan_cells is set:
Begin nonscan rules checking...
er
Nonscan cell summary: #DFF=7 #DLAT=0 #RAM_outs=0 tla_usage_type=none

Nonscan behavior: #LE=7
nt
Load disturbs : #LE=7

Nonscan rules checking completed, CPU time=0.00 sec.
rI
------------------------------------------------------------------------------
Shift_pattern simulation setup completed: #shift_cycles=1, #shift_patterns=3
Shift simulation completed: #shifts=1, #nonscancells_loaded=160
Fo

Nonscan load cell identification completed: #load_nonscan_cells=6
se
Begin DRC dependent learning...

U
ed
ct
tri
es
R

TetraMAX Workshop
Enabling Fast-Sequential ATPG
 If AU faults remain after Basic-Scan ATPG, the Fast-Sequential engine

can help detect faults that require sequential clocking
 To enable Fast-Sequential ATPG, specify the number of
ng
capture_cycles:
ni
ai
set_patterns –histogram_summary
Tr
set_atpg -capture_cycles <d>
run_atpg -auto
ip
ch
[Where <d> is an integer between 2 and 10]
ro
ic
4- 12
lM
na
d = 0 (the default) disables Fast-Sequential ATPG pattern effort and results in Basic-Scan ATPG
patterns.
er
d = 1 is invalid and not accepted.

nt
set_patterns –histogram_summary will enable printing of a histogram that list the

rI
number of patterns for each capture depth as well as the number of multi-load patterns.
-----------------------------------------------
Fo
se
#fast_sequential patterns 47
# 2-cycle patterns 7
U
ed
# 2-load patterns 14
ct
# 3-load patterns 33
-----------------------------------------------
tri
es
The capture cycles option also determines the number of scan loads that are possible. To prevent
TetraMAX from generating patterns with multiple loads:
R
set_atpg –single_load_per_pattern

TetraMAX Workshop
How to Determine –capture_cycles
 Use report_summaries sequential_depths to find the largest
sequential depth for the design
TEST-T> report_summaries sequential_depths
type depth gate_id
ng
------- ----- -------
Control 1 21569
ni
Observe 2 6866
ai
Detect 3 6859
Tr
 The depths show the theoretical maximum depths
 This doesn’t mean that ATPG will be able to detect all faults with that level of
ip
depth if -capture_cycles is set to the same value as the Detect depth
ch
 Recommendation is to start at the Detect depth
Designs with RAM models, recommended start depth is 4
ro

Incrementally increase depth to the point of diminishing returns given
ic

coverage and runtime goals 4- 13
lM
na
Note: it’s not recommended to start with a large number of capture cycles for the initial Fast-
Sequential run. Start with a reasonable setting of capture cycles (2-4). Then in subsequent runs,
er
increase the number of capture cycles incrementally as needed.

nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
When Can Fast-Sequential ATPG Help?
Non-Scan Flops/Latches D Q D Q
TI TI
SE SE
CP CP
CLK
D Q
ng
D Q
Must be stable during capture CP G
when CLK is in its off-state
ni
ai
Embedded
Memories
Tr
Internal
SA0
Tristates
ip
Bus Complex
Keeper Internal
RAM R/W,
RAM
ch
Tristate Clock
Logic controls
ro
ic
4- 14
lM
na
The Fast-Sequential algorithm supports (i.e. deterministically propagates faults through) load
unstable nonscan cells as long as they are stable (in capture cycle) when all clocks are in their off
er
state.
nt
rI
The Full-Sequential algorithm fully supports load unstable nonscan cells.

Fo
Load stable cells can be used by Fast-Sequential by creating patterns with multiple loads. The first
load places a value in a non-scan cell. After the next load, the previously loaded value can be used
se
during capture to detect faults.

U
ed
ct
tri
es
R

TetraMAX Workshop
Results after Fast-Sequential ATPG
Recall: After Basic Scan ATPG After Fast Sequential ATPG
TEST> run_atpg –auto Uncollapsed Stuck Fault Summary Report
. . . More DTs-------------------------------------------
because of
Fast-Sequential
Uncollapsed Stuck Fault Summary Report ATPG
------------------------------------------- -------------------------- ---- ---------
fault class code #faults Detected DT 87644
ng
-------------------------- ---- --------- Possibly detected PT 62
Detected DT 82669 Undetectable UD 129
ni
Possibly detected PT 23 ATPG untestable AU 176
Undetectable UD 103 Not detected ND 315
ai
ATPG untestable AU 5438 -------------------------------------------
Tr
Not detected ND 93 total faults 88326
------------------------------------------- test coverage 99.41%
total faults 88326 -------------------------------------------
ip
test coverage 93.72% Pattern Summary Report
ch
------------------------------------------- -------------------------------------------
Pattern Summary Report #internal patterns 491
ro
------------------------------------------- #basic_scan patterns 195
#basic_scan patterns 191 #fast_sequential patterns 296
ic
Fast Sequential Patterns Added Very Few AUs Remain
4- 15
lM
na
Only the very-hard-to-detect faults remained after running both Basic-Scan and Fast-Sequential
ATPG.
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
How to Enable Full-Sequential Engine
 Enable Full-Sequential ATPG before the run_atpg command:

set_atpg -full_seq_atpg <other_opts>
run_atpg -auto
ng
 To run only the Full-Sequential ATPG engine:
ni
run_atpg –auto full_sequential_only
ai
 When Full-Sequential ATPG might help:
Tr
 Clocks (ordinary clocks, resets/sets, memory writes) to nonscan elements not
controlled from Primary Inputs
ip
 Sequential Detect depth greater than 10
ch
ro
ic
4- 16
lM
na
Note: Full-Sequential ATPG is not compatible with some features and flows.
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
ATPG Guidelines
ATPG Methodology Tips:

 Always run the Basic-Scan engine first
ng
 If sequential ATPG is needed, try running the
Fast-Sequential engine next
ni
 Run the Full-Sequential ATPG engine last
ai
For all ATPG engines and fault models, use run_atpg –auto for the
Tr

best results
ip
 When run_atpg –auto is run, TetraMAX will cycle through all of the
ch
enabled ATPG engines
ro
 ATPG can utilize multiple processor cores to decrease runtime
ic
4- 17
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Multicore Support in TetraMAX
 Utilizes multiple processor cores on the same machine

 TetraMAX launches multiple slave processes to parallelize ATPG work on a single
host
ng
 User can specify the number of processes to launch based on number of CPUs
and available memory on the machine
ni
Multicore supported for ATPG (run_atpg), fault simulation
ai

(run_fault_sim) and pattern simulation (run_simulation)
Tr
 One license supports up to 4 cores
ip
 Each additional license allows 4 more cores
ch
ro
ic
4- 18
lM
na
Writing dual-STIL flow parallel compressed patterns requires run_simulation functionality to
generate the internal data
er
nt
If you observe long write times for these patterns:

rI
set_simulation -num_processes <n>

write_patterns –parallel
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Enabling Multicore Support
 Commands to enable TetraMAX multicore support

 Multicore ATPG:
set_atpg –num_processes <<n>|max>
ng
 Multicore simulation:
ni
set_simulation –num_processes <<n>|max>
ai
 Where <n> is a positive integer to specify number slave processes to be used for
Tr
Multicore
 If max is specified TetraMAX computes the maximum number of processes available
ip
on the host based on number of CPUs
ch
 Command settings are persistent throughout the same
TetraMAX session
ro
ic
4- 19
lM
na
Ensure the machine being used has as many available cores as <n> in set_atpg –
num_processes <n>
er
nt
If multicore is used on a machine that does not have sufficient cores (or memory) available, you are
rI
likely to see a slowdown!

Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Multicore Script Examples
Multicore ATPG Multicore Faultsim

set_messages -log tmax.log -rep set_messages -log tmax.log -replace
read_netlist Libs/*.v -delete read_netlist Libs/*.v -delete
read_netlist gates/top.v read_netlist gates/top.v
ng
run_build_model top_level run_build_model top_level
run_drc top_level.spf run_drc top_level.spf
ni
set_pattterns -external data.vcde \
ai
-strobe {rising CLK} \
–strobe {offset 50 ns}
Tr
… …
add_faults –all add_faults –all
set_atpg –num_processes 4 set_simulation –num_processes 4
ip
… …
run_atpg -auto run_simulation
ch
run_fault_sim
ro
Master log file: tmax.log
ic
Slave log files: tmax.log.1, tmax.log.2, tmax.log.3 etc.
4- 20
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Multicore run_atpg Output
set_messages –level expert

set_atpg –num_processes 2
run_atpg -auto
ng
Starting parallel ATPG with 2 processes.
…
ni
… Master Process Process id Wall Clock Time Shared + Private Pattern Memory
ai
Processes Summary Report
-----------------------------------------------------------------------------
Tr
Process Patterns Time(s) Memory(MB)
----------- ----------- -------------- ---------------------------------
ID pid Internal CPU Wall Shared Private Total Pattern
ip
-----------------------------------------------------------------------------
0 7611 1231 0.53 35.00 67.78 30.54 98.32 5.27
ch
1 7612 626 35.68 35.00 64.87 22.31 87.18 0.00
2 7613 605 35.50 35.00 64.71 22.47 87.18 0.00
Total 1231 71.71 35.00 67.78 75.32 143.10 5.27
ro
-----------------------------------------------------------------------------
ic
Child Processes Total Memory
4- 21
lM
na
Note: To see the process summary report expert level messaging must be enabled with: set_messages –
level expert
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Running ATPG
ng
ni
Post-ATPG Analysis
ai
Tr
ip
ch
TetraMAX II
ro
ic
4- 22
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Post-ATPG: Reducing ND Faults
 The abort limit controls how many times ATPG will re-attempt to detect
a fault (also called remade decisions)
 Raising this limit may reduce the number of ND faults – at the expense of
ng
longer run times and higher pattern counts
ni
 In the Basic-Scan and Fast-Sequential engines the abort limit is set with
the following command:
ai
set_atpg -abort <N> (default is 10)
Tr
 In the Full-Sequential engine the primary control of ATPG effort is
ip
–full_seq_time which specifies the max time (in seconds) to spend
ch
per fault:
set_atpg –full_seq_time <N> (default is 10)
ro
ic
4- 23
lM
na
What is a remade decision?
A decision is remade when a choice of stimulus to sensitize a fault control path or
er
observation path fails to achieve the desired control/observe condition.

nt
rI
Even though –full_seq_time is the primary control for Full-Sequential ATPG, there is also an
abort limit for Full-Sequential that can be set when –full_seq_time is set to zero. E.g.:
Fo
set_atpg –full_seq_time 0
se
set_atpg –full_seq_abort_limit <N>

U
ed
ct
tri
es
R

TetraMAX Workshop
Post-ATPG: Results with Higher Abort Limit
 Higher limit allows both Basic-Scan and Fast-Sequential ATPG to

generate more patterns and increase coverage
ng
ni
ai
Tr
ip
ch
ro
ic
4- 24
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Post-ATPG: Final Abort Limit Results
 Warning: Higher abort limits can result in significantly longer runtime

 Abort limits of 100 to 1000 or more are considered high
Recommendation: Increase abort limit gradually and incrementally
ng

ni
run_atpg –auto
ai
set_atpg –abort 100
Tr
run_atpg –auto
set_atpg –abort 1000
ip
run_atpg -auto
ch
ro
ic
4- 25
lM
na
More information on experimental results seen with gradually increasing abort limit can be found in
this Tutorial from San Jose SNUG 2009:
er
https://www.synopsys.com/news/pubs/snug/sanjose09/wc2_test_tutorial.pdf
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Low Coverage: Review PI Constraints
TEST-T> report_pi_constraints
port_name constraint_value
---------- ----------------
ng
RTFM_CLK 0
THAT can’t be good
ni
TMU_MODE_0 0
ai
TMU_MODE_1 0 Circuit behind MODE is AU
Tr
POW_RST_N 1
Missing RESET coverage
TAP_RST_N 1
ip
TMS 0
ch
Complex MODE
ABCD_CS0_N 0
ro
SCAN_EN 1
This isn’t good, either
ic
4- 26
lM
na
Audit the list of PI constraints. Make sure that only the required PI constraints are listed.
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Low Coverage: Analyze the Clocks
TEST-T> report_clocks –verbose

scan connections nonscan connections
ng
clock_name off clock set reset clock set reset
-------------- --- ------------------ -------------------
ni
RTFM_CLK 0 18 0 0 0 0 0
ai
PIPE_STAT0 0 47511 0 0 851 0 0
Tr
TRACE_SYNC 0 54844 0 0 2124 0 0
A08 0 0 0 0 6070 0 0
ip
RESET 1 0 500 2457 0 23 11
ch
ro
Large # of Nonscan FF’s
ic
4- 27
lM
na
To perform “what if” analysis of the Test Coverage impact if non-scan FF’s were made scanable,
use the set_scan_ability command.
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Are All Expected Flops Scannable?
TEST-T> report_nonscan_cells –summary
ng
Nonscan cell summary: #DFF=12855 #DLAT=3159
#RAM_outs=737 tla_usage_type=X_clock_tla
ni
Nonscan behavior: #CU=184 #C0=184 #C1=2138
ai
#TLA=1045 #LE=12453 #TE=1 #LS=9
#RAM_outs=737
Tr
Load disturbs : #CU=184 #C0=0 #C1=0 #TLA=1045
#LE=5507 #TE=1 #LS=1 #RAM_outs=0
ip
ch
TLA behavior: #no_clock=27, #hot_clock=1016,
#X_clock=2
ro
ic
4- 28
lM
na
C0 (constant zero) - This is a nonscan cell that has been initialized to a 0 state from the test
setup procedure and will always retain that state in the presence of the current PI (primary input) constraints.
er
C1 (constant one) - This is a nonscan cell that has been initialized to a 1 state from the test setup
nt
procedure and will always retain that state in the presence of the current PI constraints.
CU (clock unstable) - This is a nonscan cell that does not have clock-off stability and does not qualify to
rI
be a transparent latch (described below).

Fo
L0 (load 0) - This is a nonscan cell that has been set to a 0 state at the end of the scan chain load, but is not
restricted to always retain the state.
L1 (load 1) - This is a nonscan cell that has been set to a 1 state at the end of the scan chain load, but is not
se
restricted to always retain the state.

TLA (transparent latch) - This is a nonscan DLAT that is not stable when all clocks are off. This allows it
U
the opportunity to behave as a transparent latch when one of its clock inputs is active while the other
ed
clock/set/reset inputs are inactive. The transparency condition must occur at the force_pi time of a pattern
when all clocks are off.
ct
LE (leading edge clock behavior) - This is a nonscan DFF that is stable when all clocks are off and the
clock-off state results in a 0 on its clock input lines. An LE cell captures data on the leading edge of a clock
tri
pulse.
es
TE (trailing edge clock behavior) - This is a nonscan DFF that is stable when all clocks are off and the
clock-off state results in a 1 on its clock input lines. A TE cell captures data on the trailing edge of a clock
R
pulse.
LS (level sensitive behavior) - This is a nonscan DLAT that is stable when all clocks are off.

TetraMAX Workshop
DRC Rules Affecting Coverage
 Make sure to investigate the following rules because they can

adversely affect coverage
 C1, C2, C3, C4, C12, C15, C16, C19, C20, C21, C22, C23, C25, C26, C37,
ng
X1, and Z-rules for example
ni
 Example – C12 violation:
ai
Tr
ip
ch
By default, a C12 violation
will cause the captured
ro
value to be masked
ic
4- 29
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Hierarchical Test Coverage
TEST-T> report_faults -all -level {3 256}
#faults testcov instance name (type)
------- ------- -----------------------
88102 93.60% / (top_module)
ng
86866 93.55% /I_ORCA_TOP (ORCA_TOP)
11734 100.00% /I_ORCA_TOP/I_SDRAM_WRITE_FIFO (SDRAM_WFIFO)
ni
11734 99.81% /I_ORCA_TOP/I_SDRAM_READ_FIFO (SDRAM_RFIFO)
ai
2116 99.24% /I_ORCA_TOP/I_SDRAM_IF (SDRAM_IF)
12788 58.14% /I_ORCA_TOP/I_RISC_CORE (RISC_CORE)
Tr
12008 100.00% /I_ORCA_TOP/I_PCI_WRITE_FIFO (PCI_WFIFO)
11694 99.34% /I_ORCA_TOP/I_PCI_READ_FIFO (PCI_RFIFO)
ip
2344 100.00% /I_ORCA_TOP/I_PCI_CORE (PCI_CORE)
ch
1924 99.95% /I_ORCA_TOP/I_PARSER (PARSER)
19268 99.27% /I_ORCA_TOP/I_BLENDER (BLENDER)
ro
610 100.00% /I_ORCA_TOP/I_PCI_W_MUX (PCI_W_MUX)
ic
610 100.00% /I_ORCA_TOP/I_SD_W_MUX (SD_W_MUX)
4- 30
lM
na
The -level option to the report faults command can be used to display test coverage on a
hierarchical basis.
er
nt
-level <d> <m>

rI
Generates a fault report for specified hierarchical levels. The d argument specifies the hierarchical
depth of the report and the m specifies a minimum number of faults required to display a given
Fo
depth. For example, “-level 6 32” reports faults from the top level down for a total of six
levels, but shows only those hierarchical blocks that had 32 faults or more. When the -level and
se
-all options are specified with an instance, the depth can be calculated based on the specified
instance.
U
ed
Note: The faults associated with top level inputs, outputs, and bidirectional ports are not considered
as "under" the top level of hierarchical and are not included in the counts of the hierarchical report.
ct
Those faults will be included in the top_module level.

tri
es
R

TetraMAX Workshop
Isolate the Impact of the AU Faults
TEST-T> report_faults -class au -level {3 256}
------- ------- -----------------------
5427 93.60% / (top_module)
ng
ni
TEST-T> report_faults -class au -level {4 256}
ai
------- ------- -----------------------
Tr
5427 93.60% / (top_module)
ip
ch
448 83.73% /I_ORCA_TOP/I_RISC_CORE/I_REG_FILE (REG_FILE_ram)
914 11.61% /I_ORCA_TOP/I_RISC_CORE/I_DATA_PATH (DATA_PATH)
ro
3705 0.05% /I_ORCA_TOP/I_RISC_CORE/I_ALU (ALU)
ic
4- 31
lM
na
By combining the -level option and -class option to the report faults command specific
classes of faults can be reported by hierarchy.
er
nt
This example shows the density of AU faults by hierarchy side-by-side with the test coverage by
rI
hierarchy.
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Running Analysis of AU Faults
TEST-T> analyze_faults -class au
Fault analysis summary: #analyzed=4190, #unexplained=369.
952 faults are untestable due to constrain values.
2465 faults are untestable due to constrain value blockage.
58 faults are connected to CLKPO.
ng
16 faults are connected to SHADOW.
17 faults are connected to TIEX.
Note: a fault may belong to
ni
6 faults are connected to TLA.
multiple analysis categories
ai
287 faults are connected to RAM_ADR.
2232 faults are connected to RAM_DATA.
Tr
139 faults are connected to RAM_WRITE.
8 faults are connected to RAM_READ.
ip
89 faults are connected to CLOCK.
9 faults are connected to SET.
ch
11 faults are connected to RESET.
4 faults are connected to TS_ENABLE.
ro
244 faults are connected from CLOCK.
ic
1 faults are connected from TLA.
392 faults are connected from TIEX. 4- 32
lM
na
The analyze_faults command can produce a summary of faults assigned to that class and
possible reasons why the faults were placed in that class.
er
nt
The vast majority of AU faults are due to constrain values, constrain value blockages and
rI
connections to memory data paths.

Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Report More Details of AU Faults
TEST-T> analyze_faults -class AU –verbose –max 10
sa1 AN I_CLOCK_GEN/I_PLL_SD/clk_4x
. . .
ng
sa1 AN I_CLOCK_GEN/U19/S
ni
sa0 AN I_CLOCK_GEN/U16/S0
ai
. . .
sa0 AN I_ORCA_TOP/I_BLENDER/latched_clk_en_reg/Q
Tr
. . .
130 faults are connected from TIEX.
ip
ch
sa1 AN I_CLOCK_GEN/U15/S
ro
sa1 AN I_CLOCK_GEN/U15/D0
ic
sa0 AN I_CLOCK_GEN/U15/D0
. . .
4- 33
lM
na
The -verbose option of the analyze_faults command will produce a detailed report of
reasons why the faults were placed in that class.
er
nt
See the TetraMAX online Help FAQ on “Understanding Reported Data”, analyze_faults for
rI
more information.
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Fault Analysis Source Points
TEST-T> analyze_faults -class AN -source_points 5 0
14 faults are connected from TLA.
10 faults are connected from TIEX. Total of 122 points
Blockage Points - Total 122: explained AN faults
ng
------------------------------------------
o_dout[7] 14.04%
due to blockages
o_dout[6] 14.04%
ni
o_dout[5] 14.04%
o_dout[4] 14.04%
ai
o_dout[3] 14.04% Only 8 points met
o_dout[2] 14.04%
Tr
o_dout[1] 14.04% threshold of 5% of
o_dout[0] 14.04% explained faults
Blockage Value Source Points - Total 1:
ip
------------------------------------------
i_test_se 20.48%
ch
Constraint Value Source Points - Total 6:
------------------------------------------
test_mode1 7.92%
ro
SNPS_PipeHead_test_si7_1 5.73%
SNPS_PipeHead_test_si2_1 5.02%
ic
TEST-T>
4- 34
lM
na
-source_points min_percent max_points
Prints a list of blockage points, blockage value source points, and constraint value source points
er
based on the order of their effect on explained faults. The parameters for this option control the
nt
length of the report. The min_percent parameter is the minimum percentage of explained faults for
rI
the point to be reported. The max_points parameter is the maximum number of points to list in each
category; 0 specifies that there is no limit. This option must be used with the -class option. The fault
Fo
classes are supported: Undetectable (UD) and ATPG Untestable (AU), and any of their subclasses.
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Analyze a Particular AU Fault
AU Due to Constrained Values
ng
The –display option will
ni
show the fault analysis
results in the GSV
ai
Tr
Source of
constraint
ip
ch
ro
ic
4- 35
lM
na
~01 means “can’t be controlled to a 0 or a 1”
er
See the TetraMAX online Help FAQ “Understanding Schematic Data” for more information.
nt
rI
analyze_faults –display drew the highlighted MUX and path back to test_mode PI.
The net connection diamond on the MUX D0 input can be clicked on to display the clk pin driven
Fo
by the TIEX (TX) primitive.

se
TIEX’s come from:

Black box modules
U
Modules with undriven, unconnected outputs

ed
ct
tri
es
R

TetraMAX Workshop
Analyze a Particular AU Fault
AU Due To Constrain Value Blockage
ng
ni
ai
Source of Blockage
Tr
blockage point
ip
ch
ro
ic
4- 36
lM
na
Note: pindata is set to “constrain_value”.
er
See TetraMAX Online help “Understanding Schematic Data” for details:

nt
rI
Examples:
a) X/-,X/-,X/- b) 0/-,0/B,0/- c) X/-,1/B,1/- d) X/-,~01/B,~01/B
Fo
Example A "X/-,X/-,X/-" indicates no constraints and no blocks.

se
Example B "0/-,0/B,0/-" indicates the pin is constrained to 0 due to tied logic, there is also a
constraint of 0 during combinational ATPG which contributes to a blockage. During sequential scan
U
ATPG there is a constraint to 0 but no corresponding blockage.

ed
Example C "X/-,1/B,1/-" indicates a constraint to 1 for both combinational and sequential scan
ct
ATPG, but a blockage due to that constraint only for combinational ATPG.
tri
es
R

TetraMAX Workshop
Hierarchy Browser
 Displays a design’s basic hierarchy

 Enables graphical analysis of coverage
ng
 Launched as a stand-alone window
Supplements the GSV by enabling
ni

graphical analysis of test coverage and
ai
fault information while browsing the
Tr
design’s hierarchy
ip
ch
ro
ic
4- 37
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Tips for Improving Test Coverage
 Without design changes

 Increase abort limit
 Enable Fast-Sequential and Full-Sequential ATPG
Create TetraMAX memory models
ng

More effort
 See if some PI constraints can be eliminated
ni
 Example: PI constraint on an async reset will result in reduced coverage
ai
 With design changes
Tr
 Fix DRC violations
 Many DRC violations have some impact on coverage
ip
 Add scan to non-scan cells
ch
 Use set_scan_ability for what-if analysis
ro
 Add test points
Analyze test points with run_testpoint_analysis
ic

Use run_atpg –observe_file <file> for what-if analysis 4- 38


lM
na
TetraMAX can perform analysis of where might be good locations for test points to improve
coverage. Use the run_testpoint_analysis command. Refer to the appendix of this unit
er
for more details.

nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Functional Pattern Fault Simulation
 Another potential method for improving Test Coverage is to fault

simulate functional patterns targeting faults not detected by ATPG
 Supported by TetraMAX or by Z01X (Synopsys fault simulation tool)
ng
 Features of Z01X:
ni
 Optimized concurrent fault simulator (150M+ primitives)
ai
 RTL & gate level fault simulation
Tr
 Verilog (1995, 2001 & 2005) and SystemVerilog (partial) support
Stuck-At, Transition Delay, Bridge, IDDQ & transient (soft error) faults models
ip

 STIL, WGL, VCD & Verilog testbench stimulus
ch
 Advanced fault classification (28 classes) & reporting
ro
 Import and export of ATPG fault lists
ic
4- 39
lM
na
Note: Z01X is a separate tool from TetraMAX and requires a separate license.
er
Script Example for Functional Pattern fault simulation in TetraMAX:

nt
rI
# Run ATPG first

run_build_model top_mod_name
Fo
run_drc atpg_related.spf
set_faults –persistent_fault_models
se
add_faults -all
run_atpg -auto
U
write_patterns pat.bin -f binary -rep

ed
write_faults atpg.flt -all -rep

ct
# After ATPG, go back to DRC mode for fault sim flow

drc -force
tri
remove_pi_constraints -all
es
remove_clocks -all
set_drc -nofile
R
test
set_patterns -external –strobe_period {20 ns}... my_asic.evcd
run_simulation -sequential
run_fault_sim -sequential

TetraMAX Workshop
Want to Quickly Return Post-ATPG?
 First Session:
DRC-T> run_drc DUT.spf
ng
TEST-T> add_faults –all
TEST-T> run_atpg -auto
ni
TEST-T> write_image pass1.image.gz \
ai
–compress gzip –replace -violations
Tr
TEST-T> write_faults faults.all -all -replace
TEST-T> write_patterns pats.bin –format bin –replace
ip
 A Later Session:
ch
ro
TEST-T> read_faults faults.all
TEST-T> set_patterns –external pats.bin
ic
4- 40
lM
na
An image file can be password protected and it’s net name and instances can be “garbled” for extra
security. Furthermore, the user can control which commands can be executed when an image file is
er
read. Image files are covered in more detail in the Diagnosis unit.
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Interrupting a Long Process
ng
ni
ai
Tr
 When there is the need to abort the current command and any pending
output is not desired
ip
 The “Discard” button will only be visible in the GUI after a user interrupt
ch
is detected (by “Stop” button or “ESC” key)
ro
 When the original command output is discarded/flushed, the “Discard”
button will be hidden
ic
4- 41
lM
na
The Stop button will always be enabled and operational as long as the kernel is still processing the
current command.
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Running ATPG
ng
ni
Post-ATPG Analysis
ai
Tr
ip
ch
TetraMAX II
ro
ic
4- 42
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
TetraMAX II
 TetraMAX II is the Synopsys next generation

ATPG tool that includes support for
multithreading DFTMAX
ng
PrimeTime
 Multithreading allows for more efficient TetraMAX II ATPG
ni
memory usage across multiple threads 10X Faster - 25% Fewer Patterns
when compared to “multi-processor” (3x
ai
StarRC
VCS
reduction on average) Pattern Silicon Fine-grain
Tr
Generation Diagnosis Multithreading
More efficient memory usage allows more
HSPICE

ip
threads to be used by ATPG which will
ch
improve runtime (10x faster on average) Yield Explorer
Includes new ATPG algorithms to reduce
ro

pessimism and decrease pattern count (25%
ic
pattern reduction on average) 4- 43
lM
na
Running TetraMAX II requires an additional add-on license
There are separate licensing options to support 8 threads per license or 20 threads per license
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Running TetraMAX II
 New exec in $SYNOPSYS/bin/

tmax2
When TetraMAX II is launched, the default setting will use 8 threads
ng

 report_settings atpg shows num_threads=8
ni
 report_settings simulation shows num_threads=8
ai
 Threaded ATPG can not be used after invoking tmax
Tr
 Non-threaded ATPG can be used after invoking tmax2
ip
 Just set_atpg –num_threads 0 and set_simulation –num_threads 0
ch
ro
ic
4- 44
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
TetraMAX II Specific Command Options
 Two new command options for TetraMAX II

set_atpg –num_threads <N>
set_simulation –num_threads <N>
ng
 Always set both to same number
ni
 Default is 8
ai
 Set to 0 to disable threading
Tr
 Multicore options have no effect when N > 0
 These are used if execution switches to non-threaded ATPG or simulation
ip
set_atpg –num_processes <P>
ch
set_simulation –num_processes <P>
ro
ic
4- 45
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
When is Threading Used With TetraMAX II
 Commands using threading

run_atpg
run_simulation
ng
run_fault_sim
ni
run_diagnosis (good-machine simulation portion only)
ai
report_power (simulation portion only)
Tr
write_patterns (dual STIL/parallel patterns for simulation)
 All other commands behave identically whether threading is used or not
ip
ch
ro
ic
4- 46
lM
na
Messages when first command using threading is run
Parallel simulation data created for 16 threads
er
#TLA_input_gates=2312 #levels=1 CPU_time=0.00 sec.

nt
Parallel simulation data created for 16 threads

rI
#internal_gates=1876366 #levels=6 CPU_time=1.02 sec.

Message when run_atpg starts using threads
Fo
ATPG will be performed on 16 threads using words of size 64

#collapsed_faults=3100/5730.
se
Note: When chain test is enabled, this is not printed until after chain test generation
Message when run_simulation or run_fault_sim starts using threads
U
Simulation will be performed on 16 threads using words of size

ed
64.
Fault simulation will be performed on 16 threads using words of
ct
size 64.
To confirm: search for the word threads
tri
es
R

TetraMAX Workshop
TetraMAX II Messages: Ignored Settings
 The TetraMAX II ATPG doesn’t make use of all set_atpg settings

 Settings ignored by threaded ATPG are flagged by M724 messages
ng
 The M733 message will confirm that threaded ATPG is being used
Example
ni

TEST-T> run_atpg -auto
ai
The following settings are ignored for threaded ATPG. (M724)
Tr
set_atpg -decision random
set_atpg -lete_fastseq
ip
set_atpg -fast_min_detects_per_pattern 17 40
Starting threaded ATPG with 8 threads. (M733)
ch
 See the “TetraMAX II Command Option Support” section of the OLH for
ro
details
ic
4- 47
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
TetraMAX II Simulation
 TetraMAX generates patterns that can be simulated or fault simulated

with TetraMAX II
 TetraMAX II threaded simulation is better at resolving to non-X values
ng
 TetraMAX II threaded ATPG patterns should not be simulated
ni
(run_simulation) or fault simulated (run_fault_sim) with non-
ai
threaded simulation
Tr
 Non-threaded run_simulation may give got=X mismatches
 run_fault_sim may lead to Possibly Detected (NP) credit for Detected (DS) faults
ip
ch
ro
ic
4- 48
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Other Behavior Differences with TetraMAX II
 TetraMAX II generates the chain test using non-threaded ATPG
 TetraMAX II ATPG (run_atpg –auto) does not generate Parallel Strobe
Data (PSD) file
Use run_simulation to generate PSD file after final pattern set
ng

 TetraMAX adds a dummy cycle to system-clock launch transition
ni
patterns allow slow primary inputs to settle
ai
 Can be disabled by set_delay –noextra_force
Tr
 TetraMAX II never adds a dummy cycle for slow primary inputs
Instead use write_patterns –use_delay_capture_start N
ip

ch
 TetraMAX II may generate 2-cycle patterns for Stuck-At faults by default
 This can happen even with set_atpg –capture_cycles 0
ro
 To prevent 2-cycle pattern generation in TetraMAX II
ic
set_atpg –noextra_cycle 4- 49
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
TetraMAX II Limitations
 TetraMAX II has some feature limitations

 In most cases, when there is a limitation, ATPG will automatically revert
to a non-threaded run and will flag with M729 messages
ng
 The M733 message will confirm the switch to non-threaded - Example
ni
run_atpg -auto
ai
Warning: The following setting requires single-process/multi-core ATPG. (M729)
set_delay -launch_cycle last_shift
Tr
Warning: Feature "fault model" requires single-process/multi-core ATPG. (M729)
ip
Starting single-process ATPG. (M733)
ch
 If num_processes > 0 the M733 message reflects that as well
Starting parallel ATPG with 4 processes. (M733)
ro
ic
4- 50
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop

 Describe when and how to use -abort limit
ng
 Describe when and how to use -capture_cycles
Debug Low Fault Coverage
ni

ai
 Name some differences between TetraMAX and
TetraMAX II
Tr
ip
ch
Begin Lab 4: Controlling ATPG
ro
ic
4- 51
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Command Summary
add_faults -all Create faults on every location not "nofaulted"
add_nofaults Exclude certain faults from the fault list
analyze_faults -class AU Attempt to explain why AU faults are AUs
analyze_faults -display Analyze a fault through the GSV
ng
remove_faults -retain 5 Remove 95% of the faults from the fault list
report_faults -all -level {3 256} Report fault statistics hierarchically
ni
report_faults –class AU -lev {3 256} Report only AU faults hierarchically
run_atpg basic_scan_only Run only the Basic-Scan ATPG engine
ai
run_atpg fast_sequential_only Run only the Fast-Sequential ATPG engine
Tr
run_atpg full_sequential_only Run only the Full-Sequential ATPG engine
set_atpg -abort 100 Increase Basic and Fast-Sequential ATPG effort
ip
set_atpg -capture_cycles 4 Enable Fast-Sequential ATPG with a depth of 4
ch
set_atpg -coverage 98 Stop ATPG if test coverage reaches 98%
set_atpg -full_seq_atpg Enable the Full-Sequential Engine
ro
set_atpg -full_seq_abort_limit 100 Give Full-Sequential ATPG more time for NDs
ic
set_atpg -patterns 1000 Limit the total number of ATPG patterns to 1,000
4- 52
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Appendix
ng
Test Point Analysis
ni
ai
Tr
ip
ch
ro
ic
4- 53
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Test Point Analysis
 TetraMAX can analyze the design and suggest possible locations for
Test Points
 The analysis can be focused on adding Test Points to improve
ng
Testability, reduce pattern count, or target specific fault classes
ni
 The TetraMAX command that performs the Test Point analysis is
ai
analyze_test_points
Tr
analyze_test_points -target <testability | pattern_reduction | fault_class>
-test_points_file <file_name>
ip
[-max_control_points <n>] [-max_observe_points <n>]
[-num_observe_points_per_scan_cell <n>]
ch
[-class <list_of_fault_classes)]
ro
[-exclude <list_of_instance_names>] [-replace]
ic
4- 54
lM
na
Note: the analyze_test_points command requires a DFTMAX license
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Options: analyze_test_points (1/3)
 -target <testability | pattern_reduction | fault_class>

 testability
 Improves Test Coverage with control and observe points
ng
 Uses random patterns for iterative static analysis
ni
 Does not require prior ATPG
ai
 pattern_reduction
Targets reduced pattern size with observe points
Tr

 Uses SCOAP numbers for static analysis
ip
 Does not require prior ATPG
ch
 fault_class
 Improves Test Coverage with observe points for fault classes
ro
 Uses fault cone topology for dynamic analysis
ic
 Requires initial ATPG for analysis of fault cones
4- 55
lM
na
SCOAP: Sandia Controllability and Observabilty Analysis Program
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
 -test_points_file <file_name>
 Specifies the name of the output file containing the list of test points
-max_control_points <number>
ng

 Specifies the maximum number of control points selected in the design (default is
ni
1000)
ai
 -max_observe_points <number>
Tr
 Specifies the maximum number of observe points selected in the design (default
is 1000)
ip
 -num_observe_points_per_scan_cell <number>
ch
 Number of observe points XOR’ed to a scan cell or PO (default is 8)
ro
ic
4- 56
lM
na
Note: -max_control_points only support with –target testability
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
 -class:
 Default is to analyze all undetected faults
 User can choose to target specific fault sub-classes
ng
 Detected (DS, DI, TP, DR)
 Possibly detected (AP, NP)
ni
 Undetectable (UU, UO, UT, UB, UR)
ai
 ATPG untestable (AN, AX)
 Not detected (NC, NO)
Tr
 Can specify multiple sub-classes, i.e. –class {NO AN}
ip
 -exclude <list_of_instances>
ch
 Instances to avoid placing a test point
 TCL syntax: –exclude {inst_xx inst_yy}
ro
 -replace
ic
 Replaces an existing output file
4- 57
lM
na
Major fault classes not supported for –class:
DT, PT, UD, AU, ND
er
nt
Note: -class only supported when –target fault_class is used

rI
Note: -exclude only supported when –target fault_class is used

Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Test Point Analysis Flow
 Run analysis after ATPG, otherwise there will be a huge number of

ND faults resulting in very long run-times
 Rerun ATPG with the test point file to get an estimate of the
ng
resulting coverage
run_build_model
ni
run_drc
add_faults –all
ai
run_atpg –auto
Tr
analyze_test_points <options>
run_atpg –auto –observe_file <test_point_file>
ip
 Fine tune the test point list as needed by running analysis before
going to DFT Compiler for insertion
ch
 The test point file is sourced in DFT Compiler prior to insert_dft
ro
ic
4- 58
lM
na
Actual TMAX test point file:
set_test_point { CHIP_CORE_1/DM_1/dm_inface_1/U706/Z } -type observe
er

nt

rI
User modified for DFT Compiler:

Fo
set_test_point_element { CHIP_CORE_1/DM_1/dm_inface_1/U706/Z } -type observe -clock TEST_CLOCK

se
If –clock option not used, a new clock pin name tpclk would be inserted
U
Limitations:
ed
• Only observe test points are currently supported

• run_testpoint_analysis will run on LSSD designs but DFT Compiler doesn’t support
ct
automated test point insertion on LSSD designs

tri
es
R

TetraMAX Workshop
Agenda
DAY
2
ng
ni
ai
Tr
ip
ch
ro
ic
5- 1
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Minimizing ATPG Patterns ©2018 Synopsys, Inc. All Rights Reserved. 5-1
TetraMAX Workshop
Unit Objectives
ng
 List 3 methods for reducing test program size
ni
 Describe example design topologies which create parallel or
ai
disturbed dynamic clock grouping
Tr
 Run ATPG on DFTMAX compressed designs
ip
ch
ro
ic
5- 2
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Benefits of Compact Vector Sets
Cost (¢) Manufacture

0.01
0.0001
ng
Test
ni
0.00001
1991 1994 1997 2000 2003 2006 2009 2012
ai
Year
cost = $ $ $ $
Tr
10001010111000101
cost = $
ip
10001010111000101

00001000101011101
ch
11111000101011101 11111000101011101
10001010101011101
11001100101011101
vs. 10001010101011101
11001100101011101
10111000101011101 10111000101011101
ro
01110100101011101 01110100101011101
11001100101011101 11001100101011101
11001100101011101 ...
ic
11001100101011101
...
5- 3
lM
na
Most ASIC Vendors charge for “extra” tester time and/or vector set sizes.
The larger the vector sets, the longer the tester time, and the more expensive the ASIC Production
er
tests will be.

nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
What is Dynamic Pattern Compression?
Conceptual View of ATPG with Dynamic Pattern Compression
ng
Original Merged
ni
1 1 0 0 - - 1 1 0 0 1 0 1
ai
2 0 - 1 1 - - 0 - 1 1 - -
3 - 0 0 - 0 1
Tr
4 1 - 0 1 0 -
ip
5 1 - 0 - 1 - 1 1 0 - 1 0
6 - 1 0 - 1 0
ch
0/1: Care Bits
ro
“-”: Don’t Care
ic
5- 4
lM
na
Note that the example above is only a partial description of how TetraMAX merges patterns.
er
Pattern merging - also known as dynamic pattern compression - is being performed during ATPG.
nt
Pattern merging takes advantage of don’t-care values. Dynamic pattern merging is controlled with
rI
the setting of the set_atpg -merge command option prior to generating patterns.
Fo
Be aware that ATPG runtime may increase when the merging defaults are increased during
run_atpg -auto. Using a high merge effort is only recommended for generating final test
se
patterns, and only if it is really necessary.

U
When merge is on, for each new fault detected an attempt is made to modify an existing pattern to
ed
also detect this fault and still detect previous faults. If successful, no new pattern is needed. If not
successful another fault is tried until the merge effort limit is reached. Once the limit is reached a
ct
new pattern is added for the fault detection that could not be merged with existing patterns.
tri
es
R
TetraMAX Workshop
Controlling Dynamic Pattern Compression
 A default -merge setting of {high high} is used by Basic-Scan and Fast-

Sequential ATPG during run_atpg –auto
 There is individual control for each of the ATPG engines:
ng
 Basic-Scan & Fast-Sequential
ni
set_atpg -merge <low|medium|high|<d>> [<low|medium|high|<d>>]
ai
 Full-Sequential
set_atpg –full_seq_merge <low|medium|high|<d>>
Tr
 Use set_atpg -verbose reporting to get details of how effective merge
ip
settings are on your design
ch
 If the #failed_merges continually hits the limit, try raising limits (gradually); the
tradeoff is increased run time
ro
ic
5- 5
lM
na
The arguments indicate how much effort to spend doing merging. The default is off (0), which
means no merging is performed. Unless a value for this option is specified or the run_atpg -
er
auto command is being used, no merging will occur and there is no verbose output to report.
nt
rI
The first value sets normal ATPG secondary test generation merge effort The second value sets the
merge effort for multiple fault sensitization, which occurs when –auto is used. The labels low,
Fo
medium, and high are accepted for both, as well as an integer value. The first group of labels have
corresponding numeric values of low=20, medium=100, and high=500. The second group of labels
se
have corresponding numeric values of low=200, medium=1000, and high=5000.

U
Integer values <d> can also be specified for the merge effort:
ed
set_atpg -merge {1250 2000}

ct
tri
es
R
TetraMAX Workshop
Minimum Detects ATPG Option
 To avoid creating patterns that fail to detect a minimum number of

collapsed faults
 Only works when –merge option is also enabled
ng
 Separate option for each ATPG engine:
ni
set_atpg -basic_min_detects_per_pattern <d1> [d2]
set_atpg -fast_min_detects_per_pattern <d1> [d2]
ai
set_atpg -full_min_detects_per_pattern <d1> [d2]
Tr
Where:
<d1> = Minimum num of faults detected/pattern
ip
[d2] = Number of consecutive rejected patterns (optional)
ch
Examples:
set_atpg –basic_min_detects_per_pattern [list 5 10]
ro
set_atpg –fast_min_detects_per_pattern {10 20}
ic
5- 6
lM
na
This option may be set at any time prior to running ATPG; the default is 0 (not used). The second d
parameter specifies to terminate Basic-Scan ATPG when the number of consecutive rejected
er
patterns due to failure to achieve minimum detections reaches the value specified. The default value
nt
for this parameter is 40.

rI
-basic_min_detects: Basic-Scan ATPG

Fo
-fast_min_detects: Fast-Sequential ATPG

-full_min_detects: Full-Sequential ATPG
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Avoiding Patterns that Detect Too Few Faults

-----------------------------------------------
-----------------------------------------------
ng
#fast_sequential patterns 248
ni
-----------------------------------------------
reset_state
ai
set_atpg –basic_min_det 10 –fast_min_det 10
run_atpg - auto
Tr
test coverage 98.21% -1.04% drop in
ip
----------------------------------------------- test coverage
ch
-----------------------------------------------
In about 1/3rd the
ro
#basic_scan patterns 101 number of Basic
#fast_sequential patterns 62 and Fast Seq
ic
patterns! 5- 7
lM
na
For more information on the commands that control minimum detects per patterns reference:
er
SolvNet Article: 000939 – Using TetraMAX’s Minimum Detects per Pattern Options To
nt
Reduce Vector Count

rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Using run_atpg -optimize_patterns
 Produces a very compact set of patterns with high test coverage with a
single run_atpg command
 TetraMAX dynamically adjusts the internal algorithms to generate a
ng
compact pattern set
ni
 All manually specified set_atpg settings, such as abort limits,
ai
minimum detects, and merge limits are ignored during this operation
Tr
 The -optimize_patterns option is useful for a final TetraMAX ATPG
run where the goal is to optimize the pattern count at the expense of
ip
added run-time
ch
 Only supports Basic-Scan and Two-Clock optimized ATPG engines
ro
ic
5- 8
lM
na
Note the following limitations when using the -optimize_patterns option:
• Multiple run_atpg commands are supported, but pattern optimization can only be specified
er
once.
nt
• A learned recipe is not saved.

rI
• Fast-Sequential and Full-Sequential ATPG modes are not supported.

• Be aware that unlike the run_atpg -auto_compression command, specifying set_atpg -
Fo
capture_cycle number will not enable Fast-Sequential ATPG during the pattern optimization
process. To run Fast-Sequential top-off ATPG, it must be done as an extra step. For example:
se
run_atpg –optimize_patterns
set_atpg –capture 4
U
run_atpg -auto fast_sequential

ed
• Only Stuck-At and Transition fault models are supported.

ct
tri
es
R
TetraMAX Workshop
Dynamic Clock Grouping
 The clocks pulsed for a given vector are selected dynamically during
pattern generation:
 Maximizing the fault detection
ng
 Minimizing the pattern count
ni
 Dynamic clocking schemes:
ai
 Parallel
Tr
 Disturbed
 Clock grouping allows multiple clock domains to be pulsed in
ip
simultaneously during the capture window
ch
 Dynamic clock grouping is enabled by default
ro
ic
5- 9
lM
na
It is possible to pulse several clocks in the same vector, thus observing more logic and reducing the
need for additional patterns. Given two clocks independent from one another (when one clock is
er
pulsed, no logic driven by the other clock is affected), then two patterns would be required to
nt
exercise the logic in the two clock domains. However, since the clocks are independent, they could
be safely pulsed together, thereby saving one test pattern.
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Dynamic Clock Grouping: Parallel
No data paths between the
Clock CLK1 and CLK2 clock domains
Domain
1 skew
CLK1
ng
CLK1
ni
Clock
Domain CLK2
ai
2
CLK2
t t
Tr
B A
 Parallel clock pairs are clocks that can be pulsed in the same tester cycle
without any sequential effects
ip
set_drc -clock –dynamic (Enabled by default)
ch
 More flexible and gives better results than static clock grouping
ro
 TetraMAX decides on a pattern-by-pattern basis whether to pulse a clock
ic
alone or along with other clocks 5- 10
lM
na
With dynamic clock grouping enabled during DRC and clock domains CLK1 and CLK2 identified
as parallel, Basic-Scan ATPG can pulse CLK1 and CLK2 simultaneously during the same capture
er
cycle.
nt
rI
Skew is the difference between the capture clock edges of flip-flops from two different clock
domains. The test protocol timing or add_clocks command defines clock edges.
Fo
Skew does not matter when clock domains share no paths. Skew DOES matter when the clock
se
domains do share paths. TetraMAX uses the setting for skew defined by the following command
set_drc –skew <d> (default is 1)
U
ed
When the design has two state elements, A and B, with the output of A connected to the input of B,
and each element is clocked by a different clock, and those clocks have nearly identical timing, then
ct
the two clocks have a parallel grouping relationship only if the capture edge of clock B occurs at or
tri
before the capture edge of clock A minus the skew value. Otherwise, the clocks are ungrouped, or
have a disturbed grouping.
es
To disable parallel clock grouping:

R
set_drc –clock -any
For static parallel clock grouping

To group some clocks manually, use the add pi equivalences command. Once a static clock group
is defined, any clock belonging to that group cannot be pulsed alone.
TetraMAX Workshop
Dynamic Clock Group: Disturbed
Data paths between the CLK1 and CLK2
clock domains going in both directions
skew
CLK1
ng
CLK2
ni
ai
t t
B A
 Disturbed clocks pairs are clocks that can be pulsed in the same tester
Tr
cycle with a limited amount of sequential effects
ip
set_drc [-disturb_clock_grouping | -nodisturb_clock_grouping]
ch
 Disturbed cells are masked during ATPG. Disturbed clock grouping results
in fewer patterns but can leave some faults undetected due to masks
ro
 To recover coverage loss due to masks, run ATPG again without disturb clock grouping
ic
run_atpg –nodisturb_clock_grouping
5- 11
lM
na
With clock grouping disabled, Basic-Scan ATPG must pulse CLK1 and CLK2 in separate capture
cycles with a load_unload in between the two patterns.
er
nt
With dynamic clock grouping enabled and clock domains CLK1 and CLK2 identified as
rI
disturbed, Basic- Scan ATPG can pulse CLK2 and CLK1 in the same capture cycle masking
cells disturbed by sequential behavior.
Fo
Dynamic and disturbed clock grouping is supported for the Basic-Scan and Fast-Sequential engines
se
only.
U
Pattern generation does not consider masked cells:

ed
•Masks enforced during simulation

•Target fault can become undetected, no vector will be further attempted to detect this fault
ct
•Performing a separate ATPG run without disturb clock grouping may be able to detect
tri
those faults that were left undetected due to masks

es
R
TetraMAX Workshop
Analyze Clock Grouping and Disturbances
TEST-T> report_clocks –matrix
id# clock_name type 0 1 2 3
--- ---------------- ---- --- --- --- ---
0 pclk CW --- -D- -D- ---
1 sys_clk CW -D- --- -D- ---
ng
2 sdr_clk CW -P- -P- --- -D-
3 prst_n SR --- --- -D- ---
ni
------------------------------------------------
clock 1 clock 2
ai
id# #masks #cells id# #masks #cells masked gates
Tr
--- ------ ------ --- ------ ------ --------------
0 25 1074 1 25 722 29284 ...
0 5 1074 2 7 1132 29392 ...
ip
1 38 722 2 47 1132 31063 ...
ch
2 99 1132 3 78 1301 31062 ...
Clock ID 1 (sys_clk) has 722 flops of which 38 are disturbed when
ro

grouped with Clock ID 2 (sdr_clk)
ic
 sdr_clk has 1132 flops of which sys_clk disturbs 47 5- 12
lM
na
Note that report_clocks –matrix is supported only in TEST mode.
er
-matrix
nt
Displays the dynamic clock pair group ability in table form where each row indicates the potential
rI
grouping relationship of a candidate clock with each of the other candidate clocks.
Fo
The type indicates the current clock type. The clock type may be any combination of C (flip-flops),
W (RAM write control), S (set), or R (reset).
se
If two clock have a parallel relationship, then there will be a “P” in the second character of the
U
matrix, i.e., “-P-”.

ed
If there is a disturb relation between two clocks, then “-D-” is seen in the matrix. These are disturb
ct
clock pairs.
tri
Dashes “---” in the matrix means that the pair of clocks did not meet the criteria for a disturb
es
relationship.
R
TetraMAX Workshop
Clock Grouping for Each Pattern
TEST-T> report_patterns –all –type

Patn Pattern Cycle Load Observe Clocks
num type count count proc used
ng
----- ------------ ----- ----- ------- ------
0 basic_scan 1/0 1 - -
ni
. . .
ai
33 basic_scan 1/1 1 - pclk,sdr_clk
Tr
34 basic_scan 1/1 1 - pclk,sys_clk,sdr_clk
35 basic_scan 1/1 1 - sys_clk,sdr_clk
ip
36 basic_scan 1/1 1 - sys_clk
ch
38 basic_scan 1/1 1 - sys_clk,sdr_clk
ro
ic
. . .
5- 13
lM
na
Patn num:
Indicates the pattern number. Pattern numbers start with zero.
er
Pattern type:
nt
Indicates the type of pattern. Basic-Scan is a combinational pattern using one scan
rI
load, one capture clock (optional), and one scan unload. Fast-Sequential can use up to 10 scan loads
and 10 captures. Basic_scan(COM) indicates a "Clock On Measure" is being performed. A clock is
Fo
being held on and the primary outputs are being measured during the clocks on time. A type of
sequential is also possible when the pattern source is external functional patterns.
se
Cycle count:
The cycle count reports two numbers: N1/N2. The N1 is the number of capture
U
procedures, or in other words the number of force/measure pairs. This corresponds to the number of
ed
tester cycles that will be used by the pattern. The N2 is the number of these capture procedures that
contain a clock pulse. Since not every force/measure pair needs to be accompanied by a clock
ct
pulse, N2 will always be less than or equal to N1.

tri
Load count:
Indicates the number of scan loads used by the pattern.
es
Observe proc:
If a master observe or shadow observe procedure is used, the type is indicated here.
R
Clocks used:
Indicates the active clock used by the pattern. If more than one clock is listed the
order matches the order used by the pattern.
TetraMAX Workshop
Adding Fault Models Increases Test Cost
Tester Memory Limit

Above 130nm SA
Stuck-At (SA)
~4-6X Test Time & Test Data
ng
130nm & Below Transition Delay Test Bridging
(High Cost) SA BridgingTest
Test
Slack-Based Delay Test
ni
ai
130nm & Below
With Compression
Tr
(Low Cost)
Tester Cycles
ip
ch
Test budget fixed, yet
must not compromise on product quality
ro
Test Pattern Compression Needed!
ic
5- 14
lM
na
With legacy process nodes, designers generally use Stuck-At tests and some Transition Delay
testing up to the memory limits of their tester.
er
nt
At smaller process nodes, Transition delay, Slack-Based Transition Delay, and Bridging tests
rI
become critical. The Transition Delay tests can replace some of our stuck-at tests, but tester
memory is usually far exceeded.
Fo
By adding compression, we can maintain the quality of our tests and avoid any cost of upgrading
se
our tester configuration

U
ed
ct
tri
es
R
TetraMAX Workshop
How Compression Works
 Traditional scan chains are split into shorter chains

 Shorter chains require less time to load and less data to be loaded on
tester
ng
Traditional Scan Scan Compression
ni
ai
Tr
…
ip
ch
One Scan chain for each Multiple Scan chains share
ro
scan-in/scan-out pin same scan-in/scan-out pins
ic
5- 15
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Test Compression Concepts
 Test Application Time Reduction (TATR)

 Used to reduce tester execution cost
Regular Scan Patterns x Regular Chain Length
ng
TATR =
Compressed Patterns x Compressed Chain Length
ni
ai
 Test Data Volume Reduction (TDVR)
Tr
 Used to ensure test program resides within tester memory
ip
 Avoids time-consuming reloads
ch
 Used if adding more patterns to increase test quality
Regular Scan Patterns x Regular Pin Data
ro
TDVR =
ic
Compressed Patterns x Compressed Pin Data
5- 16
lM
na
DFTMAX TATR:
er

nt
TATR =
rI
DFTMAX Patterns x DFTMAX Chain Length

Fo
DFTMAX Ultra TATR:

se

U
TATR =
ed
Ultra Patterns x (Lengthinternal + Lengthcontrol + 1)

ct
tri
es
R
TetraMAX Workshop
Test Cycle Savings
1000 100 40 internal chains

flops flops
ng
ni
4 chains 4 chains
ai
Test Application Time = Patterns x ScanLength
Tr
Example: Example:
ip
 2,000 patterns  2,400 patterns
ch
 1,000 cycles to load a pattern  100 cycles to load a pattern
ro
= > 2000 * 1000 = 2,000,000 cycles = > 2400 * 100 = 240,000 cycles
ic
TATR = 2000000 / 240000 = 8.33 X
5- 17
lM
na
How does this compression work?
er
We know from scan that Test Application Time is equal to the number of patterns times the length
nt
of the longest scan chain. With DFTMAX, we are shrinking the length of that longest chain.
rI
For scan, Test Data Volume is proportional to the longest chain times the number of pins we use to
Fo
push the data through. Of course we then multiply by the number of patterns, but lets say that for
Adaptive Scan, the pattern count is the same. Again, since the scan chain length is shorter in
se
Adaptive Scan, but the pin count is identical, we get a lower Test Data Volume.
U
ed
ct
tri
es
R
TetraMAX Workshop
Test Modes Created During Insertion
 Internal Scan Mode

 Re-configures the chip to look like traditional scan
dc_shell> write_test_protocol –out internalscan.spf \
ng
-test_mode Internal_scan
 Short compression chains are reconfigured into longer scan
ni
chains
ai
 Also called:
Tr
 Reconfigured/regular/uncompressed scan mode
 Scan Compression Mode
ip
 Uses the shorter chains directly
ch
dc_shell> write_test_protocol –out scancompression.spf \
-test_mode ScanCompression_mode
ro
 Also called:
ic
 Compressed/DFTMAX/Ultra mode 5- 18
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Passing Compression Information to TetraMAX
 All the information TetraMAX needs to know about the compression

architecture is in the compression mode protocol file (SPF)
 The protocol is generated by DFT Compiler during DFT insertion, and
ng
can be written out as follows:
ni
write_test_protocol -out scancompress.spf \
ai
-test_mode ScanCompression_mode
Tr
 The ATPG flow in TetraMAX for DFTMAX is the same as for regular scan
 Both DFTMAX and regular scan designs use the same fault diagnosis
ip
flow in TetraMAX
ch
ro
ic
5- 19
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
ATPG – Scan Compression Flow
 Simply read in the DFTMAX scan netlist and run_drc with the
ScanCompression_mode STIL protocol file:
ng
read_netlist libs/tmax_libs/*.v
ni
read_netlist design_w_compression.v
ai
run_build top
Tr
run_drc scancompress.spf
add_faults –all
ip
run_atpg –auto
ch
write_patterns pat_compression.stil -format stil
ro
ic
5- 20
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Explore Compression in TetraMAX
 Use analyze_compressors to do ‘what-if’ analysis of different

compression architectures
analyze_compressors
ng
-num_chains <d>
-num_inputs <d>
ni
-num_scanouts <d>
ai
[-xtolerance <default | high>
[-nodiag]
Tr
[-verbose]
Run on any standard scan design after passing DRC
ip

ch
 Runs only Scan Compression mode ATPG
 Reports coverage, pattern count, and an estimate of compression and
ro
compressor area
ic
5- 21
lM
na
SolvNet Article: 017408 – Performing 'What If' Analysis for Inserting Adaptive Scan
Compression Logic
er
nt
-nodiag
rI
Specify this option to disable the requirement to generate a compressor with high precision
diagnosis. By default, the analyze compressors command generates a compressor with failure
Fo
diagnosis; this requires a specific number of scan outputs for a given number of chains.
se
Note: analyze_compressors does not support DFTMAX Ultra compression

U
ed
ct
tri
es
R
TetraMAX Workshop
Using analyze_compressors Example
Example:
run_build_model
run_drc SCAN.spf
ng
analyze_compressors –num_chains 96 \
-num_inputs 8 –num_scanouts 8
ni
ai
Check pattern count and coverage
Tr

 Compare with scan mode pattern count and coverage
ip
ch
ro
ic
5- 22
lM
na
-----------------------------------------------
er
------------------------------ ---- ---------

Detected DT 73803
nt
Undetectable UD 3218
rI

Not detected ND 491
-----------------------------------------------
Fo
total faults 78482

-----------------------------------------------
se
-----------------------------------------------
U
-----------------------------------------------
CPU Usage Summary Report
-----------------------------------------------
ed
Total CPU time 2.91

-----------------------------------------------
Warning: Internal pattern set is now deleted. (M133)
ct
Data reduction per pattern: 11.43X

tri
Cycle reduction per pattern: 18.34X

Compressors area overhead per internal chain: 9.2 equivalent two-input NAND
es
gates
R
TetraMAX Workshop
DFTMAX Ultra and ATPG
 TetraMAX supports both the regular DFTMAX

compression architecture as well as DFTMAX
Ultra
ng
DECOMPRESSOR
 DFTMAX Ultra is the latest scan compression
ni
architecture from Synopsys
ai
 The ATPG flow for regular DFTMAX and
Tr
DFTMAX Ultra is the same
 There are some ATPG features that are unique
ip
to DFTMAX Ultra COMPRESSOR
ch
ro
ic
5- 23
lM
na
Some current limitations of DFTMAX Ultra in TetraMAX:
er
- Full-Sequential ATPG is not supported (Path Delay must use Fast-Sequential)

nt
- The analyze_compressors command is not supported

rI
- The run_justification command is not supported

Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Updating DFTMAX Ultra Patterns
 Use the command update_streaming_patterns to manipulate

DFTMAX Ultra ATPG patterns
 Controlling the peak and average power during shifting
ng
 Use -load_scan_in option
ni
 Increase the maximum shift length of patterns to allow top-level pattern set
merging
ai
 Use -max_shift option
Tr
 Optimizing padding patterns
ip
 Use -remove_padding_patterns option
Add virtual pipeline stages to account for pipelines to be added at a higher level
ch

 Use -virtual_head_pipelines and -virtual_tail_pipelines options
ro
 Removing and reordering patterns
ic
 Use -remove and -insert options
5- 24
lM
na
Note: virtual pipelines can also be accounted for when the patterns are originally generated by
ATPG by using the following command options:
er
nt
set_drc -virtual_head_pipelines <n>

rI
set_drc -virtual_tail_pipelines <n>

Fo
VCS simulations of scan patterns will pass only if the correct number of pipelines are in the netlist.
se
U
ed
ct
tri
es
R
TetraMAX Workshop
DFTMAX Ultra Padding Patterns
 DFTMAX Ultra inserts padding patterns as follows:

 Basic-Scan/2-Clock ATPG: after every 32 patterns
 Fast-Sequential ATPG: after every pattern
ng
 Padding patterns are automatically removed during write_patterns
ni
 Manual removal of padding patterns with update_streaming_patterns
ai
P0P1 P2.........P 32P33P34 P35......... P 65P 66……Plast
Tr
ip
update_streaming_patterns –remove_padding_patterns
ch
P0P1 P2.........P 32P33P34 P35......... P 65P 66…… Plast
ro
ic
5- 25
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop

 List 3 methods for reducing test program size
ng
 Describe example design topologies which create
parallel or disturbed dynamic clock grouping
ni
 Run ATPG on DFTMAX compressed designs
ai
Tr
ip
ch
Begin Lab 5: Minimizing ATPG Patterns
ro
ic
5- 26
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
report_clocks -matrix Examine clock grouping opportunities

reset_state Removes generates patterns and resets fault list
set_atpg -basic_min_detects 50 Constrain minimum faults detected per Basic pattern
ng
set_atpg -fast_min_detects 10 Constrain minimum faults detected per Fast pattern
set_atpg -full_min_detects 5
ni
Constrain minimum faults detected per Full pattern
set_atpg -full_seq_merge value Enable Full-Sequential ATPG pattern compression
ai
set_atpg -merge [list high med] Enable Basic-Scan ATPG pattern compression
Tr
set_atpg -merge [list high low] Enable Fast-Sequential ATPG pattern compression
set_drc -disturb_clock_grouping Allow disturbed clock grouping with Basic patterns
ip
set_drc -clock -dynamic Enable DRC to analyze clock grouping
ch
analyze_compressors Perform “what if” analysis on compression setups
ro
ic
5- 27
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
ng
ni
ai
Tr
ip
ch
ro
ic
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Agenda
DAY
2
ng
ni
ai
Tr
ip
ch
ro
ic
6- 1
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Pattern Validation ©2018 Synopsys, Inc. All Rights Reserved. 6-1

TetraMAX Workshop
Unit Objectives

Explain the benefits of saving patterns in binary format
ng

 Describe the minimal set of ATPG patterns that should be
ni
simulated with serial load_unload
ai
 Use two ways to translate a STIL pattern to a Verilog
Tr
testbench with MAX Testbench
ip
 Describe 2 reasons why you might use the ATPG masking
ch
commands
ro
ic
6- 2
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
BUILD
Mode
TEST
ng
Mode
Gate-level Read Run
Test Patterns
ni
ai
Tr
Build Review
ip
Patterns
ch
DRC
Mode Incremental
ro
STIL Test Check
ATPG
Protocol DFT Rules
(If needed)
ic
6- 3
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
ATPG Pattern Validation: Agenda
Writing Patterns
ng
Pattern Validation
ni
ai
Tr
Simulation Debug
ip
ch
Dealing With ATE Failures
ro
ic
6- 4
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
ASIC Vendor: Specific Considerations
 ASIC Vendor restrictions on patterns may require some non-default

settings during pattern generation or pattern writing to meet ASIC
Vendor requirements
ng
ni
 Check with your vendor:
ai
 Documentation
Tr
 Help desk
ip
 Check with Synopsys
ch
 Documentation
ro
 SolvNet
ic
6- 5
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Options for Writing Patterns
 There are many options for saving
patterns:
 Pattern Source - normally this is the internal
pattern buffer but if external patterns have been
read, they can be written from the external buffer
ng
 Pattern Range - provides the ability to specify the
starting or stopping range to write (pattern
ni
numbering starts at zero)
ai
Tr
ip
write_patterns <file> [-replace] [-first <d>] [-last <d>] [-split [n]]
ch
[-internal | -external] [-serial | -parallel [d]] [-compress <gzip|binary>]
ro
[-nocompaction] [–use_delay_capture_start <d>] [-use_delay_capture_end <d>]
[-format <binary | stil | wgl | wgl_flat ...>] [-unified_stil_flow]
ic
[-exclude <setup|repeat_setup|patterns|chain_test|atpg_patterns|all>] ...
6- 6
lM
na
Available Formats:
STIL, WGL, WGL_Flat, STIL/99, TDL91, FTDL, TSTL2, Binary
er
nt
Split options creates multiple pattern files of “d” patterns each.

rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Unified STIL Flow vs. Dual STIL Flow
 Unified STIL Flow (USF) uses single STIL pattern for all targets
 Failing cell identification with parallel compressed simulations requires PSD
 Dual STIL Flow uses separate STIL patterns for serial/parallel
ng
 Can be used to get failing cell information of parallel compressed simulation but only
ni
if N-shifts is not required – only serial STIL pattern is appropriate for the ATE
Dual STIL Flow
ai
Unified STIL Flow (Default)
Different STIL Generate 1 STIL
TMAX TMAX
Tr
One STIL file, constructs for Scan (serial) or 2,
supports all design types, Compression depending on
simulation modes, and the ATE
Serial STIL limited
ip
STIL Parallel STIL
limited to Par STIL Ser STIL to serial sim for
Scan Compression
ch
parallel sim for
MAXTB Scan MAXTB MAXTB
Compression Be sure to send
ro
TB Ser TB the right STIL to
Par TB
Parallel N-shift not the ATE
ic
VCS ATE supported for Scan
VCS ATE
Compression 6- 7
lM
na
To support failing cell identification with USF and parallel simulation of compressed patterns
requires a Parallel Strobe Data (PSD) file. We cover creating/using a PSD file later in this Unit.
er
nt
Note: Dual STIL Flow serial and parallel patterns are identical for un-compressed (regular scan)
rI
designs
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
General Guidelines for Saving Patterns
 Save patterns in binary format so they can be translated later

to different formats:
run_atpg . . .
ng
write_patterns –format binary . . .
ni
write_image run_img.gz . . .
ai
 Save patterns in appropriate format for simulation and for
Tr
translation to ATE (USF by default):
write_patterns pats.stil –format stil -replace
ip
write_patterns pats.wgl –format wgl –replace
ch
ro
ic
6- 8
lM
na
Dual STIL patterns are written by specifying –nounified_stil_flow and –serial or –
parallel. For example:
er
nt
# Write Dual STIL parallel patterns

rI
write_patterns pats_par.stil –format stil –nounified_stil_flow –parallel

Fo
# Write Dual STIL serial patterns

write_patterns pats_ser.stil –format stil –nounified_stil_flow –serial
se
Note: If the pattern file name already exists, the –replace option will overwrite the existing file
U
with the new pattern.

ed
ct
tri
es
R

TetraMAX Workshop
Scan Chain Test
 Do all your patterns fail on the ATE or mismatch in your simulator?

 If not all, do you have so many
failures on the ATE or so many
ng
mismatches in the simulator that
ni
you do not know where to begin?
ai
 Was Static Timing Analysis performed on your scan design in scan shift
Tr
mode?
 Were best-case back-annotated delays or parasitics used to check for
ip
hold time problems?
ch
 Were worst-case delays used to check the shift speed?
ro
 Need to validate that scan shifting works!
ic
6- 9
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Set Chain Test Bit Sequence before ATPG
set_atpg -chain_test <off|0011|0101|1000|0111|<string>>

off = do not generate
0011 = repeating pattern of 0011... DEFAULT
ng
0101 = repeating pattern of 01..
1000 = leading bit 1, rest 0, i.e. 1000000...000
ni
0111 = leading bit 0, rest 1's, i.e. 01111.…111
ai
string = user defined sequence of 1's and 0's with a
Tr
final character of "C" to repeat last digit as
a constant or "R" to repeat the sequence, For example:
ip
– 011001R -> 011001 011001 011001...
ch
– 011001C -> 011001 111111 111111...
ro
run_atpg –auto ...
ic
write_patterns chain_test.stil –format stil –last 0
6- 10
lM
na
TetraMAX generates a user-controllable chain test as Pattern 0 during ATPG for regular scan
designs.
er
nt
The default chain test pattern, 0011, results in a 50% toggle rate during scan shift.
rI
TetraMAX automatically generates additional chain test patterns for DFTMAX X-tolerant designs
Fo
with R10 violations

se
To enable/disable
set_atpg [–augmented_chain_test|-noaugmented_chain_test]
U
ed
For compressed designs with multiple chain tests, run_atpg –chain_test_only can be
used:
ct
run_atpg –chain_test_only
tri
write_patterns chain_tests.stil –format stil -replace

es
R

TetraMAX Workshop
DFTMAX Ultra Chain Test Patterns
 DFTMAX Ultra chain test patterns generated by default

 To disable: set_atpg –streaming_xtol_chain_test off
Tests all internal chains plus codecs
ng

 Patterns test all faults marked DI in fault list
ni
 Required to distinguish failures in DFT logic from regular failures
ai
 Pattern count roughly equal to compression ratio
Tr
 1 pattern per internal chain if 1 scan-out port is used
Divide this by N if N scan-out ports are used
ip

All codecs tested simultaneously
ch

 Total pattern count determined by codec requiring most patterns
ro
ic
6- 11
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Splitting Up Large Pattern Sets
 Large pattern sets can be “split” into multiple STIL patterns

write_patterns pat.stil –format stil –split <n> [-exclude repeat_setup]
 Patterns will be split into groups of n patterns
ng
 Patterns will be named pat_0.stil, pat_1.stil, etc.
ni
 Each pattern file will contain a test_setup section unless excluded
ai
 If –exclude repeat_setup is used, the first split pattern (pat_0.stil) will
Tr
contain a test_setup but all other split patterns will not
 Only the first split pattern file contains the chain test patterns
ip
ch
ro
ic
6- 12
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Generate Reports Now for Later Debugging
Simulation miscompares on pattern N…

 Which ATPG engine generated pattern N?
report_patterns –all –type
ng
ni
Scan unload miscompare on chain c4 position 10…
ai
 What is the corresponding design flip-flop?
Tr
report_scan_cells –all
ip
ch
 Obtain a list of any shadow cells:
report_scan_cells -shadow
ro
ic
6- 13
lM
na
Shadow cells can effect the results of parallel Verilog simulation of scan patterns. The shadow cells
need to be accounted for by either adding serial shifts after parallel load (N-shift) or by disabling
er
the use of shadows by ATPG (set_drc –noshadows).

nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Writing Patterns
ng
Pattern Validation
ni
ai
Tr
Simulation Debug
ip
ch
ro
ic
6- 14
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
The Challenge of Verifying Scan Designs
Scan paths not in RTL; cannot use Formal Verification on scan paths
Pre Scan
design
ng
Formality DFT Compiler
DFTMAX
ni
ai
Optimized STIL
scan design Procedures
Tr
PrimeTime DSMTest
DSMTest TetraMAX IDDQ
ip
Verify scan path timing
ch
DSMTest Stuck-At IDDQ Test
Vectors Test Vectors Vectors
ro
MAX Testbench IDDQ-PLI
ic
Verify scan pattern functionality VCS 6- 15
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Verilog Pattern Validation
 It is critical to simulate the ATPG

patterns to validate their
STIL Test Data
correctness
ng
 The method for simulating ATPG
ni
patterns from TetraMAX is called
MAX Testbench
ai
Tr
 MAX Testbench uses STIL as the
source for creation of the Verilog
ip
testbench Design Under Test
ch
 The Test Pattern Validation User’s
Guide contains details on APTG
ro
pattern validation and using MAX
ic
Testbench 6- 16
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
What is MAX Testbench?
101011101 TetraMAX
111010000 STIL
011011011 Patterns
Stimulus/response
TetraMAX
Testbench
MAX Testbench
ng
write_testbench Module test; DUT
or stil2verilog
ni
Instance of DUT Model
ai
Stimulus/response
Data File Verilog
Tr
Netlist/library
ip
 MAX Testbench converts STIL patterns into a Verilog simulation
ch
testbench using write_testbench or stil2verilog
ro
 The Verilog testbench applies test stimulus to the DUT and checks
the responses against the expected data specified in the data file
ic
6- 17
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Using MAX Testbench
 Translate a STIL pattern to a Verilog testbench from within TetraMAX

write_testbench -input <stil_filename>
-output <testbench_name>
ng
[-replace]
[-config_file config_filename]
ni
[-parameters {list_of_parameters}]
ai
 Or use stil2verilog utility from UNIX
Tr
UNIX% stil2verilog <stil_filename> <testbench_name>
[-config_file <file>] [options]
ip
Two output files are generated
ch

 Verilog testbench file: <testbench_name>.v
ro
 Data file: <testbench_name>.dat
ic
6- 18
lM
na
-config_file config_filename
Specifies the name of a configuration file that contains a list of customized options to the MAX
er
Testbench command line

nt
rI
-parameters {list_of_parameters}
Enables you to specify additional stil2verilog options to the MAX Testbench command line
Fo
stil2verilog <pattern_file> <tbench_file> [options]

se
-config_file <TB_config_file>
-first <d> -last <d>
U
-generate_config <config_file_template>
ed
-help [<msg_code>]
-log <log_file>
ct
-parallel [nshift] -serial -ser_only

-replace –report -run_mode go-nogo | diagnosis
tri
-sdf_file <sdf_file_name> -shell

es
-sim_script vcs | mti | nc | xl

-split_in {1.stil, 2.stil…} <testbench_name>
R
-split_out <pat_int> <stil_file> <testbench_name>

-tb_format v95 | v01 | sv
-tb_module <module_name>
-verbose -version
-v_file <design_file_names> -v_lib <library_file_names>

TetraMAX Workshop
Configuration File Overview
 The testbench can be configured with:

 Command line options
 Configuration file
ng
 A template of the configuration file can be created by
ni
write_testbench_config or stil2verilog:
ai
TEST-T> write_testbench_config
Tr
UNIX% stil2verilog -generate_config <config_name>
 The configuration file contains two types of configuration information:
ip
 Variables affecting the testbench definition
ch
 Variables affecting the simulator script generation
ro
ic
6- 19
lM
na
The write_testbench_config command is an alias of the following command:
write_testbench -parameters {-generate_config stil2verilog.config} -rep
er
nt
# Example configuration file variables. “#” is a comment

rI
# cfg_patterns_report_interval: Specifies interval of messages

Fo
#set cfg_patterns_report_interval 5
se
# cfg_message_verbosity_level: control for trace options

#set cfg_message_verbosity_level 0
U
ed
# cfg_evcd_file evcd_file: generates an extended-VCD of the run

#set cfg_evcd_file "evcd_file"
ct
tri
# cfg_diag_file: generates a failures log file for diagnostics

#set cfg_diag_file "diag_file“
es
R

TetraMAX Workshop
Parallel vs. Serial Load During Simulation
 Parallel/Serial - specifies how the scan chain load/unload should be

formatted during simulation:
 Serial - scan chain load/unload is not flattened but left intact and patterns
ng
contain test cycles that shift data into the scan chains
Parallel - scan chain load/unload is flattened and scan cells are broadside
ni

loaded
ai
 N-Shifts <d> - parallel load followed by “d” serial shifts
Tr
 A single STIL pattern set can support both parallel and serial load
ip
during scan pattern simulation (default is parallel load)
ch
 The simulation load method can be changed when STIL patterns are
translated with write_testbench / stil2verilog or at simulation
ro
run-time
ic
6- 20
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Flexible Simulation: Serial Vs. Parallel
Note: we are not specifying serial

 Example: in TetraMAX save STIL pattern set or parallel simulation at this point
write_patterns pats.stil –format stil -replace
Default simulation is parallel with a pre-computed number of N-shifts
ng

 Number of N-shifts is based on shadow cells and settings for loadable nonscan
ni
cells
ai
 MAX Testbench can specify serial vs. parallel when translating the STIL
Tr
to a Verilog testbench - Example:
write_testbench –in pats.stil –out pat_xtb –parameters {-serial}
ip
 Can also be changed in the VCS compile script:
ch
+define+tmax_parallel=N Parallel with N serial shifts
ro
+define+tmax_serial=M First M patterns serial, remaining patterns parallel
ic
6- 21
lM
na
Parallel Options:
None or 0: all parallel patterns
er
N: all parallel patterns with last N bits serially loaded

nt
rI
Serial Options:
None or 0: all serial patterns
Fo
M: First M patterns serial, remaining patterns parallel

se
U
ed
ct
tri
es
R

TetraMAX Workshop
Serial Load Simulate Which Patterns?
 Typically, it is not feasible to serial-load simulate all

the patterns
 It’s advisable to at least serial-load simulate the
ng
chain test pattern(s)
ni
 Beyond chain test, it’s at user discretion – one
ai
strategy would be to identify a selection of patterns
Tr
so that each capture clock is serially simulated at
least once
ip
 Use report_patterns –all –type to document
ch
the capture clocks used for each pattern
ro
ic
6- 22
lM
na
Note: simulating each capture clock at least is example method that could be used to determine
which patterns to simulate with serial load. At a minimum, the chain test pattern should be
er
simulated with serial load. Beyond that, it’s up to user discretion regarding which patterns to
nt
simulate with serial load.

rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Selecting Serial Patterns by Capture Clock
TEST-T> report_patterns –all –type > pattern.rpt
Patn Pattern Cycle Load Observe Clocks
num type count count proc used
----- --------------- ----- ----- ------- -----------------------
ng
1 basic_scan 1/1 1 - sdr_clk,sys_clk,pclk
3 basic_scan 1/1 1 - sdr_clk,prst_n
ni
Patterns of
ai
Interest 6 basic_scan 1/1 1 - sdr_clk,sys_clk,pclk
Tr
8 basic_scan 1/1 1 - sys_clk,pclk
9 basic_scan 1/1 1 - prst_n
ip
ch
ro
15 basic_scan 1/1 1 - sdr_clk,sys_clk
ic
6- 23
lM
na
TEST-T> report_clocks
er
clock_name off usage

nt
---------------- --- --------------------------

rI
test_pci_clk 0 master shift

test_sys_clk 0 master shift nonscan_DLAT
Fo
test_sdram_clk 0 PO master shift

test_sys2x_clk 0 master shift nonscan_DFF
se
prst_n 1 PO master reset

U
ed
ct
tri
es
R

TetraMAX Workshop
Write Only Those Selected Patterns
unix% cp pattern.rpt serial_select.rpt

The -reorder option looks only
unix% vi serial_select.rpt at the first column of the file
ng
ni
TEST-T> write_patterns select_pats.stil –format stil \
ai
-reorder serial_select.rpt –serial
Tr
 DFTMAX compressed patterns cannot be reordered but a range of
ip
patterns can be written
ch
TEST-T> write_patterns range_pats.stil –format stil \
ro
-first 0 -last 3 –serial
ic
6- 24
lM
na
Adaptive Scan patterns cannot be “reordered” with the –reorder option. See the following
SolvNet article for a workaround flow:
er
SolvNet Article: 020892 – How to Combine Adaptive Scan Pattern Files

nt
rI
FYI, by default the first pattern is pattern 0, so it’s not required to specify that option in the above
example. The option was included to demonstrate how a range of pattern can be written.
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Handling Split Patterns With MAX Testbench
 To use previously split STIL patterns for MAX Testbench simulation:

write_testbench -input {-split_in \{pat_0.stil pat_1.stil foo_2.stil\}} \
-output pat_xtb -replace
ng
 Separate “partitions” are created when the testbench is created
 Each split pattern set is a partition and will have its own data file (i.e.,
ni
pat_xtb_0.dat)
ai
 By default, all partitions are simulated in order
Tr
 A specific partition can be simulated by specifying simv
+tmax_part=<partition#>
ip
 Alternately, a single large STIL pattern file can be split out into multiple
ch
partitions by MAX Testbench for simulation
ro
write_testbench -input pat.stil –output pat_xtb –replace \
–parameters {-split_out <n>}
ic
 Partition handling is the same as mentioned above 6- 25
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Runtime Programmability
 The goal of runtime programmability is to facilitate reusing a compiled

simulation executable (simv) for multiple validation runs
 Useful for designs that take a long time to compile with VCS
ng
 Two types of runtime programmability
ni
 Basic programmability (changing serial vs. parallel simulation, etc.)
ai
 Pattern programmability (different pattern sets reuse the same simv)
Tr
 Basic programmability involves specifying runtime options with simv
ip
simv +<runtime_option>
ch
 The available runtime options are: tmax_msg, tmax_rpt, tmax_serial,
tmax_parallel, tmax_n_pattern_sim, tmax_test_data_file
ro
ic
6- 26
lM
na
+tmax_msg=N Control for a pre-specified set of trace options
+tmax_rpt=N Specifies the interval of the progress message
er
+tmax_serial=N Forces the serial simulation of the first N patterns for a testbench written by
nt
MAX Testbench with only the -parallel option. This option then starts the parallel simulation of the
rI
remaining patterns using the parallel parameters specified when the testbench was written. If N=0
or not specified, then all patterns will be serial simulated.
Fo
+tmax_parallel=N Forces the parallel-load simulation of all scan data, with N bits extracted and
serially simulated. This option overrides the behavior of a testbench written by MAX Testbench
se
with the -serial option and overrides the value of N of a testbench written by MAX Testbench with
the -parallel option. If N is not specified, it is processed as zero (meaning all bits are parallel-
U
loaded).
ed
tmax_n_pattern_sim=N Specifies the number of patterns to simulate.

ct
tri
es
R

TetraMAX Workshop
Runtime Programmability for Patterns
 A special “generic” testbench is created

 Subsequent testbenches can be generated to only produce the required
pattern data that will be used by the generic testbench
ng
 Pattern can be changed at runtime without having to recompile simv
ni
run_atpg -auto
ai
write_patterns pats_1.stil –format stil
write_testbench –input pats_1.stil –output xtb_1 -parameter {–generic_testbench}
Tr
run_atpg -auto
write_patterns pats_2.stil –format stil
ip
write_testbench –input pats_2.stil –output xtb_2 -parameter {–patterns_only}
write_patterns -first 5 –last 10 pats_3.stil –format stil
ch
write_testbench –input pats_3.stil –output xtb_3 -parameter {–patterns_only}
ro
%> ./simv
%> ./simv +tmax_test_data_file=“xtb_2.dat"
ic
%> ./simv +tmax_test_data_file=“xtb_3.dat"
6- 27
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Recommended Simulation Strategy
 Before post-route SDF is available, run zero-delay or unit-delay

simulations
 Simulate all patterns with the parallel-load testbench
ng
 Validate the ATPG patterns as early as possible in the overall design
ni
flow in order to stay out of the critical path
ai
 With post-route SDF timing annotated simulate:
Tr
 ALL patterns with the parallel-load testbench
 As many patterns as possible with the serial-load testbench (how many depends
ip
on simulation runtime and/or ASIC vendor requirements)
ch
 At a minimum, the chain test pattern should be serially simulated
ro
ic
6- 28
lM
na
SIMULATION DELAY SWITCHES

er
Zero delay:
nt
Use +nospecify +zero_delay_mode +tetramax

rI
Having problems? Try unit delay or typical timing

Unit delay:
Fo
Unit cell delays, what about interconnect delays

Having problems? Try typical timing
se
Typical delay:
Typical cell delays, what about interconnect delays
U
Having problems? Try fully annotated timing

ed
ct
tri
es
R

TetraMAX Workshop
Verilog Simulation
 Any Verilog simulator can be used to simulate the testbench generated

by MAX Testbench
vcs -R -l xtb_verilog.log +delay_mode_zero +tetramax \
ng
parallel_xtb.v -v ../lib/class.v ../dftc/result/timer.v
ni
 Check the simulation log for mismatches
ai
#############################################################################
MAX TB Version I-2017.09-SP2
Tr
Test Protocol File generated from original file "test.stil"
STIL file version: 1.0
Enhanced Runtime Version: use <sim_exec> +tmax_help for available runtime options
#############################################################################
ip
XTB: Starting parallel simulation of 375 patterns
ch
XTB: Using 0 serial shifts
XTB: Begin parallel scan load for pattern 0 (T=200.00 ns, V=3)
ro
...
ic
XTB: Simulation of 375 patterns completed with 0 errors (time: 225400.00 ns, cycles: 2254)
6- 29
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Writing Patterns
ng
Pattern Validation
ni
ai
Tr
Simulation Debug
ip
ch
ro
ic
6- 30
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Recognize Common Mismatch Causes
Expected vs. Actual States:

 Actual all X’s
Initialization issues
ng

 Loss of internal state - glitches, transient events, X on clock
ni
 Differences with Z’s
ai
 Tristate enable lines (set_buses –external_z x)
Tr
 1/0 or 0/1 mismatches
ip
 Timing problems
ch
 Strobe positioning
 Extra/missing clocks, glitches, transients
ro
 Bad Memory model (have the memory models been validated?!)
ic
 DRC violations (for example C1, C5, or C39) 6- 31
lM
na
The first piece of data to analyze is the expected state, specified in the test data, and the actual state
present from the simulation run.
er
nt
Are all the actual states an “X” value? This can indicate initialization issues, or the loss of the
rI
internal design state during operation, caused by glitches or transient events. If an “X” is found in
the simulation, start tracing that “X” backwards in both the design and in simulation time - where
Fo
did that X come from?

se
Are the mismatches on bi-directional signals, and do the differences involve actual or expected “Z”
values? In this type of situation, review the state of the tristate enable lines.
U
ed
Are the mismatches “hard errors” - for instance, an expected “1” but an actual “0” or vice-versa?
This could be caused by timing problems in the design, or strobe positioning, or extra or missing
ct
clocks, glitches, or transients in the design that are causing the wrong state to appear too soon or too
tri
late compared to what the expected state was.

es
R

TetraMAX Workshop
Begin Debugging the First Failure
 Subsequent failures may be caused by cascade effects

 The very first error is the best place to start examining failures
Errors in scan patterns are bounded by the TetraMAX “Pattern”, which is:
ng

 The previous load_unload Shift that loads the scan-in state
ni
 One or more capture cycles
ai
 The current load_unload Shift that unloads the new scan-out state
Tr
 Example failure log
ip
ch
>>> Error during scan pattern 8 (detected from parallel unload of pattern 7)
ro
>>> At T=3340.00 ns, V=34, exp=0, got=1, chain 1, pin test_so1, scan cell 25
ic
6- 32
lM
na
Because Basic-Scan patterns, starting with a scan load and ending with a scan unload, are self-
contained units, failures in one scan pattern do not typically propagate - unless the failure is
er
indicative of a design or timing fault that persists throughout the patterns (or the patterns have
nt
sequential behavior).
rI
Do not take “first” literally as the first printed mismatch - all mismatches that happen at the same
Fo
time step (or even at different times but in the same STIL Vector) - are all a consequence of the
problem that was functionally detected at this point. Any error generated in the first failing Vector is
se
a good starting point.

U
ed
ct
tri
es
R

TetraMAX Workshop
Failure Log Formats
 For a given simulation mismatch, an initial goal for debug is to

determine the scan cell(s) that captured the wrong values
 The format of the simulation failure log varies depending on several
ng
factors including:
ni
 Parallel vs. serial simulation
ai
 Uncompressed vs. compressed mode
Tr
 Unified STIL Flow vs. Dual STIL Flow
 MAX Testbench runtime defines
ip
 MAX Testbench configuration file options
ch
ro
ic
6- 33
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Regular Scan Mode Failure Log Formats
 With “regular scan” (uncompressed) mode simulations, the failing cell

information is available for both parallel and serial simulations
 Parallel simulation:
ng
ni
ai
>>> Error during scan pattern 9 (detected from parallel unload of pattern 8) Cell names can be
determined by cross-
Tr
referencing with
 Serial simulation: report_scan_cells
ip
XTB: Begin serial scan load for pattern 0 (T=200.00 ns, V=3)
ch
>>> Error during scan pattern 4 (detected from unload of pattern 3)
ro
ic
6- 34
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Regular Scan Mode Failure Log Formats with Cell Names
 To see the cell names in the fail log, the MAX Testbench can be created
using the following configuration variable:
set cfg_parallel_stil_report_cell_name 1
ng
Cell Names
 Parallel simulation:
ni
ai
>>> At T=1540.00 ns, V=16, exp=1, got=0, chain 15, pin test_so15, scan cell 33, cell name q1_reg_0_
Tr
ip
 Serial simulation:
ch
XTB: Starting serial simulation of 288 patterns
ro
ic
6- 35
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Compression Mode Failure Log Formats (Unified STIL Flow)
 With compression mode simulations, the ability to report the failing

cells is more complicated due to the compressor
 Parallel simulation (with USF)
ng
ni
...
ai
>>> At T=13940.00 ns, V=140, exp=1, got=0, pin test_so3, shift cycle 4 ScanOut port and
shift cycle reported.
Tr
>>> At T=13940.00 ns, V=140, exp=1, got=0, pin test_so4, shift cycle 6
>>> Error during scan pattern 34 (detected from parallel unload of pattern 33) Can use diagnosis to
>>> At T=13940.00 ns, V=140, exp=1, got=0, pin test_so13, shift cycle 4 determine failing cell.
ip
 Serial simulation
ch
XTB: Starting serial simulation of 514 patterns
...
ro
ic
6- 36
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Compression Mode Failure Log Formats (Dual STIL Flow)
 With compression mode and Dual STIL Flow, failing cells are reported
XTB: Using 0 serial shifts Note that N-shift is
not supported with
ng
...
XTB: Begin parallel scan load for pattern 30 (T=9200.00 ns, V=93) the Dual STIL Flow
ni
>>> At T=10540.00 ns, V=106, exp=1, got=0, chain 242, scan cell 1
ai
 With set cfg_parallel_stil_report_cell_name 1 in config file:
Tr
ip
...
ch
>>> At T=10540.00 ns, V=106, exp=1, got=0, chain 242, scan cell 1, cell name q1_reg_0_
Reporting of serial simulations with Dual STIL Flow is the same as for USF
ro

ic
6- 37
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Combined Pattern Validation (CPV)
 To report failing cells with parallel

simulation of compression mode USF TetraMAX run_atpg *.psd file
ATPG Parallel
patterns requires additional information Strobe Data
ng
write_patterns
 TetraMAX can create a Parallel Strobe STIL (USF)
ni
Data (PSD) file to provide that additional
write_testbench
ai
information to MAX Testbench
MAX
Tr
 The PSD file is a binary file that contains Testbench
additional internal parallel strobe data
ip
tb.v tb.dat tb_psd.dat
 The PSD file can be created by
ch
TetraMAX either during pattern
generation (run_atpg) or during
ro
VCS
simulation (run_simulation)
ic
6- 38
lM
na
Note: CPV limitations:
er
• The Full-Sequential mode is not supported.

nt
• The set_patterns and run_simulation commands are not supported for multiple contiguous runs
rI
(see “Creating a PSD File”). Also, update and masking flows are not supported, including pattern
restore from binary and new pattern write flows, multiple pattern read back, and single merged
Fo
pattern write.
• When the set_atpg –parallel_strobe_data command is used with DFTMAX Ultra compression,
se
the PSD file is invalidated by a subsequent update_streaming_patterns –

remove_padding_patterns command. Only the run_simulation flow should be used with
U
DFTMAX Ultra compression.

ed
• The -first, -last, -sorted, -reorder, and -type options of the write_patterns command are not
supported.
ct
• The -sorted, -reorder, and -type options of the write_testbench and stil2verilog commands are not
tri
supported.
• The -last option of the run_simulation command is not supported.
es
R

TetraMAX Workshop
Generating a PSD File
 Enable the generation of a PSD file during run_atpg:

set_atpg –parallel_strobe_data_file <PSDfile> -replace
run_atpg -auto
ng
 PSD file can be (re)generated during simulation with:
ni
run_sim -parallel_strobe_data_file <PSDfile> -replace
ai
 TetraMAX II does not support generating a PSD file during run_atpg
Tr
 If enabled, a Warning message will be issued
 A PSD file will still be created but it will be unusable
ip
 Use run_sim to create the PSD file with TetraMAX II
ch
 In DFTMAX Ultra flows, the PSD file should be created by run_sim after
ro
the patterns have been generated by ATPG and the padding patterns
have been removed
ic
6- 39
lM
na
To create the PSD file with DFTMAX Ultra compression in a single session:
er
1. Run ATPG in TetraMAX ATPG.

nt
run_atpg -auto
rI
2. Use the update_streaming_patterns command to clean up the padding patterns.

update_streaming_patterns -remove_padding_patterns
Fo
3. Write the unified STIL patterns.

write_patterns out.stil -format stil -unified -replace
se
4. Delete all current internal and external patterns

set_patterns -delete
U
5. Specify a set of externally generated patterns.

ed
set_patterns -external out.stil

6. Create the PSD file.
ct
run_simulation -parallel_strobe_data_file comp.psd -replace

tri
7. Write the final set of patterns that match the PSD file.
write_patterns pat_u.stil -for stil -repl -unified_stil_flow -ext
es
8. Run MAX Testbench.

write_testbench -input pat_u.stil -out maxtb -replace \
R
-parameters {-log mxtb.log -verbose -config my.cfg}

TetraMAX Workshop
Compression Mode Failure Log Formats with PSD
Confirms that the
PSD file is used
 Parallel sim with PSD and cell names (USF)
XTB: Enabling Enhanced Debug Mode. Using mode 1 (conditional parallel strobe). Note that N-shift is
supported with USF
ng
...
ni
ai
Still reports the
Tr
>>>
XTB:
At T=13940.00 ns, V=140, exp=1, got=0, pin test_so13, shift cycle 4
searching corresponding parallel strobe failures...
failures seen at the
>>> At T=13940.00 ns, V=140, exp=1, got=0, chain 242, scan cell 1, cell name q1_reg_0_ ScanOut pins
ip
ch
New section of the failure log
To have the cell name reported, you
ro
shows the “internal” parallel
strobe failures that led to the still need to use a configuration file
ic
failures seen on the ScanOuts when generating the MAX Testbench
6- 40
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Post Process Fail Log to Show Failing Cell Names
 Avoids the overhead during compilation (and simulation) using the

previous solution (cfg_parallel_stil_report_cell_name)
 Useful for large designs that require a lot of memory
ng
 If a W-048 message is seen when creating the MAX Testbench, the
ni
overhead required to report the failing cell names via the configuration
ai
file may be significant
Tr
 Candidate to use the post processing flow
 Uses stil2verilog to post-process a failure log and identify failing
ip
cell names
ch
stil2verilog pats.stil -failing_cell_report sim.log –log new_sim.log
ro
ic
6- 41
lM
na
W-048: Failing scan cell name display feature may have an impact on simulator performance.
er
The failing scan cell name display functionality increases the Verilog testbench size and the
nt
memory usage. On large designs, this feature can impact the simulator performance.
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Flow to Post Process Fail Log and Show Failing Cell Names
Configuration file
not used or disabled
Configuration File
cfg_parallel_stil_report_cell_name 0
Verilog Simulation Log
Pattern, Time, Vector number,
ng
Scan chain name, Cell ID No cell
PSD File STIL File
names
ni
MAX Testbench stil2verilog
ai
stil2verilog –failing_cell_report
Tr
Log with Verilog
ip
Enhanced Simulation Log
W-048 Testbench Pattern, Time, Vector number,
ch
Scan chain name, Cell ID, Cell
Scan cell instance name names
ro
added
VCS
ic
6- 42
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Useful Debugging Signals
 A waveform viewer can view useful signals to help debug mismatches:

 Cycle number (v_count or v_count_per_pat)
 Current Pattern number (cur_pat)
STIL statement currently executed (cur_StmtName)
ng

 Cells with miscompares
ni
 Clocks/Resets
ai
 ScanEnable
Tr
...
"pattern 3":
Call "load_unload" {
"test_so1"=HLHLHHLLHLLLLLLLLLL; "test_so2"=HLHLH…; "test_so3"=HLHL…;
ip
"test_so4"=LLLLLLLLLLLLLLLLLLL; "test_so5"=HHHHL…; "test_so6"=LLLL…;
"test_si5"=0011111011000011101; "test_si1"=00011…; "test_si2"=0110…;
ch
"test_si3"=1111111011000010111; "test_si4"=01111…; "test_si6"=0000…; }
Call "allclock_launch" {
ro
"_pi"=1P101011001000111; }
Call "allclock_capture" {
"_pi"=0P001011000011111; "_po"=LLLLLHHLHHHLLLH…; }
ic
...
6- 43
lM
na
TetraMAX has a command called write_simtrace that can be used to monitor certain signals
during Verilog simulation for debug purposes. See the write_simtrace man page for details.
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
What is Parallel Testbench Doing?
 Load of scan flops not performed by full scan shift

 Load stimulus is applied/forced at scan_flop.SI port
 Shift clock pulsed to load flop then force is released
ng
 Reduces long shift cycle to single cycle for load
ni
 Strobe of scan_flop.Q done in same load cycle
ai
 Capture cycles applied by normal means
Tr
 Shift load/unload can be extended by using N-shift
ip
+define+tmax_parallel=N
ch
 Where N is > 0
ro
ic
6- 44
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Simulation Waveforms
 Sometimes the only way to debug a simulation issue is to view the waves
Time when scan cell is forced
ng
Time when scan cell is released
ni
ai
Time where scan cells
Tr
are strobed/measured
ip
1st pulse to do parallel
load, 2nd pulse for N-shift
ch
ro
Additional cycles for
load_unload and capture
ic
6- 45
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Comparing Waves to TetraMAX
 To debug the root cause of a

simulation mismatch, the value
seen during simulation can be
ng
compared to the value expected by
TetraMAX
ni
To show the simulated values for a
ai

specific pattern in the GSV
Tr
analyze_simulation_data –fast <n>
ip
 The GSV will show that pattern’s
ch
values for the capture procedure(s)
ro
 Trace backwards in the GSV and in
Waves to find the cause
ic
6- 46
lM
na
Another option to show simulated values in the GSV is:
set_pindata –good_sim_results <n>
er
nt
In many cases the cause of the mismatch is a scan cell that was loaded with the wrong value.
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Some Causes of Simulation Mismatches
 Some common causes of parallel simulation mismatches

 Difference between TetraMAX model and simulation model
 Shadow cells may not loaded with expected 1/0 due to missing N-shift(s)
ng
 DRC violations: C5, C12, S18, S29, etc.
ni
 Watch for warnings issue during ATPG and/or when patterns are written in TetraMAX
ai
 If the chain test is failing, then there’s an issue with the parallel load itself
Tr
 Timing issue and/or missing TetraMAX SDC exception with SDF At-Speed
simulation
ip
 Clock edge for falling edge flops too late in period
ch
 Conflicting forces elsewhere in the simulation environment
Some common causes of serial simulation mismatches
ro

 Issue with compression mode logic
ic
 Pipelined scan data not behaving as TetraMAX expects 6- 47
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Writing Patterns
ng
Pattern Validation
ni
ai
Tr
Simulation Debug
ip
ch
ro
ic
6- 48
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Still Have Failures in Simulation or on ATE?
 ATPG pattern testbench simulates with mismatches

 ATE test program runs, but all DUTs produce failures
ng
 Even with clean STA and simulation with no simulation
mismatches, actual DUTs can still fail on ATE
ni
 If the same ATE timing and post-route SDF is used in both STA and
ai
simulation, and STA reports no violations, simulation mismatches can
Tr
still occur due to:
Simulation mode (zero, unit, typical) issues
ip

ATPG results predicted based on 0-delay environment
ch

 Simulation model may not match ATPG model
ro
 The project schedule is tight:
ic
How will you debug the simulation mismatches or ATE failures? 6- 49
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Masking Simulation Failures
 Not Making Any Progress in Debugging?

 Will the project manager or customer relax the schedule so you can perform more
debugging?
ng
 If the mismatches and failures are localized and not widespread, one
ni
option is to use PI/PO Masks, Cell Constraints, or Capture Masks
ai
 Reduce simulation mismatches
Tr
 Reduce ATE false negatives
 Perform the masking in TetraMAX rather than ATE
ip
 Determine reduction in test coverage
ch
ro
ic
6- 50
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Defining Input or Output Masks
 Input masks are accomplished by defining a PI constraint of X on an

input:
add_pi_constraints x <port_name>
ng
 An output mask is used to prevent the ATPG algorithm from observing
ni
faults through a specific output port
ai
add_po_masks <port_name> | -all
Tr
 Faults can no longer be controlled from masked inputs or observed
from masked outputs (therefore coverage will drop)
ip
ch
ro
ic
6- 51
lM
na
Useful if you have a reduced-pin count revision to a full pin count chip and need to determine the
fault coverage (reduction).
er
nt
Power and Ground (VDD/VSS) pins would typically not be masked but totally excluded from the
rI
design. Remove VDD/VSS top-level pins using the “add_net_connections –delete”

command.
Fo
To review existing PI masks use: report_pi_constraints

se
To delete use: remove_pi_constraints [ port | -all ]

U
TetraMAX knows how to handles CLKPOs; do not mask them.

ed
If you discover after simulation or on the ATE that an output has glitches or is difficult to strobe at
ct
the correct time, consider masking it out.

tri
This command is also useful to determine the fault coverage (reduction) of a reduced-pin count
es
revision to a full pin count chip.

R
To review existing PO masks use: report_po_masks

To delete use: remove_po_masks [ port | -all ]

TetraMAX Workshop
Scan Cell Constraints
 TetraMAX supports constraining what is to be loaded into a specific

scan cell (0, 1, X)
add_cell_constraints <0|1|X> <chain|inst> \
ng
[-position {<cell_pos1|sci> [cell_pos2]>}|-all>>]
ni
 Other settings provide for scan cell masking
ai
 OX - scan cell will always “Observe X” regardless of captured value (note: OX =
Tr
“oh X”)
 XX - scan cell will always be loaded with X and observed as X
ip
 To control the value loaded and mask unload
ch
 0X – scan cell will be loaded with a 0 and observe an X
ro
 1X – scan cell will be loaded with a 1 and observe an X
ic
6- 52
lM
na
Cell constraints can be specified in several ways:
er
1. instance name
nt
add_cell_constraints OX reg2/r/D
rI
2. By chain_name & position

Fo
add_cell_constraints xx c34 –position 6

se
3. An entire chain (must also use add_po_masks on scan-output port)

add cell constraint OX CHAIN_1 -all
U
add_po_masks chain_1_SDO
ed
4. Specify a range of flops to be loaded to all 1’s

ct
add_cell_constraints 1 CHAIN_2 –position {23 29}

tri
es
R

TetraMAX Workshop
Non-Scan Cell Masks
 Scan or non-scan elements can be masked with the

add_capture_masks command
 Simulates an X when the specified cell is clocked
ng
 Is similar to but has slightly different behavior than
ni
add_cell_constraints OX
ai
Example:
Tr
add_capture_masks /PROBLEM/NONSCAN/FLOP
ip
 To prevent a loadable non-scan cell from being loaded but still allow the
ch
cell to capture
ro
add_capture_masks nonscan/cell –load_only
ic
6- 53
lM
na
Example report_capture_masks output
Only when add_capture_masks –load_only has been used
er
gate_id type lo instance_name

nt
------- ---- -- ----------------------------

rI
45 DFF -- s1
58 DFF LO n0and
Fo
LO indicates a load-only mask, and -- indicates a normal mask

se
Refer to following SolvNet Articles:

000612 – Creating Test Patterns with Timing Violations in the Scan Chain
U
901030 – Difference Between the add cell const OX and the add capture mask Commands
ed
ct
tri
es
R

TetraMAX Workshop
Per-cycle Pattern Masking
 Goal: replace L’s and H’s with X’s in scan patterns to mask specific
measures that mismatch on tester
 Use –resolve_differences <mask_file> option of set_patterns
ng
to update external patterns
ni
set_patterns –external <patterns_file> \
ai
–resolve_differences <masks_file>
Tr
 When the external patterns are read, TetraMAX will report the total
number of X measures added
ip
ch
set_patterns -external pat.stil –resolve_differences mask.txt
End parsing STIL file pat.stil with 0 errors.
ro
End reading 200 patterns, CPU_time = 33.40 sec, Memory = 5MB
6 X measures were added in the external patterns.
ic
write_patterns mask_pats.stil –format stil –external -replace
6- 54
lM
na
To determine the Test Coverage difference after masking:
er
add_faults –all
nt
# Read UD faults – run_fault_sim can’t identify redundant

rI
faults
read_faults ud.flt –retain_code
Fo
run_fault_sim
se
Per-cycle pattern masking limitations:

U
ed
• Failures in cycle-based format with cycle offset can not be automatically read
• Full-Sequential patterns could have multiple load-unloads with measures on the scanout in each
ct
unload. Only the failures for the first unload can be masked
tri
es
R

TetraMAX Workshop
Fail Data File Support From Simulation
 By default, the simulation failures are formatted to be human-readable

and not ready to be used for TetraMAX masking flows or diagnosis
>>> Error during scan pattern 20 (detected during unload of pattern 19)
ng
>>> At T=10195.00 ns, V=102, exp=0, got=1, chain 1, pin pc[11] , scan cell 0
ni
 To format failure messages for per-cycle pattern masking or diagnosis,
MAX Testbench can be configured to store the failures in a fail data file
ai
Use –run_mode diagnosis option at stil2verilog execution time
Tr

 Initializes file name for collection of the failures for the diagnostics to diag.txt
ip
 Set the variable cfg_diag_file in the config file with the name of the file
ch
set cfg_diag_file <file_name>
 Specify failures file using the tmax_diag_file and tmax_diag define options
ro
at simulation execution
ic
% vcs ... +define+tmax_diag_file=\”<file_name>\”
6- 55
lM
na
For MAX Testbench, the tmax_diag define controls the format of the fail data file.
er
+tmax_diag=<N>
nt
rI
Configures the miscompares in pattern-based (N=1) or cycle-based (N=2) format.

Fo
Note: fail data files can also be created on the ATE

se
U
ed
ct
tri
es
R

TetraMAX Workshop
Failure Data File Formats From Simulation
 Serial simulation
 Pattern-based failure file with output port name
5 test_so4 10 (exp=1, got=0)
ng
 File can be used for per-cycle pattern masking or diagnosis
ni
 Parallel simulation
ai
 Pattern-based failure file with chain name
Tr
3 chain2 7 (exp=0, got=1)
File can be used for per-cycle pattern masking or diagnosis
ip

ch
ro
ic
6- 56
lM
na
Note: If a pattern-based failure file with chain name is used with a DFTMAX design the following
command is required:
er
set_diagnosis -dftmax_chain_format
nt
rI
Note: there is also a cycle based fail data format that is covered in the Diagnosis unit:
Fo
Cycle-based:
se
C <output_name> <cycle> [expected_data]

U
ed
ct
tri
es
R

TetraMAX Workshop
DFTMAX Ultra chain masking
 Mask specific internal scan chains during ATPG or apply masks to

modify existing patterns:
add_chain_masks
ng
 Chain masking applied at compressor inputs
ni
 Done by adjusting values scanned into decompressor cache
ai
 Masked chains loaded with normal scan-in values
Tr
 Not consistent with any type of chain defect
Result is reduction in number of mismatches
ip

Large mismatch count can be hard to debug with high compression
ch

 Small mismatch count allows user to concentrate on individual causes of
ro
mismatches
ic
6- 57
lM
na
add_chain_masks main options:
er
-name { <string_value> ... } Specify chain (or list of chains) to be masked

nt
-do_not_mask { <string_value> ... } Specify chains to never be masked

rI
Takes precedence over conflicting –name or

–compressor specifications
Fo
-compressor { <string_value> ... } Specify compressors for which all chains will be masked
-filename <string_value> Specify file containing chains to be masked
se
-percent <int_value> Percentage of external patterns to be masked

-external Mask the patterns in the external pattern buffer
U
Otherwise specification applies to new patterns

ed
-reset Delete all previous add_chain_masks specifications

-diagnosis Masks the external patterns for diagnosis
ct
-diagnosis_pattern_count Specifies the pattern count for masking each chain

tri
when using the -diagnosis option. The default value is 50

es
The following example masks all chains in the abc.txt file and chains 12, 45, and 67:
R
add_chain_masks -filename abc.txt -name {12 45 67}

TetraMAX Workshop
DFTMAX Ultra chain masking: Examples
 Chain masking for new ATPG patterns

run_drc …
# User wants ch1 and ch2 to be masked
ng
add_chain_masks –name {ch1 ch2}
# add_chain_masks has specified constraints on ATPG,
# so nothing actually happens until run_atpg
ni
run_atpg -auto
ai
# Write the masked pattern set
write_patterns ..
Tr
 Chain masking for an existing pattern set
ip
set_patterns –external …
# User wants to mask ch1 and ch2 of the external pattern set
ch
add_chain_masks –name {ch1 ch2} –external
# add_chain_masks has resimulated the patterns,
ro
# so they are ready to write out immediately
# Write the masked pattern set
ic
write_patterns .. –external
6- 58
lM
na
Limitations of DFTMAX Ultra chain masking:
er
• Chains not within the DFTMAX Ultra codecs (e.g. OCC chains) cannot be masked by this
nt
command
rI
• Coverage will be lower due to loss of observation on masked scan chains

• Chain selection based on trial and error
Fo
• No multicore simulation support for masking of patterns in external pattern buffer

se
U
ed
ct
tri
es
R

TetraMAX Workshop

 Explain the benefits of saving patterns in binary format
ng
 Describe the minimal set of ATPG patterns that should
be simulated with serial load_unload
ni
 Use two ways to translate a STIL pattern to a Verilog
ai
testbench with MAX Testbench
Tr
 Describe 2 reasons why you might use the ATPG
ip
masking commands
ch
Begin Lab 6: Pattern Validation
ro
ic
6- 59
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
report_patterns -all -type Obtain report of patterns and their type

set_atpg -chain_test Specifies bit sequence to load during chain test
write_patterns –format binary Write patterns in binary format
write_patterns –format wgl Write patterns in WGL format for translation to ATE
ng
write_patterns –format stil Write patterns in STIL format for translation to ATE
write_patterns -last 0 Writes the chain test, pattern 0
ni
write_patterns -sorted Writes patterns ordered by complexity
ai
report_scan_cells –all Reports all scan cells
Tr
report_scan_cells -shadow Reports only the shadow gates of scan cells
add_pi_constraints X <port> Apply an input mask to a port
ip
add_cell_constraints <0|1|XX| Control value loaded and/or mask the value
OX|0X|1X> –chain <name> <pos> unloaded from a scan cell
ch
add_po_masks <port> Apply an output mask to a port
add_capture_masks <instance> Mask values captured on a non-scan or scan cell
ro
set_patterns –resolve_diff <f> Apply per-cycle pattern masking
ic
6- 60
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Agenda
DAY
2
ng
ni
ai
Tr
ip
ch
ro
ic
7- 1
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Fault Models and At-Speed Testing ©2018 Synopsys, Inc. All Rights Reserved. 7-1
TetraMAX Workshop
Unit Objective
ng
 List several fault models supported by TetraMAX
ni
 Describe At-Speed defects
ai
 Describe two popular fault models for At-Speed testing
Tr
 Describe three different way to launch an At-Speed transition
ip
for delay testing
ch
 Modify the default STIL Protocol File (SPF) written out from
DFT Compiler to support At-Speed ATPG
ro
ic
7- 2
lM
na
In this unit you will see an overview of At-Speed defects and their causes. You will also learn why
it is important to include At-Speed ATPG tests as part of your overall manufacturing test flow.
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
New Defect Types with New Technologies
 Rapidly changing technology moving down to smaller process

geometries
 Increasing performance requirements to reach GHz in the applications
ng
 Many defects will pass Stuck-At testing and defective parts are sent
ni
back to silicon provider
ai
 Additional IDDQ patterns are not enough, IDDQ current is too high in
Tr
Deep Submicron technology
ip
 Test cost should not increase
ch
ro
~50% of defects at < 0.18µ
not covered by Stuck-At
ic
7- 3
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Sources of Test Escapes
 Nigh and Gattiker list 7 types of test-escapes
 Timing-related defects  Environmental failures
 Resistive contacts/vias,  Soft errors
 Resistive bridges,  Untested faults
ng
 resistive opens  <100% coverage
ni
 gate oxide shorts
 Faults unmodeled by Stuck-At
improper implants
ai

 “stuck opens” causing sequential
Silicide breaks behavior
Tr

 Reliability failures  net-to-net bridging defects
ip
 Circuit / process sensitivities
ch
 Many of the defects can be detected with DFT techniques
Timing-related defects • Unmodeled faults
ro

 Untested faults
ic
Nigh & Gattiker (IBM), Test Method Evaluation Experiments & Data 7- 4
lM
na
Note: a “test escape” is a device that passes every test applied on the ATE but still has undetected
defects that could cause functional issues and/or a customer return
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Delay Testing Introduction: Agenda
Fault Models
ng
ni
At-Speed Launch Methods
ai
Tr
ip
SPF Timing For External Clock
ch
Delay Testing
ro
ic
7- 5
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Fault Models
 TetraMAX supports several fault models

 High defect coverage for established and emerging nodes
ng
1 0
D Q
ni
D Q
ai
 0 0
Tr
Slack-Based
Stuck-At Slack-Based Hold-Time Static Bridging IDDQ
1
ip

ch
1 1 0
ro
Transition Cell-Aware Path Delay Dynamic Bridging IDDQ-Bridging
ic
7- 6
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
At-Speed Defect
 Manufacturing defect that prevents the device from operating At-Speed

 Under static or slow conditions it operates as expected
ng
 In the presence of a defect, the output does not transition within the
stipulated time
ni
 Critical timing paths are particularly susceptible to At-Speed defects, but
ai
other paths as well can have a defect which can lead to failure of the chip
Tr
 If not detected, At-Speed defects will increase the number of test escapes
ip
Normal Transition Slow Transition
High
ch
ro
Low
ic
At-Speed strobe Stuck-At strobe
7- 7
lM
na
Studies have shown if scan-based At-Speed tests are removed from the test program, the escape rate
goes up nearly 3%
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Why Chips Fail “At-Speed”?
Point defects Distributed defects
 Metal scratches  Mask alignment

 Ion implants
ng
 Dark/missing vias
 Poly cracks  Oxide thickness
ni
ai
 Metal/poly bridges  Metal widths
Tr
 Metal thickness
ip
Metal short Open via FinFET opens Lithography defect
ch
ro
ic
7- 8
lM
na
Think of “point defects” like circuit nodal defects affecting a gate, for example.
er
Distributed defects affect a bigger part of a circuit. These might be magnified across a long circuit
nt
path.
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Methodologies for At-Speed Defect Testing
 At-Speed Functional Patterns

 Manual effort to create
 Unpredictable coverage
ng
 Costly high speed, high bandwidth ATE required
ni
ai
 Scan based ATPG patterns
Tr
 Automated using DFT structures
 Predictable with high coverage
ip
 Less expensive ATE needed
ch
 Complementary to Stuck-At Methodology
ro
ic
7- 9
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Which Methodology Detects Most Defects?
Slow At-Speed
0 8 Functional
Functional 0
0 5
0 22
ng
190
4 6
ni
2
Stuck-At 0 At-Speed
24 Scan
Scan
ai
Tr
 Venn diagram from HP ITC paper:
A single fault model does not catch all failures
ip

Stuck-At scan missed 20% of the failures
ch

 At-Speed scan caught 97% of the failures
ro
ic
Maxwell (HP), et al, ITC ’96, IDDQ and AC Scan: The War Against Unmodelled Defects
7- 10
lM
na
Many faults fail only At-Speed testing.
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Transition Delay Fault Model
 Defect delay is confined to a single gate pin

 Test pattern applies the transition on the fault site
ng
 Path to apply the transition or to capture its effect is selected by the
tool
ni
 May not be the longest path (more on this later)
ai
 Same fault sites and classes as stuck-at ATPG
Tr
Many possible paths for detection Transition Delay Fault
ip
ch
ro
ic
Defect causes DUT to fail At-speed
7- 11
lM
na
Time you strobe the output is constant (red arrow) and the size of the defect (hashed red pulse) is
constant.
er
nt
With 3 different length paths coming in, the amount of the delay added from the defect is the same,
rI
but you can sensitize it from different paths (I.e. the arrival time of the transition is changing).
(This example shows three paths.)
Fo
Will measure a 0 in the good circuit and a 1 if there’s delay. The larger the delay, the easier it is to
se
detect.
U
In this example, the short path will cause you to actually measure 0 and miss detecting fault. For a
ed
small defect, it’s important to use a longer path.

ct
This is generally the opposite behavior of ATPG, which tries to use less effort to generate a vector
tri
and is one of the limitations of the transition delay model (in general).
To accommodate for this limitation, you should also use the path delay model to detect defects that
es
are distributed along the path. The ATPG algorithm is given the path to test, and it doesn’t have a
choice to use less effort. Targeting a specific path requires a powerful (full-sequential) ATPG
R
algorithm.
In general, for any given transition, there may be multiple paths coming into/out of gate – need to
enhance w/Path Delay testing. Note: this paths can come directly from Prime Time.
TetraMAX Workshop
Detection Path : Does it Matter?
ng
 Consider fault b0 slow-to-rise (STR) on a 4 bit adder
ni
 Can be detected at S0,S1,S2,S3 or C4
ai
Detection at S0
Tr

 Minimum effort for ATPG
ip
 Maximum Slack on the path
ch
 Detection at C4
ro
 Maximum effort for ATPG
Minimum Slack on the path
ic

7- 12
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Detecting a Small Delay Defect
C D Q
1
1 B
A TA-B
Δt
ng
D Q
Small Delay Observe test

A
point
ni
Defect
ai
B Small delay defect not detected through path A-B
Tr
TA-B
ip
C Much better chance to detect through path A-B-C
ch
TA-B-C
ro
ic
Capture
7- 13
lM
na
To illustrate, let’s see what happens when there’s a small delay defect on node A…
• Standard transition delay ATPG will most likely target this fault along the shortest path, path A-B.
er
• Because the slack is so large relative to the defect delay, there’s enough time for the transition and
nt
so the small delay defect is not detected.

rI
• However, Slack-Based ATPG will target the fault along the longest path, path A-B-C.
• This time, the slack is less than the defect delay, so there’s not enough time for the transition and
Fo
there’s a much better chance to detect the fault through this path.
se
This is the way Slack-Based ATPG works….

U
ed
ct
tri
es
R
TetraMAX Workshop
How Are Delay Defects Distributed?
9
Delay Defect Distribution
8
Tighter timing needed

7
to cover these
Number of Devices
ng
6
ni
4 Cycle
Time Covered by transition
ai
3
testing
Tr
2
ip
0
4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46
ch
Additional Delay (ns)
ro
Source: IBM for 0.45um technology
P. Nigh and A. Gattiker, “Test Method Evaluation Experiments &
ic
Data,” ITC, Oct. 2000.
7- 14
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
TetraMAX Slack-Based Transition ATPG
SDC,
 One-pass flow SDF,
Exceptions
Parasitics
 Slack-based ATPG for small delay
defects
ng
PrimeTime
 Standard transition delay ATPG for
larger delay defects
ni
Pin Slacks
ai
Uses PrimeTime
Tr

 Industry’s de-facto sign-off timing TetraMAX
ip
engine Slack-Based ATPG
ch
 No design or DFT changes required Transition and
ro
Small Delay Reports,
Defect Patterns Histograms
ic
7- 15
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Cell-Aware Test
 Increases defect coverage, especially Example of a Complex Cell

for complex cells
 Enhances diagnostics accuracy
ng
Traditional test
targets inter-cell
 Supports flexible ATPG flows faults on pins
ni
 Cell- or instance-based
ai
 Inter-cell + intra-cell patterns
Tr
 Stuck-at and transition delay
Traditional test might
ip
not cover defects like
this inside the cell
ch
ro
ic
7- 16
lM
na
Unlike standard ATPG, cell-aware ATPG explicitly target faults inside cells (intra-cell faults).
er
• It complements existing inter-cell fault models, so it can be thought of as yet another way to
nt
increase defect coverage and lower DPPM. It can be applied to any design to increase defect
rI
coverage—especially if it has complex cells—and enhance diagnostics accuracy.

Fo
• The cell-aware ATPG flows are highly flexible. For example, you can use cell-aware ATPG on
specific cells or instances in a design.
se
• One possible flow is to first run TetraMAX ATPG using inter-cell models. Then, after fault-
U
simulating those patterns using intra-cell models, perform incremental ATPG using intra-cell
ed
models.
ct
• You can use it for both stuck-at and transition delay testing.
tri
es
R
TetraMAX Workshop
Slack-Based Cell-Aware Test
 Combines the best of both
Detect Faults Inside Cells Detect Faults on Longest Paths
ng
VDD
ni
ai
Tr
ip
ch
ro
ic
7- 17
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Z01X Cell-Aware Fault Simulation
 Z01X is a separate Synopsys fault Z01X Cell-Aware Flow

simulation tool
 Can boost defect coverage with PrimeTime Timing
ng
Slacks
functional patterns
ni
 Z01X fault simulates functional TetraMAX II ATPG
ai
patterns to measure cell-aware fault Cell Test
Tr
coverage Models
 Also measures coverage of other fault Z01X Fault Simulation
ip
types
ch
 Reuses cell-aware fault models and Coverage Reports
fault list from TetraMAX
ro
Reports aggregate fault coverage
ic

7- 18
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Path Delay Fault Model
 Transition launched at the start of a specified path

 Transition must be able to propagate along the path
ng
 The entire specified path is considered as the Path Delay “fault”
Huge number of possible circuit paths
ni

Specific Paths extracted from STA
ai

Cumulative effect of
Tr
all defects along path
ip
ch
Test along a
ro
0 1 0
specific path
ic
7- 19
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Bridging Fault Models
 Static Bridging Aggressor

 Bridge fault is static in nature
 Aggressor node will override the value on the 1 0
ng
victim node 1
1
ni
 Stuck-At fault Model used for victim with aggressor
forced to 1/0
ai
0
Dynamic Bridging 0
Tr

0 1
 Bridge fault is dynamic in nature
ip
 Victim node too slow for the rated clock speed
Victim
ch
because of aggressor node effects
 Transition Fault Model used for victim with
ro
aggressor forced to 1/0
ic
7- 20
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Fault Models
ng
ni
ai
Tr
ip
ch
Delay Testing
ro
ic
7- 21
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
At-Speed Fault Models
 Transition Delay
 Standard Transition Delay (targets medium to large delay defects)
 Slack-Based Transition Delay (targets small delay defects)
ng
 Path Delay
ni
 Setup Time Fault
ai
 Hold Time Fault
Tr
 Dynamic Bridging
ip
 Faults are targeted as STR and STF
ch
 STR --- Slow to Rise
 STF --- Slow to Fall
ro
ic
7- 22
lM
na
The Transition Delay fault model models the behavior of defects that cause individual nets or gates
to Transition too slowly. The defects are assumed large enough so that an incorrect value is sampled
er
at any flip-flop.
nt
rI
Transition Delay faults target point defects that can cause an At-Speed failure. Examples of point
defects include a bad metal contact, or a partially defective gate oxide. Transition delay tests can
Fo
provide good At-Speed coverage of gates that are not on a critical path. Path Delay faults may
catch some point defects, but specifically target systematic defects.
se
Transition Delay Testing

U
faults are associated with a library cell

ed
each node has a slow-to-rise/slow-to-fall site

targets point defects
ct
tri
Path Delay Testing

faults are associated with a path
es
targeted paths typically include “critical” paths

targets process-oriented defects
R
TetraMAX Workshop
Structured At-Speed Fault Testing
 At-Speed Test Pattern

 Uses existing scan chains
 Scan load a known circuit state (V1) to prepare for launching a transition at the
ng
target fault site
ni
 Scan shifting can be done at a slower speed
Pulse clock to launch Transition (V2)
ai

Second pulse captures effect of Transition
Tr

 At-Speed cycle time between clocks
ip
V1 V2
ch
CLK
SE
ro
ic
7- 23
lM
na
The principle of detecting a delay fault consists in applying a Transition to the fault site and, after a
specific time (your At-Speed, functional, clock period), measuring the effect of that Transition in
er
the design.
nt
rI
In this timing diagram, TetraMAX will first put the design in a known state using the V1 vector.
Then it will apply the Transition at the fault site; this is achieved using the V2 vector. (V2 vector
Fo
initiates the Transition at the head of the path.)

se
After one period of an At-Speed clock, TetraMAX will measure the effect of the Transition on the
design. This effect must correctly propagate to a PO or a scan flop in order to not have a delay
U
problem in your design.

ed
Note that the only “critical” time is the time between V2 and the capture clock edge (symbolized by
ct
the green arrow). All other operations can be done using the classical test clock, which typically has
tri
a slower period.
es
The tester will use two time sets (i.e. Waveform Tables in TetraMAX) and it changes the timesets
on the fly. (Note: Inexpensive testers can have poor accuracy, and the placement of the pulse is
R
critical.)
TetraMAX Workshop
 Transition Delay – launch method controlled by:

set_delay –launch last_shift|system_clock|extra_shift|any
 last_shift
ng
 Uses the last clock pulse of load_unload as the launch
system_clock
ni

Uses system clock pulses for launch (default)
ai

 extra_shift
Tr
 Launch the transition with a fast OCC shift pulse after the slow shift
any
ip

Allows any of the methods to be used for launching the fault
ch

 Path Delay – No direct control over the launch method
ro
 Fast-Sequential Path Delay: always uses system_clock launch
ic
 Full-Sequential Path Delay: can avoid last_shift launch by constraining ScanEnable
7- 24
lM
na
Fast-Sequential Path Delay: always uses system_clock launch
Full-Sequential Path Delay: constrain ScanEnable to it’s inactive state during capture to avoid
er
last_shift launch (add_pi_constraint 0 test_se)

nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Transition Launch Methods
system_clock Launch (default) last_shift Launch
SE inactive SE active inactive

At-Speed testing time At-Speed testing time
ng
CLK CLK
ni
launch capture launch capture
ai
extra_shift Launch
Tr
SE active inactive
ip
active inactive
Internal Pipelined SE
ch
At-Speed testing time
CLK
ro
ic
Slow Shift Last Slow Shift launch capture
7- 25
lM
na
The system_clock launch is easier to use because it does not require SE switch between
launch and capture.
er
nt
By default, the system_clock launch mode uses a two-clock ATPG engine. (This is similar to
rI
the basic_scan engine but with capture_cycles =2)

Fo
If you can use last_shift launch, you definitely can use system_clock Launch.
se
U
ed
ct
tri
es
R
TetraMAX Workshop
system_clock Launch (Default)
set_delay -launch_cycle system_clock

 PI's are changed at the beginning of each capture cycle
ng
ni
Capture Transition
ai
Launch Transition
Tr
ip
ch
Vector Shift Shift Shift Capture Capture Shift Shift Shift
Load_unload Load_unload
ro
Apply PI's for Launch Apply PI's for Capture
ic
7- 26
lM
na
set_delay –launch_cycle system_clock
er
A selection of system_clock results in a capture clock procedure being used to launch the
nt
Transition and a second capture clock procedure is used to observe it.

rI
Use of system_clock will enable you to also generate Fast-Sequential patterns with the -
Fo
capture_cycle option of the set_atpg command.

se
U
ed
ct
tri
es
R
TetraMAX Workshop
system_clock Launch: Example
ATPG controls load and capture
SI STR fault
values to SO
launch a transition
Scan Chain
X Don’t Care
X A A A
X X X
ng
1 B X B B
ni
1 0 1 1 X 1
ai
D D D
Tr
1 C X C C
X 0 1
0 1 X
ip
ch
After Nth shift V2 vector SE=0
ro
V1 vector SE=0 Capture clock
ic
SE = 1 Launch clock
7- 27
lM
na
This example shows a STR fault at the output of the AND gate. (To test a STR fault on this pin, the
tool must use a two pattern sequence which will change the value from a ‘0’ to a ‘1’).
er
nt
For system_clock, launching the ‘0’ to ‘1’ Transition (launch) at the fault location happens by the
rI
launch clock after the Scan Enable has gone low.

Fo
On the last shift, the inputs of the AND gate are ‘1’ and ‘0’, which means that the output is ‘0’. The
initial state on the output of AND gate has been achieved. The next step is to launch the fault.
se
Take a note on the functional pins of flops “B and C” driving the AND gate; both are at value ‘1’.
U
Pulsing the clock driving these flops, causes the output of the AND gate to ‘1’ and initiates the
ed
launch of the fault.

ct
Immediately after the launch, the capture clock is pulsed, which captures the Transition on the
tri
functional pin of D flop.

es
The launch and the capture happens with Scan Enable inactive.
R
TetraMAX Workshop
system_clock Launch: Details
 Patterns generated primarily using a dedicated (two clock) algorithm

 Generation is fast and efficient in terms of coverage, runtime and pattern count
 Fast-Sequential or Full-Sequential ATPG can also be used
ng
 If set_atpg –capture <n> is set where n>2, then a Fast-Sequential pass is
performed
ni
The ScanEnable timing does not affect the capture operation, it is
ai

constrained to its inactive state
Tr
 At-Speed timing for external clocks can be defined by the user in
ip
special WaveFormTable (WFTs) in the SPF
ch
 Most commonly used At-Speed launch method
ro
ic
7- 28
lM
na
Note: run_atpg –optimize_patterns supports the two-clock ATPG engine
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Additional Delay Test Cycles
 Setup Cycles
 Precede launch cycle
 Get V1 values to non-scan devices
ng
 Propagation Cycles
ni
 Follow At-Speed capture cycle
ai
 Get fault effect to an observation point
Tr
 These are slow cycles and their WFT is the same as what is defined in
the _multiclock_capture_WFT
ip
With On-Chip Clocking the additional cycles are fast pulses
ch

SE
ro
Shift Cycles Setup Cycles L C Propagation Cycles
ic
CLK
7- 29
lM
na
For Fast and Full sequential ATPG, there can be additional cycles that may be needed to set up the
fault detection.
er
nt
For example, extra clock cycles are needed to pass values through a non-scan element or when
rI
detecting faults around the shadow of the memory (i.e. when propagating values through the
memory.)
Fo
Once the capture clock arrives, additional cycles may also be needed to propagate the fault to a scan
se
flop or to the output.

U
These extra cycles use the WFTs that are defined for their capture in the SPF file.
ed
ct
tri
es
R
TetraMAX Workshop
last_shift Launch

 PI’s are changed at the beginning of the capture cycle
ng
ni
ai
Capture Transition
Launch Transition
Tr
SE
ip
CLK
ch
Shift Shift Shift Shift Capture Shift Shift Shift Shift Shift Capture Shift Shift
Load_unload Load_unload
ro
Apply PI's for Launch Apply PI's for capture
ic
7- 30
lM
na
er
For the Transition fault model, this specifies how the Transition is launched. A selection of
nt
last_shift results in the Transition being launched on the last shift clock of the scan chain
rI
load. A capture clock procedure is then used to observe the Transition.

Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
last_shift Launch: Example
ATPG controls load values
SI STR fault
to launchSO
a transitionSI SO
Scan Chain
X Don’t Care
X A A A
X
ng
1 X
X B
ni
B B
1 0 1 1 X 1
ai
D D D
Tr
X C C C
X 0 1
0 1 X
ip
ch
N - 1 shift Nth shift Capture Mode
ro
V1 vector V2 vector SE = 0
ic
SE = 1 SE = 1 Capture clock
7- 31
Launch clock
lM
na
This example shows a STR fault at the output of the AND gate. (To test a STR fault on this pin, the
tool must use a two pattern sequence which will change the value from a ‘0’ to a ‘1’).
er
This AND gate is in between some flops. These flops (A,B,C,D) are part of a scan chain, shown as
nt
dotted blue line.

rI
The ‘0’ to ‘1’ Transition (launch) at the fault location has to happen on the last shift.
Fo
On the N-1 shift, the values on the input of the AND gate are ‘1’ and ‘0’. This gives the V1 vector.
The output is now low. At this time notice the value of flop “A”. Since it creates the Transition, it
se
has a value of ‘1’.

U
On the Nth shift, the output of the AND gate changes to ‘1’ - that is the fault has been launched.
ed
After the launch the SE goes low. Scan chains are no longer present. The capture clock comes in the
first tester cycle and captures the Transition on the functional pin of flop D.
ct
tri
If a ‘0’ is captured at flop D, then there is a fault - otherwise there is not.

es
R
TetraMAX Workshop
last_shift Launch: Details
 Patterns are generated using Basic-Scan ATPG engine

 Generation is fast and efficient in terms of coverage, runtime and pattern count
The STA should ensure that the Scan Enable is fast enough to not affect
ng

the capture operation
ni
 Pipelining ScanEnable can help
ai
 Critical timing for the ScanEnable requires special tester control
Tr
 Not a commonly used launch method
ip
ch
ro
ic
7- 32
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
extra_shift Launch: Details
 Set the launch cycle before run_drc

 Different clock matrix checking for the launch cycle
 Only launching clock needs the extra shift
ng
 Better coverage
ni
 Patterns are generated using two_clock algorithm
ai
 Fast and full sequential ATPG can be used
Tr
 Requires pipelined ScanEnable
ip
 Separate for each clock domain and edge
ch
 Can be added by insert_dft
 Both OCC controller and clock chain need non-pipelined ScanEnable
ro
ic
7- 33
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Pipelined ScanEnable
D Q D Q D Q D Q
SI QB SI QB SI QB SI QB
SE SE SE SE
 Launch on shift clock requires the >CK >CK >CK >CK
ScanEnable to transition from 1 to 0

At-Speed SE
ng
D Q PipelineSE
 Scan enable net has a high load QB
ni
>CK
 Due to high load, it is sometimes not
ai
LOSPipelineEnable
possible to meet timing
Tr
 Pipelined ScanEnable can be used LOSPipelineEnable
with launch on last_shift or
ip
Clock
extra_shift
ch
SE
ro
PipelineSE
PI data
ic
Scan In
7- 34
lM
na
Pipelining scan enable allows a full cycle for the internal scan enable to propagate to the scan
registers. Without pipelining, you have less that a cycle for the external scan enable to propagate
er
and also the added input delay from the pad to account for.
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
At-Speed Faults
ng
ni
At-Speed Launch Modes
ai
Tr
ip
ch
Delay Testing
ro
ic
7- 35
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
STIL Protocol File Timing
 DFT Compiler generates the SPF with only a single timing setup
 Multiple WaveFormTables (WFT’s) all with the same timing
The default SPF timing provided works ‘as-is’ for Stuck-At, Static
ng

Bridging, IDDQ, and OCC-based At-Speed testing
ni
 Only need to modify the WFT’s timing when external clocks are used for
ai
At-Speed testing
Tr
 The same protocol file can be used for both Stuck-At and At-Speed
ATPG
ip
ch
ro
ic
7- 36
lM
na
To generate a SPF from TetraMAX that included all_clock_* procedures:
er
set_faults –model transition

nt
write_drc_file <file name>

rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Allclock Capture Procedures
 Only system_clock launch patterns with external clocks use allclock_*

capture procedures
 Note: patterns that only pulse OCC clocks use the multiclock_capture
ng
procedure
ni
 allclock_launch {}: applied to tagged launch operations in
launch/capture contexts only
ai
Tr
 allclock_capture {}: applied to tagged capture operations in
launch/capture contexts only
ip
 allclock_launch_capture {}: applied to tagged launch-capture
ch
operations only (single-cycle At-Speed tests)
ro
ic
7- 37
lM
na
The all_clock_* capture procedures are referred to a “tagged” procedures. A tagged procedure
is one that is called by TetraMAX for a specific purpose.
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
allclock_*{} Procedures Example
"allclock_capture" { "allclock_launch_capture" {
W "_allclock_capture_WFT_"; W "_allclock_launch_capture_WFT_";
F { F {
"i_scan_block_sel[0]" = 1; "i_scan_block_sel[0]" = 1;
"i_scan_block_sel[1]" = 1; "i_scan_block_sel[1]" = 1;
"i_scan_compress_mode" = 0; "i_scan_compress_mode" = 0;
"i_scan_testmode" = 1; "i_scan_testmode" = 1;
ng
} }
V { V {
ni
"_po" = \r168 #; "_po" = \r168 #;
"_pi" = \r179 #; "_pi" = \r179 #;
ai
} }
} }
Tr
"allclock_launch" {
W "_allclock_launch_WFT_";
F {
ip
...
}
ch
V {
"_po" = \r168 #;
"_pi" = \r179 #;
ro
}
}
ic
7- 38
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
WFTs for External System Clock Launch
WaveformTable "_allclock_launch_WFT_" {
Period ’40ns’;
65 ns Waveforms {
15 ns "CLK1" { P { ’0ns’ D; ’5ns’ U; ’10ns’ D; } }
40 40 "CLK2" { P { ’0ns’ D; ’30ns’ U; ’35ns’ D; } }
ng
"_default_In_Timing_"{01ZN {’0ns’ D/U/Z/N; } }
"_default_Out_Timing_"{X {’0ns’ X; } }
5 10 30 35
ni
"_default_Out_Timing_" { HLT { ’0ns’ X; ’4ns’ H/L/T; } }
CLK1 }
ai
}
30 35 5 10 WaveformTable "_allclock_capture_WFT_" {
Tr
Period ’40ns’;
CLK2
_allclock_launch_WFT_ _allclock_capture_WFT_ Waveforms {
ip
"CLK1" { P { ’0ns’ D; ’30ns’ U; ’35ns’ D; } }
"CLK2" { P { ’0ns’ D; ’5ns’ U; ’10ns’ D; } }
ch
SE
"_default_In_Timing_"{01ZN {’0ns’ D/U/Z/N; } }
"_default_Out_Timing_"{X {’0ns’ X; } }
ro
CLK1 has an effective cycle time of 65ns "_default_Out_Timing_" { HLT { ’0ns’ X; ’4ns’ H/L/T; } }
CLK2 has an effective cycle time of 15ns
ic
}
}
7- 39
lM
na
The WFT period does not need to be At-Speed
• Just need to ensure that there’s an At-Speed relationship between the launch and capture pulses
er
• WaveFormTable timing is changed in consecutive cycles

nt
• Launch pulse can be at the beginning or end of the cycle

rI
• Capture pulse can at the beginning or end of the cycle

Fo
Ensure that the strobe timing is before the clock

• The strobe timing must be earlier in the cycle than the active edge of all the external clocks
se
U
ed
ct
tri
es
R
TetraMAX Workshop
WFTs for External Clock Last Shift Launch
Timing { Timing {
WaveformTable "_default_WFT_" { Original Modified
WaveformTable "_default_WFT_" {
Period '100ns'; Timing Period '100ns'; Timing
Waveforms { Waveforms {
"all_inputs" {01Z {'0ns' D/U/Z;}} "all_inputs" {01Z {'0ns' D/U/Z;}}
"all_outputs" {X {'0ns' X;}} "all_outputs" {X {'0ns' X;}}
"all_outputs" {HLT {'0ns' X; '40ns' HLT;}} "all_outputs" {HLT {'0ns' X; '40ns' HLT;}}
"pci_Clk" {P {'0ns' D; ‘45ns' U; ‘55ns' D;}} "pci_Clk" {P {'0ns' D; '90ns' U; '95ns' D;}}
} }
ng
} }
WaveformTable "_multiclock_capture_WFT_" { WaveformTable "_multiclock_capture_WFT_" {
Period ‘100ns'; Period ‘100ns';
Waveforms { Waveforms {
ni
"all_inputs" {01Z {'0ns' D/U/Z;}} "all_inputs" {01Z {'0ns' D/U/Z;}}
"all_outputs" {X {'0ns' X;}} "all_outputs" {X {'0ns' X;}}
ai
"all_outputs" {HLT {'0ns' X; '40ns' HLT;}} "all_outputs" {HLT {'0ns' X; '8ns' HLT;}}
"pci_Clk" {P {'0ns' D; ‘45ns' U; ‘55ns' D;}} "pci_Clk" {P {'0ns' D; '10ns' U; '15ns' D;}}
} }
Tr
} }
}
}
SE
ip
_default_WFT_ _multiclock_capture_WFT_ _default_WFT_
ch
20ns
pci_Clk = 20ns
ro
90 95 90 95 10 15 90 95
ic
100 ns 100 ns 100 ns 7- 40
lM
na
The delta between rising edges of clock in the Shift WFT and the capture WFT should be equal to
the period of the system clock
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Preambles and Postambles
 Defining load_unload procedure

 Uses the slow timing waveform
 Avoid Postamble if using last_shift launch
ng
ni
"load_unload" {
W "_default_WFT_";
ai
// preamble vectors
Tr
Shift {
V { "BPCICLK"=P; “pci_CLk"=P; "Test_mode"=1;
"nReset"=1; test_sei"=0; "_so"=###; "_si"=###; }
ip
}
// postamble vectors
ch
}
ro
ic
7- 41
lM
na
Preamble and postamble vectors are often seen in scan-through-TAP designs.
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop

 List several fault models supported by TetraMAX
ng
 Describe At-Speed defects
Describe two popular fault models for At-Speed
ni

testing
ai
Describe three different way to launch an At-Speed
Tr

transition for delay testing
ip
 Modify the default STIL Protocol File (SPF) written
ch
out from DFT Compiler to support At-Speed ATPG
ro
ic
7- 42
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
set_delay -launch_cycle Launch delay fault transitions on the last scan shift
last_shift
set_delay -launch_cycle Launch delay fault transitions during capture
system_clock
ng
set_delay -launch_cycle Launch delay fault transitions with an OCC shift
extra_shift
ni
set_delay -launch_cycle any Launch delay fault transitions with any method
ai
multiclock_capture { } Capture procedure used for Stuck-At ATPG and
delay testing with OCC clocks
Tr
allclock_capture { } Capture procedure for capturing an At-Speed
transition with system_clock launch patterns
ip
allclcok_launch { } Capture procedure for launching an At-Speed
transition with system_clock launch patterns
ch
allclock_launch_capture { } Capture procedure for single cycle At-Speed
testing with system_clock launch patterns
ro
ic
7- 43
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
This page was intentionally left blank
ng
ni
ai
Tr
ip
ch
ro
ic
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Agenda
DAY
2
ng
ni
ai
Tr
ip
ch
ro
ic
8- 1
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
At-Speed Constraints ©2018 Synopsys, Inc. All Rights Reserved. 8-1

TetraMAX Workshop
Unit Objective
ng
 List sources of timing exceptions
ni
 Read SDC from PrimeTime to import timing exceptions
ai
in TetraMAX
Tr
 Handle the slow ports and Bidi’s of your designs
ip
 Use Power-Aware ATPG to reduce switching activity
ch
during At-Speed testing
ro
ic
8- 2
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
At-Speed Constraints
 Running a design at its functional rated speed in scan mode creates

issues that need to be considered by ATPG – such as:
 Some paths cannot meet timing in a single At-Speed cycle
ng
 Excessive switching activity during At-Speed scan testing may cause power
issues
ni
ai
 Paths that cannot meet timing can be accounted for with Timing
Exceptions (i.e. design constraints)
Tr
 Excessive switching activity during At-Speed scan testing can be
ip
controlled using Power-Aware ATPG
ch
ro
ic
8- 3
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
At-Speed Constraints: Agenda
Timing Exceptions
ng
ni
ai
Using SDC In ATPG
Tr
ip
ch
Power-Aware ATPG
ro
ic
8- 4
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Timing Exceptions
 Design attributes that impact the generation of valid At-Speed patterns:

 Slow ports (inputs, outputs and bidirectionals)
 False and multi-cycle paths
ng
 Inter-clock domain paths
ni
 If Timing Exceptions are not defined, At-Speed patterns may fail SDF-
ai
based simulation and/or on the ATE because of timing issues
Tr
 Timing Exceptions affect the test coverage
They cause X’s in the design during ATPG due to masking
ip

 Verify each timing exception is really needed
ch
 More of an impact for Scan Compression architectures (especially if high x-
ro
tolerance mode is not used)
ic
8- 5
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Slow Ports
 Slow Inputs: PI’s cannot switch at functional clock speed

set_delay –nopi_changes
Slow Outputs: PO’s cannot be strobed at functional clock speed
ng

set_delay –nopo_measure
ni
 Bidirectional loopback test can fail
ai
add_slow_bidis
Tr
 Output of the BUS primitive goes to X when BIDI is in
output mode
ip
Combo
ch
Logic
X Disables the path in red when
BUS
FLOP
propagating a Transition along
ro
Combo the path in green
Logic
ic
BIDI
8- 6
lM
na
Using “set_delay –nopi_changes” introduces one dead cycle between the last shift and the launch
clock for system_clock launch patterns.
er
nt
Refer to the following SolvNet Article for more details:

rI
Unclocked cycle in transition ATPG patterns

Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Slow Cells
 Cells that drive multi-cycle or false paths can be called “slow cells”
 Specified with the add_slow_cells command
ng
 Can be set on scan or non-scan elements
A transition launched from these cells will be simulated as an X
ni

add_slow_cells <instance_path>
ai
Tr
ip
ch
ro
ic
8- 7
lM
na
For Basic-Scan ATPG, the output is masked if there is a transition on the last-shift cycle. For Fast-
Sequential or Full-Sequential ATPG, the output is masked if there is a transition on any ATPG clock
er
cycle.
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Timing Exceptions
ng
ni
ai
Using SDC in ATPG
Tr
ip
ch
Power-Aware ATPG
ro
ic
8- 8
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Timing Exceptions with an SDC file
 Multi-cycle and false paths are identified in the Synopsys Design

Constraints (SDC) file from Design Compiler or PrimeTime
 To read an SDC file into TetraMAX:
ng
read_sdc <file_name>
ni
 By reading the SDC, TetraMAX can apply the same timing exceptions
ai
during ATPG
Tr
 By default, timing exceptions from the SDC are only honored during At-
Speed testing
ip
ch
 Timing exceptions can be honored during Stuck-At testing with the
following command:
ro
set_simulation –timing_exceptions_for_stuck_at
ic
8- 9
lM
na
The set_sdc command can be used to control how the timing exceptions are interpreted by
TetraMAX.
er
nt
The report_sdc command can be used to report the timing exceptions that were read by
rI
TetraMAX.
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Exception Types
 TetraMAX supports both Setup and Hold exceptions

 Use command set_sdc to control which type of exceptions are
honored
ng
set_sdc [-setup|-nosetup] [-hold|-nohold]
ni
 If both –setup and -hold exceptions are enabled
ai
 If there is no type specified in the SDC, both exceptions are applied
Tr
set_false_path –to iq_reg/D
Otherwise only specified exception is applied
ip

set_false_path –to iq_reg/D -setup
ch
ro
ic
8- 10
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Simulation of Timing Exception During ATPG
FF1 FF2
D Q D Q
SI QB
SI QB
SE
SE
>CK
ng
>CK
set_false_path-to FF2/D
ni
CK
ai
D
Tr
Q (normal)
ip
Q (-setup)
ch
Q (-hold)
ro
Q (both)
ic
8- 11
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Reading SDC
 All legal SDC commands can be read by read_sdc

 Does not support non-SDC commands (i.e. regular PrimeTime Tcl commands)
Reading an SDC is supported only in Tcl mode
ng

 Some TetraMAX Tcl API commands are also valid SDC commands: get_clocks,
ni
get_pins, etc.
ai
 SDC commands affecting Clocks (Propagation)
Tr
 create_clock, create_generated_clock, set_case_analysis
SDC commands affecting ATPG
ip

set_false_path, set_multicycle_path, set_disable_timing,
ch

set_case_analysis, set_clock_group
ro
 Other SDC timing constraint commands are ignored
ic
 set_clock_uncertainty, set_output_delay
8- 12
lM
na
Note: SDC commands are NOT shell commands
- If the SDC file was read in PT with read_sdc, then the file should only contain SDC
er
commands
nt
- If the SDC file was “sourced” in PT, then the SDC file may also contain regular PT Tcl
rI
commands that will not be allowed by TetraMAX

Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Supported SDC Clock Constructs
create_generated_clock
set_clock_groups –multiply_by … –source
–async {CLKA}
CLKA
ng
CLKB OCC
ni
PLL
ai
RAM
Tr
create_clock
-name CLK
ip
–period 100
ch
–waveform {45 55}
CLK
ro
ic
8- 13
lM
na
In summary:
create_clock defines the clock period and timing for all clock sources.
er
nt
set_clock_group defines relationship between different clocks. Used to specify clock groups
rI
that are mutually exclusive or asynchronous with each other in a design so that the paths between
these clocks are not considered during timing analysis or at speed testing. Options such as –
Fo
asynchronous or –exclusive will, in effect, create false_path information between different the
clock domains.
se
create_generated_clock can be used to create internally generated clocks based upon other
U
master clocks.
ed
ct
tri
es
R

TetraMAX Workshop
Supported SDC Exceptions
set_multicycle_path
CLKA (across a path)
ng
CLKB OCC
set_false_path
ni
PLL
-from …
ai
-to … RAM
(across a path)
Tr
ip
set_case_analysis 1
ch
test_mode
set_disable_timing
ro
(across a single arc)
ic
8- 14
lM
na
set_false_paths defines paths which are not timed or tested.
er
set_case_analysis can be used to drive a signal to a constant state such as test_mode.

nt
Similar to set_dft_signal –type constant.

rI
set_disable_timing does what the name implies. It will disable a timing arc.
Fo
set_multicycle_path defines a path which propagates data in, typically, more than one clock
se
cycle. The idea is that data through this path will likely be unknown until X-many cycles have
gone by. It is typically an X-generator.
U
ed
ct
tri
es
R

TetraMAX Workshop
Controlling Clock Propagation
set_sdc –environment none|sdc_case_analysis|tmax_drc
create_clock in SDC
ng
add_clocks in TetraMAX or SPF
ni
ai
Tr
 Clocks can be defined in the SDC file, in TetraMAX (SPF or add_clocks
ip
command), or both
ch
 With the default setting of none, both “Functional Clock” and “Test
ro
Clock” will be considered to propagate through the mux so SDC
ic
exceptions that refer to either clock will be honored
8- 15
lM
na
Note:
er
With a setting of set_sdc –environment sdc_case_analysis, only clocks that

nt
propagate based on the set_case_analysis commands in the SDC will be honored. In the
rI
above example, only SDC exceptions that refer to the “Functional Clock” would be honored by
TetraMAX, since that’s the only clock that is able to propagate through the mux based on the
Fo
set_case_analysis command.
se
Likewise, with a setting of set_sdc –environment tmax_drc, only clocks that propagate
based on the TetraMAX PI constraints will be honored. In the above example, only SDC exceptions
U
that refer to the “Test Clock” would be honored by TetraMAX, since that’s the only clock that is
able to propagate through the mux based on the add_pi_constraint command.
ed
ct
tri
es
R

TetraMAX Workshop
SDC Timing Exception Example
 SDC generated for functional mode might have:

set_false_path –from [get_clocks functional_clock_1] \
-to [get_clocks functional_clock_2]
ng
 Neither of these clocks are used for scan shift or capture, so they are
ni
not TetraMAX clocks
ai
 This exception will be honored in TetraMAX by specifying:
Tr
set_sdc –environment sdc_case_analysis | none
ip
ch
ro
ic
8- 16
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Functional Mode Vs Test Mode
 Focus of SDCs are often for functional or mission-mode timing

 In other words, the normal “in system” environment in which the chip will be
running
ng
 For manufacturing testing, the environment can be very different
ni
 Synchronization – everything fits into a tester cycle
ai
 Operational speeds – scan shifting and static defect detection is slower that
functional speed
Tr
 Test head effects – input drives/slew and output loads/strobes are very different to
ip
the application environment
ch
 Controlled environment – testers work at set temperatures and voltage supply
levels
ro
This is therefore a completely different STA environment!
ic
8- 17
lM
na
SolvNet article ID: 019765 - TetraMAX at-speed timing exceptions for a complex clocking flow
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Test Mode Timing
 Must run full chip Static Timing Analysis (STA) in scan test mode (ATPG
mode)
 STA should be configured to match the environment on the ATE (timing
ng
and loads)
ni
 All the Test-Modes and Test-Operations should be verified:
ai
 Scan Shift (used for both Stuck-At and At-Speed testing)
Tr
 Stuck-At Capture (slow speed capture)
 At-Speed Capture
ip
Design must pass full-chip STA in Test mode (ATPG mode) with sign-off
ch

accuracy
ro
ic
8- 18
lM
na
When we begin the discussions about at-speed test generation, we need the designer to consider the
operating environment of the tester. There may be new constraints to deal with in this environment.
er
nt
Test Mode Timing handle

rI
Functional Timing Mode can lead to missing constraints

Broken scan chains
Fo
Missing timing exceptions

Unconstrained test logic – OCC, Scan Compression etc.
se
Functional Timing Mode can lead to over-constraints

Timing Exceptions are used for Synthesis
U
Some Timing Exceptions may be removed

ed
New violating paths appear only in Test Mode

Misalignment of Timing Exceptions and timing constraints
ct
Testable paths becomes untestable

tri
Un-testable paths could be testable

es
There needs to be some way to simplify and automate this process

R

TetraMAX Workshop
Timing Violations in Test Mode
 SDC is usually developed for Mission Mode

 Functional timing can be very different from ATPG timing
 Often set_case_analysis can prevent STA timing of many paths used by
ng
ATPG
ni
 Result: Too many STA timing exceptions that create X’s in ATPG, but real ATPG
timing violations are missed
ai
Possible solution: Generate new SDC based on violations found by STA
Tr

using ATPG timing
ip
ch
TetraMAX at-speed timing exceptions for a complex clocking flow
ro
ic
8- 19
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Timing Exceptions From Violations Flow
TetraMAX
source tmax2pt.tcl
run_drc at_speed.spf
1. In TetraMAX: source write_timing_constraints capture.tcl \
tmax2pt.tcl -mode capture \
-wft _allclock_launch_WFT_ \
ng
write_timing_constraints \
–mode capture -wft _allclock_capture_WFT_
capture.tcl
ni
2. In PrimeTime:
PrimeTime
ai
a) Use timing from source pt2tmax.tcl
Tr
tmax2pt.tcl output source capture.tcl
write_exceptions_from_violations \
b) Source pt2tmax.tcl -output exceptions.sdc
ip
write_exceptions_from_violations
ch
TetraMAX exceptions.sdc
3. TetraMAX: Read new SDC set_sdc -environment tmax_drc
ro
from pt2tmax using read_sdc exceptions.sdc
ic
set_sdc –environment tmax_drc …
8- 20
lM
na
1. In TetraMAX
a) Run run_drc
er
b) Run tmax2pt.tcl procedure

nt
write_timing_constraints –mode capture

rI
2. In PrimeTime
a) Use timing from write_timing_constraints output script
Fo
b) Run pt2tmax.tcl procedure write_exceptions_from_violations

se
3. Re-run TetraMAX
a) Use set_sdc –environment tmax_drc
U
b) Read new SDC from write_exceptions_from_violations (but not

ed
functional SDC and not SDC from write_timing_constraints)

ct
tri
es
R

TetraMAX Workshop
Fine Tuning the SDC Flow
 To disable a group of exceptions

set_sdc [-nocase_paths –nofalse_paths \
-nodisable_paths -nomulticycle_paths …]
ng
 Prepend the specified instance path to all instances in the SDC file
ni
set_sdc –instance <instance_path>
ai
 For more verbosity during read_sdc
Tr
set_sdc –verbose
ip
 To control the length of multi-cycle paths
ch
set_delay –multicycle_length <d>
ro
ic
8- 21
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Report SDC Exceptions
 Report SDC Constraints

report_sdc # Report SDC objects
-clocks # Report clocks
ng
-to_cells # Report to cells
-groups # Report clock groups
-case_analysis # Report case analysis
ni
-false_paths # Report false paths
ai
-multicycle_paths # Report multi-cycle paths
-case_paths # Report case analysis paths
Tr
-disable_paths # Report disable timing paths
-all_paths # Report all paths
ip
 This command may be used to report on how the SDC timing
ch
exceptions were interpreted by TetraMAX and for debug
ro
ic
8- 22
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Identifying AU Faults Caused by SDC Timing Exceptions
 SDC timing exceptions identify paths that are not expected to meet
single cycle timing and will be masked in TetraMAX
 These masks will cause some faults to be untestable (AU)
ng
 The following command can be used to identify faults that are AU due
ni
to SDC timing exceptions
ai
set_atpg –timing_exception_au_analysis
Tr
 The AU faults identified are only reported separately when the
set_faults -summary verbose command has been set. They will
ip
appear in the fault summary report under the AX subclass of faults
ch
ro
ic
8- 23
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Timing Exceptions
ng
ni
ai
Using SDC in ATPG
Tr
ip
ch
Power-Aware ATPG
ro
ic
8- 24
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Scan Testing is Power-Hungry
Up to 10X Peak Levels of Normal Operating Mode
Switching Activity
70%
Power spikes can
affect at-speed tests
60%
ng
50%
ni
40%
ai
Tr
30%
20%
ip
ch
10%
0%
ro
0 50 100 150 200 250
ic
Pattern Number
8- 25
lM
na
This is a plot of flop switching activity vs. pattern number during scan testing. Notice the peaks;
they can produce up to 10 times the peak power in a device compared with its normal operating
er
mode.
nt
rI
Exceeding the power limits of a design can lead to yield loss and slows test program ramp-up
because too much power consumption can damage devices or cause false failures. It can also be
Fo
very difficult and time-consuming to trace these problems back to excessive power consumption.
se
Today’s nanometer designs are more susceptible to power problems during test because these power
spikes can affect the outcome of at-speed tests.
U
ed
ct
tri
es
R

TetraMAX Workshop
Power Problems During Shift Mode
 Excessive peak power

 IR-drop delays prevent scan data
ng
from shifting at target frequency
Excessive average power
ni

ai
 Hot spots damage device or
drive it out-of-spec
Tr
 Ad hoc “solution”
ip
Reduce scan shift frequency
ch

Functional
Test
(adds more tester time)
ro
ic
8- 26
lM
na
Too much power consumption affects test in different ways depending on whether a device is
shifting in the patterns or capturing the responses.
er
nt
During shift mode, excessive peak power can produce IR-drop delays that prevent scan data from
rI
shifting at the target frequency. That’s what we’re seeing in the red region of this graph of peak IR-
drop in a device.
Fo
Also during shift mode, excessive average power can create hot spots that damage a device or drive
se
it out-of-spec.
U
Both these problems could be addressed by reducing the scan shift frequency on the tester, but this
ed
adds more tester time and increases tester execution cost.

ct
tri
es
R

TetraMAX Workshop
Low-Power (i.e. Adjacent) Fill
 Enable low-power fill during scan shift

set_atpg –fill adjacent
ng
ADJACENT-FILL 0 0 0 0 1 1 1 transition
RANDOM-FILL 0 1 0 0 1 0
ni
CARE BITS 0 · · 0 1 · 4 transitions
ai
SCAN_IN
Tr
CLK
ip
Up to 50% Reduction in Average Test Power
ch
 Generate chain tests with limited switching activity
ro
set_atpg -quiet_chain_test | -noquiet_chain_test
ic
8- 27
lM
na
Typically, only a small fraction of the bits in a pattern are actually needed to detect target faults.
These are called “care bits.”
er
nt
We see that random-filling the other bits causes a lot of switching…

rI
But low-power fill replicates care bits as far as possible down the scan chain, and this results in
Fo
much less switching and up to a 50% reduction in average test power during shift mode.
se
There is a command to control the “effort” level when attempting to reduce shift power:
U
set_atpg -shift_power_effort <low | medium | high | number>

ed
This option enables you to reduce switching activity. The arguments specify a relative level of
effort for reducing switching activity. You can use the number argument to specify a number
ct
between 1 and 100. The lower the specified number, the more effort will be applied to reducing
tri
switching activity. The low argument corresponds to a setting of 50, the medium argument
corresponds to a setting of 30, and the high argument corresponds to a setting of 10.
es
R

TetraMAX Workshop
Shift Power Effort and Budget
 To enable ATPG to reduce the average shift power

set_atpg -shift_power_effort <off|low|medium|high|d>
ng
 To specify a shift power budget
set_atpg –shift_power_budget <d>
ni
 Where d is the maximum percentage of scan cells that switch during shift
ai
Tr
 To reject patterns that exceed the max shift budget, both
switches must be used
ip
set_atpg –shift_power_budget 50
ch
set_atpg –shift_power_effort high
ro
 If high effort is not used, patterns that exceed the budget will be kept if
ATPG can’t detect a fault without exceeding the budget
ic
8- 28
lM
na
-shift_power_effort <off | low | medium | high | d >
Specifies a relative level of effort for reducing switching activity. You can use the d argument to
er
specify a number between 1 and 100. The lower the specified number, the more effort is applied to
nt
reducing switching activity. The low argument corresponds to a setting of 50, the medium argument
rI
corresponds to a setting of 30, and the high argument corresponds to a setting of 10. The default is
the off argument, which disables the -shift_power_effort option.
Fo
The -shift_power_effort settings do not result in an exact reduction of switching activity.

In some cases, there might not be a discernible difference in switching activity reduction, even
se
though different levels are specified.

U
-shift_power_budget number
ed
Sets a budget for TetraMAX ATPG to reject patterns that exceed the specified maximum percentage
of scan cells switching in a shift cycle. This option must be used with the -
ct
shift_power_effort option, and works only with basic scan, fast-sequential, and two-clock
transition ATPG. Set the -shift_power_budget option to 0 to turn it off, as shown in the
tri
following example:
es
set_atpg shift_power_budget 0
R

TetraMAX Workshop
Power Problems During Capture Mode
L C
CLK
 Low-power fill doesn’t limit
switching during capture
SE
 Excessive peak power
ng
 IR-drop delays cause “good”
V1 V2
devices to fail at-speed tests
ni
ai
Ad hoc “solutions”
80%
70%

Tr
60%  Over-design power rails
(increases die cost)
Switching Activity
50%
ip
40%
30%
ch
20%
10%
ro
0%
0 50 100 150 200 250
ic
Pattern Number
8- 29
lM
na
Power problems during capture mode tend to be more difficult to debug and fix. They’re caused by
these peaks in switching activity that occur going from shift mode to capture mode when there are a
er
large number of logic state transitions.

nt
rI
If the switching peaks are large enough, the IR-drop delays cause “good” devices to fail at-speed
tests.
Fo
The problem could be addressed by over-designing the power rails, but this increases die size and
se
die cost. DFT techniques could be used to limit switching during capture mode, but they’re
cumbersome and require a lot of manual intervention.
U
ed
A better approach is to use power-aware ATPG to automatically reduce switching during capture
mode.
ct
tri
es
R

TetraMAX Workshop
Excessive Power During Scan Capture
 Standard ATPG will attempt to target as many faults as possible

 May cause a large number Flip-Flop’s (FF) to toggle
 May exceed the design power intent or limits
ng
 May cause IR drop and unintended ATE failures, or worse, product damage
ni
 Power-Aware ATPG Uses clock-gating structures to limit switching
ai
 Analyzes the fanout of clock gating structures and other clock sources during
Tr
DRC
 Uses a power budget directive for ATPG to reduce maximum number of switching
ip
scanable FF’s
ch
 Actual FF switching activity can be reported after ATPG
ro
ic
8- 30
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Capture Power with Standard ATPG
Standard ATPG
60%
Flop Switching Activity During Capture

50%
Budget reflects peak
switching activity of
ng
40% mission mode operation
ni
30%
ai
Switching
Budget
Tr
20%
ip
10%
ch
0%
ro
0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000 5500
Pattern Count
ic
8- 31
lM
na
This is a standard ATPG run. Each of these red dots represents the percentage of total scan flops in
the design that switch during capture mode for each pattern, and we’re including all the patterns in
er
an ATPG run.
nt
rI
Now let’s say we have a switching budget, about 25% in this example, that reflects the peak
switching activity of mission mode operation.
Fo
It’s apparent that standard ATPG generates a large number of patterns that exceed the switching
se
budget.
U
But power-aware ATPG tries to observe this budget every time it generates a test pattern….
ed
ct
tri
es
R

TetraMAX Workshop
Capture Power with Power-Aware ATPG
Standard ATPG Power-Aware ATPG
60%
Flop Switching Activity During Capture

50%
Budget reflects peak
switching activity of
ng
40% mission mode operation
ni
30%
ai
Switching
Budget
Tr
20%
Trades off more
ip
patterns for lower
10%
switching activity
ch
0%
ro
0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000 5500
Pattern Count

ic
Avoids Yield Loss from False Test Failures
8- 32
lM
na
There’s always a tradeoff between switching activity and pattern count, but the designer now has
control over it.
er
nt
TetraMAX’s power analysis summary provides the “minimum level for peak power budgeting.”
rI
It’s the flop fan-out of the largest independently-controlled clock domain in the design, expressed as
a percentage of total scan flops.
Fo
For more info on Synopsys Power-Aware Test solutions, see the following flash recording on
se
SolvNet:
SolvNet Article: 023940 – Complete Power-aware Test Solution
U
ed
ct
tri
es
R

TetraMAX Workshop
Power-Aware ATPG Commands
 Enable Power-Aware ATPG and set a budget

set_atpg –power_budget <n>
Set an effort level for Power-Aware ATPG
ng

set_atpg –power_effort <high | low>
ni
 Allow testing of asynchronous sets/resets with
ai
Power-Aware on regular scan designs
Tr
set_atpg -power_aware_asyncs | -nopower_aware_asyncs
ip
 Report clock gating analysis done during run_drc
ch
report_clocks –gating
ro
 Report the switching activity per pattern after ATPG
ic
report_power –per_pattern -percentage
8- 33
lM
na
There are several other options for the report_power command:
er
report_power
nt
[-shift] [-capture]
rI
[-average] [-peak]
[-per_clock_domain]
Fo
[-per_pattern] [-per_cycle]
[-first_pattern d] [-last_pattern d]
se
[-max d] [-percentage] [-csv filename]

[-module name]
U
ed
ct
tri
es
R

TetraMAX Workshop
Clock Gating Report
 report_clocks –gating -verbose

 Performs an analysis based upon DRC and reports the clock gating latches
associated with each clock domain
ng
 If DRC finds CG-cells transparent, then those CG cells are not reported
ni
run_drc
…
ai
Begin clock-gating analysis...
585 ATPG controllable clock-gating cells were found
Tr
…
report_clocks –gating -verbose
Clock name: clk (75)
ip
Number of cells directly controlled by the clock: 896 (6.65%)
Number of cells controlled by the clock through a clock-gating cell: 12562 (93.18%)
ch
Number of cells directly controlled by the clock + largest clock-gating domain:
1025 (7.60%)
Clock-Gating Latch topt4/regs/cgc6/latch (1287508) drives 12 (0.1%) scan cells
ro
…
Minimum Recommended Low-Power ATPG Budget: 7.60% (1025)
Estimated minimum. Don’t
ic
use as the power budget! 8- 34
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Power-Aware Pattern Reporting
 TetraMAX “power (switching) analysis” command is report_power
TEST-T> report_power –percent [many available options]
ng
-------------------------------------------------------------
Power Analysis Summary
-------------------------------------------------------------
ni
Number of Scan Cells 134813
ai
Number of Patterns 0-2908
Cycles Per Load 2366
Tr
Average Shift Switching 2440.84 1.81%
Average Capture Switching 5882.63 4.36%
ip
Peak Shift Switching 7190 5.33% (pattern: 2 cycle: 1)
Peak Capture Switching 10792 8.01% (pattern: 2669)
ch
To make report_power run faster, use set_atpg –calculate_power
ro

before run_atpg
ic
8- 35
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Power-Aware ATPG Script Example
read_netlist …
run_build_model
…
ng
run_drc
ni
report_clocks –gating [-verbose]
ai
…
Tr
set_atpg –power_budget N
ip
set_atpg –calculate_power
ch
run_atpg –auto
report_power -per_pattern -percentage
ro
ic
8- 36
lM
na
report_clocks [-gating] [-verbose]
Performs an analysis based upon DRC’s and reports the clock gating latches associated with
er
each clock domain

nt
rI
set_atpg [-power_budget <n>]

• Must be set prior to run_atpg
Fo
• Minimize power usage during capture cycles. It requires an integer argument identifying
the maximum percent of scancells associated with clocks which may be pulsed for a
se
given cycle.
U
set_atpg -calculate_power | nocalculate_power

ed
Improves the runtime performance of the report_power command by enabling the

ATPG process to internally calculate the switching activity of the scan flip-flops.
ct
tri
report_power
[-shift] [-capture] [-average] [-peak]
es
[-per_pattern] [-per_cycle] [-first_pattern <d>]

R
[-last_pattern <d>] [-max <d>]

[-percentage] [-csv <filename>]
[-module <name>]
Used after patterns are generated.

TetraMAX Workshop

 List sources of timing exceptions
ng
 Read SDC from PrimeTime to import timing
exceptions in TetraMAX
ni
ai
 Handle the slow ports and Bidi’s of your designs
Tr
 Use Power-Aware ATPG to reduce switching
activity during At-Speed testing
ip
ch
Begin Lab 8: Power-Aware ATPG
ro
ic
8- 37
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
set_sdc [-setup|-nosetup] Enable or disable setup timing exceptions in SDC
set_sdc [-hold|-nohold] Enable or disable hold timing exceptions in SDC
set_sdc –environment none Use neither tmax or case analysis for clock prop
set_sdc –environment tmax_drc Use tmax DRC env for clock propagation
ng
set_sdc –environment Use SDC case analysis for clock propagation
sdc_case_analysis
set_sdc –instance <inst_path> Prepend inst_path to all paths in the SDC
ni
set_sdc -verbose Verbose reporting when SDC is read
ai
read_sdc <sdc_file> Read SDC exceptions into tmax
Tr
report_sdc Report the results after SDC has been read
set_delay -nopi_changes Specify that PI’s cannot change At-Speed
ip
set_delay –nopo_measures Specify that PO’s cannot be measured At-Speed
ch
add_slow_cells <instance> Mask transitions launched from a slow cell
add_slow_bidis <port | -all> Mask the bidirectional loopback path
ro
set_atpg –power_budget <n> Set a switching activity budget
report_power –per_pattern Report the switching activity for each pattern
ic
8- 38
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Agenda
DAY
3
ng
ni
ai
Tr
ip
12 Diagnosis
ch
ro
13 Conclusion
ic
9- 1
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Transition Delay Testing ©2018 Synopsys, Inc. All Rights Reserved. 9-1
TetraMAX Workshop
Unit Objective
ng
Run ATPG for the Transition fault model
ni

ai
 Describe guidelines and flow considerations for Transition
ATPG
Tr
 Describe small delay defects
ip
 Use PrimeTime to generate necessary files for Slack-Based
ch
ATPG
ro
ic
9- 2
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Transition Delay: Agenda
ng
Slack-Based Testing
ni
ai
Tr
Slack-Based ATPG
ip
ch
Persistent Fault Models
ro
ic
9- 3
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Step-by-Step Transition ATPG
 DRC
1. Read the SDC file (read_sdc …)
Define the delay options (set_delay …)
ng
2.
3. Constrain the resets and the Scan Enable if not constrained in the SPF
ni
4. Set SPF file to use (set_drc <SPF file>)
ai
5. Run Design Rule Check (run_drc)
Tr
 ATPG
ip
1. Specify the target fault model (set_faults –model transition …)
ch
2. Run ATPG (run_atpg –auto)
Write pattern in desired format (write_patterns …)
ro
3.
ic
9- 4
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Transition Delay ATPG Script
 Basic Transition Delay script

read_netlist lib.v –lib
ng
read_netlist test.v
run_build_model –model top
ni
read_sdc test_mode.sdc
ai
set_delay –launch_cycle <last_shift|system_clock|extra_shift|any>
add_pi_constraints 0 scan_en
Tr
set_drc test.spf
run_drc
ip
ch
run_atpg –auto
write_patterns pats.stil –format stil
ro
exit
ic
9- 5
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Adding Transition Delay Faults
 Add all possible Transition faults

add_faults –all
 To add a specific Transition fault to the design
ng
add_faults <pin_pathname> -slow <r|f|rf>
ni
 Reading a Fault List File
ai
read_faults <fault file>
Tr
 By default, TetraMAX does not add faults on the Clocks and Scan Enables
for Transition ATPG
ip
 To add faults on the clocks and scan enable
ch
add_faults –clocks
add_faults -scan_enable
ro
 It is not recommended to add faults on clocks and scan enable for Transition
ic
ATPG 9- 6
lM
na
To consider a slow-to-rise (str) and slow-to-fall (stf) delay faults as equivalent:
er
set_delay –slow_equivalence
nt
rI
Transition pattern generation where the slow-to-rise fault for a particular node is considered
equivalent to the slow-to-fall fault for the same node. Once one fault is detected by simulation
Fo
(DS), then the other is considered detected by implication (DI). Reduces run time and pattern count
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Optimized Transition Delay ATPG Engine
set_delay –two_clock_transition_optimization
 Two-clock optimized patterns (on by default)
ng
 Following conditions must be satisfied for optimization
Fault model must be Transition fault
ni

Transition type must be system_clock launch
ai

Merging must be turned on (this is automatically enabled with run_atpg –auto)
Tr

 Basic Scan ATPG must not be disabled
ip
ch
ro
ic
9- 7
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Design Guidelines for Transition Testing
 Keep multiple clocks domains independent

 Do not use a single test-mode clock otherwise delay testing is limited to slowest
clock domain and complex masking needed
ng
 Disable asynchronous resets
ni
 Provide ability to hold resets at their inactive state
ai
 Usually these are multi-cycle (slow) signals
Tr
 Optionally disable test points
 ATPG may miss delay defects on longer functional paths (if not using Slack-
ip
Based ATPG)
ch
 Test points may also not be designed to launch/capture At-Speed
ro
ic
9- 8
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Requirements for Transition ATPG
 Ability to generate At-Speed clock pulses

 Tester must be capable of delivering At-Speed pulses - - or
 Use an existing on-chip PLL to generate At-Speed clock pulses from an on-chip
ng
clock controller (OCC)
ni
 Must run full chip Static Timing Analysis (STA)
ai
 Recommended that the STA environment be configured to match timing on tester
and the pass full-chip STA in Test mode (ATPG mode)
Tr
 Automated by tmax2pt.tcl
ip
 Transition ATPG should include multi-cycle and false path timing
ch
exceptions
 Use read_sdc command to read SDC from PrimeTime
ro
ic
9- 9
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Transition Delay Flow Considerations
 Transition Delay patterns also detect Stuck-At faults

 Persistent Fault model flow can be used to give direct credit to the overlapping
faults (see Appendix)
ng
 Transition patterns may detect Stuck-At faults other than the direct
credited Transition faults
ni
For cumulative coverage, fault simulation of transition patterns against the Stuck-
ai

At fault model is recommended
Tr
 Some Stuck-At faults won’t be detected by any Transition Delay pattern,
ip
so additional patterns will be required to top-off the Stuck-At coverage
ch
 Some transition faults not detectable by system-clock launch can be
detected by last-shift launch
ro
 However, many of those faults are functional false paths and could be considered
ic
to be untestable delay faults 1 9- 10
lM
na
1J. Rearick, “Too Much Delay Fault Coverage Is A Bad Thing”, Proceedings International Test
Conference, pp. 624-633, Oct 2001
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Inter-Clock Domain Paths
 Clock skew issue between different clock domains

 No STA performed for these paths if domain crossings are declared as false
paths
ng
 To disable test generation on inter-clock domain paths (system clock
ni
launch)
ai
 set_delay -common_launch_capture_clock
Tr
 The faults will only be detected using the same clock for launch and capture
 Faults that cannot be launched and captured by the same clock will not be
ip
detected
ch
 To allow multiple clocks to be pulsed together
set_delay –allow_multiple_common_clocks
ro

 Default with common_launch_capture_clock
ic
9- 11
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Common Launch Capture
Both clocks are

tested. Cross
CK1 path values are
CK1
masked
ng
X
Non targeted 1 0
ni
clock domains
held constant
ai
CK2 CK2
Tr
CK1
ip
CK2
ch
Fast Slow
Capture Shift
ro
ic
9- 12
lM
na
TetraMAX is capable of testing multiple clock domains at once, as seen on the left, by using
set_delay -common_launch_capture_clock . This will cause TetraMAX to only test
er
register to register paths in the same clock domain. Any paths that go between clock domains
nt
(which could cause race conditions) will get masked out, as indicated by the X on the left.
rI
To get higher coverage, TetraMAX will run additional passes where the cross clock paths will have
Fo
static values there, as on the right. This allows for improved coverage on the CK1 domain, as
shown on the right side of the figure.
se
`
U
ed
ct
tri
es
R
TetraMAX Workshop
ng
Slack-Based Testing
ni
ai
Tr
Slack-Based ATPG
ip
ch
ro
ic
9- 13
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Testing for Small Delay Defects
 Slack-Based ATPG and Fault Simulation

 Target faults on long paths where the slack available is less than a specified limit
Leverage PrimeTime for accuracy
ng

 More accurate slack calculations than an SDF approach
ni
 Considers “Clock Reconvergence Pessimism Removal”
ai
 Provide user settings for trade-offs
Tr
 Control which faults are to be targeted in test generation based on the slack
margin available
ip
 Define how close to the longest path a detected fault must be to be considered
ch
detected adequately
ro
 Trade off ATPG effort to test longer paths against runtime, coverage, and pattern
count
ic
9- 14
lM
na
SNPS has a sign-off STA engine that is widely used in the industry and extremely accurate.
er
Rather than build our own timing engine inside of TetraMAX, we’re going to leverage PrimeTime.
nt
Solution is based on slack numbers from PT and not SDF.

rI
The tool provide the user with tradeoffs to allow them to generate an optimal set of test benches.
Fo
1) Control the faults which have to be targeted using the Slack-Based ATPG
se
algorithm.
2) Relax the constraint for ATPG to detect the fault on the longest path.
U
ed
Tradeoff 1 & 2 against coverage, pattern count and CPU time.

ct
tri
es
R
TetraMAX Workshop
Slack-Based ATPG Flow
SDC,
SDF,
Exceptions
Parasitics
PrimeTime
ng
ni
Pin Slacks
ai
Tr
TetraMAX
ip
Slack-Based ATPG
ch
ro
Transition and Slack- Reports,
Based ATPG Patterns Histograms
ic
9- 15
lM
na
This shows a flow for Slack-Based ATPG. TetraMAX will read pin slacks from PrimeTime prior to
ATPG. These pin slacks represent the full accuracy of PrimeTime, including CRPR. In this flow,
er
Slack-Based ATPG is being used to measure how good existing transition fault patterns are at
nt
detecting small delay defects, and then to “top off” those patterns to improve coverage of small
rI
delay defects. In summary, Slack-Based ATPG is a way to improve transition fault testing.
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Slack Data Generation : PrimeTime Flow
 Set-up Test Mode timing report_global_slack > my_slacks.dat

constraints in STA: Max_Rise Max_Fall Min_Rise Min_Fall Point
read_sdc at_speed_constraints.sdc -------------------------------------------
ng
* * * * TOP/Z
 Timings and constraints to match 13.72 13.41 1.20 1.46 U114/A1
tester environment 12.44 11.93 1.35 1.74 U114/A2
ni
12.44 11.93 1.20 1.46 U114/Z
Report the worst case rise and
ai
 13.72 13.41 1.20 1.46 U106/A1
12.44 11.93 1.35 1.74 U106/A2
fall slack available on every
Tr
12.44 11.93 1.20 1.46 U106/Z
node for Slack-Based ATPG 13.72 13.41 1.20 1.46 U126/A1
12.44 11.93 1.35 1.74 U126/A2
ip
12.44 11.93 1.20 1.46 U129/Z
ch
ro
ic
9- 16
lM
na
From the global slack file, only the 1st, 2nd and last column is used by TetraMAX.
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Reading Slack Data
 Read slack data

read_timing <file-name> –delete
ng
 The –delete option removes current slack data and replaces with the
data in the file (default just adds data in file to current data)
ni
 Hierarchical Slack Data is not supported
ai
 Manually add the additional hierarchy to the slack data
Tr
 Slack data can be read at any time after run_build_model and prior to
ip
ATPG or fault simulation
ch
 Automatically turns on Slack-Based ATPG
ro
ic
9- 17
lM
na
Turns on/off use of slack for ATPG:
set_delay < –slackdata_for_atpg | –noslackdata_for_atpg >
er
nt
Turns on/off use of slack for fault simulation:

rI
set_delay < –slackdata_for_faultsim | –noslackdata_for_faultsim >

Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Slack on Red Path
Slack =1/1
Slack =1/1
For each Flop:
Tcq = 0.5ns Tsetup = 0.5ns
Slack =1/1
For each two input Gate:
ng
Slack =1/1
T2pind = 2.0ns
Slack =1/1
Slack =1/1 For each single Input Gate:
T1pind = 1.0ns
ni
Slack =1/1
Slack =1/1 Clock Frequency:
ai
Slack =1/1 Clk Period = 12.0ns
Slack =1/1 Rise Transition = Fall Transition
Tr
Slack =1/1
ip
Slack =1/1 Slack available on the node
Slack =1/1
for Rise / Fall Transition
ch
ro
ic
9- 18
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Slack on Green Path
Slack =8/8
Slack =8/8
Slack =8/8 Slack =8/8
For each Flop:
ng
Slack =8/8
Slack =8/8 T2pind = 2.0ns
For each single Input Gate:
ni
T1pind = 1.0ns
Clock Frequency:
ai
Clk Period = 12.0ns
Rise Transition = Fall Transition
Tr
ip
ch
ro
ic
9- 19
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Slack on Blue Path
For each Flop:

ng
Slack =4/4 T2pind = 2.0ns
ni
Slack =4/4 Slack =4/4 T1pind = 1.0ns
Clock Frequency:
ai
Slack =4/4 Clk Period = 12.0ns
Rise Transition = Fall Transition
Tr
Slack =4/4
Slack =4/4
Slack =4/4
ip
Slack =4/4
ch
Slack =4/4
Slack =4/4
ro
ic
9- 20
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Lowest Slacks On Each Pin
Slack =1/1
Slack =1/1 Slack =8/8 Slack =8/8
 The lowest slack values for

Slack =1/1
Slack =1/1
Slack =8/8 each pin is what is reported
ng
Slack =1/1 Slack =1/1 by the
report_global_slacks
ni
command
ai
Slack =1/1
Slack =4/4
Tr
Slack =1/1

Slack =1/1
ip
Slack =1/1
ch
Slack =4/4
ro
ic
9- 21
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Slack-Based ATPG Terminology
 Timing Margin : Tmgn

 Slack of the longest path on which the fault may be detected
 The smallest defect size which can make the device fail
ng
 Slack values read with read_timing
ni
Note: PrimeTime does not know if it’s even possible to launch and capture a
transition fault along its longest path
ai
Tr
 Detection Margin: Tdet
 The slack of path on which the fault is detected
ip
 This may not be the longest path
ch
 Delta
ro
 The difference between tmgn and tdet ( tdet – tmgn )
ic
 Ideally the delta would be 0 which means the detection was along the longest path
9- 22
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Illustration of Tmgn Tdet and Delta
Slack = 4
16
t mgn = 1 ns
ng
t det = 3ns
Slack = 3
ni
17
ai
Tr
18 Slack = 2
ip
Slack = 1
19
ch


ro
tmgn tdet
ic
9- 23
lM
na
Probability of Defect: The chances of physical defect present in the chip after manufacturing.
er
For a given fault : Any defect size less than its Tmgn does not create a problem. This fault does not
nt
affects the function of the chip and hence can be ignored. (area from 0 to Tmgn)
rI
Any defect size bigger that Tdet is supposed to be captured by the regular Transition ATPG.
Fo
(area from Tdet to infinity)

se
If the defect size is between Tmgn and Tdet, those defects get escaped during regular Transition
Test. This is the range of defect magnitude that is to be targeted by Slack-Based ATPG.
U
ed
ct
tri
es
R
TetraMAX Workshop
Test For Understanding (Ex. 1)
1/1
1/1
ng
1/1
For each Flop: 1/1
ni
ai
T2pind = 2.0ns 1/1
Tr
T1pind = 1.0ns
ip
Clock Frequency:
Clk Period = 10.0ns
1/1
ch
Rise Tr. = Fall Tr.
ro
Tmgn = ________
Tdet = ________
ic
Delta = ________
9- 24
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Answer: Tmgn = 1, Tdet = 1, Delta = 0
TetraMAX Workshop
1/1 4/4
1/1 4/4
ng
1/1
For each Flop:
ni
3/3
ai
T2pind = 2.0ns
Tr
T1pind = 1.0ns
ip
Clock Frequency:
Clk Period = 10.0ns
ch
Rise Tr. = Fall Tr.
ro
1’b0
Tmgn = ________
Tdet = ________
ic
Delta = ________
9- 25
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
4/4
4/4
ng
For each Flop:
ni
1’b0
ai
For each two input Gate: 3/3
T2pind = 2.0ns
Tr
T1pind = 1.0ns
ip
Clock Frequency:
Clk Period = 10.0ns
ch
Rise Tr. = Fall Tr. 3/3
ro
Tmgn = ________
1’b0
Tdet = ________
ic
Delta = ________
9- 26
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Negative and Infinite Slack
 Negative Slack
 Path segment with a timing violation
 Indication that PrimeTime and TetraMAX timing exception setups might be different
ng
 Presumably, the PrimeTime functional mode setup was “clean” (i.e., no negative slacks)
ni
 If the PrimeTime setup for Scan mode has negative slacks, then those paths will not
meet single cycle timing on the ATE (and in simulation)
ai
 Inconsistency in timing exceptions may result in bad patterns
Tr
 Use set_delay -negative_slack_checks to identify negative slack values
ip
 Infinite Slack
ch
 Fault not testable
 Use set_delay -infinite_slack_checks to identify infinite slack values
ro
ic
9- 27
lM
na
-negative_slack_checks | -nonegative_slack_checks
er
Enables or disables negative slack check during read timing file, slack-based transition fault test
nt
generation, or fault simulation. During slack-based transition fault test generation or fault
rI
simulation, warning message M752 is printed if this check is enabled. The default is -
nonegative_slack_checks.
Fo
se
-infinite_slack_checks | -noinfinite_slack_checks
U
Enables or disables infinite slack check during read timing file, slack-based transition fault test
ed
generation, or fault simulation. During read timing file, warning message M751 is printed if this
check is enabled. During slack-based transition fault test generation or fault simulation, warning
ct
message M753 is printed if this check is enabled. The default is –noinfinite_slack_checks.

tri
es
R
TetraMAX Workshop
ng
Slack-Based Testing
ni
ai
Tr
Slack-Based ATPG
ip
ch
ro
ic
9- 28
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Setting Standard for Targeted Faults
 Control the number of Faults for Slack Based ATPG

set_delay –max_tmgn <float|fault%>
Default is Infinity
ng

 Faults with tmgn less than max_tmgn or fault% of total faults will be
ni
targeted using Slack-Based ATPG
ai
 Value of max_tmgn is reported when ATPG starts
Tr
TEST-T> run_atpg –auto
The max tmgn for small delay defect faults has been set to 6.04
ip
ch
 Remaining faults targeted as standard transition faults
 The fault targeting process occurs automatically
ro
ic
9- 29
lM
na
This parameter is for the Test Generator and making tradeoffs
er
If you specify set_delay -max_tmgn 50%, you are setting the max_tmgn to include 50% of all the
nt
faults with the smallest tmgn faults as Slack-Based ATPG targets. A message is printed that informs
rI
you of the absolute value of the max_tmgn according to the percentage.

Fo
This implementation is based on following assumptions:

1. All faults are considered, not just the active faults. This is to maintain the same fault base in case
se
of multiple ATPG runs. Otherwise the set of Slack-Based ATPG faults is a moving target.
2. The max_tmgn is adjusted according to the percentage you specify. As a result, it may not be
U
possible to have the exact percentage of faults sampled. For example, if 1/2 of the faults have
ed
tmgn=1, and 1/2 of faults have tmgn=infinite, an 80% setting is essentially the same as 100% since
it will internally set the max_tmgn to infinite.
ct
3. The number of faults can be counted either as collapsed or uncollapsed, which is controlled by
tri
the command report faults -collapsed | uncollapsed.

es
For multicore runs, you need to look at the slave logs to find the absolute value of max_tmgn.
R
TetraMAX Workshop
Minimizing Pattern Count Inflation
 Slack Based ATPG will generate more patterns than standard

transition ATPG
 Selecting paths with minimum slack restricts choice and ability to merge patterns
ng
 Use of the following can help to minimize pattern count increase:
ni
 Set a realistic target fault list (max_tmgn)
ai
 Faults that already have a large timing slack can be targeted with transition ATPG
Tr
 Define minimum detection per pattern limits during slack based ATPG, e.g.:
set_atpg –basic_min_detect 10 –fast_min_detect 10
ip
ch
ro
ic
9- 30
lM
na
Note: During the pattern generation, run_atpg –optimize_patterns can also be used to
reduce the number of Slack-Based patterns that use the two-clock ATPG engine.
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Setting max_tmgn – Default ∞ – Too Many
50000
40000 Fault Universe Targeted

= by Slack-Based ATPG
Endpoints
ng
30000
ni
20000
ai
10000 
Tr
ip
0
ch
Slack
ro
 Default max_tmgn setting is infinity – targets too many faults for Slack-
Based testing
ic
9- 31
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Setting a Reasonable max_tmgn
Fault Universe Targeted by
50000 = Slack-Based ATPG
40000
ng
Endpoints
30000
ni
ai
20000
Tr
0.2
10000
ip
0
ch
Slack
ro
 A setting of 0.2 or 20% covers a reasonable percentage of faults for
ic
Slack-Based testing
9- 32
lM
na
In the TetraMAX reference methodology scripts, a setting of set_delay -max_tmgn 20% is
used as good starting point. Ultimately, it’s up to the user to determine a reasonable setting for –
er
max_tmgn.
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Setting Standard for Full Detection
 Control the maximum delta for full detection

set_delay –max_delta_per_fault <float | tmgn%>
Delta = 0 means fault was detected on the path with minimum slack (the
ng

longest path)
ni
 If delta for a detected fault is less than or equal to
ai
–max_delta_per_fault, the fault is DS; otherwise it is TP (transition
Tr
partially detected)
 The default is 0
ip
ch
ro
ic
9- 33
lM
na
TP = Transition Partially detected (it’s a sub-category of DT). A TP fault will continue to remain
active in the fault list.
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Setting max_delta_per_fault
Targeted Transition
Delay Fault
SET
D Q D
SET
Q
ng
Q
ni
CLR
CLR Q
ai
Tr
SET
D Q
ip
CLR Q
ch
Detected path slack = 0.5 = TP  DS
ro
(if max_delta_per_fault > 0.2)
Minimum slack path = 0.3 (longest) = DS
ic
delta = 0.2 9- 34
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Partially Detected Faults : TP
 Faults categorized as a TP fault

 If delta > max_delta_per_fault for slack-based ATPG faults
 All faults targeted by standard Transition ATPG
ng
 Verbose fault report shows the TP faults
ni
set_faults –summary verbose
ai
 report_faults –summary
Tr
------------------------------ ---- ---------
Detected DT 22079
ip
detected_by_simulation DS (14630)
detected_by_implication DI (3856)
ch
transition-partially_detected TP (3593)
ro
Undetectable UD 284
Not detected ND 7989
ic
9- 35
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Fault Report with Slack Data
 When reporting faults (report_faults) with slack data present, the

report will include the tmgn and delta of each detected fault
ng
tmgn delta
str DS mem2/na1_10/u57/B 3.74 0.00
ni
stf DS a2901/g0/g75/g7/B 5.27 0.00
ai
stf DS mem2/na1_10/u55/Z 3.14 0.06
str DS mem2/na1_10/u58/Z 3.12 0.15
Tr
stf DS mem2/na1_10/u58/Z 2.94 0.28
str DS a2901/g0/g75/g7/Z 3.12 0.00
ip
stf DS a2901/g0/g75/g7/Z 2.94 0.00
ch
str DS a2901/g0/g40/g7/LD 5.51 0.00
ro
ic
9- 36
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Fault Report: report_faults –slack tmgn
 report_faults –slack tmgn
Histogram of Uncollapsed Fault Distribution Cumulative Distribution of tmgn
ng
tmgn tmgn
values #faults values #faults
----------------------- -----------------------
ni
1.30 - 3.13: 8509 3.13: 8509
3.13 - 4.97: 22464 4.97: 30973
ai
4.97 - 6.80: 24549 6.80: 55522
Tr
6.80 - 8.64: 14768 8.64: 70290
8.64 - 10.48: 5741 10.48: 76031
10.48 - 12.31: 19629 12.31: 95660
ip
12.31 - 14.15: 19186 14.15: 114846
14.15 - 15.98: 6372 15.98: 121218
ch
15.98 - 17.82: 7374 17.82: 128592
17.82 - 19.66: 4196 19.66: 132788
ro
> 19.66: 0 < inf: 132788
Infinite: 12220 Infinite: 12220
ic
Undefined: 0 Undefined: 0
9- 37
lM
na
Here is the distribution of the timing margin for a particular design. The default of 10 buckets was
used.
er
nt
Both the histogram and cumulative reported simultaneously using the command.
rI
The group labeled “Infinite” are faults that have timing exceptions (i.e. set_false_path,
Fo
set_multicycle_path, etc.)
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Fault Report: report_faults –slack tdet
 report_faults –slack tdet

Histogram of Uncollapsed Fault Distribution Cumulative Distribution of tdet
ng
tdet tdet
----------------------- -----------------------
ni
1.30 - 3.15: 0 3.15: 0
3.15 - 5.01: 182 5.01: 182
ai
5.01 - 6.86: 3278 6.86: 3460
Tr
6.86 - 8.71: 18560 8.71: 22020
8.71 - 10.57: 13594 10.57: 35614
10.57 - 12.42: 15070 12.42: 50684
ip
12.42 - 14.27: 17708 14.27: 68392
14.27 - 16.13: 1596 16.13: 69988
ch
16.13 - 17.98: 5867 17.98: 75855
17.98 - 19.66: 3812 19.66: 79667
ro
> 19.66: 0 < inf: 79667
ic
9- 38
lM
na
Undetected faults (ND/AU/UD) do not have a tdet defined and are put in the “Undefined” group.
er
nt
set_multicycle_path, etc.)
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Fault Report: report_faults –slack delta
 report_faults –slack delta
Histogram of Uncollapsed Fault Distribution Cumulative Distribution of delta
ng
delta delta
----------------------- -----------------------
ni
0.00 - 1.27: 39827 1.27: 39827
1.27 - 2.55: 11692 2.55: 51519
ai
2.55 - 3.82: 10103 3.82: 61622
Tr
3.82 - 5.10: 9508 5.10: 71130
5.10 - 6.37: 5248 6.37: 76378
6.37 - 7.64: 2715 7.64: 79093
ip
7.64 - 8.92: 946 8.92: 80039
8.92 - 10.19: 255 10.19: 80294
ch
10.19 - 11.47: 79 11.47: 80373
11.47 - 12.65: 4 12.65: 80377
ro
> 12.65: 0 < inf: 80377
ic
9- 39
lM
na
Undetected faults do not have delta defined because they don’t have a tdet defined and are therefore
put in the “Undefined” group.
er
nt
rI
set_multicycle_path, etc.).
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Metric: Delay Effectiveness
Delay Effectiveness = (Area under green curve / Area under red curve) * 100
= (Area under Tdet curve / Area under Tmgn curve) * 100
 Delay Effectiveness
 Assumes uniform probability
ng
of ANY delay defect size
 Considers only faults with
ni
Fault Count
slacks less than max_tmgn
ai
 The lower the average delta,
Tr
the higher the delay
effectiveness
ip
ch
TEST-T> report_faults -slack effectiveness
ro
------------------------------------------
Slack
delay effectiveness 69.94%
ic
9- 40
lM
na
Note: Delay Effectiveness is very different from Test Coverage
er
Another metric is SDQL (Statistical Delay Quality Level)

nt
• Applies probability that a delay defect of a particular size will occur

rI
• Units of DPPM due to Small Delay Defects

• Requires data from the fab
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Slack-Based ATPG Flow
read_netlist CORE.v -library
read_netlist DESIGN.v
run_build_model TOP
read_sdc DESIGN.sdc
ng
run_drc DESIGN.spf
ni
set_faults -model transition
ai
set_delay -launch system
Tr
# Slack-Based ATPG setup
read_timing DESIGN.slack
ip
set_delay –max_tmgn 3.5
set_delay –max_delta_per_fault 0.5
ch
run_atpg –auto
ro
# Report commands
ic
report_faults -slack delta
9- 41
lM
na
The read_timing command turns on Slack-Based ATPG functionality
er
Note: TetraMAX does not support Slack-Based ATPG with the Full-Sequential ATPG engine
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Slack-Based Test Does a Better Job
ng
ni
ai
Tr
ip
ch
ro
ic
Source: STMicroelectronics, Silicon Debug and Diagnosis Workshop, 2012 9- 42
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Improved Pattern Quality
ng
ni
ai
Tr
ip
ch
ro
ic
Source: Stefano Zanatta – Avago Technologies, Adam Cron – Synopsys, Achieving Ultra-Low DPPM, Synopsys Webinar, 2017 9- 43
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
ng
Slack-Based Testing
ni
Slack Data
ai
Tr
Slack-Based ATPG
ip
ch
ro
ic
9- 44
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
 Manage faults for multiple fault models in a single ATPG session

 Setting the current fault model activates its corresponding faults
ng
 Faults in other fault models are inactive
Supports running DRC in multiple test modes
ni

Existing Patterns are deleted (when going back to DRC)
ai

Existing active and inactive faults preserved
Tr

 Fault list is not preserved if returning to BUILD mode
ip
 Supports changing fault models (within TEST mode)
ch
 Existing patterns preserved
Existing active and inactive faults preserved
ro

ic
9- 45
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Persistent Fault Model Flow
 Enable Persistent Fault Models

set_faults -persistent_fault_models
ng
 Advantages of persistent fault models
 Direct credit
ni
 Fault grading existing patterns against other fault models
ai
 Reduces pattern count
Tr
 Reduces ATPG run time
ip
 Simplifies File management
ch
 Update fault status with credit
ro
update_faults -direct_credit
ic
9- 46
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Direct Credit
update_faults -direct_credit
STR on Z pin A B Z
ng
P1 0 X 0
P2 1 1 1
ni
ai
Tr
Stuck-At-0 on Z pin A B Z
P1 1 1 1
ip
ch
A pattern for Slow-to-Rise on the Z pin will also detect a
ro

Stuck-At-0
ic
9- 47
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Combined Coverage with Persistent Fault Models
read_netlist core.v # Take direct credit for TD faults

read_netlist test_scan.v update_faults –direct_credit
run_build_model # Run fault sim to drop more faults
ng
set_drc test_scan_at_speed.spf # before Stuck-At top off
# Setup your at-speed constraints run_fault_sim
ni
run_drc write_patterns pat stil –format ...
set_faults -persistent_fault_models drc -force
ai
set_faults -model stuck # Remove all at-speed constraints
Tr
add_faults -all set_drc test_scan_stuck.spf
set_faults -model transition run_drc
ip
add_faults -all report_faults -summary
set_delay -launch system run_atpg -auto
ch
run_atpg -auto write_patterns stuck_at.pat -format ...
ro
set_faults –model stuck exit
ic
9- 48
lM
na
Note: in the script that when persistent fault models are used, the faults lists for every fault model
used are populated “up front” in the script. Afterward, a given fault list is made “active” with the
er
set_faults command.
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop

 Run ATPG for the Transition fault model
ng
 Describe guidelines and flow considerations for
Transition ATPG
ni
 Describe small delay defects
ai
Use PrimeTime to generate necessary files for
Tr

Slack-Based ATPG
ip
ch
Begin Lab 9: Transition Delay ATPG
ro
ic
9- 49
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
report_patterns -all -type Obtain report of patterns and their type
set_atpg -chain_test Specifies bit sequence to load during chain test
write_patterns –format binary Write patterns in binary format
write_patterns –format wgl Write patterns in WGL format for translation to ATE
ng
write_patterns –format stil Write patterns in STIL format for translation to ATE
write_patterns -last 0 Writes the chain test, pattern 0
ni
write_patterns -sorted Writes patterns ordered by complexity
report_scan_cells –all Reports all scan cells
ai
report_scan_cells -shadow Reports only the shadow gates of scan cells
Tr
add_pi_constraints X <port> Apply an input mask to a port
add_cell_constraints <0|1|XX| Control value loaded and/or mask the value
ip
OX|0X|1X> –chain <name> <pos> unloaded from a scan cell
ch
add_po_masks <port> Apply an output mask to a port
add_capture_masks <instance> Mask values captured on a non-scan or scan cell
ro
add_slow_cells <instance> Mask transitions driven by a slow cell
add_slow_bidis <port | -all> Mask the bidirectional loopback path
ic
9- 50
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Agenda
DAY
3
ng
ni
ai
Tr
ip
12 Diagnosis
ch
ro
13 Conclusion
ic
10- 1
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
On-Chip Clocking Support ©2018 Synopsys, Inc. All Rights Reserved. 10-1
TetraMAX Workshop
Unit Objective
ng
 Describe the need to use PLL for generating fast clocks
ni
 List the various clocks used for ATPG with OCC
ai
 Describe the flow for Transition Fault ATPG using OCC
Tr
ip
ch
ro
ic
10- 2
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
At-Speed Clocking
 To detect Delay defects, At-Speed clocks must be used during scan

testing
 For functional operation, At-Speed clocking may be supplied by:
ng
 External clock sources (i.e. top-level clock ports)
ni
 Internal clock sources (i.e. PLLs)
ai
 During scan testing, either external or internal clock sources can be
Tr
used to test a design At-Speed
Ideally, the clock source used for scan testing should be the same as
ip

for functional operation
ch
ro
ic
10- 3
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Issues Testing At-Speed with External Clocks
 Capture speed is limited by ATE speed

 Capture speed is limited by PAD speed
ng
 Multiple internal clock domains require multiple external CLK pads
In PAD limited designs CLK are collapsed, at-speed testing becomes
ni

unsustainable
ai
Expensive testers are required for at-speed ATPG
Tr

 Using PLL clocks for at-speed ATPG is now a very common practice
ip
ch
ro
ic
10- 4
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Requirements for Using Existing PLL Clocks
 Switch between a slow external clock for shift and a fast (on-chip) clock
for At-Speed capture
 Synchronization between the fast and slow clocks
ng
 Allow ATPG to control how many fast clocks are passed on to the core
ni
on a per pattern basis
ai
 Avoid any glitches
Tr
ip
Effective capture speed
ATE Period
ch
ATE clock
ro
ic
10- 5
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
On Chip Clock (OCC) Controller
Clock chain Capture performed
Controlled by TetraMAX using PLL clocks and
Clock bits
shift performed using
On chip clock generator
ATE clocks
Clock shaper pllclk1 intclk1

PLL
ng
refclk1
refclk2 divider
pllclk2 OCC intclk2 DFF DFF
ni
logic
pllclk3
control intclk3
PLL DFF DFF
ai
Multiplier
Tr
External DFF DFF
Clocks
Scan chain2
Scan chain1
Each type of clock is declared
ip
to TetraMAX via an SPF or
with Quick STIL commands
ch
test_se External clocks
pllclk1
are asynchronous
ATE_clk
ro
test_se to internal clock
domains
ATE_clk
ic
10- 6
intclk1
lM
na
Reference Clocks — The frequency reference to the PLL. Free-running or the PLL may lose
synchronization. Reference clocks can not route directly to the clock inputs of FF’s
er
nt
PLL Clocks — The output of the PLL. A free-running source that also runs at a constant frequency
which may or may not be the same frequency as its’ respective reference clock
rI
Fo
ATE Clocks — Shifts the scan chain. ATE clocks are only used and routed to the respective OCC
controller, they can not route directly to clock inputs of FF’s
se
Internal Clocks — The OCC is responsible for gating and selecting between the PLL clocks and
U
ATE clocks to create the internal clocks. Internal Clocks are the output of the OCC
ed
External Clocks — Primary inputs that clock flip-flops directly or through combinational logic. Not
generated from PLLs and can not be used or declared as a Reference Clock
ct
tri
es
R
TetraMAX Workshop
Fundaments of OCC
 OCC should be placed on internal clock generator after each PLL or

Divider
 No restriction on number of OCCs supported
ng
 Full automation of ATPG and DFT insertion available
ni
 ATPG will decide “per-pattern” which clocks should be pulsed
ai
Mix of OCC (internal) and external clocks is supported
Tr

 No inter-domain testing between internal and external clocks
ip
 Internal clocks are asynchronous to ATE, so relative timing is unpredictable
ch
ro
ic
10- 7
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
OCC IP Operation
 The OCC logic inserted by DFT Compiler supports several “modes of

operation” relating to the OCC
 Functional mode (on-chip clocks used)
ng
 OCC Bypass mode (external ATE clocks used for both shift and capture)
ni
 OCC mode – scan shift (external ATE clocks used)
ai
 OCC mode – At-Speed capture (on-chip clocks used)
Tr
 If TetraMAX uses an SPF from DFT Compiler, the SPF will include
support for both OCC mode and OCC Bypass mode in a single SPF file
ip
 The active mode is selected by specify the active PatternExec for run_drc
ch
ro
ic
10- 8
lM
na
In the SPF, the PatternExec information will look something like this:
er
PatternBurst Internal_scan {
nt
Procedures Internal_scan;
rI
MacroDefs Internal_scan;
ClockStructures Internal_scan;
Fo
}
PatternBurst Internal_scan_occ_bypass {
se
Procedures Internal_scan_occ_bypass;
MacroDefs Internal_scan_occ_bypass;
U
}
ed
PatternExec Internal_scan {
PatternBurst Internal_scan;
ct
}
tri
PatternExec Internal_scan_occ_bypass {
PatternBurst Internal_scan_occ_bypass;
es
}
R
The PatternExec label references a specific PatternBurst label. The PatternBurst label references a
set of Procedures in the SPF that are specific to the targeted mode.
TetraMAX Workshop
OCC Flows in ATPG
 When OCC is used in TetraMAX, there are two options for declaring the
OCC information to TetraMAX:
 SPF from DFT Compiler
ng
 Quick STIL commands
ni
 If scan OCC insertion is done by DFT Compiler or an existing OCC is
ai
inferred, the SPF from DFTC will contain everything that TetraMAX
needs to know about the OCC operation
Tr
 If an SPF with OCC details is not available, then Quick STIL commands
ip
can be used to describe the OCC to TetraMAX
ch
ro
ic
10- 9
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
DFT Compiler and TetraMAX OCC Flows
OCC Insertion Existing OCC 3rd Party Flow
DFTC + TMAX DFTC + TMAX TMAX ONLY
• Netlist • Netlist, • 3rd Party Netlist with OCC
• OCC Instantiated • DFTC Netlist with No SPF
• Clock chain instantiated
ng
ni
ai
• Netlist, OCC and clock chain • Netlist, OCC and clock chain • TetraMAX: QUICK STIL
• DFTC: OCC insertion + • DFTC: Stitching • Edits may be required for
Tr
Stitching • SPF Generated customizing procedures
• SPF Generated
ip
ch
• TetraMAX DRC • TetraMAX DRC • TetraMAX DRC
ro
• TetraMAX ATPG • TetraMAX ATPG • TetraMAX ATPG
ic
SPF Available SPF Not Available 10- 10
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
TetraMAX Flow: SPF Available
set_messages -log tmax.log –replace

read_netlist pll.v
read_netlist core.v
read_netlist top.v
ng
run_build_model top
ni
set_delay –common_launch_capture_clock
ai
set_drc test_scan.spf
run_drc –patternexec Internal_scan
Tr
ip
set_delay –launch system_clock
ch
add_faults –all
run_atpg –auto
ro
write_patterns pattern.stil –format STIL
ic
10- 11
lM
na
run_drc test_scan.spf –patternexec Internal_scan
er
The -patternexec is needed only incase if the SPF file is common for the PLL bypass and PLL
nt
active. If the SPF does not contain PatternExec information, then –patternexec is not
rI
needed.
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
TetraMAX Flow: SPF Not Available
 Quick STIL commands used to describe OCC controller IP and other

scan information
 Declare clocks with the add_clocks command
ng
 Internal clock
ni
 ATE clock
Reference clock
ai

 PLL clock
Tr
 External clock
Declare the other parts of the scan architecture
ip

add_pi_constraints
ch
add_scan_enables
ro
add_scan_chains
ic
10- 12
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
OCC QUICK STIL Flow (1/2)
read_netlist …
run_build_model top
add_scan_chains …
ng
add_scan_enables 1 test_se
add_pi_constraints …
ni
# The number of PLL cycles must be declared first
ai
set_drc -num_pll_cycle 2
Tr
# Declare the ATE clock
ip
add_clocks 0 ate_clk2 -shift -refclock \
–timing {100 45 55 20}
ch
# Declare the Reference clock (if any)
add_clocks 0 ref_clk -refclock –shift \
ro
-timing {100 45 55 20}
ic
10- 13
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
OCC QUICK STIL Flow (2/2)
# Declare the PLL clock

add_clocks 0 U_pll/clka -pllclock
# Declare the Internal clock conditions for each cycle
ng
add_clocks 0 "u_my_pll_ctrl_1/intclk" \
-intclock -pll_source U_pll/clka -cycle { \
ni
0 "u_my_pll_ctrl/snps_clk_chain_0/clk_ctrl_data[0]" 1 \
1 "u_my_pll_ctrl/snps_clk_chain_0/clk_ctrl_data[1]" 1 }
ai
Tr
set_delay -common_launch_capture_clocks
run_drc
ip
set_faults -model transition
set_delay -launch system
ch
run_atpg –auto
ro
write_patterns pll_pat.stil –format stil
ic
10- 14
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Black Box Requirement for DRC
 TetraMAX requires PLL clock to be defined on a black box for DRC

checks
 If the PLL module is not read, then define it as black box
ng
set_build –black_box {my_pll}
ni
 If a model for the PLL exists (via a library cell or netlist), then declare
ai
the instance associated with the PLL as a TIEX (black box)
Tr
set_build –instance_modify TIEX {my_pll}
ip
ch
ro
ic
10- 15
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
DRC Violations
 Certain C rules are for PLL checks

 PLL controller and clocks are simulated by DRC
 Conditioning of the clock-chain and controller is checked
ng
 Timing issues in the PLL controller cannot be checked by the DRC engine
ni
 C34, C35, C36 and C39 can be downgraded in the presence of a user-
ai
defined controller containing asynchronous logic
Tr
 May be required if the user’s controller is not properly understood by the
TetraMAX DRC symbolic simulation engine
ip
 C39 violations require masking: add_cell_constraints OX
ch
NOTE: Full functional simulation is required to ensure user assumptions are
ro
verified
ic
10- 16
lM
na
C39 Violation: This violation occurs when a nonlogical clock propagates to any scan cell input.
Nonlogical clocks include reference clocks and controller clocks declared with the set_drc -
er
controller_clock command. TetraMAX ATPG will not simulate the effect of pulsing the
nt
nonlogical clocks on scan cells. Failure to satisfy this rule can result in patterns which fail in
rI
simulation. If a C39 violation cannot be prevented, you can downgrade it to a warning using the
set_rules command. In addition, you should use the command add_cell_constraints
Fo
XX to both load and unload all unknown values on the affected registers.
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Reporting Internal and PLL Clocks
 Internal Clocks
report_clocks –intclocks
TEST-T> report_clocks -intclock
ng
ni
ai
Tr
 PLL Clocks
report_clocks –pllclocks
ip
ch
TEST-T> report_clocks -pllclocks
ro
ic
10- 17
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Asynchronous Reference Clocks
ATE_CLK
100 ns
ng
REF_CLK1
ni
ai
REF_CLK2
Tr
ip
 ATE and REF clocks often need different frequencies
ch
 Depending on the relationship between the ATE clock and the REF
clock, some pattern formats don’t fully support the REF clock timing
ro
ic
10- 18
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Reference Clock and Pattern Formats
 Relation between reference clock and ATE clock

 Synchronous Single Pulse: Same period for reference and ATE clock
 All formats of patterns supported
ng
 Synchronous Multi Pulse: Period of Reference clock integer divisor of period of
ATE clock
ni
STIL, STIL99, and WGL format supported
ai

 Asynchronous: No relation between the periods of Reference clock and ATE clock
Tr
 STIL format only
ip
 Writing Patterns with Unsupported Reference Clock type results in
ch
M669 message
 Manual edits to the Verilog testbench are required in this case in order to supply
ro
the reference clock for simulation
ic
 All signals besides reference clocks are written correctly
10- 19
lM
na
Example reference clock declarations:
er
# ATE clock
nt
add_clocks 0 ate_clk -shift -refclock –timing {100 45 55 20}

rI
# Synchronous Single Pulse Reference clock

Fo
add_clocks 0 ref_clk -refclock –shift -timing {100 45 55 20}

# Synchronous Multi Pulse Pulse Reference clock
se
add_clocks 0 ref_clk -refclock –shift –ref_timing {50 15 40}

# Asynchronous Reference clock
U
add_clocks 0 ref_clk -refclock –shift –ref_timing {30 10 25}

ed
ct
tri
es
R
TetraMAX Workshop
ATE Cycles During Scan Capture
 PLL clocks are asynchronous with respect to the ATE clock

 Depending on the PLL clocks speed, the internal clocks can come
anytime after the ScanEnable goes low
ng
 TetraMAX does not check if the fast clocks actually arrive while the
ni
ScanEnable is low
ai
 Define the minimum number of ATE clock cycles for which the
Tr
ScanEnable should remain low
set_atpg -min_ateclock_cycles <n>
ip
ch
 By default, ScanEnable is held low the same number of ATE cycles as
the number of PLL clock cycles
ro
set_drc -num_pll_cycles <n>
ic
10- 20
lM
na
If an SPF is used, the –num_pll_cycles is specified in the SPF with the PLLCycles
statement:
er
nt
ClockStructures Internal_scan {
rI
PLLStructures "occ1" {
PLLCycles 4;
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Issue: Capture Window Too Small
 Clock pulses from OCC controller have bled over into next load_unload
ng
shift capture shift
fast_clk
ni
slow_clk
test_se
ai
int_clk
Tr
Two ATE clock cycles
ip
was not enough time to
ch
generate the fast clock
pulses from the OCC
ro
Simulation of OCC scan patterns can catch this issue
ic
10- 21
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Solution: Increase the Number of ATE Cycles
Increase the number of
ATE clock cycles
during capture
ng
shift 4 capture cycles shift
fast_clk
ni
slow_clk
test_se
ai
f_clk_g
Tr
ip
ch
set_atpg -min_ateclock_cycles 4
ro
ic
10- 22
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Capture Cycles with OCC
 Capture cycles for Fast Sequential ATPG

set_atpg –capture_cycle N
For a given pattern, number of capture cycles can be from “2” to “N”
ng

 There can also be patterns where no internal clocks are pulsed during capture
ni
 The –num_pll_cycles value is the maximum number of internal clock
ai
pulses supported by the OCC and is also defined in the SPF
Tr
 Number of capture cycles for ATPG (specified by –capture_cycles)
must not exceed the maximum number of PLL clock cycles supported
ip
by the OCC
ch
set_drc –num_pll_cycles M (where N < M)
ro
ic
10- 23
lM
na
In the SPF, the number of PLL cycles, is defined as follows:
er
nt
PLLStructures "pll_controller" {
rI
PLLCycles 4;
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
PLL Clocks in Capture Cycle
 ATPG uses conditions declared in SPF for each internal clock to control
the number of fast PLL clock pulses used during the capture cycle
 Clock grouping is on by default and appropriate clock conditioning and
ng
masking is done if more than one clock is pulsed in the pattern
ni
 To avoid pulsing an internal clock during ATPG
ai
 add_cell_constraints (OCC w/ clock chain control)
Tr
ip
ch
ro
ic
10- 24
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Clock Grouping with OCC
 Clock grouping with OCC behaves the same way as when only external
clocks are used
ng
 With set_delay -common_launch_capture_clock
 All the OCC clocks treated asynchronously
ni
 Safe patterns generated: the same OCC clock will be used for both launch and
ai
capture
Tr
 By default, multiple “common clocks” may be pulsed in a given ATPG
ip
pattern
ch
set_delay –allow_multiple_common_clocks
ro
ic
10- 25
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Multiple OCC Controller Usage During ATPG
 ATPG uses the clock chain bits to control which OCC clocks are pulsed
in each pattern
ng
Pattern#4 0 0 1 1 0 0
Pattern#3 1 1 0 0 1 1
Pattern#2 0 0 0 0 1 1
ni
ai
Pattern#1 1 1 1 1 0 0
Clock chain
Tr
DFF
DFF
PLL
PLL control1
control1
pll1_clk
ip
DFF
DFF
PLL
PLL control2
ch
pll2_clk
PLL control3
pll3_clk
ro
DFF
ic
10- 26
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Report OCC Clocking
 To report the OCC clocking used by a given pattern:

report_patterns <pattern_#> -clocking
TEST-T> report_pattern 5 -clocking
ng
Clocking only:
Pattern 5 (fast_sequential-parallel_clocking)
ni
// PLL internal clock pulse: capture_cycle=0, node=I_CLOCK_GEN/pclk_occ/U4 (153)
// PLL internal clock pulse: capture_cycle=0, node=I_CLOCK_GEN/sdr_occ/U4 (201)
ai
// PLL internal clock pulse: capture_cycle=0, node=I_CLOCK_GEN/sys_occ/U6 (288)
// PLL internal clock pulse: capture_cycle=1, node=I_CLOCK_GEN/pclk_occ/U4 (153)
Tr
// PLL internal clock pulse: capture_cycle=1, node=I_CLOCK_GEN/sdr_occ/U4 (201)
// PLL internal clock pulse: capture_cycle=1, node=I_CLOCK_GEN/sys_occ/U6 (288)
ip
 In the above report, it shows that in pattern 5, three OCC clocks (pclk,
ch
sdr, and sys) were pulsed twice during scan capture (in cycle 0 and
cycle 1)
ro
ic
10- 27
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Verification of On-Chip Clocking
 Validation of OCC patterns must be done in a Verilog simulator

 PLL clock generation is black-boxed and not modeled in TetraMAX
Full Timing Validation (STA) must also be done
ng

ni
ai
Static Timing Analysis Constraints for On-Chip Clocking Support
Tr
ip
ch
ro
ic
10- 28
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Inter-Clock Domain Test with Synchronous OCC
 DFT Compiler supports the insertion of an OCC block that can manage
1x, 2x, and 4x synchronous clocks
 Outputs of DFT Compiler (both netlist and SPF) are ready for use in
ng
TetraMAX
ni
 Use this switch in the TetraMAX script
ai
set_drc -fast_multifrequency_capture on
Tr
 Insure inter-clock captures enabled
set_delay –nocommon_launch_capture_clock
ip
Mixtures of sync and async OCC controllers are handled safely by TetraMAX
ch

 Use this option to reduce pattern count
ro
set_drc –independent_sync_clocks
ic
10- 29
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Synchronous Multi-Frequency Clocks
 OCC described so that ATPG generates its own clock sequences

 DRC confirms OCC operation but not synchronization - user specification
is assumed to be correct
ng
 Clock synchronization explicitly stated in SPF ClockStructures block
ni
 Latency statement in PLLStructures block
ai
 Used by clock chain re-sequencing
Tr
 ClockTiming block in ClockStructures top level
ip
 Turns on synchronized internal clocks feature
ch
 SynchronizedClocks block specifies which clocks are synchronized to which
other clocks
ro
 Period and Waveform statements and MultiCyclePath block specify timing
ic
details
10- 30
lM
na
Example ClockStructures block with Synchronous OCC:
er
nt
PLLStructures "TOTO" {
Latency 0;
rI
PLLCycles 10;
Fo
Clocks {
"clkate" Reference;
"dut/PLLCLK0" PLL { OffState 0; }
se
"dut/PLLCLK1" PLL { OffState 0; }

"TOTO/U2/Z" Internal { // This block is unchanged
U
"TOTO/U5/Z" Internal { // This block is unchanged

ed
}
}
ct
ClockTiming CTiming1 {
SynchronizedClocks group0 {
tri
Clock CLKX10 { Location "TOTO/U2/Z"; Period '10ns'; Waveform

es
'0ns' '5ns'; }
Clock CLKX5 { Location "TOTO/U5/Z"; Period '20ns'; Waveform
R
'0ns' '10ns'; }
MultiCyclePath 1 { From "TOTO/U5/Z"; To "TOTO/U2/Z"; }
}
}
}
TetraMAX Workshop
Internal Clocking Procedures (ICP)
 Removes all responsibility for finding clock pulse combinations from

ATPG, give complete control to user
 ATPG constrained to use only predefined clock sequences
ng
 DRC not run on OCC Controller, only on fanout from Internal Clocks
ni
 Clock synchronization implicitly assumed
ai
Additional syntax is in ClockStructures block
Tr

 InstructionRegister block in ClockController block
ip
 InstructionRegister used instead of Clock Chain
ch
 ClockConstraints block in ClockStructures top level
ro
 ClockingProcedure blocks specify allowed clock combinations
ic
10- 31
lM
na
Supported by all ATPG engines except Full Sequential
Full Sequential ATPG generates bad patterns when used with Internal Clocking Procedures
er
Stuck-At and Transition Delay fault models

nt
Launch and Capture in adjacent frames for Transition Delay Fault detection
rI
Clock Instruction Register members

Scan cells and/or Primary Inputs
Fo
Non-scan constant-value cells

External clocks (control outside of Inst Reg)
se
U
ed
ct
tri
es
R
TetraMAX Workshop
SPF Example With ICP
ClockStructures Internal_scan { ...
ClockController "PLL_STRUCT_0" { ClockingProcedure extraU1 {
PLLCycles 2; "dutm/clk1"=PP;
Clocks {
"dutm/clk1" Internal { OffState 0; }
"dutm/clk2"=P0;
"dutm/clk2" Internal { OffState 0; } CLKIR=11;
"clkref" Reference; "clkext0"=P0;
ng
"clkext0" External; // Clocking control }
"clkext1" External; // External clock ClockingProcedure intraU0 {
} "dutm/clk1"=00;
ni
InstructionRegister CLKIR { "dutm/clk2"=PP;
"dutc1/FF_0_reg/Q";
ai
"dutc1/FF_1_reg/Q";
CLKIR=01;
} "clkext1"=PP;
Tr
} }
ClockConstraints constraints1 { ClockingProcedure ClockOff {
// Force external clocks off when they’re unspecified "dutm/clk1"=00;
ip
UnspecifiedClockValue Off; "dutm/clk2"=00;
ClockingProcedure intraU1 { CLKIR=00;
ch
"dutm/clk1"=PP;
"dutm/clk2"=00;
}
CLKIR=11; }
ro
"clkext0"=00; }
}
ic
...
10- 32
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
ICP Setup and Commands
 Use of ICP must be declared during run_drc:

set_drc –clock_constraints <name>
 Default is to not use any ClockConstraints block
ng
 Use SDC timing exceptions to mask invalid transitions
ni
 Report a summary
ai
report_clocks –constraints
Tr
 Report information on all ICP’s
ip
report_clocks –constraints -all
ch
 Report procedure-specific information
report_clocks –constraints –procedure <proc_name>
ro
ic
10- 33
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
ICP Reporting Examples
TEST> report_clocks –constraints -all TEST> report_pattern 7 -clocking

----------------------------------------------- Clocking only:
Clock constraints1: Pattern 7 (fast_sequential)
MaximumConstraints sequential depth: 2 Clocking Procedures: U0to1
Defined Clocking Procedures: 3 // PLL internal clock pulse: capture_cycle=0,
Usable Clocking Procedures: 3 node=dutm/ctrl1/U17 (64)
ng
PLL clocks off Procedure: ClockOff // PLL internal clock pulse: capture_cycle=1,
node=dutm/ctrl2/U19 (94)
U0to1:
ni
CLKIR=10010 TEST> report_patterns -all -clk_summary
dutm/ctrl1/U17/Z=10
ai
dutm/ctrl2/U19/Z=01 Pattern Clocking Constraints Summary Report
-------------------- -----------------------------------------------
Tr
#Used Clocking Procedures
U1to0: #U0to1 6
CLKIR=01010 #U1to0 5
ip
dutm/ctrl1/U17/Z=01 -----------------------------------------------
dutm/ctrl2/U19/Z=10
ch
--------------------
ClockOff:
CLKIR=00000
ro
dutm/ctrl1/U17/Z=00
dutm/ctrl2/U19/Z=00
ic
--------------------
10- 34
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Clocking Procedures Pattern Grouping
 ATPG can be controlled to keep patterns that use the same clocking
procedure together
 This allows the patterns to be “split” based on the clocking procedure
ng
 Each pattern file contains patterns from only one clocking procedure
ni
 A clocking procedure may have multiple pattern files
ai
 To group patterns by ClockingProcedure use:
Tr
set_atpg –group_clock_constraints {first_pass middle_pass final_pass}
write_patterns –occ_load_split
ip
 For best ATPG performance: {85 5 2}
ch
 Results in multiple pattern files per clocking procedure
ro
 For minimum number of pattern files: {100 0 0}
ic
 But this increases ATPG runtime substantially
10- 35
lM
na
The –group_clock_constraints arguments are specified in terms of percentages of the
fault list:
er
The first_pass argument specifies the target percentage of the fault list in the first pass through
nt
each clocking procedure. The first pass results in long blocks of patterns with just one clocking
rI
procedure.
The middle_pass argument specifies the target percentage of the fault list in the subsequent
Fo
passes through each clocking procedure. These passes are repeated until the final_pass number
is reached. The middle passes result in shorter blocks of patterns with just one clocking procedure.
se
The final_pass argument specifies the target percentage of the fault list in the final pass in
which any clocking procedure might be used. In this pass, there is no guarantee that any two
U
consecutive patterns will share the same clocking procedure.

ed
-occ_load_split
ct
This option, which is used in the internal clocking procedures feature, splits patterns into a separate
tri
file for each clocking procedure. Note that a new pattern file is saved each time a clocking
procedure changes from one pattern to the next, which can result in a large number of pattern files.
es
Because of this, you should you should use the -occ_load_split option only in combination
with the set_atpg -group_clk_constraints command.
R
TetraMAX Workshop

 Describe the need to use PLL for generating fast
clocks
ng
 List the various clocks used for ATPG with OCC
ni
 Describe the flow for Transition Fault ATPG using
ai
OCC
Tr
ip
ch
Begin Lab 10: OCC for Transition Delay
ro
ic
10- 36
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
run_drc –patternexec Run DRC check using a particular PatternExec
Internal_scan section of the SPF
set_atpg –min_ateclock_cycles 5 Number of ATE clock cycles during for capture
set_drc -num_pll_cycle M Number of OCC fast clock cycles
add_clocks … Use Quick STIL commands to declare the OCC
ng
related clocks when an SPF is not available
report_clocks –intclocks Report the internal (OCC) clocks
ni
report_clocks –pllclocks Report the PLL clocks
ai
set_atpg –capture_cycle N Set the maximum number of capture cycles used
during ATPG. The number (N) selected must be
Tr
less that or equal to the number of fast clock
cycles (M).
ip
ch
ro
ic
10- 37
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Appendix
ng
OCC Implementation Details
ni
ai
Tr
ip
ch
ro
ic
10- 38
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
OCC Controller Waveforms
 Synchronization required
 One pulse of ATE clock to switch in either direction
 3 pulses of PLL clock to capture (to prevent metastability)
ng
Count = 0 (no pulse)
ni
3 synchronization Count = 1 (pulse if enabled)
cycles 5 Count = 2 (pulse if enabled)
Count = 3 (terminal)
ai
fast_clk
Tr
4 9
slow_clk
ip
3 10
scan_en
ch
1 11
clk 2 8
ro
scan_en falling deselects scan_en rising takes effect
slow_clk asynchronously 6 7 on next falling clock edges
ic
10- 39
lM
na
Details of the OCC operation:
er
At first (1), the scan enable (scan_en) is active, so the slow ATE clock will be enabled.
nt
Next (2), scan enable falls.

rI
The slow clock first synchronizes the fall of scan enable (3), then the fast clock (4).
Once the fast clock gets a hold of the scan enable, it passes it through a metastability shift register,
Fo
and onto the counter (5).

According to the clk_enable settings scanned in by TetraMAX to the clock chain, some high-speed
se
pulses will be output from the controller (6).

After this the system stops and waits for the next event (7).
U
Scan enable comes active, again from the ATE (8).

ed
It gets synchronized by the high-speed clock (9) and by the ATE clock (10), and then the results are
shifted out while shifting in the next pattern (11).
ct
tri
es
R
TetraMAX Workshop
Avoid Unified ATE Clock
REF_clock
PLL 10ns
OCC controller
Functional
ng
REF_clock path
PLL 5 ns
ni
OCC controller
ATE
Hold time
ai
slow_clock
violation only
for scan capture
Tr
 Avoid merging different clocks domains together
ip
 Use separate ATE clock for each controller, if possible
ch
 Use set_scan_configuration –internal multi in DFT Compiler to
control scan chain architecting when clocks do get merged
ro
 If OCC is broken, a unified ATE clock makes at-speed testing very difficult when
ic
the ATE clock is used for scan capture in OCC bypass mode (complex masking
required) 10- 40
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Avoid Using Reference Clock as Shift Clock
REF_clock
PLL
OCC controller
ng
Using reference clock as shift clock:
ni

Will prevent using load_unload preambles and postambles to resolve timing
ai

issues
Tr
 Requires design to be shifted at reference clock speed
ip
ch
ro
ic
10- 41
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Avoid Using Reference Clock for Capture or in test_setup
ATE_clock
REF_clock
PLL
OCC controller
ng
ni
 Using reference clock as capture clock:
ai
 Will require logic to be always pulsed (C39 violation)
Tr
 Requires design to be shifted at reference clock speed
ip
 Using the reference clock to run specific configuration during
ch
test_setup sequence:
 Will force test_setup to run at reference clock speed and to have a pulse in
ro
every vector
ic
10- 42
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Clock Bits Must Hold State
D Q D Q occ_so
occ_si SI SI
ng
launch_enable
capture_enable
test_se
SE SE
ni
ai
Tr
 Clock bits must hold state during capture to avoid losing the loaded
ip
state
ch
 C30 and C31 Errors in TetraMAX if this condition is not satisfied
ro
ic
10- 43
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Very Slow De-assertion of Scan Enable
Shift Capture
ng
fast_clk
slow_clk
ni
ai
test_se
Tr
ip
Very slow fall time
ch
Only full timing accurate simulation can catch it
ro
ic
10- 44
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Solution: Add load_unload Postamble*
Procedures {
"load_unload" {
W "_default_WFT_";
Shift {
ng
V { “slow_clk"=P; “test_se"=1; "_so"=##; "_si"=##; “ref_clk”=P; }
}
ni
// Postamble (notice that Scan Outs are masked)
ai
V { “slow_clk"=0; “test_se"=0; “_so”=XX; ref_clk=P; }
Tr
}
shift postamble capture
ip
fast_clk
slow_clk
ch
ref_clk
test_se
ro
* Pulsing the reference clock must not disturb scan chain
ic
10- 45
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Very Slow Assertion of Scan Enable
Capture Shift
ng
fast_clk
slow_clk
ni
ai
test_se
Tr
ip
Very slow rise time
ch
Only full timing accurate simulation can catch it
ro
ic
10- 46
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Solution: Add load_unload preamble *
Procedures {
"load_unload" {
W "_default_WFT_";
V { “slow_clk"=0; “test_se"=0; “ref_clk”=P; } // Preamble
Shift {
ng
V {“slow_clk"=P; “test_se"=1; "_so"=##; "_si"=##; “ref_clk”=P;}
ni
}
}
ai
Tr
capture preamble shift
fast_clk
slow_clk
ip
ref_clk
ch
test_se
ro
* Pulsing the reference clock must not disturb scan chain
ic
10- 47
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
ng
ni
ai
Tr
ip
ch
ro
ic
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Agenda
DAY
3
ng
ni
ai
Tr
ip
12 Diagnosis
ch
ro
13 Conclusion
ic
11- 1
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Path Delay Testing ©2018 Synopsys, Inc. All Rights Reserved. 11-1
TetraMAX Workshop
Unit Objective
ng
 Extract a set of critical paths from PrimeTime
ni
 Describe the syntax of a delay path
ai
 Run ATPG for the Path Delay fault model
Tr
 Describe the Robust and Non-Robust faults classification
ip
 Analyze a Path Delay fault
ch
ro
ic
11- 2
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Automated Links for At-Speed Tests
PrimeTime Critical Timing Paths TetraMAX ATPG
ng
F Timing Exceptions
F
ni
F
F
ai
Test Constraints
Tr
ip
Automatic generation of critical paths and timing exceptions
ch
from PrimeTime to TetraMAX
ro
Automatic, complete timing constraints from ATPG
ic
11- 3
lM
na
Synopsys provides automated links to and from PrimeTime, the Industry leading sign-off timing
analysis tool.
er
nt
You can automatically generate both critical timing paths and timing exceptions from PrimeTime,
rI
and use these to generate at-speed tests using TetraMAX DSMTest.

Fo
Likewise, you can use TetraMAX to automatically generate complete timing constraints for static
timing analysis.
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Path Delay Flow
Design Compiler®
.spf
Scan Netlist
ng
file
Gate Level
ni
ai
PrimeTime®
Tr
Critical
ip
SDC
Paths
file
ch
ro
Path Delay
TetraMAX
ic
Patterns
11- 4
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Main write_delay_paths Options
 write_delay_paths [-max_paths num_paths] [-slack crit_time]

[-nworst num_per] [-clock clock_name | -launch clock_name |
-capture clock_name] [-delay_type min|max] [-group
group_name] –pba [-version] filename
ng
-max_paths Specifies the max number of paths to be written (Default = 1)
ni
-delay_type Use min to extract hold paths
ai
-slack Writes paths with slack less than the specified crit_time (Default = ∞)
-nworst Specifies the number of paths to each endpoint (Default = 1)
Tr
-clock Select paths in clock_name domain
-launch Select paths starting from clock_name domain
ip
-capture Selects paths ending at clock_name domain
ch
-group Selects paths from existing group_name
-pba Uses the exhaustive-effort level of path-based analysis to gather paths
ro
filename Name of file where paths are written
ic
write_delay_paths -slack 6 -max_paths 100 paths.txt
11- 5
lM
na
The write_delay_paths command is part of the pt2tmax.tcl utility script. This utility
script is part of the TetraMAX installation and can be found here:
er
nt
$SYNOPSYS/auxx/syn/tmax/pt2tmax.tcl
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Path Delay Fault Models and ATPG Engines
 set_faults –model path_delay to target the setup-time path delay

fault model
 set_faults –model hold_time to target the hold-time path delay
ng
fault model
ni
 By default, setup-time path delay uses the Fast-Sequential ATPG Engine
ai
 Set an appropriate -capture_cycles value for Fast-Sequential path
Tr
delay
ip
 Full-Sequential ATPG can also be used for path delay ATPG
ch
ro
ic
11- 6
lM
na
Control for using Fast-Sequential for setup-time path delay:
set_atpg –fast_path_delay | -nofast_path_delay
er
nt
Hold-time path delay can use Basic-Scan and/or Fast-Sequential ATPG engines.
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Path Delay ATPG : Setup Check
 Fault launched from a start point and

captured at an end point
 Failure if the transition of data at D of
ng
capture flop is too late
ni
 Separate launch and capture pulses
ai
 Setup Violation
Tr
ip
ch
ro
ic
11- 7
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Path Delay ATPG : Hold Check
 Clock reaching the flops at different

time due to skew
 Change in launch flop disturbs the data
ng
of capture flop in same clock pulse
ni
 Failure if the transition of data at D of
ai
capture flop is too early
Tr
 Same launch and capture pulse for a
given clock
ip
 Paths between different clock domains are
ch
rejected as ATPG Untestable
ro
 Hold Violation
ic
11- 8
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Hold Time Path Delay Flow Details
 Timing for Stuck-At ATPG is used (i.e., test does not need to be run
At-Speed)
 Hold-time violations are both launched and captured by a single clock pulse
ng
 Basic-Scan and Fast-Sequential engines are supported
ni
 Stuck-At patterns detect many hold time violations
ai
 Fault simulate hold time faults using Stuck-At patterns before running Hold-
Tr
Time ATPG
ip
ch
ro
ic
11- 9
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
ATPG Script Examples
 Path Delay script  Hold-Time ATPG script with Stuck-At

pattern fault grading
read_netlist lib.v –lib read_netlist lib.v –lib
ng
read_netlist test.v read_netlist test.v
run_build_model –model top run_build_model –model top
add_pi_constraints 0 scan_en add_pi_constraints 0 scan_en
ni
read_sdc timing_exceptions.sdc set_drc test.spf
ai
set_drc test.spf run_drc
run_drc set_faults –model hold_time
Tr
set_faults –model path_delay add_delay_paths path.txt; // Written with –delay_type min
add_delay_paths path.txt add_faults –all
ip
add_faults -all set_patterns –external stuck_at_pats.bin
set_atpg –capture_cycles 4 run_simulation
ch
run_atpg –auto run_fault_sim; // Fault sim Stuck-At pats for hold_time
write_patterns path_delay_pats.stil –format stil -replace set_patterns -internal
ro
run_atpg –auto
write_patterns hold_time_pats.stil –format stil –replace
ic
11- 10
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Path Delay Hold Time ATPG Script
 Hold-Time ATPG script with Stuck-At pattern fault grading

read_netlist lib.v –lib
read_netlist test.v
ng
run_build_model –model top
ni
set_drc test.spf
run_drc
ai
set_faults –model hold_time
Tr
add_delay_paths path.txt ; // Written from PT with –delay_type min
add_faults –all
set_patterns –external stuck_at_pats.bin
ip
run_simulation
ch
run_fault_sim ; // Fault simulate Stuck-At patterns for hold_time
set_patterns -internal
ro
run_atpg –auto
write_patterns hold_time_pats.stil –format stil –replace
ic
11- 11
lM
na
Note : Since hold_time path delay ATPG is supported only by basic and fast-sequential engine there
is no requirement for switching off the full-sequential engine.
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Managing Faults
 Read the Paths file

add_delay_paths <path_file>
 Add Paths to be targeted for ATPG
ng
add_faults -all
set_delay -relative_edge
ni
 Inject both a slow-to-rise and a slow-to-fall fault
ai
 Need to set this option before add_delay_paths
Tr
 Removing faults
remove_delay_paths
ip
 Report faults
ch
report_delay_paths
-verbose option includes information regarding launch and capture clocks and
ro

nodes, transition direction of faults, fault status and the vector in which detection took
place (Post ATPG)
ic
11- 12
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Path File
 Path File
 ASCII file
 Contains the list of paths to be targeted for ATPG
ng
 Source of Path File
ni
 Use static timing analysis tool
ai
 PrimeTime
Tr
 Create manually (not the preferred method)
 Paths
ip
Same paths as in STA
ch

 Paths for ATPG
ro
 Critical paths (sensitive to delay)
ic
 Paths from different locations of the chip
11- 13
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Path Syntax
$path {
[ $name path_name ; ]
[ $cycle required_time ; ]
[ $slack slack_time ; ]
[ $launch clock_name ; ]
ng
[ $capture clock_name ; ]
$transition {
ni
pin_name1 ^ | v | = | ! ;
ai
pin_name2 ^ | v | = | ! ;
…
Tr
pin_nameN ^ | v | = | ! ;
}
ip
[ $condition {
pin_name1 0 | 1 | Z | 00 | 11 | ZZ | ^ | v ;
ch
pin_name2 0 | 1 | Z | 00 | 11 | ZZ | ^ | v ;
…
ro
pin_nameN 0 | 1 | Z | 00 | 11 | ZZ | ^ | v ; }
]
ic
} 11- 14
lM
na
$name - Assigns a name to the delay path
$cycle - Time between launch and capture clock edges
er
$slack - Available time margin between the $cycle time and calculated delay of the path
nt
$launch - Launch clock primary input to be used

rI
$capture - Capture clock primary input to be used

$transition - (Required) Describes the expected transitions from the path startpoint through
Fo
output pins of path cells and to the path endpoint

$condition - Allows the user to add more constraint for testing the associated path. The
se
$condition statement is not included automatically from PrimeTime, but it can be added manually.
U
V - falling transition
ed
^ - rising transition
= - transition same as previous node
ct
! - transition inverted with respect to previous node

tri
0 - node must be set to "0" during V2

1 - node must be set to "1" during V2
es
Z - node must be set to "Z" during V2

00 - node must be set to "0" during V1 and remain during V2
R
11 - node must be set to "1" during V1 and remain during V2

ZZ - node must be set to “Z" during V1 and remain during V2
TetraMAX Workshop
Path Example
$path {
$name qdsp_aclk_2 ;
$cycle 40 ;
$slack 0.80 ;
ng
$launch TCK ; // (rise edge)
$capture TCK ; // (rise edge)
ni
$transition {
ai
QdbxIc/Qdsp4Core/AluIc2/U806/a v ; // (nor1)
Tr
QdbxIc/Qdsp4Core/AluIc2/U850/b ^ ; // (nd2)
QdbxIc/Qdsp4Core/AluIc2/U598/a v ; // (inv)
ip
QdbxIc/Qdsp4Core/AluIc2/U893/a v ; // (xor2)
QdbxIc/Qdsp4Core/AluIc2/AdderIc/sela ^ ; // (mux2)
ch
}
ro
$condition {
QdbxIc/Qdsp4Core/AluIc1/U702/b 1 ;
ic
} 11- 15
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Untestable Paths
 Some paths cannot be targeted by Path Delay ATPG

 Paths that require multiple launch or capture events
 Paths through RAMs or ROMs or any sequential element
ng
 Other paths may be determined to be “Untestable” or “Undetectable”
ni
 A combinational or sequential false path
ai
 Paths blocked by ATPG constraints
Tr
 Paths including redundant logic
 Paths only valid in shift mode
ip
 Report untestable or violated Paths
ch
 Check P Rule violations and their description in On-Line Help
ro
 report_faults –class AU
ic
11- 16
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
On Path Vs. Off Path Inputs
 On Path Input
 An input to a combinational gate along the circuit delay path through which a logic
transition will flow. On-path inputs are typically listed as nodes in the Path Delay
definition file
ng
 Off Path Input
ni
 An input to a combinational gate that must be sensitized to allow a transition to
flow along the circuit delay path
ai
 Off path input should settle to non-controlling values (‘0’ for OR/NOR, ‘1’ for
Tr
AND/NAND) following application of the launch pulse (V2)
ip
D Q D Q
SI SI
ch
F1 F1
SE U0 U0 SE
ro
Off Path Input
ic
On Path Input
11- 17
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Hazards Can Impact Path Delay Tests
 A hazard is a circuit condition where off-path inputs change when they

are supposed to remain constant
 Static Hazard: Off-path value changes momentarily
ng
 Dynamic Hazard: Off-path value changes multiple times
ni
 Hazards may invalidate a test pattern
ai
Increasing delay fault size
Tr
Fault Free
Fault Detected
ip
U0
Test Invalidated
ch
Fault Detected
ro
V2@ t1 t2
V2 @ t1 Output sample time t2
ic
11- 18
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Hazard-Free Path Delay Test Example
G2
C
D
1 D
A G1 G4
F
1 C 1/1 1/1 1
G3 E
ng
B
0/0 1
F
ni
E
0 1 2 3 4
All off path Tested Path: STR -> ADF
ai
inputs do AB = (00), (10) is a hazard free test for path ADF
not change
Tr
ip
 Off-path inputs are stable and hazard-free throughout the test interval
ch
 This is useful for diagnostics
ro
ic
11- 19
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Robust Path Delay Test
 When on-path nodes control the first occurrence of a transition

through all gates along the tested path
 Guarantees to produce an incorrect value at the output if the delay of
ng
the path exceeds the clock period, irrespective of other path delays
ni
Required Off-Path Input Values (AND gate)
ai
(01) (01)
On-path input
Tr
On-path
Delay Test Model
Off-path
rising falling
ip
0 in V1 Robust (DR) X1 S1
ch
1 in V2
ro
X1: initial state is “don’t care”; final state is 1
ic
S1: steady 1 state 11- 20
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Robust Path Delay Test Example
First Transition
G2
C
D
1/0/1
3
A G1 G4 D
F
C 1/0/1/0
1 1 E
G3
ng
B
1/1 1 F
ni
E
0 1 2 3 4 5
Tested Path: STF -> ACEF
ai
AB = (01), (11) is a robust test for path ACEF
Tr
 F will not change state until the transition on E has occurred, any delay
to D can never mask a delay fault that may occur on the tested path
ip
 If a test passes, then the path is not defective
ch
 If the test fails, the path may or may not be defective – depending on
ro
delay of the off path input values
ic
11- 21
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Non-Robust Path Delay Tests
 This allow the output to change before the on-path transition propagates
along the tested path
Guarantees the detection of a path-delay fault only when no other path
ng

delay fault is present on off paths
ni
ai
(01) (01) Required Off-Path Input Values (AND gate)
Tr
On-path On-path input
Off-path Delay Test Model
rising falling
ip
0 in V1
ch
1 in V2
Non-Robust (DS) X1 X1
ro
X1: initial state is “don’t care”; final state is 1
ic
11- 22
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Non-Robust Path Delay Test Example
Assume X takes 2 A
additional time G2
units beyond A to X D 1/0/1 X
switch 1
A G1 G4
F
C C
1 1
G3 D
ng
B
A STF fault for
gate G3, adding 1/1 1
E
an additional E
ni
time unit
ai
Tested Path: STR -> ACEF F
Tr
strobe
0 1 2 3 4
ip
AB = (11), (01) is a non-robust test for path ACEF
ch
 The pattern would pass even though there is a STF of 1 time unit at G3
ro
 If there is no defect at X, then it would fail
ic
11- 23
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Summary of Path Delay Fault Detections
 A Path Delay Fault can have three main types of detection:

 Hazard-Free Detected Robustly
 Guarantees that the test will fail if there’s a sufficient delay on the target path
ng
independent of delays on other paths and also independent of hazards
Detected Robustly
ni

Guarantees that the test will fail if there’s a sufficient delay on the target path
ai

independent of delays on other paths
Tr
 Detected Non-Robustly
 Guarantees that the test will fail if there’s a sufficient delay on the target path only if
ip
there are no delays on the off-paths
ch
ro
ic
11- 24
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Characterization Tests
 Generate single path sensitization tests that have unambiguous

diagnostic results to target a Hazard-Free Robust test
 Use following command to enable the characterization pattern
ng
generation
ni
 set_delay –diagnostic_propagation
ai
 Default is –nodiagnostic_propagation
Tr
 The pattern would fail only if the target path has a defect; it is not
affected by delay on any other path in the chip
ip
 Coverage may drop due to more stringent ATPG constraints
ch
ro
ic
11- 25
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Fault Classification
 Characterization Test (–diagnostic_propagation)

 DR: Fault detected and Hazard Free Robust test
ng
 DS: Fault detected Robustly but not Hazard free test
ni
 Regular Test (Default)
ai
 DR: Fault detected and Robust test
Tr
 DS: Fault detected and Non Robust test
ip
ch
ro
ic
11- 26
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Launch Cycle
 If Fast-Sequential Path Delay is used (default), the launch cycle will be

system clock launch for all Fast-Sequential Path Delay patterns
 The launch_cycle setting has no effect on Full-Sequential Path Delay;
ng
any launch type can be used
ni
 Last Shift Launch
ai
 Extra Shift Launch
Tr
 System Clock Launch
 However, to generate only system clock launch patterns with Full-
ip
Sequential Path Delay, constrain Scan Enable to its inactive state
ch
ro
ic
11- 27
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Simulating Hazards
 On-path transition from non-dominating to dominating value

 No possibility of glitch on off-path: Robust Test
 Possibility of glitch on off-path: Non-Robust Test
ng
 Check for glitch on the off path input
 set_delay –simulate_hazards
ni
 Classify a test as DR if there is no glitch possible
ai
 Default Option
Tr
 Do not check for glitch on the off-path input
 set_delay –nosimulate_hazards
ip
 May classify a Non Robust test as Robust
ch
ro
ic
11- 28
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Reconvergent Path
 Paths that branch apart and then come back together

 Marked as AU if V2 of off_path input blocks the propagation.
ng
 To allow test generation to occur
 set_delay -allow_reconverging_paths
ni
ai
Tr
ip
ch
ro
* STF on above path is AU if we don’t allow reconverging paths
ic
11- 29
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Multi-Cycle Paths
 Some paths need more than single cycle for a valid capture
 Multi-Cycle paths can also be tested with modifications to the timing in
the SPF file
ng
 Paths that are not targeted for the specified frequency need to be
ni
masked
ai
 Timing exceptions (SDC)
Tr
 set_delay –mask_nontarget_paths
ip
ch
ro
ic
11- 30
lM
na
For DFTMAX designs in compression mode, don’t use set_delay –
mask_nontarget_paths as it may inhibit effective pattern generation due to the large number
er
of X’s created by the masks.

nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Multi-Cycle ATPG Flow
 In a design with 1-cycle and 2-cycle paths, test the path delay faults in
two runs
 1st run, targets 1-cycle faults
ng
 Setup the clock to work at-speed (e.g. 10ns period)
 Remove paths longer than one cycle
ni
remove_delay_paths -max_cycle 10
ai
 Generate and save test vectors
Tr
 2nd run, targets 2-cycles faults
ip
 Remove timing exceptions for 2-cycle paths
ch
 Setup the clock to work at a multi-cycle period (e.g. 20ns)
 Remove paths less than two cycles
ro
remove_delay_paths -min_cycle 20
ic
 Generate and save test vectors 11- 31
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Analyze Fault
 Analyze UD or AU faults
analyze_faults <delay_path_name> -slow <r|f>
Can also be used for detected faults to see the pattern sequence
ng

 Analysis steps
ni
 Generate the values necessary to launch the transition at the head of the selected
ai
path
Tr
 Generate the values necessary to capture the transition at the tail of the path
Generate the values necessary to propagate the transition through the non-
ip

launch and non-capture nodes in the path till it reaches the capture point
ch
 Report success of each step unless it fails at some point
ro
ic
11- 32
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Analysis Report
 Full Sequential Analysis performed for a Path Delay fault

Non-robust path sensitization unsuccessful ...
Test generation of LAUNCH DFF 15 @ frame 1 (cycle 0, frame 1) successful ...
Test generation of LAUNCH DFF 15 @ frame 1 (cycle 0, frame 1) and CAPTURE
ng
DFF 14 @ @ frame 3 (cycle 1, frame 0) successful ...
Test generation to OR 10 ( OFF-PATH input AND 9) successful ...
ni
Test generation to MUX 12 ( OFF-PATH input PI 2) successful ...
Test generation to AND 11 ( OFF-PATH input PI 1) unsuccessful ...
ai
Analyzing conflict data ...
Tr
3 conflicting requirements found :
1. PI 1 required @ 1
2. AND 9 required @ 0
ip
3. DFF 15 required @ 1
The gate_report data is now set to "seq_sim_data"
ch
 Use the –verbose option of analyze_faults command for more details
ro
 Use the –display option of analyze_faults command to see the
simulated values of the entire path in the GSV
ic
11- 33
lM
na
A frame is a time division within a clock cycle.
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
GSV Debug of Delay Path Violations
analyze_faults PATH_1 -slow f -display
ng
ni
 Open expansion diamonds on inputs of displayed on-path cells to
display the off-path cells
ai
Tr
 See that at least one off-path cell is shown with a value opposite of the
required value
ip
 There are typically paths between these conflicting requirement cells
ch
 Gate IDs reported in “Analyzing conflict data ...” can be added to the
GSV with:
ro
 Show  Path, head=gateid, tail=gateid
ic
11- 34
lM
na
The GUI here shows a part of the Path for which the fault analysis is being done. The pin
data shown is the simulated values of the pattern, that is being used to detect the fault.
er
nt
The schematic show all the gates along the On-Path of the path. Off_path inputs are not
rI
shown , they can be expanded as needed.

Fo
Since it is a STR analysis, you can see that there is a rising transition on the first clock
cycle ( Launch) on the Q pin of the flop . ( Start Point of the path)
se
Analysis tips:
U
• Specify set_delay –noallow_reconverging_paths. Reconverging paths can

ed
cause some confusing feedback when a fault isn’t testable.

• Use –verbose option
ct
• Use –fault_simulation option. Provides the fault simulator’s opinion as well as the
tri
test generator’s.
• Check which type of path sensitization (if any) is reported as successful
es
Strong non-robust  candidate for a robust test

Weak non-robust  failed in search for a robust test
R
TetraMAX Workshop

 Extract a set of critical paths from PrimeTime
ng
 Describe the syntax of a delay path
Run ATPG for the Path Delay fault model
ni

ai
 Describe the Robust and Non-Robust faults
classification
Tr
 Analyze a Path Delay fault
ip
ch
Begin Lab 11: Path Delay ATPG
ro
ic
11- 35
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
write_delay_paths Write critical delay paths in PrimeTime
set_faults –model path_delay Set the path delay fault model
set_faults –model hold_time Set the hold time fault model
set_atpg –fast_path_delay Use Fast-Sequential ATPG for path delay testing
ng
add_delay_paths <file> Read delay paths file generated in PrimeTime
remove_delay_paths Remove previously added delay paths
ni
report_delay_paths Report current delay paths
set_delay –relative_edge Add both str and stf faults for a single delay path
ai
set_delay –diagnosic_prop Restrict path delay ATPG to only robust tests
Tr
set_delay –simulate_hazards Simulate hazards to determine if test is robust
set_delay – Allow reconvergent off path values
ip
allow_reconverging_paths
ch
set_delay –robust_fill Fill non care bits with values to make test robust
set_delay –mask_nontarget_path Mask all scan cells besides the path endpoints
ro
ic
11- 36
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
TetraMAX Workshop
Agenda
DAY
3
ng
ni
ai
Tr
ip
12 Diagnosis
ch
ro
13 Conclusion
ic
12- 1
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Diagnosis ©2018 Synopsys, Inc. All Rights Reserved. 12-1

TetraMAX Workshop
Unit Objectives
ng
 List the 2 main command used in TetraMAX diagnosis flows
ni
 Describe the difference between pattern-based and cycle-
ai
based Fail Data File formats
Tr
 Understand how to interpret the TetraMAX diagnosis results
ip
ch
ro
ic
12- 2
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Purpose of Failure Diagnosis
 Volume diagnostics
 Diagnose large numbers of parts
 In cooperation with YMS, identify yield killers
ng
 Accurate diagnostics
ni
 Run a few parts with a large amount of failure data
ai
 Intensive analysis done with specialized commands to ensure high confidence of
Tr
results
 Typically done to locate a failure location in preparation for physical failure
ip
analysis (PFA)
ch
 Help with debug of simulation failures
ro
ic
12- 3
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Yield Enhancement Process
 Diagnosis is essential part of yield enhancement process

 Diagnostic results (logical and physical) fed into a Yield Management
System (YMS)
ng
 Large volumes of device data are analyzed to identify common causes
ni
of yield loss
ai
 Detailed analysis / diagnosis can be performed on a representative
Tr
device to understand the failure mechanism
ip
 Corrective action taken on design, library cell, process and / or reticle
ch
ro
ic
12- 4
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
High Level View
Design Flow Process Flow Yield
Design YMS
Process
ng
Library Development Diagnosis
Development Results
ni
Mask
ai
Netlist
Gen Fab
TetraMAX
Tr
Library Diagnosis
ip
Failure
ch
TetraMAX Patterns Log
ATPG
ro
ATE
ic
12- 5
lM
na
Yield is affected by the physical design, library, mask generation or the fab process.
er
Synopsys offer two YMS related products:

nt
Odyssey – Manufacturing-centric YMS

rI
Yield Explorer – Design-centric YMS

Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Volume Diagnostics Flow
Scan Test Patterns
./sa_pat.stil …
./td_pat.stil
ng
Lot 1 Lot 2
ni
1 pad[1] 342 (exp=1, got=0) Failure logs files
ai
3 pad[4] 935 (exp=0, got=1)
…
Tr
ip
YDF
ch
Diagnose
Design
and save
Image
ro
TetraMAX fault candidates Yield Explorer
ic
12- 6
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
TetraMAX Diagnosis
 When a device fails testing, TetraMAX Diagnosis can be used to

determine the location of the failure
 To accomplish this, failure information from the ATE or simulation is put
ng
into a file (following a specified format) and diagnosis is run with the
ni
run_diagnosis command
ai
 TetraMAX analyzes the failure information and reports the locations and
Tr
types of faults that could have caused the failure
ip
ch
ro
ic
12- 7
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
TetraMAX Diagnosis Features
 Accuracy: pinpoints defect location in functional logic or on a scan

chain
 Diagnosis results have high accuracy if the fault(s) associated with the physical
ng
defect is in the resulting candidate fault list
ni
 Precision: uses failing and passing patterns
ai
 Diagnosis results have high precision if the resulting set of candidate faults is
small
Tr
 High performance, scan-based fault simulation
ip
 Supports Physical diagnosis with a PHDS database
ch
 Ease-of-Use
ro
 Text reporting, Tcl API, and graphical results
ic
12- 8
lM
na
Definitions
er
Physical Defect: A physical condition on a manufactured chip which causes it to not meet design
specifications.
nt
Fault: A logical representation of a defect, simplified to facilitate modeling in software.

Fault simulation: simulating the effect of faults in software.
rI
Fault Candidate: a fault which potentially explains the behavior of a physical defect on the device
Fo
under test.
Pattern: an ATPG sequence possibly consisting of shifting and capturing values into the scan chain.
Consists of many clock cycles.
se
Vector/Cycle: A cycle on ATE where stimulus is applied and/or the response is measured.
Failure: A mismatch on ATE where the DUT does not produce an expected result at a primary
U
output (PO) or a scan cell.

Failing Pattern: A pattern with at least one failure.
ed
ct
tri
es
R

TetraMAX Workshop
TetraMAX Diagnosis Flow
Verilog Library
TetraMAX ATPG
• Compile Design
Scan Design • Run design rule check
Netlist • Run ATPG
ng
Test Protocol
(STIL format) Simulation Coverage
ni
ATE Vectors
Test Patterns Reports
Binary Image
ai
ATE Tester
Tr
• Tester failure data log
• Data log post process
Failure Data File
ip
TetraMAX ATPG
ch
• Run diagnosis
ro
Failure Analysis
ic
• Perform failure analysis
12- 9
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Requirements For Diagnosis
 Test Patterns (Stuck-At, Transition or Bridging)

 Recommended formats: Binary and STIL/WGL
Failure Data File from the ATE (pattern-based or cycle-based)
ng

 Must use exactly the same TetraMAX environment that generated test
ni
patterns
ai
 Original Verilog netlist
Tr
 Original test protocol file (.spf)
Original libraries
ip

Tip: Write out an image file after DRC in the final run and use this image file for diagnosis to
ch
ensure the same environment
ro
ic
12- 10
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Diagnosis Commands
Diagnosis is primarily controlled using two commands:

 set_diagnosis
ng
 Specifies diagnosis options that will be persistent across multiple diagnosis runs
 run_diagnosis
ni
Executes the diagnosis
ai

Tr
read_netlist -lib mylib.v
read_netlist mydesign.v
ip
run_build_model
ch
set_drc mydesign.spf
run_drc
ro
set_patterns -external ./patterns/mypat.bin
run_diagnosis diag.fail
ic
12- 11
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Diagnosis Flow Using Binary Image
Binary File Saved During Pattern Generation
ng
Read Image
ni
ai
Patterns Run Diagnosis Failure
file file
Tr
ip
Transcript
+
ch
Schematic
ro
ic
12- 12
lM
na
Note that the patterns are not part of the binary image file. They need to be read into TetraMAX
separately.
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Advantages of Binary Image File
 File management is simplified

 Encapsulates design netlists, libraries and SPF files
 Simplifies data transfer when Diagnosis is performed by a different group than
ng
ATPG (i.e. a foundry)
ni
 Faster performance
ai
 No need to re-run build and DRC steps
Tr
 Instance names can be “garbled” to provide an extra layer of security
by hiding the design context
ip
# Read the image
ch
read_image design_img.gz
set_patterns -external patterns.bin
ro
run_diagnosis fail_log.txt –display
ic
12- 13
lM
na
Note: To create a “garbled” image file, the image is written with the following command:
er
write_image design_garb_img.gz –garble

nt
rI
To translate a garbled name back to the original name:

• Read the original design database or ungarbled image file
Fo
read_netlist specnetlist.v
• Run Build (if an image wasn’t read)
se
run_build_model ...
• Perform design rule checking (if an image wasn’t read)
U
run_drc ...
ed
• Supply the garbled name as argument to get ungarbled name in output.

report_instances u43259 -ungarble
ct
tri
es
R

TetraMAX Workshop
Secure Image
 Image file can be password protected

 Proprietary, undocumented encryption scheme
 Stronger protection of IP
ng
 Image creator can specify which TetraMAX commands the image
ni
receiver is allowed to execute
ai
 Image file can only be read with the private password
Tr
 After read_image of a secure image file, receiver is limited to only the
commands explicitly allowed
ip
e.g. report_primitives, GSV, etc. can be permanently disabled
ch

 Note: Tcl API commands are disabled after a secure image file is read
ro
ic
12- 14
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Secure Image Commands
 set_commands [-secure <command>]

[-nosecure <command | -all>]
 Allows the specified command along with all its options in the subsequently
written secure image
ng
 report_commands -secure
ni
 Lists all allowed commands that can be applied to the image file to be written
ai
 write_image <file_name> -password <string>
Tr
 Writes an encrypted image which only allows execution of commands listed by
report_commands –secure
ip
ch
 read_image <file_name> -password <string>
 Reads a secure image unencrypted by the given password
ro
 TetraMAX will allow only permitted commands to be run
ic
12- 15
lM
na
Instance names can be “garbled” to provide an extra layer of security by hiding the design context:
write_image -garble
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Sample Scripts With Secure Image
# Creating secure image

set_commands -secure help
set_commands -secure run_diagnosis
ng
set_commands -secure set_diagnosis
ni
set_commands -secure set_patterns
ai
write_image image_enc.gz -password top_secret \
-schematic_view –replace
Tr
# Reading secure image
ip
read_image image_enc.gz -password top_secret
ch
set_patterns -external pat.bin
ro
run_diagnosis fail.log
ic
12- 16
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Tester Failure Data File
 Captures the ATE results of a failing device

 Two formats
Pattern-based failures, in terms of failing patterns
ng

 Format used internally in TetraMAX
ni
 Cycle-based failures, in terms of failing vectors
ai
 Most ATE vendor testers can generate TetraMAX pattern-based failure
Tr
files automatically
 Partnership with most major ATE vendors
ip
 Avoids complexity in translating failure file
ch
 Contact the ATE vendor for details on generating failure files that are formatted for
ro
TetraMAX
ic
12- 17
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Pattern-based Failure Data Format
 TetraMAX expects the following fields per

line:
# Pattern Output Cell
 1. Failed ATPG pattern number
ng
50 vout 55
 Pattern 0 is first pattern - usually the chain test 50 abus 57
ni
 2. Device output which mismatched 58 vout 57
ai
83 xstrb
 Can be output pin name or chain name
Tr
 3. Failed scan cell position # + expected values
ip
 If Device output is a scan chain output, and the 94 vout 5 1
pattern performs a chain unload operation
ch
97 xstrb 0
 Position 0 is closest to scan-out pin
ro
 4. Optional expected data
ic
12- 18
lM
na
The vout and abus ports are Scan Outputs.
er
The xstrb port is regular functional output.

nt
rI
TetraMAX Online Help

Contents  Fundamental Concepts  Understanding Failure Data Format
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Cycle-based Failure Data Format
 TetraMAX expects the following field per

line:
# C Output Cycle
 1. “C”
ng
C vout 2764
 Indicates this failure log is cycle-based C abus 2940
ni
 2. Device output which mismatched C vout 3048
ai
C xstrb 3785
 3. Cycle number that failed
Tr
 Indicates vector number that failed, with first # + expected values
vector being number 1
ip
C vout 4212 1
ch
C xstrb 4908 0
 4. Optional expected data
ro
ic
12- 19
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Checking Expected Data in Failure Data File
 In some Diagnosis flows, custom scripts are used to convert failing tester
data to a TetraMAX failure log
 These translation scripts can be prone to error
ng
 If expected data exists in the Fail Data File, by default, TetraMAX will check
that the expected data is consistent with the data in the ATPG patterns
ni
 If a cycle-based fail file is used, any difference in the number of cycles on
ai
the ATE must be accounted for
Tr
set_diagnosis <file> … -cycle_offset <d>
ip
 If cycle numbers start at 0 on ATE, use “1” as the offset
If extra initialization cycles exist in vectors run on the tester, use a negative integer
ch

as the offset
ro
 If the offset is unknown, a range of offsets can be tested
run_diagnosis –find_offset {<begin_range> <end_range>}
ic
12- 20
lM
na
The set_diagnosis [-check_expected_data | -nocheck_expected_data]
controls if expected data is checked. It’s on by default.
er
nt
Note: the –find_offset option requires that the failure log contain expected values and there
rI
must be at least 10 failures in the failure log.

Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Truncated Failure Data File
 ATE limitations may force a user to generate a truncated failure log file
 Only use the first N patterns for diagnosis
run_diagnosis –truncate <N>
ng
 Set the ATE fail memory limit (d = number of failures)
ni
set_diagnosis –failure_memory_limit <d>
ai
 Set the ATE failing cycles limit (n = number of failing cycles)
Tr
set_diagnosis –failing_cycles_limit <n>
ip
 Assume last failing pattern is incomplete and ignore it
ch
set_diagnosis –incomplete
12 Out1 23
ro
ATE memory limit 15 Out2 56
ic
15 Out2 78 truncate here
15 Out2 12- 21
lM 98
na
If last failure was captured for pattern P, generally, it’s safer to truncate to pattern P-1 because we
can’t be sure if all the failures for pattern P was captured.
er
nt
If there are many failures for the first failing pattern, we may not be able to diagnose that device
rI
with the given pattern order because we cannot be sure if we have full failure information for the
pattern.
Fo
Failing patterns from the middle cannot be eliminated – only truncated from the end.
se
U
ed
ct
tri
es
R

TetraMAX Workshop
TetraMAX Diagnosis Engines
 Two primary algorithms

 Functional diagnosis
 For physical defects in functional logic
ng
run_diagnosis …
ni
 Chain diagnosis
ai
 Faults that affect chain shifting
run_diagnosis … –chain_failure
Tr
 The proper diagnosis engine is automatically selected based on the
ip
status of the chain test
ch
 Automatic selection controlled by:
set_diagnosis [-auto | -noauto]
ro
 If the chain test pattern failed, then chain diagnosis is run
ic
12- 22
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Functional Logic Diagnosis
 For Basic-Scan and Fast-Sequential patterns

 Can be used for all pattern types, except IDDQ and Full-Sequential
Finds stuck-at faults that explain the behavior of the silicon
ng

 Most physical defects behave as one or more Stuck-At faults when considering
ni
an individual failing vector
ai
Tr
ip
ch
ro
ic
12- 23
lM
na
Currently, there is no Diagnosis support for Full-Sequential or functional patterns.
er
Functional diagnosis assumes that the chain shifting is functional.

nt
rI
Note: The diagnosis engine does not make any assumptions on the nature of the defect based on the
type of fault tested. This means, for example, that any failures collected while running transition
Fo
patterns could lead the diagnosis engine to find the Stuck-At fault type. Nevertheless, it is possible
to specify the logic diagnosis engine to search by preference for a defect of the delay type by using
se
-delay_type option of the set_diagnosis command

U
ed
ct
tri
es
R

TetraMAX Workshop
Chain Diagnosis Overview
 Use first pattern to test for scan chain integrity

 Typically a chain test pattern - only shifts – no capture
Failures on the first pattern can indicate type of chain defect
ng

 Stuck-at fault, delay fault, hold-time issue
ni
 Uses all patterns to diagnose chain failure
ai
 Includes patterns that capture values
Tr
 Accuracy improves with data from more failing patterns
ip
 Recommend at least 10
ch
 Usage:
ro
set_diagnosis –auto
run_diagnosis <failure_file> –chain_failure
ic
12- 24
lM
na
Chain diagnosis assumes that the functional logic is defect free. If this assumption is not true, the
diagnosis results can be misleading.
er
The chain test can indicate the defect type. For example, if 0011 is used, a fast-to-rise defect might
nt
change the output to look like 0111…

rI
What is a proper chain test?

Fo
There should be no capture clock: a proper chain test is a pattern without clock capture cycle (or
pulse clock in TetraMAX terminology) after a measure PO.
se
A proper chain test is a pattern with at least all of the following transitions:
U
0->0, 0->1, 1->0, 1->1

ed
There can be more complex chain tests that the user can specify with set_atpg. By default, the
ct
chain test is generated as the 1st pattern. see the set_atpg command options.
tri
If chain test is not failing during the shift operation, the chain diagnosis will not help. Therefore the
es
traditional functional analysis is used.

R

TetraMAX Workshop
Chain Diagnosis Principle
 Assume a Stuck-At defect for simplicity

 Scan cells upstream will drive valid values to functional logic, but
appear stuck-at when unloaded
ng
 Scan cells downstream will drive invalid values to functional logic, but
ni
may capture valid values that can be observed
ai
 Algorithm uses these
Tr
observations to
diagnose scan chain ?
ip
1 or 0 X
D D
physical defects Q Q
ch
SI SI
Stuck at 1/0
ro
Controllable but unobservable Uncontrollable(?) but observable
ic
12- 25
lM
na
If the first pattern is not chain test, a much lower accuracy algorithm that supports only stuck-at
chain defects will be used. It is strongly recommended that the first pattern be the chain test.
er
nt
Example of why there’s uncertainty in diagnosing chain defects.

rI
Given the following chain order with groups of flops G1, G2 and G3, and a fault location as
follows:
Fo
G1, fault, G2, G3

se
When shifting in, flops G2 & G3 have unknown values. When shifting out, flop G1 and upstream
flops will have a fixed value, based on the stuck-at value of the fault. TetraMAX looks at the flops
U
with the fixed values in determining the fault location.

ed
If the functional logic fed by G3 outputs to G2, the G2 flops will have fixed values after capture.
ct
Therefore, we'll see G1 and G2 with fixed values. TetraMAX will say the fault is at the output of
tri
G2, instead of the real location further upstream.

es
R

TetraMAX Workshop
Chain Diagnosis Output
 Defects are simulated, compared with tester results and assigned a
score based on how well they match
 Best candidates are shown with match scores
ng
 Examine identified scan cell, and the scan cells before and after it,
along with the connecting nets
ni
fail.log scan chain diagnosis results: #failing_patterns=79
ai
-----------------------------------------------------------
defect type=fast-to-rise
Tr
match=100% chain=c0 position=178 master=CORE/c_rg0 (46)
match=100% chain=c0 position=179 master=CORE/c_rg2 (57)
match= 98% chain=c0 position=180 master=CORE/c_rg6 (54)
ip
defect type: type of defect
CORE/c_rg2 CORE/c_rg0
ch
match: how well simulated defect matches failure log file 179 178
chain: chain name D D
ro
Q Q
position: scan cell location in chain where position 0 is SI SI
ic
closest to the scan-out pin
master: scan cell instance name 12- 26
lM
na
No GSV for chain diagnosis.
er
Chain Diagnosis Tips:

nt
rI
Follow-up only high confidence results

Low number of fault candidates returned
Fo
Match score higher than 80%

se
If too many candidates (low precision)

Capture more failing pattern data
U
Try Fast-Sequential patterns with large number of capture cycles

ed
Add a set/reset test to the pattern set with set_atpg –add_setreset_test

For DFTMAX designs with high X-tolerance, generate xtol chain tests with the set_atpg
ct
–xtol_chain_test command. See the man page for usage details.

tri
es
R

TetraMAX Workshop
Sample Output: Diagnosis Summary
Failure log file used Failures summary

TEST-T> run_diagnosis test.fail -display
Diagnosis summary for failure file test.fail
ng
#failing_pat=2, #failures=2, #defects=1, #faults=1, CPU_time=0.00
Simulated : #failing_pat=2, #passing_pat=4 #failures=2
ni
------------------------------------------------------------------------
ai
Defect 1: stuck fault model, #faults=1, #failing_pat=2, #passing_pat=4,
#failures=2
Tr
------------------------------------------------------------------------
match=100.00%, #explained patterns: <failing=2, passing=4>
ip
sa1 DS i1/out (NOT)
sa0 -- i1/in (NOT) Simulation information
ch
sa1 -- f3/d (SDFF)
ro
------------------------------------------------------------------------
ic
12- 27
lM
na
Note: All information displayed in the report are accessible through
a Tcl API - useful for script automation and volume diagnostics
er
nt
#failing_patterns
rI
This indicates the total number of failing patterns in the failure file. A pattern is assumed to include
both a measure of all POs and an unload of the scan chain.
Fo
#failures
In the main header, shows the number of failures in the failure log file. In each defect's header, it
se
shows the number of failures the candidates in that defect caused.

#defects
U
This indicates the number of different defects that appear to be causing the failures.
ed
#faults
Indicates the number of collapsed faults. In the main header, it indicates the total number of faults.
ct
In each defect's header, it shows the number of faults in that defect group.
tri
es
R

TetraMAX Workshop
Sample Output: Fault Candidate
TEST-T> run_diagnosis test.fail -display

Diagnosis summary for failure file test.fail
Simulated : #failing_pat=2, #passing_pat=4 #failures=2
ng
------------------------------------------------------------------------
Defect 1: stuck fault model, #faults=1, #failing_pat=2, #passing_pat=4,
#failures=2
ni
------------------------------------------------------------------------
ai
Tr
sa1 DS i1/out (NOT)
sa0 -- i1/in (NOT) Failing and passing patterns
that are explained by the fault
sa1 -- f3/d (SDFF)
ip
------------------------------------------------------------------------
ch
Cell type The following faults are all equivalent
sa0 sa1 sa1 D
Fault pin pathname
ro
Fault types: sa0, sa1, str, stf, sa01, strf, bDOM, bOR, bAND, bUN
ic
Match score based on how well the fault matches the ATE failures
12- 28
lM
na
Fault types:
er
sa0 – Fault location behaves like a stuck-at 0.

nt
sa1 – Fault location behaves like a stuck-at 1.

rI
str – Fault location behaves like a slow-to-rise.

stf – Fault location behaves like a slow-to-fall.
Fo
sa01 - Fault location behaves like a sa0 on some patterns, and a sa1 on others. This could be a
coupled open or a bridge type defect.
se
strf - Fault location can cause a delay on both rising and falling transitions (slow-to-rise-fall).
bAND or bOR - The defect location behaves as a wired-AND or wired-OR type bridge.
U
bDOM - The defect location behaves as the victim node of a dominant bridge.
ed
bUN - An unknown bridging type relationship exists. It indicates that there is some signal
correlation which does not behave as the well known bridging fault models.
ct
tri
es
R

TetraMAX Workshop
What is the Match Score?
 The match score is based on how well a fault candidate’s failing

behavior matches the failures seen on the tester
 Three components are computed over patterns simulated for each fault
ng
candidate
ni
 By default, all failing patterns and subset of passing patterns are simulated to
ai
compute the match score
For a Simulated Pattern
Tr
Tester Results Simulation of a fault candidate
ip
F TFSF F T = tester
ch
S = simulator
x
F TFSP P F = fail
ro
P = pass
ic
P TPSF F 12- 29
lM
na
TFSF—tester fail, simulator fail
Number of measures that failed on the tester and the fault candidate was detected in the simulator at
er
the same location and pattern.

nt
rI
TFSP—tester fail, simulator pass

Number of measures where the tester failed, but the fault candidate was not detected in the
Fo
simulator at the same location and pattern.

se
TPSF—tester pass, simulator fail

Number of measures where the fault candidate was detected, but the tester measure passed at the
U
same location and pattern.

ed
ct
tri
es
R

TetraMAX Workshop
Computing the Match Score
 Each candidate is assigned a score

 range: 0% - 100%
It’s possible for multiple candidates to get the same score
ng

 Higher match scores indicates higher confidence that the fault
ni
candidate’s location is the same as the defect’s
ai
 Score components can be displayed with
Tr
run_diagnosis –verbose option
ip
match=25.00%, (TFSF=1/TFSP=3/TPSF=0), #perfect/partial match: <failing=1/1, passing=2>
sa1 NO i1/out
sa0 -- i1/I
ch
TFSF
ro
match % = X 100
TFSF + TFSP + TPSF
ic
12- 30
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Terminology: Explaining Patterns
 A fault explains a failed pattern if the fault simulation results

match the ATE failure exactly for that pattern
ng
 Patterns that cannot be explained by any single stuck-at fault
are unexplained
ni
Physical defect detected Fault simulation of fault F1 Fault simulation of fault F2
ai
on ATE by pattern P1 (P1 explained by F1) (P1 unexplained by F2)
Tr
1 1 1
1 1
ip
1
F 0 F 0 F
0
F1
ch
1 1
1 F2
1 F 1 F 1
ro
1 1 1
ic
12- 31
lM
na
“F” indicates a failure (mismatch on the ATE, or fault simulation detection).
er
Fault F1 has identical behavior to the failure on the tester for pattern P1. Therefore, F1 explains
nt
pattern P1.
rI
But F2 had only one matching failure, so it did not match the behavior seen on the tester.
Fo
Therefore, F2 does not explain P1.

se
U
ed
ct
tri
es
R

TetraMAX Workshop
GSV Output
 Use –display option of run_diagnosis
ng
ni
ai
Tr
ip
ch
ro
ic
12- 32
lM
na
The schematic here is in design view, not primitive view
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
N-Detect: Better Precision
 If diagnosis identifies many possible fault locations, using N-Detect

patterns may enhance precision
 Generate multiple patterns that detect the same fault
ng
 Increase confidence of defect location before beginning failure analysis
ni
ai
Tr
ip
ch
ro
ic
12- 33
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
N-Detect Flow Example
run_diagnosis orig_fail.txt \
–write_fault_list flist.txt
read_faults flist.txt
set_atpg -decision random
ng
run_atpg –ndetect 10
write_patterns ndet.stil –format stil
ni
write_patterns ndet.bin –format binary
ai
ndet.stil ndet.bin
Tr
ip
new_fail.txt run_diagnosis new_fail.txt
ch
ro
Better Results
ic
12- 34
lM
na
This flow can be used to gain higher confidence in diagnosis results. The fault candidates in the
diagnosis results can be written out as fault list, read back into tmax for additional pattern
er
generation. The new pattern set can be re-run on the tester. The new failure log file can be re-
nt
diagnosed to see if the fault site remains the same.

rI
N-detect ATPG is recommended for pattern re-generation. Can try different fault models, such as
transition and bridging.
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Physical Data Improves Diagnostics
 Many manufacturing defects have complex

logical behavior
 Short between two wires
ng
 Open in the middle of a long wire
ni
 Diagnostics need layout information to
ai
accurately model these defects
Tr
 Bridging behaviors with adjacent nets
 Open behaviors in branches of high-fanout nets
ip
 Yield analysis and PFA engineers also need
ch
physical location/layer of defect candidates
ro
ic
12- 35
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
High-Capacity Physical Database
 LEF/DEF is loaded once and used by both TetraMAX Diagnostics

TetraMAX and Yield Explorer
 Shared physical database (PHDS)
ng
 Physical data is stored on disk, not in
ni
memory
ai
 No need to partition large designs
LEF/DEF PHDS
Tr
 High-performance access for TetraMAX
physical diagnostics
ip
 Dynamic extraction of adjacent nets and net
ch
branches
ro
Yield Explorer
ic
12- 36
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
PHDS Creation in TetraMAX
# Specify LEF/DEF directories
set_physical_db -lef_dir ./LEF -def_dir ./DEF
# Specify the directory to save the database
set_physical_db -database /home/proj/chipA/PHDS
Data Preparation # Specify the device name and version
ng
set_physical_db -device [list "CHIPA" "1"]
LEF/DEF
# Specify the top level DEF file
set_physical_db -top_def_file chipA.def
ni
Read LEF/DEF & # Read LEF/DEF and create the PHDS database
ai
Create database write_physical_db -replace
Tr
Writing Physical Database...
PHDS LEF input directory : ./LEF
ip
DEF input directory : ./DEF
Top DEF file name : chipA.def
ch
PHDS output directory: /home/john/chipA/PHDS
Device name : CHIPA
ro
Device version : 1
Successfully created Physical Database.
ic
12- 37
lM
na
Note: PHDS may also be created in Yield Explorer
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
PHDS Data Access Process (DAP) Server Setup in TetraMAX
# Specify PHDS database

set_physical_db –database /home/proj/chipA/PHDS
Server Setup # Specify port number where to connect PHDS db
ng
set_physical_db –port_number 9990
DAPListener # Start the job to access the database, the
ni
@9990 # DAPListener
open_physical_db
ai
PHDS
Tr
Starting Data Access Process...
ip
Hostname : server1234
Port Number : 9990
ch
Physical Database Directory: /home/john/proj/PHDS
Successfully started Data Access Process.
ro
ic
12- 38
lM
na
Note: a Data Access Server (DAS) may also be created in Yield Explorer
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
TetraMAX PHDS Usage
# Read image and patterns

Data Usage read_image TOP.logical.img
set_patterns –external TOP.pat
TetraMAX Read Image
Image # Connect to PHDS database
ng
set_physical_db –hostname server1234
Patterns Read Patterns set_physical_db –port_number 9990
ni
set_physical_db –device [list “CHIPA” “1”]
set_physical_db –top_design TOP
ai
Connect PHDS
PHDS
Tr
# Run physical diagnosis and save results
Diagnose run_diagnosis datalog1
Failures
write_ydf TOP.1.ydf –replace
ip
run_diagnosis datalog2
ch
YDF write_ydf TOP.2.ydf –replace
...
ro
run_diagnosis datalog392
write_ydf TOP.392.ydf –replace
ic
12- 39
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Sample Output: Physical Diagnosis Summary
TEST-T> run_diagnosis fail_56.log

Setting top-level physical design name to 'RISC_CHIP'
Check expected data completed: 241 out of 241 failures were checked
Diagnosis summary for failure file fail_56.log
ng
Simulated : #failing_pat=30, #passing_pat=96, #failures=194
-----------------------------------------------
Defect 1: stuck-at fault model, #faults=1, #failing_pat=30, #passing_pat=96, #failures=241
ni
Observable points:
1693 1687 1696 1699 1672 1530 1529
ai
------------------------------------------------
Explained pattern list:
Tr
40 41 47 48 50 51 54 55 58 59 67 69 70 71 72 73 77 78 79 80 85 88
92 93 94 95 97 98 99 101
--------------------------------------------------
Physical Pin Data
ip
sa01 DS I_RISC_CORE/I_ALU/U14/ZN (inv0d1)
Cell Boundary
ch
Pin_data: X=747110 Y=652790, Layer: METAL (38)
Cell_boundary: L=746115 R=747345 B=650175 T=653865 Subnet ID
Subnet_id=4
ro
---------------------------------------------------------------- Performance Data
Total Wall Time = 22.97 sec PHDS Query Time = 22.13 sec
PHDS queries: subnets(added/total)=10/40 bridges(added/total)=28/58
ic
12- 40
lM
na
Pin_data:
• X is the horizontal coordinate of one of the vertices of the pin associated with the location of the fault
er
candidate.
nt
• Y is the vertical coordinate of one of the vertices of the pin associated with the location of the fault
candidate.
rI
• Layer is the physical layer where the pin object is defined.

Fo
Cell_boundary:
• L is the horizontal coordinate of the leftmost boundary of the cell identified with the fault candidate.
• R is the horizontal coordinate of the rightmost boundary of the cell identified with the fault candidate.
se
• B is the vertical coordinate of the bottommost boundary of the cell identified with the fault candidate.
• T is the vertical coordinate of the topmost boundary of the cell identified with the fault candidate.
U
ed
Also note that the performance data in the physical diagnosis report is slightly different than the standard
diagnosis report:
ct
The PHDS diagnosis report includes the wall time and the time it takes to query the PHDS database during
diagnosis.
tri
The second line in the report displays the number of extracted subnets and the number of bridge pairs queried
es
in the PHDS database compared to the total number of subnets and bridging pairs identified during the
previous diagnosis run. This data helps you identify any matching issues between the logical and physical
R
names during diagnosis.

The subnets and bridges extracted during a diagnosis run are displayed as “added”. The “total” includes
subnets and bridges extracted in previous diagnosis runs. For example, if the next diagnosis run extracts 10
subnets and 22 bridges, the second line appears as follows:
PHDS queries: subnets(added/total)=10/50 bridges(added/total)=22/80

TetraMAX Workshop
Physical Diagnosis: Subnets
 Physical topology is extracted from PHDS database

 Extracts subnet faults to more precisely localize defects on
high-fanout nets
ng
 Only considers physically possible combinations
ni
ai
Physical Topology Subnets Extracted
A
Tr
N.2 B
ip
E N.1
ch
C
ro
D
ic
12- 41
lM
na
The default flow, dynamic subnet extraction, is performed during diagnostics. Static subnet
extraction (i.e. extracting all subnets upfront) is only recommended when you run volume
er
diagnostics on a large number of failing parts. Otherwise, the additional runtime required for static
nt
extraction is greater than the total reduction in diagnosis runtimes.

rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Physical Diagnosis: Bridge Extraction
 During run_diagnosis, PHDS is queried dynamically for bridging pairs

 Given a net, PHDS will return likely bridge pairs to this net
 Returns neighbor nets touched within “tolerance” distance
ng
 Different “tolerance” per layer
ni
 Bridge pairs will be used in diagnostics to improve accuracy
ai
Tolerance
Tr
Neighbor
ip
Net
ch
Neighbor
ro
Net Corner-To-Corner Bridging
ic
Side-By-Side Bridging 12- 42
lM
na
Just like with subnets, bridging pairs are dynamically extracted from PHDS by default. A static
extraction flow is also available for volume diagnosis flows where it may give an overall diagnosis
er
runtime advantage.
nt
rI
Setting the tolerance:

• If pitch information exists in the technology files, default distance is equal to the pitch
Fo
• If no pitch, default is 1000nm

Changing default:
se
set_physical –tolerance {METAL 50 METAL1 100}

U
ed
ct
tri
es
R

TetraMAX Workshop

 List the 2 main command used in TetraMAX
diagnosis flows
ng
 Describe the difference between pattern-based and
ni
cycle-based Fail Data File formats
ai
 Understand how to interpret the TetraMAX
Tr
diagnosis results
ip
ch
Begin Lab 12: Diagnosis
ro
ic
12- 43
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
write_image <file> Write a binary image file
read_image <file> Read a binary image file
write_image <file> -password <string> Write a secure binary image file
read_image <file> -password <string> Read a secure binary image file
ng
set_commands –secure <command> Declare the allowed commands in a
subsequently written secure image file
ni
report_commands -secure Report the secure commands
set_diagnosis –check_expected_data
ai
Checked expected data in the fail data file
set_diagnosis –incomplete_failures Indicates that the fail data is not complete
Tr
set_diagnosis –cycle_offset <n> Adjust cycle count in the fail data file
set_diagnosis -auto Automatically select the diagnosis engine
ip
run_diagnosis –display Display diagnosis results in the GSV
ch
run_diagnosis –truncate <n> Declare last pattern applied for diagnosis
run_diagnosis –chain_failure
ro
Run chain failure diagnosis engine
run_atpg –ndetect <n> Enable N-detect ATPG
ic
12- 44
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Agenda
DAY
3
ng
ni
ai
Tr
ip
12 Diagnosis
ch
ro
13 Conclusion
ic
13- 1
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Conclusion ©2018 Synopsys, Inc. All Rights Reserved. 13-1

TetraMAX Workshop
After Units 1-4, You Can Now
 Use TetraMAX to pass the run_build_model and run_drc steps

 Run ATPG and obtain generate coverage reports
ng
 Debug Test Coverage issues
ni
ai
Tr
ip
ch
ro
ic
13- 2
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
After Unit 5-8, You Can Now
 Reduce the Test Pattern set using various methods including clock
grouping and DFTMAX compression
 Write scan patterns for validation in simulation and/or passing on to
ng
ATE
ni
 Simulate scan patterns using MAX testbench
ai
 Modify the SPF for At-Speed testing
Tr
 Read an SDC file to apply At-Speed Timing Exceptions
ip
 Control Switching activity with Power-Aware ATPG
ch
ro
ic
13- 3
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
After Units 9-12, You Can Now
 Generate At-Speed Transition Delay, Slack-Based Transition Delay, and

Path Delay patterns
 Use On-Chip Clocking (OCC) to perform At-Speed testing
ng
 Run diagnosis to determine the
ni
cause of a failure on the ATE
ai
Tr
ip
ch
ro
ic
13- 4
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
On Demand Training
ng
ni
ai
Tr
ip
ch
Recorded “Flash”
Training Modules
ro
ic
https://solvnet.synopsys.com/trainingcenter
13- 5
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Documentation on SolvNet
ng
ni
ai
Tr
ip
ch
In addition to the
OLH, TetraMAX has
ro
HTML and PDF docs
available on SolvNet
ic
13- 6
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Reference Methodology Scripts
 Synopsys Recommended Scripts

 Available for download from SolvNet
 https://solvnet.synopsys.com/rmgen
ng
 ATPG flow options include:
ni
 Stuck-At
ai
 Transition Delay
Tr
 Path Delay
 Bridging Faults
ip
 Power-Aware
ch
 On-Chip Clocking (OCC)
ro
 DFTMAX Ultra Compression
TetraMAX II
ic

13- 7
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
SolvNet: TetraMAX Reference Methodology
ng
ni
ai
Tr
ip
ch
ro
ic
13- 8
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Course Evaluation
 Synopsys needs your feedback to improve our courses

 Please take the time to complete the course evaluation you will receive
by email
ng
ni
ai
Tr
ip
ch
ro
ic
13- 9
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Thank You!
ng
ni
ai
Tr
ip
ch
ro
ic
13- 10
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
Appendix
ng
Downloading Lab Files From SolvNet
ni
ai
Tr
ip
ch
ro
ic
13- 11
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
How to Download Lab Files (1/2)
ng
ni
ai
Tr
ip
ch
ro
From the SolvNet home page:
ic
https://solvnet.synopsys.com/ 13- 12
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
How to Download Lab Files (2/2)
Locate Course Title
ng
2017.09
2016.03
ni
ai
Tr
ip
ch
Click to download the .tar.gz file.
(You may be asked for your SolvNet password a second time)
ro
A README file will walk you through the installation steps
ic
13- 13
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
ng
ni
ai
Tr
ip
ch
ro
ic
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

TetraMAX Workshop
ng
Customer Support
ni
ai
Tr
ip
ch
ro
ic
lM
© 2018 Synopsys, Inc. All Rights Reserved 20181001
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R
Customer Support © 2018 Synopsys, Inc. All Rights Reserved. cs-1

Synopsys Support Resources
 Build a solid foundation:

Hands-on training for Synopsys tools
and methodologies
https://synopsys.com/support/training.html
ng
 Workshop Schedule and Registration
 Download Labs
(SolvNet ID required)
ni
 Drill down to areas of interest:
ai
SolvNet online support
Tr
https://solvnet.synopsys.com
 Online technical information and access to
ip
support resources
 Documentation & Media
ch
 Ask an Expert:
Synopsys Support Center
ro
https://onlinecase.synopsys.com
ic
training.synopsys.com
CS - 2
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

SolvNet Online Support
 Immediate access to
the latest technical information
 Product Update Training
 Methodology Training
ng
 Thousands of expert-authored
articles, Q&As, scripts and tool tips
ni
 Open a Support Center Case
ai
 Release information
Tr
 Online documentation
License keys
ip

 Electronic software downloads
ch
 Synopsys announcements (latest
ro
tool, event and product information)
ic
https://solvnet.synopsys.com CS - 3
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

SolvNet Registration
1. Go to SolvNet page:
 https://solvnet.synopsys.com/
2. Click on:
 “Sign Up for an Account”
ng
3. Pick a username and password.
ni
4. You will need your “Site ID”
ai
 For Information on how to find your
Site ID, select the “Synopsys Site ID”
Tr
link
5. Authorization typically takes
ip
just a few minutes.
ch
ro
ic
https://solvnet.synopsys.com/ProcessRegistration CS - 4
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

Support Center
 Industry seasoned Application Engineers:

 50% of the support staff has
>5 years applied experience
ng
 Many tool specialist AEs with
>12 years industry experience
ni
 Engineers located worldwide
ai
 Great wealth of applied knowledge:
Service >2000 issues per month
Tr

 Remote access, and interactive debug,
ip
available via WebEx
ch
Contact us:
Open a support case
ro
http://www.synopsys.com/Support/GlobalSupportCenters
ic
CS - 5
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

Other Technical Sources
 Application Consultants (ACs):

 Tool and methodology pre-sales support
 Contact your Sales Account Manager for more information
ng
ni
 Synopsys Professional Services (SPS) Consultants:
ai
 Available for in-depth, on-site, dedicated, custom consulting
Tr
 Contact your Sales Account Manager for more details
ip
ch
 SNUG (Synopsys Users Group):
ro
https://www.synopsys.com/community/snug.html
ic
CS - 6
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

Summary: Getting Support
 Customer Training
https://www.synopsys.com/support/training.html
 Register for a Class
ng
 Download Labs
 SolvNet
ni
https://solvnet.synopsys.com
ai
Tool Documentation and Support Articles
Tr

 Product Update and Methodology Information / Training
ip
 Open a Support Case (Support Center)
ch
 Other Technical Resources
Synopsys Users Group (SNUG)
ro

 Application Consultants
ic
 Synopsys Professional Services CS - 7
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

ng
ni
ai
Tr
ip
ch
ro
ic
lM
na
er
nt
rI
Fo
se
U
ed
ct
tri
es
R

Tmax 2017.09 SG

Uploaded by

Copyright:

Available Formats

Tmax 2017.09 SG

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tmax 2017.09 SG

Uploaded by

Copyright:

Available Formats

ng

CUSTOMER EDUCATION SERVICES

Synopsys Customer Education Services

Mountain View, California 94043

Workshop Registration: http://training.synopsys.com

For Internal Microchip Training Purposes Only

Destination Control Statement

690 E. Middlefield Road

Document Order Number: 30-I-021-SSG-017

TetraMAX Student Guide

Synopsys Customer Education Services

For Internal Microchip Training Purposes Only

Unit i: Introduction & Overview

Propagate Fault Effect (2/4) ............................................................................................ 1-8

Record the Test Pattern (4/4) ........................................................................................ 1-10

Testing Sequential Designs ............................................................................................ 1-11

The Full Scan Strategy ................................................................................................... 1-13

Test Patterns Overlap .................................................................................................... 1-15

TetraMAX Interfaces ..................................................................................................... 1-17

Launching TetraMAX .................................................................................................... 1-19

Tcl API Commands........................................................................................................ 1-21

Retrieving Attributes Values.......................................................................................... 1-23

Tcl API Example............................................................................................................ 1-24

Getting Help - SolvNet Resources ................................................................................. 1-26

Synopsys 30-I-021-SSG-017 i TetraMAX Workshop

For Internal Microchip Training Purposes Only

Unit 2: Building ATPG Models

Investigating Models Graphically .................................................................................. 2-22

ATPG Modeling Primitives: Partial List ....................................................................... 2-24

ATPG Modeling Primitives: Examples ......................................................................... 2-25

Memory DFT Strategies ................................................................................................ 2-27

Clock Stable and Load Stable ........................................................................................ 2-30

RAM Modeling: Basic Example .................................................................................... 2-32

Utility to Generate TetraMAX Memory Models ........................................................... 2-34

Unit Objectives Summary .............................................................................................. 2-36

Command Summary (Lecture, Lab) .............................................................................. 2-37

Unit 3: Running DRC

Synopsys 30-I-021-SSG-017 ii TetraMAX Workshop

For Internal Microchip Training Purposes Only

Controlling ATPG: Agenda ............................................................................................. 3-4

Debugging an S1 Violation ............................................................................................ 3-27

Change Pindata to test_setup to Debug Initialization Issues ......................................... 3-29

Stability Patterns ............................................................................................................ 3-30

Using the SWV .............................................................................................................. 3-32

Want to Quickly Return to TEST Mode? ...................................................................... 3-34

Fault Classes .................................................................................................................. 3-36

Faults Classifications Right After DRC ......................................................................... 3-38

Unused FF Output Pins become UU Faults ................................................................... 3-40

Undetectable Redundant (UR) Fault .............................................................................. 3-42

Constraints Can Create AU Faults ................................................................................. 3-43

Defining Nofaults........................................................................................................... 3-45

Synopsys 30-I-021-SSG-017 iii TetraMAX Workshop

For Internal Microchip Training Purposes Only

Fault List After Collapsing ........................................................................................... 3-50

Enabling Fast-Sequential ATPG .................................................................................... 4-12

When Can Fast-Sequential ATPG Help? ....................................................................... 4-14

Results after Fast-Sequential ATPG .............................................................................. 4-15

ATPG Guidelines ........................................................................................................... 4-17

Enabling Multicore Support ........................................................................................... 4-19