DFTXG 2

DFTMAX™
Compression
User Guide
Version H-2013.03-SP4, September 2013
Copyright Notice and Proprietary Information
© 2013 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 of Synopsys, Inc., or as expressly provided by the license agreement.
Destination Control Statement
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 reader's responsibility to
determine the applicable regulations and to comply with them.
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 OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Trademarks
Synopsys and certain Synopsys product names are trademarks of Synopsys, as set forth at
http://www.synopsys.com/Company/Pages/Trademarks.aspx.
All other product or company names may be trademarks of their respective owners.
Third-Party Links
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.
Synopsys, Inc.
700 E. Middlefield Road
Mountain View, CA 94043
www.synopsys.com
DFTMAX™ Compression User Guide, version H-2013.03-SP4 ii

Copyright Notice for the Command-Line Editing Feature
© 1992, 1993 The Regents of the University of California. All rights reserved. This code is derived from software contributed to
Berkeley by Christos Zoulas of Cornell University.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the
following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following
disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software must display the following acknowledgement:
This product includes software developed by the University of California, Berkeley and its contributors.
4. Neither the name of the University nor the names of its contributors may be used to endorse or promote products
derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Copyright Notice for the Line-Editing Library

© 1992 Simmule Turner and Rich Salz. All rights reserved.
This software is not subject to any license of the American Telephone and Telegraph Company or of the Regents of the
University of California.
Permission is granted to anyone to use this software for any purpose on any computer system, and to alter it and
redistribute it freely, subject to the following restrictions:
1. The authors are not responsible for the consequences of use of this software, no matter how awful, even if they arise
from flaws in it.
2. The origin of this software must not be misrepresented, either by explicit claim or by omission. Since few users ever
read sources, credits must appear in the documentation.
3. Altered versions must be plainly marked as such, and must not be misrepresented as being the original software.
Since few users ever read sources, credits must appear in the documentation.
4. This notice may not be removed or altered.
DFTMAX™ Compression User Guide, version H-2013.03-SP4 iii

DFTMAX™ Compression User Guide, version H-2013.03-SP4 iv
Contents
About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv

Customer Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
1. Introduction
Introduction to the DFTMAX Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
The Adaptive Scan Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Decompressor Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
Compressor Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
Adaptive Scan Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
Design Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
Pin Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
Multicore Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Limitations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
Current Limitations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
Limitations Associated With Adaptive Scan Technology . . . . . . . . . . . . . . . . . . 1-9
Limitations Associated With Hierarchical Adaptive Scan Synthesis . . . . . . . . . 1-9
2. Using Adaptive Scan Technology

Top-Down Flat Compressed Scan Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Top-Down Flat Compressed Scan Flow With Partitions . . . . . . . . . . . . . . . . . . . . . . 2-6
Defining and Configuring Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
Configuring Partition Codecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
Choosing a Partition Codec Insertion Method . . . . . . . . . . . . . . . . . . . . . . 2-10
v
DFTMAX™
DFTMAX™ Compression
Compression User
User Guide
Guide H-2013.03-SP4
Version H-2013.03-SP4
Supported DFT Configuration Commands for Partitions . . . . . . . . . . . . . . . . . . 2-12

set_scan_configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12
set_scan_compression_configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12
set_dft_signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13
set_dft_location. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13
set_scan_path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
Supported DFT Features in the Partition Flow . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
Limitations of the Partition Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
Known Issues of the Partition Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
Partition Script Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
Scan Compression and Multiple Test Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
Defining Multiple Compressed Scan Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
Supported Compressed Scan Specification Commands. . . . . . . . . . . . . . . . . . 2-19
set_scan_compression_configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19
set_scan_path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20
Multiple Test-Mode Script Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20
Multiple Standard Scan Modes and One Compressed Scan Mode . . . . . . 2-20
Multiple Standard Scan and Compressed Scan Modes . . . . . . . . . . . . . . . 2-22
Standard Scan Flow Using Multiple Test Modes and Partitions . . . . . . . . . 2-25
Scan Compression Flow Using Multiple Test Modes and Partitions . . . . . . 2-26
Scan Compression and OCC Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-27
Specifying a Different Scan Pin Count for Compressed Scan Mode . . . . . . . . . . . . 2-28
Adding Compressed Chain Lock-Up Latches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-29
Applying Low-Power Gating to the Output Compressor . . . . . . . . . . . . . . . . . . . . . . 2-31
Preserving Compressor Gating Cells During Optimization . . . . . . . . . . . . . . . . 2-32
Forcing a Compressor With Full Diagnostic Capabilities . . . . . . . . . . . . . . . . . . . . . 2-33
Excluding Scan Chains From Scan Compression . . . . . . . . . . . . . . . . . . . . . . . . . . 2-35
Performing Congestion Optimization on Compressed Scan Designs. . . . . . . . . . . . 2-36
Using AutoFix With Scan Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-37
One-Pass DFTMAX Example With AutoFix . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-37
One-Pass DFTMAX Example With AutoFix and Multiple Test Modes . . . . . . . . 2-39
Running TetraMAX ATPG on Compressed Scan Designs . . . . . . . . . . . . . . . . . . . . 2-41
Using TetraMAX for Pattern Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-41
Compressor Structure Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-42
Chain Test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-42
Contents vi
DFTMAX™ Compression User Guide Version H-2013.03-SP4
Estimating Compression Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-42

Data Volume and Test Application Time Reduction Calculations . . . . . . . . 2-44
Pattern Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-45
Generating Patterns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-46
Generating Patterns in Compressed Scan Mode . . . . . . . . . . . . . . . . . . . . 2-46
Generating Patterns in Standard Scan Mode . . . . . . . . . . . . . . . . . . . . . . . 2-46
Translating Compressed Scan Patterns to Standard Scan Mode Patterns . . . . 2-47
3. Hierarchical Adaptive Scan Synthesis

The HSS Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
The HASS Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Preparing Cores in the HASS Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4
HASS Integration of Compressed Scan Cores . . . . . . . . . . . . . . . . . . . . . . . . . 3-5
HASS Integration of Additional Uncompressed Scan Logic . . . . . . . . . . . . . . . 3-6
The Hybrid Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
Performing Top-Level Hybrid Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
Performing Top-Level Hybrid Integration with Partitions . . . . . . . . . . . . . . . . . . 3-12
Generating Patterns in TetraMAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14
Top-Level Integration Script Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15
Typical HASS Flow Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15
Typical Hybrid Flow Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15
Hybrid Flow Script With Multiple Test Modes. . . . . . . . . . . . . . . . . . . . . . . . . . . 3-16
Limitations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18
HASS Flow Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18
Hybrid Flow Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18
4. Managing X Values in Scan Compression

High X-Tolerance Scan Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
The High X-Tolerance Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Enabling High X-Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Scan-In and Scan-Out Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
Supported Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5
Static-X Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
Architecting X Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
Chapter 2: Contents
Contents 2-vii
vii
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
The X-Chain Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8

Enabling X Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9
Manually Specifying X-Chain Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10
Using the set_scan_path Command With X Chains . . . . . . . . . . . . . . . . . . . . . 4-11
Using AutoFix With X Chains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11
Using X Chains in Hierarchical Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
Static-X Cells in the HASS Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
Hierarchical Blocks and X Sources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15
Using the test_simulation_library Variable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16
Representing X Chains in SCANDEF Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17
Passing X-Chain Information to TetraMAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-18
Error and Warning Summaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19
X-Chain Usage Guidance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20
5. Advanced Adaptive Scan Techniques

Specifying a Location for DFT Logic Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Creating New DFT Logic Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
Specifying a Location for Codec Logic Insertion . . . . . . . . . . . . . . . . . . . . . . . . 5-6
Pipelined Scan Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
Introduction to Pipelined Scan Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
Using Pipelined Scan Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
Enabling Pipelined Scan Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9
Automatically Inserting Head and Tail Pipeline Registers. . . . . . . . . . . . . . 5-9
Specifying User-Defined Head and Tail Pipeline Registers . . . . . . . . . . . . 5-10
Compressed Scan Flow With Pipelined Scan Data . . . . . . . . . . . . . . . . . . . . . . 5-13
Avoiding X Capture in Head Pipeline Registers . . . . . . . . . . . . . . . . . . . . . 5-15
Pipelined Scan Data Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17
Scan Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17
Scan Register Synchronization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18
Pipelined Scan Data Test Protocol Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18
Pipelined Scan Data Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-19
Hierarchical Flows With Pipelined Scan Data . . . . . . . . . . . . . . . . . . . . . . . . . . 5-20
General Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21
Pipelined Scan Data in the Standard Scan HSS Flow . . . . . . . . . . . . . . . . 5-21
Pipelined Scan Data in the HASS and Hybrid Flows . . . . . . . . . . . . . . . . . 5-22
Sharing Codec Scan I/O Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-22
Specifying the I/O Sharing Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24
Contents viii
Determining the Fully Shared I/O Configuration . . . . . . . . . . . . . . . . . . . . . . . . 5-26

Determining Shared Input Pin Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-26
Adding High X-Tolerance Block-Select Pins . . . . . . . . . . . . . . . . . . . . . . . . 5-28
Automatically Computing the Fully Shared Configuration . . . . . . . . . . . . . 5-30
Manually Computing the Fully Shared Configuration . . . . . . . . . . . . . . . . . 5-30
Codec I/O Sharing in the HASS Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-31
Codec I/O Sharing in the Hybrid Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-32
Codec I/O Sharing in the Top-Down Flat Flow. . . . . . . . . . . . . . . . . . . . . . . . . . 5-34
Codec I/O Sharing With Identical Cores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-35
Specifying Shared Codec Inputs With Dedicated Codec Outputs . . . . . . . 5-37
Codec I/O Sharing Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-39
Defining Sharing Groups in the HASS Flow . . . . . . . . . . . . . . . . . . . . . . . . 5-39
Defining Sharing Groups in the Hybrid Flow . . . . . . . . . . . . . . . . . . . . . . . 5-40
Defining Sharing Groups in the Top-Down Flat Flow . . . . . . . . . . . . . . . . . 5-43
Codec I/O Sharing and Standard Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . 5-45
Codec I/O Sharing and Pipelined Scan Data. . . . . . . . . . . . . . . . . . . . . . . . . . . 5-47
Integration of Cores With Shared Codec I/O Connections . . . . . . . . . . . . . . . . 5-49
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-51
Implicit Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-51
Defining Implicit Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-52
Implicit Scan Chain Script Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-54
Protocol Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-55
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-56
6. Adaptive Scan With Serializer

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
Serializer Clock Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
Deserializer Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
Serializer Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
Serializer Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
Higher Shift Speed and Update Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6
Scan-Enable Signal Requirements for Serializer Operation . . . . . . . . . . . . . . . . . . . 6-10
Timing Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11
Scan Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-12
Chapter 2: Contents
Contents 2-ix
ix
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Deserializer/Serializer Update Stage Register Clocks. . . . . . . . . . . . . . . . . . . . 6-13

Specifying a Clock for Deserializer/Serializer Registers . . . . . . . . . . . . . . . . . . 6-13
Staggered Scan Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-14
Specifying Scan Clock Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-15
User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-15
Configuring Serialized Compressed Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16
Deserializer/Serializer Register Size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-17
Serializer Implementation Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-18
Serialized Compressed Scan Core Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-18
Serializer Core-Level Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-19
User-Defined Ports for the Serializer Core-Level Flow . . . . . . . . . . . . . . . . . . . 6-20
Nondefault Scan Clock Timing for Core-Level Flows. . . . . . . . . . . . . . . . . . . . . 6-21
Top-Down Flat Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-21
Serial Mode and Standard Scan Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-22
Serial Mode, Parallel Mode, and Standard Scan Mode . . . . . . . . . . . . . . . . . . . 6-22
Top-Down Partition Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-24
Serializer Chains Dedicated to Each Partition . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25
Serializer Chains Concatenated Across Partitions . . . . . . . . . . . . . . . . . . . . . . 6-27
HASS Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-29
Serializer Chains Dedicated to Each Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-30
Serializer Chains Concatenated Across Cores . . . . . . . . . . . . . . . . . . . . . . . . . 6-34
Hybrid Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-36
Serializer Chains Concatenated Across Cores . . . . . . . . . . . . . . . . . . . . . . . . . 6-39
Serializer IP Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-39
Configuring Serializer IP Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-41
Serializer IP Insertion in the Top-Down Flat Flow . . . . . . . . . . . . . . . . . . . . . . . 6-42
Serializer IP Insertion in the Top-Down Flat Flow With Partitions . . . . . . . . . . . 6-43
Serializer IP Insertion in the HASS Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-44
Referencing Multiple Codecs in Compressed Scan Cores . . . . . . . . . . . . . 6-46
Serializer IP Insertion in the Hybrid Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-48
Serializer IP Insertion in the Hybrid Flow With Top-Level Partitions . . . . . . 6-49
Incorporating External Chains Into the Hybrid Serializer IP Flows . . . . . . . 6-50
Serializer IP Insertion and Standard Scan Chains . . . . . . . . . . . . . . . . . . . . . . 6-53
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-54
Contents x
Wide Duty Cycle Support for Serializer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-54

Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-55
Timing Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-57
Internally Generated Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-58
Wide Duty Cycle in a Core-Level Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-60
Wide Duty Cycle in the HASS Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-60
Wide Duty Cycle in the Hybrid Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-60
Dual STIL Flow Parallel Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-61
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-63
Serializer in Conjunction With On-Chip Clocking Controllers . . . . . . . . . . . . . . . . . . 6-63
Using Serializer With User-Defined OCC Controllers . . . . . . . . . . . . . . . . . . . . 6-63
Using a Serializer Clock Controller With Multiple OCC Controllers . . . . . . . . . . 6-64
Waveforms for a Serializer With OCC Controllers . . . . . . . . . . . . . . . . . . . . . . . 6-65
Using Integrated Clock-Gating Cells in the Serializer Clock Controller. . . . . . . . . . . 6-67
User-Defined Pipelined Scan Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-67
Running TetraMAX ATPG on Serializer Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-67
Simulation and Patterns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-68
Reading and Writing Patterns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-68
Pattern Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-68
STIL Procedure File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-69
load_unload Procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-69
UserKeywords SerializerStructures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-72
Compressor Structures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-76
ClockStructures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-79
Debugging TetraMAX Serializer DRC Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-80
Debugging R33 Through R38 DRC Errors . . . . . . . . . . . . . . . . . . . . . . . . . 6-80
Providing Guidance for R34 and R36 DRC Errors . . . . . . . . . . . . . . . . . . . 6-83
Pattern Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-86
Translating Parallel Mode Patterns to Serial Mode Patterns. . . . . . . . . . . . 6-86
Translating Serial Mode Patterns to Standard Scan Mode Patterns. . . . . . 6-89
Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-89
C1 Violations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-89
Serializer Core-Level Flow With Pipelined Scan Data Insertion . . . . . . . . . 6-89
Adaptive Scan With Serializer Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-90
Out-of-Scope Serializer Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-91
DFTMAX Compression Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-91
Chapter 2: Contents
Contents 2-xi
xi
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
TEST-1093 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-91
TEST-1094 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-91
TEST-1095 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-91
TEST-1096 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-91
TEST-1097 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-91
Appendix A. Example Scripts

Example Tcl Procedure to Determine the Area of Compressors . . . . . . . . . . . . . . . A-2
Example Formality Script for Equivalence Checking . . . . . . . . . . . . . . . . . . . . . . . . A-3
Contents xii
Preface
This preface includes the following sections:
• About This Guide
• Customer Support
xiii
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
About This Guide

The DFTMAX Compression User Guide describes the process for inserting adaptive scan
DFT compression logic into a design using the Synopsys DFTMAX™ tool and automatically
generating test patterns for use in the Synopsys TetraMAX® tool.
Audience
This user guide is intended for ASIC design engineers who have some experience with
testability concepts and strategies and for test and design-for-test engineers who want to
understand how certain test automation concepts and practices relate to the DFTMAX tool.
Related Publications
For additional information about the DFT Compiler tool, see the documentation on the
Synopsys SolvNet® online support site at the following address:
https://solvnet.synopsys.com/DocsOnWeb
You might also want to see the documentation for the following related Synopsys products:
• DFT Compiler
• Design Compiler®
• BSD Compiler
• TetraMAX®
• PrimeTime®
Release Notes
Information about new features, enhancements, changes, known limitations, and resolved
Synopsys Technical Action Requests (STARs) is available in the DFT Compiler Release
Notes on the SolvNet site.
To see the DFT Compiler Release Notes,
1. Go to the SolvNet Download Center located at the following address:
https://solvnet.synopsys.com/DownloadCenter
2. Select DFT Compiler, and then select a release in the list that appears.
Preface
About This Guide xiv
Conventions
The following conventions are used in Synopsys documentation.
Convention Description
Courier Indicates syntax, such as write_file.
Courier italic Indicates a user-defined value in syntax, such as

write_file design_list.
Courier bold Indicates user input—text you type verbatim—in

examples, such as
prompt> write_file top
[] Denotes optional arguments in syntax, such as

write_file [-format fmt]
... Indicates that arguments can be repeated as many

times as needed, such as
pin1 pin2 ... pinN
| Indicates a choice among alternatives, such as

low | medium | high
Ctrl+C Indicates a keyboard combination, such as holding

down the Ctrl key and pressing C.
\ Indicates a continuation of a command line.
/ Indicates levels of directory structure.
Edit > Copy Indicates a path to a menu command, such as

opening the Edit menu and choosing Copy.
Preface 1: Preface
Chapter
About This Guide 1-xv
xv
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Customer Support
Customer support is available through SolvNet online customer support and through
contacting the Synopsys Technical Support Center.
Accessing SolvNet
The SolvNet site includes a knowledge base of technical articles and answers to frequently
asked questions about Synopsys tools. The SolvNet site also gives you access to a wide
range of Synopsys online services including software downloads, documentation, and
technical support.
To access the SolvNet site, go to the following address:
https://solvnet.synopsys.com
If prompted, enter your user name and password. If you do not have a Synopsys user name
and password, follow the instructions to sign up for an account.
If you need help using the SolvNet site, click HELP in the top-right menu bar.
Contacting the Synopsys Technical Support Center

If you have problems, questions, or suggestions, you can contact the Synopsys Technical
Support Center in the following ways:
• Open a support case to your local support center online by signing in to the SolvNet site
at https://solvnet.synopsys.com, clicking Support, and then clicking “Open A Support
Case.”
• Send an e-mail message to your local support center.
❍ E-mail support_center@synopsys.com from within North America.
❍ Find other local support center e-mail addresses at
http://www.synopsys.com/Support/GlobalSupportCenters/Pages
• Telephone your local support center.
❍ Call (800) 245-8005 from within North America.
❍ Find other local support center telephone numbers at
http://www.synopsys.com/Support/GlobalSupportCenters/Pages
Preface
Customer Support xvi
1
Introduction 1
DFTMAX compression provides synthesis-based adaptive scan technology to lower the cost
of testing complex designs, particularly when fabricated with advanced process
technologies. These deep-submicron (DSM) designs can have subtle manufacturing defects
that are only detected by applying DSM tests, such as at-speed and bridging tests, in
addition to stuck-at tests. The extra patterns needed to achieve high test quality for these
designs can increase both the test time and the test data, resulting in higher test costs.
DFTMAX compression reduces these costs by delivering a significant test data and test time
reduction with very low silicon area overhead. The DFTMAX tool uniquely enables adaptive
scan compression in Design Compiler synthesis and adaptive scan pattern generation in
TetraMAX ATPG.
The following sections introduce you to the DFTMAX tool:
• Introduction to the DFTMAX Tool
• The Adaptive Scan Architecture
• Adaptive Scan Requirements
• Multicore Processing
• Limitations
1-1
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Introduction to the DFTMAX Tool

The DFTMAX tool provides the following features:
• All DFT Compiler features
The DFTMAX tool includes all scan insertion capabilities provided by the DFT Compiler
tool. For more information, see the DFT Compiler Scan User Guide.
• DFTMAX scan compression
This feature provides a significant reduction in test time and test data compared to
standard scan. For more information, see this user guide.
• IEEE Std 1149.1 and 1149.6 boundary-scan insertion
The DFTMAX tool includes all boundary-scan insertion capabilities provided by the BSD
Compiler tool. For more information, see the BSD Compiler User Guide and the BSD
Compiler Reference Manual.
• Automatic test point insertion
This feature automatically inserts test points at difficult-to-test points to improve design
testability. For more information, see the “Automatically Inserting Test Points” section in
Chapter 7, “Advanced DFT Architecture Methodologies,” in the DFT Compiler Scan User
Guide.
• Core wrapping with maximized register reuse
This feature minimizes the area and timing impact of core wrapping by reusing more
existing functional registers. For more information, see the “Maximized Reuse Core
Wrapping Flow” section in Chapter 8, “Wrapping Cores,” in the DFT Compiler Scan User
Guide.
The Adaptive Scan Architecture

Adaptive scan appears similar to standard scan at the chip-level interface, but it contains
combinational compression logic and uses many more scan chains of shorter lengths within
the chip core. As scan input values are shifted in, the adaptive scan decompressor
distributes them across numerous scan chains. The distribution method is accomplished
with a patented hardware scheme and a process that allows chip-level scan input values to
be placed into various scan chains. To maximize test coverage and minimize pattern count,
the decompressor adapts to the needs of automatic pattern generation to supply the
required values in the scan chain cells, which is why this technology is called adaptive scan.
Chapter 1: Introduction
Introduction to the DFTMAX Tool 1-2
Adaptive scan technology provides the following key benefits and features:
• A significant test time and test data reduction compared to standard scan
• Similar ease-of-use as standard scan
• Concurrent optimization of area, power, timing, physical constraints, and test constraints
through a synthesis-based implementation
• Pin-limited test optimizations
• Unknown logic value (X) handling
• Flexible scan channel configurations to support multisite testing and wafer-level burn-in
Figure 1-1 shows the adaptive scan architecture.

Figure 1-1 Adaptive Scan Technology Architecture
&RPSUHVVHGVFDQGDWDLQ
'HFRPSUHVVRU
&RPSUHVVHGVFDQFKDLQV &RGHF
VKRUWHUOHQJWK KDVYHU\VPDOO
UHGXFHVWHVWWLPH DUHDRYHUKHDG
&RPSUHVVRU
&RPSUHVVHGVFDQGDWDRXW
Adaptive scan technology divides standard scan chains into a larger number of shorter
chains, called compressed scan chains, which reduces tester time. The decompressor
controls the flow of scan data into the scan chains. The compressor reduces the captured
data from the larger number of compressed scan chains so that it can be observed through
the scan-out ports. The combination of the decompressor and compressor wrapped around
the scan chains is called the codec, which is short for compressor-decompressor.
The adaptive scan technology codec significantly reduces the amount of test data needed
to comprehensively test the chip. In turn, this lowers automatic test equipment (ATE)
memory requirements and allows additional deep submicron (DSM) test patterns.
The Adaptive Scan Architecture 1-3
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Decompressor Operation
Figure 1-2 shows a decompressor logic structure example. The decompressor outputs are
driven by different combinations of scan-in data pins, either directly or through MUXs. One
or more scan-in data pins, called load-mode pins, are dedicated to the MUX select signals.
Figure 1-2 Decompressor Logic Structure Example for 4-to-8 Decompressor
6FDQLQSLQV
/RDGPRGHSLQV 5HJXODUVFDQLQGDWDSLQV
VHO>@ GLQ>@ GLQ>@ GLQ>@
GRXW>@ GRXW>@ GRXW>@ GRXW>@ GRXW>@ GRXW>@ GRXW>@ GRXW>@
This logic structure takes advantage of the fact that not every scan cell must be uniquely
controllable in every pattern. Typically, only a sparse set of scan cells are required to be
controlled in a pattern. In each shift clock cycle, ATPG can choose load-mode and scan data
values that steer these required values into the compressed scan chains.
Some designs might have complex logic that requires more scan cells to be controlled in
each pattern. As the decompressor input width increases, the number of load-mode and
scan-in data pins increases to provide additional controllability at the decompressor outputs.
The decompressor output width is equal to the number of compressed scan chains. As the
compressed chain count increases, more data steering logic configurations are needed. If
the compressed chain count is increased too high, the data steering configurations must
repeat, which can reduce the ability of ATPG to steer data into the compressed chains.
Compressor Operation
Figure 1-3 shows a compressor logic structure example. The compressor outputs are driven
by different combinations of compressed scan chains, combined using XOR logic. An
incorrect data value (fault) from a compressed scan chain results in a specific signature of
incorrect values at the compressor outputs.
The Adaptive Scan Architecture 1-4
Figure 1-3 Compressor Logic Structure Example for 8-to-4 Compressor

GLQ>@ GLQ>@ GLQ>@ GLQ>@ GLQ>@ GLQ>@ GLQ>@ GLQ>@
GRXW>@ GRXW>@ GRXW>@ GRXW>@
The compressor input width is equal to the number of compressed scan chains. As the
compressed chain count increases, more XOR configurations are needed. If the chain count
is increased too high, the XOR configurations (and therefore the compressed chain
signatures) must repeat, which can impact the diagnosability of the design.
As the compressor output width increases, the number of fault signatures observed at each
output port decreases. This can improve the diagnosability of the design, especially when
multiple faults must be simultaneously diagnosed.
Adaptive Scan Requirements

You need to consider both design and pin requirements when using adaptive scan
technology. The following two sections describe these requirements.
Design Requirements
Designs that use adaptive scan are generally scan-replaced, that is, test-ready. The
supported DFTMAX flows include top-down and bottom-up methodologies, but you can also
start from the RTL if you can successfully run the compile -scan command to bring your
design into a test-ready state.
Pin Requirements
Adaptive scan technology reuses the scan ports and scan-enable signals that were used in
regular scan mode in DFT Compiler. Only one additional test-mode port is required to
differentiate between scan compression mode and internal scan mode.
Adaptive Scan Requirements 1-5
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
If you already have a test-mode port in your design, you can define it and specify the hookup
point by using the following command:
set_dft_signal -type TestMode -hookup_pin
If you do not have a test-mode port, the insert_dft command automatically creates one
for you. Note that you cannot use the same test-mode port for the on-chip clocking (OCC),
AutoFix, or scan compression mode. If you want to associate a particular test-mode port
with the OCC or AutoFix test-mode port, you can do so by using the -control_signal
option of the set_autofix_configuration command to control the order of the specified
TestMode pins.
Using DFTMAX compression with the default X-masking capabilities allows a single scan-in
pin and scan-out pin to be used for accessing the compressed scan chains in compressed
scan mode. You can define the minimal number of access pins for compressed scan mode
with the following command:
set_scan_compression_configuration -xtolerance default \
-inputs 1 -outputs 1
When using DFTMAX compression with the high X-tolerance capability, a minimum of two
scan-in pins and one scan-out pin are supported. You can define the minimal number of
access pins in compressed scan mode with high X-tolerance enabled by using the following
command:
set_scan_compression_configuration -xtolerance high \
Multicore Processing
DFT Compiler supports multicore processing. To enable this feature, run the following
command:
set_host_options -max_cores maximum_number_of_cores
The maximum_number_of_cores value, which specifies the number of cores for threading,
should be a positive integer that is 2 or greater.
You must specify the number of cores the tool can use before running the insert_dft
command.
The maximum_number_of_cores setting is persistent throughout a given Design Compiler
shell session. Therefore, if you specified this setting during an initial compile stage and did
not quit the session, the same setting remains in effect during the DFT insertion stage.
The setting is not saved into a .ddc file. If you quit the session before DFT insertion and then
start a new shell, DFT insertion will use the tool’s default settings.
Multicore Processing 1-6
If you request more cores than are available, the insert_dft command proceeds, using the
number of cores that actually are available.
Use the remove_host_options command to revert to the tool defaults.
License Usage
For multicore processing, one DFT Compiler/DFTMAX license supports up to two cores,
that is, one license is required for every two cores.
The tool checks out licenses per the specifications defined in the set_host_options
command.
If you do not have access to a sufficient number of licenses, the insert_dft command
issues a (SEC-50) error similar to the following:
Error: All ‘Test-Compression-Synthesis’ licenses are in use (SEC-50)
The current users of this feature are:
designer at runhost, started on Thursday 5/7 at 15:52
The following examples show commands that are common in a DFT flow, along with the
number of required licenses for the multicore operation of each command:
• compile_ultra -scan -congestion command with power constraints, using 4 cores
❍ 2 DC Expert
❍ 2 DC Ultra
❍ 2 DFT Compiler
❍ 2 Power Compiler
❍ 2 DesignWare
❍ 2 DC-Extension
• insert_dft command with compression and no congestion, using 4 cores
❍ 2 DFT Compiler
❍ 2 DFTMAX
• insert_dft command with compression and congestion, using 4 cores
❍ 2 DFT Compiler
❍ 2 DFTMAX
❍ 2 DC Expert
❍ 2 DC Ultra
Multicore Processing 1-7
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
❍ 2 DC-Extension
• insert_dft command with sequential compression and congestion, using 4 cores
❍ 2 DFT Compiler
❍ 2 DFTMAX
❍ 2 DFTMAX Ultra
❍ 2 DC Expert
❍ 2 DC Ultra
Consistent with the compile_ultra command, licenses are not automatically released until
the end of the Design Compiler shell session or until you explicitly issue the
remove_license command.
If you request more licenses than are available per licensing scheme, the insert_dft
command stops and issues an error message similar to the following:
Error: All 'Test-Compression-Synthesis' licenses are in use. (SEC-50)
The current users of this feature are: designer at runhost, started on
Thursday 5/7 at 15:52
Limitations
This section covers current limitations and known issues associated with adaptive scan
technology.
Current Limitations
The following features are currently not supported:
• You cannot use the existing scan flow to insert compression logic into a design that
already has standard scan chains at the top level.
• You cannot use the set_scan_path command, unless it is used with a multiple
test-mode specification.
Limitations 1-8
Limitations Associated With Adaptive Scan Technology

Note the following set of limitations as they relate to adaptive scan technology:
• There is no graphical DRC debugging support in the Synopsys Design Vision™ GUI for
compressor design rule violations.
• Unified DRC (dft_drc) is the only design rule checking (DRC) engine supported when
scan compression is enabled.
• There is no plan to support the ability to read back Verilog patterns.
• Write patterns nshifts is not supported with DFTMAX compression.
• You cannot write out a parallel Verilog testbench when you read in the image saved after
running DRC in regular scan mode.
• Each pattern in scan compression mode pattern is dependent on the next pattern.
Because of this, you cannot reorder any ATPG patterns, including basic scan patterns.
Limitations Associated With Hierarchical Adaptive Scan Synthesis

See “Limitations” on page 3-18.
Limitations 1-9
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Limitations 1-10
2
Using Adaptive Scan Technology 2
If you are currently implementing standard scan logic, you can insert adaptive scan
compression into your design by using a single additional command. Typically, no other
changes to your design are required.
This chapter describes the processes associated with using adaptive scan technology. It
includes the following subsections:
• Top-Down Flat Compressed Scan Flow
• Top-Down Flat Compressed Scan Flow With Partitions
• Scan Compression and Multiple Test Modes
• Scan Compression and OCC Controllers
• Specifying a Different Scan Pin Count for Compressed Scan Mode
• Adding Compressed Chain Lock-Up Latches
• Applying Low-Power Gating to the Output Compressor
• Forcing a Compressor With Full Diagnostic Capabilities
• Excluding Scan Chains From Scan Compression
• Performing Congestion Optimization on Compressed Scan Designs
• Using AutoFix With Scan Compression
• Running TetraMAX ATPG on Compressed Scan Designs
2-1
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Top-Down Flat Compressed Scan Flow

This section describes the top-down flat flow with adaptive scan technology.
Example 2-1 shows a basic top-down flat compressed scan insertion script for a test-ready
design previously compiled with the compile -scan command. The three commands in
bold indicate the commands added to the scan script to enable scan compression.
Example 2-1 Script for Enabling Compressed Scan in the Top-Down Flat Insertion Flow
read_netlist test_ready.ddc
set_dft_configuration -scan_compression enable
set_dft_signal -view existing_dft -type ScanClock \

-port CLK -timing [list 45 55] ;# default strobe is at 40
set_scan_configuration -chain_count 3 -clock_mixing mix_clocks

set_scan_compression_configuration -chain_count 8
create_test_protocol
dft_drc
preview_dft
insert_dft
change_names -rules verilog -hierarchy
write -format verilog -hierarchy -output design.v
write_test_protocol -output scan.spf \

-test_mode Internal_scan
write_test_protocol -output scancompress.spf \
-test_mode ScanCompression_mode
To insert compressed scan logic in your design, use the -scan_compression option of the
set_dft_configuration command. This is the only required command to enable
compressed scan insertion.
dc_shell> set_dft_configuration -scan_compression enable
When scan compression is enabled, the insert_dft command inserts compressed scan
logic into the design and defines the following two test modes:
• Compressed scan mode
This mode configures the scan elements as short chains driven by decompressors. The
default name for this test mode is ScanCompression_mode.
Chapter 2: Using Adaptive Scan Technology

Top-Down Flat Compressed Scan Flow 2-2
• Standard scan mode

This mode joins the short compressed scan chains to reconfigure them into longer
standard scan chains. This is also known as standard scan mode. The default name for
this test mode is Internal_scan.
These test modes are created automatically during compressed scan insertion. You do not
need to use the -test_mode option in your scripts to create or name them. Figure 2-1 shows
the scan structures for the two test modes created by Example 2-1.
Figure 2-1 Standard Scan and Compressed Scan Modes
6WDQGDUGVFDQPRGH &RPSUHVVHGVFDQPRGH
6FDQLQV 6FDQLQV
WR
WHVWBPRGH WHVWBPRGH
WR
6FDQRXWV 6FDQRXWV
At least one test-mode signal is required to select between standard scan mode and
compressed scan mode. If a TestMode signal has been defined with the set_dft_signal
command, it is used for mode selection. If no test-mode signals have been defined, a
test-mode port is created and used. Test-mode encodings are created that map the
test-mode signal values to each scan mode.
Note:
For more information on working with multiple test modes in DFT Compiler, including
information on specifying test-mode encodings, see the “Multiple Test Modes” section in
the DFT Compiler Scan User Guide.
A compressed scan mode is always associated with a corresponding standard scan mode.
The standard scan mode associated with a compressed scan mode is known as its base
mode. The base mode controls aspects of scan configuration that are common to both
modes, such as scan port definitions, scan signal hookup pin definitions, and top-level test
access structures.
The set_scan_configuration command configures aspects of the standard scan mode,
while the set_scan_compression_configuration command configures aspects of the
compressed scan mode. In Example 2-1 on page 2-2, three standard scan chains and eight
compressed scan chains are created.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
You can use the following set_scan_compression_configuration options to control the

compressed scan mode chain counts, in order of highest precedence first:
• set_scan_compression_configuration -max_length chain_length
The -max_length option specifies the maximum compressed scan mode chain length.
The tool attempts to architect the number of compressed scan mode chains needed to
meet this requirement.
• set_scan_compression_configuration -chain_count chain_count
The -chain_count option specifies the number of compressed scan mode chains. The
tool attempts to build compressed scan mode chains with the necessary lengths to meet
this requirement.
• set_scan_compression_configuration -minimum_compression ratio
The -minimum_compression option specifies the minimum amount of compression.
This is a relative method of specifying the compressed scan chain count. The standard
mode scan chains are subdivided into compressed scan mode chains according to this
ratio, along with a 20 percent pattern inflation factor to account for compression
overhead:
num_compressed_chains = num_standard_chains * ratio * 1.2
You can use any of these options to directly or indirectly specify the scan compression ratio
for your design. If none of these options are specified, a minimum compression value of 10
is used. The maximum compressed chain count is 32000.
If you use the high X-tolerance codec architecture, the X-masking architecture places an
additional upper limit, as a function of the scan-in and scan-out pin count, on the maximum
number of compressed scan chains to ensure 100 percent X-tolerance. For more
information, see “High X-Tolerance Scan Compression” on page 4-2.
After the standard scan and compressed scan modes have been configured, you can use
the preview_dft command to see the scan architecture and test-mode signal details before
scan insertion is performed, as shown in Example 2-2.
Example 2-2 Output From the preview_dft Command for a Compressed Scan Configuration
****************************************
Current mode: Internal_scan
****************************************
Number of chains: 3
Scan methodology: full_scan
Scan style: multiplexed_flip_flop
Clock domain: mix_clocks
Scan chain '1' (test_si1 --> test_so1) contains 22 cells

Active in modes: Internal_scan



****************************************
Current mode: ScanCompression_mode
****************************************
Number of chains: 8
Clock domain: no_mix
Scan chain '1' contains 8 cells

Active in modes: ScanCompression_mode
(...omitted...)

================================
Test Mode Controller Information
================================
Test Mode Controller Ports

--------------------------
test_mode: test_mode
Test Mode Controller Index (MSB --> LSB)

----------------------------------------
test_mode
Control signal value - Test Mode

--------------------------------
0 Internal_scan - InternalTest
1 ScanCompression_mode - InternalTest
During scan insertion, the insert_dft command creates and instantiates two scan
compression designs: one for the compressor and one for the decompressor. By default, the
insert_dft command instantiates these blocks at the top level of the current design.
However, for a top-down flat run, you might want to insert the codec logic into a core-level
hierarchical block. For information on inserting the codec logic within a hierarchical instance,
see “Specifying a Location for DFT Logic Insertion” on page 5-2.
After compressed scan is inserted, you can use the report_scan_path command to see
details of the scan chains in the standard scan and compressed scan modes:
dc_shell> report_scan_path -test_mode all

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Write out test protocols for both test modes using the write_test_protocol -test_mode
command:
dc_shell> write_test_protocol -output scan.spf \
dc_shell> write_test_protocol -output scancompress.spf \
After you have the netlist and protocol files, you can generate patterns in the TetraMAX tool.
Compressed scan insertion has the following requirements:
• Compressed scan requires a preclock strobe. You should ensure that the
test_default_strobe variable is set so that the strobe occurs before the active edges
of the test clock waveforms. The default DFT Compiler test timing values meet this
requirement.
• Compressed scan insertion requires an HDL-Compiler license.
Top-Down Flat Compressed Scan Flow With Partitions

For larger designs, inserting a single top-level codec that spans multiple blocks might lead
to routing congestion or timing issues due to long routes. For these designs, you can insert
multiple codecs that provide localized scan compression for different blocks. This can be
accomplished in the following ways:
• Using a top-down flat flow, where multiple codecs are inserted at the same time during
top-level DFT insertion
• Using a bottom-up hierarchical flow, where a codec is inserted during DFT insertion for
each block, then the block-level codec signals are connected and integrated during
top-level DFT insertion
If the entire design does not fit into memory, a bottom-up hierarchical flow must be used.
The DFTMAX tool provides bottom-up hierarchical flows to reduce both routing congestion
and the number of isolation cells added to designs with multiple power domains. These flows
require you to perform bottom-up DFT insertion, which in turn requires block-level DFT
constraints, DRC checks, and well-defined hierarchical boundaries. For more information on
these bottom-up hierarchical flows, see Chapter 3, “Hierarchical Adaptive Scan Synthesis.
However, some designs cannot use a bottom-up hierarchical flow. Constraints might not be
available at block-level boundaries, or the available design hierarchy boundaries might not
provide the desired mapping of codec blocks to design logic. For these designs, you can use
the top-down flat partition flow.

Top-Down Flat Compressed Scan Flow With Partitions 2-6
A partition is a portion of the design, defined from the top level, that is assigned to its own
codec. A partition definition can be defined as a set of clock domains, design references,
hierarchical cells, or sequential leaf cells. Although partitions are usually defined along
physical or logical hierarchical boundaries, it is not a requirement. You can specify separate
codec configurations for each partition, and all codecs are inserted at the same time during
top-level DFT insertion. This top-down flat partition flow provides the same multiple codec
flexibility as the bottom-up flows, but without the need for multiple runs.
Defining and Configuring Partitions

You can use the following commands to define and manage partition definitions in your
top-level run:
• define_dft_partition
• report_dft_partition
• remove_dft_partition
You can use the define_dft_partition command to define a partition. The most
commonly used options are:
define_dft_partition
partition_name
[-include list_of_cells_or_references]
[-clocks list_of_clocks]
You must provide a unique name for each partition definition. This name is used to reference
the partition when providing codec information, as well as to identify the partition in
subsequent DFT reports.
A partition can be defined as a set of cells or design references with the -include option.
Leaf cells can be specified, although only sequential cells are relevant to the partition
definition. Design references are converted to the set of all hierarchical instances of those
designs. A particular cell or design reference can exist in only one partition definition. In
Example 2-3, two partitions are defined using hierarchical cells, and a third partition is
defined using a design reference.
Example 2-3 Defining Three Partitions Using Cells and References
define_dft_partition P1 -include [get_cells {U_SMALL_BLK1 U_SMALL_BLK2}]
define_dft_partition P2 -include [get_cells {U_BIG_BLK}]
define_dft_partition P3 -include [get_references {my_ip_design}]
A partition can also be defined to include one or more clock domains with the -clocks
option. The partition includes all flip-flops clocked by the specified clocks. In Example 2-4,
two partitions are created by clock domain.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Example 2-4 Defining Partitions By Clock Domain

define_dft_partition P1 -clocks {CLK1 CLK2}
define_dft_partition P2 -clocks {CLK3}
The tool creates a default partition named default_partition that includes the flip-flops not
included in any user-defined partitions. You cannot use the name default_partition when
defining a partition.
You can use the report_dft_partition command to see what partitions have been
defined. Example 2-5 shows the output from the report_dft_partition command for the
three partitions previously defined in Example 2-3. Note that the design reference has been
converted to the corresponding set of hierarchical instances of that design.
Example 2-5 Example of Output From the report_dft_partition Command
Cells or Designs defined in Partition 'P1':
U_SMALL_BLK1
U_SMALL_BLK2
U_BIG_BLK
U_MY_IP_BLK
You can use the remove_dft_partition command to remove one or more user-defined
partition definitions. The default partition cannot be removed.
remove_partition {P1 P2 P3}
Configuring Partition Codecs

After the partitions are defined, you can configure the test configuration for each partition.
Use the current_dft_partition command to set the current partition, then apply one or
more supported test configuration commands to configure scan for that partition, as shown
in Example 2-6.
Example 2-6 Configuring Two Codecs in a Partition Flow
set_dft_signal -view existing_dft \
-type ScanClock -timing [list 45 55] -port CLK
set_dft_signal -view spec -type TestMode -port TM
current_dft_partition P1
set_dft_signal -view spec -type ScanEnable -port SE
set_dft_signal -view spec -type ScanDataIn -port {SI1 SI2}
set_dft_signal -view spec -type ScanDataOut -port {SO1 SO2}
set_scan_configuration -chain_count 2
set_scan_compression_configuration -chain_count 4 -location BLK1

set_dft_signal -view spec -type ScanEnable -port SE
set_dft_signal -view spec -type ScanDataIn -port {SI3 SI4 SI5}
set_dft_signal -view spec -type ScanDataOut -port {SO3 SO4 SO5}
set_scan_compression_configuration -chain_count 6 -location BLK2
You can specify the standard and compressed scan mode characteristics for each partition.
Not all test configuration commands are supported in a partition flow. See “Supported DFT
Features in the Partition Flow” on page 2-14 for details.
If you are defining scan-in or scan-out signals using the set_dft_signal command, you
must define them as a part of each partition’s scan configuration. Scan-enable signals can
also be defined on a per-partition basis. However, if a scan-enable signal is defined for only
one partition, it is automatically applied to the remaining partitions. Other signal types, such
as reset, clock, and test-mode signals, should be defined globally before any partitions are
defined, or as part of the default partition configuration.
In a partition flow, codecs are still inserted at the top level of the current design by default.
You can use the set_scan_compression_configuration -location command to specify
the hierarchical block where the codec is to be inserted. For more information, see
“Specifying a Location for DFT Logic Insertion” on page 5-2.
At the top level, the total standard scan chain count is the sum of the standard scan chain
counts across all partitions. Each standard scan chain requires a dedicated scan-in and
scan-out pin, just as a top-level scan chain does in an unpartitioned flow. Scan chains in
partitions are not combined or rebalanced at the top level.
Figure 2-2 shows the standard scan mode chain connections for Example 2-6. A total of five
scan-in and scan-out pins are used, two for partition P1 and three for partition P2.
Figure 2-2 Partition Scan Chains in Standard Scan Mode
3VFDQLQV 3VFDQLQV
3 3
3VFDQRXWV 3VFDQRXWV

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
After configuring the partitions, you can use the preview_dft command to display the scan
chain distribution across partitions. Example 2-7 shows a report example.
Example 2-7 Output From the preview_dft Command for Multiple DFT Partitions
****************************************
Current mode: Internal_scan
****************************************
Number of chains: 5
Scan chain '1' (SI1 --> SO1) contains 32 cells (Partition 'P1')
Choosing a Partition Codec Insertion Method

Two different codec insertion methods are available in the partition flow.
By default, the tool creates a separate codec for each partition. The scan-in and scan-out
signals associated with each partition are used for that partition’s codec connections.
Figure 2-3 shows the dedicated codec architecture for Example 2-6 on page 2-8.
Figure 2-3 Partition Scan Chains With Dedicated Codec Architectures
3VFDQLQV 3VFDQLQV
WR WR
3 3
WR WR
3VFDQRXWV 3VFDQRXWV

For improved testability, the tool can also use a single shared codec architecture for all
partitions. This shared codec architecture is enabled by setting the following variable:
set_app_var test_enable_codec_sharing true
This shared codec architecture uses the full set of scan-in and scan-out pins across all
partitions. This codec architecture is then replicated for each partition, where only a
dedicated subset of decompressor outputs and compressor inputs is connected to the
compressed scan chains in each partition. The compressor outputs are combined using an
XOR observability tree.
Figure 2-4 shows the shared codec architecture for Example 2-6 on page 2-8. The five
scan-in and scan-out pins from the standard scan mode are used to drive the decompressor
inputs and capture the compressor outputs. Each decompressor has ten output pins,
resulting from the sum of the compressed scan chain counts across all partitions. The same
codec architecture is used in each partition, but a different range of compressor outputs and
decompressor inputs is connected for each partition. In partition P1, the first four
decompressor outputs and compressor inputs are used. In partition P2, the next six
decompressor outputs and compressor inputs are used.
Figure 2-4 Partition Scan Chains With Shared Codec Architectures
3DQG3VFDQLQV
WR WR
3 3
WR WR
3DQG3VFDQRXWV
Note:
To optimize the logic around the unconnected decompressor outputs and compressor
inputs, perform an incremental compile after DFT insertion using either the
compile_ultra -scan -incremental command or the compile -scan
-incremental -boundary_optimization command.
The shared codec architecture has testability efficiency similar to inserting a single codec in
an unpartitioned flow. Because all available scan-in and scan-out pins connect to each

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
codec, this method provides better controllability, observability, and X-tolerance to the
partitions. However, this insertion method does have some limitations:
• All scan-in and scan-out pins must be shared across all codecs.
• Multiple compressed scan modes are not supported.
• Codecs that compress OCC clock chains are not supported.
• High X-tolerance is not supported.
Supported DFT Configuration Commands for Partitions

This section lists the commands you can use to configure DFT insertion for user-defined
partitions.
set_scan_configuration
The following set_scan_configuration options can be specified on a per-partition basis:
• -chain_count
• -max_length
• -exact_length
• -clock_mixing
• -insert_terminal_lockup
• -test_mode
• -exclude_elements
• -voltage_mixing
• -power_domain_mixing
set_scan_compression_configuration
The following set_scan_compression_configuration options can be specified on a
per-partition basis:
• -minimum_compression
• -chain_count
• -max_length
• -location

• -inputs
• -outputs
• -shared_inputs
• -shared_outputs
• -identical_cores
• -scramble_identical_outputs
set_dft_signal
The following set_dft_signal options can be specified on a per-partition basis:
• -view
• -type ScanDataIn | ScanDataOut | ScanEnable
• -port
• -hookup_pin
• -hookup_sense
• -active_state
set_dft_location
The following set_dft_location test logic types can be specified on a per-partition basis
with the -include and -exclude options:
• DFTMAX
• SERIAL_REG
• PIPELINE_SI_LOGIC
• LOCKUP_LATCH
• REC_MUX
For other test logic types, you can only specify the location for the default partition.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
set_scan_path
The following set_scan_path options can be specified on a per-partition basis:
• -include_elements
• -head_elements
• -tail_elements
• -ordered_elements
• -complete
• -exact_length
• -scan_enable
• -scan_data_in
• -scan_data_out
Supported DFT Features in the Partition Flow

The following DFT features are supported in a partition flow:
• AutoFix
• User-defined test points (UDTP)
• Phase-locked loops (PLL)
• Scan compression
• Multiple test modes
• Internal pins
• Pipelined scan data
• Clock gating functionality
• Writing SCANDEF files
When you use the write_scan_def command in a partition flow, the tool appends the
partition name to the PARTITION label in the SCANDEF file. This label ensures that only
scan chains within the same partition can be swapped.

Limitations of the Partition Flow

The following limitations apply to the partition flow:
• The core wrapper feature is not supported.
• Partition-specific scan-enable signals are not supported by low-power compressor
gating, which is enabled with the set_scan_compression_configuration
-min_power true command.
Known Issues of the Partition Flow

The following known issues apply to the partition flow:
• The -include option of the set_scan_path command accepts lists of cells and design
names. The option does not accept collections.
• If you repeat the same partition name, no error or warning message is issued. The first
partition definition is honored and the rest are ignored.
• If you define a scan-enable signal for a partition, that scan-enable signal is reused for
other partitions for which the signal has not been defined. This reuse avoids having to
create new scan-enable signals.
• Mode checking is needed for the define_dft_partition command. For example, if
instances and modules are specified, the tool does not issue any error or warning
message when there is a conflict between partitions.
• The following supported commands with their partition-specific options should be used
for user-defined DFT partitions:
❍ set_scan_configuration
❍ set_scan_compression_configuration
❍ set_scan_path
❍ set_dft_signal
Other commands and options are ignored except when defined for the default partition.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Partition Script Example

The following script demonstrates the use of compressed scan with multiple design
partitions.
Example 2-8 Compressed Scan Insertion with Multiple Partitions
read_ddc ./design_test_ready.ddc
current_design block
set_dft_signal -view existing_dft -type ScanClock -timing [list 45 55] \
-port clk
define_dft_partition partition1 -include [list inst1 inst2]
current_dft_partition partition1
set_scan_compression_configuration -chain_count 60 -location inst1
current_dft_partition default_partition
report_dft_partition
preview_dft -show all
insert_dft
dft_drc
write_scan_def -output ./design.scandef
write -f ddc -hierarchy -output ./scan_inserted_design.ddc
write_test_protocol -output scan.spf -test_mode internal_scan
write_test_protocol -output ascan.spf -test_mode ScanCompression_mode
Scan Compression and Multiple Test Modes

When you insert compressed scan into your design, the tool creates two test modes by
default:
• A compressed scan mode
The default name for this test mode is ScanCompression_mode.
• A standard scan mode
The default name for this test mode is Internal_scan.
Just as you can create multiple standard scan modes with the DFT Compiler tool, you can
also create multiple compressed scan modes with the DFTMAX tool. This capability uses
the same multiple test-mode creation, configuration, and reporting commands as used with

Scan Compression and Multiple Test Modes 2-16
multiple standard scan modes. For more information, see “Multiple Test Modes” in the DFT
Compiler Scan User Guide.
Usage of multiple compressed scan modes is described in the following subsections:
• Defining Multiple Compressed Scan Modes
• Supported Compressed Scan Specification Commands
• Multiple Test-Mode Script Examples
Defining Multiple Compressed Scan Modes

Use the -usage option of the define_test_mode command to specify the type of scan to be
inserted in each mode. In Example 2-9, two standard scan modes and two compressed
scan modes are defined.
Example 2-9 Defining Multiple Standard Scan and Compressed Scan Modes
define_test_mode STDSCAN1 -usage scan
define_test_mode STDSCAN2 -usage scan
define_test_mode COMPSCAN1 -usage scan_compression
define_test_mode COMPSCAN2 -usage scan_compression
You can optionally define the test-mode signals and test signal encodings that activate each
of these modes. For more information, see “Defining the Encoding of a Test Mode” in the
DFT Compiler Scan User Guide.
When you use the default compressed scan mode for scan insertion, the accompanying
standard scan mode is always considered to be the base mode. There is no need to
explicitly specify this base mode relationship when a single compressed scan mode is
inserted. When you define multiple compressed scan modes, each compressed scan mode
must have an associated standard scan base mode.
After defining the compressed scan and standard scan test modes, you must also specify
the accompanying base mode relationships for each compressed scan mode. You define
these relationships with the -base_mode option of the
set_scan_compression_configuration command. In Example 2-10, two compressed
scan modes are paired with their standard scan base modes.
Example 2-10 Providing Base Mode Relationships for Compressed Scan Modes
set_scan_configuration -test_mode STDSCAN1 -chain_count 2
set_scan_configuration -test_mode STDSCAN2 -chain_count 3
set_scan_compression_configuration -test_mode COMPSCAN1 \
-base_mode STDSCAN1 -chain_count 4
-base_mode STDSCAN2 -chain_count 5

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Although each compressed scan mode must have a corresponding base mode, there is no
complementary requirement. You can create as many additional standard scan modes as
needed.
Multiple compressed scan modes can share a common base mode. Define the common
base mode with the set_scan_configuration command, then reference this base mode
using the -base_mode option of each set_scan_compression_configuration command:
Example 2-11 Sharing a Base Mode Relationships Across Multiple Compressed Scan Modes
set_scan_configuration -test_mode STDSCAN -chain_count 2
-base_mode STDSCAN -chain_count 4
-base_mode STDSCAN -chain_count 5
For multiple compressed scan modes, the same relationship exists between each
compressed scan mode and its corresponding base mode as with a single compressed
scan mode and standard scan mode. By default, each compressed scan mode uses all
available scan-in and scan-out pins from its base mode. In Example 2-10, compressed
mode COMPSCAN1 creates a decompressor with two inputs, and compressed mode
COMPSCAN2 creates a decompressor with three inputs.
If you want to use a different number of scan-in or scan-out pins in a compressed scan mode
from what is used in its base mode, you can use the -inputs and -outputs options of the
set_scan_compression_configuration command. For more information, see “Specifying
a Different Scan Pin Count for Compressed Scan Mode” on page 2-28.
The insert_dft command inserts a separate codec for each compressed scan mode. This
is true even if the codec architectures between two compressed scan modes are identical.
Scan chain reconfiguration MUXs are added to provide the necessary scan chain paths for
all standard scan and compressed scan modes. Additional MUX logic is added to enable
one codec at a time based on the test-mode signal decoding logic. Figure 2-5 shows how
the scan compression codecs in Example 2-10 are connected.

Figure 2-5 Multiple Codecs for Multiple Compressed Scan Modes

7HVWPRGH&2036&$1 7HVWPRGH&2036&$1
6FDQLQV 6FDQLQV
WR WR WR WR
WR WR WR WR
6FDQRXWV 6FDQRXWV
Supported Compressed Scan Specification Commands

This section lists the commands and options you can use to configure compressed scan
insertion for specific test modes. Additional commands are available to configure other
aspects of DFT insertion for multiple test modes. For more information, see the “Supported
Test Specification Commands for Test Modes” section in the DFT Compiler Scan User
Guide.
The following set_scan_compression_configuration options can be applied to specific
test modes:
• -base_mode
• -max_length
• -chain_count
• -minimum_compression
• -inputs
• -outputs
• -shared_inputs

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
• -shared_outputs
• -identical_cores
• -scramble_identical_outputs
• -synchronize_chains
Note:
Although the set_scan_compression_configuration command applies to the current
test mode by default, the -test_mode option is typically used together with the
-base_mode option so that the relationship between the test mode and base mode is
explicitly highlighted.
set_scan_path
Use the set_scan_path -test_mode test_mode_name command to provide scan chain
specifications for each test mode in your design. The scan path specification can be given
for any chains in any defined test mode and can include scan data in and scan data out pin
specifications, with both port and hookup arguments. If the scan path specification applies
to a test mode which has the usage specified as scan_compression, then the scan path
statements can use the -hookup option to specify compressed chains, but they cannot use
a port argument.
Multiple Test-Mode Script Examples

This section provides examples of multiple test-mode scripts.
Multiple Standard Scan Modes and One Compressed Scan Mode

The following script example demonstrates multiple standard scan modes and a single
compressed scan mode.
Example 2-12 Multiple Standard Scan Modes and One Compressed Scan Mode
## Define the scan in and scan out pins, which will be used in
## all test modes.
## These modes are my_base1,scan_compression1, and burn_in.
for {set i 1} {$i <= 13 } { incr i 1} {
create_port -direction in test_si[$i]
create_port -direction out test_so[$i]
set_dft_signal -type ScanDataIn -view spec \
-port test_si[$i] -test_mode all
set_dft_signal -type ScanDataOut -view spec \
-port test_so[$i] -test_mode all
}
# Define Test Clocks

set_dft_signal -view existing_dft -type TestClock -timing {45 55} \

-port clk_st
# Define TestMode signals to be used

set_dft_signal -view spec -type TestMode \
-port [list i_trdy_de i_trdy_dd i_cs]
# Define the test modes, usage and encoding

define_test_mode my_base1 -usage scan \
-encoding {i_trdy_de 0 i_trdy_dd 0 i_cs 1}
define_test_mode burn_in -usage scan \
define_test_mode scan_compression1 -usage scan_compression \
# Enable DFTMAX
# Configure DFTMAX
set_scan_compression_configuration -base_mode my_base1 -chain_count 32 \
-test_mode scan_compression1 -xtolerance high
# Configure the basic scan modes

set_scan_configuration -chain_count 4 -test_mode my_base1
set_scan_configuration -chain_count 1 -clock_mixing mix_clocks \
-test_mode burn_in
# Enable rapid scan stitching feature

set_dft_insertion_configuration -synthesis_optimization none
## Give a chain spec to be applied in my_base1

## This will also define the scan ports for scan_compression1
set_scan_path chain1 -view spec -scan_data_in test_si[1] \
-scan_data_out test_so[1] -test_mode my_base1
## Give a chain spec to be applied in burn_in

-scan_data_out test_so[13] -test_mode burn_in
## Create the test protocol

# Run pre-DFT DRC

dft_drc
## Preview test structures to be inserted


DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
## Run test insertion

insert_dft
# run post-DFT DRC in scan_compression1 test mode

current_test_mode scan_compression1
report_dft_signal
dft_drc -verbose
# run post-DFT DRC in my_base1 test mode

current_test_mode my_base1
report_dft_signal
dft_drc -verbose
# run post-DFT DRC in burn_in test mode

current_test_mode burn_in
report_dft_signal
dft_drc -verbose

write -format verilog -hierarchy -output vg/top_scan_mm.v
write_test_protocol -test_mode scan_compression1 \
-output stil/scan_compression1.stil \
-names verilog stil/scan_compression2.stil -names verilog
write_test_protocol -test_mode my_base1 -output stil/my_base1.stil \
-names verilog
write_test_protocol -test_mode burn_in -output stil/burn_in.stil \
-names verilog
Multiple Standard Scan and Compressed Scan Modes

The following script example demonstrates multiple standard scan modes and multiple
compressed scan modes.
Example 2-13 Multiple Standard Scan Modes and Multiple Compressed Scan Modes
## Define the scan in and scan out pins, which will be used in
## all test modes.
## These modes are my_base1, my_base2, scan_compression1,
## scan_compression2, and burn_in.
for {set i 1} {$i <= 13 } { incr i 1} {
set_dft_signal -type ScanDataIn -view spec \
-port test_si[$i] -test_mode all
set_dft_signal -type ScanDataOut -view spec \
-port test_so[$i] -test_mode all
}
# Define Test Clocks

-port clk_st


-port [list i_trdy_de i_trdy_dd i_cs]
# Define the test modes and usage

# Enable DFTMAX
# Configure DFTMAX

-test_mode burn_in



DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4

## Give a chain spec to be applied in burn_in

-scan_data_out test_so[13] -test_mode burn_in
## Create test protocol

## Run pre-DFT DRC

dft_drc


insert_dft
report_dft_signal
dft_drc -verbose
report_dft_signal
dft_drc -verbose
report_dft_signal
dft_drc -verbose
report_dft_signal
dft_drc -verbose
report_dft_signal
dft_drc -verbose

write -format verilog -hierarchy -output vg/top_scan_mm.v
-output stil/scan_compression1.stil -names verilog
-output stil/scan_compression2.stil -names verilog


-names verilog
-names verilog
write_test_protocol -test_mode burn_in -output stil/burn_in.stil \
-names verilog
Standard Scan Flow Using Multiple Test Modes and Partitions

The following script example demonstrates multiple standard scan modes and partitions.
This example does not insert compressed scan.
Example 2-14 Multiple Standard Scan Modes With Partitions
-timing [list 45 55] -port clk
define_test_mode test_mode1 -usage scan


current_dft_partition part1
set_scan_configuration -exact_length 40 -test_mode test_mode1
insert_dft
dft_drc

write -format ddc -hierarchy -output ./scan_inserted_design.ddc
write_test_protocol -output test_mode1.spf -test_mode test_mode1
write_test_protocol -output test_mode2.spf -test_mode test_mode2

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Scan Compression Flow Using Multiple Test Modes and Partitions

The following script example demonstrates a single compressed scan mode, multiple
standard scan modes, and partitions:
Example 2-15 Standard Scan and Compressed Scan Modes With Partitions
define_test_mode my_scan_comp -usage scan_compression


set_scan_configuration -chain_count 4 -test_mode test_mode1
set_scan_compression_configuration -location inst1 \
-test_mode my_scan_comp -base_mode test_mode1
insert_dft
dft_drc
write -f ddc -hierarchy -output ./scan_inserted_design.ddc
write_test_protocol -output scan.spf -test_mode test_mode1
write_test_protocol -output ascan.spf -test_mode my_scan_comp

Scan Compression and OCC Controllers

OCC controllers allow on-chip clock sources to be used for at-speed capture during device
testing. In an OCC controller flow, the clock chain is a special scan segment that provides
control over the at-speed capture pulse sequence generated by the OCC controller.
When you insert scan compression in a DFT-inserted or user-defined OCC controller flow,
the clock chain is placed between the decompressor and compressor. The decompressor
drives the clock chain along with the other compressed scan chains, but it dedicates a
decompressor scan input to the clock chain as shown in Figure 2-6.
Figure 2-6 Compressed Clock Chain in a Compressed Scan Design
'HGLFDWHGGHFRPSUHVVRUVFDQLQSXW
2&&
FRQWUROOHU
&RPSUHVVHG
FORFNFKDLQ
The decompressor scan input path passes through the decompressor to the clock chain
input. This allows the clock chain values to be controlled without imposing constraints on
other scan cells. Such a clock chain is called a compressed clock chain because it exists
between the decompressor and compressor, even though it is driven by a dedicated scan-in
signal as if it was uncompressed.
Note:
For codecs with few scan inputs and high compression ratios, DFTMAX compression
might be forced to share the decompressor scan input with other compressed chains.
This happens if the codec would otherwise not be implementable.
The dedicated scan-in signal reduces the number of scan-in signals available for data
decompression into the remaining compressed chains. You should consider this when
determining compression architecture parameters such as scan input count and
compressed chain count.
The clock chain, which is clocked on the trailing edge, is always placed at the beginning of
its compressed scan chain. Additional scan cells can follow the clock chain for
length-balancing purposes, as allowed by the clock-mixing settings applied to the current
design. The compressed scan chain then proceeds into the compressor in the normal way.

Scan Compression and OCC Controllers 2-27
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
If you are using the high X-tolerance feature, the compressed clock chain reduces the
maximum compressed scan chain limit that can be created for a given number of scan-in
signals. For more information, see “Scan-In and Scan-Out Requirements” on page 4-4.
You can use the preview_dft -show {cells scan_clocks} command to see which
compressed scan chain contains the clock chain. The clock chain is marked with a clock
chain segment attribute (o) and a scan segment attribute (s):
****************************************
****************************************
Number of chains: 16
(l) shows cell scan-out drives a lockup latch

(s) shows cell is a scan segment
(m) shows cell scan-out drives a multi-mode multiplexer
(o) shows cell is a clock chain segment
(w) shows cell scan-out drives a wire

Active in modes: ScanCompression_mode :
snps_clk_chain_0/clock_chain (s) (o) (UPLL/CLKO, 55.0, falling)

Z1_reg[0] (UPLL/CLKO, 45.0, rising)
Z1_reg[1]
Z1_reg[2] (m)
For more information on OCC controllers, see the “On-Chip Clocking Support” chapter of the
DFT Compiler Scan User Guide.
Specifying a Different Scan Pin Count for Compressed Scan Mode

In a compressed scan mode, the decompressor inputs are driven by scan-in pins and the
compressor outputs drive scan-out pins. By default, DFTMAX compression uses the full set
of scan-in and scan-out pins from the associated base mode for the scan compression
codec construction as shown in Figure 2-1 on page 2-3. If you want to use a different
number of scan-in and scan-out pins for the codec construction, you can use the -inputs
and -outputs options of the set_scan_compression_configuration command.
Figure 2-7 shows the codec architecture created by the -inputs and -outputs options in
Example 2-16.
Example 2-16 Specifying a Different Compressed Scan Pin Configuration
set_scan_compression_configuration -chain_count 8 -inputs 4 -outputs 4

Specifying a Different Scan Pin Count for Compressed Scan Mode 2-28
Figure 2-7 Different Compressed Scan Pin Codec Architecture

6WDQGDUGVFDQPRGH &RPSUHVVHGVFDQPRGH
6FDQLQV 6FDQLQV
WR
WHVWBPRGH WHVWBPRGH
WR
6FDQRXWV 6FDQRXWV
You can use any number or scan-in and scan-out pin connections for a compressed scan
mode relative to the chain count of its base mode. The only requirement is that the scan-in
pin and scan-out pin counts are less than the compressed scan chain count.
You can also use the -inputs and -outputs options to specify asymmetrical scan I/O
configurations for scan compression, where the number of scan-in pins differs from the
number of scan-out pins, as shown in Example 2-17.
Example 2-17 Specifying an Asymmetrical Scan Pin Configuration
The minimum number of scan-in and scan-out pins for a compressed scan mode is
• One scan-in and one scan-out pin when default X-tolerance is used
set_scan_compression_configuration \
-xtolerance default -inputs 1 -outputs 1
• Two scan-in pins and one scan-out pin when high X-tolerance is used
-xtolerance high -inputs 2 -outputs 1
Adding Compressed Chain Lock-Up Latches

Shift speeds are limited by the ability to propagate data between an I/O pad cell and the
compressed scan chains. The MUX and XOR gates that are introduced in compressed scan
can add further delay to the scan paths at the scan-in and scan-out paths, respectively.
Because of the one-to-many relationship of compressed scan chains to scan I/Os, it is

Adding Compressed Chain Lock-Up Latches 2-29
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
possible for leading-edge and trailing-edge scan cells to share the same scan input or output
port, as shown in Figure 2-8. In these cases, the resulting mix of launch and capture clock
edges reduces the usable clock period.
Figure 2-8 Compressed Scan Chains With Multiple Edge Polarities
/( /HDGLQJHGJHWULJJHUHGIOLSIORS
/( 7( /(
7( 7UDLOLQJHGJHWULJJHUHGIOLSIORS
This mixed-edge penalty against shift frequency in compressed scan mode can be avoided
by using lock-up latches at the start or end of the leading-edge or trailing-edge compressed
chains, respectively. By selectively inserting lock-up latches at the end or start of the
compressed chains, the output and input flip-flops are synchronized to the same clock edge.
The inputs of the scan chains are always synchronized to the trailing edge, and the outputs
of the scan chains to the leading edge.
To synchronize the scan chains, use the following command:
-synchronize_chains head | tail | all | none
You can specify the following values for the -synchronize_chains option:
• head synchronizes the first shift state of all compressed scan chains to the trailing clock
edge.
• tail synchronizes the last shift state of all compressed scan chains to the leading clock
edge.
• all synchronizes the first and last shift states of all compressed scan chains.
• none does not add lock-up latches to the ends of compressed scan chains for
synchronization. This is the default.
Figure 2-9 shows how the previous scan compression logic is created when the
-synchronize_chains all option is used.

Adding Compressed Chain Lock-Up Latches 2-30
Figure 2-9 Compressed Scan Chains With Multiple Edge Polarities and Synchronization
/( /HDGLQJHGJHWULJJHUHGIOLSIORS
7( 7(
7( 7UDLOLQJHGJHWULJJHUHGIOLSIORS
/( 7( /(
/( /( /HDGLQJHGJHORFNXSODWFK
7( 7UDLOLQJHGJHORFNXSODWFK
Note the following restrictions and behaviors:

• Only scan chains coming from the compressor-decompressor are synchronized. All
other chains, such as user-defined logic chains and phase-locked loop (PLL) chains, are
ignored during synchronization.
• Because the inserted lock-up latches are bypassed in standard scan mode, a C3
violation is reported for these latches during standard scan mode DRC.
C3 Clock PI's off state failed to allow transparency of nonscan DLAT S
• The synchronization specification is ignored if you use any of the following features:
❍ set_scan_configuration -add_test_retiming_flops
❍ set_scan_configuration -insert_terminal_lockup true
❍ Pipelined scan data
Applying Low-Power Gating to the Output Compressor

In a compressed scan architecture, an XOR compression tree combines the shift outputs
from all compressed chains into a reduced set of scan out data signals. This XOR
compression tree is needed only during scan shifting in the compressed scan mode. At
other times, the compression logic is not needed, but it might still toggle as the final scan
flip-flops of the compressed chains toggle. The tool can insert gating at the inputs to the
XOR compression tree to eliminate this toggling activity and reduce power consumption in
other modes of operation.
You can enable output compressor gating by specifying:
dc_shell> set_scan_compression_configuration -min_power true

Applying Low-Power Gating to the Output Compressor 2-31
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
When you enable output compressor gating, the tool inserts gating at the inputs to the XOR
compression tree as shown in Figure 2-10. Every compressor input is AND-gated with an
active-low pwr_save_n signal before going to the XOR tree.
Figure 2-10 Example of a Default X-Tolerant Compressor With Gated Inputs
SZUBVDYHBQ
The pwr_save_n gating signal is generated by combining the scan-enable signal and the
decoded test-mode vector signal as shown in Figure 2-11. By generating this gating signal
from the existing test-mode and scan-enable signals, no additional dedicated control signal
is required at the block boundary. In a CTL test model flow, this also means that no update
to a block’s test model is needed when output compressor gating is added to a block.
Figure 2-11 Example of Top-Level Compressor Power Gating Control
7HVW
7HVWPRGH PRGH
SLQV GHFRGH
2QHRU ORJLF
PRUH
VLJQDOV
VFDQBHQ
SZUBVDYHBQ
Preserving Compressor Gating Cells During Optimization

When combinational gating exists at the inputs to a DFTMAX scan compression tree, it is
possible for the gate remapping algorithms to push gating cells further into the compression
tree when common terms exist in at the inputs of XOR compression gates. When the gating

Applying Low-Power Gating to the Output Compressor 2-32
cells are pushed further into the tree, toggling can occur at the upstream XOR cells, and the
power reduction effectiveness is reduced. To preserve the full power reduction benefits, logic
synthesis optimization must not move the gating cells into the compression tree.
In the .ddc flow, this is automatically handled. the tool applies the size_only attribute to the
gating cells as soon as they are created, so that optimization cannot remap the gating cell
functionality into a different gate-level structure. Because this attribute persists in a .ddc flow,
the gating cell placement and the power reduction benefits are preserved.
However, in the Verilog flow, this attribute does not persist. To get the same power-saving
benefits, run the write_script command before you write out the Verilog netlist. Extract
the commands that apply the size_only attribute to the compressor gating cells. When the
netlist is read back in, use these commands to reapply the size_only attribute to the power
gating logic.
Forcing a Compressor With Full Diagnostic Capabilities

R10 DRC violations indicate that two or more compressed scan chains share the same XOR
compression signature at the scan outputs. As a result, a single fault detected at a scan
output cannot be uniquely mapped back through the compression logic to a specific scan
chain during diagnosis. This is also called aliasing.
To force DFT insertion to implement only compressors with full diagnostic capabilities, that
is, compressors that do not have any R10 DRC violations, set the following option:
dc_shell> set_scan_compression_configuration -force_diagnosis true
Note that this option does not change how the compressor logic is built; it simply causes
DFT insertion to stop instead of complete if the compressor would have R10 DRC violations.
Table 2-1 shows the maximum number of compressed scan chains that can be built for a
given set of scan-out pins without an R10 DRC violation. Note that these limits are lower
than the maximum upper limits shown in Table 4-1 on page 4-4.
Table 2-1 Compressed Scan Chain Limits for Avoiding R10 DRC Violations
Number of scan-out Maximum number of chains

pins
2 3
3 7
4 15
5 31

Forcing a Compressor With Full Diagnostic Capabilities 2-33
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Table 2-1 Compressed Scan Chain Limits for Avoiding R10 DRC Violations (Continued)
Number of scan-out Maximum number of chains

pins
6 63
7 127
8 255
9 510
10 1012
11 1980
12 3796
13 7098
14 12910
15 22818
16 32000
If you exceed these limits when the -force_diagnosis option is set to true, DFT insertion
stops with a TEST-1603 message:
Warning: The compressor generated might have lower diagnostics precision.
(TEST-1603)
Information: Scan routing is not complete. Signals 'serial or
scan_enables' need to be routed. (TEST-899)
Information: DFT insertion was not successful. There were unrecoverable
processing errors. (TEST-211)
0
R10 violations can be issued by post-DFT DRC analysis or by TetraMAX DRC analysis. For
more information on R10 violations, see SolvNet article 036993, “What Do R10 and R11
DRC Violations Mean?”.

Forcing a Compressor With Full Diagnostic Capabilities 2-34
Excluding Scan Chains From Scan Compression

In some cases, you might need to exclude specific scan cells from scan compression by
keeping them on a separate uncompressed scan chain. Such a scan chain is called an
external chain. Figure 2-12 shows two external chains in a compressed scan design.
Figure 2-12 External Chains in a Compressed Scan Design
([WHUQDO
FKDLQV
To define an external chain, use the set_scan_path command as follows:

set_scan_path scan_chain_name
-view spec -test_mode all
-complete true -dedicated_scan_out true
-ordered_elements ordered_list
-scan_data_in port_name -scan_data_out port_name
The external chains consume connections in the scan I/O connection budget. In
compressed scan mode, the tool automatically uses the remaining scan connections for the
codec; you do not need to specify the -inputs and -outputs options of the
set_scan_compression_configuration command. The commands in Example 2-18
configure the scan structure shown in Figure 2-12.
Example 2-18 Configuring External Chains in a Compressed Scan Design
# define two external chains
set_scan_path EC1 ... ;# external chain 1
set_scan_path EC2 ... ;# external chain 2
# set standard scan chain count to 5;

# this also sets the scan I/O budget for both scan modes to 5
# codec uses remaining 3 scan I/O connections;

# you do not need to specify "-inputs 3 -outputs 3"
Note the following aspects of external chain definitions:

• The -ordered_elements option specifies the order of the scan cells in the chain. To
provide an unordered list and allow the tool to manage ordering requirements such as
clock mixing, use the -include_elements option instead.

Excluding Scan Chains From Scan Compression 2-35
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
• The -test_mode all option applies the external chain definition to both the standard
scan and compressed scan modes. To limit the definition to a specific compressed scan
mode, specify it with the -test_mode option. The specified test mode must be previously
defined with the define_test_mode command.
• The scan input and output ports must be previously defined with the set_dft_signal
command. You cannot define external scan chains that use automatically created scan
data ports.
• If you are using the pipelined scan data feature, external chains are treated the same as
other scan chains. This means,
❍ In the automatically inserted pipelined scan data flow, the tool inserts pipeline
registers around the external scan chains the same way it does with other scan
chains.
❍ In the user-defined pipelined scan data flow, you must create and define pipeline
registers with head and tail depths that match other scan chains.
Performing Congestion Optimization on Compressed Scan

Designs
As the target scan chain compression ratio increases, the number of connections between
the codec logic and compressed scan chains increases, and the number of reconfiguration
MUX connections increases. This also increases the possibility of routing congestion. The
DFTMAX tool provides congestion reduction algorithms that use Design Compiler Graphical
technology to reduce the congestion introduced by scan compression logic.
To use this feature, you must perform the initial compile with congestion optimization using
the compile_ultra -scan -congestion command.
compile_ultra -scan -congestion

# ...other DFT settings...
preview_dft
insert_dft
compile_ultra -incremental -scan -congestion
The preview_dft and insert_dft commands issue the following message:

Running Scan Compression with congestion optimization enabled.
Note:
The scan compression congestion optimization feature does not work in multiple
test-mode flows.

Performing Congestion Optimization on Compressed Scan Designs 2-36
Using AutoFix With Scan Compression

When you insert compressed scan into a design, a test-mode signal is used to enable
standard scan or compressed scan. The AutoFix feature requires a separate test-mode
signal to enable the testability fixing logic added by DFT Compiler. These test-mode signals
cannot be shared, because the AutoFix testability fixes must be activated for both values of
the compressed scan test-mode pin, that is, in both the standard scan and compressed scan
modes.
When you configure the AutoFix control signal with the -control_signal option of the
set_autofix_configuration command, specify a test-mode signal that is dedicated to
enabling the AutoFix logic. If you have not specified any test-mode encodings with the
define_test_mode -encoding command, the tool will avoid using the AutoFix control
signal when it chooses test-mode signals for the test-mode encodings. If you are specifying
your own test-mode encodings, you should avoid using the AutoFix control signal in your
encodings.
One-Pass DFTMAX Example With AutoFix

The following example performs compressed scan DFT insertion with AutoFix enabled.
Example 2-19 One-Pass DFTMAX and an AutoFix Insertion
# Define the clocks and asynchronous signals
set_dft_signal -view existing_dft -type ScanMasterClock -timing {45 55} \
-port clk_st
-port clk_st_inv
set_dft_signal -view existing_dft -type Reset -active_state 0 \
-port rst_st
# Enable DFTMAX and AutoFix for clocks, resets, sets, and buses
set_dft_configuration -scan_compression enable \
-fix_clock enable \
-fix_reset enable \
-fix_set enable \
-fix_bus enable \
-fix_bidirectional enable \
-control_points enable \
-observe_points enable
# Configure DFTMAX
set_scan_compression_configuration -minimum_compression 10 \
-xtolerance high -max_length 20
# Set the Global AutoFix settings to use data clock_autofix_clock_s

# and control TEST_MODE

Using AutoFix With Scan Compression 2-37
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4

-port clock_autofix_clock_s
set_dft_signal -view spec -type TestMode -port TEST_MODE
set_dft_signal -view spec -type TestData -port clock_autofix_clock_s
set_autofix_configuration -type clock \
-include_elements [get_object_name [get_cells -hierarchical *]] \
-control_signal TEST_MODE \
-test_data clock_autofix_clock_s
# Define the cells to fix and ports to use for clock AutoFix
-port clock_autofix_clock_sc
set_dft_signal -view spec -type TestData -port clock_autofix_clock_sc
set_autofix_element [get_object_name [get_cells dd_c/*]] -type clock \
-test_data clock_autofix_clock_sc
# Define the cells to fix and ports to use for reset AutoFix
-port reset_autofix_reset
set_autofix_element [get_object_name [get_cells -hierarchical *]] \
-type reset -control_signal TEST_MODE \
-test_data reset_autofix_reset
# Set up testpoint insertion using TEST_MODE as the mode port

# and clk_st as the testpoint clock
set_test_point_element -type force_01 -clock_signal clk_s\
-test_points_per_source_or_sink 1 {dd_c/\o_data_reg[3]/D}
set_test_point_element -type observe -clock_signal clk_st \
-test_points_per_source_or_sink 1 {dd_c/\o_data_reg[3]/Q}
# Set up port to use for DFTMAX standard scan mode

set_dft_signal -view spec -type TestMode -port TEST_COMPRESS
# Set up scan enable to use i_rd pin

set_dft_signal -view spec -type ScanEnable -port i_rd
## Create the test protocol

## Run pre-DFT DRC

dft_drc -verbose


insert_dft

One-Pass DFTMAX Example With AutoFix and Multiple Test Modes

The following script example performs compressed scan DFT insertion of multiple test
modes with AutoFix enabled.
Example 2-20 One-Pass DFTMAX and an AutoFix Insertion, Using Multiple Test Modes
read_verilog db/my_design.v
current_design top
uniquify
link
# Create ports to use as test-mode selection for test modes defined

# with define_test_mode
create_port -direction in TM1
# Test-mode ports must be defined with set_dft_signal -view spec TestMode

# before use in define_test_mode encoding
-port {TM1 TM2 TM3} -test_mode all
# Define the test modes for this design

-encoding {TM1 0 TM2 0 TM3 1}
# Define the clocks and asynchronous signals

set_dft_signal -view existing_dft -type ScanMasterClock \
-timing {45 55} -port sys_clk -test_mode all
-timing {55 45} -port sys_clk_inv -test_mode all
-port sys_reset -test_mode all
# Enable DFTMAX and AutoFix for clocks, resets, sets, and buses
set_dft_configuration -scan_compression enable \
-fix_clock enable \
-fix_reset enable \
-fix_set enable \
-fix_bus enable \
-fix_bidirectional enable \
-control_points enable \
-observe_points enable
# Configure DFTMAX and the other 2 defined test modes

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
-xtolerance high -base_mode my_base1 \
-test_mode scan_compression1
-test_mode burn_in
# Define the cells to fix and ports to use for clock AutoFix
-port clock_autofix_clock_s -test_mode all
set_dft_signal -view spec -type TestData -port clock_autofix_clock_s \
-test_mode all
set_dft_signal -view spec -type TestMode -port TEST_MODE \
-test_mode all
-type clock -control_signal TEST_MODE \
-test_data clock_autofix_clock_s
# Define the cells to fix and ports to use for reset AutoFix
-port reset_autofix_reset -test_mode all
-type reset -control_signal TEST_MODE \
-test_data reset_autofix_reset
# Set up testpoint insertion using TEST_MODE as the mode port

# and sys_clk as the testpoint clock
set_test_point_element -type force_01 -clock_signal sys_clk \
-test_points_per_source_or_sink 1 {dd_c/o_data_reg[3]/D}
set_test_point_element -type observe -clock_signal sys_clk \
-test_points_per_source_or_sink 1 {dd_c/o_data_reg[3]/Q}
# Set up scan enable to use i_rd pin

set_dft_signal -view spec -type ScanEnable -port i_rd -test_mode all
# Enable rapid scan stitching

# Create the test protocol

# Run pre-DFT DRC

dft_drc -verbose
# Preview test structures to be inserted

# Generate a report specific to AutoFix

report_autofix_configuration -type all
# Run insert_dft to insert into design

insert_dft
# List the modes inserted and report the test mode1

list_test_modes
report_test_mode1
# Run post-DFT DRC

report_dft_signal1
dft_drc -verbose
report_dft_signal
dft_drc -verbose
report_dft_signal
dft_drc -verbose
# Write test protocol for use in TetraMAX

-output stil/10x_xtol_moxie_autofix.stil -names verilog
write_test_protocol -test_mode my_base1 \
-output stil/10x_xtol_moxie.scan_autofix.stil -names verilog
# Write out the scan inserted design

write -format verilog -hierarchy \
-output vg/10x_xtol_moxie_top_scan_autofix.v
write -format ddc -hierarchy \
-output db/10x_xtol_moxie_top_scan_autofix.ddc
Running TetraMAX ATPG on Compressed Scan Designs

This section provides information on running TetraMAX ATPG on compressed scan designs,
including TetraMAX script examples.
The following topics are covered in this section:
• Using TetraMAX for Pattern Generation
• Generating Patterns
• Translating Compressed Scan Patterns to Standard Scan Mode Patterns
Using TetraMAX for Pattern Generation

After you have a netlist with scan compression logic and associated protocol files, you can
proceed to the TetraMAX tool for pattern generation.

Running TetraMAX ATPG on Compressed Scan Designs 2-41
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Compressor Structure Validation

When the DFTMAX tool writes out a STIL procedure file, it includes a CompressorStructures
section that contains information about the codecs inserted in the design. During DRC, the
TetraMAX tool extracts the compressed scan chains and validates the compressor
structures defined in the protocol file against the structure that exists in the netlist. The
TetraMAX tool provides a set of DRC rules, called R rules, for this codec validation. See
TetraMAX Online Help for documentation on R rules.
Chain Test
For a chain test, a value of 0011 is repeatedly applied to all scan input ports, shifted through
the decompressor into the scan chains, and finally observed at the scan outputs through the
compressor. Due to compression effects, the values you see on scan outputs will not be the
same as the values shifted in. TetraMAX ATPG takes these compression effects into account
when determining the expected values for a compressed scan chain test.
You can select any other chain test string to be applied by using the set atpg -chain_test
option.
Estimating Compression Results

You can use the analyze_compressors command to quickly estimate the benefits of using
adaptive scan technology on a standard scan design. The command is supported in the
TetraMAX native shell mode and the Tcl mode. The Tcl syntax is
analyze_compressors
<-NUM_Chains <d>> <-NUM_Inputs <d>> <-NUM_SCANOuts <d>> [-NODiag]
[-Verbose] -XTOLerance <Default|High>
-NUM_Chains <d>
Specify the number of internal chains you want for this analysis.
-NUM_Inputs <d>
Specify the number of scan inputs you want to use for compression
implementation.
-NUM_SCANOuts <d>
Specify the number of scan outputs you want to use for this compression
implementation.
-NODiag
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 diagnostics, which requires a
large number of scan outputs for a given number of chains.

-XTOLerance <Default|High>
This option specifies whether to perform the analysis with default
x-masking or enhanced x-masking.
You can use the analyze_compressors command to perform a what-if analysis to

determine the compression results you can achieve with adaptive scan technology. It will
allow you to run ScanCompression_mode ATPG with virtual compressors without having to
go through the DFT insertion process to add compressors to your design.
The analyze_compressors command reports the estimated data volume and test volume
reductions you can achieve. These estimates assume that you have exactly the same
coverage and pattern count in standard scan ATPG as in compressed scan ATPG. You also
get an estimate of the number of gates per chain required to create the compressors you
have chosen. You will need to run standard scan ATPG separately to obtain a truly accurate
comparison.
The analyze_compressors command uses the following equations for the test cycle
reduction and test volume reduction estimates:
Cycle reduction per pattern =
(length of longest scan chain in scan mode) /
(length of longest scan chain in scan compression mode)
Scan Test Data Volume =

3 * (length of longest scan chain in scan mode) *
(number of scan chains in scan mode)
Data Reduction per Pattern =

(Scan Test Data Volume per pattern) /
(Scan Compression Test Data Volume per pattern)
The output of the TetraMAX analyze_compressors command includes

• Data reduction per pattern
• Cycle reduction per pattern
• Compressor area overhead per compressed chain: 9.0 equivalent 2-input NAND gates
For analysis purposes, you can specify the number of scan inputs, scan outputs, chain
count, and whether you want to use a compressor with the diagnostic capability. In verbose
mode, detailed information on the compressor and decompressor being used for analysis is
reported.
You can run this analysis only after you run standard scan DRC. You cannot run it after
compressed scan DRC. Note that for analysis purposes, you can specify any number of
scan inputs, scan outputs and chains if they satisfy the scan architecture requirements for
compressed scan insertion.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Data Volume and Test Application Time Reduction Calculations

The equations for calculating data volume and test application time reduction are as follows:
Test Data Volume Reduction =
(Scan Test Data Volume)/
(Scan Compression Test Data Volume)
Test Application Time Reduction =

(scan mode test application time)/
(ScanCompression_mode test application time)
Test Data Volume Calculations

The following information is stored on the tester in each test cycle:
• Forced value on input (signal or clock waveform)
• Value expected on output (strobed output)
• Whether output value should be strobed or not (output mask)
Therefore, on every output, there are two bits of information per cycle. In the following two
equations, this accounts for the factor of 3 in the scan-test-data-volume equation and the
factor of 2 in the scan-compression-test-data-volume equation. The compression calculation
is written differently because it is no longer the number of chains but rather the number of
inputs and outputs to the compression logic.
The test data volume reduction equation can be expanded by using the following formulas:
Scan Test Data Volume =
3*(length of the longest Scan mode scan chain)*
(number of scan chains in Scan mode)*
(number of Scan mode patterns)
Scan Compression Test Data Volume =
(length of longest ScanCompression_mode scan chain)*
(number of scan_in + 2*(number of scan_out))*
(number of patterns)
The test data volume might not match the memory used by the tester because each ATE
uses the test data volume in a different way. However, the tester can optimize the memory
content. It can allocate memory differently, depending on the brand or version of the tester
and the channels and cycles used. In such cases, the factors 2 and 3 in the
scan-test-data-volume and scan-compression-test-data volume formulas, respectively,
might not match the data in the tester memory.
The following ratio indicates the test data volume reduction that can be achieved:
Test Data Volume Reduction =
(Scan Test Data Volume)/
(Scan Compression Test Data Volume)

The test data volume reduction value calculated with this formula is just an estimate of the
improvements you can get by using compression.
Test Application Time Calculations

The test application time reduction is an estimate for the improvements you can achieve by
using compression and is obtained by taking the ratio of scan versus scan-compression
test-application time.
The test-application-time-reduction equation can be expanded by using the following
formulas:
Scan Test Application Time =
(longest chain in Scan mode)*
(number of patterns in Scan mode)
Scan Compression Test Application Time =

(longest scan chain in ScanCompression_mode)*
(number of patterns in ScanCompression_mode)
The test application time reduction that can be achieved is

(scan mode test application time)/
(scanCompression_mode test application time)
Expanding this equation, using the previous test application time equations for scan and
scan compression, gives
((longest chain in Scan mode)*
(number of patterns in Scan mode))/
((longest scan chain in ScanCompression_mode)*
(number of patterns in ScanCompression_mode))
Pattern Validation
Both serial and parallel versions of a regular Verilog testbench and a Verilog direct pattern
validation (DPV) testbench are supported. Note that serial patterns pass through the
compressor and decompressor, whereas the parallel patterns directly control and observe
the scan cells.
Pattern Formats
Scan compression mode patterns can be written out in the following formats:
• Binary
• Standard Test Interface Language (STIL) (serial and parallel)

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
• Waveform Generation Language (WGL)

• Verilog (serial and parallel)
Scan compression mode patterns can be read back for the following formats:
• Binary
• STIL—serial
Generating Patterns
This section provides script examples for generating patterns in scan compression mode
and standard scan mode. The two script examples are the same except for the input and
output file names. The run drc command generates compressed or standard scan patterns
based on the contents of the STIL procedure file used as input.
Generating Patterns in Compressed Scan Mode

The script in Example 2-21 generates patterns in compressed scan mode.
Example 2-21 Script for Generating Patterns in Compressed Scan Mode
set_messages -log scancompress.log -replace
# read libraries and netlist

read_netlist libs/tmax_libs/*.v -library
read_netlist design.v
run_build_model top
# run DRC in ScanCompression_mode

run_drc scancompress.spf
set_faults -model stuck

add_faults -all
run_atpg -auto_compression
write_patterns pat_compr.v -format verilog_single -parallel
Generating Patterns in Standard Scan Mode

The script in Example 2-22 generates patterns in standard scan mode.

Example 2-22 Script for Generating Patterns in Standard Scan Mode

set_messages -log scan.log -replace

read_netlist design.v
run_build_model top
# run DRC in Internal_scan mode

run_drc scan.spf

add_faults -all
write_patterns pat_scan.v -format verilog_single -parallel
Translating Compressed Scan Patterns to Standard Scan Mode

Patterns
You can use the TetraMAX tool to convert compressed scan mode patterns to standard scan
mode patterns.
The translation is performed by writing out a netlist-independent version of the pattern in
binary format along with the normal compressed scan pattern set. The netlist-independent
pattern file contains a mapping of the scan cells and primary inputs to their ATPG-generated
values. This pattern set can be read back into the TetraMAX tool after the design is placed
into reconfigured standard scan mode by reading the standard scan mode SPF. After the
patterns are read back in, a simulation is performed internally to compute the standard scan
expected values. The resulting internal patterns can then be written out for the tester to be
used in reconfigured scan mode for diagnosis.
This translation flow applies to normal compressed scan mode patterns, and parallel mode
and serial mode patterns from designs with serialized scan compression.
To use this pattern translation flow, perform the following steps:
1. Read in the design and apply the compressed scan SPF.
# read in design
run_build_model ...
# read SPF for compressed scan mode

run_drc scan_compression.spf

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
2. Create test patterns, and write them out in binary format for diagnostics.
# create patterns
# write out binary compressed scan mode patterns for diagnostics

write_patterns compressed_pat.bin -format binary
3. Write out the patterns in the netlist-independent pattern format for translation.
# write netlist-independent patterns that can be translated
set_patterns -netlist_independent
write_patterns compressed_pat_net_ind.bin
4. In a new TetraMAX run, read in the design and apply the standard scan SPF.
# read in design
run_build_model ...
# read SPF for standard scan mode
run_drc standard_scan.spf
5. Read in the netlist-independent pattern file.

# read_netlist-independent patterns
set_patterns external compressed_pat_net_ind.bin
6. Optionally, run simulation to confirm that the patterns pass.

# optional sanity check to verify that simulation passes
run_simulation
7. Write out the translated standard scan patterns in binary format for diagnostics.
# write out translated patterns in binary format for diagnostics
write_patterns scan_pat.bin -external -format binary
8. Write out the patterns in the required output format for the tester.
# write out translated patterns in binary format for diagnostics
write_patterns scan_pat.pats -external -format tester_format
The following limitations apply when translating compressed scan patterns to standard scan
patterns:
• You cannot translate standard scan patterns back into compressed scan patterns.
• Pattern translation supports only Basic-Scan and Fast-Sequential patterns. This
limitation is similar to diagnosis.
• Scan logic configuration differences between the compressed scan mode and the
standard scan mode might result in slightly different coverage numbers.

• Netlist-independent patterns are stored in multiples of 200, as shown in the following

example:
BUILD-T> set_patterns -netlist_independent
TEST-T> write_patterns pats.bin -format binary -serial -replace
200 netlist independent patterns were stored, CPU_time=0.00
400 netlist independent patterns were stored, CPU_time=0.00
End writing file 'pats.bin' with 426 patterns, File_size = 1047744,
CPU_time = 0.0 sec.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4

3
Hierarchical Adaptive Scan Synthesis 3
This chapter explains how to run hierarchical adaptive scan synthesis flows. It also
describes how to integrate compressed scan cores, standard scan cores, and test-ready,
top-level, sequential user-defined logic.
In the hierarchical adaptive scan synthesis (HASS) flow, scan compression logic is placed at
the block level, and all cores with scan compression logic are integrated at the chip level.
This approach helps reduce the routing congestion prevalent in multimillion-gate designs.
The Hybrid flow is an extension of the HASS flow that provides additional support for
compressed scan insertion for user-defined logic. A normal HASS flow supports insertion of
standard scan chains for user-defined logic, and the Hybrid flow supports insertion of
compressed scan for user-defined logic.
This chapter includes the following sections:
• The HSS Flow
• The HASS Flow
• The Hybrid Flow
• Generating Patterns in TetraMAX
• Top-Level Integration Script Examples
• Limitations
3-1
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
The HSS Flow

You can use the hierarchical scan synthesis (HSS) flow to insert scan when one or more
standard scan cores are present. The compressed scan HSS flow is similar to the standard
scan HSS flow described in Chapter 1 of the DFT Compiler Scan User Guide, except that
scan compression is added around standard scan cores at the top level.
When the DFTMAX tool inserts scan compression in the HSS flow, it applies compression
to standard scan cores as well as top-level logic. Scan chains inside standard scan cores
are treated as scan segments.
Figure 3-1 shows an example of a compressed scan HSS flow.
Figure 3-1 The Compressed Scan HSS Flow
6B&25( 6B&25( */8(
The following logic types are supported in the compressed scan HSS flow:
• Standard scan cores
These cores can be represented by the full netlist or a CTL test model. The DFTMAX tool
incorporates the core-level scan chains into scan compression as scan chain segments.
These scan chain segments can be concatenated and rebalanced inside the codec as
needed, but they cannot be subdivided into smaller scan chains.
• Test-ready cores that are scan-replaced, but do not yet have scan chains
The tool incorporates the test-ready logic into scan compression, creating compressed
scan chains as needed to meet the scan chain requirements.
• Cores that have not yet been scan-replaced
The tool performs scan replacement before applying scan compression.
• Top-level glue logic that might or might not be test-ready
The tool performs scan replacement if needed, then it applies scan compression.
Chapter 3: Hierarchical Adaptive Scan Synthesis

The HSS Flow 3-2
The compressed scan HSS flow is automatically applied whenever one or more standard
scan cores are present and scan compression is enabled with the set_dft_configuration
command:
You do not need to specify any additional integration options with the
set_scan_compression_configuration command to enable the compressed scan HSS
flow.
The HASS Flow

Sometimes a design is too large for scan compression to be inserted using a top-down flat
or HSS flow. Or, a design might include some reused compressed scan cores. In these
cases, a bottom-up hierarchical flow is needed to assemble compressed scan cores at the
top level and perform core integration.
You can use the hierarchical adaptive scan synthesis (HASS) flow to perform top-level core
integration with one or more compressed scan cores. The HASS flow is similar to the
hierarchical scan synthesis (HSS) flow described in Chapter 1 of the DFT Compiler Scan
User Guide, except that the HASS flow adds support for compressed scan cores.
Figure 3-2 shows an example of the HASS integration flow.
Figure 3-2 HASS Integration of a Compressed Scan Core
&B&25( &B&25(
In the HASS flow, no scan compression logic is added at the top level. The DFTMAX tool
promotes the scan connections of the compressed scan cores to top-level scan
connections.
A compressed scan core contains scan chain logic that can operate in both standard scan
and compressed scan modes. A standard scan core contains scan chains that only operate
in standard scan mode. When a mix of compressed scan and standard scan cores are
integrated at the top level in the HASS flow, the test modes operate as follows:
• In standard scan mode, all cores operate in their standard scan modes.
• In compressed scan mode, compressed scan cores operate in their compressed scan
mode, while the standard scan cores continue to operate in standard scan mode.

The HASS Flow 3-3
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Preparing Cores in the HASS Flow

In the HASS flow, at least one top-level compressed scan core is required for top-level
integration. Additional cores, containing compressed scan or standard scan logic, can also
be provided.
Example 3-1 shows a typical compressed scan insertion script used in the HASS flow.
Example 3-1 Typical Core-Level Compressed Scan Insertion Script
read_ddc core1_test_ready.ddc
current_design core1
set_dft_signal -view existing_dft -port CLK -type \
ScanClock -timing {45 55}
dft_drc
preview_dft
insert_dft
current_test_mode Internal_scan
dft_drc
current_test_mode ScanCompression_mode
dft_drc
write -format ddc -hierarchy -output core1.ddc

write_test_model -format ddc -output core1.ctlddc
write -format verilog -hierarchy -output core1.v
Note:
The HASS flow does not support cores with multiple user-defined test modes.
Each core must have CTL test model information so that HASS can perform top-level
integration. If the block is smaller and will fit in memory during top-level integration, you can
use the write command to write a design .ddc file that contains the full design netlist as well
as the CTL test model information:
dc_shell> write -format ddc -hierarchy -output design_name.ddc
If the block is larger, you can use the write_test_model command to write out a
test-model-only .ddc file that contains the CTL test model, along with an interface-only
representation of the core that allows the test model to be linked at the top level:
dc_shell> write_test_model -format ddc -output design_name.ctlddc
You can use either format for standard scan and compressed scan cores in the HASS flow.

The HASS Flow 3-4
HASS Integration of Compressed Scan Cores

To enable the HASS flow at the top level, use the following commands:
dc_shell> set_scan_compression_configuration -integration_only true
The first command enables scan compression, and the second command enables the
HASS flow.
The HASS flow does not concatenate or rebalance the scan chain connections of
compressed scan cores at the top level. Each core-level scan chain is promoted to a
top-level scan chain with dedicated scan pin connections in both the standard scan and
compressed scan modes. The top-level scan count, and therefore the scan pin budget, is
determined by the number of scan chains in the compressed scan cores.
Figure 3-3 shows the results from the HASS flow when three compressed scan cores are
present. All eight codec connections are promoted to eight top-level scan-in and scan-out
connections. No other scan chain count is possible.
Figure 3-3 HASS Integration of Three Compressed Scan Cores
&B&25( &B&25( &B&25(
If you issue a set_scan_configuration -chain_count command requesting fewer scan

chains, the preview_dft and insert_dft commands issue the following warning:
Warning: Cells with 8 new incompatible clock domains have not been
assigned to scan chains. Cannot honor -chain_count specification of 7.
Try using set_scan_configuration -clock_mixing mix_edges or -clock_mixing
mix_clocks. (TEST-355)
If you issue a set_scan_configuration -chain_count command requesting more scan

chains, the preview_dft and insert_dft commands issue the following warning:
Warning: Only 8 scan chain elements are free. Cannot honor -chain_count
specification of 9. (TEST-348)
When only compressed scan cores exist, you do not need to specify a chain count with the
set_scan_configuration -chain_count command. However, you can specify the
expected chain count so that the tool verifies the actual number of scan chains against the
expected number.

The HASS Flow 3-5
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
HASS Integration of Additional Uncompressed Scan Logic

The HASS flow also supports the presence of uncompressed scan logic in addition to the
compressed scan blocks by creating standard scan chains. The following uncompressed
logic types are supported during top-level integration:
• Standard scan cores
These cores are represented by the full netlist or a CTL test model. The DFTMAX tool
incorporates the core-level scan chains into top-level scan chains as scan chain
segments. These scan chain segments can be concatenated and rebalanced at the top
level as needed, but they cannot be subdivided into smaller scan chains.
• Test-ready cores that are scan-replaced, but do not yet have scan chains
The tool architects standard scan chains that are active in both the standard scan and
compressed scan modes.
• Cores that are not scan-replaced
The tool performs scan replacement, then architect standard scan chains that are active
in both the standard scan and compressed scan modes.
• Top-level glue logic that might or might not be test-ready
The tool performs scan replacement if needed, then architect standard scan chains that
are active in both the standard scan and compressed scan modes.
The scan chain connections for compressed cores are always promoted to top-level scan
chain connections. The scan architecture behavior for the additional uncompressed logic
depends on whether a target chain count is specified with the set_scan_configuration
-chain_count command.
Figure 3-4 shows a top-level design example with a compressed scan core, a standard scan
core, and some top-level glue logic. The compressed scan core C_CORE contains 24
flip-flops divided into 6 compressed scan chains of 4 flip-flops each, with 3 scan-in and
scan-out pins. The standard scan core S_CORE contains 12 flip-flops, split into 4 scan
chains. The top-level glue logic GLUE contains 2 scan-replaced flip-flops with no scan
chains.

The HASS Flow 3-6
Figure 3-4 Design Example Before HASS Integration

&B&25( 6B&25( */8(

&RPSUHVVHGVFDQFRUH $GGLWLRQDOXQFRPSUHVVHGORJLF
When no target chain count is specified, the following goals are used for scan architecture
of the additional logic:
• For the compressed scan mode of operation, the tool attempts to architect scan chains
that do not exceed the longest compressed scan chain inside a compressed scan core.
This preserves the test compression characteristics of the compressed scan cores.
• For the standard scan mode of operation, the tool follows the default rules of scan chain
architecture where the minimum number of scan chains is built that meet any applied
scan architecture requirements.
Figure 3-5 shows the resulting HASS top-level integration results operating in compressed
scan mode. The codec scan chain connections from C_CORE are promoted directly to
top-level connections. For the remaining uncompressed logic, standard scan chains are
architected so that the chain length of the compressed core is not exceeded.
Figure 3-5 Compressed Scan Mode After HASS Integration With No Chain Count Specified

&B&25( 6B&25( */8(
Figure 3-6 shows the resulting HASS top-level integration results operating in standard scan
mode. The standard scan chain connections from C_CORE are promoted directly to
top-level connections. For the remaining uncompressed logic, a single standard scan chain
is created that includes joined scan segments from S_CORE and the scan flip-flops from the
GLUE logic.

The HASS Flow 3-7
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Figure 3-6 Standard Scan Mode After HASS Integration With No Chain Count Specified

&B&25( 6B&25( */8(
Note that when a chain count is not specified, the scan chain counts might be different
between the standard scan and compressed scan modes.
When a scan chain count is specified with the set_scan_configuration -chain_count
command, the tool attempts to honor the specified chain count for both the standard scan
and compressed scan modes. Figure 3-7 shows the HASS top-level integration results for
the compressed scan mode when the set_scan_configuration -chain_count 6
command is specified. Because the specified scan chain count applies to both the standard
scan and compressed scan modes, the scan architecture of the uncompressed logic is the
same in both modes.
Figure 3-7 Compressed Scan Mode After HASS Integration With -chain_count 6 Specified

&B&25( 6B&25( */8(
If you issue a set_scan_configuration -chain_count command requesting fewer scan

chains than is possible, the preview_dft and insert_dft commands issue the following
warning:
Warning: Cells with 4 new incompatible clock domains have not been
assigned to scan chains. Cannot honor -chain_count specification of 3.
Try using set_scan_configuration -clock_mixing mix_edges or -clock_mixing
mix_clocks. (TEST-355)
If you issue a set_scan_configuration -chain_count command requesting more scan

chains than is possible, the preview_dft and insert_dft commands issue two warnings,
one for the total set of scan chains and one for the uncompressed logic chains:

The HASS Flow 3-8
Since compressed scan mode chains are usually short, you should take care to manage the
relative lengths of standard scan and compressed scan chains at the top level. This might
require management of the scan chain lengths of any standard scan cores, as well as
providing an adequate scan pin budget at the top level to avoid excessive standard scan
chain concatenation. If further reduction in chain length is needed, you can use the Hybrid
flow. For more information, see “The Hybrid Flow” on page 3-9.
After top-level integration, you can perform DRC of the standard scan mode using the
dft_drc command. However, the tool does not support DRC of the top-level compressed
scan mode. DRC checking for the compressed scan mode is performed in the TetraMAX
tool.
In the HASS flow, a single test-mode pin that is shared across all scan cores is required for
selecting standard scan or compressed scan mode. Complex test-mode encodings are not
supported.
The Hybrid Flow

In the HASS flow, existing compressed scan core chains are promoted to top-level chains
and standard scan is used to access all other logic, including top-level user-defined logic. If
there is a large amount of top-level logic, an imbalance between the compressed scan chain
lengths and standard scan chain lengths might result. This can reduce the effective amount
of test compression.
You can use the Hybrid flow to reduce this chain length imbalance. The Hybrid flow is a
combination of the compressed scan HSS flow and the HASS flow. The Hybrid flow operates
as follows:
• For compressed scan cores, the tool promotes core-level scan connections to top-level
connections, as in the compressed scan HSS flow.
• For uncompressed logic, the tool applies top-level scan compression, as in the HASS
flow.
The Hybrid flow supports the same uncompressed logic types as the HASS flow. For a list
of these logic types, see “HASS Integration of Additional Uncompressed Scan Logic” on
page 3-6.
Figure 3-8 shows an example of the Hybrid integration flow.

The Hybrid Flow 3-9
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Figure 3-8 Hybrid Integration of a Compressed Scan Core
&B&25( 6B&25( &B&25( 6B&25( */8(
Performing Top-Level Hybrid Integration

To enable the Hybrid flow at the top level, use the following commands:
dc_shell> set_scan_compression_configuration -hybrid true
The first command enables scan compression, and the second command enables the
Hybrid flow.
To configure Hybrid integration, you must supply the following information:
• Specify the total top-level scan chain count with the set_scan_configuration
-chain_count command.
• Specify the number of compressed scan chains for the new top-level codec with the
set_scan_compression_configuration -chain_count command, or the maximum
compressed scan chain length with the set_scan_compression_configuration
-max_length command.
Note:
This value does not include the compressed chains in any existing compressed scan
cores.
Just as with the HASS flow, the scan chain connections of compressed scan cores are
promoted to top-level scan chain connections. When you specify the total top-level chain
count with the set_scan_configuration -chain_count command, this value includes
these promoted compressed scan core connections. However, the compressed chain count
specified with the set_scan_compression_configuration -chain_count command
applies only to the logic included in top-level compressed scan insertion.
Figure 3-9 shows a top-level design that contains a compressed scan core named
C_CORE, a standard scan core named S_CORE, and some top-level logic named GLUE.

The Hybrid Flow 3-10
Figure 3-9 Top Level Before Applying Hybrid Integration
&B&25( 6B&25( */8(
&RPSUHVVHGVFDQFRUH $GGLWLRQDOXQFRPSUHVVHGORJLF
Figure 3-10 shows the resulting Hybrid top-level design operating in compressed scan
mode. Note the following features:
• The tool determines the number of inputs and outputs on the new top-level codec by
taking the top-level chain count and subtracting the codec connections of the existing
compressed scan cores. In Figure 3-10, C_CORE uses three of the five total top-level
scan chain connections. The remaining two chain connections determine the width of the
new top-level codec.
• The tool architects four compressed scan chains in the uncompressed logic, then
compresses these chains with the new top-level codec.
Figure 3-10 Compressed Scan Mode Operation After Hybrid Integration
VHWBVFDQBFRQILJXUDWLRQFKDLQBFRXQW

&B&25( 6B&25( */8(

VHWBVFDQBFRPSUHVVLRQBFRQILJXUDWLRQFKDLQBFRXQW
Figure 3-11 shows the HASS top-level integration results operating in standard scan mode.
The DFTMAX tool architects two standard scan chains in the uncompressed logic, and
connects them to the two available top-level scan pins.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Figure 3-11 Standard Scan Mode Operation After Hybrid Integration


&B&25( 6B&25( */8(

Performing Top-Level Hybrid Integration with Partitions

By default, Hybrid integration creates a single codec for all scan logic except the existing
compressed scan cores. You can use the DFT partition feature to create multiple codecs at
the top level. This can help reduce routing congestion. For more information on defining DFT
partitions to create multiple codecs, see Chapter 2, “Using Adaptive Scan Technology.”
You can use the define_dft_partition command to define an additional partition and
specify the cells and designs to be placed in that partition. All cores and logic not explicitly
assigned to a user-defined partition remain in the default partition, named
default_partition.
You can use the partition feature to perform compressed scan insertion on cores which have
not yet been scan-inserted. This allows you to defer compressed scan insertion of a core to
the top level integration run, where the scan compression configuration can be adjusted and
rerun as needed.
Consider the following scenario:
• Compressed scan core C_CORE already has compressed scan inserted, and only
requires integration at the top level.
• Blocks IP_BLK1 and IP_BLK2 have been synthesized with a test-ready compile, but they
do not yet have scan chains. Each of these blocks should have its own codec inserted
within its hierarchy.
• Some top-level glue logic exists, contained in the GLUE block. This glue logic should
have its own codec inserted at the top level.
The required partitions can be defined as shown in Figure 3-12.

Figure 3-12 Hybrid Partition Definitions Before Top-Level Integration

GHIDXOWBSDUWLWLRQ
3$57,7,21
3$57,7,21
&B&25( */8( ,3B%/. ,3B%/.
Example 3-2 shows the commands used for partition creation and scan configuration. The
set_dft_location command is used to place the codecs inside IP_BLK1 and IP_BLK2.
Example 3-2 Defining Partitions in a Hybrid Flow

set_scan_compression_configuration -hybrid true
define_dft_partition PARTITION1 -include {IP_BLK1}

define_dft_partition PARTITION2 -include {IP_BLK2}
current_dft_partition PARTITION1
set_dft_location -include DFTMAX IP_BLK1
set_dft_location -include DFTMAX IP_BLK2
Figure 3-13 shows the resulting codec configurations after the insert_dft command is
used.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Figure 3-13 Hybrid Partition Definitions After Top-Level Integration

GHIDXOWBSDUWLWLRQ
3$57,7,21
3$57,7,21
&B&25( */8( ,3B%/. ,3B%/.
The normal Hybrid scan architecture rules apply inside each partition. For example:
• A top-level chain count of five is specified for the default partition. Since C_CORE
already has three scan chain connections, two scan chain connections are allocated to
the codec inserted in the GLUE block.
• A compressed chain count of three is specified for the default partition. Three
compressed chains are created inside the GLUE block during compressed scan
insertion.
• Top-level chain counts and compressed chain counts applied to other partitions only
apply to the codec insertion for logic within those partitions.
Generating Patterns in TetraMAX

In the HASS and Hybrid flows, you can use the standard compressed scan flow to run DRC
and generate patterns. Example 3-3 shows a typical script for generating patterns in
Example 3-3 Script for Generating Patterns in Compressed Scan Mode
set_messages -log scancompress.log -replace
read_netlist top.v
read_netlist sub1.v
read_netlist sub2.v
run_build_model top
# run drc in scan compression mode
run_drc comp.spf
add_faults -all
write_patterns pat_compr.v -format verilog -parallel

Generating Patterns in TetraMAX 3-14
Top-Level Integration Script Examples

This section provides script examples for the HASS and Hybrid flows. It has the following
subsections:
• Typical HASS Flow Script
• Typical Hybrid Flow Script
• Hybrid Flow Script With Multiple Test Modes
Typical HASS Flow Script

HASS integration takes place at the top level. Example 3-4 shows a typical top-level script.
Example 3-4 Top-Level Script for HASS Flow
read_verilog TOP.v
read_test_model sub1.ctlddc
read_test_model sub2.ctlddc
current_design TOP
link

set_scan_compression_configuration -integration_only true
dft_drc
preview_dft
insert_dft
write_test_protocol -test_mode ScanCompression_mode -output comp.spf
write_test_protocol -test_mode Internal_scan -output scan.spf
Note:
Post-DFT DRC in scan compression mode is not supported at the top level.
Typical Hybrid Flow Script

Example 3-5 shows a typical script for top-level integration for the Hybrid flow.
Example 3-5 Script for Top-Level Integration in the Hybrid Flow
read_verilog my_top_test_ready.v
read_test_model ddc/core1.ctlddc
current_design my_top
link

Top-Level Integration Script Examples 3-15
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4


-timing {45 55} -port CLK
set_dft_signal -view existing_dft -type constant \
-active_state 1 -port my_test_mode_port
set_dft_insertion_configuration \
-synthesis_optimization none -preserve_design_name true
dft_drc
insert_dft
dft_drc -verbose
remove_design core1
remove_design core2
write -format verilog -hierarchy -output vg/top_scan.v

write -format ddc -hierarchy -output ddc/top_scan.ddc
write_test_protocol -test_mode ScanCompression_mode \
-output stil/top_moxie.stil -names verilog
write_test_protocol -test_mode Internal_scan \
-output stil/scan.stil -names verilog
Hybrid Flow Script With Multiple Test Modes

Example 3-6 shows a typical script for the top-level integration with multiple test modes
using the Hybrid flow.
Example 3-6 Top-Level Integration With Multiple Test Modes in the Hybrid Flow
read_verilog my_top_test_ready.v
current_design my_top
link
## Define the pins for compression/base_mode using "test_mode all".

## These modes are my_comp and my_scan1
for {set i 1} {$i <= 16 } { incr i 1} {
set_dft_signal -type ScanDataIn -view spec -port test_si[$i] \
-test_mode all
set_dft_signal -type ScanDataOut -view spec -port test_so[$i] \
-test_mode all


-port [list i_trdy_de i_trdy_ddi_cs]
# Define the test modes and usage

# Configure DFTMAX
set_scan_compression_configuration -base_mode my_base1 \
-minimum_compression 10 \
-test_mode scan_compression1 \
-xtolerance high -hybrid true

# 8 chains for core1 xtol, 8 chains for core2 and UDL = 16
# 1 chain for burn_in mode
-test_mode burn_in
-port CLK
# Create the test protocol

# Preview DFT insertion

# Run the pre-DFT DRC

dft_drc
# Insert DFT logic

insert_dft
dft_drc -verbose
remove_design core1
remove_design core2
write -format verilog -hierarchy -output vg/top_scan.v
write -format ddc -hierarchy -output ddc/top_scan.ddc
-output stil/ scan_compression1.stil -names verilog
write_test_protocol -test_mode my_base1 \
-output stil/ my_base1.stil -names verilog

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
write_test_protocol -test_mode burn_in \

-output stil/ burn_in.stil -names verilog
Limitations
This section describes the limitations associated with the HASS and Hybrid flows. The
subsections in this section are as follows:
• HASS Flow Limitations
• Hybrid Flow Limitations
HASS Flow Limitations

Note the following limitations of the HASS flow:
• Cores using multiple user-defined test modes are not supported.
• Top-level post-DFT DRC in scan compression mode is not supported.
• Block-level patterns cannot be ported at the top level.
• When you use the set_scan_configuration -chain_count command at the top level
with a chain count insufficient to satisfy all core scan pin connections, you see the
following warning issued by the preview_dft command:
Warning: Cells with 33 new incompatible clock domains
have not been assigned to scan chains. Cannot honor
-chain_count specification of 2. (TEST-355)
Hybrid Flow Limitations

The limitations described in “HASS Flow Limitations” on page 3-18 also apply to the Hybrid
flow. In addition, note the following additional limitations of the Hybrid flow:
• Wrapped cores are not supported.
• Block-level patterns cannot be ported at the top level.

Limitations 3-18
4
Managing X Values in Scan Compression 4
A significant number of X sources in any compression architecture can degrade fault
coverage, especially with high scan compression ratios. Today's complex designs often
contain many such X sources: logic constrained by certain timing exceptions, memories and
IP cores without test modes or models, combinational feedback loops, and nonscan
flip-flops. This chapter describes features provided by the DFTMAX tool to analyze and
efficiently mask X values in the design.
• High X-Tolerance Scan Compression
• Static-X Analysis
• Architecting X Chains
4-1
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
High X-Tolerance Scan Compression

DFTMAX compression has a default tolerance for some Xs, but it also provides an option to
implement a full tolerance of Xs. This section describes high X-tolerance adaptive scan, a
technology that provides low-impact, 100 percent X-tolerance for designs that use scan
compression in the presence of many X sources.
This section includes the following sections:
• The High X-Tolerance Architecture
• Enabling High X-Tolerance
• Scan-In and Scan-Out Requirements
• Supported Flows
The High X-Tolerance Architecture

DFTMAX adaptive scan technology provides scan compression using only combinational
circuitry. This approach achieves moderate to high compression while minimizing the
additional cost for DFT implementation. Furthermore, scan compression can be applied to a
wide variety of designs, including designs with a large number of X values. The source of
these Xs are either static (logic-induced) or dynamic (constraint-induced).
The high X-tolerance scan compression solution provided by the DFTMAX tool meets the
challenge of coverage loss by implementing new logic that selectively masks circuit
response on a per-shift basis — a technique that provides 100 percent X-tolerance without
introducing sequential circuitry. Note that this solution does not require any additional pins
to perform X-masking. This architecture is shown in Figure 4-1.
Figure 4-1 High X-Tolerance Adaptive Scan Architecture
WHVWBVL
'HFRPSUHVVLRQ08;
0DVNHQDEOH
0DVNPRGH VLJQDO
VLJQDOV
;EORFNLQJFLUFXLW
;25FRPSUHVVRU
WHVWBVR
Chapter 4: Managing X Values in Scan Compression

High X-Tolerance Scan Compression 4-2
The high X-tolerance architecture provides the following observe modes:

• A full (unmasked) observe mode, which is equivalent to the default X-tolerance mode
• Additional X-tolerance (masked) observe modes, which can mask X values from
selected chains before they reach the XOR compressor
An existing ScanDataIn port provides the mask enable signal. A mask enable value of zero
selects the full observe mode. A mask enable value of one plus combinations of the mask
mode signals selects additional X-tolerance observe modes for unload. Information about
the X-tolerance observe modes is contained in the SPF in the CompressorStructures
section in the Compressor my_design_U_compressor_ScanCompression_mode
ModeControl definitions.
The high X-tolerance architecture introduces a combinational path between the scan input
and scan output ports. The path travels from the scan input ports, through the
decompression MUX mask signal generation logic, through the X-blocking and XOR
compactor circuits, then through the scan output ports. This path can potentially contain
long routes as well as combinational logic. To help meet timing requirements, you can use
the pipelined scan data feature. For more information, see “Pipelined Scan Data” on
page 5-7.
Enabling High X-Tolerance

By default, the scan compression logic inserted by the DFTMAX tool provides some
tolerance of Xs. No option is needed to obtain this default X-tolerance capability.
For designs with large numbers of X values, you can enable the high X-tolerance feature
with the following command:
dc_shell> set_scan_compression_configuration -xtolerance high
The preview_dft and insert_dft commands report information about the scan
compression codecs in the design. The output from these commands includes an
information message to confirm that the high X-tolerance feature is enabled:
Architecting Load Decompressor (version 5.8)
Number of inputs/chains/internal modes = 8/20/4
Architecting Unload compressor (version 5.8)
Number of outputs/chains = 5/20
Information: Compressor will have 100% x-tolerance

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Scan-In and Scan-Out Requirements

The high X-tolerance feature imposes a limit on the number of compressed scan chains you
can build with a given number of scan-in and scan-out pins. Table 4-1 shows the maximum
number of compressed scan chains that can be built for a given set of scan-in and scan-out
pins.
Table 4-1 High X-Tolerance Compressed Scan Chain Limits
Number of scan-in Maximum number of chains Maximum number of chains

and scan-out pins without OCC controller with OCC controllera
2 4
3 12 6
4 32 16
5 80 40
6 192 96
7 448 224
8 1024 512
9 2304 1152
10 5120 2560
11 11264 5632
12 24576 12288
13 32000 26624
14 and higher 32000 32000
a. This column assumes that a single decompressor input is dedicated to OCC clock chains. Additional
dedicated clock chain decompressor inputs will further reduce the limit.
If the on-chip clocking (OCC) feature is used with compressed clock chains, the dedicated
decompressor scan input lowers the limit. For more information on compressed clock
chains, see “Scan Compression and OCC Controllers” on page 2-27.

Table 4-2 shows the maximum compressed scan chain count when high X-tolerance is used
with some asymmetrical low-pin-count configurations:
Table 4-2 High X-Tolerance Compressed Scan Chain Limits for Asymmetrical Scan Pins
Asymmetrical scan-in, Maximum number of chains Maximum number of chains

scan-out pin configuration without OCC controller with OCC controller
2 scan-ins, 1 scan-out 2
3 scan-ins, 1 scan-out 4
3 scan-ins, 2 scan-outs 8 4
If the specified compressed scan chain count cannot be satisfied, the tool issues an error
message that contains information about how many compressed scan chains were
requested and how many compressed scan chains can be built for the current scan pin
configuration. Example 4-1 shows the error message issued when 20 compressed scan
chains are requested, but only 12 scan chains can be built.
Example 4-1 High X-Tolerance Error Message for Insufficient Scan-In Pins
Error: Architecting of Load/Unload compressor failed with the given set
of parameters. (TEST-1722)
Number of internal chains architected: 20
Number of available compression channels: 12
Number of load compressor inputs: 3
Number of unload compressor outputs: 3
You can also use the TetraMAX analyze_compressors command to determine if a codec
can be built for a given set of parameters. For more information, see TetraMAX Online Help.
Supported Flows
High X-tolerance scan compression supports the following flows:
• All flat flows
• All hierarchical flows that use basic scan subblock test models and insert high
X-tolerance compressors at the top level

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
• Hierarchical integration for designs in which some blocks have high X-tolerance
compressors and some blocks have basic scan
• Hierarchical integration for designs in which some blocks have high X-tolerance
compressors, some blocks have basic scan, and user-defined logic (UDL) exists
Note:
Pin requirements in hierarchical flows are the same whether or not the cores have built-in
X-tolerance.
Static-X Analysis
Some flip-flops capture X values more often than others because they are located in the
fanout of logic constructs that generate unknown values. A flip-flop that frequently captures
an X value during capture is called a static-X cell.
The DFTMAX tool provides a static-X analysis feature that analyzes a design and reports
static-X cells. This analysis feature can be used in both standard scan and compressed scan
flows. When enabled, it reports static-X cell information during pre-DFT DRC. By itself,
static-X analysis does not affect subsequent scan chain architecture.
Static-X analysis is enabled by using the following command:
dc_shell> set_dft_drc_configuration -static_x_analysis enable
When enabled, static-X analysis directs pre-DFT DRC to carry out an X-probability analysis
of the sequential cells by invoking combinational simulation within the tool and then defining
those sequential cells with high X-capture probability as static-X cells. The analysis is
performed using the following procedure:
1. Normal test DRC analysis is performed to determine the set of scannable cells.
2. Constrained primary inputs are set to their constrained values, clocks are set to their
inactive values, and scan-enable signals are set to their inactive (capture) values.
3. Constant-value state elements are set to their constant values.
4. Other primary inputs and nonconstant scannable cells are set to random binary values.
All other state elements, such as nonscan cells, are set to X.
5. 1024 random patterns are simulated to determine the frequency that the data input of a
scannable cell is at X.
6. A scannable cell whose data input is X with a frequency exceeding a predetermined
threshold is recorded along with its frequency of capturing an X value. The
predetermined threshold is 25 percent and cannot be changed.

Static-X Analysis 4-6
After identifying the static-X cells, the dft_drc command reports them as D39 violations in
the following format:
Warning: Probability of capture X (X probability <%>) exceeds threshold
for scancell DFF %s. (D39-x)
The dft_drc command also sets the test_dft_xcell_violation attribute on all identified
static-X cells. You can use this attribute to obtain the cells for further script-based analysis:
dc_shell> set static_x_cells \
[get_cells -hierarchical * -filter {test_dft_xcell_violation == true}]
When debugging static-X cells, remember that a static-X cell captures the frequent X values,
but the source of these frequent X values will likely exist in the fanin logic to the cell. The
following design constructs can introduce X values into the design logic:
• Black boxes
• CTL models
• Combinational feedback loops
• Uncontrolled internal buses
• Uncontrolled bidirectional ports
• Nonscan cells
Note:
Timing exceptions are not considered as a source of X values during static-X analysis in
the DFTMAX tool. Instead, they are considered as dynamic path-specific sources of X
values during TetraMAX ATPG.
Architecting X Chains
The DFTMAX tool provides a static-X chain feature that identifies scan cells that frequently
capture X values, and then groups them exclusively into special scan chains, called X
chains. By grouping X-capturing cells into dedicated scan chains, incidental X masking of
any chain is reduced or eliminated.
The static-X chain feature deals with the pattern inflation that is caused by the occurrence of
static-X cells in compression mode. This method of handling the X cells achieves better test
data volume reduction (TDVR), and improves ATPG quality of results. X-chain information is
communicated seamlessly in the DFTMAX to TetraMAX flow through the STIL procedure file
(SPF). The SCANDEF file generated by the DFTMAX tool groups the X cells into separate
SCANDEF partitions so that a place-and-route tool can preserve those groups.

Architecting X Chains 4-7
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4

• The X-Chain Architecture
• Enabling X Chains
• Manually Specifying X-Chain Cells
• Using the set_scan_path Command With X Chains
• Using AutoFix With X Chains
• Using X Chains in Hierarchical Flows
• Using the test_simulation_library Variable
• Representing X Chains in SCANDEF Files
• Passing X-Chain Information to TetraMAX
• Error and Warning Summaries
• X-Chain Usage Guidance
The X-Chain Architecture

The static-X analysis feature identifies and reports scan cells that frequently capture X
values, called static-X cells. However, by itself, the static-X analysis feature does not affect
scan chain architecture; it is only an analysis feature.
The X-chain feature builds on the static-X analysis feature. It groups these identified static-X
cells exclusively into special scan chains, called X chains. This allows pattern generation to
efficiently mask static-X cells for most test patterns, leaving the other chains unmasked, as
shown in Figure 4-2.

Figure 4-2 X Values in Static-X Chains
1 0 0 1 1 0
Decompression MUX
XOR
0 0 1 1 1 0
Masking logic
Compression
0 1 0 0 1 0
1 X 0 X X 1
Static-X chain Mask this chain

for this pattern
As a result, fewer chains are masked by the high X-tolerance masking logic, resulting in
better fault coverage and a lower volume of test data.
Enabling X Chains
To isolate the identified static-X cells and architect X chains that contain only these cells, use
the following commands:
dc_shell> set_dft_drc_configuration -static_x_analysis enable
dc_shell> set_scan_compression_configuration \
-xtolerance high \
-static_x_chain_isolation true
The X-chains feature has the following requirements:

• Static-X analysis must be enabled, as the static-X cell attributes are used to determine
which cells are placed in the X chains. For more information, see “Static-X Analysis” on
page 4-6.
• The X-chain feature only operates in compressed scan modes, and it requires that high
X-tolerance is enabled. For more information, see “High X-Tolerance Scan Compression”
on page 4-2.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
The preview_dft command reports X chains with an additional “(X chain)” label, as
shown in the following example:
****************************************
****************************************
Number of chains: 320
Clock domain: mix_clocks

Scan chain '2' contains 50 cells (X chain)


Note:
Use the preview_dft command to identify X chains. The report_scan_path command
does not identify X chains.
The tool performs scan chain balancing with the additional constraint that static-X cells
cannot be mixed with non-static-X cells in the same scan chain. If the number of static-X
cells exceeds 20 percent of the total number of scan cells, the tool issues the following error
message:
Error: Too many static-X cells in design. Cannot isolate cells as
separate X-chains. (TEST-1090)
Note that assigning the static-X cells to X chains applies an additional constraint to the
physical implementation tool. The static-X cells could be distributed across the chip, so
connecting them together into one or more scan chains can result in long wires that
contribute to routing congestion.
Manually Specifying X-Chain Cells

The X-chain feature uses the test_dft_xcell_violation cell attribute, set by static-X
analysis, to determine the scan cells placed in dedicated X chains. After pre-DFT DRC
completes, you can manually set or remove this attribute on scan cells to modify the set of
static-X cells. The insert_dft command then uses the modified set of static-X cells to
construct the X chains.
To specify cells as static-X cells, use the following command:
dc_shell> set_attribute -type boolean [get_cells cell_list] \
test_dft_xcell_violation true

To remove the static-X attribute from cells, use the following command:
dc_shell> remove_attribute [get_cells cell_list] \
test_dft_xcell_violation
Note:
The set_attribute and remove_attribute commands must be used after pre-DFT
DRC is run with the dft_drc command, but before scan is inserted with the insert_dft
command.
Use this capability to include additional scan cells in the X chains. For example, certain scan
cells might frequently capture dynamic X values during pattern generation in TetraMAX
ATPG. If you know the timing exceptions and are able to translate them to capturing scan
cell names, you can mark these scan cells as static-X cells with the set_attribute
command.
Using the set_scan_path Command With X Chains

If both static-X cells (identified during pre-DFT DRC) and non-static-X cells are defined in a
common set_scan_path command applied to a scan compression mode, the resulting
scan path is not an X chain even though it contains static-X cells. When this happens, the
tool issues the following warning message:
Warning: Chain %s has both X and non-X cells. (TEST-1079)
However, if the defined scan path consists entirely of static-X cells, the scan path becomes
an X-chain.
This behavior applies only to set_scan_path commands applied to a scan compression
mode. If a set_scan_path specification is applied to a standard scan mode, it does not
affect X-chain scan architecture.
Using AutoFix With X Chains

If static-X analysis reports a large number of static-X cells, you can use AutoFix to fix
X-capture problems. For more information on AutoFix, see the “Advanced DFT Architecture
Methodologies” chapter in the DFT Compiler Scan User Guide.
When using AutoFix with the X-chains feature, pre-DFT DRC performs static-X analysis
before applying AutoFix. If the features are used together, they can potentially interact in a
way that affects the static-X analysis and the resulting X chains.
Consider the circuit shown in Figure 4-3. Flip-flop FF1 always captures an X value. During
static-X analysis, FF1 is treated as a nonscan cell due to its uncontrollable reset and is
therefore not marked as a scannable static-X cell. During AutoFix processing, the

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
uncontrollable reset becomes controllable, and FF1 becomes scannable. It is placed into a
regular scan chain despite always capturing an X value.
Figure 4-3 Using AutoFix With X Chains
;
%%2;
)) ))
8QFRQWUROOHG
UHVHW
Sequential cells with D1, D2, and D3 violations (uncontrollable clock, set, and reset signals)
are susceptible to this interaction if they frequently capture X values and are subsequently
made scannable by AutoFix.
To avoid this interaction, use the following two-pass flow:
1. Apply AutoFix with scan insertion disabled, so that only the AutoFix logic is inserted:
set_dft_configuration \
-scan disable \
-fix_clock enable -fix_set enable -fix_reset enable
set_autofix_configuration ...
preview_dft
insert_dft
2. Disable AutoFix, reenable scan insertion, and continue with normal scan insertion:
set_dft_configuration \
-fix_clock disable -fix_set disable -fix_reset disable \
-scan enable -scan_compression enable
set_scan_configuration ...
set_scan_compression_configuration ...
An alternative solution is to use the single-pass flow and manually mark the affected
X-capturing sequential cells with the test_dft_xcell_violation attribute. However, this
solution requires knowledge of the cells that are affected by the interaction.
Using X Chains in Hierarchical Flows

This section provides information on using X chains in hierarchical flows. The behaviors
described in this section result from using core test language (CTL) models to represent
core blocks during hierarchical flows.

Note:
When a DFT run includes a previously scan-inserted core read from a full-netlist .ddc file,
the tool still uses a CTL model representation during DFT operations.
This section includes the following subsections:
• Static-X Cells in the HASS Flow
• Hierarchical Blocks and X Sources
Static-X Cells in the HASS Flow

This section pertains to the HASS flow, in which standard scan is inserted at the core level,
and then compressed scan is inserted at the top level using these core-level standard scan
chain segments. Figure 4-4 shows an example of this flow.
Figure 4-4 Applying the HASS Flow to a Standard Scan Core
6B&25( 6B&25( */8(
Static-X analysis can be performed in both standard scan and compressed scan flows.
However, X chains can only be created in compressed scan flows. When creating a standard
scan core that will subsequently be scan-compressed in a HASS flow, X analysis can be
used to determine if there are any static-X cells in the core. However, X chains cannot be
used to consolidate the static-X cells into X chains at the core level.
When using this flow, you should use static-X analysis to ensure that the standard scan core
does not contain any static-X cells. If it does, consider using AutoFix to resolve the X
sources. For more information on AutoFix, see the “Advanced DFT Architecture
Methodologies” chapter in the DFT Compiler Scan User Guide. Note that AutoFix might not
be able to resolve all X sources.
At the top level, the core is modeled using CTL model information during hierarchical
compressed scan insertion. Any static-X cells that exist in the core-level scan chain
segments are not visible to top-level DRC analysis, and they are incorporated into regular
codec scan chains.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
The dft_drc -verbose command reports the core-level standard scan chain segments as
possible D39 violations, with one violation reported for each segment:
-----------------------------------------------------------------
Begin Pre-DFT violations...
Warning: Probability of capture X (100) exceeds threshold for scancell

CORE Usub. (D39-1)
CORE Usub. (D39-2)
CORE Usub. (D39-3)
CORE Usub. (D39-4)
Pre-DFT violations completed...

-----------------------------------------------------------------
-----------------------------------------------------------------
DRC Report
Total violations: 4
-----------------------------------------------------------------
4 PRE-DFT VIOLATIONS
4 Static X scan cell violations (D39)
Warning: Violations occurred during test design rule checking. (TEST-124)
-----------------------------------------------------------------
Sequential Cell Report
0 out of 1333 sequential cells have violations
-----------------------------------------------------------------
SEQUENTIAL CELLS WITHOUT VIOLATIONS

* 1329 cells are valid scan cells
Z_reg[30]
Z_reg[29]
Z_reg[28]
...
CORE SEGMENTS WITHOUT VIOLATIONS

* 4 core segments are valid scan segments
Usub/1
Usub/2
Usub/3
Usub/4
The CTL model scan chain segments are reported as D39 violations to report that the
segments could potentially contain static-X cells. Although the scan chain segments are
reported as possible static-X sources, they are not incorporated into the top-level X chains.

Pre-DFT DRC also issues the following warning message:

Warning: Static X-cell analysis may be inaccurate on design containing
cells with CTL models. (TEST-610)
For compressed scan cores used in a hierarchical adaptive scan synthesis (HASS) flow,
there is no problem with static-X cells, if they are present, because the static-X cells were
already isolated into X chains when the models were created.
Hierarchical Blocks and X Sources

When a compressed scan insertion run includes a previously scan-inserted core, the core is
represented using CTL model information. This is true even when the core is represented as
a full netlist read from a .ddc file. This CTL model contains information about the DFT logic
in the core, but does not include functional information about the core outputs.
In some cases, it might be possible for X sources to drive core outputs. Consider the
example shown in Figure 4-5, where a memory cell drives a core output.
Figure 4-5 Modeling Cores With X Sources Using CTL Models
723
&25( &25(
0(0 &7/ ))

PRGHO
During core-level DRC, no scannable cells capture an X value from the memory, and
therefore no static-X cells are reported by static-X analysis. During top-level DRC, a
scannable cell now captures the memory output. However, the core is modeled using CTL
model information, which does not model the functional core outputs. As a result, static-X
analysis does not detect that flip-flop FF1 frequently captures an X value, and it is placed
into a regular codec scan chain.
If you know the list of affected top-level flip-flops, apply the test_dft_xcell_violation
attribute to place them into X chains. For more information, see “Manually Specifying
X-Chain Cells” on page 4-10.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Using the test_simulation_library Variable

In some cases, the synthesis libraries used by the tool might model a cell as a black box,
while the simulation libraries used by the TetraMAX tool might provide functional information
for the same cell. The test_simulation_library variable enables DFTMAX DRC to use
the TetraMAX simulation libraries.
When using the X-chains flow, it is desirable to replace most types of black-box cells with
their simulation models. This provides a more accurate assessment of X behaviors during
static-X analysis. You can verify the resulting X chains in the TetraMAX tool by looking for the
M469, M470, and M471 messages in conjunction with the analyze_compressors
-xchain_analysis command. These messages report on the consistency of X-capture
frequency between regular scan chains and X chains.
However, you should not configure memory cell models with the
test_simulation_library variable when using the X-chains flow. Figure 4-6 shows an
example where flip-flops capture the values from memory outputs.
Figure 4-6 Memory Outputs Driving Scan Cells
Memory
DO0 Scan
DO1 Scan
DO2 Scan
DO3 Scan
If the simulation model is configured for the memory, pre-DFT DRC reports the information
shown in Example 4-2.
Example 4-2 Pre-DFT DRC Report for Memory Models
In mode: all_dft...
Pre-DFT DRC enabled
Information: Starting test design rule checking. (TEST-222)

Loading test protocol
...basic checks...
...basic sequential cell checks...
...checking for scan equivalents...
...Loading simulation libraries...
...checking vector rules...
...checking pre-dft rules...

-----------------------------------------------------------------
Begin Modeling violations...
Warning: Cell U_RAM (MEM) is unknown (black box) because functionality
for output pin Q[0] is bad or incomplete. (TEST-451)
Information: Cells with this violation : U_RAM. (TEST-283)
Modeling violations completed...

-----------------------------------------------------------------
-----------------------------------------------------------------
Begin Pre-DFT violations...
Warning: Clock input clk of DFF U_RAM cannot capture data. (D17-1)
DFF U_RAM. (D39-1)
Pre-DFT violations completed...

-----------------------------------------------------------------
The D39 violation is issued for the memory model itself. However, no D39 violations are
issued for the sequential cells that capture the memory outputs. The simulation model used
by DFTMAX DRC is treated like a Verilog netlist with instantiated sequential cells. These
sequential cells are considered as valid scannable cells within the dft_drc command,
which results in hiding the X-generation effect of the memory outputs. As a result, the
sequential cells connected directly or indirectly to the memory outputs are not treated as
static-X cells and are therefore not placed into X chains.
Subsequently, during TetraMAX ATPG, memories are X-generators during much of the
ATPG process, and those sequential cells capture Xs, although the actual capture details
might depend on the particulars of the ATPG engine and target faults. Therefore, it is better
to put those cells into X chains. To do this, the memory models should not be configured with
the test_simulation_library variable. Instead, the normal black-box synthesis memory
models should be used during DFTMAX pre-DFT DRC.
Representing X Chains in SCANDEF Files

The DFTMAX tool puts X-chain information in the SCANDEF file to instruct the physical
implementation tool to preserve the X chains during optimization. Static-X cells are written
into a SCANDEF partition whose label name starts with X_. This allows the place-and-route
tool to preserve those groups, as shown in the following SCANDEF fragment:
- 1424
+ START M12/U4497 Y
+ FLOATING Q12/PCB_8192x64c16s0_bit_reg_17_ ( IN SI ) ( OUT Q )
Q12/PCB_8192x64c16s0_bit_reg_49_ ( IN SI ) ( OUT Q )

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
+ PARTITION X_clk_core_45_45
+ STOP Q12/PCB_8192x64c16s0_bit_reg_21_ SI ;
Passing X-Chain Information to TetraMAX

To generate the test patterns and masking controls, the ATPG tool needs to have access to
information about the structure of the X chains. The DFTMAX tool puts this information into
the SPF for use by the ATPG tool.
The following is an SPF example with X chains:
Compressor "top_U_compressor_ScanCompression_mode" {
ModeGroup mode_group;
UnloadGroup unload_group;
UnloadModeGroup unload_mode_group0 unload_mode_group1
unload_mode_group2;
CoreGroup core_group;
UnloadModeEnable enable_group;
Modes 193;
Mode 0 {
ModeControls {
"test_si17" = 0;
}
Connection "3" 0 1 2 3;
Connection "4" 4;
Connection "5" 5;
Connection "6" 6;
Compressed chains that are part of the CoreGroup but are not connected in Mode 0 are
implicitly defined as X chains. In the following example, compressed chains “1” and “2” are
X chains that consist of static-X cells exclusively. Mode 0 is called the full observe XOR
mode. The two X chains are observed by a direct-observability mode, in which each X-chain
can be observed at a different, single output with no other compressed chains XORed.
Mode 58 {
ModeControls {
"test_si17" = 1;
"test_si15" = 0;
"test_si16" = 0;
"test_si1" = 1;
"test_si2" = 1;
"test_si3" = 1;
"test_si4" = 0;
"test_si5" = 0;
"test_si6" = 1;
}
Connection "1" 3;
Connection "2" 11;
Connection "28" 6;
Connection "53" 14;

Connection "78" 15;

Connection "103" 10;
Connection "127" 0;
Connection "177" 2;
Error and Warning Summaries

The following error and warning messages exist for this feature:
• TEST-1090 (Error) Too many X cells in design. Cannot isolate static X cells as separate
X chains.
Description:
You receive this message if you have specified X-chain isolation in a Scan Compression
mode and more than 20 percent of valid scan cells have static-X (D39) violations.
• TEST-1088 (Warning) Static X chain isolation is ignored in %s as high xtolerance is not
enabled.
Description:
You receive this message if you have specified X-chain isolation without high X-tolerance
in a Scan Compression mode, using the set_scan_compression_configuration
command. Static-X chain isolation will be ignored for this mode.
• TEST-610 (Warning) Static X cell analysis may be inaccurate on design containing cells
with CTL models.
Description:
This message indicates that the current design has cells with CTL models, which means
the static-X cell analysis might be inaccurate.
• TEST-1079 (Warning) Chain %s has both X and non-X cells.
Description:
You receive this message if you have specified a set_scan_path command that mixes
X and non-X cells within the same scan chain in a scan compression mode. The resulting
mixed chain will not be considered as an X-chain.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
X-Chain Usage Guidance

The X-chains feature is intended for designs that have static-X values. This feature might not
improve results for designs with dynamic X values when compared to high X-tolerance
without X chains. There is no automated way to determine which type of X value is
propagated within a design. Additional test data volume reduction can be achieved with the
X-chain feature if the following conditions are met:
• A considerable number of memories or hard macros are used in TetraMAX ATPG.
• A large number of R14 violations are issued in TetraMAX DRC.
• Many scan cells are analyzed as X-scan cells due to capturing X values from tiex cells,
as noted when executing the TetraMAX set_simulation -analyze_x_sources and
run_simulation commands.

5
Advanced Adaptive Scan Techniques 5
This chapter describes advanced features that can be used while inserting compressed
scan circuitry into your design. These features are used to customize DFT insertion, to
improve the frequency of the scan testing logic, and to reduce the pattern count for
pin-limited designs.
• Specifying a Location for DFT Logic Insertion
• Pipelined Scan Data
• Sharing Codec Scan I/O Pins
• Implicit Scan Chains
5-1
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Specifying a Location for DFT Logic Insertion

By default, DFT Compiler places global test logic, such as test-mode decode logic and
compressed scan codecs, at the top level of the current design. Other test logic types, such
as lock-up latches and reconfiguration MUXs, are placed at the local point of use.
You can specify alternative insertion locations for different types of test logic with the
set_dft_location command:
set_dft_location dft_hier_name
[-include test_logic_types]
[-exclude test_logic_types]
If the specified hierarchical cell does not exist, the insert_dft command creates it during
test insertion. For more information, see “Creating New DFT Logic Blocks” on page 5-6.
By default, all test logic is synthesized inside the specified hierarchical cell. To synthesize
only some types of test logic at that location, use the -include or -exclude option and list
the test logic types to be included in or excluded from the specified cell.
For example, to place DFTMAX codec logic inside my_cell, and place the remaining test
logic at the top level:
dc_shell> set_dft_location my_cell -include DFTMAX
To place all test logic inside my_cell except for test control module logic, which remains at its
default top-level location:
dc_shell> set_dft_location my_cell -exclude TCM
The valid test logic types are:

• DFTMAX
This type includes the compressor and decompressor (codec) logic inserted by the
DFTMAX tool for compressed scan and serialized compressed scan modes.
• PIPELINE_SI_LOGIC
This type includes all head and tail pipelined scan data registers.
• PIPELINE_SE_LOGIC
This type includes all pipelined scan-enable logic.
• PLL
This type includes on-chip clock controller (OCC) and clock chain logic. For more
information, see the “On-Chip Clocking Support” chapter in the DFT Compiler Scan User
Guide.
Chapter 5: Advanced Adaptive Scan Techniques

Specifying a Location for DFT Logic Insertion 5-2
• WRAPPER
This type includes core wrapping cells and wrapper mode logic configured by the
set_wrapper_configuration command. For more information, see the “Wrapping
Cores” chapter in the DFT Compiler Scan User Guide.
• BSR
This type includes the IEEE Std 1149.1 boundary scan register logic inserted when the
set_dft_configuration -bsd enable command is used.
• TAP
This type includes the IEEE Std 1149.1 TAP controller logic inserted when the
set_dft_configuration -bsd enable command is used.
• SERIAL_CNTRL
This type includes the serializer clock controller used in serializer flows.
• SERIAL_REG
This type includes the standalone deserializer and serializer registers used in the
serializer IP insertion flow. This type does not affect the normal serializer insertion flow.
• XOR_SELECT
This type includes the sharing compressor and block-select logic inserted at the
compressor outputs in the shared codec I/O flow. For more information, see “Sharing
Codec Scan I/O Pins” on page 5-22.
• TCM
This type includes the test control module logic that decodes test-mode signals in a
multiple test-mode flow. For more information on multiple test modes, see “Multiple Test
Modes” in the DFT Compiler Scan User Guide.
• LOCKUP_LATCH
This type includes all lock-up latches.
• REC_MUX
This type includes all scan chain reconfiguration MUXs used to reconfigure scan chains
for different test modes in a multiple test-mode flow. It also includes scan-out MUXs,
tristate and bidirectional disable logic, and any other glue logic added during DFT
insertion.
When test logic is placed in an alternative location, new test signal pins are created on
hierarchical blocks as needed to route the test signals to the specified location. Table 5-1
lists the possible port types and their naming conventions. If you are moving test logic with

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
many individual signals, such as lock-up latch cells, this can result in a large number of
hierarchy pins being created.
Table 5-1 New Hierarchy Pin Naming Conventions for User-Specified DFT Instances
Port Purpose Direction
test_si%d External scan input pin Input
test_so%d External scan output pin Output
test_se Scan enable (single) Input
test_se%s Scan enables (multiple) Input
test_mode%d Test-mode Input
comp_shift_clk%d External compression shift clock Input
comp_lfsr_clk%d External compression linear Input

feedback shift register (lfsr) clock
pins
comp_load_en%d External compression load pins Input
comp_unload_en%d External compression unload pins Input
scan_in%d Internal scan-in pins Output
scan_out%d Internal scan-out pins Input
Lockup_latch clock Name of clock driving the lock-up Input

latch
Functional input net name Net name where the tool inserts the Input
scan-out MUX
Testmode name_out Output test-mode pin for a test_mode Output
If you issue multiple set_dft_location commands, the insert_dft command uses the
last specified location for each test logic type during DFT insertion. In Example 5-1,
reconfiguration MUXs and lock-up latches are kept at their local point of use, test-mode
decode logic is placed in a top-level UTCM block, and all other test logic types are placed in
a UTEST_LOGIC block.

Example 5-1 Issuing Multiple set_dft_location Commands

set_dft_location -exclude {REC_MUX LOCKUP_LATCH BSR} UTEST_LOGIC
set_dft_location -include {TCM} UTCM ;# TCM location is overwritten
You can use the report_dft_location command to see the currently defined locations for
all DFT logic types. The default location for global test logic types is reported as <top>,
which represents the top level of the current design. The default location for local test logic
types is reported as <local>, which represents the local point of use. Example 5-2 shows
the report resulting from the commands in Example 5-1.
Example 5-2 Example of a report_dft_location Report
Design Name DFT PARTITION NAME DFT TYPE DFT Hierarchy Location
========================================================================
top default_partition BSR <top>
top default_partition DFTMAX UTEST_LOGIC
top default_partition LOCKUP_LATCH <local>
top default_partition TAP UTEST_LOGIC
top default_partition TCM UTCM
top default_partition PIPELINE_SE_LOGIC UTEST_LOGIC
top default_partition PIPELINE_SI_LOGIC UTEST_LOGIC
top default_partition PLL UTEST_LOGIC
top default_partition REC_MUX <local>
top default_partition SERIAL_CNTRL UTEST_LOGIC
top default_partition SERIAL_REG UTEST_LOGIC
top default_partition WRAPPER UTEST_LOGIC
You can use the remove_dft_location command to remove the location specification for
one or more test logic types. When a test logic type has no location specification, it is
inserted at its default location.
In a multiple partition flow, only the following test logic types can be specified on a
per-partition basis: DFTMAX, SERIAL_REG, PIPELINE_SI_LOGIC, LOCKUP_LATCH, REC_MUX.
For other test logic types, you can only specify the location for the default partition.
The following test logic types are not affected by the set_dft_location command:
• AutoFix logic
• Automatically inserted est points
• User-defined test points
• AND gates inserted by the insert_dft command to suppress toggling

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Creating New DFT Logic Blocks

When using the set_dft_location command, if a specified hierarchical cell does not exist,
the set_dft_location command issues a warning:
dc_shell> set_dft_location UCODEC -include {DFTMAX TCM}
Warning: Specified hierarchy name 'UCODEC' doesn't exist in the current
design 'test'. (UIT-1112)
Accepted DFT location specification.
1
dc_shell> set_dft_location UOCC -include {PLL}
Warning: Specified hierarchy name 'UOCC' doesn't exist in the current
design 'test'. (UIT-1112)
Overwriting previous DFT Hierarchy Location specification for type 'PLL'.
Accepted DFT location specification.
1
During DFT insertion, the insert_dft command creates the hierarchical cells before
inserting the DFT logic and issues information messages with the cell and design names of
the new DFT blocks:
dc_shell> insert_dft
...
Created instance 'UCODEC' of design 'top_dft_design'
Created instance 'UOCC' of design 'top_dft_design_1'
Architecting Scan Chains
You can specify cell instance names with the set_dft_location command, but the
resulting design names are automatically generated. To use specific design names for the
new DFT blocks, use the rename_design command after DFT insertion completes. For
example,
set_dft_location UCODEC -include {DFTMAX TCM}
set_dft_location UOCC -include {PLL}
insert_dft
rename_design [get_attribute [get_cells UCODEC] ref_name] CODEC_design
rename_design [get_attribute [get_cells UOCC] ref_name] OCC_design
Specifying a Location for Codec Logic Insertion

By default, the tool inserts DFT logic at the top level, or in the specified hierarchical instance
if the set_dft_location command is used. You can also specify the hierarchical instance
in which the codec logic is inserted by using the following command:
dc_shell> set_scan_compression_configuration -location instance_name
The specified instance name cannot be a library cell, black box, or black-box CTL model.
The instance name can be a CTL model if the complete .ddc netlist is available.

Note:
Compressed scan reconfiguration MUXs and test-mode decode logic are not placed in
the specified location.
For codec logic insertion, this command takes precedence over the set_dft_location
-include DFTMAX command. The specified location is stored as part of the codec
configuration. You can use the report_scan_compression_configuration command to
view the specified codec location.
When a top-down multiple partition flow is used, this feature can be used to place each
partition’s codec logic at a specified location. For example,
Example 5-3 Specifying Codec Logic Insertion Locations for Multiple Partitions
set_dft_location core ;# place all non-codec logic in core
define_dft_partition P1 -include BLK1

define_dft_partition P2 -include BLK2
set_scan_compression_configuration -chain_count 10 -location core/BLK1
set_scan_compression_configuration -chain_count 8 -location core/BLK2
Pipelined Scan Data

Pipelined scan data is a feature provided by the DFTMAX tool to resolve delay problems
associated with long routes in compressed scan chain logic.
• Introduction to Pipelined Scan Data
• Using Pipelined Scan Data
• Compressed Scan Flow With Pipelined Scan Data
• Pipelined Scan Data Specifications
• Pipelined Scan Data Test Protocol Format
• Pipelined Scan Data Limitations
• Hierarchical Flows With Pipelined Scan Data

Pipelined Scan Data 5-7
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Introduction to Pipelined Scan Data

In typical scan flows, long wires between the scan chain input and the first flip-flop and
between the last flip-flop and the scan chain output can cause delay problems. In
compressed scan, the compression technology further amplifies the problem. These delays
are reduced by placing pipeline registers at the beginning and end of the scan chains. They
divide the long routes between the scan chain terminals into smaller wires between the
registers and therefore help reduce the path delay.
Figure 5-1 shows an example of a compressed scan design with pipeline registers. The
head pipeline registers are placed between the scan inputs and the decompressor, and the
tail pipeline registers are placed between the compressor and the scan outputs.
Figure 5-1 Pipeline Registers in a Compressed Scan Design
+HDGSLSHOLQHUHJLVWHUV
&B&25(
7DLOSLSHOLQHUHJLVWHUV
The tool can automate the insertion of the head and tail pipeline registers around the codec,
or you can provide user-defined pipeline registers at the scan inputs and outputs that the
tool connects to the codec. Test DRC verifies the correct operation of the pipeline registers
and updates the test protocol that TetraMAX ATPG uses for pattern generation.
Using Pipelined Scan Data

The pipelined scan data feature provides two methods of specifying pipeline register
insertion:
• Pipeline registers can be automatically inserted and connected by the tool during the
insert_dft command.
• User-defined pipeline registers can be provided in the design logic. The tool makes the
needed scan path connections to these existing pipeline registers during the
insert_dft command.

These pipeline register insertion methods are explained in the following subsections:
• Enabling Pipelined Scan Data
• Automatically Inserting Head and Tail Pipeline Registers
• Specifying User-Defined Head and Tail Pipeline Registers
Enabling Pipelined Scan Data

For both the automatically inserted and user-defined pipeline register flows, use the
set_dft_configuration command to enable the pipelined scan data feature in the
compressed scan flow:
set_dft_configuration -pipeline_scan_data enable
By default, pipeline registers are not inserted.

The type of insertion method is determined by the commands you use to configure the
pipeline registers. You must choose either automatic or user-defined pipeline register
insertion, as these methods are mutually exclusive.
Automatically Inserting Head and Tail Pipeline Registers

The set_pipeline_scan_data_configuration command is used to configure the
automatic pipeline register insertion. Specify the number of head and tail pipeline stages
using the -head_pipeline_stages and -tail_pipeline_stages options:
set_pipeline_scan_data_configuration \
-head_pipeline_stages integer \
-tail_pipeline_stages integer \
-head_scan_flop true
The -head_scan_flop option causes the tool to create scan-replaced head pipeline
registers that hold their state during scan capture. For more information, see “Avoiding X
Capture in Head Pipeline Registers” on page 5-15.
DFT insertion uses a D flip-flop from the target library for the automatically inserted pipeline
registers. To minimize the need for lock-up latches at the compressed scan chains, the head
pipeline registers are clocked on the trailing clock edge, and the tail pipeline registers are
clocked on the leading clock edge. Rising-edge-triggered or falling-edge-triggered flip-flops
are used depending on whether the scan clock uses a return-to-zero or return-to-one
waveform. Figure 5-2 shows the flip-flops used for both types of clock waveforms.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Figure 5-2 Pipeline Registers in a Compressed Scan Design
6, 62 6, 62
5HWXUQWR]HURVFDQFORFN 5HWXUQWRRQHVFDQFORFN
Note:
If you enable leading-edge retiming registers using the set_scan_configuration
-add_test_retiming_flops command with the begin_only or begin_and_end option
values, the head pipeline registers are clocked on the leading clock edge instead.
The newly inserted pipeline registers have names of the form
SNPS_PipeHead_SI_pin_name_stage
SNPS_PipeTail_SO_pin_name_stage
where SI_pin_name is the scan in port, SO_pin_name is the scan out port, and stage is the
stage depth.
By default, a new test clock port named SNPS_PipeClk is created for the pipeline registers.
If you want to use an existing design clock instead, use the -head_pipeline_clock and
-tail_pipeline_clock options to specify the clock:
-head_pipeline_clock clock_name \
-tail_pipeline_clock clock_name \
-head_pipeline_stages integer \
-tail_pipeline_stages integer \
Use the report_pipeline_scan_data_configuration command to report the current

automatic insertion configuration, and the reset_pipeline_scan_data_configuration
command to reset the automatic insertion configuration.
The automatically inserted pipeline register flow is only available for compressed scan
designs created with the tool.
Specifying User-Defined Head and Tail Pipeline Registers

DFT Compiler can connect user-provided pipeline registers to the compressed scan logic.
You can use this feature to pre-place pipeline registers at strategic locations in tight
floorplans. DFT Compiler automatically makes the needed scan path connections during the
insert_dft command.

You can use the set_scan_path command to specify the scan data path connections to
these pipeline registers:
set_scan_path chain_name \
-scan_data_in port_name \
-scan_data_out port_name \
-pipeline_head_registers instance_list \
-pipeline_tail_registers instance_list \
-view spec
Note:
Do not specify a test mode for the set_scan_path command when defining pipeline
connections. The tool automatically propagates the specification to all test modes during
scan architecture.
Each set_scan_path command associates a set of existing head and/or tail pipeline
registers with a scan-in and scan-out port. A full scan path chain definition with scan
elements is not needed. You can provide a list of multiple pipeline registers to implement
multiple pipeline stages. The head and tail pipeline depths can be different.
For user-defined pipeline registers, you are responsible for the connections to the scan data
ports and between the pipeline stages, and for proper conditioning for the scan ports and
clocks to the pipeline registers. Figure 5-3 demonstrates the required connections for two
head pipeline registers and two tail pipeline registers per scan chain.
Figure 5-3 User-Defined Pipeline Registers and Connections
3LSHOLQHFRQQHFWLRQV
8VHUGHILQHGSLSHOLQHUHJLVWHUV &B&25( PDGHGXULQJ
')7LQVHUWLRQ
During DFT insertion, DFT Compiler makes connections from the pipeline registers to the
scan decompression MUX and XOR compressor logic, but does not check the validity of the
paths between the scan inputs and head registers and between the tail registers and the
scan outputs. After DFT insertion, the dft_drc command determines whether the scan
chains are shifting properly.
You can apply the set_size_only command to user-defined pipeline registers before the
first compile -scan command so that the registers are not removed by logic optimization.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Although the size_only property allows the compile -scan command to scan-replace the
pipeline registers with their scan equivalents, the insert_dft command will unscan the
pipeline registers before making the pipeline connections.
When user-defined pipeline registers are specified with the set_scan_path command, DFT
Compiler ignores any options relating to automatically inserted pipeline registers specified
with the set_pipeline_scan_data_configuration command.
Observe these additional requirements when implementing user-defined pipeline registers:
• Design the pipeline structures before DFT insertion so that the registers can be
referenced in the set_scan_path command.
• Ensure that the specified chain count and the number of scan chains are the same.
• Specify the head and tail pipeline registers with a full hierarchical name.
• Specify the corresponding scan input and output ports for each external chain.
• Specify the pipeline registers in scan order, from input pin to scan chain, and from scan
chain to output pin.
• All head pipeline registers must be triggered by the same clock. All tail pipeline registers
must be triggered by the same clock. The clock can be dedicated or shared with other
scan flip-flops.
• DFT Compiler accepts any clocking scheme that ensures correct scan shift. However, a
good rule to follow is to have all the head pipeline registers triggered by the latest edge
of the shift clocks and to have the tail registers triggered by the earliest edge of the shift
clocks.
• All head pipelines must have the same depth, and all tail pipelines must have the same
depth.
• Design your head pipeline registers to retain their values or propagate a constant value
during the capture cycles for optimal ATPG results. This prevents unknown values from
propagating to the unload data. For more information, see “Avoiding X Capture in Head
Pipeline Registers” on page 5-15.
• The tail registers are assumed to have unknown values at the beginning of unload and
do not need to maintain the state.
The user-defined pipeline register flow is available in both the DFT Compiler and DFTMAX
tools.

Compressed Scan Flow With Pipelined Scan Data

The compressed scan flow with pipelining is similar to the regular scan flow. It follows the
typical methodology of specify, preview, and insert. The tool wires the scan chain elements,
and if necessary, inserts synchronization logic and generates appropriate test protocol files
to be used in automatic test pattern generation (ATPG).
The following steps demonstrate a compressed scan flow with pipelining. This command
sequence example applies to an unmapped design.
1. Read the design.
dc_shell> read_file -format verilog rtl.v
dc_shell> current_design top
dc_shell> link
2. Choose a scan style for your design.

dc_shell> set_scan_configuration \
-style multiplexed_flip_flop
3. Perform a test-ready compile.

dc_shell> compile -scan
4. Specify scan clocks and other DFT signals.

dc_shell> for {set i 0} {$i < 3i} {incr i} {
set_dft_signal -view spec \
-type ScanDataIn -port SI_$i \
-test_mode all
set_dft_signal -view spec \

-type ScanDataOut -port SO_$i \
-test_mode all
}
dc_shell> set_dft_signal -view spec \

-type Reset -port resetn -active_state 0
dc_shell> set_dft_signal -view spec \

-type ScanEnable -port test_se \
-active_state 1
5. Enable compressed scan and pipelined scan data.

dc_shell> set_dft_configuration \
-pipeline_scan_data enable \
-scan_compression enable

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
-xtolerance default
6. Specify the scan architecture.

dc_shell> set_scan_configuration \
-chain_count 32 -clock_mixing mix_clocks
7. Enable automatic pipeline register insertion, or specify user-defined pipeline register

scan path connections.
a. For automatically inserted pipeline registers:
dc_shell> set_pipeline_scan_data_configuration \
-head_pipeline_clock CLK \
-tail_pipeline_clock CLK \
-head_pipeline_stages 1 \
-tail_pipeline_stages 2 \
dc_shell> set_scan_path chain0 -view spec \

-scan_data_in SI_0 \
-scan_data_out SO_0
. . .

-scan_data_in SI_31 \
-scan_data_out SO_31
The -head_scan_flop option is used to prevent the head pipeline registers from
capturing during scan capture.
b. For user-defined pipeline register connections:
-pipeline_head_registers \
{head_pipe_0_reg} \
-pipeline_tail_registers \
{tail_stage1_pipe_0_reg tail_stage2_pipe_0_reg} \
-scan_data_in test_SI_0 \
-scan_data_out test_SO_0
. . .

-pipeline_head_registers \
{head_pipe_31_reg} \
-pipeline_tail_registers \
{tail_stage1_pipe_31_reg tail_stage2_pipe_31_reg} \
-scan_data_in test_SI_31 \
-scan_data_out test_SO_31

8. Generate a test protocol and check for design violations by running the test design rule
checking at the gate level.
dc_shell> create_test_protocol
dc_shell> dft_drc
9. Preview the scan structures.

dc_shell> preview_dft
10. Build the scan structures into your design.

dc_shell> set_dft_insertion_configuration \
-synthesis_optimization none \
-preserve_design_name true
dc_shell> insert_dft
11. Write out the pipeline-inserted netlist and the test protocol files.
dc_shell> report_scan_path -view spec \
-chain all
dc_shell> report_scan_configuration
dc_shell> change_names -rules verilog -hierarchy
dc_shell> write -format ddc -hierarchy -output design.ddc
dc_shell> write -format verilog -hierarchy -output design.v
dc_shell> write_test_protocol \
-output ScanCompression.spf \
dc_shell> write_test_protocol -output Scan.spf \

Avoiding X Capture in Head Pipeline Registers

When pipelined scan data is used in a compressed scan flow, the head pipeline registers
should hold their state or capture a constant value during the capture cycle. This prevents
unknown X values from being captured in the head pipeline registers, which would then get
propagated through the decompression MUX and into the compressed scan chains.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
The following methods can be used to capture known values in the head pipeline registers
during scan capture:
• Capture the current register output state during scan capture, as shown in Figure 5-4.
Figure 5-4 Head Pipeline Register With State-Holding Scan Flip-Flop
6, ' 4 ' 4 62
6,
6( 6(
&/.
If you are using the automatic pipeline insertion flow, specify the -head_scan_flop
true option of the set_pipeline_scan_data_configuration command. The tool will
use scan head pipeline registers, and tie each register’s output to its functional data input
so that the state is held during scan capture.
• Use a dedicated head pipeline register clock, as shown in Figure 5-5.
Figure 5-5 Head Pipeline Register With Dedicated Clock
6, ' 4 ' 4 62
3&/.
&/.
If you are using the automatic pipeline insertion flow, you can specify a dedicated head
pipeline register clock using the -head_pipeline_clock option of the
set_pipeline_scan_data_configuration command.
If the clock is independently controllable from the top level, you should add a constraint
in the TetraMAX tool to suppress the dedicated head pipeline register clock during scan
capture.

• Use a gated head pipeline register clock, as shown in Figure 5-6.

Figure 5-6 Head Pipeline Register With Gated Clock
6, ' 4 ' 4 62
6(
&/.
There is no option to implement a gated clock in the automatic pipeline register insertion
flow.
• Capture a constant value during scan capture, as shown in Figure 5-7.
Figure 5-7 Head Pipeline Registers With Constant Value Capture
RU
6, ' 4 ' 4 62
6(
&/.
There is no option to implement a constant value capture in the automatic pipeline
register insertion flow.
Post-DFT DRC verifies whether the head pipeline registers hold their values during capture
and issues an R-18 violation message if the check is unsuccessful.
Pipelined Scan Data Specifications

This section has the following subsections:
• Scan Architecture
• Scan Register Synchronization
Scan Architecture
While implementing the pipelined scan data, DFT Compiler takes the following aspects into
consideration:
• User-defined pipeline registers and automatically inserted pipeline registers are mutually
exclusive.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
• The specification of head and tail pipeline registers is automatically propagated from the
standard scan mode to its corresponding compression mode.
• Pipeline registers are automatically excluded from scan replacement. This exclusion
takes precedence over any other scan membership specifications, such as the
set_scan_path command and the -include and -exclude options of the
set_scan_configuration command.
• There is no optimization to minimize the number of lock-up latches at the beginning or

the end of the scan chains.
• Inversions in the pipelined scan data path are supported.
• DFT Compiler ignores pipeline registers during synthesis of compressed scan chains.
Scan Register Synchronization

DFT Compiler has the following requirements for scan synchronization:
• DFT Compiler checks whether synchronization between head pipeline registers and
scan chains can be done. It also checks for synchronization between scan chains and tail
pipeline registers. If there is a discrepancy, an error message is displayed and scan
architecting or insertion is prevented.
• The clock signal triggering the lock-up element at the beginning of the chain is the
inversion of the clock signal triggering the first flip-flop of the same chain. Similarly, the
clock signal triggering the lock-up element at the end of the chain is the inversion of the
clock signal triggering the last flip-flop of the chain.
• DFT Compiler does not insert synchronization elements inside black-box modules. You
need to plan for synchronization of the scan segment at the block level. You must also
control the clocking scheme to avoid shifting problems.
Pipelined Scan Data Test Protocol Format

The test protocol file generated for the internal scan mode is the same as in a normal scan
flow. The test protocol file generated for the scan compression mode contains information
about the pipeline registers. The test protocol file has the following additional information:
• The number of head pipeline stages is indicated by the LoadPipelineStages keyword.
• The number of tail pipeline stages is indicated by the UnloadPipelineStages keyword.
See the following example:
CompressorStructures {
LoadPipelineStages 3;
UnloadPipelineStages 2;

Compressor des2_U_decompressor {
ModeGroup mode_group;
LoadGroup load_group;
Modes 3;
...}
Compressor des2_U_compressor {
UnloadGroup unload_group;
Mode {{....}}
}
Pipelined Scan Data Limitations

These are the requirements and limitations for implementing pipeline registers in a
compressed scan flow:
• For maximum observability, the head pipeline flip-flops must hold state during the
capture cycle to avoid capturing unknown X values.
• Compressed scan does not support unbalanced pipelining across chains. The number of
head pipeline stages does not need to match the number of tail pipeline stages, but all
decompressor inputs and all compressor outputs—including any associated with
compressed clock chains—must have the same pipeline depth.
• If you are using external (uncompressed) chains, such as external clock chains or other
user-defined external chains, their pipeline depths must match other scan chains. For
more information, see “Excluding Scan Chains From Scan Compression” on page 2-35.
• Scan-enable pipelining is independent of compressor scan data pipelining. Scan-enable
signals can have any number of pipeline stages; however, the logic must be such that the
load_unload and capture operations can be independently verified by DRC. For example,
test_setup and/or load_unload preamble must set the design in shift mode, so that when
the scan-enable signal is at the nonshift value, the flip-flops are able to capture the
system data.
• All head pipeline registers must use the same clock, and all tail pipeline registers must
use the same clock.
• In a HASS flow, each core may use a different set of clocks for the head and tail pipeline
registers.
• Any combinational logic between the scan ports and the pipeline registers must be
sensitized to a known state.
• An ATE clock that is defined with the set_dft_signal -type Oscillator command
cannot be used to directly clock either the head or tail pipelined scan data registers. If the
DFT-inserted OCC controller flow is used together with pipeline register insertion,

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
specification of the ATE clock as the pipeline clock results in the OCC-controlled clock
being used by default. If the ATE clock is manually connected to the pipeline registers, no
violations will be reported, but incorrect ATPG patterns might be generated.
• Multiple test-mode operation with user-defined pipeline registers is not supported.
However, multiple test-mode operation with automatically inserted pipeline registers is
supported.
Hierarchical Flows With Pipelined Scan Data

In hierarchical flows, you can enable pipelined scan data at the chip level. When
compressed scan cores already contain pipeline stages, the DFTMAX tool incrementally
adds top-level pipeline stages as needed to meet the top-level pipeline depth target. This is
known as incremental pipelining.
Consider a core created with a pipeline depth of one:
-head_pipeline_clock clk \
-tail_pipeline_clock clk
When this core is integrated at the chip level, the chip-level pipeline depth is set to two:
-head_pipeline_clock clk \
-tail_pipeline_clock clk
Figure 5-8 shows how the tool adds an additional pipeline stage to meet the chip-level
target. The bolded flip-flops are added at the chip level during integration.
Figure 5-8 Hierarchical Pipelined Scan Data Example

At the core level, the pipeline registers can be driven by a shared functional clock or a
dedicated pipeline clock. At the chip level, you typically connect this core-level clock pin to
the desired chip-level clock signal. However, in the automatically inserted pipeline register
flow, if you have a dedicated core-level pipeline clock pin that is unconnected at the chip
level, the tool automatically connects it to the chip-level pipeline clock.
General Rules
The following general rules apply to all integration flows where cores are integrated at the
chip level with pipelined scan data enabled:
• Pipelined scan data must be enabled when integrating pipelined cores, even if no
additional pipeline stages are added at the top level.
• During chip-level integration, the tool adds pipeline stages as needed to meet the
top-level pipeline depth specification.
• The core-level and chip-level pipeline clocks can differ. Lockup latches are automatically
inserted as needed.
• Unconnected core-level pipeline clock pins (whether DFT-created or user-defined) are
automatically connected to the chip-level pipeline clock signal (whether DFT-created or
user-defined).
Pipelined Scan Data in the Standard Scan HSS Flow

In the standard scan HSS flow, note the following:
• DFT Compiler supports only unpipelined standard scan cores in hierarchical flows.
Pipelined standard scan cores are not supported.
• The scan chains in standard scan cores can be used as scan segments that are mixed
with other scan cells or scan segments.
Figure 5-9 shows these properties.

Figure 5-9 Integration Properties for the Pipelined Standard Scan HSS Flow

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Pipelined Scan Data in the HASS and Hybrid Flows

Figure 5-10 shows incremental pipelining in the HASS and Hybrid core integration flows. In
the Hybrid flow, the tool also adds pipeline stages around the top-level codec to meet the
top-level pipeline depth.
Figure 5-10 Incremental Pipelining in the HASS and Hybrid Flows
HASS integration flow Hybrid integration flow
For more information on the HASS flow, see “The HASS Flow” on page 3-3. For more
information on the Hybrid flow, see “The Hybrid Flow” on page 3-9.
Sharing Codec Scan I/O Pins

Adaptive scan technology provides design testability with reduced scan pin count
requirements. However, the tool normally requires each codec to have dedicated scan-in
and scan-out pin connections. For large designs with many blocks and many separate
codecs, the scan pin requirements can still be challenging for pin-limited designs.
The tool allows multiple codecs to share the same scan-in and scan-out pins or ports in the
HASS and Hybrid flows, as shown in Figure 5-11. This is known as codec I/O sharing.

Sharing Codec Scan I/O Pins 5-22
Figure 5-11 Dedicated Codec I/O Connections and Shared Codec I/O Connections
&B&25( &B&25( &B&25( &B&25(
6KDULQJFRPSUHVVRU
'HGLFDWHGFRGHF,2FRQQHFWLRQV
6KDUHGFRGHF,2FRQQHFWLRQV
Codec I/O sharing provides the following features:

• I/Os can be shared across codecs of different widths.
• When codec inputs have dissimilar widths or when an increased number of scan inputs
is provided, the codec input connections are allocated evenly across the scan inputs.
• You can combine shared codec inputs with dedicated codec outputs.
• You can create multiple shared codec I/O groups.
For a list of the limitations of the shared codec I/O feature, see “Limitations” on page 5-51.
• Specifying the I/O Sharing Configuration
• Determining the Fully Shared I/O Configuration
• Codec I/O Sharing in the HASS Flow
• Codec I/O Sharing in the Hybrid Flow
• Codec I/O Sharing in the Top-Down Flat Flow
• Codec I/O Sharing With Identical Cores
• Codec I/O Sharing Groups
• Codec I/O Sharing and Standard Scan Chains
• Codec I/O Sharing and Pipelined Scan Data
• Integration of Cores With Shared Codec I/O Connections
• Limitations

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Specifying the I/O Sharing Configuration

To share codec scan I/O pins, use the -shared_inputs and -shared_outputs options of
the set_scan_compression_configuration command:
-shared_inputs M
-shared_outputs N
The value M specifies the size of the set of shared scan-in pins used for all codec input
connections. The value N specifies the size of the set of shared scan-out pins used for all
codec output connections. These values pertain only to the scan I/O signals needed for
codec connections; scan I/O signals for external chains in compressed scan mode and for
scan chains in standard scan mode should not be included in these values.
Figure 5-12 shows two compressed scan cores with connections that are fully shared using
the set_scan_compression_configuration -shared_inputs 4 -shared_outputs 4
command. The first codec has four I/O pins and the second codec has three I/O pins. A
minimum shared set of four top-level scan I/O pins is required to satisfy the connections of
the wider codec. All shared scan inputs are tied together, and the scan outputs are
combined with an output sharing compressor block.
Figure 5-12 Compressed Scan Mode Operation for Two Codecs With Fully Shared I/O
VKDUHGBLQSXWV
&B&25( &B&25(
6KDULQJFRPSUHVVRU
VKDUHGBRXWSXWV
You can use the -shared_inputs option to set the number of shared scan inputs to any
value from fully shared to unshared, inclusive. You can use the -shared_outputs option to
set the number of shared scan outputs, but only to either the fully shared or unshared value.
For more information on computing the fully shared configuration, see “Determining the
Fully Shared I/O Configuration” on page 5-26.

Note:
If you specify the fully unshared (dedicated) outputs value, you must use the flow
described in “Specifying Shared Codec Inputs With Dedicated Codec Outputs” on
page 5-37.
To enable the codec I/O sharing feature, you must specify the -shared_inputs option. The
-shared_outputs option by itself does not enable codec I/O sharing. If you specify the
-shared_inputs option without the -shared_outputs option, the codec outputs are
automatically fully shared.
As you increase the number of shared scan inputs, the amount of sharing decreases and the
controllability of the compressed scan chains increases, respectively. Figure 5-13 shows the
same two codecs with the -shared_inputs 6 option specified.
Figure 5-13 Two Codecs With Reduced Scan-In Pin Sharing
VKDUHGBLQSXWV
&B&25( &B&25(
6KDULQJFRPSUHVVRU
If you provide fewer than the fully shared number of scan inputs with the -shared_inputs
option, the tool issues the following warning message and proceeds with the fully shared
input value:
Warning: Your request for 3 shared codec scan inputs in partition
default_partition cannot be met; 4 shared scan inputs will be used
instead. (TEST-1420)
If you provide fewer than the fully shared number of scan outputs with the -shared_outputs
option, a similar warning message and adjustment occurs:
Warning: Your request for 3 shared codec scan outputs in partition
default_partition cannot be met; 4 shared scan outputs will be used
DFT insertion places the output sharing compressor at the top level by default. To insert the
sharing compressor inside a specific hierarchical block, specify the location using the
set_dft_location -include XOR_SELECT command. For more information, see
“Specifying a Location for DFT Logic Insertion” on page 5-2.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Determining the Fully Shared I/O Configuration

The configuration with the minimum number of shared inputs and outputs for a design is
called the fully shared configuration. It is described in more detail in the following sections:
• Determining Shared Input Pin Types
• Adding High X-Tolerance Block-Select Pins
• Automatically Computing the Fully Shared Configuration
• Manually Computing the Fully Shared Configuration
Note:
For simplicity, shared codec I/O figures outside this section do not separate input pins
into different categories.
Determining Shared Input Pin Types

When you share the scan input connections of compressed scan codecs, their scan-in pins
are categorized for sharing, as described in the following sections:
• Scan-In Pins That Drive Compressed OCC Clock Chains
• Load Mode Scan-In Pins
• High X-Tolerance Enable Scan-In Pins
• Regular Scan-In Data Pins
Scan-In Pins That Drive Compressed OCC Clock Chains

By default, when you insert scan compression in an OCC controller flow, the clock chain is
compressed. the DFTMAX tool dedicates a decompressor scan input path to the clock chain
as shown in Figure 2-6 on page 2-27. This allows the clock chain values to be controlled
without imposing constraints on other scan cells.
When you use codec I/O sharing, codec inputs that drive compressed clock chains cannot
be shared. However, you must still include these inputs in the value provided to the
-shared_inputs option. Figure 5-14 shows two compressed scan cores, where one core,
C_CORE1, has a compressed clock chain driven by a dedicated codec scan input. The fully
shared input value in this example is five.

Figure 5-14 Dedicated Scan Inputs for Compressed Clock Chains

6KDUHGORDGPRGHSLQV
'HGLFDWHGFRPSUHVVHG
6KDUHGUHJXODUVFDQLQGDWDSLQV
FORFNFKDLQVFDQLQSLQ
2&&
&B&25( &B&25(
FRQWUROOHU
6KDULQJFRPSUHVVRU
If you are using the Hybrid flow with a top-level OCC controller and the top-level codec
compresses the clock chain of the top-level OCC controller, you must include a scan input
for the top-level codec.
If you are using external clock chains, do not include them in the value provided to the
-shared_inputs option; they are excluded from scan compression.
For more information on compressed clock chains and external clock chains, see “Scan
Compression and OCC Controllers” on page 2-27.
Load Mode Scan-In Pins

In a DFTMAX codec, some of the scan-in data pins are designated as load-mode pins.
When you use codec I/O sharing, load-mode pins can be shared, but only with other
load-mode pins. Figure 5-15 shows the fully shared configuration for two cores with different
load-mode pin counts.
Figure 5-15 Two Codecs With Different Load-Mode Pin Counts
6KDUHGORDGPRGHSLQV 6KDUHGUHJXODUVFDQLQGDWDSLQV
&B&25( &B&25(
For more information on load-mode pins, see “Decompressor Operation” on page 1-4.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
High X-Tolerance Enable Scan-In Pins

High X-tolerance enable scan-in pins are pins that enable high X-tolerance masking. A high
X-tolerance core or codec has only one of these pins. When you use codec I/O sharing,
these high X-tolerance enable scan-in pins can be shared, but only with other high
X-tolerance enable scan-in pins. Figure 5-16 shows the fully shared configuration for two
high X-tolerance cores.
Figure 5-16 Two Codecs With Different Load-Mode Pin Counts
6KDUHG 6KDUHGORDGPRGHSLQ
KLJK;WROHUDQFH 6KDUHGUHJXODUVFDQLQGDWDSLQV
HQDEOHSLQV
&B&25( &B&25(
Because codec I/O sharing requires that all codecs have the same X-tolerance type, these
enable pins do not impose any complexity on the fully shared input computation. If high
X-tolerance is used, all codecs have a single high X-tolerance enable pin, which is shared
as other scan-in data pins are shared.
For more information on high X-tolerance enable pins, see “The High X-Tolerance
Architecture” on page 4-2.
Regular Scan-In Data Pins

Regular scan-in data pins are all remaining pins that do not fall into the other three
categories. When you use codec I/O sharing, regular scan-in data pins can be shared, but
only with other regular scan-in data pins.
Adding High X-Tolerance Block-Select Pins

When you share the scan-out pins of high X-tolerance codecs, you must allow for additional
scan-in pins to provide block-select X-masking signals for the output sharing compressor.
Figure 5-17 shows the additional block-select signal connections.

Figure 5-17 Adding Shared Inputs for High X-Tolerance Block-Select Signals
VKDUHGBLQSXWV
&B&25( &B&25(
+LJK;WROHUDQFH +LJK;WROHUDQFH
6KDULQJFRPSUHVVRU
The number of additional block-select scan-in pins N is equal to log2 of the number of
shared codecs, rounded up to the next integer value. This number must be included in the
value provided to the -shared_inputs option. Table 5-2 shows the number of additional
scan-in pins required as a function of the number of shared codecs.
Table 5-2 Number of Additional Scan Data Inputs Required for Codec Sharing
Number of shared codecs Required number of additional scan data inputs
2 1
3 to 4 2
5 to 8 3
9 to 16 4
17 to 32 5
33 to 64 6
The preview_dft command at the integration level reports the block-select signal
connections that will be created. Example 5-4 shows the preview report for two shared-I/O
codecs.
Example 5-4 Shared Codec I/O Block Select Signals in preview_dft Report
ScanDataIn Ports:
(si) shows Regular ScanDataIn signal

(lm) shows Load Mode signal
(sel) shows Block Select signal
(xtol) shows Xtol Enable signal

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
test_si1 (drives C_CORE1/test_si1) (si)

test_si2 (drives C_CORE1/test_si2) (lm)
test_si4 (drives C_CORE1/test_si4) (xtol)
test_si1 (drives C_CORE2/test_si1) (si)

test_si4 (drives C_CORE4/test_si3) (xtol)
test_si5 (drives U_sharing_compressor/bsel[0]) (sel)

test_si4 (drives U_sharing_compressor/xtol_enable) (xtol)
Automatically Computing the Fully Shared Configuration

To automatically compute the fully shared configuration, use the preview_dft command.
Specify a value of 1 for the -shared_inputs and -shared_outputs options, run the
preview_dft command, and obtain the values reported in the TEST-1420 and TEST-1421
warning messages.
For example,
-shared_inputs 1 -shared_outputs 1
...
Warning: Your request for 1 shared codec scan inputs in partition
default_partition cannot be met; 4 shared scan inputs will be used
Warning: Your request for 1 shared codec scan outputs in partition
default_partition cannot be met; 4 shared scan outputs will be used
This approach is useful when codec information is not readily available for cores or codecs,
such as when you do not have the CTL models available in an integration flow or you are
using the top-down flat insertion flow and the codecs do not yet exist.
Manually Computing the Fully Shared Configuration

This section describes how to manually compute the fully shared configuration. You can use
this approach if the preview report takes too long to generate or if you are designing
core-level scan architectures to meet a particular top-level sharing goal.
Note:
If you are using the Hybrid integration mode, include the top-level codec in these
computations.

To manually compute the fully shared input configuration value, which is the minimum value
that can be specified with the -shared_inputs option, do the following:
1. If all codecs have the same load-mode pin count, compute the maximum scan-in width
of all codecs to be shared, then go to step 3.
If you do not know this information, use the automatic computation method described in
“Automatically Computing the Fully Shared Configuration” on page 5-30.
2. If some codecs have different load-mode pin counts, do the following:
a. For each codec to be shared, separate the scan-in pins into load-mode pins and
non-load-mode pins.
The non-load-mode pins are the remaining scan-in pins that are compressed clock
chain scan-in pins, high X-tolerance enable pins, or regular scan-in data pins.
b. Compute the maximum load-mode pin count value across all codecs.
c. Compute the maximum non-load-mode pin count value across all codecs.
d. Add together the maximum values from steps 2b and 2c, then go to step 3.
3. If compressed clock chains are used, add the number of compressed clock chain scan-in
pins because these pins cannot be shared.
4. If high X-tolerance is used, add N additional scan inputs for block-select signals, where
N is equal to log2 of the number of shared codecs, rounded up to the next integer value.
For more information, see “Adding High X-Tolerance Block-Select Pins” on page 5-28.
To manually compute the fully shared output configuration value, which is the minimum
value that can be specified with the -shared_outputs option, compute the maximum
scan-out width of all codecs to be shared.
Codec I/O Sharing in the HASS Flow

In the HASS flow, one or more compressed scan cores are integrated at the top level.
Figure 5-12 shows two cores with fully shared codec I/O connections. The first codec has
four I/O pins and the second codec has three I/O pins; the values for the -shared_inputs
and -shared_outputs options of the set_scan_compression_configuration command
are determined by the wider codec.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Figure 5-18 HASS Flow With Full Codec I/O Sharing

VKDUHGBLQSXWV
&B&25( &B&25(
6KDULQJFRPSUHVVRU
VKDUHGBRXWSXWV
Codec I/O Sharing in the Hybrid Flow

In the Hybrid flow, a new codec is inserted at the top level along with existing block-level
codecs. When the codec I/O sharing feature is not used, only the remaining scan data pins
not used by the existing block-level codecs are used for the new top-level codec. Figure 5-19
shows a top-level design where the new top-level codec uses the remaining three available
scan data I/O connections.
Figure 5-19 Hybrid Flow With Codec I/O Sharing Disabled
&B&25(
VHWBVFDQBFRPSUHVVLRQBFRQILJXUDWLRQLQSXWVRXWSXWV
When codec I/O sharing is performed, the new top-level codec can use some or all of the
scan input pins used by the existing block-level codecs. Figure 5-20 shows an example of
partial scan-in sharing and Figure 5-21 shows an example of full scan-in sharing.

Figure 5-20 Hybrid Flow With Some Codec Input Sharing

&B&25(
6KDULQJFRPSUHVVRU
VKDUHGBLQSXWVVKDUHGBRXWSXWV
Figure 5-21 Hybrid Flow With Full Codec Input Sharing

&B&25(
6KDULQJFRPSUHVVRU
VKDUHGBLQSXWVVKDUHGBRXWSXWV
The I/O sharing feature provides a degree of freedom in the construction of the new top-level
codec. Because the top-level codec characteristics can no longer be derived from other
scan configuration information in the Hybrid flow, you must explicitly configure the top-level
codec characteristics using the -inputs and -outputs options of the
set_scan_compression_configuration command.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Codec I/O Sharing in the Top-Down Flat Flow

In a normal top-down flat flow, multiple codecs are created by defining multiple DFT
partitions. Each partition specifies the scan logic to be scan-compressed with a codec.
However, each DFT partition is an independent scan context with its own scan configuration.
This prevents the codec I/O sharing feature from being applied as follows:
• Scan I/O ports can only belong to one partition at a time; they cannot be shared across
partitions.
• There is no single partition to attach the codec I/O sharing specification.
To remedy this, the top-down flat flow uses subpartitions to enable codec I/O sharing. A
subpartition is defined with the define_dft_partition command, and specifies the scan
logic to be scan-compressed with a codec. These subpartitions are then grouped together
into top-level partitions, which can receive codec I/O sharing and scan port specifications.
This flow is configured as follows:
1. Define the subpartitions containing the logic to be scan-compressed with a codec.
2. Define a top-level partition containing the subpartitions that should share their codec I/O
connections.
3. Configure codec characteristics within each subpartition.
4. Configure the shared codec I/O characteristics within each top-level partition.
The following example defines two codecs with shared I/O connections in a top-down flat
flow:
# globally enable scan compression
# define subpartitions that define codecs

define_dft_partition SUB_P1 -include {BLK1}
# define top-level partition that groups subpartition codecs together

define_dft_partition PARTITION -include {SUB_P1 SUB_P2} ;# subpartitions
# apply subpartition codec characteristics

current_dft_partition SUB_P1

# apply top-level codec I/O sharing characteristics

current_dft_partition PARTITION
set_scan_compression_configuration -shared_inputs 3 -shared_outputs 3
Note:
Subpartition definitions are only supported in a shared codec I/O flow.
Figure 5-22 shows the top-down flat DFT insertion results for these commands.
Figure 5-22 Top-Down Flat Flow Codec I/O Sharing
3$57,7,21
68%B3
68%B3
%/. %/.
6KDULQJFRPSUHVVRU
When you use the shared codec I/O feature in a top-down flat flow, all scan logic to be
compressed must be placed into subpartitions. If scan cells in a partition exist outside a
subpartition, the tool places them into an external chain that is not compressed inside that
partition. See Figure 5-23.
Figure 5-23 Partition-Level External Chains in Top-Down Flat Flow
3$57,7,21
68%B3
68%B3
%/. %/.
6KDULQJFRPSUHVVRU
Codec I/O Sharing With Identical Cores

If you are integrating multiple identical instances of a core, DFTMAX compression can take
advantage of their identicality to optimize their scan-in and scan-out connections for
improved testability.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Identical cores have the same functional and scan logic structures. Because of this,
DFTMAX compression optimizes shared codec I/O connections of identical cores as follows:
• Identical scan input connections are used so that each pattern sensitizes the same faults
across all cores.
• Identical scan output connections are used to reduce the impact of X values on pattern
count.
Figure 5-24 shows the codec scan data connections for two instances of COREA, two
instances of COREB, and a single instance of COREC.
Figure 5-24 Codec Scan Data Connections for Groups of Identical Cores

&25($B &25($B &25(%B &25(%B &25(&

6KDULQJFRPSUHVVRU

The tool does not identify identical core instances by default; you must specify them with the
-identical_cores option of the set_scan_compression_configuration command.
Wildcards are supported. For example,
-shared_inputs 4 -shared_outputs 4 \
-identical_cores {COREA_* COREB_*}
If there are multiple groups of identical cores, as in the previous example, the tool analyzes
them to determine the identicality grouping. Cores are considered identical when the
following codec parameters match:
• Decompressor input width
• Compressor output width
• X-tolerance configuration
• Compressed scan chain count

If your design generates few X values, you can use nonidentical (scrambled) scan output
connections for the identical cores to potentially improve the diagnosability of the design. To
do this, set the -scramble_identical_outputs option to true when you configure
identical cores with the set_scan_compression_configuration command. Scrambled
output connections, shown in Figure 5-25, provide more uniqueness in the output signatures
of each identical core.
Figure 5-25 Using Scrambled Output Connections for Identical Cores
&25($B &25($B &25(%B &25(%B &25(&

6KDULQJFRPSUHVVRU

The preview_dft and insert_dft commands print information messages that show the
identical core groups:
Information: Detected group of identical cores: COREA_1 COREA_2
(TEST-1450)
Information: Detected group of identical cores: COREB_1 COREB_2
(TEST-1450)
You can use these messages to confirm that identical cores are identified as expected.
When you run TetraMAX ATPG, use the -shared_io_analysis option of the set_atpg
command. This option performs an analysis to identify all identical circuit networks in the
identical cores, which results in improved pattern generation. This option is available
beginning with the TetraMAX H-2013.03-SP1 release.
Specifying Shared Codec Inputs With Dedicated Codec Outputs

You might want to use identical shared codec input connections for identical cores while still
using dedicated codec output connections. This configuration reduces the scan-in pin
requirements while providing full output observability with no sharing compressor required.
Figure 5-26 shows an example of this sharing configuration.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Figure 5-26 Example of Shared Codec Inputs With Dedicated Codec Outputs
VKDUHGBLQSXWV
&B&25($B &B&25($B
VKDUHGBRXWSXWV
The tool uses this sharing configuration when the following requirements are met:
• All cores are identical. Cores are considered identical when the following codec
parameters match:
❍ Decompressor input width
❍ Compressor output width
❍ X-tolerance configuration
❍ Compressed scan chain count
• The value specified for the -shared_inputs option is equal to the shared codec input
width.
• The value specified for the -shared_outputs option is equal to the sum of all shared
codec output widths.
When the tool detects that these requirements are met, it issues the following information
message:
Information: You have asked for shared codec inputs and dedicated codec
outputs in partition partition_name. (TEST-1446)
Note:
In this flow, the identical cores are automatically identified. You do not need to use the
-identical_cores option as described in “Codec I/O Sharing With Identical Cores” on
page 5-35.
Because there is no sharing of codec outputs, no sharing compressor is required. This also
means that no additional shared codec I/O block-select signals must be included in the
-shared_inputs value when using high X-tolerance. For more information on block-select
signals, see “Adding High X-Tolerance Block-Select Pins” on page 5-28.

Codec I/O Sharing Groups

You can use DFT partitions to share I/O connections within multiple codec groups. You can
use this flow to reduce routing congestion by only sharing the connections of codecs that are
in close proximity to each other or to optimize the sharing arrangement for identical cores.
DFT insertion places each partition’s sharing compressor at the top level by default. To
insert a partition’s sharing compressor inside a specific hierarchical block, specify the
location using the set_dft_location -include XOR_SELECT command applied within that
partition’s configuration. For more information, see “Specifying a Location for DFT Logic
Insertion” on page 5-2.
• Defining Sharing Groups in the HASS Flow
• Defining Sharing Groups in the Hybrid Flow
• Defining Sharing Groups in the Top-Down Flat Flow
Defining Sharing Groups in the HASS Flow

In the HASS flow, create and configure sharing groups as follows:
1. Define DFT partitions containing the compressed scan cores that are to share their
codec I/O connections.
2. Configure the shared codec I/O characteristics within each partition.
The following example defines two DFT partitions, where each contains two compressed
scan cores:
# globally enable scan compression and HASS integration
set_scan_compression_configuration -integration_only true
# define partitions that group cores

define_dft_partition PARTITION1 -include [list C_CORE1 C_CORE2]
# apply codec I/O sharing characteristics

Figure 5-27 shows the HASS integration results for these commands.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Figure 5-27 HASS Flow Codec I/O Sharing With Partitions

3$57,7,21
3$57,7,21
&B&25( &B&25( &B&25( &B&25(
6KDULQJFRPSUHVVRU 6KDULQJFRPSUHVVRU
Defining Sharing Groups in the Hybrid Flow

In the Hybrid flow, there are one or more compressed scan cores along with additional
top-level logic to be compressed. You can create one or more top-level codecs to compress
this logic, and you can choose whether or not to share the connections of each top-level
codec, as described in the following sections:
• Using Shared Codecs for Top-Level Logic
• Using Dedicated Codecs for Top-Level Logic
You can define multiple partitions to create multiple top-level codecs, including a mix of
shared and dedicated top-level codecs.
Note:
A top-level codec is a codec that compresses top-level logic, which is logic that exists
outside a compressed scan core. A top-level codec can be defined in a subpartition (for
a shared top-level codec) or in a top-level partition (for a dedicated top-level codec).
Using Shared Codecs for Top-Level Logic

You can define subpartitions to specify the top-level scan logic to be scan-compressed with
a shared codec. For more information on subpartitions, see “Codec I/O Sharing in the
Top-Down Flat Flow” on page 5-34.
In this flow, create and configure sharing groups as follows:
1. Define any subpartitions containing the logic to be scan-compressed with a top-level
shared codec.
2. Define top-level partitions containing the compressed scan cores and/or subpartitions
that are to share their codec I/O connections.
3. Configure the top-level logic codec characteristics within each subpartition.

The following example defines two top-level DFT partitions, each of which contains two
shared-I/O codecs:
# globally enable scan compression and Hybrid integration
# define subpartitions that define the new top-level codecs

define_dft_partition SUB_GLUE -include [list GLUE_cell_list]
# define top-level partitions that group subpartition codecs or cores

define_dft_partition PARTITION1 -include [list C_CORE1 SUB_GLUE]
# apply top-level codec characteristics to subpartitions

current_dft_partition SUB_GLUE
# apply codec I/O sharing characteristics

Figure 5-28 shows the Hybrid integration results for these commands.
Figure 5-28 Hybrid Flow With Sharing Groups and a Shared Top-Level Codec
3$57,7,21
3$57,7,21
68%B*/8(
&B&25( */8( &B&25( &B&25(
You can define one or more shared codec subpartitions within any top-level partition, with or
without compressed scan cores. If some scan cells exist in a top-level partition but outside a
subpartition, the tool places them into an external chain that is not compressed inside that
partition. See Figure 5-29.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Figure 5-29 Partition-Level External Chains in Hybrid Flow

3$57,7,21
68%B*/8(
&B&25( */8(
6KDULQJFRPSUHVVRU
Additional requirements apply to the scan configuration when codec I/O sharing is used in
the Hybrid flow with shared top-level codecs. For more information, see “Limitations” on
page 5-51.
Using Dedicated Codecs for Top-Level Logic

You can define top-level partitions to specify the top-level scan logic to be scan-compressed
with a dedicated codec.
In this flow, create and configure sharing groups as follows:
1. Define a top-level partition containing the logic to be scan-compressed with a dedicated
top-level codec. You can also omit a partition definition and use the default partition.
2. Define additional top-level partitions containing the compressed scan cores and/or
subpartitions that are to share their codec I/O connections.
3. Configure the top-level logic codec characteristics within its top-level partition.
4. Configure the shared codec I/O characteristics within each top-level partition where
sharing occurs.
The following example defines two top-level DFT partitions, one of which contains two
shared-I/O cores, and one of which contains a dedicated top-level codec:
# globally enable scan compression and Hybrid integration
# define top-level partitions that group cores or dedicated codecs

define_dft_partition PARTITION2 -include [list GLUE_cell_list]

# apply codec I/O sharing characteristics for cores

# apply top-level dedicated codec characteristics

Figure 5-30 shows the Hybrid integration results for these commands.
Figure 5-30 Hybrid Flow With Sharing Groups and a Dedicated Top-Level Codec
3$57,7,21
3$57,7,21
&B&25( &B&25( */8(
6KDULQJFRPSUHVVRU
Defining Sharing Groups in the Top-Down Flat Flow

This flow is a simple extension of the normal top-down flat codec I/O sharing flow, except
multiple top-level partitions are defined.
Create and configure sharing groups as follows:
1. Define any subpartitions containing the logic to be scan-compressed with a codec.
2. Define top-level partitions containing the subpartitions that are to share their codec I/O
connections.
3. Configure the codec characteristics within each subpartition.
The following example defines two codec groups, each with its own shared I/O connections,
in a top-down flat flow:
# globally enable scan compression
# define subpartitions that define codecs


DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4

# define top-level partition that groups subpartition codecs

define_dft_partition PARTITION1 -include {SUB_P1 SUB_P2} ;# subpartitions
define_dft_partition PARTITION2 -include {SUB_P3 SUB_P4} ;# subpartitions
# apply subpartition codec characteristics

# apply top-level codec I/O sharing characteristics

Figure 5-31 shows the top-down flat DFT insertion results for these commands.
Figure 5-31 Top-Down Flat Flow Codec I/O Sharing With Multiple Top-Level Partitions
3$57,7,21
3$57,7,21
68%B3
68%B3
68%B3
68%B3
%/. %/. %/. %/.

Codec I/O Sharing and Standard Scan Chains

When the top-level codec I/O connections are shared in compressed scan mode, the
standard scan mode is also affected.
In the HASS integration flow, due to the reduced number of available scan I/O pins, the
standard scan chains inside the compressed cores can no longer be promoted to dedicated
top-level connections. To remedy this, standard scan chains in compressed scan cores
become scan segments that can be concatenated, if needed, by top-level integration.
Figure 5-32 shows the compressed scan and standard scan chains for a design in the HASS
integration flow.
Figure 5-32 Standard Scan Chains in the HASS Flow With Codec I/O Sharing
&B&25( &B&25( &B&25( &B&25(
6KDULQJFRPSUHVVRU
&RPSUHVVHGVFDQPRGH 6WDQGDUGVFDQPRGH
In the Hybrid flow with codec I/O sharing, core-level scan segments can be mixed with
top-level scan cells to achieve optimal balancing. Figure 5-33 shows the compressed scan
and standard scan chains for a design in the Hybrid integration flow.
Figure 5-33 Standard Scan Chains in the Hybrid Flow With Codec I/O Sharing
68%B3
68%B3
&B&25( %/. &B&25( %/.
6KDULQJFRPSUHVVRU
In top-down flat flows, the subpartition standard scan chains are promoted to top-level scan
chains with no concatenation or rebalancing within the enclosing top-level partitions. You
must apply the set_scan_configuration -chain_count command to the subpartitions to
manage the standard scan chain counts. Figure 5-34 shows the compressed scan and

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
standard scan chains for a design in the top-down flat flow, where SUB_P1 has a specified
chain count of 2 and SUB_P2 has a specified chain count of 1.
Figure 5-34 Standard Scan Chains in the Top-Down Flat Flow With Codec I/O Sharing
3$57,7,21
3$57,7,21
68%B3
68%B3
68%B3
68%B3
%/. %/. %/. %/.
6KDULQJFRPSUHVVRU
In the HASS flow with sharing groups, partition boundaries prevent core-level scan segment
concatenation across partitions, but scan segments can still be concatenated and balanced
within each partition. Apply the set_scan_configuration -chain_count command to
each partition to specify the number of standard scan chains for that partition. Figure 5-35
shows the standard scan chains for a design in the HASS integration flow with sharing
groups.
Figure 5-35 Standard Scan Chains in the HASS Flow With Codec I/O Sharing Groups
3$57,7,21
3$57,7,21
&B&25( &B&25( &B&25( &B&25(
6WDQGDUGVFDQPRGH
In the Hybrid flow with sharing groups, core-level scan segments are concatenated and
balanced within top-level partitions (as in the HASS flow with sharing groups), but
subpartition scan chains are promoted to top-level scan chains (as in the top-down-flat
flows). For subpartitions, apply the set_scan_configuration -chain_count command to
specify the number of standard scan chains to create. For top-level partitions, apply the
set_scan_configuration -chain_count command to specify the total scan chain count
for all cores in the partition, excluding any subpartitions. Figure 5-36 shows the standard
scan chains for a design in the Hybrid integration flow with sharing groups.

Figure 5-36 Standard Scan Chains in the Hybrid Flow With Codec I/O Sharing Groups
3$57,7,21
3$57,7,21
68%B3
68%B3
&B&25( %/. &B&25( %/.
6WDQGDUGVFDQPRGH
For more information on specifying standard scan chain counts in the HASS and Hybrid
flows, see Chapter 3, “Hierarchical Adaptive Scan Synthesis.” For more information on
applying chain count and scan I/O signal specifications to DFT partitions, see “Defining and
Configuring Partitions” on page 2-7.
Codec I/O Sharing and Pipelined Scan Data

When codec I/O sharing is used with the pipelined scan data feature, pipeline stages are
added along the shared scan data signals, as shown in Figure 5-37.
Figure 5-37 Pipelined Scan Data in the Shared Codec I/O Flow
-tail_pipeline_stages 3
When compressed scan cores already contain pipeline stages, the DFTMAX tool
incrementally adds top-level pipeline stages to meet the top-level pipeline depth target. This
is known as incremental pipelining. Figure 5-38 shows two compressed scan cores with a
single head and tail pipeline stage, incrementally promoted to three pipeline stages during
HASS top-level integration.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Figure 5-38 Incremental Pipeline Register Addition in HASS Shared Codec I/O Flow
-tail_pipeline_stages 3
Note the following limitations of the pipelined scan data feature when used with shared
codec I/O:
• Only compressed scan cores can be present for integration. Standard scan cores or
unstitched logic cannot be present.
• All compressed scan cores must have the same pipeline depth.
TetraMAX versions G-2012.06-SP1 and later automatically recognize pipeline registers in
shared codec I/O scan paths. TetraMAX versions G-2012.06 and earlier require the
following additional DRC settings:
set_drc -pipeline_in_compressor -forked_pipes
If you are using high X-tolerance with codec I/O sharing and pipelined scan data, the tool
inserts pipeline stages on the block-select signals to match the total head and tail pipeline
latency. Figure 5-39 shows pipeline stages added to the block-select signals in a Hybrid flow.
Figure 5-39 I/O Sharing With High X-Tolerance Codecs and Pipelined Scan Data
&B&25( */8(
6KDULQJFRPSUHVVRU
For more information on the pipelined scan data feature, see “Pipelined Scan Data” on
page 5-7. For more information on the requirements of the pipelined scan data feature in the
HASS and Hybrid flows, see “Hierarchical Flows With Pipelined Scan Data” on page 5-20.

Integration of Cores With Shared Codec I/O Connections

When performing HASS integration of cores, you can include cores with shared codec I/O
connections along with compressed scan cores or standard scan cores.
If you do not enable codec I/O sharing at the integration level, the tool promotes the scan I/
O connections of each core to top-level scan connections during integration. See
Figure 5-40.
Figure 5-40 HASS Integration of Shared Codec I/O Cores
6+$5('B&25(
6+$5('B&25(
723
&B&25(
If you enable codec I/O sharing at the integration level with the -shared_inputs option, the
tool performs nested codec I/O sharing. The scan I/O connections of each core are shared
at the integration level. See Figure 5-41.
Figure 5-41 Shared-I/O HASS Integration of Shared Codec I/O Cores
6+$5('B&25(
6+$5('B&25(
723
&B&25(
6KDULQJFRPSUHVVRU
The values provided to the -shared_inputs and -shared_outputs options must meet
requirements that are similar to other shared codec I/O flows. The value specified for the
-shared_inputs option must be at least as wide as the widest core scan input. The value
specified for the -shared_outputs option must be equal to the widest core scan output.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
If some cores have high X-tolerance capability, you must account for additional block-select
pins when specifying a value for the -shared_inputs option. The value must be at least as
large as the sum of the following values:
• The width of the widest core-level scan data input across all cores
• The sum of the block-select signals used across all shared codec I/O cores
• The number of top-level block-select signals needed, which is log2 of the number of high
X-tolerance shared codec I/O cores, rounded up to the next integer value
Figure 5-42 shows the scan data inputs needed for two shared codec I/O cores.
SHARED_CORE1 has a wider set of scan data inputs. Because there are two shared codec
I/O cores, an additional top-level block-select signal is also required. In this example, a
minimum value of 7 must be specified with the -shared_inputs option.
Figure 5-42 Shared-I/O HASS Integration of High X-Tolerance Cores
7RSOHYHOEORFNVHOHFWFRQQHFWLRQV
&RUHOHYHOVFDQGDWDLQSXWFRQQHFWLRQVVKDUHG
&RUHOHYHOEORFNVHOHFWFRQQHFWLRQVSURPRWHG
6+$5('B&25(
6+$5('B&25(
723
+LJK;WRO +LJK;WRO +LJK;WRO +LJK;WRO +LJK;WRO
6KDULQJFRPSUHVVRU
For more information on shared codec I/O block-select signals, see “Adding High
X-Tolerance Block-Select Pins” on page 5-28.
You can only include shared-I/O cores in HASS integration runs. The Hybrid flow does not
support shared codec I/O cores.

Limitations
Note following requirements and limitations of the shared codec I/O feature:
• All codecs must have the same X-tolerance type.
• The -shared_outputs value can only be set to the fully-shared value, which is
determined by the widest codec output, or the fully unshared value, which requires the
flow described in “Specifying Shared Codec Inputs With Dedicated Codec Outputs” on
page 5-37.
• In Hybrid mode, the compressed scan chain characteristics of a shared top-level codec
must be specified with the -chain_count or -max_length options of the
set_scan_compression_configuration command. They cannot be automatically
derived using the normal chain count heuristics.
• When partitions are used, codec I/O can be shared within each top-level partition, but not
across top-level partition boundaries.
• When partitions are used, standard scan chains are balanced within each top-level
partition, but not across top-level partition boundaries.
• In flows that use subpartitions, which are the top-down flat flow and the Hybrid flow with
shared top-level codecs, the default partition cannot contain subpartitions because there
is no explicit define_dft_partition command that allows you to reference a
subpartition. You can only include subpartitions in user-defined top-level partitions.
Implicit Scan Chains

Implicit scan chains provide a mechanism to specify one or more “implicit” scan segments
that exist outside the current design but should be included in compressed scan insertion.
This is useful when an IP block to be scan-compressed exists at the chip level but
compressed scan is inserted at the core level, as shown in Figure 5-43.
Figure 5-43 Implicit Scan Chains Defined in a Core-Level Run
,PSOLFLWVFDQFKDLQV ')7LQVHUWLRQ
H[WHUQDOWRWKH ,3 SHUIRUPHGLQWKH
FRUHOHYHOUXQ FRUHOHYHOUXQ
&RUHOHYHOVFDQGDWDDFFHVVSRUWV

Implicit Scan Chains 5-51
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Each implicit scan chain segment is defined in the core level run, characterized by the
following information:
• Chain name
• Chain length
• Scan clock
• Core-level scan data access ports
When implicit scan chain segments are defined, the DFTMAX tool incorporates them into
compressed scan insertion by connecting to the core-level scan data access ports. It uses
the clock and length information to construct scan chains that are optimally balanced while
respecting the chain count and clock-mixing configuration settings applied to the current
design.
Just as with any other user-defined scan segment, implicit scan chains are incorporated into
both the standard scan and compressed scan modes. Reconfiguration MUXs are added as
needed.
When implicit scan chains are used, the tool produces a partial test protocol. This protocol
is not complete and contains only a partial ScanChain definition for the implicit scan chains.
The protocol cannot be used in the TetraMAX tool directly.
Defining Implicit Scan Chains

To define implicit scan chain segments, use the following two commands:
• set_scan_group
• set_scan_path
Use the set_scan_group command to define a scan group for each implicit scan chain:
set_scan_group group_name
-serial_routed true -segment_length length
-access {ScanDataIn core_output_port ScanDataOut core_input_port}
-clock clock_name
[-edge rising | falling]
where
• The group_name argument is a unique user-defined scan group name.
• The chain_length argument is the chain length of the implicit scan chain.
• The clock_name argument is the scan clock which clocks the implicit scan chain. It must
be defined as a scan clock in the core-level run using the set_dft_signal command.

• The core_output_port argument is the core-level output port that externally connects
to the scan input of the implicit chain.
• The core_input_port argument is the core-level input port that externally connects to
the scan output of the implicit chain.
By default, an implicit scan chain is defined as a rising-edge scan segment. To define it as a

falling-edge scan segment, add the -edge falling option to the set_scan_group
command. You cannot define an implicit scan chain that represents a mix of rising-edge and
falling-edge cells.
Use the set_scan_path command to specify how each scan group is to be incorporated
into scan stitching:
set_scan_path chain_name -test_mode all
-ordered_elements group_name
[-complete true]
where
• The group_name argument is a scan group name, previous defined with the
set_scan_group command.
• The chain_name argument is a unique user-defined scan chain name.
By default, implicit scan chains can be mixed with core-level scan cells if DFT requirements
such as scan clock mixing and chain lengths are met. To force implicit scan chains to be
standalone compressed scan chains, add the -complete true option to the
set_scan_path command. This can be useful when you have an implicit scan chain with a
mix of rising-edge and falling-edge cells that cannot be described by the set_scan_group
-edge command.
After you have defined the implicit scan chains, use the preview_dft command to report
how they will be integrated into the core-level scan structures. The following partial preview
report shows a core-level scan chain that contains an implicit scan chain and two core-level
scan cells:
...
Scan chain 'c1' contains 5 cells
Active in modes: ScanCompression_mode :
sub1/Z_reg[0] (CLK, 45.0, rising)

sub1/Z_reg[1] (m)
IMPLICIT1 (s) (m) (CLK, 45.0, rising)
...
At the chip level, the implicit scan chain segments must be connected to the core-level scan
access ports. These connections, highlighted in Figure 5-44, can exist in the chip-level RTL

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
or they can be created using netlist editing commands. the tool does not make these
connections.
Figure 5-44 Implicit Scan Chain Connections to Core in a Chip-Level Run
,PSOLFLWVFDQFKDLQFRQQHFWLRQVPXVW
,3
H[LVWRUEHFUHDWHGLQWKHFKLSOHYHOUXQ
Implicit Scan Chain Script Example

The following example shows the use of implicit scan chains in a core-level scan
compression insertion run.
current_design CORE
# create scan port that connects to the implicit scan chain’s scan input
# (which is an output from CORE)
create_port -direction out dout
# create scan port that connects to the implicit scan chain’s scan output
# (which is an input from CORE)
create_port -direction in din
# define all test signals; test clocks must be defined before being
# referenced by set_scan_group -clock
-timing {45 55} -port clk_st
# define the implicit scan chain and access pins

# in the core design; dout drives the scan input of the external scan
# chain and din is driven by the scan output of the external scan chain
set_scan_group IMPLICIT1 -segment_length 67 -serial_routed true \
-access [list ScanDataIn dout ScanDataOut din] -clock clk_st
# define each implicit chain as a scan path

set_scan_path c1 -ordered_elements IMPLICIT1 -test_mode all \
-complete true
# enable adaptive scan compression insertion

# configure adaptive scan compression

-xtolerance high

set_scan_configuration -chain_count 8 -test_mode all
# create the test protocol

# run pre-DFT DRC

dft_drc -verbose
# preview DFT insertion

# perform DFT insertion

insert_dft
# post-DFT DRC is not supported

# write out the compression mode protocol for TetraMAX

write_test_protocol -test_mode ScanCompression_mode \
-output stil/scan_compression.stil -names verilog
# write out the pure scan protocol for TetraMAX

write_test_protocol -test_mode Internal_scan \
-output stil/internal_scan.stil -names verilog
# write out the inserted design in Verilog and Synopsys ddc format
write -format verilog -hierarchical -output vg/design_with_implicit.v
write -format ddc -hierarchical -output db/design_with_implicit.ddc
Protocol Example
The following example is taken from the ScanStructures section of the test protocol written
out by DFT Compiler. The implicit scan segment is characterized by name, scan length,
scan data in, scan data out, and the scan clock in the test protocol.
ScanStructures {
ScanChain "c1" {
ScanLength 67;
ScanIn "dout";
ScanOut "din";
ScanMasterClock "clk_st";
}
In the same protocol, an example of a normal (nonimplicit) scan chain definition:

ScanChain "2" {
ScanLength 10;
ScanEnable "test_se";
ScanMasterClock "clk_st";
}

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Limitations
Note the following limitations when using implicit scan chains:
• The report_scan_path command does not show the presence of implicit scan chain
segments in the core-level scan chains; use the preview_dft command before DFT
insertion instead.
• At the chip level, the implicit scan chain segments must be connected to the core-level
scan access ports; the tool does not make these connections.
• Implicit scan chains do not reliably mix with scan cells of opposite edge polarity when
edge-mixing is enabled with the set_scan_configuration -clock_mixing command.
• When implicit scan chains are used, the DFTMAX tool produces a partial test protocol.
This protocol is not complete and contains only a partial ScanChain definition for the
implicit scan chains. The protocol cannot be used in the TetraMAX tool directly.
• Post-DFT DRC is not supported when implicit scan chains are used. Use the TetraMAX
tool to perform DRC checking.

6
Adaptive Scan With Serializer 6
Adaptive scan with serializer can be used to improve the ATPG quality of results (QoR) for
designs or blocks with a limited number of top-level ports. This QoR improvement is
accomplished by employing a serial connection between the codec and the top-level ports.
• Overview
• Architecture
• Serializer Operation
• Higher Shift Speed and Update Stage
• Scan-Enable Signal Requirements for Serializer Operation
• Timing Paths
• Scan Clocks
• User Interface
• Configuring Serialized Compressed Scan
• Deserializer/Serializer Register Size
• Serializer Implementation Flow
• Serialized Compressed Scan Core Creation
6-1
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
• Top-Down Flat Flow

• Top-Down Partition Flow
• HASS Flow
• Hybrid Flow
• Serializer IP Insertion
• Wide Duty Cycle Support for Serializer
• Serializer in Conjunction With On-Chip Clocking Controllers
• Using Integrated Clock-Gating Cells in the Serializer Clock Controller
• User-Defined Pipelined Scan Data
• Running TetraMAX ATPG on Serializer Designs
• Adaptive Scan With Serializer Limitations
• Out-of-Scope Serializer Functionality
• DFTMAX Compression Error Messages
Chapter 6: Adaptive Scan With Serializer

6-2
Overview
The scan architecture that the DFTMAX tool creates using adaptive scan technology is
called compressed scan. By default, the connection from the input and output of the
compressor/decompressor (codec) to the top-level ports or pins created by DFTMAX scan
compression is combinational. To improve the ATPG quality of results (QoR) for designs or
blocks with a limited number of top-level ports, the DFTMAX tool also supports an optional
serial connection between the codec and the top-level ports.
This chapter uses the term combinational compressed scan, or more generally, compressed
scan, to refer to compressed scan with the default combinational codec-to-top-level-ports
connection. The term serialized compressed scan refers to compressed scan that uses
serializing logic to provide a serial connection to the codec. The term serializer refers to the
logic that provides the serial connection.
For a given number of top-level scan inputs and outputs, DFTMAX compression can create
up to a maximum number of chains with full X-tolerance, using combinational compressed
scan, as shown in Table 6-1.
Table 6-1 Number of Available Compressed Scan Chains
Number of Number of Max number of full Xtol chains

inputs outputs = (number of outputs) x
(2(#inputs-1))
1 1 Unavailable
2 2 4
3 3 12
4 4 32
Table 6-1 shows that the maximum number of chains with full X-tolerance is limited for low
pin-count designs and is not available for one-scan-in-one-scan-out designs. The serializer
overcomes this limitation and achieves full X-tolerance for any number of scan inputs and
outputs, including as few as 1 scan-in pin and 1 scan-out pin.
Note:
The maximum number of chains shown in Table 6-1 will be different if an on-chip clocking
(OCC) chain is present in the design.

Overview 6-3
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Architecture
Figure 6-1 shows the basic serializer architecture.
Figure 6-1 Basic Serializer Architecture
The serializer architecture consists of the following additional logic:

• Serializer clock controller
• Deserializer registers
• Serializer registers

Architecture 6-4
Serializer Clock Controller

The serializer clock controller contains an FSM counter and clock-gating cells.
• FSM Counter: finite state machine counter creates the clock-enable signal (routed to
clock-gating cells) and the strobe signal (routed to the serializer registers). The counter
is driven by an external clock.
• CGCs: clock-gating cells are inserted at the specified scan-shift clocks. They are
enabled by the FSM counter value and produce internally generated clocks during scan
chain shifting.
Deserializer Registers
Deserializing registers are placed in the decompressor IP at the input side. These registers
load the scan input data serially and supply the data to the compressed chains.
Serializer Registers
Serializing registers are placed in compressor IP at the output side. These registers capture
data from the compressor outputs and stream the data to the scan output.
Serializer Operation
Figure 6-2 shows the serializer operation and timing diagram involving 4-bit deserializer and
serializer registers.

Serializer Operation 6-5
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Figure 6-2 Serializer Operation
The sequence of events shown in Figure 6-2 is as follows:

1. FSM counter starts counting.
2. Deserializer registers start shifting data for the first internal shift.
3. Deserializer registers complete the shift for the first internal shift.
4. First shift data is loaded into the first flip-flops of the compressed chains through the
decompressor. At the same time, the serializer registers capture the compressor outputs.
5. Tester starts strobing the compressor outputs for the first shift.
6. Tester completes strobing the compressor outputs for the first shift.
7. Deserializer registers complete the shift for the last internal shift.
8. Last shift data is loaded into the compressed chains through the decompressor.
Higher Shift Speed and Update Stage

Because the serializer clock controller behaves like a clock divider, the internal scan clocks
are generated by the external clocks being divided by S, where S is the depth of the
serializer register segment. For example, when S is 8 and the external clock speed is

Higher Shift Speed and Update Stage 6-6
10 MHz, the internal clock speed reduces to 1.25 MHz. Thus, the speed of the external clock
can be increased up to S-times faster without affecting the compressed chain shift timing.
(An 80 MHz external clock would result in a 10 MHz internal shift clock.)
However, in a fully X-tolerant implementation of the compression logic, the longest path
traverses from the deserializer flip-flop output pin through the decompressor gates and then
through the compressor selector gates to the serializer flip-flop input pin. This path is shown
in red in Figure 6-3.
Figure 6-3 Serializer Architecture Without Update Stage
As the period of the serializer clock decreases, this path becomes critical because it cannot
exceed the clock period.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Figure 6-4 Timing Diagram With Update Stage
One way to decouple this critical path from the serializer clock timing is to insert an update
stage between the deserializer register output pins and the decompressor combinational
logic inputs, as shown in Figure 6-5. This update stage is synchronized by a clock that runs
as fast as the internal shift clock.

Figure 6-5 Serializer Architecture With Update Stage
The update stage has the following effects:

• Provides an extra timing margin, as indicated in Figure 6-4 on page 6-8.
• Results in one internal clock cycle longer than a serializer architecture without an update
stage. So, for example, if there were 100 test cycles per pattern without the update stage,
then with the update stage, the whole test cycle per pattern would be 100 cycles plus 1
internal clock cycle.
• Decreases the test time by using a faster external clock.
Figure 6-6 shows the scan shift operation with the update stage implemented.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Figure 6-6 Serializer Operation With Update Stage
Scan-Enable Signal Requirements for Serializer Operation

As previously discussed, the clocks for compressed scan chains are internally generated by
the serializer clock controller. The serializer FSM counter in the controller counts when the
scan-enable signal is active and feeds the clocks to the compressed scan chains at the
proper time. When the scan-enable signal becomes inactive during capture, the FSM
counter is reset and the external clocks directly clock the compressed scan chain.
Therefore, for proper operation, the scan-enable signal must be held in the inactive state in
all capture procedures.
If you use the STIL procedure file created by the DFTMAX tool, the protocol already meets
this requirement. The tool constrains all scan-enable signals to the inactive state in the
capture procedures, excluding any scan-enable signals defined with the -usage
clock_gating option of the set_dft_signal command.

Scan-Enable Signal Requirements for Serializer Operation 6-10
If you use a custom STIL procedure file, keep the following in mind:
• Make sure that all scan-enable signals used by serializer clock controllers are
constrained to the inactive state in all capture procedures.
• If clock pulses are needed to initialize the internal registers whose clock pins are gated
by the serializer clock controller, make sure that the scan-enable signal is inactive
throughout the test_setup procedure. By keeping the scan-enable signal inactive, the
clock pulses needed for initialization can reach the initialization registers. Otherwise, the
initialization might not be performed properly, and you could see unexpected R-rule
violations in DRC.
Timing Paths
The following figures show the datapaths specific to the serialized compressed scan
architecture. Figure 6-7 shows the datapaths without the update stage. Figure 6-8 shows
the datapaths with the update stage. The figures demonstrate the use of the DFT-inserted
OCC controller and external clocks.
Figure 6-7 Datapath Diagrams Without Update Stage

Timing Paths 6-11
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Figure 6-8 Datapath Diagrams With Update Stage
In Figure 6-7 and Figure 6-8, the red, purple, green, and blue arrows in the waveforms and
the colored arrows in the block diagrams at the right side of the figures correspond to each
other. The arrows are focused on the paths from the decompressor block to the core and
then from the core to the compressor block. These diagrams are also useful in
understanding the role of the update stage, which relaxes the timing path from
decompressor to core to compressor.
Scan Clocks
The following sections discuss scan shift clocks when using a serializer:
• Deserializer/Serializer Update Stage Register Clocks
• Specifying a Clock for Deserializer/Serializer Registers
• Staggered Scan Clocks
• Specifying Scan Clock Ports

Scan Clocks 6-12
Deserializer/Serializer Update Stage Register Clocks

You use one of the scan shift clocks, defined with the command set_dft_signal -type
ScanClock command, as the clock for the deserializer/serializer registers. If you do not
specify a particular clock, the clock for these registers is selected as follows:
• When OCC is used and an automated pipeline scan data register clock is defined as one
of the ATE clocks, then the pipeline scan data clock is used for the deserializer/serializer
registers.
• In other cases, any clock that reduces the number of lock-up latches is used for the
deserializer/serializer registers.
You can determine which clock is selected for the deserializer/serializer registers by using
the preview_dft command, as shown by the following:
Load/Unload Serializer Clock = CLK1
Load stands for the input-side deserializer registers, and Unload stand for the output-side
The update stage is implemented by specifying the command
set_serialize_configuration -update_stage true. The clock for the update stage
always has the same clock source as the deserializer/serializer register clock. The
update-stage clock is a gated version of the deserializer/serializer register clock.
Specifying a Clock for Deserializer/Serializer Registers

You can specify a clock for the deserializer/serializer registers in a chip-level flow. If you have
multiple scan clocks and have a particular clock that you need to use for the deserializer/
serializer registers, you can follow Example 6-1.
Example 6-1 Script Example for Specifying a Clock for the Deserializer/Serializer Registers
set_dft_signal -view existing_dft -type ScanClock -timing {45 55} \
-port EXT_CLK1 -test_mode all
set_serialize_configuration \
-inputs 1 \
-outputs 1 \
-serializer_clock EXT_CLK2 \
-update_stage true

Scan Clocks 6-13
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
You can specify a clock for the deserializer/serializer registers with the command
set_serialize_configuration -serializer_clock. The clock specified with the
-serializer_clock option has to be predefined with the command set_dft_signal
-type ScanClock.
Staggered Scan Clocks

If you want to use staggered scan-shift clocks to reduce power during shift, the clock
waveforms should be carefully considered. Since the input side of the deserializer registers
and the update stage are triggered by the trailing edge, the timing of internal scan cells that
obtain the data from the deserializer registers-update stage must not occur later than the
trailing edge. Similarly, since the output side of the serializer registers is triggered by the
leading edge, the timing of the internal scan cells that launch the data through the
compressor to the serializer registers must not occur earlier than the leading edge. A
possible way to employ staggered clocks is to use the timing waveforms shown in Figure 6-9
for the shift mode.
Figure 6-9 Staggered Clock Waveform
Suppose, for example, your design has five external clocks, each with different timing, as
shown the following group of set_dft_signal command:
set_dft_signal -type ScanClock -view existing_dft -timing {47 88} \
set_dft_signal -type ScanClock -view existing_dft -timing {50 68}

Scan Clocks 6-14
With these specifications, the tool automatically selects EXT_CKLK1 as the deserializer/
serializer register clock. It is the only clock that can make the serializer scheme work.
Note:
For this example, even if you choose a clock other than EXT_CLK1 by using the
set_serialize_configuration -serializer_clock clock_name command, the
tool ignores your specification.
Specifying Scan Clock Ports

When you use the serializer technology, you should instruct the tool where to insert the
serializer clock controller. It should be a pin on a clock line that drives all the scan cells. The
following command example shows how to make this specification when you have pads for
the scan clock ports:
set_dft_signal -view spec -type ScanClock -port EXT_CLK1 \

-hookup_pin F1/Y -test_mode all
The value of the -hookup_pin option tells the tool where to insert the serializer clock
controller. Without this option specification, the clock controller would be inserted close to
the port, which might be outside the clock pad and therefore might adversely affect circuit
behavior.
User Interface
The set_scan_compression_configuration -serialize command allows you to
specify the location of the serializer logic. When you want to implement the serializer, specify
the either chip_level or core_level for the -serialize option. The default is none,
which indicates that no serialization is requested and combinational compressed scan is
implemented.
set_scan_compression_configuration ...
-serialize chip_level | core_level | none
The set_serialize_configuration command is used specifically to define the serializer

options. Additional options are available to configure the serializer insertion:
set_serialize_configuration ...
-test_mode name
-parallel_mode name
-inputs number
-outputs number
-update_stage true | false
-exclude_clocks name

User Interface 6-15
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
-serializer_clock name
-update_clock name
-strobe name
-ip_inputs number
-ip_outputs number
-wide_duty_cycle true | false
Note the following conditions:

• The default for the -update_stage option is false.
• The -exclude_clocks option can be used for certain clocks that are not to be gated by
the serializer clock controller.
• The specified number of -inputs and -outputs has to be the same.
• The -ip_inputs and -ip_outputs options are used for serializer IP insertion flow. For
information on this flow, see “Serializer IP Insertion” on page 6-39.
• For the usage of -serializer_clock, -update_clock and -strobe, see “Scan Clocks”
on page 6-12 and “Serialized Compressed Scan Core Creation” on page 6-18.
• The default for the -wide_duty_cycle option is false. For the wide duty cycle support,
see “Wide Duty Cycle Support for Serializer” on page 6-54.
To see how these options are used, refer to the script examples in the following top-down flat
flow, top-down partition flow, HASS flow, and Hybrid flow sections.
Configuring Serialized Compressed Scan

Figure 6-10 and the accompanying script to the right of the figure show you how to use the
following two commands together:
• set_scan_compression_configuration defines the codec specification.
• set_serialize_configuration defines the serializer specification.
Using these commands results in the architecture shown in Figure 6-10.

Configuring Serialized Compressed Scan 6-16
Figure 6-10 Association of set_serialize_configuration With Existing

set_scan_compression_configuration Command
# codec inputs
-inputs 8 \
# codec outputs
-outputs 8 \
# Compressed chains
-chain_count 200 \
# Enabling serializer specification
-serialize chip_level
# serial input
-inputs 1 \
serial output
-outputs 1 \
# update stage
-update_stage true
Deserializer/Serializer Register Size

Deserializer/serializer register size is determined by the command:
set_scan_compression_configuration -inputs number -outputs number
The deserializer/serializer register size is equal to the number of codec inputs and outputs.
For example, if this number is 8, then 8-bit deserializer/serializer registers are implemented.
The deserializer/serializer register is divided into some number of segments, depending on
the number specified in this command:
set_serialize_configuration -inputs number -outputs number
For example, if the number is 2, then two 4-bit deserializer/serializer segments are created.

Deserializer/Serializer Register Size 6-17
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Serializer Implementation Flow

When you insert a serializer, two implementation flows are available:
• Core-level flow
• Chip-level flow
The core-level flow is used for serialized compressed scan core creation. The serialized
compressed scan cores are integrated at the chip level in either a HASS or Hybrid flow. The
core-level flow is enabled by the command set_scan_compression_configuration
-serialize core_level. See “Serialized Compressed Scan Core Creation” on page 6-18.
The chip-level flow is used for top-down flat flow, top-down partition flow, HASS flow, Hybrid
flow, and serializer IP insertion flow. The chip-level flow is enabled by the command
set_scan_compression_configuration -serialize chip_level. See
• “Top-Down Flat Flow” on page 6-21

• “Top-Down Partition Flow” on page 6-24
• “HASS Flow” on page 6-29
• “Hybrid Flow” on page 6-36
• “Serializer IP Insertion” on page 6-39
Serialized Compressed Scan Core Creation

You can create serialized compressed scan cores and integrate them at the chip level in a
HASS flow or a Hybrid flow. For a serialized compressed scan core-level flow, use the
command set_scan_compression_configuration -serialize core_level.
Figure 6-11 shows a diagram for the serialized compressed scan core.

Serializer Implementation Flow 6-18
Figure 6-11 Serialized Compressed Scan Core
Note the following in Figure 6-11:

• No serializer clock controller is inserted.
❍ The ports for ser_clk, update_clk, and strobe are automatically created.
Therefore the serializer clock controller that is inserted at the top level during HASS
or Hybrid flows feeds signals to these ports.
• Each deserializer/serializer register segment has an interface that connects to and from
the different cores. Even if you specify set_serialize_configuration -inputs 1
-outputs 1, two scan-in and scan-out ports are created, as shown in Figure 6-11.
Serializer Core-Level Flow

Example 6-2 shows a typical serialized compressed scan core-level flow:
Example 6-2 Script Example for a Serialized Compressed Scan Core-Level Flow

Serialized Compressed Scan Core Creation 6-19
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
-xtolerance high \
-chain_count 200 \
-inputs 8 \
-outputs 8 \
-serialize core_level
-inputs 1 \
-outputs 1 \
-update_stage true
dft_drc
insert_dft
Note:
With regard to command requirements for serialized compressed scan core creation,
you must specify the same value in the set_scan_configuration -chain_count
number and set_serialize_configuration -inputs number -outputs number
commands for each core-level configuration. Otherwise, you will see unexpected errors
in the HASS or Hybrid flows at the chip level.
User-Defined Ports for the Serializer Core-Level Flow

You might need to specify the port usage for each core before core creation. For example,
suppose you want to specify the particular ports ser_clk, update_clk, and strobe, as the
serializer control ports. You could use a script such as the one shown in Example 6-3.
Example 6-3 Script Example for Defining Core-Level Serializer Ports
-port MY_SERI_CLK -test_mode all
-port MY_UPD_CLK -test_mode all
set_dft_signal -view spec -type TestData \
-port MY_STROBE -test_mode all
-inputs 1 \
-outputs 1 \
-update_stage true \
-serializer_clock MY_SERI_CLK \
-update_clock MY_UPD_CLK \
-strobe MY_STROBE
The ports specified with the -serializer_clock and -update_clock options must be
predefined as test clocks with the set_dft_signal -type ScanClock command, and the
port specified with the -strobe option must be predefined as test data with the
set_dft_signal -type TestData command. All of these ports must be dedicated existing
test ports. The tool connects the signals to the specified ports, instead of creating them.

Serialized Compressed Scan Core Creation 6-20
Nondefault Scan Clock Timing for Core-Level Flows

If you use clock timing that is not the default clock timing (period of 100, rise of 45, and fall
of 55) for a flow that is specified with the set_scan_compression_configuration
-serialize core_level command, you might encounter the following error message
when you run the preview_dft command on the core-level flow:
Error: Cannot synchronize scan chain cells 'U_core1/stat_reg_1_' and
'Serializer_clk_seg'. Both edges of clock 'clkA' occur before clock
'ser_clk' triggers. (TEST-344)
This error can occur because by default the tool automatically creates a serializer clock
named ser_clk and assumes it has the default timing. If you need to use nondefault clock
timing in a core-level implementation flow, you should define a clock port with nondefault
timing specified, as shown in Example 6-4.
Example 6-4 Serializer Core-Level Flow Using a Nondefault Clock
-port MY_SER_CLK -test_mode all
-port MY_UPD_CLK -test_mode all
set_dft_signal -view spec -type TestData -port MY_STROBE -test_mode all
-inputs 1 \
-outputs 1 \
-serializer_clock MY_SERI_CLK \
-update_clock MY_UPD_CLK \
-strobe MY_STROBE \
-update_stage true
As in this example, when you specify a clock port with -update_clock, you should set the
same clock timing as the clock port specified with -serializer_clock, because the clock
timing becomes the same after a serializer clock controller is inserted at the top level during
a HASS or Hybrid flow.
Top-Down Flat Flow

The following two sections describe typical command flows when a serializer codec is
inserted at a top level that does not yet contain a codec:
• Serial Mode and Standard Scan Mode
• Serial Mode, Parallel Mode, and Standard Scan Mode

Top-Down Flat Flow 6-21
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Serial Mode and Standard Scan Mode

By default, without a user-defined test mode, DFTMAX compression architects the
Internal_scan and ScanCompression_mode modes. When the -serialize chip_level
option is specified, the ScanCompression_mode becomes the serializer mode, which in this
discussion is called serial mode as a matter of convenience. The script in Example 6-5
shows you how to create the serial mode.
Example 6-5 Script Example for a Top-Down Flat Flow: Two Modes
-inputs 8 \
-outputs 8 \
-chain_count 200 \
-inputs 1 \
-outputs 1 \
-update_stage true
dft_drc
insert_dft
...
# Serial mode
write_test_protocol -output SERIAL.spf -test_mode ScanCompression_mode
# Standard scan mode

write_test_protocol -output SCAN.spf -test_mode Internal_scan
In this script example, one scan-in port and one scan-out port are created in the serial mode
and two scan-in ports and two scan-out ports are created in the standard scan mode.
Serial Mode, Parallel Mode, and Standard Scan Mode

In addition to the serial mode provided with the serializer, you can also create a “parallel
mode.” This mode is logically equivalent to combinational compressed scan as shown in
Figure 6-12. The parallel mode is created with the -parallel_mode option, as shown in the
script of Example 6-6.
Example 6-6 Script Example for a Top-Down Flat Flow: Three Modes
define_test_mode my_regular -encoding {TM1 0 TM2 0} \
-usage scan
define_test_mode my_parallel -encoding {TM1 0 TM2 1} \
-usage scan_compression
define_test_mode my_serial -encoding {TM1 1 TM2 0} \
for {set i 0} {$i < 8} {incr i} {

set_dft_signal -view spec -type ScanDataIn -port SI_${i} \

-test_mode all
set_dft_signal -view spec -type ScanDataOut -port SO_${i} \
-test_mode all
}
set_scan_configuration -chain_count 2 -test_mode my_regular
-base_mode my_regular \
-test_mode my_serial \
-xtolerance high -chain_count 200 -inputs 8 -outputs 8 \
-static_x_chain_isolation true \
-parallel_mode my_parallel \
-inputs 1 -outputs 1 \
-update_stage true
dft_drc
insert_dft
...
write_test_protocol -output SERIAL.spf -test_mode my_serial

write_test_protocol -output PARALLEL.spf -test_mode my_parallel
write_test_protocol -output SCAN.spf -test_mode my_regular
Be aware that my_parallel as a parallel mode is specified with the -parallel_mode option
of the set_serialize_configuration command and my_serial as a serial mode is
specified with the -test_mode option of the set_scan_compression_configuration
command.
In this example, one scan-in port and one scan-out port are created in the serial mode, eight
scan-in and scan-out ports are created in the parallel mode, and two scan-in and scan-out
ports are created in the standard scan mode.
When the parallel mode is implemented along with the serial mode, only one codec for the
serial mode is implemented and shared with the parallel mode. Figure 6-12 shows how it is
shared.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Figure 6-12 Top-Down Flat Flow Diagram
Top-Down Partition Flow

For a top-down partition flow, you can specify serializer insertion in each partition. If you
specify the -update_stage true option with the set_serialize_configuration
command in one partition, the option setting is applied to all other partitions.
There are two top-down partition flows: one that uses dedicated serializer chains for each
partition, and one that concatenates the serializer chains across partitions.
You can create a parallel mode, such as a top-down flat flow, by employing user-defined test
modes, but this capability is available only on the dedicated serializer chain flow.
For the concatenated serializer chain flow, the generated test modes are
• ScanCompression_mode: serial mode
• Internal_scan: standard scan mode
Note:
The top-down partition flow with core-level serializer insertion is not supported.
Core-level serializer insertion is discussed in the“Serialized Compressed Scan Core
Creation” on page 6-18.

Top-Down Partition Flow 6-24
Serializer Chains Dedicated to Each Partition

You can divide the design into multiple partitions and insert serializer codecs into each
partition. Figure 6-13 shows a top-down partition flow for which serializer chains are
dedicated to each partition. Example 6-7 shows the script for this case for two modes.
Figure 6-13 Top-Down Partition Flow With Serializer Chains Dedicated to Each Partition
Example 6-7 Script Example for a Top-Down Partition Flow With Serializer Chains Dedicated to
Each Partition: Two Modes
define_dft_partition partition1 -include [list U0 U1 U2 U3 U4]
-location U0 -xtolerance high -chain_count 200 \
-update_stage true

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
-update_stage true
dft_drc
insert_dft
...

In the script shown in Example 6-7, two scan-in and scan-out ports are created in the serial
mode and 18 scan-in and scan-out ports are created in the standard scan mode, at the top
level.
Example 6-8 shows this case for three modes.
Example 6-8 Script Example for a Top-Down Partition Flow With Serializer Chains Dedicated to
Each Partition: Three Modes
-usage scan

-update_stage true


-update_stage true
dft_drc
insert_dft
...

In the script shown in Example 6-8, two scan-in and scan-out ports are created in the serial
mode, and 18 scan-in and scan-out ports are created in the parallel mode, and 18 scan-in
and scan-out ports are created in the standard scan mode, at the top level.
Serializer Chains Concatenated Across Partitions

Scan ports can access across the multiple partitions. Figure 6-14 shows the case for a
design with two partitions. Example 6-9 shows the script for this case.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Figure 6-14 Top-Down Partition Flow With Serializer Chains Concatenated Across Partitions
For this architecture, the following three command requirements should be observed:
• You should use the -partition all option when defining top-level scan ports with the
set_dft_signal command.
• You should not specify the -inputs and -outputs options with the
set_serialize_configuration command in any partition.
• The number of scan-in and scan-out port pairs defined by the set_dft_signal
-partition all commands should be exactly the same number as the
set_scan_configuration -chain_count number command specified in each
partition.
Example 6-9 Script Example for a Top-Down Partition Flow With Serializer Chains Concatenated
Across Partitions
set_dft_signal -view spec -type ScanDataIn -port SI_TOP -partition all
set_dft_signal -view spec -type ScanDataOut -port SO_TOP -partition all

-update_stage true
-update_stage true
dft_drc
insert_dft
...

In the script shown in Example 6-9, the commands have one pair of scan-in and scan-out
settings with the -partition all option, and a chain count value of 1 is specified with the
set_scan_configuration -chain_count command. Additionally, the -inputs number
and -outputs number options are not specified in the set_serialize_configuration
command.
This example creates one scan-in port and one scan-out port in the serial mode and the
standard scan mode at the top level.
The tool relies only on the set_dft_signal -partition all command to determine
whether you are using the concatenated serializer chain flow. Be careful to define the
set_dft_signal -partition all command for the scan-in and scan-out ports correctly;
otherwise, you might encounter unexpected errors.
Note:
Implementing a different number of scan ports between the serial mode and the standard
scan mode is not supported.
HASS Flow
You can insert serializer codecs into the core modules and then integrate the multiple cores
at the top level.
For core-level serializer insertion, use the set_scan_compression_configuration
-serialize core_level command on each core. See “Serialized Compressed Scan Core
Creation” on page 6-18. At the top level, use the set_scan_compression_configuration

HASS Flow 6-29
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
-serialize chip_level -integration_only true command. This command enables

the tool to insert a serializer clock controller at the top level and to integrate the cores.
Similar to the top-down partition flow, there are two HASS flows:
• One that uses dedicated serializer chains for each core.
• One that concatenates the serializer chains across the cores.
You can create a parallel mode by employing user-defined test modes, but this capability is
limited to the dedicated serializer chain flow.
For the concatenated serializer chain flow, the generated test modes are
Note the following limitations:
• Integrating a mix of combinational compressed scan cores and serialized compressed
scan cores is not supported.
• Having a different number of scan ports between a serial mode and a standard scan
mode is not supported.
Serializer Chains Dedicated to Each Core

Serializer chains are created and dedicated to each core. If you have two cores, you would
need to have at least two scan-in and scan-out ports at the top level. Figure 6-15 shows an
example for a design with two cores. Example 6-10 shows the script for this case.

HASS Flow 6-30
Figure 6-15 HASS Flow With Serializer Chains Dedicated to Each Core
Example 6-10 Script Example for a HASS Flow With Serializer Chains Dedicated to Each Core
### core1
report_scan_configuration
-xtolerance high \
-chain_count 150 \
-inputs 8 \
-outputs 8 \
-inputs 1 \
-outputs 1 \
-update_stage true
report_scan_compression_configuration
report_serialize_configuration
dft_drc
preview_dft
insert_dft
dft_drc
dft_drc

HASS Flow 6-31
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
### core2
-xtolerance high \
-chain_count 250 \
-inputs 8 \
-outputs 8 \
-inputs 1 \
-outputs 1 \
-update_stage true
dft_drc
preview_dft
insert_dft
dft_drc
dft_drc
###For core-level serializer insertion,
###you have to specify the same <number> in the
###set_scan_configuration -chain_count <number> and
###set_serialize_configuration -inputs <number> -outputs <number>
###commands for each core level configuration; otherwise,
###you will see unexpected errors.
### top level

set_scan_compression_configuration -integration_only true \
dft_drc
preview_dft
insert_dft
write -hierarchy -output TOP.v -format verilog
Example 6-11 shows the script for the HASS parallel mode flow. In this script example, 2
scan-in and 2 scan-out ports are created for the serial mode and the standard scan mode.
Example 6-11 Script Example for a HASS Parallel Mode Flow With Serializer Chains Dedicated
to Each Core
### core1
define_test_mode my_regular -usage scan

HASS Flow 6-32
define_test_mode my_serial -usage scan_compression

define_test_mode my_parallel -usage scan_compression
-test_mode my_regular
-xtolerance high \
-chain_count 150 \
-inputs 8 \
-outputs 8 \
-inputs 1 \
-outputs 1 \
-update_stage true
dft_drc
preview_dft
insert_dft
current_test_mode my_regular
dft_drc
current_test_mode my_serial
dft_drc
current_test_mode my_parallel
dft_drc
### core2
define_test_mode my_regular -usage scan
define_test_mode my_serial -usage scan_compression
define_test_mode my_parallel -usage scan_compression
-test_mode my_regular
-xtolerance high \
-chain_count 250 \
-inputs 8 \
-outputs 8 \
-inputs 1 \

HASS Flow 6-33
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
-outputs 1 \
-update_stage true
dft_drc
preview_dft
insert_dft
current_test_mode my_regular
dft_drc
current_test_mode my_serial
dft_drc
current_test_mode my_parallel
dft_drc
### For core-level serializer insertion,
### you have to specify the same <number> in the
### set_scan_configuration -chain_count <number> and
### set_serialize_configuration -inputs <number> -outputs <number>
### commands for each core level configuration; otherwise,
### you will see unexpected errors.
### top level

-usage scan
-test_mode all
set_scan_compression_configuration -integration_only true \
dft_drc
preview_dft
insert_dft
In this script example, 2 scan-in and 2 scan-out ports are created for the serial mode and the
standard scan mode. For the parallel mode, 16 scan-in and 16 scan-out ports are created.
Serializer Chains Concatenated Across Cores

You can specify the number of scan ports at the top level so that the serializer chains can be
concatenated across multiple cores, as shown in Figure 6-16. This is controlled at the top
level by specifying the set_scan_configuration -chain_count command. When you

HASS Flow 6-34
specify a number equivalent to the sum of the numbers specified by

set_serialize_configuration -inputs number -outputs number at each core level,
the core-level scan ports are brought up to the top-level scan ports. They are not
concatenated across the cores. On the other hand, if you specify a number less than the
sum of the numbers specified by set_serialize_configuration -inputs number
-outputs number at each core level, only the specified number of scan ports are created at
the top level, which is accomplished by concatenating each core-level deserializer/serializer
register segment accordingly.
For the design example shown in Figure 6-16, if you specify the chain count at the top level
by using the set_scan_configuration -chain_count 1 command, only one scan-in and
one scan-out port is created for the serial mode and the standard scan mode.
Figure 6-16 HASS Flow With Serializer Chains Concatenated Across Multiple Cores
You should not specify a number larger than the sum of the numbers specified with the
set_serialize_configuration -inputs number -outputs number command for each
core.
Note:
In the concatenated serializer chain flow, DFTMAX compression might not be able to
build an optimal length serializer chain segment.
Suppose, for example, that you have 2 scan-ins and scan-outs for a 6-bit serializer on
core1, 2 scan-ins and scan-outs for a 6-bit serializer on core2, 2 scan-ins and scan-outs

HASS Flow 6-35
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
for a 4-bit serializer on core3, and that you want to create 2 scan-ins and scan-outs at the
top level.
You might expect two 8-bit serializer segments (6/2 + 6/2 + 4/2) to be created at the top
level, by concatenating core-level serializer segments. But this might not happen.
The workaround in this case is to create 6 scan-ins and scan-outs for core1 and core2,
and 4 scan-ins and scan-outs for core3 at the serializer core-level creation. This would
mean that each serializer segment is 1-bit. The tool would then have more flexibility to
create 8-bit serializer segments, which is the optimal length at the top level.
Hybrid Flow
If you have performed multiple core-level implementations but still have some user-defined
logic at the top level, you can apply the Hybrid flow. The Hybrid flow provides core integration
and serializer insertion for the user-defined logic at the same time at the top level.
To create a core implemented with a serializer codec, use the
set_scan_compression_configuration -serialize core_level command at each
core level. At the top level, specify the set_scan_compression_configuration
-serialize chip_level -hybrid true command. This enables the tool to insert a
serializer clock controller and a serializer codec for the top-level user-defined logic and then
integrate all the serializer cores.
The Hybrid flow does not support a user-defined test mode. You cannot have both a parallel
mode and a serial mode. Only a serial mode and a standard scan mode are supported
together. The generated test modes are
Figure 6-17 shows the Hybrid flow diagram. Example 6-12 shows the script for this case.

Hybrid Flow 6-36
Figure 6-17 Hybrid Flow Diagram
Example 6-12 Script Example for a Hybrid Flow

### core1
-xtolerance high \
-chain_count 150 \
-inputs 8 \
-outputs 8 \
-inputs 1 \
-outputs 1 \
-update_stage true
dft_drc
preview_dft
insert_dft
dft_drc
dft_drc

Hybrid Flow 6-37
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
### core2
-xtolerance high \
-chain_count 600 \
-inputs 12 \
-outputs 12 \
-inputs 2 \
-outputs 2 \
-update_stage true
preview_dft
dft_drc
insert_dft
dft_drc
dft_drc
### For core-level serializer insertion,
###you have to specify the same <number> in the
###set_scan_configuration -chain_count <number> and
###set_serialize_configuration -input <number> -output <number>
###commands for each core level configuration; otherwise,
###you will see unexpected errors.
### top level

-xtolerance high \
-chain_count 50 \
-inputs 6 \
-outputs 6 \
-hybrid true \
-inputs 1 \
-outputs 1 \
-update_stage true
dft_drc
preview_dft
insert_dft

Hybrid Flow 6-38

For the Hybrid flow, you set the numbers by using the set_scan_configuration
-chain_count number and the set_serialize_configuration -inputs number
-outputs number commands at the top level as follows:
The set_serialize_configuration -inputs number -outputs number command

specifies the number of scan-in and scan-out ports of the serializer codec used to take care
of the top-level user-defined logic. The set_scan_configuration -chain_count number
command specifies the total number of the top-level scan ports. The number specified with
the set_scan_configuration -chain_count number command at the top level has to be
exactly the same number as the sum of the numbers specified with the
set_serialize_configuration -inputs number -outputs number command for each
serializer codec.
In Example 6-12, you have one scan-in and one scan-out port for core1 and two scan-in and
two scan-out ports for core2. Then, because you have one scan-in and one scan-out port for
the serializer that takes care of the top-level user-defined logic, you have to specify four
scan-in and scan-out ports with the set_scan_configuration -chain_count number
command at the top level. This configuration ends up with four scan-in and four scan-out
ports created for both serial and standard scan mode.
Serializer Chains Concatenated Across Cores

Serializer scan chain concatenation is not supported in the Hybrid flow.
Serializer IP Insertion
When serialized compressed scan is inserted, the tool places the deserializer register inside
the decompression MUX block, and it places the serializer register inside the XOR
compression tree block. This architecture, shown in Figure 6-18, keeps the scan
compression logic together and minimizes the top-level routing requirements.

Serializer IP Insertion 6-39
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Figure 6-18 Default Serialized Compressed Scan Architecture
6, 'HVHULDOL]HU 'HFRPSUHVVRU
EORFN
'HFRPSUHVVLRQ08;
+LJKIUHTXHQF\
VHULDOVFDQ
SDWKV
;25FRPSUHVVLRQWUHH
&RPSUHVVRU
62 6HULDOL]HU EORFN
However, depending on layout characteristics, the long routes from the top-level scan I/O
connections to the serialization logic can reduce the maximum operating frequency for these
serial scan paths.
The DFTMAX tool provides a feature called serializer IP insertion that separates the
deserializer and serializer registers, collectively known as the serializer IP, from the
combinational codec logic. This architecture, shown in Figure 6-19, places the serializer IP
logic separately so that the layout characteristics of the high-frequency serial scan paths can
be improved.
Figure 6-19 Serializer IP Insertion Architecture
6, 'HVHULDOL]HU
'HFRPSUHVVLRQ08; 'HFRPSUHVVRU
EORFN
6HULDOL]HU,3EORFN
&RPSUHVVRU
;25FRPSUHVVLRQWUHH
EORFN
62 6HULDOL]HU
Serializer IP insertion can also be applied during HASS and Hybrid integration of cores that
already have combinational compressed scan inserted, as shown in Figure 6-20. The tool
inserts and connects the deserializer registers to the existing core-level decompressors, and
inserts and connects the serializer registers to the existing core-level compressors. In
addition to improving layout characteristics, this flow can be used to reduce the scan pin
requirements for existing compressed scan cores.

Figure 6-20 Inserting Serializer IP Around Combinational Compressed Scan Core
6, 'HVHULDOL]HU
6HULDOL]HU
8BFRUH FORFN 8BFRUH
FRQWUROOHU
62 6HULDOL]HU
The following sections provide more information on serializer IP insertion:

• Configuring Serializer IP Insertion
• Serializer IP Insertion in the Top-Down Flat Flow
• Serializer IP Insertion in the Top-Down Flat Flow With Partitions
• Serializer IP Insertion in the HASS Flow
• Serializer IP Insertion in the Hybrid Flow
• Serializer IP Insertion and Standard Scan Chains
• Limitations
Configuring Serializer IP Insertion

To insert serializer IP into a design or partition or around a compressed scan core, use the
-ip_inputs and -ip_outputs options of the set_serialize_configuration command:
-ip_inputs {object_name n object_name n ...} \
-ip_outputs {object_name n object_name n ...}
These options specify the number of top-level scan ports allocated to the serializer IP for
each object. They replace the -inputs and -outputs options used for normal serializer
insertion. The object_name argument can be a design name, partition name, or
compressed scan core instance name. The input and output port counts must be equal for
each object. If multiple objects exist in the design, multiple object name and port count pairs
can be specified.
If an update stage register is enabled with the -update_stage true option of the
set_serialize_configuration command, the tool includes the update stage register in
the serializer IP block.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Example 6-13 shows the commands used to identify the core shown in Figure 6-20 on
page 6-41.
Example 6-13 Specifying Serializer IP Insertion for Compressed Scan Cores
-ip_inputs {U_core_1 1} \
-ip_outputs {U_core_1 1}
You can use the set_dft_location command to specify the insertion locations for the
serializer IP logic and the codec logic:
set_dft_location -include {SERIAL_REG} ser_IP_instance_name
set_dft_location -include {DFTMAX} codec_instance_name
If the specified hierarchy level does not exist, the tool creates it during DFT insertion. For
more information, see “Specifying a Location for DFT Logic Insertion” on page 5-2.
When serializer IP insertion is enabled, the preview_dft and insert_dft commands issue
messages about each serializer IP block:
Inserting Load Deserializer IP
top_U_core_1_U_deserializer_ScanCompression_mode
for mode ScanCompression_mode
Number of inputs = 1
Maximum size per input = 3
Inserting Unload Serializer IP
top_U_core_1_U_serializer_ScanCompression_mode
for mode ScanCompression_mode
Number of outputs = 1
Maximum size per output = 3
Serializer IP Insertion in the Top-Down Flat Flow

In the top-down flat flow, the tool inserts the combinational codec and the serializer IP at the
same time. The script must define both the codec characteristics and the serializer
characteristics.
Since the serializer IP is inserted in the top-level design, the design name is specified using
the -ip_inputs and -ip_outputs options. In Example 6-14, serializer IP insertion is
performed for a top-level design named top_design.
Example 6-14 Inserting Serializer IP in a Top-Down Flat Flow
current_design top_design
set_scan_configuration \

-chain_count 6 \
-ip_inputs {top_design 1} \
-ip_outputs {top_design 1}
Figure 6-21 shows the resulting logic from Example 6-14.

Figure 6-21 Serializer IP Insertion in the Top-Down Flat Flow
WRSBGHVLJQ 'HVHULDOL]HU
6HULDOL]HU
FORFN
FRQWUROOHU
6HULDOL]HU
In this example, one scan-in port and one scan-out port are created for the serial mode. The
chain count value of one results in the same scan port count in both the standard scan mode
and the serial mode.
Serializer IP Insertion in the Top-Down Flat Flow With Partitions

In the top-down flat flow with partitions, the combinational codec and the serializer IP are
inserted at the same time. The script must define both the codec characteristics and the
serializer characteristics on a per-partition basis.
Since the serializer IP is inserted inside partitions, the partition names are specified using
the -ip_inputs and -ip_outputs options. In Example 6-15, serializer IP insertion is
performed for two partitions, a user-defined partition and the default partition.
Example 6-15 Inserting Serializer IP in a Top-Down Flat Flow With Partitions
# partition1
define_dft_partition partition1 -include {TOP_UDL_1 TOP_UDL_2}

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
-chain_count 6 \
-ip_inputs {partition1 1} -ip_outputs {partition1 1}
# default_partition
-chain_count 6 \
-ip_inputs {default_partition 1}
-ip_outputs {default_partition 1}

Figure 6-22 Serializer IP Insertion in the Top-Down Flat Flow With Partitions
WRSBGHVLJQ 'HVHULDOL]HU 'HVHULDOL]HU
GHIDXOWBSDUWLWLRQ SDUWLWLRQ
6HULDOL]HU
FORFN
FRQWUROOHU
6HULDOL]HU 6HULDOL]HU
In this example, the tool creates one scan-in port and one scan-out port for each partition,
for a total of two scan ports used in the serialized scan and standard scan modes.
Serializer IP Insertion in the HASS Flow

In the HASS integration flow, you can add serializer IPs around one or more compressed
scan cores and perform top-level core integration. The prerequisites for inserting serializer
IP around existing compressed scan cores are as follows:
• The core must have the same number of scan ports in standard scan mode and
-chain_count N
-inputs N -outputs N

• The core must have symmetrical codec scan I/O ports, where the values provided to the
-inputs and -outputs options of the set_scan_compression_configuration
command are equal.
• All scan chains in the core are compressed by a codec.
• No other test modes are defined except Internal_scan and ScanCompression_mode.
• No pipelined scan data is implemented inside the core.
• The core must be provided as a .ddc file or a test model file, so that test model
information is available for the scan compression logic.
In Example 6-16, serializer IP insertion is performed for core instances U_core_1 and
U_core_2.
Example 6-16 Inserting Serializer IP Around Cores in a HASS Flow
-integration_only true \
-ip_inputs {U_core_1 1 U_core_2 2} \
-ip_outputs {U_core_1 1 U_core_2 2}

Figure 6-23 Serializer IP Insertion in the HASS Flow
'HVHULDOL]HU 'HVHULDOL]HU
8BFRUHB 8BFRUHB
6HULDOL]HU
FORFN
FRQWUROOHU 6HULDOL]HU 6HULDOL]HU
In this example, the tool creates three scan-in ports and three scan-out ports for the serial
scan mode, one pair for U_core_1 and two pairs for U_core_2. The number specified with
the set_scan_configuration -chain_count command at the top level for the standard
scan mode should be large enough to satisfy the total number of serial mode scan ports
across all cores.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Referencing Multiple Codecs in Compressed Scan Cores

When a compressed scan core contains multiple codecs, you must specify the serializer IP
characteristics for each codec. When you specify serializer IP characteristics with the
-ip_inputs and -ip_outputs options, follow the compressed scan core cell name with the
name of a decompressor or compressor, respectively, inside the core. You must provide a
separate entry for each codec inside the core.
Example 6-17 specifies serializer IP characteristics for a single codec in a compressed scan
core named CORE1 and two codecs in a compressed scan core named CORE2.
Example 6-17 Serializer IP Insertion for Multiple Codecs in a Compressed Scan Core
-ip_inputs {CORE1 1 \
CORE2 core2_P1_U_decompressor_ScanCompression_mode 1 \
CORE2 core2_P2_U_decompressor_ScanCompression_mode 2} \
-ip_outputs {CORE1 1 \
CORE2 core2_P1_U_compressor_ScanCompression_mode 1 \
CORE2 core2_P2_U_compressor_ScanCompression_mode 2}

Figure 6-24 Serializer IP Insertion for Multiple Codecs in a Compressed Scan Core
'HVHULDOL]HU 'HVHULDOL]HU 'HVHULDOL]HU
&25( &25(
6HULDOL]HU
FORFN
FRQWUROOHU 6HULDOL]HU 6HULDOL]HU 6HULDOL]HU
You can obtain the decompressor and compressor names using one of the following
methods:
• Use the list_test_models -compressors command at the top level before DFT
insertion.
• Look in the CompressorStructures section of a core-level ASCII CTL model file.
• Look in the CompressorStructures section of a core-level STIL procedure file that is
generated for the scan compression mode.
Example 6-18 shows a report example from the list_test_models -compressors

command, run at the top level before DFT insertion.

Example 6-18 Report Example From the list_test_models -compressors Command

dc_shell> list_test_models -compressors
core1 /home/user/core1.db
Codecs:
core1_U_decompressor_ScanCompression_mode
core1_U_decompressor_ScanCompression_mode
core2 /home/user/core2.db
Codecs:
core2_P1_U_decompressor_ScanCompression_mode
core2_P2_U_decompressor_ScanCompression_mode
core2_P1_U_compressor_ScanCompression_mode
core2_P2_U_compressor_ScanCompression_mode
top /home/user/top.db
Codecs:
The report from the list_test_models -compressors command shows the list of designs
with CTL model information, along with the codec names defined in each CTL model.
However, the -ip_inputs and -ip_outputs options require core instance names, not
design names. To convert a design name to a list of instances, use the get_references
command. For example,
dc_shell> get_references core2
{CORE2}
Example 6-19 shows how the decompressor and compressor names are provided in an
example CompressorStructures block, contained in an ASCII CTL model file or STIL
procedure file.
Example 6-19 Decompressor and Compressor Names in a CompressorStructures Block
CompressorStructures {
Compressor "core2_P1_U_decompressor_ScanCompression_mode" {
...
}
Compressor "core2_P2_U_decompressor_ScanCompression_mode" {
...
}
Compressor "core2_P1_U_compressor_ScanCompression_mode" {
...
}
Compressor "core2_P2_U_compressor_ScanCompression_mode" {
...
}
}

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Serializer IP Insertion in the Hybrid Flow

The Hybrid flow is an extension of the HASS flow that applies scan compression to any
uncompressed top-level logic. The requirements and features of serializer IP insertion in the
HASS flow also apply to the Hybrid flow. See “Serializer IP Insertion in the HASS Flow” on
page 6-44.
Example 6-20 shows a typical Hybrid flow that inserts serializer IPs around existing
compressed scan cores, inserts an additional serializer and codec into the top-level
user-defined logic, and then integrates all the structures.
Example 6-20 Inserting Serializer IP Around Cores in the Hybrid Flow
current_design top_design

-chain_count 6 \
-hybrid true \
-ip_inputs {top_design 1 U_core_1 1 U_core_2 2} \
-ip_outputs {top_design 1 U_core_1 1 U_core_2 2}

Figure 6-25 Serializer IP Insertion in the Hybrid Flow
WRSBGHVLJQ 'HVHULDOL]HU 'HVHULDOL]HU 'HVHULDOL]HU
8VHUGHILQHG
8BFRUHB 8BFRUHB
ORJLF
6HULDOL]HU
FORFN
FRQWUROOHU
6HULDOL]HU 6HULDOL]HU 6HULDOL]HU
In this example, the script assigns a single scan-in and scan-out port to the top-level
serializer IP and codec by referencing the top-level design name with the -ip_inputs and
-ip_outputs options. The tool creates one scan-in and scan-out port for the serialized IP
inserted around U_core_1, and it creates two scan-in and scan-out ports for the serialized
IP inserted around U_core_2. There are a total of four scan connections in the serialized
scan mode.

The number specified with the set_scan_configuration -chain_count command at the

top level for the standard scan mode should be large enough to satisfy the total number of
serial mode scan ports across all cores. In this example, the chain count value of four results
in four scan-in and scan-out ports in both the standard scan mode and the serial mode.
Serializer IP Insertion in the Hybrid Flow With Top-Level Partitions

If you need to integrate combinational compressed scan cores but also have a great deal of
user-defined logic at the top level, you might want to use the Hybrid flow with top-level
partitions. This flow allows you to divide the user-defined logic into multiple partitions, each
of which has a serializer codec.
Consider the scenario shown in Figure 6-26.
• You have two compressed scan cores, U_core_1 and U_core_2.
• You want to distribute the top-level user-defined logic among two partitions, partition1
and the default partition.
• You want to insert serializer IP around each of the two compressed scan cores, with one
top-level serial scan-in and scan-out port for each core.
• You want to insert serialized compressed scan for each of the two top-level partitions,
with one top-level serial scan-in and scan-out port for each partition.
• You want to use four existing scan-in and four scan-out ports at the top level in both
standard scan mode and serial mode.
Figure 6-26 Serializer IP Insertion in the Hybrid Flow With Top-Level Partitions
'HVHULDOL]HU 'HVHULDOL]HU 'HVHULDOL]HU 'HVHULDOL]HU
GHIDXOWBSDUWLWLRQ SDUWLWLRQ
8BFRUHB 8BFRUHB
6HULDOL]HU
FORFN
FRQWUROOHU
6HULDOL]HU 6HULDOL]HU 6HULDOL]HU 6HULDOL]HU
Example 6-21 shows a Hybrid flow with top-level partitions script for this scenario.
Example 6-21 Script for a Serializer Hybrid Flow With Top-Level Partitions
# global settings
-hybrid true \

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
# partition1
define_dft_partition partition1 -include {TOP_UDL_1 TOP_UDL_2}
-chain_count 6 \
-ip_inputs {partition1 1} -ip_outputs {partition1 1}
set_dft_signal -view spec -type ScanDataIn -test_mode all \

-port {SI_PART1_0}
set_dft_signal -view spec -type ScanDataOut -test_mode all \
-port {SO_PART1_0}
# default partition
-chain_count 6 \
-ip_inputs {default_partition 1 U_core_1 1 U_core_2 1} \
-ip_outputs {default_partition 1 U_core_1 1 U_core_2 1}
set_dft_signal -view spec -type ScanDataIn -test_mode all \

-port {SI_PARTD_0 SI_PARTD_1 SI_PARTD_2}
set_dft_signal -view spec -type ScanDataOut -test_mode all \
-port {SO_PARTD_0 SO_PARTD_1 SO_PARTD_2}
dft_drc
insert_dft
In this flow, the compressed scan cores must exist in the default partition. As a result, they
are configured by the set_serialize_configuration command applied to the default
partition. The chain count applied to the default partition with the set_scan_configuration
-chain_count command includes both the compressed scan cores and the new top-level
codec.
Incorporating External Chains Into the Hybrid Serializer IP Flows

You might have compressed scan cores that contain one or more uncompressed external
scan chains, as shown in Figure 6-27.

Figure 6-27 External Uncompressed Chains in a Compressed Scan Core
8&
8&
8BFRUH
These uncompressed external scan chains are specified at the core level with the
set_scan_path command, as shown in Example 6-22.
Example 6-22 Defining External Uncompressed Chains at the Core Level

set_scan_path UC1 \
-view spec -test_mode all_dft \
-complete true -dedicated_scan_out true \
-scan_data_in SI_0 -scan_data_out SO_0 \
-ordered_elements {...}
set_scan_path UC2 \
-view spec -test_mode all_dft \
-complete true -dedicated_scan_out true \
-scan_data_in SI_1 -scan_data_out SO_1 \
-ordered_elements {...}
-chain_count 8 \
dft_drc
preview_dft -show scan
insert_dft
In Example 6-23, the Hybrid flow is used to insert serializer IP around a compressed scan
core, and to insert a full serialized codec around the top-level user-defined logic. The tool
includes the external chains in U_core as part of the user-defined logic.
Example 6-23 Incorporating External Chains Into Serializer IP Hybrid Integration
-hybrid true \
-serialize chip_level \
-chain_count 9 \
-ip_inputs [U_core 2 top_design_name 1] \
-ip_outputs [U_core 2 top_design_name 1]

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4

Figure 6-28 Serializer IP Insertion in the Hybrid Flow With External Chains
8VHUGHILQHG
8&
8&
8BFRUH
ORJLF
6HULDOL]HU
FORFN
FRQWUROOHU 6HULDOL]HU 6HULDOL]HU
If you are inserting serializer IP using the Hybrid flow with partitions, all external chains are
placed in the default partition by default. If you want to incorporate an external chain into a
different partition, you can include scan chain names in the partition definitions:
define_dft_partition P1 -include {top_UDL1 U_core/UC1}
define_dft_partition P2 -include {top_UDL2 U_core/UC2}
Figure 6-29 shows how these commands allocate the external chains between the two
partitions.
Figure 6-29 Allocating External Chains to Partitions in the Hybrid Serializer IP Flow
'HVHULDOL]HU 'HVHULDOL]HU 'HVHULDOL]HU

8&
8&
3 8BFRUH 3
6HULDOL]HU
FORFN
FRQWUROOHU
6HULDOL]HU 6HULDOL]HU 6HULDOL]HU
Note:
Scan chain names are only supported in partition definitions when this flow is being
used.
For more information on external chains, see “Excluding Scan Chains From Scan
Compression” on page 2-35.

Serializer IP Insertion and Standard Scan Chains

When compressed scan cores are wrapped with serializer IP logic in HASS and Hybrid
integration flows, the standard scan mode is also affected.
Due to the reduced number of available top-level scan I/O pins, the standard scan chains
inside the compressed cores can no longer be promoted to dedicated top-level connections.
To remedy this, standard scan chains in compressed scan cores become scan segments
that can be concatenated, if needed, by top-level integration. Figure 6-30 shows the
compressed scan and standard scan chains for a design in the HASS serializer IP insertion
flow.
Figure 6-30 Standard Scan Chains in the HASS Serializer IP Insertion Flow
&B&25( &B&25( &B&25( &B&25(
In the Hybrid flow with serializer IP insertion, core-level scan segments can be mixed with
top-level scan cells to achieve optimal balancing. Figure 6-31 shows the compressed scan
and standard scan chains for a design in the Hybrid serializer IP insertion flow.
Figure 6-31 Standard Scan Chains in the Hybrid Serializer IP Insertion Flow
&B&25( &B&25(
Standard scan chain concatenation is not needed for cores that are already serialized
because such a core’s standard scan mode is architected to use the same scan I/O
resources as its serialized compressed scan mode.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Limitations
The serializer IP insertion feature has the following limitations:
• For each combinational compressed scan core, the number of scan inputs and scan
outputs must be the same for the standard scan mode and the compressed scan mode.
• All cores must have the same X-tolerance type. A mix of default X-tolerance and high
X-tolerance is not supported.
• Multiple user-defined compressed scan test modes are not supported at the core level or
the top level.
• Pipeline scan data registers are not supported at the core level.
• A mix of combinational compressed scan cores and serialized compressed scan cores
is not supported.
• Serializer chains cannot be concatenated across cores at the top level.
• There is no support for core-specific serializer IP insertion.
• The number of serializer scan ports specified with the -ip_inputs and -ip_outputs
options must be less than the number of combinational codec inputs and outputs,
respectively.
• Lock-up latch insertion is not supported between the serializer IP and core scan cells.
❍ If scan clocks exist inside the compressed scan core that differ from the serializer
register clock, you should insert lock-up latches inside the compressed scan core.
Insert them between the decompressor outputs and first scan elements and between
the last scan elements and the compressor inputs. This must be done manually. The
tool cannot modify DFT-inserted cores during serializer IP insertion.
Wide Duty Cycle Support for Serializer

By default, the internally generated scan shift clocks and the update stage clock are created
by gating external clocks with enable signals generated by the serializer FSM counter. The
enable signals go active every S cycles, where S is the length of the serializer register
segment. Therefore, the internally generated scan shift clocks and the update stage clock
are inactive for (S-1) external clock cycles and pulse only at cycle S.
When you have an 8-bit serializer with one scan-in port and one scan-out port, the length of
the serializer segment is 8. When the external clock has a 10 percent duty cycle (for
example, rise = 45ns, fall = 55ns, period = 100ns), the clock duty cycle of the internally
generated clock is 1.25 percent. Figure 6-32 illustrates this scenario.

Wide Duty Cycle Support for Serializer 6-54
Figure 6-32 Timing Diagram With Default Duty Cycle
With a narrow pulse width, two issues exist:

• The clock skew for internal clocks might be more than the pulse width, thereby leading to
problems in shift.
• Because of rise and fall slew, the clock might not reach its logic level completely, and the
clock waveform might be clipped.
Wide duty cycle support makes the clock duty cycle close to 50 percent, resolving these
problems.
To enable the wide duty cycle support feature, use the following option setting:
set_serialize_configuration -wide_duty_cycle true
After the option is accepted, the preview_dft command shows the following information
message:
Information: Implementing Wide Duty Cycle Serializer Clock Controller.
Block Diagram
Figure 6-33 shows the block diagram when you implement the wide duty cycle.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Figure 6-33 Block Diagram With Wide Duty Cycle Support
When the -wide_duty_cycle true option is specified, the tool uses the following
behaviors:
• The update stage is always inserted in the decompressor IP, and the following
information message appears:
Information: the update stage will be enabled in presence of wide duty
cycle.
• Lock-up latches are always inserted in the decompressor IP between the deserializer
registers and the update stage registers. Note that lock-up latch insertion is also
available when the update stage is inserted without the wide duty cycle support enabled
by using the following variable:
set_app_var test_elpc_lul_in_deserializer true
• A synchronizing stage is inserted in the compressor IP. The synchronizing stage

registers help hold the scan-out data until serializer registers capture it. The clock of the

synchronizing stage registers is the same as the clock of the update stage registers
inserted in the decompressor IP.
• No clock-gating logic is used in the serializer clock controller.
Timing Diagram
Figure 6-34 shows the timing diagram for a 4-bit serializer, indicating how it behaves.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Figure 6-34 Timing Diagram With Wide Duty Cycle Support
Internally Generated Clocks

The following examples show how the internally generated scan shift clocks are created
when wide duty cycle support is enabled.

When you have a 7-bit serializer with one scan-in port and one scan-out port, the length of
the serializer segment is 7. With the wide duty cycle enabled, the clock is on for 3 external
clock cycles and off for 4 external clock cycles, as illustrated in the Figure 6-35.
Figure 6-35 Timing Diagram of Default Duty Cycle and Wide Duty Cycle Clock
Table 6-2 provides a table that shows the clock width based on the length of the serializer
segment.
Table 6-2 Wide Duty Cycle Clock Width Based on Serializer Segment Length
Serializer segment length # of external clock cycles for clock ON (OFF)
2 1 (1)
3 1 (2)
4 2 (2)
5 2 (3)
6 3 (3)
7 3 (4)
8 4 (4)
9 4 (5)
10 5 (5)

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Wide Duty Cycle in a Core-Level Flow

When you use the wide duty cycle feature, you must set the -wide_duty_cycle option to
true at each core creation. This setting allows the tool to insert the update stage and the
synchronization stage into the decompressor and the compressor, respectively.
Use the following command example for the core-level flow:
-xtolerance high \
-chain_count 400 \
-inputs 8 \
-outputs 8 \
-inputs 1 \
-outputs 1 \
-wide_duty_cycle true
Wide Duty Cycle in the HASS Flow

In the HASS flow, use the following command example:
-integration_only true \
Note the following when you use the wide duty cycle feature in the HASS flow:
• All serializer cores must be implemented with the -wide_duty_cycle true option.
• The option -wide_duty_cycle true must also to be set at the top level.
Wide Duty Cycle in the Hybrid Flow

In the Hybrid flow, use the following command example:
-xtolerance high \
-chain_count 400 \
-inputs 1 \
-outputs 1 \
-hybrid true \

-inputs 1 \
-outputs 1 \
Note the following when you use the wide duty cycle feature in the Hybrid flow:
• All serializer cores and the top-level serializer must be implemented with the option
setting -wide_duty_cycle true.
Dual STIL Flow Parallel Patterns

When you use Wide Duty Cycle support and write out parallel patterns with the Dual STIL
flow in TetraMAX ATPG, the waveform table contains multiple clock pulses as shown in
Example 6-24.
Example 6-24 Waveform Table _default_WFT_parallel
WaveformTable "_default_WFT_parallel_" {
Period '30ns';
Waveforms {
"EXT_CLK1" { P { '0ns' D; '4ns' U; '7ns' D; '14ns' U; '17ns' D;
'24ns' U; '27ns' D; } }
"EXT_CLK2" { P { '0ns' D; '4ns' U; '7ns' D; '14ns' U; '17ns' D;
'24ns' U; '27ns' D; } }
"all_bidirectionals" { 0 { '0ns' D; } }
"all_bidirectionals" { 1 { '0ns' U; } }
"all_bidirectionals" { T { '0ns' Z; '3ns' T; } }
"all_bidirectionals" { X { '0ns' Z; '3ns' X; }
"all_bidirectionals" { H { '0ns' Z; '3ns' H; } }
"all_bidirectionals" { Z { '0ns' Z; } }
"all_bidirectionals" { L { '0ns' Z; '3ns' L; } }
"all_bidirectionals" { N { '0ns' N; } }
This waveform table holds forced values at the state elements for multiple external clock
cycles so that scan cells driven by both the leading and trailing edges of the generated wide
duty cycle clocks can capture the values. Figure 6-36 shows how the waveform is used.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Figure 6-36 Application of the _default_WFT_parallel Waveform
This waveform example uses a 4-bit serializer. The clock-on for the internally generated
wide duty cycle clock is equal to two external clock cycles. The forced value is held across
three external clock cycles. Regardless of whether the scan cells are driven by the leading
or trailing edge of the generated wide duty cycle clock, the scan cells can capture the forced
value.
However, if you make both the external clocks wide and the trailing edge close to the end of
the cycle, the trailing edge of the generated wide duty cycle clock might cross into the
capture window due to internal delay on the clock line. This potential timing issue is shown
in Figure 6-37.

Figure 6-37 Potential Timing Issues for the _default_WFT_parallel Waveform
If this timing problem occurs, the shift operation cannot perform properly on scan cells
triggered by the trailing edge of the generated wide duty cycle clock. The problem is
independent of pattern format. Therefore, you should plan carefully to avoid this problem.
Limitations
Note the following limitation with the wide duty cycle feature:
• Staggered clock is not supported.
Serializer in Conjunction With On-Chip Clocking Controllers

The relationship between serializer clock controllers and on-chip clocking (OCC) controllers
is discussed in the following sections.
Using Serializer With User-Defined OCC Controllers

By default, the serializer clock controller generated by the DFTMAX tool considers the clock
pulse of the preamble vector outside the shift procedure to ensure correct operation for the
DFT-inserted OCC controller. Existing user-defined OCC controllers that require the
preamble clock pulse to enter shift mode are compatible with the default serializer clock
controller. However, some user-defined OCC controllers do not require the preamble clock
pulse. In this case, specify the following variable before the test protocol generation:
set_app_var test_ate_sync_cycles 0

Serializer in Conjunction With On-Chip Clocking Controllers 6-63
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
For more information, see SolvNet article 035708, “What Does the test_ate_sync_cycles
Variable Do?”.
Using a Serializer Clock Controller With Multiple OCC Controllers

When multiple DFT-inserted OCC controllers are specified with a serializer, a single
serializer clock controller is inserted. This single serializer clock controller internally
generates a slow clock that connects to the slow_clock pin of each OCC controller. This
clock and controller structure is shown in Figure 6-38.
Figure 6-38 Serializer Clock Controller With Multiple OCC Controllers, Default Architecture
An alternate architecture is also available by setting the test_elpc_unique_fsm variable to

false. In this alternate architecture, a separate serializer clock controller is inserted into
each OCC controller, so that the resulting locally-generated slow serializer clock can feed
the glitch-free clock selection MUX inside the OCC controller. See Figure 6-39.

Figure 6-39 Serializer Clock Controller With Multiple OCC Controllers, Alternate Architecture
This alternate architecture is supported in both the top-down flat flow and the top-down
partition flow. This architecture might lead to long wires connecting the external clock port to
the slow_clk pin of each OCC controller, which can produce congestion and timing issues
when the external clock frequency is high
For more information on the OCC insertion flow, see the DFT Compiler Scan User Guide.
Waveforms for a Serializer With OCC Controllers

If you use a DFT-inserted OCC controller without a serializer, the tool connects the
slow_clk pin of the OCC controller to an ATE-provided clock, which is one of the clocks
specified with the set_dft_signal -type ScanClock command. Even in a serializer flow,
the OCC controller must be connected to a clock corresponding to a scan shift clock that is
actually an internally-generated scan shift clock created by the serializer clock controller.
The two waveform examples shown in Figure 6-40 and Figure 6-41 illustrate parallel mode
and serial mode behavior. For the serial mode example, a single serializer clock controller is
used, as discussed in “Using a Serializer Clock Controller With Multiple OCC Controllers” on
page 6-64.
You can compare the waveforms directly at the OCC controller pins.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Figure 6-40 OCC With Parallel Mode
Figure 6-41 OCC With Serial Mode
As seen in these two figures, the serial mode behavior is the same as the parallel mode
behavior during capture, while the scan-enable signal (scan_en) is low. For the shift mode,
the internally generated clocks need to drive the scan cells. Since this flow uses an inserted
OCC controller, the internally generated scan clock drives the OCC controller slow_clk
input pin. Then, one clock pulse after capture is consumed inside the OCC controller, the
output of the OCC controller drives the scan cells.

Using Integrated Clock-Gating Cells in the Serializer Clock

Controller
By default, the tool uses discrete cells for clock-gating logic in a serializer clock controller.
Using the following variables, you can specify one of your integrated clock-gating cells for
the serializer clock gating logic:
set_app_var test_icg_p_ref_for_dft "library cell name"
set_app_var test_icg_n_ref_for_dft "library cell name"
The test_icg_p_ref_for_dft variable specifies a library cell to be used to gate

Return-to-Zero clocks. The test_icg_n_ref_for_dft variable specifies a library cell to be
used to gate Return-to-One clocks. The tool automatically inserts the specified integrated
clock-gating cells depending on the clock polarity.
User-Defined Pipelined Scan Data

If you implement user-defined pipelined scan data registers by hand, be careful of the
driving edge and the timing. The input-side pipelined scan data registers are connected from
the scan-in ports to the deserializer registers directly. The deserializer registers are triggered
by the trailing edge. Ideally, the pipelined scan data registers should be triggered by the
same edge and operate with the same timing to be safe. In the same manner, the
output-side serializer registers should be triggered by the leading edge, so as not to produce
a shift error. The same edge and the same timing are recommended.
Running TetraMAX ATPG on Serializer Designs

You can perform two types of ATPG with the TetraMAX ATPG tool:
• Chip-level ATPG where the serializer clock controller is inserted and the compressed
scan chain clock is provided by the serializer clock controller
• Core-level ATPG where both a serializer clock and internal scan shift clocks are provided
directly from the primary ports
Chip-level ATPG is performed on designs completed with the top-down flat flow, top-down
partition flow, HASS flow, or Hybrid flow. Core-level ATPG is performed on a core
implemented with the set_scan_compression_configuration -serialize core_level
command, which is normally integrated later with other cores by using a HASS or Hybrid
flow.

Using Integrated Clock-Gating Cells in the Serializer Clock Controller 6-67
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Chip-level and core-level test protocols are somewhat different, but the TetraMAX tool
identifies them and performs ATPG accordingly without requiring any special commands or
guidance.
The following topics are covered in this section:
• Simulation and Patterns
• STIL Procedure File
• Debugging TetraMAX Serializer DRC Errors
• Pattern Translation
• Known Issues
Simulation and Patterns

The following sections describe the support for read/write patterns and pattern validation.
Note that the normal DFTMAX limitations also apply. See “Limitations Associated With
Adaptive Scan Technology” on page 1-9.
Reading and Writing Patterns

WGL, serial STIL, and binary patterns can be read back and written out. TDL91, TSTL2, and
FTDL can also be written out.
Pattern Validation
Table 6-3 and Table 6-4 provide the support matrix tables for the serial mode.
Table 6-3 Pattern Validation Support: Verilog DPV
Verilog DPV
Dual STL flow Unified STIL flow
Serial Parallel Serial Parallel
Chip Supported Supported Supported Supported

level
Core Supported Not Supported Supported

level available

Running TetraMAX ATPG on Serializer Designs 6-68
Table 6-4 Pattern Validation Support: MAX Testbench
MAX Testbench
Dual STL flow Unified STIL flow
Serial Parallel Serial Parallel
Chip Supported Supported Supported Supported

level
Core Supported Not Supported Supported

level available
STIL Procedure File

STIL procedure file examples are presented for the following cases:
• load_unload procedures with and without an update stage
• Chip level with and without an update stage

• Core level
Also, the following compressor structure files are considered:
• Decompressor SPF
• Compressor SPF
load_unload Procedure
For the chip-level STIL procedure file, the usage of the load_unload procedure, including
shift and test_setup, is identical to the parallel mode as well as combinational scan
compression mode. Some other UserKeywords sections used by the TetraMAX tool are
provided. An additional sequence provided in the load_unload and shift procedures is only
for the core-level STIL procedure file.
Example 6-25 shows a STIL procedure file example that does not include an update stage.
Example 6-25 STIL Procedure File Example Without an Update Stage
"_clk" = '"ext_clk1" + "ext_clk2" + "ser_clk"';
...
"load_unload" {
W "_default_WFT_";
ActiveScanChains core_group;
C {
"dat1[0]" = N;

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
...
}
"ScanCompression_mode_pre_shift" : V { -- (1)
"_clk" = 00P;
"_si" = #;
"_so" = #;
"strobe" = 0;
"test_se" = 1;
}
Shift {
V { -- (2)
"_clk" = 00P;
"_si" = #;
"_so" = #;
"strobe" = 0;
}
V { -- (3)
"_clk" = 00P;
"_si" = #;
"_so" = #;
}
V { -- (4)
"_clk" = 00P;
"_si" = #;
"_so" = #;
}
V { -- (5)
"_clk" = PPP;
"_si" = #;
"_so" = #;
"strobe" = 1;
}
}
}
This STIL procedure file example defines a configuration with one scan-in and one scan-out,
and a 4-bit deserializer/serializer registers without an update stage. The vector (1) named
“ScanCompression_mode_pre_shift,” which is outside the shift procedure, uses the first
serializer clock (“ser_clk”) to load the first internal shift data into the deserializer registers.
The vector (4), which is the third vector of the shift procedure, completes loading the first
internal shift data into the deserializer registers. At vector (5), internal scan clocks (“ext_clk1”
and “ext_clk2”) are pulsed, and the first internal shift data that has been placed on the
deserializer registers is transferred to the compressed chains; also, the second internal shift
data starts loading into the deserializer registers. The “ScanCompression_mode_pre_shift”
vector is applied only to the first vector, and then the shift procedure is repeatedly applied as
many times as the number of compressed chain shifts per pattern. The scan-out measure
also takes place with each vector.

If the number of compressed chain shifts is 5, the actual vector sequence in a single pattern
is
(1) (2)(3)(4)(5) (2)(3)(4)(5) (2)(3)(4)(5) (2)(3)(4)(5) (2)(3)(4)(5)
and the capture takes place.
Example 6-26 shows a STIL procedure file example that includes an update stage.
Example 6-26 STIL Procedure File Example With an Update Stage
"_clk" = '"ext_clk1" + "ext_clk2" + "ser_clk" + "update_clk"';
...
"load_unload" {
W "_default_WFT_";
ActiveScanChains core_group;
C {
"dat1[0]" = N;
...
"ScanCompression_mode_pre_shift" : V { -- (1)
"_clk" = 00P0;
"_si" = #;
"_so" = #;
"strobe" = 0;
"test_se" = 1;
}
V { -- (2)
"_clk" = 00P0;
"_si" = #;
"_so" = #;
}
V { -- (3)
"_clk" = 00P0;
"_si" = #;
"_so" = #;
}
V { -- (4)
"_clk" = 00P0;
"_si" = #;
"_so" = #;
}
V { -- (5)
"_clk" = 00PP;
"_si" = #;
"_so" = #;
}
Shift {
V { -- (6)
"_clk" = 00P0;
"_si" = #;
"_so" = #;
"strobe" = 0;
}

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
V { -- (7)
"_clk" = 00P0;
"_si" = #;
"_so" = #;
}
V { -- (8)
"_clk" = 00P0;
"_si" = #;
"_so" = #;
}
V { -- (9)
"_clk" = PPPP;
"_si" = #;
"_so" = #;
"strobe" = 1;
}
}
}
If you implement the update stage, you see additional vectors only at the beginning of each
pattern. The first serializer clock (“ser_clk”) is pulsed at the vector (1). The vector (4)
completes loading the first internal shift data into deserializer registers. At the vector (5), the
first internal shift data that was placed on the deserializer registers is transferred to the
update stage. At the same time, the second shift data starts loading into the deserializer
registers. Then, vector (8) completes loading the second internal shift data into the
deserializer register. At vector (9), taking place at the same time, the first internal shift data
that has been on the update stage is transferred to the compressed chains, the second
internal shift data that has been on the deserializer registers is passed on to the update
stage, and the third internal shift data starts loading into the deserializer registers. If the
number of compressed chain shifts is 5, the actual vector sequence in a single pattern is
(1) (2)(3)(4)(5) (6)(7)(8)(9) (6)(7)(8)(9) (6)(7)(8)(9) (6)(7)(8)(9) (6)(7)(8)(9)
and the capture takes place.
UserKeywords SerializerStructures
For the serial mode, “UserKeywords SerializerStructures” is introduced. Some of its
parameters are used during DRC.
Chip-Level STIL Procedure File

The Length <number> is the number of deserializer/serializer registers bits. The
InternalShiftStart <number>, UnloadDataStart <number>, and
ExternalCyclePerShift <number> are determined by architecture. Example 6-27 shows
a chip-level STIL procedure file example without an update stage, and Figure 6-42 shows
how the Length, InternalShiftStart, UnloadDataStart, and ExternalCyclePerShift
numbers are determined for this STIL procedure file example.

Example 6-27 Chip-Level STIL Procedure File Example Without an Update Stage
UserKeywords SerializerStructures CompressorStructures;
SerializerStructures {
InternalShiftStart 5;
UnloadDataStart 6;
ExternalCyclesPerShift 4;
LoadSerializer "U0/U_deserializer_my_serial" {
Length 4;
ActiveScanChains load_group; }
UnloadSerializer "U0/U_serializer_my_serial" {
Length 4;
ActiveScanChains unload_group;
}
}
Figure 6-42 Timing Diagram for SerializerStructures for Chip-Level STIL Procedure File
Example Without an Update Stage
If the update stage is used, the “UserKeywords SerializerStructures” changes as follows:

InternalShiftStart is delayed by 4 cycles, from 5 cycles to 9, and UnloadDataStart is
delayed by 4 cycles, from 6 cycles to 10. Example 6-28 shows this chip-level STIL procedure
file example with an update stage.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Example 6-28 Chip-Level STIL Procedure File Example With an Update Stage
UnloadDataStart 10;
Length 4;
ActiveScanChains load_group;
}
Length 4;
}
}
In addition to the configuration shown in Example 6-28, if pipelined scan data is used (for
example, two stages of head pipeline), the InternalShiftStart is delayed by another two
cycles, from 9 to 11. If two stages of tail pipeline are also used, UnloadDataStart is delayed
by two cycles, from 12 to 14. Example 6-29 and Example 6-30 show these two cases.
Example 6-29 SerializerStructures Example With Update Stage and Head Pipeline Registers
UnloadDataStart 12;
SerializerInputPipelineStages 2;
Length 4;
}
Length 4;
}
}
Example 6-30 SerializerStructures Example With Update Stage and Head and Tail Pipeline
Registers
UnloadDataStart 14;
SerializerOutputPipelineStages 2;
Length 4;
}

Length 4;
}
}
When you use the wide duty cycle feature, the “UserKeywords SerializerStructures” section
of the STIL procedure file shows at which external clock cycle the leading and trailing edges
of the internally generated scan shift clocks occur. Example 6-31 provides an example with
this information included.
Example 6-31 Chip-Level STIL Procedure File Example With Wide Duty Cycle Feature
InternalShiftStartLeadingEdge 12;
InternalShiftStartTrailingEdge 15;
UnloadDataStart 16;
LoadSerializer "U0/U1_deserializer_my_serial" {
Length 7;
}
UnloadSerializer "U0/U1_serializer_my_serial" {
Length 7;
}
}
This example shows that the leading edge occurs at the 12th cycle and the trailing edge at
the 15th cycle. Figure 6-43 shows the corresponding timing diagram.
Figure 6-43 Correspondence Between SerializerStructures and Clock Creation

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Core-Level STIL Procedure File

For a core-level test protocol, the InternalShiftStart is used differently. This number is
always one and specifies the number of generic shift procedures performed before the first
internal shift. Example 6-32 provides a core-level STIL procedure file example.
Example 6-32 Core-Level STIL Procedure File Example
UnloadDataStart 6;
LoadSerializer "bottom1_U_deserializer_ScanCompression_mode" {
Length 4;
}
UnloadSerializer "bottom1_U_serializer_ScanCompression_mode" {
Length 4;
}
}
Compressor Structures
Figure 6-44 and Figure 6-45 contrast the compressor structures of the serial and parallel
modes.

Figure 6-44 Decompressor SPF

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Figure 6-45 Compressor SPF
This comparison assumes the architecture represented in Figure 6-46. TetraMAX ATPG
assigns indexes 0 1 2 ... to the deserializer and serializer registers from the scan-out side.
The scan-in port SI_0 in parallel mode corresponds to the deserializer register bit 0 in serial
mode. The scan-out port SO_0 in parallel mode corresponds to the serializer register bit 0
in serial mode.

Figure 6-46 Correspondence Between Serial and Parallel Modes
ClockStructures
The ClockStructures section prints the output pins of the internally generated scan clocks,
as shown in Example 6-33:
Example 6-33 ClockStructures Example for a STIL Procedure File
UserKeywords DontSimulate;
ClockStructures {
PLLStructures “serializer_init_shift_clocks” {
Clocks {
“u_clockcntrl/wide_clkgen/C75/U1/Z” PLLShift {
OffState 0;
}
“u_clockcntrl/wide_clkgen/C75/U2/Z” PLLShift {
OffState 0;

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
}
}
}
}
This information about internally-generated clocks can help TetraMAX DRC. You can
prevent the write_test_protocol command from including this information in the SPF by
setting the test_serialize_put_fsm_clock_output variable to false.
Debugging TetraMAX Serializer DRC Errors

When running TetraMAX ATPG on designs that contain serializer blocks, you might
encounter design rule violation (DRC) errors which are specific to the serializer flow. This
section provides debugging information for such DRC errors.
The following topics are discussed in this section:
• Debugging R33 Through R38 DRC Errors
• Providing Guidance for R34 and R36 DRC Errors
Debugging R33 Through R38 DRC Errors

When R33 to R38 errors are issued by TetraMAX ATPG, the following debug method might
be helpful to isolate the issue.
For an R37 error:
Error: Scan cell 19806 was clocked during serializer nonshifting cycle.
(R37-1)
The scan cells of the compressed scan chains must be clocked as described in Figure 6-2
on page 6-6. This error indicates that the scan cells are clocked at incorrect cycles.
To debug the issue, apply the following method:
DRC-T> set_drc -store_initial_shifts
DRC-T> set_pindata -shift
DRC-T> run_drc -patternexec my_serial
DRC-T> (gui_start)
When you open the TetraMAX GSV, look at the cell 19806. Figure 6-47 shows the pin data.

Figure 6-47 Pin Data Example for a Scan Cell With an R37 Error
You can find the clock being pulsed in every shift cycle at the CP pin of the scan cell, which
is not correct. Refer to the SerializerStructures section in your SPF to determine the
correct clocking. If you see the following in the SerializerStructures section:
UnloadDataStart 17;
SerializerOutputPipelineStages 2;
LoadSerializer
"my_top_U_deserializer_ScanCompression_mode" {
Length 4;
}
UnloadSerializer
"my_top_U_serializer_ScanCompression_mode" {
Length 4;
}
LoadSerializer "I_coreA/U_deserializer_ScanCompression_mode" {
Length 6;
ActiveScanChains "coreA_load_group";
}
UnloadSerializer "I_coreA/U_serializer_ScanCompression_mode" {
Length 6;
ActiveScanChains "coreA_unload_group";
}
}
then the first clocking for compressed scan chains is at the 14th cycle. You can check this
with the value of the InternalShiftStart. If clocking exists in some other cycles, the
clocking scheme is incorrect.
Figure 6-48 shows the pin data example on one of the scan cells with the correct clocking
behavior.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Figure 6-48 Pin Data Example for a Scan Cell With Correct Clocking
Verify that the clock pulse happens at 14th cycle, which is consistent with the
InternalShiftStart value in the SPF.
As a reference, in the following pin data example shown in Figure 6-49, notice what happens
to one of the deserializer registers, the serializer registers, serializer FSM counter, and
update stage registers, when you have the same SerializerStructures as the serializer
structure just described.
Figure 6-49 Pin Data Example for Some Cells of the Serializer Logic
The first cell is one of the serializer registers at the output side. The second cell is one of the
deserializer registers at the input side. The third cell is one of the serializer FSM counter
registers. Those registers need to have the external clock pulses from the primary port

without serializer clock gating. The fourth cell is one of the update stage registers. The clock
pulses appear on the registers at the 8th cycle and 14th cycles, which can be explained in
the following way:
The number of head pipeline registers is 1 and the maximum length of the serializer
registers is 6. To load scan data fully to the deserializer registers, 6+1=7 cycles are required.
Then at the next cycle, which is 8th cycle, the scan data that has been loaded into the
deserializer registers is transferred to the update stage registers. This is the reason why the
8th cycle on the update register has a clocking. The next scan data is also serially loaded
through the pipeline register to the deserializer registers, consecutively. Since the length of
the serializer registers is 6, 8+6=14 is the next clocking for the update stage to obtain the
second scan data. Also, at the 14th cycle, the data transfers from the update registers to the
compressed scan chains.
These examples show you how to read the pin data, using the set_drc
-store_initial_shifts command. After you apply this command, TetraMAX DRC does
not pass, but it does show you the stored shift data. You need to reset using the set_drc
-nostore_initial_shifts command after you have completed your debug to proceed in
the same session.
Providing Guidance for R34 and R36 DRC Errors

In some cases, TetraMAX DRC cannot identify the deserializer/serializer registers due to the
presence of other topologically-connected nonscan cells. In these cases, TetraMAX DRC
might issue R34 or R36 violations. The TetraMAX tool provides a method to allow user
guidance to be provided in the STIL procedure file to specify the correct deserializer/
For example, consider the following TetraMAX DRC violations:
Error: Multiple candidates (192417,185880) for mode-port input with
serializer connection test_si1 (4). (R36-1)
Error: Multiple candidates (192418,185824) for mode-port input with
serializer connection test_si1 (3). (R36-2)
Error: Multiple candidates (192419,185825) for input 2 of load compressor
abc_top_U_decompressor_abc. (R36-3)
To determine the cell names of the reported primitives for the first DRC error, use the
report_primitives command on the two reported primitive IDs:
DRC-T> report_primitives 192417
abc_top_U_decompressor_abc/serial_reg_4_ (192417) DFF (DFF_X1)
--- I (TIE_0)
--- I (TIE_0)
!CK I 88837-u_clockcntrl/U14/X

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
--- I
159-
Q O
178252-/abc_top_U_decompressor_abc/serial_reg_3_/D
178253-/abc_top_U_decompressor_abc/U7/A ...
DRC-T> report_primitives 185880
xyz_dig_u/xyz__u/shiftreg_reg_47_ (185880) DFF (DFF_X2)
--- I (TIE_0)
!RD P I 143-xyz_dig_u/xyz__u/U83/X
CK I 156-xyz_dig_u/gpio_pads_ctrl_u/svn_buf_s_16_u2/X
--- I 88745-
--- O 88743-
88745-
The reported instance names show that the primitive ID 192417 represents the correct
serializer register. Next, you must identify the serializer index for this primitive. Since the R36
violations are issued on the deserializer side, which is a compressor, you must run the
report_serializers -load -verbose command. For this example, the output is as
follows:
DRC-T> report_serializers -load -verbose
------------------------------------------------ ------ ------
name type length
------------------------------------------------ ------ ------
abc_top_U_deserializer_abc load 5
------ ----- ---------------- ----------------- ------
Scanin Index Serializer Index Parallel Outputs invert
------ ----- ---------------- ----------------- ------
test_si1 0 0 xyz_dig_u/xyz__u/shiftreg_reg_43_ no
From this report, you can determine that primitive ID 192417 corresponds to the serializer
index 4, as the other primitive ID 185880 matches the load register for serializer index 4. You
can repeat this process to match the other serializer register names to their corresponding
index values.
Next, open the STIL procedure file in a text editor. Locate the SerializerStructures
section, and create a ParallelOutputs block as demonstrated in the following file:
UnloadDataStart 7;
LoadSerializer "abc_top_U_deserializer_abc" {
Length 5;
ParallelOutputs {
0 "abc_top_U_decompressor_abc/serial_reg_0_" no

}
}
UnloadSerializer "abc_top_U_serializer_abc" {
Length 5;
}
}
Note the following points when providing deserializer/serializer register guidance to

TetraMAX DRC:
• The numbers specified before the serializer register name on each line must match the
serializer index values as reported by the report_serializers -verbose command.
• The serializer register names should be enclosed in double quotation marks.
• The no or yes value specified after the serializer register names specifies whether a logic
inversion exists between the data input pin of each serializer register and the
corresponding scan port.
• When you provide deserializer register (input side) guidance as with the previous
example, you must supply it in a ParallelOutputs block inside the LoadSerializer
section. When you provide serializer register (output side) guidance, you must supply it
in a ParallelInputs block inside the UnloadSerializer section.
• Guidance is only needed for deserializer/serializer registers with R36 DRC violations.
You do not need to supply guidance for other deserializer/serializer registers.
When TetraMAX DRC processes the updated STIL procedure file, it will verify that the
specified register names and inversion flags are correct. If TetraMAX DRC determines that
the register name is incorrect, it will issue an M873 warning message:
Warning: Possibly incorrect load serializer parallel output
specification: %d %s.(M873)
Warning: Possibly incorrect unload serializer parallel input
specification: %d %s.(M873)
If TetraMAX DRC determines that the register inversion flag is incorrect, it will issue an M874
warning message:
Warning: Possibly incorrect load serializer parallel output inversion
specification: %d %s %s.(M874)
Warning: Possibly incorrect unload serializer parallel output inversion
specification: %d %s %s.(M874)
When the register names and inversion flags are valid, TetraMAX DRC honors the specified
serializer register definitions and proceeds with the DRC process.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Pattern Translation
This section describes the following types of serialized scan pattern translation:
• Translating Parallel Mode Patterns to Serial Mode Patterns
• Translating Serial Mode Patterns to Standard Scan Mode Patterns
Translating Parallel Mode Patterns to Serial Mode Patterns

Designs with serialized compressed scan can have both a serial scan mode, where the
codec is connected to deserializer and serializer registers for I/O-limited operation, and a
parallel scan mode, where the codec is connected directly to top-level scan I/O ports. If the
same codec is used in both modes, you can create parallel mode scan patterns in TetraMAX
ATPG first, then translate them to serial mode scan patterns. This eliminates the need for a
second pattern generation run.
To ensure that the same codec is used in both modes, you must use the -parallel_mode
option of the set_serialize_configuration command to tie the parallel mode to the
serial mode:
-base_mode my_base_mode \ # standard scan base mode
-test_mode my_serial_mode \ # serial compressed scan mode
-xtolerance ... \
-chain_count ... \
-inputs ... \
-outputs ... \
-serialize ...
-test_mode my_serial_mode \ # serial compressed scan mode
-parallel_mode my_parallel_mode \ # parallel compressed scan mode
-inputs ... \
-outputs ...
Note:
The terms serial and parallel in this section refer to the type of scan compression being
used, not to serial or parallel scan data loading in TetraMAX testbenches.
Performing Pattern Translation for Matching Scan Data Pipeline Depths

Use this pattern translation flow if you are not using pipelined scan data, or if you are using
pipelined scan data and the parallel mode has the same pipeline depth as the serial mode.
Note:
When you use the tool to perform automatic pipeline register insertion, it ensures that all
test modes have the same pipeline depth.


1. Run TetraMAX ATPG in parallel scan mode.
2. Execute the run_drc command using the parallel mode SPF:
run_drc my_parallel_mode.spf
In the log file, you will see information reported during compressor rules checking:
Begin compressor rules checking...
Warning: Rule R11 (X on chain affects observe ability of other chains)
was violated 1008 times.
Compressor rules checking completed: #chains=200, #scanins=8,
#scanouts=8, #shifts=100, CPU time=0.13 sec.
Note the #shifts= value, which represents the number of shift cycles used in the parallel
mode.
3. Perform ATPG in the parallel mode.
4. Write out the parallel mode pattern set with the -format binary and
-compressor_based options:
write_patterns compressor_based.db \
-format binary -replace -compressor_based
When you write out the pattern set with the -compressor_based option, the pattern set
can be only read back into a serial scan mode TetraMAX run.
5. Run TetraMAX ATPG in serial scan mode.
6. Set the number of shift cycles to the #shifts= value obtained from the compressor rules
checking log file entry from the parallel mode run:
set_drc -dftmax_shift_cycles 100
7. Execute the run_drc command using the serial mode SPF:

run_drc my_serial_mode.spf
add_nofaults ...
add_faults ...
8. Read the previously saved patterns into the TetraMAX tool:

set_patterns -external compressor_based.db
9. Optionally, execute the run_simulation command, the run_fault_sim command, or

an incremental ATPG step:
run_simulation
run_fault_sim

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
10.Write out the translated serial mode pattern set:

write_patterns translated_serial.stil -format stil -external
It is expected that you might see a small amount of coverage difference between the original
parallel mode ATPG results and the run_fault_sim result using the translated serial mode
patterns. This difference can be caused by different lock-up latch configurations, different
scan chain MUXing, different primary input constraints, and other minor scan configuration
differences.
You should use options for the set_build and set_drc commands that are as similar as
possible between the parallel mode and the serial mode runs.
Performing Pattern Translation Across Different Scan Data Pipeline Depths

Use this pattern translation flow if you are manually inserting pipelined scan data registers
and the parallel mode has a different pipeline depth from the serial mode.
2. Execute the run_drc command using the parallel mode SPF:
run_drc my_parallel_mode.spf
In the log file, you will see information reported during compressor rules checking:
Note the #shifts= value, which represents the number of shift cycles used in the parallel
mode.
3. Run TetraMAX ATPG in serial scan mode.
4. Execute the run_drc command using the serial mode SPF:
run_drc my_serial_mode.spf
Obtain the resulting #shifts= value from the serial mode:


5. Take the larger #shifts= value from the two test modes. In this example, the larger value
is 202.
7. Set the number of shift cycles to the larger #shifts= value obtained from the parallel
and serial modes:
set_drc -dftmax_shift_cycles 202
8. Follow the steps in “Performing Pattern Translation for Matching Scan Data Pipeline
Depths, starting with the parallel mode ATPG performed in step 3. In the serial mode in
step 6, use the larger #shifts= value determined from the two test modes.
Translating Serial Mode Patterns to Standard Scan Mode Patterns

To convert serial mode scan patterns to standard scan mode format, use the translation flow
provided in “Translating Compressed Scan Patterns to Standard Scan Mode Patterns” on
page 2-47. This translation flow applies to both normal compressed scan patterns as well as
serialized scan patterns.
Known Issues
The known issues for serializer designs in a TetraMAX flow are described in the following
sections:
• C1 Violations
• Serializer Core-Level Flow With Pipelined Scan Data Insertion
C1 Violations
A C1 violation might occur in parallel mode or regular scan mode when you use Synopsys
automated pipeline scan data in which the clock is shared with the ATE clock of a
DFT-inserted OCC controller. The violation is related to gate-level optimization and causes
the clock-off state to be X on a lock-up-latch clock pin that has been inserted after the
pipeline head registers. The violation can be reduced to a warning if the situation is the same
as described earlier. You cannot expect to be able to downgrade all C1 violations.
Serializer Core-Level Flow With Pipelined Scan Data Insertion

Serialized compressed scan core creation with implemented pipeline stages could produce
R rule violations in TetraMAX design rule checking. One workaround is to implement the
pipeline stage only at the top level in a HASS or Hybrid flow.

DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Adaptive Scan With Serializer Limitations

The following functionalities are not supported:
• Multiple serial mode implementation
• Parallel mode support in top-down partition with concatenated serializer chain flow,
HASS with concatenated serializer chain flow, and Hybrid flows
• DFT connectivity associations using the set_dft_connect or set_dft_signal
-connect_to commands
• Pipeline scan data registers whose clock is shared with scan cells’ clock
The tool inserts the serializer clock controller on the clock lines to provide internally
generated clocks to the compressed scan chains. If it is inserted on the clock line feeding
the pipelined scan data registers, the pipeline registers do not work properly.
• Pattern translation from serial to parallel
• Launch-on-shift (LOS) transition ATPG
• Internally generated scan-enable signals
• LSSD, scan-enabled LSSD, and clocked scan styles
• Lock-up flip-flops
• Retiming flip-flops
• Terminal lock-up latches
When enabled, terminal lock-up latches are inserted at the end of the compressed scan
chains (before the serializer compressor) instead of at the scan output ports. This might
result in scan structures that do not shift into the compressor correctly.
• Mix of -xtolerance high and -xtolerance default codecs in top-down partition,
HASS, and Hybrid flows
• Any case with core wrapping in which a dedicated wrapper clock is created when the
insert_dft command is run
The dedicated wrapper clock is not gated by the serializer clock controller
• tmax2pt (TetraMAX to PrimeTime utility)

Adaptive Scan With Serializer Limitations 6-90
Out-of-Scope Serializer Functionality

The following serializer functionalities are out of the current scope:
• Serialized standard scan mode
• Serialized asymmetrical I/O codec compression
• Serialized core with standard scan chains
This is supported only when all scan chains are compressed by the serializer codec
• Legacy Verilog testbench
DFTMAX Compression Error Messages

The following TEST error messages involve the serializer feature.
TEST-1093
Size of the deserializer and serializer are not equal.
TEST-1094
The number of deserializer inputs and serializer outputs are not equal.
TEST-1095
Scan compression mode chains that are outside the codec are not supported in the
serializer flow.
TEST-1096
The head and tail pipeline flip-flops are not triggered by the same clock in the serializer flow.
TEST-1097
Pipeline clock is not dedicated to pipeline flip-flops in serializer flow.

Out-of-Scope Serializer Functionality 6-91
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4

DFTMAX Compression Error Messages 6-92
A
Example Scripts A
This appendix contains the following example scripts for determining the area of
compressors and for performing equivalence checking.
This appendix includes the following sections:
• Example Tcl Procedure to Determine the Area of Compressors
• Example Formality Script for Equivalence Checking
A-1
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Example Tcl Procedure to Determine the Area of Compressors

You can use the following script to determine the nand2 equivalent area of compressors. You
need to pass both the name of nand2 library cell and the top design name as arguments to
the procedure.
In running the script you first source the proc.tcl file and then call the procedure, that is,
source proc.tcl
compressor_area fast/nand2 top
where the file proc.tcl contains the following procedure:

proc compressor_area {nand_gate top_design_name} {
set last_design [current_design]
set nand_area [get_attribute $nand_gate area]
current_design ${top_design_name}_SCCOMP_COMPRESSOR
report_area > SnPSteMPfILe
set comp_area [sh grep 'Total cell area' SnPSteMPfILe]
set comp_area_num [lindex $comp_area 3]
set compr_gates [expr $comp_area_num/$nand_area]
current_design ${top_design_name}_SCCOMP_DECOMPRESSOR
report_area > SnPSteMPfILe
set decomp_area [sh grep 'Total cell area' SnPSteMPfILe]
sh rm SnPSteMPfILe
set decomp_area_num [lindex $decomp_area 3]
set decompr_gates [expr $decomp_area_num/$nand_area]
echo ""
echo "Area of NAND2 gate : $nand_area"
echo "Area of decompressor : $decomp_area_num"
echo "Area of compressor : $comp_area_num"
echo ""
echo "Decompressor gate count : $decompr_gates"
echo "Compressor gate count : $compr_gates"
set total_gates [expr $decompr_gates + $compr_gates]
echo "Total compression logic gate count : $total_gates"
current_design $last_design
}
Appendix A: Example Scripts

Example Tcl Procedure to Determine the Area of Compressors A-2
Example Formality Script for Equivalence Checking

set synopsys_auto_setup true
set_svf default.svf
foreach file $link_library {

read_db $file
}
create_container pre_dft
current_container pre_dft
read_ddc ./outputs/des_unit.pre_dft.ddc
set_top des_unit
set_reference_design pre_dft:/WORK/des_unit
create_container post_dft
current_container post_dft
read_ddc ./outputs/des_unit.post_dft_with_compression.ddc
set_top des_unit
set_implementation_design post_dft:/WORK/des_unit
match
verify
AppendixA:A:Example
Chapter ExampleScripts
Scripts
Example Formality Script for Equivalence Checking A-3
DFTMAX™
Compression User
User Guide
Guide H-2013.03-SP4
Appendix A: Example Scripts

Example Formality Script for Equivalence Checking A-4

DFTXG 2

Uploaded by

Copyright:

Available Formats

DFTXG 2

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

DFTXG 2

Uploaded by

Copyright:

Available Formats

What is the purpose of the document?

What is the purpose of the document?

What information is contained in Appendix A?

What information is contained in Appendix A?

DFTMAX™

DFTMAX™ Compression User Guide, version H-2013.03-SP4 ii

Copyright Notice for the Line-Editing Library

DFTMAX™ Compression User Guide, version H-2013.03-SP4 iii

About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv

2. Using Adaptive Scan Technology

Supported DFT Configuration Commands for Partitions . . . . . . . . . . . . . . . . . . 2-12

Estimating Compression Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-42

3. Hierarchical Adaptive Scan Synthesis

4. Managing X Values in Scan Compression

The X-Chain Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8

5. Advanced Adaptive Scan Techniques

Determining the Fully Shared I/O Configuration . . . . . . . . . . . . . . . . . . . . . . . . 5-26

6. Adaptive Scan With Serializer

Deserializer/Serializer Update Stage Register Clocks. . . . . . . . . . . . . . . . . . . . 6-13

Wide Duty Cycle Support for Serializer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-54

Appendix A. Example Scripts

About This Guide

Courier Indicates syntax, such as write_file.

Courier italic Indicates a user-defined value in syntax, such as

Courier bold Indicates user input—text you type verbatim—in

[] Denotes optional arguments in syntax, such as

... Indicates that arguments can be repeated as many

| Indicates a choice among alternatives, such as

Ctrl+C Indicates a keyboard combination, such as holding

\ Indicates a continuation of a command line.

/ Indicates levels of directory structure.

Edit > Copy Indicates a path to a menu command, such as

Contacting the Synopsys Technical Support Center

Introduction to the DFTMAX Tool

The Adaptive Scan Architecture

Figure 1-1 shows the adaptive scan architecture.

VHO>@ GLQ>@ GLQ>@ GLQ>@

GRXW>@ GRXW>@ GRXW>@ GRXW>@ GRXW>@ GRXW>@ GRXW>@ GRXW>@

Figure 1-3 Compressor Logic Structure Example for 8-to-4 Compressor

GRXW>@ GRXW>@ GRXW>@ GRXW>@

Adaptive Scan Requirements

Limitations Associated With Adaptive Scan Technology

Limitations Associated With Hierarchical Adaptive Scan Synthesis

Top-Down Flat Compressed Scan Flow

set_dft_configuration -scan_compression enable

set_dft_signal -view existing_dft -type ScanClock \

set_scan_configuration -chain_count 3 -clock_mixing mix_clocks

change_names -rules verilog -hierarchy

write -format verilog -hierarchy -output design.v

write_test_protocol -output scan.spf \

Chapter 2: Using Adaptive Scan Technology

• Standard scan mode

Chapter 2: Using Adaptive Scan Technology

You can use the following set_scan_compression_configuration options to control the

Scan chain '1' (test_si1 --> test_so1) contains 22 cells

Chapter 2: Using Adaptive Scan Technology

Scan chain '2' (test_si2 --> test_so2) contains 21 cells

Scan chain '3' (test_si3 --> test_so3) contains 21 cells

Scan chain '1' contains 8 cells

VHO>@ GLQ>@ GLQ>@ GLQ>@

GRXW>@ GRXW>@ GRXW>@ GRXW>@ GRXW>@ GRXW>@ GRXW>@ GRXW>@

GRXW>@ GRXW>@ GRXW>@ GRXW>@

WR WR WR WR

WR WR WR WR