SIEMENS EDA

Tessent™ Shell User’s

Manual
Software Version 2025.1
Document Revision 37
Unpublished work. © 2025 Siemens

This Documentation contains trade secrets or otherwise confidential information owned by Siemens Industry Software Inc. or
its affiliates (collectively, “Siemens”), or its licensors. Access to and use of this Documentation is strictly limited as set forth in
Customer’s applicable agreement(s) with Siemens. This Documentation may not be copied, distributed, or otherwise disclosed
by Customer without the express written permission of Siemens, and may not be used in any way not expressly authorized by
Siemens.

This Documentation is for information and instruction purposes. Siemens reserves the right to make changes in specifications
and other information contained in this Documentation without prior notice, and the reader should, in all cases, consult
Siemens to determine whether any changes have been made.

No representation or other affirmation of fact contained in this Documentation shall be deemed to be a warranty or give rise to
any liability of Siemens whatsoever.

If you have a signed license agreement with Siemens for the product with which this Documentation will be used, your use of
this Documentation is subject to the scope of license and the software protection and security provisions of that agreement. If
you do not have such a signed license agreement, your use is subject to the Siemens Universal Customer Agreement, which
may be viewed at https://www.sw.siemens.com/en-US/sw-terms/base/uca/, as supplemented by the product specific terms
which may be viewed at https://www.sw.siemens.com/en-US/sw-terms/supplements/.

SIEMENS MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS DOCUMENTATION INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND
NON-INFRINGEMENT OF INTELLECTUAL PROPERTY. SIEMENS SHALL NOT BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, CONSEQUENTIAL OR PUNITIVE DAMAGES, LOST DATA OR PROFITS, EVEN IF SUCH DAMAGES WERE
FORESEEABLE, ARISING OUT OF OR RELATED TO THIS DOCUMENTATION OR THE INFORMATION CONTAINED IN IT,
EVEN IF SIEMENS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

TRADEMARKS: The trademarks, logos, and service marks (collectively, "Marks") used herein are the property of Siemens
or other parties. No one is permitted to use these Marks without the prior written consent of Siemens or the owner of the
Marks, as applicable. The use herein of third party Marks is not an attempt to indicate Siemens as a source of a product, but
is intended to indicate a product from, or associated with, a particular third party. A list of Siemens' Marks may be viewed at:
www.plm.automation.siemens.com/global/en/legal/trademarks.html. The registered trademark Linux® is used pursuant to a
sublicense from LMI, the exclusive licensee of Linus Torvalds, owner of the mark on a world-wide basis.

About Siemens Digital Industries Software

Siemens Digital Industries Software is a global leader in the growing field of product lifecycle management (PLM),
manufacturing operations management (MOM), and electronic design automation (EDA) software, hardware,
and services. Siemens works with more than 100,000 customers, leading the digitalization of their planning and
manufacturing processes. At Siemens Digital Industries Software, we blur the boundaries between industry
domains by integrating the virtual and physical, hardware and software, design and manufacturing worlds.
With the rapid pace of innovation, digitalization is no longer tomorrow’s idea. We take what the future promises
tomorrow and make it real for our customers today. Where today meets tomorrow. Our culture encourages
creativity, welcomes fresh thinking and focuses on growth, so our people, our business, and our customers can
achieve their full potential.
Support Center: support.sw.siemens.com
Send Feedback on Documentation: support.sw.siemens.com/doc_feedback_form
 iii

Revision History ISO-26262

Revision Changes Status/Date

37 Modifications to improve the readability and comprehension of the Released

content. Approved by Lucille Woo.
Mar 2025
All technical enhancements, changes, and fixes listed in the Tessent
Release Notes for this product are reflected in this document. Approved
by Ron Press.

36 Modifications to improve the readability and comprehension of the Released

content. Approved by Lucille Woo.
Dec 2024
All technical enhancements, changes, and fixes listed in the Tessent
Release Notes for this product are reflected in this document. Approved
by Ron Press.

35 Modifications to improve the readability and comprehension of the Released

content. Approved by Lucille Woo.
Aug 2024
All technical enhancements, changes, and fixes listed in the Tessent
Release Notes for this product are reflected in this document. Approved
by Ron Press.

34 Modifications to improve the readability and comprehension of the Released

content. Approved by Lucille Woo.
Jun 2024
All technical enhancements, changes, and fixes listed in the Tessent
Release Notes for this product are reflected in this document. Approved
by Ron Press.

Author: In-house procedures and working practices require multiple authors for documents. All associated
authors for each topic within this document are tracked within the Siemens documentation source. For
specific topic authors, contact the Siemens Digital Industries Software documentation department.
Revision History: Released documents include a revision history of up to four revisions. For earlier
revision history, refer to earlier releases of documentation on Support Center.
Table of Contents

Chapter 1
Tessent Shell Introduction...........................................................................................27
What Is Tessent Shell?........................................................................................................................ 27
What Can You Do With Tessent Shell?...............................................................................................28
Tessent Shell Tcl Interface................................................................................................................... 29
Command Conventions.....................................................................................................................29
Command Completion...................................................................................................................... 30
Command History............................................................................................................................. 31
Escaped Hierarchical Names in Command Tcl Lists........................................................................32
Dofile Transcription........................................................................................................................... 32
Tcl Command Registration................................................................................................................33

Chapter 2
Tool Invocation, Contexts, Modes, and Data Models............................................... 35
Tool Invocation..................................................................................................................................... 35
Contexts and System Modes...............................................................................................................37
Contexts............................................................................................................................................ 37
System Modes.................................................................................................................................. 39
Context and System Mode Combinations........................................................................................ 39
Design Levels....................................................................................................................................40
Design Data Models.............................................................................................................................41
Flat Design Data Model.................................................................................................................... 41
Hierarchical Design Data Model....................................................................................................... 41
ICL Data Model.................................................................................................................................42
Object Attributes................................................................................................................................43

Chapter 3
Design Introspection and Editing............................................................................... 45
Design Introspection.............................................................................................................................46
Object Specification Format..............................................................................................................46
Collections......................................................................................................................................... 46
Design Introspection Examples........................................................................................................ 49
Design Introspection Command Summary....................................................................................... 53
Bundle Object Introspection..............................................................................................................56
Bundle Object................................................................................................................................ 56
Bundle Object Data Model............................................................................................................ 61
Introspection...................................................................................................................................63
Bundle Object Introspection Examples......................................................................................... 67
Fan-in and Fanout Tracing of Complex Signals and Bundle Object Tracing................................ 70
Connectivity Through Complex Signals........................................................................................ 73
Design Editing...................................................................................................................................... 77
Design Editing Command Summary................................................................................................ 78
Editing Complex Signals................................................................................................................... 80
Editing Complex Signals With the DftSpecification Wrapper........................................................ 80

4 Tessent™ Shell User’s Manual

Table of Contents
Editing Complex Verilog and SystemVerilog Signals With Tessent Shell Commands...................82
Examples Using the create_connections Command With Complex Signals............................. 83
Examples Using the delete_connections Command With Complex Signals............................. 96
Examples Using the move_connections Command With Complex Signals............................ 102
Examples Using the replace_instances Command With Complex Signals............................. 106
Design Editing Examples................................................................................................................ 109
Simulation Contexts........................................................................................................................... 114
Simulation Context Overview..........................................................................................................114
Introspection and Analysis Using Simulation Contexts.................................................................. 115
Automatic Design Mapping................................................................................................................ 118
ICL and TCD Post-Synthesis Update.............................................................................................118
Updating ICL Attributes From the Design...................................................................................... 119
Matching Rules for Port Names in Post-Synthesis Update............................................................120
Controlling the Name Mapping....................................................................................................... 120
ICL Objects Versus Design Objects Introspection.............................................................................122

Chapter 4
DFT Architecture Guidelines for Hierarchical Designs.......................................... 125
Hierarchical DFT Overview................................................................................................................ 126
Physical Layout Regions in Hierarchical Test................................................................................ 126
Pattern Retargeting......................................................................................................................... 126
Wrapped Cores and Wrapper Cells............................................................................................... 127
Internal Mode and External Mode.................................................................................................. 127
On-Chip Clock Controller................................................................................................................ 129
Graybox Model................................................................................................................................130
Top-Down Planning Before Bottom-Up Implementation.................................................................... 132
Clocking Architecture...................................................................................................................... 132
Resource Availability....................................................................................................................... 133
Test Scheduling...............................................................................................................................133
Specific Tasks That May Require Planning....................................................................................136
Sample DFT Planning Steps.......................................................................................................... 136
DFT Implementation Strategy............................................................................................................ 137

Chapter 5
RTL DFT Analysis and Insertion...............................................................................141
RTL DFT Analysis in the Overall Flow.............................................................................................. 141
RTL Design Rule Checks.................................................................................................................. 142
RTL IP Insertion................................................................................................................................. 143
RTL Design Assessment....................................................................................................................146
RTL Code Complexity Score.......................................................................................................... 146
RTL Test Point Insertion Suitability Score...................................................................................... 147
Detailed Metrics.............................................................................................................................. 148
Gate Node Location Types............................................................................................................. 150
Preparations for RTL DFT Analysis................................................................................................... 153
Test Point Analysis at RTL.................................................................................................................154
Test Point Insertion at RTL................................................................................................................ 155
Specifying RTL Test Points With Tessent Shell Commands............................................................. 156
Observation Scan Type of Test Point................................................................................................ 157

Tessent™ Shell User’s Manual 5

 Table of Contents
Test Point Implementations................................................................................................................ 161
Test Points as Function Calls............................................................................................................ 165
How to Preserve DFT Logic Inserted at RTL.................................................................................... 170
How to Report Logic Excluded From Test Point Analysis................................................................. 171
X-Bounding Analysis and Insertion at RTL........................................................................................174
Wrapper Analysis and Dedicated Wrapper Cell Insertion at RTL......................................................176
Smart Uniquification for RTL Pro.......................................................................................................178
Incremental Insertion.......................................................................................................................... 182
Limitations of RTL DFT Analysis and Insertion................................................................................. 187

Chapter 6
Tessent Shell Workflows........................................................................................... 189
Tessent Shell Flow for Flat Designs.................................................................................................. 190
Overview of the RTL and Scan DFT Insertion Flow...................................................................... 190
First DFT Insertion Pass: Performing MemoryBIST and Boundary Scan.......................................193
Second DFT Insertion Pass: EDT, Hybrid TK/LBIST, and OCC.....................................................198
Loading the Design......................................................................................................................199
Specifying and Verifying the DFT Requirements........................................................................ 201
Creating the DFT Specification................................................................................................... 204
Generating the EDT, Hybrid TK/LBIST, and OCC Hardware...................................................... 207
Extracting the ICL Module Description........................................................................................208
Generating ICL Patterns and Running Simulation...................................................................... 208
Performing Synthesis...................................................................................................................... 209
Performing Scan Chain Insertion (Flat Design)..............................................................................210
Performing ATPG Pattern Generation............................................................................................ 212
Simulating LBIST Faults................................................................................................................. 214
Considerations for Using Gate-Level Verilog Netlists.....................................................................216
Tessent Shell Flow for Hierarchical Designs..................................................................................... 217
Hierarchical DFT Terminology.........................................................................................................217
How the DFT Insertion Flow Applies to Hierarchical Designs........................................................219
RTL and Scan DFT Insertion Flow for Physical Blocks................................................................. 221
First DFT Insertion Pass: Performing Block-Level MemoryBIST................................................ 222
Second DFT Insertion Pass: Inserting Block-Level EDT and OCC.............................................224
Specifying and Verifying the DFT Requirements: DFT Signals for Wrapped Cores....................227
Performing Scan Chain Insertion: Wrapped Core.......................................................................229
Verifying the ICL Model............................................................................................................... 232
Performing ATPG Pattern Generation: Wrapped Core............................................................... 233
Running Recommended Validation Step for Pre-Layout Design Sign Off...................................238
RTL and Scan DFT Insertion Flow for the Top Chip......................................................................240
Top-Level DFT Insertion Example............................................................................................... 241
First DFT Insertion Pass: Performing Top-Level MemoryBIST and Boundary Scan................... 243
Second DFT Insertion Pass: Inserting Top-Level EDT and OCC............................................... 245
Top-Level Scan Chain Insertion Example................................................................................... 249
Top-Level ATPG Pattern Generation Example............................................................................250
Performing Top-Level ATPG Pattern Retargeting....................................................................... 251
RTL and Scan DFT Insertion Flow for Sub-Blocks........................................................................ 254
DFT Insertion Flow for the Sub-Block......................................................................................... 254
DFT Insertion Flow for the Next Parent Level............................................................................ 255

6 Tessent™ Shell User’s Manual

Table of Contents
RTL and Scan DFT Insertion Flow for Instrument Blocks..............................................................258
DFT Insertion Flow for the Instrument Block.............................................................................. 258
Instrument Block DFT Insertion Flow for the Next Parent Level................................................. 260
RTL and DFT Insertion Flow With Third-Party Scan......................................................................263
DFT Insertion Flow With Third-Party Scan Insertion...................................................................263
Wrapped Core DFT Insertion With Third-Party Scan..................................................................265
Perform Two-Pass DFT Insertion and Synthesis for Wrapped Cores......................................266
Third-Party Scan Insertion for Wrapped Cores........................................................................267
Writing the Design Back to the TSDB..................................................................................... 270
Make Pre-ATPG Connections With Third-Party Scan for Wrapped Cores...............................273
Performing Wrapped Core Graybox Generation and ATPG Pattern Generation..................... 276
Top Chip DFT Insertion With Third-Party Scan...........................................................................280
Perform Two-Pass Insertion and Synthesis for Top Chip........................................................ 280
Third-Party Scan Insertion for Top Chip...................................................................................281
Make Pre-ATPG Connections With Third-Party Scan for Top Chip......................................... 283
Perform Top-Chip ATPG Pattern Generation and Wrapped-Core Pattern Retargeting............285
Tessent Shell Flow for RTL Test Point and Wrapper Insertion.......................................................... 288
Additions to the Second DFT Insertion Pass ................................................................................ 288
DFT Insertion Pass for RTL Test Points.........................................................................................292
Performing Scan Chain Insertion With Incremental Test Point and Wrapper Cell Insertion............295
Tessent Shell Flow for Tiled Designs................................................................................................ 298
Tiling DFT Terminology................................................................................................................... 299
How the DFT Insertion Flow Applies to Tiled Designs...................................................................299
Clocking During Logic Test............................................................................................................. 303
Pre-DFT Design Modification and Integration................................................................................ 306
Chip-Level Port Requirements and Connections........................................................................ 306
Tile-Level Port Connections and Requirements..........................................................................306
Creation of IJTAG Graybox............................................................................................................ 310
Example Flow for a Tiled Design................................................................................................... 310
Tiling Flow Used in Example.......................................................................................................... 311
DFT Flow for Tiles Without TAP and BISR Controllers.................................................................. 313
Embedded Boundary Scan Insertion in Tiles Without a TAP Controller......................................313
IJTAG Network Insertion in Tiles Without a TAP Controller........................................................ 316
Memory Test Insertion in Tiles Without TAP and BISR Controllers.............................................320
SSN and EDT Insertion in Tiles Without TAP and BISR Controllers...........................................322
Scan Insertion and Scan Modes in Tiles Without TAP and BISR Controllers............................. 325
Patterns Generation in Tiles Without a TAP Controller............................................................... 326
Verification and Simulations........................................................................................................ 328
Embedded Boundary Scan Insertion in Tiles With a TAP Controller..............................................329
IJTAG Network Insertion in Tiles With a TAP Controller................................................................ 334
Memory BISR Insertion for Tiles With a BISR Controller............................................................... 335
SSN Insertion for Tiles With Primary SSN Ports............................................................................338
Scan Insertion and Scan Modes for Tiles With Promoted OCCs...................................................340
Chip-Level Integration for the Tiling Flow.......................................................................................342
BSDL File Extraction................................................................................................................... 342
IJTAG-Based Verification Patterns.............................................................................................. 343
Tile-Level Patterns Retargeting................................................................................................... 343
Tile-to-Tile Test at the Package Level......................................................................................... 350
Tessent Shell Post-Layout Validation Flow........................................................................................ 352

Tessent™ Shell User’s Manual 7

 Table of Contents
Overview of the Post-Layout Validation Flow................................................................................. 352
Soft Link TSDB and Post-Layout Netlist........................................................................................ 353
Verify MemoryBIST, Boundary Scan, and IJTAG Patterns.............................................................354
Verifying the Scan-Inserted ATPG Patterns................................................................................... 355
Post-Layout Validation When You Have Ungrouped IJTAG/OCC/EDT Logic.................................357
Testbench Generation and Simulation in RTL Mode......................................................................... 362
Simulation Wrapper Creation..........................................................................................................362
Testbench Examples....................................................................................................................... 365
Hybrid TK/LBIST Flow for Flat Designs.............................................................................................369
RTL and Scan DFT Insertion Flow With Hybrid TK/LBIST............................................................ 369
Perform the First DFT Insertion Pass: Hybrid TK/LBIST................................................................370
Perform the Second DFT Insertion Pass: Hybrid TK/LBIST.......................................................... 373
Perform Test Point Insertion........................................................................................................... 379
Perform Scan Chain Insertion (Hybrid Flow)..................................................................................381
Performing ATPG Pattern Generation: Hybrid TK/LBIST............................................................... 383
Performing LogicBIST Fault Simulation..........................................................................................386
Perform LogicBIST Pattern Generation.......................................................................................... 388
Running Multiple Load ATPG on Wrapped Core Memories With Built-In Self Repair....................... 391
Overview of Multiple Load ATPG on Memories for Wrapped Cores With Built-in Self Repair........ 391
Performing Multiple Load ATPG Pattern Generation..................................................................... 391
Performing Multiple Load Top-Level ATPG Pattern Retargeting.................................................... 394
Built-In Self Repair in Hierarchical Tessent MemoryBIST Flow.........................................................398
Performing Block-Level BISR Insertion.......................................................................................... 398
Performing Chip-Level BISR Insertion............................................................................................401
Functional Repair Clock.............................................................................................................. 401
Connection of the BISR Controller to Existing BISR Chains...................................................... 401
Connection of the BISR Controller to an External Fuse Box...................................................... 402
Connection of the BISR Controller to System Logic................................................................... 403
Verification of Block- and Chip-Level BISR.................................................................................... 403

Chapter 7
Tessent Shell Automotive Workflow ....................................................................... 405
Introduction to Tessent Automotive....................................................................................................405
Test Case Overview and Objective....................................................................................................407
Core-Level DFT Insertion for Automotive.......................................................................................... 411
DFT Insertion Flow for the Processor Core Physical Block........................................................... 412
First DFT Insertion Pass: processor_core...................................................................................413
Second DFT Insertion Pass: processor_core............................................................................. 416
Test Point, X-Bounding, and Scan Insertion: processor_core.....................................................420
ATPG Pattern Generation: processor_core.................................................................................424
LogicBIST Fault Simulation: processor_core.............................................................................. 426
LogicBIST Pattern Generation: processor_core..........................................................................428
Interconnect Bridge/Open UDFM Generation: processor_core...................................................430
Cell-Neighborhood UDFM Generation: processor_core..............................................................432
Automotive-Grade ATPG Pattern Generation: processor_core...................................................435
Automotive-Grade Topoff ATPG Pattern Generation............................................................... 435
Automotive-Grade ATPG Pattern Generation Using Only UDFMs.......................................... 439
DFT Insertion Flow for the GPS Baseband Physical Block........................................................... 442

8 Tessent™ Shell User’s Manual

Table of Contents
DFT Insertion Pass With In-System Test: gps_baseband...........................................................443
LogicBIST Fault Simulation With One NCP: gps_baseband.......................................................447
Interconnect Bridge/Open UDFM Generation: gps_baseband....................................................448
Cell-Neighborhood UDFM Generation: gps_baseband...............................................................448
Automotive-Grade ATPG Pattern Generation: gps_baseband....................................................448
Top-Level DFT Insertion for the Automotive Flow............................................................................. 449
First DFT Insertion Pass: Top With MemoryBIST, BISR, and Boundary Scan............................... 449
Second DFT Insertion Pass: Top With EDT, OCC, and In-System Test.........................................454
Scan Insertion for the Top Design..................................................................................................460
ATPG Pattern Generation for the Top Design................................................................................ 462
ATPG Pattern Retargeting for the Top Design............................................................................... 463
Interconnect Bridge/Open UDFM Generation for the Top Design.................................................. 463
Cell-Neighborhood UDFM Generation for the Top Design............................................................. 463
Automotive-Grade ATPG Pattern Generation for the Top Design.................................................. 464
UDFM Generation for Cell-Aware ATPG........................................................................................ 464
TCA Based Pattern Sorting............................................................................................................ 466
Functional Mode Fault Tolerance for Static IJTAG Signals............................................................... 469

Chapter 8
TSDB Data Flow for the Tessent Shell Flow............................................................473
Core-Level or Flat TSDB Data Flow..................................................................................................473
Top-Level TSDB Data Flow............................................................................................................... 477

Chapter 9
Streaming Scan Network (SSN)................................................................................ 483
Tessent SSN Workflows ................................................................................................................... 484
Block-Level SSN Insertion and Verification.................................................................................... 486
First DFT Insertion Pass: Performing Block-Level MemoryBIST................................................ 488
Second DFT Insertion Pass: Inserting Block-Level EDT, OCC, and SSN...................................488
Synthesis for Block-Level Insertion............................................................................................. 494
Creating the Post-Synthesis TSDB View (Block-Level).............................................................. 495
Performing Scan Chain Insertion With Tessent Scan (Block-Level)........................................... 496
Verifying the ICL-Based Patterns After Synthesis (Block-Level)................................................. 499
Generating Block-Level ATPG Patterns...................................................................................... 501
Top-Level SSN Insertion and Verification....................................................................................... 507
First DFT Insertion Pass: Performing Top-Level MemoryBIST................................................... 509
Second DFT Insertion Pass: Inserting Top-Level EDT, OCC, and SSN......................................511
Synthesis for Top-Level Insertion................................................................................................ 519
Creating the Post-Synthesis TSDB View (Top-Level)................................................................. 519
Performing Scan Chain Insertion With Tessent Scan (Top-Level).............................................. 520
Verifying the ICL-Based Patterns After Synthesis (Top-Level)....................................................520
Generating Top-Level ATPG Patterns......................................................................................... 521
Retargeting ATPG Patterns ........................................................................................................522
Performing Reverse Failure Mapping for SSN Pattern Diagnosis.............................................. 525
Rule Checks Before Writing SSN and ATPG Patterns......................................................................530
The Incremental Extraction Process...............................................................................................531
Feedthrough Path Handling............................................................................................................ 533
Limitations for Incremental Extraction............................................................................................ 533

Tessent™ Shell User’s Manual 9

 Table of Contents
Advanced Topics ............................................................................................................................... 535
Streaming-Through-IJTAG Scan Data............................................................................................ 535
On-Chip Compare With SSN..........................................................................................................537
Types of Clock Networks To Use With SSN.................................................................................. 545
Broadcast to Identical SSN Datapaths........................................................................................... 548
Determine Failing Cores on ATE With SSN................................................................................... 549
Yield Statistics on ATE With SSN.................................................................................................. 551
Manufacturing Patterns With SSN..................................................................................................557
Manufacturing Pattern Quick Reference..................................................................................... 558
SSN Pattern Structure................................................................................................................. 559
How to Write Complete SSN Patterns........................................................................................ 560
How to Write JTAG and Payload Procedures Separately........................................................... 561
How to Write SSN On-Chip Compare Patterns.......................................................................... 565
How To Write Streaming-Through-IJTAG Patterns......................................................................567
SSN Debug on the Tester........................................................................................................... 569
Signoff Patterns With SSN............................................................................................................. 576
Block-Level Signoff Patterns........................................................................................................577
Top-Level Signoff Patterns...........................................................................................................580
Signoff Pattern Quick Reference.................................................................................................583
Troubleshooting Miscompares of X Values in Signoff Patterns...................................................584
SSN SDC Constraints in the Design Flow..................................................................................... 585
Overview of SSN-Related SDC Procs and Constraints.............................................................. 586
Changes to SDC Procs for SSN Timing.................................................................................. 587
SSN/SDC Proc Usage..............................................................................................................589
SSN/SSH SDC Constraint Descriptions...................................................................................... 594
SSN Bus Clock and SSN Bus Port Timing Constraints...........................................................594
SSN Bus Data Port Delays...................................................................................................... 594
SSN Datapath Timing Constraints........................................................................................... 596
SSN FIFO Timing Constraints..................................................................................................599
SSN ScanHost Timing Constraints and Clock Tree Synthesis................................................ 602
Fast IO............................................................................................................................................ 617
Design Requirements.................................................................................................................. 617
SSN Fast IO Functionality........................................................................................................... 619
Single Data Rate Clocking....................................................................................................... 619
Double Data Rate Clocking......................................................................................................620
Modeling a Double Data Rate Interface......................................................................................622
ICL Modeling.............................................................................................................................622
Verilog Modeling....................................................................................................................... 626
Adaptive Tuning on the ATE....................................................................................................... 628
ATE Calibration.........................................................................................................................629
ATE Input Delay Tuning........................................................................................................... 629
Output Strobe Tuning............................................................................................................... 629
SSN Fast IO Bandwidth Improvement........................................................................................ 630
Fast IO Pattern Generation......................................................................................................... 631
SSN Fast IO Limitations.............................................................................................................. 631
Burn-In Pattern Support.................................................................................................................. 633
Burn-In Pattern Overview............................................................................................................ 633
Recommended Flows for Creating Burn-In Patterns.................................................................. 635
Creating Burn-In Patterns With the Retargeting Flow..............................................................635

10 Tessent™ Shell User’s Manual

Table of Contents
Creating Burn-In Patterns With the Flat ATPG Flow............................................................... 636
Burn-In Functionality Limitations................................................................................................. 637
LVX Support.................................................................................................................................... 638
LVX Hardware Requirements...................................................................................................... 638
Creating EDT With LVX Hardware.............................................................................................. 639
LVX Operation Modes With LVX Hardware Configuration.......................................................... 643
Configuring LVX Patterns............................................................................................................ 644
Writing LVX Loop Patterns.......................................................................................................... 654
Writing LVX Verification Patterns.................................................................................................655
LVI_PATCHING_INFO..................................................................................................................656
Retention Testing With SSN........................................................................................................... 659
Size Resolution Technology With SSN...........................................................................................661
Sample Area Reduction With Size Resolution............................................................................662
Size Resolution Limitations......................................................................................................... 664
Tessent SSN Examples and Solutions.............................................................................................. 667
Third-Party OCCs With SSN.......................................................................................................... 667
Defining Multiple Physical ICL Datapaths for a Single Datapath Port............................................668
SSN Frequently Asked Questions .................................................................................................... 674
SSN Limitations.................................................................................................................................. 676

Chapter 10
Tessent Examples and Solutions............................................................................. 679
How to Handle Parameterized Blocks During DFT Insertion............................................................ 680
Problem........................................................................................................................................... 680
Solution............................................................................................................................................682
Creation of Parameterization Wrappers and Initial TSDBs for Typical Designs.......................... 684
Block Uniquification and Creation of Parameterization Wrappers and Initial TSDBs for Complex
Designs........................................................................................................................................ 685
Modifications to the First DFT Insertion Pass for Blocks............................................................ 687
Modifications to the Second DFT Insertion Pass for Blocks....................................................... 688
Synthesis for Physical Blocks......................................................................................................689
Creation of the Gate-Level TSDB for a Physical Block.............................................................. 689
Scan Insertion for Physical Blocks.............................................................................................. 690
Modifications to the First DFT Insertion Pass for Chips..............................................................691
Modifications to the Second DFT Insertion Pass for Chips........................................................ 691
Synthesis for the Chip Level....................................................................................................... 692
Discussion....................................................................................................................................... 693
Typical Scenario Without Uniquification...................................................................................... 694
Creation of the Parameterization Wrappers and Initial TSDBs................................................694
Synthesis for Physical Blocks Example................................................................................... 696
Synthesis for the Chip Level Example..................................................................................... 697
Creation of the Gate-Level TSDB for a Physical Block (Optional)...........................................698
Scan Insertion for a Physical Block......................................................................................... 698
Complex Scenario With Uniquification........................................................................................ 700
Block Uniquification and Creation of Parameterization Wrappers and Initial TSDBs............... 700
How to Avoid Simulation Issues When Using the Two-Pin Serial Port Controller............................. 702
How to Handle Clocks Sourced by Embedded PLLs During Logic Test........................................... 704
How to Design Capture Windows for Hybrid TK/LBIST.................................................................... 710

Tessent™ Shell User’s Manual 11

 Table of Contents
How to Use Boundary Scan in a Wrapped Core...............................................................................712
How to Use an Older Core TSDB With Newly-Inserted DFT Cores..................................................714
TAP Configuration.............................................................................................................................. 716
Insert a Stand-Alone TAP in a Design........................................................................................... 716
Insert a TAP With an IJTAG Host Scan Interface.......................................................................... 718
Insert a Compliance Enable TAP With an IJTAG Interface............................................................ 719
Insert a Daisy‑Chained TAP............................................................................................................ 720
Insert a Primary TAP...................................................................................................................... 722
Insert a Secondary TAP..................................................................................................................723
Connecting to a Third-Party TAP....................................................................................................725
How to Create a WSP Controller in Tessent Shell............................................................................ 726
How to Set Up Third-Party Synthesis................................................................................................733
How to Set Up Support for Third-Party OCCs.................................................................................. 735
How to Configure Files for Third-Party OCCs................................................................................735
Test Logic Insertion.........................................................................................................................736
Configuration for Scan Insertion..................................................................................................... 737
Pattern Generation and Simulation................................................................................................ 738
Post-Synthesis Update....................................................................................................................... 741
Limitations Related to SystemVerilog Interface Arrays.................................................................. 741
Matching Requirements for Port Names in Post-Synthesis Update...............................................741
Design Name Mapping Commands................................................................................................743
Design Name Mapping................................................................................................................ 743
Default Matching Rules for the get_pins, get_ports, and get_instances -match_rtl_reg
Commands................................................................................................................................... 743

Chapter 11
Test Procedure File.................................................................................................... 745
Test Procedure File Creation............................................................................................................. 745
Test Procedure File Syntax................................................................................................................745
Test Procedure File Structure............................................................................................................ 749
#include Statement......................................................................................................................... 749
Set Statement................................................................................................................................. 749
Alias Definition................................................................................................................................ 752
Timing Variables..............................................................................................................................754
Timeplate Definition.........................................................................................................................757
Multiple-Pulse Clocks......................................................................................................................763
The pulse_clock Statement......................................................................................................... 763
Inferred Timing............................................................................................................................. 764
Differences Between Default add_clock and 1x Multiplier Clock................................................ 764
Always Block................................................................................................................................... 765
Procedure Definition........................................................................................................................766
Test Procedures................................................................................................................................. 777
Test_Setup (Optional)..................................................................................................................... 778
Shift (Required)............................................................................................................................... 780
Alternate Shift Procedure (Optional)...............................................................................................782
Load_Unload (Required).................................................................................................................784
Shadow_Control (Optional).............................................................................................................786
Master_Observe (Sometimes Required)........................................................................................ 788

12 Tessent™ Shell User’s Manual

Table of Contents
Shadow_Observe (Optional)...........................................................................................................789
Skew_Load (Optional).....................................................................................................................790
Clock_Control (Optional).................................................................................................................791
clock_run (Optional)........................................................................................................................ 801
Capture Procedures (Optional)....................................................................................................... 802
Rules for Creating and Editing a Default Capture Procedure..................................................... 802
Rules for Creating and Editing Named Capture Procedures...................................................... 803
Slow and Load Types in the Cycle Statement............................................................................ 805
launch_capture_pair Statement................................................................................................... 806
Clock_sequential (Optional)............................................................................................................ 807
Init_force (Optional).........................................................................................................................808
Test_end (Optional, all ATPG tools)............................................................................................... 809
Sub_procedure................................................................................................................................ 810
Additional Support for Test Procedure Files...................................................................................... 812
Creating Test Procedure Files for End Measure Mode..................................................................... 813
Serial Register Load and Unload for LogicBIST and ATPG.............................................................. 816
Register Load and Unload Use Models......................................................................................... 816
Static Versus Dynamic Register Variables..................................................................................... 816
Test Procedure File Modifications...................................................................................................817
Dofile Modifications......................................................................................................................... 819
Serial Load and Unload DRC Rules.............................................................................................. 822
P13 and P54................................................................................................................................822
P66............................................................................................................................................... 822
W5................................................................................................................................................ 823
Procedure Examples....................................................................................................................824
Notes About Using the stil2tessent Tool............................................................................................827
Extraction of Strobe Timing Information From STIL (SPF).............................................................827
The STIL ClockStructures Block.....................................................................................................827
Test Procedure File Commands and Output Formats....................................................................... 827

Chapter 12
Tessent Visualizer.......................................................................................................831
Invoking Tessent Visualizer................................................................................................................832
Invoke Explicitly on the Same Machine..........................................................................................832
Invoke Explicitly on a Different Machine........................................................................................ 833
Invoke Implicitly...............................................................................................................................834
License-Protected Tabs...................................................................................................................835
Framework Overview......................................................................................................................... 836
Tessent Visualizer Components and Preferences............................................................................. 838
Tables.............................................................................................................................................. 839
Table Toolbar Features................................................................................................................ 839
Columns and Filters Editor.......................................................................................................... 841
Table Filters..................................................................................................................................842
Data Sorting................................................................................................................................. 845
Row Highlighting.......................................................................................................................... 846
Schematics...................................................................................................................................... 847
Toolbar..........................................................................................................................................848
Schematic Symbols..................................................................................................................... 851

Tessent™ Shell User’s Manual 13

 Table of Contents
Object Types in Schematics.....................................................................................................851
Markers..................................................................................................................................... 857
Buffer and Inverter Collapsing..................................................................................................859
Folding and Unfolding Instances..............................................................................................861
Context Tables............................................................................................................................. 862
Signal Net Tracing Strategies......................................................................................................871
Context Menu Tracing................................................................................................................. 874
Displayed Property.......................................................................................................................874
Tessent Shell Attributes............................................................................................................... 874
Mouse Gestures...........................................................................................................................876
Tessent Visualizer Preferences.......................................................................................................876
Macros.............................................................................................................................................879
Tooltips............................................................................................................................................ 880
Saving and Restoring the Session State........................................................................................882
Window Title Prefixes..................................................................................................................... 882
Tessent Visualizer GUI Reference..................................................................................................... 884
Hierarchical Schematic................................................................................................................... 884
Flat Schematic................................................................................................................................ 891
ICL Schematic.................................................................................................................................892
Instance Browser............................................................................................................................ 897
ICL Instance Browser..................................................................................................................... 899
Cell Library Browser....................................................................................................................... 900
DRC Browser.................................................................................................................................. 901
Config Data Browser.......................................................................................................................904
RTL Metrics Browser...................................................................................................................... 908
RTL Metrics Browser Toolbar...................................................................................................... 908
Context Menu Actions................................................................................................................. 909
Transcript.........................................................................................................................................910
Wave Viewer................................................................................................................................... 912
Wave Viewer Toolbar...................................................................................................................913
Context Menu Actions................................................................................................................. 914
Text/HDL Viewer............................................................................................................................. 914
IJTAG Network Viewer....................................................................................................................915
iProc Viewer.................................................................................................................................... 919
Diagnosis Report Viewer................................................................................................................ 920
Search Features................................................................................................................................. 922
Using Tessent Visualizer to Debug Design Issues............................................................................ 927
Accessing Tutorials for Tessent Visualizer........................................................................................ 929
Accessing Videos for Tessent Visualizer........................................................................................... 930
Keyboard Shortcuts............................................................................................................................ 931

Chapter 13
Timing Constraints (SDC)..........................................................................................935
Generating and Using SDC for Tessent Shell Embedded Test IP.....................................................935
SDC File Generation With Tessent Shell...........................................................................................935
SDC Design Synthesis With Tessent Shell....................................................................................... 938
Preparation Step 1: Sourcing SDC File..........................................................................................938
Preparation Step 2: Setting and Redefining Tessent Tcl Variables................................................ 938

14 Tessent™ Shell User’s Manual

Table of Contents
Preparation Step 3: Verifying the Declaration of Functional Clocks............................................... 940
Preparation Step 4: Redefining Other Tessent Tcl Variables......................................................... 941
Synthesis Step 1: Applying the SDC Constraints...........................................................................941
Synthesis Step 2: Preparing the DFT Logic for Synthesis............................................................. 941
Synthesis Step 3: Synthesizing Your Design................................................................................. 942
Synthesis Step 4: Writing Out Your Final SDC.............................................................................. 942
Synthesis Step 5: Writing Out Your Final Netlist............................................................................ 943
Running Layout With Tessent Shell DFT...........................................................................................943
SDC for Modal Static Timing Analysis...............................................................................................947
Checking Your Functional Logic Alone...........................................................................................947
Checking Your Embedded Test Logic............................................................................................ 948
VHDL and Mixed Language Designs................................................................................................ 950
VHDL Generate Blocks...................................................................................................................950
SDC File Contents............................................................................................................................. 951
tessent_set_default_variables......................................................................................................... 951
tessent_create_functional_clocks....................................................................................................952
tessent_<design_name>_set_dft_signals....................................................................................... 952
<ltest_prefix>_disable......................................................................................................................952
tessent_set_non_modal.................................................................................................................. 953
tessent_<design_name>_kill_functional_paths...............................................................................954
IJTAG Instrument............................................................................................................................ 955
LOGICTEST Instruments................................................................................................................ 956
MemoryBIST Instrument................................................................................................................. 969
BoundaryScan Instrument...............................................................................................................972
Hierarchical STA in Tessent............................................................................................................972
Mapping Procs................................................................................................................................ 977
Synthesis Helper Procs.................................................................................................................. 978
Example Scripts Using Tessent Tool-Generated SDC.......................................................................979

Appendix A
The Tessent Tcl Interface ......................................................................................... 981
General Tcl Guidelines in Tessent Shell............................................................................................ 981
Encoding Tcl Scripts in Tessent Shell................................................................................................983
Guidelines for Modifying Existing Dofiles for Use With Tcl................................................................983
Special Tcl Characters....................................................................................................................... 985
Custom Tcl Packages in Tessent Shell..............................................................................................987
Tcl Resources.....................................................................................................................................987

Appendix B
Synthesis Guidelines for RTL Designs With Tessent Inserted DFT...................... 989
DFT Insertion With Tessent............................................................................................................... 989
Synthesis Guidelines.......................................................................................................................... 991
SystemVerilog and Port Name Matching........................................................................................... 993
Synthesis Guidelines for Parameterization Wrapper Flows...............................................................994
Tcl Procedures for Synthesis in the Parameterization Wrapper Flow............................................ 995

Tessent™ Shell User’s Manual 15

 Table of Contents

Appendix C
Clocking Architecture Examples.............................................................................. 997
Clocks Driven by Primary Inputs....................................................................................................... 997
Clock Generators Outside the Cores.................................................................................................997
Clock Generators Inside the Cores................................................................................................... 998
Clock Sourced From a Core With Embedded PLL............................................................................998
Clock Mesh Synthesis........................................................................................................................999

Appendix D
Formal Verification................................................................................................... 1001
Golden RTL Versus DFT‑Inserted RTL............................................................................................ 1001
Pre-Layout Versus Post-Layout....................................................................................................... 1002
Embedded Boundary Scan at the Physical Block Level..................................................................1002

Appendix E
Solutions for Genus Synthesis Issues...................................................................1005

Appendix F
Getting Help.............................................................................................................. 1007
The Tessent Documentation System............................................................................................... 1007
Global Customer Support and Success.......................................................................................... 1007

Third-Party Information

16 Tessent™ Shell User’s Manual

 List of Figures

Figure 1. Hierarchical Design Example.................................................................................................. 42

Figure 2. Hierarchical Design Example With Colors...............................................................................50
Figure 3. Complex Signals With Tessent Visualizer............................................................................... 75
Figure 4. Original Design Before Creating Connections.........................................................................84
Figure 5. Modified Design After Creating Connections.......................................................................... 85
Figure 6. Schematic of the Example Design Before Editing...................................................................98
Figure 7. Schematic of the Example Design After Editing......................................................................99
Figure 8. Original Design Before Moving Connections.........................................................................104
Figure 9. Modified Design After Moving Connections.......................................................................... 105
Figure 10. Hierarchical Design Example.............................................................................................. 109
Figure 11. Inverter Inception................................................................................................................. 111
Figure 12. Tessent Visualizer Flat Schematic (gate level)....................................................................116
Figure 13. Wrapped Cores....................................................................................................................127
Figure 14. Internal Mode.......................................................................................................................128
Figure 15. External Mode......................................................................................................................129
Figure 16. On-Chip Clock Controller.....................................................................................................130
Figure 17. Graybox Model.................................................................................................................... 131
Figure 18. Compression Analysis Example.......................................................................................... 134
Figure 19. RTL DFT Analysis in the Overall Insertion Flow................................................................. 142
Figure 20. Example Hierarchical Design.............................................................................................. 148
Figure 21. Example Design...................................................................................................................151
Figure 22. Schematic of an OST Module (use_rtl_cells : off)...............................................................158
Figure 23. Partial Schematic of an OST for an Expression..................................................................160
Figure 24. Example Gate Logic With Two Control Points.................................................................... 169
Figure 25. Two-Pass Insertion Flow for RTL, Flat Designs.................................................................. 191
Figure 26. DFT-Ready Design.............................................................................................................. 192
Figure 27. After the First DFT Insertion Pass.......................................................................................192
Figure 28. After the Second DFT Insertion Pass..................................................................................193
Figure 29. Dofile Example for MemoryBIST and BoundaryScan..........................................................195
Figure 30. Flow for the Second DFT Insertion Pass............................................................................ 198
Figure 31. Flow for Loading the Design............................................................................................... 199
Figure 32. Flow for Specifying and Verifying the DFT Requirements...................................................201
Figure 33. Flow for Creating the DFT Specification............................................................................. 204
Figure 34. Flow for Inserting the Second-Pass Hardware....................................................................207
Figure 35. Flow for Extracting ICL........................................................................................................ 208
Figure 36. Flow for Generating and Simulating ICL Patterns............................................................... 209
Figure 37. Two-Pass Insertion Flow for RTL, Gate-Level Designs.......................................................216
Figure 38. Hierarchical Design Levels.................................................................................................. 218
Figure 39. Two-Pass Insertion Flow, Physical Blocks.......................................................................... 221
Figure 40. Dofile Example for MemoryBIST in Physical Blocks........................................................... 223
Figure 41. Dofile for Second DFT Pass .............................................................................................. 225
Figure 42. Flow for Specifying and Verifying the DFT Requirements for Wrapped Cores.................... 227
Figure 43. Scan Chain Insertion in Hierarchical Flow.......................................................................... 231
Figure 44. ATPG Pattern Generation Flow for Wrapped Cores........................................................... 234
Figure 45. Graybox Example................................................................................................................ 236

Tessent™ Shell User’s Manual 17

 List of Figures
Figure 46. ATPG External Mode...........................................................................................................236
Figure 47. ATPG Internal Mode............................................................................................................ 237
Figure 48. Two-Pass Insertion Flow for RTL, Top Level.......................................................................240
Figure 49. Top-Level Example, Before DFT Insertion.......................................................................... 241
Figure 50. Top-Level Example, After DFT Insertion for Wrapped Cores.............................................. 242
Figure 51. Top-Level Example, After DFT Insertion at the Top Level................................................... 242
Figure 52. Top-Level Second DFT Pass...............................................................................................246
Figure 53. Top-Level Scan Chain Insertion.......................................................................................... 249
Figure 54. Top-Level ATPG Pattern Generation................................................................................... 250
Figure 55. Retarget Stuck-At ATPG Patterns for the Top-Level........................................................... 252
Figure 56. Retarget At-Speed Transition ATPG Patterns for the Top-Level......................................... 253
Figure 57. Two-Pass Insertion Flow for RTL, Wrapped Cores, and Third-Party Scan..........................265
Figure 58. DFT Signals and Multiplexer Logic Support Hierarchical ATPG..........................................267
Figure 59. At-Speed Flows in the Wrapper Chain................................................................................270
Figure 60. Current Level Path to Child Core Wrapper Chains............................................................. 274
Figure 61. Two-Pass Insertion Flow for RTL, Top Level, and Third-Party Scan................................... 280
Figure 62. Top Level EDT Connection to Child Cores......................................................................... 283
Figure 63. Example of Preparing for RTL Test Point Insertion............................................................. 289
Figure 64. Example of RTL Test Point Insertion...................................................................................293
Figure 65. Example of Scan Insertion With Incremental Test Point and Wrapper Cell Insertion...........296
Figure 66. Schematic of Tiling Example............................................................................................... 299
Figure 67. Schematic of Boundary Scan Logic.................................................................................... 300
Figure 68. Schematic of IJTAG Network.............................................................................................. 301
Figure 69. Schematic of Memory BISR Network.................................................................................. 302
Figure 70. Schematic of SSN Network................................................................................................. 302
Figure 71. Clocking in Internal Test Mode............................................................................................ 303
Figure 72. Clocking in External Mode...................................................................................................304
Figure 73. Forward and Backward Propagation of Data Between Tiles............................................... 304
Figure 74. Simplified Waveform of Forward Propagation, Negedge to Posedge..................................305
Figure 75. Simplified Waveform of Return Posedge to Posedge Propagation..................................... 305
Figure 76. Schematic of IJTAG Network in C2 Tile and IJTAG Ports Created on C2_i1 Instance With Their
Input Connections..................................................................................................................................310
Figure 77. Schematic of a Sample Test Case...................................................................................... 311
Figure 78. Tiling Flow Used in Example Test Case..............................................................................312
Figure 79. Schematic of Boundary Scan Logic in Example Test Case.................................................314
Figure 80. Schematic of Boundary Scan Logic Inside C1.................................................................... 315
Figure 81. Schematic of Embedded Boundary Scan Logic in C2 Without Pads.................................. 316
Figure 82. Schematic of IJTAG Network After Memory BIST Insertion in C1.......................................317
Figure 83. Schematic of IJTAG Network After Memory BIST and Logic Test insertion in Tile.............. 318
Figure 84. Schematic of C2 Tile With Additional Host Scan Interfaces................................................ 319
Figure 85. Schematic of MemoryBISR Inside the C2 Tile.................................................................... 321
Figure 86. Schematic of SSN Network Inserted in the C1 Tile.............................................................323
Figure 87. Schematic of C2 Tile With SSN Network Inserted.............................................................. 325
Figure 88. Embedded Boundary Scan Segment With Logic Test Support Ready for Integration......... 330
Figure 89. Schematic After Boundary Scan Insertion in the C3 Tile.................................................... 333
Figure 90. Schematic of IJTAG Network Inserted in C3 Tile................................................................ 335
Figure 91. Schematic of Memory BISR Network Inserted in C3 Tile....................................................337
Figure 92. Schematic of SSN Network in the C3 Tile.......................................................................... 340

18 Tessent™ Shell User’s Manual

List of Figures
Figure 93. Schematic of the SSN Network Configured for Retargeting of Internal Stuck Patterns for All
Tiles........................................................................................................................................................345
Figure 94. Schematic of SSN network Configured for Retargeting of Internal Transition Patterns for Single
C1_i2 Tile...............................................................................................................................................346
Figure 95. Post-Layout Validation Flow................................................................................................ 352
Figure 96. Post-Layout Validation Flow With Ungrouped IJTAG/OCC/EDT Logic................................ 358
Figure 97. Two-Pass Insertion Flow With Hybrid TK/LBIST................................................................. 370
Figure 98. Dofile Example for First Pass, Hybrid TK/LBIST With MemoryBIST................................... 371
Figure 99. Dofile Example for First DFT Pass, Hybrid TK/LBIST Only.................................................373
Figure 100. Dofile Example for Test Point Insertion............................................................................. 381
Figure 101. Dofile Example for Scan Chain Insertion: Hybrid TK/LBIST..............................................382
Figure 102. Dofile Example for ATPG With Controller Chain Mode: Hybrid TK/LBIST.........................384
Figure 103. Dofile Example for LogicBIST Fault Simulation.................................................................387
Figure 104. Two-Pass Insertion Flow for RTL, Wrapped Cores........................................................... 392
Figure 105. Multiple Load ATPG Pattern Generation for Memories With BISR....................................393
Figure 106. Two-Pass Insertion Flow for RTL, Top Level.....................................................................395
Figure 107. ATPG Pattern Retargeting for Memories With BISR......................................................... 396
Figure 108. Integrated Tessent DFT Solution for Automotive...............................................................406
Figure 109. Initial Design for Automotive Test Case............................................................................ 408
Figure 110. DFT Integration at the Core Level for Automotive.............................................................409
Figure 111. DFT Integration at the Top Level for Automotive............................................................... 409
Figure 112. DFT Insertion Flow for Automotive Test Case................................................................... 410
Figure 113. DFT Insertion Flow for processor_core............................................................................. 412
Figure 114. Dofile Example for First DFT Insertion Pass, processor_core........................................... 414
Figure 115. Enhanced Clocking and DFT Controls After Second DFT Insertion Pass......................... 417
Figure 116. Dofile Example for Second DFT Insertion Pass, processor_core......................................417
Figure 117. Dofile Example for Test Point and Scan Insertion, processor_core................................... 422
Figure 118. ATPG Pattern Generation Flow for processor_core.......................................................... 425
Figure 119. Dofile Example for LogicBIST Fault Simulation, processor_core...................................... 427
Figure 120. Dofile Example for LogicBIST Pattern Generation, processor_core..................................428
Figure 121. Interconnect Bridge/Open UDFM Generation Flow for processor_core............................ 430
Figure 122. Dofile Example for Interconnect Bridge/Open UDFM Generation, processor_core........... 431
Figure 123. Cell-Neighborhood UDFM Generation Flow for processor_core....................................... 433
Figure 124. Dofile Example for Extracting Cell-Neighborhood Pairs, processor_core..........................434
Figure 125. ATPG Topoff Run Flow With a UDFM for processor_core................................................ 437
Figure 126. Dofile Example for Running Topoff ATPG With a UDFM in Internal Mode for
processor_core...................................................................................................................................... 438
Figure 127. ATPG Run Flow With All UDFM for processor_core......................................................... 440
Figure 128. Dofile Example for Running ATPG With Only UDFMs in Internal Mode for
processor_core...................................................................................................................................... 440
Figure 129. DFT Insertion Flow for gps_baseband.............................................................................. 442
Figure 130. Dofile Example for DFT Insertion, gps_baseband.............................................................444
Figure 131. Dofile Example for LogicBIST Fault Simulation With One NCP........................................ 447
Figure 132. Dofile Example for Top-Level First DFT Insertion Pass, Automotive Flow.........................452
Figure 133. Dofile Example for Top-Level Second DFT Insertion Pass, Automotive Flow....................456
Figure 134. Dofile Example for Top-Level Scan Chain Insertion, Automotive Flow..............................461
Figure 135. Cell-Aware UDFM Generation Flow.................................................................................. 465
Figure 136. TCA Based Pattern Sorting Flow...................................................................................... 467

Tessent™ Shell User’s Manual 19

 List of Figures
Figure 137. Dofile Example for Running ATPG With All Types of UDFM in Internal Mode for
gps_baseband....................................................................................................................................... 467
Figure 138. Hardware Fault Tolerant Module Example........................................................................ 470
Figure 139. HFT Module in the Single-Pass Flow................................................................................471
Figure 140. HFT Modules in the Two-Pass Flow................................................................................. 471
Figure 141. Tessent Shell Task Flow.................................................................................................... 474
Figure 142. TSDB File Structure, Core Level, First Insertion Pass...................................................... 475
Figure 143. TSDB File Structure, Core Level, Second Insertion Pass................................................. 476
Figure 144. TSDB File Structure, Core Level, Synthesis and Scan Insertion.......................................477
Figure 145. TSDB File Structure, Core Level, Pattern Generation.......................................................477
Figure 146. TSDB Data Flow, Top Level, First Insertion Pass............................................................. 479
Figure 147. TSDB Data Flow, Top Level, Second Insertion Pass........................................................ 480
Figure 148. TSDB Data Flow, Top Level, Scan Insertion..................................................................... 480
Figure 149. TSDB Data Flow, Top Level, ATPG Pattern Generation................................................... 481
Figure 150. TSDB Data Flow, Top Level, ATPG Pattern Generation With Pattern Retargeting............ 482
Figure 151. Directory Structure of Reference Testcase........................................................................485
Figure 152. SSN Block-Level Workflow................................................................................................ 487
Figure 153. SSN Top-Level Workflow................................................................................................... 508
Figure 154. Multiplexer Node for Bypassing the gps_baseband Blocks...............................................515
Figure 155. Simplified Tessent Diagnosis Two-Step Flow.................................................................... 525
Figure 156. Streaming-Through-IJTAG Mode....................................................................................... 536
Figure 157. Faults in Comparator Logic That Could Mask Real Faults................................................541
Figure 158. SSN Datapath in Tiling Architecture.................................................................................. 547
Figure 159. Stepping Down the Clock Tree on the Last Pipeline Stage...............................................548
Figure 160. Example sticky_status Bit Annotation................................................................................549
Figure 161. Example Core Instance Annotations................................................................................. 549
Figure 162. SSN Packet Rotation Cycles.............................................................................................550
Figure 163. Pin Tables With Modulus and Core Instance Relationships.............................................. 550
Figure 164. Determine Failing Core Instance With Modulus and Pin Tables........................................551
Figure 165. Example Modulus and Pin Table Annotations ..................................................................551
Figure 166. Annotation Where the Cycle Rotation Begins................................................................... 551
Figure 167. Packet Rotation on the SSN Bus...................................................................................... 553
Figure 168. Annotations for SSN Mapping With Packet Rotation Disabled..........................................554
Figure 169. Annotations for SSN Mapping With Packet Rotation and Throttling Disabled................... 555
Figure 170. Writing the Simplest Complete SSN Scan Pattern............................................................559
Figure 171. SSN Pattern Structure....................................................................................................... 560
Figure 172. SSN Patterns in a Single STIL File...................................................................................561
Figure 173. SSN Patterns With Separate test_setup and ssn_setup................................................... 562
Figure 174. SSN Pattern Files With Order for Application on Tester....................................................564
Figure 175. SSN Pattern Files With Combined Single test_setup and ssn_setup................................564
Figure 176. SSN Pattern Files With Combined Setup Showing Tester Order...................................... 565
Figure 177. Writing Each Procedure of the SSN Pattern to Individual Files.........................................565
Figure 178. SSN Pattern Files With On-Chip Compare Self-Test........................................................ 567
Figure 179. Writing Streaming-Through-IJTAG Patterns...................................................................... 568
Figure 180. Tester Application Order for Streaming-Through-IJTAG.................................................... 569
Figure 181. Order To Apply Patterns for SSN Pattern Failure Debugging........................................... 570
Figure 182. Writing ICLNetwork Verify Patterns in STIL Format.......................................................... 570
Figure 183. Order To Apply ICLNetwork Verify Patterns to the Tester................................................. 571
Figure 184. Writing SSN Continuity Patterns in STIL Format...............................................................571

20 Tessent™ Shell User’s Manual

List of Figures
Figure 185. Order To Apply SSN Continuity Patterns to the Tester......................................................572
Figure 186. Writing SSH On-Chip Compare Self-Test Patterns........................................................... 572
Figure 187. Order To Apply SSN On-Chip Compare Self-Test Patterns...............................................573
Figure 188. Writing SSH Loopback Patterns in STIL Format............................................................... 573
Figure 189. Order To Apply SSH Loopback Patterns...........................................................................574
Figure 190. Writing SSH Loopback, Chain, and Scan Patterns to Individual Files...............................574
Figure 191. Order To Apply SSH Loopback, Chain, and Scan Patterns.............................................. 575
Figure 192. FIFO MCP Example.......................................................................................................... 601
Figure 193. SSH Clock Signal Generation........................................................................................... 603
Figure 194. SSH Clock Group Constraints........................................................................................... 604
Figure 195. SSH scan_en and edt_update Generation Circuit............................................................ 605
Figure 196. scan_en Margin Definition Diagram.................................................................................. 605
Figure 197. Gated Scan Clocks With All *extra_cycle* Variables Set to 1 (Default).............................606
Figure 198. Gated Scan Clocks With All *extra_cycle* Variables Set to 0........................................... 606
Figure 199. Divided Shift Clocks With Ratio of 4 and *extra_cycle* Variables at 0.............................. 607
Figure 200. Divided Shift Clocks With Ratio of 4 and *extra_cycle* Variables at 1.............................. 607
Figure 201. SSH Scan Chain Interface Circuit..................................................................................... 607
Figure 202. Recommended SSH CTS Stop Points.............................................................................. 614
Figure 203. Example SSN Fast IO Bus With SDR Clocking................................................................ 619
Figure 204. Example SSN Fast IO Bus With SDR Clocking and Alternate External Interface Access to
the SSN................................................................................................................................................. 620
Figure 205. Example SSN Fast IO Bus With DDR Clocking................................................................ 620
Figure 206. Example SSN Fast IO Bus With DDR Clocking and Alternate External Interface Access to
the SSN................................................................................................................................................. 621
Figure 207. Sample DDR Interface Schematic.....................................................................................623
Figure 208. Proper Tuning of Input Data and the Output Strobe......................................................... 628
Figure 209. Tessent LVX TDRs............................................................................................................ 639
Figure 210. LVX Hardware With enable_one_chain for Channel Input................................................ 640
Figure 211. LVX Hardware Without enable_one_chain for Channel Input............................................641
Figure 212. Propagation of LVX Scan Outputs With enable_one_chain Hardware for Channel Output. 642
Figure 213. Propagation of the LVX Scan Output Without enable_one_chain Hardware for Channel
Output.................................................................................................................................................... 642
Figure 214. Size Resolution Area Savings With On-Chip Compare.....................................................663
Figure 215. Size Resolution Area Savings Without On-Chip Compare................................................664
Figure 216. ScanHost With One chain_group...................................................................................... 665
Figure 217. ScanHost With Multiple chain_groups...............................................................................666
Figure 218. Localized Scan Timing With Shift-Only Mode OCC.......................................................... 668
Figure 219. Core Preparation for Multiple Datapaths to a Single Port................................................. 669
Figure 220. Example Tile Configuration for Multiple Datapath Setup................................................... 673
Figure 221. Hierarchical DFT Insertion Flow With Parameterization Wrappers....................................683
Figure 222. Example Chip With Parameterized Physical Blocks..........................................................694
Figure 223. Script for Creation of Parameterization Wrappers and Initial TSDBs................................ 695
Figure 224. Script for Synthesis of a Physical Block............................................................................696
Figure 225. Script for Synthesis of the Top Block................................................................................ 697
Figure 226. Example Chip - Post Synthesis.........................................................................................698
Figure 227. Script for Creation of the Gate-Level TSDB for a Physical Block......................................698
Figure 228. Chip With Parameterized Physical Blocks........................................................................ 700
Figure 229. Specifying the Uniquification Requirements in the Configuration Specification................. 700
Figure 230. Example Chip (Post-Uniquification)................................................................................... 701

Tessent™ Shell User’s Manual 21

 List of Figures
Figure 231. TRST Pulse Generator inside TPSP................................................................................. 704
Figure 232. Example Chip With PLL Embedded Inside Lower Core....................................................706
Figure 233. Active OCCs During Internal Test Modes of corec and coreb........................................... 707
Figure 234. Active OCCs During Internal Test Modes of corea and coreb...........................................708
Figure 235. Active OCCs During Test Modes of Top Level.................................................................. 709
Figure 236. Wrapped Core Boundary Scan Flow.................................................................................713
Figure 237. tdr_length ≥ log2(number of registers)...............................................................................727
Figure 238. IEEE 1687 IJTAG Network Model of the IEEE 1500 WSP Interface................................. 730
Figure 239. 200ns Timing Waveform.................................................................................................... 764
Figure 240. Shift Procedure.................................................................................................................. 781
Figure 241. Timing Diagram for Shift Procedure.................................................................................. 782
Figure 242. Load_Unload Procedure.................................................................................................... 784
Figure 243. Timing Diagram for Load_Unload Procedure.................................................................... 786
Figure 244. Shadow_Control Procedure...............................................................................................787
Figure 245. Master_Observe Procedure...............................................................................................788
Figure 246. Shadow_Observe Procedure.............................................................................................789
Figure 247. Skew_Load Procedure.......................................................................................................790
Figure 248. Skew_load applied within Pattern......................................................................................790
Figure 249. Full Clock Sequential Pattern............................................................................................ 808
Figure 250. Init_force Procedure Usage............................................................................................... 809
Figure 251. Tessent Visualizer Split View.............................................................................................837
Figure 252. Moving a Tab to the Left or Right Pane............................................................................ 837
Figure 253. Common Table Toolbar Features...................................................................................... 839
Figure 254. Columns and Filters Editor................................................................................................ 841
Figure 255. Sticky Column....................................................................................................................844
Figure 256. Sticky Indicator in Column Header.................................................................................... 844
Figure 257. Selection Colors.................................................................................................................846
Figure 258. Schematic With Overview Pane and Attributes Table....................................................... 848
Figure 259. Schematic Elements.......................................................................................................... 849
Figure 260. Hierarchical Schematic Showing Pins, Ports, Instances, and Nets................................... 851
Figure 261. Hierarchical Instance With Callout and Pin Data.............................................................. 852
Figure 262. Showing the Internal Connectivity of a Hierarchical Instance............................................853
Figure 263. Hierarchical Instance With DRC Callout............................................................................853
Figure 264. Hierarchical Cell.................................................................................................................854
Figure 265. Hierarchical Instance Representing an Assign Statement.................................................854
Figure 266. Black-Boxed Instance Example......................................................................................... 855
Figure 267. Objects in the Flat Schematic Tab.................................................................................... 855
Figure 268. Persistent Buffer Symbol................................................................................................... 856
Figure 269. Bus Index Displayed at Rip Point......................................................................................856
Figure 270. Collapsed Buffers and Inverters With No Hidden Fanout..................................................859
Figure 271. Expanded Buffers and Inverters With No Hidden Fanout................................................. 860
Figure 272. Collapsed Buffers/Inverters With Hidden Fanout...............................................................860
Figure 273. Expanded Buffers/Inverters With Hidden Fanout.............................................................. 860
Figure 274. Expanded Buffers/Inverters With Fanout Revealed...........................................................861
Figure 275. Unfolding an Instance........................................................................................................861
Figure 276. Folded Cell Group............................................................................................................. 862
Figure 277. Unfolded Cell Group.......................................................................................................... 862
Figure 278. Schematic Elements: Context Table..................................................................................863
Figure 279. Tracer Context Table......................................................................................................... 864

22 Tessent™ Shell User’s Manual

List of Figures
Figure 280. Context Table for Instance Pins (Hierarchical Schematic).................................................865
Figure 281. Context Table for Instances (Hierarchical Schematic).......................................................866
Figure 282. Context Table for Nets (Hierarchical Schematic)...............................................................867
Figure 283. Fanout Replaced by User-Added Primary Input................................................................867
Figure 284. Flat Sink.............................................................................................................................868
Figure 285. Fanout Replaced by Multiple User-Added Primary Inputs.................................................868
Figure 286. Multiple Flat Sinks............................................................................................................. 869
Figure 287. Context Table for Multiple Flat Sinks.................................................................................869
Figure 288. User-Added Primary Inputs............................................................................................... 870
Figure 289. Netlist Driver and Context Table for User-Added Primary Inputs...................................... 871
Figure 290. User-Added Primary Inputs (Flat Schematic).................................................................... 871
Figure 291. Decision Point Strategy on Hierarchy Boundary at q[6] Port.............................................872
Figure 292. Choosing a Path From the Tracing Table..........................................................................872
Figure 293. Decision Point Strategy..................................................................................................... 873
Figure 294. Tessent Shell Attributes Table........................................................................................... 875
Figure 295. Mouse Gestures in Tessent Visualizer Schematics...........................................................876
Figure 296. Light, Dark, and High-Contrast Color Themes.................................................................. 877
Figure 297. Preferences Dialog Box (Text viewers Tab).......................................................................878
Figure 298. Preferences Dialog Box (Shortcuts Tab)........................................................................... 879
Figure 299. Macro Editor...................................................................................................................... 880
Figure 300. Running a Macro............................................................................................................... 880
Figure 301. Tooltip for a Collapsed Buffer Indicator............................................................................. 881
Figure 302. Tooltip for a Filter Box....................................................................................................... 881
Figure 303. Tooltip for an Action Button............................................................................................... 881
Figure 304. Setting a Window Title Prefix............................................................................................ 882
Figure 305. Visualizer Window Label....................................................................................................883
Figure 306. Hierarchical Schematic Tab............................................................................................... 885
Figure 307. Hierarchical Instances With Pins Shown and Hidden....................................................... 886
Figure 308. Hierarchical Schematic Symbols....................................................................................... 887
Figure 309. Bus Tracing in the Hierarchical Schematic........................................................................888
Figure 310. Bus Sub-Ranges................................................................................................................889
Figure 311. Showing All Bus Pins in the Hierarchical Schematic......................................................... 889
Figure 312. Loopback Connection........................................................................................................ 890
Figure 313. Example of a Tied-Value Marker With Associated Pin Table.............................................890
Figure 314. Flat Schematic (Cell Grouping On)................................................................................... 891
Figure 315. Alias in the ICL Schematic................................................................................................ 892
Figure 316. Automatically Determined Values...................................................................................... 893
Figure 317. Mux With Select Values Displayed....................................................................................893
Figure 318. Pins Driven or Active as Needed...................................................................................... 894
Figure 319. Implicitly Connected Pins.................................................................................................. 895
Figure 320. Displaying the Definition of an ICL Instance..................................................................... 896
Figure 321. Traced and Highlighted Scan Path....................................................................................896
Figure 322. Instance Browser Elements............................................................................................... 898
Figure 323. Cell Grouping in Hierarchical Instance Browser................................................................898
Figure 324. Debugging in the Instance Browser.................................................................................. 899
Figure 325. Cell Library Browser.......................................................................................................... 901
Figure 326. DRC Browser With Data Grouped By Rule.......................................................................902
Figure 327. Flat Schematic Showing a DRC Violation......................................................................... 903
Figure 328. Config Data Browser......................................................................................................... 904

Tessent™ Shell User’s Manual 23

 List of Figures
Figure 329. Wrapper Editing in the Context Menu............................................................................... 905
Figure 330. List of Configuration Snapshots........................................................................................ 907
Figure 331. RTL Metrics Browser......................................................................................................... 908
Figure 332. Transcript Tab With an Interactive Command Line........................................................... 911
Figure 333. Wave Viewer......................................................................................................................912
Figure 334. Text/HDL Viewer................................................................................................................ 915
Figure 335. IJTAG Network Viewer.......................................................................................................916
Figure 336. Mux Select Values and Active Input..................................................................................917
Figure 337. Simulation Values in IJTAG Network Viewer..................................................................... 917
Figure 338. Highlighting SIBs in the IJTAG Network Viewer................................................................ 918
Figure 339. iProc Viewer.......................................................................................................................919
Figure 340. iProc Viewer Tooltip........................................................................................................... 919
Figure 341. Diagnosis Report Viewer (Text View)................................................................................ 921
Figure 342. Diagnosis Report Viewer (Table View).............................................................................. 922
Figure 343. Search Tab: Instances....................................................................................................... 923
Figure 344. Search Tab: Pins............................................................................................................... 923
Figure 345. Search Tab: Gate Pins...................................................................................................... 924
Figure 346. ICL Instances Search........................................................................................................ 924
Figure 347. iProc Search...................................................................................................................... 925
Figure 348. Config Data Search........................................................................................................... 926
Figure 349. RTL Metrics Search...........................................................................................................926
Figure 350. Searching by Name........................................................................................................... 929
Figure 351. Locations for Exclude Points for OCC CTS...................................................................... 944
Figure 352. tessent_test_clock and tessent_shift_capture_clock Creation.......................................... 959
Figure 353. Generated Clock Muxed Multi-Clock Memories................................................................ 971
Figure 354. Problem Occurrence Creating the Gate Level Netlist....................................................... 989
Figure 355. OCCs for Clocks Driven by Primary Inputs....................................................................... 997
Figure 356. OCCs With Clock Generators at Chip Level, Asynchronous Clocks................................. 998
Figure 357. OCCs With Clock Generators Inside the Cores, Asynchronous Clocks............................ 998
Figure 358. Clock Sourced From a Core With Embedded PLL, With MUX..........................................999
Figure 359. Clock Sourced From a Core With Embedded PLL, Without MUX.....................................999
Figure 360. Clock Mesh Synthesis..................................................................................................... 1000

24 Tessent™ Shell User’s Manual

 List of Tables

Table 1. Tessent Shell Command Conventions...................................................................................... 29

Table 2. Commands for Tcl Command Registration............................................................................... 33
Table 3. Application-Specific Environment Variables.............................................................................. 35
Table 4. Tessent Shell Contexts..............................................................................................................37
Table 5. Tessent Shell System Modes....................................................................................................39
Table 6. Tessent Shell Context and System Mode Commands..............................................................40
Table 7. Commands That Interact With Collections................................................................................48
Table 8. Design Introspection Commands.............................................................................................. 53
Table 9. Attribute Introspection Commands............................................................................................ 54
Table 10. base_class and base_type SystemVerilog Examples.............................................................62
Table 11. Complex Signals Design Introspection Commands................................................................ 66
Table 12. Design Editing Commands......................................................................................................77
Table 13. Design Editing Command Summary....................................................................................... 78
Table 14. Commands for Editing Complex Ports, Pins, and Nets.......................................................... 82
Table 15. Test Schedule Example.........................................................................................................135
Table 16. Tessent IP Configuration and Insertion Instructions..............................................................144
Table 17. RTL Code Complexity Score................................................................................................ 146
Table 18. RTL Test Point Insertion Suitability Score.............................................................................147
Table 19. Gate Node Location Mapping............................................................................................... 151
Table 20. Test Pattern Bit Name Assignments..................................................................................... 365
Table 21. Core-Level TSDB Data Flow Inputs and Outputs................................................................. 474
Table 22. Top-Level TSDB Data Flow Inputs and Outputs................................................................... 478
Table 23. SSN Manufacturing Pattern Summary.................................................................................. 557
Table 24. Manufacturing Pattern Quick Reference............................................................................... 558
Table 25. Block-Level Verification Pattern Summary............................................................................ 580
Table 26. Top-Level Verification Pattern Summary............................................................................... 582
Table 27. Signoff Pattern Quick Reference...........................................................................................583
Table 28. set_load_unload_timing_options Arguments and SDC Variables......................................... 603
Table 29. SSN Bandwidth Comparison for I/O Port/Frequency Combinations..................................... 631
Table 30. LVX Modes With enable_one_chain Hardware Configuration.............................................. 644
Table 31. Size Resolution Value Limitations Summary.........................................................................664
Table 32. Comparison of IEEE 1687 and IEEE 1500 Ports................................................................. 729
Table 33. Mux Select Signals and wsp_ir Value to Select Input 1........................................................730
Table 34. Reserved Punctuation Characters........................................................................................ 746
Table 35. Procedure File Tool Command Summary............................................................................. 828
Table 36. Common Table Toolbar Buttons............................................................................................840
Table 37. Filtering Summary................................................................................................................. 845
Table 38. Schematic Toolbar Actions....................................................................................................849
Table 39. Schematic Address Bar.........................................................................................................850
Table 40. Marker Symbols ................................................................................................................... 857
Table 41. Config Data Browser Buttons and Actions............................................................................906
Table 42. Toolbar for RTL Metrics Browser.......................................................................................... 908
Table 43. RTL Metrics Browser Context Menu..................................................................................... 910
Table 44. Wave Viewer Toolbar............................................................................................................ 913
Table 45. Wave Viewer Context Menu..................................................................................................914

Tessent™ Shell User’s Manual 25

 List of Tables
Table 46. Global Shortcuts....................................................................................................................931
Table 47. Schematic Shortcuts............................................................................................................. 932
Table 48. Config Browser Shortcuts..................................................................................................... 932
Table 49. Instance Browser Shortcuts.................................................................................................. 932
Table 50. Filter Editing Shortcuts.......................................................................................................... 933
Table 51. Text Search Shortcuts........................................................................................................... 933
Table 52. Wave Viewer Shortcuts......................................................................................................... 933
Table 53. Wave Viewer Mouse Shortcuts............................................................................................. 933
Table 54. set_ijtag_retargeting_options Arguments and SDC Variables...............................................955
Table 55. Common Dofile Issues and Solutions................................................................................... 984
Table 56. Common Tcl Characters........................................................................................................985

26 Tessent™ Shell User’s Manual

 Chapter 1
Tessent Shell Introduction
Tessent™ Shell is a platform from which you can run all the Tessent tools. The platform includes shared
design data, a common database, and powerful scripting utilities that provide a fully automated design-
for-test (DFT) flow as well as the ability to customize the flow to fit specific requirements.

What Is Tessent Shell?

What Can You Do With Tessent Shell?
Tessent Shell Tcl Interface

What Is Tessent Shell?

Tessent™ Shell is a DFT environment within which you can perform all the tasks required to insert DFT
hardware, generate manufacturing test patterns, and perform post-silicon tasks such as diagnosis and
yield analysis.
Tessent Shell provides a flexible design flow that supports a high level of automation or customization.
Key aspects of the environment that support automation as well as enhance flexibility:

• Shared Data Models — Tessent Shell uses data models to store your design data. The Tessent
environment shares these models across all tools and functions, and you can access the data
stored within them to customize your design flow.
For standard automated flows, you do not need to be aware of this infrastructure. For those flows
that need to extend the native tool commands, they have the same access to the design data
model as the Tessent Shell tools do.
For more information about the data models, refer to “Design Data Models” on page 41.

• Attributes — Attributes are characteristics associated with design objects, such as library cells,
pins, and modules, that are stored within data models. Some are predefined, and you can also
create your own attributes. Using attributes increases visibility into your design, enabling you to
manipulate and query the features of the design objects.

• Design Introspection — Introspection is the act of examining the design objects and attributes
stored within the data models. Introspection enables you to retrieve the design data you need so
that you can use Tcl scripting techniques to automate your own custom designs flows.
For more information about design introspection, refer to “Design Introspection” on page 46.

• Tcl — Use this scripting language across all Tessent tools and functions. Through scripting,
you can customize and extend the Tessent Shell standard flows as needed for your design
requirements.
For more information about Tcl usage, refer to “Tessent Shell Tcl Interface” on page 29.

• Tessent Shell Database (TSDB) — The TSDB is a database that stores all the directories and
files that Tessent Shell generates as you move through a design flow. The TSDB enhances flow
automation by acting as the central location where Tessent tools can access the data it requires

Tessent™ Shell User’s Manual 27

Tessent Shell Introduction
What Can You Do With Tessent Shell?
for the current task, whether that task be reading in a design, performing DRC, inserting logic test
hardware, or performing ATPG pattern generation.
For more information about the TSDB, refer to “TSDB Data Flow for the Tessent Shell Flow” on
page 473.

• IJTAG Automation — By default, the DFT instruments that you create with Tessent Shell are
controlled through an IJTAG network and the IEEE 1687 protocol. Tessent Shell automatically
inserts the IJTAG infrastructure. This simplifies test setup and control of all the instruments at all
levels of hierarchy, and enables reuse in hierarchical designs and testbenches at any stage of
chip development.
For more information about IJTAG, refer to the Tessent IJTAG User’s Manual.

What Can You Do With Tessent Shell?

The Tessent Shell platform is a jumping-off point for accomplishing the full array of DFT tasks available
within the Tessent tool suite. Specific DFT tasks may require different licenses, but all tools may be
launched from and managed via Tessent Shell.
DFT tasks include:

• Instrument Insertion — Generate and insert logic test hardware such as EDT (embedded
deterministic testing) and OCC (on-chip clock controller), in addition to LogicBIST, MemoryBIST,
in-system test, and boundary scan.

• Scan Analysis and Insertion — Perform scan analysis and scan chain insertion.

• ATPG — Generate ATPG patterns and perform fault simulation, including compression
technology.

• Defect Diagnosis and Yield Analysis — Perform test failure diagnosis to determine a defect’s
most probable failure mechanism, as well as statistical analysis of diagnostic failures to find
systemic defects.
Additionally, Tessent Shell provides general-purpose design editing support so that you can modify your
design netlists as needed. You can work on the command line as described in Design Editing, or use the
Tessent Visualizer graphical interface.
If you are getting started with Tessent Shell, refer to Tessent Shell Workflows for information about the
Tessent Shell workflow for RTL and scan DFT insertion.

28 Tessent™ Shell User’s Manual

 Tessent Shell Introduction
Tessent Shell Tcl Interface

Tessent Shell Tcl Interface

The Tessent Shell environment uses a Tcl-based interface that you can use from the command line or by
writing dofile scripts.
The Tcl interface supports Tcl constructs such as variables, command substitution, flow control, and
procedures. You can embed Tcl constructs in tool commands and embed tool commands within Tcl
constructs the same as with any Tcl command.
For guidelines about using Tcl in Tessent Shell, and information about converting existing dofiles and
using special characters, refer to The Tessent Tcl Interface appendix.

Command Conventions
Command Completion
Command History
Escaped Hierarchical Names in Command Tcl Lists
Dofile Transcription
Tcl Command Registration

Command Conventions
Tessent Shell provides a unified Tcl-style command set and naming convention. Commands that begin
with a certain first word (for example, "get" in get_attribute_value_list) perform operations on the current
data model.
Table 1 provides a summary listing by command first word of the Tessent Shell commands. Refer to the
Tessent Shell Reference Manual for a complete list of commands and options. You can also use the help
command with a wildcard to find a complete list of commands that start with the same word:
> help get_*

Table 1. Tessent Shell Command Conventions

Command First Word Types of Operations Performed

append_ Operates on collections. Refer to Collections for more

information.
compare_
copy_
filter_
foreach_
index_
remove_
sizeof_
sort_

get_ Returns data strings or collections of lists, objects, or object

attributes from the design object model for introspection.

Tessent™ Shell User’s Manual 29

Tessent Shell Introduction
Command Completion

Table 1. Tessent Shell Command Conventions (continued)

Command First Word Types of Operations Performed

read_ Reads files into memory, such as libraries and netlists.

report_ Displays information about a specific item, such as the current

context or licenses currently checked out.

set_ Specifies options, contexts, modes, attributes, and the current

design. Refer to Contexts and System Modes and Object
Attributes for more information.

write_ Writes design data to a file or set of files.

Command Completion
In the Tessent Shell interface, you can use the Tab key to complete command names, command option
names, and command option values. If the command you type is ambiguous, pressing the Tab key lists
all matching commands. Additionally, within a command, pressing the Tab key can match variable names
with $.
Many Tessent Shell commands are constructed as follows:
command_name command_options command_option_values
For example:
set_config_value -in_wrapper /TopBuilder(CHIP)

Using Tab key completion, you can complete each of the command parts (name, options, and option
values).
For information about Tcl shell handling in Tessent Shell, refer to the set_tcl_shell_options command.

Command Name Tab Completion

As an example of command name completion, you can abbreviate the get_attribute_list command in the
Tessent Shell interface by typing the following:
SETUP> g_a_l <tab>

Pressing the Tab key after the string completes and expands the command so that it looks like this:
SETUP> get_attribute_list

Command Option Name Tab Completion

Tab completion for command option names is available for most commands. For example:
SETUP> get_config_value -m<tab>

-meta_id -meta_name -meta_object

SETUP> get_config_value -meta_

30 Tessent™ Shell User’s Manual

 Tessent Shell Introduction
Command History

Command Option Value Tab Completion

Tab completion for command option values is available for the following value types:

• Configuration data path

• Enum (Enumerated) values

Configuration Data Path Example
In this example, pressing the Tab key on the partial configuration data path completes the path:
SETUP> set_config_value -in_wrapper /TopB<tab>
SETUP> set_config_value -in_wrapper /TopBuilder(CHIP)/

Enum Value Example

In this example, using the Tab key lists the supported time values -time_unit option to the
get_config_value command:
SETUP> get_config_value -time_unit <tab>

as_is fs ms ns ps s us

SETUP> get_config_value -time_unit

Dofile Entries
You can use abbreviated commands (for example, g_a_l for get_attribute_list) in Tessent Shell dofiles,
but it is best to always use the full command name. There is no fixed minimum typing for any command
or option, and current minimum typing could change in future releases because of the addition of new
commands or options. Using the full command names also adds readability to your dofiles.

Command History
Tessent Shell provides many interactive command line conveniences found in other Linux shells.
On the command line, Tessent Shell binds the up arrow key to scroll back in history to show previous
commands, which you can easily rerun by pressing the enter key. Tessent Shell also binds the down
arrow key to scroll forward in the command history.
Tessent Shell also supports history expansion with an exclamation mark "!" as follows:

• !! — reruns the last command.

• !n — reruns the <n>th command. <n> must be an unsigned integer.

• !-n — reruns the <n>th last command. "!-1" is equivalent to "!!".

• !?str — reruns the last command that contains the <str> string.

• !str — reruns the last command that starts with the <str> string.
Tessent Shell does not support any other command selection or replacement options.
Tessent™ Shell User’s Manual 31
Tessent Shell Introduction
Escaped Hierarchical Names in Command Tcl Lists

Escaped Hierarchical Names in Command Tcl Lists

Options, introspection, and editing commands that accept multiple object specifications as an argument
expect a list of names (for example, get_pins, create_connections, set_ijtag_instance_options). Verilog
escaped identifiers contain spaces that, if not correctly passed to these commands, could prevent Tessent
from finding the object.
You must pass these names in a list to the command. You can do this in Tcl by adding a layer of braces or
by framing the string or variable within a "list" command.
For example:
The get_pins command interprets the string of the pin path as a list and breaks it into two name patterns:
"\escaped@mem_inst" and "/CLKW," which do not match anything in the design.

SETUP> get_pins {\escaped@mem_inst /CLKW}

// Error: No result.

Passing that string in a list passes the correct full pattern "\escaped@mem_inst /CLKW," and Tessent
Shell can find the requested object. Here are four different methods of accomplishing this.
SETUP> get_pins [list {\escaped@mem_inst /CLKW}]

{{\escaped@mem_inst /CLKW}}

SETUP> get_pins {{\escaped@mem_inst /CLKW}}

{{\escaped@mem_inst /CLKW}}

SETUP> set pin_name {\escaped@mem_inst /CLKW}

SETUP> get_pins [list $pin_name]

{{\escaped@mem_inst /CLKW}}

SETUP> lappend pin_list {\escaped@mem_inst /CLKW}

SETUP> get_pins $pin_list

{{\escaped@mem_inst /CLKW}}

Dofile Transcription
By default, the transcript style is Full, which means the tool writes out all commands read from a dofile
before any Tcl evaluation occurs. The command appears in the transcript as entered but is commented
out.
During Tcl evaluation, the Tcl commands are written to the transcript as follows:

32 Tessent™ Shell User’s Manual

 Tessent Shell Introduction
Tcl Command Registration

• The tool writes all commands from the dofile with a "// command:" prefix. This includes Tessent
Shell commands, Tcl commands, and complete loop and if/else constructs.

• The tool writes all commands embedded in Tcl constructs to the transcript as run with a "//
sub_command:" prefix. Tessent Shell completes the variable and command substitutions and
writes the resolved values in the loop to the transcript.

Note:
This does not apply to introspection commands. Introspection commands are not written to
the transcript as subcommands.

• The tool indents nested dofiles when they are written to the logfile.

• The tool can read a Tcl routine in much the same manner as a dofile. If you issue the source
command (>source my_report_env), then the Tcl commands in the routine are not transcripted.
Control the Tessent Shell transcription behavior using the set_transcript_style command.
For information about modifying existing dofiles for use with the Tessent Shell Tcl interface, refer to
Guidelines for Modifying Existing Dofiles for Use With Tcl.

Tcl Command Registration

You can convert any Tcl procedure into a Tessent Shell application command. This enables you to
implement functionality in Tcl and register that functionality as a command so that Tessent Shell handles
it like any other built-in command. Like any built-in command, newly registered Tcl commands support
Tab completion, and you can control their availability relative to the context and system mode. The help
system also includes the new command.
The following commands enable you to register new commands and to define arguments and options for
those commands.

Table 2. Commands for Tcl Command Registration

Command Description

display_message Controls messages produced by Tcl commands.

lock_current_registration Locks all current Tcl commands.

register_tcl_command Registers a Tcl command.

unregister_tcl_command Unregisters a Tcl command.

When you first run the new command, the tool performs syntactic and semantic checks, and provides
the parsed results to your Tcl implementation of the command. The tool also provides a mechanism to
automatically define and register user-defined commands at tool invocation.

Tessent™ Shell User’s Manual 33

Tessent Shell Introduction
Tcl Command Registration

For more information about creating your own application commands, refer to the examples included with
the register_tcl_command description in the Tessent Shell Reference Manual.

34 Tessent™ Shell User’s Manual

 Chapter 2
Tool Invocation, Contexts, Modes, and Data
Models
In the Tessent Shell environment, setting the context and system mode orients the tool as to which task
you want to perform. The tool uses design data models to store the relevant data about your design.

Tool Invocation
Contexts and System Modes
Design Data Models

Tool Invocation
When you invoke Tessent Shell, the tool starts up in setup mode.
You can invoke Tessent Shell from a Linux shell using the following syntax:

% tessent -shell

To use most Tessent Shell functionality, you must load a cell library after invocation using the
read_cell_library command.
Refer to the tessent shell command description in the Tessent Shell Reference Manual for additional
invocation options.

Tessent Startup File

During invocation, Tessent Shell reads the .tessent_startup startup file. You can use this startup file for
both general and tool-specific settings. The default location for the startup file is the home directory:
$HOME/.tessent_startup.
This startup file is common to the contexts listed in Table 4 on page 37.

Tessent Shell Environment Variables

Tessent Shell provides environment variables for Tessent Shell environment operation in addition to
application-specific environment variables. During invocation, the tool reads all environment variables that
you have set.
The following table lists the environment variables that you can set for Tessent Shell environment
operation.

Table 3. Application-Specific Environment Variables

Variable Description

TESSENT_LICENSE_EXCLUDE Specifies licenses that Tessent tools cannot check out. The
list of licenses uses the same terminology accepted by the
set_context -license command.

Tessent™ Shell User’s Manual 35

Tool Invocation, Contexts, Modes, and Data Models
Tool Invocation

Table 3. Application-Specific Environment Variables (continued)

Variable Description

TESSENT_LICENSE_INCLUDE Specifies the only licenses that Tessent tools can check out.
The list of licenses uses the same terminology accepted by the
"set_context -license" command.

TESSENT_LICENSE_ORDER Specifies the order in which Tessent tools check out licenses.
The list of licenses uses the same terminology accepted by the
"set_context ‑license" command.

TESSENT_STARTUP Specifies the pathname of a directory that contains a Tessent

tool startup file.
Default: No default

TESSENT_TMP_LOCATION Specifies the location at which the tool creates the

.tessent.tmp.hostname.process_id scratch directory. For more
information, refer to the command description in the Tessent
Shell Reference Manual.

TESSENT_UNDERSCORE_COMMA Directs the tool to only enable commands that use the
NDS_ONLY underscore style. When this environment variable is set to any
value, the legacy commands that used spaces are disabled.
For example, the tool would accept analyze_drc_violation but
would not accept "analyze drc violation".

Related Topics
read_cell_library [Tessent Shell Reference Manual]

tessent [Tessent Shell Reference Manual]

Managing Mentor Tessent Software

set_context [Tessent Shell Reference Manual]

get_scratch_directory [Tessent Shell Reference Manual]

36 Tessent™ Shell User’s Manual

 Tool Invocation, Contexts, Modes, and Data Models
Contexts and System Modes

Contexts and System Modes

One of the first tasks you perform after invoking Tessent Shell is setting the context and system mode for
the current session.
The term "context" refers to a broad category of functionality that often corresponds to a specific point
tool, product, or license feature, such as Tessent FastScan. Each context includes several system modes,
which specify the tool’s current state of operation. By setting the context and then the system mode, you
indicate the type of tasks you want Tessent Shell to perform.
In addition, you must specify the design level where you want Tessent Shell to run tasks.

Contexts
System Modes
Context and System Mode Combinations
Design Levels

Contexts
The context specifies the functional category of tasks you want to perform with Tessent Shell.
Table 4 lists the contexts that are currently available.

Table 4. Tessent Shell Contexts

Context Description

dft Editing and introspection of the following types of designs: gate-level

Verilog, RTL Verilog, RTL SystemVerilog, and RTL VHDL.

dft -edt EDT IP generation and optional insertion.®This corresponds to the IP

creation phase of Tessent TestKompress .

dft -logic_bist -edt Configuration, generation, and insertion of the EDT/LBIST hybrid
controller IP. This corresponds to Tessent LogicBIST.

dft -no_sub_context Specifies that a command is only available in the dft context when
no sub-context, such as -scan and -edt, was specified. Refer to the
register_tcl_command in the Tessent Shell Reference Manual for
more information.

dft -scan Scan analysis and scan chain insertion. This corresponds to Tessent
Scan. Additionally in this context you can prepare a BIST-ready design
and include tasks such as X-bounding, MCP/FP handling, and test
point insertion. These features correspond to Tessent ScanPro.

dft -test_points Test point identification and insertion. The test point identification
algorithm focuses on either pattern count reduction or improving
random pattern testability of the design.

patterns -failure_mapping Reverse map top-level failures to the core so that you can perform
diagnosis with Tessent Diagnosis. Used after performing scan pattern
retargeting within the patterns -scan_retargeting context.

Tessent™ Shell User’s Manual 37

Tool Invocation, Contexts, Modes, and Data Models
Contexts

Table 4. Tessent Shell Contexts (continued)

Context Description

patterns -ijtag PDL command retargeting for IJTAG (IEEE 1687-2014) plus extraction
of the ICL network from the design.

patterns -scan Test pattern generation and good and fault simulation. This
corresponds to Tessent FastScan and the test pattern generation
phase of Tessent TestKompress. The patterns -scan context
supports uncompressed scan ATPG/fault simulation, EDT ATPG/fault
simulation, and Logic BIST fault simulation.

patterns -scan_diagnosis Test failure diagnosis to determine a defect’s failure mechanism and
location. This corresponds to Tessent Diagnosis.

patterns -scan_retargeting Scan pattern retargeting for retargeting core-level test patterns at the
top level.

patterns -silicon_insight Control, simulate, debug, and characterize BIST-related memories,

logic, PLLs, and SerDes. This corresponds to Tessent SiliconInsight.

Context Specification
Set the Tessent Shell context using the set_context command. For example:
SETUP> set_context dft -scan

You must set the context after you invoke Tessent Shell and before you can enter most commands. The
set_context command is available only in setup mode. You can use the get_context command to view the
current context.
Prior to setting the context, you can only run a small set of setup commands. These commands are those
that you would typically place inside the startup file.

Context and Licensing

When you set the context, the tool automatically acquires the appropriate license, if available.
Alternatively, you can directly specify the license Tessent Shell acquires by using the set_context
command with the optional ‑license switch.
You can control the order in which Tessent Shell checks out licenses by setting the
TESSENT_LICENSE_ORDER environment variable. You provide, as the value of the environment
variable, a space-separated list of licenses using the terminology described for "set_context ‑license." For
example:

setenv TESSENT_LICENSE_ORDER "Scan TestKompress IJTAG"

Any available licenses not explicitly listed in the value of the TESSENT_LICENSE_ORDER environment
variable are appended to the list in their original order. The tool issues a warning if the environment
variable contains a license that does not exist.
You can exclude licenses such that Tessent Shell cannot check them out by setting the
TESSENT_LICENSE_EXCLUDE environment variable. You provide, as the value of the environment
variable, a space-separated list of licenses using the terminology described for "set_context ‑license." The
following example excludes two licenses:

38 Tessent™ Shell User’s Manual

 Tool Invocation, Contexts, Modes, and Data Models
System Modes

setenv TESSENT_LICENSE_EXCLUDE "testkompress mttslogicbistf"

You can limit the licenses that Tessent Shell can check out by setting the TESSENT_LICENSE_INCLUDE
environment variable. You provide, as the value of the environment variable, a space-separated list of
licenses using the terminology described for "set_context ‑license." The tool excludes all other licenses if
you set this environment variable. The following example includes only two licenses for Tessent Shell to
check out:

setenv TESSENT_LICENSE_INCLUDE "mtfastscanf fastscan"

For more information about specifying a license feature, refer to the set_context command description
in the Tessent Shell Reference Manual. For a complete list of license feature names, refer to Managing
Tessent Software.

System Modes
A system mode in Tessent Shell defines the operational state of the tool. The default system mode is
setup. The available system mode depends on the current context of the tool.
Table 5 lists the available system modes.

Table 5. Tessent Shell System Modes

System Mode Description

setup Used as the entry point into the tool. Used to define the current context
and specify the design information.

analysis Used to perform design analysis, test pattern generation, PDL retargeting,
and simulation.

insertion Used to perform design editing and introspection.

Change the Tessent Shell system mode using the set_system_mode command. For example:
SETUP> set_system_mode insertion

Context and System Mode Combinations

Together, the context and system modes imply a Tessent Shell task flow from setup to analysis to
insertion when you are working with DFT designs, and from setup to analysis when you are working with
patterns. For example, if you are working on a DFT design while in setup mode, you cannot perform scan
analysis.
The following matrix lists the actions you can perform in the available contexts and system modes. The
tool filters out the functionality that does not apply to the context/mode you are currently in and issues an
error when you attempt to perform a task not within the scope of the current context/system mode.

Tessent™ Shell User’s Manual 39

Tool Invocation, Contexts, Modes, and Data Models
Design Levels

Context Setup Mode Analysis Mode Insertion Mode

dft • Read and configure design • Scan analysis • RTL or gate-level

design editing
• Prepare for design editing, IP • Test point analysis with design
creation, scan insertion, test introspection
point analysis and insertion • EDT IP creation
• Hybrid TK/LBIST IP creation
• MemoryBIST IP creation
• Boundary scan IP creation
• In-System Test IP creation

patterns • Read and configure design • ATPG/fault simulation (not applicable)

• Define test pattern generation • PDL retargeting
type to perform
• Scan pattern retargeting
• Run an IJTAG test pattern
• Perform SimDUT simulation

The tool provides a set of commands that enable you to interact with contexts and system modes.

Table 6. Tessent Shell Context and System Mode Commands

Command Description

get_context Returns the current context as specified by the set_context command.

Also returns inferred sub-contexts, such as whether patterns -scan is
configured to perform LogicBIST or ATPG.

set_context Sets the current context and its options.

set_system_mode Sets the system mode.

Design Levels
When working with DFT designs—that is, you are working in context dft—you must set the design level at
which you are performing tasks. There is no default setting for the design level.
The available design levels are chip, physical block, and sub-block. For flat designs, you always work at
the chip level. For hierarchical designs, it is crucial to differentiate whether you are work at the top-level
(chip) or at lower levels within physical blocks or sub-blocks. Refer to Hierarchical DFT Terminology for
definitions of these terms.
For complete information, refer to the set_design_level command description in the Tessent Shell
Reference Manual.

40 Tessent™ Shell User’s Manual

 Tool Invocation, Contexts, Modes, and Data Models
Design Data Models

Design Data Models

Tessent Shell has the following data models: the hierarchical design data model, the flat design data
model, and the ICL data model. Each of these data models contains one or more design objects, such as
pins and modules, and each design object is associated with a set of attributes, such as an ID or bit-width
of a bus.
For a complete description of the various data models, object types, and attributes, refer to the "Data
Models" chapter in the Tessent Shell Reference Manual.

Flat Design Data Model

Hierarchical Design Data Model
ICL Data Model
Object Attributes

Flat Design Data Model

The flat design data model is an internal, flattened representation of a hierarchical design that the
tool creates when entering analysis mode. You can also explicitly create the flat model using the
create_flat_model command.
The flat design data model consists of gates that are connected together. A gate is an instance of a
primitive module, and a gate_pin object represents a pin on a gate instance. Gate_pin objects have no
unique instance name. Instead they have a unique ID that differentiates one from another. The format
of the ID is two integers separated by a period character. The first integer represents the gate ID, and
the second integer represents the pin index (where 0 is the output pin, 1 is first input pin, and so on).
However, this ID does not remain in place from one netlist version to the next or from one Tessent Shell
invocation to the next. For this reason, you should avoid hard-coding this ID into a script.

Note:
You can preserve hierarchical pins in the flat model by using the set_attribute_options
‑preserve_boundary_in_flat_model option.

For more information about the flat design data model and the gate_pin object type, refer to "Flat Design
Data Model" in the Tessent Shell Reference Manual.

Hierarchical Design Data Model

Tessent Shell translates your design netlist into a hierarchical design data model in memory when you
load the design into the tool using a command such as read_verilog.
The design data remains in memory during the Tessent Shell session until you delete the model or exit
the tool.
The hierarchical design data model contains the following object types:

• Module — A basic building block of your design. A module can be a Verilog module, a Tessent
library model, or a built-in primitive.

• Instance — A single instantiation of a module.

Tessent™ Shell User’s Manual 41

Tool Invocation, Contexts, Modes, and Data Models
ICL Data Model

• Port — An input, output, or inout interface of a module.

• Pin — An input or output interface of an instance.

• Net — A wire that connects the pins of instances.

• Pseudo_port — Represents a user-added primary input or primary output.

These object types are described in detail in the Data Models" chapter of the Tessent Shell Reference
Manual.
Use the set_current_design command to designate one module within your design as the current design.
Instances, pins, and nets are hierarchical objects defined relative to the current design.
Figure 1 shows a hierarchical design upon which many of the examples in this chapter are based. The
label above the elements is the instance name while the label below the elements is the module name.
For example, the module name of the AND gate in the upper-left corner is and3, and its instance name is
u1.
The dashed boxes are modules instantiated in the parent module. For example, module modc is
instantiated inside of module modb. Its complete instance path is u4/u5.

Figure 1. Hierarchical Design Example

ICL Data Model

The Instrument Connectivity Language (ICL) describes the elements that comprise the IJTAG network as
well as their logical (though not necessarily physical) connections to each other and to the instruments at
the endpoints of the network.
ICL bears a loose resemblance to a hierarchical netlist such as Verilog; it is organized by modules
that may contain instances of other modules, and it describes the connections between the pins of the
instances. ICL is not a complete netlist. The connections are port-to-port rather than through nets, and
ICL uses abstraction rather than include the detailed physical construction of the circuitry. ICL represents
only the behavioral operation of the network.
The ICL data model defines objects as one of various object types, such as icl_module, icl_instance,
icl_port, and icl_pin.
Each icl_module object has its list of objects including the following:

42 Tessent™ Shell User’s Manual

 Tool Invocation, Contexts, Modes, and Data Models
Object Attributes

• icl_port

• icl_instance_in_module

• icl_pin_in_module

• icl_scan_register_in_module

• icl_scan_mux_in_module

• icl_one_hot_scan_group_in_module

• icl_alias_in_module

• icl_scan_interface_of_module
Once the current design is set using the set_current_design command, the ICL data model is elaborated
downward from the current design and icl_instance objects are created for each instance of icl_module,
and icl_pin objects are created for each port of the modules associated to the icl_instances. The
icl_instance and icl_pin objects are hierarchical objects and therefore only exist after the current design
is set. The same holds for objects of type icl_scan_register, icl_scan_mux, icl_one_hot_scan_group,
icl_alias, and icl_scan_interface.
For more information about the ICL data model and the icl_module, icl_instance, icl_port, and icl_pin
object types, refer to "ICL Data Model" in the Tessent Shell Reference Manual.

Object Attributes
Each design object in a design data model has a list of characteristics, called attributes, attached to that
object. For example, each pin has an attribute that specifies its hierarchical name and its parent instance.
There are both predefined and user-defined attributes.
Predefined attributes provide access to information known to the tool such as the name of a module or
the direction of a pin. All design objects have some predefined attributes, and every design object can
have user-defined attributes as well. For a complete list of attributes for each type of data model, refer to
"Data Models" chapter in the Tessent Shell Reference Manual.
The process for creating a new user-defined attribute is called registration. The predefined attributes,
unlike the user-defined attributes, do not need to be registered.
You must register each new user-defined attribute and specify a default value before you can use
the attribute. If you want to later change the default value, you must unregister and then re-register
the attribute. For more information about the registration process, refer to the description of the
register_attribute command in the Tessent Shell Reference Manual.
You can query any attribute and change any user-defined attribute. Most predefined attributes are read-
only, although some are read-write, such as the is_hard_module attribute.
You can filter and sort objects based on the attributes and their values. The filter_collection and
sort_collection commands perform these operations. For more information about filtering attributes, refer
to "Attribute Filtering Equation Syntax" in the Tessent Shell Reference Manual.

Tessent™ Shell User’s Manual 43

Tool Invocation, Contexts, Modes, and Data Models
Object Attributes

Intuitively named "get_" commands return collections of objects from the data model and the model’s
attributes that you can use for design introspection of various design objects.

44 Tessent™ Shell User’s Manual

 Chapter 3
Design Introspection and Editing
Tessent Shell provides a full range of commands for examining (introspecting) and editing designs.
Along with the command-line interface, Tessent Shell provides a graphical user interface, Tessent
Visualizer, that enables you to edit and introspect designs, and adjust object attributes. For details, refer
to “Tessent Visualizer” on page 831.

Design Introspection
Design Editing
Simulation Contexts
Automatic Design Mapping
ICL Objects Versus Design Objects Introspection

Tessent™ Shell User’s Manual 45

Design Introspection and Editing
Design Introspection

Design Introspection
Tessent Shell introspection commands enable you to examine the design objects within a design data
model. They provide access to the tool’s internal data structures, giving you the flexibility of Tcl scripting
while keeping all compute-intensive processing in the tool’s backend. The commands operate on object
specifications that you include as arguments to the commands, and they return collections.

Object Specification Format

Collections
Design Introspection Examples
Design Introspection Command Summary
Bundle Object Introspection

Object Specification Format

An object specification lists the design objects (such as instances, pins, or nets) that the specified
command acts upon. The object specification can be the name of an object, a Tcl list of names of objects,
or a collection of objects. For design objects that have unique IDs, like instances, you can use the IDs as
the object names.
The following examples show the add_schematic_objects command with valid object specifications listed
within square brackets ([]) or braces ({}).
add_schematic_objects [get_instances u*] -display hierarchical_schematic

add_schematic_objects [list u1 u2 u3] -display hierarchical_schematic

add_schematic_objects {u1 u2 u3} -display hierarchical_schematic

These commands display the results in Tessent Visualizer.

All Tessent Shell commands operating on user-specified objects accept object specifications as
arguments.

Collections
Collections are an extension of Tcl specific to Tessent Shell applications. Native Tcl commands such as
"foreach" and "puts" do not recognize collections. A collection represents a group of zero or more design
objects. Empty sets are collections with zero objects.
Design introspection commands return collections of objects. The objects are stored in the internal data
structures, and the tool returns a string handle to this collection. The string handle is a "@" character
followed by a numeric ID (for example, "@1"). The entire data volume remains in the tool’s internal data
structures, so the Tcl interface is not overloaded with large amounts of data.
Introspection commands that you run directly from the shell display the "name" attribute of the first 50
elements of the collection because the name is more useful than displaying the collection ID. However,
the tool does not display names in non-interactive mode, such as when running a dofile.
The following example demonstrates the use of the get_instances and get_name_list commands to return
collections of objects:
SETUP>set var1 [get_instances u* -hierarchical –of_modules MOD1]

46 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Collections

{u1 u2 u3 u4 u5 u6 u7}

SETUP>puts $var1

@1

SETUP>puts [get_name_list $var1]

u1 u2 u3 u4 u5 u6 u7

In this example, the first command returns a collection of names. The objects are stored in internal data
structures, and the tool returns a string handle to this collection that is "@" followed by a number ID
("@1").
In the following example, the collection created by the get_instances command is stored in the variable
instCollection, which means that the collection is referenced.
set instCollection [get_instances -of_type cell]

Tessent Shell deletes the collection when you unset the variable instCollection or set the variable to a new
value, or when the Tcl variable(s) referring to the collection go out of scope.
In the following example, the collection created by the command get_pins is passed to the
get_attribute_value_list command. This means that the collection is referenced.
get_attribute_value_list [get_pins u1/a*] -name direction

Tessent Shell deletes the collection when the command get_attribute_value_list returns a value.
Collections can refer to objects that no longer exist because they have been deleted using editing
commands, such as delete_pins. The built-in attribute is_valid is set to false when an object has been
deleted. All commands that accept collection pointers as input automatically ignore objects with the
is_valid attribute set to false.

Persistence of Collections
The tool references a collection when the collection is stored in a Tcl variable or when it is passed to a
command or procedure. The tool automatically deletes a collection when it is no longer referenced.
You should not use Tcl built-in commands that expect a Tcl list, such as the foreach command, with
collections. When you pass a collection to this type of command, the command dereferences the
collection and, as a result, deletes the collection.

How to Transcript the Contents of Collections

Use the get_name_list command to return a list of the names of all the elements in the collection. So,
to transcript the names in the log file, you can use the puts command with get_name_list (or any other
Tessent get_* command):

Commands That Work With Collections or Tcl Lists

Tessent Shell provides commands that create, manipulate, and query collections. Table 7 presents some
1
Tessent Shell commands based on how they interact with collections.

____________________________________________________________________________________
1. The table does not list all the applicable commands. Refer to the Tessent Shell Reference Manual.
Tessent™ Shell User’s Manual 47
Design Introspection and Editing
Collections

Table 7. Commands That Interact With Collections

Commands that... Command Name

Create collections or Tcl lists get_attribute_list

get_attribute_option

get_attribute_value_list

get_current_design

get_fanins

get_fanouts

get_gate_pins

get_instances

get_modules

get_name_list

get_nets

get_pins

get_ports

Operate on collections add_to_collection

append_to_collection

compare_collections

copy_collection

filter_collection

foreach_in_collection

index_collection

remove_from_collection

sort_collection

Read and write attributes of objects get_attribute_list

found within collections or Tcl lists
get_attribute_value_list

report_attributes

set_attribute_value

48 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Design Introspection Examples

Design Introspection Examples

Design introspection enables you to create procedures to show design data of interest, create and set
attributes, create and manipulate collections, create custom reports, and other tasks.

Example of Creating a Procedure to Show Flip-Flop Fanouts

The following example is based on Figure 1 on page 42 and creates a procedure called show_fanouts
that returns the fanouts of a specified flip-flop.

proc show_fanouts {flop} {

set ff_fanout [get_fanouts $flop/Q]
puts "$flop/Q is connected to: [get_name_list $ff_fanout]"
}

The following two examples show how to use the show_fanouts procedure you just created.
> show_fanouts u2

u2/Q is connected to : u4/u4/A0 u4/u1/A1

> foreach_in_collection ff [get_instances * -of_module dff* -hierarchical] \

{show_fanouts [get_name_list $ff]}

u2/Q is connected to: u4/u1/A1 u4/u4/A0

u7/Q is connected to: O3 u6/A0 u5/u3/A1 u5/u4/S0
u4/u2/Q is connected to: u4/u3/D
u4/u3/Q is connected to: u6/A1 u5/u1/A1
u4/u5/u2/Q is connected to: u5/u4/A0
u5/u2/Q is connected to: u5/u1/A0 u5/u3/A0
u4/u5/u3/Q is connected to: u6/A2

Example of Displaying the Number of Input Ports

The following example displays the number of input ports on modules (objects with names that begin with
mod in Figure 1).
> set mods [get_modules mod* -of_type design]
> foreach_in_collection itr $mods \{puts "The number of input ports of \ [get_attribute_value_list
$itr -name name] \
is [sizeof_collection [get_ports -of_module $itr -direction input]]"}

The number of input ports of modb is 6

The number of input ports of modc is 4
The number of input ports of modd is 4

The design in Figure 2 is identical to Figure 1, with the addition of colors to help you understand the
examples that follow.

Tessent™ Shell User’s Manual 49

Design Introspection and Editing
Design Introspection Examples

Figure 2. Hierarchical Design Example With Colors

Example of Creating Attributes and Manipulating Collections

The following example is based on Figure 2 and shows the complete process of creating and setting user-
defined attributes, and then creating and manipulating collections.
register_attribute -name color -value_type string -default "blue" -enum "red green blue" \
‑object_types instance

Set the color attribute of each instance to match Figure 2.

set_attribute_value {/u4/u4 /u4/u5/u3 /u5/u2} -name color -value "green"

{u4/u4 u4/u5/u3 u5/u2}

set_attribute_value {u1 u2 u6 /u4/u5/u1 /u4/u3 /u5/u4 /u5/u3} -name color -value "red"

{u1 u2 u6 u4/u5/u1 u4/u3 u5/u4 u5/u3}

set_attribute_value {u3 u7 /u4/u1 /u4/u2 /u4/u5/u2 /u5/u1} -name color -value "blue"

{u3 u7 u4/u1 u4/u2 u4/u5/u2 u5/u1}

Create collections of instances with the same color values.

set all_inst [get_instances -of_type cell]

{u1 u2 u3 u6 u7 u4/u1 u4/u2 u4/u3 u4/u4 u4/u5/u1 u4/u5/u2 u4/u5/u3 u5/u1

u5/u2 u5/u3 u5/u4}

set red_inst [filter_collection $all_inst {color == "red"}]

{u1 u2 u6 u4/u3 u4/u5/u1 u5/u3 u5/u4}

set blue_inst [filter_collection $all_inst {color == "blue"}]

{u3 u7 u4/u1 u4/u2 u4/u5/u2 u5/u1}

50 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Design Introspection Examples

set green_inst [filter_collection $all_inst {color == "green"}]

{u4/u4 u4/u5/u3 u5/u2}

Manipulate the collections and create additional collections.

puts "Number of red cells in the design: [sizeof_collection $red_inst]"

Number of red cells in the design: 7

puts [compare_collections $red_inst $blue_inst]

set red_green [add_to_collection $red_inst $green_inst]

{u1 u2 u6 u4/u3 u4/u5/u1 u5/u3 u5/u4 u4/u4 u4/u5/u3 u5/u2}

set sort_red [sort_collection $red_inst name -descending]

{u6 u5/u4 u5/u3 u4/u5/u1 u4/u3 u2 u1}

Example of Displaying Attribute Values of a Collection

After Tessent Shell has run the previous commands, the following commands display the colors assigned
to gates in the collection named ANDs.
set ANDs ""
append_to_collection ANDs [get_instances -of_type cell -filter {module_name == "AND"}]
foreach_in_collection itr $ANDs {puts "The color value for \
[get_attribute_value_list $itr -name name] is [get_attribute_value_list \ $itr -name color] "}

The color value for u1 is red

The color value for u4/u4 is green
The color value for u4/u5/u1 is red

As an alternate way to register the attribute in the previous example, you can use the register_attribute
command as shown here:
register_attribute -name is_red -value_type bool -object_types "instance" \
–description "True if color is red."

So, instead of using the color attribute with enumerated values of red, green, and blue as shown
previously, you could instead register three Boolean type attributes of is_red, is_green, and is_blue. This
enables you to use Boolean values for filtering and tracing. For example:
> set red_inst [filter_collection $all_inst {is_red}]

Example of Changing an Attribute of a Collection

The following command example is based on Figure 2 and shows how to change the color attribute of a
collection of DFFs to green.

Tessent™ Shell User’s Manual 51

Design Introspection and Editing
Design Introspection Examples

set DFFs [get_instances -of_modules dff]

# display all of the instances that have a color attribute of blue

set all_blue [filter_collection $all_inst "color == blue"]

{u7 u4/u2 u4/u5/u2}

# change all instances in the collection DFFs to have a "color" attribute value of green

set_attribute_value $DFFs -name color -value green

# now check the results

set all_green [ filter_collection [$all_inst {color == "green"}] ]

{u2 u7 u5/u2 u4/u4 u4/u2 u4/u3 u4/u5/u2 u4/u5/u3}

Example of Removing Duplicate Objects from a Collection

The following example shows how to create a collection containing three duplicate objects and then
remove the duplicate objects from the collection.
set t [get_instances {u3 u3 u3}]

{u3 u3 u3}

sizeof_collection $t

set tt [add_to_collection "" $t -unique]

{u3}

sizeof_collection $tt

Example of Creating a Custom Report

The following dofile example creates a collection of all instance objects with a leaf name starting with "u"
and then displays ten instance names per row.

set cnt 0
set line ""
foreach_in_collection element [get_instances u* -hierarchical] {
if {$cnt < 10} {
append line "[get_single_name $element] "
incr cnt
} else {
puts $line
set line ""

52 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Design Introspection Command Summary
append line "[get_single_name $element] "
set cnt 1
}
}
if {$cnt > 0} {puts $line}

Example of Finding Quick-Synthesized Objects From RTL Names

The following example calls the get_ports introspection command with the RTL name after performing
quick synthesis.
get_ports INF[1].data[5].ask

{\INF[1].data[31]}

get_ports data_in[5].ask

{data_in[31]}

The following example calls the get_instances introspection command with the RTL name after
performing quick synthesis.
get_instances u1/GEN[1].u2/REG[5].u3

{u1/\GEN[1].u2 /\REG[5].u3}

Related Topics
Editing Complex Verilog and SystemVerilog Signals With Tessent Shell Commands

Design Introspection Command Summary

The design introspection commands include the get_ commands as well as various commands for
manipulating attributes.

Design Introspection Command Summary

Table 8 lists the common design introspection commands. Refer to the Tessent Shell Reference Manual
for more information.

Table 8. Design Introspection Commands

Command Name Description

get_common_parent_instance Returns the common ancestor of all instances, pins, or nets

found in object_spec.

get_current_design Returns a collection of one element that specifies the

top-level design when previously set.

get_design_level Returns the design level previously defined with the

set_design_level command.

Tessent™ Shell User’s Manual 53

Design Introspection and Editing
Design Introspection Command Summary

Table 8. Design Introspection Commands (continued)

Command Name Description

get_fanins Returns a collection of all objects found in the fan-in of the

specified pin, net, or port objects.

get_fanouts Returns a collection of all requested objects found in the

fanout of the specified pin, net, or port object.

get_gate_pins Returns a collection of all gate_pin objects found below the

current design in the flat model.

get_instances Returns a collection of instances relative to the current

design. Returns the equivalent quick-synthesized objects
from the complete RTL instance name.

get_modules Returns a collection of modules.

get_nets Returns a collection of nets relative to the current design.

get_pins Returns a collection of pins relative to the current design.

Returns the equivalent quick-synthesized objects from the
complete RTL names of complex pins (including the instance
path).

get_ports Returns a collection of ports on a given module. Returns the

equivalent quick-synthesized objects from the complete RTL
names of complex ports (including the instance path).

Attribute Introspection Command Summary

Table 9 lists all of the commands that introspect attributes.

Table 9. Attribute Introspection Commands

Command Name Description

get_attribute_list Lists registered attributes.

get_attribute_option Returns the current setting of an attribute's option.

get_attribute_value_list Returns the attribute's value.

get_name_list Returns the name attribute of the specified objects.

get_single_name Returns a string with the name of the element specified by the object_spec
argument.

register_attribute Registers a new attribute by adding it to the attribute manager.

report_attributes Prints a report for the registered attributes.

reset_attribute_value Resets the attribute to its default value.

set_attribute_options Configures attribute options.

54 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Design Introspection Command Summary

Table 9. Attribute Introspection Commands (continued)

Command Name Description

set_attribute_value Defines the attribute's value.

unregister_attribute Makes an attribute unusable by removing it from the attribute manager.

Tessent™ Shell User’s Manual 55

Design Introspection and Editing
Bundle Object Introspection

Bundle Object Introspection

The Bundle Object Hierarchy is an extension of the module instance hierarchy, and the signals (pins,
ports, and nets) are considered as a tree of sub signals. The root bundle is the signal itself, the leaf
objects are the bit-blasted elements of the given signal, and the nodes are the middle bundle objects.
To support this bundle object concept new object types are added to Tessent Shell Hierarchical Design
Data Model. The leaf objects are represented by net, pin, port object types; the sub and root bundle
objects are represented by net_bundle, pin_bundle, and port_bundle objects types.
The bundle object is set of bits that represents a sub signal of a given net or port. This concept is applied
to complex and simple signals for RTL and no RTL flow. The difference between simple and complex
signals is in the number of levels that can be explored through the introspection commands.
Each complex signal has a select part. For example, for the following complex signal:

B[5].c[2].d

The portion in red ([5].c[2].d) is the select part, and the "B" is the root bundle. Refer to the "Bundle Object"
topic for complete details. The select part of the signals helps to explore the Bundle Object Hierarchy
level-by-level.
Tessent Shell supports introspection of RTL complex signals through a bundle object, which is a set of
bits that represent a sub signal of a given RTL net or port. Using Tessent Shell introspection commands
enable exploration inside the bundle object and selection of different bundle parts of the signals using the
hierarchical bitselect.

Bundle Object
Bundle Object Data Model
Introspection
Bundle Object Introspection Examples
Fan-in and Fanout Tracing of Complex Signals and Bundle Object Tracing
Connectivity Through Complex Signals

Bundle Object
A bundle object is a set of bits that represents a whole signal or its sub signals of a given RTL port or net.
The bundle is made up of Tessent Shell Hierarchical Design Data Model object types that you introspect
using Tessent Shell introspection commands relative to the current design. The following illustrates this
concept:
Root bundle (Signal itself)
|--> Node (Sub Signal)
| |--> Leaf (Bit-blasted elements)

Example:net_bundle (Bundle Object Type)

|--> net_bundle (Bundle Object Type)
| |--> net (Bit-blasted Object Type)

pin_bundle (Bundle Object Type)

|--> pin_bundle (Bundle Object Type)
| |--> pin (Bit-blasted Object Type)

56 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Bundle Object
port_bundle (Bundle Object Type)
|--> port_bundle (Bundle Object Type)
| |--> port (Bit-blasted Object Type)

The following object types contain several common attributes that are also associated with the bit-blasted
object types (net, pin, and port):

• net_bundle

• pin_bundle

• port_bundle
All attributes added to port, pin, and net are also added to port_bundle, pin_bundle, and net_bundle.
For example, the naming is common between a bit-blasted object type and a bundle object type.
Refer to “Bundle Object Data Model” on page 61 for complete information.

Naming Attributes
The following table shows the list of the principal name attributes associated with net, port, and pin object
types.

Attribute Description RTL View Synthesized View

name The active name. The The full RTL The full synthesis name
name depends on the name including including all the select part
selected view. This all the select (flatten position in case of
includes the select part in part. complex signals).
the case of signals (port,
pin, and net).
The -rtl mode has the RTL
view and the synthesized
view.
The -no_rtl mode only has
the netlist view.

parent_bundle_name The bundle parent of the The parent The parent name of the
port, pin, or net. name of the selected synthesized
selected RTL object.
object.

post_synthesis_name The synthesis name, The computed Equal to "name" attribute.

created by the quick equivalent post
synthesis. synthesis name.

pre_synthesis_name RTL name, the original Equal to "name" Full RTL name, the original
name before synthesis. attribute. name before synthesis.

root_bundle_name The active name without The base RTL The base synthesis name
the select part. name without without the select part.
the select part.

Tessent™ Shell User’s Manual 57

Design Introspection and Editing
Bundle Object

Bundle Naming Examples

Example 1
The post_synthesis_name attribute for complex signals is usually the base name with the flatten position
as the index. SystemVerilog interface signals are the exception. For example, in case of the following
input port "data_in" declared as array of structure in SystemVerilog:

typedef struct{
logic a;
logic [1:0] b;
} data_t;
input data_t [2:0][4:0] data_in;

The following figure illustrates the representation in the flatten dimension:

Name Attribute (RTL View) post_synthesis_name Attribute

data_in[2][1].a data_in[35]

data_in[2][1].b data_in[34:33]

data_in[2][1].b[1] data_in[34]

The following table shows the different naming of the signal "data_in[2][1].b[1]"

Attribute RTL View Synthesis View

name data_in[2][1].b[1] data_in[34]

pre_synthesis_name data_in[2][1].b[1] data_in[2][1].b[1]

post_synthesis_name data_in[34] data_in[34]

root_bundle_name data_in data_in

Example 2
In this example, the "net1" from Example 1 is declared inside nested generate blocks:

typedef struct{
logic a;
logic [1:0] b;
} data_t;

genvar i, j;
generate

58 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Bundle Object
for (i=0; i < 2; i=i+1) begin
for (j=0; j < 2; j=j+1) begin : MEM_j
data_t [2:0][4:0] net1;
…………
end
end
endgenerate

The following table shows the different naming of "genblk1[0].MEM_j[0].net1[2][1].b[1]"

Attribute RTL View Synthesis View

name genblk1[0].MEM_j[0].net1[2][1].b[1] \genblk1[0].MEM_j[0].net1 [34]

pre_synthesis_name genblk1[0].MEM_j[0].net1[2][1].b[1] genblk1[0].MEM_j[0].net1[2][1].b[1]

post_synthesis_name \genblk1[0].MEM_j[0].net1 [34] \genblk1[0].MEM_j[0].net1 [34]

root_bundle_name genblk1[0].MEM_j[0].net1 \genblk1[0].MEM_j[0].net1

Example 3
This example illustrates an interface declared as a net to connect two sub instances.

interface intf;
logic a;
logic b;
modport in (input a, output b);
modport out (input b, output a);
endinterface

module top;
intf i ();
u_a m1 (.i1(i));
u_b m2 (.i2(i));
endmodule

module u_a(intf.in i1);

endmodule
module u_b(intf.out i2);
endmodule

The following tables shows the different naming of the signals "i.a" and "m1/i1.a".
For net: "i.a"

Attribute RTL View Synthesized View

name i.a \i.a

object_type net net

pre_synthesis_name i.a i.a

Tessent™ Shell User’s Manual 59

Design Introspection and Editing
Bundle Object

Attribute RTL View Synthesized View

post_synthesis_name \i.a \i.a

root_bundle_name i i

For pin: "m1/i1.a"

Attribute RTL View Synthesized View

name m1/i1.a m1/\i1.a

object_type pin pin

pre_synthesis_name m1/i1.a m1/i1.a

post_synthesis_name m1/\i1.a m1/\i1.a

root_bundle_name m1/i1 m1/\i1.a

Example 4
The values of the name attributes are language independent and have the same values for both VHDL
and Verilog RTL objects. The following example in VHDL uses the record datatype:

library ieee;
package record_pkg is

-- Outputs from the FIFO.

type t_FROM_FIFO is record
wr_full : std_logic; -- FIFO Full Flag
rd_empty : std_logic; -- FIFO Empty Flag
rd_dv : std_logic;
rd_data : std_logic_vector(7 downto 0);
end record t_FROM_FIFO;
………
end package record_pkg;
use work.record_pkg.all; -- USING PACKAGE HERE!
entity top is
port (
i_clk : in std_logic;
i_fifo : in t_FROM_FIFO;
……… );
end top;

architecture behave of top is

begin
………
end behave;

The following table shows the different naming of the port "i_fifo.rd_data(5)" in VHDL. VHDL uses "()" to
represent the index, but Tessent Shell uses "[]" instead.

60 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Bundle Object Data Model

Attribute RTL View Synthesis View

name i_fifo.rd_data[5] i_fifo[5]

pre_synthesis_name i_fifo.rd_data[5] i_fifo.rd_data[5]

post_synthesis_name i_fifo[5] i_fifo[5]

root_bundle_name i_fifo i_fifo

Bundle Object Data Model

Bundle objects utilize the Tessent Shell Hierarchical Design Data Model object types.
For each object type, there are attributes associated with the design objects found on, in, and below the
current design (set with the set_current_design Tessent Shell command). A bundle object has a select
part and type information. Otherwise a bit-blasted object has a bit select and also type information. An
object type can be a complex type in case of bundle object, like struct, enum, typedef, multi-dimensional
array. In the case of a bit-blasted object it is always a 1 bit datatype. It can be register, wire, logic, bit, tri,
for example. Several attributes are associated with the following Hierarchical Design Data Model object
types:

• Net

• Net Bundle

• Pin

• Pin Bundle

• Port

• Port Bundle
Each of these object types is covered in detail in the Tessent Shell Reference Manual.

base_class and base_type Attributes

Each bundle object type contains a base_class and base_type attribute as follows:

• base_class — String character that represents the class category of the base type. It helps to
complete the base_type definition. Possible values are: = 4_state_signed | 4_state_unsigned |
2_state_signed | 2_state_unsigned | enum | struct_packed | struct_unpacked | union_backed |
union_unpacked | interface | interface_modport | other.

• base_type — String character that represents the base type of the selected object. The base
type is the type of the object without any dimensions. It represents the base type of the sub
bundle type if the selected object is a sub bundle object. It can be a base type of the root type if
the selected object is a root bundle. The base_type is a key or user name that help to understand
the base type of this bundle. Possible values are: logic | register | wire | bit | supply0 | supply1 | tri
| triand | trior | tri0 | tri1 |wand | wor | byte | shortint | integer | longint | user_name | other

Tessent™ Shell User’s Manual 61

Design Introspection and Editing
Bundle Object Data Model

The following examples show the values for base_class and base_type bundle object type attributes in
SystemVerilog:

Table 10. base_class and base_type SystemVerilog Examples

Examples base_type and base_class Values

Packed struct having typedef name base_type = data_t, base_class = struct_packed

"data_t"

Unpacked struct having typedef base_type = data_t, base_class = struct_unpacked

name "data_t"

shortint base_type = shortint, base_class = 2_state_signed

unsigned shortint base_type = shortint, base_class = 2_state_unsigned

integer base_type = integer, base_class = 4_state_signed

int base_type = integer, base_class = 2_state_signed

unsigned integer base_type = integer, base_class = 4_state_unsigned

unsigned int base_type = integer, base_class = 2_state_unsigned

reg base_type = register, base_class = 4_state_unsigned

logic base_type = logic, base_class = 4_state_unsigned

bit base_type = logic, base_class = 2_state_unsigned

supply0, supply1 base_type= supply0 or supply1, base_class = 2_state_unsigned

tri, wand, triand, wor, trior, tri0, tri1 base_type = tri, wand, triand....
For all those datatypes, the base_class = 4-state_unsigned

module top (INTF1 Bus) bundle "Bus" has as base_type=INTF1, base_class = interface

module top (INTF1.secondary Bus) bundle "Bus" has as base_type=INTF1.secondary,

base_class = interface_modport

Net Bundle
The Net Bundle object type has net_bundle datatype and attributes. For complete details, refer to
net_bundle in the Tessent Shell Reference Manual.

Pin Bundle
The Pin Bundle object type has pin_bundle datatype and attributes. For complete details, refer to
pin_bundle in the Tessent Shell Reference Manual.

Port Bundle
The Port Bundle object type has port_bundle datatype and attributes. For complete details, refer to
port_bundle in the Tessent Shell Reference Manual.

62 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Introspection

ICL Data Model

The ICL data model is a separate data model that reflects the design logic. The ICL data model defines
objects as one of the following four data types: icl_module, icl_instance, icl_port, and icl_pin.
When using bundle objects, the naming style may be different between the ICL data model and the
design logic data model. For this reason, bundle object-specific attributes are required to bind the ICL
objects (icl_module and icl_port) to design logic (module and port).
icl_module
The following icl_module built-in attribute applies to design objects:

• tessent_design_module — The attribute reflects the name of the design module that
corresponds to the ICL module at the time of ICL extraction.
icl_port
The following icl_port built-in attribute applies to design objects:

• tessent_design_gate_ports — The attribute reflects the post_synthesis_name of the design

port corresponding to the ICL port at the time of ICL extraction.

• tessent_design_rtl_ports — An attribute that specifies the pre_synthesis_name of the design

port corresponding to the ICL port at the time of ICL extraction.

Introspection
Using bundle object types, Tessent Shell enables you to introspect and explore any kind of signal within
the design data model.
Both simple datatypes and complex datatypes can be explored using the introspection commands listed
in “Complex Signal Introspection Commands” on page 66.
Any signal objects (ports, pins, and nets) are considered as a tree of sub signals. The given tree is
referred to as a Bundle Object Hierarchy. The root bundle is the signal; the leaf objects are the bit-blasted
elements of the given signal; the root, leaf, and middle bundle are all nodes of the tree. The middle
bundles and the leaf objects are the sub bundle objects. To support this concept there are object types in
the Hierarchical Design Data Model. The leaf objects are represented by net, pin, and port object types,
the root and middle bundles are represented by net_bundle, pin_bundle, and port_bundle objects types.
Refer to “Bundle Object Data Model” on page 61.
The concept of bundle object type is applied to complex and simple signals for RTL and no RTL flow. The
difference between simple and complex signals is in the number of levels that can be explored through
the introspection commands. The select part of the signals helps to explore the Bundle Object Hierarchy
level by level.

Tip
When performing introspection of complex signals, also refer to “Object Specification Format” on
page 46 and “Collections” on page 46.

How Complex Signal Introspection Works

Consider the bundle hierarchy of the "data_in" port as follows:

Tessent™ Shell User’s Manual 63

Design Introspection and Editing
Introspection

typedef struct{
logic a;
logic [1:0] b;
} data_t;
input data_t [1:0][2:0] data_in;

The following shows the hierarchy of the "data_in" port in the Tessent Shell design data model.
Root bundle "data_in"
|---> data_in[1]
| |---> data_in[1][2]
| | |---> data_in[1][2].a
| | |---> data_in[1][2].b
| | |---> data_in[1][2].b[1]
| | |---> data_in[1][2].b[0]
| |---> data_in[1][1]
| | |---> data_in[1][1].a
| | |---> data_in[1][1].b
| | |---> data_in[1][1].b[1]
| | |---> data_in[1][1].b[0]
| |---> data_in[1][0]
| |---> data_in[1][0].a
| |---> data_in[1][0].b
| |---> data_in[1][0].b[1]
| |---> data_in[1][0].b[0]
|---> data_in[0]
|---> data_in[0][2]
| |---> data_in[0][2].a
| |---> data_in[0][2].b
| |---> data_in[0][2].b[1]
| |---> data_in[0][2].b[0]
|---> data_in[0][1]
| |---> data_in[0][1].a
| |---> data_in[0][1].b
| |---> data_in[0][1].b[1]
| |---> data_in[0][1].b[0]
|---> data_in[0][0]
|---> data_in[0][0].a
|---> data_in[0][0].b
|---> data_in[0][0].b[1]
|---> data_in[0][0].b[0]

Referring to the figure, using the name_patterns argument of the introspection commands, the tool splits
each pattern into the different levels so that a local sub-pattern is applied to each local level.
For the bundle part, the characters "." and "[<index>]" enable access to sub bundle hierarchy, ":" to
access field sub bundle objects of struct or SVinterface and "[<index>]" to access array element sub
bundle objects. For example, the pattern "data_in[0][1].b[*]" is really five sub-patterns; "data_in", "[0]",
"[1]",".b", and "[*]", representing five levels of bundle hierarchy.
For simple wildcard patterns, the '*' is used the exact same way as it is used in instance path matching.
It does not cross hierarchy. When specified within a field name it does not cross the "." that precedes or
follows the field. When applied within [ ], it only matches elements within the [ ]. In other words delimiters
must be explicit.
For regular expression patterns, an individual regular expression only matches elements within the sub-
pattern in which they are found. Again, it does not cross the adjacent delimiters.

64 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Introspection

Without the -regexp switch in the introspection command, the tool treats the bundle hierarchy delimiters
("[]" and ".") as normal delimiters and serves to break the pattern into multiple sub-patterns. When you
include the -regexp switch in the introspection command, the tool treats the bundle hierarchy delimiters as
regular expression meta-characters (unless you have escaped those delimiters). That is, in regexp mode
the delimiters must be explicit and, unlike simple wildcard patterns, you must escape them.
For example, to match data_in[1], you need to use data_in\[.*\]. The sequence '.*' matches any character
zero or more times. For more details, refer to the Example With regexp.
Refer to Glob and Regular Expression Pattern Matching Syntax in the Tessent Shell Reference Manual
for complete information on pattern matching.

Note:
The examples use the "get_ports ... -bundle" command. For "get_nets ... -bundle" and
"get_pins ... -bundle", the behavior is the same.

Examples
These examples use the "data_in" hierarchy described in the preceding.
SETUP> get_ports data_* -bundle

data_in

SETUP> get_ports data_in* -bundle

data_in

SETUP> get_ports data_in[*] –bundle

{data_in[1]} {data_in[0]}

SETUP> get_ports data_in[0][*] -bundle

{data_in[0][2]} {data_in[0][1]} {data_in[0][0]}

SETUP> get_ports data_in[0] -bundle

{data_in[0]}

SETUP> get_ports data_in[0][*].b -bundle

{data_in[0][2].b} {data_in[0][1].b} {data_in[0][0].b}

SETUP> get_ports data_in[1][2].* -bundle

{data_in[1][2].a} {data_in[1][2].b}

SETUP> get_ports data_in[1][*] -bundle

{data_in[1][2]} {data_in[1][1]} {data_in[1][0]}

Tessent™ Shell User’s Manual 65

Design Introspection and Editing
Introspection

Note:
Integer, enum, and others are bit-blasted in unbundled objects in introspection commands when
the ‑bundle switch is omitted.

Example With regexp

In the following example the second command call is equivalent to the first, but uses ‑regexp. You should
enclose the regexp in double braces ({{ }})to avoid having to use the "\\" everywhere, that is, "{{data_in\[.*
\]\.da.*\[.*\]\..*}}".
With wildcard syntax:
SETUP> puts [join [get_name_list [get_ports data_in[*].da*[*].* ]] "\n"]

data_in[1].data[1].data1[1][1]
data_in[1].data[1].data1[1][0]
data_in[1].data[1].data1[0][1]
data_in[1].data[1].data1[0][0]
data_in[1].data[1].data2[1][2]
...
data_in[0].data[0].data2[0][2]
data_in[0].data[0].data2[0][1]
data_in[0].data[0].data2[0][0]

With regular expression syntax:

SETUP> puts [join [get_name_list [get_ports {{data_in\[.*\]\.da.*\[.*\]\..*}} -regexp]] "\n"]

data_in[1].data[1].data1[1][1]
data_in[1].data[1].data1[1][0]
data_in[1].data[1].data1[0][1]
data_in[1].data[1].data1[0][0]
data_in[1].data[1].data2[1][2]
...
data_in[0].data[0].data2[0][2]
data_in[0].data[0].data2[0][1]
data_in[0].data[0].data2[0][0]

Complex Signal Introspection Commands

The following commands support introspection of complex signals:

Table 11. Complex Signals Design Introspection Commands

Command Name Description/Usage

get_bundle_objects Returns a collection of bundle/leaf objects in the current design specified

by the name_patterns list in conjunction with the specified options. Those
bundle objects (leaf in case of descendants) are ancestors or descendants
of the objects that match the specified name_patterns depending upon the
specified options.

get_nets ... -bundle When the -bundle switch is specified, constrains the tool to return net
bundle/leaf objects. When the pattern matches a bundle, the command

66 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Bundle Object Introspection Examples

Table 11. Complex Signals Design Introspection Commands (continued)

Command Name Description/Usage

returns the bundle. When it matches leaf objects, it returns those leaf
objects.

get_pins ... -bundle When the -bundle switch is specified, constrains the tool to return pin
bundle/leaf objects. When the pattern matches a bundle, the command
returns the bundle. When it matches leaf objects, it returns those leaf
objects.

get_ports ... -bundle When the -bundle switch is specified, constrains the tool to return port
bundle/leaf objects. When the pattern matches a bundle, the command
returns the bundle. When it matches leaf objects, it returns those leaf
objects.

Bundle Object Introspection Examples

The following SystemVerilog code shows several kinds of datatypes: struct, array of interfaces,
enumeration.

typedef enum logic [1:0] {

STATE_1, STATE_2, STATE_3, STATE_4, STATE_5, STATE_6
} State_t;

typedef struct packed {

logic [2:0] eventbus;
} event_bus_packet_t;

typedef struct packed {

State_t state_encoded;
event_bus_packet_t dt_lcp_pulse;
logic [3:0] eventbus_encoded;
} event_bus_split_packet_t;

interface MSBus;
event_bus_split_packet_t Addr;
logic [1:0] Data;
logic RWn;
logic Clk;
modport Secondary (input Addr, RWn, Clk, output Data);
endinterface

module top(MSBus.Secondary Bus[2], input wire i_clk);

RAM TheRAM (.MemBus(Bus));
endmodule

Example 1
The following command returns all bit-blasted ports of "top" module (default behavior):
SETUP> get_ports -of_modules top

Tessent™ Shell User’s Manual 67

Design Introspection and Editing
Bundle Object Introspection Examples

{Bus[0].Addr.state_encoded[2]} {Bus[0].Addr.state_encoded[1]}
{Bus[0].Addr.state_encoded[0]} {Bus[0].Addr.dt_lcp_pulse.eventbus[2]}
{Bus[0].Addr.dt_lcp_pulse.eventbus[1]}
{Bus[0].Addr.dt_lcp_pulse.eventbus[0]} {Bus[0].Addr.eventbus_encoded[3]}
{Bus[0].Addr.eventbus_encoded[2]} {Bus[0].Addr.eventbus_encoded[1]}
{Bus[0].Addr.eventbus_encoded[0]} {Bus[0].RWn} {Bus[0].Clk}
{Bus[0].Data[1]} {Bus[0].Data[0]}
{Bus[1].Addr.state_encoded[2]} {Bus[1].Addr.state_encoded[1]}
{Bus[1].Addr.state_encoded[0]} {Bus[1].Addr.dt_lcp_pulse.eventbus[2]}
{Bus[1].Addr.dt_lcp_pulse.eventbus[1]}
{Bus[1].Addr.dt_lcp_pulse.eventbus[0]} {Bus[1].Addr.eventbus_encoded[3]}
{Bus[1].Addr.eventbus_encoded[2]} {Bus[1].Addr.eventbus_encoded[1]}
{Bus[1].Addr.eventbus_encoded[0]} {Bus[1].RWn} {Bus[1].Clk}
{Bus[1].Data[1]} {Bus[1].Data[0]}

Example 2
The following commands return all root bundle ports of "top" module or sub bundle objects according to
name patterns used:
SETUP> set b [get_ports -of_modules top -bundle]

Bus i_clk

SETUP> get_ports Bus –bundle

Bus

SETUP> get_ports B* –bundle

Bus

SETUP> get_ports Bus* –bundle

Bus

SETUP> get_ports Bus[0].* –bundle

{Bus[0].Addr} {Bus[0].RWn} {Bus[0].Clk} {Bus[0].Data}

SETUP> get_ports Bus[0].Addr* –bundle

{Bus[0].Addr}

SETUP> get_ports Bus[0].Addr.* –bundle

{Bus[0].Addr.state_encoded} {Bus[0].Addr.dt_lcp_pulse.eventbus}
{Bus[0].Addr.eventbus_encoded}

SETUP> get_ports Bus[0].Addr.*

68 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Bundle Object Introspection Examples

{Bus[0].Addr.state_encoded[2]} {Bus[0].Addr.state_encoded[1]}
{Bus[0].Addr.state_encoded[0]} {Bus[0].Addr.dt_lcp_pulse.eventbus[2]}
{Bus[0].Addr.dt_lcp_pulse.eventbus[1]}
{Bus[0].Addr.dt_lcp_pulse.eventbus[0]} {Bus[0].Addr.eventbus_encoded[3]}
{Bus[0].Addr.eventbus_encoded[2]} {Bus[0].Addr.eventbus_encoded[1]}
{Bus[0].Addr.eventbus_encoded[0]}

SETUP> get_ports Bus[*] –bundle

{Bus[0]} {Bus[1]}

SETUP> get_ports Bus[*].* –bundle

{Bus[0].Addr} {Bus[0].RWn} {Bus[0].Clk} {Bus[0].Data} {Bus[1].Addr}

{Bus[1].RWn} {Bus[1].Clk} {Bus[1].Data}

SETUP> get_ports Bus[0]

{Bus[0].Addr.state_encoded[2]} {Bus[0].Addr.state_encoded[1]}
{Bus[0].Addr.state_encoded[0]} {Bus[0].Addr.dt_lcp_pulse.eventbus[2]}
{Bus[0].Addr.dt_lcp_pulse.eventbus[1]}
{Bus[0].Addr.dt_lcp_pulse.eventbus[0]} {Bus[0].Addr.eventbus_encoded[3]}
{Bus[0].Addr.eventbus_encoded[2]} {Bus[0].Addr.eventbus_encoded[1]}
{Bus[0].Addr.eventbus_encoded[0]} {Bus[0].RWn} {Bus[0].Clk}
{Bus[0].Data[1]} {Bus[0].Data[0]}

SETUP> set b1 [get_bundle_objects $b -children]

{Bus[0]} {Bus[1]}

SETUP> set b2 [get_bundle_objects [index_collection $b1 0] -children]

{Bus[0].Addr} {Bus[0].RWn} {Bus[0].Clk} {Bus[0].Data}

SETUP> get_bundle_objects –of_objects {Bus[0].Addr} –root

{Bus}

SETUP> get_bundle_objects –of_objects {Bus[0].Addr} –leaf

Bus[0].Addr.state_encoded[2]} {Bus[0].Addr.state_encoded[1]}
{Bus[0].Addr.state_encoded[0]} {Bus[0].Addr.dt_lcp_pulse.eventbus[2]}
{Bus[0].Addr.dt_lcp_pulse.eventbus[1]}
{Bus[0].Addr.dt_lcp_pulse.eventbus[0]} {Bus[0].Addr.eventbus_encoded[3]}
{Bus[0].Addr.eventbus_encoded[2]} {Bus[0].Addr.eventbus_encoded[1]}
{Bus[0].Addr.eventbus_encoded[0]}

SETUP> set b3 [get_bundle_objects [index_collection $b2 0] -children]

Tessent™ Shell User’s Manual 69

Design Introspection and Editing
Fan-in and Fanout Tracing of Complex Signals and Bundle Object Tracing

{Bus[0].Addr.state_encoded} {Bus[0].Addr.dt_lcp_pulse}
{Bus[0].Addr.eventbus_encoded}

SETUP> get_attribute_value_list [$b3] –name base_class

enum struct_packed 4-state_unsigned

SETUP> get_attribute_value_list [$b3] –name select_part_value_list

{0 Addr state_encoded} {0 Addr dt_lcp_pulse} {0 Addr eventbus_encoded}

SETUP> get_ports {Bus[0].Clk} -bundle

{Bus[0].Clk}

SETUP> get_ports {Bus[0].Addr.state_encoded}

{Bus[0].Addr.state_encoded[2]} {Bus[0].Addr.state_encoded[1]}
{Bus[0].Addr.state_encoded[0]}

SETUP> get_bundle_objects -of_objects {Bus[0].Addr.state_encoded} -parent

{Bus[0].Addr}

SETUP> get_bundle_objects -of_objects {Bus[0].Addr} -parent

{Bus[0]}

SETUP> get_bundle_objects -of_objects {Bus[0]} -parent

{Bus}

SETUP> get_bundle_objects -of_objects {Bus} -parent

{}

Fan-in and Fanout Tracing of Complex Signals and

Bundle Object Tracing
Using Tessent Shell, you can introspect and trace any kind of signals (simple and complex) through their
fan-ins and fanouts. It is also possible to trace through bundle objects.
The get_fanins/get_fanouts commands accept any kind of objects as input, bundle or not, and with simple
types or complex types. The ending and intermediate nodes can also be an object or complex type. For
example, they can trace from and to, and through any kind of complex signals in SystemVerilog (SV) and
VHDL.

70 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Fan-in and Fanout Tracing of Complex Signals and Bundle Object Tracing

• get_fanins

• get_fanouts
The following shows a top-level RTL module (top1.sv) with SV Interface objects. The tool models SV
Interfaces as a named bundle of wires. Within the tool, those are considered as normal bundle ports, pins,
and nets. You access the bundle object using the get_nets, get_pins, and get_ports commands.

module top (clk, reset, ce, we, addr, datai, datao, cnto, datao2, en);

localparam WID = 8;
localparam AWID = 5;
localparam LEN = 2**AWID;
localparam GEN = 3;

input en;
input clk, reset, ce, we;
input [AWID-1:0] addr;
input [WID-1:0] datai;
output [GEN*12-1:0] datao, datao2;
output [GEN*WID-1:0] cnto;

and enAnd2 (resetEn, reset, en);

and enAnd3 (weEn, we, en);
and enAnd4 (ceEn, ce, en);

param_mem_if miff(
.clk(clk),
.reset(resetEn),
.we(weEn),
.ce(ceEn),
.dati(datai),
.addr(addr),
.dato(datao)
);

genvar i;

generate
for (i=0; i<GEN; i++) begin: gen_mem
SYNC_1RW_16x8 mem1 (.CLK(clk), .D(datai), .Q(datao2[(WID*(i+1)
-1):i*WID]), .WE(we), .OE(ce), .RE(ce), .A(addr[3:0]));
end
endgenerate

generate
for (i=0; i<GEN; i++) begin: gen_mem_wrapper

param_mem mem_inst (.mif(miff));

end
endgenerate
generate
for (i=0; i<GEN; i++) begin: gen_cnt

Tessent™ Shell User’s Manual 71

Design Introspection and Editing
Fan-in and Fanout Tracing of Complex Signals and Bundle Object Tracing
param_counter #(.WID(WID)) counter_inst (
.clk(clk),
.reset(reset),
.enable(ce&we),
.count(cnto[(WID*(i+1)-1):i*WID]));
end
endgenerate
endmodule

The following shows an example command sequence to introspect the fan-ins and fanouts in this design:
SETUP> set_context dft -rtl
SETUP> read_cell_library my_cell_library.lib
SETUP> set_design_sources -format verilog -y {verilog_source_directory} -ext {v}
SETUP> set_design_sources -format tcd_memory -y {verilog_source_directory} \
-ext {lvlib lib}
SETUP> read_verilog param_mem.sv -format sv2009
SETUP> read_verilog param_counter.sv -format sv2009
SETUP> read_verilog top1.sv -format sv2009
SETUP> set_current_design top
SETUP> set_design_level physical_block
SETUP> add_input_constraints en -C1
SETUP> puts [join [get_attribute_value_list \
[get_fanins gen_mem_wrapper[0].mem_inst/mem1/CLK ] -name name] "\n"]

clk

Here, from SV Interface sub bundle pins, the tool reaches the output pin of primitive. (Continuing from the
previous example.)
SETUP> puts [join [get_name_list \
[get_fanouts gen_mem_wrapper[2].mem_inst/mif.ce ]] "\n"]

enAnd4/OUT

SETUP> puts [join [get_name_list \

[get_fanouts gen_mem_wrapper[2].mem_inst/mif.ce ] -name name] "\n"]

gen_mem_wrapper[2].mem_inst/mem1/OE
gen_mem_wrapper[2].mem_inst/mem1/RE
gen_mem_wrapper[2].mem_inst/mem2/OE
gen_mem_wrapper[2].mem_inst/mem2/RE

Here, from SV Interface sub bundle pins, the tool reaches the SV interface sub bundle net "miff.ce".
(Continuing with the previous example.)
SETUP> puts [join [get_name_list \
[get_fanins gen_mem_wrapper[2].mem_inst/mif.ce -stop_on net] \
-name name] "\n"]

miff.ce

SETUP> puts [join [get_name_list \

[get_fanouts gen_mem_wrapper[2].mem_inst/mif.ce -stop_on net] -name name] "\n"]

72 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Connectivity Through Complex Signals

gen_mem_wrapper[2].mem_inst/mif.ce

Additional Examples
The following command sequence shows introspection of bundle objects through both fan-ins and
fanouts, as well as ports and pins:
SETUP> set bitblasted_port [get_ports jack]
SETUP> set bitblasted_conn [get_fanouts $bitblasted port]
SETUP> puts [join [get_name_list $bitblasted_conn] "\n"]

i1/jim[2]
i2/jim[1]
i1/jim[1]
i1/joe[2]
i1/jim[0]
i2/joe[2]

SETUP> set bundle_port [get_ports jack -bundle]

SETUP> set bundle_conn [get_fanouts $bundle_port]
SETUP> puts [join [get_name_list $bundle_conn] "\n"]

i1/jim

SETUP> set bitblasted_pin [get_pins i1/jim]

SETUP> set bitblasted_conn [get_fanins $bitblasted_pin]
SETUP> puts [join [get_name_list $bitblasted_conn] "\n"]

jack[2]
jack[1]
jack[0]

SETUP> set bundle_pin [get_pins i1/jim -bundle]

SETUP> set conn [get_fanins $bundle_pin]
SETUP> puts [join [get_name_list $bundle_conn] "\n"]

jack

Connectivity Through Complex Signals

Tessent Shell traces and reports on the connectivity of complex signals defined at RTL without
synthesizing every module.
The get_fanins/get_fanouts commands can report the connectivity through complex signals such as RTL
pins and nets on the hierarchical design view. The trace_flat_model command can report on a flat model.
The tool performs quick synthesis on the module only if it finds RTL logic that represents logic gates
while performing path pre-tracing. The tool maintains the RTL view and the connectivity to and from
the surrounding modules, even if a module with a SystemVerilog interface requires quick synthesis.
This limits the number of RTL modules synthesized to perform a pre-DFT DRC for MemoryBIST and to
perform ICL extraction.

Tessent™ Shell User’s Manual 73

Design Introspection and Editing
Connectivity Through Complex Signals

When Tessent Shell flattens the design, only the leaf objects of complex signals are translated to gate
pins using the post synthesis names (refer to the post_synthesis_name attribute on the Port, port_bundle,
Pin, pin_bundle, Net, and net_bundle object types for more information).
For objects found inside unsynthesized modules, the hierarchical design objects uses the pre-synthesis
names (refer to the pre_synthesis_name attribute on the Port, port_bundle, Pin, pin_bundle, Net, and
net_bundle object types for more information).
However, the tool always uses the post-synthesis name of the leaf objects of complex signals for gate pin
objects in the flat model, whether it synthesizes the modules or not.
The tool provides several switches on the introspection commands to simplify the introspection between
the hierarchical design objects and the flat model gate_pin objects. With complex signals, you cannot
assume the two objects have the same name.

• get_gate_pins -of_pins pin_objects | -of_ports port_objects |-of_nets net_objects

• get_nets [name_patterns] -of_gate_pins gate_pin_objects

• get_pins [name_patterns] -of_gate_pins gate_pin_objects

• get_ports [name_patterns] -of_gate_pins gate_pin_objects

The following example demonstrates loading an RTL design and performing tracing on the hierarchical
data module using the get_fanins command. It also shows creating and tracing the flat model using the
trace_flat_model command:
SETUP> set_context dft -rtl
SETUP> read_cell_library my_cell_library.lib
SETUP> open_tsdb InternalCore_tsdb
SETUP> read_design InternalCore -design_id rtl
SETUP> read_verilog RTL_Directory/Interfaces.sv -format sv2009
SETUP> read_verilog RTL_Directory/Core.sv -format sv2009
SETUP> set_current_design core
SETUP> set_design_level physical_block
SETUP> puts [get_name_list [get_fanins genloop[2].icw0/ic/OutBus[1]]]

{InBus[1]}

SETUP> create_flat_model
// Flattening process completed, gates=79, PIs=12, POs=13, CPU time=0.00 sec.
// ---------------------------------------------------------------------------
// Begin circuit learning analyses.
// --------------------------------
// Learning completed, CPU time=0.00 sec.

SETUP> puts [get_name_list [trace_flat_model -from [get_gate_pins -of_pins \

[get_pins genloop[2].icw0/ic/OutBus[1]]] -direction backward \
-controllability connected]]

{InBus[1]}

This example shows the use of the get_gate_pins -of_pin and get_pins ‑of_gate_pins to illustrate that the
matching objects do not have the same name:
SETUP> get_gate_pins -of_pins [get_pins genloop[2].icw0/ic/OutBus[1]]

74 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Connectivity Through Complex Signals

{{\genloop[2].icw0 /ic/OutBus[1]}}

SETUP> get_gate_pins -of_pins genloop[2].icw0/ic/OutBus[1]

{{\genloop[2].icw0 /ic/OutBus[1]}}

SETUP> get_pins -of_gate_pins {{\genloop[2].icw0 /ic/OutBus[1]}}

{genloop[2].icw0/ic/OutBus[1]}

SETUP> get_pins -of_gate_pins [get_gate_pins {{\genloop[2].icw0 /ic/OutBus[1]}}]

{genloop[2].icw0/ic/OutBus[1]}

Tessent Visualizer Tracing and Visualization

Tessent Visualizer provides a platform to trace and visualize bundle objects in the flat model. The Tessent
Visualizer GUI shows the post_synthesis_name of the ports and pins even when the RTL view of the
module is active. When you switch to the synthesized view of a module, its footprint remains unchanged
in Tessent Visualizer. The RTL logic that is not shown in the RTL view becomes logic cell instances in the
synthesized view.

Figure 3. Complex Signals With Tessent Visualizer

Tessent Visualizer facilitates cross-probing pins in the schematic to their associated RTL netlist.

Tessent™ Shell User’s Manual 75

Design Introspection and Editing
Connectivity Through Complex Signals

For complete information on using Tessent Visualizer, refer to “Tessent Visualizer” on page 831.

76 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Design Editing

Design Editing
Tessent Shell design editing commands enable you to modify your design after reading in the RTL or
gate-level netlist. Tessent Shell supports gate-level netlist editing or RTL design editing with full language
support, including multiple logical libraries, VHDL, Verilog, and SystemVerilog. Parameterized modules
are also fully supported.
The design editing commands enable you to manipulate a design’s modules, instances, nets, ports, and
pins, either interactively or through Tcl scripting.

Note:
Refer to HDL Limitations in the Tessent Shell Flow in the Tessent Shell Reference Manual for
language restrictions and limitations. The design editing commands are not available when using
some product licenses, such as Tessent FastScan and Tessent Scan.

Design editing commands work with collections and introspection commands, as well as native Tcl
commands, to automate many tasks. Table 12 presents the common design editing commands based on
the function they perform— that is, whether they create, modify, or remove elements and so on. For more
information on collections and introspection commands, refer to Design Introspection.

CAUTION:
Take special care when dealing with non-unique design scopes, such as multiple instances of
the same module or the inner part of a generate loop. Refer to Example of Handling Non‑Unique
Design Scopes within “Design Editing Examples” on page 109 for details.

Table 12. Design Editing Commands

Commands that... Command Name

Read netlists and specify logical libraries read_verilog

read_vhdl

set_logical_design_libraries

Create design elements create_connections

create_instance

create_module

create_net

create_pin

create_port

Remove design elements delete_connections

delete_instances

Tessent™ Shell User’s Manual 77

Design Introspection and Editing
Design Editing Command Summary

Table 12. Design Editing Commands (continued)

Commands that... Command Name

delete_nets

delete_pins

delete_ports

Modify the design copy_module

intercept_connection

replace_instances

set_current_design

uniquify_instances

Set or get editing options get_insertion_option

uniquify_instances

Design Editing Command Summary

Editing Complex Signals
Design Editing Examples

Design Editing Command Summary

The design editing commands enable you to work with modules, connections, instances, nets, pins, and
ports.
The commands listed in the following table are commonly used design editing commands. Refer to the
Tessent Shell Reference Manual for more information.

Table 13. Design Editing Command Summary

Command Name Description

copy_module Creates an exact copy of a design module and gives it a new name,
which the tool can use as part of create_instance and replace_instances
operations.

create_connections Creates a connection between pin, net, or port objects.

create_instance Instantiates a module (design or cell type) inside of a design module that
is part of the current design.

create_module Creates a new design module.

create_net Creates a net inside an instance of a design module.

create_pin Creates a pin on an instance of a design module.

78 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Design Editing Command Summary

Table 13. Design Editing Command Summary (continued)

Command Name Description

create_port Creates a port on a design module.

delete_connections Disconnects the specified pin objects.

delete_instances Removes an instance of a module.

delete_nets Removes net objects inside an instance of a design module.

delete_pins Removes pin objects on an instance of a design module.

delete_ports Removes port objects on a design module.

get_insertion_option Introspects the default values of options affecting many design editing
commands.

intercept_connection Using the get_dft_cell command, obtains a cell with the specified function
name and uses it to intercept a connection to a pin, port, or net.

move_connections Moves a net connected on one pin or port to another pin or port. The first
pin is left open after the move.

rename_instance Renames the leaf name of an instance object.

replace_instances Replaces the module object used in an instantiation.

set_insertion_options Specifies default values of options affecting many design editing

commands.

uniquify_instances If the module of the specified instance has other instantiations in the
design, the tool copies the module and the specified instance becomes an
instance of the copied module.

Tessent™ Shell User’s Manual 79

Design Introspection and Editing
Editing Complex Signals

Editing Complex Signals

You can edit complex ports and pins with the DftSpecification wrapper, and you can edit complex ports,
pins, and nets with the Tessent Shell commands.
Complex signals include the following:

• Leaf/bundle ports, pins, or nets

• SystemVerilog interfaces with and without modports

• Multi-dimensional packed/unpacked arrays

• Objects of the following types:

◦ Packed/unpacked struct

◦ Packed union

◦ Enum

Editing Complex Signals With the DftSpecification Wrapper

Editing Complex Verilog and SystemVerilog Signals With Tessent Shell Commands

Editing Complex Signals With the DftSpecification

Wrapper
Specify the complete RTL names of complex ports and pins using the DftSpecification wrapper.

Overview
Create the DftSpecification wrapper object with the create_dft_specification command and customize it
with configuration data editing commands. After you have finished modifying the DftSpecification, perform
DFT insertion with the process_dft_specification command. You can make connections between pins and
ports with complex types to other pins and ports with complex types, move these connections, and delete
these connections.
Load the DftSpecification either before or after quick synthesis. You can use the full names of complex
ports and pins regardless of whether the current views are quick-synthesized.

Examples
When processing a DftSpecification on the RTL view of a design, you can use bundle ports and pins to
define the DFT signals:

typedef struct packed {

logic [3:0] in;
logic [1:0] out;
} EDT_t;

80 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Editing Complex Signals With the DftSpecification Wrapper
input EDT_t edt_channel;

EdtChannelsIn(8:5) {
port_int_name : edt_channel.in;
}

When processing a DftSpecification on the quick-synthesized view of a design, you can specify port and
pin RTL names as bit-blasted:

EdtChannelsIn(8:5) {
port_pin_name : edt_channel.in[3], edt_channel.in[2], \
edt_channel.in[1], edt_channel.in[0];
}

You can also specify port and pin RTL names as slices:

EdtChannelsIn(8:5) {
port_pin_name : edt_channel.in[3:0];
}

Related Topics
Configuration-Based Specification

DftSpecification Configuration Syntax

create_dft_specification

process_dft_specification

Editing Complex Verilog and SystemVerilog Signals With Tessent Shell Commands

Tessent™ Shell User’s Manual 81

Design Introspection and Editing
Editing Complex Verilog and SystemVerilog Signals With Tessent Shell Commands

Editing Complex Verilog and SystemVerilog Signals With

Tessent Shell Commands
Tessent Shell enables you to edit complex ports, pins, and nets from the command line.
Complex signals include the following:

• Leaf/bundle ports, pins, or nets

• SystemVerilog interfaces with and without modports

• Multi-dimensional packed/unpacked arrays

• Objects of the following types:

◦ Packed/unpacked struct

◦ Packed union

◦ Enum

Table 14. Commands for Editing Complex Ports, Pins, and Nets

Command Enhancement

create_connections Accepts source and sink as complex ports, pins, or nets.

delete_connections Accepts complex ports, pins, or nets as arguments.

move_connections Accepts complex ports, pins, or nets for the ‑from and ‑to arguments.

get_instances Returns the equivalent quick-synthesized objects from the complete RTL
instance name.

get_pins Returns the equivalent quick-synthesized objects from the complete RTL
names of complex ports and pins (including the instance path).

get_ports Returns the equivalent quick-synthesized objects from the complete RTL
names of complex ports and pins (including the instance path).

replace_instances Specifies new parameter values for SystemVerilog interface parameters.

set_current_design Overrides the parameters of SystemVerliog interface ports.

Examples Using the create_connections Command With Complex Signals

Examples Using the delete_connections Command With Complex Signals
Examples Using the move_connections Command With Complex Signals
Examples Using the replace_instances Command With Complex Signals

82 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Examples Using the create_connections Command With Complex Signals
Related Topics
Editing Complex Signals With the DftSpecification Wrapper

Design Introspection Examples

HDL Limitations in the Tessent Shell Flow [Tessent Shell Reference Manual]

Examples Using the create_connections Command With

Complex Signals
This section provides examples of creating connections between complex signals.
For more information about the create_connections command, including the complete usage, refer to the
Tessent Shell Reference Manual. The following examples show how to use the command with complex
signals:

Data Types and Interfaces for Complex Signal Examples

The complex signal examples use the following data types:

package pack1;
typedef struct packed {
bit clk;
logic [1:0] data;
} struct_p;
typedef struct {
bit clk;
logic [1:0] data;
} struct_u;
typedef union packed {
struct_p data1;
logic [2:0] data2;
} union_p;
typedef enum {off, ready, running} states;
endpackage
package pack2;
import pack1::*;
// 2D packed array of packed struct
typedef struct_p [3:0][2:0] p_array_struct_p;
// compound unpacked array
typedef p_array_struct_p u_array [1:0];
// unpacked array of unpacked struct
typedef struct_u u_array_struct_u [1:0];
endpackage

The complex signal examples use the following interface:

Tessent™ Shell User’s Manual 83

Design Introspection and Editing
Examples Using the create_connections Command With Complex Signals

interface intf1;
logic tx_rx1;
logic tx_rx2;
modport usage1 ( input tx_rx1, output tx_rx2 );
modport usage2 ( input tx_rx2, output tx_rx1 );
endinterface

Example 1: Unpacked Struct Type

This example creates connections between pins of unpacked struct type by linking bundle objects. The
following RTL describes the original design:

module top;
mod1 i1 ();
mod2 i2 ();
endmodule

module mod1( input pack2::u_array_struct_u p1_struct );

endmodule

module mod2(output pack2::u_array_struct_u p1_struct );

endmodule

The following diagram shows the original design:

Figure 4. Original Design Before Creating Connections

Run the create_connections command in insertion mode to connect the pins using bundle objects:
INSERTION> create_connections [get_pins i1/p1_struct -bundle] \
[get_pins i2/p1_struct -bundle]

The tool modifies the RTL in memory as follows:

module top;
wire [5:0] p1_struct;
pack2::u_array_struct_u p1_struct_ts1, p1_struct_ts2;
mod1 i1 (.p1_struct(p1_struct_ts1));
mod2 i2 (.p1_struct(p1_struct_ts2));
assign p1_struct_ts1 = '{'{p1_struct[5], p1_struct[4:3]},

84 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Examples Using the create_connections Command With Complex Signals
'{p1_struct[2], p1_struct[1:0]}};
assign p1_struct = {p1_struct_ts2[1].clk, p1_struct_ts2[1].data,
p1_struct_ts2[0].clk, p1_struct_ts2[0].data};
endmodule

The following diagram shows the modified design with the new connection in teal:

Figure 5. Modified Design After Creating Connections

Example 2: Packed Union Type

This example creates connections between pins of the packed union type. The following RTL describes
the original design:

module top;
mod1 i1 ();
mod2 i2 ();
endmodule

import pack1::*;
module mod1( input union_p p1_union );
endmodule // mod1

module mod2( output union_p p1_union );

endmodule // mod2

Run the create_connections command in insertion mode to connect the pins of the union type:
INSERTION> create_connections i1/p1_union.data1 i2/p1_union.data2

The tool modifies the RTL in memory as follows:

module top;
wire [2:0] p1_union;
mod1 i1 (.p1_union(p1_union));
mod2 i2 (.p1_union(p1_union));
endmodule

Example 3: Packed Array of Packed Struct Type

This example creates connections between pin sub-bundles. The following RTL describes the original
design:

Tessent™ Shell User’s Manual 85

Design Introspection and Editing
Examples Using the create_connections Command With Complex Signals

module top;
mod1 i1 ();
mod2 i2 ();
endmodule

module mod1( input pack2::p_array_struct_p p1_struct );

endmodule // mod1

module mod2( output pack2::p_array_struct_p p1_struct );

endmodule // mod2

Run the create_connections command in insertion mode to connect the pin sub-bundles:
INSERTION> create_connections i1/p1_struct[3][2].data i2/p1_struct[3][2].data

The tool modifies the RTL in memory as follows:

module top;
logic p1_struct;
logic p1_struct_ts1;
wire tessent_filler_net_ts1, tessent_filler_net_ts3;
wire [32:0] tessent_filler_net, tessent_filler_net_ts2;
mod1 i1 (.p1_struct({tessent_filler_net_ts1, p1_struct_ts1, p1_struct,
tessent_filler_net[32:30], tessent_filler_net[29:27],
tessent_filler_net[26:0]}));
mod2 i2 (.p1_struct({tessent_filler_net_ts3, p1_struct_ts1,
p1_struct,tessent_filler_net_ts2[32:30],
tessent_filler_net_ts2[29:27],tessent_filler_net_ts2[26:0]}));
endmodule

Example 4: Packed Array of Packed Struct Type

This example creates connections between an input pin sub-bundle and an output pin sub-bundle. The
output pin sub-bundle has existing fanout. The following RTL describes the original design:

module top;
pack2::p_array_struct_p n1_struct;
wire [33:0] filler_net;
mod1 i1 ();
mod2 i2 (.p1_struct(n1_struct));
mod3 i3 (.p1_struct({filler_net[33], n1_struct[3][2].data,
filler_net[32:0]}));
logic [1:0] data;
always_ff @(posedge n1_struct[3][2].clk) begin
data <= n1_struct[3][2].data;
end
endmodule

module mod1( input pack2::p_array_struct_p p1_struct );

endmodule // mod1

module mod2( output pack2::p_array_struct_p p1_struct );

endmodule // mod2

86 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Examples Using the create_connections Command With Complex Signals

module mod3( input pack2::p_array_struct_p p1_struct );

endmodule // mod3

Run the create_connections command in insertion mode to connect the input sub-bundle to the output
sub-bundle:
INSERTION> create_connections i1/p1_struct[3][2].data i2/p1_struct[3][2].data

The tool modifies the RTL in memory as follows:

module top;
pack2::p_array_struct_p n1_struct;
wire [33:0] filler_net;
wire tessent_filler_net_ts1;
wire [32:0] tessent_filler_net;
mod1 i1 (.p1_struct({tessent_filler_net_ts1, n1_struct[3][2].data,
tessent_filler_net[32:30], tessent_filler_net[29:27],
tessent_filler_net[26:0]}));
mod2 i2 (.p1_struct(n1_struct));
mod3 i3 (.p1_struct({filler_net[33], n1_struct[3][2].data,
filler_net[32:0]}));
logic [1:0] data;
always_ff @(posedge n1_struct[3][2].clk) begin
data <= n1_struct[3][2].data;
end
endmodule

Example 5: Unpacked Array of Unpacked Struct Type

This example creates connections between pin leaves. The following RTL describes the original design:

module top;
mod1 i1 ();
mod2 i2 ();
endmodule

module mod1( input pack2::u_array_struct_u p1_struct );

endmodule

module mod2( output pack2::u_array_struct_u p1_struct );

endmodule

Run the create_connections command in insertion mode to connects pin leaves:

INSERTION> create_connections i1/p1_struct[1].clk i2/p1_struct[1].clk

The tool modifies the RTL in memory as follows:

module top;
bit p1_struct;
pack2::u_array_struct_u tessent_internal_net, tessent_internal_net_ts1;
wire [4:0] tessent_filler_net, tessent_filler_net_ts1;
mod1 i1 (.p1_struct(tessent_internal_net));

Tessent™ Shell User’s Manual 87

Design Introspection and Editing
Examples Using the create_connections Command With Complex Signals
mod2 i2 (.p1_struct(tessent_internal_net_ts1));
assign tessent_internal_net = '{'{p1_struct, tessent_filler_net[4:3]},
'{tessent_filler_net[2], tessent_filler_net[1:0]}};
assign {p1_struct, tessent_filler_net_ts1} =
{tessent_internal_net_ts1[1].clk, tessent_internal_net_ts1[1].data,
tessent_internal_net_ts1[0].clk, tessent_internal_net_ts1[0].data};
endmodule

Example 6: Unpacked Array of Unpacked Struct Type

This example creates connections between an input pin leaf and an output pin leaf. The output pin leaf
has existing fanout. The modification adds additional fanout to the output pin leaf.
The original RTL for this example is as follows:

module top;
pack2::u_array_struct_u n1_struct;
wire [4:0] filler_net;
mod1 i1 ();
mod2 i2 (.p1_struct(n1_struct));
mod3 i3 (.p1_struct('{'{n1_struct[1].clk, filler_net[4:3]},
'{filler_net[2], filler_net[1:0]}}));
bit clk;
always_ff @(posedge n1_struct[1].clk) begin
clk <= n1_struct[1].clk;
end
endmodule

module mod1( input pack2::u_array_struct_u p1_struct );

endmodule // mod1

module mod2( output pack2::u_array_struct_u p1_struct );

endmodule // mod2

module mod3( input pack2::u_array_struct_u p1_struct );

endmodule // mod3

Run the create_connections command in insertion mode as follows to add fanout to the output pin leaf:
INSERTION> create_connections i1/p1_struct[1].clk i2/p1_struct[1].clk

The modified RTL is as follows:

module top;
pack2::u_array_struct_u n1_struct;
wire [4:0] filler_net;
pack2::u_array_struct_u tessent_internal_net;
wire [4:0] tessent_filler_net;
mod1 i1 (.p1_struct(tessent_internal_net));
mod2 i2 (.p1_struct(n1_struct));
mod3 i3 (.p1_struct('{'{n1_struct[1].clk, filler_net[4:3]},
'{filler_net[2], filler_net[1:0]}}));
bit clk;
always_ff @(posedge n1_struct[1].clk) begin

88 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Examples Using the create_connections Command With Complex Signals
clk <= n1_struct[1].clk;
end
assign tessent_internal_net = '{'{n1_struct[1].clk,
tessent_filler_net[4:3]}, '{tessent_filler_net[2],
tessent_filler_net[1:0]}};
endmodule

Example 7: Unpacked Array of Unpacked Struct Type

This example connects an output pin to a net that is declared using a nested, locally declared typedef
whose inner typedef is declared in a package.
The following RTL describes the original design:

import pack1::*;
module mod1;
// unpacked array of unpacked struct
// inner type is in pack1;
// outer type is declared locally
typedef struct_u u_array_struct_u [1:0];
u_array_struct_u n1;
submod1 i1 ();
endmodule // mod1

module submod1( output pack2::u_array_struct_u p1 );

assign p1 = '{'{1'b1,2'b1},'{1'b1,2'b1}};
endmodule // submod1

Run the create_connections command in insertion mode as follows to connect the output pin to the net:
INSERTION> create_connections n1 i1/p1

The tool modifies the RTL in memory as follows:

import pack1::*;
module mod1;
typedef struct_u u_array_struct_u [1:0];
u_array_struct_u n1;
submod1 i1 (.p1(n1));
endmodule

module submod1( output pack2::u_array_struct_u p1 );

assign p1 = '{'{1'b1,2'b1},'{1'b1,2'b1}};
endmodule // submod1

Example 8: Enumerated Type

This example connects an input pin declared as an enum to an input pin on a child instance declared as
an enum.
The following RTL describes the original design:

Tessent™ Shell User’s Manual 89

Design Introspection and Editing
Examples Using the create_connections Command With Complex Signals

module top;
mod1 i1( .p1_enum(pack1::running));
endmodule

import pack1::*;
module mod1( input states p1_enum );
submod1 i1 ();
endmodule // mod1

module submod1( input states p1 );

endmodule // submod1

Run the create_connections command in insertion mode as follows to connect the pins:
INSERTION> create_connections i1/p1_enum i1/i1/p1

The tool modifies the RTL in memory as follows:

module top;
wire [31:0] p1_enum;
mod1 i1( .p1_enum(pack1::states'(p1_enum)));
assign p1_enum = 32'b00000000000000000000000000000010;
endmodule
import pack1::*;

module mod1( input states p1_enum );

submod1 i1 (.p1(p1_enum));
endmodule // mod1

module submod1( input states p1 );

endmodule // submod1

Example 9: Enumerated Type

The following example connects an input pin declared as an enum to an input pin on a child instance
declared as an enum. The connections are performed bit by bit.
The following RTL describes the original design:

module top;
mod1 i1( .p1_enum(pack1::running));
endmodule

import pack1::*;
module mod1( input states p1_enum );
submod1 i1();
endmodule // mod1

module submod1( input states p1 );

endmodule // submod1

Run the create_connections command in insertion mode as follows to connect the pins bit by bit:

90 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Examples Using the create_connections Command With Complex Signals

INSERTION> create_connections i1/p1_enum[1] i1/i1/p1[1]

INSERTION> create_connections i1/p1_enum[0] i1/i1/p1[0]

The tool modifies the RTL in memory as follows:

module top;
wire p1_enum, p1_enum_ts1;
mod1 i1( .p1_enum(pack1::states'({30'b000000000000000000000000000000,
p1_enum, p1_enum_ts1})));
assign p1_enum = 1'b1;
assign p1_enum_ts1 = 1'b0;
endmodule
import pack1::*;

module mod1( input states p1_enum );

wire [29:0] tessent_filler_net;
submod1 i1 (.p1(pack1::states'({tessent_filler_net, p1_enum[1:0]})));
endmodule // mod1

module submod1( input states p1 );

endmodule // submod1

Example 10: Enumerated and Int Types

This example connects an input pin declared as an enum to an input pin on a child instance declared as
an int.
The following RTL describes the original design:

module top;
mod1 i1( .p1_enum(pack1::running));
endmodule

import pack1::*;
module mod1( input states p1_enum );
submod1 i1();
endmodule // mod1

module submod1( input int p1 );

endmodule // submod1

Run the create_connections command in insertion mode as follows to connect the pins:
INSERTION> create_connections i1/p1_enum i1/i1/p1

The tool modifies the RTL in memory as follows:

module top;
wire [31:0] p1_enum;
mod1 i1( .p1_enum(pack1::states'(p1_enum)));
assign p1_enum = 32'b00000000000000000000000000000010;
endmodule
import pack1::*;

Tessent™ Shell User’s Manual 91

Design Introspection and Editing
Examples Using the create_connections Command With Complex Signals
module mod1( input states p1_enum );
wire [31:0] p1_enum_ts1;
submod1 i1(.p1(p1_enum_ts1));
assign p1_enum_ts1 = p1_enum;
endmodule // mod1

module submod1( input int p1 );

endmodule // submod1

Example 11: Enumerated and Int Types

This example connects an output pin declared as an enum to an output pin on a child instance declared
as an int. Editing provides the necessary cast to the enum type.
The following RTL describes the original design:

module top;
mod2 i1 ();
endmodule // top

import pack1::*;

module mod2( output states p1_enum );

submod1 i1 ();
endmodule // mod2

module submod1( output int p1 );

assign p1 = 2'b10;
endmodule // submod1

Run the create_connections command in insertion mode as follows:

INSERTION> create_connections i1/p1_enum i1/i1/p1

The modified RTL is as follows:

module top;
mod2 i1 ();
endmodule // top

import pack1::*;

module mod2( output states p1_enum );

wire [31:0] p1_enum_ts1;
submod1 i1 (.p1(p1_enum_ts1));
assign p1_enum = pack1::states'(p1_enum_ts1);
endmodule // mod2

module submod1( output int p1 );

assign p1 = 2'b10;
endmodule // submod1

92 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Examples Using the create_connections Command With Complex Signals

Example 12: Packed Struct and Unpacked Struct Types

This example connects a pin bundle sink declared as packed struct to a pin bundle driver declared as an
unpacked struct.
The following RTL describes the original design:

module top;
mod1 i1 ();
mod2 i2 ();
endmodule

module mod1( input pack2::p_array_struct_p p1_struct );

endmodule // mod1

module mod2( output pack2::u_array_struct_u p1_struct );

endmodule // mod2

Run the create_connections command in insertion mode as follows to connect the pin bundles:
INSERTION> create_connections i1/p1_struct[3][2] i2/p1_struct[1]

The modified RTL is as follows:

module top;
logic p1_struct;
logic p1_struct_ts1;
bit p1_struct_ts2;
wire [32:0] tessent_filler_net;
pack2::u_array_struct_u tessent_internal_net;
wire [2:0] tessent_filler_net_ts1;
mod1 i1 (.p1_struct({p1_struct_ts2, p1_struct_ts1, p1_struct,
tessent_filler_net[32:30], tessent_filler_net[29:27],
tessent_filler_net[26:0]}));
mod2 i2 (.p1_struct(tessent_internal_net));
assign {p1_struct_ts2, p1_struct_ts1, p1_struct,
tessent_filler_net_ts1} = {tessent_internal_net[1].clk,
tessent_internal_net[1].data, tessent_internal_net[0].clk,
tessent_internal_net[0].data};
endmodule

module mod1( input pack2::p_array_struct_p p1_struct );

endmodule // mod1

module mod2( output pack2::u_array_struct_u p1_struct );

endmodule // mod2

Example 13: Packed Struct and Unpacked Struct Types

This example connects a pin bundle sink declared as an unpacked struct to a pin bundle driver declared
as a packed struct.
The following RTL describes the original design:

Tessent™ Shell User’s Manual 93

Design Introspection and Editing
Examples Using the create_connections Command With Complex Signals

module top;
mod1 i1 ();
mod2 i2 ();
endmodule

module mod1( input pack2::u_array_struct_u p1_struct );

endmodule // mod1

module mod2( output pack2::p_array_struct_p p1_struct );

endmodule // mod2

Run the create_connections command in insertion mode as follows to connect the pin bundles:
INSERTION> create_connections i1/p1_struct[1] i2/p1_struct[3][2]

The modified RTL is as follows:

module top;
logic p1_struct;
logic p1_struct_ts1;
bit p1_struct_ts2;
pack2::u_array_struct_u tessent_internal_net;
wire [32:0] tessent_filler_net;
wire [2:0] tessent_filler_net_ts1;
mod1 i1 (.p1_struct(tessent_internal_net));
mod2 i2 (.p1_struct({p1_struct_ts2, p1_struct_ts1, p1_struct,
tessent_filler_net[32:30], tessent_filler_net[29:27],
tessent_filler_net[26:0]}));
assign tessent_internal_net = '{'{p1_struct_ts2, {p1_struct_ts1,
p1_struct}}, '{tessent_filler_net_ts1[2],
tessent_filler_net_ts1[1:0]}};
endmodule

Example 14: Modport Interface Type

This example connects a modport interface pin driver to a modport interface pin sink with the modports in
the module declarations.
The following RTL describes the original design:

module top;
intf1 n1 ();
intf1 n2 ();
mod1 i1 (.p1_intf(n1));
mod2 i2 (.p1_intf(n2));
endmodule

module mod1( intf1.usage1 p1_intf );

endmodule // mod1

module mod2( intf1.usage2 p1_intf );

endmodule // mod2

94 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Examples Using the create_connections Command With Complex Signals

Run the create_connections command in insertion mode as follows:

INSERTION> create_connections i1/p1_intf.tx_rx1 i2/p1_intf.tx_rx1

The modified RTL is as follows:

module top;
intf1 n1 ();
intf1 n2 ();
mod1 i1 (.p1_intf(n1));
mod2 i2 (.p1_intf(n2));
assign n1.tx_rx1 = n2.tx_rx1;
endmodule

Example 15: Modport Interface Type

This example connects a modport interface pin driver to a modport interface pin sink with the modports in
the module instantiations.
The following RTL describes the original design:

module top;
intf1 n1 ();
intf1 n2 ();
mod1 i1 (.p1_intf(n1.usage1));
mod2 i2 (.p1_intf(n2.usage2));
endmodule

module mod1( intf1 p1_intf );

endmodule // mod1

module mod2( intf1 p1_intf );

endmodule // mod2

Run the create_connections command in insertion mode as follows:

INSERTION> create_connections i1/p1_intf.tx_rx1 i2/p1_intf.tx_rx1

The modified RTL is as follows:

module top;
intf1 n1 ();
intf1 n2 ();
mod1 i1 (.p1_intf(n1.usage1));
mod2 i2 (.p1_intf(n2.usage2));
assign n1.tx_rx1 = n2.tx_rx1;
endmodule

Example 16: Generic Interface and Modport Interface Types

This example connects a generic interface pin driver to a modport interface pin sink.
The following RTL describes the original design:

Tessent™ Shell User’s Manual 95

Design Introspection and Editing
Examples Using the delete_connections Command With Complex Signals

module top;
intf1 n1 ();
intf1 n2 ();
mod1 i1 (.p1_intf(n1));
mod2 i2 (.p1_intf(n2.usage2));
endmodule // top

module mod1( intf1.usage1 p1_intf );

endmodule // mod1

module mod2( interface p1_intf );

endmodule // mod2

Run the create_connections command in insertion mode as follows:

INSERTION> create_connections i2/p1_intf.tx_rx1 i1/p1_intf.tx_rx1

The modified RTL is as follows:

module top;
intf1 n1 ();
intf1 n2 ();
mod1 i1 (.p1_intf(n1));
mod2 i2 (.p1_intf(n2.usage2));
assign n1.tx_rx1 = n2.tx_rx1;
endmodule // top

Related Topics
HDL Limitations in the Tessent Shell Flow [Tessent Shell Reference Manual]

Examples Using the delete_connections Command With Complex Signals

Examples Using the move_connections Command With Complex Signals

Examples Using the replace_instances Command With Complex Signals

Examples Using the delete_connections Command With Complex

Signals
This section provides examples of deleting complex signals.
For more information about the delete_connections command, including the complete usage, refer to the
Tessent Shell Reference Manual. The following examples show how to use the command with complex
signals:

Data Types and Interfaces for Complex Signal Examples

The complex signal examples use the following data types:

package pack1;
typedef struct packed {
bit clk;
logic [1:0] data;

96 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Examples Using the delete_connections Command With Complex Signals
} struct_p;
typedef struct {
bit clk;
logic [1:0] data;
} struct_u;
endpackage
package pack2;
import pack1::*;
// 2D packed array of packed struct
typedef struct_p [3:0][2:0] p_array_struct_p;
// compound unpacked array
typedef p_array_struct_p u_array [1:0];
// unpacked array of unpacked struct
typedef struct_u u_array_struct_u [1:0];
endpackage

The complex signal examples use the following interface:

interface intf1;
logic tx_rx1;
logic tx_rx2;
modport usage1 ( input tx_rx1, output tx_rx2 );
modport usage2 ( input tx_rx2, output tx_rx1 );
endinterface

Example 1: Packed Struct Type

This example disconnects the source of a bit of a pure net from its fanout. It is the same as in "Example
5" in the delete_connections command reference in the Tessent Shell Reference Manual but with the bits
of the clk_div_q and clk_div_d nets declared as "packed struct".
The original RTL for this example is as follows:

package pack1;
typedef struct packed {
logic clk_div_0;
logic [1:0] clk_div;
} clk_div_T;
endpackage

module top (input logic clk, input logic reset_h,

output pack1::clk_div_T clk_div_d, output logic phy_cr_clk_i,
output logic phy_cr_clk, output logic phy_cr_clk_f);
pack1::clk_div_T clk_div_q;
always_ff @(posedge clk) begin
if (reset_h == 1'b1) begin
clk_div_q <= 3'b00;
end
else begin
clk_div_q <= clk_div_d;
end
end
always_comb begin

Tessent™ Shell User’s Manual 97

Design Introspection and Editing
Examples Using the delete_connections Command With Complex Signals
clk_div_d = clk_div_q +1;
end
assign phy_cr_clk_i = clk_div_q.clk_div[1];
assign phy_cr_clk = clk_div_q.clk_div_0;
assign phy_cr_clk_f = clk_div_q.clk_div[0];
endmodule

Figure 6. Schematic of the Example Design Before Editing

Run the delete_connections command in insertion mode as follows to disconnect the bit:
INSERTION> delete_connections clk_div_q.clk_div_0 -net_name unconnected_clk_div

The tool modifies the RTL in memory as follows:

package pack1;
typedef struct packed {
logic clk_div_0;
logic [1:0] clk_div;
} clk_div_T;
endpackage

module top (input logic clk, input logic reset_h,

output pack1::clk_div_T clk_div_d, output logic phy_cr_clk_i,
output logic phy_cr_clk, output logic phy_cr_clk_f);
pack1::clk_div_T clk_div_q;
pack1::clk_div_T unconnected_clk_div;
always_ff @(posedge clk) begin
if ((reset_h==1'b1)) begin
unconnected_clk_div <= 3'b00;
end
else begin
unconnected_clk_div <= clk_div_d;
end
end

98 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Examples Using the delete_connections Command With Complex Signals
always_comb begin
clk_div_d = clk_div_q +1;
end
assign phy_cr_clk_i = clk_div_q.clk_div[1];
assign phy_cr_clk = clk_div_q.clk_div_0;
assign phy_cr_clk_f = clk_div_q.clk_div[0];
assign clk_div_q.clk_div = unconnected_clk_div.clk_div;
endmodule

Figure 7. Schematic of the Example Design After Editing

Example 2: Packed Array of Packed Struct Type

This example disconnects all bits of the input pin on the i1/p1_struct instance and the output pin on the
i2/p1_struct instance.
The following RTL describes the original design:

Tessent™ Shell User’s Manual 99

Design Introspection and Editing
Examples Using the delete_connections Command With Complex Signals

module top;
pack2::p_array_struct_p p1_struct;
mod1 i1 (.p1_struct(p1_struct));
mod2 i2 (.p1_struct(p1_struct));
endmodule; // top

module mod1( input pack2::p_array_struct_p p1_struct );

endmodule // mod1

module mod2( output pack2::p_array_struct_p p1_struct );

endmodule // mod2

This invocation of the delete_connections command in insertion mode disconnects the input pins:
INSERTION> delete_connections {i1/p1_struct i2/p1_struct}

The tool modifies the RTL in memory as follows:

module top;
pack2::p_array_struct_p p1_struct;
mod1 i1 (.p1_struct());
mod2 i2 (.p1_struct());
endmodule; // top

Example 3: Packed Array of Packed Struct Type

This example disconnects only specified sub-bundles of the input pin on the i1/p1_struct instance and the
output pin on the i2/p1_struct instance.
The original RTL is the same as in Example 2: Packed Array of Packed Struct Type.
Run the delete_connections command in insertion mode as follows to disconnect specific sub-bundles:
INSERTION> delete_connections {i1/p1_struct[3][2].data i2/p1_struct[3][2].data}

The tool modifies the RTL in memory as follows:

module top;
pack2::p_array_struct_p p1_struct;
logic [1:0] tessent_filler_net, tessent_filler_net_ts1;
mod1 i1 (.p1_struct({p1_struct[3][2].clk, tessent_filler_net,
p1_struct[3][1], p1_struct[3][0], p1_struct[2:0]}));
mod2 i2 (.p1_struct({p1_struct[3][2].clk, tessent_filler_net_ts1,
p1_struct[3][1], p1_struct[3][0], p1_struct[2:0]}));
endmodule; // top

Example 4: Modport Interface Type

This example disconnects the fanout of the p1_intf interface port.
The original RTL for this example is as follows:

100 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Examples Using the delete_connections Command With Complex Signals

module top( intf1.usage1 p1_intf, input bit clk );

logic data;
always_ff @(posedge clk) begin
data <= p1_intf.tx_rx1;
end
mod1 i1( .p1(p1_intf.tx_rx1) );
endmodule // top

module mod1( input logic p1 );

endmodule // mod1

Run the delete_connections command in insertion mode as follows to disconnect the fanout of the
interface port:
INSERTION> delete_connections p1_intf.tx_rx1

The tool modifies the RTL in memory as follows:

module top( intf1.usage1 p1_intf, input bit clk );

logic data;
intf1 p1_intf_tx_rx1();
always_ff @(posedge clk) begin
data <= p1_intf_tx_rx1.tx_rx1;
end
mod1 i1( .p1(p1_intf_tx_rx1.tx_rx1) );
assign p1_intf_tx_rx1.tx_rx2 = p1_intf.tx_rx2;
endmodule // top

module mod1( input logic p1 );

endmodule // mod1

Example 5: Modport Interface Type

This example disconnects the fanout of the i1/p1_intf interface pin.
The original RTL for this example is as follows:

module top;
intf1 n1 ();
mod1 i1(.p1_intf(n1));
mod2 i2(.p1_intf(n1));
endmodule // top

module mod1( intf1.usage1 p1_intf );

endmodule // mod1

module mod2( intf1.usage2 p1_intf );

endmodule // mod1

Run the delete_connections command in insertion mode as follows:

INSERTION> delete_connections i1/p1_intf.tx_rx2

The tool modifies the RTL in memory as follows:

Tessent™ Shell User’s Manual 101

Design Introspection and Editing
Examples Using the move_connections Command With Complex Signals

module top;
intf1 n1_ts1();
intf1 n1();
mod1 i1(.p1_intf(n1_ts1));
mod2 i2(.p1_intf(n1));
assign n1_ts1.tx_rx1 = n1.tx_rx1;
endmodule // top

module mod1( intf1.usage1 p1_intf );

endmodule // mod1

module mod2( intf1.usage2 p1_intf );

endmodule // mod1

Related Topics
Examples Using the create_connections Command With Complex Signals

HDL Limitations in the Tessent Shell Flow [Tessent Shell Reference Manual]

Examples Using the move_connections Command With Complex Signals

Examples Using the replace_instances Command With Complex Signals

Examples Using the move_connections Command With Complex

Signals
This section provides examples of moving complex signals.
For more information about the move_connections command, including the complete usage, refer to the
Tessent Shell Reference Manual. The following examples show how to use the command with complex
signals:

Data Types and Interfaces for Complex Signal Examples

The complex signal examples use the following data types:

package pack1;
typedef struct packed {
bit clk;
logic [1:0] data;
} struct_p;
typedef struct {
bit clk;
logic [1:0] data;
} struct_u;
endpackage
package pack2;
import pack1::*;
// 2D packed array of packed struct
typedef struct_p [3:0][2:0] p_array_struct_p;
// compound unpacked array

102 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Examples Using the move_connections Command With Complex Signals
typedef p_array_struct_p u_array [1:0];
// unpacked array of unpacked struct
typedef struct_u u_array_struct_u [1:0];
endpackage

Example 1: Unpacked Struct Type

This example moves a connection between pins of unpacked struct type using bundle objects. It is similar
to Example 1 in the move_connections command reference in the Tessent Shell Reference Manual but
with complex signals. The tool moves the driving bitnets from one input pin to another input pin.
The following RTL describes the original design:

module top;
pack2::p_array_struct_p p1_struct;
mod1 i1 (.p1_struct(p1_struct));
mod1 i2 ();
mod2 i3 (.p1_struct(p1_struct));
endmodule // top

module mod1( input pack2::p_array_struct_p p1_struct,

input pack2::u_array p2_struct );
endmodule // mod1

module mod2( output pack2::p_array_struct_p p1_struct );

endmodule // mod2

The following diagram shows the original design:

Tessent™ Shell User’s Manual 103

Design Introspection and Editing
Examples Using the move_connections Command With Complex Signals

Figure 8. Original Design Before Moving Connections

Run the move_connections command in insertion mode to move the complex signal from one pin to
another:
INSERTION> move_connections -from i1/p1_struct -to i2/p2_struct[1]

The tool modifies the RTL in memory as follows:

module top;
pack2::p_array_struct_p p1_struct;
pack2::u_array tessent_internal_net;
wire [35:0] tessent_filler_net;
mod1 i1 (.p1_struct());
mod1 i2 (.p2_struct(tessent_internal_net));
mod2 i3 (.p1_struct(p1_struct));
assign tessent_internal_net = '{p1_struct, tessent_filler_net};
endmodule // top

The following diagram shows the modified design with the moved connection in teal:

104 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Examples Using the move_connections Command With Complex Signals

Figure 9. Modified Design After Moving Connections

Example 2: Packed Array of Packed Struct Type

This example moves the fanout of the i1/signal1 net to the i1/i2/p1_struct pin from its original source. The
tool renames the i1/signal1 net everywhere it is used except at its source. The renamed net is then driven
by the i1/i2/p1_struct pin, leaving the original i1/signal1 net with no fanout. The i1/i2/p1_struct pin ends up
driving the fanout of the renamed net.
The following RTL describes the original design:

module top;
mod1 i1 (.p1_struct(36'b1));
endmodule // top

import pack1::*;
module mod1(input pack2::p_array_struct_p p1_struct );
struct_p signal1;
logic [1:0] data;
assign signal1 = 3'b0; // Original driver of signal1
submod2 i1(.p1_struct(signal1));
submod3 i2(.p1_struct());
always_ff @(posedge p1_struct[3][2].clk) begin
data <= signal1.data;
end
endmodule // mod1

module submod2( input struct_p p1_struct );

endmodule // submod2

module submod3( output struct_p p1_struct );

assign p1_struct = 3'b0;
endmodule // submod3

Tessent™ Shell User’s Manual 105

Design Introspection and Editing
Examples Using the replace_instances Command With Complex Signals

Run the move_connections command in insertion mode to move the complex signal from a net to a pin:
INSERTION> move_connections -from i1/signal1 -to i1/i2/p1_struct

The tool modifies the RTL in memory as follows:

import pack1::*;
module mod1(input pack2::p_array_struct_p p1_struct );
struct_p signal1;
logic [1:0] data;
pack1::struct_p signal1_ts1;
assign signal1 = 3'b0;
submod2 i1(.p1_struct(signal1_ts1));
submod3 i2(.p1_struct(signal1_ts1));
always_ff @(posedge p1_struct[3][2].clk)
begin
data <= signal1_ts1.data;
end
endmodule // mod1

module submod2( input struct_p p1_struct );

endmodule // submod2

module submod3( output struct_p p1_struct );

assign p1_struct = 3'b0;
endmodule // submod3

Related Topics
Examples Using the create_connections Command With Complex Signals

Examples Using the delete_connections Command With Complex Signals

HDL Limitations in the Tessent Shell Flow [Tessent Shell Reference Manual]

Examples Using the replace_instances Command With Complex Signals

Examples Using the replace_instances Command With Complex

Signals
This section provides examples of specifying new parameter values for SystemVerilog interface
parameters.
For more information about the move_connections command, including the complete usage, refer to the
Tessent Shell Reference Manual. The following examples show how to use the command with complex
signals:

Example 1
This example shows how to use the -parameter_values switch to change the module. The following RTL
describes the original design:

106 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Examples Using the replace_instances Command With Complex Signals

interface MSBUS #(parameter H_WIDTH = 64,

parameter L_WIDTH = 8);
logic [H_WIDTH -1:0] address;
logic [L_WIDTH -1:0] data;
logic ready;
modport in ( input address, input data, output ready);
modport out( output address, output data, input ready);
endinterface;
module SubA #(parameter CONFIG = 0)(MSBUS.in data);
endmodule
module SubB #(parameter CONFIG = 0)(MSBUS.in data);
endmodule
module top ();
MSBUS #(.H_WIDTH(64), .L_WIDTH(64)) INTF1();
SubA #(.CONFIG(1)) u1(.data(INTF1));
endmodule

Use the replace_instances command to replace module SubA with module SubB:
replace_instances u1 -with_module SubB \
-parameter_values {data.L_WIDTH 64 data.H_WIDTH 64}

The tool modifies the RTL in memory as follows:

RTL post editing:

interface MSBUS #(parameter H_WIDTH = 64,
parameter L_WIDTH = 8);
logic [H_WIDTH -1:0] address;
logic [L_WIDTH -1:0] data;
logic ready;
modport in ( input address, input data, output ready);
modport out( output address, output data, input ready);
endinterface;
module SubA #(parameter CONFIG = 0)(MSBUS.in data);
endmodule
module SubB #(parameter CONFIG = 0)(MSBUS.in data);
endmodule
module top ();
MSBUS #(.H_WIDTH(64), .L_WIDTH(64)) INTF1();
SubB #(.CONFIG(1)) u1(.data(INTF1));
endmodule

Example 2
This example shows how to use the -parameter_values switch to change the module and the
SystemVerilog interface parameters. The original RTL before editing is the same as Example 1. The
command is as follows:
replace_instances u1 -with_module SubB \
-parameter_values {data.L_WIDTH 16 data.H_WIDTH 16}

The resulting RTL after editing has a new SV interface net:

Tessent™ Shell User’s Manual 107

Design Introspection and Editing
Examples Using the replace_instances Command With Complex Signals

interface MSBUS #(parameter H_WIDTH = 64,

parameter L_WIDTH = 8);
logic [H_WIDTH -1:0] address;
logic [L_WIDTH -1:0] data;
logic ready;
modport in ( input address, input data, output ready);
modport out( output address, output data, input ready);
endinterface;
module SubA #(parameter CONFIG = 0)(MSBUS.in data);
endmodule
module SubB #(parameter CONFIG = 0)(MSBUS.in data);
endmodule
module top ();
MSBUS #(.H_WIDTH(16), .L_WIDTH(16)) tessent_filler_net();
MSBUS #(.H_WIDTH(64), .L_WIDTH(64)) INTF1();
SubB #(.CONFIG(1)) u1(.data(tessent_filler_net));
endmodule

Example 3
This example shows how to use the -with_module switch to change the module without specifying a
new parameter list. In this case, the tool adds a new SV interface with the default parameter values. The
original RTL before editing is the same as the “Example 1” on page 106. The command is as follows:
replace_instances u1 -with_module SubB

The resulting RTL after editing has a new SV interface net because the interface changed to the default of
H_WIDTH= 64 and L_WIDTH=8:

interface MSBUS #(parameter H_WIDTH = 64,

parameter L_WIDTH = 8);
logic [H_WIDTH -1:0] address;
logic [L_WIDTH -1:0] data;
logic ready;
modport in ( input address, input data, output ready);
modport out( output address, output data, input ready);
endinterface;
module SubA #(parameter CONFIG = 0)(MSBUS.in data);
endmodule
module SubB #(parameter CONFIG = 0)(MSBUS.in data);
endmodule
module top ();
MSBUS tessent_filler_net();
MSBUS #(.H_WIDTH(64), .L_WIDTH(64)) INTF1();
SubB #(.CONFIG(1)) u1(.data(tessent_filler_net));
endmodule

Related Topics
Examples Using the create_connections Command With Complex Signals

Examples Using the delete_connections Command With Complex Signals

108 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Design Editing Examples

Examples Using the move_connections Command With Complex Signals

HDL Limitations in the Tessent Shell Flow [Tessent Shell Reference Manual]

Examples Using the replace_instances Command With Complex Signals

create_module [Tessent Shell Reference Manual]

Design Editing Examples

There are many ways to create, modify, and remove elements from your design in a Tcl scripting
environment.
Figure 10 is an example design, which is followed by related examples that show some of the ways you
can edit designs within Tessent Shell.

Figure 10. Hierarchical Design Example

Example of Creating a Module From Scratch

The following example shows how to create module C (modc) in Figure 10 as a stand-alone module.
set_context dft –no_rtl
set_system_mode insertion
create_module modc
set_current_design modc

create_port I1 -on_module modc -direction input

create_port I2 -on_module modc -direction input
create_port I3 -on_module modc -direction input
create_port I4 -on_module modc -direction input
create_port O1 -on_module modc -direction output
create_port O2 -on_module modc -direction output

create_instance u1 -of_module and2

create_instance u2 -of_module dff
create_instance u3 -of_module dffr

create_connection I1 u1/A0
create_connection I2 u1/A1
create_connection I2 u3/R

Tessent™ Shell User’s Manual 109

Design Introspection and Editing
Design Editing Examples
create_connection I3 u3/D
create_connection I4 u3/CLK
create_connection I4 u2/CLK
create_connection u1/Y u2/D
create_connection u2/Q O1
create_connection u3/Q O2

write_design -output_file MODC.v -replace

Example of Replacing a Module With Another Module

The following example replaces the module definition for instance u5 (modd) to modc. The original
module and the new module have the same pinout, and the connecting nets remain the same after
issuing the replace_instances command. After replacing instance u5 with modc, that instance u5/u1
changes from an or2 gate to an and02 gate.
INSERTION> get_attribute_value_list u5 -name module_name

modd

INSERTION> get_fanin u5/I1 -stop_on net

{u4_O1}

INSERTION> replace_instances u5 -with_module modc

{u5}

INSERTION> get_fanin u5/I1 -stop_on net

{u4_O1}

INSERTION> set_system_mode setup

SETUP> set_design_level sub_block
SETUP> set_sys_mode analysis

// Flattening process completed, cell instances=15, gates=45, PIs=8

// POs=3, CPU time=0.00 sec.
// -----------------------------------------------------------------
// Begin circuit learning analyses.
// --------------------------------
// Learning completed, CPU time=0.00 sec.

ANALYSIS> report_gates u5/u1

// /u5/u1 and02
// A0 I /u4/u3/Q
// A1 I /u4/u5/u2/Q
// Y O /u5/u2/D

110 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Design Editing Examples

Example of Intercepting a Connection

Figure 11 shows an example of inserting an inverter by intercepting the existing connection between the
u7/D pin and the u6/Y pin. After the interception, the inverter A pin is connected to the u6/Y pin and the
inverter Y pin is connected to the u7/D pin.

Figure 11. Inverter Inception

INSERTION> intercept_connection u7/D -cell_function_name inverter

{insertion_inverter}

Example of Adding Input and Output Pads to a Design

The following dofile example adds input and output pads to a design by creating a collection of port
names from the design, creating a collection of pad names that match the ports, then connecting the ports
and pads together in the design. The example also adds the TAP's I/O ports, including the respective
pads.

# Setting the context to netlist editing

set_context dft -no_rtl

# Reading the library and all necessary Verilog files

read_cell_library ../libs/libs/adk.atpg
read_verilog ./counter_block2_edt_top_gate.v
read_verilog ../libs/pads/*.v

# Telling the tool, which module 'top' is

set top_module "counter_block2"
set_current_design $top_module

# Now for the editing

set_system_mode insertion

# First, insert the pad cells for all inputs of the netlist
set inputPortList [ get_ports -of_module $top_module -direction input ]
foreach_in_collection inputPort $inputPortList {

# Creating the name of the pad cell:

# The following lines take care of '[' and ']' in the portname,
# substituting these by '_'. This makes the Tcl-life easier
set portName [lindex [get_name_list $inputPort] 0]
set padName [ string map { \[ _ \] _ } ${portName}_PAD ]

# Adding the pad cell

create_instance $padName -of_module INPAD

Tessent™ Shell User’s Manual 111

Design Introspection and Editing
Design Editing Examples

# Connecting it up in the netlist

# The first line moves the existing net from the input port to the output
# of the pad cell. The second line creates a new net and connects the
# input port to the input of the pad cell
# Note: We are not connecting anything else here.
# We leave this to boundary scan insertion
move_connection -from $inputPort -to $padName/FP
create_connection $inputPort $padName/IO
}

# Second, insert the pad cells for all outputs of the netlist
set outputPortList [ get_ports -of_module $top_module -direction output ]
foreach_in_collection outputPort $outputPortList {

# Creating the name of the pad cell:

# The following lines take care of '[' and ']' in the portname,
# substituting these by '_'.
set portName [lindex [ get_name_list $outputPort ] 0]
set padName [ string map { \[ _ \] _ } ${portName}_PAD ]

# Adding the pad cell

create_instance $padName -of_module OUTPAD_2S

# Connecting it up in the netlist

# The first line moves the existing net from the IO port to the input
# of the pad cell. The second line creates a new net and connects the
# IO port to the output of the pad cell.
# Note: We are not connecting anything else here.
# We leave this to boundary scan insertion
move_connection -from $outputPort -to $padName/TP
create_connection $outputPort $padName/IO
}

# Next, add the JTAG IO pins and their respective PAD cell. Connecting
# them up.

set inputPortList { TDI TMS TRST TCK }

set outputPortList { TDO }

foreach portName $inputPortList {

# Adding the pad cell

set padName ${portName}_PAD
create_instance $padName -of_module INPAD

# Creating an Input IO pin and connecting the pad

create_port $portName -direction input
create_connection $portName $padName/IO
}

foreach portName $outputPortList {

# Adding the pad cell

112 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Design Editing Examples
set padName ${portName}_PAD
create_instance $padName -of_module OUTPAD_EN1

# Creating an output pin and connecting the pad

create_port $portName -direction output
create_connection $portName $padName/IO
}

# Write the new netlist

write_design -output_file "${top_module}.v" -replace
exit

Example of Handling Non-Unique Design Scopes

When you want to make edits to non-unique design scopes, such as multiple instances of the same
module or the inner part of a generate loop, you must exercise caution.
When using the delete_connections or move_connections commands inside a non-uniquified design, only
perform the move or disconnection once per module or once per generate loop count.
For an example, refer to how the parent_instance and the leaf_name_hash attributes are used in
Example 5 of the get_dft_cell command description. (For more information on the leaf_name_hash
attribute, refer to Instance in the Tessent Shell Reference Manual.)

Tessent™ Shell User’s Manual 113

Design Introspection and Editing
Simulation Contexts

Simulation Contexts
Tessent Shell provides simulation contexts to aid your design analysis and introspection efforts. You can
use these contexts to create "simulation scratch pads" for rapid investigation of good-machine behavior of
specific portions of your design.

Simulation Context Overview

Introspection and Analysis Using Simulation Contexts

Simulation Context Overview

Tessent Shell provides commands for creating and managing simulation contexts. From a particular user-
defined simulation context, you can use these commands to apply stimulus forces to specified gate_pins,
run simulation for a specific number of cycles, and then introspect gate_pins for simulation values.

Commands for Managing Simulation Contexts

Use the following commands to create and manage user-defined simulation contexts, as well as use
predefined simulation contexts:

• add_simulation_context — Creates a new user-defined simulation context.

• copy_simulation_context — Copies the simulation values and forces from one simulation context
to another.

• delete_simulation_contexts — Deletes one or more user-defined simulation contexts.

• get_current_simulation_context — Returns the name of the current simulation context.

• get_simulation_context_list — Returns the available simulation contexts in a Tcl list.

• report_simulation_contexts — Lists the available simulation contexts and indicates the current
simulation context.

• set_current_simulation_context — Sets the current simulation context.

Commands for Managing Stimulus and Simulating within Simulation

Contexts
The following commands are for managing stimulus (simulation forces and clock pulses) and running
limited simulations within a simulation context:

• add_simulation_forces — Forces one or more gate_pin objects to the specified value.

• delete_simulation_forces — Removes forces from one or more gate_pin objects.

• report_simulation_forces — Lists the active forces on the specified gate_pin objects.

114 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Introspection and Analysis Using Simulation Contexts

• simulate_clock_pulses — Pulses one or more clocks within the current simulation context.

• simulate_forces — Simulates the queued forces in the current simulation context.

Commands for Introspection and Analysis within Simulation Contexts

The following commands are for introspection and analysis within simulation contexts, which includes
examining simulation results:

• get_current_simulation_context — Returns the name of the current simulation context.

• get_simulation_context_list — Returns the available simulation contexts in a Tcl list.

• get_simulation_value_list — Returns the simulation values on the specified gate_pin objects.

• report_simulation_contexts — Lists the available simulation contexts and indicates the current
simulation context.

• report_simulation_forces — Lists the active forces on the specified gate_pin objects.

• set_gate_report — Specifies the information displayed by the report_gates command. This

command enables reporting of simulated values in the current simulation context.

• trace_flat_model — Traces the flat model within the current simulation context. This command
always operates within the current simulation context.

Attributes for gate_pin Objects

For a complete list of attributes, refer to the Data Models chapter in the Tessent Shell Reference Manual.

Introspection and Analysis Using Simulation

Contexts
Simulation contexts enable you to perform various types of design analysis and introspection. The
four predefined simulation contexts are: stable_after_setup, stable_load_unload, stable_shift, and
stable_capture. After setting a simulation context, you can introspect gate_pins for simulation values
based on that specific simulation context. For example, the trace_flat_model command can do design
tracing based on values specified for the current simulation context.
To use any of the following techniques in this chapter, you must be doing the following:

• Operating in the analysis system mode of Tessent Shell.

• Operating on a flattened design, and have read in the test procedure file (if available). At this
point, the values specified in the setup, shift, capture, and load_unload procedures are in place in
the design when you set the corresponding simulation context as current.

Tessent™ Shell User’s Manual 115

Design Introspection and Editing
Introspection and Analysis Using Simulation Contexts

Example
For example, if you want to trace the design based on the values specified in the shift procedure, use
the set_current_simulation_context stable_shift command. When you use this command with a small
design containing two 2-cell scan chains, the values on the gate_pins display in the Tessent Visualizer
Flat Schematic as shown in Figure 12.

Figure 12. Tessent Visualizer Flat Schematic (gate level)

In this case, no values are forced except for sen (scan enable), which is set to 1. The four possible
simulation values are 0, 1, X, and Z.
In addition to viewing values in the Flat Schematic, you can get the current simulation values of gate_pins
using any of the following techniques:

• Use the get_simulation_value_list command and specify the gate_pin object(s):

ANALYSIS> set_current_simulation_context stable_shift
ANALYSIS> get_simulation_value_list sc2_f1/D

• Check the value of the simulation_value attribute for the gate_pins:

ANALYSIS> get_attribute_value_list [get_gate_pin sc2_f1/D]
-name simulation_value

116 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Introspection and Analysis Using Simulation Contexts

• Issue the command "set_gate_report simulation_context," after which you can use the
report_gates command and the Flat Schematic to display the simulated values from the current
simulation context:
ANALYSIS> set_gate_report simulation_context
ANALYSIS> report_gates sc2_f1

// /sc2_f1 sff
// D I (X) /d3
// SI I (X) /si2
// SE I (1) /sen
// CLK I (X) /clk
// Q O (X) /an_2/A2 /sc2_f2/SI
// QB O (X)

You can use simulation context functionality for different types of analysis. For example, by default the
trace_flat_model command uses the stable_after_setup values as a simulation background. You can now
change it to stable_capture, for example, if you want to trace based on sensitized paths during capture.
Another example is to copy an existing simulation context to a new one, force some simulation value
changes, then evaluate the results in the circuit after simulating the forces or clock pulses.

Tessent™ Shell User’s Manual 117

Design Introspection and Editing
Automatic Design Mapping

Automatic Design Mapping

Logic synthesis may cause name and footprint changes in the design for both complex and regular ports.

ICL and TCD Post-Synthesis Update

Updating ICL Attributes From the Design
Matching Rules for Port Names in Post-Synthesis Update
Controlling the Name Mapping

ICL and TCD Post-Synthesis Update

Logic synthesis flattens (bit-blasts) ports. This changes the design footprint. Additionally, post-synthesis
names differ from those in the initial RTL.
Tessent in ‑no_rtl mode uses the post-synthesis netlist when you run set_current_design. The ICL and
TCD of the current design updates automatically to match the new design objects that are loaded from
the post-synthesis netlist. The following ICL model attributes are updated to enable binding of the ICL
objects and design objects later in the flow:

• tessent_design_instance (for the instance path)

• tessent_design_gate_ports (for ports)

• tessent_design_rtl_ports (for ports)

The tessent_design_instance attribute of the ICL instance object is automatically updated when you use
any of the following commands:

• set_current_design

• write_design

• update_icl_attributes_from_design
The tessent_design_gate_ports attribute of the ICL port object is automatically updated when you use any
of the following commands:

• set_current_design

• get_ports -of_icl_ports

• get_pins -of_icl_pins

• get_pins -of_icl_ports

• update_icl_attributes_from_design

• write_design

118 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Updating ICL Attributes From the Design

For ICL ports and instances, the ICL matching performed by set_current_design is insufficient if the
current ICL model does not include the complete ICL of child instances under the physical blocks. In
these cases, the ICL matching is completed later in the flow using the following commands:

• get_ports -of_icl_ports

• get_pins -of_icl_pins

• get_pins -of_icl_ports

• update_icl_attributes_from_design

• write_design
Use the ‑use_path_matching_options option with get_pins, get_ports, or get_instances to match a name
pattern to the ports and pins in the current design when the TCD of instruments dumped during RTL
mode is loaded in no RTL flow.

Updating ICL Attributes From the Design

The update_icl_attributes_from_design command updates ICL port, instance, and module attributes
for the gate views of a design. The update includes all ICL ports, instances, and modules in the current
design.
The command updates the following attributes:

• tessent_design_gate_ports — This attribute refers to the design port corresponding to the ICL
port. The attribute value is the name of the design port as it appears in the netlist.

• tessent_design_instance — This attribute refers to the design instance corresponding to the

ICL instance. The value is the hierarchical name relative to the parent ICL instance.

• tessent_design_rtl_gate_port_mapping — This attribute maps the RTL name to the netlist

name for those ports that appear in the following attribute name lists:

◦ forced_high_input_port_list

◦ forced_low_input_port_list

◦ forced_high_output_port_list

◦ forced_low_output_port_list

◦ forced_high_internal_input_port_list

◦ forced_low_internal_input_port_list

◦ tessent_ground_port_list

Tessent™ Shell User’s Manual 119

Design Introspection and Editing
Matching Rules for Port Names in Post-Synthesis Update

◦ tessent_power_port_list

◦ tessent_clock_domain_labels
The attribute value is a list of names. The names at the even index positions in the list are the
RTL names of the ports in the attribute name lists, and the names at the odd index positions are
the netlist names of those ports.
The update_icl_attributes_from_design command has one Boolean option: -verbose. This option
enables warnings when a port name cannot be found or matched in the netlist. The command is
invoked automatically by the "write_design -tsdb" command. It also runs automatically as part of
the insert_test_logic command just after insertion.

Related Topics
update_icl_attributes_from_design

Matching Rules for Port Names in Post-Synthesis

Update
The following matching rules are supported when looking up a port name in a netlist:

®
1. Apply the transformation performed by the Synopsys Design Compiler tool (dc_shell) with
"change_names ‑rules verilog" to remove the escaping and replace special characters with an
underscore ("_"). A single underscore matches multiple underscores.

®
2. Apply the transformation performed by Cadence Genus™ Synthesis Solution to get the gate
name from the RTL name. All strings and numerical indices in the RTL name are preserved. Only
the delimiters are changed.

3. Apply the Genus transformation described in rule #2 but with escaping removed and special
characters replaced with an underscore ("_") as in rule #1.

4. Apply bit-blasted escaped names generated by a layout tool. The bit select is incorporated into
the escaped name.

5. Apply end-user‑specified matching rules.

Controlling the Name Mapping

Use the add_rtl_to_gates_mapping and delete_rtl_to_gates_mapping commands to control the name
mapping. Use the report_rtl_to_gates_mapping command to obtain information about the current
mapping rules.
Refer to the Tessent Shell Reference Manual for information on these commands.

120 Tessent™ Shell User’s Manual

 Design Introspection and Editing
Controlling the Name Mapping

Default Matching Rules for the get_pins and get_ports Commands

• Component Names — All strings between non-escaped delimiters (component names) in the
name to be looked up (lookup name) must match exactly to corresponding strings in a netlist
name unless they contain special characters (refer to the following). The recognized delimiters
are ‘.’, ‘/’, ‘[]’, ‘_’.
An example lookup name:

abc.def

The ‘abc’ string in the name to be looked up must exactly match the string before the first
delimiter in a netlist name. The ‘def’ string in the name to be looked up must exactly match the
string after the last delimiter in the same netlist name.

• Escaping — Escape characters are not matched. They are only used to direct the matching
procedure.

• Delimiters — Delimiters in the lookup name are used only to extract the component names.
All component names after the first are assumed to have a leading delimiter and optionally a
trailing delimiter in a netlist name. There are two cases to consider when matching the delimiters
for a component name in the netlist:

a. Port name in netlist is escaped.

Possible matches for component name delimiters are as follows:

• Leading and trailing delimiters of [].

• Leading delimiter of ‘_’ and trailing delimiter of ‘_’ or null.

• Leading delimiter of ‘.’ or ‘/’ and trailing delimiter of null.

b. Port name in netlist is not escaped.

Possible matches for component name delimiters are as follows:

• Leading delimiter of ‘_’ and trailing delimiter of ‘_’ or null.

• Special Characters in the Lookup Name — When matching to a non-escaped name in the
netlist, any special characters (not allowed by the language without escaping) in the lookup name
are replaced with the ‘_’ character. Matching allows truncation in the netlist name down to two
trailing ‘_’ characters.

Tessent™ Shell User’s Manual 121

Design Introspection and Editing
ICL Objects Versus Design Objects Introspection

Note:
This truncation rule applies only to ‘_’ characters derived from special characters, not
delimiters.

• Bit Select Lookup Name — A bit select lookup name (last component name is an index) can
match a one-dimensional vector with the final bit select applied to the match or match directly to a
bit select.

Related Topics
add_rtl_to_gates_mapping

delete_rtl_to_gates_mapping

report_rtl_to_gates_mapping

ICL Objects Versus Design Objects

Introspection
Several Tessent Shell commands enable you to introspect ICL objects and design objects in an ICL
context.
For example, you can retrieve design modules and instances from ICL modules and instances:

• get_module ‑of_icl_module icl_module_spec

• get_instance ‑of_icl_instance icl_instance_spec

You can retrieve ICL modules and instances from design modules and instances:

• get_icl_module ‑of_module module_spec

• get_icl_instance ‑of_instance instance_spec

Certain additional command-line switches for these commands are necessary when your design includes
complex ports, or simple ports with escaped names requiring name changes during logic synthesis.
And you can also retrieve design pins and ports from ICL pins and ports:

• get_pins ‑of_icl_pins icl_pin_objects

• get_ports ‑of_icl_ports icl_port_objects

You can also retrieve icl pins and ports from design pins and ports:

• get_icl_pins ‑of_pins icl_pin_objects

• get_icl_ports ‑of_ports icl_port_objects

122 Tessent™ Shell User’s Manual

 Design Introspection and Editing
ICL Objects Versus Design Objects Introspection

Related Topics
get_modules

get_instances

get_icl_modules

get_icl_instances

get_pins

get_ports

get_icl_pins

get_icl_ports

Tessent™ Shell User’s Manual 123

Design Introspection and Editing
ICL Objects Versus Design Objects Introspection

124 Tessent™ Shell User’s Manual

 Chapter 4
DFT Architecture Guidelines for Hierarchical
Designs
Most chips follow hierarchical place-and-route because of the increase in design sizes. For DFT, you can
also use hierarchical design methodologies to perform test insertion, test generation, and diagnosis. This
use of the hierarchical design methodologies is called hierarchical DFT or hierarchical test.
If the design is implemented as one chip with flat place-and-route, then perform DFT implementation once
for the entire chip. Hierarchical DFT implementation is only applicable for block-based designs in which
the tool run time consumption is not practical for implementing DFT only from the chip level.
Hierarchical DFT has several advantages:

• Divide and conquer technique that helps with parallelization of tasks.

• Reduced memory footprint and CPU requirements to perform the given task.

• Faster pattern generation and simulation run times.

• DFT performed earlier at block level and out of design critical path.
For information about the Tessent Shell two-pass DFT insertion flow for hierarchical designs, refer to
“Tessent Shell Flow for Hierarchical Designs” on page 217.

Hierarchical DFT Overview

Top-Down Planning Before Bottom-Up Implementation
DFT Implementation Strategy

Tessent™ Shell User’s Manual 125

DFT Architecture Guidelines for Hierarchical Designs
Hierarchical DFT Overview

Hierarchical DFT Overview

Hierarchical DFT is the process of using hierarchical design methodologies to perform test insertion, test
generation, and diagnosis. Within the Tessent Shell environment, multiple components, such as physical
layout regions and wrapped cores, are used to implement DFT in hierarchical designs.

Physical Layout Regions in Hierarchical Test

Pattern Retargeting
Wrapped Cores and Wrapper Cells
Internal Mode and External Mode
On-Chip Clock Controller
Graybox Model

Physical Layout Regions in Hierarchical Test

Hierarchical designs typically have several physical layout regions, and these layout regions are
instantiated into other physical layout regions. Usually, the instantiations occur at the chip level, so you
have two levels of hierarchy (or sometimes more for some designs). From the DFT perspective, each
layout region is where you perform test insertion, with the test insertion process performed independently
for each region. You can implement DFT within the layout regions in parallel, thus improving throughput.
In some designs there may be more than two levels of physical hierarchy. From the DFT perspective,
each layout region is where you perform test insertion, with the test insertion process performed
independently for each region.
You must insert DFT into the lower-level designs before inserting it at the next higher level (at the chip
level).
The following terms describe the layout regions of a hierarchical design:

• Physical block, block, core, child core — These terms are interchangeable and refer to layout
regions below the chip level that you can instantiate within a chip, or across multiple chips. Blocks
are logical entities that remain intact through tapeout. You perform synthesis on these blocks
independent of the rest of the chip design.
The term "wrapped core" is a specialized type of block. Refer to “Wrapped Cores and Wrapper
Cells” on page 127 for details.

• Chip — The chip is the top-level physical block — that is, the entire design — in which you
typically find the pad I/O macros and clock controllers.
The chip and upper-level blocks in designs with more than two hierarchical levels are often referred to as
the parent blocks and the tasks related to them as occurring at the parent level.

Pattern Retargeting
Pattern retargeting is the process by which Tessent Shell preserves the ATPG patterns associated
with cores for purposes of reuse when testing the logic at the chip (or parent) level. You do not have to
regenerate the patterns when you process the chip. Instead, you retarget the core patterns to the chip
level. Every instantiation of a core includes its associated ATPG patterns.

126 Tessent™ Shell User’s Manual

 DFT Architecture Guidelines for Hierarchical Designs
Wrapped Cores and Wrapper Cells

The pattern retargeting process consists of generating patterns for all cores, retargeting the core‑level test
patterns to the chip level, and generating patterns for the top-level chip logic only. This is also referred to
as ATPG pattern retargeting or scan pattern retargeting. For details, refer to "Scan Pattern Retargeting" in
the Tessent Scan and ATPG User’s Manual.

Wrapped Cores and Wrapper Cells

In hierarchical DFT, you must wrap physical blocks to make them reusable through pattern retargeting.
The term wrapped cores applies to these physical blocks. The purpose of wrapping a core is to isolate its
internal logic.
In the following figure, the physical layout regions from a DFT perspective are physical blocks. Tessent
performs test insertion on the Red, Pink, Brown, and Green physical blocks first. Clk1 and Clk2 are
asynchronous clocks.

Figure 13. Wrapped Cores

The wrapping mechanism that you use for these blocks makes use of the functional flops that are already
present at the boundary of these blocks. These flops are called shared wrapper cells (or sometimes
wrapper cells) because they share the responsibility of their original functional use as I/O flops with
isolating the core.
Optionally, you can add dedicated wrapper cells. These wrapper cells are added on primary inputs or
primary outputs of a physical block that fan out from or fan into large logic cones. By adding the dedicated
wrapper cell, you can test the logic cone during internal testing of the core.
Shared and dedicated wrapper cells form the wrapper chains. Logic located within the wrapper chains is
tested during internal testing of the core, called intest. Logic located outside the wrapper chains is tested
during the external testing of the core, called extest.

Internal Mode and External Mode

For purposes of pattern retargeting, Tessent Shell differentiates between a wrapped core’s internal
circuitry and its external circuitry.

Tessent™ Shell User’s Manual 127

DFT Architecture Guidelines for Hierarchical Designs
Internal Mode and External Mode

Internal mode is the view into the wrapped core from the wrapper cells. That is, the logic completely
internal to the core. Tessent Shell retargets internal mode ATPG patterns during ATPG pattern generation
for the chip-level design.
External mode indicates the view out of the wrapped core from the wrapper cells. That is, the logic that
connects the wrapped core to external logic. Tessent Shell uses the external mode to build graybox
models, which are used by the internal modes of their parent physical blocks.
As shown in the following figure, based on chip pin availability, you can test the Red, Pink, Brown, and
Green cores in internal mode at the same time when the on-chip clock controllers (OCCs) and EDT logic
blocks inside the wrapped cores are active.

Figure 14. Internal Mode

You can test one or more wrapped cores in internal mode based on several factors, such as availability of
chip-level pins, tester channels, tester memory, and power dissipation. The OCCs and EDT compression
logic at the chip level are inactive during internal mode.
In external mode, the wrapped cores at the given physical hierarchy participate. The OCCs and EDT logic
blocks inside the cores are inactive, and the OCCs and EDT logic blocks outside the wrapped cores are
active. In a typical external mode configuration, one EDT logic block is used to test the logic outside the
wrapper chains, as shown in the following figure.

128 Tessent™ Shell User’s Manual

 DFT Architecture Guidelines for Hierarchical Designs
On-Chip Clock Controller

Figure 15. External Mode

External mode also includes the wrapper chains within the wrapped cores. Tessent tests the logic outside
of the wrapper chains during external mode.

On-Chip Clock Controller

During hierarchical test, the existence of wrapped cores, whose patterns you want to retarget to the chip
level, requires a mechanism to enable local, self-contained clock control. This mechanism is the on-chip
clock controller (OCC), which you insert into each wrapped core. OCCs inside the wrapped cores make
the ATPG patterns self-contained, which enables them to be retargeted.
The OCC is initialized for a clock waveform, and then the applicable patterns are retargeted to the parent-
or chip-level design, as applicable. Block-level patterns with block-level OCCs can be retargeted and
merged with other block patterns at the parent- or chip-level design independent of the clock waveforms.
Each wrapped core can contain one or more EDT logic blocks that contain the compression logic.
Similarly there may be several options for testing the external mode of the cores. In the following figure,
OCC insertion occurs for each clock domain entering the cores. At the chip level, OCCs are also required
for the clock domains at this level. Insert one EDT logic block for each internal mode of the core and one
EDT logic block for the core’s external mode.

Tessent™ Shell User’s Manual 129

DFT Architecture Guidelines for Hierarchical Designs
Graybox Model

Figure 16. On-Chip Clock Controller

To help facilitate test setup and automation, use a 1149.1 TAP controller along with an IJTAG network.
You may also need to insert a Test Access Mechanism (TAM) to guide how these wrapped cores may be
tested.
Standard OCCs include built-in clock selection, clock-chopping, and clock-gating functionality. For more
information about standard OCCs, as well as parent and child OCCs, refer to "Tessent On-Chip Clock
Controller" in the Tessent Scan and ATPG User’s Manual.

Graybox Model
Graybox models are wrapped core models that preserve the core’s external mode logic, which includes
the wrapper chains, along with the portion of the IJTAG network that needs to be tested along with the
logic at the next physical level. The purpose of graybox models during hierarchical test is to retain the
minimum logic required to generate ATPG patterns for the internal modes of the parent physical blocks.
When testing the next physical level, using graybox models enables Tessent Shell to load the design
faster than loading the full-chip design.
For details, refer to "Graybox Overview" in the Tessent Scan and ATPG User’s Manual.
The following figure shows a graybox model in which the internal logic of the wrapped core is removed.
This graybox model implementation has separate input and output wrapper chains with separate scan
enable signals for each wrapper chain type.

130 Tessent™ Shell User’s Manual

 DFT Architecture Guidelines for Hierarchical Designs
Graybox Model

Figure 17. Graybox Model

The input and output wrapper chains do not have to be separate, and the scan enable signals also do
not need to be separate. You can use one scan enable signal with other mechanisms to enable how the
wrapper chains operate.

Tessent™ Shell User’s Manual 131

DFT Architecture Guidelines for Hierarchical Designs
Top-Down Planning Before Bottom-Up Implementation

Top-Down Planning Before Bottom-Up

Implementation
To optimize your DFT implementation for hierarchical designs, top-down planning is necessary. Top-down
planning enables you to properly budget and allocate the resources required for hierarchical test.
As described in “Tessent Shell Flow for Hierarchical Designs” on page 217, the process for inserting
DFT into hierarchical designs is performed in a bottom-up process starting from the lowest level block.
However, prior to insertion, it is best to plan the implementation in a top-down manner, starting at the chip
level.
To address the design's challenges, consider the following factors:

• Optimizing pattern count to reduce test time

• Optimizing scan volume to fit within allocated tester memory

• Reducing chip pin requirements to fit within tester pin allocation

The planning process requires you to think about priorities such as test time, test quality, flow
compatibility, and design schedule. During the planning stage consider the priorities and also the
necessary tradeoffs to meet those priorities. In addition, be aware that how you implement DFT at the
chip level impacts DFT implementation at the core level.

Clocking Architecture
Resource Availability
Test Scheduling
Specific Tasks That May Require Planning
Sample DFT Planning Steps

Clocking Architecture
In functional mode, the clock architecture can include clocks that are divided or multiplied. The original,
divided, and multiplied clocks can be synchronous with each other within a core, and sometimes they can
be synchronous across hierarchical cores. Divided clocks can also be asynchronous across hierarchical
cores.
When generating ATPG patterns at the core level that you want to retarget, the core must include an OCC
to control clocking as described in “On-Chip Clock Controller” on page 129. How you implement OCCs in
the cores depends on various factors:

• How the clocks are balanced — The most common methods for clock balancing are clock tree
synthesis and clock mesh synthesis. The method you use can influence what type of OCCs you
insert (standard, parent, child).

• OCC behavior during intest and extest — How the OCCs need to behave during intest and
extest of the cores also dictates how you should implement the OCCs.
Some OCCs are only required to perform clock chopping or clock-gating functionality. Sometimes OCCs
may be necessary to mux clocks in for test purposes. You can use chip-level clocking to determine the
architecture and OCC types (standard, parent, child) that you should use within the wrapped cores.
132 Tessent™ Shell User’s Manual
 DFT Architecture Guidelines for Hierarchical Designs
Resource Availability

Refer to “Clocking Architecture Examples” on page 997 for examples of clocking architectures with
OCC.

Resource Availability
Resource availability plays a significant role in how you implement DFT. For example, at the chip level,
the number of pins available for test limits the number of EDT channel pins that you can use. The EDT
channel pins may not be associated with only one EDT controller; they could be connected to multiple
EDT controllers.
Likewise, the tester may have limited channel pins available for connecting to EDT channel pins on the
chip, which means that you may need to consider the tester’s memory allocation for storing the test
patterns. Available memory on the tester dictates whether you need to split the pattern set or test multiple
cores in parallel.
How you want to test the wrapped cores dictates how you create the test-access mechanism (TAM).
TAMs carry scan data in and out of the chip for each group of wrapped cores you intend to run in parallel.
You need a TAM if you have limited chip pins and are reusing them to connect to multiple EDT controllers
inside the wrapped cores.
The TAM logic is dependent on how and when the cores get tested. The TAM schedules the tests for the
wrapped cores at the top level, and it enables access to the chip level so that you can run these tests.
The TAM also needs input from floor planning and placement of these cores to avoid routing congestion;
you need to account for the proximity of the cores that you want to test in parallel and for the location of
the chip pins that connect to them.

Test Scheduling
Deciding which wrapped cores need to be tested at the same time on the tester—that is, in parallel—
depends on a number of factors.
Streaming Scan Network (SSN) on page 483 enables you to test the maximum number of cores within
your power budget in a single pass. Because all cores accessible are through the SSN bus, you can
delay the decision of which cores to run concurrently on the tester until ATPG or pattern retargeting. The
SSN ScanHost drives the TestKompress EDT channels, decoupling them from top-level input and output
pins.
SSN handles cores with different pattern counts by manipulating the network’s bandwidth during
retargeting and ATPG. The tool transfers network bandwidth from the cores with fewer patterns to the
cores with more patterns. Through this bandwidth management, cores with different pattern counts finish
on the tester closer together and have less padding than non-SSN patterns. Dynamic power is inherently
reduced with SSN as each core independently transitions between shift and capture, significantly
reducing the chance of a coincident clock edge during shift or capture.
SSN efficiently tests identical cores when you add the On-Chip Compare on page 537 feature to the
ScanHost. On-chip compare mode enables you to test any number of identical cores in constant time
because it shares the same input, mask, and expected data across all the active cores.
For non-SSN designs, you may have to test the chip in pieces. The test scheduling for non-SSN designs
depends on the following factors:

• Number of patterns

• Availability of chip pins

• Tester pin storage limitations

Tessent™ Shell User’s Manual 133

DFT Architecture Guidelines for Hierarchical Designs
Test Scheduling

• Number of identical cores

• Cores with similar pattern counts

• Power dissipation budget and allocation

• Optimal compression at the core level

• Channel sharing of cores within modular EDT or sub-chip architectures; cores need to be tested
where channels are shared
To achieve the optimal test schedule for a chip with a given number of hierarchical cores, generate an
optimized compression for the internal mode of the cores. Within each core, compression could be based
on asymmetric channel configurations. Designs with no X-sources require fewer output channels.
You can use the analyze_compression command to optimize compression. It requires gate-level scan
stitched netlists. BIST logic used for memories needs to be scan stitched and included for the best
compression estimation.
The following example shows a schedule based on compression analysis. Suppose 64 pins are available
at the chip level as channel pins. There are twelve instances of blk_a, eight instances of blk_b, four
instances of blk_c, and one instance each of blk_d, blk_e, and blk_f. The highlighted instances provide
the best utilization of resources.

Figure 18. Compression Analysis Example

134 Tessent™ Shell User’s Manual

 DFT Architecture Guidelines for Hierarchical Designs
Test Scheduling

Suppose you plan to group identical core instances for testing in parallel. The 40 input channel pins can
broadcast to the blk_a instances, providing the same input data to all the cores. Two output channels from
each instance require a total of 24 additional pins. When testing the 12 blk_a instances together, use the
64 available chip pins.

Table 15. Test Schedule Example

% Total Pins No. of

Scan Faults/Gr Input Output Used/ Shift No. of Tester
Config Channels Channels Length Patterns
oup Config Cycles

12(blk_a) 68.59 40 24 64 156 2409 375804

8(blk_b) 8.54 32 32 64 154 1411 217294

4(blk_c) 9.53 8 56 64 270 3895 1051650

blk_f, 7.33 52 12 64 259 2033 526547

blk_e

blk_d 6.01 38 18 56 259 1579 408961

. . . . . Total tester cycles 2646118

Next, test the eight instances of blk_b together by applying the retargeted patterns at the chip level. The
32 input channel pins broadcast to the eight blk_b instances. In addition, each instance uses four output
channels for a total of 64 pins. After that, test the four blk_c instances with eight input channels broadcast
and 14 output channel pins per instance of blk_c. Test the blk_f and blk_e instances together because
they have similar complexity and channel requirements. Test the blk_d instances that require the most
channels by themselves.

Tessent™ Shell User’s Manual 135

DFT Architecture Guidelines for Hierarchical Designs
Specific Tasks That May Require Planning

Use the following guidelines when developing your test schedule:

1. Group identical core instances and run them at the same time.

2. Test cores of similar complexity and channel requirements together.

3. Test the cores that require the most channels by themselves.

Specific Tasks That May Require Planning

Every design has its unique set of tasks that you need to perform during testing. Some tasks may involve
planning while others may only require turning on or off features at the command line.
The following list provides examples of tasks that you may need to plan for ahead of time. This list is not
exhaustive.

• Dual-mode configuration for Tessent TestKompress

• Low-power mode and threshold setup

• Multiple load ATPG patterns through the memories

• Test point provisioning for extra scan chains

• Support for multiple power islands and voltage islands

• Functional timing exceptions to be read in with SDC

• Low pin count test (LPCT) controllers

• Test setup sequence to enter test mode

Sample DFT Planning Steps

There are some considerations when planning your DFT implementation.

Note:
This example may not be applicable to all designs.

1. Tally how many chip pins are available for scan channels and for ATE channels that are required
for test. Use the smaller value when planning for the number of chip pins available for test.

2. Use a dedicated test clock apart from existing functional clocks. This clock can use the TCK
signal as the clock source.

136 Tessent™ Shell User’s Manual

 DFT Architecture Guidelines for Hierarchical Designs
DFT Implementation Strategy

3. Assess the functional clock architecture for the chip and plan your OCC configuration. Consider
how many OCCs you need, their OCC types (child, parent, standard), and where they need to be
inserted for wrapped cores and the chip.

4. Based on the design size and pattern count, determine the number of channels required for each
core.

5. Determine test scheduling for cores that you can run in parallel as described in “Test Scheduling”
on page 133.

6. Determine the external mode configuration as described in “DFT Implementation Strategy” on

page 137.

7. Confirm the top-level TAM that is required.

DFT Implementation Strategy

For most designs, a few decisions can make a big difference to the overall DFT implementation
architecture.

Multiple Cores Testing in Internal and External Modes

You can test multiple cores in both internal and external modes. You must consider several factors when
testing in these modes.
Internal Mode
When you have multiple wrapped cores, fix the scan chain length at a constant value so that at the next
hierarchical level when you combine cores to be tested in parallel, the shift length is identical.
If the OCC bits are roughly 25% of the longest chain, stitch OCC bits into a few dedicated compressed
chains rather than distributing them across all of the chains. If the OCC bits add up to greater than 75%
of the longest chain, then stitch the OCC bits as an uncompressed chain. If there are any remaining OCC
bits, connect them into a compressed chain.
If there are embedded boundary scan cells present, ensure they are stitched with the rest of the boundary
scan cells at the chip level.
External Mode
The number of external mode chains from across multiple wrapped cores dictates how the chains should
be handled, for example:

• Connect the external mode chains to one EDT controller.

• Connect the external mode chains to multiple EDT controllers.

• Connect the external mode chains directly to primary pins without any EDT compression logic.
However, this can cause routing congestion.

• Connect the external mode chains when there is EDT compression logic. There may be EDT
compression logic built inside the wrapped cores for the purpose of external mode, which leads

Tessent™ Shell User’s Manual 137

DFT Architecture Guidelines for Hierarchical Designs
DFT Implementation Strategy
to having at least two pins (one input and one output) for the compression logic to be used for
external mode. This configuration eliminates routing congestion, but each EDT logic block is
required to have two pins in the external mode of each core that is connected to the chip level.
If external mode chains from various cores are to be connected to one or more EDT controllers at chip
level, then you must ensure that you balance the external mode chains so they are the same length. You
can do this by using the chain length across multiple cores.
If there are multiple levels of hierarchy and the OCC needs to be active, you may need to include the
OCC bits in the external mode. That is, if you want the OCC to be used in both internal and external
modes, then you need to plan for the OCC bits to be included in the external chain also. Typically, OCCs
are only included in internal mode.
During ATPG, you can include the boundary scan chain at chip level when running the external mode of
the wrapped cores.

Dedicated Test Clock

For hierarchical test, configure the test clock so that it does not share the functional clock port. The test
clock needs an extra pulse to initialize the EDT hardware, which disturbs the scan cells and can result in
D1 violations that cannot be fixed.
From the test clock, you can use DFT signals to generate the shift capture clock required for OCCs and
the EDT clock required for EDT hardware.
Optionally, you can use TCK as your test clock. In this case, the TAP needs to run at the TCK rate, and
the shift for ATPG is limited to the TCK frequency. Thus, you need to ensure that you are using an optimal
TCK rate.
Using a dedicated test clock aids with timing closure and is beneficial for both internal test and external
test because during shift when the scan enable signal is 1, the same clock path is chosen irrespective of
whether the core is placed in internal or external mode of operation. For more information, refer to Shift-
Only Mode under "Operating Modes" in the Tessent Scan and ATPG User’s Manual.

Automated Features Within the Tessent Shell Flow

Tessent Shell provides automated features to help you implement your DFT strategy.

• TSDB — The Tessent Shell Data Base is a common database used by all the Tessent
products, which means that test information generated by one tool is recognized and usable by
downstream tools. For details, refer to TSDB Data Flow for the Tessent Shell Flow.

• IJTAG automation — As described in “What Is Tessent Shell?” on page 27, IJTAG provides
many benefits, including DFT setup reuse from blocks and sub-blocks to higher levels in the
hierarchy. This is essential for using the bottom-up DFT insertion flow as described in “Tessent
Shell Flow for Hierarchical Designs” on page 217.

• Retargetable ATPG patterns — Using OCCs inside hierarchical cores makes the ATPG patterns
self-contained, which enables them to be retargeted as described in “On-Chip Clock Controller”
on page 129.

Note:
Using the following Tessent automated features depends on your design implementation and how
you are performing the two-pass RTL and scan DFT insertion flow for hierarchical designs as
described in “Tessent Shell Flow for Hierarchical Designs” on page 217.

138 Tessent™ Shell User’s Manual

 DFT Architecture Guidelines for Hierarchical Designs
DFT Implementation Strategy

• Reset control — Tessent automatically fixes asynchronous resets with pre-DFT DRCs that
are enabled when you set the ‑logic_test option of set_dft_specification_requirements to "on".
Tessent deactivates the reset during shift and tests the reset during capture. Optionally, provision
is provided to override the reset during capture by deactivating it. This auto-fix is beneficial when
the functional reset is generated internally.

• Boundary scan chain included for ATPG — At the chip level, you can segment the boundary
scan chain into smaller chains to be connected as compressed scan chains and controlled during
ATPG. Optionally, you can configure these boundary scan chains to participate during capture or
use them during shift.

• Use memory to target shadow logic faults during logic test — During logic test insertion,
inserted memories get bypassed. The bypass can be built within the memories themselves or
built within the MemoryBIST infrastructure. You can use IJTAG-controlled internal Test Data
Registers (TDRs) to enable bypass or to use the memories during logic test. By using the
memories during logic test, the shadow logic around the memories can be tested. This requires
an ATPG model for the memories. For details, refer to the Comprehensive RAM Primitive
information in the Tessent Cell Library Manual.

• Unused scan chains — During scan insertion and stitching if there are any over-specified scan
chains, Tessent Scan automatically adds the unused scan chains with pipeline registers. This is
beneficial when not all the scan chains of the inserted EDT compression logic are utilized.

Tessent™ Shell User’s Manual 139

DFT Architecture Guidelines for Hierarchical Designs
DFT Implementation Strategy

140 Tessent™ Shell User’s Manual

 Chapter 5
RTL DFT Analysis and Insertion
Performing DFT logic insertion at the register transfer level (RTL) provides better circuit optimization to
help meet design constraints by considering both functional and test logic simultaneously. For example,
adding observe points at RTL instead of gate level enables the tool to optimally size cells for better timing.
You can analyze the complexity of your RTL design to understand which areas could benefit from
reorganization and which are suitable for test point insertion. Pre-DFT DRC rules help you catch mistakes
early.
Provide detailed specifications of the DFT logic to meet your unique needs using commands such as
set_rtl_dft_analysis_options and set_test_point_analysis_options. The existing process_dft_specification
command inserts test points, dedicated wrapper cells, and X-bounding logic in your RTL design at the
same time as other Tessent IP, including EDT controllers, LBIST, OCC, and SSN. The incremental
analysis and insertion capabilities at the gate level enable you to fine-tune the testability logic before
generating test patterns.

RTL DFT Analysis in the Overall Flow

RTL Design Rule Checks
RTL IP Insertion
RTL Design Assessment
Preparations for RTL DFT Analysis
Test Point Analysis at RTL
Test Point Insertion at RTL
Specifying RTL Test Points With Tessent Shell Commands
Observation Scan Type of Test Point
Test Point Implementations
Test Points as Function Calls
How to Preserve DFT Logic Inserted at RTL
How to Report Logic Excluded From Test Point Analysis
X-Bounding Analysis and Insertion at RTL
Wrapper Analysis and Dedicated Wrapper Cell Insertion at RTL
Smart Uniquification for RTL Pro
Incremental Insertion
Limitations of RTL DFT Analysis and Insertion

RTL DFT Analysis in the Overall Flow

Performing DFT analysis early in the Tessent Shell workflow provides insight for later steps.
Figure 19 shows the overall test logic insertion flow. In the diagram, MemoryBIST refers to memory built-
in self test (MBIST) logic, LBIST refers to hybrid TK/LBIST IP, and OCC refers to on-chip clock controllers.

Tessent™ Shell User’s Manual 141

RTL DFT Analysis and Insertion
RTL Design Rule Checks

Note:
We recommend running RTL DFT analysis between the second insertion pass of TK/LBIST and
OCC and before synthesis. This enables you to insert the DFT signals for EDT logic and test
points before performing test point insertion. When you insert TK/LBIST or EDT before test points,
you must account for additional scan cells when sizing the EDT IP.

Figure 19. RTL DFT Analysis in the Overall Insertion Flow

You can perform RTL DFT analysis as part of a flow for flat, hierarchical, or tiled designs. Refer to Tessent
Shell Flow for Flat Designs, Tessent Shell Flow for Hierarchical Designs, and How the DFT Insertion
Flow Applies to Hierarchical Designs for more information about the full flow. X-bounding and test point
insertion can be performed at the chip, physical block, or sub-block level.

Note:
We recommend that you run wrapper analysis at the physical block level.

RTL Design Rule Checks

Before inserting DFT logic in an RTL design, perform design rule checks (DRCs) to prevent errors later in
the flow.

Note:
You must run the set_dft_specification_requirements ‑logic_test on command before running the
check_design_rules command to apply pre-DFT rules to your RTL design.

The following rules are particularly important for RTL designs:

142 Tessent™ Shell User’s Manual

 RTL DFT Analysis and Insertion
RTL IP Insertion

• DFT_C6 — Runs with the check_design_rules command and verifies that each scannable flip-
flop clock port has a defined clock in its controlling fan-in.

• DFT_C9 — Runs with the check_design_rules command and verifies that it is possible to disable
the asynchronous set or reset pin of each scannable flip-flop.

• E5 — Runs with the check_design_rules command and verifies the floating and constant logic (in
RTL mode).

• SW7 — Runs automatically with the analyze_wrapper_cells command and checks for
valid locations to insert dedicated wrapper cells that comply with all specifications and tool
requirements.

• SW8 — Runs automatically with the analyze_wrapper_cells command and checks that locations
to insert dedicated wrapper cells are editable RTL constructs.

• XB3 — Runs automatically with the analyze_xbounding command and checks that locations to
insert X-bounding logic are editable RTL constructs.
As an additional check, you can use the -validate_only option on the process_dft_specification command
to check the DftSpecification for the Tessent IP without inserting it.

RTL IP Insertion
Use one general process for RTL insertion of all Tessent intellectual property (IP), such as MBIST, EDT,
LBIST, test points, and SSN. Repeat the steps outlined in this section in multiple passes corresponding to
different combinations of IP and levels of hierarchy.
Use the following steps to insert the IP at RTL:

1. Set up your work area by setting the context to dft -rtl, setting the design level, and loading any
required libraries. Refer to “Tessent Shell Workflows” on page 189.

2. Load your RTL design, by either reading the source code for the first time or reading the design in
progress from the TSDB files. Refer to “Loading the Design” on page 199.

3. Check design rules with each subsequent step. Refer to “RTL Design Rule Checks” on
page 142.

4. Specify the DFT logic and options you want to insert in this pass.

a. Define important signals using the add_dft_signals command.

b. Specify options to configure the IP, the optimization algorithms, and the generation process.
The exact commands depend on the IP you are inserting. Refer to “Table 16” on page 144
for a list of references.

Tessent™ Shell User’s Manual 143

RTL DFT Analysis and Insertion
RTL IP Insertion

c. Specify the large IP modules such as MBIST, EDT, LBIST controllers, IJTAG, and SSN
networks. Refer to Configuration-Based Specification in the Tessent Shell Reference Manual.

d. (Optional) Create post-insertion procs that perform design editing. Refer to “First DFT
Insertion Pass: Top With MemoryBIST, BISR, and Boundary Scan” on page 449.

5. Run analysis algorithms for optimal insertion, if required.

Note:
This step is required for Tessent DFT logic such as test points (analyze_test_points),
X‑bounding (analyze_xbounding), and wrapper cells (analyze_wrapper_cells). It does not
apply for IP that you specify completely, such as in-system test and LBIST.

6. Insert the IP in your RTL design by running the process_dft_specification command.

7. Prepare for synthesis by following the steps in “How to Set Up Third-Party Synthesis” on
page 733 and “How to Preserve DFT Logic Inserted at RTL” on page 170.
Refer to “Tessent Shell Workflows” on page 189 and “Tessent Shell Automotive Workflow” on
page 405 for examples of these steps applied to various design styles and situations.
Your unique design needs may require a combination of command options and DftSpecification
properties. Refer to the individual IP documentation for details on how to configure the IP for insertion in
your RTL design.

Table 16. Tessent IP Configuration and Insertion Instructions

Tessent DFT IP RTL Configuration and Insertion Instructions

Boundary Scan "Getting Started With Tessent BoundaryScan" in the Tessent

BoundaryScan User’s Manual

Compression (EDT) "Integrating Compression at the RTL Stage" in the Tessent

TestKompress User’s Manual

Dedicated Wrapper Cells “Wrapper Analysis and Dedicated Wrapper Cell Insertion at RTL” on
page 176

IJTAG "IJTAG Network Insertion" in the Tessent IJTAG User’s Manual

In-System Test "IP Insertion and Configuration" in the Tessent In-System Test User’s
Manual

LBIST "EDT and LogicBIST IP Generation" in the Hybrid TK/LBIST Flow

User’s Manual

MBIST "Planning and Inserting MemoryBIST" in the Tessent MemoryBIST

User’s Manual

On-Chip Clock Control (OCC) "Tessent On-Chip Clock Controller" in the Tessent Scan and ATPG
User’s Manual

144 Tessent™ Shell User’s Manual

 RTL DFT Analysis and Insertion
RTL IP Insertion

Table 16. Tessent IP Configuration and Insertion Instructions (continued)

Tessent DFT IP RTL Configuration and Insertion Instructions

Streaming Scan Network “Tessent SSN Workflows” on page 484

(SSN)

Test Points “Test Point Analysis at RTL” on page 154

X-Bounding “X-Bounding Analysis and Insertion at RTL” on page 174

Tessent™ Shell User’s Manual 145

RTL DFT Analysis and Insertion
RTL Design Assessment

RTL Design Assessment

Tessent can assess your RTL design to give you in-depth information about the design and guide the DFT
logic insertion process.
The tool reports two global scores: RTL code complexity and RTL test point suitability. For each hierarchy
level, the RTL code complexity score is computed to guide any RTL refactoring efforts because it points to
the most important modules of the design. Each score reflects distinct aspects of the design, as described
in the following sections.
In addition to the scores, the report lists several key design metrics, both as global statistics and on a per-
instance basis. When reading the reports, you need to understand how your RTL code corresponds to the
tool’s internal design representation down to gate-level nodes.
You can browse the RTL complexity score and design metrics in Tessent Visualizer. For more information,
refer to “RTL Metrics Browser” on page 908.

RTL Code Complexity Score

RTL Test Point Insertion Suitability Score
Detailed Metrics
Gate Node Location Types

RTL Code Complexity Score

The RTL code complexity score reflects the difficulty of analyzing, testing, and modifying each module in
the RTL design.
The Tessent solution derives the metrics required to compute the complexity score directly from the parse
tree of elaborated RTL code. The chosen metrics provide an accurate cross-section of complexity. These
metrics include a measure of the cyclomatic complexity of a module and the sub-modules.
A significant factor affecting the RTL code complexity score is the number of complex and nested control
statements within each concurrent statement (such as “always” blocks or similar RTL constructs).
Structuring the code with relatively few complex constructs within each concurrent statement results in a
lower complexity score and a design that may be more testable.
Designs that concentrate more complex statements (meaning a larger amount of logic) inside relatively
fewer concurrent statements receive a higher complexity score. An extreme example is a design with
concurrent statements that contain so much complexity that the gate-level representation does not map
back to the RTL. A very high complexity makes it difficult for the tool to identify locations for test point
insertion
In addition, complex code is typically more difficult to maintain.
To simplify the RTL quality evaluation, the tool divides the RTL code complexity score into four levels as
shown in Table 17:

Table 17. RTL Code Complexity Score

Editable Nodes (visible RTL nets and

Score Likely Maintenance Effort expression boundaries)

Low Low High percentage

146 Tessent™ Shell User’s Manual

 RTL DFT Analysis and Insertion
RTL Test Point Insertion Suitability Score

Table 17. RTL Code Complexity Score (continued)

Editable Nodes (visible RTL nets and

Score Likely Maintenance Effort expression boundaries)

Medium Medium Medium percentage

High High Low percentage

Very High Very high Very low percentage

Limiting Complexity During Development

Monitor the complexity of the modules and concurrent statements during development. RTL designers
should consider splitting modules into smaller sub-modules or constructs whenever the cyclomatic
complexity exceeds a threshold, in accordance with the NIST Structured Testing methodology in software
engineering.

RTL Test Point Insertion Suitability Score

The RTL test point insertion suitability score is a metric derived after performing code complexity analysis.
To be effective, the areas requiring RTL test point insertion must be in editable locations. Even if a design
has a “Low” complexity score, if you need most of the new test points in noneditable functional blocks
or control logic, the test point suitability may be low. The inverse also holds: a highly complex block may
require test points only in the editable nodes of the design, making the test point suitability score “High”.
The tool computes the suitability score for RTL test point insertion globally. This is done top-down for the
whole design. The score is primarily based on RTL code complexity scores for every instance across the
logic hierarchy. For every instance level, the tool adjusts the complexity score metric by considering pre-
test point analysis metrics. Example metrics include the total number of testable gate nodes and the total
editable testable gate nodes. Refer to Gate Node Location Types for more information.
To simplify the RTL suitability evaluation, the tool divides the RTL test point suitability score into three
levels:

Table 18. RTL Test Point Insertion Suitability Score

Editable Nodes
(visible RTL nets Recommended Insertion Flow to Improve ATPG and BIST
Score and expression Metrics
boundaries)

High High percentage RTL level

Medium Medium percentage RTL insertion likely enhances the testability of the block.
Gate-level insertion may provide higher testability.

Low Low percentage Gate level

If the sub-blocks have many logic elements tied constant or left floating, the tool can increase the
suitability score by optimizing the sub-blocks’ content. A design with many sub-blocks with “High” RTL
code complexity does not necessarily have a “Low” suitability score.
For example, consider the hierarchical design in Figure 20.

Tessent™ Shell User’s Manual 147

RTL DFT Analysis and Insertion
Detailed Metrics

Figure 20. Example Hierarchical Design

with the RTL code complexity:

• M1, M3: Medium

• M2: High

• Top: Low
The code complexity score of module M2 might be considered “Low” if the number of testable editable
nodes become a high percentage after excluding the constant and floating nodes. This transformation
impacts the computation of the global RTL test point suitability score of the design. The result may be
“High” RTL insertion suitability scores.

Detailed Metrics
RTL code complexity analysis provides detailed metrics on your RTL design.
The code complexity analysis provides a summary code complexity score, a summary test point suitability
score, and design metrics. The available design metrics change depending on when you perform
complexity analysis:

• Prior to quick synthesis, the tool reports only high-level information about your design:

◦ Overall RTL complexity score

◦ Design profile

• Identification of RTL and structural modules within the RTL

• Number of black boxes

• Total design instances

◦ Library profile

148 Tessent™ Shell User’s Manual

 RTL DFT Analysis and Insertion
Detailed Metrics

• Number of Synopsys DesignWare® modules and instances

• Number of Tessent library modules and instances

• After quick synthesis, the tool reports additional information:

◦ Overall test point suitability score

◦ Library profile

• Number of directly instantiated and synthesized sequential cells

• Number of constant and floating cells

◦ Detailed design pin information:

• Number of gate nodes

• Number of gate nodes at expression boundaries

• Number of gate nodes inside functional blocks

• Number of gate nodes at control logic

• Number of floating gate nodes

• Number of tied constant gate nodes

• Number of gate nodes within DesignWare

• After test point analysis, the tool also reports the number of test points targeted for visible nodes
and expression boundaries.

• Then, after test point insertion, the tool also reports the number of test points collapsed to inside
control logic and functional blocks.

• You can run complexity analysis in a high-effort mode to provide greater detail as part of the
complexity report after quick synthesis. Refer to the report_rtl_complexity command for more
information.
When you run complexity analysis with the “-effort high” option, the tool performs test point
analysis but not insertion. It considers the entire design for test points, and compares the analysis
to the editable RTL nodes. Metrics included in the high-effort report:

Tessent™ Shell User’s Manual 149

RTL DFT Analysis and Insertion
Gate Node Location Types

◦ Information about test points that target editable nodes of the RTL

• Number of test points targeted to directly visible nodes

• Number of test points targeted to expression boundaries

◦ Information about test points that target non-editable nodes of the RTL

• Number of test points targeted to functional blocks

• Number of test points targeted to control logic

Gate Node Location Types

In RTL mode, the tool performs test point analysis after Tessent quick synthesis has transformed the
input RTL design to a gate level netlist. The netlist view becomes the basis of all test point locations. This
section describes how the gate-level nodes correspond to the RTL.
While searching for RTL locations to insert control points (CP) and observe points (OP), the tool may
encounter several distinct types of gate nodes. The get_rtl_location_type command returns the type of
specific objects including gate nodes in the design. The following are types of gate nodes:

• Gate nodes directly mapped to RTL nets — Examples include nets, and port pins declared and
visible at RTL. These gate nodes are fully editable, and the tool can insert test points at the gate
node locations of the closet visible RTL nets. The Example shows these RTL constructs in green
text.
The tool inserts the CP/OP at stems instead of branches. When dealing with directly visible
nodes, the tool targets individual stems instead of branches. With RTL, the same statement or
equation may be used multiple times. In that case, if multiple test points target the same stem in
different locations in the RTL, Tessent merges the multiple stem test points into a single branch
test point.

• Gate nodes directly mapped to RTL expression boundaries — Examples include RTL sub-
expressions. These gate nodes are fully editable, and Tessent can insert CPs and OPs at the
boundaries of RTL expressions and sub-expressions. Because these expressions typically use
the same variables, Tessent considers branch locations during analysis. The Example shows
these RTL constructs in red text.

• Gate nodes mapped inside functional blocks — Examples include adders. These gate nodes
are not editable, and the tool cannot insert test points.

• Gate nodes mapped inside control logic — Examples of sequential control statements include
if-then-else and case. These gate nodes are not editable, and the tool cannot insert test points.
The Example shows these RTL constructs in blue text.

Example
This example illustrates the terminology:

150 Tessent™ Shell User’s Manual

 RTL DFT Analysis and Insertion
Gate Node Location Types

module top (input wire clk,

input wire reset_h,
input logic data_in1,
input logic data_in2,
output logic data_out);
always_ff @(posedge clk) begin
if (reset_h == 1'b1)
data_out <= '0;
else
data_out <= (data_in1 & data_in2) | data_in2;
end
endmodule

Figure 21. Example Design

Table 19. Gate Node Location Mapping

Terminology Description Example Names

Gate instances Cell instances inferred by quick rtlc0_2, rtlc_16, rtlc_15, rtlc_14,
synthesis rtlcreg_data_out

Gate nodes (pins) Pins of cells instances inferred by rtlc0_2/A, rtlc0_2/B,

quick synthesis to represent the rtlc0_2/Z, rtlc_16/A,
input/output of inferred logic rtlc_16/B, rtlc_16/Z, rtlc_15/A,
rtlc_15/B, rtlc_15/Z, rtlc_14/A,
Primary inputs/outputs rtlc_14/Z, rtlcreg_data_out/D,
rtlcreg_data_out/CP,
rtlcreg_data_out/Q,clk, data_in1,
data_in2, data_in3, reset_h,
data_out

Branch All gate nodes (pins) can be rtlc0_2/A, rtlc0_2/B

considered as branches

Stem Root source signal of one or data_in2 is the stem of rtlc0_2/B

more branches and rtlc_16/B.
clk is stem of rtlcreg_data_out/CP.

Visible RTL nets All nets or portNets represented clk, data_in1, data_in2, data_out,
by RTL signals; both internal nets reset_h
of ports and pure nets.

Tessent™ Shell User’s Manual 151

RTL DFT Analysis and Insertion
Gate Node Location Types

Table 19. Gate Node Location Mapping (continued)

Terminology Description Example Names

RTL expressions (sub- All RTL expressions such as Expression 1: (reset_h == 1'b1)
expression) arithmetic, logical, and function
calls Expression 2: (data_in1 &
data_in2)
Expression 3: (data_in1 &
data_in2) | data_in2
Corresponding gate instances are:
Expression 1: rtlc_14
Expression 2: rtlc0_2
Expression 3: rtlc0_2, rtlc_16

Control logic vs Control All logic inferred to represent

statements the control statements in RTL if (…) begin
such as if-then-else, case, and …
read/write expressions end else begin
…
end;

This control statement is

represented by the gate instances:
rtlc_15. This logic is controlled by
the reset signal "reset_h".

Functional Blocks All logic inferred to represent

complex operators are named
functional blocks, for example:
==, !=, +, -, *, /, >=, <=, <, >

From the example, the tool may identify the following editable testable gate nodes (pins) as potential CPs
and OPs:

• rtlc0_2/A

• rtlc0_2/B

• rtlc0_2/Z

• rtlc_16/A

• rtlc_16/B

• rtlc_16/Z

• rtlcreg_data_out/Q

• data_in1

152 Tessent™ Shell User’s Manual

 RTL DFT Analysis and Insertion
Preparations for RTL DFT Analysis

• data_in2

• data_out
The tool identifies the gate nodes (pins) on the clock and reset paths as editable but not testable and not
suitable as potential test points. Example untestable gate nodes:

• clk

• rtlcreg_data_out/CP

• reset_h

• rtlc_14/A

• rtlc_14/Z

Preparations for RTL DFT Analysis

RTL DFT analysis shares many common steps with gate-level DFT insertion such as setting options,
running analysis, and reporting results before insertion. However, performing analysis and insertion of
wrapper cells, X-bounding logic, and test points in RTL requires unique preparations.

Pre-DFT DRCs
Your design must pass the pre-DFT design rule checks (DRCs). Refer to “RTL Design Rule Checks” on
page 142 for more information.

DFT Analysis Options

You can exclude parts of the RTL such as floating logic, tied logic, and non-editable nodes. For more
information, refer to the set_rtl_dft_analysis_options command in the Tessent Shell Reference Manual.

RTL Complexity Analysis

Identify RTL Complexity and TPI Suitability using the report_rtl_complexity command described in the
Tessent Shell Reference Manual.

Handling Known Non-Scan Elements

Inserting DFT logic at the register transfer level requires all sequential elements to pass scannability
checking, including clock/set/reset controllability checks. Therefore, non-scan elements must be defined
to pass DRC for any cells which would not be scanned later in the flow.

Tip
Use a consistent naming convention such as a prefix for non-scan elements and use the
introspection commands to find them.

To refer to non-scan elements in the RTL code, use the add_nonscan_instances command with the
-rtl_reg switch. For example:

Tessent™ Shell User’s Manual 153

RTL DFT Analysis and Insertion
Test Point Analysis at RTL

add_non_scan_instances -rtl_reg [get_nets ${<nonscan_prefix>}* -hierarchical]

This example identifies instantiated non-scan elements:

add_non_scan_instances -instances [get_instances ${<nonscan_prefix>}* -hierarchical]

Quick Synthesis
Control quick synthesis options with the set_quick_synthesis_options command. Options include adding
parallel synthesis and skipping synthesis of large two-dimensional arrays.

DFT-Inserted RTL Written to TSDB

The tool saves the modified RTL to the Tessent Shell database (TSDB).

Test Point Analysis at RTL

Tessent RTL Pro enables you to analyze your RTL design for potential test point locations and optimize
your strategy before insertion.
You can choose the goals of test point analysis by running the set_test_point_types command in setup
mode. The tool can optimize for LBIST test coverage or deterministic test pattern count, or both. Refer to
"Test Point Usage Scenarios" in the Scan and ATPG User’s Manual.
Specify your test point requirements using the set_test_point_analysis_options command. Optionally, you
can add your own test points using the add_control_points and add_observe_points commands or restrict
areas using the add_notest_points commands. These commands run in the dft -rtl -test_points context for
RTL insertion.
When you transition from setup to analysis mode, the tool automatically runs quick synthesis to generate
a gate-level view of the RTL design. The tool builds the netlist view and marks all gate pins to be
excluded from test point insertion based on the options you specify with the set_rtl_dft_analysis_options
command. When you run the analyze_test_points command in analysis mode in the dft -rtl -test_points
context, the tool chooses the test point locations, which it inserts later in the process. It maps those test
point locations based on the gate-level view back to RTL.
You can evaluate the results of test point analysis before insertion by running the report_test_points
command. You can iterate the analysis process by returning to setup mode and setting different options.
The tool automatically cleans up test point locations if you switch back to setup mode ands keeps them
while you stay in analysis mode.
After identifying the optimal settings for your RTL design, Tessent RTL Pro can insert those test points at
RTL. Refer to “Test Point Insertion at RTL” on page 155 for more information.
For more in-depth information about test points, refer to the following topics in the Tessent Scan and
ATPG User’s Manual:

• What are Test Points?

• Test Points Special Topics

154 Tessent™ Shell User’s Manual

 RTL DFT Analysis and Insertion
Test Point Insertion at RTL

Test Point Insertion at RTL

The tool inserts the test points it identified with the analyze_test_points command and those you
specified with the add_control_points and add_observe_points commands when you run the
process_dft_specification command.
You must run the set_current_design command before starting test point insertion.
Control the test point insertion using the following commands in the "dft -rtl -test_points" context:

• set_test_point_analysis_options

• set_test_point_insertion_options

• set_test_point_sharing_restrictions
The following example uses the set_current_design command to select the portion of the design for test
point insertion, the analyze_test_points command to automatically identify where to insert control points
and observe points, and the process_dft_specification command to insert the test points:

set_context dft -rtl -test_points -design_id rtl1

read_cell_library <library_path>/NangateOpenCellLibrary.atpglib \
../data/picdram.atpglib
read_verilog ../data/piccpu1.v
read_verilog ../data/picdram.v -blackbox -exclude
read_cell_library ../data/cell_selection
set_cell_library_options -default_dft_cell_selection tc_selection

set_current_design piccpu1
set_design_level physical_block

add_clocks 0 clk
add_clocks 0 ramclk
add_black_box -instance bbox

check_design_rules

analyze_test_points

report_test_points

create_dft_specification
process_dft_specification

Test Point Sharing

To enable test point sharing, use the set_test_point_analysis_options command to specify the
‑shared_control_points_per_flop and -shared_observe_points_per_flop options. For more information,
refer to the "Test Point Sharing" section of the Tessent Scan and ATPG User’s Manual.
A limitation at RTL involves an observe point (OP) within the clocked always statement at the boundary
of an expression. Within the always statement, the tool makes an assignment to the test data output

Tessent™ Shell User’s Manual 155

RTL DFT Analysis and Insertion
Specifying RTL Test Points With Tessent Shell Commands
that observes the expression. Synthesis automatically infers a flip-flop that cannot be shared with other
observe points.
For example, consider an OP at the expression "in1 & in2" in the following RTL code:

always_ff @(posedge clk , negedge reset )

if ( !reset )
done_sm_ps <= NOT_DONE ;
else
done_sm_ps <= in1 & in2;

The tool creates the following RTL after test point insertion:

reg [0:0] tessent_persistent_cell_op_test_out_1;

always_ff @(posedge clk , negedge reset )
if ( !reset )
done_sm_ps <= NOT_DONE ;
else
done_sm_ps <= InsertObservePointOutput(in1 & in2, op_en,
tessent_persistent_cell_op_test_out_1);

top_rtl_tp_op_holder tessent_persistent_cell_op_holder_instance_1
(.funcin(tessent_persistent_cell_op_test_out_1), .ff_out());

function logic InsertObservePointOutput(input logic sig_in,

input logic TM,
output logic test_out);
test_out = sig_in & TM;
return sig_in;
endfunction

Synthesis infers the flip-flop of this observe point by the test data output
signal "tessent_persistent_cell_op_test_out_1". The output of the flip-flop
"tessent_persistent_cell_op_test_out_1" connects to an empty instance
"tessent_persistent_cell_op_holder_instance_1" that does not include a flip-flop. When Tessent detects
this kind of observe point, it automatically transforms it to a regular OP, and does not share the same flip-
flop with other OPs in the same group.

Specifying RTL Test Points With Tessent Shell

Commands
You can use the add_observe_points and add_control_points commands in the "dft -rtl ‑test_points"
context to add test points on RTL ports, pins, and nets.
Use these commands to specify observe points and control points to be inserted in RTL when you run the
process_dft_specification command.

Example
set_context dft -rtl -test_points

read_verilog ../prerequisites/insert_test_point_logic.tshell/rtl/tp.v

156 Tessent™ Shell User’s Manual

 RTL DFT Analysis and Insertion
Observation Scan Type of Test Point
read_verilog -format sv2009 ../data/pkg1.sv
read_verilog -format sv2009 ../data/top1.sv

set_current_design top
add_clocks 0 clk
add_clocks 1 rstn
check_design_rules

add_control_points -location IF1.mode[0] -type AND \

-enable ts_control_enable -clock clk
add_observe_points -location IF1.mode[2] \
-enable ts_observe_enable -clock clk

analyze_test_points

create_dft_specification
process_dft_specification

Observation Scan Type of Test Point

The observation scan type (OST) is an observe test point type for use in the RTL context that stitching
tools can connect into scan chains.
Tessent scan technology inserts OST observe points in RTL by either instantiating a scan cell or
describing the behavior of the scan cell. The tool exports information to enable the stitching of these cells
into separate scan chains.
The OST uses a positive-edge scan flip-flop RTL cell, the PosedgeSff.

Process
Use the following process to add OST observe points in RTL.

• Use the set_context dft -test_points -rtl command.

• Add the capture_per_cycle_static_en DFT signal in SETUP mode.

• Use the set_test_point_analysis_options -capture_per_cycle on command.

• Use the "set_test_point_analysis_options -minimum_shift_length" command.

• Run test point analysis with the analyze_test_points command.

Note:
The tool requests an LBIST-OST license.

• Insert OSTs by running the process_dft_specification command.

• Use the "set_context dft -rtl" command.

Tessent™ Shell User’s Manual 157

RTL DFT Analysis and Insertion
Observation Scan Type of Test Point

• Synthesize the RTL design.

• Use the "set_context dft -scan -no_rtl" command.

• Insert scan chains.

Note:
After inserting test logic, you can synthesize the design. The behavioral scan cell flip‑flops
must have the set_dont_scan mark to prevent the synthesis tool from replacing them with
scan flip-flops.
The OST observe points must have the set_preserve_boundary mark to prevent their
removal by synthesis tool optimizations. The other observe and control test point types
also use this mark during synthesis.

This flow is analogous to the post-synthesis insertion flow in the "dft -scan -test_points" context.

Inserting OST Modules

After test point analysis is complete, insert OST test point logic using the process_dft_specification
command,. The use_rtl_cells property of the DftSpecification wrapper affects the RTL implementation.
Figure 22 shows an example of the logic that process_dft_specification inserts when use_rtl_cells is off.
The logic module code follows the figure.

Figure 22. Schematic of an OST Module (use_rtl_cells : off)

module cb_oc_rtl1_tp_osp(funcin, tp_en, op_clk, cpc_en, si, se, q);

input funcin, tp_en, op_clk, cpc_en, si, se;
output q;

assign gatedFuncIn = funcin & tp_en;

assign cpcGatedFuncIn = gatedFuncIn & cpc_en;
assign siXored = cpcGatedFuncIn ^ si;
assign qXored = q ^ gatedFuncIn;
SDFFHX2 ts_0_osp_sff (
.D ( qXored ),
.CK ( op_clk ),
.SI ( siXored ),

158 Tessent™ Shell User’s Manual

 RTL DFT Analysis and Insertion
Observation Scan Type of Test Point
.SE ( se ),
.Q ( q )
);
endmodule

The process_dft_specification command inserts behavioral code for the ts_0_osp_sff scan flip-flop in
Figure 22 if use_rtl_cells is on. The code is a pos-edge RTL scan cell, PosedgeSff.

module cb_oc_rtl1_tp_tessent_posedge_scan_cell (
input wire d,
input wire si,
input wire se,
input wire clk,
output reg so
);
wire mux_net;
assign mux_net = (se) ? si : d;
always @ (posedge clk) begin
so <= mux_net;
end
endmodule

You can substitute the PosedgeSff behavioral cells with actual scan cells later in the flow.

Inserting OSTs Inside Expressions

After test point analysis is complete, the tool inserts OST observe points inside expressions using a
function call.
For example, if you want to insert an OST on !data_conflict in the following expression:

wire ready_no_conflict = (!data_conflict || resolve_enable) &&

(stored_cycle ? match : !match);

The insertion process creates the InsertObservePointV95 function call and modifies the expression to use
it:

function InsertObservePointV95;
input sig_in;
input TM;
begin
InsertObservePointV95 = sig_in & TM;
end
endfunction
assign ts_temp_0 = (!data_conflict);

wire ready_no_conflict = (ts_temp_0 || resolve_enable) &&

(stored_cycle ? cycle_match : !cycle_match);

assign ts_0_osp_test_out_1_0 = InsertObservePointV95(ts_temp_0,

observe_test_point_en);

cb_oc_rtl1_tp_sff_osp ts_0_osp_dff_instance_1_0_0 (
.clk(clk_ts1),

Tessent™ Shell User’s Manual 159

RTL DFT Analysis and Insertion
Observation Scan Type of Test Point
.ff_in(ts_0_osp_test_out_1_0),
.cpc_en(capture_per_cycle_en_out),
.se(1'b0),
.si(1'b0),
.q()
);

Figure 23 shows the schematic of the cb_oc_rtl1_tp_sff_osp cell and how it includes the rest of the OST
scan cell.

Figure 23. Partial Schematic of an OST for an Expression

Stitching OSTs Into Scan Chains

The scan cell within the OST already has logic in the scan-in path, which prevents the replacement of
a D flip-flop with a scan flip-flop. Instead, the tool generates a TCD scan file for all OSTs during RTL
generation in the dft -rtl context. The tool automatically imports this file in the dft -scan context.
The flow must stitch all OSTs into separate scan chains from the normal scan cells. The tool can stitch the
observation scan cells correctly when the module_type property value is observation_scan_cell.
The following is an example TCD scan file, cb_oc_rtl1_tp_tessent_osp.tcd_scan, for an observation scan
cell. An example path to the file is tsdb_outdir/instruments/cb_oc_rtl1_tp_rtl_scan_dft_logic.instrument/.

Core(cb_oc_rtl1_tp_tessent_osp) {
Scan {
module_type : observation_scan_cell;
is_hard_module : 1;
internal_scan_only : 0;
traceable : 0;
Clock(op_clk) {
off_state : 1'b0;
}
ScanEn(se) {
active_polarity : all_ones;
}
ScanChain {
length : 1;
scan_in_port: si;
scan_out_port: q;

160 Tessent™ Shell User’s Manual

 RTL DFT Analysis and Insertion
Test Point Implementations
scan_in_clock: op_clk;
scan_out_clock: op_clk;
}
}
}

The tool can generate a CTL file for third-party scan insertion.

Limitations
Insertion of scan cells inside always-clocked logic blocks is not yet possible. If you try to insert an OST
observe point inside an always-clocked logic block, the tool replaces it with a regular test point.

Test Point Implementations

The tool implements test points by instantiating control point and observe point flip‑flops using the cell
versions you specified with the read_cell_library command. You can use the DftSpecification/use_rtl_cells
property to force the tool to generate behavioral flops using RTL always statements in the RTLCells
instrument directory.

DftSpecification(module_name,id) {
…
use_rtl_cells : on | off | auto ;
…
}

Examples
Example 1
This example specifies "use_rtl_cell on":

set_context dft -rtl -test_points -design_id rtl1

read_cell_library ../45nm/Tessent/NangateOpenCellLibrary.atpglib \
../data/picdram.atpglib
read_verilog ../data/piccpu1.v
read_verilog ../data/picdram.v -blackbox -exclude
read_cell_library ../data/cell_selection
set_cell_library_options -default_dft_cell_selection tc_selection

set_current_design piccpu1
set_design_level physical_block

add_clocks 0 clk
add_clocks 0 ramclk
add_black_box -instance bbox

check_design_rules

analyze_test_points

Tessent™ Shell User’s Manual 161

RTL DFT Analysis and Insertion
Test Point Implementations
report_test_points
set_defaults_value DftSpecification/use_rtl_cells on
set spec [create_dft_specification -replace]
process_dft_specification

The control point and observe point instruments instantiate the RTL behavior version of the DFF defined
in the RTLCells directory as follows:

module dff_cp(clk, ff_out);

input clk;
wire clk;
output ff_out;
wire ff_out;
piccpu1_rtl2_tessent_posedge_dff ts_0_cp_dff (
.d ( ff_out ),
.clk ( clk ),
.q ( ff_out )
);
endmodule
module dff_op(clk, ff_in);
input clk;
wire clk;
input ff_in;
wire ff_in;
piccpu1_rtl2_tessent_posedge_dff ts_0_op_dff (
.d ( ff_in ),
.clk ( clk ),
.q ( )
);
endmodule
module cpor(funcin, tp_en, cp_clk, cp_out);
input funcin;
input tp_en;
input cp_clk;
wire funcin;
wire tp_en;
wire cp_clk;
output cp_out;
wire ff_out;
piccpu1_rtl2_tessent_posedge_dff ts_0_cp_dff (
.d ( ff_out ),
.clk ( cp_clk ),
.q ( ff_out )
);
assign cp_out = (tp_en & ff_out) | funcin;
endmodule
module cpand(funcin, tp_en, cp_clk, cp_out);
input funcin;
input tp_en;
input cp_clk;
wire funcin;
wire tp_en;
wire cp_clk;

162 Tessent™ Shell User’s Manual

 RTL DFT Analysis and Insertion
Test Point Implementations
output cp_out;
wire cp_out;
wire ff_out;
piccpu1_rtl2_tessent_posedge_dff ts_0_cp_dff (
.d ( ff_out ),
.clk ( cp_clk ),
.q ( ff_out )
);
assign cp_out = (~tp_en | ff_out) & funcin;
endmodulemodule op(funcin, tp_en, op_clk);
input funcin, tp_en, op_clk;
wire funcin, tp_en, op_clk;
piccpu1_rtl2_tessent_posedge_dff ts_0_op_dff (
.d ( funcin & tp_en ),
.clk ( op_clk ),
.q ( )
);
endmodule

Example 2
This example specifies "use_rtl_cell off":

set_context dft -rtl -test_points -design_id rtl1

read_cell_library ../45nm/Tessent/NangateOpenCellLibrary.atpglib \
../data/picdram.atpglib
read_verilog ../data/piccpu1.v
read_verilog ../data/picdram.v -blackbox -exclude
read_cell_library ../data/cell_selection
set_cell_library_options -default_dft_cell_selection tc_selection

set_current_design piccpu1
set_design_level physical_block

add_clocks 0 clk
add_clocks 0 ramclk
add_black_box -instance bbox

check_design_rules

analyze_test_points

report_test_points
set_defaults_value DftSpecification/use_rtl_cells off
set spec [create_dft_specification -replace]
process_dft_specification

The control point and observe point instruments instantiate the available cells as follows:

module dff_cp(clk, ff_out);

input clk;
wire clk;
output ff_out;

Tessent™ Shell User’s Manual 163

RTL DFT Analysis and Insertion
Test Point Implementations
wire ff_out;
DFF_X2 ts_0_cp_dff (
.D ( ff_out ),
.CK ( clk ),
.Q ( ff_out )
);
endmodule
module dff_op(clk, ff_in);
input clk;
wire clk;
input ff_in;
wire ff_in;
DFF_X2 ts_0_op_dff (
.D ( ff_in ),
.CK ( clk ),
.Q ( )
);
endmodule
module cpor(funcin, tp_en, cp_clk, cp_out);
input funcin;
input tp_en;
input cp_clk;
wire funcin;
wire tp_en;
wire cp_clk;
output cp_out;
wire ff_out;
DFF_X2 ts_0_cp_dff (
.D ( ff_out ),
.CK ( cp_clk ),
.Q ( ff_out )
);
assign cp_out = (tp_en & ff_out) | funcin;
endmodule
module cpand(funcin, tp_en, cp_clk, cp_out);
input funcin;
input tp_en;
input cp_clk;
wire funcin;
wire tp_en;
wire cp_clk;
output cp_out;
wire cp_out;
wire ff_out;
DFF_X2 ts_0_cp_dff (
.D ( ff_out ),
.CK ( cp_clk ),
.Q ( ff_out )
);
assign cp_out = (~tp_en | ff_out) & funcin;
endmodule
module op(funcin, tp_en, op_clk);
input funcin, tp_en, op_clk;

164 Tessent™ Shell User’s Manual

 RTL DFT Analysis and Insertion
Test Points as Function Calls
wire funcin, tp_en, op_clk;
DFF_X2 ts_0_op_dff (
.D ( funcin & tp_en ),
.CK ( op_clk ),
.Q ( )
);
endmodule

Example 3
This example specifies "use_rtl_cell auto":

set_context dft -rtl -test_points -design_id rtl1

read_cell_library ../45nm/Tessent/NangateOpenCellLibrary.atpglib \
../data/picdram.atpglib
read_verilog ../data/piccpu1.v
read_verilog ../data/picdram.v -blackbox -exclude
read_cell_library ../data/cell_selection
set_cell_library_options -default_dft_cell_selection tc_selection

set_current_design piccpu1
set_design_level physical_block

add_clocks 0 clk
add_clocks 0 ramclk
add_black_box -instance bbox

check_design_rules

analyze_test_points

report_test_points
set_defaults_value DftSpecification/use_rtl_cells auto
set spec [create_dft_specification -replace]
process_dft_specification

The control point and observe point instruments instantiate the available cells as shown in Example 2.

Test Points as Function Calls

RTL functions represent the combinatorial logic portions of control and observe test points identified at the
boundaries of RTL expressions.

Examples
Example 1
This is an example of a 1-bit control point:

Tessent™ Shell User’s Manual 165

RTL DFT Analysis and Insertion
Test Points as Function Calls

Always
@(posedge clk or negedge rst_n)
begin : TXID_SLOT_CNT_FF
if ((~rst_n))
txid_slot_cnt[7] <= 3'd0;
else if (block_en_n)
txid_slot_cnt[7] <= 3'd0;
else
begin
if ((((conf_ofdma_mode & active_txids[7]) &
o_fifo_wr[txid_active_slot[7]])
& fifo_llr_last[txid_active_slot[7]]))
begin
if (InsertControlPointORTypeV95(
(txid_slot_cnt[7]
==(conf_txid_slots_array[7] - 4'd1)),
control_test_point_en,
ts_0_cp_test_in_360_0)
)
txid_slot_cnt[7] <= 3'd0;
else
txid_slot_cnt[7] <= (txid_slot_cnt[7] + 3'd1);
end
end
end
end

function InsertControlPointORTypeV95;
input sig_in;
input TM;
input test_in;
reg sig_in_tp;
begin
sig_in_tp = (TM & test_in) | sig_in;
InsertControlPointORTypeV95 = sig_in_tp;
end
endfunction

Example 2
This example has two control points on the same expression:

assign length_burst = (((in_length_burst[3:0] >

4'd0)&&(in_length_burst[3:0] <=4'd4))
? 4'hc :
InsertControlPoint4Bits2ORTypeV95_1309(
(((in_length[3:0] > 4'd4)&&(in_length[3:0]
<=4'd8))
? 4'h8 :
(((in_length[3:0] > 4'd8)&&
(in_length[3:0] <=4'd12))

166 Tessent™ Shell User’s Manual

 RTL DFT Analysis and Insertion
Test Points as Function Calls
? 4'h4 :
((in_length[3:0] ==4'd13)
? 4'h3 :
((in_length[3:0] ==4'd14)
? 4'h2 :
((in_length[3:0] ==4'd15)
? 4'h1 :
4'h0))))),
control_test_point_en,
ts_0_cp_test_in_782_0)
);

function [4-1:0] InsertControlPoint4Bits2ORTypeV95_1309;

input [4-1:0] sig_in;
input TM;
input [2-1:0] test_in;
reg [4-1:0] sig_in_tp;
begin
sig_in_tp[0] = (TM & test_in[0]) | sig_in[0];
sig_in_tp[1] = (TM & test_in[1]) | sig_in[1];
sig_in_tp[2] = sig_in[2];
sig_in_tp[3] = sig_in[3];
InsertControlPoint3Bits2ORTypeV95_1309 = sig_in_tp;
end
endfunction

Example 3
This example inserts a control point and connects the associated flip-flop to a negative edge-triggered
clock.
The original RTL specifies a negative edge-triggered clock.

module top(input clk,in1,in2,

output reg out);
sample i1(clk,in1,in2,out);
endmodule
module sample (input clk, in1,in2,
output reg out);
always @(negedge clk) begin
out = in1&in2;
end
endmodule

Assume that the tool inserts a control point on "in1&in2" on "path i1". The following code is the modified
RTL with a negative edge-triggered test point inserted.

module top(input clk,in1,in2, output reg out, input wire cp_en);

sample i1(clk,in1,in2,out, cp_en);
endmodule
module sample (input clk, in1,in2, output reg out, input wire cp_en);
wire [0:0] tessent_persistent_cell_cp_test_in_1_0;
always @(negedge clk) begin
out = InsertControlPointANDTypeSV09((in1 & in2), cp_en,

Tessent™ Shell User’s Manual 167

RTL DFT Analysis and Insertion
Test Points as Function Calls
tessent_persistent_cell_cp_test_in_1_0);
end
top_tessent_dff_cp_neg tessent_persistent_cell_cp_dff_instance_1_0_0(
.clk(clk), .ff_out(tessent_persistent_cell_cp_test_in_1_0)
);
function logic InsertControlPointANDTypeSV09(input logic sig_in,
input logic TM,
input logic test_in);
return (~TM | test_in) & sig_in;
endfunction
endmodule

The following Verilog code defines the negative edge-triggered flip-flop associated with the inserted
control point:

module top_tessent_dff_cp_neg(clk, ff_out);

input clk;
wire clk;
output ff_out;
wire ff_out;
top_tessent_negedge_dff tessent_persistent_cell_cp_dff (
.d ( ff_out ),
.clk ( clk ),
.q ( ff_out )
);
endmodule
module top_tessent_negedge_dff (
input wire d,
input wire clk,
output reg q
);
always @ (negedge clk) begin
q <= d;
end
endmodule

Example 4
This example shows control point insertion on input pins driven by multiple branches of a sub-expression.
In the original RTL, the "in1 & in2" expression has three branches. For the purpose of this example,
control points are inserted on only two of the branches, which are highlighted in red in the following code.
The other branch does not get a control point and is highlighted in green.

module top(input clk, input in1,in2,in3,

output reg out1, out2, out3);
always @(posedge clk) begin
out1 <= (in1 & in2) | in3;
out2 <= (in1 & in2) & in3;
out3 <= (in1 & in2) ^ in3;
end
endmodule

The following figure shows the corresponding gate logic with the two control point locations marked in red.

168 Tessent™ Shell User’s Manual

 RTL DFT Analysis and Insertion
Test Points as Function Calls

Figure 24. Example Gate Logic With Two Control Points

The tool modifies the RTL to insert the two control points as function calls, which are highlighted in red.
The unmodified branch of the original expression is highlighted in green.

module top(
input clk, input in1,in2,in3,
output reg out1, out2, out3, input wire cp_en);
wire [0:0] tessent_persistent_cell_cp_test_in_1_0,
tessent_persistent_cell_cp_test_in_1_00;
always @(posedge clk) begin
out1 <= (InsertControlPointORTypeSV09((in1 & in2), cp_en,
tessent_persistent_cell_cp_test_in_1_0) | in3);
out2 <= ((in1 & in2) & in3);
out3 <= (InsertControlPointORTypeSV09((in1 & in2), cp_en,
tessent_persistent_cell_cp_test_in_1_00) ^ in3);
end
top_tessent_dff_cp tessent_persistent_cell_cp_dff_instance_1_0_0(
.clk(clk), .ff_out(tessent_persistent_cell_cp_test_in_1_0)
);
top_tessent_dff_cp tessent_persistent_cell_cp_dff_instance_1_0_0_1(
.clk(clk), .ff_out(tessent_persistent_cell_cp_test_in_1_00)
);
function logic InsertControlPointORTypeSV09(input logic sig_in,
input logic TM,

Tessent™ Shell User’s Manual 169

RTL DFT Analysis and Insertion
How to Preserve DFT Logic Inserted at RTL
input logic test_in);
return (TM & test_in) | sig_in;
endfunction
endmodule

How to Preserve DFT Logic Inserted at RTL

RTL insertion adds new DFT logic, such as test points, X-bounding logic, and dedicated wrapper cells,
directly into the design. In a gate-level insertion flow, the tool stitches the DFT logic into scan chains in the
same run in which it is inserted. In an RTL insertion flow, the tool inserts the DFT logic before the scan
chains are connected, and you must explicitly direct the synthesis tool to preserve the DFT logic.
For example, control point registers have a holding path from output to input, while observe point registers
are simply connected to, and act as, a sink to signals fanning out from functional logic. Synthesis tools
are likely to view these cells as static and unused (respectively) and optimize them away if they are not
explicitly maintained through the synthesis process.
To avoid this situation, the synthesis script must be modified to preserve all boundaries and content of the
DFT logic inserted at RTL. You can control the naming of the inserted logic to aid in identification.

Prerequisites

• Predefined DFT logic generated into the following sub-directory of <TSDB output directory>/
instruments:

◦ <current_design_name>_<design_id_name>_rtl_scan_dft_logic.instrument

Optional Method to Customize Naming

By default, the tool uses "tessent_persistent_cell_" as a prefix in the names of the logic it inserts. You can
customize this prefix by using the following method:

• Configuration-based specification — Steps:

a. Create an empty DftSpecification configuration wrapper and copy the newly created wrapper
object to the variable “spec” to customize the specification later.

b. Set a new value for DftSpecification/persistent_cell_prefix. For example:

set spec [create_dft_specification]

set_defaults_value DftSpecification/persistent_cell_prefix \
testEx_
process_dft_specification

Methods for Preserving Instances

You must decide whether to manually add commands to the Synopsys Design Compiler® synthesis script
(if you have not run the extract_icl command to generate an SDC file) or to use the Tessent SDC created
as part of the Tessent Shell flow (recommended).

170 Tessent™ Shell User’s Manual

 RTL DFT Analysis and Insertion
How to Report Logic Excluded From Test Point Analysis

• Modify the synthesis script — Steps:

a. Add the following commands to the synthesis script:

set_test_point_insertion_options -persistent_cell_prefix testEx_

set rtl_test_points [get_cells testEx_?p_* -hier]
set_preserve_instances $rtl_test_points
set_boundary_optimization $rtl_test_points false

b. Run Design Compiler.

• Use the Tessent SDC and the tessent_get_preserve_instances proc — Steps:

a. Insert DFT logic into the RTL design using the process_dft_specification command.

b. Re-extract the Tessent SDC using the extract_sdc command.

c. Follow the instructions in the “SDC Design Synthesis With Tessent Shell” section, and refer to
the “Synthesis Helper Procs” topic for more information.
Example
This example adds the following commands to the synthesis script:

source ../tsdb_outdir/dft_inserted_designs \
cb_oc_rtl1.dft_inserted_design/cb_oc.sdc
source <TSDB output directory>/dft_inserted_designs/ \
<current_design_name>_<design_id_name>.dft_inserted_design/ \
<current_design_name>_<design_id_name>.sdc
tessent_set_default_variables
set preserve_instances [tessent_get_preserve_instances scan_insertion]
set_boundary_optimization$preserve_instances true
set_ungroup $preserve_instances false
set_boundary_optimization [tessent_get_optimize_instances] true
set_size_only -all_instances [tessent_get_size_only_instances]
set_app_var compile_enable_constant_propagation_with_no_boundary_opt \
false
set_app_var compile_seqmap_propagate_high_effort false
set_app_var compile_delete_unloaded_sequential_cells false

How to Report Logic Excluded From Test

Point Analysis
Use the "report_notest_points -tool_identified" command to report areas of logic excluded from the test
point analysis.
The report_notest_points command by default reports the circuit points you mark with the
add_notest_points command. However, with the optional -tool_identified switch, it prints the logic areas
that the tool excluded according to your set_rtl_dft_analysis_options command settings.

Tessent™ Shell User’s Manual 171

RTL DFT Analysis and Insertion
How to Report Logic Excluded From Test Point Analysis

The report shows the reason and type for each pin excluded at the gate level after quick synthesis. The
following are the reasons and their meanings:

• constant_cone — logic tied to a constant 0 or 1.

• pins_in_floating_logic — all unused logic that is not observed by any primary output ports.

• design_ware_internal — logic excluded because it is part of a macro that requires synthesis by

Synopsys DesignWare®.

• not_editable_in_rtl — logic excluded because it is not editable RTL. For example, control logic
or logic inside functional blocks.
The tool sets the no_control_reason and no_observe_reason predefined object attributes to the reason
literal when the predefined attributes no_control_point and no_observe_point are set to true.
The list of reasons in this section applies only to the RTL flow. Other no_control_reason and
no_observe_reeason values apply to the gate-level flow. For more information, refer to “Object Attributes”
on page 43.

Examples
Example 1
This example reports the logic excluded from test point analysis:

set_tsdb_output_directory tsdb_outdir
set_context dft -test_points -rtl

read_verilog -f ../data/filelist.f
read_verilog ../prerequisites/insert_test_point_logic.tshell/rtl/tp.v

set_current_design lifo_top

set_design_level physical
add_black_box -auto

add_clocks 1 rbu_reset_n
add_clocks 1 reset_n
add_clocks 0 clk

set_test_point_type {lbist_test_coverage edt_pattern_count}

set_rtl_dft_analysis_options -exclude_floating_logic on \
-exclude_tied_logic on -nodes_available_for_analysis editable

check_design_rules

analyze_test_points
report_notest_points -tool_identified
Pin name Type Reason
--------------------------------------------- ---------------- -----------------------
/i_scan_clk_216_pad control, observe clock_cone
/i _ s c an_c_108_pad control, observe clock_cone
/i_pinmux_clock_108_enable control, observe pins_in_floating_logic

172 Tessent™ Shell User’s Manual

 RTL DFT Analysis and Insertion
How to Report Logic Excluded From Test Point Analysis
/i_mbist_control[14] control, observe pins_in_floating_logic
/i_mbist_control[13] control, observe pins_in_floating_logic
/i_mbist_control[12] control, observe pins_in_floating_logic
/ijtag_ce control, observe tessent_ip_instance
/ijtag_se control, observe tessent_ip_instance
/edt_update control, observe pin_with_constant_value
/mjc_edge/mjc_fcb_inst/REV_MOD_07/CONST/o control, observe constant_cone
/mjc_edge/mjc_fcb_inst/REV_MOD_07/CONST/ob control, observe constant_cone
/mjc_edge/mjc_fcb_inst/REV_MOD_06/CONST/o control, observe constant_cone
/mjc_edge/mjc_fcb_inst/REV_MOD_06/CONST/ob control, observe constant_cone
/mjc_edge/mjc_bic_inst/…/u_tree_chroma/U919/Z control, observe pin_with_constant_value
/mjc_edge/mjc_bic_inst/…/u_tree_chroma/U920/Z control, observe pin_with_constant_value
/mjc_edge/mjc_bic_inst/…/pixel_0_mult/U272/Z control, observe pin_with_constant_value
/mjc_edge/mjc_bic_inst/…/pixel_0_mult/U273/Z control, observe pin_with_constant_value
/mjc_edge/mjc_bic_inst/…/pixel_1_mult/U272/Z control, observe pin_with_constant_value
/mjc_edge/mjc_bic_inst/…/u_tree_chroma/U517/Z control, observe design_ware_internal
/mjc_edge/mjc_bic_inst/…/u_tree_chroma/U980/Z control, observe design_ware_internal
/mjc_edge/mjc_bic_inst/…/u_tree_chroma/U912/Z control, observe design_ware_internal
/mjc_edge/mjc_bic_inst/…/u_tree_chroma/U871/Z control, observe design_ware_internal
/mjc_edge/mjc_bic_inst/…/u_tree_chroma/U625/Z control, observe design_ware_internal

Example 2
The following example uses attribute introspection such as the report_attributes command to show the
value on any gate-pin/port/net/pin objects:
ANALYSIS> report_attributes axi_lfm_awprot[0]

Attribute Definition Report

Attributes defined for object 'axi_lfm_awprot[0]':
Name Value Inheritance
----------------------- ----------------------- -----------
base_class 4_state_unsigned -
base_type wire -
bus_left_index 2 -
bus_name axi_lfm_awprot -
bus_range_direction down -
bus_right_index 0 -
bus_width 3 -
design_hierarchy_level 1 net
direction output -
gate_pin_id 66087.1 -
has_functional_source true -
has_rtl false net
index 0 -
is_bus true -
is_created false -
is_non_editable false -
is_non_editable_reason -
is_valid true -
leaf_name axi_lfm_awprot[0] net
library_name work -
master_module_name lifo_top -
module_name lifo_top -

Tessent™ Shell User’s Manual 173

RTL DFT Analysis and Insertion
X-Bounding Analysis and Insertion at RTL
name axi_lfm_awprot[0] -
no_control_point true -
no_control_reason pin_with_constant_value -
no_observe_point true -
no_observe_reason pin_with_constant_value -
object_id port:6 -
object_type port -
parent_bundle_name axi_lfm_awprot -
parent_instance net
parent_is_hard_module false net
post_synthesis_name axi_lfm_awprot[0] -
pre_synthesis_leaf_name axi_lfm_awprot[0] net
pre_synthesis_name axi_lfm_awprot[0] -
root_bundle_name axi_lfm_awprot -
select_part_value_list {0} -
tie_value -

X-Bounding Analysis and Insertion at RTL

Starting from RTL, the tool performs quick synthesis to generate a flat model for X-bounding analysis. It
stores the results of the analysis in the TSDB. The tool performs the X-bounding insertion in RTL when
you run the process_dft_specification command.
The analyze_xbounding command is enabled in the dft (with no sub-context) context with both
-rtl and -no_rtl options and the analysis system mode. You can control the process with the
set_xbounding_options command and view the results with the report_xbounding command.

Note:
These commands are permitted only if set_dft_specification_requirements -logic_test is set to on.
This ensures definition and controllability requirements are met for clocks, sets, and resets during
pre-DFT DRC.

To insert other instruments but not the X‑bounding logic after the X-bounding analysis is done, you
must clear the analysis results using the analyze_xbounding -reset command before running the
process_dft_specification command.
The tool considers all flip‑flops as scannable, unless they are explicitly declared as non-scan. Flip-flops in
X-bounding analysis have the following capabilities:

• They can be used to drive the inserted multiplexer gates.

• They can observe Xs.

X-Bounding Logic
The tool inserts the following X-bounding logic:

174 Tessent™ Shell User’s Manual

 RTL DFT Analysis and Insertion
X-Bounding Analysis and Insertion at RTL

• A flip-flop with a multiplexer that intercepts an X-source when the corresponding enable signal is
enabled (when you specify the "set_xbounding_options -connect_to new_scan_cell" option).

• A multiplexer that intercepts an X-source when the corresponding enable signal is enabled, with
the other input connected to an existing potential scan cell (when the "set_xbounding_options –
connect_to is set to existing_scan_cell", which is the default).

• An AND/OR gate intercepting the existing connection, with the relevant enable signal
controlling the gate (if the tool finds a flip-flop to drive the multiplexer or when you specify
set_xbounding_options -xbounding_enable –connect_to constant_value).

• A clock gater fix. If an X propagates to a functional enable pin of a clock gater, then the
tool connects the clock gater’s test_enable to the X-bounding enable signal (if you specify
"set_xbounding_options -bound_clock_gater_enables").

• A recirculating feedback path with a multiplexer with an inverter on the D input of the destination
scan cells of false and multicycle paths. The inversion ensures that the destination scan cell
output has a transition during a broadside test to achieve higher coverage. Refer to "False and
Multicycle Paths Handling" in the Hybrid TK/LBIST Flow User’s Manual.

X-Sources
The tool considers the following as potential sources of unknown values:

• Unconstrained primary inputs, except for test-related ports (such as DFT signals, ICL ports, and
so on).

• Bus-related X-sources (based on E9-E11 DRC handling setting).

• Non-scan flops specified with add_nonscan_instances.

• Black boxes.

• False and multicycle paths.

• Memories are considered sources of unknown values. However, the tool forces the
memory_bypass_en DFT signal to "on", which prevents those Xs from propagating to scan cells if
the memory has a bypass.
Instruments with the keep_active_during_scan attribute set to true are not considered X-sources.
If boundary scan is present, you must put it in the shift mode using input constraints to prevent
redundant bounding of the wrapped primary inputs. Alternatively, you can exclude the inputs with the
"set_xbounding_options -exclude" command. The boundary scan cells are not considered X-sources
because all flops are considered scannable (unless defined non-scan).
Ports and pins with DFT control points of async_set_reset type that are added with add_dft_control_point
or by DFT_C9 block the X propagation.
The tool can bound the unknown states introduced by false and multicycle paths when you read an SDC
file before starting the analysis. Refer to “Limitations of RTL DFT Analysis and Insertion” on page 187
for details about SDC file parsing.

Tessent™ Shell User’s Manual 175

RTL DFT Analysis and Insertion
Wrapper Analysis and Dedicated Wrapper Cell Insertion at RTL

Synthesis typically optimizes unused (constrained or floating) logic. Adding X-bounding multiplexers in
such areas can prevent synthesis optimizations and lead to elevated area overhead. Consequently, the
tool tries to mimic synthesis by forcing undriven logic to 0 and excluding these pins from X-bounding.
Such locations have the no_control_reason attribute set and are excluded from DFT analysis. Floating
logic is also analyzed and marked with the no_control_reason attribute. The tool makes sure not to use
the flip-flops that are only driving floating logic, or that are driven by undriven logic, as a source of non-X
input of X-bounding multiplexers.

X-Bounding Enable Signal

The tool selects the first available DFT signal as the enable signal for X‑bounding logic, in the following
order:

1. mcp_bounding_en (only for multicycle path bounding logic)

2. x_bounding_en

3. lbist_en

Non-Editable Nodes
Some regions of the RTL design cannot be modified. The tool marks them with no_control_point/
no_observe_point attributes, and the corresponding no_control_point_reason and
no_observe_point_reason attributes.

Wrapper Analysis and Dedicated Wrapper Cell

Insertion at RTL
When starting from RTL, the tool performs quick synthesis to generate a flat model for wrapper analysis.
The tool performs the dedicated wrapper cell insertion in RTL when you run the process_dft_specification
command.
The analyze_wrapper_cells command runs in analysis mode in the dft (with no sub-context) context for
both -rtl and ‑no_rtl options. You can control the wrapper analysis with the set_wrapper_analysis_options
and set_dedicated_wrapper_cell_options commands.

Note:
These commands are permitted only if set_dft_specification_requirements ‑logic_test is set to on.
This ensures definition and controllability requirements are met for clocks, sets, and resets during
pre-DFT DRC.

You can inspect the analysis results using the report_wrapper_cells command or by introspection. The
tool does not insert dedicated wrapper cells if you run the analyze_wrapper_cells ‑reset command before
the process_dft_specification command.
When you run the process_dft_specification command, the tool writes the locations of the dedicated
wrapper cells to the dft_info_dictionary in the corresponding TSDB directory. If you use a third-party scan
insertion tool, you need to identify dedicated wrapper cells for scan stitching. The following example
shows how to get information for dedicated wrapper cells after the extract_icl command is complete:
format_dictionary [dict get [get_dft_info_dictionary] dedicated_wrapper_cells]

176 Tessent™ Shell User’s Manual

 RTL DFT Analysis and Insertion
Wrapper Analysis and Dedicated Wrapper Cell Insertion at RTL

dft_signals {
async_set_reset_dynamic_disable {
connection_node_name tp_cell_async_set_reset_dynamic_disable/y
connection_node_type pin
}
…
}
dedicated_wrapper_cells {
cpu_en {
ts_0_dihw_2568smodp1_i {
intercept cpu_en
capture_window_behavior invert_hold
}
}
dco_enable {
ts_0_dohw_2350smodp1_i {
intercept dco_enable
capture_window_behavior invert_hold
}
}
…
}

Features and Capabilities of RTL Wrapper Analysis and Insertion

The tool supports the following:

• Most switches of the set_dedicated_wrapper_cell_options and set_wrapper_analysis_options

commands, including those that define thresholds, handle blackboxes, and exclude ports. Setting
the dedicated wrapper cell location with respect to power isolation cells and level shifters does
not apply in RTL. The tool does not support the -input_module_name and -output_module_name
switches of the set_dedicated_wrapper_cell_options command in RTL.

• Insertion of all types of dedicated wrapper cells selected by the "set_wrapper_analysis_options

-capture_window_behavior" command and switch: shifting, holding with inversion, and holding
with programmable inversion.

• Scan segment handling.

• Clock source analysis to determine the clock source for dedicated wrapper cells.

• Tessent wrapper analysis identifies the constant, undriven, and floating logic that synthesis tools
remove from the RTL during optimization. If wrapper analysis determines that a port connects
only to this kind of logic, it ignores the port and reports it as "Optimized post-synthesis". You can
still force a dedicated wrapper cell for the port by using the "set_dedicated_wrapper_cell_options
on -ports" command and switch.

Limitations
The quick synthesis does not use multi-bit cells or flip-flop trays, unlike regular synthesis. For this reason,
wrapper analysis does not account for multi-bit cells the same way it does in the "dft -scan" context. In
the "dft -scan" context, it accounts for their cost towards flip-flop threshold by dividing their size by the

Tessent™ Shell User’s Manual 177

RTL DFT Analysis and Insertion
Smart Uniquification for RTL Pro
number of ports that reach it. In dft (with no sub_context), you can alleviate the impact of this limitation by
reducing input/output fanout/fan-in flip-flop thresholds using the set_wrapper_analysis_options command.

Smart Uniquification for RTL Pro

RTL Pro can perform smart uniquification to help you manage the size and complexity of your design.
The set_insertion_options -auto_uniquify_edited_modules command controls smart uniquification for RTL
DFT insertion.
When the -auto_uniquify_edited_modules switch is set to "on", the tool creates a new unique module for
every instance that has test point, X-bounding, or dedicated wrapper cell DFT logic inserted.
When the -auto_uniquify_edited_modules switch is set to "when_needed" (the default), a smart algorithm
identifies where a new unique view is needed and whether the tool can share the same unique view by
several instances. The tool creates a copy of a module and uniquifies it for each parameterized view
rather than for each instance. For example, if all instances have DFT logic insertion locations and they are
instantiated over two parameterized views, the number of unique copies created equals two, in addition to
the original.
The tool distributes all DFT locations (such as test points, X-bounding logic, and dedicated wrapper cells)
per elaborated views. Elaborated views are new modules created by design elaboration to represent the
hierarchy of logic instances after propagating parameters and the System Verilog interface from the top
module down.
Before starting insertion of the test logic into the RTL design, RTL Pro identifies all sets of instances of
the same elaborated view that require the same test logic. If a set of instances has the same required test
logic but some descendants do not, the tool creates different unique views.

Example 1
This example shows the behavior of the "set_insertion_options ‑auto_uniquify_edited_modules"
command. The example design has 10 instances of the same module "DECODE" under the top module
"TOP" as follows:

module TOP (…….);

DECODE #(.WITDH(8)) u1(……);
DECODE #(.WITDH(16)) u2(……);
DECODE #(.WITDH(8)) u3(……);
DECODE #(.WITDH(8)) u4(……);
DECODE #(.WITDH(8)) u5(……);
DECODE #(.WITDH(16)) u6(……);
DECODE #(.WITDH(8)) u7(……);
DECODE #(.WITDH(8)) u8(……);
DECODE #(.WITDH(8)) u9(……);
DECODE #(.WITDH(16)) u10(……);
endmodule

After design elaboration, the tool creates two elaborated views for the "DECODE" module according to
the WIDTH parameter.

• DECODE@PV1 for instances: u1, u3, u4, u5, u7, u8, u9

• DECODE@PV2 for instances: u2, u6, u10

178 Tessent™ Shell User’s Manual

 RTL DFT Analysis and Insertion
Smart Uniquification for RTL Pro

The following scenarios show how the tool uniquifies the design depending on the test logic inserted and
the setting you specified for the -auto_uniquify_edited_modules switch:
Scenario 1
The tool inserts ten control points implemented with OR gates. All control points are on the same output
of the same expression (same logic).
In this case, the tool performs the following uniquification:

• -auto_uniquify_edited_modules on —

◦ 10 new unique views (DECODE_1, DECODE_2, …, DECODE_10)

• -auto_uniquify_edited_modules when_needed —

◦ DECODE_1 for instances {u1, u3, u4, u5, u7, u8, u9}

◦ DECODE_2 for instances {u2, u6, u10}

Scenario 2
The tool inserts ten control points implemented with OR gates. All control points are on the same output
of the same expression (same logic). The tool also inserts six observe points, with three observe points
on the same location for u1, u2, and u3, and three other observe points on the same location for u4, u5,
and u6.
In this case, the tool performs the following uniquification:

• -auto_uniquify_edited_modules on —

◦ 10 new unique views (DECODE_1, DECODE_2, …, DECODE_10)

• -auto_uniquify_edited_modules when_needed —

◦ DECODE_1 for instances {u1, u3}

◦ DECODE_2 for instances {u2, u6, u10}

◦ DECODE_3 for instances {u4, u5, u7, u8, u9}

If you enable test point sharing, the uniquification changes because the tool always inserts the common
flip-flop at the common ancestor instance, as shown in Scenario 3.
Scenario 3
As in Scenario 2, the tool inserts ten control points implemented with OR gates. All control points are
on the same output of the same expression (same logic). The tool also inserts six observe points, with
three observe points on the same location for u1, u2, and u3, and three other observe points on the same
location for u4, u5, and u6.
This scenario enables test point sharing with the following command:
set_test_point_analysis_options -shared_control_points_per_flop 5

Tessent™ Shell User’s Manual 179

RTL DFT Analysis and Insertion
Smart Uniquification for RTL Pro

In this case, the tool creates two clusters of control points (CP) that share a single flip-flop for each
cluster.

• Cluster 1 = {CP of u1, u2, u3, u4, u5}

• Cluster 2 = {CP of u6, u7, u8, u9, u10}

The tool performs the following uniquification:

• -auto_uniquify_edited_modules on —

◦ 10 new unique views (DECODE_1, DECODE_2, …, DECODE_10)

• -auto_uniquify_edited_modules when_needed —

◦ DECODE_1 for instances {u1, u3}

◦ DECODE_2 for instances {u2}

◦ DECODE_3 for instances {u6, u10}

◦ DECODE_4 for instances {u4}

◦ DECODE_5 for instances {u5, u7, u8, u9}

The tool identified the same test points for Scenario 2 and 3 but a different number of unique views
because of test point sharing.
To have better control on uniquification when the test point sharing is enabled, use the
set_test_point_sharing_restrictions command. For example, use the -module switch to restrict sharing to
specific elaborated views only:
set_test_point_sharing_restrictions on -modules {DECODE@PV1 DECODE@PV2}

Example 2
This example shows the behavior of the "set_insertion_options ‑auto_uniquify_edited_modules"
command on the following design, top.sv:

module M1 (input clk, input [3:0] in, output reg

out1,out2,out3,out4);
always @(posedge clk) begin
out1 <= in[0] & in[2];
end
M2 U3(clk, in, out2);
M2 U4(clk, in, out3);
M2 U5(clk, in, out4);
endmodule
module M2 (input clk, input [3:0] in, output reg out1);
always @(posedge clk) begin
out1 <= in[1] & in[3];
end

180 Tessent™ Shell User’s Manual

 RTL DFT Analysis and Insertion
Smart Uniquification for RTL Pro
endmodule
module top(input clk,input [3:0]in,output out1,
out2,out3,out4,out5,out6,out7,out8);
M1 U1(clk, in, out1, out2,out3,out4);
M1 U2(clk, in, out5, out6,out7,out8);
endmodule

The dofile for this example includes the following commands, where the gate pin "rtlc0_0/Z" represents
the output pin of expression "in[1] & in[3]":

add_control_points -clock U1/U3/clk -location U1/U3/rtlc0_0/Z \

-enable cp_en -type and
add_control_points -clock U1/U4/clk -location U1/U4/rtlc0_0/Z \
-enable cp_en -type and
add_control_points -clock U2/U3/clk -location U2/U3/rtlc0_0/Z \
-enable cp_en -type and
add_control_points -clock U2/U4/clk -location U2/U4/rtlc0_0/Z \
-enable cp_en -type and

The tool inserts four control points on the same RTL location. With "‑auto_uniquify_edited_modules
when_needed", the tool creates two new unique views, M1_1 and M2_1. The following shows the RTL for
top.sv after test point insertion:

module M1 (input clk, input [3:0] in,

output reg out1,out2,out3,out4,
input wire cp_en);
always @(posedge clk) begin
out1 <= in[0] & in[2];
end
M2_1 U3(clk, in, out2, cp_en);
M2_1 U4(clk, in, out3, cp_en);
M2 U5(clk, in, out4);
endmodule

module M1_1 (input clk, input [3:0] in,

output reg out1,out2,out3,out4,
input wire cp_en);
always @(posedge clk) begin
out1<= in[0] & in[2];
end
M2_1 U3(clk, in, out2, cp_en);
M2_1 U4(clk, in, out3, cp_en);
M2 U5(clk, in, out4);
endmodule

module M2 (input clk, input [3:0] in, output reg out1);

always @(posedge clk) begin
out1<= in[1] & in[3];
end
endmodule

module M2_1 (input clk, input [3:0] in,

output reg out1, input wire cp_en);

Tessent™ Shell User’s Manual 181

RTL DFT Analysis and Insertion
Incremental Insertion
wire [0:0] tessent_persistent_cell_cp_test_in_1_0;
always @(posedge clk) begin
out1<= InsertControlPointANDTypeV95((in[1] & in[3]), cp_en,
tessent_persistent_cell_cp_test_in_1_0);
end
top1_rtl_tessent_dff_cp
tessent_persistent_cell_cp_dff_instance_1_0_0(.clk(clk),
.ff_out(tessent_persistent_cell_cp_test_in_1_0));
function InsertControlPointANDTypeV95;
input sig_in;
input TM;
input test_in;
begin
InsertControlPointANDTypeV95 = (~TM | test_in) & sig_in;
end
endfunction
endmodule

module top(input clk,input [3:0]in,

output out1,out2,out3,out4,out5,out6,out7,out8,
input wire cp_en);
M1_1 U1(clk, in, out1, out2,out3,out4, cp_en);
M1 U2(clk, in, out5, out6,out7,out8, cp_en);
endmodule

Incremental Insertion
After synthesizing the DFT logic inserted at RTL, you can perform incremental insertion at the gate level
for fine-tuning before test pattern generation.
You can perform incremental test point analysis at the gate level. The Example in this section shows how
to use it to increase LBIST test coverage.
You can perform incremental X-bounding at the gate level for these reasons:

• Bound any Xs introduced by synthesis.

• Bound false and multicycle paths after reading in a gate-level SDC file. For more information,
refer to "False and Multicycle Paths Handling" in the Tessent Hybrid TK/LBIST Flow User’s
Manual.
You can perform incremental wrapper cell analysis at the gate level. Refer to "Automatic Identification
of Pre-Existing Dedicated Wrapper Cells" in the Tessent Scan and ATPG User’s Manual for detailed
information about the following topics:

• How the tool handles dedicated wrapper cells inserted at RTL.

• The behavior of the analyze_wrapper_cells command if you run it again in the dft ‑scan context
on a gate-level design.

182 Tessent™ Shell User’s Manual

 RTL DFT Analysis and Insertion
Incremental Insertion

Example
This example first inserts test points in an RTL design and then incrementally inserts test points at the
gate level. It focuses on the commands related to test points only. For more information on the overall
flow, refer to “Tessent Shell Workflows” on page 189.
Define DFT-specific signals in the first insertion pass, including the following signals for test points:

add_dft_signals observe_test_point_en -create_with_tdr

add_dft_signals control_test_point_en -create_with_tdr

The following code shows the test point insertion at RTL with the goal of increasing LBIST test coverage:

set_context dft -test_points -rtl -design_id rtl1_tp

read_design lifo_top -design_id rtl1 -verbose
set_current_design lifo_top
add_black_boxes -auto
set_test_point_types lbist_test_coverage
set_test_point_analysis_options -test_coverage_target 90
set_test_point_insertion_options -control_point_enable
lifo_top_rtl1_tessent_tdr_sri_ctrl_inst/control_test_point_en \
-observe_point_enable \
lifo_top_rtl1_tessent_tdr_sri_ctrl_inst/observe_test_point_en
check_design_rules
set_test_point_analysis_options -capture_per_cycle_observe_points on
set_test_point_analysis_options -minimum_shift_length 4
analyze_test_points
create_dft_specification
process_dft_specification

The following tool transcript shows the results of the analyze_test_points command for RTL insertion:

// command: analyze_test_points
// Identifying locations of x-bounding muxes prior to test point
// analysis.
// Note: Test points cannot be inserted at 72057 (63.0%) gate-pins.
// 10978 ( 9.6%) gate-pins are located on clock lines or on the
// scan path.
// 23033 (20.1%) gate-pins are constant due to inputs that are
// constrained to 0 or 1 or as a result of the test setup procedure.
// 32061 (28.0%) gate-pins are in excluded uneditable regions.
// Warning: This design may not be suitable for test point analysis
// unless you can take the following action(s) -
// a) Reduce the number of uneditable regions by improving the RTL.
// For guidance, users can analyze the RTL complexity of the whole
// design using the command "report_rtl_complexity".
//
// Test Coverage Report before Test Point Analysis
// -----------------------------------------------
// Target number of random patterns 10000
//
// Total Number of Faults 225688

Tessent™ Shell User’s Manual 183

RTL DFT Analysis and Insertion
Incremental Insertion
// Testable Faults 195086 ( 86.44%)
// Logic Bist Testable 169632 ( 75.16%)
// Blocked by xbounding 9200 ( 4.08%)
// Uncontrollable/Unobservable 5586 ( 2.48%)
//
// Estimated Maximum Test Coverage 86.95%
// Estimated Test Coverage (pre test points) 54.86%
// Estimated Relevant Test Coverage (pre test points) 58.04%
//

//
// Incremental Test Point Analysis
// -----------------------------------------
// TPs 100 = 61 (CP) + 39 (OP), Est_RTC 68.68
// TPs 200 = 112 (CP) + 88 (OP), Est_RTC 70.13
…
// TPs 1700 = 178 (CP) + 1522 (OP), Est_RTC 81.37
// TPs 1800 = 178 (CP) + 1622 (OP), Est_RTC 81.44
//
// Incremental optimization to find more effective test points is in
// progress. The final distribution of control and observe points may
change.
//
// Test Coverage Report after Test Point Analysis
// ----------------------------------------------
// Target number of random patterns 10000
//
// Total Number of Faults 225688
// Testable Faults 195086 ( 86.44%)
// Logic Bist Testable 169632 ( 75.16%)
// Blocked by xbounding 9200 ( 4.08%)
// Uncontrollable/Unobservable 5586 ( 2.48%)
//
// Estimated Test Coverage (post test points) 79.51%
// Estimated Relevant Test Coverage (post test points) 84.11%
//
//
// Test point analysis completed: no more useful test points could be
// identified.
// Total inserted test points 1473
// Control Points 274
// Observation scan Test Points 1199
// Maximum control point per path 4
// CPU_time (secs) 15.7

After insertion, the RTL design is ready for synthesis. At the gate level, perform fault simulation of the
LBIST patterns to evaluate the test coverage. The following tool transcript shows the results of fault
simulation:

// command: simulate_patterns -source bist -store_patterns all

// Warning: Current sequential depth is not large enough to apply named
// capture procedures.
// Automatically increase the sequential depth to be 2.

184 Tessent™ Shell User’s Manual

 RTL DFT Analysis and Insertion
Incremental Insertion
// ---------------------------------------------------------------------
// Simulation performed for #gates = 93375 #faults = 234443
// Run fault simulation and store all patterns.
// pattern source = 1000 LBIST-OST patterns
// ---------------------------------------------------------------------
// #patterns test #faults #faults # eff. # test process
// simulated coverage in list detected patterns patterns CPU time
// Note: Pattern classification is automatically turned off.
// 64 73.28% 54435 180008 64 64 5.19
sec
// 128 74.66% 49786 4649 64 128 8.28
sec
…
// 960 79.07% 34718 1791 29 960 47.49
sec
// 1000 79.13% 34508 210 15 1000 50.09 sec
// 21 faults were identified as detected by implication.

The result is that test point insertion at RTL added 1473 test points, which increased the estimated test
coverage from 54.86% to 79.51%. The fault simulation confirmed the LBIST test coverage at 79.13% for
1000 patterns simulated.
To further increase LBIST test coverage, this example script performs incremental test point insertion in
the design at the gate level:

set_context dft -scan -test_points -no_rtl -design_id gate_tpi_1

read_cell_library adk.tcelllib
read_verilog lifo_top.vg
read_design lifo_top -design_id rtl1_tp -no_hdl -verbose
set_current_design lifo_top
add_black_boxes -auto
set_test_point_types lbist_test_coverage
set_test_point_analysis_options -test_coverage_target 90
set_test_point_insertion_options -control_point_enable \
lifo_top_rtl1_tessent_tdr_sri_ctrl_inst/control_test_point_en \
-observe_point_enable \
lifo_top_rtl1_tessent_tdr_sri_ctrl_inst/observe_test_point_en
set_test_point_analysis_options -capture_per_cycle_observe_points on
set_test_point_analysis_options -minimum_shift_length 4
check_design_rules
analyze_test_points
insert_test_logic

The following tool transcript shows the test points added during gate-level incremental insertion:

// command: analyze_test_points
// Identifying locations of x-bounding muxes prior to test point
// analysis.
// Note: Test points cannot be inserted at 37804 (29.4%) gate-pins.
// 12855 (10.0%) gate-pins are located on clock lines or on the
// scan path.
// 17191 (13.4%) gate-pins are constant due to inputs that are
// constrained to 0 or 1 or as a result of the test setup procedure.
// 5746 ( 4.5%) gate-pins are restricted by add_notest_points

Tessent™ Shell User’s Manual 185

RTL DFT Analysis and Insertion
Incremental Insertion
// command(s) and/or no_control_point/no_observe_point attribute
// settings.
// Warning: Consider taking the following action(s) -
// a) Reduce the number of user-specified no_control_point
// and no_observe_point locations.
//

// Test Coverage Report before Test Point Analysis

// -----------------------------------------------
// Target number of random patterns 10000
//
// Total Number of Faults 310642
// Testable Faults 232586 ( 74.87%)
// Logic Bist Testable 204504 ( 65.83%)
// Blocked by xbounding 9691 ( 3.12%)
// Uncontrollable/Unobservable 6788 ( 2.19%)
//
// Estimated Maximum Test Coverage 87.93%
// Estimated Test Coverage (pre test points) 70.00%
// Estimated Relevant Test Coverage (pre test points) 73.68%
//
//
// Incremental Test Point Analysis
// -----------------------------------------
// TPs 100 = 33 (CP) + 67 (OP), Est_RTC 87.50
//
// Incremental optimization to find more effective test points is in
// progress. The final distribution of control and observe points
may // change.
//
// Test Coverage Report after Test Point Analysis
// ----------------------------------------------
// Target number of random patterns 10000
//
// Total Number of Faults 311012
// Testable Faults 232103 ( 74.63%)
// Logic Bist Testable 204243 ( 65.67%)
// Blocked by xbounding 9691 ( 3.12%)
// Uncontrollable/Unobservable 6574 ( 2.11%)
//
// Estimated Test Coverage (post test points) 86.07%
// Estimated Relevant Test Coverage (post test points) 90.60%
//
//
// Test point analysis completed: target estimated test coverage has been
// achieved.
// Total inserted test points 191
// Control Points 78
// Observation scan Test Points 113
// Maximum control point per path 3
// CPU_time (secs) 5.6
//
// command: insert_test_logic

186 Tessent™ Shell User’s Manual

 RTL DFT Analysis and Insertion
Limitations of RTL DFT Analysis and Insertion
=============================
Test Logic Insertion Summary:
=============================
Structural Data:
----------------
Added top-level port count: 0
Added instance count: 950
Logical Data:
-------------
Added control testpoint logic count: 272
Added observation scan testpoint logic count: 113

After incrementally inserting test points, you can fault simulate the LBIST patterns. Here is an excerpt
from the fault simulation tool transcript:

// command: simulate_patterns -source bist -store_patterns all

// Warning: Current sequential depth is not large enough to apply named
// capture procedures.
// Automatically increase the sequential depth to be 2.
// ---------------------------------------------------------------------
// Simulation performed for #gates = 94868 #faults = 237762
// Run fault simulation and store all patterns.
// pattern source = 1000 LBIST-OST patterns
// ---------------------------------------------------------------------
// #patterns test #faults #faults # eff. # test process
// simulated coverage in list detected patterns patterns CPU time
// Note: Pattern classification is automatically turned off.
// 64 80.63% 30232 206893 64 64 5.25
sec
// 128 82.34% 24377 5855 64 128 7.50
sec
…
// 960 86.32% 10742 318 36 960 32.62
sec
// 1000 86.35% 10643 99 18 1000 34.29
sec
// 35 faults were identified as detected by implication.

The result is that incremental insertion at the gate level put in an additional 191 test points, further
increasing the estimated test coverage from 79.51% to 86.07%. The fault simulation confirmed the LBIST
test coverage as 86.35% for 1000 patterns simulated.

Limitations of RTL DFT Analysis and Insertion

Tessent Shell RTL DFT analysis and insertion capabilities have the following limitations:

• At RTL, you can perform test point insertion in incremental mode, but we recommend
that you insert dedicated wrapper cells and X‑bounding logic with a single call to the
process_dft_specification command. At the gate-level, you can incrementally insert dedicated
wrapper cells, X‑bounding logic, and test points after RTL insertion.

Tessent™ Shell User’s Manual 187

RTL DFT Analysis and Insertion
Limitations of RTL DFT Analysis and Insertion

• The tool identifies dedicated wrapper cell structures that are inserted by Tessent in RTL designs.
These are only a subset of dedicated wrapper cells that are part of IEEE Std 1500.

• The tool does not support insertion of dedicated wrapper cells, test points, and X-bounding logic
in VHDL.

• Parts of the design marked as non-editable RTL for test points are treated as non-editable for
dedicated wrapper cells and X-bounding logic, too.

• You must use the no_control_point attribute to mark the parts of the design where you do
not want the tool to insert X-bounding logic because the add_notest_points command is not
available.

• If X-bounding is necessary in the logic analyzed but not marked with the no_control_point
attribute, and the logic is in non-editable RTL, the tool reports a violation of the XB3 DRC rule.
You can remedy this by marking the logic with the no_control_point attribute.

• The -use_scan_cells {off | on} option to the set_test_point_insertion_options and

set_xbounding_options commands is not supported in the dft (with no sub‑context) context.

• The -input_module_name and -output_module_name switches of the

set_dedicated_wrapper_cell_options command are not supported in RTL.

• The -dedicated_wrapper_cells_location and -identify_existing_dedicated_wrappers switches of

the set_wrapper_analysis_options command are not supported in RTL.

• The -prefer_scan_cells switch of the set_test_point_insertion_options command is not supported

in RTL.

• The tool only supports a subset of the SDC file syntax. Refer to the read_sdc command in the
Tessent Shell Reference Manual for more information. The tool may not support the attributes
and commands specific to third-party tools. A possible workaround is to read the SDC file in
the synthesis tool and write out a preprocessed version after elaboration and before synthesis.
However, this can result in tool-specific, post-synthesis design object names that may not match
the design objects in Tessent, requiring some additional manual post-processing. Another
alternative is to prepare a tool-independent SDC file by extracting the tool-specific queries and
implementing them separately for Tessent and third-party tools.

• You must first create an ICL representation of your RTL design in the TSDB by running
the extract_icl command before running the extract_sdc command to generate the
tessent_get_preserve_instances procs in the SDC file. These procs can be used to preserve the
inserted DFT logic during synthesis.

188 Tessent™ Shell User’s Manual

 Chapter 6
Tessent Shell Workflows
Tessent Shell workflows are grouped into two main subflows: prelayout and postlayout. The prelayout
DFT insertion workflow describes the process for using Tessent Shell for flat and hierarchical designs.
The post-insertion validation workflow describes the flow for netlists that have completed placement and
routing.

Tessent Shell Flow for Flat Designs

Tessent Shell Flow for Hierarchical Designs
Tessent Shell Flow for RTL Test Point and Wrapper Insertion
Tessent Shell Flow for Tiled Designs
Tessent Shell Post-Layout Validation Flow
Testbench Generation and Simulation in RTL Mode
Hybrid TK/LBIST Flow for Flat Designs
Running Multiple Load ATPG on Wrapped Core Memories With Built-In Self Repair
Built-In Self Repair in Hierarchical Tessent MemoryBIST Flow

Tessent™ Shell User’s Manual 189

Tessent Shell Workflows
Tessent Shell Flow for Flat Designs

Tessent Shell Flow for Flat Designs

In the RTL and scan DFT insertion flow for flat designs, you perform DFT insertion for the entire chip-level
design.
The flat DFT implementation aligns with the physical implementation of the design. The flow consists of
the following steps:

1. Performing DFT hardware insertion

2. Synthesis

3. Scan insertion (optional)

4. Gate-level ATPG
Understanding the RTL and scan DFT prelayout insertion flow for flat designs helps you manipulate
hierarchical designs or implement a variation of the basic flow.
Refer to the following test case for a detailed usage example of the flow described in this section:

tessent_example_flat_flow_<software_version>.tgz

Access this test case from the following directory:

<software_release_tree>/share/UsageExamples/

Overview of the RTL and Scan DFT Insertion Flow

First DFT Insertion Pass: Performing MemoryBIST and Boundary Scan
Second DFT Insertion Pass: EDT, Hybrid TK/LBIST, and OCC
Performing Synthesis
Performing Scan Chain Insertion (Flat Design)
Performing ATPG Pattern Generation
Simulating LBIST Faults
Considerations for Using Gate-Level Verilog Netlists

Overview of the RTL and Scan DFT Insertion Flow

Whether you are using a flat design or a hierarchical design, the RTL and scan DFT insertion flow
requires you to use a two-pass insertion process to insert the DFT hardware.
As shown in the following figure, insert MemoryBIST and boundary scan prior to embedded deterministic
test (EDT) or hybrid TK/LBIST (LBIST), and the on-chip clock controller (OCC). In this section, EDT refers
to embedded deterministic test IP only; and LBIST refers to hybrid TK/LBIST IP, which also includes EDT.

190 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Overview of the RTL and Scan DFT Insertion Flow

Note:
EDT is a subset of LBIST. You can choose EDT and no LBIST, but you cannot choose LBIST
without it also including EDT.

The DFT logic you insert during the first DFT insertion pass gets tested by EDT or LBIST. When inserting
DFT into an RTL design, you only need to run synthesis once after you have performed the two DFT
insertion passes.

Figure 25. Two-Pass Insertion Flow for RTL, Flat Designs

During the first pass, Tessent inserts the IJTAG network and any IJTAG instruments that have ICL
descriptions. Refer to the command for details about this process.
During the second pass, the tool checks MemoryBIST’s logic for rule compliance with the rest of the
functional logic to prevent implications for the DFT signals and IJTAG network connections that could
result in coverage loss and pattern count increase.

Tessent™ Shell User’s Manual 191

Tessent Shell Workflows
Overview of the RTL and Scan DFT Insertion Flow

Optionally, you can perform scan insertion at the same time as synthesis. This does not affect how you
perform DFT insertion, but you do lose some of the automation that Tessent Shell provides during ATPG
pattern generation.
The following figures show an example of the progression of DFT hardware inserted into a DFT-ready
design.

Figure 26. DFT-Ready Design

In the first DFT insertion pass, Tessent inserts the MemoryBIST and boundary scan hardware.

Figure 27. After the First DFT Insertion Pass

192 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
First DFT Insertion Pass: Performing MemoryBIST and Boundary Scan

In the second DFT insertion pass, Tessent inserts the EDT or LBIST, and OCC hardware. You clock
the MemoryBIST logic (shown in yellow in Figure 28) using the same functional clock that feeds the
memories. The IJTAG network (blue) is scan tested using the IJTAG clock, which is the TCK clock. The
TAP network (red) is not scan tested or is made non-scan during ATPG.

Figure 28. After the Second DFT Insertion Pass

First DFT Insertion Pass: Performing MemoryBIST

and Boundary Scan
Insert MemoryBIST and boundary scan prior to EDT and OCC so that you can accurately estimate the
number of scannable sequential elements (often referred to as "flops") to be tested. The number of flops
determines the size of the EDT controller that Tessent generates in the second DFT insertion pass.
The flow for inserting MemoryBIST and boundary scan together is the same as inserting them separately.
For details about this insertion pass flow, refer to:

• "Getting Started" in the Tessent MemoryBIST User’s Manual

• "Getting Started With Tessent BoundaryScan" in the Tessent BoundaryScan User’s Manual
Notes About This Procedure

• The "set_dft_specification_requirements -memory_test" switch in the reference testcase is set to

On even though this testcase has no memories in the top level. This requests that the memory
clocks at the boundary of the child blocks receive design rule checks (DRCs) up through the top
level. Although the extract_icl process would detect any issues, you would need to redo the DFT
insertion to fix them. By performing the DRC before DFT, you can detect and correct those issues
sooner.

• The line numbers used in this procedure refer to the command flow dofile in Example 1 on
page 195.

Tessent™ Shell User’s Manual 193

Tessent Shell Workflows
First DFT Insertion Pass: Performing MemoryBIST and Boundary Scan

Prerequisites
• To insert boundary scan, you must have an RTL design with instantiated I/O pads if you are using
a chip-level design.

• For RTL netlists, you must have a Tessent cell library or the pad library for the I/O pads. For more
information, refer to the Tessent Cell Library Manual.

Procedure
1. Load the RTL design data (refer to lines 1-7).

2. For the first insertion pass, set the set_context -design_id switch. By convention, the identifier used
for this is typically rtl1.
The ‑design_id switch stores all the data associated with a particular DFT insertion pass in the
TSDB. For the first pass, rtl1 contains the data for the MemoryBIST and boundary scan hardware,
and for the IJTAG network.

Note:
rtl1 is the recommended naming convention for the design ID for the first insertion pass,
but you can specify any name. Refer to Loading the Design for more information about
setting the design ID.

3. Set the set_dft_specification_requirements command to auto for ‑memory_test and on for

‑boundary_scan. (Refer to line 11.)
This tells Tessent Shell that you are generating the MemoryBIST and boundary scan hardware at
the same time.

4. Set the design level (set_design_level chip, refer to line 12).

Refer to Design Levels for more information.

5. Identify test pins and apply options to special pins. (Refer to lines 14-26.)

6. Apply the check_design_rules command to instruct the tool to leave setup mode and enter analysis
mode.
If there are issues with the design, the tool remains in setup mode. (Refer to line 31.)

7. Create the DFT specification. (Refer to lines 33-43.)

a. To configure the functional pins so that they are shared as EDT channel input and output
pins, add the required logic using the AuxiliaryInput ports and AuxiliaryOutput ports wrappers,
respectively.
Functional pins can be shared as EDT channel pins. You must insert auxiliary input and output
logic at the same time as you insert boundary scan to avoid cascading two multiplexers along

194 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
First DFT Insertion Pass: Performing MemoryBIST and Boundary Scan
the functional output paths. For additional information, refer to the AuxiliaryInputOutputPorts
wrapper in the Tessent Shell Reference Manual.

Note:
You can also share test_clock, scan_en, and edt_update pins with functional pins. The
functional coverage is maintained when you use boundary scan during scan test.

8. Create the DFT hardware, IJTAG network connectivity, and input test patterns. (Refer to lines
46-53.)

9. Run simulations to verify the design. (Refer to lines 55-62.)

Results
For MemoryBIST, Tessent inserts the MemoryBIST controllers, interfaces, BIST Access Port (BAP), and
segment insertion bits (SIBs). This hardware is later scan-tested using EDT, which you insert during the
second insertion pass. In addition, Tessent automatically connects pre-existing scan testable instruments
and scan resource instruments to the Scan Tested Instrument (STI) and Scan Resource Instrument (SRI)
sides of the IJTAG network, respectively.
For boundary scan, you can segment the boundary scan chain into smaller chains that are used during
logic testing with Tessent TestKompress. To segment the boundary scan chain into smaller chains to be
connected to the EDT, specify max_segment_length_for_logictest within the BoundaryScan wrapper or
alternatively specify the following command prior to running create_dft_specification:
set_defaults_value DftSpecification/BoundaryScan/max_segment_length_for_logictest

Examples
The following dofile example shows a typical command flow.
The highlighted command lines illustrate additional considerations for inserting the Tessent Shell
MemoryBIST and Tessent Shell Boundary Scan instruments in the first insertion pass of a two-pass DFT
insertion process. The functional pins are equipped with logic so that they can be shared as EDT channel
input and output pins.

Example 1. Dofile Example for MemoryBIST and BoundaryScan

1 # Load the design

2 set_context dft –rtl –design_id rtl1
3 set_tsdb_output_directory ../tsdb_rtl
4 read_verilog ../RTL/cpu_top.v
5 read_cell_library ../library/tessent/adk.tcelllib
6 set_design_sources -format tcd_memory -Y ../library/memory \
7 -extension memlib
8 set_current_design cpu_top
9
10 # Specify and verify the DFT requirements
11 set_dft_specification_requirements –memory_test auto \
-boundary_scan on
12 set_design_level chip
13
14 # Identify TAP pins
15 set_attribute_value tck_p -name function -value tck
16 set_attribute_value tdi_p -name function -value tdi

Tessent™ Shell User’s Manual 195

Tessent Shell Workflows
First DFT Insertion Pass: Performing MemoryBIST and Boundary Scan
17 set_attribute_value tms_p -name function -value tms
18 set_attribute_value trst_p -name function -value trst
19 set_attribute_value tdo_p -name function -value tdo
20 set_boundary_scan_port_options ramclk_p -cell_options clock
21 set_boundary_scan_port_options reset_p -cell_options sample
22
23 # Some pins cannot add any boundary scan cells
24 set_boundary_scan_port_options test_clock_p \
-cell_options dont_touch
25 set_boundary_scan_port_options edt_update \
-cell_options dont_touch
26 set_boundary_scan_port_options scan_en_p -cell_options dont_touch
27
28 # Specify the clocks feeding the memories
29 add_clocks 0 ramclk_p -Period 5ns
30
31 check_design_rules
32
33 # Create DFT specification
34 set spec [create_dft_specification]
35 report_config_data $spec
36 set_config_value \
$spec/BoundaryScan/max_segment_length_for_logictest 150
37 read_config_data -in ${spec}/BoundaryScan -from_string {
38 AuxiliaryInputOutputPorts {
39 auxiliary_input_ports : portain_p[0], portain_p[1], \
portain_p[2] ;
40 auxiliary_output_ports : portbout_p[0], portbout_p[1],
41 portbout_p[2];
42 }
43 }
44 report_config_data $spec
45
46 # Create the hardware for the DFT inserted with the DFT
specification
47 process_dft_specification
48
49 # Extract the IJTAG network connectivity and create ICL for the
design
50 extract_icl
51
52 # Create patterns specification for validating the inserted
hardware
53 create_patterns_specification
54
55 # Process the patterns specification and create simulation
testbenches
56 process_patterns_specification
57
58 # Run and check testbench simulations
59 set_simulation_library_sources -v ../library/verilog/adk.v \

196 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
First DFT Insertion Pass: Performing MemoryBIST and Boundary Scan
60 -v ../library/pad_cells.v -v ../library/memory/ram.v
61 run_testbench_simulations
62 check_testbench_simulations -report_status

Tessent™ Shell User’s Manual 197

Tessent Shell Workflows
Second DFT Insertion Pass: EDT, Hybrid TK/LBIST, and OCC

Second DFT Insertion Pass: EDT, Hybrid TK/LBIST,

and OCC
In the second DFT insertion pass, insert either the EDT or hybrid TK/LBIST logic test hardware, and
OCC. This insertion pass includes requirements and considerations that differ from the first DFT insertion
pass, including inserting the DFT signals.
For information about OCC, refer to "Tessent On-Chip Clock Controller" in the Tessent Scan and ATPG
User’s Manual.
Before running this flow for chip-level designs, source nodes must be present in the RTL design so that
you can define dynamic DFT signals, as described in "Specifying and Verifying the DFT Requirements".
Dynamic DFT signals (for example, scan enable, edt_clock, and edt_update) need to change during
specific tests.

Figure 29. Flow for the Second DFT Insertion Pass

198 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Loading the Design

Note:
For the second DFT insertion pass, use the process described in “First DFT Insertion Pass:
Performing MemoryBIST and Boundary Scan” on page 193 to generate ATPG patterns and
perform simulation.

Loading the Design

Specifying and Verifying the DFT Requirements
Creating the DFT Specification
Generating the EDT, Hybrid TK/LBIST, and OCC Hardware
Extracting the ICL Module Description
Generating ICL Patterns and Running Simulation

Loading the Design

When loading the design for the second DFT insertion pass, you must ensure that you specify a new
design ID name and, optimally, use the same TSDB directory that you used in the first insertion pass. In
addition, you must read in the design from the first insertion pass and elaborate the design.
The design loading process for the second pass is similar to the process you used in the first insertion
pass, with a few exceptions.

Figure 30. Flow for Loading the Design

Prerequisites
• For chip-level designs, source nodes must be present in the RTL design so that you can define
dynamic DFT signals as described in Specifying and Verifying the DFT Requirements. Dynamic
DFT signals are signals such as scan enable, edt_clock, edt_update, and so on, that need to
change during specific tests.

Tessent™ Shell User’s Manual 199

Tessent Shell Workflows
Loading the Design

Procedure
1. Apply the set_context command with the ID rtl2 for the second pass. For example:

set_context dft -rtl design_id rtl2

In the first DFT insertion pass, you set the design ID to "rtl1" with the command.

Note:
This manual uses recommended naming conventions for the design IDs for flat designs,
which are rtl1 for the first DFT insertion pass, rtl2 for the second DFT insertion pass,
and gate for the scan chain insertion pass. Refer to Considerations for Using Gate-Level
Verilog Netlists for the naming conventions when using gate-level Verilog netlists.

For a specified design, the design ID stores all the data associated with a DFT insertion pass
into the TSDB. For the first pass, "rtl1" contains the data for the MemoryBIST and boundary scan
hardware. Setting the design_id to rtl2 at the beginning of the second DFT insertion pass identifies
that "rtl2" stores the EDT or LBIST, and OCC hardware data generated during the second pass.
The rtl2 design data is cumulative. That is, it contains the necessary rtl1 data in addition to
the new data generated for EDT or LBIST, and OCC. The "rtl2" designation indicates that the
second insertion pass is performed on the resulting edits of the first pass RTL data. In subsequent
insertion passes, you can use either design ID to load the design and its supporting files.
Tessent generates IJTAG nodes during both insertion passes and their module names are
differentiated using the design ID you specified in each pass.

2. Specify the set_tsdb_output_directory command with the same directory location for both the first
and second DFT insertion passes:

set_tsdb_output_directory ../tsdb_rtl

If you forget to specify the command for the second DFT insertion pass, Tessent creates a default
tsdb_outdir directory in the current working directory. If you use a different output TSDB directory
for the two insertion passes, ensure that you open the TSDB used by the first insertion pass by
specifying the open_tsdb command.
For more information about the TSDB, refer to Tessent Shell Data Base (TSDB) in the Tessent
Shell Reference Manual. For information about the TSDB data flow, refer to TSDB Data Flow for
the Tessent Shell Flow.

3. Specify the read_cell_library command to read in the library file for the standard cells and the pad
I/O macros.
The following command reads the Tessent cell library file for the standard cells and pad I/O
macros:

read_cell_library ../library/adk_complete.tcelllib

If the pad I/O library and standard cell library are separate, use the following commands to read in
the atpg.lib files and the library for the pad I/O description:

read_cell_library ../library/atpg.lib
read_cell_library ../library/pad.library

200 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Specifying and Verifying the DFT Requirements

4. Specify the read_design command to load the design:

read_design cpu_top –design_id rtl1

The design was created in the first DFT insertion pass when you used the read_verilog or
read_vhdl commands. The read_design command also loads supporting files such as the TCD,
ICL, and PDL, if present in the TSDB.
The design is read in using the design ID from the first DFT insertion. In this case, the design ID is
"rtl1"
To load the design correctly for the second insertion pass, the read_design command refers to
the design source dictionary that was created during the first DFT insertion pass and stored in the
dft_inserted_designs directory.

5. Specify the set_current_design command to elaborate the design:

set_current_design cpu_top

If any module descriptions are missing, design elaboration identifies them. You can fix elaboration
errors by adding the missing modules or by specifying the add_black_boxes ‑module command.

Specifying and Verifying the DFT Requirements

After loading your design data, define the DFT requirements for the EDT or LBIST, and OCC hardware
you want to insert. The requirements definition includes adding DFT signals followed by performing
design rule checking.

Figure 31. Flow for Specifying and Verifying the DFT Requirements

Procedure
1. Specify the set_dft_specification_requirements command to run pre-DFT design rule checking as
follows:

set_dft_specification_requirements -logic_test on

Because you already specified that you were working at the chip level in the first DFT insertion
pass, you do not need to specify this information for the second insertion pass.

2. Specify the add_dft_signals command to define the DFT signals. For example:

Tessent™ Shell User’s Manual 201

Tessent Shell Workflows
Specifying and Verifying the DFT Requirements

add_dft_signals ltest_en
…

Refer to “DFT Signals” on page 202 for a more complete example.

DFT signals are used to determine the various modes of operation, control values, and signal
behaviors that are necessary for each test mode. The DFT signals capability in Tessent Shell
automates the following tasks:

• Adding DFT signals

• Configuring DFT signals for various modes of operation

• Transferring information about DFT signals from one step to the next
Based on the specified mode of operation, Tessent creates the necessary setup procedures to
control DFT signals through an IJTAG network.

3. Specify the check_design_rules command to run pre-DFT design rule checking.

Tessent Shell generates DFT_C violations when error conditions are detected. For details, refer to
"Pre-DFT Clock Rules (DFT_C Rules)" in the Tessent Shell Reference Manual.

Results
When DRC passes, Tessent Shell shifts from setup mode to analysis mode. Pre-DFT DRC verifies that
clocks are defined for all of the scannable sequential elements to be scan-tested and identifies the async
sets and resets so that they can be turned off during shift operations. In addition, if you have specified the
add_dft_clock_enable command, Tessent checks clock-gating logic and module-type clocks.

Examples

DFT Signals
You can add static DFT signals and dynamic DFT signals. Static DFT signals include global DFT control,
logic test control, and scan mode signals. As described in the add_dft_signals command description,
these DFT signals are typically controlled by a Test Data Register that is part of the IJTAG network.
Most dynamic DFT signals originate from primary input ports. For chip-level designs, these primary input
ports must already be present in the RTL and be pre-connected to a pad buffer cell. The three dynamic
DFT signals that originate from primary inputs are test_clock, scan_en, and edt_update. To share their
input ports with the functional mode, ensure that you added auxiliary input logic for them during boundary
scan insertion. Tessent cannot create the nodes as ports.
The following example shows the required DFT signals for the second insertion pass when you are
inserting EDT or LBIST, and OCC.

// Create the static DFT signals

add_dft_signals ltest_en

// Generate dynamic DFT signals from source nodes

add_dft_signals scan_en edt_update test_clock \
–source_node { porta_in1 portb_in1 porta_in2 }

// Create shift_capture_clock and edt_clock as gated versions of

202 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Specifying and Verifying the DFT Requirements
// test_clock
add_dft_signals shift_capture_clock edt_clock -create_from_other_signals

// Used by top-level EDT

add_dft_signals edt_mode

// Required for boundary scan to be used with logic test without

// contacting inputs
add_dft_signals int_ltest_en output_pad_disable

// Required for scan-tested instruments (STI network) such as MemoryBIST

// and boundary scan
add_dft_signals tck_occ_en

// To bypass memories or to run multiple load ATPG for memories

add_dft_signals memory_bypass_en

Note:
Tessent Shell automatically recognizes scan-tested instruments and stitches them into scan
chains.

Refer to the Tessent Shell Reference Manual for information about the following commands:

• add_dft_signals — Insert DFT signals.

• register_static_dft_signal_names — Register your DFT signal, if, for example, you need to
augment the default DFT signals for specific usage requirements.

• report_dft_signals — View a list of the DFT signals added with the add_dft_signals command.

• delete_dft_signals — Delete any previously specified DFT signals.

• add_dft_modal_connections — Though not normally required for flat designs, if you have
multiple EDT configurations that you want to multiplex into a common set of top-level I/Os, use
this command to implement the multiplexing. In addition, if the EDT channel pins are shared with
functional pins, they need to include auxiliary input/output muxing logic.

Related Topics
add_dft_signals

register_static_dft_signal_names

report_dft_signal_names

report_dft_signals

delete_dft_signals

add_dft_modal_connections

Tessent™ Shell User’s Manual 203

Tessent Shell Workflows
Creating the DFT Specification

Creating the DFT Specification

After defining the DFT requirements for the DFT signals in setup mode, you are ready to create the DFT
specification for EDT or LBIST, and OCC in analysis mode. The DFT specification defines how the tool
inserts hardware into the design.

Figure 32. Flow for Creating the DFT Specification

Prerequisites
• For EDT or LBIST, and OCC, you must first generate a skeleton DFT specification that contains
three empty SRI SIBs that specify the EDT, LBIST, and OCC sections of the IJTAG network.
Creating the DFT specification for EDT or LBIST, and OCC differs from the process you use for
MemoryBIST and boundary scan in the first DFT insertion pass.

Procedure
1. Specify the create_dft_specification command as follows:

create_dft_specification -sri_sib_list {occ edt lbist}

2. Apply commands to customize the DFT specification using one of the following interfaces:
To customize the DFT specification on the command line, type the EDT or LBIST, and OCC data
as an argument to the read_config_data -from_string command. Modify the DFT specification
with introspected data using the add_config_element and set_config_value commands. Tessent
automatically saves modifications to the dofile/scripts directory for use in future sessions. Refer to
“DFT Customization Example” on page 205 for an example.

Note:
To input the EDT or LBIST, and OCC wrapper details for the DFT specification, you can
either use the Tessent GUI, known as Tessent Visualizer (refer to "Customizing the DFT
Specification for EDT"), or the Tessent Shell command line.

204 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Creating the DFT Specification

Note:
Tessent automatically connects the divided boundary scan segment (if present from the
first DFT insertion pass) to the EDT hardware that Tessent inserts in the second insertion
pass. Refer to connect_bscan_segments_to_lsb_chains for details.

3. Specify the following command to ensure that no errors exist in the DFT specification:

process_dft_specification -validate_only

Complete this step before generating the EDT, LBIST, and OCC hardware.

Examples

DFT Customization Example

The following example modifies a DFT specification to add LBIST (including EDT) and OCC and saves
the changes.

Note:
If you are using Tessent OCC, Tessent Scan automatically identifies and stitches the sub-chains
in the OCC into scan chains.

read_config_data -in $spec -from_string {

OCC {
ijtag_host_interface : Sib(occ);
}
}
# The following illustrates a generic way to populate the OCC. The clock
# list is design specific and needs to be updated for the design to the
# OCC, scan_enable and shift_capture_clock are connected automatically
# Modify the following for your specific design requirements
set id_clk_list [list \
clk1 clk1_p \
clk2 clk2_p \
clk3 clk3_p \
clk4 clk4_p \
ramclk_p ramclk_p \
]
foreach {id clk} $id_clk_list {
set occ [add_config_element OCC/Controller($id) -in $spec]
set_config_value clock_intercept_node -in $occ $clk
}
report_config_data $spec
# To the EDT controller, the edt_clock and edt_update are connected
# automatically. The EDT controller is built-in with bypass
# Modify the following for your specific design requirements
read_config_data -in $spec -from_string {
EDT {
ijtag_host_interface : Sib(edt);

Tessent™ Shell User’s Manual 205

Tessent Shell Workflows
Creating the DFT Specification
Controller (c1) {
longest_chain_range : 65, 100;
scan_chain_count : 85;
input_channel_count : 3;
output_channel_count : 3;
Connections +{
EdtChannelsIn(1) {
}
EdtChannelsIn(2) {
}
EdtChannelsIn(3) {
}
EdtChannelsOut(1) {
}
EdtChannelsOut(2) {
}
EdtChannelsOut(3) {
}
}
}
}
}
# Connecting the EDT channel in to the primary input and connecting
# EDT channel out to the primary output
# You had inserted the auxiliary logic for these ports during the first DFT
insertion pass
set_config_value port_pin_name \
-in $spec/EDT/Controller(c1)/Connections/EdtChannelsIn(1) \
[get_single_name [get_auxiliary_pins portain_p[0] -direction input]]
set_config_value port_pin_name \
-in $spec/EDT/Controller(c1)/Connections/EdtChannelsIn(2) \
[get_single_name [get_auxiliary_pins portain_p[1] -direction input]]
set_config_value port_pin_name \
-in $spec/EDT/Controller(c1)/Connections/EdtChannelsIn(3) \
[get_single_name [get_auxiliary_pins portain_p[2] -direction input]]
set_config_value port_pin_name \
-in $spec/EDT/Controller(c1)/Connections/EdtChannelsOut(1) \
[get_single_name [get_auxiliary_pins portbout_p[0] -direction output] ]
set_config_value port_pin_name \
-in $spec/EDT/Controller(c1)/Connections/EdtChannelsOut(2) \
[get_single_name [get_auxiliary_pins portbout_p[1] -direction output] ]
set_config_value port_pin_name \
-in $spec/EDT/Controller(c1)/Connections/EdtChannelsOut(3) \
[get_single_name [get_auxiliary_pins portbout_p[2] -direction output] ]
report_config_data $spec
LogicBist {
ijtag_host_interface : Sib(lbist) ;
Controller(C0) {
ShiftCycles {
max : 100 ;
}
CaptureCycles {
max : 10 ;

206 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Generating the EDT, Hybrid TK/LBIST, and OCC Hardware
}
PatternCount {
max : 16384;
}
Connections {
shift_clock_src : clk1;
}
}
NcpIndexDecoder {
Ncp(no_pulse) {
}
Ncp(pulse_clk1) {
cycle(0) : $occ;
}
Ncp(pulse_clk2) {
cycle(0) : $occ;
cycle(1) : $occ;
}
}
}

Generating the EDT, Hybrid TK/LBIST, and OCC Hardware

After creating the DFT specification, generate the EDT or hybrid TK/LBIST, and OCC hardware. The
process_dft_specification command generates and inserts the DFT hardware, as defined by the DFT
specification, into your design.

Figure 33. Flow for Inserting the Second-Pass Hardware

Procedure
1. Specify the process_dft_specification command to insert EDT or LBIST, and OCC in the second
pass:

process_dft_specification

2. (Optional) If you want to generate the hardware, but not insert it into the design, specify the
following command:

Tessent™ Shell User’s Manual 207

Tessent Shell Workflows
Extracting the ICL Module Description

process_dft_specification -no_insertion

You can then insert the hardware into the design manually.

Extracting the ICL Module Description

After inserting the EDT or LBIST, and OCC hardware, verify the connectivity of the ICL modules that
were inserted with the process_dft_specification command. This is a preparatory step for ICL pattern
generation.

Figure 34. Flow for Extracting ICL

Procedure
1. Specify the extract_icl command to find all modules (both Tessent instruments and non-Tessent
instruments) and their associated ICL descriptions, and to run DRC to verify their connectivity.
The top-level ICL description corresponds to the design name you specified with the
set_current_design command during the first insertion pass (which is also the same design name
you specified when you elaborated the design at the beginning of the second insertion pass).

2. Specify the analyze_drc_violation command to debug the DRC violations.

Tessent generates I-rule errors when it detects ICL extraction errors and opens Tessent Visualizer
to a schematic view of the error. For more information about the DRC I-rule errors, refer to "ICL
Extraction Rules (I Rules)" in the Tessent Shell Reference Manual. For details about using Tessent
Visualizer, refer to “Tessent Visualizer” on page 831.
The extract_icl command also creates a Synopsys Design Compiler file that you can use for
synthesis. Refer to Timing Constraints (SDC) for more information.

Generating ICL Patterns and Running Simulation

Generate and process the ICL verification patterns for EDT or LBIST, and OCC, then verify the testbench
simulations.
The following figure shows the tasks required to complete the second insertion pass and move on to
synthesis.

208 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Performing Synthesis

Figure 35. Flow for Generating and Simulating ICL Patterns

Procedure
1. Generate the test patterns for the design:

create_patterns_specification

2. Validate and process the content of the test patterns:

process_patterns_specification

3. Run and check testbench simulations. For example:

# Run and check testbench simulations

set_simulation_library_sources -v ../library/verilog/adk.v \
-v ../library/pad_cells.v -v ../library/memory/ram.v

run_testbench_simulations
check_testbench_simulations -report_status

Performing Synthesis
Synthesize the original RTL and the DFT-inserted RTL for MemoryBIST, boundary scan, EDT or LBIST,
and OCC. For RTL designs, perform synthesis once after performing the first and second DFT insertion
passes.

Tessent™ Shell User’s Manual 209

Tessent Shell Workflows
Performing Scan Chain Insertion (Flat Design)

Prerequisites
• For information regarding synthesis with third-party tools and Tessent DFT methodologies, refer
to “Synthesis Guidelines for RTL Designs With Tessent Inserted DFT” on page 989.

• Tessent Shell supports several third-party synthesis tools by generating Synopsys Design
Constraints (SDC) to convey timing constraint information. Refer to Timing Constraints (SDC)
for details. Find information about example scripts for the supported synthesis tools in “Example
Scripts Using Tessent Tool-Generated SDC” on page 979.

Procedure
1. Specify the write_design_import_script command to create a design load script that loads the RTL
design as it exists after the two DFT insertion passes. The following is an example command:
write_design_import_script for_synthesis.tcl -replace

Note:
If you are not using a supported third-party synthesis tool, you can still use the
write_design_import_script command to create a script and adjust it to match the
command set of your synthesis tool.

2. Synthesize the hardware using the synthesis manager of the run_synthesis command to run the
third-party synthesis tool. The following is an example command:
run_synthesis -startup_file for_synthesis.tcl

Alternatively, you can generate the synthesis script without running synthesis by specifying your
local startup file. The following example targets dc_shell:
run_synthesis -startup_file ./.synopsys_dc.setup

Use the following command to generate a script for other third-party synthesis tools:
run_synthesis -startup_file for_synthesis.tcl -generate_script_only

Performing Scan Chain Insertion (Flat Design)

During scan chain insertion, Tessent inserts and stitches scan chains on the gate-level netlist that was
synthesized after DFT insertion. After you run scan chain insertion, proceed to ATPG pattern generation.
During scan insertion using Tessent Scan, the non-scan instances such as EDT are automatically
understood. In addition, the built-in OCC sub-chains are understood and stitched into scan chains.
Tessent uses DFT signals such as the scan enable that you specified in the previous insertion passes,
therefore you do not need to specify the DFT signals again.
For information about scan chain insertion using Tessent Shell, refer to the "Internal Scan and Test
Circuitry Insertion" in the Tessent Scan and ATPG User’s Manual.

Procedure
1. Specify the following command to set the DFT context:

set_context dft –scan -design_id gate

210 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Performing Scan Chain Insertion (Flat Design)

When setting the context, ensure that you specify the design ID with a unique name. The
recommended name is gate for a flat design. For a gate-level netlist the recommended name is
gate3.

2. Load the synthesized netlist. For example:

../Synthesis/cpu_top_synthesized.vg

This netlist contains the gates for the original RTL design and the DFT-inserted hardware.

3. Specify the same output directory you used in the first and second DFT passes:

../tsdb_rtl

4. Load the rtl2 design data for the DFT hardware that you inserted. For example:

cpu_top -design_id rtl2 -no_hdl

The -no_hdl switch specifies to read in all of the DFT data files—such as ICL, PDL, and TCD—
except for the design files. (You are using the synthesized design from this point forward.)

After design elaboration and design rule checking, Tessent Shell transitions from Setup mode to
Analysis mode.

5. Specify the add_scan_mode edt_mode command to connect the scan chains to the EDT signals
and EDT hardware that you inserted during the second insertion pass.
The use of preregistered DFT signal edt_mode as the scan mode using the add_scan_mode
command infers the ‑enable_dft_signal also as the edt_mode DFT signal.

Results
The scan stitched and inserted netlist is located in the TSDB under the design ID gate for RTL designs or
gate3 for gate-level netlists. Refer to Considerations for Using Gate-Level Verilog Netlists for details.

Examples
The following dofile shows a command flow for scan insertion and stitching:

set_context dft –scan -design_id gate

read_cell_library ../library/tessent/adk.tcelllib
read_verilog ../Synthesis/cpu_top_synthesized.vg
set_tsdb_output_directory ../tsdb_rtl
read_design cpu_top -design_id rtl2 -no_hdl
set_current_design cpu_top
check_design_rules
set edt_instance [get_name_list [get_instance -of_module \
[get_name [get_icl_module -filter \
tessent_instrument_type==mentor::edt]]]]
add_scan_mode edt_mode -edt_instance $edt_instance
analyze_scan_chains
report_scan_chains
insert_test_logic
exit

Tessent™ Shell User’s Manual 211

Tessent Shell Workflows
Performing ATPG Pattern Generation

Related Topics
read_verilog

set_tsdb_output_directory

read_design

Performing ATPG Pattern Generation

After inserting scan chains, proceed to ATPG pattern generation. You can create patterns for various fault
model types, including stuck-at, transition, path delay, and IDDQ.

Procedure
1. Do one of the following:

• If you used Tessent Scan to insert the scan chains, run the "import_scan_mode edt_mode"
command for ATPG pattern generation.

• If you did not use Tessent Scan for scan insertion, use the TCD IP mapping flow as described in
"Running ATPG Patterns without Tessent Scan" in the Tessent Scan and ATPG User’s Manual.
When you run the import_scan_mode command, Tessent Shell passes through the scan-insert
design data for the EDT or LBIST, and OCC logic. This data includes the scan structures (scan
chains and scan channels) that are stored in the TSDB under the gate design ID. The gate design
ID was created during scan insertion when you specified the insert_test_logic command.
In addition, Tessent automatically creates and simulates the test_setup procedure cycles that
are required to initialize the EDT or LBIST, and OCC static signals. You only need to specify non-
default parameter values, if, for example, you run EDT with bypass on or set int_ltest_en to 1 to
use the boundary scan as the source of the core values and isolate the ATPG test from the top-
level IOs.
You can create ATPG patterns for any mode that you need, such as stuck-at and transition.
These patterns are stored in the TSDB database under the logic_test_cores directory. The
import_scan_mode command uses the same scan configuration—that is, the DFT signals—that
were used for the add_scan_mode command during scan insertion.

2. Specify the set_current_mode command to indicate the type of pattern you are generating (refer to
“Stuck-at ATPG Patterns” on page 213 and “Transition At-speed ATPG Patterns” on page 213).
In addition, the name you give to the generated ATPG pattern sets must differ from the mode name
you specify for import_scan_mode (that is, "edt_mode").

3. Specify the create_patterns command to generate the ATPG patterns.

4. Specify the write_tsdb_data command to save the flat model, fault list, PatDB, and TCD files into
the TSDB.

5. Specify the write_patterns command to write out the Verilog testbenches and STIL patterns.
For details about ATPG pattern generation, refer to "Running ATPG Patterns" in the Tessent Scan
and ATPG User’s Manual.

212 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Performing ATPG Pattern Generation

Examples

Stuck-at ATPG Patterns

The following example generates stuck-at ATPG patterns as indicated by the "set_current_mode
edt_stuck" command. It shows that you have a choice between using the boundary scan chains for
capture during ATPG or using the primary pins of the chips (using the pads).

set_context patterns -scan

read_cell_library ../library/tessent/adk.tcelllib
read_cell_library ../library/memory/memory.lib
open_tsdb ../tsdb_rtl
read_design cpu_top -design_id gate
set_current_design cpu_top
set_current_mode edt_stuck
import_scan_mode edt_mode

# To apply the patterns through the boundary scan chains and not through
# the pads use:
# set_static_dft_signal_values int_ltest_en 1
# set_static_dft_signal_value output_pad_disable 1
# To allow the shift_capture_clock during capture phase on Scan Tested
# Instruments:
set_system_mode analysis
create_patterns
write_tsdb_data –replace
write_patterns patterns/cpu_top_stuck_parallel.v -verilog -parallel \
-replace -pattern_sets scan
write_patterns patterns/cpu_top_stuck_serial.v -verilog -serial -replace
exit

Transition At-speed ATPG Patterns

The following example generates transition at-speed patterns. The import_scan_mode command
uses the –fast_capture_mode switch to indicate that the OCC supplies the fast clock during capture.
The set_current_mode command indicates edt_transition, and the set_fault_type command indicates
transition faults.

set_context patterns -scan

read_cell_library ../library/tessent/adk.tcelllib
read_cell_library ../library/memory/memory.lib
open_tsdb ../tsdb_rtl
read_design cpu_top -design_id gate
set_current_design cpu_top
set_current_mode edt_transition
import_scan_mode edt_mode -fast_capture_mode on -verbose

set_static_dft_signal_values int_ltest_en 1
set_static_dft_signal_value output_pad_disable 1
set_system_mode analysis
set_fault_type transition
set_external_capture_options -pll_cycles 5 [lindex [get_timeplate_list] 0]

Tessent™ Shell User’s Manual 213

Tessent Shell Workflows
Simulating LBIST Faults
create_patterns
write_tsdb_data –replace
write_patterns patterns/cpu_top_transition_parallel.v -verilog \
-parallel -replace -pattern_sets scan
write_patterns patterns/cpu_top_transition_serial.v -verilog -serial \
-replace
exit

Simulating LBIST Faults

If your design contains logic BIST, you must run LBIST fault simulation after scan insertion.

Prerequisites
• Scan insertion has been completed.

Procedure
1. Set the context:

set_context pattern -scan -design_id rtl2

2. Load the cell and memory libraries:

set_tsdb_output_directory tsdb_outdir
read_cell_library ../prereq/techlib_adk.tnt/tessent/adk.tcelllib
read_cell_library design/mem/mems.atpglib

3. Load the scan-inserted gate-level design:

read_design top -design_id rtl2

4. Elaborate the design:

set_current_design top

5. Import the scan insertion data:

import_scan_mode int_mode

6. Define the LBIST core instance:

add_core_instances -module top_dft2_tessent_lbist

7. Define DFT signals that differ from their default values:

set_static_dft_signal_values tck_occ_en 1
set_static_dft_signal_values int_ltest_en 1
set_static_dft_signal_values ltest_en 1
set_static_dft_signal_values control_test_point_en 1

214 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Simulating LBIST Faults
set_static_dft_signal_values observe_test_point_en 1

set_core_instance_parameters -instrument_type occ ‑parameter_values

{static_clock_control external}

8. Point to the dofile containing the proc definitions:

dofile
tsdb_outdir/instruments/top_dft2_lbist_ncp_index_decoder.instrument/t
op_dft2_tessent_lbist_ncp_index_decoder.dofile

set_static_dft_signal_values x_bounding_en 1

9. Add required pin constraints and output masks:

add_input_constraints [get_ports {[ABC].*} ‑regexp] ‑CX

add_output_masks [get_ports Y*]

report_static_dft_signal_settings

10. Run rule checks:

set_system_mode analysis
report_scan_cells> scan_cells_fsim.rpt
report_clocks
report_pin_constraints

11. Read the test proc file containing NCP definitions:

read_procfile
tsdb_outdir/instruments/top_dft2_lbist_ncp_index_decoder.instrument/t
op_dft2_tessent_lbist_ncp_index_decoder.testproc

12. Run pattern fault simulation:

add_faults -all
set_random_patterns 4096
simulate_patterns -source bist -store all

13. Report the test coverage and other test data:

report_statistics

14. Write the patterns using the write_patterns or write_tsdb_data command:

#write_patterns elt1_lbist_patt_parallel_ncp.v -verilog -parallel

# ‑replace -mode_internal -begin 0 -end 260
write_tsdb_data -rep

Tessent™ Shell User’s Manual 215

Tessent Shell Workflows
Considerations for Using Gate-Level Verilog Netlists
report_lbist_configuration -hardware_default_compatibility

exit

Considerations for Using Gate-Level Verilog

Netlists
In some cases, you may only have a gate-level Verilog netlist, not the RTL. You can use Tessent Shell to
perform the DFT insertion flow when you have a gate-level netlist. The flow is similar to the RTL and scan
DFT insertion flow. The main difference is that you must perform synthesis after each DFT insertion pass.
Figure 36 shows the gate-level DFT insertion sequence in which you insert MemoryBIST and boundary
scan in the first insertion pass and then immediately run synthesis on these instruments before inserting
the logic test instruments for the second DFT insertion pass (EDT, LBIST, OCC, and so on). After
inserting the logic test instruments, run synthesis a second time before proceeding to scan chain
insertion.

Figure 36. Two-Pass Insertion Flow for RTL, Gate-Level Designs

The following differences apply when using a gate-level Verilog netlist rather than RTL. Other than these
differences, plus performing synthesis after each DFT insertion pass, you can follow the flow as described
starting with First DFT Insertion Pass: Performing MemoryBIST and Boundary Scan.

• Prerequisites — You must have the Tessent cell library or the ATPG library for the standard
cells, in addition to the Tessent cell library for the I/O pad cells.

• Design Loading — During the first and second DFT insertion passes, ensure the following:

◦ Specify the set_context command with the -no_rtl option rather than the -rtl option.

◦ When setting the context, use the recommended naming conventions for the design IDs,
which are "gate1" for the boundary scan/MemoryBIST insertion pass and "gate2" for the
EDT/OCC insertion pass. If you are following this convention, you would then use design ID
"gate3" for scan insertion.

◦ Use the read_cell_library command to read in the library files for both the standard cells and
pad I/O macros that are instantiated in the design.

216 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Tessent Shell Flow for Hierarchical Designs

Tessent Shell Flow for Hierarchical Designs

Tessent Shell uses the same "divide and conquer" methodology for hierarchical DFT by enabling you
to perform RTL and scan DFT insertion at the sub-physical block level rather than only at the chip level.
Implementing DFT hierarchically in a bottom-up process, starting with the lowest level blocks, helps divide
the task and make it manageable.
Hierarchical design methodologies provide efficiencies for large designs. Rather than design at the chip
level, chip designers break designs down into RTL blocks that enable design teams to work on different
functional blocks in parallel. This method streamlines the process and enables RTL modifications,
engineering change orders (ECOs), and other changes to be localized to particular blocks.

Tip
Before performing DFT on a hierarchical design, familiarize yourself with “DFT Architecture
Guidelines for Hierarchical Designs” on page 125.

This section builds on the "Tessent Shell Flow for Flat Designs" section to describe the pre-layout RTL
and scan DFT insertion process for hierarchical designs.
Refer to the following test case for a detailed usage example of the flow described in this section:

tessent_example_hierarchical_flow_<software_version>.tgz

Access this test case from the following directory:

<software_release_tree>/share/UsageExamples/

Hierarchical DFT Terminology

How the DFT Insertion Flow Applies to Hierarchical Designs
RTL and Scan DFT Insertion Flow for Physical Blocks
RTL and Scan DFT Insertion Flow for the Top Chip
RTL and Scan DFT Insertion Flow for Sub-Blocks
RTL and Scan DFT Insertion Flow for Instrument Blocks
RTL and DFT Insertion Flow With Third-Party Scan

Hierarchical DFT Terminology

Tessent Shell uses a particular set of terms related to working with blocks in a hierarchical design. You
must understand these terms to perform the RTL and scan DFT insertion process on hierarchical designs.
Refer to set_design_level in the Tessent Shell Reference Manual for more information.

• Physical Block — Physical blocks are logical entities that remain intact through tapeout. They
are synthesis and layout regions. Below the top level of a chip, these are blocks that you can
reuse, or instantiate, within a chip or across multiple chips. You perform synthesis on these
blocks independent of the rest of the chip design.

Tessent™ Shell User’s Manual 217

Tessent Shell Workflows
Hierarchical DFT Terminology

When performing DFT insertion on physical blocks, Tessent preserves the ports at the root of the
physical block. Instances of the physical block that exist below the current physical block may not
be preserved in the final layout when ungrouping is used.
In Tessent Shell, the hierarchical DFT insertion flow distinguishes between three types of physical
blocks: wrapped cores, unwrapped cores, and chip.

◦ Wrapped core. Wrapped cores contain wrapper cells that are used to isolate the internal logic
of the core. Wrapper cells are inserted when you perform scan chain insertion. Wrapped
cores are required to make the cores reusable through ATPG pattern retargeting. Wrapped
cores can contain sub-blocks. (Refer to the following description.)

◦ Unwrapped core. Unwrapped cores do not contain wrapper cells but can contain sub-blocks.
For additional information, refer to "Unwrapped Cores Versus Wrapped Cores" in the Tessent
Scan and ATPG User’s Manual.

◦ Chip. The chip is the top-level physical block—that is, the entire design—in which you
typically find the pad I/O macros and clock controllers. A chip may include another physical
block or sub-block. Physical blocks can be wrapped cores or unwrapped cores. Unlike the
other types of physical blocks, chips are layout regions.

• Sub-Block — Sub-blocks are designs that exist within parent blocks and are synthesized with
their parent blocks, which could be wrapped cores, unwrapped cores, or the top level of the chip.
Sub-blocks merge into their parent physical blocks during synthesis of the parent block. Refer to
set_design_level for details.
Sub-blocks are not layout physical regions. After layout is performed on the post-layout netlist,
the sub-block module boundary may or may not be preserved. Sometimes the same sub-block is
instantiated at both the physical block level and the chip level, as shown in the following figure.

Figure 37. Hierarchical Design Levels

You can insert DFT hardware such as MemoryBIST, EDT, and OCC into sub-blocks, but you
perform synthesis and scan insertion at the sub-block’s parent physical block level (where the

218 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
How the DFT Insertion Flow Applies to Hierarchical Designs
sub-block is instantiated). To learn about how to use sub-blocks within the Tessent Shell flow,
refer to RTL and Scan DFT Insertion Flow for Sub-Blocks.

• Instrument Block — The design is a special empty module into which the DFT elements are
inserted. The special module is then manually instantiated into its parent block and its pins are
manually connected inside the parent block.
The synthesis, scan chain insertion, and pattern generation steps are done the usual way, as
described in Instrument Block DFT Insertion Flow for the Next Parent Level.

• ATPG (or scan) pattern retargeting — The process by which Tessent Shell preserves the ATPG
patterns associated with wrapped cores for purposes of reuse when testing the logic at the parent
instantiation level. This means you do not have to regenerate the patterns when you process the
top level of the chip. Instead, you retarget the wrapped core ATPG patterns to the top level. Every
instantiation of a wrapped core includes its associated ATPG patterns.
For details, refer to "Scan Pattern Retargeting" in the Tessent Scan and ATPG User’s Manual.
For purposes of ATPG pattern retargeting and graybox modeling (refer to the following
description), Tessent Shell differentiates between a wrapped core’s internal circuitry and its
external circuitry.

◦ Internal mode. Internal mode is the view into the wrapped core from the wrapper cells. That
is, the logic completely internal to the core. Tessent Shell retargets internal mode ATPG
patterns during ATPG pattern generation for the chip-level design.

◦ External mode. External mode indicates the view out of the wrapped core from the wrapper
cells. That is, the logic that connects the wrapped core to external logic. Tessent Shell uses
the external mode to build graybox models, which are used by the internal modes of their
parent physical blocks.

• Graybox — Graybox models are wrapped core models that preserve only the core’s external
mode logic along with the portion of the IJTAG network needed for test setup of the logic test
modes. The purpose of graybox models in the bottom-up hierarchical DFT process is to retain the
minimum logic required to generate ATPG patterns for the internal modes of the parent physical
blocks. For details, refer to "Graybox Overview" in the Tessent Scan and ATPG User’s Manual
and “Graybox Model” on page 130.

How the DFT Insertion Flow Applies to Hierarchical

Designs
Performing RTL and scan DFT insertion on hierarchical designs assumes basic knowledge of the RTL
and scan insertion flow for flat designs. The process for hierarchical designs builds on the process you
would use for a flat design.
You perform a two-pass pre-scan insertion process for flat designs. For hierarchical designs, the same
flow applies except that you perform the insertion process in a bottom-up manner for each core and sub-
block in the design. After you have inserted DFT into all the lower-level physical blocks, you perform the
same insertion into the parent blocks until you have reached the top level of the chip.
The following considerations apply when performing DFT insertion on a hierarchical design as opposed to
a flat design:

Tessent™ Shell User’s Manual 219

Tessent Shell Workflows
How the DFT Insertion Flow Applies to Hierarchical Designs

• When performing hierarchical DFT, you must specify the hierarchical design level at which you
are performing the DFT insertion process. For flat designs, the set_design_level command is
always set to chip. For hierarchical designs, you can also specify physical_block or sub_block.

• Inserting boundary scan during the first DFT insertion pass typically applies to the chip design
level. For hierarchical designs, this means that for cores and sub-blocks you insert only
MemoryBIST during the first DFT insertion pass unless you have cores with embedded pad I/O
macros. If you have cores with embedded pad I/O macros, then you need to insert boundary scan
into the pad IOs using the embedded boundary scan flow as described in the Tessent Boundary
Scan User’s Manual.

• Within the hierarchical flow, each physical block and sub-block has a unique design name and
should have its own TSDB.

Tip
To facilitate data management, save each design (whether core, sub-block, or chip) in
its own TSDB directory. This is the recommended practice when using Tessent Shell for
DFT insertion. Using different directories ensures that you can run all sibling physical and
sub-blocks in parallel without causing read-write errors into the TSDB directories between
the parallel runs. Only when all the child physical and sub-blocks of a given block are
completed can you then implement the DFT into the given block. Refer to TSDB Data Flow
for the Tessent Shell Flow for more information.

• You can perform ATPG pattern retargeting of core-level patterns when you process the parent
physical block of the wrapper cores, as shown in section Top-Level ATPG Pattern Generation
Example.

220 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
RTL and Scan DFT Insertion Flow for Physical Blocks

RTL and Scan DFT Insertion Flow for Physical

Blocks
For each wrapped core, perform a two-pass pre-scan DFT insertion process as you would for a flat
design except that in the first DFT insertion pass, do not insert boundary scan unless you have embedded
pad IO macros present inside the core. The flow details for working with wrapped cores differ from those
when working with flat designs.
Refer to Tessent Shell Flow for Flat Designs for overall flow details.

Note:
This discussion assumes that your design consists of wrapped cores as your lower level physical
blocks, and that the wrapped cores do not contain embedded pad IOs, so boundary scan is not
required.

Figure 38. Two-Pass Insertion Flow, Physical Blocks

First DFT Insertion Pass: Performing Block-Level MemoryBIST

Second DFT Insertion Pass: Inserting Block-Level EDT and OCC
Specifying and Verifying the DFT Requirements: DFT Signals for Wrapped Cores
Performing Scan Chain Insertion: Wrapped Core

Tessent™ Shell User’s Manual 221

Tessent Shell Workflows
First DFT Insertion Pass: Performing Block-Level MemoryBIST
Verifying the ICL Model
Performing ATPG Pattern Generation: Wrapped Core
Running Recommended Validation Step for Pre-Layout Design Sign Off

First DFT Insertion Pass: Performing Block-Level

MemoryBIST
Because you are not inserting boundary scan at the same time as MemoryBIST (as in the flat flow), you
can follow the DFT insertion process for Tessent MemoryBIST.
Refer to "Getting Started" in the Tessent MemoryBIST User’s Manual.

Note:
The line numbers used in this procedure refer to the command flow dofile in Example 2 on
page 223.

Procedure
1. Load the RTL design data. (Refer to lines 1-22.) The following steps are important for the first DFT
insertion pass for wrapped cores:

a. Set the set_context -design_id switch to rtl1.

All the data associated with MemoryBIST insertion for the wrapped core is stored under the ID
"rtl1" in the wrapped core’s TSDB.

Note:
rtl1 is the recommended naming convention for the design ID for the first insertion
pass, but you can specify any name. Refer to Loading the Design for more information
about setting the design ID.

b. Specify the read_verilog command with a list of the RTL filenames and locations for Tessent to
read and compile for the design. For example:

../rtl/omsp_timerA_defines.v
../rtl/omsp_timerA_undefines.v
../rtl/omsp_timerA.v
../rtl/omsp_wakeup_cell.v
../rtl/omsp_watchdog.v
../rtl/openMSP430_defines.v
../rtl/openMSP430_undefines.v
../rtl/openMSP430.v
../rtl/processor_core.v

c. Set the design level to "physical_block" so that the layout of this core is maintained as an
independent logical entity through tapeout.

2. Create the DFT specification. (Refer to lines 24-30.)

3. Generate the MemoryBIST hardware and extract the ICL. (Refer to lines 32-36.)

222 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
First DFT Insertion Pass: Performing Block-Level MemoryBIST

4. Create the input test patterns and simulation testbenches. (Refer to lines 38-41.)

5. Run simulations to verify the design. (Refer to lines 43-47.)

Examples
The following dofile example shows a typical command flow as detailed in the procedure listed in the
preceding.

Example 2. Dofile Example for MemoryBIST in Physical Blocks

1 # Set context to dft and indicate DFT insertion into an rtl-level

design
2
3 set_context dft -rtl -design_id rtl1
4
5 # Set the TSDB directory location to be used
6
7 set_tsdb_output_directory ../tsdb_core
8
9 # Read in the memory library model
10 set_design_sources -format tcd_memory \
-y ../../../library/memory \
11 -extension tcd_memory
12
13 # Read in memory Verilog model
14 set_design_sources -format verilog \
-v {../../../library/memory/*.v }
15
16 # Read in the design
17 read_verilog -f rtl_file_list
18
19 set_current_design processor_core
20
21 # Set the design level as a physical_block
22 set_design_level physical_block
23
24 # Specify to insert memory test
25 set_dft_specification_requirements -memory_test on
26 add_clocks 0 dco_clk -period 3
27 check_design_rules
28 report_memory_instances
29 set spec [create_dft_specification]
30 report_config_data $spec
31
32 # Generate the memoryBIST hardware
33 process_dft_specification
34
35 # Create ICL for this design
36 extract_icl
37
38 # Generate testbenches
39 create_patterns_specification

Tessent™ Shell User’s Manual 223

Tessent Shell Workflows
Second DFT Insertion Pass: Inserting Block-Level EDT and OCC
40 process_patterns_specification
41 set_simulation_library_sources -v \
42
../../../library/standard_cells/verilog/NangateOpenCellLibrary.v
43
44 # Run simulations
45 run_testbench_simulations
46
47 # If simulation fails, use the following command
48 //check_testbench_simulations
49 exit

Second DFT Insertion Pass: Inserting Block-Level EDT

and OCC
In the second DFT insertion pass for wrapped cores, insert the EDT and OCC hardware. Unlike flat
designs, which use standard OCCs, for wrapped cores you have a choice between inserting OCCs of
type child or type standard.
Refer to "Tessent OCC Types and Usage" in the Tessent Scan and ATPG User’s Manual for details.
If your physical design implementation does not support using a clock MUX in the clock path, then you
can use an OCC of type child. With the child type OCC, only clock chopping and clock gating functions
occur inside the wrapped core, and these functions are sufficient for ATPG pattern retargeting (later in
the flow) as long as at the chip-level you have included a parent OCC or other hardware that can perform
clock selection.
Clock selection is used to select between shift and capture clocks when generating ATPG patterns for
the internal mode of the core. Typically, scan chain shifting occurs at a significantly slower speed than the
capture clock, hence the need for the clock.
Most of the steps for the second DFT insertion pass for wrapped cores are the same as those you would
perform for a flat design. Refer to the applicable sections.

Note:
The line numbers used in this procedure refer to the command flow dofile in Example 3.

Procedure
1. Load the design (lines 1-10). Refer to “Loading the Design” on page 199.

2. Specify and verify the DFT requirements (lines 12-31). Refer to “Specifying and Verifying the DFT
Requirements” on page 201.

Note:
Wrapped cores have their own DFT requirements for the clock signals.

3. Create the DFT specification (lines 33-37). Refer to “Creating the DFT Specification” on page 204.

4. Generate the EDT and OCC hardware (lines 39-77). Refer to “Generating the EDT, Hybrid
TK/LBIST, and OCC Hardware” on page 207.

224 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Second DFT Insertion Pass: Inserting Block-Level EDT and OCC

5. Extract the ICL module description (lines 79-83). Refer to “Extracting the ICL Module Description”
on page 208.

6. Generate ICL patterns and run the simulation (lines 85-94). Refer to “Generating ICL Patterns and
Running Simulation” on page 208.

Examples
The following dofile example shows that you set the design ID to "rtl2" for the second DFT insertion pass,
set the internal mode and external mode for the wrapped core, and have chosen to specify an OCC of
type child.

Example 3. Dofile for Second DFT Pass

1 # Set context to dft and specify design_id as rtl2

2 set_context dft -rtl -design_id rtl2
3
4 # Specify where the tsdb_outdir is to be located, default is at
5 # the current working directory
6 set_tsdb_output_directory ../tsdb_core
7
8 # Use read_design with the design ID from the first DFT insertion
pass
9 read_design processor_core -design_id rtl1
10 set_current_design processor_core
11
12 # No need to reset the design level, which remains
"physical_block" from
13 # the first pass
14 # Add DFT signals for the wrapped core
15
16 # The following commands are required for logic test
17 add_dft_signals ltest_en -create_with_tdr
18 add_dft_signals scan_en edt_update test_clock -source_node {
19 scan_enable edt_update test_clock_u }
20 add_dft_signals edt_clock shift_capture_clock \
-create_from_other_signals
21
22 # Required for memories to be tested with multiple load ATPG
patterns
23 add_dft_signals memory_bypass_en -create_with_tdr
24
25 # Required for STI network to be tested during logic test
26 add_dft_signals tck_occ_en -create_with_tdr
27
28 # Required for hierarchical DFT and used during scan insertion
29 # Specifying both the internal mode and the external mode
30 add_dft_signals int_ltest_en ext_ltest_en int_mode ext_mode
31
32 report_dft_signals
33
34 # Run pre-DFT DRC
35 set_dft_specification_requirements -logic_test on

Tessent™ Shell User’s Manual 225

Tessent Shell Workflows
Second DFT Insertion Pass: Inserting Block-Level EDT and OCC
36
37 check_design_rules
38 set spec [create_dft_specification -sri_sib_list {edt occ} ]
39
40 # Use report_config_syntax DftSpecification/edt|occ to see full
syntax
41 report_config_data $spec
42 read_config_data -in $spec -from_string {
43 OCC {
44 ijtag_host_interface : Sib(occ);
45 }
46 }
47 # The following is a generic way to populate the OCC
48 # The clock list is design specific and needs to be updated for
the design
49 # To the OCC - scan_enable and shift_capture_clock gets connected
50 # automatically
51 # Modify the following to your design requirements
52 set id_clk_list [list \
53 dco_clk dco_clk \
54 ]
55
56 foreach {id clk} $id_clk_list {
57 set occ [add_config_element OCC/Controller($id) -in $spec]
58 set_config_value clock_intercept_node -in $occ $clk
59 }
60 report_config_data $spec
61
62 ## To EDT controller, the edt_clock and edt_update get auto
connected
63 ## The EDT controller is built-in with bypass
64 ## Modify the following to your design requirements
65 read_config_data -in $spec -from_string {
66 EDT {
67 ijtag_host_interface : Sib(edt);
68 Controller (c1) {
69 longest_chain_range : 200, 300;
70 scan_chain_count : 60;
71 input_channel_count : 3;
72 output_channel_count : 2;
73 }
74 }
75 }
76 report_config_data $spec
77 //display_spec
78 # Generate the hardware
79 process_dft_specification
80
81 # Extract the IJTAG network and create ICL file for core level
82 extract_icl
83
84 # Write updated RTL into this new file to elaborate and
synthesize later

226 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Specifying and Verifying the DFT Requirements: DFT Signals for Wrapped Cores
85 write_design_import_script for_dc_synthesis.tcl -replace
86
87 # Generate testbench
88 create_patterns_specification
89 process_patterns_specification
90
91 set_simulation_library_sources -v \
92
../../../library/standard_cells/verilog/NangateOpenCellLibrary.v
93
94 # Run Verilog simulation
95 run_testbench_simulations
96 # If simulation fails, use the command below to see which pattern
failed
97 //check_testbench_simulations
98
99 exit

Specifying and Verifying the DFT Requirements: DFT

Signals for Wrapped Cores
After loading the design data from the TSDB, define the DFT requirements for the EDT and OCC
hardware. This includes adding DFT signals and performing DRC.

Figure 39. Flow for Specifying and Verifying the DFT Requirements for Wrapped Cores

Procedure
1. Specify the following command to set DFT requirements:

set_dft_specification_requirements -logic_test on

Note:
The design level as specified by set_design_level remains "physical_block" from the first
DFT insertion pass, so you do not need to specify this command again.

Tessent™ Shell User’s Manual 227

Tessent Shell Workflows
Specifying and Verifying the DFT Requirements: DFT Signals for Wrapped Cores

2. Use the following procedure to define the DFT signals for wrapped cores in the second DFT
insertion pass:

a. Specify a global DFT signal to enter logic test mode. For example:

add_dft_signals ltest_en -create_with_tdr

b. Define the DFT signals. For example:

add_dft_signals scan_en edt_update test_clock -source_node \

{ scan_enable edt_update test_clock_u }

add_dft_signals edt_clock shift_capture_clock \

-create_from_other_signals

If these ports do not exist, the tool creates new ports.

c. Specify the following command to test with multiple load ATPG patterns in MemoryBIST:

add_dft_signals memory_bypass_en -create_with_tdr

d. Specify the following command to test an STI network during logic test.

add_dft_signals tck_occ_en -create_with_tdr

e. Specify both the internal mode and the external mode for hierarchical DFT. This is required for
scan insertion.

add_dft_signals int_ltest_en ext_ltest_en int_mode ext_mode

This command specifies that wrapped cores have both internal modes and external modes,
and that you must specify both. Differentiating between internal mode and external mode
enables Tessent to stitch the scan chains into internal chains and external chains as described
in Performing Scan Chain Insertion: Wrapped Core.
The internal and external modes are also required for proper ATPG pattern retargeting and
graybox modeling later in the insertion flow. Refer to Hierarchical DFT Terminology for more
information.

3. After defining the DFT signals, run DRC as in the flat design flow.
If the design includes clock gating that is implemented in RTL and not with an integrated clock
gating cell, you must specify their func_en and test_en ports using the add_dft_clock_enables
command. Tessent checks for proper clock and asynchronous set and reset controllability.

Results
Tessent Shell generates DFT_C errors for DRCs that are run. For details, refer to "Pre-DFT Clock Rules
(DFT_C Rules)" in the Tessent Shell Reference Manual.

Examples
To define the DFT signals, the following example shows the required DFT signals for wrapped cores in
the second DFT insertion pass:

228 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Performing Scan Chain Insertion: Wrapped Core

# Required global DFT signal to enter logic test mode

add_dft_signals ltest_en -create_with_tdr

# If these ports do not exist, the tool creates new ports

add_dft_signals scan_en edt_update test_clock -source_node \
{ scan_enable edt_update test_clock_u }
add_dft_signals edt_clock shift_capture_clock -create_from_other_signals

# Required for MemoryBIST to be tested with multiple load ATPG patterns

add_dft_signals memory_bypass_en -create_with_tdr

# Required for STI network to be tested during logic test

add_dft_signals tck_occ_en -create_with_tdr

# Required for hierarchical DFT and used during scan insertion

# Specifying both the internal mode and the external mode
add_dft_signals int_ltest_en ext_ltest_en int_mode ext_mode

Performing Scan Chain Insertion: Wrapped Core

Scan chain insertion for wrapped cores includes a task for performing wrapper analysis, which prepares
the functional scannable sequential elements (or "flops") for reuse as wrapper cells. Specifically, these
cells are called shared wrapper cells. Using shared wrapper cells reduces the number of flops required
for isolating the internal test modes from the primary input ports of the wrapper core. It also reduces
the number of flops required for isolating the external test modes from the internal logic. Tessent
automatically generates shared wrapper cells.
The analyze_wrapper_cells command performs wrapper analysis. In addition to preparing the shared
wrapper cells, the command infers dedicated wrapper cells for ports having a large fanout or fan-
in. You can configure the size of the fan-in and fanout using the set_wrapper_analysis_options
-input_fanout_flop_threshold and -output_fanin_flop_threshold options. By default, Tessent infers
dedicated wrapper cells on input ports fanning out to 32 or more scannable flip-flops, and on output ports
in the fanout of 32 or more scannable flip-flops.
Both shared wrapper cells and dedicated wrapper cells can coexist in the same wrapper chains, which
helps Tessent maintain wrapper chains of similar length. Scan insertion uses the DFT signals int_ltest_en
and ext_ltest_en along with the scan enable signal to control the wrapper cell.
For information about scan chain insertion using Tessent Shell, refer to the "Internal Scan and Test
Circuitry Insertion" in the Tessent Scan and ATPG User’s Manual.

Note:
The line numbers used in this procedure refer to the command flow dofile in Example 4 on
page 231.

Prerequisites
• Prior to scan chain insertion, perform synthesis as described in section Performing Synthesis.

Tessent™ Shell User’s Manual 229

Tessent Shell Workflows
Performing Scan Chain Insertion: Wrapped Core

Procedure
1. Specify the following command to set the DFT context:

set_context dft -scan -design_id gate

2. Load the synthesized netlist. For example:

read_verilog ../3.synthesis/processor_core_synthesized.vg

3. Specify the same output directory you used in the first and second DFT passes:

set_tsdb_output_directory ../tsdb_core

4. Load the rtl2 design data for the DFT hardware you previously inserted. For example:

read_design processor_core -design_id rtl2 -no_hdl

5. Run design rule checking (DRC) using the following command:

check_design_rules

6. Set up the wrapper cells as follows (refer to lines 25-35):

a. Specify the options for analyzing the wrapper cells.

b. Add dedicated wrappers, as necessary.

c. Analyze the wrapper cells with the analyze_wrapper_cells command.

d. Ensure that you exclude the EDT channel IO ports from wrapper analysis.
For details, refer to "Scan Insertion for Wrapped Core" in the Tessent Scan and ATPG User’s
Manual.

7. Specify the add_scan_mode command to connect the scan chains to the EDT signals and EDT
hardware that you inserted during the second insertion pass.
Scan insertion for wrapper cells requires using multi-mode scan insertion as described in the
Tessent Scan and ATPG User’s Manual. Do the following (refer to lines 41-46):

a. Create one scan mode for the entire population of scan cells.
The entire population of scan cells are stitched into the first scan mode using the int_mode
command to generate a scan mode consisting of all the scan cells stitched together.

b. Create a second scan mode only for the shared and dedicated wrapper cells.
In the second DFT insertion pass, you had generated a DFT signal named "int_mode" with the
add_dft_signal command. This signal enables this scan mode. You do not need to specify the
add_scan_mode -enable_dft_signal switch when the mode name matches the name of a DFT
signal of type scan mode.
The add_scan_mode ext_mode command stitches the shared and dedicated wrapper cells
together, similar to the DFT signal you generated named ext_mode. ext_mode enables the scan
mode for shared and dedicated wrapper cells.

230 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Performing Scan Chain Insertion: Wrapped Core

Examples
The following dofile shows a command flow for scan insertion. The highlighted statements illustrate
additional considerations for performing scan insertion for wrapper cores. For a general overview, refer to
Performing Scan Chain Insertion (Flat Design) for a flat design.

Example 4. Scan Chain Insertion in Hierarchical Flow

1 set_context dft -scan -design_id gate

2
3 # You must respecify the TSDB
4 set_tsdb_output_directory ../tsdb_core
5
6 # Read Tessent library
7 read_cell_library \
8
../../../library/standard_cells/tessent/NangateOpenCellLibrary.tcell
lib
9
10 # Read synthesized netlist
11 read_verilog ../3.synthesis/processor_core_synthesized.vg
12
13 # Use read_design to read in the DFT signals and other data from
14 # the second DFT insertion pass
15 read_design processor_core -design_id rtl2 -no_hdl
16 set_current_design processor_core
17
18 # If there are no ATPG models available for memories, use
blackboxes
19 add_black_boxes -modules { \
20 SYNC_1RW_8Kx16 \
21 }
22
23 check_design_rules
24
25 report_clocks
26 # Exclude the EDT channel in and out ports from wrapper chain
analysis
27 # The ijtag_* edt_update ports are automatically excluded
28 set_wrapper_analysis_options \
29 -exclude_ports [ get_ports {*_edt_channels_*} ]
30
31 # To force insertion of dedicated wrapper cell use the following
command
32 # set_dedicated_wrapper_cell_options on -ports {.... }
33
34 # Perform wrapper cell analysis
35 analyze_wrapper_cells
36 report_wrapper_cells -Verbose
37
38 # Find edt_instance
39 set edt_instance [get_instances -of_icl_instances \

Tessent™ Shell User’s Manual 231

Tessent Shell Workflows
Verifying the ICL Model
40 [get_icl_instances -filter
tessent_instrument_type==mentor::edt]]
41
42 # Specify different modes (internal and external) of the chains
that need
43 # to be stitched
44 # The type internal/external and enable_dft_signal are inferred
from the
45 # registered DFT signals(int_mode and ext_mode)
46 add_scan_mode int_mode -edt_instances $edt_instance
47 add_scan_mode ext_mode -chain_count 2
48
49 # Before scan insertion you can analyze the different scan modes
and scan # chains
50 analyze_scan_chains
51 report_scan_chains
52 //delete_scan_modes -all
53 # Insert scan chains and write the scan inserted design into the
TSDB
54 insert_test_logic
55 report_scan_chains
56 report_scan_cells > scan_cells.list
57
58 exit

Verifying the ICL Model

The ICL-based verification step verifies the ICL network before the pattern generation step.
During this verification, the tool checks the ICL network against semantic rules to verify the connectivity of
the network. The tool verifies that it can access each IJTAG test data register through iWrite and iRead.
The checks includes MemoryBIST logic if it is present in the design.
During scan chain stitching with Tessent Scan, the tool automatically updates the ICL model when
complex ports generate loops, which causes ports and instances names to change through synthesis.
When using a third-party scan insertion tool, additional ICL module matching rules may be required to
complete the ICL-based verification step.
The following procedure and example dofile show how to verify the ICL model for SSN.

Procedure
1. Set the context to patterns to create ICL-based patterns.

2. Set the location of the tsdb_outdir directory and load the cell libraries.

3. Read the third-party scan-inserted netlist.

4. Load the collateral from the last DFT insertion step before scan insertion without reading the
netlist.

5. Create and write the ICL-based pattern sets. This includes ICLNetwork verify patterns and
MemoryBIST patterns, if memories are present.

6. Define the path to the Verilog simulation libraries, simulate the patterns, and check the simulation
results.

232 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Performing ATPG Pattern Generation: Wrapped Core

Examples
This example dofile shows how to verify the ICL model for SSN.

# Set context to patterns

set_context patterns
# Open the previous TSDB directories if not in the current
# working directory
set_tsdb_output_directory ../tsdb_outdir
# Read Tessent Library
read_cell_library \
../../../library/standard_cells/tessent/NangateOpenCellLibrary.tcelllib
read_verilog \
../../../library/memories/SYNC_1RW_8Kx16.v ‑interface_only
# Read the design files from the scan insertion pass
read_design processor_core -design_identifier gate -verbose
set_current_design processor_core
# Generate patterns to verify the inserted DFT logic
set spec [create_patterns_specification]
report_config_data $spec
process_patterns_specification
# Point to the libraries and run the simulation
set_simulation_library_sources \
-v ../../../library/standard_cells/verilog/NangateOpenCellLibrary.v \
-v ../../../library/memories/*.v
run_testbench_simulations
check_testbench_simulations -report_status
exit

Performing ATPG Pattern Generation: Wrapped Core

Generating ATPG patterns for a wrapped core includes a step for generating a graybox model. In
addition, you must perform ATPG twice, once for the core’s external mode and once for the core’s internal
mode.
Refer to Performing ATPG Pattern Generation for flat designs for a general description.

Tessent™ Shell User’s Manual 233

Tessent Shell Workflows
Performing ATPG Pattern Generation: Wrapped Core

Figure 40. ATPG Pattern Generation Flow for Wrapped Cores

As described in Hierarchical DFT Terminology, the graybox model excludes the internal mode logic of the
wrapped core, preserving only the external mode logic that needs to be tested at the parent level. The
IJTAG infrastructure is preserved in the graybox model also. Specifically, Tessent preserves the external
logic that is present between the primary input and the input wrapper cells, plus any logic between the
output wrapper cells and primary output. The parent could be another wrapper core or the top level of the
chip.
You can use external mode patterns, if generated, for calculating fault coverage for the entire core (both
internal and external mode). Use the internal mode ATPG patterns for ATPG pattern retargeting when
performing the RTL and scan DFT insertion process on the top level of the chip.

Procedure
1. Generate graybox models (refer to Example 5 on page 236 for a command flow example):

a. Load in the design using the same design ID as you used for scan insertion to write the
graybox to the TSDB.
(Recommended) Use "gate" as the design ID if you inserted the MemoryBIST and EDT logic at
the RTL level and "gate3" if the logic was also inserted into the gate level.

b. Specify the analyze_graybox command to generate graybox models.

When working at the parent level, using the same design ID for the graybox model as you used
for scan insertion enables Tessent to access the full design view or the graybox model with the
same design ID.

2. Run ATPG on the external mode of the wrapped core. This ATPG pattern is only used to calculate
the entire core's fault coverage and cannot be reused from the chip-level. To generate ATPG
patterns for external mode, do the following:

a. Read in the graybox model of the design with the read_design command.
Use the set_current_mode command to specify a unique ATPG mode name that represents
the purpose of the pattern. The mode type is external.

b. Use the import_scan_mode command to retrieve the core’s external mode data. Tessent uses
the graybox model of the core. Using the import_scan_mode command assumes that you used
Tessent Scan to perform scan chain stitching.

c. Run design rule checking (DRC) using the following command:

234 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Performing ATPG Pattern Generation: Wrapped Core

check_design_rules

d. Generate the ATPG patterns using the following command:

create_patterns

e. Use the write_tsdb_data command to store the TCD, flat model, fault list and PatDB files in the
TSDB.

f. Use the write_patterns command to write out the testbench required to simulate the generated
ATPG patterns.
Refer to Example 6 on page 236.

3. Run ATPG on the internal mode of the wrapped core. This results in the ATPG pattern that you
retarget at the top level of the chip. To generate ATPG patterns for internal mode, do the following:

a. Load in the graybox views for the wrapper cores that contain child wrapper cores.

b. If you used Tessent Scan for scan insertion, specify import_scan_mode to import the internal
mode.

c. Specify a unique ATPG mode name with the set_current_mode command.

The current mode type is internal. Typical mode names are scan_mode_name_sa or
scan_mode_name_tdf.

d. Run design rule checking (DRC) using the following command:

check_design_rules

e. Generate the ATPG patters using the following command:

create_patterns

f. Store the TCD, flat model, fault list and PatDB files in the TSDB using the write_tsdb_data
command.

g. Use the read_faults command to merge the fault list from running external mode to find the
total overall fault coverage of the wrapped core.
Refer to Example 7 on page 237.

4. Run Verilog simulation of the core-level ATPG patterns.

Performing this task ensures that the patterns function as needed when they are retargeted at
the parent level. For parallel load patterns as specified by the -parallel command, simulate all the
patterns. For serial load patterns, a handful of patterns are sufficient; the run time for simulating
gate-level serial load patterns is significant.

Examples

Generate the Graybox Model

The following example creates a graybox model for a scan-inserted processor_core design and saves the
data under the "gate" design ID.

Tessent™ Shell User’s Manual 235

Tessent Shell Workflows
Performing ATPG Pattern Generation: Wrapped Core

Example 5. Graybox Example

set_context patterns –scan –design_id gate

set_tsdb_output_directory ../tsdb_core
read_cell_library \

../../../library/standard_cells/tessent/NangateOpenCellLibrary.tcelllib

## Reads in the scan inserted netlist/design

read_design processor_core -design_id gate -verbose
set_current_design processor_core
add_black_boxes -modules { \
SYNC_1RW_8Kx16 \
}
report_dft_signals

import_scan_mode ext_mode
check_design_rules
analyze_graybox
write_design -tsdb -graybox -verbose

exit

Run ATPG on the Core’s External Mode

The following example shows the command flow for running ATPG on the external mode of a core.

Example 6. ATPG External Mode

set_context patterns -scan

set_tsdb_output_directory ../tsdb_core
read_cell_library \

../../../library/standard_cells/tessent/NangateOpenCellLibrary.tcelllib

# Read in the graybox model using the -view switch

read_design processor_core -design_id gate -view graybox -verbose
set_current_design processor_core

# Specify a different name that what was used during scan insertion with
# the add_scan_mode command
set_current_mode edt_multi_SAF -type external
report_dft_signals
# Extract the external mode specified during scan insertion
import_scan_mode ext_mode
report_core_instances
report_static_dft_signal_settings

# Run DRC, Tessent Shell prompts changes to Analysis

check_design_rules
report_clocks
set_xclock_handling x

236 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Performing ATPG Pattern Generation: Wrapped Core
# Generate ATPG patterns
create_patterns
# Store TCD, flat_model, fault list, and PatDB files in the TSDB
write_tsdb_data -replace
write_patterns patterns/processor_core_ext_stuck_parallel.v -verilog \
-parallel -replace
set_pattern_filtering -sample_per_type 2
write_patterns patterns/processor_core_ext_stuck_serial.v \
-verilog -serial -replace
exit

Run ATPG on the Core’s Internal Mode

The following example shows the command flow for running ATPG on the internal mode of a core.

Example 7. ATPG Internal Mode

set_context patterns -scan

set_tsdb_output_directory ../tsdb_core
read_cell_library \

../../../library/standard_cells/tessent/NangateOpenCellLibrary.tcelllib
# Read in the full scan-inserted netlist
read_design processor_core -design_id gate
set_current_design processor_core
# Extract the internal mode specified during scan insertion
import_scan_mode int_mode
# Use add_scan_mode to specify a different name than what was used
during
# scan insertion
# Specify import_scan_mode before set_current_mode because
# import_scan_mode overrides the test mode type specified by
# set_current_mode
set_current_mode int_mode_sa -type internal

report_dft_signals
report_core_instances
report_static_dft_signal_settings

# Run DRC
check_design_rules
report_clocks
report_core_instances
add_fault -all
report_statistics -detail
# Generate ATPG patterns
create_patterns
report_statistics -detail
# Store TCD, flat_model, fault list, and PatDB files in the TSDB
write_tsdb_data -replace
write_patterns patterns/processor_core_stuck_parallel.v -verilog \
-parallel -replace
set_pattern_filtering -sample_per_type 2

Tessent™ Shell User’s Manual 237

Tessent Shell Workflows
Running Recommended Validation Step for Pre-Layout Design Sign Off
write_patterns patterns/processor_core_stuck_serial.v \
-verilog -serial -replace
exit
# To view the coverage of the faults testable by internal mode, you must
# eliminate the undetected faults, which would be detected in
# external mode. Do this by merging in the fault list generated from
# performing ATPG on the graybox in external mode
read_faults -mode ext_multi_SAF –fault_type stuck -merge

# Final coverage of the core that includes internal and external modes
report_statistics -detail
exit

Running Recommended Validation Step for Pre-Layout

Design Sign Off
During the first pass of the hierarchical DFT insertion flow for a wrapped core, you insert and simulate
the MemoryBIST hardware, mostly at the RTL level. To ensure that the MemoryBIST simulation passes
before the core is signed off as the pre-layout netlist, rerun MemoryBIST simulation at gate level on the
core’s scan-inserted netlist.

Procedure
1. Read in the scan-inserted netlist from the TSDB.
Using the recommended naming conventions for the RTL and scan DFT insertion flow, the design
ID would be "gate" if you inserted the MemoryBIST and EDT logic at the RTL level and "gate3" if
the logic was also inserted into the gate level.

2. Elaborate the design and run DRC.

3. Create the input test patterns and simulation files.

4. Simulate the testbench.

Tessent Shell stores the generated testbench in the TSDB under the Patterns directory using the
design ID "gate".

Examples
The following example shows how to validate the MemoryBIST patterns for a scan-inserted netlist.

set_context patterns –ijtag –design_id gate

set_tsdb_output_directory ../tsdb_core

##Reading the tessent cell library

read_cell_library \
../../../library/standard_cells/tessent/NangateOpenCellLibrary.tcelllib

## Reading the scan inserted netlist

read_design processor_core -design_id gate -verbose -view interface
set_current_design processor_core
add_black_boxes -modules { \
SYNC_1RW_8Kx16 \

238 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Running Recommended Validation Step for Pre-Layout Design Sign Off
}
check_design_rules
create_patterns_specification
process_patterns_specification
set_simulation_library_sources \
-v ../../../library/standard_cells/verilog/NangateOpenCellLibrary.v \
-v ../../../library/memories/SYNC_1RW_8Kx16.v.v
run_testbench_simulation
exit

Tessent™ Shell User’s Manual 239

Tessent Shell Workflows
RTL and Scan DFT Insertion Flow for the Top Chip

RTL and Scan DFT Insertion Flow for the Top Chip
After performing the RTL and scan DFT insertion flow for each wrapped core in your design, you can
perform the DFT insertion process for the top-level chip design.
Before implementing DFT at the top level of the chip, plan how you should test the wrapped cores at
the chip level. The planning for logic testing the wrapped cores is not automated, so you must decide
how you want to allocate the resources and organize the test schedule (especially for ATPG pattern
retargeting) and specify your intent by using the add_dft_modal_connections command.
The RTL and scan DFT insertion flow for the top level of a chip follows the same basic process you used
for the cores, with the addition of a step for retargeting the ATPG patterns you generated for the wrapped
cores.

Figure 41. Two-Pass Insertion Flow for RTL, Top Level

In addition, processing at the chip level differs from wrapped cores in that you must insert a Test Access
Mechanism (TAM). A TAM is a mechanism that you use to carry the scan data in and out of the chip for
each group of wrapped cores you intend to run in parallel. The TAM schedules the tests for the wrapped
cores at the top level, and enables access to the chip level so that you can run these tests.
During insertion and pattern generation, you open the TSDBs that store the wrapped core design data
and read in the designs for their graybox models. The DFT insertion flow for the top level of the chip
requires differentiating between three design views of the wrapped cores.

240 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Top-Level DFT Insertion Example

• Full netlist view — All the logic for the core. This is the default view when you do not explicitly
specify a design view with the read_design command.

• Graybox model — External mode logic for the core as described in Hierarchical DFT
Terminology, including its IJTAG interface. You use this view so that Tessent Shell can connect
the wrapped cores at the top level for logic testing of the chip.

• Interface view — The core’s ports only. Tessent auto-loads the interface view of any sub-
physical block for which you have not used read_design to load its view.

Top-Level DFT Insertion Example

First DFT Insertion Pass: Performing Top-Level MemoryBIST and Boundary Scan
Second DFT Insertion Pass: Inserting Top-Level EDT and OCC
Top-Level Scan Chain Insertion Example
Top-Level ATPG Pattern Generation Example
Performing Top-Level ATPG Pattern Retargeting

Top-Level DFT Insertion Example

The RTL and scan DFT insertion flow for the top level of a chip can be illustrated using two wrapped
cores, processor_core and gps_baseband. The processor core has memory instantiated within it, and the
GPS baseband is a logic-only core that is instantiated twice.

Figure 42. Top-Level Example, Before DFT Insertion

After performing the RTL and scan DFT insertion process for the wrapped cores, each of the cores has
an EDT controller and a child OCC. The processor core has the memories with MemoryBIST already
inserted.

Tessent™ Shell User’s Manual 241

Tessent Shell Workflows
Top-Level DFT Insertion Example

Figure 43. Top-Level Example, After DFT Insertion for Wrapped Cores

After inserting DFT at the top level, the design includes a TAP controller along with boundary scan, a top-
level EDT controller, a parent OCC, and a TAM for purposes of retargeting the wrapped cores (not shown
in Figure 44 on page 242).
In this top-level example test case, the hierarchical core starts with RTL insertion, and in addition, at
the top level you want to perform DFT at RTL as well. However, there is no RTL logic at the top level
that needs to be synthesized. The PLL and pad IOs are Verilog macros. The only RTL that needs to be
synthesized is the Tessent-generated RTL. Hence, this test case uses design IDs "gate1" and "gate2" for
the first two DFT insertion passes, respectively.

Figure 44. Top-Level Example, After DFT Insertion at the Top Level

242 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
First DFT Insertion Pass: Performing Top-Level MemoryBIST and Boundary Scan

First DFT Insertion Pass: Performing Top-Level

MemoryBIST and Boundary Scan
For the top level of a chip, insert boundary scan plus MemoryBIST for any memories that are present at
the top level. In addition, build the IJTAG network for the wrapped cores at the top level and insert a TAP
controller or reuse an existing TAP controller.
As with flat designs, the flow for inserting MemoryBIST and boundary scan together is the same as
inserting them separately. For details about this insertion pass flow, refer to:

• "Getting Started" in the Tessent MemoryBIST User’s Manual, or

• "Getting Started With Tessent BoundaryScan" in the Tessent BoundaryScan User’s Manual
For information about TAP controller reuse, refer to create_dft_specification in the Tessent Shell
Reference Manual.

Prerequisites
• Refer to First DFT Insertion Pass: Performing MemoryBIST and Boundary Scan (for flat designs)
for general information and prerequisites. For example, as with flat designs, you can segment
the boundary scan chain into smaller chains that are used during logic testing with Tessent
TestKompress by using the max_segment_length_for_logictest command.

Procedure
1. Load the design.

Note:
Use the open_tsdb command to open the TSDBs for all the lower-level cores. Opening
their TSDBs makes their design data available.
There is no need to specify the read_design command because, by default, Tessent reads
in the interface views of the wrapped cores, which is all that is required for DRC for the first
DFT insertion pass.

2. Set the design level to "chip" for the top level of the chip.
When working with the wrapped cores, you had set the design level to "physical_block."

3. Create the DFT specification.

Note:
Boundary scan patterns can test functional I/Os, but you can also reuse functional I/Os for
the scan_en, test_clock, and edt_update DFT signals if they have the necessary auxiliary
logic. For more information, refer to the AuxiliaryInputOutputPorts wrapper in the Tessent
Shell Reference Manual.

4. Specify enough auxiliary input and output ports for the largest retargeting wrapper core group.

5. Generate the hardware and extract the ICL.

Tessent™ Shell User’s Manual 243

Tessent Shell Workflows
First DFT Insertion Pass: Performing Top-Level MemoryBIST and Boundary Scan

6. Create the input test patterns and simulation testbenches.

7. Run simulations to verify the design.

Examples
The following dofile example shows a typical command flow for inserting MemoryBIST and boundary
scan. The flow is the same as you would use for a flat design with the exception of the commands
highlighted in bold. The chip-level design data exists in its own TSDB. This is recommended for the data
flow as described in TSDB Data Flow for the Tessent Shell Flow.

set_context dft -rtl -design_id rtl1

set_tsdb_output_directory ../tsdb_outdir

# Open the TSDB of all the wrapped cores

open_tsdb ../../wrapped_cores/processor_core/tsdb_outdir
open_tsdb ../../wrapped_cores/gps_baseband/tsdb_outdir

# Read the Tessent cell library

read_cell_library \
../../library/standard_cells/tessent/NangateOpenCellLibrary.tcelllib
read_cell_library ../../library/pad_cells/tessent/Nangate_pads.tcelllib

# Read hard macros

read_verilog ../../library/plls/pll.v -blackbox \
‑exclude_from_file_dictionary

# Read the design

set_design_sources -format verilog \
-y ../../library/pad_cells/verilog -extension v
read_verilog ../rtl/chip_top.v
read_verilog ../rtl/rds_process.v
set_current_design chip_top
set_design_level chip

# Specify and verify the DFT requirements

set_dft_specification_requirements -boundary_scan on -memory_bist on

# Identify the TAP pins

set_attribute_value TCK -name function -value tck
set_attribute_value TDI -name function -value tdi
set_attribute_value TMS -name function -value tms
set_attribute_value TRST -name function -value trst
set_attribute_value TDO -name function -value tdo

# Some pins cannot add any boundary scan cells

set_boundary_scan_port_options TEST_CLOCK_top -cell_options dont_touch
set_boundary_scan_port_options EDT_UPDATE_top -cell_options dont_touch
set_boundary_scan_port_options SCAN_ENABLE -cell_options dont_touch
set_boundary_scan_port_options RESET_N -cell_options dont_touch
set_boundary_scan_port_options INCLK -cell_options dont_touch

# Add DFT signals

add_dft_signals scan_en -source_nodes SCAN_ENABLE

244 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Second DFT Insertion Pass: Inserting Top-Level EDT and OCC
report_dft_signals
add_clocks PLL_1/pll_clock_0 -reference REF_CLK -FREQ_Multiplier 16
add_clock REF_CLK -period 48
check_design_rules

# Create a dft specification

set spec [create_dft_specification]
report_config_data $spec
# Segment the boundary scan to be used during logic test
set_config_value $spec/BoundaryScan/max_segment_length_for_logictest 80

# Equip these ports with auxiliary input/output muxes to be used by EDT

# channel pins
read_config_data -in ${spec}/BoundaryScan -from_string {
AuxiliaryInputOutputPorts {
auxiliary_input_ports : GPIO1_0, GPIO1_1, GPIO1_2, GPIO1_3;
auxiliary_output_ports : GPIO2_0, GPIO2_1, GPIO2_2, GPIO2_3, GPIO1_0,
GPIO1_1 ;
}
}

report_config_data $spec
process_dft_specification
extract_icl
create_patterns_specification
process_patterns_specification
set_simulation_library_sources \
-v ../../library/standard_cells/verilog/*.v \
-v ../../library/pad_cells/verilog/*.v \
-y ../../library/plls \
-y ../../library/memories \
-extension v
run_testbench_simulations
exit

Second DFT Insertion Pass: Inserting Top-Level EDT and

OCC
For the top level of a chip, additional considerations for the second DFT insertion pass for EDT and
OCC include grayboxes, DFT signals for purposes of ATPG retargeting, and TAMs. EDT, or Embedded
Deterministic Test, reduces scan data volume and test time.

Note:
This procedure follows a similar flow as flat designs as documented in “First DFT Insertion Pass:
Performing MemoryBIST and Boundary Scan” on page 193.

Tessent™ Shell User’s Manual 245

Tessent Shell Workflows
Second DFT Insertion Pass: Inserting Top-Level EDT and OCC

Procedure
1. Specify the open_tsdb command to open the TSDBs for the wrapped cores, as in the first DFT
insertion pass for the chip.

2. Specify the read_design command to read in the graybox models of the wrapped cores.
This enables Tessent to perform DRC on the wrapper chains in addition to the rest of the top-level
logic to be tested.

3. Define a retargeting mode for each group of wrapped cores whose ATPG patterns you want to
retarget to run in parallel.
For ATPG pattern retargeting purposes, Tessent requires you to include retargeting mode DFT
signals in addition to the DFT signals defined in section DFT Signals. The retargeting<X>_mode
signals along with the TAM specified with the add_dft_modal_connections command ensure that
ATPG pattern retargeting occurs correctly. Optionally, you can register your own DFT signals to be
used for retargeting purposes.
Example 8 on page 246 demonstrates retargeting of two wrapped cores: processor_core and
gps_baseband.

4. Apply the add_dft_modal_connections command to specify the TAM.

During the first insertion pass, you identified the functional pins to be shared with EDT channel pins
and added the required auxiliary input and auxiliary output logic. Now you use the TAM to sensitize
paths to and from the top-level EDT using the set_config_value command.
In Example 8 on page 246, the functional input pin GPI01_0 is shared as an EDT channel input
pin. Similarly, the functional output pin GPI02_0 is shared as an EDT channel output pin.

5. Combine with the top-level EDT mode signal you defined by connecting the EDT channel IOs of
the wrapped cores to top-level pins via the TAM. Use the add_dft_modal_connections command.

6. Apply the set_defaults_value command to specify that Tessent Shell simulate the instruments
within the wrapped cores in addition to the top-level instruments.

Examples
The following dofile example shows that the DFT insertion flow for inserting EDT and OCC into the top
level of a chip follows the same basic process as for flat designs as described in Second DFT Insertion
Pass: EDT, Hybrid TK/LBIST, and OCC, with the exception of the highlighted commands.

Example 8. Top-Level Second DFT Pass

set_context dft ‑rtl -design_id rtl2

set_tsdb_output_directory ../tsdb_outdir
open_tsdb ../../wrapped_cores/processor_core/tsdb_outdir
open_tsdb ../../wrapped_cores/gps_baseband/tsdb_outdir

# Read the tessent cell library

read_cell_library \
../../library/standard_cells/tessent/NangateOpenCellLibrary.tcelllib
read_cell_library ../../library/pad_cells/tessent/Nangate_pads.tcelllib

# Read the hard macros

read_verilog ../../library/plls/pll.v -blackbox \

246 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Second DFT Insertion Pass: Inserting Top-Level EDT and OCC
‑exclude_from_file_dictionary

# Read the verilog

set_design_sources -format verilog -y ../../library/pad_cells/verilog \
‑extension v
read_design chip_top -design_id rtl1 -verbose
read_design processor_core -design_id gate -view graybox -verbose
read_design gps_baseband -design_id gate -view graybox -verbose
set_current_design chip_top

# Add DFT Signals

# When using boundary scan in logic test without contacting inputs
add_dft_signals int_ltest_en output_pad_disable -create_with_tdr

# Needed for Scan Tested Instruments such as MemoryBIST and boundary scan
add_dft_signals tck_occ_en -create_with_tdr

# When you are using logic test

add_dft_signals ltest_en -create_with_tdr

# Used by top-level EDT

add_dft_signals edt_mode -create_with_tdr

# These are used for the top-level EDT

add_dft_signals test_clock edt_update \
-source_nodes {TEST_CLOCK_top EDT_UPDATE_top}
add_dft_signals shift_capture_clock edt_clock -create_from_other_signals

# Retargeting mode signals used for ATPG pattern retargeting

add_dft_signals retargeting1_mode retargeting2_mode retargeting3_mode \
retargeting4_mode

# Add TAM connections

# For chip-level EDT mode, the asterisk(*) means do not make connection to
the data inputs
add_dft_modal_connections -ports GPIO1_0 -input_data_destination_nodes * \
-enable_dft_signal edt_mode
add_dft_modal_connections -ports GPIO2_0 -output_data_source_nodes * \
-enable_dft_signal edt_mode

# Connect wrapped core EDT channel I/Os to top level for retargeting1_mode
signal
add_dft_modal_connections -ports GPIO1_2 -input_data_destination_nodes
PROCESSOR_1/processor_core_rtl2_controller_c1_edt_channels_in[0] \
-enable_dft_signal retargeting1_mode
add_dft_modal_connections -ports GPIO2_2 -output_data_source_nodes
PROCESSOR_1/processor_core_rtl2_controller_c1_edt_channels_out[0] \
-enable_dft_signal retargeting1_mode

# Connect wrapped core EDT channel I/Os to top level for retargeting2_mode
signal
add_dft_modal_connections -ports GPIO1_2 -input_data_destination_nodes
GPS_1/gps_baseband_rtl1_controller_c1_edt_channels_in[0] \
-enable_dft_signal retargeting2_mode

Tessent™ Shell User’s Manual 247

Tessent Shell Workflows
Second DFT Insertion Pass: Inserting Top-Level EDT and OCC
add_dft_modal_connections -ports GPIO1_2 -input_data_destination_nodes
GPS_2/gps_baseband_rtl1_controller_c1_edt_channels_in[0] \
-enable_dft_signal retargeting2_mode
...
add_dft_modal_connections -ports GPIO1_0 -output_data_source_nodes GPS_1/
gps_baseband_rtl1_controller_c1_edt_channels_out[0] \
-enable_dft_signal retargeting2_mode -pipeline_stages 1
add_dft_modal_connections -ports GPIO1_1 -output_data_source_nodes
GPS_1/gps_baseband_rtl1_controller_c1_edt_channels_out[1] \
-enable_dft_signal retargeting2_mode -pipeline_stages 1
...

report_dft_modal_connections
set_dft_specification_requirements -logic_test On
add_clocks INCLK -period 10ns
check_design_rules
report_dft_control_points

# Create DFT specification

set spec [create_dft_specification -sri_sib_list {occ edt} ]
report_config_data $spec
read_config_data -in $spec -from_string {
OCC {
ijtag_host_interface : Sib(occ);
}
}
set id_clk_list [list \
pll_clock_0 PLL_1/pll_clock_0 \
INCLK INCLK \
]
foreach {id clk} $id_clk_list {
set occ [add_config_element OCC/Controller($id) -in $spec]
set_config_value clock_intercept_node -in $occ $clk
}
report_config_data $spec
read_config_data -in $spec -from_string {
EDT {
ijtag_host_interface : Sib(edt);
...
}

set_config_value port_pin_name \
-in $spec/EDT/Controller(c1)/Connections/EdtChannelsIn(1) \
[get_single_name [get_auxiliary_pins GPIO1_0 -direction input]]
set_config_value port_pin_name \
-in $spec/EDT/Controller(c1)/Connections/EdtChannelsOut(1)
[get_single_name [get_auxiliary_pins GPIO2_0 -direction output] ]
report_config_data $spec
process_dft_specification
extract_icl

# By setting this value, all the lower level instruments in the wrapped
# cores are simulated

248 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Top-Level Scan Chain Insertion Example
set_defaults_value /PatternsSpecification/SignoffOptions/
simulate_instruments_in_lower_physical_instances on
create_patterns_specification
process_patterns_specification
set_simulation_library_sources \
-v ../../library/standard_cells/verilog/*.v \
-v ../../library/pad_cells/verilog/*.v \
-y ../../library/plls \
-y ../../library/memories \
-extension v
...
run_testbench_simulations
exit

Top-Level Scan Chain Insertion Example

For the top level of the chip, additional considerations for scan chain insertion include opening the TSDBs
for the wrapped cores and reading in the wrapped core graybox models as you did for the second DFT
insertion pass.

Note:
Prior to scan chain insertion, perform synthesis as described in section Performing Synthesis.

Logic that is present at the top-level needs to be scan stitched along with the wrapper chains (external
mode) of the cores.
Refer to Performing Scan Chain Insertion (Flat Design) (for flat designs) for more information about scan
chain insertion. The following dofile example shows that Tessent Shell needs to access the graybox
models for each wrapped core.

Example 9. Top-Level Scan Chain Insertion

set_context dft -scan -design_id gate

set_tsdb_output_directory ../tsdb_outdir
open_tsdb ../../wrapped_cores/processor_core/tsdb_core
open_tsdb ../../wrapped_cores/gps_baseband/tsdb_core
# Read the tessent cell library
read_cell_library \
../../library/standard_cells/tessent/NangateOpenCellLibrary.tcelllib
read_cell_library ../../library/memories/SYNC_1RW_8Kx16.atpglib
read_cell_library ../../library/pad_cells/tessent/Nangate_pads.tcelllib
# Read the hard macros
read_verilog ../../library/plls/pll.v -blackbox
# Read the verilog
read_verilog ../3.synthesize_rtl/chip_top_synthesized.vg
read_design chip_top -design_id rtl2 -no_hdl ‑verbose
read_design processor_core -design_id gate -view graybox -verbose
read_design gps_baseband -design_id gate -view graybox -verbose
set_current_design chip_top
check_design_rules
report_clocks
set edt_instance [get_name_list [get_instance -of_module \

Tessent™ Shell User’s Manual 249

Tessent Shell Workflows
Top-Level ATPG Pattern Generation Example
[get_name [get_icl_module -of_instances chip_top* \
-filter tessent_instrument_type==mentor::edt]]] ]
add_scan_mode edt_mode -edt_instance $edt_instance
analyze_scan_chains
report_scan_chains
insert_test_logic
exit

Top-Level ATPG Pattern Generation Example

At the top level, Tessent Shell uses the scan-inserted design data for the chip. In the recommended flow
this equates to design ID "gate." In addition, Tessent uses the graybox models for the wrapped cores so
that you can use the external mode of the wrapper chains to run ATPG.
Refer to Performing ATPG Pattern Generation (for flat designs) for information about generating the
ATPG patterns. The flow for the top level of a chip builds onto the process by adding in the grayboxes and
blackboxes. As with flat designs, you have a choice between using the boundary scan chains for capture
or using the primary pins of the chips (using the pads).
The following dofile example generates ATPG patterns at the top level using the stuck-at fault model. The
dofile shows that you can read in the stuck-at fault models for the wrapped cores to calculate the total
fault coverage for the chip.

Example 10. Top-Level ATPG Pattern Generation

set_context pattern -scan

set_tsdb_output_directory ../tsdb_top
open_tsdb ../../wrapped_cores/processor_core/tsdb_core
open_tsdb ../../wrapped_cores/gps_baseband/tsdb_core
read_cell_library \
../../library/standard_cells/tessent/NangateOpenCellLibrary.tcelllib
read_cell_library ../../library/memories/ \
SYNC_1RW_8Kx16.atpglib
read_cell_library ../../library/pad_cells/tessent/Nangate_pads.tcelllib

# Read the hard macros

read_verilog ../../library/plls/pll.v -blackbox \
‑exclude_from_file_dictionary
read_design chip_top -design_id gate
read_design processor_core -design_id gate -view graybox -verbose
read_design gps_baseband -design_id gate -view graybox -verbose
set_current_design chip_top
set_current_mode edt_top_stuck
import_scan_mode edt_mode
report_core_instances
set_static_dft_signal_values tck_occ_en 1
report_static_dft_signal_settings
set_system_mode analysis
add_fault –all
report_statistics -detail
create_patterns
report_statistics -detail
write_tsdb_data -replace
# Create manufacturing patterns

250 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Performing Top-Level ATPG Pattern Retargeting
write_patterns patterns/chip_top_edt_stuck.stil -stil -replace
# Create parallel simulation patterns
write_patterns patterns/chip_top_edt_parallel.v -verilog -parallel \
-replace -pattern_sets scan
# Create a sampled set of patterns for simulation
set_pattern_filtering -sample_per_type 2
write_patterns patterns/chip_top_edt_serial.v -verilog -serial -replace
# Total fault coverage for stuck-at patterns at the chip level including
# the cores
read_faults -module processor_core –mode edt_int_stuck \
–fault_type stuck –merge -graybox
read_faults –module gps_baseband –mode edt_int_stuck \
–fault_type stuck –merge -graybox
report_statistics –detail
exit

Performing Top-Level ATPG Pattern Retargeting

For each wrapped core, retarget the internal ATPG patterns for all the modes you have specified and all
the fault types.

Note:
This procedure is similar to “Performing ATPG Pattern Generation: Wrapped Core” on page 233.

Procedure
1. Specify the set_context patterns ‑retargeting command to retarget the ATPG patterns generated
for the wrapped cores.

2. Use the same TSDB for ATPG retargeting as you used for ATPG pattern generation.

3. Set the current mode to a unique mode name that, ideally, indicates the core name, the fault type,
and the retargeting mode DFT signal you had previously defined.

4. Specify which wrapped core ATPG patterns you are retargeting by enabling the correct retargeting
mode DFT signal. Set the set_static_dft_signal_values command to the retargeting mode for this
wrapped core.

5. Apply the add_core_instances command to specify the wrapped core whose internal ATPG
patterns you want to retarget.

Note:
If you are using this procedure for the automotive flow, also apply the "add_clocks -period"
command to add the top-level free-running repair clock.

6. Apply the read_patterns command to read in the stuck-at ATPG patterns that you want to retarget.

Examples
The following dofile example shows how you would retarget the stuck-at ATPG patterns for the wrapped
core, processor_core.

Tessent™ Shell User’s Manual 251

Tessent Shell Workflows
Performing Top-Level ATPG Pattern Retargeting

Example 11. Retarget Stuck-At ATPG Patterns for the Top-Level

set_context pattern -scan_retargeting

set_tsdb_output_directory ../tsdb_top
open_tsdb ../../wrapped_cores/processor_core/tsdb_core
open_tsdb ../../wrapped_cores/gps_baseband/tsdb_core

# Read the tessent cell library

read_cell_library \
../../library/standard_cells/tessent/NangateOpenCellLibrary.tcelllib
read_cell_library ../../library/memories/SYNC_1RW_8Kx16.atpglib
read_cell_library ../../library/pad_cells/tessent/Nangate_pads.tcelllib
# Read the hard macros
read_verilog ../../library/plls/pll.v -blackbox \
-exclude_from_file_dictionary
read_design chip_top -design_id gate
read_design processor_core -design_id gate -view graybox -verbose
read_design gps_baseband -design_id gate -view graybox ‑verbose
set_current_design chip_top
# Retarget processor_core stuck-at patterns
set_current_mode retarget1_processor_stuck
set_static_dft_signal_values retargeting1_mode 1
add_core_instances -instances {PROCESSOR_1} -core processor_core \
-mode edt_int_stuck
report_core_descriptions
report_clocks

set_system_mode analysis
write_tsdb_data -replace

# Read the patterns to be retargeted

read_patterns -module processor_core -fault_type stuck -mode edt_int_stuck
set_external_capture_options -pll_cycles 5 [lindex [get_timeplate_list] 0]
write_patterns patterns/processor_core_edt_stuck_retargeted.v -verilog \
-parallel -replace -begin 0 -end 7 -pattern_sets scan
write_patterns patterns/processor_core_edt_stuck_retargeted_serial.v \
-verilog -serial -replace -Begin 0 -End 2

# Write out the STIL file to use on the tester

write_patterns patterns/processor_core_edt_stuck_retargeted.stil \
-stil -replace
exit

The following dofile snippet shows how you would retarget at-speed transition ATPG patterns for the
wrapped core, gps_baseband. Commands that are not shown are the same as the commands for
processor core in Example 11 on page 252.

252 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Performing Top-Level ATPG Pattern Retargeting

Example 12. Retarget At-Speed Transition ATPG Patterns for the Top-Level

# Set the context and open TSDBs ...

# Read in cell libraries, PLL, macro IO pads, designs ...
# Set the current design ...
# Retarget gps_baseband transition patterns
set_current_mode retarget2_gps_transition
set_static_dft_signal_values retargeting2_mode 1
add_core_instances -instances {GPS_1 GPS_2} -core gps_baseband \
-mode edt_int_transition
report_core_descriptions
import_clocks -verbose
report_clocks
set_system_mode analysis
write_tsdb_data -replace
# Read the patterns to be retargeted
read_patterns -module gps_baseband -mode edt_int_transition \
-fault_type transition
set_external_capture_options -pll_cycles 5 [lindex[get_timeplate_list]
0]
write_patterns patterns/gps_edt_transition_retargeted.v -verilog \
-parallel -replace -begin 0 -end 7 -pattern_sets scan
write_patterns patterns/gps_edt_transition_retargeted_serial.v \
-verilog -serial -replace -Begin 0 -End 2

# Write out the STIL file to use on the tester

write_patterns patterns/gps_edt_transition_retargeted.stil -stil
-replace

exit

Tessent™ Shell User’s Manual 253

Tessent Shell Workflows
RTL and Scan DFT Insertion Flow for Sub-Blocks

RTL and Scan DFT Insertion Flow for Sub-Blocks

When performing the DFT insertion flow with sub-blocks, you insert MemoryBIST and pre-DFT DRCs at
the sub-block level and then move up to the sub-block’s next parent physical block level (where the sub-
block is instantiated) to perform synthesis and scan insertion.
Refer to Hierarchical DFT Terminology for more information about sub-blocks.
You may want to use the sub-block flow for any of the following reasons.

• Multiple instantiations — You only need to perform the DFT insertion flow once for a sub-block.
Thereafter, every instantiation of the sub-block includes the inserted DFT hardware.

• Small size — Most sub-blocks are not big enough to be considered their own physical regions.

• Readiness — Sometimes the sub-block RTL is complete before the RTL for the physical layout
region, thus you can begin DFT insertion on the sub-block as soon as RTL is ready.

DFT Insertion Flow for the Sub-Block

DFT Insertion Flow for the Next Parent Level

DFT Insertion Flow for the Sub-Block

The DFT insertion flow for sub-blocks is similar to the insertion flow for physical blocks with a few
exceptions.

• You do not perform synthesis or scan insertion at the sub-block level because the sub-block
netlist may not exist after synthesis.

• During the second DFT insertion pass, you only insert pre-DFT DRCs.
Typically, you do not insert EDT controllers at the sub-block level because the logic inside of the
sub-block is too small, and the sub-block module may not exist after synthesis. You can insert an
EDT controller at the next parent level that you dedicate to testing the logic inside of a sub-block.
In most cases, this EDT controller is active at the same time as other EDT controllers that are
present at the next parent level.

Note:
The sub-block flow for inserting MemoryBIST and pre-DFT DRCs follows the same steps
as described in RTL and Scan DFT Insertion Flow for Physical Blocks, with the exception of
generating the EDT and OCC hardware. There are slight variations, which are described in the
following procedure.

Procedure
1. First DFT Insertion Pass: Performing MemoryBIST and Boundary Scan. Ensure that you set the
design level to sub_block rather than physical_block.

set_design_level sub_block

254 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
DFT Insertion Flow for the Next Parent Level

2. Second DFT insertion pass: insert pre-DFT DRCs. Follow the steps for the Second DFT Insertion
Pass: Inserting Block-Level EDT and OCC procedure, excluding generating the EDT and OCC
hardware.
Because you specified that you were working at the sub_block level in the first DFT insertion pass,
you do not need to re-specify this information for the second insertion pass.
After specifying and verifying the DFT requirements, Tessent Shell performs the following tasks
automatically:

• At the sub-block level, any static DFT signals you have added are implemented as IJTAG ports
rather than inserted via TDRs. Tessent Shell automatically connects the IJTAG ports to the TDR
at the next parent level.

• At the next parent level, adds DFT signals such as ltest_en and
async_set_reset_static_disable. Tessent Shell infers the add_dft_control_point command on
the sub-block pins if you have DFT DRCs that need to be fixed.

• At the next parent level, adds the tck_occ_en DFT signal if there is a STI-SIB network inside the
sub-block.
The following command performs pre-DFT DRC:

set_dft_specification_requirements -logic_test on

During ICL extraction, Tessent Shell generates the Synopsys Design Constraints (SDC) for the
sub-block.

Results
Proceed to performing the DFT insertion flow on the next parent level where this sub-block is instantiated.

DFT Insertion Flow for the Next Parent Level

The next parent level in the bottom-up flow where a sub-block is instantiated may either be a physical
layout block that is a wrapped core, or the physical layout region that is the chip (the top level). By moving
the focus of DFT insertion from child block to immediate parent block, you maintain the correctness and
consistency of the test hardware. The following procedure describes the flow when you have a sub-block
instantiated at the chip level.

Prerequisites
• You have performed the DFT insertion flow as described in DFT Insertion Flow for the Sub-Block
for the sub-blocks instantiated at this parent level so that you have the design after a clean pre-
DFT DRC run.

Note:
This flow occurs after the DFT insertion process described in RTL and Scan DFT Insertion Flow
for the Top Chip. When you have a sub-block inserted inside a wrapped core, you complete the
procedures described in “RTL and Scan DFT Insertion Flow for Physical Blocks” on page 221
after you load the sub-block design.

Tessent™ Shell User’s Manual 255

Tessent Shell Workflows
DFT Insertion Flow for the Next Parent Level

Procedure
1. First DFT Insertion Pass: Performing Top-Level MemoryBIST and Boundary Scan. When you load
the design, open the sub-block’s TSDB and load the design of the sub-block that passed pre-DFT
DRCs.

2. Second DFT Insertion Pass: Inserting Top-Level EDT and OCC. When you load the design, open
the sub-block’s TSDB, load the full design for the sub-block, and load the design for the top-level
after the first DFT insertion pass.

3. Synthesis on page 209. Synthesis of the chip-level RTL and the sub-block’s post-DFT inserted RTL
occur at the same time. Tessent Shell merges the sub-block into the parent-level logic.
Refer to Timing Constraints (SDC) to learn how the synthesis constraints from the sub-block are
merged at the next parent level.

4. Scan Chain Insertion on page 249. Tessent Shell performs scan chain insertion on the sub-block
and parent-level logic at the same time.

5. ATPG Pattern Generation on page 250.

Examples

Design Loading for the First DFT Insertion Pass

The following example shows opening the TSDB for the sub-block and using read_design to read in the
sub-block (processor_core) design.

# Set the context to insert DFT into RTL-level design

set_context dft -rtl -design_id rtl1
# Set the location of the TSDB. Default is the current working directory.
set_tsdb_output_directory ../tsdb_top
# Open the TSDBs for all the instantiated sub-blocks
open_tsdb ../../sub_block/tsdb_outdir
# Read the tessent cell library
read_cell_library \
../../library/standard_cells/tessent/NangateOpenCellLibrary.tcelllib
read_cell_library ../../library/pad_cells/tessent/Nangate_pads.tcelllib

# Read the hard macros

read_verilog ../../library/plls/pll.v -blackbox \
‑exclude_from_file_dictionary
# Read the design
read_verilog ../../rtl/chip_top.v
# Explicitly load the sub-block netlist
read_design processor_core -design_id rtl2 -verbose
set_current_design chip_top
set_design_level chip
# Follow the rest of the flow for the first DFT insertion pass for a chip.

256 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
DFT Insertion Flow for the Next Parent Level

Design Loading for the Second DFT Insertion Pass

# Set the context to insert DFT. Define a new design ID
set_context dft -rtl -design_id rtl2
# Set the location of the TSDB. Default is the current working directory.
set_tsdb_output_directory ../tsdb_top
# Open the TSDBs for all the instantiated sub-blocks
open_tsdb ../../sub_block/tsdb_outdir
# Read the tessent cell library
read_cell_library \
../../library/standard_cells/tessent/NangateOpenCellLibrary.tcelllib
read_cell_library ../../library/pad_cells/tessent/Nangate_pads.tcelllib
# Read the hard macros
read_verilog ../../library/plls/pll.v -blackbox
‑exclude_from_file_dictionary
set_design_sources -format verilog -y ../../library/pad_cells/verilog \
‑extension v
read_design chip_top -design_id rtl1 -verbose
# Explicitly load the sub-block netlist
read_design processor_core -design_id rtl2 -verbose
set_current_design chip_top
# Follow the rest of the flow for the second DFT insertion pass for a chip

Tessent™ Shell User’s Manual 257

Tessent Shell Workflows
RTL and Scan DFT Insertion Flow for Instrument Blocks

RTL and Scan DFT Insertion Flow for Instrument

Blocks
When performing the DFT insertion flow with instrument blocks, create a special empty module to insert
DFT elements into, then move up to the instrument block’s next parent physical block level to perform
synthesis and scan insertion.
Use the instrument block flow to avoid having Tessent Shell modify your golden RTL.

DFT Insertion Flow for the Instrument Block

Instrument Block DFT Insertion Flow for the Next Parent Level

DFT Insertion Flow for the Instrument Block

Create a special empty module into which the DFT elements are inserted.

Procedure
1. Start with an empty DFT module that contains the port definitions for IJTAG and an input
and output port for each functional clock. Optionally, create output ports for the all_test and
async_set_reset_dynamic_disable DFT signals, which you can use to control clock multiplexers
and disable your asynchronous set and reset signals during scan shifting.

The following RTL shows an example module definition required for the instrument block flow:

module elt1_dft_box (
input clk,
output clk_occ,
input ijtag_tck,
input ijtag_reset,
input ijtag_ce,
input ijtag_se,
input ijtag_ue,
input ijtag_sel,
input ijtag_si,
output ijtag_so,
input [1:0] edt_channels_in,
output edt_channels_out,
input scan_en,
input test_clock,
input edt_update,
output async_set_reset_dynamic_disable
);

// Drive the DFT signal to its off value

assign async_set_reset_dynamic_disable = 1'b0;

// Add feedthroughs for ijtag chain

258 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
DFT Insertion Flow for the Instrument Block
assign ijtag_so = ijtag_si;
// Add feedthrough for func clock that will be equipped with OCC
assign clk_occ = clk;
endmodule

2. Perform the DFT insertion flow within the DFT module as normal, but you must add DFT control
points to output ports corresponding to DFT signals.

read_verilog design/rtl/elt1_dft_box.v
set_current_design elt1_dft_box
set_design_level instrument_block

set_dft_specification_requirements -logic_test on
add_dft_signals ltest_en int_mode int_ltest_en ext_mode ext_ltest_en
add_dft_signals scan_en test_clock edt_update \
-source_node {scan_en test_clock edt_update}
add_dft_signals edt_clock shift_capture_clock \
‑create_from_other_signals
add_dft_signals x_bounding_en mcp_bounding_en \
observe_test_point_en control_test_point_en -create_with_tdr
add_dft_signals async_set_reset_static_disable
add_dft_signals async_set_reset_dynamic_disable \
‑create_from_other_signals
add_dft_signals capture_per_cycle_static_en –create_with_tdr

#Add DFT control points

add_dft_control_points async_set_reset_dynamic_disable \
-type dynamic_dft_control \
-dft_signal_source_name async_set_reset_dynamic_disable

add_clocks clk -period [expr {1000.0/300.0}]

check_design_rules

set spec [create_dft_specification -sri_sib_list {edt lbist occ}]

set_config_value use_rtl_cells off -in_wrapper $spec

read_config_data -in_wrapper $spec -from_string {

Edt { // {{{
ijtag_host_interface : Sib(edt);
Controller(c1) {
...
Connections {
EdtChannelsIn(1:2) {
port_pin_name : edt_channels_in;
}
EdtChannelsOut(1) {
port_pin_name : edt_channels_out;
}
}
}
} // }}}
LogicBist { // {{{

Tessent™ Shell User’s Manual 259

Tessent Shell Workflows
Instrument Block DFT Insertion Flow for the Next Parent Level
ijtag_host_interface : Sib(lbist);
Controller(lbist_1) {
...
Connections {
shift_clock_src : clk;
}
}
NcpIndexDecoder {
...
}
} // }}}
OCC { // {{{
ijtag_host_interface : Sib(occ);
static_clock_control : external;
Controller(clk_controller) {
clock_intercept_node : clk;
}
} // }}}
}

process_dft_specification
set_system_mode setup
extract_icl
write_design_import_script ‑replace ‑use_relative_path_to [pwd]

Results
Proceed to performing the DFT insertion flow on the next parent level where this instrument block is
instantiated.

Instrument Block DFT Insertion Flow for the Next Parent

Level
The next parent level in the bottom-up flow where an instrument block is instantiated may either be a
physical layout block that is a wrapped core, or the physical layout region that is the chip (the top level).
By moving the focus of DFT insertion from child block to immediate parent block, you maintain the
correctness and consistency of the test hardware. The following procedure describes the flow when you
have an instrument block instantiated at the physical_block level.

Prerequisites
• You have performed the DFT insertion flow as described in DFT Insertion Flow for the Instrument
Block for the instrument blocks instantiated at this parent level so that you have the design after a
clean pre-DFT DRC run.

260 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Instrument Block DFT Insertion Flow for the Next Parent Level

Procedure
1. Instantiate and connect the special empty DFT module in your parent module. Modify your RTL to
use clk_occ wherever it used clk so that the clock of all your scannable elements is controlled by
the OCC inserted into the block.

Tip
Remember to manually connect in the parent module all the connections for the IJTAG
network and all dynamic DFT signals.

2. At the next level, read your design normally, and then load the DFT module using the read_design
command. Specify your clocks and run the check_design_rules command to validate and store
them. Then, call the extract_icl command.

At that point, it is as if you had inserted the DFT elements from this level using the normal flow.
After ICL is extracted, you can go to the DFT context and verify that the RTL has a controllable
clock and reset signals. DRC violation errors indicate if the RTL is not clean, which you must fix
manually.

read_design elt1_dft_box -design_id dft

read_verilog design/rtl/elt1.v
set_current_design elt1
set_design_level physical_block
add_clocks CLK1 -period [expr {1000.0/300.0}]
check_design_rules
extract_icl
report_dft_signals
write_design_import_script -replace -use_relative_path_to [pwd]

#Check that it passes the pre-DFT DRC rules

set_context dft
set_dft_specification_requirements -logic_test on
set_drc_handling dft_c9 -auto_fix off
check_design_rules

# Generate patterns
set spec [create_pattern_specification]
process_pattern_specification

# Run Simulation
set_simulation_library_sources -v \
../../../library/standard_cells/verilog/NangateOpenCellLibrary.v
run_testbench_simulations

3. Synthesis on page 209. Synthesis of the chip-level RTL and the instrument_block’s post-DFT
inserted RTL occur at the same time. Tessent Shell merges the instrument_block into the parent-
level logic.
Refer to Timing Constraints (SDC) to learn how the synthesis constraints from the
instrument_block are merged at the next parent level.

Tessent™ Shell User’s Manual 261

Tessent Shell Workflows
Instrument Block DFT Insertion Flow for the Next Parent Level

4. Scan Chain Insertion on page 249. Tessent Shell performs scan chain insertion on the
instrument_block and parent-level logic at the same time.

5. ATPG Pattern Generation on page 250.

262 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
RTL and DFT Insertion Flow With Third-Party Scan

RTL and DFT Insertion Flow With Third-Party Scan

The RTL and DFT insertion flow enables you to use a third-party scan insertion tool instead of Tessent
Scan. Regardless of which scan insertion tool you use, you must follow a number of sequences in the
DFT insertion flow that include creating the logic for internal and external mode, and the multiplexing
mechanism that Tessent Scan normally inserts in order to support hierarchical ATPG.
The workflow uses the standard hierarchical DFT insertion flow, both for each wrapped core and, once
you have inserted DFT in each wrapped core, for top chip.
Refer to “Hierarchical DFT Terminology” on page 217.

Note:
If your design consists of wrapped cores as your lower level physical blocks, and the wrapped
cores do not contain embedded pad IOs, refer to “How to Use Boundary Scan in a Wrapped
Core” on page 712.

CAUTION:
Third-party tools may have different insertion capabilities compared to Tessent Scan. This may
affect the quality of the results you achieve.

DFT Insertion Flow With Third-Party Scan Insertion

Wrapped Core DFT Insertion With Third-Party Scan
Top Chip DFT Insertion With Third-Party Scan

DFT Insertion Flow With Third-Party Scan Insertion

The DFT insertion flow with third-party scan insertion requires you to manually collect and provide certain
data during hierarchical ATPG. Normally when using Tessent Scan for scan insertion and stitching, the
information that is needed for performing hierarchical ATPG is transferred.

Prerequisites
Before starting this flow, you should identify the DFT functions you need to insert in each core and identify
how many scan chains and wrapper cells are needed for each core.

Note:
Tessent Scan automatically concatenates scan chain and wrapper chains into mixed chains to
achieve the number of scan channels on the EDT logic.

CTL (IEEE 1450.6) Generation for Tessent IP With Embedded Scan

Segments
Certain Tessent Shell IP blocks include embedded scan segments that must be a part of scan chains. To
simplify integration with third-party scan insertion tools, Tessent Shell generates the CTL (IEEE 1450.6)
file whenever generating the tcd_scan file for test IP.

Tessent™ Shell User’s Manual 263

Tessent Shell Workflows
DFT Insertion Flow With Third-Party Scan Insertion

The tool generates a CTL file that includes information about embedded scan segments for the following
applications:

• A CTL file to describe the embedded chain to help in connecting the programmable registers
inside the following IP:

◦ OCC

◦ STI SIB or Sib(STI)

• A CTL file to describe the controller chain mode (CCM) scan segment, when the tool generates
test IP with enabled segment_per_instrument property. This applies to the following IP:

◦ LogicBIST controller

◦ EDT controller (available only when used as part of hybrid TK/LBIST IP)

◦ Single Chain Mode Logic controller (part of hybrid TK/LBIST IP)

◦ In-system test controller

For information about CCM, refer to "Controller Chain Mode" in the Hybrid TK/LBIST User’s Manual. For
information about CTL files, refer to "Default Generation of CTL Files" in the Tessent Shell Reference
Manual.

264 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Wrapped Core DFT Insertion With Third-Party Scan

Wrapped Core DFT Insertion With Third-Party Scan

For each wrapped core, perform a two-pass pre-scan DFT insertion process as you would for a flat
design except that in the first DFT insertion pass, do not insert boundary scan unless you have embedded
pad IO macros present inside the core. The flow details are unique to working with wrapped cores and
using a third-party scan insertion tool to insert the scan.
Refer to “RTL and Scan DFT Insertion Flow for Physical Blocks” on page 221 for overall details.

Note:
This discussion assumes your design consists of wrapped cores as your lower level physical
blocks, and the wrapped cores do not contain embedded pad IOs.

Figure 45. Two-Pass Insertion Flow for RTL, Wrapped Cores, and Third-Party Scan

Perform Two-Pass DFT Insertion and Synthesis for Wrapped Cores

Third-Party Scan Insertion for Wrapped Cores
Writing the Design Back to the TSDB
Make Pre-ATPG Connections With Third-Party Scan for Wrapped Cores
Performing Wrapped Core Graybox Generation and ATPG Pattern Generation

Tessent™ Shell User’s Manual 265

Tessent Shell Workflows
Perform Two-Pass DFT Insertion and Synthesis for Wrapped Cores

Perform Two-Pass DFT Insertion and Synthesis for Wrapped

Cores
This flow for wrapped cores is the same as the DFT insertion flow for physical blocks except you insert
the scan with a third-party scan tool instead of Tessent Scan.

Procedure
1. First DFT Insertion Pass: Performing MemoryBIST and Boundary Scan. Ensure you set the design
level to physical_block.

set_design_level physical_block

2. Second DFT Insertion Pass: Inserting Block-Level EDT and OCC. Ensure you set the design level
to physical_block.

a. During the second insertion pass and when specifying the DFT signals, follow the procedure
defined in “Specifying and Verifying the DFT Requirements: DFT Signals for Wrapped Cores”
on page 227.
The following are the internal and external modes that are required for mode switching:

add_dft_signals int_ltest_en ext_ltest_en int_mode ext_mode \

-create_with_tdr

add_dft_signals input_wrapper_scan_en output_wrapper_scan_en \

-create_from_other_signals

b. Creating the DFT Specification.

The test case implements compressed ATPG test using Tessent TestKompress. You define the
EDT logic for Tessent TestKompress and the Tessent OCC in an EDT DftSpecification wrapper
as follows:

read_config_data -in $spec -from_string "

OCC {
ijtag_host_interface : Sib(occ);
type : standard;
}
EDT {
ijtag_host_interface : Sib(edt);
Controller (c1) {
longest_chain_range : 50, 65;
scan_chain_count : 80;
input_channel_count : 2;
output_channel_count : 1;
Connections {
EdtChannelsIn(2:1) {
port_pin_name : edt_channel_in[1:0];
}
EdtChannelsOut(1:1) {
port_pin_name : edt_channel_out[0:0];

266 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Third-Party Scan Insertion for Wrapped Cores
}
}
}
}"

You define the scan_chain_count as follows:

scan_chain_count = number of internal only scan chains + number of wrapper chains
This number covers all chains that the EDT logic at the current level needs to connect to. In
other words the EDT hardware need to be connected to both the internal only chains and
wrapper chains.

3. Generating the EDT, Hybrid TK/LBIST, and OCC Hardware.

4. Extracting the ICL Module Description.

5. Generating ICL Patterns and Running Simulation.

6. Performing Synthesis.

Third-Party Scan Insertion for Wrapped Cores

You can use a third-party scan insertion tool to insert scan and perform scan stitching for wrapped cores
in your design. The actual process depends on the third-party scan insertion tool you use. You must wrap
all the inputs and outputs of hierarchical physical blocks and perform scan insertion and stitching in your
design. Your choice of wrapper cells depends on the capabilities of the third-party scan tool you are using.
For hierarchical ATPG, you must insert multiplexers before each wrapper chain to multiplex the primary
input from the top level and the current level of the EDT scan input. Figure 46 shows an abstract level
depiction of the multiplexing logic. The inclusion of these multiplexers is mandatory for hierarchical ATPG
support using Tessent tools.

Figure 46. DFT Signals and Multiplexer Logic Support Hierarchical ATPG

To the child cores, the preregistered static DFT signals ext_mode and int_mode control these multiplexers
as follows:

Tessent™ Shell User’s Manual 267

Tessent Shell Workflows
Third-Party Scan Insertion for Wrapped Cores

• External Mode — The ext_mode DFT signal is active, and the int_mode DFT signal is inactive.
The top level drives input into the wrapper chains through the wrapper’s scan in on the core
boundary.

• Internal Mode — The ext_mode DFT signal is inactive and the int_mode DFT signal is active.
The EDT logic drives all the scan chains inside the hierarchical physical block (both internal only
and wrapper chains).
When using this configuration, you must control the corresponding TDR bits for mode switching. Refer
to “Performing Wrapped Core Graybox Generation and ATPG Pattern Generation” on page 276 for a
detailed explanation.

Usage Guidelines
Use the following guidelines and criterion for configuring your third-party scan insertion tool for wrapper
and scan stitching:

• For the hierarchical physical block on which you intend to perform scan insertion, you have
completed the “Perform Two-Pass DFT Insertion and Synthesis for Wrapped Cores” on
page 266 flow.

• You have identified the scan chains of the current core and how many of the scan chains should
be wrapper chains. The total number of scan chains is the same as the EDT scan_chain_count,
as defined in the previous DFT insertion step. The rest of the scan chains can be specified and
used as core chains.

• During wrapper analysis, you must exclude the following pins from any wrapper insertion:

◦ IJTAG-related pins

◦ edt_channel_input pins

◦ edt_channel_output pins

◦ scan_enable pins

◦ Any clock pins

• The DFT signals for input and output wrapper scan enable that you have defined during the
second DFT insertion pass should be used as scan enable signals for input and output wrapper
chains, respectively, during wrapper analysis and insertion.

• To run ATPG after scan insertion, you must create and supply a test procedure file for the
Graybox generation step to trace and control the wrapper chains. A test procedure file tells the
tool how to clock the scan chains, and the tool automatically passes this to ATPG in the Tessent
Shell flow. A graybox does not normally include an OCC and EDT logic for tracing and controlling
wrapper chains; consequently, you must create the test procedure file manually when using the
third-party scan insertion flow.
Refer to “Test Procedure File” on page 745 for complete details on how you create and use a
test procedure file. Also, refer to “Example Test Procedure File” on page 271.

268 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Third-Party Scan Insertion for Wrapped Cores

• The Tessent Shell environment get_dft_info_dictionary command offers you a method to access
the Tessent Database (TSDB) to use this information with your third-party scan insertion tool.
The command reads the scan information from the TSDB’s dft_inserted_designs directory,
specifically in a Tcl dictionary file named:
<design_name>.dft_info_dictionary
The Tcl dictionary contains the information about the DFT inserted in the design that must be
considered during scan insertion when using a third-party scan insertion tool. Refer to “Example
dft_info_dictionary File” on page 272.
All instances under "non_scannable_instance_list" should be regarded as non-scan. All modules
under "modules_with_chains" should be considered as sub-chains and should not be modified
during scan insertion.

• The Tessent Shell environment provides a mechanism for generating an example Tcl script you
can customize for your third-party scan insertion tool. Perform the following steps:

a. In Tessent Shell, run the following commands in the dft or pattern context:
set_tsdb_output_directory ../tsdb_outdir
read_design <design_name>
puts [ get_dft_info_dictionary -example_usage_script ]> ./usage_template.tcl

The tool creates an example usage script as shown in the following excerpt:

…
puts "Declare the Non-Scannable instances"

set non_scannable_instance_list [dict get $tessent_dft_info_dict

non_scannable_instance_list]
if {[llength $non_scannable_instance_list] > 0} {
### Command to declare the Non-Scannable instances
add_nonscan_instances [get_instances
$non_scannable_instance_list]
}
…

b. Use the script as a starting point to convert the dictionary into specific commands for your
third-party scan insertion tool. In the script, the tool inserts pound signs (#) with comments
that specify the actions your third-party tool must perform. You must replace those comments
with the corresponding third-party tool-specific commands to the file.

c. In the third-party scan insertion tool, source the Tessent dictionary from
../tsdb_outdir/dft_inserted_designs/
design_name_last_DFT_insertion_design_id.dft_inserted_design/
design_name.dft_info_dictionary.
An example path and filename is ../tsdb_outdir/dft_inserted_designs/
gps_baseband_rtl_edt.dft_inserted_design/gps_baseband.dft_info_dictionary.

d. In the third-party scan insertion tool, source the example usage script you modified in
previous steps.

Tessent™ Shell User’s Manual 269

Tessent Shell Workflows
Writing the Design Back to the TSDB

• For the hierarchical transition fault model, you may need to insert one additional at-speed cell
at the beginning of each wrapper chain to make the transition on the first cell of each wrapper
chain. This way, you achieve the best coverage. The method you use depends on the third-party
insertion tool. Figure 47 shows the logic.

Figure 47. At-Speed Flows in the Wrapper Chain

• If required and after you have inserted the scan using your third-party tool, you can follow the
procedure described in “Make Pre-ATPG Connections With Third-Party Scan for Wrapped Cores”
on page 273 if required.

• If no pre-ATPG connections are required, then you can load the scan-inserted netlist into Tessent
Shell and write the modified netlist and scan information back to the Tessent Shell Database
(TSDB).

Writing the Design Back to the TSDB

After completing scan insertion by your third-party scan insertion tool, you must write the scan-
inserted netlist back to the TSDB to associate the netlist with Tessent DFT instruments. You create this
association by creating a softlink to the scan inserted netlist in TSDB, which also creates the Tessent
Core Description files and the ICL information.

Prerequisites
• You have completed scan insertion with a third-party tool.
Use the following procedure to save a scan-inserted netlist to the TSDB. The line numbers are
represented in the Example dofile under Examples:

Procedure
1. Set the context (refer to lines 1-3).

2. Set the TSDB location if not already set (refer to line 6).

3. Load the cell library (refer to line 9).

4. Load the scan-inserted netlist (refer to line 12). This netlist is modified by your third-party scan
insertion tool and contains the scan cells.

270 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Writing the Design Back to the TSDB

5. Load the supporting DFT files (except the netlist) from the last DFT insertion pass and set the
current design (refer to lines 15-17).

6. Set the design level. Make sure you specify "physical_block" (refer to line 21).

7. Write the design information to the TSDB and create the softlink (refer to line 22).

Examples

Example dofile
1 # Use the design_id as "scan." Use this in all the ATPG
2 # runs that this design is read in.
3 set_context patterns -ijtag -design_id <scan>
4
5 # Set the location of the TSDB. Default is the current working
directory
6 set_tsdb_output_directory ../tsdb_outdir
7
8 # Read the Tessent Cell Library
9 read_cell_library \
10
../../library/standard_cells/tessent/NangateOpenCellLibrary.tcelllib
11
12 # Read the scan inserted netlist and elaborate the design
13 read_verilog ../3.synthesize_rtl/<current_core>_scan.vg
14
15 # Read the -no_hdl from the last DFT insertion pass
16 read_design <current_core> -design_id <rtl2> -no_hdl -verbose
17 read_verilog ../../../library/memories/SYNC_1RW_8Kx16.v
18 set_current_design <current_core>
19
20 # Specify the design level before writing out a softlink of the
design in
21 # TSDB
22 set_design_level physical_block
23 write_design -tsdb -softlink_netlist -verbose
24 exit

Example Test Procedure File

set time scale 1.000000 ns ;
timeplate gen_tp1 =
force_pi 0 ;
measure_po 10 ;
pulse_clock 20 10 ;
pulse clock2 20 10;
period 40 ;
end;
procedure shift =
scan_group grp1 ;

Tessent™ Shell User’s Manual 271

Tessent Shell Workflows
Writing the Design Back to the TSDB
timeplate gen_tp1 ;
// cycle 0 starts at time 0
cycle =
force_sci ;
measure_sco ;
pulse clock1;
pulse clock2;
end;
end;

procedure load_unload =
scan_group grp1 ;
timeplate gen_tp1 ;
// cycle 0 starts at time 0
cycle =
force clock1 0;
force clock2 0;
force scan_enable 1 ;
end ;
apply shift 76;
end;

Example dft_info_dictionary File

set tessent_dft_info_dict {
version 1
dft_signals {
dft_signal_name {
connection_node_name node_name
connection_node_type port|pin
forced_value_in_pre_scan_drc 0|1
}
}
modules_with_chains {
module_name {
pre_scan_drc_on_boundary_only 0|1
module_type normal|memory|occ
is_hard_module 0|1
internal_scan_only 0|1
allow_scan_out_retiming 0|1
instance_list {inst_name ...}
scan_en_ports|ltest_en_ports|set_reset_ports {
port_name { active_polarity 0|1
}
}
clock_ports {
port_name {
off_state 0|1
}
}
clock_out_ports_or_pins {
port_or_pin_name {}

272 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Make Pre-ATPG Connections With Third-Party Scan for Wrapped Cores
}
scan_chains {
scan_chain_name {
length auto|int
scan_in_port port_name
scan_in_clock_name port_name
scan_in_clock_inversion 0|1
scan_out_port port_name
scan_out_clock_name port_name
scan_out_clock_inversion 0|1
}
}
}
}
non_scannable_instance_list {inst_name ...}
edt_instances {
instance_name {
edt_module_name module_name
scan_chains {
chain_name {
scan_in_port port_name
scan_out_port port_name
}
}
}
}
}

Make Pre-ATPG Connections With Third-Party Scan for Wrapped

Cores
You perform this step only if the wrapped core has at least one child wrapped core or there is one upper
layer beyond the current module.
Otherwise, skip this step in the flow and proceed directly to “Performing Wrapped Core Graybox
Generation and ATPG Pattern Generation” on page 276.
This step includes two parts:

Tessent™ Shell User’s Manual 273

Tessent Shell Workflows
Make Pre-ATPG Connections With Third-Party Scan for Wrapped Cores

1. It creates connections from the current level EDT logic to the wrapped child cores' wrapper
chains for the paths depicted in red in Figure 48.

Figure 48. Current Level Path to Child Core Wrapper Chains

The external mode logic and chains of child cores become part of the current test coverage.

2. It also creates logic from the current level wrapper chain to the upper-level logic, marked in green
in Figure 48. Logic added at this stage includes the muxes controlled by dft_signals, ports at the
module boundary, and connections between those ports and the EDT logic. This enables the
external mode testing of the wrapped child core from the upper level.

Note:
The line numbers used in this procedure refer to the command flow dofile in “Example Dofile for
Pre-ATPG Connections for Wrapped Cores” on page 275.

Prerequisites
• You must have performed the two-pass DFT insertion as described in “Perform Two-Pass DFT
Insertion and Synthesis for Wrapped Cores” on page 266.

• You must have inserted scan using your third-party scan insertion tool per the guidelines provided
in “Third-Party Scan Insertion for Wrapped Cores” on page 267.

Procedure
1. Load the design. (Refer to lines 1-8.)

2. Change to insertion mode. (Refer to line 10.)

3. Make the red connections shown in Figure 48 on page 274. (Refer to lines 13-27.)

4. Make the ports, logic, and connections shown in green in Figure 48. (Refer to lines 29-44.)

5. Save the design. (Refer to line 46.)

6. Write the design back to the TSDB. (Refer to lines 47-72.)

274 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Make Pre-ATPG Connections With Third-Party Scan for Wrapped Cores

Examples

Example Dofile for Pre-ATPG Connections for Wrapped Cores

1 set_context dft -no_rtl
2
3 read_verilog ../3.synthesis/<current_design_name>_scan.vg
4
5 # Read the tessent cell library
6 read_cell_library \
7
../../library/standard_cells/tessent/NangateOpenCellLibrary.tcelllib
8
9 set_current_design <current_design_name>
10
11 set_system_mode insertion
12
13
14 # Make the connections marked in red in the preceding figure (refer
to Step 1)
15
16 # empty pins of edt logic were grounded, need to delete before
connection
17 delete_connection <current_edt_instance>/edt_scan_out[]
18
19
20 delete_connection <current_edt_instance>/edt_scan_in[]
21
22
23 # connect edt scan-in/scan-out to ext_wsi/ext_wso of every chain
24 create_connection /<child_core_instance>/ext_wsi[] \
25 <current_edt_instance>/edt_scan_in[]
26
27 create_connection /<child_core_instance>/ext_wso[] \
28 <current_edt_instance>/edt_scan_out[]
29
30 # Make the ports, logic, and connection marked in green in the
preceding figure (refer to Step 2)
31 delete_connection <current_edt_instance>/edt_scan_in[]
32 # create ports for upper level to connect to
33 create_port ext_wsi[]
34 create_port ext_wso[] –direction output
35 # create mux logic and control logic
36 create_instance wrapper_mux0 –of_module mux21
37 create_instance ext_mode_inv –of_module inv01
38 create_instance mode_and –of_module and02
39 create_connection <current_tdr_instance>/ext_mode ext_mode_inv/A
40 create_connection <current_tdr_instance>/int_mode mode_and/A0
41 # connect mux between ports and wrapper chain beginning/ends
42 create_connection wrapper_mux0/A1 <edt_instance>/edt_scan_in[]
43 create_connection wrapper_mux0/A0 ext_wsi[]

Tessent™ Shell User’s Manual 275

Tessent Shell Workflows
Performing Wrapped Core Graybox Generation and ATPG Pattern Generation
44 create_connection wrapper_mux0/Y <wrapper chain beginning cell or
buffer before it>/A
45 create_connection ext_wso[] <wrapper chain ending cell or buffer
after it>/Q
46
47 write_design -output_file ../3.synthesis/<current_design_name>.vg
48
49 # Use the design_id as "scan." Use this in all the ATPG
50 # runs that this design is read in.
51
52 set_context patterns -ijtag -design_id <scan>
53
54 # Set the location of the TSDB. Default is the current working
directory
55 set_tsdb_output_directory ../tsdb_outdir
56
57 # Read the Tessent Cell Library
58 read_cell_library \
59
../../library/standard_cells/tessent/NangateOpenCellLibrary.tcelllib
60
61 # Read the scan inserted netlist and elaborate the design
62 read_verilog ../3.synthesize_rtl/<current_core>_scan.vg
63
64 # Read the -no_hdl from the last DFT insertion pass
65
66 read_design <current_core> -design_id <rtl2> -no_hdl -verbose
67
68 read_verilog ../../../library/memories/SYNC_1RW_8Kx16.v
69
70 set_current_design <current_core>
71
72 # Specify the design level before writing out a softlink of the
design in
73 # TSDB
74 set_design_level physical_block
75 write_design -tsdb -softlink_netlist -verbose
76 exit

Performing Wrapped Core Graybox Generation and ATPG Pattern

Generation
This step in the flow creates the graybox model of the current wrapped core and generates ATPG
patterns. You must perform this step for each wrapped core in your design.

Prerequisites
• You must have completed the “Performing Wrapped Core Graybox Generation and ATPG Pattern
Generation” on page 276 step for each wrapped core.

• You must have inserted scan with your third-party scan insertion tool per the guidelines cited
in “Third-Party Scan Insertion for Wrapped Cores” on page 267 for each wrapped core, and

276 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Performing Wrapped Core Graybox Generation and ATPG Pattern Generation
written the scan-inserted netlist back into the Tessent Shell Database as described in “Writing the
Design Back to the TSDB” on page 270.

• If required, make ATPG connections using the process outlined in “Make Pre-ATPG Connections
With Third-Party Scan for Wrapped Cores” on page 273 for each wrapped core.

Procedure
1. Generate the graybox model for the wrapped core and add a scan group of wrapper chains
by importing the test procedure file you created during Third-Party Scan Insertion for Wrapped
Cores—refer to “Example Graybox Generation” on page 277 and “Performing ATPG Pattern
Generation: Wrapped Core” on page 233.
To generate external patterns to check fault coverage for the wrapped core, refer to “Example
External ATPG Pattern Generation” on page 278. You do not retarget these patterns.
As long as the scan mode (scan chains and test logic) is stitched conforming to DRC, Tessent
Shell generates internal ATPG patterns formed in the correct way.

2. Save the design and write the patterns to the TSDB using the write_tsdb_data command.

write_tsdb_data -replace

3. Repeat Steps 1 and 2 for each wrapped core to generate transition patterns.

All of the information is passed by the Tessent Shell through the TSDB.

Results
When you complete graybox and ATPG for each wrapped core, perform scan insertion for the top chip.
Refer to “Top Chip DFT Insertion With Third-Party Scan” on page 280 for complete flow details.

Examples

Example Graybox Generation

set_context pattern -scan -design_id <scan>
set_tsdb_output_directory ../tsdb_outdir
# Read the tessent cell library
read_cell_library \
../../../library/standard_cells/tessent/NangateOpenCellLibrary.tcelllib
read_design <current_design_name> -design_id <scan>
set_current_design <current_design_name>
# set memory modules black box
add_black_box -module SYNC_1RW_32x16_RC_BISR
add_black_box -module SYNC_1RW_32x4
add_clock 0 clock1
# Graybox generation requires core configured to external mode by
# setting DFT signal values:
set_static_dft_signal_values int_mode 0
set_static_dft_signal_values ext_mode 1
set_static_dft_signal_values int_ltest_en 0
set_static_dft_signal_values ext_ltest_en 1
# exclude edt_channels for graybox
set_attribute_value [get_ports *edt_channel*] \

Tessent™ Shell User’s Manual 277

Tessent Shell Workflows
Performing Wrapped Core Graybox Generation and ATPG Pattern Generation
-name ignore_for_graybox -value true
# import wrapper chain information by importing testproc file of
# wrapper chains
add_scan_group grp1 ../4.scan_insertion/wrapper.testproc
# add every wrapper chain from input pin to output pin
add_scan_chains chain1 grp1 ext_wsi[0] ext_wso[0]
add_scan_chains chain2 grp1 ext_wsi[1] ext_wso[1]
add_scan_chains chain3 grp1 ext_wsi[2] ext_wso[2]
set_system_mode analysis
# external mode information saved in tsdb
write_design -graybox -tsdb -verbose
exit

Example External ATPG Pattern Generation

set_context pattern -scan -design_id <scan>
set_tsdb_output_directory ../tsdb_outdir
# Read the tessent cell library
read_cell_library \
../../../library/standard_cells/tessent/NangateOpenCellLibrary.tcelllib
read_design <current_design_name>-design_id <scan> -view graybox
set_current_design <current_design_name>
add_clock 0 clock
# create mode information for external ATPG
set_current_mode ext_multi_stuck -type external
# configure core to external mode
set_static_dft_signal_values int_mode 0
set_static_dft_signal_values ext_mode 1
set_static_dft_signal_values int_ltest_en 0
set_static_dft_signal_values ext_ltest_en 1
# for transition fault ATPG, replace stuck with transition
set_fault_type stuck
# import wrapper chain information
add_scan_group grp1 ../4.scan_insertion/wrapper.testproc
add_scan_chains chain1 grp1 ext_wsi[0] ext_wso[0]
add_scan_chains chain2 grp1 ext_wsi[1] ext_wso[1]
add_scan_chains chain3 grp1 ext_wsi[2] ext_wso[2]
set_system_mode analysis
create_pattern
write_tsdb_data -replace
exit

Example Internal ATPG Pattern Generation

set_context patterns -scan -design_id <scan>
set_tsdb_output_directory ../tsdb_outdir
# Read the tessent cell library
read_cell_library \
../../../library/standard_cells/tessent/NangateOpenCellLibrary.tcelllib
read_design <current_design_name> -design_id <scan>
add_black_box -module SYNC_1RW_32x16_RC_BISR

278 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Performing Wrapped Core Graybox Generation and ATPG Pattern Generation
add_black_box -module SYNC_1RW_32x4
set_current_design <current_design_name>
# current_mode is used when add core instance at top level
set_current_mode edt_int_stuck -type internal
# import core instances of OCC, EDT and sib_sti if exist
add_core_instances -module <occ_instance_name> -parameter_values {}
add_core_instances -module <edt_instance_name>
add_core_instances -module <sib_sti_instance_name>
# for transition fault ATPG, replace stuck with transition
set_fault_type stuck
add_clock 0 clock -pulse_always
# configure core to internal mode
set_static_dft_signal_values int_mode 1
set_static_dft_signal_values ext_mode 0
set_static_dft_signal_values int_ltest_en 1
set_static_dft_signal_values ext_ltest_en 0
report_static_dft_signal_settings
set_system_mode analysis
create_pattern
write_tsdb_data -replace
exit

Tessent™ Shell User’s Manual 279

Tessent Shell Workflows
Top Chip DFT Insertion With Third-Party Scan

Top Chip DFT Insertion With Third-Party Scan

After performing the RTL and scan DFT insertion flow for each wrapped core in your design, you can
perform the DFT insertion process for the top-level chip design using a third-party scan insertion tool to
insert the scan.
Refer to “RTL and Scan DFT Insertion Flow for the Top Chip” on page 240 for overall flow details, and a
detailed description of the Test Access Mechanism (TAM).

Figure 49. Two-Pass Insertion Flow for RTL, Top Level, and Third-Party Scan

Perform Two-Pass Insertion and Synthesis for Top Chip

Third-Party Scan Insertion for Top Chip
Make Pre-ATPG Connections With Third-Party Scan for Top Chip
Perform Top-Chip ATPG Pattern Generation and Wrapped-Core Pattern Retargeting

Perform Two-Pass Insertion and Synthesis for Top Chip

After performing the RTL and scan DFT insertion flow for each wrapped core in your design, you can
perform the DFT insertion process for the top-level chip design.

280 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Third-Party Scan Insertion for Top Chip

Prerequisites
• Before you perform the top level steps, all the child cores must be ready with their retargetable
patterns. A spec form for the top level logic is also recommended to define the number of scan
chains and what DFT instruments need to be inserted.

• You must have completed the Perform Two-Pass DFT Insertion and Synthesis for Wrapped
Cores step for each wrapped core.

• You must have completed the Third-Party Scan Insertion for Wrapped Cores step for reach
wrapped core.

• If required, you must have completed the Make Pre-ATPG Connections With Third-Party Scan for
Wrapped Cores step for each wrapped core.

• You must have completed the Performing Wrapped Core Graybox Generation and ATPG Pattern
Generation for each wrapped core.

Procedure
1. Set the design level to chip for the top level of the chip and insert DFT for MemoryBIST and
Boundary Scan. Refer to “First DFT Insertion Pass: Performing MemoryBIST and Boundary Scan”
on page 193.

2. Insert top-level EDT and OCC. Refer to “Second DFT Insertion Pass: EDT, Hybrid TK/LBIST, and
OCC” on page 198.

Note:
You must correctly define the scan_chain_count of the EDT, to include all scan chain
counts of child cores in addition to the top-level scan chain count.

3. Perform synthesis. Refer to “Performing Synthesis” on page 209.

Results
You now have a design ready for top level scan insertion with your third-party scan insertion tool. Proceed
to “Third-Party Scan Insertion for Top Chip” on page 281.

Third-Party Scan Insertion for Top Chip

You can use a third-party scan insertion tool to insert scan into the top chip of your design. Your process
depends on the third-party scan insertion tool you use.

Usage Guidelines

• Top level logic does not require wrapper chains as all primary inputs and primary outputs are
controllable.

• The Tessent Shell environment get_dft_info_dictionary command offers you a method to access
the Tessent Database (TSDB) to use this information with your third-party scan insertion tool.

Tessent™ Shell User’s Manual 281

Tessent Shell Workflows
Third-Party Scan Insertion for Top Chip

The command reads the scan information from the TSDB’s dft_inserted_designs directory,
specifically in a Tcl dictionary file named <design_name>.dft_info_dictionary.
This file can be sourced to any Tcl script engine. The file contains the information about the DFT
inserted in the design that must be considered during scan insertion when using a third-party
scan insertion tool and contains the following sections:

◦ dft_signals — Contains all of the DFT signals.

◦ modules_with_chains — Contains all modules that already scanned, which means that they
should be stitched into scan chains as sub-chains.

◦ non_scannable_instance_list — Contains those instances set to non-scan during scan

insertion.

◦ edt_instances — Contains and describes the EDT modules that the scan changes connect to.

• The Tessent Shell environment provides a mechanism for generating an example usage script
you can customize to work with your third-party scan insertion tool. In the Tessent Shell tool, you
invoke the following commands:

read_verilog design_netlist
source \
../
tsdb_outdir/dft_inserted_designs/design_name.last_DFT_insertion_design
_id/design_name.dft_info_dictionary
get_dft_info_dictionary -example_usage_script

After issuing these commands, the tool creates an example usage script. Use this script as a
starting example to convert the dictionary into the specific commands used by your third-party
scan insertion tool. In the file, the tool inserts pound signs (#) with comments that specify which
actions your third-party tool must perform. For example:

puts "Processing DFT signals"

set dft_signals_dict [dict get $tessent_dft_info_dict dft_signals]
puts "Setting up Static Dft Signals"
foreach dft_signal [dict keys $dft_signals_dict] {
if {[dict exists $dft_signals_dict \
$dft_signal forced_value_in_pre_scan_drc]} {
set connection_node_name \
[dict get $dft_signals_dict $dft_signal connection_node_name]
set connection_node_type \
[dict get $dft_signals_dict $dft_signal connection_node_type]
set forced_value_in_pre_scan_drc \
[dict get $dft_signals_dict $dft_signal \
forced_value_in_pre_scan_drc]
puts "--- Static Dft Signal $dft_signal ---"
if {$connection_node_type eq "pin"} {
### Command to cut and force created pseudo port
add_primary_input [get_pins [list $connection_node_name]] \
-internal
add_input_constraints \

282 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Make Pre-ATPG Connections With Third-Party Scan for Top Chip
[get_pins [list $connection_node_name]] \
-c${forced_value_in_pre_scan_drc}
} else {
### Command tp force port
add_input_constraints \
[get_ports [list $connection_node_name]] \
-c${forced_value_in_pre_scan_drc}
}
}
}
...

• If required and after you have inserted the scan using your third-party tool, you can proceed to
“Make Pre-ATPG Connections With Third-Party Scan for Top Chip” on page 283.

• When you have completed scan insertion, the next step is to “Perform Top-Chip ATPG Pattern
Generation and Wrapped-Core Pattern Retargeting” on page 285.

Make Pre-ATPG Connections With Third-Party Scan for Top Chip

You perform this step in the flow only if the wrapped core has at least one sub-wrapped core.
If your design contains no sub-wrapped cores, skip this step in the flow and proceed directly to “Perform
Top-Chip ATPG Pattern Generation and Wrapped-Core Pattern Retargeting” on page 285.
The most important logic to support hierarchical ATPG is the connection from the top level EDT scan in
ports to the primary inputs that you created for each wrapper chain to cover external faults to all child
cores.
Figure 50 illustrates this connection at an abstract level, marked in red.

Figure 50. Top Level EDT Connection to Child Cores

Note:
The line numbers used in this procedure refer to the command flow dofile in “Example Dofile for
Pre-ATPG Connections for Top Chip” on page 284.

Tessent™ Shell User’s Manual 283

Tessent Shell Workflows
Make Pre-ATPG Connections With Third-Party Scan for Top Chip

Prerequisites
• You must have performed the two-pass DFT insertion as described in “Perform Two-Pass
Insertion and Synthesis for Top Chip” on page 280.

• You must have inserted scan using your third-party scan insertion tool per the guidelines provided
in “Third-Party Scan Insertion for Top Chip” on page 281.

Procedure
1. Load the design. (Refer to lines 1-10.)

2. Change to insertion mode. (Refer to line 13.)

3. Make the connections. (Refer to lines 15-34.)

4. Save the design. (Refer to line 37.)

5. Write the design back to the TSDB. (Refer to lines 39-41.)

Examples

Example Dofile for Pre-ATPG Connections for Top Chip

1 # load the design
2 set_context dft -no_rtl
3 set_tsdb_output_directory ../tsdb_outdir
4 open_tsdb
\ ../../cores_will_be_wrapped/<child_core_name>/tsdb_outdir
5 # Read the tessent cell library
6 read_cell_library \
7
../../library/standard_cells/tessent/NangateOpenCellLibrary.tcelllib
8 read_design <top_level_name> -design_id <rtl2> -no_hdl
9 read_verilog ../<synthesis_path>/<top_level_name>.vg
10 read_design <child_core_name> -design_id <scan> -view graybox
11 set_current_design <top_level_name>
12
13 # make the ATPG connections:
14 set_system_mode insertion
15
16 # disconnect empty scan out from ground
17
delete_connection /chip_top_rtl2_tessent_edt_c1_inst/edt_scan_out[20]
18
delete_connection /chip_top_rtl2_tessent_edt_c1_inst/edt_scan_out[21]
19
delete_connection /chip_top_rtl2_tessent_edt_c1_inst/edt_scan_out[22]
20
delete_connection /chip_top_rtl2_tessent_edt_c1_inst/edt_scan_out[23]
21 …

284 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Perform Top-Chip ATPG Pattern Generation and Wrapped-Core Pattern Retargeting
22 # connect top level EDT scan in to child core primary input of
wrapper
23 # chain
24 create_connection /chip_top_rtl2_tessent_edt_c1_inst/edt_scan_in[20]
25 /<child_core_instance_1>/ext_wsi[0]
26 create_connection /chip_top_rtl2_tessent_edt_c1_inst/edt_scan_in[21]
27 /<child_core_instance_1>/ext_wsi[1]
28 …
29 # connect top level EDT scan out to child core primary output of
wrapper
30 # chain
31
create_connection /chip_top_rtl2_tessent_edt_c1_inst/edt_scan_out[20]
32 /<child_core_instance_1>/ext_wso[0]
33
create_connection /chip_top_rtl2_tessent_edt_c1_inst/edt_scan_out[21]
34 /<child_core_instance_1>/ext_wso[1]
35 # repeat for all ext_wsi/wso of all child core instances
36
37 # save design after insertion
38 write_design -output_file <top_level_name>_scan.vg -replace
39
40 # Specify the design level before writing out a softlink of the
design
41 set_design_level physical_block
42 write_design -tsdb -softlink_netlist -verbose
43 exit

Perform Top-Chip ATPG Pattern Generation and Wrapped-Core

Pattern Retargeting
This step in the flow reads the graybox model view of the child cores, generates ATPG patterns, and
retargets those patterns for each child core in the design.

Prerequisites
• You must have completed the “Perform Two-Pass Insertion and Synthesis for Top Chip” on
page 280 step for the top chip.

• You must have inserted scan with your third-party scan insertion tool per the guidelines cited in
“Third-Party Scan Insertion for Top Chip” on page 281 for the top chip and written the scan-
inserted netlist back into the Tessent Shell Database.

• If required, make ATPG connections using the process outlined in “Make Pre-ATPG Connections
With Third-Party Scan for Top Chip” on page 283 for the top chip.

Procedure
1. Retarget the internal ATPG patterns for each wrapped core. Refer to “Performing Top-Level ATPG
Pattern Retargeting” on page 251.
Refer to “Top-Level ATPG Pattern Generation Example” on page 286 for details on top-level
ATPG. Verification of these patterns is a must to ensure that the circuit functions.

Tessent™ Shell User’s Manual 285

Tessent Shell Workflows
Perform Top-Chip ATPG Pattern Generation and Wrapped-Core Pattern Retargeting

Refer to “Pattern Retargeting of Each Child Core Example” on page 287 for details on the
retargeting of patterns for each child core.
Depending on tester channel availability on how many cores can be run in parallel, the internal
mode ATPG patterns from each of the lower-level cores can be retargeted to the chip-level top.

2. Save the design and write the patterns to the TSDB using the write_tsdb_data command.

write_tsdb_data -replace

Examples

Top-Level ATPG Pattern Generation Example

# Import design:
set_context pattern -scan -design_id <scan>
set_tsdb_output_directory ../tsdb_outdir

# This open_tsdb should import all tsdb of child cores

open_tsdb ../../wraped_cores/<child_core_name>/tsdb_outdir
# Read the tessent cell library
read_cell_library \
../../library/standard_cells/tessent/NangateOpenCellLibrary.tcelllib
# make sure to import all child cores in graybox view
read_design <child_core_name> -design_id <scan> -view graybox
read_design <top_level_name> -design_id <scan>
set_current_design <design_name>
set_design_level top

# Import core instances we want to active:

add_core_instances -module chip_top_gate2_tessent_occ_INCLK
add_core_instances -module chip_top_gate2_tessent_occ_pll_clock_0
add_core_instances -module chip_top_gate2_tessent_edt_c1

# Configure top level DFT signal values to edt_mode and all wrapped child
# core instances to external mode:
set_static_dft_signal_values edt_mode 1
set_static_dft_signal_values ltest_en 1
set_static_dft_signal_values tck_occ_en 1
set_static_dft_signal_values int_ltest_en 1

# Configure child core by set_test_setup_icall

set_static_dft_signal_values ext_mode 1 -instance <child_core_name1>
set_static_dft_signal_values ext_ltest_en 1 -instance <child_core_name1>

# Repeat for all child core instances

# Generate and save pattern:

set_fault_type stuck
set_system_mode analysis
create_patterns
write_tsdb_data -replace

286 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Perform Top-Chip ATPG Pattern Generation and Wrapped-Core Pattern Retargeting
# Write parallel testbench and serial testbench for simulation
write_patterns <top_level_name>_parallel.v -verilog -parallel
write_patterns <top_level_name>_serial.v -verilog -serial
# Repeat to generate transition patterns. Verification of these patterns
# are a must to ensure the circuit functions.

Pattern Retargeting of Each Child Core Example

# Import design:
set_context pattern -scan_retargeting
set_tsdb_output_directory ../tsdb_outdir

# This open_tsdb should import all tsdb of child cores

open_tsdb ../../wraped_cores/<child_core_name>/tsdb_outdir
# Read the tessent cell library
read_cell_library \
../../library/standard_cells/tessent/NangateOpenCellLibrary.tcelllib
# Make sure to import all child cores except the one we are doing
# retargeting in graybox view
read_design <child_core_name> -design_id <scan> -view graybox
read_design <current_core_name> -design_id <scan> -view graybox
read_design <top_level_name> -design_id <scan>
set_current_design <top_level_name>
set_design_level top

# Read in the internal mode core description file of current child core
# by add_core_instance:
# -mode should match the mode while generating internal mode patterns
add_core_instances -instance <current_core_instance_name> \
-core <current_core_name> -mode edt_int_stuck

# Configure top level DFT signal values to retargeting_mode for this exact
# child core:
set_current_mode retarget1_<current_child_core_name>_stuck
# Configure top level to retargeting mode for current child core
set_static_dft_signal_values retargeting1_mode 1

# Generate and save pattern:

# for transition fault ATPG, replace stuck with transition
set_fault_type stuck
import_clocks
set_system_mode analysis
create_patterns
write_tsdb_data -replace

# Write parallel testbench and serial testbench for simulation

write_patterns <current_child_core_name>_parallel.v -verilog \
-parallel
write_patterns <current_child_core_name>_serial.v -verilog \
-serial

Tessent™ Shell User’s Manual 287

Tessent Shell Workflows
Tessent Shell Flow for RTL Test Point and Wrapper Insertion

Tessent Shell Flow for RTL Test Point and

Wrapper Insertion
The Tessent Shell flow enables you to analyze the complexity of your RTL design and insert DFT logic,
such as test points, wrapper cells, and X-bounding logic.

Tip
Before performing RTL DFT insertion, familiarize yourself with “RTL DFT Analysis and Insertion”
on page 141.

This section builds on the "Tessent Shell Flow for Flat Designs" and "Tessent Shell Flow for Hierarchical
Designs" sections to add RTL test points.
Refer to the following test case for a detailed usage example of the flow described in this section:

tessent_rtldft_hierarchical_flow_<software_version>.tgz

Access this test case by navigating to the following directory:

<software_release_tree>/share/UsageExamples/

This example modifies only a portion of the steps for the “RTL and Scan DFT Insertion Flow for Physical
Blocks” on page 221. The following steps remain unchanged:

• “First DFT Insertion Pass: Performing Block-Level MemoryBIST” on page 222

• “Verifying the ICL Model” on page 232

• “Performing ATPG Pattern Generation: Wrapped Core” on page 233

• “Running Recommended Validation Step for Pre-Layout Design Sign Off” on page 238
The following sections describe the differences from the standard insertion flows when inserting test
points and wrapper cells in RTL designs:

Additions to the Second DFT Insertion Pass

DFT Insertion Pass for RTL Test Points
Performing Scan Chain Insertion With Incremental Test Point and Wrapper Cell Insertion

Additions to the Second DFT Insertion Pass

Insert wrapper cells and prepare for test point insertion at RTL during the second pass of DFT insertion.

Restrictions and Limitations

• Refer to “Limitations of RTL DFT Analysis and Insertion” on page 187.

288 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Additions to the Second DFT Insertion Pass

The line numbers in the following procedure refer to the dofile in Figure 51 on page 289.

Prerequisites
• An RTL physical block with MemoryBIST hardware inserted.

Procedure
1. Open the design and prepare for the second insertion pass by following the steps from the basic
flow. (Lines 1-23)

2. Register the enable signals for test points and wrapper cells. (Lines 25-27)

3. Register the other DFT signals and check the pre-DFT design rules. (Lines 29-47)

4. Specify the EDT and OCC instruments for insertion. (Lines 49-95)

5. Set up for wrapper cell insertion by performing the following steps (Lines 97-107):

a. Specify dedicated wrapper cells for output ports with no functional source.

b. Turn on dedicated wrapper cells for all ports.

c. Run the analyze_wrapper_cells command to identify the locations to insert wrapper cells.

d. Report the wrapper cell locations and check the report.

6. Insert the EDT, OCC, and wrapper cells with the process_dft_specification command. (Lines
109-110)

7. Extract the ICL model and simulate to verify correct insertion by following the steps from the basic
flow. (Lines 112-129)

Results
An RTL physical block with inserted MemoryBIST, EDT, OCC, and wrapper cells that is ready for the next
step (inserting RTL test points).

Examples
The following example script highlights the Tessent flow modifications (in orange) for DFT logic insertion
at RTL.

Figure 51. Example of Preparing for RTL Test Point Insertion

1 # Set the context to insert DFT into RTL-level design

2 # Define a new design ID
3 set_context dft -rtl -design_id rtl2
4
5 # Set the location of the TSDB.
6 # Default is the current working directory.
7 set_tsdb_output_directory ../tsdb_outdir
8
9 # No need to read in the design using read_verilog.
10 # It can be read directly from the TSDB.
11 # Read the RTL after mbist insertion

Tessent™ Shell User’s Manual 289

Tessent Shell Workflows
Additions to the Second DFT Insertion Pass
12 read_design processor_core -design_id rtl1
13
14 # Read cell library
15 read_cell_library ../library/standard_cells/tessent/adk.tcelllib
16
17 # Read in memory verilog model
18 read_verilog ../library/memories/*.v \
19 -exclude_from_file_dictionary
20
21 set_current_design processor_core
22
23 set_design_level physical_block
24
25 # RTL DFT Signals
26 add_dft_signals control_test_point_en observe_test_point_en
27 add_dft_signals wrapper_toggle_en
28
29 # Add DFT Signals
30 # DFT Signal used for logic test
31 add_dft_signals ltest_en
32 add_dft_signals scan_en edt_update test_clock \
33 -source_node { scan_enable edt_update test_clock_u }
34 add_dft_signals edt_clock shift_capture_clock \
35 -create_from_other_signals
36 # DFT Signal used to test memories with multi-load ATPG patterns
37 add_dft_signals memory_bypass_en
38 # DFT Signal used for Scan Tested network to be tested
39 # during logic test
40 add_dft_signals tck_occ_en
41 # DFT Signals used for hierarchical DFT
42 add_dft_signals int_ltest_en ext_ltest_en int_mode ext_mode
43 report_dft_signals
44
45 # Specify to run pre-DFT DRC rules
46 set_dft_specification_requirements -logic_test on
47 check_design_rules
48
49 # Create and report a DFT Specification
50 set spec [create_dft_specification -sri_sib_list {edt occ} ]
51 report_config_data $spec
52
53 # Use report_config_syntax DftSpecification/edt|occ to
54 # see full syntax
55 read_config_data -in $spec -from_string {
56 OCC {
57 ijtag_host_interface : Sib(occ);
58 }
59 }
60
61 # Below is a generic way to populate the OCC.
62 # The clock list is design specific and needs to be updated
63 # for the design
64 # The scan_enable and shift_capture_clock signals are

290 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Additions to the Second DFT Insertion Pass
65 # automatically connected to OCC instances
66 # Modify the list below to your specific design requirements
67 set id_clk_list [list \
68 dco_clk dco_clk\
69 ]
70
71 foreach {id clk} $id_clk_list {
72 set occ [add_config_element OCC/Controller($id) -in $spec]
73 set_config_value clock_intercept_node -in $occ $clk
74 }
75
76 report_config_data $spec
77
78 # The edt_clock and edt_update signals are automatically
79 # connected to EDT instances
80 # The EDT controller is built-in with Bypass
81
82 # Modify the below specification to your specific design
83 # requirements

84 read_config_data -in $spec -from_string {

85 EDT {
86 ijtag_host_interface : Sib(edt);
87 Controller (c1) {
88 longest_chain_range : 100, 200;
89 scan_chain_count : 20;
90 input_channel_count : 1;
91 output_channel_count : 1;
92 }
93 }
94 }
95 report_config_data $spec
96
97 # To facilitate insertion of dedicated wrapper cells
98 set_wrapper_analysis_options -register_undriven on

99 #-- Turn on dedicated wrapper cell insertion for all input/ouput

100 # ports,enable below command
101 set_dedicated_wrapper_cell_options on -ports [get_ports *]
102 ##-- To turn off dedicated wrapper cell insertion,
103 # uncomment command below
104 #set_dedicated_wrapper_cell_options off

105 analyze_wrapper_cells
106 report_wrapper_cells -verbose > WC_at_RTL_Verbose.rpt
107 report_wrapper_cells -summary > WC_at_RTL_Summary.rpt
108
109 # Generate and insert the hardware
110 process_dft_specification
111
112 # Extract IJTAG network and create ICL file for core level
113 extract_icl
114

Tessent™ Shell User’s Manual 291

Tessent Shell Workflows
DFT Insertion Pass for RTL Test Points
115 # Generate patterns to verify the inserted DFT logic
116 create_pattern_specification
117 process_pattern_specification
118
119 # Point to the libraries and run the simulation
120 set_simulation_library_sources \
121 -v ../library/standard_cells/verilog/adk.v \
122 -v ../library/memories/*.v
123 run_testbench_simulations
124
125 # If simulation fails use the command below to see which pattern
126 # failed
127 #check_testbench_simulations -report_status
128
129 exit

DFT Insertion Pass for RTL Test Points

Insert the RTL test points in a separate insertion pass after inserting any wrapper cells and X-bounding
logic.

Restrictions and Limitations

• Refer to “Limitations of RTL DFT Analysis and Insertion” on page 187.

Prerequisites
• An RTL physical block with all test instruments inserted except test points and scan chains.
The line numbers in the following procedure refer to the dofile in Figure 52 on page 293.

Procedure
1. Open the design and prepare for another insertion pass by following the steps from the basic flow.
(Lines 1-20)

2. Specify test point types and quantity. (Lines 22-36)

a. Set the goal of test point insertion as reducing the number of embedded deterministic test
(EDT) patterns with the set_test_point_type command.

b. Specify test point constraints with the set_test_point_analysis_options command.

This example specifies the maximum number of test points as a percentage of the number of
flip-flops in the block.

c. Specify the enable signals for control points and observe points.

d. Specify practical options for test point analysis that mimic synthesis by excluding floating and
tied logic, and consider only the editable portions of the designs.

3. Assess the complexity of the RTL and its suitability for test point insertion with the
report_rtl_complexity command. (Lines 38-39)

292 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
DFT Insertion Pass for RTL Test Points

Optionally, edit the RTL design to reduce complexity and facilitate test point insertion.

4. After checking design rules (to elaborate the design and transition to analysis mode), report the
RTL complexity again to get a detailed analysis of potential test point locations. (Lines 41-49)
This example uses the "-effort low" argument of the report_rtl_complexity command to analyze
only the editable regions of the design. You can also use the "-effort high" argument of the
report_rtl_complexity command to analyze both the editable and non-editable regions of the
design.

5. Determine the optimal locations to insert test points with the analyze_test_points command. (Lines
51-52)

6. Use the report_test_points and report_rtl_complexity commands to understand the number of test
points and the types of locations. (Lines 54-55)

7. Insert the RTL test points in the RTL design with the process_dft_specification command. (Lines
57-61)

8. Write scripts that facilitate synthesis. (Lines 63-69)

Results
An RTL physical block with test points inserted that is ready for synthesis.

Examples
The following example script inserts test points in an RTL physical block.

Figure 52. Example of RTL Test Point Insertion

1 # Set context to insert test points into RTL-level design

2 set_context dft -rtl -test_points -design_id rtl3
3
4 # Set location of TSDB. Default is current working directory.
5 set_tsdb_output_directory ../tsdb_outdir
6
7 # Reading the tessent cell library
8 read_cell_library ../library/standard_cells/tessent/adk.tcelllib
9
10 # No need to read in the design using read_verilog.
11 # It can be read directly from the TSDB.
12 # Read the RTL after mbist insertion
13 read_design processor_core -design_id rtl2
14
15 # Read in memory verilog model
16 read_verilog ../library/memories/*.v \
17 -exclude_from_file_dictionary
18
19 set_current_design processor_core
20 report_clocks
21
22 # Pattern count reduction focus
23 set_test_point_type edt_pattern_count
24 # Insert maximum total number of flops

Tessent™ Shell User’s Manual 293

Tessent Shell Workflows
DFT Insertion Pass for RTL Test Points
25 set_test_point_analysis_options -total_number 2%
26
27 # Enable test point types. CP and OP
28 set_test_point_insertion_options -control_point_enable \
29 control_test_point_en
30 set_test_point_insertion_options -observe_point_enable \
31 observe_test_point_en
32
33 # Specify test point analysis options
34 set_rtl_dft_analysis_options -exclude_floating_logic on \
35 -exclude_tied_logic on \
36 -nodes_available_for_analysis editable
37
38 # Report RTL complexity prior to mode transition
39 report_rtl_complexity -summary > rtl_complexity_presmt
40
41 # Check the test point logic
42 check_design_rules
43
44 # Use effort high, for more info, if RTL is not deemed
45 # appropriate for RTL test point insertion
46 # report_rtl_complexity -summary -effort high \
47 # > rtl_complexity_pretpi_high
48 report_rtl_complexity -summary -effort low \
49 > rtl_complexity_pretpi_low
50
51 # Determine where to insert control and observe points
52 analyze_test_points
53
54 report_test_points
55 report_rtl_complexity -summary > rtl_complexity_posttpi
56
57 # Use RTL rather than logic for test point insertion
58 set_defaults_value DftSpecification/use_rtl_cells on
59 set spec [create_dft_specification -replace]
60 # Insertion of dedicated testpoints
61 process_dft_specification
62
63 extract_sdc
64
65 set_system_mode setup
66 write_design_import_script processor_core.dc_design_load_script \
67 -use_relative_path_to ../4.synthesize_rtl -replace
68
69 exit

294 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Performing Scan Chain Insertion With Incremental Test Point and Wrapper Cell Insertion

Performing Scan Chain Insertion With Incremental

Test Point and Wrapper Cell Insertion
After inserting the test points and wrapper cells in the RTL design and synthesizing, perform incremental
insertion of test points and wrapper cells at the gate level. Then insert scan chains that include the flip-
flops for the test points and wrapper cells inserted at the register transfer level and gate level.

Prerequisites
• A gate-level design with test points and wrapper cells already inserted. Prior to scan chain
insertion, you must perform synthesis as described in “Performing Synthesis” on page 209.

• Familiarity with “Performing Scan Chain Insertion (Flat Design)” on page 210 and “Performing
Scan Chain Insertion: Wrapped Core” on page 229.
The line numbers in the following procedure refer to the dofile in Figure 53 on page 296.

Procedure
1. Open the gate-level design and prepare for the scan insertion pass by following the steps from the
basic flow. (Lines 1-32)

2. Perform incremental test point insertion with the set_test_point_types and

set_test_point_analysis_options commands before running the analyze_test_points command.
(Lines 34-40)

3. Perform incremental wrapper cell insertion. (Lines 48-54)

a. Identify the wrapper cells inserted at RTL to enable the tool to find locations for incremental
wrapper cell insertion with the set_wrapper_analysis_options command.

b. Insert the wrapper cells and report by running the analyze_wrapper_cells command.

4. Continue with the scan insertion setup. (Lines 56-78)

5. Perform any scan chain stitching and incremental insertion of test points and wrapper cells with the
insert_test_logic command. (Lines 80-82)

6. Analyze the reports for scan chains, wrapper cells, and test points. (Lines 84-87)

Results
A physical block at the gate level that is ready for ATPG and the rest of the Tessent flow.

Examples
The following example script highlights the Tessent flow modifications (in orange) for incremental DFT
logic insertion:

Tessent™ Shell User’s Manual 295

Tessent Shell Workflows
Performing Scan Chain Insertion With Incremental Test Point and Wrapper Cell Insertion

Figure 53. Example of Scan Insertion With Incremental Test Point and Wrapper Cell Insertion

1 # Set context to perfrom scan insertion and stitching

2 set_context dft -scan -test_points -no_rtl
3
4 # Open the previous TSDB directories if it is not in the current
5 # working directory
6 set_tsdb_output_directory ../tsdb_outdir
7
8 # Read Tessent Library
9 read_cell_library ../library/standard_cells/tessent/adk.tcelllib
10
11 # Read the synthesized netlist
12 read_verilog ../4.synthesize_rtl/processor_core_synthesized.vg
13
14 # Read the design files from the second RTL insertion pass
15 # Use the -no_hdl switch to skip reading the netlist as the
16 # synthesized netlist has already been read
17 read_design processor_core -design_identifier rtl3 \
18 -no_hdl -verbose
19
20 add_black_boxes -modules { \
21 SYNC_1RW_8Kx16 \
22 }
23
24 set_current_design processor_core
25
26 set_scan_enable -single_global_scan_enable on
27
28 # No need to define the clocks as this was done during
29 # pre-dft-drc in Step 2 when EDT was inserted
30 # The EDT instance will be automatically marked as non-scan
31
32 report_static_dft_signal_settings
33
34 # Incrementally add test points to further improve pattern count
35 set_test_point_type edt_pattern_count
36 set_system_mode analysis
37
38 set_test_point_analysis_options -total_number 3%
39
40 analyze_test_points
41
42 # Exclude the edt_channel in and out ports from wrapper chain
43 # analysis. The ijtag_* edt_update ports are automatically
44 # excluded
45 set_wrapper_analysis_options -exclude_ports \
46 [ get_ports {*edt_channel*} ]
47
48 # Identify previously inserted dedicated wrapper cells
49 set_wrapper_analysis_options \
50 -identify_existing_dedicated_wrappers on

296 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Performing Scan Chain Insertion With Incremental Test Point and Wrapper Cell Insertion
51
52 ##Performs wrapper cell analysis
53 analyze_wrapper_cells
54 report_wrapper_cells -verbose > wrapper_cells.list
55
56 # The OCC and sti-sib(mbist ijtag network) chains will be
57 # traced automatically
58 report_scan_segments
59
60 # Specify different modes (internal and external) how the chains
61 # need to be stitched
62 # The type internal/external and enable_dft_signal are inferred
63 # from registered DFT
64 # Signals(int_mode and ext_mode)
65 # Create a scan mode and specify EDT instance to connect the
66 # scan chains to
67 set edt_instance [get_instances -of_icl_instances
68 [get_icl_instances -filter
69 tessent_instrument_type==mentor::edt]]
70 add_scan_mode int_mode -edt_instances $edt_instance
71
72 # Stitch shared and dedicated wrapper cells together
73 add_scan_mode ext_mode -chain_count 2
74
75 # Analyze the scan chains and review the different scan modes and
76 # chains before stitching the chains
77 analyze_scan_chains
78 report_scan_chains
79
80 # Insert scan chains and writes the scan inserted design into
81 # tsdb_outdir directory
82 insert_test_logic
83
84 report_scan_chains
85 report_scan_cells > scan_cells.list
86
87 exit

Tessent™ Shell User’s Manual 297

Tessent Shell Workflows
Tessent Shell Flow for Tiled Designs

Tessent Shell Flow for Tiled Designs

A tile is a physical block that abuts to other tiles without any logic between them. The port placement
is fixed early on so that the tile lines up with its neighbors. The DFT flow is adapted to the tiling flow
because communication between non‑neighboring tiles happens through the tile between them.
The Tessent Shell flow enables independent testing of tiles, retargeting internal modes from tiles, and
creating consolidated patterns to detect faults on tile-to-tile connections.

Note:
Because test planning uses a top-down approach, knowledge of the layout placement of tiles,
including the DFT ports, is required. Use set_dft_specification_requirements ‑design_type tile for
all DFT insertions. This prevents any modification to tile boundaries, as the tool does not edit the
layout.

The functional clock tree is localized within each tile and controlled by dedicated On‑Chip Clock
Controllers (OCCs).
A tile-based design affects different aspects of DFT insertion, and the Tessent Shell flow provides the
following capabilities:

• Handling of boundary scan insertion using embedded boundary scan

• Infrastructure to support IJTAG/Memory BIST and BISR chains

• Clocking architecture for internal and external mode testing of tiles

• Logic testing of tiles with handling of identical cores

Tiling DFT Terminology

How the DFT Insertion Flow Applies to Tiled Designs
Clocking During Logic Test
Pre-DFT Design Modification and Integration
Creation of IJTAG Graybox
Example Flow for a Tiled Design
Tiling Flow Used in Example
DFT Flow for Tiles Without TAP and BISR Controllers
Embedded Boundary Scan Insertion in Tiles With a TAP Controller
IJTAG Network Insertion in Tiles With a TAP Controller
Memory BISR Insertion for Tiles With a BISR Controller
SSN Insertion for Tiles With Primary SSN Ports
Scan Insertion and Scan Modes for Tiles With Promoted OCCs
Chip-Level Integration for the Tiling Flow

298 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Tiling DFT Terminology

Tiling DFT Terminology

The Tessent Shell flow uses a set of terms when dealing with a tiled design. You must understand these
terms to perform the RTL and scan DFT insertion process on tiled designs.

• Tile — A tile is a physical block designed to abut to other tiles at the top level directly.

• Tile-based design — A tile-based design has tiles abutted at the chip level. Therefore, there are
just wire connections and no logic between the tiles, at the chip level. The chip acts as only a
container for the tiles. Typically, a tiled design uses mirroring, symmetry, and repeated blocks.

How the DFT Insertion Flow Applies to Tiled

Designs
To perform DFT insertion on tiled designs, basic knowledge of the RTL and scan insertion flows for flat
designs is required. The process for tiled designs builds on the process you use for a flat design.
During design, create a top-down floor plan of the chip. You must be aware of the placement of ports to
build the tiled design bottom-up with the precise pin placements so that they are abutted correctly.

Figure 54. Schematic of Tiling Example

The example schematic, shown in Figure 54, used to demonstrate this flow contains three unique tiles
— C1, C2, and C3. C1 and C2 are mirrored on both sides of C3. Most of the I/O pads are located in the
central C3 tile. For each tile, you perform the insertion process in a bottom-up manner, but there is no
insertion of a standard boundary scan at the chip level. Because the tiling topology affects the insertion
process of instruments, it differs from the hierarchical approach. The tiles must include DFT ports before
the DFT insertion process. Refer to “Chip-Level Port Requirements and Connections” on page 306 for
more information.

Tessent™ Shell User’s Manual 299

Tessent Shell Workflows
How the DFT Insertion Flow Applies to Tiled Designs

Boundary Scan Insertion Using Embedded Boundary Scan

The insertion of a standard boundary scan at the chip design level is not present in this flow. Instead, you
create the boundary scan chain from the embedded boundary scan segments in the tiles. Figure 55 on
page 300 presents a schematic of boundary scan topology.
When pads exist in a tile, like the C1 tiles in Figure 55 on page 300, the tiles need segments of
embedded boundary scan to be inserted. However, tiles without pads may also require internal boundary
scan cells. These cells act as pipeline stages and provide access to the neighboring tiles equipped with
scan segments, like the C2 modules in Figure 55 on page 300.
Pads are wrapped with dedicated modules, in the C3 tile where TAP is located. Along with the shared and
dedicated functional scan wrapper cells in each tile, the boundary scan cells are also used during logic
test to provide scan isolation for the tile. The wrapper cell analysis does not include BIDI (inout) ports.
Therefore, the boundary scan logic acts as dedicated wrapper cells for these ports and provides scan
isolation. For more information on how tiles with TAP and without TAP are handled, refer to “Embedded
Boundary Scan Insertion in Tiles With a TAP Controller” on page 329 and “Embedded Boundary Scan
Insertion in Tiles Without a TAP Controller” on page 313, respectively.

Figure 55. Schematic of Boundary Scan Logic

Infrastructure to Support IJTAG and Memory BIST

The IJTAG network is used to set up the memory BIST and memory repair, and to configure the design in
the required scan mode. Figure 56 on page 301 shows the schematic of the IJTAG network inserted in
the described example.
Access to the inner tile IJTAG network in tiles without a TAP controller is through their Tile Client (TC)
Segment Insertion Bit (SIB), the Scan Tested Instrument (STI), and Scan Resource Instrument (SRI)
SIBs located below the TC SIB. The TC SIB is not needed in the C3 tile because the TAP is present. If
Secondary Host Scan Interfaces to connect neighboring tiles are present, a Tile Host Collector (THC) SIB
is also added. The THC SIB provides access to the dedicated Tile Host (TH) SIBs for Secondary Host
Scan Interfaces — th_left and th_right SIBs in the C3 module, or r1 and r2 SIBs in C2 tiles.

300 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
How the DFT Insertion Flow Applies to Tiled Designs

Figure 56. Schematic of IJTAG Network

Infrastructure to Support Memory BISR Chains

The insertion of memory BISR logic depends on the number of power domains in the tiling design. Each
power domain must have a dedicated BISR chain connected to the MBISR controller. There are two
power domains in the example; BISR registers from the first power domain (pdgA) in red, and registers
from the second domain (pdgB) in blue. Figure 57 on page 302 shows the schematic of the BISR
network.
Similar to the case of embedded boundary scan insertion, the BISR chain may be required in tiles without
repairable memories because it acts as a pipeline stage to provide access to neighboring tiles. The
C2 tiles in Figure 57 on page 302 have BISR chain logic from the blue domain to provide access to
neighboring C1 tiles with repairable memories in the same power domain.
The Tessent tool cannot deduce this requirement when performing bottom-up insertion. Therefore, you
must specify it using the set_dft_specification_requirements ‑memory_test on ‑memory_bisr_host_list
{<hosts_list>} command. You must be aware of the physical layout of the BISR network before the DFT
process begins.

Tessent™ Shell User’s Manual 301

Tessent Shell Workflows
How the DFT Insertion Flow Applies to Tiled Designs

Figure 57. Schematic of Memory BISR Network

Logic Testing of Tiles Using SSN

The SSN network must go through every ScanHost node (SSH) in the design to enable scan tests of
all tiles in internal and external modes. You can also design the network to enable single testing of the
tile for diagnosis purposes. Figure 58 on page 302 shows the SSN network inserted in the example.
The SSN bus has its primary inputs and outputs in the C3 tile. It starts and terminates on auxiliary data
logic implemented during Embedded Boundary Scan insertion. The SSN network in each tile without
SSN primary ports starts from the Receiver1xPipeline (r1x pipe) and ends in a standard Pipeline. The
pipeline stages are necessary to achieve correct timing in tile-to-tile connections. The SSN network is
implemented in a plug-and-play manner. Therefore, there is no need to determine EDT requirements for
each tile beforehand. For more information on how tiles with and without primary SSN ports are handled,
refer to “SSN Insertion for Tiles With Primary SSN Ports” on page 338 and “SSN and EDT Insertion in
Tiles Without TAP and BISR Controllers” on page 322, respectively.

Figure 58. Schematic of SSN Network

302 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Clocking During Logic Test

Clocking During Logic Test

The tiling approach supports at-speed tile-to-tile test in external mode. Internal and external scan modes
require different clock controls. You must add a clock multiplexer at every clockout port to support running
several tiles in parallel while they are in their respective internal modes. This is to avoid cascaded active
OCCs.

Clock Control in Internal Mode

During internal test, each tile is tested independently and must have its own clock control, using OCCs.
Additional bypass clock multiplexers are required to provide free-running clocks directly to the dedicated
OCCs and to avoid potentially cascading active OCCs. In the following figure, active OCCs are marked
with a red dot, and the blue clock path indicates the free-running clock to the OCCs. The insertion of
additional clock multiplexers is described in “SSN and EDT Insertion in Tiles Without TAP and BISR
Controllers” on page 322.

Figure 59. Clocking in Internal Test Mode

Clock Control in External Mode

You must synchronize the scan chains in the tiles to test the tile-to-tile timing paths. Only the OCCs
at the bases of the functional clock trees are active in the external mode. The native functional clock
paths deliver the clock to all tiles (the additional clock multiplexers select the native clock path in external
mode). This makes it possible to restore functional synchronicity between the tiles. The following
figure shows this configuration. The OCC in the C3 tile is marked active, and the rest of the OCCs are
transparent and operate in the shift-only mode.

Tessent™ Shell User’s Manual 303

Tessent Shell Workflows
Clocking During Logic Test

Figure 60. Clocking in External Mode

Timing of Tile-To-Tile Connections

The IEEE 1687 IJTAG protocol is a robust two-edge protocol in which data is strobed from one node at
negedge and then captured at the next network node at posedge. There is always one half of a TCK cycle
to propagate data from one node to another. In some cases, this time window may be too short for correct
propagation. Figure 61 on page 304 shows the schematic of the forward and the return paths between
tiles:

Figure 61. Forward and Backward Propagation of Data Between Tiles

The clock in the C1_i1 tile is always a delayed version of the clock in C2_i1 because it is sourced from
a leaf of the C2 clock tree. With this assumption, you extend the propagation window in the forward
path by the value of the TCK clock delay. Figure 62 on page 305 shows a simplified waveform of the
forward propagation. The TCK clock delay reduces the time window for the returning path. The retiming
element of the IJTAG node connected to the scan-out port is removed, making it a posedge-to-posedge
propagation and extending the time window in this case.

304 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Clocking During Logic Test

Figure 62. Simplified Waveform of Forward Propagation, Negedge to Posedge

Figure 63 on page 305 shows a simplified waveform for this propagation. The gray arrow depicts the
propagation if the retiming stage is present and the path is not relaxed.

Figure 63. Simplified Waveform of Return Posedge to Posedge Propagation

The relaxation of return path data propagation is applied to all the Tessent instruments that need
communication between the tiles (IJTAG network, memory BISR chains, and boundary scan chains).

Tessent™ Shell User’s Manual 305

Tessent Shell Workflows
Pre-DFT Design Modification and Integration

Pre-DFT Design Modification and Integration

The DFT ports and their connections between the tiles and to the package boundary must preexist.
If they do not, use the TopModuleConnections wrapper or insertion commands to create them.
To prevent any modification of the current module boundary during insertion,
use the set_dft_specification_requirements -design_type tile command. The
allow_port_creation_on_current_design property is set to off by default in every processed
DftSpecification if the design type is set to tile.
This means that the tool assumes all DFT ports required by Tessent instruments to already
exist in each tile before inserting their DFT in a bottom-up fashion. If this is not the case, set the
"allow_port_creation_on_current_design" property to on in the DftSpecification before specification
processing.

Chip-Level Port Requirements and Connections

Tile-Level Port Connections and Requirements

Chip-Level Port Requirements and Connections

There is no logic at the chip level for a tiled design but the design must have certain preexisting ports for
you to run the DFT flow.
The required chip-level DFT ports are:

• BISR ports: bisr_prog_voltage, bisr_clock, bisr_trigger

◦ bisr_clock and bisr_trigger can be generated internally and are, therefore, optional ports.

• IJTAG TAP client ports: tck, trst, tms, tdi, tdo

The SSN bus ports may not always be required because functional ports can be reused using boundary
scan auxiliary logic.
You must add the dedicated SSN ports, that is, SSN input and output bus ports, and the SSN bus clock
port.
If the required ports and connections are not present, use the TopModuleConnections specification to
insert DFT ports in tiles and to connect them at the chip level.

Tile-Level Port Connections and Requirements

The manual integration of many tiles to a single chip in Verilog may be hard to achieve.

Tip
We recommend that you use the Tessent insertion mode and the TopModuleConnections
specification to integrate DFT logic in tiles if the automation you used to create and connect the
functional ports did not include the DFT ports.

The following example shows a Tessent script using the TopModuleConnections specification to integrate
a tiling design and the syntax of the TopModuleConnections wrapper.

306 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Tile-Level Port Connections and Requirements

set_context dft -rtl ‑design_id rtl0

read_verilog ../../design/chip/chip.v
set_current_design chip

read_config_data \
top.top_level_ports_and_connections

process_top_module_connections

Start the TopModuleConnections specification from a definition of modules that are used in the
integration. Use the ChildBlock wrapper to describe the module and the ports to be used, or to create
them if not available. The Instance wrapper below ChildBlock is used to define the input sources for newly
created input ports on each instance of the ChildBlock module.

TopModuleConnections(<design_name>) {
ChildBlock(<design_name>) {
file_name : <full_path_name> ;
input_ports : <port_name>, ... ;
output_ports : <port_name>, ... ;
Instance(<instance_name>) {
input_port_sources :
<port_pin_name>, ... ;
}
}
}

Note:
The order of sources in the Instance wrapper must correspond to the order of input ports in the
ChildBlock wrapper.

IJTAG DFT Ports

The ports required for IJTAG integration are listed here. Declare the additional IJTAG secondary
interfaces in the ChildBlock wrapper.

Note:
You also require preexisting ports for embedded boundary scan and memory BISR. Contact your
Siemens representative to refer to the example test case.

IJTAG client input ports:

• ijtag_tck

• ijtag_reset

• ijtag_ce

• ijtag_se

Tessent™ Shell User’s Manual 307

Tessent Shell Workflows
Tile-Level Port Connections and Requirements

• ijtag_ue

• ijtag_sel

• ijtag_si
IJTAG client output ports:

• ijtag_so
IJTAG secondary interface input ports:

• <interface_name>_ijtag_from_so
IJTAG secondary interface output ports:

• <interface_name>_ijtag_to_tck

• <interface_name>_ijtag_to_reset

• <interface_name>_ijtag_to_ce

• <interface_name>_ijtag_to_se

• <interface_name>_ijtag_to_ue

• <interface_name>_ijtag_to_sel

• <interface_name>_ijtag_to_si
The following code example shows the part of the ChildBlock wrapper that describes IJTAG ports and
their connections on instance C2_i1:

ChildBlock(c2) {
file_name : ../../design/c2/c2.v;
input_ports : …
#Blue in figure
ijtag_tck,
ijtag_reset,
ijtag_ce,
ijtag_se,
ijtag_ue,
ijtag_sel,
ijtag_si,

#Red in figure
r1_ijtag_from_so,
#Orange in figure

r2_ijtag_from_so,
…

308 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Tile-Level Port Connections and Requirements

output_ports : …
#Blue in figure
ijtag_so,

#Red in figure
r1_ijtag_to_tck,
r1_ijtag_to_reset,
r1_ijtag_to_ce,
r1_ijtag_to_se,
r1_ijtag_to_ue,
r1_ijtag_to_sel,
r1_ijtag_to_si,

#Orange in figure
r2_ijtag_to_tck,
r2_ijtag_to_reset,
r2_ijtag_to_ce,
r2_ijtag_to_se,
r2_ijtag_to_ue,
r2_ijtag_to_sel,
r2_ijtag_to_si,
…

Instance(c2_i1) {
input_port_sources : …
#Blue in figure
c3_i1/left_ijtag_to_tck,
c3_i1/left_ijtag_to_reset,
c3_i1/left_ijtag_to_ce,
c3_i1/left_ijtag_to_se,
c3_i1/left_ijtag_to_ue,
c3_i1/left_ijtag_to_sel,
c3_i1/left_ijtag_to_si,
#Red in figure
c1_i1/ijtag_so,
#Orange in figure
c1_i2/ijtag_so,
…
}
Instance(c2_i2) {
…
}
}

The following figure shows the schematic of the IJTAG network in the C2 tile and input connections of
C2_i1:

Tessent™ Shell User’s Manual 309

Tessent Shell Workflows
Creation of IJTAG Graybox

Figure 64. Schematic of IJTAG Network in C2 Tile and IJTAG

Ports Created on C2_i1 Instance With Their Input Connections

Creation of IJTAG Graybox

After every DFT insertion phase (after the process_dft_specification command), extract the ICL
description and generate the IJTAG graybox.
The IJTAG graybox is a design view that preserves only IJTAG instruments. Using an IJTAG graybox view
instead of the full view of a tile reduces runtime and memory consumption in simulation tools.
In integrated package simulations, sometimes you cannot directly access a tile under test and may need
to access it through other tiles. In such cases, you must read in the full view of the targeted tile and the
IJTAG graybox views of all the other tiles.

Note:
We recommend you use IJTAG graybox views whenever possible.

Running the extract_icl command generates the IJTAG graybox by default. The IJTAG graybox
generation can also be turned off, as demonstrated in this code example:
extract_icl ‑create_ijtag_graybox off

Example Flow for a Tiled Design

The following figure shows a sample schematic of a tiled design. If you would like to run this design,
contact your Siemens representative for the tiling test case matching the example used here.
The tiles are connected only to the neighboring tiles or to chip-level ports when pads for primary ports are
present in the tile.

310 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Tiling Flow Used in Example

Figure 65. Schematic of a Sample Test Case

This design consists of seven tiles:

• Four instances of the C1 module

• Two instances of the C2 module

• One instance of the C3 module

The C1_i3 and C1_i4 instances are mirrored versions of C1_i1 and C1_i2 respectively, and, similarly,
C2_i2 is a mirrored version of C2_i1. The OCCs are the blue rectangles with red dots, and the pads are
the green squares.
This design has the TAP, the Memory BISR controller, and the SSN bus access pads in the C3_i1 tile.
The presence of these instruments affects the DFT flow for the C3 tile. This causes the DFT flow for
the C3 tile to differ from the other tiles. All DFT ports are pre-created on each tile and pre-connected
in the chip module (“Pre-DFT Design Modification and Integration” on page 306). Example 1 in
process_top_module_connections shows how you can automate this within the tool.
You do not need to insert TAP in the same tile as the Memory BISR controller or SSN bus access pads as
shown in the example (Figure 65 on page 311). If the controllers and pads are in different tiles, modify
the DFT flow for those tiles accordingly.

Tiling Flow Used in Example

The flow used for the example schematic is depicted in the following flowchart.
The color coding used in the flow diagram is:

• Green — Steps related to tiles

• Blue — Steps for optional early verification

• Orange — Steps for chip-level integration

Tessent™ Shell User’s Manual 311

Tessent Shell Workflows
Tiling Flow Used in Example

Figure 66. Tiling Flow Used in Example Test Case

312 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
DFT Flow for Tiles Without TAP and BISR Controllers

DFT Flow for Tiles Without TAP and BISR

Controllers
For tiles without TAP or BISR controllers, the tiling DFT flow is similar to the Tessent Shell hierarchical
DFT flow.
In the example test case (“Example Flow for a Tiled Design” on page 310), the tiles do not have nested
physical blocks, but the presence of nested physical blocks does not affect the tiling flow. The design
type of a tile affects the default specifications generated for embedded boundary scan, IJTAG, and
MemoryBISR.

Note:
For embedded boundary scan, IJTAG, MemoryBIST and MemoryBISR insertion, set the
design_type property to tile using the set_dft_specification_requirements ‑design_type tile
command.

Embedded Boundary Scan Insertion in Tiles Without a TAP Controller

IJTAG Network Insertion in Tiles Without a TAP Controller
Memory Test Insertion in Tiles Without TAP and BISR Controllers
SSN and EDT Insertion in Tiles Without TAP and BISR Controllers
Scan Insertion and Scan Modes in Tiles Without TAP and BISR Controllers
Patterns Generation in Tiles Without a TAP Controller
Verification and Simulations

Embedded Boundary Scan Insertion in Tiles Without a

TAP Controller
Use the Embedded Boundary Scan flow to add boundary scan in tiled designs because the pads are
embedded inside the child tile blocks. The insertion of internal boundary scan cells may also be required
in tiles without pads.
These internal boundary scan cells, in the C2 tile, act as pipeline registers, and enable the C3 tile (with
TAP interface) to access all the tiles with embedded boundary scan segments.
In the following figure, the C2 modules require boundary scan logic to connect segments in instances of
the C1 module. You can insert the auxiliary pad logic for SSN during Embedded Boundary Scan insertion.

Tessent™ Shell User’s Manual 313

Tessent Shell Workflows
Embedded Boundary Scan Insertion in Tiles Without a TAP Controller

Figure 67. Schematic of Boundary Scan Logic in Example Test Case

Embedded Boundary Scan Insertion in Tiles With Pads

Embedded boundary scan segments are reused during logic test to provide scan isolation from the chip-
level I/Os for tiles during chip-level ATPG modes.
To enable test logic support for embedded boundary scan segments, you must set the
EmbeddedBoundaryScan/max_segment_length_for_logictest property to unlimited, or to an integer value
that corresponds to the required length of the embedded boundary scan segments used during scan
chain stitching. You need the pipeline stage on the output of the embedded boundary scan segment
to relax the timing loop on the return path. This is described in “Timing of Tile-To-Tile Connections” on
page 304.
The following code presents the DftSpecification for Embedded Boundary Scan for the C1 tile with pads:

DftSpecification(c1,rtl1) {
allow_port_creation_on_current_design : off;
EmbeddedBoundaryScan {
pad_io_ports : clk_ref, rx_data_in, …;
max_segment_length_for_logictest : 200;
Interface {
scan_out_pipeline : on;
}
BoundaryScanCellOptions {
clk_ref : clock;
}
}
}

The following schematic displays the logic inside the C1 tile with pads:

314 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Embedded Boundary Scan Insertion in Tiles Without a TAP Controller

Figure 68. Schematic of Boundary Scan Logic Inside C1

For more details on how the HostBscanInterface wrapper assembles the boundary scan chain in C1, refer
to Example 1 in HostBScanInterface in the Tessent Shell Reference Manual.

Embedded Boundary Scan Insertion in Tiles Without Pads

In tiles without pads, embedded boundary scan logic is used to provide access to adjacent tiles equipped
with other embedded boundary scan segments.
The following example shows the DftSpecification for a tile with one client interface and two host
interfaces to connect neighboring tiles. For more details on how the HostBscanInterface wrapper
assembles the boundary scan chain in C2, refer to Example 1 in HostBScanInterface in the Tessent Shell
Reference Manual.

DftSpecification (c2,rtl1) {
EmbeddedBoundaryScan {
# 1 in figure
HostBscanInterface(client){
# 2 in figure
EBScanPipeline(client_out) {
so_retiming : off;
}
# 3 in figure is input pipeline
EBScanPipeling(from_r1) {
}
# 4 in figure is a host interface
SecondaryEBScanInterface(r1) {
}
# 5 in figure is input pipeline
EBScanPipeline(to_r1) {
}
# 6 in figure is output pipeline

Tessent™ Shell User’s Manual 315

Tessent Shell Workflows
IJTAG Network Insertion in Tiles Without a TAP Controller
EBScanPipeline(from_r2) {
}
# 7 in figure is a host interface
SecondaryEBScanInterface(r2) {
}
# 8 in figure is output pipeline
EBScanPipeline(to_r2) {
}
}
}
}

The client interface in the resulting schematic (Figure 69 on page 316), requires a pipeline on the scan
output port (client interface marked 1, output pipeline marked 2). The host interfaces require input and
output pipelining.

Figure 69. Schematic of Embedded Boundary Scan Logic in C2 Without Pads

IJTAG Network Insertion in Tiles Without a TAP Controller

The IJTAG network used in the tiling flow is almost identical to the network used in the hierarchical flow.
The tool modifies the network topology for the tiling flow when you set the design type to "tile".
Access to the local Scan Resource Instrument (SRI) and Scan Test Instrument (STI) Segment Insertion
Bits (SIBs) is guarded by an additional Tile Client (TC) SIB. This TC SIB, with internal scan-in pipelining
and retiming stage removed, gets added to the default DftSpecification when you set the -design_type to
tile. The output of the TC SIB is connected directly to the scan-out port. To relax the propagation of the

316 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
IJTAG Network Insertion in Tiles Without a TAP Controller
loop timing interface, the retiming stage is removed as detailed in “Timing of Tile-To-Tile Connections” on
page 304.
In this example (“Example Flow for a Tiled Design” on page 310), after Embedded Boundary Scan you
insert the memory BIST that requires an IJTAG connection. Figure 70 on page 317 presents the IJTAG
network after insertion of Memory BIST. To build the IJTAG network, refer to Example 3 in IJTAG Network
in the Tessent Shell Reference Manual.

Figure 70. Schematic of IJTAG Network After Memory BIST Insertion in C1

The logic test support (EDT, OCC, and SSN) is inserted in the next insertion pass. In the tiling flow, new
elements of the IJTAG network are connected below TC SIB, by default. The following figure depicts this:

Tessent™ Shell User’s Manual 317

Tessent Shell Workflows
IJTAG Network Insertion in Tiles Without a TAP Controller

Figure 71. Schematic of IJTAG Network After Memory BIST and Logic Test insertion in Tile

Sometimes, the IJTAG network requires additional scan interfaces to host neighboring tiles, such as
the C2 tile. In such cases, a dedicated SIB hosts each secondary host scan interface. All SIBs that
host secondary host scan interfaces are collected and hosted by a dedicated Tile Host Collector (THC)
SIB. The THC SIB is placed in series with the TC SIB as shown in Figure 72 on page 319. Use the
create_dft_specification command to provide names of additional scan interfaces.
In the following example, r1 and r2 are two additional SecondaryHostScanInterfaces:
create_dft_specification -tile_ijtag_host_list {r1 r2}

The following code sample presents an example DftSpecification with two additional IJTAG host scan
interfaces:

IjtagNetwork {
#Blue in figure
HostScanInterface(ijtag) {
Sib(tc) {
Attributes {
tessent_dft_function : tile_client_sib;
}
to_scan_in_feedthrough : pipeline;
so_retiming : off;
Sib(sti) {
…
}
}
Sib(thc){
Attributes {
tessent_dft_function : tile_host_collector;
}

318 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
IJTAG Network Insertion in Tiles Without a TAP Controller
#Red in figure
Sib(th_r2) {
to_scan_in_feedthrough : pipeline;
SecondaryHostScanInterface(r2) {
}
}
#Orange in figure
Sib(th_r1) {
to_scan_in_feedthrough : pipeline;
SecondaryHostScanInterface(r1) {
}
}
}
}
}

Figure 72. Schematic of C2 Tile With Additional Host Scan Interfaces

Tessent™ Shell User’s Manual 319

Tessent Shell Workflows
Memory Test Insertion in Tiles Without TAP and BISR Controllers

Memory Test Insertion in Tiles Without TAP and BISR

Controllers
The MemoryBIST logic does not require any specific changes related to the tiling flow and is placed below
the Scan Test Instrument (STI) Segment Insertion Bit (SIB). You can insert the memory test logic and the
IJTAG network in the same insertion pass.
To ensure access to the BISR chains in tiles, you must slightly modify the MemoryBISR logic. You can
insert additional BISR chains for the different power domains. To specify these power domains and
memories, we recommend that you use the Unified Power Format (UPF) file.
Refer to “Figure 73” on page 321 for an example BISR network in the C2 tile. There is one repairable
RAM in the C2 tile. In this example, you require access to the neighboring tiles that are connected to the
left of the C2 tile. The neighboring tiles operate in different power domains, so you need two BISR chains
and two client interfaces:

• The first client interface, marked "1", accesses the BISR segment of RAM in the tile.

• The second client interface, marked "2", accesses BISR segments in two neighboring tiles that
work in a different power domain, pdgB.

• The third and fourth interfaces, marked 3 and 4, are host interfaces for neighboring
tiles in the power domain pdgB. You can create these interfaces using the
set_dft_specification_requirements command with the ‑memory_bisr_host_list switch.
Place a pipeline element, without the retiming stage, at the end of each of the two BISR chains (the return
path) to provide a full clock period in the loop timing interface (refer to “Timing of Tile-To-Tile Connections”
on page 304).
For more details on how memory BISR chains are inserted into a tile-based design, refer to Example 3 in
MemoryBisr/Secondary Host Chain Interface in the Tessent Shell Reference Manual. The following code
generates and displays the DftSpecification used to insert the MemoryBISR logic:

set_dft_specification_requirements -memory_test on \
‑design_type tile \
-memory_bisr_host_list {pdgB {pdgB_r1 pdgB_r2}}
create_dft_specification -tile_ijtag_host_list {r1 r2}
report_config_data DftSpecification(c2,rtl2)/MemoryBisr

MemoryBisr {
bisr_segment_order_file : c2.bisr_segment_order;
BisrElement("SegmentEnd(*)") {
Pipeline(after) {
so_retiming : off;
}
}
}

The following code sample shows the bisr_segment_order file. It lists the order of the elements in the
BISR chain from scan-out to scan-in:

320 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Memory Test Insertion in Tiles Without TAP and BISR Controllers

BisrSegmentOrderSpecification {
#1 in figure
PowerDomainGroup(pdgA) {
OrderedElements {
RAM; // RepairGroup:None BISRLength:24
}
}
#2 in figure
PowerDomainGroup(pdgB) {
OrderedElements {
#3 in figure
"SecondaryHostChainInterface(pdgB_r1)";
#4 in figure
"SecondaryHostChainInterface(pdgB_r2)";
}
}
}

Figure 73. Schematic of MemoryBISR Inside the C2 Tile

Tessent™ Shell User’s Manual 321

Tessent Shell Workflows
SSN and EDT Insertion in Tiles Without TAP and BISR Controllers

SSN and EDT Insertion in Tiles Without TAP and BISR

Controllers
The next step in the tiling flow is insertion of logic test instruments such as EDT and SSN.
Insert two EDT controllers in each tile: one for internal mode and another for external mode. Usually,
these two modes use different numbers of scan channels and lengths and numbers of scan chains. So,
each mode requires a dedicated controller to achieve adequate compression.
Any DFT signal required for logic test that has not been included in the previous steps must be added at
this step. Such signals include int_ltest_en and ext_ltest_en. For more information on how to insert SSN
network in a tile-based design, refer to Example 3 in DftSpecification/SSN in the Tessent Shell Reference
Manual.
The clock multiplexers for output clocks are also inserted in this step. Refer to “Timing of Tile-To-Tile
Connections” on page 304 for more information.
The following example adds clock multiplexers to bypass local OCC in internal test mode:

add_dft_clock_mux clkc_to_1 -dft_signal int_ltest_en \

‑test_clock_source clkc
add_dft_clock_mux clkc_to_2 -dft_signal int_ltest_en \
‑test_clock_source clkc

This example shows the commands to add DFT signals in logic test:

add_dft_signals int_edt_mode ext_edt_mode

add_dft_signals ltest_en int_ltest_en ext_ltest_en
# ssn_en is required when the tile has auxiliary ports for SSN
add_dft_signals ssn_en
# Use the following only if memory BIST was inserted in a previous pass
add_dft_signals memory_bypass_en
tck_occ_en

The following code is the DftSpecification to insert EDTs for internal and external modes:

EDT {
ijtag_host_interface : Sib(edt);
Controller(c1_int) {
longest_chain_range : 10, 50;
scan_chain_count : 15;
input_channel_count : 4;
output_channel_count : 3;
Connections {
mode_enables : DftSignal(int_edt_mode);
}
}
Controller(c1_ext) {
longest_chain_range : 10, 50;
scan_chain_count : 3;
input_channel_count : 1;
output_channel_count : 1;
Connections {

322 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
SSN and EDT Insertion in Tiles Without TAP and BISR Controllers
mode_enables : DftSignal(ext_edt_mode);
}
}
}

The SSN network inserted in the C1 tile does not require any SSN bus multiplexing or SSN extra output
paths. The network begins with the receiver input pipeline stage, followed by SSH, and ends at the
output pipeline stage. You can use the DftSpecification from the following code sample to insert the SSN
network:

read_config_data -in_wrapper $spec ‑from_string {

SSN {
ijtag_host_interface : Sib(ssn);
DataPath(1) {
output_bus_width : 4;
Pipeline(1) {
}
ScanHost(1) {
OnChipCompareMode {
present: on;
}
}
Receiver1xPipeline(in) {
}
}
}
}

The following figure shows the inserted SSN network:

Figure 74. Schematic of SSN Network Inserted in the C1 Tile

The SSN network inserted in the C2 tile has multiplexers to include or exclude neighboring tiles from the
SSN datapath. The following example DftSpecification inserts an SSN network in the C2 tile:

Tessent™ Shell User’s Manual 323

Tessent Shell Workflows
SSN and EDT Insertion in Tiles Without TAP and BISR Controllers

SSN {
ijtag_host_interface : Sib(ssn);
DataPath(1) {
output_bus_width : 4;
// 1 in Figure
Pipeline(1) {
}
// 2 in Figure
ScanHost(1) {
}
// 3 in Figure
Multiplexer (from_r2) {
Connections {
secondary_bus_data_in : r2_ssn_from_bus _out[3:0];
}
}
// 4 in Figure
Multiplexer (from_r1) {
Connections {
secondary_bus_data_in : r1_ssn_from_bus_out[3:0];
}
// 5 in Figure
ExtraOutputPath {
Connections {
bus_clock_out : r2_ssn_to_bus_clock;
bus_data_out : r2_ssn_to_bus_data_in[3:0];
}
pipeline (r2) {
}
}
}
// 6 in Figure
Receiver1xPipeline (in) {
//7 in Figure
ExtraOutputPath {
Connections {
bus_clock_out : r1_ssn_to_bus_clock;
bus_data_out : r1_ssn_to_bus_data_in[3:0];
}
pipeline (r1) {
}
}
}
}
}

The following figure shows the schematic of the SSN network in the C2 tile:

324 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Scan Insertion and Scan Modes in Tiles Without TAP and BISR Controllers

Figure 75. Schematic of C2 Tile With SSN Network Inserted

Scan Insertion and Scan Modes in Tiles Without TAP and

BISR Controllers
For tiles without a TAP or BISR controller, you should create at least two scan modes in each tile: internal
and external.
The internal patterns from tiles are retargeted later in the tiling flow. You can combine the internal patterns
into a single pattern that simultaneously tests internal modes in all tiles. Scan isolation between tiles
enables simultaneous testing. After package integration, create patterns for external modes to test tile-
to-tile connections. Perform wrapper cell analysis to provide scan isolation for the tile. During scan mode
creation, specify the dedicated EDT instance name using the add_scan_mode command.
Run scan insertion with the insert_test_logic command. After scan insertion, change the context to
patterns -scan, then import the internal scan mode, and run the check_design_rules command to start
DRC before ATPG.
The following code example shows scan insertion in the C1 tiles and verification before ATPG. In the
basic DRC check, the severity of the E5 rule that checks for the possible capture of "X" into scan chains,
is modified to an error. Successful scan isolation removes E5 violations and any sources of "X" within
your logic.

Tessent™ Shell User’s Manual 325

Tessent Shell Workflows
Patterns Generation in Tiles Without a TAP Controller

# Scan insertion step

analyze_wrapper_cells
add_scan_mode int_edt_mode ‑edt_instances c1_rtl3_tessent_edt_c1_int_inst
add_scan_mode ext_edt_mode ‑edt_instances c1_rtl3_tessent_edt_c1_ext_inst
analyze_scan_chains
insert_test_logic

# Scan mode verification and scan graybox generation step

set_context patterns -scan

# To ensure that there are no sources of X left over in both internal and
external modes
set_drc_handling E5 error
import_scan_mode int_edt_mode
check_design_rules
set_system_mode setup
import_scan_mode ext_edt_mode
#Enable boundary scan isolation
#Only if ebscan segments are present in the tile
set_static_dft_signal_values bscan_input_isolation_enable 1
set_static_dft_signal_values output_pad_disable 1
check_design_rules
analyze_graybox
write_design -tsdb -graybox

After scan insertion, you must generate scan graybox and IJTAG graybox views. Generate these
views after importing external test mode. To generate the IJTAG graybox, you can refer to the following
example:

# IJTAG graybox generation step

set_context patterns -ijtag
set_system_mode analysis
analyze_graybox -ijtag
write_design -tsdb -graybox ‑verbose

Patterns Generation in Tiles Without a TAP Controller

In the patterns generation step, you generate patterns for internal modes. You must generate the external
mode patterns after chip integration. External mode patterns are not retargeted to chip level.
However, you can generate and simulate some external patterns for stand-alone tile verification. We
recommend that you create and verify some external mode patterns. At a minimum, you must create a
dedicated external ATPG mode. The results of internal pattern generation must be saved in a TSDB to
enable reuse after design integration.
To create a dedicated ATPG mode:

1. Import the internal scan mode.

2. Change the setup of the DFT instruments, such as OCCs or DftSignals, if necessary, to meet the
requirements.

326 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Patterns Generation in Tiles Without a TAP Controller

3. Use the set_current_mode <name> ‑type internal command to set a new name for the current
ATPG mode.

Note:
All scan modes must be of "internal" type. This means that logic test responses are
captured to scan chains only, and there is no external capture of ports from the tester side,
except for SSN bus outputs. The external scan mode used to detect faults on tile-to-tile
connections must be declared as "internal".

4. Save the ATPG mode and pattern data for future retargeting using the write_tsdb_data command.
The following code imports the internal scan mode, generates patterns for the internal mode, and then
saves them. In this example, the Tcl script (../utilities/write_testbenches.tcl) to automate writing patterns
is used. It invokes the write commands multiple times to save commonly used pattern sets. You can also
save the patterns using the write_patterns command.

import_scan_mode int_edt_mode -fast_capture_mode off -verbose

set_core_instance_parameters -instrument_type occ \
-parameter_values {capture_window_size 3}
set_current_mode int_edt_mode_stuck -type internal

check_design_rules
set_fault_type stuck
create_patterns
write_tsdb_data -replace

set param_list {SIM_TOP_NAME TB SIM_COMPARE_SUMMARY 1}

# source ../utilities/write_testbenches.tcl
# Either use the Tcl script above or use write_patterns command calls as
shown below

write_patterns patterns/parallel.v \
-serial -verilog -replace \
-param_list $param_list \
-generate_info_file_dictionary on \
-pattern_sets scan
write_patterns patterns/loopback.v \
-serial -verilog -replace \
-param_list $param_list \
-generate_info_file_dictionary on \
-pattern_sets ssn_loopback

The generation of external mode patterns is almost identical to the generation of internal mode patterns.
The following code example generates an external scan mode and patterns for it. After importing scan
mode ext_edt_mode, two signals to provide scan isolation are set to 1, and then specify the ATPG mode
using the set_current_mode command. Run the write_tsdb_data command after check_design_rules to
save the ATPG mode in the Tessent Shell Database (TSDB).

Tessent™ Shell User’s Manual 327

Tessent Shell Workflows
Verification and Simulations

import_scan_mode ext_edt_mode -fast_capture_mode off -verbose

# Isolate the PIs equipped with bscan in external mode
# IOs are tested in the BoundaryScan test
# Allow keeping SSN in internal capture mode when testing the paths between
the tiles.

set_static_dft_signal_values bscan_input_isolation_enable 1
set_static_dft_signal_values output_pad_disable 1

set_current_mode ext_edt_mode_stuck -type external

check_design_rules

set_fault_type stuck
set_atpg_limit -p 128
create_patterns

write_tsdb_data -replace

write_patterns patterns/parallel.v \
-serial -verilog -replace \
-param_list $param_list \
-generate_info_file_dictionary on \
-pattern_sets scan

write_patterns patterns/loopback.v \
-serial -verilog -replace \
-param_list $param_list \
-generate_info_file_dictionary on \
-pattern_sets ssn_loopback

During pattern generation, you can import the saved ATPG modes from the TSDB using the
add_core_instances command. The values of any required signals and other settings related to the
imported ATPG modes are also automatically restored. Refer to the code example in Tile-to-Tile Test at
the Package Level where the external ATPG modes of the tiles are used to configure the internal ATPG
modes of the chip.
For transition faults, you must generate dedicated ATPG scan modes and patterns again. The Tessent
Shell scripts to generate these patterns are similar. However, you must create the ATPG mode using an
additional switch -fast_capture_mode on and use the set_fault_type command to set the fault type to
transition.

Verification and Simulations

Run the verification simulations when a set of tile patterns is ready.

Note:
The run_testbench_simulations command is used to simulate the created ATPG patterns, as
explained in “ATPG-Based Testbench Simulation” on page 329.

328 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Embedded Boundary Scan Insertion in Tiles With a TAP Controller

ICL-Based Testbench Simulation

Generate the ICL-based patterns in the patterns ‑ijtag context. Read the core in the interface view. The
run_testbench_simulations command generates the PatternsSpecification with a default set of patterns
including ICL verification, MemoryBIST, MemoryBISR, and SSN continuity patterns.
The following code sample generates the ICL-based patterns and runs the related simulations:

set_context patterns -design_id gate -no_rtl

read_design c2 -view interface
set_current_design c2

set spec [create_patterns_specification]

process_patterns_specification

set_simulation_library_sources \
-Y ../../library/macros/ -extensions {v} \
-V ../../library/cells/adk.v

run_testbench_simulations

ATPG-Based Testbench Simulation

The run_testbench_simulations command can simulate the ATPG patterns. To use this command, set
the context to patterns ‑scan (set_context patterns ‑scan). You must also provide the file paths to the
testbenches generated during the ATPG step. Use the create_patterns_specification command, with the
‑testbench_files switch to pass the file paths.
The following code example is a Tessent Shell script to run verification testbenches:

# Create a list of testbenches

# Tcl glob function can search for files matching the pattern
set tb_file_list [lsort -dictionary [glob ${tb_dir}/${td_prefix}*.v]]
set spec [create_patterns_specification -testbench_files $tb_file_list]
process_patterns_specification
set_simulation_library_sources \
-v ../../library/cells/adk.v \
-y ../../library/macros -extension v
run_testbench_simulations

Embedded Boundary Scan Insertion in Tiles With a

TAP Controller
The presence of a TAP controller affects the boundary scan insertion in a tile. Inserting Tessent Boundary
Scan auxiliary logic enables the reuse of functional ports as SSN bus ports.
For performing embedded boundary scan, there must be a design hierarchy around the pad IO cells
where you insert embedded boundary scan. If a dedicated container for pads does not exist in the tile
where TAP is inserted, then you must create it. In this example, pads in the C3 tile are split into two
groups. So create two modules, C3_top_pads and C3_bottom_pads, and insert embedded boundary
scan in each module. The DFT insertion in these modules makes them an embedded boundary scan
segment with logic test support that can integrate into a bigger boundary scan chain.

Tessent™ Shell User’s Manual 329

Tessent Shell Workflows
Embedded Boundary Scan Insertion in Tiles With a TAP Controller

Insert embedded boundary scan logic using the set_design_level sub_block command. This connects
the inserted DFT signals to the newly created ports. Refer to Example 1 in HostBScanInterface in the
Tessent Shell Reference Manual for more details on how the HostBscanInterface wrapper assembles
the boundary scan chain in C3. The bscan_inout_isolation_enable DFT signal is required to reuse the
embedded boundary scan segments as scan isolation during logic test in external mode. The IJTAG
graybox views for these modules are created automatically during ICL extraction as described in
“Creation of IJTAG Graybox” on page 310.
The following code example shows the commands to create the required DFT signals:

add_dft_signal bscan_input_isolation_enable output_pad_disable

add_dft_signal tck_occ_en ext_ltest_en ltest_en

add_dft_signal scan_en -source_node ltest_scan_en

add_dft_signal shift_capture_clock -source_node shift_capture_clock

Figure 76. Embedded Boundary Scan Segment With Logic Test Support Ready for Integration

When the blocks with pads are complete, then perform the insertion of TAP and boundary scan logic to
access other tiles. The IJTAG graybox views of the dedicated containers with pads (bottom pads and
top pads modules) must be read in the next steps. Because the design_level is set to physical_block,
you must force the insertion of the TAP interface using the set_dft_specification_requirements
‑host_scan_interface_type tap command (tap is the default type when design_level is chip).
The following code shows the setup used to integrate embedded boundary scan in the C3 tile:

set_context dft -rtl -design_id rtl1

# Read extra Verilog files

read_verilog …

# Read pad containers using the ijtag_graybox view

330 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Embedded Boundary Scan Insertion in Tiles With a TAP Controller
read_design c3_top_pads -view ijtag_graybox
read_design c3_bottom_pads -view ijtag_graybox
set_current_design c3
set_design_level physical_block

# Force insertion of the TAP

set_dft_specification_requirement -host_scan_interface_type tap
check_design_rules

Use DftSpecification to perform the integration of embedded boundary scan segments with TAP and
insertion of boundary scan logic. The following code sample shows the modifications to the default
specification:

set spec [create_dft_specification]

set tap_wrapper ${spec}/IjtagNetwork/HostScanInterface(tap)/Tap(main)

# Modify the TAP client if required

read_config_data -in $tap_wrapper -from_string {
DeviceIDRegister {
version_code : 4'h0;
manufacturer_id_code : 11'h0;
part_number_code : 16'h0;
}
}
# Integration of boundary scan logic
read_config_data -in $spec -from_string {
EmbeddedBoundaryScan {
HostBscanInterface(tap) {
Interface {
ijtag_host_interface : Tap(main)/HostBscan;
}
EBScanPipeline(from_right) {
}
SecondaryEBScanInterface(right) {
}
EBScanPipeline(to_right) {
}
EBScanInstance(top_pads) {
}
EBScanPipeline(from_left) {
}
SecondaryEBScanInterface(left) {
}
EBScanPipeline(to_left) {
}
EBScanInstance(bottom_pads) {
}
}
}
}

This code sample shows the detailed description of the specification used to integrate boundary scan in
the C3 tile:

Tessent™ Shell User’s Manual 331

Tessent Shell Workflows
Embedded Boundary Scan Insertion in Tiles With a TAP Controller

EmbeddedBoundaryScan {
HostBscanInterface(tap) {
Interface {
ijtag_host_interface :
Tap(main)/HostBscan;
}
EBScanPipeline(from_right) {
}
SecondaryEBScanInterface(right) {
}
EBScanPipeline(to_right) {
}
// 2 in Figure
EBScanInstance(top_pads) {
}
// 3 in Figure
EBScanPipeline(from_left) {
}
SecondaryEBScanInterface(left) {
}
EBScanPipeline(to_left) {
}
EBScanInstance(bottom_pads) {
}
}
}

332 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Embedded Boundary Scan Insertion in Tiles With a TAP Controller

Figure 77. Schematic After Boundary Scan Insertion in the C3 Tile

Early Boundary Scan Verification

A BSDL file is required to generate the patterns, but the tool cannot infer the entire boundary scan
network from the C3 tile scope.
Verify the inserted logic by adding loopbacks to unconnected SecondaryEBScanInterfaces and extracting
a dummy BSDL file to generate the patterns.

Note:
This is not a mandatory step but helps in early verification of the boundary scan network at the tile
level. You can also verify the boundary scan network after the integration of tiles at the chip level.

The following Tessent Shell script is used to add loopbacks, extract a fake BSDL file, generate patterns,
and simulate the generated patterns:

# Close the host bscan scan interfaces and extract the fake BSDL file for
C3 for early verification
foreach bscan_host {left right} {
lappend inputs [get_ports ${bscan_host}_bscan_from_scan_out]
lappend outputs [get_ports ${bscan_host}_bscan_to_scan_in]
}
add_loadboard_loopback_pairs -inputs $inputs -outputs $outputs
set_flat_model_options -emulate_loadboard_loopback_pairs on

Tessent™ Shell User’s Manual 333

Tessent Shell Workflows
IJTAG Network Insertion in Tiles With a TAP Controller
# Extract BSDL file from current design scope
set_dft_specification_requirements -bsdl_extraction on
set_boundary_scan_port_options -pad_io_ports [get_ports -filter \
equipped_with_bscan]
check_design_rules
# Generate the verification patterns
set_context patterns -IJTAG -rtl
set spec [create_patterns_specification -bscan_sim_views ijtag_graybox]
process_patterns_specification
set_simulation_library_sources \
-Y ../../library/macros/ -extensions {v} \
-V ../../library/cells/adk.v
run_testbench_simulations

IJTAG Network Insertion in Tiles With a TAP

Controller
The presence of a TAP affects the IJTAG insertion in a tile.
Similar to the C2 tile that is a host for two C1 tiles, the C3 tile requires additional host scan interfaces to
connect neighboring tiles. The Tile Client (TC) Segment Insertion Bit (SIB) is not required in the C3 tile
because there is a TAP controller instead. Insert the Tile Host Collector (THC) SIB in series with Scan
Resource Instrument (SRI) and Scan Test Instrument (STI) SIBs.
The following is used to generate the DftSpecification:

set spec [create_dft_specification /

-tile_ijtag_host_list {left right}]
report_config_data [get_config_value IjtagNetwork ‑in $spec]

Example 3 in IJTAG Network in the Tessent Shell Reference Manual to build the IJTAG network in the
tiling flow. The following example shows the DftSpecification to insert the IJTAG network in the C3 tile:

IjtagNetwork {
HostScanInterface(sti) {
Interface {
design_instance: c3_rtl1_tessent_sib_sri_inst;
scan_interface : client;
}
Sib(thc) {
Attributes {
tessent_dft_function : tile_host_collector;
}
}
Sib(th_right) {
to_scan_in_feedthrough : pipeline;
SecondaryHostScanInterface(right) {
}
Sib(th_left) {
to_scan_in_feedthrough : pipeline;
SecondaryHostScanInterface(left) {
}

334 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Memory BISR Insertion for Tiles With a BISR Controller
}
}
Sib(sti) { … }
}
}

The following figure shows the schematic of the inserted IJTAG network. You can insert the IJTAG
network with the MBIST and MBISR instruments simultaneously.

Figure 78. Schematic of IJTAG Network Inserted in C3 Tile

Memory BISR Insertion for Tiles With a BISR

Controller
The presence of a BISR controller in a tile affects the tiling flow. The insertion of a MemoryBIST and a
MemoryBISR logic must include an MBISR controller and a fusebox.
If you set the design_level to physical_block, the insertion of the MBISR controller is not on by
default. Enable the MBISR controller insertion using the set_dft_specification_requirements
-memory_bisr_controller on command. This inserted BISR controller has to access two power domains.
Therefore, you require additional host interfaces to host BISR chains in neighboring tiles. These
interfaces are specified using set_dft_specification_requirements ‑memory_bisr_host_list <host_list>.
The following code sample shows how the set_dft_specification_requirements command and its switches
are used during memory test insertion:

Tessent™ Shell User’s Manual 335

Tessent Shell Workflows
Memory BISR Insertion for Tiles With a BISR Controller

set_dft_specification_requirements \
-memory_test on \
-memory_bisr_controller on \
-design_type tile \
-memory_bisr_host_list {pdgA {pdgA_left pdgA_right} \
pdgB {pdgB_left pdgB_right}}

The part of the default DftSpecification that describes the memory test does not require any modifications.
Read in the DEF file with coordinates for memories and ports using the read_def command to generate
and stitch the BISR segments in layout-aware order. If the BISR segments are not in the correct order,
edit the generated bisr_segment_order_file before processing DftSpecification. You can print the
generated bisr_segment_order_file using the cat command.
For more information, refer to Example 3 in MemoryBisr/Secondary Host Chain Interface. The following
code example shows the contents of the bisr_segment_order_file generated for the C3 tile:

BisrSegmentOrderSpecification {
PowerDomainGroup(pdgA) {
OrderedElements {
"SecondaryHostChainInterface(pdgA_left)";
"SecondaryHostChainInterface(pdgA_right)";
}
}
PowerDomainGroup(pdgB) {
OrderedElements {
"SecondaryHostChainInterface(pdgB_left)";
"SecondaryHostChainInterface(pdgB_right)";
}
}
}

The following figure shows the inserted MBISR network:

336 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Memory BISR Insertion for Tiles With a BISR Controller

Figure 79. Schematic of Memory BISR Network Inserted in C3 Tile

You cannot calculate the length of the BISR chains from the scope of the C3 tile with the DftSpecification.
So you must set the repair_word_size and zero_counter_bist properties in the MemoryBisr/
Controller/AdvancedOptions wrapper using the set_config_value command.
The SDC input/output delay constraints for the SecondaryHostScanInterface BISR ports are derived from
a Tcl dictionary. The tessent_set_default_variables proc in the SDC file defines the bisr_shsi_delay Tcl
dictionary. This dictionary documents the default input/output delay percentages relative to their clocks
(functional or TCK). The following is an example of a bisr_shsi_delay dictionary:

set bisr_shsi_delay {
scan_in {
direction input
delay_pct {
Functional {
min 0.25
max 0.25
}
TCK {
min 0.25
max 0.25
}
}
}
scan_out {
direction output

Tessent™ Shell User’s Manual 337

Tessent Shell Workflows
SSN Insertion for Tiles With Primary SSN Ports
delay_pct {
Functional {
min 0.75
max 0.75
}
TCK {
min 0.75
max 0.75
}
}
}
to_shift_en {...}
MemoryDisable {...}
Select {...}
Reset {...}
}

We recommend using the default values. However, you can specify different values before running the
tessent_set_non_modal SDC procedure, as follows:
dict set bisr_shsi_delay <SignalName> delay_pct {Functional|TCK} {min|max} <value>

For example, the maximum delay for the to_shift_en signal can be set to 23% (instead of 25%) for TCK
(IJTAG) mode:
dict set bisr_shsi_delay to_shift_en delay_pct TCK max 0.23

SSN Insertion for Tiles With Primary SSN Ports

Inserting Tessent Boundary Scan auxiliary logic enables the reuse of functional ports as SSN bus ports.
The SSN network insertion in the C3 tile is similar to that of a tile without SSN primary bus ports.
For more information on auxiliary logic insertion, refer to “Embedded Boundary Scan Insertion in Tiles
With a TAP Controller” on page 329.
The SSN insertion step requires one additional DFT signal ssn_en to enable auxiliary logic in embedded
boundary scan segments connected to the SSN bus. The SSN network in the C3 tile needs access to the
SSH nodes on its left and right sides. Therefore, you need two multiplexers on the data path. The default
data path configuration (after reset) does not include any neighboring tiles. For detailed information on
how to insert the SSN network in a tile-based design, refer to Example 3 in DftSpecification/SSN in the
Tessent Shell Reference Manual.

SSN {
ijtag_host_interface : Sib(ssn);
DataPath(1) {
output_bus_width : 4;
Connections {
bus_clock_in : core_data_in[4];
bus_data_in : core_data_in[3:0];
bus_data_out : core_data_out[3:0];
}
# 1 in figure
Pipeline(1) {
}
# 2 in figure

338 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
SSN Insertion for Tiles With Primary SSN Ports
ScanHost(1) {
}
# 3 in figure
Multiplexer (from_left) {
Connections {
secondary_bus_data_in : left_ssn_from_bus_data_out[3:0];
}
}
# 4 in figure
Multiplexer (from_right) {
Connections {
secondary_bus_data_in : right_ssn_from_bus_data_out[3:0];
}
ExtraOutputPath {
Connections {
bus_clock_out : left_ssn_to_bus_clock;
bus_data_out : left_ssn_to_bus_data_in[3:0];
}
# 5 in figure
pipeline (left) {
}
}
}
# 6 in figure
pipeline (in) {
ExtraOutputPath {
Connections {
bus_clock_out : right_ssn_to_bus_clock;
bus_data_out : right_ssn_to_bus_data_in[3:0];
}
# 7 in figure
pipeline (right) {
}
}
}
}
}

The following figure is the schematic of the SSN network in the C3 tile. The path in red is a default SSN
data path after reset:

Tessent™ Shell User’s Manual 339

Tessent Shell Workflows
Scan Insertion and Scan Modes for Tiles With Promoted OCCs

Figure 80. Schematic of SSN Network in the C3 Tile

Scan Insertion and Scan Modes for Tiles With

Promoted OCCs
The scan insertion process in the C3 tile is almost identical to scan insertion in the C1 and C2 tiles. The
difference between the two processes is that you must include OCC chains in external scan mode.
These chains are required for proper clocking. For more information, refer to “Clock Control in External
Mode” on page 303.
The following code shows how the add_scan_mode command creates external scan mode in the C3 tile.
To control the clocks, OCC chains must be a part of this scan mode:

# Promote clkc OCC to external mode as there is

# no OCC outside the tile.
add_scan_mode ext_edt_mode \
-edt_instances c3_rtl3_tessent_edt_c1_ext_inst \
-include_elements [add_to_collection \
[get_scan_element -class wrapper] \
[get_scan_element *tessent_occ_clkc*]]

ATPG pattern generation is not dependent on the presence of test instruments and is similar for all the
tiles.

340 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Scan Insertion and Scan Modes for Tiles With Promoted OCCs

Refer to Patterns Generation in Tiles Without a TAP Controller to perform pattern generation.

Tessent™ Shell User’s Manual 341

Tessent Shell Workflows
Chip-Level Integration for the Tiling Flow

Chip-Level Integration for the Tiling Flow

When all the tiles are ready and verified stand-alone, you can integrate them onto the chip.
The following sections provide information on how you must integrate tiles into a single chip, generate tile-
to-tile patterns, and retarget internal mode tile patterns.

BSDL File Extraction

IJTAG-Based Verification Patterns
Tile-Level Patterns Retargeting
Tile-to-Tile Test at the Package Level

BSDL File Extraction

You require a BSDL file to generate correct patterns for the boundary scan network. Typically, you can
generate the BSDL file during the insertion of the boundary scan with TAP. However, in the tiling flow the
boundary scan segments may be placed in different tiles and the entire boundary scan chain is traceable
only after chip-level integration. So, you must use the BSDL extraction feature to generate a chip-level
BSDL file.
Read in the ijtag_graybox views of all tiles and then extract the ICL file using extract_icl ‑write_in_tsdb on.
This creates a TSDB directory for the integrated chip that can be read in the next steps.
Perform the BSDL extraction using the set_dft_specification_requirements ‑bsdl_extraction on command.
The check_design_rules command triggers the process of BSDL extraction, and your result file is saved
in the TSDB directory.
The following code example shows a Tessent script to extract integrated ICL and BSDL:

set_context dft -rtl -design_id rtl1

# Read libraries, macros
read_verilog ../../design/chip/chip.v_with_dft_port
…
# Read designs in ijtag_graybox view
read_design c1 -view ijtag_graybox
read_design c2 -view ijtag_graybox
read_design c3 -view ijtag_graybox
read_design c3_bottom_pads -view ijtag_graybox
read_design c3_top_pads -view ijtag_graybox
set_current_design chip
set_design_level chip
extract_icl -write_in_tsdb on
### Extract the chip level BSDL file
set_dft_specification_requirements -bsdl_extraction on
set_attribute_value [get_port bisr_prog_voltage] -name function \
‑value power
check_design_rules

342 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
IJTAG-Based Verification Patterns

IJTAG-Based Verification Patterns

The verification of IJTAG-based patterns is performed after the ICL and the BSDL extraction. The BSDL
file is used to generate the boundary scan patterns.
The PatternsSpecification creation must take lower physical blocks (tiles) into account. The set of
generated patterns includes ICL Verification, MemoryBist, MemoryBISR, and SSN continuity patterns.
The following code sample shows a Tessent script to generate IJTAG-based patterns:

set_defaults_value -in_wrapper /PatternsSpecification/SignoffOptions/ \

simulate_instruments_in_lower_physical_instances on
set spec [create_patterns_specification -bscan_sim_views ijtag_graybox]
report_config_data $spec
process_patterns_specification
set_simulation_library_sources -y ../../library/macros -extension v \
-v ../../library/cells/adk.v
run_testbench_simulations

Tile-Level Patterns Retargeting

To perform pattern retargeting, you must do a set of operations on each tile.

• Read in the Tessent core instance (add_core_instances).

• Define the setup for SSN multiplexing and concatenate it with the test setup procedure
(set_test_setup_icall).

• Define the set of functional clocks in case of transition patterns (for stuck patterns use test_clock).

• Read in the pattern file generated during internal mode ATPG.

You must set the MemoryBISR controller to not disturb the BISR logic in tiles; MBISR logic is under test
during internal modes.
We recommend that you use a "retargeting dictionary" that helps manage the pattern retargeting. A
retargeting dictionary is a Tcl dictionary with basic information about retargeting modes.
The following code shows a part of a retargeting dictionary that defines the "all_stuck" test pattern that is
retargeting stuck patterns from all tiles:

all_stuck {
instances {
c1_i1 {
mode_name int_edt_mode_stuck
fault_type stuck
}
c1_i2 {
mode_name int_edt_mode_stuck
fault_type stuck
}
c1_i3 {

Tessent™ Shell User’s Manual 343

Tessent Shell Workflows
Tile-Level Patterns Retargeting
mode_name int_edt_mode_stuck
fault_type stuck
}
c1_i4 {
mode_name int_edt_mode_stuck
fault_type stuck
}
c2_i1 {
mode_name int_edt_mode_stuck
fault_type stuck
}
c2_i2 {
mode_name int_edt_mode_stuck
fault_type stuck
}
c3_i1 {
mode_name int_edt_mode_stuck
fault_type stuck
}
}
ssn_muxes {
c2_i1.c2_rtl3_tessent_ssn_mux_from_r1_inst.setup
c2_i1.c2_rtl3_tessent_ssn_mux_from_r2_inst.setup
c2_i2.c2_rtl3_tessent_ssn_mux_from_r1_inst.setup
c2_i2.c2_rtl3_tessent_ssn_mux_from_r2_inst.setup
c3_i1.c3_rtl3_tessent_ssn_mux_from_left_inst.setup
c3_i1.c3_rtl3_tessent_ssn_mux_from_right_inst.setup
}
}

Figure 81 shows the SSN network configuration for the all_stuck mode. The active data path is marked in
red. The red multiplexers require reconfiguration; ICL instances of these multiplexers are listed under the
ssn_muxes key in the retargeting dictionary.

344 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Tile-Level Patterns Retargeting

Figure 81. Schematic of the SSN Network Configured

for Retargeting of Internal Stuck Patterns for All Tiles

The following code shows part of the dictionary for single-tile retargeting of transition patterns:

c1_i2_tdf {
instances {
c1_i2 {
mode_name int_edt_mode_tdf
fault_type transition
}
}
ssn_muxes {
c2_i1.c2_rtl3_tessent_ssn_mux_from_r2_inst.setup
c3_i1.c3_rtl3_tessent_ssn_mux_from_left_inst.setup
}
}

Figure 82 shows the SSN Network configuration for this mode. You do not need to reconfigure the
multiplexers marked in black but those marked in red need reconfiguring. The setup procedures related to
the ICL instances of these multiplexers are listed under the ssn_muxes dictionary key.

Tessent™ Shell User’s Manual 345

Tessent Shell Workflows
Tile-Level Patterns Retargeting

Figure 82. Schematic of SSN network Configured for

Retargeting of Internal Transition Patterns for Single C1_i2 Tile

The retargeting dictionary must be processed during the Tessent setup phase.

Tip
We recommend using the automated script attached to the demonstration test case. The script
reads the dictionary, performs the Tessent setup, and saves the retargeted pattern. Contact your
Siemens representative for more information.

The following code is from a sample dofile that operates on the retargeting dictionary:

foreach retargeting_mode_name [dict keys $retarget_dict $mode_filter] {

# Set the name for new retargeting mode, use name from retargeting
dictionary
set_current_mode $retargeting_mode_name
# Apply the required scan mode to the core instances
set instances [dict keys [dict get $retarget_dict \
$retargeting_mode_name instances]]
foreach instance $instances {
add_core_instances -instances $instance \
-mode [dict get $retarget_dict $retargeting_mode_name \
instances $instance mode_name]
}

# Apply setting of ssn datapath muxes

foreach ssn_mux [dict get $retarget_dict $retargeting_mode_name \
ssn_muxes] {
set_test_setup_icall [list $ssn_mux select_secondary_bus 1] \
-append ‑merge
}

# Add functional clocks in case of Transition Delay Faults

if {[dict get $retarget_dict $retargeting_mode_name instances \
$instance fault_type] eq "transition"} {

346 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Tile-Level Patterns Retargeting
if {$retargeting_mode_name in {c3_i1_tdf all_tdf}} {
add_clocks bisr_clock -period 20ns
}
add_clocks clkc -period 10ns
if {$retargeting_mode_name eq "all_tdf" || [regexp {^c1.*_tdf$} \
$retargeting_mode_name]} {
add_clocks clk_ref_1 -period 10ns
add_clocks clk_ref_2 -period 10ns
add_clocks clk_ref_3 -period 10ns
add_clocks clk_ref_4 -period 10ns
}
}

# These settings force the BISR controller not to disturb the BISR chains
set_static_dft_signal_values -icl_instance c3_i1 ltest_en 1
if {$retargeting_mode_name ni {c3_i1_tdf all_tdf}} {
add_input_constraints bisr_clock -c0
}

# Change mode to ANALYSIS

check_design_rules

# Read core faults from instances for retargeting

foreach instance $instances {
read_patterns -instance $instance \
-mode [dict get $retarget_dict $retargeting_mode_name \
instances $instance mode_name] \
-fault_type [dict get $retarget_dict $retargeting_mode_name \
instances $instance fault_type]
}

# Write consolidated faults

write_tsdb_data -replace

# Write testbenches (patterns)

set testbench_type retargeting
source ../../utilities/write_testbenches.dofile

# Restore tool to setup for next retargeting dict entry

set_system_mode setup
reset_design
}

On completion, the design state is reset to start the next retargeting.

If you do not use the retargeting dictionary flow, you can use the following set of commands to retarget
the TDF patterns on the C1_i2 instance:

set_context patterns -scan_retargeting

…
read_design c1 -view ijtag_graybox
read_design c2 -view ijtag_graybox
read_design c3 -view ijtag_graybox
set_current_design chip

Tessent™ Shell User’s Manual 347

Tessent Shell Workflows
Tile-Level Patterns Retargeting
…
set_current_mode c1_i2_tdf
add_core_instances -instances c1_i2 -mode int_edt_mode_tdf
set_test_setup_icall \
"c2_i1.c2_rtl3_tessent_ssn_mux_from_r2_inst.setup \
select_secondary_bus 1" -append -merge set_test_setup_icall \
"c3_i1.c3_rtl3_tessent_ssn_mux_from_left_inst.setup \
select_secondary_bus 1" -append -merge
add_clocks bisr_clock -period 20ns
add_clocks clkc -period 10ns
add_clocks clk_ref_1 -period 10ns
add_clocks clk_ref_2 -period 10ns
add_clocks clk_ref_3 -period 10ns
add_clocks clk_ref_4 -period 10ns
set_static_dft_signal_values -icl_instance c3_i1 ltest_en 1
check_design_rules
read_patterns -instance c1_i2 -mode int_edt_mode_tdf -fault_type
transition
write_tsdb_data -replace
write_patterns chip_retargeting.testbenches/chip_c1_i2_tdf_parallel.v \
-verilog -replace -pattern_sets scan
write_patterns chip_retargeting.testbenches/chip_c1_i2_tdf_loopback.v \
-serial -verilog -replace -pattern_sets ssn_loopback
write_patterns chip_retargeting.testbenches/chip_c1_i2_tdf_serial_chain.v \
-verilog -serial -replace -pattern_sets chain
write_patterns chip_retargeting.testbenches/chip_c1_i2_tdf_serial_scan.v \
-verilog -serial -replace -pattern_sets scan
set_system_mode setup
reset_design

Create the PatternSpecification for the ATPG testbenches using the create_patterns_specification
command with the -testbench_files switch and provide a list of written patterns.

create_patterns_specification -replace -testbench_files { \

chip_retargeting.testbenches/chip_c1_i2_tdf_loopback.v \
chip_retargeting.testbenches/chip_c1_i2_tdf_parallel.v \
chip_retargeting.testbenches/chip_c1_i2_tdf_serial_chain.v \
chip_retargeting.testbenches/chip_c1_i2_tdf_serial_scan.v \
}

Simulating the retargeted patterns is automated with the PatternsSpecification flow. The ‑testbench_files
switch ensures that the simulator compiles and uses the correct design view for each child block of the
design.
The following code shows the created PatternsSpecification:

PatternsSpecification(chip,gate,c1_i2_tdf_signoff) {
Patterns(chip_c1_i2_tdf_loopback) {
SimulationOptions {
LowerPhysicalBlockInstances {
c1_i2 : full;
c2_i1 : ijtag_graybox;
c3_i1 : ijtag_graybox;
}

348 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Tile-Level Patterns Retargeting
}
TestbenchVerify(1) {
testbench_file_name : \
chip_retargeting.testbenches/chip_c1_i2_tdf_loopback.v;
}
}
Patterns(chip_c1_i2_tdf_parallel) {
SimulationOptions {
LowerPhysicalBlockInstances {
c1_i2 : full;
c2_i1 : ijtag_graybox;
c3_i1 : ijtag_graybox;
}
}
TestbenchVerify(1) {
testbench_file_name : \
chip_retargeting.testbenches/chip_c1_i2_tdf_parallel.v;
}
}
Patterns(chip_c1_i2_tdf_serial_chain) {
SimulationOptions {
LowerPhysicalBlockInstances {
c1_i2 : full;
c2_i1 : ijtag_graybox;
c3_i1 : ijtag_graybox;
}
}
TestbenchVerify(1) {
testbench_file_name : \
chip_retargeting.testbenches/chip_c1_i2_tdf_serial_chain.v;
}
}
Patterns(chip_c1_i2_tdf_serial_scan) {
SimulationOptions {
LowerPhysicalBlockInstances {
c1_i2 : full;
c2_i1 : ijtag_graybox;
c3_i1 : ijtag_graybox;
}
}
TestbenchVerify(1) {
testbench_file_name : \
chip_retargeting.testbenches/chip_c1_i2_tdf_serial_scan.v;
}
}
}

Note:
The core C2_i1 and C3_i1 design views are set as IJTAG grayboxes because this view is
sufficient for simulating the internal mode scan patterns of the C1_i2 core.

Process the PatternsSpecification and run testbench simulations.

Tessent™ Shell User’s Manual 349

Tessent Shell Workflows
Tile-to-Tile Test at the Package Level

process_patterns_specification
set_simulation_library_sources -v ../data/adk.lib/verilog/adk.v -y ../data/mems -extension v
run_testbench_simulations

Tile-to-Tile Test at the Package Level

The generation of tile-to-tile connection pattern is similar to the retargeting of internal modes for all tiles.
To test all the tiles, you must read in the accurate core descriptions and reconfigure the SSN network to
consider all the tiles. The SSN network configuration is similar to all_stuck or all_tdf patterns, as shown in
Figure 81 on page 345.
Capture the responses from the scan pattern to scan chains only (internal capture) because the primary
inputs and outputs get checked during boundary scan verification patterns. To do this, set the scan mode
type to internal using the set_current_mode ‑type internal command.
The following code example shows how a new name for mode is set here:

set_context patterns -scan

# Read design prerequisites like libraries and extra Verilog files
…
read_design chip
read_design c1 -view scan_graybox
read_design c2 -view scan_graybox
read_design c3 -view scan_graybox
set_current_design chip
add_core_instances -instances [get_instances * -of_module c1] \
-mode ext_edt_mode_stuck
add_core_instances -instances [get_instances * -of_module c2] \
-mode ext_edt_mode
add_core_instances -instances [get_instances * -of_module c3] \
-mode ext_edt_mode_stuck
# Using boundary Scan to isolate the chip from the outside
# Only covers tile-to-tile logic
# PIs/POs tested with boundary scan test
set_current_mode ext_edt_mode_stuck -type internal

foreach ssn_mux {
c2_i1.c2_rtl3_tessent_ssn_mux_from_r1_inst \
c2_i1.c2_rtl3_tessent_ssn_mux_from_r2_inst \
c2_i2.c2_rtl3_tessent_ssn_mux_from_r1_inst \
c2_i2.c2_rtl3_tessent_ssn_mux_from_r2_inst \
c3_i1.c3_rtl3_tessent_ssn_mux_from_left_inst \
c3_i1.c3_rtl3_tessent_ssn_mux_from_right_inst} {
set_test_setup_icall \
[list ${ssn_mux}.setup select_secondary_bus 1] ‑append -merge
}
check_design_rules
set_fault_type stuck
create_patterns
write_tsdb_data -replace

350 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Tile-to-Tile Test at the Package Level

write_patterns chip_atpg.testbenches/chip_ext_edt_mode_stuck_parallel.v \
-verilog -replace -pattern_sets scan

You can simulate saved patterns using run_testbench_simulations. Refer to the code sample in
Verification and Simulations.

Tessent™ Shell User’s Manual 351

Tessent Shell Workflows
Tessent Shell Post-Layout Validation Flow

Tessent Shell Post-Layout Validation Flow

Performing physical place and route on pre-layout netlists results in post-layout netlists you must validate
before you can proceed to tape-out.
This flow assumes that you are familiar with the pre-layout flows as described in Tessent Shell Flow for
Flat Designs and Tessent Shell Flow for Hierarchical Designs, especially as related to ATPG pattern
generation.

Overview of the Post-Layout Validation Flow

Soft Link TSDB and Post-Layout Netlist
Verify MemoryBIST, Boundary Scan, and IJTAG Patterns
Verifying the Scan-Inserted ATPG Patterns
Post-Layout Validation When You Have Ungrouped IJTAG/OCC/EDT Logic

Overview of the Post-Layout Validation Flow

You can validate the post-layout netlist for hierarchical core, hierarchical top, and flat chip-level designs.
As shown in the following figure, you must first generate a soft link in the TSDB that points to the post-
layout netlist. Then you verify the patterns for the MemoryBIST, boundary scan (if any) and IJTAG
network, followed by verifying the post-scan-inserted ATPG patterns.

Figure 83. Post-Layout Validation Flow

352 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Soft Link TSDB and Post-Layout Netlist

This flow assumes that within the post-layout netlist, modules exist for the IJTAG network and inserted
EDT and OCC instruments. That is, they remain distinct logical entities. Refer to Post-Layout Validation
When You Have Ungrouped IJTAG/OCC/EDT Logic if you have ungrouped (unpreserved) logic.

Soft Link TSDB and Post-Layout Netlist

The soft link enables Tessent Shell to access the post-layout netlist for validation purposes. You are
associating and linking the post-layout netlist (place-and-routed design) with all the pre-layout data files
such as the ICL, TCD, and PDL.

Prerequisites
• You have previously performed the pre-layout flow so that you have the post-scan inserted DFT
data files (ICL, PDL, TCD, and so on).

• You have a post-layout netlist as a result of place and route.

Procedure
1. Load the design, including the post-layout netlist (lines 1-16). Ensure that you specify a unique
design ID, such as "post_layout".

2. Add any black boxes, as applicable, and set the design level, which can be chip, physical_block, or
sub_block (lines 18-23).

3. Save the updated netlist (line 24). Ensure that you use the ‑softlink_netlist option with the
write_design command.
Using this switch references the post-layout netlist rather than copies it into the TSDB. This
prevents duplication and enables the post-layout netlist to be updated without the need to repeat
this step.

Examples
The following example generates an updated netlist for a wrapped core named processor_core that
includes a soft link to the core’s post-layout netlist.

1 set_context patterns -ijtag -design_id post_layout

2
3 # Set the location of the TSDB
4 set_tsdb_output_directory ../tsdb_core
5
6 # Read the Tessent Cell Library
7 read_cell_library \
8
../../../library/standard_cells/tessent/NangateOpenCellLibrary.tcelllib
9 read_cell_library ../../../library/memories/SYNC_1RW_8Kx16.atpglib
10 # Read the post-layout netlist and elaborate the design
11
read_verilog ../7.place_and_route/verilog/processor_core.post_layout.vg
12
13 # Read in the scan-inserted design data files generated during
pre-layout

Tessent™ Shell User’s Manual 353

Tessent Shell Workflows
Verify MemoryBIST, Boundary Scan, and IJTAG Patterns
14 # The -no_hdl switch loads all relevant data except the original
netlist
15 read_design processor_core -design_id gate -no_hdl -verbose
16
17 set_current_design processor_core
18
19 add_black_boxes -modules { \
20 SYNC_1RW_8Kx16 \
21 }
22
23 # Specify the design level before writing out the softlink
24 set_design_level physical_block
25 write_design -tsdb -softlink_netlist -verbose
26 exit

Verify MemoryBIST, Boundary Scan, and IJTAG

Patterns
Create and validate the MemoryBIST, boundary scan (if present), and IJTAG network patterns
by creating and processing a patterns specification with the create_patterns_specification and
process_patterns_specification commands.

Prerequisites
• You have generated a soft link in the TSDB that points to the post-layout netlist as described in
Soft Link TSDB and Post-Layout Netlist.

Procedure
1. Load the design by using read_design and pointing to the soft-linked post-layout netlist (lines 1-9).

2. If needed, add black boxes, and then check the design rules (lines 11-14).

3. Create, simulate, and check the testbenches (refer to lines 16-24). Refer to
create_patterns_specification and process_patterns_specification in the Tessent Shell Reference
Manual for details.

Examples

Verify the Patterns With a New Patterns Specification

The following example verifies the patterns for a hierarchical core, processor_core.

1 set_context patterns -ijtag -design_id post_layout

2 set_tsdb_output_directory ../tsdb_core
3
4 # Read the tessent cell library
5 read_cell_library \
6
../../../library/standard_cells/tessent/NangateOpenCellLibrary.tcelllib
7 # Reading the soft-linked post-layout netlist from the tsdb_core
8 read_design processor_core -design_id post_layout –verbose

354 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Verifying the Scan-Inserted ATPG Patterns
9 set_current_design processor_core
10
11 add_black_boxes -modules { \
12 SYNC_1RW_8Kx16 \
13 }
14 check_design_rules
15
16 create_patterns_specification
17 process_patterns_specification
18
19 set_simulation_library_sources \
20
-v ../../../library/standard_cells/verilog/NangateOpenCellLibrary.v \
21 -v ../../../library/memories/SYNC_1RW_8Kx16.v
22
23 # Disable clock monitoring when running simulation on post-layout
netlist
24 run_testbench_simulations -simulation_macro_definitions \
25 TESSENT_DISABLE_CLOCK_MONITOR
26 check_testbench_simulations -report_status
27 exit

Verify the Patterns with a Customized Patterns Specification from Pre-Layout Signoff
You may have customized a patterns specification during pre-layout signoff. You can read in this patterns
specification that was stored in the TSDB during pre-layout signoff. Use the read_config_data command
instead of the create_patterns_specification command.
The following example shows how to read in a customized patterns specification from pre-layout netlist.
The pre-layout patterns specification "processor_core_gate.patterns_spec_signoff" was used to create
the patterns on the gate-level scan-inserted netlist.

set_context patterns –ijtag –design_id after_layout

set_tsdb_output_directory ../tsdb_core
# Reading the tessent cell library
# Read the soft-linked post-layout netlist and elaborate the design...
check_design_rules
read_config_data ../tsdb_core/patterns/ \
processor_core_gate.patterns_spec_signoff
process_patterns_specification
# Read in the required libraries and simulate
...

Verifying the Scan-Inserted ATPG Patterns

Perform ATPG on the post-layout netlist and save the patterns.

Tessent™ Shell User’s Manual 355

Tessent Shell Workflows
Verifying the Scan-Inserted ATPG Patterns

Prerequisites
• In the SDC that was created during ICL extraction on page 208 for the pre-layout DFT insertion
flow, set the tessent_get_preserve_instances proc to add_core_instances when you do not need
grayboxes. For example, when you are working with flat designs.
For wrapped cores, set the tessent_get_preserve_instances proc to icl_extraction to
automatically include ICL instances in the grayboxes.
The SDC file is located in the TSDB directory under dft_inserted_designs. Refer to Timing
Constraints (SDC) for more information.

Procedure
1. Load the design (lines 1-9). Ensure that you set the context to patterns -scan and read in the soft-
linked post-layout netlist.

2. Set the current mode (lines 11-12). Specify a different name than that used during scan insertion
and used during pre-layout pattern generation.

3. Perform the remainder of the ATPG pattern generation flow (refer to lines 14-35).

Examples
The following example shows how to verify scan-inserted ATPG patterns by using the patterns -scan
context and a post-layout netlist. This example shows the flow for a flat design. For hierarchical designs,
refer to Performing ATPG Pattern Generation: Wrapped Core for specifics related to wrapped cores and
Top-Level ATPG Pattern Generation Example for a top-level example.

1 set_context patterns -scan

2 read_cell_library \
3 ../library/standard_cells/tessent/NangateOpenCellLibrary.tcelllib
4 read_cell_library ../library/mem_ver/memory.lib
5 # Point to the TSDB directory
6 set_tsdb_output_directory ../tsdb_rtl
7
8 # Reading the post-layout netlist
9 read_design cpu_top -design_id post_layout
10 set_current_design cpu_top
11
12 # Use a unique mode name
13 set_current_mode edt_stuck_final
14
15 report_dft_signals
16 # If Tessent Scan was used for scan insertion, can use the scan
configuration mode
17 import_scan_mode edt_mode
18 # Set the following DFT Signal values to use the boundary scan chain
to apply/capture values that would normally use the I/O pads
19 set_static_dft_signal_values int_ltest_en 1
20 set_static_dft_signal_values output_pad_disable 1
21 # Set the following DFT signal value to apply the
shift_capture_clock to the scan-tested network during capture phase of
ATPG

356 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Post-Layout Validation When You Have Ungrouped IJTAG/OCC/EDT Logic
22 set_static_dft_signal_value tck_occ_en 1
23 report_static_dft_signal_settings
24
25 set_system_mode analysis
26
27 # Generation of ATPG patterns
28 create_patterns
29 report_statistics -detailed_analysis
30 write_tsdb_data -replace
31
32 # Patterns written out for simulation
33 write_patterns patterns/cpu_top_stuck_parallel.v -verilog -parallel
\-replace -pattern_sets scan
34 write_patterns patterns/cpu_top_stuck_serial.v -verilog -serial
-replace \
35 # Writing the STIL pattern for tester
36 write_patterns patterns/cpu_top_stuck.stil -stil -replace
37 exit

Post-Layout Validation When You Have Ungrouped

IJTAG/OCC/EDT Logic
During layout, IJTAG, OCC, and EDT logic can become ungrouped, which means the hierarchy around
this logic is dissolved so that the gates that were inside of the ungrouped instances become part of the
next higher instance. Ungrouped test logic during layout can cause some of the automated setup for
pattern generation to no longer operate seamlessly.
The automated flow relies on preservation of Tessent test logic’s hierarchical names. Use the following
post-layout validation flow to update the TSDB with the post-layout netlist and set up the design for ATPG.
The flow assumes knowledge of the ATPG pattern generation flow for physical blocks as described in
Performing ATPG Pattern Generation: Wrapped Core.

Tessent™ Shell User’s Manual 357

Tessent Shell Workflows
Post-Layout Validation When You Have Ungrouped IJTAG/OCC/EDT Logic

Figure 84. Post-Layout Validation Flow With Ungrouped IJTAG/OCC/EDT Logic

The best way to avoid complications related to ungrouping in layout is to use the
tessent_get_preserve_instances procedures in the generated SDC file to identify which instances must
be preserved based on their intended uses. Refer to the Synthesis Helper Procs section in the Tessent
Shell User’s Manual.
If you expect the layout process to ungroup the test instruments, you can preserve the hierarchical
names by adding persistent buffers. You must generate the IP using the DftSpecification. The
add_persistent_buffers_in_scan_resource_instruments property is on by default. With persistent
buffers present, you can run the add_core_instances command directly on the IP instance, even if it is
ungrouped. Otherwise, you must follow the example using “add_core_instances ‑current_design” if the IP
is ungrouped without persistent buffers present.

Prerequisites
• If you do not preserve the instances, you must write out a TCD file for every mode of operation at
the core level before you perform layout. In some cases, you may not need to generate patterns
until after layout, but even then, you must run ATPG before layout to generate the core-level TCD
files. Failure to perform this task could result in R14 or R15 rule check errors.

Procedure
1. Soft link the post-layout netlist to the TSDB. Refer to Soft Link TSDB and Post-Layout Netlist for
more information.

2. Generate the graybox model.

Graybox models are only required for hierarchical cores, not for hierarchical top or flat designs.
(The line numbers in this step refer to the example “Generate the Graybox Model” on page 360.)

358 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Post-Layout Validation When You Have Ungrouped IJTAG/OCC/EDT Logic

a. When loading the design (line 4), specify the same design that you used to write the post-
layout netlist to the TSDB, for example "post_layout".
Using the same design ID for the graybox model that you used for the post-layout netlist
enables Tessent to access the full design view or the graybox model with the same design ID.

b. Read the core description for external mode using the add_core_instances command (line 9).
Because you already ran the pre-layout ATPG step and saved the TCD file to the TSDB, the
add_core_instances command can read the existing TCD file and add the core instances that
are active in external mode.

c. Use analyze_graybox to generate the graybox (line 13). If the IJTAG network was ungrouped
in layout, the analyze_graybox command can automatically find and preserve the IJTAG SRI
network as long as the default names of the logic have not changed.

3. If you are running in hierarchical mode, run ATPG on the core’s internal mode of the wrapped core
to generate the ATPG patterns that you retarget at the top level of the chip. If you are running in
hierarchical top or in flat mode, run ATPG.
The line numbers in this example refer to example “Run ATPG on the Core’s Internal Mode” on
page 360.

a. Specify a unique ATPG mode name with the set_current_mode command (line 10). Append
the name with "_post_layout" or "_final" to clarify which mode to use for silicon diagnosis, and
then set the current mode type to "internal".

b. Add the core instances using the design ID and mode from the pre‑layout step (line 15).
This loads the TCD file that contains the information for the design’s core instances. It
is unnecessary to match these instances to the test logic instances that may have been
ungrouped during layout.

c. (Optional) Use the read_faults command to merge the fault list from running external mode to
find the total overall fault coverage of the wrapped core (line 37).
When you run ATPG in internal mode for transition patterns, you must do the following:

• Specify a unique name for the ATPG run with the set_current_mode command. For example,
edt_int_tdf_final.

• Use the add_core_instances command to read the transition mode TCD. For example:

add_core_instance -current_design -design_id gate -mode

edt_int_transition

• Ensure that you set the correct fault type:

set_fault_type transition

• You can optimize the number of capture cycles used by the OCCs by specifying the optional
capture_window_size parameter. The following command specifies a capture_window_size of
2:

Tessent™ Shell User’s Manual 359

Tessent Shell Workflows
Post-Layout Validation When You Have Ungrouped IJTAG/OCC/EDT Logic

set_core_instance_parameters -instrument_type occ

-parameter_values [list capture_window_size 2]

4. Run Verilog simulation of the core-level ATPG patterns.

Performing this task ensures that the patterns function as needed when they are retargeted at
the parent level. For parallel load patterns, as specified by the write_patterns -parallel command,
simulate all the patterns. For serial load patterns, a handful of patterns are sufficient; the run time
for simulating gate-level serial load patterns is significant. The set_pattern_filtering command (line
28) is used to reduce the number of serial patterns saved for the simulation.

Examples

Generate the Graybox Model

The following example creates a graybox model for a post-layout processor_core design and saves the
data under the same design ID.

1 set_context patterns -scan -design_id post_layout

2 set_tsdb_output_directory ../tsdb_outdir
3 read_cell_library \
4
../../../library/standard_cells/tessent/NangateOpenCellLibrary.tcelllib
5 read_design processor_core -design_id post_layout -verbose
6 read_verilog ../../../library/memories/SYNC_1RW_8Kx16.v
-interface_only
7 set_current_design processor_core
8 # Use the add_core_instances command to read the TCD file.
9 #import_scan_mode ext_mode
10 add_core_instances -current_design -design_id gate
11 check_design_rules
12 report_scan_cells
13 # Create and write the updated graybox model to the TSDB.
14 analyze_graybox
15 write_design -tsdb -graybox -verbose
16 exit

Run ATPG on the Core’s Internal Mode

1 set_context patterns -scan -design_id post_layout
2 set_tsdb_output_directory ../tsdb_outdir
3 read_cell_library \
4
../../library/standard_cells/tessent/NangateOpenCellLibrary.tcelllib
5 read_design processor_core -design_id post_layout -verbose
6 read_verilog ../../../library/memories/SYNC_1RW_8Kx16.v
-interface_only
7 set_current_design processor_core
8 # Specify the current mode using a different name than what was used
9 # during scan insertion or pre-layout
10
11 set_current_mode edt_int_stuck_final -type internal

360 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Post-Layout Validation When You Have Ungrouped IJTAG/OCC/EDT Logic
12
13 # Use the -design_id and -mode from pre-layout to read in the TCD of
that
14 # mode
15
16 add_core_instance -current_design -design_id gate -mode
edt_int_stuck
17 set_system_mode analysis
18 add_fault -all
19 report_statistics -detail
20 create_patterns
21 report_statistics -detail
22 # Store TCD, flat_model, fault list and patDB format files in the
TSDB
23 # directory
24
25 write_tsdb_data -replace
26
27 # Write Verilog patterns for simulation
28 write_patterns patterns/processor_core_stuck_parallel.v -verilog
‑parallel -replace
29 set_pattern_filtering -sample_per_type 2
30 write_patterns patterns/processor_core_stuck_serial.v -verilog
-serial
‑replace
31 # Optional Step - Can run in external mode and calculate the fault
32 # coverage of the core(both Internal and External) as described
below.
33 # In order to understand the coverage of the faults testable by
Internal
34 # mode it is necessary to eliminate the undetected faults that would
35 # otherwise be detected in External mode. This is done by merging
the
36 # fault list from running the graybox in External mode with
read_faults:
37
38 #read_faults -mode ext_multi_stuck -fault_type stuck -merge -verbose
39
40 # Final coverage of the core that includes both Internal and
External
41 # modes
42 # report_statistics -detail
43 exit

Tessent™ Shell User’s Manual 361

Tessent Shell Workflows
Testbench Generation and Simulation in RTL Mode

Testbench Generation and Simulation in RTL

Mode
Testbench module generation and the Standard Test Interface (STI) infrastructure support complex port
data types. The tool generates a simulation wrapper to connect a design under test (DUT) with specific
complex port types to the testbench environment.
The simulation wrapper port list includes ports of scalar and one-dimensional bus data types. The port
names are the post-synthesis names of sub-bundle objects as inferred from the original RTL complex
ports of the DUT. This approach isolates the DUT from the testbench environment and hides the
complexity of its ports and other SystemVerilog dependencies.

Simulation Wrapper Creation

Testbench Examples

Simulation Wrapper Creation

Simulation wrapper creation occurs while the tool is processing DFT specifications and extracting ICL.
Use the simulation wrapper for designs with specific complex port types.
The tool creates simulation wrappers during process_dft_specification and extract_icl. You need the
simulation wrapper in the testbench for designs that contain the following complex port types if they drive
(or are driven by) a testbench port:

• enumerations

• unpacked arrays

• unpacked structs

• SystemVerilog interfaces
You can also create the simulation wrapper manually with the get_current_design, report_current_design,
and write_design commands.
The tool reports a warning if read_design encounters ports that can cause issues in simulation or in the
TSDB flow:

// Warning: The design 'sv_mod1' just read has ports with 'unpacked struct'/'enumerate'
// datatypes declared in Global ($unit) or local scope ('sv_mod1' scope).
// If you try to elaborate this design within its parent, you will get an error.
// It will only work if this design is your current design.

These issues typically arise when port declarations use data types that are not visible to the tool. The
warning indicates that a call to set_current_design of the parent block raises additional warnings. Use
report_current_design after running set_current_design to obtain more information about these ports.
The following example shows how the simulation wrapper is created during extract_icl:

362 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Simulation Wrapper Creation

// command: extract_icl
// Writing simulation wrapper : \
./tsdb_outdir/dft_inserted_designs/sv_mod1_RTL1.dft_inserted_design/sv_mod1
.sv09_simulation_wrapper
// Note: Updating the hierarchical data model to reflect RTL design
changes.
// Writing design source dictionary : \
./tsdb_outdir/dft_inserted_designs/
sv_mod1_RTL1.dft_inserted_design/sv_mod1.design_source_dictionary
// Flattening process completed, cell instances=111, gates=1310, PIs=470,
POs=166, CPU time=0.04 sec.
// --------------------------------------------------------------------
// Begin circuit learning analyses.
// --------------------------------
// Learning completed, CPU time=0.02 sec.
// --------------------------------------------------------------------
// Begin ICL extraction.
// ---------------------
// ICL extraction completed, ICL instances=10, CPU time=0.16 sec.
// --------------------------------------------------------------------
// --------------------------------------------------------------------
// Begin ICL elaboration and checking.
// -----------------------------------
// ICL elaboration completed, CPU time=0.09 sec.
// --------------------------------------------------------------------
// Writing ICL file : ./tsdb_outdir/dft_inserted_designs/
sv_mod1_RTL1.dft_inserted_design/sv_mod1.icl
// Writing consolidated PDL file: ./tsdb_outdir/dft_inserted_designs/
sv_mod1_RTL1.dft_inserted_design/sv_mod1.pdl
// Writing SDC file: ./tsdb_outdir/dft_inserted_designs/
sv_mod1_RTL1.dft_inserted_design/sv_mod1.sdc
// Writing DFT info dictionary: ./tsdb_outdir/dft_inserted_designs/
sv_mod1_RTL1.dft_inserted_design/
sv_mod1.dft_info_dictionary

The following example shows how the simulation wrapper is created during process_dft_specification:

// command: process_dft_specification
//
// Begin processing of /DftSpecification(sv_mod1,RTL2)
// --- IP generation phase ---
// Validation of IjtagNetwork
// Validation of OCC
// Validation of EDT
// Processing of IjtagNetwork
// Generating design files for IJTAG SIB module
sv_mod1_RTL2_tessent_sib_1
// Verilog RTL : ./tsdb_outdir/instruments/
sv_mod1_RTL2_ijtag.instrument/sv_mod1_RTL2_tessent_sib_1.v
// IJTAG ICL : ./tsdb_outdir/instruments/
sv_mod1_RTL2_ijtag.instrument/sv_mod1_RTL2_tessent_sib_1.icl
// Generating design files for IJTAG SIB module

Tessent™ Shell User’s Manual 363

Tessent Shell Workflows
Simulation Wrapper Creation
sv_mod1_RTL2_tessent_sib_2
// Verilog RTL : ./tsdb_outdir/instruments/
sv_mod1_RTL2_ijtag.instrument/sv_mod1_RTL2_tessent_sib_2.v
// IJTAG ICL : ./tsdb_outdir/instruments/
sv_mod1_RTL2_ijtag.instrument/sv_mod1_RTL2_tessent_sib_2.icl
// Generating design files for IJTAG Tdr module
sv_mod1_RTL2_tessent_tdr_sri_ctrl
// Verilog RTL : ./tsdb_outdir/instruments/
sv_mod1_RTL2_ijtag.instrument/sv_mod1_RTL2_tessent_tdr_sri_ctrl.v
// IJTAG ICL : ./tsdb_outdir/instruments/
sv_mod1_RTL2_ijtag.instrument/sv_mod1_RTL2_tessent_tdr_sri_ctrl.icl
//
// Loading the generated RTL verilog files (2) to enable instantiating
the contained modules
// into the design.
// Processing of EDT
// Generating design files for EDT module
sv_mod1_RTL2_tessent_edt_edt1
// Verilog RTL : ./tsdb_outdir/instruments/
sv_mod1_RTL2_edt.instrument/sv_mod1_RTL2_tessent_edt_edt1.v
// IJTAG ICL : ./tsdb_outdir/instruments/
sv_mod1_RTL2_edt.instrument/sv_mod1_RTL2_tessent_edt_edt1.icl
// IJTAG PDL : ./tsdb_outdir/instruments/
sv_mod1_RTL2_edt.instrument/sv_mod1_RTL2_tessent_edt_edt1.pdl
// TCD : ./tsdb_outdir/instruments/
sv_mod1_RTL2_edt.instrument/sv_mod1_RTL2_tessent_edt_edt1.tcd
//
// Loading the generated RTL verilog files (1) to enable instantiating
the contained modules
// into the design.
// --- Instrument insertion phase ---
// Inserting instruments of type 'ijtag'
// Inserting instruments of type 'edt'
//
// Writing out modified source design in ./tsdb_outdir/
dft_inserted_designs/sv_mod1_RTL2.dft_inserted_design
// Writing simulation wrapper : ./tsdb_outdir/dft_inserted_designs/
sv_mod1_RTL2.dft_inserted_design/sv_mod1.sv09_simulation_wrapper
// Writing out specification in ./tsdb_outdir/dft_inserted_designs/
sv_mod1_RTL2.dft_spec
// Done processing of
DftSpecification(sv_mod1,RTL2

Related Topics
get_current_design

read_design

report_current_design

write_design

set_current_design

364 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Testbench Examples

Testbench Examples
SystemVerilog design definition with the top level named "top" and one SystemVerilog interface port
named "Bus":

typedef enum logic [2:0] {

RED, GREEN, BLUE, CYAN, MAGENTA, YELLOW
} color_t;

typedef struct packed{

logic [2:0] eventbus;
} event_bus_packet_t;

typedef struct packed{

color_t state_encoded;
event_bus_packet_t dt_lcp_pulse;
logic [3:0] eventbus_encoded;
} event_bus_split_packet_t;

interface MSBus;
event_bus_split_packet_t Addr;
logic [1:0] Data;
logic RWn;
logic Clk;
modport Secondary (input Addr, RWn, Clk, output Data);
endinterface

module top(MSBus.Secondary Bus);

endmodule

Each bit-blasted bit of the DUT is connected to its associated test pattern wire using the post-synthesis
pin name. The name of the test pattern bit is the same as that of the DUT pin bit, escaped with a
backslash (\). The DUT instance (DUT_inst) is the generated simulation wrapper, with the DUT itself
instantiated in it. This table cross-references the DUT pin names and the test pattern bit names:

Table 20. Test Pattern Bit Name Assignments

DUT Pin of Port "Bus" Test Pattern Bits

DUT_inst/\Bus.Addr [10] \Bus.Addr [10]

DUT_inst/\Bus.Addr [9] \Bus.Addr [9]

DUT_inst/\Bus.Addr [8] \Bus.Addr [8]

DUT_inst/\Bus.Addr [7] \Bus.Addr [7]

DUT_inst/\Bus.Addr [6] \Bus.Addr [6]

DUT_inst/\Bus.Addr [5] \Bus.Addr [5]

DUT_inst/\Bus.Addr [4] \Bus.Addr [4]

Tessent™ Shell User’s Manual 365

Tessent Shell Workflows
Testbench Examples

Table 20. Test Pattern Bit Name Assignments (continued)

DUT Pin of Port "Bus" Test Pattern Bits

DUT_inst/\Bus.Addr [3] \Bus.Addr [3]

DUT_inst/\Bus.Addr [2] \Bus.Addr [2]

DUT_inst/\Bus.Addr [1] \Bus.Addr [1]

DUT_inst/\Bus.Addr [0] \Bus.Addr [0]

DUT_inst/\Bus.RWn \Bus.RWn

DUT_inst/\Bus.Clk \Bus.Clk

DUT_inst/\Bus.Data [1] \Bus.Data[1]

DUT_inst/\Bus.Data [0] \Bus.Data[0]

The testbench module generated is as follows, in part:

`timescale 1ns / 1ns

module TB;
integer _write_DIAG_file;
integer _DIAG_file_header;
integer _diag_file;
integer _diag_chain_header;
integer _diag_scan_header;
integer _last_fail_pattern;
. . .
wire \Bus.Addr[10], \Bus.Addr[9], \Bus.Addr[8], \Bus.Addr[7],
\Bus.Addr[6], \Bus.Addr[5], \Bus.Addr[4], \Bus.Addr[3],
\Bus.Addr[2], \Bus.Addr[1], \Bus.Addr[0], \Bus.RWn ,
\Bus.Clk , \Bus.Data[1], \Bus.Data[0], ijtag_tck,
ijtag_reset, ijtag_ce, ijtag_se, ijtag_ue, ijtag_sel,
ijtag_si, ijtag_so;
assign \Bus.Addr[10] = _ibus[19];
assign \Bus.Addr[9] = _ibus[18];
assign \Bus.Addr[8] = _ibus[17];
assign \Bus.Addr[7] = _ibus[16];
assign \Bus.Addr[6] = _ibus[15];
assign \Bus.Addr[5] = _ibus[14];
assign \Bus.Addr[4] = _ibus[13];
assign \Bus.Addr[3] = _ibus[12];
assign \Bus.Addr[2] = _ibus[11];
assign \Bus.Addr[1] = _ibus[10];
assign \Bus.Addr[0] = _ibus[9];
assign \Bus.RWn = _ibus[8];
assign \Bus.Clk = _ibus[7];
assign ijtag_tck = _ibus[6];
assign ijtag_reset = _ibus[5];
assign ijtag_ce = _ibus[4];

366 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Testbench Examples
assign ijtag_se = _ibus[3];
assign ijtag_ue = _ibus[2];
assign ijtag_sel = _ibus[1];
assign ijtag_si = _ibus[0];
assign _sim_obus[2] = \Bus.Data[1] ;
assign _sim_obus[1] = \Bus.Data[0] ;
assign _sim_obus[0] = ijtag_so;
. . .
reg[71:0] mem [0:1864134];
top_wrapper DUT_inst (.\Bus.Addr ({\Bus.Addr[10], \Bus.Addr[9],
\Bus.Addr[8], \Bus.Addr[7],
\Bus.Addr[6], \Bus.Addr[5],
\Bus.Addr[4], \Bus.Addr[3] ,
\Bus.Addr[2], \Bus.Addr[1],
\Bus.Addr[0]}),
.\Bus.RWn (.\Bus.RWn ),
.\Bus.Clk (.\Bus.Clk ),
.\Bus.Data ({\Bus.Data[1], \Bus.Data[1]},
.ijtag_tck(ijtag_tck),
.ijtag_reset(ijtag_reset),
.ijtag_ce(ijtag_ce),
.ijtag_se(ijtag_se),
.ijtag_ue(ijtag_ue),
.ijtag_sel(ijtag_sel),
.ijtag_si(ijtag_si),
.ijtag_so(ijtag_so));
. . .
endmodule

Simulation wrapper:

module top_wrapper(input wire [10:0] \Bus.Addr ,

input wire \Bus.RWn ,
input wire \Bus.Clk ,
output wire [1:0] \Bus.Data
input wire ijtag_tck,
input wire ijtag_reset,
input wire ijtag_ce,
input wire jtag_se,
input wire ijtag_ue,
input wire ijtag_sel,
input wire ijtag_si,
output wire ijtag_so);

MSBus tessent_intf_inst1();

assign tessent_intf_inst1.Addr = \Bus.Addr ;

assign tessent_intf_inst1.RWn = \Bus.RWn ;
assign tessent_intf_inst1.Clk = \Bus.Clk ;
assign \Bus.Data = tessent_intf_inst1.Data;

top current_design(.Bus(tessent_intf_inst1),
.ijtag_tck(ijtag_tck),

Tessent™ Shell User’s Manual 367

Tessent Shell Workflows
Testbench Examples
.ijtag_reset(ijtag_reset),
.ijtag_ce(ijtag_ce),
.ijtag_se(ijtag_se),
.ijtag_ue(ijtag_ue),
.ijtag_sel(ijtag_sel),
.ijtag_si(ijtag_si),
.ijtag_so(ijtag_so));
endmodule

The testbench dofile:

set_context dft -rtl -design_id RTL1

read_cell_library techlib_adk.tnt/current/tessent/adk.tcelllib
read_core_description design/mem/*.tcd_memory
read_verilog design/packages/types.sv -format sv2009
read_verilog -f design/sv.list -format sv2009
set_current_design top
set_design_level phys
set_dft_specification_requirements -memory_test on
add_clocks [get_ports Bus.Clk] -period 10ns
check_design_rules
set spec [create_dft_spec]
// (the spec is populated here)
process_dft_spec
extract_icl
create_pattern_spec
process_pattern_spec
set_simulation_library_sources -v techlib_adk.tnt/current/verilog/adk.v
-logical_library_map_list memlib
./memlib -v design/sv_v_files/pll.v
run_testbench_simulation -simulator_options {-t 10ps -L
memlib}

368 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Hybrid TK/LBIST Flow for Flat Designs

Hybrid TK/LBIST Flow for Flat Designs

Tessent Shell supports inserting LogicBIST controllers that share IP resources with EDT controllers to
reduce hardware overhead. The process for performing this task is known as the hybrid TK/LBIST flow. In
this flow, Tessent Shell automatically adds hybrid logic to the EDT controllers for IP resource sharing. The
shared LogicBIST and EDT IP is often referred to as hybrid TK/LBIST IPs, or simply hybrid IPs.
This discussion builds on the Tessent Shell RTL and scan DFT insertion flow as described in “Tessent
Shell Flow for Flat Designs” on page 190. Refer to Hybrid TK/LBIST Flow User’s Manual for details about
the hybrid TK/LBIST flow and inserted architecture.

Tip
This flow increments the basic Tessent Shell RTL and scan DFT insertion flow. To aid
comprehension, ensure that you have reviewed the test case for flat designs.

Refer to the following test case for a detailed usage example of the flow described in this section. This
test case illustrates hybrid IP insertion into a flat design with MemoryBIST in the first DFT insertion pass
and EDT, OCC, and LogicBIST in the second DFT insertion pass.

tessent_example_hybrid_tk_lbist_flow_<software_version>.lbist

You can access this test case by navigating to the following directory:

<software_release_tree>/share/UsageExamples/

RTL and Scan DFT Insertion Flow With Hybrid TK/LBIST

Perform the First DFT Insertion Pass: Hybrid TK/LBIST
Perform the Second DFT Insertion Pass: Hybrid TK/LBIST
Perform Test Point Insertion
Perform Scan Chain Insertion (Hybrid Flow)
Performing ATPG Pattern Generation: Hybrid TK/LBIST
Performing LogicBIST Fault Simulation
Perform LogicBIST Pattern Generation

RTL and Scan DFT Insertion Flow With Hybrid

TK/LBIST
Within the two-pass DFT insertion process for a flat design, insert the hybrid TestKompress/LogicBIST IP
during the second DFT insertion pass. Adding LogicBIST to your Tessent Shell flow introduces several
new steps: X‑bounding, test point insertion, and LogicBIST fault simulation and pattern generation. This
hybrid solution adds self-test capabilities and is key to satisfying the reliability requirements of the ISO
26262 automotive safety standard.

Tessent™ Shell User’s Manual 369

Tessent Shell Workflows
Perform the First DFT Insertion Pass: Hybrid TK/LBIST

Note:
The test case that illustrates the hybrid TK/LBIST flow does not include boundary scan insertion.
Refer to “First DFT Insertion Pass: Performing MemoryBIST and Boundary Scan” on page 193 for
information about inserting boundary scan in the first DFT insertion pass.

Figure 85. Two-Pass Insertion Flow With Hybrid TK/LBIST

Perform the First DFT Insertion Pass: Hybrid

TK/LBIST
When performing the hybrid TK/LBIST flow to insert the hybrid IP, perform the first pass of the two-pass
DFT and scan insertion process as usual—insert MemoryBIST and boundary scan. In addition, for the
hybrid TK/LBIST flow, enable controller chain mode (CCM) test by specifying a dedicated control signal.
CCM enables you to generate ATPG patterns that target the hybrid-IP logic so that you can test the test
logic. Refer to "Controller Chain Mode" in the Hybrid TK/LBIST User’s Manual for details.
Refer to “First DFT Insertion Pass: Performing MemoryBIST and Boundary Scan” on page 193 for
additional information.

Note:
The line numbers used in this procedure refer to the command flow dofile in Example 13 on
page 371.

370 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Perform the First DFT Insertion Pass: Hybrid TK/LBIST

Procedure
1. Load the RTL design data and set the design parameters. (Refer to lines 1-11.)

Note:
rtl1 is the recommended naming convention for the design ID for the first insertion pass,
but you can specify any name. Refer to Loading the Design for more information about
setting the design ID. The default design ID for the current test case is rtl.

2. Add a DFT signal to use for controller chain mode. (Refer to lines 13-16.) You must register the
DFT signal name and then add the signal.
By default, Tessent Shell adds a pin at the current design level to control CCM. You can save
this pin by using a TDR register to control CCM; do this by specifying the add_dft_signal
-create_with_tdr switch.
Whether or not you are inserting MemoryBIST or boundary scan, you must add the CCM DFT
signal in the first DFT insertion pass because its generated hardware is used in the second pass
when you insert the hybrid IP.

3. Set the set_dft_specification_requirements command to on for ‑memory_bist. (Refer to lines

18-19.)

4. Define the design clocks. (Refer to lines 21-23.)

5. Check the design rules and set the system mode to analysis. (Refer to lines 25-26.)

6. Create the DFT specification. (Refer to lines 28-31.)

7. Generate the DFT hardware, IJTAG network connectivity, and test patterns. (Refer to lines 33-43.)

8. Run simulations to verify the design. (Refer to lines 45-50.)

Examples

Example 1
The following dofile example shows a typical command flow as detailed in the preceding procedure. The
highlighted command lines are unique to the process for inserting hybrid IP in a two-pass DFT insertion
process.

Example 13. Dofile Example for First Pass, Hybrid TK/LBIST With MemoryBIST

1 # Load the design

2 set_context dft –rtl
3 set_tsdb_output_directory ../tsdb_outdir
4 read_verilog ../rtl/piccpu_rtl.v
5 read_cell_library ../lib/tessent/adk.tcelllib \
6 ../lib/tessent/picdram.atpglib
7 set_design_source -format tcd_memory -y ../rtl -extension memlib
8
9 set_current_design piccpu
10
11 set_design_level physical_block

Tessent™ Shell User’s Manual 371

Tessent Shell Workflows
Perform the First DFT Insertion Pass: Hybrid TK/LBIST
12
13 # Add DFT signal for controller chain mode test
14 add_dft_signal controller_chain_mode -create_with_tdr
15
16 # Specify the DFT requirements
17 set_dft_specification_requirements -memory_test on
18
19 # Define memory clock
20 add_clocks 0 ramclk -period 100ns
21 add_clocks 0 clk -period 100ns
22
23 check_design_rules
24 set_system_mode analysis
25
26 # Create and report the DFT specification
27 # This test case reads in the DFT specification from a separate
file
28 read_config_data mbist_ip.dftspec
29 report_config_data
30
31 # Generate and insert the hardware
32 process_dft_specification
33
34 extract_icl
35
36 # Generate MemoryBIST and IJTAG network verification patterns
37 create_patterns_specification
38
39 report_config_data
40
41 process_patterns_specification
42
43 # Run and check testbench simulations
44 set_simulation_library_sources -v {../lib/verilog/adk.v} \
45 -y ../lib/verilog -extension v
46
47 run_testbench_simulations
48 check_testbench_simulations -report_status
49
50 exit

Example 2
Typically, you insert MemoryBIST or boundary scan in the first DFT insertion pass before inserting
the hybrid IP (and OCC) in the second DFT insertion pass. The following sample dofile shows a first
DFT insertion pass without MemoryBIST or boundary scan, in which you are adding the DFT signal for
controller chain mode test.

372 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Perform the Second DFT Insertion Pass: Hybrid TK/LBIST

Example 14. Dofile Example for First DFT Pass, Hybrid TK/LBIST Only

# Load the design

set_context dft –rtl –design_id rtl1
set_tsdb_output_directory ../tsdb_outdir
set_design_sources -format tcd_memory -y ../rtl -extension memlib
read_verilog ../rtl/piccpu_rtl.v -verbose
read_cell_library ../library/tessent/adk.tcelllib \
../rtl/picdram.atpglib
set_current_design piccpu
set_design_level physical_block
# Specify the clocks
add_clocks 0 clk -period 100ns
add_clocks 0 ramclk -period 100ns

# Add DFT signal for controller chain mode test

add_dft_signal controller_chain_mode -create_with_tdr
check_design_rules
# Create DFT specification
set spec [create_dft_specification]
set_config_value -in $spec user_rtl_cells on
process_dft_specification
extract_icl
# Generate patterns
create_patterns_specification
# Create patterns specification and create simulation testbenches
process_patterns_specification
# Run and check testbench simulations
set_simulation_library_sources -v ../library/verilog/adk.v \
-v ../library/memory/ram.v -y ../library/verilog -extensionv
run_testbench_simulations -simulator_option +nowarnTSCALEexit

Perform the Second DFT Insertion Pass: Hybrid

TK/LBIST
In the second DFT insertion pass with the hybrid TK/LBIST flow, insert the EDT, OCC, and LogicBIST
instruments.

Note:
The line numbers used in this procedure refer to the command flow dofile in “Example 1: Dofile
Flow for the Second DFT Insertion Pass: Hybrid TK/LBIST” on page 375 unless otherwise
noted.

Tessent™ Shell User’s Manual 373

Tessent Shell Workflows
Perform the Second DFT Insertion Pass: Hybrid TK/LBIST

Procedure
1. Load the design and set the environment (refer to lines 1-6). Refer to “Loading the Design” on
page 199 for more information.

2. Define the DFT signals (refer to lines 8-28). Refer to “Specifying and Verifying the DFT
Requirements” on page 201 for more information.

Note:
Hybrid TK/LBIST has additional DFT requirements for the clock signals.

3. Create the LogicBIST test point and X-bounding signals with a TDR (refer to lines 23-24).

4. Add a core instance for the MemoryBIST mini-OCC for LogicBIST test. (refer to lines 30‑31.)

add_core_instances -instances [get_instances *_tessent_sib_sti_inst]

This is required when you have inserted MemoryBIST in the first DFT insertion pass.

5. Creating the DFT Specification. (Refer to lines 38-50.) Include a SIB for LogicBIST by specifying
lbist in the create_dft_specification command.

create_dft_specification -sri_sib_list {edt occ lbist}

Customize the generated DFT specification as follows. Refer to “Example 2: DFT Specification
Example for Second DFT Insertion Pass with Hybrid TK/LBIST” on page 376.

a. For OCC, set the static clock control to external and the capture trigger to capture_en.
When static_clock_control is set to external, the OCC has an N-bit input (where N equals the
number of shift register bits), which is driven by the NcpIndexDecoder. This is what gives the
OCC programmability for LogicBIST.
When capture_trigger is set to capture_en, the OCC is capable of handling a free-running slow
clock. In LogicBIST applications, the slow clock is a free-running clock (whereas for ATPG this
comes from a top-level tester-controlled clock).
For details about OCC for the hybrid TK/LBIST flow, refer to "Tessent OCC TK/LBIST Flow" in
the Hybrid TK/LBIST Flow User’s Manual.

b. Specify a LogicBist wrapper that contains both a Controller wrapper and an NcpIndexDecoder
wrapper.
This wrapper causes Tessent Shell to automatically convert the EDT controller into a hybrid
controller for the hybrid TK/LBIST flow. In the Controller/Connections wrapper, you must
specify the controller_chain_enable property if you are using a TDR to control CCM. Specify
the full path to the pin or port name.
The NcpIndexDecoder wrapper specifies the named capture procedures (NCPs) for LogicBIST
test. For details, refer to "NCP Index Decoder" in the Hybrid TK/LBIST Flow User’s Manual.

c. In the EDT/Controller wrapper, define the LogicBistOptions if you are not using the default
values.
When you specify the LogicBIST wrapper, the tool adds a LogicBistOptions wrapper to the
EDT controller automatically populated with default values.

374 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Perform the Second DFT Insertion Pass: Hybrid TK/LBIST

The misr_input_ratio property provides a way to specify the MISR size. The automatic (default)
ratio results in the lowest hardware with a small MISR.
You can control how many chains are masked by a single mask register bit using the
chain_mask_register_ratio property. By default, the ratio is 1:1; there are as many bits in the
chain mask register as there are number of scan chains.
Specify the low-power shift options specifically for hybrid IP usage separately from the low-
power shift options for the EDT controller.

6. Process the DFT specification to generate the test hardware, including LogicBIST (refer to line
52). Refer to “Generating the EDT, Hybrid TK/LBIST, and OCC Hardware” on page 207 for more
information.

7. Extract the ICL information (refer to line 54). Refer to “Extracting the ICL Module Description” on
page 208 for more information.

8. Generate the patterns and simulate the testbench (refer to lines 56-63). Refer to “Generating ICL
Patterns and Running Simulation” on page 208 for more information.

Examples

Example 1: Dofile Flow for the Second DFT Insertion Pass: Hybrid
TK/LBIST
The following dofile example shows a typical command flow. The highlighted command lines are unique
to the process for inserting Tessent Shell LogicBIST and hybrid IP instruments in a two-pass DFT
insertion process. In this example, the dofile reads in the DFT specification that defines the instruments to
be inserted.

1 set_context dft -rtl -design_id rtl2

2 set_tsdb_output_directory ../tsdb_outdir
3 read_design piccpu -design_id rtl1
4 read_cell_library ../lib/tessent/adk.tcelllib \
5 ../lib/tessent/picdram.atpglib
6 set_current_design piccpu
7
8 # Add the DFT signals
9 # For scan test MemoryBIST-related logic
10 # Define tck_occ_en to access mini-OCC during LogicBIST
11 add_dft_signal ltest_en memory_bypass_en tck_occ_en
12
13 # Scan test shift/capture and edt clocks are driven from the
14 # test clock (saves a port)
15 add_dft_signal scan_en edt_update -source_node {scan_en edt_update }
16 add_dft_signal test_clock -source_node test_clock
17 add_dft_signal edt_clock shift_capture_clock
-create_from_other_signals
18 # Alternatively, they can be directly driven from a primary port as
19 # follows
20 # add_dft_signal edt_clock shift_capture_clock -source_node
{edt_clock
21 # shift_capture_clock}
22
23 # Required DFT signals for hybrid TK/LBIST

Tessent™ Shell User’s Manual 375

Tessent Shell Workflows
Perform the Second DFT Insertion Pass: Hybrid TK/LBIST
24 add_dft_signals control_test_point_en observe_test_point_en
X_bounding_en
25
26 add_dft_signals int_ltest_en ext_ltest_en
27
28 set_dft_specification_requirements -logic_test on
29
30 # Add the MemoryBIST mini-OCC for LogicBIST test
31 add_core_instances -instances [get_instances *_tessent_sib_sti_inst]
32
33 # add_clock clk -period 100ns
34 # Need to define it because of ICL clock port tracing
35
36 check_design_rules
37
38 # Create DFT specification
39 # Populated later in this dofile
40 set spec [create_dft_specification -sri_sib_list {occ edt lbist } ]
41
42 # You can set this property if there are no library cells
43 # set_config_value -in $spec use_rtl_cells on
44
45 report_config_data $spec
46
47 # Read in the DFT specification data
48 # This test case reads in the DFT specification from a separate file
49 # This file is illustrated in the next example
50 read_config_data logic_instruments.dftspec -in_wrapper $spec
-replace
51
52 process_dft_specification
53
54 extract_icl
55
56 create_patterns_specification
57 process_patterns_specification
58
59 set_simulation_library_sources -v {../lib/verilog/adk.v} \
60 -y ../lib/verilog -extension v
61
62 run_testbench_simulations
63 check_testbench_simulations -report_status
64
65 exit

Example 2: DFT Specification Example for Second DFT Insertion Pass with
Hybrid TK/LBIST
The following example illustrates a DFT specification customized to include the wrappers for the
LogicBIST controller and additional LogicBIST options for the EDT controller.

376 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Perform the Second DFT Insertion Pass: Hybrid TK/LBIST

1 Occ {
2 ijtag_host_interface: Sib(occ);
3 capture_trigger: capture_en;
4 static_clock_control: both;
5 Controller(clk) {
6 clock_intercept_node: clk;
7 }
8 Controller(ramclk) {
9 clock_intercept_node: ramclk;
10 }
11 }
12
13 # Include the LogicBIST controller
14 # Example LogicBIST only; modify for your design requirements
15 LogicBist {
16 ijtag_host_interface : Sib(lbist);
17 Controller(c0) {
18 burn_in : on ;
19 pre_post_shift_dead_cycles : 8 ;
20 SingleChainForDiagnosis { Present : on ; }
21 ShiftCycles {max: 40; hardware_default : 1024;}
22 CaptureCycles {max: 4;}
23 # Hardware default is max
24 PatternCount {max: 10000; hardware_default : 1024;}
25 # Hardware default is 0
26 WarmupPatternCount { max : 512;}
27 ControllerChain {
28 present : on;
29 clock : tck;
30 }
31 Connections {
32 shift_clock_src: clk;
33 controller_chain_enable :
piccpu_rtl_tessent_tdr_sri_ctrl_inst/ \
34 controller_chain_mode;
35 }
36 }
37 NcpIndexDecoder{
38 Ncp(clk_occ_ncp) {
39 cycle(0): OCC(clk);
40 cycle(1): OCC(clk);
41 }
42 Ncp(ramclk_occ_ncp) {
43 cycle(0): OCC(ramclk);
44 cycle(1): OCC(ramclk);
45 }
46 # References to piccpu_rtl_tessent_sib_1 only applicable when
47 # inserting MemoryBIST
48 Ncp(ALL_occ_ncp) {
49 cycle(0): OCC(clk) , OCC(ramclk) , piccpu_rtl_tessent_sib_1;
50 }
51 Ncp(sti_occ_ncp) {

Tessent™ Shell User’s Manual 377

Tessent Shell Workflows
Perform the Second DFT Insertion Pass: Hybrid TK/LBIST
52 cycle(0): piccpu_rtl_tessent_sib_1 ;
53 cycle(1): piccpu_rtl_tessent_sib_1 ;
54 }
55 }
56 }
57
58 # Example EDT only; modify for your design requirements
59 # Note the additional LogicBIST options for the hybrid TK/LBIST flow
60 EDT {
61 ijtag_host_interface : Sib(edt);
62 Controller (c0) {
63 longest_chain_range : 20, 60;
64 scan_chain_count : 10;
65 input_channel_count : 1;
66 output_channel_count : 1;
67 ShiftPowerOptions {
68 present : on ;
69 min_switching_threshold_percentage : 15 ;
70 }
71 LogicBistOptions {
72 misr_input_ratio : 1 ;
73 chain_mask_register_ratio : 1 ;
74 ShiftPowerOptions {
75 present : on ;
76 default_operation : disabled ;
77 SwitchingThresholdPercentage { min : 25 ; }
78 }
79 }
80 }
81 }

Example 3: DFT Signals Required for the Hybrid TK/LBIST Flow

The following dofile snippet shows the DFT signals required if you are performing the hybrid TK/LBIST
flow only (without MemoryBIST or boundary scan in the first DFT insertion pass).

# For logic test

add_dft_signals ltest_en -create_with_tdr
add_dft_signals scan_en edt_update -source_node \
{ scan_en edt_update }
# You can create edt_clock and shift_clock from a test clock
add_dft_signals test_clock -source_node { scan_test_clock }
add_dft_signals edt_clock shift_capture_clock -create_from_other_signals
add_dft_signals int_ltest_en ext_ltest_en
# Required for TK/LBIST IP
add_dft_signals observe_test_point_en -create_with_tdr
add_dft_signals control_test_point_en -create_with_tdr
add_dft_signals x_bounding_en -create_with_tdr

Related Topics
Sib

378 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Perform Test Point Insertion

Perform Test Point Insertion

The two-pass DFT insertion flow with hybrid TK/LBIST includes a step for test point insertion prior to
performing scan chain insertion. Inserting test points increases the testability of a design by improving
controllability and observability during scan testing.
The tool inserts observation points that enable the tool to observe test responses during scan cycles and
control points that activate and receive pseudo-random values during built-in self test. For details, refer to
"Test Points for LBIST Test Coverage Improvement" in the Tessent Scan and ATPG User’s Manual.
Before inserting the test points, specify a DFT signal that enables X-bounding signals. X‑bounding is the
process of preventing signals originating from X-generating nets (from non-scan cells, black boxes, and
primary inputs) from reaching the scan cells. The tool inserts a MUX with an X-bounding enable signal
that is controlled by a top-level pin. X-bounding ensures that only valid binary values propagate through
the scan cells during test. For details, refer to "X-Bounding" in the Hybrid TK/LBIST Flow User’s Manual.

Prerequisites
• Prior to test point insertion, perform synthesis as described in section “Performing Synthesis” on
page 209."

Procedure
1. Specify the following command to set the DFT context for test point insertion:

set_context dft -test_point -no_rtl -design_id gate1

For test point insertion, you must use a gate-level netlist. Ensure that you specify a design ID
with a unique name from the design ID for scan chain insertion that you perform after test point
insertion.

2. Load the cell libraries:

read_cell_library ../lib/tessent/adk.tcelllib ../rtl/picdram.atpglib

3. Specify the same output directory that you used in the first and second DFT passes:

set_tsdb_output_directory ../tsdb_outdir

4. Load the synthesized netlist. For example:

read_verilog ../03.synthesis/piccpu.vg

5. Load the design data for the DFT hardware you previously inserted. For example:

read_design piccpu -design_id rtl2 -no_hdl -verbose

6. Set the maximum number of test points you want to add. For example:

set_test_point_analysis_options -total_number 50

Tessent™ Shell User’s Manual 379

Tessent Shell Workflows
Perform Test Point Insertion

Typically, the maximum number of test points should be 1%-2% of the number of flops in the
design.

7. Set the test point-related insertion options:

set_test_point_insertion_options -observe_point_share 5

The control_test_point_en and observe_test_point_en enable signals are required for test
point insertion, and they are automatically inferred from the control_test_point_en and
observe_test_point_en DFT signals you previously added.

8. Specify the type of test points you want to insert into the design:

set_test_point_types { lbist_test_coverage edt_pattern_count }

Specify both LogicBIST test coverage and EDT pattern count test point types so that the tool
generates test points to reduce pattern count and improve random pattern testability.

9. Specify to insert test logic on the set and reset signals to make them controllable when you insert
scan chains:

set_test_logic -set on -reset on

This command increases test coverage.

10. Prohibit test point insertion for Tessent-inserted scan-resource instruments (SRIs)—EDT, OCC,
and LogicBIST:

add_notest_point [ get_instance *tessent* ]

You can only insert test points into scan-tested instruments (STIs).

11. Analyze and optimize the test points:

analyze_test_points

Tessent Shell returns a log file that lists the test points that are inserted into the tool. You can write
out a test point dofile that lists the test point locations. You can use this dofile to edit the test points
you want to insert.

write_test_point_dofile tpi.dofile -all -replace

12. Insert the test point and scan logic:

insert_test_logic

To generate a script to use with third-party test point insertion tools, use the following command to
target the insertion script for Design Compiler.

insert_test_logic -write_in_tsdb off -write_insertion_script \

testpoint_dc.tcl -insertion dc -replace

380 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Perform Scan Chain Insertion (Hybrid Flow)

Examples
Example 15. Dofile Example for Test Point Insertion

set_context dft -test_point -no_rtl -design_id gate

read_cell_library ../lib/tessent/adk.tcelllib ../rtl/picdram.atpglib
set_tsdb_output_directory ../tsdb_outdir
read_verilog ../03.synthesis/piccpu.vg
read_design piccpu -design_id rtl2 -no_hdl -verbose
set_current_design piccpu
add_input_constraint reset -C0
set_test_point_analysis_options -total_number 50

# Following command inferred when X-bounding enable DFT signal was added
# -xbounding_enable [ get_dft_signal x_bounding_en ]
set_test_point_insertion_options -observe_point_share 5
set_test_point_types { lbist_test_coverage edt_pattern_count }
set_test_logic -set on -reset on
# no test points in Tessent-inserted IPs
add_notest_point [ get_instance *tessent* ]
set_system_mode analysis
analyze_test_points
insert_test_logic
report_test_logic
exit

Perform Scan Chain Insertion (Hybrid Flow)

Scan chain insertion for the hybrid TK/LBIST flow includes additional commands for connecting the scan
enable signal, performing DRC, specifying non-scannable design objects, and X-bounding.

Note:
The line numbers used in this procedure refer to the command flow dofile in Example 16 on
page 382.

Procedure
1. Load the design data and set the design parameters. (Refer to lines 1-6.) Ensure that you specify a
unique design ID name from the name you used for test point insertion.

2. Set DRC handling to issue warnings for E9 and E11 DRC checks. (Refer to lines 8-10.)

set_drc_handling E09 W
set_drc_handling E11 W

These DRCs check for possible bus contention issues. By default, Tessent Shell ignores these
rules. Set these checks to issue warnings so that the X-bounding algorithm checks them and fixes
any X-source contention issues.

3. Specify the pins/ports to exclude from X-bounding. (Refer to lines 12-13.) For example:

Tessent™ Shell User’s Manual 381

Tessent Shell Workflows
Perform Scan Chain Insertion (Hybrid Flow)

set_xbounding_options -exclude { reset }

Exclude the pins/ports that are guaranteed to have a known value during fault simulation and never
propagate an X value to the MISR. The tool does not insert X-bounding muxes at the specified
pins/ports, or at the logic that is driven by these pins.

4. Run X-source analysis with the analyze_xbounding command to identify memory elements that
might capture an unknown during LogicBIST. (Refer to lines 17-19.)

5. Perform wrapper analysis and insertion. (Refer to lines 21-34.)

6. Connect the scan chains to the EDT block, analyze the scan chains, and insert the scan chains.
(Refer to lines 36‑50.)

Examples
The following dofile example shows a typical command flow. The highlighted command lines are unique
to the process for inserting Tessent Shell LogicBIST and hybrid IP instruments in a two-pass DFT
insertion process.

Example 16. Dofile Example for Scan Chain Insertion: Hybrid TK/LBIST

1 set_context dft -scan -design_id gate2

2 read_cell_library ../lib/tessent/adk.tcelllib \
3 ../lib/tessent/picdram.atpglib
4 set_tsdb_output_directory ../tsdb_outdir
5 # Reading in test point-inserted design
6 read_design piccpu -design_identifier gate1 -verbose
7
8 # Enable DRCs for X-bounding
9 set_drc_handling E09 w
10 set_drc_handling E11 w
11
12 # Set x-bounding options
13 set_xbounding_options -exclude {reset}
14
15 set_system_mode analysis
16
17 # Run X-source analysis
18 analyze_xbounding
19 report_xbounding -verbose -ignored_x_sources on
20
21 ## Perform wrapper analysis and insertion
22 # Exclude the edt_channel in and out ports from wrapper analysis
23 # The ijtag_* edt_update ports are automatically excluded
24 set_wrapper_analysis_options -exclude_ports \
25 [ get_ports {*_edt_channels_*} ]
26
27 # Add a new wrapper dedicated cell on reset
28 set_dedicated_wrapper_cell_options on -ports { reset }
29 set_wrapper_analysis_options -input_fanout_flop_threshold 100 \
30 -output_fanin_flop_threshold 40
31

382 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Performing ATPG Pattern Generation: Hybrid TK/LBIST
32 # Perform wrapper cell analysis
33 analyze_wrapper_cells
34 report_wrapper_cells -Verbose
35
36 # Find the edt_instance
37 # Instance of module *edt_lbist_c0
38 set edt_instance [get_instances -of_icl_instances [get_icl_instances
\
39 -filter tessent_instrument_type==mentor::edt]]
40
41 # Connect scan chains to the EDT signals
42 add_scan_mode int_mode -type internal -edt_instances $edt_instance
43 add_scan_mode ext_mode -type external -chain_count 2
44 analyze_scan_chains
45
46 analyze_scan_chains
47 report_scan_chains
48
49 # Insert scan chains and write the scan-inserted design into the
TSDB
50 insert_test_logic
51
52 report_scan_chains
53 report_scan_cells
54
55 exit

Related Topics
Performing Scan Chain Insertion: Wrapped Core

Performing ATPG Pattern Generation: Hybrid

TK/LBIST
ATPG pattern generation for the hybrid TK/LBIST flow includes a process for generating controller chain
mode patterns to test the TK/LBIST logic itself.
For details, refer to "Performing Pattern Generation for CCM in the TSDB Flow" in the Hybrid TK/LBIST
Flow User’s Manual.

Note:
The line numbers used in this procedure refer to the command flow dofile in Example 17 on
page 384.

Prerequisites
• Perform EDT pattern generation as described in “Performing ATPG Pattern Generation” on
page 212.

Tessent™ Shell User’s Manual 383

Tessent Shell Workflows
Performing ATPG Pattern Generation: Hybrid TK/LBIST

Procedure
1. Load the design and set the environment (refer to lines 1-12). Refer to “Loading the Design” on
page 199 for more information.

2. Enable CCM (refer to lines 16-17).

set_static_dft_signal_values controller_chain_mode 1

You had added a DFT signal for ccm_en during IP creation, which is now being configured. If this is
a port (default), then this command is not required.

3. Define the scan chain for CCM (refer to lines 19-22).

4. Specify tck or edt_clock for CCM, depending on which you are using in your implementation (refer
to lines 24-25).

5. Define the pin constraints (refer to lines 33-37).

You must disable core clock and reset activity. If ccm_en was not added as a DFT signal, then also
include a pin constraint for it (enabled).

6. For retargeting, specify to pulse the CCM clock during shift. (refer to line 39.) The following
command is only required when you use edt_clock for CCM and edt_clock is a top-level port, or
when you use tck for CCM.

set_procedure_retargeting_options -pulse_during_shift edt_clock

The tool automatically generates a test procedure file that configures the scan_en and
shift_capture_clock DFT signals. If the edt_clock is derived from test_clock, do not specify the
set_procedure_retargeting_options command.

7. Specify the set_current_mode command with a unique name to indicate that you are generating
CCM patterns (refer to line 41). For example:

set_current_mode ccm_stuck

8. Create and write the patterns (refer to lines 43-60).

Examples
The following example generates CCM ATPG patterns. The highlighted statements illustrate additional
considerations for CCM.

Example 17. Dofile Example for ATPG With Controller Chain Mode: Hybrid TK/LBIST

1 ### DESIGN VARIABLES

2 set DesignName piccpu
3 set DesignLevel physical_block
4
5 set_context patterns -scan
6 set_tsdb_output_directory ../tsdb_outdir
7 read_cell_library ../lib/tessent/adk.tcelllib \
8 ../lib/tessent/picdram.atpglib

384 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Performing ATPG Pattern Generation: Hybrid TK/LBIST
9 set_design_source -format tcd_memory -y ../lib/tessent -extension
memlib
10
11 # Read in the scan-inserted design
12 read_design $DesignName -design_id gate2
13
14 report_dft_signals
15
16 # Enable CCM
17 set_static_dft_signal_values controller_chain_mode 1
18
19 add_scan_groups grp1
20 # These are the required scan chains for CCM
21 add_scan_chains ccm_chain grp1 control_chain_scan_in \
22 control_chain_scan_out
23
24 # Add edt_clock or tck as the primary clock source for CCM
25 add_clock 0 tck
26
27 # Specify clocks driven by primary-input ports; this is optional
28 add_clocks 0 clk
29 add_clocks 0 ramclk
30 add_clocks 0 reset
31 add_clocks 0 test_clock
32
33 # Define the pin constraints
34 add_input_constraints clk -c0
35 add_input_constraints ramclk -c0
36 add_input_constraints reset -c0
37 add_input_constraints test_clock -c0
38
39 set_procedure_retargeting_options -pulse_during_shift edt_clock
40
41 set_current_mode ccm_stuck
42
43 set_system_mode analysis
44 add_fault -module [ get_module *tessent* ]
45 report_clocks
46
47 create_patterns
48 report_statistics -detailed_analysis
49
50 report_statistics -instance piccpu_rtl2_tessent_lbist
51 report_statistics -instance \
52 piccpu_rtl2_tessent_lbist_ncp_index_decoder_inst
53 report_statistics -instance
piccpu_rtl2_tessent_single_chain_mode_logic
54 report_statistics -instance piccpu_rtl2_tessent_edt_lbist_c0_inst
55
56 write_tsdb_data -replace
57 write_patterns ${DesignName}_ccm_stuck_parallel.v -verilog -parallel
\
58 ‑replace

Tessent™ Shell User’s Manual 385

Tessent Shell Workflows
Performing LogicBIST Fault Simulation
59 write_patterns ${DesignName}_ccm_stuck_serial.v -verilog -serial \
60 ‑replace
61
62 exit

Performing LogicBIST Fault Simulation

Perform LogicBIST fault simulation on the scan-inserted, gate-level design. LogicBIST fault simulation
generates pseudo-random, parallel pattern sets.
Refer to "Parallel Versus Serial Patterns" in the Tessent Scan and ATPG User’s Manual for more
information.

Note:
The line numbers used in this procedure refer to the command flow dofile in Example 18 on
page 387.

Procedure
1. Load the design and set the environment (refer to lines 1-12). Refer to “Loading the Design” on
page 199 for more information.

2. Set the current test mode to a unique name for the new pattern set you are creating to test the
hybrid IP. (Refer to line 7.)

3. Import the core’s internal mode data. (Refer to line 9.)

Tessent Shell imports the scan-inserted design data for the EDT and OCC logic. For LogicBIST
fault simulation, the tool requires EDT for PRPG/compactor/MISR configuration and chain tracing,
and OCC for the clocks. Using the import_scan_mode command assumes that you used Tessent
Scan to perform scan chain stitching.
For LogicBIST fault simulation, only the internal mode data is valid.

4. Add the hybrid TK/LBIST core instances. (Refer to lines 11-12.) For example:

add_core_instances -instance piccpu_rtl2_tessent_lbist

For the hybrid TK/LBIST flow, you must explicitly add the LogicBIST controller core.

5. Specify the capture procedure names with the set_lbist_controller_options command. (Refer to
lines 16-18.)
Include the names of all Named Capture Procedures (NCPs) that are defined in the
DftSpecification, along with their active percentages, regardless of whether you intend to use them
in LogicBIST simulation.
The tool defines the NCPs in the Tessent Core Description (TCD) file while processing the
DftSpecification. You can override the automatically generated NCPs with the read_procfile
command.

6. Define the DFT signals (refer to lines 23-37). In addition to enabling the ltest_en and int_ltest_en
logic test control signals, you must specify the following signals for the hybrid TK/LBIST flow:

386 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Performing LogicBIST Fault Simulation

set_static_dft_signal_values control_test_point_en 1
set_static_dft_signal_values observe_test_point_en 1
set_static_dft_signal_values xbounding_en 1
set_static_dft_signal_values tck_occ_en 1
set_static_dft_signal_values controller_chain_mode 0

7. Set the PLL external capture clocks if your design has a PLL that is a driving clock, but the PLL
itself is driven by external clocks. (Refer to lines 43-46.)
This indicates the number of cycles the NCPs take with respect to the LogicBIST controller clock,
as specified with the -fixed_cycles switch.

8. Specify the maximum number of pseudo-random patterns you want the tool to simulate. (Refer to
line 48.)

9. Set the pattern source to LogicBIST and run fault simulation. (Refer to line 51.)

10. Write out the parallel testbench and save all the data into the TSDB. (Refer to lines 53-57.)

Examples
The following dofile example shows a typical command flow as detailed in the preceding procedure. The
highlighted text illustrates additional considerations for the hybrid TK/LBIST flow.

Example 18. Dofile Example for LogicBIST Fault Simulation

1 set_context pattern -scan -design_id gate2

2 set_tsdb_output_directory ../tsdb_outdir
3 read_cell_library ../lib/tessent/adk.tcelllib ../rtl/picdram.atpglib
4 read_design piccpu
5 set_current_design piccpu
6
7 set_current_mode lbist
8
9 import_scan_mode int_mode
10
11 # Explicitly add the LogicBIST controller core
12 add_core_instances -instance piccpu_rtl2_tessent_lbist
13 # EDT and OCC are loaded with the int_mode imported scan mode
14
15
16 # Define the number of patterns per NCP capture window
17 set_lbist_controller_options -capture_procedure {clk_occ_ncp 70 \
18 ramclk_occ_ncp 10 ALL_occ_ncp 10 sti_occ_ncp 10}
19
20 add_input_constraint test_clock -c0
21 add_nofault [get_instance *tessent*]
22
23 # Set the DFT signals
24 set_static_dft_signal_values ltest_en 1
25 # The following DFT signal is inferred by ltest_en 1 if you have
memory
26 # set_static_dft_signal_value memory_bypass_en 1

Tessent™ Shell User’s Manual 387

Tessent Shell Workflows
Perform LogicBIST Pattern Generation
27
28 set_static_dft_signal_values control_test_point_en 1
29 set_static_dft_signal_values observe_test_point_en 1
30 set_static_dft_signal_values x_bounding_en 1
31
32 set_static_dft_signal_values int_mode 1
33 # The following DFT signal is inferred by int_mode 1
34 # set_static_dft_signal_values int_ltest_en 1
35
36 set_static_dft_signal_values tck_occ_en 1
37 set_static_dft_signal_values controller_chain_mode 0
38
39 report_static_dft_signal_settings
40
41 set_system_mode analysis
42
43 # Specify the number of cycles the NCPs take with respect to the
LogicBIST
44 # controller clock
45 # This ensures that the tool runs the testproc correctly
46 set_external_capture_options -fixed_cycles 4
47
48 set_random_patterns 1000
49 add_faults -all
50
51 simulate_patterns -source bist -store_patterns all
52
53 # Write the parallel pattern Verilog testbench
54 write_patterns piccpu_lbist_parallel.v -verilog -parallel -replace \
55 -parameter_list {SIM_POST_SHIFT 3}
56 # Save the TCD, PatternDB, flat model, and fault list to the TSDB
57 write_tsdb_data -replace
58
59 exit

Perform LogicBIST Pattern Generation

Generate LogicBIST patterns using the scan-inserted and LogicBIST fault simulated design. The process
includes IJTAG pattern retargeting from the extracted ICL module description for the design. Tessent
Shell translates (or retargets) the PDL commands so that you can control the LogicBIST controller
through the TAP controller/IJTAG infrastructure.

Note:
Do not confuse IJTAG retargeting with ATPG (or scan) pattern retargeting as described in
“Hierarchical DFT Terminology” on page 217.

388 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Perform LogicBIST Pattern Generation

Procedure
1. Load the design and set the environment (refer to lines 1-12). Refer to “Loading the Design” on
page 199 for more information.

2. Set the context to patterns -ijtag and set the design ID to the name of the scan-inserted, gate-level
netlist generated during scan chain insertion.
When you specify the -ijtag switch, Tessent Shell automatically accesses the ICL module
description for the current design, which enables IJTAG retargeting mode.

3. Define clocks and constraints (refer to lines 7-10).

4. Generate and validate the IJTAG patterns for the design (refer to lines 14-16).

5. Run and check the testbench simulations (refer to lines 18-23). The following step is important for
the hybrid TK/LBIST flow:

a. Specify the simulator option to keep all the logic gates for simulation.
®
The following example applies to Questa SIM:

run_testbench_simulations -simulator_options \
{ -voptargs="+acc" }

For correct pattern simulation, use the applicable simulator option to ensure that the necessary
design logic is not optimized away during elaboration.
Tessent Shell simulates the logic test operations only, which means the testbench does not
connect all the pins in the design. The tool issues warnings for the unconnected pins. To
filter these warnings out, you can use the run_testbench_simulations -simulation_option
+nowarnTSCALE option.

Examples
The following dofile shows a command flow to generate IJTAG patterns for LogicBIST. Highlighted text
illustrates additional considerations for the hybrid TK/LBIST flow.

1 set_context patterns -ijtag -design_id gate2

2 read_cell_library ../lib/tessent/adk.tcelllib ../rtl/picdram.atpglib
3 set_tsdb_output_directory ../tsdb_outdir
4 read_design piccpu
5 set_current_design piccpu
6
7 # This is the clock driving the internal PLL
8 add_clocks 0 clk -period 100ns
9 # Scan enable has to be tied to low
10 add_input_constraint scan_en -c0
11
12 set_system_mode analysis
13
14 read_config_data ./lbist_mbist_pattern.patspec
15
16 process_patterns_specification
17
18 set_simulation_library_sources -v { ../lib/verilog/adk.v \

Tessent™ Shell User’s Manual 389

Tessent Shell Workflows
Perform LogicBIST Pattern Generation
19 ../lib/verilog/picdram.v ../lib/verilog/SYNC_1R1W_256x16.v }
20
21 run_testbench_simulation -simulator_options { -voptargs="+acc" \
22 -quiet} -wait
23 check_testbench_simulations -report_status
24
25 exit

390 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Running Multiple Load ATPG on Wrapped Core Memories With Built-In Self Repair

Running Multiple Load ATPG on Wrapped

Core Memories With Built-In Self Repair
If your design has wrapped cores that include repairable memories, and you want to test the logic around
the memories at speed, then you use multiple load ATPG patterns.

Overview of Multiple Load ATPG on Memories for Wrapped Cores With Built-in Self Repair
Performing Multiple Load ATPG Pattern Generation
Performing Multiple Load Top-Level ATPG Pattern Retargeting

Overview of Multiple Load ATPG on Memories for

Wrapped Cores With Built-in Self Repair
When generating ATPG multiple load patterns for memories with Built-In Self Repair (BISR), the
memories inside the wrapped cores are tested first. If any memories need to be repaired because of
defects that are present inside the memory, then the BISR registers are programmed such that the
contents of these registers vary based on the repair solution that is stored in the fuses at the parent level.
To generate multiple load ATPG patterns, the BISR registers need to be excluded from the retargetable
ATPG patterns that you created for the wrapped core. At the wrapped core level, a test_setup_iCall
resets the BISR registers, resulting in all spare elements being unallocated before ATPG is run. Only
the memory control ports and data ports participate in the ATPG patterns; the memory repair ports are
excluded. If memory defects are detected and repaired via the BISR registers, the retargeted ATPG
patterns also pass.
You must provide an ATPG model of the eFuse/OTP during pattern generation to meet the E14 design
rule requirements. If such a model is not available, you can instead provide an input constraint on the
fuseValue output pin of the eFuse/OTP interface module. To do this, create a pseudo-port associated with
the fuseValue output pin of the fuse box interface instance. Then, add a constant 0 input constraint on the
"fuseValue" pseudo-port, as shown in the following example:
add_primary_inputs chip_rtl_tessent_mbisr_controller_inst/ \
chip_rtl_tessent_mbisr_generic_fusebox_interface_instance/fuseValue \
-pseudo_port_name fuseValue
add_input_constraints -c0 fuseValue

For more details, refer to the add_primary_inputs and add_input_constraints commands.

Performing Multiple Load ATPG Pattern Generation

When you need to generate multiple load ATPG patterns when the memory is not bypassed but used
during ATPG there is no difference in the flow steps used for inserting DFT. You use this procedure to
bypass the memories.
The DFT insertion at the wrapped core level for memories with BISRs is similar to the two-pass pre-scan
DFT insertion process for wrapped cores with the primary difference being the ATPG pattern generation.
There are no changes to creating the graybox model, and running the wrapped core in external mode for
stuck and transition patterns by bypassing the memories. There are no changes for running the wrapped
core in internal mode for stuck and transition patterns by bypassing the memories.

Tessent™ Shell User’s Manual 391

Tessent Shell Workflows
Performing Multiple Load ATPG Pattern Generation

You should be familiar with the two-pass pre-scan DFT insertion flow as described in “RTL and Scan
DFT Insertion Flow for Physical Blocks” on page 221, especially as related to performing ATPG pattern
generation. Figure 86 shows this flow.

Figure 86. Two-Pass Insertion Flow for RTL, Wrapped Cores

The init_bisr_chains iProc contains Tcl code you can use to initialize the BISR registers at any level (core
or chip-level) as follows:

• At the wrapped core level, the iProc performs an asynchronous clear of the BISR registers.

• At the chip-level, the iProc initiates a BISR controller power-up emulation.

The power-up emulation clears the BISR registers if the fuse box has not been programmed, or initializes
the BISR registers with the repair data if memory repair information was programmed in the fuse box.
Refer to "Creating and Inserting the BISR Controller" in the Tessent MemoryBIST User's Manual.

Note:
The line numbers used in this procedure refer to the command flow dofile in Example 19 on
page 393.

Prerequisites
• You have performed the “RTL and Scan DFT Insertion Flow for Physical Blocks” on page 221 up
to the ATPG pattern generation step.

Procedure
1. Load the Tessent Cell Library for the memory. (Refer to lines 1-9.)

2. Load the design. (Refer to lines 11-13.)

3. Set the DFT Signal memory_bypass to 0, so memory is not bypassed. (Refer to lines 24-26.)

4. Load the PDL for the Memory BISR chains, which has an iProc (init_bisr_chains) that is called with
set_test_setup_icall -non_retargetable. (Refer to lines 28-35.)

392 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Performing Multiple Load ATPG Pattern Generation

The init_bisr_chains iProc contains Tcl code you can use to initialize the BISR registers at any level
(core or chip-level) as follows:

• At the wrapped core level, the iProc performs an asynchronous clear of the BISR registers.

• At the chip level, the iProc initiates a BISR controller power-up emulation.

5. Generate the multiple load ATPG patterns. (Refer to lines 39-40.)

6. Write the design data and patterns to the TSDB. (Refer to lines 42-44.)

7. Write out the Verilog testbenches for simulation. (Refer to lines 47-50.)

Results
At the wrapped core level, if you inject a fault in the repairable memory, and then run the multiple load
ATPG Pattern, the run should fail. This check shows that if a repairable memory has a defect that is not
repaired, then when you retarget the multiple load ATPG patterns from the top level, the multiple load
ATPG pattern run fails.
You must run the memoryBIST inside the wrapped core to determine if the memory is repairable. If it is,
then the repairable information from Built-In Redundancy Analysis (BIRA) to BISR must be stored and the
repair performed by storing the repairable contents using the fusebox repair solution that you use at the
top-level.

Examples
The following example for the repairable memory "MGC_SYNC_1RW_1024x8_C" generates ATPG
patterns that is run by the memory.

Example 19. Multiple Load ATPG Pattern Generation for Memories With BISR

1 set_context patterns -scan

2
3 # Set the location of the TSDB. Default is the current working
directory.
4 set_tsdb_output_directory ../tsdb_outdir
5
6 # Read Tessent Library
7
read_cell_library ../../../library/standard_cells/tessent/adk.tcelllib
8 # Read the Tessent Cell Library for the memory
9
read_cell_library ../../../library/memories/MGC_SYNC_1RW_1024x8_C.atpglib
10
11 # Read in the scan inserted netlist/design
12 read_design processor -design_id gate -verbose
13 set_current_design processor
14
15 # Specify the current mode using a different name than what was used
16 # with the add_scan_mode command
17 set_current_mode edt_int_multiple_load_atpg -type internal
18 report_dft_signals
19

Tessent™ Shell User’s Manual 393

Tessent Shell Workflows
Performing Multiple Load Top-Level ATPG Pattern Retargeting
20 # Extract the scan chains using the internal mode specified during
21 # scan insertion with the add_scan_mode command
22 import_scan_mode int_mode -fast_capture_mode on
23
24 # Memory is used during ATPG, by setting the DFTSignal memory_bypass
25 # to "0"
26 set_static_dft_signal_values memory_bypass_en 0
27
28 # Read in the PDL for the memory BISR
29 source \
30 ../tsdb_outdir/instruments/processor_rtl1_mbisr.instrument/\
31 processor_rtl1_tessent_mbisr.pdl
32
33 # Specify the iProc init_bisr_chains for the memory BISR as
34 # non_retargetable
35 # If the block contains a dedicated BISR controller, add -front to
the
36 # following command.
37 set_test_setup_icall init_bisr_chains -non_retargetable
38
39 report_statistics -detail
40 # Generate patterns
41 create_patterns
42 report_statistics -detail
43
44 # Store TCD, flat_model, fault list and patDB format files in the
TSDB
45 # directory
46 write_tsdb_data -replace
47
48 # Write testbenches for Verilog simulation
49 write_patterns patterns/processor_multiple_load_parallel.v \
50 -verilog -parallel -replace
51 write_patterns patterns/processor_multiple_load_serial.v \
52 -verilog -serial -replace
53 exit

Performing Multiple Load Top-Level ATPG Pattern

Retargeting
When you have wrapped cores with repairable memories, then at the chip-top level you need to insert a
memory BISR controller. This can be done along with the TAP, boundary scan, and MemoryBIST insertion
if there are any memories present at the top-level.
You should be familiar with the RTL and scan DFT fnsertion flow for the top as described in “RTL and
Scan DFT Insertion Flow for the Top Chip” on page 240, especially as related to performing ATPG pattern
retargeting. Figure 87 shows this flow.

394 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Performing Multiple Load Top-Level ATPG Pattern Retargeting

Figure 87. Two-Pass Insertion Flow for RTL, Top Level

For retargeting multiple load ATPG patterns where the memories are not bypassed from a lower level
wrapped core that has repairable memories, specify the correct retargeting mode signal. Subsequently,
use the add_core_instances command to load the specific core with the correct ATPG mode that you
want to retarget.
Finally, you need to source the PDL of the BISR chain with the iProc init_bisr_chains. This PDL was
created when the BISR controller RTL was generated at the chip-level. The iProc detects the presence of
the BISR controller and initiates a PowerUpEmulation. When the iProc is called and no BISR controller is
found, the iProc performs an asynchronous clear of the BISR chains using the primary inputs (bisr_reset
port).

Note:
The line numbers used in this procedure refer to the command flow dofile in Example 20 on
page 396.

Prerequisites
• You have performed the “RTL and Scan DFT Insertion Flow for the Top Chip” on page 240 up to
the ATPG retargeting step.

Procedure
1. Set the context to pattern retargeting. (Refer to lines 1-2.)

2. Specify the TSDB directory and open the TSDB. (Refer to lines 4-8.)

3. Read the Tessent Cell Library. (Refer to lines 10-11.)

4. Load the Verilog design. (Refer to lines 13-15.)

5. Set the retargeting from the lower-level patterns. (Refer to lines 20-24.)

Tessent™ Shell User’s Manual 395

Tessent Shell Workflows
Performing Multiple Load Top-Level ATPG Pattern Retargeting

6. Read the PDL of the memoryBISR chains that has the iProc "init_bisr_chains". This PDL is
different than the one created at the wrapped core level. (Refer to lines 30-34.)

7. Change mode to analysis. (Refer to line 36.)

Examples
The following example retargets the ATPG pattern from the lower level to the chip-level.

Example 20. ATPG Pattern Retargeting for Memories With BISR

1 # Set the context to retarget ATPG Patterns from lower level child
cores
2 set_context pattern -scan_retargeting
3
4 # Point to the TSDB directory
5 set_tsdb_output_directory ../tsdb_outdir
6
7 # Open all the TSDB of the child cores
8 open_tsdb ../../wrapped_cores/processor/tsdb_outdir
9
10 # Read the tessent cell library
11 read_cell_library ../../library/standard_cells/tessent/adk.tcelllib
12
13 # Read the verilog
14 read_design chip_top -design_id gate
15 read_design processor -design_id gate -view graybox -verbose
16
17 set_current_design chip_top
18
19
20 # Retarget Transition patterns from processor
21 set_current_mode retarget1_processor_multiple_load
22 set_static_dft_signal_values retargeting1_mode 1
23 add_core_instances -instances {processor_inst1 processor_inst2} \
24 -core processor -mode edt_int_multiple_load_atpg
25
26 report_core_descriptions
27 import_clocks -verbose
28 report_clocks
29
30 # Read the PDL of the MBISR chains that has the iProc
"init_bisr_chains"
31 # that needs to be called before running the ATPG pattern.
32 source ../tsdb_outdir/instruments/chip_top_rtl1_mbisr.instrument/\
33 chip_top_rtl1_tessent_mbisr.pdl
34 set_test_setup_icall init_bisr_chains -front
35
36 set_system_mode analysis
37 report_clocks
38
39 # write the TCD file for chip-level in the TSDB outdir
40 write_tsdb_data -replace

396 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Performing Multiple Load Top-Level ATPG Pattern Retargeting
41 # Read the patterns to be retargeted
42 read_patterns -module processor -fault_type transition
43 set_external_capture_options -pll_cycles 5 [lindex
[get_timeplate_list] 0]
44
45
46 # Write Verilog patterns for simulation
47 write_patterns patterns/processor_edt_multiple_load_retargeted.v \
48 -verilog -parallel -replace -begin 0 -end 7 -pattern_sets scan \
49 write_patterns
patterns/processor_edt_multiple_load_retargeted_serial.v \
50 -verilog -serial -replace -Begin 0 -End 2 \
51 exit

Tessent™ Shell User’s Manual 397

Tessent Shell Workflows
Built-In Self Repair in Hierarchical Tessent MemoryBIST Flow

Built-In Self Repair in Hierarchical Tessent

MemoryBIST Flow
You use the BISR registers to control the repair ports of repairable memory. The BISR logic insertion
tasks include inserting BISR chains in a block and connecting a BISR controller to existing BISR chains,
to an external fuse box, and to system logic. This omits the additional BISR capabilities of Repair Sharing
and Fast BISR Loading.
You perform the first two tasks in a bottom-up, hierarchical design methodology where BISR chains are
inserted in lower-level blocks before being connected at the chip top level to the BISR controller. This is
the most frequently used method for inserting the repair logic.
You complete the BISR insertion task with the memoryBIST insertion in the same pass at the block or
chip level. If the BISR insertion task is carried out separately from the memory BIST insertion, you must
perform BISR insertion after you have completed all memoryBIST insertion tasks at the block or chip level
in a single pass.
If you use Tessent Scan, do not scan test the BISR hardware if you plan to generate multiple load
patterns for logic test. Tessent Scan does this automatically.
In contrast, if you use a third-party scan insertion tool, then the non_scannable_instance_list in the
dft_info_dictionary should be honored and is located in the TSDB in the dft_inserted_designs directory—
refer to “RTL and DFT Insertion Flow With Third-Party Scan” on page 263.
For additional information, refer to “First DFT Insertion Pass: Performing Top-Level MemoryBIST and
Boundary Scan” on page 243.
You can also find related information in the Tessent MemoryBIST User’s Manual in the topics "Repair
Sharing Overview" and "Fast BISR Loading Overview".
The flow consists of the following steps:

Performing Block-Level BISR Insertion

Performing Chip-Level BISR Insertion
Verification of Block- and Chip-Level BISR

Performing Block-Level BISR Insertion

The insertion of BISR chains is automatic if memories instantiated in the design have spare resources
described in their memory library file. BISR registers associated to repairable memories are connected
together to form scan chains.

Assigning Memories to Power Domains

By default, all repairable memories are part of the same power domain, and the tool creates a single
BISR chain. If, however, more than one power domain exists, multiple BISR chains are required.
The tool determines the power domain of a memory instance by its bisr_power_domain_name attribute,
which you specify in the following two ways:

398 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Performing Block-Level BISR Insertion

• Reading a CPF or UPF file corresponding to the design using the read_cpf or read_upf
command. This is the recommended method.

• Manually setting the bisr_power_domain_name attribute using the set_attribute_value command.

The following example defines power domains with UPF:
UPF:
create_power_domain pd_A
create_power_domain pd_AA -element {mem3 mem4}
create_power_domain pd_AB -element {mem5 mem6}

Generate BISR segment order file:

BisrSegmentOrderSpecification {
PowerDomainGroup(pd_AA) {
OrderedElements {
mem3;
mem4;
}
}
PowerDomainGroup(pd_AB) {
OrderedElements {
mem5;
mem6;
}
}

For additional implementation details, refer to "Inserting BISR Chains in a Block" in the Tessent
MemoryBIST User's Manual.

Controlling the BISR Chain Order

BISR chains are connected according to the content of the BisrSegmentOrderSpecification wrapper
containing a list of memory instances defining the BISR chain order.
This file is generated automatically when check_design_rules successfully completes. When a DEF file
is provided, the BISR segments are ordered using an algorithm that optimizes the routing based on the
memory coordinates. If a DEF file is not provided, the memories are sorted alphabetically within each
power domain group.
If you want to change the generated BISR change order, you can manually modify the
<design_name>.bisr_segment_order file and change the order of memory instance names before running
the process_dft_specification command.

Turning Off Insertion of BISR Registers

It is possible to deactivate the generation of BISR registers for specific memory instances.
You do this by issuing the set_memory_instance_options command as follows:
set_memory_instance_options memory_inst -use_in_memory_bisr_dft_specification off

Tessent™ Shell User’s Manual 399

Tessent Shell Workflows
Performing Block-Level BISR Insertion

Excluding Child Block BISR Chains

When you do not implement memory repair in a parent design but integrate sub-blocks or physical blocks
that already contain BISR chains, you must not connect or use these chains, and you must properly tie
the chains off.

Note:
This is not a typical use model and is rarely implemented.

Related Topics
Inserting BISR Chains in a Block

Excluding Child Block BISR Chains

400 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Performing Chip-Level BISR Insertion

Performing Chip-Level BISR Insertion

As with the block level, the insertion of BISR chains is automatic if memories instantiated in the design at
the chip level have spare resources. When you insert chip level BISR, you must also choose a functional
repair clock and connect the BISR controller to an existing BISR chain, an external fuse box, and to
system logic.

Functional Repair Clock

Connection of the BISR Controller to Existing BISR Chains
Connection of the BISR Controller to an External Fuse Box
Connection of the BISR Controller to System Logic

Functional Repair Clock

The distributed architecture and conservative clocking methodology used for self-repair require some care
in the selection of the functional repair clock used to apply repairs during chip power up. You should use a
functional clock of 10 MHz or less in that functional mode.
For implementation details, refer to "Inserting BISR Chains in a Block" in the Tessent MemoryBIST User's
Manual.

Connection of the BISR Controller to Existing BISR

Chains
As with block level BISR insertion, BISR chains are connected according to the content of the
BisrSegmentOrderSpecification wrapper containing a list of memory instances defining the BISR chain
order as well as lower level blocks containing pre-inserted BISR chains.
The tool automatically generates this file when the check_design_rules command successfully completes.
The following example shows two instances of the same block (blockA, instances blockA_clka_i1 and
blockA_clkb_i2), which has two BISR chains partitioned by two power domains (pd_AA and pd_AB):

BisrSegmentOrderSpecification {
PowerDomainGroup(pd_AA) {
OrderedElements {
blockA_clka_i1/pd_AA_bisr_si;
blockA_clkb_i2/pd_AA_bisr_si;
}
}
PowerDomainGroup(pd_AB) {
OrderedElements {
blockA_clka_i1/pd_AB_bisr_si;
blockA_clkb_i2/pd_AB_bisr_si;
}
}
}

As with the block-level BISR insertion, if you change the generated BISR chain order
(<design_name>.bisr_segment_order), you can manually modify this file and change the order of memory
instance names before running the process_dft_specification command.

Tessent™ Shell User’s Manual 401

Tessent Shell Workflows
Connection of the BISR Controller to an External Fuse Box

Connection of the BISR Controller to an External Fuse

Box
The BISR controller hardware is created at the top level of the chip automatically. The BISR controller is
accessed using the TAP. The BISR chain control ports are automatically connected to the BISR controller.
The BISR controller is also connected to the fuse box. A typical implementation of BISR is with an
external fuse box.
The hardware implements several functions and can be used to perform the following operations:

• Compress the repair information and write the result into the fuse box

• Decompress the fuse box contents and shift the contents into the chip BISR chain

• Initialize or observe BISR chain content via the TAP

• Read and program fuses via the TAP

Note:
A BISR controller with an internal fuse box is supported. For details, refer to "Implementing and
Verifying Memory Repair" in the Tessent MemoryBIST User's Manual.

The design instance for the external fuse box must already be instantiated in the design. Typically, the
fuse box is instantiated within a module that also contains interface logic. All input ports of the module
should be tied off, and the output ports should be left open. When running the process_dft_specification
command, the tool disconnects all input ports and then reconnects the ports to the BISR controller
module.
When using an external fuse box, you must set the fuse_box_location property in the
MemoryBisr/Controller wrapper to external. The fuse_box_interface_module property located in the
same wrapper can be used to specify the library module for the external fuse box. If this is not specified,
the library module is inferred from the design instance specified in the design_instance property
of ExternalFuseBoxOptions wrapper. If neither of these properties are specified and only a single
tcd_fusebox file exists in the design, the fuse box module is inferred from this tcd_fusebox description.
The core description for the external fuse box can automatically be read in during module matching using
the set_design_sources -format tcd_fusebox command or directly using the read_core_descriptions
command.
If the instantiated module has a core description with a FuseBoxInterface wrapper, then connections
between the fuse box controller and the fuse box interface are completed automatically. If a core
description is not available, or not complete, explicit connections can be made in the MemoryBisr/
Controller/ExternalFuseBoxOptions/ConnectionOverrides wrapper.

Related Topics
Fuse Box Interface

Connecting the BISR Controller to an External Fuse Box

402 Tessent™ Shell User’s Manual

 Tessent Shell Workflows
Connection of the BISR Controller to System Logic

Connection of the BISR Controller to System Logic

Typically, system logic is connected to the BISR controller for initiating memory repair and monitoring the
progress of the operation. All connections are specified in the DftSpecification configuration file in the
MemoryBisr:Controller section.

• The BISR controller input clk must be driven by an appropriate functional clock. The
connection is made by specifying the repair_clock_connection property in the DftSpecification/
MemoryBisr/Controller wrapper.

• The BISR controller input resetN is the signal used to reset the BISR chains and initiate memory
repair. The connection is made by specifying the repair_trigger_connection property in the
DftSpecification/MemoryBisr/ wrapper.

Verification of Block- and Chip-Level BISR

You must verify the BISR at both the block and chip level to guarantee functional hardware.

Block-Level BISR Verification

The default signoff is the PatternsSpecification you generate with Tessent Shell to test the connectivity of
the BISR chain using a pattern named MemoryBisr_BisrChainAccess.
You can create future verification patterns as follows:

• Running fault-inserted MemoryBIST

• Performing BIRA-to-BISR capture

◦ Scan external BISR chain into the internal BISR chain

• Running post-repair memory BIST

Chip-Level BISR Verification

The default signoff is the PatternsSpecification that you generate with Tessent Shell using the
create_patterns_specification command for the BISR hardware. PatternsSpecification verifies the
FuseBoxAccess, BisrChainAccess, and Autonomous modes of operation of the BISR controller and BISR
chains via the TAP.
You do not need to run memoryBIST with fault-inserted memories at the top level of the chip. This type of
verification is better performed at the block level where memoryBIST can be run on the full address space
of all memories.

Related Topics
PatternsSpecification

create_patterns_specification

Tessent™ Shell User’s Manual 403

Tessent Shell Workflows
Verification of Block- and Chip-Level BISR

Verifying BISR at the Block Level

Top-Level Verification and Pattern Generation

404 Tessent™ Shell User’s Manual

 Chapter 7
Tessent Shell Automotive Workflow
This chapter describes a pre-layout DFT insertion workflow that helps you meet the safety, quality, and
reliability requirements of the ISO 26262 "Road vehicles - Functional safety" standard. The usage model
provides capability for both manufacturing and in-system chip testing and diagnosis. It also provides
examples of how to run, and how to generate UDFM files for, Automotive-Grade ATPG.
This chapter highlights the important steps required for you to achieve the optimal automotive DFT
strategy early in your design process. At a high level, this is a comprehensive hybrid TK/LBIST two-pass
RTL and scan DFT insertion flow that includes MemoryBIST, MBISR, advanced BAP, boundary scan, and
in-system test.

Tip
This is an advanced-level workflow, which assumes knowledge about the Tessent Shell two-pass
DFT insertion process. Familiarize yourself with the basic hybrid TK/LBIST flow for flat models as
described in “Hybrid TK/LBIST Flow for Flat Designs” on page 369. In addition, because this is
a hierarchical design, the workflow described in this chapter follows the bottom-up DFT insertion
process as described in “Tessent Shell Flow for Hierarchical Designs” on page 217.

Refer to the following test case for a detailed usage example of the flow described in this section:

tessent_automotive_reference_flow_<software_version>.tgz

You can access this test case by navigating to the following directory:

<software_release_tree>/share/UsageExamples/

Introduction to Tessent Automotive

Test Case Overview and Objective
Core-Level DFT Insertion for Automotive
Top-Level DFT Insertion for the Automotive Flow
Functional Mode Fault Tolerance for Static IJTAG Signals

Introduction to Tessent Automotive

Designs with aggressive quality and reliability requirements, such as those required to comply with the
ISO 26262 standard, must exercise efficient test strategy to ensure high quality with very low defective
parts per billion (DPPB). One of the key ISO 26262 requirements is the ability to test safety-critical
portions of a system during power-on and periodically during in-system operation.
The Tessent product suite provides a flexible design flow that supports a high-level of automation and
integration, creating an RTL-based hierarchical automotive flow that you can use for implementation of a
DFT solution. It provides design rule checking, test planning, integration, and verification at the RTL- and
gate-level, and it achieves high coverage for functional logic, memories, and test IPs.

Tessent™ Shell User’s Manual 405

Tessent Shell Automotive Workflow
Introduction to Tessent Automotive

Figure 88. Integrated Tessent DFT Solution for Automotive

Tessent automotive includes the following features:

• Low-impact in-system test (IST).

◦ Low resource requirements to design system-side logic for IST.

◦ Interface to access IJTAG network at the chip or block level.

• Unified environment.

◦ Design introspection capabilities.

◦ Full access to design and pattern data.

◦ All information stored in one place, the Tessent Shell Database (TSDB).

• Test scheduling flexibility using an IJTAG infrastructure.

◦ The IST controller can access and operate any instrument in the IJTAG network.

◦ Any LogicBIST or MemoryBIST (IJTAG-compliant IP) test can be converted to in‑system test.

◦ Run the same or different tests multiple times during in-system operation.

• Verification setup.

◦ Test time is automatically calculated.

◦ ROM data contents are also generated for the IST controller.

◦ Designer can easily verify IST with Verilog simulation.

• Area optimization

406 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
Test Case Overview and Objective

◦ The hybrid TK/LBIST IP shares the compression logic for scan and LogicBIST.

◦ Several optimization schemes for MemoryBIST.

• Fully hierarchical flow.

◦ RTL-level generation and insertion.

◦ Enable flow automation by using DFT signals.

◦ Pattern re-targeting to generate and validate patterns at any level of the design hierarchy.

• Direct access to MemoryBIST.

◦ Advanced BIST access port (BAP) to access MemoryBIST and consider limited test time of
in-system test.

◦ Direct control of algorithm, operation set, step, and memories.

◦ Incremental repair to improve reliability of automotive application.

Test Case Overview and Objective

In the tessent_automotive_reference_flow test case, you perform an RTL and scan DFT pre-layout
insertion process in a bottom-up manner for each core and sub-block in the design. After inserting DFT
into all the lower-level physical blocks, perform the same insertion process into the parent blocks until you
reach the top level of the chip. You also create ATPG core-level and top-level patterns and perform ATPG
pattern re-targeting of the wrapped cores at the parent physical block and top level.

Note:
The test case and this chapter assume that you understand the Tessent concepts and terms for
hierarchical DFT as described in “Hierarchical DFT Overview” on page 126.

Your objective is to integrate the DFT IP and provide a mechanism to test your logic and memories during
in-system operation. Considering your in-system test time constraints and coverage requirements, you
must:

• Analyze and decide on the algorithms you want to run on the memories in-system for power-on
reset (PoR) and periodic test.

• Analyze and decide the number of pseudo-random patterns during PoR and periodic test. (This
depends on the scan chain length and shift clock frequency.)

• Insert test point and X-bounding cells for LogicBIST.

• Use the advanced BAP capability to provide a low-latency protocol for configuring the
MemoryBIST controller, running Go/NoGo tests, and monitoring the pass/fail status for in-system
and manufacturing test.

Tessent™ Shell User’s Manual 407

Tessent Shell Automotive Workflow
Test Case Overview and Objective

• Insert the in-system test (IST) IP to access IJTAG instruments in system, and, depending on the
length of your IJTAG network, insert the IST controller within individual cores as well as at the top
level. As a reference, the tool runs both CPU-based and DMA-based in-system test options.

• Test the inserted test logic. That is, the LogicBIST and EDT IP blocks in addition to testing the
core design logic. Do this by using controller chain mode, which enables you to generate ATPG
patterns that target the hybrid EDT/LBIST blocks and LogicBIST controller in addition to the
single chain mode logic and in-system test controller. While MemoryBIST IPs can be scan tested,
under EDT test mode you can test them in system through LogicBIST.

Design Overview
The test case uses an UltraSPARC (open-source) design with a processor core and two GPS basebands.
The processor core design includes non-repairable and repairable memory, and the GPS baseband is a
logic-only core that is instantiated twice.

Figure 89. Initial Design for Automotive Test Case

Following the bottom-up flow, you insert the following DFT logic at the core level.

408 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
Test Case Overview and Objective

Figure 90. DFT Integration at the Core Level for Automotive

After you have inserted the core-level IP, you perform top-level DFT logic insertion and integration,
followed by ATPG and pattern retargeting.

Figure 91. DFT Integration at the Top Level for Automotive

To test your IJTAG instrument in system and achieve high test coverage for your automotive IC, you insert
an IST controller that intercepts the TAP controller and run MemoryBIST tests. This test case inserts a
direct memory access (DMA) IST controller at the top level and a CPU-based IST controller within the
GPS baseband cores. Depending on your IJTAG network length, you might or might not need an IST
controller at the core. A single DMA IST controller could be sufficient to run MemoryBIST and other IJTAG
tests.

DFT Insertion Flow

The following figure shows that Tessent Shell generates a TSDB for each core, and then at the top level,
it uses the information stored in the core-level TSDBs for DFT integration.

Tessent™ Shell User’s Manual 409

Tessent Shell Automotive Workflow
Test Case Overview and Objective

Figure 92. DFT Insertion Flow for Automotive Test Case

For details about the TSDB data flow, refer to “TSDB Data Flow for the Tessent Shell Flow” on
page 473.

410 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
Core-Level DFT Insertion for Automotive

Core-Level DFT Insertion for Automotive

The process for inserting DFT into hierarchical designs is performed in a bottom-up process starting from
the lowest level blocks. This section describes how to perform the DFT insertion flow for the processor
core and GPS baseband cores.
For general information about the RTL and scan DFT insertion flow for physical blocks, refer to “RTL and
Scan DFT Insertion Flow for Physical Blocks” on page 221. (The section relates to a hierarchical test
case; however, the basic flow remains the same.)

DFT Insertion Flow for the Processor Core Physical Block

DFT Insertion Flow for the GPS Baseband Physical Block

Tessent™ Shell User’s Manual 411

Tessent Shell Automotive Workflow
DFT Insertion Flow for the Processor Core Physical Block

DFT Insertion Flow for the Processor Core Physical

Block
In addition to the MemoryBIST logic, during the first DFT insertion pass, insert the advanced BAP and
the built-in self-repair (BISR) IP, which includes built-in redundancy analysis (BIRA). You can control
whether to test the memory in the same controller step or not, depending on memory power domains, test
algorithms, and other design factors.
The advanced BAP enables certain feature overrides in the hardware default (hw_default) operating
mode of the MemoryBIST controller and reduces test time by eliminating shift cycles to serially configure
the controllers in the IJTAG environment.

Figure 93. DFT Insertion Flow for processor_core

First DFT Insertion Pass: processor_core

Second DFT Insertion Pass: processor_core
Test Point, X-Bounding, and Scan Insertion: processor_core
ATPG Pattern Generation: processor_core
LogicBIST Fault Simulation: processor_core
LogicBIST Pattern Generation: processor_core
Interconnect Bridge/Open UDFM Generation: processor_core
Cell-Neighborhood UDFM Generation: processor_core

412 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
First DFT Insertion Pass: processor_core
Automotive-Grade ATPG Pattern Generation: processor_core

First DFT Insertion Pass: processor_core

During the first DFT insertion pass, generate a default DFT specification for MemoryBIST that includes
the BISR/BIRA, and then edit the DFT specification to include the additional connections for the advanced
BAP.

Note:
The line numbers used in this procedure refer to the command flow dofile in Example 21 on
page 414.

For in-system tests, you can apply MemoryBIST during the power-on/off phase of the device operation or
periodically while the device is operating. For details, refer to the Tessent In-System Test User’s Manual.

Procedure
1. Load the RTL design data and set the design parameters. (Refer to lines 1-15.)

Note:
rtl1 is the recommended naming convention for the design ID for the first insertion pass,
but you can specify any name. Refer to Loading the Design for more information about
setting the design ID.

2. Set the set_dft_specification_requirements command to on for ‑memory_bist. (Refer to lines

17-18.)
When memory_test is on, memory_bist, memory_bisr_chains, and memory_bisr_controller default
to auto; otherwise, they default to off. memory_bisr_chain auto changes to on for physical blocks
having repairable memory, so the tool inserts a BISR chain with a BIRA engine created within the
MemoryBIST controller.

3. Define the design clocks. (Refer to lines 20-22.)

4. Check the design rules. (Refer to lines 24.)

5. Create the DFT specification. (Refer to lines 26-28.)

6. Edit the DFT specification to add the advanced BAP. (Refer to lines 30-76.)
You can configure the connections to control the BAP directly through your system logic, thus
bypassing the IJTAG network. Or, you can provide a way to control the advanced BAP as part of
the IJTAG network. For this test case, implement the first strategy. When utilizing the advanced
BAP feature, specify the options you plan to control directly using the ExecutionSelections wrapper
in the DFT specification, and then specify the BAP connections to the system logic. You can
specify the connections within the DftSpecification wrapper or through a post-insertion procedure.

7. Generate the DFT hardware, IJTAG network connectivity, and test patterns. (Refer to lines 79-86.)

8. Run simulations to verify the design. (Refer to lines 88-92.)

Tessent™ Shell User’s Manual 413

Tessent Shell Automotive Workflow
First DFT Insertion Pass: processor_core

Examples
The following dofile example shows a typical automotive command flow for a core-level first DFT
insertion. Modify the DFT specification for your design requirements.

Example 21. Dofile Example for First DFT Insertion Pass, processor_core

1 # Load the design

2 set_context dft –rtl -design_id rtl1
3 set_tsdb_output_directory ../tsdb_outdir
4
read_cell_library ../../../lib/standard_cells/tessent/adk.tcelllib \
5 set_design_source -format tcd_memory -y ../../../library/memories
6 ‑extension tcd_memory
7 read_verilog ../../../library/memories/SYNC_1RW_32x16_RC.v
8 ‑interface_only -exclude_from_file_dictionary
9 read_verilog ../../../library/memories/SYNC_1RW_8Kx16_RC.v
10 ‑interface_only -exclude_from_file_dictionary
11 read_verilog -f rtl_file_list
12
13 set_current_design processor_core
14
15 set_design_level physical_block
16
17 # Specify the DFT requirements
18 set_dft_specification_requirements -memory_test on
19
20 # Define memory clock
21 add_clocks 0 dco_clk -period 3
22 add_clocks 0 directclk -period 12
23
24 check_design_rules
25
26 # Create and report the DFT specification
27 set spec [create_dft_specification]
28 report_config_data $spec
29
30 # Edit DFT specification to include additional advanced BAP
connections
31 add_config_element
DftSpecification(processor_core,rtl1)/MemoryBist/
32 BistAccessPort/DirectAccessOptions
33 set_config_value
34 DftSpecification(processor_core,rtl1)/MemoryBist/
35 BistAccessPort/DirectAccessOptions/direct_access_on
36 set_config_value
37 DftSpecification(processor_core,rtl1)/MemoryBist/
38 Controller(c1)/DirectAccessOptions/ExecutionSelections
39 set_config_value
40 DftSpecification(processor_core,rtl1)/MemoryBist/
41 Controller(c1)/DirectAccessOptions/algorithm on
42 set_config_value

414 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
First DFT Insertion Pass: processor_core
43 DftSpecification(processor_core,rtl1)/MemoryBist/
44 Controller(c1)/DirectAccessOptions/operation_set on
45 set_config_value
46 DftSpecification(processor_core,rtl1)/MemoryBist/
47 Controller(c1)/DirectAccessOptions/memory on
48 set_config_value
49 DftSpecification(processor_core,rtl1)/MemoryBist/
50 Controller(c1)/DirectAccessOptions/step on
51 set_config_value
52 DftSpecification(processor_core,rtl1)/MemoryBist/Controller(c1)/
53 AdvancedOptions/extra_algorithms {SMARCHCHKB SMARCHCHKBCI
SMARCH
54 SMARCHCHKBCIL}
55
56 report_config_data $spec
57
58 # Specify BAP connection to system logic
59 read_config_data -in $spec/MemoryBist/BistAccessPort/Connections/
60 -from_string {
61 DirectAccess {
62 controller_select : DBAP_control/ctrl_select ;
63 step_select : DBAP_control/step_select ;
64 step_select_enable :
DBAP_control/step_select_en ;
65 algorithm_select : DBAP_control/algo_select ;
66 algorithm_select_enable :
DBAP_control/algo_select_en ;
67 operation_set_select : DBAP_control/opset_select ;
68 operation_set_select_enable :
DBAP_control/opset_select_en ;
69 ClockDomain (-) {
70 clock : DBAP_control/clkout ;
71 reset : reset_n ;
72 test_start : DBAP_control/start;
73 test_done : DBAP_control/done ;
74 test_pass : DBAP_control/pass ;
75 }
76 }
77 }
78
79 # Generate and insert the hardware
80 process_dft_specification
81
82 extract_icl
83
84 # Generate testbench verification patterns
85 create_patterns_specification
86 process_patterns_specification
87
88 # Run and check testbench simulations
89 set_simulation_library_sources -y ../../../library/memories/
90 ‑extension v -v ../../../library/standard_cells/verilog/adk.v
91 run_testbench_simulations

Tessent™ Shell User’s Manual 415

Tessent Shell Automotive Workflow
Second DFT Insertion Pass: processor_core
92 check_testbench_simulations
93
94 exit

Second DFT Insertion Pass: processor_core

In the second DFT insertion pass, insert the EDT, OCC, and LogicBIST instruments. Use the hybrid
TK/LBIST process to share the EDT and LogicBIST IP. Control the clocking scheme for the LogicBIST
pattern using a named capture procedure (NCP) index decoder, which decodes the NCP index output
of the hybrid controller into clock sequences that are generated by Tessent OCCs across all capture
procedures.
For details about OCC for the hybrid TK/LBIST flow, refer to "Tessent OCC TK/LBIST Flow" in the Hybrid
TK/LBIST Flow User’s Manual.

Note:
The line numbers used in this procedure refer to the command flow dofile in Example 22 on
page 417 unless otherwise noted.

Procedure
1. Loading the Design.

2. Follow the steps described in “Specifying and Verifying the DFT Requirements: DFT Signals for
Wrapped Cores” on page 227, ensuring that you also include the required DFT signals for the
hybrid TK/LBIST flow and for controller chain mode. (Refer to lines 3-31.)

3. Creating the DFT Specification with SIBs for EDT, OCC, and LogicBIST, and edit the default
specification to include the OCC, hybrid IP, and LogicBIST. (Refer to lines 33-125.)
Use the read_config_data command to edit the DFT specification as follows:

• Specify the OCC wrapper and specify your clock intercept node for the OCC.
For details about OCC for the hybrid TK/LBIST flow, refer to "Tessent OCC TK/LBIST Flow" in
the Hybrid TK/LBIST Flow User’s Manual.

• Specify the EDT wrapper to include a LogicBistOptions wrapper, and specify a MISR ratio of
one. This reduces the chances of aliasing at the MISR (for better debugging capability) while
trading off the area.
If you want to use the edt_clock as a shift clock source for LogicBIST, specify a dash (-) value in
the interface wrapper, which caused the tool to not create a shift_clock_src port.

• Specify a LogicBist wrapper that contains both a Controller wrapper and an NcpIndexDecoder
wrapper. Tessent Shell automatically converts the EDT controller into a hybrid TK/LBIST
controller.
You must specify the clocking combinations to be used during TK/LBIST test. The tool
synthesizes the NCP index decoder and generates named capture procedures based on this
description. For details, refer to "NCP Index Decoder" in the Hybrid TK/LBIST Flow User’s
Manual.

416 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
Second DFT Insertion Pass: processor_core

Note:
When you have only one NCP, the tool does not generate an NCP index decoder. You
can use this configuration to implement a static clock sequence loaded through the ICL
network. (You notice this for the GPS baseband block.)

4. Generating the EDT, Hybrid TK/LBIST, and OCC Hardware, plus the LogicBIST hardware. (Refer
to line 125.)

5. Extracting the ICL Module Description. (Refer to line 127.)

6. Generating ICL Patterns and Running Simulation. (Refer to lines 129-140.)

Results
The following figure shows the clocking and DFT controls after the second DFT insertion pass.

Figure 94. Enhanced Clocking and DFT Controls After Second DFT Insertion Pass

Examples
The following dofile example shows a typical automotive command flow for a core-level second DFT
insertion. Modify the DFT specifications for you design requirements.

Example 22. Dofile Example for Second DFT Insertion Pass, processor_core

1 // Load the design commands ...

2
3 set_dft_specification_requirements -logic_test on
4
5 # Add required DFT signals for logic test
6 add_dft_signals ltest_en -create_with_tdr
7 add_dft_signals scan_en edt_update test_clock
8 -source_node {scan_enable edt_update test_clock u }
9 add_dft_signals edt_clock shift_capture_clock
-create_from_other_signals
10
11 # Add required DFT signals specific to hybrid TK/LBIST flow

Tessent™ Shell User’s Manual 417

Tessent Shell Automotive Workflow
Second DFT Insertion Pass: processor_core
12 add_dft_signals observe_test_point_en control_test_point_en
x_bounding_en
13
14 # Add required DFT signal for MemoryBIST
15 # DFT signal used for scan-tested instruments such as MemoryBIST
16 add_dft_signals tck_occ_en
17
18 # Add DFT signals to bypass memories or run multiple load ATPG
for them
19 add_dft_signals memory_bypass_en
20 add_dft_signals mcp_bounding_en
21
22 # Add DFT signals required for hierarchical DFT (external,
internal modes)
23 add_dft_signals int_ltest_en ext_ltest_en int_mode ext_mode
24
25 # Add DFT signal for controller chain mode
26 add_dft_signals controller_chain_mode
27
28 # Enable Observation Scan Technology (OST) for capturing per
shift and capture
29 add_dft_signals capture_per_cycle_static_en
30
31 check_design_rules
32
33 # Create DFT specification
34 set spec [create_dft_specification -sri_sib_list {occ edt
lbist } ]
35
36 Use report_config_syntax DftSpecification/edt|occ to see full
syntax
37 report_config_data $spec
38
39 # Edit DFT specification to specify the SIB of the OCC and to
insert OCC
40 read_config_data -in $spec -from_string {
41 OCC {
42 ijtag_host_interface : Sib(occ);
43 static_clock_control : external;
44 }
45 }
46
47 # Specify OCC insertion and intercept node
48 # This is a generic method for populating the OCC; modify for
your design
49 # Scan enable and shift capture clock signals are automatically
connected
50 # to the OCC instances
51 set id_clk_list [list \
52 dco_clk dco_clk \
53 directclk directclk
54 ]
55 foreach {id clk} $id_clk_list {

418 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
Second DFT Insertion Pass: processor_core
56 set occ [add_config_element OCC/Controller($id) -in $spec]
57 set_config_value clock_intercept_node -in $occ $clk
58 }
59
60 # Specify the hybrid EDT configuration
61 read_config_data -in $spec -from_string {
62 EDT {
63 ijtag_host_interface : Sib(edt);
64 Controller (c1) {
65 longest_chain_range : 100, 200 ;
66 scan_chain_count : 10;
67 input_channel_count : 1;
68 output_channel_count : 1;
69 LogicBistOptions {
70 misr_input_ratio : 1 ;
71 ShiftPowerOptions {
72 present : on ;
73 default_operation : disabled ;
74 SwitchingThresholdPercentage {
75 min : 25 ;
76 }
77 }
78 }
79 }
80 }
81 }
82
83 # Specify the LogicBIST controller with NCP index decoder
84 read_config_data -in $spec -from_string {
85 LogicBist {
86 ijtag_host_interface : Sib(lbist);
87 Controller(1%ctrl_lbist) {
88 burn_in : on ;
89 pre_post_shift_dead_cycles : 8 ;
90 SingleChainForDiagnosis { Present : on ; }
91 ControllerChain {
92 present : on;
93 clock : tck;
94 }
95 Connections {
96 scan_en_in : scan_enable ;
97 controller_chain_scan_in : ccm_scan_in ;
98 controller_chain_scan_out : ccm_scan_out ;
99 }
100 Interface {
101 shift_clock_src : - ;
102 }
103 ShiftCycles { max : 200 ; }
104 CaptureCycles { max : 7 ; }
105 PatternCount { max : 1024 ; }
106 WarmupPatternCount { max : 512 ; }
107 }
108

Tessent™ Shell User’s Manual 419

Tessent Shell Automotive Workflow
Test Point, X-Bounding, and Scan Insertion: processor_core
109 NcpIndexDecoder{
110 Ncp(dco_clk) {
111 cycle(0): OCC(dco_clk);
112 cycle(1): OCC(dco_clk);
113 }
114 Ncp(ALL) {
115 cycle(0): OCC(dcoo_clk);
116 cycle(1): OCC(directclk);
117 }
118 Ncp(sti_occ) {
119 cycle(0): processor_core_rtl1_tessent_sib_sti_inst ;
120 }
121 }
122 } // End of LogicBIST controller wrapper
123 // End of report_config_data
124
125 process_dft_specification
126
127 extract_icl
128
129 # Write script for design compilation
130 write_design_import_script for_dc_synthesis.tcl -replace
131
132 create_patterns_specification
133 process_patterns_specification
134
135 set_simulation_library_sources -v
136 ../../../library/standard_cells/verilog/adk.v -y
137
../../../library/memories ../../../library/standard_cells/verilog
138 -extension v
139
140 run_testbench_simulations -simulator_option +nowarnTSCALE
141
142 exit

Test Point, X-Bounding, and Scan Insertion:

processor_core
After synthesizing the design using a third-party tool, perform test point analysis and insertion, X-
bounding, wrapper analysis, and scan chain analysis and insertion.

• Test points — Inserting test points increases the testability of a design by improving controllability
and observability during scan testing. This step is part of the hybrid TK/LBIST workflow; refer to
“Perform Test Point Insertion” on page 379 for details.
In addition, a new type of observe point — the observation scan observe point (OP) — is inserted
during test point insertion. The tool monitors observation scan OPs during every shift cycle
and capture cycle compared with traditional OPs, which are monitored only during capture.
Observation scan observe points are a part of observation scan technology (OST). For details,
refer to "Observation Scan Technology" in the Hybrid TK/LBIST Flow User’s Manual.

420 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
Test Point, X-Bounding, and Scan Insertion: processor_core

Note:
For OST, you must add the capture_per_cycle_static_en DFT signal during the DFT
insertion pass.

• X-bounding — X-bounding ensures that only valid binary values propagate through the scan
cells during test. This prevents X sources from reaching the memory elements and corrupting the
signature during LogicBIST. For details, refer to "X-Bounding" in the Hybrid TK/LBIST Flow User’s
Manual.

• Wrapper analysis — In hierarchical DFT, wrapper analysis prepares the functional scannable
sequential elements (or flops) for reuse as wrapper cells. Use the analyze_wrapper_cells
command.

• Scan chains — The tool inserts wrapper scan chains around the physical blocks that connects to
each input and output. The input and output wrapper chains are exercised using the internal and
external scan mode DFT control signals. For more information, refer to “Performing Scan Chain
Insertion: Wrapped Core” on page 229.
In addition, you must configure the controller scan chains and add a scan mode for controller
chain mode (CCM).

Note:
Tessent Shell works with any third-party scan insertion or other tools. However, because all
Tessent products reside on the same code and database, you lose some automation with third-
party tools.

Note:
The line numbers used in this procedure refer to the command flow dofile in Example 23 on
page 422 unless otherwise noted.

Procedure
1. After loading the design and setting the design parameters, perform test point, X-bounding,
wrapper, and scan insertion in the merged DFT context. (Refer to lines 7.)

2. Read the design files and specify the requirements for test points and OST observe points. (Refer
to line 9-51.)

3. Post-test point insertion, specify the requirements for X-bounding. (Refer to lines 60-70.)

4. Specify wrapper cell requirements and perform wrapper cell analysis. (Refer to lines 72-77.)
For details, refer to "Scan Insertion for Wrapped Core" in the Tessent Scan and ATPG User’s
Manual.

5. Activate controller chain segments. (Refer to lines 79-82.)

By default, CCM scan segments in Tessent IP cores are not active to prevent them from being
confused with standard scan elements. You must activate a CCM scan mode on Tessent IP
instances before adding them to the scan mode population.

Tessent™ Shell User’s Manual 421

Tessent Shell Automotive Workflow
Test Point, X-Bounding, and Scan Insertion: processor_core

6. Specify the scan modes: internal, external, and controller chain. (Refer to lines 84-94.)
For internal and external modes, connect the scan chains to the EDT block. For CCM mode,
ensure that you only include CCM scan segments as valid scan elements.

7. Analyze scan chains and insert X-bounding, wrapper, and scan chain logic. (Refer to lines 96-103.)

Examples
The following dofile shows a command flow for test point and scan insertion.

Example 23. Dofile Example for Test Point and Scan Insertion, processor_core

1 ##======== Test Point, X-bounding, Wrapper, and Scan Insertion

========
2
3 # Open the previous TSDB directory if it is not in the current
working directory
4 set_tsdb_output_directory ../tsdb_outdir
5
6 # Setting context to dft since inserting DFT into gate-level
design
7 set_context dft ‑test_point ‑scan ‑no_rtl ‑design_id gate1
8
9 ##Read in the design (you may use ‑exclude_from_file_dictionary to
exclude the netlist from the tessent database)
10
read_cell_library ../../../library/standard_cells/tessent/adk.tcelllib
11 # Read the synthesized netlist
12 read_verilog ../3.synthesize_rtl/processor_core_synthesized.vg
13
14 ##Read in the memory library model
15 set_design_sources ‑format tcd_memory ‑y ../../../library/memories/
‑extension tcd_memory
16
17 ##Read in memory verilog model
18 read_verilog ../../../library/memories/SYNC_1RW_32x16_RC.v
‑interface_only ‑exclude_from_file_dictionary
19 read_verilog ../../../library/memories/SYNC_1RW_8Kx16.v
‑interface_only ‑exclude_from_file_dictionary
20
21 ##Read the design files from the RTL insertion pass
22 # Use the ‑no_hdl switch to skip reading the netlist as the
synthesized netlist has already been read
23 read_design processor_core -design_id rtl2 -no_hdl
24
25 set_current_design processor_core
26
27 ##Setting the design level as physical_block
28 set_design_level physical_block
29
30 set_static_dft_signal_value ltest_en 1
31

422 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
Test Point, X-Bounding, and Scan Insertion: processor_core
32 report_static_dft_signal_settings
33
34 # Specify the number of testpoint (integer or integer %)
35 set_test_point_analysis_options ‑total_number 250
36
37 # Specify how many observe points to be observed by one scan cell
38 set_test_point_insertion_options ‑observe_point_share 5
39
40 # Specify both types of test points to reduce both pattern count
41 # and improve random pattern testability
42 set_test_point_type { lbist_test_coverage edt_pattern_count }
43
44 # Specify capture per cycle observation for OST to observe per
shift cycle
45 set_test_point_analysis_options ‑capture_per_cycle_observe_points on
46
47 # Setting the shift length to the anticipated scan chain length
of the design for OST
48 set_test_point_analysis_options -minimum_shift_length 80
49
50 # Set mcp_bounding_en to 1 to gate BIST.CLK and prevents
additional hardware bounding logic
51 set_static_dft_signal_values mcp_bounding_en 1
52
53 # Check design rule
54 set_system_mode analysis
55
56 # Report clocks and dft signals
57 report_clocks
58 report_dft_signals
59
60 # Analyze test points
61 analyze_test_points
62 write_test_point_dofile processor_core_tpi.dofile ‑all ‑replace
63
64 ## Exclude reset from X-bounding to avoid XB DRC. Handled by
wrapper insertion. Automation in 19.2
65 set_xbounding_options ‑exclude {reset_n}
66
67 ## Perform X-bounding for LBIST
68 analyze_xbounding
69 report_xbounding ‑verbose > xbound_list
70 report_xbounding ‑verbose ‑ignored_x_sources on >
xbound_list_with_ignored_x_source
71
72 # Exclude the edt_channel in and out ports from wrapper chain
analysis. The ijtag_* edt_update ports are automatically excluded
73 set_wrapper_analysis_options ‑exclude_ports [ get_ports
{*_edt_channels_*} ]
74
75 # Perform wrapper cell analysis
76 analyze_wrapper_cells
77 report_wrapper_cells -Verbose > wrapper_cell.rpt

Tessent™ Shell User’s Manual 423

Tessent Shell Automotive Workflow
ATPG Pattern Generation: processor_core
78
79 # Set attribute value for in-built chains for
controller_chain_mode
80 set_attribute_value [get_instances
*tessent_single_chain_mode_logic_*] ‑name active_child_scan_mode ‑value
controller_chain_mode
81 set_attribute_value [get_instances *tessent_lbist_inst] ‑name
active_child_scan_mode ‑value controller_chain_mode
82 set_attribute_value [get_instance -of_module *_edt_lbist_c1]
‑name active_child_scan_mode ‑value controller_chain_mode
83
84 # Specify different modes (internal and external) how the chains
need to be stitched
85 # The type internal/external and enable_dft_signal are inferred
from registered DFT Signals(int_mode and ext_mode)
86 # Create a scan mode and specify EDT instance to connect the scan
chains to
87 set ccm [get_scan_elements ‑of_child_scan_mode
controller_chain_mode]
88 set core [remove_from_collection [get_scan_elements] $ccm]
89 #set core [remove_from_collection [get_scan_elements -class core]
$ccm]
90 set edt_instance [get_instances ‑of_icl_instances [get_icl_instances
‑filter tessent_instrument_type==mentor::edt]]
91
92 add_scan_mode int_mode -edt $edt_instance ‑include_elements $core
‑enable_dft_signal int_mode
93 add_scan_mode controller_chain_mode ‑include_elements $ccm ‑chain_count
1 ‑enable_dft_signal controller_chain_mode ‑si_port_format ccm_scan_in%d
‑so_port_format ccm_scan_out%d
94 add_scan_mode ext_mode -chain_count 2
95
96 # Analyze the scan chains and review the different scan modes and
chains before stitching the chains
97 analyze_scan_chains
98
99 # Insert scan chains and writes the scan inserted design into
tsdb_outdir directory
100 insert_test_logic
101
102 report_scan_chains
103 report_scan_cells > scan_cells.list

ATPG Pattern Generation: processor_core

Generating ATPG patterns for a wrapped core includes a step for generating a graybox model. In
addition, you must perform ATPG twice, once for the core’s external mode and once for the core’s internal
mode, which is typical for any hierarchical design. Controller chain mode, when used, also requires its
own ATPG pass.

424 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
ATPG Pattern Generation: processor_core

Figure 95. ATPG Pattern Generation Flow for processor_core

For information about graybox models, refer to “Graybox Model” on page 130.

Procedure
Perform ATPG as described in “Performing ATPG Pattern Generation: Wrapped Core” on page 233 with
the following extra considerations:

a. After running ATPG on the internal mode and saving the collateral data to the TSDB with the
write_tsdb_data command (step 3-d), do the following:

i. Return to setup mode and disable the memory_bypass_en signal.

ii. Read the PDL of the BISR chains that have the init_bisr_chains iProc. The procedure is located
at:

/tsdb_outdir/instruments/processor_core_rtl1_mbisr.instrument/proces
sor_core_rtl1_tessent_mbisr.pdl

Invoke the procedure as follows:

set_test_setup_icall init_bisr_chains –front

iii. Run ATPG on the internal mode again and save the data with the write_tsdb_data command.
ATPG generates a multiple load pattern that can scan through the memory. You can use
multiple load scan patterns to generate scan patterns through ROM and RAM memories.
Before generating multiple load patterns on repairable memories, any repair information that
was previously generated by the MemoryBIST run must be applied to the memory repair ports.
For details, refer to “Running Multiple Load ATPG on Wrapped Core Memories With Built-In
Self Repair” on page 391.

iv. Use the read_faults command to merge the fault list from running external mode to find the total
overall fault coverage of the wrapped core.

Tessent™ Shell User’s Manual 425

Tessent Shell Automotive Workflow
LogicBIST Fault Simulation: processor_core

b. Run ATPG on the controller chain mode to create APTG patterns for the following test logic IPs:
hybrid controller, LogicBIST controller, single chain mode logic, and in-system test controller. Do
the following:

i. Load the wrapped cores that contain the child wrapped cores.

ii. If you used Tessent Scan for scan insertion, specify "import_scan_mode
controller_chain_mode" to import the controller chain mode.

iii. Specify a unique ATPG mode name for controller chain mode, such as ccm. For example:

set_current_mode ccm

iv. After running DRC, generate the ATPG patterns, and store the TCD, flat model, fault list and
PatDB files in the TSDB using the write_tsdb_data command.
The generated ATPG patterns are core-level patterns. You generate these patterns again at the
top level.

v. Use the read_faults command to merge the fault list from running internal mode to find the total
overall fault coverage of the wrapped core.

LogicBIST Fault Simulation: processor_core

Perform LogicBIST fault simulation to generate pseudo-random, parallel pattern sets. Tessent Shell
chooses the PRPG seed value based on the specified warm-up pattern and creates the signature for the
MISR. The signature is stored in the TSDB. Specify the number of random patterns based on your in-
system requirements for test time and LogicBIST coverage.
For details about seeding, refer to "Warm-Up Patterns" in the Hybrid TK/LBIST Flow User’s Manual.
Refer to "Parallel Versus Serial Patterns" in the Tessent Scan and ATPG User’s Manual for more
information about pattern types.

Note:
The line numbers used in this procedure refer to the command flow in Example 24 on page 427.
Refer to “Performing LogicBIST Fault Simulation” on page 386 for additional details about some
of the following steps.

Procedure
1. Loading the Design. (Refer to lines 1-10.)

2. Set the current test mode to a unique name for the new pattern set you create to test the hybrid IP.
(Refer to line 12.)

3. Import the core’s internal mode data—that is, the scan-inserted design data for the EDT and OCC
logic. (Refer to line 14.)
Using the import_scan_mode command assumes that you used Tessent Scan to perform scan
chain stitching.

4. Add the hybrid TK/LBIST core instances. (Refer to line 16.)

426 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
LogicBIST Fault Simulation: processor_core

You must explicitly add the LogicBIST controller core.

5. Specify the capture procedure names and the count percentage to repeat the NCP once every 256
patterns. (Refer to lines 18-19.)

6. Specify the order of the NCPs. (Refer to lines 21-25.)

7. Read in the NCP testproc file. (Refer to lines 29-32.)

8. Add the faults and specify the maximum number of pseudo-random patterns you want the tool to
simulate. (Refer to lines 34-35.)

9. Set the pattern source to LogicBIST and run fault simulation. (Refer to line 36.)

10. Write out the parallel testbench and save the data into the TSDB. (Refer to lines 38-40.)

Examples
The following dofile example shows a typical command flow for LogicBIST fault simulation.

Example 24. Dofile Example for LogicBIST Fault Simulation, processor_core

1 set_context patterns -scan -design_id gate2

2 set_tsdb_output_directory ../tsdb_outdir
3 open_tsdb ../tsdb_outdir
4
read_cell_library ../../../library/standard_cells/tessent/adk.tcelllib
5 read_cell_library ../../../library/memories/SYNC_8X16.atpglib
6 read_cell_library ../../../library/memories/SYNC_1RW_32x16_RC.atpg
7
8 read_design processor_core -design_id gate1
9
10 set_current_design processor_core
11
12 set_current_mode lbist_sa -type internal
13
14 import_scan_mode int_mode
15
16 add_core_instances -module *tessent_lbist
17
18 set_lbist_controller_options -capture_procedures {ALL 90 directclk 8
19 sti_occ 2 }
20
21 # Specify the full pathname to the dofile located in the
22 # *_lbist_ncp_index_decoder.instrument directory in the TSDB
23 dofile ../tsdb_outdir/instruments/processor_core_rtl2
24 _lbist_ncp_index_decoder.instrument/processor_core_rtl2_tessent
25 _lbist_ncp_index_decoder.dofile
26
27 set_system_mode analysis
28
29 # Specify the full pathname to the testproc file located in the
30 # *_lbist_ncp_index_decoder.instrument directory in the TSDB
31 read_procfile ../tsdb_outdir/instruments/processor_core_rtl2

Tessent™ Shell User’s Manual 427

Tessent Shell Automotive Workflow
LogicBIST Pattern Generation: processor_core
32 _lbist_ncp_index_decoder.instrument/processor_core_rtl2
33
34 add_faults -all
35 set_random_pattern 1024
36 simulate_patterns -source bist -store_patterns all
37
38 write_patterns patterns/processor_core_lbist_parallel.v -verilog
39 -parallel -replace
40 write_tsdb -replace

LogicBIST Pattern Generation: processor_core

To program the LogicBIST controller, use the pattern specification in hardware default mode to generate
testbench and pattern range-specific vectors.

Note:
The line numbers used in this procedure refer to the command flow in Example 25 on page 428.
Refer to “Perform LogicBIST Pattern Generation” on page 388 for additional details about some of
the steps in the following.

Procedure
1. Loading the Design, ensuring that you set the context to patterns -ijtag. (Refer to lines 1-7.)
The design ID should be the same design you used for LogicBIST fault simulation.

2. Create the patterns specification. (Refer to lines 15-16.)

3. Edit the patterns specification to specify the LogicBIST pattern configuration. (Refer to lines 18-52.)
If you want to debug Xs in your MISR during simulation, you can enable debugging with the
logic_bist_debug property.

4. Generate the IJTAG patterns for LogicBIST and run simulation. (Refer to lines 55-63.)

Examples
The following dofile shows a command flow for generating IJTAG patterns for LogicBIST in the automotive
Tessent Shell flow.

Example 25. Dofile Example for LogicBIST Pattern Generation, processor_core

1 set_context patterns -ijtag

2 set_tsdb_output_directory ../tsdb_outdir
3
read_cell_library ../../../library/standard_cells/tessent/adk.tcelllib
4 # read memory library models too
5 read_design processor_core -design_id gate2
6
7 set_current_design piccpu
8
9 # Report clock and DFT signal settings
10 report_static_dft_signal_settings

428 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
LogicBIST Pattern Generation: processor_core
11 report_clocks
12
13 set_system_mode analysis
14
15 # Create patterns specification
16 set patt_spec [ create_patterns_specification ]
17
18 # Edit the patterns specification for LogicBIST pattern
19 # Example only; modify for your design requirements
20 read_config_data -replace -in $patt_spec -from_string {
21 AdvancedOptions {
22 ConstantPortSettings {
23 scan_enable : 0;
24 }
25 }
26 Patterns(ICLNetwork) {
27 ICLNetworkVerify(processor_core) {
28 }
29 }
30 Patterns(LogicBist_processor_core) {
31 ClockPeriods {
32 dco_clk : 3.00ns;
33 directclk: 12.00ns;
34 test_clock_u: 100.00ns;
35 }
36 SimulationOptions {
37 # You can opt to enable debugging Xs in the MISR during simulation
38 logic_bist_debug : off;
39 }
40 TestStep(serial_load) {
41 LogicBist {
42 CoreInstance(.) {
43 run_mode : run_time_prog;
44 mode_name : lbist_sa ;//same as set_current_mode in
45 lbist fault simulation
46 begin_pattern : 0;
47 end_pattern : 255 ;
48 misr_compares : 1 ;
49 }
50 }
51 }
52 }
53 }
54
55 process_patterns_specification
56
57 set_simulation_library_sources -y ../../../library/memories/
-extension v
58 -v ../../../library/standard_cells/verilog/adk.v
59
60 run_testbench_simulation -simulator_options { -voptargs="+acc" }
61
62 # Use the following command if simulation fails

Tessent™ Shell User’s Manual 429

Tessent Shell Automotive Workflow
Interconnect Bridge/Open UDFM Generation: processor_core
63 check_testbench_simulations -report_status
64
65 exit

Interconnect Bridge/Open UDFM Generation:

processor_core
If you want to perform Automotive-Grade ATPG targeting interconnect bridge and open defects, generate
a UDFM for the interconnect bridge/open defects in your design. Then, read in the UDFM during
Automotive-Grade ATPG.

Note:
The line numbers used in this procedure refer to the command flow in “Example 26” on
page 431. Refer to the following directory, which has a usage example described in this section:
tessent_automotive_reference_flow_<software_version>/wrapped_cores/processor_core/
11.extract_fault_sites

Procedure
1. Load the post-layout design and generate a flat model. (Refer to lines 1-19.)

2. Load the flat model. (Refer to lines 21–23.)

3. Read in the layout data and generate an LDB. (Refer to lines 25-34.)

4. Load the LDB by applying the open_layout command, and then apply the extract_fault_sites
command with an output file name to generate a UDFM. (Refer to lines 36-40.)

Note:
Use "all" as the defect_types option for the extract_fault_sites command to write out both
bridges and opens to the UDFM file.

Examples
Figure 96. Interconnect Bridge/Open UDFM Generation Flow for processor_core

430 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
Interconnect Bridge/Open UDFM Generation: processor_core

The following dofile shows a command flow for generating a bridge/open UDFM for use in the
Automotive-Grade ATPG flow.

Example 26. Dofile Example for Interconnect Bridge/Open UDFM Generation, processor_core

1 set_context patterns -scan

2 set design_name "processor_core"
3
4 # Read Tessent Library
5 read_cell_library \
6
../../../library/NangateOpenCellLibrary_PDKv1_3_v2010_12/Front_End/DFT/Na
ngateOpenCellLibrary.tcelllib
7
8 # Read in the post layout netlist
9 read_verilog ../9.pnr/pnr_db/golden/${design_name}.post.vg
10
11 #Read in the memory library model
12 read_cell_library ../../../library/memories/SYNC_1RW_8Kx16.atpglib
13 read_cell_library ../../../library/memories/SYNC_1RW_32x16_RC.atpg
14 set_design_sources -format tcd_memory -y ../../../library/memories/
‑extension tcd_memory
15
16 set_current_design $design_name
17
18 set_system_mode analysis
19
20 write_flat_model flat/${design_name}_post.flat -rep
21
22 set_context patterns -scan_diagnosis
23
24 read_flat_model flat/${design_name}_post.flat
25
26 set deffile [glob -directory ../9.pnr/pnr_db/golden
${design_name}.def]
27
28 set leffile [concat [glob
-directory ../
../../library/NangateOpenCellLibrary_PDKv1_3_v2010_12/Back_End/lef
NangateOpenCellLibrary.macro.lef] \
29 [glob
-directory ../
../../library/NangateOpenCellLibrary_PDKv1_3_v2010_12/Back_End/lef
NangateOpenCellLibrary.tech.lef] \
30 [glob -directory ../../../library/memories
SYNC_1RW_8Kx16.lef] \
31 [glob -directory ../../../library/memories
SYNC_1RW_32x16_RC.lef] \
32 ]
33
34 analyze_layout_hierarchy hier_db/${design_name}.hierdb -leflist
$leffile ‑deflist $deffile -rep

Tessent™ Shell User’s Manual 431

Tessent Shell Automotive Workflow
Cell-Neighborhood UDFM Generation: processor_core
35 create_layout ldb/${design_name}.ldb -rep -deflist $deffile ‑leflist
$leffile
36
37 open_layout ldb/${design_name}.ldb
38
39 extract_fault_sites -output_file udfm/${design_name}_brdg_opn.udfm
‑defect_types all -rep
40
41 exit

Cell-Neighborhood UDFM Generation: processor_core

If you want to perform Automotive-Grade ATPG targeting cell-neighborhood defects, which may be
located between cells, generate a UDFM for your design's cell-neighborhood defects. Use that UDFM
during Automotive-Grade ATPG.
To generate a cell-neighborhood UDFM, extract cell-neighborhood pairs from the design LDB, then feed
the cell pairs information into Tessent CellModelGen. Combine the UDFM files for all individual cell pairs
into a single UDFM file. The required input data is the same as the data required for generating a cell-
aware UDFM on standard cells. For information on Tessent CellModelGen or input requirements, refer to
the Tessent CellModelGen Tool Reference.

Note:
The line numbers used in this procedure refer to the command flow in “Example 27” on
page 434. Refer to the following directory, which has a usage example described in this section:
tessent_automotive_reference_flow_<software_version>/wrapped_cores/processor_core/
11.extract_fault_sites

Procedure
1. Extract cell-neighborhood pairs.

a. Load the flat model generated for interconnect bridge/open UDFM generation. (Refer to lines
1-5.)

b. Load the LDB using the open_layout command, which is generated for interconnect bridge/
open UDFM generation. (Refer to line 7.)

c. Run the extract_inter_cell_data command, specifying an output file name to write the extracted
cell-neighborhood pairs. (Refer to line 9.)

2. Generate the UDFM using Tessent CellModelGen with the extracted cell-neighborhood pairs.

a. Before running Tessent CellModelGen, ensure that all the required input data is available and
all the required tools are accessible.

b. Create an empty directory, and retrieve run scripts.

cellmodelgen -get_script all

c. Copy the run_flow.merge script into your working directory from the lib/scripts directory, which
you get from step 1.b.

432 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
Cell-Neighborhood UDFM Generation: processor_core

d. Modify the run_flow.merge script for your design. Refer to the comments in the script
for details. The output file from step 1, the extracted inter-cell pairs, is the input to the
run_flow.merge script.

e. Run the run_flow.merge script to run Tessent CellModelGen with the cell-neighborhood pairs.
Specify the filename of the extracted cell-neighborhood pairs and a working directory name.

f. Copy the run_export.merge script into your working directory from the lib/scripts directory,
which you get from step 1.b.

g. Modify the run_export.merge script for your working environment.

h. Run the run_export.merge script to combine all single UDFM files on each of the cell pairs into
a single UDFM file.

Examples
Figure 97. Cell-Neighborhood UDFM Generation Flow for processor_core

Tessent™ Shell User’s Manual 433

Tessent Shell Automotive Workflow
Cell-Neighborhood UDFM Generation: processor_core

The following dofile shows a command flow for generating a bridge/open UDFM for use in the
Automotive-Grade ATPG flow.

Example 27. Dofile Example for Extracting Cell-Neighborhood Pairs, processor_core

1 set_context patterns -scan_diagnosis

2
3 set design_name "processor_core"
4
5 read_flat_model flat/${design_name}_post.flat
6
7 open_layout ldb/${design_name}.ldb
8
9 extract_inter_cell_data -output_file
inter_cell_data/${design_name}_cellpairs.data -rep
10
11 exit

434 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
Automotive-Grade ATPG Pattern Generation: processor_core

Automotive-Grade ATPG Pattern Generation:

processor_core
Generating automotive-grade ATPG patterns is similar to regular ATPG pattern generation. It needs
several UDFM files for cell-internal defects, interconnect bridge or open defects, and cell-neighborhood
defects.
Refer to Interconnect Bridge/Open UDFM Generation: processor_core for interconnect bridge/open
UDFM generation on your design, and Cell-Neighborhood UDFM Generation: processor_core for cell-
neighborhood UDFM generation for your design.
Refer to “UDFM Generation for Cell-Aware ATPG” on page 464 for details on how to generate the cell-
aware UDFM for your technology library.
As you do for regular ATPG, you must generate a graybox model; then, you must perform ATPG twice:
once for the core’s external mode and once for its internal mode. When you run ATPG in external mode
or internal mode, you can run ATPG with topoff runs by loading only the UDFM files you want to target
during an ATPG run. Also, you can run ATPG all together by reading in all UDFM files at once.

Automotive-Grade Topoff ATPG Pattern Generation

Automotive-Grade ATPG Pattern Generation Using Only UDFMs

Automotive-Grade Topoff ATPG Pattern Generation

This procedure describes how to run cell-aware ATPG topoff when you already have ATPG patterns from
previous runs.

Note:
The line numbers used in this procedure refer to the command flow in “Example 28” on
page 438. Refer to the following directory, which has a usage example described in this section:
tessent_automotive_reference_flow_<software_version>/wrapped_cores/processor_core/
12.generate_AGA_patterns

Prerequisites
• Existing patterns from previous ATPG runs.

• Existing UDFM file(s) for your technology library and design.

Procedure
1. Load the flat model generated from a post-layout design. (Refer to lines 1–11.)

2. Set a fault type, read in the UDFM file for your standard cells, and add faults. (Refer to lines
14-18.)

3. Read patterns from previous ATPG runs. (Refer to line 20.)

4. Simulate the patterns to determine the baseline test coverage. (Refer to line 21.)

5. Create patterns. (Refer to line 28.)

Tessent™ Shell User’s Manual 435

Tessent Shell Automotive Workflow
Automotive-Grade Topoff ATPG Pattern Generation

6. Check how much benefit there is with the newly-created patterns (refer to line 31). Set a baseline
to understand the benefit after step 4. (Refer to line 24.)

7. Write the newly-created patterns. (Refer to lines 34–40.)

8. Check final ATPG test coverage. (Refer to lines 47-51.)

436 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
Automotive-Grade Topoff ATPG Pattern Generation

Examples
Figure 98. ATPG Topoff Run Flow With a UDFM for processor_core

The following dofile shows a command flow for generating Automotive-Grade ATPG flow topoff patterns.

Tessent™ Shell User’s Manual 437

Tessent Shell Automotive Workflow
Automotive-Grade Topoff ATPG Pattern Generation

Example 28. Dofile Example for Running Topoff ATPG

With a UDFM in Internal Mode for processor_core

1 set_context patterns -scan -design_id pnr

2 set design_name "processor_core"
3
4 # Specify the location of TSDB. Default is the current working
directory
5 set_tsdb_output_directory ../tsdb_outdir
6
7 # Add more processors to run ATPG
8 add_processors localhost:4
9
10 # Read flat model
11
read_flat_model ../
tsdb_outdir/logic_test_cores/${design_name}_pnr.logic_test_core/${design_na
me}.atpg_mode_ATPG_int/${design_name}_ATPG_int.flat.gz
12
13 # Cell-Aware Test Pattern Generation
14 set_fault_type udfm -static_fault
15 read_fault_sites \
16 ../../../udfm_gen/stdlib/udfm/NangateOpenCellLibrary.udfm
17 report_fault_sites -undefined_cells
18 add_fault_sites -all
19 add_faults -all
20
21
read_patterns ../
tsdb_outdir/logic_test_cores/${design_name}_pnr.logic_test_core/${design_na
me}.atpg_mode_ATPG_int/${design_name}_ATPG_int_stuck.patdb
22 simulate_patterns -source external
23
24 # Set baseline
25 report_udfm_statistics -set_baseline -group *OAI* *AOI* *OR* *AND*
*INV* *BUF* *HA* *DFF* *MUX* *DLL*
26 report_statistic
27
28 # Generate patterns
29 create_patterns
30
31 # Check gain
32 report_udfm_statistics -group *OAI* *AOI* *OR* *AND* *INV* *BUF*
*HA* *DFF* *MUX* *DLL*
33 report_statistic
34
35 write_patterns patterns/${design_name}_int_CAT_static_topoff.stil.gz
‑stil -replace
36 write_faults faults/${design_name}_int_CAT_static_topoff.faults.gz
‑replace
37
38 # Write Verilog patterns for simulation

438 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
Automotive-Grade ATPG Pattern Generation Using Only UDFMs
39 write_patterns
patterns/${design_name}_int_CAT_static_topoff_parallel.v ‑verilog ‑parallel
‑replace
40 set_pattern_filtering -sample_per_type 2
41 write_patterns
patterns/${design_name}_int_CAT_static_topoff_serial.v ‑verilog ‑serial ‑replace
42
43 # To understand the coverage of the faults testable by Internal mode
it is
44 # necessary to eliminate the undetected faults that would otherwise
be
45 # detected in External mode. This is done by merging the fault list
46 # from running the graybox in External mode
47 read_faults faults/${design_name}_ext_CAT_static_topoff.faults.gz
‑merge
48
49 # Final coverage of the core that includes both Internal and
External
50 # modes
51 report_stat -detail
52
53 exit

Automotive-Grade ATPG Pattern Generation Using Only UDFMs

This procedure describes how to run cell-aware ATPG using only existing UDFMs.

Note:
The line numbers used in this procedure refer to the command flow in “Example 29” on
page 440. Refer to the following directory, which has a usage example described in this section:
tessent_automotive_reference_flow_<software_version>/wrapped_cores/processor_core/
12.generate_AGA_patterns

Prerequisites
• Existing UDFM files for your technology library and design.

Procedure
1. Load the flat model generated from a post-layout design. (Refer to lines 1–11.)

2. Set a fault type and read in the UDFM files for your standard cells, interconnect bridge/open, and
cell-neighborhood defects. Then add faults. (Refer to lines 14-20.)

3. Create patterns. (Refer to line 24.)

4. Write the patterns. (Refer to line 27.)

Tessent™ Shell User’s Manual 439

Tessent Shell Automotive Workflow
Automotive-Grade ATPG Pattern Generation Using Only UDFMs

Examples
Figure 99. ATPG Run Flow With All UDFM for processor_core

The following dofile shows a command flow for generating Automotive-Grade ATPG flow patterns using
only UDFMs.

Example 29. Dofile Example for Running ATPG With

Only UDFMs in Internal Mode for processor_core

1 set_context patterns -scan -design_id pnr

2 set design_name "processor_core"
3
4 # Specify the location of TSDB. Default is the current working
directory
5 set_tsdb_output_directory ../tsdb_outdir
6
7 # Add more processors to run ATPG
8 add_processors localhost:4
9
10 # Read flat model

440 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
Automotive-Grade ATPG Pattern Generation Using Only UDFMs
11
read_flat_model ../
tsdb_outdir/logic_test_cores/${design_name}_pnr.logic_test_core/${design_na
me}.atpg_mode_ATPG_int/${design_name}_ATPG_int.flat.gz
12
13 # Cell-Aware Test Pattern Generation
14 set_fault_type udfm -static_fault
15 read_fault_sites \
16 ../../../udfm_gen/stdlib/udfm/NangateOpenCellLibrary.udfm
17
read_fault_sites ../
11.extract_fault_sites/udfm/${design_name}_brdg_opn.udfm
18 read_fault_sites ../11.extract_fault_sites/udfm/CELLS_neighbor.udfm
19 report_fault_sites -undefined_cells
20 add_fault_sites -all
21 add_faults -all
22 report_statistics -detail
23
24 # Generate patterns
25 create_patterns
26 report_statistics -detail
27
28 write_patterns patterns/${design_name}_int_AGA_static.stil.gz -stil
-rep
29 write_faults faults/${design_name}_int_AGA_static.faults.gz -rep
30
31 # Write Verilog patterns for simulation
32 write_patterns patterns/${design_name}_int_AGA_static_parallel.v
-verilog ‑parallel ‑replace
33 set_pattern_filtering -sample_per_type 2
34 write_patterns patterns/${design_name}_int_AGA_static_serial.v
-verilog ‑serial ‑replace
35
36 # To understand the coverage of the faults testable by Internal mode
it is necessary to
37 # eliminate the undetected faults that would otherwise be detected
in External mode. This is done
38 # by merging the fault list from running the graybox in External
mode
39 #read_faults -mode ATPG_ext -fault_type udfm -merge
40 read_faults faults/${design_name}_ext_AGA_static.faults.gz ‑merge
41
42 # Final coverage of the core that includes both Internal and
External modes
43 report_stat -detail
44
45 exit

Tessent™ Shell User’s Manual 441

Tessent Shell Automotive Workflow
DFT Insertion Flow for the GPS Baseband Physical Block

DFT Insertion Flow for the GPS Baseband Physical

Block
The GPS baseband design does not include memory. Because MemoryBIST is not required, you can skip
the first DFT insertion pass as described for the processor core. Instead, perform one DFT pass to insert
the hybrid IP, OCC, and in-system test.
In addition to illustrating how to insert in-system test at the block level, the flow for this block shows you
how to perform LogicBIST fault simulation when a design only has one clock, and, thus, no NCP decoder
logic.

Figure 100. DFT Insertion Flow for gps_baseband

This section highlights aspects of the flow for gps_baseband that differ from processor_core: DFT
insertion and LogicBIST fault simulation. Refer to the test case for dofile details.

DFT Insertion Pass With In-System Test: gps_baseband

LogicBIST Fault Simulation With One NCP: gps_baseband
Interconnect Bridge/Open UDFM Generation: gps_baseband
Cell-Neighborhood UDFM Generation: gps_baseband
Automotive-Grade ATPG Pattern Generation: gps_baseband

442 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
DFT Insertion Pass With In-System Test: gps_baseband

DFT Insertion Pass With In-System Test: gps_baseband

This DFT insertion pass shows how to insert the in-system test controller at the core level. This could be
a requirement for your design depending on the length of your IJTAG network. The tool generates a CPU-
based controller, which is enabled from the system logic at the parent level.

Note:
The line numbers used in this procedure refer to the command flow dofile in Example 30 on
page 444 unless otherwise noted.

Procedure
1. Loading the Design. (Refer to lines 1-8.)

2. Follow the steps described in “Specifying and Verifying the DFT Requirements: DFT Signals for
Wrapped Cores” on page 227, ensuring that you also include the required DFT signals for the
hybrid TK/LBIST flow and for controller chain mode. (Refer to lines 10-35.)
Constrain the enable signal for the in-system test controller to 0 for manufacturing test. The tool
emulates the control of this port during in-system test. (Refer to lines 25-26.)
For the DFT signals, create a new port if a source node does not exist. The ports are created only
if set_design_level is not chip.

3. Creating the DFT Specification with SIBs for EDT, OCC, and LogicBIST, and edit the default
specification to insert the OCC, hybrid IP, and in-system test controllers. (Refer to lines 37-138.)
As you did with the processor core, use the read_config_data command to edit the DFT
specification.

• Specify the OCC wrapper and specify your clock intercept node for the OCC.
For details about OCC for the hybrid TK/LBIST flow, refer to "Tessent OCC TK/LBIST Flow" in
the Hybrid TK/LBIST Flow User’s Manual.

• Specify the EDT wrapper to include a LogicBistOptions wrapper, and specify a MISR ratio of
one.
The edt_clock and edt_update signals are automatically connected to EDT instances, and the
EDT controller is built with bypass.

• Specify a LogicBist wrapper that contains both a Controller wrapper and an NcpIndexDecoder
wrapper.
Because this core has a single clock, you only need one NCP; the tool does not generate the
NCP index decoder.

• Specify an InSystemTest wrapper, ensuring that you specify that you are using the CPU
interface.
Create a TCD segment for this instrument, and specify the in-system test controller connections
using the Connections wrapper.

4. Generating the EDT, Hybrid TK/LBIST, and OCC Hardware, plus the LogicBIST and in-system test
hardware. (Refer to line 139.)

Tessent™ Shell User’s Manual 443

Tessent Shell Automotive Workflow
DFT Insertion Pass With In-System Test: gps_baseband

5. Extracting the ICL Module Description. (Refer to line 141.)

6. Generating ICL Patterns and Running Simulation. (Refer to lines 143-151.)

Examples
The following dofile example shows a typical automotive command flow for a core-level first DFT
insertion. Modify the DFT specifications for you design requirements.

Example 30. Dofile Example for DFT Insertion, gps_baseband

1 # Load the design

2 set_context dft –rtl -design_id rtl1
3 set_tsdb_output_directory ../tsdb_outdir
4 read_verilog ../rtl/gps_baseband.v
5
6 set_current_design gps_baseband
7
8 set_design_level physical_block
9
10 # Add required DFT signals for logic test
11 add_dft_signals ltest_en
12 add_dft_signals scan_en edt_update test_clock
13 -source_node {SCAN_EN_w edt_update test_clock_w }
14 add_dft_signals edt_clock shift_capture_clock
-create_from_other_signals
15
16 # Add DFT signals required for hierarchical DFT (external,
internal modes)
17 add_dft_signals int_ltest_en ext_ltest_en int_mode ext_mode
18
19 # Add DFT signal for controller chain mode
20 add_dft_signals controller_chain_mode
21
22 # Add required DFT signals specific to hybrid TK/LBIST flow
23 add_dft_signals observe_test_point_en control_test_point_en
x_bounding_en
24
25 # Constrain the in-system test controller to 0 for manufacturing
test
26 add_input_constraints mission_test_enable -C0
27
28 set_dft_specification_requirements -logic_test on
29
30 add_clocks clk -period 3ns
31
32 # Enable Observation Scan Technology (OST) for capturing per
shift and capture
33 add_dft_signals capture_per_cycle_static_en
34
35 check_design_rules
36
37 # Create and report the DFT specification

444 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
DFT Insertion Pass With In-System Test: gps_baseband
38 set spec [create_dft_specification -sri_sib_list {edt occ
lbist} ]
39 report_config_data $spec
40
41 # Edit DFT specification to specify the SIB of the OCC and to
insert OCC
42 # Modify for your design requirements
43 read_config_data -in $spec -from_string {
44 OCC {
45 ijtag_host_interface : Sib(occ);
46 static_clock_control : external;
47 }
48 }
49
50 # Specify OCC insertion and intercept node
51 # This is a generic method for populating the OCC; modify for
your design
52 # Scan enable and shift capture clock signals are automatically
connected
53 # to the OCC instances
54 set id_clk_list [list \
55 clk clk\
56 ]
57 foreach {id clk} $id_clk_list {
58 set occ [add_config_element OCC/Controller($id) -in $spec]
59 set_config_value clock_intercept_node -in $occ $clk
60 }
61
62 # Specify the hybrid EDT configuration
63 read_config_data -in $spec -from_string {
64 EDT {
65 ijtag_host_interface : Sib(edt);
66 Controller (c1) {
67 longest_chain_range : 50, 65 ;
68 scan_chain_count : 60;
69 input_channel_count : 2;
70 output_channel_count : 2;
71 LogicBistOptions {
72 misr_input_ratio : 1 ;
73 ShiftPowerOptions {
74 present : on ;
75 default_operation : disabled ;
76 SwitchingThresholdPercentage {
77 min : 25 ;
78 }
79 }
80 }
81 }
82 }
83 }
84
85 # Specify the LogicBIST controller with NCP index decoder
86 read_config_data -in $spec -from_string {

Tessent™ Shell User’s Manual 445

Tessent Shell Automotive Workflow
DFT Insertion Pass With In-System Test: gps_baseband
87 LogicBist {
88 ijtag_host_interface : Sib(lbist);
89 Controller(1%ctrl_lbist) {
90 burn_in : on ;
91 pre_post_shift_dead_cycles : 8 ;
92 SingleChainForDiagnosis { Present : on ; }
93 ControllerChain {
94 present : on;
95 clock : tck;
96 }
97 Connections {
98 scan_en_in : SCAN_EN_w ;
99 controller_chain_scan_in : ccm_scan_in ;
100 controller_chain_scan_out : ccm_scan_out ;
101 }
102 Interface {
103 shift_clock_src : - ;
104 }
105 NcpOptions {
106 count : 1 ;
107 }
108 ShiftCycles { max : 200 ; }
109 CaptureCycles { max : 7 ; }
110 PatternCount { max : 1024 ; }
111 WarmupPatternCount { max : 512 ; }
112 }
113
114 # Specify the in-system test controller
115 read_config_data -in $spec -from_string {
116 InSystemTest {
117 Controller(c0) {
118 protocol : cpu_interface ;
119 host_interface : HostScanInterface(ijtag) ;
120 data_width : 8 ;
121 ControllerChain {
122 present : on ;
123 clock : tck ;
124 segment_per_instrument : on ;
125 }
126 Connections {
127 reset : hw_rstn; //reset of gps_baseband core
128 CpuInterface {
129 clock : cpu_interface_clock ;
130 enable : mission_test_enable ;
131 write_en : from_cpu_write_en ;
132 data_in : data_in;
133 data_out : data_out;
134 }
135 }
136 }
137 }
138 }
139 process_dft_specification

446 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
LogicBIST Fault Simulation With One NCP: gps_baseband
140
141 extract_icl
142
143 # Write script for design compilation
144 write_design_import_script for_dc_synthesis.tcl -replace
145
146 set pat_spec [ create_patterns_specification ]
147 process_patterns_specification
148
149 run_testbench_simulations
150 # If simulation fails use the command below to see which pattern
failed
151 check_testbench_simulations
152
153 exit

LogicBIST Fault Simulation With One NCP:

gps_baseband
The GPS baseband core contains one clock, and, therefore, one NCP. There is no need for NCP decoder
logic so Tessent Shell does not generate the NCP index decoder during IP insertion. This means that you
must explicitly specify the clock sequence during LogicBIST fault simulation.
The following dofile excerpt invokes the clock sequence during LogicBIST fault simulation. The sequence
is generated by a TDR, and the static control clock is set to "both" during IP insertion.

Example 31. Dofile Example for LogicBIST Fault Simulation With One NCP

set_core_instance_parameters -instrument_type occ ‑parameter_values \

{static_clock_control internal clock_sequence 3}

add_bist_capture_range SINGLE_OCC_NCP 0 255

set_lbist_controller_options -programmable_ncp_list { SINGLE_OCC_NCP }

set_system_mode analysis

create_capture_procedures ‑name SINGLE_OCC_NCP \

‑clock_sequence ([ get_name_list [ get_clock \
gps_baseband_rtl1_tessent_occ_clk_inst/ \
tessent_persistent_cell_clock_out_mux/y ]]) \
([ get_name_list [ get_clock \
gps_baseband_rtl1_tessent_occ_clk_inst/ \
tessent_persistent_cell_clock_out_mux/y ]])

Tessent™ Shell User’s Manual 447

Tessent Shell Automotive Workflow
Interconnect Bridge/Open UDFM Generation: gps_baseband

Interconnect Bridge/Open UDFM Generation:

gps_baseband
Generate an interconnect bridge and open UDFM on the gps_baseband module in the same way as you
did for the processor_core module.
Refer to “Interconnect Bridge/Open UDFM Generation: processor_core” on page 430 to understand how
to generate an interconnect bridge/open UDFM on a wrapped core.
Refer to the following directory, which has an example on the gps_baseband module:
tessent_automotive_reference_flow_<software_version>/wrapped_cores/gps_baseband/
10.extract_fault_sites

Cell-Neighborhood UDFM Generation: gps_baseband

Generate a cell-neighborhood UDFM on the gps_baseband module in the same way as the
processor_core module.
Refer to “Cell-Neighborhood UDFM Generation: processor_core” on page 432 to understand how to
generate a cell-neighborhood UDFM on a wrapped core.
Refer to the following directory, which has an example on the gps_baseband module:
tessent_automotive_reference_flow_<software_version>/wrapped_cores/gps_baseband/
10.extract_fault_sites

Automotive-Grade ATPG Pattern Generation:

gps_baseband
Generate Automotive-Grade ATPG topoff and UDFM patterns on the gps_baseband module in the same
way as you did for the processor_core module.
Refer to “Automotive-Grade ATPG Pattern Generation: processor_core” on page 435 to understand how
to generate ATPG patterns on a wrapped core.
Refer to the following directory, which has an example on the gps_baseband module:
tessent_automotive_reference_flow_<software_version>/wrapped_cores/gps_baseband/
11.generate_AGA_patterns

448 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
Top-Level DFT Insertion for the Automotive Flow

Top-Level DFT Insertion for the Automotive

Flow
You previously inserted CPU-based in-system test controllers inside the GPS baseband cores. At the
top level, you now insert a DMA in-system test controller and associated memory block. In addition to
a Verilog testbench, this controller requires memory or lookup table (LUT)-based logic to save both the
controller instructions and the pattern data.
Typically, you use ROM for the DMA memory block, but you can use any storage mechanism as long as
you configure it to behave like a clocked synchronous memory. You can perform MemoryBIST testing on
this memory during manufacturing. For testing the memory in system, the process for applying power-on
reset tests during initialization differs if you are using ROM, RAM, or LUT-based logic.
For general information about the RTL and scan DFT insertion flow for the top chip, refer to “RTL
and Scan DFT Insertion Flow for the Top Chip” on page 240. (The documented process relates to a
hierarchical test case; however, the basic flow remains the same.)

First DFT Insertion Pass: Top With MemoryBIST, BISR, and Boundary Scan
Second DFT Insertion Pass: Top With EDT, OCC, and In-System Test
Scan Insertion for the Top Design
ATPG Pattern Generation for the Top Design
ATPG Pattern Retargeting for the Top Design
Interconnect Bridge/Open UDFM Generation for the Top Design
Cell-Neighborhood UDFM Generation for the Top Design
Automotive-Grade ATPG Pattern Generation for the Top Design
UDFM Generation for Cell-Aware ATPG
TCA Based Pattern Sorting

First DFT Insertion Pass: Top With MemoryBIST,

BISR, and Boundary Scan
The top design includes I/O pads. Insert boundary scan plus MemoryBIST for any memories that are
present at the top level; this includes the memory block for the DMA IST controller. Build the IJTAG
network for the wrapped cores at the top level. In addition, the design includes repairable memories in the
processor core, so you must insert an eFuse/OTP with an eFuse/OTP interface and a BISR controller.
If you do not plan to implement hard repair, use the Tessent soft-repair only option.

Note:
You must perform the first DFT insertion pass, even if you do not use MemoryBIST or boundary
scan to insert IJTAG to configure your child blocks. You cannot run logic test DRC in this first
pass. Logic test DRC requires that the child blocks are connected to the network in order to be
configured. Because of this, you can only run logic test DRC on the second DFT insertion pass,
after the network is configured.

Tessent™ Shell User’s Manual 449

Tessent Shell Automotive Workflow
First DFT Insertion Pass: Top With MemoryBIST, BISR, and Boundary Scan

Note:
For general instructions about inserting MemoryBIST and boundary scan at the top level, refer to
“First DFT Insertion Pass: Performing Top-Level MemoryBIST and Boundary Scan” on page 243.
This test case adds in the BISR and DMA memory block to the baseline use case.

Note:
Because you cannot use the in-system test patterns from the DMA memory block to test that
memory block, do not create in-system test patterns for testing the DMA memory.

If you plan to insert a LogicBIST controller at the same level as the DMA IST controller to generate in-
system test logic test patterns (not illustrated by this test case), ensure that the DMA IST controller and its
memory block have the same async clock source. In addition:

• Isolate the DMA memory block, its MemoryBIST logic, and the IST controller by pushing them
into their own module.

• If isolation is not possible because of design considerations, exclude the observation logic
inside the memory interface by disabling the observation_xor_size property. (The MemoryBIST
controller and MemoryBIST interface are scannable logic.) This prevents a MISR signature
difference between manufacturing and in-system LogicBIST tests. For example:

set_config_value
DftSpecification(processor_core,rtl1)/MemoryBist/Controller(c2)/St
ep/MemoryInterface(m1)/observation_xor_size off

In addition, disable the memory library DisableDuringScan property, which removes both the
gating logic at the memory inputs and the memory bypass mux that disables the memory control
during scan and LogicBIST test. As needed, re-enable the memory bypass mux by setting the
scan_bypass_logic property to sync_mux, as follows:

set_config_value
DftSpecification(processor_core,rtl1)/MemoryBist/Controller(c2)/St
ep/MemoryInterface(m1)/scan_bypass_logic sync_mux

The memory bypass mux is supported in this scenario as long as you are directly connecting the
memory data output to the IST controller data input.

Note:
The line numbers used in this procedure refer to the command flow dofile in Example 32 on
page 452 unless otherwise noted.

Prerequisites
• To insert boundary scan, you must have an RTL design with instantiated I/O pads if you are using
a chip-level design.

• For RTL netlists, you must have a Tessent cell library or the pad library.

450 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
First DFT Insertion Pass: Top With MemoryBIST, BISR, and Boundary Scan

Procedure
1. Load the design, including opening the TSDBs for the child cores: processor_core and
gsp_baseband. (Refer to lines 1-25.)
In addition, load the design for the DMA memory block, fusebox, and fusebox interface. The dofile
example shows an example fusebox. You must include an eFuse/OTP and eFuse/OTP interface in
your design unless you are opting for soft repair only.

2. Specify the DFT specification requirements. (Refer to line 27.)

When you set the design level to chip, -memory_test on automatically initiates BISR insertion if
BISR chains exist on blocks instantiated in the current design or repairable memories exist in the
current design. This assumes that you have not changed the set_dft_specification_requirements
‑memory_bist, ‑memory_bisr_chains, and ‑memory_bisr_controller options from their default auto
settings.

3. Identify TAP pins and pins that cannot add boundary scan cells. (Refer to lines 29-41.)

4. Add DFT signals and clocks. (Refer to lines 43-50.)

5. Create the connections for the CPU-based and DMA IST controllers. (Refer to lines 52-68.)
You must connect the CPU-based IST controllers that you inserted at the block level so that they
can be controlled by the system logic. In addition, create the connection between the DMA memory
block and the DMA IST controller clock.
You can use a post-insertion script to connect the system logic with the IST controller.

6. Check the design rules and create the DFT specification. (Refer to lines 70-76.)

7. Segment the boundary scan to be used during logic test. (Refer to lines 78-79.)

8. Create the BISR controller connections for the clock, VDD, and fusebox. (Refer to lines 81-91.)
To connect the BISR controller to the system logic, you must specify the connection for the BISR
controller to use for repair clock, BISR reset, and VDD. Typically, system logic is connected to the
BISR controller for initiating memory repair and monitoring the progress of the operation.
The BISR controller input clock must be driven by an appropriate functional clock. Specify the
connection with the repair_clock_connection property in the DftSpecification/MemoryBisr/Controller
wrapper. The BISR controller input signal resets the BISR chains and initiates memory repair.
Specify the reset signal with the repair_trigger_connection property in the DftSpecification/
MemoryBisr/Controller wrapper. Also, specify your fusebox module and its location.

9. Identify the functional pins to be shared with EDT channel pins and add the required auxiliary I/O
logic. (Refer to lines 93-100.)

10. Generate the hardware and extract ICL. (Refer to lines 104-106.)

11. Generate ICL patterns and simulation testbenches for the controllers and instruments in the current
and lower physical instances. (Refer to lines 108-115.)
To re-run the lower physical instance simulations at higher levels, enable the set_default_values
simulate_instruments_in_lower_physical_instances property.

12. Run and check testbench simulations. (Refer to lines 117-130.)

Tessent™ Shell User’s Manual 451

Tessent Shell Automotive Workflow
First DFT Insertion Pass: Top With MemoryBIST, BISR, and Boundary Scan

Examples
The following dofile example shows a command dofile for the top-level first DFT insertion pass for the
automotive flow.

Example 32. Dofile Example for Top-Level First DFT Insertion Pass, Automotive Flow

1 set_context dft -rtl -design_id rtl1

2 set_tsdb_output_directory ../tsdb_outdir
3 open_tsdb ../../wrapped_cores/processor_core/tsdb_outdir
4 open_tsdb ../../wrapped_cores/gps_baseband/tsdb_outdir
5 read_cell_library ../../library/standard_cells/tessent/adk.tcelllib
6 read_verilog ../rtl/noncore_blocks/pll.v -blackbox
7
8 set_design_sources -format verilog \
9 -v ../rtl/noncore_blocks/pad8_io_macro.v \
10 -v ../rtl/noncore_blocks/iopad_sel.v \
11 ../rtl/noncore_blocks/iopad.v
12
13 # Read the memory block for the DMA IST controller too
14 read_verilog ../../library/memories/SYNC_1R1W_4096x8.v \
15 -interface_only -exclude_from_file_dictionary
16
17 read_verilog ../rtl/chip_top.v
18
19 # Read fusebox, example only
20 read_verilog fusebox/LVFuseBox.vb -exclude
21 read_verilog fusebox/genericFuseBox.vb
22 read_core_description fusebox/genericFuseBox.tcd_fbox
23
24 set_current_design chip_top
25 set_design_level chip
26
27 set_dft_specification_requirements -boundary_scan on -memory_test on
28
29 # Specify the TAP pins
30 set_attribute_value TCK -name function -value tck
31 set_attribute_value TDI -name function -value tdi
32 set_attribute_value TMS -name function -value tms
33 set_attribute_value TRST -name function -value trst
34 set_attribute_value TDO -name function -value tdo
35
36 # Specify pins that cannot add any boundary scan cells
37 set_boundary_scan_port_options TEST_CLOCK_top -cell_options
dont_touch
38 set_boundary_scan_port_options EDT_UPDATE_top -cell_options
dont_touch
39 set_boundary_scan_port_options SCAN_ENABLE -cell_options dont_touch
40 set_boundary_scan_port_options RESET_N -cell_options dont_touch
41 set_boundary_scan_port_options INCLK -cell_options dont_touch
42
43 # Add DFT signals

452 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
First DFT Insertion Pass: Top With MemoryBIST, BISR, and Boundary Scan
44 add_dft_signals scan_en -source_nodes SCAN_ENABLE
45
46 # Specify the clocks
47 add_clocks PLL_1/pll_clock_0 -reference REF_CLK -freq_multiplier 16
48 add_clocks REF_CLK -period 48
49 add_clocks TEST_CLOCK_top -period 10
50 add_clocks INCLK -period 10ns
51
52 # Create connections for CPU-based IST controller inserted in
gps_baseband
53 proc process_dft_specification.post_insertion {topWrapper args} {
54 create_connection RDS_1/mission_test_enable_gps
GPS_1/mission_test_enable
55 create_connection RDS_2/mission_test_enable_gps
GPS_2/mission_test_enable
56 create_connection istb/write_en GPS_1/from_cpu_write_en
57 create_connection istb/write_en GPS_2/from_cpu_write_en
58 create_connection istb/clock GPS_1/cpu_interface_clock
59 create_connection istb/clock GPS_2/cpu_interface_clock
60 create_connection istb/data_out GPS_1/data_in
61 create_connection istb/data_out GPS_2/data_in
62 create_connection GPS_1/data_out istb/data_in1
63 create_connection GPS_2/data_out istb/data_in2
64
65 # Create connection for DMA IST controller
66 create_connection IST_memory/CLK
67 chip_top_rtl1_tessent_in_system_test_post_inst/dma_clock
68 }
69
70 check_design_rules
71 set_system_mode analysis
72
73 report_clocks
74
75 set spec [create_dft_specification]
76 report_config_data $spec
77
78 # Segment the boundary scan to be used during logic test
79 set_config_value $spec/BoundaryScan/max_segment_length_for_logictest
80
80
81 # Create BISR controller connection for clock, VDD and fusebox
82 set_config_value -in $spec MemoryBisr/Controller/
83 repair_clock_connection PLL_1/pll_clock_0
84 set_config_value -in $spec
85 MemoryBisr/Controller/programming_voltage_source VDD/C
86 set_config_value -in $spec MemoryBisr/Controller/
87 repair_trigger_connection BISR_RESET/C
88 set_config_value -in $spec MemoryBisr/Controller/fuse_box_location
89 external
90 set_config_value -in $spec MemoryBisr/Controller/
91 fuse_box_interface_module genericFuseBox
92

Tessent™ Shell User’s Manual 453

Tessent Shell Automotive Workflow
Second DFT Insertion Pass: Top With EDT, OCC, and In-System Test
93 # Add auxilary MUX on the inputs and outputs used for EDT channel
pins
94 read_config_data -in ${spec}/BoundaryScan -from_string {
95 AuxiliaryInputOutputPorts {
96 auxiliary_input_ports : GPIO1_0, GPIO1_1, GPIO1_2, GPIO1_3;
97 auxiliary_output_ports : GPIO2_0, GPIO2_1, GPIO2_2, GPIO2_3,
GPIO1_0,
98 GPIO1_1 ;
99 }
100 }
101
102 report_config_data $spec
103
104 process_dft_specification
105
106 extract_icl
107
108 # Include the lower-level physical instances for IJTAG retargeting
109 set_defaults_value PatternsSpecification/SignOffOptions/
110 simulate_instruments_in_lower_physical_instances on
111
112 # Create pattern testbenches to verify the inserted DFT logic
113 set pat_spec [create_patterns_specification]
114
115 process_pattern_specification
116
117 set_simulation_library_sources
-v ../../library/standard_cells/verilog/ \
118 *.v
119 -v ../rtl/noncore_blocks/pll.v \
120 -v ../rtl/noncore_blocks/pad8_io_macro.v \
121 -v ../rtl/noncore_blocks/iopad_sel.v \
122 -v ../rtl/noncore_blocks/iopad.v \
123 -v ../../library/memories/SYNC_1RW_8Kx16.v \
124 -v ../../library/memories/SYNC_1RW_32x16_RC.v \
125 -v ../../library/memories/SYNC_1R1W_4096x8.v \
126 -v ../../library/standard_cells/verilog/adk.v \
127 -v fusebox/LVFuseBox.vb
128
129 run_testbench_simulations -exclude {InSystemTest_0_MemoryBist_P1}
130 check_testbench_simulations -report_status
131
132 exit

Second DFT Insertion Pass: Top With EDT, OCC,

and In-System Test
For the top level, the second DFT insertion pass for EDT and OCC include gray boxes, DFT signals for
purposes of ATPG retargeting, and TAMs. In addition, for the automotive flow, you insert the DMA IST
controller.

454 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
Second DFT Insertion Pass: Top With EDT, OCC, and In-System Test

Note:
For top-level EDT and OCC, this procedure follows a typical second DFT insertion flow for a
top design as detailed in “Second DFT Insertion Pass: Inserting Top-Level EDT and OCC” on
page 245. Refer to this section for associated details.

Note:
The line numbers used in this procedure refer to the command flow dofile in Example 33 on
page 456 unless otherwise noted.

Procedure
1. Load the design. (Refer to lines 1-14.)
Ensure that you load in the TCD for the DMA memory block that is used for in-system test. (Refer
to line 10.)

2. Add DFT signals. (Refer to lines 16-30.)

Ensure that you include a DFT signal for controller chain mode and define retargeting modes for
each group of wrapped cores whose ATPG patterns you want to retarget.

3. Apply the add_dft_modal_connections command to specify the TAM and to connect the EDT
channel IOs of the wrapped cores to top-level pins via the TAM. (Refer to lines 32-76.)
Include connections for controller chain mode. For the processor core, use retargeting_mode1, and
for the GPS baseband, use retargeting_mode2.
With Tessent Shell you can share functional pins as EDT channel pins. The dofile shows that the
input pin GPI01_0 is shared as an EDT channel input pin, and the output pin GPI02_0 is shared
as an EDT channel output pin. Different modes can also share input and output pins. For example,
GPIO1_2 functions as both the processor core EDT mode channel input and the controller chain
mode uncompressed input for the entire design.

4. Set the DFT specification requirements. (Refer to line 78.)

5. Create and process the DFT specification, using the read_config_data command to add the EDT
controller with bypass and the DMA IST controller. (Refer to lines 83-150.)
The top-level EDT controller includes bypass, and the edt_clock and edt_update signals are
automatically connected to EDT instances. The connect_bscan_segments_to_lsb_chains property
defaults to auto and connects the divided boundary scan segments from the previous insertion
pass to the top-level EDT controller.
Using the set_config_value command, connect the top-level EDT channels that you left
unconnected during step 3 to the GPIO ports. (Refer to lines 108-114.) The controller chain
connections are completed during scan insertion.
Finally, insert the DMA IST controller. (Refer to lines 116-150.) Set the protocol property to
direct_memory_access. To account for ATPG coverage of the IST controller under controller
chain mode, you can specify a TCD scan segment. Specify the data width, address width, and
max_test_program_count that determine the bus width of the IST controller’s program index,
and thus the number of patterns that are programmed for the controller. In addition, specify the
connections for the DirectMemoryAccess interface. The DMA IST controller inserts a comparator
circuit and outputs a fail flag and done bit.

Tessent™ Shell User’s Manual 455

Tessent Shell Automotive Workflow
Second DFT Insertion Pass: Top With EDT, OCC, and In-System Test

6. Generate ICL patterns and simulation testbenches for the instruments in the current and lower
physical instances. (Refer to lines 152-172.)
Create the in-system test patterns for the IJTAG instruments you want to test. The dofile example
illustrates applying the MemoryBist_P1 pattern to test the memory inside the processor core. The
resulting Verilog testbench file is named FilePrefix_TestProgramIndex_PatternSetName.v, and the
memory file (for use with the DMA IST controller) is named testbench_file_name.mem.

7. Run and check testbench simulations. (Refer to line 174-194.)

For in-system test, ensure that you point to the memory file that contains the control instructions
for the testbench and the data necessary for interaction with the DMA IST controller. (Refer to line
191.) This file has the same name as the testbench file with the addition of a ".mem" suffix. The
testbench loads the memory file during simulation.
In addition, add three levels to the IST controller’s actual location because the run occurs inside
three levels in the simulation_outdir directory.
After running the in-system test patterns, run the remaining testbench simulations for the top and
the physical blocks.

Examples
The following dofile example shows a command dofile for the top-level second DFT insertion pass for the
automotive flow.

Example 33. Dofile Example for Top-Level Second DFT Insertion Pass, Automotive Flow

1 set_context dft -rtl -design_id rtl2

2 set_tsdb_output_directory ../tsdb_outdir
3 open_tsdb ../../wrapped_cores/processor_core/tsdb_outdir
4 open_tsdb ../../wrapped_cores/gps_baseband/tsdb_outdir
5
6 read_design chip_top -design_id rtl1 -verbose
7 read_design processor_core -design_id gate1 -view graybox -verbose
8 read_design gps_baseband -design_id gate1 -view graybox -verbose
9
10 read_core_description ../../library/memories/SYNC_1R1W_4096x8.lvlib
11 read_verilog ../../library/memories/SYNC_1R1W_4096x8.v \
12 -interface_only exclude_from_file_dictionary
13
14 set_current_design chip_top
15
16 # Add DFT signals
17 add_dft_signals int_ltest_en output_pad_disable
18 add_dft_signals tck_occ_en
19 add_dft_signals ltest_en
20 add_dft_signals edt_mode
21 add_dft_signals controller_chain_mode
22
23 # These are used for top-level EDT
24 add_dft_signals test_clock edt_update \
25 -source_nodes {TEST_CLOCK_top EDT_UPDATE_top}
26 add_dft_signals shift_capture_clock edt_clock
-create_from_other_signals

456 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
Second DFT Insertion Pass: Top With EDT, OCC, and In-System Test
27
28 # Define retargeting modes
29 add_dft_signals retargeting1_mode retargeting2_mode
retargeting3_mode \
30 retargeting4_mode
31
32 # TAM connections
33 add_dft_modal_connections -ports GPIO1_0 \
34 -input_data_destination_nodes * -enable_dft_signal edt_mode
35 add_dft_modal_connections -ports GPIO2_0 \
36 -output_data_source_nodes * -enable_dft_signal edt_mode
37 add_dft_modal_connections -ports GPIO1_0
-input_data_destination_nodes \
38 * -enable_dft_signal controller_chain_mode
39 add_dft_modal_connections -ports GPIO2_0 -output_data_source_nodes \
40 * -enable_dft_signal controller_chain_mode
41
42 # For processor_core
43 add_dft_modal_connections -ports GPIO1_2
-input_data_destination_nodes \
44
PROCESSOR_1/processor_core_rtl2_controller_c1_edt_channels_in[0] \
45 -enable_dft_signal retargeting1_mode
46 add_dft_modal_connections -ports GPIO2_2 -output_data_source_nodes \
47
PROCESSOR_1/processor_core_rtl2_controller_c1_edt_channels_out[0] \
48 -enable_dft_signal retargeting1_mode
49
50 # For gps_baseband
51 add_dft_modal_connections -ports GPIO1_2
-input_data_destination_nodes \
52 GPS_1/gps_baseband_rtl1_controller_c1_edt_channels_in[0] \
53 -enable_dft_signal retargeting2_mode
54 add_dft_modal_connections -ports GPIO1_2
-input_data_destination_nodes \
55 GPS_2/gps_baseband_rtl1_controller_c1_edt_channels_in[0] \
56 -enable_dft_signal retargeting2_mode
57 add_dft_modal_connections -ports GPIO1_3
-input_data_destination_nodes \
58 GPS_1/gps_baseband_rtl1_controller_c1_edt_channels_in[1] \
59 -enable_dft_signal retargeting2_mode
60 add_dft_modal_connections -ports GPIO1_3
-input_data_destination_nodes \
61 GPS_2/gps_baseband_rtl1_controller_c1_edt_channels_in[1] \
62 -enable_dft_signal retargeting2_mode
63 add_dft_modal_connections -ports GPIO1_0 -output_data_source_nodes \
64 GPS_1/gps_baseband_rtl1_controller_c1_edt_channels_out[0] \
65 -enable_dft_signal retargeting2_mode -pipeline_stages 1
66 add_dft_modal_connections -ports GPIO1_1 -output_data_source_nodes \
67 GPS_1/gps_baseband_rtl1_controller_c1_edt_channels_out[1] \
68 -enable_dft_signal retargeting2_mode -pipeline_stages 1
69 add_dft_modal_connections -ports GPIO2_0 -output_data_source_nodes \
70 GPS_2/gps_baseband_rtl1_controller_c1_edt_channels_out[0] \

Tessent™ Shell User’s Manual 457

Tessent Shell Automotive Workflow
Second DFT Insertion Pass: Top With EDT, OCC, and In-System Test
71 -enable_dft_signal retargeting2_mode -pipeline_stages 1
72 add_dft_modal_connections -ports GPIO2_1 -output_data_source_nodes \
73 GPS_2/gps_baseband_rtl1_controller_c1_edt_channels_out[1]
74 -enable_dft_signal retargeting2_mode -pipeline_stages 1
75
76 report_dft_modal_connections
77
78 set_dft_specification_requirements -logic_test on -memory_test on
79
80 set_system_mode analysis
81 report_dft_control_points
82
83 # Create DFT specification
84 set spec [create_dft_specification -sri_sib_list {occ edt lbist} ]
85 report_config_data $spec
86 read_config_data -in $spec -from_string {
87 OCC {
88 ijtag_host_interface : Sib(occ);
89 }
90 }
91 set id_clk_list [list \
92 pll_clock_0 PLL_1/pll_clock_0 \
93 INCLK INCLK \
94 ]
95 foreach {id clk} $id_clk_list {
96 set occ [add_config_element OCC/Controller($id) -in $spec]
97 set_config_value clock_intercept_node -in $occ $clk
98 }
99 report_config_data $spec
100
101 read_config_data -in $spec -from_string {
102 EDT {
103 ijtag_host_interface : Sib(edt);
104 Controller (c1) {
105 ...
106 }
107
108 # Connect the EDT channels to the GPIO ports
109 set_config_value port_pin_name \
110 -in $spec/EDT/Controller(c1)/Connections/EdtChannelsIn(1) \
111 [get_auxiliary_pins GPIO1_0 -direction input]]
112 set_config_value port_pin_name \
113 -in $spec/EDT/Controller(c1)/Connections/EdtChannelsOut(1) \
114 [get_single_name [get_auxiliary_pins GPIO2_0 -direction
output] ]
115
116 # Insert DMA IST controller
117 read_config_data -in $spec -from_string {
118 InSystemTest {
119 Controller(post) {
120 DesignInstance (.) {}
121 // host_interface: HostScanInterface(tap);
122 data_width : 8 ;

458 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
Second DFT Insertion Pass: Top With EDT, OCC, and In-System Test
123 protocol : direct_memory_access ;
124 ControllerChain {
125 present : on ;
126 clock: tck;
127 segment_per_instrument: on;
128 }
129 DirectMemoryAccessOptions {
130 max_wait_cycles: 6400;
131 address_width: 12;
132 max_test_program_count: 2;
133 }
134 Connections {
135 reset: RESET_N;
136 DirectMemoryAccess {
137 clock: PLL_1/pll_clock_0_100; // free-running clock
138 enable: istb/enable;
139 test_program_index: istb/program_index;
140 mem_data: IST_memory/Q[%d];
141 mem_address: DMA_A/Y[%d];
142 fail_flag: istb/fail_flag ;
143 test_program_done: istb/test_done;
144 }
145 }
146 }
147 }
148 }
149
150 process_dft_specification
151
152 extract_icl
153
154 write_design_import_script for_dc_synthesis.tcl -replace
155
156 # Include the lower-level physical instances for IJTAG retargeting
157 set_defaults_value PatternsSpecification/SignOffOptions/
158 simulate_instruments_in_lower_physical_instances on
159
160 set pat_spec [create_patterns_specification]
161
162 # Create in-system test pattern for core-level memory
163 add_core_instance -module [ get_name [get_icl_module *post] ]
164 read_config_data -replace -in $pat_spec -from_string {
165 InSystemTest {
166 Controller(chip_top_rtl1_tessent_in_system_test_post_inst) {
167 TestProgram(0) { pattern : MemoryBist_P1 ; }
168 }
169 }
170 }
171
172 process_pattern_specification
173
174 set_simulation_library_sources
175 -v ../../library/standard_cells/verilog/*.v

Tessent™ Shell User’s Manual 459

Tessent Shell Automotive Workflow
Scan Insertion for the Top Design
176 -v ../rtl/noncore_blocks/pll.v \
177 -v ../rtl/noncore_blocks/pad8_io_macro.v \
178 -v ../rtl/noncore_blocks/iopad_sel.v \
179 -v ../rtl/noncore_blocks/iopad.v \
180 -v ../../library/memories/SYNC_1RW_8Kx16.v \
181 -v ../../library/memories/SYNC_1RW_32x16_RC.v \
182 -v ../../library/memories/SYNC_1R1W_4096x8.v \
183 -v ../../library/standard_cells/verilog/adk.v \
184 -v fusebox/LVFuseBox.vb
185
186 # Add three levels to the actual location because the run occurs
inside
187 # three levels in the simulation_outdir/
188 run_testbench_simulations -simulator_option
189 { +nowarnTSCALE -voptargs="+acc"
190 +IST_INIT_MEM=../../../../tsdb_outdir/patterns/
191 chip_top_rtl2.patterns_signoff/InSystemTest.mem }
192 -select InSystemTest_0_MemoryBist_P1
193
194 run_testbench_simulations -exclude {InSystemTest_0_MemoryBist_P1 }
195
196 exit

Scan Insertion for the Top Design

After synthesizing your design, stitch the scan logic at the top-level along with the wrapper chains
(external mode) of the cores. During scan insertion, the non-scan instances such as EDT are
automatically understood. In addition, the built-in OCC sub-chains are understood and stitched into scan
chains. The TCD segments that were created for the hybrid IP and IST controller test logic must be
stitched together within the controller chain mode so that you can test them during ATPG.
Tessent uses the DFT signals that you specified during the previous insertion passes, therefore you do
not need to specify them again.

Note:
Tessent Shell works with any third-party scan insertion or other tools. However, because all
Tessent products reside on the same code and database, you lose some automation with third-
party tools.

Note:
The line numbers used in this procedure refer to the command flow dofile in Figure 101 on
page 461 unless otherwise noted.

Procedure
1. Load the design. (Refer to lines 1-12.)
Ensure that you specify a unique design ID, and that you open the TSDB for all the child cores.

2. Exclude some design objects from the scan insertion process. (Refer to lines 17-19.)

460 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
Scan Insertion for the Top Design

Exclude the pipeline stages that you added using add_dft_modal_connections and the fusebox
instance.

3. Constrain the BISR reset to constant 1 (c1). (Refer to line 21.)

4. Create EDT and controller chain mode scan modes. (Refer to lines 25-55.)
Create an EDT scan mode to connect the scan chains to the EDT signals and EDT hardware that
you inserted during the second DFT insertion pass.
Create a top-level controller chain mode. To do this, you must first set the active_child_scan_mode
attribute value, which enables you to select the active child scan mode of a multi-mode core
and build a single chain for all controller chain mode IPs in all cores and also the top-level IST
controller. The IST controller must be tested in controller chain mode.
When you specify add_chain_mode for the controller chain mode, include controller chain mode
segments from the processor core, GPS baseband cores and the top elements. To reuse the
I/O pins you created with add_dft_modal_connections during the second DFT insertion pass,
specify the auxiliary pin SI/SO connections. For controller chain mode, you must specify the SI/SO-
associated ports so the tool recognizes that the chains are uncompressed.

5. Perform scan insertion. (Refer to lines 57-61.)

Examples
The following dofile example shows a command dofile for top-level scan insertion for the automotive flow.

Figure 101. Dofile Example for Top-Level Scan Chain Insertion, Automotive Flow

1 # Load the design

2 set_context dft -scan -design_id gate3
3 open_tsdb ../../wrapped_cores/processor_core/tsdb_outdir
4 open_tsdb ../../wrapped_cores/gps_baseband/tsdb_outdir
5
read_cell_library ../../library/standard_cells/tessent/adk.tcelllib
6 read_verilog ../3.synthesize_rtl/chip_top_synthesized.vg
7
8 read_design chip_top -design_id rt12 ‑no_hdl -verbose
9 read_design processor_core -design_id gate1 -verbose
10 read_design gps_baseband -design_id gate1 -view graybox -verbose
11
12 set_current_design chip_top
13
14 report_clocks
15 report_static_dft_signal_settings
16
17 # Specify the non-scan instances
18 add_nonscan_instances *tessent_dft_modal_*
19 add_nonscan_instances -instances fbi_instance
20
21 add_input_constraints BISR_RSTN_PAD -c1
22
23 set_system_mode analysis
24
25 # Create a scan mode to connect scan chains to EDT

Tessent™ Shell User’s Manual 461

Tessent Shell Automotive Workflow
ATPG Pattern Generation for the Top Design
26 set edt_instance [get_name_list [get_instance -of_module
[get_name
27 [get_icl_module -of_instances chip_top* -filter
28 tessent_instrument_type==mentor::edt]]] ]
29
30 add_scan_mode edt_mode -edt_instance $edt_instance
31
32 # Start creating a scan mode for controller_chain_mode
33 set_attribute_value [get_instance -of_module *in_system_test*]
-name
34 active_child_scan_mode -value controller_chain_mode
35 set_attribute_value [get_instance PROCESSOR_1] -name
36 active_child_scan_mode -value controller_chain_mode
37 set_attribute_value [get_instance GPS_1] -name
active_child_scan_mode
38 -value controller_chain_mode
39 set_attribute_value [get_instance GPS_2] -name
active_child_scan_mode
40 ‑value controller_chain_mode
41
42 # Create a scan chain family for elements at the top
43 create_scan_chain_family ccm_mm_top -include_elements
44 [get_scan_elements -of_child_scan_mode controller_chain_mode]
45
46 # Create the ccm scan mode and include elements at core and top
47 add_scan_mode controller_chain_mode -include_chain_families
48 {ccm_mm_top}
49
-include_elements{controller_chain_mode/PROCESSOR_1/ccm_scan_out
50 controller_chain_mode/GPS_1/ccm_scan_out
51 controller_chain_mode/GPS_2/ccm_scan_out} -si_connections
52 [get_single_name [get_auxiliary_pins GPIO1_2 -direction
input]]
53 -so_connection [get_single_name [get_auxiliary_pins GPIO2_2
54 -direction output] ] si_associated_ports GPIO1_2
55 -so_associated_ports GPIO2_2 -enable_dft_signal
controller_chain_mode
56
57 analyze_scan_chains
58 report_scan_chains
59
60 insert_test_logic
61 report_scan_cells > scan_cells.list
62
63 exit

ATPG Pattern Generation for the Top Design

For top-level ATPG pattern generation, use the scan-inserted design data for the chip. Tessent uses the
graybox models for the wrapped cores so that you can use the external mode of the wrapper chains to
run ATPG.

462 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
ATPG Pattern Retargeting for the Top Design

Note:
Top-level ATPG pattern generation for the automotive flow follows the typical hierarchical flow as
described in “Top-Level ATPG Pattern Generation Example” on page 250.

If you used Tessent Scan to insert the scan chains, specify the import_scan_mode command for ATPG
pattern generation. Tessent Shell passes the scan-inserted design data through for the EDT and OCC
logic. This data includes the scan structures that are stored in the TSDB under the "gate" design ID. You
can create ATPG patterns for any mode that you need, such as stuck-at, transition, and controller chain
mode.
In addition, Tessent automatically creates and simulates the test_setup procedure cycles that are required
to initialize the EDT and OCC static signals. You only need to specify non-default parameter values, if, for
example, you run EDT with bypass on or set int_ltest_en to 1 to use the boundary scan as the source of
the core values and isolate the ATPG test from the top-level IOs.
You can read in the stuck-at fault models for the wrapped cores to calculate the total fault coverage for the
chip.

ATPG Pattern Retargeting for the Top Design

For each wrapped core, retarget the internal ATPG patterns for all the modes you specified and all the
fault types.
Perform pattern retargeting as described in “Performing Top-Level ATPG Pattern Retargeting” on
page 251.

Note:
For the automotive flow, you must add the top-level free-running repair clock, as described in the
procedure steps.

Interconnect Bridge/Open UDFM Generation for the

Top Design
Generate an interconnect bridge and open UDFM for the top design module in the same way as you did
for the processor_core module.
Refer to “Interconnect Bridge/Open UDFM Generation: processor_core” on page 430 to understand how
to generate an interconnect bridge/open UDFM on a wrapped core.
Refer to the following directory, which has an example on the top design module:
tessent_automotive_reference_flow_<software_version>/top/9.extract_fault_sites

Cell-Neighborhood UDFM Generation for the Top

Design
Generate a cell-neighborhood UDFM for the top design module in the same way as the processor_core
module.

Tessent™ Shell User’s Manual 463

Tessent Shell Automotive Workflow
Automotive-Grade ATPG Pattern Generation for the Top Design

Refer to “Cell-Neighborhood UDFM Generation: processor_core” on page 432 to understand how to

generate a cell-neighborhood UDFM on the top design.
Refer to the following directory, which has an example on the top design module:
tessent_automotive_reference_flow_<software_version/top/9.extract_fault_sites

Automotive-Grade ATPG Pattern Generation for the

Top Design
Generating automotive-grade ATPG patterns on the top design is similar to regular ATPG pattern
generation. It needs several UDFM files for cell-internal defects, interconnect bridge or open defects, and
cell-neighborhood defects.
Refer to the Interconnect Bridge/Open UDFM Generation: processor_core for interconnect bridge/open
UDFM generation on your design, and Cell-Neighborhood UDFM Generation: processor_core for cell-
neighborhood UDFM generation for your design.
Refer to “UDFM Generation for Cell-Aware ATPG” on page 464 for details on how to generate the cell-
aware UDFM for your technology library.
As you do for regular ATPG, you must use graybox models for wrapped cores. The only difference with
the regular top-level ATPG, in terms of the flow, is that you must read UDFM files for Automotive-Grade
ATPG on the top design. You can run ATPG with topoff runs by loading only the UDFM files you want to
target during an ATPG run. Also, you can run ATPG all together by reading in all UDFM files at once.
Refer to “Automotive-Grade ATPG Pattern Generation: processor_core” on page 435 to understand how
to generate ATPG patterns on a wrapped core.
Refer to the following directory, which has an example on the top design module:
tessent_automotive_reference_flow_<software_version>/top/10.generate_AGA_patterns

UDFM Generation for Cell-Aware ATPG

To run cell-aware ATPG, you should generate cell-aware UDFMs for standard cells using Tessent
CellModelGen. Ensure that all input requirements and required tools are available before running Tessent
CellModelGen.
For information on Tessent CellModelGen or input requirements, refer to the Tessent CellModelGen
User’s Manual.

Note:
Refer to the following directory, which has a usage example described in this section:
tessent_automotive_reference_flow_<software_version>/udfm_gen/stdlib

464 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
UDFM Generation for Cell-Aware ATPG

Figure 102. Cell-Aware UDFM Generation Flow

Tessent™ Shell User’s Manual 465

Tessent Shell Automotive Workflow
TCA Based Pattern Sorting

Procedure
1. Check all inputs and tools requirements are met.
For details, refer to the Required Licenses and Input Data chapter in the Tessent CellModelGen
Tool Reference.

2. Create an empty directory, and retrieve run scripts:

cellmodelgen -get_script all

3. Look at the existing run_flow script in the directory. Modify the run_flow script for your design.
Refer to the inline comments within the script for details.

4. Run the run_flow script to run Tessent CellModelGen on your standard cells.

5. Look at the existing run_export script in the directory. Modify the run_export script for your design.
Refer to the inline comments within the script for details.

6. Run the run_export script to combine the individual standard cell UDFM files into a single UDFM
file.

TCA Based Pattern Sorting

Tessent Shell provides a way to sort ATPG patterns based on the total critical area (TCA) of defects. The
TCA defect data is saved in cell-aware, interconnect bridge/open, and cell-neighborhood UDFM files.

Note:
The line numbers used in this procedure refer to the command flow in “Example 34” on
page 467. Refer to the following directory, which has a usage example described in this section:
tessent_automotive_reference_flow_<software_version>/wrapped_cores/gps_baseband/
12.pattern_sorting

Procedure
1. Load the flat model generated from a post-layout design. (Refer to lines 1–11.)

2. Set a fault type, read in the UDFM file for your standard cells, and add faults. (Refer to lines
13-18.)

3. Read the patterns you want to sort. (Refer to lines 20-26.)

4. Run the set_critical_area_options ‑reporting on command to enable the TCA coverage reporting
feature. (Refer to line 28.)

5. Simulate the patterns. (Refer to line 30.)

6. Run the order_patterns -critical_area to sort the patterns based on TCA. (Refer to line 31.)

7. Write out the sorted patterns (Refer to line 33.)

466 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
TCA Based Pattern Sorting

Examples
Figure 103. TCA Based Pattern Sorting Flow

The following dofile shows a command flow for generating a bridge/open UDFM for use in the
Automotive-Grade ATPG flow.

Example 34. Dofile Example for Running ATPG With

All Types of UDFM in Internal Mode for gps_baseband

1 set_context patterns -scan -design_id pnr

2 set design_name "gps_baseband"
3
4 # Specify where the tsdb_outdir is to be located, default is the
current working directory
5 set_tsdb_output_directory ../tsdb_outdir
6

Tessent™ Shell User’s Manual 467

Tessent Shell Automotive Workflow
TCA Based Pattern Sorting
7 # Add more processors to run ATPG
8 add_processors localhost:4
9
10 # Read flat model
11
read_flat_model ../
tsdb_outdir/logic_test_cores/${design_name}_pnr.logic_test_core/${design_na
me}.atpg_mode_ATPG_int/${design_name}_ATPG_int.flat.gz
12
13 # Read UDFMs
14 set_fault_type udfm -static_fault
15 read_fault_sites \
16 ../../../udfm_gen/stdlib/udfm/NangateOpenCellLibrary.udfm
17
read_fault_sites ../
10.extract_fault_sites/udfm/${design_name}_brdg_opn.udfm
18 read_fault_sites ../10.extract_fault_sites/udfm/CELLS_neighbor.udfm
19 add_faults -all
20
21 # Read patterns
22
#read_patterns ../
tsdb_outdir/logic_test_cores/${design_name}_pnr.logic_test_core/${design_na
me}.atpg_mode_ATPG_int/${design_name}_ATPG_int_stuck.patdb
23
read_patterns ../
11.generate_AGA_patterns/patterns/${design_name}_int_stuck.stil.gz
24
read_patterns ../
11.generate_AGA_patterns/patterns/${design_name}_int_CAT_static_topoff.stil
.gz ‑append
25
read_patterns ../
11.generate_AGA_patterns/patterns/${design_name}_int_BRDG_static_topoff.sti
l.gz ‑append
26
read_patterns ../
11.generate_AGA_patterns/patterns/${design_name}_int_OPN_static_topoff.stil
.gz ‑append
27
read_patterns ../
11.generate_AGA_patterns/patterns/${design_name}_int_intercell_static_topof
f.stil.gz ‑append
28
29 set_critical_area_options -reporting on
30
31 simulate_patterns -source external ‑store_patterns all
32 order_patterns -critical_area
33
34 write_patterns
patterns/${design_name}_int_static_topoff_sorting.stil.gz ‑stil ‑rep
35 exit

468 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
Functional Mode Fault Tolerance for Static IJTAG Signals

Functional Mode Fault Tolerance for Static

IJTAG Signals
Tessent Shell provides a way to implement gating logic to ensure that a single-event upset (SEU) does
not affect the mission mode operation of a user design.
TDR outputs are gated in a hardware fault tolerant (HFT) module to create an alarm signal that you
monitor during functional operation mode. The alarm indicates that a test signal register value has been
altered.
This gating and monitoring logic is available for static DFT signals implemented with the ‑create_with_tdr
option. You can control the implementation of this logic for individual signals.

Procedure
1. Add the dft_signal_disable DFT signal to gate the TDR logic:

add_dft_signals dft_signal_disable

2. Enable the creation of the HFT module for all static DFT signals interacting with functional logic:

set_dft_signals_options ‑disable_for_functional_safety static

3. Add the individual DFT signals that you want to monitor:

add_dft_signals dft_signal ‑create_with_tdr \

‑disable_for_functional_safety on

4. Add any DFT signals you want to exclude from monitoring:

add_dft_signals dft_signal ‑create_with_tdr \

‑disable_for_functional_safety off

5. Create and process the DftSpecification:

check_design_rules
create_dft_specification
process_dft_specification

Results
An instance of an HFT module is created in a TDR hosting the static DFT signals. This module provides
the gating of the specified static DFT signals in addition to SEU monitoring logic. Refer to Figure 104 for
an example.

Tessent™ Shell User’s Manual 469

Tessent Shell Automotive Workflow
Functional Mode Fault Tolerance for Static IJTAG Signals

Figure 104. Hardware Fault Tolerant Module Example

The alarm signal is raised only in functional mode, and is gated with the all_test_out signal (the
all_test signal gated with fault tolerant logic). It is accessible on a persistent buffer regardless of the
DftSpecification add_persistent_buffers_in_scan_resource_instruments setting. The buffer instance name
is <tessent_persistent_cell_prefix>_hft_alarm_buf.
Use the following command to introspect the alarm signal:

get_icl_pins –filter \
{tessent_dft_function=="functional_mode_alarm"} \
-of_instance [get_icl_instance –filter \
{tessent_instrument_type=="mentor::ijtag_node"}]

Note:
If you do not add the DFT signals explicitly, the tool creates all_test and dft_signal_disable
automatically.

Note:
Typically, the reset value for DFT signals is 0. When the reset value is 1, the gating logic is
inverted, as shown with <sig_ResetVal_1> in Figure 104. Each DFT signal holds its reset value in
the functional mode of circuit operation.

In the single-pass DFT insertion flow, the dft_signal_disable signal is created in a Scan Resource
Instrument (SRI) TDR. Refer to Figure 105 for an example.

470 Tessent™ Shell User’s Manual

 Tessent Shell Automotive Workflow
Functional Mode Fault Tolerance for Static IJTAG Signals

Figure 105. HFT Module in the Single-Pass Flow

In the two-pass DFT insertion flow, the dft_signal_disable and all_test signals are defined in a Tdr(sri_ctrl)
module created during the first insertion pass. The TDR with logic test signals is created in the second
DFT insertion pass, and takes the all_test and dft_signal_disable signals as primary inputs. Each TDR
instance contains its own HFT logic, and two alarm signals are available on the TDR output ports. Refer
to Figure 106 for an example.

Figure 106. HFT Modules in the Two-Pass Flow

Tessent™ Shell User’s Manual 471

Tessent Shell Automotive Workflow
Functional Mode Fault Tolerance for Static IJTAG Signals

If you implement signal monitoring with the global set_dft_signals_options command, only those signals
that affect the functional mode of operation can be monitored. If you implement signal monitoring and
gating on a per-signal basis, any signal can be monitored.
By default, the capture_per_cycle_static_en and se_pipeline_en logic test control signals are not
monitored. Also, no scan mode signals are monitored by default. Monitoring and gating is possible only
for those static DFT signals you create with the ‑create_with_tdr option.
If you create the dft_signal_disable signal using the ‑source_node option, the tool implements the source
node as part of an ICL network regardless of design level.

Related Topics
add_dft_signals

set_dft_signals_options

get_dft_signals_option

472 Tessent™ Shell User’s Manual

 Chapter 8
TSDB Data Flow for the Tessent Shell Flow
The Tessent Shell Database (TSDB) is a repository for all the files and directories that Tessent Shell
generates. The TSDB enhances flow automation by acting as the central location where Tessent can
access the data it requires for the current task, whether that task be reading in a design, performing DRC,
inserting logic test hardware, or performing ATPG pattern generation.
The TSDB structure aids data management between steps in a process even if you are not performing
these steps within the Tessent Shell platform. If the steps are performed within Tessent Shell, then
specifying the correct design ID automatically ensures that Tessent uses the correct file inputs for the
current task.
Refer to Tessent Shell Database (TSDB) in the Tessent Shell Reference Manual for details about the
TSDB directory structure and contents.
The data flow content builds on the material described in Tessent Shell Flow for Flat Designs and Tessent
Shell Flow for Hierarchical Designs regarding the RTL and scan DFT insertion flow. During the RTL and
scan DFT insertion process, Tessent Shell generates many output files and directories that it accesses
later in the flow as data inputs. This chapter illustrates the data flow through each step of the RTL and
scan DFT insertion flow.

Core-Level or Flat TSDB Data Flow

Top-Level TSDB Data Flow

Core-Level or Flat TSDB Data Flow

The core-level TSDB data flow applies to wrapped cores in a hierarchical DFT insertion flow. In the
bottom-up insertion process, you process the wrapped cores before the top-level chip.
You can also apply this data flow to flat and DFT-inserted designs by adding boundary scan in the first
DFT insertion pass (unless the core includes embedded pad I/O macros that need boundary scan). Refer
to "Tessent Shell Flow for Flat Designs" for details.
The Tessent Shell task flow is shown in Figure 107. The details of the inputs and outputs are shown in
Table 21.

Tessent™ Shell User’s Manual 473

TSDB Data Flow for the Tessent Shell Flow
Core-Level or Flat TSDB Data Flow

Figure 107. Tessent Shell Task Flow

Refer to "Tessent Shell Flow for Hierarchical Designs" for details.

Table 21. Core-Level TSDB Data Flow Inputs and Outputs

Task Input Output

DFT insertion: first • RTL netlist • Modified RTL + new RTL

pass • Libraries • ICL for IJTAG network
Design ID for
output: rtl1 • Required DFT signals • TCD: clocks, DFT signals
• MemoryBIST requirements • ICL for Memory + PDL
• For flat: boundary scan • For flat: boundary scan also
requirements also

DFT insertion: • rtl1 design data • Modified RTL + new RTL

second pass • Libraries • ICL for IJTAG network
Design ID for
output: rtl2 • Required DFT signals • TCD: clocks, DFT signals
• EDT and OCC requirements • ICL for OCC and EDT + PDL

Synthesis • Output from • Synthesized gate-level netlist

write_design_import_script
Third-party tool command (use rtl2 design data)

Scan chain • Synthesized gate-level netlist • Scan-stitched gate-level netlist

insertion • Scan modes • ICL, PDL
Design ID for
output: gate • TCD, ICL, PDL from rtl2 • TCD with scan modes
• Graybox model (not flat)

474 Tessent™ Shell User’s Manual

 TSDB Data Flow for the Tessent Shell Flow
Core-Level or Flat TSDB Data Flow

Table 21. Core-Level TSDB Data Flow Inputs and Outputs (continued)

Task Input Output

ATPG pattern • Gate scan-inserted design data • Flat model

generation • ATPG run name • Fault list
• Scan mode • Patterns database
• TCD

During the first DFT insertion pass, you provide the required files for your DFT implementation. These
files can include the RTL netlist, libraries for MemoryBIST insertion and boundary scan, and gate-level
cells that require a Tessent cell library.
Tessent Shell generates the dft_inserted_designs, instruments, and patterns directories within the TSDB
you specified. By default, Tessent Shell generates the TSDB in the current working directory if you do not
specify a location. For details about these directories and the TSDB, refer to "Tessent Shell Database
(TSDB)" in the Tessent Shell Reference Manual.
Tessent modifies the RTL netlist for the design into which it inserts the first-pass instrument hardware.
This hardware may include a MemoryBIST controller, BAP interface, and IJTAG network. In the flat DFT
implementation, it may also include boundary scan and a TAP controller. Tessent Shell generates new
RTL for the newly inserted DFT instruments.
In addition, Tessent Shell produces the TCD, ICL, and PDL for the design and the inserted instruments.
As shown in the red boxes in Figure 108, the design-level files and modified RTL are stored within
the dft_inserted_designs subdirectory for this insertion pass (design ID rtl1). However, the new RTL,
TCD, ICL, and PDL files for each inserted instrument are stored in subdirectories within the instruments
directory.
The patterns directory stores the patterns associated with the rtl1 design ID in an associated subdirectory.

Tip
To facilitate data management, you can save each design (whether flat, core, sub-block, or chip)
in its own TSDB. This is the recommended practice when using Tessent Shell for DFT insertion.

Figure 108. TSDB File Structure, Core Level, First Insertion Pass

Figure 109 shows the file structure for the second DFT insertion pass. The yellow box shows the design
data that the tool saved as rtl1 in the first pass, which it uses as input for the second pass. The red boxes
show the output files.

Tessent™ Shell User’s Manual 475

TSDB Data Flow for the Tessent Shell Flow
Core-Level or Flat TSDB Data Flow

The relevant design RTL, TCD, ICL, and PDL files from the first DFT insertion pass are automatically
read in after you specify the read_design command as described in "Loading the Design". You only need
to supply a library, if required, and any DFT input requirement for the DFT instruments you are inserting
during this pass.
The hardware you insert in this pass, such as EDT and OCC, is stored in the instruments directory.
Separate directories are created for each type of hardware inserted in each insertion pass.
The patterns directory stores the patterns associated with the rtl2 design ID in an associated subdirectory.

Figure 109. TSDB File Structure, Core Level, Second Insertion Pass

Figure 110 shows the TSDB file structure after synthesis and scan chain insertion. The third-party
synthesis tool provides a synthesized gate-level netlist. This netlist, shown in Figure 110 in the yellow box
with a red outline, is the input for scan chain insertion along with the design-level TCD, ICL, and PDL from
the rtl2 design generated during the second DFT insertion pass.
For wrapped cores, Tessent performs wrapper analysis along with scan chain insertion, whereas for flat
designs, Tessent performs scan chain replacement and stitching. For information about using Tessent
Scan for scan insertion, refer to "Internal Scan and Test Circuitry Insertion" in the Tessent Scan and ATPG
User’s Manual.
Scan insertion does not insert instruments, so the instruments and patterns directories are not utilized in
this step.

476 Tessent™ Shell User’s Manual

 TSDB Data Flow for the Tessent Shell Flow
Top-Level TSDB Data Flow

Figure 110. TSDB File Structure, Core Level, Synthesis and Scan Insertion

The inputs to ATPG are the scan-inserted netlist and all the supporting files such as TCD, ICL, and PDL
files that were stored in the TSDB during the scan insertion pass (design_id gate), as shown in the yellow
box in Figure 111. Tessent creates the logic_test_cores directory to store the output pattern data for each
ATPG run, which can include runs for various test types and associated fault models as described in
"Fault Modeling Overview" in the Tessent Scan and ATPG User’s Manual. This is shown in the red boxes
in Figure 111. Refer to "Generating Test Patterns for Different Fault Models and Fault Grading" in the
Tessent Scan and ATPG User’s Manual for an example.

Figure 111. TSDB File Structure, Core Level, Pattern Generation

Before generating patterns for wrapped cores, Tessent creates a graybox model of the core. This model
is stored using the same design ID as the one created during scan insertion (design ID gate), so that
at the top-level you can either use the full design view or graybox view of the wrapped core. Refer to
"Performing ATPG Pattern Generation: Wrapped Core" for more information.

Top-Level TSDB Data Flow

The top-level TSDB data flow applies to the hierarchical RTL and scan DFT insertion flow. In the
hierarchical DFT insertion flow, you insert boundary scan and MemoryBIST, if present, at the top level of a
chip during the first DFT insertion pass.

Tessent™ Shell User’s Manual 477

TSDB Data Flow for the Tessent Shell Flow
Top-Level TSDB Data Flow

At the chip level, the core-level design data that was stored in the core-level TSDBs is used for ATPG
pattern retargeting. Refer to "RTL and Scan DFT Insertion Flow for the Top Chip" for details.

Table 22. Top-Level TSDB Data Flow Inputs and Outputs

Task Input Output

DFT insertion: • RTL netlist • Modified RTL + new RTL

first pass • Libraries • ICL for IJTAG network
design ID for • Required DFT signals • TCD: clocks, DFT signals
output: rtl1
• Boundary scan requirements • ICL for boundary scan + PDL
• TSDBs, lower core design data

DFT Insertion: • rtl1 design data • Modified RTL + new RTL

second pass • Libraries • ICL for IJTAG network
design ID for
output: rtl2 • Required DFT signals • TCD: clocks, DFT signals
• EDT and OCC requirements • ICL for OCC and EDT + PDL

Synthesis • Output from • Synthesized gate-level netlist

write_design_import_script
third-party tool command (use rtl2 design data)

Scan chain • Synthesized gate-level netlist • Scan-stitched gate-level netlist

insertion • Scan modes • ICL, PDL
design ID for
output: gate • TCD, ICL, PDL from rtl2 • TCD with scan modes

ATPG pattern • Gate scan-inserted design data • Flat model

generation (flat) • ATPG run name • Fault list
• Scan mode • Patterns database
• TCD

ATPG pattern • Gate scan-inserted design data • Flat model

generation (core • ATPG run name • Fault list
level)
• Scan mode • Patterns database
• Wrapped core ATPG pattern data, • TCD
retargeted

Figure 112 shows the data flow for the first DFT insertion pass. Tessent modifies the RTL netlist for
the design and generates new RTL for the boundary scan and MemoryBIST (if inserted) hardware. In
addition, it produces the TCD, ICL, and PDL for the design and the inserted instruments.
For integration at the top level, the scan-inserted design data and the interface views from the wrapped
cores are used. This is done by opening the core TSDB directories and using the read_design command
to read in the graybox model and the TCD, ICL, and PDL files.
The patterns directory stores the patterns associated with the rtl1 design ID in an associated subdirectory.

478 Tessent™ Shell User’s Manual

 TSDB Data Flow for the Tessent Shell Flow
Top-Level TSDB Data Flow

Tip
To facilitate data management, you can save each design (whether flat, core, sub-block, or chip)
in its own TSDB. This is the recommended practice when using Tessent Shell for DFT insertion.
You should have one TSDB per design.

Figure 112. TSDB Data Flow, Top Level, First Insertion Pass

Figure 113 shows the data flow for the second DFT insertion pass. In addition to the other input
requirements that you provide as shown in Table 22, Tessent uses the design data that was saved as rtl1
in the first pass, the gate scan-inserted design data, and graybox models from the wrapped cores.
Tessent saves the output design data for the EDT and OCC hardware in their applicable instruments
subdirectories. The design-level TCD, ICL, PDL, and modified RTL that includes the EDT, OCC, and
IJTAG network is placed in the dft_inserted_designs subdirectory for this insertion pass (rtl2).
The patterns directory stores the patterns associated with the rtl2 design ID in an associated subdirectory.

Tessent™ Shell User’s Manual 479

TSDB Data Flow for the Tessent Shell Flow
Top-Level TSDB Data Flow

Figure 113. TSDB Data Flow, Top Level, Second Insertion Pass

Figure 114 shows the data flow for scan chain insertion. Scan insertion does not insert instruments, so the
instruments and patterns directories are not utilized in this step.

Figure 114. TSDB Data Flow, Top Level, Scan Insertion

Figure 115 shows that output from ATPG pattern generation gets stored in the logic_test_cores directory.
As inputs, Tessent uses the scan-inserted design data for the chip and for the cores.

480 Tessent™ Shell User’s Manual

 TSDB Data Flow for the Tessent Shell Flow
Top-Level TSDB Data Flow

Figure 115. TSDB Data Flow, Top Level, ATPG Pattern Generation

As the final step for the top level in a hierarchical design, you perform ATPG pattern retargeting of the
core ATPG patterns as shown in "Top-Level ATPG Pattern Generation Example". Figure 116 shows that
you read in the ATPG patterns from the logic_test_cores directory from each of the core TSDB directories
and the scan-inserted design data for the chip and for the cores.

Tessent™ Shell User’s Manual 481

TSDB Data Flow for the Tessent Shell Flow
Top-Level TSDB Data Flow

Figure 116. TSDB Data Flow, Top Level, ATPG Pattern Generation With Pattern Retargeting

482 Tessent™ Shell User’s Manual

 Chapter 9
Streaming Scan Network (SSN)
Tessent Streaming Scan Network (SSN) is a bus-based scan data distribution architecture for use with
Tessent TestKompress. The design of SSN addresses common DFT challenges in testing system-on-
chip (SoC) designs, such as planning effort, tiled designs with abutment, test cost, and routing and timing
closure.
SSN decouples test delivery and core-level DFT requirements. This means that instance core-level
compression can be defined completely independently of chip I/O limitations. It enables programmatic
decisions, such as selecting which cores are tested concurrently. In a traditional pin-muxed approach,
these options would be hard-wired.
This section describes the recommended SSN work flows, including how to use SSN to effectively test
designs with identical cores and how to use different clock networks with SSN.

Tessent SSN Workflows

Rule Checks Before Writing SSN and ATPG Patterns
Advanced Topics
Tessent SSN Examples and Solutions
SSN Frequently Asked Questions
SSN Limitations

Tessent™ Shell User’s Manual 483

Streaming Scan Network (SSN)
Tessent SSN Workflows

Tessent SSN Workflows

There are several SSN Workflows, which are based on the Tessent Shell Flow for Hierarchical Designs.
In the general SSN Workflow, you perform a bottom-up DFT insertion for each physical block followed by
DFT insertion at the parent level. You continue this bottom-up flow until you have reached the top level of
the design.
The SSN Workflow description focuses on the differences from the base flows described in the Tessent
Shell Workflows section of this manual. The descriptions of the Workflows assume you understand the
information contained in the following sections. It is recommended that you read them first if you are new
to the Tessent Workflows.

• Tessent Shell Flow for Hierarchical Designs on page 217

• How the DFT Insertion Flow Applies to Hierarchical Designs on page 219

• Hierarchical DFT Terminology on page 217

Reference Testcase
The Tessent Shell release tree includes a testcase to accompany the block- and top-level workflows
described in the following sections. From within Tessent Shell, use the getenv TESSENT_HOME
command to find the installation tree. The testcase is in $TESSENT_HOME/share/UsageExamples in the
following file:
tessent_example_hierarchical_flow_with_ssn_v<year>.<quarter>.tgz
Figure 117 shows the structure of the directories in the testcase. You can run each step of the workflow in
one of these directories.

484 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Tessent SSN Workflows

Figure 117. Directory Structure of Reference Testcase

Block-Level SSN Insertion and Verification

Top-Level SSN Insertion and Verification

Tessent™ Shell User’s Manual 485

Streaming Scan Network (SSN)
Block-Level SSN Insertion and Verification

Block-Level SSN Insertion and Verification

This section presents the block-level Tessent Workflow for SSN by highlighting the minor differences from
the normal workflow where SSN is not present.
The SSN Workflow for block-level insertion contains minor differences in the dofiles relative to the flow
in the RTL and Scan DFT Insertion Flow for Physical Blocks on page 221 section of this manual. These
differences include minor additions and deletions required in the dofiles specific to each step. In Figure
117 on page 485 in the section Tessent SSN Workflows, the wrapped_cores subdirectories contain the
block-level SSN flow. The text preceding the figure explains how to find the testcase within the release
directory.

Note:
This procedure assumes your design meets the prerequisites of the hierarchical flow, as
described in DFT Architecture Guidelines for Hierarchical Designs on page 125. Additionally, each
physical block must have a full OCC with a shift clock injection mux and shift_only_mode.

The following figure shows an identical block-level workflow used to process a child physical block to
when you are not using SSN. As highlighted in the figure, you insert SSN into the design during the
second DFT insertion pass. In this same step, you add a second smaller EDT to the design for the
wrapper chains during external test. Click the boxes in the flow diagram to access the section describing
each step.

486 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Block-Level SSN Insertion and Verification

Figure 118. SSN Block-Level Workflow

First DFT Insertion Pass: Performing Block-Level MemoryBIST

Second DFT Insertion Pass: Inserting Block-Level EDT, OCC, and SSN
Synthesis for Block-Level Insertion
Creating the Post-Synthesis TSDB View (Block-Level)
Performing Scan Chain Insertion With Tessent Scan (Block-Level)
Verifying the ICL-Based Patterns After Synthesis (Block-Level)
Generating Block-Level ATPG Patterns

Tessent™ Shell User’s Manual 487

Streaming Scan Network (SSN)
First DFT Insertion Pass: Performing Block-Level MemoryBIST

First DFT Insertion Pass: Performing Block-Level

MemoryBIST
The first DFT insertion pass is identical to the Tessent Shell Flow for Hierarchical designs.
You can perform this step in the following directory of the Reference Testcase:

Procedure
The first DFT insertion pass inserts the non-scan DFT elements, such as memory BIST and IJTAG. It
happens before the second insertion pass inserts the logic test elements. Using SSN in the second DFT
insertion pass does not affect the first DFT insertion pass. At the top level, you must equip the boundary
scan cells with auxiliary input and output pins to connect the SSN bus. This change to the first DFT
insertion pass for the top level is described in “First DFT Insertion Pass: Performing MemoryBIST and
Boundary Scan” on page 193. For complete information about the current step at the block level, refer to
“First DFT Insertion Pass: Performing Block-Level MemoryBIST” on page 222.

Examples
Refer to the example dofile run_mbist_insertion in the directory shown in the "Referenced Testcase Step"
section earlier in this topic.

Second DFT Insertion Pass: Inserting Block-Level EDT,

OCC, and SSN
In the second DFT insertion pass, you insert the block-level EDT, OCC, and SSN elements.
This section explains the slight modifications that you do to the standard flow when you insert the SSN,
EDT, and OCC into the physical block level. For a complete description of this step in the standard flow,
refer to “Second DFT Insertion Pass: Inserting Block-Level EDT and OCC” on page 224.
You can perform this step in the following directories of the Reference Testcase:

Notes About This Procedure

488 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Second DFT Insertion Pass: Inserting Block-Level EDT, OCC, and SSN

• Similar to EDT and OCC, the tool creates the SSN hardware based on the SSN wrapper of the
DftSpecification. For a description of the SSN wrapper, refer to the SSN wrapper description in
the Tessent Shell Reference Manual.

• When the tool creates the SSH, EDT, and OCC elements at the same time with a single
invocation of the process_dft_specification command, the tool automates the connections
between the SSH, EDT, and OCC instances.

• As with the normal flow, after the insertion of the SSN and the other logic test elements,
you must simulate the ICLNetwork pattern to verify the correct IJTAG access to all inserted
logic test elements, including the SSN elements. Following a successful simulation of the
ICLNetwork pattern, you must simulate the SSN Continuity pattern to verify that the SSN
datapath is correctly integrated into the design. The tool automates the ICL verification
patterns and the SSN continuity patterns as part of the create_patterns_specification and
process_patterns_specification commands. During validation of the SSN datapath, you are
responsible for using the iProc command to write to the Multiplexer node to configure the
datapath for which you want to verify continuity, as explained in Step 7 in the following procedure.
You must complete simulation of both the ICLNetwork pattern and SSN continuity pattern before
moving to the next step of the DFT flow.

• To use third-party OCC with SSN, refer to the topic “Third-Party OCCs With SSN” on page 667
in the Tessent SSN Examples and Solutions section.
To insert the logic test elements with SSN, use the following procedure to modify the dofile described in
“Second DFT Insertion Pass: Inserting Block-Level EDT and OCC” on page 224.
Lint Checks for the SSN Hardware
®
RTL output for SSN includes waivers for SpyGlass to avoid lint errors. These waivers include comments
detailing why the rules are waived and use the following format:

// <explanatory comment>
// spyglass disable_block <rule list>
// <waived code>
// spyglass enable_block <rule list>

The <rule list> uses SpyGlass naming for the rules that are being waived (for example, "W116 W164a").

Prerequisites
• SSN requires that each physical block have a full OCC with a clock injection multiplexer and
support of the shift_only_mode feature.

Procedure
1. Remove the add_dft_signals commands for the scan signals edt_clock, edt_update, scan_en,
shift_capture_clock, and test_clock.
These signals are not needed because they are sourced by the ScanHost node during scan test.
If you want to have your legacy channel access mechanism coexist with SSN for your first few
designs, refer to Example 2 in the ScanHost reference page.

Tessent™ Shell User’s Manual 489

Streaming Scan Network (SSN)
Second DFT Insertion Pass: Inserting Block-Level EDT, OCC, and SSN

a. Delete this line:

add_dft_signals scan_en edt_update test_clock –source_node \

{ scan_enable edt_update test_clock_u }

b. Delete this line:

add_dft_signals edt_clock shift_capture_clock \

–create_from_other_signals

2. Update the "create_dft_specification ‑sri_sib_list" option to include SSN:

set spec [create_dft_specification -sri_sib_list {edt occ ssn} ]

This creates a dedicated IJTAG Sib node to serve as the host for the IJTAG interfaces of the
ScanHost and Multiplexer SSN nodes.

3. Update the comment for the report_config_syntax command to include SSN as an option to view
the syntax of the SSN DftSpecification:

// Use report_config_syntax DftSpecification/edt|occ|ssn to see full

syntax.

4. Update the DftSpecification to include the SSN wrapper to create one or more SSN Datapaths with
the nodes you want to insert in them. The following example creates a 32‑bit wide Datapath with
a ScanHost node preceded and followed by a Pipeline node. The SSN reference page contains
several example of different SSN DftSpecifications:

SSN {
ijtag_host_interface : Sib(ssn);
DataPath(main) {
output_bus_width : 32;
Pipeline(out) {
}
ScanHost(1) {
}
Pipeline(in) {
}
}
}

5. Update the EDT wrapper of the DftSpecification to include mode enables for the EDT, and add a
second EDT for the wrapper chains to be used during external test mode.

a. Change the name of the EDT Controller from "Controller (c1)" to "Controller (c1_int)" to indicate
that this EDT controller is used for internal test mode and is different from the second EDT that
is used in external test mode.

b. Add a Connections wrapper within the EDT Controller (c1_int) wrapper with the mode_enables
property to define the DFT Signal int_edt_mode as the mode enable for this EDT. This DFT
Signal was added previously in the dofile and is used in the muxing logic that selects this
EDT’s channel outputs to the SSH during the internal test mode.

490 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Second DFT Insertion Pass: Inserting Block-Level EDT, OCC, and SSN

EDT {
ijtag_host_interface : Sib(edt);
Controller (c1_int) {
longest_chain_range : 70, 80;
scan_chain_count : 20;
input_channel_count : 3;
output_channel_count : 3;
Connections {
mode_enables : DftSignal(int_edt_mode);
}

c. Add a second EDT controller for the wrapper chains to be used during external test mode.
The "ext_edt_mode" DFT signal is used as the mode enable for this EDT. This DFT signal was
added previously in the dofile and is used in the muxing logic that selects this EDT’s channel
outputs to the SSH during the external test mode.

Controller (c1_ext) {
longest_chain_range : 70, 80;
scan_chain_count : 2;
input_channel_count : 1;
output_channel_count : 1;
Connections {
mode_enables : DftSignal(ext_edt_mode);
}
}

6. The SSN network that the specification just inserted is checked and extracted within the ICL
model using the same extract_icl command that already checks and extracts the IJTAG network
description. These design rule checks run automatically, and there is generally no need for
additional input, except that you must specify the ‑create_ijtag_graybox on switch to create the
IJTAG graybox in the TSDB.

7. The create_patterns_specification command creates a pattern specification for the ICL network
that includes the SSN logic that was just inserted and all other element types, such as the
Memory BIST logic (if present). The SSN continuity pattern is also created as part of the
create_patterns_specification process and verifies the SSN datapath is properly connected. This is
a mandatory verification step. The following example contains no Multiplexer node to configure at
the block level. If you have such nodes at the block level, understand how they are handled at the
bottom of the dofile example in the section “Second DFT Insertion Pass: Inserting Top-Level EDT,
OCC, and SSN” on page 511. Because you created an IJTAG graybox, the tool creates the ICL
verification patterns wrapper and SSN continuity patterns wrapper using the IJTAG graybox view
for both simulations.

Note:
You can also create the SSN continuity pattern with the low-level
create_ssn_continuity_patterns command, as shown at the bottom of the example dofile
found at the end of this section.

Tessent™ Shell User’s Manual 491

Streaming Scan Network (SSN)
Second DFT Insertion Pass: Inserting Block-Level EDT, OCC, and SSN

Examples
The following is a dofile for the second DFT pass. You can also find it in the run_ssh_edt_occ_insertion
scripts in the testcase directories shown in the "Referenced Testcase Step" section earlier in this topic.
The testcase also includes the run_continuity_sims script that shows how to simulate the SSN continuity
patterns.

# Set the context to insert DFT into RTL-level design

# Define a new design ID
set_context dft -rtl -design_id rtl2
# Set the location of the TSDB. Default is the current working directory.
set_tsdb_output_directory ../tsdb_outdir
# Read in the Tessent cell library
read_cell_library ../../../library/standard_cells/tessent/adk.tcelllib
# Read in memory verilog model
read_verilog ../../../library/memories/*.v -exclude_from_file_dictionary
# Use read_design with the design ID from the first DFT insertion pass
read_design processor_core -design_id rtl1 -verbose
set_current_design processor_core
# DFT Signal used for logic test
add_dft_signals ltest_en
# DFT Signal used to test memories with multiple load ATPG patterns
add_dft_signals memory_bypass_en
# DFT Signal required to test STI network during logic test
add_dft_signals tck_occ_en
# DFT Signals required for hierarchical DFT and used during scan insertion
add_dft_signals int_ltest_en ext_ltest_en int_mode, ext_mode, \
int_edt_mode ext_edt_mode
report_dft_signals
# Run pre-DFT DRC rules
set_dft_specification_requirements -logic_test on
check_design_rules
# Create and report a DFT Specification
set spec [create_dft_specification -sri_sib_list {edt occ ssn} ]
# Use report_config_syntax DftSpecification/edt|occ|ssn to see full syntax
report_config_data $spec
# Specify the logic to be created with the EDT, OCC, and SSN wrappers.
# The connection between the EDT, OCC, and SSH created by the too.
# Modify the below specification to your specific design requirements.
read_config_data -in_wrapper $spec -from_string {
Occ {
ijtag_host_interface : Sib(occ);
include_clocks_in_icl_model : on;
Controller(dco_clk) {
clock_intercept_node : dco_clk;
}
}
SSN {
ijtag_host_interface : Sib(ssn);
DataPath(1) {
output_bus_width : 32;
Pipeline(2) {

492 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Second DFT Insertion Pass: Inserting Block-Level EDT, OCC, and SSN
}
ScanHost(1) {
}
Pipeline(1) {
}
}
}
EDT {
ijtag_host_interface : Sib(edt);
Controller (c1_int) {
longest_chain_range : 70, 80;
scan_chain_count : 20;
input_channel_count : 3;
output_channel_count : 3;
Connections {
mode_enables : DftSignal(int_edt_mode);
}
}
Controller (c1_ext) {
longest_chain_range : 70, 80;
scan_chain_count : 2;
input_channel_count : 1;
output_channel_count : 1;
Connections {
mode_enables : DftSignal(ext_edt_mode);
}
}
}
}
# Display the content of the DftSpecification just defined above
report_config_data $spec
# Generate the hardware
process_dft_specification
# Extract IJTAG network and create ICL file for core level
extract_icl ‑create_ijtag_graybox on
# Write updated RTL into this new file to elaborate and synthesize later
write_design_import_script -use_relative_path_to . for_dc_synthesis.tcl -
replace
# Generate testbench for ICLNetwork and Continuity patterns
# Generate ICL Verify patterns. Use the variable to update it if needed.
set spec [create_patterns_specification]
process_patterns_specification
# Point to simulation libraries and run the Verilog simulation
set_simulation_library_sources \
-v ../../../library/standard_cells/verilog/adk.v \
-v ../../../library/memories/*.v
run_testbench_simulations
exit

The following is an alternate way to create the SSN continuity pattern. Refer to Step 7 in the Procedure
section of this topic for an explanation of how to create the SSN continuity pattern.

Tessent™ Shell User’s Manual 493

Streaming Scan Network (SSN)
Synthesis for Block-Level Insertion

#
# Create the continuity pattern
#
# Define SSN bus clock. If you are using time multiplexing
# you must specify the -freq_multiplier switch
add_clocks ssn_bus_clock

# check design rules and transition to analysis mode

check_design_rules

# set ijtag period

set_ijtag_retargeting_options -tck_period 10

# set ssn bus clock period

set_load_unload_timing_options -usage ssn -ssn_bus_clock_period 5

# Create the SSN continuity pattern

open_pattern_set ssn_continuity -usage ssn
create_ssn_continuity_patterns
close_pattern_set
# Write simulation testbench
write_patterns patterns/ssn_continuity.v -verilog -replace \
-parameter_list {SIM_COMPARE_SUMMARY 1}

Synthesis for Block-Level Insertion

Use the following dofile changes to synthesize the DFT-inserted RTL block.
You can perform this step in the following directories of the Reference Testcase:

In the dofile of the section “Second DFT Insertion Pass: Inserting Block-Level EDT, OCC, and SSN” on
page 488, you used the write_design_import_script command to export a design load script for use in
your synthesis tool.
Refer to the section “Synthesis Guidelines for RTL Designs With Tessent Inserted DFT” on page 989
for guidelines on how to perform the synthesis step. Also, refer to the section “Example Scripts Using
Tessent Tool-Generated SDC” on page 979 for example scripts specific to various synthesis tools.
When synthesis completes, it produces a file containing the concatenated netlist of the physical block you
just synthesized.

494 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Creating the Post-Synthesis TSDB View (Block-Level)

• If you performed scan insertion within the synthesis tool, continue with the steps described in the
section “Creating the Post-Synthesis TSDB View (Block-Level)” on page 495.

• If you are inserting your scan chains within Tessent, continue with the steps described in the
section “Performing Scan Chain Insertion With Tessent Scan (Block-Level)” on page 496.

Example
Example dofiles are available as the <module_name>.dc_synth_script files found in the testcase
directories shown in the "Referenced Testcase Step" section earlier in this topic. These files
specify the TCK period and the set_load_unload_timing_options values using a separate file called
<design_name>.timing_options. When you source this file at this point, it configures the SDC during
synthesis. A step later in the flow also sources this file from ATPG dofiles to configure the patterns with
the exact timing options that the tool used during timing closure.

Creating the Post-Synthesis TSDB View (Block-Level)

When you are using third-party scan insertion, use the following procedure to create the post-synthesis
TSDB, separate from scan insertion. Creation of the post-synthesis TSDB occurs automatically as part of
scan insertion when you use Tessent Scan.
You can perform this step in the following directories of the Reference Testcase:

Notes About This Procedure

This step combines a third-party scan-inserted netlist and the collateral from the RTL insertion step
into a new dft_inserted_design directory. By consolidating the netlist and the collateral into the
dft_inserted_design directory, you can use the tool automation in future steps to load the design using the
read_design command.
The TSDB consolidation flow works by using the read_verilog command to read the third-party scan-
inserted netlist into the tool and then using the "read_design ‑no_hdl ‑design_id rtl2" command to read
the collateral from the last RTL insertion step. Write the design into the tsdb_outdir directory using the
"write_design ‑tsdb ‑softlink_netlist ‑create_ijtag_graybox on" command.
The following procedure and example dofile show how to create a dft_inserted_design directory with the
post-synthesis TSDB flow.

Procedure
1. Set the context to -no_rtl and define the design_id as "gate" using the set_context command.

2. Use the read_verilog command to read the scan-inserted design. This is the output of the third-
party scan-insertion step.

3. Use the "read_design ‑no_hdl -design_id rtl2" command to load the collateral from the last DFT
RTL insertion step.

Tessent™ Shell User’s Manual 495

Streaming Scan Network (SSN)
Performing Scan Chain Insertion With Tessent Scan (Block-Level)

The design collateral includes the block level ICL, PDL, SDC, TCD, and other files.

4. Use the "write_design ‑tsdb -softlink_netlist ‑create_ijtag_graybox_on" command to populate the

dft_inserted_design directory with the collateral and a symbolic link to your scan-inserted netlist.
This also creates a gate-level IJTAG graybox view for the design that you can use during the ICL-
based pattern verification step, and also later during SSN scan retargeting at the top level.

The tool also updates design instance names in the ICL file. This happens when the ICL objects
were below generated blocks in the RTL.

Examples
The following is an example dofile for the TSDB consolidation step:

# Set context for this step

set_context dft -no_rtl -design_id gate
# Specify the TSDB output directory to write into.
set_tsdb_output_directory ../tsdb_outdir
# Read the scan-inserted design
read_verilog ../3.synthesize_rtl/processor_core_synthesized.vg
# Read only the collateral from the last DFT insertion step
read_design processor_core -design_identifier rtl2 -no_hdl –verbose
set_current_design processor_core
# Write the netlist and collateral to the tsdb_outdir
write_design -tsdb -softlink_netlist -create_ijtag_graybox on –verbose

exit

Performing Scan Chain Insertion With Tessent Scan

(Block-Level)
The Tessent Scan insertion step in the SSN flow is similar to the scan chain insertion step in the Tessent
Shell Flow for hierarchical designs.
You can perform this step in the following directories of the Reference Testcase:

The complete details for this step appear in the topic “Performing Scan Chain Insertion: Wrapped Core”
on page 229.
When SSN is present, the tool connects wrapper chains to the second, smaller EDT controller added
during the step “Second DFT Insertion Pass: Inserting Block-Level EDT, OCC, and SSN” on page 488.
The following procedure shows how to modify the dofile from the topic Performing Scan Chain Insertion:
Wrapped Core when you are using SSN.

496 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Performing Scan Chain Insertion With Tessent Scan (Block-Level)

Procedure
1. Remove the commands that exclude the *_edt_channels_* from wrapper analysis. For example,
remove:

set_wrapper_analysis_options \
-exclude_ports [ get_ports {*_edt_channels_*}]

In the SSN flow, the EDT channels connect directly to the ScanHost node instead of being brought
to the boundary of the block.

2. Add the following code to find each EDT and assign it to its intended scan mode:

foreach_in_collection edt $edt_instance {

if {[regexp {.*int.*} [get_single_name $edt] int_edt_instance]}{
puts "Found instance $int_edt_instance. \
Will use this for internal scan_mode."
} elseif {[regexp {.*ext.*} [get_single_name $edt] \
ext_edt_instance]} {
puts "Found instance $ext_edt_instance. \
Will use this for external scan_mode."
}
}

During the second DFT insertion pass, the tool gave each added EDT controller a name according
to how it was intended to be used (internal mode EDT is "c1_int" and external mode EDT is
"c1_ext").

3. Add the following commands to assign each EDT to the intended scan mode. In this example, the
scan mode is named using the name of the DFT signal that activates that mode:

add_scan_mode int_edt_mode -edt_instances $int_edt_instance

add_scan_mode ext_edt_mode -edt_instances $ext_edt_instance

If you wanted to use different scan mode names, you would need to use the ‑dft_signal_name
switch of the add_scan_mode command to associate the correct DFT signal to that mode.

4. After you implement all the scan modes using the insert_test_logic command, run the code block
highlighted in gold at the end of the following example dofile to perform DRC on each scan mode
and extract the graybox model for the external mode.

5. Create the gate-level IJTAG graybox view by changing the context to patterns ‑ijtag and then
running the "analyze_graybox ‑ijtag" command followed by the "write_design ‑tsdb -graybox"
command.

Examples
The following is an example dofile for the scan insertion step:

# Set context to perform scan insertion and stitching

set_context dft -scan
# Open the previous TSDB directories if not in the current working
# directory
set_tsdb_output_directory ../tsdb_outdir

Tessent™ Shell User’s Manual 497

Streaming Scan Network (SSN)
Performing Scan Chain Insertion With Tessent Scan (Block-Level)
# Read Tessent Library
read_cell_library ../../../library/standard_cells/tessent/adk.tcelllib
# Read the synthesized netlist
read_verilog ../3.synthesize_rtl/processor_core_synthesized.vg
# Read the design data for the second RTL insertion pass
read_design processor_core -design_identifier rtl2 -no_hdl -verbose
set_current_design processor_core
add_black_boxes -modules { \
SYNC_1RW_8Kx16 \
}
check_design_rules
report_clocks
# To force insertion of dedicated wrapper cell use the
# set_dedicated_wrapper_cell_options command
# set_dedicated_wrapper_cell_options on -ports {… }
# Perform and Report wrapper cell analysis
analyze_wrapper_cells
report_wrapper_cells -Verbose
# Specify different modes (int/ext) how the chains need to be stitched
# The type internal/external and enable_dft_signal are inferred from
# registered DFT Signals(int_edt_mode and ext_edt_mode)
set edt_instance [get_instances -of_icl_instances [get_icl_instances -
filter tessent_instrument_type==mentor::edt]]
foreach_in_collection edt $edt_instance {
if {[regexp {.*int.*} [get_single_name $edt] int_edt_instance]} {
puts "Found EDT instance $int_edt_instance. Will use for int scan_mode."
} elseif {[regexp {.*ext.*} [get_single_name $edt] ext_edt_instance]} {
puts "Found EDT instance $ext_edt_instance. Will use for ext scan_mode"
}
}
add_scan_mode int_edt_mode -edt_instances $int_edt_instance
add_scan_mode ext_edt_mode -edt_instances $ext_edt_instance
# Analyze the scan chains and review the different scan modes and chains
# before stitching the chains
analyze_scan_chains
report_scan_chains
# Insert scan chains and write the scan-inserted design into tsdb_outdir
insert_test_logic
report_scan_chains
report_scan_cells > scan_cells.list

# DRC check the scan chains in each mode and create graybox for
# external mode

set_context pattern -scan

foreach_in_collection mode_wrapper [get_config_elements \

Core(processor_core)/Scan/Mode -part tcd -silent] {
set mode_name [get_config_value $mode_wrapper -id <0>]
set mode_type [get_config_value type -in $mode_wrapper]
import_scan_mode $mode_name
#In setup mode
report_clocks

498 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Verifying the ICL-Based Patterns After Synthesis (Block-Level)
check_design_rules
#In Analysis mode
if {$mode_type eq "external"} {
report_scan_cells
analyze_graybox ‑scan
write_design -tsdb -graybox -verbose
}
set_system_mode setup
}
# Create the IJTAG graybox

set_context patterns -ijtag

set_system_mode analysis
analyze_graybox -ijtag
write_design -tsdb -graybox -verbose

exit

Verifying the ICL-Based Patterns After Synthesis

(Block-Level)
Resimulating the MemoryBIST and ICL verification patterns after synthesis ensures the ICL network is
fully functional and able to be reliably used during ATPG and Scan retargeting setup.
You can perform this step in the following directories of the Reference Testcase:

Notes About This Procedure

Verifying the ICL-based patterns after synthesis is especially critical when using SSN because the bulk
of the test_setup relies on IJTAG. Your MemoryBIST simulations are also redone in this step. For the
complete details of this step, refer to “Verifying the ICL Model” on page 232.
When you use SSN, it is important to also reverify the SSN continuity after synthesis before you try to use
it for ATPG and scan retargeting.
The following procedure and example dofile show how to verify an ICL model including SSN.

Procedure
1. The top part of the dofile is identical to the normal flow. You can examine the PatternsSpecification
generated by the create_patterns_specification command to determine how it uses the IJTAG
graybox view that you created in the previous step to simulate the ICLVerify patterns and the SSN
continuity patterns.

2. As discussed earlier in this flow, you are responsible for configuring the SSN datapath you want to
verify the continuity for by using iProcs containing iCall commands to the Tessent-generated PDL

Tessent™ Shell User’s Manual 499

Streaming Scan Network (SSN)
Verifying the ICL-Based Patterns After Synthesis (Block-Level)
to write to the Multiplexer nodes when present. You must complete simulating both the ICLNetwork
pattern and SSN continuity pattern before moving to the next step of the DFT flow.

Note:
You can also create the SSN continuity pattern with the low-level
create_ssn_continuity_patterns command, as shown at the bottom of the example dofile
found at the end of this section.

Examples
This example dofile shows how to verify the ICL model for SSN.
The create_patterns_specification command creates a pattern specification for the SSN continuity pattern
and the ICL network that includes the IJTAG logic, SSN logic, and the MemoryBIST logic, if present.
This example contains no Multiplexer node to configure. If you have such nodes at the block level,
understand how they are handled at the bottom of the dofile example in the section “Second DFT
Insertion Pass: Inserting Top-Level EDT, OCC, and SSN” on page 511.

# Set context to patterns

set_context patterns
# Open the previous TSDB directories if it is not in the current
# working directory
set_tsdb_output_directory ../tsdb_outdir
# Read Tessent Library
read_cell_library ../../../library/standard_cells/tessent/adk.tcelllib
read_verilog ../../../library/memories/SYNC_1RW_8Kx16.v -interface_only
# Read the design files from the scan insertion pass
read_design processor_core -design_identifier gate -verbose
set_current_design processor_core
# Generate patterns to verify the inserted DFT logic
set spec [create_patterns_specification]
report_config_data $spec
process_patterns_specification
# Point to the libraries and run the simulation
set_simulation_library_sources -v ../../../library/standard_cells/ \
verilog/adk.v -v ../../../library/memories/*.v
run_testbench_simulations
check_testbench_simulations -report_status

exit

The following is an alternate way to create the SSN continuity pattern. Refer to Step 2 in the Procedure
section of this topic for an explanation of how to create the SSN continuity pattern.

#
# Create the continuity pattern
#
# Define SSN bus clock. If you are using time multiplexing
# you must specify the -freq_multiplier switch
add_clocks ssn_bus_clock

# check design rules and transition to analysis mode

500 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Generating Block-Level ATPG Patterns
check_design_rules

# set ijtag period

set_ijtag_retargeting_options -tck_period 10

# set ssn bus clock period

set_load_unload_timing_options -usage ssn -ssn_bus_clock_period 5

# Create the SSN continuity pattern

open_pattern_set ssn_continuity -usage ssn
create_ssn_continuity_patterns
close_pattern_set
# Write simulation testbench
write_patterns patterns/ssn_continuity.v -verilog -replace \
-parameter_list {SIM_COMPARE_SUMMARY 1}

Generating Block-Level ATPG Patterns

The process for generating ATPG patterns in the SSN flow is similar to the process used without SSN.
You can perform this step in the following directories of the Reference Testcase:

Notes About This Procedure

The complete details for this step appear in the “Performing ATPG Pattern Generation: Wrapped Core”
on page 233. The SSN flow generates the scan graybox model as part of the "" step. Therefore, this step
follows most of the standard flow, skipping the graybox generation because the insertion step has already
completed that part. If you are performing scan insertion as part of synthesis, you create the graybox as
part of creating ATPG patterns for the external mode, as shown in the Sample Dofile in this section and
illustrated in the 0opt.run_scan_graybox_generation script in the reference testcase directories mentioned
previously.
When SSN is present, the tool automatically generates all load and unload procedures and their timing
based on the timing specified with the set_load_unload_timing_options, set_ijtag_retargeting_options,
and set_capture_timing_options commands. The default bus_clock frequency and shift_clock frequency
are 400 MHz and 100 MHz, respectively. Furthermore, you can improve the setup and hold timing
around the edges of the scan_en and edt_updated signals. Use the -scan_en_*_extra_cycles and
‑edt_update_*_extra_cycles arguments to the set_load_unload_timing_options command to add
extra cycles around the edges of scan_en and edt_update, respectively. If at any time during scan
pattern retargeting or top-level ATPG you need to change the timing of a physical block, use the
set_current_physical_block command to set the scope of all subsequent load/unload and capture timing
settings. The reference page for the set_load_unload_timing_options command contains an explanation
on how to use a single file that you source in both Tessent and the synthesis tool to configure the pattern
generation and SDC consistently. The 1.run_internal_stuck and 2.run_internal_transition scripts in
the reference testcase directories mentioned previously provide clear illustrations of this process. The
<module_name>.timing_options file configures the SDC during synthesis, and you reuse it later to
configure the patterns so that they are generated consistently.

Tessent™ Shell User’s Manual 501

Streaming Scan Network (SSN)
Generating Block-Level ATPG Patterns

If you did not use Tessent Scan, you cannot use the import_scan_mode command, and you use the
add_core_instances command to select your active OCC and EDT controllers. You never need to use
the add_core_instances command on the ScanHost instance. The tool automatically adds ScanHost
core instances during the transition to analysis mode. When the tool performs the check_design_rules
command, it automatically adds the ScanHost instance to which a scan chain or an active EDT traced.
The 0opt.run_scan_graybox_generation script in the reference testcase mentioned previously provides a
clear illustration of this process.
After you run create_patterns, the tool maps the SSN data stream to the SSN bus. It calculates SSH
parameters when you write patterns with the write_patterns command. To determine the final calculated
parameters of the SSH, use the report_core_instance_parameters command after having called the
write_patterns command.
Use the SSH loopback pattern to verify that the SSN network can successfully deliver packetized data to
each active SSH. During the SSH loopback pattern, the ScanHost node does not send scan data out to
the scan chains and EDT but instead loops it back internally.

• SSN patterns written in the serial testbench format deliver packetized scan data over the SSN
data bus to each active SSH. Each active SSH transfers scan data to the scan chains and EDT
and locally generates the scan signals. The scan out compares are mapped to the SSN bus_out.

• SSN patterns written in the parallel testbench format apply scan data similarly to a non-SSN
parallel testbench. The tool adds cut points to the boundary of the SSH to drive the scan signals.
During Streaming-Through-IJTAG, the tool replaces the parallel SSN bus by the serial JTAG interface.
Select the serial JTAG interface as the streaming interface with the set_ssn_options command. The
tool delivers packetized scan data synchronously through the TDI port using TCK as the clock. You can
stream any SSN pattern set through the serial JTAG interface without modification. For more information
about Streaming-Through-IJTAG, refer to “Streaming-Through-IJTAG Scan Data” on page 535.
You can create SSN patterns using a scaled-down SSN bus width. Scale the SSN bus width with the
set_ssn_datapath_options command. You can reapply any SSN pattern using a scaled-down SSN bus.
When simulating patterns at the core level, the SSN bus clock typically runs slower because
it is limited by shift clock frequency. To run the bus clock at maximum frequency, set the
"SIM_SSN_MAXIMUM_BUS_SPEED 1" parameter value pair with the "write_patterns ‑parameter_list"
command and switch to add padding to the packet.
SSN supports only the .patdb file format for scan pattern retargeting.

Prerequisites
• Running ATPG with SSN requires a validated ICL model of the current design.

Procedure
1. Run ATPG in internal mode on the wrapped core.
This step in the SSN flow is similar to the step "Run ATPG on the internal mode of the wrapped
core" in the topic “Performing ATPG Pattern Generation: Wrapped Core” on page 233, in the
hierarchical flow section of this manual. Refer to this section for a detailed description of this step.
Use the following steps to update the dofile from the hierarchical flow procedure referenced
previously:

502 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Generating Block-Level ATPG Patterns

a. Set the ijtag_tck period for this core to the required frequency using the
set_ijtag_retargeting_options command. This should be the ijtag_tck clock frequency you
closed timing at.

b. Define the SSN bus_clock and shift_clock periods for the core using the
set_load_unload_timing_options command. The bus_clock period should be the maximum
bus_clock frequency you plan to use for the chip. If you specify a slower frequency, it limits the
bus clock frequency of the entire datapath when this ATPG pattern is retargeted. The default
bus_clock period is 2.5 ns, and the default shift_clock is 10 ns. The 1.run_internal_stuck and
2.run_internal_transition scripts in the reference testcase directories mentioned previously
show you how to do this with the synthesis process used.

c. Define the clock frequency used during the capture process. The SSH is capable of having
a different frequency for the shift_capture_clock during the shift and the capture cycles. The
default slow capture clock frequency is 40 MHz to enable reliable capture staggering.

d. Report core instances after you run check_design_rules. As part of check_design_rules, the
tool automatically adds the SSH core instance that was traced to from the active scan chains
and EDT controllers.

e. Write the SSH loopback pattern. Simulate this pattern to confirm that the SSN network can
successfully deliver packetized data to the SSH. Start by simulating the parallel load scan
patterns. Once those are clean, simulate the serial SSH loopback pattern, followed by one
Serial Chain pattern and one Serial Scan pattern.
The sample dofile in the following Examples section also creates the on-chip comparator self-
test pattern. This pattern set is only relevant for blocks having a ScanHost that supports the
on-chip compare mode. This pattern set is not required for sign-off simulation but is critical
during manufacturing test to ensure that no fault within the comparator logic can be present,
which could mask faults within the scanned logic to be detected. Refer to the section “On-Chip
Compare With SSN” on page 537 for more information about this pattern set.

f. Run the "set_chain_test ‑type nomask" command. This enables writing the chain test patterns
without masking. Simulating all chain test patterns is not practical for most designs. When you
write the chain test patterns with the "‑end 0" option, the tool writes one chain test pattern that
simulates all the chains more efficiently.

g. Write a single serial scan pattern. One serial scan pattern combined with a full set of parallel
patterns provides sufficient coverage of the SSN and the scan chains.
Refer to the Examples section for a sample dofile updated using these steps. Also, refer to the
1.run_internal_stuck and 2.run_internal_transition scripts in the reference testcase directories
mentioned previously.

2. Run ATPG in external mode on the wrapped core.

This step in the SSN flow is similar to the step "Run ATPG on the external mode of the wrapped
core" in the topic “Performing ATPG Pattern Generation: Wrapped Core” on page 233, in the
hierarchical flow section of this manual. During the external mode run, the core-level SSH sources
the scan signals to the small wrapper chain EDT.

Note:
This ATPG pattern is used only to verify the proper behavior of the wrapper chains. It
cannot be reused from the chip level.

Tessent™ Shell User’s Manual 503

Streaming Scan Network (SSN)
Generating Block-Level ATPG Patterns

The procedure for modifying the dofile presented in the hierarchical flow section is the same as the
procedure for modifying the internal mode dofile. Refer to Substeps 1.a through 1.g in Step 1 for
the instructions on updating your dofile. Refer to the Examples section for a sample dofile updated
using these steps.

Examples

Sample Dofile
The following dofile shows the result of following the instructions for internal and external mode ATPG.
Because the dofile for the two modes are very similar, the following dofile shows the full internal
mode dofile. The differences for an external mode dofile appear as comments in green text marked
"EXTERNAL MODE:".
All changes from the base hierarchical flow for SSN appear in gold text.

set_context patterns -scan

# Set the location of the TSDB. Default is the current working directory.
set_tsdb_output_directory ../tsdb_outdir

# Read Tessent Library

read_cell_library ../../../library/standard_cells/tessent/adk.tcelllib

# Read in the scan inserted netlist/design

read_design processor_core -design_id gate -verbose

set_current_design processor_core

# Specify the current mode using a unique name (different from

# add_scan_mode).
# Then bring in required scan mode configuration
set_current_mode int_edt_mode_stuck -type internal
import_scan_mode int_edt_mode -fast_capture off
# EXTERNAL MODE:
# set_current_mode ext_edt_mode_stuck -type external
# import_scan_mode ext_edt_mode -fast_capture off
# Define the tck period and ijtag retargeting options
set_ijtag_retargeting_options -tck_period 10

# Define the shift and bus clock timing

set_load_unload_timing_options -usage ssn \
-shift_clock_period 10ns \
-ssn_bus_clock_period 5ns

# Define the slow clock capture timing

set_capture_timing_options -mode_type internal \
-capture_clock_period 40ns
# Report core instances that were added as part of importing scan mode
report_core_instances

set_core_instance_parameters -instrument_type occ -parameter_values \

{capture_window_size 3}

504 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Generating Block-Level ATPG Patterns
report_dft_signals
report_core_instances
report_static_dft_signal_settings
check_design_rules
# EXTERNAL MODE:
# If you inserted your scan chains during synthesis, extract the graybox
# model here.
# analyze_graybox
# write_design -graybox -tsdb -verbose

report_clocks
report_core_instances

# Confirm the SSN core instance was added

report_core_instance_parameters
set_fault_type stuck
add_fault -all
report_statistics -detail

# Generate patterns
create_patterns
report_statistics -detail

# Store TCD, flat_model, fault list and patDB format files in the TSDB
# directory
write_tsdb_data -replace
# Write Verilog patterns for simulation
# Write parallel load testbench
write_patterns patterns/processor_core_int_edt_mode_stuck_parallel.v \
-verilog -replace -parameter_list {SIM_COMPARE_SUMMARY 1} \
-pattern_sets scan

# Write SSH loopback pattern

write_patterns patterns/processor_core_int_edt_mode_stuck_loopback.v \
-verilog -serial -replace -parameter_list {SIM_COMPARE_SUMMARY 1} \
-pattern_sets ssh_loopback

# Use this option for signoff simulations to verify all chains with a
# single chain pattern
set_chain_test ‑type nomask
write_patterns patterns/processor_core_int_edt_mode_stuck_serial_chain.v \
-verilog -serial -replace -end 0 -parameter_list \
{SIM_COMPARE_SUMMARY 1} -pattern_sets chain

write_patterns patterns/processor_core_int_edt_mode_stuck_serial_scan.v \
-verilog -serial -replace -end 0 -parameter_list \
{SIM_COMPARE_SUMMARY 1 ALL_EXCLUDE_UNUSED 0} \
-pattern_sets scan

# EXTERNAL MODE:
# write_patterns patterns/processor_core_ext_edt_mode_stuck_parallel.v \
# -verilog -replace -parameter_list {SIM_COMPARE_SUMMARY 1} \
# -pattern_sets scan

Tessent™ Shell User’s Manual 505

Streaming Scan Network (SSN)
Generating Block-Level ATPG Patterns
# write_patterns patterns/processor_core_ext_edt_mode_stuck_loopback.v \
# -verilog -serial -replace -parameter_list {SIM_COMPARE_SUMMARY 1} \
# -pattern_sets ssn_loopback

# Use this option for signoff simulations to verify all chains with a
# single chain pattern
# set_chain_test ‑type nomask
# write_patterns patterns/processor_core_ext_edt_mode_stuck_serial_chain.v \
# -verilog -serial -replace -end 0 -parameter_list \
# {SIM_COMPARE_SUMMARY 1} -pattern_sets chain
# write_patterns patterns/processor_core_ext_edt_mode_stuck_serial_scan.v \
# -verilog -serial -replace -end 0 -parameter_list \
# {SIM_COMPARE_SUMMARY 1 ALL_EXCLUDE_UNUSED 0} -pattern_sets scan
# Write SSH on-chip comparator self test patterns
write_patterns patterns/processor_core_int_ssh_occomp_self_test.v \
-verilog -serial -replace -end 8 -parameter_list \
{SIM_COMPARE_SUMMARY 1} -pattern_sets ssh_on_chip_compare
# report fault coverage
report_statistics -detail

exit

506 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Top-Level SSN Insertion and Verification

Top-Level SSN Insertion and Verification

During top-level SSN insertion, the tool inserts other logic test elements into the design. This DFT
insertion flow is similar to the one where SSN is not present.
This section explains the differences in the dofiles relative to the standard hierarchical flow (described in
the section “RTL and Scan DFT Insertion Flow for the Top Chip” on page 240). These differences include
modifications that specific dofiles require.

Note:
This procedure assumes your design meets the prerequisites of the hierarchical flow, as
described in “DFT Architecture Guidelines for Hierarchical Designs” on page 125. Additionally,
each physical block must have a full OCC with a shift clock injection mux and shift_only_mode.

Figure 1 shows the same top-level workflow you follow when not using SSN. It has been updated to
indicate that you insert SSN into the design during the second DFT insertion pass. This step adds a single
EDT if there is top-level logic. You can also add the boundary scan chains to this top-level EDT using
the BoundaryScan/max_segment_length_for_logictest property. Unlike at the core-level SSN insertion
flow, this process does not add a second, smaller EDT, because the top-level boundary scan chains can
provide isolation for the top level during top-level ATPG. Click the boxes in the flow diagram to access the
section describing each step. The steps described in this section are implemented in the "top" directory of
the Reference Testcase.

Tessent™ Shell User’s Manual 507

Streaming Scan Network (SSN)
Top-Level SSN Insertion and Verification

Figure 119. SSN Top-Level Workflow

First DFT Insertion Pass: Performing Top-Level MemoryBIST

Second DFT Insertion Pass: Inserting Top-Level EDT, OCC, and SSN
Synthesis for Top-Level Insertion
Creating the Post-Synthesis TSDB View (Top-Level)
Performing Scan Chain Insertion With Tessent Scan (Top-Level)

508 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
First DFT Insertion Pass: Performing Top-Level MemoryBIST
Verifying the ICL-Based Patterns After Synthesis (Top-Level)
Generating Top-Level ATPG Patterns
Retargeting ATPG Patterns
Performing Reverse Failure Mapping for SSN Pattern Diagnosis

First DFT Insertion Pass: Performing Top-Level

MemoryBIST
The first DFT insertion pass at the top level adds non-scan DFT elements to the design. This step is
similar to the first DFT insertion pass of the standard hierarchical flow. However, it uses the auxiliary input
and output pins to connect the SSN bus and the bus_clock instead of using them for the EDT channels.
You can perform this step in the following directory of the Reference Testcase:

Notes About This Procedure

• For a complete description of this step in the standard hierarchical flow, refer to the section “First
DFT Insertion Pass: Performing Top-Level MemoryBIST and Boundary Scan” on page 243.
To define the auxiliary logic pins for connecting the SSN bus and bus_clock, modify the dofile
described in this referenced procedure.

• Identify the top-level input and output ports in your design that you plan to use for the SSN bus
and bus_clock. The bus should have the same number of input and output ports (for example, 16
inputs and 16 outputs).

• The "set_dft_specification_requirements -memory_test" switch in the reference testcase is set to

On even though this testcase has no memories in the top level. This requests that the memory
clocks at the boundary of the child blocks receive design rule checks (DRCs) all the way to the
top. Although the extract_icl process would detect any issues, you would need to redo the DFT
insertion to fix them. By performing the DRC before DFT, you can detect and correct those issues
sooner.

Prerequisites
• SSN requires that the top-level design has an IEEE 1149.1 interface available during logic test.

• The lower-level physical blocks should have SSN inserted prior to inserting SSN into the top-level
design. If the SSN is incomplete for any lower-level physical blocks, use the ijtag_greybox view to
model the SSN datapath through the physical block during top-level SSN insertion. Alternatively,
use an SSN multiplexer to force the SSN datapath around the incomplete physical block.

Procedure
Modify the auxiliary_input_ports and auxiliary_output_ports wrappers with the top-level ports you plan to
use for the SSN bus and bus_clock:

Tessent™ Shell User’s Manual 509

Streaming Scan Network (SSN)
First DFT Insertion Pass: Performing Top-Level MemoryBIST

# Add auxiliary mux on the inputs and outputs used for SSN bus and
# bus_clock
# bus_in {GPIO3_0 GPIO3_1} bus_out {GPIO4_0 GPIO4_1} bus_clock
{GPIO3_2}
read_config_data -in ${spec}/BoundaryScan -from_string {
AuxiliaryInputOutputPorts {
auxiliary_input_ports : GPIO3_0, GPIO3_1, GPIO3_2;
auxiliary_output_ports : GPIO4_0, GPIO4_1;
}
}

Examples
The following dofile is for the first DFT insertion pass. It contains changes to support SSN. These
changes appear in gold text.

# Set the context to insert DFT into top-level design

set_context dft -rtl -design_id rtl1

# Set the location of the TSDB. Default is the current working directory.
set_tsdb_output_directory ../tsdb_outdir

# Open the TSDB of all the child cores

open_tsdb ../../wrapped_cores/processor_core/tsdb_outdir
open_tsdb ../../wrapped_cores/gps_baseband/tsdb_outdir

# Read the tessent cell library

read_cell_library ../../library/standard_cells/tessent/adk.tcelllib

# Read the design

read_verilog ../rtl/noncore_blocks/pll.v -blackbox
set_design_sources -format verilog -v ../rtl/noncore_blocks/iopad_sel.v
read_verilog ../rtl/chip_top.v
read_verilog ../rtl/rds_process.v
set_current_design chip_top

set_design_level chip
# Define set_dft_specification_requirements to insert boundary scan at
# chip level
set_dft_specification_requirements -boundary_scan on -memory_Ttest on
# Specify the TAP pins using set_attribute_value
set_attribute_value TCK -name function -value tck
set_attribute_value TDI -name function -value tdi
set_attribute_value TMS -name function -value tms
set_attribute_value TRST -name function -value trst
set_attribute_value TDO -name function -value tdo
# Specify all clocks so that the proper BSCAN cells gets inserted
automatically for them

add_clocks PLL_1/pll_clock_0 -reference REF_CLK -freq_multiplier 16

add_clock REF_CLK -period 48ns
add_clock INCLK -period 10ns

510 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Second DFT Insertion Pass: Inserting Top-Level EDT, OCC, and SSN

check_design_rules
# Create and report a DFT Specification
set spec [create_dft_specification]

report_config_data $spec
# Segment the boundary scan to be used during logic test
set_config_value $spec/BoundaryScan/max_segment_length_for_logictest 80
# Add auxiliary mux on the inputs and outputs used for SSN bus and
# bus_clock
# bus_in {GPIO3_0 GPIO3_1} bus_out {GPIO4_0 GPIO4_1} bus_clock {GPIO3_2}
read_config_data -in ${spec}/BoundaryScan -from_string {
AuxiliaryInputOutputPorts {
auxiliary_input_ports : GPIO3_0, GPIO3_1, GPIO3_2;
auxiliary_output_ports : GPIO4_0, GPIO4_1 ;
}
}

report_config_data $spec
# Generate and insert the hardware
process_dft_specification -transcript_insertion_commands

# Extract IJTAG network and create ICL file for the design
extract_icl

# Create patterns(testbenches) to verify the inserted DFT logic

set spec [create_patterns_specification]
process_patterns_specification
# Point to the libraries and run simulation
set_simulation_library_sources -v ../../library/standard_cells/verilog/*.v \
-v ../rtl/noncore_blocks/pll.v \
-v ../rtl/noncore_blocks/iopad_sel.v \
-v ../../library/memories/SYNC_1RW_8Kx16.v

run_testbench_simulations

exit

Second DFT Insertion Pass: Inserting Top-Level EDT,

OCC, and SSN
In the second DFT insertion pass at the top level, you insert any EDT, OCC, and SSN elements that exist
at the top level. In addition, you use the DftSpecification to specify the physical order of lower-level cores
from the SSN bus_in to SSN bus_out.
Specify this physical order using the following elements. SSN nodes that appear at the top of the
DftSpecification are closest to SSN data_out.

• DesignInstance wrapper

• Any of the following SSN nodes along the datapath:

Tessent™ Shell User’s Manual 511

Streaming Scan Network (SSN)
Second DFT Insertion Pass: Inserting Top-Level EDT, OCC, and SSN

◦ Pipeline

◦ Receiver1xPipeline

◦ OutputPipeline

◦ Multiplexer

◦ BusFrequencyDivider

◦ BusFrequencyMultiplier
This section explains the slight modifications that you do to the standard flow when you insert the SSN,
EDT, and OCC at the top level. For a complete description of this step in the standard flow, refer to
“Second DFT Insertion Pass: Inserting Block-Level EDT and OCC” on page 224.
Reference Testcase Step
You can perform this step in the following directory of the Reference Testcase:

Notes About This Procedure

• Similar to the logic test insertion passes at the block level, the tool creates the SSN hardware
based on the SSN wrapper of the DftSpecification. For a description of the SSN wrapper, refer to
the "SSN" wrapper description in the Tessent Shell Reference Manual.

• When the tool creates the SSH, EDT, and OCC elements at the same time with a single
process_dft_specification command, the tool automates the connections between the SSH, EDT,
and OCC instances.

• You must complete an ICL-based verification step at the end of the second DFT insertion
pass in order to verify the DFT elements you just added to the IJTAG network. The
ICL-based patterns are created as part of running the create_patterns_specification
and process_patterns_specification commands, and you simulate them using the
run_testbench_simulations command. The following are the ICL-based pattern verifications:

◦ ICLNetwork Pattern — Verifies IJTAG access to all new DFT elements added to the IJTAG
network and to the child blocks.

◦ SSN Continuity Pattern — Verifies you have correctly integrated the SSN datapath into your
design and detects potential problems along the datapath. If your datapath includes SSN
multiplexers, you must configure the multiplexer select to test each leg of the multiplexer, as

512 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Second DFT Insertion Pass: Inserting Top-Level EDT, OCC, and SSN
demonstrated in step 5 and at the bottom of the 1.run_ssh_edt_occ_insertion script in the
directory of the reference testcase mentioned previously.

Note:
You can also create the SSN continuity pattern with the low-level
create_ssn_continuity_patterns command, as shown at the bottom of the example
dofile found at the end of this section.

• To use a third-party OCC with SSN, refer to the topic “Third-Party OCCs With SSN” on
page 667 in the "Tessent SSN Examples and Solutions" section.
To insert the logic test elements with SSN, use the following procedure to modify the dofile described in
“Second DFT Insertion Pass: Inserting Block-Level EDT and OCC” on page 224.

Prerequisites
• SSN requires that each physical block have a full OCC with a clock injection multiplexer and
support of the shift_only_mode feature.

• It is recommended that you have terminated the wrapper chains of the child blocks on a local
small EDT and that EDT is driven by the ScanHost node local to the block, as it was done in the
flow description found in the section “Second DFT Insertion Pass: Inserting Block-Level EDT,
OCC, and SSN” on page 488.

Procedure
1. Remove the add_dft_signals commands for the scan and retargeting signals edt_clock,
edt_update, shift_capture_clock, test_clock, retargeting1_mode, retargeting2_mode,
retargeting3_mode, and retargeting4_mode.
The scan signals (edt_clock, edt_update, shift_capture_clock, and test_clock) are not needed
because they are sourced by the SSH located in the top level. The scan signals to the lower-level
EDT and wrapper chain are sourced by the SSH inside the lower-level child core. When the lower-
level child cores are in external test mode, the internal mode EDT is inactive.
The retargeting signals (retargeting<n>_mode) are not needed because each core-level EDT is
accessible through the ScanHost node, effectively decoupling the dependency between core-level
EDT channels and top-level I/O. With SSN, you can retarget each core to the top level individually
or concurrently with any combination of the other cores.
To remove these commands, delete these lines:

add_dft_signals test_clock edt_update -source_nodes \

{TEST_CLOCK_top EDT_UPDATE_top}
add_dft_signals shift_capture_clock edt_clock \
-create_from_other_signals
add_dft_signals retargeting1_mode retargeting2_mode \
retargeting3_mode retargeting4_mode

2. Add the ssn_en DFT signal:

# DFT Signal used for logic test

add_dft_signals ltest_en ssn_en

Tessent™ Shell User’s Manual 513

Streaming Scan Network (SSN)
Second DFT Insertion Pass: Inserting Top-Level EDT, OCC, and SSN

3. Remove all of the add_dft_modal_connections commands that add multiplexer logic to support
scan pattern retargeting.

4. Add the SSN wrapper to the DftSpecification, as shown later in this step. The Datapath
connections point to the top-level ports that the previous step equipped with auxiliary input and
output logic during Boundary Scan. The tool automatically maps the specified port connections
to the corresponding auxiliary data pins and automatically connects the auxiliary en pins to the
ssn_en DFT signal.
A Multiplexer node wraps the two DesignInstance wrappers associated with the GPS instances.
You may need to create a similar setup in your design if the datapath through the those two cores
can be powered down. One way to avoid those multiplexers is to make sure the SSN datapath
remains in the always on domain. In this example, it is used to illustrate the way you create an
iProc to setup the datapath so that you can use it during SSN continuity and Scan retargeting.

read_config_data -in_wrapper $spec -from_string {

SSN {
ijtag_host_interface : Sib(ssn);
Datapath(1) {
output_bus_width : 2;
Connections {
bus_clock_in : GPIO3_2;
bus_data_in : GPIO3_%d;
bus_data_out : GPIO4_%d;
}
OutputPipeline(1) {
}
ScanHost(1) {
}
DesignInstance(PROCESSOR_1) {
}
Multiplexer(gps_byp) {
DesignInstance(GPS_2) {
}
DesignInstance(GPS_1) {
}
}
Receiver1xPipeline(1) {
}
}
}

5. Create the SSN continuity pattern to test the primary and secondary paths through the SSN
multiplexer.

a. Identify the different paths from SSN bus_in to bus_out through each leg of the SSN
multiplexers. In the example in substep 5.b, a single multiplexer is in the datapath. Some
complex datapaths may contain multiple SSN multiplexers.

b. Create an iProc to program the secondary datapath through the multiplexer. Reuse the iProc
during ATPG pattern generation to ensure that the datapath during ATPG has been checked.
Some complex datapaths may have multiple iProc procedures to program the different
multiplexer combinations.

514 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Second DFT Insertion Pass: Inserting Top-Level EDT, OCC, and SSN

#
# PDL for configuring top-level mux.
# When mux select=1'b1, gps_baseband physical blocks are included
#
iProcsForModule chip_top
iProc include_gps_blocks_in_ssn_datapath {} {
iCall chip_top_rtl2_tessent_ssn_mux_gps_byp_inst.setup \
select_secondary_bus 0b1
}

Figure 120. Multiplexer Node for Bypassing the gps_baseband Blocks

c. For each configuration of the multiplexers, use the ProcedureStep wrapper to create the
continuity pattern.

# Add path through gps_baseband physical blocks to continuity pattern.

read_config_data -last -in_wrapper $spec/Patterns(SSN) -from_string {
ProcedureStep(cfg_datapath) {
iCall(include_gps_blocks_in_ssn_datapath) {
}
}
SSNContinuityVerify(include_gps_baseband) {
}
}

6. Add the "‑create_ijtag_graybox on" switch to the extract_icl command. The ICL-based patterns
verification step also makes use of the IJTAG graybox views of the top and child levels to optimize
the simulations.

Examples
The following is a dofile for the second DFT pass.

# Set the context to insert DFT

set_context dft -rtl -design_id rtl2

# Use dft_cell_selection that is part of the library

read_cell_library ../../library/standard_cells/tessent/adk.tcelllib

# Set the location of the TSDB. Default is the current working directory.
set_tsdb_output_directory ../tsdb_outdir
# Open the TSDB of all the child cores
open_tsdb ../../wrapped_cores/processor_core/tsdb_outdir
open_tsdb ../../wrapped_cores/gps_baseband/tsdb_outdir

# Read the tessent cell library

Tessent™ Shell User’s Manual 515

Streaming Scan Network (SSN)
Second DFT Insertion Pass: Inserting Top-Level EDT, OCC, and SSN
read_cell_library ../../library/standard_cells/tessent/adk.tcelllib

# Read the verilog

read_verilog ../rtl/noncore_blocks/pll.v -blackbox
set_design_sources -format verilog -v ../rtl/noncore_blocks/iopad_sel.v

# Read the synthesized netlist

read_design chip_top -design_id rtl1 -verbose
read_design processor_core -design_id gate -view graybox -verbose
read_design gps_baseband -design_id gate -view graybox -verbose

set_current_design chip_top
# The design level is already specified in the first pass; no need to specify it
# again

# Add DFT Signals

# DFT Signal used for BoundaryScan to be used with logic test without
contacting inputs
add_dft_signals int_ltest_en output_pad_disable
# DFT Signals used for Scan Tested Network with Instruments like
# memorybist/boundary scan
add_dft_signals tck_occ_en
# DFT Signal used for logic test
add_dft_signals ltest_en
# DFT Signal used by top-level EDT
add_dft_signals edt_mode ssn_en
# Specify pre-DFT DRC rules
set_dft_specification_requirements -logic_test On

check_design_rules
report_dft_control_points
# Create and report a DFT Specification
set spec [create_dft_specification -sri_sib_list {occ edt ssn} ]
report_config_data $spec
# Use report_config_syntax DftSpecification/edt|occ to see full syntax
# The edt_clock and edt_update signals are automatically connected to EDT
instances
# The EDT controller is built with Bypass
# The shift_capture_clock is automatically connected to OCC instances
read_config_data -in_wrapper $spec -from_string {
SSN {
ijtag_host_interface : Sib(ssn);
DataPath(1) {
output_bus_width :2;
Connections {
bus_clock_in : GPIO3_2;
bus_data_in : GPIO3_%d;
bus_data_out : GPIO4_%d;
}
OutputPipeline(1) {
}
ScanHost(1) {
}
DesignInstance(PROCESSOR_1) {

516 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Second DFT Insertion Pass: Inserting Top-Level EDT, OCC, and SSN
}
Multiplexer(gps_byp) {
DesignInstance(GPS_2) {
}
DesignInstance(GPS_1) {
}
}
Receiver1xPipeline(1) {
}
}
}
Occ {
ijtag_host_interface : Sib(occ);
include_clocks_in_icl_model : yes;
Controller(pll_clock_0) {
clock_intercept_node : PLL_1/pll_clock_0;
}
Controller(INCLK) {
clock_intercept_node : INCLK;
}
}
EDT {
ijtag_host_interface : Sib(edt);
Controller (c1) {
longest_chain_range : 60, 100;
scan_chain_count : 17;
input_channel_count : 2;
output_channel_count : 2;
Connections {
EdtChannelsIn(1) {
}
EdtChannelsOut(1) {
}
}
}
}
}
# Generate and insert the hardware
process_dft_specification

# Note the effective data and clock rate comments above each SSN node in the
# following command
report_config_data $spec

# Extract IJTAG network and create ICL file for the design
extract_icl ‑create_ijtag_graybox on

# Creates a synthesis script of ALL the RTL (original and newly-created)

# to be used in your synthesis tool in next Step
write_design_import_script -use_relative_path_to . for_dc_synthesis.tcl -replace
# Generate patterns to verify the inserted DFT logic
set_defaults_value /PatternsSpecification/SignoffOptions/
simulate_instruments_in_lower_physical_instances on

Tessent™ Shell User’s Manual 517

Streaming Scan Network (SSN)
Second DFT Insertion Pass: Inserting Top-Level EDT, OCC, and SSN
# Generate patterns. Use the variable to update it if needed.
set spec [create_patterns_specification]
# chip level iProc to select secondary datapath through mux
source ../ssn_datapath_configuration.pdl
# Add path through gps_baseband physical blocks to continuity pattern.
read_config_data -last -in_wrapper $spec/Patterns(SSN) -from_string {
ProcedureStep(cfg_datapath) {
iCall(include_gps_blocks_in_ssn_datapath) {
}
}
SSNContinuityVerify(include_gps_baseband) {
}
}

# Validate pattern specification

process_patterns_specification
# Point to the libraries and run the simulation
set_simulation_library_sources -v ../../library/standard_cells/verilog/*.v \
-v ../rtl/noncore_blocks/pll.v \
-v ../rtl/noncore_blocks/iopad_sel.v \
-v ../../library/memories/SYNC_1RW_8Kx16.v

run_testbench_simulations -simulation_macro_definitions
TESSENT_DISABLE_CLOCK_MONITOR
check_testbench_simulations

exit

The following is an alternate way to create the SSN continuity pattern. Refer to Step 5 in the Procedure
section of this topic for an explanation of how to create the SSN continuity pattern.

#
# Create the continuity pattern
#

# Define SSN bus clock. If you are using time multiplexing

# you must specify the -freq_multiplier switch.
add_clocks GPIO3_2

# Check design rules and transition to analysis mode

check_design_rules
# set ijtag period
set_ijtag_retargeting_options -tck_period 10

# set ssn bus clock period.

set_load_unload_timing_options -usage ssn -ssn_bus_clock_period 5
# chip level iProc to select secondary datapath through mux
source ../ssn_datapath_configuration.pdl
# Create the SSN continuity pattern
open_pattern_set ssn_continuity -usage ssn
# This is the default datapath configuration
create_ssn_continuity_patterns
# Select secondary datapath side of MUX
iCall include_gps_blocks_in_ssn_datapath

518 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Synthesis for Top-Level Insertion
create_ssn_continuity_patterns
close_pattern_set
# Write simulation and STIL patterns
write_patterns patterns/ssn_continuity.v -verilog -replace -parameter_list \
{SIM_COMPARE_SUMMARY 1}
write_patterns patterns/ssn_continuity.stil -stil -replace

Synthesis for Top-Level Insertion

Use the following dofile changes to synthesize the DFT-inserted RTL at the top level.
You can perform this step in the following directory of the Reference Testcase:

In the dofile of the section “Second DFT Insertion Pass: Inserting Top-Level EDT, OCC, and SSN” on
page 511, you used the write_design_import_script command to export a design load script for use in
your synthesis tool.
Refer to the section “Synthesis Guidelines for RTL Designs With Tessent Inserted DFT” on page 989
for guidelines on how to perform the synthesis step. Also, refer to the section “Example Scripts Using
Tessent Tool-Generated SDC” on page 979 for example scripts specific to various synthesis tools.
When synthesis completes, it produces a file containing the concatenated netlist of the physical block you
just synthesized.

• If you performed scan insertion within the synthesis tool, continue with the steps described in the
section “Creating the Post-Synthesis TSDB View (Block-Level)” on page 495.

• If you are inserting your scan chains within Tessent, continue with the steps described in the
section “Performing Scan Chain Insertion With Tessent Scan (Block-Level)” on page 496.

Example
Example dofiles are available as the <module_name>.dc_synth_script files found in the testcase
directories shown in the "Referenced Testcase Step" section earlier in this topic. These files
specify the TCK period and the set_load_unload_timing_options values using a separate file called
<design_name>.timing_options. When you source this file at this point, it configures the SDC during
synthesis. A step later in the flow also sources this file from ATPG dofiles to configure the patterns with
the exact timing options that the tool used during timing closure.

Creating the Post-Synthesis TSDB View (Top-Level)

When you are using third-party scan insertion, use the following procedure to create the post-synthesis
TSDB, separate from scan insertion. Creation of the post-synthesis TSDB occurs automatically as part of
scan insertion when you use Tessent Scan.
Reference Testcase Step
You can perform this step in the following directory of the Reference Testcase:

Tessent™ Shell User’s Manual 519

Streaming Scan Network (SSN)
Performing Scan Chain Insertion With Tessent Scan (Top-Level)

Procedure
Creating the post-synthesis TSDB view at the top level is identical to the equivalent step at the block
level. The only difference is that you also need to open the TSDB to the child blocks. Refer to the
section “Creating the Post-Synthesis TSDB View (Block-Level)” on page 495 for the details. The
create_post_synthesis_tsdb_view script in the directory shown previously in the reference testcase also
illustrates this process.

Performing Scan Chain Insertion With Tessent Scan

(Top-Level)
The Tessent Scan insertion step in the SSN flow is similar to the scan chain insertion step in the Tessent
Shell Flow for hierarchical designs.
Reference Testcase Step
You can perform this step in the following directories of the Reference Testcase:

Procedure
When you are using SSN, the scan insertion step at the top level is very similar to the flow you use at
the block level. The only difference is that you do not need wrapper chains and, typically, have a single
scan mode. The boundary scan chains implemented in the section “First DFT Insertion Pass: Performing
Top-Level MemoryBIST” on page 509 were built so that the EDT controller can control them during
scan test, and they can serve as isolation from the outside. Those chains were preconnected to the EDT
ports and are left untouched during scan insertion. Refer to the section “Performing Scan Chain Insertion
With Tessent Scan (Block-Level)” on page 496 for more details. It may also be helpful to look at the
run_scan_insertion script in the directory shown previously in the reference testcase.

Verifying the ICL-Based Patterns After Synthesis

(Top-Level)
Resimulating the MemoryBIST and ICL verification patterns after synthesis ensures the ICL network is
fully functional and able to be reliably used during ATPG and Scan retargeting setup.
Reference Testcase Step
You can perform this step in the following directory of the Reference Testcase:

520 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Generating Top-Level ATPG Patterns

Procedure
The verification of the ICL-based patterns at the top level is identical to the procedure at the block level.
The only difference in the script is that you must open the TSDB for the child blocks. Refer to the section
“Verifying the ICL-Based Patterns After Synthesis (Block-Level)” on page 499 for the full details. It may
also be helpful to review the 1.create_post_synthesis_icl_verification_patterns script in the directory
shown previously in the reference testcase.

Generating Top-Level ATPG Patterns

The process for generating ATPG patterns in the SSN flow is similar to the process used without SSN.
Reference Testcase Step
You can perform this step in the following directories of the Reference Testcase:

Procedure
Generating the ATPG patterns at the top level is identical to generating the patterns at the block level. The
block levels are in external mode when you create top-level ATPG patterns, so you only need to read in
their scan graybox views using the "read_design ‑view scan_graybox" command.
You also need to import the .timing_options file used for all blocks so that you create the ATPG
patterns to satisfy the maximum frequencies within all the blocks. The 1.run_tk_chip_stuck and
2.run_tk_chip_transition scripts in the directory shown previously for the reference testcase illustrate the
loading of the timing options. Use the following Tcl code used to perform this import procedure:

# Import timing options used during synthesis

set tck_period 0
foreach {physical_block path} {
processor_core ../../wrapped_cores/processor_core/3.synthesize_rtl \
gps_baseband ../../wrapped_cores/gps_baseband/2.synthesize_rtl \
chip_top ../3.synthesize_rtl/} {

set_current_physical_block -module $physical_block

source ${path}/${physical_block}.timing_options
if {[set ${physical_block}_tck_period] > $tck_period} {
puts "Imported tck_period from $physical_block"
set tck_period [set ${physical_block}_tck_period]
}

# Define the tck period and ijtag retargeting options

set_ijtag_retargeting_options -tck_period $tck_period

Refer to the section “Generating Block-Level ATPG Patterns” on page 501 for more details about the
content of the dofile, or examine the 1.run_tk_chip_stuck and 2.run_tk_chip_transition scripts in the
directory shown previously for the reference testcase. The file 3.run_sims in same directory shows how

Tessent™ Shell User’s Manual 521

Streaming Scan Network (SSN)
Retargeting ATPG Patterns
to perform the simulation. It compiles the full view of the top level and the scan graybox view of the child
blocks.
Similar to the block-level process, the parallel load scan patterns are simulated first, followed by the serial
SSH loopback patterns and then the one Serial Chain and one Serial Scan patterns.

Retargeting ATPG Patterns

The steps you use to retarget the ATPG scan patterns from the block to the top level are very similar to
the steps used when not using SSN. When SSN is present, the process is easier and more flexible.
Reference Testcase Step
You can perform this step in the following directories of the Reference Testcase:

Notes About This Procedure

When you use SSN, the design does not have a scan_mode to set at the top level that configures
the channel access to the required blocks. Instead, you use the add_core_instances command to
specify which mode you want to retarget on a given set of block modules or instances. During the DFT
signoff process, you typically retarget one block at a time. You can speed up the simulation by using
the IJTAG graybox views of all blocks other than the one you are retargeting. This is the usage model
that the reference testcase demonstrates. The testcase retargets the stuck and transition patterns for
process_core into a set of testbenches independently from the stuck and transition patterns for the
gps_baseband block. The 3.run_retarget_processor_core_sims and 6.run_retarget_gps_baseband_sims
scripts in the reference testcase directory show how to compile the correct view for each simulation.
When you want to create the manufacturing patterns, you can retarget any number of blocks in
parallel. The flow is identical to the one in the dofile in the Examples section, except that you use the
add_core_instances command to specify all the blocks you want to include in the given retargeting
pattern set. The SSN procedure has the advantage that you do not hard code the grouping of blocks at
design time, so you can optimize them later, between power and test time.
The example dofile shows how you source the .timing_options files from each block again at this time to
ensure you create the SSN patterns consistently with how timing was closed within each block.

Procedure
1. Load the design in Tessent Shell.
Regardless of which blocks you are retargeting, you always load the IJTAG graybox view of
all blocks when doing scan retargeting with SSN. The three "read_design ‑view ijtag_graybox"
commands used in the example dofile illustrate how to do this.

2. Import the timing options files for all blocks.

As shown in the dofile in the Examples section and in the description of the previous step, the
tool automatically configures the SSN patterns to satisfy the requirements specified with the
set_load_unload_timing_options command. You use the same command to configure the Tessent
SSN SDC during timing closure. Specifying the command in a distinct file for each block enables
you to share the exact same specification during timing closure and pattern generation to ensure
they are always consistent.

3. Configure the SSN Multiplexer node to provide access to all active SSH blocks.

522 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Retargeting ATPG Patterns

The third section of highlighted code in the example dofile is commented out because the iCall it
contains configures the Multiplexer node when you want to include the gps_baseband. However,
this dofile only retargets the patterns for the processor_core block. As illustrated in Figure 120 on
page 515 in the section Second DFT Insertion Pass: Inserting Top-Level EDT, OCC, and SSN,
an inserted Multiplexer node enables you to bypass the gps_baseband blocks. When you want
to retarget the scan patterns of the gps_baseband block, you must configure the Multiplexer to
include them in the active SSN datapath.

Examples
The following dofile example illustrates how to perform scan retargeting with SSN.

# Set the Context to retarget ATPG Patterns from lower level child cores
set_context pattern -scan_retargeting

# Point to the TSDB directory

set_tsdb_output_directory ../tsdb_outdir

# Open all the TSDB of the child cores

open_tsdb ../../wrapped_cores/processor_core/tsdb_outdir
open_tsdb ../../wrapped_cores/gps_baseband/tsdb_outdir

# Read the tessent cell library

read_cell_library ../../library/standard_cells/tessent/adk.tcelllib

# Read the hard macros

read_verilog ../../library/plls/pll.v -interface_only
read_verilog ../../library/memories/SYNC_1RW_8Kx16.v -interface_only
#For scan retargeting with SSN, only the ijtag_graybox view is needed.
read_design chip_top -design_id gate -view ijtag_graybox
read_design processor_core -design_id gate -view ijtag_graybox
read_design gps_baseband -design_id gate -view ijtag_graybox

set_current_design chip_top

# Import timing options used during synthesis

set tck_period 0
foreach {physical_block path}
{processor_core ../../wrapped_cores/processor_core/3.synthesize_rtl \
gps_baseband
../../wrapped_cores/gps_baseband/2.synthesize_rtl \
chip_top ../3.synthesize_rtl/} {
set_current_physical_block -module $physical_block
source ${path}/${physical_block}.timing_options
if {[set ${physical_block}_tck_period] > $tck_period} {
puts "Imported tck_period from $physical_block"
set tck_period [set ${physical_block}_tck_period]
}
}
# Define the tck period and ijtag retargeting options
set_ijtag_retargeting_options -tck_period $tck_period

# Define the slow clock capture timing

set_capture_timing_options -mode_type internal \

Tessent™ Shell User’s Manual 523

Streaming Scan Network (SSN)
Retargeting ATPG Patterns
-capture_clock_period 40ns

# Retarget Stuck-at patterns from processor_core

set_current_mode retarget1_processor_stuck

add_core_instances -instances {PROCESSOR_1} -core processor_core -mode

int_edt_mode_stuck
import_clocks

# Configure SSN datapath to include all SSH

# This is not needed for the processor_core as it is always part of
# the active SSN datapath

# source ../ssn_datapath_configuration.pdl
# set_test_setup_icall include_gps_blocks_in_ssn_datapath -append

check_design_rules

# Write the TCD for the chip-level in the TSDB directory

write_tsdb_data -replace

# Read the patterns to be retargeted. The mode is specified with the

add_core_instances command.
read_patterns -module processor_core -fault_type stuck
# Write Verilog patterns for simulation
# Write parallel load testbench
write_patterns patterns/\
top_retarget_processor_core_stuck_parallel_scan.v \
-parallel -v -replace -parameter_list {SIM_COMPARE_SUMMARY 1} \
-pattern_sets scan

# ssh loopback pattern

write_patterns patterns/\
top_retarget_processor_core_stuck_ssh_loopback.v \
-serial -v -replace -parameter_list {SIM_COMPARE_SUMMARY 1} \
-pattern_sets ssh_loopback

# ssh on-chip comparator self test when OCComp mode present

# Not needed for Sign-off sims but critical as a manufacturing pattern
write_patterns patterns/top_retarget_gps_baseband_occomp_self_test.v \
-serial -v -replace -parameter_list {SIM_COMPARE_SUMMARY 1} \
-pattern_sets ssh_on_chip_compare

# Write a single chain and single scan test pattern

write_patterns patterns/top_retarget_processor_core_stuck_serial_chain.v\
-serial -v -replace -end 0 -parameter_list {SIM_COMPARE_SUMMARY 1} \
-pattern_sets chain
write_patterns patterns/top_retarget_processor_core_stuck_serial_scan.v \
-serial -v -replace -end 0 -parameter_list {SIM_COMPARE_SUMMARY 1} \
-pattern_sets scan

exit

524 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Performing Reverse Failure Mapping for SSN Pattern Diagnosis

Performing Reverse Failure Mapping for SSN Pattern

Diagnosis
SSN patterns include core-level patterns retargeted to the top level to create chip-level tester patterns. In
this way, they are similar to retargeted patterns for a hierarchical DFT design. Tessent Diagnosis requires
a core-level design flat model as an input. This means that, to diagnose failures, you must reverse-map
the tester-reported failures at the top level to their corresponding core level, which enables you to map the
reported transactions at the SSN bus level into transactions at the active SSH and EDT scan chain level.
This failure mapping process must include top-level ATPG. Tessent Diagnosis then uses the mapped
failure file, design flat model, and test pattern database (patdb) to perform the diagnosis.
The following figure shows a simplified Tessent Diagnosis flow as a two-step flow. In the first step, you
map tester-generated failures to core-level failures. Refer to the section "Reverse Mapping Top-Level
Failures to the Core" in the Tessent Diagnosis User’s Manual for more details. In the second step, you run
Tessent Diagnosis using the mapped failure files.

Note:
This procedure validates that reverse mapping failures back to the core level is working properly.
It does not validate diagnosis.

Figure 121. Simplified Tessent Diagnosis Two-Step Flow

Note:
When you write SSN patterns with the ‑max_loads option and exclude one of the pattern files from
being applied to the DUT on the tester, you should also exclude that file from the reverse failure
mapping process from reading that pattern file.

Tessent tools support a flow for validating the reverse failure mapping process that leads into the
diagnosis flow in the preceding figure by enabling the Verilog testbench to log simulation failure
information in a format similar to a tester fail file. To generate those failures, you must inject a fault on
a design primitive instance (sequential or combinational logic). The simplest way to do this is to force a
design node to a fixed value during the entire simulation, as illustrated in the testcase demonstration.
This demonstration injects a fault at one of the core scan cells during the event-driving simulation using
Questa Advanced Simulator or a third-party simulator. You use the fail file generated during pattern
Tessent™ Shell User’s Manual 525
Streaming Scan Network (SSN)
Performing Reverse Failure Mapping for SSN Pattern Diagnosis
testbench simulation to generate a core-level failure file; this does not change the diagnosis flow. Then
you use the failure file, design flat model, and pattern database to perform the diagnosis and generate the
list of suspects in an effort to find the root cause.
Reference Testcase Step
You can perform this step in the following directory of the Reference Testcase:

Notes About This Procedure

• While the diagnosis flow requires post-layout design flat models and patterns, the testcase uses
the post-synthesis flat model and patterns for the sole purpose of demonstrating the validation
flow.

• This validation flow uses the Verilog testbench for serial patterns. You cannot use the parallel
Verilog testbench.

• The Verilog testbench and STIL patterns should come from the same session, which means that
the number of patterns written for Verilog simulation must match the STIL patterns.

• The number of Verilog testbench patterns affects the simulation results during fault injection.
Choose a number that you can simulate in a reasonable amount of time while still being able to
detect the injected fault. This is typically ten patterns if you inject faults on the D input of a scan
flop.

• To demonstrate the flow, the testcase uses a Tessent-generated testbench of the serial scan
patterns to simulate and inject a fault at a given scan cell.

• Tessent uses the provided name as a prefix. This results in the following generated filename:

<command-provided_filename_> _ _<core_module_name>_ _<scan_test_mode>

Prerequisites
• When you create the serial scan testbench, you must set the parameter SIM_DIAG_FILE with a
value of two to create the fail file during the fault-injected simulation:
write_patterns <testbench_filename> -serial -parameter_list {SIM_DIAG_FILE 2}

• You have injected a fault at any design cell. Do this by directly forcing any cell instances pin in
the design to a constant value to emulate a fault. The testcase does this as part of the simulation
invocation, as shown at the end of this prerequisite. The testcase uses the following cells as a
fault location:

◦ gps_baseband core — sw_rst_reg/D

◦ processor_core core — watchdog_0.wdt_reset_reg/D

526 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Performing Reverse Failure Mapping for SSN Pattern Diagnosis

The following example uses the Questa Advanced Simulator force command to inject a fault on
the data input of a design sequential cell:

vsim -c -voptargs="+acc"
chip_top_top_retarget_processor_core_stuck_serial_scan_v_ctl -l
logfiles/verilog.log_top_retarget_processor_core_stuck_serial_scan \
-do " force
sim:/chip_top_top_retarget_processor_core_stuck_serial_scan_v_ctl/
chip_top_inst/PROCESSOR_1/PROCESSOR_1/watchdog_0/wdt_reset_reg/D 1 -f ; \
if {0} {log -r /*};run -all"

Procedure
1. Perform reverse failure mapping:

a. Set the context for failure mapping.

set_context patterns -failure_mapping

b. Read in the retargeted pattern TCD file.

read_core_descriptions <pattern_tcd_file>.tcd.gz

c. Read in the retargeted STIL pattern.

read_patterns <pattern_stil_file>

d. Read in the fail file generated during pattern fault injection and simulation.
read_failures <fail_file>

e. Write out the failure file.

write_failures <fail_file> -replace

2. Perform failure diagnosis:

a. Set the context for scan diagnosis.

set_context patterns ‑scan_diagnosis

b. Read in the core-level design flattened model.

read_flat_model <flat_model_path>

The ATPG process for the targeted pattern creates this model. Typically, this is a compressed
file with a .gz extension.

c. Read in the core-level pattern database.

read_patterns <pattern_database_path>.patdb

Tessent™ Shell User’s Manual 527

Streaming Scan Network (SSN)
Performing Reverse Failure Mapping for SSN Pattern Diagnosis

d. Run diagnosis on the failure file to produce a list of suspects.

diagnose_failures <failure_mapped_file>

Examples

Example 1
The following dofile is for the gps_baseband failure mapping. Find it in the run_script in the testcase
directories for this step.

# Set the Context to pattern

set_context pattern -failure_mapping

# read retargeted ATPG tcd file

read_core_descriptions ../tsdb_outdir/logic_test_cores/ \
chip_top_gate.logic_test_core/ \
chip_top.atpg_retargeting_mode_retarget1_gps_baseband_stuck/ \
chip_top_retarget1_gps_baseband_stuck.tcd.gz

# set the current design to the chip_top

set_current_design chip_top
set_system_mode analysis

# read the STIL pattern

read_patterns ../7.retarget_atpg_patterns/patterns/ \
top_retarget_gps_baseband_stuck_serial_scan.stil

# read the fail file generated by the testbench

read_failures ../7.retarget_atpg_patterns/patterns/ \
top_retarget_gps_baseband_stuck_serial_scan.v.fail

# write failure file for the diagnosis tool

write_failures
top_retarget_gps_baseband_stuck_serial_scan.failure_diagnosis -replace

Example 2
The following dofile is for the gps_baseband failure diagnosis. Find it in the run_script in the testcase
directories for this step.

# Set the Context to pattern

set_context pattern -scan_diagnosis

# read flat model file

read_flat_model ../../wrapped_cores/gps_baseband/tsdb_outdir/ \
logic_test_cores/gps_baseband_gate.logic_test_core/ \
gps_baseband.atpg_mode_int_edt_mode_stuck/ \
gps_baseband_int_edt_mode_stuck.flat.gz
read_patterns ../../wrapped_cores/gps_baseband/tsdb_outdir/ \
logic_test_cores/gps_baseband_gate.logic_test_core/ \
gps_baseband.atpg_mode_int_edt_mode_stuck/ \

528 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Performing Reverse Failure Mapping for SSN Pattern Diagnosis
gps_baseband_int_edt_mode_stuck_stuck.patdb

# Diagnose failures
diagnose_failures top_retarget_gps_baseband_stuck_serial_scan. \
failure_diagnosis_ _ _GPS_2_ _gps_baseband_ _int_edt_mode_stuck

Tessent™ Shell User’s Manual 529

Streaming Scan Network (SSN)
Rule Checks Before Writing SSN and ATPG Patterns

Rule Checks Before Writing SSN and ATPG

Patterns
The tool calculates the latency of an SSN bus based on the amount of pipelining present on the bus.
When you run the check_design_rules command, the tool maps the ICL model associated with the design
onto the netlist to verify consistency between the two. Some cases require additional pipelining to meet
timing after the physical design (PD) phase, especially in tiled designs with unanticipated long routing of
the bus. Changes in the floorplan can sever bus connections between two tiles or physical blocks. These
discontinuities can be addressed by adding feedthrough wires to the blocks.
You may not always be able to perform ICL extraction at the gate level. The following are some possible
reasons for this:

• Gate-level modules have been ungrouped during synthesis or the physical design process.

• The clock tree synthesis (CTS) process may replicate clock ports.

• There are additional inversions across module boundaries.

Adding additional pipelining, or any other form of latency, to the datapath creates an inconsistency
between the netlist and ICL module. This results either in failure to pass the DRCs due to violations, or
in simulation mismatches. Furthermore, some elements added after generating RTL but before the PD
phase may also impact the SSN behavior, such as a power isolation cell inserted on a datapath. Some
datapaths may be subject to gating. The pattern generation and retargeting processes cannot detect
improper path sensitization, leaving it to be detected while validating simulations instead.
The process of incremental datapath extraction implements a tracing algorithm that identifies all
sequential elements added after ICL extraction. When it finds an inconsistency between the ICL and
the netlist, it stores the total latency on the datapath in an ICL attribute in memory. It does not write out
or save the updated ICL model. The number of elements counted during tracing must be no fewer than
what is described in ICL. The tool supports any third-party element instantiated along the datapath. This
process does not require the ICL model; it automatically detects all elements along the bus
This tracing functionality also enables identification of other potential blockades on the datapath, such as
blackboxed modules. For more information about the DRCs that are part of the algorithm, refer to “The
Incremental Extraction Process” on page 531.
You must provide additional information for all pipelines that hold values for more than one cycle (that is,
that have a phase counter with a hold disable pin). In such cases, the tool relies on hold buffers that the
ICL must describe. If the information is not present, the tool excludes the nodes from the latency count.
For more information on how to ensure optimal datapath extraction, refer to “Limitations for Incremental
Extraction” on page 533.
If additional latency is present, the graybox view of the design becomes out of sync with the updated
netlist. To prevent problems related to an incomplete view, preserve all new elements in the new graybox
with the "analyze_graybox -preserve_instances" command. In addition to the analyze_graybox reference
page in the Tessent Shell Reference Manual, refer to the section “Feedthrough Path Handling” on
page 533.
The tool runs this tracing the first time you use the check_design_rules command and every time tool
commands change the datapath, such as in the following cases:

530 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
The Incremental Extraction Process

• When you return to setup mode to change active datapath nodes by using an iProc call or the
set_test_setup_icall command and you re-run design rule checking

• You invoke the write_patterns command after changing the datapath settings by running the
set_ssn_datapath_options command in analysis mode
This checking is turned off by default. Turn it on by running the "set_ssn_options
-incremental_datapath_extraction on" command in setup mode.
The following topics discuss incremental extraction and the rule checks SSN uses to validate the ICL in
cases where you must add elements to meet timing:

The Incremental Extraction Process

Feedthrough Path Handling
Limitations for Incremental Extraction

The Incremental Extraction Process

The incremental extraction process uses a tracing algorithm to identify all elements added after ICL
extraction at the RTL. When it finds an inconsistency between the ICL and the netlist, it tracks the number
of pipelines found on the datapath.
The algorithm traces between the first node and the input ports, along with all adjacent nodes for SSN
datapath elements, to the last node and POs unless the datapath is input-only. If the tool detects a
discrepancy in the latency, it notes it in an ICL attribute.
Turn on incremental extraction with the "set_ssn_options -incremental_datapath_extraction on" command
in setup mode.
When turned on, incremental extraction occurs once during system mode transition and any time you
use the write_patterns command after certain configuration changes. Any changes that result in a new
ssn_setup procedure or a new active datapath trigger incremental extraction, such as when you change
the multiplexer selector values (using set_test_setup_icall in the patterns -scan context or an explicit iCall
in the patterns -ijtag context) or change the bus width (with set_ssn_datapath_options).
The tracing process uses the tessent_ssn_datapath_pipeline_stages ICL attribute to record any
differences it detects in the latency between the traced design and the extracted ICL. Changing to
analysis mode clears any of these attributes that were previously set. The tool reports a warning if it finds
user-set attributes in analysis mode when this process is on. Modeling the pipeline stages in ICL is not
required; the extraction process handles this.
If the incremental extraction option is on, these attributes are set to read-only while the tool is in analysis
mode.
For ICL modules that are not available for tracing, such as black-boxed design modules, set the
tessent_ssn_datapath_not_verifiable_in_design attribute. If you do not set this attribute, the tool reports a
DRC error—either SSN_R25 or SSN_R26. The tool traces the datapath connection from the boundary of
the block and skips any internal connectivity.
The analysis process can report several DRC messages specific to incremental extraction. These include
the following:

• SSN_R24

• SSN_R25

Tessent™ Shell User’s Manual 531

Streaming Scan Network (SSN)
The Incremental Extraction Process

• SSN_R26

• SSN_R28

• SSN_R29

• SSN_R30

• SSN_R31

• SSN_R32

• SSN_R33

• SSN_R34

Tool Steps During Incremental Extraction

When incremental extraction is on, the tool does the following when you change to analysis mode or call
write_patterns:

1. For all active datapath pipelines that have a hold functionality (that is, a pipeline holds the value
for extra cycles), the tool asserts the persistent buffer that disables the hold functionality.

2. For all active datapath elements of the following types:

◦ ScanHost

◦ BusFrequencyMultiplier

◦ BusFrequencyDivider

◦ Fifo
the tool traces between all adjacent nodes and between the first node and the input ports.
It ignores connections with the tessent_ssn_datapath_not_verifiable_in_design attribute as
appropriate. For datapaths that are not input-only, it also traces between the last node and the
POs.
Tracing occurs through pipeline stages. It pulses them in a shift simulation context that includes
pulsing the ssn_bus_clock or clocks. In this context, all hold disable pins for phase counters are
set.
Pipeline extraction uses X-value tracing. Pipelines controlled by a phase counter require a
persistent buffer on a hold disable pin to propagate the X value. If the tool does not find a
persistent buffer, it reports a warning stating that it cannot trace the ICL instance and ignores it
during analysis.

3. The tool counts the latency between pairs of pins, compares the latency with the values in ICL,
and sets the tessent_ssn_datapath_pipeline_stages ICL attribute with the additional latency
amount for cases where the extracted latency is greater.

532 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Feedthrough Path Handling

4. The tool retains extracted pipeline stages only while it remains in analysis mode. When you
change from analysis mode to setup mode, the tool performs datapath extraction.
For this case, do not use black boxes for any instances the active datapath travels through. This
includes instances that do not have an active SSH. Instead, you should use the ijtag_graybox
view. This contains the elements of the datapath that the tool traces. You can also use the full
gate-level view of each instance; however, this is less efficient in terms of memory requirements
and tool run time.
The tool also reads the TCDs for any inactive SSHs to locate their persistent cells, so these files
are required. TCD files with support for incremental extraction have an incremented TCD version
(8).

Feedthrough Path Handling

Changes in the floorplan can sever the SSN bus connection between tiles or physical blocks. You can add
feedthrough wires to affected blocks to reconnect the bus.
Use the following guidelines for feedthrough paths:

• The sources and sinks of these paths must be ScanHost, BusFrequencyMultiplier,

BusFrequencyDivider, or Fifo nodes.

• Only pipeline stages are permitted on feedthrough paths.

If there are feedthrough paths with pipeline stages added during physical design, the tool does
not include them in the extracted tile-level ICL model. This is because they were not present
when the ICL model was extracted. These paths are not testable at the tile level.
Instead, you must manually preserve such feedthrough paths in the ijtag_graybox. Use the
"analyze_graybox -ijtag -preserve_instances" command.

• The tool traces and tests feedthrough paths with pipeline stages only when they are part of the
active SSN datapath selected during retargeting and ATPG. They are not required in the ICL
model.

Limitations for Incremental Extraction

The incremental extraction functionality has the limitations described in this section.

• The functionality requires a flat model of the design. The tool maps ICL pins to flat model gates
using persistent buffers or pin name translation. It reports an SSN_R24 violation if the mapping
process fails.

• The tool does not trace internal connectivity of DDR cells.

• The tracing skips pipelines controlled by a phase counter without a persistent buffer on a hold
disable pin. In this case, it reports the following warning:

Tessent™ Shell User’s Manual 533

Streaming Scan Network (SSN)
Limitations for Incremental Extraction

// Warning: The '<instance_name>' ICL instance cannot be traced

// because it contains a phase counter without a persistent buffer
// on the hold disable pin. This instance will be ignored during the
// SSN incremental datapath extraction analysis.

• You cannot move feedthrough pipelines added in RTL and extracted in ICL to a different design
hierarchy. We recommend adding feedthrough pipelines after ICL extraction.

• You cannot move pipelines to a different hierarchy after extracting them in ICL.

• The first and last state elements of a datapath must have the same strobe edge that the ICL
contains.

534 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Advanced Topics

Advanced Topics
The following topics provide additional information about working with SSN. This information can help you
use other features and modes with SSN, configure your design for optimal use with SSN, and understand
the underlying structures of SSN.

Streaming-Through-IJTAG Scan Data

On-Chip Compare With SSN
Types of Clock Networks To Use With SSN
Broadcast to Identical SSN Datapaths
Determine Failing Cores on ATE With SSN
Yield Statistics on ATE With SSN
Manufacturing Patterns With SSN
Signoff Patterns With SSN
SSN SDC Constraints in the Design Flow
Fast IO
Burn-In Pattern Support
LVX Support
Retention Testing With SSN
Size Resolution Technology With SSN

Streaming-Through-IJTAG Scan Data

The ScanHost node is designed to also enable streaming the SSN data through the IJTAG network
instead of through the SSN data bus. This feature is always available with no additional overhead
because the IJTAG network is already connected to each ScanHost node, and the ScanHost nodes can
be programmed to use a single-bit bus.
For details on enabling this mode during ATPG or scan pattern retargeting, refer to the "set_ssn_options
-streaming_interface" command in the Tessent Shell Reference Manual.
When activated, the ijtag_si data reaching the ScanHost node is injected on bit 0 of the input data
register, and bit 0 of the output data register is fed back to the ijtag_so pin, as the blue lines in the
following figure show. TCK is also injected from the ijtag_tck pin as the SSN bus clock within the
ScanHost node.

Tessent™ Shell User’s Manual 535

Streaming Scan Network (SSN)
Streaming-Through-IJTAG Scan Data

Figure 122. Streaming-Through-IJTAG Mode

Scan data delivery into the chip is significantly slower when using Streaming-Through-IJTAG than with the
SSN data bus. It is only one bit wide and limited to the maximum operating frequency of TCK. However,
the IJTAG network is very robust due to its two-edge timing and is always accessible in the system
through the IEEE 1149.1 JTAG TAP.
In silicon, if you find you have a timing problem in a section of the SSN datapath, the
Streaming‑Through‑IJTAG mode is available as an alternative method to deliver patterns to bring up
your initial parts. For this reason, the Streaming-Through-IJTAG mode is also referred to as a fail-safe
mechanism.
The Streaming‑Through‑IJTAG feature is also a more flexible replacement for LPCT-2. You are no longer
limited to being able to drive only a single EDT controller having a single channel pair when using the
IEEE 1149.1 protocol for delivering scan data.
If your IJTAG network architecture is an IJTAG streaming-compatible setup, in that it provides concurrent
access to all ScanHost nodes you want to access through IJTAG (as is possible when using SIBs), you
can test any number of blocks in parallel with an unlimited number of channels. This can be useful in a 3D
or 2.5D package if IEEE 1838 compliance is a requirement.
The IEEE 1838 standard mandates that you can perform the die interconnect test through the IEEE
1149.1 JTAG TAP, using only TCK as the scan and capture clock. To do this, create a scan mode within
each die that collects the wrapper cells interacting with the pins of the die, and create ATPG patterns
using this scan mode to target the interconnect faults. Apply these patterns through the normal SSN bus,
which is effectively the FFP mode of the IEEE 1838 standard. Alternatively, retarget those ATPG patterns
to apply through the IEEE 1149.1 TAP by using the Streaming‑Through‑IJTAG mode that comes with SSN,
and satisfy the IEEE 1838 requirements.
Consider the following while using Streaming‑Through‑IJTAG:

• All ScanHost nodes you want to include must be in the active IJTAG scan path.
Streaming‑Through‑IJTAG mode does not support IJTAG broadcast. Star network configurations
restrict the number of ScanHost nodes that can be active in parallel. The IJTAG solver within the
Tessent tool automatically opens up the IJTAG path if the network permits it.

536 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
On-Chip Compare With SSN

• The Streaming‑Through‑IJTAG mode supports both internal and external capture, and all fault
models are supported.

Tip
At the top level, make the boundary scan chains available to the top-level EDT
controller for best results. (Refer to the max_segment_length_for_logictest property
description in the DftSpecification/BoundaryScan wrapper reference page for more
details.) Add the int_ltest_en DFT signal at the top level and set it to 1 using the
set_static_dft_signal_values command during ATPG.
This enables full coverage of the chip logic without the need to drive the primary inputs and
observe the primary outputs during ATPG.

• You can run any number of ScanHost nodes concurrently in this mode as long as your IJTAG
network permits placing all the ScanHost nodes along the active IJTAG scan path.

• When a Streaming‑Through‑IJTAG session is complete, the binary states of all SIBs along the
active scan path are restored to their states that were present before streaming began. This
provides a predictable IJTAG network configuration between Streaming‑Through‑IJTAG sessions.
All scan testable instruments on the IJTAG network must be isolated from the following IJTAG interface
signals:

• ijtag_select

• ijtag_se

CAUTION:
If the state of these IJTAG interface signals is observable into scan cells, the enabling of the
IJTAG streaming feature may invalidate the patterns.

You can accomplish this isolation by gating the signals with the ltest_en DFT signal. All scan tested
instruments under the SIB STI are already isolated and do not require any hardware changes. Refer to
the figure "Sib(sti) With Scan Isolation Chain" in the "Sib" reference page for details about the way scan
tested instruments are isolated from the IJTAG network during scan test when you use the recommended
Sib structure that is automatically inferred within the create_dft_specification command.

On-Chip Compare With SSN

The on-chip compare feature enables the ScanHost node to compare expected data against the response
of the scan chains within the node itself.
The following subsections describe in more detail how to get the most effective use of the on-chip
compare feature and the self-test patterns used to test faults with it:

• Common Usage Scenarios — Scenarios that the on-chip compare feature is designed to
address.

• On-Chip Compare Mode Operation — The methods used by the on-chip compare feature and the
packet format when the feature is enabled.

Tessent™ Shell User’s Manual 537

Streaming Scan Network (SSN)
On-Chip Compare With SSN

• Costs, Benefits, and Recommendations — Trade-offs between DFT area and test time efficiency,
and recommendations for when the on-chip compare feature is most effective.

• On-Chip Compare Mode Setup — Instructions for building your ScanHost with the on-chip
compare feature and enabling the feature during ATPG and scan pattern retargeting.

• Diagnosis Using On-Chip Compare — Instructions for enabling detailed diagnostics when using
the on-chip compare feature.

Common Usage Scenarios

Comparing expected data to scan chain response in hardware within the ScanHost can be helpful in the
following scenarios:

• You have one or more physical blocks that are instantiated multiple times within the design. With
on-chip compare, the packet includes the chain input values and also the expected and mask
values. The packet values are not altered by the ScanHost node because the chain input values
are not replaced by the chain output values and thus can be reused by any number of instances
of that physical block. The section “Costs, Benefits, and Recommendations” on page 539
describes the number of instances of the physical block required for the on-chip compare feature
to become beneficial for test time and test data volume considerations.

• You want to quickly identify the failing cores on the ATE during manufacturing because you
have a Partial Good Die methodology that tolerates a subset of identical cores failing. In such
a case, the failing cores must be identified on the tester, and the test flow must take actions to
decommission them while testing the rest of the chip.
The on-chip compare mode provides a sticky status bit per ScanHost node that IJTAG scans
out at the end of the pattern set to directly identify the failing blocks. You can also scan
out a sticky status per channel output if you require. Refer to the "OnChipCompareMode/
sticky_status_resolution" property description in the ScanHost reference page in the Tessent
Shell Reference Manual for information about how to request usage of this feature. Refer to the
OnChipCompareMode/present property description in the same topic for information about the
special annotations added to the STIL file to quickly identify the comparisons that match the
sticky status bits.

On-Chip Compare Mode Operation

When you add the on-chip compare mode (OCComp mode) to the ScanHost node, it can still operate in
the normal mode, in which the input time slots of the packet corresponding to the channel input values
are replaced by the channel output values. The ATE compares the values at the end of the SSN data bus
when they come off the chip. The packet format in this normal mode of operation is illustrated in the figure
"SSN Packet Formats When Not Using On-Chip Compare" in the ScanHost reference page in the Tessent
Shell Reference Manual.
When you enable the on-chip compare mode of operation, the packet is modified to include the channel
input values followed by the expected values, the mask values, and the optional status values. When
the packet contains one or more status groups, the active ScanHost nodes force the status bits of their
assigned status group high in the first word of each scan load. These toggled bits help prevent false
passes resulting from incorrectly applied patterns or incorrect configuration. The packet format in on-chip
compare mode is illustrated in the figure "SSN Packet Formats When Using On-Chip Compare" in the
ScanHost reference page in the Tessent Shell Reference Manual. When building a ScanHost node with
support for on-chip compare, you should use as few output channels as possible to minimize the time slot
count used to carry the expected and mask data.

538 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
On-Chip Compare With SSN

For more details about the packet format in both modes, refer to the section "SSN Packet Formats" in the
ScanHost reference page.

Costs, Benefits, and Recommendations

The Common Usage Scenarios section explains why it is beneficial to include the on-chip compare
mode within your ScanHost node when you reuse the physical block that contains it multiple times in the
chip. Because the OCComp mode uses packet data time slots for the channel inputs, for the expected,
mask, and status values, and for the status time slot, it becomes more efficient than the normal mode of
operation when you have at least three identical instances of the physical block. With fewer instances,
the test time and data volume reduction are negligible and do not justify the area overhead needed to
implement the OCComp mode.
The typical area of a ScanHost node that does not support the OCComp mode is significantly smaller
than a typical EDT controller. When the ScanHost node supports the OCComp mode, its area becomes
comparable to a typical EDT controller. To minimize the area impact of OCComp on the ScanHost node,
you must minimize the number of output channels you use with the EDT. In this case, you typically use a
single output channel.
You can build the ScanHost node with the support of many status groups for diagnosis. Building support
for many status groups increases the area of the ScanHost node, and using many status groups
increases test time and data volumes. Refer to the section “Diagnosis Using On-Chip Compare” on
page 539 for more information when and how to use multiple status groups.

On-Chip Compare Mode Setup

To set up OCComp mode, you need to equip the ScanHost hardware node with the logic for it and then
enable the mode once the node is set up for it. The following subsections describe how to do this.
Equipping the ScanHost Hardware Node With On-Chip Compare Mode
The ScanHost node is not built with the on-chip compare mode by default. Building with OCComp
mode doubles the area of the controller. Enable the creation of the OCComp mode by inserting
the OnChipCompareMode wrapper within the ScanHost wrapper, typically when you have one
of the conditions described in the section “Common Usage Scenarios” on page 538. Use the
OnChipCompareMode/sticky_status_resolution property within the wrapper to specify whether you want
one sticky status per output channel or only a single one for the entire ScanHost node.
Enabling On-Chip Compare Mode During ATPG and Scan Pattern Retargeting
By default, using the write_patterns command in the patterns -scan or patterns -scan_retargeting
context does not enable OCComp mode. Manually enable OCComp mode by using the
"set_core_instance_parameters -parameter_values {on_chip_compare_enable on}" command. You can
either specify a group of ScanHost instances by using the -instances switch or use the -instrument_type
ssh switch to enable on-chip compare on all ScanHost nodes that support it.

Diagnosis Using On-Chip Compare

As described in the figure "SSN Packet Formats When Not Using On-Chip Compare" and its preceding
text in the ScanHost reference page in the Tessent Shell Reference Manual, you can program the
ScanHost node to report per-cycle pass/fail information into special Status time slots when using
the OCComp mode. You can choose to have no status time slots and rely purely on the Go/NoGo
sticky status bit scanned out with IJTAG at the end of the session. This sticky status provides failure
resolution down to the failing EDT output channel when you have specified OnChipCompareMode/
sticky_status_resolution as "output_chain", but it does not provide diagnostic resolution down to the failing
gate because there are no per-cycle compare statuses.
When several ScanHost nodes are programmed to use the same status time slots, which is the default
behavior, diagnosis may require reapplication of the pattern set to collect all the data needed to perform

Tessent™ Shell User’s Manual 539

Streaming Scan Network (SSN)
On-Chip Compare With SSN
detailed diagnostics of every failing core. Consider a case where all identical core instances are placed
into a single status group, such that their per-cycle pass/fail information aggregates into the same status
time slots. If any of those bits indicate failures, you have the cumulative per-pin, per-cycle fail data but
may not be able to determine which core or cores the failures came from. The sticky status bits unloaded
at the end of the pattern set through IJTAG indicate which cores failed at least once. If only one core in
this group failed, then you know the per-cycle pass/fail data came from this core alone; therefore, you
have all the information needed for diagnosis. However, if multiple cores fail, you must then separately
test and observe each failing core to get its individual fail data. If two cores fail, for example, then you
reapply the same test set twice, with patching applied to the disable_on_chip_compare_contribution bit
for all but one ScanHost node at a time. There is no need to store separate patterns for diagnosis on
the tester. Refer to the description of the disable_on_chip_compare_contribution bit in the table "IJTAG
Registers in ScanHost Nodes" in the ScanHost reference page in the Tessent Shell Reference Manual for
more information about the special iWriteVar annotation that identifies the location of such patchable bits.

Note:
If you disable contribution with the disable_on_chip_compare_contribution bit, the sticky status
bits for that SSH are not set. However, the status bits that are forced high to verify correct
ScanHost configuration are still forced in this situation.

If identical core instances are split into multiple groups, this slightly increases the test time, but decreases
the probability of resorting to multiple test applications for collecting diagnosis data. In the example shown
in the figure "SSN Packet Formats When Using On-Chip Compare" in the ScanHost reference page in the
Tessent Shell Reference Manual, the six cores are split into two groups. If you find cores A1 and A4 to
have failed, there is no need for test reapplication, because cores A1 through A3 accumulate their status
bits separately from cores A4 through A6. However, if cores A1 and A3 fail, you must reapply the tests
with patching to acquire the individual fail data. In an extreme case, you may choose to assign each core
instance to its own group to observe each core individually. This mode of operation may be better suited
for silicon debug than high-volume manufacturing.
To learn about the ATE failure log format, refer to the section "ATE Failure File Format Requirements" in
the Tessent Diagnosis User’s Manual. Performing on-chip compare requires special handling for scan
diagnosis in both test application and failure logging. For details, refer to the section Logging Failures for
SSN On-Chip Compare in the Tessent Diagnosis User’s Manual.
To learn about how to map the failures at the chip boundary to the core level and to enable performing
detailed diagnostics, refer to the section "Reverse Mapping Top-Level Failures to the Core" in the Tessent
Diagnosis User’s Manual. The failure mapping steps described in this section are required when using
SSN, even for top-level ATPG patterns. This is unlike when you are not using SSN, where they are only
required for retargeted scan patterns.

On-Chip Comparator Self-Test Patterns

As described in this section, you can equip the SSN ScanHost node with On-Chip compare logic. This
logic is described in the On-Chip Compare Logic figure in the ScanHost reference page. There are
several possible faults in the comparator logic that could prevent the detection of miscompares caused
by defects in the scanned circuit. Figure 123 identifies those faults. The opposite fault polarity would
result in systematic miscompares, and you can detect them with the normal On-Chip compare patterns.
The faults listed in this figure would result in faults within the scan circuitry that can go undetected. You
can generate a special pattern using the ScanHost loopback mode with expected values set opposite
to the scan-in values, to cause miscompares and enable you to observe the effects on the SSN bus
outputs. The logic shown in blue in the following figure exists only when you have specified the ScanHost/
OnChipCompareMode/sticky_status_resolution property as "output_chain".

540 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
On-Chip Compare With SSN

Figure 123. Faults in Comparator Logic That Could Mask Real Faults

Structure of the On-Chip Comparator Patterns

Generate the on-chip comparator self-test pattern set using the "write_patterns ‑pattern_sets
ssh_on_chip_compare" command in the patterns ‑scan or ‑scan_retargeting context. The tool performs
the on-chip comparator self-test pattern on all active SSHs in the current atpg or scan retargeting session.
Use the report_core_instances command to observe the active SSHs
The self-test pattern programs the ScanHost node with the following register values, so that each scan
load comprises exactly five packets.

edt_update_falling_launch_word 0
edt_update_falling_transition_words 0
extra_shift_packets 0
force_suppress_capture 1
loop_back_en 1
on_chip_compare_enable 1
on_chip_compare_group 1
on_chip_compare_group_count 1
scan_en_launch_packet 0
scan_en_transition_packets 0
total_shift_cnt_minus_one 1

With these settings, each scan load is exactly five packets long, and the packets have the
following labels: edt_update, shift0, shift1, post_shift0, and post_shift1. The values of the
from_scan_out_bits registers equal the number of output chains usable during on-chip compare for
each chain group; refer to the ScanHost reference page for more details in the description of the
output_chain_count_in_on_chip_compare_mode property. The values of the to_scan_in_bits registers
match the exact value of the from_scan_out_bits register for each chain group. This ensures that there
are exactly the same amount of scan-in values as there are comparators to test. The format of the five
packets is shown in the following output for an example ScanHost having 3 comparators. The green
values in the following output carry the scan payload in and out. The tool compares the i0, i1, and i2
values provided in the shift0 and shift1 packets against the e0, e1, and e2 values and masks them with
the m0, m1, and m2 values scanned in during the shift1 and post_shift0 packets. The tool scans out the
comparator statuses per output chain during the post_shift0 and post_shift1 packets.

Tessent™ Shell User’s Manual 541

Streaming Scan Network (SSN)
On-Chip Compare With SSN

packet_id scanin exp mask status

----------- -------- -------- -------- --------
edt_update i0 i1 i2 e0 e1 e2 m0 m1 m2 s0 s1 s2
shift0 i0 i1 i2 e0 e1 e2 m0 m1 m2 s0 s1 s2
shift1 i0 i1 i2 e0 e1 e2 m0 m1 m2 s0 s1 s2
post_shift0 i0 i1 i2 e0 e1 e2 m0 m1 m2 s0 s1 s2
post_shift1 i0 i1 i2 e0 e1 e2 m0 m1 m2 s0 s1 s2

The following list describes three control bits whose time slots are identified in gold in the preceding scan
load description.

• select_sticky_status — This control bit is scanned in during the i0 time slot of the edt_update
packet. When the value is "1", the select_sticky_status signal, shown in Figure 123 on
page 541, goes high at the end of the shift1 packet within the same scan load.
As that figure illustrates, the logic injects the sticky status results into the status time slots of
the post_shift0 and post_shift1 within the same scan load. It also injects the global sticky status
into the status time slots of the shift0 packet (shown in magenta in the preceding scan load
description) of the next scan load. As previously described, the select_sticky_status signal goes
up or down at the end of the shift1 packet, which explains why the global sticky status observed
in the shift0 packet happens in the next scan load.

• last_scan_load — This control bit scans in during the i0 time slot of the post_shift0 packet. It
indicates to the ScanHost that the current scan load is the last one and to stop performing any
comparisons in the next scan loads that may continue to flow through the datapath, which are to
complete the testing of other ScanHosts with more comparators to test.

• clear_sticky_status — This control bit is scanned in during the i0 time slot of the post_shift1
packet. When the value is "1", the clear_status signal, shown in Figure 123 on page 541,
goes high during the shift1 packet within the next scan load. As mentioned in the preceding
"select_sticky_status" section, the tool observes the global sticky status during the shift0 packet,
which is before the clear_sticky_status takes effect. Therefore, it observes the effect of the
clear_sticky_status in the next scan load, assuming no new miscompares were injected during
the post_shift0 and post_shift1 packet to cause the global sticky status to go up again after it was
cleared at the end of the shift1 packet.
The on-chip comparator self-test pattern set comprises six phases, described in the following sections.
Every compare in the pattern uses a unique label for identification, constructed as in the following:

<ssh_icl_instance>.<phase_id>.<packet_id>.scanin# for the scan in values

<ssh_icl_instance>.<phase_id>.<packet_id>.exp# for the expected values
<ssh_icl_instance>.<phase_id>.<packet_id>.mask# for the mask values
<ssh_icl_instance>.<phase_id>.<packet_id>.status# for the status values

The output patterns file such as STIL has one such bit_annotation for each output time slot to help quickly
identify the meaning of any miscompares. Refer to the section "Retargeted Symbolic Variables" in the
Tessent IJTAG User’s Manual for information about the bit annotations.
The following describes the six phases of the on-chip compare self-test, with the faults from Figure 123 on
page 541 that they each cover.
Phase 1
This phase consists of a single scan load formed with one set of the five packets shown previously.
This scan load uses consistent scanin and expected values for both shift cycles so that it generates no
miscompares and the sticky statuses get initialized to 0. The phase_id is "phase1".

542 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
On-Chip Compare With SSN

i0 i1 i2 e0 e1 e2 m0 m1 m2 s0 s1 s2
edt_update: 0 0 0 0 0 0 0 0 0 L L L
shift0: 1 1 1 0 0 0 0 0 0 L L L
shift1: 0 0 0 1 1 1 0 0 0 L L L
post_shift0 0 0 0 0 0 0 0 0 0 L L L
post_shift1 0 0 0 0 0 0 0 0 0 L L L

Phase 2
This phase consists of N scan loads used to test that the N XOR gates in Figure 123 on page 541 are
not stuck at 0 when the scanin value is 0 and the expected value is 1. The phase_id is "phase2_X"" when
testing the Xth comparator. The following is the scan load used to test comparator 0.

i0 i1 i2 e0 e1 e2 m0 m1 m2 s0 s1 s2
edt_update: 0 0 0 0 0 0 0 0 0 L L L
shift0: 0 0 0 0 0 0 0 0 0 L L L
shift1: 0 0 0 1 0 0 0 0 0 L L L
post_shift0 0 0 0 0 0 0 0 0 0 H L L
post_shift1 0 0 0 0 0 0 0 0 0 L L L

Phase 3
This phase consists of N scan loads used to test that the N XOR gates in Figure 123 on page 541 are
not stuck at 0 when the scanin value is 1 and the expected value is 0. The phase_id is "phase3_X" when
testing the Xth comparator. The following is the scan load used to test comparator 0.

i0 i1 i2 e0 e1 e2 m0 m1 m2 s0 s1 s2
edt_update: 0 0 0 0 0 0 0 0 0 L L L
shift0: 1 0 0 0 0 0 0 0 0 L L L
shift1: 0 0 0 0 0 0 0 0 0 L L L
post_shift0 0 0 0 0 0 0 0 0 0 H L L
post_shift1 0 0 0 0 0 0 0 0 0 L L L

Phase 4
This phase consists of two scan loads. It tests that the sticky statuses are able to hold. As shown
in Figure 123 on page 541, there is a global sticky status and optional sticky statuses per output
chain. The ScanHost/OnChipCompareMode/sticky_status_resolution property controls the presence
of the sticky statuses per output chains. The phase_id for those two scan loads are "phase4_0" and
"phase4_1".
The effect of the select_sticky_status control bit takes effect at the end of the shift1 packet within the
same scan load. The effect of the clear_sticky_status happens at the end of the shift1 packet within the
next scan load.
When only the global sticky status is present, the pattern looks like the following diagram. The
select_sticky_status takes effect at the end of the shift1 packet. The red H in the second scan load
corresponds to the global sticky status being observed during the last status time slot of the shift0 packet.
The global sticky status remembers the faults injected during Phase2 and Phase3 and clears at the end
of the shift1 packet of the second scan load.

i0 i1 i2 e0 e1 e2 m0 m1 m2 s0 s1 s2
edt_update: 1 0 0 0 0 0 0 0 0 L L L // select_sticky_status
shift0: 1 1 1 0 0 0 0 0 0 L L L
shift1: 0 0 0 1 1 1 0 0 0 L L L

Tessent™ Shell User’s Manual 543

Streaming Scan Network (SSN)
On-Chip Compare With SSN
post_shift0 0 0 0 0 0 0 0 0 0 L L L
post_shift1 1 0 0 0 0 0 0 0 0 L L L // clear_sticky_status
i0 i1 i2 e0 e1 e2 m0 m1 m2 s0 s1 s2
edt_update: 1 0 0 0 0 0 0 0 0 L L L // select_sticky_status
shift0: 1 1 1 0 0 0 0 0 0 X X H
shift1: 0 0 0 1 1 1 0 0 0 L L L // status cleared here
post_shift0 0 0 0 0 0 0 0 0 0 L L L
post_shift1 0 0 0 0 0 0 0 0 0 L L L

When the sticky statuses per output chain are present, the pattern looks like the following diagram.
The global sticky status observation is identical to what was described previously. However, because
the sticky statuses per output chain are present, the tool observes them during the first scan load. The
clear_sticky_status control requested during the first scan load takes effect after the shift1 packet of the
next scan load, which explains why the status values return to being L during the second scan load.

i0 i1 i2 e0 e1 e2 m0 m1 m2 s0 s1 s2
edt_update: 1 0 0 0 0 0 0 0 0 L L L // select_sticky_status
shift0: 1 1 1 0 0 0 0 0 0 L L L
shift1: 0 0 0 1 1 1 0 0 0 L L L
post_shift0 0 0 0 0 0 0 0 0 0 H H H
post_shift1 1 0 0 0 0 0 0 0 0 H H H // clear_sticky_status
i0 i1 i2 e0 e1 e2 m0 m1 m2 s0 s1 s2
edt_update: 1 0 0 0 0 0 0 0 0 L L L
shift0: 1 1 1 0 0 0 0 0 0 X X H // global sticky status
shift1: 0 0 0 1 1 1 0 0 0 L L L // status cleared here
post_shift0 0 0 0 0 0 0 0 0 0 L L L
post_shift1 0 0 0 0 0 0 0 0 0 L L L

Phase 5
This phase consists of N scan loads. It tests that all inputs of the wide OR gate feeding the global sticky
status register are not stuck at 0. The tool generates faults for each comparator in its respective scan load
by setting the shift0 value to 0 and expecting a H. It observes the global sticky status in the last status bit
of the Shift0 packet of the next scan load. The phase_id for those two scan loads is "phase5_x".
The following diagram shows the first two scan loads with the sticky status per chain output feature
enabled. The failure appears during the post_shift1 packet, even though the tool detected the fault in the
post_shift0 packet because of the presence of the blue flip-flops in Figure 123 on page 541:

i0 i1 i2 e0 e1 e2 m0 m1 m2 s0 s1 s2
edt_update: 1 0 0 0 0 0 0 0 0 L L L // select_sticky_status
shift0 0 1 1 0 0 0 0 0 0 L L L // global sticky status
shift1 0 0 0 1 1 1 0 0 0 L L L
post_shift0 0 0 0 0 0 0 0 0 0 L L L
post_shift1 1 0 0 0 0 0 0 0 0 H L L // clear_sticky_status

edt_update: 1 0 0 0 0 0 0 0 0 L L L // select_sticky_status
shift0 1 0 1 0 0 0 0 0 0 X X H // global sticky status
shift1 0 0 0 1 1 1 0 0 0 L L L
post_shift0 0 0 0 0 0 0 0 0 0 L L L
post_shift1 1 0 0 0 0 0 0 0 0 L H L // clear_sticky_status

The following diagram shows the first two scan loads with the sticky status per chain output feature turned
off. The failure appears during the post_shift0 packet because of the absence of the blue flip-flops in
Figure 123:

544 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Types of Clock Networks To Use With SSN

i0 i1 i2 e0 e1 e2 m0 m1 m2 s0 s1 s2
edt_update: 1 0 0 0 0 0 0 0 0 L L L // select_sticky_status
shift0 0 1 1 0 0 0 0 0 0 L L L // global sticky status
shift1 0 0 0 1 1 1 0 0 0 L L L
post_shift0 0 0 0 0 0 0 0 0 0 H L L
post_shift1 1 0 0 0 0 0 0 0 0 L L L // clear_sticky_status

edt_update: 1 0 0 0 0 0 0 0 0 L L L // select_sticky_status
shift0 1 0 1 0 0 0 0 0 0 X X H // global sticky status
shift1 0 0 0 1 1 1 0 0 0 L L L
post_shift0 0 0 0 0 0 0 0 0 0 L H L
post_shift1 1 0 0 0 0 0 0 0 0 L L L // clear_sticky_status

Phase 6
This phase consists of one scan load. It observes the last global sticky status result associated to the last
comparator that was triggered during the last scan load of Phase 5. During this phase, the tool also fault-
injects all comparators to set all sticky statuses per comparator and observes them with an IJTAG scan
load as a last step when the feature is present. The phase_id for this scan load is "phase6".

i0 i1 i2 e0 e1 e2 m0 m1 m2 s0 s1 s2
edt_update: 0 0 0 0 0 0 0 0 0 L L L
shift0 0 0 0 0 0 0 0 0 0 X X H
shift1 0 0 0 1 1 1 0 0 0 L L L
post_shift0 1 0 0 0 0 0 0 0 0 H H H // last scan load
post_shift1 0 0 0 0 0 0 0 0 0 L L L

Types of Clock Networks To Use With SSN

The configuration of the clock network you use with SSN depends on the logic in your design. Frequency
multipliers and dividers, along with other nodes, can help you optimize your clock network and avoid large
a cumulative delay value.
The streaming scan network is a synchronous bus going from a set of inputs through several stages of
pipelining across many physical regions until it comes back out on a set of outputs. The pipeline stages
occur within the various node types along the datapath.
The SSN DftSpecification offers several node types to help with crossing clock domain boundaries.
The following sections explain various ways in which you can implement clock trees to best meet your
requirements.

Note:
For more information about clock tree synthesis (CTS) and implementing stop points for CTS,
refer to the section “CTS Exceptions for the SSH” on page 614.

Hierarchical Clock Tree

The most common and straightforward clock scheme is to build a hierarchical clock tree for the entire
SSN datapath or for the SSN datapath within groups of physical blocks. Implementation of one or more
hierarchical clock trees requires space in the upper physical regions to place the clock buffers around
the child physical blocks. You may not want to or be able to build a hierarchical clock tree that is common

Tessent™ Shell User’s Manual 545

Streaming Scan Network (SSN)
Types of Clock Networks To Use With SSN
for all child physical blocks. Instead, you can create more than one smaller Clock Tree Synthesis (CTS)
regions. If you do this, you must use a pair of BusFrequencyDivider and BusFrequencyMultiplier nodes to
reliably transfer the data from one clock domain to the next.

• To understand how to insert the clock domain transfer node within the top physical regions, refer
to Example 1 of the BusFrequencyDivider topic.

• To understand how to insert the clock domain transfer node such that the source and
destination clock domains remains localized to each physical block, refer to Example 2 of the
BusFrequencyDivider topic.

• To understand how to insert the clock domain transfer node inside the receiving physical block
to keep the number of pins crossing the physical block boundary to a minimum, refer to Example
3 of the BusFrequencyDivider topic. When you do this, you need an extra miniature clock tree
within the receiving physical block for the BusFrequencyDivider node and must use a source
synchronous timing interface between the sourcing and receiving physical block. Refer to the next
section for an explanation of such timing interfaces.
Refer to the Using the BusFrequencyDivider to Cross CTS Regions section of the BusFrequencyDivider
topic in the Tessent Shell Reference Manual for an explanation on how the BusFrequencyDivider and
BusFrequencyMultiplier nodes work together to provide an arbitrarily large tolerance of skew between the
transmitting and receiving clock domains by increasing the frequency_ratio value.

Source Synchronous Timing Interface

A source synchronous timing interface, also called a forward timing interface, relies on the fact that the
clock follows the data. The physical block sourcing the data to the receiving node also sources the clock
input at the same time. The delay of the datapath closely matches the delay of the clock path. The data
is launched on one edge of the clock at the source and is captured on the opposite clock edge at the
destination. As long as the delay on the datapath matches the delay of the clock path within half a clock
period, the transfer of data is synchronous and reliable.
Example 3 of the BusFrequencyDivider topic uses this technique. The transmitting physical block
ends with a Pipeline node, which launches the data on the positive edge of the clock. The receiving
BusFrequencyDivider is built with the input_retimed property set to "on" so that it is equipped with a
negative edge retiming flip-flop stage on its input data bus. The retiming stage ensures that the receiving
node strobes the data on the opposite edge of the clock relative to the launch edge of the transmitter.
The forward timing technique is used in Example 3 of the BusFrequencyDivider topic to hand off data
from one physical block to the next without requiring the balance clock tree of one block to enter the other.
It also uses the narrow data bus when crossing the physical block boundaries. It is important to use this
technique combined with a BusFrequencyDivider and BusFrequencyMultiplier node pair so that you can
return to using a hierarchical clock tree for the other section of the datapath. Although it is possible to use
a source synchronous interface between each physical block, due to its easy implementation, this is not
a recommended practice in a large design, because this would accumulate a CTS insertion delay in each
physical block. The data output of the last physical block would become so delayed relative to the clock
input coming from the tester that it would be impossible to reliably sample the output data on the ATE and
find a strobe point that would work for best- and worst-case conditions.
The following sections explain how to use forward design timing between each node when the datapath
goes and comes back between each pair of physical blocks.

Combining Forward and Loop Timing for Tiling Layout Flows

When you are implementing a pure tiling layout flow, you do not have any logic between the blocks.
Everything is self-contained within the child physical blocks, which simply abut each other. In such
a case, it is not possible to use a hierarchical clock tree to synchronize a clock to all child physical
blocks. Instead, each block provides the clock to the next. As the clock goes through several blocks, it

546 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Types of Clock Networks To Use With SSN
accumulates a large delay because of the clock delay in each block. By the time the clock reaches the
Nth block, the delay is so large that it is no longer possible to reliably strobe the data on the tester. To
avoid accumulating delay in a tiling configuration, you must implement the datapath through your physical
block so that it goes and comes back through the block as shown in Example 3 of the SSN topic. Use a
forward timing interface to go from one physical block to the next and a loop timing interface to get the
returned data back from the next block. Both the input and the output data are localized in the first block,
so it is easy to synchronize with the tester. Refer to the next section to understand how to minimize the
loop timing between the chip and the tester to increase the SSN shift rate.
Figure 124 shows a block diagram of a chip where the SSN datapath starts from the center top of the
device and makes a loop going down the middle of the chip. The datapath also branches out to both
sides in mirrored groups of physical blocks called "Corea". The GPIO are all localized in the top center
block, including the clock input. The timing with the tester is completely localized into that physical block
and is predictable before you complete the full chip layout. As Example 3 of the SSN topic illustrates, the
timing of the datapath is localized between each pair of blocks and not affected by distant elements. In
the example, there are three instances of corea on top of each other. These correspond to three Corea
instances in following figure, where the bottom corea instance from the example is the Corea instance
closest to the center in the figure.

Figure 124. SSN Datapath in Tiling Architecture

Minimizing Loop Delay With the Tester

When a tester interacts with the SSN datapath of a chip, the critical timing path is always the loop timing
path that starts from the clock supplied by the tester and continues to the data coming back from the chip.
To be able to shift the SSN bus at 200 MHz, the worst case delay of the clock coming into the chip and
reaching the last stage of the pipelining, with the data coming out of the chip, must be less than 4 ns. As
described in the Using the BusFrequencyDivider to Enable Faster Internal Bus Clock Frequency section
of the BusFrequencyDivider topic in the Tessent Shell Reference Manual, when the delay is 4 ns in the
worst case, it is about 1.5 ns in the best case. This leaves very little opening in which to place a strobe
point on the ATE that is reliable in both best- and worst-case conditions. To minimize the internal bus
width, it is easy to operate the SSN bus at 400 MHz, but you need to use a BusFrequencyDivider node
to bring the external data rate to 200 MHz so that the loop timing delay is less than a clock period. If you
used a hierarchical clock tree, a large portion of the loop timing would be consumed in the clock tree

Tessent™ Shell User’s Manual 547

Streaming Scan Network (SSN)
Broadcast to Identical SSN Datapaths
delay itself. Figure 125 shows how to use an OutputPipeline node placed on a miniature local clock tree
to retime the data before it goes out the chip. This eliminates the large CTS delay in the loop timing.

Figure 125. Stepping Down the Clock Tree on the Last Pipeline Stage

Broadcast to Identical SSN Datapaths

When multiple identical SSN datapaths exist, it is beneficial to reuse the same copy of scan data going to
each datapath. When you broadcast scan data to identical datapaths, you must set up observation for the
outputs of each identical datapath independently.
You can use input broadcast for test when the physical implementation of the datapaths would benefit
from broadcasting to their inputs from the same source. When you use a copy of the same data across
multiple identical datapaths, this reduces scan data volume, because the same copy of input data tests
the datapaths. Furthermore, testing identical datapaths concurrently can reduce test time.
However, not all designs with multiple datapaths benefit from input broadcast. For example, multi-die
designs with nonidentical datapaths do not benefit from broadcasting their inputs from the same source,
because nonidentical die do not use the same scan payload. Instead, each datapath requires its own
payload. Similarly, designs with mux access to their datapaths would not benefit from input broadcast,
because the mux access to the different die requires serial testing.
"Identical" refers to both the physical specifications of the datapaths and the configuration of the
datapaths. For example, if one instance has on-chip compare enabled and a second otherwise identical
instance has on-chip compare disabled, these instances are not eligible for input broadcast. The
datapaths must be physically identical and their SSHs must be configured identically. The only exception
to this is that you can include extra pipelining or a disabled SSH (which acts like pipeline stages) after the
last active SSH.
Even when broadcasting to identical datapaths, top-level ATPG can still be run. This means that
broadcast to SSN datapaths has a broader use than retargeting. In this case, the lower-level instances
must load the same scan data, whether performing retargeting or top-level ATPG.

548 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Determine Failing Cores on ATE With SSN

Independent observation of datapaths is required both during loading and unloading of the datapath.

Determine Failing Cores on ATE With SSN

Test engineers can make binning decisions on ATE, based on which core instances pass or fail. Core
instance binning is useful in salvaging die with a failing core or two to sell as a reduced-functional version
of the design. Core instance binning is also valuable for yield analytics, which enables product engineers
to determine which cores are more sensitive to defects.
Hierarchical scan methodologies typically connect the EDT outputs of core instances directly to pins for
particular retargeting modes. This methodology simplifies binning on an ATE because of the one-to-one
relationship between a failing pin and a failing core instance. SSN adds a layer of complexity because
packetized outputs of the cores-under-test can occur on any output of the SSN bus. Binning on an ATE
requires mapping a core instance to a pin and cycle combination.

SSN and On-Chip Compare

It is straightforward to determine the failing core instance when the cores use the on-chip compare
function of SSN. For these cores, the sticky_status bit in the SSH captures the pass/fail status of the core
instance. Read this bit through the IJTAG network to observe the TDO pin.
Find the Failing SSH Instance
During a retargeting mode using retargeted patterns, the test reads the sticky status bit for each on-chip
compare instance during the SSN_end portion of the test. The tool annotates the vectors in the retargeted
pattern file corresponding to each sticky_status bit. The annotation indicates the SSH instance associated
with the sticky status bit.
The following figure shows an example sticky_status bit annotation. Identify the vector annotation by
searching for "sticky_status" at the end of the register name. The first portion of the register name ending
with "_inst" is the SSH instance name.

Figure 126. Example sticky_status Bit Annotation

Find the Core Instance

To determine the core instance, use another set of annotations in the pattern file. Each core instance in
the retargeting mode has an associated annotation section indicating which SSH instances are in each
core instance. The following figure shows an example:

Figure 127. Example Core Instance Annotations

Normally there is one SSH instance per core instance, but there can be more than one SSH per core as
shown in the figure. Every SSH instance has its own packet location on the SSN bus.

Tessent™ Shell User’s Manual 549

Streaming Scan Network (SSN)
Determine Failing Cores on ATE With SSN

SSN Without On-Chip Compare

For core instances that do not use on-chip compare, there is no sticky_status bit to indicate which one is
failing. Instead, their failures can be observable on any pin of the SSN bus because they are interwoven
with the outputs of all cores in the retargeting mode. Further complicating matters, bandwidth tuning
allocates more data to the cores with larger patterns so that all cores finish simultaneously to minimize
wasted time. This packet rotation forms a repetitive cycle enabling a simple modulus calculation based on
the cycle number and the number of cycles in each repetition.
The following figure illustrates this rotation for an example SSN bus with five pins for core instances a and
b. Core "a" has two bits per scan word: a1 and a2. Core "b" has five bits per scan word: b1 through b5.
These bit locations repeat every seven cycles.

Figure 128. SSN Packet Rotation Cycles

The following figure summarizes the information using a table for each pin on the SSN bus. Each table
also indicates the modulus and core instance relationships:

Figure 129. Pin Tables With Modulus and Core Instance Relationships

These pin tables associate each failing pin and cycle combination with a particular core instance based
on the following modulus calculation:
Modulus = Cycle % Cycle Repetition
The cycle repetition is seven, which was first established in Figure 128. If there is a failure in cycle 15 on
Pin1, the equation 15 % 7 calculates that the modulus is 1. Using the Pin 1 look-up table in Figure 129,
modulus 1 reveals that the failure came from core instance "b". The following figure has a summary:

550 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Yield Statistics on ATE With SSN

Figure 130. Determine Failing Core Instance With Modulus and Pin Tables

There are annotations in the pattern file to provide the necessary information to calculate modulus and
setup pin tables. The following figure shows an example of these annotations, which are located in the
"ssn_mapping" section:

Figure 131. Example Modulus and Pin Table Annotations

The final piece of information that you need is the cycle where the rotation begins. The vector in the
retargeted pattern file that has the following annotation is the cycle where the rotation begins:

Figure 132. Annotation Where the Cycle Rotation Begins

Yield Statistics on ATE With SSN

You may use per-pin fail limits to prevent a single core from filling up the fail buffer on the tester during
manufacturing. You may also perform partial good die testing and need to identify failing cores live on
the tester without performing full failure diagnosis. In these cases, you can create SSN patterns with
packet constraints to enable both partial good die testing and yield statistics tabulation for failing cores

Tessent™ Shell User’s Manual 551

Streaming Scan Network (SSN)
Yield Statistics on ATE With SSN
while using per-pin fail limits. This feature is useful in cases where the pass-fail sticky bit is unavailable for
indicating the presence of a failure.

Note:
By default, the pattern includes annotations that specify the mapping from the top-level ports to
the SSH, regardless of whether packet rotation is on or off. You can control these annotations with
the set_ssn_options ‑ssh_mapping_annotations command.
If a ScanHost node has multiple status groups for on-chip compare (as defined by the
OnChipCompareMode/status_groups property) and throttling is enabled, the resulting pattern
does not include mapping annotations for that node. In this case, the tool reports a warning
instructing you to disable throttling if you want the pattern file to include annotations.

Note:
Creating SSN patterns with packet constraints is useful for testing non-identical cores for which
the SSH is not implemented with the on-chip compare feature.

Use the "set_ssn_options ‑packet_constraints no_rotation" command to stop rotation of the packet around
the SSN bus, as shown in Figure 133. In this figure, the packet is nine bits wide and contains five bits
of Core A and four bis of Core B. The SSN bus is eight bits wide [7:0]. The packet rotates around the
bus by one bit in bus_clock cycle 0 in the top half of the figure. As the bus_clock cycles increase, the
packet continues to rotate around the bus. When you stop rotation of the packet with the set_ssn_options
command, the tool pads the packet to make the packet size a multiple of the bus width, as shown in the
bottom half of the figure. In this example, the packet increases to two bus_clock cycles wide (0 and 1),
with seven bits of padding added to time slots one through seven in Cycle 1.

552 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Yield Statistics on ATE With SSN

Figure 133. Packet Rotation on the SSN Bus

Regardless of the number of bus words the packet occupies, when you use the "set_ssn_options
‑packet_constraints no_rotation" command, the tool adds padding to the packet to make the packet a
multiple of the bus width. This enables a predictable mapping from top-level data_out ports to the active
SSHs. Because the packet can be multiple bus words, the mapping is different for each bus_clock cycle,
as shown in the following example.
This example illustrates the annotations that the write_patterns command adds to the SSN STIL or WGL
pattern files to show the SSH to SSN data_out port mapping required when you use the "set_ssn_options
‑packet_constraints no_rotation" command.

Tessent™ Shell User’s Manual 553

Streaming Scan Network (SSN)
Yield Statistics on ATE With SSN

Example 35. Annotations for SSN Mapping With Packet Rotation Disabled

Ann {* TESSENT_PRAGMA ssn_mapping –begin *}

Ann {* TESSENT_PRAGMA ssn_mapping -datapath_id 1 -cycle_repetition 2
-cycle_mod 0 -design_port "ssn_bus_data_out[3]" -ssh_icl_instance
xtea_3.xtea_rtl_tessent_ssn_scan_host_1_inst –core_instance "xtea_3" *}
Ann {* TESSENT_PRAGMA ssn_mapping -datapath_id 1 -cycle_repetition 2
-cycle_mod 0 -design_port "ssn_bus_data_out[4]" -ssh_icl_instance
xtea_3.xtea_rtl_tessent_ssn_scan_host_1_inst –core_instance "xtea_3" *}
Ann {* TESSENT_PRAGMA ssn_mapping -datapath_id 1 -cycle_repetition 2
-cycle_mod 0 -design_port "ssn_bus_data_out[5]" -ssh_icl_instance
xtea_2.xtea_rtl_tessent_ssn_scan_host_1_inst –core_instance "xtea_2" *}
Ann {* TESSENT_PRAGMA ssn_mapping -datapath_id 1 -cycle_repetition 2
-cycle_mod 0 -design_port "ssn_bus_data_out[0]" -ssh_icl_instance
xtea_3.xtea_rtl_tessent_ssn_scan_host_1_inst –core_instance "xtea_3" *}
Ann {* TESSENT_PRAGMA ssn_mapping -datapath_id 1 -cycle_repetition 2
-cycle_mod 0 -design_port "ssn_bus_data_out[1]" -ssh_icl_instance
xtea_3.xtea_rtl_tessent_ssn_scan_host_1_inst –core_instance "xtea_3" *}
Ann {* TESSENT_PRAGMA ssn_mapping -datapath_id 1 -cycle_repetition 2
-cycle_mod 0 -design_port "ssn_bus_data_out[2]" -ssh_icl_instance
xtea_3.xtea_rtl_tessent_ssn_scan_host_1_inst –core_instance "xtea_3" *}
Ann {* TESSENT_PRAGMA ssn_mapping -datapath_id 1 -cycle_repetition 2
-cycle_mod 1 -design_port "ssn_bus_data_out[3]" -ssh_icl_instance
xtea_2.xtea_rtl_tessent_ssn_scan_host_1_inst –core_instance "xtea_2" *}
Ann {* TESSENT_PRAGMA ssn_mapping -datapath_id 1 -cycle_repetition 2
-cycle_mod 1 -design_port "ssn_bus_data_out[4]" -ssh_icl_instance
xtea_2.xtea_rtl_tessent_ssn_scan_host_1_inst –core_instance "xtea_2" *}
Ann {* TESSENT_PRAGMA ssn_mapping -datapath_id 1 -cycle_repetition 2
-cycle_mod 1 -design_port "ssn_bus_data_out[5]" -ssh_icl_instance
xtea_2.xtea_rtl_tessent_ssn_scan_host_1_inst –core_instance "xtea_2" *}
Ann {* TESSENT_PRAGMA ssn_mapping -datapath_id 1 -cycle_repetition 2
-cycle_mod 1 -design_port "ssn_bus_data_out[0]" -ssh_icl_instance
xtea_2.xtea_rtl_tessent_ssn_scan_host_1_inst –core_instance "xtea_2" *}
Ann {* TESSENT_PRAGMA ssn_mapping -datapath_id 1 -cycle_repetition 2
-cycle_mod 1 -design_port "ssn_bus_data_out[1]" -ssh_icl_instance
xtea_2.xtea_rtl_tessent_ssn_scan_host_1_inst –core_instance "xtea_2" *}
Ann {* TESSENT_PRAGMA ssn_mapping -datapath_id 1 -cycle_repetition 2
-cycle_mod 1 -design_port "ssn_bus_data_out[2]" -ssh_icl_instance
xtea_2.xtea_rtl_tessent_ssn_scan_host_1_inst –core_instance "xtea_2" *}
Ann {* TESSENT_PRAGMA ssn_mapping –end *}

This mapping enables the ATE to set up a fail limit per pin × (shift_cycle % cycle_repetition), where
cycle_repetition is the number of bus words a packet occupies. In this way, you can ensure that all cores
can be observed and the ATE can enforce a per-pin limit for failure messages.
If you need to map back to the specific from_scan_out bus of the SSH without dealing with the
complexities of bandwidth tuning, you can disable data throttling, combined with disabling the packet
rotation. This typically costs test efficiency, so it may not suit your overall run time needs. Use the
"set_ssn_options ‑packet_constraints no_rotation ‑throttling off" command to disable data throttling and
stop the rotation of the packet around the bus.
The following example shows annotations that the write_patterns command adds to the SSN STIL
or WGL pattern files to show the SSH to SSN data_out port mapping required when you use the
"set_ssn_options ‑packet_constraints no_rotation" command.
554 Tessent™ Shell User’s Manual
 Streaming Scan Network (SSN)
Yield Statistics on ATE With SSN

Example 36. Annotations for SSN Mapping With Packet Rotation and Throttling Disabled

Ann {* TESSENT_PRAGMA ssn_mapping –begin *}

Ann {* TESSENT_PRAGMA ssn_mapping -datapath_id 1 -cycle_repetition 2
-cycle_mod 0 -design_port "ssn_bus_data_out[3]" -ssh_icl_instance
xtea_3.xtea_rtl_tessent_ssn_scan_host_1_inst –core_instance "xtea_3"
-ssh_chain_group 3 -ssh_chain_group_chain_index 2 *}
Ann {* TESSENT_PRAGMA ssn_mapping -datapath_id 1 -cycle_repetition 2
-cycle_mod 0 -design_port "ssn_bus_data_out[4]" -ssh_icl_instance
xtea_3.xtea_rtl_tessent_ssn_scan_host_1_inst –core_instance "xtea_3"
-ssh_chain_group 3 -ssh_chain_group_chain_index 3 *}
Ann {* TESSENT_PRAGMA ssn_mapping -datapath_id 1 -cycle_repetition 2
-cycle_mod 0 -design_port "ssn_bus_data_out[5]" -ssh_icl_instance
xtea_2.xtea_rtl_tessent_ssn_scan_host_1_inst –core_instance "xtea_2"
-ssh_chain_group 1 -ssh_chain_group_chain_index 0 *}
Ann {* TESSENT_PRAGMA ssn_mapping -datapath_id 1 -cycle_repetition 2
-cycle_mod 0 -design_port "ssn_bus_data_out[0]" -ssh_icl_instance
xtea_3.xtea_rtl_tessent_ssn_scan_host_1_inst –core_instance "xtea_3"
-ssh_chain_group 2 -ssh_chain_group_chain_index 4 *}
Ann {* TESSENT_PRAGMA ssn_mapping -datapath_id 1 -cycle_repetition 2
-cycle_mod 0 -design_port "ssn_bus_data_out[1]" -ssh_icl_instance
xtea_3.xtea_rtl_tessent_ssn_scan_host_1_inst –core_instance "xtea_3"
-ssh_chain_group 3 -ssh_chain_group_chain_index 0 *}
Ann {* TESSENT_PRAGMA ssn_mapping -datapath_id 1 -cycle_repetition 2
-cycle_mod 0 -design_port "ssn_bus_data_out[2]" -ssh_icl_instance
xtea_3.xtea_rtl_tessent_ssn_scan_host_1_inst –core_instance "xtea_3"
-ssh_chain_group 3 -ssh_chain_group_chain_index 1 *}

Ann {* TESSENT_PRAGMA ssn_mapping -datapath_id 1 -cycle_repetition 2

-cycle_mod 1 -design_port "ssn_bus_data_out[3]" -ssh_icl_instance
xtea_2.xtea_rtl_tessent_ssn_scan_host_1_inst –core_instance "xtea_2"
-ssh_chain_group 1 -ssh_chain_group_chain_index 4 *}
Ann {* TESSENT_PRAGMA ssn_mapping -datapath_id 1 -cycle_repetition 2
-cycle_mod 1 -design_port "ssn_bus_data_out[4]" -ssh_icl_instance
xtea_2.xtea_rtl_tessent_ssn_scan_host_1_inst –core_instance "xtea_2"
-ssh_chain_group 2 -ssh_chain_group_chain_index 0 *}
Ann {* TESSENT_PRAGMA ssn_mapping -datapath_id 1 -cycle_repetition 2
-cycle_mod 1 -design_port "ssn_bus_data_out[5]" -ssh_icl_instance
xtea_2.xtea_rtl_tessent_ssn_scan_host_1_inst –core_instance "xtea_2"
-ssh_chain_group 2 -ssh_chain_group_chain_index 1 *}
Ann {* TESSENT_PRAGMA ssn_mapping -datapath_id 1 -cycle_repetition 2
-cycle_mod 1 -design_port "ssn_bus_data_out[0]" -ssh_icl_instance
xtea_2.xtea_rtl_tessent_ssn_scan_host_1_inst –core_instance "xtea_2"
-ssh_chain_group 1 -ssh_chain_group_chain_index 1 *}
Ann {* TESSENT_PRAGMA ssn_mapping -datapath_id 1 -cycle_repetition 2
-cycle_mod 1 -design_port "ssn_bus_data_out[1]" -ssh_icl_instance
xtea_2.xtea_rtl_tessent_ssn_scan_host_1_inst –core_instance "xtea_2"
-ssh_chain_group 1 -ssh_chain_group_chain_index 2 *}
Ann {* TESSENT_PRAGMA ssn_mapping -datapath_id 1 -cycle_repetition 2

Tessent™ Shell User’s Manual 555

Streaming Scan Network (SSN)
Yield Statistics on ATE With SSN
-cycle_mod 1 -design_port "ssn_bus_data_out[2]" -ssh_icl_instance
xtea_2.xtea_rtl_tessent_ssn_scan_host_1_inst –core_instance "xtea_2"
-ssh_chain_group 1 -ssh_chain_group_chain_index 3 *}
Ann {* TESSENT_PRAGMA ssn_mapping –end *}

556 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Manufacturing Patterns With SSN

Manufacturing Patterns With SSN

When you use the streaming scan network (SSN), you create manufacturing patterns from a netlist
that has been through layout and timing closure. You should create these patterns without any ATPG
pattern limits to achieve maximum test coverage. Simulate these patterns using a cycle-based simulator,
backannotating SDF delays on the design. For larger designs, it may not be practical to simulate all scan
patterns.

Note:
The process of creating manufacturing patterns is different from creating signoff patterns. For
a description of signoff patterns with SSN, refer to the section “Signoff Patterns With SSN” on
page 576.

Use the set_load_unload_timing_options command to set the timing of the SSN when creating
manufacturing patterns. If you share the SDC procedure set_load_unload_timing_options between the
Tessent tools and static timing analysis, it is only required for you to source the shared file. Sharing the
SDC procedure set_load_unload_timing ensures the timing of the manufacturing patterns written from the
Tessent tools precisely matches the timing of the design.
Table 23 shows the patterns you should use to test your silicon with SSN. These patterns are
recommended for both first silicon test and production test. It is also recommended for both that you start
with the least complex patterns and incrementally verify the SSN with each pattern up through the most
complex patterns. The ICLNetwork Verify patterns are the least complex, gradually leading to Retargeted
SSN patterns and (where applicable) Top-Level ATPG SSN patterns. For more detailed descriptions of
the patterns in this table, refer to the section “Signoff Patterns With SSN” on page 576.
Only designs that you have implemented with on-chip compare require the OCComp Self-Test Pattern
shown in this table. This pattern verifies that the SSN on-chip compare logic is free of any stuck-at faults.
For more information about SSN on-chip compare patterns, refer to "How to Write SSN On-Chip Compare
Patterns" in this section.

Table 23. SSN Manufacturing Pattern Summary

Order of Priority → → → Order of Priority

Top-Level
OCComp
ICLNetwork Continuity Loopback ATPG and
2 3 Self-Test
Verify Patterns Pattern 4 Pattern Retargeted SSN
Pattern
Patterns

First silicon X X X X X (chain test)

test
X (scan test)
5 5 5
Production test X X (chain test)

X (scan test)
____________________________________________________________________________________
2. Includes verification of streaming-through-IJTAG.
3. Based on multiplexers in the active datapath, you may need multiple continuity patterns.
4. Required only when the SSN is equipped with on-chip compare. If your datapath includes
multiplexers, required only when the multiplexers are configured such that the datapath contains
ScanHost nodes with OCComp.
5. Optional pattern that can be used to identify cause of failure.
Tessent™ Shell User’s Manual 557
Streaming Scan Network (SSN)
Manufacturing Pattern Quick Reference

Note:
Manufacturing patterns achieve maximum test coverage of the device under test and do not have
any pattern limits when created.

The following topics describe the SSN patterns and, because you can write the procedures that make
up SSN patterns to separate files, they also describe the strict order you must follow when applying the
manufacturing patterns to the tester when you have written the different procedures of the SSN pattern to
separate files:

Manufacturing Pattern Quick Reference

SSN Pattern Structure
How to Write Complete SSN Patterns
How to Write JTAG and Payload Procedures Separately
How to Write SSN On-Chip Compare Patterns
How To Write Streaming-Through-IJTAG Patterns
SSN Debug on the Tester

Manufacturing Pattern Quick Reference

The table in this topic summarizes the manufacturing patterns for use at first silicon test and production
test. You should simulate the Verilog pattern equivalent of these patterns without error before releasing
them to be used on the tester.

Table 24. Manufacturing Pattern Quick Reference

Pattern Type Limits Description

ICLNetwork None Verifies ICL instruments (tool and user) are readable and writable along the
verify IJTAG serial path.
Verifies the full scope of the IJTAG network, including
streaming-through-IJTAG path.
Runs at TCK period.

Continuity None Verifies SSN bus integrity between bus data_in and data_out.
Runs at bus_clock period.

Parallel scan None Verifies each scan register can reliably capture.
Capture clock and scan signals are cut points on SSH that testbench
pulses.
For retargeted scan patterns, can verify top-level clocking to lower-level
cores.

OCCompare None Verifies no stuck-at faults exist in SSH on-chip compare logic.
self-test

SSH loopback None Verifies SSN network can reliably deliver packetized data (excluding path to
EDT).
All SSN nodes are programmed with ssn_setup procedure as though full
pattern is to be run.

558 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
SSN Pattern Structure

Table 24. Manufacturing Pattern Quick Reference (continued)

Pattern Type Limits Description

Runs at bus_clock period.

Serial chain None Delivers packetized data to all SSH and verifies all chains shift without error.
Saves only nonmasking patterns.
The bus_clock in the SSH generates scan signals.
Runs off bus_clock.

Serial scan None Delivers packetized data to all SSH and verifies all chains shift and capture
without error. SSN end-to-end test.
The bus_clock in the SSH generates scan signals.
Runs off bus_clock.

SSN Pattern Structure

This section describes the basic structure of the SSN pattern as the write_patterns command writes it.
When you use the streaming scan network (SSN), there are additional procedures that are part of every
SSN pattern that do not appear in non-SSN patterns: ssn_setup and ssn_end. Furthermore, SSN delivers
the scan test data as a stream of data over the SSN bus. The ssn_setup, test_payload, and ssn_end
procedures combine with the existing test_setup and test_end procedures to create an SSN pattern as
shown in Figure 134.
The ssn_setup and ssn_end procedures configure the SSN nodes before and after you apply the
test_payload to the network. The test_payload is packetized scan data that streams over the SSN bus,
which delivers it to the streaming scan hosts (SSH) and scan chains. The ssn_setup procedure prepares
each active SSH to receive streaming data by programming the SSH ijtag_registers. The ssn_end
procedure prepares the SSN for the next test_payload by resetting the SSN nodes without resetting the
IJTAG programming. When you write SSN patterns using the ‑max_loads option, inclusion of an ssn_end
procedure after each test_payload enables the individual test_payload patterns to be applied in any order.
The ssn_end procedures also unload the SSH sticky bits when on-chip compare is active.
To produce the simplest SSN scan pattern, run the write_patterns command using only a format and
the -replace switch. The following example and figure show an SSN pattern with the SSN- specific
procedures along with the test_setup and test_end procedures. The ssn_setup and ssn_end SSN
procedures occur directly before and after the test_payload, respectively.

Example 37. Writing the Simplest Complete SSN Scan Pattern

write_patterns chip.stil -stil -replace

Tessent™ Shell User’s Manual 559

Streaming Scan Network (SSN)
How to Write Complete SSN Patterns

Figure 134. SSN Pattern Structure

How to Write Complete SSN Patterns

You can write complete SSN patterns into a single pattern file.
When you write SSN patterns, as in the following example, the write_patterns command stores the
test_setup, ssn_setup, test_payload, ssn_end, and test_end procedures all in a single file:
write_patterns chip.stil -stil -replace

560 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
How to Write JTAG and Payload Procedures Separately

Figure 135. SSN Patterns in a Single STIL File

Because of tool default values, the preceding command is a shortened form of this one:
write_patterns chip.stil -test_setup one_per_file -ssn_setup one_per_file -test_end one -stil \
-replace

Note:
If on-chip compare (OCComp) is turned off, the tool automatically removes the ssn_end
procedure at the end of the payload.

How to Write JTAG and Payload Procedures Separately

Duplicating setup procedures for large manufacturing counts may result in the setup procedures
dominating test time that should be allocated to applying the test_payload. To avoid this, you can write
procedures for the SSN patterns to separate files in a similar fashion to how you can write test_setup and
test_end procedures to separate files for non-SSN patterns. This enables more tester time to be spent
applying test_payload patterns.

CAUTION:
When you write out the test_setup, ssn_setup, ssn_end, test_end, and test_payload separately,
you are responsible for ensuring that the patterns are applied to the tester in the correct order. If
they are not, the tester produces mismatches on the SSN bus output.

Follow these rules when you write the procedures of SSN patterns to separate files:

Tessent™ Shell User’s Manual 561

Streaming Scan Network (SSN)
How to Write JTAG and Payload Procedures Separately

• Each write_patterns command must use the same pattern parameters (such as -begin/‑end and
‑pattern_sets).

• The individual procedures must be applied in the correct order on the tester.

• No additional clock cycles (including TCK) or pin constraints should be applied to the DUT before
or after applying the different pattern files.

Tip
SSN patterns are natively written to a single pattern file. Use write_patterns command options to
control whether it excludes a procedure when it writes the pattern files

Tip
When you write the SSN payload out separately and use the ‑max_loads option, ensure the
number of loads is greater than the number of cycles of ssn_setup and ssn_end.

Tip
The constraint "timeplate_constraints same_period" applies to SSN patterns when you
write the JTAG procedures and payload to the same pattern file. When you write them into
separate pattern files, the tool uses "timeplate_constraints none". Writing JTAG and payload
procedures into separate files provides the most efficient use of tester memory. Refer to the
set_tester_options command for more information about ‑timeplate_constraints.

Example 38 shows how to optionally write some of the procedures of the SSN pattern to separate pattern
files. It writes the test_setup, ssn_setup, and test_end procedures separately from the SSH loopback and
payload patterns. By writing out test_setup, ssn_setup, and test_end separately, you can apply numerous
payload patterns without the penalty of applying slow TCK procedures more than once.
Separate ssn_setup patterns are required for SSH loopback, chain payload, and scan payload data to
ensure the SSH programming matches the payload.

Example 38. SSN Patterns With Separate test_setup and ssn_setup

write_patterns test_setup.stil -test_setup only -stil -replace

write_patterns ssn_setup_loopback.stil -ssn_setup only \

-pattern_sets ssh_loopback -stil -replace
write_patterns ssh_loopback_payload.stil -test_payload \
-pattern_sets ssh_loopback -stil -replace
write_patterns ssn_end.stil -ssn_end only -pattern_sets ssh_loopback \
-stil -replace

write_patterns ssn_setup_chain.stil -ssn_setup only \

-pattern_sets chain -stil -replace
write_patterns chain_payload.stil -test_payload -max_loads <n> \
-pattern_sets chain -stil -replace
write_patterns ssn_end.stil -ssn_end only -pattern_sets chain -stil \
-replace

562 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
How to Write JTAG and Payload Procedures Separately
write_patterns ssn_setup_scan.stil -ssn_setup only -pattern_sets scan \
-stil -replace
write_patterns scan_payload.stil -test_payload -max_loads <n> \
-pattern_sets scan -stil -replace
write_patterns ssn_end.stil -ssn_end only -pattern_sets scan -stil
-replace

write_patterns test_end.stil -test_end only -stil -replace

The write_patterns commands in this example demonstrate how to write the payload and JTAG
procedures separately. When you write these procedures separately, the tck_ratio in the pattern is one
and the tool can maximize the compression for ATE memory.
Figure 136 illustrates the correct order in which to apply the pattern files. The test_setup procedure is
your custom chip setup and is identical to what you would use without SSN. The ssn_setup procedure
prepares the SSN by configuring the ScanHost nodes through the programming in the embedded IJTAG
registers. Each pattern type requires its own ssn_setup procedure, because the JTAG programming may
differ between them. For example, the throttling (that is, bits per packet) for SSH loopback and chain
test patterns may be different. The payload pattern files are applied after the ssn_setup procedure. The
ssn_end procedure is applied after the payload and prepares the network for the next pattern file when
you use the ‑max_loads argument. When on-chip compare is active, the ssn_end procedures shit out
the on-chip compare sticky status bits, which are visible on the TDO. The test_end procedure is the last
procedure of the pattern set and reconfigures the IJTAG network to a state that is equivalent to the post-
iReset state.

Note:
The payload patterns can be applied in any order as long as the ssn_end procedure is applied
after each payload pattern file.

Tessent™ Shell User’s Manual 563

Streaming Scan Network (SSN)
How to Write JTAG and Payload Procedures Separately

Figure 136. SSN Pattern Files With Order for Application on Tester

Using ‑all_* Options To Minimize File Count

You can group the test_setup and ssn_setup procedures into a single file by specifying the ‑all_setup_only
switch, as in the following example.

Example 39. SSN Pattern Files With Combined Single test_setup and ssn_setup

write_patterns setup.stil -all_setup_only -stil -replace

write_patterns payload.stil -test_payload -max_loads 500 \
-pattern_sets scan -stil -replace
write_patterns test_end only -stil -replace

When you write SSN patterns with the ‑all_setup_only switch, it produces a combined setup STIL file that
is separate from the test_payload and SSN and test end procedures, as in the following figure.

564 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
How to Write SSN On-Chip Compare Patterns

Figure 137. SSN Pattern Files With Combined Setup Showing Tester Order

Note:
You cannot combine the ‑all_end_only switch with the ‑max_loads option, because the ssn_end
procedure must be applied after each payload pattern file, as shown in Figure 136 on page 564
and Figure 137.

How to Write SSN On-Chip Compare Patterns

The on-chip compare feature of SSN is one of the primary features to make your test process more
efficient. It is common to use it when you have identical core instances or you are performing partial good
die testing. When present, the on-chip compare hardware in the SSH compares expected and measured
scan responses. You must test and verify that the on-chip compare hardware and the sticky bit status
registers in each SSH are free of any stuck-at faults.
The following example shows how to write the on-chip compare self-test pattern alongside the other SSN
patterns. It also uses the option to write the test_end procedure to a separate file. Use these commands
as a guide for using on-chip compare with your design.

Example 40. Writing Each Procedure of the SSN Pattern to Individual Files

write_patterns test_setup.stil -test_setup only -stil -replace

write_patterns ssn_setup_loopback.stil -ssn_setup only \

-pattern_sets ssh_loopback -stil -replace
write_patterns ssh_loopback_payload.stil -test_payload \
-pattern_sets \ssh_loopback -stil -replace
write_patterns ssn_end.stil -ssn_end only -pattern_sets ssh_loopback \
-stil -replace

write_patterns ssn_setup_occomp.stil -ssn_setup only \

-pattern_sets ssh_on_chip_compare -stil -replace
write_patterns occomp_payload.stil -test_payload \
-pattern_sets ssh_on_chip_compare -stil -replace

Tessent™ Shell User’s Manual 565

Streaming Scan Network (SSN)
How to Write SSN On-Chip Compare Patterns
write_patterns ssn_end.stil -ssn_end only \
-pattern_sets ssh_on_chip_compare -stil -replace

write_patterns ssn_setup_chain.stil -ssn_setup only \

-pattern_sets chain -stil -replace
write_patterns chain_payload.stil -test_payload -max_loads <n> \
-pattern_sets chain -stil -replace
write_patterns ssn_end.stil -ssn_end only -pattern_sets chain -stil \
-replace

write_patterns ssn_setup_scan.stil -ssn_setup only -pattern_sets scan \

-stil -replace
write_patterns scan_payload.stil -test_payload -max_loads <n> \
-pattern_sets scan -stil -replace
write_patterns ssn_end.stil -ssn_end only -pattern_sets scan -stil
-replace

write_patterns test_end.stil -test_end only -stil -replace

The JTAG and payload patterns in this example must be applied on the tester in the correct order to avoid
mismatches on the SSN bus output. The SSN data stream depends on the order of how the patterns are
applied on the tester.
This example extends the idea of the example in the section “How to Write JTAG and Payload
Procedures Separately” on page 561 by writing the on-chip compare self-test. As described previously,
the on-chip compare self-test verifies the on-chip compare logic in the SSH. The on-chip compare self-
test should be applied before any payload patterns when you have enabled on-chip compare.

566 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
How To Write Streaming-Through-IJTAG Patterns

Figure 138. SSN Pattern Files With On-Chip Compare Self-Test

The on-chip compare self test uses the SSN bus for the following:

• To deliver the stimulus used to test the on-chip compare hardware for stuck-at faults.

• To unload the status of the hardware test.

Unloaded data is compared on the bus output.

How To Write Streaming-Through-IJTAG Patterns

Streaming-Through-IJTAG patterns are SSN patterns delivered to the active SSHs through TDI and
measured on TDO with TCK as the synchronous clock source.

Tessent™ Shell User’s Manual 567

Streaming Scan Network (SSN)
How To Write Streaming-Through-IJTAG Patterns

Note:
Streaming-Through-IJTAG patterns can only be applied when you have selected the streaming
interface using the set_ssn_options command.

While Streaming-Through-IJTAG patterns are being applied, the TAP finite-state machine is put into the
Shift-DR state while data is being delivered to the network through TDI. The SSH functional behavior
during Streaming-Through-IJTAG is the same as when you use the parallel bus. The only difference is the
delivery of streaming scan data to the network as a single bit through TDI.

Note:
Any SSN pattern created using the parallel bus can be retargeted through the top-level TAP
controller and converted to a Streaming-Through-IJTAG pattern.

Note:
Writing the on-chip compare hardware self-test pattern is not compatible with Streaming-Through-
IJTAG mode.

Example 41. Writing Streaming-Through-IJTAG Patterns

write_patterns test_setup.stil –test_setup only -stil –replace

write_patterns ssn_setup_loopback.stil –ssn_setup only \

–pattern_sets ssh_loopback –stil -replace
write_patterns ssh_loopback_payload.stil –test_payload \
–pattern_sets ssh_loopback –stil –replace
write_patterns ssn_end.stil -ssn_setup off -ssn_end only -stil -replace

write_patterns ssn_setup_chain.stil –ssn_setup only \

–pattern_sets chain –stil –replace
write_patterns chain_payload.stil –test_payload –pattern_sets chain \
–stil –replace
write_patterns ssn_end.stil -ssn_setup off -ssn_end only -stil -replace

write_patterns ssn_setup_scan.stil –ssn_setup only –pattern_sets scan \

–stil –replace
write_patterns scan_payload.stil –test_payload –max_loads 500 \
–pattern_sets scan –stil –replace
write_patterns ssn_end.stil -ssn_setup off -ssn_end only -stil -replace

write_patterns test_end.stil –test_end only –stil –replace

568 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
SSN Debug on the Tester

Figure 139. Tester Application Order for Streaming-Through-IJTAG

SSN Debug on the Tester

Use a combination of patterns to help narrow down the source of the failure when SSN patterns fail on the
tester. It is important to apply SSN patterns to the tester in the correct order.
During silicon debug, you can reuse the verification patterns used during insertion and integration of the
SSN. Use the following patterns to narrow the scope of the potential source of the failure when applied in
the correct order, incrementally verifying the functional behavior of the SSN:

• ICLNetwork Verify Patterns — Confirms the IJTAG registers of the SSN can be accessed.

• Continuity Patterns — Confirms the parallel bus is connected to each SSN node and each
branch of SSN multiplexer is accessible from bus_in to bus_out.

• SSH Loopback Pattern — Confirms the network can reliably deliver packetized data to the
active SSHs without involving the EDT/scan chains.

• On-Chip Compare Self-Test Pattern — Confirms there are no stuck-at faults in the on-chip
compare logic, including the sticky bit status registers.

Tessent™ Shell User’s Manual 569

Streaming Scan Network (SSN)
SSN Debug on the Tester

The examples in the following sections show how to create and apply these patterns on the tester. This
flow diagram indicates the order in which to apply them and incrementally verify the functional behavior of
the SSN:

Figure 140. Order To Apply Patterns for SSN Pattern Failure Debugging

ICLNetwork Verify Patterns

The following example shows the commands to write ICLNetwork verify patterns that you can apply on
the tester. These patterns verify that the IJTAG registers in the SSN are accessible and that they can be
read and written without any errors. Passing ICLNetwork verify patterns indicates the SSN network is
properly configured, including the SSH nodes that are programmed as part of the ssn_setup procedure.
To determine the order of application for ICLNetwork verify patterns, refer to Figure 141.

Example 42. Writing ICLNetwork Verify Patterns in STIL Format

set_context patterns -ijtag

…
open_pattern_set icl_network
create_icl_verification_patterns
close_pattern_set
write_patterns ICLNetwork_verify.stil -stil –replace

570 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
SSN Debug on the Tester

Figure 141. Order To Apply ICLNetwork Verify Patterns to the Tester

Continuity Patterns
The following example shows the commands to write SSN continuity patterns for application on the tester.
These patterns verify that the parallel bus is connected to each SSN node without any bit swizzles or
opens and that each branch of an SSN multiplexer is accessible from bus_data_in to bus_data_out.
A passing SSN continuity pattern indicates the parallel bus in the design has no opens or gaps. To
determine the order of application for SSN continuity patterns, refer to Figure 142.

Note:
Each of the SSN multiplexers along the parallel bus is configured individually with an IJTAG iProc
followed by an iCall to that procedure. Refer to the script in the section “Second DFT Insertion
Pass: Inserting Top-Level EDT, OCC, and SSN” on page 511 for a working example of how the
iCall reconfigures the SSN multiplexers.

Note:
The tool does not support SVF output for SSN continuity patterns.

Example 43. Writing SSN Continuity Patterns in STIL Format

set_context patterns -ijtag

…
open_pattern_set ssn_continuity -usage ssn
create_ssn_continuity_patterns
close_pattern_set
write_patterns test_setup.stil -test_setup only \
-pattern_sets ssn_continuity -stil -replace
write_patterns ssn_setup_continuity.stil -ssn_setup only \
-pattern_sets ssn_continuity -stil -replace
write_patterns ssn_continuity.stil -test_payload \
-pattern_sets continuity -stil -replace

Tessent™ Shell User’s Manual 571

Streaming Scan Network (SSN)
SSN Debug on the Tester
write_patterns ssn_end_continuity.stil -ssn_end only \
-pattern_sets continuity -stil -replace
write_patterns test_end.stil -test_end only \
-pattern_sets ssn_continuity -stil -replace

Note:
The ssn_end procedure is an empty procedure when it is written and the pattern set is
ssn_continuity.

Figure 142. Order To Apply SSN Continuity Patterns to the Tester

On-Chip Compare Self-Test Patterns

The SSH on-chip compare self-test is only necessary when one or more SSHs are equipped with on-
chip compare hardware. The following example shows the commands to write the SSH on-chip compare
self-test patterns for application on the tester. A passing on-chip compare self-test indicates the on-chip
compare hardware and sticky bit status registers are free of any stuck-at faults. To determine the order of
application for on-chip compare self-test patterns, refer to Figure 143.

Example 44. Writing SSH On-Chip Compare Self-Test Patterns

write_patterns test_setup.stil -test_setup only \

-pattern_sets ssn_on_chip_compare -stil -replace
write_patterns ssn_setup_occomp.stil -ssn_setup only \
-pattern_sets ssh_on_chip_compare -stil -replace
write_patterns ssn_occomp.stil -test_payload \
-pattern_sets ssh_on_chip_compare -stil -replace

572 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
SSN Debug on the Tester
write_patterns ssn_end_occomp.stil -ssn_end only \
-pattern_sets ssh_on_chip_compare -stil -replace
write_patterns test_end.stil -test_end only \
-pattern_sets ssn_on_chip_compare -stil -replace

Figure 143. Order To Apply SSN On-Chip Compare Self-Test Patterns

SSH Loopback Patterns

The SSH loopback pattern is the culmination of the first two test patterns: ICLNetwork verify and SSN
continuity patters. Use this pattern with any configuration of active cores during ATPG and scan pattern
retargeting. The following example shows commands to write the SSH loopback patterns for application
on the tester.

Example 45. Writing SSH Loopback Patterns in STIL Format

write_patterns test_setup.stil -test_setup only -stil -replace

write_patterns ssn_setup_loopback.stil -ssn_setup only \
-pattern_sets ssh_loopback -stil -replace
write_patterns ssh_loopback.stil -test_payload \
-pattern_sets ssh_loopback -stil -replace
write_patterns ssn_end_loopback.stil -ssn_end only \
-pattern_sets ssh_loopback -stil -replace
write_patterns test_end.stil -test_end only -stil -replace

In this example, the SSH loopback patterns test the SSH without involving the EDT and scan chains. The
SSH loopback pattern uses the ssn_setup procedure to configure the SSH based on the payload of the
active cores. During the SSH loopback pattern, the streaming interface (bus or IJTAG) delivers packetized
data to each active SSH that is programmed to match the payload. The ssn_end procedure is applied to
the network after each SSH loopback pattern. When you combine SSH loopback patterns and payload
patterns, you must place the SSH loopback patterns before the payload patterns, because the SSH
loopback patterns confirm that the network can reliably deliver packetized data, as described previously.

Tessent™ Shell User’s Manual 573

Streaming Scan Network (SSN)
SSN Debug on the Tester
A passing SSH loopback pattern set indicates the SSN can reliably deliver packetized data to the current
configuration of active cores and that the SSHs correctly operate after application of ssn_setup and
ssn_end. To determine the order of application for SSH loopback patterns, refer to the following figure.

Figure 144. Order To Apply SSH Loopback Patterns

The following example shows the commands to write the chain and scan patterns with the loopback
pattern for application on the tester. By extending the previous example to include the chain and scan
patterns, you can further narrow the scope of failing patterns on silicon. To determine the order of
application for SSH loopback, chain, and scan patterns on the tester, refer to Figure 145.

Example 46. Writing SSH Loopback, Chain, and Scan Patterns to Individual Files

write_patterns test_setup.stil -test_setup only -stil -replace

write_patterns ssn_setup_loopback.stil -ssn_setup only \
-pattern_sets ssh_loopback -stil -replace
write_patterns ssh_loopback.stil -test_setup off -ssn_setup off \
-ssn_end on -pattern_sets ssh_loopback -stil -replace
write_patterns ssn_setup_chain.stil -ssn_setup only \
-pattern_sets chain -stil -replace
write_patterns chain.stil -test_setup off -ssn_setup off -ssn_end on \
-pattern_sets chain -stil -replace
write_patterns ssn_setup_scan.stil -ssn_setup only -pattern_sets scan \
-stil -replace
write_patterns scan.stil -test_setup off -ssn_setup off -ssn_end on \
-max_loads 500 -pattern_sets scan -stil -replace
write_patterns test_end.stil -test_end only -stil -replace

574 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
SSN Debug on the Tester

Figure 145. Order To Apply SSH Loopback, Chain, and Scan Patterns

Tessent™ Shell User’s Manual 575

Streaming Scan Network (SSN)
Signoff Patterns With SSN

Signoff Patterns With SSN

This section describes the list of signoff patterns you should simulate at the block level, during top-level
ATPG, and during scan retargeting. Signoff patterns are the minimum set of patterns you should simulate
to verify your design with the DFT-inserted structures before releasing the design to layout. Use this
signoff process to find potential problems in your design with a minimum set of patterns that provides a
maximum amount of simulation coverage.

Note:
The process of creating signoff patterns is different from creating manufacturing patterns. For a
description of manufacturing patterns with SSN, refer to the section “Manufacturing Patterns With
SSN” on page 557.

The following sections describe the unique behavior of each type of signoff pattern when written with SSN
present. The signoff pattern guidelines in these sections minimizes the risk of problems occurring in your
post-layout netlists. For each test, the section does the following:

• Identifies the synchronous source of the SSN.

• Explains the purpose of the test.

• Describes the behavior of the SSH when writing patterns at the block level, during top-level
ATPG, and during pattern retargeting.
You should create signoff patterns without any ATPG pattern limits (for example, by specifying
"set_atpg_limits ‑pattern_count off"). The methods for writing the patterns are described in the following
sections. For more examples of writing patterns, refer to “Tessent SSN Workflows” on page 484. Create
patterns using both the stuck-at and transition fault models. Simulate the patterns in the following order,
which incrementally verifies the SSN network:

1. Parallel Scan

2. SSH Loopback

3. Serial Chain

4. Serial Scan
Each pattern uses the previously validated step. You should create and simulate these patterns until they
are error-free before signoff, regardless of whether you choose parallel bus or IJTAG streaming for SSN.

Note:
You should create signoff patterns only after you have successfully simulated the ICL Network
Verify and SSN Continuity patterns without any errors.

576 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Block-Level Signoff Patterns

Note:
Verification of the SSN at intermediate levels of hierarchy in your design is necessary prior to top-
level ATPG or pattern retargeting when you have assembled the datapath by hand or using a
script.

Block-Level Signoff Patterns

Top-Level Signoff Patterns
Signoff Pattern Quick Reference
Troubleshooting Miscompares of X Values in Signoff Patterns

Block-Level Signoff Patterns

You should simulate the block-level patterns without error before signoff. Block-level patterns include
parallel scan patterns, SSH loopback patterns, serial chain patterns, and serial scan patterns. Each of
these pattern types has its own set of prerequisites.

Parallel Scan Patterns

Prerequisites:

• Passing ICL verification patterns

• Passing SSN continuity patterns

During parallel pattern simulation with SSN, only scan pins of synchronous elements are active during
scan shift and capture procedures, as in testing without SSN. These patterns’ purpose is to validate the
capture procedure for a large volume of scan patterns by simulating them in a reasonable amount of time.
While you simulate these patterns, the synchronous clock source to the SSN is not active, and the data
delivered to the scan cells is not packetized data. The SSH is not actively transferring data between the
SSN bus and the EDT/scan chains, and the scan signals generated by the SSH in the serial patterns are
replaced by cut points that the tool automatically creates. The transitioning of the scan signals precisely
models the protocol of the scan pattern. The shift_capture_clock and capture clock run at their default
clock periods unless you use the set_load_unload_timing_options and set_capture_timing_options
commands to specify otherwise.
The following is an example of writing SSN parallel patterns:
write_patterns parallel.v -verilog -pattern_sets scan -replace

This should be the first pattern you simulate before signoff.

SSH Loopback Patterns

Prerequisites:

• Passing ICL verification patterns

• Passing SSN continuity patterns

During SSH loopback pattern simulation, the tool delivers packetized data to the SSH. The purpose of
these patterns is to verify that SSN can correctly process packetized data without error, and that the
SSHs operate correctly after application of ssn_setup and ssn_end. The SSH loopback pattern tests

Tessent™ Shell User’s Manual 577

Streaming Scan Network (SSN)
Block-Level Signoff Patterns
exclude the EDT/scan chains from the test and include the SSH and other SSN nodes between bus_in
and bus_out.
The SSH loopback pattern test consists of multiple phases, each delivering a payload file. By default,
there are three phases. You can change this with the "set_ssn_options -loopback_patterns_phases"
command. If you set the number of phases to 1, the tool produces only a single payload file, and the
tool cannot check for correct operation after application of ssn_setup and ssn_end, although it still
checks for correct processing of packetized data. Each payload is followed by an ssn_end procedure.
For SSHs with on-chip compare, the tool injects fails into the expected patterns. The SSH status
bits and sticky status bits indicate these failures, and the generated patterns expect this so that the
applied patterns do not report mismatches. You can turn off this behavior with the "set_ssn_options
-on_chip_compare_loopback_pattern_inject_fails" command.
During simulation of this pattern, the SSN bus_clock is the clock source, and packetized data
synchronously streams over the SSN. The SSH extracts the correct bits from the packet based on
the ssn_setup procedure. The data loops back into the SSH, skipping the EDT/scan chains. After the
data loops back into the SSH, it returns to the packet in the same time slot as the input data. As the
packet synchronously streams through the network, the expected values are strobed on bus_out. During
simulation of this pattern, only the bus_clock runs, and the scan signals from the SSH do not toggle and
are constrained to zero.
The following is an example of writing SSH loopback patterns:
write_patterns ssh_loopback.v -verilog -serial -pattern_sets ssh_loopback -replace

Serial Chain Patterns

Prerequisites:

• Passing SSH loopback patterns

During serial chain pattern simulation, the tool delivers packetized scan shift data to the EDT/scan chains
through SSH. The purpose of these patterns is to verify that the scan chains can reliably shift scan data
without error.
During simulation of these patterns, the SSN bus_clock is the clock source, and packetized data
synchronously streams over the SSN. The SSH extracts the correct number of bits from the packet and
transfers them to the EDT/scan chains. The scan signals are synchronously created within the SSH and
clock the scan circuit. When SSN is present, the tool suppresses the capture clock, regardless of whether
you use the Tessent OCC or a third-party OCC. Without the capture cycle, the SSH holds the scan_en
high during chain tests. During unloading of the scan chains, the SSH puts the scan unload data back into
the packet. When on-chip compare is off, the scan unload data is added back into the packet in the same
time slots as the input data. When on-chip compare is enabled, the data is added back into the packet
but does not overwrite the input data. It is added to the packet in a location determined by the number of
status groups.
The shift_capture_clock runs at the default clock period unless you use the
set_load_unload_timing_options command to specify otherwise.
Typically, the SSN bus_clock runs at a slower frequency than specified with the
set_load_unload_timing_options command at the block level. The bus clock period is governed by the
packet size relative to the bus width. When the packet size is less than two bus_clock cycles, the SSN
bus_clock is reduced to the shift_capture_clock frequency. To increase the bus_clock frequency to the
default or to the maximum frequency you specified using the set_load_unload_timing_options command,
use the SIM_SSN_MAXIMUM_BUS_SPEED testbench parameter. When you write the testbench with
this parameter set to one, the tool increases the size of the packet so that the bus_clock runs at its
maximum frequency in a Verilog testbench.
It can be difficult to debug mismatches in a serial SSN simulation, because the SSH obfuscates the EDT
channels/scan chains. Furthermore, there may be any number of pipeline stages along the SSN bus,

578 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Block-Level Signoff Patterns
further complicating the analysis of the root cause to the failure. To debug serial SSN simulations, use the
SIM_PARALLEL_MONITOR testbench parameter. When you set this parameter to one, the testbench
monitors the load and unload values of each memory element and echoes the instance name to the log
file for easier analysis of any failure.
For large designs, simulating all chain test patterns can be time-consuming and impractical. Use the
"set_chain_test -type nomask" command to enable you to efficiently simulate the shift path of all your
scan chains without testing the magic logic of the EDT decoder. Combine the "set_chain_test ‑type
nomask" command with the "write_patterns ‑end 0" command to write a single chain test pattern that
tests the shift paths of all the scan chains. A single chain test pattern that simulates all scan chains is all
you require.
The following example commands write a single serial chain test pattern that excludes testing any of the
EDT decode logic:
set_chain_test -type nomask
write_patterns chain_test.v -verilog -serial -end 0 -pattern_sets chain -replace

Serial Scan Patterns

Prerequisites:

• Passing SSN serial chain patterns

During serial scan pattern simulation, the tool delivers packetized scan shift data to the EDT/scan chains
through SSH. These patterns’ purpose is to verify that the scan chains can reliably shift and capture
without error.
When simulating this pattern, the SSN network operates exactly as described in the preceding
subsection, Serial Chain Patterns, with the addition that capture cycles are included in this pattern. The
correct number of capture pulses comes through the OCC clock control bits. During stuck-at fault testing,
the SSH synchronously creates the capture clock from the SSN bus_clock. The SSH capture clock
frequency comes from the default clock period unless you use the set_capture_timing_options command
to specify otherwise. During transition fault testing, the functional clock is the capture clock. This pattern is
an SSN end-to-end test.
For large designs, simulating all serial scan patterns can be time-consuming and impractical. Use the
"write_patterns -end 0" command to write a single end-to-end scan test pattern that is sufficient to test the
SSN along with the previously specified patterns.
You can use the SIM_SSN_MAXIMUM_BUS_SPEED testbench parameter, as described in the Serial
Chain Patterns section, to simulate the serial scan patters at the maximum SSN bus frequency.
You can use the SIM_PARALLEL_MONITOR testbench parameter, as described in the Serial Chain
Patterns section, to debug the serial scan patterns.
The following example command writes a single serial scan test pattern:
write_patterns scan_test.v -verilog -serial -end 0 -pattern_sets scan -replace

Block-Level Signoff Pattern Summary

The following table summarizes the block-level patterns used for verification from integration to pattern
creation of the SSN. You should run the pattern verification from least complex to most complex. When
you follow this order, it verifies the SSN incrementally, making it easier to identify problems along the way.
Depending on your flow, you can perform verification of the SSN during integration either at the RTL or
the gate level. For both cases, the ICLNetwork verification patterns also verify the Streaming-Through-
IJTAG Scan Data path of the SSN. The entry point and path within the SSH is the same, regardless
of whether you are accessing IJTAG registers in the SSH or streaming scan data through the IJTAG
interface of the SSH.

Tessent™ Shell User’s Manual 579

Streaming Scan Network (SSN)
Top-Level Signoff Patterns

Table 25. Block-Level Verification Pattern Summary

Least complex → → → Most complex

ICLNetwork Scan Pattern Scan Pattern

Verify 6 Continuity Loopback
Pattern Pattern
Patterns Parallel Serial
7
SSN integration X X

Post-synthesis X X
validation
(non‑scan)

Core-level ATPG X X (chain test)

pattern validation
X (scan test) X (scan test)

Top-Level Signoff Patterns

You should simulate the top-level patterns without error before signoff. Block-level patterns include
parallel scan patterns, SSH loopback patterns, serial chain patterns, and serial scan patterns. Each of
these pattern types has its own set of prerequisites.
As part of the signoff process, you should retarget cores on a per-module basis. Do not group different
modules for retargeting during signoff. Grouping different modules for retargeting is a process performed
for manufacturing.

Parallel Scan Patterns

Prerequisites:

• Passing ICL verification patterns

• Passing SSN continuity patterns

• Passing child core scan patterns, as described in “Block-Level Signoff Patterns” on page 577

• Scan graybox has been created for all lower-level blocks

Top-level parallel scan patterns operate in two different situations:

• Parallel pattern during top-level ATPG with child cores — During ATPG, the top-level scan
chains and the wrapper scan chains of each child core are active. This pattern tests the intra-
domain capture between the top level and the child cores. The active SSHs in the parallel pattern
are capture-aligned. You should write the parallel pattern without a pattern count limit.

• Parallel pattern during pattern retargeting — Normally, during scan pattern retargeting
with SSN, each core transitions between shift and capture independently. However, a Verilog

____________________________________________________________________________________
6. Includes verification of the streaming-through-IJTAG SSH path
7. SSN integration at RTL, gate level, or both
580 Tessent™ Shell User’s Manual
 Streaming Scan Network (SSN)
Top-Level Signoff Patterns
testbench cannot accurately model this behavior for the cores. Therefore, in this testbench the
active cores appear to be capture-aligned, although this is not the way that the implemented
design behaves. Use this pattern to verify the clocking during pattern retargeting.
For a description of parallel scan pattern behavior and an example of how to write the pattern, refer to the
section Parallel Scan Patterns in the topic “Block-Level Signoff Patterns” on page 577.

SSH Loopback Patterns

Prerequisites:

• Passing ICL verification patterns

• Passing SSN continuity patterns

During top-level ATPG when child cores are present, the top-level SSH loopback pattern delivers
packetized data to the top-level SSH and the SSH of each child core. The cores are in external mode.
During simulation of this pattern, the tool forces the scan signals at the edges of the SSHs low. The
packet contains data for the top-level SSH and the SSH for each child core. These patterns are short and
simulate quickly. They verify that each SSH can precisely extract and replace data in the packet and that
the SSHs operate correctly after application of ssn_setup and multiple applications of ssn_end.
You cannot retarget SSH loopback patterns. During pattern retargeting, the packet used in the SSH
loopback test is created from the scan data for each core whose patterns is being retargeted. In this case,
the purpose of the SSH loopback pattern is to test the SSN with a representative packet to be used during
pattern retargeting.
For a description of SSH loopback pattern behavior and an example of how to write the pattern, refer to
the section SSH Loopback Patterns in the topic “Block-Level Signoff Patterns” on page 577.

Serial Chain Patterns

Prerequisites:

• Passing SSH loopback patterns

Top-level serial chain patterns operate in two different situations:

• Serial chain pattern during top-level ATPG with child cores — During ATPG, this pattern
delivers packetized scan shift data to the top-level SSH and to the SSH of each child core. The
child cores are in external mode, and the local SSH to those child cores shifts their wrapper
chains. During simulation of this pattern, the capture clock is suppressed and the top-level SSH
and child core SSHs are capture-aligned.

• Serial chain pattern during pattern retargeting — During simulation of this pattern, the tool
creates the packet from each core whose patterns are being retargeted. Each core operates
independently of the others, receiving a different number of bits per packet based on data
throttling. By default, the tool optimizes throttling for pattern retargeting based on all scan patterns
if scan patterns are present, and all chain patterns if scan patterns are not present. Refer to the
description of the -throttle_based_on_selected_patterns argument in set_ssn_options for more
details.
For a description of serial chain pattern behavior and an example of how to write the pattern, refer to the
section Serial Chain Patterns in the topic “Block-Level Signoff Patterns” on page 577.

Tessent™ Shell User’s Manual 581

Streaming Scan Network (SSN)
Top-Level Signoff Patterns

Serial Scan Patterns

Prerequisites:

• Passing serial chain patterns

Top-level serial chain patterns operate in two different situations:

• Serial scan pattern during top-level ATPG with child cores — During ATPG, this pattern
delivers packetized scan data to the top-level SSH and to the SSH of each child core. The child
cores are in external mode, and the local SSH to those child cores shifts their wrapper chains.
During simulation of this pattern, the scan chains shift and capture, and the top-level SSH and
child core SSHs are capture-aligned.

• Serial scan pattern during pattern retargeting — During simulation of this pattern, the tool
creates the packet from each core whose patterns are being retargeted. Each core operates
independently of the others, receiving a different number of bits per packet based on data
throttling. By default, the tool optimizes throttling for pattern retargeting based on all scan patterns
if scan patterns are present, and all chain patterns if scan patterns are not present. Refer to the
description of the -throttle_based_on_selected_patterns argument in set_ssn_options for more
details.
For a description of serial chain pattern behavior and an example of how to write the pattern, refer to the
section Serial Scan Patterns in the topic “Block-Level Signoff Patterns” on page 577.

Top-Level Signoff Pattern Summary

The following table summarizes the top-level patterns used for verification from integration to pattern
creation of the SSN. You should run the pattern verification from least complex to most complex. If your
design has more than two levels of hierarchy (for example, more than block and top), you should verify
the SSN at all intermediate levels. This ensures that the datapath is properly connected. When you follow
this order, it verifies the SSN incrementally, making it easier to identify problems along the datapath.
Depending on your flow, you can perform verification of the SSN during integration either at the RTL or
the gate level. For both cases, the ICLNetwork verification patterns also verify the Streaming-Through-
IJTAG Scan Data path of the SSN. The entry point and path within the SSH is the same, regardless
of whether you are accessing IJTAG registers in the SSH or streaming scan data through the IJTAG
interface of the SSH.

Table 26. Top-Level Verification Pattern Summary

Least complex → → → Most complex

ICLNetwork Scan Pattern Scan Pattern

Verify 8 Continuity Loopback
Pattern Pattern
Patterns Parallel Serial
9
SSN integration X X

Post-synthesis X X
validation
(non‑scan)

____________________________________________________________________________________
8. Includes verification of streaming-through-IJTAG
9. SSN integration at RTL, gate level, or both
582 Tessent™ Shell User’s Manual
 Streaming Scan Network (SSN)
Signoff Pattern Quick Reference

Table 26. Top-Level Verification Pattern Summary (continued)

Least complex → → → Most complex

ICLNetwork Scan Pattern Scan Pattern

Verify 8 Continuity Loopback
Pattern Pattern
Patterns Parallel Serial

Top-level ATPG X X (chain test)

pattern validation
X (scan test) X (scan test)

Pattern X X (chain test)

retargeting
validation 10
X (scan test) X (scan test)

Signoff Pattern Quick Reference

The table in this topic summarizes the signoff patterns at the block and top levels. You should simulate
these patterns without error before releasing the design for layout.

Table 27. Signoff Pattern Quick Reference

Pattern
Pattern Type Limits Description

ICLNetwork None Verifies ICL instruments (tool and user) are readable and writable along
verify the IJTAG serial path.
Verifies the full scope of the IJTAG network, including
streaming-through-IJTAG path.
Runs at TCK period.

Continuity None Verifies SSN bus integrity between bus data_in and data_out.
Runs at bus_clock period.

Parallel scan None Verifies each scan register can reliably capture.
Capture clock and scan signals are cut points on SSH that testbench
pulses.
For retargeted scan patterns, can verify top-level clocking to lower-level
cores.

SSH loopback None Verifies SSN network can reliably deliver packetized data (excluding path
to EDT).
All SSN nodes are programmed with ssn_setup procedure as though full
pattern is to be run.
Runs at bus_clock period.

Serial chain 1 Delivers packetized data to all SSH and verifies all chains shift without
error. Saves only nonmasking patterns.

____________________________________________________________________________________
8. Includes verification of streaming-through-IJTAG
10. SSN retargeting parallel testbench only verifies clocking during scan pattern retargeting
Tessent™ Shell User’s Manual 583
Streaming Scan Network (SSN)
Troubleshooting Miscompares of X Values in Signoff Patterns

Table 27. Signoff Pattern Quick Reference (continued)

Pattern
Pattern Type Limits Description

bus_clock in the SSH generates scan signals.

Runs off bus_clock.

Serial scan 1 Delivers packetized data to all SSH and verifies all chains shift and
capture without error. SSN end-to-end test.
bus_clock in the SSH generates scan signals.
Runs off bus_clock.

Troubleshooting Miscompares of X Values in Signoff

Patterns
Miscompares of X values in serial patterns with passing parallel patterns may result from a simulation
artifact.

Symptoms
In certain rare circumstances, serial pattern simulation may report miscompares involving X values in
cases where the parallel patterns pass and parallel scan cell monitoring does not identify the root cause.
The source of the X value may be from a floating pin or an analog block that Verilog signoff simulation
does not simulate and that later propagates to the ScanHost logic.

Causes
This may be related to convergence generated by synthesis optimization, which can lead to X pessimism
during serial SSN pattern simulation.

Solution
Siemens EDA does not recommend ungrouping the SSN logic outside SSN modules, which may hamper
the debugging process. Use the following steps to debug these miscompares:

1. Verify that the parallel patterns pass.

2. Change the ScanHost module view to RTL and verify that the patterns pass.

3. Force the original X source (the floating pin or analog output) to 1 and 0 values to confirm that
both values work correctly.
If all three steps are successful, then the design and the patterns are good despite the miscompare,
which results only from simulation. The patterns can be successfully verified on an ATE and on the design
silicon.

Related Topics
SIM_PARALLEL_MONITOR [Tessent Shell Reference Manual]

584 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
SSN SDC Constraints in the Design Flow

SSN SDC Constraints in the Design Flow

The following topics describe how to work with SDC constraints when SSN is present in the design.

Overview of SSN-Related SDC Procs and Constraints

SSN/SSH SDC Constraint Descriptions

Tessent™ Shell User’s Manual 585

Streaming Scan Network (SSN)
Overview of SSN-Related SDC Procs and Constraints

Overview of SSN-Related SDC Procs and Constraints

SSN requires updates to the logictest-related constraint procs in the SDC output file that the extract_sdc
command produces.
The following topics describe these updates to the SDC file procs and how to use them in synthesis,
layout, hierarchical signoff static timing analysis (STA), and full-chip STA in the SSN context.
SSN SDC constraints work in conjunction with many of the Tcl procs dedicated to Tessent-logictest
SDC constraints, such as those that define the shift, slow_capture, and fast_capture STA modes. This
is possible because SSN is simply a faster and more flexible scan implementation than traditional
implementations.
The generated constraints added for SSN perform the following functions:

• Declare the SSN bus clocks and define the timing of the SSN bus ports.

• Relax paths across node multipliers and node dividers with MCP constraints.

• Accurately time the SSH scan interface circuits, which includes creating the scan clocks and
adding timing exceptions for the scan control signals and serial paths.

• Add timing exceptions to and from subphysical block boundaries.

• Provide a way to time the SSN/SSH logic of the lower-level physical blocks.

• Properly time SSN nodes that can only stream through IJTAG, with no SSN bus clock.

• Provide ways to disable the SSN logic if needed, and prevent other mode clocks, such as
ijtag_tck, from propagating to the scan flops.
For more information about constraints, refer to the section “SSN/SSH SDC Constraint Descriptions” on
page 594.
The chapter “Timing Constraints (SDC)” on page 935 describes the flow usage of the standard logictest
Tcl procs. The addition of SSN constraints adds only minor changes to the usage of these procs. You still
use the following design flow:

1. In synthesis, invoke the non_modal SDC proc constraints.

2. In layouts, sequentially invoke non_modal SDC constraints followed by some modal logictest
SDC procs.

3. In post-layout STA, time your different logictest modes one at a time, calling the provided
"*ltest_modal*" procs for each mode.
The following sections provide more information about SDC procs with SSN:

Changes to SDC Procs for SSN Timing

SSN/SDC Proc Usage

586 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Changes to SDC Procs for SSN Timing

Changes to SDC Procs for SSN Timing

The presence of SSN adds new constraint procs to the SDC file and modifies some other preexisting
logictest-related SDC procs.
For a detailed description of the procs that are modified for SSN, refer to their original descriptions in the
section “LOGICTEST Instruments” on page 956.

Note:
When you specify the SSH scan_signals_bypass, all modified logictest proc constraints cover
both the SSN mode and the bypass mode timing paths at the same time, so there is no need to
separate your bypass-mode STA from your SSN-mode STA runs.

Summary of New and Modified Tcl Procs for SSN Timing Support
<prefix> :== tessent_set

New SSN-Specific Procs

<prefix>_ltest_ssn

• Applies set_input/output delay constraints on SSN bus ports

• Creates clock groups between SSN clocks, functional clocks, and other DFT clocks

• Adds SSH constraints

• Adds MCP constraints for frequency multiplier and divider nodes

• Accepts "mode" argument with values "shift" or "non_modal"

set_load_unload_timing_options

• The SDC file equivalent of the command of the same name in Tessent Shell
For usage information, refer to the set_load_unload_timing_options command reference page.

• Sets global Tcl timing variable values, which are used in SSN constraints
Modified Preexisting Procs
<prefix>_ltest_create_clocks

• Creates SSN bus clocks on top-level ports and generated clocks within the SSH logic
<prefix>_ltest_non_modal

• Calls <prefix>_ltest_ssn with the argument "non_modal"

<prefix>_ltest_modal_shift

Tessent™ Shell User’s Manual 587

Streaming Scan Network (SSN)
Changes to SDC Procs for SSN Timing

• Calls <prefix>_ltest_ssn with the argument "shift"

<prefix>_ltest_modal_edt_slow_capture

• Calls <prefix>_ltest_ssn with the argument "non_modal"

• Conditionally calls the <prefix>_ltest_relax_xdomain_paths proc, which does the following:

◦ Creates one slow generated clock at the slow_clock input pin of each OCC.

◦ Uses these per-OCC clocks in set_multicycle_path commands to relax the hold of cross-
domain capture paths in slow capture mode. This enables checking the timing of the
scan_enable signal, along with some other paths within the OCCs, while avoiding false hold
timing violations on interdomain paths.

◦ Reads a global Tcl dictionary variable that contains per-OCC generated clock target pins and
identifies the SSH instance in the fan-in for these pins. You can create this dictionary yourself
or extend an existing one if you use custom OCC module instances.
<prefix>_ltest_modal_edt_fast_capture

• Forces the SSH scan_en output signal inactive

<prefix>_ltest_disable

• Blocks ts_tck_tck from propagating to SSH and scannable logic

Note:
This proc still permits ts_tck_tck to propagate to the SSH logic so it can properly time the
serial scan path to and from the IJTAG network. It uses the assumption that timing paths
between the SSH IJTAG registers and the SSH logic always meet a single-cycle path of
ts_tck_tck, with no excessive stress to the quality of results (QoR) for the layout. Clock tree
synthesis can balance both branches of ts_tck_tck within the SSH logic.

New Procs for Chip-Level SSN STA

These are global chip-level versions of the procs in the previous subsection, which apply the same
constraints over all SSN node instances across sub-physical block hierarchies.

• <prefix>_ltest_ssn_with_sub_PBs

• <prefix>_ltest_create_clocks_with_sub_PBs

• <prefix>_ltest_modal_shift_with_sub_PBs

• <prefix>_ltest_modal_edt_slow_capture_with_sub_PBs

• <prefix>_ltest_modal_edt_fast_capture_with_sub_PBs

588 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
SSN/SDC Proc Usage

SSN/SDC Proc Usage

Use SSN-related SDC procs during preparation for synthesis, layout, and STA (both pre- and post-
layout). SSN/SSH implementation has a few important points in which it differs from implementation
without SSN.
Much of this material is covered in greater detail in some portions of the chapter “Timing Constraints
(SDC)” on page 935. However, the following sections describe some details that are specific to SSN/
SSH implementations.

SSN/SDC Constraints for Synthesis

Preparing a block with SSN for RTL-to-gate synthesis does not differ significantly from preparing
a standard EDT-inserted block, as described in “Timing Constraints (SDC)” on page 935. That
section contains example synthesis scripts for third-party tools that can help you understand the SDC
constraints for synthesis. The primary difference from the non-SSN flows for SSN is that you must
specify your SSH scan interface global Tcl variables by calling the set_load_unload_timing_options
proc instead of overriding them directly with a set command in your mainSDC script. Refer to the
set_load_unload_timing_options command reference page for usage information for the command and
Tcl proc.
The following summarizes the usage flow for preparing a block with SSN for synthesis:

1. Load your design.

2. Set your functional constraints.

3. Source the Siemens EDA <design>.sdc file.

4. Call the tessent_default_variables proc.

5. Redefine the global Tessent variables to meet your needs.

6. Call the "set_load_unload_timing_options ‑usage ssn" proc with the proper option values.
This redefines the default SSH global Tcl timing variables.

7. Call the <prefix>_non_modal proc.

This adds SDC for all of your Tessent DFT, including SSN.

8. Add synthesis control commands and run synthesis according to the process in the Timing
Constraints (SDC) chapter.

Tessent™ Shell User’s Manual 589

Streaming Scan Network (SSN)
SSN/SDC Proc Usage

Note:
The <prefix>_non_modal proc declares all SSN bus clocks and SSH-generated scan clocks and
propagates them alongside your functional clocks to all your scannable domains. Such clocks
may expose some invalid shift_capture_clock (SCC)-speed capture paths between otherwise
asynchronous functional domains. Because synthesis usually runs with ideal clocks, these
bogus timing paths are unlikely to fail hold timing; however, it is possible that they could still fail
setup timing if your specified scan frequency is too high. Such a proc is also unusable as-is in
layout without major modification, as described in the subsection "Single-Mode vs Dual-Mode
Constraining in Synthesis/Layout" in the section “LOGICTEST Instruments” on page 956.

SSN/SDC Constraints for Layout

As described in the section “Running Layout With Tessent Shell DFT” on page 943, the
recommendation for layout with Tessent is to load multiple timing mode constraints. This section also
shows the preparation steps required prior to loading the constraints themselves.
If your design includes at least one SSH controller, your clock tree synthesis (CTS) step must include the
CTS exception declarations listed by the tessent_get_cts_skew_groups_dict proc inside your generated
SDC file. These points are located at the base of the SSH edt_clock and shift_capture_clock generated
clock source pins. These prevent the potentially problematic balancing of the SSN datapath clock network
with your potentially very large scan clock network.
The following sections describe how the presence of SSN affects these SDC constraints.
Mode 1: All Tessent DFT Logic Except logictest
proc: <prefix>_non_modal off
Loads non-modal constraints for all Tessent DFT controllers but turns off the logictest DFT
logic, including the ScanHost-generated scan clocks. The maximum-frequency SSN bus clock
is still defined and propagated to all SSN datapath nodes. In this mode, some constraints are
needed to prevent ts_tck_tck from propagating to the scannable domains through the SSH
Streaming-through-IJTAG and "capture" with "tck" logic. For more details, refer to the subsection
“<ltest_prefix>_non_modal” on page 965.
Mode 2: SSN Bus and Modal Shift
proc: <prefix>_modal_shift
Forces the SSH and SSH bypass scan_enable signals to be tied active and covers all SSN bus and
SSH scan interface timing paths. If the SSH supports bypass mode, both bypass and SSH modes are
covered at once.
Mode 3: SSN Bus and Capture With Slow Clock
proc: <prefix>_modal_edt_slow_capture
Adds the same SSN constraints as the <prefix>_modal_shift proc but leaves the SSH scan_en
signals toggling in order to time them using specifications from the set_load_unload_timing_options
command. Optionally relaxes SCC intra- and cross-domain paths to avoid false violations. Its main
function is to cover the scan_en signal timing path.
You can merge the preceding Modes 2 and 3 into a single stage to save on total layout runtime and
complexity. You can do this only if your design meets the following criteria:

590 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
SSN/SDC Proc Usage

• Clock tree synthesis (CTS) has balanced the entire SSH shift_capture_clock source fanout, along
with the same SSH edt_clock source fanout, so that there are no hold issues on same-edge
cross-domain paths.

• All cross-domain paths can still meet setup timing in one SCC cycle. Capture clock waveforms
are assumed to be the same as those of the shift clock.
In this case, you only need to run the <prefix>_modal_edt_slow_capture proc, which then covers both
the shift paths and capture paths in addition to properly timing the scan_enable signal with the specified
number of setup and hold cycles.
For designs with SSN, the <prefix>_ltest_modal_edt_slow_capture proc includes the possibility of
defining one set of generated clocks per OCC in the fanout of each SSH. This results in relaxed hold for
all capture between different OCCs. This also relaxes paths between SIBs or Bscan to or from other OCC
domains. Turn on this feature by defining the following global Tcl variable in your top-level calling script:

set tessent_relax_xdomain_capture_paths 1

Setting this variable means the tool supports hardened OCCs and all-design-level STA. Each generated
clock is defined at the OCC slow_clock input pin, to permit a possible shift_capture_clock from the parent
level to go through the fast_clock pin in multi-level designs. If the OCC persistent slow_clock buffer is
visible in the netlist, the multicycle path constraint is defined on its input pin.
You can modify each generated clock OCC pin by editing a global OCC dictionary, but support for full
custom OCC is not available.
If you do not define this variable, you can also choose from the following options:

• Not relaxing any path—this means closing stuck-at slow capture timing, for setup and hold,
across those generated clocks coming from the OCC

• (default) Applying a global same-edge multicycle path ‑hold to the SSH shift_capture_clocks
Limitation for bypass mode constraints: When the SSH bypass is present, the bypass mode scan_en
and edt_update input ports have no MCP declaration, unlike the SSH local scan_en signal sources,
which MCP constraints relax based on timing specifications from the set_load_unload_timing_options
command. For more details, refer to the section “SSN/SSH SDC Constraint Descriptions” on page 594.
Furthermore, the bypass mode test clock frequency is assumed to be the same as the SSH test clock
frequency, which is unlikely to be the case. If you intend to run the SSH-bypass scan at a slower
frequency than the SSH-based scan, you must override the SSH-bypass test_clock definition in your main
script after calling the procs listed previously. You may also need to add your own MCP declarations for
both scan_en and edt_update top-level ports, as in the following example:

<prefix>_modal_edt_slow_capture
create_clock –period <bypass test_clock period> \
[get_ports test_clock port]
Set_multicycle_path 2 –setup –from [get_ports <scan_enable port>]
Set_multicycle_path 2 –hold –from [get_ports <scan_enable port>]
Set_multicycle_path 2 –setup –from [get_ports <edt_update port>]
Set_multicycle_path 2 –hold –from [get_ports <edt_update port>]

Tessent™ Shell User’s Manual 591

Streaming Scan Network (SSN)
SSN/SDC Proc Usage

SSN/SDC Constraints for STA Signoff on the Current Design

The Tessent logictest DFT STA Signoff flow is described in the sections “Checking Your Functional
Logic Alone” on page 947 and “LOGICTEST Instruments” on page 956. The modal SDC procs
these sections describe also cover both the fast SSN bus logic and the SSH scan interface logic. For
more details on the SSN constraints, refer to the section “SSN/SSH SDC Constraint Descriptions” on
page 594. Therefore, to perform STA signoff on your SSN DFT logic, you must run the same modes and
the same procs as for the EDT/logictest logic; that is, the following:

• Mode shift STA — Call proc <prefix>_modal_shift

• Mode edt_slow_capture STA — Call proc <prefix>_modal_edt_slow_capture

• Mode edt_fast_capture STA — Call proc <prefix>_modal_edt_fast_capture

Note:
As with SSN/SDC Constraints for Layout, if your design meets the configuration conditions
described in the note in that section, you can run only the <prefix>_modal_edt_slow_capture proc
to cover both the shift and edt_slow_capture modes simultaneously.

SSN/SDC Constraints for Hierarchical or Whole-Chip STA

The hierarchical STA flow with SSN stays the same as that described in the section “Hierarchical STA
in Tessent” on page 972 for as long as you use extracted timing models (ETM or .lib) to represent the
timing of child physical blocks (PBs). If your flow requires full or partial child PB instance netlists, you
must replace your call to the usual logictest modal procs with their "*_with_sub_PBs" equivalent; that is,
the following:

• <prefix>_ltest_modal_shift_with_sub_PBs

• <prefix>_ltest_modal_edt_slow_capture_with_sub_PBs

• <prefix>_ltest_modal_edt_fast_capture_with_sub_PBs
These procs include retargeted SDC constraints for all SSN logic inside all of your individual child PBs.
Tessent-generated graybox models include all SSN logic. Without them, the parent SSN bus clock would
enter through the block’s SSN bus pins and propagate directly to the block’s scannable logic. This, in
turn, would overconstrain the child SSH-generated DFT signals. The following is an example of such a
retargeted constraint:

array set tessent_ssh_mapping_with_sub_PBs {

ssh2 top_rtl2_tessent_ssn_scan_host_1_inst
ssh0 corea_i1/corea_rtl2_tessent_ssn_scan_host_1_inst
ssh1 corea_i2/corea_rtl2_tessent_ssn_scan_host_1_inst
}
…
if {$mode eq "shift"} {
set_case_analysis 1 [tessent_get_pins \
$tessent_ssh_mapping_with_sub_PBs(ssh0)/tessent_persistent_cell_scan_en_buf/Y]
set_case_analysis 1 [tessent_get_pins \

592 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
SSN/SDC Proc Usage
$tessent_ssh_mapping_with_sub_PBs(ssh1)/tessent_persistent_cell_scan_en_buf/Y]
set_case_analysis 1 [tessent_get_pins \
$tessent_ssh_mapping_with_sub_PBs(ssh2)/tessent_persistent_cell_scan_en_buf/Y]
}

When you run top-level logictest STA with isolated lower-level PBs, your calling script must also call the
proc <prefix>_ltest_lower_pbs_external_mode. This takes care of constraining the DFT signal and the
OCC logic of the lower PBs. For example, to set the shift STA mode, you must run the following command
sequence:
tessent_set_default_variables
set_load_unload_timing_options <list of timing options>
# (or source the file containing this command)
<prefix>_ltest_modal_shift_with_sub_PBs
<prefix>_lower_pbs_external_mode

Note:
Using *_with_sub_PBs procs is subject to the following limitations:
• These procs create retargeted SSN/SSH SDC constraints for all instances of SSN/SSH
modules in the child PBs; however, all PBs end up using the same set of timing parameter
variables (such as the bus clock, the shift clock frequency, and the number of scan_en/
edt_update extra setup/hold cycles) as the level of the current design. Child PBs may have
been designed and laid out with different parameter sets, with potentially faster internal
shift clocks than their parents. If this applies to any of your PBs, you must manually fix their
associated constraints in your extract_sdc file.
• SSN/SSH constraints are declared for all PB instances, so you must load all of those instances
to avoid errors in reading constraints.
• You cannot set child PBs to internal ltest mode only using the provided procs in the SDC file.
If you need to do this, you can copy your <prefix>_lower_pbs_external_mode proc, change its
name, and manually change the settings of the int_ltest_en and ext_ltest_en signals to put all
child PBs into internal mode.

Tessent™ Shell User’s Manual 593

Streaming Scan Network (SSN)
SSN/SSH SDC Constraint Descriptions

SSN/SSH SDC Constraint Descriptions

The following sections provide more detailed descriptions of SDC constraints for SSN and SSHs.

SSN Bus Clock and SSN Bus Port Timing Constraints

SSN Bus Data Port Delays
SSN Datapath Timing Constraints
SSN FIFO Timing Constraints
SSN ScanHost Timing Constraints and Clock Tree Synthesis

SSN Bus Clock and SSN Bus Port Timing Constraints

The SSN bus clock is declared using variables that contain a period in nanoseconds and a multiplier that
aligns the units with your timing tool.
The following example shows the variables you use to declare the SSN bus clock:

global tessent_ssn_bus_clock_network_period
global time_unit_multiplier
set local_ssn_bus_clock_network_period \
[expr $tessent_ssn_bus_clock_network_period * $time_unit_multiplier]
create_clock <port> -name tessent_ssn_bus_clock_network \
-period $local_ssn_bus_clock_network_period –add

In this example, the tessent_ssn_bus_clock_network_period variable is always given in ns. The

time_unit_multiplier variable converts the ns unit to the one used by the timing tool. For example, set a
value of 1000 if the timing tool uses ps instead of ns. In the Tessent recommended flow, you set the bus
clock network period variable indirectly with the following proc in your primary timing script:

set_load_unload_timing_options –usage ssn –ssn_bus_clock_period

The option values corresponds to the maximum possible SSN network speed across your
entire design, even if your current level test patterns do not require that speed. Refer to the
set_load_unload_timing_options command reference page for more information on using it in the SSN
reference flow.

Note:
If your SSN scan host implementation uses only Streaming-Through-IJTAG, your generated SDC
file does not contain this declaration. For more information about Streaming-Through-IJTAG, refer
to “Streaming-Through-IJTAG Scan Data” on page 535.

SSN Bus Data Port Delays

The SSN data bus port external delays reflect the hard-coded timeplates in Tessent test patterns, relative
to the tessent_ssn_bus_clock_network clock edges.
The SSN test patterns do the following:

594 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
SSN Bus Data Port Delays

• Force SSN bus data primary inputs at 0% of the tester period or 50% of the bus_clock period.
Refer to the following discussion for further explanation.

• Cause the bus clock to rise at 0% of the tester period.

• Measure SSN bus data primary outputs at 0 ns into the next tester period.
This translates to an external delay of zero for both directions.
The first node of an SSN bus might capture its input data at every rising edge of the bus clock or on the
first phase of a multi-phase node. This is the case for nodes of type Pipeline, ScanHost, or Multiplexer, or
one of BusFrequencyMultiplier with its capture_phase property set to "transmitter". For such nodes, the
following is true:

• If the current design level is chip, the SSN patterns force the bus inputs at 50% of the bus clock
period inside the tester period, thus giving a half bus_clock_period margin for both setup and
hold.

• Otherwise, the patterns assume a synchronous data path across the block boundaries and force
the bus inputs at 0% of the tester period.
For all other node types, SSN patterns force the bus inputs at 0% of the tester period.
The 0% output delay permits a full bus clock period to the setup margin of the bus data out loop timing
path, as shown in the figure "Schematic Showing Loop Timing Path for Bus Data Out" in the section
"BusFrequencyDivider" in the Tessent Shell Reference Manual.
The input/output delay constraints include an "‑add_delay" option that enables them to share their primary
pin with functional signals when you apply the non-modal constraints.
The following example illustrates the input/output delay constraints:

set_input_delay 0.0 -add_delay \

-clock tessent_ssn_bus_clock_network \
[tessent_get_ports {gpio[0]}]

set_output_delay 0.0 -add_delay \

-clock tessent_ssn_bus_clock_network \
[tessent_get_ports {gpio[16]}]

At the chip level, the tester directly feeds input/outputs. Therefore, input/output pin delays are based on
the actual pattern waveforms, and no adjustments or virtual clocks are necessary. For a chip, constraints
look like the following:

set_input_delay 0.0 -add_delay \

-clock tessent_ssn_bus_clock_network \
[tessent_get_ports {gpio[1]}]

set_output_delay 0.0 -add_delay \

-clock tessent_ssn_bus_clock_network \
[tessent_get_ports {gpio[6]}]

For a block, in order to account for pre- and post-layout designs with varying ssn_bus_clock latency and
in order to facilitate timing path budgeting, the proc declares a virtual clock and set_input/output_delay
constraints use global user-modifiable Tcl variables, such as in the following example:

Tessent™ Shell User’s Manual 595

Streaming Scan Network (SSN)
SSN Datapath Timing Constraints

proc xxx_ltest_set_timing_variables_default:

set tessent_ssn_bus_input_delay_percentage 25.

set tessent_ssn_bus_output_delay_percentage 25.

proc xxx_ltest_ssn:

set local_ssn_bus_clock_network_period \
[expr $tessent_ssn_bus_clock_network_period * $time_unit_multiplier]
set local_ssn_bus_input_delay
[expr $tessent_ssn_bus_input_delay_percentage/100. * \
$local_ssn_bus_clock_network_period]
set local_ssn_bus_output_delay \
[expr $tessent_ssn_bus_output_delay_percentage/100. * \
$local_ssn_bus_clock_network_period]

set_input_delay $local_ssn_bus_input_delay -add_delay \

-clock tessent_ssn_virtual_bus_clock_network \
[tessent_get_ports {ssn_bus_data_in[0]}]
set_output_delay $local_ssn_bus_output_delay -add_delay \
-clock tessent_ssn_virtual_bus_clock_network \
[tessent_get_ports {ssn_bus_data_out[0]}]

Note:
To accurately reflect the generated test patterns, the following occurs at the chip level:
• If the first SSN datapath node is a receiver_1x_pipeline (which captures at the falling edge of
the ssn_bus_clock), the preceding input delay is set to 0.0 ns.
• If the first node is anything else (that is, captures at the rising edge of the ssn_bus_clock), the
input delay is set to 0.5 × ssn_bus_clock_period.

For a core, the input delay is always set to 0.0 + <an external delay timing budget>, assuming the
following:
The driving node exists inside the chip, either in the parent design or in another core.
SSN source nodes always toggle their output data on the ssn_bus_clock posedge, and full-speed data
paths likely need balanced source/destination clocks.
If the datapath crosses a non-balanced clock, it does so through an SSN divider/multiplier combination.
This combination is less sensitive to these input/output delay constraints, because it relaxes with
additional multicycle path (MCP) constraints.

SSN Datapath Timing Constraints

Some sections of the SSN datapath may run with a bus data rate that is a fraction of the bus clock speed,
such as at half- or quarter-speed, thus behaving as multicycle paths (MCPs) across SSN nodes. Such
paths occur when inserting SSN nodes of the types BusFrequencyDivider, BusFrequencyMultiplier, or
OutputPipeline in your datapath specifications.
For more details about these nodes and their usage, refer to the section "BusFrequencyDivider" in the
Tessent Shell Reference Manual.
The three previously mentioned nodes (BusFrequencyDivider, BusFrequencyMultiplier, and
OutputPipeline) intercept the data bus bits with rows of flops that capture or update all bus data bits

596 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
SSN Datapath Timing Constraints
at a specified phase of the bus clock. In the SDC file, the phase of each node is represented by two
numbers "(n m)" where m is the number of bus clock cycles for a single data cycle. For example, consider
a quarter-speed SSN data bus section. The section may require MCPs between the following types of
nodes:

• A BusFrequencyDivider node with a (1 4) phase

This means that the divider latches its output data at the beginning of the first (1) cycle for a
duration of four (4) cycles.

• A BusFrequencyMultiplier node with a (3 4) phase

The specified phase number (3) represents the clock cycle number that the input data is latched
at the beginning of. The output data rate of a multiplier always equals the clock rate.

• An OutputPipeline node with a (1 4) phase

The node features a single pipeline flop row that captures at the beginning of the first (1) cycle of
four (4).
As another example, a bus datapath between a (1 4) divider and a (3 4) multiplier ends up with timing
margins of two cycles of setup and two cycles of hold, making that combination suitable for data handoff
between two skewed CTS regions:

# -----------------------------------------------------------------------
# From bus_frequency_divider (phase 1 4) to bus_frequency_multiplier
# (phase 3 4)
set_multicycle_path -setup 2 -start \
-from [tessent_get_cells <divider node instance>/datapath/r1*] \
-to [tessent_get_cells <multiplier node instance>/datapath/r0*]
set_multicycle_path -hold 3 -start \
-from [tessent_get_cells <divider node instance>/datapath/r1*] \
-to [tessent_get_cells <multiplier node instance>/datapath/r0*]

A bus datapath between the previously referenced (1 4) divider node and a (1 4) output pipeline node
features timing margins of four cycles of setup and zero cycles of hold, thus requiring balanced source
and destination clocks:

# -----------------------------------------------------------------------
# From bus_frequency_divider (phase 1 4) to output_pipeline (phase 1 4)
set_multicycle_path -setup 4 -start \
-from [tessent_get_cells <divider node instance>/datapath/r1*] \
-to [tessent_get_cells <multiplier node instance>/datapath/r0*]
set_multicycle_path -hold 3 -start \
-from [tessent_get_cells <divider node instance>/datapath/r1*] \
-to [tessent_get_cells <multiplier node instance>/datapath/r0*]

Datapaths from SSN bus output ports of a (1 4) OutputPipeline node also feature four cycles of setup
margin, as shown in the figure "Output Data Slow Down Using BusFrequencyDivider Node" in the section
"BusFrequencyDivider" in the Tessent Shell Reference Manual, because the test patterns capture the bus
data at the rising edge of Phase 1, leaving all four bus cycles for data to close its output timing loop:

Tessent™ Shell User’s Manual 597

Streaming Scan Network (SSN)
SSN Datapath Timing Constraints

# -----------------------------------------------------------------------
# From output_pipeline (phase 1 4) to output bus ports
set_multicycle_path -setup 4 -start \
-from [tessent_get_cells <divider node instance>/datapath/r1*] \
-to [tessent_get_ports <list of output bus ports>]
set_multicycle_path -hold 3 -start \
-from [tessent_get_cells <divider node instance>/datapath/r1*] \
-to [tessent_get_ports <list of output bus ports>]

More subtle MCP constraints are required when handling datapath sections that run across bus clocks
that operate at frequencies that are ratios of each other. This could result in, for example, a (1 2) divider
fanning out to a (3 4) multiplier, which implies that the destination multiplier is clocked at double the
frequency of the source divider. In such cases, the MCP constraint always sets its setup and hold number
of cycles relative to the faster of the two clocks, using either the ‑start or the ‑end option:

# -----------------------------------------------------------------------
# From bus_frequency_divider (phase 1 2) to bus_frequency_multiplier
# (phase 3 4)
set_multicycle_path -setup 2 -end \
-from [tessent_get_cells <divider node instance>/datapath/r1*] \
-to [tessent_get_ports <multiplier node instance>/datapath/r0*]
set_multicycle_path -hold 2 -end \
-from [tessent_get_cells <divider node instance>/datapath/r1*] \
-to [tessent_get_ports <multiplier node instance>/datapath/r0*]

Input and output pins of child physical blocks may also include phases if they internally connect to either
SSN multiplier or divider nodes. These phases are reported in the module description of their .icl file.
Because the internal cells of a physical block are not normally visible to the parent SDC, you must set
MCP constraints using the ‑through switch with the PB boundary pins, as in the following example:

# -----------------------------------------------------------------------
# From PB output pins (phase 1 2) to PB input pins (phase 0.5 1)
set_multicycle_path -setup 1 -start \
-through [tessent_get_pins <PB1 list of bus data output pins> \
-through [tessent_get_pins <PB2 list of bus data input pins>]
set_multicycle_path -setup 1 -start \
-through [tessent_get_pins <PB1 list of bus data output pins> \
-through [tessent_get_pins <PB2 list of bus data input pins>]

The extract_sdc command itself actively traces the .icl files of the design to find which actual SSN node
is connected to which other SSN nodes and whether phase specifications are involved. Such tracing
enables handling of bus networks with multiplexer nodes and connections between partial lists of SSN
bus ports or subphysical block pins, which can further complicate the list of MCPs. For the sake of clarity
and self-documentation, the SDC file reports the traced list of connections under a comment banner
labeled "SSN list of node connections." This banner shows all connections, including those not involving
clock phases, as in the following example:

#----------------------------------------------------------------------
# SSN list of node connections
# output_pipeline 'top_rtl2_tessent_ssn_out_pipe_out_inst'
# --> SSN Bus Data Outputs
# bus_frequency_divider 'top_rtl2_tessent_ssn_bus_freq_div_1_inst'
# --> output_pipeline 'top_rtl2_tessent_ssn_out_pipe_out_inst'

598 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
SSN FIFO Timing Constraints
# scan_host 'top_rtl2_tessent_ssn_scan_host_1_inst'
# --> bus_frequency_divider 'top_rtl2_tessent_ssn_bus_freq_div_1_inst'
# pipeline 'top_rtl2_tessent_ssn_pipe_2_inst'
# --> scan_host 'top_rtl2_tessent_ssn_scan_host_1_inst'
# bus_frequency_multiplier 'top_rtl2_tessent_ssn_bus_freq_mult_1_inst'
# --> pipeline 'top_rtl2_tessent_ssn_pipe_2_inst'
# physical_block 'corea_i1' (launching phase = 1/2)
# --> bus_frequency_multiplier 'top_rtl2_tessent_ssn_bus_freq_mult_1_inst'
# physical_block 'corea_i2' (launching phase = 1/2)
# --> physical_block 'corea_i1' (strobing phase = 0.5/1)
# pipeline 'top_rtl2_tessent_ssn_pipe_1_inst'
# --> physical_block 'corea_i2' (strobing phase = 0.5/1)
# SSN Bus Data Inputs
# --> pipeline 'top_rtl2_tessent_ssn_pipe_1_inst'
#----------------------------------------------------------------------

Datapath instances retimed using a trailing edge (TE) register at their inputs have a multicycle path timing
exception from the reset register that controls the datapath registers to the TE retiming registers. This
includes the Receiver1XPipeline, and it also includes the FIFO and BusFrequencyDivider instances if
their datapaths are retimed with TE registers. The input data for these instances is held at zero during
reset.

# Reset of the TE datapath retiming register can have a setup MCP of 2 because
# the initial data in this register is flushed and not observed during test.
# The data input of the registers is also zero during reset.
set_multicycle_path -setup 2 \
-from [tessent_get_cells \
top_tessent_ssn_receiver_1x_pipe_in_inst/fsm/bus_sync_reset_ff*] \
-to [tessent_get_cells \
top_tessent_ssn_receiver_1x_pipe_in_inst/datapath/r0_n*]
set_multicycle_path -hold 1 \
-from [tessent_get_cells \
top_tessent_ssn_receiver_1x_pipe_in_inst/fsm/bus_sync_reset_ff*] \
-to [tessent_get_cells \
top_tessent_ssn_receiver_1x_pipe_in_inst/datapath/r0_n*]

SSN FIFO Timing Constraints

An SSN FIFO advantageously replaces a combination of BusFrequencyDivider and
BusFrequencyMultiplier nodes in cases where the clock domain handoff can occur within a single
physical partition.
For a full description of the FIFO circuit and node definition usage, refer to the section "Fifo" in the
Tessent Shell Reference Manual. This section also includes information about how Tessent Shell
identifies which clocks are associated with the first and last sequential elements on the SSN datapath for
SDC extraction when a Fifo node is present.
A Fifo node includes an input register for storing input packets, similar to that of a BusFrequencyDivider,
and it selects the output packet based on the phase counter value, similar to the operation of a
BusFrequencyMultiplier. Similar to datapaths between BusFrequencyDivider and BusFrequencyMultiplier
explained in the section “SSN Datapath Timing Constraints” on page 596, a set_multicycle_path
declaration can relax FIFO internal paths from the input register. The setup and hold parameters for this
declaration depend the following property values inside the DftSpecification/SSN/Datapath/Fifo wrapper:

Tessent™ Shell User’s Manual 599

Streaming Scan Network (SSN)
SSN FIFO Timing Constraints

• frequency_ratio

• in_clock_to_out_clock

• in_clock_to_out_clock_skew_programmable
You can think of the last two properties as defining a "deskewing" mode.
Data output from the FIFO input register remains stable for a number of clock cycles equal to the value
of the FIFO frequency_ratio property. The FIFO output register captures this data either in the middle of
these cycles (when in_clock_to_out_clock_skew is early_or_delayed) or at the end of these cycles (when
in_clock_to_out_clock_skew is delayed_only). Refer to the figures "Waveform for FIFO early_or_delayed
Configuration" and "Waveform for FIFO delayed_only Configuration" in the "Fifo" reference page in
the Tessent Shell Reference Manual for examples of these capture cycles. Because of this, both of
your SDC FIFO multicycle path (MCP) constraint ‑setup and ‑hold parameters depend on the FIFO
frequency_ratio and in_clock_to_out_clock_skew parameters. You can adjust them at run time if the
in_clock_to_out_clock_skew_programmable parameter is on.
In the SDC, the setup and hold calculations are done explicitly using intermediate Tcl variables.
If you set in_clock_to_out_clock_skew_programmable to "on", the SDC enables you to dynamically select
the deskewing mode just before applying the SDC in the timing tool. For each such FIFO instance in your
design, select the deskewing mode by defining the Tcl variable tessent_ssn_fifo_deskew_setting(sfifo<n>)
in your primary script. This variable name is mapped; refer to the primary calling script in the Examples
section in this topic to understand how to use these variables. The in_clock_to_out_clock_skew property
determines the default deskew mode when you do not set these variables.
The following figure illustrates how the MCP is applied in a FIFO.

600 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
SSN FIFO Timing Constraints

Figure 146. FIFO MCP Example

Examples
Example of FIFO Settings in Your Primary Calling Script
The following example shows how to use Tcl variables in the primary calling script to set up the FIFO and
control programmable skew settings:

tessent_set_default_variables
tessent_ssn_fifo_deskew_setting(sfifo0) delayed_only
tessent_ssn_fifo_deskew_setting(sfifo1) early_or_delayed
tessent_ssn_fifo_deskew_setting(sfifo2) delayed_only
tessent_set_non_modal
# this proc calls the tessent_set_ltest_ssn proc, which appears in the
# next example section

Examples of FIFO SDC File Contents

The following is an example of content appearing in the SDC proc tessent_set_default_variables:

array set tessent_sfifo_mapping {

sfifo0 top_rtl2_tessent_ssn_fifo_1_inst
sfifo1 core1/core_rtl2_tessent_ssn_fifo_1_inst
sfifo2 core2/core_rtl2_tessent_ssn_fifo_1_inst
}

The following is an example of content appearing in the SDC proc tessent_set_ltest_ssn:

Tessent™ Shell User’s Manual 601

Streaming Scan Network (SSN)
SSN ScanHost Timing Constraints and Clock Tree Synthesis

global tessent_ssn_fifo_deskew_setting
array set sfifo_setup_multiplier {delayed_only 1 early_or_delayed 0.5}
# sfifo0:
# frequency_ratio : 4
# in_clock_to_out_clock_skew: delayed_only
# in_clock_to_out_clock_skew_programmable: on
set deskew_setting delayed_only

if {[info exists tessent_ssn_fifo_deskew_setting(sfifo0)]} {

set deskew_setting $tessent_ssn_fifo_deskew_setting(sfifo0)
}

set frequency_ratio 4
set_multicycle_path \
-setup [expr int($frequency_ratio* $sfifo_setup_multiplier($deskew_setting))] \
-from [tessent_get_cells $tessent_sfifo_mapping(sfifo0)/datapath/fifo_reg*] \
-to [tessent_get_cells $tessent_sfifo_mapping(sfifo0)/datapath/bus_data_out*]
set_multicycle_path \
-hold [expr $frequency_ratio - 1] \
-from [tessent_get_cells $tessent_sfifo_mapping(sfifo0)/datapath/fifo_reg*] \
-to [tessent_get_cells $tessent_sfifo_mapping(sfifo0)/datapath/bus_data_out*]

Note:
The preceding constraints repeat for sfifo1 and sfifo2, but with variations for the actual MCP
constraints that depend on the DftSpecification property settings for these FIFOs.

Note:
The section in bold in the previous example is present only when programmable skew is enabled;
that is, in_clock_to_out_clock_skew_programmable is set to "on".

SSN ScanHost Timing Constraints and Clock Tree Synthesis

The ScanHost node generates the scan control and data signals when it drives the logictest modules of a
block. It generates all of these signals from the SSN bus_clock.
As a prerequisite for the SSH SDC descriptions in this section, it is recommended that you clearly
understand the SSH scan interface operation and features described in the section "ScanHost Scan
Interface Operation and Timing Requirements" of the "ScanHost" reference page in the Tessent Shell
Reference Manual.

SSH Scan Clocks

A given Tessent test SSN scan pattern may drive the SSN bus clock port with one of three different
frequencies. The frequency depends on whether the ScanHost is bypassed or used for scan with gated or
with divided shift clocks. To precisely determine the timing that the hardware implements, the SDC needs
to create three clocks on that port. The following figure shows all root clocks and generated clocks that
may exist in the SDC.

602 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
SSN ScanHost Timing Constraints and Clock Tree Synthesis

Figure 147. SSH Clock Signal Generation

Call the set_load_unload_timing_options command to configure the SDC clock and control signal
timing parameters, and to configure pattern generation so that the parameters of the generated
patterns are consistent with those used during timing closure and analysis. The following table lists
set_load_unload_timing_options arguments that define Tcl variables used in SDC. If your primary timing
script does not explicitly set these options, then the tool uses the default values from the table.

Table 28. set_load_unload_timing_options Arguments and SDC Variables

Option SDC Timing Variable Default

‑ssn_bus_clock_period tessent_ssn_bus_clock_network_period 2.5 ns

‑shift_clock_period tessent_ssn_bus_clock_scan_slow_period 10.0 ns

‑scan_en_setup_extra_cycles tessent_scan_en_setup_extra_cycles 1

‑scan_en_hold_extra_cycles tessent_scan_en_hold_extra_cycles 1

‑edt_update_setup_extra_cycles tessent_edt_update_setup_extra_cycles 1

‑edt_update_hold_extra_cycles tessent_edt_update_hold_extra_cycles 1

The first SSN bus clock is called ssn_bus_clock_network (red dot in Figure 147). It times the SSN
network operation at its maximum possible datapath speed, whether or not the ScanHost node is active.
When the ScanHost node is active, the SSN bus clock pin generates the shift_capture_clock and the
edt_clock used to operate the scan circuitry. One scan bit per chain gets shifted in per SSN packet. If the
SSN packet is small enough to occupy less than two bus clock cycles on the network, the scan clocks
can be generated from the SSN bus_clock using a clock gater. The test patterns then adjust the SSN
bus clock frequency to match the required shift_clock_period. However, when the SSN packet is large
enough to occupy a minimum of N bus clock cycles on the network, a faster frequency clock is applied to
the ssn_bus_clock pin and is divided to generate the shift clocks using a clock divider flop, maintaining
as much as possible a fifty-percent duty cycle. Because these two clock paths differ slightly, both must

Tessent™ Shell User’s Manual 603

Streaming Scan Network (SSN)
SSN ScanHost Timing Constraints and Clock Tree Synthesis
be covered in SDC and STA, requiring the SDC to create one generated clock for the gated clock and
another for the divided clock.
When the test patterns generate the scan clocks using a clock gater, they must increase the SSN bus
clock period to be as large as the shift clock period, which defaults to 10 ns. The SDC version of the SSN
bus clock created at the shift_clock_period is called ssn_bus_clock_scan_slow (green dot labeled 1 in
Figure 147) and is referenced as the source of the generated clocks ssn_shift_capture_clock_gated and
ssn_edt_clock_gated, which are defined on the outputs of the edt_clock_cg and shift_capture_clock_cg
persistent cells (green dots 2 and 3 in Figure 147).
When the test patterns generate the scan clocks using a clock divider, another SDC clock called
ssn_bus_clock_scan_fast is required (blue dot 1 in Figure 147) and becomes the ‑master option of the
divided_by N generated clocks called ssn_shift_capture_clock_div and ssn_edt_clock_div, which are
defined on the output of the edt_clock_div and shift_capture_clock_div cells (blue dots 2 and 3 in Figure
147).
The SDC aims to set the period of the ssn_bus_clock_scan_fast clock to exactly half that of the
ssb_bus_clock_scan_slow clock. Then it applies a "divided_by 2" generated clock at the output of the
clock divider flop. This enables all scan timing paths depending on that divided clock to be constrained
to their tightest possible limits. If the target ssn_bus_clock_scan_fast period would actually make the
SSN bus exceed its maximum speed, then it is instead made equal to the ssn_bus_clock_network period.
Consider an example where the ssn_bus_clock period is 2.5 ns and the shift_clock period is 10 ns. In this
case, the SDC would set the ssn_bus_clock_scan_fast period to 10 ns / 2 = 5 ns. If the ssn_bus_clock
period were instead set to 6 ns, then the SDC would set the ssn_bus_clock_scan_fast period to the
same 6 ns, making the divided generated scan clock slower than the target shift_clock; this is acceptable
because it correctly reflects the reality of the test patterns.

Note:
In practice, the divided clock frequency ratio might often exceed 2, because that value depends
on the size of the SSN bus packet. The packet size can be quite large if many SSHs are driven in
parallel or if the number of EDT channels greatly exceeds the SSN bus width.

Even more clock declarations are required if the SSH supports the optional scan bypass
mode. These clocks are represented by the brown dots in Figure 147. Both the *edt_clock and
*ssh_shift_capture_clock are divided_by 1 versions of the test_clock. For simplification of the constraints,
the generated SDC file assumes a test_clock period that always matches the value specified by the
"set_load_unload_timing_options ‑shift_clock_period" command, even though the latter value ideally
applies only to the SSN scan mode and not the bypass mode.
The preceding clocks belong to clock groups that correspond to their dot colors in Figure 147. Red,
blue, green, and brown clocks never run at the same time. Therefore, the SDC declares them as
‑physically_exclusive. All such clocks are also asynchronous to all functional domain clocks, because both
clock types may interact at the same time on the pre-OCC branches during scan. The following is an
excerpt from a sample design:

Figure 148. SSH Clock Group Constraints

scan_en and edt_update Signal Timing

The following figure shows the SSH circuit that generates the scan_en and edt_update signals.

604 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
SSN ScanHost Timing Constraints and Clock Tree Synthesis

Figure 149. SSH scan_en and edt_update Generation Circuit

The SSH generates the edt_update signal with a negedge flop (brown dot 3) when
bus_clock_period = scan_clock_period to provide negedge retiming to its destination EDT controller’s
posedge flops. The posedge flops run off the late edt_clock relative to the bus_clock. When edt_clock is
divided, on the other hand, a posedge source flop (brown dot 2) can properly toggle the edt_update signal
0.5 edt_clock cycles before and after the posedge of the destination flop.
Although the scan_en signal may propagate to either posedge or negedge scannable flops on a delayed
SCC clock tree, the fact that SCC is gated while scan_en toggles makes both its setup and hold timing
safer without needing to rely on a negedge flop source like for edt_update. Furthermore, the scan_en
setup margin to negedge flops gets a half-cycle bonus, because the first SCC falling edge after a scan_en
transition always occurs after the first rising edge. The following figure shows the margin definitions.

Figure 150. scan_en Margin Definition Diagram

By default, although these signals show some very safe setup and timing margins, you can still extend
them by calling the set_load_unload_timing_options command. As discussed previously, this proc sets
several global Tcl variables used in timing exceptions discussed in the following information.
In the Tessent SDC file, the hold and setup margins of all MCP constraints are derived dynamically from
the variable values in Table 28. The following excerpt from an SDC file shows how all setup and hold
margins are calculated. In this excerpt, the Tcl variable names intentionally match the setup and hold
margin names shown in Figure 150. As previously mentioned, it is helpful when reading this excerpt to
remember that the divided scan clock is a "divided_by 2" version of the ssn_bus_clock_scan_fast clock.

Tessent™ Shell User’s Manual 605

Streaming Scan Network (SSN)
SSN ScanHost Timing Constraints and Clock Tree Synthesis

# Scan_en to gated scan clocks:

set seSetupPos [expr 1 + $tessent_scan_en_setup_extra_cycles]
set seHoldPos [expr 1 + $tessent_scan_en_hold_extra_cycles]
set seSetupNeg [expr 1 + $seSetupPos]
set seHoldNeg $tessent_scan_en_hold_extra_cycles
# Scan_en to divided by 2 scan clocks
set seSetupPos_div [expr $seSetupPos * 2]
set seHoldPos_div [expr $seHoldPos * 2]
set seSetupNeg_div [expr $seSetupPos_div + 1]
set seHoldNeg_div [expr $seHoldPos_div - 1]
# edt_update to gated scan clocks:
set setup [expr 1 + $tessent_edt_update_setup_extra_cycles]
set hold $tessent_edt_update_hold_extra_cycles
# edt_update to divided scan clocks:
set setup [expr 1 + $tessent_edt_update_setup_extra_cycles * 2]
set hold [expr 1 + $tessent_edt_update_hold_extra_cycles * 2]

The following is an example of how the preceding $setup and $hold Tcl variables are typically used in the
SDC file MCP constraints:

set_multicycle_path -setup $setup -start \

-from [tessent_get_cells $tessent_ssh_mapping(ssh0)/clock_gen/edt_update_delayed*] \
-to [tessent_get_clocks tessent_ssh*_div]
set_multicycle_path -hold [expr $setup-1 + $hold] -start \
-from [tessent_get_cells $tessent_ssh_mapping(ssh0)/clock_gen/edt_update_delayed*] \
-to [tessent_get_clocks tessent_ssh*_div]

To help you visualize these constraints, the following figures show some actual simulation results of the
timing of the scan_en and edt_update signals relative to the SSN bus and SSH scan clocks:

Figure 151. Gated Scan Clocks With All *extra_cycle* Variables Set to 1 (Default)

The following figure is the same as the previous, but the *extra_cycle* variables are set to zero. This
results in shorter setup and hold margins.

Figure 152. Gated Scan Clocks With All *extra_cycle* Variables Set to 0

606 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
SSN ScanHost Timing Constraints and Clock Tree Synthesis

In this figure, due to some inner SSH logic requirements, the scan_en setup and hold paths get some
bonus margins over the gated clocks case.

Figure 153. Divided Shift Clocks With Ratio of 4 and *extra_cycle* Variables at 0

Figure 154. Divided Shift Clocks With Ratio of 4 and *extra_cycle* Variables at 1

Scan Chain Interface Timing

The SSH scan chain interface circuit appears in the following figure. Given the many different clocks and
the two operation modes involved, this circuit requires many timing exceptions of different natures, such
as set_disable_timing, set_false_path, and set_multicycle_paths.

Figure 155. SSH Scan Chain Interface Circuit

Tessent™ Shell User’s Manual 607

Streaming Scan Network (SSN)
SSN ScanHost Timing Constraints and Clock Tree Synthesis

The following describes how this circuit operates:

• Persistent cells appear with red borders.

• All clock names appear without the "tessent_" prefix.

• The two flops on the right-hand side represent the scan chains. Their SI input comes from the
SSH to_scan_in* pins, and their SO outputs go back to the SSH through the from_scan_out*
pins.

• Direct loopback paths exist in some modes between the SSH to_scan_in* and from_scan_out*
pins.

• Logic elements that are active only during scan with gated shift clocks are colored green.

• Logic elements that are active only during scan with divided shift clocks are colored blue.

• The from_scan_out*_and (blue) cell strobes the SO data of the returning chain when running with
divided shift clocks, at the last of the N cycles of the divided clock. It is transparent when running
with the gated clock.

• Chains may feature either a trailing edge (TE) or leading edge (LE) chain terminating SO flop.

◦ When running with gated shift clocks, the from_scan_out_ret_n (green) flop captures TE SO
data.

◦ With both gated and divided clocks, the from_scan_out_ret_p flop captures the LE SO data.

◦ With divided clocks, the SSH control logic directly captures TE SO data through the
from_scan_out_mux.

• The tck_clock_gater (purple) cell feeds a gated version of ts_tck_tck to the SSH logic when it
runs in Streaming-Through-IJTAG mode.
Scan Chain Interface Timing Exceptions

• The clock tessent_ssn_bus_clock_scan_fast* serves as a master clock for creating the

SSH divided clock and for timing the interactions of the tessent_ssh*_div (divided) clocks
with the posedge flops of the SSH scan interface circuit. However, because all of the
SSH controller’s intradomain paths can be timed to their maximum speeds with the clock
tessent_ssn_bus_clock_network*, the extract_sdc command can declare the following:

set_false_path -from [tessent_get_clocks tessent_ssn_bus_clock_scan_fast*] \

-to [tessent_get_clocks tessent_ssn_bus_clock_scan_fast*]

• All of the preceding SSH scan interface negedge (green) flops are used only in combination with
the slower tessent_ssn_bus_clock_scan_slow and tessent_ssh*_gated clocks:

set_false_path -fall_from [tessent_get_clocks tessent_ssn_bus_clock_scan_fast*]

set_false_path -fall_to [tessent_get_clocks tessent_ssn_bus_clock_scan_fast*]

608 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
SSN ScanHost Timing Constraints and Clock Tree Synthesis

• Similarly, all green flops are active only when a slow shift-speed clock is injected on the
ssn_bus_clock port. Therefore, the resulting half-cycle paths are all false with regard to
the maximum speed of the tessent_ssn_bus_clock_network. The simpler -fall_from/-fall_to
tessent_ssn_bus_clock_network constraint cannot be used, because it might also kill some valid
half-cycle timing paths inside the SSN 1x receiver pipelining nodes.

set negedge_flops_list [list \

<SSH instance>/clock_gen/edt_update_ret* \
<SSH instance>/datapath/to_scan_in*_ret_not_for_div* \
<SSH instance>/datapath/from_scan_out*_ret_n* \
<SSH instance>/datapath/last_in_bits_in_current_bus_word_ret* \
]
set_false_path -from [tessent_get_clocks "tessent_ssn_bus_clock_network*"] \
-to [tessent_get_cells $negedge_flops_list]
set_false_path -to [tessent_get_clocks "tessent_ssn_bus_clock_network*"] \
-from [tessent_get_cells $negedge_flops_list]

• The SSH with the posedge flop that sources the to_scan_in signal is only active with the divided
clock and toggles in the middle of the tessent_ssh*_div clock cycle in order to act as a retiming
scan element.

set_false_path -from [tessent_get_cells \

<SSH instance>/datapath/to_scan_in*_ret_for_div*] \
-to [tessent_get_clocks tessent_ssh*_gated]
set_multicycle_path -hold 1 -start \
-from [tessent_get_cells \
<SSH instance>/datapath/to_scan_in*_ret_for_div*] \
-to [tessent_get_clocks tessent_ssh*_div]

• The from_scan_out logic constraints are more complex than other constraints because they
support scan SO paths coming from either leading-edge (LE) or trailing-edge (TE) flops.

# With a gated clock, all chain SO are captured by a single strobing flop. All
# other paths are false.
set_false_path -from [tessent_get_clocks tessent_ssh*_gated] \
-through [tessent_get_pins \
<SSH instance>/datapath/tessent_persistent_cell_from_scan_out*_mux*/Y]

# With a gated clock, the chain SO TE flop is captured by the TE strobe register
set_false_path -fall_from [tessent_get_clocks tessent_ssh*_gated] \
-to [tessent_get_cells \
<SSH instance>/datapath/from_scan_out*_ret_p*]
# With a gated clock, the chain SO LE flop is captured by the LE strobe register
set_false_path -rise_from [tessent_get_clocks tessent_ssh*_gated] \
-to [tessent_get_cells \
<SSH instance>/datapath/from_scan_out*_ret_n*]

# Divided clock to fast clock logic inside the SSH

set_multicycle_path -setup 2 -end \
-from [tessent_get_clocks tessent_ssh*_div] \
-through [tessent_get_pins \

Tessent™ Shell User’s Manual 609

Streaming Scan Network (SSN)
SSN ScanHost Timing Constraints and Clock Tree Synthesis
<SSH instance>/tessent_persistent_cell_from_scan_out*_and/A0] \
-to [tessent_get_clocks tessent_ssn_bus_clock_scan_fast_0]
set_multicycle_path -hold 1 -end \
-from [tessent_get_clocks tessent_ssh*_div] \
-through [tessent_get_pins \
<SSH instance>/tessent_persistent_cell_from_scan_out*_and/A0] \
-to [tessent_get_clocks tessent_ssn_bus_clock_scan_fast_0]

• For SSH loopback logic, only valid paths exist inside the SSH controller, and they always meet
one cycle of the slow shift clock with zero hold, so they can be accurately timed using only the
SSN slow scan clock. However, because the SSH constraints are multimode, the absence of
case_analysis settings enable unexpected invalid paths to pass through the SSH*_bypass ports,
coming from different irrelevant clocks, including those from other SSHs. Such clocks must be
disabled.

set non_ssn_slow_clocks [remove_from_collection [all_clocks] \

[tessent_get_clocks tessent_ssn_bus_clock_scan_slow*]]
set_false_path \
-from $non_ssn_slow_clocks \
-through [tessent_get_pins \
<SSH instance>/tessent_persistent_cell_to_scan_in*_buf/Y] \
-through [tessent_get_pins \
<SSH instance>/tessent_persistent_cell_from_scan_out*_and/A0]
set_false_path \
-through [tessent_get_pins \
<SSH instance>/tessent_persistent_cell_to_scan_in*_buf/Y] \
-through [tessent_get_pins \
<SSH instance>/tessent_persistent_cell_from_scan_out*_and/A0] \
-to $non_ssn_slow_clocks

• Disable false paths going through SSH scan control signals to external EDT pipelining flops,
which are only used when the SSH is inactive.

set_false_path \
-from [tessent_get_clocks tessent_ssn_bus_clock*] \
-through [tessent_get_pins \
<SSH instance>/tessent_persistent_cell_from_scan_out*_and/*] \
-to [tessent_get_clocks tessent_ssh*]

® ®
• Some multiplexers switch clocks statically. In Synopsys PrimeTime products, the following
command suppresses noisy clock gating check warnings, such as the PrimeTime PTE-060
warning:

set_disable_clock_gating_check [tessent_get_cells <SSH instance>/*clock_mux]

• The setup margin of full- and half-cycle ijtag_tck timing paths is relaxed with a two-cycle
multicycle path (MCP), and the hold margin is set to false.

610 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
SSN ScanHost Timing Constraints and Clock Tree Synthesis

# Static SSH TDR registers to SSH mission logic are all stable during test.
# Both source and destination are in the fanout of the ijtag clock.
set ssh_flops [tessent_get_flops \
[list $tessent_ssh_mapping(ssh0)/* \
$tessent_ssh_mapping(ssh0)/*/* \
$tessent_ssh_mapping(ssh0)/*/*/*] \
-filter {is_hierarchical==false}]
set ssh_ijtag_flops [tessent_get_flops \
$tessent_ssh_mapping(ssh0)/ijtag_registers/* \
-filter {is_hierarchical==false}]
set ssh_mission_flops [remove_from_collection $ssh_flops $ssh_ijtag_flops]
set_multicycle_path 2 -from $ssh_ijtag_flops -to $ssh_mission_flops
set_false_path -hold -from $ssh_ijtag_flops -to $ssh_mission_flops

• The following provides various additional necessary constraints that may be present depending
on the SSH options:

# Block ts_tck_tck used as capture clock

set_disable_timing [tessent_get_pins \
<SSH instance>/clock_gen/clock_signals/tessent_persistent_cell_*_or2/<A1>

# Prevent false paths to scannable tessent memory_bist logic, which uses

# ts_tck_tck in setup mode.
set_false_path -from [tessent_get_clocks $tessent_clock_mapping(ts_tck_tck)]\
-through [tessent_get_pins \
<SSH instance>/tessent_persistent_cell_scan_en_buf/<out>]

# ssh0 enable_sync is static during test and fans out to ltest logic through the
# scan_en and edt_update signals.
set_false_path -from [tessent_get_cells <SSH instance>/fsm/enable_sync*] \
-to [tessent_get_clocks "tessent_ssh*_gated tessent_ssh*_div"]

# bscan_capture_shift_clock is in the same clock group as ts_tck_tck,and timing

# paths from static SSH IJTAG TDRs may reach the bscan cells through the
# SSH/scan_en signal.
if {[sizeof_collection [tessent_get_clocks bscan_capture_shift_clock -quiet]]} {
set_false_path -from [tessent_get_cells <SSH instance>/ijtag_registers/*_reg] \
-to [tessent_get_clocks bscan_capture_shift_clock]
}

SDC Constraints and the Optional Clock Shaper Cell

The optional use_clock_shaper_cell property in the SSH configuration wrapper specifies to use library
clock shaper cells instead of flip-flops and clock gaters to generate SSH output scan clocks such as
edt_clock, shift_capture_clock, and test_clock. You can program a clock shaper cell either to simply gate
its incoming clock input or to divide it by a factor of N with a 50% duty cycle, while maintaining a constant
insertion delay across all selected ratios. For more details about the clock shaper cell and its impact on
the SSH SDC, refer to "ScanHost" in the Tessent Shell Reference Manual.
When you specify the clock shaper, the Tessent SDC provides two generated clocks for each clock
shaper in the SSH: a gated clock and a divided clock, which enable accurate timing of the design.

Tessent™ Shell User’s Manual 611

Streaming Scan Network (SSN)
SSN ScanHost Timing Constraints and Clock Tree Synthesis

You can simplify the clock definitions by specifying that the SSH generates only the test_clock source,
which in turn feeds the external edt_clock and shift_capture_clock clock gaters. Refer to the figure
"ScanHost Node Sourcing test_clock With Following DFT Signal Clock Gater" in the ScanHost reference
page in the Tessent Shell Reference Manual. The following shows how the SDC creates the gated clock
and divided clock from their master clock:

# Master clock
create_clock [tessent_get_ports ssn_bus_clock] \
-name tessent_ssn_bus_clock_scan_slow_0 \
-period $local_ssn_bus_clock_scan_slow_period -add
create_clock [tessent_get_ports ssn_bus_clock] \
-name tessent_ssn_bus_clock_scan_fast_0 \
-period $local_ssn_bus_clock_scan_fast_period -add
# SSH generated clocks
create_generated_clock [tessent_get_pins \
<ssh_instance>/clock_gen/clock_signals/*_test_clock_shaper/clk_out] \
-source [tessent_get_ports ssn_bus_clock] \
-name tessent_ssh0_test_clock_gated \
-master tessent_ssn_bus_clock_scan_slow_0 -add \
-combinational \
-divide_by 1
create_generated_clock [tessent_get_pins \
ssh_instance/clock_gen/clock_signals/*_test_clock_shaper/clk_out] \
-source [tessent_get_ports ssn_bus_clock] \
-name tessent_ssh0_test_clock_div \
-master tessent_ssn_bus_clock_scan_fast_0 -add \
-combinational \
-divide_by 2

The fact that a single clock source pin fans out to both scannable logic and EDT controller circuit
branches makes clock tree synthesis (CTS) balance these two branches together by default. This helps
maximize the shift speed of the scan mode. Although edt_clock and shift_capture_clock have separate
clock gaters due to their functionality, they are considered to be on the same clock tree from an STA point
of view. For that reason, when an SSH is configured to generate test_clock, STA needs only one pair of
gated and divided clocks defined for that SSH.
It is also possible to simplify the SDC when SSH bypass mode is present and the test_clock DFT signal
is shared with the ssn_bus_clock port, by setting the SSH use_ssn_bus_clock_as_test_clock_bypass
property to "on". In this case, the SSH hardware does not add a bypass mode multiplexer for test_clock
injection, and the SDC does not need to create a separate test_clock, because both SSN and bypass
clock trees are identical. The figure "ScanHost Sourcing test_clock Reused for Legacy Bypass Mode" in
the "ScanHost" reference page in the Tessent Shell Reference Manual provides a detailed example.
To summarize, when you combine the following SSH property settings:

ScanHost (id) {
use_clock_shaper_cell : on;
scan_signal_bypass : on;
use_ssn_bus_clock_as_test_clock_bypass: on;
Interface {
ChainGroup {
test_clock_present : on;
shift_capture_clock_present : off;

612 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
SSN ScanHost Timing Constraints and Clock Tree Synthesis
edt_clock_present : off;
}
}
}

it reduces the resulting SDC from defining six different generated clocks:

tessent_ssh*_{edt_clock|shift_capture_clock}_{gated | div | bypass}

to two clocks:

tessent_ssh*_test_clock_gated
tessent_ssh*_test_clock_div

This eliminates a large number of set_clock_groups, set_false_path, and set_multicycle_path commands

that refer to these defined clocks.
At the design implementation stage, you should use a library cell for the clock shaper. Do this
by loading the cell library model of the clock shaper cell into Tessent Shell before running the
process_dft_specification command.
The clock shaper RTL cell is useful for simulation, but you should not use it for design implementation.
Using the clock shaper RTL cell at the design implementation stage could result in under constraint of the
design and could simultaneously create false timing violations. If you want to use the clock shaper RTL
cell during design implementation, you must characterize additional timing arcs for the clock multiplexer
cell being used, and you must apply additional clock gating constraints to the design, which are not
supplied in the Tessent SDC.

Clock Tree Synthesis Strategy for SSN

The SSN bus and the SSN ScanHost (SSH) nodes are intended to have all their logic balanced together
in CTS, including all registers and the buffer or multiplexer persistent cell that drives each scan clock out
of the SSH. Each buffer or multiplexer that drives a scan clock out of the SSH needs a CTS stop point.
Siemens EDA defines a CTS stop point as a leaf cell to which the clock tree is balanced; refer to Figure
156 on page 614.
All scan clocks driven out of a single SSH should start new clock trees and be balanced together in CTS,
including edt_clock. Although edt_clock usually drives less logic than shift_capture_clock, it must be
balanced with shift_capture_clock. If you do not balance the clocks together, it could cause large hold
violations from the scan chains to the EDT logic that would need to be fixed in the physical design phase.
SSH configurations that have both shift_clock and capture_clock must have those clocks balanced with
edt_clock. SSH configurations that drive a single test_clock require only a new balanced CTS clock tree
starting at the SSH persistent cell that drives test_clock.
A single SSH can control multiple functional clock domains. Each functional clock that is asynchronous to
other functional clocks has its own on-chip clock controller (OCC). In most cases, you perform CTS on the
functional clocks first at the output of each OCC. The resulting clock trees driven by each OCC usually
have different insertion delays from each other. To address this, add any necessary CTS buffers upstream
from the OCCs to balance all clock endpoints on shift_capture_clock driven from a single SSH.
Large designs may need pipeline stages from the ScanHost node to the EDT logic and from the
EDT logic back to the ScanHost node. Such pipeline stages must have their clock insertion delays
managed to deskew the clock insertion delay between the source and destination clocks in steps.
For more information about using pipelines with the SSH and EDT, refer to the DftSpecification/EDT/
Controller/Connections wrapper in the Tessent Shell Reference Manual.
If you use an SSN FIFO to minimize the loop timing delay of the SSN input clock to the data driven out
to the tester, that FIFO requires a CTS exclude point exception on the clock sub-tree that communicates

Tessent™ Shell User’s Manual 613

Streaming Scan Network (SSN)
SSN ScanHost Timing Constraints and Clock Tree Synthesis
with the SSN ports. The location of the exclude point depends on whether the FIFO is on the input or
output of the datapath:

• An SSN FIFO on the input of the datapath would have a CTS exclude point on its write-side clock
pin.

• An SSN FIFO on the output of the datapath would have a CTS exclude point on its read-side
clock pin.
Siemens EDA defines a CTS exclude point to be a pin where CTS clock balancing does not happen at
that point or at any point downstream in the clock tree from that exclude point. The exclude point should
still be treated as a clock pin for design rule fixing. Tessent tools also write out CTS exclude points in their
SDC files for logic internal to the OCC that generates clock gating signals. Refer to the your place and
route tool documentation to determine which CTS exception command matches the description of a CTS
exclude point provided in this section, and use that command as appropriate with your tool.

CTS Exceptions for the SSH

Figure 156. Recommended SSH CTS Stop Points

The preceding figure shows where Siemens EDA recommends specifying CTS instructions for balancing
stop points. If you omit these stop points from your CTS script, the tool interprets this script as indicating
that it must balance all of your scannable functional domains along with your SSN network bus clock tree.
This can lead to the following notable timing closure issues during layout, among others:

• A large increase in the total SSN bus clock tree latency. This creates excessive SSN clock
skew between neighboring tile blocks, your top-level SSN data bus ports, or both. This, in turn,
demands either large BusFrequencyMultiplier/BusFrequencyDivider nodes or deep SSN FIFO
nodes and could also potentially impact your maximum SSN bus clock frequency.

• Placement of your SSH clock generation subcircuit in the SSH clock_signal block in Figure 156
at the very root of the clock tree generated by CTS, instead of at the leaf cells in the fsm and
datapath block. This, in turn, results in a large reduction in your P1 timing path setup margin, by
the amount of the clock tree propagation D2. This can make it impossible to meet timing, even
for large functional trees or slow clock frequencies. You cannot add a pipelining flop to the path,
because this breaks the SSN scan protocol.

• Increased IJTAG clock network latency, because the ijtag_clock tree would come through the
scannable logic to the clock_signals logic.

614 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
SSN ScanHost Timing Constraints and Clock Tree Synthesis

If you specify the recommended CTS stop points, it makes the scan clock tree delay (D2) part of the chain
SI/SO timing paths in a predictable manner. This might force you to insert one or more rows of Tessent
pipelining flops along your EDT channels. The design of the SSH Scan SI/SO Interface already handles
a minimal level of skew, where all to_scan_in paths are retimed and all from_scan_out timing paths are
full-cycle paths of the slow clock. The from_scan_out circuit requires no retiming, because it includes a
single-direction clock timing loop, as shown in the figure. Timing Loop #2 includes the potentially very
large D2 delay, which the pipelining flops can reduce to the D1 value. The number of required pipelining
flops depends on both the size of your scannable domain and your target scan frequency. A large number
requires more effort during physical design to select the correct clock tree tapping point for each flop
layer. Automation has the potential to reduce these efforts, as does reducing the scan domain size by
multiplying the number of SSH instances at the DFT planning stage.
No other CTS constraints are required for the SSH bus clock and the ijtag_tck clocks. Tessent SDC
declares these clocks as physically exclusive, so the CTS process does not need to balance them
together. However, the ijtag_tck feeds both the ijtag_registers block, which contains standard TDR setup
logic, and the fsm and datapath block, which contains the SSH scan mode control logic. This enables
timing tck paths between the two blocks. The clock path to the fsm and datapath block is enabled only
during streaming_through_ijtag or bus_register access modes. When these modes are active, timing
paths P3, P4, and P5 must meet timing in 0.5 tck cycles, while P2 paths are static control signals that
Tessent SDC declares as false. All other tck timing paths within the fsm/datapath logic are more tightly
constrained by the faster SSN bus clock. CTS balances these two tck branches by default in the absence
of specific guidance, which improves the maximum IJTAG network speed without placing too much of a
penalty on the total tck insertion delay.
In the output SDC file, the extract_sdc command writes a Tcl proc named
tessent_get_cts_skew_groups_dict, which returns a dictionary of the CTS exceptions for clock skew
groups across all SSH and OCC instances in your design. You can use that dictionary with a custom
script that issues CTS commands specific to your layout tool. A CTS root point in Figure 156 on
page 614 shows where a new CTS clock tree should begin. Clocks starting at CTS root points grouped
under the same SSH in the tessent_get_cts_skew_groups_dict proc should be balanced together. The
header comment for the proc contains instructions on how to use it during CTS. The following is an
example:

proc tessent_get_cts_skew_groups_dict {} {

# This proc returns a dictionary of clock source pins from where clock
# tree synthesis balancing should stop.
# Use it in your CTS script, along with your proper tool command.
# In Synopsys ICC, invoke the following:
# set_clock_tree_exceptions -exclude_pins <exclude_pin>
# In Cadence Innovus, invoke the following:
# create_ccopt_skew_group -sources <exclude_pin> -auto_sinks
# -skew_group <group name>
# The effect of those commands is:
# * to prevent adding delay buffers to the small OCC internal clock tree,
# due to balancing with all flops in the OCC fanout, therefore
# helping the OCC clock_enable signals meet setup timing.
# * to prevent adding long delays to the SSN clock tree due to balancing
# with the functional clock tree in the fanout of each SSN scan host
# (SSH).
#
#
# You can use the dictionary the following way:
# set cts_skew_groups_dict [tessent_get_cts_skew_groups_dict]
# dict for {skew_group sub_dict} $cts_skew_groups_dict {
# dict with sub_dict {

Tessent™ Shell User’s Manual 615

Streaming Scan Network (SSN)
SSN ScanHost Timing Constraints and Clock Tree Synthesis
# foreach pin $cts_exclude_pins {
# puts "$skew_group : $dc_instance/$pin"
# <insert your CTS command here>
# }
# }
# }
set return_dict {
cts_skew_group(occ0) {
dc_instance top_rtl2_tessent_occ_parent_clka_inst
cts_exclude_pins {occ_control/
tessent_persistent_cell_ltest_ntc_sync_cell/CK occ_control/
tessent_persistent_cell_cgc_SHIFT_REG_CLK/CK occ_control/
tessent_persistent_cell_SHIFT_REG_CLK_mux/A1}
}
cts_skew_group(occ1) {
dc_instance top_rtl2_tessent_occ_parent_clkb_inst
cts_exclude_pins {occ_control/
tessent_persistent_cell_ltest_ntc_sync_cell/CK occ_control/
tessent_persistent_cell_cgc_SHIFT_REG_CLK/CK occ_control/
tessent_persistent_cell_SHIFT_REG_CLK_mux/A1}
}
…
cts_skew_group(ssh0) {
dc_instance top_rtl2_tessent_ssn_scan_host_1_inst
cts_stop_pins {
clock_gen/clock_signals/
tessent_persistent_cell_edt_clock_buf/A
clock_gen/clock_signals/
tessent_persistent_cell_shift_capture_clock_buf/A} }
cts_root_pins {
clock_gen/clock_signals/
tessent_persistent_cell_edt_clock_buf/Y
clock_gen/clock_signals/
tessent_persistent_cell_shift_capture_clock_buf/Y} }
}
}
return $return_dict
}

616 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Fast IO

Fast IO
SSN Fast IO is an SSN configuration in which the top-level external input and output ports of the SSN run
faster than the internal SSN bus.
These input and output ports are single-ended or DDR I/O ports, not SerDes or differential I/O ports.
These I/O ports can reliably run at 200 MHz and higher speeds. When you implement an SSN Fast
IO datapath, you place a BusFrequencyDivider (BFD) and BusFrequencyMultiplier (BFM) along with
Fifo nodes at either end of the SSN. These nodes collectively retime the data between the fast external
interface and the slower internal SSN bus.

Note:
The I/O ports that make up the fast external interface to the SSN must be part of the design
before you implement SSN Fast IO. The Tessent implementation does not supply these ports.

The following topics describe how to implement and use SSN Fast IO functionality:

Design Requirements
SSN Fast IO Functionality
Modeling a Double Data Rate Interface
Adaptive Tuning on the ATE
SSN Fast IO Bandwidth Improvement
Fast IO Pattern Generation
SSN Fast IO Limitations

Design Requirements
To implement SSN Fast IO, you must have a design with a single data rate or double data rate digital
interface that can be reused as the external interface to the SSN.
The interface should be capable of running faster than standard GPIO, which typically is limited to a
maximum operating frequency of 200 MHz. You can use a single clock as the source for both input and
output of the SSN. You can also use an optional second clock as one of the SSN clock sources, as shown
in Figure 157 on page 619.
Furthermore, you can also use a slower external interface to share access to the SSN. This requires
an equal number of data inputs and outputs to be used as the SSN bus_data_in and bus_data_out. It
also requires a single slower clock as the clock source to the SSN when you use the slower external
interface. A multiplexer, slow_fast_mux, enables the slower external interface to share access to the SSN,
as shown in Figure 158 on page 620 in "Single Data Rate Clocking".
Your Fast IO implementation must also conform to the following rules:

• The Fast IO BusFrequencyDivider (BFD) node (generating a divided clock) must be at the start of
the datapath, before any ScanHost (SSH) node.

• The Fast IO BusFrequencyMultiplier (BFM) node (generating a divided clock) must be at the end
of the datapath, after any SSH node.

• You must not cascade BFD or BFM nodes that generate divided clocks.

Tessent™ Shell User’s Manual 617

Streaming Scan Network (SSN)
Design Requirements

• A Fast IO datapath that starts with a BFD node that generates a divided clock must end with a
BFM that also generates a divided clock.

• If you have multiple dies and the datapath within each die meets the preceding requirements, you
can cascade the datapath across a pair of dies. At the boundary, you must have one die end with
a BFM node and the next die start with a BFD node. There must not be any SSH node between
these two nodes.

• If a BFD node generates a divided clock and drives an SSH node after it in the datapath (using
forward timing), you must have a Fifo or Receiver1xPipeline node between them.

618 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
SSN Fast IO Functionality

SSN Fast IO Functionality

SSN Fast IO functionality uses enhanced BFD and BFM node definitions that create internal clocks for
the SSN, using the fast external clock source.
Creating a divided clock from the BFD on the SSN datapath input provides a clock that matches the
slower internal data rate. Likewise, the clock created from the BFM retimes the data from the slower
internal bus back to the faster external interface on the SSN datapath output. Refer to Figure 157 on
page 619 to observe the placement of the BFD and BFM nodes and the clock distribution of each.
The figure also shows how the FIFO instances on either end of the SSN use two separate copies of
ssn_bus_clock. One copy of the ssn_bus_clock is created from the BFD and a second copy of the
ssn_bus_clock is created from the BFM. The clock output from the BFD is the source clock to the FIFOin
and the internal SSN. The clock output from the BFM is the source clock to only the read side of the
FIFOout. This creates a loop timing path between the FIFOout and the BFM. Both FIFO instances ensure
that data reliably transfers between the two versions of ssn_bus_clock.

Single Data Rate Clocking

Double Data Rate Clocking

Single Data Rate Clocking

When you use single data rate (SDR) clocking, data is driven into the SSN from the I/O pads using a
single edge of the input clock.
On the input side of the SSN, a fast external interface drives the BFD through input pipeline stages, as
shown in Figure 157. The BFD slows the input data rate by the frequency ratio N and widens it by the
same ratio. The tool creates two separate clocks from the BFD node, illustrated by the blue 1. Both clocks
are created from the fast external input clock. The two clocks are copies of each other and come from
the same source in the BFD. One clock output, bus_clock_out_local, is the write clock to FIFOin, and the
other clock, bus_clock_out, is the read clock for FIFOin. You can also use bus_clock_out as the clock
source for the slower, wider internal SSN and the write clock to FIFOout, which the figure also illustrates.
For more information about the clocks created by the BFD and how to use them with SSN Fast IO, refer
to "BusFrequencyDivider" in the Tessent Shell Reference Manual.
The BFM, on the output side of the SSN, is the interface from the slower, wider SSN to the faster external
interface, as in the figure. The BFM speeds up the internal data rate of the SSN by the frequency ratio N
and narrows it by the same ratio. The FIFOout retimes the data coming from the slower internal SSN to
the BFM that runs at the faster external interface frequency. The output clock of the BFM is created from
the fast external clock input and creates a loop timing path between the FIFOout and the BFM, allowing
a full clock cycle of the fast clock for the data to propagate to the BFM. The data returns to the tester
through pipeline stages that are also running at the faster external frequency. For more information about
the clocks created by the BFM and how to use them with SSN Fast IO, refer to "BusFrequencyMultiplier"
in the Tessent Shell Reference Manual.

Figure 157. Example SSN Fast IO Bus With SDR Clocking

Tessent™ Shell User’s Manual 619

Streaming Scan Network (SSN)
Double Data Rate Clocking

As an alternative to the previous configuration (where the fast external interface is the only access to
the SSN), you can add a slow_fast_mux, as shown in the following figure, to share access to the SSN
through a slower external interface. The multiplexer enables you to share access to the SSN between the
two interfaces. The slow_fast_mux enables you to develop the SSN and create patterns using the slower
external interface while you work on the access through the faster external interface. You can remove the
slow_fast_mux once you are satisfied with the faster external interface as the only access mechanism to
the SSN.

Figure 158. Example SSN Fast IO Bus With SDR Clocking

and Alternate External Interface Access to the SSN

Double Data Rate Clocking

SSN Fast IO with double data rate (DDR) clocking functions similarly to SSN Fast IO with SDR clocking.
The primary difference is that the DDR external interface provides 2× the data rate of the SDR external
interface.
When you use SSN Fast IO with DDR clocking, input data is sampled using both the leading and falling
edges of the clock. Similarly, the SSN output data bus is strobed using both the leading and falling edges
of the clock.
The following figure shows an example of SSN Fast IO with DDR clocking. When you use the DDR
external interface, the input and output pipelines on the SSN are optimal due to the nature of the DDR
clocking scheme.

Figure 159. Example SSN Fast IO Bus With DDR Clocking

When you use the DDR external interface, the clocks generated from the BFD and BFM are still required,
as described in “Single Data Rate Clocking” on page 619.
As with SDR clocking, you can add an alternate external interface to the SSN Fast IO with DDR clocking
configuration. The alternate external interface can access the SSN through a slow_fast_mux, shown in
the following figure. This mux enables you to develop the SSN and create patterns while you work on the
access through the faster external interface. You can remove the slow_fast_mux once you are satisfied
with the DDR interface as the only access mechanism to the SSN.

620 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Double Data Rate Clocking

Figure 160. Example SSN Fast IO Bus With DDR Clocking

and Alternate External Interface Access to the SSN

Tessent™ Shell User’s Manual 621

Streaming Scan Network (SSN)
Modeling a Double Data Rate Interface

Modeling a Double Data Rate Interface

An ICL representation of the DDR interface is required to model the DDR clock and the delay of the data
through the DDR macro when you use SSN Fast IO with DDR clocking. Additionally, you can model DDR
inputs and outputs using Verilog RTL.
A cycle-accurate simulation model is required for the DDR interface. This model is used during validation
of the SSN pattern.
When you use the DDR external interface, the clock is defined relative to the data. The data rate is one
bit per edge of the clock. On the rising edge of the clock, one data bit is strobed. On the falling edge of the
clock, a different data bit is strobed. Define the clock so that one bit of data is strobed for each edge of the
clock.
Defining the clock with a frequency divider of two (half of the data rate) means that each edge of the clock
strobes data:
add_clocks ssn_ddr_clock_name ‑freq_divider 2

For example, if the DDR clock period is defined as 10 ns, the data is strobed every 5 ns: once on each
clock edge, rising and falling.
When you use the PatternsSpecification to create DDR verification patterns, define the DDR clock with
the same frequency division, as in the following example:

PatternsSpecification(…) {
Patterns(…) {
ClockPeriods {
<ssn_ddr_clock_name> : tester, 0.5 ;
}
}
}

Refer to the PatternsSpecification reference topic and its subtopic Patterns in the "Configuration-
Based Specification" chapter of the Tessent Shell Reference Manual for more information about using a
PatternsSpecification.
The following topics provide specific information about modeling the interface in various languages:

ICL Modeling
Verilog Modeling

ICL Modeling
The following sections show examples of how to model the DDR input and DDR output in ICL. New ICL
attributes are required for the DDR ICL models. These attributes are highlighted in these examples.
These ICL models describe the following schematic :

622 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
ICL Modeling

Figure 161. Sample DDR Interface Schematic

DDR Input Model

The DDR input ICL model has the following properties:

• The DataInPort has "Attribute tessent_ssn_function = "ddr_bus_data_input" ;".

This attribute distinguishes a DDR input cell from other SSN logic in which one input has fanout to
several DataRegisters.

• The di_pos_ret DataRegister has "Attribute tessent_active_clock_edge = "rising" ;", and

di_neg_ret has "Attribute tessent_active_clock_edge = "falling" ;".
These two registers determine the destination bus bit for the stimulus values provided to the
primary input during both of the following periods:

◦ Between the rising and falling edges of the SSN DDR clock.

◦ Between the falling and rising edges of the SSN DDR clock.

• The do_ret DataRegister spans all outputs and aligns the incoming data to the same clock edge.
This DataRegister does not necessarily have to be part of the DDR input ICL. For example, it can
be the register of the first pipeline. It is only necessary that it must use the same clock.
The following is an example of the input ICL model:

Tessent™ Shell User’s Manual 623

Streaming Scan Network (SSN)
ICL Modeling

Module ddr_in {
ClockPort clk {
Attribute function_modifier = "tessent_ssn_clock";
Attribute forced_high_dft_signal_list = "ssn_en";
}
ToClockPort clk_out {
Attribute function_modifier = "tessent_ssn_clock";
Source clk;
}
DataInPort di {
Attribute function_modifier = "tessent_ssn_bus_data";
Attribute tessent_ssn_function = "ddr_bus_data_input";
Attribute forced_high_dft_signal_list = "ssn_en";
}
DataOutPort do[1:0] {
Attribute function_modifier = "tessent_ssn_bus_data";
Attribute forced_high_dft_signal_list = "ssn_en";
Source do_ret[1:0];
}
DataRegister do_ret[1:0] {
WriteDataSource di_neg_ret,di_pos_ret;
WriteEnSource 1'b1;
}
DataRegister di_neg_ret {
Attribute tessent_active_clock_edge = "falling";
WriteDataSource di;
WriteEnSource 1'b1;
}
DataRegister di_pos_ret {
Attribute tessent_active_clock_edge = "rising";
WriteDataSource di;
WriteEnSource 1'b1;
}
}

DDR Output Model

The DDR output ICL model has the following properties:

• The DataOutPort has "Attribute tessent_ssn_function = "ddr_bus_data_output" ;".

This attribute is required to identify the DDR output without ambiguity and to apply checks
verifying that the output is correctly set up.

• A DataMux selects between two inputs and is controlled by an instance output of a special
module, as described in the following example.
This multiplexer selects between the source of the value that can be observed at the primary
output between the rising and falling edges of the SSN DDR clock and the source of the value
that can be observed at the same primary output between the falling and rising edges of the SSN
DDR clock.

624 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
ICL Modeling

• A special module has "Attribute tessent_ssn_function = "ddr_out_selector" ;", along with a

ClockPort and a DataOutPort that converts the SSN clock into a data signal that can be used as a
mux select input.
This module is required to specify to the tool which SSN clock is associated with the multiplexer
in the DDR output cell. ICL syntax does not allow the SSN clock to control the multiplexer directly,
so this special module converts the clock signal to a data signal.
The following is an example of the output ICL model:

Module ddr_out {
ClockPort clk {
Attribute function_modifier = "tessent_ssn_clock";
Attribute forced_high_dft_signal_list = "ssn_en";
}
ToClockPort clk_out {
Attribute function_modifier = "tessent_ssn_clock";
Source clk;
}
DataInPort di[1:0] {
Attribute function_modifier = "tessent_ssn_bus_data";
Attribute forced_high_dft_signal_list = "ssn_en";
}
DataOutPort do {
Attribute function_modifier = "tessent_ssn_bus_data";
Attribute tessent_ssn_function = "ddr_bus_data_output";
Attribute forced_high_dft_signal_list = "ssn_en";
Source ddr_mux;
}
DataRegister di_ret[1:0] {
WriteDataSource di[1:0];
WriteEnSource 1'b1;
}
DataRegister di_ret1 {
WriteDataSource di_ret[1];
WriteEnSource 1'b1;
}
DataRegister di_ret0 {
Attribute tessent_active_clock_edge = "falling";
WriteDataSource di_ret[0];
WriteEnSource 1'b1;
}
Instance do_select Of ddr_out_do_select {
InputPort in = clk;
}
DataMux ddr_mux SelectedBy do_select.out {
1'b0 : di_ret1;
1'b1 : di_ret0;
}
}
Module ddr_out_do_select {
Attribute tessent_ssn_function = "ddr_out_selector";
ClockPort in {

Tessent™ Shell User’s Manual 625

Streaming Scan Network (SSN)
Verilog Modeling
Attribute function_modifier = "tessent_ssn_clock";
}
DataOutPort out;
}

Verilog Modeling
The following sections show examples of how to model the DDR input and DDR output using Verilog
HDL. Use these examples to help create your simulation models if needed.

DDR Inputs
module ddr_in (clk, di, do, clk_out);
input clk;
input di;
output reg [1:0] do;
output clk_out;

reg di_neg_ret, di_pos_ret;

always @ (negedge clk) begin
di_neg_ret <= di;
end
always @ (posedge clk) begin
di_pos_ret <= di;
do <= {di_neg_ret, di_pos_ret};
end
assign clk_out = clk;

endmodule

DDR Outputs
module ddr_out (clk, di, do, clk_out);
input clk;
input [1:0] di;
output do;
output clk_out;

reg [1:0] di_ret;

reg di_ret1, di_ret0;
wire select;

always @ (posedge clk) begin

di_ret <= di;
di_ret1 <= di_ret[1];
end
always @ (negedge clk) begin
di_ret0 <= di_ret[0];
end
assign #0 select = clk;
assign do = (select) ? di_ret0 : di_ret1;

626 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Verilog Modeling
assign clk_out = clk;

endmodule

Tessent™ Shell User’s Manual 627

Streaming Scan Network (SSN)
Adaptive Tuning on the ATE

Adaptive Tuning on the ATE

When you use SSN Fast IO to test your chip, you may need to calibrate the ATE to reliably test your chip.
You may need to delay the output strobe on the ATE to match the delay of the data coming from the
chip. Similarly, you may need to delay the input stimulus from the ATE to account for clock latency within
the chip. As clock frequencies increase, the delays within each chip may vary across process corners,
taking up more of the clock period and requiring each chip to be individually calibrated to test reliably.
The following figure shows an example of properly tuning the input delay, d_tuned, and the output strobe,
strobe_tuned, to account for delays within a chip.

Figure 162. Proper Tuning of Input Data and the Output Strobe

The waveform of d-V1 at time zero shows the data perfectly centered around the rising edge of the clock
clk1g, which provides a sufficient setup and hold margin. Both are shown to be applied at time zero
without considering the delays inside the chip. However, the waveform for clk1g_int in cycle T2 shows a
roughly 400 ps delay before the first rising edge appears at the internal clock pin. To reliably strobe the
input stimulus, the input data from the ATE must be delayed to account for the delay on the clock net.
When it is not delayed and forced at time zero, as is shown in the preceding figure, there is not enough
setup and hold margin to be strobed by clk1g_int. Therefore, the input d‑V2 is mistakenly strobed.
As a result, to sample the d-V1 input data with sufficient setup and hold margin, it must be delayed to
account for the delay on the clock net inside the chip. The waveform d_tuned-V1 shows how the ATE can
provide a delayed version of the input data that is properly centered around the rising edge of clk1g_int,
providing sufficient setup and hold margin.
The output strobe is more commonly required to be tuned even at lower frequencies, to account for the
delays internal to the chip, because those delays translate into the data appearing on the output later
in the cycle compared to ideal timing. In Figure 162, the strobe is placed at the falling edge of the clock
clk1g, as shown in cycle T8. This strobe placement is based on timing of the clock being applied at time
zero without considering the delays inside the chip.
The waveform of q‑V1 shows the actual timing of the output based on the delay of the data before it
appears on the output. The "strobe" waveform shows the output strobe can be moved to later in the cycle
T8 while still providing sufficient setup and hold margin on q‑V1. The tuned placement of the output strobe
is shown in the waveform strobe_tuned.
The previous figure and accompanying description demonstrate the need to perform adaptive tuning to
test your chip reliably when you use SSN Fast IO. Refer to the section “ATE Calibration” on page 629
for the process of calibrating the tester to adapt to the internal delays of your chip using the SSN
continuity pattern.
The following topics provide more information about adaptive tuning:

628 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
ATE Calibration

ATE Calibration
ATE Input Delay Tuning
Output Strobe Tuning

ATE Calibration
Use the SSN continuity pattern to calibrate the tester to the delays in your chip.
To calibrate the ATE, start by slowing the pattern by a factor of four and setting the output strobe point just
before the end of the tester cycle. Slowing the pattern to this degree enables you to have a reliable output
strobe and a slow enough clock to strobe the input data reliably without any delay from the tester.
When you test your device at a frequency of 200 MHz or higher, you must find a reliable output strobe.
When your external clock frequency is 400 MHz or higher, you may also need to tune the input data from
the tester to account for internal clock delays across all PVT conditions. Testing your part without properly
calibrating the tester may result in yield loss.
Use the following equations to calculate the clock period and the location of the output strobe. In these
equations, T is the clock period (ps) of the SDR or DDR clock defined for the SSN continuity pattern:
Equation 1: Clock Period for the SSN Continuity Pattern When Calibrating the ATE
Clock period (calibration) = T × 4
Equation 2: Location of the Output Strobe, in Picoseconds, When Calibrating the ATE
Strobe point (calibration) = (T × 4) - 1 ps

ATE Input Delay Tuning

Tune the tester input delay by increasing the delay until the output shows failures.

Note:
This section uses the DDR clock waveform in Figure 162 on page 628 for reference.

With the SSN continuity pattern running at a 4× slower speed, increase the delay on d‑V1 from the tester
until the output shows failures. The delay added to d‑V1 moves the data change edge of d‑V1 toward
the rising edge of the clock clk1g_int, causing a setup violation, which results in failures on the SSN bus
output.
This is the amount of delay that causes the pattern to stop working and is the same for any clock
frequency. Use this delay to calculate the amount of delay needed by the tester before applying the input
data d‑V1. Use the following equation to calculate this delay:
Equation 3: Input Delay To Be Applied by the Tester
Input Delay (tuned) = delay - 750 ps
Subtracting 750 ps from the delay puts the data eye of d-V1 into the timing window T2, around the rising
edge of clk1g_int, and it provides 250 ps of hold margin, as shown in d_tuned in the waveform. Similarly,
the delay puts the data eye of d-V2 into the timing window T3 and around the falling edge of clk1g_int,
with the same hold margin. This is also shown in d_tuned in the waveform.

Output Strobe Tuning

Tune the output strobe by delaying it to later in the cycle until the strobe no longer works.

Tessent™ Shell User’s Manual 629

Streaming Scan Network (SSN)
SSN Fast IO Bandwidth Improvement

Note:
This section uses the DDR clock waveform in Figure 162 on page 628 for reference.

Start with the clock period of the SSN continuity pattern at full rate. You must restore the clock to its
maximum frequency before slowing it down to determine the input delay. If you have moved the output
strobe, you must also return it to its original position. It should be in the middle of the data eye of q‑V1 in
the timing window T8. With the clock running at full frequency and with the input tuned to the delay of the
clock, delay the output strobe by moving it toward the end of the T8 timing window and the data change
edge of q‑V1. Increase the delay until the strobe point no longer works, which occurs when you have
moved it sufficiently close to the data change edge between q‑V1 and q‑V2. The point of failure occurs
when the strobe violates the hold time of q‑d1. This amount of delay causes the pattern to stop working.
Use this delay to calculate the output strobe point, as shown in the following equation:
Equation 4: Delay To Apply to Output Strobe
Output Strobe Delay (tuned) = delay - 250 ps
Subtracting 250 ps from the measured delay puts strobe_tuned toward the end of the data eye of q‑V1.
This provides a sufficient setup margin and 250 ps of hold margin, as shown in the figure.

SSN Fast IO Bandwidth Improvement

Implementing SSN Fast IO can improve the bandwidth of your SSN as compared to an SSN with a slower
external interface.
Table 29 shows how an SSN with a number N of I/O ports running at 800 MHz has 4× the bandwidth of
the same SSN running at 200 MHz. For example, an SSN Fast IO with SDR clocking and 8 I/O ports
running at 800 MHz yields 6.4 Gbps of bandwidth. The same SSN with an external interface running at
200 MHz yields only 1.6 Gbps. To achieve the equivalent bandwidth of the SSN running with the faster
external interface, it requires 4× the number of I/O ports on the slower external interface. Thus, the slower
external interface must increase to 32 I/O ports to achieve the same results.

Tip
Calculate SSN bandwidth by multiplying the number of I/O ports by their maximum operating
frequency.

In some cases when a faster external interface with SDR clocking has fewer I/O ports than the number
of slower external I/O ports, the Fast IO interface does not yield a higher bandwidth for the SSN. The
following table shows that an SSN using SDR clocking with a slower external interface of 32 I/O ports
yields 6.4 Gbps when running at 200 MHz. To achieve the same bandwidth with a faster external interface
requires 16 I/O ports running at 400 MHz or eight I/O ports running at 800 MHz.
However, an SSN Fast IO can still provide value even if there is less throughput while testing a single part
at a time. If the bandwidth of a Fast IO interface is less than that of the slower external interface, multi-site
testing can improve the test time. For example, the following table shows you can test one SSN device
with 32 I/O ports running at 200 MHz in one-fourth of the test time of the same SSN device with a faster
external interface running at 800 MHz with two I/O ports.

630 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Fast IO Pattern Generation

Table 29. SSN Bandwidth Comparison for I/O Port/Frequency Combinations

Data Rate (Gbps) Data Rate (Gbps) Data Rate (Gbps)

Number of I/O Ports
@ 800 MHz @ 400 MHz @ 200 MHz

2 1.6 0.8 0.4

4 3.2 1.6 0.8

8 6.4 3.2 1.6

12 9.6 4.8 2.4

16 12.8 6.4 3.2

32 25.6 12.8 6.4

Testing four devices concurrently running at 800 MHz yields a combined throughput of 6.4 Gbps. If
you use fewer ports for Fast IO than slower I/O ports, you may not observe the benefits of using Fast
IO functionality when testing individual devices. However, you may still observe benefits when testing
devices in parallel using multi-site testing.

Fast IO Pattern Generation

The SSN pattern generation flow for SSN Fast IO is identical to the normal SSN pattern generation flow.
When you have more than one external interface, as in the figure in Example 4 in "BusFrequencyDivider"
in the Tessent Shell Reference Manual, the default access mechanism is the I/O port group
with the ID matching the datapath ID in the extracted ICL. Use the ‑alternate_input_id <id> and
‑alternate_output_id <id> arguments of the set_ssn_datapath_options to change the active external
interface of the SSN.

SSN Fast IO Limitations

Creation of SSN Fast IO patterns is subject to certain process limitations.

• An equal number of data inputs and outputs must be used as the SSN bus_data_in and
bus_data_out.

• When you create SSN Fast IO patterns, you must use frequency-similar input and output ports of
the same datapath.
For example, when you retarget SSN patterns, both the bus_data_in and bus_data_out must
operate at the same frequency. You cannot mix a fast external interface with a slower external
interface.

• The clock input of a BFD cannot be driven by the clock output of another BFD (for example,
bus_clock_out or bus_clock_out_local).
Similarly, the clock input of a BFM cannot be driven by the clock input of another BFM (for
example, bus_clock_out).

• Because of limitations in WGL for representing DDR patterns, DDR clocking does not support the
WGL pattern format.

Tessent™ Shell User’s Manual 631

Streaming Scan Network (SSN)
SSN Fast IO Limitations

• The following Fast IO cases are not permitted:

◦ DDR clocking with frequency-multiplied clocks.

◦ DDR clocking with 1× clocks.

◦ SDR input with DDR outputs.

632 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Burn-In Pattern Support

Burn-In Pattern Support

The Tessent Streaming Scan Network (SSN) supports creation of burn-in patterns. Burn-in patterns are a
silicon aging technique that enable you to make predictions about how the silicon you are designing ages
with use. They are commonly used during high-temperature operating life (HTOL) testing.

Burn-In Pattern Overview

Recommended Flows for Creating Burn-In Patterns
Burn-In Functionality Limitations

Burn-In Pattern Overview

Burn-in pattern support for SSN uses a specially designed burn-in mode that you can configure to
generate patterns that meet your needs.
Historically, the burn-in process has used EDT to drive pseudorandom patterns into chains. You would
toggle the edt_update signal low for the duration, and drive EDT channels and pulse the clocks like
edt_clock and shift_clock. Custom observability for burn-in used "proof of life" (activity) with a counter or a
path to the edge of the design through the GPIO.
During generation of burn-in patterns with SSN, the tool configures the SSH hardware into "infinite shift"
mode. In this mode, capture is disabled, and the burn-in payload loops without an ssn_end procedure.
The burn-in payload can target all SSHs (the default) or one or more SSHs. The packet is serially
distributed along the SSN bus. The packet size calculation is based on the number of input channels of
each active EDT. Each EDT has its own time slots in the packet. There is no data throttling during the
application of the burn-in patterns. Unlike normal SSN operation, the output response is not added back
into the packet for observation at the SSN outputs.
The default payload sequence for burn-in is "1100": the first two packets drive all bus inputs to 1, and the
next two drive all bus inputs to 0. This triggers pseudorandom data out of the EDT and is compatible with
uncompressed chains.
To configure the burn-in pattern, use the set_burnin_options command, which controls the target SSH
instance or instances, the payload sequence, and the number of repetitions of the sequence in the
pattern.

Note:
Because low-power shift hardware interferes with the operation of burn-in patterns, you must
disable any low-power shift hardware in your design to use the burn-in pattern functionality.

Handling EDT Channel Pipeline Stages

To ensure proper handling of EDT pipeline stages during burn-in, edt_clock is the default clock source
for pipelines when added to both the input and output EDT channels. When the EDT is equipped with
edt_bypass, edt_clock and edt_update are combined with additional logic to ensure the EDT channel
pipeline stages are properly controlled during ATPG and initialized for simulation. During EDT bypass,
EDT channel pipeline stages are treated as scan cells. When present on either input and output EDT
channels, the pipeline stages are equipped with hold logic to ensure each pipeline stages holds its current
value during the load_unload procedure. Reset logic is added to each input pipeline stage to ensure
known values during simulation.

Tessent™ Shell User’s Manual 633

Streaming Scan Network (SSN)
Burn-In Pattern Overview

When you bypass both the EDT and SSH and use tool automation of add_dft_signals to create
shift_capture_clock and edt_clock from test_clock, the tool ensures edt_clock is correctly controlled. The
pulsing of test_clock results in pulsing of the edt_clock during the load_unload and shift procedures. If
you do not use automation of the add_dft_signals in this case, you must manually define the edt_clock
on an independent top-level port and manually constrain it off (to 0) to avoid scan chain blockages and
unknowns during simulation:
SETUP> add_clocks my_edt_clock
SETUP> add_input_constraints my_edt_clock -C0

Changing the clock source for the EDT channel pipeline stages to shift_capture_clock and using
edt_bypass mode results in DRC violations during ATPG. In addition, the pipeline stages are uninitialized
for simulation, resulting in unknowns being driven into the EDT decompresser and scan chains.

634 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Recommended Flows for Creating Burn-In Patterns

Recommended Flows for Creating Burn-In Patterns

There are two recommended flows for creating burn-in patterns: a retargeting flow for large designs, and
a flat ATPG flow for designs running flat ATPG.
The retargeting flow follows the scan pattern retargeting approach. Because it requires a lower amount of
machine memory than the flat ATPG flow, it is suited for large designs.
The flat ATPG flow uses the same setup that ATPG uses, simplifying the process to configure this flow.

Creating Burn-In Patterns With the Retargeting Flow

Creating Burn-In Patterns With the Flat ATPG Flow

Creating Burn-In Patterns With the Retargeting Flow

Use the retargeting flow to create burn-in patterns for large designs. If you use a retargeting flow for
scan patterns, you should also use this flow to create burn-in patterns. This flow is designed to minimize
machine memory usage to accommodate such designs.
In addition to reducing memory usage, this flow also improves run time by using TCD files. The tool
makes certain assumptions about the state of each core when loading TCD files and applies a simplified
(reduced) set of DRCs. The full DRC process can take significantly longer for a full hierarchical design.
In normal (non-burn-in) SSN operation, when a core has at least one lower-level child core, the parent
is in internal test mode, and the child cores are in external test mode, where only the wrapper chains
of these child cores are active. However, when you create burn-in patterns for a parent-child core
configuration with SSN, only the parent-level scan chains are active and the tool resolves the module
instances for child cores using IJTAG grayboxes. The child cores are not configured into external mode in
this case.
Only the IJTAG graybox design view is required for all design levels (including the top level) to create
burn-in patterns following the retargeting flow. The IJTAG graybox design view is only a small fraction of
the design size, and it is already a recommended part of the SSN flow.

Tip
When you set up your burn-in patterns, use a mode name that includes a phrase like "burnin" so
you can easily identify your burn-in patterns. Refer to Step 2.a for an example of this. You can use
this mode name with the set_current_mode command.

Prerequisites
• The IJTAG graybox view is highly recommended for the retargeting flow. Although you can still
create burn-in patterns without them, doing so causes the flow to use significantly more memory
and take much longer.

Tessent™ Shell User’s Manual 635

Streaming Scan Network (SSN)
Creating Burn-In Patterns With the Flat ATPG Flow

Procedure
1. Generate a Tessent core description (TCD) file for each level of hierarchy, starting at the lowest
level.

a. Create a burn-in TCD at the wrapped core level.

The setup for this TCD is identical to what you use for the "patterns ‑scan" context. It
represents a core configured for burn-in. Treat any lower levels of hierarchy as IJTAG
grayboxes (for example, "read_design -view ijtag_graybox").

b. Configure the tool into internal mode. Add the core instances for the EDTs and OCCs using a
command such as read_core_descriptions or add_core_instances.

c. Check the design rules with the check_design_rules command.

The tool automatically adds the SSH core instance information.

d. Write the TCD out with the write_tsdb_data command.

This command uses the name (if any) you supplied with the set_current_mode command.

e. (Optional) Write out the testbench, using the set_burnin_options command, to verify the burn-in
setup and sequence.

f. Repeat this process for each hierarchical level, including the top level.

2. Create a top-level burn-in pattern. The setup is identical to what you would use for pattern
retargeting, including the context ("set_context patterns ‑scan_retargeting").

a. Target the top level and any lower-level cores added by the TCD file. For example:
add_core_instances ‑instances {top corea_i1 corea_i2} ‑mode edt_mode_burnin

b. Check the design rules again with the check_design_rules command.

c. Write out the testbench, using the set_burnin_options command, to verify the burn-in setup and
sequence

d. (Optional) Configure the burn-in pattern setup with the set_burnin_options command.

e. Write the burn-in STIL pattern and testbench for verification.

Creating Burn-In Patterns With the Flat ATPG Flow

Use the flat ATPG flow to create burn-in patterns for designs already running flat ATPG. The flat ATPG
flow requires a full flat netlist and uses unwrapped scan mode.

Prerequisites
• The flat ATPG burn-in flow uses the same setup that flat ATPG uses.

Procedure
1. Configure the tool into internal mode.

2. Add the core instance for the EDTs and OCCs using a command such as read_core_descriptions
or add_core_instances.

636 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Burn-In Functionality Limitations

3. Check the design rules with the check_design_rules command.

The tool automatically adds the SSH core instance information.

4. (Optional) Configure the burn-in pattern setup with the set_burnin_options command.

5. Write the burn-in STIL pattern and testbench for verification.

Burn-In Functionality Limitations

The following limitations apply to the Tessent burn-in functionality with SSN:

• Tessent burn-in functionality does not support observation of design activity during application of
the pattern using SSN. You must supply your own device proof of life or activity.

• The verification testbench has limited functionality. A passing simulation does not confirm setup
or payload presence; you must inspect for these manually.

Tessent™ Shell User’s Manual 637

Streaming Scan Network (SSN)
LVX Support

LVX Support
Tessent software includes the capability for laser voltage imaging (LVI) and laser voltage probing (LVP)
functionality. Tessent LVI and LVP support is referred to collectively as "LVX" support.
The LVX capabilities of laser scanning microscopy platforms measure timing and functional
characteristics of semiconductor devices. Their architecture usually supports docking with automated
test equipment (ATE) and back-side analysis for localization of cell- and transistor-level faults and design
marginalities.
Tessent LVX functionality includes the following:

• Packet-based delivery of any repeating sequence, such as "1100", from the tester through the
SSN network to all chains of an EDT (using EDT LVX hardware) or uncompressed chains.

• Broadcasting the sequence to all chains of an EDT or to a specific chain that you select on the
tester.

• Looping a payload pattern set (after setup) that applies the repeating sequence on internal chains
without interruption. You do not need to apply the ssn_end procedure between iterations, as
ATPG patterns require.

• Diagnosis reporting of the failing chains with the full ICL instance pathname of the driving EDT
instances and the chain indices.

LVX Hardware Requirements

Creating EDT With LVX Hardware
LVX Operation Modes With LVX Hardware Configuration
Configuring LVX Patterns
Writing LVX Loop Patterns
Writing LVX Verification Patterns
LVI_PATCHING_INFO

LVX Hardware Requirements

Support for Tessent LVX requires the following hardware setup.

• SSH hardware generated with the 2021.2 release or a later release.

• EDT hardware generated with LVX enabled in the DftSpecification. The EDT hardware can have
one of the following two configurations:

◦ One-hot chain selection support (more hardware but reduced LVX noise).

◦ Broadcast only to all chains driven by EDT (less hardware).

Tessent LVX minimizes EDT hardware overhead by reusing the existing hardware when this is possible.

638 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Creating EDT With LVX Hardware

Creating EDT With LVX Hardware

Specify LVX settings within the EDT DftSpecification to generate EDT with LVX hardware.

Procedure
Use the following wrappers and properties to generate the EDT with LVX hardware:

DftSpecification(module_name, id) {
EDT {
Controller {
LVxMode {
present: on | off | auto ;
enable_one_chain: on | off ;
}
}
}
}

Note:
If you specify enable_one_chain as "off" instead, the EDT can broadcast the LVX sequence only
to the scan chains.

Results
The DftSpecification results in an EDT with two new TDRs for controlling the LVX hardware:

• lvx_mode

• lvx_chain_index
These TDRs are controlled behind a SIB, as shown in the following figure, and accessible through the
IJTAG interface.

Figure 163. Tessent LVX TDRs

Tessent™ Shell User’s Manual 639

Streaming Scan Network (SSN)
Creating EDT With LVX Hardware

The PDL represents both of these TDRs with iWriteVars, so they are annotated in the pattern set and you
can patch them on the tester.
With the LVX setup, the EDT controller has an IJTAG scan interface. The tool resets the EDT hold
registers using the ijtag_reset signal.

Tip
Maintain no more than one EDT or one uncompressed chain per SSH chain group.

If you do not put each EDT and uncompressed chain into its own chain group, this results in the tool
adding padding to the packet. This, in turn, increases the number of shifts between each EDT/chain in the
lvx_loop sequence. Adding each EDT and uncompressed chain into its own SSH chain group results in a
more efficient packet for applying the lvx_loop to all the EDT/chains.
The tool delivers the LVX payload as packetized data serially along the SSN bus, as with normal scan
operation. Unlike normal scan operation, the LVX payload consists of a single bit per active EDT.
For example, using the preceding recommendation, the packet size for a single SSH with two active
internal mode EDTs, each in their own SSH chain_group, is two bits: a single bit for each EDT. The least
significant bit (LSB) of each SSH chain group drives a specific scan chain or broadcasts to all chains,
based on the LVX hardware for each EDT.
LVX Hardware for Channel Input
The following figures show the LVX hardware for the EDT channel input both with and without
enable_one_chain specified as part of the DftSpecification. The enable_one_chain specification adds
chain masks after the phase shifter. This is the hardware that the tool adds to the EDT to support LVX.
Specifying enable_one_chain enables you to observe individual chains during the application of the LVX
pattern. Without enable_one_chain, the LVX hardware does not have the granularity to block individual
chains. Instead, the hardware includes an additional mask_all_chains signal when you do not specify
enable_one_chain.

Figure 164. LVX Hardware With enable_one_chain for Channel Input

640 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Creating EDT With LVX Hardware

Figure 165. LVX Hardware Without enable_one_chain for Channel Input

When multiple cores are active in an lvx_loop pattern, each core can be independently controlled through
the EDT LVX IJTAG registers for each individual core. This enables some cores to broadcast the lvx_loop
sequence to all scan chains, while other cores target unique scan chains trough the lvx_chain_index
TDR. Control this by patching the iWriteVars in the pattern.
LVX Hardware for Channel Output
The following figures show the propagation of LVX scan data for the EDT channel output both with
and without enable_one_chain hardware. The enable_one_chain specification adds some logic to
accommodate the enable_one_chain signal on EDT channel output 1. When a single SSH and EDT
are active, the LVX mode output appears on channel output 1. The SSH loads the LVX output into the
packet, and it is visible on the SSN bus output. When observing a single chain, the EDT masking logic is
controlled, and the one-hot masking logic that is already part of the EDT propagates the selected chain to
the first EDT channel output and the other chains are masked off. When broadcasting the LVX payload to
all chains, the chain selected by lvx_chain_index is visible on the first channel output.

Tessent™ Shell User’s Manual 641

Streaming Scan Network (SSN)
Creating EDT With LVX Hardware

Figure 166. Propagation of LVX Scan Outputs With

enable_one_chain Hardware for Channel Output

If the enable_one_chain hardware is unavailable (broadcast-only hardware) during enable_all_chains

mode, the first scan chain output of each compactor propagates through the EDT channel output.

Figure 167. Propagation of the LVX Scan Output Without

enable_one_chain Hardware for Channel Output

642 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
LVX Operation Modes With LVX Hardware Configuration

When using the lvx_loop pattern with enable_one_chain, the SSH unloads channel 1 of each active EDT
back into the packet, and that random data is observable at the SSN bus output. The lvx_loop pattern
lacks the ability to confirm the current LVX configuration, because the expected output seen at the SSN
output does not provide a pass/fail status. The lvx_verification pattern, however, enables you to verify
and confirm the LVX payload. The lvx_verification pattern is functionally the same as the lvx_loop pattern
except that the output observed on the SSN bus output is compared against an expected value and
provides a pass/fail status. Changing an iWriteVar such as lvx_chain_index in the lvx_loop pattern causes
the two patterns, lvx_loop and lvx_verification, to differ.
When generating the lvx_verification pattern set, the tool generates sufficient data on the input side for
one full shift through the scan chains. This means that the pattern set consists of two patterns. The first is
applied and shifts in the LVX sequence into the scan chains, and the second unloads the LVX sequence
from the scan chains and compares it with the calculated expected sequence.
The following example pattern is from a STIL2005 file:

Pattern scan_test {
Ann {* Pattern:0 Vector:0 TesterCycle:0 *}
Call "test_setup" ;
Call "ssn_setup" ;
Ann {* Pattern:0 Vector:3436 TesterCycle:5109 *}
"pattern 0":
Macro "load_unload_edt_grp1"{"_ssn_datapath1_ssn_bus_data_in[0]_" =
010011111000001111100000111110000011111000001111100000111110;
"_ssn_datapath1_ssn_bus_data_out[0]_" = \r51 X HHHHHLLLL;
}
Ann {* Last unload *}
"last unload":
Macro "load_unload_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" =
000011111000001111100000111110000011111000001111100000111110;
"_ssn_datapath1_ssn_bus_data_out[0]_" =
LHHHHHLLLLLHHHHHLLLLLHHHHHLLLLL \r29 X ;
}
Call "test_end" ;
}

This pattern illustrates how every pattern has an expected sequence on the SSN bus data output ports.

LVX Operation Modes With LVX Hardware Configuration

Tessent LVX hardware can operate in several different modes that change the LVX behavior. The
hardware configuration for the enable_one_chain functionality affects how these modes behave.
You must specify the enable_one_chain hardware configuration to make the enable_one_chain mode
available. Whether or not your hardware configuration includes the enable_one_chain specification
affects how the LVX modes behave. Control the LVX hardware using core instance parameters. The
parameters in Table 30 apply to the EDT with LVX hardware, based on whether you created the EDT with
or without specifying enable_one_chain.
The following examples show how to specify the LVX mode with the "lvx_mode" parameter value in the
set_core_instance_parameters command:
# Select chain 5 with the lvx_chain_index parameter

Tessent™ Shell User’s Manual 643

Streaming Scan Network (SSN)
Configuring LVX Patterns
set_core_instance_parameters ‑instrument_type edt ‑parameter_values \
{lvx_mode enable_one_chain lvx_chain_index 5}

or
# Broadcast to all scan chains with the lvx_mode parameter

set_core_instance_parameters ‑instrument_type edt ‑parameter_values \

{lvx_mode enable_all_chains}

Table 30. LVX Modes With enable_one_chain Hardware Configuration

Hardware
Configuration LVX Mode Behavior

With off Normal non-LVX operation.

enable_one_chain
(default) enable_one_chain Specified chain gets the value from EDT channel input 1
and propagates the value through EDT output channel 1.
All other chains load 0s.
Default operation mode in pattern generation.
Default chain index is 0. Change this with the
"lvx_chain_index <int>" parameter.

enable_all_chains All chains get values from EDT channel input 1

(broadcast).
The specified chain propagates through EDT output
channel 1.

mask_all_chains All chains are masked on both input and output.

Without off Normal non-LVX operation.

enable_one_chain
enable_one_chain Not permitted.

enable_all_chains All chains get values from EDT channel input 1

(broadcast).
The first chain propagates through EDT output channel 1.

mask_all_chains All chains are masked on the input side by forcing 0 on

the first channel input.

Configuring LVX Patterns

Tessent LVX functionality contains a number of options that enable you to tailor the generated patterns to
meet your design needs. Unless otherwise specified, these configurations are optional.

Procedure
1. Configure LVX patterns and LVP settings with the set_lvx_options command.
General LVX configuration enables you to specify a subset of the active SSHs to target, a
sequence for the pattern set, and the minimum number of repetitions.
Refer to the Examples section, following, for examples of how various options may affect the LVX
pattern files.

644 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Configuring LVX Patterns

2. Configure EDT for LVX by setting the LVX mode with the set_core_instance_parameters
command.
This is typically for one of the following use cases:

• You have generated the EDT with enable_one_chain hardware, so that enable_one_chain is
the default LVX mode, and you want to switch to broadcast mode (enable_all_chains) instead.

• You want to change the default chain selected from chain 0. For example:
set_core_instance_parameters -instrument_type edt \
-parameter_values {lvx_mode enable_one_chain 487}

Examples
The following examples show variations in STIL files resulting from different configurations with the
set_lvx_options command. The gold text highlights important differences in the output.

Change Pattern Sequence (‑sequence)

Running "set_lvx_options ‑sequence 101101" alters the pattern sequence to 101101 from the default
sequence of 1100:

Default Sequence (1100)

Pattern scan_test {
//Pattern:0 Vector:0 TesterCycle:0
Ann {* Pattern:0 Vector:0 TesterCycle:0 *}
Ann {* Test_setup procedure omitted from this pattern set *}
//Pattern:0 Vector:0 TesterCycle:0
Ann {* Pattern:0 Vector:0 TesterCycle:0 *}
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 1;
}
//Pattern:1 Vector:1 TesterCycle:1
Ann {* Pattern:1 Vector:1 TesterCycle:1 *}
"pattern 1":
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 1;
}
//Pattern:2 Vector:2 TesterCycle:2
Ann {* Pattern:2 Vector:2 TesterCycle:2 *}
"pattern 2":
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 0;
}
Macro "scan_edt_grp1" {

Tessent™ Shell User’s Manual 645

Streaming Scan Network (SSN)
Configuring LVX Patterns
"_ssn_datapath1_ssn_bus_data_in[0]_" = 0;
}
Ann {* Total count Patterns:3 Vectors:4 TesterCycles:4 *}
}

set_lvx_options -sequence 101101

Pattern scan_test {
//Pattern:0 Vector:0 TesterCycle:0
Ann {* Pattern:0 Vector:0 TesterCycle:0 *}
Ann {* Test_setup procedure omitted from this pattern set *}
//Pattern:0 Vector:0 TesterCycle:0
Ann {* Pattern:0 Vector:0 TesterCycle:0 *}
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 1;
}
//Pattern:1 Vector:1 TesterCycle:1
Ann {* Pattern:1 Vector:1 TesterCycle:1 *}
"pattern 1":
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 0;
}
//Pattern:2 Vector:2 TesterCycle:2
Ann {* Pattern:2 Vector:2 TesterCycle:2 *}
"pattern 2":
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 1;
}
//Pattern:3 Vector:3 TesterCycle:3
Ann {* Pattern:3 Vector:3 TesterCycle:3 *}
"pattern 3":
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 1;
}
//Pattern:4 Vector:4 TesterCycle:4
Ann {* Pattern:4 Vector:4 TesterCycle:4 *}
"pattern 4":
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 0;
}
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 1;
}
Ann {* Total count Patterns:5 Vectors:6 TesterCycles:6 *}
}

Repeating Sequence to Generate Activity on All EDTs (‑repetitions

load_chains)
Running "set_lvx_options ‑repetitions load_chains" specifies for the tool to repeat the sequence in the
payload until there is sufficient activity across all EDTs. In this scenario, the tool repeated the sequence

646 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Configuring LVX Patterns
(1100) approximately 25 times for a single payload. This results in using 99 tester cycles, because each
bit in the sequence repeats 25 times. By default, the sequence in the payload does not repeat.

Default Behavior

Pattern scan_test {
//Pattern:0 Vector:0 TesterCycle:0
Ann {* Pattern:0 Vector:0 TesterCycle:0 *}
Ann {* Test_setup procedure omitted from this pattern set *}
//Pattern:0 Vector:0 TesterCycle:0
Ann {* Pattern:0 Vector:0 TesterCycle:0 *}
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 1;
}
//Pattern:1 Vector:1 TesterCycle:1
Ann {* Pattern:1 Vector:1 TesterCycle:1 *}
"pattern 1":
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 1;
}
//Pattern:2 Vector:2 TesterCycle:2
Ann {* Pattern:2 Vector:2 TesterCycle:2 *}
"pattern 2":
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 0;
}
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 0;
}
Ann {* Total count Patterns:3 Vectors:4 TesterCycles:4 *}
}

set_lvx_options -repetitions load_chains

Pattern scan_test {
//Pattern:0 Vector:0 TesterCycle:0
Ann {* Pattern:0 Vector:0 TesterCycle:0 *}
Ann {* Test_setup procedure omitted from this pattern set *}
//Pattern:0 Vector:0 TesterCycle:0
Ann {* Pattern:0 Vector:0 TesterCycle:0 *}
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 1;
}
//Pattern:1 Vector:1 TesterCycle:1
Ann {* Pattern:1 Vector:1 TesterCycle:1 *}
"pattern 1":
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 1;
}
//Pattern:2 Vector:2 TesterCycle:2
Ann {* Pattern:2 Vector:2 TesterCycle:2 *}
"pattern 2":

Tessent™ Shell User’s Manual 647

Streaming Scan Network (SSN)
Configuring LVX Patterns
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 0;
}
}
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 0;
}
…
//Pattern:96 Vector:96 TesterCycle:96
Ann {* Pattern:96 Vector:96 TesterCycle:96 *}
"pattern 96":
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 1;
}
//Pattern:97 Vector:97 TesterCycle:97
Ann {* Pattern:97 Vector:97 TesterCycle:97 *}
"pattern 97":
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 1;
}
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 0;
}
Ann {* Total count Patterns:98 Vectors:99 TesterCycles:99 *}
}

Repeating Sequence a Fixed Number of Times (‑repetitions <int>)

Running "set_lvx_options ‑repetitions 10" specifies that the sequence (1100) repeats 10 times in the
payload. This results in using 40 tester cycles to run one payload.

Default Behavior

Pattern scan_test {
//Pattern:0 Vector:0 TesterCycle:0
Ann {* Pattern:0 Vector:0 TesterCycle:0 *}
Ann {* Test_setup procedure omitted from this pattern set *}
//Pattern:0 Vector:0 TesterCycle:0
Ann {* Pattern:0 Vector:0 TesterCycle:0 *}
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 1;
}
//Pattern:1 Vector:1 TesterCycle:1
Ann {* Pattern:1 Vector:1 TesterCycle:1 *}
"pattern 1":
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 1;
}
//Pattern:2 Vector:2 TesterCycle:2
Ann {* Pattern:2 Vector:2 TesterCycle:2 *}
"pattern 2":
Macro "scan_edt_grp1" {

648 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Configuring LVX Patterns
"_ssn_datapath1_ssn_bus_data_in[0]_" = 0;
}
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 0;
}
Ann {* Total count Patterns:3 Vectors:4 TesterCycles:4 *}
}

set_lvx_options -repetitions 10

Pattern scan_test {
//Pattern:0 Vector:0 TesterCycle:0
Ann {* Pattern:0 Vector:0 TesterCycle:0 *}
Ann {* Test_setup procedure omitted from this pattern set *}
//Pattern:0 Vector:0 TesterCycle:0
Ann {* Pattern:0 Vector:0 TesterCycle:0 *}
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 1;
}
//Pattern:1 Vector:1 TesterCycle:1
Ann {* Pattern:1 Vector:1 TesterCycle:1 *}
"pattern 1":
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 1;
}
//Pattern:2 Vector:2 TesterCycle:2
Ann {* Pattern:2 Vector:2 TesterCycle:2 *}
"pattern 2":
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 0;
}
…
//Pattern:37 Vector:37 TesterCycle:37
Ann {* Pattern:37 Vector:37 TesterCycle:37 *}
"pattern 37":
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 1;
}
//Pattern:38 Vector:38 TesterCycle:38
Ann {* Pattern:38 Vector:38 TesterCycle:38 *}
"pattern 38":
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 0;
}
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 0;
}
Ann {* Total count Patterns:39 Vectors:40 TesterCycles:40 *}
}

Tessent™ Shell User’s Manual 649

Streaming Scan Network (SSN)
Configuring LVX Patterns

Repeating the Payload (‑payload_loop_count <int>)

Running "set_lvx_options ‑payload_loop_count 5" specifies that the payload repeats five times. In the
test payload, a Loop 5 wrapper surrounds the sequence (1100) of the payload. This instructs the ATE to
reapply the payload five times. By default, the payload is applied only once.

Default Behavior

Pattern scan_test {
//Pattern:0 Vector:0 TesterCycle:0
Ann {* Pattern:0 Vector:0 TesterCycle:0 *}
Ann {* Test_setup procedure omitted from this pattern set *}
//Pattern:0 Vector:0 TesterCycle:0
Ann {* Pattern:0 Vector:0 TesterCycle:0 *}
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 1;
}
//Pattern:1 Vector:1 TesterCycle:1
Ann {* Pattern:1 Vector:1 TesterCycle:1 *}
"pattern 1":
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 1;
}
//Pattern:2 Vector:2 TesterCycle:2
Ann {* Pattern:2 Vector:2 TesterCycle:2 *}
"pattern 2":
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 0;
}
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 0;
}
Ann {* Total count Patterns:3 Vectors:4 TesterCycles:4 *}
}

set_lvx_options -repetitions 10

Pattern scan_test {
//Pattern:0 Vector:0 TesterCycle:0
Ann {* Pattern:0 Vector:0 TesterCycle:0 *}
Ann {* Test_setup procedure omitted from this pattern set *}
Loop 5 {
//Pattern:0 Vector:0 TesterCycle:0
Ann {* Pattern:0 Vector:0 TesterCycle:0 *}
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 1;
}
//Pattern:1 Vector:1 TesterCycle:1
Ann {* Pattern:1 Vector:1 TesterCycle:1 *}
"pattern 1":
Macro "scan_edt_grp1" {

650 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Configuring LVX Patterns
"_ssn_datapath1_ssn_bus_data_in[0]_" = 1;
}
//Pattern:2 Vector:2 TesterCycle:2
Ann {* Pattern:2 Vector:2 TesterCycle:2 *}
"pattern 2":
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 0;
}
Macro "scan_edt_grp1" {
"_ssn_datapath1_ssn_bus_data_in[0]_" = 0;
}
} // end loop
Ann {* Total count Patterns:3 Vectors:4 TesterCycles:20 *}
}

Pulsing a Port at the Start of Each Pattern Set (‑sync_pulse_port and

‑sync_pulse_cycles)
Running "set_lvx_options ‑sync_pulse_port GPIO3_3 ‑sync_pulse_cycles 3" specifies that the tool pulses
the supplied port, GPIO3_3, for three cycles at the start of the pattern set, after which it forces it low for
the remainder of the payload. When the payload is reapplied, the tool again pulses the port for the first
three cycles.

Default Behavior

Pattern scan_test {
//Pattern:0 Vector:0 TesterCycle:0
Ann {* Pattern:0 Vector:0 TesterCycle:0 *}
Ann {* Test_setup procedure omitted from this pattern set *}
//Pattern:0 Vector:0 TesterCycle:0
Ann {* Pattern:0 Vector:0 TesterCycle:0 *}
Macro "scan_edt_grp1" {
"_ssn_datapath1_GPIO3_0_" = 1;
"_ssn_datapath2_GPIO3_1_" = 1;
}
//Pattern:1 Vector:1 TesterCycle:1
Ann {* Pattern:1 Vector:1 TesterCycle:1 *}
"pattern 1":
Macro "scan_edt_grp1" {
"_ssn_datapath1_GPIO3_0_" = 1;
"_ssn_datapath2_GPIO3_1_" = 1;
}
//Pattern:2 Vector:2 TesterCycle:2
Ann {* Pattern:2 Vector:2 TesterCycle:2 *}
"pattern 2":
Macro "scan_edt_grp1" {
"_ssn_datapath1_GPIO3_0_" = 1;
"_ssn_datapath2_GPIO3_1_" = 1;
}
//Pattern:3 Vector:3 TesterCycle:3
Ann {* Pattern:3 Vector:3 TesterCycle:3 *}
"pattern 3":

Tessent™ Shell User’s Manual 651

Streaming Scan Network (SSN)
Configuring LVX Patterns
Macro "scan_edt_grp1" {
"_ssn_datapath1_GPIO3_0_" = 1;
"_ssn_datapath2_GPIO3_1_" = 1;
}

//Pattern:4 Vector:4 TesterCycle:4

Ann {* Pattern:4 Vector:4 TesterCycle:4 *}
"pattern 4":
Macro "scan_edt_grp1" {
"_ssn_datapath1_GPIO3_0_" = 0;
"_ssn_datapath2_GPIO3_1_" = 0;
}
//Pattern:5 Vector:5 TesterCycle:5
Ann {* Pattern:5 Vector:5 TesterCycle:5 *}
"pattern 5":
Macro "scan_edt_grp1" {
"_ssn_datapath1_GPIO3_0_" = 0;
"_ssn_datapath2_GPIO3_1_" = 0;
}
//Pattern:6 Vector:6 TesterCycle:6
Ann {* Pattern:6 Vector:6 TesterCycle:6 *}
"pattern 6":
Macro "scan_edt_grp1" {
"_ssn_datapath1_GPIO3_0_" = 0;
"_ssn_datapath2_GPIO3_1_" = 0;
}
Macro "scan_edt_grp1" {
"_ssn_datapath1_GPIO3_0_" = 0;
"_ssn_datapath2_GPIO3_1_" = 0;
}
Ann {* Total count Patterns:7 Vectors:8 TesterCycles:8 *}
}

set_lvx_options -sync_pulse_port GPIO3_3 ‑sync_pulse_cycles 3

Pattern scan_test {
//Pattern:0 Vector:0 TesterCycle:0
Ann {* Pattern:0 Vector:0 TesterCycle:0 *}
Ann {* Test_setup procedure omitted from this pattern set *}
//Pattern:0 Vector:0 TesterCycle:0
Ann {* Pattern:0 Vector:0 TesterCycle:0 *}
Macro "scan_edt_grp1" {
"_ssn_datapath1_GPIO3_0_" = 1;
"_ssn_datapath2_GPIO3_1_" = 1;
"_datapath1_GPIO3_3_" = 1;
}
//Pattern:1 Vector:1 TesterCycle:1
Ann {* Pattern:1 Vector:1 TesterCycle:1 *}
"pattern 1":
Macro "scan_edt_grp1" {
"_ssn_datapath1_GPIO3_0_" = 1;

652 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Configuring LVX Patterns
"_ssn_datapath2_GPIO3_1_" = 1;
"_datapath1_GPIO3_3_" = 1;
}
//Pattern:2 Vector:2 TesterCycle:2
Ann {* Pattern:2 Vector:2 TesterCycle:2 *}
"pattern 2":
Macro "scan_edt_grp1" {
"_ssn_datapath1_GPIO3_0_" = 1;
"_ssn_datapath2_GPIO3_1_" = 1;
"_datapath1_GPIO3_3_" = 1;
}
//Pattern:3 Vector:3 TesterCycle:3
Ann {* Pattern:3 Vector:3 TesterCycle:3 *}
"pattern 3":
Macro "scan_edt_grp1" {
"_ssn_datapath1_GPIO3_0_" = 1;
"_ssn_datapath2_GPIO3_1_" = 1;
"_datapath1_GPIO3_3_" = 0;
}
//Pattern:4 Vector:4 TesterCycle:4
Ann {* Pattern:4 Vector:4 TesterCycle:4 *}
"pattern 4":
Macro "scan_edt_grp1" {
"_ssn_datapath1_GPIO3_0_" = 0;
"_ssn_datapath2_GPIO3_1_" = 0;
"_datapath1_GPIO3_3_" = 0;
}
…

//Pattern:13 Vector:13 TesterCycle:13

Ann {* Pattern:13 Vector:13 TesterCycle:13 *}
"pattern 13":
Macro "scan_edt_grp1" {
"_ssn_datapath1_GPIO3_0_" = 0;
"_ssn_datapath2_GPIO3_1_" = 0;
"_datapath1_GPIO3_3_" = 0;
}
//Pattern:14 Vector:14 TesterCycle:14
Ann {* Pattern:14 Vector:14 TesterCycle:14 *}
"pattern 14":
Macro "scan_edt_grp1" {
"_ssn_datapath1_GPIO3_0_" = 0;
"_ssn_datapath2_GPIO3_1_" = 0;
"_datapath1_GPIO3_3_" = 0;
}
Macro "scan_edt_grp1" {
"_ssn_datapath1_GPIO3_0_" = 0;
"_ssn_datapath2_GPIO3_1_" = 0;

Tessent™ Shell User’s Manual 653

Streaming Scan Network (SSN)
Writing LVX Loop Patterns
"_datapath1_GPIO3_3_" = 0;
}
Ann {* Total count Patterns:15 Vectors:16 TesterCycles:16 *}
}

Writing LVX Loop Patterns

Generate the LVX loop pattern set by writing separate patterns for setup and payload.

Note:
If you generate LVX loop and LVX verification patterns, you can reuse the ssn_setup procedures.
Refer to “Writing LVX Verification Patterns” on page 655 for more information.

Procedure
1. Generate the LVX loop setup files:
write_patterns lvx_test_setup.stil -test_setup only -stil
write_patterns lvx_ssn_setup.stil -ssn_setup only -pattern_sets lvx_loop -stil

The following alternative command generates combined setup patterns, which include both the
test_setup and ssn_setup procedures:
write_patterns lvx_all_setup.stil -all_setup_only -pattern_sets lvx_loop -stil

Note:
The test_setup procedure for LVX mode contains significant differences from the procedure
without LVX mode specified. In LVX mode, the procedure programs the IJTAG registers
inside the EDT. This does not occur outside LVX mode.

2. Generate the LVX loop payload:

write_patterns lvx_loop_payload.stil -test_payload -pattern_sets lvx_loop ‑stil

This writes the pattern set on which to loop onto the ATE.

Results
The lvx_loop pattern set includes the following functionality:

• It contains the shift vectors you loop through when performing LVI/LVP.

• There is no measurement of the datapath output for this payload.

• During LVX, you loop through the lvx_loop payload without applying an ssn_end procedure.

Note:
The chain index in the test_setup.stil file can be modified on the ATE, which eliminates needing to
rewrite the pattern for a different change index.

654 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Writing LVX Verification Patterns

Examples
Refer to the example in “Writing LVX Verification Patterns” on page 655, which contains both LVX loop
and LVX verification patterns.

Writing LVX Verification Patterns

Writing LVX verification patterns is optional when writing LVX loop patterns. The lvx_verification patterns
measure the SSN bus output, so you can use them to verify any arbitrary LVX sequence.
The lvx_verification pattern is functionally equivalent to the lvx_loop pattern, except that the output
observed on the SSN bus is compared against an expected value to provide a pass/fail status. The pass/
fail status confirms the response of the targeted shift registers. Do not loop on an LVX verification pattern.

Note:
Changing the chain_index from the value used when writing the lvx_verification pattern can lead
to pattern failures. The expected value is calculated based on the original chain_index. This
change can occur when the chain_index is switched to a chain with a different length or inversion.

Both the lvx_loop and lvx_verification pattern sets share the same ssn_setup programming. You can
optionally apply the lvx_verification pattern to the DUT to confirm the targeted shift register response.
Then you must apply the test_setup and ssn_setup for the lvx_loop before applying the lvx_loop payload
pattern.

Note:
You can generate the LVX verification setup and payload files before the LVX loop files.

Procedure
1. Generate the LVX verification setup files:
write_patterns lvx_test_setup.stil –test_setup only –stil
write_patterns lvx_ssn_setup.stil –ssn_setup only -pattern_sets lvx_verification ‑stil

The following alternative command generates combined setup patterns, which include both the
test_setup and ssn_setup procedures:
write_patterns lvx_all_setup.stil -all_setup_only -pattern_sets lvx_verification ‑stil

2. Generate the LVX verification payload:

write_patterns lvx_verification_payload.stil -test_payload \
‑pattern_sets lvx_verification ‑stil

Examples
The following example commands write the test_setup, ssn_setup, lvx_verification, and lvx_loop patterns.
write_patterns lvx_test_setup.stil –test_setup only ‑stil
write_patterns lvx_ssn_setup.stil –ssn_setup only -pattern_sets lvx_verification ‑stil
write_patterns lvx_verification.stil –test_payload -pattern_sets lvx_verification ‑stil
write_patterns lvx_loop.stil –test_payload -pattern_sets lvx_loop ‑stil

Tessent™ Shell User’s Manual 655

Streaming Scan Network (SSN)
LVI_PATCHING_INFO

Note:
The command to write the ssn_setup pattern uses the "‑pattern_sets lvx_verification" argument.
Because the SSN programming for lvx_loop and lvx_verification is identical for both patterns, you
can share the ssn_setup information for both the lvx_loop and lvx_verification patterns.

LVI_PATCHING_INFO
The LVI_PATCHING_INFO table enables the use of fault isolation techniques for SSN by providing two
pieces of information: the ICL instance name for EDT instances driving failing chains and the chain index
of the failing chain (as reflected in the STIL pattern).
LVI is an electrical fault isolation (EFI) technique for localizing defects in scan chains. LVI requires a
repeating periodic pattern on the chain of interest. This periodic pattern causes transistors in the scan
chain to turn on and off within the field of view of the LVI equipment. LVI collects the signals and analyzes
them in the frequency domain. The analysis detects transistors that switch with the expected pattern (and
those that do not) and produces an image.
During hardware generation in hierarchical DFT flows, the tool can only generate the LVX verification
pattern for the specified default chain. The tool can generate the loop pattern for any chain driven by
the LVX hardware. However, the tool's default pattern set contains the loop pattern for the default chain,
which is the same default chain specified when creating the LVX hardware. You can specify scan chains
with lvx_chain_index, or you can enable broadcast mode for all chains. Refer to “LVX Operation Modes
With LVX Hardware Configuration” on page 643 for more information.

Note:
For failure analysis (FA) purposes, you must patch the patterns to apply the looping pattern to
the (failing) chain of interest. When using SSN, usually the FA engineer that runs LVI patches the
patterns.

The goal of patching is to ensure that a repeating sequence drives the failing chain of interest. The FA
engineer requires the full ICL instance pathname of the EDT instance that drives the failing chain, and the
chain index of the failing chain to patch the original LVI patterns delivered by design engineering teams.
When the tool generates a diagnosis report, it automatically adds the LVI_PATCHING_INFO table within
the XMAP table if the design has LVI or LVP hardware present.

Example XMAP Table

The following example shows an LVI_PATCHING_INFO table within an XMAP table. The
LVI_PATCHING_INFO table contains the chain name and index, and the ICL and EDT instance names for
symptom 1.

diagnosis_mode=chain
#symptoms=1 #suspects=1 CPU_time=0.70sec fail_log=chain.flog

symptom=1 #suspects=1 faulty_chain=edt._chain_8 fault_type=STUCK

suspect score type value pin_pathname cell_name net_pathname \
----------------------------------------------------------------------------\
1 96 STUCK(CELL+OUT) 1 /XTEA…_reg[10]/Q SDFFR_X1 /XTEA…hi[10] \
----------------------------------------------------------------------------\

cell_number chain_name memory_type shift_clock

656 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
LVI_PATCHING_INFO
------------------------------------------------------------
34 edt…_chain_8 MASTER /xtea…_clock_out_mux_Z
------------------------------------------------------------

XMAP_TABLE_BEGIN
…
LVI_PATCHING_INFO_BEGIN
symptom chain_name chain_index ICL_instance EDT_instance
1 edt…_chain_8 7 xtea…_edt_c1_inst /xtea…_edt_c1_inst
LVI_PATCHING_INFO_END
…
XMAP_TABLE_END

ICL Instance Name of an EDT Controller

Patching starts by locating in your STIL pattern the ICL instance name of the EDT controller provided by
the LVI_PATCHING_INFO table. The following example is an excerpt of a STIL pattern. The "Targets"
annotation has LVX chain index variables that hold the chain index values for LVI inspection. Highlighted
in red is the ICL instance name of an EDT controller that has three variable bits for the lvx_chain_index
variable.

Ann {* + Targets: *}
Ann {* + Apply 0 *}
Ann {* + writes: *}
Ann {* + xtea_2.edt_three.edt_bypass = 0
*}
Ann {* + xtea_2.edt_three.edt_low_power_shift_en = 0
*}
Ann {* + xtea_2.edt_three.lvx_chain_index[1:0] = 00
*}
Ann {* + xtea_2.edt_three.lvx_mode[1:0] = 00
*}
Ann {* + xtea_2.xtea_rtl_tessent_edt_one_inst.edt_bypass = 0
*}
Ann {* + xtea_2.xtea_rtl_tessent_edt_one_inst.lvx_chain_index[2:0] = 000
*}
Ann {* + xtea_2.xtea_rtl_tessent_edt_one_inst.lvx_mode[1:0] = 00
*}

Relative Cycles by Pin

Tessent pragma annotations identify the relative cycles by pin to reach an ICL instance. In the following
pragma, the ICL instance name of the EDT controller is highlighted in red. The variable to patch is
lvx_chain_index. The range of variable bits of the chain index are in the value {2:0} of the ‑var_bits
parameter. The -pin parameter identifies the tdi pin. The relative cycles to patch on the tdi pin are in the
value {30:28} of the ‑relative_cycles parameter.

Tessent™ Shell User’s Manual 657

Streaming Scan Network (SSN)
LVI_PATCHING_INFO

Ann {* + Shift-DR *}
…
Ann {* TESSENT_PRAGMA variable
xtea_2.xtea_rtl_tessent_edt_one_inst.lvx_chain_index \
-type write \
-var_bits {2:0} -pin tdi -relative_cycles {30:28} *}
…

Signal Groups
The pin of the Tessent pragma is in a signal group of your pattern. In the following SignalGroups, the tdi
pin is in the _pi_ signal group at the third position from the end.

SignalGroups {
…
_pi_ = '"ssn_bus_data_in"[11] + "ssn_bus_data_in"[10] +
"ssn_bus_data_in"[9] + "ssn_bus_data_in"[8] + "ssn_bus_data_in"[7] +
"ssn_bus_data_in"[6] + "ssn_bus_data_in"[5] + "ssn_bus_data_in"[4] +
"ssn_bus_data_in"[3] + "ssn_bus_data_in"[2] + "ssn_bus_data_in"[1] +
"ssn_bus_data_in"[0] + "ssn_bus_clock" + "reset_pad" + "xtea_1_rst" +
"xtea_2_rst" + "tck" + "tdi" + "tms" + "trst"';
…
}

Vector Locations
Tessent pragma annotations at each bit variable mark vectors of each index location. The following
annotations identify the three vectors to patch.

Ann {* TESSENT_PRAGMA bit_variable \

xtea_2.xtea_rtl_tessent_edt_one_inst.lvx_chain_index \
-type write -var_bits {0} -pin tdi -inversion 0b0 *}
V {
_pi_=\r13 0 1001001;
_po_=\r13 X;
}
Ann {* TESSENT_PRAGMA bit_variable \
xtea_2.xtea_rtl_tessent_edt_one_inst.lvx_chain_index \
-type write -var_bits {1} -pin tdi -inversion 0b0 *}
V {
_pi_=\r13 0 1001001;
}
Ann {* TESSENT_PRAGMA bit_variable \
xtea_2.xtea_rtl_tessent_edt_one_inst.lvx_chain_index \
-type write -var_bits {2} -pin tdi -inversion 0b0 *}
V {
_pi_=\r13 0 1001001;
}

658 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Retention Testing With SSN

Retention Testing With SSN

Tessent SSN supports retention testing. If you use retention tests with SSN, you can enable the SSN
to lose its state and be part of the powered-off logic. The tool uses multiple pattern files to achieve this
functionality.
For a full description of Tessent Shell retention testing capabilities, refer to the section "Retention Test
Pattern Generation" in the Tessent Scan and ATPG User’s Manual.
To enable loss of state functionality, use the "set_retention_test_options
‑allow_ssn_to_lose_state_during_test" command. For more information about this functionality, refer to that
command description.
For SSN, the test_setup and ssn_setup procedures for retention are different from those of non-retention
pattern sets. Use the write_patterns command to write those two IJTAG procedures separately:
write_patterns retention_test_setup.stil -stil -test_setup only -pattern_sets retention -replace
write_patterns retention_ssn_setup.stil -stil -ssn_setup only -pattern_sets retention -replace

For more information about writing SSN patterns, with examples, refer to the section “Manufacturing
Patterns With SSN” on page 557.

Note:
We recommend that you write the IJTAG and payload procedures for all SSN patterns to separate
files.

Like logic test SSN patterns, SSN retention test patterns require failure mapping when a miscompare
is identified on the SSN bus output. The failure mapping step identifies the SSH the failing register is
associated with. You can identify the precise failing register using Tessent Diagnosis. The following is a
recipe for both failure mapping and diagnosis with a retention test pattern:

1. Failure mapping recipe:

a. set_context -failure_mapping

b. read_design <my_top.v>

c. read_core_description

d. set_current_design
check_design_rules

e. read_patterns <.stil…>

f. read_failures …<tessent failure file — cycle based>

g. write_failures <reverse mapped failure file>

2. Tessent Diagnosis recipe:

Tessent™ Shell User’s Manual 659

Streaming Scan Network (SSN)
Retention Testing With SSN

a. set_context -scan_diagnosis

b. read_flat_model <core_flat_model>

c. read_patterns <core_patterns>

d. read_failures <reverse mapped failure file> -pattern

For more information on the SSN failure mapping step and Tessent Diagnosis, refer to “Performing
Reverse Failure Mapping for SSN Pattern Diagnosis” on page 525 and the Tessent Diagnosis User’s
Manual.

Note:
Retention testing with SSN requires a scan host generated with a 2022.1 or newer release.
Streaming-Through-IJTAG mode does not support retention testing.

660 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Size Resolution Technology With SSN

Size Resolution Technology With SSN

Using size resolution technology with SSN enables you to reduce the size of the ScanHost node,
providing improvements in area and timing at the cost of flexibility and data efficiency.
The area of an SSN ScanHost node depends on the width of the SSN parallel bus and the size of the
EDT that connects to the node. The area of the typical SSH is comparable to an EDT, and adding on-
chip compare logic to an SSH generally makes it 1.5× to 2.0× larger than an EDT. However, for some
use models, an SSH with on-chip compare can be even larger if you are using logic redundancy or die
harvesting, or if you require a very large EDT when using on-chip compare. Furthermore, if you set
the sticky status resolution type for on-chip compare to output_chain, the area of the SSH can further
increase. In rare cases, it may be difficult to close timing when using a very wide parallel bus and a fast
bus_clock.
The flexibility of the SSH hardware can also contribute to the size of the SSH. The default ScanHost
hardware is flexible enough to support delivery of any number of bits based on the EDT and scan chains
it connects to. The hardware can operate on bits of any number (that is, multiples of one). For example,
the SSH can receive as little as one bit of data and as much as a full scan word of data during ATPG and
retargeting. (A full scan word is the amount of data shifted with a single clock pulse into all EDT input
channels, uncompressed scan chains, or the sum of both.)
Creating a ScanHost with size resolution technology can offset some of the factors contributing to an
increased SSH area. When you use a ScanHost equipped with size resolution, you give up some of the
efficiency of the SSH to gain better area and timing. An SSH with size resolution changes the minimum
number of bits that the SSH can deliver, instead operating on numbers of bits that are multiples of two,
four, or eight. As an example, an SSH with size resolution of four can deliver only a minimum of four bits,
and any number of bits that is a multiple of four. If ATPG or retargeting calls for a smaller number of bits,
the tool adds padding to increase the number of bits to satisfy the size resolution bit requirement.
Turn on size resolution by specifying the DftSpecification/SSN/Datapath/ScanHost/size_resolution
property. Legal values are 2, 4, and 8.
The following designs may benefit from size resolution technology:

• Designs with a ScanHost using on-chip compare that requires an EDT with a large output
channel count.

• Designs in which the area of the ScanHost is too large and must be reduced.

• Designs that fail to meet timing in the ScanHost.

CAUTION:
Size resolution can have a noticeable impact on scan data volume. Therefore, we recommend
using a ScanHost equipped with size resolution technology cautiously, and only when necessary.

The following circumstances are the most likely scenarios for which padding is necessary to meet size
resolution requirements:

• During ATPG when using an EDT with a smaller channel count for wrapper chains.

• When using on-chip compare where the output bits are not a multiple of the size resolution
requirements.

Tessent™ Shell User’s Manual 661

Streaming Scan Network (SSN)
Sample Area Reduction With Size Resolution

You can use a ScanHost equipped with size resolution technology during ATPG and scan pattern
retargeting. There are no limitations or restrictions associated with using ScanHost nodes with and
without size resolution technology together. You can also use ScanHosts with identical or different size
resolution values concurrently.

Sample Area Reduction With Size Resolution

Size Resolution Limitations

Sample Area Reduction With Size Resolution

ScanHost node area decreases more when you set larger size resolution values. You can expect up to
an 80% area reduction when on-chip compare is on and up to 60% when on-chip compare is off. This
percentage reduction remains consistent across different bus widths and EDT channel counts.
These area reduction patterns illustrate the trade-offs between size resolution value, bus width, EDT
channel count, and the presence of on-chip compare when considering area reduction gains from size
resolution.
The following examples demonstrate area savings for a ScanHost node with and without on-chip compare
functionality. These examples use builds with size resolution values of 2, 4, and 8. A size resolution value
of 1 represents the default setting with no size resolution and is the baseline 100% area.

On-Chip Compare: On
Figure 168 shows the decrease in the area of the ScanHost node using a 128-bit wide bus and different
EDT channel configurations. We recommend asymmetric EDT configurations when using on-chip
compare. The figure includes the following EDT configurations:

• 32 input and output channels

• 64 input channels and 32 output channels

• 128 input channels and 64 output channels

The ScanHost area decreases on an approximately linear basis with the size resolution value. You can
extrapolate comparable area savings when using a narrower or wider SSN bus for a ScanHost with on-
chip compare.

662 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Sample Area Reduction With Size Resolution

Figure 168. Size Resolution Area Savings With On-Chip Compare

On-Chip Compare: Off

For the same bus width and EDT configurations but without on-chip compare, a size resolution setting of
2 produces similar area savings to the case with on-chip compare. However, for size resolution values of
4 and 8, the area savings are approximately 20% less as compared to the ScanHost node with on-chip
compare. Refer to Figure 169 for details.

Tessent™ Shell User’s Manual 663

Streaming Scan Network (SSN)
Size Resolution Limitations

Figure 169. Size Resolution Area Savings Without On-Chip Compare

Size Resolution Limitations

A ScanHost node equipped with size resolution technology is subject to limitations on the values for the
SSN bus_width and input and output chain group bit counts. If these values are not multiples of the size
resolution value for the SSH, the tool may respond with an error or by padding packets.
The following table summarizes the tool response to values that are not multiples of the size resolution
setting. For more details, refer to the sections following the table.

Table 31. Size Resolution Value Limitations Summary

Value Not a Multiple of the SSH Size Resolution Setting Tool Response

SSN bus_width Error

Single chain group input or output bit count Pads packets

Sum of input or output bit counts for multiple chain groups Pads packets

Error Condition — Bus Width

The SSN bus_width must be a multiple of the size resolution value. If there are multiple ScanHost nodes
with different size resolution values, the bus width must satisfy all of them. If the bus_width is not a
multiple of the size resolution value, the tool reports an error.

664 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Size Resolution Limitations

For example, if the ScanHost has a size resolution value of 8 and the bus width (M in the following figure)
is 50 bits, the tool reports an error. You must change the bus width or the size resolution value to resolve
this error.

Figure 170. ScanHost With One chain_group

Padding Condition — Inputs and Outputs for a Single Chain Group

If a single chain_group is present, the SSH chain_group inputs and outputs must individually be a multiple
of the size resolution value of the ScanHost. If an input or output bit count is not a multiple of the size
resolution value, the tool adds padding to the packets to ensure that this condition is met.
Examples of Padding for a Single Chain Group
Refer to Figure 170 for these examples.

• If the SSH has a size resolution value of 8 and the EDT has one channel, the tool adds seven bits
of padding to satisfy the size resolution requirements.

• If the SSH uses on-chip compare, has a size resolution value of 8, and uses an EDT with one
output channel and a single on-chip compare status group, the tool calculates the number of
output bits as three (3 × the EDT output channel count). Because three is not a multiple of the
size resolution value, the tool adds padding to satisfy the size resolution requirements: it adds 21
bits to the 3 to make the total number of output bits a multiple of 8, because the tool adds padding
to each packet.

Padding Condition — Inputs and Outputs for Multiple Chain Groups

If multiple chain_groups are present, the sum of the input bit counts for the SSH chain_group must be a
multiple of the size resolution value of the ScanHost. Likewise, the sum of the output bit counts for the
SSH chain_group must also be a multiple of the size resolution value. If these sums are not multiples of
the size resolution value, the tool adds padding to the packets to ensure that this condition is met.

Tessent™ Shell User’s Manual 665

Streaming Scan Network (SSN)
Size Resolution Limitations

For example, in the following figure, the sums of the input bit counts for chain_group_1 and
chain_group_2 (A+C) must be a multiple of the SSH size resolution value, and the sums of the output bit
counts (B+D) must also be a multiple of the size resolution value.

Figure 171. ScanHost With Multiple chain_groups

Examples of Padding for Multiple Chain Groups

Refer to Figure 171 for these examples.

• If the SSH has a size resolution value of 4 and the input counts for the chain groups are 3 and 5,
then the sum (8) is a multiple of the size resolution value and the tool does not add padding.

• If the SSH has on-chip compare and a size resolution value of 4, and the output bit counts for the
chains are B=3 and D=5, the tool calculates the output bits for each chain group as 9 (3×B) and
15 (3×D). The sum of these output counts is 9+15=24, which is a multiple of the size resolution
value, so the tool does not add padding.

666 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Tessent SSN Examples and Solutions

Tessent SSN Examples and Solutions

This section contains Tessent solutions for DFT scenarios and problems specific to SSN. This includes
applications and flows that solve issues resulting from the presence of specific design objects or the use
of specific implementation flows.
The solutions are organized in the following sections:

Third-Party OCCs With SSN

Defining Multiple Physical ICL Datapaths for a Single Datapath Port

Third-Party OCCs With SSN

Third-party OCC connections require specific handling when you are using SSN.

Problem
Third-party OCCs need connections to scan_en and shift_capture_clock, which do not exist until the SSN
ScanHost node is inserted. This section explains how to automate these connections.

Solution
The third-party OCCs are assumed to be pre-inserted into the design when SSN is inserted as described
in the section “Second DFT Insertion Pass: Inserting Block-Level EDT, OCC, and SSN” on page 488. The
scan_en and slow_clock pins on the OCC instances are tied low.
Follow these steps to properly connect the OCC to the ScanHost node:

1. Before calling the check_design_rules command, run the "add_dft_control_points

‑type dynamic_dft_signal -dft_signal_name scan_en" command while pointing to the scan_en pin
of each OCC instance.

set occs [get_instances my_occ*]

add_dft_control_points [get_pins scan_en -of_inst $occ] \
-type dynamic_dft_control \
-dft_signal_source_name scan_en

2. Run the "add_dft_control_points -type dynamic_dft_signal -dft_signal_name shift_capture_clock"

command while pointing to the slow_clock pin of each OCC instance:

add_dft_control_points [get_pins slow_clock -of_inst $occ] \

-type dynamic_dft_control \
-dft_signal_source_name shift_capture_clock

Discussion
In the solution described in the previous subsection, you use the add_dft_control_points command to
make the scan_en and shift_capture_clock connections to the OCC. This is the general command you
use to connect any DFT signal to any destination. When you insert the ScanHost node, the insertion

Tessent™ Shell User’s Manual 667

Streaming Scan Network (SSN)
Defining Multiple Physical ICL Datapaths for a Single Datapath Port
process remaps dynamic DFT signals scan_en, edt_update, edt_clock, and shift_capture_clock to the
output pins of the ScanHost node.
Because the ScanHost node delivers the scan data in both the internal and external scan modes, your
third-party OCC must still be able to inject the slow_clock into the clock_domains when scan_en is high,
even when the OCCs are not active. In a wrapped core, you have an OCC on each clock input. Those
OCCs are active during the internal scan modes but are typically inactive during the external test modes,
such that the sourcing for the capture clock is from a single OCC localized at the functional clock source
of the domain. Those inactive OCCs must, however, still inject the shift_capture_clock generated by
the local ScanHost node when scan_en is high during the external modes. This is the shift_only_mode
feature described in the Tessent OCC reference page. The presence of this feature enables easier timing
closure because the entire shift timing is internal to the physical block and completely derived from the
SSN bus clock, as illustrated in the following figure:

Figure 172. Localized Scan Timing With Shift-Only Mode OCC

If you want your legacy scan access mechanism to coexist with SSN in your first few designs that use
SSN, add the scan_en and other dynamic DFT signals on their original sources as you do currently. Then,
continue to preconnect the scan_en and slow_clock inputs of your third-party OCC to those sources.
When the ScanHost node is inserted, the complete fanout of the specified sources moves so that the
output pins of the ScanHost node drive them, and your original sources are connected to the bypass_in
pins of the ScanHost. Refer to "Example 2 in the ScanHost" reference page for more information about
this flow.
Unlike with the Tessent OCC, you must describe the third-party OCC to the Tessent Tool. To do this, use
the "add_clocks -capture_only" command manually on each OCC output clock pin, and provide a clock
control definition as described in the "Support for Internal Clock Control" section of the Tessent Scan and
ATPG User’s Manual.

Defining Multiple Physical ICL Datapaths for a

Single Datapath Port
You can use scan multiplexers (SMUX) to define multiple physical ICL datapaths for a single ScanHost
datapath port. Then you can manually configure the ICL datapaths to specify which datapath the SSH
uses.

668 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Defining Multiple Physical ICL Datapaths for a Single Datapath Port

For a tile-based design, this enables you to vary the interface location for the tile by configuring multiple
potential datapaths and then specifying the datapath ID for each tile.
This procedure demonstrates how to define multiple ICL datapaths so you can select the necessary one.
It uses the example tile in the following figure. You can adapt this example for your own design needs.

Figure 173. Core Preparation for Multiple Datapaths to a Single Port

from_top
to_top

from_left to_right
SMUX

SMUX

SMUX

SSH

to_left from_right
from_bottom

to_bottom

Tessent™ Shell User’s Manual 669

Streaming Scan Network (SSN)
Defining Multiple Physical ICL Datapaths for a Single Datapath Port

Procedure
1. Set up the core shown in Figure 173 with the following DftSpecification:

DftSpecification(core,rtl) {
SSN {
ijtag_host_interface: Sib(ssn);
Datapath(1) {
output_bus_width : 4;
Connections {
bus_data_in : from_left[%d];
bus_data_out : to_left[%d];
}
ScanHost(1) {
ExtraOutputPath {
Connections {
bus_data_out : to_right[%d];
}
}
ExtraOutputPath {
Connections {
bus_data_out : to_top[%d];
}
}
ExtraOutputPath {
Connections {
bus_data_out : to_bottom[%d];
}
}
}
Multiplexer(from_right) {
Connections {
secondary_bus_data_in : from_right[%d];
}
}
Multiplexer(from_top) {
Connections {
secondary_bus_data_in : from_top[%d];
}
}
Multiplexer(from_bottom) {
Connections {
secondary_bus_data_in : from_bottom[%d];
}
}
}
}
}

2. Once you have configured the full DftSpecification, process it with the process_dft_specification
command.

670 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Defining Multiple Physical ICL Datapaths for a Single Datapath Port

The tool has defined a default ICL SSN datapath according to the DftSpecification, using the
Datapath/Connections wrapper:

INSERTION> get_icl_ssn_datapath_list
1
INSERTION> get_icl_ssn_datapath_ports -name 1
{
ssn_bus_clock
from_left[3]
from_left[2]
from_left[1]
from_left[0]
to_left[3]
to_left[2]
to_left[1]
to_left[0]
}

3. Define the ICL datapath combinations that are available for tile creation. Do this by removing the
default datapath and creating renamed versions manually, as with the following script:

delete_icl_ssn_datapaths -all
foreach from_direction {from_left from_right from_top \
from_bottom} {
foreach to_direction {to_left to_right to_top to_bottom} {
set icl_ssn_datapath [string cat $from_direction \
"_" $to_direction]
add_icl_ssn_datapaths $icl_ssn_datapath
set_icl_ssn_datapath_ports -name $icl_ssn_datapath \
-bus_data_inputs $from_direction \
-bus_data_outputs $to_direction \
-clock_inputs ssn_bus_clock
}
}

This creates the following ICL datapaths:

INSERTION> get_icl_ssn_datapath_list
from_bottom_to_bottom from_bottom_to_left from_bottom_to_right
from_bottom_to_top from_left_to_bottom from_left_to_left
from_left_to_right from_left_to_top from_right_to_bottom
from_right_to_left from_right_to_right from_right_to_top
from_top_to_bottom from_top_to_left from_top_to_right from_top_to_top
INSERTION> get_icl_ssn_datapath_ports -name from_right_to_bottom
{
ssn_bus_clock
from_right[3]
from_right[2]
from_right[1]
from_right[0]
to_bottom[3]

Tessent™ Shell User’s Manual 671

Streaming Scan Network (SSN)
Defining Multiple Physical ICL Datapaths for a Single Datapath Port
to_bottom[2]
to_bottom[1]
to_bottom[0]
}

This completes the setup for the core level. You can use any of the datapath combinations during
DFT insertion in the next level.

4. To connect tiles set up using this setup, specify the appropriate ICL datapath from the core-level
DFT insertion pass.
The following DftSpecification creates the connections in Figure 174:

DftSpecification(chip,rtl) {
SSN {
ijtag_host_interface: Sib(ssn);
Datapath(1) {
output_bus_width : 4;
Connections {
bus_data_in : GPIO[8:5];
bus_data_out : GPIO[3:0];
bus_clock_in : GPIO[4];
}
DesignInstance(core_i4) {
datapath : from_right_to_left;
}
DesignInstance(core_i3) {
datapath : from_top_to_left;
}
DesignInstance(core_i2) {
datapath : from_left_to_bottom;
}
DesignInstance(core_i1) {
datapath : from_left_to_right;
}
}
}
}

672 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
Defining Multiple Physical ICL Datapaths for a Single Datapath Port

Figure 174. Example Tile Configuration for Multiple Datapath Setup

from_top

from_top
to_top

to_top
from_left to_right from_left to_right
to_left from_right to_left from_right
to_top from_bottom

to_top from_bottom
from_top to_bottom

from_top to_bottom
from_left to_right from_left to_right
to_left from_right to_left from_right
from_bottom

from_bottom
to_bottom

to_bottom

Tessent™ Shell User’s Manual 673

Streaming Scan Network (SSN)
SSN Frequently Asked Questions

Note:
Each core instance has unused datapath ports. To prevent ICL I2 DRC violations, you must
set the connection_rule_option ICL attribute for those pins. You can define the attribute for
all pins, not only those that are not in use. The following is an example script:

set core_out_port_collection [get_icl_ports \

-direction output \
-of_modules [get_icl_modules core] \
-filter "tessent_ssn_datapath_ids != {}"]

set_attribute_value $core_out_port_collection \
-name connection_rule_option \
-value allowed_no_destination

set core_in_port_collection [get_icl_ports \

-direction input \
-of_modules [get_icl_modules core] \
-filter "tessent_ssn_datapath_ids != {}"]

set_attribute_value $core_in_port_collection \
-name connection_rule_option \
-value allowed_no_source

SSN Frequently Asked Questions

This section contains frequently asked questions and possible solutions about SSN.

1. Is it possible for an SSN datapath to have a branch that is narrower than the main
datapath?
Tessent SSN does support this, but it is not recommended. IPs with narrower bus widths than the
parent design are supported, but the IP is should be rebuilt with the proper width.
Use the SSN multiplexer node to isolate the narrower branch of the bus from the parent design.
When an SSH on the narrower bus is active, the effective bus width is scaled down to the
narrower bus width.
An IP with a wider bus than the parent design is not supported.

2. Can I have multiple independent active datapaths?

SSN supports multiple SSN datapaths operating concurrently at different frequencies for
retargeting. During top-level ATPG, the effective bus width is scaled down to the narrower
datapath width. The two datapaths are capture-aligned, with padding added to the packet to
ensure capture alignment.

3. Can I change the SSN bus_clock and shift_capture_clock frequencies during retargeting?
You can change the bus_clock and shift_capture_clock frequencies during retargeting after the
patterns have already been created at the block level.

674 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
SSN Frequently Asked Questions

During retargeting, set the set_current_physical_block command to the scope of the physical
block that you want to change either frequency. Use the set_load_unload_timing_options
command to change the frequencies.

Note:
The SSN bus_clock frequency operates at the slowest specified frequency set by the
set_load_unload_timing_options command at any physical block.

4. How do I exclude a physical block from top-level ATPG with SSN?

Do not add the core instance for the EDT inside the physical block that you want to exclude.
Without the core instance of the EDT added, the SSH is disabled and behaves as a two-stage
pipeline.

5. What design view of my physical blocks should I use during pattern retargeting?
Use the graybox design view of the physical block whose patterns you want to retarget.

6. How do I program my SSN multiplexer nodes?

Use the generated PDL to write the select of the SSN multiplexer using the set_test_setup_icall
command.

set_test_setup_icall \
"chip_top_ssh_insertion_tessent_ssn_mux_returnPath_inst.setup
select_secondary_bus 1" ‑append

7. How is the negative edge of scan_en synchronized across all SSH during top-level ATPG?
During top-level ATPG, one SSH may enter the capture state before another SSH in the same
active datapath. This may happen with certain bus configurations and is normal behavior. During
top-level ATPG, all active SSH nodes are capture-aligned. Each SSH receives the same number
of packets before entering or leaving the capture state. This guarantees that each physical block
does not miss any capture clock pulses.

8. Can I use a custom test_setup sequence with "pulse TCK" and "force TMS" to initialize an
analog IP and still use SSN?
Yes, add your custom test_setup sequence using the set_procfile_name command, and the SSN
initialization is appended at the end of your custom sequence.

9. How do I enable Streaming-Through-IJTAG?

Use the set_ssn_options command to enable the Streaming-Through-IJTAG mode.

set_ssn_options -streaming_interface ijtag

10. How do I decide the width of my SSN bus?

Reuse the same number of GPIO used for scan in/out without SSN. The SSN data_in and
data_out ports should be symmetrical.

Tessent™ Shell User’s Manual 675

Streaming Scan Network (SSN)
SSN Limitations

11. How fast can I run my SSN bus?

The default SSN bus_clock frequency is 400 MHz. A wide high-speed bus requires physical
resources. Consult with your physical implementation team to work within the physical design
budget.

12. Do all my physical blocks have to shift at the same frequency?

No, each physical block can shift at an independent frequency.

13. Can I change the shift frequency of one of my partitions during retargeting?
You can lower the shift frequency of a physical block after the patterns have been created. Set
the set_current_physical_block command to the physical block to change the frequency and use
the "set_load_unload_timing_options -shift_clock_period" command to change the shift clock
frequency. You can observe the changed frequency using the report_load_unload_timing_options
or get_load_unload_timing_options commands.

14. Do I have to insert SSH, EDT, and OCC in the same DFT insertion step?
The SSH, EDT, and OCC do not have to be created or inserted at the same time. However, if you
do not insert them at the same time in one DFT insertion step, you are responsible for making the
physical connections between them and for the multiplexing logic that shares the path back to the
SSH between external and internal test EDT channels.

SSN Limitations
Use of SSN is subject to limitations in pattern writing, ScanHost identification, failure mapping, Streaming-
Through-IJTAG mode, automatic configuration, and certain commands that are incompatible with SSN.

Pattern Writing Limitations

Pattern writing using the write_patterns command for designs including SSN has the following limitations:

• The following write_patterns command switches are not supported for SSN:

◦ -MEMory_size

◦ -SCAN_Memory_size

• For hierarchical designs, writing core-level patterns in the PatDB format using the write_patterns
command is the only source for retargeting scan patterns to the top level. ASCII format patterns
are not supported for retargeting.

• SSN patterns do not support SVF output format.

ScanHost Identification Limitations

Other instruments, such as EDT and OCC, can use the add_core_instances command to associate a
core description currently in memory with a specified core instance or instances in the design.

• Do not use the add_core_instances command to add SSN ScanHost core instances.

676 Tessent™ Shell User’s Manual

 Streaming Scan Network (SSN)
SSN Limitations

The ScanHost instances are inferred from the ICL, and the active ScanHost instances are automatically
identified.

Streaming-Through-IJTAG Limitations
The status of the on-chip compare self-test is available only through the SSN parallel output bus. If you try
to write the on-chip compare self-test using Streaming-Through-IJTAG, the tool reports an error.
You cannot use Streaming-Through-IJTAG if all of the following are true:

• The IJTAG control signals include additional pipelines to enable an increased TCK clock shift
frequency.

• One or more of the active scan hosts on that path are capture-aligned with other active scan
hosts in the streaming scan network.

• You are writing a pattern that requires capture alignment, such as "write_patterns ‑pattern_sets
scan" or "write_patterns ‑pattern_sets retention".
For more information about Streaming-Through-IJTAG, refer to the section “Streaming-Through-IJTAG
Scan Data” on page 535.

Automated SSN Datapath Configuration

SSN does not support automated programming of SSN multiplexers. You must manually configure these
multiplexers using IJTAG to ensure that all of the SSH you intend to use are along the active datapath
between the SSN bus_in and bus_out.

Manual Integration of SSN Datapath

The SSN datapath is subject to the following limitations for manual integration of the datapath:

• You must ensure there are no incidental inversions or permutations of bits on the SSN bus.

• The bit sequence of the datapath must be maintained throughout the SSN bus.

STARTPAT and ENDPAT in SSN Serial Testbench

SSN serial testbenches do not contain STARTPAT and ENDPAT statements. The STARTPAT/ENDPAT
mechanism does not work with serial testbenches in SSN, because the SSN stream is a single shift
pattern that cannot be broken up. If you need to break up the pattern manually, save it again using ‑begin
and ‑end values instead. Refer to the section "Verilog Plusargs" in the Tessent Scan and ATPG User’s
Manual for more information about using Verilog plusargs like STARTPAT and ENDPAT.

Reuse of SSN Datapath Wires in SSN Bypass Mode

If the tool is in SSN bypass mode ("set_ssn_options off") and you reuse the SSN datapath wires
for EDT channels, the tool requires an ATPG model to trace through any time multiplexing and Fifo

Tessent™ Shell User’s Manual 677

Streaming Scan Network (SSN)
SSN Limitations
nodes along the wires between the top-level pins and EDT. This includes the BusFrequencyDivider,
BusFrequencyMultiplier, and Fifo nodes.

678 Tessent™ Shell User’s Manual

 Chapter 10
Tessent Examples and Solutions
This chapter contains Tessent solutions for specific DFT scenarios and problems. This includes
applications and flows that solve common, difficult issues encountered in DFT.

How to Handle Parameterized Blocks During DFT Insertion

How to Avoid Simulation Issues When Using the Two-Pin Serial Port Controller
How to Handle Clocks Sourced by Embedded PLLs During Logic Test
How to Design Capture Windows for Hybrid TK/LBIST
How to Use Boundary Scan in a Wrapped Core
How to Use an Older Core TSDB With Newly-Inserted DFT Cores
TAP Configuration
How to Create a WSP Controller in Tessent Shell
How to Set Up Third-Party Synthesis
How to Set Up Support for Third-Party OCCs
Post-Synthesis Update

Tessent™ Shell User’s Manual 679

Tessent Examples and Solutions
How to Handle Parameterized Blocks During DFT Insertion

How to Handle Parameterized Blocks During

DFT Insertion
Physical blocks and sub-blocks that are parameterized in the top module of the block present special
challenges for DFT insertion. The Tessent solution handles all types of parameterization, including simple
parameters, parameterized types, SystemVerilog interface ports with modports, and SystemVerilog
generic interface ports.
The steps you must take depend on the degree of impact on the DFT insertion. This section covers
three different scenarios. In all three scenarios, the parameterized block is instantiated with parameter
overrides.
Multiple Unique Sets of Parameter Overrides with No Impact on RTL DFT Insertion
The simplest of the three scenarios has multiple unique sets of parameter overrides. However, the effect
of those parameter overrides on RTL DFT insertion is no different than the default parameter values.
Synthesis creates multiple netlists that must be mapped to a single RTL view.
Two or More Unique Sets of Parameter Overrides That Impact RTL DFT Insertion Differently
In the typical scenario, the parameter overrides affect RTL DFT insertion; however, the effect on insertion
for each set of overrides is the same. During insertion, the block must be instantiated in the same way
as it is instantiated in the parent block. Any of the override sets can be selected, because they all have
the same effect on insertion. Synthesis creates multiple netlists when there are multiple unique sets of
parameter overrides. Those netlists must be mapped to a single RTL view, as in the simplest scenario.
Two or More Unique Sets of Parameter Overrides That Impact RTL DFT Insertion Differently
In the most complex scenario, each set of parameter overrides can affect RTL DFT insertion differently.
The parameterized block must be uniquified such that all sets of parameter overrides associated with a
given uniquified block affect RTL DFT insertion in the same way. The material in this section regarding
insertion and the mapping of multiple netlists applies separately for each uniquified block.
The following topics provide full problem descriptions, solutions, and examples for all three of these
scenarios:

Problem
Solution
Discussion

Problem
Different design scenarios with parameterization wrappers have different impacts on the DFT insertion
process.
Multiple Unique Sets of Parameter Overrides with No Impact on RTL DFT Insertion
In the simplest scenario, the parameters have no impact on the DFT logic that is being inserted. In the
insertion steps the design is elaborated with its default parameter values. It makes no difference if the
parameter values are different when the block’s root module is instantiated into its parent module because
the parameters do not affect the DFT logic that is inserted. The distinctive characteristic of this scenario
is multiple unique sets of parameter overrides; therefore, synthesis creates multiple netlists. Those
netlists must be mapped to a single RTL view with DFT inserted. A small modification to the standard flow
enables this mapping.

680 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
Problem

In addition to having normal Verilog parameters, your design may have SystemVerilog interface ports
with modports or it may have parameterized types. In the first case, as long as the modports that are
specified when the block’s root module is instantiated do not affect RTL DFT insertion, the preceding
scenario and its solution are applicable. In the second case, as long as the actual type specified for the
parameterized type when the block’s root module is instantiated does not affect RTL DFT insertion, the
preceding scenario and its solution are applicable.
One or More Unique Sets of Parameter Overrides That Impact RTL DFT Insertion in the Same Way
In the typical scenario, the parameters do have an impact on the DFT logic inserted during RTL DFT
insertion. There may be multiple unique sets of parameter overrides; however, in this scenario, all of
them have the same effect on RTL DFT insertion. For example, your design may have a parameter that
controls the size of a generate loop which instantiates memories. Given that memory BIST must be
configured to test the right amount of memories, it is mandatory that, during DFT insertion, the parameter
be set to the same value it has when the block's root module is instantiated into its parent module.
Tessent Shell provides parameterization wrappers to ensure that the block’s root module is instantiated
in exactly the same way as in its parent module. A parameterization wrapper is a module that instantiates
the block's root module with the same parameter overrides used in the parent module's instantiation.
If the design has multiple unique sets of parameter overrides, the choice of which set to target in the
parameterization wrapper is arbitrary since they all have the same effect on RTL DFT insertion.
In addition, your design may have one or more of the following:

• System Verilog interface ports with modports specified in the instantiation of the block’s root
module. If the modports that are specified in the instantiation affect RTL DFT insertion, a
parameterization wrapper must ensure that the modports that are specified during insertion are
the same as in the parent module instantiation.

• System Verilog generic interface ports that are bound in the instantiation of the block’s root
module to System Verilog interface nets. In this case, a parameterization wrapper is always
required. You cannot perform stand-alone elaboration of the top module of a design that has
generic interface ports. The generic interface ports must be bound to actual interface nets.

• System Verilog parameterized types and the default types are overridden in the instantiation of
the block’s root module. If the actual types that are specified in the instantiation affect RTL DFT
insertion, a parameterization wrapper ensures that the types that are specified during insertion
are the same as in the parent module instantiation.
Parameterization wrappers properly handle those constructs; that is, they specify that the block’s root
module be instantiated with the same actuals (modports, interface nets, or types) as in the instantiation of
the block in the parent module.
Two or More Unique Sets of Parameter Overrides That Impact RTL DFT Insertion Differently
In the most complex scenario, your parameterized block must be uniquified in such a way that the sets of
parameter overrides associated with a given uniquified block have the same effect on RTL DFT insertion.
Tessent Shell provides a uniquification feature that enables you to associate multiple instantiations
with a single uniquified block. The Tessent flow facilitates the solution steps for each uniquified block.
Once you decide which instantiations of the block to associate with a given uniquified block, the tool
performs the required uniquification, creates the needed parameterization wrappers, and provides the
structures to facilitate RTL DFT insertion, synthesis, and gate-level insertion on each uniquified block and
its associated netlists.

Tessent™ Shell User’s Manual 681

Tessent Examples and Solutions
Solution

Solution
This section presents the Tessent parameterization wrappers solution flow.
“Tessent Shell Flow for Hierarchical Designs” on page 217 describes the basic flow. However, except for
the simplest scenario, you must add a step that performs uniquification of the top module of a block (when
required) and creates the parameterization wrappers. You must also replace a few existing command
sequences with new ones.
Figure 175 shows the flow for using parameterization wrappers. It uses the following conventions:

• Dashed red border—this is an additional step and is optional.

• Solid red border—this is an additional step and is mandatory.

• Solid black border—this is an existing step in the standard flow.

◦ Normal black text—this step has differences with the corresponding step in the standard flow.

◦ Gray text—this step is identical to the corresponding step in the standard flow.

682 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
Solution

Figure 175. Hierarchical DFT Insertion Flow With Parameterization Wrappers

The red step on the top left in Figure 175, Creation of parameterization wrappers and initial TSBDs,
creates parameterization wrappers for each parameterized child block that requires RTL DFT insertion.
For most parameterized designs, parameterization wrappers are required for insertion as well as for
synthesis. If your design has one or more unique sets of parameter overrides that impact RTL DFT
insertion in the same way, this step is mandatory. We also recommend this step in the simpler case of
multiple unique sets of parameter overrides with no impact on RTL DFT insertion. Refer to “Creation of
Parameterization Wrappers and Initial TSDBs for Typical Designs” on page 684 for details.
The red step on the top right in Figure 175, Block Uniquification and Creation of Parameterization
Wrappers and Initial TSDBs, uniquifies the design such that a given uniquified parameterized block is
only instantiated with parameter overrides that impact RTL DFT insertion in the same way. The tool must
create parameterization wrappers for each (possibly uniquified) parameterized block before it performs
RTL DFT insertion on the block. If your design has two or more unique sets of parameter overrides that
impact RTL DFT insertion differently, this step is mandatory. Refer to “Block Uniquification and Creation of
Parameterization Wrappers and Initial TSDBs for Complex Designs” on page 685 for details.
The remaining steps in Figure 175 apply to all three of the scenarios described in the Problem section.
The dashed red optional step, "Creation of the gate-level TSDB for a Physical Block", is required only if
you do not use Tessent Scan for scan insertion.

Tessent™ Shell User’s Manual 683

Tessent Examples and Solutions
Creation of Parameterization Wrappers and Initial TSDBs for Typical Designs

The following subsections describe the command changes in detail:

Creation of Parameterization Wrappers and Initial TSDBs for Typical Designs

Block Uniquification and Creation of Parameterization Wrappers and Initial TSDBs for Complex Designs
Modifications to the First DFT Insertion Pass for Blocks
Modifications to the Second DFT Insertion Pass for Blocks
Synthesis for Physical Blocks
Creation of the Gate-Level TSDB for a Physical Block
Scan Insertion for Physical Blocks
Modifications to the First DFT Insertion Pass for Chips
Modifications to the Second DFT Insertion Pass for Chips
Synthesis for the Chip Level

Creation of Parameterization Wrappers and Initial TSDBs

for Typical Designs
This step of the flow generates the parameterization wrappers for RTL DFT insertion, and generates
additional files that help automate many of the details of the synthesis flow and provide for predictable
naming of the netlists generated during synthesis. You must perform this step if your parameterized
design has one or more unique sets of parameter overrides that impact RTL insertion in the same
way. We also recommend this step if your parameterized design has multiple unique sets of parameter
overrides with no impact on RTL DFT insertion.
This step generates a parameterization wrapper for each view of a parameterized block. The tool
arbitrarily choses one of those wrappers during RTL DFT insertion to elaborate the block with the
proper parameter overrides. The synthesis tool uses all of the wrappers to generate a netlist for each
parameterized view of the block.
In this step of the flow, you tag the design files to indicate the block to which they belong, load
the design files, and elaborate the design. You then create a configuration specification for the
process_parameterized_design_specification command and invoke that command. That command
creates the parameterization wrappers for each parameterized block and the side files for synthesis. It
also creates a TSDB with a sub-directory for each block and writes the blocks to the TSDB. Finally, it
verifies the correctness of the design source dictionaries for the blocks.

Prerequisites
None.

Procedure
1. Specify the Tessent Shell context with a unique design_id and set the TSDB output directory:

set_context dft -rtl -design_id rtl0

set_tsdb_output_directory golden_rtl_contexts.tsdb

2. Tag the design files to indicate the block to which they belong and load the design files:

set_read_design_tag <root_module_name_of_block>
read_verilog <design_files_for_the_block>

684 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
Block Uniquification and Creation of Parameterization Wrappers and Initial TSDBs for Complex Designs

Repeat these two commands for each block you list in the configuration specification, including the
top block of the design. You must invoke the set_read_design_tag command before loading the
design files for each block.

3. Elaborate the design:

set_current_design <root_module_name_of_top_block>

4. Create the configuration specification:

read_config_data -replace -from_string {

ParameterizedDesignSpecification(<root_module_name_of_top_block>,
<design_level_of_block>) {
Block(<root_module_name_of_block>,<design_level>) {
// The design_level must be physical_block, sub_block, or chip.
}
…
}
}

Refer to the description of the ParameterizedDesignSpecification in the Tessent Shell Reference

Manual for the full syntax of the configuration specification. Include a Block wrapper for each
parameterized block and each ancestor block of a parameterized block. You must include the
immediate parent blocks to generate the side files that promote error-free linking of child netlists
to root module names in child block instantiations in the parent block during synthesis. Include the
remaining ancestor blocks to facilitate hierarchical insertion up to the top block.

5. Invoke the process_parameterized_design_specification command:

process_parameterized_design_specification
ParameterizedDesignSpecification(<root_module_name_of_top_block>, <de
sign_level_of_block>)

The tool creates an initial set of TSDBs for the blocks. The next step is “Modifications to the First
DFT Insertion Pass for Blocks” on page 687. We also recommend that you use the synthesis
approach exemplified in the scripts in “Synthesis Guidelines for Parameterization Wrapper Flows”
on page 994.
For a discussion of these steps applied to an example design, refer to “Creation of the
Parameterization Wrappers and Initial TSDBs” on page 694.

Block Uniquification and Creation of Parameterization

Wrappers and Initial TSDBs for Complex Designs
This step of the flow uniquifies the design as specified in the following configuration specification. Each
parameterized block must be uniquified such that any two sets of parameter overrides used to instantiate
the block have the same effect on RTL DFT insertion. You must perform this step if your parameterized
design has two or more unique sets of parameter overrides that impact RTL DFT insertion differently.
This step of the flow also generates the parameterization wrappers for RTL DFT insertion, and generates
additional files that help automate many of the details of the synthesis flow and provide for predictable
naming of the netlists generated during synthesis.

Tessent™ Shell User’s Manual 685

Tessent Examples and Solutions
Block Uniquification and Creation of Parameterization Wrappers and Initial TSDBs for Complex Designs

This step generates a parameterization wrapper for each view of a uniquified block. The tool arbitrarily
chooses one of those wrappers during RTL DFT insertion to elaborate the block with the proper
parameter overrides. The synthesis tool uses all of the wrappers to generate a netlist for each
parameterized view of the block.
In this step of the flow, you tag the design files to indicate the block to which they belong, load
the design files, and elaborate the design. You then create a configuration specification for the
process_parameterized_design_specification command and invoke that command. That command
uniquifies the blocks and creates the parameterization wrappers and side files for synthesis. It creates
a TSDB with a sub-directory for each block and writes the blocks to the TSDB. Finally, it verifies the
correctness of the design source dictionaries for the blocks.

Prerequisites
None.

Procedure
1. Specify the Tessent Shell context with a unique design_id and set the TSDB output directory:

set_context dft -rtl -design_id rtl0

set_tsdb_output_directory golden_rtl_contexts.tsdb

2. Tag the design files to indicate the block to which they belong and load the design files:

set_read_design_tag <root_module_name_of_block>
read_verilog <design_files_for_the_block>

Repeat these two commands for each block listed in the configuration specification described as
follows, including the top block of the design. You must invoke the set_read_design_tag command
before loading the design files for each block.

3. Elaborate the design:

set_current_design <root_module_name_of_top_block>

4. Create the configuration specification:

read_config_data -replace -from_string {

ParameterizedDesignSpecification(<root_module_name_of_top_block>,\
<design_level_of_block>) {
Block(<root_module_name_of_block>, <design_level>) {
// The design_level must be one of
// physical_block, sub_block, or chip.
UniquificationGroup {
Instances {
<path_to_instance_of_root_module_of_block>
…
// List all instances whose parameter overrides have the
// same effect on RTL DFT insertion.
}
}
UniquificationGroup {
Instances {

686 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
Modifications to the First DFT Insertion Pass for Blocks
<path_to_instance_of_root_module_of_block>
…
// List all instances whose parameter overrides have the
// same effect on RTL DFT insertion.
}
}
…
// The uniquification groups must cover all block instances.
}
…
// List all parameterized blocks and all ancestors of such
// blocks.
}
}

Refer to the description of the ParameterizedDesignSpecification in the Tessent Shell Reference

Manual for the full syntax of the configuration specification.
You must create UniquificationGroup wrappers if your parameterized design has two or more
unique sets of parameter overrides that impact RTL DFT insertion differently. List the ancestor
blocks for two reasons:

• You must list the immediate parent blocks to generate the side files that promote error-free
linking of child netlists to root module names in child block instantiations in the parent block
during synthesis.

• You must list the remaining ancestor blocks in case uniquification of such blocks is implied by
uniquification of a child block and to facilitate hierarchical insertion up to the top block.

5. Invoke the process_parameterized_design_specification command as follows:

process_parameterized_design_specification \
ParameterizedDesignSpecification(<root_module_name_of_top_block>,\
<design_level_of_block>)

The tool creates an initial set of TSDBs for the blocks. The next step is “Modifications to the First
DFT Insertion Pass for Blocks” on page 687. We also recommend that you use the synthesis
approach exemplified in the scripts in “Synthesis Guidelines for Parameterization Wrapper Flows”
on page 994.
For a discussion of these steps applied to an example design, refer to “Block Uniquification and
Creation of Parameterization Wrappers and Initial TSDBs” on page 700.

Modifications to the First DFT Insertion Pass for Blocks

You must make the changes in this step of the flow to use parameterization wrappers.

Prerequisites
• Refer to “First DFT Insertion Pass: Performing Block-Level MemoryBIST” on page 222 and
modify that flow as follows:

Tessent™ Shell User’s Manual 687

Tessent Examples and Solutions
Modifications to the Second DFT Insertion Pass for Blocks

Procedure
1. Immediately after setting the TSDB output directory, open the TSDB created in the first step of the
flow:

open_tsdb golden_rtl_contents.tsdb

2. Open the TSDBs for any immediate child blocks:

open_tsdb <root_module_name_of_block>.tsdb

3. Load the interface modules for any immediate child blocks in case those modules have external
dependencies:

read_design <root_module_name_of_block> -design_id \

<id_of_last_RTL_insertion_pass> -view interface

4. Replace the invocations of the read_verilog command for your block’s design files with the
following read_design command:

read_design <root_module_name_of_block> ‑design_id rtl0

Results
These modified steps of the flow accomplish the following actions:

• The tool automatically loads the parameterization wrapper for the block and uses it to elaborate
the design.

• The tool loads any files containing external dependencies that are present in the parameterization
wrapper but not in the block’s RTL design files.

Modifications to the Second DFT Insertion Pass for

Blocks
You must make the changes in this step of the flow to use parameterization wrappers.

Prerequisites
• Refer to “Second DFT Insertion Pass: Inserting Block-Level EDT and OCC” on page 224 and
modify that flow as follows:

Procedure
1. Open the TSDBs for any immediate child blocks:

open_tsdb <root_module_name_of_block>.tsdb

2. Load the interface modules for any immediate child blocks in case those modules have external
dependencies:

688 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
Synthesis for Physical Blocks

read_design <root_module_name_of_block> -design_id \

<id_of_last_RTL_insertion_pass> -view interface

3. Replace the invocations of the read_verilog command for your block’s design files with the
following read_design command:

read_design <root_module_name_of_block> ‑design_id rtl1

4. Replace the invocation of write_design_import_script with the following:

set td synth/[get_master_module_name]
file delete -force $td
file mkdir $td
write_design_import_script $td/analyze.tcl -use_relative_path $td \
-include_child_physical_block_interface_modules -replace

Results
These modified steps of the flow accomplish the following actions:

• The tool automatically loads the parameterization wrapper for the block and uses it to elaborate
the design.

• The tool loads any files containing external dependencies that are present in the parameterization
wrapper but not in the block’s RTL design files.

• The -include_child_physical_block_interface_modules option of the write_design_import_script

command causes the tool to load the interface modules for the child blocks and any files needed
to resolve external dependencies in the interface modules.

• The write_design_import_script command creates a separate analyze.tcl file for each

parameterized view of the block to distinguish any differences in external dependencies across
views. Those files are distinguished by the suffix "_<i>", where "i" is an integer starting at 1.

Synthesis for Physical Blocks

The parameterization wrapper flows present special challenges for synthesis. We supply Tcl procs
for interoperability purposes to help you manage the files created by the flow when using third-party
synthesis tools.
Refer to “Synthesis Guidelines for Parameterization Wrapper Flows” on page 994 for more information.
Refer to “Synthesis for Physical Blocks Example” on page 696 for a discussion of an example.

Creation of the Gate-Level TSDB for a Physical Block

This step of the flow is required if you do not use Tessent Scan for scan insertion. You must create a gate-
level TSDB to contain the synthesized physical blocks and associated side files. Repeat this step for each
physical block netlist.

Tessent™ Shell User’s Manual 689

Tessent Examples and Solutions
Scan Insertion for Physical Blocks

Prerequisites
None.

Procedure
1. Specify the Tessent Shell usage context with a unique design_id:

set_context dft -no_rtl -design_id gate

2. Specify the same TSDB output directory you used in the first and second RTL DFT insertion
passes:

set_tsdb_output_directory <RTL DFT

insertion output directory>

3. Load the synthesized netlist:

read_verilog <path to netlist>

4. Load the design data for the last RTL insertion pass:

read_design <root_module_name_of_RTL_block> -design_id \

<id_of_last_RTL_insertion_pass> -no_hdl

5. Load the gate level interface views of any child physical blocks:

read_design <root_module_name_of_synthesized_netlist> \
-design_id gate -view interface

6. Elaborate the design. Use the "icl_module" option to map the netlist back to the correct RTL block:

set_current_design <root_module_name_of_synthesized_netlist> \
-icl_module <root_module_name_of_RTL_block>

7. Set the design level:

set_design_level physical_block

8. Write the design to the TSDB:

write_design -tsdb -softlink_netlist

Scan Insertion for Physical Blocks

The standard Tessent flow to perform scan insertion for a physical block applies with potential
modifications for designs with parameterized blocks. The changes in this step are required only if your
parameterized block is instantiated using more than one unique set of parameter overrides. In that case,
you must add the -icl_module option to the set_current_design command to map the netlist to the correct
RTL view.

690 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
Modifications to the First DFT Insertion Pass for Chips

Prerequisites
• Refer to “Performing Scan Chain Insertion: Wrapped Core” on page 229 and modify that flow as
follows:

Procedure
When the design is elaborated using the set_current_design command, use the -icl_module option to
map the netlist back to the correct RTL block:

set_current_design <root_module_name_of_synthesized_netlist> \
-icl_module <root_module_name_of_RTL_block>

Modifications to the First DFT Insertion Pass for Chips

You must make the changes in this step of the flow to use parameterization wrappers.

Prerequisites
• Refer to “First DFT Insertion Pass: Performing Top-Level MemoryBIST and Boundary Scan” on
page 243 and modify that flow as follows:

Procedure
1. Immediately after setting the TSDB output directory, open the TSDB created in the first step of the
flow:

open_tsdb golden_rtl_contents.tsdb

2. Open the TSDBs for any immediate child blocks:

open_tsdb <root_module_name_of_block>.tsdb

3. Load the interface modules for any immediate child blocks in case those modules have external
dependencies:

read_design <root_module_name_of_block> -design_id \

<id_of_last_RTL insertion_pass> -view interface

4. Replace the invocations of the read_verilog command for your block’s design files with the
following read_design command:

read_design <root_module_name_of_block> ‑design_id rtl0

Modifications to the Second DFT Insertion Pass for Chips

You must make the changes in this step of the flow to use parameterization wrappers.

Tessent™ Shell User’s Manual 691

Tessent Examples and Solutions
Synthesis for the Chip Level

Prerequisites
• Refer to “Second DFT Insertion Pass: Inserting Top-Level EDT and OCC” on page 245 and
modify that flow as follows:

Procedure
1. Open the TSDBs for any immediate child blocks:

open_tsdb <root_module_name_of_block>.tsdb

2. Load the interface modules for any immediate child blocks in case those modules have external
dependencies:

read_design <root_module_name_of_block> -design_id \

<id_of_last_RTL insertion_pass> -view interface

3. Replace the invocations of read_verilog for your block’s design files with the following:

read_design <root_module_name_of_block> ‑design_id rtl1

4. Replace the invocation of write_design_import_script with the following:

set td synth/[get_master_module_name]
file delete -force $td
file mkdir $td
write_design_import_script $td/analyze.tcl -use_relative_path $td \
-include_child_physical_block_interface_modules -replace

The -include_child_physical_block_interface_modules option causes the tool to load the interface

modules for the child blocks and any files needed to resolve external dependencies in the interface
modules.

Synthesis for the Chip Level

The parameterization wrapper flows present special challenges for synthesis. We supply Tcl procs
for interoperability purposes to help you manage the files created by the flow when using third-party
synthesis tools.
Refer to “Synthesis Guidelines for Parameterization Wrapper Flows” on page 994 for more information.
Refer to “Synthesis for the Chip Level Example” on page 697 for a discussion of an example.

692 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
Discussion

Discussion
Parameterization wrappers enable you to succinctly describe design variations at a high level. The
Tessent solution handles all types of parameterization, including simple parameters, parameterized types,
SystemVerilog interface ports with modports, and SystemVerilog generic interface ports.
The following examples show how to apply this capability for different design types:

Typical Scenario Without Uniquification

Complex Scenario With Uniquification

Tessent™ Shell User’s Manual 693

Tessent Examples and Solutions
Typical Scenario Without Uniquification

Typical Scenario Without Uniquification

The example chip shown in the following figure shows how the Tessent tools handle typical design
scenarios. The typical scenario has one or more unique sets of parameter overrides that impact RTL
insertion in the same way. This example also applies to the simpler scenario of multiple unique sets of
parameter overrides with no impact on RTL DFT insertion. The example shows how parameterization
wrappers can be used to perform RTL DFT insertion in parameterized blocks in designs with one or more
unique sets of parameter overrides that impact RTL insertion in the same way, which is the typical case.
In Figure 176, processor_core is a parameterized physical block that is instantiated three times with
three sets of parameter overrides, only two of which are unique. The parameters are indicated using
the symbols P1 and P2. The values in each box are the parameter overrides. In the simplest case, the
overrides have no effect on RTL DFT insertion. In the typical case, the overrides do affect RTL DFT
insertion and the effect is the same for all three sets.

Figure 176. Example Chip With Parameterized Physical Blocks

The following topics apply to this example of a typical scenario. They also discuss common modifications
to the flow for parameterization wrappers in all three scenarios detailed in “Problem” on page 680.

Creation of the Parameterization Wrappers and Initial TSDBs

Synthesis for Physical Blocks Example
Synthesis for the Chip Level Example
Creation of the Gate-Level TSDB for a Physical Block (Optional)
Scan Insertion for a Physical Block

Creation of the Parameterization Wrappers and Initial TSDBs

The script in the following example creates the parameterization wrappers for the two views of
processor_core as well as the initial TSDBs.
Refer to “Creation of Parameterization Wrappers and Initial TSDBs for Typical Designs” on page 684 for
more information about this step.
In lines 39-40, the Block wrapper for processor_core is empty because no uniquification is required.
In lines 46-47, the process_parameterized_design_specification command creates the parameterization
wrappers, the TCD, the design source dictionaries, and the info dictionaries needed for synthesis, and
then writes the initial TSDBs.

694 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
Creation of the Parameterization Wrappers and Initial TSDBs

Example 47. Script for Creation of Parameterization Wrappers and Initial TSDBs

1 set_context dft -rtl -design_id rtl0

2 # Create a separate TSDB for the parameterization wrapper files
and other
3 # files needed for synthesis.
4 set_tsdb_output_directory golden_rtl_contexts.tsdb
5 read_cell_library ./library/standard_cells/tessent/adk.tcelllib
6 # Point to Verilog libraries for pad I/O macros.
7 set_design_sources -format verilog \
8 -v ./top/rtl/noncore_blocks/pad8_io_macro.v \
9 -v ./top/rtl/noncore_blocks/iopad_sel.v \
10 -v ./top/rtl/noncore_blocks/iopad.v
11 # Create a list for the top block files.
12 set file_list(chip_top) {
13 {./top/rtl/noncore_blocks/pll.v -interface_only \
14 -exclude_from_file_dictionary}
15 {./top/rtl/chip_top.v}
16 {./top/rtl/rds_process.v}
17 }
18 # Tag the top block with the name of its top module and read the
19 # top block files.
20 set_read_design_tag chip_top
21 foreach file $file_list(chip_top) {
22 read_verilog $file
23 }
24 # Tag each child block with the name of its top module and read
the
25 # block's files.
26 set_read_design_tag processor_core
27 read_verilog -f ./wrapped_cores/processor_core/rtl_file_list
28 # Point to the memory library model.
29 set_design_sources -format tcd_memory -y ./library/memories \
30 -ext tcd_memory
31 # Read the memory Verilog model.
32 read_verilog ./library/memories/*.v -exclude_from_file_dictionary
33 # Elaborate the complete design (top block and its child blocks).
34 set_current_design chip_top
35 # Create the configuration specification for this multi-level
36 # parameterized design.
37 read_config_data -replace -from_string {
38 ParameterizedDesignSpecification(chip_top, chip) {
39 Block(processor_core, physical_block) {
40 }
41 }
42 }
43 # Apply the configuration specification to the elaborated design
to
44 # create the parameterization wrappers and other files mentioned
above.

Tessent™ Shell User’s Manual 695

Tessent Examples and Solutions
Synthesis for Physical Blocks Example
45 # Write out the initial TSDBs.
46 process_parameterized_design_specification \
47 ParameterizedDesignSpecification(chip_top, chip)

In this example, the processor_core physical block is instantiated with parameter overrides that affect RTL
DFT insertion and requires modifications to the first pass and second pass DFT insertion steps.
Refer to the following sections for more information on modifications to the RTL DFT insertion passes:

• “Modifications to the First DFT Insertion Pass for Blocks” on page 687

• “Modifications to the Second DFT Insertion Pass for Blocks” on page 688

• “Modifications to the First DFT Insertion Pass for Chips” on page 691

• “Modifications to the Second DFT Insertion Pass for Chips” on page 691
In the step in the second pass of DFT insertion that invokes the write_design_import_script command, the
‑include_child_physical_block_interface_modules option is not applicable at the block level in this example
because processor_core has no child blocks. However, it is applicable in the general case and in the
second RTL DFT insertion pass for chip_top in this example.
For further discussion of this example, proceed to “Synthesis for Physical Blocks Example” on
page 696.

Synthesis for Physical Blocks Example

The script in the following example shows how the synthesis step for a physical block works with
parameterization wrappers.
Refer to “Synthesis Guidelines for Parameterization Wrapper Flows” on page 994 for more information
including the synthesize_block Tcl proc.
This example script creates a netlist for each of the two views of processor_core: processor_core_1 and
processor_core_2.

Example 48. Script for Synthesis of a Physical Block

1 set design_name processor_core

2 set design_id rtl2
3 set tsdb ../../wrapped_cores/processor_core/tsdb_outdir_pv1
4 set preserve_type icl_extract
5 set clock_dictionary { dco_clk {3.0 dco_clk} }
6 # Directives to the synthesis tool. Add others for your flow.
7 set_app_var timing_enable_multiple_clocks_per_reg true
8 set_app_var
compile_enable_constant_propagation_with_no_boundary_opt
9 set_app_var compile_seqmap_propagate_high_effort false
10 set_app_var compile_delete_unloaded_sequential_cells false
11 set_app_var sh_continue_on_error false
12 set_app_var sh_script_stop_severity E
13 # Source the Tcl script
14 source <path_to_synthesis_flow_procs>/flow_procs.tcl
15 # Invoke top-level proc

696 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
Synthesis for the Chip Level Example
16 synthesize_block $design_name $design_id $tsdb \
17 -preserve_type $preserve_type \
18 -clock_dictionary_name clock_dictionary

Synthesis for the Chip Level Example

The script in the following example shows how the synthesis step for the top level of a chip works with
parameterization wrappers.
Refer to “Synthesis Guidelines for Parameterization Wrapper Flows” on page 994 for more information
including the synthesize_block Tcl proc.
This script creates the netlist for the chip_top. The netlist instantiates processor_core_1 and
processor_core_2. This synthesis script differs from the script in “Synthesis for Physical Blocks Example”
on page 696 only in the values of the design_name and clock_dictionary variables.

Example 49. Script for Synthesis of the Top Block

1 set design_name chip_top

2 set design_id rtl2
3 set tsdb ../../top/tsdb_outdir
4 set preserve_type icl_extract
5 set clock_dictionary { REF_CLK {48.0 REF_CLK} }
6 # Directives to the synthesis tool. Add others for your flow.
7 set_app_var timing_enable_multiple_clocks_per_reg true
8 set_app_var
compile_enable_constant_propagation_with_no_boundary_opt \
9 false
10 set_app_var compile_seqmap_propagate_high_effort false
11 set_app_var compile_delete_unloaded_sequential_cells false
12 set_app_var sh_continue_on_error false
13 set_app_var sh_script_stop_severity E
14 # Source the Tcl script
15 source <path>/flow_procs.tcl
16 # Invoke top-level proc
17 synthesize_block $design_name $design_id $tsdb \
18 -preserve_type $preserve_type \
19 -clock_dictionary_name clock_dictionary

Figure 177 shows the post-synthesis diagram for the example design shown in the figure in “Typical
Scenario Without Uniquification” on page 694. Two separate netlists are created for processor_core:
processor_core_1 and processor_core_2.

Tessent™ Shell User’s Manual 697

Tessent Examples and Solutions
Creation of the Gate-Level TSDB for a Physical Block (Optional)

Figure 177. Example Chip - Post Synthesis

Creation of the Gate-Level TSDB for a Physical Block (Optional)

The script in the following example creates the gate-level TSDB. You must perform this step if you do not
use Tessent scan insertion.
Line 11 maps the netlist processor_core_1 to the top ICL module in the RTL view processor_core. The
tool creates a new TSDB for this gate-level view in line 15. In this TSDB, the ICL is uniquified. This step
must be repeated for the processor_core_2 netlist.
Refer to the Scan Insertion for a Physical Block topic for a detailed discussion of the ICL uniquification
process.

Example 50. Script for Creation of the Gate-Level TSDB for a Physical Block

1 # Set the design_id in the set_context command to "gate".

2 set_context dft –no_rtl –design_id gate
3 # Output directory for the first and second RTL DFT insertion
passes is
4 # assumed to be tsdb_outdir. Specify that as the output
directory here:
5 set_tsdb_output_directory tsdb_outdir
6 # Load the synthesized netlist for processor_core_1 as follows:
7 read_verilog <path to netlist file for processor_core_1>
8 # Load the design data for the second RTL DFT insertion pass as
follows:
9 read_design processor_core_1 –design_id rtl2 –no_hdl
10 # Elaborate the design as follows:
11 set_current_design processor_core_1 –icl_module processor_core
12 # Set the design level as follows:
13 set_design_level physical_block
14 # Write the design to the TSDB as follows:
15 write_design –tsdb –softlink_netlist

Scan Insertion for a Physical Block

For processor_core, there are two sets of parameter overrides. Although those overrides have the same
impact on DFT insertion, the synthesis tool generates two netlists—one for each unique set of parameter
overrides. When the ICL extraction was performed on processor_core, only one ICL module was created

698 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
Scan Insertion for a Physical Block
for the top module of the block. When one of the netlists is elaborated in preparation for scan insertion,
map that netlist to the proper ICL module in the RTL view.
Use the set_current_design command as follows:
set_current_design processor_core_<i> -icl_module processor_core

where <i> indicates which netlist is being elaborated.

The -icl_module option specifies the ICL module that maps to the netlist being elaborated. After scan
insertion is completed, a new TSDB is created for this gate-level view. Because there are two gate views
for processor_core, the corresponding ICL needs to be uniquified. All references to processor_core are
updated to either processor_core_1 or processor_core_2 in the .icl, .tcd, and .tsdb_info files.
When scan insertion is done at the parent level (chip_top) and the new TSDB is written, the ICL hierarchy
which is referenced in the chip_top.icl file is updated to reflect both netlists for the processor_core block.
The ChildBlockModules wrappers in the .tcd and .tsdb_info files are updated as well.

Tessent™ Shell User’s Manual 699

Tessent Examples and Solutions
Complex Scenario With Uniquification

Complex Scenario With Uniquification

The example chip in the following figure demonstrates how you can use parameterization wrappers to
perform RTL DFT insertion in parameterized blocks that need uniquification.

Figure 178. Chip With Parameterized Physical Blocks

The block processor_core is a parameterized physical block that is instantiated three times with three sets
of parameter overrides. These parameters are shown in the figure as P1 and P2. The values shown in
each block are the parameter overrides. The overrides for PROCESSOR_1 and PROCESSOR_2 have
the same effect on DFT insertion. The overrides for PROCESSOR_3 affect DFT insertion differently than
those for the other two instances.

Block Uniquification and Creation of Parameterization Wrappers and Initial TSDBs

Block Uniquification and Creation of Parameterization Wrappers

and Initial TSDBs
This example focuses on the uniquification of the processor_core block for the complex scenario with two
or more unique sets of parameter overrides that impact RTL DFT insertion differently.
This example shows only the changes to the steps in “Creation of the Parameterization Wrappers and
Initial TSDBs” on page 694 for a typical design.
The following example shows the additional uniquification steps required for a design with two or more
unique sets of parameter overrides that impact RTL DFT insertion differently.

Example 51. Specifying the Uniquification Requirements in the Configuration Specification

1 # The steps from the typical scenario up to creation of the

configuration
# specification are the same for this scenario.
2 # Create the configuration specification for this multi-level
# parameterized design.
3 read_config_data -replace -from_string {
ParameterizedDesignSpecification(chip_top, chip) {
Block(processor_core, physical_block) {
UniquificationGroup {
Instances {
PROCESSOR_1;

700 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
Block Uniquification and Creation of Parameterization Wrappers and Initial TSDBs
PROCESSOR_2;
}
}
UniquificationGroup {
Instances {
PROCESSOR_3;
}
}
}
}
}
4 # Apply the configuration specification to the elaborated design
to
# uniquify the design, create the parameterization wrappers, and create
# the info dictionary files needed for synthesis. Write out the initial
# TSDBs.
5 process_parameterized_design_specification \
ParameterizedDesignSpecification(chip_top, chip)

By default, the tool prefixes each uniquified block name with the top block name, chip_top in this example.
This enables the uniquified block to be used in multiple contexts.
The tool uniquifies the processor_core block such that the parameter overrides that are associated with
the instances specified in the uniquification group wrapper have the same effect on RTL DFT insertion.
Figure 179 shows the same design after uniquification for the example design shown in “Complex
Scenario With Uniquification” on page 700. The tool uniquifies the block processor_core into
chip_top_processor_core_pv1 and chip_top_processor_core_pv2.

Figure 179. Example Chip (Post-Uniquification)

In this example, the processor_core physical block is instantiated with parameter overrides that affect RTL
DFT insertion and requires modifications to the first pass and second pass DFT insertion steps.
Refer to the following sections for more information on modifications to the RTL DFT insertion passes:

• “Modifications to the First DFT Insertion Pass for Blocks” on page 687

• “Modifications to the Second DFT Insertion Pass for Blocks” on page 688

Tessent™ Shell User’s Manual 701

Tessent Examples and Solutions
How to Avoid Simulation Issues When Using the Two-Pin Serial Port Controller

• “Modifications to the First DFT Insertion Pass for Chips” on page 691

• “Modifications to the Second DFT Insertion Pass for Chips” on page 691
For further discussion of this example, proceed to “Synthesis for Physical Blocks Example” on page 696.

How to Avoid Simulation Issues When Using

the Two-Pin Serial Port Controller
You may observe some compare failures during signoff simulations using the Two-Pin Serial Port (TPSP)
interface. This topic describes a common cause and its solution.

Problem
Some pad models with internal pull resistors also model delays for the pull value, which allows a "Z"
or "X" value to propagate to the clock pin of the TRST generator. This causes a simulation artifact that
propagates an "X" on the network’s TRST signal and effectively fails the simulation.

Solution
The failure is purely a simulation artifact. The solution uses a Verilog side file that prevents an
undetermined value from propagating to the TRST generator’s clock pins.

`timescale 1ns/1ns
module tpsp_artifact_solution;
`ifndef TPSP_INST
`define TPSP_INST top_rtl_tessent_twopinserialport_tpsp_inst
`endif
always@(TB.DUT_inst.`TPSP_INST.tessent_persistent_cell_spio_in_trst_clk_buf.A) begin
if (TB.DUT_inst.`TPSP_INST.tessent_persistent_cell_spio_in_trst_clk_buf.A === 1'bx)
force TB.DUT_inst.`TPSP_INST.tessent_persistent_cell_spio_in_trst_clk_buf.Y = 1'b0;
else
#0.1 release TB.DUT_inst.`TPSP_INST.tessent_persistent_cell_spio_in_trst_clk_buf.Y;
end
endmodule

Using the "run_testbench_simulation" command inside Tessent Shell

1. Create a Verilog side file using the preceding code, such as "tpsp_artifact_solution.v".

2. Determine the path to your TPSP instance. If you do not know the path, then you can use the
following commands to find it.
set tpsp_module [get_icl_modules -filter tessent_instrument_subtype=="tpsp_controller"]
set tpsp_icl_instance [get_icl_instances -of_modules $tpsp_module]
set tpsp_instance [get_single_name [get_instances -of_icl_instances $tpsp_icl_instance]]
set tpsp_sim_path [convert_design_path_format $tpsp_instance -to_dot_separator]

702 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
How to Avoid Simulation Issues When Using the Two-Pin Serial Port Controller

3. Define the library sources for simulation in the Tessent shell.

set_simulation_library_sources -v ../data/sim_models.v ../data/pad_models.v

4. Run the simulation using the extra options to provide the TPSP controller’s path, the extra Verilog
side file, and the module inside.
run_testbench_simulations \
-simulation_macro_definitions "TPSP_INST=$tpsp_sim_path" \
-extra_verilog_files ../data/tpsp_artifact_solution.v \
-extra_top_modules tpsp_artifact_solution

Using the Questa Simulator outside Tessent Shell

1. Create a Verilog side file using the preceding code, such as "tpsp_artifact_solution.v".

2. Load your design files with Questa’s "vlog" command.

3. Load the side file and provide the path to the TPSP controller instance using the "+define+"
command unless it is hard coded in the side file.
vlog -work dut_work "../../../../data/tpsp_artifact_solution.v" \
+define+TPSP_INST=path.to.instance.top_rtl_tessent_twopinserialport_tpsp_inst

4. Run the simulation using Questa’s "vsim" command, adding the module’s name from the Verilog
side file. (Use "acc" optimization if simulating with SDF.)
vsim -lib "dut_work" -L dut_work -do 'run -all; exit' \
-voptargs=\"+acc\" \
p1_configuration \
p1_sdf \
tpsp_artifact_solution

Discussion
The failure is purely a simulation artifact. The proposed solution is to use a Verilog side file to prevent an
undetermined value from propagating to the TRST generator’s clock pins.
The Two-Pin Serial Port (TPSP) controller is an interface for the 1149.1 TAP controller and can drive a
TAP with two pins on the chip boundary. A 4-bit shift register inside the TPSP generates the TRST signal
pulse for the TAP controllers it drives.

Tessent™ Shell User’s Manual 703

Tessent Examples and Solutions
How to Handle Clocks Sourced by Embedded PLLs During Logic Test

Figure 180. TRST Pulse Generator inside TPSP

In Figure 180, an undetermined value (X) may occur on the internal spio_in net and reach the clock pin of
the TRST generator (shown in red), causing corruption of the simulation results. This register is sensitive
to these states, and the TPSP protocol is such that the inout port is put in a high impedance state every
third cycle. For these reasons, Tessent Shell requires a pull resistor modeled for the SPIO port, whether
an Inout Pad or Input Pad model.
The pull value drives the input immediately if the pad has no delay modeled. The registers do not get
corrupted, and the simulation ends with the correct results. However, if your pad models a delay for the
pull value, you will observe the problem. This problem is purely a simulation artifact and is not present
during manufacturing tests, and you can use a Verilog side file to avoid it.
To solve the simulation artifact when your pad model has a delay on the pull value, you can use
a Verilog side file to prevent a corrupting value from reaching the TRST generator registers’
clock pins. The side file changes the behavior of the persistent buffer inside the TPSP controller,
"tessent_persistent_cell_spio_in_trst_clk_buf" (refer to Figure 180), to disable the propagation of
an undetermined value through the buffer. The output of the buffer cell (Y) is forced to "0" when the
undetermined value is present on its input (A). The forced value is released with minor delay when the
value on the buffer’s input becomes determined.
An example Verilog side file was provided in the “Solution” on page 702. The code uses the `define
statement to provide the TPSP controller instance’s design path. However, the path could be hard coded
as well. Copy the code and create a new Verilog side file (Step 1). Before you can compile your new
Verilog side file and run it with the testbench generated by Tessent, you must define values for several
Tcl variables (Step 2). Define the library sources for simulation using the set_simulation_library_sources
command (Step 3). Finally, run the run_testbench_simulations command with extra options to use the
Verilog side file (Step 4).
You can also compile and run the new Verilog side file directly in a simulation tool such as Questa. Copy
the code and create a new Verilog side file (Step 1). Load your design files into the Questa simulator
(Step 2). Load the Verilog side file and define the path to the TPSP controller instance using a +define+
statement unless it is already hard coded in the side file (Step 3). Finally, run Questa simulation using the
additional options to utilize the Verilog side file (Step 4).
In summary, you can use a Verilog side file to resolve a simulation artifact. A pad modeled with a delay
on the pull value exhibits the problem. You can use a Verilog side file to prevent "X" value propagation by
changing the behavior of a buffer inside the TPSP. The side file solution works with a Tessent testbench
inside the Tessent shell or the Questa simulator outside the Tessent shell.

How to Handle Clocks Sourced by Embedded

PLLs During Logic Test
Clocks sourced by an embedded PLL have local OCCs that are reused when testing parent physical
regions. The flow is different when the parent physical regions are wrapped cores.

704 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
How to Handle Clocks Sourced by Embedded PLLs During Logic Test

Problem
For embedded PLLs, such as the one shown inside corec in Figure 181, the OCC inserted on the VCO
output of the PLL is used during the internal logic test modes of the core. The OCC is also reused during
the internal test modes of its parent physical regions.
When the PLL is inside a wrapped core that is the child of another wrapped core, you must ensure that
the OCC is still controllable by the scan chains when running logic test modes of the top level.

Solution
Wrapped Core Only Used in the Top Level
If the PLL is embedded inside a wrapped core that is only used inside the top level physical region,
then no further action is needed. The standard flow handles this scenario automatically, as described in
“Tessent Shell Flow for Hierarchical Designs” on page 217.
Wrapped Cores Used Inside Other Wrapped Cores
You must use the following procedure when the wrapped core in which the embedded PLL is located has
another wrapped core above it, as shown in Figure 181.

1. Add an extra DFT signal when you process the wrapped core that embeds the PLL in “Second
DFT Insertion Pass: Inserting Top-Level EDT and OCC” on page 245 (for example, when
processing corec) as follows:

add_dft_signals promoted_cells_mode

2. Create a new scan mode when you process the wrapped core that embeds the PLL in the Scan
Chain Insertion step (for example, when processing corec) as follows:

set promoted_instances \
[get_attributed_objects \
-attribute_name wrapper_type_from_clock_source \
-object_type instance]
if {[sizeof_collection $promoted_instances] > 0} {
add_scan_mode promoted_cells_mode \
-include_elements [get_scan_elements \
-of_instances $promoted_instances]
}

The new scan mode contains the control flip-flops of the OCCs that need to be accessible from
the top-level.

3. Modify the definition of the external scan mode when you process the parent wrapped core in the
scan chain insertion step of the flow (for example, when processing corea).

set_attribute_value corea_i1 -name active_child_scan_mode \

-value promoted_cells_mode

set ext_scan_elements [add_to_collection \

[get_scan_elements -class wrapper] \
[get_scan_elements -of_child_scan_modes promoted_cells_mode ]]

Tessent™ Shell User’s Manual 705

Tessent Examples and Solutions
How to Handle Clocks Sourced by Embedded PLLs During Logic Test

add_scan_mode ext_mode -chain_length 32 \

-include_elements $ext_scan_elements

Modifying the external scan mode definition enables you to include the promoted scan chains
from the child wrapped cores in the external chain of the current wrapped core. This step ensures
that the control flip-flops of the embedded OCCs are accessible by the test modes of the top
level.

4. Depending on the hierarchy of your design, do one of the following:

◦ If your design only uses the wrapped core at the top level of the chip (such as corea), then no
further modifications are required for the standard flow.

◦ If your design embeds the wrapped core inside another wrapped core (for example, there was
a layer of wrapped core between corea and top), you need to recreate the promoted scan
mode at the current level.
This step provides access to the OCC control bits in its external scan mode. The method
shown in Step 3 is reapplied to that parent wrapped core as follows:

set_attribute_value corea_i1 -name active_child_scan_mode \

-value promoted_cells_mode
add_scan_mode promoted_cells_mode \
-include_elements [get_scan_elements \
-of_child_scan_modes promoted_cells_mode]

Discussion
The example chip shown in the following figure illustrates functional clocking when a PLL is embedded
inside a child physical region.

Figure 181. Example Chip With PLL Embedded Inside Lower Core

Figure 182 shows the location of the OCCs inserted inside corec and coreb. The two OCCs inside corec
are active during its internal test modes to inject the shift clock during the shift cycles and to chop the
functional clocks during capture cycles. The two OCCs inside coreb are also active during its internal test
modes.

706 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
How to Handle Clocks Sourced by Embedded PLLs During Logic Test

Figure 182. Active OCCs During Internal Test Modes of corec and coreb

If you want to run the internal test modes of corec in parallel with those in coreb, you need to provide a
clock bypass path, such that the free running output of the PLL can continue to source the red clock of
coreb when the OCC inside corec is active.
The bypass clock path is not required. The tool issues an error if you try to re-target an internal test mode
of coreb in parallel with an internal test mode of corec or corea, and the bypass path is not present. The
reason for this check is that the OCC at the input of the red domain of coreb expects and requires a free
running clock when active. The red clock output of corea is not a free running clock when the red OCC
inside corec is active. Instead, it is alternating between the shift clock and bursts of at-speed clock pulses.
If you provide the bypass clock path, you reduce the overall chip test time as you can concurrently
test corec or corea with coreb. If you want to insert the clock bypass path within the DFT insertion
process, use a process_dft_specification.post_insertion callback to create the ports and make the
connections. Use the intercept_connection command to insert the multiplexer inside coreb. The best
option to control the select input of the multiplexer is to register and add a new DFT signal. Refer to the
register_static_dft_signal_names command for more information.
The get_dft_signal command in the process_dft_specification.post_insertion callback gets the connection
point for the added DFT signal. If the bypass path is manually added in the golden RTL, leave the
select input of the multiplexer tied low and connect it to the DFT signal during the DFT process with the
add_dft_control_points command. Refer to of the register_static_dft_signal_names command description
section for an example.
When you move up to corea, another OCC is inserted at the base of the blue clock domain to be used
during its internal logic test modes, as shown in Figure 183.

Tessent™ Shell User’s Manual 707

Tessent Examples and Solutions
How to Handle Clocks Sourced by Embedded PLLs During Logic Test

Figure 183. Active OCCs During Internal Test Modes of corea and coreb

The OCC on the blue domain inside corec is kept inactive, as it is during the functional mode. The
clocking of the entire blue clock domain is controlled by the OCC located inside of corea at the base of
the clock tree. The red OCC inside corec is active during the internal test mode of corea to control the
scannable flip-flops on the red domain inside corea, as well as the wrapper flops on the red domain inside
corec. Because the "fast_clock" input of that red OCC is not sourced by an input of corec, its scan chain
is automatically promoted to its wrapper chains. This promotion enables the scan chain to be under ATPG
control when running the internal test mode of corea.
If corec was not embedded within another wrapped core (such as coreb that is directly instantiated in the
top level), the handling is completely automated and no deviation from the standard flow, described under
“Tessent Shell Flow for Hierarchical Designs” on page 217, is necessary. However, when the wrapped
core containing the embedded PLL is inside another wrapped core, you must follow the steps described
under “Solution” on page 705 to enable the embedded OCC inside corec to be under ATPG control at
the top level.
Extra DFT Signals
Figure 184 shows the active OCCs when running the logic test mode of the top level. The red OCC inside
corec is active, which requires that the scan segment that contains the control flip-flops of the red OCC
must be accessible by the scan chains of the top level. This requirement is why Step 1 shows how to add
a new DFT signal called promoted_cells_mode to use as the enable for that scan chain configuration.
The OCCs within the cores are implemented with the shift only mode parameter. This has the advantage
of keeping the internal core shift timing identical between internal and external modes. The relative
shift timing between the many functional clock domains and the EDT clock domain is derived from the
common test_clock entering each core. You can close timing during layout on each core and not have to
wait until you run final STA from the top level to know how fast each core shifts in external mode.

708 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
How to Handle Clocks Sourced by Embedded PLLs During Logic Test

Figure 184. Active OCCs During Test Modes of Top Level

If the OCCs do not have the shift only mode, the shift clock is injected through the red and the blue
OCCs. The relative timing of the shift clock as it arrives at the input of the two clocks inside coreb is not
known until the clock trees of the two functional clocks are completed, which does not happen until you
complete the layout of the top level.
When you use the add_dft_signals command to add the ext_ltest_en DFT signal to a given core, the
OCCs of that core are automatically equipped with the shift only mode.
New Scan Mode
Step 2 shows how to create the scan mode that contains the control flip-flops of the promoted OCCs. The
OCC instances that have their fast_clock input controlled by an internal source have an attribute named
wrapper_type_from_clock_source set on them automatically. The get_attributed_objects command is
used to find them and make them part of the special scan mode.
Promoted Scan Chains
When you get to the corea level, you need to promote the special scan chain on corec into the wrapper
chain of corea, such that the control flip-flops of the red OCC are under ATPG control from the top level.
This task is described in step 3.
Step 4 provides instructions for when corea is not directly instantiated into the top level, but instead
is embedded within another wrapper core. In that case, you need a special scan mode to collect the
embedded OCC chains such that they can be included in the wrapper chains of the parent wrapped
core. You follow step 3 on the parent wrapped core to include the promoted scan mode of corea within its
wrapper chain.
The purple line in Figure 184 represents the promoted scan chain that contains the control flip‑flops of
the red OCC. This scan segment is inserted in the ext_mode of corea in step 3 such that the OCC is part
of the scan chains of the top level.

Related Topics
Tessent OCC Types and Usage

OCC

Tessent™ Shell User’s Manual 709

Tessent Examples and Solutions
How to Design Capture Windows for Hybrid TK/LBIST

How to Design Capture Windows for Hybrid

TK/LBIST
A capture window is a group of capture cycles defined by one or more clocks. Test logic can be
configured to run a selected number of patterns for each capture window. This approach gives full control
over the patterns to optimize test coverage and test power consumption.

Problem
The fundamental objectives for LBIST are increased test coverage, decreased test time, and lower power
consumption for the test run. In a typical flow, the full set of data needed to perform optimal insertion
to meet these objectives is not available until the gate-level netlist is ready. In practice, test circuitry is
closely integrated into the design and the design suffers when test is treated as an ad-hoc component or
inserted later in the gate-level netlist.
To address these issues and achieve a high level of test coverage and performance, the Hybrid TK/LBIST
flow enables you to insert DFT logic at the RTL level, before the gate-level netlist is ready. Capture
windows enable the flexibility to add test logic in the RTL and test accurately.

Solution
The solution is provided in two parts:

• Define capture windows (which clocks and how many pulses from each clock).

• Determine how many patterns to run per capture domain to achieve the targeted coverage.
Define Capture Windows
If the clocking structure is known and determined during the insertion of the IP, define capture windows
for this flow by following the examples under NCP Index Decoder in the Hybrid TK/LBIST Flow User's
Manual.
If the clocking structure is not yet defined or finalized, use the following procedure:

1. Create a gate-level netlist using quick synthesis.

2. Run ATPG with the following constraints:

a. Use the same setup and constraints used for LBIST.

b. Set the number of random patterns:

set_random_pattern integer

where the integer argument is the number of patterns that are planned for use in LBIST.

c. Run pattern simulation:

simulate_patterns –source random –store all

710 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
How to Design Capture Windows for Hybrid TK/LBIST

d. Report the test coverage per clock domain:

report_statistics –clock all

e. Report the generated patterns:

report_patterns

f. Design your capture windows using information from the ATPG run and the report_statistics
command.

• The ATPG run helps you identify the test clock domains in the design.

• The report_statistics command helps you identify the number of clock pulses per clock
domain

g. Determine how many patterns to run for each capture domain to achieve the targeted
coverage.
In the following example, the design has three clock domains, with possible interaction between CLK2
and CLK3. The highest faults per domain is at CLK2 at 78%, followed by CLK3 at 43%.

---------------------------------------------------------------
Clock Domain Summary % faults Test Coverage
(total) (total relevant)
--------------------------------------------------------------
CLK3_OCC 43.07% 99.13%
CLK2_OCC 78.80% 99.08%
CLK1_OCC 22.98% 98.17%
---------------------------------------------------------------

Patterns to Run per Capture Domain

For stuck-at-fault, try to use as many clock domains in the capture window as possible. This saves
test time. Complete the steps under Define Capture Windows in the preceding to select the number of
patterns per capture window.
In the following example, to achieve the best coverage with the lowest number of patterns, use a two-
cycle capture window for 20% of the patterns and use a single CLK2_OCC/CLK1_OCC pulse capture
window for 80% of the patterns.

pre-filtering
patt. # pattern # type cycles loads capture_clock_sequence
------- ------------- ---------------- ------ ----- ------------------
0 0 basic 1 1 [CLK1_OCC,*]
1 1 basic 1 1 [CLK2_OCC,*]
… … …
1 400 basic 1 1 [CLK2_OCC,*]

Tessent™ Shell User’s Manual 711

Tessent Examples and Solutions
How to Use Boundary Scan in a Wrapped Core
2 401 clock_sequential 2 1 [CLK2_OCC,*] [CLK3_OCC,*]
3 405 clock_sequential 2 1 [CLK2_OCC,*] [CLK3_OCC,*]
3 500 clock_sequential 2 1 [CLK2_OCC,*] [CLK3_OCC,*]
Note: [*] = "SHIFT_CLOCK", which is a pulse-in-capture clock.

How to Use Boundary Scan in a Wrapped Core

You must perform a specific procedure if a wrapped core has embedded pads that require boundary scan.
Care must be taken during the insertion of the boundary scan and during ATPG.

Problem
Pads embedded inside a wrapped core must be identified such that boundary scan cells can be added.
The resulting boundary scan cells must also be made visible to the tool in order for them to be included in
scan chains and to apply scan patterns.

Solution
The solutions are given for wrapped core and chip-level flows.
Wrapped Core Flow
The following figure shows the standard command flow for creating a wrapped core that includes
embedded boundary scan:

712 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
How to Use Boundary Scan in a Wrapped Core

Figure 185. Wrapped Core Boundary Scan Flow

If the core contains pads and boundary scan, you must include the following commands in the wrapped
core flow shown in Figure 185 on page 713:

• Insert memory BIST and embedded boundary scan using during the insert_mbist_ebscan step as
follows:

a. Specify DFT requirements to insert memory test and embedded boundary scan:

set_dft_specification_requirements -memory_test on \
-boundary_scan on

b. Insert embedded boundary scan cells and identify the pads:

Tessent™ Shell User’s Manual 713

Tessent Examples and Solutions
How to Use an Older Core TSDB With Newly-Inserted DFT Cores

set_boundary_scan_port_options \
-pad_io_ports [list taclk ta_cci0a ta_cci0b ta_cci1a ta_cci1b
ta_cci2a ta_cci2b ta_out0 ta_out1 ta_out2]

Note:
The order specified is the order in which the boundary scan cells are inserted.

• Specify not to add any dedicated wrapper cells on the embedded pad I/O during the insert_scan
step:

set_dedicated_wrapper_cell_options off \
-ports {ta_out0 ta_out1 ta_out2}

set_dedicated_wrapper_cell_options off \
-ports {ta_cci0a taclk ta_cci0b ta_cci1a ta_cci1b ta_cci2a
ta_cci2b}

• Preserve the boundary scan instances in the graybox during the ATPG_patterns (graybox
generation) step.

set preserve_bscan {}

set preserve_bscan \
[get_instances ‑hier *_tessent_bscan_logical_group_*]
analyze_graybox -preserve_instances $preserve_bscan
write_design -tsdb -graybox -verbose

Chip-Level Flow
For boundary scan at the chip-level, follow the standard chip-level flow by inserting boundary scan as
the first step in the flow. There are no specific additions for embedded boundary scan at this phase of the
flow. The boundary scan segments from the wrapped core are picked up automatically during chip-level
boundary scan insertion.

How to Use an Older Core TSDB With

Newly-Inserted DFT Cores
When you have existing cores with Tessent DFT inserted, you can use them with automation through the
Tessent Shell database (TSDB).

Prerequisites
• Legacy core TSDB file.

714 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
How to Use an Older Core TSDB With Newly-Inserted DFT Cores

Procedure
1. Open the TSDB of the legacy core:

open_tsdb <tsdb_directory>/legacy_core.tsdb

Tessent Shell provides automation through the TSDB directory and TCD files. From the TSDB, the
tool finds all available TCD files that apply to the design.

2. Load the current design:

read_design <core_name> ‑design_id <final_design_id>

3. Prepare your legacy cores by configuring them into the correct mode.

a. If scan insertion was performed using Tessent Scan, use the import_scan_mode command
during pattern generation to import the EDT and OCC settings.

b. If the scan insertion was not performed using Tessent Scan, but there are TCD files in the
TSDB, use the add_core_instances command to configure the EDT and OCC.

add_core_instances -module <module_name>

c. If scan insertion was not performed using Tessent Scan and there are no TCD files for OCC,
manually add clock information using the add_clocks command and define the clock definition
as a third-party OCC.

# For OCC clock definition

add_clocks <occ_output_mux/y_pin> -capture_only
# For procedure setup of OCC
set_test_setup_icall "<OCC_name.setup>"
# For OCC clock definition file
read_procfile <occ_control.proc>

4. Perform pattern generation with a regular ATPG session.

Results
You have successfully added legacy cores to newly-inserted cores using the TSDB.

Tessent™ Shell User’s Manual 715

Tessent Examples and Solutions
TAP Configuration

TAP Configuration
Tessent Shell typically relies on an IEEE 1149.1-based Test Access Port (TAP) as the primary access
mechanism to the DFT it inserts. When boundary scan is implemented, the Tessent TAP fully complies
with IEEE 1149.1 standard requirements, however many other possible configurations are possible.

Note:
For IEEE 1149.1-based TAP controllers using the optional TRST signal, TRST must be high
for functional mode and to force a synchronous reset with the TMS and TCK signals. Driving
TMS high for five TCK clock cycles forces the controller into the test/reset state. You can use the
PatternsSpecification/AdvancedOptions/ConstantPortSettings wrapper to force TRST high, as in
the following example:

PatternsSpecification(MyDesign,rtl,signoff) {
AdvancedOptions {
ConstantPortSettings {
TRST : 1 ;
}
}
}

This section provides a quick reference to the various TAP insertion styles that are supported, how to
specify them, and what to expect from such implementations.

Insert a Stand-Alone TAP in a Design

Insert a TAP With an IJTAG Host Scan Interface
Insert a Compliance Enable TAP With an IJTAG Interface
Insert a Daisy‑Chained TAP
Insert a Primary TAP
Insert a Secondary TAP
Connecting to a Third-Party TAP

Insert a Stand-Alone TAP in a Design

Insert a stand-alone TAP in a design. The TAP generated in this example can be further enhanced with
additional IR opcodes, IJTAG host scan interfaces, and decoded outputs to enable downstream logic,
such as another TAP.

Solution

1. Set the design level to "chip."

2. Use the following dofile example to insert the TAP:

716 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
Insert a Stand-Alone TAP in a Design

set DFT [create_dft_specification]

read_config_data -in $DFT -from_string {
IjtagNetwork {
HostScanInterface(ijtag) {
Interface {
tck : tck;
}
Tap(single) {
}
}
}
}
process_dft_specification

The generated TAP connects to the trst, tck, tms, tdi, and tdo pads that were present in the pre-DFT
design.

Discussion
If the TAP pins in the current design do not use the default names (trst, tck, tms, tdi, or tdo), then they can
be mapped using one of the following:

• The DftSpecification::IjtagNetwork::HostScanInterface::Interface wrapper.

• The following dofile command:

set_attribute_value portname -name function \

-value [trst | tck | tms | tdi | tdo]

The tool issues errors if the TAP pads are not yet present in the current design. If the design is
only temporary, you can specify the "set_design_level sub_block" command instead. Many TAP-
specific DRCs are not run in such a case and other side effects may result. You should read an
updated design that includes TAP pads as soon as possible.
The following is a schematic representation of this example:

Tessent™ Shell User’s Manual 717

Tessent Examples and Solutions
Insert a TAP With an IJTAG Host Scan Interface

Related Topics
Insert a TAP With an IJTAG Host Scan Interface

Insert a Compliance Enable TAP With an IJTAG Interface

Insert a Daisy‑Chained TAP

Insert a Primary TAP

Insert a Secondary TAP

Connecting to a Third-Party TAP

Insert a TAP With an IJTAG Host Scan Interface

Insert a TAP equipped with an IJTAG host scan interface. An IJTAG network can then be connected to the
TAP in a subsequent test insertion phase.

Solution

1. Set the design level to "chip."

2. Use the following dofile example to insert the TAP:

set DFT [create_dft_specification]

read_config_data -in $DFT -from_string {
IjtagNetwork {
HostScanInterface(ijtag) {
Interface {
tck : tck;
}
Tap(single) {
HostIjtag(1) {
}
}
}
}
}
process_dft_specification

Discussion
The host scan interface on the generated TAP can be used to control any type of IJTAG‑compliant
network.
The host scan interface provides a test_logic_reset output to reset downstream logic; it asserts the
host_<hostname>_to_sel output to 1 when accessing the client IJTAG network.
The capture_dr_en, shift_dr_en, and update_dr_en outputs are consumed by the client IJTAG network or
instruments after qualification with the host_<hostname>_to_sel port.
The following is a schematic representation of this example:

718 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
Insert a Compliance Enable TAP With an IJTAG Interface

Related Topics
Insert a Stand-Alone TAP in a Design

Insert a Compliance Enable TAP With an IJTAG

Interface
Insert a TAP in a design with compliance enable (CE) decoding logic. The CE decoding logic ensures that
the TAP can only be accessed if all of the specified values are present on the primary inputs. The same
scheme is also used when the TAP pins are shared with functional pins. The CE pins ensure that the TAP
is only activated during intended test modes and not accidentally, for example, while the functional pins
toggle during normal operation.

Solution

1. Set the design level to "chip."

2. Ensure that at least one primary input pad is set to 0 or 1 to enable the TAP logic.

3. Use the following dofile example to insert the TAP:

set DFT [ create_dft_specification \

-active_low_compliance_enables {tap_en0} \
-active_high_compliance_enables {tap_en1} ]
read_config_data -in $DFT/IjtagNetwork/HostScanInterface(tap) \
-from_string {
Tap(CE_decoded) {
HostIjtag(1) {
}
}
}
process_dft_specification

Discussion
Note how the CE pins are specified as options to the create_dft_specification command.

Tessent™ Shell User’s Manual 719

Tessent Examples and Solutions
Insert a Daisy‑Chained TAP

The CE decoding module relies on the CE pin values to select the active TDO and TDO_EN signals and
route both to the primary TDO output pad.
The same CE module also gates the TMS signal such that when the proper values are not present, the
TMS input on the TAP is kept to 0. This normally has the effect of "parking" the TAP in one of the stable
FSM states (refer to the IEEE 1149.1 FSM state diagram for details).

CAUTION:
Do not confuse the CE decoding module input port names with expected CE values! For instance,
in the preceding diagram the "ce0" input is actually sourced by the CE pin driven at 1; the "ce1"
input is connected to the CE pin driven at 0.

The general rule is that if n CE inputs are specified, the tool creates CE decoding logic with input ports
ranging from ce<n-1> down to ce0.
If internal CE nodes have to be used (that is, when the pre-DFT design already contains decoding
logic and hookup points to connect the new TAP to), declare those hierarchical nodes in a new
DftSpecification::IjtagNetwork::HostScanInterface::Interface wrapper. The Tap<name> wrapper then has
to be put within the very same interface wrapper.
The following is a schematic representation of this example:

Related Topics
Insert a Stand-Alone TAP in a Design

Insert a Daisy‑Chained TAP

This example inserts a second TAP in series with an existing one. The TRST, TCK, and TMS signals are
shared between both TAPs, which implies that the complete JTAG chain (for example, top-level TDI to
TDO) always shifts through both TAPs.

720 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
Insert a Daisy‑Chained TAP

Solution

CAUTION:
You should not daisy-chain TAP controllers for BoundaryScan. The result is not IEEE 1149.1
compliant, and as a result you cannot create BoundaryScan patterns for the design with Tessent
Shell. During BoundaryScan testing, the scan paths contain both TAP controllers. This works for
the instruction and the BoundaryScan registers, but the bypass and the device_id path are longer
than the mandated size.

1. Set the design level to "chip."

2. Use the following dofile example to insert the TAP:

set DFT [create_dft_specification]

read_config_data -in $DFT -from_string {
IjtagNetwork {
HostScanInterface(tap) {
Interface {
tck : tck;
daisy_chain_with_existing_client : on;
}
Tap(2) {
HostIjtag(2) {
}
}
}
}
}
process_dft_specification

Discussion
The first TAP in this example has a name that starts with "top_rtl_", while the second TAP begins with
"top_rtl1_". These names are used because this step is typically done as a subsequent insertion pass,
such that the current design already contains at least one valid TAP.
The following is a schematic representation of this example:

Tessent™ Shell User’s Manual 721

Tessent Examples and Solutions
Insert a Primary TAP

Related Topics
Insert a Stand-Alone TAP in a Design

Insert a Primary TAP

This example inserts a TAP into a design that does not contain one. The generated TAP is used as a
primary TAP. Primary TAPs provide outputs to enable or disable secondary TAPs, which are inserted in
subsequent insertion passes.

Solution

1. Set the design level to "chip."

2. In the IjtagNetwork::HostScanInterface::Tap wrapper, create one or several DataOut output ports

on the primary TAP. These enable a secondary TAP when the corresponding DataOut port is
asserted:

set DFT [create_dft_specification]

read_config_data -in $DFT -from_string {
IjtagNetwork {
HostScanInterface(tap) {
Interface {
tck : tck;
}
Tap(primary) {
HostIjtag(1) {
}
DataOutPorts {
count : 1;
}
}
}
}
}
process_dft_specification

Discussion
Except for the new user_ir_bits[0] output port created using the DataOutPorts wrapper, this TAP is
functionally identical to a stand-alone TAP with a host scan interface.
The added DataOutPort ports are TAP IR bits. If you need to create these bits as DR bits, insert a TDR on
the existing host scan interface using the following command:

create_dft_specification –existing_ijtag_host_scan_in hierarchical_pin

The following is a schematic representation of this example:

722 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
Insert a Secondary TAP

Related Topics
Insert a Stand-Alone TAP in a Design

Insert a Secondary TAP

Insert a Secondary TAP

This example generates a primary TAP, a 2-to-1 scan mux, and a secondary TAP. The primary TAP is
enabled by default.

Solution

1. Set the design level to "chip."

2. Use the following dofile example to insert the TAP:

set DFT [create_dft_specification]

read_config_data -in $DFT -from_string {
IjtagNetwork {
HostScanInterface(tap) {
Interface {
tck : tck;
}
Tap(primary) {
HostIjtag(0) {
}
DataOutPorts {
count : 1 ;
}

Tessent™ Shell User’s Manual 723

Tessent Examples and Solutions
Insert a Secondary TAP
}
ScanMux(1) {
select : Tap(primary)/DataOut(0) ;
Input(0) {
Tap(secondary) {
HostIjtag(1) {
}
}
}
}
}
}
}
process_dft_specification

Discussion
To trace through the secondary TAP implementations, begin with the TDO output and trace back toward
the primary TDI input.
The inserted ScanMux selects the TDI input by default and routes it to its own mux_out output.
The reset value of user_ir_bits[0] is 1. When this output transitions to 0, the secondary TAP is enabled
and the complete JTAG scan path goes through both TAPs.

Note:
When the primary TAP is used to host the BoundaryScan chain, it should be the only one
between TDI and TDO to ensure that the design is IEEE 1149.1 compliant.

The following is a schematic representation of this example:

724 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
Connecting to a Third-Party TAP

Related Topics
Insert a Stand-Alone TAP in a Design

Insert a Primary TAP

Connecting to a Third-Party TAP

Connecting an IJTAG network or instruments to a third-party TAP requires reading the Verilog module of
that TAP along with its ICL before setting the current design in Tessent Shell.

Tessent™ Shell User’s Manual 725

Tessent Examples and Solutions
How to Create a WSP Controller in Tessent Shell

Solution
When creating the DFT specification, specify the ‑existing_ijtag_host_scan_in port option and point to the
ScanInPort on the third-party TAP that receives the scanned-out data from the inserted IJTAG network or
instruments. The DFT specification is then created accordingly.

Related Topics
Insert a Stand-Alone TAP in a Design

How to Create a WSP Controller in Tessent

Shell
Create a fully compliant IEEE 1500 Wrapper Serial Port (WSP) using Tessent Shell.

Problem
Tessent Shell does not natively generate and insert WSP Controllers for the IEEE 1500 standard.
However, you can build one using Tessent Shell’s IJTAG features for the IEEE 1687 standard.

Solution
To create a WSP controller, use an empty Verilog module and an IJTAG network that you can specify
using DftSpecification wrappers for the Tessent Shell. Refer to the Discussion for details of the IEEE 1687
IJTAG network model of the IEEE 1500 WSP interface.

Note:
Refer to "IJTAG Network Insertion" in the Tessent IJTAG User’s Manual for more information
about the insertion flow and how to edit or modify a DftSpecification.

Create a Verilog Module

Begin the implementation by preparing a WSP interface module in Verilog. Use two buffers to provide
logic0 and logic1 constraints. These constraints create the default capture values that define the device
ID (dev_id).

module WSP ();

buf02 logic0 (.A(1'b0), .Y());
buf02 logic1 (.A(1'b1), .Y());
endmodule

Create an IJTAG Network Model

1. Create a DftSpecification using an IjtagNetwork wrapper.

DftSpecification(wsp, 1_ijtag) {
IjtagNetwork {
}
}

726 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
How to Create a WSP Controller in Tessent Shell

2. Create a DataInPort inside the DftSpecification/IjtagNetwork wrapper. Specify the port name as
"wir_select" to control the select input of a ScanMux Instruction Register (scanmux_ir).

DataInPorts {
port_naming : wir_select
}

3. Create a HostScanInterface wrapper with one ScanMux inside the DftSpecification/IjtagNetwork

wrapper. This is the ScanMux to select the Instruction Register. It is driven by DataIn(0), which
corresponds to the wir_select signal in the DataInPorts wrapper.

HostScanInterface(wsp) {
ScanMux(scanmux_ir) {
select : DataIn(0);
Input(1) {}
Input(0) {}
}
}

4. Create a TDR for the WSP Instruction Register (wsp_ir) that connects to Input(1) of the
scanmux_ir. The length of the TDR depends on the number of registers in the hierarchy. Use a
TDR length greater than or equal to the base 2 logarithm of the number of registers.

Figure 186. tdr_length ≥ log2(number of registers)

Tdr(wsp_ir) {
length : tdr_length;
DataInPorts {
connection(tdr_length-1) : logic0/Y;
...
connection(1) : logic1/Y;
connection(0) : logic0/Y;
}
DecodedSignal(level1_mux_select) {
decode_values : <tdr_length>'bXX...X1;
}
DecodedSignal(level2_mux_select) {
decode_values : <tdr_length>'bXX...1X;
}
DecodedSignal(level<tdr_length>_mux_select) {
decode_values : <tdr_length>'b1X...XX;
}
}

5. Create the remaining IJTAG network hierarchy under Input(0) of the scanmux_ir. The bypass
register must be accessible only through code consisting of zeros or ones. The logic constraints
specify the device ID (dev_id) default capture value.

Tessent™ Shell User’s Manual 727

Tessent Examples and Solutions
How to Create a WSP Controller in Tessent Shell

Tdr(dev_id) {
length : 32;
DataInPorts {
connection(31:18) : logic0/Y;
connection(17) : logic1/Y;
connection(16:2) : logic0/Y;
connection(2:0) : logic1/Y;
}
}

6. The following code is the complete DftSpecification that models the IEEE 1500 WSP.

DftSpecification(wsp,1_ijtag) {
IjtagNetwork {
DataInPorts {
port_naming : wir_select;
}
HostScanInterface(wsp) {
ScanMux (ir_dr) {
select : DataIn(0);
Input(1) {
Tdr(wsp_ir) {
length : <tdr_length>;
DataInPorts {
connection(tdr_length-1) : logic0/Y;
...
connection(1) : logic1/Y;
connection(0) : logic0/Y;
}
DecodedSignal(level1_mux_select) {
decode_values : <tdr_length>'bXX...X1;
}
DecodedSignal(level2_mux_select) {
decode_values : <tdr_length>'bXX...1X;
}
DecodedSignal(level<tdr_length>_mux_select) {
decode_values : <tdr_length>'b1X...XX;
}
}
}
Input(0) {
// part of the network connected to input 0 of the scanmux
...
}
}
}
}
}

728 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
How to Create a WSP Controller in Tessent Shell

Discussion
You can specify IJTAG networks in Tessent Shell using DftSpecification wrappers. The DftSpecification
interface can mimic an IEEE 1500 Wrapper Serial Port (WSP). The implementation is fully compliant with
the IEEE 1500 standard.
The WSP interface is almost the same as an IJTAG interface fully supported by Tessent Shell with only
one small modification required for the SelectWIR port. A primary input port must be created for the
SelectWIR. The ijtag_sel port is not connected in the model for the WSP. Table 32 summarizes the
signals.

Table 32. Comparison of IEEE 1687 and IEEE 1500 Ports

Function IEEE 1687 IJTAG IEEE 1500 WSP

Scan Input ijtag_si WSI

Capture Enable ijtag_ce CaptureWR

Shift Enable ijtag_se ShiftWR

Update Enable ijtag_ue UpdateWR

Test Clock ijtag_tck WRCK

Reset ijtag_reset WRSTN

Scan Output ijtag_so WSO

Select ijtag_sel -

Select Instruction Register - SelectWIR

If the WSP module is not hosted by IJTAG, you must assert the ijtag_sel port to logic 1.
IJTAG does not have the SelectWIR port. Therefore, the primary input port created with the DataInPort
wrapper has no relation to the ToIRSelectPort of the TAP.
The DataIn port is used to control the ScanMux Instruction Register (scanmux_ir). The WSP Instruction
Register (wsp_ir) operates as a normal DataRegister in the IJTAG model.
Figure 186 shows an IJTAG network model of the IEEE 1500 WSP interface. It consists of a bypass
register, a dev_id register, and five other registers.

Tessent™ Shell User’s Manual 729

Tessent Examples and Solutions
How to Create a WSP Controller in Tessent Shell

Figure 186. IEEE 1687 IJTAG Network Model of the IEEE 1500 WSP Interface

The following method is recommended to create a DftSpecification for the IJTAG network model of Figure
186.
Connect the scanmux_ir to the scan output port. Use wir_select primary input signal to drive the
scanmux_ir select signal to model the IEEE 1500 functionality.
Sort the scan muxes by hierarchy level. The yellow level1_mux is the first level in the mux hierarchy. The
green level2_mux0 and level2_mux1 are the second level in the mux hierarchy. The blue level3_mux00,
level3_mux01, and level3_mux10 are the third level in the mux hierarchy.
The wsp_ir generates signals to control the active scan path. Each bit of the wsp_ir controls one level
of mux hierarchy. Bit 0, the yellow bit, drives the select signal of the level1_mux. Bit 1, the green bit,
drives both select signals of the two level2_muxes. Bit 2, the blue bit, drives all three select signals of the
level3_muxes.
Table 33 lists the wsp_ir bit values that drive each select signal in the mux hierarchy. A logic 0 value
selects the input labeled 0 of the mux. A logic 1 value selects the input labeled 1 of the mux.

Table 33. Mux Select Signals and wsp_ir Value to Select Input 1

Signal Name wsp_ir Value

level3_mux_select 1XX

level2_mux_select X1X

level1_mux_select XX1

You can create the DftSpecification after understanding the model structure and the signal values driving
the select signals of the muxes. Recreate the structure of this IJTAG network in the DftSpecification. The
additional wir_select signal drives the select signal of the final scanmux_ir.

730 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
How to Create a WSP Controller in Tessent Shell

DftSpecification(test,rtl) {
IjtagNetwork {
DataInPorts {
port_naming : wir_select;
}
HostScanInterface(wsp) {
ScanMux (ir_dr) {
select : DataIn(0);
Input(1) {
Tdr(wsp_ir) {
length : 3;
DataInPorts {
connection(1) : logic0/Y;
connection(0) : logic1/Y;
}
DecodedSignal(level1_mux_select) {
decode_values : 3'bXX1;
}
DecodedSignal(level2_mux_select) {
decode_values : 3'bX1X;
}
DecodedSignal(level3_mux_select) {
decode_values : 3'b1XX;
}
}
}

Input(0) {
ScanMux (level1_mux) {
select : Tdr(wsp_ir)/DecodedSignal(level1_mux_select);
Input(1) {
ScanMux (level2_mux1) {
select : Tdr(wsp_ir)/DecodedSignal(level2_mux_select);
Input(1) {
Tdr(tdr4) {
length : 10;
}
}
Input(0) {
ScanMux (level3_mux10) {
select : Tdr(wsp_ir)/DecodedSignal(level3_mux_select);
Input(1) {
Tdr(tdr3) {
length : 8;
}
}
Input(0) {
Tdr(tdr2) {
length : 6;
}
}
}

Tessent™ Shell User’s Manual 731

Tessent Examples and Solutions
How to Create a WSP Controller in Tessent Shell
}
}
}

Input(0) {
ScanMux (level2_mux0) {
select : Tdr(wsp_ir)/DecodedSignal(level2_mux_select);
Input(1) {
ScanMux (level3_mux01) {
select : Tdr(wsp_ir)/DecodedSignal(level3_mux_select);
Input(1) {
Tdr(tdr1) {
length : 4;
}
}
Input(0) {
Tdr(tdr0) {
length : 2;
}
}
}
}

Input(0) {
ScanMux (level3_mux00) {
select : Tdr(wsp_ir)/DecodedSignal(level3_mux_select);
Input(1) {
Tdr(dev_id) {
length : 32;
}
}
Input(0) {
Tdr(bypass) {
}
}
}
}
}
}
}
}
}
}
}
}
}

In summary, an IJTAG network can model an IEEE 1500 WSP interface and be fully compliant with the
IEEE 1500 standard. The DftSpecification/IjtagNetwork wrappers can describe the model for Tessent
Shell to generate and insert it into your design.

732 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
How to Set Up Third-Party Synthesis

How to Set Up Third-Party Synthesis

You must synthesize DFT logic generated in the Tessent Shell flow in order to perform scan insertion, test
pattern generation, and other processes.

Solution
You must define constraints in synthesis tools to enable accurate gate level representations of the RTL.
These constraints are primarily made up of clock definitions and timing constraints. Use the following
procedures to set up constraints for Synopsys and Cadence synthesis tools within the Tessent Shell flow.
Synopsys
The following procedure provides a high-level overview of the synthesis flow for Synopsys. For more
information, refer to “Example Scripts Using Tessent Tool-Generated SDC” on page 979 for an example.

1. Source the SDC file generated by the tool.

The generated SDC file is located in the TSDB of the current design under the design ID to which
the DFT was inserted and the ICL was extracted.

2. Set and redefine the Tessent Tcl variables.

The SDC file includes variables that need to be set in order for the script to operate correctly. For
example, the period of the TCK clock needs to be set. Depending on your DFT flow, you may
need to define additional variables. The variables that you must set are identified in the SDC
script file.

3. Verify the declaration of the functional clocks.

You must define all functional clocks. The tool automatically generates clock definitions based on
the information from your DFT insertion script. You must review these definitions for accuracy.

4. Redefine other Tessent Tcl variables.

You must review and customize any additional variables. For example, a variable must be set that
defines the input delay for the primary pins. This setting is based on the pre-defined TCK period
and a custom multiplier value. The following is an example:

set tessent_input_delay [expr 0.3 * $tessent_tck_period]

Note:
The value of tessent_tck_period might depend on the maximum tck clock frequency that
can be applied to the circuit. Refer to "IJTAG Network Performance Optimization" in the
Tessent IJTAG User’s Manual showing how to maximize the frequency of the IJTAG
network test clock.

5. Load the design into your synthesis tool.

The Tessent Shell tool automatically creates a script to import your design. The tool then sources
the generated script to elaborate the design.

Tessent™ Shell User’s Manual 733

Tessent Examples and Solutions
How to Set Up Third-Party Synthesis

6. Apply the SDC constraints.

At this stage of the flow, the SDC constraints for the DFT logic are applied by sourcing the
appropriate procedure. The procedures are described under the extract_sdc command of the
Tessent Shell Reference Manual.

7. Prepare the DFT logic for synthesis.

You must set up the DFT logic by configuring synthesis tool settings to ensure proper synthesis.
For example, some instances need to be preserved during synthesis to ensure that the gate-level
analysis functions correctly. The following statements are examples of configuration settings:

set_app_var compile_enable_constant_propagation_with_no_boundary_opt
false
set preserve_instances [tessent_get_preserve_instances icl_extract]
set_boundary_optimization $preserve_instances false
set_ungroup $preserve_instances false
set_app_var compile_seqmap_propagate_high_effort false
set_app_var compile_delete_unloaded_sequential_cells false
set_boundary_optimization [tessent_get_optimize_instances] true
set_size_only -all_instances [tessent_get_size_only_instances]

8. Synthesize your design.

The synthesis script compiles the design to create a gate‑level representation of the RTL.

9. Write out the SDC and the final gate-level netlist.

The final SDC is a combination of the functional and the DFT constraints.
Genus
For synthesis with the Genus tool, follow the procedure for the Synopsys tool, but ensure that you adjust
steps 3 through 9 to match the example script. For more information, refer to “Example Scripts Using
Tessent Tool-Generated SDC” on page 979. These steps are different because the tools use different
commands to run synthesis. Otherwise, the flow and results are the same.

Tip
Refer to “Solutions for Genus Synthesis Issues” on page 1005 if you experience issues
synthesizing mixed Verilog/VHDL designs.

734 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
How to Set Up Support for Third-Party OCCs

How to Set Up Support for Third-Party OCCs

Tessent tools provide automation that enables you to insert Tessent OCCs as well as define and configure
them for ATPG. If the design contains third-party OCCs, Tessent tools can set up and operate the OCC
throughout the flow by reading and processing files that describe the operation of the OCC.

How to Configure Files for Third-Party OCCs

Test Logic Insertion
Configuration for Scan Insertion
Pattern Generation and Simulation

How to Configure Files for Third-Party OCCs

In order to automate the flow as much as possible, the following files set up and control how the tool
interacts with the OCC.

Solution
You must place the ICL and PDL files in the same directory as the Verilog of the OCC using the same file
base name. For this example, the OCC Verilog module is in a file named third_party_occ.v.
Moving the ICL and PDL files into the same directory as the Verilog enables the tool to automatically load
them and carry the information throughout the flow.
You must prepare the following files and definitions as described:

• ICL — Provide an ICL file based on the IEEE 1687 IJTAG standard to describe the ports on the
OCC that need to be controlled by IJTAG during test. Name the file third_party_occ.icl and place
it in the same directory as the Verilog file.

• PDL — Provide a PDL file based on the IEEE 1687 IJTAG standard to describe the procedures
that configure the third-party OCC. Name the file third_party_occ.pdl and place it in the same
directory as the Verilog file.

• TCD Scan — Provide a TCD Scan file based on the Tessent Core description language to
describe the OCC’s programming shift register (chain segment) that needs to be connected to the
design’s scan chains during scan insertion.
The following is an example TCD Scan file for a third-party OCC. The sub-chain port information
must be included in the ScanChain wrapper and in the Clock and ScanEn wrappers to define the
polarity of each port.

Core(third_party_occ) {
Scan {
module_type : occ;
allow_scan_out_retiming : 0;
is_hard_module : 1;
traceable : 0;
pre_scan_drc_on_boundary_only : 1;
Clock(slow_clock) {
off_state : 1'b0;

Tessent™ Shell User’s Manual 735

Tessent Examples and Solutions
Test Logic Insertion
}
ClockOut(clock_out_mux/y) {
slow_clock_input : slow_clock;
fast_clock_input : fast_clock;
}
ScanEn(scan_en) {
active_polarity : 1'b1;
}
ScanChain {
length : 4;
scan_in_port : scan_in;
scan_out_port : scan_out;
scan_in_clock : slow_clock;
scan_out_clock : ~slow_clock;
}
}
}

• Clock Control Definitions — Provide a test procedure file that contains Clock Control Definitions
(CCDs) for the OCC instances in the design. For details on the format of CCDs, refer to
“Clock_Control (Optional)” on page 791.

Test Logic Insertion

During test logic insertion (for example, EDT), the tool reads and processes the ICL and PDL files and
includes this information in design files stored in the TSDB. Additionally, any OCC ports described in the
ICL file that need to be controlled by IJTAG are connected to the generated IJTAG network such that the
OCCs can be easily configured in subsequent steps.
Refer to “How to Configure Files for Third-Party OCCs” on page 735 for instructions on setting up the
ICL and PDL files.

Solution
EDT Example
The following EDT example uses a post-insertion procedure to connect the slow_clock port of the OCC
to the newly-generated shift_capture_clock DFT signal. This enables the OCC and EDT logic to use the
same clock source. The post-insertion script is run after the process_dft_specification command creates
all other logic defined in the DftSpecification. For detailed information on how to create and use a post-
insertion procedure, refer to process_dft_specification.post_insertion in the Tessent Shell Reference
Manual.

set_context dft -rtl

set_tsdb_output_directory ../tsdb_outdir

# Read the design and OCC module. The ICL and PDL files with the
# same base name are automatically read from the same directory
read_verilog ../rtl/RDS_process_with_occ.v
read_verilog ../rtl/third_party_occ.v

set_current_design RDS_process
set_design_level physical_block
# Define DFT Signals for EDT and scan test.

736 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
Configuration for Scan Insertion
add_dft_signals scan_en edt_update test_clock -source_node \
{scan_en_r edt_update test_clock_r}
add_dft_signals edt_clock shift_capture_clock -create_from_other_signals
set_dft_specification_requirements -logic_test on
add_clocks clock1 -period 3ns
add_clocks clock2 -period 4ns

check_design_rules

# Create the DFT Spec for adding EDT

set spec [create_dft_specification -sri_sib_list {edt} ]
read_config_data -in $spec -from_string {
EDT {
ijtag_host_interface : Sib(edt);
Controller (c1) {
longest_chain_range : 50, 65;
scan_chain_count : 60;
input_channel_count : 2;
output_channel_count : 2;
}
}
}
# Post-insertion procedure to change the existing connection to
# third-party OCC's slow_clock port and connect to the shift_capture_clock
# DFT Signal
proc process_dft_specification.post_insertion {RDS_process args} {
set occ_insts [get_instances -of_module third_party_occ -silent]
if {[sizeof_collection $occ_insts] > 0} {
set slow_clock_pins [get_pins slow_clock -of_instances $occ_insts]
foreach_in_collection occ_pin $slow_clock_pins {
delete_connection $occ_pin
create_connection [get_dft_signal shift_capture_clock] $occ_pin
}
}
}
process_dft_specification
extract_icl

# Create a synthesis script of all RTL (original and newly created)

write_design_import_script use_in_synthesis.tcl -use_relative_path_to . \
-replace
exit

Configuration for Scan Insertion

You must configure the tool to read the OCC files before running scan insertion. The Tessent OCC
provides independent control of each clock domain in your design in the context of DFT.
Refer to “How to Configure Files for Third-Party OCCs” on page 735 for instructions on setting up the
OCC files.

Tessent™ Shell User’s Manual 737

Tessent Examples and Solutions
Pattern Generation and Simulation

Solution
When inserting scan into the post-synthesis netlist, you must specify the location of the TCD Scan file
using the set_design_sources command. The tool uses the description of the OCCs’ scan segment to
stitch them into the design’s scan chains.
The following is an example:

set_context dft –scan

set_tsdb_output_directory ../tsdb_outdir

# Specify the location of the TCD Scan file that describes the OCC's scan
# segment
set_design_sources -format tcd_scan -Y ../rtl -extension tcd_scan

# Read the cell library and synthesized netlist from DC Shell

read_cell_library ../library/tessent/adk.tcelllib
read_verilog ../2.synthesis/RDS_process_synthesized.vg

# Use read_design to read in information (DFT signals, etc.) performed in

# previous pass
read_design RDS_process -design_identifier rtl -no_hdl
set_current_design RDS_process
set_system_mode analysis

# Add a scan mode and specify EDT instances to which scan chains should be
# connected
set edt_instance [get_instances -of_icl_instances [get_icl_instances \
-filter tessent_instrument_type==mentor::edt]]
add_scan_mode edt -edt_instance $edt_instance
analyze_scan_chains
insert_test_logic
exit

Pattern Generation and Simulation

You must configure the tool to read the OCC files before generating patterns. The Tessent OCC provides
independent control of each clock domain in your design in the context of DFT.
Refer to “How to Configure Files for Third-Party OCCs” on page 735 for instructions on setting up the
OCC files.

Solution
Pattern Configuration
For stuck-at ATPG, much of the setup is automatically imported using the import_scan_mode command.
You should provide additional clock definitions and settings for the OCC for the OCC’s asynchronous
source clocks and the clocks on the output of the OCC instances.

set_context patterns -scan

set_tsdb_output_directory ../tsdb_outdir

738 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
Pattern Generation and Simulation
# Read the cell library and design
read_cell_library ../library/tessent/adk.tcelllib
read_design RDS_process -design_id gate
set_current_design RDS_process

# Specify a test mode for stuck-at ATPG

set_current_mode edt_stuck

# Import scan, EDT, and clock configuration for ATPG

import_scan_mode edt
# Define external and OCC clocks
set_clock_options test_clock_r -pulse_in_capture on
set occ_insts [get_instances -of_module third_party_occ* -silent]
if {[sizeof_collection $occ_insts] > 0} {
foreach_in_collection occ_inst $occ_insts {
set inst_name [get_single_name $occ_inst]
add_clocks [get_pins ${inst_name}/clock_out_mux/y] -capture_only
# Run iProc for third_party OCC to set default values (test_mode = 1)
set_test_setup_icall "${inst_name}.setup" -append
}
}
set_system_mode analysis
# Specify a procedure file containing clock control definition for the OCC
# instances
read_procfile third_party_occ_clock_controls.proc
create_patterns
write_tsdb_data -replace
write_patterns patterns/RDS_process_stuck_parallel.v -verilog -parallel \
-replace
set_pattern_filtering -sample_per_type 2
write_patterns patterns/RDS_process_stuck_serial.v -verilog -serial \
–replace

In analysis mode, specify a procedure file that contains the clock control definitions for the OCC
instances.
For transition fault ATPG, a number of changes to the dofile are highlighted in the following example.
Define any additional internal clocks that are needed for the third-party OCC, similar to those defined in
the example (for example, if the OCC internally gates the fast clock during transition test).
Additionally, specify any parameters to the OCC’s iCalls that must be set to configure the OCC for
transition/fast-capture test.
You must constrain the design’s I/Os that are not used for transition test.

set_context patterns -scan

set_tsdb_output_directory ../tsdb_outdir

# Read the cell library and design

read_cell_library ../library/tessent/adk.tcelllib
read_design RDS_process -design_id gate
set_current_design RDS_process

# Specify a test mode for transition ATPG

set_current_mode edt_transition

Tessent™ Shell User’s Manual 739

Tessent Examples and Solutions
Pattern Generation and Simulation

# Import scan, EDT, and clock configuration for ATPG

import_scan_mode edt
import_clocks
# Define external and OCC clocks
set_clock_options test_clock_r -pulse_in_capture on
set occ_insts [get_instances -of_module third_party_occ* -silent]
if {[sizeof_collection $occ_insts] > 0} {
foreach_in_collection occ_inst $occ_insts {
set inst_name [get_single_name $occ_inst]
add_clocks [get_pins ${inst_name}/clock_out_mux/y] -capture_only
add_clocks \
[get_pins ${inst_name}/occ_control/cgc_SHIFT_REG_CLK/clkg] \
-pulse_in_capture
# Execute iProc for third_party OCC and enable fast capture mode for OCCs
set_test_setup_icall "${inst_name}.setup fast_capture_mode 1" \
-append
}
}
add_input_constraints -hold
add_output_masks -all

set_system_mode analysis
# Specify a procedure file containing clock control definition for the OCC
# instances
read_procfile third_party_occ_clock_controls.proc

set_fault_type transition
set_external_capture_options -pll_cycles 5 [lindex [get_timeplate_list] 0]

create_patterns
write_tsdb_data -replace
write_patterns patterns/RDS_process_transition_parallel.v -verilog \
-parallel -replace
set_pattern_filtering -sample_per_type 2
write_patterns patterns/RDS_process_transition_serial.v -verilog \
-serial –replace

Pattern Simulation
You must run a Verilog simulation of the generated patterns to ensure no mismatches are reported and
the patterns function as expected during the tester application.
For parallel load patterns specified by the "write_patterns ‑parallel" command, you simulate all the
patterns.
For serial load patterns, a handful of patterns are sufficient because the run time for simulating serial load
patterns can be significant.

740 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
Post-Synthesis Update

Post-Synthesis Update
Mapping complex ports during synthesis may cause name and footprint changes in the design.
After logic synthesis with Design Compiler, Genus, or Oasys, ports may be flattened or bit-blasted,
causing design footprint changes. Post-synthesis names differ from those in the initial RTL. Refer to “ICL
and TCD Post-Synthesis Update” on page 118 for more information.
The update_icl_attributes_from_design command updates ICL port, instance, and module attributes for
the gate views of a design. Refer to “Updating ICL Attributes From the Design” on page 119 for more
information.

Limitations Related to SystemVerilog Interface Arrays

Matching Requirements for Port Names in Post-Synthesis Update
Design Name Mapping Commands

Limitations Related to SystemVerilog Interface

Arrays
Designs using SystemVerilog interface arrays synthesized with Design Compiler require special handling.
If your design contains ports declared using SystemVerilog interface arrays, and your netlist is created
with Synopsys Design Compiler, the syntax for these declarations should be restricted as follows:
Use the following syntax to declare the SystemVerilog interface ports array when creating your RTL
design. The packed range must be from 0 to a positive right index. Without this syntax, Tessent Shell
cannot match and automatically update ICL objects and TCD models post-synthesis with Design
Compiler.

<SV interface type> <port name> [0:<positive right index>]

For example, if your design has an interface type named intf1 and a port named p1, the port declaration in
the design file should be written so that the range is restricted:

intf1 p1 [0:<positive_index>];

The left index must be 0 and the right index must be positive. If you do not follow this convention, the tool
reports a warning similar to the following:

// Warning: SystemVerilog Interface Array: 'p1' is defined with

// a descending range, and will cause Tessent Shell errors
// post-synthesis(Design Compiler only).

Matching Requirements for Port Names in

Post-Synthesis Update
The following matching rules are supported when looking up a port name in a netlist:

Tessent™ Shell User’s Manual 741

Tessent Examples and Solutions
Matching Requirements for Port Names in Post-Synthesis Update

®
1. Support the transformation performed by the Synopsys Design Compiler tool (dc_shell) with
"change_names ‑rules verilog" to remove the escaping and replace special characters with
underscores ("_"). A single underscore matches multiple underscores.

2. Support the transformation performed by Genus to get the gate name from the RTL name. All
strings and numerical indices in the RTL name are preserved. Only the delimiters are changed.

3. Support the Genus transformation described in rule #2 but with escaping removed and special
characters replaced with an underscore ("_") as in rule #1.

4. Support bit-blasted escaped names generated by a layout tool. The bit select is incorporated into
the escaped name.

5. Support user-specified matching rules.

742 Tessent™ Shell User’s Manual

 Tessent Examples and Solutions
Design Name Mapping Commands

Design Name Mapping Commands

The add_rtl_to_gates_mapping, report_rtl_to_gates_mapping, and delete_rtl_to_gates_mapping
commands have several features to help you control design name mapping.

Design Name Mapping

Default Matching Rules for the get_pins, get_ports, and get_instances -match_rtl_reg Commands

Design Name Mapping

Use the add_rtl_to_gates_mapping, report_rtl_to_gates_mapping, and delete_rtl_to_gates_mapping
commands to control design name mapping.
You define custom name mapping rules for RTL to post-synthesis or post-layout name mapping with the
add_rtl_to_gates_mapping command. You can specify substrings, prefixes, and suffixes in addition to
basic mapping rules. Use this command if the matching rules described in “Default Matching Rules for the
get_pins, get_ports, and get_instances -match_rtl_reg Commands” on page 743 are not sufficient for
your application.

Related Topics
report_rtl_to_gates_mapping

delete_rtl_to_gates_mapping

Default Matching Rules for the get_pins, get_ports, and

get_instances -match_rtl_reg Commands
The tool provides several default rules.

• Component Names — All strings between non-escaped delimiters (component names) in the
name to be looked up (lookup name) must match the corresponding strings in a netlist name
unless they contain special characters. The recognized delimiters are periods ("."), forward
slashes ("/"), brackets ("[]"), and underscores ("_").
There are two types of component names: subnames and indices. Any of the preceding
characters can delimit subnames. Indices can be delimited only by brackets or underscores. A
right bracket must follow a component name that is preceded by a left bracket.

Note:
Negative indices are not supported.

An example lookup name:

abc.def

The "abc" string in the name to be looked up must exactly match the string before the first
delimiter in a netlist name. The "def" string in the name to be looked up must exactly match the
string after the last delimiter in the same netlist name.

Tessent™ Shell User’s Manual 743

Tessent Examples and Solutions
Default Matching Rules for the get_pins, get_ports, and get_instances -match_rtl_reg Commands

• Escaping — Escape characters are not matched. They are only used to direct the matching
procedure.

• Delimiters — Delimiters in the lookup name are used only to extract the component names.
All component names after the first are assumed to have a leading delimiter and optionally a
trailing delimiter in a netlist name. There are two cases to consider when matching the delimiters
for a component name in the netlist:

◦ The port name in the netlist is escaped.

Possible matches for component name delimiters are as follows:

• Leading and trailing delimiters of brackets ("[]").

• Leading delimiter of underscore ("_") and trailing delimiter of underscore or null.

• Leading delimiter of period (".") or slash ("/") and trailing delimiter of null.

◦ The port name in the netlist is not escaped.

Possible matches for component name delimiters are as follows:

• Leading delimiter of underscore and trailing delimiter of underscore or null.

• Special Characters in the Lookup Name — When matching to a non-escaped name in the
netlist, any characters not allowed by the language without escaping in the lookup name are
replaced with the underscore character ("_"). Matching allows truncation in the netlist name to two
trailing underscores.

Note:
This truncation rule applies only to underscore characters derived from special characters,
not delimiters.

• Bit Select Lookup Name — A bit select lookup name (last component name is an index) can
match a one-dimensional vector with the final bit select applied to the match or match directly to a
bit select.

744 Tessent™ Shell User’s Manual

 Chapter 11
Test Procedure File
Test procedure files specify how the scan circuitry within a design operates. Previously-defined scan
clocks and other control signals specify the scan circuitry operation. To operate the scan circuitry in your
design, the tool must have a specification of the scan circuitry and a test procedure file to describe its
operation. If you used Tessent Shell to insert the test logic or used the TCD IP mapping flow, the tool
automatically creates the test procedure files for most standard configurations. You can also create and
modify test procedure files manually. The design rule checking (DRC) process, which occurs when you
switch from setup to analysis mode, performs extensive checking to ensure the scan circuitry operates
correctly.

Test Procedure File Creation

Test Procedure File Syntax
Test Procedure File Structure
Test Procedures
Additional Support for Test Procedure Files
Creating Test Procedure Files for End Measure Mode
Serial Register Load and Unload for LogicBIST and ATPG
Notes About Using the stil2tessent Tool
Test Procedure File Commands and Output Formats

Test Procedure File Creation

You insert scan circuitry and create test procedure files for ATPG operations using the "patterns -scan"
context of Tessent Shell. If your design already contains scan circuitry, you need to create a test
procedure file to describe its operation either by hand or with Tessent Shell.
You can specify a test procedure file in setup mode using the add_scan_groups command. The tools
can also read in procedure files by using the read_procfile command or the write_patterns command
when not in setup mode. When you load more than one test procedure file, the tool merges the timing and
procedure data.
You can also translate a STIL Procedure File (SPF) into a dofile and test procedure file using the
stil2tessent tool. This tool produces a dofile that defines clocks, scan chains, scan groups, and pin
constraints. This tool also creates test procedure files with a timeplate and the following standard scan
procedures: test_setup, load_unload, and shift. For more information about stil2tessent, refer to “Notes
About Using the stil2tessent Tool” on page 827.
You can run the report_procedures command to list the procedures you created and the procedures the
tool created automatically.
The following subsections describe the syntax and rules of test procedure files, give examples for the
various types of scan architectures, and outline the checking that determines whether the circuitry is
operating correctly.

Test Procedure File Syntax

The test procedure file uses common syntactical conventions such as bold and italic fonts, and reserved
characters. The file supports Tcl conditional statements.

Tessent™ Shell User’s Manual 745

Test Procedure File
Test Procedure File Syntax

Syntax Conventions
The following syntax conventions are used in this chapter:

• Bold — Indicates a keyword. Enter the keyword exactly as shown.

• Italic — Indicates lexical elements such as identifiers, strings, or numbers. Replace the italicized
word with the appropriate name or integer.

• | — A vertical bar or pipe character indicates a logical "OR" as in "select ham OR ham_not".

• [ ] — Square brackets indicate optional elements. Do not include the brackets.

• … — An ellipsis indicates a repeatable item or set.

Reserved Characters
If you have a pin or pathname that uses a reserved punctuation character, you must enclose that name in
quotation marks (""). Refer to Table 34 for a list of reserved punctuation characters.
For example, the following statement is illegal because it uses the exclamation point outside of quotation
marks.

force /inst_my_adder_1/xclk_header!x1!x1/op1[9] 1

The signal name contains a reserved punctuation character, the exclamation point (!), so it must be
enclosed inside quotation marks. The correct syntax would be:

force "/inst_my_adder_1/xclk_header!x1!x1/op1[9]" 1

Table 34. Reserved Punctuation Characters

Name Character

Ampersand/AND &

Caret/Circumflex/XOR ^

Comma ,

Equals =

Exclamation mark !

Left/Opening brace {

Left/Opening parenthesis (

Right/Closing brace }

Right/Closing parenthesis )

746 Tessent™ Shell User’s Manual

 Test Procedure File
Test Procedure File Syntax

Table 34. Reserved Punctuation Characters (continued)

Name Character

Semicolon ;

Vertical bar/OR |

Throughout this chapter, value = 0, 1, X, or Z.

Using Tcl in the Test Procedure File

Procedure files support the Tcl conditional statements "if", "else", and "elseif" using the following syntax:

if { tcl_expr } {
procedure file statements
}
elseif { tcl_expr } {
procedure file statements
}
else {
procedure file statements
}

Where a "tcl_expr" is any Boolean Tcl expression that uses Tcl variables, dofile variables, or environment
variables. Just as when doing variable substitution in the procedure file, other Tcl statements and
defining Tcl variables are not supported. All variables must be defined in the dofile or from the shell as
environment variables.
The body of these Tcl conditional statements should contain only legal procedure file syntax, not any
other Tcl statements. The Tcl conditional statements are treated as preprocessor statements in the
procedure file parser. They are not preserved in the tool after parsing is finished; only the procedure file
code selected by the evaluation of the Tcl "if" expression is stored in the tool. Therefore, when using
write_procfile to write out the procedure file, none of the Tcl conditional statements are present, and the
procedure file code not used is also not present. For more information, refer to “The Tessent Tcl Interface”
on page 981.

Introductory Test Procedure File Example

The following is an example of a test procedure file.

// Comments use "//" characters

//
// Set the base time increment for use in all timeplates
set time scale 1.0 ns;

// Define the strobe time for the measure statements

set strobe_window time 1;

// This design uses a single timeplate, named "tp1", for all

// vectors.

timeplate tp1 =
force_pi 0;
measure_po 1;

Tessent™ Shell User’s Manual 747

Test Procedure File
Test Procedure File Syntax
pulse CLK0_7 2 1;
pulse CLK8_15 2 1;
period 4;
end;

// The shift and load_unload procedures define how the design

// must be configured to allow shifting data through the scan
// chains. The procedures define the timeplate to use
// and the scan group that it references.

procedure shift =
scan_group grp1;
timeplate tp1;
cycle =
force_sci;
measure_sco;
pulse CLK8_15;
pulse CLK0_7;
end;
end;

procedure load_unload =
scan_group grp1;
timeplate tp1;
cycle=
force CLEAR 0;
force CLK0_7 0;
force CLK8_15 0;
force scen1 1;
end;
apply shift 8;
end;

// The capture procedure is a "non-scan" procedure. This

// procedure describes the timeplate to use for the
// capture cycle. It also defines the number of cycles
// to use in the capture cycle. In this example there is
// just one cycle.

procedure capture =
timeplate tp1;
cycle =
force_pi;
measure_po;
pulse_capture_clock;
end;
end;

748 Tessent™ Shell User’s Manual

 Test Procedure File
Test Procedure File Structure

Test Procedure File Structure

The test procedure file consists of many structural elements that display in a specific order, starting with
#include statements. Some of these elements are required and others are optional.

#include "<file_name>";
[set_statement ...]
[alias_definition ...]
[timing_variables ...]
timeplate_definition // includes pulse clock statements
always_block
procedure_definition
clock control definition

#include Statement
Set Statement
Alias Definition
Timing Variables
Timeplate Definition
Multiple-Pulse Clocks
Always Block
Procedure Definition

#include Statement
The "#include" statement specifies that the tool read test procedure data from a specified file.
The following rules apply to #include statements and files:

• The "#include" statement can occur anywhere in the file, and multiple "#include" statements can
occur in one file. For example:

#include "ham.proc";

• The filename to be included must be enclosed in quotation marks (""), and the statement must be
followed by a semicolon.

• All timeplates and procedure rules apply to the statements placed in #include files.

• Included files can use the #include statement to include other files, up to a maximum include
depth of 512. If you later use the write_procfile command to write out procedure data, the
#include statements are not preserved, and the tool writes all procedure data to a single file.

Set Statement
The Set statements define specific parameters used throughout the test procedure file.

Tessent™ Shell User’s Manual 749

Test Procedure File
Set Statement

The following statements are available:

set time scale tscale;

set strobe_window time window_width;
set default_timeplate timeplate_name;
set autoforce off;

set time scale Statement

Defines the time scale and unit. The "set time scale" statement must be at the beginning of the procedure
file, before any timeplate or procedure definition. If you do not specify the time scale, the default value is 1
ns.
The tool applies the time scale and unit to the test procedure file and timeplates. The tscale you specify
can be any real number. Time values in the timeplate, however, must be integers, representing whole time
scale units. If you find you are specifying fractional times in the timeplate, you must reduce the time scale
unit so you can specify integer time values in the timeplate. For example, the following would result in a
syntax error:

set time scale 1 ns ;

set strobe_window time 1 ;

timeplate fast_clk_tp =
force_pi 0 ;
measure_po 0.500 ;
pulse CLKA 0.750 1.50 ;
pulse CLKB 0.750 1.50 ;
period 3.000 ;
end ;

To correct the syntax, you could change the time scale to picoseconds, and adjust the time value to meet
the scale as follows:

set time scale 10 ps ;

set strobe_window time 1 ;

timeplate fast_clk_tp =
force_pi 0 ;
measure_po 50 ;
pulse CLKA 75 150 ;
pulse CLKB 75 150 ;
period 300 ;
end ;

The units supported are ms, us, ns, ps, and fs.
The tool translates the time scale in the procedure file into a Verilog ‘timescale directive in the Verilog
testbench when writing patterns in Verilog format.
If the time scale number you specify in the test procedure file is 1 or larger, the resulting Verilog ‘timescale
directive has the same time unit (resolution) and time precision. For example, "set time scale 1 ns ;"
would result in this Verilog directive:

`timescale 1ns / 1ns

750 Tessent™ Shell User’s Manual

 Test Procedure File
Set Statement

If you want the testbench to have smaller precision than resolution, there are several ways to designate
this:

• Specify a time scale number of less than 1 in the procedure file. For example, "set time scale 0.5
ns ;" produces this Verilog directive:

`timescale 1ns / 100ps

• Add non-zero significant bits to the time scale in the procedure file. For example, "set time scale
10.05 ns ;" produces this Verilog directive:

`timescale 1ns / 10ps

• Add trailing zeros as significant bits for an asynchronous clock period or pattern_sets period
(when creating IJTAG patterns). For example, an "add_clocks ‑period 10.00ns" command
produces this Verilog directive:

`timescale 1ns / 10ps

• Use the SIM_PRECISION parameter file keyword. For example, "SIM_PRECISION 0.5ns;"
produces this Verilog directive:

`timescale 1ns / 100ps

The precision in the Verilog testbench can originate from any of the previous sources, and the tool uses
the smallest specified precision when writing out the Verilog testbench.
The resolution in the Verilog testbench originates from the procedure file. When you use multiple
procedure files, the various "set time scale" statements can specify different values, and the tool uses the
smallest specified resolution when writing the Verilog testbench.

set strobe_window time Statement

Defines the strobe-window width. The "set strobe_window time" statement must be at the beginning of the
procedure file, before any timeplate or procedure definition. If you do not specify the strobe_window time,
it defaults to the maximum allowable size. For example, if you look at a timeplate, and if there is a 10 ns
window between the measure_po event and the next event (or end of timeplate), that is the size of the
strobe window. If there are multiple timeplates, then the smallest strobe window from the timeplates is the
maximum allowable strobe window.
Some tester formats measure primary outputs (POs) at the exact time that you specify with the
measure_po statement in the timeplate. However, other tester formats, such as STIL, require that
output measurements occur during a specified window of time (window_width). For WGL, this statement
changes the strobe window in the output file.
A strobe window can only stretch from the measure_po time to the end of the cycle or the next force or
pulse event. For example, if you issue a measure_po at time 10 and the rising edge of a pulse at time
30, the strobe window can only be a maximum of 20. Strobe_window lets you know that, starting at the
measure_po time, the primary output should be stable for the time specified by the strobe window.

Note:
Strobe_window only affects the following formats: STIL, TSTL2, and WGL.

Tessent™ Shell User’s Manual 751

Test Procedure File
Alias Definition

set default_timeplate Statement

Specifies a timeplate that can be used for any procedure definition that does not explicitly specify a
timeplate. The referenced timeplate_name must be defined prior to the set default_timeplate statement in
the procedure file.

set autoforce Statement

An optional statement that controls the behavior for automatically adding force events. If included, this
statement must appear at the beginning of the procedure file, prior to any procedures.
By default (without this statement), if a constrained pin is not forced to the constrained value in the
test_setup procedure, a force event is automatically added to the first cycle of the test_setup procedure.
If the test_setup procedure starts with a call to a subprocedure, then the force event is added to the
first cycle following the subprocedure. If a force event already exists in the test_setup procedure for a
constrained pin, then no additional force event is added for that pin.
When you include the "set autoforce off" statement, the tool does not add any force events on the
constrained pins to the test setup procedure.
Including the "set autoforce off" statement also prevents the tool from forcing clock pins to the inactive
state at the beginning of the load_unload procedure. The statement also disables copying the last value
forced on an input port in test_setup and prevents it from becoming a force at the start of the load_unload
procedure.
The "set autoforce off" statement also turns off auto forcing Z values on bidis in the load_unload
procedure—refer to “Load_Unload (Required)” on page 784.

Alias Definition
The Alias definition groups multiple signal names or cell paths into a single alias name. Signal Alias
statements are useful in procedures or timeplates where multiple signals need to be assigned to the same
value at the same time.
Cell Alias statements are used to group cell paths into a single alias name. You must define aliases
before using them. The definition can occur at any place in the procedure file outside of a timeplate or
procedure definition.

Note:
When saving STIL2005, CTL, or Structural_STIL patterns, all aliases defined in the procedure file
are defined as SignalGroups in the resulting STIL file.

There is a predefined alias available for specifying all bidirectional pins. The "_ALL_BIDI" keyword may
be useful for forcing all bidirectional pins to a specified value without having to identify each individual pin.
For example:

force _ALL_BIDI Z;

In using a cell Alias statement to group cell paths from condition statements into a single alias name, it
is possible to override a condition statement in a named capture procedure with a subsequent condition
statement that occurs in the same place (global condition, or local to a specific cycle). A condition
statement can only override a previous condition if the first condition is specified using an alias name, and
if the second condition is specified without using an Alias statement.

752 Tessent™ Shell User’s Manual

 Test Procedure File
Alias Definition

Tip
When using multiple named capture procedures where each procedure requires many condition
statements, it is helpful to group cells into a common name and apply the condition statement
once to the entire group of cells, and then override specific cells that need a different value
than what was applied to the group. This frees you from having to enter numerous condition
statements for each named capture procedure, while only a handful of the cells require different
values for each procedure.

The Alias definition has the following format:

alias alias_name = pin_name [, pin_name ...];

or

alias alias_name = cell_name [, cell_name ...];

• alias_name
A string that specifies the name of the alias.

Note:
The alias_name you specify should begin with an alphabetical character. If you want the
name to begin with a numerical character, you must put the name in quotation marks.

• pin_name
A repeatable string that specifies the pin name to associate with the alias name.

• cell_name
A repeatable string that specifies the cell name to associate with the alias name.

Alias Examples
This example groups two signal names into a single alias name.

alias my_group = T, U;

This next example shows how a named capture procedure should look when using an Alias statement
for condition cells. The example sets each of four cells to a value of 0, and then the fourth cell (/inst_3/
blockb/reg_2/Q) is overridden with a value of 1.

alias cond_cells = "/inst_0/blocka/reg_1/Q", "/inst_1/blocka/reg_1/Q",

"/inst_2/blocka/reg_1/Q", "/inst_3/blockb/reg_2/Q";
timeplate tp1 =
force_pi 0;
measure_po 10;
pulse ref_clk 50 50;
period 100;
end;

Tessent™ Shell User’s Manual 753

Test Procedure File
Timing Variables
procedure capture capture1 =
timeplate tp1;
condition cond_cells 0;
condition /inst_3/blockb/reg_2/Q 1;
// overrides condition in previous statement
cycle =
force scan_en 0;
force ctrl_a 1;
force_pi;
pulse ref_clk;
end;
cycle =
force_pi;
measure_po;
pulse ref_clk;
end;
end;

This example shows how to define a user-defined bus in a procedure file:

alias wdata = "D[0]", "D[1]", "D[2]", "D[3]";

And this shows how to assign a value to that user-defined bus:

procedure sub_procedure subpro1 =

scan_group grp1 ;
timeplate shift_tp ;
cycle =
force wdata 0010 ;
pulse ref_clk ;
end;
end;

Timing Variables
Two timing variable block definitions enable a procedure file to express timing using variables and
equations, and to have this equation-based timing preserved in the tool and reproduced in the correct
syntax in pattern output files.
Test data languages such as WGL and STIL have the ability to express time values in the timing blocks
as numerical values or as equations based on variables. Using equation-based timing enables one value
to be specified for a global attribute, such as the test cycle period, while other values are derived from this
using equations.
The two timing block definitions are called "timing_variables" and "variables". In the "timing_variables"
block, variables can be defined and assigned timing values. These values are expressed in the time scale
that is already specified by the Set Time Scale statement. The "timing_variables" block must be defined
before the timeplate definitions.
The "variables" block is used to define variables that are not time values and have no units associated
with them. These variables can only be assigned integer numbers, and can be used as scaling multipliers
in the timing equations.

754 Tessent™ Shell User’s Manual

 Test Procedure File
Timing Variables

The variables in the timing_variables block can also be assigned timing equations instead of time values.
These equations can use either timing values or previously defined variables or timing variables as
operands. When using timing equations, you must ensure that the final value has a valid time unit. When
the tool parses the procedure file, timing variables that are computed to have an invalid time unit cause a
W42 DRC error.

Note:
The event statements in the timeplate definition block accept timing values and timing variables.

When saving patterns in the Verilog, WGL, and STIL supported formats, the waveform tables in these
formats are written using the equations and variables, and the variables are defined in the appropriate
definition blocks that exist in each format. When saving patterns in formats that don’t support equation-
based timing, the equations are computed and the timing information is specified as the resulting numeric
values in the pattern file. Setting the ALL_FLATTEN_TIMING parameter file keyword to "1" causes
Verilog, WGL, and STIL outputs to compute the timing equations and use only the resulting numeric
values in the output files. Any equation that does not compute to an integer value is rounded to the
nearest integer value.
The "timing_variables" block has the following syntax:

variables =
variable_name = integer;
[variable_name = integer; …]
end;

timing_variables =
variable_name = time_or_equation;
[variable_name = time_or_equation; …]
end;

Note that time_or_equation can either be an integer time value or a time equation. A time equation is
expressed using operators and operands. An operator is one of +, -, *, or /. An operand can be a time
value or a variable name (time or scaling variable). The multiplication and division operators (* and /)
take precedence over the addition and subtraction operators (+ and -). You can use parenthesis to group
operations for precedence.

Note:
In the timeplate definitions, any place where a time value can be used, a timing variable is also
valid. A scaling variable from the "variables" block cannot be used in a timeplate definition. These
can only be used in time equations.

Variable names can be any identifier except for reserved keywords used in the procedure file syntax
(such as "period" and "force_pi"). The variable names must conform to the rules that apply to all identifiers
used in the procedure file (alpha numeric string, starting with an alpha character, and no reserved
punctuation marks). If reserved characters or reserved words are used in a variable name, the name must
be enclosed in quotation marks.

Equation-Based Timing Example

The following is a partial example of using equation-based timing.

Tessent™ Shell User’s Manual 755

Test Procedure File
Timing Variables

set time scale 1.0 ns;

variables =
v_scale = 1;
end;

timing_variables =
t_period = 100;
t_force = 0;
t_meas = ((t_period * 0.1) * v_scale );
t_rise = ((t_period / 2) * v_scale );
t_width = ((t_period * 0.2) * v_scale);
end;

timeplate tp1 =
force_pi t_force;
measure_po t_meas;
pulse ref_clk t_rise t_width;
period t_period;
end;

This is how the preceding timing example would be represented in the STIL output:

Spec STUCK_spec {
Category STUCK_cat {
v_scale = '1';
t_period = '100ns';
t_force = '0ns';
t_meas = '(t_period*0.1)*v_scale';
t_rise = '(t_period/2)*v_scale';
t_width = '(t_period*0.2)*v_scale;
}
}

Timing STUCK_timing {
WaveformTable tset_tp1 {
Period 't_period';
Waveforms {
input_time_gen_0 { 01 { 't_force' D/U; }}
input_time_gen_1 { 01 { '0ns' D; 't_rise' D/U;
't_rise+t_width' D;}}
_po_ { LHX { '0ns' X; 't_meas' l/h/x; 't_rise' X;}}
}
}
}

This is how the timing example would be represented in the WGL output:

equationsheet STUCK_sheet
exprset STUCK_set
v_scale := 1.0;
t_period := 100nS;
t_force := 0nS;

756 Tessent™ Shell User’s Manual

 Test Procedure File
Timeplate Definition
t_meas := (t_period * 0.1) * v_scale;
t_rise := (t_period / 2) * v_scale;
t_width := (t_period * 0.2) * v_scale;
_tp1_fall_1 := t_rise + t_width;
end
end

timeplate tp1 period t_period

"input_a" := input [t_force:S];
…
"output_z" := output[0nS:X, t_meas:Q, t_rise:X];
…
"refclk" := input[0nS:D, t_rise:S, _tp1_fall_1:D];
end

Timeplate Definition
The timeplate definition describes a single tester cycle and specifies where in that cycle all event edges
are placed.
You must define all timeplates before they are referenced. A procedure file must have at least one
timeplate definition. All clocks must be defined in the timeplate definition. The period statement must be
the last statement in the timeplate definition.
The timeplate definition has the following format:

timeplate timeplate_name =
timeplate_statement
[timeplate_statement …]
period time;
end;

The following list contains available timeplate_statement statements. The timeplate definition should
contain at least the force_pi and measure_po statements. You are not required to include pulse
statements for the clocks. But if you do not "pulse" any of the clocks, the tool uses two cycles to pulse a
clock, resulting in larger patterns.
The tool uses the pulse_clock statement rather than individual pulse statements when generating default
procedures.

timeplate_statement:
offstate pin_name off_state;
force_pi time;
bidi_force_pi time;
measure_po time;
bidi_measure_po time;
force pin_name time;
measure pin_name time;
pulse pin_name time width [, time width];
pulse_clock time width [, time width];

Tessent™ Shell User’s Manual 757

Test Procedure File
Timeplate Definition

Note:
In timeplate_statement definitions, you can use timing variables instead of time values. For more
information, refer to “Timing Variables” on page 754.

The following is a list of statements in the timeplate definition:

• timeplate_name
A string that specifies the name of the timeplate.

Note:
The timeplate_name you specify should begin with an alphabetical character. If you want
the name to begin with a numerical character, you must put the name in quotation marks.

• offstate pin_name off_state

A literal and double string that specifies the inactive, off-state value (0 or 1) for a specific named
primary input pin that is pulsed within this timeplate but is not defined as a clock pin by the
add_clocks command. The complex timeplates are most useful in the shift procedure where a
non-clock pin must be pulsed while still maintaining a single cycle in the shift procedure.
This statement must occur before all other timeplate_statement statements. This statement is
required for any pin that is not defined as a clock pin by the add_clocks command but is pulsed
within this timeplate.

Note:
An "offstate" statement does not automatically force pin_name to its off state at time 0. For
that to occur, you must force or pulse pin_name appropriately in a procedure.

• force_pi time
A literal and integer pair that specifies the force time for all primary inputs.

• bidi_force_pi time
A literal and integer pair that specifies the force time for all bidirectional pins. This statement
enables the bidirectional pins to be forced after applying the tri-state control signal, so the system
avoids bus contention. This statement overrides "force_pi" and "measure_po".

• measure_po time
A literal and integer pair that specifies the time at which the tool measures (or strobes) the
primary outputs.

Note:
Capture clocks pulsing on the same cycle must have an overlapped clock waveform.
If they do not, the tool splits the capture cycle into two cycles. This results in an error
reporting that a measure_po event is absent.

758 Tessent™ Shell User’s Manual

 Test Procedure File
Timeplate Definition

• bidi_measure_po time
A literal and integer pair that specifies the time at which the tool measures (or strobes) the
bidirectional pins. This statement overrides "force_pi" and "measure_po".

• force pin_name time

A literal, string, and integer that specifies the force time for a specific named pin.

Note:
This force time overrides the force time specified in force_pi for this specific pin.

• measure pin_name time

A literal, string, and integer that specifies the measure time for a specific named pin. You can use
a "measure" statement in timeplates only to specify a measure time for a pin.

Note:
This measure time overrides the measure time specified in measure_po for this specific
pin.

• pulse pin_name time width [, time width]…

A literal, string, and repeatable integer set that specifies the pulse timing for a specific named pin.
pin_name — String that refers to a pin in the design. Valid pins must meet one of the following
conditions:
Defined as a clock pin using the add_clocks command.
Not defined as a clock pin, but has a pulse signal and an off-state specified by the "offstate"
statement.
time — Integer that defines the offset from time 0 to the leading edge of the pulse.
width — Integer that defines the width of the pulse.
To define a multiple-pulse waveform, include multiple time and width pairs separated by a
comma.
All pulses must occur within the tester cycle period. You define this period using the "period"
keyword.

Note:
Multiple pulses are only supported for the following output formats: Verilog, WGL, STIL,
STIL2005, CTL, FJTDL, MITDL, and TSTL2. Additionally, the TSTL2 output format does
not support more than two pulses.

For MITDL format there is restriction that multiple pulse timing must be a cyclical repetition of the
first pulse. Consequently, multi-pulse and double-pulse timing in the procedure file only works in
the MITDL output without an error if the timing fits the restrictions of the MITDL syntax.

Tessent™ Shell User’s Manual 759

Test Procedure File
Timeplate Definition

• pulse_clock time width [, time width ]…

A literal and integer set that specifies the pulse timing for all signals defined as clocks, unless
another statement such as a "force" or "pulse" exists for a particular clock signal. This is similar to
the force_pi statement, which specifies the timing for ports that are not explicitly overridden by a
force statement for those specific ports.
time — Integer that defines the offset from time 0 to the leading edge of the pulse for the first
pulse. For subsequent edges in a multi pulse clock, time equals the time of the previous leading
edge plus the period of the clock.
width — Integer that defines the width of the pulse.
You can use the pulse_clock statement to ensure that any added clocks (especially internal
clocks) automatically have defined timing.
You may have multiple pulse_clock statements within a timeplate definition, as long as each
statement has a different number of offset and width pairs. If two pulse_clock statements in the
timeplate definition have the same number of offset and width pairs, the tool issues an error.
For more information on multiple-pulse clocks, refer to Multiple-Pulse Clocks.
All pulses must occur within the tester cycle period. You define this period using the "period"
keyword.
For example (1x pulse_clock):

timing_variables =
tester_period = 10;
strobe_1 = (0.96 * tester_period);
t_time = (0.25 * tester_period);
t_width = (0.5 * tester_period);
end;

timeplate tessent_ijtag =
force_pi 0 ;
measure_po strobe_1;
force tck 0;
pulse_clock t_time t_width;
period tester_period;
end;

• period time
A literal and integer pair that defines the period of a tester cycle. This statement ensures that the
cycle contains sufficient time, after the last force event, for the circuit to stabilize. The time you
specify should be greater than or equal to the final event time.

760 Tessent™ Shell User’s Manual

 Test Procedure File
Timeplate Definition

Example 1
timeplate tp1 =
force_pi 0;
pulse T 30 30;
pulse R 30 30;
measure_po 90;
period 100;
end;

Example 2
The following example shows a shift procedure that pulses the b_clk pin with an off-state value of 0. The
timeplate tp_shift defines the off-state for the b_clk pin. The b_clk pin is not declared as a clock in the
ATPG tool.

timeplate tp_shift =
offstate b_clk 0;
force_pi 0;
measure_po 10;
pulse clk 50 30;
pulse b_clk 140 50;
period 200;
end;

procedure shift =
timeplate tp_shift;
cycle =
force_sci;
measure_sco;
pulse clk;
pulse b_clk;
end;
end;

Example 3
In the following example, the b_clk pin is not declared as a clock in the ATPG tool. However, the shift
procedure specifies that the pin is to be pulsed twice with an off-state of 0.

timeplate tp_shift =
offstate b_clk 0;
force_pi 0;
measure_po 10;
pulse clk 50 30;
pulse b_clk 40 50, 140 50;
period 200;
end;

procedure shift =
timeplate tp_shift;

Tessent™ Shell User’s Manual 761

Test Procedure File
Timeplate Definition
cycle =
force_sci;
measure_sco;
pulse clk;
pulse b_clk;
end;
end;

762 Tessent™ Shell User’s Manual

 Test Procedure File
Multiple-Pulse Clocks

Multiple-Pulse Clocks
You can use the pulse_clock statement to handle multiple-pulse clock timing and still use a single generic
timeplate definition as a template in various flows. The pulse_clock statement handles multiple-pulse
timing definitions in the same manner as the pulse statement.

The pulse_clock Statement

Inferred Timing
Differences Between Default add_clock and 1x Multiplier Clock

The pulse_clock Statement

In a timeplate statement, each pulse_clock statement has a different number of integer pairs for the offset
and width of the clocks. The different statements represent 1x, 2x, 3x, and so on, pulse timing for clocks.
The frequency multiplier that you specify for the clocks identifies the appropriate pulse timing used for
them.
When you specify a multiplier for a clock and no pulse_clock statement exists for that clock, the tool
creates inferred timing for the clock using the timeplate period. The tool issues an error when a port-
specific pulse or force statement exists for the clock and the timing in the statement does not specify the
correct number of pulse statements to match the frequency multiplier of the clock.
The following example has multiple pulse_clock statements. It is a timeplate that includes both a port
specific pulse statement for a clock and the generic pulse_clock statements for all other clocks. The
first pulse_clock statement sets the default clock timing for this timeplate and contains a single pair
of numbers (offset and width). Clocks other than "SlowClockA" that do not have frequency multipliers
use this timing. Clocks with 2x multipliers use the second pulse_clock statement, and clocks with 4x
multipliers use the third pulse_clock statement. The tool uses inferred timing for clocks specified with any
other frequency multiplier and issues an error if "SlowClockA" has a frequency multiplier of 2x or more.

timeplate tp1 =
force_pi 0;
measure_po 95;
pulse SlowClockA 20 50;
pulse_clock 30 30;
pulse_clock 13 25, 63 25;
pulse_clock 6 12, 31 12, 56 12, 81,12;
period 100;
end;

The following example shows a timeplate with one port-specific pulse and one pulse_clock statement
for 4x multiplier timing. Clocks other than "ClockA" that do not have a frequency multiplier use force_pi
timing. Inferred timing only occurs when clocks have frequency multipliers, which means other clocks still
use NRZ timing when you use multiple cycles to create the clock pulse.

timeplate tp1 =
force_pi 0;
measure_po 95;
pulse ClockA 20 50;
pulse_clock 6 12, 31 12, 56 12, 81, 12;
period 100;
end;

Tessent™ Shell User’s Manual 763

Test Procedure File
Inferred Timing

Inferred Timing
Based on the period of the timeplate, the tool creates inferred timing for frequency multiplied clocks when
there are no pulse_clock statements in the timeplate with the correct number of clock edges for the clock.
The total period of a clock pulse is the period of the timeplate divided by the frequency multiplier of the
clock. The offset for the leading edge of the first clock pulse is one-fourth of the period of the clock. For
example, the inferred timing for a 4x clock in a timeplate with a period of 200 is equivalent to the following
pulse_clock definition:

pulse_clock 13 25, 63 25, 113 25, 163 25

Figure 187. 200ns Timing Waveform

The first edge is one-fourth the period of the clock rounded to the nearest integer, and the width of the
pulse is one-half the period of the clock. Each subsequent edge is the previous leading edge plus the
period of the clock.
The tool bases the inferred timing for a 1x frequency-multiplied clock on any other clock timing found for a
single pulse clock; otherwise, it uses the inferred timing formula.
When you specify a timeplate period and a clock frequency multiplier that combine to create inferred
timing that is too small to be integer timing, the tool automatically reduces the procedure file timescale
and scales all timing numbers to larger values.
For example, suppose the timescale for the procedure file is 1ns, the period of the timeplate is 5, and the
clock frequency multiplier is 10. The tool automatically adjusts the timescale to 100ps and the period of
the timeplate becomes 50. It adjusts all of the other numbers accordingly. In this case, the tool multiplies
them by 10.

Differences Between Default add_clock and 1x Multiplier

Clock
Default add_clock clocks use the time specified by pulse_clock statements with one pulse or by pin-
specific pulse statements. However, frequency-multiplied clocks use the timing specified for them only if
they match the number of pulses. If this is not the case, the tool uses inferred timing and issues an error if
there are mismatches.
Clocks specified with a frequency multiplier of one behave differently than default clocks. For this reason,
you must specify the timing for a 1x frequency-multiplied clock with a single clock pulse. The tool does not
use NRZ timing with multiple cycles or forced timing edges, and it issues an error if the timeplate specifies
a double-pulse or multiple-pulse timing for the 1x clock.

764 Tessent™ Shell User’s Manual

 Test Procedure File
Always Block

Always Block
This optional block definition specifies events that happen in all cycles of all procedures. Because the
always block specifies events for all cycles, it is used with all timeplates and does not require a timeplate
to be referenced in the block. Also, any signal that is pulsed in the always block must have a pulse
waveform in all timeplate definitions.
If you defined any pulse-always clocks using the add_clocks command, an always block is automatically
created in the procedure file, if one does not already exist, and a pulse statement added for each clock.
Similarly, if you pulse a clock signal in the always block, the signal is automatically defined as a pulse-
always clock. For more information, refer to the add_clocks description in the Tessent Shell Reference
Manual.

Note:
Pulse-always clocks are not automatically pulsed in a named capture procedure. The clocks must
be pulsed explicitly.

All events specified in the always block is subject to rules checks that apply to each procedure. In other
words, the events in the always block is added to each cycle of each procedure, and all DRC rules still
apply to these events.
When saving patterns that preserve the structure of the procedures as macros (such as the CTL
pattern file, or structural STIL pattern file), the events in the always block is placed in the cycles of each
procedure. The always block is not present in the structural pattern file as a macro or procedure.

Always Block Syntax

The always block has the following syntax.

always =
always_statement ;
[always_statement ; ... ]
end ;

The always_statement is defined as one of the following.

pulse pin_name ;
force pin_name value ;

Always Block Example

The following is a partial example of an always block.

set time scale 1,0 ns ;

timeplate tp1 =
force_pi 0 ;
measure_po 10 ;
pulse ref_clk 20 20, 60 20 ;
pulse shift_clk 50 20 ;
period 100 ;
end ;

Tessent™ Shell User’s Manual 765

Test Procedure File
Procedure Definition
always =
pulse ref_clk ;
end ;

procedure shift =
timeplate tp1 ;
cycle =
force_sci ;
measure_sco ;
pulse shift_clk ;
end ;
end ;

Procedure Definition
The procedure definition is the heart of the procedure file. The procedure defines precisely how the scan
circuitry operates.
All procedure definitions contain one or more cycle definitions. Each cycle definition in the procedure
specifies a vector; each statement in the cycle specifies which events occur in that vector. The timeplate
being used specifies any timing associated with that vector. The following is a list of rules for writing
procedure definitions:

• If more than one timeplate is defined, you can assign a specific timeplate for each procedure
definition or for each cycle within the procedure definitions. You must assign a timeplate at some
point within a procedure definition.

• You must group all procedure statements, except scan_group, timeplate, apply, and loop, into
cycle statements.

• You cannot specify time values in cycle statements.

• You cannot specify loop statements within cycle statements.

• The order of events within a cycle definition does not matter. The assigned timeplate specifies the
order.

• Within a procedure definition, you can specify a scan group.

• Each scan group needs a unique test procedure file. You associate the test procedure file with
the scan group when you specify the add_scan_groups command.

• Text following "//" is a comment and is ignored.

• You can include blank lines.

• You define a procedure type for a particular scan group (with the exception of the
seq_transparent and clock procedures) only once in a test procedure file.

• You can only have a single test_setup procedure, even if you define multiple scan groups for your
design.

766 Tessent™ Shell User’s Manual

 Test Procedure File
Procedure Definition

The procedure definition has the following general format, but certain statements are restricted to certain
procedures.

procedure procedure_type [proc_name] =

[scan_group scan_group_name;]
proc_statement [proc_statement …]
end;

proc_statement:
[timeplate timeplate_name;]
cycle =
cycle_statement [cycle_statement …]
end;
annotate "quoted string";
apply proc_name #times;
loop loop_count =
cycle =
cycle_statement [ cycle_statement …]
end;
end;

cycle_statement:
force_pi;
bidi_force_pi;
force_sci;
force_sci_equiv;
measure_po;
bidi_measure_po;
measure_sco;
restore_pi;
restore_bidi;
bidi_force_off;
pulse_capture_clock;
force_capture_clock_on;
force_capture_clock_off;
pulse_read_clock;
pulse_write_clock;
force pin_name value;
expect pin_name value;
condition cell_name value;
measure pin_name;
initialize instance_name [value];
pulse pin_name;
timeplate timeplate_name;
annotate "quoted string";

• procedure_type
A string that specifies the type of procedure that follows. The following list contains valid
procedures types:

◦ test_setup ◦ capture ◦ seq_transparent

Tessent™ Shell User’s Manual 767

Test Procedure File
Procedure Definition

◦ shift ◦ ram_passthru ◦ test_end

◦ master_observe ◦ clock_sequential ◦ skew_load

◦ load_unload ◦ sequential ◦ clock

◦ shadow_observe ◦ init_force ◦ sub_procedure

◦ shadow_control

For more information, refer to “Test Procedures” on page 777.

• proc_name
An optional string that specifies the user-defined name of the procedure. Because you can
specify multiple seq_transparent and clock procedures in a test procedure file, these procedure
types require explicit procedure names, proc_name, for each procedure that you define.

Note:
The proc_name you specify should begin with an alphabetical character. If you want the
name to begin with a numerical character, you must put the name in quotation marks.

• scan_group scan_group_name
A literal and string pair that specifies a scan group within a scan procedure. Because some of the
scan procedures are scan group specific, you can specify scan groups within scan procedures.
This makes it possible to define the scan procedures (shift, load_unload) for multiple scan groups
within the same procedure file. You can then specify this file on the add_scan_groups command
for each scan group in this file. If you use the read_procfile command to read a procedure file,
you must include this statement. However, if you use the add_scan_groups command, this
statement is optional because the group is specified on the command line. When the tool writes
out a procedure file, it produces the scan_group statement.

Note:
The scan_group_name argument is case-sensitive if the netlist used is case-sensitive.

• timeplate timeplate_name
A literal and string pair that specifies the name of the timeplate the procedure uses.
A timeplate statement at the beginning of the procedure, outside of the cycle definitions, is the
timeplate used by the entire procedure, if no other timeplates are referenced.
A timeplate statement within a cycle is the timeplate used for that cycle and all other subsequent
cycles until another timeplate statement is encountered. For more information about timeplates,
refer to “Timeplate Definition” on page 757.

Note:
The timeplate_name you specify should begin with an alphabetical character. If you want
the name to begin with a numerical character, you must put the name in quotation marks.

768 Tessent™ Shell User’s Manual

 Test Procedure File
Procedure Definition

• annotate " quoted string ";

A literal and string pair that reports the Verilog testbench annotations during simulation.
The annotate statement is optional and must always include a quoted string. All procedures can
be annotated, including sub-procedures. The annotate statement can occur inside or outside of
cycle blocks, including before the first cycle or after the last cycle.
A special use of the annotate statement is to include TESSENT_PRAGMA directives within a
procedure. TESSENT_PRAGMA directives can affect the behavior of the tool when it writes
patterns.
This example shows the annotate statement in the beginning of a cycle along with the cycle
timeplate statement, before any event statements:

CYCLE =
[ TIMEPLATE tp_name ; ]
[ ANNOTATE "quoted string" ; ]
event_statement;
…
END ;

The following is an example of using the annotate statement outside of a cycle block:

procedure test_setup =
timeplate tp1 ;
annotate "Before first cycle" ;
cycle =
…
end;
annotate "start sub procedure" ;
apply mySub 1 ;
…
end;

The following is an example of an annotate statement used in a test_setup procedure, and how
this appears in a STIL pattern file.

Procedure test_setup =
timeplate tp1;
cycle =
annotate "first cycle in test_setup" ;
force reset 1;
force clock 0;
end;
cycle =
annotate "next annotation" ;
force reset 0;
end;
…

This is a segment of the resulting STIL pattern file:

Tessent™ Shell User’s Manual 769

Test Procedure File
Procedure Definition

W tset_tp1;
V { _pi_ = 0X11XXX;
_po_ = XXXX;
}
Ann {* Begin chain test *}
Ann {* first cycle in test_setup *}
V { …
}
Ann {* next annotation *}
V { …
}

The following is an example of an annotate statement used to include TESSENT_PRAGMA

directives. This pair of simulation_only directives instructs the tool to include the cycles they
surround only in a simulation format. The cycles are eliminated, along with the annotations, for
any other formats.

procedure test_setup =
timeplate tp1 ;
annotate "TESSENT_PRAGMA simulation_only begin";
cycle =
…
end;
iCall …;
…
annotate "TESSENT_PRAGMA simulation_only end";
…
end;

Note:
The ALL_IGNORE_SIMULATION_ONLY parameter keyword can affect which output
files contain simulation_only directives. For more information about the simulation_only
directive, refer to the description of the <format_switch> parameter in the write_patterns
command in the Tessent Shell Reference Manual.

• label "quoted_string";
A literal and string pair for including pattern labels in saved patterns. As with the annotation
statement, you can have one label statement per cycle in a procedure definition. The
quoted_string becomes a pattern label for the vector that corresponds to that procedure cycle.
Only the STIL and WGL pattern formats support a pattern label statement. For pattern file formats
that don't support a pattern label, the label is present as an annotation statement that has the
string "label:" added at the beginning of the label string.
For the simulation testbench, the label is also present as an annotation that has the string "label:"
added at the beginning, and the annotation is echoed when the patterns are simulated. You
can use the existing parameter file keyword SIM_ANNOTATE_QUIET to turn off echoing the
annotations and labels while simulating.
Each pattern label is a unique identifier, with its vector count appended to the end of the label
string.

770 Tessent™ Shell User’s Manual

 Test Procedure File
Procedure Definition

This statement can be used at the start of any cycle, just like an annotation statement. A cycle
cannot contain both a label and an annotation statement.
The following example shows how to use the label statement within the test_setup procedure:

procedure test_setup =
timeplate my_tp;
cycle =
force my_sig 0;
end;
cycle =
label "end of test_setup" ;
force my_sig 1;
end;
end;
The previous example produces the following STIL vectors:
V { _pi_ = …;
}
"end of test_setup_1": V { _pi_ = …;
}

• apply proc_name #times

A literal and double-argument string that tells the tool to apply the specified procedure
the specified number of times. You must use the apply shift statement at least once in the
load_unload procedure. For the apply shift statement, you must enter a proper #times parameter.
If required, you must enter the apply shadow_control statement immediately after the apply shift
procedure statement, and you must set the #times argument to 1. The apply statement is only
valid outside of the cycle blocks because it specifies another group of cycles within another
procedure to be added at that point.

• loop loop_count
A literal and integer pair that specifies the loop count and is followed by a block of statements.
The loop procedure statement takes the loop count and causes all cycles within the loop block
to be repeated by the number of times specified by the count. For example, the following test
procedure file excerpt specifies 3 cycles within the loop that are each repeated 20 times:

procedure test_setup =
timeplate tp1 ;
cycle =
force_pi;
measure_po;
end;
loop 20 =
cycle =
…
end;
cycle =
pulse tck;
end;
cycle =

Tessent™ Shell User’s Manual 771

Test Procedure File
Procedure Definition
…
end;
end; // end loop
end;

Nesting loops within other loops is permitted. For example, the following test procedure file
excerpt causes tck to be pulsed 20 times and clk_a to be pulsed 100 times:

procedure test_setup =
timeplate tp1 ;
cycle =
force_pi;
measure_po;
end;
loop 20 =
cycle =
…
end;
cycle =
pulse tck;
end;
loop 5 =
cycle =
pulse clk_a;
end;
end; // end inside loop
cycle =
…
end;
end; // end outside loop
end;

This statement can be used in procedures but must be specified outside of the cycle statement.
The loop statement is preserved in the flat model when the tool writes the model and is also
present in the TCD files.
When writing out the patterns in tester pattern formats, the loops are preserved where
possible, and unrolled if the syntax of the pattern file does not support loops. Specifying the
ALL_NO_LOOP parameter keyword unrolls loops in the pattern files in similar fashion to sub
procedures that are applied more than once. Using the loop statement to repeat a certain
number of cycles N times is exactly equivalent to putting those cycles within a sub procedure and
applying that procedure N times.

• start_pulse pin_name
A literal and string pair that specifies for the tool to start pulsing the named clock pin in every
cycle, starting with the next cycle encountered. This enables you to specify that a clock that is not
a pulse_always clock should be pulsed in every cycle of an iCall statement. It also enables you to
restart a pulse_always clock that has been temporarily suppressed with the stop_pulse keyword.
This keyword can also be used inside a cycle_statement.

• stop_pulse pin_name

772 Tessent™ Shell User’s Manual

 Test Procedure File
Procedure Definition

A literal and string pair that specifies for the tool to stop pulsing the named clock pin, starting
with the next cycle encountered. This enables you to suppress a pulse_always clock for a known
number of tester cycles until you restart it with the start_pulse keyword. It also enables you to
stop a clock started with the start_pulse keyword when you no longer need it to be pulsed.
This keyword can also be used inside a cycle_statement.

• cycle_statement
The following list describes valid cycle_statement keywords. Cycle_statements cannot contain
time values.

◦ force_pi
A literal that specifies for the tool to force all primary inputs.

◦ bidi_force_pi
A literal that specifies for the tool to force all bidirectional pins.

◦ force_sci
A literal that specifies for the tool, in the shift procedure, to place values on the scan chain
inputs, thus implementing scan cell controllability.

◦ force_sci_equiv
A literal that acts the same as the force_sci statement, except that it also forces all pins
equivalent to the scan input pins. Using this statement places the complement value on the
associated differential pin of a scan input during scan loading. This statement is necessary
because the test procedures do not consider pin equivalence relationships (those specified
with add_input_constraints -equivalent).

◦ measure_po
A literal that specifies for the tool to measure or strobe the primary outputs.

◦ bidi_measure_po
A literal that specifies for the tool to measure or strobe the bidirectional pins.

◦ measure_sco
A literal that specifies for the tool, in the shift procedure, to measure scan output values, thus
implementing scan cell observability. In End Measure Mode (refer to “Creating Test Procedure
Files for End Measure Mode” on page 813), measure_sco is also used in the load_unload
procedure.

◦ restore_pi
A literal that returns primary inputs to their original states (before running this procedure). Use
the restore_pi statement at the end of a seq_transparent procedure.

◦ restore_bidi

Tessent™ Shell User’s Manual 773

Test Procedure File
Procedure Definition

A literal that returns bidirectional pins to their original states (before running this procedure).
Use the restore_bidi statement at the end of a "clock" procedure.

◦ bidi_force_off
A literal that specifies for the tool to force all unconstrained bidirectional pins off.

◦ pulse_capture_clock
A literal that specifies for the tool to pulse the capture clock.

◦ force_capture_clock_on
A literal that specifies the cycle when the capture clock goes active. This statement and
the force_capture_clock_off statement can be used in place of the pulse_capture_clock
statement.
The "_on" refers to the active state of the clock, which is not necessarily the high binary
value. This statement is used only with the non-scan procedures and cannot be mixed with
the following statements in the same procedure:

• pulse_capture_clock

• pulse_write_clock

• pulse_write_clock

◦ force_capture_clock_off
A literal that specifies the cycle when the capture clock goes inactive. This statement and
the force_capture_clock_on statement can be used in place of the pulse_capture_clock
statement.
The "_off" refers to the inactive state of the clock, which is not necessarily the low binary
value. This statement is used only with the non-scan procedures and cannot be mixed with
the following statements in the same procedure:

• pulse_capture_clock

• pulse_write_clock

• pulse_read_clock

◦ pulse_read_clock
A literal that specifies for the tool to pulse the RAM read clock.

◦ pulse_write_clock
A literal that specifies for the tool to pulse the RAM write clock.

◦ force pin_name value

774 Tessent™ Shell User’s Manual

 Test Procedure File
Procedure Definition

A literal and pair of strings that forces the specified value of 0, 1, X, or Z on the specified pin.
The pin names you specify must be valid pin pathnames for primary inputs.

◦ expect name value

A literal and pair of strings that causes the tool to expect the specified value of 0, 1, X, or Z
on the specified internal pin or port. The default value is X. You can use "expect" statements
only in the test_setup and test_end procedure. Internal pins are checked by DRC and are
compared in the testbench. For ports, the tool validates the values in the testbench, the
DRCs, and in the tester pattern formats.

◦ condition cell_name value

A literal and pair of strings that you use at the beginning of a seq_transparent procedure
to identify the necessary scan cell states (conditions) to establish transparency in non-
scan cells. You identify the scan cell by the pin pathname associated with the output of its
state element. The path from the defined pin to the scan cell must only contain buffers and
inverters. The value argument sets the value at the specified pin pathname, which may be
inverted relative to the associated scan cell value.

◦ measure pin_name
A literal and string pair that specifies for the tool to measure the value of the named pin. You
can use a "measure" statement in the capture procedure only to specify a measure on a pin
in a different cycle than the measure_po event.

◦ initialize instance_name value

A literal and pair of strings that initializes the named memory element to the value given. This
statement is particularly useful for initializing the finite state machine in the TAP controller
of boundary scan circuitry, when the TAP does not contain the TRST signal. Once set to a
binary state, the TCK and TMS pins can place the finite state machine in a known state. If not
set, these pins remain at X.
If you do not specify a value, the tool chooses a random value to assign to all latches and flip-
flops with the specified instance name.

◦ pulse pin_name
A literal and string pair that specifies for the tool to pulse the named clock pin.

◦ start_pulse pin_name
A literal and string pair that specifies for the tool to start pulsing the named clock pin in every
cycle. This enables you to specify that a clock that is not a pulse_always clock should be
pulsed in every cycle of an iCall statement. It also enables you to restart a pulse_always clock
that has been temporarily suppressed with the stop_pulse keyword.
This keyword can also be used outside of a cycle_statement. In this case, it takes effect
starting with the next cycle encountered.

◦ stop_pulse pin_name
A literal and string pair that specifies for the tool to stop pulsing the named clock pin. This
enables you to suppress a pulse_always clock for a known number of tester cycles until you
restart it with the start_pulse keyword. It also enables you to stop a clock started with the
start_pulse keyword when you no longer need it to be pulsed.

Tessent™ Shell User’s Manual 775

Test Procedure File
Procedure Definition

This keyword can also be used outside of a cycle_statement. In this case, it takes effect
starting with the next cycle encountered.

◦ observe_method value
A literal and string pair set to a value of master, slave, or shadow, to specify for a specific
observe method to be defined for each named capture procedure.
The following example shows how to use a cycle_statement to force scan inputs and measure
scan outputs:

procedure shift =
scan_group grp1;
timeplate tp1;
cycle =
force_sci;
measure_sco;
pulse T;
end;
end;

776 Tessent™ Shell User’s Manual

 Test Procedure File
Test Procedures

Test Procedures
The test procedure file contains scan and clock procedures, and non-scan procedures. The scan and
clock-related procedures inform the tool how to operate the scan chain and pulse clocks. The non-scan
procedures can represent any type of pattern that the tool produces.
You can use the non-scan procedures to specify in which cycles of the procedure "potential events"
happen. A potential event is an event that the ATPG engine may or may not have created to cover a
certain fault.
To avoid DRC violations, each non-scan procedure must contain the proper statements in the correct
order with the timing from the timeplate. The statements in a non-scan procedure can be spread over any
number of cycles using a different timeplate for each cycle if needed.
A basic pattern consists of loading the scan chains, a default capture procedure, followed by unloading
the scan chains; however, you do not specify the loading and unloading of scan chains in non-scan
procedures. The following shows the basic pattern for non-scan procedures.

All example procedures shown in this section use one of the following two timeplates, unless otherwise
stated:

timeplate tp1 =
force_pi 0;
measure_po 10;
pulse scan_clk 30 10;
pulse sys_clk 30 10;
period 50;
end;

timeplate tp2 =
force_pi 0;
measure_po 10;
pulse scan_mclk 15 10;
pulse scan_sclk 30 10;
period 50;
end;

Test_Setup (Optional)
Shift (Required)
Alternate Shift Procedure (Optional)
Load_Unload (Required)
Shadow_Control (Optional)
Master_Observe (Sometimes Required)

Tessent™ Shell User’s Manual 777

Test Procedure File
Test_Setup (Optional)
Shadow_Observe (Optional)
Skew_Load (Optional)
Clock_Control (Optional)
clock_run (Optional)
Capture Procedures (Optional)
Clock_sequential (Optional)
Init_force (Optional)
Test_end (Optional, all ATPG tools)
Sub_procedure

Test_Setup (Optional)
This optional procedure, which can only contain force, pulse, init, and expect event statements, sets non-
scan elements to the required states for the load_unload procedure. You may use this procedure only
once for all scan groups, and it appears only once at the beginning of the test pattern set.
This procedure is particularly useful for initializing boundary scan circuitry. For an example using this
procedure to set up boundary scan circuitry, refer to "Pattern Generation for a Boundary Scan Circuit" in
the Tessent Scan and ATPG User’s Manual.

Note:
Use the read_modelfile command instead of this procedure to specify the initial values for RAMs.

IJTAG Embedded Instruments

In the "patterns -scan" ATPG context, IJTAG is valid in the test_setup and test_end procedures only. It is
invalid in any other procedure, as well as in ATPG’s analysis mode. Also, only iReset and iCall commands
are valid in the test procedures.
For detailed information, refer to "How to Set Up Embedded Instruments Through Test Procedures" in the
Tessent IJTAG User’s Manual.

Bidirectional Scan Out Pins

The value of all bidirectional scan out pins must be forced to the Z state (indicating it is operating in
"output" mode) to properly sensitize the scan chain. When reading in a test procedure file, the tool
automatically adds force events to the beginning of the load_unload procedure to force all bidi pins to Z.
Bidi pins that are clocks or constrained pins are not forced to a Z, as they were already forced to the off-
state or the constrained values. Bidi scan-in pins are also not forced to a Z. Any bidi pin already forced
later in the load_unload procedure is not forced to a Z. Any bidi forced to a specific value in the test_setup
procedure is instead forced to this value instead of a Z.
Like previous automatic force values, these can be disabled by putting the "set autoforce off;" statement
at the beginning of the procedure file.

Pin Constraints
If you use the add_input_constraints command to set pin constraints, be aware this command only
forces pins during capture. To constrain these pins during test_setup, you should include the same pin
constraints in the test_setup procedure. This ensures the pins are in the same state for loading the first
pattern as for loading all subsequent patterns.

778 Tessent™ Shell User’s Manual

 Test Procedure File
Test_Setup (Optional)

If you do not properly constrain the pins prior to the end of the test_setup procedure, the tool
automatically constrains them by inserting a cycle statement in the test_setup procedure. However, this
automatic handling may not insert the events with the timing you want. Also, the automatic handling is not
included in DRC.
If you have defined input constraints but have not provided a test_setup procedure, the tool automatically
generates a test_setup procedure to force those pins to their constrained values.
You can use both the write_procfile and the report_procedures commands to view the contents of the
test_setup procedure the tool has generated. The write_procfile command writes existing procedure and
timing data to a specified file. The report_procedures command writes the information to the screen.

Example 1
The following is an example using a sub_procedure. In this example, the signal named C retains its value
of 1 during the test unless it is forced to a different value in a later cycle, by another procedure, or it is
overwritten by WGL patterns.

procedure sub_procedure initialize =

template soc_timeplate ;
cycle =
force C 1;
end;
end;

The following example shows how to apply the previous sub_procedure. For more information, refer to
“Sub_procedure” on page 810.

procedure test_setup =
timeplate soc_timeplate;
cycle =
force test_en 1; // force test_en 1
force chip_en 0; // force chip_en to 0
end;
apply initialize 10; // force C to 1 for 10 cycles
end;

Example 2
The following example shows a way to reset a memory. The RST signal is active for the first 128 cycles,
then it is deactivated in the next cycle (cycle 129).

procedure sub_procedure reset_mem =

timeplate soc_timeplate;
cycle =
force RST 1;
end;
end;
procedure test_setup =
timeplate soc_timeplate;
apply reset_mem 128;

Tessent™ Shell User’s Manual 779

Test Procedure File
Shift (Required)
cycle =
force RST 0; // deactivate RST
end;
end;

Example 3
The following example shows a way to use an expect statement in a test_setup procedure. The output
signal (DFT) is expected to be 1 in the first cycle and X in the remaining cycle. An "expect" statement
does not work the same as a force or pulse statement. When none is present, it means do not measure.

procedure test_setup =
timeplate soc_timeplate;
cycle =
expect DFT 1;
end;
end;

Example 4
This example shows a way to start pulsing a clock in a test_setup procedure. The SYSCLK starts pulsing
at cycle number 2 until the end of test.

timeplate soc_timeplate =
force pi;
measure_po 90;
pulse SYSCLK 50 50;
period 100;
end;

procedure test_setup =
timeplate soc_timeplate;
cycle =
force RST_L 0;
end;
cycle =
pulse SYSCLK;
end;
end;

Shift (Required)
This required procedure describes how to shift data one position down the scan chain by forcing the scan
input, toggling the clocks, and strobing the scan output.
Figure 188 shows the data flow process for the shift procedure.

780 Tessent™ Shell User’s Manual

 Test Procedure File
Shift (Required)

Figure 188. Shift Procedure

Within this procedure, you must use the force_sci, or force_sci_equiv, and the measure_sco event
statements. You can also use the force and pulse event statements. A shift procedure can contain more
than one cycle, although not all pattern formats can support multiple cycles and parallel load. Pattern
formats that do not support multiple cycles are any parallel format other than STIL and Verilog. If you
use write_patterns to write out one of these other parallel formats with a multicycle shift procedure, the
command generates an AG11 error.
The times at which the timeplate used by the shift procedure applies the force_sci and measure_sco
commands must be consistent with proper operation of the load_unload procedure. The measure_sco
occurs at the measure_po time specified in the timeplate. The force_sci occurs at the force_pi time
specified in the timeplate.
The following are examples of the shift procedure for both mux-DFF and LSSD architectures.

Mux-DFF Example
procedure shift =
timeplate tp1;
cycle =
// force scan chain input
force_sci;
// measure scan chain output
measure_sco;
// pulse the scan clock
pulse scan_clk;
end;
end;

LSSD Example
procedure shift =
timeplate tp2;
cycle =
// force scan chain input
force_sci;
// measure scan chain output
measure_sco;
// pulse master clock
pulse scan_pclk;
// pulse slave clock
pulse scan_sclk;
end;
end;

Tessent™ Shell User’s Manual 781

Test Procedure File
Alternate Shift Procedure (Optional)

Figure 189 graphically displays the waveforms for the clock pin, the scan-in pin, and the scan-out pin
derived from the Mux-DFF shift procedure example. This timing diagram shows one scan chain shift
cycle, assuming the time unit is 1ns.

Figure 189. Timing Diagram for Shift Procedure

The procedure contains four scan events: forces scan input values at 0ns, strobes (or measures) scan
output values at 10ns, pulses the scan clock scan_clk (turning it on at 30ns and off at 40ns), and holds
the state of the last event until the procedure finishes at 50ns.
A timing clock monitors when each significant event occurs. If the timing clock is at X when the shift
procedure begins, the timing clock assigns those four events with time values X, X+10, X+30, and X
+40. When the shift procedure finishes, the timing clock advances to X+50. The shift cycle ending time
becomes the starting time for the next shift cycle.

Alternate Shift Procedure (Optional)

When using on-chip clock generators, such as programmable PLLs, it is sometimes necessary to change
values on input (control) signals to the clock generator a cycle or two before the change in generated
clocking schemes is realized. When the shift clocks for a scan chain are also provided by the on-chip
clock generator, it is sometimes not possible to reprogram the clock generator near the end of the scan
chain shifting in order to stop the shift clock and prepare for the capture clocks. To accomplish this you
might want to use an alternative shift procedure.
Alternate shift procedures have names, as described in the following paragraph. Alternate shift
procedures can only be used for single shifts (a pre shift or a post shift), and there must be one un-named
normal shift as the main shift in the required load_unload procedure. Refer to Load_Unload (Required).
The shift procedure enables an optional name following the shift procedure type. For each scan group,
one shift procedure must be defined that has the default name of shift. For each scan group, additional
alternate shift procedures can be defined as long as each has a unique name.
Each shift procedure is required to contain a force_sci or force_sci_equiv statement and a measure_sco
statement.

782 Tessent™ Shell User’s Manual

 Test Procedure File
Alternate Shift Procedure (Optional)

Syntax

procedure shift [ procedure_name ] =

…
end ;

Example
The following is a partial example of how the alternate shift procedure might be used in a procedure file
for a scan chain with a length of 100.

timeplate tp1 =
force_pi 0;
measure_po 10;
pulse ref_clk 50 50;
period 100;
end;
procedure shift =
timeplate tp1;
scan_group grp1;
cycle =
force ctrl_a 1;
force_sci;
measure_sco;
pulse ref_clk;
end;
end;
procedure shift shift_last =
timeplate tp1;
scan_group grp1;
cycle =
force ctrl_a 0;
force_sci;
measure_sco;
pulse ref_clk;
end;
end;
procedure load_unload =
timeplate tp1;
scan_group grp1;
cycle =
force ref_clk 0;
force scan_en 1;
force ctrl_a 1;
end;
apply shift 98;
apply shift_last 1;
apply shift_last 1;
end;

Tessent™ Shell User’s Manual 783

Test Procedure File
Load_Unload (Required)

Load_Unload (Required)
This required procedure describes how to load and unload the scan chains in the scan group. To load the
scan chain, you must force the circuit into the appropriate state for the start of the shift sequence. This
includes forcing clocks, resets, RAM write control signals, and any other signals that need to be at their
off-states for scan chain loading. Also, if a reset signal is defined as a clock, and pin constrained to its
off-state in the dofile, it needs to again be forced to its off-state in the load_unload and named capture
procedures in order to avoid a P34 DRC.
The tool automatically adds the off-state for clock pins, constrained pin values, and other pins that have
values forced in the test_setup procedure as force statements to the beginning of the load_unload
procedure (if not present). This helps reduce DRC failures.
Figure 190 shows the data flow for the load_unload procedure.

Figure 190. Load_Unload Procedure

If the scan out pin is bidirectional, you must force its value to the Z state (indicating it is operating in
"output" mode) to properly sensitize the scan chain. If there is a scan enable signal, you must force it on
to enable the scan chain prior to the shift. You then use the apply shift statement to specify the number of
shift cycles (which equals the number of scan elements in the chain). If you have optionally included the
shadow_control procedure (which, if used, immediately follows the shift procedure), you must also include
the apply command.
The following list includes the basic statements in the load_unload procedure:

Mux-DFF Example
procedure load_unload =
timeplate tp1;
cycle =
// force clocks off
force RST 0;
force CLK 0;
// activate scanning mode
force scan_en 1;
end;
// shift data thru each of 7 cells
apply shift 7;
end;

784 Tessent™ Shell User’s Manual

 Test Procedure File
Load_Unload (Required)

LSSD Example
procedure load_unload =
timeplate tp2;
cycle =
// force all clocks off
force RST 0;
force CLK 0;
force scan_sclk 0;
force scan_mclk 0;
end;
// apply shift procedure 7 times
apply shift 7;
end;

The timing for the load_unload procedure is generally straightforward. The load_unload procedure
contains the apply statement. Therefore, the total time for a load_unload procedure includes the time
specified by the timeplate being used plus the time required to run the apply cycles.
For example, examine the following load_unload procedure, using the Example of a shift procedure in
“Alternate Shift Procedure (Optional)” on page 782.

procedure load_unload =
timeplate tp1;
cycle =
force RST 0;
force CLK 0;
force scan_en 1;
end;
apply shift 1;
end;

The timeplate of the load_unload procedure specifies the period is 50 ns. However, the load_unload
procedure includes an apply statement that runs one shift procedure. The shift procedure requires an
additional 50 ns. Thus, the load_unload procedure actually requires a total time of 100 ns, as shown in
Figure 191.

Tessent™ Shell User’s Manual 785

Test Procedure File
Shadow_Control (Optional)

Figure 191. Timing Diagram for Load_Unload Procedure

Within the load_unload procedure, after the completion of the cycle block, the shift procedure starts at 50
ns, runs for 50 ns, and ends at 100 ns. Thus, the load_unload procedure also ends at 100 ns.
As with the shift procedure, the timing clock determines the event times for the load_unload procedure. If
the timing clock is at Y when the load_unload procedure begins, the first three events happen at time Y.
When the apply cycle runs, the timing clock advances to Y+50, which is when the shift procedure begins.
As mentioned previously, the shift procedure requires 50 time units. Therefore, when the apply cycle
finishes, the timing clock reads Y+100.
Because it is the last event in the load_unload procedure, the end of the apply cycle determines the end
of the load_unload procedure.

Shadow_Control (Optional)
The optional shadow_control procedure, which may only contain force and pulse event statements,
describes how to load the contents of a scan cell into the associated shadow.

Note:
This procedure is not supported when using SSN.

If you use this procedure, you must also apply the shadow_control command in the load_unload
procedure. This procedure must not disturb the contents of any of the scan cells. Figure 192 shows the
data flow for the shadow_control procedure.

786 Tessent™ Shell User’s Manual

 Test Procedure File
Shadow_Control (Optional)

Figure 192. Shadow_Control Procedure

The following procedure file example demonstrates the syntax for applying a shadow_control procedure
within a load_unload procedure:

proc shift =
force_sci 0;
measure_sco 0;
force SK2 1 1;
force SK2 0 2;
force SK1 1 3;
force SK1 0 4;
end;

proc load_unload =
force WE 0 0;
force ABC 1 0;
force COMB_B 1 0;
force SK2 0 0;
force CLK 0 0;
force SK1 0 0;
force sh_clk 0 0;
apply shift 5 1;
apply shadow_control 1 2;
end;

proc shadow_control =
force sh_clk 1 1;
force sh_clk 0 2;
end;

proc master_observe =
force WE 0 0;
force SK2 0 0;
force CLK 0 0;

Tessent™ Shell User’s Manual 787

Test Procedure File
Master_Observe (Sometimes Required)
force SK1 0 0;
force sh_clk 0 0;
force SK1 1 1;
force SK1 0 2;
end;

proc shadow_observe =
force WE 0 0;
force EN 1 0;
force SK2 0 0;
force CLK 0 0;
force SK1 0 0;
force sh_clk 0 0;
force CLK 1 1;
force CLK 0 2;
force SK1 1 3;
force SK1 0 4;
end;

Master_Observe (Sometimes Required)

The master_observe procedure, which may only contain force and pulse event statements, describes
how to place the contents of a master element into the output of its scan cell, where you can observe it by
using the unload operation.
Figure 193 shows the data flow for the master_observe procedure.

Figure 193. Master_Observe Procedure

You do not need to use this procedure if the master element’s output is the output of the scan cell.
The D1 rule ensures that this procedure does not disturb the master memory element’s contents.
You can override this requirement by changing the D1 rule handling. The following example shows a
master_observe procedure for the LSSD architecture:

788 Tessent™ Shell User’s Manual

 Test Procedure File
Shadow_Observe (Optional)

// LSSD architecture example

procedure master_observe =
timeplate tp1;
cycle =
// Force all clocks off
force scan_sclk 0;
force scan_mclk 0;
force rst 0;
force clk 0;
// Pulse the slave clock
pulse scan_sclk;
end;
end;

Shadow_Observe (Optional)
The optional shadow_observe procedure, which may only contain force and pulse event statements,
describes how to place the contents of a shadow into the output of its scan cell, assuming that data can
be transfered in this way in the scan cell. Once the data is at the scan cell output, you can observe it by
applying the unload command. This procedure enables the shadow to be used as an observation point in
the design.

Note:
This procedure is not supported when using SSN.

Figure 194 shows the data flow of the shadow_observe procedure.

Figure 194. Shadow_Observe Procedure

Tessent™ Shell User’s Manual 789

Test Procedure File
Skew_Load (Optional)

Skew_Load (Optional)
The optional skew_load procedure propagates the output value of the preceding scan cell into the master
memory element of the current cell without changing the slave, for all scan cells. Using only force and
pulse event statements, this procedure defines how to apply an additional pulse of the master shift clock
after the scan chains are loaded.
Figure 195 shows the data flow of the skew_load procedure.

Figure 195. Skew_Load Procedure

Figure 196 shows where you apply the skew_load procedure and the master_observe procedure within
the basic scan pattern events.

Figure 196. Skew_load applied within Pattern

790 Tessent™ Shell User’s Manual

 Test Procedure File
Clock_Control (Optional)

Clock_Control (Optional)
You can manually create clock control definitions in the test procedure file.
For complete information about when you use this definition, refer to "Support for Internal Clock Control"
in the Tessent Scan and ATPG User’s Manual.

ATPG Restrictions
The following restrictions apply to ATPG when clock control definitions are enabled:

• In undefined cycles, the internal clock is assumed to be off, even if the source clock pulses.

• Source clocks are pulsed regardless of clock restrictions. You should define explicitly any false
paths using DC or the add_false_paths command.

• External clocks without clock control definitions are controlled through top-level pins.

• Clock control definitions applied to a clock defined as equivalent also apply to all associated
equivalent clocks.

• Timeplate definitions apply only to external clocks.

• If you use the "set_clock_restriction -same_clocks_between_loads" command, you must use one
of the following definitions to pulse the controlled clock:

◦ {ATPG_SEQUENCE, END}

◦ {ATPG_SEQUENCE <N> <M>, END} with N starting from 0. The generated test pattern
includes M+1 capture cycles between the scan loading operation and the scan unloading
operation.

◦ {ATPG_CYCLE <i>, END} with i=0 defined

If none of these statements are present, the tool displays a warning during ATPG about clock
controls that cannot be applied because of clock restrictions.

Tessent™ Shell User’s Manual 791

Test Procedure File
Clock_Control (Optional)

Rules for Clock Control Definitions

The following rules apply to the clock control definitions in the test procedure file:

• Global control conditions and source clocks defined for equivalent clocks must be the same.

• When a clock is forced off, it cannot be used as a source in the same definition.

• A FORCE statement cannot force a clock pin to an on state.

• Clock control cannot be applied to an asynchronous free-running clock.

• Condition statements cannot be applied to non-scan state elements.

• You must specify a condition to turn on the internal clock; otherwise, it is assumed to be off.

• When multiple sequence clock control definitions are defined for the same clock, they must use
mutually exclusive pulse conditions as follows:

◦ The clock control condition to pulse a clock in sequence mode must be mutually exclusive
with the clock control condition for the same clock in per-cycle mode.

◦ The condition to pulse a clock in sequence mode must be mutually exclusive with the
condition to pulse the same clock by using another sequence mode.

Keywords
The following is a list of keywords used in clock control statement:

• ATPG_CYCLE cycle_number
A literal and integer pair that specifies a test pattern capture cycle to map the clock control to. The
specified capture cycle values start from 0, which corresponds to the first capture cycle after scan
loading.
Multiple ATPG_CYCLE definitions can be declared to pulse the internal clock at the same capture
cycle with different sets of conditions.
Use a FORCE statement to turn the clock off, or the clock continues to pulse when the conditions
are satisfied.
The specified and actual capture cycles may differ—refer to "Capture Cycle Determination" in the
Tessent Scan and ATPG User’s Manual.

• ATPG_SEQUENCE N M
A literal and an integer pair that specify a range of capture cycles for clock pulsing from N to M
consecutively.
Define the condition to pulse the clock continuously from capture cycle N (N>=0) to capture cycle
M (M>=N) right after scan loading. If N is greater than 0, the clock is automatically set to off state
from the first capture cycle right after scan loading to the capture cycle N -1. When the generated
test pattern includes more than M capture cycles after scan loading, the clock is set to off state
from the M +1 capture cycle to the last capture cycle.

792 Tessent™ Shell User’s Manual

 Test Procedure File
Clock_Control (Optional)

You can declare multiple ATPG_SEQUENCE definitions, as necessary.

Use a FORCE statement to turn the clock off, or the clock continues to pulse when the conditions
are satisfied.
The specified and actual capture cycles may differ—refer to "Capture Cycle Determination" in the
Tessent Scan and ATPG User’s Manual.

• ATPG_SEQUENCE
A literal that specifies clock pulsing. When a condition list is provided, the controlled clock pulses
in all capture cycles in the pattern when the conditions are met. When checking the off conditions
for cycles outside the capture window, the conditions listed in this special atpg_sequence are
ignored.
When there is no condition list, the controlled clock pulses unconditionally in every capture cycle
between scan loading.
You can declare multiple ATPG_SEQUENCE definitions, as necessary.
Use a FORCE statement to turn the clock off, or the clock continues to pulse when the conditions
are satisfied.
The specified and actual capture cycles may differ—refer to "Capture Cycle Determination" in the
Tessent Scan and ATPG User’s Manual.

• CLOCK_CONTROL pin_pathname
A literal and string value that specifies the pin pathname of the PI for the internal clock. The
specified pin must be an existing clock. You must define internal clocks using the add_clocks
command.

• CONDITION cell_name value

An optional literal and double string that specifies necessary scan cell states (conditions). The
scan cell is specified by the pin pathname associated with the output of its state element. The
value argument specifies the value loaded into the scan cell at the end of shift.
The specified and actual capture cycles may differ—refer to "Capture Cycle Determination" in the
Tessent Scan and ATPG User’s Manual.

• FORCE pin_pathname value

A literal and double string that forces a value of 0, 1, or Z on a specified pin. The specified pin
names must be valid pin pathnames for primary inputs. This keyword is used to force necessary
pins off during capture cycles when the controlled clock is pulsed.

• SOURCE_CLOCK pin_pathname...
A literal and repeatable string that specifies one or more source clocks to drive the internal clock
logic to pulse in the specified capture cycles. If no source clock is specified, the source clock is
assumed to be an always-capture clock that pulses in every capture cycle.

• FAST_CAPTURE_STAGGERED_GROUP group_number
A literal and integer pair that specifies the encoding of the fast capture staggered
group register. Group numbering starts at 0. CONDITION statements in each
FAST_CAPTURE_STAGGERED_GROUP wrapper define the fast capture staggered group
register value that assigns a source clock to that group. The ATPG tool determines this value

Tessent™ Shell User’s Manual 793

Test Procedure File
Clock_Control (Optional)
automatically based on which clocks to pulse together and which clocks to stagger in capture.
This value then loads into the fast capture staggered group register as a part of the scan chain
loading process, similar to other CONDITION registers. Refer to “Fast Capture Staggered Group
Example” on page 799 to see how these CONDITION statements might be written.
The tool performs the following checks for the definition:

If the following is true: The tool performs this check...

A clock control with a fast No source clock definition exists.

capture staggered group
register is defined OR
The source clock is a pulse_always/pulse_in_capture
clock.

A fast capture staggered group The tool is in "fast capture" mode.

register is defined
For more information about clock control operation
modes, refer to the section "Operating Modes" in the
Tessent Scan and ATPG User’s Manual.

The add_core_instances It is consistent with the OCC setting.

command has been performed

Note:
The tool treats any clock controls for which no fast capture staggered group register is
defined as though it is always in the first staggering group (0). You cannot pulse these
clocks in any other staggering group.

Group numbers are global across the design.

• END
Required literal the specifies the end of an ATPG_CYCLE or ATPG_SEQUENCE block, or at the
end of the clock control definition.

Global Condition Statements

Global conditions are CONDITION statements that are accessible in every scope of a clock control
definition. You can use global conditions to define default conditions within a clock control definition.
For example, you can specify a CONDITION statement for all ATPG_CYCLE/ATPG_SEQUENCE blocks
within a definition. Then you can define a CONDITION statement within individual ATPG_CYCLE/
ATPG_SEQUENCE blocks to override the global CONDITION variable when necessary.
The following example uses local conditions (italicized) to define some of the control bits necessary for
each scan cell to pulse the clock. The global conditions define other conditions that must be satisfied for
all clock cycles.

CLOCK_CONTROL /clk_ctrl/int_clk1 =
SOURCE_CLOCK ref_clk;
CONDITION /clk_ctrl/enable_1/q 0;
CONDITION /clk_ctrl/enable_2/q 0;
ATPG_CYCLE 0 =
CONDITION /clk_ctrl/F0/q 1;
END;

794 Tessent™ Shell User’s Manual

 Test Procedure File
Clock_Control (Optional)
ATPG_CYCLE 1 =
CONDITION /clk_ctrl/F1/q 1;
END;
ATPG_CYCLE 2 =
CONDITION /clk_ctrl/F2/q 1;
END;
ATPG_CYCLE 3 =
CONDITION /clk_ctrl/F3/q 1;
END
END;

The previous example is equivalent to the following:

CLOCK_CONTROL /clk_ctrl/int_clk1 =
SOURCE_CLOCK ref_clk;
ATPG_CYCLE 0 =
CONDITION /clk_ctrl/F0/q 1;
CONDITION /clk_ctrl/enable_1/q 0;
CONDITION /clk_ctrl/enable_2/q 0;
END;
ATPG_CYCLE 1 =
CONDITION /clk_ctrl/F1/q 1;
CONDITION /clk_ctrl/enable_1/q 0;
CONDITION /clk_ctrl/enable_2/q 0;
END;
ATPG_CYCLE 2 =
CONDITION /clk_ctrl/F2/q 1;
CONDITION /clk_ctrl/enable_1/q 0;
CONDITION /clk_ctrl/enable_2/q 0;
END;
ATPG_CYCLE 3 =
CONDITION /clk_ctrl/F3/q 1;
CONDITION /clk_ctrl/enable_1/q 0;
CONDITION /clk_ctrl/enable_2/q 0;
END
END;

The previous example demonstrates the importance of ensuring that global conditions do not conflict
with local conditions. To further illustrate this point, consider the following incorrect definition of global
conditions:

// Example of incorrect definition of global conditions

CLOCK_CONTROL /clk_ctrl/int_clk1 =
SOURCE_CLOCK ref_clk;
CONDITION /clk_ctrl/F0/q 0;
ATPG_CYCLE 0 =
CONDITION /clk_ctrl/F0/q 1;
END;
ATPG_CYCLE 1 =
CONDITION /clk_ctrl/F1/q 1;
END;
ATPG_CYCLE 2 =
CONDITION /clk_ctrl/F2/q 1;

Tessent™ Shell User’s Manual 795

Test Procedure File
Clock_Control (Optional)
END;
ATPG_CYCLE 3 =
CONDITION /clk_ctrl/F3/q 1;
END
END;

On the surface, it may appear correct that the condition in ATPG_CYCLE 0 overrides the global condition
while the other cycles can still be satisfied. However, after the global condition is expanded to all cycles,
the clock control definition looks like this:

// Example of incorrect definition of global conditions

CLOCK_CONTROL /clk_ctrl/int_clk1 =
SOURCE_CLOCK ref_clk;
ATPG_CYCLE 0 =
CONDITION /clk_ctrl/F0/q 1;
END;
ATPG_CYCLE 1 =
CONDITION /clk_ctrl/F1/q 1;
CONDITION /clk_ctrl/F0/q 0;
END;
ATPG_CYCLE 2 =
CONDITION /clk_ctrl/F2/q 1;
CONDITION /clk_ctrl/F0/q 0;
END;
ATPG_CYCLE 3 =
CONDITION /clk_ctrl/F3/q 1;
CONDITION /clk_ctrl/F0/q 0;
END
END;

You can now observe that it would not be possible to pulse the clock in ATPG_CYCLE 0 while also
pulsing it in any other cycle. The tool can load only one value into /clk_ctrl/F0, so it can either pulse the
clock in cycle 0 by loading a 1 or pulse it in another cycle by loading a 0.

Per-Cycle Clock Control Definition Example

The following example defines per-cycle clock control for two internal clocks (/top/core1/clk1 and /top/
core1/clk2):

CLOCK_CONTROL /top/core1/clk1 =
ATPG_CYCLE 0 =
CONDITION /pll_ctl/cell_0/Q 1;
END;
ATPG_CYCLE 1 =
CONDITION /pll_ctl/cell_1/Q 1;
CONDITION /pll_ctl/cell_4/Q 0;
//both conditions must be satisfied for clock to pulse in
//capture cycle 1
END;
END;
CLOCK_CONTROL /top/core1/clk2 =
ATPG_CYCLE 0 =
CONDITION /pll_ctl/cell_2/Q 1;

796 Tessent™ Shell User’s Manual

 Test Procedure File
Clock_Control (Optional)
END;
ATPG_CYCLE 1 =
CONDITION /pll_ctl/cell_3/Q 1;
CONDITION /pll_ctl/cell_5/Q 1;
END;
END;

Sequence Clock Control Definition Example

The following example defines sequence clock control for two internal clocks (/top/core/clk1 and /top/
core1/clk2) derived from the source clock clk_src:

CLOCK_CONTROL /top/core1/clk1 =
SOURCE_CLOCK clk_src;
ATPG_SEQUENCE 0 1 =
// Pulses 2 consecutive cycles if the scan cell
// is loaded with 1, and the source clock is pulsed.
CONDITION /pll_ctl/cell_1/Q 1;
END;
END;
CLOCK_CONTROL /top/core1/clk2 =
SOURCE_CLOCK clk_src;
ATPG_SEQUENCE 0 1=
CONDITION /pll_ctl/cell_2/Q 1;
END;
END;

The following example defines sequence clock control for two internal clocks (/top/core/clk1 and /top/
core1/clk2) derived from the source clock clk_src. The clock pulses in all capture cycles when the
conditions are met.

CLOCK_CONTROL /top/core1/clk1 =
SOURCE_CLOCK clk_src;
ATPG_SEQUENCE =
// Pulse clock in all capture cycles if the scan cell
// is loaded with 1, and the source clock is pulsed.
CONDITION /pll_ctl/cell_1/Q 1;
END;
END;
CLOCK_CONTROL /top/core1/clk2 =
SOURCE_CLOCK clk_src;
ATPG_SEQUENCE =
CONDITION /pll_ctl/cell_2/Q 1;
END;
END;

The following example pulses clock /top/core1/clk1 unconditionally in every capture cycle between scan
loading:

Tessent™ Shell User’s Manual 797

Test Procedure File
Clock_Control (Optional)

CLOCK_CONTROL /top/core1/clk1 =
ATPG_SEQUENCE =
// empty body
END;
END;

The following example defines a multi-sequence clock control definition:

CLOCK_CONTROL /top/core/clk1_int =
SOURCE_CLOCK /clk1;
ATPG_SEQUENCE 0 2 =
CONDITION /pll/ctl_1/Q 1;
FORCE ENABLE_1 1;
END;
ATPG_SEQUENCE 3 4 =
CONDITION /pll/ctl_1/Q 0;
FORCE ENABLE_1 1;
END;
END;

Exclusive conditions ensure that only one sequence block is applied per capture cycle (otherwise, no
sequence is applied). If no cycle numbers are specified for sequence clock control, the clock pulses in
every capture cycle when conditions are loaded.

Multiple Sets of Conditions for the Same Cycle Example

The following example shows that if a clock can be pulsed in a particular cycle or sequence of cycles
when there are multiple sets of conditions where any one set can activate the clock for that cycle, the
same cycle can be defined multiple times:

CLOCK_CONTROL /top/core1/clk1 =
ATPG_CYCLE 0 =
CONDITION /pll_ctl/cell_1/Q 1;
END;
ATPG_CYCLE 0 =
CONDITION /pll_ctl/cell_2/Q 1;
END;
END;

The previous example shows that /top/core1/clk1 can be pulsed in ATPG_CYCLE 0 when any set of the
specified conditions are met. This demonstrates the case where loading a '1' into either /pll_ctl/cell_1 or /
pll_ctl_cell_2 pulses the clock in cycle 0.
Similarly, the following example defines multiple sets of conditions for the same sequence of cycles,
which can overlap. The sequence of cycles must have mutually exclusive conditions to ensure conditions
for each ATPG_SEQUENCE can be satisfied without conflicting with other sequences.

CLOCK_CONTROL /top/core1/clk1 =
ATPG_SEQUENCE 0 2 =
CONDITION /pll_ctl/cell_1/Q 1;
CONDITION /pll_ctl/cell_2/Q 0;
CONDITION /pll_ctl/cell_3/Q 0;
END;

798 Tessent™ Shell User’s Manual

 Test Procedure File
Clock_Control (Optional)
ATPG_SEQUENCE 0 3 =
CONDITION /pll_ctl/cell_1/Q 0;
CONDITION /pll_ctl/cell_2/Q 1;
CONDITION /pll_ctl/cell_3/Q 0;
END;
ATPG_SEQUENCE 1 4 =
CONDITION /pll_ctl/cell_1/Q 0;
CONDITION /pll_ctl/cell_2/Q 0;
CONDITION /pll_ctl/cell_3/Q 1;
END;
END;

Source Clocks with Different Frequencies Example

The following example defines source clocks that have different frequencies when using clock control
definitions:

timeplate _default_WFT_ =
force_pi 0 ;
measure_po 40 ;
pulse clk1 45 10;
pulse ref_clock 15 5, 40 5, 65 5, 90 5;
pulse clocks_02/my_controller/U2/Z 45 10;
pulse clocks_03/my_controller/U2/Z 45 10;
pulse clocks_04/my_controller/U2/Z 45 10;
period 100 ;
end;

procedure capture =
timeplate _default_WFT_;
cycle =
force_pi ;
measure_po ;
pulse_capture_clock ;
end;
end;

In this example, for one pulse of clk1, there are 4 pulses of ref_clock, specifically the ref_clock frequency
is 4 times the frequency of clk1.

Fast Capture Staggered Group Example

The following example uses the FAST_CAPTURE_STAGGERED_GROUP keyword to define four groups
(highlighted in green) each for two clocks, fast_clk1 and fast_clk2. This corresponds to the example
waveform shown in section "Fast Capture Clock Staggering" in the Tessent Scan and ATPG User’s
Manual.

CLOCK_CONTROL /clk_ctrl/fast_clk1_gated =
SOURCE_CLOCK fast_clk1;
FAST_CAPTURE_STAGGERED_GROUP 0 =
CONDITION /clk1_occ_inst/occ_control/fast_capture_staggered_group_reg[0] 0;
CONDITION /clk1_occ_inst/occ_control/fast_capture_staggered_group_reg[1] 0;
END;

Tessent™ Shell User’s Manual 799

Test Procedure File
Clock_Control (Optional)
FAST_CAPTURE_STAGGERED_GROUP 1 =
CONDITION /clk1_occ_inst/occ_control/fast_capture_staggered_group_reg[0] 1;
CONDITION /clk1_occ_inst/occ_control/fast_capture_staggered_group_reg[1] 0;
END;
FAST_CAPTURE_STAGGERED_GROUP 2 =
CONDITION /clk1_occ_inst/occ_control/fast_capture_staggered_group_reg[0] 0;
CONDITION /clk1_occ_inst/occ_control/fast_capture_staggered_group_reg[1] 1;
END;
FAST_CAPTURE_STAGGERED_GROUP 3 =
CONDITION /clk1_occ_inst/occ_control/fast_capture_staggered_group_reg[0] 1;
CONDITION /clk1_occ_inst/occ_control/fast_capture_staggered_group_reg[1] 1;
END;
ATPG_CYCLE 0 =
CONDITION /clk1_occ_inst/occ_control/ShiftReg/FF_reg[0]/q 1;
END;
ATPG_CYCLE 1 =
CONDITION /clk1_occ_inst/occ_control/ShiftReg/FF_reg[1]/q 1;
END;
END;

CLOCK_CONTROL /clk_ctrl/fast_clk2_gated =
SOURCE_CLOCK fast_clk2;
FAST_CAPTURE_STAGGERED_GROUP 0 =
CONDITION /clk2_occ_inst/occ_control/fast_capture_staggered_group_reg[0] 0;
CONDITION /clk2_occ_inst/occ_control/fast_capture_staggered_group_reg[1] 0;
END;
FAST_CAPTURE_STAGGERED_GROUP 1 =
CONDITION /clk2_occ_inst/occ_control/fast_capture_staggered_group_reg[0] 1;
CONDITION /clk2_occ_inst/occ_control/fast_capture_staggered_group_reg[1] 0;
END;
FAST_CAPTURE_STAGGERED_GROUP 2 =
CONDITION /clk2_occ_inst/occ_control/fast_capture_staggered_group_reg[0] 0;
CONDITION /clk2_occ_inst/occ_control/fast_capture_staggered_group_reg[1] 1;
END;
FAST_CAPTURE_STAGGERED_GROUP 3 =
CONDITION /clk2_occ_inst/occ_control/fast_capture_staggered_group_reg[0] 1;
CONDITION /clk2_occ_inst/occ_control/fast_capture_staggered_group_reg[1] 1;
END;
ATPG_CYCLE 0 =
CONDITION /clk2_occ_inst/occ_control/ShiftReg/FF_reg[0]/q 1;
END;
ATPG_CYCLE 1 =
CONDITION /clk2_occ_inst/occ_control/ShiftReg/FF_reg[1]/q 1;
END;
END;

In the preceding example, to assign the clock "fast_clk1" to group 0, ATPG must set both
fast_capture_staggered_group_reg[0] and fast_capture_staggered_group_reg[1] to 0.
To assign it to group 1, ATPG must set fast_capture_staggered_group_reg[0] to 1 and
fast_capture_staggered_group_reg[1] to 0, and so on.

800 Tessent™ Shell User’s Manual

 Test Procedure File
clock_run (Optional)

clock_run (Optional)
For every controller, or concurrent controller group, you can write a clock_run procedure, if needed. The
clock_run procedure has both an internal mode as well as an external mode.
You can specify only one clock_run procedure per controller or concurrent group; however, you do not
need to specify a separate procedure for each controller instance. The same procedure can be used for
multiple controllers. You need to specify a separate procedure for a controller instance only if it maps to a
different set of internal clocks.
In case of controllers running concurrently, and some of these controllers clocks are driven by PLL
internal clocks, the clock_run procedure is required per concurrent group. It is not required for every BIST
controller participating in the group to have its clock driven by a PLL internal clock. For some controllers,
their clocks can be driven by a PLL reference clock or even by a system clock.
The tool relies on you to control the PLL control signal. This can be achieved by forcing the PLL control
signal to a proper value in a test_setup procedure and in external mode of clock_run procedure as well (it
depends on the PLL model behavior).
A clock_run procedure has to have a N-to-1 or 1-to-N ratio between internal and external cycles; that is,
either the internal mode has to have only one cycle, or the external mode has to have only one cycle. You
cannot have, for example, two external cycles and three internal cycles.

Tessent™ Shell User’s Manual 801

Test Procedure File
Capture Procedures (Optional)

Capture Procedures (Optional)

There are three types of capture procedures. These procedures are optional in the "patterns ‑scan"
context.

• The default capture procedure is an optional capture procedure, without a name, that provides
information on how the series of capture events are broken into cycles and which timeplates
these cycles use. The default capture procedure is defined in the procfile as part of the scan
group definition or internally derived by the tool when you do not define one.

• The named capture procedure is an optional capture procedure with a name that defines explicit
clock cycles. You can create multiple named capture procedures, each with a unique name, using
the create_capture_procedures command. If you need to manually create or edit named capture
procedures, refer to "Rules for Creating and Editing Named Capture Procedures" in this chapter.
For information on using named capture procedures to create at-speed test patterns, refer to "At-
Speed Test With Named Capture Procedures" in the Tessent Scan and ATPG User’s Manual.

• The external_capture procedure is an optional capture procedure used for all capture cycles
between each scan load, even when the pattern is a multiple load pattern. External_capture
procedures are used by the "set_external_capture_options ‑capture_procedure" command.
External_capture procedures that are used with this command have several restrictions:

◦ The procedure can only have one force_pi statement and no measure_po statements. This is
because to use the "set_external_capture_options ‑capture_procedure" switch, the patterns
to be saved must be hold_pi and mask_po patterns. The statements in the capture procedure
must match up to this.

◦ Unlike named capture procedures, the external_capture procedure cannot have

any load_cycles as it is meant to be used between each scan load of a pattern. The
external_capture cannot contain any events on internal signals.

◦ When using the -capture_procedure switch with set_external_capture_options, all clocks

in the design that are internally connected (do not trace to just a cut point), must be
controlled. In addition, the clocks must either be constrained, always-capture, controlled by a
clock_control definition, or the clock must have an event in the external_capture procedure.

Rules for Creating and Editing a Default Capture Procedure

Rules for Creating and Editing Named Capture Procedures
Slow and Load Types in the Cycle Statement
launch_capture_pair Statement

Rules for Creating and Editing a Default Capture

Procedure
There are several issues to consider when working with default capture procedures.

• The default procedure may only contain force_pi, measure_po, pulse_capture_clock, bidir_force,
bidi_force_pi, bidi_force_off, and bidi_measure_po event statements that represent the non-scan
activity for a normal pattern. There is no overlap between the capture procedure and the existing
clock procedure.

802 Tessent™ Shell User’s Manual

 Test Procedure File
Rules for Creating and Editing Named Capture Procedures

• Use the pulse_capture_clock statement in the default capture procedure to indicate in which cycle
one or more capture clocks should be pulsed.

• Do not specify any complex clocking that needs to be described for capture clocks or other clocks
in the default capture procedure; specify it in the clock procedure or by using a named capture
procedure.

• Do not specify any type of pin or ATPG constraint in the default capture procedure. For example,
specifying that a certain pin is to be held at a certain state in the default capture procedure does
not restrict the ATPG engine from applying different values to that pin. However, you can use the
bidi_force and bidi_force_pi statements in the default capture procedure to force all bidirectional
pins off in one cycle and force the ATPG values on the bidirectional pins in the next cycle.

Rules for Creating and Editing Named Capture

Procedures
There are several issues to consider when working with named capture procedures.

• A named capture procedure may only contain force_pi, measure_po, observe_method, pulse
(named clock), and condition statements.

• If you use mode definitions, all cycles in a procedure must be defined within mode definitions.
Use the keyword "mode" with two mode blocks: "internal" and "external". Use the mode_internal
definition to describe what happens on the internal side of the on-chip PLL. Use the
mode_external definition to describe what happens on the external side of the on-chip PLL.

• All events in a named capture procedure that use modes must be duplicated in both modes. The
only difference is that the internal mode uses only internal clocks and the external mode uses
only external clocks. The number of cycles and timeplates used can be different as long as the
total period of both modes is the same.

• Signal events used in both internal and external modes must happen at the same time. Examples
of these events are force_pi, measure_po, and other signal forces, but also include clocks that
can be used in both modes.

◦ If a measure_po statement is used, it can only appear in the last cycle of the internal mode
and must occur before the last clock pulse. If no measure_po statement is used, the tool
issues a warning that the primary outputs cannot be observed.

◦ The cumulative time from the start of the first cycle to the measure_po must be the same in
both modes.

◦ The external mode cannot pulse any internal clocks or force any internal control signals.

◦ A force_pi statement needs to appear in the first cycle of both modes and occur before the
first pulse of a clock.

◦ If an external clock goes to the PLL and to other internal circuitry, a C2 DRC violation is
issued.

Tessent™ Shell User’s Manual 803

Test Procedure File
Rules for Creating and Editing Named Capture Procedures

◦ At-speed cycles need to be continuous; that is, a named capture procedure cannot have
more than one at-speed clocking subsequence.

◦ All defined real clocks (excluding internal clocks) must be forced to off state first in the
mode_internal definition.
For more information, refer to "Internal and External Modes Definition" in the Tessent Scan and
ATPG User’s Manual.

• Do not use the pulse_capture_clock statement in a named capture procedure. The clocks used
are explicitly pulsed.

• If you want to specify the internal conditions that need to be met at certain scan cells in order to
enable a clock sequence, use the condition statement before the cycle statement in the named
capture procedure, as shown in the following example:

procedure capture capture1 =

scan_group groupcnt ;
timeplate gen_tp1 ;
condition /inst_0/clkenhold/reg_sco/Q 1;
condition /inst_1/clkenhold/reg_sco/Q 1;
condition /inst_2/clkenhold/reg_sco/Q 1;
condition /inst_3/clkenhold/reg_sco/Q 1;
condition /inst_4/clkenhold/reg_sco/Q 1;
condition /inst_5/clkenhold/reg_sco/Q 0;
condition /inst_6/clkenhold/reg_sco/Q 0;
condition /inst_7/clkenhold/reg_sco/Q 0;
condition /inst_8/clkenhold/reg_sco/Q 0;
condition /inst_9/clkenhold/reg_sco/Q 0;
cycle =
force clear 0 ;
force clock[0] 0 ;
force clock[1] 0 ;
force clock[2] 0 ;
force clock[3] 0 ;
force clock[4] 0 ;
force clock[5] 0 ;
force clock[6] 0 ;
force clock[7] 0 ;
force clock[8] 0 ;
force clock[9] 0 ;
force test_clk 0 ;
force_pi ;
measure_po ;
pulse clock[0] ;
pulse clock[1] ;
pulse clock[2] ;
pulse clock[3] ;
pulse clock[4] ;
end;
end; // capture1

804 Tessent™ Shell User’s Manual

 Test Procedure File
Slow and Load Types in the Cycle Statement

• If you want to define a specific observe method for each named capture procedure, use the
observe_method statement in the named capture procedure; otherwise, the ATPG engine
automatically selects master, slave, or shadow observation.

Note:
The write_patterns command enables you to save internal or external clock patterns.
Internal clock patterns can be used to simulate the DUT without having the PLL modeled,
while the external patterns only exercise the PLL external clocks and control signals.
Internal patterns are the default for ASCII and binary formats, and external patterns are the
default for tester formats.

• If you generate patterns using a named capture procedure that has both internal and external
modes and you save them in STIL or WGL format, you must use the write_patterns command’s
internal option to read them back into the tool (for example, to use in diagnosis). For more
information and for information about special considerations that apply to LBIST mode in
the TK/LBIST Hybrid flow, refer to the ‑Mode_internal and ‑Mode_external switches for the
write_patterns command in the Tessent Shell Reference Manual.
DRC rules W20 through W36 check named capture procedures. If a DRC error prevents use of a capture
procedure, the run halts.

Slow and Load Types in the Cycle Statement

Optionally, you can add a "slow" or a "load" type to the cycle definition.
For example:

cycle slow =
...
end;

• The slow cycle indicates that at-speed faults cannot be launched or captured. The tool must know
which at-speed cycles are slow to get accurate at-speed fault coverage simulation numbers;
therefore, be sure to include "slow" when defining cycles that are not at-speed cycles in an at-
speed capture procedure.

Note:
At-speed cycles need to be continuous; that is, a named capture procedure cannot have
more than one at-speed clocking subsequence.

• The load cycle indicates that the cycle is always preceded by an extra scan load. The first cycle
in a named capture procedure is always a load (with or without the load type designation), so
you typically apply "load" to subsequent cycles. An at-speed launch cycle can be a load cycle;

Tessent™ Shell User’s Manual 805

Test Procedure File
launch_capture_pair Statement
however, none of the cycles that follow in the at-speed sequence, up to and including the capture
cycle, can be load cycles.

Note:
To get extra loads, you must enable the tool’s multiple load and clock sequential
capabilities by using the set_pattern_type command with "‑multiple load on" and
"‑sequential <2 or greater>". For more information, refer to "Multiple Load Patterns" in the
Tessent Scan and ATPG User’s Manual.

The following example illustrates the "slow" and "load" attributes:

procedure capture multiple_load_example =

timeplate tp1;
// first cycle is always a load, with or without load type designation
cycle slow =
force_pi;
force wr_enable 1;
pulse int_clk1;
end;
cycle slow load =
pulse int_clk1;
end;
cycle =
force re_enable 1;
pulse int_clk1; // launch clock
end;
cycle =
pulse int_clk1; // capture clock
end;
end; // end of capture procedure

launch_capture_pair Statement
Optionally, you can add one or more "launch_capture_pair" statements to the beginning of a named
capture procedure. This statement defines legal at-speed launch and capture points in non-adjacent
cycles. If you do not use the launch_capture_pair statement, the tool launches and captures only in
adjacent cycles. If at least one launch and capture clock pair is defined, the launch and capture points are
derived from the defined launch and capture clock pairs.

Note:
This statement is only supported when using a named capture procedure to perform test
generation.

The syntax of the launch_capture_pair statement is as follows:

launch_capture_pair <launch_clock_pin_name> <capture_clock_pin_name>;

Where:

806 Tessent™ Shell User’s Manual

 Test Procedure File
Clock_sequential (Optional)

• launch_clock_pin_name is the clock used to launch the transition.

• capture_clock_pin_name is the clock used to capture the transition.

The launch clock cycle is used to check the transition condition. The capture clock cycle is used to
capture the transition fault effect. The cycles between the launch clock and capture clock must be at-
speed cycles. They cannot include any slow cycles between them. The faults to be tested by the named
capture procedure with the defined launch and capture clock pair are the faults that can be launched by
the launch clock and captured by the capture clock defined in the launch_capture_pair statement.
The following is an example of the launch_capture_pair statement:

procedure capture c1_c1 =

launch_capture_pair c1 c1;

cycle = // cycle 1
force_pi;
force c1 0;
force c2 0;
force c3 0;
pulse c1;
end;

cycle = // cycle 2
pulse c2;
end;

cycle = // cycle 3
pulse c1;
pulse c3;
end;
end; // end of capture procedure

In this example, a valid launch can happen in cycle 1. A valid capture can happen in cycle 3 only with
c1 as the capture clock. A launch in cycle 1 and a capture in cycle 2 is not used for fault detection. The
faults to be tested by this named capture procedure are the faults that can be launched and captured by
clock c1.

Clock_sequential (Optional)
The clock_sequential procedure (optional for "patterns -scan" context), which may only contain force_pi,
pulse_write_clock, pulse_read_clock, pulse_capture_clock, bidi_force_pi, and bidi_force_off event
statements, represents the clock sequential events in a clock sequential pattern. Use this procedure with
the capture procedure.
The following shows the clock_sequential procedure pattern.

Tessent™ Shell User’s Manual 807

Test Procedure File
Init_force (Optional)

Figure 197 shows an entire clock sequential pattern, which illustrates where the clock_sequential and
capture procedures are used.

Figure 197. Full Clock Sequential Pattern

Init_force (Optional)
The init_force procedure (optional for "patterns -scan" context), which may only contain force_pi event
statements, represents the force cycle that is used in an ATPG pattern that targets a transition fault. The
transition must be launched off of the last scan chain shift. This procedure is used when the fault type is
set to transition fault and either the depth is set to 2 or less or the ATPG engine fails to find a sequential
pattern that can cover this transition fault. Use this procedure with the capture procedure.
The following illustrates the format of the init_force procedure pattern.

Figure 198 shows the pattern that uses the init_force procedure.

808 Tessent™ Shell User’s Manual

 Test Procedure File
Test_end (Optional, all ATPG tools)

Figure 198. Init_force Procedure Usage

Test_end (Optional, all ATPG tools)

The optional test_end procedure is used to add a sequence of events to the end of a test pattern set.
The test_end procedure may only contain force and pulse event statements (refer to the following
exception), and can only be defined once for all scan groups. When saving patterns, the test_end
procedure is applied to the end of each pattern set saved.
The following shows the general pattern for the test_end procedure pattern.

IJTAG Embedded Instruments

In the "patterns -scan" ATPG context, IJTAG is valid in the test_setup and test_end procedures only. It is
invalid in any other procedure, as well as in ATPG’s analysis mode. Also, only iReset and iCall commands
are valid in the test procedures.
For detailed information, refer to "How to Set Up Embedded Instruments Through Test Procedures" in the
Tessent IJTAG User’s Manual.

Example 1: Using test_end in a Procedure File

The following is a partial example of how the test_end procedure might be used in a procedure file:

timeplate tp1 =
force_pi 0;
measure_po 10;
pulse ref_clk 50 50;
period 100;
end;

procedure test_end =
timeplate tp1;
cycle =

Tessent™ Shell User’s Manual 809

Test Procedure File
Sub_procedure
force ctrl_a 1;
force tms 0;
pulse ref_clk;
end;
end;

Example 2: Test_end Procedure with Timeplate

The following is an example test_end procedure with its corresponding timeplate:

timeplate tp4 =
force_pi 0;
pulse TCK 10 10;
measure_po 30;
period 40;
end;

procedure test_end =
timeplate tp4;
cycle =
// TMS = 1, change to select-DR state
force TDI 1;
force TMS 1;
pulse TCK;
end;

cycle =
// TMS = 0, change to capture-DR state

…
cycle =
// Scan out signature (MISR has length of 4)
force TDI 1;
force TMS 0;
pulse TCK;
end;
cycle =
force TDI 1;
force TMS 0;
pulse TCK ;
end;
…
end;

Sub_procedure
The sub_procedure procedure eliminates the need to insert duplicate actions within a procedure. Once
you have defined a sub_procedure, you can specify this procedure within other procedures using the
apply statement.

810 Tessent™ Shell User’s Manual

 Test Procedure File
Sub_procedure

You can also set the tool to reissue the sub_procedure as many times as needed by specifying the
repeat_count. Because the repeat_count is required when using apply sub_procedure, you must enter a
minimum of 1 for this parameter.

Sub_procedure Looping
Sub_procedure looping is used to reduce the size of pattern files. The default behavior of the
sub_procedure is to use "loops" or "repeats" in all applicable pattern formats to repeat the contents of the
sub_procedure N times, where N is greater than 1.

Disabling Sub_procedure Looping

If you want the event data in a sub_procedure to be expanded and represented as N sets of vectors in
the pattern file, where N is the number of times the sub_procedure is applied, use the ALL_NO_LOOP 1
parameter file keyword to disable the use of loop or repeat statements.
For example, if the test_setup procedure has the following statement:

apply pulse_bclock 1000;

The vector data for the sub_procedure "pulse_bclock" would be expanded to be 1000 vectors. The default
for the ALL_NO_LOOP keyword is off (0).

Sub_procedure Definition Format

The sub_procedure definition has the following format.

procedure sub_procedure my_subprocedure =

timeplate tp1;
cycle =
force_pi;
measure_po;
end;
end;

Using the Sub_procedure in a Procedure

The following is an example of how to use the sub_procedure in a procedure.

procedure shift =
scan_group grp1;
timeplate tp1;
apply my_subprocedure 4;
cycle =
force_sci;
measure_sco;
pulse T;
end;
end;

Tessent™ Shell User’s Manual 811

Test Procedure File
Additional Support for Test Procedure Files

Note:
You must first define a sub_procedure before using it in a procedure. Next, you can apply a
sub_procedure within any procedure type. Also, you cannot use a sub_procedure within the
"cycle =" and "end;" statements.

Additional Support for Test Procedure Files

Tessent Shell provides additional support so that you can use environment variables, merge, and default
template capabilities with your test procedure files.

Tcl Variables Used for Substitution and Conditional Selection

The procfile can include Tcl variables to provide parameterized values within the procfile statements. The
Tcl variables must be set in the global Tcl namespace. If you are setting the variables within a proc, make
sure to use :: as a prefix to the variable name such that it is set in the global namespace. For example,
use "set ::my_period 4" such that $my_period exists when processing the proc files.
The Tcl variable can also be used to evaluate the condition of a Tcl "if" command located inside the
procfile. The element of a list of ports in the procfile must be separated by commas. If the port names are
escaped identifiers, they must be enclosed in quotation marks. Use the method shown in the following
example to convert a list of port names into a quoted comma-separated list needed in the proc file:
Command invoked in the dofile:

set ::add_clocks_timing 1
set ::edges "25 75"
set ::port_list [get_name_list [get_clocks -type sync_source]]
set ::all_clocks [string cat {"} [join $port_list {", "}] {"}]
set_procfile_name ./myproc

Given the content of the ./myproc is:

alias all_clocks = $all_clocks;

timeplate mytimeplate =
if {$add_clocks_timing} {
pulse all_clocks $edges;
}
end;

The report_procedures command displays the following:

alias all_clocks = "clk1", "clk2", clk3";

timeplate mytimeplate =
pulse all_clocks 25 75;
end;

Merging Procedure Files

It is possible to specify more than one procedure file for a design. You can specify a procedure file with
the add_scan_groups command or with the read_procfile command. You need to supply (to the ATPG

812 Tessent™ Shell User’s Manual

 Test Procedure File
Creating Test Procedure Files for End Measure Mode
tool) a minimum set of information in the procedure file with the add_scan_groups command. You must
supply all event information for the scan procedures.
However, after leaving setup mode, it is possible to specify non-scan procedures, timeplates, and new
timing for the scan procedures by reading in an additional procedure file with the read_procfile command.
Specifying new information for the same design, from more than one procedure file, is known as "merging
the procedure files." To properly merge the information from multiple procedure files, the Vector Interfaces
code follows these rules:

• All scan procedures that you use must be specified in the procedure file that you load with the
add_scan_groups command.

• If you load a procedure that contains nothing but the procedure name, a timeplate name, and an
optional scan group, it is a template procedure. If a procedure already exists by that name for that
scan group (if it is a group-specific procedure), then the timeplate is mapped onto the existing
procedure. If no procedure already exists with that name, the tool stores the template procedure
for future use.

• If you load a new complete procedure (not a template) and a procedure already exists by that
name for the specified scan group (if applicable), the new procedure overwrites the existing one.

• In both cases, when a procedure overwrites an existing one, or if a new timeplate is mapped to
an old procedure, the tool checks the procedures to make sure that the sequence of events in the
new procedure does not differ from the old procedure.

Default Information Provided by the Tool

When you issue the write_patterns command, the tool checks to make sure that all procedures and
timeplates needed to save the patterns in the specified format are present.
If there are any missing non-scan procedures, the tool creates default procedures and reports a warning.
For any procedures that are created or that do not have a timeplate specified, the default timeplate
is mapped to these procedures, if it is set. You can set the default timeplate by using the set
default_timeplate statement previously described in the Set Statement section. If you use this statement,
the timeplate specified when creating default procedures is used. If the default procedure needs to be
created and no default timeplate has been set, the first timeplate specified is used. If no timeplates are
specified, a default timeplate is created as well.

Creating Test Procedure Files for End Measure

Mode
You can create test procedure files that enable end measure mode. End measure mode refers to the
special handling that the Vector Interfaces code needs to move the measure to the end of the shift and
capture cycle.

Prerequisites
• A test procedure file.

Tessent™ Shell User’s Manual 813

Test Procedure File
Creating Test Procedure Files for End Measure Mode

Procedure
1. Create a new timeplate that measures the outputs after the clock pulse.

2. Change the timeplate for the shift and load_unload to point to the new timeplate.

3. Add the measure_sco statement to the load_unload procedure.

4. Make sure all shift procedures have the measure_sco statement after the shift clock. When end
measure mode is enabled, the measure_sco statement measures the next value from the output of
the scan chain. The very first value for the output of the scan chain is measured by a measure_sco
statement in the load_unload procedure.

5. Change the timeplate for the capture cycle by breaking it into two cycles. Move the capture clock to
the second cycle of the capture procedure to enable the measure at the end. In the first cycle, the
force_pi and measure_po are performed. In the second cycle, the capture clock is pulsed. When
using end measure mode, a measure cannot be performed after the capture clock.

Examples
set time scale 1.000000 ns ;
set strobe_window time 10 ;
timeplate gen_tp1 =
force_pi 0 ;
measure_po 10 ;
pulse clk 20 10;
pulse edt_clock 20 10;
pulse ramclk 20 10;
period 40 ;
end;
// CREATE A NEW TIMEPLATE THAT MEASURES AFTER THE CLOCK PULSE
timeplate gen_tp2 =
force_pi 0 ;
// measure_po 10 ;
pulse clk 20 10;
pulse edt_clock 20 10;
pulse ramclk 20 10;
measure_po 35 ; // <<== NEW MEASURE STATEMENT
period 40 ;
end;
// FOR CAPTURE SPLIT INTO TWO CYCLES
procedure capture =
timeplate gen_tp1 ;
cycle =
force_pi ;
measure_po ;
end ;
cycle =
pulse_capture_clock ;
end;
end;
// FOR THE SHIFT AND LOAD_UNLOAD, USE THE NEW TIMEPLATE
procedure shift =
scan_group grp1 ;

814 Tessent™ Shell User’s Manual

 Test Procedure File
Creating Test Procedure Files for End Measure Mode
timeplate gen_tp2 ; //<<=== NEW TIMEPLATE
cycle =
force_sci ;
force edt_update 0 ;
measure_sco ;
pulse clk ;
pulse edt_clock ;
end;
end;
// ADD A MEASURE_SCO TO THE LOAD_UNLOAD PROCEDURE
procedure load_unload =
scan_group grp1 ;
timeplate gen_tp2 ; //<<=== NEW TIMEPLATE
cycle =
force clk 0 ;
force edt_bypass 0 ;
force edt_clock 0 ;
force edt_update 1 ;
force ramclk 0 ;
force scan_en 1 ;
pulse edt_clock ;
measure_sco; //<<=== NEW MEASURE STATEMENT
end ;
apply shift 39;
end;
procedure test_setup =
timeplate gen_tp1 ;
cycle =
force edt_clock 0 ;
end;
end;

Tessent™ Shell User’s Manual 815

Test Procedure File
Serial Register Load and Unload for LogicBIST and ATPG

Serial Register Load and Unload for LogicBIST

and ATPG
You can use the test_setup or test_end test procedure file procedures to serially load or unload control
registers in the circuit under test. Additionally, this section discusses the commands you must add to your
dofile to use this functionality.
Serial register load and unload targets the following flows:

• LogicBIST — Used to serially unload certain registers (for example, MISRs) using the test_end
procedure.

• Low pin count test — Used to serially load registers with test information through a serial access
port such as a JTAG TAP controller.

Register Load and Unload Use Models

Static Versus Dynamic Register Variables
Test Procedure File Modifications
Dofile Modifications
Serial Load and Unload DRC Rules

Register Load and Unload Use Models

Using serial register load and unload enables you to identify a load/unload register variable value in the
test procedure file and define this variable, either static or dynamic, using commands in your Tessent
dofile. By using this functionality, you can load control registers by using a type of load procedure where
the data value for the register can be passed as a string of values, and the load register uses a shift
mechanism to show how this string of data values is shifted into the register.
To serially load/unload register value variables, you must make modifications to your test procedure file
and your Tessent dofile.
The register value variable is used in the test procedure file to load the value into a register through the
data input pin, or unload a value from a register through the data output pin. The load/unload procedures
support pin inversions, but you must explicitly specify this.
The registers to be loaded/unloaded can be cascaded such that one load or unload operation loads or
unloads multiple values, for example PRPG/MISR values.

Static Versus Dynamic Register Variables

You can define both static and dynamic register value variables.

• Static variable — A specific register value variable string you specify during setup mode. Once
set, you cannot change this variable.

• Dynamic variable — A register value variable string that you can define or change later, and can
use tool-specific switches.

816 Tessent™ Shell User’s Manual

 Test Procedure File
Test Procedure File Modifications

Static Variable
A static register variable is one where the value is assigned to the variable when the variable is defined
(using the add_register_value), and this value then cannot be changed. This static value is used by DRC
when simulating the procedures. A static variable cannot be set using tool specific switches to link the
variable to tool computed values, as these may change.

Dynamic Variable
A dynamic register value variable uses tool-specific switches and arguments to link the variable to a value
computed by the tool. If you use a dynamic variable, then you must specify the register’s width unless the
tool knows this value at the time DRC is run (for example, PRPG size).
This method is used for defining a variable that has a tool-specific computed value that is available
when patterns are saved and needs to be loaded or unloaded by the test_setup or test_end procedures.
The value defaults to all X bits, and you can specify the actual value in non-Setup mode by using the
set_register_value command.
If no value is specified the first time DRC is invoked after adding a register value variable, the tool
considers the variable to be dynamic for DRC and any future invocation of DRC.

Test Procedure File Modifications

In the test procedure file, the load_unload_registers Procedure and shift Keyword are used.

load_unload_registers Procedure
The load_unload_registers procedure is a named procedure; consequently, you can have multiple
occurrences of this procedure, corresponding to multiple groups of registers that need to be loaded or
unloaded. The load_unload_registers procedure can only be called from the following procedures:

• test_setup

• test_end
The load_unload_registers procedure can load, unload, or both. Additionally, one application of the
procedure can load/unload multiple cascaded registers.
When the test procedure file explicitly calls the load_unload_registers procedure from either the
test_setup or test_end procedures, the values to load or unload are passed to the procedure using the
string of binary values (value hard-coded in the procedure application) or the register value variables.

shift Keyword
The load_unload_registers procedure uses the shift keyword to define a block of events that result in
one shift operation. This is similar to the IEEE STIL syntax where the shift keyword defines a shift block
within a load or unload procedure. It is analogous to embedding the shift procedure into the load_unload
procedure.

Apply Statement Extension

The apply statement in the procedure file syntax is extended to accept a statement that associates a set
of string values or register value variables with a particular input pin, output pin, or alias. This pin or alias
must then be used within the shift statement and have a "#" character associated with it. This character is

Tessent™ Shell User’s Manual 817

Test Procedure File
Test Procedure File Modifications
a placeholder for the values that is loaded or unloaded using the string of values passed to the procedure,
or the internally generated values associated with the value name.

Test Procedure File Syntax

The following illustrates using the load_unload_registers procedure and shift keyword:

procedure load_unload_registers procedure_name =

…
[ cycle blocks ]
shift =
cycle blocks
end ;
[ cycle blocks ]
end ;

The load_unload_registers procedure must have a shift block defined, which has one or more cycles
used to shift the data into the data input pin or the data out of the data output pin. The procedure can also
optionally have cycles that precede or follow the shift block, to be used to put the circuit into shift mode or
finish the shift mode when done, similar to how a load_unload procedure is used.

Event Statements
Within a shift block, at least one event statements in a load_unload_registers procedure must use the "#"
character to denote where the shift data passed into the procedure is used.
The event statement must be either a "force" event or an "expect" event. An event statement with the "#"
character can also occur in the cycles preceding or following the "shift" block to express pre-shifts and
post-shifts for loading the register. This event statement has the following syntax:

<force | expect > pin_or_alias_name # ;

The apply statement used to call the sub_procedure also calls the shift and load_unload_registers
procedures. However, when calling the shift and load_unload_registers procedures, the #times argument
in the apply statement is replaced with one or more value assignments for the data in or data out pins.

apply procedure_name [ #times | shift_data_assignment

[ , shift_data_assignment …] ] ;

A shift_data_assignment has the following syntax:

identifier = < value_string | register_value_variable >

[<value_string | register_value_variable>…]

where identifier is either a pin name or an alias name.

The identifier used in the shift_data_assignment must match an identifier used within the procedure in
one of the event statements with the "#" character.

Register Value Strings

A register value string (value_string) is one of the following:

818 Tessent™ Shell User’s Manual

 Test Procedure File
Dofile Modifications

• A binary string of 0s, 1s, or Xs, where the length of the string determines the number of shifts to
load the register.

• A string of a different radix as long as the Verilog syntax of identifying the radix and width are
used, such as "32'h" for a 32 bit hexadecimal value.
If a register_value_variable is used in the shift_data_assignment, then a value computed by the tool for
that register_value_variable (as bound within the dofile) or hard-coded in the dofile is loaded or unloaded
at that time and the shift length is also provided by the tool. It is possible for more than one value_string
or register_value_variable to be assigned to an identifier in one shift_data_assignment. In this case, the
extra values are separated by spaces. This enables multiple shorter values to be shifted into one register
group.
The typical usage is that each register_value_variable corresponds to one register being loaded, and the
specification of multiple variables is used when those registers are cascaded and loaded/unload on after
another.

Alias Names
It is possible to use an alias name in the procedure type for loading shift data, even if that alias name
refers to multiple pins. If this is the case, the number of bits assigned by the "#" character for each shift is
equal to the width of the alias being used. The length of the value string being passed to the procedure
must be a multiple of the width of the alias.
Loading or unloading an alias can be used if performing parallel load/unload and no shift is required. For
example, if each MISR bit is connected to a separate primary output. Even if no shifting is required, the
functionality is still useful to bind the expected values to the signature computed by the tool.
If multiple shift_data_assignments are passed to a procedure, then all of them must have the same shift
length such that each pin being loaded/unloaded requires the same number of cycles to load/unload all
the data. No padding is performed by the tool.
If a "measure" event is used in one of these procedures to unload a register, then these measure values
can be compared in the final patterns and the Verilog testbench.

Dofile Modifications
You define register value variables using commands you issue to the tool interactively or in a dofile. The
value variables are subsequently referenced in the procedure file.
You use the following commands to perform these operations:

• add_register_value

• set_register_value

• delete_register_value

• report_register_value

Addition of a Register Value Variable

The add_register_value command defines the register value variables. You can define the variables as
either static value variables or dynamic value variables.

Tessent™ Shell User’s Manual 819

Test Procedure File
Dofile Modifications

You can only use this command in setup mode. You must define the register value variables in the dofile
before the variables are used in a test procedure file to load values into the registers.

Static Value Variables

You specify a static value variable by stating a specific value string. This value variable then has this
value string as a constant value.
You must specify this value in setup mode; the value is considered to be static by default, and the value is
present when simulating procedures in DRC.

add_register_value value_name {value_string [-Radix {Binary | Decimal |

Octal | hexadecimal} -Width integer]} optional_arguments

The value_name is a user-specified identifier, and the value_string is a state string in a particular radix.
The default is binary radix.
If you use the –Radix switch to change this to a different radix, you must also specify a register width
using the –Width switch.

Dynamic Value Variables

You specify a dynamic value variable using the following variation of the command:

add_register_value value_name value_string -Dynamic -Width integer

optional_arguments

The value_string is optional and defaults to all X bits if not specified.

You can subsequently enter the actual value once you have exited setup mode using the
set_register_value command. If no value is specified the first time DRC is invoked after adding a register
value variable, it is considered as dynamic in this and any future invocation of DRC.

Data Pin Inversions

When using either a static or dynamic variable, you can optionally specify inversions on the input and
output data pins by using the -INput_pin_inversion and -OUtput_pin_inversion switches, respectively.
These are optional switches you use to specify that the data value in this variable should be inverted
before it is loaded into the register through the load_unload_register procedure.

Definition of a Dynamic Register Value Variable

You can define a dynamic register value variable by using tool-specific switches and arguments to link the
variable to a value computed by the tool. These variables are dynamic, and the width must be specified
unless the width is known to the tool at the time DRC is run.
This method is used for defining a variable that has a tool-specific computed value that is available when
patterns are saved and needs to be loaded or unloaded by the test_setup or test_end procedures.
In this case, you use the add_register_value command with the -Width switch and omit the value while in
setup mode. Once you have exited setup mode, you can use the set_register_value command to set the
variable:

set_register_value value_name value_string [-RAdix {BInary | HEx | OCtal |

Decimal}]

820 Tessent™ Shell User’s Manual

 Test Procedure File
Dofile Modifications

The name of the register value and its width are known prior to parsing the procedure file and running
DRCs. The value is all X bits for DRC.
This command can only be used for a register value that was defined without a value string, and the width
of the value string must match the width specified in the add_register_value command.
If the value overflows the width specified, an error is issued.
By default, the bits extracted by force/measure "#" in the procedure are from MSB to LSB. If the value
specified should be shifted in/out in the opposite order, with the LSB bits applied/measured first, use the "-
LSB_shifted_first" optional switch.

Deletion of a Register Value Variable

The delete_register_value command deletes all or a specified register value variable. You can only use
this command in setup mode.

Register Value Variable Reports

The report_register_value command provides a detailed report of the register value variables to stdout or,
optionally, a file.

Tessent™ Shell User’s Manual 821

Test Procedure File
Serial Load and Unload DRC Rules

Serial Load and Unload DRC Rules

The P13 and P54, P66, and W5 DRC rules are applied to the procedures and syntax in the section
"Procedure Examples."
The P1 "syntax error" message is used to catch many potential issues, such as specifying a "#times"
value for applying a load_unload_registers procedure instead of the shift_data_assignment.

P13 and P54

P66
W5
Procedure Examples

P13 and P54

The P13 and P54 rules are used to check the shift assignment statements when calling a
load_unload_registers procedure.
If the shift assignment uses a value string that is not properly formatted or contains illegal characters for
that radix, then a P13 is issued.

Error: Invalid state value state string. (P13)

If the shift assignment references an undefined register value variable name, a P54 is issued.

Error: Undefined identifier identifier_string referenced by signal_name.

(P54)

P66
The P66 rule is used to check for missing statements within a load_unload_registers procedure.
For example, if no Shift block is specified, or if an event statement using the "#’ character is not present
for each shift_assignment passed to the load_unload_registers procedure, the tool reports a P66
violation.

Error: Procedure procedure_name is missing required statement_string

statement. (P66)

The following examples show the types of P66 DRC errors you could encounter.

Example 1
In the following example, the tool reports this error if there is no shift block within the load_unload
registers procedure:

Error: Procedure procedure_name is missing required shift statement. (P66)

822 Tessent™ Shell User’s Manual

 Test Procedure File
W5

Example 2
In the following example, the tool reports this error if there are no events in the load_unload_register
procedure that use the "#’ substitute character.

Error: Procedure procedure_name is missing required substitute event

statement. (P66)

Example 3
In the following example, the tool reports this error if an apply statement that uses a
load_unload_registers procedure has a shift data assignment that uses a signal that does not appear in
the load_unload_registers procedure with the substitute character "#’.

Error: Procedure procedure_name is missing event using shift

assign signal_name statement. (P66)

W5
The W5 DRC error is used to flag any extra events or statements in a load_unload_registers procedure,
or any events that are not legal.
For example, if an event type other than Force or Expect is used with the "#" substitute character, the tool
reports a W05 rule violation. If the load_unload_registers procedure contains more than one shift block,
this rule is reported. If there is a Force or Expect statement using a "#" character for a signal name that is
not being passed to the procedure as a shift assignment, this rule is reported. The W05 rule is used when
shift assignments for a particular Apply statement do not all have the same length.

Error: Procedure procedure_name has an illegal event statement or event

order (event_statement_string) (W5)

Example 1
The following error is reported if an event in the load_unload_register procedure uses the "#" substitute
character, but no shift data for this signal is passed into the procedure when it is called "extra shift block":

<force | measure> signal_name # without matching shift assign data

Example 2
The following error is reported if there is more than one shift block in the load_unload_registers
procedure.

"extra shift block"

Example 3
The following error is reported if more than one event of the same type in the shift block uses the same
signal name with the "#’ substitute character.

Tessent™ Shell User’s Manual 823

Test Procedure File
Procedure Examples

"too many events using shift assign signal_name"

Example 4
The following error is reported for an apply statement that uses a load_unload_registers procedure but
has no shift data assignments in the apply statement.

"apply with no shift data assignment"

Example 5
The following error is reported for an apply statement that uses a load_unload_registers procedure and
has more than one shift assignment, however, the target of the shift assignments are aliases and they are
not the same width.

"unmatched shift assign signal width"

Example 6
This is reported for an apply statement that uses a load_unload_registers procedure and has more than
one shift assignment and the assignments have different shift lengths.

"unmatched shift lengths"

Procedure Examples
This topic provides examples of the definition of the load_unload_registers procedure. Notice how this
procedure uses the "shift =" statement and the "force tdi #" statement to denote the shifting and where the
string of data is applied, one bit at a time.

procedure load_unload_registers load_prpg1 =

timeplate tp1 ;
cycle =
force prpg_select 1 ;
… // setup tap controller to load prpg
end;
shift =
cycle =
force tdi # ;
pulse tck ;
end;
end;
end;

This procedure could then be applied in the test_setup procedure to initialize the PRPG, specifying the
string of bits to apply to "tdi" during shifting.

824 Tessent™ Shell User’s Manual

 Test Procedure File
Procedure Examples

procedure test_setup =
timeplate tp1 ;
cycle =
force clk1 0 ;
force clk2 1 ;
force tck 0 ;
…
end;
apply load_prpg1 tdi = 000000000000000000000001 ;
cycle =
…
end;
end;

For loading a register with the shift length during test_setup, using the values computed by the tool, the
procedure definition looks the same, but how the procedure is called is slightly different. The following
example both loads and unloads the register, as this same procedure could be used in a test_end
procedure to unload the shift length value. The dofile for this example contains the following command:
add_register_value length_val -shift_length -width 16

The procedure file contains the following:

procedure load_unload_registers load_unload_length =

timeplate tp1 ;
cycle =
force clk1 0 ;
…
end;
shift =
cycle =
force tdi # ;
expect tdo # ;
pulse tck ;
end;
end;
end;
procedure test_setup =
timeplate tp1 ;
cycle =
…
end;
apply load_unload_length tdi = length_val, tdo = XXXXXXXXXXXXXXXX;
cycle =
…
end;
end;

This next example uses an alias to group three tdi signals into one alias, and also adds a post-shift cycle
to the load_unload_registers procedure. When this procedure is called, the data passed to it is consumed
three bits at a time, with each bit being shifted into tdi1, tdi2, and tdi3 in order. The total number of shifts
applied in the "shift" block is the total length of the value string divided by three, and then minus one for

Tessent™ Shell User’s Manual 825

Test Procedure File
Procedure Examples
the post shift. Each shift consumes three bits, and the final cycle adds a post shift that assigns the last
three bits. The length of the value string being passed to this procedure must be a multiple of three.

alias TDI_GRP = tdi1, tdi2, tdi3 ;

procedure load_unload_registers load_reg1 =
timeplate tp1 ;
cycle =
force clk1 0 ;
…
end;
shift =
cycle =
force TDI_GRP # ;
pulse tck ;
end;
end;
cycle =
force TDI_GRP # ;
pulse tck;
end;
end;

This final example shows how to use a dofile commands to set up a user-defined register value that is
used to store total number of scan patterns when the final patterns are saved.

add_register_value scan_pat_count -pattern_count scan_test -width 24

826 Tessent™ Shell User’s Manual

 Test Procedure File
Notes About Using the stil2tessent Tool

Notes About Using the stil2tessent Tool

You can use the stil2tessent tool to create a dofile and procedure file. The stil2tessent tool reads a STIL
Procedure File (SPF) and then creates a dofile and test procedure file.
The dofile defines clocks, scan chains, scan groups, and pin constraints. The test procedure file contains
a timeplate and the following standard scan procedures: test_setup, load_unload, and shift. For more
information about this tool, refer to the stil2tessent command description in the Tessent Shell Reference
Manual.

Extraction of Strobe Timing Information From STIL (SPF)

The STIL ClockStructures Block

Extraction of Strobe Timing Information From STIL

(SPF)
In the STIL WaveformTable, strobe window and edge strobe are indicated by which event characters
are used for the measure timing. Using the ‘H’ and ‘L’ characters indicates that the measure is an edge
strobe, while using the ‘h’ and ‘l’ character indicates a window strobe with the length of the strobe window
being determined by the following X event in the event list for that WaveformCharacter.
If the window strobe events (‘h’ or ‘l’) are used for a measure event, then the strobe window is calculated
taking into account the strobe window indicated by these events. The shortest strobe window calculated is
the one used for the procedure file.
If "-edge_strobe_processing on" is specified to the tool, and the edge strobe events (‘H’ or ‘L’) are used
for a measure event, then the strobe window is set to 0 in the procedure file to indicate edge strobe
timing.
If the "-edge_strobe_processing" option is not used or is set to off, and edge strobe events (‘H’ and
‘L’) are used for a measure event, then the existing behavior is maintained where the strobe window is
calculated based on the next force event or the period of the Waveform table. The strobe window is not
set to 0.

The STIL ClockStructures Block

When parsing STIL Procedure Files (SPF), stil2tessent recognizes the Synopsys-defined ClockStructures
block and uses this information to create clock_control definitions. The Latency statement within the
ClockStructures block controls the "set_external_capture_options" statement in the generated dofile.

Test Procedure File Commands and Output

Formats
The test procedure file is supported by a set of commands and a set of output formats.

Tessent™ Shell User’s Manual 827

Test Procedure File
Test Procedure File Commands and Output Formats

Test Procedure File Tool Commands

The following table provides a summary of the tool commands that support the use of test procedure files.
For a detailed description of each command, refer to the corresponding command reference page in the
Tessent Shell Reference Manual.

Table 35. Procedure File Tool Command Summary

Command Description

add_scan_groups Adds a scan group using the scan procedures in the named procedure
file.

read_procfile Reads a new procedure file in non-setup mode. Merges new

procedure and timing data with existing data loaded from previous
procedure files.

write_procfile Writes out existing procedure and timing data as the named procedure
file.

write_patterns Loads a cycle before saving patterns and merges the new data with
the existing data.

report_procedures Reports (displays) a named procedure to the screen. The -All switch
displays all procedures to the screen.

report_timeplates Reports (displays) a named timeplate to the screen. The -All switch
displays all timeplates to the screen.

Test Procedure File Output Formats

The test procedure file format supports the following output formats:

• Fujitsu TDL

• Mitsubishi TDL

• STIL

• TI TDL

• WGL

• TSTL2

• VERILOG

828 Tessent™ Shell User’s Manual

 Test Procedure File
Test Procedure File Commands and Output Formats

The -PROcfile switch causes the write_patterns command to get its timing information from the procedure
file. For more information, refer to the write_patterns command in the Tessent Shell Reference Manual.

Tessent™ Shell User’s Manual 829

Test Procedure File
Test Procedure File Commands and Output Formats

830 Tessent™ Shell User’s Manual

 Chapter 12
Tessent Visualizer
Tessent Visualizer is a graphical user interface for Tessent Shell. This chapter describes the various
features of Tessent Visualizer and how to work with those features. With Tessent Visualizer, you can
use schematics, browsers, tables, and other reports to analyze and understand DFT issues. By cross-
referencing between these different viewpoints of your data and performing various analyses on them,
you can more quickly arrive at solutions to those issues.

Invoking Tessent Visualizer

Framework Overview
Tessent Visualizer Components and Preferences
Tessent Visualizer GUI Reference
Search Features
Using Tessent Visualizer to Debug Design Issues
Accessing Tutorials for Tessent Visualizer
Accessing Videos for Tessent Visualizer
Keyboard Shortcuts

Tessent™ Shell User’s Manual 831

Tessent Visualizer
Invoking Tessent Visualizer

Invoking Tessent Visualizer

Tessent Visualizer is a client-server application, that is, Tessent Shell is the server and Tessent Visualizer
is a client of that server.
Therefore, you can invoke Tessent Visualizer in different ways, depending on the task you need to
perform. Tessent Visualizer can be launched directly from the Tessent Shell application or remotely from
another machine or a different terminal on the same machine.
Irrespective of how you invoke the Tessent Visualizer GUI, two separate processes run and communicate
with each other using the TCP/IP protocol. If you use Tessent Shell commands to invoke the tool,
the details of the TCP/IP protocol such as hostname, port, and the one-time authorization code are
automatically passed to the client. If you choose to launch the GUI directly in the console, you must pass
the TCP/IP protocol details using the optional command-line switches or provide them in the Tessent
Visualizer GUI dialog box.
Use any of the following methods to invoke the Tessent Visualizer GUI:

Invoke Explicitly on the Same Machine

Invoke Explicitly on a Different Machine
Invoke Implicitly
License-Protected Tabs

Invoke Explicitly on the Same Machine

Use the open_visualizer command to run the Tessent Visualizer GUI on the same machine as the Tessent
Shell. Typically, this is how you run the tool unless you have restrictions on running GUI applications on
the same machine as the Tessent Shell.

Prerequisites
• Comply with the hardware and operating systems requirements listed under "Supported
Hardware and Operating Systems" in the Managing Tessent Software manual.
The requirements also apply to the machine providing the X Window desktop (as defined by the
DISPLAY environment variable).

• Set the DISPLAY environment variable correctly.

Procedure
1. Set a context using the set_context command.

2. Load a design and library using the read_verilog and read_cell_library commands. You can also
load an ICL model using the read_icl command.

3. Set the current design using the set_current_design command.

832 Tessent™ Shell User’s Manual

 Tessent Visualizer
Invoke Explicitly on a Different Machine

Note:
You can invoke Tessent Visualizer without running these commands, but most of the user
interface is disabled until you load a design and library, or an ICL model, of your design. To
debug certain IJTAG issues, loading and extracting an ICL file is sufficient to enable you to
examine the ICL network.
You can also use these commands in the Transcript tab after you invoke Tessent
Visualizer.

4. Invoke Tessent Visualizer explicitly on the same machine Tessent Shell is running:

ANALYSIS> open_visualizer
// Note: Tessent Visualizer client successfully started and connected
to the server.

Invoke Explicitly on a Different Machine

In certain cases, it is preferable to run the Tessent Visualizer GUI client and the Tessent Shell server on
separate machines. For example, if the Tessent Visualizer GUI is not backward-compatible with an older
variant SLES machine, use different machines to run the Tessent Visualizer client and the Tessent Shell
server after ensuring the TCP/IP protocol is not blocked between these two machines.

Prerequisites
• Comply with the hardware and operating systems requirements listed under "Supported
Hardware and Operating Systems" in the Managing Tessent Software manual.
The requirements also apply to the machine providing the X Window desktop (as defined by the
DISPLAY environment variable).

• Set the DISPLAY environment variable correctly.

Procedure
1. Set a context using the set_context command.

2. Load a design and library using the read_verilog and read_cell_library commands. You can also
load an ICL model using the read_icl command.

3. Set the current design using the set_current_design command.

Note:
You can invoke Tessent Visualizer without running these commands, but most of the user
interface is disabled until you load a design and library, or an ICL model, of your design. To
debug certain IJTAG issues, loading and extracting an ICL file is sufficient to enable you to
examine the ICL network.
You can also use these commands in the Transcript tab after you invoke Tessent
Visualizer.

4. Invoke Tessent Visualizer explicitly on a different machine.

Tessent™ Shell User’s Manual 833

Tessent Visualizer
Invoke Implicitly

To start the server in Tessent Shell, invoke the open_visualizer command with the ‑server_only
switch. Optionally, specify the TCP/IP port using the ‑tcp_port switch. Valid port numbers are from
1024 to 65535.

ANALYSIS> open_visualizer -server_only

// Server: started
// - Hostname: server01.example.com
// - TCP/IP port: 43527
// - Authorization code: 821703
// Client: not connected
// Note: To connect Tessent Visualizer client to the server, issue
// the following command in a Linux console:
// ----------------------------------------------------------
/<path>/tessent -visualizer -server server01.example.com \
-tcp_port 43527 -authorization_code 821703
// ----------------------------------------------------------

To start the client, use the "tessent ‑visualizer" command:

$TESSENT_HOME/bin/tessent -visualizer
This opens a remote connection dialog box that prompts for the hostname, port, and authorization
code.
The six-digit authorization code is a one-time password that is cleared upon successful connection
to a server or after five invalid attempts. To reconnect to the same server, generate a new
authorization code by invoking open_visualizer on that server with the ‑authorization_code switch.
For more information, refer to the "tessent" command description in the Tessent Shell Reference
Manual.

Note:
The IP address and port of the server must be accessible from the client machine.

Invoke Implicitly
Some Tessent Shell commands run Tessent Visualizer to perform their functions. Therefore, when you
run any of these commands they launch the Tessent Visualizer GUI.

Prerequisites
• Comply with the hardware and operating systems requirements listed under "Supported
Hardware and Operating Systems" in the Managing Tessent Software manual.
The requirements also apply to the machine providing the X Window desktop (as defined by the
DISPLAY environment variable).

• Set the DISPLAY environment variable correctly.

834 Tessent™ Shell User’s Manual

 Tessent Visualizer
License-Protected Tabs

Procedure
1. Set a context using the set_context command.

2. Load a design and library using the read_verilog and read_cell_library commands. You can also
load an ICL model using the read_icl command.

3. Set the current design using the set_current_design command.

Note:
You can invoke Tessent Visualizer without running these commands, but most of the user
interface is disabled until you load a design and library, or an ICL model, of your design. To
debug certain IJTAG issues, loading and extracting an ICL file is sufficient to enable you to
examine the ICL network.
You can also use these commands in the Transcript tab after you invoke Tessent
Visualizer.

4. Invoke Tessent Visualizer implicitly using one of the commands listed in open_visualizer in the
Tessent Shell Reference Manual.

The following example opens the Flat Schematic tab in a Tessent Visualizer window with the
location of the instance with the C7-6 DRC violation highlighted:
ANALYSIS> analyze_drc_violation C7-6

License-Protected Tabs
Some tabs in the Tessent Visualizer window require a Tessent IJTAG (mtijtagf) license. These tabs are
referred to as license-protected tabs.
The following tabs are license-protected:

• ICL Instance Browser

• ICL Schematic

• IJTAG Network Viewer

• iProc Viewer

• Search - ICL Instances

• Search - ICL Pins

• Search - ICL Aliases

• Search - iProcs

Tessent™ Shell User’s Manual 835

Tessent Visualizer
Framework Overview

Note:
When starting the Tessent Visualizer GUI, the tool tries to check out a Tessent IJTAG license
to restore any licensed tabs from the previous session. If the tool displays a message stating
that a required Tessent IJTAG license is unavailable, it could mean that you selected Do not
show this dialog again and clicked OK in a previous session when a dialog box informed you that
some tabs to be restored require a Tessent IJTAG license. Use the "open_visualizer -display"
command and specify any non-license protected tab to start the GUI. For example, you can use
the "open_visualizer ‑display instance_browser" command to start the GUI.

Framework Overview
Tessent Visualizer provides multiple tabs for viewing and debugging design and simulation data in
specialized windows.
The Tessent Visualizer framework consists of the following:

• Windows — Windows contain one or two panes, a global top menu, and a status bar. The menu
and status bar are identical across multiple windows; only the pane content differs.

• Panes — There are at most two panes per window. By default, one pane provides multiple tabs.
Windows can be split into two panes by dragging and dropping. Each pane has its own tabs.

• Tabs — You can view and select multiple tabs within a pane. Each functional task in Tessent
Visualizer is placed as a tab. You can reorder the tabs by dragging and dropping, or cycle through
them with Ctrl+Tab (next tab) or Ctrl+Shift+Tab (previous tab). Refer to “Keyboard Shortcuts”
on page 931 for more ways to interact with Tessent Visualizer using the keyboard. Refer to
“License-Protected Tabs” on page 835 for information about how the tool handles license-
protected tabs.
Each window can contain two panes (separate sets of tabs). This is called a split view. To create a split,
drag one of the tabs to either side. Drag and drop a tab to move it from one side of the split to the other.
There are at most two work areas (panes) per window, as shown in Figure 199.

836 Tessent™ Shell User’s Manual

 Tessent Visualizer
Framework Overview

Figure 199. Tessent Visualizer Split View

You can undock any tab from a window as a separate (floating) window and redock as necessary.
Floating windows have the original window’s full functionality, with access to features such as global
settings and the capability to offer a split view. To undock a tab, double-click the tab or drag and drop
it away from the parent window. To redock, drag it back to the parent window (or any other Tessent
Visualizer window) and drop it as a tab in that window.
You can move a tab to the left or right pane with the context menu, as shown in the following figure.

Figure 200. Moving a Tab to the Left or Right Pane

Tessent™ Shell User’s Manual 837

Tessent Visualizer
Tessent Visualizer Components and Preferences

Tessent Visualizer Components and

Preferences
Tables and schematics represent different views of pins, instances, nets, and other design objects, as well
as actions associated with those design objects. For example, a hierarchical pin visible on a hierarchical
schematic, the instance browser, or a search window can also be visible on a flat schematic.

Tables
Schematics
Tessent Visualizer Preferences
Macros
Tooltips
Saving and Restoring the Session State
Window Title Prefixes

838 Tessent™ Shell User’s Manual

 Tessent Visualizer
Tables

Tables
Tessent Visualizer presents data such as tracing results, pin listings, instances, and nets in tabular form in
all windows, including schematics. These tables are configurable, and you can filter data dynamically.

Table Toolbar Features

Columns and Filters Editor
Table Filters
Data Sorting
Row Highlighting

Table Toolbar Features

All tables in Tessent Visualizer have several common elements, including toolbars, dynamic headers, filter
fields, and data rows and cells.
Most report tables in Tessent Visualizer use a spreadsheet-like format with customizable columns, a
toolbar, and filter fields for each column. The following are additional features common to tables:

• Customize the data types included in the table with the Columns and Filters Editor.

• Select one or more table rows in the Tessent Visualizer window and perform various compatible
actions using the popup menus available by right-clicking.

• Export table data in CSV format with the Export Table icon.

• Add line numbers to tables from the Preferences dialog box.

The following figure and table show an example of a table toolbar and list the common buttons in a table
toolbar, respectively.

Figure 201. Common Table Toolbar Features

Tessent™ Shell User’s Manual 839

Tessent Visualizer
Table Toolbar Features

Table 36. Common Table Toolbar Buttons

Button/Field Description

Columns and Filters Editor. Controls the form and content of the table.

Automatic/Manual Column Width. Toggles between automatic and manual

mode for controlling column widths and column header wrap. In automatic mode,
column widths stretch to fit the table and column headers wrap if necessary to
accommodate narrow data.

Resize columns to contents. This fits the column widths to accommodate the
size of the displayed data.

Export table in CSV format. Alternately, use Ctrl+S.

Loaded row counter. By default, the table loads up to 250 items. Change the
default threshold from the Preferences dialog box.
The "+" next to this number indicates that all data for the table has been loaded if
it is displayed in a gray circle. A green circle indicates that additional data exists in
Tessent Shell. Load this additional data by scrolling down or clicking the circle.

Related Topics
Columns and Filters Editor

Tessent Visualizer Preferences

840 Tessent™ Shell User’s Manual

 Tessent Visualizer
Columns and Filters Editor

Columns and Filters Editor

To access: click the "Columns and Filters Editor" icon in the Tessent Visualizer toolbar.
Use the Columns and Filters Editor to control the content and format of tables.

Description
Figure 202 shows features of the Columns and Filters Editor:

Figure 202. Columns and Filters Editor

Objects

Object Description

Apply filters by typing terms in the filter fields, shown in Figure 202. When a
column is being filtered, the funnel icon is displayed next to the column name in
both the Column and Filters Editor and the tabbed window being modified by the
Column and Filters Editor.

Tessent™ Shell User’s Manual 841

Tessent Visualizer
Table Filters

Object Description

Reorder columns by dragging and dropping the header items at the top of the
Columns and Filters Editor.

Search for specific data types by using string matching in the column for the
property name. Search results are displayed as you type.

Add or remove table columns by checking or unchecking the boxes associated

with column names.

Customize column label names by double-clicking the name representing the

column. The name change is indicated by a bold italic font in the column and filters
editor as well as the results table.

Add or edit column filters by double-clicking the filter cell.

Usage Notes
The report table content is automatically refreshed when you accept the modifications by clicking OK.

Table Filters
Filters limit the data visible in tables using the search criteria you specify.
The filter field is located directly beneath the column headers, as shown in Figure 201. Tessent Visualizer
uses the following filters:

• Wildcard match — The default filtering mechanism used in table filters is wildcard matching. If
you do not provide any other keywords or comparators, the tool uses wildcard matching for the
table filters.
Wildcard matching uses the following special characters:

◦ The asterisk (*) symbol matches any number of characters

◦ The question mark (?) symbol matches a single character

The tool uses adaptive formatting if the filter text does not contain any special keyword such as,
NOT, GLOB, LIKE, or REGEXP, or any comparison or logical operator. The tool wraps the text
within single quotation marks ('') when the focus is out of the filter field.
If the tool detects Tcl-escaped text, that is, text within braces ({}) or double braces ({{}}), it
replaces the braces with single quotation marks. For example, {\\\{\{core_i\}\}\ } results in
'\{{core_i}} '. Consequently, if you want to input text that is enclosed within braces, wrap it with
single quotation marks. Wildcard matching does not work within an escaped Verilog identifier.
By default, wildcard matching is case-insensitive. However, you can also specify the "Case
sensitive filtering" option for wildcard matching. You can set this option in the global Tessent

842 Tessent™ Shell User’s Manual

 Tessent Visualizer
Table Filters
Visualizer Preferences dialog box. All the string literals specified with operators or keywords such
as NOT, GLOB, LIKE, or REGEXP must be enclosed within single quotation marks.

• Exact match — A string literal or value, prepended with an equal sign (=). This restricts the
display of data to those objects matching the string or value.

• Exact inverse match — A string literal or value prepended with the not equals sign (!=). This
restricts the display of data to those objects not matching the string or value.

• Numerical comparison operators — Data columns that include numerical information can be
filtered using standard numerical comparison operators (<, <=, >, >=).

• Logical operators — AND, OR, and NOT. For example:

◦ != abc AND != xyz restricts the display of data to all objects that are not named abc and are
not named xyz.

◦ abc OR xyz restricts the display of data to those objects named abc or xyz.

◦ abc* OR x?z restricts the display of data to objects matching both wildcard expressions.

◦ NOT operator can be used to negate the GLOB, LIKE, or REGEXP expression.

• GLOB and LIKE — Table filters support SQL’s GLOB and LIKE operators.
GLOB syntax:

◦ GLOB expressions are always case-sensitive.

◦ The asterisk (*) character matches any number of characters.

◦ The question mark (?) character matches exactly one character.

◦ The set operator ([]) matches one character from the list of characters enclosed within square
brackets.To match wildcard characters or an opening square bracket ([), specify them with an
extra set operator. For example, GLOB ‘pinname[[]*]’ matches "pinname[1]", "pinname[10]",
and "pinname[]".
LIKE syntax:

◦ LIKE expressions are always case-insensitive.

◦ The percent sign (%) matches any number of characters.

◦ The underscore (_) character matches any single character.

◦ To escape special characters, use the backslash (\). For example, LIKE ‘core\_i’ matches
"core_i", "CORE_i", or any other case-insensitive combination.

Tessent™ Shell User’s Manual 843

Tessent Visualizer
Table Filters

• Standard regular expressions — Data can be filtered using regular expressions by using the
construct REGEXP 'RE'. For example, REGEXP 'clk_\d+$' restricts the display of data to all
objects with names ending in the string clk_ followed by one or more decimal digits.

Note:
In this filter, the keyword "REGEXP" and the single quotation marks are required.

You can make a filter for a hierarchical data structure sticky with the Columns and Filters Editor as shown
in Figure 203. Select the checkbox to enable the sticky behavior for the corresponding column. If the
sticky behavior is enabled, a filter defined for one hierarchy level is applied for all other hierarchy levels. If
it is not enabled, the filter applies only to the hierarchical level where it is defined.

Figure 203. Sticky Column

The sticky filter is also marked in the Hierarchical and ICL Instance Browser with a plus sign (+) on the
standard filter icon ( ) as shown in Figure 204.

Figure 204. Sticky Indicator in Column Header

This feature is only available for the Instance Browser and ICL Instance Browser’s child instance tables
displaying hierarchical data.

844 Tessent™ Shell User’s Manual

 Tessent Visualizer
Data Sorting

Table 37. Filtering Summary

Filter Type Filter Format Examples

Exact match value abc

=value =xyz
=12

Exact match !=value !=abc

(inverse)

Numerical < >10

operators
<= >20 AND <= 50
>
>=

Wildcards GLOB 'expression' GLOB 'abc*'

GLOB '*xyz*'
GLOB 'abc?xyz'
GLOB 'abcdef??'

Regular REGEXP 'expression' REGEXP '^abc.*'

expression
REGEXP '.*_\d0$'

Logical AND abc OR xyz

operators
OR !=abc AND != xyz
NOT GLOB 'expression' NOT GLOB 'abc*'
NOT REGEXP NOT REGEXP '^abc.*'
'expression'

Note:
Filters applied to table columns are processed in Tessent Shell on the complete data model, no
matter how many resulting rows appear in the Tessent Visualizer tabular reports.

Data Sorting
The default order of rows in tabular data is determined by the underlying data structure in Tessent Shell.
In some tables, you can sort this data by clicking the column title cell. The ordering cycles through each of
ascending, descending, and the default ordering.
Data sorting is enabled when the number of rows loaded is less than the limit (250 by default, but
configurable in the Preferences menu). Exceptions: sorting is always enabled in the following cases:

• A table with child instances in the Instance Browser.

• A table with modules in the Cell Library Browser.

Tessent™ Shell User’s Manual 845

Tessent Visualizer
Row Highlighting

Tip
For better performance, limit the set of visible data with filtering before using the sorting function.

Related Topics
Tessent Visualizer Preferences

Row Highlighting
Tables in Tessent Visualizer use color coding to indicate the status of rows.

Figure 205. Selection Colors

• Dark blue — Selected objects

• Light blue — Active cell

• Gray — Objects currently displayed in the schematic

Most popup menus operate on the selected object (dark blue). Copy and paste actions (Ctrl+C and Ctrl
+V) work only on the active cell (light blue). The gray highlighting shows which objects are currently
displayed in a schematic.
Use Shift+click to select multiple adjacent objects in a table and Ctrl+click to select multiple nonadjacent
objects.
You can also use a Boolean value in the "Displayed" column for easy filtering of objects displayed in a
schematic.

846 Tessent™ Shell User’s Manual

 Tessent Visualizer
Schematics

Schematics
Tessent Visualizer schematics contain features that enable you to inspect and navigate your design.
The figure in the "Toolbar" section shows a Flat Schematic with the following GUI objects highlighted:

• Toolbar — Controls how objects are displayed in the schematic and export schematic objects
for use by other tools. You can configure the shortcuts for some actions using Preferences >
Shortcuts.

• Address Bar — Displays the name of the currently selected object. You can also use the
address bar to add new objects to the schematic by name.

• Selection Buttons for Context Table — Select which context table you want to display.
Figure 206 illustrates some additional schematic common features:

• Attributes Table for the Selected Object — Displays information about the currently selected
object. The specific types of data in this table depend on the object selected.

• Overview Pane — Shows all objects that have been added to the schematic. The currently
zoomed view is highlighted. Drag and drop the highlight rectangle to pan the view.

• Pin Table — Displays information about the pins on the currently selected object.
Many objects can be transferred from one schematic to another by dragging and dropping or by right-
clicking and using the context menu. Any highlighting on these objects is preserved when they appear in
the target schematic. If you transfer an object into a schematic where it already exists, any highlighting
on the new copy of the object overrides any highlighting on the previous one. If you transfer multiple
objects that include connectivity obtained with signal tracing from the Flat Schematic to the Hierarchical
Schematic, or from the IJTAG Network viewer to the ICL Schematic, that connectivity is preserved if you
choose "Transfer connectivity" from the schematic settings menu. This option is enabled by default.

Tessent™ Shell User’s Manual 847

Tessent Visualizer
Toolbar

Figure 206. Schematic With Overview Pane and Attributes Table

Toolbar
Schematic Symbols
Context Tables
Signal Net Tracing Strategies
Context Menu Tracing
Displayed Property
Tessent Shell Attributes
Mouse Gestures

Toolbar
There is a toolbar at the top of each Tessent Visualizer schematic tab.
Figure 207 shows the location of the schematic toolbar.

848 Tessent™ Shell User’s Manual

 Tessent Visualizer
Toolbar

Figure 207. Schematic Elements

The following tables summarize the schematic elements. You can also configure the shortcuts for some
actions using Settings > Preferences > Shortcuts.

Table 38. Schematic Toolbar Actions

Button Description

Zoom all: fit the current view of the schematic in the window.

Zoom in.

Zoom out.

Zoom selected: zoom in on and center the selected object or objects.

Undo: undo the previous action.

Redo: redo the previous action.

Redraw: refresh the schematic view.

Tessent™ Shell User’s Manual 849

Tessent Visualizer
Toolbar

Table 38. Schematic Toolbar Actions (continued)

Button Description

Select all: select all objects in the schematic view.

Delete selected: delete all selected objects from the schematic view.

Delete unselected: delete all objects from the schematic view except those
currently selected. There are two exceptions:
• If a selected object is an instance that has some pins displayed, those pins are
not deleted.
• If the selected objects are pins that are connected with a net, that net
connection is not deleted.

Delete all: delete all objects from the schematic view.

Collapse callouts: collapse all callout messages to their icon representations, or

expand if currently collapsed.

Mark/Unmark: highlight the currently selected object or objects with the selected
color, or clear the highlighting on the selected object. If the color you want to use is
already active, you can use Ctrl+M to highlight the selected object(s).

Export schematic: save the current view of the schematic in PDF or PostScript
format, or as a schematic dofile. You can run the generated schematic dofile (or
any other dofile) using the Execute dofile option under the Open menu, or by
using the dofile command in the Transcript or shell window.

Schematic options: set schematic-specific options (different schematic types

have different options in this submenu).

Note:
When a dofile generated with the Export schematic action is run in a future session, the
displayed schematic is re-created as closely as possible. In rare circumstances, some objects
may not be displayed or connected exactly as in the original schematic.

Table 39. Schematic Address Bar

Field Description

Object name Displays the names of the objects you select in the schematic.
You can also use it to specify the names of the objects you want
displayed.

850 Tessent™ Shell User’s Manual

 Tessent Visualizer
Schematic Symbols

Schematic Symbols
Tessent Visualizer schematics use a variety of conventional symbols to present the structure, objects, and
connections of a design.

Object Types in Schematics

Markers
Buffer and Inverter Collapsing
Folding and Unfolding Instances

Object Types in Schematics

The object types displayed in schematics are instances, pins, ports, and nets. You interact with these
objects to explore your design, obtain information about the objects’ properties, trace nets forward and
backward, and so on.

Figure 208. Hierarchical Schematic Showing Pins, Ports, Instances, and Nets

Instances
Instances are individual copies of library cells, primitives, or groups of cells connected by nets to form
hierarchical instances. Both the Hierarchical Schematic and Flat Schematic tabs can contain instances
of library cells and primitives, which display as conventional logic symbols (such as NAND, NOR, and
MUX). Library cells display as rectangles in the Hierarchical Schematic tab, but you can observe their
functional representation in the Flat Schematic tab.

Note:
The ordering of pins on displayed instances matches the ordering as provided by report_gates.

Hierarchical Instances

Tessent™ Shell User’s Manual 851

Tessent Visualizer
Object Types in Schematics

Tessent Visualizer schematics show groupings of symbols by enclosing them in rectangles, objects called
hierarchical instances. Hierarchical instances include their pins. All instances except those at the leaf
level display with both the internal and external connections to those pins.
Figure 209 depicts an instance in the Hierarchical Schematic tab. Callouts convey information about
specific design objects in certain contexts, and the schematic shows simulation data on design pins
where appropriate.

Figure 209. Hierarchical Instance With Callout and Pin Data

Use the right mouse button as shown in Figure 210 to show the internal connectivity of a selected
hierarchical instance. If the number of objects at the selected instance’s interface is large, this option
is not available. In this case, use context tables to selectively add instances and connections to the
schematic.

852 Tessent™ Shell User’s Manual

 Tessent Visualizer
Object Types in Schematics

Figure 210. Showing the Internal Connectivity of a Hierarchical Instance

Figure 211 shows an instance in the Hierarchical Schematic tab with a red callout symbol. Hover the
mouse pointer over the symbol to show the number of DRC violations, and click the symbol to display a
table of those violations.

Figure 211. Hierarchical Instance With DRC Callout

Hierarchical cells (HCells, defined by `celldefine and `endcelldefine in Verilog) are depicted with a slightly
lighter gray color than the library cells. You can view objects inside hierarchical cells, but these are not
annotated with gate data from the flat model.

Tessent™ Shell User’s Manual 853

Tessent Visualizer
Object Types in Schematics

Figure 212. Hierarchical Cell

Figure 213. Hierarchical Instance Representing an Assign Statement

The code for the assign statement symbol is similar to this:

module RDS_process_rtl_tessent_buf_49(a, y);

input a;
output y;

assign y = a;
endmodule

Black-Boxed Instances
A black-boxed instance is an instance with no defined model that you create with the add_black_boxes
command.
Figure 214 shows how the add_black_boxes command creates a blackbox from the dr_mux_i instance
within the tap_i module. The instance then becomes a BB type and displays as a solid gray rectangle in
the Hierarchical Schematic tab.

854 Tessent™ Shell User’s Manual

 Tessent Visualizer
Object Types in Schematics

Figure 214. Black-Boxed Instance Example

Instances in the Flat Schematic Tab

Flattening the design creates certain artificial gates, as shown in Figure 215.

Figure 215. Objects in the Flat Schematic Tab

The flattening process creates primary inputs and outputs, as well as bus instances necessary for
modeling bidirectional pins and ports. In addition, there are instances that tie a net to a fixed value.
User-defined cells display as rectangles with a solid fill. User-added ports display with an orange fill.
Figure 216 shows a persistent buffer symbol in the Flat Schematic tab. The same buffer would look like
Figure 213 in the Hierarchical Schematic tab because you typically implement persistent buffers using
an assign statement.

Tessent™ Shell User’s Manual 855

Tessent Visualizer
Object Types in Schematics

Figure 216. Persistent Buffer Symbol

Pins and Ports

Pins and ports are electrical connections between an instance and a net. Both of these, along with
buses (a collection of related pins) indicate signal sources or destinations in the schematic, and are
characterized by their size and direction (input, output, or bidirectional). For bus naming conventions,
refer to “Buses” on page 887.

Callout Messages
Callouts are informational messages that display on a schematic, as shown in Figure 209 on page 852.
You can add callouts to any instance, pin, or net object that exists on the schematic using the
add_schematic_callout command.
Callouts can also display in a collapsed format, as shown as collapsed callouts in Table 40 on
page 857. The table describes how to view the text of a collapsed callout. Use the Collapse callouts
button as described in Table 38 on page 849 to collapse all callouts. Use Ctrl+left mouse button to drag
and drop individual callouts.

Nets
Single nets display as thin green lines, and bus nets display as thicker green lines. When a bus net
branches to a single net, the bus index displays when the mouse pointer is hovered over the triangular rip
point symbol, as shown in Figure 217.

Figure 217. Bus Index Displayed at Rip Point

856 Tessent™ Shell User’s Manual

 Tessent Visualizer
Markers

Markers
Tessent Visualizer uses marker symbols in schematics to indicate additional properties of the elements
shown. Some, such as trace markers and buffer-collapsing markers, have actions associated with them.
Table 40 lists a summary of marker symbols used in Tessent Visualizer schematics, and whether they are
displayed in flat schematics (F), hierarchical schematics (H), ICL schematics (I), or the IJTAG Network
Viewer (N).

Table 40. Marker Symbols

Symbol Type Description

H,F Green diamond: pin with single connection available to display. Click to
display unambiguous connection from this pin.

H,F Orange diamond: pin with multiple connections available to display. Click
to open the Tracer table and select the tracing destination.

H Blue diamond: ambiguous bidirectional pin. When all drivers and drains of
the port are visible, the color changes to green or orange, as appropriate.
Click to open the Tracer table and select the tracing direction and
destination.

H Half-filled diamond (green): single connection left on bus. Remainder of

displayed pins tied or unconnected. Click to open the Pins context table to
show the tie values on all bus pins.

H Half-filled diamond (blue): one or more ambiguous bidirectional pins on

bus. Remainder of displayed pins tied or unconnected. When all drivers
and drains of the port are visible, the color changes to green or orange, as
appropriate. Click to open the Pins context table to show the tie values on
all bus pins.

H Half-filled diamond (orange): multiple connections on bus, some pins

tied or unconnected. Click to open the Pins context table to show the tie
values on all bus pins.

H Red triangle: pin with coercion (connection against a declared direction).

Click to open the Tracer context table and select the tracing destination.

H Blue square: RTL connection (no connection in hierarchical model).

Click to open the Text/HDL Viewer with a textual representation of this
connection.

I Tan square: implicit connection on the ICL Schematic. The pin is not
constrained by the parent module, and is assumed to be driven or active
as needed.

H,F,I,N Crossed circle (red): no connection.

Tessent™ Shell User’s Manual 857

Tessent Visualizer
Markers

Table 40. Marker Symbols (continued)

Symbol Type Description

H,I Circle with 0/1/X/Z (green): tied to 0/1/X/Z. When shown on a bus port,
click to open the Pins context table to show the tie values on all bus pins.

H,I Circle with "a": ambiguous tie values (mix of some or all of 0/1/X/Z) on
bus. Click to open the Pins context table to show the tie values on all bus
pins.

H,F,I,N Diamond with "+": collapsed buffers and inverters. Click this symbol to
expand.
• Green: no hidden fanout.
• Orange: fanout within collapsed region.

H,F,I,N Diamond with "-": expanded buffers and inverters. Click this symbol to
collapse.
• Green: no fanout in collapsible region.
• Orange: collapsing hides potential fanout.

H,F,I,N Collapsed callout. The green symbol indicates that the callout was added
with the "add_schematic_callout ‑collapsed" command. View the callout
text as a tooltip by mouse hover. The yellow symbol is a native callout,
which you can expand with the "Collapse/Uncollapse callout" toolbar
button.

H DRC violation callout. This symbol indicates that there are DRC violations
related to the marked object. View the number of DRC violations by
mouse hover. Click the symbol to open the list of violations in the DRC
Violations table.

I,N Simulation data callout. Hover over or click this symbol to show simulation
data for scan registers.

H,I Light blue callout. It is displayed on an instance on the hierarchical

schematic to indicate that a corresponding ICL instance exists, and on
the ICL schematic to indicate that a corresponding instance exists on the
hierarchical schematic.

H Red scissors: cut point (input connections cut or disconnected by the user
or the tool).

F Green scissors: cut point driver (single sink). Click the green scissors
symbol to show the driver or sink port.

F Orange scissors: cut point driver (multiple sinks). Click the orange
scissors symbol to display a context table showing the drivers or sinks.

858 Tessent™ Shell User’s Manual

 Tessent Visualizer
Buffer and Inverter Collapsing

Table 40. Marker Symbols (continued)

Symbol Type Description

H,I Orange polygon: pseudo-port (primary output added by the user or tool)
on the hierarchical schematic. Also used to indicate an ICL alias defined
on an ICL instance or port on the ICL Schematic. Click this symbol on the
ICL Schematic to show alias information in the context table.
Note:
Orange fill is also used to indicate primary input or output
pseudo-ports on the flat schematic.

I Blue polygon: indicates a pin that is driven by an ICL alias on the ICL
Schematic. Click this symbol to show alias information in the context table.

H,F,I,N Tessent Shell attributes markers with gui_marking_index set and

"set_attribute_option ‑display_in_gui" enabled.
• Filled circle: all displayed objects with the marker have a value set for
the associated attribute.
• Half circle: not all displayed objects with the marker have a value set
for the associated attribute.
• Empty circle: displayed in the attributes table; indicates that the
attribute is set to the default value and hence is not marked on the
schematic.

Buffer and Inverter Collapsing

Buffers and inverters can be collapsed and expanded in schematics to improve readability. Set the
preference for this feature in the Options (gear) menu of the schematic toolbar.
The collapsed and expanded symbols are shown in either green or orange. Green indicates that there are
no hidden fanouts associated with the collapsed objects, as shown in Figure 218:

Figure 218. Collapsed Buffers and Inverters With No Hidden Fanout

After expanding, there is no additional fanout, as shown in Figure 219:

Tessent™ Shell User’s Manual 859

Tessent Visualizer
Buffer and Inverter Collapsing

Figure 219. Expanded Buffers and Inverters With No Hidden Fanout

Orange indicates that there is additional fanout hidden by the buffer/inverter collapsing, as shown in
Figure 220 and Figure 221:

Figure 220. Collapsed Buffers/Inverters With Hidden Fanout

Figure 221. Expanded Buffers/Inverters With Hidden Fanout

Additional objects appear after adding the fanouts to the schematic, and the color of the markers changes
to green as shown in Figure 222:

860 Tessent™ Shell User’s Manual

 Tessent Visualizer
Folding and Unfolding Instances

Figure 222. Expanded Buffers/Inverters With Fanout Revealed

Note:
Only buffers and inverters added implicitly to the schematic as a result of tracing are collapsible.
These are identified with a gradient fill. Buffers and inverters added explicitly by name or gate ID
are not collapsible and are identified with a solid fill.

Folding and Unfolding Instances

Cell grouping boxes in the Flat Schematic and instances in the Hierarchical Schematic can be folded and
unfolded.
Folding and unfolding grouping boxes or instances is analogous to collapsing and expanding buffers and
inverters, as described in “Buffer and Inverter Collapsing” on page 859. Double-click the grouping box
or instance to do this. Figure 223 shows how you can also unfold hierarchical instances by clicking the
plus sign (+) symbol at the top-left corner.

Figure 223. Unfolding an Instance

Tessent™ Shell User’s Manual 861

Tessent Visualizer
Context Tables

Figure 224. Folded Cell Group

Figure 225. Unfolded Cell Group

Context Tables
Schematics include tables to display information about the objects in the schematic. The tables take
different forms depending on the current selection in the schematic.
Context tables are interactive. They display information, but you also use them to select and manipulate
objects in the schematic. The following example shows a context table listing the data for a selected
instance.

862 Tessent™ Shell User’s Manual

 Tessent Visualizer
Context Tables

Figure 226. Schematic Elements: Context Table

Tracer
The context table for the tracing function provides information about the objects available to the tracing
process.
When you trace from an ambiguous point (orange trace marker) or click the Tracer button next to the
address bar when a pin is selected, the tracer context table opens. Use this table to add the next object
in the tracing path to the schematic by double-clicking the appropriate row in the table. You can select the
tracing direction and strategy, as described in “Signal Net Tracing Strategies” on page 871.

Tessent™ Shell User’s Manual 863

Tessent Visualizer
Context Tables

Figure 227. Tracer Context Table

Pins and Gate Pins

Context tables are available for instance pins in the Hierarchical Schematic and gate pins in the Flat
Schematic.
You can select an instance in the Hierarchical Schematic tab or Flat Schematic tab and click the Pins
button or the Gate Pins button near the address bar, respectively, to view information about the pins
belonging to that instance.

864 Tessent™ Shell User’s Manual

 Tessent Visualizer
Context Tables

Figure 228. Context Table for Instance Pins (Hierarchical Schematic)

Instances (Hierarchical Schematic)

A context table is available for instances in the Hierarchical Schematic tab.
Select an instance in the Hierarchical Schematic tab and click the Instances button near the address
bar to view information about the child instances.

Tessent™ Shell User’s Manual 865

Tessent Visualizer
Context Tables

Figure 229. Context Table for Instances (Hierarchical Schematic)

Nets (Hierarchical Schematic)

A context table is available for nets in the Hierarchical Schematic tab.
Select an instance in the Hierarchical Schematic tab and click the Nets button near the address bar to
list the nets one level below that instance.

866 Tessent™ Shell User’s Manual

 Tessent Visualizer
Context Tables

Figure 230. Context Table for Nets (Hierarchical Schematic)

Flat Sinks (Flat Schematic)

Flat sinks are the set of primary inputs that you add to control internal pins. For example, you can add a
primary input at the output of a PLL to model the clock, while keeping the PLL black-boxed.
The green dashed line in the following figure representing the original fanout net shows that this
replacement is complete, and that there is only one user-added primary input associated with this fanout.
The red scissors symbol indicates that a pseudo-port now drives that fanout.

Figure 231. Fanout Replaced by User-Added Primary Input

Tessent™ Shell User’s Manual 867

Tessent Visualizer
Context Tables

Figure 232 shows the same MUX in the Flat Schematic, as well as the user-added primary input. The
primary input is added to the schematic when you click the green scissors symbol on the MUX output.

Figure 232. Flat Sink

Figure 233 shows a Hierarchical Schematic view of the same clock MUX, but in this case it has had all
of its fanout replaced by multiple user-added primary inputs. The orange dashed line representing the
original fanout net shows that this replacement is complete, and that there is more than one user-added
primary input associated with this fanout. The red scissors symbols indicate that pseudo-ports now drive
that fanout.

Figure 233. Fanout Replaced by Multiple User-Added Primary Inputs

Figure 234 shows the same MUX in the Flat Schematic, as well as the user-added primary inputs. The
primary inputs are added to the schematic when you click the orange scissors symbol.

868 Tessent™ Shell User’s Manual

 Tessent Visualizer
Context Tables

Figure 234. Multiple Flat Sinks

Clicking the orange scissors symbol displays the context table for the user-added primary inputs, and
double-clicking a row displays the flat sink.

Figure 235. Context Table for Multiple Flat Sinks

Netlist Drivers (Flat Schematic)

Netlist drivers are the original drivers of the fanout of user-added primary inputs.
Use the following commands to add primary inputs. These are indicated by the red scissors symbol in the
Hierarchical Schematic tab.

Tessent™ Shell User’s Manual 869

Tessent Visualizer
Context Tables

add_primary_inputs I01/in1 -internal -pin INTERNAL_1

add_primary_inputs I01/b1/A0 -internal -pin INTERNAL_2
add_primary_inputs u1/D -internal -pin INTERNAL_3

Figure 236. User-Added Primary Inputs

As a result, the original fanout of the pi1 pin was disconnected, as indicated by the dashed line.
Figure 237 shows the pi1 pin in the Flat Schematic. The circle with the red X shows that it is
disconnected, and the orange scissors symbol indicates that its original fanout is now driven by multiple
user-added primary inputs. Click the orange scissors symbol to display the context table listing the flat
sinks, as shown in the following figure.

870 Tessent™ Shell User’s Manual

 Tessent Visualizer
Signal Net Tracing Strategies

Figure 237. Netlist Driver and Context Table for User-Added Primary Inputs

Figure 238 shows the user-added primary inputs in the Flat Schematic. The orange fill indicates that
these are user-added, and the green scissors symbol indicates that they have a single original driver.
Clicking the scissors symbol shows the driver.

Figure 238. User-Added Primary Inputs (Flat Schematic)

Related Topics
Markers

Signal Net Tracing Strategies

The Tessent Visualizer schematic tabs feature multiple tracing strategies. They are available when the
Tracer context table is activated for a pin, either by clicking an orange trace marker in the schematic or
the Tracer button after a pin is selected. These tracing strategies are common for all schematics.
For the green trace markers, the following tracing strategies are available in the schematics:

Tessent™ Shell User’s Manual 871

Tessent Visualizer
Signal Net Tracing Strategies

• Trace to decision point (default)

• Trace by one

Use the Options button ( ) in the schematic toolbar to select an option. A decision point is any point
where a logic decision is made, such as a gate, state element, or a hierarchical pin with multiple fanouts,
as shown in Figure 239.

Figure 239. Decision Point Strategy on Hierarchy Boundary at q[6] Port

Figure 240. Choosing a Path From the Tracing Table

You can continue tracing from the decision point by double-clicking one of the paths in the table.
For additional information about tracing buses, refer to “Buses” on page 887.

Decision Point Tracing Strategy

Decision point tracing is the default strategy. In the decision point tracing strategy, a path is traced to the
point where a logic decision is to be made. Tracing continues through buffers, inverters, wire primitives,
and hierarchical boundaries as long as there is only one fanout (forward tracing) or fan-in (backward
tracing), and stops on other gates, cells, and logic primitives.

872 Tessent™ Shell User’s Manual

 Tessent Visualizer
Signal Net Tracing Strategies

Figure 241 shows the result of a trace using the Decision Point strategy. Pin A1 on the AND gate has
been traced back through the inverter to the MUX, which is the first logic decision point.

Figure 241. Decision Point Strategy

Endpoint Tracing Strategy

When you use the endpoint tracing strategy, the tracing stops on any endpoint element. An endpoint is
defined as any primary input or output, or any sequential element, memory, or black box. Tracing under
the endpoint strategy traverses all buffers, inverters, logic gates, and hierarchical boundaries between the
tracing start point (the pin selected on the schematic) and the endpoint, and the resulting paths includes
those elements.

Nearest State Element Tracing Strategy

When you use the nearest state element tracing strategy, tracing stops on the first state element
encountered. State elements are sequential elements or memories. Tracing under the nearest state
element strategy includes all buffers, inverters, logic gates, and hierarchical boundaries between the
tracing start point and the state-element endpoint, and the resulting paths include those elements.

Nearest Scan Element Tracing Strategy

The nearest scan element tracing strategy is similar to the nearest state element tracing strategy. The
difference is that while the nearest state element tracing strategy includes all state elements in the fanout
of the starting trace point, the nearest scan element tracing strategy only considers those elements that
are included in the scan chain path.

Complete Fan-in and Fanout Tracing Strategy

Complete fan-in or fanout tracing performs full structural tracing. When tracing with the complete fan-in
and fanout strategy, the entire input or output logic cone is included in the results.

Stop on First Match Tracing Strategy

For the first match tracing strategy, you provide additional data in the form of a filter. The complete fan-in /
fanout strategy is used, but tracing stops when the first element matching the filter is found on the path. A
single result is reported.

Trace by One Tracing Strategy

When you use the trace by one strategy, tracing stops at the next hierarchical level found in the
Hierarchical Schematic, or the next logic element found in the Flat Schematic.

Tessent™ Shell User’s Manual 873

Tessent Visualizer
Context Menu Tracing

Context Menu Tracing

The Tessent Visualizer schematic tabs support multiple actions for context menu tracing. These actions
are available when the context table is activated after you select pins on the schematic.
The following tracing actions are available in the schematic tabs:

• Trace backward — The tool activates this action if at least one input or bidirectional pin is
selected. This option enables you to trace backward to the immediately preceding decision
point from the selected pin, bus, or instance objects. If you trace from an instance object in the
schematic, the tool performs the tracing from all the input pins of the schematic.

• Trace pins — The tool activates this action if you select exactly two pins, ports, or bus pins.
The tool tries to connect the selected pins on the schematic. If the tool cannot find a connection
between the specified pins, it displays a corresponding message.

Displayed Property
All objects in Tessent Visualizer have a property called "displayed."
The "displayed" property of an object refers to the corresponding schematic for the object, and indicates
whether that object is added to the schematic. The context of being displayed is important for pin buses
because all tracer actions are run for parts of the bus being added to the schematic. By default, the
"displayed" property is indicated in tables by a distinct background color for a row, and can also be added
as a column in those tables.

Tessent Shell Attributes

Tessent Visualizer includes functionality to view Tessent Shell attributes and annotate the objects
displayed in schematics with them.
The Tessent Shell attributes for the currently selected object in the schematic are shown in a table.

874 Tessent™ Shell User’s Manual

 Tessent Visualizer
Tessent Shell Attributes

Figure 242. Tessent Shell Attributes Table

By default, only those attributes with non-default values, or that were registered with the "‑show_default"
option, are shown. You can use the Show all checkbox to show all attributes, including those with default
values.
You can double-click a cell or use the right mouse button context menu in the GUI column to select a
color in the GUI marking index and show a corresponding marker near schematic objects that have that
attribute set to a non-default value. Hover the mouse pointer over that marker in the schematic as shown
in Figure 242 to show a tooltip with the attribute name and value.

Note:
The circles in the GUI column correspond to the integer GUI marking indices from the
set_attribute_options ‑gui_marking_index command. You can use > 0 or !=0 in the filter field of
this column to search for attributes with this property set.

Note:
For Boolean attributes, the marker is only shown if the value is set to "true."

An empty circle in the GUI column indicates that the attribute is set to the default value. A corresponding
marker is not displayed in the schematic window in this case. A half-filled circle applies to buses only and
indicates that not all of the pins composing the bus have the relevant attribute set to nondefault values.
Additionally, the "Value" column indicates "<multiple values>" for buses where the values for this attribute
of separate pins are not consistent.

Tessent™ Shell User’s Manual 875

Tessent Visualizer
Mouse Gestures

Mouse Gestures
Zoom in or out within schematics using the left mouse button.
Figure 243 summarizes the four mouse gestures (stroke commands) available to perform a zoom.

Figure 243. Mouse Gestures in Tessent Visualizer Schematics

You can also zoom in and out using the scroll wheel of your mouse.
Additional mouse gestures are available:

• Shift-click and drag with the left mouse button: area select.

• Click and drag with the scroll wheel: pan the view.
Customize the mapping of mouse gestures to specific mouse buttons and keyboard modifiers in the
Preferences dialog box. Refer to “Tessent Visualizer Preferences” on page 876.

Tessent Visualizer Preferences

Customize Tessent Visualizer with the Preferences dialog box, which is available from the Settings
pulldown menu.

876 Tessent™ Shell User’s Manual

 Tessent Visualizer
Tessent Visualizer Preferences

The Preferences dialog box contains several tabs:

• Schematics

• Tables

• Text viewers

• Shortcuts

• Other
Use the Schematics tab to define how schematics look and operate. Set maximum lengths for names,
set the width of net representations, redefine how the mouse works when interacting with schematics, and
choose the color theme.
There are three predefined color themes available in Tessent Visualizer schematics: light, dark, and high-
contrast. Set the color scheme with the Preferences dialog box.

Figure 244. Light, Dark, and High-Contrast Color Themes

Use the Tables tab to set the maximum number of rows loaded in tables and to show line numbers in
tables.
Use the Text viewers tab to set the font size and line-wrapping policy in the Text Viewer. You can also
configure the maximum number of lines displayed in the text viewer, the default being 20,000. You can
use the Text viewers tab to define an external text editor that can be launched from the Text/HDL Viewer
tab. Choose from several common text editors, or define your own preferred one. Use the variables
"%l" (line number) and "%f" (filename) as arguments to the text editor executable. For example, this text
editor definition opens the file currently in the Text/HDL Viewer tab in the Gedit editor with the cursor
positioned at the current line:

/usr/bin/gedit +%l %f

Tessent™ Shell User’s Manual 877

Tessent Visualizer
Tessent Visualizer Preferences

Figure 245. Preferences Dialog Box (Text viewers Tab)

Note:
Tessent Visualizer invokes whichever executable you specify as the external text editor. Ensure
that valid and working options are set here.

Use the Shortcuts tab to review, change, and set custom shortcuts for GUI actions within the Tessent
Visualizer GUI. You cannot record any of the reserved shortcuts, such as Copy (Ctrl-C), and if you
attempt to do so, the tool displays an informational message. It manages conflicting shortcuts and does
not permit duplicate global shortcuts. However, duplicates are permitted for widget-specific shortcuts.

878 Tessent™ Shell User’s Manual

 Tessent Visualizer
Macros

Figure 246. Preferences Dialog Box (Shortcuts Tab)

Use the Other tab to set the global font size.

Macros
You can define a macro for any script or command that you can run in the Tessent Shell environment.
Open the Macros menu to define or run custom macros. You can use the Macro Editor dialog box to
create new macros or modify existing macros. Figure 247 shows the Macro Editor with two simple macros
defined. With the Macro Editor, you can do the following:

• Add, remove, or duplicate a macro.

• Reorder the macros in the Macros menu.

• Record a keyboard shortcut for a macro.

• Undefine a macro keyboard shortcut.

• Select an icon for a macro.

Tessent™ Shell User’s Manual 879

Tessent Visualizer
Tooltips

Figure 247. Macro Editor

The following example shows the macros menu after creating the report myType macro in the editor. In
this example, the macro runs the report_gates command with the -type option and the predefined variable
shown in Figure 247.

Figure 248. Running a Macro

You can define a keyboard shortcut, for example, Shift+R, for a new macro. You can run the macro
directly from the macros menu, or from the keyboard using that shortcut. If you attempt to record a
keyboard shortcut for a macro using an existing shortcut, an error message is reported.

Tooltips
Many Tessent Visualizer features have associated tooltips, which are informational text popups that
appear when you hover the mouse pointer over a graphical element such as an object, filter box, or
button.
Figure 249, Figure 250, and Figure 251 show examples of tooltips for several Tessent Visualizer features.

880 Tessent™ Shell User’s Manual

 Tessent Visualizer
Tooltips

Figure 249. Tooltip for a Collapsed Buffer Indicator

Figure 250. Tooltip for a Filter Box

Figure 251. Tooltip for an Action Button

Tessent™ Shell User’s Manual 881

Tessent Visualizer
Saving and Restoring the Session State

Saving and Restoring the Session State

The session state, such as the tabs displayed in a window and specific user preferences, is stored in a
hidden file in your home directory. Some other specific settings such as filtering and instance highlighting
persist in memory until the Tessent Visualizer server is closed. For example, if you close a Tessent
Visualizer client and later start a new client connected to the same server, the session is displayed as you
left it.
You can save and restore specific configurations with Settings > Export configuration and Settings
> Import configuration. You can also start Tessent Visualizer with a specific configuration using
-import_configuration option of the open_visualizer with either the open_visualizer command or tessent
-visualizer invocation.

Window Title Prefixes

You can define a prefix to be added to the title bars of the Visualizer windows, to distinguish between
multiple sessions running on the same machine.
To define a window title prefix, invoke Tessent or open the Visualizer session with the -label option:

% $TESSENT_HOME/bin/tessent -visualizer -label name

SETUP> open_visualizer -label name

Alternately, set the prefix directly in Visualizer as shown in Figure 252:

Figure 252. Setting a Window Title Prefix

The standard window table is prepended with the string you set, as shown in Figure 253. In addition,
Tessent Visualizer is added to the window title as a suffix:

882 Tessent™ Shell User’s Manual

 Tessent Visualizer
Window Title Prefixes

Figure 253. Visualizer Window Label

Tessent™ Shell User’s Manual 883

Tessent Visualizer
Tessent Visualizer GUI Reference

Tessent Visualizer GUI Reference

The Tessent Visualizer GUI consists of several tabbed windows that function as different views on design
data. You can look at objects as part of schematics, browse tables, view a report, or look at different types
of syntactically‑highlighted text.

Hierarchical Schematic
Flat Schematic
ICL Schematic
Instance Browser
ICL Instance Browser
Cell Library Browser
DRC Browser
Config Data Browser
RTL Metrics Browser
Transcript
Wave Viewer
Text/HDL Viewer
IJTAG Network Viewer
iProc Viewer
Diagnosis Report Viewer

Hierarchical Schematic
This section describes features available only in the Hierarchical Schematic tab. The Hierarchical
Schematic shows a representation of the design before design flattening. Use this feature to explore the
structure of your design and the relationships between the elements making up the design.

Note:
“Schematics” on page 847 describes schematic features common to both the Hierarchical
Schematic and the Flat Schematic.

884 Tessent™ Shell User’s Manual

 Tessent Visualizer
Hierarchical Schematic

Figure 254. Hierarchical Schematic Tab

You can use the tools available from the Toolbar, or you can use the context menu to do the following:

• Show the selected objects in the Flat Schematic.

• Show the HDL definition for the selected object in the Text/HDL Viewer.

• Show the HDL instantiation for the selected object in the Text/HDL Viewer.

• Show all pins, or hide unconnected pins, on the selected instance (as shown in Figure 255).

• Show the internal connectivity of a hierarchical instance.

• Show an instance as parent in the Instance Browser.

• Delete all selected objects from the schematic.

• Delete all unselected objects from the schematic.

• Trace backward, or trace between two selected pins or bus pins.

• Report gates on selected pins.

• Copy the post-synthesis names of selected objects to the system clipboard.

• Copy the active names of selected objects to the system clipboard. Active names are compatible
with Tessent introspection commands.
In addition to the common toolbar actions, the Hierarchical Schematic tab also contains a Gate Report
Settings widget. The widget opens the Gate Report Settings dialog box, which provides access to a

Tessent™ Shell User’s Manual 885

Tessent Visualizer
Hierarchical Schematic
subset of the set_gate_report command options. Different options are active depending on the data
models available in Tessent Shell.

Note:
The Gate Report Settings widget is available only in the Flat and Hierarchical Schematic tabs.
You can edit any of the displayed options directly in the widget.

Figure 255. Hierarchical Instances With Pins Shown and Hidden

Note:
The menu items Show HDL definition and Show HDL instantiation are available only when
the Tessent Shell context is set to "dft -rtl." The Show HDL definition menu item is available for
library cells in all contexts when the library cell file is available.

Note:
By default, all pins are initially shown on an instance when it is added to the Hierarchical
Schematic if the total number of single pins and bus ports is 16 or fewer.

The following tables relate specifically to the Hierarchical Schematic:

• Instances Table — Displays information about the instances contained within a selected
instance. For more information, refer to “Instances (Hierarchical Schematic)” on page 865.

• Nets Table — Displays information about the nets of a selected instance. For more information,
refer to “Nets (Hierarchical Schematic)” on page 866.
Figure 256 shows several symbols specific to the Hierarchical Schematic:

886 Tessent™ Shell User’s Manual

 Tessent Visualizer
Hierarchical Schematic

Figure 256. Hierarchical Schematic Symbols

Design hierarchy is shown with rectangles surrounding the objects in a design instance, and library cells
are shown without rectangles and filled with gray. The leaf-level instance names are displayed above
each instance, and the module or cell names are displayed below them.

Buses
The Hierarchical Schematic can display either complete or partial buses, using the following naming
conventions:

• Fully displayed — Shows the full range. For example, "scan[7:0]".

• Partially displayed — Indicates the count of displayed pins versus the total pin count. For
example, "scan[2 of 8]".

• Single pin of a bus — The index of the displayed pin is shown. For example, "scan[3]".
You can add or remove bus pins in the display from any table that lists hierarchical pins, such as the Pins
table in the Instance Browser or the Pins context table at the bottom of the Hierarchical Schematic.
You can also add bus pins with the following procedure:

1. Select the instance in the Hierarchical Schematic. The instance name is displayed in the address
bar (refer to Figure 207 on page 849).

2. Append text to the instance name to add the bus pins. For a single pin, include the pin index (for
example, "data[3]" in "mytop/parent_module/this_instance/data[3]"). To designate the complete
bus, use the "*" wildcard character (for example, "data*").

3. Press Enter. The address bar shows both the pins and the nets. Click the pins line. The pins are
added to the instance in the schematic.
The display of bus pins affects the operation of the tracing function, because the tracer starts from
displayed bus pins. Add individual pins for tracing to the Hierarchical Schematic, or apply filtering in the
tracer table for the pins of interest.

Tessent™ Shell User’s Manual 887

Tessent Visualizer
Hierarchical Schematic

Tessent Visualizer uses several naming and symbol conventions for buses in schematic windows. Refer
to Figure 257 for examples.

Figure 257. Bus Tracing in the Hierarchical Schematic

Item Description

Bus-to-scalar connection with rip index ("0" in this case) shown with mouse
pointer hover over rip symbol.

Generated name for a partial bus (two bits of a three-bit bus in this case).

Orange diamond representing multiple paths not shown from this bus pin.

Generated name of a partial bus with a single bit displayed (bit index 2, in
this case).

Buses can be split into sub-ranges as shown in Figure 258. In this case, ten bits of the 31-bit output bus
from instance s1 are merged with all ten bits of the output buses from instances s2 and s3 to form the 30-
bit merged_out_bus.
Bus rip indices can also be shown directly on the hierarchical schematic by choosing this feature from the
options menu.

888 Tessent™ Shell User’s Manual

 Tessent Visualizer
Hierarchical Schematic

Figure 258. Bus Sub-Ranges

Note:
This schematic does not indicate which ten bits of the output bus from s1 are connected. Use the
Tracer table to determine connectivity.

To show all bus pins when only a subset is displayed, select one or more bus pins and right-click to
access the Show all pins item from the context menu:

Figure 259. Showing All Bus Pins in the Hierarchical Schematic

If the width of the bus is greater than 256 bits, this feature is disabled. To show all pins in this case, use
the Pins Table.

Loopbacks
Loopbacks defined with add_loadboard_loopback_pairs are indicated on the Hierarchical Schematic
as shown in Figure 260. All indicators such as trace markers, the tracer table, and net visualization are
available on primary inputs and outputs with these connections.

Tessent™ Shell User’s Manual 889

Tessent Visualizer
Hierarchical Schematic

Figure 260. Loopback Connection

The tool also displays loopbacks on the ICL Schematic.

Other Symbols
Additional marker symbols indicate other hierarchical schematic features, such as tied-value indicators. A
tied-value indicator is displayed when a net is tied to a logic value or an unknown. Refer to Figure 261 for
an example, and Table 40 on page 857.

Figure 261. Example of a Tied-Value Marker With Associated Pin Table

890 Tessent™ Shell User’s Manual

 Tessent Visualizer
Flat Schematic

Flat Schematic
The Flat Schematic shows a representation of the design after design flattening. Use the Flat Schematic
to analyze and debug issues when the details required for analysis are not available in the Hierarchical
Schematic. For example, simulation data and functional representations of hierarchical and library cells
are available in the Flat Schematic.
Library and hierarchical cells in the design appear in the Flat Schematic as gates. Cells that consist of
a single gate are displayed with the conventional symbols for those gates. Figure 262 shows cells that
consist of multiple gates, displayed either with or without a bounding box showing the grouping. You
can control this display option using the Cell grouping checkbox in the Options menu available from the
toolbar.

Figure 262. Flat Schematic (Cell Grouping On)

You can right-click the dashed-line bounding box and use the context menu to delete the instance from
the Flat Schematic, show it in the Hierarchical Schematic, or show all gates within the grouping.

Note:
In a library cell bounding box, a NAND function that has at least one (but not all) inputs inverted
is displayed as an OR symbol. A NOR function that has at least one (but not all) inputs inverted is
displayed as an AND symbol.

Note:
When cell grouping is turned on, instances shown on the schematic are identified by their module
or primitive names (below the symbol) and leaf-level cell library names (above the symbol). When
it is turned off, they are identified by their module/primitive names and their gate IDs from the flat
model.

Many features of the Flat Schematic are similar to those in the Hierarchical Schematic. However, one
difference is that you cannot control the display of pins on most instances, with the exception of RAM and
ROM instances. You can add or remove pins for these instances by using the popup menu or by dragging
and dropping from the pins table.
Pin names on instances appear in quotation marks when the pin is not part of the design hierarchy.

Tessent™ Shell User’s Manual 891

Tessent Visualizer
ICL Schematic

ICL Schematic
The Tessent Visualizer ICL Schematic is similar to the standard Tessent Visualizer Hierarchical
Schematic, including a main schematic window, a small overview window, and an attributes table for
selected instances. There are, however, several differences and additional features.

Context Tables
In addition to the Tracer, Pins, and Instances context tables, the ICL Schematic includes two additional
context tables:

• Scan Interfaces — Shows the same information for selected instances as the Scan Interfaces
table in the ICL Instance Browser does.

• Aliases — Shows aliases that reference the selected pin or instance.

Instances and pins referenced by aliases are marked on the ICL Schematic with an orange or blue port
symbol, as shown in Figure 263. As with the Hierarchical and Flat Schematics, objects can be cross-
referenced to their text definitions from the ICL Schematic, as shown in the figure.

Figure 263. Alias in the ICL Schematic

In addition to the options also available in the Hierarchical Schematic options menu, the ICL Schematic
options menu includes options specific to ICL.
The Show simulation values option annotates the ICL Schematic object’s pins with their simulation data.
The tool displays a 0 or 1 to indicate the current ICL simulator value. The tool encloses the 0 and 1 bits
within parentheses (()) to indicate that these bits are part of a symbolic variable and their values are
patchable at run time. Refer to the "Retargeted Symbolic Variables" section in the Tessent IJTAG User’s
Manual for more information.

892 Tessent™ Shell User’s Manual

 Tessent Visualizer
ICL Schematic

The tool displays a question mark ("?") to indicate that the ICL simulator value is not relevant and that
the tool has deferred determining the value until it is needed. The value may be determined by the IJTAG
retargeter after an iApply command when it must be determined to fulfill the current iApply targets. The
remaining unknown values are resolved when the close_pattern_set command finalizes the pattern.
The tool displays the value as an A for automatically determined signals. The tool considers these signals
to be always correct. Refer to Figure 264 for an example of automatically determined signal values on the
TAP’s FSM module.

Figure 264. Automatically Determined Values

The Highlight scan path option displays the Highlight Scan Path toolbar. Refer to “IJTAG Network Viewer”
on page 915 for complete information on this toolbar. Select the Show scan pins by default option to
display scan in and scan out ports on instances, or the Show SSN pins by default option to display the
SSN pins on the instances. This enables you to easily trace the scan path or SSN datapath.

Mux Select Values

Hover the mouse pointer over a mux in the ICL Schematic to view its select values in a tooltip. The tool
also displays the active mux input with "<" on the symbol.

Figure 265. Mux With Select Values Displayed

Tessent™ Shell User’s Manual 893

Tessent Visualizer
ICL Schematic

Implicit Connections and Driven-As-Needed Pins

The tool displays a tan square marker on a hierarchical pin on the outside of a block to indicate that the
pin is not constrained by the parent module and is assumed to be driven or active as needed.

Figure 266. Pins Driven or Active as Needed

The tool displays a tan square marker on a hierarchical pin on the inside of a block to indicate that every
element in the block normally required to be connected to the indicated pin is implicitly connected to the
signal associated with that pin.

894 Tessent™ Shell User’s Manual

 Tessent Visualizer
ICL Schematic

Figure 267. Implicitly Connected Pins

ICL Definition
Choose "Show ICL definition" on the right mouse button menu to display an instance’s definition in the
Text/HDL Viewer. Keywords are highlighted in color.

Tessent™ Shell User’s Manual 895

Tessent Visualizer
ICL Schematic

Figure 268. Displaying the Definition of an ICL Instance

Tracing the Current Scan Path

To trace the scan path, select both the scan input and scan output pins of interest in the ICL Schematic or
IJTAG Network window, click one with the right mouse button, and select "Trace pins along scan path".

Figure 269. Traced and Highlighted Scan Path

Choose between "network end state" and "last used" in the "Highlight" menu.

896 Tessent™ Shell User’s Manual

 Tessent Visualizer
Instance Browser

Loopbacks
The tool displays loopbacks created with add_loadboard_loopback_pairs on the ICL Schematic. Refer to
“Hierarchical Schematic” on page 884 for complete information.

Displaying Bus Pins

When a subset of pins is displayed for a bus, you can display all the pins by selecting the bus (or buses),
right-clicking, and choosing the Show all pins feature. Refer to “Hierarchical Schematic” on page 884 for
complete information.

Instance Browser
Use the Instance Browser to navigate your design and obtain reports about its elements. It is analogous
to a file browser.
The Instance Browser consists of the following major elements:

• Tree View — A pane that shows the instances in your design hierarchy directly. Click the pane
header repeatedly to sort the tree in ascending alphabetical, descending alphabetical, or default
order.

• Child Instances table — A pane that displays information about the children of the instance
currently selected in the tree view or the Address Bar.

• Address Bar — A text field that shows the instance currently selected in the tree view and the
parent instance for instances displayed in the Child Instances table. Type an instance name in
this field to select an instance without using the Tree View or Child Instances table.

• Pins and DRC Violations tables — A table that lists the pins or DRC violations for the
instance(s) currently selected in the Child Instances table.

Note:
For huge designs, it may be more efficient to select an instance and then use the filtering
functions in the Child Instances table to find objects and explore the hierarchy from the search
results.

Click an instance in the tree view to display that instance’s contents in the Child Instances table. Double-
clicking an instance in the tree view expands the node in the tree. First, the node is selected, and it
becomes the parent instance. If the double-clicked node is different than the one previously selected, the
Child Instances table is reloaded with the children of the new parent.
Select an instance of any type in the Child Instances table to display its pins or DRC violations in the
appropriate context table. Double-click, or use the Enter key, to open the next level of hierarchy (if any) in
the Child Instances table. Press the Backspace key to navigate up one level of hierarchy.
Show instances of cells or modules in the Hierarchical Schematic, the Flat Schematic, or the Text/HDL
Viewer by right-clicking the cell or module in the tree view or Child Instances table and choosing the
appropriate option from the popup menu.
Copy the active or post-synthesis name of an instance to the system clipboard by right-clicking the name
in the tree view and choosing the appropriate option from the popup menu. Active names are compatible
with Tessent introspection commands; post-synthesis names are not.

Tessent™ Shell User’s Manual 897

Tessent Visualizer
Instance Browser

Figure 270. Instance Browser Elements

The Child Instances table and Pin/DRC Violations table include toolbars that provide the common controls
described in “Tables” on page 839, as well as buttons you can use to switch between pin information
and DRC violations in the table. The Child Instances table has a Hierarchy-Up button to navigate to
the parent of the currently selected instance. In addition, the Child Instances table has a gear icon for
additional Options. If you click the gear icon, a dropdown list with options displays (Refer to Figure
271 on page 898). If you select the Enable cell grouping checkbox, the tool enables cell grouping
and groups all the library cells at the current hierarchy level into a single new node. The tool creates
this new node with the instance type LibraryCells. The fault statistics for all the cells in the current
library are collected under this node. If you select the Exclude unlisted faults checkbox, the tool runs the
report_statistics command with the ‑hierarchy and ‑exclude_unlisted_faults switches to calculate coverage
statistics.

Figure 271. Cell Grouping in Hierarchical Instance Browser

898 Tessent™ Shell User’s Manual

 Tessent Visualizer
ICL Instance Browser

Note:
The tool provides cell grouping only for the Hierarchical Instance Browser.

To debug directly in the instance browser, use the sorting and filtering functions as shown in Figure 272
to investigate faults and design rule violations, and to discover instances with problematic coverage
statistics. In this example, the test coverage loss and total DRC violations columns have been added and
sorted, and a significant problem can be seen in the U_3 instance.

Figure 272. Debugging in the Instance Browser

Related Topics
Search Features

ICL Instance Browser

The Tessent Visualizer ICL Instance Browser is similar in form and function to the standard Tessent
Visualizer Instance Browser for hierarchical designs. There are, however, several additional features.

ICL Instances
You can examine several types of ICL objects in the ICL Instance Browser:

• Instance

• ScanMux

• DataMux

• ClockMux

Tessent™ Shell User’s Manual 899

Tessent Visualizer
Cell Library Browser

• ScanRegister

• DataRegister

• LogicSignal

• OneHotDataGroup

• OneHotScanGroup

• Primitive
Refer to "Instrument Connectivity Language" in the Tessent Shell Reference Manual for information on
these and other ICL objects.

ICL Instance Browser Actions

You can perform several operations on objects in the ICL Instance Browser:

• Show ICL definition — Similar to the Show HDL definition action in the hierarchical design
Instance Browser. Displays the ICL object’s definition in the Text/HDL Viewer.

• Show on ICL Schematic — Similar to the Show on Hierarchical Schematic action in the
hierarchical design Instance Browser. Displays the ICL object on the ICL Schematic.

• Show on Hierarchical Schematic — Displays the hierarchical design object associated with the
ICL object in the Hierarchical Schematic, if a mapping from the ICL object to a hierarchical design
object exists.

• Copy name(s) — Copies the name of the selected ICL object to the system clipboard.

Context Tables
The ICL Instance Browser includes two context tables: one for the ICL instance pins, and another for
the ICL scan interfaces. These interactive tables display information about the ICL objects. You can use
these tables to select and manipulate these objects. Use the Columns and Filters editor to control the
information that is displayed in these tables.

Related Topics
Search Features

Cell Library Browser

Use the Cell Library Browser to debug test coverage and fault coverage loss from the perspective of
library cells.
The Cell Library Browser consists of two panes:

900 Tessent™ Shell User’s Manual

 Tessent Visualizer
DRC Browser

• Left Pane — Lists the available cell libraries. This pane can include data such as the module
name, statistics including the number of instances in the design, and fault coverage.

• Right Pane — Shows the instantiations of those library cells in the design. You can add columns
to display data such as the attributes of those instantiations, the hierarchical name, the parent
module, and fault information.

Figure 273. Cell Library Browser

Click in a row in the left pane to show the instantiation information for that cell type in the right pane.
Right-click an instance name in the table in the right pane to get access to all actions available for
hierarchical instances.

Related Topics
Search Features

DRC Browser
The DRC Browser is a tabular reporting tool for exploring the rule violations in your design and ICL data
models. Customize the browser to group and filter DRC violations by various criteria.
The DRC Browser consists of two panes. The left pane enables you to group the violation list by rule
name (the default), instance, or module.
The right pane shows specific information about the violations associated with the rule, instance, or
module selected in the left pane, such as:

Tessent™ Shell User’s Manual 901

Tessent Visualizer
DRC Browser

• Violation name

• Description of the violation

• Indication of whether the violation is visualizable

If nothing is selected in the left grouping table, the right table displays all violations currently registered in
Tessent Shell.

Figure 274. DRC Browser With Data Grouped By Rule

If you group by instance or module, data for the violations in the selected instance or module is displayed.
You can display the specifics for a visualizable rule violation in a schematic or the Text/HDL Viewer
by double-clicking a row in the right pane of the DRC Browser, or by right-clicking and choosing the
appropriate item from the popup menu. You cannot visualize all DRC violations.

Note:
This method is equivalent to issuing the analyze_drc_violation command on the Tessent Shell or
Transcript command line.

902 Tessent™ Shell User’s Manual

 Tessent Visualizer
DRC Browser

Figure 275. Flat Schematic Showing a DRC Violation

You can view the results of analyzing many ICL DRC violations in Tessent Visualizer by double-clicking
them in the DRC Browser window or using analyze_drc_violation on the command line.
The following DRC violations are visualized in the Text/HDL Viewer:

• ICL1-ICL28 (except ICL8 and ICL24)

• ICL92-ICL96

• ICL100

• ICL113

• ICL136
The following DRC violations are visualized in the ICL Schematic:

• ICL68

• ICL76

• ICL77

• ICL80

• ICL111

Tessent™ Shell User’s Manual 903

Tessent Visualizer
Config Data Browser

• ICL117-ICL119

• ICL134

• ICL140

Related Topics
analyze_drc_violation

Config Data Browser

The Config Data Browser enables you to view and edit configuration specification trees that are loaded in
the current Tessent Shell session.
The Config Data Browser includes a top toolbar and a dedicated tab for each top-level wrapper in the
configuration data that has been added for visualization in the GUI. Each tab has two panes, as shown in
Figure 276.

Figure 276. Config Data Browser

When you open the Config Data Browser with the Open menu action, no wrappers or tabs are displayed
unless a previous session was restored. Use the navigation bar in the top toolbar to add new tabs with
configuration trees. First, choose a partition from the Partition dropdown list in the toolbar. Then, choose a
wrapper by typing or pasting a hierarchical name in the navigation bar. You can use tab completion while
typing a wrapper name. If the wrapper has already been loaded into the GUI, the existing tab is raised
and the specified wrapper is selected. If the wrapper has not yet been loaded into the GUI, a new tab is
opened and the specified wrapper is selected in the tree view.
Alternately, you can use the add_config_tab command to open a configuration tree in the Config Data
Browser.
The tree view pane enables you to browse wrappers in the configuration hierarchy, and the table pane
displays the properties for the currently selected wrappers. The property table includes features common
to other tabular views in Tessent Visualizer such as filtering and exporting.

904 Tessent™ Shell User’s Manual

 Tessent Visualizer
Config Data Browser

Unspecified wrappers and properties with unspecified default values appear in gray text. User-specified
wrappers and properties appear in black text, unless there is an error. If an error is attached to a wrapper
or property, the text appears in red, and the parent wrappers of the node with the error appear in orange.
The "default" partition enables you to edit the configuration in the GUI. Right-click a property and choose
one of the options to edit it or copy its contents. You can also double-click a property name or a value
to open a popup to change the value. You can also use the context menu on a wrapper to add data
properties or repeatable properties to the wrapper, or to add new wrappers above as parents or below as
children of the wrapper, as shown in the following figure.

Figure 277. Wrapper Editing in the Context Menu

For PatternsSpecification, PatternsGroup, or Patterns wrapper trees, you can use the checkboxes next
to each wrapper to select only those wrappers that you want the tool to process or validate. The tool
displays a checkbox only next to processable wrappers. The following points explain the behavior of the
tree widget:

Tessent™ Shell User’s Manual 905

Tessent Visualizer
Config Data Browser

• If you do not select any wrapper, the tool processes or validates the root wrapper. This is the
default behavior.

• If you select at least one child wrapper, the tool indicates this partially-selected state using the
checkbox next to the parent wrapper. The tool can process or validate only one child wrapper at a
time.

• If you select or uncheck a parent wrapper, the tool updates the states of all the child wrappers to
match the parent wrapper.

• If you select or uncheck all the child wrappers, the tool updates the state of the parent wrapper to
match the state of the child wrappers.
Choose Set name(s) to change the names of named wrappers (ICLNetworkVerify is shown in the figure).
Other actions enable you to cut or copy and paste wrappers, delete wrappers, or move wrappers to new
positions. Use Specify and Unspecify with some wrapper types to mark them as user-specified or to
reset their properties to their default values, respectively.
The toolbar in the view pane for the wrapper tree includes several action buttons, as described in the
following table.

Table 41. Config Data Browser Buttons and Actions

Button Action

Validate — validates the correctness of the specified configuration. This

action is available for the DftSpecification and PatternsSpecification
wrappers. It is equivalent to running the process_dft_specification ‑validate or
process_patterns_specification ‑validate command in Tessent Shell.

Process/Execute — runs the same commands as the "Validate" action, except

that it excludes the "-validate" option. In SiliconInsight, also simulates the test
patterns. Refer to the Tessent SiliconInsight User’s Manual for details.

Diagnose — this is a SiliconInsight-specific action for the PatternsSpecification()

wrapper only. Refer to the Tessent SiliconInsight User’s Manual for details.

Clear status — this is a SiliconInsight-specific action for the

PatternsSpecification() wrapper only. Refer to the Tessent SiliconInsight User’s
Manual for details.

Configuration snapshot — saves a snapshot of the GUI configuration data for

the specified root wrapper. The current list of saved snapshots is available in the
dropdown list.

Export config data — saves the displayed configuration data to a file using the
write_config_data command.

Hide unspecified — removes all unspecified wrappers from the current view.

The tool stores a snapshot of the GUI configuration data for the root wrapper displayed in the Config Data

Browser. To save the current state of configuration, click and specify the snapshot name in the
dialog box that opens. The tool also automatically saves a snapshot of the current configuration whenever

906 Tessent™ Shell User’s Manual

 Tessent Visualizer
Config Data Browser
you click Validate or Process/Execute. In this case, the tool creates a concatenated name using the
action performed and the outcome of the action, and saves the configuration snapshot with this name.
The following figure demonstrates how the tool displays the current list of saved snapshots:

Figure 278. List of Configuration Snapshots

If you want to restore the GUI configuration to one saved previously, select the required configuration
from the dropdown list. The tool restores the Config Data Browser to the saved configuration. The
configuration you select becomes the latest saved configuration and moves to the top of the dropdown list
with its updated timestamp.
The tool can distinguish between the snapshots you save and the ones that are automatically saved. If
you try to save a snapshot of the current configuration and if the previously saved configuration is the
same, the tool updates the name and timestamp of the previously saved snapshot and moves it to the top
of the dropdown list.
The number of snapshots of each type per configuration tree is limited to 10. The tool removes the oldest
snapshot from the list once the limit is reached. The tool also deletes all saved snapshots when the
Tessent Visualizer session is closed (close_visualizer ‑server) or if the specified root wrapper is removed.

Related Topics
add_config_tab

delete_config_tabs

process_dft_specification

process_patterns_specification

report_config_data

Tessent SiliconInsight User’s Manual for Tessent Shell

write_config_data

Tessent™ Shell User’s Manual 907

Tessent Visualizer
RTL Metrics Browser

RTL Metrics Browser

Use the RTL Metrics Browser tab to display RTL metrics related to RTL designs. The tool generates the
RTL metrics before and after quick synthesis (with the report_rtl_complexity command), and after test
point analysis (with the "report_rtl_complexity -effort high" or analyze_test_points commands).

Figure 279. RTL Metrics Browser

The RTL Metrics Browser tab contains the following major elements:

• Tree View — Displays the instances in your design hierarchy that have their metrics calculated.

• Child instances table — Displays information about the metrics for children of the instance you
select in the Tree View or the Address Bar.

• RTL constructs table — Displays information about the subconstructs of the instance you select
in the Child instances table.

RTL Metrics Browser Toolbar

The toolbar for the RTL Metrics Browser tab has some additional buttons and checkboxes as described in
the following table.
For more information on the common table toolbar buttons, refer to Table 36.

Tip
Use the Columns and Filters Editor button to add or delete columns.

Table 42. Toolbar for RTL Metrics Browser

Button/Checkbox Action

Views Displays a dropdown list from which you can select one of the following
predefined views. When you switch between the views, the tool replaces the
currently displayed columns with a different set of columns.

908 Tessent™ Shell User’s Manual

 Tessent Visualizer
Context Menu Actions

Table 42. Toolbar for RTL Metrics Browser (continued)

Button/Checkbox Action
• Pre-synthesis metrics — Displays columns corresponding to the metrics
described in the "Code Complexity Metrics Pre-Synthesis" table
• Post-synthesis metrics — Displays columns corresponding to the metrics
described in the "Code Complexity Metrics After Synthesis" table
• Post-TPA metrics — Displays columns corresponding to the metrics
described in the "Code Complexity Metrics After Test Point Analysis"
table

Aggregate Mode Displays the same columns for the same instances in the Child
instances table except it displays the aggregate values in the columns.
The tool populates the table after running the "report_rtl_complexity
-aggregate_mode" command.

All Displays all subconstructs of the instance you select in the Child instances
table.

Code Complexity Displays all subconstruct objects that contribute to the code complexity
score of the instance you select in the Child instances table.

Visible Nets Displays all RTL Visible Nets objects that have test points in the instance
you select in the Child instances table. The tool populates this table after
performing test point analysis with the "report_rtl_complexity -effort high" or
"analyze_test_points" commands.

Expressions Displays all RTL Expression objects that have test points in the instance
you select in the Child instances table. The tool identifies test points at the
boundaries of, or inside, an expression object. If the test point is inside
an expression object, the tool displays it using the metrics associated
with the corresponding functional block. The tool populates this table after
performing test point analysis with the "report_rtl_complexity -effort high" or
"analyze_test_points" commands.

Control Statements Displays all RTL Control Statements objects that have test points in the
instance you select in the Child instances table. The test points can be
identified inside control statements declared in sequential context (process,
or function/task) such as if-then-else or case statements. The tool populates
this table after performing test point analysis with the "report_rtl_complexity
-effort high" or "analyze_test_points" commands.

Related Topics
analyze_test_points

report_rtl_complexity

Context Menu Actions

The RTL Metrics Browser tab supports context menus in the Child instances table, RTL constructs table,
and Tree View to perform a range of actions.
The context menu is similar to the one available for instance objects in the Instance Browser and
Hierarchical Schematic tabs and also includes the following actions that are specific to the RTL Metrics
Browser.

Tessent™ Shell User’s Manual 909

Tessent Visualizer
Transcript

Table 43. RTL Metrics Browser Context Menu

Option Description

Show RTL location Displays the location of the module, instance, or RTL object you select
in its respective Verilog file. The tool displays this Verilog file in the
Text/HDL Viewer tab.

Transcript
The Tessent Visualizer Transcript tab provides access to the Tessent Shell command line and a record of
commands used and responses to those commands.
Text in the Transcript is highlighted as shown in Figure 280:

• Green — informational notes

• Orange — warning messages

• Red — error messages

910 Tessent™ Shell User’s Manual

 Tessent Visualizer
Transcript

Figure 280. Transcript Tab With an Interactive Command Line

You can issue Tessent Shell commands directly from the Transcript, with the same features as the
standard Tessent Shell command line. (For example, command history using the up and down arrow
keys, command completion using the Tab key, and multi-line commands.) Commands are syntactically
highlighted as you type them.
Press Ctrl+Enter to enable multi-line command mode. The background color of the command entry box
changes to light blue to indicate that multi-line command mode is active. Use Shift+Enter to insert a new
line and the arrow keys to navigate over the multi-line command. Multi-line commands can be recalled
with the up-arrow and edited as shown in Figure 280.

Tessent™ Shell User’s Manual 911

Tessent Visualizer
Wave Viewer

Wave Viewer
Use the Tessent Visualizer Wave Viewer tab to debug and analyze Test Setup and Test End data. This
tab displays the Test Setup and Test End data as waveforms with their corresponding signal values
over time. The Wave Viewer tab contains a toolbar, a signal pane, and a generic plotting widget. It also
provides an option to export the waveform data to Value Change Dump (VCD) files. You can use these
VCD files with other waveform viewers to further analyze and validate the behavior of your design.

Note:
To use the Wave Viewer tab, it is necessary to have a flat model of the design. For any
hierarchical pins, the flat model must include their equivalent pins.

To open the Wave Viewer tab, right-click the pins of a hierarchical or flat schematic. From the context
menu that appears, select Add to Wave Viewer. Additionally, you have the option to add pins to the
Wave Viewer from various sources such as search tabs, the Instance Browser, or from context tables that
display pins or gate pins. When adding pins individually to Wave Viewer, use the Add to Wave Viewer
option. If any of the selected pins are either a bus or a bi-directional pin, the Add to Wave Viewer as
option is enabled. The Add to Wave Viewer option is also available to add all the signals for an element
of type "Instance", such as a library cell or a flat gate, from schematics and tables.
In addition, there are two more ways to open the Wave Viewer. First, you can use the
add_wave_viewer_signals command to open the Wave Viewer and add signals directly. This command
enables you to specify the specific signals you want to view in Wave Viewer. Second, you can access the
Wave Viewer directly from the dropdown menu in the Tessent Visualizer window. Click the Open menu
and select the option to open the Wave Viewer.

Figure 281. Wave Viewer

In the Wave Viewer toolbar (refer to “Wave Viewer Toolbar” on page 913), you can select either the Test
Setup or Test End procedure. If the Test Setup or Test End procedure is not loaded into Tessent Shell,
but there is a flat model, you can still add signals to the list, but there is no data on the plots. The tool
automatically switches to the None option and displays a warning message on the toolbar.
After you have chosen the desired procedure, you can export the waveform data to a VCD file or a dofile.
Use the "Export Wave Viewer data" option in the toolbar to create a dofile that you can use to restore the
pins that are currently displayed in the Wave Viewer tab.
Right-click a set of signal names in the left pane to access a context menu. This menu displays a list
of supported actions that you can choose from to perform various operations on the selected signals.
refer to Table 45 on page 914 for a detailed list of the available actions. You can also use the keyboard
shortcuts and mouse actions described in “Keyboard Shortcuts” on page 931.

912 Tessent™ Shell User’s Manual

 Tessent Visualizer
Wave Viewer Toolbar

To remove specific signals from the Wave Viewer, select the signals you want to delete and then
utilize the delete actions found in the Wave Viewer toolbar. You could also right-click a set of
signals and delete them from the signal pane using the context menu. Another option is to use the
delete_wave_viewer_signals command.
The following topics provide more information about the specific actions that the tool can perform in the
Wave Viewer tab:

Wave Viewer Toolbar

Context Menu Actions

Wave Viewer Toolbar

You can instruct the tool to perform specific actions in the Wave Viewer tab using the Wave Viewer
toolbar.

Table 44. Wave Viewer Toolbar

Button Description

None/Test Choose whether to use the test setup or the test end procedure. If there is no
Setup/Test End simulation data present, the tool sets this option to "None".

Fits all waveforms to view their full range.

Zoom in on the active cursor by a factor of 2x.

Zoom out on the active cursor by a factor of 2x.

Zoom in the region between the C1 and C2 cursors.

Deletes the selected signals.

Deletes all signals.

Moves the active cursor to the previous transition for the selected signals.

Moves the active cursor to the next transition for the selected signals.

Displays the current position of Cursor 1. Use the range field to move C1 to a
different location. The range displayed varies based on the data loaded into
Wave Viewer. Click C1 to highlight or select it.

Displays the current position of Cursor 2. Use the range field to move C2 to a
different location. By default, C2 is set at 0 ns. Click C2 to highlight or select it.

Calculates and displays the absolute distance between the C1 and C2 cursors.

Export Wave Viewer data to a VCD file or dofile.

Displays the hierarchical path name for each signal.

Tessent™ Shell User’s Manual 913

Tessent Visualizer
Context Menu Actions

Context Menu Actions

The left signal pane in the Wave Viewer tab supports a context menu with the following actions.

Table 45. Wave Viewer Context Menu

Option Description

Show on Displays the selected signal on the Hierarchical Schematic. This option is
Hierarchical available only if you select a hierarchical pin.
Schematic

Show on Flat Displays the selected signal on the Flat Schematic.

Schematic

Insert separator Adds a separator below the currently selected signals. The separator acts
as a visual marker for grouping between signals. You can drag and place the
separator at any location within the signal list. A separator name can contain
only alphanumeric, hyphen (-), and underscore (_) characters.

Label Edits the name of the currently selected signal to a name you specify. You
cannot edit the name of the test procedure <cycles> and individual bus
pin signals. A label name can contain only alphanumeric, hyphen (-), and
underscore (_) characters.

Group Groups selected signals. You cannot group signals that belong to a different
group or a bus, the test procedure <cycles> signal, or separators. A group name
can contain only alphanumeric, hyphen (-), and underscore (_) characters.

Ungroup Ungroups signals from selected groups. The ungrouped signals then appear in
the signals list in the order they were present within the groups.

Radix Sets the default radix for a selected signal. The radix for each signal can be
binary, octal, decimal, or hexadecimal. This option is available only if you select
a bus signal or the cycles signal.

Color Sets a color for the selected signal. This option is available even if you select
multiple signals. The tool colors an x-value signal red, and a z-value signal blue
by default. The test procedure <cycles> signal is displayed in yellow color.

Delete Selected Deletes selected signal. You cannot delete a subset of signals of a bus pin or
the test procedure <cycles> signal.

Copy name(s) Copies the names of the selected signals. This action creates a Tcl list in the
system clipboard that can be pasted elsewhere.

Text/HDL Viewer
The Text/HDL Viewer enables you to examine the HDL description of your design or cell library. The text
displayed in this window includes syntax highlighting, and can be copied to the system clipboard for use
elsewhere.
Open the Text/HDL Viewer by right-clicking objects in the Instance Browser, Cell Library Browser, or a
schematic and choosing Show HDL definition or Show HDL instantiation from the popup menu. Figure
282 shows the Text/HDL Viewer for an object with the appropriate line in the HDL highlighted where the

914 Tessent™ Shell User’s Manual

 Tessent Visualizer
IJTAG Network Viewer
definition or instantiation was found. These actions are available on any hierarchical instance, including
library cells, and any table that lists these instances.

Figure 282. Text/HDL Viewer

The files opened by the Text/HDL Viewer display on tabs at the bottom of the viewer. To open the current
file in an external text editor, right-click the tab and choose Open in external editor from the popup
menu. Use the Tessent Visualizer Preferences dialog box to specify the external text editor.
To copy the file path of the current file to the system clipboard, right-click the tab and choose Copy file
path from the popup menu.

Note:
When Tessent Shell is in the "dft -rtl" context, you can select a text object in the viewer and
display it in the Hierarchical Schematic. To do so, select a text fragment, right-click, and choose
Show on Hierarchical Schematic.

IJTAG Network Viewer

The IJTAG Network viewer enables you to navigate and introspect the ICL network in a schematic
window. The schematic shows a simplified topological view.
The IJTAG Network viewer includes a SIB tree view on the left side of the window and a schematic view
in the center of the window. Navigate the schematic with the toolbar, address bar, and the tracer context
table, which are similar to those in other types of schematic windows.

Tessent™ Shell User’s Manual 915

Tessent Visualizer
IJTAG Network Viewer

Figure 283. IJTAG Network Viewer

The SIB tree in the left pane displays a hierarchical view of the SIB instances in the network. Select an
instance in the SIB tree and choose Show on IJTAG Network from the right-click popup menu to display
it in the schematic view. The IJTAG Network viewer also includes a schematic overview (similar to the
overview in the Flat and Hierarchical Schematics) and a table of attributes for the selected instance in the
right pane. The right pane is collapsed by default. Expand it to observe the schematic overview and the
attributes table.
Select an instance in the IJTAG Network viewer and choose Show on ICL schematic from the right-
click context menu to display it in the ICL Schematic. You can also choose Trace to scan input, Trace
to scan output, and Trace backward from this menu. When you select an instance, the IJTAG Network
viewer also highlights the parent SIB of the selected instance in the SIB tree.
Select a "from_so" pin on a SIB instance in the IJTAG Network viewer. Right-click and choose Expand
SIB ring from the context menu to show the associated IJTAG nodes hosted by the SIB. The tool traces
scan paths from the "from_so" and "si" pins on the SIB to find the closest common point and displays
these scan paths with the IJTAG nodes that belong to those paths.
You can also trace to scan inputs and outputs by selecting an instance in the SIB tree and using the right-
click context menu.
Hover the mouse pointer over a mux symbol in the IJTAG Network viewer to display the select values, as
shown in Figure 284. The tool also displays the active mux input with < on the symbol.

916 Tessent™ Shell User’s Manual

 Tessent Visualizer
IJTAG Network Viewer

Figure 284. Mux Select Values and Active Input

Use the Options button ( ) in the toolbar to set options unique to the IJTAG Network:

• Collapse scan registers — Select this option to collapse the scan registers. This is similar to
Collapse buffers/inverters in the Hierarchical or Flat Schematics. Refer to "Buffer and Inverter
Collapsing on page 859" for further information.

• Show simulation values — Select this option to display simulation values in the IJTAG Network
viewer. Hover the mouse pointer over the callout associated with a shift register to view the
simulation values, as shown in Figure 285.

Figure 285. Simulation Values in IJTAG Network Viewer

Tessent™ Shell User’s Manual 917

Tessent Visualizer
IJTAG Network Viewer

• Highlight scan path — Select this option to display the Highlight Scan Path toolbar as shown in
Figure 283 on page 916. Use this toolbar to select the current top interface with its scan chain.
This toolbar provides GUI access to the set_icl_network -top_client_interface and set_icl_network
-current_scan_chain_number commands, which are available in the patterns -silicon_insight sub-
context.
Choose a scan path highlighting type:

◦ last used — Highlights the scan path determined when the iApply command was most
recently run.

◦ network end state — Highlights the scan path determined when the close_pattern_set
command was run. If you have not run close_pattern_set, the scan path is not highlighted.
The highlighted path is an IJTAG data path. The value of the -network_end_state switch for
the close_pattern_set command affects the highlighting of the scan path. Refer to the Tessent
Shell Reference Manual for details.
If the close_pattern_set command is run immediately after the iApply command and without
the -network_end_state switch (or with the default value of that switch), the "network end
state" choice behaves like the "last used" choice. An exception to this is when the iApply
affects only the instruction path.
Use the Show SI and Show SO buttons to show respectively the scan-in or scan-out port of the
currently selected scan interface.
When you highlight SIBs in the IJTAG Network Viewer directly or with the add_schematic_objects
‑highlight options, the corresponding entry in the SIB tree is also highlighted as shown in Figure 286.

Figure 286. Highlighting SIBs in the IJTAG Network Viewer

918 Tessent™ Shell User’s Manual

 Tessent Visualizer
iProc Viewer

iProc Viewer
The Tessent Visualizer iProc Viewer is similar in form and function to the Tessent Visualizer Text/HDL
Viewer, with additional features.
Choose the ICL module and iProc from the table to the left of the viewer pane as shown in Figure 287.
To show iProcs in the viewer pane, select one or more rows in the table, right-click, and choose Show in
iProc Viewer. Alternately, drag the selected row or rows from the table into the viewer pane.
The iProc Viewer features color syntax highlighting and a find function similar to the Text/HDL Viewer.

Figure 287. iProc Viewer

To display data about the iProc, hover the mouse pointer over its tab in the viewer as shown in Figure
288.

Figure 288. iProc Viewer Tooltip

If the filepath of the iProc is available, and the file is accessible on disk, you can right-click the tab and
open the iProc in an external editor.

Tessent™ Shell User’s Manual 919

Tessent Visualizer
Diagnosis Report Viewer

Diagnosis Report Viewer

Use the Diagnosis Report Viewer to open reports created with the write_diagnosis command.
Open the Diagnosis Report Viewer by choosing the Open > Diagnosis Report Viewer menu item. Then
you can open a diagnosis report using the toolbar at the top of the Diagnosis Report Viewer or by issuing
the display_diagnosis_report command. You can open multiple reports using either of these methods.
Select either text view or table view mode from the same toolbar.
In text view mode (Figure 289), the diagnosis report opens in the window, annotated with hypertext links
for each design object affected. These links refer to the following:

• Symptoms

• Suspects

• Sub-suspects

• Pin and net objects associated with suspects

You can click a link to show the indicated object in the Hierarchical Schematic. Right-click to display a
popup menu for other actions available to examine these objects.

920 Tessent™ Shell User’s Manual

 Tessent Visualizer
Diagnosis Report Viewer

Figure 289. Diagnosis Report Viewer (Text View)

Figure 289 also shows text searching in the Diagnosis Report Viewer.
Figure 290 shows the three panes of the tabular layout for the diagnosis report. The left pane is a list
of the symptoms denoted with integer IDs. Select a symptom in this pane to display a list of suspects in
the right top table. Double-click an object in the table, or right-click and choose Show on Hierarchical
Schematic, to show it in the Hierarchical Schematic. If a suspect has sub-suspects, the bottom table
displays a list of sub-suspects.

Tessent™ Shell User’s Manual 921

Tessent Visualizer
Search Features

Figure 290. Diagnosis Report Viewer (Table View)

Search Features
The Tessent Visualizer GUI provides multiple search features.

• From the main menu bar, open the Search menu to search for instances, pins, gate pins, or
specific ICL object types in your design. You can also search for iProcs or configuration elements
currently defined in the Tessent Shell session.

• For browser tabs, you can directly open the related search tab using the Search button in the
toolbar.

• You can also use the Ctrl+F shortcut from browser tabs to open related search tabs; the tool
opens the search tab matching the table currently in focus.

Instances
Figure 291 shows a search for all instances in the design with module names that begin with the string
nor.

922 Tessent™ Shell User’s Manual

 Tessent Visualizer
Search Features

Figure 291. Search Tab: Instances

Pins
Figure 292 shows a search for all hierarchical pins with the string mode in the pin name.

Note:
The search for pins in a large design can be time consuming because the tool searches across all
hierarchical instances and their pins.

Figure 292. Search Tab: Pins

Gate Pins
Figure 293 shows a search for flat pins (gate pins) that have a hierarchical pin with a leaf name of Q
below the bsr_i1 instance.

Tessent™ Shell User’s Manual 923

Tessent Visualizer
Search Features

Figure 293. Search Tab: Gate Pins

ICL Search Functions

You use Search > Search - ICL Instances in the same way you use Search > Search - Instances for
the hierarchical design model, and Search > Search - ICL Pins the same way as you use Search >
Search - Pins for the hierarchical design model.

Figure 294. ICL Instances Search

You can select one or more rows in a filtered search table. Then, use the right-click popup menu to
show those objects in a schematic, add them to the pin data (pin searches), or show the HDL definition
(instance searches).

Note:
The display properties for Search Instances and Search Pins are based on the Hierarchical
Schematic. The display properties for Search Gate Pins are based on the Flat Schematic.

You can search for ICL aliases in a similar fashion with Search > Search - ICL Aliases.
Refer to “Tessent Visualizer Components and Preferences” on page 838 for information about interacting
with these tables in Tessent Visualizer.

924 Tessent™ Shell User’s Manual

 Tessent Visualizer
Search Features

iProc Search Functions

Use Search > Search - iProcs to search for available iProcs. You can filter the column data just as you
do with the other search functions.

Figure 295. iProc Search

To view iProcs from the iProc Search window, select one or more rows, right-click them, and choose
"Show in iProc Viewer." Alternately, drag and drop the rows into the iProc Viewer.

Config Properties
Use Search > Search - Config Properties to find a particular configuration property or wrapper path in
the currently loaded configuration. Scroll through the list of wrapper paths and properties or use filtering to
find the path and property of interest. Use the right-mouse-button context menu as shown in the following
figure to set the property value or to reset it to its default value, to change the name of a named wrapper,
or to show the wrapper path in the Config Data Browser.
Refer to “Config Data Browser” on page 904 for more information.

Tessent™ Shell User’s Manual 925

Tessent Visualizer
Search Features

Figure 296. Config Data Search

RTL Metrics
Use Search > Search - RTL Metrics to search through all RTL metrics of the instances in your design
hierarchy. You can also switch between the predefined views using the Views button in the toolbar. Right-
click on any table cell to access the context menu and choose from a range of actions as shown in the
following figure. Refer to “RTL Metrics Browser” on page 908 for more information.

Figure 297. RTL Metrics Search

926 Tessent™ Shell User’s Manual

 Tessent Visualizer
Using Tessent Visualizer to Debug Design Issues

Related Topics
iProc Viewer

Using Tessent Visualizer to Debug Design

Issues
You can use Tessent Visualizer to solve various design problems. You can view state elements or
observation points from a pin fanout, add or hide pins on an instance in the hierarchical schematic, search
for pins by name, trace the bits of a bus, and debug issues by viewing simulation waveforms on pins.

Procedure
Perform any of the following actions:

If you want to... Do the following:

List all state elements in the 1. Click a pin in a schematic.

fanout of a pin.
The Tracer table displays below the schematic.
2. Click the "Strategy:" dropdown list and select "Nearest state element."
The Tracer table lists all the state elements and the distance from the
source in terms of number of pins in the traced path. The pin count for
the same traced path is higher in the Hierarchical Schematic than in the
Flat Schematic because of additional pins on hierarchical boundaries.

Add pins to an instance on a 1. Select an instance on a Hierarchical Schematic, then click the Pins
hierarchical schematic. button.
A table listing the pins on the selected instance displays.
2. Click the Pins button below the schematic to display a table listing the
pins on the selected instance.
3. Use the filter feature to search for the pin you want.
4. Add the pin to the schematic by double-clicking or by dragging it onto
the schematic.

Search for pins by name. 1. Choose the Search > Search - Pins menu item.
2. Filter or sort the list of pins as needed.
3. Right-click the pin name of interest in the table and choose one of
these menu items to display the pin in a schematic:
• Show on Hierarchical Schematic
• Show on Flat Schematic

Debug test setup or test end 1. Select one or more pins on a flat/hierarchical schematic.
issues using a waveform viewer. 2. Right-click the selected signals and choose Add to Wave Viewer
from the popup menu.
This displays the selected signals in the Wave Viewer tab.

Tessent™ Shell User’s Manual 927

Tessent Visualizer
Using Tessent Visualizer to Debug Design Issues

If you want to... Do the following:

Trace a single bit of a bus. When tracing a single bit of a bus, the bit remains split from the bus.
When tracing a net that recombines into a bus, the bit indices display in
the schematic when you hover the mouse pointer, over the split point as
shown in the following figure:

Results
Listing all state elements in the fanout of a pin: the Tracer table lists all the state elements and the
distance from the source in terms of number of pins in the traced path. The pin count for the same traced
path is higher in the Hierarchical Schematic than in the Flat Schematic because of additional pins on
hierarchical boundaries.
Adding pins to an instance in a hierarchical schematic: when you add an instance to a schematic
directly or by tracing to it, the schematic displays only the pins that have connections (except for cases
where there are very few pins in total). This feature simplifies the schematic to focus on pins of interest,
improving run time.

Examples

Searching for Pins by Name

The following figure shows a search for the "qai" bus, and subsequent selection of an element of that bus,
which is displayed in the hierarchical schematic. You can then trace the signal.

928 Tessent™ Shell User’s Manual

 Tessent Visualizer
Accessing Tutorials for Tessent Visualizer

Figure 298. Searching by Name

Tracing a Single Bit of a Bus

When tracing a single bit of a bus, the bit remains split from the bus. When tracing a net that recombines
into a bus, the bit indices display in the schematic when you hover the mouse pointer, over the split point
as shown in the following figure:

Related Topics
Nearest State Element Tracing Strategy

Wave Viewer

Accessing Tutorials for Tessent Visualizer

Tutorial instructions and design data are available for download in an Example Kit (eKit) file. The tutorials
demonstrate some basic operations you can perform with Tessent Visualizer. The eKit is a ZIP file
containing the instructions and design data that you need to perform the Tessent Visualizer tutorials.

Tessent™ Shell User’s Manual 929

Tessent Visualizer
Accessing Videos for Tessent Visualizer

Procedure
1. Log on to Support Center:
https://support.sw.siemens.com

2. Find the Tessent product page.

3. Click the Documentation link in the page banner.

4. Use the "Restrict content to version" dropdown list to specify the current Tessent version.

5. Click the Getting Started Guide in Document Types on the left side of the page.

6. Click the link for "Try It: Tessent Visualizer Quick Start and Example Kit Design Data."

This downloads the eKit ZIP file to your default location.

7. Move the downloaded file to a working directory that you can access with a Linux shell.

8. From a Linux shell, unpack the download file:

$ unzip <path>/tesvis_qs_ekit.zip

9. Navigate to the tesvis_qs_ekit/Docs directory and open the tesvis_quickstart.pdf file.

This file contains instructions for performing the tutorials.

Results
You are now ready to perform the Tessent Visualizer tutorials.

Accessing Videos for Tessent Visualizer

Getting Started with Tessent Visualizer is a set of two videos that show some basic operations you can
perform with Tessent Visualizer.

Part 1: Analyzing and Improving Test Coverage demonstrates how to analyze test coverage and explore
areas of the design that need coverage improvement:

• Invoking Tessent Visualizer

• Using the Instance Browser to navigate a design

• Adding data columns to a table

930 Tessent™ Shell User’s Manual

 Tessent Visualizer
Keyboard Shortcuts

• Sorting and filtering data

• Examining DRC violations and locating a violation on a schematic

• Using the Cell Library Browser to examine a library module

Part 2: Troubleshooting Problems With Verilog Design Files shows how to troubleshoot a problem with a
Verilog design file, which includes the following operations:

• Examining the source of a DRC violation on a schematic

• Troubleshooting an error with scan chain insertion

• Tracing a signal path on a schematic

• Recognizing problems on a schematic and locating the problem source in HDL code

• Determining the number of times a library module is instantiated in a design

Keyboard Shortcuts
A number of keyboard shortcuts are available for Tessent Visualizer.

Table 46. Global Shortcuts

Shortcut Action

Ctrl+Shift+H Open/Show Hierarchical Schematic

Ctrl+Shift+B Open/Show Instance Browser

Ctrl+Shift+F Open/Show Flat Schematic

Ctrl+Shift+W Open/Show Waveform Generator

Ctrl+Shift+I Open/Show ICL Schematic

Ctrl+Shift+J Open/Show ICL Instance Browser

Ctrl+Shift+T Open/Show Transcript

Tessent™ Shell User’s Manual 931

Tessent Visualizer
Keyboard Shortcuts

Table 46. Global Shortcuts (continued)

Shortcut Action

Ctrl+Shift+G Open/Show Gate Report Settings dialog

F12 Open Preferences dialog

Ctrl+Tab Go To next tab

Ctrl+Shift+Tab Go to previous tab

Ctrl+W Close current tab

Ctrl+Q Quit Tessent Visualizer

Ctrl+S Save/Export

Table 47. Schematic Shortcuts

Shortcut Action

Ctrl+0 Zoom all

Ctrl++ Zoom in

Ctrl+- Zoom out

Ctrl+Z Undo

Ctrl+Shift+Z Redo

Ctrl+A Select all

Ctrl+M Mark with chosen color

Del Delete selected

Esc Clear selection

Table 48. Config Browser Shortcuts

Shortcut Action

F2 Set name

Table 49. Instance Browser Shortcuts

Shortcut Action

Enter Go down in hierarchy

Backspace Go up in hierarchy

932 Tessent™ Shell User’s Manual

 Tessent Visualizer
Keyboard Shortcuts

Table 49. Instance Browser Shortcuts (continued)

Shortcut Action

Arrow Keys Move to the chosen cell

Table 50. Filter Editing Shortcuts

Shortcut Action

Tab Next filter

Shift+Tab Previous filter

Enter Accept filters

Esc Discard changes to the current filter

Table 51. Text Search Shortcuts

Shortcut Action

Ctrl+F Open text find function

Esc Close text find function

F3 Find next

Shift+F3 Find previous

Table 52. Wave Viewer Shortcuts

Shortcut Action

Ctrl+H Show hierarchical names

F2 Set label

Ctrl+0 Zoom fit

Ctrl++ Zoom in

Ctrl+- Zoom out

Table 53. Wave Viewer Mouse Shortcuts

Shortcut Action

Ctrl+Scroll up Zoom in on the active cursor by a factor of 2x

Ctrl+Scroll down Zoom out on the active cursor by a factor of 2x

Shift+Scroll up Scroll the signals listed vertically in the upward direction

Tessent™ Shell User’s Manual 933

Tessent Visualizer
Keyboard Shortcuts

Table 53. Wave Viewer Mouse Shortcuts (continued)

Shortcut Action

Shift+Scroll down Scroll the signals listed vertically in the downward direction

934 Tessent™ Shell User’s Manual

 Chapter 13
Timing Constraints (SDC)
This chapter describes the Synopsys Design Constraints (SDC) file generated by Tessent Shell and how
you use it to constrain the test mode of the Embedded Test hardware generated by the tool.

Generating and Using SDC for Tessent Shell Embedded Test IP

SDC File Generation With Tessent Shell
SDC Design Synthesis With Tessent Shell
Running Layout With Tessent Shell DFT
SDC for Modal Static Timing Analysis
VHDL and Mixed Language Designs
SDC File Contents
Example Scripts Using Tessent Tool-Generated SDC

Generating and Using SDC for Tessent Shell

Embedded Test IP
We guide you through an example SDC flow, from generation of the Tessent SDC file, through adjusting
the variables used within the file, to using it in your design synthesis.
First, you learn how to generate an SDC file for your design, which may be at the chip or the physical
block level. SDCs for sub blocks are automatically merged by Tessent with the constraints of their parent
physical block.
Then we show you how to adjust variables in the SDC file to match your particular synthesis setup or
requirements. There is no need however, to ever directly edit the generated SDC files.
Next, you observe how to use the generated SDC file in a step-by-step example synthesis flow, followed
by additional notes on Static Timing Analysis (STA), mixed-language and VHDL specific issues.
Key SDC procs are then explained. These procedures are used by Tessent instruments (like MBIST or
OCC) or maybe useful to use in your own synthesis scripts.
“Example Scripts Using Tessent Tool-Generated SDC” on page 979 shows examples of using and
adjusting Tessent SDC files in third-party synthesis and STA environments.
Note: The SDC described in this manual is to be used in conjunction with your functional SDC for the
synthesis of your design after Tessent Shell RTL insertion and the static timing analysis of your design
after synthesis. The Tessent Shell gate insertion flow uses a different set of SDC constraints during the
run_synthesis command, but the generated SDC should still be used for layout.

SDC File Generation With Tessent Shell

You generate your design SDC file using Tessent Shell.
In the standard Tessent Shell flow, the tool creates the SDC for the current design when you run the
extract_icl command, which does the following:

Tessent™ Shell User’s Manual 935

Timing Constraints (SDC)
SDC File Generation With Tessent Shell

• Stores the SDC in Tcl procs

• Writes the SDC to a single file named design_name.sdc, where design_name is the name of the
current design loaded in Tessent Shell
The SDC file is located next to the extracted ICL, which is typically in the dft_inserted_designs directory
as follows:

${tsdb}/dft_inserted_designs/${design_name}_${design_id}.dft_inserted_design

Every instrument type (for example, MBIST, IJTAG) of the current design and all sub-blocks that provide
SDC constraints are represented by a separate proc in the SDC file. Constraints for logictest-related
instruments such as OCC, EDT, or LBIST, including logictest-related DFT signals, are all grouped under
similar placeholder "ltest" instrument procs.
There is no need to call each instrument’s individual SDC proc. Tessent Shell provides user procs, which
are customized to call all relevant SDC procs for your design.
If you encounter a problem with SDC generation preventing ICL extraction, you can temporarily skip SDC
generation by using the following command options:
extract_icl -skip_sdc_extraction

To regenerate your SDC file for a given design and to take advantage of changes in the SDC constraints
in a newer version that does not reflect a hardware change, you can extract the SDC of your design
without running ICL extraction by loading the design’s full view and running the Tessent Shell extract_sdc
command. You should load the interface view of all physical blocks of your design. For example:
read_design <design_name> -design_identifier <design_id> -view full
extract_sdc

When it is time to use the SDC, locating your SDC file requires the following:

• Your latest TSDB location for the design you want to synthesize/analyze.

• Your design’s name.

• The design_id of the latest insertion pass of your design.

For example, if your design "myChip" used only a single TSDB directory, the default "tsdb_outdir", then
your SDC files would be located in the following places:

• For the processed DftSpecification(myChip,rtl1):

tsdb_outdir/dft_inserted_designs/myChip_rtl1.dft_inserted_design/myChip.sdc

• For the processed DftSpecification(myChip,rtl2):

tsdb_outdir/dft_inserted_designs/myChip_rtl2.dft_inserted_design/myChip.sdc

936 Tessent™ Shell User’s Manual

 Timing Constraints (SDC)
SDC File Generation With Tessent Shell

Note:
The latest SDC file is always a superset of the previous one. If you use a two-pass flow, you only
need to load the latest file.

Tessent™ Shell User’s Manual 937

Timing Constraints (SDC)
SDC Design Synthesis With Tessent Shell

SDC Design Synthesis With Tessent Shell

What follows is a list of steps you must follow during your synthesis flow to properly handle Tessent
Embedded Test IP. We use a non-modal approach to constrain the inserted test logic. This means that we
let both functional and test clocks through muxes and we do not set any constant anywhere. This lets the
synthesis tools optimize both the functional and test timing paths simultaneously.
The following steps are run after you have loaded the functional design and applied functional SDC.
These steps do not describe the entire flow, but, rather, only highlight typical steps affected by the
presence of Tessent IP. Design Compiler commands are used as an example. Refer to “Example Scripts
Using Tessent Tool-Generated SDC” on page 979 for complete example scripts.

Preparation Step 1: Sourcing SDC File

Preparation Step 2: Setting and Redefining Tessent Tcl Variables
Preparation Step 3: Verifying the Declaration of Functional Clocks
Preparation Step 4: Redefining Other Tessent Tcl Variables
Synthesis Step 1: Applying the SDC Constraints
Synthesis Step 2: Preparing the DFT Logic for Synthesis
Synthesis Step 3: Synthesizing Your Design
Synthesis Step 4: Writing Out Your Final SDC
Synthesis Step 5: Writing Out Your Final Netlist

Preparation Step 1: Sourcing SDC File

The first step is to source the Tessent Shell tool-generated SDC file, associated to the last insertion pass,
from within your synthesis script. We suggest creating central variables for the TSDB location and design
name:

set design_name myChip

set tsdb ../../../golden_repo/${design_name}_tsdb
set design_id rtl2
source
${tsdb}/dft_inserted_designs/${design_name}_${design_id}.dft_inserted_desi
gn/${design_name}.sdc

Preparation Step 2: Setting and Redefining Tessent

Tcl Variables
The Tessent Shell tool-generated SDC file makes extensive use of Tcl variables. This section discusses
the redefinition of those variables
Their definitions are contained in the proc tessent_set_default_variables. You must call this procedure
to set all Tessent variables to their design dependent default value. All other Tessent SDC-related procs
make use of these variables. This procedure call is mandatory:

tessent_set_default_variables

938 Tessent™ Shell User’s Manual

 Timing Constraints (SDC)
Preparation Step 2: Setting and Redefining Tessent Tcl Variables

Tessent SDC variables can and should be redefined to better suit your setup and design. For example,
you can change the TCK period from the default of 100.0ns to any value by redefining the variable
tessent_tck_period.

set tessent_tck_period 80.0

Note:
The value of tessent_tck_period might depend on the maximum tck clock frequency that can
be applied to the circuit. Refer to the "IJTAG Network Performance Optimization" section in the
Tessent IJTAG User’s Manual showing how to maximize the frequency of the IJTAG network test
clock.

You do not need to edit the Tessent Shell-generated SDC file, but rather use the set command in your
synthesis script to overwrite the value of the Tessent Shell tool-specific SDC variable tessent_tck_period.
Refer to “Example Scripts Using Tessent Tool-Generated SDC” on page 979 for synthesis script
examples.
For designs with Siemens EDA Logictest IP, you possibly need to update the global Tcl variables
that reproduce your fastscan test_proc timeplate specifications, so that your SDC constraints closely
match your simulation waveforms. For more information on these Tcl variables, refer to “LOGICTEST
Instruments” on page 956.
When the design contains LogicBIST instruments, create the shift_clock_src of the LogicBIST controller
and indicate its name to the SDC procs by using the tessent_lbist_shift_clock_src Tcl array variable.
Creating this clock and setting its name with the tessent_lbist_shift_clock_src variable is mandatory.
Specify this variable as follows:
set tessent_lbist_shift_clock_src(lbist_inst<index>) clock_name

For example:
create_clock -name lbist_clock pll/clk_out_2 -period 20
set tessent_lbist_shift_clock_src(lbist_inst0) lbist_clock

If multiple controllers use the same clock, create the clock once only. However, you must still specify the
tessent_lbist_shift_clock_src variable for each controller with the same clock name. Starting at 0, specify
as many lbist_inst indices as the number of LogicBIST controllers in the current design level minus one.
For example, for a design with two LogicBIST controllers, set the tessent_lbist_shift_clock_src(lbist_inst0)
and tessent_lbist_shift_clock_src(lbist_inst1) variables.
You can find the mapping of the lbist_inst<index> identifier to the instance path name of the LogicBIST
controllers in the tessent_lbist_mapping Tcl array variable inside the tessent_set_default_variables SDC
proc. When the clock is created with a different name than its source, specify the name of the clock as
specified with -name option of the create_clock SDC command. Existence of this Tcl variable and the
clock it refers to is rule checked by the generated SDC.
Similarly, when the design contains InSystemTest instruments, indicate the clocks to SDC by using the
tessent_ist_clock Tcl array variable. You can find the mapping from the ist_inst<index> identifier to the
InSystemTest controller instance path name in the tessent_ist_mapping variable.
Another key variable to possibly overwrite is the tessent_clock_mapping array explained in the next
section. Other, much less frequently used variables are discussed in “Preparation Step 4: Redefining
Other Tessent Tcl Variables” on page 941.

Tessent™ Shell User’s Manual 939

Timing Constraints (SDC)
Preparation Step 3: Verifying the Declaration of Functional Clocks

Preparation Step 3: Verifying the Declaration of

Functional Clocks
In Tessent Shell’s system mode ‘setup’, you may have specified asynchronous clocks, reference
clocks, and branch clocks. Some might be functional clock domain bases of some instruments, namely
MemoryBist, and they could be used in some timing constraints.
The tool stores this information in the tessent_clock_mapping array. It is defined in the generated SDC
file, within the proc tessent_set_default_variables, and has the following form:

array set tessent_clock_mapping {

<TessentShell ClockLabel> <FunctionalSDC ClockLabel>
[…]
}

This array is used by the Tessent Shell tool-generated SDC constraints to refer to your functional clocks.
They do so only through a remapped "tessent_clock_mapping(<TessentShell ClockLabel>)" array
element. By default, in tessent_set_default_variables, <TessentShell ClockLabel> and <FunctionalSDC
ClockLabel> are identical.

Note:
It is imperative that you examine this array and look for cases where this default mapping must be
updated. Overriding names are not necessary if you have used the -label option of the add_clocks
command in Tessent Shell to match the -name value in the SDC.

If you need to update one of the tessent_clock_mapping() array values, do so in your main synthesis
script, immediately after the call to the tessent_set_default_variables proc. For example, if you had a
clock defined with a label "CK25" in Tessent Shell, but in your SDC constraints the same clock is defined
with a name "PIN_CK25", you need to specify:

set tessent_clock_mapping(CK25) PIN_CK25

The new definition of tessent_clock_mapping(CK25) overrides the default one contained in

tessent_set_default_variables.
It is important to understand that you do not need to edit the Tessent-generated SDC file, but rather
use the ‘set’ command in your synthesis script to overwrite the value of the Tessent SDC variable array
element you want to change. Alternatively, if many of your Tessent defined clocks and respective SDC
clocks have different names, you might want to redefine a block of the array:

set tessent_clock_mapping(CLK25) pCLK25

set tessent_clock_mapping(CLK_PLL_REF) pCLK100

or

array set tessent_clock_mapping {

CLK25 pCLK25
CLK_PLL_REF pCLK100
}

940 Tessent™ Shell User’s Manual

 Timing Constraints (SDC)
Preparation Step 4: Redefining Other Tessent Tcl Variables

Note:
You do not need to define tessent_clock_mapping() entries for clocks that you have not specified
in Tessent Shell. Those are not used in the timing constraints.

Preparation Step 4: Redefining Other Tessent Tcl

Variables
The tessent_tck_period and tessent_clock_mapping array variables are the most important Tessent SDC
variables you should double check and overwrite as needed. Tessent SDC uses a number of additional
variables that are all defined and set to a default value in the tessent_set_default_variables proc.
For example, you can independently change the input and output delay (from the default, 25%
of the tessent_tck_period) or change the hierarchy separator character. Refer to the header of
the generated SDC file and the embedded comments in the tessent_set_default_variables proc,
explaining each such variable. Within the synthesis tool, you can use the Tcl command "info body
tessent_set_default_variables" to determine what variables are being defined.

Note:
The value of tessent_tck_period might depend on the maximum tck clock frequency that can
be applied to the circuit. Refer to the "IJTAG Network Performance Optimization" section in the
Tessent IJTAG User’s Manual showing how to maximize the frequency of the IJTAG network test
clock.

Synthesis Step 1: Applying the SDC Constraints

If you use Design Compiler, you need to set the variable "timing_enable_multiple_clocks_per_reg" to true.
This is needed to properly constrain MemoryBIST in the presence of MemoryBIST clock muxing.

set_app_var timing_enable_multiple_clocks_per_reg true

To apply the Tessent Shell-generated SDC constraints, run the merged non_modal proc:

tessent_set_non_modal

This Tessent SDC proc in turn calls all instrument non-modal procs as needed by your design and its sub-
blocks. There is nothing else for you to do than call this one proc to apply all non-modal SDC constraints.

Synthesis Step 2: Preparing the DFT Logic for

Synthesis
Once your design is loaded, you need to make sure to preserve instances of Tessent Shell-inserted
"persistent" cells and possibly instrument instances, depending on your downstream needs.
Refer to “Synthesis Helper Procs” on page 978 for more information on the different options.
Persistent cells should not be optimized as Tessent Shell SDC uses them as anchor points for layout and
STA, and different instances need to be preserved depending on if you do scan insertion with Tessent

Tessent™ Shell User’s Manual 941

Timing Constraints (SDC)
Synthesis Step 3: Synthesizing Your Design
Shell or more DFT insertion. Procs are provided in the .sdc file to generate a list of all instances that need
to be preserved in different ways: tessent_get_preserve_instances, tessent_get_optimize_instances, and
tessent_get_size_only_instances.
First you need to prevent boundary optimization of DFT objects using the proc
tessent_get_preserve_instances:

set_app_var compile_enable_constant_propagation_with_no_boundary_opt false

set preserve_instances [tessent_get_preserve_instances scan_insertion]
set_boundary_optimization $preserve_instances false
set_ungroup $preserve_instances false
set_app_var compile_seqmap_propagate_high_effort false
set_app_var compile_delete_unloaded_sequential_cells false

Then, because boundary optimization applies hierarchically, you re-enable boundary optimization of the
child instances of DFT objects using tessent_get_optimize_instances:

set_boundary_optimization [tessent_get_optimize_instances] true

Avoid inverting the logic signals of any Tessent IP instantiated in Tessent Shell. Signal inversion can
cause design rule checks of the gate-level netlist to fail or disrupt the ATPG flow. Find all the Tessent
sequential cells and turn off any output inversion by the synthesis tool.

set allETRegs [all_registers -edge_triggered]

set TessentETRegs [filter_collection $allETRegs "full_name =~ *tessent*"]
set_register_output_inversion $TessentETRegs false

Cells from your provided Tessent Cell Library instantiated in Tessent Shell must also be preserved but
can be resized to enable critical data path timing optimization during synthesis. You can get them using
tessent_get_size_only_instances:

set_size_only -all_instances [tessent_get_size_only_instances]

If your design contains shared bus assemblies, you can save significant area by ungrouping their content,
with the exception of the MemoryBIST controller. For examples of the suggested procedures, refer to the
Synthesis Step 2 portions in the “Example Scripts Using Tessent Tool-Generated SDC” on page 979.
For background information, refer to "Implementing MemoryBIST With Memory Shared Bus Interface" in
the Tessent MemoryBIST User’s Manual.

Synthesis Step 3: Synthesizing Your Design

You can now proceed with the compilation of your design:

link
check_design
compile -boundary_optimization [...]

Synthesis Step 4: Writing Out Your Final SDC

Use the write_sdc command after this step to export the merged SDC (Functional and Tessent Shell) for
use with your layout tool:

942 Tessent™ Shell User’s Manual

 Timing Constraints (SDC)
Synthesis Step 5: Writing Out Your Final Netlist

write_sdc ${design_name}.merged_sdc

Synthesis Step 5: Writing Out Your Final Netlist

You can now proceed with writing out your synthesized netlist.

write -format verilog -output ${design_name}.vg ${design_name} -hier

Running Layout With Tessent Shell DFT

There exist a few possible ways to apply your Tessent SDC constraints in layout.

Note:
This section uses the following convention to shorten proc names:
<ltest_prefix> := tessent_set_ltest

You can do either of the following:

• Use the SDC that you wrote out in previous synthesis Step 5 and feed it directly to your layout
tool, or

• Define all your functional SDC constraints and add Tessent DFT constraints, like you previously
did in synthesis, by repeating the steps:

◦ Define your functional constraints.

◦ Set your global Tcl Tessent variables.

◦ Call tessent_set_non_modal.
You also must preserve your Tessent DFT persistent cells from further layout logic optimization. Get the
list of these cells by calling your SDC file proc tessent_get_size_only_instances.
That is all you must do if your design does not feature Tessent logictest DFT. If you used 3rd-party scan
insertion tools, refer to their instructions as to how to constrain that mode. The rest of this section details
what you must do in layout with Tessent logictest DFT.

Clock Tree Synthesis With Tessent On-Chip Clock Controllers (OCCs)

If your design includes Tessent OCC IP, you may need to instruct your clock tree synthesis command to
stop balancing the inner flop clock pins of your OCC with the leaves of the functional domain clock tree
that the OCC controls. This balancing adds a significant amount of latency to the OCC flop clocks, which
causes a drastic reduction to the setup margin of the internal fast_clock_en and slow_clock_en timing
paths of the OCC to the OCC clock gaters at the root of the controlled functional domain tree.
Locate the tessent_get_cts_skew_groups_dict inside the output .sdc file from the extract_sdc command,
and follow the instructions provided in the banner of that proc to disable this balancing.

Tessent™ Shell User’s Manual 943

Timing Constraints (SDC)
Running Layout With Tessent Shell DFT

Clock Tree Synthesis With On-Chip Controllers

Figure 299. Locations for Exclude Points for OCC CTS

The preceding figure shows a schematic of a Tessent standard OCC module, with red indicators showing
where CTS exclude points must be applied to prevent balancing internal OCC logic with its driven clock
tree. That balancing would considerably increase the OCC logic clock insertion delay; this would, in turn,
shorten the setup margin of the OCC critical at-speed paths, shown by the dashed purple arrows, when
the OCC runs in fast capture mode. This could sometimes make it impossible to close timing.
In the Tessent OCC, balancing must be blocked in the following locations, corresponding to the numbers
in the figure:

1. The synchronizer cell that captures the transitions of the scan_enable

2. The fast_clock clock gater cell

3. The shift register block clock multiplexer

Adding a CTS exclude point directly at the output of the OCC would forbid any eventual balancing
of the shift clock tree across multiple OCCs. This permits maximizing the shift clock frequency of the
scan chain between scan domains and the EDT controller. It would also have blocked balancing of
functionally synchronous clocks across different OCCs. You can still add any additional required CTS
control commands after the OCC output.
The extract_sdc command writes a Tcl proc named tessent_get_cts_skew_groups_dict to the output SDC
file. This proc returns a dictionary of the CTS exclude points or skew groups across all OCC instances in
your design. You can use this dictionary with a custom script that issues CTS commands specific to your
layout tool. The proc includes instructions in the header comment to help you use the proc during CTS.
Refer to the following example:

proc tessent_get_cts_skew_groups_dict {} {

# This proc returns a dictionary of clock source pins from where clock tree synthesis
# balancing should stop.
# Use it in your CTS script, along with your proper tool command.
# In Synopsys ICC, invoke:
# set_clock_tree_exceptions -exclude_pins <exclude_pin>
# In Cadence Innovus, invoke:
# create_ccopt_skew_group -sources <exclude_pin> -auto_sinks -skew_group <group name>
# The effect of that command is:

944 Tessent™ Shell User’s Manual

 Timing Constraints (SDC)
Running Layout With Tessent Shell DFT
# * to prevent adding delay buffers to the small OCC internal clock tree, due to balancing
# with all flops in the OCC fanout, therefore helping the OCC clock_enable signals meet
# setup timing.
# * to prevents adding long delays to the SSN clock tree due to balancing with the
# functional clock tree in the fanout of each SSN scan host (SSH).
#
# You can use the dictionary the following way:
# set cts_skew_groups_dict [tessent_get_cts_skew_groups_dict]
# dict for {skew_group sub_dict} $cts_skew_groups_dict {
# dict with sub_dict {
# foreach pin $cts_exclude_pins {
# puts "$skew_group : $dc_instance/$pin"
# <insert your CTS command here>
# }
# }
# }
set return_dict {
cts_skew_group(occ0) {
dc_instance top_rtl2_tessent_occ_parent_clka_inst
cts_exclude_pins {occ_control/tessent_persistent_cell_ltest_ntc_sync_cell/CK
occ_control/tessent_persistent_cell_cgc_SHIFT_REG_CLK/CK
occ_control/tessent_persistent_cell_SHIFT_REG_CLK_mux/A1}
}
cts_skew_group(occ1) {
dc_instance top_rtl2_tessent_occ_parent_clkb_inst
cts_exclude_pins {occ_control/tessent_persistent_cell_ltest_ntc_sync_cell/CK
occ_control/tessent_persistent_cell_cgc_SHIFT_REG_CLK/CK
occ_control/tessent_persistent_cell_SHIFT_REG_CLK_mux/A1}
}
…
}
return $return_dict
}

Loading SDC Constraints in Layout With Tessent Logictest

In layout, some issues may limit one's ability to constrain the logictest DFT simultaneously with all other
logic. For instance:

1. Letting scan_en=X, unblocks a large number of false at-speed path between neighboring flops on
the same scan chains, unless you have your own custom way to globally disable these paths in
your own design environment and flow.

2. As opposed to synthesis, where all clocks are ideal, propagating test_clock with scan_en=X in
layout may enable false cross-domain paths between unbalanced functional domains. Those
paths become single-cycle paths of test_clock which, if test_clock is unbalanced, may cause both
setup and hold false timing violation.

3. Some false at-speed capture paths might get unblocked between test-only dedicated wrapper
cells and functional logic.
If your layout flow provides custom methods to work around these issues, you can run layout using only
one global set of constraints that covers both your functional and DFT modes. In such a case, you would

Tessent™ Shell User’s Manual 945

Timing Constraints (SDC)
Running Layout With Tessent Shell DFT
only need to call the tessent_set_non_modal proc with no argument, or use the extracted .sdc file from
synthesis. If not, then you need to use the multi-mode feature of your layout tool and sequentially load the
following modal SDC constraints:
Mode 1:

• Set your functional SDC constraints.

• Call tessent_set_non_modal with the argument "off", like in:

tessent_set_non_modal off

This adds all Tessent DFT constraints, but disables all logictest DFT paths.
Mode 2:

• Call proc <ltest_prefix>_modal_shift

• This forces the "shift" mode over your design, asserting scan_en to 1 creating scan mode clocks
and taking care of DFT signals, OCC, and EDT logic setup. This covers all of your scan chain and
EDT channels paths, as well as any pipelining flop timing along the way.

• Run layout incrementally, so as to fix any leftover timing paths that were blocked in the first pass.
Mode 3:

• Call proc <ltest_prefix>_modal_edt_slow_capture. This proc does the following:

◦ Creates test_clock and propagates it across the design.

◦ Lets scan=X, which enables covering the timing of that signal as well as some leftover timing
paths inside Tessent’s OCC clock gating circuit.

◦ Disables same-edge paths from test_clock to test_clock, leaving only retimed cross-domain
paths enabled, so as to prevent false timing violations across functional domains. Intra
domain paths are assumed covered more tightly by the functional mode constraints.

◦ Enables capture paths across your design’s top ports as single-cycle paths of test_clock.

• Run layout incrementally again.

To save time and resources, you can choose to skip mode #3 if you know you are running scan mode at a
very slow clock speed and that all your capture paths are guarded with extra cycles of test_clock.

946 Tessent™ Shell User’s Manual

 Timing Constraints (SDC)
SDC for Modal Static Timing Analysis

SDC for Modal Static Timing Analysis

The following are guidelines to help you perform static timing analysis of the embedded test hardware that
was inserted by Tessent Shell.

Checking Your Functional Logic Alone

Checking Your Embedded Test Logic

Checking Your Functional Logic Alone

Tessent automatically turns off logictest circuitry when you add the "tessent_set_non_modal off" proc to
your SDC file. For most designs, this is the only step you need. You can provide constraints for specific
instruments to address any specific concerns.
If you want to only focus on functional logic and completely disable all Tessent Shell embedded test IP,
include the following steps in your primary functional STA script.
If flops in your cell library do not propagate constant settings through their set or reset pin to their data
output pin, you need to set a PrimeTime variable:

set case_analysis_sequential_propagation always

This turns off all embedded test modes with just a few asserts of the TAP’s reset port.
For example:

-------------------------------------------------------------------------
... loading your functional constraints ....
set case_analysis_sequential_propagation always
# Hold the DFT in reset and kill TCK to make sure only functional logic is
# active.
set_case_analysis TRST 0
set_case_analysis TCK 0
-------------------------------------------------------------------------

You also need to disable your scan circuit timing by forcing your scan_enable pin to its inactive value, and
by issuing a set_false_path to/from all your lockup cells and your pipeline flops. Those can normally be
found with regular expressions such as:

[get_pins -hier <standard naming>*/d]

[get_pins -hier <standard naming>*/q]

You might also have to turn your BISR clock or reset pin off, if present, like in:

set_case_analysis bisr_clk 0
set_case_analysis bisr_reset 0

When you are working with a physical block or sub-block, you can turn off all DFT signals accessible at its
interface. For example:

Tessent™ Shell User’s Manual 947

Timing Constraints (SDC)
Checking Your Embedded Test Logic

set_case_analysis scan_en 0
set_case_analysis ijtag_tck 0
set_case_analysis ijtag_reset 1
set_case_analysis ijtag_sel 0
set_case_analysis ijtag_se 0
set_case_analysis ijtag_ce 0
set_case_analysis ijtag_ue 0
set_case_analysis ijtag_si 0
set_case_analysis edt_update 0
set_case_analysis edt_clock 0

Resetting the IJTAG logic should also reset any dedicated wrapper cells (DWC). If you want to explicitly
identify and turn off DWCs or other test logic, you can use the report_insert_test_logic_options command
to find the name infix used by the tool when it inserted the logic. Then use the introspection commands to
find the instances you want. For example, the following returns pins on DWCs:

set_false_path -through [get_pins -hier *dihw_*/DI]

set_false_path -through [get_pins -hier *dihw_*/DO]
set_false_path -through [get_pins -hier *diw_*/DI]
set_false_path -through [get_pins -hier *diw_*/DO]
set_false_path -through [get_pins -hier *dohw_*/DI]
set_false_path -through [get_pins -hier *dohw_*/DO]
set_false_path -through [get_pins -hier *dow_*/DI]
set_false_path -through [get_pins -hier *dow_*/DO]

Tip
To set your own naming convention, use the set_insert_test_logic_options -logic_infix command
before test logic insertion.

Related Topics
tessent_set_non_modal

Checking Your Embedded Test Logic

You can find a self-documenting example script of how to run STA using Tessent Shell generated
hardware.
Refer to “Example Scripts Using Tessent Tool-Generated SDC” on page 979 for an example STA script.
Carefully read the instructions in this script before proceeding.
The script runs the following:

• Loads the generated SDC file and initializes some Tcl variables used by Tessent Shell SDC
constraints.

• Sets some PrimeTime control variables to their required value.

• Sources user input files if present in the same directory as follows:

948 Tessent™ Shell User’s Manual

 Timing Constraints (SDC)
Checking Your Embedded Test Logic

◦ user_timing_data.tcl

◦ user_remapping_procs.tcl

◦ load_design.pt

• Loads your final netlist.

• Sequentially runs all EmbeddedTest modes present in your design, each separated by a
"reset_design" command.

• Runs an example "report_constraints" command for each mode and redirects its output to a file.

Tessent™ Shell User’s Manual 949

Timing Constraints (SDC)
VHDL and Mixed Language Designs

VHDL and Mixed Language Designs

Synthesis tools have similar but sometimes different internal representations of elaborated designs.
Here are some instructions on how to deal with those differences to be able to use the SDC constraints
generated by Tessent Shell.

VHDL Generate Blocks

VHDL Generate Blocks

Required tool settings and other mixed-language issues.

Synopsys Design Compiler

Constraints applying to cells and pins in VHDL generate loops are problematic to apply in dc_shell. The
default naming scheme of the internally synthesized design is different for Verilog and VHDL. To illustrate,
here is a Verilog path of an instance within two nested generate for loops: blk[0].jblk[0].i0. The equivalent
configuration in VHDL would be changed during dc_shell’s GTECH pre-synthesis and would be named
i0_0_0. Because Tessent Shell’s SDC does not "flatten" generate loops, if you have VHDL generate loops
in your design, you must use the following setting in dc_shell to restore the loop naming:

set_app_var hdlin_enable_upf_compatible_naming true

This variable restores VHDL generate loop naming to follow Verilog style: blk(0)/jblk(0)/i0

Cadence Encounter and Genus

There are no special steps for these two synthesis tools to be able to apply Tessent Shell generated SDC
constraints to a mixed language design.

Oasys
Use the following commands in Oasys to generate a naming scheme for generate loops (Verilog and
VHDL) that is compatible with the Tessent SDC constraints:

set_parameter generate_naming_style %s[%d]

set_parameter if_generate_naming_style %s

Dealing With Unrolled VHDL Generate for Loops

Tessent Shell tries to minimize unrolling of generate loops. If VHDL generate loops are unrolled then
one "if-generate" block is generated for each loop iteration. The trailing closing square brace, that would
normally be changed to an underscore, has to be truncated because of VHDL language restrictions. This
means that functional SDC constraints pointing to cells or pins within those generate blocks do not match
even if special characters are mapped to wildcards. Ex: the instance path blk[0].i0 which would need to be
unrolled would be written out as blk_0.i0.
For this reason, you should use the provided procs tessent_get_pins and tessent_get_cells They are
able to match your functional instance path blk[0].i0 to blk_0.i0 using a caching algorithm that searches
for generate blocks in the path and tries to match with our unrolling strategy if the path does not match
outright. Refer to the “Mapping Procs” on page 977 for the procs’ description.

950 Tessent™ Shell User’s Manual

 Timing Constraints (SDC)
SDC File Contents

SDC File Contents

This section describes the procs contained in the generated SDC file. Note that many of these procs are
called automatically by other procs in the file. You do not need to call all of these procs.

Note:
This section uses the following convention to shorten proc names:
<ltest_prefix> := tessent_set_ltest

tessent_set_default_variables
tessent_create_functional_clocks
tessent_<design_name>_set_dft_signals
<ltest_prefix>_disable
tessent_set_non_modal
tessent_<design_name>_kill_functional_paths
IJTAG Instrument
LOGICTEST Instruments
MemoryBIST Instrument
BoundaryScan Instrument
Hierarchical STA in Tessent
Mapping Procs
Synthesis Helper Procs

tessent_set_default_variables
This proc defines the initial/default value of all global variables used in all procs of the sdc file. The
variables contained in this proc are there for you to customize the constraints without having to edit the
constraints themselves. A good example of this would be the variable "tessent_tck_period". It currently
defaults to 100.0 (nanoseconds). If your TCK clock has a different period than 100 ns, you can overwrite
the value of this variable after having called the proc tessent_set_default_variables but before calling the
constraint procs.

Note:
The value of tessent_tck_period might depend on the maximum tck clock frequency that can
be applied to the circuit. Refer to the "IJTAG Network Performance Optimization" section in the
Tessent IJTAG User’s Manual showing how to maximize the frequency of the IJTAG network test
clock.

The mapping between LogicBIST and InSystemTest controller IDs and their instance path names is
available in this proc. Use the mapping information to indicate the clocks of these instruments to the other
ltest SDC procs as described in “Preparation Step 2: Setting and Redefining Tessent Tcl Variables” on
page 938.
This proc must always be the first proc to be run.

Tessent™ Shell User’s Manual 951

Timing Constraints (SDC)
tessent_create_functional_clocks

tessent_create_functional_clocks
This proc is generated for your convenience. It contains the SDC create_clock and
create_generated_clock commands to define the various functional clocks needed by the instruments
constrained by the SDC procs. Typically, your functional clocks would already be defined by your
functional SDC. If that is the case, you should override the default values of the tessent_clock_mapping
array to match the clock names you used in the definition of your clocks.
This proc would typically not be called in your synthesis SDC.
Required clocks are determined with ICL tracing. create_clock constraints are added for all clock sources
like top level ClockPort ports and source ToClockPort ports (embedded crystals). create_generated_clock
constraints are added for all generated clocks (add_clocks -reference), branch clocks and unidentified
ICL ToClockPort ports (typically PLLs). If your design contains an ICL instrument with a ToClockPort that
should not require a new generated clock, set the exclude_from_sdc attribute on the port.

tessent_<design_name>_set_dft_signals
This procedure forces all your specified static dft_signal sources to either reset or get their default value
during all_test, depending on the proc's argument.

argument mode :== reset | logic_off

• logic_off — Recommended argument for running non-logictest STA modes such as

memoryBIST. But if you added Siemens EDA TestKompress, your sdc file also gets the proc
<ltest_prefix>_disable. You then only need to call that proc for running the other non-logictest
modes such as modal memoryBIST.

• reset — Disables all DFT-inserted logic.

If you are using functional-only mode, you can optionally call the proc with the "reset" argument under one
of the following circumstances:

1. Many static dft signals come from top-level ports.

2. Although all static dft signals sourced by the Siemens EDA IJTAG Test Data Registers (TDR)
reset when the IJTAG reset port is asserted, the timing tool would not propagate that assert
through the TDR flops. That may happen in Synopsys PrimeTime when the control variable
"case_analysis_sequential_propagation" is set to "never".

<ltest_prefix>_disable
This proc disables all Logictest logic in your design. You call this proc when setting up exclusive STA
mode for your IJTAG, BoundaryScan or MemoryBIST, and you do not want to bother about ltest logic and
scan chains timing at the same time.
This proc is invoked by proc tessent_set_non_modal when called with the logictest argument set to
off. Specifying on would invoke proc tessent_set_ltest_non_modal proc instead. You would typically
use on during pre-layout synthesis and off during layout. In layout, you would then need to apply two
different mode scripts in your layout tool. The second mode would time logictest-only shift logic, for
which you would invoke the proc <ltest_prefix>_shift. For more information about this proc, refer to
“<ltest_prefix>_modal_shift” on page 962.

952 Tessent™ Shell User’s Manual

 Timing Constraints (SDC)
tessent_set_non_modal

You can call the proc with or without an argument:

• <ltest_prefix>_disable — Disables logictest controller and forces the all_test dft signal active. Use
this when setting up the membist STA mode. For an example, refer to “Example Scripts Using
Tessent Tool-Generated SDC” on page 979.

• <ltest_prefix>_disable all_test_x — Disables the logictest controller but does not force the
all_test dft signal. Use this when constraining your design for synthesis or for layout. For more
information, refer to “tessent_set_non_modal” on page 953
When SSH is present in the design, this proc permits ts_tck_tck to propagate to the SSH logic so it
can properly time the serial scan path to and from the IJTAG network. It assumes that timing paths
between the SSH IJTAG registers and the SSH logic always meet a single-cycle path of ts_tck_tck, with
no excessive stress to the quality of results (QoR) for the layout. Clock tree synthesis can balance both
branches of ts_tck_tck within the SSH logic.
In this case, constraints added at the SSH scan clock sources and scan_en pin prevent ts_tck_tck from
leaking into the scan domains and prevent potential false paths to memory BIST logic clocked by tck. The
following example illustrates these constraints:

# Stop ts_tck_tck from propagating to core logic

set_disable_timing [tessent_get_pins $tessent_ssh_mapping(ssh0)/ \
clock_gen/clock_signals/tessent_persistent_cell_edt_clock_mux/Y]
set_disable_timing [tessent_get_pins $tessent_ssh_mapping(ssh0)/ \
clock_gen/clock_signals/ \
tessent_persistent_cell_shift_capture_clock_mux/Y]
# Prevent false paths to scannable tessent memory_bist logic, which uses
# ts_tck_tck in setup mode.
set_false_path -from [tessent_get_clocks \
$tessent_clock_mapping(ts_tck_tck)] \
-through [tessent_get_pins $tessent_ssh_mapping(ssh0)/ \
tessent_persistent_cell_scan_en_buf/Y]

tessent_set_non_modal
This proc contains calls to the non_modal procs of all constrained instruments, which are documented in
the sections that follow. For synthesis, this is the only constraint proc you need to call.
You can call this proc with no argument, or with the argument "off":

tessent_set_non_modal off

The argument "off" disables logictest circuitry by asserting dft_signal source pins and prevents adding any
non-modal logictest clocks or constraints. The default is to call the proc tessent_set_ltest_non_modal.
This is an example of the tessent_set_non_modal proc using the design "blka":

proc tessent_set_non_modal {{logictest "on"}} {

tessent_set_ijtag_non_modal
tessent_set_memory_bisr_non_modal
tessent_set_memory_bist_non_modal
if {$logictest eq "on"} {
tessent_set_ltest_non_modal

Tessent™ Shell User’s Manual 953

Timing Constraints (SDC)
tessent_<design_name>_kill_functional_paths
} else {
tessent_set_ltest_disable all_test_x
}
}

For an example of how to use the proc, refer to Single-Mode vs Dual-Mode Constraining in Synthesis/
Layout in “<ltest_prefix>_non_modal” on page 965.

tessent_<design_name>_kill_functional_paths
This procedure disables all timing paths involving non-Tessent flops. It enables running test-only timing
analysis without having to fix functional path violations with your own functional SDC constraints. It
helps making functional mode STA and Siemens EDA DFT mode STA fully orthogonal, and reduces the
Siemens EDA DFT mode STA run-time.

CAUTION:
Do not call this procedure for any logic test STA modes. It is intended for use only in the Siemens
EDA DFT mode. Refer to “Example Scripts Using Tessent Tool-Generated SDC” on page 979
for the location of an example STA script.

You can optionally run this procedure when you know that your functional logic has many intra-
domain timing paths that cannot meet default single-cycle path timing with the clocks being set by
tessent_create_functional_clocks and tessent_set_* procs.
Disabling some sequential cells in your design might accidentally block the test clocks feeding your
inserted instruments. Examples of such cells are Integrated Clock Gating (ICG) cells or flops that belong
to clock dividers. You can fix this by specifying those cells either by module name or by instance names.
By module name:

set ClockSeqCellModuleRegExp "<regularExpression>"

Note:
This finds only library cells that match this module name pattern. If your module is hierarchical
and the cells you are trying to preserve are below it, use the instance name option described in
the following.

By instance name:

set ClockSeqCellInstanceRegExp "<regularExpression>"

Note:
This expression is tested against the full hierarchical instance paths. A pattern that would match a
hierarchical instance preserves all cells within it.

The procedure optionally creates a report file containing a sorted list of all disabled flops
instance names. To enable this option, you need to define the following variable prior to calling
tessent_kill_functional_paths:

954 Tessent™ Shell User’s Manual

 Timing Constraints (SDC)
IJTAG Instrument

set CreateDisabledFlopsReport 1

IJTAG Instrument
Tessent IJTAG provides the following procs:

• set_ijtag_retargeting_options

◦ This proc would typically be called directly in your synthesis scripts to set the supported
options and related variables.
This proc is a replica of the Tessent Shell command set_ijtag_retargeting_options supporting options that
are pertinent to SDC. Any unsupported option specified to the SDC version of the command is ignored.

Table 54. set_ijtag_retargeting_options Arguments and SDC Variables

Option SDC Timing Variable Default

-default_scan_out_strobe_point tessent_default_scan_out_strobe_point auto

-extra_control_setup_hold_cycles tessent_extra_control_setup_hold_cycles 0

-extra_tms_setup_hold_cycles tessent_extra_tms_setup_hold_cycles 0

-tck_period tessent_tck_period 100.0 ns

Note:
The set_output_delay constraint includes a "-clock_fall" option for scan-out ports if you use the
"set_ijtag_retargeting_options -default_scan_out_strobe_point before_falling_edge_of_tck"
command.

• tessent_set_ijtag_non_modal

◦ This proc would typically not be called directly in your synthesis script, it is called as part of
tessent_set_non_modal.
This proc contains the clock creation for your TCK clock and configurable input and output delays for
created ports at the sub_block and physical_block design levels.
It also creates an asynchronous clock group with all TCK clocks. It is used to prevent synthesis from
balancing paths between TCK and functional clocks. This clock group could be recreated with additional
clocks if your design contains Tessent BoundaryScan or Tessent OCC hardware. This is managed via the
"tessent_tck_clock_list" global variable. This variable is built from different procs (ijtag and jtag_bscan)
and used to create an asynchronous clock group. If you have your own TCK generated clocks that are
not used in the Tessent Shell SDC constraints, we suggest adding their name to this list right after calling
tessent_set_default_variables.

tessent_set_default_variables
lappend tessent_tck_clocks_list my_tck_generate_clock

Tessent™ Shell User’s Manual 955

Timing Constraints (SDC)
LOGICTEST Instruments

At the sub-block and physical block levels, constraints are added to reflect the timing of the IJTAG
protocol. The IJTAG reset port is declared a false path and the IJTAG select port’s hold paths are
declared false and its setup paths are given two cycles with a multicycle_path constraint.
The select signal source of all non-scan SIBs (part of the SRI network) is relaxed to MCP setup 2 hold
2. This is to reflect the protocol and enable deep combinational paths to close timing. This constraint
did not include the SIBs part of the STI network as those should be local to each physical region, and it
should be easier for timing tools to close timing. If you experience problems with scan-testable SIB select
signals, you can add those to the list of SIBs that are relaxed. However, this has an adverse impact on
scan patterns.

LOGICTEST Instruments
The section lists the logic test-based procs. LogicBIST and InSystemTest-related procs listed in the
following are included only when LogicBIST and InSystemTest controllers are present in the design.

Note:
This section uses the following convention to shorten proc names:
<ltest_prefix> := tessent_set_ltest

1. Non-modal constraints, to be merged with other DFT instrument constraints, for synthesis or
layout. Refer to this proc description for a discussion on single-mode synthesis/layout vs multi-
mode synthesis/layout flow:

◦ <ltest_prefix>_non_modal

◦ tessent_set_in_system_test_non_modal

2. Modal procs, used for signoff STA and optionally for synthesis or layout constraining:

◦ <ltest_prefix>_modal_shift

◦ <ltest_prefix>_disable

◦ <ltest_prefix>_modal_lbist_shift

3. Procs only for per-mode signoff STA constraints:

◦ <ltest_prefix>_edt_shift

◦ <ltest_prefix>_bypass_shift

◦ <ltest_prefix>_single_bypass_chain_shift

◦ tessent_set_edt_slow_capture

◦ <ltest_prefix>_edt_fast_capture

956 Tessent™ Shell User’s Manual

 Timing Constraints (SDC)
LOGICTEST Instruments

◦ <ltest_prefix>_modal_lbist_shift

◦ <ltest_prefix>_modal_lbist_capture

◦ <ltest_prefix>_modal_lbist_setup

◦ <ltest_prefix>_modal_lbist_single_chain

◦ <ltest_prefix>_modal_lbist_controller_chain

4. Procs sub-invoked by the preceding procs.

◦ <ltest_prefix>_create_clocks

◦ <ltest_prefix>_set_pin_delays

<ltest_prefix>_create_clocks
This proc creates the slow-speed test clocks for use during scan mode. There are a few possible clock
configurations:

• tessent_test_clock — This is a DFT signal in Tessent Shell. It should be your tester's

synchronous clock and is used to create the shift_capture_clock and the edt_clock.

• tessent_edt_clock — This clock is created when the edt_clock source is a primary input port,
separate from the shift_capture_clock. It is not necessary when edt_clock is generated from the
test_clock.

• tessent_shift_capture_clock — This clock can either be a primary input port or it can be

generated from the test_clock and is the main scan mode clock propagating to your functional
logic through the OCCs.

• tessent_virtual_force_pi and tessent_virtual_measure_po — Two virtual clocks of the same

frequency as the preceding tessent_test_clock, used to time all top-level ports that directly
interface with your EDT controllers and your scan chains, through the "set_input_delay" and
"set_output_delay" constraints.

• tessent_lbist_shift_clock_src — This clock is typically an internally generated free-running

clock used as the source for LogicBIST tests.
When using LogicBIST, the clock gaters (CGC) shown in the following figure for tessent_edt_clock
and tessent_shift_capture_clock are located inside the LogicBIST controller, and the clock source
automatically updates to this new location. This clock is created by the user outside of the Tessent-
generated SDC.
This proc is also called by every SDC proc that propagates the edt_clock or shift clocks, specifically:

• <ltest_prefix>_non_modal

• <ltest_prefix>_shift

Tessent™ Shell User’s Manual 957

Timing Constraints (SDC)
LOGICTEST Instruments

• <ltest_prefix>_modal_slow_capture

• <ltest_prefix>_modal_lbist_shift

• <ltest_prefix>_modal_lbist_capture
The following is an example of the created clocks you get if you run the following commands:
add_dft_signals test_clock -source_nodes [get_ports test_clock]
add_dft_signals {edt_clock shift_capture_clock} -create_from_other_signals

set slow_clock_period \
[expr $tessent_slow_clock_period * $time_unit_multiplier]
set sc_rise_time \
[expr $tessent_shift_clock_edge1_percentage/100. * $slow_clock_period]
set sc_fall_time \
[expr $tessent_shift_clock_edge2_percentage/100. * $slow_clock_period]
set sc_waveform "$sc_rise_time $sc_fall_time"
set force_pi_rise \
[expr $tessent_force_pi_percentage/100. * $slow_clock_period]
et measure_po_rise \
[expr $tessent_measure_po_percentage/100. * $slow_clock_period]
set min_width [expr 0.25 * $slow_clock_period]
set force_pi_waveform \
"$force_pi_rise [expr $force_pi_rise + $min_width]"
set measure_po_waveform \
"$measure_po_rise [expr $measure_po_rise + $min_width]"

# test_clock:
create_clock [tessent_get_ports test_clock] \
-add -period $slow_clock_period -waveform $sc_waveform\
-name tessent_test_clock

# Virtual force_pi clock, to comply with your timeplate "force_pi"

# specifications:
create_clock -period $slow_clock_period -waveform $force_pi_waveform \
-name tessent_virtual_force_pi

# Virtual measure_po clock, to comply with your timeplate "measure_po"

# specifications:
create_clock -period $slow_clock_period -waveform $measure_po_waveform \
-name tessent_virtual_measure_po

958 Tessent™ Shell User’s Manual

 Timing Constraints (SDC)
LOGICTEST Instruments

Figure 300. tessent_test_clock and tessent_shift_capture_clock Creation

Tessent Slow Clocks Waveform Definitions

To maintain consistency of the scan clocks and scan ports timing between your SDC and your
backannotated scan simulations, you need to define the following variables based on your
Fastscan timeplate specifications. These variables shape the waveforms of the tessent_test_clock,
tessent_virtual_force_pi, and tessent_virtual_measure_po clock definitions in your SDC. The variables
are as follows:

• tessent_slow_clock_period
Tessent slow clock period (the same for all clocks).
Default: 40 ns.

• tessent_shift_clock_edge1_percentage
Timeplate position of the shift clock rising edge as a percentage of its period.
Default: 50.

• tessent_shift_clock_edge2_percentage
Timeplate position of the shift clock falling edge as a percentage of its period.
Default: 75.

• tessent_force_pi_percentage
Timeplate position of the force_pi point as a percentage of the shift clock period.
Default: 0.

• tessent_measure_po_percentage
Timeplate position of the measure_po point as a percentage of the shift clock period.
Default: 25.

Tessent™ Shell User’s Manual 959

Timing Constraints (SDC)
LOGICTEST Instruments

Using percentages instead of absolute time values enables you to quickly modify the
tessent_slow_clock_period specification without also having to update the other Tcl variables.
The defaults described in the preceding reflect the Tessent FastScan timeplate default specifications, that
is:

timeplate gen_tp1 =
force_pi 0 ;
measure_po 10 ;
pulse_clock 20 10 ;
period 40 ;
end;

resulting into the following default clock definitions:

create_clock <port> -add -period 40. -waveform {20 30} -name tessent_test_clock
create_clock -period 40. -waveform {0 10} -name tessent_virtual_force_pi
create_clock -period 40. -waveform {10 20} -name tessent_virtual_measure_po

Finally, two more global Tcl variables might be necessary to specify the timing budget of the scan data
paths outside of the current module:

• tessent_scan_input_delay
Default value: 0.

• tessent_scan_output_delay
Default value: 0.
Update these variables if you plan to retarget your test vectors from a higher level module and you
budgeted some propagation delay for your scan signals in that module. Here is how the variables are
used:

set_input_delay $tessent_scan_input_delay -clock tessent_virtual_force_pi <port>

set_output_delay $tessent_scan_output_delay -clock tessent_virtual_measure_po <port>

Currently, the extract_sdc command assumes that timeplate specified values are identical for both
load_unload and capture phases, which is the Tessent FastScan default. Although, the non_modal ltest
proc has to use only one set of specifications, modal shift and capture STA may have to run with different
timeplate specifications. If it is your case, you can do it by updating the preceding Tcl variables prior
to calling the selected shift or capture modal proc. The fast_capture modal proc ignores those values,
because it uses your functional waveform specifications.

<ltest_prefix>_edt_fast_capture
This proc must be called in your STA to constrain the EDT in fast capture mode. Logictest fast capture
mode is the one that detects your at-speed transition faults. It counts on user SDC to provide the capture
clocks and timing exceptions that would actually time the capture paths. Typically this would be your
original functional SDC constraints, but those might still require some adjustments if your test conditions
(clock frequencies, false paths) slightly differ from what they are in functional mode. Obviously, you also
need to remove any constraint that resets the IJTAG network or ties the scan_enable or test_enable
control pins to zero.
If present, the following dft signals are turned off:

960 Tessent™ Shell User’s Manual

 Timing Constraints (SDC)
LOGICTEST Instruments

• scan_enable (putting the circuit in capture mode)

• control_test_point_en (these hold during capture)

The proc also enables you to check that some dft signals such as x_bounding_en, memory_bypass_en,
observe_testpoint_en are doing their isolation job correctly. You can optionally force them to a known
value by setting global Tcl variables prior to calling the proc.
The following demonstrates how this is done (annotations are in red):

global memory_bypass_en_value <<< set this variable if needed in

your primary script
if {[info exists memory_bypass_en_value]} {
set_case_analysis $memory_bypass_en_value \
[tessent_get_pins
elt1_mbist_tessent_tdr_sri_ctrl_inst/tessent_persistent_cell_memory_bypass
_en/Y]
}
global x_bounding_en_value <<< set this variable if needed in
your primary script
if {[info exists x_bounding_en_value]} {
set_case_analysis $x_bounding_en_value \
[tessent_get_pins
elt1_dft_tessent_tdr_sri_ctrl_inst/tessent_persistent_cell_x_bounding_
en/Y]
}
global observe_test_point_en_value <<< set this variable if needed
in your primary script
if {[info exists observe_test_point_en_value]} {
set_case_analysis $observe_test_point_en_value \
[tessent_get_pins
elt1_dft_tessent_tdr_sri_ctrl_inst/tessent_persistent_cell_observe_test_po
int_en/Y]
}

Finally, the proc also disables any other timing paths that are ignored during capture, such as those going
through the EDT channel pins.

tessent_set_edt_slow_capture
This proc must be called in your STA to constrain the EDT in slow capture mode.
The proc does the following:

• Forces the test_enable dft signals on.

• Declares the test_clock and lets your scan_en dft signal toggling, so that it can be timed and
relaxed with your number of dead cycles specification.

• Disables same-edge paths from test_clock to test_clock, leaving only retimed cross-domain paths
enabled, so as to prevent false timing violations across functional domains. Intra domain paths
are assumed covered more tightly by the functional mode constraints; enables capture paths
across your design’s top ports as single-cycle paths of test_clock.

Tessent™ Shell User’s Manual 961

Timing Constraints (SDC)
LOGICTEST Instruments

• Disables ignored timing paths.

• Sets an MCP for your scan_en signal using your global Tcl variables
tessent_scan_en_setup_extra_cycles and tessent_scan_en_hold_extra_cycles.

• Set an MCP for your edt_update signal, if present, using your global variables
tessent_edt_update_setup_extra_cycles and tessent_edt_update_hold_extra_cycles.

• Enables capture paths across your design’s top ports as single-cycle paths of test_clock.

Note:
Just as with the preceding <prefix>shift_ltest_non_modal proc, propagating test_clock may create
false capture timing paths across asynchronous domains as single-cycle paths of test_clock.
This may or may not be a problem, given that test_clock fanout is balanced and running at slow
speed. By default, this proc assumes that all valid intra-domain hold timing paths were already
covered by your functional modes STA, and therefore sets a multicycle_path of 1 hold to all
paths from test_clock to itself. Remember that all scan mode shift paths are properly covered
for both setup and hold by the "xxx_ltest_shift" mode proc defined in the preceding. If you
need to, you can still force the proc to revert to zero-hold constraint by setting the Tcl variable
tessent_time_hold_in_slow_capture to value 1 in your calling script.

<ltest_prefix>_modal_shift
This proc sets the circuit in scan shift mode. It covers both EDT shift modes and all available bypass
modes, assuming you run them all with the same shift clock frequency. If you need more specific timing
analysis, you can choose to apply the following procs in separate STA runs. These procs sub-invoke the
<ltest_prefix>_shift proc:

• <ltest_prefix>_edt_shift

• <ltest_prefix>_bypass_shift

• <ltest_prefix>_single_bypass_chain_shift
The <ltest_prefix>_shift proc applies a set of common constraints required for shifting. Then they only
need to complete their mode setting by forcing the edt_bypass and single_chain_bypass signals to the
required constant value.
The proc <ltest_prefix>_shift does the following:

• Creates the shift clocks.

• Applies set_input/output_delays to scan control pins.

• Forces dft signals ltest_en and scan_en to 1.

• Applies any LogicBIST mode constraints as applicable.

962 Tessent™ Shell User’s Manual

 Timing Constraints (SDC)
LOGICTEST Instruments

Note:
You can save on total STA time and flow complexity if you already plan to apply the same
test_clock (with the same period) for all shift and bypass modes. In this case you only need to call
the <ltest_prefix>_shift proc directly in place of all of the three procs defined in the preceding.

Note:
If you plan to feed your synthesis or layout tool with two separate mode scripts (functional/dft and
logictest), the <ltest_prefix>_shift proc is the one you need to apply for the logictest mode. That
way, all possible shift paths are timed, and because scan_enable is forced active, it prevents the
existence of a potentially large number of false capture timing paths across your functional logic.
It also covers all of your possible scan chain configurations at once, including the internal and
external mode for cores. Refer to later discussion on logictest single-mode or dual mode usage—
refer to <ltest_prefix>_non_modal.

<ltest_prefix>_modal_lbist_shift
You can configure timing analysis for this mode to run with shift_clock_src, test_clock, or ijtag_tck. The
default is shift_clock_src. Add the optional test_clock or ijtag_tck argument when calling this SDC Tcl proc
to analyze timing with test_clock or ijtag_tck, respectively.
The proc does the following:

• Adds multicycle path exceptions on dynamic signals from the LogicBIST controller to design scan
cells and hybrid EDT blocks. These include LogicBIST mode scan enable, prpg_en, misr_en, and
LogicBIST synchronous reset for the hardware default mode of operation.

• Adds case analysis on the mux, which chooses between the top-level scan enable for ATPG and
the LogicBIST controller-generated scan enable to enable only the LogicBIST mode paths.

• Adds case analysis to set lbist_en to active.

• Disables single chain mode scan chain concatenation paths.

• Disables paths from edt_chain_mask masking registers to the scan cells. This constraint is
required because even though this register is configured using tck as the source, the clock net
connected to the edt_lbist_clock signal carries both edt_clock and shift_clock_src clocks.

<ltest_prefix>_modal_slow_capture and <ltest_prefix>_modal_fast_capture

You get these procs in your SDC file only under the following conditions:

• You added the following dft signals in your current design level: scan_en, test_clock, or
(edt_clock and shift_capture_clock).

• And you did not insert a Tessent logictest-related controller, such as EDT or logicbist in that same
level.
These two procs properly assert all static dft signals, such as scan_en and ltest_en. They are the "no-
EDT" version of the following two procs:

Tessent™ Shell User’s Manual 963

Timing Constraints (SDC)
LOGICTEST Instruments

• <ltest_prefix>_modal_edt_slow_capture

• <ltest_prefix>_modal_edt_fast_capture
Because no EDT is present in the current design, extract_sdc does not generate these procs:

• <ltest_prefix>_edt_bypass_shift

• <ltest_prefix>_edt_single_chain_shift
However, if your design meets all of the following conditions:

• Your core instances actually do support edt_bypass chain or single_chain modes.

• You intend to run these modes at a test_clock frequency that differs from their EDT mode.

• You intend to use core-extracted timing models in a hierarchical STA flow.

Then you should load a per-mode core timing model, and then run the <ltest_prefix>_modal_shift proc
as a general setup for the top-level. For each such STA run, you must properly set the global Tcl variable
tessent_slow_clock_period value.
For <ltest_prefix>_modal_edt_fast_capture, all edt_bypass and edt_chain_bypass asserts are skipped by
default. If you do not want to skip these asserts, define the "tessent_block_edt_bypass_in_fast_capture"
global variable.

<ltest_prefix>_modal_lbist_capture
This mode is similar to <ltest_prefix>_modal_lbist_shift, except that the LogicBIST mode scan enable is
constrained to off.
To use this proc in your SDC file, you must do the following:

1. Define all functional clocks.

2. Based on the clocking scheme, declare false paths between clock domains that do not pulse
together.

<ltest_prefix>_modal_lbist_setup
This mode propagates tck through the IJTAG network within the LogicBIST controller and hybrid EDT
blocks to time the LogicBIST test_setup paths that initialize registers such as PRPG and edt_chain_mask,
as well as test_end paths that read the MISR signature.
This mode does not propagate tck to the design scan cells because it is only intended to check the IJTAG
network paths.

<ltest_prefix>_modal_lbist_single_chain
This mode is available when single chain mode logic that enables LogicBIST diagnosis is enabled
during IP generation. This mode propagates tck through the IJTAG network paths and design scan cells,
including the concatenation of the internal scan chains for single-chain shifting. The LogicBIST scan
enable is constrained to 1 to time only the shift paths in the design with the tck signal.

964 Tessent™ Shell User’s Manual

 Timing Constraints (SDC)
LOGICTEST Instruments

<ltest_prefix>_modal_lbist_controller_chain
This mode is available when controller chain mode (CCM) logic is enabled during IP generation. When
CCM is present, all of the previously described LogicBIST modes disable the controller chain logic by
constraining the ccm_en signal to off. This mode tests the CCM paths by constraining the ccm_en signal
to on. The clock for this mode is either tck or test_clock, as specified during IP creation.
This mode only tests the LogicBIST and hybrid EDT controller blocks; clocks are not propagated to
design scan cells.
Paths that are normally disabled during the LogicBIST operation modes described in the preceding
become valid single-cycle paths in CCM and are timed accordingly.

• Signals such as lbist_en are not constrained to 1 because paths from the TDR register in the
LogicBIST controller to the hybrid EDT blocks that use this signal are tested with ATPG in CCM.
Paths from static signals—such as x_bounding_en, test_point_en, and capture_per_cycle—to the
design scan cells are correctly excluded because no clocks are propagated to the scan cells.

• Paths from dynamic control signals that are declared as multicycle for other modes—such as
scan_en, prpg_en, and misr_en—that go from the LogicBIST controller to the EDT blocks are
tested as valid single-cycle paths.

• Paths from IJTAG network nodes such as SIBs are timed as valid single-cycle paths of the CCM
clock.

• Input and output pin delays from top-level ports to EDT blocks and CCM scan I/O ports are
included for this mode. This differs from the LogicBIST shift and capture modes, which do not
have any active paths from or to design ports.

<ltest_prefix>_non_modal
This procedure provides SDC timing constraints to add to your combined functional-dft non-modal
timing scripts for one-pass synthesis or layout. Its contents is merged with both your functional
constraints and all other Tessent controller's non-modal constraints. It is called by the umbrella proc
"tessent_set_non_modal" proc.
The procedure calls the previously described procs:

• <ltest_prefix>_create_clocks

• <ltest_prefix>_set_pin_delays
It also:

• Defines a specific clock group (using 'set_clock_groups') for all logictest slow clocks, isolating
them from your declared functional clocks.

• Adds "set_false_path" constraints from each of your primary ports assigned to a static dft signals
such as "all_test", "ltest_en", and "edt_mode". If the same signals come instead from an internal
IJTAG Test Data Register (TDR), the "set_clock_groups" command between ts_tck_tck and the
scan clocks replaces the individual set_false_path commands.

Tessent™ Shell User’s Manual 965

Timing Constraints (SDC)
LOGICTEST Instruments

• Provides constraints to prevent "tck" and your functional clocks to propagate to unwanted paths
inside your Siemens EDA OCCs, as well as constraints that prevent false timing violations on the
select pin of clock muxes inside that OCC.

• Provides constraints that disable automatic clock gating checks across input pins of the Siemens
EDA OCC clock multiplexers, because all OCC clock selection is either performed statically
during test setup or at slow speed in a glitchless way during scan.

• Adds an optional set_multicycle_path constraint from your primary 'scan_en' port and
"edt_update" signal, based on your setting of the global variables:

◦ tessent_scan_en_hold_extra_cycles

◦ tessent_scan_en_setup_extra_cycles

◦ tessent_edt_update_hold_extra_cycles

◦ tessent_edt_update_setup_extra_cycles
which all default to zero, meaning single-cycle paths of slow clock.

• When using LogicBIST, includes a 3-to-1 shift_clock_select mux at the clock structure root of the
LogicBIST controller. This mux enables any one of three clocks—shift_clock_src, test_clock or tck
—to be used as the source clock for LogicBIST test.

◦ Blocks tck propagation through the shift_clock_select mux into the design scan cells. This
removes analysis of the slowest LogicBIST mode of operation using tck to reduce timing
analysis run time.

◦ Propagates both shift_clock_src and test_clock to the design scan cells, but all interactions
between them are blocked.

• Adds the following LogicBIST-related exceptions:

◦ Declares multicycle paths from LogicBIST scan enable generation logic to the design scan
cells. The number of cycles are based on the pre_post_shift_dead_cycles IP generation
parameter and defaults to eight.

◦ Declares multicycle paths from logic that generates the prpg_en, misr_en, and LogicBIST
synchronous reset for hardware default mode operation signals to the hybrid EDT blocks. The
number of cycles are based on the pre_post_shift_dead_cycles IP generation parameter.

◦ Disables paths from static control registers in the LogicBIST controller—such as lbist_en and
x_bounding_en—to design scan cells and hybrid EDT blocks. This is implicitly performed by
declaring tck as asynchronous to other clocks in the IJTAG non-modal proc. When CCM is
implemented with the EDT clock as the CCM clock, explicit false paths are added to disable
such paths.

966 Tessent™ Shell User’s Manual

 Timing Constraints (SDC)
LOGICTEST Instruments

• Excludes single chain mode logic scan chain concatenation paths through case analysis on the
single bypass chain control TDR output.

• When CCM is implemented with test_clock as the CCM clock, the test_clock propagates to all
IJTAG scan elements on the tck domain. Constraints are added to disable such paths to the
tessent_lbist_shift_clock_src clock.
Single-Mode vs Dual-Mode Constraining in Synthesis/Layout
Important: As it stands in the current release, leaving the scan_enable signal free to toggle in this proc is
known to create false shift_clock-frequency timing paths across your functional design, which may or may
not affect timing closure or quality of results in layout. Siemens EDA customers’ experience greatly varies
on this front. Here are some examples of such false paths:

1. Scan chains intra-domain shift-only paths are constrained at the speed of the functional clock.

2. As a result of creating only one shift_capture_clock source and letting it propagate to all
functional clock domains, all cross-domain capture paths become single-cycle of the shift clock,
regardless of whether they are asynchronous in functional mode or not.
This said, these new timing paths do not instantly condemn your layout or physical synthesis tool to fail
timing closure or perform a bad P&R job, knowing that clock tree synthesis also balances the test_clock
fanout by default. Non-physical synthesis is generally not a problem.
On the other hand, re-constraining of all those bogus timing paths would typically require a very large
number of design-dependent timing exceptions, which extract_sdc is not able to provide at this point.
Applying them could also slow down some layout tools considerably.
The alternative to single-mode constraining is to apply individual mode scripts at different times in
the synthesis or layout tool. It is a well-known solution that has been applied by most Siemens EDA
customers historically.

1. Functional/Dft mode:

◦ Apply your functional constraints

◦ Invoke proc tessent_set_non_modal off

2. Logictest-only mode, covering all EDT scan configurations, such as EDT shift and EDT bypass
shift:

◦ Invoke proc <ltest_prefix>_modal_shift

3. If your design contains hybrid EDT/LBIST, another logictest-only mode to cover the LBIST shift
configuration:

◦ Invoke proc <ltest_prefix>_modal_lbist_shift

This script cannot be combined with EDT scan configuration script because these modes are not
compatible; they propagate different shift clocks, have different case analysis constraints on the
lbist_en signal, and have different timing requirements for scan enable with respect to the shift
clock.

Tessent™ Shell User’s Manual 967

Timing Constraints (SDC)
LOGICTEST Instruments

<ltest_prefix>_set_pin_delays
This procedure assigns the clock "tessent_virtual_slow_clock" to your top-level ports that directly interface
with your EDT controllers or your scan chains during scan or EDT mode, using the "set_input_delay" and
"set_output_delay" timing constraints.
This proc is called by every SDC proc which propagate the EDT or shift clocks, that is:

• <ltest_prefix>_non_modal

• <ltest_prefix>_shift

• <ltest_prefix>_modal_slow_capture
Input/Output Pin Delay Constraints
Input and output delay constraints are declared for the EDT control and channel pins. For example:

# channel_input:
set_input_delay $tessent_scan_input_delay \
-clock tessent_virtual_slow_clock \
[get_ports {my_edt_channels_in[0]}]
# channel_output:
set_output_delay $tessent_scan_output_delay \
-clock tessent_virtual_slow_clock \
[get_ports {my_edt_channels_out[0]}]

# edt_update:
set_input_delay $tessent_scan_input_delay \
-clock tessent_virtual_slow_clock \
[get_ports edt_update]

DFT Signals Handling in ltest STA Procs

All EDT-related modal STA procs in the following force these dft signals, when present, to their active
value:

• all_test (active in all tests)

• ltest_en (active in logictest only)

For example:

set_case_analysis 1 [get_ports all_test]

set_case_analysis 1 [get_ports ltest_en]

The same procs leave all other logictest-related dft signals toggling, and add a false_path constraint if
they come from a primary port. For example:

968 Tessent™ Shell User’s Manual

 Timing Constraints (SDC)
MemoryBIST Instrument

set_false_path -from [get_ports async_set_reset_static_disable]

set_false_path -from [get_ports control_test_point_en]
set_false_path -from [get_ports ext_ltest_en]
set_false_path -from [get_ports ext_mode]

If the same signals come instead from an internal IJTAG Test Data Register (TDR), the
"set_clock_groups" command between ts_tck_tck and the scan clocks replaces the individual
set_false_path commands.
Procedure "tessent_set_ltest_edt_fast_capture", on the other hand, optionally asserts some of these
dft_signals under control of a user-declared variable.

MemoryBIST Instrument
Tessent MemoryBIST provides the following procs:

• tessent_set_default_variables

◦ For a tiling design, the SDC input/output delay constraints for the
SecondaryHostScanInterface BISR ports are derived from a Tcl dictionary. This proc also
includes the bisr_shsi_delay Tcl dictionary that documents the default input/output delay
percentages relative to their clocks (functional or TCK). Refer to the Memory BISR Insertion
for Tiles With a BISR Controller section for an example of a bisr_shsi_delay dictionary.

• tessent_set_memory_bist_non_modal for chip synthesis

◦ This proc would typically not be called in your synthesis script, it is called as part of
tessent_set_non_modal.

• tessent_set_memory_bist_modal for STA

◦ This proc must be called in your STA script if you want to constrain the MemoryBist mode.

• tessent_<design_name>_top_set_dft_signals logic_off
Specify this call if your design also feature logictest-based dft signals that need to be turned off in
membist STA mode.

• tessent_mbist_set_ai_timing_mode
This procedure assures all functional clocks are defined and properly propagated, but leaves
the asynchronous interface free of constraints so they can be formally analyzed by procedure
tessent_mbist_report_controller_ai_timing. This proc is not present or needed if none of the
controllers being constrained utilize an asynchronous interface.

• tessent_mbist_report_ai_timing [-verbose 1|0] [-tck_period time_in_ns]

This procedure runs tessent_mbist_report_controller_ai_timing once for every MemoryBIST
controller in the current design. This proc is not present or needed if none of the controllers being
constrained utilize an asynchronous interface.

Tessent™ Shell User’s Manual 969

Timing Constraints (SDC)
MemoryBIST Instrument

• tessent_mbist_report_controller_ai_timing [-verbose 1|0] [-controller_id id] [‑tck_period

time_in_ns]
This procedure accurately measures the BAP AI timing paths to the specified MemoryBIST
controller. The covered AI signals are: BIST_SHIFT, BIST_SI, BIST_SO, and BIST_HOLD.
Because of the asynchronous nature of this interface, the signals listed in the preceding cannot
be accurately timed with SDC constraints. Although the circuit is designed to always work with a
low TCK frequency, this procedure validates that it works at the frequency you specified.
Each AI signal timing margin depends on a combination of the TCK period, the controller’s
BIST_CLK period, and the skew related to the TCK branch reaching that AI TCK transition
detector. Siemens EDA recommends running this procedure only once with your worst case
operating conditions. In most cases, AI signal timing is expected to largely exceed their setup
timing requirements. Hold timing is never a problem because of the design of the interface.
This proc is not present or needed if none of the controllers being constrained utilize an
asynchronous interface.
They contain many multicycle path constraints to and from controller registers aiming to minimize the
impact of the MemoryBIST DFT on your timing closure.

Multi-Clock Memories
Additional timing exceptions were added for synthesis if you have multi-port memories functionally driven
by multiple clocks. A mux is inserted in the memory interface to enable both clock ports of the memory to
be driven using a single clock during the Memory BIST mode. The insertion of this clock multiplexer adds
different timing modes between functional and test modes that must be described correctly in the SDC
file.

Note:
If you want to skip the memoryBIST constraints of clock muxing (creating the generated clock and
false paths) for multi-clock memories, set the tessent_apply_mbist_mux_constraints variable to
"0" in the tessent_set_default_variable proc. This variable should be set to "0" in two cases:
• For synthesis: When the BIST clock used by the MemoryBIST tests is declared as false path
with the memory’s functional clock in the user’s SDC script.
• For STA: When verifying the timing of the scan modes.

In the following, we explain key points of the MemoryBist constraints to handle these modes
harmoniously. Suppose the situation where CLKA and CLKB are two of your functional clocks that drive
two clock ports of a single memory. The MemoryBIST logic is inserted and runs on CLKA. CLKA is
multiplexed onto the CLKB branch of the memory during tests.

970 Tessent™ Shell User’s Manual

 Timing Constraints (SDC)
MemoryBIST Instrument

Figure 301. Generated Clock Muxed Multi-Clock Memories

First, we need to create a generated clock on the input of the clock mux. In our example, this clock is
called mbist1_m0_mux0.

create_generated_clock [tessent_get_pins
$tessent_memory_bist_mapping(mbist1_m3)/tessent_persistent_cell_MUX1/b] \
-name mbist1_m0_mux0 \
-source [get_ports CLKA] \
-add -master_clock $tessent_clock_mapping(CLKA) \
-divide_by 1

Creating this clock at the input of the clock mux (instead of the output) enables all input clocks to
propagate through the mux and times the following interactions precisely:

• Timing paths between the memory BIST logic and the memory

• Timing paths between the functional flops and the memory

With the mbist1_m0_mux0 defined, we can now define clock-based exceptions to declare as false any
interaction between CLKB and the memory BIST flops, and between mbist1_m0_mux0 and the functional
flops on CLKB. Those false paths are described using the following SDC commands:

set nonMBISTclocks [remove_from_collection [all_clocks] [get_clocks

"$tessent_clock_mapping(CLKA) mbist1_m0_mux0 "]]
set_false_path -from [get_clocks mbist1_m0_mux0] \
-to $nonMBISTclocks
set_false_path -from $nonMBISTclocks \
-to [get_clocks mbist1_m0_mux0]
set_false_path -from [get_clocks $tessent_clock_mapping(CLKB)] \
-to [tessent_get_cells [concat \
$tessent_memory_bist_mapping(mbist1_m3)/SCAN_OBS_FLOPS* \
$tessent_memory_bist_mapping(mbist1_m3)/MBISTPG_STATUS/GO_ID_REG* \
$tessent_memory_bist_mapping(mbist1_m3)/FREEZE_STOP_ERROR*]]
set_false_path -from [tessent_get_cells [concat \
$tessent_memory_bist_mapping(mbist1_m3)/Q1_SCAN_IN* \
$tessent_memory_bist_mapping(mbist1_m3)/Q2_SCAN_IN* \
$tessent_memory_bist_mapping(mbist1_m3)/BIST_INPUT_SELECT*]] \
-to [get_clocks $tessent_clock_mapping(CLKB)]
set_false_path -from [tessent_get_cells [concat \

Tessent™ Shell User’s Manual 971

Timing Constraints (SDC)
BoundaryScan Instrument
$tessent_memory_bist_mapping(mbist1)/MBISTPG_PORT_COUNTER/PORT_COUNTER* \
$tessent_memory_bist_mapping(mbist1)/MBISTPG_FSM/STATE* \
$tessent_memory_bist_mapping(mbist1)/MBISTPG_POINTER_CNTRL/EXECUTE_OP_SELECT_CMD** \
$tessent_memory_bist_mapping(mbist1)/MBISTPG_SIGNAL_GEN/JCNT* \
$tessent_memory_bist_mapping(mbist1)/MBISTPG_SIGNAL_GEN/OPSET_SELECT_REG* \
$tessent_memory_bist_mapping(mbist1)/MBISTPG_DATA_GEN/WDATA_REG* \
$tessent_memory_bist_mapping(mbist1)/MBISTPG_DATA_GEN/X_ADDR_BIT_SEL_REG* \
$tessent_memory_bist_mapping(mbist1)/MBISTPG_DATA_GEN/Y_ADDR_BIT_SEL_REG* \
$tessent_memory_bist_mapping(mbist1)/MBISTPG_ADD_GEN/AX_ADD_REG* \
$tessent_memory_bist_mapping(mbist1)/MBISTPG_ADD_GEN/AY_ADD_REG* \
$tessent_memory_bist_mapping(mbist1)/MBISTPG_OPTION/BIST_EN_RETIME2* \
$tessent_memory_bist_mapping(mbist1)/MEM_SELECT_REG*]] \
-to [get_clocks $tessent_clock_mapping(CLKB)]

By making these timing exceptions, we are precisely timing the memory BIST interaction with the memory
using CLKA reaching the two-clock ports of the memory and the functional logic to memory interaction
using the CLKB reaching the memory clock port. The added logic is precisely timed to simplify timing
closure. These constraints make physical design tools aware of the mux on the clock port of the memory
and they place the mux in a location where it does not affect timing.

BoundaryScan Instrument
Tessent BoundaryScan provides the following proc:

• tessent_set_jtag_bscan_non_modal

◦ This proc would typically not be called directly in your synthesis script, it is called as part of
tessent_set_non_modal.
It creates generated clocks from each BoundaryScan interface and relaxes the timing between them.

Hierarchical STA in Tessent

This section explains how to use Tessent-generated SDC constraint procs to run the hierarchical STA
flow with Siemens EDA DFT. This flow runs STA separately on each individually laid-out physical block.
If a block instantiates other lower-level physical blocks, partial or full back-annotated netlists or extracted
models of those physical blocks are loaded. The procs enable you to cover all Siemens EDA DFT timing
paths crossing the lower physical block boundaries, including those related to the IJTAG interface, BISR
register interface, bscan interface, and logictest scan/capture paths, while preventing interference and
false violations from irrelevant functional paths inside these physical blocks.
When the following conditions occur, the extract_sdc command creates a few callable SDC timing procs
to help with the hierarchical STA flow:

• The current DFT-inserted design instantiates lower-level physical blocks.

• Physical blocks have been DFT-inserted with Siemens EDA IP, using add_dft_signals commands,
along with the DftSpecification flow.

• For "xxx_ltest_xxx" procs, lower-level physical blocks are assumed to have the following:

972 Tessent™ Shell User’s Manual

 Timing Constraints (SDC)
Hierarchical STA in Tessent

◦ One or more EDT controllers.

◦ Optional Tessent OCCs.

◦ An external logictest mode, controlled with DFT signals ext_ltest_en and optionally
int_ltest_en.

Note:
This hierarchical STA flow is not the same as running flat logictest STA on a full design netlist
with multiple physical levels. Running flat STA would require an extra layer of complexity for the
needed constraints, especially if you intend to run each level with a different test_clock frequency.
Tessent Shell currently generates no SDC procs to support this type of procedure.

Extracting a Timing Model for Combined Tessent/Functional Mode

The tessent_set_non_modal proc in the extract_sdc output file provides SDC constraints that time your
inserted Tessent DFT logic. You can merge those constraints with your functional SDC constraints to
form a unique STA mode (called non_modal in this description). This mode fills all of your non-logictest
timing requirements. You can apply these non_modal constraints to your core before extracting the timing
model. Doing this means your core timing model includes timing arcs that cover the following core pins:

• IJTAG data and control signals

• Embedded boundary-scan interface signals

• BISR register interface pins

• SSN bus clock and data pins

• All functional timing paths

The Tessent logictest inserted DFT is likely to create clock configuration and timing path incompatibilities
with your functional mode. To address this, you must run the tessent_set_non_modal proc with the
argument "logictest=off" and cover the remainder of your logictest-dependent core interface paths with
other procs and methods, described later in this section.
However, if your core logictest DFT logic is controlled entirely by the SSN ScanHost (SSH) node, with
no SSH bypass mode, and your core has no dedicated wrapper cells that change the functional data
paths in logictest mode, you can time your core boundaries fully using only the extracted model described
previously, in all parent-level timing modes including the logictest ones. This is possible because of the
following:

• Scan chain shifting inside the core is directly under the control of the internal SSH of the core
even when running in external test mode. As a result, all scan data transits first through the core
SSN bus pins, which are already timed by this external test mode.

• If your functional data paths across the core are the same as when they are tested in the parent
TDF mode of the core, there are no further logictest-only cross-core timing paths that are not
covered.

Tessent™ Shell User’s Manual 973

Timing Constraints (SDC)
Hierarchical STA in Tessent

If your SSH supports the SSH bypass mode (SSH is turned off and all scan chains are accessed
through other standard EDT channel pins on your core), then you must extract specialized timing models
dedicated to your shift and slow_capture modes. This process is described in the following sections.

Extracting a Timing Model for Logictest

The extract_sdc command provides the following hierarchical STA procs:

• tessent_set_modal_lower_pbs — Enables all Siemens EDA DFT non-logictest timing paths

through physical block pins and disables all paths through the rest of the same physical block
pins.

• tessent_set_ltest_pb_external_mode — Enables the external logictest mode on an isolated

physical block, forcing its dedicated wrapper cells to select the boundary logic. Call this proc
before extracting your current physical block design timing model, for use at the next level up.

• <ltest_prefix>_lower_pbs_external_mode — Configures the instantiated lower physical blocks

of the parent design in their external mode, enabling running parent logictest modes with loaded
lower physical block full or partial netlists.
The extract_sdc command generates the <xxx>_mentor_modal_lower_pbs proc even when the Logictest
IP comes from non-Siemens EDA sources. The command only generates the other two if the IP comes
from Tessent TestKompress.

Hierarchical STA Procs Descriptions

The following describe the hierarchical STA procs in detail.
tessent_set_modal_lower_pbs
The tool creates this proc only for parent designs instantiating lower-level physical blocks.
The proc provides STA coverage of the Siemens EDA non-logictest DFT timing path going across the
physical block pins while blocking all other paths. Call it along with either the non-modal constraints of the
current design or the modal DFT STA constraints (membist, BISR, bscan, IJTAG, with disabled logictest).
You need to load some timing models for your lower physical block instances.
The proc does the following:

• Disables timing through your physical block interface pins, except those active used Siemens
EDA non-logictest DFT, such as the IJTAG pins, the BISR register pins, or the embedded
boundary scan control pins. All Siemens EDA logictest IP related pins are also disabled.

• Relaxes some paths in physical block’s IJTAG network.

• Blocks TCK from propagating to physical block logic through the eventual Siemens EDA OCC
muxes.
Assuming that your current hierarchical STA flow methodology may require loading a mix of black
boxes from lower physical blocks, extracted timing models, or backannotated netlists, the proc always
checks whether a physical block’s internal pin is actually loaded in memory before attempting to apply a
constraint to it. As a result, the call to the proc never errors out because of unloaded lower physical block
logic.
Disabling timing on all your physical block input’s clock pins purposely kills their non-DFT internal
functional timing paths. Likewise, physical block scan logic does not require any additional SDC
constraints, because of the following:

974 Tessent™ Shell User’s Manual

 Timing Constraints (SDC)
Hierarchical STA in Tessent

• The global scan_enable control signal is assumed already off in their parent design, leaving all
scan flops in functional mode.

• All physical block relevant logic (such as controllers, functional scan flops, LogicBist) receives no
clock.
The proc is called along with current level <xxx>_non_modal or Siemens EDA DFT modal constraints
procs to complete timing coverage of both non-modal synthesis and pre/post-layout modal STA steps.
The following is a typical example:

<load your current design files>

<load your lower physical blocks timing models or annotated netlist>
<link your design>
source ${tsdb}/dft_inserted_designs/.../${design}.sdc
tessent_set_default_variables
<override global variable values if needed>

The following example includes non-modal constraints (*):

<define your functional clocks and your timing exceptions>

tessent_set_non_modal <arg>
tessent_set_modal_lower_pbs
update_timing

Note:
The <arg> value is required only if your design contains Siemens EDA logictest IP.

The following example includes Tessent MemoryBIST modal constraints (*):

tessent_create_functional_clocks
tessent_set_ijtag_non_modal
tessent_set_jtag_bscan_non_modal
tessent_set_memory_bisr_non_modal
tessent_set_memory_bist_modal
tessent_kill_functional_paths
tessent_set_modal_lower_pbs
update_timing

(*) IJTAG constraints are always present in any design. The presence of all other procs are design-
dependent.
tessent_set_ltest_pb_external_mode
The tool creates this proc only for isolated physical blocks with the "ext_ltest_en" DFT signal present. It
forces ext_ltest_en active and int_ltest_en (if present) inactive. Use this call after a previous call to one
of the xxx_ltest_modal_xxx procs, to select the external mode version of your shift, bypass, or capture
modes. The proc merely forces the lower physical block’s ext_ltest_en and int_ltest_en DFT signals to
their external mode requirements. You should always call this proc when extracting your physical block’s
timing model for later use in your parent ltest STA modes, because it prevents ambiguous timing paths in
your extracted model timing arcs.

Tessent™ Shell User’s Manual 975

Timing Constraints (SDC)
Hierarchical STA in Tessent

Current-level <xxx>_ltest_modal* STA procs aim to cover both internal and external mode test paths in
the same STA run, despite that letting ext_ltest_en toggling may introduce a few false paths that could
affect your design timing closure. For most cases, it is a risk worth taking, because merging multiple STA
modes together is highly desirable for minimizing your total number of STA runs.
The following shows an example of this proc:

<load your current design files>

<link your design>
source ${tsdb}/dft_inserted_designs/…/${design}.sdc
tessent_set_default_variables
<override global variable values if needed>

# Extract one timing model per ltest mode

# Under some conditions, you can merge edt_shift and bypass_shift into
# "shift".
foreach mode {edt_shift bypass_shift edt_slow_capture} {
reset_design
tessent_set_ltest_modal_${mode}
tessent_set_ltest_pb_external_mode
set_propagated_clock [all_clocks]
update_timing
# SYNOPSYS PrimeTime-specific command
extract_model -output $design_name}_ext_${mode}_etm -format lib -library
}

<ltest_prefix>_lower_pbs_external_mode
The extract_sdc command writes this proc only for designs instantiating lower-level physical blocks
featuring the ext_ltest_en DFT signal. The objective of this proc is to set all lower physical blocks into
external mode when running one of the logictest STA modes at the parent level, which covers logictest
mode timing paths through the boundary pins of these physical blocks. Path coverage includes all logic
between the physical block pins and their wrapper cells, in addition to the wrapper chains shift mode
paths.
Assuming that your current hierarchical STA flow methodology may require loading a mix of black
boxes from lower physical blocks, extracted timing models, or back-annotated netlists, the proc always
checks whether a physical block’s internal pin is actually loaded in memory before attempting to apply a
constraint on it. As a result, the call to the proc never errors out because of unloaded lower physical block
logic.
Such constraints include:

• Preventing logictest slow clock reconvergent timing paths inside the physical block OCC logic.

• Asserting the ltest_en dft_signal.

• Asserting and deasserting the ext_ltest_en and int_ltest_en dft_signals.

• Deasserting the lbist_en dft_signal, if present.

• Conditionally asserting or deasserting the following dft_signals:

976 Tessent™ Shell User’s Manual

 Timing Constraints (SDC)
Mapping Procs

◦ edt_mode, int_edt_mode, ext_edt_mode, edt_bypass

◦ memory_bypass_en

◦ async_set_reset_static_disable

• Preventing false timing checks within the physical block OCC clock multiplexing logic.
The following shows an example of this proc:

<load your current design files>

<load your lower physical blocks timing models or netlist>
<link your design>
source ${tsdb}/dft_inserted_designs/…/${design}.sdc
tessent_set_default_variables
<override some global tessent Tcl variables value if needed>
foreach mode {shift edt_shift bypass_shift edt_slow_capture} {
reset_design
tessent_set_ltest_modal_${mode}
tessent_set_ltest_lower_pbs_external_mode
set_propagated_clock [all_clocks]
update_timing
<report_timing and other checks>
}

Mapping Procs
Because you can use the Tessent SDC constraints both pre- and post-synthesis, the tool must perform
some mapping to find all pins and cells with the pre-synthesis instance path.
The mapping is accomplished with the following procs:

• tessent_get_ports

• tessent_get_pins

• tessent_get_cells

• tessent_get_flops

• tessent_map_to_verilog

• tessent_remap_vhdl_path_list
The procs tessent_get_ports, tessent_get_pins, and tessent_get_cells are wrapper procs of the original
SDC commands get_ports, get_pins, and get_cells, and they are used throughout the Tessent SDC.
These wrapper procs use the tessent_map_to_verilog and tessent_remap_vhdl_path_list procs as
required. Use these mapping procs (as opposed to get_ports, get_pins, and get_cells) in your functional
SDC if you have a design with unrolled VHDL generate loops, and you have problems applying your

Tessent™ Shell User’s Manual 977

Timing Constraints (SDC)
Synthesis Helper Procs
functional SDC to the RTL. Refer to “Dealing With Unrolled VHDL Generate for Loops” on page 950 for
more information.
The tessent_get_flops proc runs the tessent_get_cells proc and then filters the result collection for
sequential elements. The proc uses a filtering method appropriate for the current tool.
The tessent_map_to_verilog proc adds wildcarding to pre-synthesis instance paths to match post-
synthesis instance paths for layout and STA. For example, the instance path core_inst/my_reg[0] would
return the pattern core_inst/my_reg?0?. This is to be able to match both the RTL instance path and the
post-synthesis path core_inst/my_reg_0_ even if "change_names ‑rules Verilog" was used. It also maps
the slash (/) coming from Tessent Shell instance paths to any user-defined "tessent_hierarchy_separator".
This proc is called by tessent_get_cells and tessent_get_pins. You should not need to call this proc
directly.
The tessent_remap_vhdl_path_list proc is used when the instance path cannot be found with the simple
mapping. It should only be needed when Tessent Shell has unrolled some VHDL generate loops to do
uniquified insertion in the instances within them. Refer to “Dealing With Unrolled VHDL Generate for
Loops” on page 950 for more information. The proc supports finding cells/instances that have a trimmed
last character, for example a closing brace or a question mark. This proc is called by tessent_get_cells
and tessent_get_pins if needed. You should not need to call this proc directly. You can also use the proc
in the unlikely event that your synthesis tool changed the names of cells in an unexpected way such as
trimming any trailing closing brace, for example my_reg[0] changed to my_reg_0 instead of the expected
my_reg_0_
If you require additional mapping capabilities, the tessent_map_to_verilog proc provides a method for
custom mapping of regular expressions/substitutions that run prior to the tool’s mapping process. To use
this, you must add your own mapping by defining the global array variable.
For example:

global tessent_custom_mapping_regsub
array set tessent_custom_mapping_regsub {
{\](/| |$)} {\1}
}

This example maps all RTL instance paths from the SDC file to remove any closing bracket preceding a
hierarchy separator (/) or at the end of the path (space for end of list element, $ for end of list). You would
need this mapping expression during your STA run if the synthesis tool was trimming the closing brace of
registers after a change_name. For example, my_reg[0] -> my_reg_0 instead of my_reg_0_ as expected.

Synthesis Helper Procs

To be able to apply Tessent Shell SDC constraints on your post-synthesis netlist, some steps are required
to preserve the boundary of certain instruments as well as to preserve certain "persistent" cells, which
must not be optimized away.
Three procs are provided to return the design instances that need to be boundary preserved, optimized,
or preserved:

• tessent_get_preserve_instances preservation_intent

• tessent_get_optimize_instances

• tessent_get_size_only_instances
tessent_get_preserve_instances preservation_intent returns a collection of instances whose boundaries
must be preserved. It must be provided an argument to establish the future use of the netlist and

978 Tessent™ Shell User’s Manual

 Timing Constraints (SDC)
Example Scripts Using Tessent Tool-Generated SDC
determine which instances need to be preserved. The "select" value you need to choose depends on
whether you intend to use your post-synthesis netlist with our tools. Here are the valid values for the
"select" argument, in increasing order of inclusiveness:

• add_core_instances
This usage selection returns instances that need to be preserved for applying SDC constraints
for STA to your post-synthesis design, and instances required for the TCD automation flow with
ATPG.

• scan_insertion
This usage selection returns all instances of the previous selection, plus any instance of modules
having existing scan segments described in a TCD scan file and non-scan instances (ICL
attribute keep_active_during_scan_test=true). This selection is required if you intend to do scan
insertion on your design with Tessent Shell or a third-party tool.

• icl_extract
This usage selection returns all instances of the two previous selections, plus any instance
of modules providing an ICL definition. This context is needed if you intend to go through the
DftSpecification flow again, this time with your gate level netlist. ICL extraction requires that all
ICL instances be present and traceable in the design.
If persistent cells added by Tessent Shell are RTL constructs (RTL cells or wrappers from the cell library),
they are returned by tessent_get_preserve_instances. If they are library leaf cells, they are not returned
by tessent_get_preserve_instances. Use the tessent_get_size_only_instances proc to obtain these (refer
to the following).
The tessent_get_optimize_instances proc returns a collection of child instances within Tessent
instruments whose boundaries can be optimized. This should be used when your synthesis tools
propagates boundary optimization attributes downward hierarchically.
The tessent_get_size_only_instances proc returns a collection of instances of all persistent cells,
although the collection may be empty under certain conditions. These cells are required to be intact to
apply SDC constraints for layout and STA. However, the synthesis tool can change the size of the driving
stage as needed.

Example Scripts Using Tessent

Tool-Generated SDC
Tessent supplies example Tcl scripts to use with the Tessent Shell tool-generated SDC.
Find these scripts in your installed release tree under the share directory:

• <installed release tree>/share/SDC/UsageExamples/design_compiler_synth.tcl

• <installed release tree>/share/SDC/UsageExamples/fusion_compiler_synth.tcl

• <installed release tree>/share/SDC/UsageExamples/genus_synth.tcl

• <installed release tree>/share/SDC/UsageExamples/primetime_sta.tcl

Tessent™ Shell User’s Manual 979

Timing Constraints (SDC)
Example Scripts Using Tessent Tool-Generated SDC

Tip
Refer to “Solutions for Genus Synthesis Issues” on page 1005 if you experience issues
®
synthesizing mixed Verilog/VHDL designs with the Cadence Genus™ Synthesis Solution.

980 Tessent™ Shell User’s Manual

 Appendix A
The Tessent Tcl Interface
Tessent Shell provides a Tcl-based command interface.

General Tcl Guidelines in Tessent Shell

Encoding Tcl Scripts in Tessent Shell
Guidelines for Modifying Existing Dofiles for Use With Tcl
Special Tcl Characters
Custom Tcl Packages in Tessent Shell
Tcl Resources

General Tcl Guidelines in Tessent Shell

If Tcl procedures are available in separate files, you can source these files from within the tool or dofiles.
You can also place Tcl procedures in a .tool_startup file so that they are available for use. Tcl file input/
output is also supported.
You should be aware of the following guidelines and behaviors when using Tcl in Tessent Shell:

• You can use Tcl variables interchangeably with legacy Tessent tool variables and environment
variables.

• You should use Tcl syntax for setting and referencing variables, including using
$env(<ENVARNAME>) for accessing environment variables.
For example, if the value of environment variable "ham" equals "mode1" ($ham = mode1), you
can compare this value to a Tcl variable value using the following syntax:

set eggs mode2

if {$env(ham) == $eggs} {puts Match} else {puts "No match"}

Note:
Use Tcl namespaces to avoid creating procedures that conflict with existing tool or Tcl
commands.

• When processing comments within a dofile, the tool does not write comments preceded with "//"
characters to the transcript. However, the tool does write comments that are preceded with a
pound sign (#) (the Tcl comment delimiter) to the transcript.

• A variable can contain a command string or be empty; attempting to run by referencing $variable
results in an error if $variable is empty.

• When a tool command error occurs, the command interpreter prints the error message and does
not return anything.

Tessent™ Shell User’s Manual 981

The Tessent Tcl Interface
General Tcl Guidelines in Tessent Shell

• You can use the catch_output command to issue a specified tool command line and prevent
command errors from aborting an enclosing dofile or Tcl proc. The catch_output command can
optionally capture the output of a command or the returned result.

• When a command error occurs nested inside a Tcl construct or Tcl proc, you can obtain additional
information about the error by issuing the following command:
> set errorInfo

This command prints the value of the $errorInfo Tcl variable, which may contain a traceback of
the nested Tcl calls so that you can determine the root cause of the error.

Difference Between the Dofile Command and the Tcl Source Command
You normally use the tool’s dofile command to run a file of tool commands. The Tcl source command also
runs a file of commands, but you should only use it to load Tcl procs, set Tcl variables, or do other strictly
Tcl commands.
You should use the dofile command to run a command file containing tool commands for the following
reasons:

• The dofile command is affected by the set_tcl_shell_options ‑abort_dofile_on_error command,

which provides you with the ability to specify whether the tool aborts when an error condition is
detected. The Tcl source command is not affected by the ‑abort_dofile_on_error option.

• The dofile command transcripts the commands to the shell and logfile. The Tcl "source" command
always stops running if any command in the file encounters an error.

Example 1
In this example, the add_scan_chains command defines every scan chain in the design. This command is
sometimes used hundreds of times and makes the dofile very long. Using Tcl, you can shorten the dofile
substantially by using a loop construct as shown here:

for {set xx 1} {$xx < 257} {incr xx} {

add_scan_chains int chain$xx group1 /top/edt_si$xx /top/edt_so$xx
}

For the values of xx from 1 up to 256, the tool runs a separate add_scan_chains command for each
value. The transcript and logfile contain all 256 add_scan_chains commands (preceded with "//
subcommand: ").

Example 2
The following example controls the flow of creating test patterns and uses a variable to run different
commands based on the variable’s value:

if {$mode == stuck} {
set_fault_type stuck
…
} elseif {$mode == transition} {

982 Tessent™ Shell User’s Manual

 The Tessent Tcl Interface
Encoding Tcl Scripts in Tessent Shell
set_fault_type transition
set_pattern_type -sequential 2
…
}

Example 3
Module hierarchies may become ungrouped through either synthesis or layout and ATPG may operate
on a flattened view of the design. Automated DRCs find and trace the EDT IP and subsequently find and
trace the flattened scan chains automatically. In the following example, we are capturing the output of the
report_scan_chains command and placing it into the variable rsc by using the catch_output command.
The foreach loop iterates on the report_scan_chains output, capturing the chain name, group name
and input and output connections in the variables chain, group, input, and output, respectively. This
information is written into the file add_chains.txt.

set out [open "add_chains.txt" w]

catch_output {report_scan_chains} -output rsc
set rsc1 [split $rsc "\n"]

foreach a $rsc1 {
puts "NEWLINE =\t$a"
regexp {.*chain = (.*)\s+group = (.*)\s+input = \'(.*)\'\s+output = \
'(.*)\'\s+.*} $a match chain group input output
puts $out "add_scan_chains -internal $chain $group \{$input\} \{$output\
}"
}

close $out

Encoding Tcl Scripts in Tessent Shell

Tessent Shell enables the distribution of custom Tcl scripts without exposing the source code.
Tessent Shell reads files encoded by the encode_tcl_scripts command with Tcl’s existing source
command and decodes them automatically. Tessent Shell blocks introspection of the procedures in the
file by Tcl’s info body command, but the procedure names are visible with the info procs command.
For details on how to use the encode_tcl_scripts command, refer to the Tessent Shell Reference Manual.

Guidelines for Modifying Existing Dofiles for

Use With Tcl
When using an existing dofile with the Tcl interface, you should evaluate the dofile for issues that could
cause incorrect evaluation by the Tessent Tcl interpreter.
Table 55 provides guidance for correcting common dofile issues.
The most common issues you can run across with an existing dofile is accounting for Tcl special
characters. For more information, refer to Table 56 on page 985, which provides a list of typically-used
Tcl special characters.

Tessent™ Shell User’s Manual 983

The Tessent Tcl Interface
Guidelines for Modifying Existing Dofiles for Use With Tcl

Table 55. Common Dofile Issues and Solutions

Dofile Issue Solution

Stopping dofile runs at a specific Use the native Tcl "error" command to stop the run of a dofile
point at any point. The "error" command requires a message string,
which the tool outputs. But to avoid any message you can use an
empty string:
error ""

Escaping Tcl special characters Use the following techniques to escape Tcl special characters:
• Quotation marks ("") group tokens but enable $variable and
[command] evaluations.
• Braces ({}) also group tokens and disable $variable and
[command] evaluations.
• Brackets ([]) implement command substitution and are used to
nest or embed commands.
• A backslash (\) escapes the next character. Use this to tame a
Tcl special character such as $, [, {, or ".

Using dollar signs in pathnames A dollar sign ($) specifies variable substitution. In some netlists,
pathnames (for example, ham/pin$p7) can contain the dollar
sign. When using pathnames with dollar signs, enclose the
pathname with braces ({ }) to prevent the tool from substituting
the value as shown in the following example:
report_gates {ham/pin$p7}

Escaping quotation marks In Tcl, quotation marks ("") instruct the Tcl interpreter to treat the
enclosed words as a single argument. For example:
puts " Hello World "

If embedded quotation marks are required, you must use

backslashes ( \ ) to escape the embedded quotation marks. For
example:
puts " Hello \"World\" "

Otherwise, the tool issues an error message.

Using brackets Brackets ([ ]) implement command substitution and are used

to nest or embed commands. A command and its arguments
enclosed in square brackets is evaluated and its result inserted in
place in the enclosing command.

Optional single quotation marks Optional single quotation marks (' ') are no longer valid for
Tessent commands. For example, the following produces an
error:
set_design_sources '-v MODB.v -v MODC.v'

Correct this by using no quotation marks or braces:

set_design_sources -v MODB.v -v MODC.v
set_design_sources "-v MODB.v -v MODC.v"

984 Tessent™ Shell User’s Manual

 The Tessent Tcl Interface
Special Tcl Characters

Table 55. Common Dofile Issues and Solutions (continued)

Dofile Issue Solution

set_design_sources {-v MODB.v -v MODC.v}

Environment variables You should use Tcl syntax for setting and referencing variables,
including using $env(ENVARNAME) for accessing environment
variables. For example, if the value of environment variable
"ham" equals "mode1" ($ham = mode1), you can compare this
value to a Tcl variable value using the following syntax:

set eggs mode2

if {$env(ham) == $eggs}
{puts "Match"}
else
{puts "No match"}

Special Tcl Characters

In Tcl scripts, you often find characters used for special purposes. For a complete list of special
characters, you should consult a Tcl resource.
Table 56 lists and describes the more common special characters you can encounter when reading the
examples in this manual. Refer to the additional resources described in “Tcl Resources” on page 987.

Table 56. Common Tcl Characters

Character Description

; The semicolon terminates the previous command, enabling you to place more than one
command on the same line.

\ Used at the end of a line, the backslash continues a command on the following line.

\$ The backslash with other special characters, like a dollar sign, instructs the Tcl
interpreter to treat the character literally.

\n The backslash with the letter "n" instructs the Tcl interpreter to create a new line.

$ The dollar sign in front of a variable name instructs the Tcl interpreter to access the value
stored in the variable.

[] Square brackets group a command and its arguments, instructing the Tcl interpreter
to treat everything within the brackets as a single syntactical object. You use square
brackets to write nested commands. For example:
set chain_report [report_scan_chains -subchains -verbose]

{} Braces instruct the Tcl interpreter to treat the enclosed words as a single string. The
Tcl interpreter accepts the string as is, without performing any variable substitution or
evaluation. For example, to create a string that contains special characters such as $ or
\:

Tessent™ Shell User’s Manual 985

The Tessent Tcl Interface
Special Tcl Characters

Table 56. Common Tcl Characters (continued)

Character Description

set my_string {This book costs $25.98.}

"" Quotation marks instruct the Tcl interpreter to treat the enclosed words as a single string.
However, when the Tcl interpreter encounters variables or commands within string in
quotation marks, it evaluates the variables and commands to generate a string. For
example, to create a string that displays a final cost calculated by adding two numbers:
set my_string "This book costs \$[expr $price + $tax]"

# The pound sign (#) indicates a comment and directs the Tcl compiler to not evaluate the
rest of the line. When using the pound sign, you must use it where a command starts,
and at the beginning of a command, not within a command. Be aware of the following:
• Evaluate does not equal parse. Despite the pound sign, the following comment gives
an error because Tcl detects an open lexical clause.

# if (some condition) {
if { new text condition } {
…
}

• The apparent beginning of a line is not always the beginning of a command:

# This is a comment

In the following code snippet, the line beginning with "# -type" is not a comment,
because the line immediately preceding it has a line continuation character (\). In fact,
the Tcl interpreter does not interpret the "#" character as you might expect, resulting in
an error when it attempts to create the tk_messageBox.

tk_messageBox -message "The diagnosis report was successfully

written."\
# -type ok

# and this is also a comment. This one spans \

multiple lines, even without the # at the beginning \
of the second and third lines.

In general, it is good practice to begin all comment lines with a #. Be aware that the
beginning of a command is not always at the beginning of a line. Usually, you begin new
commands at the beginning of a line. That is, the first non-space character is the first
character of the command name. However, you can combine multiple commands into
one line using the semicolon ";" to designate the end of the previous command:

set myname "John Doe" ; set this_string "next command"

set yourname "Ted Smith" ; # this is a comment

986 Tessent™ Shell User’s Manual

 The Tessent Tcl Interface
Custom Tcl Packages in Tessent Shell

Custom Tcl Packages in Tessent Shell

Tessent Shell supports several standard techniques for adding your own Tcl packages with the Tcl
"package require" command, which you can issue from Tessent Shell.
You can use any of the following ways to specify directory locations of Tcl packages. Any directory that
contains a Tcl package must also contain a pkgIndex.tcl file within its hierarchy. The following methods
are listed in order of the precedence in effect if there is more than one package with the same name:

• Default location for Tessent Shell Tcl packages. You can place your package underneath a
directory named tessent_plugin/packages that is located at the top of your Tessent install tree.
When Tessent Shell finds a package in this directory upon invocation, it appends the directory
path to tessent_plugin/packages to the auto_path Tcl global variable, if it exists.

• TESSENT_PLUGIN_PATH environment variable. You can set this variable to a colon-separated

list of directory paths that contain Tcl packages in a packages subdirectory. When Tessent Shell
finds a package, it appends the directory path to packages to the auto_path Tcl global variable, if
it exists.

• auto_path Tcl global variable. You can issue the following command in Tessent Shell to specify a
package location:

> lappend auto_path pathToTclPackageDir

• TCLLIBPATH environment variable. You can set this variable to a space-separated list of
directory paths that contain Tcl packages. A packages subdirectory is not required under any of
the paths.

Note:
Tessent Shell ignores the TCL_LIBRARY environment variable.

Tcl Resources
The following website is a place to start in your search for the reference material that works best for you.
It is not an endorsement of any book or website.
https://www.tcl-lang.org

Tessent™ Shell User’s Manual 987

The Tessent Tcl Interface
Tcl Resources

988 Tessent™ Shell User’s Manual

 Appendix B
Synthesis Guidelines for RTL Designs With
Tessent Inserted DFT
This appendix provides guidelines for you to use when synthesizing your design with Tessent created IP
RTL with a third-party synthesis tool, specifically Synopsys DC Ultra™.
You may experience problems with synthesis optimization using DC Ultra caused by propagating
constants even if the boundary optimization is false. This synthesis optimization results in some of the
DFT logic that is not connected until scan insertion being optimized away, and the ports being kept. This
creates a situation where some of the necessary Tessent logic is eliminated during optimization, which
breaks the design.

Figure 302. Problem Occurrence Creating the Gate Level Netlist

This problem does not appear to be present with the basic DC compile command; it seems to only be an
issue when using the compile_ultra command in certain tool versions.

DFT Insertion With Tessent

Synthesis Guidelines
SystemVerilog and Port Name Matching
Synthesis Guidelines for Parameterization Wrapper Flows

DFT Insertion With Tessent

When the Tessent tools create the IP logic to add to the design, the logic includes some persistent
instances that are used as anchor points for items such as clocks, control signals, constraints, and so on.
For automation, the tool uses modules and port matching, and, consequently, requires that some specific
modules be preserved after synthesis and place and route.
There are two types of persistent instances for synthesis:

Tessent™ Shell User’s Manual 989

Synthesis Guidelines for RTL Designs With Tessent Inserted DFT
DFT Insertion With Tessent

• Cells

◦ Requires the use of a set_size_only command

• Design Modules

◦ Requires ungroup to be set to off

◦ Requires boundary optimization to be set to off

Boundaries of all instances of modules with Tessent Core Descriptions (TCDs) need to be preserved,
which means the following:

• No boundary optimization.

• No ungrouping.

• No new ports.

• No logic optimization.
The logic test module types that require this include EDT, LBIST, OCC, STI SIB, Bscan interface, and any
module with tcd_scan (pre-existing scan chain). ICL extraction uses modules and ports of ICL modules
so they also need to be preserved. You can avoid preserving the IJTAG instance boundaries, which
enables the synthesis tool to obtain a better optimization result. You can use the ICL file from RTL in post
synthesis and place and route.
The boundary optimization option during synthesis is global in the sense that it applies to every design
hierarchy on and below the specified module or instance. Hence, if you want to globally optimize your
design, you specify it on the root (top) module and then boundary optimization runs through the entire
design doing its work (assuming that there are no "don’t touch" cores, which were already synthesized
earlier). The problem is that valid constrained or not (yet) connected ports or nets get optimized away. To
prevent this, tell the DC tool not to apply this boundary optimization to selected modules or instances.
DC has two compilation modes:

• Basic compile (using the compile command):

◦ Problems are avoided because the tool does not ungroup and optimize boundaries.

◦ Constants are not optimized away.

• Optimization On (using compile_ultra command):

◦ The synthesis tool does its best to remove any dead logic (either because of constraints
propagation or missing loads or unused).

◦ DC propagates constraints even if boundary optimization is set false for design instances.
As this issue is becoming more prevalent, there is an informational message from DC Ultra when using
the compile_ultra command that reports the following:

990 Tessent™ Shell User’s Manual

 Synthesis Guidelines for RTL Designs With Tessent Inserted DFT
Synthesis Guidelines

Information: Starting from 2013.12 release, constant propagation is

enabled even when boundary optimization is disabled. (OPT-1318)

If you receive this message, you may not fully understand the ramifications or how to correctly synthesize
the Tessent IP in this environment. If not properly handled, you may observe additional information
messages from the tool similar to the following:

Information: Removing unused design 'corea_rtl_tessent_occ_shift_reg_1'.

(OPT-1055)
Information: The register
'corea_rtl_tessent_occ_clka_inst/occ_control/scan_out_reg' is a constant
and will be removed. (OPT-1206)
Information: Ungrouping hierarchy tessent_persistent_cell_edt_clock before
Pass 1 (OPT-776)

Synthesis Guidelines
When synthesizing a design for Tessent DFT, certain considerations must be taken into account to avoid
issues later in the flow.
When using Cadence Genus, set the attribute hdl_flatten_complex_port to "true" for any designs that
include complex ports declared using unions to facilitate post-synthesis port name matching.
When using any of the Synopsys Design Compiler family of synthesis tools, declare the ranges of any
ports declared as SystemVerilog interface arrays be declared as follows to facilitate post-synthesis port-
name matching:

<interface_type> <port_name> [0:<positive right index>]

When using DC Ultra, there are two key commands to be aware of to synthesize correctly with the
Tessent IP.

• Turn off constant propagation with no boundary optimization by setting an application variable.
This variable works globally and is used with the following syntax:

set_app_var compile_enable_constant_propagation_with_no_boundary_opt false

• For instance level control, use the following compile directive before using the compile_ultra
command to turn off the constant propagation for cells:

set_compile_directives -constant_propagation false [get_cells

<hier-cell-name>]

Or for pin-level granularity, use the following command:

set_compile_directives -constant_propagation false [get_pins <hier-pin-name>]

Other means of restricting the synthesis tool from changing and optimizing instances and levels of
hierarchy include the set_size_only command and ungrouping. When set_size_only is used for a
specified list of leaf cells, the tool can only change their drive strength, or sizing. The ungroup, group,
set_ungroup, and uniquify commands can be used to control how the tool removes (or not) levels of

Tessent™ Shell User’s Manual 991

Synthesis Guidelines for RTL Designs With Tessent Inserted DFT
Synthesis Guidelines
hierarchy and how reused blocks are uniqified during synthesis. The dont_touch attribute is also effective
for adding to designs, sub designs, and cells to prevent them from being ungrouped during optimization.

Note:
During the synthesis of MemoryBIST logic, there are two types of warnings that may be issued by
synthesis tools that are related to the optimization of registers. These warnings may be ignored
as synthesis tools are very reliable. Additionally, formal verification can be used to confirm the
functionality is not affected. The warning types are:
• Registers with no fanout are removed, along with the combinational logic driving the inputs.
• Registers with inputs and outputs that are always identical are merged.

Different guidelines apply to the type of flow you are using, whether a bottom-up synthesis flow, or a top-
down approach.

Bottom-Up Flow Using DC Ultra

1. Read full design in synthesis tool.

2. Set current design to each DFT IP and compile.

3. Set don’t touch or set size only to all the DFT IP.

4. Set current design TOP.

5. Read functional SDC.

6. Read DFT SDC.

7. Set ungroup false to all DFT IP and persistent modules.

8. Set boundary optimization false to all DFT IP and persistent modules.

9. Set size only to all persistent cells.

10. Disable constant propagation during boundary optimization.

11. Compile ultra.

Top-Down Flow Using DC Ultra

1. Read full design in synthesis tool.

2. Read functional SDC.

3. Read DFT SDC.

4. Set ungroup false to all DFT IP and persistent modules.

992 Tessent™ Shell User’s Manual

 Synthesis Guidelines for RTL Designs With Tessent Inserted DFT
SystemVerilog and Port Name Matching

5. Set boundary optimization false to all DFT IP and persistent modules.

6. Set size only to all persistent cells.

7. Disable constant propagation during boundary optimization.

8. Compile ultra.

SystemVerilog and Port Name Matching

Any ports declared as interface arrays in a SystemVerilog RTL design should be declared as follows:

<interface_type><port_name>[0:<N>]

<N> is a positive integer that represents the size of the array minus 1. You can use this method to
properly map the port names in a netlist generated by any of the Design Compiler family of tools.

Tessent™ Shell User’s Manual 993

Synthesis Guidelines for RTL Designs With Tessent Inserted DFT
Synthesis Guidelines for Parameterization Wrapper Flows

Synthesis Guidelines for Parameterization

Wrapper Flows
We recommend using or adapting the script and Tcl procedures in this section for the parameterization
wrapper flows. Tessent Shell supplies the Tcl procedures for interoperability with third-party synthesis
tools to help you manage the multiple files required for parameterized designs.

Note:
To use the Tcl procedures, you must run the process_parameterized_design_specification
command before the RTL DFT insertion steps for the blocks in your design.
After the RTL DFT insertion steps for a block, run the write_design_import_script
‑include_child_physical_block_interface_modules command. This command generates the
prerequisite files for the Tcl procedures that help you manage synthesis. Refer to “How to Handle
Parameterized Blocks During DFT Insertion” on page 680 for more information about creating and
using parameterization wrappers.

The set of Tcl procedures in “Tcl Procedures for Synthesis in the Parameterization Wrapper Flow” on
page 995 and the example script in this section are designed for interoperability with the Synopsys
®
Design Compiler tool (dc_shell). If you are using another synthesis tool, we recommend adapting these
procedures for use with that tool.
You can use these procedures for synthesis of all parameterized blocks, including the following situations:

• The block is parameterized and is instantiated with parameter overrides. The block does not
instantiate parameterized child blocks with parameter overrides.

• The block is parameterized and is instantiated with parameter overrides. The block does
instantiate parameterized child blocks with parameter overrides.

• The block is not parameterized or is not instantiated with parameter overrides; however, the block
instantiates one or more parameterized child blocks with parameter overrides.
Use or adapt the following example script. Invoke the script from the same directory where the
write_design_import_script command wrote the loading scripts for the RTL design files for the block.

# Parameters for the rest of the synthesis script.

set design_name <design_name>
set design_id <design_id>
set tsdb <tsdb_path>
set preserve_type icl_extract
# Clock(s) to create on the design
set clock_dictionary { <port_name> { <period> <clock_name> } }
# Directives to the synthesis tool. Add others for your flow.
set_app_var hdlin_enable_upf_compatible_naming true
set_app_var timing_enable_multiple_clocks_per_reg true
set_app_var compile_enable_constant_propagation_with_no_boundary_opt \
false
set_app_var compile_seqmap_propagate_high_effort false
set_app_var compile_delete_unloaded_sequential_cells false
# The following directives may be useful - your decision.

994 Tessent™ Shell User’s Manual

 Synthesis Guidelines for RTL Designs With Tessent Inserted DFT
Tcl Procedures for Synthesis in the Parameterization Wrapper Flow
set_app_var sh_continue_on_error false
set_app_var sh_script_stop_severity E
source <path_to_synthesis_flow_procs>/flow_procs.tcl
# Invoke top-level proc
synthesize_block $design_name $design_id $tsdb \
-preserve_type $preserve_type \
-clock_dictionary_name clock_dictionary

Tcl Procedures for Synthesis in the Parameterization Wrapper Flow

Tcl Procedures for Synthesis in the

Parameterization Wrapper Flow
Tessent supplies Tcl procedures (procs) for synthesis to aid interoperability with third-party synthesis tools
for blocks in parameterized block hierarchies.
The synthesize_block and other procedures in the following Tcl files target dc_shell, which is the
®
Synopsys Design Compiler tool. If you are using another synthesis tool, Siemens EDA recommends
adapting the procedures they contain:

• flows_procs.tcl — contains the synthesize_block and synthesize_view procedures.

• support_procs.tcl — contains support procedures used in flow_procs.tcl.

Note:
The synthesize_block procedure is the top-level proc to call from your synthesis script. The
flow_procs.tcl file has usage instructions at the top.

Find these Tcl files in your installed release tree under the share directory:

• <installed release tree>/share/ParamWrappers/SynthScripts/flows_procs.tcl

• <installed release tree>/share/ParamWrappers/SynthScripts/support_procs.tcl

Refer to “How to Handle Parameterized Blocks During DFT Insertion” on page 680 for more
information about different design scenarios and their impact on the DFT insertion process when using
parameterization wrappers.
The Tcl procedures source and parse one or two files generated by the
process_parameterized_design_specification command for parameterized blocks or blocks that
instantiate parameterized blocks.

• The <design_name>.parameterization_wrapper_info_dictionary file is generated for all

parameterized blocks. The following is a template for this file:

set parameterization_wrapper_info_dictionary {
<design_name> {
parameterized_view_<i> {
// <i> is an integer starting at 1. Omitted if only one view.
post_synthesis_uniquified_block_name <post_synthesis_name>
parameterization_wrapper_file_name \

Tessent™ Shell User’s Manual 995

Synthesis Guidelines for RTL Designs With Tessent Inserted DFT
Tcl Procedures for Synthesis in the Parameterization Wrapper Flow
<post_synthesis_name>.<lang>_parameterization_wrapper
block_instance_list_in_parent <list of instances which \
instantiate above view>
}
… // Additional views
}
}

• The <design_name>.consolidated_child_blocks_info_dictionary file is generated for blocks that

instantiate parameterized child blocks. The following is a template for that file:

set consolidated_child_blocks_info_dictionary {
<child_block_design_name> {
parameterized_view_<i> {
// <i> is an integer starting at 1. Omitted if only one view.
post_synthesis_uniquified_block_name <post_synthesis_name>
parameterization_wrapper_file_name \
<post_synthesis_name>.<lang>_parameterization_wrapper
block_instance_list_in_parent <list of instances which \
instantiate above view>
}
… // Additional views
}
… // Additional child blocks
}

996 Tessent™ Shell User’s Manual

 Appendix C
Clocking Architecture Examples
The clocking architecture in designs may vary, and they play a role during test planning, especially for
hierarchical test.
This appendix provides examples of common clocking architectures and how to insert the on-chip clock
controllers (OCCs) given those architectures. The examples assume that you are performing hierarchical
test as described in “DFT Architecture Guidelines for Hierarchical Designs” on page 125".
For information about the OCCs supported by Tessent, refer to "Tessent On-Chip Clock Controller" in the
Tessent Scan and ATPG User’s Manual.

Clocks Driven by Primary Inputs

Clock Generators Outside the Cores
Clock Generators Inside the Cores
Clock Sourced From a Core With Embedded PLL
Clock Mesh Synthesis

Clocks Driven by Primary Inputs

In the following figure, coreA and coreB are wrapped cores, and the clk_r and clk_g clocks are
asynchronous to each other. Insert standard OCCs inside coreA and coreB for both clk_r and clk_g. At
the chip-level, insert standard OCCs on the clk_r and clk_g ports.

Figure 303. OCCs for Clocks Driven by Primary Inputs

During intest mode for the wrapped cores, the OCCs inside the cores are active and the OCCs outside
the cores are inactive. During extest, the OCCs outside the cores are active and the OCCs inside the
cores are inactive.

Clock Generators Outside the Cores

In the following figure, coreA and coreB are wrapped cores, and a clock generator at the chip level divides
the clock frequency by half to generate the green clock. The red and green clocks are asynchronous
to each other. Insert standard OCCs inside coreA and coreB for both the red and green clocks. At the

Tessent™ Shell User’s Manual 997

Clocking Architecture Examples
Clock Generators Inside the Cores
chip-level, insert standard OCCs on both the red and green clocks generated at the output of the clock
generator.

Figure 304. OCCs With Clock Generators at Chip Level, Asynchronous Clocks

Clock Generators Inside the Cores

In the following example, coreA and coreB are wrapped cores and a clock generator is located inside
coreA. The red and green clocks are asynchronous to each other inside coreA, so you would insert
standard OCCs inside coreA. In addition, the red and purple clocks are asynchronous to each other, so
you insert standard OCCs for these clocks inside coreB as well as at the chip-level.

Figure 305. OCCs With Clock Generators Inside the Cores, Asynchronous Clocks

During intest mode for the wrapped cores, the OCCs inside the cores are active, and the OCCs outside
the cores are inactive. During extest, the OCCs outside the cores are active, and the OCCs inside the
cores are inactive.

Clock Sourced From a Core With Embedded

PLL
In the following figure, coreA and coreB are wrapped cores, and coreB contains an embedded PLL
module. coreB sources the clock that feeds both coreA and the chip. In this case, you would retarget
coreA and coreB at the same time.

998 Tessent™ Shell User’s Manual

 Clocking Architecture Examples
Clock Mesh Synthesis

Figure 306. Clock Sourced From a Core With Embedded PLL, With MUX

When you are retargeting coreA and coreB at the same time, you must add a mux. Use a clock net before
reaching the OCC inside coreB as a clock to feed the OCC inside coreA to avoid having back-to-back
OCCs. To retarget both coreA and coreB at the same time, the OCCs inside coreA and coreB must be
active at the same time.
Insert standard OCCs inside the cores. The standard OCC inside the core with the embedded PLL
(coreB) gets promoted so that it is also included in the external chains. When in external mode, the OCC
inside coreB can be reused. For details, refer to “How to Handle Clocks Sourced by Embedded PLLs
During Logic Test” on page 704.
During intest, the standard OCCs inside coreA and coreB are active. The mux is set to 1 to avoid
cascading OCCs. During extest, only the promoted standard OCC within coreB is active, and the mux is
held at 0.
In the following example, you are retargeting coreA and coreB in separate runs, so there is no need to
insert a mux. During intest of coreA, only coreA’s OCC is active, and then during intest of coreB, only
coreB’s OCC is active. During extest of the cores, only the promoted standard OCC within coreB is active.

Figure 307. Clock Sourced From a Core With Embedded PLL, Without MUX

Clock Mesh Synthesis

The most common method for clock balancing is clock tree synthesis. However, you can also use clock
mesh synthesis to balance the clocks. For clock mesh, rather than standard OCCs, use parent OCCs
at the chip level and child OCCs inside the wrapped cores. In the following figure, coreA and coreB are
wrapped cores, and the clk_r and clk_g clocks are asynchronous to each other.

Tessent™ Shell User’s Manual 999

Clocking Architecture Examples
Clock Mesh Synthesis

Figure 308. Clock Mesh Synthesis

Core-level child OCCs have additional timing requirements because a single clock on the boundary
of the wrapped core is used for shift as well as for slow and fast capture. For details, refer to
"Recommendations" in the Tessent Scan and ATPG User’s Manual. Using SDC for timing closure is
described in “Timing Constraints (SDC)” on page 935.
During intest of coreA and coreB, the child OCCs are active, and the parent OCCs are in parent mode.
During extest of coreA and coreB, the parent OCCs are in standard mode and the child OCCs are
inactive.

1000 Tessent™ Shell User’s Manual

 Appendix D
Formal Verification
Tessent™ Shell-based products do not generate scripts for use with formal verification tools such as
® ® ® ®
Synopsys Formality or Cadence Conformal . You can, however, set constraints in your design that
are used with these tools.
For EDT, constraining scan_en to 0 is sufficient to proceed with equivalence checking. The formal
verification tool reports some unmatched nodes (such as the newly added EDT pins, clock/update/
bypass/low_power/channel) and registers inside the EDT logic.
For OCC, if it has an IjtagInterface, or if the test_mode pin of the OCC is connected to an IjtagNetwork,
then keeping the IJTAG network in the reset state is sufficient. If the test_mode pin is connected to a top-
level port, this port needs to be constrained to 0.
The following sections provide guidance on how to set up formal verification. Use the correct syntax for
your chosen tool.

Golden RTL Versus DFT‑Inserted RTL

Pre-Layout Versus Post-Layout
Embedded Boundary Scan at the Physical Block Level

Golden RTL Versus DFT‑Inserted RTL

Use the following guidance to create a script for use with your formal verification of golden RTL versus
DFT-inserted RTL.
Set the following:

• Set the circuit to functional mode to hold the IJTAG network or TAP in reset.

• If you are at the chip level, set a constant 0 on TRST. If you are at the sub_block or
physical_block level, set a constant on the ijtag_reset ports to their active value. This is typically
0.

• If your design has DftSignals coming from ports in both the chip and design levels, these ports
must be held at their reset values. The reset automatically handles DftSignals from the TDR.

• If you are at the sub_block or physical_block level, suppress the verification of ports created by
Tessent Shell to prevent reporting violations.

• Assert the ijtag_reset pins to their active values on all instruments and SIBs inserted by Tessent
tools.

• Because the ICL network may already be present, the SIBs could result in mismatches on the ICL
network scan path. Set the SIB scan in/outs as "don’t verify" points.

• Use the "Consistency" mode for the verification passing mode rather than the "Equality" mode by
setting the following:

Tessent™ Shell User’s Manual 1001

Formal Verification
Pre-Layout Versus Post-Layout

set verification_passing_mode Consistency

The default verification passing mode of Formality is the "Consistency" mode.

• If you want to use the "Equality" mode for verification, add the following setting to deal with clock
gating logic inserted by Tessent:

set_app_var verification_clock_gate_hold_mode any

Pre-Layout Versus Post-Layout

Use the following guidance to create a script for use with your formal verification of pre-layout versus
post-layout.
Ensure that the layout step did not affect DFT functionality. Ignore violations caused by scan chain
reordering. Also, constrain the scan_en signal low, but do not constrain anything else on the inserted DFT.
Tessent Shell may insert lockup elements at the end of the scan chains during scan insertion. These are
marked as stop points in the scanDEF file and are not reordered. After scan chain reordering, you may
find mismatches on these lockup latches during layout.
For example:

GPIO_2/\p2out_reg[1] ( IN SI ) ( OUT Q )
+ STOP GPIO_2/ts_1_lockup_latchn_clkc6_intno266_i D\

When this occurs, and you perform formal verification on the pre- versus post-layout, the tool returns
warnings that these lockup latches are no longer connected to the same functional flop as previously.
This is not an issue with the other scan flops because you can disable the scan path by setting the scan
enable to 0. However, the lockup latch is a flop/latch without scan-in.
If you encounter this situation, use the following workaround: Specify set_dont_verify_point for the lockup
latches in both the reference and implemented designs to determine if formal verification passes. To find
the lockup latches, introspect the design in Tessent Shell using the following:

get_instances ts_1_lockup*

Embedded Boundary Scan at the Physical

Block Level
Use the following guidance to create a script for use with your formal verification checking tool.
Most signals are blocked by the bscan_select signal, but you should set the following:

• add_pin_constraints 0 bscan_select ‑golden

• add_pin_constraints 0 bscan_select ‑revised

• add_ignored_outputs bscan_scan_out ‑golden

1002 Tessent™ Shell User’s Manual

 Formal Verification
Embedded Boundary Scan at the Physical Block Level

• add_ignored_outputs bscan_scan_out ‑revised

• add_pin_constraints 0 bscan_force_disable ‑both

• add_pin_constraints 0 bscan_select_jtag_output ‑both

• add_pin_constraints 0 bscan_clock ‑both

• add_pin_constraints 0 bscan_select_jtag_input ‑both

Tessent™ Shell User’s Manual 1003

Formal Verification
Embedded Boundary Scan at the Physical Block Level

1004 Tessent™ Shell User’s Manual

 Appendix E
Solutions for Genus Synthesis Issues
You may encounter some issues when using Cadence Genus to synthesize mixed Verilog/VHDL designs.
This section describes some common issues and proposed solutions.

• Problem: There is a mismatch between the port list of the VHDL component definition for a
memory and the port list of an auto-created blackbox for the memory. — Solution:

◦ Use the Synopsys translate_off/translate_on pragmas to effectively comment out everything

in the memory module definition after the port list. This avoids performance issues during
synthesis.

◦ In the Genus synthesis script for synthesizing a design that instantiates one or more
memories, do the following:

• Load the file containing the memory module definition with the internals surrounded by
pragmas, as mentioned in the previous solution. This avoids creating a blackbox with a
mismatch between the port list in the VHDL component definition of the memory and the
port list of the blackbox.

• Immediately after elaborating the design, add the following lines to prevent the memory
definition from being written to the netlist:

set mem_mod [vfind . -module "<name of the memory module>"]

set_db $mem_mod .write_vlog_skip_subdesign true

• Problem: A blackbox for a memory is written to the netlist. — In the Genus synthesis script
for synthesizing a design that instantiates one or more memories, do the following:

◦ Immediately after elaborating the design, add the following lines to prevent the memory
definition from being written to the netlist:

set mem_mod [vfind . -module "<name of the memory module>"]

set_db $mem_mod .write_vlog_skip_subdesign true

• Problem: Uniquification of logic abstracts for a memory. — These are simply unresolved
references. Only one such logic abstract should be created. Set the following root attribute before
loading/elaborating the design to prevent uniquification of logic abstracts:

set_db / .write_vlog_empty_module_for_logic_abstract false

Tessent™ Shell User’s Manual 1005

Solutions for Genus Synthesis Issues

1006 Tessent™ Shell User’s Manual

 Appendix F
Getting Help
There are several ways to get help when setting up and using Tessent software tools. Depending on your
need, help is available from documentation, online command help, and Siemens EDA Support.

The Tessent Documentation System

Global Customer Support and Success

The Tessent Documentation System

From the Tessent 2024.1 release, Siemens provides an improved method to access your Siemens Digital
Industries Software product documentation. The default option serves your product documentation
from Support Center, giving you immediate access to the latest release-specific documentation, and an
enhanced search of HTML and PDF files. This new method also eliminates the requirement to install
product documentation as part of the local software installation.
For easy access, you can now view Support Center documentation using a documentation proxy on your
network. This documentation proxy removes the need for your users to have a Support Center account or
to log into Support Center to view documentation.
We understand that some customers use our products on restricted networks without internet access. You
have the option to download the documentation and set up a Siemens Documentation Server to view the
documentation package on your local network.
Refer to "Configuring Documentation Access" in the Managing Tessent Software manual for instructions
to set up the documentation proxy or the documentation server.

Global Customer Support and Success

A support contract with Siemens Digital Industries Software is a valuable investment in your
organization’s success. With a support contract, you have 24/7 access to the comprehensive and
personalized Support Center portal.
Support Center features an extensive knowledge base to quickly troubleshoot issues by product and
version. You can also download the latest releases, access the most up-to-date documentation, and
submit a support case through a streamlined process.
https://support.sw.siemens.com
If your site is under a current support contract, but you do not have a Support Center login, register here:
https://support.sw.siemens.com/register

Tessent™ Shell User’s Manual 1007

 Third-Party Information
Details on open source and third-party software that may be included with this product are available in the
<your_software_installation_location>/legal directory.