Kenneth P.

Parker

The Boundary-
Scan Handbook
Fourth Edition
The Boundary-Scan Handbook
Kenneth P. Parker

The Boundary-Scan
Handbook
Fourth Edition
Kenneth P. Parker
Fort Collins, CO, USA

ISBN 978-3-319-01173-8 ISBN 978-3-319-01174-5 (eBook)

DOI 10.1007/978-3-319-01174-5

Library of Congress Control Number: 2015949097

Springer Cham Heidelberg New York Dordrecht London

© Springer International Publishing Switzerland 2016
This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of
the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation,
broadcasting, reproduction on microfilms or in any other physical way, and transmission or information
storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology
now known or hereafter developed.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication
does not imply, even in the absence of a specific statement, that such names are exempt from the relevant
protective laws and regulations and therefore free for general use.
The publisher, the authors and the editors are safe to assume that the advice and information in this book
are believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the
editors give a warranty, express or implied, with respect to the material contained herein or for any errors
or omissions that may have been made.

Printed on acid-free paper

Springer International Publishing AG Switzerland is part of Springer Science+Business Media

(www.springer.com)
This book is dedicated to the memory of an
Uncle for whom I was namesake.
Kenneth Fredric Parker, 1912-1998

This book is dedicated also to the memory

of my Parents, who instilled within me the
essential values of communication.
Jack Donald Parker, 1918-2002
Marian Parker, 1918-2010
Preface

It has been 10 years since the third edition of this book first appeared. Since then it
has been translated into the Japanese language by a team of engineers at Fujitsu, led
by Shuichi Kameyama. I was amazed at the effort this required, and greatly appreci-
ated the care and thoroughness that was exhibited by this team.
Also in this decade, a new standard, 1149.8.1, has appeared which is an addition
to the family of supporting test standards. The “Dot-81” standard is aimed at sup-
porting the test of passive components that often surround integrated circuits on
boards. A classic example of such components is connectors that transfer signals to/
from these ICs to other plug-in boards or cables. Boards that possess passive com-
ponents still have to have them tested to assure they are free of open or shorted
connections. A new chapter (10) has been added to describe this new standard.
The base standard, 1149.1, has undergone a very extensive revision and expan-
sion, and this is called IEEE Std 1149.1-2013. This revision is detailed in its own
chapter (12). This reflects the fact that the underlying basic concepts of Boundary-
Scan testing are still the same (those covered in Chaps. 1–4) while new concepts
have been added driven by advancing technology in the electronics industry. This
new revision also has caused some significant changes and additions to the BSDL
language (of Chap. 2). It is expected that well into the future, we will be seeing older
devices (pre-2013) on boards along with newer devices that are compliant with the
2013 revision. Thus it was logical to retain the first chapters of this book in their
largely pre-2013 state, while detailing the 2013 revision later in this book. That said,
references in the earlier chapters are made to specific technology enhancements
found in the new, post-2013 information.
The 23+ years that Boundary-Scan has been with us represents a full generation
of engineers who have benefited from its contributions. As readers will see as they
continue on, “This is not your father’s Boundary-Scan”.

Fort Collins, CO, USA Kenneth P. Parker

vii
Acknowledgments

I’d like to acknowledge those who contributed to this effort. Significant technical
contributions have been made over several years by Stig Oresjo, Ken Posse, John
McDermid and Rod Browen. Others who influenced this work were Colin Maunder,
Rod Tulloss, Chi Yau, Najmi Jarwala, Lee Whetsel, Gordon Robinson, Frans de
Jong, Peter Hansen, Tom Williams, Luke Girard, Dick Chiles, Larry Saunders,
David Simpson, Grady Giles, Tom Langford, Markus Robinson, C. J. Clark, Carl
Thatcher, Adam Cron, Adam Ley, Steve Sunter, Mani Soma, Keith Lofstrom, Steve
Dolens, Brian Wilkins and Ramaswami Dandapani.
Special mention goes to my friends at Matsushita Electric Industries in Osaka,
Japan, who worked incredibly quickly to produce working silicon containing 1149.4
structures. They are Kozo Nuriya, Katsuhiro Hirayama, Akira Matsuzawa, Atsushi
Kukutsu and Ren Franse.
Additional mention goes to my friends in the IEEE 1532 Working Group, Neil
Jacobson, Kurt Guntheroth, Mark Moyer, Brad Ishihara, Alan Herrmann, Dave
Bonnett, Ray Dellecker and Pat McHugh. Yet more recognition goes to contributors
to the IEEE 1149.6 Working Group, Bill Eklow, Carl Barnhart, Jeff Rearick, John
Rohrbaugh, Mike Gilsdorf, Charles Moore, Robert Schuelke, Benny Lai, Rodger
Schuttert, Sung Chung, Sang Baeg, Greg Jordan, Ted Eaton, Terry Borroz, Harry
Hulvershorn, John Braden and Bob Russell. The recent 1149.8.1 standard was
brought into being by my friends, Jeff Burgess, “JJ” Grealish, Steve Sunter, Adam
Cron, Steve Butkovich, Dave Dubberke, Ted Eaton, Heiko Ehrenberg, Adam Ley,
Sopho Metsis, Skip Meyers and Tony Suto.
The 2013 revision of 1149.1 was a huge effort, and I single out the contributions
of John Braden, Bill Bruce, Adam Cron, Wim Driessen, Dave Dubberke, Heiko
Ehrenberg, Bill Eklow, Peter Elias, Josh Ferry, Jeff Halnon, Roland Latvala, Adam
Ley, Francisco Russi, Brian Turmelle, John Seibold, Roger Sowada, Dharma Konda,
Sankaran Menon, Craig Stephan, Hugh Wallace, Carol Pyron and C. J. Clark. Special
mention goes to Carl Barnhart who took on the massive editing job for this effort.
I am indebted to my wife Jana, and daughters Katherine and Lisa who missed
paternal contact while their father spent all those hours in the basement. Without
their support, I could not have completed this work.

ix
x Acknowledgments

Finally, certain indicated passages and drawings have been reprinted, with per-
mission, from IEEE Standards 1149.1, 1149.4, 1149.6, 1149.8.1 and 1532, and all
revisions thereof, copyrighted by IEEE. The IEEE disclaims any responsibility or
liability resulting from the placement and use in the described manner.

Fort Collins, CO, USA Kenneth P. Parker

Contents

List of Figures .................................................................................................. xix

List of Tables.................................................................................................... xxix

List of Design-For-Test Rules ......................................................................... xxxi

Part I Classical Boundary-Scan

1 Boundary-Scan Basics and Vocabulary ................................................ 3
1.1 Digital Test Before Boundary-Scan ................................................. 4
1.1.1 Edge-Connector Functional Testing .................................... 4
1.1.2 In-Circuit Testing ................................................................. 6
1.2 The Philosophy of 1149.1 ................................................................ 9
1.3 Basic Architecture ............................................................................ 10
1.3.1 The TAP Controller.............................................................. 12
1.3.2 The Instruction Register ....................................................... 18
1.3.3 Data Registers ...................................................................... 21
1.3.4 The Boundary Register ........................................................ 23
1.3.5 Optimizing a Boundary Register Cell Design ..................... 28
1.3.6 Architecture Summary ......................................................... 29
1.3.7 Field-Programmable IC Devices.......................................... 31
1.3.8 Boundary-Scan Chains......................................................... 32
1.4 Non-Invasive Operational Modes .................................................... 34
1.4.1 BYPASS ............................................................................... 34
1.4.2 IDCODE .............................................................................. 34
1.4.3 USERCODE ........................................................................ 36
1.4.4 SAMPLE .............................................................................. 36
1.4.5 PRELOAD ........................................................................... 37
1.5 Pin-Permission Operational Modes ................................................. 37
1.5.1 EXTEST............................................................................... 38
1.5.2 INTEST ................................................................................ 39

xi
xii Contents

1.5.3 RUNBIST............................................................................. 39
1.5.4 HIGHZ ................................................................................. 40
1.5.5 CLAMP ................................................................................ 41
1.5.6 Exceptions Due to Clocking ................................................ 41
1.6 Extensibility ..................................................................................... 42
1.7 Subordination of IEEE 1149.1 ......................................................... 43
1.8 Costs and Benefits ............................................................................ 43
1.8.1 Costs ................................................................................... 44
1.8.2 Benefits............................................................................... 45
1.8.3 Trends ................................................................................. 47
1.9 Other Testability Standards .............................................................. 48
2 Boundary-Scan Description Language (BSDL) ................................... 49
2.1 The Scope of BSDL ......................................................................... 51
2.1.1 Testing ................................................................................ 52
2.1.2 Compliance Assurance ....................................................... 53
2.1.3 Synthesis ............................................................................ 55
2.2 Structure of BSDL ........................................................................... 57
2.3 Entity Descriptions........................................................................... 60
2.3.1 Generic Parameter .............................................................. 61
2.3.2 Logical Port Description .................................................... 62
2.3.3 Standard USE Statement .................................................... 63
2.3.4 Use Statements ................................................................... 64
2.3.5 Component Conformance Statement ................................. 64
2.3.6 Device Package Pin Mappings ........................................... 65
2.3.7 Grouped Port Identification ................................................ 66
2.3.8 TAP Port Identification....................................................... 67
2.3.9 Compliance Enable Description......................................... 68
2.3.10 Instruction Register Description ........................................ 69
2.3.11 Optional Register Description ............................................ 70
2.3.12 Register Access Description .............................................. 71
2.3.13 Boundary-Scan Register Description ................................. 72
2.3.14 RUNBIST Execution Description ...................................... 76
2.3.15 INTEST Execution Description ......................................... 76
2.3.16 User Extensions to BSDL .................................................. 77
2.3.17 Design Warnings ................................................................ 78
2.4 Some Advanced BSDL Topics......................................................... 78
2.4.1 Merged Cells ...................................................................... 78
2.4.2 Asymmetrical Drivers ........................................................ 81
2.5 BSDL Description of 74BCT8374................................................... 82
2.6 Packages and Package Bodies.......................................................... 85
2.6.1 STD_1149_1_2001 ............................................................ 85
2.6.2 Cell Description Constants................................................. 89
2.6.3 Basic Cell Definitions BC_0 to BC_7................................ 92
2.6.4 Cells BC_8 to BC_10 Introduced in 2001 ......................... 99
2.6.5 User-Defined Boundary Cells ............................................ 101
2.6.6 Definition of BSDL Extensions ......................................... 104
Contents xiii

2.7 Writing BSDL .................................................................................. 105

2.8 Summary .......................................................................................... 107
3 Boundary-Scan Testing........................................................................... 109
3.1 Basic Boundary-Scan Testing ........................................................ 110
3.1.1 The 1149.1 Scanning Sequence ........................................ 110
3.1.2 Basic Test Algorithm ........................................................ 115
3.1.3 The “Personal Tester” Versus ATE ................................... 117
3.1.4 In-Circuit Boundary-Scan ................................................ 118
3.1.5 IC Test............................................................................... 120
3.1.6 IC BIST ............................................................................ 122
3.2 Testing with Boundary-Scan Chains .............................................. 123
3.2.1 1149.1 Chain Integrity ...................................................... 124
3.2.2 Interconnect Test............................................................... 126
3.2.3 Connection Tests............................................................... 139
3.2.4 Interaction Tests................................................................ 140
3.2.5 Capacitive Opens Tests ..................................................... 144
3.2.6 BIST and Custom Tests .................................................... 144
3.3 Porting Boundary-Scan Tests ......................................................... 145
3.4 Boundary-Scan Test Coverage ....................................................... 147
3.5 Summary ........................................................................................ 148
4 Advanced Boundary-Scan Topics .......................................................... 149
4.1 DC Parametric IC Tests .................................................................. 149
4.2 Sample Mode Tests ....................................................................... 151
4.3 Concurrent Monitoring................................................................... 154
4.4 Non-scan IC Testing ....................................................................... 155
4.5 Non-digital Device Testing ............................................................ 158
4.6 Mixed Digital/Analog Testing........................................................ 158
4.7 Multi-chip Module Testing ............................................................ 161
4.8 Firmware Development Support .................................................... 163
4.9 In-System Configuration ................................................................ 164
4.10 Flash Programming ........................................................................ 166
4.11 Hardware Fault Insertion................................................................ 167
4.12 Power Pin Testing........................................................................... 169
5 Design for Boundary-Scan Test ............................................................. 171
5.1 Integrated Circuit Level DFT ......................................................... 173
5.1.1 TAP Pin Placement ........................................................... 173
5.1.2 Power and Ground Distribution ........................................ 174
5.1.3 Instruction Capture Pattern ............................................... 178
5.1.4 Damage Resistant Drivers ................................................ 179
5.1.5 Output Pins ....................................................................... 180
5.1.6 Bidirectional Pins ............................................................. 182
5.1.7 Post-lobotomy Behavior ................................................... 183
5.1.8 IDCODEs ......................................................................... 184
5.1.9 User-Defined Instructions ................................................. 185
5.1.10 Creation and Verification of BSDL .................................. 185
xiv Contents

5.2 Board-Level DFT ............................................................................. 187

5.2.1 Chain Configurations ........................................................... 187
5.2.2 TCK/TMS Distribution ........................................................ 190
5.2.3 Mixed Logic Families .......................................................... 191
5.2.4 Board Level Conflicts .......................................................... 193
5.2.5 Control of Critical Nodes ..................................................... 194
5.2.6 Power Distribution ............................................................... 195
5.2.7 Boundary-Scan Masters ....................................................... 195
5.2.8 Post-lobotomy Board Behavior............................................ 197
5.3 System-Level DFT ........................................................................... 198
5.3.1 The MultiDrop Problem....................................................... 198
5.3.2 Coordination with Other Standards ..................................... 200
5.4 Summary .......................................................................................... 201
6 Analog Measurement Basics .................................................................. 203
6.1 Analog In-Circuit Testing ................................................................ 203
6.1.1 Analog Failures .................................................................... 204
6.1.2 Measuring an Impedance ..................................................... 206
6.1.3 Errors and Corrections ......................................................... 210
6.1.4 Measurement Hardware ....................................................... 212
6.2 Limited Access Testing .................................................................... 217
6.2.1 Node Voltage Analysis ......................................................... 218
6.2.2 Testing with Node Voltages ................................................. 220
6.2.3 Limited Access Node Voltage Testing ................................. 221
6.3 The Mixed-Signal Test Environment ............................................... 223
6.4 Summary .......................................................................................... 226
7 IEEE 1149.4: Analog Boundary-Scan ................................................... 227
7.1 1149.4 Vocabulary and Basics ......................................................... 228
7.1.1 The Target Fault Spectrum ................................................... 228
7.1.2 Extended Interconnect ......................................................... 229
7.1.3 Digital Pins .......................................................................... 231
7.1.4 Analog Pins .......................................................................... 231
7.2 General Architecture of an 1149.4 IC .............................................. 233
7.2.1 Silicon “Switches” ............................................................... 235
7.2.2 The Analog Test Access Port (ATAP).................................. 236
7.2.3 The Test Bus Interface Circuit (TBIC) ................................ 237
7.2.4 The Analog Boundary Module (ABM)................................ 242
7.2.5 The Digital Boundary Module (DBM) ................................ 247
7.3 The 1149.4 Instruction Set ............................................................... 248
7.3.1 The EXTEST Instruction ..................................................... 249
7.3.2 The CLAMP Instruction ...................................................... 252
7.3.3 The HIGHZ Instruction........................................................ 252
7.3.4 The PROBE Instruction ....................................................... 253
7.3.5 The RUNBIST Instruction ................................................... 253
7.3.6 The INTEST Instruction ...................................................... 254
Contents xv

7.4 Other Provisions of 1149.4 .............................................................. 256

7.4.1 Differential ATAP Port......................................................... 256
7.4.2 Differential I/O..................................................................... 256
7.4.3 Partitioned Internal Test Buses ............................................ 258
7.4.4 Specifications and Limits ..................................................... 261
7.5 Design For 1149.4 Testability .......................................................... 263
7.5.1 Integrated Circuit Level ....................................................... 263
7.5.2 Board Level .......................................................................... 264
7.5.3 System Level ........................................................................ 266
7.6 Summary .......................................................................................... 266
8 IEEE 1149.6: Testing Advanced I/O ..................................................... 269
8.1 The Advanced I/O Problem ............................................................. 270
8.1.1 Traditional Inter-IC Communication ................................... 270
8.1.2 Advanced Inter-IC Communication ..................................... 272
8.1.3 AC Coupled Signal Paths ..................................................... 275
8.1.4 Testing Advanced I/O .......................................................... 278
8.2 1149.6 Vocabulary and Basics ......................................................... 280
8.2.1 Advanced I/O ....................................................................... 280
8.2.2 Signal Pin Categories ........................................................... 281
8.2.3 Operational Modes ............................................................... 282
8.3 Test facilities for AC Pins ................................................................ 282
8.3.1 Provisions for All Signal Pins .............................................. 282
8.3.2 Provisions for AC Pin Drivers ............................................. 283
8.3.3 AC/DC Selection Cells ........................................................ 286
8.3.4 Provisions for AC Pin Receivers .......................................... 287
8.4 The Defect Model for 1149.6........................................................... 288
8.5 The 1149.6 Test Receiver................................................................. 291
8.5.1 Test Receiver Definitions ..................................................... 292
8.5.2 Transitions............................................................................ 293
8.5.3 Test Receiver DC Response ................................................. 295
8.5.4 Test Receiver AC Response ................................................. 298
8.5.5 Guaranteed AC-Coupling .................................................... 301
8.5.6 An Integrated AC/DC Test Receiver .................................... 302
8.5.7 Initializing and Capturing Hysteretic Memory .................... 302
8.6 BSDL Extensions for 1149.6 ........................................................... 304
8.6.1 Boundary Registers Cells for 1149.6 ................................... 305
8.6.2 STD_1149_6_2003 .............................................................. 309
8.6.3 Example 1149.6 Device and BSDL ..................................... 311
8.7 Design for 1149.6 Testability ........................................................... 318
8.7.1 Integrated Circuit Level DFT ............................................... 318
8.7.2 Board-Level DFT ................................................................. 319
8.8 Summary .......................................................................................... 320
xvi Contents

9 IEEE 1532: In-System Configuration ................................................... 321

9.1 IEEE 1532 Vocabulary and Basics ............................................... 323
9.1.1 Fixed System Pins ........................................................ 323
9.1.2 ISC System Pins ........................................................... 323
9.1.3 System Modal States .................................................... 324
9.1.4 System I/O Behavior .................................................... 330
9.1.5 ISC Pin I/O Cell Design ............................................... 331
9.2 Programming Features of IEEE 1532 .......................................... 334
9.2.1 Core 1532 Programming Instructions .......................... 335
9.2.2 Programming a Single, Simple 1532 Device................ 337
9.2.3 Concurrent Programming of Multiple Devices ............ 338
9.3 Design for IEEE 1532 Programmability ...................................... 340
10 IEEE 1149.8.1: Passive Components ..................................................... 343
10.1 Unpowered Capacitive Sensing.................................................... 344
10.2 Powered Capacitive Opens Testing .............................................. 348
10.3 IEEE 1149.8.1 Vocabulary and Basics ......................................... 350
10.3.1 Normal System Pins ..................................................... 350
10.3.2 Selective Toggle System Pins ....................................... 350
10.3.3 Instructions and Registers............................................. 351
10.4 The TOGGLE_SETUP Instruction .............................................. 352
10.5 The SELECTIVE_TOGGLE Instruction ..................................... 352
10.6 The TOGGLE_CONTROL Register............................................ 354
10.7 Differential Signal Unbalancing................................................... 354
10.8 Selective Toggle Pin I/O Cell Design........................................... 356
10.8.1 Single-Ended Output Pins ............................................ 356
10.8.2 Single-Ended Input Pins ............................................... 358
10.8.3 Single-Ended Bidirectional Pins................................... 360
10.8.4 Differential Output Pins................................................ 360
10.8.5 Differential Input Pins .................................................. 363
10.8.6 Differential Bidirectional Pins ...................................... 364
10.9 Testing with 1149.8.1 Resources ................................................. 365
10.9.1 Testing Single-Ended Pins ............................................ 366
10.9.2 Testing Differential Pins ............................................... 367
10.10 BSDL Extensions for 1149.8.1 .................................................... 367
10.10.1 Boundary Registers Cells for 1149.8.1......................... 368
10.10.2 STD_1149_8_1_2012................................................... 369
10.10.3 Selective Toggle Keywords .......................................... 370
10.10.4 BSDL Extension Syntax ............................................... 370
10.10.5 Example 1149.8.1 BSDL .............................................. 372
10.11 Design for IEEE 1149.8.1 Testability .......................................... 374
10.11.1 Integrated Circuit Level DFT ....................................... 374
10.11.2 Board-Level DFT.......................................................... 375
10.12 Epilog: What Next for 1149.1, 1149.4, 1149.6, 1149.8.1
and 1532? ..................................................................................... 376
Contents xvii

Part II Boundary-Scan Updated

11 IEEE 1149.1: The 2013 Revision ........................................................... 381

11.1 Moore’s Law, the Principle Driver ................................................. 381
11.1.1 Circuit Density ............................................................... 382
11.1.2 Design Automation ........................................................ 382
11.1.3 Lower Power Rail Voltages ............................................ 383
11.1.4 Higher I/O Data Rates .................................................... 383
11.2 Lower Power Consumption ............................................................ 384
11.3 The 1149.1 Response to These Drivers .......................................... 385
11.3.1 New Operational Modes ................................................. 385
11.3.2 New Register Designs .................................................... 387
11.3.3 New 1149.1 Instructions................................................. 389
11.3.4 New 1149.1 Data Registers ............................................ 393
11.3.5 Dynamic Data Registers ................................................. 397
11.4 Revisions to BSDL ......................................................................... 401
11.4.1 Breaking the VHDL Link ............................................... 401
11.4.2 VHDL Reserved Words .................................................. 402
11.4.3 BSDL Reserved Words................................................... 403
11.4.4 New Numeric Literals .................................................... 403
11.4.5 New “Identifiers” ............................................................ 403
11.4.6 New Information Tag ..................................................... 404
11.4.7 New Port Types .............................................................. 404
11.4.8 Standard Use Statement.................................................. 405
11.4.9 Use Statements ............................................................... 406
11.4.10 Component Conformance Statement.............................. 406
11.4.11 New Device Pin Mappings ............................................. 406
11.4.12 Register Access Description ........................................... 407
11.4.13 Boundary Register Specification Changes ..................... 408
11.4.14 Fixed Boundary Register Description ............................ 409
11.4.15 New Segmented Boundary Register Description ........... 410
11.4.16 New Boundary Register Assembly ................................ 412
11.4.17 New System Clock Requirements Attribute................... 414
11.4.18 Enhanced Register Description ...................................... 415
11.4.19 New Register Mnemonics Description ........................... 415
11.4.20 New Register Fields Description .................................... 417
11.4.21 New Register Assembly Description.............................. 425
11.4.22 New Register Constraint Description ............................. 431
11.4.23 New Register and Power Port Association
Description ..................................................................... 433
11.5 The New “Procedural Description Language” (PDL).................... 435
11.5.1 The PDL Use Model....................................................... 436
11.5.2 PDL Syntax Definition ................................................... 439
11.5.3 PDL Procedures.............................................................. 440
xviii Contents

11.5.4 PDL Level-0 Command Reference ................................ 441

11.5.5 PDL Level-1 Command Reference .................................. 449
11.5.6 Integrated Example BSDL/PDL ....................................... 452
11.6 Design for IEEE 1149.1 Testability ............................................... 452
12 IEEE 1149.6: The 2015 Revision ........................................................... 455
12.1 The 2013 Revision of IEEE Std 1149.1, the Principle Driver ....... 455
12.1.1 Intellectual Property Packages.......................................... 456
12.1.2 Register Descriptions........................................................ 456
12.1.3 Register Segmentation ...................................................... 457
12.1.4 Initialization Capabilities.................................................. 457
12.1.5 The Addition of PDL Routines......................................... 457
12.2 Fixes to 1149.6 Driven by Experience ........................................... 457
12.2.1 Voltage Variations, Scaling and Programmability ............ 458
12.2.2 Improved Detection of Shorted Capacitors ...................... 458
12.2.3 On-chip Coupling and Bypassing Thereof ....................... 459
12.2.4 Allowing EXTEST_PULSE to Not Work
on Certain Pins ................................................................. 459
12.2.5 SAMPLE Incompatibility ................................................. 460
12.2.6 New AC Boundary Register Cells .................................... 460
12.3 Changes to BSDL for 1149.6 ......................................................... 460
12.3.1 Support for IP Packages ................................................... 461
12.3.2 Support for Describing AC Parameters ............................ 461
12.3.3 Support for Programmable Features ................................. 462
12.3.4 Support for Boundary Register Segmentation .................. 463
12.3.5 Pin Behavior Description (Entity) .................................... 463
12.3.6 Port Link Description (Package) ...................................... 464
12.3.7 Examples of 1149.6 Package and Entity BSDL ............... 464
12.3.8 STD_1149_6_2015........................................................... 466
12.4 PDL Support for Programmable Pins ............................................ 467
12.5 Integrated BSDL-PDL Example .................................................... 469
12.6 Design for IEEE 1149.6-2015 Testability ...................................... 489

Appendix A BSDL Syntax Specifications .................................................. 491

Appendix B 2013 BSDL Syntax Revisions ................................................. 505

References ........................................................................................................ 533

Index ................................................................................................................. 541

List of Figures

Fig. 1.1 In-Circuit test setup with full nodal access.

The component under test may be embedded
within a board and connected to other components ....................... 6
Fig. 1.2 Cutaway drawing of a board resting on top of an In-Circuit,
vacuum-actuated test fixture: the “bed of nails.”
The module interface pins are the mechanical interface
to the ATE pin electronics, which are placed very close
to reduce path lengths .................................................................... 8
Fig. 1.3 General, simplified architecture of an 1149.1 compliant
Integrated Circuit ........................................................................... 11
Fig. 1.4 State transition diagram of the 16-state TAP controller ................. 13
Fig. 1.5 Architecture detail of a typical Boundary-Scan register
with shift and parallel hold ranks ................................................... 19
Fig. 1.6 Example of an instruction register cell design.
The expanded cell shows several control signals generated
by the TAP state machine............................................................... 21
Fig. 1.7 A typical boundary register cell ..................................................... 24
Fig. 1.8 A Bidirectional pin with separate input and output
Boundary Register cells ................................................................. 25
Fig. 1.9 A Bidirectional pin served by a reversible Boundary
Register cell ................................................................................... 26
Fig. 1.10 Compensating inversions in an input Boundary Register cell that
monitors an inverting input buffer.................................................. 27
Fig. 1.11 Compensating inversion in an output Boundary
Register cell connected to an inverting output buffer .................... 27
Fig. 1.12 Two logical symbols for typical boundary cells,
one with an Update (UPD) flip-flop (a) and one without (b) ........ 28
Fig. 1.13 An example (adapted from [Whet95]) of an output cell
design that eliminates both a discrete register stage
and a multiplexer delay .................................................................. 29
Fig. 1.14 Block diagram of a boundary-scan IC ........................................... 30

xix
xx List of Figures

Fig. 1.15 A field-programmable component with Boundary-Scan

hard-wired into its I/O Blocks (IOBs). Each IOB starts
out with bidirectional support for a component pin,
but subsequent programming may reduce each
to supporting input or output only ................................................. 32
Fig. 1.16 A simple chain of boundary-scan ICs ............................................ 33
Fig. 1.17 Code bit allocation in a device identification register
accessed by IDCODE .................................................................... 35
Fig. 1.18 Observe-only boundary register cell for inputs.............................. 41
Fig. 1.19 Product introductions by companies X and Y,
and their relative performance ....................................................... 46
Fig. 2.1 BSDL use model within or outside of a VHDL environment........ 51
Fig. 2.2 BSDL used as a test driver ............................................................. 52
Fig. 2.3 A process for checking the compliance of an IC
with the Standard ........................................................................... 54
Fig. 2.4 An 1149.1 synthesis system that both creates
and uses BSDL............................................................................... 55
Fig. 2.5 The relationship of a BSDL entity to the standard package
and package body ........................................................................... 59
Fig. 2.6 Candidate for merged cell design................................................... 79
Fig. 2.7 Design with input and control cells merged................................... 79
Fig. 2.8 A design illustrating several merged cell situations ....................... 80
Fig. 2.9 Texas Instruments 74BCT8374 Octal D Flip-Flop
with Boundary-Scan....................................................................... 82
Fig. 2.10 An abstraction of a Boundary Register cell showing
capture data sources ....................................................................... 91
Fig. 2.11 Cell architecture BC_1, a basic but very flexible design ............... 93
Fig. 2.12 Cell architecture BC_2. This cell can capture its own Update
latch content ................................................................................... 94
Fig. 2.13 Cell architecture BC_3, an input cell with no Update latch .......... 95
Fig. 2.14 Cell architecture BC_4, a cell with no Update latch
and no series multiplexer ............................................................... 96
Fig. 2.15 Cell architecture BC_5, a control cell for an input pin .................. 96
Fig. 2.16 Cell architecture BC_7 (see the circuitry in the dotted
line box) which supports bidirectional data flow ........................... 98
Fig. 2.17 Cell architecture BC_8 for self-monitoring bidirectional pins ...... 100
Fig. 2.18 Cell architecture BC_9 for outputs with INTEST support ............ 101
Fig. 2.19 Cell architecture BC_10 for outputs with no INTEST support ..... 102
Fig. 2.20 A cell that captures a constant 1 during EXTEST ......................... 103
Fig. 3.1 Side view of a surface-mount IC soldered to a board.
An open and a short are pictured. The poor quality joint will be
invisible to electrical test methods, including Boundary-Scan ...... 110
Fig. 3.2 TAP Controller state diagram showing path taken
to shift an N-bit instruction into the Instruction Register .............. 111
List of Figures xxi

Fig. 3.3 The newly loaded instruction is activated when Update-IR

is passed, selecting a new data register targeted
between TDI and TDO when we enter the Data Column
of the state diagram ........................................................................ 113
Fig. 3.4 Sequence of states traversed to capture data and shift it out
while at the same time entering new data ...................................... 114
Fig. 3.5 Completing a data shifting operation and updating
the parallel hold portion of a data register ..................................... 115
Fig. 3.6 An IC undergoing an INTEST function while loaded
on a board....................................................................................... 121
Fig. 3.7 A simple chain that has just passed Capture-IR,
loading all Instruction Registers with “01” .................................... 124
Fig. 3.8 A boundary-scan chain of ICs with four interconnect nodes ......... 127
Fig. 3.9 Interconnect test drives unique patterns assigned to each
node from drivers to receivers. A short is shown
that creates a Wired-OR result ....................................................... 128
Fig. 3.10 An interconnect open that prevents driven data from reaching
one of two receivers on a node. This fact can help
a diagnostic isolate the location of the open .................................. 128
Fig. 3.11 Simple interconnect test showing STVs (horizontal patterns)
for 4 nodes. The columns are PTVs and represent
the data as transmitted at each Update-DR state.
Nodes A and B are bussed ............................................................. 129
Fig. 3.12 Three examples of bus wire driver opens not detected
by interconnect shorts test.............................................................. 135
Fig. 3.13 Control cell fanout combined with board topology
that results in undetected opens ..................................................... 136
Fig. 3.14 Parallel testing of two bussed nodes .............................................. 137
Fig. 3.15 A case where four buses containing different numbers
of drivers are tested in parallel ....................................................... 138
Fig. 3.16 A circuit where not all Boundary-Scan pins can be tested
via interconnect test ....................................................................... 140
Fig. 3.17 Example of potential interactions between a Boundary-Scan
node and two non-scanned nodes .................................................. 141
Fig. 3.18 Boundary-Scan nodes B and C that can interact (by shorting)
with nodes A, D or F ...................................................................... 142
Fig. 3.19 Two cooperating components provide stimulus vectors
and capture a signature response for data path logic ..................... 145
Fig. 3.20 Developing and porting a manually generated test
for similar applications .................................................................. 146
Fig. 3.21 Developing a Boundary-Scan test for similar applications ............ 146
Fig. 3.22 A simple In-Circuit test of resistor R ............................................. 148
xxii List of Figures

Fig. 4.1 The analog testing subsystem of an IC tester is used to switch

load and test resources to measure analog parametric
properties of an IC ......................................................................... 150
Fig. 4.2 A simple circuit and its timing diagram showing setup
and hold times, and the effects of system clock skew.................... 152
Fig. 4.3 Simple circuit showing the relationships between the system
clock and TCK during SAMPLE operation ................................... 153
Fig. 4.4 Concurrent sampling of component I/Os during system
diagnostics, with sampled data compressed in a multiple-input
signature analysis register (MISR)................................................. 155
Fig. 4.5 Testing a non-scan IC U7 with a combination of physical
nails and Boundary-Scan pins........................................................ 156
Fig. 4.6 A timing diagram that shows how Boundary-Scan resources
must be coordinated with the resources of a host ATE system ...... 156
Fig. 4.7 Shorted inputs on a NAND gate that may not be detectable
when tested by ordinary Boundary-Scan drivers ........................... 157
Fig. 4.8 A Boundary-Scan testable node that has a termination
resistor to eliminate noise .............................................................. 158
Fig. 4.9 A mixed digital/analog IC with the Boundary Register
partitioning the digital from the analog ......................................... 159
Fig. 4.10 Two digital ICs that communicate by differential signaling .......... 160
Fig. 4.11 Three examples of “unusual” differential signaling
applications .................................................................................... 160
Fig. 4.12 Multi-Chip Module shown in cross section. This example
shows a multi-layer ceramic PGA made of multiple dielectric
and metallization layers. Bare IC die and other discrete
components are mounted on the top surface .................................. 162
Fig. 4.13 Conventional Flash RAM accessed by a Boundary-Scan device .... 166
Fig. 4.14 A BC_1 Boundary Register cell modified to support
fault insertion ................................................................................. 168
Fig. 5.1 Three pin layouts for TDI and TDO .............................................. 173
Fig. 5.2 An oscillograph of a Ground-Bounce induced clock cycle
on TCK during Update-DR, measured at the TCK pin
referenced to component ground ................................................... 175
Fig. 5.3 A high pincount IC with two 32-bit buses ..................................... 176
Fig. 5.4 The transition timing for activities on the two buses
in Fig. 5.3 ....................................................................................... 176
Fig. 5.5 Deliberately inserted delays in the Boundary Register
control signal paths can be used to distribute driver edge
placements in time ......................................................................... 177
Fig. 5.6 A Boundary Register output cell design with the capability
of monitoring its driver output pad during EXTEST ..................... 181
Fig. 5.7 A conjoined chain pair with common TCK and TMS signals,
but independent data paths. Any number of chains
could be linked in parallel this way ............................................... 188
List of Figures xxiii

Fig. 5.8 A conjoined chain pair with separate TMS lines,

common TCK, and shared board-level TDI and TDO signals ...... 189
Fig. 5.9 A simple chain with buffered TCK and TMS signals needed
to avoid overloading ....................................................................... 190
Fig. 5.10 A low-skew clock buffer with 50 % duty cycle preserved
by utilizing inversion...................................................................... 191
Fig. 5.11 A simple Boundary-Scan chain containing ICs
from different logic families. Logic level conversion
must be made between them .......................................................... 192
Fig. 5.12 A simple Boundary-Scan chain with a scanned level
conversion interface for the parallel signals. Note the TCK
and TMS lines must not have a scanned conversion ...................... 192
Fig. 5.13 A Boundary-Scan IC during test can set two normally
complementary outputs to the same state, exciting conflicts
in conventional ICs downstream .................................................... 193
Fig. 5.14 Two Boundary-Scan nodes A and B need additional
support from tester resources to enable proper testing .................. 194
Fig. 5.15 A Boundary-Scan master interfaces between a microprocessor
on one side and 1149.1 on the other. (The directions of TDI
and TDO are reversed, reflecting mastership.)............................... 196
Fig. 5.16 The 74ACT8997 Scan-Path linker IC linking simple
chains A, B and C. Extra shift stages (marked with “*”)
are inserted in the linked chain. These stages are actually
resident in the ‘8997, which itself appears in a normal 1149.1
form at the end of the chain ........................................................... 197
Fig. 5.17 A system of several boards where each slot may accept
several board types, or not contain a board at all. A simple 1149.1
chain through these boards would be broken at an empty slot ...... 199
Fig. 6.1 A simple filter circuit and the actual circuit when parasitic
capacitance is included .................................................................. 204
Fig. 6.2 Distribution of resistance values for a 4.7 kΩ resistors
with a tolerance of ±5 % ................................................................ 205
Fig. 6.3 Measuring impedance with current source stimulus
(a) and with voltage source stimulus (b) ....................................... 206
Fig. 6.4 Measuring the impedance of a device on a board, connected
to a silicon device (a), and as seen by an ATE system (b)............. 208
Fig. 6.5 Devices may be connected into networks providing
parallel pathways for currents ........................................................ 209
Fig. 6.6 Some sources of error in an ATE setup for measuring
a simple impedance ........................................................................ 211
Fig. 6.7 Error impedances for a delta measurement
(a) and a 6-wire measurement configuration (b) ........................... 212
Fig. 6.8 An operational amplifier with feedback resistor
used as a current meter ................................................................... 213
xxiv List of Figures

Fig. 6.9 An operational amplifier setup to integrate a DC voltage

V over time..................................................................................... 213
Fig. 6.10 An operational amplifier setup for DC Dual Slope Integration ..... 214
Fig. 6.11 A dual slope integrator modified for AC measurements ................ 215
Fig. 6.12 A dual slope integrator used to measure a reactive component ..... 216
Fig. 6.13 Imaginary voltage waveform seen when measuring a capacitor ... 217
Fig. 6.14 A simple network containing four resistors
with full nodal access ..................................................................... 218
Fig. 6.15 Three-dimensional coordinates for graphing voltage differences.. 219
Fig. 6.16 Three-dimensional plots where only some components
are potentially faulty at any one time ............................................. 220
Fig. 6.17 Example circuit with access to node B removed ........................... 221
Fig. 6.18 Projecting the shadow of a three-dimensional object
onto a plane .................................................................................... 222
Fig. 6.19 Projections of failure spaces for R2 and R3 onto two
of the voltage planes ...................................................................... 222
Fig. 6.20 A mixed-signal printed circuit board ............................................. 224
Fig. 6.21 Key to the color photograph appearing on the cover of this book . 225
Fig. 6.22 Comparison of relative sizes of various features ........................... 226
Fig. 7.1 A mixed-signal circuit with some possible defects........................ 229
Fig. 7.2 Examples of interconnections seen in mixed-signal circuits ......... 230
Fig. 7.3 General (minimal) architecture of an 1149.4 compliant IC ........... 233
Fig. 7.4 Detail of 1149.4 data register structure .......................................... 234
Fig. 7.5 Symbols used for opened and closed switches .............................. 236
Fig. 7.6 Two or more 1149.4 ICs chained together.
Note AT1 and AT2 are not required to be connected
in parallel as shown here ................................................................ 237
Fig. 7.7 A TBIC switching structure inserted between AT1/AT2
and AB1/AB2. Note one-bit digitized values of the AT1/AT2
signals are generated ...................................................................... 238
Fig. 7.8 Control structure for the switches shown in Fig. 7.7 ..................... 238
Fig. 7.9 ABM design detail for a generalized analog function pin ............. 243
Fig. 7.10 Control structure for the switches shown in Fig. 7.9 ..................... 243
Fig. 7.11 ESD protection circuit for a typical pin (a) and an 1149.4
pin (b)............................................................................................. 247
Fig. 7.12 Alternative forms for the Boundary Register depending
on whether INTEST and/or RUNBIST are supported ................... 248
Fig. 7.13 An ATE system set up to utilize 1149.4 resources
in an IC to measure an externally connected impedance ............... 250
Fig. 7.14 Two measurements (a) and (b) used to find the voltage
across Z for a known current.......................................................... 251
Fig. 7.15 Testing the digital core using INTEST. The analog core
is not directly tested ....................................................................... 255
Fig. 7.16 The analog core can be tested by patterns supplied
at the D/A interface and by signals supplied or controlled
by the ABMs .................................................................................. 255
List of Figures xxv

Fig. 7.17 An example implementation for differential inputs

and outputs ..................................................................................... 258
Fig. 7.18 Example of a TBIC structure with one extension (k = 2) ............... 259
Fig. 7.19 Control structure for the extended TBIC switches in Fig. 7.18 ..... 260
Fig. 7.20 A conventional transmission gate switch and a shunting “T”
switch structure that reduces coupling when the switch is off....... 264
Fig. 7.21 Degrees of guarding between two ATn signals.............................. 265
Fig. 8.1 Traditional single-ended bidirectional bus architecture
for inter-IC communication ........................................................... 271
Fig. 8.2 Two single-ended drivers, one affected by noise such
as ground bounce ........................................................................... 272
Fig. 8.3 Two differential driver/receivers, one affected by noise ................ 273
Fig. 8.4 Serialized high-speed data transmission on dedicated
unidirectional paths. This is a serialized implementation
of the system seen in Fig. 8.1......................................................... 274
Fig. 8.5 Classical parallel single-ended bus structure ................................. 276
Fig. 8.6 Same system as Fig. 8.5, but with a SERDES implementation ..... 276
Fig. 8.7 DC and AC-coupled differential paths ........................................... 277
Fig. 8.8 DC-coupled signals propagate and remain available
indefinitely ..................................................................................... 278
Fig. 8.9 AC-coupled signals that decay before they can be captured.......... 279
Fig. 8.10 An 1149.1 data cell for a driver, and how 1149.6
adds AC signal modulation ............................................................ 284
Fig. 8.11 AC pin driver waveforms created by the EXTEST_PULSE
and EXTEST_TRAIN instructions ................................................ 285
Fig. 8.12 A circuit for generating the AC Test Signal ................................... 285
Fig. 8.13 AC pin data cell, modified for control by an AC/DC
selection cell................................................................................... 286
Fig. 8.14 A single-ended AC input pin equipped with a test receiver........... 288
Fig. 8.15 A differential AC pin pair equipped with test receivers,
and an optional 1149.1 control and observe data cell
monitoring the mission receiver ..................................................... 289
Fig. 8.16 Circuit used to define defects addressed by the 1149.6 standard ..... 289
Fig. 8.17 An open circuit defect may be undetectable depending
on termination and biasing ............................................................. 292
Fig. 8.18 DC-coupled transitions seen at the test receiver input ................... 294
Fig. 8.19 AC-coupled transitions seen at the test receiver input ................... 294
Fig. 8.20 A test receiver circuit for DC (EXTEST) waveforms .................... 296
Fig. 8.21 Timing of signals within the test receiver during EXTEST ........... 297
Fig. 8.22 Edge-detecting test receiver model for AC EXTEST
instructions ..................................................................................... 298
Fig. 8.23 Performance of the edge detector for AC and DC-coupled
signals ............................................................................................ 299
Fig. 8.24 AC integrating test receiver............................................................ 300
xxvi List of Figures

Fig. 8.25 Timing of signals within the test receiver

during an AC EXTEST instruction .............................................. 301
Fig. 8.26 An integrated AC/DC test receiver implementation .................... 302
Fig. 8.27 Generation of “Init Clk” for test receiver memory ...................... 303
Fig. 8.28 Integrating a test receiver with its associated Boundary
Register cell ................................................................................. 304
Fig. 8.29 Two AC/DC selection cell design possibilities ............................ 305
Fig. 8.30 AC output pin data cell AC_1 ...................................................... 306
Fig. 8.31 AC output pin data cell AC_2 ...................................................... 307
Fig. 8.32 AC Bidirectional pin data cell AC_7 ........................................... 307
Fig. 8.33 AC Bidirectional pin data cell AC_8 ........................................... 308
Fig. 8.34 Self-monitoring output data cell AC_9 ........................................ 308
Fig. 8.35 AC output pin data cell AC_10 .................................................... 309
Fig. 8.36 An example device with several Advanced I/O pins ................... 311
Fig. 8.37 Example device with 1149.1 and 1149.6 inserted ....................... 313
Fig. 9.1 A device may contain both fixed and configurable
functionality ................................................................................. 324
Fig. 9.2 Operational modes defined by 1149.1, and their transitions ........ 325
Fig. 9.3 1532 system modal states, and transitions between them ............ 327
Fig. 9.4 Entry and exit to test mode from the system modal states ........... 329
Fig. 9.5 A simple PLD Boundary Register design .................................... 331
Fig. 9.6 Typical PLD I/O module design .................................................. 332
Fig. 9.7 Output data cells for HIGHZ-like and CLAMP-like behavior .... 332
Fig. 9.8 A control cell design for HIGHZ-like behavior ........................... 333
Fig. 9.9 A control cell design for CLAMP-like behavior ......................... 333
Fig. 9.10 Simple PLD configuration memory model .................................. 335
Fig. 9.11 Simple PLD memory structure with 1532 access ........................ 336
Fig. 10.1 In-Circuit tester setup for unpowered capacitive opens test ........ 344
Fig. 10.2 Electrical model of the capacitance measurement,
defect-free (a) and with an open (b) ............................................ 345
Fig. 10.3 Intervening series components also receive test coverage ........... 346
Fig. 10.4 Basic stimulus/sense model of 1149.8.1 testing .......................... 348
Fig. 10.5 Some Boundary-Scan driving resources may be missing ............ 349
Fig. 10.6 Model of a differential driver ....................................................... 355
Fig. 10.7 A differential driver with unbalanced signal capability ............... 356
Fig. 10.8 An “ST_10” design for a self-monitoring output pin
adapted from BC_10 .................................................................... 357
Fig. 10.9 Normal input pins and options for converting to ST-pins ............ 359
Fig. 10.10 Symbols used to depict differential drivers and their related
boundary register cells ................................................................. 361
Fig. 10.11 Differential outputs with ST-pin modifications............................ 362
Fig. 10.12 A fully capable boundary cell design for differential outputs ..... 363
Fig. 10.13 Modifications for differential input ST-pins ................................ 364
Fig. 10.14 Two “Unbalance” cell designs ..................................................... 368
List of Figures xxvii

Fig. 11.1 Test Mode Persistence (TMP) state diagram ............................... 385
Fig. 11.2 Classic dual-rank shift/update data register cell
with gated clocks.......................................................................... 388
Fig. 11.3 Revised data cell introduced in 2013, with non-gated
TCK clocking ............................................................................... 388
Fig. 11.4 Example of an output driver with selectable parameters ............. 391
Fig. 11.5 A reset select register for controlling N domains in an IC........... 396
Fig. 11.6 An excludable segment ................................................................ 398
Fig. 11.7 An excludable segment with a domain control cell ..................... 399
Fig. 11.8 Three selectable segments and their control ................................ 400
Fig. 11.9 A test data register and its description ......................................... 417
Fig. 11.10 A re-organized MemTest register................................................. 419
Fig. 11.11 Three registers composed from two segments ............................. 426
Fig. 11.12 A set of selectable segments in three different power domains ... 428
Fig. 11.13 A register assembly with selectable fields ................................... 429
Fig. 11.14 Broadcast data to parallel assemblies .......................................... 430
Fig. 11.15 The PDL scan frame .................................................................... 437
Fig. 11.16 Data flow for the iApply command.............................................. 437
Fig. 12.1 Board with two ICs containing IP blocks A and B ...................... 470
Fig. 12.2 IP block A is a programmable differential driver ........................ 470
Fig. 12.3 IP block B is a programmable differential receiver ..................... 472
List of Tables

Table 1.1 Instruction register operation during each TAP

controller state ............................................................................. 20
Table 2.1 Pin types in a BSDL logical port description .............................. 63
Table 2.2 Function symbols and their meanings ......................................... 74
Table 2.3 Definition of disable result field symbols .................................... 75
Table 2.4 Definitions of allowable CELL_TYPE symbols ......................... 90
Table 2.5 Definitions of CAP_DATA symbols ............................................ 91
Table 2.6 Mode signal assignment for cell BC_1 used in any context........ 93
Table 2.7 Mode signal assignments for cell BC_2 in the context
of use. See text for an exception regarding INTEST ................... 94
Table 2.8 Mode signal assignment for cell BC_3 ....................................... 95
Table 2.9 Mode signal assignments for cell BC_5 ...................................... 97
Table 2.10 Mode signal assignments for BC_7 and its related
BC_2 control cell......................................................................... 98
Table 2.11 Mode control settings for cell BC_8 ........................................... 100
Table 2.12 Mode line settings for the BC_9 output data cell ........................ 101
Table 2.13 Mode settings for the BC_10 cell ................................................ 102
Table 3.1 Example data bits for chains shown in Fig. 3.7.
The bits for IC7 are the first to appear at TDO............................ 125
Table 3.2 Data streams from chains shown in Fig. 3.7 with IC4 TDI
and TDO shorted together, producing a Wired-AND ................. 126
Table 3.3 Sequential test vectors for a set of nodes.
The rows are STVs and the columns are PTVs ........................... 132
Table 3.4 A set of test PTVs (the columns) for interconnect test.
(The Notes are explained in the text)........................................... 134
Table 3.5 Parallel test data for two bussed nodes ........................................ 137
Table 3.6 Test data required for bus wires with different numbers
of drivers ...................................................................................... 139

xxix
xxx List of Tables

Table 6.1 Node voltages for the circuit in Fig. 6.14 when
the component values vary from nominal ................................... 218
Table 7.1 Comparison of parameters of various switches ........................... 235
Table 7.2 TBIC switching patterns (P0 through P9) for the switches
shown in Fig. 7.7 ......................................................................... 240
Table 7.3 Assignment of TAP instructions to mode signal values
for the TBIC ................................................................................ 240
Table 7.4 Selection of TBIC switch patterns versus Boundary
Register cell content .................................................................... 241
Table 7.5 Logic equations for TBIC switch control .................................... 242
Table 7.6 ABM switching patterns (P0 through P19) for the switches
shown in Fig. 7.9 ......................................................................... 245
Table 7.7 Selection of ABM switch patterns versus Boundary
Register cell content .................................................................... 246
Table 7.8 Logic equations for ABM switch control .................................... 246
Table 7.9 TBIC extension switching patterns for the switches
in Fig. 7.18 for extension k .......................................................... 259
Table 7.10 Selection of TBIC extension switch patterns versus
Boundary Register cell content ................................................... 261
Table 7.11 Logic equations for TBIC extension switch control.................... 261
Table 8.1 Comparison of pin counts for busses in the structures shown
in Figs. 8.1 and 8.4. (Does not account for power pins).............. 274
Table 8.2 Actions of an AC pin driver per instruction versus TAP state ..... 284
Table 8.3 Defects that the 1149.6 standard is designed to detect ................ 290
Table 8.4 Mode settings for Figs. 8.30, 8.31, 8.32, 8.33, 8.34,
and 8.35 ....................................................................................... 306
Table 9.1 Control cell operation for HIGHZ-like behavior......................... 334
Table 9.2 Control cell operation for CLAMP-like behavior ....................... 334
Table 9.3 Sequence of events to program and verify one simple
1532 device .................................................................................. 338
Table 9.4 Sequence of events to program two similar devices
of differing size............................................................................ 339
Table 11.1 Growth in IC density since 1990, as predicted by Moore ........... 382
Table 11.2 New port types and their meanings ............................................. 404
Table 11.3 Input specification keyword meanings ........................................ 408
Table 12.1 Pre-defined PDL procedure names for pin parameters................ 467
Table A.1 Constraint operator definitions .................................................... 523
List of Design-for-Test Rules

DFT-1: Place TDI and TDO pins on the end or the corner
of a package to reduce their likelihood of being bridged
by solder. ......................................................................................... 174
DFT-2: Place power pins between TDI and TDO pins
and other signal pins. ....................................................................... 174
DFT-3: Ensure that worst-case switching of all IC drivers
will not cause power/ground transients that disrupt
the operation of the TAP controller. ................................................ 178
DFT-4: Assure that your ATE system can manage phased release
of overdriven nodes, to minimize slew-rate induced
Ground-Bounce. .............................................................................. 178
DFT-5: Use higher-order bits of the Instruction Register capture
pattern to implement an informal ID code. The bits captured
must be predictable “0”s and “1”s................................................... 178
DFT-6: If design-dependent bits are captured in the Instruction Register,
then any combination of these bits should decode
to the same operation....................................................................... 179
DFT-7: Specify a tolerance period that drivers can withstand shorts
to each other or to Power/Ground voltages. .................................... 180
DFT-8: Use self-monitoring output cells in the Boundary Register
to improve Boundary-Scan diagnosis of shorts and opens.............. 182
DFT-9: For bidirectional pins, utilize a single-cell bidirectional design
with a self-monitoring capability (such as cell BC_7). ................... 182
DFT-10: When the 1149.1 logic executes a pin-permission instruction,
the system logic should be forced into a state that prevents
internal conflicts. ............................................................................. 183
DFT-11: When the 1149.1 logic returns to non-invasive mode,
the system logic should stay in a state that will not conflict
with board level signals. .................................................................. 183
DFT-12: Use formal or informal ID codes to differentiate similar
components or revisions of components. ........................................ 184

xxxi
xxxii List of Design-for-Test Rules

DFT-13: Consider board-level testing problems that will require

user-defined instructions for their solutions before final
implementation of the 1149.1 logic................................................. 185
DFT-14: Verify that a BSDL description matches the silicon
implementation of 1149.1 on every component. ............................. 187
DFT-15: Before designing a board-level chain configuration,
be sure that the software that will be used during testing
will support it. ................................................................................. 189
DFT-16: If there are field-programmable components in a chain
of 1149.1 devices, group them together in the chain order
and place the group at either end of the chain. ................................ 190
DFT-17: Utilize simple buffering (where possible) of the broadcast
TCK/TMS signals. Document the enabling and initialization
requirements needed to preserve the 1149.1 protocol
through TCK/TMS distribution. ...................................................... 191
DFT-18: Do not allow logical inversion in the TCK or TMS pathways. ....... 191
DFT-19: When mixed logic families are used on a board, use scanned
level converters for the parallel signals and a non-scanned
level conversion31 for TCK/TMS distribution. ................................ 192
DFT-20: Check conventional portions of board circuitry that may be
affected by Boundary-Scan test data for damaging conflicts
that may be induced. Design disable methods into these portions
that will make them insensitive to this testing activity. ................... 193
DFT-21: Provide for the ability of a tester to disable conventional
ICs whose outputs would otherwise conflict with nodes
involved in Boundary-Scan tests. .................................................... 194
DFT-22: Provide for the ability of a tester to create strong drive values
on weak nodes. ................................................................................ 194
DFT-23: Make sure you locate and condition all Test Reset (TRST*)
pins and all compliance enable pins before executing
any Boundary-Scan tests. ................................................................ 195
DFT-24: Design analog and digital subsystems such that the analog
power can be shut off while Boundary-Scan testing
is being done.................................................................................... 195
DFT-25: If a Boundary-Scan master is used in a board design,
provide for test equipment access and control
of the 1149.1 side of the master’s interface. .................................... 196
DFT-26: Ensure that a board, after any 1149.1 operation completes,
will have safe states on all components and nodes. ........................ 197
DFT-27: Restrict 1149.1 implementations for system tests to simple
system architectures not containing a multidrop scheme. ............... 199
DFT-28: Eliminate all common conductive paths between a system pin
pad and the ATn switches (SB1 and SB2)....................................... 263
DFT-29: Partition internal analog test buses (per Sect. 7.4.3)
to control on-chip cross talk, leakage, and capacitance. ................. 263
List of Design-for-Test Rules xxxiii

DFT-30: Examine the location of switches for places where the circuit
may be sensitive to parasitic coupling and leakage.
Use enhanced switch designs in these areas to reduce
these effects. .................................................................................... 264
DFT-31: Analyse the layout of the ATn pins with respect to leakage
and parasitic effects between them and other signals...................... 264
DFT-32: Group compatible ATAPs together on common ATn buses.
Be prepared to accommodate more ATAP buses than there
are TAP chains................................................................................. 265
DFT-33: For ATn ports expected to be used in measurements
of very high impedances, place a board-level guard wire
between the ATn signals. ................................................................. 266
DFT-34: Consider which of all ATn ports in a system will be needed
for system test and provide access to them. .................................... 266
DFT-35: Consider if noise-immunity testing of differential signaling
is required in the system. ................................................................. 266
DFT-36: Consider equipping all differential I/O ports
with IEEE 1149.6 resources. ........................................................... 318
DFT-37: Consider equipping all I/O ports that could be AC-coupled
with IEEE 1149.6 resources. ........................................................... 318
DFT-38: Consider integrating AC-coupling, termination
and biasing into receiving ICs. ........................................................ 319
DFT-39: Use 1149.6 in all differential board and system
signal pathways. .............................................................................. 319
DFT-40: Assure that 1149.6 drivers and receivers have compatible
definitions of a “valid” transition. ................................................... 319
DFT-41: When board-level coupling capacitors are present,
use the 1149.1 EXTEST instruction to find shorted capacitors. ..... 319
DFT-42: Document the state of each PLD at the completion
of board power up, for testing purposes. ......................................... 341
DFT-43: Document how PLDs are configured on a board,
and how to trigger or prevent configuration. ................................... 341
DFT-44: Document supporting conditions needed
for device programming. ................................................................. 341
DFT-45: Document what actions should be taken when
a programming process fails while on an ATE system. .................. 341
DFT-46: Plan how non-PLD devices will be disabled
during programming, and avoid using data-intensive
EXTEST disabling. ......................................................................... 342
DFT-47: Consider adding 1149.8.1 resources to IC pins that
will ultimately be connected to pins on passive devices
such as connectors. .......................................................................... 375
DFT-48: Consider adding 1149.8.1 resources to IC pins
that will be connected to IC that do not implement
testability features. .......................................................................... 375
xxxiv List of Design-for-Test Rules

DFT-49: Consider adding monitor capabilities to input ST-pins

to support accurate testing for shorts............................................... 375
DFT-50: Survey boards for passive components and determine
if there are 1149.8.1 resources that can be used to support
capacitive sense testing.................................................................... 375
DFT-51: Help define IC requirements used by IC designers to get
1149.8.1 installed in the best places in upcoming IC designs. ........ 375
DFT-52: Consider implementing the ECID_CODE instruction
and ECID register, to capture design specifics
and manufacturing details for later support evaluation ................... 452
DFT-53: Consider implementing the Init_Data register for storing
key parameters that make drivers and receivers compatible ........... 453
DFT-54: Use register fields and mnemonics in BSDL
to provide human-friendly descriptions of registers
and values they may be given .......................................................... 453
DFT-55: Consider implementing the Test Mode Persistence controller
in an IC, particularly in those that manage power regulation
on-chip, or for other ICs on a board ................................................ 453
DFT-56: Survey the portions of an IC that may undergo power
management and assure that any 1149.1 resources
within such domains are properly implemented
according to the standard................................................................. 453
DFT-57: Survey your board/system designs to assure safety
during test, and at test completion ................................................... 453
DFT-58: For all selectable features of an 1149.6 I/O pin,
assure they are controlled by fields within the Init_Data
register and supply a BSDL register fields description
for them, with friendly register mnemonics
to help users identify them .............................................................. 489
DFT-59: If there are on-chip in-line capacitors, consider
supplying programmable bypasses (shunts) for them,
or in the least, automatically shunt them when EXTEST
is the effective instruction. Show these choices in the BSDL
with the On_Chip_AC, On_Chip_Programmable
or On_Chip_AC_Programmable keywords .................................... 490
 Part I
Classical Boundary-Scan

The first ten chapters of this book cover what I call “Pre-2013”, or “Classical”
Boundary-Scan, that is, the Boundary-Scan technology that sprang from the earliest
work that started in the late 1980s. By the mid-2000s, it was becoming obvious that
technology advances and changes in the overall electronics industry, from circuit
design, distribution of Intellectual Property, extreme miniaturization, etc., were
causing major changes to how people implemented and used Boundary-Scan tech-
nology. So, starting with the 2013 release of the base 1149.1 standard, there are
major changes to the base 1149.1 standard to be aware of, and how these propagate
into the rest of the tools and technology of Boundary-Scan. These are covered in
Part II of this book.
Part I is still quite relevant and serves as a useful tutorial about Boundary-Scan.
It starts with the basic concept of Boundary-Scan as provided by the base standard,
1149.1, which has undergone several editions since first appearing in 1990. Those
editions were “additive”, for example, adding the Boundary-Scan Description
Language (BSDL) in 1994. Then a number of subsidiary standards were developed
in the late 1990s into the 2000s. Each of these addressed a set of new capabilities that
could be added to a device to augment its testing capabilities. For example, a device
could be compliant to both 1149.1 and 1149.4, which added new capabilities to sup-
port analog measurements via Boundary-Scan. The first ten chapters of this book
provide this background which will be necessary to understand before reading Part II.
Chapter 1
Boundary-Scan Basics and Vocabulary

Boundary-Scan, formally known1 as IEEE/ANSI Standard 1149.1-2001 [IEEE01,

Maun90], is a collection of design rules applied principally at the Integrated Circuit
(IC) level that allow software to alleviate the growing cost of designing, producing
and testing digital systems. A fundamental benefit of the standard is its ability to
transform extremely difficult printed circuit board testing problems that could only
be attacked with Ad-Hoc testing methods [Will83] into well-structured problems
that software can easily and swiftly deal with.
Note I have twice stated that software would be utilizing the standard. In com-
plex designs where testing problems are most difficult, Boundary-Scan is quite
tedious for a human to program manually. The attendant serialization of test data
makes the purpose of a test quite incomprehensible. Thus, it is extremely important
that the rules of this standard be strictly obeyed, and, that the details of how a given
IC has Boundary-Scan implemented be described with complete accuracy. If this
warning is not heeded, then software may well obey a fundamental law of comput-
ing: Garbage In, Garbage Out. The net result will be difficulty or even failure.
However, if you have a robust and well-described implementation of the Standard
[Ores92], you can expect many improvements in efficiency in several areas as will
be outlined later in this book. Some startling improvements have been observed,
such as in [Kaji92] where a complex board test was created at least ten times more
quickly than anticipated, without need of debugging.
The suffix that you see on the name of the Standard indicates the year the Standard
was issued or last reissued. The IEEE requires that every 5 years, a standard be
updated if necessary and balloted again. When it passes ballot, it gets a new suffix.
During the 5-year cycle, up to two supplements may be issued as separate documents

1
Informally, the Standard is often referred to as the “JTAG” proposal, due to its history of develop-
ment. JTAG was the Joint Test Action Group made up of companies primarily in Europe and North
America. This group created the foundation for the IEEE work.

© Springer International Publishing Switzerland 2016 3

K.P. Parker, The Boundary-Scan Handbook, DOI 10.1007/978-3-319-01174-5_1
4 1 Boundary-Scan Basics and Vocabulary

that give clarifications and/or corrections to the standard. The original Standard
[IEEE90] was issued in 1990. Supplement A appeared in 1993 [IEEE93a] and con-
tained a thorough rewrite of the fundamental chapter describing the Boundary
Register. Then in 1994, Supplement B issued. This supplement contained the formal
description of the Boundary-Scan Description Language (see Chap. 2) known as
BSDL. The Standard was once again released in 2001, containing both previous
supplements and some smaller changes as well. The remainder of this chapter gives
an overview of the Standard2 upon which subsequent chapters of the book rely. The
IEEE requires the following disclaimer, so please note:
The information presented in this book represents the interpretation of the IEEE 1149.1,
1149.4, 1149.6, 1149.8.1 and 1532 Standards by the author. If you intend to use these
Standards, you should always refer to the official documents provided by the IEEE, taking
care to obtain the latest issue and any Supplements.

First, we give a brief preview of digital test technology before the advent of
Boundary-Scan.

1.1 Digital Test Before Boundary-Scan

Digital logic testing is nearly as old as the digital system, because it was quickly
realized that volume production of digital boards and systems could not be economi-
cal without some type of formalized testing. Furthermore, this testing should be
accomplished with relatively unskilled labor to free designers for new projects. This
led to the birth, in the 1960s, of the Automatic Test Equipment (ATE) industry.3

1.1.1 Edge-Connector Functional Testing

The first digital testers were often not ATE systems at all, but rather, “hot mock-ups.”
These consisted of testbeds cobbled together on a designer’s workbench along with
a few instruments such as signal sources, digital word generators, and other rigging
that attempted to approximate the operating environment of the board or system to
be tested. Sometimes, a known-good system was used as a mock-up to test newly
manufactured boards and indeed, this is still widely in use today for final assurance4

2
In this portion of this book, the term “Standard” shall refer to 1149.1. Later we will switch our
attention to 1149.4, 1149.6 and 1532.
3
There were many examples of proprietary test systems in existence well before this time, typi-
cally at the larger, vertically integrated electronics manufacturers.
4
The quality of this “assurance” varies wildly from place to place. In some instances, the effective-
ness is good. In other cases, this last test step may be nearly useless, serving mainly as a psycho-
logical comfort, or the fulfillment of some contractual agreement.
1.1 Digital Test Before Boundary-Scan 5

that a board meets its specifications. The main problem with the hot mock-ups is that
it generally takes a skilled person, very familiar with the design of both the board
and the mock-up, to construct tests and evaluate the results of a failing test.
The commercial ATE industry got started by attempting to provide a universal
environment for testing digital boards or systems. This amounted to providing
power supplies for the device or unit under test (DUT or UUT) and a collection of
programmable digital drivers and receivers operating in parallel under the control of
a test sequencer. These resources were usually fixed in some physical format (a box)
that had to be connected to the DUT via some adaptation scheme. The obvious
method was to provide an interface from the tester to the edge-connector(s) of the
DUT via a “test adapter.” This became known as edge-connector functional test.
Thus, a universal hot mock-up was approximated.
Of course, this approach had problems: it was not really universal and it was not
a good approximation of the ultimate environment of the DUT. For example, edge-
connector functional testers were inevitably slower than the environment of the DUT,
because testers were built from existing components and expected to last a long time
to justify their (high) capital expense. Thus, the circuits they were testing were often
newer generations of higher speed and denser logic. This taxed their abilities. But,
the biggest problem of all was the difficulty in programming the tester. This spawned
the research field of digital test generation, which has kept legions of investigators
busy for decades. (See [Agra88] for a tutorial, history, and many references.)
In attempting to create stimulus and response patterns for assemblies of complex
digital components, whole industries have been created. The most popular tool is
the logic simulator. A logic simulator allows a designer to create an abstract model
of a circuit, then apply stimulus “vectors” to it and let the model produce the output
or response “vectors”. By adding the capability of injecting failure mechanisms
(faults) into the model, it was then possible for a simulator5 to track differences in
how the circuit responds to stimulus; if the differences were visible at an observa-
tion point (like an edge-connector pin), the fault was said to be “detected.”
Clever circuit designers with intimate knowledge of how a circuit behaves still
have some difficulty in deriving stimulus vectors that will detect all the faults possi-
ble6 within a circuit.7 Worse, it is often the case that the original designer was not
available (or motivated) to create tests. Thus a harried, overburdened test engineer
was expected to receive a complex design and create tests with little or no information
on how the design worked.

5
In the early days of simulation (late 1960s) simple gate level models or systems of Boolean logic
equations were used to describe circuits. Now there is a range of technology spanning transistor
level models to high level behavioral models.
6
“Faults” are an abstraction. The most popular fault model is the Single Stuck-at fault model.
Considering multiple Stuck-at faults is explosively combinatorial and quickly become intractable.
Thus, “all faults” means “all faults that are practical to consider.”
7
Automatic Test Generation software has had marginal success in supplanting humans in this task.
In cases where strict design rules are obeyed, automation can be achieved. For many electronics
manufacturers, this has not been practical.
6 1 Boundary-Scan Basics and Vocabulary

By the mid-1970s, the severe blow was delivered to simulator-based functional

testing (although it survived in certain niches) in the form of the (LSI) of integrated
circuits. At this time, the sizes of ICs exploded beyond these capacities:
• The capacity of existing simulators to process the size of models.
• The capacity for creating accurate models for LSI circuits.
While today, the Intel 8008 microprocessor seems like a trivial relic, it was at the
time a revolution that stymied simulator-based functional testing.
Simulator-based functional testing is enjoying resurgence today. There are two
contributing factors: first, today’s simulation tools have made significant strides in
catching up with IC technology; second, the successor to functional testing
(In-Circuit testing) is running into obstacles that are threatening its effectiveness.

1.1.2 In-Circuit Testing

The successor to simulator-based functional testing became pre-eminent in the lat-

ter 1970s; In-Circuit testing (ICT). The key concept (shown in Fig. 1.1) was that
accessing the circuit via the edge-connector was too limiting. What if we could

Device Under
Test Fixture
Fixture Probe
Wiring

PC Board Under Test

Test System
Actual
D1
Receive R1
Pass/Fail
D2 States
0=Pass
R2 1=Fail
D3
D4 Pass/Fail
Expected
Receive
States
Drive States
ICTDUT

Fig. 1.1 In-Circuit test setup with full nodal access. The component under test may be embedded
within a board and connected to other components
1.1 Digital Test Before Boundary-Scan 7

access internal nodes as well? What if we could observe these nodes AND we could
also stimulate8 these nodes?
With In-Circuit testing, we could now divide and conquer formidable digital
circuits by testing individual components as if they were standing alone. This
reduced the test preparation problem to that of a (significant) one-time investment
of a test per IC, which could then be recalled from a test library for each application
instance of the IC.
If the In-Circuit test for a IC failed, then more relevant diagnosis was possible;
the problem had to be in the vicinity of the IC or its interconnect. A weakness of
In-Circuit IC testing was that opens on IC inputs could not be accurately diagnosed
and could indict the IC itself. This could cause us to replace the (expensive) IC
rather than touching up a faulty solder connection. However, the overall efficiency
of preparing and interpreting tests was overwhelmingly popular. In-Circuit testing
became King. (See [Park87, Coom95] for more detail on the In-Circuit technique.)
But, as technology marched on, problems grew for In-Circuit testing as well. The
In-Circuit approach depends on a bed-of-nails test fixture, such as the one shown in
Fig. 1.2, to gain access to the internal nodes of the DUT. In the 1970s and into the
1980s, IC packaging technology was dominated by dual-inline, through-hole-
mounted packages. This meant that every board signal was visible on the bottom of
a board where they were soldered to through-hole package pins and the majority of
these pins were spaced on tenth-inch (100-mil) centers. It was common to arrange
In-Circuit fixture nails to target the IC pins9 themselves.
With the switch to Surface-Mount Technology (SMT) and much finer packaging
geometries, new problems arose. First, there were no through-hole pin targets for
In-Circuit nails. Second, some board-level signals may never appear on the bottom
side of the board if In-Circuit test access was not a design criterion. Third, for fur-
ther packing density, ICs might be mounted on both sides of the board. This all led
to access problems; some board nodes may be inaccessible to In-Circuit nails.
Notice I did not list fine-pitch package leads as a problem. One of the fallacies
of SMT testing is that fine-pitch packages are automatically inaccessible to nails.
This is a carryover from the days when In-Circuit nails were targeted at package pins.
With fine pitch packages, this is not feasible. What must be done is to target
inter-layer vias10 or deliberately placed test pads. (See [Bull87] for a practical

8
Stimulating embedded nodes requires the ability to overdrive the states that upstream ICs may be
driving. This “backdrive” capability requires tester drivers that can source/sink in excess of 700
milliamperes of current (at speed) for many of today’s logic families.
9
When targeting IC pins, the test probes often do not look like sharpened nails, but instead have a
variety of machined surfaces that are circular and contain a “waffle” pattern of small, sharpened
points that will not slip off the targeted pin/solder surface. This surface, in time will collect solder
flux and other debris leading to contact problems. Today’s nails are usually targeted at specific test
pads and have a single (very) sharp point.
10
A “via” is a cylindrical conductor that makes a physical connection between segments of a node
on different layers of a printed circuit board. Most vias traverse the entire thickness of the board
and are thus visible to In-Circuit nails. These are referred to as “natural” test points [Bull87]. Those
that do not pierce the entire thickness and are not visible from the outside are called “blind” vias.
8 1 Boundary-Scan Basics and Vocabulary

Precision Tooling Pin Board Under Test

Gasket

Test Probe
Platen
Vacuum Channel

Fixture Personality
Wire Pin

Tester
Interface
Pins
Removeable
Alignment Test Electronics
Plate
ICTVFixt

Fig. 1.2 Cutaway drawing of a board resting on top of an In-Circuit, vacuum-actuated test fixture:
the “bed of nails.” The module interface pins are the mechanical interface to the ATE pin electron-
ics, which are placed very close to reduce path lengths

analysis of SMT probing.) This necessitates having precise X-Y coordinate location
data for all test points and vias, not just the package pins. The development of
“Bead Probe” technology [Park04, Park05a] is a way to facilitate test pads, making
contacts with them more reliable while reducing their overall size. Bead probes
have the important advantage of not disturbing wiring layout and interfering with
high-speed signaling.
Nevertheless, the trend is clear; board-level probing will become increasingly
difficult and costly so that alternatives are needed. Boundary-Scan clearly makes a
contribution to solving this problem. As we shall soon see, Boundary-Scan actually
helps one prolong the life of the In-Circuit approach, because it allows the reduction
of the number of nails needed to test a board while maintaining fault coverage.
This reduction in nail count tracks the increasing difficulty in placing nails.
1.2 The Philosophy of 1149.1 9

1.2 The Philosophy of 1149.1

IEEE Standard 1149.1-2001 [IEEE01] is a testing standard. However, upon reading

it, you mostly find that it is a collection of design rules, and that these are applied at
the Integrated Circuit (IC) level. Yet, the Standard is intended to have impact at
several points in the life cycle of a product. These are:
• At the Integrated Circuit level. The Standard facilitates IC testing and has direct
support for Built-In Self-Test [Bruc91].
• At the Printed Circuit Board level. The Standard facilitates Board testing. It can
be used for bench testing of prototype boards [Hall89], for production testing
[Hans89a, Hans89b, Park89, Park90a, Robi90, Coom95] and can be used to
support emulation functions [AMD91].
• At the module or system level. The Standard can be used to support the testing
of higher-level assemblies from modules [Poss91] and “boxes” [Fasa89, Swee88]
to full systems [Lefe90]. Here, the Standard may also cooperate with other
standards such as 1149.5 [IEEE95].
Next, you will notice that the Standard has two major modes of operation.
These modes are defined by setting up the 1149.1 portion of the ICs with specific
instructions. The major modes are:
• Non-Invasive. The Standard specifies a set of resources guaranteed to be inde-
pendent of the rest of the logic (called the System Logic11) within an IC. In Non-
Invasive mode these resources are used to communicate asynchronously with the
outside world to set up tests or read out results. These activities are invisible to
the normal behavior of the IC and may be conducted concurrently with them.
• Pin-Permission. The Standard specifies instruction modes of operation that can
usurp control of the input/output (I/O) pins of the IC, effectively disconnecting
the ICs System Logic from the outside world. These modes allow the testing of
the ICs System Logic or its isolation from testing activities taking place at its pins.
The implications of these major modes are extensive. When a circuit assembly,
such as a board or system, is first “brought to life” by applying power, it must be
taken to an initial state from which all future behavior progresses in an orderly fash-
ion. All 1149.1 ICs must “wake up” in non-invasive mode. While 1149.1 ICs are
operating in non-invasive mode, the assembly will initialize to a proper starting state,
at least to the extent that any faults that may exist will allow. However, when any one
of the 1149.1 ICs switches to a pin-permission mode, this disconnects its System
Logic from the rest of the circuit. For circuit assemblies of non-trivial complexity,
this constitutes radical surgery. As with any surgery, great care might be needed in
post-operative recovery. (I will refer to a number of problems through the course of
this book; this one will be called the Lobotomy problem and will be revisited later.)

11
In the literature, the term “System Logic” has a number of synonyms. Some are “core logic”,
“internal logic”, and “mission logic”. Currently, with the attention attracted by the 1149.4 Analog
Test Bus Standard, there is a move to replace “logic” with “circuitry”.
10 1 Boundary-Scan Basics and Vocabulary

The Standard tends to view itself as a test vehicle that when put to use (that is,
when pin-permission modes are invoked) will do useful test functions. After these
useful things are done, the Standard offers little guidance on what may be neces-
sary12 next. It behooves the user of the Standard to study what after-effects may
occur when the circuit assembly has completed an 1149.1-based operation. It might
be necessary to immediately perform a hard reset or remove the power because bus
driver conflicts could be the result when leaving the pin-permission mode.
Finally, the Standard is highly extensible, allowing designers to add modes of
operation (either non-invasive or pin-permission) in support of functions useful at
any level(s) of assembly. This flexibility is a fundamental contribution. It allows a
variety of testing schemes to be accessed in a standardized manner. Further, as will
be seen in Chap. 4 and also Chap. 9, it allows for other activities not necessarily
recognized as “test.”

1.3 Basic Architecture

The basic architecture of 1149.1 Boundary-Scan is incorporated at the Integrated

Circuit level. See the illustration in Fig. 1.3. First, four (optionally, five) new pack-
age pins are dedicated to Boundary-Scan. These pins form the Test Access Port
(TAP) and must be dedicated to Boundary-Scan; they may not be shared with any
other function. These pins are used with a simple protocol to communicate with on-
chip Boundary-Scan logic.
The protocol is driven by two of the pins (three if the optional Test Reset TRST*13
input pin is included14). These two input pins are a Test Clock (TCK) and a Test Mode
Select (TMS). The remaining two pins are for serially shifting data into and out of the
IC, labeled Test Data In (TDI) and Test Data Out (TDO). The Standard requires that
TMS, TDI and TRST* float high15 if they are unconnected (intentionally or due to a
fault). This requirement enhances system reliability (as will be seen) since these

12
With the advent of the 2013 version of 1149.1 Boundary-Scan, the concept of “Test Mode
Persistence” has been introduced to give test engineers a tool to manage post-testing activities on
boards. See Sect. 11.3.4.1 in Part 2 of this book.
13
As in the Standard itself, signals that are asserted or active in the low state will have an asterisk
suffix. All others are asserted in the high state.
14
Making TRST* optional allows the tradeoff of having an asynchronous reset for the TAP versus
the cost of adding a fifth pin.
15
This requirement implies the use of internal pull-ups on these pins, which drain current. There
are two negatives to this that sometimes tempt designers to ignore the float-high rule; first, in ultra-
low power systems (for example, battery-powered), the extra power drain is a concern. Second, the
quiescent current consumption in CMOS ICs (IDDQ) is significantly higher which frustrates
IDDQ testing [Hawk85], an example of two testing methodologies in conflict. These negatives can
be mitigated with clever design. For example, as an extension of the standard, a designer could
provide a mode that turns off the pull-ups for IDDQ testing.
1.3 Basic Architecture 11

Boundary Register Cell Boundary

Register

System I/O

System I/O
System
Circuitry

Device ID Register

Bypass Register

Instruction Register

(Control Signals)

TDI TAP Controller TDO

TCK
TMS
TRST*
SmplArch

Fig. 1.3 General, simplified architecture of an 1149.1 compliant Integrated Circuit

values on these pins permit fail-safe operation. Second, on the IC die itself, a simple
finite state machine is added called the TAP controller. It recognizes the communica-
tion protocol and generates internal control signals used by the remainder of the
Boundary-Scan logic. The TAP controller is driven by TCK and TMS (and optionally,
TRST*, if it exists) only; no other signals affect the TAP controller.
Third, on the die again, is a Boundary-Scan Instruction Register and decode
logic. This register is controlled by the TAP and can be placed between TDI and
TDO for loading (and unloading) serially shifted instruction data. The Instruction
12 1 Boundary-Scan Basics and Vocabulary

Register is used to set the mode of operation for one or more data registers. Several
instruction modes are mandated by the Standard. Others are described, but are
optional. Rules are also given that allow the addition of user-defined instructions
and modes.
Last, also on the die, is a collection of Boundary-Scan data registers. Two are
always required to be present on an 1149.1 component: the Bypass Register and the
Boundary Register. Several others are described by the Standard such as a Device
Identification Register, but are optional. Finally, rules are given for adding
user-defined data registers.

1.3.1 The TAP Controller

The TAP controller is a finite state machine with a state diagram containing 16 states.
A transition between states only occurs on a rising edge of the Test Clock (TCK) or
asynchronously with the assertion of Test Reset (TRST*) if it exists. An assertion of
TRST* will always send the machine to the reset state. A synchronizing sequence for
the state machine also exists: five cycles of TCK with TMS held high will set the
machine to the reset state, regardless of its current position in the diagram.
The state transition diagram is shown in Fig. 1.4. It is the fundamental “road-
map” that all 1149.1 applications must follow. Each state contains a label. Each arc
between states is labeled with a 0 or 1 indicating the logic value of TMS that must
be set up before the rising edge of TCK to cause the transition. Falling edges of
TCK do not cause state transitions, but cause other actions within the architecture.
The asynchronous transitions due to TRST* are not shown, but all lead to the
Test-Logic-Reset state.
Looking at Fig. 1.4 you will notice that there are two vertical columns of seven
states each and that they are identical except for the labels they carry. Furthermore,
notice that the labels are quite similar. Indeed, the left vertical column is the data
column and the right vertical column is the instruction column. These two columns
reference data registers (DR) or the Instruction Register (IR) respectively. They
behave in an otherwise identical fashion that greatly simplifies understanding them.
The purpose of each state follows.

1.3.1.1 Test-Logic-Reset

This is the reset state. In this controller state, the test logic is disabled16 so that normal
operation of the IC’s system circuitry can proceed unhindered. The Instruction
Register is initialized to contain the IDCODE instruction (described in Sect. 1.4.2) if

16
An exception to this occurs if the device has “Test Mode Persistence” enabled. See Sect. 11.3.4.1
in Part 2 of this book.
1.3 Basic Architecture 13

Test-Logic-
1 Reset
0
1 1 1
0 Run-Test-Idle Select-DR-Scan Select-IR-Scan

0 0

Capture-DR Capture-IR
1 1
0 0

Shift-DR 0 Shift-IR 0
1 1

Exit1-DR Exit1-IR
1 1
0 0

Pause-DR 0 Pause-IR 0

1 1
0 0
Exit2-DR Exit2-IR
1 1

Update-DR Update-IR

1 0 1 0

TAPD Data Column Instruction Column

Fig. 1.4 State transition diagram of the 16-state TAP controller

the component contains a Device Identification Register or the BYPASS instruction

(see Sect. 1.4.1) if the component does not contain a Device Identification Register.
Regardless of the TAP controller’s current state, it will enter Test-Logic-Reset when
TMS is held high for at least five rising edges of TCK17 (or when an asynchronous
TRST* is asserted). The controller remains in this state while TMS is high. Power-
up should also force the TAP Controller to this state.

1.3.1.2 Run-Test/Idle

Once entered, the controller will remain in the Run-Test/Idle state as long as TMS is
held low. When TMS is high, the controller moves to the Select-DR-Scan state.

17
Upon entering Test-Logic-Reset by means of clocking TCK, it is necessary to return TCK to 0 (a
falling edge) to completely reset certain portions of the 1149.1 logic that are sensitive to falling
edges of TCK. TRST* on the other hand completely resets all 1149.1 circuitry immediately.
14 1 Boundary-Scan Basics and Vocabulary

In the Run-Test/Idle state, activity in selected test logic occurs only when certain
instructions are present. For example, the RUNBIST instruction (described in
Sect. 1.5.3) causes a self-test on the IC’s system circuitry to execute. Self-tests
selected by other instructions can also be designed to execute in this state.18 For
instructions that do not cause functions to execute in this state, all test data registers
selected by the current instruction retain their current states.

1.3.1.3 Select-DR-Scan

The Standard calls this a “temporary controller state”, meaning that it will be exited
on the next rising edge of TCK. Here, a decision is made whether to enter to Data
Register (DR) column, or to continue on to the Instruction Register (IR) column. If
TMS is held low when the controller is in this state, the controller moves into the
Capture-DR state and a scan sequence is initiated for the selected test data register.
If TMS is held high, the controller moves on to the Select-IR-Scan state.

1.3.1.4 Select-IR-Scan

This is a temporary controller state. Here, a decision is made whether to enter the
Instruction Register (IR) column, or to reset the TAP Controller by returning to the
Test-Logic-Reset state. If TMS is held low when the controller is in this state, then
the controller moves into the Capture-IR state and a scan sequence is initiated for
the Instruction Register. If TMS is held high, the controller returns to the Test-
Logic-Reset state.

1.3.1.5 Capture-IR

In this controller state, the shift-register19 contained in the Instruction Register par-
allel loads a pattern of fixed logic values on the rising edge of TCK. The two least
significant bits20 are assigned the values “01”. Any higher-order bits of the Instruction
Register, if they exist, may receive fixed bit values or design specific values. This bit
pattern is not necessarily an instruction; it has significance as a test pattern for the
integrity of the 1149.1 circuitry as will be seen in Chaps. 3 and 5.
When the TAP Controller is in Capture-IR, the controller enters either the
Exit1-IR state if TMS is high or the Shift-IR state if TMS is low.

18
See also the 1149.6 (Chap. 8) and 1532 standards (Chap. 9) which use the Run-Test/Idle state
extensively to control activities related to testing and device programming.
19
Registers are constructed with dual ranks, a shiftable part and a hold part to prevent rippling, due
to shifting, from being visible to downstream logic. When we say a register is selected or shifted,
we mean the shift portion of it which is connected between TDI and TDO.
20
Throughout this book, any pattern of bits will be displayed with the most significant bit on the
left, through to the least significant on the right. The least significant bit would be the first bit
shifted into TDI or out from TDO.
1.3 Basic Architecture 15

1.3.1.6 Shift-IR

In this controller state the Instruction Register is connected between TDI and TDO
and shifts, on each rising edge of TCK, the captured pattern one stage towards its
serial output. It also shifts the new instruction bits into the Instruction Register from
TDI. When the TAP Controller is in this state, the controller enters either the
Exit1-IR state if TMS is high or remains in the Shift-IR state if TMS is low. By stay-
ing in Shift-IR, a long sequence of instruction bits can be shifted into the instruction
register.
As can be seen by examining Fig. 1.4, it is possible to return to Shift-IR by pass-
ing to the Exit1-IR, Pause-IR and Exit2-IR states. This is important if an external
controller (called a Boundary-Scan master, see Sect. 5.2.7) is loading instruction
bits but does not have enough memory depth to complete the entire shift sequence
in one burst. The shift sequence can be broken into manageable pieces by passing to
Pause-IR21 while the next portion of shift data is prepared.

1.3.1.7 Exit1-IR

This is a temporary controller state. At this point, a decision must be made whether
to enter the Pause-IR state, or the Update-IR state. If TMS is held high while in this
state, the controller enters the Update-IR state, which terminates the scanning pro-
cess. If TMS is held low, the controller enters the Pause-IR state.

1.3.1.8 Pause-IR

This controller state allows shifting of the Instruction Register to be temporarily

halted. It is used, for example, when Automatic Test Equipment (ATE) reloads tes-
ter memory. The controller remains in this state while TMS is low. When TMS goes
high, the controller moves on to the Exit2-IR state.

1.3.1.9 Exit2-IR

This is a temporary controller state. Once again a decision must be made whether to
move on to the Update-IR state, or return to the Shift-IR state. If TMS is held high
while in this state, the scanning process terminates and the TAP Controller enters
the Update-IR state. If TMS is held low, the controller enters the Shift-IR state.

21
Another approach to solving this problem is to simply stop the TCK signal (in the low state)
while in Shift-IR while overhead activities are processed. However, some Boundary-Scan masters
may not be capable of halting TCK.
16 1 Boundary-Scan Basics and Vocabulary

1.3.1.10 Update-IR

In Update-IR, the instruction previously shifted into the Instruction Register is

latched, on the falling edge of TCK, by the hold portion of the Instruction Register.
Once the new instruction has been latched, it becomes the current instruction setting
a new operational mode. When the TAP Controller is in this state, the controller
enters either the Select-DR-Scan state if TMS is high or the Run-Test/Idle state if
TMS is low.

1.3.1.11 Capture-DR

In this controller state, data can be parallel-loaded into the shift portion of the test
data register selected by the current instruction on the rising edge of TCK. When the
TAP Controller is in this state, the controller enters either the Exit1-DR state if TMS
is held high or the Shift-DR state if TMS is held low.

1.3.1.12 Shift-DR

In this controller state the test data register connected between TDI and TDO, as
selected by the current instruction, shifts data one stage towards its serial output on
each rising edge of TCK. At the same time, it shifts data into data registers from TDI.
When the TAP Controller is in this state, the controller enters either the Exit1-DR
state if TMS is held high or remains in the Shift-DR state if TMS is held low.
As can be seen by examining Fig. 1.4, it is possible to return to Shift-DR by pass-
ing to the Exit1-DR, Pause-DR and Exit2-DR states. This is important if an external
controller (called a Boundary-Scan master, see Sect. 5.2.7) is loading data bits
but does not have enough memory depth to complete the entire shift sequence in
one burst. The shift sequence can be broken into manageable pieces by passing to
Pause-DR22 while the next portion of shift data is prepared.

1.3.1.13 Exit1-DR

This is a temporary controller state. At this point, a decision must be made whether
to enter the Pause-DR state, or the Update-DR state. If TMS is held high while in
this state, the controller enters the Update-DR state, which terminates the scanning
process. If TMS is held low, the controller enters the Pause-DR state.

22
As before with instruction shifting, we could simply stop the TCK signal (in the low state) while
in Shift-DR while overhead activities are processed if stopping TCK is supported.
1.3 Basic Architecture 17

1.3.1.14 Pause-DR

This controller state allows shifting of the test data register in the serial path between
TDI and TDO to be temporarily halted. It is used, for example, when ATE systems
reload tester memory. The controller remains in this state while TMS is low. When
TMS goes high, the controller moves on to the Exit2-DR state.

1.3.1.15 Exit2-DR

This is a temporary controller state. Once again a decision must be made whether to
move on to the Update-DR state, or return to the Shift-DR state. If TMS is held high
while in this state, the scanning process terminates and the TAP Controller enters the
Update-DR controller state. If TMS is held low, the controller enters the Shift-DR state.

1.3.1.16 Update-DR

Some test data registers might be provided with a latched parallel output to prevent
changes at the parallel output while data is shifted in the associated shift-register path
in response to certain instructions. In Update-DR, data is latched, on the falling edge
of TCK, onto the parallel outputs of these test data registers from the shift-register
path. The data held at the latched parallel output changes only in this state. When the
TAP Controller is in this state, the controller enters either the Select-DR-Scan state if
TMS is high or the Run-Test/Idle state if TMS is low.
A few additional remarks about the actions of the Boundary-Scan test logic are
in order.
• The two shift states Shift-IR and Shift-DR both activate the output driver for the
TDO pin. This driver remains active until the falling edge of TCK in Exit1-IR or
Exit1-DR respectively. At all other times the TDO driver is turned off, that is, in
a high impedance state.
• In either update state (Update-IR or Update-DR), the update process of transfer-
ring data from the shift portion of the shift register to the hold rank occurs on the
falling edge of TCK. Thus, a write operation23 occurs on the falling edge.
• In either capture state (Capture-IR or Capture-DR), the data is captured by the shift
portion of the target register between TDI and TDO on the rising edge of
TCK. Because this edge causes the TAP controller to leave the capture state, the
data is captured on either arc leaving the capture state. We call this a read operation.
Paired with the write operation of updating, these two operations allow a Boundary-
Scan circuit to write data, and later read it in no fewer than 2.5 cycles of TCK.

23
The meaning of “write” operation will become clearer in the description of the Boundary
Register.
18 1 Boundary-Scan Basics and Vocabulary

• Data is shifted out on TDO on the falling edge of TCK when in either of the
two shift states. Note however that data is shifted in from TDI on the rising edge.
This yields two effects:
– Data is shifted out when taking either arc that leaves a shift state. A common
mistake is to associate shifting with the state and not the arc. When you want
to shift one last bit into a register, you must take the arc that goes to Exit1-IR
or Exit1-DR. No data is shifted by the rising edge of TCK that first brings the
TAP controller into a shift state from either Capture-DR or Capture-IR.
– The data that might be present on TDO when first entering a shift state will
not be valid until after the first falling edge of TCK. Data is set up on TDO a
half TCK cycle before TDI is read for the first time.
As of this writing, many TAP circuits have been designed and as might not sur-
prise, their designs are quite different. A problem pointed out by Lavo [Lavo00] is
that you might want to take Boundary-Scan designs from different sources and
merge parts of them together. This may be frustrated by hard-wired designs; simple
things like the assertion polarities might be different. Lavo has suggested that we
develop a “universal”, synthesizable TAP description in a high-level design lan-
guage, and then use it for all new designs. Then it would be easier to re-use 1149.1
designs across our industry. Steps in this direction were taken with the 2013 issue of
1149.1, as seen in Chap. 11, in Part 2 of this book.

1.3.2 The Instruction Register

The Instruction Register defines the mode in which Boundary-Scan data registers
will operate. As with most other registers in an 1149.1 design, it is composed of a
shift rank and a parallel hold rank as shown in Fig. 1.5. The shift rank can be loaded
in parallel at Capture-IR, shifted between TDI and TDO at Shift-IR, and the contents
of the shift rank are transferred to the hold rank at Update-IR.
Each Instruction Register cell comprises a shift register flip-flop and a parallel
output latch.24 The shift registers hold new instruction bits moving through the
Instruction Register. The latches hold the current instruction in place while any
shifting is done. This prevents “shift ripple” from being observed at the register
parallel hold outputs during shifting. (This ripple-free behavior is important to many
Boundary-Scan applications.)

24
The parallel output stage can be implemented with a simpler latch. The shift register element
must be a full edge-triggered design or equivalent.
1.3 Basic Architecture 19

Parallel Hold Element

Parallel Out
Parallel In/Parallel Out
Shift Register Element
Shift In Shift Out

Parallel In
Parallel Hold Data

TDI 5 4 3 2 1 0 TDO

Parallel Capture Data ParaShft

Fig. 1.5 Architecture detail of a typical Boundary-Scan register with shift and parallel hold ranks

Mandatory and optional instructions are defined by IEEE Standard 1149.1; the
instructions will be discussed later in this chapter. Design-specific instructions can
also be added to a component by a designer. The minimum size of the Instruction
Register is two cells. The size of the register dictates the size of the instruction
codes that can be used: code size must match the length of the register.
The two least significant register cells must capture a fixed binary “01” pattern
during controller state Capture-IR. (These bits will be used later for testing the
integrity of the 1149.1 logic. See Sect. 3.2.1 on page 124.) Higher-order bits of this
register, if they exist, may capture fixed bits or variable, design-dependent bits. The
instruction shifted into the shift register flip-flops is latched into the parallel hold
latch outputs at the completion of the shifting process; this must occur during the
Update-IR state only. This requirement ensures that the instruction changes only at
the end of the Instruction Register (IR) scanning sequence. The values latched into
the Instruction Register parallel hold output latches define the test mode to be
entered and the test data register to be accessed.
It is not possible to directly observe the TAP Controller state for the purpose of
testing the TAP itself during IC test. Some designers have elected to have the higher-
order bits of the Instruction Register capture internal states of the TAP Controller,
or to capture instruction decode states of the previously loaded instruction. These
are then shifted out where they can be observed. However, there are good reasons to
20 1 Boundary-Scan Basics and Vocabulary

Table 1.1 Instruction register operation during each TAP controller state
TAP controller state Shift register flip-flops Parallel output latches
Test-Logic-Reset Undefined Set to give the IDCODE instruction if a
Device Identification Register is present, or
BYPASS if no Device ID Register exists
Capture-IR Load “01” into LSBs Retain last state
and design-specific data
into any MSBs
Shift-IR Shifts instruction bits Retain last state
towards the serial output
Exit1-IR Retain last state Retain last state
Exit2-IR
Pause-IR
Update-IR Retain last state Latch data from shift register flip-flops into
the parallel hold latches
All other states Undefined Retain last state

fix at least some of the higher-order bits. (See Sect. 3.2.1 on Integrity Testing in
Chap. 3.) Also, if this technique is used, it is possible for the 1149.1 implementation
to exhibit strange behavior. Consider what happens when the path through the state
diagram is Capture-IR to Exit1-IR to Update-IR. In this instance, design-dependent
bits are captured in the Instruction Register, then latched as the next effective
instruction. While this may be nonsensical to do, it is possible to do.
When a reset is applied to TRST*, or after the controller enters the Test-Logic-
Reset state, one of two instructions must be latched onto the Instruction Register
outputs. If the IC has a Device Identification Register, then the IDCODE instruction
bit pattern must be loaded onto the parallel hold rank. Otherwise, the BYPASS
instruction is loaded. Table 1.1 summarizes the behavior of the Instruction Register
during each TAP Controller state.

1.3.2.1 A Sample Instruction Register Cell

Figure 1.6 shows an example of a single Instruction Register cell. The signals labeled
“Capture Data” and “Instruction Bit” are the parallel input and output. The pins
labeled “From Previous Cell or TDI” and “To Next Cell or TDO” are the serial input
and output of the Instruction Register’s shift-register flip-flops. The pin labeled
“ClockIR” is derived from TCK and clocks the shift-register flip-flop for capturing
and shifting data. The pin labeled “UpdateIR” is derived from a negated TCK and
clocks the update latch for updating the hold rank of the Instruction Register. The pin
labeled “ShiftIR” is true only when the TAP Controller is in Shift-IR. The pin labeled
“Reset*” is true only when the TAP Controller is in Test-Logic-Reset. TAP Pin TRST*,
asserted asynchronously, will immediately clear (or preset) the state of the hold latch.
Upon a TRST* or Reset*, all bits in the Instruction Register parallel hold rank will
preset or clear to set up the required initial instruction (BYPASS or IDCODE).
1.3 Basic Architecture 21

TRST*
Reset*
To Next Cell
Shift-IR G
or TDO
Capture Data 0 R
D Q D Q
Instruction
Previous cell or 1
Bit
TDI CK CK

Clock-IR
Update-IR

Instruction Reg
TDI TAP TDO

TCK
TMS
TRST*
IRClDesn

Fig. 1.6 Example of an instruction register cell design. The expanded cell shows several control
signals generated by the TAP state machine

1.3.3 Data Registers

All Boundary-Scan instructions set operational modes that place a selected data
register between TDI and TDO.25 This register is referred to as the target register.
This preserves a fundamental notion of Boundary-Scan; that TDI and TDO always

25
However, if an instruction is marked private then the size and purpose of a target register may or
may not be documented. (See Sect. 2.3.12.)
22 1 Boundary-Scan Basics and Vocabulary

constitute the two ends of a shift register. The function of this register is dictated by
the instruction currently loaded (active) in the Instruction Register. The general
architecture of most data registers is shown in Fig. 1.5 on page 19. Some data reg-
isters are simpler because they do not require a parallel hold rank. This rank may be
omitted for registers that do not control anything with their content.

1.3.3.1 Bypass Register

One mandatory data register is the Bypass Register. The Bypass Register is a simple
register that doesn’t require a parallel hold rank. This register consists of only one
scan cell. When selected by the BYPASS instruction (see Sect. 1.4.1), the Bypass
Register shortens the shift path within an IC to a single cell. This is useful for reduc-
ing shift time when testing other boundary-scan components on a board. Another
important feature of the Bypass Register is that when the TAP passes through
Capture-DR, it captures a fixed binary “0” which is subsequently shifted out. This
will be useful for chain integrity testing (see Sect. 3.2.1).

1.3.3.2 Device Identification Register

Another data register, the Device Identification Register (called Device_ID),

described by the Standard is optional. When implemented, it must be 32 bits in length.
This register contains component identification information. The register services
two functions: the IDCODE instruction (see Sect. 1.4.2) and USERCODE instruction
(see Sect. 1.4.3). This register is also simple, with no parallel hold rank required.
The Device Identification Register, when the TAP passes through the Capture-DR
state, will parallel load a fixed 32-bit identification code to be shifted out. The assign-
ment of this code is discussed in Sects. 1.4.2 and 1.4.3. This code will be useful for
chain integrity testing (see Sect. 3.2.1) as well as for simply identifying the IC.

1.3.3.3 Boundary Register

Most important is the Boundary Register, which has one or more boundary-scan
cells adjacent to each digital system input and digital system output pin (but not the
TAP Pins). This register is used to control and observe activities on the IC’s input
and output pins. The Boundary Register is a mandatory feature of IEEE 1149.1 and
is covered in more detail in Sect. 1.3.4 that follows.

1.3.3.4 User-Defined Registers

The standard also allows designers to implement user-defined registers. These reg-
isters are used in conjunction with user-defined TAP instructions for proprietary
built-in self-tests, internal scan testing, or other functions. These registers must
form a consistent shift path between TDI and TDO so that when selected, the path
is not broken (a detail sometimes overlooked by designers).
1.3 Basic Architecture 23

1.3.3.5 Registers Defined by the 2013 Release of 1149.1

Briefly mentioned here are five new data registers added to 1149.1 by the 2013 update
of the standard. These are detailed in Chap. 11, Sect. 11.3.4, in Part 2 of this book.
These registers are: ECID, Init_Data, Init_Status, Bypass_Escape and Reset_Select.

1.3.4 The Boundary Register

Figure 1.7 shows an example of a single data register cell suitable for use in a
Boundary Register. The cell design shown is flexible enough to permit the cell to be
used as an input or output cell. The “Parallel In” and “Parallel Out” labels in the
signals in Fig. 1.7 are connected to the device pin or system circuitry depending on
the role of the cell. For example, if the cell services an input pin, then the Parallel In
signal is connected to the device pin and the Parallel Output signal is connected to
the system circuitry. For a device output these assignments are reversed. Note the
capture (CAP) and update (UPD) flip-flops; these components (members of the shift
and parallel hold ranks) are important to the functionality of the data register cells
during test functions.
In Fig. 1.7 the signals labeled “Shift In” and “Shift Out” are the serial inputs and
outputs of the Boundary Register forming the shift path. The shift path links the
capture flip-flops into a shift register structure. All other signals route control sig-
nals from the TAP Controller into the cell.
For Boundary Register support of bidirectional pins, you can use one of two
approaches. First, you can use two data register cells: one as an input and one as an
output as shown in Fig. 1.8. Second, you can use a single, somewhat more complex
cell to perform both functions as shown in the lower half of Fig. 1.9. Both figures
show an additional control cell (in their upper halves) that gives the Boundary
Register control over the output enables of the driver. The Standard allows a single
control cell to fan out to multiple driver enables, though when this is done, all driv-
ers must behave identically26 to the value stored in the control cell.
Ignoring the control cell, the reversible data cell shown in the lower part of
Fig. 1.9 has the advantage of creating only one position in the Boundary Register
scan chain rather than two required by the double-cell structure of Fig. 1.8. This
reduction in cell count can be substantial for larger ICs. While the actual reduction
in silicon consumption is likely to be negligible, the reduction in shift length is ben-
eficial. Shorter registers take less time (and disc space!) to load and unload. This can
be an important factor for programming FLASH devices (see Sect. 4.10) and testing
RAM arrays (see Sect. 4.4).

26
The initial release of IEEE 1149.1 [IEEE90] did not have this restriction. Then, it was allowable
to have some drivers enabled and others disabled simultaneously by a single control cell. This
caused problems for test algorithms and decreased fault coverage so in 1993, this restriction was
added [IEEE93].
24 1 Boundary-Scan Basics and Vocabulary

Shift Out

Mode G
Parallel In 0
Parallel
Shift-DR G
Capture Update 1
Out
0 Flip-Flop Flip-Flop
D Q D Q
1
CK CK

Shift In Clock-DR Update-DR

Shift Out

Boundary
Parallel Parallel
Register
In Out
Cell

Shift In

Instruction Reg
TDI TAP TDO

TCK
TMS
BRCIDesn TRST*

Fig. 1.7 A typical boundary register cell

Inherent in the double-cell structure is the ability for the input cell to capture the
state of the package pin regardless of what the driver is attempting to do. This
allows test software, by noting a discrepancy between what the output cell is pro-
grammed to drive and what the input cells observes, to determine if the output
driver is damaged or is attempting to drive into a short.
On examination of Fig. 1.9 you will notice that it too can monitor the output pin
while the driver is enabled. This allows the state of the pin to be sensed while the
driver is driving it. The original version of the standard [IEEE90] showed a
1.3 Basic Architecture 25

Shift Out

Mode G
Parallel In 0
Parallel
Shift-DR G
Capture Update 1
Out
0 Flip-flop Flip-flop
D Q D Q
1
CK CK

Shift In

Clock-DR Update-DR Reset

To Next
Cell

System
Output Cell as above
Enable

System
Output Cell
Output
System Pin

System
Input Cell
Input

From
Previous Cell 3ClBidir

Fig. 1.8 A Bidirectional pin with separate input and output Boundary Register cells

bidirectional cell design now considered flawed27 because it lacked this important
capability. Supplement A [IEEE93a, IEEE93b] introduced this improved design
that does allow driver monitoring.
It is sometimes the case that signal inversion is an inherent feature of an input or
output buffer. However, the Standard is firm in requiring the data captured in (say) an
input Boundary Register cell to have the same polarity as the data that entered the pin.

27
The flawed cell is named “BC_6” in BSDL. Designers should avoid using it. The improved cell
is called “BC_7”. (See Sect. 2.6.3 on page 97.) Indeed, with the 2013 update of 1149.1, this cell is
officially unsupported, and erased from the supporting BSDL package STD_1149_1_2013.
26 1 Boundary-Scan Basics and Vocabulary

Mode_1 ShiftDR To Next Cell Mode_3

G
Output
0
Control
1

G
0
CAP UPD
D Q D Q
1
CK CK

Control
Cell

G Reversible System
Output
0 Data Cell Pin
Data
1

G
G
0 CAP UPD
0
1 D Q D Q
1
CK CK
G
Input 0

Data
1
From Last

UpdateDR
Mode_2

ClockDR
Cell

2ClBidir

Fig. 1.9 A Bidirectional pin served by a reversible Boundary Register cell

The cell design in Fig. 1.10 for an inverting input buffer shows two compensating
inversions that assure this requirement is met. Similarly, data shifted into an output
Boundary Register cell, upon updating, should produce the same polarity data on the
output pin. The cell design in Fig. 1.11 will compensate for an inverting output buffer.
The Boundary Register may include cells that do nothing, called internal cells.
These cells are not associated with I/O pins, or enables. They are most likely to be
found in field-programmable ICs, FPGAs, and Programmable Logic Devices, PLDs
(see Sect. 1.3.7) where bidirectional Boundary Register resources are allocated to
1.3 Basic Architecture 27

Inverting Shift Out

Input Buffer
Mode G
0
ShiftDR Capture Update To
G 1 System
Input 0
Flip-flop Flip-flop
Pin D Q D Q
Circuitry
1
CK CK

Compensating Compensating

Update-DR
Clock-DR
Inversion Shift In Inversion

BRegInvI

Fig. 1.10 Compensating inversions in an input Boundary Register cell that monitors an inverting
input buffer

Shift Out Inverting

Output
Mode G Buffer
0
ShiftDR Capture Update To
G 1 Output
From 0
Flip-flop Flip-flop
D Q D Q
Pin
System
1
Circuitry CK CK

Compensating Compensating
Update-DR
Clock-DR

Inversion Inversion
Shift In

BRegInvO

Fig. 1.11 Compensating inversion in an output Boundary Register cell connected to an inverting
output buffer

all pins because it is not known how the IC will eventually be programmed. If, for
example, each pin is configured with three cells (input, output, and output enable),
but one is programmed as a simple input pin, the one cell is used as an input cell and
the other two are not used; they still exist but are just place-holders.
When reading chapter of the Standard titled “The Boundary-Scan Register”, one
finds a number of Boundary Cell designs and rules for designing others as well. We
will use a logical symbols shown in Fig. 1.12 to denote a Boundary Register cell.
Figure 1.12a shows a common cell symbol containing a capture (CAP) flip-flop, an
update (UPD) flip-flop or latch, the parallel input (PI) and output (PO) signals and
the shift in (SI) and shift out (SO) signals. Figure 1.12b shows an “observe-only”
cell that does not have an update flip-flop.
28 1 Boundary-Scan Basics and Vocabulary

Shift Output
(SO) SO

Parallel Parallel
CAP UPD PI CAP PO
Input (PI) Output (PO)

Shift Input SI
(SI)

a b CAPUPD

Fig. 1.12 Two logical symbols for typical boundary cells, one with an Update (UPD) flip-flop (a)
and one without (b)

1.3.5 Optimizing a Boundary Register Cell Design

It is important to note that the 1149.1 Standard is a collection of rules that govern
the implementation of the facilities of the standard. The written rules tell you what
you must do. The figures published in the Standard are not rules, but examples of
ways that the rules could be interpreted. Thus there are myriad conceivable ways
you could interpret the rules to obtain new Boundary Register cell designs.
Many of the figures of Boundary Register cells shown in the Standard are fully
featured. For example, they may support several (or all) optional instructions as
well as those that are mandated. This can lead to additional complexity that could
be stripped out if you decide to support less functionality.
A common mistake made by designers who are implementing 1149.1 is to treat
the figures showing cell designs as if they were rules rather than interpretations of
rules. They look at cell design examples such as shown in Fig. 1.7 and conclude
they must use the circuit elements shown in that figure. A paper by Lee Whetsel
[Whet95] is very useful because it shows how designing from the rules rather than
the figures can lead to some fundamental optimizations. Consider one example from
[Whet95] shown in Fig. 1.13.
This design is essentially the same as that in Fig. 1.7 for the capture portion
(CAP) of the cell, but differs quite a bit in the update (UPD) portion. Whetsel attacks
the inserted delay problem (see Sect. 1.8.1) presented by the output multiplexer by
replacing it with two FET switches S1 and S2. These switches are controlled by two
new signals DC and UC from the TAP controller, replacing Update-DR and Mode.
He then commandeers the output buffer and adds a weak feedback buffer FB, con-
verting it into a latch that serves as the update latch (UPD).28 The claim is made

28
Care must be taken to assure that on transitioning from PRELOAD to EXTEST (at Update-IR),
that the update latch does indeed load the content of the Capture Flip-Flop.
1.3 Basic Architecture 29

Shift Out
DC Update Flip-flop
and Output Driver
From Core Out
S1
Shift-DR G
Capture
Flip-flop
0
S2 FB
D Q
1
CK
UC
Shift In Clock-DR FastDesn

Fig. 1.13 An example (adapted from [Whet95]) of an output cell design that eliminates both a
discrete register stage and a multiplexer delay

(arguably) that if you didn’t know this was the actual implementation, you would
conclude that the structure of Fig. 1.7 was in place. Whetsel points out that this is
true when there are no faults present. However you can determine which of these
two implementations is present if you short the output (even momentarily) since this
will have the effect of setting or clearing the update latch in his design, but not in the
“standard” design. (The 1149.1 Working Group has not taken a stand on whether
this behavior is acceptable, but it is not currently forbidden by a rule.) A desirable
side effect of this resetting/clearing is that the driver only momentarily fights with a
short that stresses the driver, while the “standard” design will persist with this stress-
ful endeavor. However, a momentary glitch presented to the Whetsel output (per-
haps even a line reflection) could conceivably cause the output to toggle.29 This
behavior treads into a gray area, again not addressed by any rules in the Standard.
The point to be made is that the Whetsel design is quite different from a “standard”
figure in 1149.1, but offers significant new advantages. It was arrived at by deliber-
ately ignoring the figures in 1149.1 and synthesizing a cell from the rules alone.
Additional references now exist on the design of the Boundary Register and how
to avoid some pitfalls. See [Cogs02, Kris02] and [Stan02], but remember to keep the
rules of the standard itself foremost in your design.

1.3.6 Architecture Summary

By now we have examined the major pieces of the Boundary-Scan architecture.

A block diagram of this overall architecture is given in Fig. 1.14.

29
Without proper design care, this driver structure could interact with external circuitry (passive or
active) to form an oscillator. If the output portion of this driver was implemented in stages of suc-
cessively larger buffers, an internal stage could have the latching property and the final stage
would isolate the latch (feedback) from outside influences. This would remove the “anti-stress”
feature of the Whetsel driver however.
30 1 Boundary-Scan Basics and Vocabulary

ArchSum
Test Data Registers

Device Outputs
Device Inputs

Boundary Reg

...
System Circuitry

Design Specific Reg

G
Device ID Reg
Mux

Bypass Reg
Mode1

Mode2

ModeN

Select
...

ClockDR Instruction Decode

ShiftDR
UpdateDR ... 0
G

TDI Instruction Register 1

ClockIR ShiftIR UpdateIR

TMS TAP
TCK Controller Select TDO
D Q
(16-State
TRST* TCK TCK*
Machine) CK
Shift

Fig. 1.14 Block diagram of a boundary-scan IC

There is a Test Access Port (TAP) Controller, consisting of a 16-state machine.

This machine is the first in a cascade of three simple state machines. The next
machine is the Instruction Register and its decode logic. The last machine is made
up of the Data Registers. In particular, the Boundary Register surrounds the System
Logic that could be looked on as a fourth machine—the one the designer originally
created. Notice also in Fig. 1.14 that TDO is synchronized by an additional register
stage clocked by the falling edge of TCK, as required by the standard. This ensures
that all transitions on TDO occur ½ TCK cycle after TDI bits are read in. As seen
earlier, all outputs under control of Boundary-Scan (system pins and TDO) change
on the falling edge of TCK.
1.3 Basic Architecture 31

1.3.7 Field-Programmable IC Devices

Field-programmable ICs are the Chameleon of the Integrated Circuit world. They
are “blank pages” that can have logic written into them while they sit on a board.
The writing process is not unlike storing data into a volatile, or non-volatile mem-
ory. If desired, new logic can be programmed in at any time. There is more about
this in Sect. 4.9, and IEEE Standard 1532 (see Chap. 9) has been developed to
codify device programming.
Field-programmable ICs often cause severe testing problems for board test.
Before programming, they have no I/O pin definition and cannot respond to tradi-
tional test techniques. By their very nature, their logic is fluid and changeable.
Preparation of conventional In-Circuit tests for such components may be delayed by
these changes. During the board design, these ICs may be the last to settle into a
“final” configuration. Furthermore, volatile devices must be programmed at the
time power is applied (often from an on-board Read-Only Memory) so there is
plenty of opportunity for board faults to cause confusion and diagnostic difficulties
(see [Park00]).
Field-programmable ICs have come in two flavors: the “blank page” containing
no pre-defined logic; and components that do have a small amount of logic in place.
In the second case, we are interested in the type of IC exemplified by the Xilinx
4005 [Xili90] or the Xilinx XC9500 family [Xili98] which contain a hard-wired
Boundary-Scan facility. Now with the advent of the 1532 standard and its wide
adoption, we have a growing supply of blank devices that can participate in 1149.1
testing before programming. This is because the very first rule in 1532 is a device
compliant with it must also be compliant with 1149.1.
The “blank page” component can always be programmed to have Boundary-
Scan logic [Xili92]. Indeed, it could have only Boundary-Scan logic rather than its
mission logic if Boundary-Scan testing is a one-time event. The mission logic would
later replace the test logic. Of course, before programming, the component is not
compliant with the Standard. The 1149.1 Working Group is also hesitant to declare
anything compliant that can have its Boundary-Scan logic “disappear” on subse-
quent reprogramming. This attitude notwithstanding, a test engineer will certainly
see the value of adding Boundary-Scan to a field-programmable IC whether or not
this facility is permanent.
The Xilinx 4005 has a hard-coded 1149.1 “shell” that is always present as shown
in Fig. 1.15. This is done by placing a TAP, an Instruction Register and a Bypass
Register onto the component infrastructure. What is left to be added is the Boundary
Register itself. This is made part of the Input/Output Blocks (IOBs)30 which are gen-
eral purpose blocks attached to each IC signal pin. Each IOB makes its associated
pin fully bidirectional, including a dedicated control cell for the output buffer enable.

30
See also the notion of a “Digital Boundary Module” introduced in Sect. 7.2.5 on page 246 by the
1149.4 standard.
32 1 Boundary-Scan Basics and Vocabulary

IOB
UC

Programmable
IOB

IOB
Device
Pin

Core
...

...
C U
IOB

IOB
C U

TDI TDO

TAP
Controller

TCK TMS
FPGAIOB

Fig. 1.15 A field-programmable component with Boundary-Scan hard-wired into its I/O Blocks
(IOBs). Each IOB starts out with bidirectional support for a component pin, but subsequent pro-
gramming may reduce each to supporting input or output only

Now all seems to be settled, except that during programming, each system pin
can take on a new personality. A pin can change from bidirectional to simple input
or output. In the case of the Xilinx 4005 this personality change causes certain
Boundary Register cells to become “internal” cells. For example, if an IOB is pro-
grammed to become a simple input, then the two cells that provide data and output
enable control become internal cells, just placeholders. Test engineers do have to
make a basic choice; they can use the full bidirectional resources of the device or
use the restricted resources defined by the system programming. Using the full
resource set gives more flexibility during test, but it may introduce new problems by
adding additional disabling problems to be solved (see Sect. 5.2.5).

1.3.8 Boundary-Scan Chains

Boundary-Scan ICs are designed to link together into chains. A simple chain on a
printed circuit board is shown in Fig. 1.16. Simple chains are a collection of
Boundary-Scan ICs with common TCK and TMS, and with their shift paths linked
together by connecting a TDO pin of one IC to the TDI pin of the following IC.
The parallel system pins of the components may be connected together. When this
is true, the Boundary Register of one component can be set up to communicate with
the Boundary Register of another. In other cases, IC pins may be connected to the
board edge connector. When connected to an edge connector or bed-of-nails, an
external ATE system can be used in conjunction with the Boundary Register to imple-
ment tests. In both cases, we can implement tests and at the same time avoid having
to set up or propagate logic values through the System Logic of the components.
1.3 Basic Architecture 33

System Circuitry

System Circuitry

System Circuitry
Bypass Bypass Bypass

Instruction Instruction Instruction

TDI TAP TAP TAP TDO
Controller Controller Controller

TCK
TMS
SmplChn

Fig. 1.16 A simple chain of boundary-scan ICs

In some cases there might be Boundary-Scan ICs connected to conventional ICs.

In such a case, it is possible to use the Boundary Register(s) to set up logic values
necessary for testing the conventional ICs. This will be covered in Chap. 4.
An important property of simple chains is that, because of the commonality of
TCK and TMS, every TAP of every IC in the chain is always in the same state.31
This means that a single TAP state diagram is sufficient to keep track of the state of
the entire chain.
Multiple simple chains could exist on a board (or in a system) where no TAP
signals are shared between them. Any parallel system signals shared between ICs of
separate chains can be tested, but we now have to coordinate the operation of mul-
tiple chains.
The Standard issued in 1990 shows some additional chain configurations that we
call conjoined chains because they consist of two (or more) chains that share certain
TAP signals. For example, two chains could share TCK and TMS, meaning they are
locked together state-wise, but have independent shift paths. In another configuration,
they could share TCK, have paralleled shift paths, but have separate TMS signals.
By clever manipulation of the TMS signals, you can make the chains co-exist.
More exotic chain configurations can be imagined, but an important question
should be asked; will the software tools at hand be able to comprehend and utilize
these more complex configurations? The answer could well be NO, so beware.

31
Exceptions could occur when some of the ICs have an optional TRST* pin. We assume all ICs
are synchronized to Test-Logic-Reset and that no assertions are made to TRST*.
34 1 Boundary-Scan Basics and Vocabulary

1.4 Non-Invasive Operational Modes

The TAP Controller and the four (optionally five) independent TAP Pins may be
operated asynchronously and independently of the System Logic. This allows the
Boundary-Scan TAP to be used without disturbing the normal operation of a chip,
board or system, as long as we utilize only the Non-Invasive modes32 of operation.
These modes are keyed to TAP instructions.

1.4.1 BYPASS

The BYPASS instruction places the single-bit BYPASS data register between TDI
and TDO. Its purpose is to produce a short one-bit shift path through a component,
and for this component to be operating normally. This instruction and its target reg-
ister are mandatory features of any 1149.1 component. Further, the bit pattern of all
1s in the Instruction Register must decode to the BYPASS instruction. Other bit
patterns may also decode to BYPASS33 if desired.
When the BYPASS instruction is in effect, the Bypass Register is parallel loaded
with a 0 upon passing through the Capture-DR state. This initializes the register
with known, predictable data.

1.4.2 IDCODE

The IDCODE instruction places the 32-bit Device Identification Register between
TDI and TDO that contains an identification code. IDCODE is an optional instruction.
The Standard makes no requirement on the instruction bit pattern used for IDCODE.
The Device ID Register is parallel loaded with a hard-coded value upon passing
through the Capture-DR state. The least significant bit (bit 0) of any IDCODE must
be a 1. This bit is the first shifted out via TDO. The other bits of the Device Identification
Register are assigned as shown in Fig. 1.17. Bits 31 to 28 (four bits) are a version
number for the IC. The version number should be changed every time the IC is
revised. Bits 27 to 12 (16 bits) are a part number assigned by the manufacturer.

32
If a Pin-Permission mode has been entered, it may be necessary to perform a reset upon both the
Boundary-Scan logic and the System Logic before the System Logic will operate normally. In
some cases, the surest, safest way of achieving this is by cycling the power.
33
The Standard also states that all unused instruction codes not declared to be private must also
decode to BYPASS.
1.4 Non-Invasive Operational Modes 35

IDAssign
Version Mandatory
(4 bits) "1"

Manufacturer's Manufacturer's
1
Part Number (16 bits) Identification (11 bits)

31 28 27 12 11 1 0

Fig. 1.17 Code bit allocation in a device identification register accessed by IDCODE

Bits 11 to 1 (11 bits) are a manufacturer’s identity number34 derived [IEEE01] from
the JEDEC (the Joint Electron Device Engineering Council) code35 [JEDE86]. The
IDCODE instruction allows a component to be identified via the Boundary-Scan port.
What about second-source manufacturers? It is expected that a second-sourced
IC will have a different IDCODE value36 (at least different in the manufacturer’s
identification) than the original IC. There is provision in the BSDL language (see
Sect. 2.3.11) to specify all IDCODEs that might exist for devices that are otherwise
(supposed to be) identical. Also beware of pin-compatible replacement components
such as we see in the microprocessor world. These devices are reverse-engineered
to have identical pinouts and system behavior, but are not likely to be identical with
respect to their 1149.1 implementation.
In an earlier discussion of the Test-Logic-Reset state (on page 13) we saw that the
Instruction Register is jammed with either BYPASS or IDCODE, if IDCODE exists.
This would allow a test sequence to proceed directly to data shifting via Capture-DR
with one of the two instructions in effect by default. Because the first bit shifted out
is a “0” for BYPASS and a “1” for IDCODE, it is possible to carry out a blind inter-
rogation of a component or chain of components. Blind interrogation can be done
with no knowledge of any Boundary-Scan device’s instruction register implementa-
tion or opcode assignments. Those possessing IDCODEs indicate so by first shift-
ing out a “1” which indicates that the next 31 bits to follow are the remainder of the
IDCODE. A “0” indicates that there is no IDCODE and that the component is in
BYPASS. In principle, blind interrogation could be used to learn the configuration
of a system that comes with a set of options.

34
There is a code (00001111111) reserved by 1149.1 and considered an “illegal” manufacturer’s
code. This code can be fed into the TDI of a chain of devices of unknown composition so that when
it finally appears at TDO, you then know you have scanned out all the devices in the chain.
35
The actual list of manufacturer’s ID numbers maintained by JEDEC has more bits, so this 11-bit
field is a compression and allows for only 2048 unique numbers. It could happen that two unique
devices could appear some day with identical IDCODE values, but the probability is low that this
will ever cause confusion in testing boards and systems.
36
This is much easier to accomplish if a second–source agreement is based upon the exchange of
design data (that can be re-synthesized) rather than based upon exchanging mask data.
36 1 Boundary-Scan Basics and Vocabulary

1.4.3 USERCODE

The USERCODE instruction places the same 32-bit Device Identification Register
between TDI and TDO as IDCODE does, but the value captured upon passing
through the Capture-DR state is user-defined. USERCODE is an optional instruc-
tion and the Standard does not specify a bit pattern for it. However, if a device does
support USERCODE, it must also contain IDCODE.
The purpose of USERCODE is to expand upon IDCODE in situations such as
for programmable ICs, where an IDCODE alone is insufficient for identifying the
IC and its programming. For example, IDCODE would alert you to the fact that an
IC was programmable, but because the programming will occur after the manufac-
ture of the IC (or board or system), the USERCODE function can be used to identify
the version of programming. The user is free to define the 32-bit USERCODE
value; a scheme similar to IDCODE, containing several fields of information would
allow the encoding of several pertinent types of information.

1.4.4 SAMPLE

The SAMPLE instruction is a mandatory instruction,37 but its bit pattern in the
Instruction Register is not specified by the Standard. This is the first instruction to
target the Boundary Register between TDI and TDO. While it does so, it does not
disconnect the System Logic from the IC pins. (See the multiplexer in Fig. 1.7 (page
23); the Mode signal is “0”.)
SAMPLE functionality occurs upon passing through the Capture-DR TAP state.
All the capture flip-flops (CAP) load the states of the signals they are attached to; IC
inputs, or System Logic signals destined for IC outputs. The Boundary Register thus
takes a “snap-shot” of the activity of the IC’s I/O pins. This data sample can then be
shifted out for examination. In principle, one can implement “logic analyzer” func-
tionality in a digital system using SAMPLE. (See the discussion in Sect. 4.2 for
some practical issues regarding the use of SAMPLE.)

37
SAMPLE and PRELOAD, in previous releases of the Standard since the beginning [IEEE90],
were one instruction with one opcode. (It was called “SAMPLE/PRELOAD”.) In a long ranging
debate, the 1149.1 Working Group has now divorced the two instructions so that each can be inde-
pendently encoded and implemented. This lays the groundwork for a possible future demotion of
SAMPLE from mandatory to optional status. (PRELOAD will remain mandatory.) There are sub-
tle implications of this move which are controversial within the Working Group and still subject to
much debate. It is possible and permissible however to merge the design of SAMPLE with
PRELOAD so that the same opcode does both functions. This is likely to be how these instructions
will be treated until SAMPLE is (if ever) demoted.
1.5 Pin-Permission Operational Modes 37

1.4.5 PRELOAD

The PRELOAD instruction is a mandatory instruction, but its bit pattern in the
Instruction Register is not specified by the Standard. This instruction targets the
Boundary Register between TDI and TDO. While it does so, it does not disconnect
the System Logic from the IC pins. (See the multiplexer in Fig. 1.7 (page 23); the
Mode signal is “0”.)
The PRELOAD function is used to initialize the capture (CAP) flip-flops of the
Boundary Register. The CAP flip-flops receive this data, which is then transferred
to the update (UPD) flip-flops upon passing through the Update-DR TAP state.
Because this data is blocked by the multiplexer (see Fig. 1.7, page 23) from being
driven out, it will not affect the IC outputs or System Logic. However, when the
multiplexer Mode line is switched by loading a Pin-Permission instruction (see
Sect. 1.5) at Update-IR, the multiplexer will switch to the update flip-flops as data
source. The PRELOAD function allows us to have proper data set up before this
switching takes place.
The PRELOAD instruction has no requirement for what is captured in the CAP
flip-flops when the TAP passes through the Capture-DR state. This allows the func-
tionality of PRELOAD to be merged with the functionality of SAMPLE such that
the two instructions need only consume one instruction bit pattern. (See the discus-
sion in footnote 37.)

1.5 Pin-Permission Operational Modes

The Pin-Permission instructions provide the next major mode of operation. These
instructions are characterized by the switching of the cell output multiplexers such
that the update flip-flop data bits are selected and passed to the parallel outputs of
the Boundary Register cells. This disconnects the component I/O pins from the
System Logic. It is important that the System Logic not be harmed by this radical
change of configuration. Thus, on component inputs, it may be necessary to add
logic to force specific holding values presented to the System Logic. For example,
the component RESET line might be forced to an asserted state by a Pin-Permission
instruction. This would prevent the System Logic from suffering internal conflicts.
Notice that both BYPASS and IDCODE are not pin-permission modes, so if a pin-
permission instruction is currently active, passing to the Test-Logic-Reset state will
remove this mode and put the IC’s test logic back into non-invasive mode.
What happens to an IC that has been held in a safe RESET state when the Pin-
Permission mode is departed; for example, when Test-Logic-Reset is entered? This
is a serious problem (the Lobotomy problem, see [Park10] and [Park11]) for IC,
board and system designers to consider. What should the System Logic do upon
“waking up” from Pin-Permission mode? One answer would be to assert, as quickly
as possible, some master reset to the entire board or system to force a safe sequence
38 1 Boundary-Scan Basics and Vocabulary

of events. However, a fault could frustrate this. Another approach would be to

remove or cycle the power, recognizing that this is not an instantaneous process. Yet
another approach is to have the System Logic remember that it was disconnected
from its I/O pins38 and stay in a benign reset state until such time as a formal reset
sequence or cycling of power is performed.

1.5.1 EXTEST

The EXTEST instruction is a mandatory instruction, but the choice of instruction

bit pattern is left to the designer. In the first edition of the Standard [IEEE90] the
all-zero instruction bit pattern was mandated to decode to EXTEST. This led to a
safety concern; what happens to a system when a stuck-at fault (such as a solder
short to ground) occurs on the TDI input of one IC? If the next instruction scan
sequence intends to load non-invasive instructions (for example BYPASS or
SAMPLE) the stuck TDI signal will instead load all zeroes into one (or more) IC’s
instruction register, causing the IC(s) to instead go into EXTEST. This could have
devastating consequences to a system performing a critical mission. To remove this
potential problem, the 1149.1 Working Group removed the all-zero requirement for
the EXTEST opcode [IEEE99] and further recommends that the all-zero opcode
now map to a non-invasive instruction, such as BYPASS to improve system safety
in the face of this possible failure mechanism.
The EXTEST instruction targets the Boundary Register between TDI and TDO. At
the Capture-DR state, all IC inputs39 are captured in their respective Boundary
Register cells.40 Looking at Fig. 1.7 on page 23, the multiplexer Mode signal is set to
“1”. Because the cell output multiplexers are reading the UPD flip-flops, all IC out-
puts and output enables are under control of the Boundary Register. Thus, during
EXTEST, we can sample the inputs and control the outputs of the IC pins. Shifting
the Boundary Register during Shift-DR allows us to read out captured input states
and to set up new output and output enable states that will become effective upon
passing through Update-DR. EXTEST is the workhorse of Boundary-Scan testing.

38
The 2013 update of 1149.1 provides an additional resource for this problem called “Test Mode
Persistence”. See Sect. 11.3.4.1 in Part 2 of this book.
39
Also, an input cell on a bidirectional I/O pin will capture that pin’s state.
40
Note the Standard only requires EXTEST to capture IC inputs (and bidirectionals) but does not
specify what must be captured by control or output cells. This will allow us to merge the behavior
of EXTEST with INTEST so that the two instructions can be implemented with a single opcode.
Another option is to implement self-monitoring outputs (see Sect. 5.1.5 on page 180) if INTEST
is not implemented.
1.5 Pin-Permission Operational Modes 39

1.5.2 INTEST

The INTEST instruction is an optional instruction and the Standard does not specify
an instruction bit pattern for it. INTEST targets the Boundary Register between TDI
and TDO.
INTEST is an inward-looking instruction; it puts the System Logic inputs under
control of the update (UPD) flip-flops of the Boundary Register input cells. The
Boundary Register cells connected to System Logic outputs and output enables
sample the states produced by the System Logic at Capture-DR. Thus, at Update-DR,
a test pattern can be applied to the System Logic inputs, and at Capture-DR, the
results of that pattern can be sampled. During shifting, these results can be shifted
out and a new test pattern can be shifted in. While this is happening, the states
driven to the component output pins are controlled one of two ways: first, they may
be under control of the Boundary Register so that they can be held at deterministic
values41 while the System Logic is being tested. The second choice is to place all
system outputs (including 2-state drivers) in a disabled, non-driving state. Whichever
option is chosen, it must be applied uniformly to all IC pins.
INTEST can be used to apply IC tests42 to the System Logic while the IC rests
In-Situ on a board. Board level conflicts can be controlled by assuring that the IC
outputs are held to benign values by the Boundary Register43 if the first output con-
trol option (above) is selected. The second option (disabling all IC outputs) will also
eliminate board level conflicts.
One major problem with INTEST IC testing is that the test is serialized and
delivered via the TAP Port. It is possible for the apparent testing rate to be greatly
reduced, by factors of hundreds or even thousands. The reduction is proportional to
the length of the Boundary Register, plus any other bits contributed by other ICs in
a chain. If the System Logic is dynamic, it might not be possible to maintain a high
enough testing rate to keep the dynamic logic alive.

1.5.3 RUNBIST

The RUNBIST instruction is an optional instruction and the Standard does not spec-
ify an instruction bit pattern for it. RUNBIST has a designer-specified target register.
The purpose of this instruction is to provide users of an IC access to internal built-in
self-tests with a standardized access protocol.

41
This option must be chosen if a merger of EXTEST and INTEST behavior is desired.
42
These tests are not the same as those applied by an IC tester in parallel to the component I/O pins.
The tests must be prepared for the System Logic I/O signals. For each bus or bidirectional pin,
there may be several System Logic I/O signals.
43
Actually, if the outputs are disabled which is an option offered by the Standard, this might not be
perfectly true. Disabled outputs may seem safe but downstream board logic may be confused by
high impedance values on their inputs.
40 1 Boundary-Scan Basics and Vocabulary

While RUNBIST is in effect, the IC output pins are controlled one of two ways
(just as for INTEST); first, under control of the Boundary Register or second, all
(including 2-state outputs) placed in a non-driving state. In the first instance, states
supplied by a PRELOAD sequence executed before loading RUNBIST will be used
to control the IC outputs while the self-test is being performed. Either method
allows us to eliminate potential conflicts that the IC might have with other board-
level components.
RUNBIST is self-initializing; it does not require any seed data (for example, to
initialize counters or signature accumulators) to be loaded in advance of its opera-
tion. Loading the Boundary Register with a PRELOAD process to eliminate board-
level conflicts is not considered part of the initialization of the self-test.
RUNBIST targets some register between TDI and TDO as specified by the IC
designer. It may be a dedicated register or it may be an existing register such as the
Bypass or Boundary Registers. The purpose of this register is to accumulate the
result of the self-test so it can be shifted out for observation. This result must be:
• Deterministic. All bits must be defined.
• Invariant for all versions of the IC.
• Independent of any activity on (non-clock) component I/O pins.
The actual self-test runs when the TAP is placed in the Run-Test/Idle state. The
clocking of the self-test may come from TCK, from the system clock(s), or both.
The production of the self-test result may take many clock cycles, but a further
requirement states that any clocks received beyond this number will not affect the
result. This freezing of the self-test result allows us to execute RUNBIST in several
components in parallel, applying clocks to all, such that the largest number required
by any component have occurred. The test result is captured by the target register in
each component upon passing through Capture-DR. Then all results can be shifted
out for examination.

1.5.4 HIGHZ

The HIGHZ instruction was introduced with the 1993 supplement to the Standard
[IEEE93a, IEEE93b]. It is an optional instruction and the Standard makes no require-
ment on its instruction bit pattern. Its purpose is to enhance the ability of In-Circuit
test ATE systems to test complex boards by reducing the potential for overdrive
damage. By loading an IC with HIGHZ we make it release control of its output
nodes. We can then safely overdrive them with an In-Circuit tester indefinitely.
HIGHZ targets the Bypass Register between TDI and TDO, to shorten the shift
path. It also causes all output and bidirectional pins to go into high-impedance states.
(In the case of asymmetrical drivers such as TTL Open-Collector or ECL Open-
Emitter drivers, the non-driving state is selected.) In this condition, In-Circuit over-
drive is not needed to gain control of the IC’s output pins. This switching to a disabled
state occurs when HIGHZ becomes effective, upon passing through Update-IR.
1.5 Pin-Permission Operational Modes 41

1.5.5 CLAMP

The CLAMP instruction was introduced with the 1993 supplement of the Standard
[IEEE93a, IEEE93b]. This, too, is an optional instruction and the Standard makes
no requirement on its instruction bit pattern.
CLAMP targets the Bypass Register between TDI and TDO, to shorten the shift
path. It also places all output and bidirectional pins under control of the Boundary
Register, which should be previously set up beforehand with a PRELOAD sequence.
These states become effective at Update-IR. This allows a test to set fixed values on
an IC’s output pins without incurring the overhead of its entire Boundary Register.
In other words, this function could have been accomplished by putting the IC in
EXTEST, but the Boundary Register would then be in the shift path (lengthening it)
and it would have to have its clamp values reinstated on every new shifting cycle.
CLAMP is intended for “digital guarding.” When testing a board, it is often nec-
essary to force static “0”s or “1”s on selected nodes in order to set up testable condi-
tions or to block interfering signals. With an In-Circuit tester having full nodal
access, we would simply assign tester drivers to the selected nodes and force the
required values. If the nodes of interest are sourced from Boundary-Scan devices
that possess the CLAMP function, then this digital guarding activity can be per-
formed without nail access or potentially damaging overdrive.

1.5.6 Exceptions Due to Clocking

For extremely performance-sensitive component inputs, the Standard allows a

designer to use “observe-only” Boundary Register cells. Figure 1.18 shows an exam-
ple. Notice there is no update (UPD) flip-flop or multiplexer in the path from input
pin to System Logic. The logical symbol for this was shown in Fig. 1.12b on page 28.
Such cell designs do not support INTEST or RUNBIST because they cannot
isolate the System Logic from the effects of external signals attached to these pins.
The Standard does allow an exception; if a component pin is a clock then an observe-only

From Shift Out

System
To System
Pin
Circuitry
G
Capture
0 Flip-flop
D Q

ShiftDR 1
CK

Shift In ClockDR MntrOnly

Fig. 1.18 Observe-only boundary register cell for inputs

42 1 Boundary-Scan Basics and Vocabulary

cell may be used and the component may still claim support of INTEST and/or
RUNBIST. This complicates the application of test patterns for INTEST because we
must now coordinate the shifted portions of a test with parallel clocking. In the
previous section on RUNBIST, we saw that clocking of self-tests could be a func-
tion of TCK or system clock pins. Designers might be tempted to categorize other
performance-sensitive pins as “clocks” in order to circumvent the rules, but this will
simply make testing more difficult.

1.6 Extensibility

A powerful feature of the 1149.1 Standard is its extensibility. The architecture can be
extended two ways; by adding user-defined instructions and user-defined registers.
User-defined instructions may be public or private. Public instructions must be prop-
erly documented (see Sect. 2.3.10), but private instructions may be undocumented
except for their instruction bit patterns. This much is required so users will know to
avoid these patterns. User-defined instructions could cause unusual or hazardous con-
ditions to occur so they must be used with care or avoided altogether.
User-defined instructions may target standard registers (such as the Boundary
Register or the Bypass register), portions of standard registers, or concatenations of
registers between TDI and TDO. Alternatively, new user-defined registers may be
targeted.
Consider the Texas Instruments 74BCT824444 [Texa91a]. This IC has a number
of extensions defined by TI. Several of these reference standard registers such as
Boundary or Bypass while others reference a TI-defined Boundary Control Register
(BCR). This 2-bit register can be loaded with control bits that configure the
Boundary Register for special functions that other TI-defined instructions then acti-
vate. For example, the Boundary Register can be configured as a Linear Feedback
Shift Register (LFSR) that can collect a signature of the states seen on the input
pins. Similarly, the outputs can be controlled by the Boundary Register, configured
as a Pseudo-Random Pattern Generator. Both functions can be set up, so that the IC
generates random patterns on its outputs and performs Signature Analysis [Nadi77]
on its inputs. Because octal bus components are often the logical partition points in
a circuit, these functions are attractive; these ICs can be used to perform board-level
Built-In Self-Tests. All of this can be done using the 1149.1 facility as a communi-
cations protocol for accessing a unique test function.
In general, this view of the Standard as a communication protocol for accessing
new functions within an IC is a powerful contribution. Board-level self-tests,
special IC self-tests, hybrid digital/analog tests, emulation support and many other

44
This IC is one of several in a family (called the SCOPE octals) that all implement the same exten-
sions. SCOPE is a trademark of Texas Instruments.
1.8 Costs and Benefits 43

functions can be accessed using the same four-wire port already there for 1149.1
testing. Section 4.9 discusses how the 1149.1 port is being used to define a class of
instructions for programming Field-Programmable ICs.

1.7 Subordination of IEEE 1149.1

The 1149.1 Working Group formally recognized, in 1993 [IEEE93a, IEEE93b], that
other testing technologies might exist within an IC. Notably, internal scan method-
ologies may be used that test all the circuitry within an IC, including the 1149.1 test
circuitry.
For example, a single Integrated Circuit could contain 1149.1 and some other
testability technology such as IBM’s Level Sensitive Scan Design (LSSD) [Will83].
Indeed, the first release of the Standard [IEEE90] contains Appendix A, which
shows just such a scenario. Such an intersection of testability approaches can lead
to a problem; does one standard have superiority over the other when it comes to
interpreting the rules of both? For example, must the control signals for LSSD be
governed by the 1149.1 Boundary Register? Does the TAP controller use LSSD
memory elements in its construction? Careful study of Appendix A of the Standard
will reveal that LSSD exercises superiority over 1149.1. It would be impossible to
maintain LSSD rules without this superiority, but it has the effect that that several of
the LSSD controlling pins are not testable by the 1149.1 facility. Further, if these
pins are not held at certain stable levels, then the 1149.1 facility will not work at all.
The solution to this is to recognize certain pins as “compliance enable” pins. These
pins must be conditioned with stable logic states before and during all 1149.1 activities.
If this condition is not met, then the 1149.1 features cannot be used. Such devices are
considered 1149.1 compliant when the compliance enable conditioning is satisfied.
Compliance enable pins do exist on many devices that have been implemented,
many of which do not include a second testing technology. Unfortunately, this was
not always communicated to users of these devices. Hence they spent a great deal
of time trying to get the 1149.1 features to work reliably but they suffered enormous
difficulties. (Compliance enable pins can now be described in BSDL, see Sect.
2.3.9.) Today, compliance enabling is a recognized condition for some ICs and soft-
ware should be able, when notified, to handle many of the implications. See Sect.
5.2.5 for more discussion.

1.8 Costs and Benefits

On first examination of the structure in Fig. 1.14 (page 30), it certainly looks like the
System Logic is dwarfed by Boundary-Scan circuit overhead. Indeed, early criti-
cism of the Boundary-Scan effort often centered on the apparent impracticality of
the costs. If you look at some actual ICs in existence today that have Boundary-
Scan, you can get a feel for what the overhead penalties are.
44 1 Boundary-Scan Basics and Vocabulary

1.8.1 Costs

First, consider the Texas Instruments 74BCT8244 Octal Buffer with Boundary-
Scan [Texa91a, Texa91b]. This IC represents an extreme in that the System circuitry
is simply eight buffers while the Boundary-Scan logic is several hundreds of gates.
Note several things however. First, the die contains 24 bonding pads (four dedicated
to Boundary-Scan) for the eight buffers. It is a pad-limited design, meaning there is
a lot of unused silicon space and most of the die is made up of bonding pads. Second,
Texas Instruments has added a number of additional capabilities to the Boundary
Register and a number of additional instructions to the TAP. Thus, it is a rich imple-
mentation. Third, most of this circuitry made use of the unused silicon space and
was much less expensive as a result. A significant cost was simply the additional
four pins needed for the TAP signals and the four additional bonding pads on the
die. This is pad overhead.
Another problem with adding 1149.1 to the 74BCT8244 is potential yield loss;
fewer good die are found per silicon wafer. This is a result of placing active circuitry
in formerly “unused” silicon space. Any silicon defects lurking in these spaces can
cause the die to fail.
Next consider a VLSI component, the Motorola 68040. This IC contains a basic
implementation of Boundary-Scan. It has a large number of pins (174) of which 102
are for System Logic, so five (including TRST*) additional TAP pins is a small
percentage. Indeed, on many VLSI components, pins are often dedicated for testing
purposes anyway to support proprietary testing functions. The 68040 is area-limited
rather than pad-limited, meaning they packed as many gates onto the largest size of
die that was commercially feasible. Thus, every gate expended on Boundary-Scan
subtracted from those available for System Logic. In [Gall90], the percentage of
gates in the 68040 used for Boundary-Scan was listed as 0.3%. For dense IC designs
such as CMOS VLSI, the gate overhead45 due to Boundary-Scan will be small.
Consider the problem of inserted delay. Figure 1.7 (page 23) shows a multiplexer
in the system data path between the I/O pin and the System Logic. This will insert
some delay. Now the Standard allows, in selected cases on input pins, for this
multiplexer to be eliminated.46 However, the multiplexer function must be present
on output pins. Again this caused a lot of concern in the early development of
Boundary-Scan, and was often seized upon by reluctant IC designers as a fatal flaw.

45
Another concern is the routing of global signals such as ClockDR, ShiftDR, UpdateDR and Mode
(see Fig. 1.7 on page 22). These signals must be routed to every Boundary Register cell. Note that
once a routing channel has been found for one signal, adding more is considerably easier.
46
The price for eliminating these multiplexers may be the inability to implement the optional INTEST
instruction. However, the value of INTEST to anyone beyond the original manufacturer is debatable
and many original manufacturers use internal scan techniques rather than INTEST anyway.
1.8 Costs and Benefits 45

In reality, merging its function with the output driver can minimize the multiplexer
delay. That is, the multiplexer shown in Fig. 1.7 (page 23) is a logical representation
of the cell design and not necessarily a preferred implementation. It is interesting to
note that when Intel switched to Boundary-Scan design in their microprocessors, the
first product containing Boundary-Scan [Inte91] was their fastest processor of that
time, the 80486DX, not a slower version. Every Intel processor since has contained
1149.1. The current speed record-holder is the Agilent HDMP-2689 Quad SERDES
device. Its I/O pins run at 2.5 GHz47 and yet it contains a complete Boundary-Scan
implementation. IC designers committed to successfully implementing Boundary-
Scan can greatly reduce the inserted delay penalty by clever design.
Another cost of Boundary-Scan is increased design time. This has been aggra-
vated by the lack of tools that support Boundary-Scan designs. This problem is
solved today, as several EDA design tool vendors such as Cadence, LogicVision,
Mentor Graphics and Synopsys, to name four. The ATE community has been offer-
ing test equipment and supporting software for Boundary-Scan since late 1990.
Examples of proprietary design tools were reported as early as 1991 [Chil91]. When
Boundary-Scan reaches maturity, the goal will be for its design and use to be
“untouched by human hands”; that is, fully automated.
Yet another problem is lack of discipline in the overall manufacturing process.
As stated in the very first sentence in this book, software is a key to success with
Boundary-Scan. Software is highly dependent on the quality of data it uses. A manu-
facturer must have the discipline to assure that 1149.1 devices are compliant, that the
attendant BSDL descriptions are accurate representations, and that board netlist data
really reflects the construction of the boards (complete with engineering changes), to
be successful. However, this hasn’t been the case for all of those attempting to use
1149.1. To be fair, some attempts have been sabotaged by the lack of discipline
amongst vendors of ICs and tools, who have sometimes been sloppy with their
degree of compliance with the Standard. This is changing, but you should be wary.48

1.8.2 Benefits

Critics of 1149.1 often cite the various problems listed above. Although most of
these problems seem individually less significant, they worry about their combined
effects. However, these worries may be balanced by a systematic view of the
economics of producing products. Lab prototypes of a new product may promise
incredible performance for a modest price, but the realities of volume production

47
This device is also an example of one that has special initialization requirements. See Sect. 10.11
for a discussion of this topic, which is becoming more important with System-on-Chip technology.
This device is faster (by a decade) than the upper bound on practical Boundary-Scan implementa-
tions that some have claimed to the author.
48
Indeed, if more people are wary, improvements will come faster!
46 1 Boundary-Scan Basics and Vocabulary

G
Relative Product Performance

F
E
6
D
5
3 4
2
1 C
Company X
A B
Company Y

1996 1997 1998 1999 2000 2001

Time

Fig. 1.19 Product introductions by companies X and Y, and their relative performance

may prove disappointing. Without suitable testability, the product may not be
producible. As product complexities and densities increase, so does the risk of
product failure. A maxim in the industry is:
“Don’t be silicon-wise, but system-foolish.”49

There are many benefits that will be credited to Boundary-Scan. These are often
listed as (1) the automation of test development, (2) the reuse of tests, (3) the
standardization of testability access, and so on. These are all admirable, but it is
interesting to see what affect they may have on the electronics industry while taking
their costs into account as well.
For this purpose, consider two hypothetical electronics companies X and Y that
compete with each other. They are using similar technologies, including Surface-
Mount Technology (SMT), Application Specific ICs, and they are increasing com-
ponent densities on boards. They are both examining 1149.1 testability. Company X
decides to wait while company Y decides to develop Boundary-Scan technology.
Both companies introduced their last products (1) and (A) in 1996. See Fig. 1.19 for
a possible scenario.
In this scenario, company X introduces its next product (2), without Boundary-
Scan, promptly in 1997. These are followed regularly every year by products (3)
through (6). Company Y does not get its next product (B) to market until after product
(2), and its performance is a slightly less than product (2) as well. This is because of
the learning curve for Boundary-Scan, the lack of some tools, and some performance
penalties directly ascribed to Boundary-Scan. But, company Y has learned to use

49
I am told that Vishwani Agrawal originated this phrase. It beautifully sums up the fact that plac-
ing some responsibility for the economic success of a product on the design team can solve many
of our testing problems. This usually requires enlightened management support.
1.8 Costs and Benefits 47

Boundary-Scan, found and developed tools, and is ready to take advantage of this on
its new product (C). Product (C) is introduced in record time due to the advantages of
Boundary-Scan. Company Y’s engineers did not have to spend much time preparing
tests, and were able to react swiftly to last minute design changes. Thus they beat
product (3) from company X to market, although it has a little less performance than
product (3) will eventually have. Now, company Y invests the savings in engineering
due to Boundary-Scan two ways; first, they can get products out faster; second, they
can investigate more aggressive technologies. They begin to use very-high density
boards and a few Multi-chip Modules. Meanwhile company X is still trying to get its
products out the same old way, and has little time to try new approaches. Company Y
introduces products (D) through (F) in rapid succession, which exceed both the per-
formance and the schedule of company X.
Does this scenario seem far-fetched? I think not. Other revolutions in the elec-
tronics industry showed similar patterns, like the move to Surface Mount. With
SMT there was a significant learning curve and a need for advanced automatic
placement machinery and new test procedures. At first these slowed down the pro-
cess of bringing out new products. But the overall improvement in manufacturing
processes eventually paid off in better efficiency. Indeed, as time progressed, SMT
became the more cost-effective process and devices were no longer packaged as
both SMT and through-hole. Thus, even manufacturers who perceived no real need
for SMT were forced to use it. As always, there are no guarantees and no substitutes
for the thoughtful application of technology.

1.8.3 Trends

It has been over two decades since the ratification of the first IEEE 1149.1 Standard
[IEEE01]. Some trends are becoming clear.
• There is a growing list of vendors for 1149.1 devices and tools.
Most larger devices today contain 1149.1. As one example, there is a move in the
Field-Programmable marketplace to support 1149.1. This reflects two facts; first,
these devices, without Boundary-Scan, are inherently difficult to test within their
applications. Second, the vendors of these devices have begun standardizing on the
1149.1 protocol (see Sect. 4.9) as the programming port for these devices, thus
giving (in their view) value to the TAP pins. As already noted, there is an increas-
ing amount of support from the Electronic Design Automation community. This
reflects growing demand from designers for 1149.1 support. This will increase
both the quantities of ICs containing 1149.1, and the uniformity of their quality.
• More people have experience with 1149.1.
While it would be foolish of me to claim that all 1149.1 experiences are good,
many manufacturers have begun to utilize Boundary-Scan. The driver for this trend
is lack of probing access that is threatening the viability of highly valued In-Circuit
test technology. Recently, Matsushita Electric Industries Ltd. (MEI) documented
their adoption of Boundary-Scan technology for their products [Milo95]. Their
marketplace is very cost sensitive, high volume, density driven and fiercely com-
petitive, yet they see Boundary-Scan as a way to get ahead in the long term.
48 1 Boundary-Scan Basics and Vocabulary

• The silicon costs of 1149.1 are declining.

This is an inevitable result of two facts; the first is that Boundary-Scan silicon
overhead is roughly proportional to the signal pin count of the devices it is placed
into. Signal pin count, while increasing, is not increasing as fast as silicon density.
The second is that the density of silicon devices is increasing exponentially,
roughly doubling every 18 months or so (known as Moore’s law). These two facts
combine with the result that Boundary-Scan silicon costs are going down in a
roughly linear fashion to the point where they will vanish. Thinking back to 1990,
what was the predominant silicon feature size? It certainly wasn’t 0.13 μ we see
today. Yet at this level, Boundary-Scan technology is quite affordable [Park97].
It can only be getting cheaper with 0.09 μ and 0.06 μ geometries coming.

1.9 Other Testability Standards

IEEE/ANSI Standard 1149.1 is part of an overall effort titled IEEE 1149 Testability
Bus Standards. There are five standardization efforts mapped out under 1149.
Boundary-Scan (1149.1) was the first to complete its mission. The second was IEEE
1149.5, “Standard Module Test and Maintenance (MTM) Bus Protocol” which com-
pleted in 1995. The brand new IEEE 1149.4, is covered later in this book (see Chap. 7).
The P1149.3 (a system test bus) has long been defunct. In 1997 the P1149.2 [IEEE92]
effort decided to end its quest. Recently, in 2000, development started on IEEE
Standard 1149.6 [IEEE03] which released in record time in 2003 (see Chap. 8).
P1149.2 (“Extended Digital Serial Subset”) was similar in many respects to 1149.1.
It was a Boundary-Scan capability in that there was a Boundary Register that could
observe and control component I/O pins. It had a different control design, called a
“stateless” approach. There was no TAP state diagram; to make up for this, more con-
trol pins were needed to control the test facility. Offsetting this price was the ability to
move from one function to another merely by changing the pattern applied to these
pins. One goal of this effort was to supply more direct support for higher testing
speeds and to allow the sharing of certain test logic elements with system logic.
Another goal was for components adhering to both 1149.1 and P1149.2 to be able to
perform tests cooperatively. However this compatibility goal turned out to be a funda-
mental problem. The work done by Lee Whetsel [Whet95] (see Sect. 1.3.5) showed
how clever design might be able to achieve many of these goals within the 1149.1
discipline (though that Working Group still needs to evaluate these ideas). In this light,
the P1149.2 Working Group voted to join with the existing 1149.1 Working Group to
find ways to evolve 1149.1 to address the concerns of the P1149.2 constituency.
The 1149.5 standard is a bus protocol that focuses on high-level systems test-
ability. This standard allows the partitioning of a system into subsystems, modules
or boards. The lower-level items may utilize 1149.1. This gives more organizational
flexibility than 1149.1 has by itself (see Sect. 5.3.1).
Chapter 2
Boundary-Scan Description Language (BSDL)

The chapter of IEEE/ANSI Standard 1149.1 titled “Conformance and Documentation

Requirements,” [IEEE01] gives a list of items a designer of an 1149.1 component
must document. This information must be provided to users of the component so
they may effectively use the Boundary-Scan features. While this list is necessary, it
is not sufficient in the practical sense that in nearly all cases software will be utiliz-
ing this data. Software cannot read specification documents generated by randomly
chosen designers, each with a unique interpretation of the documentation require-
ments, each with a unique style. On top of this, the propensity of humans to over-
look an item or two, or to make mistakes, is high.
For 1149.1 to be really successful, it became apparent that some canonical and
machine-readable description was needed to describe the parameters of an 1149.1 IC
[Park91]. This is even more important because 1149.1 is intended to bridge between
industry segments. Each segment, be it the merchant IC community, the Design
Automation tool providers or the Automatic Test Equipment (ATE) vendors, and so
on, have their own way of describing and using 1149.1 data internally. Each segment
(or worse, each entity within each segment) could develop a proprietary way of
describing Boundary-Scan components. This looked like a Tower of Babel problem
in the making, for sooner or later these entities would need to share this data.
In 1989, a group at Hewlett-Packard that produces board test ATE systems was
busily creating its own proprietary description syntax for 1149.1 ICs. It suddenly
became clear that there was little incentive for IC vendors, Design Automation ven-
dors, and others to adopt this format, particularly if there was an equivalent effort
inside their organizations. Thus, chaos was looming because an ATE system would
be presented with ICs to test from numerous sources. Realizing that cooperation
would be necessary, Hewlett-Packard began a process of creating a standard descrip-
tion language with the aid of a diverse group of companies. White papers were
written, distributed and commented upon. Next, a more refined proposal (still in a
unique syntax) was presented to the IEEE 1149.1 Working Group at its meeting in
March 1990 in Amsterdam. The Working Group recognized the value of a standard

© Springer International Publishing Switzerland 2016 49

K.P. Parker, The Boundary-Scan Handbook, DOI 10.1007/978-3-319-01174-5_2
50 2 Boundary-Scan Description Language (BSDL)

language and encouraged more development, but strongly recommended that the
proposal take on the syntax of an existing language.
Upon looking about for a suitable language, it was clear that no existing lan-
guage was ideal, at least to all observers. However, one language did exist that was
already an IEEE standard, dealt with describing, modeling and synthesizing digital
logic, and was gaining a growing following in the commercial marketplace. This
was the VHSIC Hardware Description Language, VHDL (IEEE Standard 1076)
[IEEE93b]. Thus, VHDL became the foundation language specification for BSDL,
[Park90b] that after significant additional development was formally balloted and
adopted by the IEEE in 1994 [IEEE94] as IEEE Std 1149.1b-1994.
There are problems with VHDL as indeed there are with other existing lan-
guages. First, it is a huge language.1 Second, not everyone is using it. Therefore,
some applications would be implemented within a VHDL environment and some
would be written to stand alone. Thus, BSDL had to be a subset and standard prac-
tice of VHDL. By keeping the subset small, stand-alone software would not be
burdened with supporting a large VHDL parser. By specifying a standard practice
wherever VHDL allows a choice in syntactic style, we both simplify software and
create a canonical form for BSDL. All of this is accomplished without costing the
ability of a VHDL system to utilize BSDL.
Figure 2.1 shows use models for BSDL within and outside of VHDL environ-
ments. A BSDL source can be consumed by a VHDL analyzer, which converts it into
a compiled design library. From here, tools specific to Boundary-Scan can be created
that access the compiled design information. Other tools are free to access this infor-
mation (as well as any other information present) to perform simulation, logic synthe-
sis, or other tasks. In a non-VHDL environment, tools must analyze BSDL directly.
A few more words on the genealogy of BSDL are in order. The first version of
the language [Park90b] quickly became a de-facto standard near the end of 1990. A
side effect of the development of BSDL was a realization that there were some
unanswered questions about the 1149.1 Standard itself. Most of these questions
centered on the construction of the Boundary Register and the definition of “System
Logic”. In response to these questions, the 1993 revision [IEEE93a] called IEEE
Std 1149.1a-1993 concentrated on improving the clarity of the rules for implement-
ing the Boundary Register. This revision completely re-wrote the chapter on
Boundary Register construction and ushered in other improvements. Later in 1994,
BSDL became a formal part of 1149.1 [IEEE94]. In 2001, the Standard was revised
again. Small changes in silicon implementation are reflected in BSDL. These will
be noted in this chapter and also Appendix A.
There are differences between the initial version of BSDL and the official IEEE
version, but these are relatively minor. These will be pointed out in this chapter, but
this chapter will document only the IEEE version. All important software applica-
tions that I am aware of will accept either version of the language, so one does not
have to write BSDL in both versions. When you create BSDL, it should be in the

1
Even within the VHDL world, there are full and partial implementations of the VHDL
language.
2.1 The Scope of BSDL 51

Boundary-
BSDL
Scan
Source
Tools
Outside VHDL
Environment

Inside VHDL
VHDL Analyser Environment
Test
(Lex, Parse, Programs,
Semantics) Etc.

Compiled Boundary-Scan
Design Tools
Library (Semantics, etc.)

Synthesis
Tools
Simulation
Tools
... Other Tools

BSDLUseM

Fig. 2.1 BSDL use model within or outside of a VHDL environment

IEEE version. However, if you have older devices and BSDL files in your inventory,
they should be usable without change.2 IEEE BSDL has an internal mechanism for
documenting its revision level that is covered in Sect. 2.3.3.

2.1 The Scope of BSDL

BSDL allows the description of the testability features in components that comply
with IEEE/ANSI Standard 1149.1. This language can be used by tools that make use
of those testability features. Such tools include testability analyzers, test generators,
and fault diagnosis routines. With a BSDL description of a component and knowl-
edge of the Standard, software tools can completely understand the data transport
characteristics of the component; that is, how the IC captures, shifts, and updates
data. Note that BSDL itself is not a general-purpose hardware description language.
It is not a “model”. BSDL does not provide architectural, structural or detailed
design information about an 1149.1 implementation.

2
The older version of BSDL lacks certain capabilities that may be crucial to your success. For
example, compliance enable pins (see Sect. 2.3.9) cannot be described. If a device has compliance
enable pins, applications using this device will not condition these pins correctly, leading to com-
plex debugging problems. In such cases, you should convert the older BSDL to the new IEEE form.
52 2 Boundary-Scan Description Language (BSDL)

The BSDL description of a compliant component’s parameters has a key

characteristic: its adherence to the rules of the Standard. As a result, those elements
of a design that are absolutely mandated by the standard are not included in BSDL
descriptions. For example, the Bypass Register is not described in BSDL because it
is completely described by the Standard itself, without option. The same is true for
the TAP State Diagram. As another example the content of the Device Identification
Register (upon passing Capture-DR) is described, but not the design detail of how
the register is implemented, because that is completely defined by the Standard. In
essence, stating “1149.1” implies a great deal of information common to any such
component. This eliminates both redundancy and the opportunity for error. BSDL is
intended to specify those parameters necessarily unique to a given Boundary-Scan
implementation.

2.1.1 Testing

BSDL can be used as a test driver. Consider the automatic generation of board tests
as shown in Fig. 2.2. Here, an ATE program generator is provided with a BSDL
description of every unique IC adhering to the Standard. Then, as many such program

BSDL BSDL ... BSDL

File #1 File #2 File N

Board Topology
ATE Program
(Netlist and
Generator
Parts list)

Testability Changes
Report

Test
Program

BSDLATPG

Fig. 2.2 BSDL used as a test driver

2.1 The Scope of BSDL 53

generators do today, it consumes a description of the board topology (consisting of

parts list, interconnections, and so on) and writes a test for the ATE system.
To support Boundary-Scan, this generator notices that some of the components
have BSDL descriptions. From BSDL it can then determine which pins are the TAP
pins. From this it can determine the layout of Boundary-Scan chains. Once this
layout is known, it can determine which board nodes3 are testable using Boundary-
Scan and create the appropriate tests. (Test generation is covered in Chap. 3.)

2.1.2 Compliance Assurance

When one attempts to implement 1149.1 within an IC, one question naturally arises;
“Did I do it right?” Answering this quickly becomes a process for ensuring compli-
ance. One approach for this is shown in Fig. 2.3. In this process, the IC is conceived
and the 1149.1 facility is then added. The full and perfected implementation of the
IC’s System Logic may need much further development, but because the System
I/O assignment, or pinout, of the IC is one of the first items to stabilize, it is often
possible to design the 1149.1 circuitry before the IC design is finalized. When the
1149.1 portion of the IC is designed, a BSDL description may be written.
The process of writing BSDL can uncover errors in the implementation of the
1149.1 circuitry. For example, if System Logic is illegally placed between Boundary
Register cells and the I/O pins, it will not be possible to describe this configuration
within BSDL.
After a BSDL description is written, it may be checked by a program that looks
for specific requirements that must be met for the component to be in compliance.
For example, it might check that the TAP Instruction Register captures a valid pat-
tern at Capture-IR as laid out by the Standard. It may look for more subtle problems,
such as using a Boundary Register cell design that does not support INTEST when
INTEST was listed as one of the instructions the TAP will decode. If an error is
found, then the design must be corrected. If the program approves of the design, then
it may proceed to create an IC test program directly from the BSDL that can then be
used to test the 1149.1 portion of the IC. One important result is that the BSDL will
match the implementation of the 1149.1 circuitry. See Sect. 5.1.10 on page 185 for
more information regarding compliance certification of both 1149.1 and BSDL.
In general, the programmatic verification of compliance is very difficult and a
guarantee is virtually impossible. This is because:
• The Standard offers no formalized rules or procedures for checking compliance.
• The Standard is open; it allows the implementation of user defined extensions of
arbitrary complexity.
• The IEEE does not bestow a seal of approval upon persons or software purport-
ing to judge compliance.

3
The term “node” refers to an interconnection of component pins. Frequently used synonyms for
“node” are “net”, “network”, “signal”, “trace”, “track” and “wire”.
54 2 Boundary-Scan Description Language (BSDL)

Partition System
Circuitry for IC

Idenfify I/O Map

Complete
Design 1149.1 Design of
Circuitry System
Circuitry

BSDL Create BSDL

File Description

Yes
Problems with Fix 1149.1
Description? Circuitry

Yes
No
Compliance
Errors?
Checker

No

Test Fabricate IC
Program

Test IC

CmplVerf

Fig. 2.3 A process for checking the compliance of an IC with the Standard

It is important to note that an IEEE standards effort represents a consensus

among many individuals. In the case of 1149.1 (and many others) this consensus
should be well communicated by the standard document, but supplements and revi-
sions are planned for clarifications. Questions of interpretation are formally col-
lected by the IEEE and sent to the standard working group for ruling, again a
consensus process.
For those who are (rightfully) concerned that they may innocently misinterpret
the Standard and generate a non-compliant design, it is highly recommended that
they take the following course:
• Implement only the most basic 1149.1 functions.
• Describe the 1149.1 function in BSDL.
2.1 The Scope of BSDL 55

• Pass this description through a checker and/or test generator from one or more
independent sources.4
• Physically run any tests created against the real component or simulate them
against a high-quality model.
When success breeds new confidence, you may want to incorporate advanced
features. The next section on synthesis offers hope that much of the risk of a compli-
ance violation can be removed during structured design.

2.1.3 Synthesis

Ideally, standardized testability circuitry can be added to an IC automatically during

its synthesis. The goal would be 1149.1-compliant ICs (and BSDL descriptions)
untouched by human hands. Good news! The development of such systems is hap-
pening. Let us examine one of the first reported synthesis systems [Chil91], which
is diagramed in Fig. 2.4.

Device Concept

Synthesize Model Device

Simulate Operation Model

Synthesize 1149.1,
Add to Device Model,
Designer Review,
Optimize
Modifications

BSDL
Editor
Description

SynthBS

Fig. 2.4 An 1149.1 synthesis system that both creates and uses BSDL

4
One such free service is available at http://bsdl.service.keysight.com/.
56 2 Boundary-Scan Description Language (BSDL)

This synthesis system works in a VHDL environment where IC designers work

to describe and simulate the System Logic of their ICs. Typically, they do not have
deep knowledge of the 1149.1 Standard, but they are required to produce
1149.1-compliant components. When the design of the System Logic is relatively
mature, they invoke a program that automatically adds an 1149.1 TAP and Boundary
Register. These come from pre-designed library information (meaning one designer
did have to know the Standard). This software produces a fairly random organiza-
tion and layout of the 1149.1 circuitry, adds it into the System Logic description
(producing a model for simulation) and creates a BSDL description of the 1149.1
implementation.
Designers are both creative and artistic; therefore, they tend to dislike anything
that modifies their design. At the same time, they may consider learning the Standard
to be an interference with their real job. The interesting feature of this system is that
it recognizes these characteristics of designers and caters to them.
Designers may do two things. First, they simulate the new design that contains
the 1149.1 circuitry to see if it still meets target specifications. After all, the over-
head due to Boundary-Scan could have made a critical change. Second, they may
decide they want to improve upon the random choices made by the insertion pro-
gram. This is done by editing the BSDL (text), not by editing the 1149.1 circuitry
itself. They can then feed the edited BSDL back into the insertion program, which
will use it as guidance for redesigning the Boundary-Scan implementation. Now the
1149.1 circuitry is theirs as well. Typical edits may reorganize the order of the
Boundary Register cells, or group driver enables differently among control cells.
This process can be iterated until the designer is happy with the result. The end
result is:
• The designers did not need intimate knowledge of the 1149.1 Standard.
• BSDL is created automatically, exactly matching the silicon.
• The designer has control over the effects of the 1149.1 circuitry on the design
goals of the IC.
Is the IC compliant? Most likely, but it depends on the skill of the designer who
interpreted the standard when creating the support library and on the faithfulness of
the insertion program. It still would be very wise to use the resulting BSDL and an
independent test generation program to create and execute tests for the
implementation.
A more recent BSDL generator/checker has been documented [Sing97] that
works from a Hardware Description Language (HDL) input such as Verilog or
VHDL. It operates in a succession of phases with just a few clues supplied in the
beginning; the user identifies the TAP signals, the system clocks, and any compli-
ance enable pins and one compliance enable pattern.
• Phase 1 extracts the TAP and verifies the TAP state diagram and timing. It veri-
fies TAP synchronization and whether the TCK signal can be halted per the rules.
2.2 Structure of BSDL 57

It looks for the required pull-ups on TDI, TRST* and TMS. Finally it checks
TDO generation to assure it is properly handled in each TAP state.
• Phase 2 begins the extraction of the shift register portions of the instruction reg-
ister and various data registers. It does this by a series of deductions driven by
loading the instruction register with required opcodes,5 and by seeing what is
selected when in the Test-Logic-Reset state. Then it checks the lengths of these
registers and their capture patterns, and performs extensive checks on the map-
ping of signal pins to the Boundary Register.
• Phase 3 extracts the instruction decode logic and identifies the various target
registers. SAMPLE and PRELOAD are deduced from this exercise and then
checked for adherence to the rules.
• Phase 4 finds more instructions (INTEST, CLAMP, HIGHZ and so on) and their
data register interactions. It checks that the Boundary Register cell behavior is
appropriate for these instructions and labels the cells per the Standard.
• Phase 5 reads an externally supplied pad-to-pin mapping and then writes out the
BSDL for the IC, provided the rules check out.
Now, commercial tools are available from synthesis vendors such as Cadence,
Mentor Graphics and Synopsys. As you can see, we’ve come a long way since 1991.

2.2 Structure of BSDL

IEEE Std 1149.1b-19946 [IEEE94], known as Supplement B, describes BSDL in

minute detail (The Appendices of this book contain a syntax summary of the lan-
guage and its 2013 revision). The supplement can be used by a compiler expert to
create BSDL-driven software, but may be somewhat daunting for the more casual
reader. This chapter will give an overview of BSDL sufficient for the reader to
understand, read and write the language. Please remember that BSDL is a subset
and standard practice of VHDL7 [IEEE93b].
Before jumping in, I’ll try to map some VHDL terms that are probably foreign to
engineers accustomed to “normal” programming languages. In VHDL, an entity
description is similar to a subroutine. It may contain declarations and an execution
part. In BSDL, there is an entity, but it contains only declarations.8 An entity can be

5
For example, it loads the all-one opcode to force a BYPASS instruction. It then looks to see what
register was accessed and checks it for the rules concerning BYPASS. Note the recent relaxation
of the former rule that associated the all-zero opcode with EXTEST adds a new complication here.
6
This supplement to the Standard is now Annex B of the 1149.1.
7
This relationship with VHDL was terminated with the 2013 revision of 1149.1. See Chap. 11 in
Part 2 of this book.
8
This is an important point; BSDL is not an executable language, but rather a description.
58 2 Boundary-Scan Description Language (BSDL)

passed formal parameters, again like a subroutine.9 These are called “generic”
parameters. An entity can incorporate external definitions, like the “include” pro-
cess in other languages, with use statements. These items that are “used” are called
packages and are themselves broken into package and package body elements.
The package contains global data type declarations and the body contains more
declarations, enumerating constant data, as will be described later.
BSDL is structured as a VHDL entity supported by VHDL packages and VHDL
package bodies. All BSDL entities reference a standard package and package body
labeled STD_1149_1_2001.10 The standard package contains definitions of the ele-
ments of BSDL such that a VHDL system will understand how to recognize them.
The standard package also contains logical definitions of Boundary Register cell
designs given by the 1149.1 Standard [IEEE01] and likely to be adopted by design-
ers. Figure 2.5 shows this structure.
The following sections describe the elements of the BSDL language. We will use
a real IC as an example, the Texas Instruments 74BCT8374 [Texa91b] octal flip-
flop register. Here are some notes on the lexical structure of the language.
• The language is case insensitive and free form, with statements that may cover
multiple lines, terminated with semicolons.
• Identifiers are made up of alpha, numeric, and underscore “_” characters, with
the first character being alpha. Adjacent or trailing underscores are not allowed
in identifiers.
• A double dash “--” starts a comment, which continues to the end of the current
line. Comments are ignored when BSDL is processed.
• BSDL uses VHDL string structures to contain some information. These strings
may be broken into manageable pieces by concatenation of smaller strings using
the “&” operator. A single string cannot be split across lines.
Here is an example of how BSDL uses strings. (BSDL examples appear in
Courier New Font, a non-proportional typeface, to help differentiate them.)

"This is an example of a BSDL string that just fits a line."

The following string expression using concatenation takes two lines but it is
otherwise logically identical to the string above. This example also shows
comments between, and following, two concatenated strings. These comments are
logically invisible.

"This is an example of a BSDL string " & -- shorter string

"that just fits a line." -- remaining string

9
Again, BSDL uses a “generic”, but it is used to select among several descriptive options.
10
This is the most recent package. Older BSDLs may refer to STD_1149_1_1994 or the non-IEEE
package STD_1149_1_1990.
2.2 Structure of BSDL 59

entity ttl74bct8374 is

generic (PHYSICAL_PIN_MAP : string :="DW");

port (CLK:in bit; Q:out bit_vector(1 to 8);

D:in bit_vector(1 to 8); GND, VCC:linkage bit;
OC_NEG:in bit; TDO:out bit;
TMS, TDI, TCK:in bit);

use STD_1149_1_1994.all; -- Get Standard Attributes and Definitions

attribute COMPONENT_CONFORMANCE of ttl74bct8374 is

"STD_1149_1_1990";
package STD_1149_1_1994 is
attribute PIN_MAP of ttl74bct8374 : entity is PHYSICAL_PIN_MAP;
-- Give Component Conformance declaration
constant DW:PIN_MAP_STRING:= "CLK:1, Q:(2,3,4,5,7,8,9,10), " &
-- Standard
"D:(23,22,21,20,19,17,16,15), " &Boundary Cells
attribute Component_Conformance : string;
"GND:6, VCC:18, OC_NEG:24," &
"TDO:11, TMS:12, packageTDI:14";
TCK:13, body STD_1149_1_1994 is
-- Give pin mapping declarations

attribute TAP_SCAN_IN -- Generic

of TDI cell is
: signal capturing
true; minimum allowed data
attribute PIN_MAP : string;
attribute TAP_SCAN_MODE of
subtype PIN_MAP_STRING TMS : signal is
is :string;true;
attribute TAP_SCAN_OUT constant
of TDO BC_0
: signal CELL_INFO
is true; :=
attribute TAP_SCAN_CLOCK ((INPUT,
of TCK :EXTEST,
signal is PI), (OUTPUT2,
(20.0e6, BOTH); EXTEST, PI),
-- Give TAP control declarations
(INPUT, SAMPLE, PI), (OUTPUT2, SAMPLE, PI),
attribute INSTRUCTION_LENGTH (INPUT, ttl74bct8374
INTEST, X), (OUTPUT2, INTEST, PI),
type CLOCK_LEVEL is of (LOW, BOTH); : entity is 8;
type CLOCK_INFO. . .is record FREQ : real;
attribute INSTRUCTION_OPCODE of ttl74bct8374 : entity is
. . .
"BYPASS (11111111, 10001000,10000100, 00000001)," &
"EXTEST -- (00000000,
Boundary Cell deferred constants
10000000)," & (see package body)
"SAMPLE (00000010, 10000010)," &
"INTESTconstant BC_0
(00000011, : CELL_INFO;
10000011)," &
constant BC_1 : CELL_INFO;
... constant BC_2 : CELL_INFO;
constant BC_3 : CELL_INFO;
... ...
... ...
...
end STD_1149_1_1994; -- End of IEEE 1149.1-1994 Package
end ttl74bct8374;

BSDLPack

Fig. 2.5 The relationship of a BSDL entity to the standard package and package body

Strings are used to express certain BSDL structures that are often quite long.
Concatenation is used to map these structures into the constraints of common editing
software and can be used to produce a visually appealing format. Having just said that…
Warning! BSDL is intended for distribution from serving organizations to client
organizations. It is common practice today to use the Internet or other electronic
systems for this communication. However, BSDL strings and comments can interact
60 2 Boundary-Scan Description Language (BSDL)

with features of this channel between server and client to produce errors in the
information as received by clients. Here is an example. Say you create a BSDL file
containing the following hypothetical text:

A_String := "A text line longer than an Email system likes";

-- A Comment that exceeds an Email system’s line definition

Here is what your client may receive after using electronic mail service to receive
your BSDL:

A_String := "A text line longer than an Email system

likes";
-- A Comment that exceeds an Email system’s line
definition

Your client then compiles the file and sees errors something like this:

A_String := "A text line longer than an Email system

*** Syntax Error: Missing quote mark
likes";
*** Syntax Error: Unexpected symbol ‘likes’

-- A Comment that exceeds an Email system’s line

definition
*** Syntax Error: Unexpected symbol ‘definition’

This problem is surprisingly common and puts an unnecessary burden on clients.

Further, their impression of “your” BSDL is that it has obvious quality problems and
should not be trusted. The solution is, as a practical measure, to ensure that the lines
you use in a BSDL description are reasonably short, say 55–65 characters. When you
start getting near 70+ characters, you will find some electronic information transfer
systems begin to make formatting decisions on their own that potentially inject
BSDL syntax errors. These errors may be injected at either end of the transfer.

2.3 Entity Descriptions

The entity description begins with an entity statement and terminates with an end
statement like so:

-- BSDL for the Texas Instruments 74bct8374 Octal D Flip-Flop

--
entity ttl74bct8374 is

{BSDL statements to describe the entity}

end ttl74bct8374;
2.3 Entity Descriptions 61

The entity statement names the entity. Typically we place the component name
here. (Notice that this entity identifies the “74bct8374” component, but the entity
name is “ttl74bct8374”, reflecting the VHDL requirement that identifiers must start
with an alphanumeric character.) Other statements within the entity body will refer-
ence this name.
The entity body contains a set of mandatory and some optional statements. The
optional statements are shown between “{ }” brace characters. They must occur in
a specific order. Below is a listing of these statements that will serve as a roadmap.

entity <component name> is

<generic parameter> -- (see Sect. 2.3.1)
<logical port description> -- (see Sect. 2.3.2)
<standard use statement> -- (see Sect. 2.3.3)
{<use statements>} -- (see Sect. 2.3.4)
<component conformance statement> -- (see Sect. 2.3.5)
<device package pin mappings> -- (see Sect. 2.3.6)
{<grouped port identification>} –- (see Sect. 2.3.7)
<scan port identification> -- (see Sect. 2.3.8)
{<compliance enable description>} -- (see Sect. 2.3.9)
<instruction register description> -- (see Sect. 2.3.10)
{<optional register description>} -- (see Sect. 2.3.11)
{<register access description>} -- (see Sect. 2.3.12)
<boundary-scan register description> -- (see Sect. 2.3.13)
{<RUNBIST description>} -- (see Sect. 2.3.14)
{<INTEST description>} -- (see Sect. 2.3.15)
{<BSDL extensions>} -- (see Sect. 2.3.16)
{<design warning>} -- (see Sect. 2.3.17)
end <component name>;

The next few subsections describe these statements.

2.3.1 Generic Parameter

The generic parameter immediately follows the entity statement. It may look like
this:

generic (PHYSICAL_PIN_MAP : string);

or like this, with a default assignment:

generic (PHYSICAL_PIN_MAP : string := "DW");

A generic parameter is a parameter that may be filled by a call from the outside
world, or it may be defaulted. In BSDL, the generic is a string with the name
PHYSICAL_PIN_MAP. It is either passed in from outside (by an application) or it
62 2 Boundary-Scan Description Language (BSDL)

defaults to the string value like “DW” in this example. Any value passed in has
precedence over the default value. The default string is arbitrary. Ultimately, the
value of PHYSICAL_PIN_MAP must be assigned for future reference.
A generic parameter, in BSDL, is used to select an IC packaging option by name.
Because the same IC die may be placed in packages with different configurations
(pinouts), BSDL allows the specification of all package-to-pin mappings within one
BSDL description. The generic allows an external application to select one. If there
is only one package, then by defaulting the generic to its name, one can implicitly
select the option from within. Remember that one package option is “no package”
in the case of bare die. The bare die bonding layout could also be documented and
selected this way and could be used by BSDL-driven applications supporting IC
wafer test.
The string value assigned to PHYSICAL_PIN_MAP should be a meaningful,
descriptive string. For example, if an IC is packaged in an 18 × 18 pin grid array,
then you could use “PGA_18 × 18” as the value, which obeys the requirements of a
VHDL identifier (for the reason see Sect. 2.3.6) and conveys the package type to
observers.

2.3.2 Logical Port Description

The logical port description gives logical names to the I/O pins (system and TAP
pins), and denotes their nature such as input, output, bidirectional, and so on. The
port statement for the example IC is as follows.

port (CLK:in bit;

Q:out bit_vector(1 to 8);
D:in bit_vector(1 to 8);
GND, VCC:linkage bit;
OC_NEG:in bit;
TDO:out bit;
TMS, TDI, TCK:in bit);

In this example we see that CLK is an input (in bit), TDO is an output (out bit),
that there is an eight-bit input bus labeled D (in bit_vector (1 to 8)), and so on. If this
IC had bidirectional pins, they would be of type inout. The bit_vector notation indi-
cates a series of related signals numbered (here) from 1 to 8, inclusive. (Bit_vectors
can use descending orders by replacing “to” with “downto”.) Non-digital signals
such as Power, Ground, no-connects or analog are labeled as linkage. The set of
labels for pins is given in Table 2.1.
Port names must be VHDL identifiers. Later (see Sect. 2.3.6) we will see how
these ports are associated with a device’s pins, which may be numeric identifiers.
VHDL allows more richness in logical port expression, but BSDL limits the syntax
to that shown here as a standard practice.
2.3 Entity Descriptions 63

Table 2.1 Pin types in a BSDL logical port description

Label Meaning
In An input-only pin
Out An output-only pin that could be connected to a bus wire driven by multiple drivers.
The driver of this pin must be a 3-state, or open-collector (etc.) driver compatible
with busing
Buffer A two-state output-only pin where both states are actively driven, that cannot be
attached to a multiple-driver bus
Inout A bidirectional pin
Linkage Other pin types such as power, ground, no-connect or analog

2.3.3 Standard USE Statement

The standard use statement refers to external definitions found in packages and
package bodies, as in our example.

use STD_1149_1_2001.all; -- Get Std 1149.1-2001 definitions

This standard use statement must appear in any BSDL description, and must
appear before any other use statement (see Sect. 2.3.4). It instructs a VHDL ana-
lyzer to look into a VHDL package named STD_1149_1_2001 for definitions of
statements that will subsequently be found in the description. The “.all” suffix
means to use all of the package and is not part of the package name. This package,
with its attendant package body, also contains frequently used Boundary Register
cell definitions as defined by the Standard. (The content of STD_1149_1_2001
appears in Sect. 2.6.1 starting on page 88.)
VHDL, and thus BSDL, is a case-insensitive language. However, practical limi-
tations often arise here with the actual name of the standard package. In a pure
VHDL environment, a package is a set of definitions that reside in the workspace of
the VHDL application. This workspace is isolated from the details of the host com-
puter’s file system. Thus, the fact that the host computer is running under Windows-XP
(which is case-insensitive) versus UNIX11 (which does give significance to case) is
not apparent to the VHDL user. However, many BSDL tools are not written within a
VHDL application. These tools often store package data in the native file system of
the host computer. For this reason, some applications will have case-sensitivity on
the name of the package. Taking care to preserve the casing of package names can
prevent future errors if you port a BSDL between environments.
There is another important implication to the actual name of the standard pack-
age. The name implies the version of the BSDL language being used to describe a
device. As BSDL evolves with subsequent issues of the Standard, it is important
for software to understand which version of the language it may be processing.

11
Windows-XP and UNIX are trademarks of their respective owners.
64 2 Boundary-Scan Description Language (BSDL)

Today’s version may contain new constructs that did not exist in a previous version. In
some cases, a construct may be obsoleted, as has actually happened.12 When coding
BSDL, it is important to use only the syntax defined by current issue of the language.

2.3.4 Use Statements

Use statements are optional and one or more may be added. If a designer were to
invent new cell definitions, these could be placed in a new package, for example,
called “My_New_Cells”, and referenced with a use statement, like so.

use My_New_Cells.all; -- Get new Boundary Register cell info

(See Sect. 2.6.2 on page 92 for details on cell definitions.) User-defined packages
can also be used to define BSDL extensions, covered in Sect. 2.3.16 appearing on
page 79. The package name used in a use statement will have the same sensitivity to
casing just described for the standard use statement in Sect. 2.3.3.

2.3.5 Component Conformance Statement

The component conformance statement13 identifies the release of the Standard that
was used to design the 1149.1 circuitry within an Integrated Circuit. This allows users
(and software) to identify what features may be present in the implementation.

attribute COMPONENT_CONFORMANCE of ttl74bct8374 is

"STD_1149_1_1990";

This statement, written in the 1994 (IEEE) version of BSDL, tells us that the IC was
designed by the rules of the 1990 version of the Standard. Other values this attribute
may have are “STD_1149_1_1993”, “STD_1149_1_2001” and STD_1149_1_2013
reflecting the 1993 Supplement A and the more current issues of the standard.14 Future
releases of BSDL will most likely be coordinated with any future changes or additions
to the Standard itself. However, the component conformance attribute allows us to
know exactly what set of rules were used to design an IC in any case.
Certain features in an 1149.1 design may be “grandfathered”, meaning they
were designed by the rules of a previous issue of the Standard, but are no longer
considered compliant by a later version. By knowing the issue of the Standard that

12
The original version of BSDL (pre-IEEE) had a standard package named STD_1149_1_1990
which defined five attributes that were obsoleted with the acceptance of the IEEE version of the
language. Several new attributes have also been introduced. These are included in this chapter.
13
Component conformance was first defined by the 1993 Supplement to the Standard itself, with
BSDL syntax first appearing in the 1994 Supplement that first defined IEEE BSDL.
14
The alert reader may ask “why not a ‘-1994’ suffix?” This is because the 1994 revision [IEEE94]
made no change to the rules for implementing silicon.
2.3 Entity Descriptions 65

governed the design of an IC, software that checks for compliance can make the
exceptions for these grandfathered features. For example, in the 1990 release of
1149.1, it was allowed (because there was no forbidding rule) to have a control cell
enable two output drivers with complementary values. This of course means that the
two drivers cannot both be enabled or disabled simultaneously.15 In the 1993 release
of the Standard, this type of control structure was expressly forbidden.

2.3.6 Device Package Pin Mappings

As mentioned in the discussion on generic parameters, we can describe the mapping

of package pins to logical names from the port description. Further, BSDL can
describe a multiplicity of mappings. This is done with a VHDL attribute and one or
more VHDL constants. These constants are the first example of BSDL data encoded
within VHDL strings. Notice that because the mappings are long (they rarely fit in
one line) they are broken up into substrings joined by concatenation “&” operators.

attribute PIN_MAP of ttl74bct8374:entity is PHYSICAL_PIN_MAP;

constant DW:PIN_MAP_STRING:=
"CLK:1, Q:(2,3,4,5,7,8,9,10), " &
"D:(23,22,21,20,19,17,16,15), " &
"GND:6, VCC:18, OC_NEG:24," &
"TDO:11, TMS:12, TCK:13, TDI:14";

constant FK:PIN_MAP_STRING:=
"CLK:9, Q:(10,11,12,13,16,17,18,19)," &
"D:(6,5,4,3,2,27,26,25)," &
"GND:14, VCC:28, OC_NEG:7," &
"TDO:20, TMS:21, TCK:23, TDI:24";

This example shows mappings for two IC package types, the DW and FK pack-
ages. For example, signal CLK is pin 1 in the DW package, but pin 9 in the FK
package. The attribute sets up a relationship between the generic string and the
PIN_MAP attribute so that an application will know that the generic value is used
for mapping. See also that bussed signals such as D are associated with a group of
pins (eight in this case) because D was declared in the port definition as being a
bit_vector(1 to 8). In this example, D(1) corresponds to pin 23 of the DW package,
D(2) is pin 22 and so on.
If the package uses a matrix scheme to label pins such as those often used on ball
grid array (BGA) packages, then these may be named H13 or B7 so as to be VHDL
identifiers. They cannot be named 13H or 7B because these are not legal VHDL
identifiers.

15
Fortunately, this “feature” was quite rare. If it had proliferated, it would have seriously compro-
mised the ability of 1149.1 to support interconnection tests.
66 2 Boundary-Scan Description Language (BSDL)

When an application program uses a BSDL description of a component, it passes

in the desired package option via the generic parameter. This in turn selects one of
the package-to-pin mapping constants that sets the association between the logical
port names and the physical pins of the package. Obviously, this mapping will be
crucial to properly understanding how a component interacts with board topologies.
It sometimes happens that an IC is packaged in two very different packages with
different pin counts. The extra pins in the larger package may be no-connects or
simply bonded as extra power/ground pins. In this case, the extra pins are mapped
in the larger pin map and omitted in the smaller. All pins must correspond to ports
in the logical port statement. Note that only linkage ports16 may be handled this
way; all other pins must be accounted for in all pin mappings. It is highly recom-
mended that all linkage pins be documented in BSDL.

2.3.7 Grouped Port Identification

The grouped port identification is optional. It is used to identify system pins17 that
have the special property of using more than one pin to carry a bit of data. Differential
signaling is the most common example, with pairs of pins used to convey each bit
of data. Note that differential signaling may be done with voltage signals, or with
directional current flow.
With differential signaling on a pair of pins, one pin is always the logical complement
of the other (again, in the assigned voltage or current domain). One pin is the “plus” pin
and the other is the “minus” pin. Differential signaling is used to improve noise immu-
nity by its inherent ability to reject common-mode noise. It is also used to improve
system speed and to reduce signal skew, though at the cost of doubling the pin count.
Differential signaling needs special consideration in Boundary-Scan implementa-
tions. In the case where a differential driver or receiver is considered an “analog” port,
we can still test its ability to deliver digital data, albeit on a pair of signal lines. BSDL’s
grouped port identification gives software the mechanism to identify these situations.
The example IC we have been using has no differential signals, so we will use a
hypothetical case for a “Diff_IC” device:

attribute PORT_GROUPING of Diff_IC:entity is

"Differential_Voltage ((Q_Pos(1), Q_Neg(1)), " &
"(Q_Pos(2), Q_Neg(2)), " &
"(Q_Pos(3), Q_Neg(3)), " &
"(Q_Pos(4), Q_Neg(4)))," &

16
The 2013 release of 1149.1 deleted the term “linkage” and added several new port types to give
more information about the nature of non-signal pins. See Chap. 11 in Part 2 of this book.
17
The 1149.1 Standard makes no provision for differential TAP pins.
2.3 Entity Descriptions 67

"Differential_Current ((D_Pos(1), D_Neg(1)), " &

"(D_Pos(2), D_Neg(2)), " &
"(D_Pos(3), D_Neg(3)), " &
"(D_Pos(4), D_Neg(4))) ";

In this example, we are defining the relationship of two 4-bit differential ports
made up of 4 BSDL ports, each with 4 signals. The first pair are Q_Pos and Q_Neg
which are each defined in the port statement as “bit_vector(1 to 4)”. Similarly, ports
D_Pos and D_Neg are both “bit_vector(1 to 4)” as well. Ports Q_Pos and Q_Neg
are voltage differential pins while D_Pos and D_Neg are current differential pins.
The structure above identifies the pairings. For example, pins Q_Pos(1) and Q_
Neg(1) are a voltage differential pair. A BSDL convention is that the first pin men-
tioned in a pair is the “plus” pin and the second is the “minus” pin.18 Similarly, pins
D_Pos(2) and D_Neg(2) are a current differential pair and so on.
Later in the same BSDL description, we will see ports referenced in the Boundary
Register description (described in Sect. 2.3.13 on page 73). Normally all system
signals are required to appear somewhere in the Boundary Register description. An
exception is that the “minus” ports shown in a grouped port description are not
required, indeed they should not appear.19 This reflects the fact that only one
Boundary Register cell is associated with each pair of differential pins. (See Fig.
4.10 on page 169.) Note that if a pair of system pins do have a full set of Boundary
Register resources, then with respect to 1149.1 these pins are not differential and
should not be described as such.

2.3.8 TAP Port Identification

There are four (optionally five) TAP pins. The TAP port identification section
assigns special meaning to these signals. It looks like this.

attribute TAP_SCAN_IN of TDI : signal is true;

attribute TAP_SCAN_MODE of TMS : signal is true;
attribute TAP_SCAN_OUT of TDO : signal is true;
attribute TAP_SCAN_CLOCK of TCK : signal is (20.0e6, BOTH);

If there is an optional TRST* pin, it is identified by the following statement.

attribute TAP_SCAN_RESET of TRST : signal is true;

18
The choice of port names used here helps a reader maintain the “plus” and “minus” relationship,
but is not required by BSDL.
19
The 2013 release of 1149.1 allows an observe-only Boundary register cell to monitor the nega-
tive side of a differential pair. See Part 2 of this book.
68 2 Boundary-Scan Description Language (BSDL)

The statements in this section may appear in any order, but the first four must
always appear in any BSDL description. All of them assign a VHDL attribute to a
signal that must have appeared in the port definition. In the example above, familiar
names such as “TDI” or “TCK” are shown, but these may have been arbitrary
names. For example, binding an attribute like TAP_SCAN_OUT to a signal identi-
fies it as being the Test Data Output (TDO). There is no significance to these attri-
butes being “true”; the Boolean value is a requirement of VHDL syntax. Any signal
bound with a scan port attribute may not appear later in any other BSDL structure.
The signal identified as TAP_SCAN_CLOCK is bound to a VHDL record con-
taining two fields. The first (a real number) is the maximum TCK clocking fre-
quency20 in Hertz and the second is a field with one of two values, BOTH or LOW,
indicating the allowable states the TCK signal may be stopped in. Note that a com-
pliant implementation may not specify HIGH as the only allowable stop state.

2.3.9 Compliance Enable Description

Compliance enable pins were described in Sect. 1.7 on page 42. These pins must be
held at static logic states before any 1149.1 activities are attempted on an IC, and
maintained until the completion of these activities. If such pins exist on an IC, then
an optional compliance enable description must be documented in BSDL.
Annex A of the Standard shows an example of an 1149.1 IC that was designed in
a Level-Sensitive Scan Design (LSSD) environment. The 1149.1 facility is subordi-
nate to LSSD, so this means that the LSSD feature must be controlled to allow the
Boundary-Scan implementation to work. Here we use the example from Annex A
to illustrate the syntax:

attribute COMPLIANCE_PATTERNS of Annex_A_Chip : entity is

"(LSSD_A, LSSD_B, LSSD_P, LSSD_C1, LSSD_C2) (00011)";

Here we see five input signals from the port description, LSSD_A, LSSD_B,
LSSD_P, LSSD_C1 and LSSD_C2 must be held to the static logic states “00011”,
assigned from left to right to the listed signals. When this condition is met, the
1149.1 circuitry will perform as mandated by the Standard. The signals listed in a
compliance enable attribute cannot be scan port signals (see Sect. 2.3.8) nor can
they appear in the subsequent Boundary Register description (see Sect. 2.3.13).

20
The Standard is not very clear on the significance of this maximum TCK frequency. For example,
is it the maximum frequency we can shift bits through any register? How does this parameter relate
to capture and update behavior? What does it tell us about TDI/TDO setup and hold time? In general,
many devices have maximum TCK rates of (say) 20 MHz, but we find that chains of such devices
from multiple vendors should be probably be run somewhat slower, for example, at 10 MHz. Some
devices are particularly sensitive to rise and fall times on TCK itself. One important note, it is not
necessary for a device’s 1149.1 circuitry to perform at the same frequency as the mission circuitry.
2.3 Entity Descriptions 69

In real life we have seen many devices with “compliance enable” pins that are
not subordinating testability pins, but pins used for other purposes. A major exam-
ple is the programming control pins on Field-Programmable devices. The compli-
ance enable attribute is very helpful for alerting software algorithms (and users) that
special handling is needed to make an IC behave. Unfortunately, the compliance
enable feature in BSDL was defined in 1994 by IEEE BSDL and many ICs that
would benefit were already introduced and described in pre-IEEE BSDL. It is
essential to convert these older BSDL files to the IEEE form so that the compliance
enable information can be conveyed.

2.3.10 Instruction Register Description

The next major piece of information required in a BSDL description covers the TAP
instructions that are implemented by the IC’s 1149.1 facility. These include the
mandatory, optional and user-defined (both public and private) instructions and
their associated registers. Hence this description contains five elements; the length
of the instruction register, an enumeration of instructions by name, the instruction
codes (called “opcodes”) associated with instructions, the instruction register cap-
ture pattern and whether any instructions are private. Here is the description for the
example component:

attribute INSTRUCTION_LENGTH of ttl74bct8374 : entity is 8;

attribute INSTRUCTION_OPCODE of ttl74bct8374 : entity is

"BYPASS (11111111, 10001000, 00000101, 00000001)," &
"EXTEST (00000000, 10000000)," &
"SAMPLE (00000010, 10000010)," &
"PRELOAD (00000010, 10000010)," &
"INTEST (00000011, 10000011)," &
"TRIBYP (00000110, 10000110)," & -- Boundary Hi-Z
"SETBYP (00000111, 10000111)," & -- Boundary 1/0
"RUNT (00001001, 10001001)," & -- Boundary run test
"READBN (00001010, 10001010)," & -- Boundary read normal
"READBT (00001011, 10001011)," & -- Boundary read test
"CELLTST(00001100, 10001100)," & -- Boundary selftest
"TOPHIP (00001101, 10001101)," & -- Boundary toggle test
"SCANCN (00001110, 10001110)," & -- BCR Scan normal
"SCANCT (00001111, 10001111)"; -- BCR Scan test
attribute INSTRUCTION_CAPTURE of ttl74bct8374 : entity is
"10000001";
attribute INSTRUCTION_PRIVATE of ttl74bct837421 : entity is
"CELLTST";

21
The 74bct8374 in reality does not have any private instructions. This example is used to illustrate
the syntax.
70 2 Boundary-Scan Description Language (BSDL)

The first attribute (INSTRUCTION_LENGTH) gives the length of the Instruction

Register, which must be two or greater. Next, the instruction mnemonics are identi-
fied and the bit patterns (opcodes) that decode to them are listed in the
INSTRUCTION_OPCODE attribute. There may be more than one opcode listed
for one mnemonic.22 Each opcode must have a length equal to that specified by
INSTRUCTION_LENGTH.
BYPASS must have an all-one decode. Because BSDL does not require docu-
menting what is mandated by the Standard, BYPASS documentation for the all-one
opcode could be left out. The Standard, in its initial release, specified that EXTEST
must have an all-zero opcode but this was relaxed in [IEEE01].23 Because EXTEST,
SAMPLE and PRELOAD24 do not have prescribed opcode bit patterns, they must
be given in a BSDL description. Note in the example above that the 74BCT8374 has
a number of Texas Instruments defined instructions as well as an optional 1149.1
instruction, INTEST.
After the instruction mnemonics and opcodes have been defined, one and option-
ally two attributes are given that provide additional information. First we see the
attribute INSTRUCTION_CAPTURE which specifies a bit pattern captured by the
Instruction Register when passing through the Capture-IR TAP State. The bottom
two bits (as specified by the Standard) must be “01”, but any higher-order bits may
be constants (“0” or “1”) or unknown (“X”).
Next, we see the optional attribute INSTRUCTION_PRIVATE, which is used to
identify any instructions that are private to an implementation. Other users should not
access private instructions that the designer of an IC has implemented. Documenting
them in BSDL allows software to avoid loading those opcode patterns. Failure to
respect private opcodes may result in damage to an IC, circuit board or system.

2.3.11 Optional Register Description

Two more optional attributes may now appear. They identify the content of
the Device Identification Register after passing Capture-DR when the IDCODE
or USERCODE instructions are loaded, if they exist for the component.

22
It may be necessary to use “x” characters to specify don’t care locations in an opcode. When this
is done, software that consumes BSDL must check that ambiguous decodes have not been errone-
ously specified. In this example, the line defining EXTEST could be written “EXTEST (x0000000),”.
23
The reason for not assigning the all-zero opcode to EXTEST is for fail-safety; a stuck-at fault on
TDI could cause the all-zero opcode to load into an instruction register rather than a non-invasive
instruction opcode.
24
In the initial release of 1149.1, SAMPLE and PRELOAD were defined as the same instruction,
or “merged”, and called SAMPLE/PRELOAD. With the current release [IEEE01] these two
instructions have been separated, but still can be merged within an implementation. This is shown
(as above) by both have the same instruction opcode(s).
2.3 Entity Descriptions 71

(The example IC does not have these instructions.) The mnemonics and all associated
opcodes must have been listed in the table of data given in the INSTRUCTION_
OPCODE attribute. The syntax for these attributes looks like this:

attribute IDCODE_REGISTER of My_IC : entity is

"0011" & -- 4-bit version number
"1111000011110000" & -- 16-bit part number
"00000000111" & -- 11-bit manufacturer’s number
"1"; -- mandatory LSB of 1

attribute USERCODE_REGISTER of My_IC : entity is

-- 3A1B00F3 hex programming ID
"0011" & "1010" & "0001" & "1011" &
"0000" & "0000" & "1111" & "0011";

The character “X” may appear in the 32-bit fields indicating don’t care bit posi-
tions. This could be used, for example, to null out some of the manufacturer’s bits if
you were using a component that had multiple sources.
With the advent of IEEE BSDL, it was also allowed to specify multiple IDCODEs
to handle scenarios where a given IC had multiple IDCODE patterns. Some exam-
ples are: second sourcing (otherwise identical ICs have different manufacturers) and
version updates (different versions of an IC have identical 1149.1 logic). This allows
a single BSDL to encode all the information for a family of otherwise identical ICs.
The syntax for this addition uses a comma-separated list of bit patterns like this for
either instruction:

"0011" & "1010" & "0001" & "1011" & -- First code
"0000" & "0000" & "1111" & "1111," &
"0011" & "1000" & "0001" & "1011" & -- Second code
"0000" & "0000" & "1111" & "0011";

2.3.12 Register Access Description

Finally, to wrap up the discussion of instruction description, we have the optional

attribute REGISTER_ACCESS that is used to show how user-defined instructions
interact with data registers. These data registers will be placed between TDI and
TDO when the instructions become effective at Update-IR.

attribute REGISTER_ACCESS of ttl74bct8374 : entity is

"BOUNDARY (READBN, READBT, CELLTST)," &
"BYPASS (TOPHIP, SETBYP, RUNT, TRIBYP)," &
"BCR[2] (SCANCN, SCANCT CAPTURES 0x)";
72 2 Boundary-Scan Description Language (BSDL)

A user-defined instruction may target an existing data register such as the Bypass,
Boundary or Device_ID Registers. It may target a user-defined register.25 In the
example above we see that some instructions such as READBN or SETBYP access
standard registers (Boundary and Bypass) and that others like SCANCN and
SCANCT access a new register called BCR, which is two bits long. It is redundant
to specify standard pairings (for example, Boundary with EXTEST) but if such
pairings are written, they must obey the rules of the Standard. For example, it is an
error to pair the BYPASS instruction with the Device_ID register.
The development of IEEE BSDL brought a new (optional) capability to the
REGISTER_ACCESS attribute; the ability to describe a pattern of static bits26 that
a register captures (when passing the Capture-DR state) for a given instruction.
Looking at the example above, the two-bit BCR register captures a “0x” pattern27
when the SCANCT instruction is active, but no specification is made for SCANCN,
which could have been coded somewhat redundantly as capturing “XX” in this
example. The “captures” modifier allows software to verify that the bits that are
shifted out of a register after passing Capture-DR are indeed those expected for the
implementation in response to a given instruction. Note that the standard register/
instruction pairings (for example, Device_ID with IDCODE) cannot have their cap-
ture patterns documented using the “captures” modifier because they are already
specified by the Standard itself or by other elements of BSDL.
If any previously defined instruction was marked private (see Sect. 2.3.10) by the
INSTRUCTION_PRIVATE attribute, then it does not need to appear in the
REGISTER_ACCESS attribute at the option of the designer. All other user-defined
instructions must appear in this attribute description. This allows software applica-
tions to predict the static capture behavior and data transport characteristics of the
IC for any public instruction.

2.3.13 Boundary-Scan Register Description

The description of the Boundary Register contains a large block of data. It gives a
description of every cell in the register.
Two attributes make up this description. The first is the attribute BOUNDARY_
LENGTH. The length attribute simply states the length of the register, an integer
greater than zero.

25
The Standard states that designers may add new data registers, or they may access existing reg-
isters, in whole or in part. Further, they may take a collection of registers (whole or in part) and
concatenate them. If an existing register is subsetted or concatenated in any way, the Standard
requires that it be given a new name and treated as a unique new register.
26
This feature only describes constant (static) bits. Bits that may differ in successive passages
through the Capture-DR state are either marked as “x” bits, or the capture description may be omit-
ted altogether.
27
Using the established BSDL convention, the capture pattern has its rightmost bit closest to TDO
and the leftmost bit closest to TDI.
2.3 Entity Descriptions 73

The second attribute, BOUNDARY_REGISTER, is an array of data records.

Each record has a cell number field28 followed by a cell description structure within
parentheses. The description structure contains either four or seven fields. The first
four are always the same. The remaining three fields, when present, give informa-
tion for cells devoted to IC outputs regarding how those outputs are disabled. This
is how these attributes look for the example component.
The 2013 release of 1149.1 (see Chap. 11 in Part 2 of this book) adds the concept
of variable-length Boundary registers that are assembled from “register segments”.
What is being described here is essentially the structure and description of a single
segment.

attribute BOUNDARY_LENGTH of ttl74bct8374 : entity is 18;

attribute BOUNDARY_REGISTER of ttl74bct8374 : entity is

-- num cell port function safe [ccell disval rslt]
"17 (BC_1, CLK, input, X)," &
"16 (BC_1, OC_NEG, input, X)," & -- Merged In/Cntrl
"16 (BC_1, *, control, 0)," & -- See Sect. 2.4
"15 (BC_1, D(1), input, X)," &
"14 (BC_1, D(2), input, X)," &
"13 (BC_1, D(3), input, X)," &
"12 (BC_1, D(4), input, X)," &
"11 (BC_1, D(5), input, X)," &
"10 (BC_1, D(6), input, X)," &
"9 (BC_1, D(7), input, X)," &
"8 (BC_1, D(8), input, X)," &
"7 (BC_1, Q(1), output3, X, 16, 0, Z)," &
"6 (BC_1, Q(2), output3, X, 16, 0, Z)," &
"5 (BC_1, Q(3), output3, X, 16, 0, Z)," &
"4 (BC_1, Q(4), output3, X, 16, 0, Z)," &
"3 (BC_1, Q(5), output3, X, 16, 0, Z)," &
"2 (BC_1, Q(6), output3, X, 16, 0, Z)," &
"1 (BC_1, Q(7), output3, X, 16, 0, Z)," &
"0 (BC_1, Q(8), output3, X, 16, 0, Z)";

The fields in Boundary Register description structure are defined in the follow-
ing paragraphs.
Field 1: This is the cell identification field where the specific cell design is listed.
The definition of this cell design must be provided in a package called out in a “use”
statement. (See Sects. 2.3.3 and 2.3.4 beginning on page 64.) In this example, cell
design BC_1 is referenced from the standard package STD_1149_1_2001.

28
Note the cell number field “tags” the cell description. Thus the cell descriptions can be listed in
any order. In this book the order will typically be ascending or descending. As always, cell 0 is
closest to TDO. All cells must be described, i. e., all numbers between 0 and N-1 must appear.
74 2 Boundary-Scan Description Language (BSDL)

Table 2.2 Function symbols and their meanings

Function
field symbol Meaning
Input Control-and-Observe cell (or an Observe_only cell not supporting INTEST)
serving an input pin as shown in Fig. 1.7 (page 23)
Clock Observe_only cell at a system clock input as shown in Fig. 1.18 (page 41).
This cell supports INTEST
Output2 A cell at a 2-state (either symmetric or asymmetric) output pin as shown in
Fig. 1.7 (page 23)
Output3 A cell at a 3-state output. (May be used in composite bidirectional structures
such as shown in Fig. 1.8 on page 24)
Control A cell that controls a 3-state enable as shown in Fig. 1.8 (page 24)
Controlr A control cell that is forced (reset) to its disabling value when the TAP enters
the Test-Logic-Reset state. See Fig. 1.8 (page 24) where a reset signal is used
to clear the Update flip-flop
Internal A placeholder cell not associated with any pin. It may capture undefined data
(“x”), static “0” or “1” data, or its own present value
Bidir A single cell that can both observe a pin and supply data for its output driver.
(See the lower half of Fig. 1.9 on page 26.) It is connected only to ports of
type Inout (see Sect. 2.3.2)
Observe_Only A solitary observe-only cell on an input, or an additional cell observing any
device system pin. (This cell by itself cannot support INTEST.)

Field 2: This is the port field where a signal from the port statement29 that is
attached to this cell is identified. In some cases a cell has no attached signal; then an
asterisk (“*”) appears in this field.
Field 3: This is the function field where the cell function is identified from an
enumeration. This enumeration consists of the symbols input, clock, output2, out-
put3, internal, control, controlr, bidir and observe_only. See Table 2.2 for details on
the meanings of these symbols.
Field 4: This is the safe field. It contains a single character “0”, “1” or “x”. This
field specifies what an Update (UPD) flip-flop should be loaded with when software
might otherwise choose a value at random. This value has the least precedence with
respect to any other choice so it cannot be used to influence a test generation algo-
rithm. An “x” indicates that it doesn’t matter what value is loaded. In the example
shown above, a “0” was specified in the safe field for the control cell (cell 16) so that
its associated drivers would be disabled when the safe value is loaded.
This ends the first four fields required of every cell description record. Some
records will have the next three fields as well.

29
If the port uses a “bit_vector” to denote a group of signals, then a subscripted port name must be
used here. In the example, see that the D and Q ports are shown in Boundary_Register attribute as
subscripted signals, like D(3) or Q(5).
2.3 Entity Descriptions 75

Table 2.3 Definition of disable result field symbols

Result
field symbol Meaning
Z The driver enters a high-impedance state and does not supply current to its pin.
This is not a logic state
Pull0 The (asymmetrical) driver does not supply current to its pin, but an internal
pull-down function supplies a weak logical “0” state
Pull1 The (asymmetrical) driver does not supply current to its pin, but an internal
pull-up function supplies a weak logical “1” state
Weak0 The (asymmetrical) driver does not supply current to its pin. An externally
connected pull-down function must supply a weak logical “0” state
Weak1 The (asymmetrical) driver does not supply current to its pin. An externally
connected pull-up function must supply a weak logical “1” state
Keeper The driver enters a high impedance state. The last strongly driven state supplied
by the driver is “kept” by a weak feedback buffer. This is not a logic state

Field 5: This is the control cell (ccell) field. It contains an integer that is the cell
number of the control cell associated with an output or bidirectional pin. This cell
can be used to disable the driver attached to the output or bidirectional signal.
(In the case of asymmetrical output drivers such as an open-collector driver, this
field must contain its own cell number, indicating the cell controls itself.
See Sect. 2.4 on page 80 for an example.)
Field 6: This is the disable value (disval) field that contains either a 0 or a 1. This value
is what must be loaded into the associated control cell (of field 5) to disable the driver.
Field 7: This is a disable result field (rslt) that indicates what happens when the
driver is disabled. It may contain one of an enumeration of six symbols; Z, Pull0,
Pull1, Weak0 Weak1 or Keeper. These values correspond to a 3-state disable or to
asymmetrical drivers (such as TTL Open Collector or ECL Open Emitter) when
disabled. See Table 2.3.
All (non-linkage) IC pins must appear in the port field of cell(s) in the Boundary
Register description with three exceptions that should never appear;
• TAP control signals such as TCK, TDO, etc. (See Sect. 2.3.8).
• Compliance enable pins (see Sect. 2.3.9).
• Negative (or “Minus”) representatives of grouped port pins.30 (See Sect. 2.3.7.)
Many other rules about the construction of the Boundary Register description are
given in the Standard. Some are obvious, such as the numbers assigned to cells must
fall in the range of 0 to BOUNDARY_LENGTH-1, and all numbers in this range
must be assigned to a cell. Some deal with the special requirements of the INTEST
instruction. For “generic” implementations of 1149.1, these rules are mainly com-
mon sense. For more intricate designs, you should take BSDL guidance directly
from the latest revision of the Standard.

30
The 2013 release of 1149.1 does allow observe-only cells that monitor negative legs of differen-
tial pairs, as well as other pins that were formerly not monitored. See Part 2 of this book.
76 2 Boundary-Scan Description Language (BSDL)

2.3.14 RUNBIST Execution Description

The (optional) RUNBIST instruction has a myriad of implementation possibilities,

particularly with respect to clocking options. BSDL allows the description of the basic,
logical nature of RUNBIST in an IC. Details, such as multiple clock phasing, may
have to be adjusted after a RUNBIST test is generated from a BSDL description.
The RUNBIST_EXECUTION attribute is optional, even if RUNBIST function-
ality is implemented in an IC. It contains three pieces of information as shown in
this example:

attribute RUNBIST_EXECUTION of BIST_IC : entity is

"Wait_Duration (1.0e-4)," -- Duration of test
"Observing HIGHZ At_Pins," -- Condition of Output pins
"Expect_Data 0011001"; -- Result of passing test

The first piece of information is the duration of test clause. A RUNBIST instruc-
tion must run for some length of time in the Run-Test/Idle state, governed by the
passage of time, or some number of clock cycles, or both. The duration in this exam-
ple was 100 μs, but there are other options. For example, maybe the IC needs to be
clocked by the TCK port 1000 times. Then the duration would have been “(TCK
1000)” rather than “(1.0e-4)”. A more complicated device might require both the
system clock and TCK to be running, and for a minimum time to elapse as well. In
this case the duration might look like this: “(2.8e-2, TCK 1000, SCLOCK 12000)”.
The observing clause tells us how the output and bidirectional pins behave while
RUNBIST is in effect. All of these pins do one of two things; they go into a HIGHZ
(high impedance) state,31 or they take on states defined by the Boundary Register,
which should be initialized by a PRELOAD operation before RUNBIST is exe-
cuted. These two options are selected by “HIGHZ” and “Boundary” keywords.
The expect clause documents what test result will be found in the target register
of RUNBIST, listed in the REGISTER_ACCESS attribute appearing earlier in the
BSDL description (see Sect. 2.3.12). A pattern of bits is given here that must match
the length of the target register. All of these bits must be deterministic “0” or “1”
bits. For a passing test, these bits will be read out from the target register after the
duration requirements for the test have been met.

2.3.15 INTEST Execution Description

The (optional) INTEST instruction has a myriad of implementation possibilities, par-

ticularly with respect to clocking options. BSDL allows the description of the basic,
logical nature of INTEST in an IC. Details, such as multiple clock phasing, may have
to be adjusted after an INTEST sequence is derived from a BSDL description.

31
All pins, including those whose system nature is to be 2-state pins.
2.3 Entity Descriptions 77

The INTEST_EXECUTION attribute is optional, even if INTEST functionality

is implemented in an IC. It contains two pieces of information as shown in this
example:

attribute INTEST_EXECUTION of INTEST_IC : entity is

"Wait_Duration (1.0e-4)," -- Duration of test
"Observing HIGHZ At_Pins"; -- Condition of Output pins

These two pieces of information are identical to those used by the description of
RUNBIST execution (see Sect. 2.3.14).
The actual patterns that one would apply via INTEST must come from an exter-
nal source such as the design verification tests for an IC. BSDL does not provide a
means of describing these patterns. The INTEST_EXECUTION attribute docu-
ments the details on how such patterns should be applied.

2.3.16 User Extensions to BSDL

Some people have expressed the desire to “extend” BSDL to support new syntax for
some options and capabilities important to them. These applications might not be
relevant to anyone else. BSDL Extensions allow a standardized mechanism for
users to define their own extensions to the BSDL language that will not upset other
applications that are otherwise unaware of their format and content.
BSDL Extensions are named. These names must be declared before they can be
defined. Here is an example for a fictional IC named “My_IC”:

attribute My_First_Extension : BSDL_Extension; -- Declaration

attribute My_First_Extension of My_IC : entity is

"A string that provides " & -- Definition of extension
"data for my personal, " &
"proprietary application " &
"in my own personal format.";

You can define multiple extensions, with the declaration for each appearing
before it is defined. It is also possible to include the definitions of extensions in User-
defined packages (see Sect. 2.6.6 on page 108) which may be useful if you intend to
use one or more extensions in multiple BSDL descriptions. When this is done, you
only need to define the value of the desired extensions in a given BSDL file.
Once you have decided on a BSDL extension and its format, you can add pro-
cessing capability to your tools that will recognize the attribute by name. Foreign
tools will see the attribute too, but will recognize it as an extension and ignore it.
78 2 Boundary-Scan Description Language (BSDL)

2.3.17 Design Warnings

It is possible that the IC designer will want to communicate information to users of

the IC about dangerous or illegal conditions to be avoided. This may be conveyed
with an optional attribute DESIGN_WARNING. This is a textual attribute with no
format; it simply contains a message from the designer. It must appear just before
the end of the entity. It looks like this.

attribute DESIGN_WARNING of My_IC : entity is

"The private instruction USER_BIST must be used " &
"carefully! It requires a seed register to be " &
"initialized (See LOAD_SEED), and the output drivers " &
"should be disabled during operation.";

It is intended for application software to pass this warning text on to the user of
the software as appropriate. The attribute is useful for capturing and transmitting the
intent of a function from the designer to a user.

2.4 Some Advanced BSDL Topics

Certain structures in ICs need special treatment when 1149.1 is added to an IC, and
these are reflected in BSDL as special cases. The reader may have already detected
“cell merging” in the foregoing example of the 74bct8374. The treatment of asym-
metrical drivers and bidirectionality can also require special action.

2.4.1 Merged Cells

In the description of the 74BCT8374 (see the example BSDL fragment on page 75)
you may have noticed that the BOUNDARY_REGISTER array had two entries for
cell 16. The first showed the cell to be associated with an input pin; the second
showed the cell to be a control cell for disabling drivers. This is an example of a cell
with merged behavior.
Figure 2.6 shows a Boundary Register design that contains a candidate case for
cell merging. Here, an input pin is attached to an input cell. The output of this cell
travels directly to a control cell for an output driver. There is no System Logic in the
path, unless one were to count the wire as “logic”. Because there are two flip-flops
(CAP) and (UPD) in a cell, one can capture and shift data while the other holds the
output to a fixed value. Thus, we could merge two cells into one and still obey the
rules of the standard.
2.4 Some Advanced BSDL Topics 79

C U System CU

Circuitry Device
Device
Inputs Output

C U CU

MergCand

Fig. 2.6 Candidate for merged cell design

C U System CU

Circuitry Device
Device
Inputs Output

CU
Cell with Merged
Input/Control
Behavior Merger

Fig. 2.7 Design with input and control cells merged

Figure 2.7 shows the same Boundary Register design of Figure 2.6 after cell
merging has combined two cells into one. Cell merging is reflected in BSDL as a
doubled cell entry in the attribute BOUNDARY_REGISTER as we have seen in the
example.
Cell merging has two benefits: it cuts down on the cell count in the Boundary
Register, which reduces gate overhead due to Boundary-Scan; and, cell merging
also reduces inserted delay. Cell merging can only be done where the System Logic
between two cells is a wire.32
There are other instances where merged cells can be found. Figure 2.8 shows
several examples where cell merging has been done between input/control cells and
between input/output cells. The BSDL fragment below gives the Boundary Register
description for this design.

32
In Sect. 1.3.4 starting on page 21 we saw cases where System Logic consisting of an inverter can
be subsumed into a Boundary Register cell. Having done this, if the logic left is a wire, then cell
merging can again be done.
80 2 Boundary-Scan Description Language (BSDL)

BIDIR2 CU BIDIR3
6
5
UC

4
CU
7
CU
3
CU

2
BIDIR
8 CU
1
IN2 CU +5
1
System CU OUT2
Circuitry
0
CU
9
IN1 CU OUT1

TDI TAP CONTROLLER TDO

TCK
TMS MergCell

Fig. 2.8 A design illustrating several merged cell situations

attribute BOUNDARY_LENGTH of My_IC : entity is 10;

attribute BOUNDARY_REGISTER of My_IC : entity is

-- num cell port function safe [ccell disval rslt]
"0 (BC_1, *, control, 0)," &
"1 (BC_1, OUT2, output2, 1, 1, 1, Weak1),"&
"2 (BC_6, BIDIR1, bidir, X, 3, 0, Z)," &
2.4 Some Advanced BSDL Topics 81

"3 (BC_2, *, control, 0)," &

"4 (BC_1, *, control, 0)," &
"5 (BC_1, BIDIR3, input, X)," &
"5 (BC_1, BIDIR2, output3, X, 7, 1, Z)," &
"6 (BC_1, BIDIR2, input, X)," &
"6 (BC_1, BIDIR3, output3, X, 4, 0, Z)," &
"7 (BC_1, *, control, 1)," &
"8 (BC_1, IN2, input, X)," &
"9 (BC_1, IN1, input, X)," &
"9 (BC_1, OUT1, output3, X, 0, 0, Z)";

Cell 0 is simply a control cell between the system logic and the enable for signal
OUT1. (Cells 4 and 7 are similar to cell 0.) Notice that the safe bits are assigned to
cause the associated drivers to disable. Cell 3 is the control for the bidirectional cell
(see Fig. 1.9 on page 26) used on the bidirectional signal BIDIR1.
Cell 1 is discussed in the next Sect. 2.4.2.
Cell 2 is the bidirectional data cell in the lower half of Fig. 1.9 on page 26. This
cell always monitors the state of BIDIR1 regardless of whether its driver is enabled.
Cell 5 (and similarly with cells 6 and 9) has merged behavior: it serves as the
input receiver for BIDIR3, and as the data source for BIDIR2. As a result, the cell
has two lines of description in the Boundary Register definition. The first gives its
behavior as an input cell while the second describes its characteristics as an output
cell. Note that cell BC_1 used in this capacity must support both input and output3
functions. This is reflected in the definition of BC_1 (see Sect. 2.6.1) where both
functions exist for all instructions.
Cell 8 is a simple input cell using cell BC_1, but it could be an Observe_Only
cell if we do not wish to support INTEST in this implementation.
The example illustrated by Fig. 2.8 is deliberately extreme and dwells on odd
cases. Most component implementations will be quite simple by comparison.

2.4.2 Asymmetrical Drivers

Returning to Fig. 2.8 for a moment, notice that cell 1 is a 2-state output data cell. It
has the three extra fields needed to describe an output driver that can be disabled;
so, the cell is marked “Output2” and the output can be disabled. This indicates the
driver is asymmetrical because one state is actively driven and the other must be an
inactive drive state. (The external pull-up resistor is another clue.) This design does
not have a separate cell to enable the 2-state driver. BSDL codes this configuration
as a cell that controls its own open-collector, asymmetrical driver. Placing a "1" in
cell 1 will disable OUT2 by putting it into the "Weak1" state.
82 2 Boundary-Scan Description Language (BSDL)

2.5 BSDL Description of 74BCT8374

All BSDL descriptions are similar; some will be longer than others will of course,
but the data content and organization are the same. This is true regardless of the
nature of the System Logic function. For example, the BSDL descriptions of a sim-
ple octal transceiver will be quite similar to that of a large 32-bit microprocessor.
The example BSDL description for Texas Instruments 74BCT8374 shown in
Fig. 2.9 looks like this in its entirety.

74BCT8374 (DW Package)

8 0
15 10
D8 CU D Q CU Q8
9 1
16 9
D7 CU D Q CU Q7
10 2
17 8
D6 CU D Q CU Q6
11 3
19 7
D5 CU D Q CU Q5
12 4
20 5
D4 CU D Q CU Q4
13 5
21 4
D3 CU D Q CU Q3
14 6
22 3
D2 CU D Q CU Q2
15 7
23 2
D1 CU D Q CU Q1
16
OC 24 CU

17
CLK 1 CU

BCR Register

Bypass Register

Instruction Register

14 TAP Controller 11
TDI TDO

13
TCK
12
TMS 748374

Fig. 2.9 Texas Instruments 74BCT8374 Octal D Flip-Flop with Boundary-Scan

2.5 BSDL Description of 74BCT8374 83

-- BSDL for Texas Instruments 74bct8374 Octal D Flip-Flop

--
entity ttl74bct8374 is
generic (PHYSICAL_PIN_MAP : string := "DW");

port (CLK:in bit; Q:out bit_vector(1 to 8);

D:in bit_vector(1 to 8);
GND, VCC:linkage bit; OC_NEG:in bit;
TDO:out bit; TMS, TDI, TCK:in bit);

use STD_1149_1_2001.all; -- Get Std 1149.1-2001 defs

attribute COMPONENT_CONFORMANCE of ttlbct8374 : entity is

"STD_1149_1_1990"; -- This is an older IC

attribute PIN_MAP of ttl74bct8374 : entity is

PHYSICAL_PIN_MAP;

constant DW:PIN_MAP_STRING:=
"CLK:1, Q:(2,3,4,5,7,8,9,10), " &
"D:(23,22,21,20,19,17,16,15)," &
"GND:6, VCC:18, OC_NEG:24, TDO:11, " &
"TMS:12, TCK:13, TDI:14";
constant FK:PIN_MAP_STRING:=
"CLK:9, Q:(10,11,12,13,16,17,18,19)," &
"D:(6,5,4,3,2,27,26,25)," &
"GND:14, VCC:28, OC_NEG:7, TDO:20, " &
"TMS:21, TCK:23, TDI:24";

-- This is where grouped port identification would appear

attribute TAP_SCAN_IN of TDI : signal is true;

attribute TAP_SCAN_MODE of TMS : signal is true;
attribute TAP_SCAN_OUT of TDO : signal is true;
attribute TAP_SCAN_CLOCK of TCK : signal is (20.0e6, BOTH);

-- This is where compliance enable description would appear

attribute INSTRUCTION_LENGTH of ttl74bct8374 : entity is 8;

attribute INSTRUCTION_OPCODE of ttl74bct8374 : entity is

"BYPASS (11111111, 10001000, 10000100, 00000001)," &
"EXTEST (00000000, 10000000)," &
"PRELOAD (00000010, 10000010)," & -- Note PRELOAD and
"SAMPLE (00000010, 10000010)," & -- SAMPLE are merged
"INTEST (00000011, 10000011)," &
"HIGHZ (00000110, 10000110)," & -- Boundary Hi-Z
"CLAMP (00000111, 10000111)," & -- Boundary 1/0/Z
"RUNT (00001001, 10001001)," & -- Boundary run test
"READBN (00001010, 10001010)," & -- Boundary read
84 2 Boundary-Scan Description Language (BSDL)

"READBT (00001011, 10001011)," & -- Boundary read test

"CELLTST(00001100, 10001100)," & -- Boundary self test
"TOPHIP (00001101, 10001101)," & -- Boundary toggle out
"SCANCN (00001110, 10001110)," & -- BCR Scan normal
"SCANCT (00001111, 10001111)"; -- BCR Scan test

attribute INSTRUCTION_CAPTURE of ttl74bct8374 : entity is

"10000001";

-- This is where INSTRUCTION_PRIVATE would appear.

-- This is where IDCODE_REGISTER would appear.
-- This is where USERCODE_REGISTER would appear.

attribute REGISTER_ACCESS of ttl74bct8374 : entity is

"BOUNDARY (READBN, READBT, CELLTST)," &
"BYPASS (TOPHIP, SETBYP, RUNT, TRIBYP)," &
"BCR[2] (SCANCN, SCANCT)"; -- 2-bit Boundary Control Reg

attribute BOUNDARY_LENGTH of ttl74bct8374 : entity is 18;

attribute BOUNDARY_REGISTER of ttl74bct8374 : entity is

-- num cell port function safe [ccell disval rslt]
"17 (BC_1, CLK, input, X)," &
"16 (BC_1, OC_NEG, input, X)," & -- Merged In/Cntrl
"16 (BC_1, *, control, 0)," & -- Merged In/Cntrl
"15 (BC_1, D(1), input, X)," &
"14 (BC_1, D(2), input, X)," &
"13 (BC_1, D(3), input, X)," &
"12 (BC_1, D(4), input, X)," &
"11 (BC_1, D(5), input, X)," &
"10 (BC_1, D(6), input, X)," &
"9 (BC_1, D(7), input, X)," &
"8 (BC_1, D(8), input, X)," &
"7 (BC_1, Q(1), output3, X, 16, 0, Z)," &
"6 (BC_1, Q(2), output3, X, 16, 0, Z)," &
"5 (BC_1, Q(3), output3, X, 16, 0, Z)," &
"4 (BC_1, Q(4), output3, X, 16, 0, Z)," &
"3 (BC_1, Q(5), output3, X, 16, 0, Z)," &
"2 (BC_1, Q(6), output3, X, 16, 0, Z)," &
"1 (BC_1, Q(7), output3, X, 16, 0, Z)," &
"0 (BC_1, Q(8), output3, X, 16, 0, Z)";

-- This is where BSDL_EXTENSIONs would appear.

-- This is where DESIGN_WARNING would appear.

end ttl74bct8374;
2.6 Packages and Package Bodies 85

2.6 Packages and Package Bodies

Packages and package bodies are VHDL files containing supporting information
that is imported into an entity definition. It is analogous to the concept of inclusion
or importation found in other languages. In BSDL, the main information about an
IC is conveyed in an entity description described in Sect. 2.3. There, the statement
“use STD_1149_1_2001.all” (Sect. 2.3.3) is used to set up the definition of the
BSDL environment. User-defined packages may then be included with additional
“use” statements to allow BSDL to mirror the extensibility of the 1149.1 Standard.
A VHDL package can contain definitions of data structures and may also contain
pre-defined constants constructed from those definitions. If a definition is ever
changed then anything that ever references that package would have to be re-
compiled (re-analyzed in VHDL parlance).
A package body, associated with a package, can be used to contain pre-defined
constants. The advantage of this is that if the definition of a constant’s contents is
changed, everything that references the associated package does not have to be re-
analyzed. This is how packages and package bodies are used for BSDL.
The basic definition of the BSDL environment (the data structures) is given in a
standard BSDL package called STD_1149_1_2001, which has an associated package
body that contains (to date) eleven constant definitions representing 1149.1 Boundary
Register cell designs. This information is considered the foundation definition of
BSDL and should only change when BSDL itself is revised. This package would
typically be write-protected on a BSDL based system to prevent modification.

2.6.1 STD_1149_1_2001

The information contained in STD_1149_1_2001 is documented next. This includes

both the package and package body. Following this is a set of figures and discussion
about the cell definitions given in the package, in Sect. 2.6.3.

package STD_1149_1_2001 is
-- Give component conformance declaration
attribute COMPONENT_CONFORMANCE : string;
-- Give pin mapping declarations
attribute PIN_MAP : string;
subtype PIN_MAP_STRING is string;
-- Give TAP control declarations
type CLOCK_LEVEL is (LOW, BOTH);
type CLOCK_INFO is record
FREQ : real;
LEVEL: CLOCK_LEVEL;
end record;
86 2 Boundary-Scan Description Language (BSDL)

attribute TAP_SCAN_IN : boolean;

attribute TAP_SCAN_OUT : boolean;
attribute TAP_SCAN_CLOCK: CLOCK_INFO;
attribute TAP_SCAN_MODE : boolean;
attribute TAP_SCAN_RESET: boolean;
-- Give instruction register declarations
attribute INSTRUCTION_LENGTH : integer;
attribute INSTRUCTION_OPCODE : string;
attribute INSTRUCTION_CAPTURE : string;
attribute INSTRUCTION_PRIVATE : string;
-- Give ID and USER code declarations
type ID_BITS is ('0’, '1', 'x', 'X');
type ID_STRING is array (31 downto 0) of ID_BITS;
attribute IDCODE_REGISTER : ID_STRING;
attribute USERCODE_REGISTER: ID_STRING;
-- Give register declarations
attribute REGISTER_ACCESS : string;
-- Give boundary cell declarations
type BSCAN_INST is (EXTEST, SAMPLE, INTEST);
type CELL_TYPE is (INPUT, INTERNAL, CLOCK, OBSERVE_ONLY,
CONTROL, CONTROLR, OUTPUT2,
OUTPUT3, BIDIR_IN, BIDIR_OUT);
type CAP_DATA is (PI, PO, UPD, CAP, X, ZERO, ONE);
type CELL_DATA is record
CT : CELL_TYPE;
I : BSCAN_INST;
CD : CAP_DATA;
end record;
type CELL_INFO is array (positive range <>) of CELL_DATA;
-- Boundary cell deferred constants (see package body)
constant BC_0 : CELL_INFO;
constant BC_1 : CELL_INFO;
constant BC_2 : CELL_INFO;
constant BC_3 : CELL_INFO;
constant BC_4 : CELL_INFO;
constant BC_5 : CELL_INFO;
constant BC_6 : CELL_INFO; -- This cell not recommended
constant BC_7 : CELL_INFO; -- Use BC_7 in place of BC_6
constant BC_8 : CELL_INFO;
constant BC_9 : CELL_INFO;
constant BC_10 : CELL_INFO;
-- Boundary register declarations
attribute BOUNDARY_LENGTH : integer;
attribute BOUNDARY_REGISTER : string;
2.6 Packages and Package Bodies 87

-- Miscellaneous
attribute PORT_GROUPING : string;
attribute RUNBIST_EXECUTION : string;
attribute INTEST_EXECUTION : string;
subtype BSDL_EXTENSION is string;
attribute COMPLIANCE_PATTERNS : string;
attribute DESIGN_WARNING : string;
end STD_1149_1_2001; -- End of 1149.1-2001 Package

package body STD_1149_1_2001 is -- Standard boundary cells

-- Generic cell capturing minimum allowed data

constant BC_0 : CELL_INFO :=
((INPUT, EXTEST, PI), (OUTPUT2, EXTEST, X),
(INPUT, SAMPLE, PI), (OUTPUT2, SAMPLE, PI),
(INPUT, INTEST, X), (OUTPUT2, INTEST, PI),
(OUTPUT3, EXTEST, X), (INTERNAL, EXTEST, X),
(OUTPUT3, SAMPLE, PI), (INTERNAL, SAMPLE, X),
(OUTPUT3, INTEST, PI), (INTERNAL, INTEST, X),
(CONTROL, EXTEST, X), (CONTROLR, EXTEST, X),
(CONTROL, SAMPLE, PI), (CONTROLR, SAMPLE, PI),
(CONTROL, INTEST, PI), (CONTROLR, INTEST, PI),
(BIDIR_IN,EXTEST, PI), (BIDIR_OUT, EXTEST, X ),
(BIDIR_IN,SAMPLE, PI), (BIDIR_OUT, SAMPLE, PI),
(BIDIR_IN,INTEST, X ), (BIDIR_OUT, INTEST, PI),
(OBSERVE_ONLY, SAMPLE, PI), (OBSERVE_ONLY, EXTEST, PI) );

-- Description for f11-18, f11-30, f11-34c, f11-34d, f11-36c,

-- and f11-46d (see Fig. 2.11 on page 95)
constant BC_1 : CELL_INFO :=
((INPUT, EXTEST, PI), (OUTPUT2, EXTEST, PI),
(INPUT, SAMPLE, PI), (OUTPUT2, SAMPLE, PI),
(INPUT, INTEST, PI), (OUTPUT2, INTEST, PI),
(OUTPUT3, EXTEST, PI), (INTERNAL, EXTEST, PI),
(OUTPUT3, SAMPLE, PI), (INTERNAL, SAMPLE, PI),
(OUTPUT3, INTEST, PI), (INTERNAL, INTEST, PI),
(CONTROL, EXTEST, PI), (CONTROLR, EXTEST, PI),
(CONTROL, SAMPLE, PI), (CONTROLR, SAMPLE, PI),
(CONTROL, INTEST, PI), (CONTROLR, INTEST, PI) );

-- Description for f11-14, f11-31, f11-35c, f11-35d, f11-37c,

-- f11-38c, f11-39(output) and f11-41c (see Fig. 2.12 on
-- page 96)
88 2 Boundary-Scan Description Language (BSDL)

constant BC_2 : CELL_INFO :=

((INPUT, EXTEST, PI), (OUTPUT2, EXTEST, UPD),
(INPUT, SAMPLE, PI), (OUTPUT2, SAMPLE, PI),
(INPUT, INTEST, UPD), -- Intest on output2 not supported
(OUTPUT3, EXTEST, UPD), (INTERNAL, EXTEST, PI),
(OUTPUT3, SAMPLE, PI), (INTERNAL, SAMPLE, PI),
(OUTPUT3, INTEST, PI), (INTERNAL, INTEST, UPD),
(CONTROL, EXTEST, UPD), (CONTROLR, EXTEST, UPD),
(CONTROL, SAMPLE, PI), (CONTROLR, SAMPLE, PI),
(CONTROL, INTEST, PI), (CONTROLR, INTEST, PI) );

-- Description for f11-15 (see Fig. 2.13 on page 97)

constant BC_3 : CELL_INFO :=
((INPUT, EXTEST, PI), (INTERNAL, EXTEST, PI),
(INPUT, SAMPLE, PI), (INTERNAL, SAMPLE, PI),
(INPUT, INTEST, PI), (INTERNAL, INTEST, PI) );

-- Description for f11-16, f11-17, f11-39(input) (see

-- Fig. 2.14 on page 99)
constant BC_4 : CELL_INFO :=
((INPUT, EXTEST, PI), -- Intest on input not supported
(INPUT, SAMPLE, PI),
(OBSERVE_ONLY, EXTEST, PI),
(OBSERVE_ONLY, SAMPLE, PI),
-- Intest on observe_only not supported
(CLOCK, EXTEST, PI), (INTERNAL, EXTEST, PI),
(CLOCK, SAMPLE, PI), (INTERNAL, SAMPLE, PI),
(CLOCK, INTEST, PI), (INTERNAL, INTEST, PI) );

-- Description for f11-46c, a combined input/control (see

-- Fig. 2.15 on page 100)
constant BC_5 : CELL_INFO :=
((INPUT, EXTEST, PI), (CONTROL, EXTEST, PI),
(INPUT, SAMPLE, PI), (CONTROL, SAMPLE, PI),
(INPUT, INTEST, UPD), (CONTROL, INTEST, UPD) );

-- Description for f11-38d, a reversible cell

-- (see discussion in Sect. 2.6.3 on page 100)
-- !! Not recommended; replaced by BC_7 below !!
constant BC_6 : CELL_INFO :=
((BIDIR_IN, EXTEST, PI), (BIDIR_OUT, EXTEST, UPD),
(BIDIR_IN, SAMPLE, PI), (BIDIR_OUT, SAMPLE, PI),
(BIDIR_IN, INTEST, UPD), (BIDIR_OUT, INTEST, PI) );

-- Description for f11-37d, self monitor reversible (see

-- Fig. 2.16 on page 102)
-- !! Recommended over cell BC_6 !!
2.6 Packages and Package Bodies 89

constant BC_7 : CELL_INFO :=

((BIDIR_IN, EXTEST, PI), (BIDIR_OUT, EXTEST, PO),
(BIDIR_IN, SAMPLE, PI), (BIDIR_OUT, SAMPLE, PI),
(BIDIR_IN, INTEST, UPD), (BIDIR_OUT, INTEST, PI) );

-- Description for f11-40, f11-41d (see Fig. 2.17 on

-- page 104)
constant BC_8 : CELL_INFO :=
-- Intest on bidir not supported
((BIDIR_IN, EXTEST, PI), (BIDIR_OUT, EXTEST, PO),
(BIDIR_IN, SAMPLE, PI), (BIDIR_OUT, SAMPLE, PO) );

-- Description for f11-32 (see Fig. 2.18 on page 105)

constant BC_9 : CELL_INFO
-- Self-monitoring output
((OUTPUT2, EXTEST, PO),
(OUTPUT2, SAMPLE, PI),
(OUTPUT2, INTEST, PI),
:=
that supports Intest
(OUTPUT3, EXTEST, PO),
(OUTPUT3, SAMPLE, PI),
(OUTPUT3, INTEST, PI) );

-- Description for f11-33 (see Fig. 2.19 on page 106)

constant BC_10 : CELL_INFO :=
-- Self-monitoring output that does not support Intest
((OUTPUT2, EXTEST, PO), (OUTPUT3, EXTEST, PO),
(OUTPUT2, SAMPLE, PO), (OUTPUT3, SAMPLE, PO) );
end STD_1149_1_2001; -- End IEEE Std 1149.1-2001 Package Body

In the above set of definitions for Boundary Register cells (in the package body)
you will see comments that call out figure drawings33 both from IEEE Std 1149.1-
2001 and in this book to help you recognize the architecture of cells versus the
names given in the package. A description of these cells and their figures is given in
Sects. 2.6.3 and 2.6.4, and a detailed discussion of how Boundary Register cells are
described in BSDL is given in the next section.

2.6.2 Cell Description Constants

Boundary-Scan Boundary Register cell designs are documented in packages bodies

such as STD_1149_1_2001 using constants of type CELL_INFO. In that package
one can find the definition of CELL_INFO. It is an unconstrained array of CELL_
DATA records. "Unconstrained" means the array size is defined at the time the

33
The IEEE figure descriptors look like “f11-37d” or “f11-35c” referring to Clause 11 in the stan-
dard. The “d” and “c” suffixes refer to the data cell or control cell in a drawing.
90 2 Boundary-Scan Description Language (BSDL)

constant is defined. Each CELL_DATA record contains three fields34 that define
how the cell behaves upon passing through Capture-DR. Each field is an enumer-
ated type. The fields are:
• the CELL_TYPE field. This field identifies the context that the cell can be used
in within a component design. Its values may be INPUT, INTERNAL, CLOCK,
CONTROL, CONTROLR, OUTPUT2, OUTPUT3, OBSERVE_ONLY, BIDIR_IN
and BIDIR_OUT. (See discussion below.)
• the BSCAN_INST field. This field identifies an instruction supported by this
cell. The values allowed in this field are EXTEST, SAMPLE, and INTEST. All
cells are required to support SAMPLE and EXTEST.35
• the CAP_DATA field. This field identifies the source of the data captured by the
capture (CAP) flip-flop in a given context and for a given instruction. Its values
must be PI, PO, UPD, CAP, X, ZERO and ONE. (See discussion below.)
A Boundary Register cell design such as shown Fig. 2.11 is very versatile and
may be used in a number of contexts; it may serve as an input cell, an output cell, an
internal cell, a control cell, and so on. (This cell is called BC_1 in the standard pack-
age.) For compactness, eliminating the need for a description for each context, the
CELL_TYPE field allows us to state the allowable contexts the cell can be used in.
Table 2.4 gives the definitions of the CELL_TYPE field symbols.
The CAP_DATA field can be determined by tracing backward from the capture
flip-flop through the various multiplexers until the source of the captured data is
found. We use an abstraction of a Boundary Register cell to show the various
sources of capture data, shown in Fig. 2.10.

Table 2.4 Definitions of allowable CELL_TYPE symbols

Value Meaning
Input A simple input pin receiver cell
Clock A cell at a clock input
Output2 Cell supplying data for a 2-state output
Output3 Cell supplying data for a 3-state output
Control Cell controling a 3-state drive or cell direction
Controlr A control cell that disables at Test-Logic-Reset
Internal Cell that captures internal data
Bidir_in A bidirectional pin cell acting as an input
Bidir_out A bidirectional pin cell acting as an output
Observe_Only A cell with only a capture flip-flop (CAP), no control capability

34
It is a BSDL standard practice that these fields be defined positionally (as shown) rather than by
VHDL field tagging. The order of the fields is significant.
35
Non-invasive instructions such as BYPASS or IDCODE are not included here because they do
not cause the Boundary Register to capture data.
2.6 Packages and Package Bodies 91

Mode G
PI 0

0 PO
Capture Update
1 1
0 Reg Reg
1 2
D Q D Q
X 3
4
CK CK
5
6

Sel

Update-DR
Clock-DR
From TAP
Controller

BRegAbst

Fig. 2.10 An abstraction of a Boundary Register cell showing capture data sources

Table 2.5 Definitions Value Meaning

of CAP_DATA symbols
PI The parallel input of the cell (see discussion)
Zero a constant 0
One A constant 1
X Unknown
PO the parallel output of the cell or driver if present
(see discussion)
UPD the output of the Update (UPD) flip-flop
CAP the output of the Capture (CAP) flip-flop

Table 2.5 gives the definitions of the symbols used for CAP_DATA field that
match the capture data sources shown in Fig. 2.10. Two of these symbols, PI (paral-
lel input) and PO (parallel output) must be interpreted in the context that the cell is
used. For example, if the cell may be used at an IC input, then PI must be interpreted
as the IC input pin and PO must be interpreted as the output that drives System
Logic. If, on the other hand, the cell is serving an IC output, then PO must be inter-
preted as the IC output pin after any driver and PI must be interpreted as a System
Logic output. This is important for many software applications because they often
will not know how the system logic behaves. Thus, capturing a System Logic output
will be associated with the unknown value "X" by these applications.
For a bidirectional such as shown in Fig. 2.16 on page 102, the context is condi-
tioned by the direction that the cell is currently serving. Such a cell has a collection
of multiplexers that reverse the apparent direction of data. While the cell is operat-
ing as bidir_out as governed by its attending control cell, then PO is the IC pin and
PI is the System Logic. While the cell is operating as bidir_in, then PI is the IC pin
and PO is the System Logic. Note that in the attribute BOUNDARY_REGISTER
92 2 Boundary-Scan Description Language (BSDL)

description, the function field (see Table 2.2 on page 76) for a reversible cell is
coded as bidir while in a CELL_DATA description, the symbols bidir_in and bidir_
out are used to incorporate the direction information.

2.6.3 Basic Cell Definitions BC_0 to BC_7

In the previous Sect. 2.6.1 we saw constants that describe certain “standard” cells
commonly found in 1149.1 implementations, as given in the Standard itself. These
constants were labeled BC_0 through BC_7, and new cells designs may be intro-
duced in the future.36 Indeed, BSDL has reserved the names BC_0 through BC_99
to give the capability to define 100 “standard” cell designs, although it is very
unlikely the Working Group will ever define more than a fraction of these.
This section shows some common architectures of cell designs, extracted from
the Standard itself. If you examine the chapter titled “The Boundary-Scan Register”
in the Standard in detail, you will see many examples of cell architectures, but many
of these are based on a common theme. BSDL has extracted these common archi-
tectures and labeled them for reference purposes with the result that there are only
seven basic architectures.
Seven cells? Yes. The cell BC_0 is a special case. The Working Group added it
to BSDL to serve as a “minimum” cell description that satisfies all the rules for cell
architecture but has no additional capabilities. It is intended to be used as a “default”
cell design when the situation arises where you need to describe an IC’s 1149.1
implementation, but do not know the exact details of the Boundary Register cell
architectures used in the design. A BC_0 cell definition should allow software tools
to provide minimum basic performance. Of course, using BC_0 also means a reduc-
tion in test diagnostic resolution if a device actually contains more advanced cell
designs. If you know (or can find out) the actual cell design information, then you
should avoid using the BC_0 default.

2.6.3.1 Cell BC_1

This cell architecture is shown in Fig. 2.11. It is a very basic design and also very
flexible. It can be used in many contexts; as an input cell, an output cell, a control
cell, an internal cell and as a building block for handling bidirectional pins.
Furthermore it will support all 1149.1 instructions that deal with the Boundary
Register, including INTEST. This cell is typified by the fact that it contains a multi-
plexer37 in the system signal path that is placed at the exit of the cell to the Parallel
Output (Table 2.6).

36
See Sect. 2.6.4 for three new cells, BC_8 through BC_10 introduced with the 2001 revision of
the standard.
37
Refer to Sect. 1.3.5 for a discussion of ways to optimize cell designs.
2.6 Packages and Package Bodies 93

BC_1 Cell Shift Out

Mode G
Parallel In 0
Parallel
Shift-DR G
Capture Update Out
1
0 Reg Reg
D Q D Q
1
CK CK

Shift In Clock-DR Update-DR BC_1Cell

Fig. 2.11 Cell architecture BC_1, a basic but very flexible design

Table 2.6 Mode signal assignment for cell BC_1 used in any context
Instruction Mode
EXTEST 1
SAMPLE, PRELOAD, BYPASS, IDCODE, USERCODE 0
INTEST 1
RUNBIST 1
CLAMP 1
These are all the public non-invasive instructions

2.6.3.2 Cell BC_2

This cell architecture differs from BC_1 in that there is a multiplexer in the signal
path placed at the entrance of the cell from the Parallel Input. Examining Fig. 2.12
you will see that the Capture flip-flop can capture the content of the Update latch
when the Mode control signal is set to “1”. This feature increases the testability of
the 1149.1 logic38 itself; if, for example you use BC_2 cells at input pins, then the
Update latch and the “1” pathway through the series multiplexer are now testable
(using the INTEST instruction) without requiring data to be propagated through
the system circuitry.39 (The BC_1 design does require that the system circuitry be
involved in testing these same portions of an input Boundary Register cell)

38
It is important to consider how the 1149.1 circuitry will be verified during production of the
IC. This is one reason why some will want to include the 1149.1 circuitry within another testability
discipline such as internal scan (for example LSSD). If another testability scheme subordinates
1149.1 (see Sect. 1.7 on page 41), then the testability of a given cell design in 1149.1 operation
may not be an issue.
39
This feature may not be utilized by ATPG software however. You should investigate the capabili-
ties of an ATPG algorithm if this feature will be important to you.
94 2 Boundary-Scan Description Language (BSDL)

BC_2 Cell Shift Out

G
Parallel
0
Input Parallel
1 Output

Update Capture G
Reg Reg 0
Q D Q D
1
CK CK

Shift
M ode UpdateDR ClockDR In ShiftDR BC_2Cell

Fig. 2.12 Cell architecture BC_2. This cell can capture its own Update latch content

Table 2.7 Mode signal assignments for cell BC_2 in the context of use. See text for an exception
regarding INTEST
Mode Mode
Instruction (used as an input cell) (used as an output or control cell)
EXTEST 0 1
SAMPLE, PRELOAD, BYPASS, 0 0
IDCODE, USERCODE
INTEST 1 0
RUNBIST X 1
CLAMP X 1

BC_2 is also very flexible in that it can be used for input cells, output cells, internal
cell, control cells and in some composite bidirectional cell structures. However, this
cell has a subtle limitation with respect to INTEST support; if the cell is used to sup-
port a two-state output pin, where the two-state driver is integrated into the signal path
multiplexer, then this cell does not satisfy a rule for INTEST. This rule requires that
the cell capture the system output, but because of the placement of the multiplexer, a
faulty state on the output pin could be captured rather than the system output value.
Table 2.7 shows mode assignments for cell BC_2 for the case where the cell is used
to service an input versus being used to service an output or driver enable control.

2.6.3.3 Cell BC_3

Cell BC_3 shown in Fig. 2.13 is a cell, used only for inputs (or internal cells), that
does not possess an Update latch but does support INTEST. One of the principle
reasons for providing an Update latch is to prevent shift ripple that occurs on the
output of the Capture flip-flop while shifting data, from being propagated to the
parallel output of the cell. This data noise would then be presented to the system
2.6 Packages and Package Bodies 95

BC_3 Cell Shift Out

From
System G
Pin 0
To System
G
Capture 1
Circuitry
0 Reg
D Q
1
CK

Shift In ClockDR Mode

ShiftDR BC_3Cell

Fig. 2.13 Cell architecture BC_3, an input cell with no Update latch

Table 2.8 Mode signal assignment for cell BC_3

Instruction Mode
EXTEST 0
SAMPLE, PRELOAD, BYPASS, IDCODE, USERCODE 0
INTEST 1
RUNBIST X
CLAMP X

circuitry where it might have unwanted effects. However, for some system circuitry
(notably, combinatorial circuitry) this shift noise would have no harmful effects nor
would it even be detectable from outside the IC. For applications where this will be
true, a BC_3 design will have the (small) economy of eliminating the Update latch
and its clock signal (Table 2.8).

2.6.3.4 Cell BC_4

Cell BC_4 shown in Fig. 2.14 also has no Update latch and it eliminates the series
multiplexer from the system signal path as well. This is attractive because it removes
some potential signal delay from the system signal pathway. The price for eliminat-
ing delay is that the cell does not support INTEST on general input pins. If INTEST
functionality is desired in an IC, then the BC_4 cell design cannot be used on any
input pin except a system clock40 input.
Cell BC_4 has no mode signal supplied by the TAP instruction decoder.

40
Omitting INTEST control (by using cell BC_4) from a clock pin eliminates delay from a pin that
could be extraordinarily sensitive to inserted skew and propagation effects due to Boundary-Scan.
However, it creates the complication of coordinating system clocks with an INTEST application.
96 2 Boundary-Scan Description Language (BSDL)

BC_4 Cell Shift Out

From
System
To System
Pin
Circuitry
G
Capture
0 Reg
D Q
1
CK

Shift In ClockDR

ShiftDR BC_4Cell

Fig. 2.14 Cell architecture BC_4, a cell with no Update latch and no series multiplexer

BC_5 Cell Shift Out

INTEST Shift-DR
Mode G
Output 0 To Driver
Enable G
G
Capture Update Enable
0 1
0 Reg Reg
1 D Q D Q
1
CK CK

Shift In Clock-DR Update-DR BC_5Cell

Fig. 2.15 Cell architecture BC_5, a control cell for an input pin

2.6.3.5 Cell BC_5

Cell BC_5 is shown in Fig. 2.15. This cell can be used in the “merged input/control”
cell situation (Sect. 2.4.1) seen in Fig. 2.7 on page 81. It is like the BC_1 cell, but
has and additional multiplexer controlled by the TAP decoder. When INTEST is the
effective instruction, this cell reloads its Update flip-flop content to avoid capturing
data appearing on the input pin (Table 2.9).

2.6.3.6 Cell BC_6

Cell BC_6 is used as a data cell at a bidirectional system pin, but it is not shown in
a figure in this book because the 1149.1 Working Group is actively discouraging41
its further use in Boundary-Scan implementations. The cell architecture called
BC_7 should be used in its place.

41
Indeed, the 2013 version of 1149.1 (see Part 2 of this book) does not document the BC_6 cell in
its revision of BSDL.
2.6 Packages and Package Bodies 97

Table 2.9 Mode signal assignments for cell BC_5

Instruction Mode
EXTEST 1
SAMPLE, PRELOAD, BYPASS, IDCODE, USERCODE 0
INTEST 1
RUNBIST 1
CLAMP 1

Cell BC_6 does conform to the rules of the Standard, but is seriously limited in
one respect. It cannot monitor the state of its bidirectional pin when the pin’s driver
is enabled to drive data out. Pin monitoring capability is inherently available in multi-
cell bidirectional structures we saw in Fig. 1.8 (page 24) and is now provided by the
BC_7 architecture, also a single-cell implementation. Pin monitoring at all times
gives important diagnostic capability that the Working Group wants to promote.
The BC_6 architecture was only promoted with the first edition [IEEE90] of the
1149.1 standard. Since the release of Supplement A [IEEE93a, IEEE93b] it has
been discouraged. If you have an older design for Boundary Register cells support-
ing bidirectional pins, you should examine them to see if they are indeed utilizing
the BC_6 architecture. If so, you should convert them to the BC_7 architecture.42

2.6.3.7 Cell BC_7

The BC_7 Boundary Register cell architecture shown in Fig. 2.16 (in the dotted line
box) is a single data cell that supports bidirectional system pins. The control cell
also shown is a BC_2-type cell.
BC_7 can provide data to the output driver and also monitor the pin activity even
when the output driver is driving the pin. This is an important feature that was lack-
ing in the BC_6 architecture just documented, and is a feature inherent in the
double-celled implementation for a bidirectional pin shown in Fig. 1.8 on page 24.
Monitoring a pin while it is driving can be used by diagnostic software to discover
that a driver is looking into a short and is thus not capable of delivering the requested
pin state. This is doubly important when the signal being driven does not travel to
other Boundary-Scan ICs (Table 2.10).

42
It may be true that the ATPG software you plan to use cannot tell the difference between a BC_6
and BC_7 architecture. Such limited software will probably make the assumption that all bidirec-
tional cells act like BC_6. If you are designing an IC to be used by others outside your industry
segment, you should assume that they have access to a fully capable ATPG algorithm that can use
the advanced capability offered by BC_7. In any event, it is a good question to put to the provider
of your ATPG algorithms.
98 2 Boundary-Scan Description Language (BSDL)

Mode_1 ShiftDR Shift Out Mode_3

G
Output
0
Control
1

G
0
D Q D Q
1
CK CK

G System
Output 0 Pin
Data
1

G
0 G
0
1 D Q D Q
1
CK CK
G
Input 0

Data
1

Mode_2 ClockDR
BC_7 Cell Shift In UpdateDR
BC_7Cell

Fig. 2.16 Cell architecture BC_7 (see the circuitry in the dotted line box) which supports bidirec-
tional data flow

Table 2.10 Mode signal assignments for BC_7 and its related BC_2 control cell
Instruction Mode 1 Mode 2 Mode 3
EXTEST 1 0 1
SAMPLE, PRELOAD, BYPASS, IDCODE, USERCODE 0 0 1
INTEST 0 1 0
RUNBIST X X 0
CLAMP 1 X 1
HIGHZ X X 0
2.6 Packages and Package Bodies 99

The “sea of multiplexers” in Fig. 2.16 can be confusing. It may be helpful to make
copies of the figure and mark it with a highlighting pen to trace the data flow under
various conditions. For example, if the cell is acting as an output (the control cell
contains a “1”) with the EXTEST instruction loaded (setting the three Mode signals
to 101), you can see how data must move through the cell. Similar tracings will show
how the other instructions route data for the cell behaving as either input or output.
Contrasting the double-celled implementation with BC_7, it is obvious that the
double-celled approach is very straightforward and that the BC_7 approach con-
tains more circuitry in the form of additional multiplexers. So it is probably true that
each approach contains about the same silicon area. So why would you use a BC_7?
One important advantage is that BC_7 reduces the cell count of an IC, by requiring
only one data cell per bidirectional pin versus two. Since most ICs these days are
heavy users of bidirectional pins, you could see savings in cell counts43 from 30 %
to nearly 50 %. Since ICs have growing pin counts, this can easily represent saving
scores or even hundreds of cells per IC.
Cell count matters when practical application of 1149.1 is studied. When many
ICs are strung together into Boundary-Scan chains, the lengths of the Boundary
Registers can accumulate into a very long total register length. This directly impacts
shift time and since Boundary-Scan tests are often stored for future use, the length
of these registers dictates storage space44 and the time to move this data around.
Another practical problem is that a given 1149.1 master architecture (like an ATE
system) will ultimately have to break up a shifting process into manageable pieces.
These pieces are separated by overhead processing which may significantly delay
the overall shift time and thus reduce throughput.
Note that the control cell circuitry shown above the dotted line box shown in
Fig. 2.16 is a BC_2 control cell design. The entire structure shown is capable of
supporting a complete set of instructions.45 If, for example, INTEST were not of
interest in your IC, you could eliminate the Mode2 signal and a multiplexer. Further,
eliminating HIGHZ and the HIGHZ-type option for RUNBIST eliminates the need
for Mode3 and the AND gate.

2.6.4 Cells BC_8 to BC_10 Introduced in 2001

The 1149.1 Working Group, with the release of the 2001 revision of the standard
[IEEE01] introduced three new Boundary Register cells. All three support varia-
tions of output or bidirectional behavior, with self-monitoring features, with and
without INTEST support.

43
The variability in savings is influenced by the number of control cells included to enable collec-
tions of bidirectional pin drivers.
44
It also influences the length of the BSDL used to describe the IC, which you may have to write!
45
With appropriate assignment of the “X” values for Mode2, you can make it the complement of
Mode3. Then you can remove one of these signals.
100 2 Boundary-Scan Description Language (BSDL)

One small technical change in the standard (with the 2001 revision) that was
taken advantage of in these newer cells is the idea that the SAMPLE instruction can
monitor the output driver’s output, rather than only the input to the output driver.
This does have the effect that the SAMPLE instruction may record the pin state
rather than the mission logic output, in cases where the driver cannot establish the
intended output state. This can happen for example, when a fault exists on the driven
signal, or if the driver is disabled at the time SAMPLE is capturing the pin state.

2.6.4.1 Cell BC_8

Cell BC_8, shown in Fig. 2.17, is used for bidirectional pins. This cell monitors
only the pin driver output and therefore does not support the INTEST instruction.
This cell does not need any additional control signals from the internal workings
of a companion control cell as seen with the BC_7 cell (Fig. 2.16). As such it can
serve for 2-state bidirectionals, where the data cell also serves as an output control,
as described in Sect. 2.4.2. The values for the Mode signal for BC_8 are shown in
Table 2.11.

Shift Out BC_8 Cell

Output
From G Driver
System 0

Circuitry
1

Update Capture G
Reg Reg 0
Q D Q D
1
CK CK

Shift In
Mode UpdateDR ClockDR ShiftDR
To System
Circuitry BC_8Cell

Fig. 2.17 Cell architecture BC_8 for self-monitoring bidirectional pins

Table 2.11 Mode control settings for cell BC_8

Instruction Mode
EXTEST 1
SAMPLE, PRELOAD, BYPASS, IDCODE, USERCODE 0
RUNBIST X
CLAMP 1
An ‘X’ is allowed if the RUNBIST instruction, by other means, disables the
output driver
2.6 Packages and Package Bodies 101

2.6.4.2 Cell BC_9

Cell BC_9 as shown in Fig. 2.18 is a self-monitoring cell for outputs that does sup-
port the INTEST instruction. See Table 2.12 for Mode1 and Mode2 settings.

2.6.4.3 Cell BC_10

Cell BC_10 shown in Fig. 2.19 is a self-monitoring output cell that does not support
the INTEST instruction. Note it is nearly the same as the BC_8 cell, but does not
propagate the driver state towards the mission logic (Table 2.13).

2.6.5 User-Defined Boundary Cells

Suppose a designer wanted to implement a component that could give an informal

self-identification rather than suffer the overhead of the IDCODE instruction. The
designer could do this by implementing a cell structure such as in Fig. 2.20 where a

Shift Out
From
Shift-DR BC_9 Cell
System Mode1 Output
Circuitry Mode2 G Driver
0
G
G
Capture Update 1
0
0 Reg Reg
1 D Q D Q
1
CK CK

Shift In Clock-DR Update-DR

BC_9Cell

Fig. 2.18 Cell architecture BC_9 for outputs with INTEST support

Table 2.12 Mode line settings for the BC_9 output data cell
Instruction Mode 1 Mode 2
EXTEST 1 1
SAMPLE, PRELOAD, BYPASS, IDCODE, USERCODE 0 0
INTEST 0 1
RUNBIST X 1
CLAMP X 1
102 2 Boundary-Scan Description Language (BSDL)

Shift Out BC_10 Cell

Output
From G Driver
System 0

Circuitry
1

Update Capture G
Reg Reg 0
Q D Q D
1
CK CK

Shift In
Mode UpdateDR ClockDR ShiftDR
BC_10Cell

Fig. 2.19 Cell architecture BC_10 for outputs with no INTEST support

Table 2.13 Mode settings for the BC_10 cell

Instruction Mode
EXTEST 1
SAMPLE, PRELOAD, BYPASS, IDCODE, USERCODE 0
RUNBIST 1
CLAMP 1
The standard shows a ‘1’ here, where in similar situations (e.g., BC_8) it
shows an ‘X’. This is inconsistent since in either case the RUNBIST instruc-
tion could be causing global disabling of all drivers and thus it would not
matter what the RUNBIST Mode setting was

new multiplexer has been added to route a constant 1 (or 0) into the capture (CAP)
flip-flop whenever EXTEST is in effect. This cell could be used as an output cell, a
control cell46 or an internal cell. Then, by using combinations of these cells that
capture 0 or 1 during EXTEST at various locations within the chain, the IC could
uniquely identify itself whenever captured EXTEST data was shifted out.
The next problem is to communicate this capability in a BSDL description.
This is done by creating a user-defined package and package body that describe two
new cells as in the example below. There, the two cells are named USER_0 and
USER_1. These names will be used in the component entity description, in field 1
of the Boundary Register description (see Sect. 2.3.13 on page 73). BSDL-based
software then knows from the package body that during EXTEST, the cells capture
their respective constants.

46
This cell design will not support cell merging of a control cell with an input cell because the
capture flip-flop cannot capture data from two different sources at the same time.
2.6 Packages and Package Bodies 103

Shift Out
Mode G
0
EXTEST ShiftDR Capture Update PO
G G 1
PI 0 0 Reg Reg
D Q D Q
"1" 1 1
CK CK

Update-DR
Clock-DR
Shift In

BRegCap1

Fig. 2.20 A cell that captures a constant 1 during EXTEST

The example package and package body, titled "USER_PACKAGE" looks like
this:

package USER_PACKAGE is

-- Boundary Cell deferred constants (see package body)

use STD_1149_1_2001.all; -- Get definition of "Cell_Info"

constant USER_0 : CELL_INFO;

constant USER_1 : CELL_INFO;

end USER_PACKAGE; -- End of User Package

package body USER_PACKAGE is -- User Boundary Cells

use STD_1149_1_2001.all;

constant USER_0 : CELL_INFO :=

((OUTPUT2, EXTEST, ZERO), (OUTPUT2, SAMPLE, PI),
(OUTPUT2, INTEST, PI), (OUTPUT2, RUNBIST, PI),
(OUTPUT3, EXTEST, ZERO), (INTERNAL, EXTEST, ZERO),
(OUTPUT3, SAMPLE, PI), (INTERNAL, SAMPLE, PI),
(OUTPUT3, INTEST, PI), (INTERNAL, INTEST, PI),
(OUTPUT3, RUNBIST, PI), (INTERNAL, RUNBIST, PI),
(CONTROL, EXTEST, ZERO), (CONTROLR, EXTEST, ZERO),
(CONTROL, SAMPLE, PI), (CONTROLR, SAMPLE, PI),
(CONTROL, INTEST, PI), (CONTROLR, INTEST, PI),
(CONTROL, RUNBIST, PI), (CONTROLR, RUNBIST, PI) );
104 2 Boundary-Scan Description Language (BSDL)

constant USER_1 : CELL_INFO :=

((OUTPUT2, EXTEST, ONE), (OUTPUT2, SAMPLE, PI),
(OUTPUT2, INTEST, PI), (OUTPUT2, RUNBIST, PI),
(OUTPUT3, EXTEST, ONE), (INTERNAL, EXTEST, ONE),
(OUTPUT3, SAMPLE, PI), (INTERNAL, SAMPLE, PI),
(OUTPUT3, INTEST, PI), (INTERNAL, INTEST, PI),
(OUTPUT3, RUNBIST, PI), (INTERNAL, RUNBIST, PI),
(CONTROL, EXTEST, ONE), (CONTROLR, EXTEST, ONE),
(CONTROL, SAMPLE, PI), (CONTROLR, SAMPLE, PI),
(CONTROL, INTEST, PI), (CONTROLR, INTEST, PI),
(CONTROL, RUNBIST, PI), (CONTROLR, RUNBIST, PI) );

end USER_PACKAGE; -- End of User Package Body

2.6.6 Definition of BSDL Extensions

A user-defined package can also be used to contain definitions of BSDL extensions.

Then, by referencing the package with a “use” statement (see Sects. 2.3.4 and
2.3.16) the declarations of the extensions become available to a BSDL description.
Consider this example:

Package Global_Def is -- An example BSDL extension package

-- Does not define boundary cells, just extensions

use STD_1149_1_2001.all;

-- Deferred constant declarations go here, if any

attribute First_extension : BSDL_EXTENSION; -- Declare BSDL

attribute Second_extension : BSDL_EXTENSION; -- extensions
attribute Third_extension : BSDL_EXTENSION; -- here.

end Global_Def;

package body Global_Def is

use STD_1149_1_2001.all;

-- Deferred constant definitions go here, if any

end Global_Def;

Any of the three extensions declared in this package are now available for refer-
ence in BSDL descriptions that “use” this package.
2.7 Writing BSDL 105

2.7 Writing BSDL

How does one go about writing a BSDL description? First, you must gather informa-
tion about the 1149.1 implementation within the IC to be described. Once you have
this information, it is a fairly simple process to transcribe it into BSDL. Some people
choose to take an existing BSDL description and edit it into the new one. A similar
approach taken by some is to create a BSDL template with guiding comments
embedded within it to prompt the writer for the correct style and organization.
The following list will help you gather the needed information and write the
BSDL description. Note that in several places, mandatory statements must appear
that are common (for example, the "use" statement) to any BSDL. Editing a tem-
plate or existing file will help you remember these statements and their placement.
1. Identify the component with a name. This will become the entity name that is
sprinkled throughout a BSDL description. Remember it must begin with an
alpha character.
2. Find all packaging configurations for the component. Typically, ASICs or other
one-of-a-kind components will have only one packaging option, but merchant
components may have several.
3. Examine the packaging configurations. Make sure all the pin names are valid
VHDL identifiers. This will now allow you to write the port statement (see
Sect. 2.3.2) for the entity. You may choose to use the bit_vector shorthand for
buses, or give each pin a unique name.
4. After the port statement, write the “standard use” statement (see Sect. 2.3.3). You
may need to come back to this spot later to add a user-defined package “use”
statement (see Sect. 2.3.4) if step 13 below turns up any user-defined cell designs.
5. Write the component conformance statement (see Sect. 2.3.5). Remember that
this identifies the release of the Standard that governed the design of the IC.
6. Write the pin mapping constants for all package configurations (see Sect. 2.3.6).
Name these constants with recognizable names such as "PGA_18x18" or
"PQFP_64." If there is only one constant, consider making the generic param-
eter default to this value (see Sect. 2.3.1).
7. Does this device have any differential signals? If so, use a grouped port state-
ment to describe them (see Sect. 2.3.7).
8. Identify the TAP Port pins. Write the TAP pin attributes. Don’t forget TRST* if
it exists. (See Sect. 2.3.8.)
9. This step is very important; if this device has any compliance enable pins, be
sure to document them (see Sect. 2.3.9). Lack of this information can cause
ugly debugging problems later.
10. Find the TAP instruction set for the IC; the length of the Instruction Register,
the instructions names and opcode bit patterns. Then write the Instruction_
Length and Instruction_Opcode attributes. (See Sect. 2.3.10.)
106 2 Boundary-Scan Description Language (BSDL)

11. Find the Instruction Register capture pattern, the bits it captures at Capture-IR.
The least two should be "01" and any higher order bits may be constants or
design-dependent. Those that are constants can be written so, but variable bits
will have to be coded as "X". Write the Instruction_Capture attribute. (See
Sect. 2.3.11.) If any of the instructions are considered private, then write an
Instruction_Private attribute that identifies them.
12. If any user-defined instructions exist, find out which register(s) they access.
Note any public instructions that access user-defined registers. Then write the
Register_Access attribute for these, taking care to define the lengths of user-
defined registers. If any of the user-defined registers capture static bits, denote
this with a “captures” clause. (See Sect. 2.3.12.) If any instructions were marked
private in step 10 above, you may choose to omit them from this attribute.
13. Begin investigating the Boundary Register construction. Note its length and
organization. Find out what cell designs were used. If any are special designs
not covered by cell definitions BC_1 through BC_6 given in STD_1149_1_2001,47
then you will need to write a user-defined supporting package that gives their
behavior (see Sect. 2.6.4 on page 104). This package might already exist if the
IC reuses cell designs from other ICs. Don’t forget to add another "use" state-
ment (see step 4 and Sect. 2.3.4) to refer to this new package.
14. Write the two attributes that describe the Boundary Register (see Sect. 2.3.13).
They are Boundary_Length and Boundary_Register.
15. Does this device support RUNBIST and/or INTEST? Then consider document-
ing their behavior with the associated execution statements (see Sects. 2.3.14
and 2.3.15).
16. Do you wish to document any additional data beyond the current definition of
BSDL? If so, consider using BSDL extensions (see Sect. 2.3.16) to place this
information within your BSDL file.
17. Does any design-specific information need to be documented so that other peo-
ple using this description will be alerted to its existence? If so, consider adding
a Design_Warning attribute (see Sect. 2.3.17).
18. End the entity with an end statement.
The main effort in creating a BSDL usually goes into the package-pin mapping
since typographical errors are easy to make, and into describing the Boundary
Register. In particular, the cell designs used in the Boundary Register and the sense of
the disabling bits for drivers seems to be difficult to dig up. Sometimes the original
designer must be located to supply this data. Remember, after creating a BSDL
description it is very important to verify its accuracy. This will be covered in Chap. 5.

47
The 2013 release of 1149.1, in its BSDL support package STD_1149_1_2013 documents cells,
BC_1 to BC_10, excepting the BC_6 cell. See Part 2 of this book.
2.8 Summary 107

You might ask, “I am not an IC designer so I cannot use these wonderful BSDL
generator/checkers. Can I avoid writing BSDL?” The answer is “maybe”. Consider
the work reported in [Raym95]. Here, they used a hardware simulation48 of a target
IC and a minimum of advance knowledge of the IC; like which pins are the TAP
pins and so on. Then the hardware simulation painstakingly performs experiments
on the IC to slowly deduce its basic structure. It finds the BYPASS instruction,
IDCODE (if there), EXTEST and SAMPLE. Once it knows EXTEST it then works
to find the length of the Boundary Register and then, one-by-one finds the I/O map-
ping. This process could potentially take hours of time, but if overnight you get a
workable BSDL from it, that sounds like a good deal.
The process will only find out the most basic facts about the IC. It will not dis-
cover advanced cell designs, for example. However, it may well be good enough to
do elementary Boundary-Scan testing.

2.8 Summary

BSDL exists in recognition of several problems. First, the 1149.1 Standard, while
conceptually simple, contains a great deal of detail that must be communicated
accurately. Second, software to support Boundary-Scan is essential. Third, this soft-
ware will come from many sources crossing boundaries among industry segments.
A standardized description language serves as a canonical form for 1149.1 infor-
mation. This form helps to ensure that all necessary data is described and is easily
interpreted by software. Without this standardization, much needless work must be
done to send 1149.1 data between industry segments.
As of the early 2000s, over 500 copies of the BSDL Version 0.049 parser have
been directly distributed by Hewlett-Packard (now Agilent Technologies) to people
in countries ranging from Australia to Yugoslavia.50 The desire for effortless inter-
change of 1149.1 data is real.

48
In a hardware simulation, the IC is actually mounted in a socket on a tester, powered up, and
driven with signals while the responses are learned. This requires both a tester and a known-good
copy of the IC in question.
49
This parser was developed to handle the first (non-IEEE) version of the language. Since the IEEE
version of BSDL is substantially similar to the first version, and since most people want to aug-
ment their existing BSDL parsing software to accept both versions of the language, Hewlett-
Packard did not release a second IEEE version of the parser specification.
50
The code is still available at http://www.eda.org/vug_bbs/bsdl.parser.
Chapter 3
Boundary-Scan Testing

Boundary-Scan testing is aimed primarily at digital logic structures, although

Boundary-Scan assets can provide invaluable resources for assisting with mixed
digital/analog testing as well. This chapter covers various test approaches utilizing
1149.1.
Before launching into a discussion of Boundary-Scan testing, it is important to
agree on what we are testing for. Boundary-Scan testing is primarily focused out-
ward from ICs, since the mandatory features of 1149.1 are set up to support testing
of the interconnect between Boundary-Scan devices. Other optional Boundary-Scan
features, if present, will allow various degrees of testing within a given IC. Also, the
fact that we are using the internal Boundary-Scan features of a set of ICs will give
us identification information about each IC as a side effect.
Boundary-Scan testing is good at detecting solder problems between devices and
boards; too much solder will often lead to solder bridges (shorts) between device
pins. Too little solder may lead to open pins. Pins may get bent during manufactur-
ing, leading to shorts and opens. If a device has had a pin driver or receiver damaged
by Electrostatic Discharge (ESD), this will be detected by Boundary-Scan testing.
If a device is rotated 180° before it is placed on the board, this will be detected as a
device within a chain that does not operate at all. Figure 3.1 shows examples of
some manufacturing defects affecting solder.
Boundary-Scan is not a good technology for detecting or diagnosing certain
problems. For example, say ESD damage has occurred in a transistor deep inside a
device, far from the Boundary-Scan logic. Unless a (very thorough) Built-In Self-
Test accessible via a TAP instruction is run, this defect will not be discovered by
Boundary-Scan testing. Similarly, if a device has a parametric defect (for example,
its propagation delay slightly exceeds specifications), it is unlikely that Boundary-
Scan testing will find this problem. If a solder joint is marginal but continuity still
exists, Boundary-Scan will not see a problem.

© Springer International Publishing Switzerland 2016 109

K.P. Parker, The Boundary-Scan Handbook, DOI 10.1007/978-3-319-01174-5_3
110 3 Boundary-Scan Testing

Integrated Circuit
1 2 3 4 5 6 7
Poor Quality
Joint

Open Solder
Joint

Board

Excess Solder
Short ShrtOpen

Fig. 3.1 Side view of a surface-mount IC soldered to a board. An open and a short are pictured.
The poor quality joint will be invisible to electrical test methods, including Boundary-Scan

Boundary-Scan testing is primarily aimed at finding and diagnosing major

manufacturing defects; bad devices, rotated devices, bad solder joints, blown driv-
ers, and so on.1 It is not able (without the addition of optional or user-defined capa-
bilities) to find subtle problems unrelated to manufacturing errors such as parametric
defects within ICs. Boundary-Scan testing essentially assumes that perfect devices
are used in an imperfect manufacturing process, and we want to find the manufac-
turing defects that result.

3.1 Basic Boundary-Scan Testing

Basic testing with Boundary-Scan requires detailed use of the TAP state diagram
and the fundamental TAP instructions BYPASS, PRELOAD, EXTEST, SAMPLE
and other optional instructions (if present) such as RUNBIST, IDCODE, CLAMP,
HIGHZ or INTEST. The fundamental 1149.1 scanning sequence is described next
as a basic building block.

3.1.1 The 1149.1 Scanning Sequence

In this section, we will examine the basic operation of the 1149.1 Standard. Many
of the operations we need to perform testing will utilize the Boundary-Scan logic
and the TAP state diagram in the same way. The following discussion will examine
a single IC containing Boundary-Scan. Later, we will look at the implications of
operating chains of ICs.

1
See the “PCOLA/SOQ” defect model presented in [Hird02]. Boundary-Scan does a pretty good
job finding these defects as noted in [Park03].
3.1 Basic Boundary-Scan Testing 111

In nearly all cases when we want to use the 1149.1 test logic, we must start by
initializing it to the Test-Logic-Reset state. Because it is not a safe assumption that
the test logic is already in this state, and since not all ICs possess the optional
TRST* pin, a robust test sequence should begin with a Boundary-Scan synchronizing
sequence: hold TMS high for five cycles of TCK. This forces the TAP into Test-
Logic-Reset regardless of its starting state. Once the logic is reset, we need to set up
an instruction in the TAP Instruction register.
Figure 3.2 traces the operation of the TAP state machine to accomplish this.
Note we proceed to the Shift-IR state using only the TMS and TCK signals. When
we reach Shift-IR the TDO pin becomes active (it was disabled) and data can be
shifted in via TDI.

Test-Logic-
1 Reset
0
1 1 1
0 Run-Test-Idle Select-DR-Scan Select-IR-Scan

0 0

Capture-DR Capture-IR
1 1
0 0

Shift-DR 0 Shift-IR 0 *
1 1

Exit1-DR Exit1-IR
1 1
0 0

Pause-DR 0 Pause-IR 0

1 1
0 0
Exit2-DR Exit2-IR

1 1

Update-DR Update-IR

1 0 1 0

* The self-loop on Shift-IR is traversed N-1 times to shift N-1 new

instruction bits into the instruction register. Bit N is shifted on the
transition to Exit1-IR. TAPDIRL

Fig. 3.2 TAP Controller state diagram showing path taken to shift an N-bit instruction into the
Instruction Register
112 3 Boundary-Scan Testing

Because we passed through Capture-IR to get to Shift-IR, the shift portion of the
Instruction Register, which is placed between TDI and TDO, now contains the
Instruction Capture pattern. This is the data that will appear on TDO while we are
shifting the desired instruction bit pattern into TDI. This data can be checked as it
comes out on TDO to see if it matches what we expect; the capture pattern specified
in the BSDL description using the INSTRUCTION_CAPTURE attribute (Sect.
2.3.10). If the instruction register is N bits long, we cycle back to Shift-IR N-1 times,
each time presenting a new bit2 of the instruction code to TDI. The Nth bit is shifted
while taking the transition to Exit1-IR.
At this point, we have a new instruction code in the shift portion of the Instruction
Register. This new instruction becomes effective upon passing through Update-IR,
when it is transferred to the parallel hold portion of the register. This occurs on the
falling edge of TCK while in the Update-IR state. Note that this is the time that a
Pin-Permission mode of operation would be entered if that is what the loaded
instruction calls for.
Figure 3.3 then shows how we set up to utilize the new instruction and the data
register that it targets. First, we travel to Capture-DR by way of Update-IR. Passing
Update-IR sets up the new instruction and targets the appropriate data register
between TDI and TDO.
The shift portion of the target data register captures parallel data upon exiting
Capture-DR and entering Shift-DR. The nature of this parallel data depends upon
the register and the current instruction. For example, if the BYPASS instruction is
in effect, then the BYPASS register captures a “0” as the Standard requires.
If EXTEST is in effect, then the Boundary Register captures parallel I/O data.
If IDCODE is in effect, the DEVICE_ID register captures the 32-bit Device
Identification code for the component, and so on.
We are then ready to shift this register as shown in Fig. 3.4. As we saw before
with the Instruction Register, we need to loop back upon the Shift-DR state until N-1
bits have been shifted. The last bit is shifted on the transition to the Exit1-DR state.
Typically, we want to shift N bits where N is the length3 of the target register. While
this shifting is occurring, the captured bits are transmitted out by TDO while new
bits are entering via TDI. These bits that enter will become the new residents of the
shift portion of the target register. When shifting is completed, they will be
transferred to the parallel hold portion of the target register at Update-DR as in
Fig. 3.5. That is, the contents of the Capture (CAP) flip-flops, which form the shift
portion, are transferred to the Update (UPD) flip-flops, which form the parallel hold
portion. (Please refer to Sect. 1.3.3 on page 21 for the construction of a data regis-
ter.) This occurs on the falling edge of TCK in the Update-DR TAP state.

2
The bits are shifted in via TDI, starting with the least significant bit.
3
Application software must keep track of N by knowing what register is targeted by the current
TAP instruction. A BSDL description contains the length of all registers and their associations with
TAP instructions.
3.1 Basic Boundary-Scan Testing 113

Test-Logic-
1 Reset
0
1 1 1
0 Run-Test-Idle Select-DR-Scan Select-IR-Scan

0 0

Capture-DR Capture-IR
1 1
0 0

Shift-DR 0 Shift-IR 0
1 1

Exit1-DR Exit1-IR
1 1
0 0

Pause-DR 0 Pause-IR 0

1 1
0 0
Exit2-DR Exit2-IR

1 1

Update-DR Update-IR

1 0 1 0

TAPDIRU

Fig. 3.3 The newly loaded instruction is activated when Update-IR is passed, selecting a new data
register targeted between TDI and TDO when we enter the Data Column of the state diagram

At the point where we are sitting in Update-DR, we have completed an entire

operation consisting of loading an instruction and capturing, shifting and updating
a data register. We are at a juncture here; we can proceed to Run-Test/Idle if we are
executing an instruction that uses TCK cycles; we may load another instruction by
proceeding to Select-IR-Scan; or we may make another pass down the data column
for another capture-shift-update operation on the target data register. This last option
is what is done most often during testing and is shown in Fig. 3.5.
Every time we pass down the data column while EXTEST is in effect, we capture
(read) data on component inputs (and bidirectional pins configured as inputs).
We then may shift this data out for examination. The update (write) part of the pro-
cess places newly shifted data on the output pins (and bidirectional pins configured
as outputs). This gives us a basic testing mechanism: we can use component outputs
114 3 Boundary-Scan Testing

Test-Logic-
1 Reset
0
1 1 1
0 Run-Test-Idle Select-DR-Scan Select-IR-Scan

0 0

Capture-DR Capture-IR
1 1
0 0
*
Shift-DR 0 Shift-IR 0
1 1

Exit1-DR Exit1-IR
1 1
0 0

Pause-DR 0 Pause-IR 0

1 1
0 0
Exit2-DR Exit2-IR

1 1

Update-DR Update-IR

1 0 1 0

* The self-loop on Shift-DR is traversed N-1 times to shift N-1 new

instruction bits into a target data register. Bit N is shifted on the
transition to Exit1-DR. TAPDDRL

Fig. 3.4 Sequence of states traversed to capture data and shift it out while at the same time enter-
ing new data

to write data on board-level nodes.4 We can then read, by means of component

inputs, the data that appears on their associated nodes. Thus, if one Boundary-Scan
driver in one IC is connected to another Boundary-Scan receiver in a second IC, the
interconnecting pathway (node) can be checked for opens and shorts. This can be
carried out in parallel for all nodes. While this is a straightforward process, you
should readily appreciate the role that software will play in keeping track of this data.

4
In practice, we would have preloaded the Boundary Register with the first set of data to be written by
using a capture-shift-update cycle with PRELOAD in effect. This data would then actually be written
to the board-level nodes when passing through Update-IR after loading the EXTEST instruction.
3.1 Basic Boundary-Scan Testing 115

Test-Logic-
1 Reset
0
1 1 1
0 Run-Test-Idle Select-DR-Scan Select-IR-Scan

0 0

Capture-DR Capture-IR
1 1
0 0

Shift-DR 0 Shift-IR 0
1 1

Exit1-DR Exit1-IR
1 1
0 0

Pause-DR 0 Pause-IR 0

1 1
0 0
Exit2-DR Exit2-IR

1 1

Update-DR Update-IR

1 0 1 0

TAPDDRU

Fig. 3.5 Completing a data shifting operation and updating the parallel hold portion of a data
register

3.1.2 Basic Test Algorithm

The following steps describe the basic test process of Boundary-Scan, including:
initialization of the TAP, initialization of the Boundary Register, multiple scanning
sequences, flushing the last stimulus pattern, and resetting the TAP. Note that the
algorithm is written using EXTEST, but the process is often similar for other testing
instructions as well. In this description, the “stimulus” pattern is applied to the com-
ponent driver pins and the “response” pattern is received at the component input pins.
In the literature on Boundary-Scan testing (see [Wagn87, Yau89] and [Jarw89]),
a pattern applied by a collection of drivers is called a Parallel Test Vector (PTV). A
PTV applies data by all drivers in parallel. For a given driver, a series of PTVs
116 3 Boundary-Scan Testing

applied in sequence creates a Sequential Test Vector (STV) on each associated node.
Thus, an STV is a stream of data applied sequentially by some driver to an indi-
vidual node. A Sequential Response Vector is a set of states received (captured)
sequentially by a Boundary-Scan receiver listening to a node.

3.1.2.1 Basic Test Algorithm

• Step 1: Initialize the TAP to Test-Logic-Reset.

• Step 2: Load the Instruction Register with the PRELOAD instruction. This puts
the Boundary Register between TDI and TDO, but does not grant
pin-permission.
• Step 3: Shift the first stimulus pattern into the Boundary Register. This is the
“preload” phase of the algorithm.
• Step 4: Load the Instruction Register with EXTEST. This puts the Boundary
Register between TDI and TDO and grants pin-permission upon passing
Update-IR. This applies (writes) the first stimulus pattern (PTV).
• Step 5: Capture (read) the response pattern into the shift portion of the Boundary
Register.
• Step 6: Shift the captured response pattern out while shifting in the next stimulus
pattern.
• Step 7: Update (write) the next stimulus pattern.
• Step 8: Have we written the last stimulus pattern? If so, go to step 9; otherwise
go to step 5.
• Step 9: Capture (read) the last response pattern.
• Step 10: Shift in a “safe” stimulus pattern5 while shifting out the last captured
response pattern.
• Step 11: Update (write) the safe pattern.
• Step 12: Go to Test-Logic-Reset and halt the test.
Analysis of the basic test algorithm shows that steps 1 through 4 initialize and set
up the test. Steps 5 through 8 apply tests, and steps 9 through 12 finish the test and
clean up. Note that “capturing,” as in steps 5 and 9, is done by all Boundary Register
cells, not just the input cells of interest. Thus there is plenty of extraneous data
mixed in with the data of interest.
As we shall see in future sections, the data shifted out will need to be analyzed
as a whole in order to interpret the results of the test and prepare a diagnosis. It is
usually the case that the “stop-on-first-fail” test approach typically used by In-Circuit
test systems is inadequate for Boundary-Scan testing. A true diagnostic system
must capture all the Boundary-Scan test results for a complete set of Parallel Test
Vectors.

5
A typical “safe” pattern would use the data from the BSDL description safe field (see Sect. 2.3.13
beginning on page 72) within the attribute BOUNDARY_REGISTER description. This can be
augmented with data needed to create safe board-level conditions as well.
3.1 Basic Boundary-Scan Testing 117

3.1.3 The “Personal Tester” Versus ATE

In the early days as the 1149.1 Standard was being developed, it was said that
Boundary-Scan would eliminate In-Circuit testing. This would lead us to a world
where ATE systems consist of nothing more than a Personal Computer with a spe-
cial (inexpensive) I/O card6 that could drive the four-wire 1149.1 protocol. A floppy
disk full of software would enable us to test any Boundary-Scan board. Indeed some
cynics have suggested that this view was excessively promoted in order to “sell”
management on the merits of investing in the IEEE Standard development process.
The concept of a “Personal Tester” is viable and the ASSET® System from Asset
Intertech7 is one actual example. This system is positioned as a useful tool for pro-
totype development as well as a way to learn about 1149.1 designs and verify their
operation. It is not intended as a general-purpose production ATE system, although
for low volume applications it can be used as such.
A major difference between a personal tester and a fully capable ATE system is
in the use model. It turns out that you almost always need to control more than 4 (or
5) signals to make Boundary-Scan work for practical board testing.8 Further, these
signals may require In-Circuit overdrive to achieve this control and these signals
may be embedded somewhere inside the board which leads you to the access ques-
tion. Now you are looking at the need for a test fixture. While you are testing, you
also must apply power to the board, so that brings on a little more complexity. Next,
consider how much of a board contains Boundary-Scan versus that portion (digital
and analog) that does not. The bench top tester offers no solutions here. Thus, for
low volume bench-top applications where limited test coverage could be accept-
able, the personal tester is a successful approach, but it can quickly become imprac-
tical for the general production line with high throughput and defect coverage goals.
For the verification of prototype boards, the personal tester has good merit. Here,
a designer responsible for getting 15 “Rev A” boards ready for evaluation will be
thrilled to get Boundary-Scan coverage of at least a portion of a board. If it takes
half a morning to set up some bench top power supplies and rig up a connector
for the TAP signals, this is quite acceptable. This disabling and conditioning prob-
lem can be addressed with clip leads or by simply ignoring the affected nodes.

6
Indeed, some people have used a standard 16-bit parallel I/O card for this purpose.
7
The ASSET system was originally developed by Texas Instruments [Texa90] and later spun off as
a new company devoted to personal Boundary-Scan equipment. Similar product concepts and
services are available from companies such as Corelis, Goepel, Intellitech and JTAG Technologies,
to name four more. They all can be found on the World Wide Web.
8
These additional signals are typically control nodes needed to hold certain states on a board that
will disable or condition other devices (that do not contain Boundary-Scan) so they do not interfere
with the test. Any compliance enable pins must also be controlled (see Sect. 1.7). The complicated
support software behind this capability is not often available on personal testers even if some con-
trol node capability is advertised. Even more tester I/O signals are required to stimulate and receive
data from incomplete Boundary-Scan nodes as the rest of this section explains.
118 3 Boundary-Scan Testing

Indeed, Boundary-Scan has proven quite useful for “rapid prototyping” as it is

called at companies that use it.9
The year 2002 saw the integration of a personal tester with a full production ATE
board test system.10 This integration allows greater cooperation between board
designers and board test engineers. For example, if a board designer has spent time
debugging a Boundary-Scan test and has it working, he can “export” it to the ATE
system (that has the personal tester integrated inside) and thus immediately have a
working test, with full diagnostic capability, for immediate use in volume board
production. While this test may not be a thorough as would be possible using the
native tools of the full ATE system, partial fault coverage immediately is better than
full coverage sometime later. Test engineers can then go back and “fill in” the miss-
ing coverage as time permits, using the additional ATE system’s resources. This can
be an important advantage when time-to-market pressures become significant.
I find this development very significant because it bridges the gap between board
designers and test engineers. They now have common goals in “getting Boundary-
Scan to work” for them. The board designer wants to get prototypes running, and
perhaps craft some access routines for doing Built-In Self-Test (see Sect. 3.2.6). In
that process, he will have found the potential problems11 with non-compliant devices
or inaccurate BSDL, and found ways to solve them. This advance work can only
help the board test engineer as he tunes the test for volume production.

3.1.4 In-Circuit Boundary-Scan

When people talk today about the difficulties facing In-Circuit testing, they often
focus on the anticipated difficulties in gaining nodal access. But actually, another
problem has been around longer and has had a much more deleterious effect: the
Application Specific12 Integrated Circuit (ASIC).

9
Interestingly, rapid prototyping is sometimes performed on personal testers, but with tests devel-
oped on fully capable ATE systems. This reflects the desire to use the program development tools
found on the ATE system without building an expensive, throw-away fixture. It also frees up the
more capital-intensive ATE for production test.
10
This was the Asset Intertech “ScanWorks” system with the Agilent Technologies 3070 board test
system.
11
The board designer also has considerably more leverage with device vendors when a compliance
problem is found. Test engineers typically do not influence purchasing decisions and are likely to
get less attention.
12
The meaning of “Application Specific” has a very narrow definition in the industry. For the pur-
pose of this discussion on the difficulty of testing, an ASIC could mean any one-of-a-kind design,
including Field-Programmable Gate Arrays (FPGA) ), Complex Programmable Logic Devices
(CPLDs) and the like.
3.1 Basic Boundary-Scan Testing 119

It is extremely difficult, in general, to develop board-level tests for ASICs

because they are one-of-a-kind designs; you will not find a “canned” test in a library
for an ASIC. Also, they rarely are designed with much thought towards testing,
particularly board level testing. Because ASICs may rival large VLSI processors in
size, yet may contain obscure and relatively unstructured logic, they present formi-
dable test generation problems13 [Agra88]. Add to this the fact that an ASIC might
undergo a design change at the last minute that would most likely obsolete a pains-
takingly developed test. These problems add up to the following unfortunate fact of
life: many ASICs are never tested at In-Circuit board test! Thus, a simple solder
problem, such as an open, would have to be discovered at functional/system test. As
ASICs are becoming a significant fraction of the digital components used in today’s
board designs, there is a serious problem here.
So what does Boundary-Scan do to help out? Imagine for a moment that you
have full nodal access to a board, and it has many ASICs. You have In-Circuit nails
surrounding each Boundary-Scan IC, but no “canned” tests for them in a library.
Because we have full nodal access to every pin of the IC, we can use standard,
In-Circuit unpowered shorts testing14 to find shorts. This still leaves opens testing15
and the basic verification that the IC is alive. This will require a powered digital test.
We can use the Boundary-Scan facility within each IC to enable Automatic Test
Program Generation (ATPG) for board-level ASIC testing. All that is needed is a
BSDL description of an ASIC’s 1149.1 implementation. With this, it is possible to
automate the creation of an In-Circuit test for that IC that will cover 100 % of the
manufacturing fault spectrum and do a better job of isolating open solder problems
on input pins than is possible with conventional ICs. We call this “In-Circuit
Boundary-Scan Testing.”
In-Circuit Boundary-Scan testing makes use of the basic testing algorithm
(Sect. 3.1.2.) and the fact that the In-Circuit ATE system can read IC output pins
when Boundary-Scan writes to them and it can write to IC input pins for the
Boundary Register to read. Thus the problem is to coordinate the Boundary-Scan
resources with the parallel drive/receive resources connected to In-Circuit test nails.

13
Structural problems in the electronics industry also contribute to the difficulty; tools for IC level
testing of ASICs do exist, but are of little use at board test due to board level constraints (nodal
wiring) and to the difference in failure mechanisms of interest between the two contexts. Finally,
the ASIC designer may have no motivation to solve board level test problems.
14
“Unpowered shorts testing” is accomplished before power is applied to the board. It uses a series
of very low voltage analog measurements that can isolate shorts between nailed nodes. Note that
the power supply nodes would be included in this test, finding Power/Ground shorts as well as
(nailed) signal nodes shorted to power nodes.
15
There are also unpowered techniques for finding opens on ICs, called Unpowered Open Test
technology. Three such technologies are Capacitive Leadframe test, Radio Frequency Induction
test and Analog Junction test. These have been documented at the International Test Conference
(see 1996 proceedings) and are available from major ATE vendors. Note all require nodal access.
See Chap. 10 for 1149.8.1 support for Capacitive Leadframe test.
120 3 Boundary-Scan Testing

In steps four and seven of our basic test algorithm (on page 120) we are causing
the Boundary-Scan drivers to write a stimulus pattern, which our ATE system can
then read and compare for valid data. In steps five and nine we are reading the com-
ponent inputs into the Boundary Register. We must instruct the ATE system to drive
the parallel inputs of the component just before this read occurs. Note that we can
disable the ATE drivers after the read occurs, which reduces the time that upstream
drivers are being overdriven. Between read and write operations, we are shifting out
captured states that the ATE system placed on the inputs and shifting in new stimuli
to be written to the component outputs where ATE receivers may see them.
A failing bit on TDO indicates that some Boundary Register cell did not capture
the value that the ATE system set up on an IC input. We can correlate the failing bit
position in the scan sequence to a cell in the Boundary Register. From there we map
(using the information from the BSDL attribute BOUNDARY_REGISTER) to an IC
input (or bidirectional acting as input) and can give a diagnostic for a failing input.
This capability is difficult16 or impossible with In-Circuit testing before 1149.1.
Other capabilities can be enjoyed that were not possible before 1149.1. For
example, if we have a very large pin count on an ASIC, we can choose to test sub-
sets of pins in succession, taking advantage of an In-Circuit ATE system’s multi-
plexed resources. Thus, we can multiply the value of our resources at the expense of
testing time. The concept of testing portions of an IC’s I/O pins would not be pos-
sible with conventional ASICs, unless of course they contained trivial logic. If some
of the IC inputs are connected to fixed signals (such as logic 0 or 1) we can skip
these pins, or directly verify the fixed values. With conventional ASICs, fixed values
have to be considered as a board-level constraint when developing the test, a con-
straint that effectively modifies the logic of the IC.
When Boundary-Scan was in its infancy (in the early 1990s) it was common for
people to say, “I only have one or two ICs with Boundary-Scan, so it will not help
me.” To them I would respond, “If Boundary-Scan can take a 2-week In-Circuit
programming problem and solve it in less than 10 s, is that of interest?” It was.

3.1.5 IC Test

The INTEST function allows us to test the System Logic of an IC even when the IC is
mounted on a board such as shown in Fig. 3.6. (Here, the IC is shown as part of a
chain, though we could also make use of an In-Circuit nail on the TDI-TDO connec-
tion between the chips to directly access the target IC.) When the TAP Instruction
Register is loaded with INTEST and we pass through Update-IR, the IC’s I/O pins are
disconnected from the System Circuitry, and the Boundary Register takes control of it.

16
It is possible to use a “fault dictionary” approach to diagnose opens on inputs, if there is only one
open, because this looks like a single stuck-at failure and matches the assumptions used to create
dictionaries. If multiple failures exist, then the dictionary approach will often give no diagnosis, or
a false diagnosis.
3.1 Basic Boundary-Scan Testing 121

IC in BYPASS IC in INTEST

System Circuitry

System Circuitry
Bypass Bypass

Instruction Instruction
TDI TAP TAP TDO
Controller Controller

TCK
TMS
ICINTEST

Fig. 3.6 An IC undergoing an INTEST function while loaded on a board

The IC’s output drivers also can be controlled by the Boundary Register.17 This control
allows us to set safe values on the IC’s outputs while INTEST in functioning.
To do an INTEST, we make use of the basic testing algorithm (Sect. 3.1.2) with
the following modifications:
• INTEST is loaded in place of EXTEST at step 4.
• All stimulus and response patterns must be organized with respect to the System
Logic I/Os rather than the component I/O pins.
• The “stimulus” pattern is being written to the System Logic inputs rather than to
the component output pins.
• The captured (read) response is that of the System Logic outputs, including out-
put enable signals.
• Component outputs can be held at safe or disabled states by adding these values
to each stimulus pattern.
In principle, it is possible to use the INTEST function to fully exercise the System
Logic of an IC loaded on a board, independent of its board wiring. In reality, there
are some practical restrictions. First, System Logic tests are often very long before
1149.1 serialization. After serialization, they could be far too long from two stand-
points: application time and the requirements placed on tester memory. Second, the
tests may have, as part of their goal, a high pattern application rate. This might not
be achieved after serialization, thus nullifying their intent.

17
As noted in Chap. 1, there are two options for output control during INTEST. All outputs may be
under control of the Boundary Register or they may all be set to the high impedance state.
122 3 Boundary-Scan Testing

One last difficulty is contributed by the notion given in the Standard that INTEST
may be implemented in an IC but that certain “clock” inputs do not have to be con-
trolled by the Boundary Register. When you have uncontrolled system clock inputs,
you must coordinate them with the application of the INTEST patterns and perhaps
with TCK as well. In this case, we must ensure that an ATE system coordinates
these additional requirements along with the basic INTEST concept. On analysis,
there can be one or several system clocks, as well as TCK, to manage and the prob-
lem can, in principle, become quite complex. When INTEST is to be used in this
environment, additional engineering of the basic test algorithm outlined above
could be necessary; in short, there is still a need for test engineers, even with the
advent of Boundary-Scan!

3.1.6 IC BIST

The 1149.1 Standard contains direct provisions for IC-level Built-In Self-Test
(BIST) of the System Logic. There is the optional RUNBIST capability specified by
the Standard. (Designers can implement their own BIST functions separate from
RUNBIST.) Shown next is a description of a basic RUNBIST test process.
RUNBIST is self-initializing, so no steps are shown that initialize internal counters
or accumulators.

3.1.6.1 Basic RUNBIST Test Algorithm

• Step 1: Initialize TAP to Test-Logic-Reset.

• Step 2: Load the Instruction Register with PRELOAD. This puts the Boundary
Register between TDI and TDO, but does not grant pin-permission.
• Step 3: Shift a “safe” pattern18 into the Boundary Register. This pattern will pre-
vent the IC drivers from conflicting with other board level signals when the
Boundary Register takes control of them.
• Step 4: Load the Instruction Register with RUNBIST. This puts the BIST result
register between TDI and TDO and grants pin-permission to the Boundary
Register upon passing Update-IR. This applies the “safe” pattern to all output
drivers.
• Step 5: Proceed to the Run-Test/Idle state. Issue TCK cycles19 from this state
fulfilling at least the minimum RUNBIST clocking requirement.
• Step 6: Proceed through Capture-DR, capturing the BIST response pattern in the
BIST result register targeted by RUNBIST.

18
Steps 2 and 3 can be omitted for ICs that do not use the Boundary Register to control outputs
during RUNBIST. These ICs place all output drivers in a high impedance state during RUNBIST.
19
The same clocking complications noted in section 3.1.5 concerning just what is a “clock” apply
here as well.
3.2 Testing with Boundary-Scan Chains 123

• Step 7: Shift out the BIST response pattern for verification.

• Step 8: Go to Test-Logic-Reset and halt the test.
The Standard has crafted the RUNBIST function such that it can protect the
component outputs from harm due to conflicts during the potentially lengthy BIST
test. Notice in step 5 that a minimum number of clocks must be issued to exercise
the BIST function; however, more may be applied. This facilitates performing
RUNBIST on several ICs in a chain in parallel even when they have different (non-
conflicting) clocking requirements. When the BIST result register is shifted out
(step 7), the interpretation of this result is up to the designer of the BIST function;
it could be a single pass/fail bit or perhaps a longer register with meaningful diag-
nostic information encoded within it.

3.2 Testing with Boundary-Scan Chains

The Boundary-Scan Standard allows for ICs to be linked into chains by linking the
TDO pin of one IC with the TDI pin of the next. For example, the 1149.1 ICs on a
board may all be linked together in a simple chain by sharing the TCK and TMS
signals and linking their TDO-TDI pins in succession. Several distinct simple chains
may exist on a board if they do not share any TAP signals; or conjoined chains can
be created by sharing some TAP signals. For a single simple chain, operation of the
Standard for testing purposes is straightforward. For multiple simple chains or con-
joined chains, operation becomes more difficult (see Sect. 5.2.1). Here we will
restrict our discussions to individual simple chains.
As mentioned in Chap. 1, a simple chain of Boundary-Scan ICs are always in the
same TAP state.20 This simplifies our view of the TAP states of the ICs; one can
picture the chain itself as following the TAP state diagram. However, each member
of the chain could have a different instruction active at any time, each of which
targets a different register. On top of this, each IC may have its own unique dimen-
sions on each register. This all changes as new instructions are loaded. Thus, there
is some careful bookkeeping involved with managing a Boundary-Scan chain. (Note
if we want to consider multiple simple or conjoined chains, then we must keep track
of independent TAP states for each chain or even for each IC.)
A fact of Boundary-Scan testing is that we depend upon our chain being in oper-
ational order before we can do useful testing. In essence, we have moved part of our
tester hardware onto the board we are trying to test. Just as no one would expect a
malfunctioning tester to reliably test a board, we cannot expect a malfunctioning
chain to be of much service either. The problem becomes that of ensuring that a
chain is basically functional and if it is not, quickly locating the problem so that it
can be repaired.

20
Again, assume that no assertion of an optional TRST* signal occurs that would drive some chain
members to Test-Logic-Reset independently.
124 3 Boundary-Scan Testing

3.2.1 1149.1 Chain Integrity

Chain integrity must be assured before we should trust the results of a test and obtain
reliable diagnoses. There are many faults that can damage a chain, for example:
• A component in the chain could be dead, missing, or misloaded.
• A component in the chain could have a broken connection for one of its TAP pins.
• A TDO to TDI connection between components could be shorted to another node.
Fortunately, the 1149.1 Standard has provided resources that facilitate chain
integrity testing. You should note that a combination of the above problems could
exist in a chain of components. If this is the case, it may be necessary to test and
repair and re-test the chain repeatedly until integrity is restored. Typically, an integ-
rity test will find only the problem closest to the TDO end21of the chain. This will
usually prevent us from seeing any problems that might exist further upstream.
The primary characteristic that facilitates integrity testing is the ability of each
IC in a chain to set up a deterministic data pattern in its TAP Instruction Register at
Capture-IR. We can then shift all the concatenated capture data out on TDO of the
last IC. By examining the BSDL description of each IC in a chain, we know from
the attribute INSTRUCTION_CAPTURE what this data will be. Furthermore,
because the Standard states that the two least significant bits must be “01,” we know
that each IC should cause TDO to toggle to both logic states. In the simplest case
where all instruction registers in a chain have only two bits (see Fig. 3.7), we would
see, in Table 3.1, the following concatenated data for a good chain (of seven ICs)
and one example of a failed chain. (Remember the rightmost bits, the least signifi-
cant, flow out of TDO first.)
In the bad data stream, IC 7 first shifts out its “01” (which is correct) followed by
the data for IC 6 (shifted through IC 7), which is also a correct “01.” Then we see a
correct “01” for IC 5. For IC 4, we see an incorrect “11” come out, and all subse-
quent bits are “11” for the upstream ICs 1–3. From this we can conclude that ICs
5–7 were basically functional but that something is wrong with one or more ICs
starting with IC 4. This conclusion might not be perfect because a damaged TDI

CaptIRPT
1 2 3 4 5 6 7

TDI '01' '01' '01' '01' '01' '01' '01' TDO

Fig. 3.7 A simple chain that has just passed Capture-IR, loading all Instruction Registers with “01”

21
However, one can sometimes find multiple chain integrity problems with a single test execution
if tester access is provided to the interior TDI-TDO connections within the chain.
3.2 Testing with Boundary-Scan Chains 125

Table 3.1 Example data bits for chains shown in Fig. 3.7. The bits for IC7 are the first to appear
at TDO
Integrated circuit
1 (TDI) 2 3 4 5 6 7 (TDO)
Good data stream 01 01 01 01 01 01 01
Bad data stream 11 11 11 11 01 01 01

receiver22 in IC 5 that always reads a “1” could be the real cause of the problem.
Because solder problems are often a prevalent failure mechanism, we could begin
by looking at the solder workmanship on IC 4; is there an open circuit on TCK,
TMS or TDO of IC 4? How about a solder open between TDO of IC 4 and TDI of
IC 5? Is IC 4 misloaded? Is IC 4 dead? From this, a diagnosis would have to suspect
a problem first with IC 4, but cannot completely rule out a problem with IC 5. Thus,
integrity testing will usually indict one of two ICs, with one having a higher likeli-
hood of causing the problem.
Because testing algorithms such as we have already seen start by immediately
programming the Instruction Registers of each component in the chain, we have the
nucleus of an integrity test built into the beginning of the test itself. If we instruct
our ATE system to check the instruction capture bits as they come out during the
first instruction programming sequence, it is possible to make basic integrity testing
an integral part of any test. This is highly advisable, as it will protect a test from the
potentially false assumption that a chain has integrity.
The above test sequence has one limitation—it does not test the integrity of TDI
for IC 1. This is easily solved by shifting two more bits, prepended to (that is,
attached to the beginning of) the sequence we want to load into the Instruction
Registers. If these bits are deliberately made the opposite of the mandatory instruc-
tion capture pattern (that is, “10”), they will be the last two bits shifted out and will
serve to indicate the end of the chain. These prepended bits are called sentinel bits.
More intricacy may be added to integrity testing; for example, we could program
the IDCODE instruction into those components that have it, while setting the rest to
BYPASS.23 We can then proceed to Shift-DR and read out the IDCODEs of those
components. This will tell us if any pin-compatible components have been loaded
in the wrong positions. In general, many of the failure mechanisms of interest have
fairly catastrophic effects on chain integrity. Thus, simply programming the
Instruction Registers for the first time will expose most problems.

22
We assume that all ICs have been thoroughly tested before placement on a board. Damage from
handling and placement, either physical (bent pins for example) or electrical (from Electrostatic
Discharge—ESD for example) are our main concerns.
23
Alert readers may wonder why we would program these instructions when the Test-Logic-Reset
state sets these intrinsically; you could proceed directly to Shift-DR to read out the IDCODEs. The
reason is many ICs do not contain IDCODE and place a single-bit Bypass Register with a captured
“0” between TDI and TDO. This single bit cannot cause a transition on TDO so that we suffer even
more ambiguity in isolating chain problems.
126 3 Boundary-Scan Testing

Table 3.2 Data streams from chains shown in Fig. 3.7 with IC4 TDI and TDO shorted together,
producing a Wired-AND
Integrated circuit
Sentinel bits 1 (TDI) 2 3 4 5 6 7 (TDO)
Good data stream 10 01 01 01 01 01 01 01
Bad data stream 00 00 01 01 01 01 01 01

One fairly insidious problem (see DeJo91]) can cause difficulty in diagnosing
chain integrity. If several identical components are chained in series, then the pat-
terns they capture in their Instruction Registers are also identical. Now, imagine that
TDI and TDO of IC 4 are shorted together and assume a Wired-AND occurs (see
Fig. 3.7). This creates the AND of the TDO signals in ICs 3 and 4. Using our
improved test sequence with a prepended sentinel “10” attached, we see the follow-
ing data propagated from TDO (Table 3.2).
What we see would indicate there is a problem in the vicinity of IC 1 when it
really is located at IC 4. This is because the data being wire-ANDed at IC 4 never
conflicts until the “10” sentinel is finally shifted out of IC 3. Then it ANDs to “00”
and this is loaded into both IC 4 and IC 5 at the same time. We do not see this result
until the data traverses ICs 6 and 7. This problem is studied in [DeJo91] and some
diagnostic processes are offered. However, there are two easier solutions; one is to
place In-Circuit probes on all interior TDI-TDO nodes so that all TAP signals used
by the chain can be tested for shorts using unpowered shorts test. The second is to
eliminate the chance that TDI can short to TDO on an IC; this can be done by making
sure that TDI is physically distant from TDO on the package pins24 (see Sect. 5.1.1).

3.2.2 Interconnect Test

Interconnect test refers to the testing for shorts and opens within the nodal wiring
between Boundary-Scan components only (see Sect. 3.2.4 for interactions between
Boundary-Scan nodes and other nodes25). Figure 3.8 shows a simple example. Note
that nodal connections between components are considered “interconnect.” The
nodes connected to nails are assumed to be board-edge signals; these will be tested
by Connection tests covered in Sect. 3.2.3. In this drawing we use the convention
that I/O pins on the left side of the package are inputs and those on the right are
outputs or bidirectional pins.

24
We are taking advantage of the fact that the vast majority of shorts are caused by improper con-
nections (for example, bad solder) between physically adjacent I/O pins. Board shorts between
printed node traces are usually eliminated before expensive components are loaded onto a board.
25
Boundary-Scan nodes are defined as those possessing at least one driver and receiver under
control of the combined Boundary Registers of a chain. (Note that this could be satisfied by a
single, bidirectional I/O pin.) “Other” nodes include analog nodes, conventional digital nodes and
power supply or voltage-reference nodes that would appear to be a logic “0” or “1” value.
3.2 Testing with Boundary-Scan Chains 127

A
B
C

U1 U2

TDI Nodes Tested as

Interconnections

A
B
D

U3 U4

TDO
IntcNode

Fig. 3.8 A boundary-scan chain of ICs with four interconnect nodes

The interconnect testing problem was studied by Kautz long before Boundary-
Scan was invented [Kaut74]. Kautz showed how a binary counting sequence could
offer a minimum sized test for wiring interconnects. Wagner [Wagn87] placed the
counting sequence technique into the Boundary-Scan lexicon. The definitive papers
by collaborators Yau and Jarwala offer an excellent survey, analysis and theoretical
framework for the problem ([Jarw89] and [Yau89]). To this book, we add some
practical experience to leaven our expectations for Boundary-Scan.
Interconnect testing usually lumps the testing for shorts and opens into one topic.
Here, we will split the two problems apart. Shorts (see Fig. 3.9) are a very destruc-
tive problem in that they can confuse diagnostic procedures and hide the occurrence
of other failures.
Opens, on the other hand (see Fig. 3.10) are a relatively simple problem to diag-
nose. Shorts, by their very nature, may cause driver conflicts on a board that could
degrade the lifetime or performance of the affected components. Opens will usually
not damage components. Since any Boundary-Scan testing necessitates applying
power26 to a board, shorts that are present immediately begin to act upon the affected
drivers. This gives us concern about component damage that could occur due to

26
The process of applying power is more complex and time consuming than many realize. It might
take several hundred milliseconds to stabilize a power voltage to specification. There may be several
voltages to be applied in sequence. It also might take hundreds of milliseconds to turn power off!
 Expected Captured
Signatures Signatures
A
B 010 011

C 001 011

Short
U1 U2

TDI

A
B
D

U3 U4

IntcShrt
TDO

Fig. 3.9 Interconnect test drives unique patterns assigned to each node from drivers to receivers.
A short is shown that creates a Wired-OR result

Open
A 0 1
B 0
C 0

U1 U2

TDI

A 0
B
D

U3 U4

TDO
IntcOpen

Fig. 3.10 An interconnect open that prevents driven data from reaching one of two receivers on a
node. This fact can help a diagnostic isolate the location of the open
3.2 Testing with Boundary-Scan Chains 129

powered shorts. There is a wealth of study [Sobo82, Robi83, Bush84, Hewl85,

Swen86] in the area of abused drivers, study inspired by In-Circuit testing. These
studies show us that we need to be concerned with the duration of time that a short
is excited under power. We can do little about the power sequencing and stabiliza-
tion time, so we need to try to minimize the time spent testing when testing will
excite driver conflicts. We have seen how the 1149.1 protocol can greatly lengthen
test times due to serialization; this then forces us to organize our tests such that
shorts are excited for a minimized duration.
By breaking our interconnect problem into two phases, one that focuses on shorts
first followed by another that focuses on opens, we can minimize the time that driv-
ers are in conflict. Be aware that failures will not allow neat assumptions; when
testing for shorts first, we cannot assume that opens do not exist. However, once we
have completed testing for shorts, then we can perform opens testing under the
assumption that there are no shorts to complicate matters.

3.2.2.1 Interconnect Shorts Test

Interconnect shorts testing is done by utilizing our basic test algorithm (Sect. 3.1.2).
It is used to transmit Sequential Test Vectors (STVs) onto nodes to be received by
Boundary-Scan input pins (see Fig. 3.11). The data received at Boundary-Scan

A 0 1 0 0 1
B 0 1 0 1 0
C 0 1 0 1 1

U1 U2

TDI

A 0 1 0 0 1
B 0 1 0 1 0
D 0 1 1 0 1

U3 U4

TDO
IntcSPTV

Fig. 3.11 Simple interconnect test showing STVs (horizontal patterns) for 4 nodes. The columns
are PTVs and represent the data as transmitted at each Update-DR state. Nodes A and B are bussed
130 3 Boundary-Scan Testing

input pins are called Sequential Response Vectors (SRVs). If a given node is operat-
ing properly, then the SRVs seen at all its receivers should match the STV of the
driver. We proceed as follows:
• Step 1: Examine the board netlist and BSDL descriptions of the Boundary-Scan
components. Enumerate the Boundary-Scan interconnect nodes and all attached
component pins.
• Step 2: For each node, identify all component pins that can drive the node,
including bidirectional pins. Select one and call it the designated driver of the
node. (See 3.2.2.2.)
• Step 3: Assign a unique Sequential Test Vector (STV) to each node. (See 3.2.2.2.)
• Step 4: Transpose the STVs into Parallel Test Vectors (PTVs). Use the basic test
algorithm to write an ATE program for the test.
• Step 5: Execute the test on an ATE system. Record each captured PTV that is
shifted out.
• Step 6: Transpose the captured PTVs into SRVs.
• Step 7: Analyze the SRVs. Use observed differences from the original STVs to
diagnose shorts and opens.
Note that steps 1–4 can be done once in preparation of the interconnect test and,
of course, can be completely automated. Step 5 is performed by an ATE system
once per board tested. Steps 6 and 7 may be skipped if the ATE system does not note
a failure during the test. If a failure is detected, the ATE system can immediately
remove power from the board before steps 6 and 7 are performed.

3.2.2.2 Discussion

Step 2 selects a designated driver for a node. This driver is enabled for the entire
interconnect test; no other driver is used. This means that for nodes with multiple
drivers, there are driver opens that might not be detected. Since we are deliberately
concentrating on shorts detection, we leave this class of undetected opens for future
testing as discussed later in this section (see Sect. 3.2.2.4 on page 140). In that dis-
cussion, we will examine several cases where opens are missed by interconnect
shorts testing.
The main reason for selecting and enabling a single designated driver is to keep
interconnect shorts tests brief. Testing for opens on bussed drivers can be relatively
expensive in terms of the number of PTVs needed. Because opens are benign and
shorts are potentially dangerous, we defer testing for this class of opens until we are
satisfied that shorts have been eliminated.
Step 3 assigns a unique STV to each node. The work by Yau and Jarwala [Jarw89,
Yau89] goes into great depth on this matter. The simplest and shortest test uses
binary numbers, sequentially assigned, as the STVs for nodes. When transposed
into PTVs, this gives us a number of PTVs equal to

[log 2 N ]
3.2 Testing with Boundary-Scan Chains 131

where N is the number of nodes being tested.

Logarithmic compression is impressive; we can test 1000 nodes with just 10
PTVs and 4000 with just 12 PTVs. The length of a PTV is loosely related to N. For
example, if the average node connects 4 pins, then there are 4*N pins being tested.
Each has at least one Boundary Register cell so there is an order of 4*N bits to shift
in the PTV. Let A be the average number of pins per node. Then the number of shift
cycles in the test is on the order of

AN [ log 2 N ]

cycles.27 For 4000 nodes of four pins each this is approximately 192,000 shift cycles.
In contrast to a counting sequence is a walking-bit sequence. (The walking-bit
sequence has the advantage that it eliminates a problem called aliasing, discussed in
this section in the topic “Aliasing and Confounding” below.) Here a single “1” (“0”)
is imposed on a field of “0”s (“1”s). For N nodes, each PTV is N bits long with only
the ith bit set to “1” (“0”) among them. This makes a much longer test, on the order of

AN 2
cycles. For the same 4000 nodes of four pins each, this is approximately 64,000,000
shift cycles.
The counting sequence test and the walking-bit test are two extremes of a con-
tinuum of test patterns, as studied by Yau and Jarwala. They trade length for diag-
nostic resolution. This will be discussed in the topic of “Aliasing” found next.
Step 4, our preparation for interconnect test, transposes STVs into PTVs. Here,
we take the least significant bit of each STV and assign it to the Boundary Register
cell of its designated driver, taking care to also turn on any associated driver enable
cell as well. When this has been done for the LSB of every STV, we have the stimu-
lus portion of the first test cycle, a PTV. We then look for every receiving cell con-
nected to each node and program our ATE system to expect those same bits in those
locations. This becomes the expected SRV that the ATE system can use to note if
any failures occur during the test. We iterate this process for each more significant
bit of the STVs until we have created all the PTVs.
In step 5, the ATE system executes the test. If a failure is noted, it does not stop-
on-first-fail as would be typical in times past. Rather it continues, logging all the
shifted response data for processing in steps 6 and 7. If no failure is noted, this
subsequent processing can be skipped.
In step 6, we transpose the captured PTVs back into a list of SRVs. This is done
by examining each receiving cell location in the captured PTVs and building the
associated SRVs from least to most significant bits. When this is done, we know
what each receiving cell observed (its SRV) during the test. In step 7, we act upon
any case where a receiving cell’s SRV does not match the designated driver’s STV.
This indicates an interconnect failure.

27
The “order” of a problem’s complexity identifies how that complexity grows with the size of
problem variables. The equations given here are not exact because of various assumptions, but do
show you how to estimate the behavior of a problem that is twice as big, for example.
132 3 Boundary-Scan Testing

3.2.2.3 Aliasing and Confounding

We diagnose failures by examining the SRVs that are incorrect and by trying to
decide what could have caused the discrepancies. In many logic families, an open
will be interpreted by a receiving pin as a constant “1” or “0”. If an SRV were all
“1”s or “0”s, we might suspect an open, but there could also be a short of that node
to a fixed signal such as Ground or Power. In some logic families, two shorted driv-
ers will perform a Wire-AND function. Other logic families may see Wire-ORs. In
logic families where drivers have varying strengths for “0” and “1” (for example,
CMOS) it may not be possible in general to predict the result of a short; we call this
a Wire-X function. Now if two Wire-AND nodes were shorted, then the SRVs of all
the related Boundary-Scan receivers would be identical and would be the bitwise
AND of the two STVs of the designated drivers. It would seem a straightforward
process to write a diagnostic report for this short. But, depending on how the STVs
were chosen, a precise diagnosis might be frustrated by aliasing.
Aliasing occurs when the combined failures of two or more nodes results in an
SRV (seen at a receiver) matching the STV (assigned to the designated driver) of yet
another node. For example, if nodes B and C shown in Table 3.3 were shorted
(assume Wire-AND), the resulting SRVs captured on these nodes (0001) is the same
as the STV for node A. Does this indicate a short to node A as well? Aliasing leaves
us with this ambiguity: two (or more) nodes are known to be shorted, but another
correctly operating node is also suspect.
Similarly, if nodes D and E were also shorted, the resulting SRVs captured on
these node receivers (0001) would also indicate a short to node A (0001). This phe-
nomenon is known as confounding; we cannot determine if there is one short or two
shorts, and whether A is part of the short in either case.
Aliasing and confounding do not harm the ability of 1149.1 interconnect testing
to detect shorts, but complicate the diagnosis of shorts. This complication can be an
irritation during the actual repair of the board. In the example above, nodes B and C
are definitely shorted together; we just are not sure if node A is also involved. Since
solder problems are the main cause of shorts, we would visit each pin destination of
nodes B and C and inspect the solder at each location for a short. One or more of
these locations may also be adjacent to a pin belonging to node A, the aliased node.
If a solder defect were found, we would repair it. For the price of inspecting all the
destinations of B and C, we can discover any short to A as well if one should exist.
Since repair is a manual process anyway, this bit of extra care is not a bad investment.

Table 3.3 Sequential test vectors for a set of nodes.

The rows are STVs and the columns are PTVs
A 0 0 0 1
B 0 0 1 1
C 0 1 0 1
D 1 0 1 1
E 0 1 0 1
3.2 Testing with Boundary-Scan Chains 133

A key assumption here is that the destination pins of each node are indeed visible for
inspection.28 In the case that some are not, then a simple electrical continuity test
from node A to either of nodes B or C will tell if a short to node A is also present. It
is also possible to use X-Y coordinate data of all the pins of the three nodes to see if
any adjacencies exist that could be the site of a short.
If your goal is to reduce the probability of aliasing and confounding so that the
repair process is as straightforward as possible, the price you must pay is that of a
longer test. We have seen two extremes of tests: the counting sequence, which will
often exhibit aliasing; and the walking bit test, which is virtually immune. We have
also seen a dramatic difference in the length of the two tests with the walking bit
approach producing tests of breathtaking proportions. Jarwala [Jarw89] and Yau
[Yau89] show how to construct tests of varying sizes such that the aliasing probabil-
ity can be traded for test size.
Another tradeoff must also be considered; that of the probability of damaging
components by applying power to shorted drivers versus some convenience during
the repair process. This is not a trivial matter. One proposed diagnostic procedure
uses an adaptive process. First run a brief (that is, alias-prone) test to produce a rela-
tively compact list of shorted nodes and their aliases. Then, construct a new test (like
a walking-bit test) for the compact list of nodes and run this to produce the final
diagnosis. The assumption is that since the list of suspect nodes is compact, the new
test will be compact as well. However, the duration of time for this process will not
be small, since the new test must be calculated on-the-fly with data from the first test.
A more frightening problem with the adaptive process comes from an analysis of
a key assumption in the Yau-Jarwala work; that shorts always have wired-AND,
wired-OR or strong-driver behavior with known and deterministic results. If this
deterministic assumption is ever violated by a real fault,29 then we are using adap-
tion in an unpredictable or unrepeatable environment. Imagine, during test develop-
ment, that you are trying to debug a “flaky” test and that the adaption process
behaves differently on each application of the test! This will make debug very inter-
esting indeed. If the problem is not seen during test preparation (very likely since
tests are not validated against the myriad possible failure combinations), then it will
wait until production testing to appear.
If we decide that the problems with an adaptive process are too severe, that
leaves us with a preset test that should be as brief as possible and yield good diag-
noses with little irritation due to aliasing. The “preset” requirement means the test
never changes, which is a great help during debugging. The “brief” requirement

28
Inspection can be done with the human eye, or with an automated inspection system. With the
increasing use of Ball-Grid Array (BGA) packaging, optical visual inspection is giving way to
X-Ray laminographic inspection, a technology that can see through most optically opaque objects
and make quantitative measurements of solder quality in three dimensions.
29
Consider a short between three drivers of varying strengths, none overwhelming. Then consider
the eight combinations of data they may have during the test. Next consider that each receiver of
the combined nodes will interpret voltages as one or zero differently, particularly if there is any
hysteresis at work. This example, entirely common, should give you concern about “simplifying”
assumptions.
134 3 Boundary-Scan Testing

Table 3.4 A set of test PTVs (the columns) for interconnect test. (The Notes are explained in the text)
Node Note 1 Note 2 Note 3 Note 4
A 0 1 1 1 0 0 0
B 0 1 1 0 0 0 1
C 0 1 0 1 0 1 0
D 0 1 0 0 0 1 1
N 0 1 1 1 1 0 1

suggests that a counting sequence test be the basis of the test, while the “good
diagnoses” and “little aliasing” requirements suggest that we augment the counting
sequence with additional tests (PTVs).
Table 3.4 shows such an augmented counting sequence test. The column labeled
Note 1 heads a PTV that places all nodes at “0”. Note 2 heads a PTV that places all
nodes at “1”. Shorted nodes will never cause a driver conflict in either of these two
PTVs, so both the “0” and the “1” will be conserved in the SRVs for these PTVs for
any shorted signal nodes. This means we can differentiate an open (or a Power/
Ground short) that causes a constant SRV (all 1 s or 0 s) from any other short. Note
4 heads three columns that are a binary counting sequence, known to be brief, but
also prone to aliasing.
Note 3 heads two columns in the table. These two columns are complements of
the rightmost two columns from the binary counting sequence. These are anti-
aliasing PTVs. A full set of anti-aliasing PTVs would consist of adding the comple-
ment of the complete binary counting sequence, which in this case, is the complement
of the last three columns [Wagn87, Jarw89]. Adding less than the full set represents
a compromise; fewer PTVs but more chance of aliasing. The advantage of this
approach is simplicity; we are not using any knowledge of driver performance30 or,
the circuit topology or any complex analysis to create anti-aliasing PTVs. We just
complement a subset of the counting PTVs, starting with the least significant bits
(that change the most). Adding more such PTVs increases the length of the test, but
reduces the chance of aliasing.
Practical testing experience has shown that the test selection approach illustrated
by Table 3.4 gives good diagnostic resolution for shorted signals, good resolution of
Power/Ground shorts, rarely produces aliasing, is quite brief, and is deterministic.

3.2.2.4 Interconnect Opens Test

Once we have tested the Boundary-Scan interconnect using the counting sequence
style of approach, we have detected any short between these interconnects and have
also discovered many of the possible opens as well. However, if there are nodes with
multiple drivers, then we know that only the designated driver for each such node

30
This knowledge may be inaccessible to the test engineer.
3.2 Testing with Boundary-Scan Chains 135

CU
U1 A U1
C U

Off
C U
CU
U3
On
C U CU

U2
CU
U4
On U2
C U CU C U

CU

U3 On
CU
C U
Off Undetected
C U Open
Undetected
Open B
U1 On C
CU

C U

On U2
CU C U

Undetectable
Open
BusOpens

Fig. 3.12 Three examples of bus wire driver opens not detected by interconnect shorts test

has been verified for opens. The others were never activated,31 so we have not tested
for opens on them. We need to do an interconnect opens test that will finish the job.
Figure 3.12a shows the basic configuration used during interconnect shorts test-
ing. There you see three ICs that drive the node and one that receives. U2 was arbi-
trarily chosen to be the designated driver during interconnect shorts test, but that
leaves both U1 and U3 untested for driver opens.

31
In some cases these other drivers may actually be part of a bidirectional pin structure. In this
case, the receiving Boundary Cell was tested, so the solder must be good. However, since we have
never turned on the driver, we still do not know if there is any problem with it.
136 3 Boundary-Scan Testing

11
CU
12
13

U1 U2

TDI

8
CU
9
10

U3 U4

TDO
IntcMDvr

Fig. 3.13 Control cell fanout combined with board topology that results in undetected opens

Figure 3.12b shows a case where there are two ICs, U1 and U2, both activated to
drive the bus during interconnect shorts testing. In other words, we could not desig-
nate a single driver for this node. This is necessary because the control cell that
turns on the driver in one IC fans out to other drivers (in the same IC) that must also
be turned on to perform interconnect shorts test. Each masks a problem that might
exist with the other and introduces the requirement that both data cells must be
loaded with matching data to prevent drive conflicts.
Figure 3.12c shows an example of two drivers ganged together to increase drive
current. Solitary opens on either driver cannot be detected using Boundary-Scan,
unless of course the DC loading is such that one driver cannot create proper
logic levels.
The situation in Fig. 3.12b is caused by control cell fanout to multiple drivers
combined with board-level topology that requires two or more drivers to be turned on
at the same time. Figure 3.13 shows a simple case of this; pins 11, 12 and 13 of com-
ponent U1 must be turned on to detect shorts between their nodes. Pins 11 and 12 are
also bussed drivers. Down in U3, pin 10 must be turned on as well or its node would
not be tested for shorts. When this is done, we also have pins 8 and 9 turned on as
well, causing multiple designated drivers to exist for their nodes potentially masking
opens. Thus, when bus wires exist on a board, it is likely that conditions exist where
the interconnect shorts testing process will not completely test for opens.
3.2 Testing with Boundary-Scan Chains 137

10 A 7
9 B 6
C
8 5

U1 U2

TDI Two Bussed Wires

A
10 7
B
9 6
D
8 5

U3 U4

TDO
Intc2Bus

Fig. 3.14 Parallel testing of two bussed nodes

Table 3.5 Parallel test Component and pin Node Bit pattern
data for two bussed nodes
U1.10 (driver) A 01 ZZ
U3.10 A ZZ 01
U1.9 B 01 ZZ
U3.9 B ZZ 01
U2.6 (receiver) B 01 01
U2.7 A 01 01
U4.6 B 01 01
U4.7 A 01 01

If we had a single bussed wire with N drivers we could test it very simply with
2*N PTVs, N pairs that turn on just one driver and set it to “0” and “1”
successively.32
Figure 3.14 shows an example of a board topology where two bussed wires
marked A and B exist side by side. These two wires each have two drivers, but we
can test them in parallel as before with N equal to 2. This is shown in Table 3.5.

32
All receivers, including those within bidirectional structures that are not driving, should be
checked to ensure the correct driver data is received from the node.
138 3 Boundary-Scan Testing

In this example, nodes A and B are driven simultaneously, first from component
U1, then from component U3. The bit patterns show either “01” for two PTVs
driven by a pin, or “ZZ” for two PTVs where a pin is disabled. The SRVs seen at
each receiver are “0101”. Nodes C and D are not tested (meaning their SRVs are not
examined) because they were already tested by interconnect shorts test.
Figure 3.15 shows a case where four bus nodes A, B, C and D exist with two
drivers for nodes A, C, and D and three for node B. These, too, can be tested in par-
allel, but with N equal to 3, the maximum size of any one bus. Table 3.6 shows the
data for this case. When a node is not driven for a PTV which occurs on nodes A, C,
and D, then the SRVs in these cases are “XX” as shown, indicating a “don’t care.”
In either case just shown in Figs. 3.14 and 3.15, the fanned-out, control cell
structure that we saw in Fig. 3.13 could be present as well. This influences how we
choose which drivers to turn on at the same time. Obviously, if the same control cell

10 A 7
9 B 6
C
8 5

U1 U2

TDI

Nodes A, C and D
have 2 Drivers
6
Node B has 3 Drivers
5
4

U5

A
10 7
B
9 6
D
8 5

U3 U4

TDO
Intc3Bus

Fig. 3.15 A case where four buses containing different numbers of drivers are tested in parallel
3.2 Testing with Boundary-Scan Chains 139

Table 3.6 Test data required for bus wires with different numbers of drivers
Component and pin Node Bit pattern
U1.10 (driver) A 01 ZZ ZZ
U3.10 A ZZ 01 ZZ
U1.9 B 01 ZZ ZZ
U5.5 B ZZ 01 ZZ
U3.9 B ZZ ZZ 01
U1.8 C 01 ZZ ZZ
U5.6 C ZZ 01 ZZ
U5.4 D 01 ZZ ZZ
U3.8 D ZZ 01 ZZ
U2.7 (receiver) A 01 01 XX
U2.6 B 01 01 01
U2.5 C 01 01 XX
U4.7 A 01 01 XX
U4.6 B 01 01 01
U4.5 D 01 01 XX

enables two drivers, they must be enabled or disabled simultaneously.33 As shown

in Table 3.6 we choose to test all the drivers in an IC in parallel while the other ICs
are disabled. We call this process “choosing a designated IC” rather than just a des-
ignated driver.

3.2.3 Connection Tests

Connection tests are similar to In-Circuit Boundary-Scan tests. They test the con-
nectivity of nailed nodes to Boundary-Scan components. The circuit in Fig. 3.16
shows an example of several ICs that have nailed connections in need of testing.
This circuit has a number of nodes and Boundary-Scan pins that cannot be tested
with any of the typical Boundary-Scan interconnect tests. These nodes may come
from edge-connector pins or may be those that cross between the Boundary-Scan
portion of the design to the conventional portion. A connection test utilizes the tester
resources available on such nodes to test that the Boundary-Scan IC is connected to
those nodes. One, several, or all IC pins may be tested this way.
A connection test is relatively easy to do. It only looks for opens, since shorts
between the nodes it is testing are already detected by a preceding, unpowered shorts
test that should be performed on all tester nails before applying power to the board.
Two PTVs that drive all inputs (and bidirectionals acting as inputs) are first run to

33
Supplement A [IEEE93] to the Standard makes it a firm rule that drivers that are controlled by
the same control cell must respond identically to the value loaded into that cell. The original stan-
dard allowed them to be different, causing obvious problems for test algorithms.
140 3 Boundary-Scan Testing

U1 U2

TDI

U3 U4

TDO
ConnTest

Fig. 3.16 A circuit where not all Boundary-Scan pins can be tested via interconnect test

see that each can receive a “1” and a “0”. Then two more PTVs are used that cause
each output (and each bidirectional acting as an output) to drive a “1” and a “0”. The
tester can directly see failing output pins, and can correlate failing TDO bits with
faulted input pins.
It is common for some component inputs to be tied to fixed “0” or “1” signals
(often Power or Ground). By noting which pins are fixed, we can also verify that
these inputs are always capturing constant “0”s or “1”s.
It is possible to perform connection tests on several ICs in parallel, but this will
require more parallel and independent tester resources. By testing the ICs in sepa-
rate tests, we can multiplex and reuse these resources. Indeed, if one IC were par-
ticularly large and had many connections to test, we could choose to test portions of
these connections in separate tests. This allows us to save on tester resources and
lower the cost of the tester.
3.2 Testing with Boundary-Scan Chains 141

U3 A
1
B
2
C 3

D
U1 4 U2

TDI R1 TDO

C1

InterAct

Fig. 3.17 Example of potential interactions between a Boundary-Scan node and two non-scanned
nodes

3.2.4 Interaction Tests

Most literature on Boundary-Scan discusses interconnect testing as if all nodes were

connected to 1149.1 components. In reality, especially in the early days of the
Standard, full Boundary-Scan implementations are an exception rather than a rule.
Not all digital components have Boundary-Scan. Since shorts do not show a prefer-
ence, a Boundary-Scan node could be shorted to a non-scan node. These interac-
tions can cause some special testing problems [Robi90].
Figure 3.17 shows a simple example of potential interactions between a
Boundary-Scan node B and two non-scanned nodes A and C, which are connected
to physically adjacent pins and thus, prone to shorting. Here, node B is a simple
Boundary-Scan node driven by U1 and received by U2. Node A is driven by con-
ventional component U3. Node C is a digital node with an intervening analog filter.
If we assume that there are no In-Circuit nails available for these nodes, then it
might be difficult to test for shorts between nodes A, B and C. If the driver in U3 is
strong enough to interfere with the operation of node B and it is enabled, we could
see a failure on node B during interconnect testing. Node C might not have enough
current source/sink capability to interfere with the operation of node B. If so, a short
from node C to B might not be visible during testing.
If we have limited nail access, we should first spend one nail on node C. This
allows our ATE system to place a strong34 and deterministic value on node C that
will definitely interfere with node B in the case of a short. This leaves node A; we
could place a nail on it, or, perhaps we can more easily gain control of the inputs to

34
The ATE driver must be strong enough to overdrive node C and node B simultaneously.
142 3 Boundary-Scan Testing

U3 A
1
B
5 2
C 3
6
D
U1 7 4 U2
E
TDI TDO
F 8 9

U4
InterAct2

Fig. 3.18 Boundary-Scan nodes B and C that can interact (by shorting) with nodes A, D or F

U3. In either case, the goal is to set up a condition where node A will definitely
interfere with node B if a short is present.
Once we have ATE resources available35 to set up interference, we can run a
standard, interconnect shorts test. We can use our ATE drivers to freeze the values
of the non-scanned nodes A and C during Capture-DR when any interference will
be captured in the Boundary Register receiver cells. The ATE drivers can be turned
off at other times to minimize overdrive stress on upstream IC drivers. We can
choose static values to place on the ATE drivers, or, as suggested in [Robi90] we
could assign each ATE driver a unique counting sequence number as we have done
with the Boundary-Scan nodes. This way, any Boundary Register receiver seeing
one of these SRVs corresponding to an STV assigned to an ATE driver will readily
identify the non-scanned node involved in a short. The approach chosen will be
influenced by our concern over how many (expensive) ATE drivers we wish to have
running in parallel versus running the test several times with multiplexed resources.
A somewhat different approach to this problem is given in [USP93]. Again the
idea is to use ATE resources to create strong values on neighboring non-scan nodes
and then see if these values appear on Boundary-Scan nodes. The drawing in
Fig. 3.18 shows an example board topology.
Here we set up a Boundary-Scan test with only two PTVs, one that drives all
Boundary-Scan nodes (in this case nodes B and C) to “0” and a second that drives
them all to “1”. Thus, while we are performing this interaction test, if there are any
other shorts between Boundary-Scan nodes themselves, they will not be excited and
therefore are unable to cause driver damage or confuse the ultimate diagnosis.

35
Note that this could be a large number of expensive resources if there are many locations on a
board where interactions are likely. This introduces the problem of managing these resources (for
example, by multiplexing) so that our tester costs are not driven too high.
3.2 Testing with Boundary-Scan Chains 143

Next, while these two PTVs are being driven, we use our ATE drivers to create
the opposite states (“1” and then “0”) on only the adjacent non-scan nodes, in this
case nodes A, D and F. This ATE drive condition need only exist for the length of
time the chain of devices is in the Capture-DR state.
Figure 3.18 shows some situations that need further discussion. Node A is being
tested because it is adjacent to node B, a Boundary-Scan node. This adjacency rela-
tionship can be determined two ways; first, by examining the X-Y board location
data for every pin (in this case, pins 1 and 2 of U2) we can determine the distance
between any two pins. If this distance is less than a predetermined shorting radius,
then we will include the related nodes in our interaction test. The shorting radius is
chosen by our experience with solder shorts such that two pins beyond this radius
have little probability of ever being spanned by solder short. Second, if we do not
have board X-Y location data, we can infer adjacency by looking at device pin num-
bers. Here we assume that pin 1 is adjacent to pin 2, but not adjacent to pins 3 or 4.
This second method is certainly less satisfactory since on a pin-grid array device, we
may not know that pins A3 and B5 are adjacent. Numerical adjacency may also cause
us to test nodes that X-Y data would have told us are beyond the shorting radius.
Figure 3.18 also shows us that Boundary-Scan node C is adjacent to nailed node
D. We can test node D, even though it is a TDO-to-TDI connection. This is because
we only overdrive node D with our ATE driver when the chain is in the Capture-DR
state. Because TDO is unused and disabled during this time, we are able to do this.
This could detect a short from TDO to some other signal that was disabled during
other forms of Boundary-Scan testing including chain integrity testing.
Next note that we can check for a short between nodes B and F which are adja-
cent at device U4, pins 8 and 9. (Also note that node E will have to be controlled by
an ATE driver so that the output driver in U4 is disabled during testing.) Now ask
the question, what if Boundary-Scan node B is shorted to both node A and node F
at the same time? The test will fail, but which nodes do we diagnose? This can be
solved by noting that nodes A and F are adjacent to the same Boundary-Scan node
and should be tested at by the same algorithm, but at separate times. This temporal
splitting resolves the ambiguity.
The circuit in Fig. 3.18 can thus be tested with two applications of our Boundary-
Scan test; the ATE drivers drive nodes A and D in the first application and then drive
node F in the second. If a failure36 is observed in the first test application, we can say
without ambiguity which node(s) failed since they will affect independent Boundary-
Scan nodes. If the second test application fails, we know that it had to be node
F. Multiple applications also allow us to re-use expensive ATE resources in succes-
sive applications, if they are multiplexed. Finally, it is possible when producing the

36
Note, a failure here is defined as the opposite state being observed on the Boundary-Scan node
for both the expected “0” and “1” states. This helps us prevent other problems (for example, an
open solder joint on a receiver) from confusing the diagnosis.
144 3 Boundary-Scan Testing

diagnostic report, to report the adjacent pins37 of the shorted nodes. These pins are
the probable location of the short, so we are now getting a pin-level diagnostic for a
shorts test that tests nodes.

3.2.5 Capacitive Opens Tests

Capacitive opens testing uses a capacitive sense plate mounted over a DUT to sense
the presence of an AC signal provided by the tester. The very attractive property of
this type of testing is that it can test for open circuit connections on passive compo-
nents such as vacant connectors. A Boundary-Scan subsidiary standard called 1149.8.1
has been developed to support such testing. See Chap. 10 for a complete discussion.

3.2.6 BIST and Custom Tests

We can perform other tests with Boundary-Scan component chains. For example, if
several components have the RUNBIST capability, we can load all of them with
RUNBIST (and the rest with BYPASS) and in principle,38 have them all execute
their self-tests in parallel. We put the chain in Run-Test/Idle and clock it for the
maximum number of clocks that any of the components require. All those receiving
more clocks than necessary will retain their self-test result. After clocking is done,
we proceed down the data column of the TAP diagram to Shift-DR where the self-
test results are shifted out for examination.
User-defined instructions may be accessed to set up tests for internal portions of
components, or to set up tests between cooperating components. For example, the
Texas Instruments SCOPE Octal ICs [Texa91a, Texa91b] can be made to cooperate
for testing circuitry and interconnect between them as shown in Fig. 3.19. One such
IC (U1) can have its Boundary Register drivers create pseudo-random patterns
while being clocked in Run-Test/Idle. A cooperating IC (U2) can be set up as a
Linear Feedback Shift Register (LFSR) to capture a test signature in its Boundary
Register input cells. The intervening data path is thus tested with random patterns
with the resulting data undergoing signature analysis compaction [Nadi77]. The
compacted signature can then be read out and compared against a known-good sig-
nature. (The known-good signature could be “learned” by exercising this test on a
known-good board.) One point to note, if the signature received is not good, that
indicates a failure of the data path but gives no detailed diagnostic information.

37
The use of pin adjacency data, integrated with knowledge of the workings of a test algorithm, can
be used to enhance the diagnosis in other cases, such as standard Boundary-Scan interconnection
tests. Again, the assumption is that shorts and opens are likely to be caused by solder defects, so
the diagnostic reports should use the words “probably located at”.
38
This parallel operation may not be possible if the allowable variations in how the ICs are clocked
are not mutually compatible.
3.3 Porting Boundary-Scan Tests 145

Data
Path
Logic

U1 U2

TDI TDO
DataPath

Fig. 3.19 Two cooperating components provide stimulus vectors and capture a signature response
for data path logic

3.3 Porting Boundary-Scan Tests

The question sometimes arises, “Can I port a Boundary-Scan test from one applica-
tion to another?” This usually happens when someone creates a Boundary-Scan test
in one setting (say for example, prototype debug) and now wants to run this test in
another (say, production test). The answer is “yes”, but there is a new and rather
exciting opportunity here that many people miss. To see this, consider the historical
root of this question.
Before Boundary-Scan came about, people had to construct digital tests (typi-
cally, for individual ICs) manually39 with a great deal of engineering sweat. It could
take weeks or even months for larger, more complex ICs. Naturally, after expending
this much talent and time, if the test was to be used in a new context (say, ported
from an IC production tester to an In-Circuit board tester) the difficulties in porting
this test were usually much less than redeveloping the test from scratch. This recog-
nizes there is a great deal of intellectual value embedded in the test vectors.
Figure 3.20 shows how one might manually develop a digital test for several similar
applications. The key thing to note here is that both the test creation effort and each
debug/porting effort may be an exhaustive process.
This model for developing and porting test vectors has been around for a long
time, even creating its own industry. It is natural at first, to imagine that you would
want to use the same model with Boundary-Scan tests. However, there are impor-
tant differences with Boundary-Scan tests that make this approach wasteful and
even counterproductive. Figure 3.21 shows how Boundary-Scan tests are developed
for similar applications.

39
Automated test generation for general ICs is fairly youthful, and it tends to generate tests of hor-
rific size, unsuited for board/system test purposes.
146 3 Boundary-Scan Testing

Gather Data
Debug and Debug and
Manually
Release for Release for
Analyse Create Test
Application A Application B
IC in Depth

PortTest

Fig. 3.20 Developing and porting a manually generated test for similar applications

Debug and
ATPG for
Release for
Application A
Application A
Gather Data

BSDL and
Netlist
Debug and
ATPG for
Release for
Application B
Application B

PortData

Fig. 3.21 Developing a Boundary-Scan test for similar applications

With Boundary-Scan you have Automatic Test Program Generation (ATPG) soft-
ware that actually generates test vectors and diagnostic information used by that same
test when it is executed. The ATPG software should be able to generate the entire test
in a time frame measured in seconds rather than weeks. This is the first major differ-
ence. The second comes from the realization that the manually generated test does not
have diagnostic information accompanying it. It is essentially a go/no-go test. When
it fails, you typically get a report that says something like “Output pins 38, 39, 44
failed at test vector 19287”. For this same example, a Boundary-Scan test will give a
much more thorough diagnostic that can include input pin diagnostics.40
If at all possible, when porting a Boundary-Scan test, you should not port the test
vectors, but rather, port the basic information of the device(s) participating in the
test and the structure of their interconnect. This amounts to porting the BSDL and
netlist information for most applications. Then the ATPG software used by a given

40
When an In-Circuit test for a non-scan IC fails, we can only report what we see failing, not what
might be the cause of the failure, unless we have used an extensive simulation that can provide this
correlation. This will add additional time to the test development process if indeed it is practical at
all. Further, the assumptions used by the simulation model may cause improper diagnoses.
3.4 Boundary-Scan Test Coverage 147

application can (in a few seconds) construct a test optimized for that application,
complete with sophisticated diagnostics. If instead, you port a Boundary-Scan test
the old way by translating its vectors, you will find that it will lose its diagnostic
capabilities, resulting in a go/no-go test only.
There is a language called Serial Vector Format (SVF) that is being maintained
by Asset Intertech Inc.41 This language can be used to port vectors among applica-
tions, although with the problems mentioned above. This language will allow the
porting of (many) Boundary-Scan tests and also has the advantage of being
comparatively terse and thus frugal with disc space.42
An objection sometimes heard about SVF is that it can only describe a subset of
legal 1149.1 state transition sequences. For example, the compliance verification
test sequence given in Sect. 5.1.10 (page 195) cannot be expressed in SVF. This type
of test, in places, will specify a precise trajectory through the state diagram. This is
where SVF, in the interest of being terse, breaks down. It cannot specify all legal
transitions. So beware that using SVF will first convert your full-featured diagnostic
test into a go/no-go test, and that it may modify the state transition sequences in
your tests to fit the limitations of the language.

3.4 Boundary-Scan Test Coverage

The collection of Boundary-Scan shorts, opens and interaction tests, taken together,
can provide very good defect coverage for a board. Of course, those parts of a board
not addressed by Boundary-Scan, such as the analog and mixed signal portions as
well as digital components without Boundary-Scan must still be addressed, and this
is where conventional board test ATE will still shine.
The paper [Hird02] gives a concise definition of defect coverage and shows how
to actually measure the coverage of board tests. This is done by aggregating the
coverage of all the “smaller” tests that make up a full board test. This paper shows
how to enumerate a set of potential defects (called the “Defect Universe”) and then
how to measure the effectiveness of each test against this set. This is done by answer-
ing the question “What does it mean when this test passes?”. A simple example
illustrates this. Consider the simple resistor, accessed with nails, shown in Fig. 3.22.
Fig. 3.22 A simple In-Circuit test of resistor RAn In-Circuit test will literally measure
the value of resistor R. In so doing, when the test passes, you then know the resistor
must be present, must be the correct value, must be basically “live” and its pins can-
not be open or shorted together.43

41
Try the site map at www.asset-intertech.com to find specifications for Serial Vector Format.
42
This terseness also means that it is highly unreadable by humans, so don’t expect to debug a test
written in SVF. It is advised that only mature, fully debugged tests be converted to SVF.
43
These are five of the eight properties that make up the “PCOLA/SOQ” model of [Hird02]. The
orientation property is a “don’t care” for resistors (they are unpolarized). The two remaining prop-
erties (alignment and joint quality) cannot be measured by electrical tests including those provided
by Boundary-Scan.
148 3 Boundary-Scan Testing

If this same resistor has no nail access, but it is used as a series termination resis-
tor between two Boundary-Scan device pins where one is driving and the other is
receiving, then a Boundary-Scan interconnection test will also answer certain ques-
tions about the resistor when it passes. In such case, the resistor must be present,
must be basically “live” and its pins cannot be open. Note the correct resistor value
and a short across its pins cannot be tested. So Boundary-Scan, not generally con-
sidered an “analog” test, can actually provide significant test coverage for such
components. See also [Park03] for test coverage of Boundary-Scan tests using the
“PCOLA/SOQ” defect model.

3.5 Summary

To conclude, we have seen in detail how the 1149.1 architecture can be used to
implement IC, board-level and system-level tests. There is more that can be done;
this is the subject of the next chapter on advanced Boundary-Scan topics.
This chapter has highlighted some of the practical issues seen when attempting
to do Boundary-Scan tests on real boards and systems. For example, the fanout of
control cells to driver enables on-chip will interact with board-level interconnection
topologies to create particular cases of faults that need special attention during test.
Boundary-Scan tests taken as a whole, along with supplemental tests tradition-
ally performed by board test ATE, can provide very respectable test coverage for
board defects. This is true even when traditional bed-of-nails access is much less
than 100 %. But most importantly, Boundary-Scan tests can often be created com-
pletely automatically from board construction data and BSDL information, without
need of time-consuming debugging.
Chapter 4
Advanced Boundary-Scan Topics

As this book goes to press, the 1149.1 Standard is in its 25th year of existence.
Chapter 3 discussed the most basic and general uses of the Standard. This chapter
will examine some other uses that have been proposed or have been implemented in
some quarters.
Some of these advanced uses are clearly devoted to testing. For example, indi-
vidual ICs can be tested during production for DC parametric performance (see
Sect. 4.1). A system can be unobtrusively observed during its operation using
Sample Mode test (see Sects. 4.2 and 4.3). Devices that do not themselves contain
Boundary-Scan can be tested by surrounding Boundary-Scan devices (see Sects. 4.4
and 4.5). Multi-Chip Modules (MCM) and other packaging hierarchies can be
tested (see Sect. 4.7).
However, some of these topics, such as firmware development support (see
Sect. 4.8) and In-System Configuration (see Sect. 4.9) are examples of applications
that are not obviously aimed at testing. Indeed they show how 1149.1 may add value
to a system beyond the realm of testing, which makes Boundary-Scan appeal to a
wider audience. Even now, the promise for new applications is still strong.

4.1 DC Parametric IC Tests

Most of the attention paid to Integrated Circuit test is focused on the testing of the logic;
does the circuit meet its logical function? Yet there is another realm that is also critical,
that of ensuring an IC’s DC parameters are within specification. Some of these are:
• Input voltage levels; verify that a range of voltages appearing on an input are
perceived by the IC as logic “0” or logic “1”. These parameters are termed VIL
(voltage, input low) and VIH respectively.
• Output voltage levels; verify that voltages produced on outputs are within speci-
fications for logic “0” and logic “1”. These parameters are termed VOL (voltage,
output low) and VOH respectively.

© Springer International Publishing Switzerland 2016 149

K.P. Parker, The Boundary-Scan Handbook, DOI 10.1007/978-3-319-01174-5_4
150 4 Advanced Boundary-Scan Topics

Interface Wiring

Analog Subsystem
Relays

System Circuitry

Precision
Programmable
Measurement
Load
Bypass Unit (PMU)

Instruction
TAP
Controller
TDI TDO
TCK
TMS PMeasure

Fig. 4.1 The analog testing subsystem of an IC tester is used to switch load and test resources to
measure analog parametric properties of an IC

• Output current drive; verify that an IC output, while producing a valid voltage
for logic “0” or logic “1” is able to sink or source a rated current. These param-
eters are termed IOL (current, output low) or IOH respectively.
• Disabled output leakage; verify that an IC output, when disabled, has a leakage
current IOFF within specification.
Testing for these parameters may need voltage or current measurements, often
requiring the provision of specific DC loading while the measurement is taken. IC
testers containing analog test subsystems such as shown in Fig. 4.1, routinely per-
form these tests on ICs at wafer test or package test as appropriate. These parame-
ters are typically not tested any other time.
A difficulty is that some of these parameters relate to specific conditions at out-
put pins. These conditions, like driving an output high, low or disabling it, require
us to coax the internal logic of the component into setting them up for us. If the IC
is complex, it can take a lot of work to set up these conditions. Sensitive current
measurements, particularly for small currents seen during leakage tests, may take
significant time on the order of (say) milliseconds. If a component contains dynamic
logic, millisecond measurements could exceed the ability of the logic to retain its
state without some (noisy) keep-alive sequencing being supplied to it.
Testing parameters such as VIL and VIH can also be difficult to set up. In essence,
stimulus to the IC logic is supplied using marginal voltages for these parameters and
if the outputs behave improperly, the test fails. It may be difficult to interpret the
result into a diagnostic indicting specific input pins.
4.2 Sample Mode Tests 151

Boundary-Scan ICs can avoid many of these difficulties since the Boundary-
Scan facility has direct control of IC outputs and can observe IC inputs.1 For exam-
ple, it is a simple matter (using HIGHZ or EXTEST instructions) to turn off output
drivers for IOFF measurements. In principle, using 1149.1 it should be possible to
completely automate the development of many DC parametric IC tests that today
require much tedious engineering to prepare. This automation will be immediately
useful to ASIC foundries where the preparation of DC parametric tests for customer-
supplied IC designs is currently a challenge. Indeed, they may actually be able to
save their customers time and money because of 1149.12 rather than in spite of it.

4.2 Sample Mode Tests

The 1149.1 SAMPLE instruction is constructed to operate in Non-Invasive mode; it

will not disturb an operating component when it captures the values on its I/O pins
(and driver enables) and shifts out the sampled data. We can sample on many com-
ponents in a chain simultaneously, which offers the promise of implementing a
“logic analyzer” function through the 1149.1 port. For example, a microprocessor
address and data bus could be sampled as well as an upstream data buffer to see if
data associated with an address is arriving at the processor inputs. Some early work
in this area has been reported [Swee88, Lefe90].
Some practical problems exist with the SAMPLE function, having to do with the
coordination of the System Logic clock(s) and TCK. For a system consisting of a
collection of ICs, there are skews in the system clock distribution that have to be
accounted for along with the setup and hold times of the various clocked elements.
This can prove challenging for even a single clock. When we attempt to add a sec-
ond clock distribution path for TCK, we now must coordinate two independently
clocked state machines, the system logic of the board and the 1149.1 logic. When
the 1149.1 logic is operating Non-Invasively, the two state machines are completely
independent, except when the SAMPLE instruction is in effect. SAMPLE causes the
cells of the Boundary Registers to capture (sample) data appearing on the I/O pins
of the components, while these same pins are under control of the system clock.
Figure 4.2 shows two hypothetical flip-flops feeding data to each other. Below
the circuit diagram is a timing diagram for the circuit that shows the skews, setup
times, hold times and propagation delays that must be properly accounted for. In the
distribution of SYSCLK, skews are introduced into the resulting buffered3 clock

1
Warning! If an IC input pin is attached directly to a Boundary Register cell without an intervening
input buffer, then input parametric tests may prove that the Boundary Register works within DC
parametric limits, but not prove the same for the System Logic.
2
See also [Sunt02] for a discussion of how the 1149.4 standard (see Chap. 7) can be used to test IC
parametrics with very little access to IC pins.
3
Differences in the propagation delays of these buffers represent a source of skew for this example.
Another source of skew is simply the wiring that distributes the clock signals. On boards, ICs may
be widely separated so that differences in path lengths may be significant.
152 4 Advanced Boundary-Scan Topics

D Q
Q1 D Q
Q2
CK1 CK
CK2 CK
SYSCLK

Skew1

SYSCLK

CK1

Valid Valid
Q1
thold1
tprop1 tsetup2

CK2
Skew2

Valid Valid
Q2
thold2 tprop2 tsetup1
1ClkSkew

Fig. 4.2 A simple circuit and its timing diagram showing setup and hold times, and the effects of
system clock skew

signals CK1 and CK2, shown as skew1 and skew2. When a rising edge occurs on
SYSCLK, both Q1 and Q2 retain their data for time thold1 and thold2, then become
unpredictable until times tprop1 and tprop2—the flip-flop propagation delays—
have expired. Then, to properly set up the data before the next SYSCLK occurs,
times tsetup1 and tsetup2 must be observed.
Now consider Fig. 4.3 where we have added TCK distribution to the same sim-
ple circuit where components 1 and 2 now have Boundary-Scan. SAMPLE mode is
driven by TCK and we now have an asynchronous sampling process going on in the
same ICs, driven by TCK.
We see the same timing diagram for the system operation of the flip-flops. Below
that is the timing for the operation of the Boundary-Scan SAMPLE function. There,
we see skews on TCK distribution. The two TAPs are slightly skewed as they pro-
ceed from Select-DR-Scan to Capture-DR. Once in Capture-DR, the next rising
edge of TCK will cause the data on Q1 and Q2 to be captured. What concerns us is
the relationship of the timing on Q1 and Q2 to the setup times of the Capture (CAP)
flip-flops. As shown in Fig. 4.3, there is not enough setup time for Q2 to be properly
sampled by TCK1.
4.2 Sample Mode Tests 153

D Q
Q1 D Q
Q2
CK1 CK
CK2 CK
SYSCLK TCK TCK
TCK1
TCK
TCK2
Skew1

SYSCLK

CK1

Valid Valid
Q1
thold1
tprop1 tsetup2

CK2
Skew2

Valid Valid
Q2
thold2 tprop2 tsetup1

SYSCLK to ! Setup Violation

TCK skew tck1 tsetup

TCK
TCK1 Skew
TCK1

TAP1 Select-DR-Scan Capture-DR

TCK2

TCK2 Skew tck2 tsetup

TAP2 Select-DR-Scan Capture-DR

2ClkSkew

Fig. 4.3 Simple circuit showing the relationships between the system clock and TCK during
SAMPLE operation

During SAMPLE mode, it is quite possible that the setup and hold time require-
ments of the Capture (CAP) flip-flops will be violated unless some careful measures
are taken. Now, because many newly designed digital systems are being clocked at
154 4 Advanced Boundary-Scan Topics

rates that already stress technological limits, this problem of controlling errors and
skews in two asynchronously operating clock systems is a real challenge.
One possible solution (that is often not possible without specific design effort)
involves interrupting the system clock very briefly while applying the critical TCK
that performs the data capture. This introduces the difficulty of interrupting a clock
without creating hazardous clock slivers. Also, there is a propensity for many new
components to be internally clocked with their own clocking subsystems that are
phase-locked to the board-level system clock. Phase-locked clocks cannot tolerate the
phase jitter that an interrupted system clock would inject. These challenges, though
not insurmountable, make SAMPLE mode testing much more difficult to implement.
An approach to solving this problem has been documented [Jose93] where a
special variant of the SAMPLE function was implemented. (It was given a new
name since it was not compliant with the 1149.1 SAMPLE definition.) This instruc-
tion effectively coordinates the capturing of data in Capture-DR with the system
clock, to control the timing problems shown above.

4.3 Concurrent Monitoring

Concurrent monitoring, proposed by Wagner and Williams, [Wagn91] utilizes the

1149.1 SAMPLE mode and pays special attention to the clocking problems dis-
cussed in Sect. 4.2. The technique uses the SAMPLE mode operation of 1149.1 in
conjunction with diagnostic procedures (for example, test microcode) in a coordi-
nated fashion to increase the fault coverage of the diagnostic procedures. In essence,
each scanned pin of the circuit can be sampled while diagnostics are running to
obtain much higher visibility into the circuit’s operation.
The basic concept, shown in Fig. 4.4, is to have the diagnostics set up conditions
of interest in the system then, in a controlled manner, sample the ICs’ I/O pins.
While the diagnostics continue, the sampled data can be shifted out and collected in
a signature collector, a multiple-input signature register (MISR)4 in this case. The
resulting signature is then compared against an expected-good signature calculated
by simulation or learned from a known-good board.
The paper offers a probabilistic argument for how this technique will improve
fault coverage. Intuitively, one can see how having hundreds of extra observation
points available by means of concurrent sampling can help detect faults that
may have been excited, but not propagated to a conventional observation point.
In the case of test microcode the observation point is the test-and-branch unit of the
test controller actually executing the microcode.

4
Note that this work [Wagn91] was not done with an 1149.1 compliant design although there is no
reason why it could not be as the authors point out. Locating the MISR that monitors several TDO
pins in an 1149.1 compliant component may be stretching the rules of the Standard.
4.4 Non-scan IC Testing 155

MISR
TDI

TDO
Concurnt

Fig. 4.4 Concurrent sampling of component I/Os during system diagnostics, with sampled data
compressed in a multiple-input signature analysis register (MISR)

4.4 Non-scan IC Testing

Boards will still contain non-scan ICs that require testing for the foreseeable future
[Hans89b, Park89]. Such a situation is shown in Fig. 4.5 where a non-scan device (U7)
is connected to some Boundary-Scan ICs and has some tester nail access as well.
The non-scan IC can be tested by placing scanned ICs U3 and U4 in EXTEST.
ICs U1 and U2 should be in BYPASS (or CLAMP or HIGHZ) to keep their contri-
bution to the shift chain as short as possible. ICs U3 and U4 will receive some of the
output data from U7 (at Capture-DR) and will supply some of the input data to U7
(at Update-DR). Physical nails will supply the rest of the stimulus or receive the
remaining IC output signals. We must coordinate our physical nail drivers with
Update-DR and look for IC outputs on our physical receivers at Capture-DR as in
Fig. 4.5. In this way, we can approximate fairly closely a simple unformatted “truth
table”5 test for U7 (Fig. 4.6).

5
This cannot hope to approach the timing accuracy that a tester with full nodal access can enjoy,
since some of our resources are controlled by Boundary-Scan resources through intervening TAPs
in several dispersed ICs. We do not have control of the skews and errors that these will introduce.
156 4 Advanced Boundary-Scan Topics

U1 U2

TDI

U7

U3 U4

SiNail TDO

Fig. 4.5 Testing a non-scan IC U7 with a combination of physical nails and Boundary-Scan pins

TCK

TAP
Update-DR Select-DR-Scan Capture-DR Shift-DR
State

BScan Drivers

BScan Receivers

Tester Nails Strobe Tester Receivers

Strobe Tester Drivers
SiNailTM

Fig. 4.6 A timing diagram that shows how Boundary-Scan resources must be coordinated with
the resources of a host ATE system
4.4 Non-scan IC Testing 157

Some problems with this approach do exist:

• If the component under test is not synchronizable and requires a homing
sequence,6 this will introduce considerable complication into the Boundary-Scan
scanning process, perhaps to the point of being impractical.
• A dynamic component may require a minimum test application rate that cannot
be achieved because of the length of the scan sequences.
• Serialization will greatly lengthen the overall test time, which could significantly
reduce throughput.
• A longer test has tester drivers overdriving upstream signals that may now be
liable to overdrive damage.
• If the original test was formatted, that is, it had waveform modulation imposed
on its logical data [Park87], this will vastly lengthen the test if it is translated
verbatim.
• There is the problem of undetectable shorts, as shown in Fig. 4.7.
Figure 4.7 shows a short between two Boundary-Scan drivers that creates a
Wired-AND of their data. The logic component they are to test also performs the
AND of these signals, so the output of the target component does not show a failure.
This short is not detectable, but it could degrade the lifetime of the drivers that it
affects so it may be of great concern. If the Boundary-Scan drivers are part of a
bidirectional construct, or are capable of monitoring their pad states (see Sect. 5.1.5
on page 191) during EXTEST, then this short can be detected.
These problems point out that while we could eliminate some test nails using this
technique, we can also create a new set of test concerns.

Undetectable
Short

U1 U2

TDI TDO
UndShort

Fig. 4.7 Shorted inputs on a NAND gate that may not be detectable when tested by ordinary
Boundary-Scan drivers

6
A homing sequence requires the tester to apply input patterns, examine component outputs, and
make decisions as to what patterns to apply next based on the observed outputs. If the outputs that
must be observed are only visible by means of the scan process, this greatly complicates the deci-
sion logic.
158 4 Advanced Boundary-Scan Topics

4.5 Non-digital Device Testing

Can Boundary-Scan resources be used to test non-digital devices? This question

could be asked when a circuit like that in Fig. 4.8 is to be tested. Here, resistor RT is
used to match the line impedance to eliminate nodal noise caused by signal reflec-
tions. In a DC sense, the node could perform perfectly even with the resistor miss-
ing. However its AC performance may not be adequate. Unfortunately,
Boundary-Scan interconnect testing is slow enough to be essentially a DC test.
We can test this resistor very simply with an analog measurement if we have a
tester nail on this node (and of course, on the power node too). If we do not, then we
will have to use some planned feature that we deliberately add to our Boundary-
Scan implementation to sense the existence (not necessarily the value) of resistor RT.
One approach might be to add a new instruction to the Boundary-Scan instruc-
tion decoder in U1 (we could call it “LEAK”) that causes a small current flow from
the driver pad to ground. We could then set up a test that turns off the driver enable
in the driving IC U1 and captures the value seen at the receiving IC U2. If the
pull-up resistor is in place, the receiving cell will see a “1”. If the resistor is missing,
the small current flow will cause a “0” to appear. Of course, a resistor with the
wrong value might not fail this test.
The point to be made is that the removal of nails from supposedly digital circuits
that are scanned may not be practical in many cases without some plan of attack for
all those analog components that are actually there but are logically invisible.

4.6 Mixed Digital/Analog Testing

Boundary-Scan is a digital testing technology. However, ICs do exist (and are

expected to become more common) that contain mixed digital/analog circuitry.
Mixed-signal testing is a difficult problem, but Boundary-Scan can again play a role
by adding the ability to partition the analog and digital portions of the circuit as

RT
C U

C U CU

U1 U2

T DI TDO
ParaTerm

Fig. 4.8 A Boundary-Scan testable node that has a termination resistor to eliminate noise
4.6 Mixed Digital/Analog Testing 159

Analog
Analog
Signals
Signals
Digital Analog
Core Core

Digital Digital
Signals Signals

TDI TDO
MixedSig

Fig. 4.9 A mixed digital/analog IC with the Boundary Register partitioning the digital from
the analog

shown in Fig. 4.9. (Note, mixed-signal ICs can also be implemented with 1149.4
technology as described in Chap. 7.)
By partitioning the digital logic from the analog circuitry with the Boundary
Register, it is possible to write tests that can check the digital portion of the compo-
nent directly. Further, one can set up digital values to stimulate the analog circuitry
directly for subsequent analog measurements.
One great benefit of this partitioning is that it can make tests for the digital logic
completely deterministic. Without Boundary-Scan, we might have to apply analog
inputs to a device in hopes of setting up the proper digital stimulus conditions for
testing. However, analog circuits are inherently “noisy” from a testing point of
view. The quantization of analog signals into digital values will often show varia-
tions that are completely acceptable from an operational standpoint, but frustrate
our effort to apply known, repeatable digital signals during a test. With Boundary-
Scan, we can also apply digital tests with extreme values that fall outside the normal
domain of operation of the analog circuitry. For example, an analog filter front end
to a digital circuit might not be able to slew from an “all zeroes” digital value to an
“all ones” value in two successive tests.
Figure 4.10 shows two ICs with Boundary-Scan that communicate by differen-
tial signaling. Differential signaling is an analog technology,7 but is a common tech-
nique often found in “digital” designs. Many digital designers would argue that
differential signaling is a digital technology, but it is not generally possible to insert
Boundary-Scan cells directly in the differential pathway; they must be placed
(as shown) before or after the differential conversion. This leaves us with a testing

7
From the point of view of the 1149.1 Working Group, differential drivers and receivers should be
viewed as instances of the analog/digital configuration shown in Fig. 4.9.
160 4 Advanced Boundary-Scan Topics

SIG+
+
-
SIG-

TDI TDO

Diffrntl

Fig. 4.10 Two digital ICs that communicate by differential signaling

SIG+
+
A -

SIG+
+
B -

SIG+
C +
Reference -
Circuitry
DiffCase

Fig. 4.11 Three examples of “unusual” differential signaling applications

problem because we have two signals controlled or observed by single cells. These
signals can suffer opens and shorts like any others. Today’s consensus is that this
problem should be treated as follows:
• design differential structures with Boundary-Scan as shown in Fig. 4.10.
• use the PORT_GROUPING attribute in a BSDL description (see Sect. 2.3.7 on
page 67) to identify the paired differential signals, whether they are voltage or
current signals, and which signals are positive and negative.
• conduct test generation as before for the positive portion of each differential pair.
Test diagnostics routines must be made aware of the negative signal pairing for
generating effective repair instructions.
4.7 Multi-chip Module Testing 161

To complicate matters a little more, differential signaling is not always utilized

in a straightforward manner at the board level. Figure 4.11 shows three examples of
board topologies that use differential drivers and/or receivers in ways that may be
troublesome for Boundary-Scan software.
Figure 4.11a shows a case where the positive and negative legs of a differential
pair are swapped, yielding a “free” inversion in the logic. The effect of this on a
Boundary-Scan test algorithm is that Serial Test Vector (STV) data from a driver is
inverted upon reaching a receiver. If the algorithm is not prepared for this situation,
it will try to diagnose a failure.
Figure 4.11b shows a case where a single-ended driver is connected to the posi-
tive leg of a differential receiver while the negative leg is connected to a reference
voltage. (If the legs were swapped, as in the case above, then an inversion would be
implemented too.) Boundary-Scan software should prepare and execute a test for
this case without problems, but defects in the reference circuitry would likely not be
diagnosed correctly.
Figure 4.11c shows a case where a single-ended driver is connected to the posi-
tive leg of a differential receiver while the negative leg is driven by an active refer-
ence generator function. This function may change the generated reference level
“on-the-fly”, with the effect that the output of the receiver has a selectable delay.
Tester resources could be used to force the reference generator to produce a static
level to convert the problem into the same form as Fig. 4.11b.
The differential question is revisited in Chap. 7 where 1149.4 resources are used
to implement tests of differential signals. And, the year 2003 saw the advent of
IEEE Standard 1149.6 (see Chap. 8 and [IEEE03]) which specifically addresses the
differential I/O question with technology that can diagnose defects, and also deal
with new forms of channel coupling, notably, AC-coupling.

4.7 Multi-chip Module Testing

Multi-chip module (MCM) technology offers the ability to place a number of

Integrated Circuit die8 upon a single substrate within one package as shown in
Fig. 4.12. MCMs have been used for many specialized applications for a long time.
For example, Hewlett-Packard (now Keysight Technologies) has used mixed
analog/digital MCMs as the front end of digital voltmeters for at around 40 years.
Today the desire is great to utilize MCMs much more broadly in many new
applications.9 Because testing is a large contributor to the cost of an MCM,

8
Other components may also be placed, such as surface mounted capacitors. Integral thin-film
resistors, capacitor, and even inductors may be part of the substrate as well.
9
MCMs still exist today, and have been joined by System on Chip (SOC) technology as well as
“stacked ICs”, where multiple dies are bonded atop one another in a vertical stack. These technolo-
gies allow extraordinary density improvements.
162 4 Advanced Boundary-Scan Topics

Die Die Die

Pad/Signal
Thin-film
Copper- Ground
Signal
Polyimide Power
Ceramic Ground
Layers Power

...
(Not to scale)
Signal Power Ground Signal Signal MCMSubst

Fig. 4.12 Multi-Chip Module shown in cross section. This example shows a multi-layer ceramic
PGA made of multiple dielectric and metallization layers. Bare IC die and other discrete compo-
nents are mounted on the top surface

Boundary-Scan has much to offer in the quest to bring MCM technology into
mainstream applications [Poss91].
That said, there is little to add about what Boundary-Scan can do because an
MCM is essentially a very small board, with little chance of being effectively probed
with In-Circuit probes. The various interconnect, bus, connection or BIST tests
already outlined are quite useful. Additional performance testing that may be needed
will not enjoy much enhancement because of Boundary-Scan—as is also the case
with boards.
It is important to note that 1149.1 does not form a hierarchy; for example, if you
place a number of 1149.1 components onto an MCM, you can test it as a small
board. When you place the MCM onto a board with other MCMs and individual
1149.1 ICs, you cannot visualize that MCM as a monolithic individual component
containing 1149.1. The MCM is still a collection of N 1149.1 ICs. For example,
when programmed for BYPASS operation, the MCM does not have a single-bit
BYPASS register; it is N bits long. The MCM contains N Instruction Registers, each
with its own repertoire of instructions, and so forth. Thus, an MCM must be docu-
mented with its own netlist10 and set of BSDL descriptions. Note in the late 1990s
we have seen the advent of “silicon core” technology, where several entire ICs may
be laid down on a monolithic piece of silicon. Some research [Jarw94] has been
done for this problem,11 but it looks like we will have the same result as we have
seen for MCMs. This could change if silicon cores are re-synthesized such that their
1149.1 circuitry is merged into a compliant design with a single BSDL description.

10
The netlist information need not be completely specified for board testing application if you
assume that once successfully fabricated, the internal MCM interconnect will not break. It is suf-
ficient to document only those nodal connections that reach an MCM I/O pin. Leaving internal
interconnects undocumented may ease concern for those who want to keep this information secret.
11
Jarwala’s work specifically addressed MCMs but the problem discussed is the same.
4.8 Firmware Development Support 163

4.8 Firmware Development Support

For some time now, microprocessors have offered emulation support for hardware
development systems. These development systems allow a system designer (for
either hardware, firmware or software) to gain control of the microprocessor and use
it as a tool to control and observe the system. For example, a hardware development
system would allow a designer to halt the processor, examine or modify processor
registers, single-step it through a sequence of instructions, set software breakpoints,
and so on. Add to this the ability to display the point in the program being executed
(in both assembly code and higher-level code) and to display additional measure-
ments taken from important system signals (by clip-on probes) and you can appreci-
ate the power of such a tool. Indeed, a new microprocessor entering the marketplace
without such support available is not likely to be successful.
The hardware development system is usually interposed between the micropro-
cessor and the system by means of an isolated and instrumented socket that is placed
into the board where the processor would be. The processor itself is contained in a
remote pod where the board signals are delivered and the development system can
monitor them.
Today, several trends are making the traditional hardware development system
obsolete. First, the higher operating frequencies we are seeing, along with higher
processor pin counts make sockets12 and umbilical cables quite unreliable. Second,
each new processor, even from the same vendor, requires a massive investment in
the design of a complementary development system. Third, yesterday’s single pro-
cessor is today’s family of processors, each with a smaller market share and shorter
market lifetime. This adds up to a situation where traditional development systems
are increasingly costly to develop and yet each addresses a smaller share of the
market with a shorter lifetime.
The 1149.1 Standard can help with this problem [Gols00]. After all, part of its
name is “Standard Test Access Port”. If Boundary-Scan exists on a processor, it is a
relatively simple matter to implement additional instructions that will help support
hardware development systems through the TAP port. This immediately solves the
first problem concerning access and operating frequencies. Second, with some
cooperation from IC merchants (who have much to gain if development support is
easily available) it is possible to standardize on a small set of development support
methodologies. Such standardization would allow one investment in a development
system to support many processors.
An example of a processor with 1149.1 support for development is the Advanced
Micro Devices Am29035 [AMD91]. This IC allows access to a set of hardware
development support functions using the 1149.1 port. These same functions are also
available from the processor edge pins, if you can get to them. Via 1149.1, you can

12
Packaging techniques such as Surface Mount Technology (SMT) and Ball-Grid Arrays are
rapidly making sockets obsolete.
164 4 Advanced Boundary-Scan Topics

access these functions through four wires without physically disturbing the board or
system it is mounted in. Indeed the processor could be a member of a chain of
1149.1 ICs and we could still access its support functions, as well as those of other
ICs in the chain.

4.9 In-System Configuration

Programmable Logic Devices (PLD) such as Field-programmable gate arrays

(FPGAs) and complex programmable logic devices (CPLDs) have become increas-
ingly popular. One factor driving this is that they are getting quite dense, allowing
major portions of a system to reside within them. Another factor that is decreasing
the total systematic cost of these devices is that fact that they are specifically
designed to be programmed after they have been mounted on a board. This is known
as “In-System Configuration” or “ISC”.
ISC has several attractions; first, the design can be changed at any time by repro-
gramming the device(s). This is attractive for system maintenance, field updates,
and even as a run-time feature of the system itself. Second, if you program these
devices after they are placed on board, you do not need an inventory of pre-
programmed devices.13 This lowers your Work-in-Progress expenses. Third, han-
dling blank devices14 for a programming step before they are mounted on a board
invites a lot of additional manufacturing defects.
CPLDs are getting very large and they represent a worst-case for conventional
In-Circuit testing due to lack of models as discussed in Sect. 1.1.1. Worse, if you do
conventional In-Circuit test you must first wait until the devices are programmed
before they can be tested. This could be a lengthy period of time during which device
damage due to fault may occur. Then there is always the chance that some board-
level fault causes the programming to fail. This will lead to diagnostic ambiguity.
Because of such problems consumers have demanded that 1149.1 be included in
programmable device designs. Thus, PLD vendors have invested in the four extra
pins for Boundary-Scan. It did not take long for them to realize that these same four
pins and serial protocol could be used for programming these devices as well. In
1996, a group of these vendors, brokered by an ATE company, met to see if they
could agree on a common protocol for using 1149.1 for In-System configuration. It
delights me to say this group has now become a formal IEEE Working Group and
has decided (after some initial misgivings) that full compliance with 1149.1 is

13
However, if the rate of programming failure is more than a few percent, this could translate into
a lot of board repair work dedicated to replacing programmable devices, which might negate these
advantages.
14
These devices are themselves becoming quite large with high pincounts, which aggravates han-
dling difficulty.
4.9 In-System Configuration 165

desirable. This group has created IEEE Standard 1532 [IEEE02] that will allow
users to program multiple devices with device family independence and vendor
independence. All 1532 devices support 1149.1 Boundary-Scan. This new standard
is covered in Chap. 9, and in more detail in [Jaco03].
There are several underlying technologies used in PLD devices. Some non-
volatile devices look a lot like EEPROMs and some are like FLASH RAMs. In most
cases, the common thread is that you pump bits into them and then allow them to
“cook” until the bits are successfully programmed. This can take anywhere from
several microseconds to tens of milliseconds, per “word” of data. When the time to
move data (serially) into one or more devices is a fraction of the cook time, it becomes
attractive to program multiple devices in concurrently. By “concurrently”, I mean in
time, not that we are using separate Boundary-Scan chains. Here is how it is done:
• Step1: Initialize a chain containing one or more programmable devices and
assure the integrity of the chain.
• Step 2: Program each non-ISC device into a benign state (load BYPASS, CLAMP
or HIGHZ as appropriate) and use PRELOAD on the ISC devices to set up their
output drivers for a benign condition.15
• Step 3: Load the ISC device instruction registers with the ISC_ENABLE instruc-
tion16 while preserving the non-ISC instruction registers with the choices made
in Step 2.
• Step 4: Load the ISC device instruction registers with the ISC_PROGRAM
instruction. This is the workhorse instruction used to load programming
information.
• Step 5: Shift data/address information for all ISC devices into the chain.
(Shift appropriate “don’t care” data into the non-ISC device data registers.)
• Step 6: Proceed to the Run-Test/Idle state and clock the chain until the longest
“cook” time has expired.
• Step 7: If there is more data for any ISC device, return to Step 5. If some devices
are completely programmed, simply reprogram their last address/data over again.
• Step 8: Load the ISC device instruction registers with ISC_DISABLE. Go to the
Run-Test/Idle state and clock the chain for the number required by the longest
ISC device.
• Step 9: Proceed to Test-Logic-Reset to bring the ISC devices into their
programmed operational states.17

15
Some ISC devices will not have their outputs controlled by the Boundary Register, but rather will
simply disable all drivers. This mirrors the choice you have when implementing INTEST (see Sect.
1.5.2 on page 37).
16
ISC_ENABLE sets up an environment for ISC programming. It must be executed before any
other ISC instruction. The ISC_DISABLE instruction removes this environment.
17
Note you can bring the ISC devices into their operational states in a particular sequence by load-
ing their instruction registers with the BYPASS instruction one-by-one while the others remain in
ISC_DISABLE.
166 4 Advanced Boundary-Scan Topics

Other programming activities, such as readback verification of the programmed

content or device erasure are supported in a similar fashion. See Chap. 9 and
[Jaco03] for more detail.

4.10 Flash Programming

Flash RAM programming [DeJo01, Wibl99] is an important topic today. Constructs

such as seen in Fig. 4.13 are common, where a device (like IC1) that has Boundary-
Scan accesses data from a non-Boundary-Scan Flash RAM (IC2).
In the past, the Flash RAM would be programmed off-line before placement on
a board. Now, using Boundary-Scan, we can deliver bits into the Flash RAM after
board manufacture. Using the EXTEST instruction, address and data can be set up,
and then a write pulse can be generated.
There is a problem here however. It will take three scans: the first to set up data
and address, the second to cause a rising edge on Write Enable, and then a third to
clear the Write Enable signal. If the Boundary Register of IC1 is long, this will take

Write Enable

16-Bit Address
IC 2
Flash RAM
IC 1
32-Bit
Data

TDI TDO

Address Valid Valid Valid

Data Valid Valid Valid

Write Enable
FlashProg

Fig. 4.13 Conventional Flash RAM accessed by a Boundary-Scan device

4.11 Hardware Fault Insertion 167

some time. Since most Flash RAMs are quite deep, the total time to program the
device may be unacceptable.
This process can be accelerated by a factor of three if there is access to the Write
Enable signal, perhaps with an ATE resource nailed to that signal. Then we only
need to scan in the data/address bits. Once these are in place, an ATE driver can
pulse the Write Enable line18 in real time rather than in “scan time”. More accelera-
tion can be had if several Flash RAMs are present, and they can be programmed
concurrently. This will be a function of the sophistication of the programming soft-
ware being used.

4.11 Hardware Fault Insertion

Hardware fault insertion is a technique used to “simulate” faults in a hardware

implementation rather than by more traditional software simulation techniques. One
obvious advantage is speed; hardware executes its function at its native speed while
software simulation is typically orders of magnitude slower. However, many
schemes for hardware fault insertion are cumbersome at best. A paper [Nade95]
shows how a relatively simple addition to Boundary Register cells, along with a
supporting instruction, can be used to perform hardware fault insertion.
Boundary-Scan-based hardware fault insertion takes advantage of the multi-
plexor function that most Boundary-Scan cells have between the Update Flip-Flop
(UPD) and the output of the Boundary Register cell. This multiplexor determines
whether an input(output) is passed through the cell untouched, or whether the con-
tent of the Update Flip-Flop is substituted in its place. If we think of the Update
Flip-Flop as containing the value of a stuck-at fault, all we need is a way to selec-
tively apply this fault value to an I/O pin. This is done with a simple modification19
to a classic Boundary Register cell shown in Fig. 4.14.
In this cell design, a “second” Update Flip-Flop is added, labeled “Update-FI”,
(for “fault insertion”). For all the standard 1149.1 instructions, the first Update Flip-
Flop is clocked by the Update-DR clock signal. But for a new instruction (let’s call
it “Insert_Fault”) the Update-DR clock is deactivated and the Update-FI clock takes
its place. Thus, when the Update-DR state in the TAP State Diagram is passed, the
Update-FI Flip-Flop loads the data from the Capture Flip-Flop rather than the nor-
mal Update register.

18
If the Write Enable driver in IC1 can be disabled via Boundary-Scan, then this would allow the
ATE system to pulse that signal without needing to overdrive IC1’s driver.
19
This modification is simpler than that shown in [Nade95]. The design in Fig. 4.14 does not sup-
port fault insertion while EXTEST is in effect. The design in [Nade95] is not strictly compliant
with the standard since it can interfere with the non-invasive definitions of instructions such as
BYPASS, but it will work well with most tools.
168 4 Advanced Boundary-Scan Topics

Shift Out
FI-Enable
Reset
D Q

Update-FI CK

Mode
G
Parallel In 0
Parallel
Shift-DR G
Capture Update 1
Out
0 Reg Reg
D Q D Q
1
CK CK

Shift In Clock-DR Update-DR FaultIns

Fig. 4.14 A BC_1 Boundary Register cell modified to support fault insertion

The content of the Update-FI Flip-Flop is OR’ed with the Mode line supplied by
the TAP Instruction decoder. If Update-FI contains a “0”, then it has no effect on the
normal operation of what is essentially a BC_1 cell design. If the Update-FI Flip-
Flop contains a “1”, then it overrides the Mode signal and forces the cell to insert
the value contained in the Update Register cell, regardless of what instruction is
loaded in the Instruction Register.
Here is how you would use this capability. First, as with any 1149.1 activity, you
would reset the chain of devices to the Test-Logic-Reset state. This asserts the
RESET signal so that the Update-FI Flip-Flop is cleared. Then you would execute a
PRELOAD sequence (which is non-invasive) to preload the Boundary Register with
a set of stuck-at “0” or “1” values for any pin(s) of interest, both input and output.20
(Note you must to assign a “0” or “1” to all cells, but only those later “fault insertion
enabled” will actually substitute faulty values.) Then you would load the instruction
register with the INSERT_FAULT instruction which targets the Boundary Register,
but now clocks only the Update-FI Flip-Flops at the Update-DR state. You would
shift in a pattern of “0” and “1” bits such that only those pins that should be faulted
(either high or low) are activated. Once passing Update-DR the selection of faulted
pins would be injected with faulty data specified in the PRELOAD sequence.
You can insert as many faults, of either polarity, to any set of equipped I/O pins
on as many Boundary-Scan devices as you want. This can be used to evaluate the
effectiveness of other test/diagnostic techniques, such as background system diag-
nostic tests. This was a principle motivation for the [Nade95] work, done for the
telecommunications industry.

20
Note, if this cell design is applied to output enable control cells, then you can “fault” a 3-state
driver, causing it to be “stuck-at-enabled” or “stuck-at-disabled”.
4.12 Power Pin Testing 169

4.12 Power Pin Testing

A paper by van de Lagemaat in 1989 [Lage89] anticipated a problem later spelled

out by Tegethoff et al. in 1996 [Tege96], that of how to test power pins on ICs. The
problem is that the fraction of all device pins that are power pins (including “ground”
pins) has been growing [Tege96]. It is not uncommon on larger devices to see
40–60 % of all the pins be devoted to power and ground connections. The question
is this – are open connections on these pins, which are not tested by Boundary-Scan
today, of importance?
Tegethoff performed a limited set of experiments on a real workstation mother-
board that concluded open connections on power pins was not of concern, at least in
that generation of product. They literally chiseled some power pin solder balls off a
large BGA-type device and then tracked that device through production and system
test to see if any failures were found that could be traced to the missing connections.
None could. The conclusion was that (for room temperature and nominal operating
conditions) the BGA power distribution structure was overdesigned and thus toler-
ant of a “few” open power pins. The next concern is that if pin counts are too high,
one might be tempted to redesign power distribution structures such that every pin
must be connected, that is, there is no safety margin.
Can power and ground pins (somehow) be monitored by Boundary-Scan?
Several schemes have been proposed [Lage89, Tege96, DeJo00], none of which is
particularly satisfying. In all cases, some form of current monitoring has to be done
that can signal, via a voltage level that can be captured in a data register cell, if an
expected amount of current is actually flowing through a power pin. What makes
this more difficult is that parallel current paths may be strapped together in the lead
frame of the device, perhaps at other places in the package, and finally, on the IC
itself. There may also be large bypass capacitors mounted inside the package as
well, to muddle matters further.
This is still an open question. Boundary-Scan test coverage reporting tools
[Hird00] will report that open pin coverage on large ICs with high power pin counts
are relatively poor. Our industry could adjust by deliberately specifying “power pin
opens tolerance” by design, or by coming up with a standardized method for detect-
ing these opens. Stay tuned…
Chapter 5
Design for Boundary-Scan Test

Design for Testability (DFT) is a subject covering a huge amount material. The
1983 survey by Williams and Parker [Will83] is still remarkably current in its enu-
meration of DFT techniques (it lacks Boundary-Scan of course), but many of the
contexts have changed. For example, signature analysis [Nadi77] testing is now
conducted on-chip, though it started as a board-level technique. This reflects the
incredible increase in the density of Integrated Circuit (IC) components. In 1983,
the 1149.1 Standard would have been largely impractical because the logic needed
to implement it would have been a large fraction of an IC. Today, we are seeing ICs
designed with significant amounts of on-chip testing circuitry, including 1149.1.
Without DFT, a VLSI component might not be economical to produce in volume.
Other technologies are also driving the need for DFT. In the board domain, we
see VLSI components contained in ever-shrinking packages placed ever closer
together on boards fabricated with ever-smaller trace widths and increasing num-
bers of layers. Two-sided component placement, blind vias, Surface-Mount
Technology (SMT), Tape Automated Bonding (TAB), Ball-Grid Arrays (BGAs),
Chip-on-Board (COB), daughter-board structures, Multi-chip Modules and stacked
ICs are some of the factors that threaten existing board testing technology. The
phrase “yesterday’s system is today’s board” is quite true. Indeed, today’s ICs can
be complex systems—hence the term “System-on-Chip” (SOC).
One complaint I have had about DFT literature (for which I am partly responsi-
ble) is that the word “Test” embedded in “DFT” is all-inclusive. It should not be. As
with the title of this chapter, DFT should be qualified by the type of testing antici-
pated. For example, there should be Design for In-Circuit Testing (should this be
called DFICT?) and Design for Edge-Connector Functional Testing (DFECFT?)
and Design for Integrated Circuit Testing (DFICT?—no, already taken.) and so on.
The type of testing to be done greatly influences your DFT decisions. For example,
many In-Circuit testing DFT rules [Bull87] are mechanical in nature, to facilitate
In-Circuit probing. These are irrelevant for edge-connector testing. We need to
consider DFT as “DFxT” where “x” is the target test technology.

© Springer International Publishing Switzerland 2016 171

K.P. Parker, The Boundary-Scan Handbook, DOI 10.1007/978-3-319-01174-5_5
172 5 Design for Boundary-Scan Test

Along with the type of testing, we must not forget the target failure mechanisms,
the “real” faults1 that we are trying to detect. Unfortunately, we are often guilty of
testing for failures that are not prevalent because they are convenient (that is, sup-
ported by our tools). Untold wealth has been spent simulating single-stuck-at (SSA)
faults and calculating dictionaries for them when prevalent real defects, such as
shorts, are not adequately described by the SSA model. Fortunately we have been
lucky that SSA derived tests often will detect non-modeled failures, but accurate
diagnosis has been a problem. Can we depend on luck in the future?
Boundary-Scan is primarily targeted at board level manufacturing faults—the
havoc of the production process—affecting digital components. These include, in
rough order of prevalence:
• Solder defects creating opens (too little solder).
• Solder defects creating shorts (too much solder).
• Misloaded components, including wrong or missing components.
• Dead components or components with electrical damage to input or output
buffers.
Boundary-Scan does not directly attack problems such as AC timing (delay test)
for example. If a device implementing 1149.1 does not contain a self-test capability
(such as RUNBIST) then it can completely miss deeply embedded internal faults
too. If either of these failure mechanisms are important to you, you need a different
strategy for them.
IEEE/ANSI Standard 1149.1 [IEEE99] is the first standardized DFT technology.
Other techniques exist [Will83] such as Level-Sensitive Scan Design (LSSD) and
Built-In Logic Block Observer (BILBO), but they have not achieved the status of a
standard. Generally, there is little available support (that is, software) for these
approaches; and the support that does exist typically is not transferable.2 For exam-
ple, an LSSD design system may have been used in the design of a board, but it
cannot readily transfer test information to an ATE system from an outside vendor.
The 1149.1 Standard, along with BSDL, is a major step towards surmounting
these obstacles. The Standard gives the IC community, the Electronic Design
Automation (EDA) community, and the ATE community (among others) a common
target. BSDL creates an interchange capability so that the customers common to
these communities can readily utilize a selection of tools from different vendors.
The selection of “Best-of-Class Tools” will be a revolution in our industry.

1
See [Hird02] for a concise definition of “defect” and a discussion of defect coverage.
2
Of course within large, vertically integrated companies there may be vast quantities of software
support for a particular DFT methodology. However, this software would be largely inapplicable
outside its native environment because of small differences in how other companies might define
similar DFT techniques. (The avoidance of patents is another issue.)
5.1 Integrated Circuit Level DFT 173

5.1 Integrated Circuit Level DFT

We first look at Design for Test concerns that should be observed at the IC level.
Some of these concerns have their effects later at the board or system levels, but
then it may be too late to redesign the IC.

5.1.1 TAP Pin Placement

We noted in the section on chain integrity testing (see Sect. 3.2.1 on page 128) that
a short between the TDI and TDO pins on a package was particularly troublesome
to diagnose. Figure 5.1 shows some TAP pin placements. It is natural for them to be
near each other because they are the terminals of the Boundary Register that lies on
the circumference of the die.
Figure 5.1a shows a placement for TDI and TDO pins that maximizes the likeli-
hood that a short could occur between them. This type of layout should be avoided.
Figure 5.1b, c show preferred layouts that reduce the probability of their shorting.3
This leads to our first DFT rule.

TDI
A
TDO
TDO
Ground
TDI

Power

B
C
TDI TDO
PinOuts

Fig. 5.1 Three pin layouts for TDI and TDO

3
The main cause of board shorts is the bridging of solder between adjacent pins.
174 5 Design for Boundary-Scan Test

• DFT-1: Place TDI and TDO pins on the end or the corner of a package to
reduce their likelihood of being bridged by solder.
Second, noting that many ICs today require a large number of power and
ground pins, you could contrive placing some of them next to TDI and TDO as
depicted in Fig. 5.1c. In the event of a short, these pins will create a solid “0” or
“1” if they become shorted to a TAP pin. Shorts to other signals might not have
deterministic behavior.
• DFT-2: Place power pins between TDI and TDO pins and other signal pins.

5.1.2 Power and Ground Distribution

Power and ground distribution is always a concern during IC design.4 A typical

VLSI component may have many power and ground pins to distribute lead induc-
tance over many parallel pathways. If this distribution is not handled carefully, the
result could be Ground-Bounce.
Ground-Bounce occurs when inductance and/or resistance in the power distribu-
tion pathway injects a voltage drop across internal circuit nodes that are supposedly
referenced to the same value (power or ground). This has the effect of superimposing
a voltage fluctuation on a signal. If this signal is TCK by chance, then we can lose
synchronization with the TAP state diagram if the fluctuation is large enough to inject
a new TCK clock cycle. Figure 5.2 shows an actual Ground-Bounce on TCK for a
VLSI component. This 1.38-V bounce, approximately 25 ns wide, is sufficient to add
a new TCK cycle. The voltage pulse seen inside the package is likely to be higher
because the inductive contribution of the lead frame and bond wires will be added.
Inductive Ground-Bounce is worsened by the ability of Boundary-Scan to cause
many drivers to switch state at the same time, causing a current surge. While the
value of lead inductance L may be very small, high-speed current (i) transitions
amplify the effect because the voltage V is given by:
di
V =L
dt
When a Ground-Bounce on TCK occurs, it is quite likely to occur on the falling
edge of TCK while in Update-IR or Update-DR because this is when output pin
drivers can switch. The effect is to inject a clock pulse on TCK some nanoseconds
after the falling edge. Now, since TMS is set to one at this time (needed to get into
the update state and then to get to Select-DR-Scan), the TAP will proceed to
Select-DR-Scan, one cycle sooner than we expect. If our intent is to travel down

4
Note too that power and ground pins, by nature, are often highly redundant. This leads to test
coverage deficiencies that are often overlooked. See [Tege96] for a discussion.
5.1 Integrated Circuit Level DFT 175

Soope Pic

−50.000 ns 200:000 ns 450.000 ns

Ch. 1 = 1.000 volts/div Offset = 2.000 volts

Timebase = 50.0 ns/div Delay = 200.000 ns
Delta V = 1.380 volts
Vmarker 1 = 0.000 volts Vmarker2 = 1.380 volts

Fig. 5.2 An oscillograph of a Ground-Bounce induced clock cycle on TCK during Update-DR,
measured at the TCK pin referenced to component ground

the data column again (which is often the case during testing) we will then issue
another TCK to get to Select-DR-Scan, not realizing we are actually there because
of the bounce. This sends the TAP to Select-IR-Scan instead. Since traversing
the data column and the instruction column take an identical protocol on TMS, we
find ourselves attempting to do testing with the Instruction Register between TDI
and TDO rather than the Boundary Register! Of course, this is disastrous to the
integrity of our test.
A debugging tip: if an extra TCK pulse does occur at one of the update states,
you can recognize the problem by examining the bits that are shifted out. Instead of
the expected target register bits, you will see the Instruction Register capture pattern
(because Capture-IR was traversed) shift out. This is another argument for having
fixed bits in the Instruction Register capture pattern since more fixed bits will make
it easier to recognize that the IR column is being traversed. (See rule DFT-5.)
Consider the example shown in Fig. 5.3. Here a large IC generates signals on a
pair of 32-bit buses. In this IC’s normal usage, the two buses are never active at
the same time, as shown in Fig. 5.4. However, the figure also shows how the two
buses could behave when the device is in EXTEST. In this case, both buses can
176 5 Design for Boundary-Scan Test

32-Bit Bus
A IC2

IC 1
32-Bit Bus
B IC3

TDI TDO

ActivBus

Fig. 5.3 A high pincount IC with two 32-bit buses

S y s te m F u n c tio n EXTEST

A Active A Active

B Active B Active
Time Time
ActivDif

Fig. 5.4 The transition timing for activities on the two buses in Fig. 5.3

produce transitions at the same time. In the worst case, guaranteed to occur in the
interconnect test algorithm5 shown in Sect. 3.2.2 on page 131, all 64 drivers will
change at the same time.6
Deliberately adding skew to the update clocking of the Boundary Register cells
[Maun90] will help to control the magnitude of the switching current transients.
This is shown in Fig. 5.5. Be careful to note that the delays are not inserted in the
system data path so they have no effect on system performance. These delays, per-
haps only a few nanoseconds apiece, are used to deliberately skew driver transitions
in time so that the required supply current demands do not change as quickly in

5
The Standard specifically disallows designers from specifying some maximum number of simul-
taneously switching drivers that is less than all drivers. Further, designers may not attempt to out-
law certain combinations of states driven by drivers.
6
In this case, all drivers are at “0” and then switch to “1”. These two PTVs are used to eliminate
aliasing with power/ground shorts, which are quite common. PTVs can be re-ordered to try to
ameliorate this problem.
5.1 Integrated Circuit Level DFT 177

Shift Out

From G
System 0
Output
Circuitry Pin A
G 1
0 CAP UPD
D Q D Q
1
CK CK

Delay

Delay
From G
System 0
Output
Circuitry Pin B
G 1
0 CAP UPD
D Q D Q
1
CK CK
Delay

Delay

From G
System 0
Output
Circuitry Pin C
G 1
0 CAP UPD
D Q D Q
1
CK CK

ShiftDR ClockDR UpdateDR Mode

Shift In ActivSkw

Fig. 5.5 Deliberately inserted delays in the Boundary Register control signal paths can be used to
distribute driver edge placements in time

time. There is one fine point to be considered as well; your distribution of control
signals to driver enables (a high-speed system path) will not be delayed. The more
drivers you gang together on a common control cell, the more likely you could
enable or disable a large current flow. Be alert for this when considering how many
driver enables to control with a single control cell, and make sure the delay scheme
shown in Fig. 5.5 is not compromised by grouping your control cells next to each
178 5 Design for Boundary-Scan Test

other in the Boundary Register.

It is thus very important to do a worst-case analysis7 of Ground-Bounce accounting
for the maximum number of drivers switching states. It will also be important to sepa-
rate the power distribution of the TAP logic from the System logic and the output
drivers. Doubtless there are other schemes that are possible for controlling supply
current surges8 that will work as well.
• DFT-3: Ensure that worst-case switching of all IC drivers will not cause
power/ground transients that disrupt the operation of the TAP controller.
Another Ground-Bounce inducing mechanism has been observed. It is caused
by an interaction of ATE drivers with IC drivers on a board. In years past, IC driv-
ers had more modest slew rates than are prevalent now. When an IC driver was
overdriven by an ATE driver, a large current would flow. When the ATE driver
stopped driving (that is, it was disabled) the IC driver would recover control of
the overdriven node at a speed determined by its drive slew rate. Today, higher
slew rate drivers on boards are being overdriven. When the ATE system stops
overdriving, the IC driver creates much more of a current surge as it recovers
control of the node. This can induce a Ground-Bounce. Thus, ATE systems now
need to manage how many signals are being overdriven and released at any point
of time. In most cases, ATE systems can disable drivers in smaller groups (called
“phased release”), since Boundary-Scan tests are essentially static in nature.
• DFT-4: Assure that your ATE system can manage phased release of over-
driven nodes, to minimize slew-rate induced Ground-Bounce.

5.1.3 Instruction Capture Pattern

The bit pattern captured in the Instruction Register upon passing Capture-IR has
useful diagnostic properties as we saw in Chap. 3 in the discussion of 1149.1
Integrity testing (Sect. 3.2.1). Most 1149.1 components have Instruction Registers
with more than the minimum of two bits. If you are creating 1149.1 components,
you can increase the usefulness of the instruction capture pattern by:
• DFT-5: Use higher-order bits of the Instruction Register capture pattern
to implement an informal ID code. The bits captured must be predictable
“0”s and “1”s.
This rule is especially important if you have identical pinouts for the TAP pins
on several different components. For example, the Texas Instruments ICs
74BCT8373 and 74BCT8374 have identical pinouts and identical eight-bit cap-
ture patterns. Thus, if one IC is misloaded in place of the other, we cannot discover

7
This analysis should also take into account any exceptional currents that may exist if shorted pin
drivers conflict with each other or are tied to a supply voltage.
8
Note, increasing use of differential drivers on ICs will help smooth out current surges. In effect,
they steer current to and from a pin pair, with no net change in current for the IC.
5.1 Integrated Circuit Level DFT 179

the misload during Integrity testing, nor will we see a failure during EXTEST
functions. The only way to test for this problem is to perform a functional test on
the IC’s system logic9 capable of discerning the slight difference between the ICs.
Other components have been implemented that capture design-specific data in
the higher-order bits of the capture pattern that are not predictable. They must be
listed as “x” bits (“don’t know” bits) in the INSTRUCTION_CAPTURE attribute
of BSDL. The capture of design-specific data is sometimes done to increase visi-
bility into the TAP decode logic for fault simulation, where critical TAP decode
signals are placed in the capture pattern, making the pattern a function of the pre-
viously loaded instruction. This eases the problem of testing the decode circuitry
at IC test, but does nothing to help differentiate similar components at board test.
The capture of indeterminate data can also lead to indeterminate behavior of
an 1149.1 circuitry. This can happen if you follow this trajectory through the TAP
state diagram: Capture-IR to Exit1-IR to Update-IR. This sequence will load the
design-dependent bits into the Instruction Register and make them the next
effective instruction. To prevent this from being a random instruction, we have
our next DFT rule.
• DFT-6: If design-dependent bits are captured in the Instruction Register,
then any combination of these bits should decode to the same operation.
Since unused bit patterns are required to default to BYPASS, it may be easiest to
arrange that a capture pattern containing random bits also decode to BYPASS.

5.1.4 Damage Resistant Drivers

Engineers rarely study the issue of damage caused by driver conflicts when they
create the basic structures that will become the building blocks of an Integrated
Circuit. The typical reaction of an IC designer when confronted with the question
“How long can your drivers be shorted together before they suffer (some form of)
damage?” is to exclaim that they cannot tolerate any conflicts. Thirty years of
In-Circuit and Functional testing, where driver conflicts are not only tolerated, but
often deliberately induced, say otherwise. The studies done into the question, such
as [Robi83, Bush84], and [Hewl85] were primarily conducted by ATE designers
and users, not semiconductor device physicists.
The studies (of that era) show that some amount of abuse10 can be tolerated. The
two primary damage mechanisms are thermal heating of transistor junctions and
thermal heating that causes full or partial opening of bond wires. In either case, the

9
This test can be implemented using the 1149.1 INTEST function that both of these ICs support.
The test in this case needs to differentiate a latch (‘8373) from a flip-flop (‘8374).
10
Note that the abuse studied was In-Circuit overdrive abuse, which is likely to be more stressful
than driver conflicts, since an In-Circuit tester driver is usually far stronger than an IC driver. Do
note that drivers shorted to Power or Ground suffer worst-case current flows and durations.
180 5 Design for Boundary-Scan Test

mechanisms take time to occur. In some worst-case situations, damage is projected

to occur in several hundred microseconds. In most, it is prudent not to exceed dura-
tions of several milliseconds. Yet, functional test with manual probe backtracing has
been used for years. Such testing will power the board (and the conflicts on it) for
many minutes. This tells us that while driver damage is definitely a concern, our
components (at least for now) are relatively robust.
What about the IC components of the future? What affects will smaller transistor
feature sizes have? Will a move to lower power voltages make damage less proba-
ble? What about non-silicon ICs (for example, Gallium Arsenide)?
Since 1149.1 testing must be done with power applied to a board, we have three
choices. First, we learn the duration limits of our drivers to tolerate conflicts and
stay within those bounds. Unfortunately, those bounds may be too constraining.
Second, we construct abuse-tolerant drivers. This requires that we understand the
physics of damage. Third, when a fault is isolated that has resulted in driver abuse,
we replace the affected components even if they appear to have survived. This could
be a very expensive option.11 Of course, we could continue with a fourth policy
often followed in the past: ignore the problem.
I prefer a mix of choices 1 and 2. Study (theoretically and empirically) the toler-
ance of driver structures to conflicts, then improve on them as needed. This needs to
be done in a context of some minimum required test duration. This duration can be
roughly calculated as follows; add the times to apply power, run the Boundary-Scan
test,12 and remove power. Then double that result. Times in the range of several
seconds are quite possible.
• DFT-7: Specify a tolerance period that drivers can withstand shorts to each
other or to Power/Ground voltages.

5.1.5 Output Pins

Upon examining the example Boundary Register output cell designs shown in the
Standard [IEEE01], denoted as cells BC_1, BC_2, or BC_6 in BSDL, one notices
they have a common characteristic. While EXTEST is in effect, they all capture data
from one of two places, the System Logic,13 or the Update (UPD) flip-flop. However,

11
However, in certain applications where the cost of failure due to reduced component lifetime is
extreme, this may be quite acceptable. Consider electronic health care products or airborne naviga-
tion systems as examples.
12
Be extremely wary to include the time to set up the tester, any reload times, and the time it
requires to determine if a conflict exists. The time cannot be reliably predicted by simply multiply-
ing the TCK cycle time by the number of TCK cycles in the longest expected test.
13
The actual BSDL CELL_INFO triple for this is, for example, (Output2, EXTEST, PI). “PI” is the
parallel input that, for an output cell, must be the System Logic.
5.1 Integrated Circuit Level DFT 181

Shift Out

EXTEST Shift-DR Mode G Output

System 0 Driver
Circuitry
G G
Capture Update 1
0 0 Reg Reg
D Q D Q
1 1
CK CK

Shift In Clock-DR Update-DR

POMonitr

Fig. 5.6 A Boundary Register output cell design with the capability of monitoring its driver out-
put pad during EXTEST

upon reading the rules in the Standard concerning output cell construction, you see
no rules that require one of these sources. This suggests an improved design14 as
shown in Fig. 5.6.
The self-monitoring output cell design (Fig. 5.6) is capable of reading, during
EXTEST, the output state of the driver at Capture-DR. This value should be the
same as what we previously loaded into the Update (UPD) flip-flop, unless there is
a board-level condition where this is no longer true. There are several such condi-
tions: first, the driver is intentionally Wire-ANDed or Wired-ORed (two-state case)
with some other driver(s) on the board. Second, the driver is not enabled (three-state
case); and third, a defect in the driver or a board-level fault such as a short prevents
the driver from operating correctly. It is this third case that makes the self-monitoring
output cell very useful.
The BSDL description of this cell would look as follows15:
constant SMOC:CELL_INFO := -- Define a Self-Monitoring
-- Output Cell (SMOC)
((OUTPUT2, EXTEST, PO), (OUTPUT3, EXTEST, PO),
(OUTPUT2, INTEST, PI), (OUTPUT3, INTEST, PI),
(OUTPUT2, SAMPLE, PI), (OUTPUT3, SAMPLE, PI),
(OUTPUT2, RUNBIST, PI), (OUTPUT3, RUNBIST, PI));

14
The alert reader will note that this design is virtually identical to the BC_9 cell (page 100) which
was introduced with the 2001 revision of the standard. This revision provides direct support for
rules DFT-8 and DFT-9.
15
This description would be part of a user-defined VHDL package for cell design description as
described in Sect. 2.6 on page 84. The package would be referenced in the entity description for
the IC in a “use” statement. The “SMOC” name would appear in the cell field of the attribute
BOUNDARY_REGISTER (see Sect. 2.3.13 on page 72).
182 5 Design for Boundary-Scan Test

Here, the “PO” field (Parallel Output) implies the driver pad state because the
context is that of an output cell.
Given that this cell design is used in an IC with the attendant BSDL description,
software can look for pad value discrepancies that indicate a shorted node or faulty
driver. This information will be especially valuable when a driver is connected to a
node that does not terminate at a Boundary-Scan receiver; a self-monitoring driver
cell will still be able to participate in Interconnect shorts testing. In another situa-
tion, if a self-monitoring driver is connected to a node that has a single Boundary
Register receiver, the self-monitoring property can be used by the diagnostic rou-
tines to differentiate between a node shorted to Power/Ground and an open solder
connection. This leads us to our next DFT rule.
• DFT-8: Use self-monitoring output cells in the Boundary Register to improve
Boundary-Scan diagnosis of shorts and opens.

5.1.6 Bidirectional Pins

Bidirectional pins can be serviced several ways. For example, you may implement
a two-cell bidirectional structure with independent drive and receive cells. You may
implement a single-cell bidirectional structure. The advantage of the single-cell
structure is that it reduces the number of stages (cell count) in your Boundary
Register, which reduces shift time, saves storage space and increases test applica-
tion rates. The advantage of the two-cell design, before Supplement A [IEEE93a] is
that it could monitor the state of the bidirectional pin (by virtue of the receive cell)
regardless of whether the driver was enabled. Supplement A to 1149.1 shows a
much-improved bidirectional data cell design16 that is able to monitor its driver
result at all times. This leads to the diagnostic advantages already outlined for self-
monitoring output cells (see Sect. 5.1.5 above) combined with reduced Boundary
Register length.
• DFT-9: For bidirectional pins, utilize a single-cell bidirectional design with
a self-monitoring capability (such as cell BC_7).

16
The bidirectional cell that has the lack of pin monitoring is known in BSDL as cell BC_6 (see
Sect. 2.6.3 on page 46). The improved bidirectional cell design is known as BC_7. You are urged
to design out the BC_6 design if you currently use them, and use BC_7. Note the 2013 release of
1149.1 has removed the BC_6 design from the standard.
5.1 Integrated Circuit Level DFT 183

The BSDL description of such a cell looks as follows:

constant BC_7:CELL_INFO := --
--
((BIDIR_IN, EXTEST, PI),
(BIDIR_IN, INTEST, PI),
(BIDIR_IN, SAMPLE, PI),
(BIDIR_IN, RUNBIST, UPD),
Self-Monitoring
Bidirectional Cell
(BIDIR_OUT, EXTEST, PO),
(BIDIR_OUT, INTEST, PO),
(BIDIR_OUT, SAMPLE, PI),
(BIDIR_OUT, RUNBIST, UPD));

The triple “(BIDIR_IN, EXTEST, PI),” for example, shows (see Sect. 2.6.2 on
page 92) that while behaving as an input during EXTEST, the cell captures data
from the pad input buffer (PI = parallel input).
The triple “(BIDIR_OUT, EXTEST, PO),” for example, shows that while behav-
ing as an output during EXTEST, the cell captures data from the pad driver
(PO = parallel output). In the original issue of the Standard ([IEEE90], Fig. 10.22),
the cell BC_6 captured System Logic data (PI).

5.1.7 Post-lobotomy Behavior

As first discussed in Chap. 1, a complicated IC with Boundary-Scan, when yielding

pin-permission to an instruction such as EXTEST, will lose contact with its com-
panion ICs. These companion ICs as well may undergo Boundary-Scan testing. If
they do not, then they see the Boundary-Scan test data going by. In either case, this
is a total disruption of the environment these ICs constitute [Eklo01, Park10,
Park11]. If all IC TAPs are then placed back into the Test-Logic-Reset state the
1149.1 logic reverts to non-invasive mode, but the system cannot resume normal
operation as if nothing has happened. This situation was called the Lobotomy prob-
lem. It is the responsibility of the IC designer to ensure that the IC, when returning
to a non-invasive instruction from a pin-permission instruction, does not suffer from
internal conflicts or board-level conflicts. This gives:
• DFT-10: When the 1149.1 logic executes a pin-permission instruction, the
system logic should be forced into a state that prevents internal conflicts.
• DFT-11: When the 1149.1 logic returns to non-invasive mode, the system
logic should stay in a state that will not conflict with board level signals.
Thus, the system logic is placed in a quiescent state by pin-permission mode
instructions. It stays quiescent until the 1149.1 logic returns to non-invasive mode
and a general reset sequence brings the system logic back into coordinated opera-
tion. Note that RUNBIST may not operate correctly in a lobotomized component,
requiring a reset of the system logic.
184 5 Design for Boundary-Scan Test

5.1.8 IDCODEs

The 1149.1 IDCODE instruction is a very useful resource. It allows a component to

identify itself and give its revision level as well. This can detect problems where similar
components or different revisions of the same component are misloaded on a board.17
However, the IDCODE instruction does require resources: an instruction with
decode logic, a 32-bit IDCODE register, and so on. If this is not practical, it is still
possible to do an informal ID code. We have already seen how higher-order bits of
the instruction capture pattern can be utilized for this (see Sect. 5.1.3). Another
opportunity exists to differentiate an IC informally, by having certain cells in the
Boundary Register capture constant “0”s and “1”s.
During EXTEST, Boundary Register output and control cells are free to capture
anything. We have already discussed having the output cells capture their driver pad
states (in Sect. 5.1.5), which is very useful. This leaves us with the driver enable
control cells that we can design to perform a similar trick during EXTEST. They can
load a constant “0” or “1” into their Capture (CAP) flip-flop.18 Because most
Boundary-Scan components will have three-state and/or bidirectional outputs, there
should be one or several control cells. Each of these can provide a bit of our infor-
mal ID code. The BSDL for two cells, one capturing a “0” and the other capturing
a “1”, follows:
constant Ctrl_0:CELL_INFO := -- Control cell that captures 0
-- for EXTEST
((CONTROL, EXTEST, ZERO), (CONTROLR, EXTEST, ZERO),
(CONTROL, INTEST, PI), (CONTROLR, INTEST, PI),
(CONTROL, SAMPLE, PI), (CONTROLR, SAMPLE, PI),
(CONTROL, RUNBIST, PI), (CONTROLR, RUNBIST, PI));

constant Ctrl_1:CELL_INFO := -- Control cell that captures 1

-- for EXTEST
((CONTROL, EXTEST, ONE), (CONTROLR, EXTEST, ONE),
(CONTROL, INTEST, PI), (CONTROLR, INTEST, PI),
(CONTROL, SAMPLE, PI), (CONTROLR, SAMPLE, PI),
(CONTROL, RUNBIST, PI), (CONTROLR, RUNBIST, PI));

These BSDL descriptions allow software to predict the locations of “0”s and
“1”s in the Boundary Register that form an informal ID code.
• DFT-12: Use formal or informal ID codes to differentiate similar components
or revisions of components.

17
In the case where different revisions or manufacturing codes are permissible, you can edit
the BSDL attribute IDCODE_REGISTER to describe multiple device identification bit strings.
(see Sect. 2.3.11 on page 70.)
18
If the control cell has been merged with an input cell, then it must capture the input pin state in
that case. See the discussion of the BC_5 cell (page 95).
5.1 Integrated Circuit Level DFT 185

5.1.9 User-Defined Instructions

We have already seen a case (see Sect. 4.5) where a special 1149.1 user-defined
instruction called “LEAK” was used to perform a gross test for the existence of a
nodal termination resistor. “LEAK” is but one example of how some forethought
can be used during IC design to solve sticky, board-level test problems. In practice,
you might be frustrated by not having the privilege of controlling the design of all
the ICs on your board. Thus, you must look for clever ways to test the problem
nodes of your board using just those ICs you do have control over.
• DFT-13: Consider board-level testing problems that will require user-
defined instructions for their solutions before final implementation of
the 1149.1 logic.
Notice that this rule is a guideline for management of the design process. Board
testability needs to be an input to the IC design process.

5.1.10 Creation and Verification of BSDL

Ideally, a BSDL description should be created as a natural part of the IC design

process. Indeed, the same software that lays out the IC design can create it.
Unfortunately, in some cases, a test engineer may create the BSDL description, with
little input from the original IC designer. There is much opportunity for error.
Another source of error in BSDL comes from its distribution. How do you know
that the BSDL you have received for a component is up-to-date with the component
itself? Has the device been revised since you last obtained its BSDL description?
Another, really exasperating problem comes from the channel itself; BSDL is often
distributed over the Internet via electronic mail. Errors injected by this channel are
disturbingly frequent. For example, many electronic mail handlers automatically
split longer lines (called “line-wrap”) into smaller lines. This can create syntax
errors, usually when the tail ends of comments end up on new lines. Sometimes
mailers will simply truncate lines, losing data. Sometimes HTML19 formatting
information is included in the BSDL, causing syntax errors.20 Measures as simple as
limiting line lengths in your BSDL to less than 70 characters can often avoid some
of these problems.

19
Hyper-Text Markup Language (HTML) is a language used to construct pages accessed on the
World Wide Web. I have seen BSDL files containing HTML commands like “</Bigger>”.
20
One IC vendor I know, after receiving complaints about poor BSDL quality from their Web site,
downloaded some of their own files and verified them. Quite a few contained errors.
186 5 Design for Boundary-Scan Test

Errors in a BSDL description will have a devastating effect on the ability of a

Boundary-Scan test to run properly. Furthermore, it will be difficult at a board or
system level to determine where the problem is. It is highly recommended that a
BSDL verification test be run on each 1149.1 component on an IC tester21 before the
component is used in a board or system test. A BSDL verification test should con-
tain at a minimum, the following elements:
• Verification of IDCODE, if it exists and what instruction is jammed into the
Instruction Register at the Test-Logic-Reset state.
• Verification of the Instruction Register capture pattern.
• Verification that the Bypass register captures a 0 at Capture-DR.
• Verification of the USERCODE, if it exists.
• Passage through every state and transition in the TAP state diagram.
• Verification that each instruction opcode targets a register between TDI and TDO
of the specified length and that bits are read into TDI on the rising edge of TCK
while TDO bits appear on the falling edge.22
• Verification of the mapping23 between each input pin (or bidirectional pin acting
as an input) and the Boundary Register cells.
• Verification of the mapping between each output pin (or bidirectional pin acting
as an output) and the Boundary Register cells.
• Verification of the mapping between each driver enable and the Boundary
Register cells.
• Verification that SAMPLE can capture values presented at all inputs and bidirec-
tional pins acting as inputs.24
• Verification that the Capture (CAP) flip-flops of each cell perform as their BSDL
CELL_INFO constants specify.
• Verification that HIGHZ, if it exists, targets the BYPASS register and disables all
IC outputs upon passing the Update-IR state.
• Verification that CLAMP, if it exists, targets the BYPASS register and controls
all IC outputs upon passing the Update-IR state with a pattern set up by
PRELOAD.
• Verification of the RUNBIST function if it exists. (Note, this will require compo-
nents that both pass and fail RUNBIST.)
BSDL verification tests can be very long, with the mapping verification being
an N2 complexity problem.25 They look for discrepancies between a BSDL
description and the actual silicon of the IC. A manufacturing test for the 1149.1
portion of the IC, once the 1149.1 implementation and BSDL are proven, may be

21
If an IC has yet to be fabricated, then consider simulating the test patterns against a model of the
IC. This is a good strategy if the model and the resulting IC are good matches.
22
Private instructions may be omitted from this test.
23
The verification of mapping is done to ensure the cell information in the BSDL attribute
BOUNDARY_REGISTER is correct, which can be done using the EXTEST instruction.
24
SAMPLE also captures System Logic values for outputs and control cells, but these cannot be
verified since the data captured cannot be determined from BSDL alone.
25
The complexity can be reduced at the expense of diagnostic resolution.
5.2 Board-Level DFT 187

much shorter. For example, a BSDL verification test for the Intel 80486DX,
based on the elements above, contains approximately 36,000 TCK cycles,
excluding the test for RUNBIST. A manufacturing test for the 1149.1 logic in the
same IC, takes on the order of 7000 TCK cycles, again excluding RUNBIST.
(The RUNBIST function takes over 1,250,000 TCK and CLK cycles.)
• DFT-14: Verify that a BSDL description matches the silicon implementation
of 1149.1 on every component.
Creating a test solely from the BSDL and executing it against the IC on a
tester (or simulator) should perform this verification. For off-the-shelf merchant
ICs, the vendor should be able to provide BSDL and proof of its verification.
Unfortunately, too many IC vendors still do not have a good process for creating,
certifying and maintaining BSDL. You should not assume that a vendor’s BSDL
is verified and up-to-date. Ask questions like these:
• How is your BSDL created?
• How is it verified for syntactic and semantic correctness?
• Is it verified against the actual silicon (or a simulation thereof)?
• How is it distributed?
• How do you notify users about updates or changes that may be needed?

5.2 Board-Level DFT

Once we have ICs with robust implementations of 1149.1 and verified BSDL, we
can tackle the problems presented by boards. Some of these problems will be easier
to handle since the ICs should have been designed (see DFT-13) with thought
towards their solution.

5.2.1 Chain Configurations

Most of the discussion about Boundary-Scan chains has been in the context of sim-
ple chains. Other configurations are possible as well. These can offer some marginal
advantages, but it is important to look at the difficulties these will present to soft-
ware as well.
A simple chain has a single TCK and TMS signal broadcast to all members of the
chain. The TDO signal of the first component is cascaded into the TDI of the next com-
ponent, and so on, until all components have been threaded together linearly. Throughout
this discussion, the optional TRST* pins that may exist on some of the components are
assumed to be driven by a common signal, but we will generally ignore TRST*.
A board may have one or more simple chains. If two exist, for example, and we
want to perform interconnect testing on signals that connect the Boundary Registers
of the two chains, we must operate the two chains in parallel. There is no reason to
have the two chains in different TAP states while testing progresses, so you could
188 5 Design for Boundary-Scan Test

TDI1 ... TDO1

TDI2 ... TDO2

TCK
TMS
SiamMTDI

Fig. 5.7 A conjoined chain pair with common TCK and TMS signals, but independent data paths.
Any number of chains could be linked in parallel this way

drive the two TCKs and TMSs from one tester driver each. This realization then
suggests having common TCK and TMS signals on the board, as shown in Fig. 5.7.
This is the first example of a conjoined chain.
The conjoined chain of Fig. 5.7 effectively takes a single TDI/TDO data path and
turns it into a multiple-bit bus. An obvious reason to do this would be to increase the
amount of data shifted through the combined chains per TCK cycle. Note however,
that the individual TDI/TDO paths will very likely have different lengths because
different numbers of components exist in each chain, and each component may
contain registers of differing lengths. This will require care to manage and if the
disparity in lengths is great, it will reduce the throughput advantage.
The second form of conjoined chain (shown in Fig. 5.8) has a common TCK
signal. Then, two otherwise linear chains with independent TMS signals share the
board-level TDI and TDO signals, which can be done since TDO is disabled when-
ever the TAP is not in a shift state. It requires us to operate the chains separately,
which can be done by manipulating the separate TMS lines. This operation is a good
bit more complex because whenever we want to shift data into one chain, we have
to keep the other chain in a non-interfering state, such as Pause-IR or Pause-DR.
While this configuration will work in principle, it does not appear to be of much
practical value; it saves one TAP signal compared to the conjoined chain in Fig. 5.7,
but it does not save any overall shift time and has a more complicated protocol.
Third, we have dynamically reconfigurable chains. These structures are essen-
tially a set of simple chains that have their TDI/TDO data paths linked together by
5.2 Board-Level DFT 189

...
TMS1

TDI ... TDO

TCK
TMS2
SiamMTMS

Fig. 5.8 A conjoined chain pair with separate TMS lines, common TCK, and shared board-level
TDI and TDO signals

multiplexers or more complex switching networks.26 At least two commercial ICs

exist (the Texas Instruments 74ACT8997 and 74ACT8999) that will perform these
functions. While some software exists that can manage dynamic reconfiguration, a
much simpler test approach is to set a configuration, then freeze it for the duration
of the test.
• DFT-15: Before designing a board-level chain configuration, be sure that the
software that will be used during testing will support it.
Finally, we have field-programmable chains, where some number of the devices in
the chain are composed of field-programmable ICs. Since these devices could have
their 1149.1 circuitry altered or even erased27 when they are programmed, they should
be considered volatile members of the chain. If these volatile members are distributed
throughout the length of the chain, then their programming could cut the chain into
many small segments which will reduce the value of the remaining 1149.1 devices.
Therefore, it would probably be a good strategy to place all field-programmable ICs

26
The 1149.1 Working Group has not issued an opinion on the merits of dynamic reconfiguration.
This capability seems to be more properly the realm of system-level test bus schemes, such as
IEEE 1149.5.
27
Smaller FPGAs may not contain a permanent 1149.1 facility because of cost considerations, so
the 1149.1 capability may be implemented by programming the devices to have one and later
overlaying that configuration with a mission configuration. The trend today is toward much larger
devices containing permanent 1149.1 facilities.
190 5 Design for Boundary-Scan Test

TDO
TDI ...
TCK1
TCK
TCK2
TMS1
TMS
TMS2 BufrdTAP

Fig. 5.9 A simple chain with buffered TCK and TMS signals needed to avoid overloading

together in the chain ordering, either at the beginning or end of the chain. This way,
the remainder of the chain remains intact. You will need to provide access to the TDI
and TDO signals of the non-volatile segment of chain.
• DFT-16: If there are field-programmable components in a chain of 1149.1
devices, group them together in the chain order and place the group at either
end of the chain.

5.2.2 TCK/TMS Distribution

If an appreciable number of components in a simple chain on a board contain the

1149.1 capability, then it may be necessary to buffer the TCK and TMS signals, as
shown in Fig. 5.9. This example shows a simple chain with two logically identical
nodes (TCK1 and TCK2) for TCK and (TMS1 and TMS2) for TMS.28
Now, a pair of simple buffers has been shown in Fig. 5.9, but in many real cases,
the distribution of the broadcast TCK/TMS signals is done using a more complex
component. This component might require conditioning (initialization or enabling)
that essentially interposes a complex function29 between the board-level TCK/TMS
signals and the simple chain. Automated software that attempts to identify the
chain(s) on a board for test generation may decide that the configuration of Fig. 5.9
is really two separate simple chains.30 This is because it has no way of determining

28
The buffering IC cannot itself be an 1149.1 design in the same chain (unless it is maintained in
BYPASS) since its Boundary Register, during EXTEST, would prevent the TCK/TMS signals
from being distributed.
29
See also the discussion of Boundary-Scan Masters in Sect. 5.2.7.
30
To manage the two separate chains, nodal access to the TDI/TDO node at the junction of the two
chains will be necessary. Then it will not be possible to run the two chains simultaneously, since
driving TDI of the second chain overwrites TDO from the first.
5.2 Board-Level DFT 191

Fig. 5.10 A low-skew

clock buffer with 50 %
CLK1
duty cycle preserved by
utilizing inversion
CLK2
CLK
CLK3

CLK4
ClkTree

(without intervention) that TCK1 and TCK2 are really buffered copies of TCK, and
similarly for TMS. This leads us to another DFT consideration.
• DFT-17: Utilize simple buffering (where possible) of the broadcast TCK/
TMS signals. Document the enabling and initialization requirements needed
to preserve the 1149.1 protocol through TCK/TMS distribution.
If a board-level oscillator is used to drive TCK, be wary of clock distribution
buffers. Such components are usually needed in sensitive clocked systems to
produce high-power low-skew copies of the main clock frequency. Such compo-
nents may contain a buffer tree as shown in Fig. 5.10. The inversion in the signal
path is used to help maintain a 50 % duty cycle. If the IC is simply used to buffer an
oscillator output for a system clock, there is no phase relationship to maintain
between CLK and CLK1-4. However, if such a buffer is used for distributing TCK,
then the inversion is indeed a critical matter since it may confuse software.
• DFT-18: Do not allow logical inversion in the TCK or TMS pathways.

5.2.3 Mixed Logic Families

Mixed logic families at the board level may require voltage level translation of the
logic signals between ICs. This will also be true of the TAP signals if some of the
ICs of a chain are implemented in different families, such as pictured in Fig. 5.11.
Here we see a simple chain with some ICs implemented in TTL logic and some
in ECL. We must translate the parallel signals between families as the upper con-
verter in Fig. 5.11 does. The question is, does this IC contain 1149.1 as well? If so,
what family does each of its TAP Pins belong to? If the upper converter is not an
1149.1 IC, how can software keep track of the data flowing from IC 3 to IC 4
through the converter during interconnect testing?
The lower converter of Fig. 5.11 translates the TAP signals for the ECL portion
of the chain. The lower converter must not be an 1149.1 component since that would
prevent the transmission of TAP signals to the ECL portion of the system when the
lower converter was in EXTEST.
192 5 Design for Boundary-Scan Test

TTL TTL ECL ECL

Convert
TDO
U1 U2 U3 U4
TDI

Convert
TCK
TMS
TTL ECL
TTLECL1

Fig. 5.11 A simple Boundary-Scan chain containing ICs from different logic families. Logic level
conversion must be made between them

TTL TTL ECL ECL

Convert

TDO
U1 U2 U3 U4
TDI
TCK
TMS
Convert

TTL ECL TTLECL2

Fig. 5.12 A simple Boundary-Scan chain with a scanned level conversion interface for the parallel
signals. Note the TCK and TMS lines must not have a scanned conversion

Figure 5.12 shows the same simple chain as in Fig. 5.11, but with a Boundary-
Scan implementation for the conversion of the parallel signals. Notice that the TDI/
TDO data path is converted by the scanned converter IC as part of its TAP port
function. The conversion of TCK and TMS must be done with a conventional
non-scanned component.31 This introduces the same problems we saw (in Sect. 5.2.2
on page 201) with respect to buffered TCK/TMS distribution.
• DFT-19: When mixed logic families are used on a board, use scanned level
converters for the parallel signals and a non-scanned level conversion31 for
TCK/TMS distribution.

31
The device could be an 1149.1 device, but it must reside in another independent chain that is not
being tested at the same time; the converter would be in BYPASS.
5.2 Board-Level DFT 193

RAM

Address
C U Select
Data
CU C U RAM

Address
TDI U1 TDO
Select
DrCnflct

Fig. 5.13 A Boundary-Scan IC during test can set two normally complementary outputs to the
same state, exciting conflicts in conventional ICs downstream

5.2.4 Board Level Conflicts

One very important point to continually emphasize is that Boundary-Scan driven

activity on a board is radically different from normal activity. This means that nodal
constraints that are part of a board’s design will not be honored during Boundary-
Scan testing.32 This can lead to conflicts [Eklo01] if we are testing a mixture of scan
and non-scanned components, such as we see in Fig. 5.13.
Figure 5.13 shows a Boundary-Scan component with signals that propagate to
two chip selects on RAMs not containing 1149.1. During normal operation, the two
chip selects are always complementary (barring a fault). During testing, they may
both have enabling values that cause the RAM outputs to conflict. The duration and
intensity of these conflicts are of concern since they could damage33 the RAMs. If
such conflicts are not tolerable, it may be necessary to remove these nodes from our
list of nodes that will be tested by Boundary-Scan. The nodes could be constrained
to safe states rather than be tested.34 We could use RAMs containing 1149.1, or
redesign the circuit such that the RAMs have an alternate method of being disabled
not subject to Boundary-Scan signaling.
• DFT-20: Check conventional portions of board circuitry that may be
affected by Boundary-Scan test data for damaging conflicts that may be
induced. Design disable methods into these portions that will make them
insensitive to this testing activity.

32
Remember that these constraints will not be honored by failures either.
33
Damage could occur in the driver circuitry, or if several drivers are in conflict on one IC, their
summed currents could damage power distribution wiring.
34
If Boundary-Scan receivers are present on constrained nodes, then the constraints can be cap-
tured and verified, yielding a partial test of the nodes.
194 5 Design for Boundary-Scan Test

U1

U3 A U4

TDI TDO

C
U2

AddNails

Fig. 5.14 Two Boundary-Scan nodes A and B need additional support from tester resources to
enable proper testing

5.2.5 Control of Critical Nodes

During Boundary-Scan testing, it is important to be able to control certain nodes

on a board that may not have direct Boundary-Scan control. Typically, this occurs
at the border between scanned and non-scanned portions of the circuitry.
Figure 5.14 shows two such situations.
First, Fig. 5.14 shows a Boundary-Scan node A between ICs U3 and U4 that can
be interconnect tested if conventional IC U1 can be turned off so as not to interfere.
To support this, we need a tester resource on the enable of IC U1 that can apply a
disable value to U1 while Boundary-Scan tests are running.
• DFT-21: Provide for the ability of a tester to disable conventional ICs whose
outputs would otherwise conflict with nodes involved in Boundary-Scan tests.
Second, Fig. 5.14 shows a digital node C that has weak drive capability because
of the analog filtering it has undergone. A short between nodes B and C will not be
visible because C is too weak to interfere with the driver of B. Again, a tester
resource can be used to supply a strong value to node C, such that a B-to-C short
will cause B to fail.
• DFT-22: Provide for the ability of a tester to create strong drive values on
weak nodes.
Third, if any Boundary-Scan ICs possess compliance enable pins then the nodes
attached to these pins need to be conditioned to the enabling state before and during any
Boundary-Scan testing. Note that some ICs may also have a Test Reset (TRST*) pin.
It will be very important to locate all nodes attached to Test Reset pins so that they can
5.2 Board-Level DFT 195

be held high during testing. (In this respect, they can be thought of as compliance
enables too!) This leads to:
• DFT-23: Make sure you locate and condition all Test Reset (TRST*) pins
and all compliance enable pins before executing any Boundary-Scan tests.
In these cases we are arguing for additional tester resources, and access to criti-
cal board nodes [Albe01]. If this access is unavailable, we must find another means
to accomplish our goals, or accept degraded test coverage.

5.2.6 Power Distribution

On boards with a hybrid analog/digital design, it may be very dangerous to run

Boundary-Scan tests on the digital portion of the circuitry since the apparently ran-
dom data may be having an undesirable impact on the analog circuitry. For example,
the analog circuitry may have considerable power handling capability and be subject
to severe damage (to devices, the board itself, the tester, and even the equipment
operator) if improperly excited. Such risk could be alleviated if critical analog power
supplies are separated from the digital power supplies. Separation could allow the
powering of only the digital portion while Boundary-Scan tests are running.
• DFT-24: Design analog and digital subsystems such that the analog power
can be shut off while Boundary-Scan testing is being done.
The non-powered analog nodes will now have no drive capability and could
therefore not be tested for shorts to digital nodes. See Sect. 5.2.5 for a discussion of
this problem. If 1149.4 (see Chap. 7) is in place in mixed-signal ICs, then that may
change the nature of this consideration since 1149.4 can be used to disable key ana-
log signals.

5.2.7 Boundary-Scan Masters

At least two examples exist in the commercial IC market of ICs called Boundary-
Scan masters.35 These ICs form an interface between a microprocessor and the 1149.1
TAP Port. They execute the useful function of performing a parallel-to-serial conver-
sion directly in hardware from a “common” microprocessor interface as depicted in
Fig. 5.15. They also contain some hardware support for testing functions.
From a board-test point of view, Boundary-Scan masters have a completely dif-
ferent effect. They convert a standard testability port into a non-standard parallel
protocol. Since general 1149.1 software is not likely to directly support this parallel

35
They are the Texas Instruments 74ACT8990 and the AT&T 479AA.
196 5 Design for Boundary-Scan Test

TDI
Data Bus
TDO Boundary-
Boundary-
uProcessor TCK Scan
Control Scan
TMS Chain
Interrupts Master
TRST*

CLK
BusMastr

Fig. 5.15 A Boundary-Scan master interfaces between a microprocessor on one side and 1149.1
on the other. (The directions of TDI and TDO are reversed, reflecting mastership.)

protocol,36 the Boundary-Scan master must be circumvented by an ATE system to

gain access, either logical or physical, to the 1149.1 port. Logical access could be
obtained by having a “transparent” mode where the master could pass through TAP
signals from the parallel side. Physical access would consist of standard In-Circuit
overdrive of the 1149.1 side of the component; perhaps made easier by having the
master disable its TAP drivers. Nail access would have to be anticipated.
• DFT-25: If a Boundary-Scan master is used in a board design, provide for test
equipment access and control of the 1149.1 side of the master’s interface.
Other ICs called Scan-Path Linkers (like the Texas Instruments 74ACT8997)
and Scan-Port Selectors (the Texas Instruments 74ACT8999) may be mounted on a
board. These ICs are not parallel-to-serial protocol converters. Rather, they take a
set of 1149.1-driven commands and create a pathway through an attached set of
simple chains.
Once the path is set up as shown in Fig. 5.16, it will behave as one expects an
1149.1 chain to act, with the following exceptions: the start of a linked or multi-
plexed simple chain is prepended with a single, additional shift-register stage and a
selected register37 is appended to the end of the simple chain. The prepended and
appended stages are contained within the same Linker/Selector IC. If several simple
chains are linked together, additional shift register stages are sprinkled through the
concatenated result. This forms a rather exotic chain structure, which may prove
troublesome for general 1149.1 software to comprehend. The foregoing DFT rule,
DFT-25, applies here as well.

36
The vendors of Boundary-Scan masters usually supply supporting software for their components
to facilitate prototyping and the development of microprocessor software or firmware. Such soft-
ware is usually not of general use outside of this environment.
37
The selected register is a function of the instruction loaded into the TAP Instruction Register of
the Linker/Selector IC.
5.2 Board-Level DFT 197

ScanLink

A1 A2 Ai

TDI
* ...

B1 B2 Bj

* ...

C1 C2 Ck '8997

TDO
* ...

Fig. 5.16 The 74ACT8997 Scan-Path linker IC linking simple chains A, B and C. Extra shift
stages (marked with “*”) are inserted in the linked chain. These stages are actually resident in the
‘8997, which itself appears in a normal 1149.1 form at the end of the chain

5.2.8 Post-lobotomy Board Behavior

As we saw in the case of Integrated Circuits, we must concern ourselves with the
behavior of a board after a Pin-Permission operation of any component(s) in a
Boundary-Scan chain has lobotomized the board [Park10, Park11]. Assuming the
1149.1 components take care of themselves—for example, by staying in a quiescent
state after a Boundary-Scan operation completes—we still must take care that a
board will do the same. This is because a board might have non-scan components
that are not privy to the facts of 1149.1 life.
• DFT-26: Ensure that a board, after any 1149.1 operation completes, will
have safe states on all components and nodes.
On complex boards where this analysis may be difficult, one could add a special
feature to the board reset logic, a general hold-reset feature that can be triggered at
198 5 Design for Boundary-Scan Test

the start38 of 1149.1 testing. This hold-reset function would clamp the reset line(s)
of the circuit into the reset state such that all non-scan components would be held
quiescent. After Boundary-Scan testing, a board-level general reset would clear out
the hold-reset function and bring the board back to orderly operation. Perhaps the
simplest way to do this might be to cycle the power on the board.
It is important to be aware of any such precautions that may be built into a board,
for it will influence the operation of subsequent tests. For example, if 1149.1 testing
leaves the board lobotomized, then a general reset of some type will be necessary if
any later, conventional digital testing is to be done. If any board-level Built-In Self-
Tests are to be executed with the aid of Boundary-Scan, these should not be disabled
by the hold-reset function. Of course, the more ICs of a board that implement
1149.1, the less of a board-level problem you should have.
Note that the 2013 release of 1149.1 provides for the concept of “Test Mode
Persistence” which is a tool that test engineers may use to help manage post-
lobotomy behavior of a board. See 11.3.4.1 in Part 2 of this book.

5.3 System-Level DFT

A system, for the purpose of this discussion, is any collection of boards, modules, or
boxes that operate together. (This is a much higher level than the “System Logic” defined
in the 1149.1 Standard as the mission logic of one IC.) If the 1149.1 Standard has been
used in their design, then it is desirable to reuse this investment for system testing.
It is quite easy to imagine that a system, of boards for example, each containing
a simple Boundary-Scan chain, are simply concatenated together into one (very)
long simple chain. There is nothing wrong with this approach, in principle.
The practical problem of the length of the chain exists. However, the BYPASS
function helps us eliminate useless shift positions. If the number of nodes that pass
between boards is limited, or if these nodes do not connect a significant percentage
of all system ICs, then one can imagine system-level interconnection tests that do
not require terribly long shift paths. Again, many ICs would be in BYPASS mode.
Another problem is more significant; many systems may be populated with a
mixture of boards, and missing boards (empty slots) may be permissible. This leaves
us with chains whose construction is a function of the mix of boards in the system,
or chains that are broken by empty slots. We call this the multidrop problem.

5.3.1 The MultiDrop Problem

Figure 5.17 shows an example of a system implemented with a single simple chain.
Any missing board in the system causes a break in the TDI/TDO chain. This could
be healed with a jumper board that connects TDI to TDO, but jumper boards are not
popular and are typically removed from a system as a design goal.

38
Of course, the access to nodes needed for this capability should have been provided as noted in
rule DFT-21.
5.3 System-Level DFT 199

TDO
TMS
TCK
TDI

Missing
Board 1 Board 2 Board 4
Board 3
BackPlan

Fig. 5.17 A system of several boards where each slot may accept several board types, or not con-
tain a board at all. A simple 1149.1 chain through these boards would be broken at an empty slot

It is also a problem, from a software standpoint, to determine how, from a mix of

boards and empty slots, a system is populated. The concept of Blind Interrogation
has been proposed to identify which chips exist in a chain of components. Blind
Interrogation is done by starting in Test-Logic-Reset and proceeding directly to the
data column to shift out either the IDCODE registers or BYPASS registers of the
chained components. If IDCODEs exist in enough ICs, then, in principle, you can
deduce from the ID codes which chains (and thus which boards) exist in a system.
Jumper boards will not be identified unless they contain an 1149.1 IC with the pur-
pose of identifying the boards as jumpers.
If a mix of boards is allowed, then tests for such a system must be constructed
after the mix is identified. Identification can take some time and require a potent
computing resource rather than a simple test sequencer. In conflict with this in many
cases is a system test requirement for fast testing with a simple, inexpensive (per-
haps portable) piece of controlling equipment. The sum of these objections has
made system-level, 1149.1-based testing problematic. See also the IEEE 1149.5
standard briefly discussed in Sect. 5.3.2.
• DFT-27: Restrict 1149.1 implementations for system tests to simple system
architectures not containing a multidrop scheme.
200 5 Design for Boundary-Scan Test

5.3.2 Coordination with Other Standards

IEEE Standard 1149.5 [IEEE93b], the “Standard Module Test and Maintenance
(MTM) Bus Protocol”, offers a way to add hierarchy to a system containing 1149.1-
based boards. It allows—via an 1149.5 bus—the addressing of individual boards,
sets of boards or all boards for an operation. Addressing of boards allows us a
mechanism for dealing with the multidrop problem. This entails having an 1149.5
controlling IC on each board, as well as one other such IC in the test and mainte-
nance unit of the system. One such component is the “master” and all others (up to
250 or so) are “slaves.” Mastership can be passed to a slave. Once on a board, the
1149.5 protocol can be used to control an 1149.1 chain.
The possibility exists that other approaches to managing multiple 1149.1 chains
will become industry standards. We have already seen two ICs with this potential, the
74ACT8997 and 74ACT8999 Linker and Selector ICs. The work by Whetsel [Whet92]
shows how 1149.1 could be extended with the concept of an “Addressable Shadow
Port” device that uses a “shadow protocol” to link 1149.1 boards together in a back-
plane structure. This device is available as the 74ABT8996. The hurdle any such ICs
must overcome to become de-facto standards is to gain widespread software support.
Much work has been published on ways to create a testing hierarchy (for exam-
ple, see [Avra87, Breu88] and [Derv88]). The work reported by Dervisoglu39
[Derv88] gives a case study of a real implementation successfully carried out for a
workstation product. See also more modern works dealing with System on Chip and
backplane approaches [Ke96, Whet97, Barr00, Oakl00, Harr01, Verm02].
It is interesting to note that the hierarchy problem is also occurring in the micro-
cosm of core-based ICs, or appropriately, Systems on a Chip. Here the problem is
that several IC designs are integrated together onto a single silicon substrate. What
do you do if some of these designs also contain 1149.1? The effect of this has been
studied in [Jarw94]. (On reflection you will note that this is just like the problem
with MCMs that contain several 1149.1 compliant die.) The resulting IC is not itself
compliant to the 1149.1 Standard, but can be thought of as a collection of 1149.1
entities, each with a BSDL description. Jarwala [Jarw94] also made some other sug-
gestions; it is too early yet to see where the industry is going with this situation.
Further, with the advent of stacked ICs, some of which could contain Boundary-
Scan, there is yet another technology evolution to watch out for.
It is difficult to give solid design-for-test rules for scan-based systems other than
to say that if a standard should emerge for this, use it!

39
The scan-based architecture reported by Dervisoglu predates the 1149.1 Standard and is signifi-
cantly different in the details.
5.4 Summary 201

5.4 Summary

Boundary-Scan offers great potential to solve emerging test problems that have
staggered yesterday’s testing technology. Many companies are well into 1149.1
implementations and have progressed well up the learning curve. A statement from
one test engineer summed up his experience;
I really like Boundary-Scan. Now I can work on improving test coverage rather than just
getting a test to work at all.

We have seen a growing percentage of ICs that contain Boundary-Scan, particu-

larly among the larger ICs. Formerly troublesome FPGA/CPLD ICs are now stan-
dardizing on 1149.1. Automatic insertion of 1149.1 by synthesis tools is becoming a
reality as well as the automated production of BSDL. But all is not rosy. The single
most detrimental problem still remains compliance to the Standard with accurate
BSDL descriptions. This problem will be solved, but it seems we must cure
the offenses with economic pressure. You are wise to question the compliance efforts
of the vendors you patronize and to take your business elsewhere when their sincerity
is shown to be questionable. IEEE 1149.1 has become a vital contributor to the prog-
ress of the electronics industry. As such, all parties need to treat it with respect.
One other warning must be given to manufacturers. If you have a manufacturing
process that is capable of fairly good yields before testing, then 1149.1 is a good tech-
nology to pursue. If your manufacturing process is of low or erratic yield, then
Boundary-Scan may be disappointing. You could spend a lot of time chasing chain
integrity problems rather than in fruitful testing. Keep this in mind when venturing
into new technologies such as Multi-Chip Module (MCM) or stacked IC technology.
Chapter 6
Analog Measurement Basics

The preceding chapters of this book have confined the discussion to digital circuits
and test subjects. Most electronic engineers are experts in digital technology but
many will admit that their familiarity falls off quickly when the discussion turns to
analog topics, particularly analog testing. Before getting into IEEE 1149.4 Analog
Boundary-Scan, it will be important to lay a foundation for basic analog measure-
ments used today in In-Circuit testers. While 1149.4 does have significant differ-
ences over classical In-Circuit test, there are a lot of similarities. Knowing where we
came from will also help motivate where we are now going.
Nearly every board ever produced has analog components on it, even those
boards called “digital”. This amounts to perhaps hundreds of analog components
per “average” board. Over the last 25 years, it would be no exaggeration to claim
that one billion (109) of these boards have been tested with In-Circuit techniques. So
how have these several hundred billion components been tested? It serves as excel-
lent background to take a look at how In-Circuit testers do this.

6.1 Analog In-Circuit Testing

How does a typical In-Circuit tester test analog components mounted on a board?
First, assume we have a bed-of-nails fixture such as we saw in Fig. 1.2 on page 6.
This fixture gives us nodal access to every terminal of each analog device. But
before we jump into the discussion of testing these components, let’s first agree on
what it is we are testing for.

© Springer International Publishing Switzerland 2016 203

K.P. Parker, The Boundary-Scan Handbook, DOI 10.1007/978-3-319-01174-5_6
204 6 Analog Measurement Basics

6.1.1 Analog Failures

In-Circuit test is a “divide-and-conquer” technology (when we have access). This

provides its strength in testing individual components rather than entire networks.
When you test individual components, you verify the construction of a network of
arbitrary complexity. If a network is properly assembled from a set of components,
each tested and verified to be the correct device and in working order, they should
work together as the designer of the network intended. If they do not, it could be due
to a reliance on unspecified parasitic relationships among some of the components.
Commonly called “parasitics”, they can be modeled as additional components in a
network, typically with small values. While the values may be small, they could be
significant to the operation of the network.
For example as in Fig. 6.1, a filter’s performance may depend on parasitic capac-
itance CP between a “real” capacitor C and the windings of a nearby inductor L. If
an engineering change causes the network to be laid out a little differently, the para-
sitic component may be changed causing the circuit performance to change. The
manufacturing team (and the designer) may puzzle over this change for a while,
looking for a cause.
It is not the primary role of In-Circuit test to test the overall functionality of net-
works, but rather to prove their proper construction and to verify all the physical
(i.e., non-parasitic) components are correct and operational. Parasitic relationships
that a network may depend upon for proper performance are tantamount to compo-
nents missing from a netlist description of the network. Since these devices are not
specified, the programming process for the In-Circuit test will be unable to account
for their effects.
If unspecified parasitic relationships are important to the operation of a network,
one may question the quality of the design of this network. In essence, to effectively
manufacture the device, some new “tests” (often called “Performance Tests”) may
be needed to ensure the network performs as the designer intended.
For example, consider a capacitor that has one terminal connected to the outer-
most surface of the plate structure. The parasitic capacitance between this surface
and another component nearby may be necessary for network performance. However,
if the capacitor is reversed so that the opposite terminal is connected instead, the
network may no longer perform correctly. Thus, an additional test is needed that
verifies the orientation of this ceramic capacitor (assuming we know of this require-
ment). Such a test may require a new process step such as visual inspection of the

Fig. 6.1 A simple filter

circuit and the actual
circuit when parasitic
capacitance is included
C CP C
L L
R R
ParasitC
6.1 Analog In-Circuit Testing 205

Number of Devices

-5% Nominal +5%

Resistor Value in Ohms BellDist

Fig. 6.2 Distribution of resistance values for a 4.7 kΩ resistors with a tolerance of ±5 %

capacitor, which may significantly increase total test costs. But more costly may
have been the process that discovered the need for this new test, or the “bone pile”
of functionally faulty boards that grew before this problem was identified. Then
there is the problem that the vendor of the capacitor may change how it is labeled
(which serves as the visual clue to its construction) or a similar but differently con-
structed capacitor may be used from an alternate source.
In-Circuit test is able to measure the value of analog components1 such as resis-
tors, inductors and capacitors. These devices have nominal values specified for the
design, and a tolerance on this value. For example, a resistor may have a nominal
value of 4.7 kΩ, ±5 %. Thus if we measure the resistor we expect it to have a value
of 4.7 kΩ ± 235 Ω. In a sample of these resistors, we might expect to see a truncated
bell curve for the distribution of values as seen in Fig. 6.2.
What if we measure this resistor and see a value that is high or low by 240 Ω? Is
this a failure? The answer is clouded by the fact that the measurement process itself
may inject errors (see Sect. 6.1.3). It also happens that the circuit design itself could
tolerate a 10 % deviation, but the designer only has 5 % resistors available to save
on inventory costs. In this case, testing for a 5 % deviation could be failing perfectly
functional boards. To avoid rejecting good boards, test engineers will add a guard-
band to the (true) tolerance on the device value. This might be an extra 1 %, or it
could be surprisingly large, for example, tripling the tolerance.
In summary, analog In-Circuit testing of a circuit can be used to prove the con-
struction of a set of specified analog components. This may not be enough to ensure
the operation of the circuit when parasitic impedances are present. However, it is
also true that In-Circuit test has practical limits on the range of component values
that may be tested. As we see in Sect. 6.1.3, combinations of components in certain
interconnection topologies may be difficult to test.

1
Real components, not parasitics.
206 6 Analog Measurement Basics

6.1.2 Measuring an Impedance

To measure the value of an impedance R, we make use of Ohm’s law in one of the
two configurations shown in Fig. 6.3. Figure 6.3a shows an ideal current source
forcing a known current through the impedance while a perfect voltmeter measures
the voltage across the impedance. The value of R is computed by dividing the mea-
sured voltage by the known current:
R =V / i
Of course, the world is neither ideal nor perfect, so in reality we would have to
take some care that errors are not introduced. For example, the voltmeter provides
an alternate pathway around the device being measured so we may find some of the
stimulus current taking that pathway rather than going through the device. However,
since the input impedance of a voltmeter is typically 1010 Ω, the amount of current
being sidetracked is likely to be insignificant.
Next, we should take a moment to think about the current source. An ideal source
will force a specified current, developing whatever voltage is required. However, if
the device is a low-power device, it could conceivably be damaged by the power
dissipation (V*i) such a current and voltage would necessitate. Higher voltages
could also damage diode junctions by causing voltage breakdown.2 This presents us
with a problem; in order to keep the voltages in safe operating limits, we need to
know an expected value (approximately) for the device being measured. But if it is
truly an unknown value, then we need a compliance limit on the current source.
A compliance limit is an upper bound on the voltage the source will develop and
hence a bound on the both the voltage and the energy it will supply.
Whenever we use the setup in Fig. 6.3a, it is assumed that the current source is not
in compliance (not limited). If the device to be measured is a true unknown, the first
selected current setting may produce a compliance limit signal and a different (lower)

R R

+
i V I
V -

A B EisIR

Fig. 6.3 Measuring impedance with current source stimulus (a) and with voltage source stimulus (b)

2
As we will see later in this section, we also have to be careful of other devices surrounding the
device we are testing.
6.1 Analog In-Circuit Testing 207

current should be tried. This process should eventually converge3 on a ­current setting
that stays within the compliance limit and yet develops a measurable voltage across
the resistor. However, if the current source is set too low, then the voltage across the
resistor will be small, perhaps sacrificing some voltmeter accuracy as a result. Thus
we look for a current setting that is high enough to utilize our voltmeter accuracy, but
not too high to damage the device under test. (Other criteria will appear shortly.)
Another stimulus/measurement configuration is shown in Fig. 6.3b. Here we use
a voltage source to provide a known voltage across the resistor and a current meter
to measure the resulting current. Note the ideal current meter has zero series imped-
ance, so there is no voltage drop across it. (This means the right side of the resistor
is at zero volts.) The ideal voltage source will develop the desired voltage with
whatever current is required by the circuit. As before, this could result in a damaged
resistor if the energy delivered is too great. Therefore we need a current compliance
limit (an upper bound) on the voltage source current capability. Again, if the value
of R is unknown, we may need to search for a voltage setting on the voltage source
that does not cause a compliance condition,4 yet gives us good current measurement
accuracy from the current meter.
So we have seen it is not necessarily straightforward to measure the impedance
of a simple freestanding resistor. If its value is unknown, or if there is an anomaly
present such as a short or open circuit, this leads to special considerations. However,
freestanding components will be the exception and not the rule when testing boards.
The situation shown in Fig. 6.4a will be quite common. Here, a resistor is connected
between board ground and an integrated circuit output. How do we go about testing
the value of the resistor?
In Fig. 6.4a we have access to both sides of the resistor we want to test, but there
are other components connected to the resistor as well. Inside the silicon device we
see two transistors connected to the resistor. What effect will these have on our
simple measurement process?
To answer this, we first remember that In-Circuit analog component testing is
done with no power applied to the board. This means that the transistors inside the
IC are not turned on. Further, if we limit the voltages used during testing to values
that will not turn on a diode,5 perhaps less than 0.2 V, then the silicon junctions
within the IC will never conduct current. This makes the IC “disappear” from our
problem. However, reality intrudes again when we consider the physical apparatus
needed to measure the resistor. This is the In-Circuit tester itself.

3
There is the case where the impedance is infinite because of an open circuit. In this case the pro-
cess of finding a current setting will converge on zero.
4
It is possible that the search would converge on zero volts in the case where the value of R was
zero, such as in the case of a short circuit.
5
Not shown in this figure are Electrostatic Discharge (ESD) protection diodes often found between
IC pins and the power rails. These diodes can provide additional conduction paths if they turn on.
208 6 Analog Measurement Basics

+V R
Board Power Plane A G

U1 Fixture

Probe
Mux

A Measurement Buses

R + Stimulus/
V Measurement I
-
Resources
G
Board Ground Plane ATE Ground Plane

A B ICTMeas

Fig. 6.4 Measuring the impedance of a device on a board, connected to a silicon device (a), and
as seen by an ATE system (b)

Figure 6.4b shows the elements of a typical In-Circuit tester. Nails from the bed-
of-­nails fixture touch the nodes A and G on either side of resistor R. Within the fix-
ture, wire-wrap wires connect the nails to the fixed array of tester channels that, in
this diagram, are multiplexed to a measurement bus. The multiplexing is done with
mechanical reed relays that have several desirable qualities. First, reed relays have
very low “on” resistance, perhaps only 10−2 Ω. Second, when reed relays are open,
they have very high “off” resistance, perhaps 1012 Ω. They come close to being
“perfect” switches.6
From the measurement buses (Fig. 6.4b) another layer of reed relay multiplexing
brings us to the stimulus and measurement resources of the In-Circuit tester. This is
where we find the various forcing functions for voltage and current as well as mea-
surement devices for current and voltage. Figure 6.4b shows how the appropriate
relays are closed to set up the same voltage forcing measurement we saw in
Fig. 6.3b. The voltage source is set to less than 0.2 V to prevent the silicon junctions
in U1 from turning on. (Not shown in Fig. 6.4b are any control functions for the
relays and instrumentation.) With all of this complexity in the measurement path it

6
The switching time from open to closed is less than perfect, in the neighborhood of 500 microsec-
onds. They often take longer to open.
6.1 Analog In-Circuit Testing 209

U1 B R A
B R A
+ i
V Ra Rb I
Ra Rb -

C C

A B
B R A

Ra Rb

Fixture

Probe
Mux

Measurement Buses

+ Stimulus/
V I Measurement
-
Resources

ATE Ground Plane

C Delta

Fig. 6.5 Devices may be connected into networks providing parallel pathways for currents

should not be surprising that we have new sources of error. This will be covered in
Sect. 6.1.3, but next we examine complications in measurements due to parallel
device topologies such as seen in Fig. 6.5.
The parallel impedance problem is personified by the delta configuration of
impedances shown in Fig. 6.5a. Here we have three resistors and three In-Circuit
nails, plus a connected IC. We can make the IC “disappear” by doing unpowered
tests with low stimulus voltages as before. However, to measure the value of R
when Ra and Rb are present, we need something more to deal with the parallel path
problem. This is shown in Fig. 6.5b.
In Fig. 6.5b we see the familiar voltage forcing configuration on nodes B and A
seen originally in Fig. 6.3b, but with a new addition; a third node C is grounded
using a third nail. This is called guarding. Guarding uses low impedance paths
210 6 Analog Measurement Basics

through reed relays to insert grounded points into the circuit.7 If you examine
Fig. 6.5b closely, you will see that current from the voltage source splits at node B
and proceeds both to nodes A and C. However, because node C is grounded and
because node A is also grounded (the current meter has zero impedance), the volt-
age across Rb is zero. No current can flow to node A from node C. This means the
current meter measures only current through R. Thus we know the voltage across R
(the voltage source value) and the current through it which yields its impedance.
Figure 6.5c shows a typical ATE setup for measuring the resistor in a delta
configuration.

6.1.3 Errors and Corrections

As noted earlier, an ATE system is constructed from imperfect components. This

leads to unavoidable additional impedances in the measurement pathways. For the
example of measuring a simple resistance given in Fig. 6.4b, we find impedances
inserted along measurement pathways contributed by relays, nail contacts8 and wir-
ing. This is shown in Fig. 6.6a.
These error impedances will often be small compared to the value of the resistor
R, so if they sum into its value, the error may be small compared to the tolerance
associated with R itself. However, for smaller values of R, the errors could cause
our test to fail for some boards when the value of R is close to (but still within) its
tolerance limit.
Errors can be controlled by taking additional measurements; one example is
shown in Fig. 6.6b. Note that our voltage source is sending a significant current
around a loop containing the error impedances. If we make a new voltmeter mea-
surement9 as close as we can get to resistor R, we can get closer to the true voltage
appearing across it. This figure shows we can eliminate the errors in the ATE system
itself, but we still are seeing the fixture errors.
Figure 6.6c shows a more realistic situation. Here we have a single voltmeter
multiplexed to either path. We can get the same measurement result as in Fig. 6.6b,
but with two voltmeter readings taken in succession on the paths. Some additional
error due to this slightly more complicated process will result, and the process takes
more time.

7
An example at the macroscopic level of Heisenberg’s Uncertainty Principle. To measure the value
of a component with this technique, we must significantly perturb the circuit under test.
8
Relays will have sub-ohm resistances typically, but nail contacts may have resistances of 2 Ω and
higher depending on the cleanliness of the nail and board surfaces. Nail contact resistance may
increase with time but may be restored by periodic cleaning of nails.
9
Remember that because of its very high input impedance, the insertion of the voltmeter will not
seriously affect the current flow of the circuit.
6.1 Analog In-Circuit Testing 211

R R
A G A G

Probe
Impedances
Rp Rp Rp Rp

Rr Rr Rr Rr
Summed
+ Relay +
V I V V I
- Impedances -

A B
R
A R G A G

Rp Rp Rp Rp

Rr Rr Rr Rr

+ +
V V V I
- I -
V

C D
MeasErr

Fig. 6.6 Some sources of error in an ATE setup for measuring a simple impedance

Figure 6.6d shows how we could eliminate almost all error, by using a Kelvin
measurement. The voltmeter pathway is virtually independent of the path that car-
ries current. The cost, however, is significant because we now need two additional
In-Circuit nails. This configuration is rarely used unless we need a very precise
measurement of a very small resistance R.
Similarly, the delta configuration of Fig. 6.5 will also suffer from voltage errors
caused by currents traveling through relays, wires and nails. These are shown in
Fig. 6.7a. Of particular concern is the error impedance in the guard path (Rg) which
raises the voltage at node C above ground. This allows an error current to flow into
Ra and subsequently through Rb and on to the current meter. Ultimately, a higher
current reading yields a calculation of R that is lower than the actual value. Consider
just Rg; if Rg is 1 Ω and R is 10 kΩ while Ra and Rb are both 10 Ω, the calculated value
of R would be about 100 Ω. This is because the current circumventing R is nearly
100 times as great as that traveling through R.
212 6 Analog Measurement Basics

A B R A

+ Rs i Ri
V Ra Rb I
-
C
Error
Current
Rg

B B R A
Rs Ri
Ra Rb
C
+
V Rg I
-

DeltaErr

Fig. 6.7 Error impedances for a delta measurement (a) and a 6-wire measurement configuration (b)

This error can be corrected with additional voltage measurements taken from
nodes A, B and C with three additional In-Circuit nails as shown in Fig. 6.7b. This
is known as a 6-wire measurement and is expensive in nails and the time required
to do the additional measurements. Thus 6-wire measurements are done rarely,
when the ratio of component values in the original delta configuration are large and
there is need for good accuracy. See [Croo79] for more discussion of In-Circuit
measurement errors and corrections.

6.1.4 Measurement Hardware

Current meters are not usually supplied in ATE systems, but rather an operational
amplifier is used as shown in Fig. 6.8, where it is monitoring the same delta configu-
ration we have used in other examples. In this configuration (often called a
Measuring Operational Amplifier or MOA) the op-amp combined with the feed-
back resistor Rf will endeavor to keep node A at zero volts.
The value of R is calculated by this formula:
R = -V * R f / Vout
6.1 Analog In-Circuit Testing 213

Rf

B R A
-
+ Vout
+
Ra Rb
V
-
C

CVMOA

Fig. 6.8 An operational amplifier with feedback resistor used as a current meter

R Vout
-
- + Vout
V
+

Time T
OneInteg

Fig. 6.9 An operational amplifier setup to integrate a DC voltage V over time

So far we have confined the discussion to the measurement of static DC values.

To measure reactive components such as capacitors and inductors, we will need to
use AC voltages and currents. One way to do this is with a tool called a dual slope
integrator, which can be used for both DC and AC measurements. A dual slope
integrator is constructed from a basic integrator such as shown in Fig. 6.9.
This integrator is made from an operational amplifier with a high quality capaci-
tor10 C in the feedback path. The voltage Vout will be a highly linear ramp given a DC
input V, which is the solution to this equation:
T
1 VT
Vout = ò
RC 0
Vdt =
RC

which is both a function of V and the time constant of the system defined by the
product of R and C.
A dual slope integrator is similar, as shown in Fig. 6.10. It integrates the unknown
voltage Vin for a period of time T which produces a positive voltage Vout. Then a
known negative reference voltage Vref is switched in place of Vin, which causes a

10
This capacitor doesn’t need to be accurate (only stable over the period of measurement) but it
should have excellent characteristics with respect to dielectric absorption.
214 6 Analog Measurement Basics

R
-

Vout
+ Vout

- +
Vin Ref
+ - Time T T+X

TwoInteg

Fig. 6.10 An operational amplifier setup for DC Dual Slope Integration

downward ramp on Vout. The time X to reach zero volts is recorded. The dual slope
integrator is a physical solution to the equation:

æ 1 T 1
T+X
ö
ç RC ò0 in òV
ç V dt - dt ÷ = 0
RC
ref
÷
è T ø

This equation, when solved for the unknown Vin yields:

X
Vin = Vref
T

which is the product of the known Vref with the ratio of integration times X and T.
(Notice the time constant RC has dropped out of the equation.) Time is something
we can measure very precisely in digitally controlled systems. This allows us to
construct (in this case) a very accurate DC voltmeter that is largely independent of
the values of the components used.
As always, we do have to be wary of the non-ideal. Since we may not know the
approximate value of Vin before we measure it, we will have to guess at a value of
integration time T. If we guess too short, then very little ramp on Vout will occur with
an accuracy penalty. If our guess is too long, our integrator may ramp Vout beyond
the linear region11 of the integrator’s operation. We could have a selection of values
for R and C, selected with switches, to help us stay within the operating range. We
could also scale Vin with a ranging amplifier before integrating it. We still need to
know if our first guess at their selection was appropriate. Therefore the controller
for this apparatus will have to make one (or more) guesses, selecting values of T,
range amplification, and/or R and C, until a suitable ramp12 has been found.

11
This region will be within the power supply rail voltages of the operational amplifier.
12
To limit effects from environmental noise, we may restrict the values of T to those that will mask
out common sources such as low frequency power line noise.
6.1 Analog In-Circuit Testing 215

E
R
-
A B D + Vout
-1

Vin
+ A
Ref
-

Vin
Input to Integrator

T T+X

Time B
Vref
Vout

T T+X
C
Time
ACInteg

Fig. 6.11 A dual slope integrator modified for AC measurements

The dual slope integrator can also be used to measure AC voltages. We will con-
fine this discussion to sinusoidal waveforms of a known frequency, because in an
ATE system the stimulus portion of the hardware is under our control. Further, we
will also know the phase relationship of our AC sources so that we can lock the
phase relation of the measurement to them. This will allow us to measure the real
and imaginary components of a sinusoidal voltage waveform necessary for
­measuring values of reactive components such as inductors and capacitors. For AC
measurements, the dual slope integrator shown in Fig. 6.11 may be used.
If we were to measure a simple sinusoid with our DC integrator, every complete
cycle of waveform would integrate to zero, leaving us no information. If we integrate
the first ½ cycle and then invert the voltage and measure the second ½ cycle, we will
get a non-zero result. Looking at Fig. 6.11a, this is the purpose of switches D and E.13

13
Actually, switches D and E are conceptual. The AC voltages are digitally constructed by the
system sources. The system has complete on-the-fly control of the frequency and phase.
216 6 Analog Measurement Basics

Vin AC/DC
Dual Slope Vout
Integrator
Rs
-
Vstim Ref
+

MeasImag

Fig. 6.12 A dual slope integrator used to measure a reactive component

The sources are connected by either of switches A and B. The sinusoidal source has a
known phase so we can chose the portions of the sinusoid we are integrating and
whether the unity-gain inverter complements that portion. The DC reference voltage
source serves the same function we saw in Fig. 6.10 for DC measurements.
To measure an unknown AC signal Vin, first we integrate several full cycles of Vin
(with its known phase) taking care to invert the negative portions to positive until
time T has elapsed. Figure 6.11b shows this waveform. Then the negative DC source
Vref is switched into the integrator replacing Vin causing a downward ramp. The
integrated waveforms yielding Vout are shown in Fig. 6.11c. As with the DC case, the
process continues until Vout returns to zero while we measure time interval X. As
before, the measured value of Vin is computed as:

X
Vin = Vref
T

which again is a function only of the magnitude of the reference voltage and the two
time intervals we can measure accurately.
By controlling when we open and close switches D and E, we can select a phase
offset for a measurement. If we offset a measurement by 90° we can measure the
imaginary14 component of a waveform. An offset of 0° gives us the real component.
These two measurements allow us to compute values of reactive devices in net-
works. See the example in Fig. 6.12.
In Fig. 6.12 we want to measure a capacitor C. The In-Circuit nails give access
to both sides of C. An AC voltage source (we control its frequency and phase) is
connected to the capacitor through a known source impedance Rs and the other side
of the capacitor is grounded. After we close the nail relays, we can successively
measure the voltage on both sides of the source resistor Rs. Note however that we

14
Imaginary signal detection is sometimes called a quadrature measurement.
6.2 Limited Access Testing 217

Vin
Input to Integrator

T T+X

Time A
Vref
Vout

T T+X
B
Time ACImag

Fig. 6.13 Imaginary voltage waveform seen when measuring a capacitor

will offset the measurement by 90° with respect to the stimulus voltage source so
that we measure the imaginary voltage as shown in Fig. 6.13. We then compute the
imaginary current IC through the known resistor Rs. This plus the imaginary voltage
VC across the capacitor (the measurement at the top of Rs), along with the stimulus
voltage frequency FStim allows us to calculate the capacitor’s value of C.

IC
C=
( FStim *VC )

6.2 Limited Access Testing

In-Circuit nail access to every circuit node is progressively harder to achieve. It is

now apparent that we must think about “bed-of-nails” testing with a restricted set of
nails. A central contribution of both the 1149.1 and 1149.4 standards is that they
allow us to continue testing for manufacturing faults even as access becomes com-
promised. However, even with the aid of 1149.4, we may find that nail points within
an analog circuit that are not associated with IC pins may be inaccessible. This prob-
lem begs the question, “can we test analog networks with less than 100 % access?”
The answer is, of course, yes. We have always been able to fall back onto func-
tional test techniques. However, this is unsatisfactory if you want to retain diagnos-
tic capabilities of a test. It is often nearly impossible to predict from a failing analog
functional test the precise nature of the defect in the circuit. The desire to continue
enjoying In-Circuit test advantages such as automated program development and
218 6 Analog Measurement Basics

high-quality diagnoses has led to new research in In-Circuit test [Huan97, McDe98a,
McDe98b, McDe98c]. Today’s In-Circuit approach tests analog networks with
board power turned off. Tomorrow’s 1149.4-based testing will, of necessity, turn the
power on. In either case, we will need updated approaches to analog measurements
for testing purposes.

6.2.1 Node Voltage Analysis

The work presented in [McDe98a, McDe98b] and [Huan97] shows us a new way to
approach In-Circuit testing when access is limited. This can be shown by way of
example. Consider the simple circuit shown in Fig. 6.14.
The ATE system can switch a current source and ground path to the network, as
shown. Each node will develop a voltage; node A will see VA, and so on. (All volt-
ages are referenced to ground node C.) Each node voltage can be observed because
the circuit has full access. We will not use any of these test nails for conventional
guarding as discussed in Sect. 6.1.2.
Now assume the circuit is made up of perfect resistors at their nominal values.
Then the node voltages will be equal to a mathematical prediction. These voltages
are labeled VA-nominal, and so on. When the resistors vary as real resistors will, then
there will be some differences. This is expressed in Table 6.1. It is important to note
that even varying only one resistor from nominal will change all three voltages.

Fig. 6.14 A simple

network containing four A R1 B R3 D
resistors with full nodal
access
R2 R4

NewMet1

Table 6.1 Node voltages for Change in Node Voltage = Actual

the circuit in Fig. 6.14 when Voltage − Nominal Voltage
the component values vary
ΔVA = VA − VA-nominal
from nominal
ΔVB = VB − VB-nominal
ΔVD = VD − VD-nominal
6.2 Limited Access Testing 219

(0,0,0)
VD A

VA VB

(0,0,0)
VD B

VA VB
BoundBox

Fig. 6.15 Three-dimensional coordinates for graphing voltage differences

This example was carefully chosen to have three voltage differences so that they
can be plotted in a three-dimensional coordinate system15 such as shown in Fig. 6.15a.
Figure 6.15b shows a plot of many points forming a “cloud” of data. This data is
the result of performing thousands of Monte Carlo simulations of the 4-resistor
network in Fig. 6.14. Each simulation starts with a randomly selected set of
­variations for the four resistors and then computes the resulting node voltages.
These are compared to the nominal solution and the differences plotted as a single
point in the three-dimensional space. This technique can be used to plot all “good”
circuit behaviors by only using resistor variations that are within the tolerances
allowed in the design. Faulty behaviors can be plotted by varying one or more resis-
tor values beyond the specified tolerance. As you would expect, the cloud occupied
by good behaviors is much smaller than the cloud where any variations are allowed.
The next section shows how we can perform tests using node voltages.

15
The techniques shown here work for higher numbers of nodes and components. However it is
difficult to visualize higher-order dimensions.
220 6 Analog Measurement Basics

6.2.2 Testing with Node Voltages

Node voltages can be used to test a circuit. One simple idea is to measure all the ΔV
node voltages for a circuit and check the point so defined for inclusion within the
good cloud. This gives us a Pass/Fail result, but says nothing about which resistor(s)
may be out of specification if the circuit fails. This is because all combinations of
passing and failing devices are encoded in the cloud of points. What happens if we
put an upper bound on the number of resistors that are out of tolerance at any time?
This is shown in the three graphs presented in Fig. 6.16.
Figure 6.16a is constructed by plotting the differences in node voltages when
resistors R1, R2 and R4 are within tolerance limits, but R3 is outside its limits.
Similarly, Fig. 6.16b is a plot where only R2 is outside its tolerance limits.

R3 Failing

(0,0,0)
VD Passing A
Region

VA VB

Passing
Region (0,0,0)
VD B
R2 Failing

VA VB

Passing
Region
(0,0,0)
R2 or R3
VD
Failing
C

VA VB FailedRs

Fig. 6.16 Three-dimensional plots where only some components are potentially faulty at any one time
6.2 Limited Access Testing 221

Figure 6.16c shows a plot for R2 and R3 together. (For clarity we omit plots for R1
and R4.) Figure 6.16c shows us that observed changes in node voltages due to fail-
ure of either R3 or R4 will have a “signature” that can be used to distinguish the
two. Knowing this, we can test copies of this simple network and diagnose out-of-­
tolerance16 components distinctly.
It is possible that there may be significant (or even total) overlap of the clouds of
points belonging to different failures. When this happens, you will see a failure of
the circuit, but will only be able to say that “one or more of the following devices”
failed. This is called an ambiguity class. The next section describes how we can use
node voltage analysis for testing in a limited access environment.

6.2.3 Limited Access Node Voltage Testing

So far the discussion has assumed complete nodal access. Now we look at the
­situation where some node voltages are not known. See the same example circuit in
Fig. 6.17 where we now have lost access to node B.
Removing access to a node deprives us of information in one dimension of our
node voltage space. In our example, this has the effect of projecting an image of our
three-dimensional object onto a two-dimensional plane, as shown in Fig. 6.18.
In this case, losing access to node B means we cannot measure ΔVB for this
node. Figure 6.19a shows the shadows of the clouds for R2 and R3 projected onto
the plane of voltages for ΔVA and ΔVD. Because the shadows have distinct areas, we
can still perform a diagnosis if one of these devices should fail.
Figure 6.19b shows a different projection. Here, we have lost access to a different
node (node A rather than node B) and thus we cannot measure ΔVA. The shadows of
the R2 and R3 clouds onto the plane of voltages for ΔVB and ΔVD are completely
overlapped. Thus, while we can see if the circuit is failing, the ambiguity class
­contains two components so we cannot differentiate which of the two failed.

Fig. 6.17 Example circuit

with access to node B A R1 B R3 D
removed
R2 R4

C Access
Unavailable
i

NewMet2

16
Using AC voltages, we can also determine if a different type of component, for example, a
capacitor, has been misloaded in place of a resistor. With extreme miniaturization, many compo-
nents look the same and do not have enough space on them for labels.
222 6 Analog Measurement Basics

Shadows
Passing
Region Lamp
(0,0,0)
R2 or R3
VD
Failing

VA VB
Shadows1

Fig. 6.18 Projecting the shadow of a three-dimensional object onto a plane

(0,0) A
VD

R2 R3

VA

(0,0)
VD

VB
Shadows2

Fig. 6.19 Projections of failure spaces for R2 and R3 onto two of the voltage planes

By analyzing projections of higher-dimensional objects in lower-dimensions

we can find out what nodal access is most valuable for diagnosis and also what
access is not needed. Experiments on real circuits are reported in [McDe98a]. For
example, one circuit made from 14 resistors, 2 inductors and 20 capacitors with a
total of 21 nodes was analyzed. It was testable even though only 9 nodes were
6.3 The Mixed-Signal Test Environment 223

accessible. The largest ambiguity class contained three components. The CPU time
(on a modest CPU) to construct a test for this 20-dimensional17 problem was
about 2 min. (This is a one-time investment.) Nodal access was chosen by the
manufacturer of the circuit and was not optimal.

6.3 The Mixed-Signal Test Environment

There are many examples of mixed-signal boards and these have been in existence
for a very long time, yet until recently the IEEE itself did not recognize the term
“mixed-signal.” The 1149.4 Working Group had to assure the IEEE that such a term
existed. The term mixed-signal refers to single devices, boards or systems where
some information carrying signals exist that are digital in nature while others exist
that are analog.18
Digital signals utilize just two states (usually voltage states) to convey binary
digits of information. For example, a stream of “0” and “1” states on a Test Mode
Select (TMS) signal is used to navigate the 1149.1 TAP state diagram. Analog sig-
nals convey information via continuous states19 of voltage and current. For example,
the signal representing a singer’s voice, as converted to electrical form by a micro-
phone, is a remarkably complex analog waveform. While this waveform can be
“digitized” into a stream of bits, this process is always an approximation of the
original signal. Digital and analog signals may also be turned off such that no infor-
mation is represented.
Analog designers quickly point out that all circuits are analog. It’s just that so-­
called digital circuits have chosen to convey information with two discrete states
separated by a fairly wide unused voltage space that provides a noise margin. As
operating frequencies increase and noise margins decrease, most digital designers
tend to agree with the analog designers’ viewpoint! This is because yesterday’s digi-
tal designs could ignore parametric factors such as impedance matching, signal
reflections and ringing. Tomorrow’s designs must be concerned with these “analog”
problems. Often the solution to these problems involves adding extra discrete ana-
log devices to the “digital” circuitry.
Figure 6.20 depicts a mixed-signal board. It contains purely digital ICs marked
“D”, purely analog ICs marked “A” and some ICs marked “M” that contain both
types of circuitry. Then there are swarms of discrete components such as resistors,
capacitors, inductors, diodes, transistors, and so on. Such a board may be the signal

17
One node is always used as the reference node for voltage measurements.
18
Indeed, it is possible to have a single signal with both natures. Consider for example the encod-
ing of digital information within an analog television signal, used for closed-captioning.
19
“Continuous” means non-quantized, to differentiate analog signals from multiple-valued logic
signals that are still essentially digital in nature.
224 6 Analog Measurement Basics

M A

D D D A

D A

D D D A

M
M
A

D D D D

MixBoard

Fig. 6.20 A mixed-signal printed circuit board

processor for a video camera, for example. Because of that it is probably quite small
so it can be compressed into a hand-held unit, and you could expect the reverse side
of this board to look similar to the side shown. These types of boards are difficult to
test because of test access problems and the complex nature of mixed-signal testing.
This is the type of board that both 1149.1 and 1149.4 are well suited to address.
Indeed, the cover of this book illustrates the access problem by showing a juxta-
position of In-Circuit nails with old and new devices against a backdrop of a com-
mon coin, a US Lincoln penny. A key to this photograph is presented in Fig. 6.21. If
you have a penny, it is instructive to examine it.
The lettering on this penny is done with 10 mil lines.20 Some circuit boards today
use signal traces only 4 mils wide. Some vias coming into use are also only 4 mils
in diameter, fitting within the width of a trace. The diameter of the circular portion
of a “nine” in the date “1996” is approximately 35 mils, which is the generally
accepted lower limit on a test pad diameter needed for reliable probing. Clearly, it
will not be feasible to use 4 mil vias for test pads in the future since they are nearly
a decade smaller yet.
Ball-Grid Array technology is a major driver for smaller printed circuit
board trace widths and “micro” via diameters. A BGA requires a great number of
connections in a small area, so getting the required signals into this dense area is

20
Printed circuit dimensions are often specified in English (Imperial) units. A “mil” is 0.001 in., or
about 25 μm.
6.3 The Mixed-Signal Test Environment 225

50 mil
Probe 1208 SMT

100 mil
ICT Probes
0402 SMT

96
Du
alIn-
L
IC ine 1 9 75 mil
D ICT Probe

1/8 Watt Axial

Resistor
10 mil
Ruler
Lincoln

Fig. 6.21 Key to the color photograph appearing on the cover of this book

challenging. Smaller traces and vias makes this possible and become the enabler for
both Chip-Scale packaging and Chip-on-Board attachments. In the past, BGA ICs
had to be surrounded by an unpopulated perimeter in order to find room to route all
the signals. This perimeter was a good place to locate test pads. However, with
higher routing densities, these perimeters will shrink, leaving little room for test
pads. Making room will amount to trading off test pads for ICs and other devices.
Also shown atop the penny in Fig. 6.21 are three types of test nails, the common
100 mil nail, and 75 and 50 mil probes as well. In particular, notice the 50 mil probe
points to a discrete device in an “0402” Surface Mount Technology (SMT) package.
This designation means it is 40 by 20 mils on a side. To relate to this size, compare
it to President Lincoln’s bow tie. Soon we will see “0102” devices, which are
­one-­fourth the size and will easily fit within the circular portion of the “nine”.
Conventional In-Circuit nails and test pads are rapidly dwarfing the size of discrete
components. Thus asking board designers for thousands of test pads is becoming a
serious design issue.
Why not just shrink the nails and pads? This is a surprisingly complex mechani-
cal issue. Suffice it to say that the accumulated mechanical tolerances on boards and
fixtures makes it very difficult to target thousands of probes reliably over large
226 6 Analog Measurement Basics

SMT 4 mil
10 mils 35 mils Devices line
15 mil
0402 pad
0201 35 mil
pad RelSize

Fig. 6.22 Comparison of relative sizes of various features

areas, and remember that each nail is a spring-loaded assembly that contacts the
board with a notable21 force. This is a source of mechanical deviation, stress and
failure. But if we could somehow shrink nails and pads to (say) 15 mils, this is still
about four times the size of a modern signal trace and about the same size of today’s
smaller components. Designers have also questioned how fat test pads may impact
signal integrity on far narrower controlled impedance signal paths. Figure 6.22
compares the relative sizes of some of the items discussed in this section.
One last note; today’s more advanced IC geometries are based on 0.25 μ features.
These are 100 times smaller than a single mil and are shrinking with time. Mechanical
probing technology has essentially already reached its practical economic limits.

6.4 Summary

This chapter has set the stage for discussing the resources provided for analog test-
ing by IEEE 1149.4. It will certainly be the case that today’s In-Circuit test tech-
niques will still be used in the future, even as nail access becomes increasingly
limited. IEEE 1149.4 will be a powerful tool for providing measurement access to
many physically inaccessible points in a network.
The newly defined node voltage technique will allow us to continue to enjoy test
development automation and high-quality diagnostics. The dependence on guarding
that has been a mainstay of In-Circuit ATE will, of necessity, give way to the less
brutish non-guarded approach. Of course, for the foreseeable future, every tech-
nique we know will continue to have value since it is not likely that boards with
100 % IEEE 1149.1/1149.4 implementations will become very common.

21
Consider a board requiring 4000 nails, each with 0.5 lb of spring force. That comes to 2000 lb
(nearly 1 metric ton) of spring force distributed across a board and fixture.
Chapter 7
IEEE 1149.4: Analog Boundary-Scan

IEEE Standard 1149.4 [IEEE99] is titled “Mixed Signal Test Bus” but has become
known popularly as “Analog Boundary-Scan”. It is natural to ask, what is “Analog
Boundary-Scan”? The digital paradigm we have been using is confusing when we
hear the word analog. Could it mean we somehow capture analog voltages and
somehow shift them out for viewing (as proposed in [Wagn88])? The answer is
“no”. The simplest concept of the 1149.4 Standard is to imagine that we have inte-
grated a portion of an ATE system’s analog measurement bus and multiplexing
system into an IC, eliminating the need for bed-of-nails access to it. Since these test
resources have been converted from discrete relays, wire wrap and nails into silicon,
they will scale with silicon technology as it continues to shrink.
The 1149.1 Standard since its inception, has studiously avoided any consider-
ation of analog pins. Essentially, they were completely ignored. In the early 1990s,
the P1149.4 Working Group was chartered to study the question of how analog test-
ing could be facilitated with a standardized approach. This group had extensive
debates on just what it was they were trying to standardize. This debate crystallized
during a panel session at the International Test Conference (ITC) in 1992 when the
debate was presented to an audience of potential users. The users essentially said,
“Forget about measuring complex parameters like gain and distortion. Give us the
ability to find shorts, opens, and misloaded components in mixed signal circuits.”
They wanted to find manufacturing faults, not perform functional tests. This change
in emphasis was a turning point for P1149.4 and led to a proposed architecture in
1993 [Park93] that has since been refined into what we have today.
The extremely difficult practical problems of high frequency testing usually
needed for functional testing can be avoided when considering manufacturing
faults. So the first important characteristic to note about the IEEE 1149.4 Standard
is that it is intended for use with lower1 frequencies; from DC to around 1 MHz.
If this seems like a serious limitation, consider the fact that virtually all the boards

1
This isn’t to say you could not engineer an 1149.4 implementation to function at higher frequen-
cies. You can add special functions that have elevated performance, though this could be
expensive.

© Springer International Publishing Switzerland 2016 227

K.P. Parker, The Boundary-Scan Handbook, DOI 10.1007/978-3-319-01174-5_7
228 7 IEEE 1149.4: Analog Boundary-Scan

tested with In-Circuit test equipment over the last 35 years have had their analog
components tested at 10 kHz or less.
The second thing to notice about 1149.4 is the obvious fact that to use it, the
board must have power applied to it. Just as is the case for 1149.1, this produces
some nervousness when first realized. It means some number of shorts and many
analog defects on the board that were detectable with the power off (when we have
full nodal access) will have to be detected after the power is turned on. A good board
design will also take into account that the test process may generate unusual signals
on the board which could cause other powered elements to react. These reactions
may need to be controlled or otherwise suppressed.
A third thing to notice about 1149.4 is that it augments a traditional ATE system
with new resources on-chip for switching measurement currents and voltages.
However, these resources are implemented in silicon rather than with traditional
reed relays and wires. The impedances inherent in these new resources are signifi-
cantly higher2 than those achieved by relays and wire. This immediately rules out
testing activities based upon traditional guarding techniques seen in Sect. 6.1.3 on
page 220. IEEE 1149.4 does not support brute-force insertion of virtual grounds.
Thus, new metrologies [Park93, McDe98a, McDe98b, McDe98c] are needed that
use the available resources in new ways that respect these limitations.

7.1 1149.4 Vocabulary and Basics

IEEE Standard 1149.4 has been carefully designed to be fully compatible with the
existing 1149.1 standard. In many ways it can be thought of as a pure superset of
1149.1. For example, it uses an identical Test Access Port (TAP) controller fully
described in Chap. 1 (see Sect. 1.3.1 beginning on page 11). An 1149.4 compliant
IC can participate cooperatively with 1149.1 ICs to perform interconnect testing
such as described in Chap. 3, but adds the ability to address analog IC pins as well.
As a superset standard, 1149.4 adds the ability to test analog devices and func-
tions as well as simple interconnect. First, we need a model of what we are testing.

7.1.1 The Target Fault Spectrum

Figure 7.1 shows a mixed-signal circuit consisting of several mixed-signal ICs,

some digital ICs and a collection of discrete analog components. (The “A” and “D”
labels identify pins that are analog and digital.) Just as is the case with 1149.1, the

2
There are two reasons for this; first, there is a fundamental limit to what could be achieved at any
cost. Second, for 1149.4 to be economical it must consume a small area of an IC. Lower impedance
switches consume larger areas. In 2003 technologies, you should expect to see economical silicon
switches with on-impedances of several thousands of ohms.
7.1 1149.4 Vocabulary and Basics 229

Misloaded
Open
Device
A A A A A A
A A A A A A
D D D D D D D D D D
D D D D D D D D D D
D D D D D D D D D D
A A A A A A

Wrong
Value Short
InterconF

Fig. 7.1 A mixed-signal circuit with some possible defects

1149.4 standard has mandatory features that are used to test a target fault spectrum.
Parts of this fault spectrum are interconnection defects such as shorts and opens,
as shown in the figure. In addition, there are defects such as misloaded analog
components, for example, substituting a capacitor for a resistor. Also considered are
analog components with values that are wrong due to misloading or that are not
within their tolerances.
It is important to note that shorts and opens will not discriminate analog from
digital. A solder short may connect an analog pin to a digital pin. An open may
disconnect a discrete component from the circuit.
The 1149.4 standard also contains optional, codified features that may be used to
test functions within a given 1149.4 conformant IC, again, just like 1149.1 does (see
[Sunt02]). See also Sects. 7.3.5 and 7.3.6. Further, 1149.4 allows designer-specified
extensions that allow virtually unlimited test support for internal functions within an
IC. See for example [Lofs96a, Lofs96b].

7.1.2 Extended Interconnect

The 1149.1 standard viewed “interconnect” as simple wires that connect IC pins.
However, even “pure” digital boards may have discrete analog components, typi-
cally series termination resistors, between IC pins rather than simple wiring. This
leads to the necessity of viewing interconnect in two forms, “logical” and “physi-
cal”. Logical interconnect considers information flow, eliminating the physical
details such as series terminations. Some test software packages completely ignore
the physical details of a circuit and work solely in the logical domain. When such a
model sees a failure in the circuit behavior, the resulting diagnosis must omit the
additional physical detail that could be very useful in locating the offending defect.
The 1149.4 standard defines interconnect into categories; simple interconnect
(wires), and extended interconnect. It also notes the existence of differential inter-
230 7 IEEE 1149.4: Analog Boundary-Scan

Extended Interconnect
A A

A A

A A
Simple Interconnect
D D

+ +
Differential Interconnect
- -
(Analog or Digital)
Single-Ended Single-Ended
Transmission Point Reception Point SimpExtn

Fig. 7.2 Examples of interconnections seen in mixed-signal circuits

connections, where a pair of wires is used to transmit a single signal. Figure 7.2
shows some examples of these interconnect categories.
Extended interconnect is defined as “non-wire” interconnections between device
pins. For example, two IC pins may be connected through a discrete analog compo-
nent such as a resistor, inductor or capacitor.3 It could be true that there is a logical
behavior of this extended interconnect that is equivalent to simple wiring as you
might expect for low-valued termination resistors. However, this may not be true,
so you will have to account for the effects of the discrete components when con-
structing interconnect tests. As noted in [Park97] special care may be needed with
reactive components that store energy. For example, the capacitor connecting two
pins in Fig. 7.2 may have an initial stored voltage that could be added into subse-
quent test signals, causing confusion4 if not accounted for.
It seems reasonable to ask, “how much longer will there be a need for discrete
analog devices?” After all, are we not seeing increased integration giving us the
means to replace analog functions with digital equivalents? If this happened,
extended interconnect could soon disappear. It turns out that there are a number of
reasons why we still see discrete components, and many of these are not amenable
to obsolescence by integration. Discrete components are used for:
• Impedance matching; while completely customized ICs have on-chip impedance
matching resistances, merchant ICs will not likely have these because it makes
assumptions about their end use.

3
Capacitive coupling of digital signals between ICs is becoming more common. See an extensive
discussion of this in Chap. 8 which covers IEEE Standard 1149.6.
4
Voltage addition by the capacitor could also cause signals to go out of normal operating range
with possibly damaging effect.
7.1 1149.4 Vocabulary and Basics 231

• Power dissipation; if a discrete resistor will dissipate significant power, this may
be incompatible with integration.
• Larger inductances and capacitances; reactive components may be expensive to
integrate. Note that small resistances can consume expensive amounts of silicon
real estate.
• Customization; some ICs have their range of functionality extended by connect-
ing external discrete reference devices.
• Precision; it is difficult to integrate analog functions with high absolute precision.5
These and other factors tell us that we will still see discrete components in the
future, but it is likely that more and more analog functionality will be integrated into
mixed-signal ICs. This trend will likely mean that while we will see discrete net-
works of analog devices, the size of these networks will diminish in time. Instead of
one large network, we may see several smaller, independent networks surrounding
large mixed-signal ICs. If these ICs comply with 1149.4, we will have a powerful
tool to use for testing these networks.

7.1.3 Digital Pins

Both IEEE 1149.1 and 1149.4 treat digital pins identically. However, the 1149.4
standard has introduced a change in nomenclature; it describes all the Boundary
Register test circuitry needed to support a single digital pin as a “Digital Boundary
Module” or DBM (see Sect. 7.2.5).
A DBM may contain one or more Boundary Register cells as discussed at length
in Chap. 1. Because the 1149.1 standard allows the shift order of Boundary Register
cells to be assigned completely randomly, a DBM does not imply a shift order. Indeed
the Boundary Register cells contained within several DBMs may be intermixed at
random with respect to their shift positions.6 A DBM is a method for organizing our
thinking of the test resources for a single digital pin. The “Boundary Module” concept
is also used to describe those resources needed for analog pins, as discussed next.

7.1.4 Analog Pins

IEEE 1149.4 directly addresses analog pins, rather than ignoring them as IEEE
1149.1 has done for over 25 years. Analog pins are assigned test resources con-
tained in an “Analog Boundary Module”, or ABM, covered in Sect. 7.2.4. As just
discussed, an ABM will contain Boundary Register cells which are not constrained

5
Relative precision is possible. For example, resistances can be matched on a single IC, but their
absolute values may vary significantly from IC to IC.
6
While random ordering is allowed, you will often find the Boundary Cells associated with a pin
are indeed adjacent in the Boundary Register. All figures in this chapter will show such adjacency
even though it is not required.
232 7 IEEE 1149.4: Analog Boundary-Scan

in their ordering, either within the ABM itself, or in their ordering with any other
Boundary Register cells in other ABMs or DBMs. An ABM also contains addi-
tional resources needed to support analog test functions, and control logic for these
resources.
An ABM is capable of two major modes of test operation. It supports the emula-
tion of 1149.1-style interconnection testing and it supports analog stimulus and
measurement capabilities needed for analog tests. If two analog pins on 1149.4
conformant ICs are connected with a simple wire, then the 1149.1 emulation capa-
bility will be sufficient to test that wire for shorts and opens. If these same two pins
had extended interconnect, say with a low-valued series resistance, then 1149.1
emulation will still be sufficient to test the interconnect, plus the analog capabilities
will allow testing of the resistor itself.
If there is extended interconnect between two pins that does not allow 1149.1-
type interconnect tests, then the 1149.1 emulation will not be usable for intercon-
nection testing, but it may still be useful for shorts testing. Suppose there is a small
capacitor between these two pins such as we saw in Fig. 7.2. For the purposes of
interconnect tests (which are essentially DC tests) the small capacitor looks like an
open circuit. Modeling the two pins as logically independent nodes, we can test for
shorts between them (or across the capacitor) with standard 1149.1 interconnection
tests. Later, an analog test may be used to measure the capacitor’s value.
This brings us to another important point about how 1149.4 treats analog pins.
The 1149.1 standard takes great pain to treat digital pins, for testing purposes, as
having the same nature during test as they do when not being tested. Thus there are
“input” DBMs, “output” DBMs and “bidirectional” DBMs. When first examining
analog pins, it seems this paradigm continues, but soon examples of analog pins are
found that do not have a clearly definable I/O nature.
For example, consider two analog pins intended for connection to a crystal fre-
quency reference. Are these pins inputs or outputs? The answer may not be clear.
And as just seen with the example of a small capacitor, the two pins connected to
the crystal are not “connected” to each other in the traditional 1149.1 sense because
the impedance of the crystal is very high. If we give each of these analog pins the
ability to be driven and simultaneously sensed, then we can include them in 1149.1
interconnection tests. Any shorts between them or other 1149.1 pins can then be
detected. So even though these pins are not recognizably inputs or outputs, by
treating them as bidirectional we can still perform useful 1149.1-style shorts tests.
Thus an important feature of ABMs is that they do not mimic the system nature of
the analog pins to which they are attached but rather treat every analog pin as if it
were bidirectional while supporting 1149.1-style tests.
An ABM also provides new test capabilities in support of analog test that are cov-
ered extensively in Sect. 7.2.4. It could happen that these new resources are not
needed because (in a particular application) there are no analog components or param-
eters that one wished to test that are associated with that analog pin. However, it is
also possible that you have pins that are clearly digital in nature connected to discrete
analog components. If you are implementing a custom IC where you know this will
happen, then the 1149.4 standard allows you to replace a DBM with an ABM. This
allows superset test capability over simple 1149.1, giving a formerly digital pin the
ability to participate in analog tests as well as 1149.1-style interconnect testing.
7.2 General Architecture of an 1149.4 IC 233

7.2 General Architecture of an 1149.4 IC

Figure 7.3 shows a high level general architecture of an 1149.4 IC. This is a minimal
implementation as additional features are also allowed. These will be described
later.
The important high level features of this implementation are:
• A test control block containing an 1149.1 TAP, instruction register and the famil-
iar four (optionally five) TCK, TMS, TDI, TDO (and TRST*) signals. These
elements are described completely by 1149.1 (see Sect. 1.3 beginning on page 8).
• Digital I/O pins served by Digital Boundary Modules (DBMs) made up of 1149.1
Boundary Register cells as described in Sect. 1.3.4 starting on page 22. DBMs
are discussed in Sect. 7.2.5 on page 262.
• An “Analog Test Access Port” (ATAP) where analog stimulus and measurements
can be conducted to/from the IC. This port (in the minimal configuration) is made
up of two I/O pins labeled AT1 and AT2. (See Sect. 7.2.2) As an option, the ATAP
can be extended by adding two additional pins, AT1N and AT2N. These are used
to support differential stimulus and measurement. (See Sect. 7.4.1 on page 271.)

Digital Analog
Boundary Boundary
Module D Module
A
VH
D B
VL Analog
M G
Digital D Core I/O
I/O D Circuitry
A
VH
D B
VL
Analog M
G
Test Access D
Port (ATAP)
AT1 Test Bus AB1
Internal
Interface
AB2 Test Bus
Circuit
AT2 (TBIC) Control

TDI Test Control Block TDO

(1149.1 TAP, Instruction Register
and Decode)

TCK TMS
Basic.4

Fig. 7.3 General (minimal) architecture of an 1149.4 compliant IC

234 7 IEEE 1149.4: Analog Boundary-Scan

Boundary Register
TBIC ABMs DBMs

Optional Design-Specific
Data Registers
TDO
Bypass Register Mux Output TDO
Stage

TDI Instruction Reg

Test Control Block
Instruction Control Signals for
Decode Register Enables,
TCK Register Clocking,
TAP Controller Mux selection, etc.
TMS
RegStruc

Fig. 7.4 Detail of 1149.4 data register structure

• A “Test Bus Interface Circuit” (TBIC) which controls connections of the ATAP
to an internal analog test bus (AB1 and AB2 in the minimal configuration) that is
distributed to all ABMs. The control mechanism for the TBIC is composed of
Boundary Register cells that are part7 of the overall Boundary Register. (See
Sect. 7.2.3 on page 250.) As an option, the internal analog bus can be extended
by adding two signals, AB1N and AB2N. These are used to support differential
stimulus and measurement. (See Sect. 7.4.1 on page 271.) A separate option
allows a TBIC to generate a partitioned internal analog bus structure to improve
internal loading and noise characteristics. (See Sect. 7.4.3 on page 274.)
• Analog IC pins connected to Analog Boundary Modules (ABMs). The ABMs
have access to the internal analog test bus as well as (up to) three reference volt-
ages labeled VH, VL and G. (See Sect. 7.2.4 on page 255.)
Just as is the case with 1149.1, the 1149.4 standard connects selected registers
between TDI and TDO as shown in Fig. 7.4. Mandatory registers include the
Instruction Register (described in Sect. 1.3.2 on page 17), the Bypass Register
(described in Sect. 1.3.3 on page 21) and a Boundary Register. The Boundary Register
is identical in nature to that described in 1149.1 (see Sect. 1.3.4 on page 22) but
contains additional cells that are used to control the actions of ABMs and the TBIC.

7
The Boundary Register cells within a TBIC may also be intermixed randomly with other Boundary
Register cells. Drawings shown in this book will keep them together.
7.2 General Architecture of an 1149.4 IC 235

7.2.1 Silicon “Switches”

Throughout this chapter we will be using switching structures implemented in sili-

con to perform test functions. The TBIC and ABMs contain these switches in spe-
cifically defined configurations.
In silicon processes such as CMOS, switches can be implemented rather easily
with Metal Oxide Semiconductor Field Effect Transistor (MOSFET) structures that
(roughly) approximate the nature of mechanical relays. In other silicon processes,
bipolar buffers (that can be turned off) may be used as a “switch”. Table 7.1 shows
a comparison of several switch characteristics for various implementations.
A perfect switch is a component connected to two nodes. When closed, it joins the
two nodes into one so there is no voltage difference between them and it conducts
current in either direction. When open the two nodes are completely independent.
The ideal switching time would be zero and the size would be negligible. As you can
see from the table, a typical mechanical surface mount relay is near perfect except for
switching time (slow!) and size (huge!). A CMOS switch has an on-resistance four or
more decades higher than a relay, but it is four million times smaller and hundreds of
times faster. It is bidirectional, but it should be noted that it is somewhat nonlinear
over larger signal swings. A bipolar switch can be made from a buffer that can be
turned off. As such it really doesn’t have an on-resistance.8 In an 1149.4 implementa-
tion implemented in a bipolar process, some (buffer) switches are required to con-
duct current (the AT1 and AB1 paths) and others (the AT2 and AB2 paths) are
required to convey voltage. (The 1149.4 standard does not require that switches be
bidirectional.) Bipolar implementations will require careful characterization since
buffer offset may not be zero and gain may not be unity for practical reasons.
Figure 7.5 shows symbols used in the following discussions to reflect the nature
of switches. In some cases (see the two left-hand symbols) we show the switches
without a control mechanism to avoid clutter. Other times we will show the control
signal, as on the two right-hand symbols. When a switch is open, it has infinite

Table 7.1 Comparison of parameters of various switches

CMOS Bipolar
Parameter Mechanical relay (SMT) switch (0.35 μ) switch (0.35 μ)
On-resistance 10−2 Ω 102–103 Ω (see discussion)
Off-resistance 1012 Ω 1012 Ω 1010 Ω
Bidirectional? Yes Yes (see discussion) No
Switching time ≥500 μs <1 μs <1 μs
Area (approx.) 200 × 750 mils = 96.7 × 106 μ2 20 μ2 100–5000 μ2

8
A buffer-type switch does have an upper limit on the magnitude of the signal it can transmit
which, if exceeded, will be distorted.
236 7 IEEE 1149.4: Analog Boundary-Scan

Series Impedance
When Closed

Control=0 Control=1

Very High Impedance

When Open
Switches

Fig. 7.5 Symbols used for opened and closed switches

impedance for practical purposes. However, when closed, it has non-negligible

series impedance that is represented with the integral “resistor” shown. This sym-
bolism is used to remind the reader that we do not have low impedance switching
we once enjoyed with relays.9

7.2.2 The Analog Test Access Port (ATAP)

The 1149.4 standard contains the 1149.1 Test Access Port which is four (optionally
five) digital signals. In addition to this it contains an Analog Test Access Port or
“ATAP”. In a minimum configuration, this port consists of two analog signals
labeled AT1 and AT2 as originally shown in Fig. 7.3. This port is used to connect
external analog stimulus and measurement resources to an 1149.4 conformant IC.
Typically, the AT1 port is used for stimulus into the IC and the AT2 port is used
for transmitting a response back to a measurement resource.10 It is intended that one
or more compatible ICs would have their ATAP signals connected in parallel, just as
TCK and TMS are connected in parallel as shown in Fig. 7.6 creating a simple
chain. However, it is not required that two ICs that do have common TCK and TMS
signals also have common AT1 and AT2. For example, one IC may generate a great
deal of internal noise and the other may be required to have a very quiet environ-
ment, so it may be undesirable to connect the two ATAPs together when optimum
system performance is required. In this case, the external test equipment used for
analog testing will need access to both of the ATAPs.

9
These switches are known as “crummy switches” within the 1149.4 Working Group. (For non-
English speakers, “crummy” means “low quality”.) The term constantly reminds us that these
switches have serious limitations.
10
If the switches used in an implementation are bidirectional (for example in a CMOS technology)
then the pins AT1 and AT2 may have their roles reversed.
7.2 General Architecture of an 1149.4 IC 237

U1 U2

TDI TDO

TCK
TMS
AT1
AT2
ParaConn

Fig. 7.6 Two or more 1149.4 ICs chained together. Note AT1 and AT2 are not required to be con-
nected in parallel as shown here

7.2.3 The Test Bus Interface Circuit (TBIC)

The TBIC function first introduced in Fig. 7.3 (on page 245) is used for three major
purposes. First, it is used to connect or isolate the internal analog measurement
buses AB1 and AB2 to/from AT1 and AT2. Second, it is used to perform 1149.1-
type interconnect tests on the AT1 and AT2 pins. Third, it supports characteriza-
tion11 processes that may be needed to improve the accuracy of analog measurements.
A switching structure meeting the requirements of 1149.4 is shown in Fig. 7.7.
Switches S1 through S4, along with the one-bit digitizers that generate signals
DAT1 and DAT2, are used to support 1149.1-style interconnect tests. (The destination
of these digitized signals is found in Fig. 7.8) The digitization is performed in rela-
tion to some threshold voltage shown as VTH. Because this digitization need only be
coarse rather than a precise operation, this threshold reference may not physically
exist except as a physical property12 of the silicon implementation. The goal is to
cheaply obtain a one-bit measure of the voltage on the pin. (Lofstrom [Lofs96a]
shows how to avoid undesirable current surges when an input voltage is near the
threshold.) In general, VL<VTH<VH with the additional goal that a short between
AT1 and AT2 will not produce an intermediate voltage that approximates VTH.

11
In other literature (including 1149.4) you will see the word “calibrate” rather than “characterize”
used in this context. The 1149.4 standard does not have any adjustable features that can be cali-
brated, so instead we characterize the operational parameters of important features and record
them for mathematical corrections performed later.
12
For example, a simple logic buffer has an inherent threshold somewhere between a “low” voltage
value and a “high” value. There is no “comparison” done with an actual threshold.
238 7 IEEE 1149.4: Analog Boundary-Scan

DAT1

AT1 AB1
S5
S1 S3 Dig S9
S7
VH VL VTH VClamp
S8
S2 S4 Dig S10
S6
AT2 AB2
For Interconnect Test For Isolation and Characterization
DAT2 TBICSwch

Fig. 7.7 A TBIC switching structure inserted between AT1/AT2 and AB1/AB2. Note one-bit digi-
tized values of the AT1/AT2 signals are generated

Towards
TDO
M2
From TAP Mode2 S1
TBIC Control Decode Logic

Controller M1
Mode1 S2

D2 S3
DAT2 C U

From TBIC S4
Digitizers S5
D1
DAT1 C U
S6

Co S7
C U
Uncommited, may S8
be used for improved
TBIC testability Ca S9
C U
S10

From
TDI
TBICCntl

Fig. 7.8 Control structure for the switches shown in Fig. 7.7
7.2 General Architecture of an 1149.4 IC 239

It is an interesting feature of 1149.4 that it can execute a conventional Boundary-

Scan interconnect test on its ATAP pins. When testing a board full of 1149.1 and
1149.4 devices, one first checks the integrity of the TAP signals using a (digital)
integrity test. Then one tests the simple wiring for interconnect defects. At this point
in time, 1149.4 can also check each ATn port for shorts and opens as well. Later, the
ATn pins can be used for analog tests with the assurance that these tests will not be
defeated by connectivity defects in the ATAP infrastructure.
Switches S5 and S6 are used to connect/isolate the AT1/AT2 signals to/from the
internal AB1/AB2 signals. When these two switches are open, then the ABn signals
are isolated which could cause them to float and thus become susceptible to noise.
Switches S9 and S10 are optional but serve the purpose of clamping the internal
ABn signals to a safe voltage to eliminate unwanted noise or parasitic effects when
these signals are not in use for test purposes. Switch S9 is always in the opposite
state as S5; S10 is always in the opposite state as S6.
Closing S5 and S8 (or S6 and S7) allow us to characterize the AT1/AT2 pathway
via a loopback test. This characterization will allow us to correct for the many para-
sitic parameters13 that will exist on the board and the ATAP pins.
Figure 7.7 contains ten switches so there are 1024 possible combinations of these
switches opened and closed. However, only ten switching patterns have been defined
as meaningful by the 1149.4 Standard. These are enumerated as patterns P0 through
P9 in Table 7.2. A “1” (“0”) in the table indicates a closed (open) switch.
The (minimal) TBIC control structure14 for the switches in Fig. 7.7 is shown in
Fig. 7.8. This control structure makes use of four Boundary Register cells15 and two
control mode signals “Mode1” (M1) and “Mode2” (M2) from the TAP controller,
which are a function of the instruction currently loaded in the instruction register.
The four Boundary Register cells are named16 “Calibrate” (Ca), “Control” (Co),
“Data1” (D1) and “Data2” (D2).
Note that the capture stages of D1 and D2 capture the DAT1 and DAT2 signals gen-
erated within the switching structure shown in Fig. 7.7. (The capture stages of cells
Ca and Co are uncommitted.17) Cells Co, D1 and D2 form a pair of self-monitoring
output cells with a shared control cell that can be used for 1149.1-style interconnect
tests of the AT1/2 pins.

13
Testing software will often need to know the value of parasitic parameters in the AT1/AT2 paths,
both within the IC (mainly resistive impedance or gain factors, see Sect. 7.4.4) and at the board
level (mainly capacitance). These parameters can then be modeled as additional devices in the
overall network being tested.
14
See Sect. 7.4.3 for the control needed for more elaborate TBIC structures that handle partitioned
internal analog buses.
15
The order of these cells is arbitrary and they may be intermixed with other cell in the Boundary
Register.
16
Boundary Register cells in 1149.1 were implicitly named “control”, “data”, and so on.
The 1149.4 standard has chosen to explicitly name the cells it uses in both the TBIC and ABMs.
17
It is recommended in 1149.4 that these uncommitted capture cells should capture internal TBIC
signals with poor observability to improve the testability of the TBIC implementation.
240 7 IEEE 1149.4: Analog Boundary-Scan

Table 7.2 TBIC switching patterns (P0 through P9) for the switches shown in Fig. 7.7
Switch state (S1–S10)
P# 1 2 3 4 5 6 7 8 9 10 Function
0 0 0 0 0 0 0 0 0 1 1 ATn disconnect (Hi-Z), clamp ABn
1 0 0 0 0 0 1 0 0 1 0 Connect AT2 to AB2 Patterns P1-P3 support
2 0 0 0 0 1 0 0 0 0 1 Connect AT1 to AB1 analog metrology.
3 0 0 0 0 1 1 0 0 0 0 Connect ATn to ABn
4 0 0 1 1 0 0 0 0 1 1 AT1/2 drive 00 out Patterns P0 and P4-P7
5 0 1 1 0 0 0 0 0 1 1 AT1/2 drive 01 out support 1149.1-style
6 1 0 0 1 0 0 0 0 1 1 AT1/2 drive 10 out interconnection tests.
7 1 1 0 0 0 0 0 0 1 1 AT1/2 drive 11 out
8 0 0 0 0 0 1 1 0 1 0 For characterization
9 0 0 0 0 1 0 0 1 0 1 For characterization

Table 7.3 Assignment of TAP instructions to mode signal values for the TBIC
TAP instruction Mode1 (M1) Mode2 (M2)
EXTEST, CLAMP, RUNBIST 1 1
PROBE, INTEST 0 1
HIGHZ 1 0
BYPASS, SAMPLE, PRELOAD, IDCODE, USERCODE 0 0

The next question is “what is the ‘TBIC Control Decode Logic’” in Fig. 7.8. This
logic is used to select from the switching patterns (P0 through P9) given in Table 7.2
for the switches in Fig. 7.7. We need to know how this logic will select them. First,
TAP instructions must be associated with the mode lines M1 and M2. A possible
assignment is shown in Table 7.3. (Most of these instructions are familiar, but more
description will be presented in Sect. 7.3 where their effects in an 1149.4 environ-
ment are detailed.)
Now that M1 and M2 are assigned, Table 7.4 shows how the bits contained in the
four Boundary Register cells Ca, Co, D1 and D2 are used to select switch patterns.
An asterisk (“*”) in some table entries indicates that there is no switching pattern
yet assigned for this combinations of mode and cell values. Future versions of the
1149.4 standard may assign patterns to these uncommitted combinations, so they
should be considered “reserved”. Application software designed to support the
current edition of the standard should avoid these reserved combinations.
Table 7.4 may seem confusing, so it is useful to point out that there are some
simple relationships that make it more understandable.18

18
The following list of statements assumes Mode1 and Mode2 are not “10” (HIGHZ) or “00”
(BYPASS, etc.). When they are, no pattern of bits in the TBIC control cells has any effect on the
mission operation of the IC nor on the state of the ATn pins, which are disconnected.
7.2 General Architecture of an 1149.4 IC 241

Table 7.4 Selection of TBIC switch patterns versus Boundary Register cell content
Cells Modes 1/2 = 11 Modes 1/2 = 01 Modes 1/2 = 10 Modes 1/2 = 00
Ca/Co/D1/D2 EXTEST, etc. PROBE, etc. HIGHZ BYPASS, etc.
0000 P0 P0 P0 P0
0001 P1 P1 P0 P0
0010 P2 P2 P0 P0
0011 P3 P3 P0 P0
0100 P4 * P0 P0
0101 P5 * P0 P0
0110 P6 * P0 P0
0111 P7 * P0 P0
1000 P0 * P0 P0
1001 P8 * P0 P0
1010 P9 * P0 P0
1011 * * P0 P0
1100 * * P0 P0
1101 * * P0 P0
1110 * * P0 P0
1111 * * P0 P0

• When all four bits are “0”, the ATn port is disconnected from the ABn bus and
the ATn pins are in a high impedance state.
• When Ca = 0 (i.e., the first eight rows) the test circuitry is configured for test
purposes. Otherwise it is configured for characterization.
• When Ca and Co are both “0” (i.e., the first four rows) then none, one, or both of
the ATn ports are connected to ABn. The AT1 connection is governed by the D1
cell and the AT2 connection is governed by the D2 cell.
• When Ca = 0 and Co = 1 (i.e., the second set of four rows) then AT1 and AT2 are
enabled to drive digital interconnect test signals out from the IC19 while monitor-
ing the pin state. In this mode, D1 is a bidirectional data cell for AT1 and D2 is a
bidirectional data cell for AT2. Cell Co is the enable control for both.
Finally, Table 7.5 shows a set of logic equations (for the mode assignments used
in this example) that will implement the switch pattern selections given in Table 7.4.
This concludes the discussion of a minimal TBIC. The TBIC can be extended to
support a differential ATAP (see Sect. 7.4.1 on page 271) which may be used to sup-
port differential measurements (if desired) on ICs that have differential I/O. The
TBIC can also be expanded to support partitioned internal ABn buses (see Sect. 7.4.3
on page 274) when an IC designer desires to separate potential parasitic coupling
between (for example) sensitive input amplifiers and large signal output buffers.

19
Note one slight difference here as compared with conventional 1149.1 drivers. When Co is “0”
which disables the ATn drivers, the data cells have a possible, small parasitic effect on the IC by
enabling switches S5 and/or S6 if D1 and D2 are not both “0”.
242 7 IEEE 1149.4: Analog Boundary-Scan

Table 7.5 Logic equations TBIC Logic equation (a trailing

for TBIC switch control switch “*” indicates inversion)
S1 Ca*CoD1M1M2
S2 Ca*CoD2M1M2
S3 Ca*CoD1*M1M2
S4 Ca*CoD2*M1M2
S5 Co*D1M2(Ca* + D2*M1)
S6 Co*D2M2(Ca* + D1*M1)
S7 CaCo*D1*D2M1M2
S8 CaCo*D1D2*M1M2
S9 S5*
S10 S6*

7.2.4 The Analog Boundary Module (ABM)

The ABM function first introduced in Fig. 7.3 (on page 245) is used for two major
purposes. First, it supports 1149.1-style interconnect tests. Second, it supports ana-
log test metrologies aimed at testing off-chip analog components in “extended inter-
connect”. Figure 7.9 shows a structure of an ABM meeting the requirements of
1149.4 that may be used at any analog system pin.20
Starting on the left side of Fig. 7.9 is the analog core circuitry that performs the
mission of the IC. For test purposes, this core will need to be disconnected from the
analog pin on the right side. This disconnection property is shown as a discrete switch
SD, but it is quite important to note that this switch may not physically exist as shown
in the implementation of an ABM. In some cases, usually for analog outputs, it may
be a function that exists in the analog core that can be controlled as if it were a switch
in the location shown. In other cases (for example, analog inputs) this switch may not
exist because the input has a very high impedance and thus cannot interfere with test
activities. In yet another instance (again, for an analog input) the switch may not
exist, but the control signal that controls it is used in the analog core to desensitize the
core function to test signals appearing on the pin. Because the core disconnect switch
SD may not actually exist as a physical entity, we call it a conceptual switch [Park93].
Next in Fig. 7.9 we see a one-bit digitizer that creates a digital interpretation of
the voltage on the analog I/O pin. This signal DPin will appear later in Fig. 7.10. This
digitized signal is used to support 1149.1-style interconnect tests. The digitization
is performed in relation to some threshold voltage shown as VTH. Because this digi-
tization need only be coarse rather than a precise operation, this threshold may not
physically exist except as a physical property of the silicon implementation. The
goal is to cheaply obtain a one-bit measure of the voltage on the pin (see [Lofs96a]).
In general, VL < VTH < VH with the additional goal that a short between neighboring
analog pins should not produce an intermediate voltage that approximates VTH.

20
Note, the AT1/AT2 pins are not analog system pins, but part of the 1149.4 test resource set.
7.2 General Architecture of an 1149.4 IC 243

AB1 AB2
VH ESD
DPin Protection
SH
Analog SD
Core Core
Disconnect Dig SL SG SB1 SB2

Analog
VTH VL VG
Pin
From
TBIC ABMSwtch

Fig. 7.9 ABM design detail for a generalized analog function pin

Towards
TDO
M2
From TAP Mode2 SD
ABM Control Decode Logic

Controller M1
Mode1
SH
B2
Uncommited, may CU

be used for improved SL

ABM testability
B1
CU
SG

C
CU SB1

From ABM D SB2

DPin CU
Digitizer

From
TDI
ABMCntl

Fig. 7.10 Control structure for the switches shown in Fig. 7.9

Also in Fig. 7.9 we see three DC voltages labeled VL, VH and VG which can be
connected to the analog pin with three switches respectively labeled SL, SH and
SG. Voltages VL and VH are used to create digital voltage levels on the analog pin in
support of 1149.1-style interconnect tests. Voltage VG is used in support of analog
metrology. Therefore VG should be a reference quality voltage, which means it is a
voltage source capable of sourcing or sinking current over a defined range without
244 7 IEEE 1149.4: Analog Boundary-Scan

a noticeable change in voltage, and it should be stable with respect to time. If an IC

has a connection to system ground, this would make an excellent choice for VG. If
either VH or VL has the “reference quality” property, then it may be used as VG.
Switches SH and SL may also be conceptual if, for example, there is already a
pin driver present that can produce both VH and VL as a test function. The driver
control circuitry can be modified to activate it when the control signals for SH and
SL are activated. An obvious advantage of using an existing driver is that it will
likely have a much larger current drive capability than 1149.4 switches would have
in the interest of keeping the 1149.4 circuitry a small fraction of the IC’s area. If a
pin driver is capable of driving (say) a 50 Ω load, then it might be reasonable to
expect that such a load is likely to exist external to the IC. It is doubtful that small
(cheap) switches could drive such a load, making it impossible for that pin to par-
ticipate in 1149.1-style interconnect tests.21
Next in Fig. 7.9 we see the internal measurement bus wires AB1 and AB2 that
can be connected to the analog pin via switches SB1 and SB2. It is required that
AB1 be able to provide a current to the pin, and that AB2 be able to monitor the pin
voltage. (If the ABM is constructed with CMOS switches, then AB1 and AB2 could
be interchangeable in these roles.)
The 1149.4 Standard has defined 20 switch settings (labeled P0 through P19) for
the switches shown in Fig. 7.9. These are shown in Table 7.6.
In Table 7.6, only 20 of the possible 64 switch settings are listed. This is because
many settings are nonsensical, such as connecting VH and VL simultaneously to a
pin. The rationale for these settings is:
• P0 isolates the pin completely from the core and all test resources.
• P1 through P5 are used for testing extended interconnect by connecting one or
both analog buses and the reference voltage VG.
• P6 and P7 can be used to characterize the quality of the VG reference.
• P0, P8 and P12 are, respectively, Hi-Z, drive low and drive high when used for
1149.1-style interconnect tests.
• P9 through P11 and P13 through P15 allow characterization of VL and VH
sources, or biasing external devices while measurements are made.
• P16 connects the pin to the core and disconnects all test circuitry. Used for “mis-
sion mode” operation of the pin.
• P17 through P19 are used to support the requirements of the PROBE and INTEST
instructions (see Sects. 7.3.4 and 7.3.6, on pages 268 and 269).
The ABM control structure for the switches shown in Fig. 7.9 is shown in
Fig. 7.10. This control structure makes use of four Boundary Register cells and two
control mode signals “Mode1” (M1) and “Mode2” (M2) from the TAP controller
which are a function of the currently active instruction. The four Boundary Register
cells are named “Bus1” (B1), “Bus2” (B2), “Control” (C) and “Data” (D).

21
This does not necessarily mean a loss of fault coverage since shorts and opens can be detected as
a side effect of testing extended interconnect. However, the considerable speed advantage of
1149.1-style testing would be lost.
7.2 General Architecture of an 1149.4 IC 245

Table 7.6 ABM switching patterns (P0 through P19) for the switches shown in Fig. 7.9
Switch state (0/1 = open/closed)
P# SD SH SL SG SB1 SB2 Pin state
0 0 0 0 0 0 0 Completely isolated
1 0 0 0 0 0 1 Monitored by AB2
2 0 0 0 0 1 0 Connected to AB1
3 0 0 0 0 1 1 Connected to AB1, monitored by AB2
4 0 0 0 1 0 0 Connected to VG
5 0 0 0 1 0 1 Connected to VG, monitored by AB2
6 0 0 0 1 1 0 Connected to VG and AB1
7 0 0 0 1 1 1 Connected to VG & AB1, monitored by AB2
8 0 0 1 0 0 0 Connected to VL
9 0 0 1 0 0 1 Connected to VL, monitored by AB2
10 0 0 1 0 1 0 Connected to VL and AB1
11 0 0 1 0 1 1 Connected to VL & AB1, monitored by AB2
12 0 1 0 0 0 0 Connected to VH
13 0 1 0 0 0 1 Connected to VH, monitored by AB2
14 0 1 0 0 1 0 Connected to VH and AB1
15 0 1 0 0 1 1 Connected to VH & AB1, monitored by AB2
16 1 0 0 0 0 0 Connected to core, isolated from test
17 1 0 0 0 0 1 Connected to core, monitored by AB2
18 1 0 0 0 1 0 Connected to core and AB1
19 1 0 0 0 1 1 Connected to core & AB1 monitored by AB2

Note that the capture stage of D captures the state of the DPIN signal generated in
Fig. 7.9. The C and D cells form a two-cell bidirectional structure (full pin monitor-
ing) for the support of 1149.1-style interconnect tests. The capture stages of the
other three cells, C, B1 and B2 are uncommitted. It is recommended that these be
used to capture embedded, hard-to-observe signals within the ABM to improve the
testability of the implementation.
So now the question is “what is the ‘ABM Control Decode Logic’” shown in
Fig. 7.10. Table 7.7 shows how the four Boundary Register cells C, D, B1 and B2
are used to select from the 20 switch patterns P0 through P19. An asterisk (“*”) in
an entry indicates there is no switch pattern (yet) assigned for this combination of
control bits and they should be considered “reserved” for future assignment by the
1149.4 Working Group. As before in the discussion of the TBIC control, we need to
associate values for Mode1 (M1) and Mode2 (M2) with instructions. This is done in
Table 7.3 on page 253, the same assignment used for the TBIC.
Table 7.7 also contains some simple relationships that make it more
understandable.22

22
The following list of statements assumes Mode1 and Mode2 are not “00” or “10”. When they are
“00”, then no pattern of bits in the ABM control cells has any effect on the mission operation of
the IC. If they are “10” then the pin is HIGHZ regardless of cell content.
246 7 IEEE 1149.4: Analog Boundary-Scan

Table 7.7 Selection of ABM switch patterns versus Boundary Register cell content
Cells Modes 1/2 = 11 Modes 1/2 = 01 Modes 1/2 = 10 Modes 1/2 = 00
C/D/B1/B2 EXTEST, etc. PROBE, etc. HIGHZ BYPASS, etc.
0000 P0 P16 P0 P16
0001 P1 P17 P0 P16
0010 P2 P18 P0 P16
0011 P3 P19 P0 P16
0100 P4 * P0 P16
0101 P5 * P0 P16
0110 P6 * P0 P16
0111 P7 * P0 P16
1000 P8 * P0 P16
1001 P9 * P0 P16
1010 P10 * P0 P16
1011 P11 * P0 P16
1100 P12 * P0 P16
1101 P13 * P0 P16
1110 P14 * P0 P16
1111 P15 * P0 P16

Table 7.8 Logic equations for ABM switch control

ABM switch Logic equation (a trailing “*” indicates inversion)
SD M1*
SH CDM1M2
SL CD*M1M2
SG C*DM1M2
SB1 B1M2
SB2 B2M2

• When cell C = 0 (the first 8 rows), cell D determines whether the VG reference is
connected to the pin. These rows are used for analog measurements.
• When cell C = 1 (the last 8 rows), cell D controls the logic state of the pin for
1149.1-style interconnect tests. Thus cell C can be envisioned as a driver enable
cell and cell D is a self-monitoring data cell23 for the pin.
• In all rows, cell B1 controls the connection of AB1 to the pin and cell B2 controls
the connection of AB2 to the pin.
The logic equations for controlling the six ABM switch functions (remember,
some of the switches themselves may be conceptual) are given in Table 7.8.

23
Note however that cells B1 and B2 do have a parasitic effect of closing the switches on the analog
ABn bus to the pin. To prevent this, load B1 and B2 with “00” while doing 1149.1-style testing. Cell
D should also be set to “0” when the 1149.1 “driver” is not enabled, to prevent the VG reference
from being connected to the pin.
7.2 General Architecture of an 1149.4 IC 247

AB1 AB2
A B
VH VH
RP RP
SB1
RP
VL
Analog VL
SB2
Pin Analog
ABMESD Pin

Fig. 7.11 ESD protection circuit for a typical pin (a) and an 1149.4 pin (b)

There is one last detail shown in Fig. 7.9 on page 256. Note the electrostatic
discharge protection circuitry next to the pin pad. The existence of this circuitry
must be accounted for with respect to the connection layout of AB1 and AB2 and
the pin itself. The AB1 path conducts current, so there may be a voltage drop when
this current traverses the series resistance RP in the protection circuitry. This is only
a problem if the voltage sensing path for AB2 is inside this path so that the true pin
voltage is not being measured. Figure 7.11 shows a pin ESD protection network
before and after 1149.4 is added. The redundant paths allow us to remove the effects
of the voltage drop within the protection circuit. This is an important point because
IC layout processes may put a common metallization path with significant shared
impedance in place of the two independent paths [Nuri97b, Park97].
This concludes the discussion of the ABM architecture. Soon the 1149.4 instruc-
tion set will be described which will make use of the ABM structures. This should
answer some questions the reader has probably generated concerning how an
analog pin is supposed to behave during the execution of these instructions.

7.2.5 The Digital Boundary Module (DBM)

Digital Boundary Modules can be constructed in many ways, as discussed in Sect.

1.3.4. The term “module”, introduced by 1149.4, is used to refer to all the Boundary
Register cells associated with a given pin.24 This added nomenclature in no way
changes how 1149.1 relates to digital pins or how 1149.1 is implemented.

24
A clean assignment of cells to pins is somewhat blurred by the fact that in 1149.1, a single driver
enable control cell may be shared by several pins. Then there is cell merging (see Sect. 2.4.1 on
page 78) to further cloud this concept. Neither concept exists for cells in TBIC or ABM structures
governed by 1149.4.
248 7 IEEE 1149.4: Analog Boundary-Scan

D D D D

Outputs
Digital
Digital Digital
Digital
Inputs

D D D D
Core Core
D D D D

Interface
DBMs at
D D D

D/A D/A
Interface Interface
ABM ABM ABM ABM

Analog
Analog

I/O
Analog Analog
I/O

Core Core
ABM ABM ABM ABM

TBIC TBIC
TDI TDI

TDO TDO

A B InternIF

Fig. 7.12 Alternative forms for the Boundary Register depending on whether INTEST and/or
RUNBIST are supported

The philosophy behind DBM design is different than that behind the ABM.
While ABMs treat all pins homogeneously, DBMs strive to mimic the system nature
of the pins they control. That is why in 1149.1 you see “input”, “output” and “bidi-
rectional” DBMs. In 1149.4 you see a standardized ABM, though the implementa-
tion details may indeed reflect the nature of the pin by using some of the native
resources for that pin.
In a mixed signal IC, there is very likely to be an analog-to-digital and/or digital-
to-analog interface between the two domains. The 1149.1 standard has always
required that there be DBMs located at the interface between digital and analog
domains. The 1149.4 standard allows an option, shown in Fig. 7.12. If the IC does
not support INTEST or RUNBIST, the DBMs used to partition the analog domain
from the digital are not required.

7.3 The 1149.4 Instruction Set

The 1149.4 instruction set is a superset of the 1149.1 instruction set in two ways.
First, there is a new, mandatory instruction called PROBE described in Sect. 7.3.3.
Second, the instructions that target the Boundary Register such as EXTEST
7.3 The 1149.4 Instruction Set 249

(Sect. 7.3.1) and INTEST (Sect. 7.3.6) have expanded definitions that take into
account the fact that analog pins are now included.
Some 1149.1 instructions are identical in definition within 1149.4. For example,
BYPASS, PRELOAD, IDCODE and USERCODE are exactly the same in that they
are non-invasive. They have no effect on analog pins. This means they connect the
analog pin to the core circuit and open all other switches to isolate the pins (including
the ATn pins) from the test circuitry.
The HIGHZ instruction is also the same, but expanded to include the analog
pins, all of which float, completely isolated from the core and test circuitry. The
SAMPLE instruction is the same, but it also captures a digitization of the voltages
appearing on the analog pins.25 The remaining instructions described in the follow-
ing sections deserve a bit more discussion.

7.3.1 The EXTEST Instruction

The mandatory EXTEST instruction (see Sect. 1.5.1 on page 38) is still the funda-
mental workhorse of 1149.4. It is used in the familiar role of implementing 1149.1-
style interconnect tests. (see Chap. 3) It is also used to support analog measurements
for the testing of external analog components that make up extended interconnect.
On digital pins, EXTEST behaves exactly as described in 1149.1. On analog
pins, EXTEST may emulate “digital” behavior by either disabling an analog pin, or
by connecting it to a low or high voltage, VL or VH. (See switch patterns P0, P8 and
P12 in Table 7.6.) This allows many analog pins to participate in interconnect tests.
However, some analog pins may be connected to extended interconnect that pre-
vents them from emulating digital signals. In one case, the external impedance (for
example, a 50 Ω termination to ground) may be too low for the drive capability of
ABM to overcome in order to establish both logic states. When this occurs, the
interconnect test must treat the pin as fixed. Later, when analog measurements are
made of the external impedance, problems such as shorts and opens will be detected,
albeit sequentially and at much slower speed.
In another case, the extended interconnect presents very high impedance, such
that two nodes are logically independent. For example, in Fig. 7.2 on page 242 we
saw two analog pins connected through a capacitor. If this capacitor is (say) 100 pF,
then the two nodes connected to it are going to be logically independent. In this
case, they should be treated by the interconnect test algorithm as two distinct nodes
with their own interconnect serial test vectors (STVs) as discussed in Chap. 3. This
works because an ABM has bidirectional capability, allowing it to simultaneously
control and observe its pin.

25
Both HIGHZ and SAMPLE act upon the ATn pins as if they were system digital pins.
250 7 IEEE 1149.4: Analog Boundary-Scan

Test Power
Controller Supply 1 Device
Under
1149.4 Z Test
AT1 IC
AT2 2

i
TDI TDO
V
Digital Test TCK
Sequencer TMS

ATE System
Metrol1

Fig. 7.13 An ATE system set up to utilize 1149.4 resources in an IC to measure an externally con-
nected impedance

When EXTEST is used to support analog measurements, then a given ABM

involved in this process26 will use switch patterns P1 through P5 in Table 7.6. Note
that while some ABMs are used for analog measurements, all the other ABMs plus
the DBMs can be set up to disable or statically condition their respective pins in
support of these measurements. This is crucial because it stabilizes the circuit being
measured and reduces general system noise.
It is useful to see how a simple analog measurement is actually made with the
support of EXTEST. Consider the circuit shown in Fig. 7.13 where an ATE system,
using only the six-wire 1149.4 port, can measure the value of an external impedance
Z connected to an IC [Park93, Lofs96a, Nuri97b, Park97].
First, the ATE system must provide power to the board containing the circuitry.
This also establishes a reference for subsequent measurements and a return path for
current used to stimulate the circuit.
Next, the ATE system uses its digital sequencer to supply test patterns to the TAP
pins. First, TAP integrity patterns are applied to assure the 1149.4 devices (or chain
of 1149.1 and 1149.4 devices) is working. At this point it might then execute 1149.1-
style interconnect tests to test all the board wiring. Then we begin the measurement
of impedance Z. Refer now to Fig. 7.14.
To measure impedance Z we first instruct the ATE system’s current source to
produce a small current. This current proceeds along AT1 to the IC’s TBIC where it
is routed onto the internal AB1 bus. From there it travels to ABM1 where it gets
routed out onto pin 1 and the impedance. It travels through Z to pin 2 and back into
the IC where ABM2 routes it to the reference supply VG. This reference completes
the path back through the IC ground and the current source.

26
The TBIC must also be set up to connect one or both of ATn to ABn signals as needed.
7.3 The 1149.4 Instruction Set 251

AB1 ABM1 1
TBIC
Current
AT1 S5 SB1
SB2
Voltage Z
A AT2 S6

ABM2
i V

SG 2
AB2

AB1 ABM1 1
TBIC
Current
AT1 S5 SB1

Voltage Z
B AT2 S6

ABM2
i V SB2
SG 2
AB2
Metrol2

Fig. 7.14 Two measurements (a) and (b) used to find the voltage across Z for a known current

Now that a known current is flowing through impedance Z, we need to measure

the voltage across it so we can uses Ohm’s law to calculate Z. Figure 7.14a shows
that the ATE system’s voltmeter is connected to AT2. From there, the TBIC con-
nects AT2 to internal bus AB2. ABM1 connects AB2 to pin 1, completing the volt-
age measurement circuit (ground referenced). This allows the ATE system to record
the voltage at pin 1. Similarly, in Fig. 7.14b (for the same current stimulus configu-
ration) we can measure the voltage at pin 2. Subtracting these two voltages yields
the voltage across the impedance that results when a known current travels through
it. An example from [Park93] assumes the nominal value of Z is 50 Ω and that the
pathway impedance through the switches is much larger, totaling 5000 Ω. A 50 μA
DC current is used which develops a voltage of 0.2525 V at the AT1 terminal and
only 2.5 mV across Z. Assuming a 4½ digit voltmeter with a 10 μV resolution, there
will be 20 μV of potential error in the two voltage measurements. This translates to
±0.4 Ω of error, or 0.8 % in the final calculated value of Z.
There are practical issues (see [Park97]). The magnitude and type of current used
to stimulate the impedance must be selected such that for the expected value of Z,
252 7 IEEE 1149.4: Analog Boundary-Scan

the resulting voltages will be within operating range of all parts of this circuit. Keep
in mind the total impedance of the pathway must be considered, which includes the
series impedance of the three switches that conduct the stimulus current. A voltage
compliance limit on this current source must be set to keep it from exceeding these
operating ranges in the event there is an open circuit, or if Z has been misloaded
with a much larger valued device. If the component Z blocks DC current (for exam-
ple, Z is a capacitor) then an AC source may be needed as discussed in [Park97].
This example has illustrated the basic idea of using 1149.4 resources and the
EXTEST instruction to provide access to external impedances. Of course it will be
necessary to deal with networks of these impedances, and [Park93] showed how
this can be accomplished27 with more manipulations of the switches, and so on. But
the idea is the same; inject a known current and make a series of node voltage mea-
surements. The node voltage analysis technique [McDe98a, McDe98b] presented in
Sect. 6.2.1 on page 228 is a perfect match for this process, and also shows us how
we can reduce the number of nodes that must be measured to obtain a result. This is
particularly important when there are nodes in the network-under-test that are not
connected to either 1149.4 resources or test system probes.

7.3.2 The CLAMP Instruction

The optional CLAMP instruction (see Sect. 1.5.5 on page 40) is used to freeze the
states of digital outputs for the duration of some testing operation while placing the
BYPASS register between TDI and TDO for fast shifting.
In 1149.4, digital pins are treated identically. Analog pins too are frozen as well
as the state of the TBIC. Thus you can have an analog pin held to (say) VL or you
could even have a measurement setup frozen if it doesn’t need to change during a
set of analog measurements. The CLAMP instruction will most likely be used to
keep the both analog and digital circuitry quiescent while either digital or analog
testing is underway.

7.3.3 The HIGHZ Instruction

In 1149.1, the optional HIGHZ instruction (see Sect. 1.5.4 on page 40) when loaded
and activated, disables all output and bidirectional pins. The 1149.4 behavior is
identical for digital pins. For analog pins, the behavior is also to disable all pins by
opening the core disconnect function (switch SD in Fig. 7.9 on page 256) and dis-
connecting all test resources. The TBIC is also disabled.

27
This 1993 work was based on an extremely useful network analysis theorem given by Tellegen
[Tell52].
7.3 The 1149.4 Instruction Set 253

7.3.4 The PROBE Instruction

The mandatory PROBE instruction is the only instruction unique to the 1149.4
standard. It targets the Boundary Register between TDI and TDO. The designer may
choose the instruction bit pattern that decodes to PROBE. The PROBE instruction
is analogous to SAMPLE, but in the analog domain and with the restriction that
only one of the analog pins can be sampled at one time.28 This is because there is
only one set of ABn wires available to perform analog sampling.
When the PROBE instruction is active, all DBMs are set to allow digital pins to
be connected to the core circuitry. Also, all core disconnect functions (labeled SD in
Fig. 7.9, page 256) are closed so that all analog pins are connected to the core cir-
cuitry. Further, the TBIC switches are also governed by the content of the TBIC
control register so that ATn to ABn connections may be made as desired.
ABM switch patterns P16 through P19 in Table 7.6 are used by the PROBE instruc-
tion to connect none, one or both of the ABn lines to an analog pin. If AB2 is con-
nected (and AB2 is connected to AT2 by the TBIC) then the voltage appearing on any
analog pin can be monitored at AT2 in real time.29 In all other respects the IC is fully
operational although there could be some small parasitic effect from having the AB2
switch closed. If AB1 is also enabled (and AT1) then one can inject a small (attenu-
ated) stimulus into any analog pin while the IC is otherwise fully operational. This
could be useful for testing experiments where one wants to measure the effect of an
externally applied voltage, current, at frequency, such as in noise measurements.30

7.3.5 The RUNBIST Instruction

The optional RUNBIST instruction (see Sect. 1.5.3 on page 39) is identical to its
1149.1 definition. This instruction targets a register (that can be the Boundary
Register) between TDI and TDO that will collect the RUNBIST test result upon
completion of the RUNBIST action. This result can be shifted out to determine if
the test passed. As in 1149.1, there are two choices for I/O pin behavior while
RUNBIST is active. The first choice is to mimic the HIGHZ instruction, disabling
all output drivers. The second choice is to mimic CLAMP, controlling all outputs
via the content of the Boundary Register.

28
In CMOS technology, AB1 and AB2 could be electrically identical such that you could monitor
two pins at the same time.
29
This pathway is not a high frequency path because there is the significant series impedance of the
ABM and TBIC switches plus the external (mainly capacitive) loading on AT2. However, for lower
frequencies, or testing experiments contrived to operate at low frequencies, this is a powerful feature.
30
The ability to inject analog stimulus on a pin is why the PROBE feature is not considered an
extension of SAMPLE which is completely non-invasive.
254 7 IEEE 1149.4: Analog Boundary-Scan

Analog pins must behave the same way as the digital pins (HIGHZ or CLAMP
behavior). The signature developed by RUNBIST that is finally read out may or
may not give an indication of the health of the internal analog circuitry. In either
case, this result should be completely independent of any externally generated
analog signals appearing on analog inputs just as the signature is required to be
independent of any external digital signals.

7.3.6 The INTEST Instruction

The optional INTEST instruction (see Sect. 1.5.2 on page 38) is used to test the
internal circuitry of an IC while that IC is mounted on a board. In the 1149.1 world,
it does this by replacing each I/O pin with one or more Boundary Register cells and
using these cells to present inputs and collect outputs in parallel. If an 1149.4 device
supports INTEST, then the Boundary Register must include interface cells between
the digital and analog portions of the system circuitry as shown in Fig. 7.12b back
on page 263. This is because this interface contains I/O for both the digital and ana-
log portions of the device that must be controlled and observed in order to test each.
Just as with RUNBIST, there are two choices for I/O pin behavior while INTEST
is active. However there is a difference; the choices only apply to digital pins. The
first choice is to mimic the HIGHZ instruction, disabling all output drivers. The sec-
ond choice is to mimic CLAMP, controlling all outputs via the content of the Boundary
Register. Analog pins remain connected to the core during INTEST; that is, the SD
switch function is closed (see Fig. 7.9 on page 256). Further, each analog pin may be
connected to none, one, or both of ABn31 as controlled by the content of the ABM
control bits. (Switch patterns P16 through P19 in Table 7.6, page 258, are used.)
With 1149.4, the digital core can be tested with INTEST exactly as is done with
1149.1. Digital test patterns can be shifted in, applied to the core, and the result
captured and shifted out (see Sect. 3.1.5). The Boundary Register cells between the
analog and digital portions of the core ensure that the two portions are isolated and
unable to affect each other. Because of this, any activity on the analog I/O of the IC
will not propagate to the digital portion of the IC. This is shown in Fig. 7.15.
In 1149.4, INTEST can also be used to test the analog core as depicted in
Fig. 7.16. Here, the digital portion of the core is no longer the focus.32 Instead, the
analog core is controlled and observed at the internal digital-to-analog interface by
DBMs, and the analog I/O can be stimulated/observed via the ABMs. Of course,

31
Connecting either AB1 or AB2 requires that the TBIC also be controlled to connect the appropri-
ate ATn pins.
32
There is no difference in the operation of the test logic, just in the focus. In principle, you could
conduct testing on both the analog and digital portions of the circuit simultaneously, though this
would likely be cumbersome. Usually you would focus on one portion and leave the other in a
quiescent state.
7.3 The 1149.4 Instruction Set 255

D D
Digital Digital Digital
D D
Inputs Core Outputs
D D

D D D
Digital Outputs
Digital Inputs
Captured by DBMs
Supplied by DBMs
Unaffected by
Analog Signals

Analog Analog
I/O I/O

TDI TDO

Intest

Fig. 7.15 Testing the digital core using INTEST. The analog core is not directly tested

Digital Digital
Inputs Outputs

Digital Outputs of
Digital Inputs of Analog Core
Analog Core D D D Monitored by
Supplied by DBMs
DBMs D/A
Interface
ABM ABM
Analog Analog Analog
I/O Core I/O
ABM ABM

TBIC
TDI TDO

IntestAn

Fig. 7.16 The analog core can be tested by patterns supplied at the D/A interface and by signals
supplied or controlled by the ABMs
256 7 IEEE 1149.4: Analog Boundary-Scan

only one pin33 can be stimulated and one observed, though all may interact with
external circuitry. One can use other ATE resources to control the external circuitry,
if so desired.
INTEST and PROBE are similar in that they both allow the analog core to remain
connected to external circuitry. They differ in that PROBE allows the internal digital
circuitry to interact with the analog core, while INTEST disconnects the digital core
and supplies control and observation capability over their interface. See Sect. 7.4.2
for a discussion of how INTEST is used to test differential signal transmissions.

7.4 Other Provisions of 1149.4

What has been described to this point is a (near) minimal 1149.4 implementation.
Additions are provided for by the standard. These include adding a second TBIC
creating a differential ATAP port, a differential ABn bus, and the ability to partition
the ABn bus to isolate groups of analog pins more completely.

7.4.1 Differential ATAP Port

The 1149.4 standard allows for the addition of a second TBIC that provides two new
test pins AT1N and AT2N to an 1149.4 IC. Inside the IC, this second TBIC is con-
nected to a second ABn bus with wires labeled AB1N and AB2N. It is intended that
the ABn bus service the positive side of differential function pins and that the ABnN
bus service the negative side.34 The section immediately following describes how
1149.4 addresses differential function I/O.

7.4.2 Differential I/O

Differential I/O has been a surprisingly difficult topic for both the 1149.1 and 1149.4
Working Groups to deal with. (See also Chap. 8 on testing differential I/O with
IEEE Standard 1149.6.) Until only recently, the 1149.1 stance was that if a pair of
differential signals had a clear “digital” nature, then you would treat them as if they
were ordinary digital outputs, with a DBM structure devoted to each. However, if
they were not digital, then you would either ignore them, or place a DBM at the
boundary of the analog-to-digital interface (see Fig. 4.10 on page 169).

33
Two pins (each) may be tested if the differential option (see Sect. 7.4.1) is implemented.
34
A designer may also opt to add the second TBIC to provide for differential access to private func-
tions governed by private instructions.
7.4 Other Provisions of 1149.4 257

The 1149.4 Working Group had the charter for dealing with analog pins, so this
group couldn’t advise you to “just ignore” differential pins of either nature. The first
recommendation from this group was simple; put an ABM on all differential pins.
However, this led to some debate.
Debate Item 1: Differential drivers are often “special” designs that always create
opposite states on their pin pairs.35 Since 1149.4 can emulate 1149.1 for intercon-
nect test purposes, this requires that differential pins must not be constrained to
opposite states, at least during EXTEST-based testing. To actually do this in a dif-
ferential driver design may be quite difficult (costly).
Debate Item 2: Placing ABMs on differential pin pairs may be fine for manufac-
turing tests of individual boards where noise may be non-existent. However, if you
need to perform a system test of a differential pathway in a noisy environment, you
really do need to transmit data across the path in differential form. You could try to
coordinate two ABMs on the driver side to create the opposite states, but the two
ABMs on the receiving side do not have the ability to remove common-mode noise.
First, we examine Debate Item 1 a bit more. There are two scenarios. In one
scenario, we have only simple interconnect between the differential driver and
receiver such as we saw back in Fig. 4.10 (page 169). Thus an ABM that simply
disconnects (or places into a high impedance state) the differential driver and sub-
stitutes its own (weak) drive high/low capability on the pin will be sufficient to do
interconnect testing. All that is required of the differential driver design is that it be
disconnected on demand by the core disconnect signal.36 In scenario two, there is
extended interconnect between the differential driver and receiver, typically, low-
valued termination resistors. An ABM’s weak drive high/low capability would be
insufficient to create logic states into this loading. We can try to design the differen-
tial driver to act as the source of VH and VL for the ABM as 1149.4 allows if that is
practical. If not, we will have to omit these differential signals from 1149.1-style
interconnect testing. This means we will have to determine the integrity of the inter-
connect with analog measurements of the external impedances. This will detect
interconnect faults, but at the price of a sequence of slow analog measurements and
potentially degraded diagnostic resolution.
Then there is Debate Item 2, how to verify the noise rejection capability of dif-
ferential signaling. For this discussion, examine Fig. 7.17.
This figure shows an example of analog differential signaling and how you could
marry the 1149.1 and 1149.4 approaches to differential signaling. It places ABMs at
the I/O periphery and places DBMs at the boundary where the system changes to/
from differential signaling. From first appearances, the DBMs give you the ability

35
For digital pins, this means opposite voltage states. For analog pins, this may be represented by
the polarity of current flow, as one example.
36
This signal is “SD” in Table 7.8. Note the differential receiver should also be able to tolerate
non-differential signals that occur during interconnect testing. The SD signal may be used to gov-
ern this behavior.
258 7 IEEE 1149.4: Analog Boundary-Scan

Analog
Differential
U1 Signals U2
Digital Core

Digital Core
SIG+
ABM ABM +
CU CU
ABM ABM -
SIG-

D/A A/D
TDI Interface TDO TDI Interface TDO
DiffTest

Fig. 7.17 An example implementation for differential inputs and outputs

to drive and receive differential information and that seems sufficient to perform
system tests for noise rejection. You might imagine that EXTEST will be the way
this gets done. However, this is an example of the “EXTEST Paradox”. When you
load EXTEST into the Instruction Register, this indeed will set up the DBMs to
control the differential driver and observe the differential receiver. However, the
ABMs also respond to EXTEST by disconnecting the pins from the differential
driver and receiver. Thus you cannot test the noise rejection capability of this dif-
ferential pathway using EXTEST!
There is a solution. If you examine Fig. 7.17 closely, you will notice that it con-
forms to the general concept of separating analog and digital cores that was shown
in Fig. 7.16. In essence there is no analog core per se, just the digital-analog inter-
face. Note too that Fig. 7.16 illuminates the behavior of INTEST. This is our solu-
tion; use INTEST to test for noise rejection of differential signaling.
To do this, set U1 and U2 in Fig. 7.17 to perform INTEST. This allows the two
DBMs shown to control/observe the differential port. Remember that while in
INTEST, the ABMs leave the I/O pins connected to their respective analog cores,
which in this case are the differential driver and receiver. Is this a perversion of the
meaning of INTEST, you may ask? I’d have to say yes, but I can also hedge by say-
ing you are testing an ensemble of internal circuitry spanning two ICs.

7.4.3 Partitioned Internal Test Buses

For practical reasons, it may be undesirable to have a single ABn bus distributed to
all ABMs. A single bus could be a parasitic pathway for noise to travel from large-
signal outputs back to small-signal inputs. If an IC has multiple power supplies,
then some portions of the IC may have voltage levels that are incompatible with an
ABn bus that visits other regions of the IC supplied by other voltages. Thus 1149.4
supports the partitioning of ABn buses.
7.4 Other Provisions of 1149.4 259

AB1a
S5a
S9a
DAT1 S7a
VClamp
AT1 S8a
S10a
S1 S3 Dig S6a
AB2a
VH VL VTH
AB1b
S2 S4 Dig S5b
S9b
AT2 S7b
VClamp
DAT2 S8b
S10b
S6b
AB2b
PartTBIC

Fig. 7.18 Example of a TBIC structure with one extension (k = 2)

Table 7.9 TBIC extension switching patterns for the switches in Fig. 7.18 for extension k
Switch State (0/1 = open/closed)
P# S5k S6k S7k S8k S9k S10k Function
0k 0 0 0 0 1 1 ATn disconnect (Hi-Z), clamp ABnk
1k 0 1 0 0 1 0 Connect AT2 to AB2k Patterns P1 to P3 used
2k 1 0 0 0 0 1 Connect AT1 to AB1k for analog metrology.
3k 1 1 0 0 0 0 Connect ATn to ABnk
8k 0 1 1 0 1 0 For characterization
9k 1 0 0 1 0 1 For characterization

Partitioning may be done such that a single set of ATn pins can be connected to k
sets of ABn wires, labeled (AB1a, AB2a), (AB1b, AB2b), … (AB1k, AB2k). If k = 1,
then the TBIC is exactly as discussed in Sect. 7.2.3 beginning on page 250. The 1149.4
standard allows for k > 1 extensions of the TBIC, where each extension contains six
additional switches (four are mandatory) and two additional Boundary Register
control cells. Figure 7.18 shows an example where a single ATn port services two
ABn ports (k = 2). This structure is expandable to an arbitrary number of extensions.
Table 7.9 displays the switching patterns defined by the 1149.4 Standard for
extension k.
To control an extension we need two more Boundary Register control cells such
that we can control the switches in the extension independently of the main body of
the TBIC. The main body contains the non-replicated switches S1 through S4 plus
260 7 IEEE 1149.4: Analog Boundary-Scan

Towards S5b
TDO
S6b

Partition (b)
D2b
CU S7b
Uncommited, may
be used for improved D1b S8b
CU
TBIC testability S9b
S10b

M2

TBIC Control Logic, Partition (a)

From TAP Mode2 S1
Controller M1
Mode1 S2

D2a S3
DAT2 CU

From TBIC S4
Digitizers S5a
D1a
DAT1 CU
S6a

Co S7a
CU
Uncommited, may S8a
be used for improved
TBIC testability Ca S9a
CU
S10a
From
TDI PartCNTL

Fig. 7.19 Control structure for the extended TBIC switches in Fig. 7.18

the first set of switches S5 through S10 (all given the suffix “a”). The control structure
(for a single extension) is depicted in Fig. 7.19. Additional extensions may be added
in similar fashion.
The control for partition “a” (the main body) is identical to that shown in Fig. 7.8
(page 253), governed by Table 7.2 through Table 7.5. In general, since there may be any
number of extensions, Table 7.9 shows the switching patterns for the kth extension.
Then Table 7.10 describes how Boundary Register cells Ca plus two additional
cells D1k and D2k in the kth extension are used to select switch patterns. As before,
the asterisks in some entries indicate the definition of switching patterns that are
reserved for future definition.
It is useful to point out, for Table 7.10, that there are some simple relationships
that make it more understandable.37

37
The following list of statements assumes Mode1 and Mode2 are not “00” or “10”. When they are,
no pattern of bits in the TBIC control cells has any effect on the mission operation of the IC.
7.4 Other Provisions of 1149.4 261

Table 7.10 Selection of TBIC extension switch patterns versus Boundary Register cell content
Cells Modes 1/2 = 11 Modes 1/2 = 01 Modes 1/2 = 10 Modes 1/2 = 00
Ca/D1k/D2k EXTEST, etc. PROBE, etc. HIGHZ BYPASS, etc.
000 P0k P0k P0k P0k
001 P1k P1k P0k P0k
010 P2k P2k P0k P0k
011 P3k P3k P0k P0k
100 P0k * P0k P0k
101 P8k * P0k P0k
110 P9k * P0k P0k
111 * * P0k P0k

Table 7.11 Logic equations for TBIC extension switch control

TBIC extension switch Logic equation (a trailing “*” indicates inversion)
S5k D1kM2(Ca* + D2k*M1)
S6k D2kM2(Ca* + D1k*M1)
S7k CaD1k*D2kM1M2
S8k CaD1kD2k*M1M2
S9k S5k*
S10k S6k*

• When Ca = 0, the test circuitry is configured for test purposes. Otherwise it is

configured for characterization.
• When Ca = 0 (selecting the first four rows of the table) then none, one, or both of
the ATn ports are connected to ABnk. Cell D1k governs AB1k and cell D2k gov-
erns AB2k.
• When all three bits are “0”, the ATn port is disconnected from the ABnk bus.
Table 7.11 lists the logic equations for the control of the kth TBIC extension.
With this control structure, any extension can be connected to the ATn lines, and,
any ABn bus can be characterized independently.

7.4.4 Specifications and Limits

The 1149.4 standard gives specifications for items like path impedance, current car-
rying capacity, gain variation versus bandwidth, and so on. Some of these are
beyond the scope of this book,38 so just a few of these are given here to give the
reader an idea of what is expected of an implementation.39 When implementing an
1149.4 IC, it is very important to analyze these specifications ahead of time.

38
Others are beyond the scope of the author!
39
See [Vinn98], Chap. 7, where Steve Sunter gives additional guidance on characterization.
262 7 IEEE 1149.4: Analog Boundary-Scan

In CMOS-type technologies, the 1149.4 switching structures are most easily

implemented with complementary field effect transistor pairs linked in parallel, to
give bidirectional current flow. Here are some basic specifications on these switches.
• The impedance of the pathway from the AT1 pin (through TBIC switch S5) onto
AB1 and through an ABM to a system pin (through ABM switch SB1) should be
the lesser of: 10 kΩ; or an impedance that will allow 200 μA to flow through the
path when the voltage drop across the path is (VDD − VSS − 0.2).
• The path impedance from AT2 (through TBIC switch S6) onto AB2 and through
an ABM to a system pin (through ABM switch SB2) should be less than 10 kΩ.
• The impedance of the switch that connects VH or VL to a pin (when switches are
used) should be less that 10 kΩ.
• The impedance of the switch that connects VG to a pin is the lesser of 10 kΩ or
an impedance that will allow 200 μA to flow through the path when the voltage
drop across the path is (VDD − VSS − 0.2). This measurement is made with a
100 μA 1 kHz AC source.
These expectations of perhaps thousands of ohms in the pathways used for ana-
log measurements are an acknowledgement that for 1149.4 to be cost effective, the
switches must be very small. Indeed, in the earliest days of the 1149.4 development,
the working group had to give up on the idea of low-impedance switching (which
could support guarded measurements) and find a metrology that would work with
high-impedance switches. The experimental ICs developed for analysis [Lofs96a,
Nuri97b, Park97] have switches with hundreds to thousands of ohms impedance
and yet measurements of devices could be achieved with accuracy better than 1 %.
If instead of CMOS-type switches, 1149.4 will be implemented in a bipolar-type
process, then buffers that can be disabled must be used in the measurement pathways.
Here are some specifications for these buffers. In the pathway from AT1 to a pin:
• They should be able to deliver any current between −100 and +100 μA.
• The absolute value of the gain should be between 0.5 and 1.5.
• Input currents that exceed the capability of the buffer should cause the buffer to
saturate with a recognizable voltage output that indicates saturation.
• In the voltage AT2 pathway from any pin:
• buffers should be capable of monitoring any voltage between VDD + 0.1 V and
VSS −0.1 V.
• The maximum absolute value of gain should be 1.0.
• Input voltages that exceed the capability of the buffer should cause the buffer to
saturate with a recognizable voltage output that indicates saturation.
• It is recommended that buffers have less than 5 % variation in gain between
10 Hz and 10 kHz and have a 3 dB bandwidth of 0–100 kHz.
Characterizing the buffers compensates for the fairly loose specifications
(for example on gain). This is one thing the TBIC loopback switches (S7, S8) may
be used for.
7.5 Design For 1149.4 Testability 263

7.5 Design For 1149.4 Testability

Embedded in the previous sections is some rationale for some DFT rules at the IC
level. Rules for board level DFT are harder to come by for lack of experience. And
at the system level (depending on what a “system” is) we have less still. However,
this section presents a collection of DFT guidelines we can imagine today.

7.5.1 Integrated Circuit Level

We have already had hints of DFT rules show up in previous sections. For example,
in Fig. 7.11 (page 261) we saw that we need to take care in laying out ESD protec-
tion circuitry. Since the AB1 bus may conduct a significant current to a pin, we want
to avoid errors that can occur if we connect the AB2 path at a point where we are no
longer measuring the voltage of the pin itself. This becomes more important as the
line widths of metallization paths become narrower with decreases in IC geome-
tries. This leads us to our first rule.
• DFT-28: Eliminate all common conductive paths between a system pin pad
and the ATn switches (SB1 and SB2).
In Sect. 7.4.3 we saw that we can implement multiple ABn busses with separate
switching. This adds isolation between groups of pins that may otherwise want to
“talk” to each other over the parasitic impedances that can exist. Other reasons to
break the ABn buses into smaller groups are (1) to reduce the accumulated leakages
in any one bus that are the sum of the small leakages that each switch contributes,
and (2) to reduce the accumulated capacitance that each switch will contribute.
Excessive leakage or capacitance may damage the ability of the circuit to perform
analog measurements during testing. An IC designer is well suited to evaluate the
sensitivity of his/her design with respect to these criteria.
• DFT-29: Partition internal analog test buses (per Sect. 7.4.3) to control on-
chip cross talk, leakage, and capacitance.
In some cases the switches themselves, due to their parasitics, may introduce a
worrisome amount of coupling between portions of the circuitry. All the switches
shown to this point are simple transmission structures that take a minimum area but
may not provide optimum isolation. For cases where there is sensitivity to these
parasitics, a pair of switches in series with a shunt switch that connects the middle
node to a quiescent reference voltage (called a “T” switch) can be used to greatly
improve the isolation of the two sides of the overall switch structure as shown in
Fig. 7.20. On a local scale of a single switch, this is similar to the effect we are pur-
suing via bus partitioning examined in the previous DFT rule (DFT-29).
As IC feature geometries continue to shrink, the leakage in these switch struc-
tures will rise. The “T” switch will be very useful for controlling this leakage. So
while the “T” switch is a larger structure, smaller feature sizes will mitigate the cost.
264 7 IEEE 1149.4: Analog Boundary-Scan

Enable Enable
TSwitch

Fig. 7.20 A conventional transmission gate switch and a shunting “T” switch structure that
reduces coupling when the switch is off

• DFT-30: Examine the location of switches for places where the circuit may
be sensitive to parasitic coupling and leakage. Use enhanced switch designs
in these areas to reduce these effects.
Continuing on the topic of parasitic effects, consider how your ATAP pins are
positioned in the IC’s physical pinout. If they are adjacent to each other, can they
influence each other via leakage and capacitance? How about if they are adjacent to
active digital signals, will they be disturbed by these signals during functions such
as PROBE? The layout of the ATn pins with respect to power and ground pins may
be used to mitigate parasitic effects. Consider placing the VG reference voltage pin
between them since subsequent measurements will use this voltage reference.
• DFT-31: Analyse the layout of the ATn pins with respect to leakage and
parasitic effects between them and other signals.
Finally, consider implementing the optional INTEST instruction since this gives
the ability to isolate the digital and analog portions of the IC for tests done later at
the board or system level (see DFT-35 on page 282).

7.5.2 Board Level

Board DFT for 1149.4 deals with the fact that two ICs containing 1149.4 may not
be compatible with respect to the reference voltages they use internally. These volt-
ages may appear at system pins or the ATn pins. Assume that if two ICs have their
system pins connected, this implies they are compatible at those pins. However,
since the ATn pins can be driven and received, some choice had to be made for the
voltages that are used on these pins. It is possible that they are not compatible from
IC to IC. In Fig. 7.6 (page 250) we saw ICs with their respective TAP and ATAP
pins connected together. It may turn out that the TAPs are all implemented in a com-
mon technology, (say, 3.3 V CMOS) but that VH, VL and VTH used in their respective
ATAPs are not compatible. This would be a reason why a chain of devices, as
viewed by the 1149.1 standard may require separated ATAP ports. If this is neces-
sary, then plan on grouping compatible ATAPs together with common wiring, inde-
pendently of how the TAPs are chained. This will necessitate test access to multiple
7.5 Design For 1149.4 Testability 265

ATAP ports even if there is only one TAP chain on board. For manufacturing test,
this should not present any problems (as long as we have access to all the ATn ports)
since the ATE system can choose which of the ATn ports to access. However, if a
design goal is to implement an embedded self-test using these resources, the addi-
tional ATn ports will have to be accommodated, perhaps with multiplexing to the
board level stimulus and measurement resources.
• DFT-32: Group compatible ATAPs together on common ATn buses. Be pre-
pared to accommodate more ATAP buses than there are TAP chains.
With respect to leakage between ATn signals, an extension of DFT-31 may be
considered at the board level. In analog designs, it is a well-known board layout
technique to place a “guard wire” between two sensitive signal wires. This wire is
connected to a quiescent reference voltage40 also used in measurements (typically
ground) as suggested in Fig. 7.21. Board leakage may be exacerbated by “no-clean”
board manufacturing processes where ionic contamination from manufacturing
(typically soldering) is often still present.
The decision to use a guard wire during layout can be made by examining what
types of values will be measured by a given ATn port. If lower impedances (for
example, termination resistors) will be measured, then guarding will not be needed.
If high impedance, high precision devices (many megohms) are the measurement
target, then a guard wire may be important. Note that in Fig. 7.21, guards are shown
connected to ground. In general, the board node connected to an IC’s VG pin is what
should be used for the guard. It is possible that two identical ICs on the same board
may have their VG pins connected to different voltages. If guard wires are needed
for both ICs, then they should probably have independent ATn ports.

AT1 AT1 AT1

AT2 AT2 AT2

Pin Guard Guard Wire Driven Guard

Guards

Fig. 7.21 Degrees of guarding between two ATn signals

40
In extreme cases, for example, ultra-high resolution voltmeters, this guard wire completely sur-
rounds a sensitive wire in a “box”. Further, it may be a “driven guard”, where an amplifier copies
the signal from the sensitive wire onto the guard to keep the guard wire at the same potential. Thus
there is no voltage between the guard and the target wire and any leakage from surrounding cir-
cuitry is absorbed by the guard. Obviously, care must be taken with this type of guard design. It is
unlikely that driven guards would be needed in 1149.4 designs.
266 7 IEEE 1149.4: Analog Boundary-Scan

• DFT-33: For ATn ports expected to be used in measurements of very high

impedances, place a board-level guard wire between the ATn signals.

7.5.3 System Level

At the system level, it may be important to make analog measurements utilizing the
analog test facilities of 1149.4. Or, it may not! This is a strong function of what a
“system” looks like and what type of analog measurements may be required of the
system. The full suite of analog measurements of interest at board test may be over-
kill at system test. This will determine how many ATn ports need to be made acces-
sible to a system level analog stimulus/measurement facility.
My favorite hypothetical example comes from the automotive industry. The
engine control system for an automobile could be implemented with 1149.1/1149.4
technology to support system level testing and diagnosis. Interconnect tests would
be very important since it is well known that interconnections (cabling and connec-
tors) in cars are a weak point. Though there may be many analog components too,
it may be too difficult (expensive) to make analog measurements on all of these if
doing so requires routing several ATn domains back to a central analog stimulus and
measurement resource. However, certain analog devices may be wear items that are
expected to degrade in time. These could be serviced with a port while most other
items are not.
• DFT-34: Consider which of all ATn ports in a system will be needed for sys-
tem test and provide access to them.
Finally, at system test, we may want to test differential signaling and its immu-
nity to system noise. This is a digital test, but requires the 1149.4 resource for dif-
ferential testing provided by the INTEST instruction (see Sect. 7.4.2 on page 272).
This gives us our last DFT rule.
• DFT-35: Consider if noise-immunity testing of differential signaling is
required in the system.

7.6 Summary

This single chapter describing the 1149.4 standard is breathtakingly short when you
consider the scope of the Mixed Signal Test Bus standard. This brevity is in part due
to the fact that the 1149.1-emulation capability contained within 1149.4 is covered
in previous chapters. But another reason is that the whole concept of 1149.4 is still
new and we have much yet to learn from experiences with it. Test ICs [Lofs96a,
Nuri97b, Park97, Sunt96, Sunt01] have been invaluable for proving concepts and
gaining experience. There are also new textbooks on this standard [Osse99, Vinn98].
7.6 Summary 267

I have been asked many times to speculate on the rate of adoption of the 1149.4
standard. I see several factors in this.
• To its advantage, 1149.4 builds upon the growing infrastructure of 1149.1 tools,
products, knowledge and experience. Indeed it is possible to perform useful digi-
tal interconnect tests (even in extended interconnect cases) with 1149.4 using
today’s software, unmodified [Park97].
• The level of concern that people have today about limited physical probing
access is quite high. People perceive a lack of alternatives and a motivation to
“make it work”. These people will also expect IC vendors to make good-faith
efforts to support their test needs. (This is true for 1149.1 as well.)
• While not often admitted by 1149.4 Working Group members, the 1149.4 stan-
dard is CMOS-centric. The good news is that CMOS-type technologies are
becoming more prevalent in mixed-signal IC designs, if for no other reason than
the densities it can achieve for the digital portions of the ICs.
• To its disadvantage, 1149.4 is harder to implement because, after all, it is an
analog design problem.
• The “market size” of mixed-signal designs, while growing respectably, is still a
good bit smaller than that of digital designs. This may retard investment in
advanced tools for a time.
• The 1149.4 standard can also be used to facilitate testing of ICs that contain it,
by making it possible to test pin parametrics without a large number of analog
test channels in the tester (see [Sunt02] and also Sect. 4.1). This will add appeal
to IC producers looking to lower their IC production test costs.
• The 1149.4 standard will more sensitive to the accuracy of data you have about
the construction of a board and its ICs. It is fitting to end this chapter with the
same warning that appeared on the first page of this book, that if you are not in
control of your data, then Garbage In, Garbage Out will be the result.
Pressed for a prediction, I say that I expect the adoption of 1149.4 to be similar
to 1149.1 which took a longer period than proponents had anticipated. However,
I personally have seen mixed-signal products on drawing boards for which there are
extraordinary testing problems that only 1149.4 can solve. Until 1149.4 comes of
age, we are likely to see such products cost more than they should and be late to
market. This will be an incentive for larger manufacturers who see 1149.4 as a stra-
tegic opportunity. I find it interesting that globally, 1149.1 was adopted last in the
Far East. Today, I see high levels of interest with significant participation in 1149.4
from the Far East. This should be raising eyebrows in rest of the world.
Chapter 8
IEEE 1149.6: Testing Advanced I/O

IEEE Standard 1149.6 [IEEE03]1 addresses “Boundary-Scan Testing of Advanced

Digital Networks” but has become known popularly as “The AC EXTEST” stan-
dard. This popular title is really a misnomer. The formal title speaks of testing of
advanced digital networks, meaning the I/O structures between ICs. During the
development of IEEE Standard 1149.1 over a decade ago, communication between
ICs was conducted over single wires. Now we see a growing trend for differential
transmission of signals, using two wires per signal channel, and we also are begin-
ning to see AC coupling structures between ICs. AC-coupled differential channels
are a signaling process that effectively defeats the testing capabilities of IEEE 1149.1.
This rather alarming development caused a flurry of action within the electronics
industry. First, two companies2 recognized the problem in the year 2000. After a bit
of discussion they realized that this was a general problem for the industry. An
informal group of people from over 20 companies was assembled, called the “AC
EXTEST Working Group” (hence the popular name) and it began to develop some
proposals [Chun01, Kim01] for solving this problem. At first it was thought that
only the AC-coupling problem existed. But as research continued, the group came
to realize that a larger problem existed, that of “Advanced I/O”. This became the
focus of proposed solutions. Soon, the group took several potential solutions to the
IEEE and formally incorporated itself as an IEEE Working Group in 2001 [Eklo02].

1
Some drawings and definitions in this Chapter come from IEEE Std. 1149.6. Copyright 2003
IEEE. All rights reserved.
2
Cisco Systems had AC-coupled differential designs on their drawing boards. Realizing a problem,
they contacted Agilent Technologies for advice on both the design of AC-coupled IC drivers and
receivers, and on how to test such structures using some revision of Boundary-Scan. These two
companies spearheaded the industry’s development of a solution.

© Springer International Publishing Switzerland 2016 269

K.P. Parker, The Boundary-Scan Handbook, DOI 10.1007/978-3-319-01174-5_8
270 8 IEEE 1149.6: Testing Advanced I/O

8.1 The Advanced I/O Problem

As Moore’s Law3 inexorably advances IC technology, it is reasonable to expect the

number of transistors (and gates) to grow exponentially. We often hear of “N-million-
gate” ICs, where N keeps rising. However, all ICs also have input/output structures
(called “I/O pads”) that need to be updated with Moore’s Law as well. This is actu-
ally a very complex problem, firmly rooted in the black arts of analog design and
solid-state physics.
Logic designers typically fear to tread into this domain. They depend on a small
cadre of “Pad Designers” who produce the magic black boxes that will transmit and/
or receive logic signals on and off chip. These designs are placed in a design library
where logic designers can call them up as needed, with little understanding of how
they actually work, just as software programmers call utility routines from archives.
These routines perform stated functions when properly instituted and hide the messy
details of their implementation.
In the earliest days of the formulation of Boundary-Scan, pad designs were rela-
tively simple, containing a few dozen transistors, diodes and resistors. Now pad
designs may be rightly thought of as small systems in themselves, containing many
hundreds or thousands of transistors. Some of these form logic, but many handle
analog signals as well. A driver today may have programmable or even adaptive
characteristics, where it can change its drive current strength, slew rate and voltage
levels. These capabilities allow ICs to perform at higher frequencies, and better
match the board transmission impedance they may be driving. One cause of all this
effort is that ICs can run internally at extreme frequencies far into gigahertz ranges,
but bringing signals off-chip is very difficult at even relatively reduced frequencies.
A lot of sweat goes into achieving this.

8.1.1 Traditional Inter-IC Communication

For many years the electronics industry has used a bus architecture for data and
address information sent in multi-bit packets, transmitting one bit per wire in the
bus per increment in time defined by a clock signal. Wires in the bus would fan out
to each IC (or off-board signal connector) and typically would support bidirectional
data transfer, as shown by example in Fig. 8.1.
This architectural style of inter-IC communication has limitations on data rates
that can be achieved. These limits are governed by the number of ICs being con-
nected, their physical layout on a board, and the relative difficulty in coordinating

3
Gordon Moore of Intel: “IC density doubles every 18 months”. The implications are that costs can
decrease, and gate speeds can increase non-linearly as well.
8.1 The Advanced I/O Problem 271

64-Bit Single-Ended
Bidirectional Bus IC2

IC 1

IC3

TDI TDO
CLK-2
CLK-1
CLK-3
Clock
Master
Distribution
Clock
& Deskew
PrllBus

Fig. 8.1 Traditional single-ended bidirectional bus architecture for inter-IC communication

data transfers using a centralized clock structure. Adjusting clock skew becomes a
major effort as data frequencies climb. Maintaining signal quality is a necessity,
yet the layout of busses as more devices are connected works against this goal. As
more ICs are connected to a bus, the clock skew management problem also gets
much more difficult.
Another factor is that traditional data busses were single-ended, meaning a sin-
gle wire carried a single bit of data. (Contrast this with differential transmission,
where two wires carrying positive and negative copies of data are used.) This was
economical in pin count and layout difficulty, but even a solitary single-ended wire
has data frequency limits. Over the years, busses widened from 8-bit to 16-bit,
32-bit and on to 64-bit and higher. This was the principle method of raising data
rates since clock frequencies seemed to level out in the one-or-two-hundred-mega-
hertz range. Obviously, widening the busses cost more in pin counts and layout
difficulty. But less obvious problems come from the fact that on-chip and on-board
current surges (often lumped into the topic of “ground bounce”) get worse with
increasing single-ended bus width. The amount of current surge is data-dependent
from clock cycle to cycle. Thus signal quality is again at risk. In response to this,
ICs have been given more power and ground pins to reduce the inherent inductance
and resistance seen by the power surges, in an effort to control them. So we see ICs
getting higher pin counts for parallel bus signals, and also for power distribution.
This is costly.
272 8 IEEE 1149.6: Testing Advanced I/O

People working in leading edge data communications businesses (network rout-

ers, high capacity servers) have a unique combination of need (for higher data
speeds) and investment capability (they sell high-end products). They helped drive
a move towards “advanced I/O” to find better ways to transfer data across boards
and systems at high speed. This development is now rapidly moving into main-
stream products, such as volume consumer products like personal computers (see
“PCI Express” or “3GIO” bus specifications on the World Wide Web). One element
that makes this possible is (again) Moore’s Law.

8.1.2 Advanced Inter-IC Communication

When you poll people in the high-speed data transmission segments of our industry,
they feel that the higher limit of data transmission speed in copper wires on printed
circuit boards made with “ordinary” materials and processes will be about 10 giga-
bits per second. Above this they need to take extraordinary measures (read: costly)
or move into the optical transmission domain, using light. Ten gigabits per second
(per wire) is about 50 times the de-facto limits seen with single-ended bidirectional
architectures of the past.
It is interesting to note that the technologies needed to move into the gigabit
realm are already well known and understood. The first technology change is to
move from single-ended to differential data transmission. This transmits a single bit
of data on two parallel4 wires. Single-ended signals are referenced to fixed voltage
levels Vlow and Vhigh (see Fig. 8.2). If noise is present, data being transmitted may be
damaged if the magnitude of the noise causes extra transitions in a signal.

Logic high
Vhigh
0-1 Undefined
Vlow
Logic low
Single-ended
Noise driver

Logic high
Vhigh
0-1 Undefined
Vlow
Logic low
Single-ended
driver SnglRef

Fig. 8.2 Two single-ended drivers, one affected by noise such as ground bounce

4
Note that differential wiring has strict layout rules governing trace widths, spacing and thickness,
as well as rules about the proximity of ground planes, dielectric constants and impedance control.
8.1 The Advanced I/O Problem 273

Neg
Pos
Out 0-1 Switching
0-1 Neg Point
Pos
Differential Differential
driver receiver Logic high
Undefined
Logic low
Out = Pos - Neg
Noise

Pos Neg
Out 0-1 Switching
0-1 Neg Point

Differential Differential
driver receiver Pos
Logic high
Undefined
Logic low
DiffRef
Out = Pos - Neg

Fig. 8.3 Two differential driver/receivers, one affected by noise

Differential signals are not referenced to fixed voltage levels, but rather, to each
other. Figure 8.3 shows and example of one differential driver/receiver pair trans-
mitting a normal signal, and one affected by “common mode” noise, which is noise
added equally to both the positive and negative signals. When you look at the volt-
age waveforms produced by a differential driver on the two wires, they are effec-
tively analog complements of each other5 except for any common mode noise.
A differential receiver literally takes the difference of these two signals to regener-
ate the originally transmitted data stream. This has the advantage of canceling out
any common mode noise. Principle sources of common mode noise are radiated
interference and that feared nemesis, ground bounce. Note also that differential driv-
ers have a “current balancing” effect on an IC’s internal power distribution. For every
wire now sourcing current, there is a second sinking that same amount6 of current.
This balancing greatly reduces the I/O noise generated by current surges on-chip.

5
A common differential driver design works by switching the direction of current flow on the pair
of wires it drives. One direction encodes a “0” bit and the other encodes a “1” bit. Near or even
within the receiver, there is a simple resistor terminator across the two wires that converts current
direction into voltage.
6
This holds true for differential wire pairs that are equally loaded. Again, the layout of the pair, if
not properly engineered, may violate this assumption when edge rates that are much faster than the
transmission time of the wire path interact with asymmetries in the wire pair.
274 8 IEEE 1149.6: Testing Advanced I/O

But, you say, differential data transmission must double the pin count on my
IC. My 64-bit data bus now needs 128 wires! This looks bad. But here is where
Moore’s Law helps. Data that was transmitted in parallel can be serialized into a
single data stream. Yes, that takes time (and more than a few gates), but if you spend
a bit of energy on designing a single high-speed differential driver, you can take
(say) eight bits of data and transmit them serially faster than you could get them
across a board with eight single-ended parallel wires in one clock cycle. Thus two
wires can replace eight wires, with better signal integrity as well. An example of this
is shown in Fig. 8.4, where the same architecture as shown in Fig. 8.1 has been
converted from parallel single-ended bidirectional busses to pairs of unidirectional
differential busses of smaller widths. Note that bus pairs may be of different widths
to account for the data transmission need between pairs of ICs. In this example,
between IC1 and both IC2 and IC3, there is a need to transmit more data per unit
time, so eight-bit serialized busses are used. But between IC2 and IC3 alone, the

4-Bit Serialized
Differential Buses

IC2
8-Bit Serialized
Differential Buses
IC 1

IC3

TDI TDO
CLK-2

CLK-1 CLK-3 SerlBus

Fig. 8.4 Serialized high-speed data transmission on dedicated unidirectional paths. This is a seri-
alized implementation of the system seen in Fig. 8.1

Table 8.1 Comparison of pin counts for busses in the structures shown in
Figs. 8.1 and 8.4. (Does not account for power pins)
Bus pin counts
Single-ended bidirectional Serial differential
IC1 64 (1 bus × 64 bits) 64 (4 busses × 8 bits × 2 wires)
IC2 64 48
IC3 64 48
8.1 The Advanced I/O Problem 275

bandwidth requirement is less, so a pair of four-bit busses could suffice. Table 8.1
compares the bus pin counts on each IC for the two schemes. There is no change in
pin count for IC3 because the serialization ratio chosen was 8-to-1 and it communi-
cates with both ICs 2 and 3 at maximum bandwidth. ICs 2 and 3 both see a pin count
reduction because communication between them is at a reduced bandwidth. Another
important boost to bandwidth is the fact that in Fig. 8.4, all six busses can be trans-
mitting data independently and simultaneously, while in Fig. 8.1 only one path, in
one direction between two ICs can be transferring data.
Yet another advantage comes with serialized data transmission technology, and
again it is a well-known idea: incorporating clock with data. This technology looks
at (say) 8-bit bytes of parallel data that may be any of 256 combinations of zeroes
and ones. It then expands these bytes into (say) 10-bit packets of data that are always
guaranteed to contain a minimum number of zeroes and ones such that there are
never long contiguous strings of either data. (The algorithms for this are also well
known.) These ten bits are transmitted serially. A cooperating serial receiver that
has no knowledge of the transmission phase or frequency is able to recover the
original 8-bit bytes from the 10-bit serial packets. When each is recovered, it can
then be sent out in parallel using a clock that has been recovered from the data
stream. This technology is known as clock/data recovery. Thus an IC transmitting
data using one (or more) independent clocks can send data to a second IC using its
own clock(s), without need of closely coordinating the timing between them. This
is shown in Fig. 8.4 as three independent clock domains with no deskew control
seen in Fig. 8.1. This property greatly simplifies board design.
Serialized data transmission technology is today denoted by the “SERDES”
acronym (for SERialize/DESerialize). You see it in common I/O standards such
as Gigabit Ethernet, FireWire, Sonet, PCI Express and others that you can find on
the World Wide Web. Figure 8.6 shows the parallel bus implementation in Fig. 8.5
re-implemented with SERDES technology.
Moore’s Law now allows the gate density needed to replace parallel single-ended
drivers and receivers with SERDES structures. Further, the availability of pre-
designed SERDES core descriptions allows mortal designers to incorporate these
technologies with much less effort.

8.1.3 AC Coupled Signal Paths

In years past, digital ICs were connected together with simple wires, or at worst,
with a small-valued resistor used to improve signal integrity. Now we see digital ICs
connected with capacitors. Why is this? The answer has two elements, one driven
by technology and one driven by business considerations.
Technology, again manifested by Moore’s Law, has created new IC processes
that are denser. As transistors get smaller, their operating voltages must come down
to solve solid-state physics problems of heat dissipation and leakage, and also to
keep voltage gradients across junctions from becoming excessive. In the 1980s and
276 8 IEEE 1149.6: Testing Advanced I/O

TX Bit 1 RX

Bit 2
Mission Logic

Mission Logic
Bit 8

Master Clk
NonSerl

Fig. 8.5 Classical parallel single-ended bus structure

TX RX
Serial-to-Parallel Decoder
Parallel-to-Serial Encoder
Mission Logic

Mission Logic
8-Bit to 10-Bit

10-Bit to 8-Bit

Recovered Clock
TX CLK 8b10b

Fig. 8.6 Same system as Fig. 8.5, but with a SERDES implementation

into the 1990s, we saw new generations of IC processes that maintained the 5-V
regime originally dominated by TTL and earlier CMOS logic families. There were
sound business reasons to maintain voltage compatibility across these generations.
However in the later 1990s we could no longer (reasonably) maintain this
compatibility, and we saw the advent of 3.3-V logic, albeit with “5-V compatibility”
8.1 The Advanced I/O Problem 277

R = Z0 R = Z0 VBias

DC-Coupled Path AC-Coupled Path

DC-ACcpl

Fig. 8.7 DC and AC-coupled differential paths

that allowed such logic to talk with older ICs. This then led to many logic families
with supply voltages that are new to us, from 3.3, to 3.0, to 2.5 and even 1.8 V. You
might be able to directly connect a 3.0-V device to a 2.5-V device, but there is some
chance that their performance will be compromised by this difference. For example,
the logic high level of the 3-V device may be 2.8 V, and this may overdrive the 2.5-V
device’s inputs causing a performance slowdown due to saturation. The 2.5-V
device may have a logic high level of 1.8 V, and this may be “just barely” a logic one
for the 3.0-V device. This implies a loss of noise immunity between the two. In
essence, there may be scaling and offset errors between the two sets of logic levels
that degrade their performance when DC-coupled.
Now consider what happens if we AC-couple two digital devices with capacitors
(as in Fig. 8.7) and for the moment assume the coupling time constant value is large7
with respect to the data rates being transmitted. On the driven side of the capacitor,
we see voltages that range from Vlow to Vhigh. On the receiver side of the capacitor,
we will see voltage changes that have a magnitude of Vhigh minus Vlow, but what is
the actual range of these voltages? This is determined by bias generation that is
explicitly provided by a bias network on the board, or by bias generation provided
within the receiver itself. This bias point becomes the midpoint of the Vhigh minus
Vlow swing, and can thus be engineered to “translate” the voltage levels of the driv-
ing IC to those more compatible to the receiving IC. Note that the magnitude of the
Vhigh minus Vlow swing may exceed the best range of the receiver, and this swing can
be reduced by an appropriate voltage divider. However, in many cases the swing
magnitude is less of a concern than mismatched levels. Thus it is possible to squeeze
more performance from two somewhat incompatible devices from different pro-
cesses by using AC coupling.8 Even with differential signaling, which is designed to
be somewhat “forgiving” of level mismatches, there is usually a performance “sweet
spot” where the best performance can be achieved. In leading-edge products, this
can be very important.

7
If the coupling time constant is too small, then the charge on the capacitor can drain away, reduc-
ing the voltage with a classic RC discharge curve, ultimately to zero.
8
Deliberately omitted are several other concerns, such as what happens when a long string of
zeroes or ones is transmitted that would eventually discharge even a larger capacitor. SERDES
technology solves this problem by inserting extra “data” to help “balance” the charge over the long
term. This makes AC coupling work during normal mission mode, but we have yet to discuss how
Boundary-Scan will be affected…
278 8 IEEE 1149.6: Testing Advanced I/O

Above we have seen a hint of the business consideration for AC coupling. If you
are a manufacturer buying very large quantities of ICs, you most likely are acutely
interested in “supply chain management”, which in a nutshell means getting the
most for your purchasing dollars. You can usually get better prices for ICs when
there are competing suppliers. But if two IC suppliers are manufacturing ICs in
somewhat different processes, it may happen that supplier A’s devices work less
well with supplier B’s devices than with more of supplier A’s devices. Thus, if your
designs call for DC-coupling these devices, you may be locked into using only
devices from supplier A. However, if your designs can be AC-coupled, then maybe
you can buy from both suppliers A and B. Thus you can write supply contracts for
second source suppliers when you know they use different process technologies,
and still mix the devices in the design. This may lead to substantial cost savings.

8.1.4 Testing Advanced I/O

Advanced I/O introduces new testing problems and confounds those that already
exist, especially those with differential signals already alluded to in Sect. 4.6. The
1149.1 standard is, for practical purposes, a DC technology as depicted in Fig. 8.8.
Thus, AC-coupling presents an insurmountable problem as shown in Fig. 8.9
where test data generated at Update-DR decays away before we can get to

C U C U

TX RX

Update-DR
2.5 TCK Cycles
VH
TX
VL
VH
RX
VL
Propagation Capture-DR DCpass

Fig. 8.8 DC-coupled signals propagate and remain available indefinitely

8.1 The Advanced I/O Problem 279

C U C U

TX RX
VT
Update-DR
VH
TX
VL
VT+VH-VL
RX
VT
Capture-DR ACfail

Fig. 8.9 AC-coupled signals that decay before they can be captured

Capture-DR. In principle, one could try to mandate that the coupling time constant
be much longer than the time between Update-DR and Capture-DR, but in practice,
this presents a design constraint on the coupling and a performance requirement on
test systems, either of which is likely to be unacceptable.
It is quite true that IEEE Standard 1149.4 (see Chap. 7) provides additional test
resources that could be used to solve such problems. For example, in the AC-coupled
circuit in Fig. 8.7, we could use analog measurement techniques supported by
1149.4 to measure the values of the coupling capacitors, the termination resistor R,
the value of VBias and the values of the bias resistors. When these values were veri-
fied to be correct, this would effectively guarantee that they were all connected
properly (no shorts or opens) and that they were all there, in the right places.
However, if you had many hundreds or thousands of such couplings to test, a linear
sequence of analog measurements would take a significant amount of time. We have
seen in Chap. 3 that Boundary-Scan interconnect testing is a relatively speedy “digi-
tal” process by comparison as it tests all interconnections in parallel. Since we
believe that advanced I/O problems are going to become prevalent in the near
future, this difference in testing efficiency is important, and was used to justify a
new standard dedicated to the problem.
However, it will become obvious that the 1149.6 standard has its shortcomings
as well. For example, while it may enable faster testing of AC couplings than we
could achieve with 1149.4, it will not be quite as thorough. For example, it will not
enable the measuring of analog component values as 1149.4 does. Thus if a circuit
is faulty because of a wrong-valued termination resistor, the 1149.6 standard may
280 8 IEEE 1149.6: Testing Advanced I/O

not detect this9 or if it does, may not give as clear a diagnostic report. In principle,
one could implement both 1149.4 and 1149.6 in an IC and then use the best proper-
ties of both standards.10

8.2 1149.6 Vocabulary and Basics

IEEE Standard 1149.6 has been carefully designed to be fully compatible with the
existing 1149.1 standard. It is built atop the 1149.1 standard so as to maximize our
current investments in that standard. However, to understand 1149.6, it is important
to understand some terminology.11

8.2.1 Advanced I/O

Here is the definition of “Advanced I/O” taken directly from IEEE Standard 1149.6
[IEEE03]:
Advanced I/O: Input/Output (I/O) circuits and protocols that are designed to convey digital
information, the interconnections of which cannot, either by design or by common usage, be
adequately tested with static digital signals such as those provided for in IEEE Std 1149.1. …

This part of the definition clearly includes I/O that is intended to support
AC-coupling. But the standard goes on to include an example:
… For example, such an I/O pin may be self-referenced (i.e., to its own average voltage), or
referenced to another I/O pin, rather than to a fixed voltage.

This leads us to question what the word “referenced” means. The key here is
found in the concept of logic that is not referenced to a fixed voltage. Conventional
logic circuits define a high (“1”) and low (“0”) value as voltages above and below
fixed reference levels. The example lists two types of signaling that do not use fixed
references: signals referenced to their own average value and signals referenced to
another I/O pin. The former case would be the case of a single-ended pin that con-
tains a waveform varying between a lower and higher value, but where there is not

9
The 1149.6 standard may indeed detect a wrong-valued termination if it causes reflections that are
detectable by the 1149.6 test receivers. (See section 8.5.)
10
More likely, one would implement an alternative test technique to validate the resistor values,
such as using in-circuit test measurements on one or two resistors of each type. If they pass, then
the assumption is that all the others must be the correct value as well, since the resistor manufactur-
ers guarantee (credibly) that all the resistors on a reel are the same value.
11
The 1149.6 standard has an extensive glossary that defines over sixty terms. The serious user of
this standard should read it carefully.
8.2 1149.6 Vocabulary and Basics 281

a specified voltage reference other than the average value seen on that pin over
time.12 The latter case includes signals that are compared to analog voltages13
supplied by a circuit designer, or signals that are compared as differential pairs.
The 1149.1 standard is oriented towards testing with fixed logic levels. The
1149.6 standard expands these test capabilities to include testing of interconnections
between I/O pins that do not rely on fixed logic levels.

8.2.2 Signal Pin Categories

The 1149.6 standard divides signal pins into two categories. Consider this definition
of AC pins again taken directly from IEEE Standard 1149.6 [IEEE03]:
AC pins: Advanced I/O pins that require a time-varying (AC) signal to permit testing of their
interconnections. This includes all differential signal pins, and differential or single-ended
signal pins that are expected by design to support AC-coupling.

These pins are something special. When implementing 1149.6, a device designer
is given the liberty of defining AC pins as those that have properties best tested by
the facilities provided by 1149.6, which are also likely to be handled poorly or com-
pletely ignored14 by the 1149.1 standard. All signal pins not so classified (called DC
pins) are expected to obey all the rules in 1149.1. A device designer is expected to
provide 1149.6 capabilities on AC pins so that they will have enhanced test capabili-
ties. Note this category of pins includes all differential pins, and all pins that are
intended to support AC-coupling networks between ICs.15
The first part of the AC pin definition says that they “require a time-varying (AC)
signal to permit testing of their interconnections.” It seems obvious why such a
signal is needed for AC-coupled pins, but why for any differential pins, even those
never intended to be AC-coupled? The answer to this lies in the fact that differential
signals have no fixed references. The 1149.6 standard tackles this problem head on
with AC testing signals16 and something called a “test receiver”. (These topics are
covered in Sect. 8.3.) Note that 1149.6 does not separate digital and analog signals
for the purpose of test, so differential signals are not to be ignored because they
“may be analog”.

12
The average value over time can be determined by a simple low-pass filtered version of the origi-
nal signal.
13
For example, some ICs have one or more receivers that perform low/high comparisons against
the voltage appearing on a reference input pin. This allows them to receive data from a variety of
logic family levels just by adjusting the reference value.
14
The classic example is that of analog pins, which the 1149.1 standard chooses to ignore. It allows
a designer to categorize differential signals as “analog” and therefore not be considered.
15
The 1149.6 standard allows a designer to declare pins as “AC” even when they may support both
AC and DC-coupling. The AC testing facilities still will work properly when used to test
DC-coupled pins. This case can be thought of as AC-coupling with an infinite time constant.
16
Indeed, the 1149.6 Working Group spent considerable time and energy coming to this important
realization.
282 8 IEEE 1149.6: Testing Advanced I/O

8.2.3 Operational Modes

Operational modes can be broadly categorized (as in the 1149.1 standard) as “mis-
sion mode” and “test mode”. In mission mode, a device performs its intended func-
tion. In test mode, it performs as defined by various invasive test instructions,
notably, EXTEST. The 1149.6 standard subdivides the test mode into two additional
modes: AC test mode and DC test mode. The standard gives these definitions
[IEEE2003]:
DC test mode: A test mode that enables traditional Boundary-Scan testing between DC
pins that are DC-coupled.

It is important to remember that traditional Boundary-Scan testing between DC

pins that may be AC-coupled is not supported by the 1149.1 standard due to signal
decay. This problem appears on boards where AC-coupling is being performed
between traditional 1149.1 devices.
AC test mode: A test mode that enables Boundary-Scan testing between AC pins that are
AC-coupled or DC-coupled. AC testing of DC-coupled pins may enable testing that cannot
be supported in DC test Mode due to voltage level incompatibilities.

Here we see that AC test mode will allow testing between DC-coupled devices
that are not voltage compatible for DC test mode. This typically can occur in the
1149.1 domain when a designer chooses to provide, on a differential receiver,
Boundary Register cell support for each leg. This means the designer had to choose
fixed thresholds for voltages that define 0 s and 1 s. If this receiver is then DC-coupled
to a differential driver that produces different voltages for logic values, they may not
be compatible and Boundary-Scan testing will fail to test the interconnections cor-
rectly. Yet, in mission mode, the receiver is comparing the two differential signals
against each other and works perfectly well. Again, this is the problem of how
should designers choose fixed references that will work in all cases. (They can’t.)

8.3 Test facilities for AC Pins

The 1149.6 standard provides new capabilities for AC pins. These capabilities are
broken down into driving and receiving capabilities, and one or both may exist on a
given pin depending on whether that pin is a driving, receiving or bidirectional pin.

8.3.1 Provisions for All Signal Pins

Since the 1149.6 standard is built upon the 1149.1 standard, every AC and DC sig-
nal pin must behave as defined by the 1149.1 standard when any 1149.1-defined
instruction is effective (SAMPLE, PRELOAD, INTEST, EXTEST, CLAMP,
HIGHZ, BYPASS, IDCODE, USERCODE).
8.3 Test facilities for AC Pins 283

The 1149.6 standard defines two new variants of 1149.1 EXTEST, called the AC
EXTEST instruction set, comprised of the new instructions EXTEST_PULSE and
EXTEST_TRAIN. These instructions only affect the behavior of AC pins. Any DC
pins behave exactly as defined by 1149.1 EXTEST when either of these AC
EXTEST instructions are effective. Thus a DC pin acts as though there were only
one EXTEST instruction, but an AC pin can behave as if there were a family of
three such instructions.

8.3.2 Provisions for AC Pin Drivers

AC pins with drivers will produce transition waveforms in response to either the
EXTEST_PULSE or EXTEST_TRAIN instructions. This is important because the
1149.6 standard works by generating and detecting transitions on pins. The 1149.1
standard produces levels. If (say) you load the Boundary Register data cell behind a
driver with a 1, the driver will produce a high state indefinitely, until you later load
the data cell with a 0. If the data cell still contains a 1 when the Update-DR state is
passed any number of subsequent times, the driver does not change state. However,
either of the AC EXTEST instructions will always produce at least two transitions
every time the TAP transitions through the Update-DR portion of the TAP state
diagram. This is done by modifying the Boundary Register cell in a relatively simple
way, shown in Fig. 8.10.
An AC pin driver data cell preserves the high-speed path from the mission cir-
cuitry to the driver as seen in an 1149.1 data cell. In the test path, there is still a
capture and update flip-flop as before, but a new multiplexer is present that selects
either the update flip-flop output, or that same signal modulated via an exclusive-
OR gate with an “AC Test Signal”. (Circled area in Fig. 8.10.) This modulated sig-
nal is selected for output only if an AC EXTEST instruction is loaded. If ordinary
EXTEST is loaded, then everything works as 1149.1 says it should.
An AC pin driver data cell requires two new control signals, AC Mode that
selects EXTEST or AC EXTEST behavior, and the AC Test Signal. The first is sim-
ply decoded from the TAP instruction decoder, being asserted by loading EXTEST_
PULSE or EXTEST_TRAIN. The TAP generates the second as follows in Table 8.2
and Fig. 8.11. The asterisk marks where, if an even number of steps in the Run-Test/
Idle state occur, the driver will already be producing non-inverted data before enter-
ing Select-DR-Scan. If the number is odd, the driver will be producing inverted data.
Thus a last transition may occur in Select-DR-Scan, or in the last step in Run-Test/
Idle. From this table, the reason for the names of the two instructions becomes evi-
dent. EXTEST_PULSE creates a pulse of inverted data on the driver that lasts as
long as the TAP stays in the Run-Test/Idle state. For EXTEST_TRAIN, we see a
“train” of pulses at ½ the TCK frequency while we are in the Run-Test/Idle state.
In either case, the data will be the same as the Boundary Register data cell content
when we exit Select-DR-Scan. If we never enter the Run-Test/Idle state, by skipping
directly to Select-DR-Scan, we will see both of these instructions behaving identi-
cally to the 1149.1 EXTEST definition.
284 8 IEEE 1149.6: Testing Advanced I/O

from mission IEEE Std 1149.1 Data Cell BC_1 to

0 Output
Shift out 1
0

1 C U Mode

Shift in
ShiftDR UpdateDR
ClockDR

from mission AC Pin Output Data Cell to

0 Output
Shift out 1
0
0
1
1 C U Mode
AC Mode
Shift in
ShiftDR UpdateDR
ClockDR
AC Test Signal
BasicDrive

Fig. 8.10 An 1149.1 data cell for a driver, and how 1149.6 adds AC signal modulation

Table 8.2 Actions of an AC pin driver per instruction versus TAP state
Effective instruction
On falling edge of TCK in: EXTEST_PULSE EXTEST_TRAIN
Update-xR Driver drives (new) cell data Driver drives (new) cell data
Run-Test/Idle Driver drives inverted data Driver drives inverted data
Run-Test/Idle Driver holds inverted data Driver drives cell data
Run-Test/Idle Driver holds inverted data Driver drives inverted data
... Driver holds inverted data ...
Select-DR-Scan Driver drives cell data Driver drives cell data

Figure 8.11 shows the waveforms created by AC pin drivers when the AC
EXTEST instructions are effective. Note that the number of TCK cycles spent in the
Run-Test/Idle state determines the width of the inverted data pulse for EXTEST_
PULSE, and the number of transitions between data and inverted data for
EXTEST_TRAIN.
8.3 Test facilities for AC Pins 285

DriveWave

Select-DR-Scan
Run-Test/Idle

Run-Test/Idle

Run-Test/Idle
Update-xR
TCK

AC Pin Drive for

Previous Data Data Data* Data
EXTEST_PULSE

AC Pin Drive for

Previous Data Data Data* Data Data* Data
EXTEST_TRAIN

Fig. 8.11 AC pin driver waveforms created by the EXTEST_PULSE and EXTEST_TRAIN
instructions

Train/Pulse
Train/Pulse Extest_Pulse 0
Extest_Train 1

Run-Test/Idle D Q
AC Test Signal
(distributed to all AC drivers)
TCK
SigGen

Fig. 8.12 A circuit for generating the AC Test Signal

One simple means for generating the AC Test Signal is shown in Fig. 8.12. This
circuit would be centrally located (near the TAP) and the AC Test Signal distributed
to all the AC pin drivers. The Train/Pulse signal would be provided by the TAP
instruction decoder.
The 1149.6 Working Group invented the EXTEST_PULSE instruction with the
idea that it guaranteed that transitions would occur on drivers every time data was
updated onto the driver, provided the trajectory included a trip through Run-Test/
Idle. Later it was decided to add the EXTEST_TRAIN variant, in case a driver tech-
nology was ever encountered that required a “startup” process, meaning it had some
AC performance characteristics that took some time to stabilize. No such case is
known today, but the instruction is ready if needed. It is expected that EXTEST_
PULSE will be the “workhorse” of the 1149.6 test process.
Before leaving this section, it is crucial to emphasize that the mission driver con-
trolled by an AC pin data cell is being used to drive the output pin(s). This driver is
expected to create transitions at its full native edge speed into whatever the board
286 8 IEEE 1149.6: Testing Advanced I/O

loading is.17 Thus, while the frequency of transitions is governed by the TCK rate and
testing algorithms and is likely to be much lower than data frequencies seen in
mission mode, the edge speed will be the same as seen during mission performance.

8.3.3 AC/DC Selection Cells

AC pin drivers may be enabled or disabled in exactly the same was as defined in
1149.1, with output control cells (see Sect. 1.3.4) that may be present to enable or
disable the driver itself. The 1149.6 standard introduces an additional (but optional)
AC/DC selection cell that can be used to cause an AC pin or a set of AC pins to
revert to EXTEST behavior when either EXTEST_PULSE or EXTEST_TRAIN is
loaded. Such cells are part of the Boundary Register, and look like “internal” cells
to applications (for standards 1149.1, 1149.4 and 1532) that are unaware of their
true purpose. Indeed, they are coded as Internal cells in BSDL. (See Sect. 8.6.) The
AC pin output data cell originally depicted in Fig. 8.10 is modified in Fig. 8.13 to
be controlled by an AC/DC selection cell. The modifications are circled.

from mission AC Pin Output Data Cell

to
0 Output
Shift out 1
0
0
1
1 C U Mode

ShiftDR UpdateDR
ClockDR AC Test Signal
AC Mode

AC/DC Selection Cell, C U

"1" selects AC Behavior,
"0" overrides with DC
behavior.
Shift in ACSelect

Fig. 8.13 AC pin data cell, modified for control by an AC/DC selection cell

17
There is a key difference here compared to the 1149.4 standard. Digital data driven by 1149.4
switches may not have enough current capacity into external loading to create valid voltage levels.
The 1149.6 standard makes use of the native driver which is expected to drive such loads.
8.3 Test facilities for AC Pins 287

AC/DC selection cells were provided by the 1149.6 Working Group to handle a
case that was thought to be relatively unlikely, but still possible. This case occurs in
testing when, while performing EXTEST (or an AC EXTEST instruction) you
might want to hold a given signal at a constant 1 or 0 for the duration of the test.
Since, when an AC EXTEST instruction is effective, AC pins will not be held con-
stant18 it was felt that some means of overriding the AC performance of selected AC
pins was needed, if a device designer wants to provide for it. An AC/DC selection
cell can provide this override for one or more AC pin drivers. Each AC pin may be
controlled by exactly zero or one AC/DC selection cells. In custom devices, it is
most likely that data paths will be provided with AC pins but not for control signals
that emanate from the device (they would treated as DC pins). It is the control sig-
nals of a device that are most likely candidates for static control during a test, in
order to condition some external circuitry for testing purposes. However, for pro-
grammable devices, it is possible that AC/DC selection cells may have utility,
because it is not always known beforehand which signal pins19 will end up being AC
or DC pins. To summarize, an AC/DC selection cell controls the AC performance of
an AC pin driver, but does not affect whether that driver is enabled.

8.3.4 Provisions for AC Pin Receivers

This subsection gives the broad parameters of AC input pin implementation. The
salient point is that they are provided with a “Test Receiver” that is used to condition
the input waveform into something a standard 1149.1 receiver cell can process. An
example of this is shown in Fig. 8.14. A detailed explanation of test receivers is
given in Sect. 8.5.
Test receivers have four important characteristics. They are:
1. single ended, they do not use another pin for reference in differential structures.
2. provided one per pin, so a differential signal pair would have one for each pin.
(See Fig. 8.15.)
3. edge sensitive when EXTEST_PULSE or EXTEST_TRAIN are in effect. They
respond to signal edges, not levels. As such, they do not have defined reference
voltages for low and high signals.
4. transparent (or translational) to DC levels when EXTEST is in effect.

18
DC pins can be held constant since they perceive all three flavors of EXTEST to be equivalent to
EXTEST.
19
At this writing, programmable devices appear to have pins grouped into functional categories.
For example, they may have subsets of I/O pins with special differential drive capabilities pro-
vided. These would be natural candidates for AC pin capability. Other more ordinary pins would
be candidates to remain DC pins, and would likely serve for control functions. Thus programmable
devices may have few or no AC/DC selection cells offered.
288 8 IEEE 1149.6: Testing Advanced I/O

Mission

C U
Test
Receiver
Mode
AC Mode
RX (Control and Observe)
InputRec

Fig. 8.14 A single-ended AC input pin equipped with a test receiver

Test receivers process waveforms that are either clearly digital (as in Fig. 8.8 on
page 295), but will also process analog waveforms20 as in Fig. 8.9 on page 296.
They produce a digital output that is compatible with a standard Boundary Register
cell constructed from the logic circuitry available in the interior of the device.
Differential signal input pairs are each monitored separately (Fig. 8.15) and each
test receiver output is captured in its own Boundary Register cell. The device
designer may opt to provide the mission differential receiver with a Boundary
Register cell as well. This cell records what the differential receiver recovers from
the input waveform pair. The additional information provided by this data cell is
actually minimal, but the cell may be useful for INTEST implementation (as shown).
The reason the additional information may be of little use is due to the inherent
redundancy of differential signaling. Some defects that can occur may not be
detected at the output of the mission receiver. This is the reason why features 1 and
2 above were necessary. Single-ended, self-referenced performance of test receivers
is crucial for defect detection and unambiguous diagnosis.

8.4 The Defect Model for 1149.6

The 1149.6 standard gives a precise list of defects that the Working Group consid-
ered as “must detect” defects. The list was generated from a model that is shown in
Fig. 8.16. The actual list is shown in Table 8.3. Note that defects that are equivalent
by symmetry are omitted. The word “unreferenced” in the table refers to termina-
tion by a single resistor (typically) across the receiver inputs as in Fig. 8.16.
Unreferenced termination allows communication between legs in defect situations.
“Referenced” termination is done (typically) with two resistors from each leg

20
The test receiver may be connected to an input buffer output rather than directly to the input pin
if the isolation is required. However, the buffer should be analog amplifier (e.g., unity gain) so it
doesn’t perturb the analog waveform.
8.4 The Defect Model for 1149.6 289

Test C
Receiver

AC Mode Optional,
from 1149.1

Mission

C U

Mode

Test
C
Receiver

AC Mode
RX Control and Observe
DiffRec

Fig. 8.15 A differential AC pin pair equipped with test receivers, and an optional 1149.1 control
and observe data cell monitoring the mission receiver

C1
1 1
1 2 1
R
2 1 2 2 2

C2
TX1 RX1

1 1

TX2 RX2
Defects

Fig. 8.16 Circuit used to define defects addressed by the 1149.6 standard
290 8 IEEE 1149.6: Testing Advanced I/O

Table 8.3 Defects that the 1149.6 standard is designed to detect

Defect site Possible defect causes Possible AC test syndromes at receiver
TX1 pin 1 open Open solder joint, Pin-1-follows-pin-2 null, possibly with detectable
broken bond wire reflections on both pins (unreferenced), or pin 1
float (referenced)
C1 pin 2 open Open solder joint, Pin-1-follows-pin-2 null (unreferenced), or pin 1
missing capacitor float (referenced)
RX1 pin 1 open Open solder joint, Pin 1 float
broken bond wire
TX1 pin 1 short Pin-to-pin short, Pin 1 float, possibly with detectable reflections if
to VDD solder splash unreferenced
TX1 pin 1 short Pin-to-pin short, Pin 1 stuck, possibly with detectable reflections if
to Ground solder splash unreferenced
TX1 pins 1, 2 Pin-to-pin short, Both pins stuck, transients at switching times
shorted together solder splash suppressed by voltage and time hysteresis
C1 pins 1, 2 Solder splash, internal Pin 1 passes EXTEST, which would normally
shorted together short in C1 ‘fail’ due to DC blocking of capacitor
C1 pin 1 short to Pin-to-pin short, Pin-2-follows-pin-1 null
C2 pin 2 solder splash
RX1 pin 1 short Pin-to-pin short, Pin 1 stuck detected by EXTEST. Pin 2 common-
to VDD solder splash mode shifted, and may also appear to be stuck in
EXTEST (unreferenced)
RX1 pin 1 short Pin-to-pin short, Pin 1 float, stuck detected by EXTEST. Pin 2
to Ground solder splash common-mode shifted, and may also appear to be
stuck in EXTEST (Unreferenced)
RX1 pins 1, 2 Pin-to-pin short, Both pins float, (transients at switching times
shorted solder splash suppressed by voltage and time hysteresis.)
TX1 pin1 short to Pin-to-pin short, There are a large number of effects of device-to-
TX2 pin 1 solder splash device shorts. See text
RX1 pin1 short Pin-to-pin short, There are a large number of effects of device-to-
to RX2 pin 1 solder splash device shorts. See text
R pin 1 open Open solder joint, Much longer time constant on both pins
missing resistor (unreferenced) or just pin 1 (referenced), which
may ‘pass’ EXTEST

to a reference voltage bias source. This source is assumed to be of low enough

impedance so that the two legs are independent. The term “null” means that both
legs appear to have very nearly the same voltage on them. The term “float” means a
receiver leg does not receive any signal and it state is determined by biasing or
leakage. The information in Table 8.3 was developed after studying hundreds of
analog simulations.21
Some defects deserve some discussion. Notice (in Table 8.3) that a shorted
capacitor may not be detected by an AC EXTEST instruction since the capacitor is
expected to pass the AC test signal, and it may also be successfully passed by a

21
Many thanks to Carl Barnhart and IBM for performing these simulations!
8.5 The 1149.6 Test Receiver 291

shorted capacitor as well. The 1149.6 Working Group specifically identified this
type of defect as one that should be tested for with ordinary EXTEST. In such a
case, the defect would allow data to pass from the driver to the test receiver, when
the capacitor would normally prevent such a transfer due to it blocking22 DC levels.
Thus a passing test would see constant data in the test receiver, while the “correct”
signature of the driver would indicate a failing test. (Some have called this a test that
“fails” when it passes.)
Two other defects have the effect of shorting a nearby data signal to either one
leg of the driver, or to one leg of the receiver. This can result in a large number of
possible syndromes, determined by the logic families of the two devices. For exam-
ple, if two shorted drivers are fighting, the result may be that the test receiver sees
no change if the differential driver is “strong” enough to “win” the fight. Of course,
any Boundary-Scan receiver on the other signal may fail as a result. In other cases,
depending on circuit layout, the two signals may produce odd-looking waveforms
due to complex reflections enabled by the shorted signal layouts. These can have the
effect of being interpreted as extra data edges when viewed by the test receiver in
its edge-detecting mode.
Finally, if the differential driver’s two legs are shorted together, this can produce
transients on the signals at the time of signal switching. These will usually be
of small amplitude and duration. The test receiver is constructed to ignore such
“noise” events.
Advanced I/O, by virtue of being more than just simple wires, has the potential
for defects that were not imagined when Boundary-Scan was first envisioned. It is
also the case that some of these defects can escape detection by ordinary means.
As an example, consider the differential pair shown in Fig. 8.17. Here an open cir-
cuit, due to an open solder joint or even a completely missing capacitor, is not
detectable at the output of the mission receiver. However the mission performance
will be degraded, probably showing up as an elevated bit error rate (BER) in this
channel. Because the differential nature of this channel has effectively been con-
verted to single-ended by this defect, its performance in the face of noise or extreme
environmental conditions will be degraded. Imagine the difficulty in trying to relate
a poor bit error rate result to such a mundane defect as an open solder joint.

8.5 The 1149.6 Test Receiver

The test receiver is the heart of the 1149.6 standard. It has the ability to listen to an
input pin and respond to one of two types of test signal. These would be either a DC
level when the EXTEST instruction is being executed, or an AC signal when
EXTEST_PULSE or EXTEST_TRAIN is being executed.

22
Here it is assumed the time constant of the coupling is significantly shorter than the time between
updating and capturing data. This can be assured by spending extra time in the Run-Test/Idle state
if needed.
292 8 IEEE 1149.6: Testing Advanced I/O

Open Undetected

Vref

Equivalent
Circuit

Vref

Fig. 8.17 An open circuit defect may be undetectable depending on termination and biasing

8.5.1 Test Receiver Definitions

The building blocks of a test receiver are a comparator possessing voltage and time
hysteresis, a memory and a reference system with switchable characteristics for AC
and DC testing. The 1149.6-2003 standard [IEEE03] gives these definitions, to
establish its working vocabulary:
Comparator: An amplifier with two inputs labeled positive and negative, typi-
cally with very high input impedance. The amplifier usually has very high gain
and produces an output signal that is the amplified difference of the positive and
negative input signals. For all but the smallest differences, the output will be Vmax
or Vmin, which are the most positive and most negative voltages the amplifier can
produce on its output. A comparator can be used as a differential receiver.
A comparator can be used to determine if an input signal is logically above or
below a reference voltage.
High-pass filter: An electrical network that passes higher frequencies and atten-
uates lower frequencies. DC current is blocked.
8.5 The 1149.6 Test Receiver 293

Hysteresis: From magnetics: lagging in the values of resulting magnetization in

a magnetic material (such as iron) subjected to a changing magnetizing force. In
this document, hysteresis refers to the memory of an input state to an amplifier
or buffer after that state is removed but before a different input state is applied.
Typically there is a hysteresis threshold that defines the difference between “no
input” and “input.” As applied to electronics, a digital output circuit such as a
comparator where the output switches to one output state when the input is above
one level and switches to the opposite output state when the input is below a
lower level, and the output does not switch at any intermediate level. Example:
a buffer produces a high output when a voltage above 0.5 V is applied, produces
a low output when a voltage below 0.3 V is applied, and does not change its
output for voltages between 0.3 and 0.5 V.
Low-pass filter: An electrical network that passes lower frequencies, including
DC levels, and attenuates higher frequencies.
Self-referenced comparison: The comparison of a signal with a delayed, aver-
aged version of the same signal, used to detect signal transitions. This process
does not need a static reference voltage to find a transition in a signal.
Time constant: Typically the product of resistance and capacitance of an RC
network (e.g., a high-pass filter) measured in seconds. One time constant is the
time for a capacitor to discharge 63 % of its voltage through a resistor. In
AC-coupled systems, the termination resistance combined with the coupling
capacitor forms a high-pass filter.
Transition: A voltage transition occurs when a signal traverses a specified volt-
age range in a specified time in either direction.
The next section gives a precise view of what test data transitions look like, for
both DC and AC coupled I/O.

8.5.2 Transitions

A driver will create a voltage transition23 that ultimately is received. If the receiving
device (and its test receiver) is DC-coupled, the transition will be seen directly. If
the receiving device is AC-coupled, a high-pass filtered waveform will be seen.

23
The 1149.6 standard notes that some drivers actually do not create voltages, but rather steer the
direction of current flow. Such drivers must be terminated with a resistor that converts the current
flow into a voltage. Receivers in all cases are voltage devices.
294 8 IEEE 1149.6: Testing Advanced I/O

8.5.2.1 DC-Coupled Response

Figure 8.18 gives a view of a DC voltage waveform with rising and falling transitions.
The change in voltage in a period of time is defined as ΔV in time TTrans. Note that there
may be a voltage offset between the lower voltage and a reference such as ground.
Transitions are defined without use of a reference. Thus ΔV is equal to V2–V1.

8.5.2.2 AC-Coupled Response

Figure 8.19 shows a received waveform typical of an AC-coupled system. The orig-
inal driver waveform (such as in Fig. 8.18) is high-pass filtered into fast transitions
(the original signal transition edges) followed by “invalid transitions” caused by the
decay of the signal after the transition.

TTrans TTrans

V2
Voltage

Valid Falling
Valid Rising Input Swing
Transition
Transition V= V2-V1
V1
Arbitrary Offset

t1 t2 Time t3 t4
DCTran

Fig. 8.18 DC-coupled transitions seen at the test receiver input

TTrans

VT+V2-V1 TTrans
Invalid Falling
Transition
Voltage

V=(VT+V2-V1)-VT=V2-V1
VT
Valid Rising V=VT-(VT-V2+V1)=V2-V1
Transition

Valid Falling
VT-V2+V1 Invalid Rising
Transition
Transition

t1 t2 Time t3 t4 ACTran

Fig. 8.19 AC-coupled transitions seen at the test receiver input

8.5 The 1149.6 Test Receiver 295

The voltage VT is a bias termination voltage defined at the receiver, which may
be significantly different from any voltage level defined at the driver. Indeed this is
one reason for AC-coupling, to perform signal level shifting. As before with DC
waveforms, there is a valid transition defined as ΔV in time TTrans. Note that ΔV is
still equal to V2–V1 when the math is completed.
The most important realization needed to understand the AC performance of the
test receiver is the difference between a valid and invalid transition. The magnitude
of ΔV and TTrans will form a basis for noise rejection in test receivers, so that they
do not respond to “little wiggles” imposed on the signal waveform by Ground-
Bounce, crosstalk or other noise. But most importantly, the difference between a
signal edge and its decay are used in the design of the test receiver. In essence, there
is a difference in slope. A valid edge has a steep slope (high slew rate) and a signal
decay waveform has much shallower slope (lower slew rate). The decay rate is a
function of the coupling time constant of the system. Board and system designers
are in control of this parameter.24 Typically the characteristic impedance of the
board (often around 50–75 Ω) constrains half the time constant equation, so the
designers choose a capacitance value that will easily propagate the expected edges.
They often choose larger capacitances (e.g., 100 nF) which give relatively long time
constants. For example, 50Ω times 10−7 Farads is 5 μs. Thus a test receiver will be
expected to differentiate a signal edge (typically a nanosecond or less) from a decay
waveform with substantially longer timing.

8.5.3 Test Receiver DC Response

When the EXTEST instruction is in effect, the test receiver is expected to respond
to the voltage levels seen at the input pin. A circuit to do this is shown in Fig. 8.20.
This circuit certainly seems a bit complex for what it does, but the reason for this
will become clear later.
The DC portion of the test receiver is composed of a memory element (a clocked
“D” flip-flop with asynchronous set and clear inputs25). This flip-flop is set or cleared
by two simple comparators. Each comparator has one of its inputs listening to the
input pin, but not directly as there is an offset voltage VHyst imposed. This estab-
lishes “voltage hysteresis”. The other legs of the comparators are connected to a
common reference voltage VBias which determines the center voltage of a transition.

24
That is, until the capacitive coupling is integrated into the receiver itself. In this environment, the
IC designer will choose values for R and C. The value of R is no longer constrained to be equal to
the characteristic impedance, but will be decades larger. This in turn means the capacitor can be
decades smaller. ICs are now on the drawing boards with the AC-coupling built into the receivers.
Values of R and C are in the 20 kΩ range with a capacitance of 5 pF (0.1 μs). These are easily
integrated, and in differential receivers, they can be matched rather well which is important in
higher performance systems.
25
The set and clear inputs override the clock if asserted when a clock edge arrives.
296 8 IEEE 1149.6: Testing Advanced I/O

VHyst

A B C
VBias Init Set
D Q
Data
Device Input Init Clk Ck

Clear

VHyst

DCReceiver

Fig. 8.20 A test receiver circuit for DC (EXTEST) waveforms

The value of this voltage should be the center point of what the designer deems is the
optimal input waveform for the performance of the mission receiver. (If this is a dif-
ferential receiver, then this would be the optimal common-mode voltage of the receiver.)
When the voltage on the input pin is lower than VBias -VHyst, then the lower comparator
asserts the clear input of the flip-flop. If the input pin voltage is higher than VBias + VHyst,
then the upper comparator asserts the set input of the flip-flop. When any other voltage
is present, neither set nor clear is asserted, and the flip-flop retains its current state.
The test receiver memory flip-flop also has a clock and data input. These are used
to set an initial state of the test receiver. This state will be retained in the flip-flop
until the time a valid voltage state (high or low) is seen at the input pin. If for
example, there was an open circuit on the input pin, then there would never be a
valid voltage seen on the input. Thus the initial state of the test receiver would later
be captured by the associated Boundary Register data cell.
This offers an interesting improvement over the behavior of input data cells as
specified by 1149.1. With 1149.1, an unconnected input data cell will capture some
default value or perhaps even random data. With 1149.6 and its initialized test
receiver memory, you can define what will be received if there is an open. (See
Sect. 8.5.7 for more information about initializing this “hysteretic memory”.) When
multiple Sequential Test Vectors (see Sect. 3.2.2) are used, each one can define a
particular initial state.
The timing of how the test receiver works during EXTEST is shown in Fig. 8.21.
As always, the upstream driver will produce data changes (if any) at the Update-DR
state on the falling edge of TCK. This data is presented to the test receiver either
directly (when DC-coupled to the driver) or in a high-pass filtered version (when
AC-coupled26) as shown. When AC-coupled, the waveform will decay away. Later,

26
Remember from Sect. 8.4 that we want to use EXTEST on AC-coupled networks to determine if
a capacitor is shorted.
8.5 The 1149.6 Test Receiver 297

Update Point Capture-DR Point

TCK

(TAP State) Update-xR Select-DR Capture-DR

DC AC
Signal
Data N-1 Data N
Pin A
EXTEST Capture Window
Init Clk

DC AC
Set or Clear
DC
Test
Receiver
Output C
AC
(Init) DCRecWave

Fig. 8.21 Timing of signals within the test receiver during EXTEST

at the falling edge of TCK in the Capture-DR state, which is ½ TCK cycle before
we will capture data, the test receiver is initialized with data. If the input pin still
sees a signal with a valid logic level, that signal will override the initial data and be
recorded in the test receiver memory. If not, the initialized data will be retained. At
the rising edge of TCK in the Capture-DR state, the result of the test receiver’s
operations will be captured in the Boundary Register input data cell.
Note that noise is likely to be generated by outputs transitioning at the falling
edge of TCK in the Update-DR state, but that any noise event that was captured in
the memory flip-flop before the falling edge of TCK in the Capture-DR state will be
erased by loading the initial state at that time. This is one way that noise is controlled
by this standard. The hysteresis voltages prevent small signal noise from toggling
the flip-flop, and the 1149.6 standard gives rules for the test receiver design that limit
the bandwidth of its response, also to reduce noise sensitivity. Since the test receiver
is not in the high-speed mission pathway and deals with test signals only, these steps
to eliminate noise sensitivity will not hamper mission performance.
It is possible, in differential signaling, that a DC-coupled test receiver has a VBias
setting that is not compatible with the voltages produced by the upstream driver.
This can happen when the driver and receiver are constructed in different logic
families. Differentially (in mission mode) they work fine. But when EXTEST is
298 8 IEEE 1149.6: Testing Advanced I/O

loaded, the single-ended test receiver may construe the voltage levels coming from
the driver to be stuck high or low. This is not a problem, because the test receivers
can be used in AC test mode even when they are DC-coupled. Indeed, this is a major
strength of 1149.6. See the next section.

8.5.4 Test Receiver AC Response

When either the EXTEST_PULSE or EXTEST_TRAIN instruction are in effect,

the test receiver is expected to respond to valid signal transitions seen at the input
pin. A simplified model of a circuit to do this is shown in Fig. 8.22.
This model shows a hysteretic comparator that has both inputs listening to the
input pin, but one is directly connected while the other is receiving a low-pass filtered
version of the input signal. This is a “self-referenced” comparison scheme as the com-
parator is not using any fixed voltage reference. Instead, the comparator is comparing
the instantaneous signal value against the recent average history of the signal. The
hysteresis only allows the comparator to change state if the difference is significant.
This circuit is an “edge detector”, that is, it responds to valid transitions. Examples of
this are shown in Fig. 8.23 for both DC and AC-coupled input waveforms.
Consider first the edge-detector performance for a DC-coupled input signal as
seen in the upper half of Fig. 8.23. The positive input of the comparator sees an
immediately rising edge, but the negative leg sees a much slower, smoother rise.
The comparator has both voltage hysteresis and delay which prevent it from
responding for some period of time, after which it produces a rising edge and holds
a high level. Similarly, on the falling edge of the input signal, the comparator’s posi-
tive input sees the change first, but the negative leg sees a slower falling transition.
The output tracks the input after the same delay interval.
Next consider the edge-detector performance for an AC-coupled input signal
as seen in the lower half of Fig. 8.23. Again, the positive input of the comparator
sees an immediately rising edge which, after reaching the peak, decays away.

Fig. 8.22 Edge-detecting

test receiver model for AC A
EXTEST instructions

Input Pin
C
RF B

CF
Low Pass
Filter ACRec1
8.5 The 1149.6 Test Receiver 299

Hysteresis Delay
Hysteresis Offset
A Input

DC Coupled Case Reference

B
Filter
Delay
C Output
Receiver Response

Hysteresis Delay
Hysteresis Offset
A Input

B Reference
AC Coupled Case
Filter
(small time constant) Delay
C Output

Receiver Response
ACRecWave1

Fig. 8.23 Performance of the edge detector for AC and DC-coupled signals

However the negative leg sees a filtered version of this spike that never moves
much above zero. The comparator, after the hysteresis delay, responds and holds its
output high. Thus is has “integrated” the edge into a level. Similarly, on the falling
signal edge, the test receiver sees the falling edge and tracks it by sending its output
low. The test receiver output has reconstructed a level waveform from the edge
information it gets from the high-pass filter formed by AC-coupling. Note in
both AC and DC cases, the waveform on the test receiver output matches that
originally created by the upstream driver, provided that driver was producing
valid transitions.
A possible implementation for the model in Fig. 8.22 is shown in Fig. 8.24. Just
as for the DC receiver (Fig. 8.20) it uses two comparators, each with hysteresis volt-
age source VHyst used to suppress response to small signal noise and that also define
a “valid” transition. The top comparator detects positive (valid) transitions in the
input waveform. The bottom comparator detects the falling transitions. As before,
their outputs are used to set or clear a D-type flip-flop. The output of the flip-flop is
a reproduction of the original waveform driven (either DC or AC-coupled) to the
test receiver.
300 8 IEEE 1149.6: Testing Advanced I/O

VHyst

A RF B C
Set
Init Data D Q
DC
CF Init Clk Ck
or AC
Clear

VHyst

ACRec2

Fig. 8.24 AC integrating test receiver

Why doesn’t this circuit respond to invalid transitions (see Fig. 8.19) such as the
high-pass filter signal decay? This happens because the high-pass time constant is
much larger than the low-pass time constant of the AC test receiver. Thus the slope
of a valid transition is much steeper than the slope of the decay. A low-slope signal
will not produce a voltage difference at the comparator that exceeds VHyst. The value
of TTrans is a design parameter used in the selection27 of these two time constants.
The D-type flip-flop is provided (again) with a clock and data input. These are
(again) used to set its initial state. This ability can be used during testing to differ-
entiate an open, floating input pin from other defects. (See Sect. 8.5.7.)
The waveforms in Fig. 8.25 show the behavior of the test receiver output when
EXTEST_PULSE or EXTEST_TRAIN are in effect. Notice the initialization of the
hysteretic memory is earlier than we saw for DC level detection, at the falling edge
of TCK in the Exit1-DR (or Exit2-DR) state.
This initializes the memory before the upstream driver creates its first transition
(the falling edge of TCK in the Update-DR state). While in the Run-Test/Idle state,
the driver will create at least two more transitions. If any update noise occurs that
disrupts the state of the test receiver memory, these additional transitions will clear
the disrupted state.28

27
Parameters TTrans, ΔVMin, and VHyst are used via rules that give maximum design flexibility.
28
Indeed, the Working Group referred to the driver as “clearing its throat” in the earlier transitions
so the receiver could “hear what it said” more clearly at the last transition.
8.5 The 1149.6 Test Receiver 301

ACRecW ave2

TCK

Exit1-DR Update-DR Run-Test/Idle Select-DR Capture-DR

DC coupled AC coupled
Driver Data N -1 Data N Data* Data N

Init Data Data* Data or Initial State

Test Receiver
Detect Edges (If Any) Test Receiver Edge-
Initial State
Detector Output Captured
Test Receiver Edge-Detection Initialization Point in Boundary Register Cell

Fig. 8.25 Timing of signals within the test receiver during an AC EXTEST instruction

8.5.5 Guaranteed AC-Coupling

If the high-pass coupling is built into the receiving IC, then the test receiver is guar-
anteed to be AC coupled. (When it is on-chip, it should appear between the pin29 and
the test receiver.) In some cases the IC designer knows that even though the cou-
pling will be off-chip, it will always be there, for example, guaranteed by system
specifications. The mission receiver will then have some form of bias network that
establishes a reference voltage for signals. Thus, the test receiver can also be guar-
anteed that same reference voltage.
When a test receiver is guaranteed to be AC coupled to the driving signal, a device
designer is allowed to omit the low-pass filter seen in the previous section, since
there is a signal reference that cannot be disturbed by the driver. When this condition
is assured, the designer can revert to what appears to be a DC test receiver structure
as seen in Fig. 8.20 (page 314). The rules of the standard will dictate the minimum
time constant of the high-pass filter. A valid driver transition will arrive unattenuated
by the high-pass filter, and the decay waveform will have a much longer time con-
stant than a valid edge. After the hysteresis delay of the receiver is satisfied (deter-
mined by bandwidth limit of the test receiver) the signal will still be sufficiently
non-decayed to produce either a set or clear pulse to the memory flip-flop.

29
Any input protection circuitry (clamp diodes and series resistors) should be connected to the pin
side of the high-pass filter.
302 8 IEEE 1149.6: Testing Advanced I/O

Analog switch controlled by AC Mode

VHyst

A RF AC B
Set C
Init Data D Q
DC
CF
Init Clk Ck

Clear
VBias

VHyst

ACDCRec

Fig. 8.26 An integrated AC/DC test receiver implementation

8.5.6 An Integrated AC/DC Test Receiver

As you probably suspect by now, the DC and AC performances of the test receiver
(see Figs. 8.20 and 8.24) can be integrated into one implementation controlled by a
signal (“AC Mode”, from the TAP) that indicates whether DC (level) performance is
requested, or AC (edge detecting) performance is needed. This is shown in Fig. 8.26.
As always with an IEEE standard, the pictures of possible implementations do not
rule out other possibilities. The figures in this chapter are suggestions only. IC design-
ers are welcome to innovate their own interpretation of the rules, recommendations
and permissions, as long as no rules are violated. Also note that serious designers
must always consult the latest revision of the standard itself for the precise set of rules.

8.5.7 Initializing and Capturing Hysteretic Memory

The previous sections have several times alluded to initializing the hysteretic mem-
ory of the test receiver. In Fig. 8.26 this amounts to setting a value on the “Init Data”
signal, and producing an edge on “Init Clk” to load that value at the appropriate
time. A circuit30 to generate “Init Clk” is shown in Fig. 8.27.
Testing software now has a new job, that of managing the initial values of test
receiver data. One simple algorithm for doing this is to initialize the memory to the
opposite value of what the driver is (or will be) driving.

30
This circuit is not susceptible to a race on the TCK signal since only one of the EXTEST-type
instructions can ever be active.
8.5 The 1149.6 Test Receiver 303

Init Clk
(common to all
Capture-DR
test receivers)
EXTEST

TCK
EXTEST_TRAIN
EXTEST_PULSE
May be located
Exit1-DR
near TAP controller
Exit2-DR
InitClk

Fig. 8.27 Generation of “Init Clk” for test receiver memory

Another perhaps subtle point is that when first entering AC test mode, that is, on
the falling edge of TCK in the Update-IR TAP controller state, the test receiver is
switched from listening31 to mission data32 to now listening to test data. We have no
control over whether there is a meaningful transition in the data at this juncture.
Thus if the upstream driver is not performing an AC EXTEST instruction (it may be
a simple 1149.1 driver) or if the Run-Test/Idle state is not entered to “clear the
throat” of the AC driver, the first Sequential Test Vector’s results may not be cap-
tured correctly. Because of this, testing tools should ignore the results of that first
STV and repeat it before capturing it for examination.
Initial memory data for the test receiver is delivered by shifting it in through the
Boundary Register to the input data cell associated with the test receiver. This cell
later captures the data that is collected by the test receiver on the rising edge of TCK
in the Capture-DR state. The data used for initializing the test receiver is shifted into
the capture cell either by the PRELOAD or an EXTEST-type instruction.
A circuit to initialize test receiver memory from the associated Boundary Register
cell is shown in Fig. 8.28. Here, a typical BC_1-type cell is used for shifting and
capturing data. The Update flip-flop is only required for single-ended input pins if
control-and-observe capability is needed (e.g., for INTEST support). Initial data
is shifted into the Capture flip-flop. At the appropriate time, the “Init Clk” signal
(see Fig. 8.27) copies this data into the test receiver hysteretic memory. When the
rising edge of TCK in the Capture-DR state occurs, the result of the test receiver’s
work, as recorded in its hysteretic memory, is captured in the Capture flip-flop of the
Boundary Register cell where it can be shifted out for examination. As we saw
before in Sect. 3.1.2, while data is being shifted out, new test data and test receiver
initial states can be shifted in for the next Sequential Test Vector.

31
Some designers will opt to “shut down” the test receiver when it is not in use, so it may be “wak-
ing up” in some unknown state. The problem is the same.
32
It is conceivable that at the time of switching, the mission driver was not producing any data, i.e.,
it was disabled. This again means we cannot be assured of a valid transition being seen at the test
receiver at that time.
304 8 IEEE 1149.6: Testing Advanced I/O

Optional, Required for Observe-and-Control

Capabilty on Single-Ended Inputs Only

Shift Out 1

0
Shift In

Boundary 1
Register Capture Update
Cell ShiftDR

ClockDR UpdateDR

VHyst

Pad RF
AC
DC Set
Receiver

Hyst
Test

CF Init Data
Init Clk Mem
Clear
VT
VHyst

RecBReg

Fig. 8.28 Integrating a test receiver with its associated Boundary Register cell

8.6 BSDL Extensions for 1149.6

An 1149.6 device is quite similar to an ordinary 1149.1 device because the Working
Group took pains to carefully build the new standard atop the foundation standard.
This is evident in a BSDL description for an 1149.6 device. Essentially, some new
instructions (EXTEST_PULSE and EXTEST_TRAIN) have to be documented, and
some new Boundary Register cells have to be identified. The existence of test
receivers has to be documented along with some details of their construction, and a
mapping of test receivers to their monitoring Boundary Register cells.
The additional information needed to describe an 1149.6 device is contained in a
BSDL extension (see Sect. 2.6.6). BSDL extensions are used to describe new attri-
butes beyond the 1149.1 BSDL definition. The 1149.6 standard codifies an official
extension for its descriptive purposes within a VHDL package (see Sect. 2.6) called
8.6 BSDL Extensions for 1149.6 305

STD_1149_6_2003. This package is reproduced in Sect. 8.6.2. It is expected to

reside in a “read-only” area of a test system file space, most likely co-resident with
the 1149.1 package STD_1149_1_2001. Remember that the intent of BSDL exten-
sions is to encode information in such a way that application software that doesn’t
know about the use of the extension is still able to read the BSDL file and perform
activities with the 1149.1 implementation.
The 1149.6 extension defines new attributes. The syntax of these attributes is
given in Appendix A, Sect. A.6.

8.6.1 Boundary Registers Cells for 1149.6

The 1149.6 standard pre-defines some Boundary Register cells. Two of these are
used as AC/DC selection cells and are shown in Fig. 8.29. The rest are data cells.
AC/DC selection cells are coded in the Boundary Register description (see Sect.
2.3.13) as “Internal” cells. These two cells, AC_SelX and AC_SelU are similar, dif-
fering in what they capture on the rising edge of TCK in the Capture-DR state. The
AC_SelX cell captures an unknown value (actually, the state of its “Shift In” line
which is not known). The AC_SelU cell captures the state of its Update flip-flop. This
can improve the testability of that portion of logic for production test33 purposes.

Shift out
AC/DC Select

C U
Shift in
AC_SelX AC/DC
ClockDR UpdateDR Selection Cell

Shift out
0 AC/DC Select

1 C U

Shift In
AC_SelU AC/DC
ShiftDR
UpdateDR Selection Cell
ClockDR ACDCSel

Fig. 8.29 Two AC/DC selection cell design possibilities

33
If the IC is built with its own internal scan capability as allowed by 1149.1 (see Sect 1.7) then this
additional circuitry may be unnecessary.
306 8 IEEE 1149.6: Testing Advanced I/O

Table 8.4 Mode settings for Figs. 8.30, 8.31, 8.32, 8.33, 8.34, and 8.35
Mode 1 Mode 2 Mode 3 Mode 4 Mode 5 AC mode
EXTEST (1149.1) 1 0 1 1 1 0
AC EXTEST (1149.6) 1 0 1 1 1 1
PRELOAD 0 0 1 X 0 X
SAMPLE 0 0 1 0 0 X
INTEST 0 1 0 0 1 0
RUNBIST X X 0 X 1 0
CLAMP 1 X 1 X 1 0
HIGHZ X X 0 X X X

Mission Input Mission

0 Output
Shift out 1
0
0
1
1 C U Mode 5
AC Mode
Shift in
ShiftDR
UpdateDR AC_1 Output Data Cell
ClockDR
AC Test Signal AC_1

Fig. 8.30 AC output pin data cell AC_1

The following figures give output data cell designs for AC output pins. Table 8.4
gives the values of various mode lines used in the drawings, versus effective instruc-
tion. The BSDL cell descriptions of these designs is given in Sect. 8.6.2.
The AC_1 cell in Fig. 8.30 is an adaptation of the highly general BC_1 cell (see
Sect. 2.6.3, page 95). This cell supports the INTEST instruction. Note that the BC_1
cell can be used in contexts other than supplying data to output drivers (input cells,
control cells) but AC_1 cell only supports the Output2 and Output3 contexts.
The AC_2 cell is shown in Fig. 8.31 is an adaptation of the BC_2 cell shown in
Sect. 2.6.3, page 96. Note that the BC_2 cell can be used in contexts other than sup-
plying data to output drivers (input cells, control cells) but that the AC_2 cell only
supports the Output2 and Output3 contexts. This cell does not support INTEST.
The AC_7 cell shown in Fig. 8.32 (shown with its companion BC_2 control cell)
is an adaptation of the bi-directional BC_7 cell seen in Sect. 2.6.3, page 101. This
cell supports the INTEST instruction.
Data cell AC_8, shown in Fig. 8.33 is an adaptation of the bi-directional BC_8
cell from Sect. 2.6.4 on page 104. This cell does not support INTEST.
 0 AC_2 Output Data Cell Mission Output
Mission
Input
1
Shift out
Mode 5 0
0
U C 1
1
Shift in
ShiftDR
AC Mode UpdateDR
AC Test Signal ClockDR
AC_2

Fig. 8.31 AC output pin data cell AC_2

AC_7
Mode 3
0 Output/Mission
Output
Control
1
1149.1 Control Cell BC_2

Mode 1 Shift out

0

1 C U Pad
Shift in
ShiftDR
ClockDR UpdateDR

0
Output
Data 1

Mode 1

Bidirectional Data Cell AC_7

1
Shift out
0
0
0 1
1 C U
Shift in AC Mode
ShiftDR
ClockDR UpdateDR AC Test Signal
1
Input
Data 0

Mode 2

Fig. 8.32 AC Bidirectional pin data cell AC_7

308 8 IEEE 1149.6: Testing Advanced I/O

Output Data 0

1
Bidirectional Data Pad

Cell AC_8
Mode 1
Shift out
0
0
1
1 C U
Shift in AC Mode
Input ShiftDR
Data ClockDR UpdateDR AC Test Signal
AC_8

Fig. 8.33 AC Bidirectional pin data cell AC_8

AC_9 Self-Monitoring
Output
Mission Output Output Data Cell
0 Pad
Shift out 1
0 0
0
1 1
1 C U Mode 5
Mode 4
Shift in AC Mode
ShiftDR UpdateDR AC Test Signal
ClockDR
AC_9

Fig. 8.34 Self-monitoring output data cell AC_9

The AC_9 cell shown in Fig. 8.34 is an adaptation of the self-monitoring BC_9
cell from Sect. 2.6.4 on page 105. This cell supports the INTEST instruction.
The AC_10 cell shown in Fig. 8.35 is an adaptation of the self-monitoring BC_10
cell from Sect. 2.6.4, page 106. This cell (inside the dotted line) monitors the state
of its pad driver. This cell does not support INTEST.
8.6 BSDL Extensions for 1149.6 309

AC_10 Self-Monitoring
Mission Data
0 Output Data Cell
1
Pad

Mode 5 Shift out

0
0
1
1 C U
AC Mode
Shift in
ShiftDR UpdateDR AC Test Signal
ClockDR
AC_10

Fig. 8.35 AC output pin data cell AC_10

8.6.2 STD_1149_6_2003

The content of STD_1149_6_2003 is given below. A “use” statement should appear

in the BSDL description for an 1149.6 device directly following the standard use
statement (see Sects. 2.3.3 and 2.3.4, and the example in Sect. 8.6.3). That portion
of the BSDL description would look like this:

…
use STD_1149_1_2001.all; -- Standard ‘use’ statement
use STD_1149_6_2003.all; -- BSDL Extension for AIO
…

The 1149.6 package defines the extension attributes, and also gives the cell
descriptions for AIO Boundary Register cells (see Sect. 8.6.1).
Package STD_1149_6_2003 is -- Attribute definitions for AIO
use STD_1149_1_2001.all; -- Refer to BSDL definitions

constant AC_SelX : Cell_Info; -- AC/DC selection X

constant AC_SelU : Cell_Info; -- AC/DC selection U
constant AC_1 : Cell_Info; -- Output cell derived from BC_1
constant AC_2 : Cell_Info; -- Output cell derived from BC_2
constant AC_7 : Cell_Info; -- Output cell derived from BC_7
constant AC_8 : Cell_Info; -- Output cell derived from BC_8
constant AC_9 : Cell_Info; -- Output cell derived from BC_9
constant AC_10 : Cell_Info; -- Output cell derived from BC_10
310 8 IEEE 1149.6: Testing Advanced I/O

attribute AIO_Component_Conformance: BSDL_Extension;

attribute AIO_EXTEST_Pulse_Execution: BSDL_Extension;
attribute AIO_EXTEST_Train_Execution: BSDL_Extension;
attribute AIO_Pin_Behavior: BSDL_Extension;
end STD_1149_6_2003;

Package Body STD_1149_6_2003 is

use STD_1149_1_2001.all; -- Refer to BSDL definitions

constant AC_SelX : Cell_Info:= -- Captures ‘X’, unknown data

((INTERNAL, SAMPLE, X),
(INTERNAL, INTEST, X),
(INTERNAL, EXTEST, X)); -- EXTEST,EXTEST_PULSE,EXTEST_TRAIN

constant AC_SelU : Cell_Info:= -- Captures ‘UPD’, Update FF

((INTERNAL, SAMPLE, UPD),
(INTERNAL, INTEST, UPD),
(INTERNAL, EXTEST, UPD));--EXTEST,EXTEST_PULSE,EXTEST_TRAIN

constant AC_1 : Cell_Info:= -- Output cell derived from BC_1

((OUTPUT2, SAMPLE, PI),
(OUTPUT2, EXTEST, PI), -- EXTEST,EXTEST_PULSE,EXTEST_TRAIN
(OUTPUT2, INTEST, PI),
(OUTPUT3, SAMPLE, PI),
(OUTPUT3, EXTEST, PI), -- EXTEST,EXTEST_PULSE,EXTEST_TRAIN
(OUTPUT3, INTEST, PI));

constant AC_2 : Cell_Info:= -- Output cell derived from BC_2

((OUTPUT2, SAMPLE, UPD), -- No support for INTEST
(OUTPUT2, EXTEST, UPD), -- EXTEST,EXTEST_PULSE,EXTEST_TRAIN
(OUTPUT3, SAMPLE, UPD),
(OUTPUT3, EXTEST, UPD));-- EXTEST,EXTEST_PULSE,EXTEST_TRAIN

constant AC_7 : Cell_Info := -- BIDIR cell derived from BC_7

((BIDIR_IN, SAMPLE, PI),
(BIDIR_IN, EXTEST, PI),-- EXTEST,EXTEST_PULSE,EXTEST_TRAIN
(BIDIR_IN, INTEST, UPD),
(BIDIR_OUT, SAMPLE, PI),
(BIDIR_OUT, EXTEST, PO),-- EXTEST,EXTEST_PULSE,EXTEST_TRAIN
(BIDIR_OUT, INTEST, PI));

constant AC_8 : Cell_Info := -- BIDIR cell derived from BC_8

((BIDIR_IN, SAMPLE, PI),-- No support for INTEST
(BIDIR_IN, EXTEST, PI),-- EXTEST,EXTEST_PULSE,EXTEST_TRAIN
(BIDIR_OUT, SAMPLE, PO),
(BIDIR_OUT, EXTEST, PO));--EXTEST,EXTEST_PULSE,EXTEST_TRAIN

constant AC_9 : Cell_Info :=

-- Self-monitoring Output cell derived from BC_9
((OUTPUT2, SAMPLE, PI),
(OUTPUT2, EXTEST, PO), -- EXTEST,EXTEST_PULSE,EXTEST_TRAIN
8.6 BSDL Extensions for 1149.6 311

(OUTPUT2, INTEST, PI),

(OUTPUT3, SAMPLE, PI),
(OUTPUT3, EXTEST, PO), -- EXTEST,EXTEST_PULSE,EXTEST_TRAIN
(OUTPUT3, INTEST, PI));

constant AC_10 : Cell_Info :=

-- Self-monitoring Output cell derived from BC_10
((OUTPUT2, SAMPLE, PO), -- No support for INTEST
(OUTPUT2, EXTEST, PO), -- EXTEST,EXTEST_PULSE,EXTEST_TRAIN
(OUTPUT3, SAMPLE, PO),
(OUTPUT3, EXTEST, PO)); -- EXTEST,EXTEST_PULSE,EXTEST_TRAIN

end STD_1149_6_2003;

8.6.3 Example 1149.6 Device and BSDL

This section shows a hypothetical device containing a number of Advanced I/O pins
that would be good candidates for the application of the 1149.6 standard. Then, a
BSDL description is given to illustrate the 1149.6 extensions to BSDL.
The example device, before adding the 1149.1 and 1149.6 circuitry is shown in
Fig. 8.36. The designer has marked some of the pins as “DC” or “AC” depending

AC
AC A E
AC

AC
B
AC F DC
Mission
AC
C
AC AC
G
AC
DC D
H

Dot6Ex1

Fig. 8.36 An example device with several Advanced I/O pins

312 8 IEEE 1149.6: Testing Advanced I/O

on whether they would benefit from the extra test resources provided by 1149.6.
This determination is made on a pin-by-pin basis.
Receiver A could be AC-coupled by external components, so its pin is chosen for
AC treatment. Receiver B is guaranteed to be AC-coupled by virtue that the
AC-coupling is actually integrated on chip. (Note the receiver has internal biasing
and termination resistances to establish its operating point that are not shown. The
time constant of this coupling is designed to be 2 microseconds.) Receiver C is a
standard 50-Ω terminated differential receiver. It could be AC or DC coupled
depending on the application, so the designer chooses the AC designation for its
pins. Receiver D is known to be an “ordinary” logic input so it is considered a “DC”
input and will be given 1149.1 resources only.
Continuing on the output side of the device, driver E is differential and could be
connected to other ICs at the board level that have 1149.6 capability, so it is a good
idea to have the driver support the EXTEST_PULSE and EXTEST_TRAIN instruc-
tions. However, the designer elects to have an AC/DC selection cell (see Sect. 8.3.3)
available to control this capability, just in case. Driver F is “ordinary” so it is treated
as a DC pin. Finally, driver G and receiver H form a terminated, differential, bidi-
rectional pin pair. Driver G can be disabled from the mission logic. These are given
AC status. The next exercise is to add both 1149.1 (the TAP and Boundary Register)
and various 1149.6 resources (mainly, test receivers and AC boundary cells). This
results in the implementation shown in Fig. 8.37.
The BSDL coding for this implementation appears next. Comments follow it,
indexed to line numbers that appear in the far right side of the lines.

entity AC_DEVICE is -- line numbers appear on the right --1

-- Generic Parameter --2

generic (PHYSICAL_PIN_MAP : string := "DIP32"); --3

-- Logical Port Description --4

port ( --5
TDI : in bit; TMS : in bit; --6
TCK : in bit; TDO : out bit; --7
A : in bit; --8
B_Diff : in bit_vector(0 to 1); --9
C_Diff : in bit_vector(0 to 1); --10
D : in bit; --11
E_Diff : buffer bit_vector(0 to 1); --12
F : buffer bit; --13
G_Diff : inout bit_vector(0 to 1); --14
GND : linkage bit_vector(1 TO 10); --15
VDD : linkage bit_vector(1 TO 7) ); --16

-- Use Statements
use STD_1149_1_2001.all; --17
use STD_1149_6_2003.all; --18
8.6 BSDL Extensions for 1149.6 313

8 7 P8
P7 A C U C U E
P9

TR C 9 6
C U

TR C 10
5
P6 11
C U F P10
B C U
P5 4
C U
TR 12
C
Mission 3 P11
TR C U G
C 13 P12
P4 14
C C U 2 C TR
P3

TR C 15 1
U C H

16
P2 D C U 0 C TR

P1 TAP P13
TDI TDO

TCK TMS
P15 P14 Dot6Ex2

Fig. 8.37 Example device with 1149.1 and 1149.6 inserted

-- Component Conformance Statement

attribute COMPONENT_CONFORMANCE of AC_DEVICE : entity is --19
"STD_1149_1_2001"; --20

-- Device Package Pin Mappings

attribute PIN_MAP of AC_DEVICE : entity is PHYSICAL_PIN_MAP;
constant DIP32:PIN_MAP_STRING := --22
" TDI : P1, TMS : P14," & --23
" TCK : P15, TDO : P13," & --24
" A : P7," & --25
" B_Diff : (P6, P5)," & --26
" C_Diff : (P4, P3)," & --27
" D : P2," & --28
" E_Diff : (P8, P9)," & --29
314 8 IEEE 1149.6: Testing Advanced I/O

" F : P10," & --30

" G_Diff : (P11, P12)," & --31
" GND : (P16, P17, P18, P19, P20, " & --32
" P28, P29, P30, P31, P32)," & --33
" VDD : (P21, P22, P23, P24, P25, " & --34
" P26, P27)"; --35

-- Grouped Port Identification

attribute PORT_GROUPING of AC_DEVICE: entity is --36
"DIFFERENTIAL_VOLTAGE (" & --37
"(B_Diff(0), B_Diff(1)), " & --38
"(C_Diff(0), C_Diff(1)), " & --39
"(E_Diff(0), E_Diff(1)), " & --40
"(G_Diff(0), G_Diff(1)))"; --41

-- Scan Port Identification

attribute TAP_SCAN_CLOCK of TCK : signal is (50.0e6, BOTH);
attribute TAP_SCAN_IN of TDI : signal is true; --43
attribute TAP_SCAN_MODE of TMS : signal is true; --44
attribute TAP_SCAN_OUT of TDO : signal is true; --45

-- Instruction Register Description

attribute INSTRUCTION_LENGTH of AC_DEVICE: entity is 4; --46
attribute INSTRUCTION_OPCODE of AC_DEVICE: entity is --47
-- IEEE Std 1149.1, BYPASS gets all unused codes
"EXTEST (0001)," & --48
"SAMPLE (0010)," & --49
"PRELOAD (0011)," & --50
"IDCODE (1000)," & --51
"CLAMP (0100)," & --52
"HIGHZ (0101)," & --53
-- IEEE Std 1149.6
"EXTEST_PULSE (0110)," & --54
"EXTEST_TRAIN (0111)"; --55
attribute INSTRUCTION_CAPTURE of AC_DEVICE: entity is "0001";

-- Optional Register Description

attribute IDCODE_REGISTER of AC_DEVICE : entity is --57
"01110000110100001111000011110001"; --58

-- Register Access Description

attribute REGISTER_ACCESS of AC_DEVICE: entity is --59
"BOUNDARY (EXTEST_PULSE, EXTEST_TRAIN)"; --60

-- Boundary-Scan Register Description

attribute BOUNDARY_LENGTH of AC_DEVICE : entity is 17; --61
attribute BOUNDARY_REGISTER of AC_DEVICE : entity is --62
"16 (BC_1, D, INPUT, X)," & --63
"15 (BC_4, C_DIFF(1), OBSERVE_ONLY, 0)," & --64
8.6 BSDL Extensions for 1149.6 315

"14 (BC_1, C_DIFF(0), INPUT, X)," & --65

"13 (BC_4, C_DIFF(0), OBSERVE_ONLY, 0)," & --66
"12 (BC_4, B_DIFF(1), OBSERVE_ONLY, 0)," & --67
"11 (BC_1, B_DIFF(0), INPUT, X)," & --68
"10 (BC_4, B_DIFF(0), OBSERVE_ONLY, 0)," & --69
" 9 (BC_4, A, OBSERVE_ONLY, 0)," & --70
" 8 (BC_1, A, INPUT, X)," & --71
" 7 (AC_1, E_DIFF(0), OUTPUT2, X)," & --72
" 6 (AC_SELU, *, INTERNAL, 0)," & --73
" 5 (BC_1, F, OUTPUT2, X)," & --74
" 4 (BC_1, *, CONTROL, 1)," & --75
" 3 (AC_1, G_DIFF(0), OUTPUT3, X, 4, 1, Z),"&--76
" 2 (BC_4, G_DIFF(0), OBSERVE_ONLY, 0)," & --77
" 1 (BC_4, G_DIFF(0), INPUT, X)," & --78
" 0 (BC_4, G_DIFF(1), OBSERVE_ONLY, 0)"; --79

-- Advanced I/O Description

attribute AIO_COMPONENT_CONFORMANCE of AC_DEVICE : entity is
"STD_1149_6_2003"; --81

attribute AIO_EXTEST_Pulse_Execution of --82

AC_DEVICE:entity is "Wait_Duration 10.0e-6"; --83

attribute AIO_Pin_Behavior of AC_DEVICE : entity is --84

"A[9] : LP_time=5.0e-9 HP_time=15.0e-9;" & --85
"B_DIFF(0)[10] : HP_time=2.0e-6 On_Chip;" & --86
"C_DIFF(0)[13] : LP_time=5.0e-9 HP_time=15.0e-9;" & --87
"G_DIFF(0)[2] : LP_time=5.0e-9 HP_time=15.0e-9;" & --88
"E_DIFF(0) : AC_Select = 6"; --89

end AC_DEVICE; --90

Lines 1–16: standard BSDL header and port description.

Line 17: “use” statement that identifies the device as conforming to 1149.1.
Line 18: “use” statement that identifies the device as conforming to 1149.6.
Lines 19–20: identifies the level of 1149.1 standard for this device.
Lines 22–35: standard pin mapping attribute.
Lines 36–41: port grouping to identify the four differential pairs on this device.
Lines 42–45: normal TAP port identification.
Lines 46–56: TAP instruction register length, capture and opcode enumeration. Note in lines
54-55 are the two 1149.6 instructions that must appear.
Lines 57–58: an IDCODE definition for this device.
Lines 59–60: the 1149.6 instructions are associated with the Boundary Register.
Lines 61–79: description of the Boundary Register cells. (More comments below.)
Lines 80–81: identifies the level of the 1149.6 standard used.
Lines 82–83: (optional) defines the pulse width requirement for EXTEST_PULSE.
Lines 84–89: provides addition 1149.6 parametric information for the AC pins.
(More comments follow.)
316 8 IEEE 1149.6: Testing Advanced I/O

Next, look at lines 61–79 in more detail (as well as Fig. 8.37). There are four
differential structures that are described. In lines 64–66, differential inputs P3 and
P4 (to buffer C) are described. There are two observe_only cells that monitor test
receivers on the positive and negative pins. There is also a control-and-observe
(input) cell that monitors the result of the differential input buffer. This cell is
optional by 1149.1, and not required at all by 1149.6.34 Similarly, lines 67-69 docu-
ment the differential pins P6 and P5 for differential input buffer B. Special note
must be made for lines 64 and 67 (and later, 79). These are instances where the
negative leg of a differential pair shows up in the Boundary Register description.
Normally, with 1149.1, only the positive leg is associated with a cell, but 1149.1
does allow observe_only cells to monitor any signal pin, even the negative legs35 of
differential pairs. The 1149.6 standard uses this method to document the test receiv-
ers that monitor negative differential legs.
Lines 70 and 71 show an observe_only monitor for the test receiver on this
single-ended input. The control-and-observe (input) cell again is not necessary, but
would allow support for INTEST. Line 63 shows standard 1149.1 support for pin
P2, which is a “DC” input pin. Similarly, line 74 shows standard 1149.1 support for
the DC output pin of buffer F.
Cells 6 and 7 (lines 73 and 72) provide for the AC behavior of differential driver
E. Cell 7 provides that data and cell 6 is an AC/DC selection cell (see Sect. 8.3.3)
that can override the AC behavior of the driver if so desired (by loading a zero in
cell 7). Cell 7 is documented as an “internal” cell, since its real purpose is unknown
to 1149.1. Soon we will see how this purpose is communicated.
Lines 75–79 show how the differential, bidirectional pins P11 and P12 are han-
dled. Cell 4 is a control cell that can disable driver G, allowing external signals to be
read by buffer H. Cell 3 provides data to driver G. Cells 2 and 0 monitor test receiv-
ers on the pins. Cell 1 (again, optional) monitors the state of input buffer H.
Now that all the cells have been documented, we need a final attribute to identify
those cells that have purposes unique to 1149.6. This code runs from lines 84 to 89,
where AC pin behavior is finally documented. Lines 85-89 identify five AC signals,
A, B_Diff(0), C_Diff(0), G_Diff(0) and E_Diff(0). Note that these include only the
AC single-ended signal (A) and the positive legs, only, of the AC differential pairs.
It is mandatory that if the positive leg of a differential pair is an AC pin, then its
negative leg must be provisioned with an identical capability, and it need not be
documented. As such, the characteristics of test receivers on positive legs are “inher-
ited” by their companion negative legs.

34
This device does not declare support for INTEST. The control-and-observe cell would be needed
if it did.
35
This clarification has been published as an addendum to the 2001 draft of 1149.1.
8.6 BSDL Extensions for 1149.6 317

Line 85 documents the test receiver associated with single-ended input buffer
A. This test receiver has a low-pass filter (see Sect. 8.5.4 and Fig. 8.20) inside it with
a time constant of 5 ns, and this is indicated with the “LP_time” phrase. The “HP_
time” phrase indicates the test receiver is designed to work with a high-pass cou-
pling time constant of 15 ns or more. This coupling, if it existed, would be provided
by board components. One last detail: the “[9]” field directly following the signal
name “A” indicates that cell 9 is the cell that monitors the test receiver for this input.
Note cell 8 also monitors the input, but at the output of the input buffer. This brack-
eted number allows software to resolve this ambiguity, when it exists, and it can be
omitted when there is no potential confusion. In like fashion, lines 87 and 88 also
document the low-pass and high-pass characteristics of input buffers C and H.
Line 86 documents the test receiver(s) associated with differential input buffer
B. There is no low-pass filter time constant documented here, since this buffer is
AC-coupled by capacitors integrated into the IC itself, thus guaranteeing it to be
AC-coupled. (See discussion in Sect. 8.5.4.) The time constant of the AC-coupling
is documented with the HP_time phrase, again. Note the modifier “On_Chip”
appears to let tools know the coupling is integrated into the receiver itself.
Line 89 documents differential output driver E as being an AC pin pair. The
“AC_Select” phrase documents there is an AC/DC selection cell (cell 6) associated
with this particular driver. (See Sect. 8.3.3.) If this selection cell were not there, then
the entire phrase, starting with the “:” up to but not including the semicolon could
be omitted. Again, the documentation only mentions the positive leg and the nega-
tive leg can be figured out from the information supplied earlier (lines 36-41) in the
port grouping statement.
The advance I/O information in lines 85–89 can be written more compactly
if so desired, by noting that three of the test receivers have identical properties.
The BSDL below shows an equivalent expression:

attribute AIO_Pin_Behavior of AC_DEVICE : entity is

"A[9], C_DIFF(0)[13], G_DIFF(0)[2] : LP_time=5.0e-9 " &
" HP_time=15.0e-9;" &
"B_DIFF(0)[10] : HP_time=2.0e-6 On_Chip;" &
"E_DIFF(0) : AC_Select = 6";

Finally, lines 82–83 deserve some explanation. The time between driver edges
while an AC test is being performed is required to be at least three times the longest
value of “LP_time”36 for any test receiver in the device. However, the standard
allows this time to be extended if desired by the device designer for some reason,
and this optional attribute is the mechanism for expressing this. This should be rare.

36
In this example, the minimum time between edges would be 15 ns. Edges are produced by falling
edges of TCK in the Run-Test/Idle TAP state, implying a TCK period of 15 ns (66.6 MHz) which
is higher than practical systems run, and also higher than TCK maximum clock frequencies of
many devices.
318 8 IEEE 1149.6: Testing Advanced I/O

There is a similar attribute for the EXTEST_TRAIN instruction, that allows a

designer to express a minimum number of transitions that should be produced (the
“length of the train”) while in the Run-Test/Idle TAP state. The Working Group
expects that the use of EXTEST_TRAIN and the expression of this minimum will
be rare events.
A complete summary of 1149.1 BSDL extension syntax appears in Appendix A
Sect. A.6.

8.7 Design for 1149.6 Testability

We have little experience on which to build a Design for Test lore for the 1149.6
standard since the standard and this edition are both appearing in 2003. However,
the 1149.6 Working Group does have a few ideas to offer.

8.7.1 Integrated Circuit Level DFT

The 1149.6 standard depends, in part, on examining signals for edges, and reacting
to those edges. This allows its great strength of not needing to compare signals
against fixed references. This is invaluable for detecting defects in differential chan-
nels. Therefore it would be highly useful to equip all differential channels with the
1149.6 feature set, even if no AC-coupling is anticipated.
New varieties of Programmable Logic Devices are appearing that have some I/O
ports dedicated to various differential signaling uses, the nature of which may be
programmable. These would be obvious candidates for the AC pin designation.
• DFT-36: Consider equipping all differential I/O ports with IEEE 1149.6
resources.
The 1149.6 standard was originally inspired as a solution to AC-coupled signals.
The art of AC coupling may be anticipated when designing an IC because the
designer has global knowledge of the system the IC will inhabit. However, if there
is even a small chance that AC-coupling will be used with an IC currently being
designed, then go ahead and implement 1149.6 on those pins. This will likely
include data ports. Control signals (interrupt requests, clocks, etc.) will probably
never be AC-coupled.
• DFT-37: Consider equipping all I/O ports that could be AC-coupled with
IEEE 1149.6 resources.
Finally, in an application where AC-coupling of connections is expected, the
coupling can be integrated into the receiving IC, as well as the line termination and
signal level biasing. Having these components inside the IC reduces the number of
8.7 Design for 1149.6 Testability 319

board level components needed for that same application. This reduces the number
of things that can be defective during manufacturing. This also guarantees
AC-coupling, which enables a simpler implementation (see Sect. 8.5.5).
• DFT-38: Consider integrating AC-coupling, termination and biasing into
receiving ICs.

8.7.2 Board-Level DFT

It is at the board level and beyond where the 1149.6 investment really pays off.
Board designers do need to consider several issues when implementing 1149.6 on
boards.
First, board designers should ask for 1149.6 resources in ICs even when
AC-coupling is not anticipated, on differential channels. Differential signaling can
mask important manufacturing defects that can pass ordinary Boundary-Scan tests,
but fail in the performance domain.
• DFT-39: Use 1149.6 in all differential board and system signal pathways.
If a board designer must make use of catalog devices that (someday soon) have
1149.6 resources, care must be taken that they will be interoperable. This amounts
to finding out what the design parameters of ΔV, and TTrans were in the design of the
test receivers (see Sect. 8.5.2). The slew rate of the upstream driver should exceed
these values for proper operation of 1149.6, after proper de-rating is done to account
for signal attenuation along the path. (This de-rating is important in very fast signal
paths only.) If a driver produces edges that have too little voltage swing or are to
slow, the downstream test receiver may not see transitions, essentially leaving it
blind. It is highly likely that for devices designed to interoperate in mission mode
will also operate in 1149.6 test mode. But it pays to be careful.
• DFT-40: Assure that 1149.6 drivers and receivers have compatible defini-
tions of a “valid” transition.
Board-mounted AC-coupling capacitors will need to be checked for shorts that
restore a DC path. This one defect mode is not detectable, generally, by 1149.6.
However, the 1149.1 EXTEST instruction can be used. In this case, a good capacitor
will block 1149.1 signals from getting to a receiver while a shorted capacitor will
allow the data to arrive. Thus, an 1149.1 tests for capacitor shorts can be set up with
a data stream (Sequential Test Vectors) being generated by a driver, but the receiver
is expecting to see a constant value (1 or 0 depending on what its default is). If the
constant value is not seen, a short may be present. This amounts to checking to see
in the tester system you will use is able to perform this test.
• DFT-41: When board-level coupling capacitors are present, use the 1149.1
EXTEST instruction to find shorted capacitors.
320 8 IEEE 1149.6: Testing Advanced I/O

8.8 Summary

This single chapter describing the 1149.6 standard is obviously an overview when
you consider the scope of the Advanced Digital Network standard. Serious imple-
menters will need to study the standard itself in detail. The 1149.6 standard is aimed
at the growing trend towards “advanced I/O” of IC devices. It may well be expanded
in the future to handle new features unknown today in the I/O arena.
At this writing, there is one prototype IC that has been designed37 that sheds some
light on design issues with 1149.6. This IC was a process test case for several tech-
nologies, including 3.125 GHz SERDES data transmission. Eight such channels
(both drive and receive) were equipped with 1149.6 capabilities to see how well they
worked, both fault free and in the presence of defects. To summarize here, all impor-
tant defects (listed in Table 8.3) were detectable. The silicon overhead of the test
receiver was in the 1–2% range (130 nm processing). Since this IC had some of the
channels implemented with the AC-coupling on-chip, the size of the coupling was
also noted to be quite reasonable, on par with other capacitors routinely integrated
on-chip. Newer information [Eklo05] is now available on the state of the industry.
See [Fout06] for work on automating the inclusion of 1149.6 technology into ICs.

37
This IC was designed and fabricated by a team at the Semiconductor Products Group of Agilent
Technologies (now Avago Inc).
Chapter 9
IEEE 1532: In-System Configuration

IEEE Standard 1532 [IEEE02]1 addresses “In-System Configuration of

Programmable Devices”. The term “In-System2 configuration” (ISC) means the
devices can be loaded with programming data after they have been mounted on
a board. Indeed, even non-volatile devices most likely are blank at the time of
board placement, since this can eliminate potentially damaging handling steps for
programming, and pre-placement inventory.
The development of this standard began with an exploratory meeting held in
April of 1996, in Loveland Colorado. There, a group of 19 Programmable Logic
Device (PLD) vendors3 and users discussed the possibility of standardizing the pro-
gramming process for PLDs. Subsequent meetings were held regularly, typically in
San Jose, and agreement was developed for basing the programming process upon
IEEE Standard 1149.1. At first, many of the PLD vendors simply wanted to adopt the
TAP Controller only, and leave the rest of 1149.1 standard as an option to implement.
However, the users of these devices were quite adamant that all of 1149.1 be used as
the foundation. This was because they recognized the difficulty of testing newly
manufactured boards that had quantities of blank devices to test. To them it was
entirely unacceptable to add a TAP, but no test facilities. Today, the very first rule in
the 1532 standard is “Thou shalt be compliant with 1149.1” in all ways. A very large
percentage of PLDs are now available with Boundary-Scan, because of 1532.

1
Some drawings and definitions in this Chapter come from IEEE Std. 1532. Copyright 2003
IEEE. All rights reserved.
2
Sometimes synonymously referred to as “In-Situ” configuration.
3
In principle, this standard could be adopted by FLASH RAM vendors as a programming process.
However, like most RAM vendors, they have resisted adoption of 1149.1 for economic reasons
they feel are justified in the marketplace.

© Springer International Publishing Switzerland 2016 321

K.P. Parker, The Boundary-Scan Handbook, DOI 10.1007/978-3-319-01174-5_9
322 9 IEEE 1532: In-System Configuration

This group adopted this statement of its mission [IEEE02]:

To define, document and promote the use of a standardized process and methodology for
implementing programming capabilities within programmable integrated circuit devices,
utilizing (and compatible with) the IEEE Std 1149.1 communication protocol. This stan-
dard would allow the programming of one or more compliant devices concurrently, while
mounted on a board or embedded in a system, known as “In-System Configuration.”
Concurrent programming may often result in significant programming time efficiencies.
The In-System feature would address the need to configure or reconfigure, read back, verify
or erase programmable devices after they have been installed by a manufacturing process.
This eliminates handling damage and the need for manufacturing steps and inventory man-
agement related to preprogrammed devices.

The group asked for the support of the IEEE Standard 1149.1 Working Group,
which ultimately urged that this effort become its own standard within the Test
Technology Technical Committee of the IEEE Computer Society in July of 1998.
Since this standard does not provide any new testing capabilities, but instead
addresses programming issues, it was not given an 1149-type name.
IEEE Standard 1532 [IEEE02] was developed in two phases. The initially
approved version of this standard described the necessary hardware elements for
compliance. By making this available earlier, the development of compliant silicon
was accelerated. This subsequent revision completed the standard by formalizing
the ISC algorithm description within the infrastructure of BSDL. This last element
was required to enable the proliferation of software tools for supporting compliant
devices. A recent edition of the standard appeared in 2002 [IEEE02], which added
some new nuances to the programming algorithms. As ever, you should keep cur-
rent with standards releases.
The 1532 Working Group stated a number of objectives for its efforts.
• To provide 1149.1-compliant test capabilities in programmable devices.
• To allow concurrent programming of multiple devices, regardless of their vendor
or vintage.
• To provide board and system designers with a consistent and predictable behav-
ior for devices that are unprogrammed, and those being programmed.
• To provide the users of 1532-compliant devices with an existing set of tools and
processes for handling In-System programming needs.4
• To provide toolmakers with a sufficiently large marketplace to encourage the
development of tools to service it.
• To provide new entrants into the PLD marketplace with an existing, readily
available set of tools for programming their devices.
• To foster innovation in the programming process for product features, field
applications, remote programming and ideas not yet realized.

4
This by itself is a huge contribution if you are familiar with the past. Then, each new device, even
from the same vendor, may have had a unique programming process, often best described as a
“kludge”. There was little incentive to develop tools for these devices.
9.1 IEEE 1532 Vocabulary and Basics 323

This chapter will focus on the features of the 1532 standard that are important to
people charged with testing boards and systems containing PLDs, as well as related
Design for Test issues. The basics of programming will be discussed briefly. The
nuances of programming will be omitted altogether. See [Jaco03] for a complete
treatment of 1532 programming.

9.1 IEEE 1532 Vocabulary and Basics

IEEE Standard 1532 has been carefully designed to be fully compatible with the
existing 1149.1 standard. The 1149.1 standard principally addresses digital I/O pins
of devices. The 1532 standard does this too, but introduces a categorization of I/O
pins into two types, fixed system pins and ISC system pins.

9.1.1 Fixed System Pins

In the 1532 standard, a fixed system pin is a system pin with an I/O function that is
independent of configuration information programmed into the device, and has not
been designated as an In-System Configurable system pin by the device designer.
So, two things can define a fixed system pin. First, its nature is not a function of
configuration. Second, even if it is “fixed” by being independent of configuration, it
has not been declared to be “not fixed” (ISC) by the device designer (see the next
section).
By “nature”, it is meant that no parameter of the pin is a function of device
configuration,5 be it the logic definition of the pin, or analog specifications such as
voltage levels, drive strength, slew rate, etc.

9.1.2 ISC System Pins

In the 1532 standard, an ISC system pin is a system pin that is defined by configura-
tion information programmed into the device, or has been designated as an ISC
system pin by the device designer. See example in Fig. 9.1.

5
Be careful of a subtlety here. By “configuration” we mean the downloading of a block of memory
data that defines the function of at least a part of the PLD. There are some non-PLD devices that do
manage some I/O parameters, typically driver strength, via some algorithm we don’t consider here.
324 9 IEEE 1532: In-System Configuration

ISC Pins Fixed Pins

Fixed Pins
Programmable Micro-Controller
ISC Pins

Logic Core Core

TAP

ISC Pins Fixed Pins,

Designated as ISC FixISC

Fig. 9.1 A device may contain both fixed and configurable functionality

The designer has some leeway in the definition of pins. Any pin that has a
programmable nature must be designated as ISC. However, the designer may add
some fixed pins to the list if desired. The reason is that before, during, and after the
configuration process, the two pin types have somewhat different behaviors.
The behavior of ISC and fixed pins is tied to the concept of “system modal
states” that are covered next. See also Sect. 9.1.4.

9.1.3 System Modal States

IEEE Standard 1149.1 defines two modes, “system” mode and “test” mode, as
shown in Fig. 9.2. The device powers up in system mode and may transition to or
from test mode6 depending on the 1149.1 instruction that is loaded on the falling
edge of TCK in the Update-IR state.

6
The transition from test mode back to system mode can be inhibited by the “Test Mode
Persistence” feature added to IEEE 1149.1 by 2013 release. See Sect. 11.3.4.1 in Part 2 of
this book.
9.1 IEEE 1532 Vocabulary and Basics 325

Any non-test Any test instruction

instruction loaded loaded
Any test Instruction loaded

System Test
Mode Any non-test Mode
instruction loaded

Test-Logic-Reset
Power
Up
1149Mode

Fig. 9.2 Operational modes defined by 1149.1, and their transitions

Devices that conform to the 1532 standard have a system mode that is
subdivided into four “system modal states”. This reflects the fact that programmable
devices, at various times in their operational life:
1. May be in an “Unprogrammed” mode with blank logic configuration memory,
or they …
2. May be in “ISC Accessed” mode for accessing logic configuration memory for
writing, reading or erasing, or they …
3. May be in “ISC Complete” mode when accessing configuration memory is
complete, but before entering the operational mode, or they …
4. May be in “Operational” mode, containing fully operational system logic.
Again, all four of these system modal states are part of the “system” mode as
defined by 1149.1.
The 1532 standard defines a set of instructions (called “ISC” instructions) that,
along with other factors, govern the system modal state a device is in, and the transi-
tions between them. The two most important instructions are ISC_ENABLE and
ISC_DISABLE. The ISC_ENABLE instruction sets up a device for programming
activities such as writing, reading or erasing program memory. The ISC_DISABLE
instruction takes a device out of a programmable mode. Quite a few other ISC
instructions are defined by the 1532 standard, but they only work when they are
used between the execution of ISC_ENABLE and ISC_DISABLE. Nearly all ISC
instructions require that some specified number of TCK cycles be executed while in
the Run-Test/Idle state. These TCK cycles drive internal state machines that conduct
programming activities. For example, the ISC_ENABLE instruction may turn on
a charge pump that is used to generate higher voltages needed for programming
activities. The ISC_DISABLE instruction would later turn off this charge pump.
The manipulation of the charge pump would be clocked by TCK.
326 9 IEEE 1532: In-System Configuration

The other factors that govern the system modal states and navigation among
them are three “signals” that are set or cleared by activities of ISC instructions, and
other events such as assertion of TRST*, powering up the device, or passing through
the Test-Logic-Reset state. These signals7 are:
• ISC_Enabled—a signal that indicates the ISC_ENABLE instruction has been
successfully executed to completion. This signal is cleared at power up, by pass-
ing to the Test-Logic-Reset state and, by completion of the ISC_DISABLE
instruction.
• ISC_Done—a signal that indicates there are valid programming bits in the PLD
program memory. It is set by the programming algorithm8 used to download and
verify program information. In volatile devices, it is cleared upon power up. In
non-volatile devices, its state is retained when powered down and later powered
up again.
• ISC_Disable_Completing—a signal that indicates the ISC Complete modal state
has been entered legally by action of the ISC_DISABLE instruction. This signal
is cleared at power up.
The four system modal states and transitions between them are shown in Fig. 9.3.
Each state bubble in the diagram shows the state of the three signals (in parenthesis)
just described. (Note, “TLR” in the diagram indicates passage to the Test-Logic-
Reset state, as could occur if TRST* is asserted.) The “non-test” instructions include
BYPASS, IDCODE, etc. from 1149.1, and all of the 1532 instructions.
To understand the diagram, consider a device at power up. It will be placed in either
the Unprogrammed or Operational system modal states, depending solely on the state
of the ISC_Done signal. This signal indicates whether there is a valid configuration
stored in the device. ISC_Done can only be set at power up in non-volatile devices that
were programmed at an earlier time before power down. In volatile devices, the device
would have to power up in the Unprogrammed system modal state.
Assume the device has a cleared ISC_Done signal. It will power up in the
Unprogrammed system modal state. The only way for it to exit this state is by the
successful execution of the ISC_ENABLE instruction, including some number of
required TCK cycles in the Run-Test/Idle state. This number is a function of the
PLD design and will vary from device to device. It is a minimum number. If more
TCK cycles are applied, the device will have no future action due to extra clocking.
As we saw before with other instructions (e.g., RUNBIST) that may execute in

7
These signals may or may not exist in the actual implementation. Their existence cannot be veri-
fied from the I/O pins of the device. They are used as a mechanism for describing internal behav-
iors of a 1532 device and for writing rule to govern this behavior. These behaviors must exist and
can be observed from outside the device.
8
It should be set at the end of programming activities. A device may be incompletely programmed,
for example, due to some error sensed during programming, but the ISC_Done signal should not
be set until the programming algorithm is satisfied the program data is correct.
9.1 IEEE 1532 Vocabulary and Basics 327

Any non-test Any non-test instruction but

instruction but ISC_DISABLE executed
ISC_ENABLE
executed ISC_ENABLE executed

ISC
Accessed
Unprogrammed TLR and
(1,X,X) *
(0,0,0) * ISC_Done is clear

d t
an se

ISC_DISABLE executed
ISC_Done
LR e is
is clear T on
D
C_
IS

Power
Up

ISC_Done
is set
E ISC_DISABLE
A BL loaded
N ed
C_E cut
IS exe
IS r a t IS
C ny C
o u
_D n _
on on Dis
b

e -te ab

Operational ISC
is s le

(0,1,0) * Complete
cl t in lo
ea s a

(0,X,1) *
r a tru de
nd cti d)
(T on
LR

Any non-test
instruction but
ISC_ENABLE ISC_Done is set and
executed * Signals:
(TLR or any non-test
(ISC_Enabled, ISC_Done,
instruction but
ISC_Disable_Completing)
ISC_Disable loaded)
1532SMode

Fig. 9.3 1532 system modal states, and transitions between them

Run-Test/Idle, several devices may all be in this state at the same time. The device
that requires the most cycles will define the duration of clocking. The others will
simply idle until it completes.
If the device had powered up with a set ISC_Done signal, it would go to the
Operational system modal state. Again, the only way to exit this state is to success-
fully execute the ISC_ENABLE instruction. In either case of power up in
328 9 IEEE 1532: In-System Configuration

Unprogrammed or Operational states, the ISC_ENABLE instruction leads the

device into the ISC Accessed system modal state. In this state, it is ready for pro-
gramming activity. (These will be discussed in Sect. 9.2.) In one case the device was
blank, and in the other it has valid programming.
Once in the ISC Accessed system modal state, the device can be programmed
(by writing bits into its configuration memory), read out for verification, or erased
if this is supported.9 All these activities may take large numbers of ISC instruction
loads, data scans, and TCK cycles spent in the Run-Test/Idle state. Note that a num-
ber of 1532 devices in a chain can be doing these types of things concurrently, if
each is in the ISC Accessed modal state.
At the end of some programming activity, be it for writing data, verifying data,
or erasing data, the ISC Accessed system modal state can be exited in two major
ways. The first (and preferred) way is by executing the ISC_DISABLE instruction
to completion. This takes the device to the ISC Complete system modal state. Here
it is ready to become operational if the ISC_Done signal is set, or it will return to the
Unprogrammed modal state if ISC_Done is clear. The way the device actually
makes either transition is by displacing the ISC_DISABLE instruction from the
instruction register. Displacement is different from execution of some new instruc-
tion. It occurs on the falling edge of TCK in the Update-IR state, whereas before we
needed to execute an instruction to completion in the Run-Test/Idle state. This was
done to allow software algorithms to predict exactly when a device within a chain
would become Operational, and to control the order of operational transitions when
there might be several devices in a chain that are ready to become Operational. The
order is determined by loading the first device’s instruction register with some
instruction (typically BYPASS) that displaces ISC_DISABLE from it. The others
have ISC_DISABLE reloaded, so they stay in the ISC Complete system modal
state. This can be repeated as needed to assure that certain devices become
Operational before others do. In some cases, this sequencing will be important to
the orderly bootup of a newly programmed system.
A second way the ISC Accessed state can be exited is by passing to the Test-
Logic-Reset state, for example, by asserting TRST*. This is not the normal way to
finish a programming sequence, but shows what must happen if for some reason
programming must be aborted. In this case, the ISC_Done bit again determines
which final system modal state will result, Unprogrammed or Operational. This is
why it is important to have the ISC_Done bit managed so that it is never set when
program memory content is invalid.

9
The 1532 standard allows optional security methods that can “protect” a device from unwanted
read out, erasure and writing. In its most capable usage, the security mechanism can effectively
turn a non-volatile PLD into a permanently programmed, unreadable device much like a custom
(non-PLD) device.
9.1 IEEE 1532 Vocabulary and Basics 329

Unprogrammed ISC
Accessed

in

ed
st
An ed d I

An on
lo ar

n t
ru

ad
i o es

a b on
ad an
cle

y an S C

d
cti

lo
ct t

t En cti
le
no d _

te ad

ru ny

se _ ru
st

st A
n- IS Do

is ISC nst
lo
te C_ ne

d ti
st

an -tes
ed
ins Ena is c

in

ed n
tru ble lea

o
ad n
cti d r

lo ny
on is

A
Test
Mode

in
ed

st
An tion
ru
lo t

on b on
ad
i o es

se is

y
c
D na cti

te loa
ct t

e led
t
ru ny

st de
C_ _E tru
n
st A

is
IS C s
d IS in

Any test
t
an nd tes

d
instruction loaded
in

ar a - n
cle de no
y
lo An
d
a

ISC
Operational
Complete

1532SMode

Fig. 9.4 Entry and exit to test mode from the system modal states

Finally, a device in any system modal state can enter test mode by having a test
instruction (EXTEST, CLAMP, HIGHZ, INTEST, RUNBIST) loaded into its
instruction register. This is shown in Fig. 9.4.
It is possible that a designer does not want to support certain sequences of 1532
and 1149.1 instructions. For example, if in the ISC Accessed system modal state
certain high voltages are generated, these may conflict with the operation of (say)
EXTEST if they aren’t removed. The designer may shut down the voltage generator
when EXTEST is loaded, but must also clear the ISC_Enabled signal in this situa-
tion. Then, when a non-test instruction is reloaded, the ISC Accessed modal state
will not be re-entered. The designer must document the behavior of “illegal instruc-
tion sequences” so that software can avoid them.10

10
It is probably a rare case that a software tool might want to execute (say) EXTEST while in the
middle of a programming operation.
330 9 IEEE 1532: In-System Configuration

9.1.4 System I/O Behavior

With the 1149.1 standard, system I/O pins behave as defined by their system
definition in system mode, and are controlled by Boundary-Scan resources when in
test mode. With the 1532 standard, the same is also true, but what does it mean to
have system mode divided into four system modal states?
The Operational system modal state (see Sect. 9.1.3) is the only state that seems
to match the 1149.1 definition of “system mode”. Yet, 1532 defines the other three
as also being a part of system mode as well, for ISC pins. Fixed pins do not differ-
entiate their behavior based on system modal states. ISC pins do. Indeed, this is a
contribution of 1532, the rigorous definition of system modal state I/O behavior.
The “system behavior” of ISC pins of a programmable device is not at all like
that of fixed pins. When a device is Unprogrammed, what should be the behavior of
ISC pins? Clearly it cannot be the same behavior as that of Operational ISC pins
since no functional definition for these pins has been provided. Thus, the 1532 stan-
dard provides the definition.
For the Unprogrammed system modal state, the 1532 standard requires ISC pins
to be non-driven, for example they should be in a high-impedance state. In the
Operational system modal state, the ISC pins should take on their system definition
as dictated by the programmed configuration within the device. In the other two
system modal states (ISC Accessed and ISC Complete) the ISC pins as a group have
one of two choices of behavior. First, they may all be non-driven as in the
Unprogrammed modal state. This is called the “HIGHZ-like” behavior. Second,
they may all take on a state controlled by the content of the Boundary Register, in a
manner identical to the I/O behavior of the CLAMP instruction. (See Sect. 1.5.5.)
This is called the “CLAMP-like” behavior. If this choice is taken, then a PRELOAD
instruction sequence will be needed to establish the state of the Boundary Register
needed to produce an appropriate I/O state on the ISC pins. This “appropriate” state
would be determined by the application software11 using the feature. It allows the
ISC device to condition its outputs to some static configuration during program-
ming, which may be useful for controlling surrounding devices it is attached to.
This specification of ISC pin behavior can lead to a surprising consequence.
Let’s say you’ve chosen the CLAMP-like ISC pin behavior in your device design.
You start with a blank device in the Unprogrammed modal state. You PRELOAD
bits in the Boundary Register for I/O control. You then load and execute the ISC_
ENABLE instruction. This causes the device to go into the ISC Accessed system
modal state and the outputs are now controlled by the content of the Boundary
Register. If you now do a second PRELOAD operation (still in the ISC Accessed
modal state) you will see the ISC pin drivers respond to the newly loaded Boundary
Register content at the falling edge of TCK in the Update-DR state, just as if the
EXTEST instruction was in effect. This is a consequence of the system modal state
definition of 1532, and not a violation of the 1149.1 standard.

11
Since most PLDs have very flexible programmable I/O behavior (meaning an ISC pin may be
defined as input, output or bidirectional by programming) it is likely that any device that chooses
to implement the CLAMP-like behavior can emulate the HIGHZ-like behavior.
9.1 IEEE 1532 Vocabulary and Basics 331

Since fixed pins on an ISC device are always performing their system function
during ISC programming activities, it is possible for a portion of an IC such as the
microcontroller in Fig. 9.1 (page 344) to be performing the configuration of the
programmable portion of the same device!

9.1.5 ISC Pin I/O Cell Design

A typical PLD device may have a Boundary Register that looks as shown in Fig. 9.5.
The I/O modules (IOM in the figure) contain Boundary-Scan resources for full bidi-
rectionality since a pin may end up being an input, output or bidirectional pin after
programming.
The content of an IOM is shown in Fig. 9.6, for the case where the designer
chooses to implement independent data output and input cells. A single-cell bidirec-
tional based on the BC_7 cell (see Sect. 2.6.3, page 101) could have been used that
would result in a 33% reduction in shift register length, but we use this design for
discussion.
The input cell design can be a standard BC_1 type cell (see Sect. 2.6.3, page 95).
The output and control cells can be modified version of BC_1. For the purposes
of BSDL, they are identical to BC_1 cells. The modifications have to do with
supporting the system modal states and two possible output behaviors, CLAMP-
like and HIGHZ-like. Both options are shown in parts A and B of Fig. 9.7.
(Note these designs are not optimized.) Part A is basically identical to a BC_1 cell.
This is because the control cell will disable the driver. However part B has some
differences in the output multiplexer structure. System data is passed to the output

Fig. 9.5 A simple PLD

Boundary Register design

IOM IOM

IOM IOM

IOM Core Logic IOM

IOM IOM

TAP and
TDI TDO
Instruction Register

TCK
TMS PLDBreg
332 9 IEEE 1532: In-System Configuration

Fig. 9.6 Typical PLD I/O

module design
From TDI
Input Cell
IOM
U C

Output Cell
C U ISC Pin

Control Cell
C U

Towards
TDO IOModule

Instruction Type Mode

ISC Instruction X
Test Instruction 1
Mode G
Non-Test Instruction 0 Shift Out
Parallel In 0 Parallel
Capture Update 1 Out
Shift-DR G
0 Reg Reg
D Q D Q
1
CK CK

Shift In Clock-DR Update-DR A (HIGHZ-like)

Instruction Type Mode B (CLAMP-like)
ISC Instruction 1
Shift Out
Test Instruction 1 Mode G2
Non-Test Instruction 0 ISC_Enabled G1

Parallel In 00
01 Parallel
Shift-DR Capture Update
G 10 Out
0 Reg Reg 11
D Q D Q
1
CK CK

Shift In Clock-DR Update-DR DataCell

Fig. 9.7 Output data cells for HIGHZ-like and CLAMP-like behavior
9.1 IEEE 1532 Vocabulary and Basics 333

Mode1 G2
ISC_Enabled G1
ISC_Done G0
Instruction Type Mode1 Mode2
111
ISC Instruction 0 0
110
Test Instruction 1 X Parallel
101 Out
Non-Test Instruction 0 1 100
011
Shift Out
010
Parallel In 001
Capture Update 000
Shift-DR G
Mode2
0 Reg Reg "0"
D Q D Q
1
CK CK

Shift In Update-DR
Clock-DR Reset CntlHiZ

Fig. 9.8 A control cell design for HIGHZ-like behavior

Mode G2
ISC_Enabled G1
ISC_Done G0

111
Instruction Type Mode 110
ISC Instruction 1 101 Parallel
Test Instruction 1 100 Out
Non-Test Instruction 0 011
Shift Out
010
Parallel In 001
Capture Update "0" 000
Shift-DR G
0 Reg Reg
D Q D Q
1
CK CK

Shift In Clock-DR Update-DR Reset CntlClamp

Fig. 9.9 A control cell design for CLAMP-like behavior

only when there is a non-test instruction loaded and the ISC_Enabled signal is clear.
Otherwise the Update latch contents are passed to the output. Again, the control cell
may disable the driver, blocking data from the output pin.
The HIGHZ-like and CLAMP-like control cells are shown in Figs. 9.8 and 9.9
respectively. Both these cells are modifications of the BC_1 cell design (see Sect.
2.6.3, page 95) and for the purposes of BSDL, they are still considered BC_1 cells.
The modifications affect the output multiplexer as was the case with the data cells.
334 9 IEEE 1532: In-System Configuration

Table 9.1 Control cell operation for HIGHZ-like behavior

Source of control for the output pin driver Condition when this occurs
System control 1. An 1149.1 non-test instruction is loaded, and
2. ISC_Enabled is clear and ISC_Done is set
Content of Update Latch An 1149.1 test instruction is loaded
“0” (disable) All other cases

Table 9.2 Control cell operation for CLAMP-like behavior

Source of control for the output pin driver Condition when this occurs
System control 1. An 1149.1 non-test instruction is loaded, and
2. ISC_Enabled is clear and ISC_Done is set
Content of Update Latch 1. An 1149.1 test instruction is loaded, or
2. An ISC instruction is loaded, or
3. An 1149.1 non-test instruction is loaded and
ISC_Enabled is set
“0” (disable) 1. An 1149.1 non-test instruction is loaded, and
2. ISC_Enabled is clear and ISC_Done is clear

The HIGHZ-like cell of Fig. 9.8 controls the output as summarized in Table 9.1.
The CLAMP-like cell of Fig. 9.9 controls the output as summarized in Table 9.2.
All the ISC data and control cells shown in Figs. 9.7, 9.8, and 9.9 are unopti-
mized. The system pathway from “parallel in” to “parallel out” can be optimized for
speed, while the path from the Update Latch to “parallel out” is not speed-critical.

9.2 Programming Features of IEEE 1532

At the time of IEEE Standard 1532 inception, the PLD marketplace was a riot of
complex and incompatible programming methodologies. Granted, there are signifi-
cant technological differences between (say) a volatile RAM-based Field-
Programmable Gate Array and a non-volatile Complex Programmable Logic Device
(CPLD). PLD devices are also benefiting from Moore’s Law, not just that they can
contain more configurable logic, but they can also utilize some gates to “hide” the
messy details of how the programming is actually done.
The 1532 standardization effort started at a fortunate time—a time where the
various PLD vendors could think about moving towards a common programming
approach while dedicating some circuitry to maintain backward compatibility
with older designs. Think of it as putting an on-chip hardware interface between a
“logical” programming model that can be standardized, and a tried-and-true physi-
cal realization of a programming method. This allowed them to minimize the impact
of 1532 acceptance on their programmable designs. As we all go forward, PLD
vendors will have time to optimize the internal workings of the programming
circuitry as they see fit.
9.2 Programming Features of IEEE 1532 335

That said, when you peruse the 1532 standard you see quite a large list of ISC
instructions and their associated registers. This reflects the fact that PLD vendors
wanted to make sure that the 1532 standard did not preclude a particular favorite
mechanism of their architecture, currently in use, even though it might be dropped
as part of a later optimization. Hence, I expect that many of the ISC instructions
currently in place will fall into disuse relatively soon, leaving a small, core set of
essential instructions in wide use.
This chapter will not document the entire 1532 programming capability, as this
book is dedicated to Boundary-Scan testing, not device programming.12 (See
[Jaco03] for a generous treatment of 1532 programming, and of course, the 1532
standard itself [IEEE02].) Therefore, only an abbreviated discussion of 1532-based
programming is given here, based on a “core set” of capabilities.

9.2.1 Core 1532 Programming Instructions

We start with a simple model of a PLD configuration memory, depicted in Fig. 9.10.
Here, the PLD memory is a typical array13 of locations, addressed by rows that are
some number of bits wide. Unlike “typical” memories, some bit positions may be
unpopulated, such that if you read them back after a write operation, you do not get
back what was written. In the model, there is an address register to select a row of
memory, and a data register to read/write from that row.

Address Data

Registers
Memory Array
(some space unused)

PLDMem

Fig. 9.10 Simple PLD configuration memory model

12
This is not to say that test engineers do not care about programming, since In-System
Configuration is often performed during manufacturing test of boards, on ATE systems.
13
Some PLDs have more complex memory structures, broken up into sectors of varying depths and
widths. It is even possible that some sectors are volatile while others are non-volatile.
336 9 IEEE 1532: In-System Configuration

Address Gen

ISC_Address

TDI ISC_PData TDO

Memory Array

PLD1532

Fig. 9.11 Simple PLD memory structure with 1532 access

The 1532 standard provides a series of instructions to target this model. Indeed,
the address and data registers become target registers for these instructions, so that
they become shift registers between TDI and TDO. In the simplified subset of capa-
bilities documented here, there is an ISC_ADDRESS_SHIFT instruction that
selects an ISC_Address register, and an ISC_PROGRAM instruction that selects
the ISC_PData register. There is an ISC_READ instruction that also targets the
ISC_PData register. Finally, there is an ISC_ERASE instruction that targets the
ISC_Default register, which in this simplified case is really the Bypass register. An
integrated model of this simple PLD device is shown in Fig. 9.11, showing how
address and data are shifted and manipulated.
In this view, the ISC_ADDRESS_SHIFT instruction can be used to set up an
address then used by the ISC_PROGRAM (or ISC_READ) instruction to write to
(or read from) the memory array. This would entail an instruction scan to load ISC_
ADDRESS_SHIFT, followed by a data scan to supply an address. (See Sect. 3.1.1
to refresh your memory on what instruction and data scans look like.) Then an
instruction scan would load the ISC_PROGRAM instruction, followed by a data
scan to provide data to be written into the array. Once that data was in place, some
specific number of TCK cycles in the Run-Test/Idle state would actually “burn” the
data into the memory.14 In some devices this may be quick (a few TCK cycles) and
in others, typically non-volatile memory, this could take milliseconds of time during
which some minimum number of TCK cycles are also needed.

14
In some older devices, the programming activity is literally used to burn small fuses. In newer
technologies, electrons are transported across potential barriers and trapped. In RAM-based tech-
nologies, the TCK cycles are used to drive a state machine that delivers the data via some internal
protocol. In all cases, the so-called “burn” mechanism is hidden from external users who only see
the 1532 protocol. This is a major contribution of 1532.
9.2 Programming Features of IEEE 1532 337

This is the simplest way of programming (or reading) a row of memory. However,
notice that there is a lot of instruction scanning and data scanning going on. This
could be considered wasteful if one wants to program a sequence of contiguous mem-
ory locations. That is why there is an “address gen” block in Fig. 9.11. This block
performs an “auto-increment” on the address in response to the successful comple-
tion of an execution of ISC_PROGRAM. This allows us to do one ISC_ADDRESS_
SHIFT operation to set up the first address of a sequence of data rows. Once that
address is in place, the ISC_PROGRAM instruction is loaded just once to begin data
transfer. Then a sequence of data shifts is used to program subsequent rows of data.
Reading back a sequence of memory location is done in like fashion, with the
ISC_READ instruction used to access an addressed location and shift it out where
it can be verified. Again, some number of TCK cycles in the Run-Test/Idle state are
used to do this access, so that the internal protocol for reading is hidden.
Finally, the ISC_ERASE instruction can be used to perform a bulk-erase
function on a device, returning it to a blank (Unprogrammed) system modal state.
Note the ISC_ERASE instruction should also clear the ISC_Done signal. Yet again,
TCK cycles in the Run-Test/Idle state are used to sequence the actual details of
erasure, which are hidden from external view.

9.2.2 Programming a Single, Simple 1532 Device

The sequence of activities needed to program one very simple 1532 device is given
in Table 9.3. This would be performed after the 1149.1 capabilities of the device had
been used to verify the device was properly mounted on the board and that its inter-
connections with other devices were not open or shorted.
Steps 6 and 12 of this process are where configuration data is shifted into or out of
the device. In step 6 that data for a given row is shifted into place and then the burn
occurs. At the end of the burn, the address is incremented, ready for a new row.
However, in step 12 things are a bit different. The actual transport of configuration data
from the device’s memory to the ISC_PData register occurs in the Run-Test/Idle state,
yet the register is shifted out before that has happened. This means on the first iteration
of the readback loop, there is undefined data in the register. This is “lagging” behavior
we so often see with TAP operations. All subsequent read/shift operations will read
back configuration data of the previously addressed row. On the last valid row, we
have to proceed to step 15 to do one final data scan to shift it out for inspection.
The 1532 standard contains the concept of an optional status register. If it is
implemented, then every time data is captured in some target register, the bottom N
bits indicate status. N must be at least 2, capturing a “10”, with any more significant
bits having device specific meaning. Status should be thought of as bits appended
next to TDO. If ISC_PData was K bits long, it would be K + N bits long if status in
implemented. Thus when using ISC_PData for reading in data, an extra N dummy
bits must first be shifted in at the status location.
In the example just reviewed, the simple device did not implement status. If some
memory location failed to accept data, that would be later determined by reading back
338 9 IEEE 1532: In-System Configuration

Table 9.3 Sequence of events to program and verify one simple 1532 device
Step Device TAP activity What is happening
1 Instruction Scan Load ISC_ENABLE
2 Run-Test/Idle Wait for enable time
Device in ISC Accessed system modal state, ready for programming.
3 Instruction Scan Load ISC_ADDRESS_SHIFT
4 Data Scan Shift in starting address
5 Instruction Scan Load ISC_PROGRAM
6 Data Scan Shift a row of configuration data into ISC_PData register
7 Run-Test/Idle Wait for write burn time. This increments the address at the
completion of each burn.
8 If more data to program, return to step 6
Now continue with configuration readback to verify the programmed data.
9 Instruction Scan Load ISC_ADDRESS_SHIFT
10 Data Scan Shift in starting address
11 Instruction Scan Load ISC_READ
12 Data Scan Shift a row of configuration data out of the ISC_PData register
(see text)
13 Run-Test/Idle Wait for read time. This increments the address at the completion
of each read.
14 If more data to read back, return to step 12
15 Data Scan Shift out the last row of configuration data in the ISC_PData
register (see text)
Now complete the process and make the device operational.
16 Instruction Scan Load ISC_DISABLE
17 Run-Test/Idle Wait for disable time
18 Test-Logic-Reset Device configured and operational

and verifying the data. If status were implemented, then the device could indicate
much sooner that something was not right with the programming process. The
device’s internal programming circuitry can be monitoring various operational fac-
tors such as charge pump voltage, time spent burning, etc. and create a valid status
indication when these parameters are nominal, and an error indication with “01” bits
in the least significant positions when some error is sensed. Another condition that
can create a status error is any attempt to perform an operation (such as reading con-
figuration content) that has been disabled by an activated security mechanism.

9.2.3 Concurrent Programming of Multiple Devices

Next we consider the case where we are concurrently programming multiple devices.
In Table 9.4 we will examine the process for two devices of similar but not identical
natures, probably from the same family of devices, but of differing sizes. Thus there
is more data to program into the larger device. These devices do no implement a
9.2 Programming Features of IEEE 1532 339

Table 9.4 Sequence of events to program two similar devices of differing size
Smaller device A Larger device B
Step TAP activity What is happening What is happening
1 Instruction Scan Load ISC_ENABLE Load ISC_ENABLE
2 Data Scan Shift ISC_Config Register Shift ISC_Config Register
3 Run-Test/Idle Wait for maximum enable time
Both devices in ISC system modal state, ready for programming.
4 Instruction Scan Load ISC_PROGRAM Load ISC_PROGRAM
5 Data Scan Shift configuration data Shift configuration data
into the ISC_PData register into the ISC_PData register
6 Run-Test/Idle Wait for maximum write burn time
7 If more Device A data to program, return to step 5
8 Instruction Scan Load ISC_NOOP (see text) Reload ISC_PROGRAM
9 Data Scan Shift dummy bits into Shift configuration data
the ISC_Default register into the ISC_PData register
10 Run-Test/Idle Wait for Device B write burn time
11 If more Device B data to program, return to step 9
Now read back programming data from both devices.
12 Instruction Scan Load ISC_READ Load ISC_READ
13 Data Scan Shift configuration data Shift configuration data
out of the ISC_PData register out of the ISC_PData register
14 Run-Test/Idle Wait for maximum read time
15 If more Device A data to read back, return to step 13
16 Data Scan Shift ISC_PData Reg Shift ISC_PData Reg
17 Instruction Scan Load ISC_NOOP Load ISC_READ
18 Data Scan Shift dummy bits out Shift configuration data
of the ISC_Default register out of the ISC_PData register
19 Run-Test/Idle Wait for Device B read time
20 If more Device B data to read back, return to step 18
21 Data Scan Shift dummy bits out Shift configuration data
of the ISC_Default register out of the ISC_PData register
Now program security and set both devices to their operational states.
22 Instruction Scan ISC_PROGRAM_SECURITY ISC_PROGRAM_SECURITY
23 Run-Test/Idle Wait for maximum security set time
24 Instruction Scan Load ISC_DISABLE Load ISC_DISABLE
25 Data Scan Scan out status of security Scan out status of security
26 Run-Test/Idle Wait for maximum disable time
27 Test-Logic-Reset Device operational Device operational

separate ISC Address register, but have address and data combined in one register
load of the ISC_PData register. Further, the ISC_ENABLE instruction targets a reg-
ister called “ISC_Config”, which must be loaded with some configuration control
information. These two devices also implement a security method that prevents
readback of data, controlled by the ISC_PROGRAM_SECURITY instruction.
340 9 IEEE 1532: In-System Configuration

In this example there are a number of times (steps 3, 6, 10, 14, 19, 23 and 26)
where a time is spent in the Run-Test/Idle state waiting for some event to complete.
A key point here is that in most of these steps, both devices are waiting concurrently.
If for example, the burn time is (say) 5 milliseconds in both devices, we have both
burn intervals elapsing at the same time (step 6). Since the data and instruction shift-
ing time may be much smaller than a burn time, the burn times will dominate the
total time of the operation, meaning we can concurrently program two devices in
nearly the same time it takes to program the larger device.
Because device B has more data to manage than device A, we see a segmentation
of burning and reading activities. From steps 4 to 7, we are burning data into both
devices. From steps 8 to 11 we finish burning the last data into device B. Notice that
while device B continues with the ISC_PROGRAM instruction loaded in it, device
A has the instruction ISC_NOOP loaded into it. This instruction is very much like
BYPASS (see Sect. 1.4.1) in that it targets a short register, and has no other effect
on the device. This way, device A “idles” while we finish placing data in device B.
The readback operation is similarly segmented to account for the different
amounts of data. Note the “lagging” data behavior again. In step 16 the last data
extracted from both devices is read out before reprogramming the instruction regis-
ters. In step 21 there is one last data scan to scan shift out the last row of device B
data, while device A idles.
Finally, in step 27 we see both devices placed in the Test-Logic-Reset state at the
same time, which places them in the Operational system modal state. If we wanted
to make device A operational first, we could have executed one more instruction
scan at that time, loading device A with BYPASS and reloading device B with
ISC_DISABLE. This would cause device A to enter the Operational system modal
state while device B stayed in the ISC Complete system modal state. Later we could
make device B operational by entering the Test-Logic-Reset state.

9.3 Design for IEEE 1532 Programmability

IEEE Standard 1532 supports the configuration of programmable logic devices after
they have been mounted on a board. Indeed, many people want to perform this func-
tion (for non-volatile devices) after proving a board is defect-free. A natural place to
do this is on the same ATE system that tested the board. There, it has power avail-
able, and any resources needed for testing can be re-used to support programming.
Several “DFT” rules will be given here, that should make both testing and program-
ming more practical.
The 1532 standard specifies that blank (unprogrammed) devices will have all
outputs in a non-driven state. When a board containing these devices is designed,
the board designer will be aware of this and plan for it. The designer may give the
board, on power-up, autonomous processes that configure some fraction of these
devices. A test engineer will need to know which devices power up blank and which
will become configured.
9.3 Design for IEEE 1532 Programmability 341

• DFT-42: Document the state of each PLD at the completion of board power
up, for testing purposes.
If an autonomous configuration process may not complete properly when a board
is powered up, this could result in devices that do not implement the correct func-
tionality or even cause board level conflicts. There could be a number of reasons for
configuration to fail. For example, the tester fixture attached to the board may over-
load critical clock signals or otherwise interfere with signal integrity, causing con-
figuration to fail. Or, the tester may deliberately power up part of the board but leave
other parts unpowered. Or the tester may assert some reset lines needed for testing,
and these may prevent configuration. In some cases, the test engineer may want to
defeat an autonomous configuration process so PLD I/O states are guaranteed to be
disabled for test purposes. Plus, having autonomous logic operations progressing
during normal testing is very likely to disrupt the test. This means the test engineer
must know about PLD configuration processes, how they are triggered, how long
they take and if needed, how to suppress them.
• DFT-43: Document how PLDs are configured on a board, and how to trigger
or prevent configuration.
If it is desired to use a tester as the programming system for PLDs, the test engi-
neer will need to know if there is any particular conditioning of the board necessary
before, during and after programming. For example, the board may itself be a com-
ponent of a larger system, and this system may supply some conditions needed for
configuration. The tester would have to “step in” and provide this conditioning in
place of the system.
• DFT-44: Document supporting conditions needed for device programming.
If a configuration process is executed on an ATE system, what should be done if
it fails? If, for example, there were 20 PLDs to be programmed in three groups, what
should be the reaction of the tester if the second group’s program displays a bad
status indication in the middle of programming? Should the program be re-tried?
Should the third group’s program be tried or skipped? Should the first group (suc-
cessfully programmed) be erased? Should board level resets be asserted in a certain
time frame? The bottom line here is you should not assume the programming pro-
cess will be unerringly successful, and plan for contingencies. A partially pro-
grammed board with power applied may be at risk.
• DFT-45: Document what actions should be taken when a programming pro-
cess fails while on an ATE system.
Earlier rule DFT-16 (page 200) suggested that PLDs should be chained together
contiguously, at one or the other ends of the chain, so that if needed they could be
accessed by a tester as if they were a separate chain. It is less important for this to
be done if the devices are actually 1532-compliant. However, one should consider if
some non-PLD device(s) on the board will need to be disabled with Boundary-Scan
in order to support the programming process. For example, some non-PLD device
342 9 IEEE 1532: In-System Configuration

might cause driver conflicts during programming15 if it is not disabled. However, if

disabling can only be done with EXTEST (because CLAMP and HIGHZ were not
available), then this could greatly lengthen the programming process in terms of
data to be downloaded. This is because for each row of programming data to be sup-
plied, you also have to resupply the controlling states being used by EXTEST.
If the tester will support it, this may be a good time to consider putting the PLDs in
a different chain from the devices with complex disabling requirements.
• DFT-46: Plan how non-PLD devices will be disabled during programming,
and avoid using data-intensive EXTEST disabling.

15
Note this is not because of a design flaw, but because the board may not be able to configure on
the test system the same way the board designer intended during normal system operation. This
can be a tester loading issue, or perhaps the board cooperates with missing system functions in
normal operation that cannot be replicated on the tester.
Chapter 10
IEEE 1149.8.1: Passive Components

IEEE Standard 1149.8.1[IEEE12]1 addresses “Boundary-Scan-Based Stimulus of

Interconnections to Passive and/or Active Components”. The stated purpose of
this standard is: “… to codify testability circuitry added to an IC incremental to the
testability provisions specified by IEEE Std 1149.1. This will enable selective AC
stimulus generation that, when combined with non-contact signal sensing, allows
testing signal paths between devices adhering to this standard and passive and/or
active components.”2 What this means is, the 1149.8.1 standard adds new capabili-
ties to the existing 1149.1 standard3 to support test technologies that utilize sensing
technologies that are both unconventional and unanticipated by 1149.1. The prin-
ciple target technology for this standard is generically called “Unpowered Capacitive
Opens Detection”, where test signals are injected into printed circuit boards, which
are then sensed by a non-contacting capacitive sensing plate mounted over a
targeted device under test. Some examples of commercially available tools to
­perform such testing are called “TestJet”, “Opens Express” and “Framescan”, and
these have available for decades now. 4
The defect of interest in unpowered capacitive opens testing is an open circuit,
typically a missing solder joint or ball (see pin 1 in Fig. 3.1 on page 114). The target
device is often passive, such as an empty connector or socket. Obviously, such a
device, being passive (non-silicon) cannot itself contain its own testability struc-
tures compliant to 1149.1. Thus, when boards contain such devices, even when
connected to ICs that do contain 1149.1 testability, there is a lack of test coverage
for the pins on those passive devices.

1
This standard has two suffixes (.8 and .1) in anticipation that other standards in the future may be
created that are also adjuncts to the base, 1149.1 standard. Basically, the IEEE was running out of
numbers using only 1 suffix, so this convention was adopted.
2
This statement comes from IEEE Std. 1149.8.1, Copyright 2012 IEEE. All rights reserved.
3
This additive quality is the same seen with 1149.4 and 1149.6. Indeed it is anticipated that
1149.8.1 could coexist inside an IC with 1149.1 and 1149.6.
4
TestJet is a trademark of Keysight Technologies. Opens Xpress and Framescan are trademarks of
Teradyne Inc.

© Springer International Publishing Switzerland 2016 343

K.P. Parker, The Boundary-Scan Handbook, DOI 10.1007/978-3-319-01174-5_10
344 10 IEEE 1149.8.1: Passive Components

Notice the title of the standard mentions “Passive and/or Active Components”.
This is because in many cases, active ICs that do not contain 1149.1 Boundary-Scan
can be tested for opens using the capacitive sensing technique. A prevalent example
of such ICs are dynamic random access memories (DRAM). See [Park12]. The next
section gives a description and history of this technology, which helps map its evo-
lution into Boundary-Scan based application.

10.1 Unpowered Capacitive Sensing

Annex A in [IEEE12] gives a tutorial on Unpowered Capacitive Opens Testing. The

salient points are repeated here. Consider a circuit board with a vacant connector
attached by a ball grid array of solder balls, as seen in Fig. 10.1. The board is placed
on a standard In-Circuit tester fixture (for example, see Fig. 1.2 on page 6) where a
new feature, a capacitive sense plate is mounted over each Device Under Test (DUT)
that needs to be tested for open connections. The sense plate has a signal amplifier
atop it, to buffer a tiny sensed signal and pass it back to the tester’s detection elec-
tronics, which may be several feet away.
The sense plate is close to, but not in contact with the conductors inside the con-
nector. The In-Circuit tester, using its bed-of-nails, can ground all the unpowered5

To tester

Signal
amplifier
Solder ball array
Sense Plate Internal
conductors
Vacant Connector

PC Board Under Test

Test access pad

In-circuit access
AC Source in tester stimulates one board node
connected to DUT, all other nodes grounded

ICTUOT

Fig. 10.1 In-Circuit tester setup for unpowered capacitive opens test

5
“Unpowered” is an important distinction since none of the active devices receive power. Thus we
can ground many nodes without fear of any damage. Note also that all these nailed nodes can be
tested for shorts between them by using conventional In-Circuit shorts testing techniques.
10.1 Unpowered Capacitive Sensing 345

board’s nodes except for one of interest, to which it applies a low-amplitude AC

signal at a specific frequency (typically around 8 kHz). The low amplitude, typically
400 mV, means the node will not exceed ±200 mV with respect to the board. This
means diode junctions connected to the stimulated node inside other devices (for
example, the protection diodes inside ICs) will not turn on. (If they did, then they
would clip the stimulus signal, depleting it.) By examining the board’s netlist infor-
mation, the tester software will know which nail stimulates a connection under the
DUT. When this connection is stimulated with the AC signal, the sense plate above
the DUT will pick up a small amount of this signal, which is buffered and sent to the
tester’s frequency detector. The amplitude of this signal is proportional to the amount
of coupling capacitance from the connector conductor to the sense plate. These
capacitances are very small, with values well below a picofarad (10−12). Indeed, in
modern devices we are seeing readings in the low tens of femtofarads (10−15).
So, how does this help with testing for open connections? The answer comes by
looking at an equivalent model of the measurement setup, and then what happens
when an open circuit exists, as in Fig. 10.2a, b. In the defect-free case (a), the source
frequency couples from the tip of the internal connector pin to the sense plate, with
a measured capacitance of CS. The tester can determine what a good reading should
be by “learning” the readings from a known-good board.6 When a defect causes an

Defect-free connection With open solder defect

Sense plate

CS
Connector
pin

Connector
Sense plate
lead
CS CO
Connector AC Detector Board AC Detector
pin solder pad
Measured Measured
capacitance capacitance
= CS CS*CO
AC Source AC Source =
CS + C O

A B CapModel

Fig. 10.2 Electrical model of the capacitance measurement, defect-free (a) and with an open (b)

6
This is greatly simplified here. The learning process needs to make multiple readings and examine
their statistics, so as to set reliable limits on what constitutes a good or failed reading.
346 10 IEEE 1149.8.1: Passive Components

To tester

Solder joint
Signal
Board amplifier
node 1 Resistor Internal
Sense Plate
conductors
Vacant Connector

PC Board Under Test

Board
node 2
In-circuit access Connector pin ball Defects

Fig. 10.3 Intervening series components also receive test coverage

open circuit (in part b) this has the effect of injecting a second capacitance CO in
series with CS. The measured result is given by the equation for series capacitances
as shown. Note that when CS is larger than CO, the measured value tends to change
rather drastically. For example, if CS = 4*CO, then the measured value changes from
the defect-free CS to a defective value of 0.2*CS. Happily, the values of CS have
historically been much larger that CO, but there is a trend towards smaller values of
CS due to the shrinking physical sizes of many components.
When there are intervening series components between the tester nail and the
device that has the sense plate atop of it, there can be additional test coverage gained
by this test. For example, in Fig. 10.3 there is a surface mounted series resistor between
the nail and a vacant connector pin being tested. When the test passes, then we know:
1. the connector pin has continuity to board node 2,
2. the resistor R is present (but we don’t know its value7), and
3. the two resistor solder joints to board nodes 1 and 2 are not open.
Unpowered capacitive opens testing has been used very successfully in board
test for decades now. However, it is not immune to technology changes. Notably, it
depends on nodal access and this is increasingly difficult to obtain due to the ram-
pant trends towards miniaturization of virtually all components and the boards they
are mounted upon. One good thing about unpowered opens testing is that as access
degrades, the coverage it can supply declines linearly. Other test technologies

7
If an incorrectly placed resistor has a very large value, then it might block enough signal to the sense
plate that it will cause a failure. However, most series components have relatively low impedances
and will not be noticed, compared to the AC impedance of a typical CO of well under a picofarad.
10.1 Unpowered Capacitive Sensing 347

sometimes degrade catastrophically with access loss—that is, if you lose a few key
access points, you may lose a large amount of coverage. The question is, is there a
way to use the capacitive sensing idea in an environment where physical nodal
access is limited—that is, can we substitute a new way of providing the stimulus
needed for the technique to work?
This question occurred to board test engineers, who wondered if Boundary-Scan
could be substituted for the array of access points. (See [Dubb08] [Norr08], and
[Sunt09].) First, the “unpowered” part of unpowered capacitive opens testing would
have to be removed since at least enough power would have to be applied to a board
to make Boundary-Scan devices work. Then, since many nodes would not have phys-
ical access, you would need to do two things with Boundary-Scan drivers: first, hold
most nodes at “ground” and second, provide a stimulus frequency to a target node.
It was quickly realized that “ground” was not important to capacitive sensing.
What was needed was to provide a stable DC level to the pins that were formerly
grounded. This means using Boundary-Scan drivers to supply either a static high or
low. This is something Boundary-Scan’s EXTEST is well suited for, as long as the
required drivers can be enabled during the test. In fact, it is quite possible that some
drivers might need to be in a preferred state (0/1) to keep the surrounding (powered)
circuitry “happy” and quiescent.8
Then there is the stimulated node. This can be provided by a Boundary-Scan
driver that is toggled by successive scans to be 0 and then 1, repeatedly.9 The prob-
lem here was, could you achieve the needed stimulus frequency (again, somewhere
around 8 kHz10) with successive scans? This was a function of the TCK frequency
and the total length of the boundary register in effect at the time of the test. Since
two scans per stimulus cycle are needed, the time to do this is roughly 2*N times the
clock period of TCK, where N is the number of bits shifted. For example, if you
have a maximum 2 MHz TCK (period of 500 ns) then to achieve 8 kHz toggling at
a pin, you must have a boundary register no longer than 250 bits. This limitation can
easily be exceeded by even a single device’s boundary register11 So, using ordinary
1149.1 EXTEST may not be feasible.

8
There are two problems to be addressed. First, other devices need to “ignore” what we are doing,
for example, we might de-assert a neighboring device’s select line to keep it from reacting to our
test signals and perhaps doing something detrimental to device safety. Second, since the capacitive
technique can be frustrated by noise pickup from other board nodes, we may have to keep neigh-
boring devices from generating signals at the key sensing times.
9
The Boundary-Scan driver will drive at its native levels, often more than 400 mV peak-to-peak.
Since it is likely to be attached (via fanout) to other compatible devices, we do not have to be
concerned with protection diodes in these devices turning on and depleting the signal. Also, the
larger signal amplitude helps the sense plate amplifier recover a larger signal.
10
The In-Circuit tester supplies an 8 kHz sinusoidal wave. A Boundary-Scan driver would supply
something more like a square wave. Remember that most of its energy is in the fundamental fre-
quency at 8 kHz. Filters in the sense plate amplifier remove higher harmonics.
11
It is often true that several devices may need to be performing EXTEST, making the total bound-
ary register length much longer.
348 10 IEEE 1149.8.1: Passive Components

Finally, many of today’s devices make use of differential signaling, meaning, a

device driver sending signals to a DUT may actually be sending two signals that are
complementary. These two signals change states simultaneously and when both are
sensed by the capacitive plate, they tend to cancel each other out, leaving almost no
signal to detect. For defect-free (no opens) pins, this means a lack of any detected
signal signifies a passing test—or, does it? What detection threshold levels would be
needed? You could not learn these from a known-good board. Now, a single open
pin on a differential pair would lead to a detectable signal, but what if both were
open? Clearly, differential signals introduce a new layer of problems.
These realizations laid the groundwork for the 1149.8.1 standard, so that Powered
Capacitive Opens testing could be supported. This is explored next.

10.2 Powered Capacitive Opens Testing

The model needed for 1149.8.1-based testing is shown in Fig. 10.4. There a group
of Boundary-Scan drivers are used to supply test signals to a vacant connector, as
before. One driver is supplying a square wave at the required frequency to a
pin being tested for continuity. During that time the other drivers hold a static
“background state” of 0/1 data.

To tester

Signal
amplifier

Sense Plate
Vacant Connector

PC Board Under Test

Board Interconnect

TDI 0 1 1 0 0 0 0 TDO

TCK Toggling
driver
TMS
Statically held driver states

Boundary-Scan IC(s) elsewhere on the board

with connectivity to the vacant connector
BSStim

Fig. 10.4 Basic stimulus/sense model of 1149.8.1 testing

10.2 Powered Capacitive Opens Testing 349

To tester

Signal
amplifier

Sense Plate
Vacant Connector

PC Board Under Test

Board Interconnect

TDI 0 1 1 0 TDO
Toggling
TCK
driver
TMS To Boundary-Scan
receivers on board
Statically held driver states
Boundary-Scan IC(s) elsewhere on the board
with connectivity to the vacant connector
IOPrblm

Fig. 10.5 Some Boundary-Scan driving resources may be missing

However, this model is potentially deficient in that it assumes every pin on the
vacant connector is connected to a Boundary-Scan driver in some IC on the board.
This is often not true. For example, if the vacant connector is intended (for example)
to have an extension board plugged into it, then some pins will be inputs to the plug-
­in board (with Boundary-Scan drivers on the board under test) while other pins will
be outputs from the plug-in board, which might only have Boundary-Scan receivers
on the board under test.
This is depicted in Fig. 10.5. This tells us we need some driver resources in those
pins that are not part of the normal functional requirement of the device. This may
seem oppressive—adding a Boundary-Scan driver to a pin that normally only
receives data. However, what we need is a very basic drive capability, not an exotic
or powerful drive functionality. It will be used to support opens testing; therefore it
only needs to produce a relatively low frequency square wave with a relatively
small voltage swing. It will also participate in standard shorts testing as well, and
again, no exotic requirements are needed for this either.
This realization drives the 1149.8.1 standard to divide system pins into those that
need special new resources, while others (called “normal”) are basically left alone
to implement the requirements of 1149.1 Boundary-Scan, alone. These special pins
are called “Selective Toggle”, or “ST” system pins. This closely mimics how the
350 10 IEEE 1149.8.1: Passive Components

1149.6 standard works; it divides the system pins into “DC” and “AC” categories
(see Sect. 8.2.2) where the DC pins operate exactly as specified by 1149.1, while the
AC pins take on additional new behavior.
It is envisioned that an IC could implement 1149.1, plus 1149.6 and 1149.8.1 as
well. These latter two are set up to be compatible with each other. Some pins could
then end up being both “AC” and “ST” capable.

10.3 IEEE 1149.8.1 Vocabulary and Basics

IEEE Standard 1149.8.1 has been carefully designed to be fully compatible with the
existing 1149.1 standard. The 1149.1 standard principally addresses digital I/O pins
of devices. The 1149.8.1 standard does this too, but introduces a categorization of
I/O pins into two types, normal system pins and selective toggle system pins.

10.3.1 Normal System Pins

In the 1149.8.1 standard, a normal system pin is a system pin, as defined by the
1149.1 standard, which has the testability resources given to it as defined by 1149.1.
Normal system pins do not have any new capabilities provided by the 1149.8.1
standard. As will be seen later (see Sect. 10.3.3) the new instructions provided by
1149.8.1 will have a default behavior designated by 1149.1 as to how they affect
normal system pins.

10.3.2 Selective Toggle System Pins

In the 1149.8.1 standard, a Selective Toggle system pin (called an ST pin) is a system
pin, as defined by the 1149.1 standard, which has the testability resources given to it
as defined by 1149.1 as well as a new “Selective Toggle” capability which may
expand the resources provided by 1149.1. The principle example of this expansion
is to give a pin that 1149.1 would equip with only monitoring (receiving) resources,
the ability to drive as well. Think of it as promoting an input pin to a bidirectional
pin, but only during test. However, the drive capability need only be rudimentary,
producing 0/1 levels on the pin when activated, and with only the minimum speed
needed to keep up with the TCK rate of the device, which is typically less than
20 MHz. That is, we do not need a powerful, high-speed driver, which would be
expensive to add. The 1149.8.1 standard [IEEE12] provides this definition of ST pin:
ST-Pins: Device system pins defined as those in need of the selective toggle capability
defined by this standard and requiring an output drive capability.
10.3 IEEE 1149.8.1 Vocabulary and Basics 351

So, what is the “selective toggle” capability, and why do some pins get this label?
Selective toggle means the ability to select one pin and have its driver toggle12 at a
rate that is equal to a frequency of TCK reduced by an integer divisor.13 Non-selected
pins will maintain a static 0/1 state while the selected pin is toggling. The toggling
occurs on falling edges of TCK while the TAP is in the Run-Test/Idle state and stops
when that state is exited. Further, toggling starts from a preloaded 0/1 state and
when it completes, that same state is returned to the pin, which means one last tran-
sition may be needed as Run-Test/Idle is exited to restore that state. (This would
occur on the falling edge of TCK in the Select-DR-Scan TAP controller state.)
The assignment of the ST label to pins is intended to be a negotiation between
the IC design team, and users of their device who expect it to be used in capacitive
sensing scenarios. A classic example is a large processor chip with a memory con-
troller port. The signals that will travel to the memory subsystem may be routed
through a set of connectors to plug-in memory cards. These cards are unlikely to be
populated while the main board is being tested, leaving us with a set of passive,
vacant connectors that we would like to test for shorts and opens. We then ask the
processor design team to incorporate both 1149.1 in the processor, and, to designate
the memory port pins (address, data and control) as ST pins, which are given
1149.8.1 resources. The other pins of the processor do not need this capability, so
the design team can save time and resources by calling them “normal”.
In this particular design example, the address bus and control wires are driven,
and the data lines are bidirectional, so no additional drive capability needs to be
added—it is already there. However, the address lines coming out of the processor
should be implemented with self-monitoring capability (for example, with BC_8
cells shown in Sect. 2.6.4 on page 104) so that shorts between address lines can be
detected. The same is true for the control lines and it is inherent in the data bus since
that is bidirectional. Opens between the processor and any of the vacant connectors
are tested by the capacitive sensing technique. (There would be one sense plate over
each connector.)

10.3.3 Instructions and Registers

Since the IEEE 1149.8.1 standard is a subsidiary standard to IEEE Std 1149.1, all
instructions mandated by 1149.1 are also mandated in 1149.8.1, and all optional
instructions from 1149.1 are also allowed, at the designer’s discretion, in 1149.8.1

12
Note, the word “toggle” here means to change state once, from 0 to 1, or 1 to 0. Two toggles
equal one cycle when we refer to “toggle frequency”.
13
This divisor is stored in a “Toggle Control Register” and may have a value of 0. The toggle fre-
quency for divisor “D” is F = FTCK/(2(D + 1)), so TCK/2 is the maximum toggle frequency. Larger
values of D produce lower toggle rates, and a minimum rate of 2 kHz is required at the maximum
rated TCK frequency of the device.
352 10 IEEE 1149.8.1: Passive Components

implementations as well. In all cases, the 1149.1 instructions operate as specified in

that standard, and act upon selected registers as mandated by that standard.
The 1149.8.1 standard mandates the addition of two new instructions. The first is
the instruction TOGGLE_SETUP (see Sect. 10.4). Second is the SELECTIVE_
TOGGLE instruction (see Sect. 10.5).
The TOGGLE_SETUP instruction is a normal mode instruction that does not
affect the normal operation of the device’s pins, and it targets a mandatory Toggle_
Control register (see Sect. 10.6) between TDI and TDO. This register is loaded with
data that later is used to control pin toggling rates.
The SELECTIVE_TOGGLE instruction is a test mode instruction that targets
the Boundary register as constructed by the rules of 1149.1. However, it controls I/O
pins by one two of sets of rules depending on whether a given pin is “normal” or
“ST”, per the categorization seen in Sects. 10.3.1 and 10.3.2. When a pin is normal,
then when SELECTIVE_TOGGLE is active, that pin behaves exactly as specified
for the EXTEST instruction mandated by 1149.1. ST-pins are given “selective tog-
gle” behavior which is described in Sect. 10.5.

10.4 The TOGGLE_SETUP Instruction

The TOGGLE_SETUP instruction is used to preload the Toggle_Control register

with data that will control the frequency of ST-pin toggling when the SELECTIVE_
TOGGLE instruction is active. This instruction would be used before test mode is
entered, just as the 1149.1 PRELOAD instruction is used to prepare for testing with
EXTEST. TOGGLE_SETUP is a normal mode instruction that does not tamper
with IC functionality, so normal I/O pin activity is unaffected.
The TOGGLE_SETUP instruction targets the Toggle_Control register between
TDI and TDO for shifting in control bits. For more detail see Sect. 10.6 below.

10.5 The SELECTIVE_TOGGLE Instruction

The SELECTIVE_TOGGLE instruction is used to select (typically) one pin from

the set of ST-pins and cause it to toggle its state at a frequency determined by the
TCK rate as divided by an integer specified in Toggle_Control register. This instruc-
tion is a test mode instruction, so it takes over the I/O pin states when it becomes
effective (in the Update-IR TAP controller state). At that instant of time, it behaves
the same way that 1149.1 EXTEST does, where driven pins are placed under control
of the Boundary register. This means a previous loading of pin state data using the
1149.1 PRELOAD instruction should be performed before changing to the
SELECTIVE_TOGGLE instruction.
The SELECTIVE_TOGGLE instruction, as stated before, treats all normal pins
the same way that EXTEST does; meaning drivers will drive out data as set up in
the Boundary register. The ST-pins will do this as well, until the Run-Test/Idle TAP
10.5 The SELECTIVE_TOGGLE Instruction 353

state is entered. What happens next is a function of the content of the Capture
flip-­flop behind a given ST-pin. If the flip-flop contains a ‘1’, then that pin is
“selected” for toggling. If the Capture flip-flop contains a ‘0’, then that pin is not
selected and will maintain the state provided in the Update flip-flop, just as would
happen with the EXTEST instruction. The key is that the Boundary register Update
flip-flops are set up with the PRELOAD instruction before loading SELECTIVE_
TOGGLE. Then, when SELECTIVE_TOGGLE is loaded, we can shift a set of bits
into the Boundary register that, for ST-pins, act as “selection” bits. For these pins
only, the transfer of data from Capture to Update flip-flops (in the Update-DR TAP
state) is inhibited, so the state of pins set up by PRELOAD is preserved. Now, after
entering the Run-Test/Idle TAP state, a selected ST-pin will then toggle its state on
the first falling edge of TCK, and as we stay in Run-Test/Idle, subsequent falling
edges of TCK will cause new pin toggles as controlled by the content of the Toggle_
Control register. Basically, you should think of the integer stored in the Toggle_
Control register as count of how many falling edges of TCK to ignore before a new
toggle occurs on selected pins, while still in the Run-Test/Idle TAP state.
To review, the SELECTIVE_TOGGLE instruction behaves just like EXTEST
for normal pins. Thus, the “basic test algorithm” of Sect. 3.1.2 (on page 120) applies.
Typically, when doing a test based on SELECTIVE_TOGGLE, we want the normal
pins to stay quiescent, so every shift of data into the Boundary register, for normal
pins, would contain the same data as was originally set up by PRELOAD. However,
for the ST-pins, we would want just one14 of these to toggle while all the others held
some static state pattern of our choosing, as determined by the PRELOAD data. To
select the pin to toggle, we load only that pin’s Boundary cell with ‘1’ while all the
other ST-pin Boundary register cell get a ‘0’. Think of the ST-pin cells as pointers
to the pin we want to toggle. On successive data scans, we can change these pointers
to select different pins for toggling. Toggling always starts from the preloaded state
and only occurs while in Run-Test/Idle.15 Thus, we can predict the exact time a
given edge will occur on a pin, its frequency and its phase. This allows us to set
up our capacitive sense circuitry to look for exactly this signal and reject others
(like noise) that are sensed.
Some capacitive sensing algorithms might operate by examining just two driven
edges, effectively, the pulse response. The time between these two toggles is an
important parameter; so this means the pulse width rather than toggle frequency is
what we need to control. This means staying in the Run-Test/Idle TAP state long
enough to issue two toggles separated by this pulse width, and then exiting before a
third toggle occurs.

14
More than one pin could be selected when there are multiple sense plates in different places on a
board and the tester is capable of using them in parallel to speed up testing. Typically, only one
signal under a given sense plate is stimulated, but, there is a special case due to differential signals
covered later in Sect. 10.7.
15
As noted before, one last edge may occur after leaving Run-Test/Idle, if the number of edges cre-
ated is an odd number. This could likely be an “early” edge, so it is recommended to create an even
number, or, assure that the detection process will not be affected by it.
354 10 IEEE 1149.8.1: Passive Components

10.6 The TOGGLE_CONTROL Register

The content of the Toggle_Control register is used to reduce the frequency of pin
toggling to a value needed by the detection parameters of the capacitive sensing sys-
tem. The highest toggle frequency is TCK/2, which corresponds to the content of the
Toggle_Control register being all-zero. The 1149.8.1 standard mandates that increas-
ing integer values in Toggle_Control will decrease the toggle frequency, down to as
low as 2 kHz for the maximum frequency of TCK (FMax, in Hertz) supported by the
device. This implies the Toggle_Control register has a length N defined by:

N ³ éëlog 2 ( FMax / 2000 ) ùû

For example, if the device has an FMax of 20 MHz, then the length of the register
must be at least 15 so as to divide the toggle frequency to the lower limit. If you have
a TCK frequency of FTCK and you want to achieve a pin toggle rate F, then the value
D loaded into the Toggle_Control register is given by16:
FTCK
D= -1
2* F
For example, if you have FTCK of 5 MHz and want to have pins toggle at F = 8 kHz,
then the value of D is 312. It is instructive to note that by the toggle frequency equa-
tion F = FTCK/(2(D + 1)), a value of D = 312 yields F of 7987 (13 Hz low), while D =
311 yields F of 8013 (13 Hz high). Thus the least significant bit has a value of 26 Hz.
The smaller the value of D, the larger the value of the least significant bit is, so this
should be considered if the frequency filters on the capacitive sensing subsystem are
very precise. A more accurate setting can also be achieved by adjusting the FTCK value.
The Toggle_Control register will capture, on the first time through the
Capture-DR TAP controller state after TOGGLE_SETUP becomes active, a value
of all-zero. Subsequently, a different value can be shifted in using the Shift-DR
state. If, while TOGGLE_SETUP is active, the Capture-DR state is re-entered, its
content may be a value defined by the device designer that could be useful for IC
testing. (This would typically never be used in board testing environments.)

10.7 Differential Signal Unbalancing

As stated earlier, differential pin pairs, due to their complementary waveforms, will
not be sensed17 by a capacitive sense plate held over them. This is recognized in the
1149.8.1 standard and it provides for a concept of “unbalancing” a differential driver.
To provide a framework for discussion, see a “typical, simplified” model for a
­differential driver shown in Fig. 10.6.

This equation is only valid for F not exceeding FTCK/2.

16

There could be some slight differences in coupling between the pin pair and the sense plate that
17

might lead to a small signal pickup, but usually, signal cancellation is nearly complete.
10.7 Differential Signal Unbalancing 355

Differential Neg
Driver 2.25v

Voltage (IS = 12ma)

1.2v
Pos
1.05v

1
Data
0
Time
Pos

R I1 I0

Neg
Neg
Data 2.775v
Pos 0.6v
Voltage (IS = 6ma) 2.175v

Current
IS 1
Source
Data
0
Time
DiffDrive

Fig. 10.6 Model of a differential driver

This picture shows a lot of information. Basically, two pairs of transistors steer
current IS in/out of the positive (Pos) and negative (Neg) legs, based on the value of
the Data pin. The two waveform charts show the voltages that appear on the legs in
time as Data changes. The top chart shows the voltages for a current source IS of
12 mA, while the bottom chart shows the voltages for IS equal to 6 mA. In both
cases, the change in the Pos and Neg legs are complementary, one rises while the
other falls by the same voltage delta. This is “balanced” behavior, and a capacitive
sense plate over the Pos and Neg pins would not see a net voltage change, that is, no
signal would be detected.
So, what does an unbalanced differential driver look like? Please examine
Fig. 10.7 for one way this can be achieved.
This driver is nearly identical with that shown in Fig. 10.6, except it has a new
input, Current Select, which can select between two values of IS, 6 or 12 mA. The
two charts in Fig. 10.7 are also a bit different. In these, we show a fixed value on the
Data line, but vary the Current Select. Notice that now, both legs move in the same
direction, although by different magnitudes depending on the setting on Data.
In either case, the movement is significant (525 or 1125 mv). A capacitive sense
plate over these two signals will see a robust signal, as there is no cancellation.
The 1149.8.1 standard gives a simple circuit for a current source, and the selectable
current feature is quite simple to add. Details of such a design are best left to IC
designers; the point is it is not difficult or expensive.
Unbalanced behavior is only enabled during testing with the SELECTIVE_
TOGGLE instruction. At all other times the differential driver remains in its bal-
anced (normal) mode of operation. The way unbalanced differential drivers are used
during test is discussed in Sect. 10.9.
356 10 IEEE 1149.8.1: Passive Components

Differential Driver with 2.775v

2.250v Neg 0.525v
Unbalance Capability

Voltage (Data = 0)
2.175v
Pos 1.125v
1.05v

Current Select

Time
Pos

Neg
2.775v Pos
Data 2.250v 0.525v
Voltage (Data = 1) 2.175v
Neg 1.125v
IS Current 1.05v
Source
Current IS=6, 12ma Current Select
Select 0,1
Time
Unbal

Fig. 10.7 A differential driver with unbalanced signal capability

10.8 Selective Toggle Pin I/O Cell Design

This section reviews the design of Boundary-Scan I/O cell designs, as modification
of conventional cell designs such as found in Sects. 2.6.3 and 2.6.4. These modifica-
tions add the toggle capabilities for ST-Pins, and also assure that ST-Pins can par-
ticipate in interconnection shorts testing, that is, outputs are self-monitoring. The
self-monitoring property is not mandated by the 1149.8.1 standard, but is (here)
considered too valuable not to implement. While it is only recommended, not man-
dated by the standard, it was felt by the standard’s authors to be a feature that could
be dispensed with if the IC designers might otherwise omit toggling behavior on a
given pin for technical or cost reasons.

10.8.1 Single-Ended Output Pins

Single-ended output pins are considered first. The Boundary-Scan register cell
design is based on the BC_10 design of 1149.1 (see Sect. 2.6.4 on page 104), which
supports the self-monitoring concept. Such a cell, when executing EXTEST-based
interconnection tests, is capable of detecting shorts from its pin other pins, or power/
ground rails. This is important since the reason this pin has been designated as an
ST-Pin is there may not be any other Boundary-Scan pin on its board node that
could monitor the node’s state. For example, if the pin was connected only to a
10.8 Selective Toggle Pin I/O Cell Design 357

vacant connector on the board, that pathway would not be testable for shorts
without the self-monitoring property.
The cell design, which is called ST_10 here, is derived from the BC_10 provided
by the 1149.1 standard. Note, the 1149.8.1 standard did not document an ST_10 cell
in its BSDL specification, because, from the standpoint of BSDL, it was identical to
the BC_10 cell, in terms of its capture behavior.18 As will become clear next, there
are some significant circuitry additions that do make the ST_10 unique, and an IC
vendor (or design tool vendor) can choose to offer their own cell design with a
unique name, if they so choose.
A potential design of ST_10 is shown in Fig. 10.8. Note that there are some new
control signals needed to drive its toggle behavior, and these are broadcast from an
area near the TAP, to all the ST-Pins. These signals, called “ToggleData” and
“T-UpdateDR” are also shown in the diagram and are implemented once per IC, not
once per pin.

ST_10 Self-Monitoring
Output Data Cell
Shift Out
M2 Output
From G
Driver
System 0

Circuitry
1

Update Capture M1
M3 G
G Reg Reg 0
0 Q D Q D Input
1 Buffer
CK CK
1 C
Shift In
M od e ClockDR ShiftDR
Located near pins
ToggleData Shared resources located
T-UpdateDR near TAP

B D Q A
RTI-State
Instruction Mode
Toggle-Clk CK TogHold
BYPASS 0
UpdateDR
Test-Logic/Reset SAMPLE, PRELOAD 0
EXTEST 1
RTI-State is ‘1’ when TAP is in the Run-Test/Idle state. SELECTIVE_TOGGLE 1
TogHold is ‘1’ when SELECTIVE_TOGGLE is effective.
Toggle-Clk signal comes from TCK divider subsystem. ST_10Cell

Fig. 10.8 An “ST_10” design for a self-monitoring output pin adapted from BC_10

18
This decision is discussed in Sect. 8.3 of the 1149.8.1-2012 document.
358 10 IEEE 1149.8.1: Passive Components

The actual cell design (shown in the dotted-line box) is very similar to BC_10, but
contains an additional multiplexor M3 and a new exclusive-OR gate C. The M3
multiplexor chooses one of two signals to pass on towards the pin driver. The choice
between these two is determined by the content of the Capture flip-flop. If that con-
tent is ‘0’, then the content of the Update flip-flop is passed toward the driver, which
is what BC_10 does. But if the Capture value is ‘1’, then the output of gate C is
passed on. Gate C exclusive-ORs the Update register content with the ToggleData
signal, which is a divided version of TCK. When ToggleData is ‘0’, then the Update
data is passed on. When ToggleData is ‘1’, then an inverted version of the Update
content is passed to the pin driver. The ToggleData signal is derived from the Toggle_
Control register (see Sect. 10.6) which determines the toggle frequency ultimately
seen at the pin’s driver. The ToggleData flip-flop in the figure only changes state with
the rising edge of Toggle-Clk, and when the TAP is in the Run-Test/Idle state. This
is determined by AND gate B. Note that ToggleData will be ‘0’ when the TAP leaves
the Run-Test/Idle state, by virtue of gate B and the generation of Toggle-­Clk. This
ensures that exclusive-OR gate C does not see a ‘1’ when we are (for example) shift-
ing new data through the Capture flip-flops during a PRELOAD sequence
The T-UpdateDR signal is simply the normal UpdateDR signal gated (by AND
gate A) to suppress updating the Update flip-flop when the SELECTIVE_TOGGLE
instruction is the effective instruction. Thus, when a ST-pin is being toggled, the
Update flip-flop is never updated and it continues to hold the preloaded data through-
out toggle testing. This way, an ST-pin has a start state determined by the Update
flip-flop, and this start state is returned after a toggle sequence is finished.

10.8.2 Single-Ended Input Pins

Single-ended input pins that are to be converted from normal to ST status, must are
given significant new capabilities; namely the ability to drive out from the pin such that
holding a state and toggling are supported. This also implies the ability to enable/disable
the drive capability under the control of an output drive control cell. This control cell
may, at the discretion of the device designer, may be shared, but sharing should be mini-
mized whenever possible, to give test generation fewer constraints to deal with.
Adding a driver that supports both EXTEST and SELECTIVE_TOGGLE means
adding much of the circuitry seen in Fig. 10.8. It is instructive to look at two single-­
ended input pin situations. First, there is a single-ended input with a bare-bones
minimum observe-only boundary register cell observing it. The second is a full
control-and-observe boundary register cell. These are shown in parts a and c in
Fig. 10.9. Then in parts b and d respectively of the same figure, design modifications
are shown to make these normal inputs behave as ST-pins.
The observe-only case in part a is modified (see part b) to add a driver that
can be disabled by an added BC_2 control cell (marked with a “*” character).
The observe-only cell has an update stage added (marked with the “†” character) to
give it control-and-observe capability over the pin. This cell would also contain the
capabilities shown in Fig. 10.8 so that is can support SELECTIVE_TOGGLE. The
10.8 Selective Toggle Pin I/O Cell Design 359

ST_inputs

*
C U
System System
Logic Logic

C † BC_2 Cell
BC_4 Cell U C

A) Normal input pin with simple B) ST-pin input pin with added driver,
observe-only cell. update stage* and output enable cell † .

BC_1 Cell BC_1 Cell

C U C U
System System
Logic Logic

*
U C

†
U C
BC_2 Cell

C) Normal input pin with control- D) ST-pin input pin with added driver,
and-observe cell. drive cell* and output enable cell †.

Fig. 10.9 Normal input pins and options for converting to ST-pins

BC_2 cell shows its input capturing a ‘0’ by being connected to ground. This is an
option that could be changed (to ‘1’ or “UPD”) at the whim of the device designer.
This cell does not actually monitor any system signal.
The full control-and-observe input pin shown in part c can be modified to the
design shown in part d. Here, a driver and a new data cell (marked with “*”) is
added. A new control cell (marked with “†”) is added to control the newly added
driver. This is a classic three-cell bidirectional first seen in Fig. 1.8 on page 24,
except that the data cell (“*”) also contains capabilities to support SELECTIVE_
TOGGLE, again as seen in Fig. 10.8.
It is certainly true that converting a normal single-ended input pin adds some
circuitry and complexity to the silicon. It is fortunate that we are not nearly as con-
cerned with transistor counts today as we were in (say) 1990 when Boundary-Scan
first came about, thanks to Moore’s Law.
360 10 IEEE 1149.8.1: Passive Components

10.8.3 Single-Ended Bidirectional Pins

Since single-ended bidirectional ST-pins already have the ability to observe and
control their connected net on the board, they are only required to be able to drive
their net the same as for single-ended outputs (see Sect. 10.8.1). This means they
already have the ability to participate in standard shorts testing algorithms, which
single-ended outputs may not have if they are not given self-monitor capability. The
cell design in Fig. 10.8 will suffice.

10.8.4 Differential Output Pins

Differential output ST-pins differ in a key respect from single-ended output ST-pins:
they have two operational modes. These are balanced and unbalanced operation. As
seen in Sect. 10.7, this can be summarized by thinking of a differential driver as hav-
ing a data input, and a new “current select” input. To view this, consider the symbols
shown in Fig. 10.10. The differential driver is shown (at the top of the figure) with a
new “current select” input. It may or may not have a tri-state enable input that would
be fed from a control cell in the boundary register. The data line and current select
signals would also come from a boundary register cell such as shown at the bottom of
the figure. The two tables in Fig. 10.10 show how the two operational modes, bal-
anced and unbalanced, are achieved. For balanced mode, the current select line
remains fixed at 0 while the data is active, causing classic differential (complemen-
tary) outputs on the positive and negative legs. For unbalanced mode, the data line is
fixed at 0 while the current select line is active, causing the sum of the voltages on the
two legs19 to move in the same direction as the current select line when current select
changes. This provides a signal that a capacitive sense plate can observe.
Figure 10.11 depicts a device with three differential output pairs that are always
active, and two other differential output pairs that can be disabled. All five of these
differential drivers can be unbalanced, and the “Unbalance” cell in the figure is used
to govern this; when loaded with a “0”, the drivers behave in their normal, balanced
fashion. When the unbalance cell is loaded with a “1”, then the drivers, in response
to SELECTIVE_TOGGLE, will drive in an unbalanced mode. This means that both
outputs of a given unbalanced driver will have the sum of their output voltages move
higher in response to the data cell having a “1” loaded, and the sum of their voltages
will move lower in response to the data cell having a “0” loaded.

19
In the example differential driver shown in Fig. 10.7, both legs move in the same direction, but
the standard allows for them to move in opposite directions as long as the sum of the two voltages
behave as stated.
10.8 Selective Toggle Pin I/O Cell Design 361

Enable (optional)
Pos Leg
Data
Neg Leg
Current Select

Current Select fixed at 0

Balanced Differential Mode
Pos Leg = 0
0 Neg Leg = 1
Data
Pos Leg = 1
1 Neg Leg = 0

Data fixed at 0
Unbalanced Differential Mode
Sum of positive and
0 negative leg
voltages lower
Current Select
Sum of positive and
1 negative leg
voltages higher

SO

PI C U PO (to Data)
Current Select
Cell symbol for
Differential ST-pin
SI Unbalance
Diff Symb

Fig. 10.10 Symbols used to depict differential drivers and their related boundary register cells

A familiar control cell (labeled “Enable”) is used by two of the drivers to disable
their outputs; if these drivers are disabled then being balanced or unbalanced will
not matter to what is detected—that is, no signal change would be detected by a
capacitive sense plate.
As is the case with control cells, the unbalance signal can originate in one bound-
ary register cell, or several may be used. This allows an IC designer some flexibility
to locate unbalance cells near to the cells they will be connected to, to alleviate
potential layout difficulties.
A possible design for a differential output ST-pin pair is shown in Fig. 10.12.
This design implements the ability to observe the differential pair (see the added
“special receiver”) which allows this pin pair to participate in shorts testing.
This capability is not mandated by the standard however, so IC designers may opt
362 10 IEEE 1149.8.1: Passive Components

Diff Use

TDO

C U

C U

C U
System
Logic
C U Unbalance Unbalance Cell
(‘Internal’ in BSDL)

C U

C U Control Cell
(optional)

C U Enable

TDI

Fig. 10.11 Differential outputs with ST-pin modifications

to omit it. As before when receive capability is added for shorts testing, the added
resource does not need to be an aggressive functional design, but rather just enough
to observe (at low speeds) if the pins are behaving independently. This can reduce
its cost and design requirements significantly.
Note the controlling circuitry near the bottom of Fig. 10.12 is identical to that
seen for single-ended outputs seen in Fig. 10.8. Again, this circuitry can be shared
among many ST-pins.
The standard gives design details for a slightly simpler cell that can control a
differential pair of outputs with no receiver capability and as such, cannot partici-
pate in shorts testing. This eliminates a significant amount of test coverage, which
should be considered in the negotiations for which pins are designated as ST-pins
and how much capability they are given.
10.8 Selective Toggle Pin I/O Cell Design 363

Unbalance (from internal Breg cell) Self-Monitoring Differential

0 = Balanced, 1 = Unbalanced Output Data Cell

Current Select
E
Shift Out Enable
M2 Output
From G
Driver
System 0
Circuitry
D 1

Update Capture M1
M3 G
G Reg Reg 0
0 Q D Q D Special
1 Receiver
CK CK
1 C
Shift In
Mode ClockDR ShiftDR
Located near pins
ToggleData Shared resources located
T-UpdateDR near TAP

B D Q A
RTI-State
Instruction Mode
Toggle-Clk CK TogHold
BYPASS 0
UpdateDR
Test-Logic/Reset SAMPLE, PRELOAD 0
EXTEST 1
RTI-State is ‘1’ when TAP is in the Run-Test/Idle state. SELECTIVE_TOGGLE 1
TogHold is ‘1’ when SELECTIVE_TOGGLE is effective.
Toggle-Clk signal comes from TCK divider subsystem. DiffDCell

Fig. 10.12 A fully capable boundary cell design for differential outputs

10.8.5 Differential Input Pins

Just as was the case with single-ended inputs (seen in Sect. 10.8.2), converting a
differential input pin pair requires the addition of a differential driver and some new
cells to manage it. As before, this differential driver need not have exotic (expen-
sive) capability, it just needs to be able to (slowly) drive states onto the pin pair.
Note, it will need the balanced and unbalanced capability, just as was needed for
differential drivers seen in Sect. 10.8.4. This is summarized in Fig. 10.13, for two
cases. In part a is the case where the differential input pair was monitored by a
simple observe only cell. In part c is the case where the input pair connected to a
control-and-observe cell.
364 10 IEEE 1149.8.1: Passive Components

ST_DiffIns

*
C U
System System
Logic Logic

C †
BC_4 Cell U C
BC_2 Cell
from Unbalance Cell
A) Normal input pin pair with simple B) ST-pin input pin pair with added driver,
observe-only cell. update stage* and output enable cell † .

BC_1 Cell BC_1 Cell

C U C U
System System
Logic Logic

*
U C

†
U C
BC_2 Cell
from Unbalance Cell
C) Normal input pin pair with D) ST-pin input pin pair with added driver,
control-and-observe cell. drive cell* and output enable cell †.

Fig. 10.13 Modifications for differential input ST-pins

Parts b and d of this figure show the added differential driver (with balance and
unbalance control), an added driver enable cell marked with a “†” character, and a
driver cell (with a balance and unbalance output) marked with a “*” character. In
normal mode of operation, the added differential driver is always disabled, since it
is not part of the original functionality of the device.

10.8.6 Differential Bidirectional Pins

In the case where a differential pin pair is bidirectional, then the receiver and driver,
plus a driver enable structure are already in place. The circuitry must be modified to
provide for balancing and unbalancing, so the result will look like that seen in
Fig. 10.13d.
10.9 Testing with 1149.8.1 Resources 365

10.9 Testing with 1149.8.1 Resources

Section 3.2 (beginning on page 128) discussed several types of testing based on the
use of Boundary-Scan chains. Each was focused on some class of defects20 such as
interconnection shorts, interconnection opens, interactions between Boundary-
Scan nets and non-scan nets, etc. Testing with 1149.8.1 resources should be
focused on finding opens and shorts among nets connected to passive (or non-
scannable) devices. The classic example is for finding such defects on passive,
vacant connectors21 that are wired to Boundary-Scan devices. These devices are
then inspected for their pins that are providing this connectivity and these are then
candidates for becoming ST-pins. As stated before, IC designers often know well
in advance of completing their IC design how an IC may be used, although board
designers are often involved in such discussions. They should negotiate the list of
ST-pins at this stage.
The board-level coverage improvement offered by capacitive sensing, as sup-
ported by the resources provided by 1149.8.1 can be quite valuable. Thus, a new
phase of testing using capacitive sensing can be added to the overall suite of
Boundary-Scan chain tests. It is probable that such testing will itself be broken
into smaller units, with a given unit focused on some target device, such as a
vacant connector. This reflects how capacitive sensing may have to use multiple
sense plates, for example, one per connector in a group of connectors. To continue
this example, imagine four vacant connectors that will ultimately be populated
with memory daughter boards. The associated Boundary-Scan devices will have
nets that fan to each connector, so separate capacitive sense plates are needed to
observe just one connector at a time, even though all four are stimulated in paral-
lel. This allows us to locate the precise location of an open pin among the four
connectors. If there is an instance of several target devices located in close prox-
imity but with distinct nets connecting them to 1149.8.1 resources, then a single
sense plate could be located over these devices and they could be tested together.
In such case, knowing which 1149.8.1 device is toggling which pin gives us
­precise diagnostic information.

20
There is often overlapping coverage among these types of test. It is usually true that some defects
that are not the principal focus of a test are also detected, but perhaps with less diagnostic resolu-
tion. Thus, running several tests may detect the same defect multiple times, with some giving
better diagnostic results than others.
21
Another common situation is for such Boundary-Scan devices to be connected to non-scannable
devices—for example, bulk memory devices such as DRAM. In many cases, these non-scan
devices can be tested with capacitive sensing and are thus candidates for testing using 1149.8.1 in
the companion Boundary-Scan devices.
366 10 IEEE 1149.8.1: Passive Components

10.9.1 Testing Single-Ended Pins

When a target device has single-ended connections to some device(s) equipped with
1149.8.1, then capacitive sense testing proceeds as follows. First, a background pat-
tern of data for the Boundary-Scan device chain is calculated. This pattern takes into
account that a board may need to be properly initialized and certain nodes fixed at
particular static “0” or “1” states in order to keep the board quiescent and otherwise
“happy” with the testing about to commence. In many cases, nets will not need to
be held at all, but will also not be directly involved in the test either (for example,
normal pins) and these can be assigned arbitrary hold states. It is advisable that only
the ST-pins required for a given test be identified, and all the rest kept quiescent for
the duration of a given test, to reduce overall noise.
Once the background pattern is calculated and the required ST-pins are identi-
fied, then testing commences by loading the background pattern into the chain using
PRELOAD in all the needed devices. Once in place, then each device in the chain is
loaded with EXTEST or SELECTIVE_TOGGLE as needed. Those with EXTEST
will continue to hold the background pattern, as this will be continually re-loaded
for each update cycle. Those with SELECTIVE_TOGGLE will also load the back-
ground pattern for its normal pins. But for the ST-pins used in the test, they will
(typically) be loaded with all zeroes, except for one ST-pin that is loaded with a “1”.
This will be the pin that is selected to toggle.
The selected pin will toggle at a frequency that is determined by the TCK fre-
quency, as divided by the number stored in the Toggle_Control register (see
Sect. 10.6). This is set up during the initialization stage before testing begins. The
toggle frequency and duration of toggling is determined by the requirements of the
capacitive sensing system. It is possible that the sensing system needs a string of
many toggles, or it may only require two toggles (a pulse) to occur. Since toggling
starts from the initial state set up during PRELOAD, some sensors may also have a
requirement on this state if they take into account phase information during signal
detection. The test tool that runs all of this will be in charge of such details.
The test then iterates down the list of ST-pins involved for the device under test.
Each is selected for toggling, and the toggling proceeds until the capacitive sense
system has collected the data needed to determine if an open is present. Note, if a
short of a given net exists to some other net, that can also show up as a bad measure-
ment. Shorts can be tested using the standard interconnect test which would be run
earlier in the sequence of overall testing. This is why it is desirable to give ST-pins
the ability to observe their action—to discover shorts in this more direct way.
The test completes by sending the chain into the Test-Logic-Reset state, which
removes the EXTEST and SELECTIVE_TOGGLE instructions. This does recon-
nect the I/O pins of all chained devices back to their internal system logic, and the
effects of this must be accounted for.
Another item to note is that capacitive sense plate measurements are analog and
may require several iterations (per pin) to gain a reliable reading. Indeed, part of
test preparation will be to run each pin and accumulate measurement statistics.
10.10 BSDL Extensions for 1149.8.1 367

The average measurement value is recorded, and then standard deviation analysis is
performed to see if the measurements are stable enough to set appropriate pass/fail
limits on the measurement value. This statistical process during test development is
best accomplished using a known-good board, or set of boards, and the test tool will
be in charge of this process as well.

10.9.2 Testing Differential Pins

Testing of differential pin pairs is more complex, because we have pairs of pins
controlled by a single cell the boundary register. In the balanced mode (see
Sect. 10.7) of operation, a pin pair will toggle with nearly perfectly complementary
waveforms, and thus be nearly invisible to the capacitive sense plate. Thus, for a
defect-free pin pair, we see no signal and cannot set up pass/fail limits. Worse, if
we simply guess at some limits and then run a test, then certain defects will also
produce no signal, and we cannot detect them. For example, if both pin have open
connections, or, are shorted together, then we may not see any signal.
This problem is attacked by running the test with the drivers in balanced mode
first. If one pin of a pin pair is open, then the sense plate will see an unexpected
signal, of either an in-phase or out-of-phase polarity depending on which of the
two legs (positive or negative) is open. This is good, but, how do we know if both
pins are open?
This is solved by running the test a second time, with the drivers set into unbal-
anced mode of operation. In this mode, the sum of voltages on the selected pin pair
will move up/down in concert with the pin pair toggling. Thus, a defect-free pair will
be seen by the sense plate and we can use this to characterize pass/fail limits. If there
is an open on both pins, then the sense plate will see an attenuated signal. If there is
short across the two pins, then this will not be sensed—which again is why we desire
ST-pins to have observation capability.
The test is essentially run two times, once iterating through the list of differential
ST-pins with the device(s) in balanced mode, and then again, with the unbalance
mode. Post-test results are then analyzed to determine what defects might be present.

10.10 BSDL Extensions for 1149.8.1

An 1149.8.1 device is (again) quite similar to an ordinary 1149.1 device because the
Working took pains to carefully build the new standard atop the foundation stan-
dard. This is evident in a BSDL description for an 1149.8.1 device. Essentially,
some new instructions (TOGGLE_SETUP and SELECTIVE_TOGGLE) have to be
documented, the Toggle Control register, the ST-pins and some new Boundary
Register cells have to be identified. It is intended that an 1149.8.1 device could also
support (say) 1149.6, so a BSDL file for describing such a device would have both
368 10 IEEE 1149.8.1: Passive Components

the 1149.6 and 1149.8.1 extensions referenced. Indeed, the 1149.8.1 standard (in
Annex B) shows a Boundary register cell design that will support both standards.
The additional information needed to describe an 1149.8.1 device is contained in
a BSDL extension (see Sect. 2.3.16). BSDL extensions are used to describe new
attributes beyond the 1149.1 BSDL definition. The 1149.8.1 standard codifies an
official extension for its descriptive purposes within a VHDL package (see Sect.
2.6) called STD_1149_8_1_. This package is reproduced in Sect. 10.10.2. It is
expected to reside in a “read-only” area of a test system file space, most likely co-
resident with the 1149.1 package STD_1149_1_2001. As always, the intent of
BSDL extensions is to encode information in such a way that application software
that doesn’t know about the use of the extension is still able to read the BSDL file
and perform activities with the 1149.1 implementation.

10.10.1 Boundary Registers Cells for 1149.8.1

The 1149.8.1 standard pre-defines just two Boundary Register cells. These are used
as “Unbalance” and are shown in Fig. 10.14.
Unbalance are coded in the Boundary Register description (see Sect. 2.3.13) as
“Internal” cells. These two cells, ST_UnbalX and ST_UnbalU are similar, differing
in what they capture on the rising edge of TCK in the state. The ST_UnbalX cell
captures an unknown value (actually, the state of its “Shift In” line which is not

Shift Out

Shift In Unbalance
C U
CK CK
ST_UnbalX
Clock-DR Update-DR cell

Shift Out
0
Unbalance
1 C U
CK CK
Shift In ST_UnbalU
Clock-DR Update-DR cell
Shift-DR
ST_Unbal

Fig. 10.14 Two “Unbalance” cell designs

10.10 BSDL Extensions for 1149.8.1 369

known). The ST_UnbalU cell captures the state of its Update flip-flop. This can
improve the testability of that portion of logic for production test22 purposes.
Cells used for driving or receiving on pins are standard BC designs, in that their
capture behavior is the same as those used in standard 1149.1. Of course, their inter-
nal design details are different, in order to support the SELECTIVE_TOGGLE
instruction, as is seen in Sect. 10.8).

10.10.2 STD_1149_8_1_2012

The content of STD_1149_8_1_2-12 is given below. A “use” statement should

appear in the BSDL description for an 1149.8.1 device directly following the stan-
dard use statement (see Sects. 2.3.3 and 2.3.4, and the example in Sect. 10.10.5).
That portion of the device BSDL description would look like this:

     …
use STD_1149_1_2001.all; -- Standard ‘use’ statement
use STD_1149_8_1_2012.all; -- BSDL Extension for Selective Toggle
     …

The 1149.8.1 package defines the extension attributes, and also gives the cell
descriptions for ST Boundary Register cells (see Sect. 10.10.1).

Package STD_1149_8_1_2012 is -- Attribute definitions for ST

  use STD_1149_1_2001.all; -- Refer to BSDL definitions
  constant ST_ : Cell_Info; -- Unbalance-X
  constant ST_ : Cell_Info; -- Unbalance-U

  attribute ST_Component_Conformance:    BSDL_Extension;
  attribute ST_Pin_Behavior:        BSDL_Extension;
end STD_1149_8_1_2012;

Package Body STD_1149_8_1_2012 is

  use STD_1149_1_2001.all; -- Refer to BSDL definitions

constant : Cell_Info:= -- Captures ‘X’, unknown data

((INTERNAL, SAMPLE, X),
(INTERNAL, INTEST, X),
(INTERNAL, EXTEST, X));
constant : Cell_Info:= -- Captures ‘UPD’, Update FF
((INTERNAL, SAMPLE, UPD),

22
If the IC is built with its own internal scan capability as allowed by 1149.1 (see Sect. 1.7) then
this additional circuitry may be unnecessary.
370 10 IEEE 1149.8.1: Passive Components

(INTERNAL, INTEST, UPD),

(INTERNAL, EXTEST, UPD));
end STD_1149_8_1_2012;

10.10.3 Selective Toggle Keywords

The selective toggle extension requires additional keywords. These are:

  Selective_Toggle        ST_Pin_Behavior
  ST_Unbal                ST_Swing
  ST_UnbalX                    ST_1149_8_1_2012
  ST_UnbalU                    Toggle_Control
  ST_Component_Conformance    Toggle_Setup

Thus when coding BSDL for a device with 1149.8.1, these words cannot be used
for port names and such.

10.10.4 BSDL Extension Syntax

The selective toggle extension syntax defines two attributes. They are ST_Component_
Conformance and ST_Pin_Behavior. The syntax for the first is simple:

<ST component conformance statement> ::=

attribute ST_Component_Conformance of <component name> : entity is
<ST conformance string>;
<ST conformance string> ::= “ <ST conformance identification> “
<ST conformance identification> ::= STD_1149_8_1_2012

There is only one value for the conformance identification, but new ones are
added when the standard is updated.
The second attribute, ST_Pin_Behavior, is more detailed; it allows the identifica-
tion of ST pins and their characteristics. The syntax is:

<ST pin behavior statement> ::=

attribute ST_Pin_Behavior of <component name> : entity is
<ST pin behavior string> ;
<ST pin behavior string> ::=
“ <ST pin behavior spec> { ; <ST pin behavior spec> } “
<ST pin behavior spec> ::= <signal list> : <behavior spec>
<signal list> ::= <signal spec> {, <signal spec> }
10.10 BSDL Extensions for 1149.8.1 371

<signal spec> ::= <port name> | <subscripted port name>

<behavior spec> ::= [ <unbalance spec> ,] <swing spec>
<unbalance spec> ::= ST_Unbal = <cell number>
<swing spec> ::= ST_Swing = ( <voltage deltas> )
<voltage deltas> ::= <minimum swing> , <maximum swing> [ variable ]
<minimum swing> ::= <real number>
<maximum swing> ::= <real number>

Here are some quick examples of some device pins that have been given 1149.8.1
capabilities. First, consider some simple single-ended pins with individual (i.e., bit)
port names SEA, SEB and SEC. They could be of types output, inout or buffer, and
have a small voltage swing variation. Next, consider an output bus (i.e., bit_vector)
with port name “Address”. These pins have a rather large voltage swing between 1.0
and 3.5 V as determined by the voltage applied to the device’s VDD pin. Then,
consider a set of differential ports labeled DiffA and DiffB. (These are the positive
legs only, as the negative legs are assumed to have the same characteristics.) These
also are driven with a larger possible voltage swing as it depends on the values of
VDD connected to the device. Finally, there are some differential bidirectionals
Bidi(1) and Bidi(2) which have a minimal swing. These could all be coded with the
same pin behavior statement like so:

attribute ST_Pin_Behavior of ST_DEV:entity is

“SEA, SEB, SEC: ST_Swing=(1.9, 2.0);” & --single ended
“Address: ST_Swing=(1.0, 3.5 Variable);” &
-- SE_Address members swing between 1.0 and
-- 3.5 volts depending on the voltage on VDD.
“DiffA: ST_Unbal=11, ST_Swing=(1.2, 3.5 Variable);”&
--Unbalanced from cell 11, with
--swing which depends on VDD. Positive pin.
“Bidi(0): ST_Unbal=7, ST_Swing=(0.7, 0.8) “;
-- Unbalanced from cell 7,
-- voltage swing between 0.7 and 0.8 volts
-- Positive pin

The differential pins have unbalancing controlled by cells 11 and 7. These would
be internal cells in the Boundary register description and would have cell names of
ST_UnbalX or ST_UnbalU. Note that there is no limit on how many differential
pins could be unbalanced from a single cell. The “variable” keyword seen in places
where the voltage swing is high (in this case due to being a function of the VDD
voltage) is used to flag such pins so if a test engineer is having problems with getting
a test to work properly, he can be flagged about how some pins might have incom-
patible voltages which could be the cause of debugging issues.
The next section gives an abbreviated BSDL description of a simple device that
contains the above pins to point out where the changes/additions are found.
372 10 IEEE 1149.8.1: Passive Components

10.10.5 Example 1149.8.1 BSDL

entity ST_DEV is
generic (PHYSICAL_PIN_MAP : string := “DIP40”);
-- Logical Port Description
port (TDI : in bit; TMS : in bit;
TCK : in bit; TDO : out bit;
A : in bit; -- Normal port
B : out bit; -- Normal port
. . .
Address : out bit_vector(0 to 5); --ST port
SEA : out bit; --ST port
SEB : out bit; --ST port
SEC : out bit; --ST port
DiffA : buffer bit; -- Differential ST port
DiffB : buffer bit; -- Differential ST port
Bidi : inout bit_vector(0 to 1); --Diff ST
. . .
GND : linkage bit_vector(1 TO 10);
VDD : linkage bit_vector(1 TO 7) );

-- Use Statements
use STD_1149_1_2001.all;
use STD_1149_8_1_.all;

-- Component Conformance Statement

attribute COMPONENT_CONFORMANCE of ST_DEV : entity is
“STD_1149_1_2001”; -- Conforms to 1149.1-2001

-- Device Package Pin Mappings

attribute PIN_MAP of ST_DEV : entity is PHYSICAL_PIN_MAP;
constant DIP32:PIN_MAP_STRING :=
“ TDI : P1, TMS : P14,” &
“ TCK : P15, TDO : P13,” &
“ A : P7,” &
“ B : P6,” &
. . .
“ Address : (P4, P3, P2, P8, P9, P10),” &
“ SEA : P11,” &
“ SEB : P12,” &
“ SEC : P28,” &
“ DiffA : P33,” &
“ DiffB : P34,” &
“ Bidi(0) : P35,” &
10.10 BSDL Extensions for 1149.8.1 373

“ Bidi(1) : P36,” &

. . .
“ GND : (P16, P17, P18, P19, P20, “ &
“ P28, P29, P30, P31, P32),” &
“ VDD : (P21, P22, P23, P24, P25, “ &
“ P26, P27)” ;

-- Grouped Port Identification

attribute PORT_GROUPING of ST_DEV: entity is
“DIFFERENTIAL_VOLTAGE (“ &
“(DiffA, DiffB), “ &
“(Bidi(0), Bidi(1)) )” ;

-- Scan Port Identification

attribute TAP_SCAN_CLOCK of TCK : signal is (20.0e6, BOTH);
attribute TAP_SCAN_IN of TDI : signal is true;
attribute TAP_SCAN_MODE of TMS : signal is true;
attribute TAP_SCAN_OUT of TDO : signal is true;

-- Instruction Register Description

attribute INSTRUCTION_LENGTH of ST_DEV: entity is 4;
attribute INSTRUCTION_OPCODE of ST_DEV: entity is
-- IEEE Std 1149.1, BYPASS gets all unused codes
“EXTEST (0001),” &
“SAMPLE (0010),” &
“PRELOAD (0011),” &
“CLAMP (0100),” &
“HIGHZ (0101),” &
-- IEEE Std 1149.8.1
“TOGGLE_SETUP (0110),” &
“SELECTIVE_TOGGLE (0111)” ;
attribute INSTRUCTION_CAPTURE of ST_DEV:entity is “1101”;

-- Register Access Description

attribute REGISTER_ACCESS of ST_DEV: entity is
“BOUNDARY (SELECTIVE_TOGGLE),” &
“TOGGLE_CONTROL[15] (TOGGLE_SETUP)”; --15 bit divisor

-- Boundary-Scan Register Description

attribute BOUNDARY_LENGTH of ST_DEV : entity is 17;
attribute BOUNDARY_REGISTER of ST_DEV : entity is
“16 (BC_1, A, INPUT, X),” &
“15 (BC_1, SEA, OUTPUT2, 0),” &
“14 (BC_1, SEB, OUTPUT2, 0),” &
“13 (BC_1, SEC, OUTPUT2, 0),” &
374 10 IEEE 1149.8.1: Passive Components

. . .
“11 (ST_UnbalU, *, INTERNAL, 0),” &
“10 (BC_1, DiffA, OUTPUT2, 0),” &
“ 9 (BC_1, Address(0), OUTPUT2, 0),” &
“ 8 (BC_1, Address(1), OUTPUT2, 0),” &
“ 7 (ST_UnbalU, *, INTERNAL, 0),” &
“ 6 (BC_1, Address(2), OUTPUT2, 0),” &
“ 5 (BC_1, Address(3), OUTPUT2, 0),” &
“ 4 (BC_1, *, CONTROL, 1),” &
“ 3 (BC_1, Address(4), OUTPUT2, 0),” &
“ 2 (BC_1, Address(5), OUTPUT2, 0),” &
. . .
“ 0 (BC_1, Bidi(0), BIDIR, X, 4, 1, Z)” ;

-- 1149.8.1 Selective Toggle Description

attribute AIO_COMPONENT_CONFORMANCE of ST_DEV : entity is
“STD_1149_8_1_2012”; -- 1149.8.1 conformance

attribute ST_Pin_Behavior of ST_DEV : entity is

“SEA, SEB, SEC: ST_Swing=(1.9, 2.0);” &
“Address: ST_Swing=(1.0, 3.5 Variable);” &
“DiffA: ST_Unbal=11, ST_Swing=(1.2, 3.5 Variable);”&
“Bidi(0): ST_Unbal=7, ST_Swing=(0.7, 0.8) “;

end ST_DEV;

10.11 Design for IEEE 1149.8.1 Testability

At the time of writing this edition, we do not have an official 1149.8.1 device in
hand. There are some experimental devices (see [Dubb08]) that have given us some
early experience. The DFT rules given below are partly derived from experience
and from expectation.

10.11.1 Integrated Circuit Level DFT

As stated several times in this chapter, the best time to add 1149.8.1 features into an
IC are during its design, when the user community building boards can participate
in the enumeration of ST-pins from the list of normal pins. The first, most obvious
candidates are IC pins that are expected to be routed on a board to passive devices
such as vacant connectors. The classic example is from a memory controller IC to a
set of connectors that ultimately will hold daughter boards contain memories. Since
10.11 Design for IEEE 1149.8.1 Testability 375

most manufacturing board test will be done before these daughter boards are popu-
lated, this is an ideal time to consider capacitive sensing, with the sense plates
mounted above the memory connectors in the manufacturing tester’s fixturing.
• DFT-47: Consider adding 1149.8.1 resources to IC pins that will ultimately
be connected to pins on passive devices such as connectors.
Other candidates for ST-pins are those on an IC that will be routed to other ICs
that do not contain any 1149.x testability. A classic example of these devices are
DRAM devices, which almost never contain additional testability features. Many
(though not all) DRAMs are amenable to capacitive sensing test approaches.
• DFT-48: Consider adding 1149.8.1 resources to IC pins that will be con-
nected to IC that do not implement testability features.
The 1149.8.1 standard recommends, but does not mandate that IC inputs equipped
with 1149.8.1 capability also have the ability to monitor pin states during
EXTEST. This means testing for shorts in compromised, and while a short may show
up during capacitive sensing, this is not certain, and some diagnostic resolution may
be lost, that is, an open may be signaled when in reality a short is the actual defect.
• DFT-49: Consider adding monitor capabilities to input ST-pins to support
accurate testing for shorts.

10.11.2 Board-Level DFT

Resources added by 1149.8.1 can add a lot of test coverage in areas that might oth-
erwise be chronically undertested. For example, an array of six memory connectors,
each with over 100 single-ended and differential signals could be largely untested
without the facilities provided by 1149.8.1. Since many such connectors today are
mounted with ball-grid attachments, there is little hope of inspecting for opens,
except possibly with an X-ray laminographic test system. Such an addition to the
test requirements can be costly. The test engineer should be aware of such
opportunities.
• DFT-50: Survey boards for passive components and determine if there are
1149.8.1 resources that can be used to support capacitive sense testing.
Of course, being a proactive test engineer can help IC designers understand the
advantages of adding 1149.8.1 resources to the right pins of the right integrated
circuits.
• DFT-51: Help define IC requirements used by IC designers to get 1149.8.1
installed in the best places in upcoming IC designs.
Negotiation with the IC design team can convince them to take the additional
time and engineering if you can show how improved board coverage will ultimately
be important to all of the design teams.
376 10 IEEE 1149.8.1: Passive Components

10.12  pilog: What Next for 1149.1, 1149.4, 1149.6, 1149.8.1

E
and 1532?

To reiterate some history scattered about this book, the 1149.1 Standard came into
being as a digital standard. It essentially ignored analog signals on an IC. After
some time and a large amount of debate, thought and research, the 1149.4 Standard
proposed a method for treating analog signals. This method recognized the value of
1149.1-style interconnection tests and showed how the salient features of 1149.1
could in essence be emulated by 1149.4 such that wiring tests could be supported as
well as analog metrologies.
In the 1993 time frame, the 1149.4 Working Group was talking about how analog
metrology and 1149.1-style interconnect tests were essentially “orthogonal”, and
how an ABM could, in effect, provide independent hardware to support these two
goals. Again debate swirled for a time. Ultimately this realization was accepted
after it was shown, by actually analyzing test chip designs, that an orthogonal imple-
mentation was not much different in cost to a seemingly cheaper design that inte-
grated (i.e. encoded) control for the analog and interconnect test problems.
Around 1996, Lee Whetsel proposed that the 1149.1 Working Group consider
extracting the interconnect test capability for analog wiring supported by 1149.4
and merge it back into 1149.1.23 This would take the “analog blinders” off of 1149.1.
Then by coordinating 1149.4 with this change in direction, ultimately 1149.4 would
become a true “analog” standard rather than one that “fixed up” 1149.1. However,
this move never gained momentum.
While this was going on, the PLD industry was beginning its emergence as a
factor in the industry. A big change here was the desire to program devices after they
were mounted on boards. This implied some form of I/O standard. People noted that
with the demand for these devices to contain 1149.1, came a “free” I/O port that
could be used for programming. At first, they simply wanted to extract the TAP
concept from 1149.1 and leave out the rest, but their customers insisted they wanted
all of 1149.1. Testing blank devices was just too hard otherwise. The 1532 Working
Group that evolved eventually decided to adopt all of 1149.1, and build the
­programming specification on top.
In the 2000 time frame, concern suddenly sprang up about AC-coupling net-
works between ICs, and this led to the rapid development of the 1149.6 standard.
These networks were assuredly analog and an obvious candidate for testing by
1149.4. However, they seemed to form a simple class of coupling that could be
(and indeed is) testable using a spruced-up version of EXTEST and a high-speed
digital paradigm. The problem of testing arbitrary analog networks between ICs is
still best addressed by 1149.4.

This idea had been hypothesized for some time. Lee proposed the actual Boundary Register cell
23

designs within 1149.1 that could make this happen. These proposal cells were immediately called
“Whet-cells” by the two working groups.
10.12 Epilog: What Next for 1149.1, 1149.4, 1149.6, 1149.8.1 and 1532? 377

In the 2001 time frame, 1149.1 was released and put into a “maintenance mode”.
Around 2010 it was re-opened again, leading to the 2013 release, which is found in
Chap. 11 in Part 2 of this book. As you will see, the 2013 release has some rather
large implications that spread out across the industry.
The jury is still out on the long-term acceptance of the 1149.4 standard. It is not
in widespread use as of yet. One thought is that the usage of analog components is
in decline, resulting in fewer analog components on boards, and their clusters being
smaller and less complex.24 Certainly, one major use of analog parts was for damp-
ing reflections and AC coupling. However, it appears that adequate test coverage for
these applications is possible without resorting to a full 1149.4 application.
The 1532 standard will also likely evolve a bit more. One open question is how
to deal with PLD devices that have an extreme amount of programmability of I/O
pin behavior. Here the problem amounts to needing to program a device before it
can successfully communicate with its neighbors. But what if this “communication”
is actually Boundary-Scan test activity? Then we find ourselves programming a
board before it has been thoroughly tested. If an entire (large) download is needed,
this could unacceptably increase tester time. The PLD industry has yet to address
this issue. For example, could there be a “lite” version of programming that only
affects the I/O pin parameters? Could the industry agree on a rational set of default
pin parameters that avoid the problem in many cases?
Finally, the 1149.6 standard has also left an open question—that of the need for
an “INITIALIZE” instruction. This instruction would prepare a device25 for testing.
Here it is envisioned that “System-on-Chip” (SOC) devices will need some sort of
“warning” given to them so they can prepare themselves for safe and sane testing
using the Boundary-Scan facility. For example, they may have on-chip phase-lock
clocking that needs to be switched to an internal oscillator26 before EXTEST cuts
off outside communication. The concern here is that complex devices may generate
internal conflicts or other irrational behavior if not properly prepared for testing.
A prototype of this instruction was provided in the first release of the 1149.6 stan-
dard, but it is not formalized. This may happen in a later release, although it is not
yet clear that the concept belongs in 1149.6 when it might better reside somewhere
else (like 1149.127). Actually, the 1149.1 Working Group in the 1997 time frame

24
Also, some types of analog discrete components such as inductors and capacitors are becoming
very low valued, nanohenries and picofarads. These are difficult to measure on boards with any
technology.
25
Note that the ISC_ENABLE instruction in 1532 is an example of this capability. It prepares a
1532 device for programming.
26
The Agilent HDMP-2689 Quad SERDES is an example of an IC that would have benefited from
an INITIALIZE instruction had it existed. This IC must receive a system clock to condition its
phase-lock loop while testing is being conducted. This is likely to startle board test engineers who
are accustomed to shutting down all clocks while testing is done.
27
The 2013 revision of 1149.1 addresses the “Initialization” issue with three new instructions; see
Sect. 11.3.4.1 in Part 2 of this book.
378 10 IEEE 1149.8.1: Passive Components

briefly considered a “SHUTDOWN” instruction28 but it wasn’t fully appreciated at

that time what it would contribute.
One last time I urge the reader to keep up-to-date with these standards, as change
is to be expected as we learn more about testing digital, analog, mixed signal and
configurable designs.

28
Proposed by Grady Giles, then of Motorola.
 Part II
Boundary-Scan Updated

In the early 2010s time frame, it was becoming apparent that Boundary-Scan, as
then described and understood, was being hampered by technology changes that
were a threat to its continued usefulness. A simple example of this is the mobile
device we all use, which is battery powered. Such devices are extremely sensitive to
power consumption issues—we all want our phones to work longer than they do.
So, IC vendors have striven to reduce power consumption, even as the underlying
technology itself was moving in the opposite direction.
This was a problem. So, IC designs are common today with power domains
within them where significant portions of internal logic may literally be powered
down when not in use. They may be powered up for a few milliseconds, then put
back to sleep, all to conserve battery life (and reduce heating). Now it is one thing
to power down some internal logic, such as a floating point math unit buried deep
inside an IC. But in many cases, circuitry directly associated with I/O pins may also
be powered or unpowered over time. For example, a device may contain a serial data
port like USB that is not always operational. It could be powered down when not in
use. But, the classical view of Boundary-Scan is that all I/O pins are always pow-
ered. Indeed, a central tenant of classical Boundary-Scan was that a Boundary reg-
ister is always a certain length at all times. This was no longer practical, and without
some change of viewpoint, Boundary-Scan could be relegated to obsolescence. This
was not acceptable to Boundary-Scan users—it is simply too valuable to discard.
Part II of this book looks at the response to this challenge. Now there is a major
upgrade to the 1149.1 standard, released in 2013. It allows for power domains inter-
rupting a Boundary register and how to handle it. It also addresses other major tech-
nology trends as well—the 2013 version is exceptional in what it introduced and
changed. All modern devices and tools are affected. Chapter 11 covers this new
paradigm of Boundary-Scan. Subsidiary standards are also affected. The first one to
respond to this with its own revision is the 1149.6 standard revised in 2015, which is
covered in Chap. 12. I expect that other subsidiary standards will also have to adapt
over time. The “Dot6” approach will serve as a useful template for such efforts.
380 Part II Boundary-Scan Updated

Finally, Appendix B is provided which contains the formalized syntax of the

changes to BSDL that are introduced by 1149.1-2013. Much of the original BSDL
is still present (see Appendix A), but a large amount of new information can now be
described.
Chapter 11
IEEE 1149.1: The 2013 Revision

IEEE Standard 1149.1 underwent a significant revision which appeared in early

2013. Unlike other revisions past, this one reflects technology trends that are caus-
ing major problems for circuit designers, and how their designs are being negatively
impacted. The risk is that without suitable changes, the 1149.1 standard might
become obsolete, or implemented in a compromised fashion. For example, some
I/O pins might not fully comply with the standard or perhaps be omitted from any
design requirements of the standard. Obviously, this would impact board and sys-
tem testability. One might suggest that compromised testability is preferable to
none, but the reconstituted 1149.1 Working Group was determined to update the
standard in light of the technology drivers at play.

11.1 Moore’s Law, the Principle Driver

In 1965, Gordon Moore (then of Fairchild Semiconductor) was asked to project the
rate of change of the semiconductor industry. He stated that circuit densities tended
to double each year1 which was due to the photolithographic process improving
resolution steadily with time. Many have speculated that “Moore’s Law” would
eventually break down2 as the limits of photolithography finally became insur-
mountable, but this time still has not come. The Moore prediction of growth in logic
IC density3 since the inception of Boundary-Scan is shown in Table 11.1, using the
18 month interval. You could call it “a decade per half-decade”.

1
Nowadays, we hear the doubling rate happens in 18 months. An exponential process yields
impressive rates nonetheless.
2
The “law” should probably have been called “Moore’s Conjecture” since it is not a physical law
like those of Newton’s. However, it has been uncannily accurate for the last 50 years.
3
Logic IC density is somewhat different than memory density due to the more “random” layout of
logic as compared to regular memory structures. Analog ICs may also have different densities due
to power considerations. Then, some ICs will contain mixes of these technologies.

© Springer International Publishing Switzerland 2016 381

K.P. Parker, The Boundary-Scan Handbook, DOI 10.1007/978-3-319-01174-5_11
382 11 IEEE 1149.1: The 2013 Revision

Table 11.1 Growth in IC density since 1990, as predicted by Moore

Year 1990 1995 2000 2005 2010 2015 2020
Density 1.0 10.1 101.6 1024 10,321 104,027 1,048,576

Given the more than 100,000-fold density increase we have witnessed in the first
25 years of Boundary-Scan, it should not be surprising that IC technology has been
driven in certain directions as a result. It will be a million-fold by 2020! What has
this driver meant to Boundary-Scan?

11.1.1 Circuit Density

As just stated, circuit density has exploded. In 1990 Boundary-Scan proponents

argued for adding 1149.1 circuitry to ICs, and that the 5–10% circuitry cost was
worthwhile. Now, the amount of the Boundary-Scan circuitry compared to total
circuitry is basically vanishing. Also, since many ICs today have much larger pin
counts, the percentage consumed by 4 or 5 TAP pins is typically quite small. And,
most notably, since IC designs are extremely complex, most designers are adding a
lot of additional circuitry to assist with design verification and IC test. They find it
quite useful to commandeer the TAP port to support this functionality. This is
encouraged by the 1149.1 standard itself.

11.1.2 Design Automation

The increase in circuit density means that mortal humans are able to place far more
circuitry upon a substrate than they may be capable of understanding in their life-
time. Clearly, automated design is crucial to getting ICs into production. Reflecting
this trend is the move to “Intellectual Property packages” where a subsystem can be
bought and sold at will. This allows re-use of complex circuits within a larger
design, without the purchaser really knowing what is inside the IP. It is not uncom-
mon for scores or hundreds of IP circuits to exist in a major IC design today. This
trend will continue for the foreseeable future.
It is probable that some of this IP will be related to parts of an IC that contain
Boundary-Scan functions. Most obvious would be IP that implements certain I/O
functions, as these should contain a portion of the Boundary register. This means that
the IC design team would have to link multiple portions of a Boundary register
together. These portions might be indigenous, and/or purchased from outside suppli-
ers. Are they compatible? Is this linkage easy to accomplish? We did not have to deal
with these issues back in the good-ole-days, but back then, we had to design the
entire Boundary-Scan subsystem pretty much from scratch. The use of IP packages
is a significant driver for changes in the Boundary-Scan standard.
11.1 Moore’s Law, the Principle Driver 383

11.1.3 Lower Power Rail Voltages

Increased circuit density means that wiring inside and IC gets closer together, and
junctions get progressively smaller. This means voltage field strength in volts per
meter grows very high, which can lead to unwanted circuit effects. Back in 1990, the
predominant positive voltage of a logic family was 5.0 V. Now it is unusual to see
the positive voltage much in excess of a single volt. This has had the side effect of
dropping the power dissipation of ICs, but not as much as might be hoped, as internal
leakage currents have increased with circuit density. The overall power consumption
problem is an important driver for changes to the Boundary-Scan standard.

11.1.4 Higher I/O Data Rates

To keep up with greater circuit density, devices need to pump larger amounts of data
around in a system to keep up with what can be processed inside an IC. It does no
good to have a 64-bit floating point processor that can compute at incredibly fast
rates, if we can’t get the data to it fast enough to keep it busy.
Another contribution of increased circuit density is increased circuit speed. In
the late twentieth century, we made systems faster by increasing bus widths. Eight
bit data paths became 16, 32 or even 64 bits. But, such paths, at the board and sys-
tem level, take up a lot of board space. Also, trying to distribute clocking to wide
busses across multiple ICs becomes a limiting factor. The clock deskew problem
grows very quickly, which limits clock speeds on wide busses.
In the twenty-first century, increased circuit density comes again to the rescue.
First, let’s get rid of wide busses by multiplexing data in time onto (say) a single bit
path. For example, transmit a byte of data on a one-bit path. This would seem to take
eight times longer, but, we use differential signaling on the path (now two wires
wide) and we also play a new trick: we encode the 8 bits into a 10-bit data string4
that balances the numbers of ‘1’ bits and ‘0’ bits such that we never have long
strings of any similar bits. This allows us to encode clocking information with the
data, which reduces the need for complex clocking and deskew, which in turn allows
us to greatly raise data transmission speed.5 Basically, an IC transmitting data this
way operates within its own local clocking domain, while a receiving IC, also oper-
ating within its own clocking domain, is able to extract 8-bit data packets from the
10-bit strings without knowing very much about the transmitting IC’s clocking.
That is, there is no deskew problem to limit frequency.

4
This is called 8b/10b encoding. Basically, the 256 possible data bytes are encoded from 1024
possibilities by an algorithm that controls the overall average DC level of the signal.
5
Older wide bus-based boards might run data rates in the 50–100 Mb range. Modern data rates are
well into the tens of gigabits.
384 11 IEEE 1149.1: The 2013 Revision

Yes, it takes a lot of circuitry to implement such a scheme, but, Moore’s Law
delivers this for us. Let me hasten to say that some of this circuitry is sophisticated
analog design needed in the differential transmitters and receivers, to make it all
work. Your average digital system designer will gladly leave this part of the design
to analog I/O pad design specialists.
Note also that defects, particularly in differential circuit pathways, can have new
effects we did not observe before. For example, two differential signals (one data
path) need a carefully constructed grounding structure surrounding them as the
move across a board. Therefore, an open ground pin on an IC or connector, while
redundant in a DC sense, may cause data errors in high-speed data paths. See
[Park05] for more about these effects.

11.2 Lower Power Consumption

Users of mobile electronics devices always want better battery life. The vast data
centers that support the internet consume huge amounts of power (and cooling).
There is a tremendous desire to reduce the power needs of circuitry, even as the
amounts of such circuitry grow exponentially. Reducing power consumption is an
important technology driver, as a result.
So, IC designers have responded by implementing “power domains” within their
devices. A simple example would be floating point math unit inside a processor.
This unit might be used fairly rarely in many applications such as examining email
or even processing a spreadsheet. So, why not turn off the floating point math cir-
cuitry when not in use? Indeed, this is done and it is not uncommon to have many
power domains within a device, many with independent controls that turn units on/
off at will, even hundreds of times per second.
Now, a floating point math unit deep inside an IC will very likely have no connec-
tion at all to the Boundary-Scan portion of that device. But other power domains may
indeed contain portions of the Boundary-Scan implementation as noted earlier in
Sect. 11.1.2, and of particular concern are those portions that contain device I/O pins.
Imagine a group of I/O pins that are part of an IP package that a designer has
incorporated in an IC design. Further, this package of circuitry is designed to exist
in a power domain that can be powered down when not needed. These I/O pins have
Boundary-Scan boundary register support6 in the form of some number of data and
control cells that form a “segment” of the boundary register. Now, if these cells are
powered down, we have two major problems; first, the boundary register is “bro-
ken”, meaning it cannot shift data from TDI to TDO. If, during such shifting the
power was turned off, then the data shifted out from cells downstream of the break
would be valid, but all data above that point would be lost, perhaps just a stream of
‘0’ bits, for example. This is quite similar to behavior seen in a chain of devices

6
There is also the new Init_Data register (see Sect. 11.3.4.2) that may be associated with I/O pins
and may also be part of a power domain.
11.3 The 1149.1 Response to These Drivers 385

when there is an open connection of (for example) some TDI pin. Useful testing is
stymied until this break can be found and repaired. But in this case, the break is
internal to the IC’s boundary register itself. The second problem is that whatever
data may have been successfully preloaded into the boundary register during testing
will be lost when power to the domain is cycled. This would obviously upset any
testing dependent on that data.
Clearly, the Boundary-Scan standard needed to account for what can be called
“dynamic data registers”, that is registers than may have different configurations at
times. This means there needs to be a way to reconnect a broken shift register path
when a segment within it is removed. Note this means its length will be shorter.
How this is controlled is very important; and yes, there can be multiple segments,
each with different controls.7

11.3 The 1149.1 Response to These Drivers

There have numerous changes incorporated into the 2013 version of 1149.1 to
accommodate these technology changes we absolutely must respect. This section
outlines these responses.

11.3.1 New Operational Modes

Two new operational modes have been added to the 1149.1 view of the world. These
modes are called “Test Mode Persistence”, one for “On” and the other for “Off”. It
is optional to implement these, and, they can be thought of as a new, two-state dia-
gram that works in parallel with the 16-state TAP state diagram (see Sect. 1.3.1).
Figure 11.1 shows this new diagram.

CLAMP_HOLD Instruction

Persistence Persistence
Off On
CLAMP_RELEASE Instruction
TAP-POR*
“BYPASS-Escape”
TMPStates

Fig. 11.1 Test Mode Persistence (TMP) state diagram

7
And worse, the controls could be mutually exclusive in perverse cases.
386 11 IEEE 1149.1: The 2013 Revision

The concept of Test Mode Persistence (called TMP) is directly related to how we
might solve the “lobotomy problem”, where an IC (or board full of them) has been
doing 1149.1-based testing, and then, the test completes. What happens to the board
when those ICs doing testing (typically using EXTEST) are suddenly placed back
into “normal” mode, usually by passing back to the Test-Logic-Reset TAP state?
This was examined in [Park10], and a case study was reported in [Park11]. In the
case study, when the boards in question were not properly managed at the point
where Test-Logic-Reset occurred, the boards had an unacceptable rate of damage
due to power supply subsystem misbehavior. Some boards were fine, but some were
damaged beyond repair. Essentially, when each board “woke up” from its testing
duties, it might cause signals to pass to the power subsystem calling for inappropri-
ate action. The irony was, the Boundary-Scan test may have passed, so the damaged
boards were passed on to later production steps.
From this realization it was decided that the 1149.1 standard should offer a tool for
test software and test engineers to use to try to control this unpredictable return to “nor-
mal mode”. This is where the term “Test Mode Persistence” comes from—it allow an
IC that has been doing test functions, to remain in test mode even when it passes the
Test-Logic-Reset TAP state. This means the I/O pins stay under the control of the
Boundary register instead of being reconnected to the IC’s system logic, which is in
some unpredictable state. When TMP is turned “On”, then test mode persists after a test
completes. If TMP is implemented in an IC but not turned “ON” (or is turned “Off”),
then the IC behaves as have all other 1149.1 ICs since 1990, that is, potentially badly.
The TMP controller is manipulated by two new instructions called CLAMP_
HOLD and CLAMP_RELEASE (see Sect. 11.3.3.3). The first turns TMP on and
the second turns TMP off. The 1149.1 working group worried that it might be pos-
sible to get a device into TMP-on mode but not be able to get it back off again. This
seems unlikely, but in some critical applications (typically in military or medical
areas), there is concern over being “trapped” in an inoperative state with no way to
get out of it. Now, powering up a trapped device will bring it to the TMP-off state as
seen in the diagram (the assertion of TAP Power-on-Reset, TAP-POR*), but in typi-
cal system operation, this is not a normal option.8 So, the working group provided a
second way to move from the on to off states, called “Bypass-Escape”. This escape
mechanism is triggered by:
• First loading a ‘1’ bit into the bypass-escape bit of the TMP status register (see
Sect. 11.3.4.4).
• Then loading the device’s TAP instruction register with a BYPASS instruction
opcode (note, the all-‘1’ pattern defaults to BYPASS).
• Updating9 BYPASS into the instruction register by passing through the Update-IR
TAP state.

8
If the device possesses the TRST* pin on its TAP, this will also set TMP to “off”. However,
TRST* is not a required pin in an 1149.1 implementation.
9
Some devices default the IR to the BYPASS instruction when passing Test-Logic-Reset. This is
not sufficient to force a Bypass-Escape since Update-IR has not (yet) been traversed.
11.3 The 1149.1 Response to These Drivers 387

Loading the TMP status register is accomplished with any of the CLAMP_
HOLD, CLAMP_RELEASE or TMP_STATUS instructions. The first two of these
three operate like the normal CLAMP instruction (see Sect. 1.5.5) in that they clamp
the I/O pins to a state defined by the Boundary register. TMP_Status is a normal
mode instruction (when TMP is off).
The previous sentence offers a new insight—when TMP is asserted on, then
some instructions that are normally non-invasive, begin to behave like test mode
instructions. Prime example: the PRELOAD instruction behaves just like EXTEST!
Be aware of this. An advantage of the TMP mode is that when one test completes,
the 1149.1 test pins retain the last test state they were in, which is presumably a safe
state. When a new test starts up in Test-Logic-Reset,10 it may begin with a PRELOAD
sequence. Normally this would be done in normal mode so the I/Os would not know
about whatever the new Boundary register state was until EXTEST was installed.
Not so with TMP asserted on, the pins will respond to Update-DR while PRELOAD
is active. This is probably not a problem since the very next thing likely to happen
was to load EXTEST, but the user should be aware nonetheless.
How is TMP implemented within test data register cells? Please refer to the
Boundary register cell designs shown in Sects. 2.6.3 through 2.6.5, starting on page
94. In the cells designs documented there you see a “Mode” signal11 that determines
whether the primary output of the cell (PO) is fed by the Update flip-flop, or by the
primary input (PI) data. A new signal from the Test Mode Persistence controller
called (say) TMP_On can be OR’ed with Mode to keep the cell blocking the system
pathway while TMP is in the On state.

11.3.2 New Register Designs

In the earlier versions of the 1149.1 standard, a typical dual-rank shift/update data
register cell is depicted as shown in Fig. 11.2, with two edge-triggered flip-flops
(capture and update) that each had their own clock, Clock-DR and Update-DR. The
two multiplexors allow PI data to be passed directly to the PO, but in some data cell
designs, these may be omitted. The update flip-flop may have a reset signal keyed to
the test data register it was part of, called Reset_<TDR> in the figure.
Note that the two clock signals are so-called “gated clocks”, which means
that they are derived from TCK by combinational logic elsewhere on-chip.
This logic would, for example, allow TCK pulses to reach the test data register
only when that register is selected for use by the current instruction, and only
when the TAP was in the appropriate state.

10
Passing the TLR state jams BYPASS (or IDCODE) into the instruction register, but the pins
remain in test mode.
11
In some of the more complex drawings, the signal is “Mode_1” or “Mode_2”.
388 11 IEEE 1149.1: The 2013 Revision

Shift Out

Mode G
Parallel In 0
Parallel
Capture Update Out
Shift-DR G
Flip-Flop Flip-Flop 1
0
D Q D Q
1
CK CK

Shift In Clock-DR Update-DR

Reset_<TDR>
ShUp1990

Fig. 11.2 Classic dual-rank shift/update data register cell with gated clocks

Shift Out

Capture_<TDR> Update_<TDR>
Mode G
Parallel In 0
Parallel
G
Update 1
Out
Capture Flip-Flop
G 0
Flip-Flop MU D Q
Shift_<TDR> G 0
0 MC D Q 1
CK
1
CK
1

Shift In
TCK

Reset_<TDR> ShUp2013

Fig. 11.3 Revised data cell introduced in 2013, with non-gated TCK clocking

Great care must be taken with gated clock designs to make sure that their genera-
tion is “glitch-free”, that is, free of static hazards that might inject undesired clock
pulses12 into the circuitry. Gated clock designs are sometimes more “intuitive” for
observers to fathom and are in many cases retained in the 2013 version of the 1149.1
standard. However, modern design automation tools have stricter rules about gated-
clock designs, to help them support advanced automated design rule checking
which is crucial for designing large-scale devices. Users of these tools work in a
non-gated clock design environment. The data cell design in Fig. 11.3 is a non-gated
clock design for the same cell as in Fig. 11.2.

12
These may be malformed glitches or “runt pulses” which may upset the flip-flop state in
unpredictable ways.
11.3 The 1149.1 Response to These Drivers 389

This newer design contains two new multiplexors (MC and MU) that feed the
capture and update flip-flops. They choose to feed back either the existing flop data,
or new data, on every relevant13 TCK edge (positive for capture, negative for
update). There are two new multiplexor select signals “Capture_<TDR>” and
“Update_<TDR>” which make these choices. They are generated near the TAP and
are broadcast to the data cells. Clearly, this design is less intuitive to the reader at
first look, and it contains significantly more circuitry. However, with the fabulous
circuit densities now available, the extra gates are not as important as being able to
use design automation tools to synthesize and verify gigantic IC designs.
One more advantage of these modern cell designs is that they provide a frame-
work for a standardized TAP design. This assists the industry with sharing IP across
industry segments. If you design an IP circuit that uses the non-gated concept as
seen here, then it is more likely you can provide this IP to customers who have
also adopted this convention. In the past, your IP may have been incompatible or
otherwise difficult to integrate.

11.3.3 New 1149.1 Instructions

The 2013 revision has added some new instructions, with concomitant registers
assigned (see Sect. 11.3.4).

11.3.3.1 The ECID_CODE Instruction

The first new instruction is an (optional) “Electronic Chip Identification” and is a

response to the desire to identify much more about an IC that the existing IDCODE
instruction (see Sect. 1.4.2) offers. Not only may it deliver much more data, the
device designer is given complete freedom about how much data to store, whether
it is static or changeable, and whether it is “plain” or encrypted.
The ECID_CODE instruction in non-invasive, thus not affecting system perfor-
mance. It targets an ECID register (see Sect. 11.3.4.1). It is possible that some num-
ber of TCK clocks or system clocks are required to fully retrieve the data. If the data
is not ready for full retrieval, then an all-‘1’ pattern is produced in the register.
A PDL procedure may be required to document the process of obtaining the code, if
it is not simply a matter of shifting out captured bits. In the case where the time
required to fully acquire the code is not known, then it can be repetitively shifted out
until the all-‘1’ pattern is not observed (polling).

13
This means these select signals must only change after the non-relevant edge, that is, 180° out of
phase with the relevant edge. Any hazards on select lines that occur at that point should be settled
before the critical edge arrives a half cycle later. This is much easier to verify during rule checking.
390 11 IEEE 1149.1: The 2013 Revision

Here are some examples of data that may be extracted from an IC by ECID_
CODE:
• A manufacturing data code, in vendor-specific format.
• Lot and wafer numbers, with positional location data on wafer.
• A readout of fuse settings programmed during manufacturing.
• A readout of accumulated error correction counts.
• Identification of “circuit-ware” installed during (or after) production.
• Any/all of the above.
Be assured clever designers will add to this list. Having such data (perhaps
encrypted) would allow an IC manufacturer to examine facts14 about a given IC that
may be germane to yield analysis, defect distributions, or other relevant statistics. The
vendor of a device may examine such data before shipment to a customer, or after a
device has been returned. The vendor could also just examine the data delivered by
this instruction, after the customer reads it out at his location and transmits it to him.
In such a case the IC vendor probably does not want to reveal what all the bits encode.

11.3.3.2 The INIT_SETUP, INIT_CLAMP and INIT_RUN Instructions

These (optional) instructions15 were added in the 2013 release of 1149.1 to facilitate
the initialization of test facilities within the IC needed for performing tests. In sim-
pler times, just powering up a device, and/or asserting TRST* was enough to do
this. Later, it was not uncommon to have an IC with test facilities that would not
work if you did not know “the secret” process for getting it ready.
What was really going on here was there were practical needs that had to be
fulfilled before the IC was ready for test—and there was no standardized way to set
these up. For example, an FPGA might have drivers and receivers with program-
mable levels. What levels should they have set for testing? If you just launch into
EXTEST testing, will the drivers drive out the right voltage for their connected
receivers? Will the device’s receiver be set to compatible receive levels to see data
coming in? Maybe the power-up default levels are not correct in a given design. The
test won’t work until this problem is solved. As stated, people would figure out the
“secret process” and write some pattern code to accomplish it. Then they would
pass that around their user community, saying, before you try to test with your tool,
plug these secret patterns in first. The family of initialization instructions is an orga-
nized approach to standardizing this process.
The INIT_SETUP, and the very similar INIT_SETUP_CLAMP instructions target
an initialization data register (known in BSDL and “INIT_DATA”). This register of
at least one bit in length is where data is inserted to set up important parameters for

14
There is much concern growing now about counterfeit devices. These codes could help identify
such cases.
15
When implemented, all three of these must be provided.
11.3 The 1149.1 Response to These Drivers 391

testing, like the voltage levels of the FPGA seen in the previous example. The data is
shifted into the register in the Shift-DR TAP state, as always. The register can be
loaded by either instruction, the difference being that INIT_SETUP is a non-invasive
instruction, not disturbing the IC’s behavior. The INIT_SETUP_CLAMP instruction
allows initialization data to be shifted into the device, while keeping its I/O pins
clamped to the values dictated by the Boundary register content (previously set up by
PRELOAD). This “clamp-like” behavior is like the CLAMP instruction (see Sect.
1.5.5), but the instruction targets the initialization register. Thus, the initialization data
register can be set up in non-invasive, or in test modes. If a test has lobotomized a
board, and you need to change the initialization data before conducting a new portion
of testing, the INIT_SETUP_CLAMP instruction should be used to keep the IC(s)
from exiting test mode while delivering the new initialization setup.
See Fig. 11.4 for an example of a portion of Boundary-Scan circuitry behind an
output driver. Two Boundary register cells supply digital data and output enable con-
trol. Then there are seven Init_Data cells that provide analog parameter controls for the
driver. These are now made visible to test engineers, where before, they were “Secret”.

Enable
C U
Boundary
Register
Segment C U
Data Driver

C U Common
Mode
Voltage
C U
Generator

C U
Swing
Init_Data Control
Register C U

Segment

C U

Transmit
C U Stregth
Control
C U

InitData

Fig. 11.4 Example of an output driver with selectable parameters

392 11 IEEE 1149.1: The 2013 Revision

In some cases in an IC design, it may be necessary to let some time pass, along
with perhaps some TCK and system clock cycles, to allow the setting of data or the
parameters controlled thereby to take effect. The INIT_RUN instruction (which
targets the Init_Status register) serves this purpose. For example, say a device uses
internal charge pumps to develop pin reference voltages. These may require some
time and clocking to do their job before you can begin using the pins. In more com-
plex cases, you may need to set up INIT_DATA first, and then some internal state
machine, clocked by TCK, must run to execute some internal setup procedures. This
would probably be done by first running a PRELOAD sequence to ready the
Boundary register for testing, then running either INIT_SETUP or INIT_SETUP_
CLAMP to set up the INIT_DATA, and then switching to INIT_RUN to complete
the sequential process of finishing the initialization. Note that INIT_RUN is inva-
sive, so preload and initialization data need to be in place ahead of its use.
The “secret patterns” that were needed before the 2013 release of 1149.1 should
soon be replaced by the formalized initialization process now supported by these
three new instructions. Note that later, the details of the construction of the INIT_
DATA register and how data patterns inserted within fields of this register will pro-
duce specified actions, can be described in BSDL. See Sects. 11.4.19 through 11.4.21.

11.3.3.3 The CLAMP_HOLD, CLAMP_RELEASE

and TMP_STATUS Instructions

The CLAMP_HOLD, CLAMP_RELEASE and TMP_STATUS instructions are a

group that are all implemented only when the Test Mode Persistence controller
(TMP, see Sect. 11.3.1) is implemented16 in a device. All three instructions target
the TMP status register, called TMP_Status17 in BSDL. This register is described in
Sect. 11.3.4.4. Both CLAMP_HOLD and CLAMP_RELEASE are test mode
instructions, giving I/O control to the Boundary register. The TMP_STATUS
instruction is a normal mode instruction, that is, when the TMP controller is in the
persistence off mode.
These instructions manipulate the TMP controller, to turn persistence “On” or
“Off” (CLAMP_HOLD and CLAMP_RELEASE respectively) or in the case of
TMP_STATUS, to interrogate the status of the TMP controller. They all access the
TMP status register, and can thus read out the TMP-status bit or set the state of the
Bypass-escape bit. Note that updating CLAMP_HOLD or CLAMP_RELEASE
into the instruction register will cause a TMP mode change—that is, no data need
be shifted. Since at the time that this updating happens, the I/Os are controlled by
the Boundary register, we cannot directly observe the state of the TMP controller
from outside of the device.

16
The presence of these three instructions in a BSDL file indicate the existence of the TMP
controller in the device.
17
Note that the keyword “TMP_STATUS” is both the name of a register and an instruction in the
2013 release of 1149.1. This has also been true of the keyword “BYPASS” since the advent of BSDL.
11.3 The 1149.1 Response to These Drivers 393

11.3.3.4 The IC_RESET Instruction

The optional IC_RESET instruction provides a means to control a set of resets to

the system logic under the control of the TAP. It targets the reset selection register
(see Sect. 11.3.4.5). This allows a device to have individual subsystems within it
reset, or have such resets blocked, by use of the IC_RESET instruction. This allows
a test engineer to satisfy device and test requirements, such as holding the device in
a quiescent state internally while testing proceeds, or preparing some internal BIST
function for operation. The intention of this instruction is to give test engineers
access to all IC reset functions, whether those are triggered by I/O pin assertions, or
are generated internally on-chip. Further, it is encouraged that multiple sectors of
circuitry that are reset by a single reset function, be independently reset by bits in
the reset select register.
The IC_RESET instruction loads and updates the reset select register provided
by the IC designer, which may contain an arbitrary number of such resets. The
resets are asserted or de-asserted by the falling edge of TCK while in the Update-DR
state. Such assertions can be performed in parallel with one update, or, several shift/
update cycles can be used to sequence the assertions in some preferred order. Note
that some reset processes may require both assertion (to start the process) and de-
assertion (to complete the process).
If the device has an TMP controller (see Sect. 11.3.1) and it is in the Persistence
On state, then loading/updating the reset select register should not change the
Boundary register content, nor any features set by the INIT_SETUP, INIT_SETUP_
CLAMP or INIT_RUN instructions (see Sect. 11.3.3.2). The IC_RESET instruction
is not allowed to interfere with the operation of TRST* or any other reset function
within the Boundary-Scan circuitry. However, a Power-On reset to the system cir-
cuitry (only) can be asserted via this mechanism.
The reset select register is a useful tool for test engineers to use to keep an IC
from performing unusual actions upon test completion. It can keep resets asserted
via the TAP when a tester is not able to assert such resets due to lack of access.

11.3.4 New 1149.1 Data Registers

The 2013 release of the 1149.1 standard added new public data registers. All are
optional and are targets of new public standard instructions, also optional.

11.3.4.1 The ECID Register

An electronic chip identification (ECID) is a bit string with a value unique to each
individual component within a set of devices of the same type. Devices with the
same Device ID (see Sect. 1.4.2) or User ID (see Sect. 1.4.3) can have differing
ECID patterns that identify unique features of interest to the vendor of the device.
394 11 IEEE 1149.1: The 2013 Revision

This information may be documented publicly, or it could be encrypted, as the

device vendor sees fit.
The ECID register is accessed when the ECID_CODE instruction is in effect (see
Sect. 11.3.3.1). The ECID register length is determined by the device vendor, and it
could be rather larger than (say) the Device ID, which is a fixed 32 bits long. It was
anticipated that some ECID data might take time and/or clocking to become avail-
able and thus might not be “ready” in the 2.5 TCK cycles it takes to travel from the
Update-IR to Capture-DR TAP states. In the case of data not being ready, the ECID
register should capture the all-‘1’ pattern. When enough time and/or clocking has
elapsed, then the value captured will contain zeros here and there. Thus no one bit
is specifically identified (by the standard) as a “ready” bit. It is envisioned that suc-
cessive ECID shifting would be executed until “ready” data is seen, or, a PDL rou-
tine with more detail about the readout mechanism is supplied with the device.

11.3.4.2 The Init_Data Register

The Init_Data register is targeted by the INIT_SETUP and INIT_CLAMP instruc-

tions (see Sect. 11.3.3.2). This register is intended to store information needed to set
up a device’s Boundary-Scan facilities for testing purposes. A prime example of this
is an FPGA with programmable drive and/or receive levels. For example, see
Fig. 11.4. Such a device may have default voltage levels that do not match what
other devices connected to it require for transmitting/receiving data, during testing.
Now this FPGA, during normal functioning, would be set up to communicate with
its neighbors, but this may entail some special bootup processes being executed.
During a board test, these processes might not be available; perhaps the processor
that does it is not yet mounted on the board, or, the data is delivered from another
board not available during test. Or, maybe a board defect prevents the initialization
from happening.
This problem was recognized some time ago, leading to special “secret” instruc-
tions and registers being implemented inside devices in a non-standardized way.
Then, special pattern sets were passed around among test engineers to properly
initialize devices before testing commenced. This was a big problem. The “Init
Problem” has since been addressed by the 2013 release. Now we have a way to
bring the initialization process out into the open, with appropriate, machine read-
able documentation.
Note that the Init_Data register, like the Boundary register, may be segmented
(see Sect. 11.3.5), and some segments could be in power domains that are turned on
or off during normal operation. Clearly, these must be controlled.
The Init_Data register may be rather long. Its cell data may also be changed (dur-
ing the Test-Logic-Reset TAP state) by system functions18 allowing system func-
tionality to be shared with test function. There may be cases where some input pins

18
It the device is not in the Test Mode Persistence “On” state.
11.3 The 1149.1 Response to These Drivers 395

of a device are used to configure its I/O behavior. In such case, the Init_Data register
can capture these states for observation after shifting them out, to verify they are
what is expected.19
Improvements to BSDL that support identifying data fields in registers, and mne-
monics for data patterns that can be loaded into these fields, can greatly assist users
in understanding what they need to do with the Init_Data register. (See Sects. 11.4.19
through 11.4.21.) The device supplier can assist by providing PDL routines to
document how to access these fields and place the right data in them.

11.3.4.3 The Init_Status Register

The INIT_Status register is the target of the INIT_RUN instruction. This register
should be thought of as a read-only register, that is, you have nothing to write into
it, because it just registers the status of a sequential initialization process driven by
INIT_RUN.
This register is at least 2 bits long, with more added at the designers wish. The
lowest bit (nearest TDO) is a “busy/done” bit, which indicates via a 1/0 whether the
initialization process in completed. An accompanying PDL routine is used to docu-
ment how long the process should take, and what clocking requirements are needed.
The busy/done bit can be shifted out periodically to implement “polling” when the
time requirements are uncertain.
The next mandatory bit (bit 1) is used to indicate whether the initialization pro-
cess was “successful”, that is, it is a 1/0 pass/fail indicator, for those processes that
can judge their success. (If they cannot so judge, then ‘pass’ is the only result.)
Higher order bits can be implemented that can be used to capture extra details about
what may have happened; perhaps an error code or an indication of how close
the initialization process came towards some limit. Again, the new register
documentation features in BSDL can assist us in understanding these higher bits.
See Sects. 11.4.19 through 11.4.21, beginning on page 429.

11.3.4.4 The TMP Status Register

The TMP status register (named TMP_STATUS in BSDL) is targeted by the

CLAMP_HOLD, CLAMP_RELEASE and TMP_STATUS20 instructions. It is
exactly two bits long, with bit zero (nearest TDO) being the Bypass-escape bit and
bit one being the TMP-status bit.

19
You ask, doesn’t EXTEST do this? Well, yes, but if we can observe these particular pins before
we get into testing and see they are not right, we can avoid later confusion.
20
As noted, “TMP_STATUS” is both an instruction name and register name in BSDL..
396 11 IEEE 1149.1: The 2013 Revision

The TMP-status bit is ‘1’ when the TMP controller is in the persistence on mode,
and is ‘0’ otherwise. This bit can be captured and shifted out, but not written changed
at Update-DR. Its state is determined by whether CLAMP_HOLD or CLAMP_
RELEASE has been previously executed—and is always set to ‘0’ by powering up
the device, or asserting the TRST* pin.
The Bypass-escape bit can be set or reset by any of these three instructions, to
enable or disable the bypass-escape mechanism described in Sect. 11.3.1. This bit is
also set by powering up the device or asserting TRST*.

11.3.4.5 The Reset_Select Register

The reset select register (called Reset_Select in BSDL) is targeted by the IC_RESET
instruction (see Sect. 11.3.3.4). This register consists of a Reset-Hold bit which is
closest to TDO, and one or more pairs of bits, where each pair consists of a Reset-
Enable bit (closer to TDO) and a Reset-Control bit, as seen in Fig. 11.5.
Upon power-up of the device, the reset select register it initialized to all-‘1’,
which means all domain resets are connected to their normal, system reset sources

TDO
TAP-POR* To TDO
(from TAP)
C U Reset-Hold
Boundary
Reset* C U
Register Cell
(from TAP)
System Reset Pin From
TDI
C U Reset-Enable 1 G
0
Domain 1
1
Reset
C U Reset-Control 1
Reset
Select
Register C U Reset-Enable 2 G
0
Domain 2
1
Reset
C U Reset-Control 2

C U Reset-Enable N G
0
Domain N
1
Reset
C U Reset-Control N
Internal System Reset
TDI ResetSel

Fig. 11.5 A reset select register for controlling N domains in an IC

11.3 The 1149.1 Response to These Drivers 397

and all the reset-control signals are in the non-asserted state. In this example,
Domains 1 and 2 are both reset by a single system input pin. The first two pairs of
reset select register bits control Domains 1 and 2, so they can be independently reset
by using the IC_RESET instruction. Domain N is reset by an internally generated
reset signal, so bit pair N is used to reset this domain. Note that the state of the
internally reset domain’s reset signal is captured by the Reset-Control N register
cell, allowing the user to verify its state.
To perform a reset, the IC_RESET instruction is used to shift a set of bits into the
reset select register. The Reset-Hold bit can be set to ‘1’, which would allow the
passing of the Test-Logic-Reset TAP state to reset all the higher bits to ‘1’. If the
Reset-Hold bit is set to ‘0’, then passing the Test-Logic-Reset TAP state will not
change the higher bits. This is the meaning of “Hold” in the Reset-Hold name.
Shifting in the remaining bit pairs allow each domain reset to be fed from either
its normal source, or from the Reset-Control cell paired with it. Putting a ‘0’ into a
Reset-Control cell asserts the reset function. As noted, this assertion may kick off a
process that needs to be completed by setting the Reset-Control back to ‘1’, which
would require a new shifting sequence.

11.3.5 Dynamic Data Registers

The new feature that is perhaps most revolutionary in the 2013 version of 1149.1
is the concept of a dynamic data register. This is a register which may change it
length and organization in certain specified ways. In all earlier versions of the
standard, data registers were always fixed, having just one length and organization
at all times.
The standard contains standard public registers such as the bypass, device_id and
test mode persistence that are not allowed to have dynamic behavior. The standard
boundary register, initialization data and status registers, ECID and reset selection
registers are allowed to have “excludable segments” only, but these segments are not
allowed to be nested—that is, one excludable segment cannot contain a second
excludable segment within it.

11.3.5.1 Excludable Segments

The foremost reason for excludable segments in standard registers like the boundary
or init_data registers is to account for power domains. It is becoming common for
an IC to have multiple domains that have independently controlled power. When
(say) the boundary register passes through such a domain, then some portion (a seg-
ment) of the register may have power applied at random intervals. When not pow-
ered, the chain would be broken if we don’t deal with the idea of excluding that
segment. Therefore, the standard provides a way to switch a segment into place as
needed. See Fig. 11.6.
398 11 IEEE 1149.1: The 2013 Revision

“Ready for Scan” Segment

Select Mux
Excludable Segment
From TDI 1

C U
Reset* (excluded at power up)
Towards TDO
0
Segment G

Select Cell

Shift_<TDR>
Optional gates
Capture_<TDR>

Update_<TDR>
ExclSeg

Fig. 11.6 An excludable segment

In this figure we see an excludable segment, which must have at least one data
register cell. When the device powers up, the segment select cell21 is reset, so that
the segment select multiplexor22 selects the segment select cell to pass on to the rest
of the register. Note that only the excludable segment may be in power domain,
while the segment select cell and segment select multiplexor are always powered.
The segment select cell captures a logic value from a signal (here) called “Ready for
Scan”. A captured ‘1’ means the excludable segment is operational, while a ‘0’
means the segment is not functional. This bit can be shifted out for inspection to
assure that the segment is ready, or not ready, as needed. Typically, the segment is
inside a power domain that may or may not be powered. The power may be con-
trolled by some on-chip function, or it may receive power from a device power pin
which itself is receiving power from some external function, like an on-board regu-
lator. In any case, the “Ready for Scan” signal should reflect this.
Figure 11.6 also shows three signals that control shifting, capturing and updating
of the excludable segment. The updating is always gated by the segment select cell
content, to keep an excluded segment’s update flip-flops (when powered) from
changing when the segment is excluded. The shift and capture functions may or
may not be similarly controlled. Note, when a segment of a boundary register is
excluded (assuming it is powered) the I/O pins that it observes and/or controls are
in the system (not test) mode of operation. This means those pins are connected to
their system logic.
A data register may contain multiple segments, and all are excluded at power-up,
so the register’s default length is the minimum possible. As segments are inserted
into the register, its length will increase by the length of the inserted segment, and,
this has the effect of changing the cell position of all cells towards the TDI side of

21
This cell is called a “SegSel” in BSDL, seen later in Sect. 11.4.20.
22
This multiplexor is called a “SegMux” in BSDL, seen later in Sect. 11.4.20. There is also a
“SegStart” field in BSDL. Both of these are zero-length felds, whereas SegSel is one bit.
11.3 The 1149.1 Response to These Drivers 399

the register. In the boundary register for example, if cell N is above an L-bit exclud-
able register, then at power up, it is the Nth cell, but it becomes the N + Lth cell
when the segment is later included. It’s nice we have computers to help us keep
track of all of this.

11.3.5.2 Domain Controls

Certain areas of an IC may have independent power supplies. There are two cases;
the first is where there is an on-chip power provision to a domain. The second is
where power is brought in from an external source, through a power pin. In the first
case, a “domain control” bit can be used to assure that power is supplied to the
domain, that is, it will override an on-chip controller that may be attempting to turn
the domain off. This allows us to govern which on-chip-controlled domains are not
allowed to turn off. In the case where power is externally supplied, we have no such
control we can exercise inside the IC; at best, we can try to observe if the domain is
powered before we use it.
Part of an overall test strategy for a system will be to identify those important
segments we want to have powered, and to achieve that powered state reliably. For
the on-chip controllers, we can use the domain control bits to demand power for
their domains. For those that are externally supplied, we have to figure out where
that power comes from, and how we can assure it will be there when needed. This
could be simple, for example, our tester may be able to supply the power at our con-
trol. If the power comes from some on-board power regulator, then we may have to
analyze how to get it to provide the power we need to the correct parts of the board.
Figure 11.7 shows an elementary excludable segment with a domain control
cell ahead of the segment. The output of that cell travels to the power supply for
the excludable segment and acts as a “request” for power to be supplied, when that
cell is loaded with a ‘1’. It might turn out that there is some time lag between when
the request is asserted, and when the segment gets power. The “ready for scan”

Domain-
control cell “Ready for Scan” Segment
Select Mux
Excludable Segment
From TDI 1
C U

C U

(excluded at power up)

Towards TDO
0
Reset* G
Segment
Select Cell
Shift_<TDR>
Optional gates
Capture_<TDR>

Update_<TDR>
DomCntl

Fig. 11.7 An excludable segment with a domain control cell

400 11 IEEE 1149.1: The 2013 Revision

indicator will be set to ‘1’ when the power is ready. Note that the domain control
cell must always be powered and not itself be in an excludable segment.23
Note that a domain control cell may not be in the same register as the segment it
is associated with. For example, for an excludable segment in a boundary register,
the domain control cell that provides power to the segment may be in the Init_Data
register. Further, there could be two domain control cells for a segment, with either
of them (by being set to ‘1’) providing power. Thus there could be a domain control
cell for a segment if both the boundary register and Init_Data register. This will be
coded in the BSDL for the device. Test engineers and their tools must be alert for
these situations.

11.3.5.3 Selectable Segments

Design-specific test data registers may have excludable segments, with nesting
allowed. Further, design-specific TDRs may have “selectable segments”, where
a segment may be included from a set of possibilities, as depicted in Fig. 11.8.

Segment 2, Length N
Segment
Select Mux
Segment
3
Selection Field
Segment 1, Length M 2
Towards TDO
1
0
G
From TDI Segment 0, Length L
C U

C U

Decode/Control

Shift_<TDR>

Capture_<TDR>
Update_<TDR> SelSegs

Fig. 11.8 Three selectable segments and their control

23
Actually, in complex registers not provided by 1149.1, it is allowed for domain controls and seg-
ment select cells to be nested within other segments. It is specifically disallowed for boundary
register and Init_Data registers. Clearly, using such nested structures can present us with sequenc-
ing issues that need to be carefully thought out.
11.4 Revisions to BSDL 401

Here, a set of register segments 0, 1 and 2, with non-zero lengths L, M and N are
selectable by a two-bit segment selection field. The segment select multiplexor has
an unused input (3), which should not be selected since that would break the chain.
The segment selection field in Fig. 11.8 is shown directly ahead of the segment
group, but it could be almost anywhere else, or in a different register altogether. The
segment selection bits may capture data if the IC designer so chooses, but there is
no requirement for a “Ready for Scan” signal being captured. Basically, with a
design-specific test data register, the IC designer sees few limits for segment selec-
tion, and users can operate them at their own risk. See how these are described
within BSDL in Sect. 11.4.21.
More complex examples are shown in the 2013 revision of 1149.1. In particular,
see the examples (in Sect. B.8.21.3) of an implementation of a “Wrapper Serial Port”
(WSR) structure from the IEEE 1500 standard.24 This structure has a nested select-
able register form, with the outer level selecting between data register and instruc-
tion register access of the 1500 WSR, and the inner level selects among a set of 1500
data registers. The example continues to show how several identical 1500 WSRs
could themselves be linked together as a set of selectable segments, with the ability
for all of them to be loaded in parallel, while only one is selected for passing its data
out. This can be used to “broadcast” input data to the WSRs, when it is intended for
them to receive the same data or setup information. Again, use at your own risk.

11.4 Revisions to BSDL

The 2013 release of 1149.1 makes an extensive list of changes and additions to
Boundary-Scan Description Language. This section discusses the rationale for the
changes and gives an overview. Details about syntax are found in Appendix B which
notes the changes/additions to the syntax listed in Appendix A.

11.4.1 Breaking the VHDL Link

Boundary-Scan Description Language was originally developed as a “subset and

standard practice of the VHSIC Hardware Description Language (VHDL) (IEEE
Std 1076-1993)”. The size and complexity of BSDL was deliberately minimized, to
keep it simpler and easier to implement. Keeping it to a proper subset of VHDL also
meant some compromises were made in what could be described.

24
This is IEEE 1500 Standard for Embedded Core Test (SECT). In the past, such structures may
have been embedded in ICs, unknown to outside users. With the advent of the 2013 revision of
1149.1, it is possible to describe their existence in BSDL, if the IC vendor chooses.
402 11 IEEE 1149.1: The 2013 Revision

The 2013 release of 1149.1 has broken the “proper subset” claim of BSDL. It is
now described as “based on” VHDL. The principle place this is seen is in changes
to the set of “VHDL reserved words” used in BSDL. These are “pin type” keywords
that were somewhat limited in VHDL; these are now expanded to offer more infor-
mation about what functionality a device pin might possess. Indeed, the VHDL
reserved word “linkage” has been eliminated in BSDL and replaced with an
expanded list of words that have “linkage_” as their start.
Breaking the VHDL link means that the 1994 goal of having BSDL be parsable
by a compliant VHDL compiler is no longer achievable. It was felt that this goal
was not really important since tool makers created dedicated parsers for BSDL
rather than modify existing, VHDL-based tools.

11.4.2 VHDL Reserved Words

The list of VHDL reserved words that are also reserved in BSDL has been shortened
to just 30 words (see the list in Sect. A.1.1). This is another side effect of breaking
the VHDL link.
There is one reserved word missing from the table above; it is “Linkage”. This
word was reserved in all previous versions of BSDL (before 2013) and served as a
catch-all for pins that were not signals, like power/ground or analog pins. In the
BSDL reserved word section (Sect. A.1.2) you will see several words that start with
“Linkage_” and these are now used to provide more information about the nature of
a pin, such as “Linkage_out”, which might be assigned to an analog output pin not
controlled by the Boundary register. It is now the case that when a parser starts read-
ing a BSDL file of unknown vintage, it could come across the word “linkage”, or
perhaps “linkage_out” in the port declaration before is comes across the standard
use statement that identifies the date of the BSDL standard being processed. Thus,
if (say) “linkage_out” is encountered in a pre-2013 BSDL, which would easily be
recognized25 as an error. But, if the word “linkage” is found in a 2013 version of
BSDL, that cannot be flagged as an error until the standard use statement is found,
which could be many lines farther down in the file.
The 2013 version of the standard is silent on whether the word “linkage” should
be avoided as a name of some item. The fact that it no longer appears in the VHDL
or BSDL reserved word lists suggests that you could name a port “linkage”, but it
seems like asking for parser troubles and other possible confusion.

25
At least in the case of a parser that has not been upgraded to accept both 2013 and pre-2013 ver-
sions. If the parser can read both versions, then if “linkage” and later “linkage_out” were both seen
in the port statement, then an error could be issued at that point.
11.4 Revisions to BSDL 403

11.4.3 BSDL Reserved Words

The list of BSDL reserved words has been enlarged with 66 new entries. Many of
these are related to the new statements that have been added. The original list
appears in Sect. A.2.3 and the new words are shown in Sect. A.1.2.

11.4.4 New Numeric Literals

The pre-2013 versions of BSDL have four types of numeric literals, for integers,
real numbers, general pattern data (made up of ‘0’, ‘1’ and ‘X’ characters) and
32-bit patterns.
The new BSDL add three new numeric number types (see Sect. A.1.3), which
are used to describe pattern data in binary, hexadecimal or decimal formats as
found convenient in a given application. These patterns can be given friendly
mnemonic names and are used to populate named fields within registers
(see Sects. 11.4.19 and 11.4.20).

11.4.5 New “Identifiers”

The 2013 revision of BSDL adds two new types of identifier, mnemonic identifiers
and prefix identifiers. See syntax details in Sect. A.1.4.
Mnemonic identifiers are used as names for bit patterns (see Sect. 11.4.19) that
are more readable and understandable to users. Here are some examples:
• 133 MHz.
• 60 %_Swing.
• Reserved_for_future.
• SATA.
Two of these cannot be expressed by a common VHDL identifier (they start with
a digit or contain special characters). They are equated to a bit pattern that is most
likely not easily remembered. Thus a user remembers “133MHz” rather than
“0x27”. This is even more helpful when “0x27” is a 7-bit string of data that is dis-
tributed into seven non-contiguous locations in some obscure register. It is intended
that mnemonic identifiers be displayed to users on interfaces that allow them to
select what actions they want to enable from lists of meaningful mnemonic names.
The software then takes care of bit distribution details.
Prefix identifiers are used to help resolve bit fields in nested field descriptions
(see Sect. 11.4.20).
404 11 IEEE 1149.1: The 2013 Revision

11.4.6 New Information Tag

An information tag is a relatively free-form sequence of characters that convey tex-

tual information. They are used in mnemonic data descriptions (see Sect. 11.4.19)
and add meaning to mnemonics. This content can be displayed to users to help them
understand what a given mnemonic is for. They can contain special characters like
@#$%&* and such. They cannot contain BSDL comments or format effectors.
Their definition appears in Sect. A.1.5. An example of an information tag is:
<38.7% VDD Swing - Not valid for XAUI>
Here a mnemonic is tagged with this informational text, between the enclosing
chevrons, to alert users that a given voltage swing within a list may not be appropri-
ate with other selected features.

11.4.7 New Port Types

In pre-2013 BSDL the only <port type> descriptors were IN, OUT, INOUT, and
LINKAGE. The “linkage” ports were a catch-all for all the non-I/O pins, such as
power, ground, analog and unconnected pins. The 2013 revision replaces “linkage”
with a set of new descriptors with enhanced meanings. (See Table 11.2 and syntax
detail in B.2.1.) This allows tools to better analyze board topologies and create bet-
ter tests and diagnostic results (Table 11.2).

Table 11.2 New port types and their meanings

Port type value Description
LINKAGE_BUFFER A non-Boundary-Scan analog port that sinks or sources current, with no
known disable method
LINKAGE_IN A non-Boundary-Scan analog input that does not sink or source current
LINKAGE_INOUT A non-Boundary-Scan analog bidirectional
LINKAGE_ A pin without electrical function, usually used for positional keying. It
MECHANICAL is not usually connected to the silicon
LINKAGE_OUT A non-Boundary-Scan analog port which may sink or source variable
current; it may have a disable method not controlled by Boundary-Scan
POWER_0 A non-Boundary-Scan zero-volt power supply pin
POWER_NEG A non-Boundary-Scan power supply port that receives a constant
voltage less than zero volts
POWER_POS A non-Boundary-Scan power supply port that receives a constant
voltage greater than zero volts
VREF_IN A non-Boundary-Scan input reference voltage required for component
functionality
VREF_OUT A non-Boundary-Scan output reference voltage generated on-chip
11.4 Revisions to BSDL 405

Clearly, the word “linkage” has been expanded to give a lot of new detail. Here
are some examples of device pins and how they would be typed.
• An input pin that receives a sinusoidal frequency reference: LINKAGE_IN.
• An output pin that is used to supply regulated voltage to another device:
LINKAGE_BUFFER.
• A Ground pin: VOLTAGE_0.
• An input pin that supplies a reference voltage a set of on-chip receivers:
VREF_IN.
• An output pin that supplies a reference voltage to another device so that its
receivers will properly receive data: VREF_OUT.
These <port type> values are used in the <logical port description> portion near
the top of any BSDL file. The word “logical” may seem out of place here as all these
new types help describe pins that are not commonly thought of as logic. Notice also
that the <port dimension> may be bit or bit_vector, which may also seem strange
since (say) a power pin is not usually thought of as a “bit”. These seeming anoma-
lies were not changed with the break from VHDL.
The three “power” types can help with board topology analysis. For the majority
of ICs that use positive logic (that is, the voltage of a ‘1’ is higher than the voltage
for a ‘0’), then if we see a board node connected to a device pin that is typed
“Power_0”, and then later, we see a board-mounted resistor connected between that
node and a Boundary-Scan input pin, we may assume that that input will load a ‘0’
into its Boundary register cell. This may not be a valid assumption in every case, but
it may help us find missing resistors in many instances, where the pull-down ‘0’
provided by the resistor seen as a logic ‘1’ of a floating input.

11.4.8 Standard Use Statement

The standard use statement appears directly after the logical port description. The
name of the package identified there is used to key a parser on which version of
BSDL it is reading. The statement for the 2013 version of BSDL looks like this:
use STD_1149_1_2013.all; -- For a 2013-compliant file

The “2013” number tells software the revision level. Previous versions had revi-
sion numbers of 1990, 1994 and 2001. There is new information provided in this
new package26 (see Sect. A.3) that provides description of some standardized mne-
monics and register fields.

26
An older parser that does not know about the 2013 revision would likely produce errors when it
encountered this standard package. But since the standard use statement appears after the port
description, errors due to “linkage” changes may have already aborted the compilation.
406 11 IEEE 1149.1: The 2013 Revision

11.4.9 Use Statements

Following the standard use statement, there may be optional use statements that
identify supporting packages that may be supplied by the IC vendor, or passed along
by that vendor from some IP supplier. In particular, mnemonic data, register fields
and assemblies may be found in them—even design warnings may now appear. See
Sect. B.4 for details.

11.4.10 Component Conformance Statement

The component conformance statement now can be encoded with STD_1149_1_2013,

which means the component is designed to meet the requirements of the 2013
release of the 1149.1 standard. Yes, it is possible to use the 2013 version of BSDL
to describe a device that conforms to older revisions (e.g., 2001). However, the lan-
guage changes (notably, with respect to port type “linkage”) would require you to
use the newer version of BSDL, which means some editing if you want, for some
reason, to transcribe an existing pre-2013 BSDL into the 2013 version. Why would
you do this? Perhaps you want to take advantage of some of the newer details you
can convey using the newer version, to gratify your customers.

11.4.11 New Device Pin Mappings

Device pin mappings now offer more detail with the 2013 revision of BSDL. As
seen in Sect. A.1.7 the syntax now allows naming a pin (by number or alphanumeric
ID) or using one of three keywords, OPEN, TIE0 or TIE1 to describe it. The reason
for this is it is now relatively common for a single die to be mounted in one of sev-
eral IC packages, where the pin counts may vary widely.
One reason to do this could happen when a die is made up of several identical
units (for example, a quad processor) and during die testing, it is determined that
only (say) dies 1 and 2 are properly functional. So, this die can be placed into a
smaller package and only those two die are wired up to package pins. However, the
die may have a full Boundary-Scan implementation inside it that doesn’t even know
about the “quad” nature of the device. Further, some of the die pads need to be con-
nected to voltage levels (power/ground are obvious) or left open. So, in the device
pin mapping, these otherwise abandoned ports are tagged with “open” or “tie” key-
words. For example, some unused input pads may be left unbonded (floating) so
they are marked “open”, meaning software should not predict a logic value being
captured on the associated Boundary register cell. Or, an input may be tied to
ground, so it could be marked “tie0”, meaning it will always capture a ‘0’. Similarly,
device outputs could be marked “open”, meaning the associated Boundary register
cells do not actually control anything—although if they are self-monitoring, soft-
ware could look for data if it so chose to do so.
11.4 Revisions to BSDL 407

Note it is an error to encode, for example, a port as “tie1” when its port type is
“power_0”, as this implies you have a logic ‘1’ level tied to ground. The three
new keywords are not allowed in association with the TAP signals TCK, TDI,
TMS and TDO. It is allowed to associate “tie1” or “open” with the TRST* TAP
signal, provided the device has an on-chip power-on reset capability. If a port
appears in a compliance port list then it cannot have “open” assigned to it—and if
such a port is set to “tie0” or “tie1”, then that should produce a compliance enabling
conditions.
Here is a partial BSDL description for an 8-bit register die that can be mounted
in either a full 8-bit package, or a 4-bit “nibble” package:
attribute PIN_MAP of ttl74bct8374: entity is
PHYSICAL_PIN_MAP;
constant Pack8:PIN_MAP_STRING:=
"CLK:1, Q:(2,3,4,5,7,8,9,10), " &
"D:(23,22,21,20,19,17,16,15), " &
. . .
constant Pack4:PIN_MAP_STRING:=
"CLK:9, Q:(open, open, open, open, 16, " &
" 17, 18, 19), " &
"D:(tie0, tie0, tie0, tie0, 2, " &
" 1, 26, 25), " &
. . .

In this example, the bit_vector ports Q and D both have 8 elements. In the P8
mapping, both are assigned 8 unique pins. In the P4 package, 4 of the Q output
ports are “open” and 4 of the D input ports are tied low. The remaining ports have
pins assigned.

11.4.12 Register Access Description

The <register access description> syntax (see Sect. A.2.3) has been changed to
account for new “standard variable registers”, as differentiated from “standard fixed
registers”. Standard fixed registers are defined by the standard and all except the
Boundary register have a fixed, defined length. For example, the Bypass register is
always exactly one bit long, and the Device ID register is always 32 bits. A standard
variable register is defined by the standard (example, ECID) but its length and orga-
nization are variable from device to device. As before, there may be “design-specific
registers” which are not defined by the standard, but are allowed to be included in
the design and described (minimally) by BSDL.
Note that the <reg length> syntax item may now be an <integer> or filled in with
an asterisk (*), which is called a deferred length descriptor. If the length is deferred,
it must be specified later in either a register field description, or a register assembly
description.
408 11 IEEE 1149.1: The 2013 Revision

With the 2013 release, the Boundary register may now be of variable length27 due
to the segment exclusion capability.
As before, in the case of instructions marked “private”, they may optionally be
omitted from the register access description. If documented, they are required to
have a length specification, but it could be given there (as an <integer>) or specified
later with register descriptions.

11.4.13 Boundary Register Specification Changes

The portion of BSDL that describes the Boundary register has been changed. First,
it is now able to describe “fixed” as well as “segmented” Boundary registers as
described in Sects. 11.4.14 and 11.4.15. So the syntax for the <boundary-scan reg-
ister description> seen in Sect. A.4 has also changed as described in Sect. A.2.4.
Next, the <cell entry> description has been augmented, with a new ability to
describe how input cells behave under certain connection conditions. The new
<input spec> syntax adds new keywords EXPECT0, EXPECT1, EXTERN0,
EXTERN1, OPEN0, OPEN1, OPENX, PULL0 and PULL128 in this area of the
description (see Table 11.3). These <input spec> keywords are associated with cell
functions of INPUT or CLOCK only, and describes what is captured by a cell when
the input pin is unconnected. A cell is unconnected when the pin is not connected to
a board signal, or when it is marked “Open” in a package mapping (Table 11.3).

Table 11.3 Input specification keyword meanings

Input specification
keyword Meaning
EXPECT0 A fault detector circuita feeds this cell with ‘0’, indicating no-fault
EXPECT1 A fault detector circuit feeds this cell with ‘1’, indicating no-fault
EXTERN0 The unconnected input requires an external pull down which should be
provided on the board
EXTERN1 The unconnected input requires an external pull up which should be
provided on the board
OPEN0 An unconnected input will perceive ‘0’
OPEN1 An unconnected input will perceive ‘1’
OPENX An unconnected input will not (reliably) perceive either a ‘0’ or ‘1’
PULL0 The input has a weak pull down on-chip
PULL1 The input has a weak pull up on-chip
a
A fault detector is some internal monitor being observed. For example, some differential receivers
have a “cable connected” signal that indicates the receiver is connected to a differential driver. If
the cell is marked “Expect1”, then capturing a ‘1’ means a cable is indeed connected

27
Note the syntax shows the Boundary register as belonging to the set of standard fixed registers.
This is because its length is not described in the register access description area, but is described
later as shown in either of Sect. 11.4.14 or 11.4.15.
28
Note Pull0 and Pull1 already exist in the <disable result> field which is associated with drivers.
11.4 Revisions to BSDL 409

Board defects, such as broken traces or missing solder joints may cause cell dis-
connection. Knowing that an unconnected pin has a particular behavior can assist in
diagnosing such defects.
Take care, however, with inputs connected to upstream drivers that may be dis-
abled. What is the disabled driver’s leakage current while disabled? How might that
be perceived by an input marked (say) PULL0 or PULL1? Having these keywords
will help in many situations where, in the past, we could only assume “X” for a
cell’s content during testing. If we know a cell will actually contain predictable data
when it is open, we can find more defects. For example, if a device input pin is not
connected to a board signal (that is, its defect-free condition is open), it has an input
specification of Open1, and, a solder defect is shorting the pin to ground, then a test
will see a constant ‘0’ captured in the cell and can make a diagnosis. In the past we
would have predicted “X” and no fault would have been detected.
What is captured by a PULL0 input cell connected to a PULL1 driver that is
disabled? Again, it is not clear, and making a prediction either way could be an
error, so it is still an “X” in this situation.
Finally, the disable result keywords (see Table 2.3 on page 77) has been augmented
with two new values: Open0 and Open1. These values are only used in conjunction
with bidirectional signals where the on-chip driver is disabled and no board-level
signal is present. A single-cell bidir (like a BC_7) needs a disable spec, but also, we
would like to describe its input specification as well. This addition allows this.

11.4.14 Fixed Boundary Register Description

Fixed Boundary register description is almost the same as in the pre-2013 versions
of BSDL. See the example shown in Sect. 2.3.13. This example is repeated here,
showing how the 2013 changes would appear in the register description.29

attribute BOUNDARY_LENGTH of ttl74bct8374 : entity is 18;

attribute BOUNDARY_REGISTER of ttl74bct8374 : entity is

-- num cell port function safe [ccell disval rslt]
"17 (BC_1, CLK, input, X, PULL0)," &
"16 (BC_1, OC_NEG, input, X, OPEN1)," &
"16 (BC_1, *, control, 0)," &
"15 (BC_1, D(1), input, X, PULL1)," &
"14 (BC_1, D(2), input, X, PULL1)," &
"13 (BC_1, D(3), input, X, PULL1)," &
"12 (BC_1, D(4), input, X, PULL1)," &
"11 (BC_1, D(5), input, X, PULL1)," &

29
The input specifications added are speculative on the part of the author—only the IC designer
would know the correct values. They are added for illustration.
410 11 IEEE 1149.1: The 2013 Revision

"10 (BC_1, D(6), input, X, PULL1)," &

"9 (BC_1, D(7), input, X, PULL1)," &
"8 (BC_1, D(8), input, X, PULL1)," &
"7 (BC_1, Q(1), output3, X, 16, 0, Z)," &
"6 (BC_1, Q(2), output3, X, 16, 0, Z)," &
"5 (BC_1, Q(3), output3, X, 16, 0, Z)," &
"4 (BC_1, Q(4), output3, X, 16, 0, Z)," &
"3 (BC_1, Q(5), output3, X, 16, 0, Z)," &
"2 (BC_1, Q(6), output3, X, 16, 0, Z)," &
"1 (BC_1, Q(7), output3, X, 16, 0, Z)," &
"0 (BC_1, Q(8), output3, X, 16, 0, Z)";

Note that cell 17 now has a fifth “Pull0” word, which says the CLK input, if
unconnected, will load a ‘0’ into cell 17 upon every capture. There are two lines of
description for cell 16, due to its in/output control merger. The first gives its nature
as an input, and the cell will capture a ‘1’ if the pin is open. This would also imply
that the eight data outputs would be enabled if the OC_NEG input was left uncon-
nected. The second line of cell 16 description is unchanged, as this line describes it
control nature. Cells 9–15 are input cells, and they have “Pull1” words added, to
indicate that the data inputs will capture ‘1’ data if left unconnected. The eight data
outputs (cells 0–7) disable to ‘Z’ as before. Other values such as “Pull1” or “Weak0”
could appear there. However, “Open0” or “Open1” could not since these eight pins
are neither bidirectional nor self-monitoring.

11.4.15 New Segmented Boundary Register Description

The existence of excludable segments in a Boundary register requires new

descriptive capabilities in BSDL. Thus, BSDL now supports the description of
Boundary register segments, some of which may later be described30 as excludable.
(The syntax for this description is seen in Sect. A.2.4.) Note that perhaps none of the
segments are excludable, but they could still exist if (say) the segments were deliv-
ered by independent IP providers. Yes, the IC designer could re-write such segments
into the fixed form seen in Sect. 11.4.14 and remove the complexity if desired, but
then, there is no requirement for that to happen. In the working group, there were
discussions about how IP (and nested IP) can complicate BSDL descriptions, and,
how nice it would be if the IC designer “flattened” the BSDL into a single level, like
we enjoyed in the pre-2013 times. That however has its own problems. First, it is
work for the IC designer; second, it puts some support issues that may have been the
IP provider’s responsibility on the IC designer’s back; it complicates updates that an
IP provider might issue; and, there is the real issue of the errors that might occur
during the flattening process—who made the error?

30
The excludable segments are revealed in the register assembly description.
11.4 Revisions to BSDL 411

Here is an example of an IC called IC_NSEW with segments, four of them in this

case. Imagine it has four “sides” to it, imaginatively named “North”, “East”, “South”
and “West”. Further, three of them are basically identical and the 4th is excludable.
Here is its description.

Attribute ASSEMBLED_BOUNDARY_LENGTH of IC_NSEW:entity

is (17, 22); -- Min length 17, Max length 22

Attribute BOUNDARY_SEGMENT of IC_NSEW : entity is

"North [5] ("&
-- num cell port function safe [ccell disval rslt]
"4 (BC_1, *, controlr, 1 ), "&
"3 (BC_1, N_D(1), input, X, PULL0), "&
"2 (BC_1, N_D(0), input, X, PULL0), "&
"1 (BC_1, N_Q(1), output3, X, 10, 4, PULL0), "&
"0 (BC_1, N_Q(0), output3, X, 10, 4, PULL0)), "&
"South [5] ("&
-- num cell port function safe [ccell disval rslt]
"4 (BC_1, *, controlr, 1 ), "&
"3 (BC_1, S_D(1), input, X, PULL0), "&
"2 (BC_1, S_D(0), input, X, PULL0), "&
"1 (BC_1, S_Q(1), output3, X, 10, 4, PULL0), "&
"0 (BC_1, S_Q(0), output3, X, 10, 4, PULL0)), "&
"West [5] ("&
-- num cell port function safe [ccell disval rslt]
"4 (BC_1, *, controlr, 1 ), "&
"3 (BC_1, W_D(1), input, X, PULL0), "&
"2 (BC_1, W_D(0), input, X, PULL0), "&
"1 (BC_1, W_Q(1), output3, X, 10, 4, PULL0), "&
"0 (BC_1, W_Q(0), output3, X, 10, 4, PULL0)), "&
"East [5] ("&
-- num cell port function safe [ccell disval rslt]
"4 (BC_1, *, controlr, 1 ), "&
"3 (BC_1, E_D(1), input, X, PULL0), "&
"2 (BC_1, E_D(0), input, X, PULL0), "&
"1 (BC_1, E_Q(1), output3, X, 10, 4, PULL0), "&
"0 (BC_1, E_Q(0), output3, X, 10, 4, PULL0)) ";

At this point, we don’t know which (if any) segment is excludable. We see four
segments, each of five bits. Yet the length min/max is 17/22, so some sort of exclud-
ability must be present. We also see unique port names, like E_D(0) or N_Q(1),
uniquely in each segment. Each segment has a cell table that starts numbering at 0,
up to 4. The driven ports all have control cells with the number ‘1’, and there are
four of them. Each cell table is an independent description. When the actual
Boundary register is assembled from these segments, then we get a new table with
sequential numbers, but we don’t yet know the ordering. Finally, why are there 22
cells for the maximum length, and 17 for the minimum?
412 11 IEEE 1149.1: The 2013 Revision

There are 20 cells described in the four segments. One segment is excludable,
and there are two additional cells used for domain control and segment selection.
That’s where 22 comes from, but we won’t see them until the register assembly of
the Boundary register is described, in the following section.

11.4.16 New Boundary Register Assembly

The assembly of a Boundary register from segments is a part of the overall register
assembly description discussed in Sect. 11.4.21. The Boundary register uses a small
portion of the assembly description capability, so, let’s finish the example
IC_NSEW of the previous section while it is still freshly in mind.

Attribute REGISTER_ASSEMBLY of IC_NSEW : entity IS

"Boundary ( "& -- This instantiates the BReg
"(North IS North), "& -- This identifies segment 1
"(South IS South), "& -- Second segment
-- The next three lines describe a domain control
-- cell and segment selection cell.
"(PowerUp IS DomCtrl Domain(PwrEast) TAPReset), "&
"(East_Start IS SegSel Domain(PwrEast) "&
"Segment(SegEast) TAPReset), "&
"(East IS East), "& -- The excludable East segment
-- The next line shows the zero-length segment MUX
"(East_End IS SegMux Segment(SegEast)), "&
"(West IS West) )" ; -- Fourth segment

In a register assembly, the segment listed first is closest to TDI and the last seg-
ment listed will drive TDO. Within each segment, the cells can be listed in any
order, with the cell number identifying their actual order in the segment, with cell 0
being closest to TDO. Note all cell numbers must appear the tables.
The domain control cell is named PowerUp and controls a domain labeled
PwrEast. This cell is reset by TAPReset, so at power up, the PwrEast domain will
not have power. The segment select cell is named East_Start, it includes/excludes a
segment labeled SegEast, it resides in the PwrEast domain, and it is reset by
TAPReset. At power on, the segment SegEast is excluded. This cell should capture
the state of a PwrEast bit that we can look at to see if the domain is powered.
Now, what does the Boundary register look like with the East segment excluded?
Something like this31:

-- num cell port function safe [ccell disval rslt]

"16(BC_1, *, controlr, 1 ), "&
"15(BC_1, N_D(1), input, X, PULL0), "&

31
This is a visualization which is fairly close to a static cell table, except the domain control and
segment select cells (6 and 5) are descriptors since no such concept exists in static tables.
11.4 Revisions to BSDL 413

"14(BC_1, N_D(0), input, X, PULL0), "&

"13(BC_1, N_Q(1), output3, X, 16, 1, PULL0), "&
"12(BC_1, N_Q(0), output3, X, 16, 1, PULL0)), "&
"11(BC_1, *, controlr, 1 ), "&
"10(BC_1, S_D(1), input, X, PULL0), "&
"9 (BC_1, S_D(0), input, X, PULL0), "&
"8 (BC_1, S_Q(1), output3, X, 11, 1, PULL0), "&
"7 (BC_1, S_Q(0), output3, X, 11, 1, PULL0)), "&
"6 (< the domain control cell >), "&
"5 (< the segment selection cell >), "&
"4 (BC_1, *, controlr, 1 ), "&
"3 (BC_1, W_D(1), input, X, PULL0), "&
"2 (BC_1, W_D(0), input, X, PULL0), "&
"1 (BC_1, W_Q(1), output3, X, 4, 1, PULL0), "&
"0 (BC_1, W_Q(0), output3, X, 4, 1, PULL0)) ";

Cells 5 and 6 are the segment and domain control cells and appear between the
West signals and the South signals. Of course, no East signals are listed since that
segment is excluded.
So, what does the Boundary register look like with the East segment included?
Like this:

-- num cell port function safe [ccell disval rslt]

"21(BC_1, *, controlr, 1 ), "&
"20(BC_1, N_D(1), input, X, PULL0), "&
"19(BC_1, N_D(0), input, X, PULL0), "&
"18(BC_1, N_Q(1), output3, X, 21, 1, PULL0), "&
"17(BC_1, N_Q(0), output3, X, 21, 1, PULL0)), "&
"16(BC_1, *, controlr, 1 ), "&
"15(BC_1, S_D(1), input, X, PULL0), "&
"14(BC_1, S_D(0), input, X, PULL0), "&
"13(BC_1, S_Q(1), output3, X, 16, 1, PULL0), "&
"12(BC_1, S_Q(0), output3, X, 16, 1, PULL0)), "&
"11(< the domain control cell >), "&
"10(< the segment selection cell >), "&
"9 (BC_1, *, controlr, 1 ), "&
"8 (BC_1, E_D(1), input, X, PULL0), "&
"7 (BC_1, E_D(0), input, X, PULL0), "&
"6 (BC_1, E_Q(1), output3, X, 9, 1, PULL0), "&
"5 (BC_1, E_Q(0), output3, X, 9, 1, PULL0)), "&

"4 (BC_1, *, controlr, 1 ), "&

"3 (BC_1, W_D(1), input, X, PULL0), "&
"2 (BC_1, W_D(0), input, X, PULL0), "&
"1 (BC_1, W_Q(1), output3, X, 4, 1, PULL0), "&
"0 (BC_1, W_Q(0), output3, X, 4, 1, PULL0)) ";
414 11 IEEE 1149.1: The 2013 Revision

In this description we see all signals listed, but starting with the segment select
and domain control cells, we see they are re-numbered, to account for the insertion
of the East cells. Thus, the output signal N_Q(0) gets its data from a cell numbered
17 and is enabled by a cell numbered 21 when the East segment is included. But
when East is excluded, N_Q(0) gets its data from a cell numbered 12 and is enabled
by a cell numbered 16. This is why we need computers, to keep track of it all.

11.4.17 New System Clock Requirements Attribute

As time has progressed with Boundary-Scan technology, we have seen ICs devel-
oped where some amount of system clocking32 is needed to keep parts of the cir-
cuitry working, even in test mode. The 1149.1 working group has acknowledged
this truth and implemented a way in BSDL to describe where such clocking is
needed. This is the new SYSCLOCK_REQUIREMENTS attribute and the syntax is
detailed in Sect. A.2.5.
Here is an example of this attribute:

Attribute SYSCLOCK_REQUIREMENTS of MyChip : entity IS

"(F155MHz, 150.0e6, 160.0e6, ECIDCODE, INIT_RUN), "&
"(SerDesClock, 198.5e6, 201.5e6, SERDES_LOOPBACK, "&
SERDES_BER) ";

This example shows us that a total of four instructions, ECIDCODE, INIT_RUN,

SERDES_LOOPBACK and SERDES_BER require clocking. The first two are
standard instructions that require a clock signal to be applied at the port33 named
F155MHZ, and it should be between 150 and 160 MHz. The second two instruc-
tions are provided by the device designer for some sort of on-chip test support34 and
they require a fairly accurate frequency (between 198.5 and 201.5 MHz) on an input
port named SerDesClock.
Test engineers must decide when to make use of clocks, and a principle value of
this attribute is to alert them that clocks may be required, on which pins, for which
functions, and at what frequencies. It is possible that such clocks will need to be
shut off at one point in testing, and later turned on in other points in testing, due to
disruptive noise they may induce in the board being tested. Turning on clocks may
also lead to heat dissipation problems that the test engineer will need to plan for.

32
Note, this does not include the TCK clock.
33
The test engineer may have to provide this frequency from the tester or test fixture, or, he may
need to allow the board to provide it with its own oscillator that he must enable when needed.
34
We can guess from the names that they are for loopback and Bit-Error rate tests of some SerDes
channels.
11.4 Revisions to BSDL 415

11.4.18 Enhanced Register Description

The next five sections (Sects. 11.4.19 through 11.4.23) introduce new (optional) attri-
butes that greatly enhance the amount of information that BSDL can convey about
the structure, construction and content of test data registers. This information is ulti-
mately accessible to PDL routines (see Sect. 11.5) that can read/write or otherwise
manipulate the data. This data can be supplied at the entity level (the IC level) or at
the IP level, in the form of user-supplied packages. In the latter case, an IC integrator
may obtain IP from an external supplier that (for example) provides a proprietary I/O
functionality. The IP will supply the circuitry needed for this functionality, and, also
some portions of the Boundary-Scan circuitry needed to implement 1149.1 for that
I/O. This can amount to some Boundary register cells for drivers and receivers, and
perhaps some Init_Data register cells for providing setup information for those driv-
ers and receivers. The IP supplier does not know the overall IC functionality or which
I/O pins of that IC his IP will end up providing. When the IC designer integrates the
IP into the IC, then the I/O pins become known, as well as the position of the inte-
grated IP cells within the Boundary register and Init_Data register.
This new register descriptive capability can also be used to describe some amount
of mission functionality that may be useful for advanced functional testing of certain
device functions. A prominent example is for complex I/O functions that may be
capable of producing and receiving data via I/O protocols, such as “Serialize/
Deserialize” protocols35 (often abbreviated as “SerDes”). Indeed, some PLA-type
devices may offer a selection of protocols on I/O pins. Thus, by programming certain
bit patterns into various segments of an Init_Data register, you may be able to select
an I/O protocol, its voltage swing and clock settings for some of the pins on a device.
Then, a functional test can use this setup for testing the performance of the pins.

11.4.19 New Register Mnemonics Description

Register mnemonics provide a way to name bit patterns that can be assigned to
registers, or fields within registers. The name given is a <mnemonic identifier> (see
Sect. 11.4.5 and the syntax in Sect. Sect. A.1.4) and with it an <information tag>
(see Sect. 11.4.6 and the syntax in Sect. A.1.5) can be associated.
The new idea here is that we may need to know about the content of registers
used to set up working parameters for a test. The Init_Data register (see Sect. 11.3.4.2)
is the most obvious example, where data fields within this register may be used to
select driver voltage swings, receiver thresholds, functional I/O protocols, PLL fre-
quencies, etc. In pre-2013 Boundary-Scan, we only know that a register is targeted

35
Some examples are: Serial Advance Technology Attachment (SATA), 10 Gbps Attachment Unit
Interface (XAUI) and Serial RapidIO (SRIO).
416 11 IEEE 1149.1: The 2013 Revision

by a given instruction, and that it has some fixed length. Now we can see that the
register has a definite structure (see Register Fields in Sect. 11.4.20) with named
fields and we can label and identify bit patterns in these fields. The labels will (hope-
fully) have meaningful names like “725millivolts”36 rather than just raw bit patterns
like “0x6”. Tool makers can read the mnemonic information and combine it with
register field information to give users friendly GUI displays of the Init_Data regis-
ter content, what can be selected for each field and the tag information can also fill
in what the intent of the content is. The actual bits and how they are stored in the
register is a bookkeeping job for software to manage.
The syntax details for register mnemonics is given in Sect. A.1.6. Here is a simple
example of a single register mnemonic description:

attribute REGISTER_MNEMONICS of INIT_Example:entity is

"SerDesClockSettings ( "& -- Only 2 settings work
"135MHz (0x07) <135 MHz SerDes Clock>, "&
"110MHz (0x15) <110 MHz SerDes Clock>, "&
"Invalid (Others) <Undefined - DO NOT USE!>"&
" )" ;

In this example, we see a single mnemonic group name of “SerdesClockSettings”

with three entries:
1. The first is called “135MHz” is associated with a hex pattern 0x07 and has an
information tag “135 MHz SerDes Clock”.
2. The second entry, similarly, says the name “110MHz” is associated with a hex
pattern 0x15 and has an information tag “110 MHz SerDes Clock”.
3. The final entry is called “Invalid” which is associated with all other unused pat-
terns and has an information tag “Undefined—DO NOT USE!”. At this point we
do not know how many patterns that would be since the field the patterns will be
assigned to is not yet known. (That happens in the Register Fields description.)
Let’s continue the example with a more complex statement:

attribute REGISTER_MNEMONICS of Serdes:package is

"ONOFF(ON (1) <Enable>, " &
" OFF (0) <Off>), " &
"CMV ( 0V (1) <Low power mode voltage>, " &
" 500mV (0) <Mission common-mode voltage>),"&
"SWING(900mV (0b11) <Driver Output Swing, mV pp>,"&
" 800mV (0b10), " &
" 700mV (0b00), " &
" 600mV (0b01))" ;

36
Note this <mnemonic identifier> starts with a digit, which would not be allowed with a VHDL
identifier. The working group felt VHDL rules were too constraining in this context.
11.4 Revisions to BSDL 417

In this example, three mnemonic groups are named, ONOFF, CMV and SWING,
with 2, 2 and 4 mnemonic identifiers listed respectively. In this example, this attri-
bute is described within a package called “Serdes”, whereas in the previous exam-
ple, the attribute was defined at the entity level. The entity level is where an IC is
described, while a package is where IP provided by some supplier used in an entity
is described.

11.4.20 New Register Fields Description

The syntax for register fields description is found in Sect. A.2.7, and it is complex.
Here are a number of examples with some drawings here to illuminate what is
going on.
The first is very basic. In Fig. 11.9 we see an IP that is being integrated into an
IC that implements some memory function, and this IP includes a memory test
capability that we can access from the 1149.1 TAP, via a MemTest register. This
register is divided into three fields. There is a 4-bit TestSelect field in the top bits,
followed by a StartTest bit used to initiate a test, and in the lowest bits, a 2-bit
TestStatus field. To run the test, you first scan in some algorithm control bits into the
TestSelect field, but a ‘0’ into StartTest and the bits that get sent to TestStatus are
ignored (it’s read-only). Next we scan in those same bits, except we put a ‘1’ into
the StartTest field. We then wait for a while and do another scan with those same
bits, but now we are interested in the TestStatus bits that come out. We check to see
if the test is complete, and whether it passed.

MemTest
Register

From Towards
6 5 4 3 2 1 0
TDI TDO

TestStatus
TestSelect Field
Field
StartTest
Attribute REGISTER _FIELDS of MemTest :Package is
“MemTest [7](” & -- 7 bit MemTest controller
“(TestSelect [4] is (6 downto 3)),” & -- Algorithm control
“(StartTest [1] is (2)),” & -- Initiate
“(TestStatus [2] is (1 downto 0)))”; -- Read only status
RegField1

Fig. 11.9 A test data register and its description

418 11 IEEE 1149.1: The 2013 Revision

Here it would be nice to have some register mnemonics to help us clarify what is
going on. Here is a possibility:

attribute REGISTER_MNEMONICS of Serdes:package is

"ONOFF(Start (1) <Kick off the test>, " &
" Stop (0) <Stop the test unconditionally>),"&
"STATUS (Idle (0b00) <Test not running>, " &
" Running (0b11) <Test is in progress>, " &
" Passed (0b01) <Test complete, passed>," &
" Failed (0b10) <Test complete, failed>)," &
"TESTSEL (1-March (0b1100) <Marching 1 Test>, "&
" 0-March (0b1001) <Marching 0 Test>, " &
" GalPat (0b0111) <Gallop Pattern Test>,”&
" Reserved (Others) <Do not use.>)" ;

Given these mnemonics, we can improve the MemTest register field description
by adding a field option that assigns mnemonics, like so:

attribute REGISTER_FIELDS of MemTest:Package is

"MemTest [7]( " &
"(TestSelect[3] is (6 downto 3) TESTSEL(1-March)), "&
"(StartTest [1] is (2) ONOFF(Stop)), " &
"(TestStatus[2] is (1 downto 0) STATUS(-))) ";

Now we have friendly mnemonic names to display for test selection or status
examination; that is, when a test completes and we scan out the status, we can show
“Passed” as the result rather than “0b01”. In this description, the TestSelect segment
is associated with the mnemonic named TESTSEL, and it is defaulted to “1-March”.
The StartTest segment is associated with the ONOFF mnemonic and defaulted to
“Stop”. The TestStatus segment is associated with the STATUS mnemonic and it
has no default value—this segment is not written, just read back. Notice that the
information tags on a given mnemonic can also be displayed to the user for yet more
user-friendly meaning.
The example in Fig. 11.9 showed the bits of the 7-bit MemTest register organized
with each segment laid out contiguously, and the attribute mimicked this layout by
enumerating them in left-to-right sequence. However, when register cells are
“stitched” together by layout software, it can happen that the bits are organized in a
way more convenient to the layout algorithm37 and the bits are thus “scrambled” as
we would think of them. This is illustrated in Fig. 11.10.
In this organization, only the top two significant bits of TestSelect and the
StartTest bit are where they were before. Looking at the register fields description,
we see the segments listed in a different order. No matter—the key is the bit assign-
ments reflect the re-organized layout. It is a software responsibility to take a bit
pattern like “0-March” (which is 0b1001) and load them into the four bits of

37
For example, the layout algorithm may be optimizing layout area and metallization length.
11.4 Revisions to BSDL 419

MemTest
Register

From Towards
6 5 4 3 2 1 0
TDI TDO

TestSelect TestStatus TestSelect

Field MSBs Field Field LSBs
StartTest
Attribute REGISTER _FIELDS of MemTest :Package is
“MemTest [7](” & -- 7 bit MemTest controller
“(StartTest [1] is (2)),” & -- Initiate
“(TestSelect [4] is (6,5,1,0)),” & -- Algorithm control
“(TestStatus [2] is (4 downto 3)))”; -- Read only status
RegField2

Fig. 11.10 A re-organized MemTest register

MemTest’s TestSelect segment. In the first organization, MemTest would be

1001xxx, while in the scrambled organization, they would be 10xxx01.
The preceding examples list each bit exactly once across the three fields, but not
all bits are required to be listed. For example, if MemTest was actually 20 bits long
but only the bottom 7 bits are used in fields, that is allowed. Also, we might want to
add a new field “AllWriteable” that includes all the bits in StartTest and TestSelect.
We can reference the AllWriteable field for initializing those bits and then later
reference only the smaller fields when working with them only.
There are three types of field options that can optionally be associated with fields
and they appear after the bit listing. Briefly, these are:
1. A value assignment option which contains keywords:
(a) CAPTURES means the field always captures one or more fixed bits in the
Capture-DR TAP state. (Not compatible with the NOPI keyword.)
(b) DEFAULT is a field value to be used when there is no other required valued
for an intended operation—in other words, a value to be used rather than a
random or residual value. (Not compatible with the NOPO keyword.)
(c) SAFE is a field value to be used to keep system logic in a safe or non-
interfering state during testing. (Not compatible with the NOPO keyword.)
(d) RESETVAL is a field value that is placed in the field after a reset, and indi-
cates a reset signal is required (see reset assignment below).
(e) USER identifies a user keyword. The standard does not provide a rationale for
its use, but it is being used in the 2015 revision of the 1149.6 standard where
it attaches a keyword “Cap_Bypass_Control” to a field. (See Chap. 12.)
420 11 IEEE 1149.1: The 2013 Revision

2. A structural reset assignment option which contains keywords:

(a) PORRESET38 (Power-on Reset) means the register contents and primary
outputs change in response to the on-chip POR signal (the same that resets
the TAP).
(b) TRSTRESET, the register contents and primary outputs change in response
to the TRST* TAP signal being asserted.
(c) TAPRESET, the register contents and primary outputs change when the TAP
controller enters the Test-Logic-Reset state, even if there is a TMP controller
currently in the Persistence ON state.
(d) CHRESET (Clamp-hold Reset), the register content and primary outputs
change when the TAP controller enters the Test-Logic-Reset state and the
TMP controller is in the Persistence OFF state. (Not compatible with a
device that does not implement the TMP controller.)
(e) HIERRESET (Hierarchical Reset), the parallel output of a SEGSEL, when
contained in an excludable segment, is reset when the outer (containing) seg-
ment is excluded.
(f) DOMPOR (Domain Power-on Reset), the parallel output of a SEGSEL,
contained in an excludable segment that could be powered down. It is reset
when a power-up reset occurs in a domain.
(g) RESETIN (Local Reset), a register field reset by a local reset control cell
having the same identifier as this keyword.
(h) RESETOUT (Local Reset Control) is the output of a single bit field, of type
PULSE0 or PULSE1, which controls the reset of other register fields that
have the same identifier as this keyword.
3. A test data register structural type assignment option which contains keywords:
(a) NOPI (No Primary Input) means the register contents do not change during
the Capture-DR TAP state.
(b) NOPO (No Primary Output) means the TDR contents do not affect any func-
tional or test logic.
(c) NOUPD (No Update Stage) means the primary outputs (if any) of the TDR
may change during Shift-DR, but not at the Update-DR TAP states.
(d) MON (Self Monitoring) means the shift-capture stage of the TDR captures
the update stage output. This allows verification of the value currently driven
out. (Not compatible with NOPO and NOUPD.)
(e) PULSE0, a register field cell that, at Update-DR, goes low for a single TCK
cycle and returns to high, producing a high-low-high pulse. (Not compatible
with NOUPD and NOPO.)
(f) PULSE1, a register field cell that, at Update-DR, goes high for a single TCK
cycle and returns to low, producing a low-high-low pulse. (Not compatible
with NOUPD and NOPO.)

38
Yes, there are two Rs in the abbreviation, if not the name.
11.4 Revisions to BSDL 421

(g) DELAYPO, a register cell that delays any change that normally changes at
Update-DR, to two TCK cycles after that time. It is used to control potential
race conditions and is required for cells that control excludable or selectable
segments.
(h) NORETAIN, register field cells that may not retain their values when
excluded or not selected, including when not selected for scanning by the
current active instruction.
(i) SHARED, register field cells that are shared with mission mode functional-
ity and thus should not be scanned during mission mode operation.
(j) USER, as before in a value assignment (above) it attaches a user keyword to
a field.
4. A structural domain assignment option, used in register assembly descriptions
(see Sect. 11.4.21) which contains keywords:
(a) DOMAIN, the associated field are controlled, or controlled by named
domain, which has an on-chip power controller.
(b) DOMAIN_EXTERNAL, the associated field are controlled by the named
domain, which does not have an on-chip power controller.
(c) SEGMENT links with a specified name the SEGSEL with an associated
SEGSTART when a SEGSEL is not in the same TDR with the excluded
segment.
A register field description can name a known register defined by the standard, for
example, Device_ID, or ECID. In the first case, the length of the register is required to
be 32 bits. In the second case, the length must equal that shown in the Register_Access
attribute for the ECID_Code instruction, if it was actually specified there. If it was not
specified, that is, it was deferred “[*]”, then it must be provided in this description or
a subsequent register assembly description (see Sect. 11.4.21). Here is an example of
how the ECID register could be described in a register field description:

attribute REGISTER_FIELDS of MyCorp_ELA32:package is

"ECID[89] ( "&
"(ELA32_ID[16] IS (15 downto 0) Captures(0xE203)),"&
"(DateCode[14] IS (29 downto 16)Captures(201509)),"&
"(LotNum [11] IS (40 downto 30)),"& -- Encrypted
"(WaferID [20] IS (60 downto 41)),"& -- Encrypted
"(X_Loc[14] IS (74 downto 61)),"& -- Encrypted
"(Y_Loc[14] IS (88 downto 75))"; -- Encrypted

In this example, the attribute is provided in a user package, perhaps by the fabri-
cation factory for the device. The first two fields read out an IP identity code for the
device and its date (year/month) of fabrication. The next four fields give the lot
number, wafer ID name, and X/Y coordinates of the die.39 These are considered

39
This data might be set by masking options or by fusible links programmed at IC final test, or both.
422 11 IEEE 1149.1: The 2013 Revision

sensitive40 so they are encrypted. A board manufacturer could be asked to read out
the ECID and send it to the IC vendor, who could then decode the data for analysis.
There were two type assignments (Captures) included, but no others. For example,
in the last four fields, you could have seen NOPO or NOUPD listed. This, for most
testing purposes would be unnecessary clutter. It might only matter to the earlier
stages of the IP design where design consideration of the register fields are weighed.
In the syntax shown in Sect. A.2.7 we see several items having to do with “pre-
fix”. What are these? In modern designs, it is common to deal with design hierarchy
and IP from one source may incorporate IP from other sources, and those yet others,
such that when you want to refer to a field name deep down inside a design hierarchy,
you need to “get there” with a <prefix string> which may be set of <prefix identifier>
items separated with a period (.). Indeed, a design automation system may dump out
a listing of register bits like this41 as presented in 1149.1-2013:

510 TOP.n1.IO_Lane1.RX_cntl.deskew.Sequencer.state_machine_reg_Q(5)
509 TOP.n1.IO_Lane1.RX_cntl.deskew.Sequencer.state_machine_reg_Q(4)
508 TOP.n1.IO_Lane1.RX_cntl.deskew.Sequencer.state_machine_reg_Q(3)
507 TOP.n1.IO_Lane1.RX_cntl.deskew.Command_reg_Q(1)
506 TOP.n1.IO_Lane1.RX_cntl.deskew.Command_reg_Q(0)
505 TOP.n1.IO_Lane1.RX_cntl.deskew.Sequencer.state_machine_reg_Q(0)
504 TOP.n1.IO_Lane1.RX_cntl.deskew.Command_reg_Q(7)
503 TOP.n1.IO_Lane1.RX_cntl.deskew.Command_reg_Q(4)
502 TOP.n1.IO_Lane1.RX_cntl.deskew.Sequencer.state_machine_reg_Q(1)
501 TOP.n1.IO_Lane1.RX_cntl.deskew.Sequencer.state_machine_reg_Q(2)
500 TOP.n1.IO_Lane1.RX_cntl.deskew.Command_reg_Q(5)
. . . many skipped lines . . .
383 TOP.n1.IO_Lane2.RX_cntl.deskew.Sequencer.state_machine_reg_Q(5)
382 TOP.n1.IO_Lane2.RX_cntl.deskew.Sequencer.state_machine_reg_Q(4)
381 TOP.n1.IO_Lane2.RX_cntl.deskew.Sequencer.state_machine_reg_Q(3)
380 TOP.n1.IO_Lane2.RX_cntl.deskew.Command_reg_Q(1)
379 TOP.n1.IO_Lane2.RX_cntl.deskew.Command_reg_Q(0)
378 TOP.n1.IO_Lane2.RX_cntl.deskew.Sequencer.state_machine_reg_Q(0)
377 TOP.n1.IO_Lane2.RX_cntl.deskew.Command_reg_Q(7)
. . .

To interpret this data, we see register cell numbers (510, 509…) at the left. Then
the hierarchy is shown, as “TOP”, then “n1”, then “IO_Lane1”, then “RX_cntl” , etc/
until you finally reach a register bit name like “Command_reg_Q(1)”.42 Note that in
all the entries shown, “TOP” through “deskew” are always the same, except starting

40
Indeed, if sophisticated IC customers could see this, they might use this for their own yield
analysis to help them negotiate later contract pricing.
41
Only a small fraction is shown here. Apologies for the small font needed to make it fit.
42
While the leftmost register bits are numbered contiguously, the bit numbers you see in the indices
of registers are not. There is some data scrambling here.
11.4 Revisions to BSDL 423

at cell 383, we see “IO_Lane1” become “IO_Lane2”. Using PREFIX statements in

a register field description, we can greatly reduce some redundancy (and file size).
Here is a partial BSDL example to illustrate this:
attribute REGISTER_FIELDS of Big_Chip:Entity is
"Internal_Chain_Ex [511] ( "&
"(Prefix 0 TOP), "&
"(Prefix 1 n1), "&
"(Prefix 2 IO_Lane1), "&
"(Prefix 3 RX_cntl), "&
"(Prefix 4 deskew), "&
"(Sequencer.state_machine_reg_Q [6] IS "&
" (510,509,508,501,502,505)), "&
"(Command_reg_Q [5] IS "&
" (504,500,503,507,506)), "&
. . . many lines deleted . . .
"(Prefix 2 IO_Lane2), "& -- Prefix 3 & 4 deleted
"(Prefix 3 RX_cntl), "& -- and must be re-defined
"(Prefix 4 deskew), "& -- even if not changed
"(Sequencer.state_machine_reg_Q [6] IS "&
" (383,382,381,378, …)), "&
"(Command_reg_Q [5] IS "&
" (377,380,379, …)), "&
. . . many lines deleted . . .
" )";

In this example, the first PREFIX statements list, in ascending order, the prefix
names for each level of hierarchy from 0 (the top level) to 4, the lowest common
lower level. Below level 4 is one more level “Sequencer” for some “state_machine_
reg_Q” bits, and at level 4 are some “Command_reg_Q” bits. Before cell 383 is
described, PREFIX statements for levels 2–4 are re-issued. This overwrites “IO_
Lane1” with “IO_Lane2”, and the levels below “IO_Lane2 must be re-issued even
though they have the same names. The prefixes at levels 0 and 1 are unchanged.
Prefixes must always be provided in numerically ascending order, contiguously
from the starting level. If a prefix statement is issued with a minus sign (−) rather
than a name, then the prefix at that level and all levels below that (higher numbered)
are erased. In the example above, a “Prefix 3 (−)” statement would erase “RX_cntl”
and “deskew”, leaving just prefix levels 0, 1 and 2 in place.
To illustrate the simplification this gives, here is a bit of what the above attribute
would look like without the prefixes in place:

attribute REGISTER_FIELDS of Big_Chip:Entity is

"Internal_Chain_Ex [511] ( "&
"(TOP.n1.IO_Lane1.RX_cntl.deskew.Sequencer."&
"state_machine_reg_Q [6] IS "&
" (510,509,508,501,502,505)), "&
424 11 IEEE 1149.1: The 2013 Revision

"(TOP.n1.IO_Lane1.RX_cntl.deskew."&
"Command_reg_Q [5] IS "&
" (504,500,503,507,506)), "&
. . . many MORE lines deleted . . .
"(TOP.n1.IO_Lane1.RX_cntl.deskew.Sequencer."&
"Sequencer.state_machine_reg_Q [6] IS "&
" (383,382,381,378, …)), "&
"(TOP.n1.IO_Lane1.RX_cntl.deskew."&
"Command_reg_Q [5] IS "&
" (377,380,379, …)), "&
. . . many MORE lines deleted . . .
" )";

Yes, the prefix statements are a bit of overhead, but later references are shorter
and more readable.
Perhaps the most important application of register fields to a test engineer will be
for its use in describing the content of the Init_Data register (see Sect. 11.3.4.2).
A register fields description can handle the description of non-contiguous or scram-
bled bits to define registers that are later used in a register assembly description of
Init_Data, that may describe multiple occurrences and arrays of such registers, so a
realistic example is provided in the standard. This is what it looks like:

attribute REGISTER_FIELDS of INIT_Example:entity is

-- IP configuration register, see release document.
-- Done in a register field because of non-contiguous
-- bits. The PLL enable bits are used and the rest not
-- used for 1149 testing.
-- First define 15-bit Configuration register with two
-- subfields, IP_reg and PLL_Enable:
"Configuration [15] ("&
"(IP_reg [12] IS (14 DOWNTO 6,4,2,0) " &
"DEFAULT (0x0DB) NoPI), "& --Required for 1149
"(PLL_Enable [3] IS (5,3,1) SAFE "&
"(PLLConfigValues(PLLsoff)) NoPI)), "&
-- Next define 5-bit Channel register with two
-- subfields, Protocol and TX_Swing:
"Channel [5] ("&
"(Protocol [3] IS (2,0,1) "&
"DEFAULT (SerDes_Protocol(*))), "&
"(TX_Swing [2] IS (3,4) "&
"DEFAULT (SerDes_TX_Outputs(*)))), "&
-- Then define the 5-bit ChClock register:
"ChClock [5] ((Setting [5] IS (4 downto 0) "&
"DEFAULT SerDesClockSettings (100Mhz)))" ;
11.4 Revisions to BSDL 425

This code refers to some mnemonic names like “SerDes_Protocol” and

“PLLConfigValues” which must have appeared earlier. Some have bit pattern names
provided (like “100Mhz”) while others do not (they show “*”) which associates the
mnemonic name with the register without picking out a particular bit pattern. Note
also that the “IP_reg” subfield of the Configuration register is given a default value
of 0x0DB, which the comment tells us is needed to enable 1149 test behavior. A test
engineer will have to pick out values for “Protocol” and “TX-Swing” to make the
drivers work, and this will be determined by what those drivers are connected to on
the board. This example will be utilized in the next section that details an assembly
of a larger Init_Data register.

11.4.21 New Register Assembly Description

The register assembly description is used to define registers or segments of registers

by the concatenation of segments and/or fields some of which may be excludable or
selectable or within domains, in a specified order from TDI down to TDO. This
attribute is one of the more complex additions, and the material presented here gives
some of the reasoning for it and motivate what it is for—but, as always, you should
read the standard itself for all the details, particularly the rules, of which there are
29, some with multiple parts.
Here is a very simple example of a register assembly description, which uses the
Channel and ChClock field definitions found in the example in the section above
(Sect. 11.4.20).

attribute REGISTER_ASSEMBLY of INIT_Example:entity IS

"Init_Data (" & -- TDI
"(SerDesChannel_03 IS Channel), "&
"(SerDesChannel_02 IS Channel), "&
"(SerDesChannel_01 IS Channel), "&
"(SerDesChannel_00 IS Channel), "&
"(SerDesClk_0 IS ChClock))"; --TDO

In the above, we see Init_Data assembled from five register segments, starting
with the first, closest to TDI and the last closest to TDO. Now, the first four of these
segments are identical and contiguous, so, they could be more compactly described
with an array, as in the next example, which has an identical result.

attribute REGISTER_ASSEMBLY of INIT_Example:entity IS

"Init_Data (" & -- TDI
"(array SerDesChannel(3 downto 0) IS Channel), "&
"(SerDesClk_0 IS ChClock))"; --TDO
426 11 IEEE 1149.1: The 2013 Revision

In both these cases, no length specifications appear, we know the length of the
resulting register from the length details of the component segments. The length is four
copies of Channel (5 bits each for 20 bits) followed by ChCLock (5 bits) or 25 bits.
The 1149.1 standard has always allowed the sharing of register segments, to
compose registers of different lengths, with different names. See the example in
Fig. 11.11.
In this figure, three different instructions select Whole_Reg, Left_Reg or Right_
Reg. These three registers can be described by a register fields and register assembly
like this:

attribute REGISTER_FIELDS of MyChip:entity IS

"Left_Seg[3] ( "&
"(a[1] IS (2)), "&
"(b[1] IS (1)), "&
"(c[1] IS (0)) ), "&
"Right_Seg[3] ( "&
"(x[1] IS (2)), "&
"(y[1] IS (1)), "&
"(z[1] IS (0)) )";

attribute REGISTER_ASSEMBLY of MyChip:entity IS

"Left_Reg ((i1 IS Left_Seg) ), "& --Create i1
"Right_Reg ((i2 IS Right_Seg) ), "& --Create i2
"Whole_Reg ((i1), "& -- Reference i1
"(i2))"; -- Reference i2

Of course, the component stages A–C and X–Y could all be larger registers than
just one bit. Here, all the bits of Whole_Reg are specified in the assembly—as
required by a register assembly.
The following example is that of a reasonably complex Init_Data register. It uses
field definitions for Configuration, Channel and ChClock given in the previous exam-
ple in Sect. 11.4.20. (The mnemonics used must have been defined previously.)

From Instruction Decoder

Sel_L Sel_R
G
0 G
X Y Z 0
Towards
From
A B C 1
TDO
TDI 1

TDR Name Sel_L Sel_R Component Stages

Whole_Reg 1 0 A, B, C, X, Y, Z
Left_Reg 1 1 A, B, C
Right_Reg 0 0 X, Y, Z
RegField3

Fig. 11.11 Three registers composed from two segments

11.4 Revisions to BSDL 427

attribute REGISTER_ASSEMBLY of INIT_EXAMPLE:entity is

-- Register Assembly of INIT_DATA register
"Init_Data ( "& -- TDI
"(Reserved1[36]), " & -- First 36 bits unused.
"(VSEL_bits[5] "& -- VSEL observed in Init_Data,
-- must be set at power-up.
"Captures(IO_VSEL_Decodes(*)) NoPO), " &
"(IP_Config IS Configuration), " &
"(Array SerDesChannel(0 TO 5) IS Channel " &
-- SAFE values determined by IC designer,
-- not specified for IP.
"SAFE( SerDes_Protocol(off)) " &
"SAFE( Serdes_TX_Outputs(75%_Swing))), " &
"(Array SerDesClk(1 TO 2) IS ChClock), " &
"(Array SerDesChannel(6 TO 17) IS Channel " &
-- SAFE values determined by IC designer,
-- not specified for IP.
"SAFE( SerDes_Protocol(off)) " &
"SAFE( Serdes_TX_Outputs (75%_Swing))), " &
"(Array SerDesClk(3 TO 3) IS ChClock), " &
"(SerDesCXVddSel [1] -- Power level supplied to
-- SerDes internal gates
"DEFAULT (SerDesCXVddSelLevel(*)) NoPI), "&

"(SerDesSamplePowerUp [1] -- Powerup SerDes Test

-- Receivers during SAMPLE operation
"DEFAULT (SerDesSampleOvrd (off)) NoPI), "&
"(DDRTermSel [10] SAFE(0) NoPI), "&
"(Reserved2[8]), " & -- Reserved Field
-- TDO
") ";

An example of assembling a Boundary register has been given in Sect. 11.4.16.

Here is a more complex example of three excludable segments that make up “Reg2”,
with domain controls in a different register called “Reg1”. See Fig. 11.12.
This IC has an on-chip power controller that delivers power, when ordered, to
segments “SegA” and “SegB”. Segment “SegC” gets power from an external IC
pin, so in principle we do not have direct control over whether there is power there.
Two cells in Reg1 determine whether the power controller delivers power to SegA
and/or SegB. A third cell in Reg1 called “SSB” is the segment select cell for SegB
in Reg2; this is a case where segment exclusion is controlled by a cell not in the
same register as the excludable segment. Note that signals “PonA”, “PonB” and
“PonC” tell us when segments have power on, and are captured by the segment
select cells SSA, SSB and SSC. Because segment SegB is selected by SSB which is
not in Reg2, you will see a “SegStart” keyword, which tells us that there is no bit
there—that is, a SegStart is a zero-length entity.
428 11 IEEE 1149.1: The 2013 Revision

Dm1 Dm2 SSB

C C C Reg1
Reg1
SO
SI U U U On-Chip
Power
1149.1 Controller
Mission Sigs Gating
PA PB
PonA PonB
PwrB
PwrA
SegA + SegB +
SSA
Reg2 C C C C C C C C 1
1
SI U U U U U U U U
0 0

G G

External SegStart
Power Pin PonC For SegB
+ SegC
SSC
1 C C C C C C
Reg2 U U U U U U
SO 0

PwrDom

Fig. 11.12 A set of selectable segments in three different power domains

The register assembly description of this is shown next. Note there is a trailing reg-
ister association attribute (see Sect. 11.4.23) that tells us that SSC segment select bit is
associated with power port “Ext_Pwr_Pin”.
attribute REGISTER_ASSEMBLY of PwrDom:entity IS
"Reg1("& -- Two domain controls, 1 segment select
"(SegA_Pwr IS DomCtrl Domain(Dm1) CHReset), "&
"(SegB_Pwr IS DomCtrl Domain(Dm2) CHReset), "&
"(SSB IS SegSel Domain(Dm2) "&
"Segment(SegB) CHReset)), "&
"Reg2("& -- Three excludable segments, 2 seg selects
"(SSA IS SegSel Domain(Dm1) Segment(SegA) CHReset),"&
"(SegA[4]), "&
"(SegA_mux IS SegMux Segment(SegA)), "&
"(SSB_Start IS SegStart Segment(SegB) CHReset),"&
"(SegB[3]), "&
"(SegB_mux IS SegMux Segment(SegB)), "&
"(SSC IS SegSel Domain_External(Dm3) "&
Segment(SegC) CHReset), "&
"(SegC[5]), "&
"(SegC_mux IS SegMux Segment(SegC)) ";
11.4 Revisions to BSDL 429

C C C C C C
U U U U U U
From Seg2 M2 Towards
Seg1 M1 1 TDO
TDI F2
C C C C C C C C C C C C 1
C C C
U U U U U F1 U U U U U U U 0
U U U
0 G
SegIn Seg3 Seg4 SegOut
G

C C C C C
U U U U U
Seg5

RegAssy

Fig. 11.13 A register assembly with selectable fields

attribute Register_Association of PwrDom:entity is

"SSC : port(Ext_Pwr_pin) ";

Public user-defined registers may be made up of more complex structures than

simple exclusion of segments. Register pathways may have fanout points and have
several parallel paths that later recombine with multiplexors. These can get com-
plex, but one rule is the structure must be acyclic, that is, there is no feedback path
that would link a segment output back to its input, even if that path traverses other
segments. Figure 11.13 shows a register structure with three selectable pathways.
These start at the fanout points labeled F1 and F2. They later recombine at multi-
plexors M1 and M2.
Segments Seg2, Seg4 and Seg5 exist on unique paths. Segment Seg3 appears in
front of both Seg4 and Seg5. Segments SegIn and Seg1 are common to all paths, as
is the final segment SegOut.
Segment Seg1 has two bits, and these are segment select bits that control the
multiplexor switching. There are several ways to describe this with a register
assembly description. Here is a way which is considered “nested”:
attribute REGISTER_ASSEMBLY of Sel_Example:entity IS
"Seg_In2Out ("& -- TDI of overall register
"(SegIn [3]), "&
"(Seg1 [2]), "&
"(SELECTMUX "& -- This is M2
"(Seg2 [6]), "&
"(S345 IS Seg_345),"& --Seg_345 defined below
"SELECTFIELD(Seg1) SELECTVALUES((Seg2:0b1X)
(S345:0b0X))), "&
"(SegOut [3])), "& -- TDO of overall register
"Seg_345 ("& -- Now describe Seg_345
"(Seg3 [3]), "& -- Common to two paths
430 11 IEEE 1149.1: The 2013 Revision

"(SELECTMUX "& -- This is M1

"(Seg4 [4]), "&
"(Seg5 [5]), "&
"SELECTFIELD(Seg1) SELECTVALUES((Seg4:0bX1)
(Seg5:0bX0))))”;

This example lists the “Seg_In2Out” path first, which uses an as-yet undefined
variable “Seg_345”. Then “Seg_345” is defined next. These could have been
reversed which might make debug easier if there was a coding error that occurred
earlier in the code, but was not detected until later.
Now the same assembly could be coded in a “non-nested” way, by noting that the
two multiplexors in Fig. 11.12 essentially form a 3-to-1 selection function. It would
look like this:
attribute REGISTER_ASSEMBLY of Sel_Example:entity IS
"Seg_In2Out ("& -- TDI of overall register
"(SegIn [3]), "&
"(Seg1 [2], "&
"(SELECTMUX "& -- This is a 3-1 Mux
"(Seg2 [6]), "&
"(S34 IS Seg_34), "& -- Seg_34 defined below
"(S35 IS Seg_35) "& -- Seg_35 defined below
"SELECTFIELD(Seg1) SELECTVALUES((Seg2:0b1X)
(S34:0b01) (S35:0b00))), "&
"(SegOut [3])), "& -- TDO of overall register
"Seg_34 ((Seg3 [3]), (Seg4 [4])),"& --Seg3 defined
"Seg_35 ((Seg3), (Seg5 [5]))"; -- Seg3 referenced

Again in this example the definitions of “Seg_34” and “Seg_35” could have been
provided first.
Selectable fields also have the capability to shift data into more than one parallel
path while just one is being shifted out. For example, in Fig. 11.14 we see a pair of
identical IEEE 1500 assemblies inside an IC that are part of a register selection

WSPAWSPB
P1500 P1500
Assembly Assembly
Core Core
SI SO SI SO

3
2
WSP_Sel SO
1
SI C C 0
U U 1
G
0
BroadCast

Fig. 11.14 Broadcast data to parallel assemblies

11.4 Revisions to BSDL 431

structure. Since the assemblies are the same, you can load data into them both with
one set of scan operations. This might be a significant time saver, for example, if
you want each unit to run a set of internal BIST tests in parallel rather than
sequentially. Of course, when it is time to read out results, they will have to be
accessed sequentially.
The 3-bit WSP_Sel register selects which assembly will put data on the SO line.
Here is the description of this case:
Attribute REGISTER_MNEMONICS of MyIC_1500:entity is
"WSP ( "&
" None (0B00) <Bypass both WSPs>, "&
" WSP1 (0B01) <Select WSPA>, "&
" WSP2 (0B10) <Select WSPB>, "&
" Unused (0B11) <Do not use> );

Attribute REGISTER_ASSEMBLY of MyIC_1500:entity IS

"WIRE ((WIRE[0])), "& -- zero length
"Reg_1500_Parallel ( "&
"(WSP_Sel[2] DelayPO ResetVal(WSP(None)) "&
"TAPReset ), "& --selection register
"(SELECTMUX "& -- start list of segments43
"(WIRE1 is WIRE), "& -- zero length
"(ARRAY WSP(1 TO 2) IS P1500) "& --defined earlier
"SELECTFIELD (WSP_Sel) "& -- 3:1 selection
"SELECTVALUES ((WIRE1:None) (WSP(1):WSP1) "&
"(WSP(2):WSP2)) "&
"BROADCASTFIELD (WSP_Sel) "&
-- Always scan data into both WSPs when either
-- is selected.
"BROADCASTVALUES ((WSP(1),WSP(2):WSP1,WSP2)))";

In this example, the two broadcast statements identify the register used to select
the parallel elements, and which values of this register that will enable parallel load-
ing of which parallel elements. In this case, whenever either of the WSP units is
selected for TDO connection, both units are loaded with scanned in data.

11.4.22 New Register Constraint Description

The optional REGISTER_CONSTRAINTS attribute is used to facilitate test, debug,

and diagnosis by documenting constraints on values to be written to a TDR. This
attribute provides logical expressions that can be evaluated before a scan to a TDR

43
It is perhaps confusing that for excludable segments, the word SEGMUX identifies the location
of the exclusion mux, which terminates the segment. For selectable segments, the word
SELECTMUX marks the start of a list of parallel segments and SELECTFIELD marks the end.
432 11 IEEE 1149.1: The 2013 Revision

is performed. If the expression evaluates to TRUE, then that data should not be
scanned into the TDR, or, scanned in at your own risk.44 A severity level and infor-
mation tag are supplied with the expression to assist with such a decision. The
severities come in three levels: INFO, WARNING and ERROR—with ERROR
being indicative of action by the user, that is, they should not execute a scan. The
complete syntax is shown in Sect. A.2.9. Note that the logical expression formula-
tion is adopted from Sect. 11.2 of SystemVerilog [IEEE12a].
These expressions can be complex, allowing logical operators on True/False
variables, arithmetic operations, data shifting, and bitwise logical operations. It is
most likely that practical constraint equations will be simple logic statements. Here
are two examples adapted from the 2013 version of 1149.1.
In the first example, imagine an IC with two power domains A and B within it
which it controls—with the constraint, governed by circuit limitations, that only one
domain can be powered at any given time. The DomCtrl cells to enable power are
found in the Init_Data register by the field names PDA and PDB, and there is a
mnemonic “PwrOn” which requests power turn-on. But such a request cannot be
accomplished by the hardware. Here is the attribute:

attribute REGISTER_CONSTRAINTS of Init_Ex1:entity is

"Init_Data (" &
"((PDA=={PwrOn})&&(PDB=={PwrOn})) ERROR "&
"<Domains A & B cannot be ON at the same time.>)";

This expression shows a field PDA being logically compared (using the “==”
operator) to a mnemonic value PwrOn, which is surrounded by brace characters to
indicate it is a mnemonic. If both PDA and PDB are equivalent to the PwrOn mne-
monic, then the “&&” operator will see TRUE values on both sides and the expres-
sion is TRUE. This says an ERROR should be indicated, along with the information
tag explaining the situation.
It is becoming more common now to use the Boundary-Scan facility as a way to
configure functional tests. The second example shows a case where the Init_Data
register controls some functional parameters of some driver IP circuitry, namely, the
driver swing and transmission protocol. Here is an example of some information to
warn a test engineer about some limitations of the IP.
attribute REGISTER_CONSTRAINTS of My_SERDES:package is
"Init_Data (" &
"((TX_Swing=={200mv})&&(Protocol=={SRIO})) "&
" WARNING <A differential Swing of 200mv is not "&
"robust with SRIO. The driver will do it, but "&
"communication may have elevated error rates.> )";

44
You may have specific knowledge about what the constraint pertains to and why it could be
ignored, but in general, without such knowledge the condition should be avoided.
11.4 Revisions to BSDL 433

In this example, if a test engineer sets up the TX_Swing field in Init_Data to

drive out a 200 mv voltage swing, and also selects the SRIO communication proto-
col, a warning is given that this may not yield good results. The engineer can try
anyway, but the IP designer warned it might not work well. In general, the severity
of the constraint alert provided can be observed by tools, and the policy it uses to
react is a matter of tool design. The <information tag> in the statement can be dis-
played to the user, but probably cannot be interpreted by the tool.

11.4.23 New Register and Power Port Association Description

The Register_Association and Power_Port_Association attributes are both used to

provide information that may be useful for test debugging and defect diagnosis.
They give us clues as to what may be interacting with a test that will help us get
better results. They are separate attributes but are described here together due to
their similar nature and also similar syntax descriptions (see Sect. A.2.10).
Here is an example of a Register_Association that follows from the example
INIT_EXAMPLE given in Sect. 11.4.21, where these registers are defined.

Attribute REGISTER_ASSOCIATION of
Init_Example:entity is
"VSEL_bits (4) : port (PwrUp_IO_VSEL(4)), "&
"VSEL_bits (3) : port (PwrUp_IO_VSEL(3)), "&
"VSEL_bits (2) : port (PwrUp_IO_VSEL(2)), "&
"VSEL_bits (1) : port (PwrUp_IO_VSEL(1)), "&
"VSEL_bits (0) : port (PwrUp_IO_VSEL(0)), "&
"SerDesChannel(0) : port "&
"(IO_TXP(0),IO_TXN(0),IO_RXP(0),IO_RXN(0)), "&
"SerDesChannel(1) : port
"(IO_TXP(1),IO_TXN(1),IO_RXP(1),IO_RXN(1)), "&
. . .
"SerDesChannel(16): port
"(IO_TXP(16),IO_TXN(16),IO_RXP(16),IO_RXN(16)),"&
"SerDesChannel(17): port
"(IO_TXP(17),IO_TXN(17),IO_RXP(17),IO_RXN(17))";

So here we see the five read-lnly VSEL_bits enumerated, and each is observing
a power pin from the port bit_vector PwrUp_IO_VSEL. If we scan out the Init_
Data register and see a bad VSEL_bits value, we can “look up” what IC pin this
monitor was observing. The second section of the data shows how a group of 18
SerDesChannel controls are associated with differential I/O pin drive and receive
pairs. Thus if we see (say) a driver pair misbehaving, we can link it back to a
particular SerDes channel controller. In this example, we see the “Port” keyword in
434 11 IEEE 1149.1: The 2013 Revision

the association list. Other keywords, “Info”, “SysClock”, “User” and “Unit” may
appear. Here is what they mean:
1. Port: Links device pins to register bits that are in a control and/or observe rela-
tionship together, or have other more parametric effects. For example, a register
bit may enable/disable a pull-down on a device pin.
2. SysClock: Links device pins to register bits (like Port) but with the special inten-
tion of showing clocking relationships. The pins identified must have already
appeared in a SYSCLOCK_REQUIREMENTS attribute (see Sect. 11.4.17).
This list shows which register bits are clocked by which system clock pin.
3. Info: Links text strings (<info tag>) with register fields or bits. This allows label-
ing of fields and bits used in functional testing or BIST applications.
4. User: Allows a component supplier to provide one or more named lists of identi-
fiers or even text string with register fields or bits. This allows for design-specific
or tool-specific communication within a user community.
5. Unit: Links a “unit description” with a field for interpreting the value contained
in that field. The unit description is a machine-readable format standardized by
the IEEE 1451.0 standard [IEEE07].
An example of a unit specification is:
Attribute REGISTER_ASSOCIATION of MyChip : entity is
"frequency:unit(KHz "&
" {0x00808080807E8080808000 1.0E+3} ), "&
"phase:unit(ms "&
" {0x0080808080828080808000 1.0E-3} )";

The content of the hex string is documented in IEEE 1451.0, and is not human
compatible.
Next see an example of a Power_Port_Association attribute, where three refer-
ence voltage pins are mapped onto the pins they affect.
attribute POWER_PORT_ASSOCIATION of MyChip:entity is
"DDR_REF1:( DDR_DATA(3), "&
" DDR_DATA(2), "&
" DDR_DATA(1), "&
" DDR_DATA(0)), "&
"IO_REF1:( SERDES(0), SERDES(1)), "&
"IO_REF2:( SERDES(2), SERDES(3))";

In this example, power ports DDR_REF1, IO_REF1 and IO_REF2 provide ref-
erence voltages to a total of eight pins. If any of these pins should fail (during test
debug or actual testing) then this information can supply useful clues as to what
might causing the problem—sometimes an open solder joint on an isolated power
pin is the reason you can’t get a Boundary-Scan test on some signals to work.
11.5 The New “Procedural Description Language” (PDL) 435

11.5 The New “Procedural Description Language” (PDL)

The BSDL language has been around since 1994 (officially) to document the fea-
tures of an 1149.1 implementation within an IC. With the 2013 release, BSDL was
given much more structural information content about registers and the fields within
them, as well as data patterns (mnemonics) that can be used in those registers.
However, with the weak exceptions of the RUNBIST_EXECUTION and INTEST_
EXECUTION attributes (see Sects. 2.3.14 and 2.3.15), BSDL does nothing to
describe how activities are done. With the 2013 release of the standard, a Procedural
Description Language is introduced that allows the documentation of how to use
1149.1 registers and instructions.
Now, for operations using EXTEST for structural testing, or, reading out the
Device_ID register, the use of the instructions is basically inherent as it is part of the
“DNA” of the standard. But for non-standard public instructions, especially those
that can be used to support various gradations of functional testing, it is very impor-
tant to know how to set up and use such features.
In the earlier days of the standard, private features were inserted into 1149.1
implementations that the IC vendor might find handy for their own purposes. These
were hidden from the user’s view. However, in time, users became very vocal about
wanting to use those functions for the support of functional testing. For example, a
device might be able to produce a pseudorandom bitstream of data on a differential
driver, and another receiver (on that IC or a different IC on a board) might be able
to coordinate with that bitstream to perform a Bit-Error rate analysis on a differen-
tial receiver. Users would find out about this and demand access to such functional-
ity. For a while, such features were enabled by passing “secret” pattern sets around
that would set up and kick off such tests. It was very difficult to know what those
pattern sets were really doing, as they could amount to setting up private registers
(using private instructions), then loading new test instructions and doing more
scans, supplying a bunch of TCK and/or system clocks, then reading out data
(maybe using other instructions) to see if a certain bit pattern was observable some-
where in the sea of bits so obtained. This process is wildly prone to error, especially
when you have several IC you are trying to coordinate within a chain of several (or
many) other ICs that will need to stay “out of the way” while all this is going on.
There may be some number of instruction register scans interspersed with scores of
data register scans. How do manage this?
Procedural Description Language is an important step towards making functional
usage of internal IC facilities possible. Of course, IC vendors can still hide some of
their proprietary functions by declaring the related instructions “private”, but now
they have the option of documenting those instructions and their target registers and
register details to the general public (in BSDL) and how such facilities are used, in
PDL. PDL is intended to utilize the structural information provided by the new reg-
ister attributes (see Sects. 11.4.19 through 11.4.23) now available in BSDL. It is
used to describe how to load and/or unload register fields independent of packaging
level, that is, you can write a PDL for an entity (IC) or for a package (IP). It is
436 11 IEEE 1149.1: The 2013 Revision

intended that IP be supplied with PDL for its feature set, which can be utilized by
higher hierarchy levels, all the way to the IC level, without modification.
PDL follows the conventions of the (open-source) “Tool Command Language”
(Tcl)45 and designed to be an extension of Tcl. PDL is defined in two stages, called
Level-0 and Level-1. Briefly, Level-0 PDL does not allow embedded Tcl com-
mands, while Level-1 PDL does. (Later, Sects. 11.5.2 and 11.5.3 give rationale and
details of each.)
Level-0 PDL is intended to “keep it simple” so that it can describe straightforward
loading and unloading of registers or fields within. It is stated in the 2013 standard
that Level-0 is intended to support “load-and-go” automatic test equipment.46
Basically, this view of test is that of loading bit patterns into registers, passing from
Update-DR to Capture-DR and reading captured bits out for immediate comparison
to expected bits and recording simple pass/fail results. There is no passing of actual
readout data back for analysis, and only the most primitive if-then-else sequencing
of test activities. Basically, it supports pass/fail testing, perhaps as simplistic as
“stop-on-fail” testing at the point where a miscompare on scanned out data is first
seen. Such test schemes do have advantages of execution speed and throughput.
Level-1 PDL is intended to support more advanced diagnostic, debug and test
procedures where interactive or complex if-then-else action sequences are employed.
It is a superset of Level-0 PDL. It allows the full Tcl language for manipulating data
and making complex decisions. Basically, it is more of an interpretive approach and
will not normally achieve higher speed or throughput. None-the-less, it is very capa-
ble of sophisticated test activities, particularly those needed for functional testing.
The bottom line is PDL is the official language for documenting and exchanging
IEEE 1149.1-compliant procedures in a standard format. That said, PDL routines
could be called from or translated to other languages, if needed. The following dis-
cussion is a very brief description of the PDL language. Serious users of PDL should
always consult the standard for full details.

11.5.1 The PDL Use Model

PDL is an environment where we can describe what we want to do with a scan chain
in terms of loading fields within it with data to shift in, and data we expect to see
coming out. This means we need to specify target registers, and this in turn implies
an instruction that must be in the Instruction register. In the case where there may be
several instructions that target the same register, we need to specify which to use.
PDL is also an execution engine linked to test hardware that does the actual 1149.1
I/O protocols.

45
Often pronounced as “Tickle”, there is no standard for Tool Command Language. A websearch
for useful syntax guides currently yields these: http://wiki.tcl.tk/299 and http://wiki.tcl.tk/10259.
It is widely used in engineering circles for developing executable programming scripts.
46
The standard does not define what the term “load-and-go automatic test equipment” means.
11.5 The New “Procedural Description Language” (PDL) 437

Register iWrite stimulus data iRead expected data

Instruction X X X X X X X 0 1

Bypass 0

Device_ID 0 0 1 0 1

Boundary X X X X X

Init_Data X X X X X

My_TDR X X X X X
PDLFrame

Fig. 11.15 The PDL scan frame

iWrites For Level-1 PDL Only

Output Data
TDI Capture Data
N-1 2 1 0
(Sticky) Unit Under N-1 2 1 0
Test Fail Data
iReads
N-1 2 1 0
Expect Data TDO
0 Accumulating
N-1 2 1 0
Expect Mask Fail Flag
0 Local
N-1 2 1 0
Fail Flag
PDLFlow

Fig. 11.16 Data flow for the iApply command

To support this environment, a concept of a PDL scan frame is used, as shown in

Fig. 11.15. PDL contains this frame in memory, where each register (Instruction,
Bypass, Device_ID, etc.) is shown in two places, one for an iWrite action and a
second for an iRead action.
An iWrite action puts binary data bits into a field or whole register. An iRead
action specifies expected data for a register or field within it, in terms of 0/1/X bits.
A series of these actions can be performed, each putting some data into the frames in
various places, but, no hardware action is initiated until an iApply action is invoked.
The iApply action drives the stimulus data out into TDI of the target chain and reads
back data for processing from TDO. Figure 11.16 shows a diagram of what iApply
does. (Actually, iApply can be far more complicated, as will be seen later.)
The iApply action takes the specified output data and drives it serially into the
chain’s TDI. Simultaneously, it receives bits from TDO and records them in a cap-
ture data register. Also, the expected data and a data mask are used to see if there
are any differences in the TDO stream from the expected data. This is done by
438 11 IEEE 1149.1: The 2013 Revision

Exclusive-ORing the TDO stream with expected data and using the mask data to
zero-out bits that are don’t cares. Thus, when an iRead action is specified, it loads
0/1 data bits into the expect data register, and also 0/1 bits into the mask register.
Expected 0/1 bits load those bits into the expect data register, and ‘1’ bits into the
expect mask. Any ‘X’ bits produce ‘0’ bits in the mask, so that a difference at the
XOR gate for that bit position is zeroed-out. The fail data register records ‘0’ for
passing (matching) bits and ‘1’ for failing bits. Using captured data with failed data
gives us enhanced diagnostic information.
Figure 11.16 notes that the capture data and fail data registers are not used by
Level-0 PDL, only Level-1 uses this data. The two fail flag bits are all that Level-0
PDL sees. The “local” flag is set to ‘1’ if any bit failure is seen during a single iAp-
ply action and it is automatically initialized to ‘0’ at the start of each iApply action.
The “accumulated” flag is set to ‘1’ for any fails seen in a set of consecutive iApply
actions, and it must be explicitly set to ‘0’ before such a set is applied.
Note also that the output data, expect data and expect mask data registers have
data shifted into them during iApply. The output data register content is cycled back
to the register’s input, so upon completion, the original data is still there. This gives
“sticky” behavior to the output data register, meaning any new iWrite actions per-
formed will only update targeted fields and the rest is retained. The expect data and
mask registers are zeroed-out. Thus, for a new iApply action that occurs without
updating the expect registers with iRead actions, no failure will be indicated (the
mask is all-zero). There is an exception to this however; if a field has a “Captures”
specification, then the capture value will be restored to the field.
Now, just when you think you have command of these concepts, something
comes along to upset that view. What if the TDR that was recently updated with
iWrite/iRead actions is not the target of the presently loaded instruction? What
about segment exclusion and domain controls? Indeed, it is the responsibility of
iApply to keep track of this information (as part of the PDL scan frame data) and to
perform extra IR or DR scans such that the final result is achieved. For example, if
an iWrite puts new data into a register segment that is currently excluded, then that
means the excluded segment must be brought into the shift path before we can actu-
ally get the data into it. To do that may mean writing bits to a different TDR where
the domain and segment controls reside. But to do that will mean loading a different
instruction into the IR. Then the segment in the first TDR can be included with a
data scan that sets the needed bits, while keeping the other bits unchanged (they are
sticky). Once done, iApply must switch back to the first TDR again with another IR
scan to load the needed instruction. Now, finally, iApply can do the DR scan for the
iWrite data that started all of this.
So, a single iWrite/iRead can generate a lot of ancillary activity during a subse-
quent iApply. Indeed, Annex E in IEEE 1149.1-2013 contains a 2.5-page long block
of pseudo-code that in very condensed form lays out the iApply actions. It contains
13 if-then-else statements, a while-loop, and can exit with errors in two places.
A long note at the end of this passage warns the user that ambiguous results are
possible having to do with the order segments might be included. It offers some
clues to the PDL writer about how to remove potential ambiguities, but this is small
11.5 The New “Procedural Description Language” (PDL) 439

comfort. The downside of this is that two tool vendors could, in good faith, read the
same PDL but execution seen at the UUT level could be quite different between the
two. Could the end results be different as a consequence? If the difference was
consequential, who is “right”?
Being aware of this issue, a PDL coder could try to head off trouble by specify-
ing actions in other registers by expressly writing to them and issuing iApply
actions, one at a time rather than allowing iApply to do it all behind your back.
That’s a bit of pain, but it could lead to fewer support problems and finger-pointing
between users, IC vendors, IP providers and tool makers.

11.5.2 PDL Syntax Definition

PDL is a scripting language with some significant differences from BSDL that need
to be kept in mind. There is a liberal use of curly brace characters “{“ and “}” in
PDL which are called <L brace> and <R brace> in syntax descriptions.
First, it is important to know that PDL is a string of characters containing one or
more “commands”. These are separated by semicolons and newlines.47 Every com-
mand is composed of a sequence of “words”, where words are separated by “white
space”. White space is composed of spaces and horizontal tabulation characters.
Commands that exceed a comfortable line length can be expressed across multiple
lines by using “backslash-newline” characters. When a command is parsed, the
backslash-newline characters are eliminated (replaced with a space) so that the
entire command appears on a virtual line, before the command is then broken into
words. (Do not break an intended word into two words by careless use of backslash-
newlines when writing PDL.) The first word in the command is the name of a com-
mand processor. The processor is called to perform actions using the remaining
words in the command.
Once the command is broken into individual words, other substitutions are then
performed. A value substitution for words containing a dollar sign ($) is used to
replace a portion of a word with the value of an identifier. For example, here are two
words, each containing a dollar sign: “ My$reg $code”. If these appear within a
procedure with parameters “reg” and “code” with values of “Protocol” and “0xa3”
respectively, then value substitution is performed verbatim and yields: “ MyProtocol
0xa3”, and these newly formed words are processed as part of the command. In
Level-0 PDL, value substitutions are limited to parameter values or default values.
More complex substitutions48 are not allowed. Do note that if the value of a param-
eter contains spaces, then the verbatim replacement will also contain those spaces,
but, the result is still considered one word. (Now, how could that be confusing?)

47
An end-of-file marker (EOF) is treated as a newline.
48
Examples are provided by the standard, such as $name(index) and ${non-PDL name}. Level-0
PDL is deliberately designed to be very simple since it is the principle method for conveying pro-
cedural information from vendors to users.
440 11 IEEE 1149.1: The 2013 Revision

When a word starts with a double-quote (“) character, it must terminate with a
double-quote. Other characters like semicolon, close brackets, white space or
newline are treated as ordinary characters, but substitutions are still performed. The
double-quotes are removed before the word is passed to the command processor.
If the word starts with a left brace ({) and ends with a right brace (}), then no sub-
stitutions are performed within the braces, except for backslash-newline replace-
ments. The braces are removed before the word is passed to the command processor.
Comments can be placed inside PDL, but they must start with the hash mark (#)
and this character must appear where parsing is expecting the start of a command. All
characters up to a trailing newline are part of the comment. Thus a comment can start
a new line, or may follow a semicolon, but cannot break a command into two parts.
PDL does not possess the concept of a “string”. Every “word” may be enclosed
in double-quotes (“”) or curly braces ({}). They are discarded. Thus the two follow-
ing commands are equivalent:
iWrite myreg 0xAC09
“iWrite” {myreg} “0xAC09”

PDL has no formal reserved words, except for those that start with “STD_1149_”.
PDL has <PDL identifiers> and these are case sensitive, unlike <VHDL identifier>
elements, but are more liberal with regard to underscore (_) characters, allowing
trailing or consecutive underscores.

11.5.3 PDL Procedures

PDL supports the definition and usage of callable test procedures. The form for
these is given here as:
iProc <proc_name> <proc_options> { <arguments> }{ <PDL commands> }

Notice: This is not formal syntax, and it should not be confused with the syntax
expressions used to describe BSDL. A formalized49 syntax for PDL can be found in
IEEE 1149.1-2013, Annex C.
Here we have a mandatory procedure name <proc name> which is a PDL identi-
fier, followed by zero or more <proc options> which are PDL identifiers prepended
with a dash (–) character. Examples are “-info”, “-export”, “-TRSTreset” etc. Then
there is a first set of curly braces which enclose zero or more arguments. Next is a
second set of curly braces which enclose a set of PDL commands.
PDL procedures may call other procedures using iCall commands. Level-0 PDL
procedures do not return values nor do they manipulate variables seen outside of them.
The standard defines several PDL procedures that are intended to support ICs
that have various features. For example, an IC may implement the “INIT*” family

49
PDL is based on Tool Command Language (Tcl) which has no “formalized” definition itself.
Annex C provides useful definitions that are helpful for tool implementation.
11.5 The New “Procedural Description Language” (PDL) 441

of instructions that target the Init_Data and Init_Status registers. The IC vendor
would then supply procedures to read/write these registers, using register mnemon-
ics, register fields and/or register assemblies provided in the BSDL for that IC.
Further, IP providers might supply so-named procedures for their pieces of Init_
Data, also using their register definitions. The IC level routines would make appro-
priate iCalls to these routines.
These defined PDL iProc procedures (which are spelled in lowercase) are:
• “init_setup” is intended to set up various I/O parameters that can be controlled
from the Init_Data register. When there are choices for parameters, such as volt-
age drive levels, then the most common might be set as a default, and a user
might want to choose alternates as needed by his board testing problem. This
might be as simple as changing a mnemonic name used in the procedure body.
The goal is to prepare the IC for EXTEST-based test. Note that the procedure
may have the choice of using INIT_SETUP versus the INIT_SETUP_CLAMP
instruction. In the latter case, a Boundary register preload might be needed, and
the user would investigate what that entails.
• “init_run” will document the activities needed by the INIT_RUN instruction to
get the IC into testing condition, where clocking or other sequential stimuli are
needed to complete initialization.
• “ecid” will document reading out the ECID_code register using the ECID
instruction.
• “main” will document other tests that are provided by the IC (or IP) that would
probably be run after interconnect testing, if desired. For example, the IC might
contain two instances of a memory IP, for which the IP supplier has implemented
a BIST routine. The IC level main would call the BIST routine for each block.

11.5.4 PDL Level-0 Command Reference

There are numerous PDL Level-0 commands and they are organized in groups for
procedure definition, test setup, test execution, flow control, optimization, miscel-
laneous and low-level.

11.5.4.1 Procedure Definition

Procedure definition commands appear at the top of PDL code file. Remember PDL
routine names are case sensitive.
• iSource: This optional statement takes a single <PDL file name> parameter. This
is an “include” statement that copies PDL code from a file inline. All PDL proce-
dures must be defined before being called.
• iPDLLevel: has two parameters, a <level> which is 0 or 1, and a <1149.1_ver-
sion> which identifies the version of the standard this file adheres to. Currently,
only “STD_1149_1_2013” is a recognized version.
442 11 IEEE 1149.1: The 2013 Revision

• iProcGroup: takes a single parameter, the name of the entity, package or instance
name the following iProc procedures are associated with.
• iProc: one or more PDL procedures, each with a <procedure name>, zero or
more <options>, then zero or more <arguments> enclosed in curly braces, and
then a set of <commands> enclosed in curly braces.

11.5.4.2 Test Setup

Test setup commands appear within iProc procedures.

• iSetInstruction: takes a single parameter <instruction> which is the name of an
instruction to use when accessing a register with more than one accessing instruc-
tion. For example, the Boundary register is accessed by EXTEST, CLAMP,
PRELOAD, etc. This command directs which one to use for the next iApply that
needs to use the Boundary register. This command is not needed when there is no
ambiguity about a register/instruction pair.
• iClock: takes a <clock name> parameter, and optionally, a period option and a
<clock state> indicator. The <clock name> is a port name that must match a
name given in a BSDL SYSCLOCK_REQUIREMENTS attribute for the device.
If a period option is present, it is –period followed immediately by <seconds>
which a real number expressing the clock’s period time in seconds. The <clock
state> is either –on or –off, and indicates whether a clock should or should not
be running.
• iClockOverride: takes an <IntClockName> parameter followed by a source
phrase and a multiplier phrase. The <IntClockName> is PDL identifier that gives
an arbitrary name to an internal clock; the name is only known within the iProc
that defines it. The source phrase –source <clock name> identifies a port name
(same as for iClock) from which the internal clock is derived. The multiplier
phrase –freqMultiplier <rvalue> is a real number which is used to divide the
clock port’s period to obtain the internal clock’s period. Then there is an optional
<clock state>, which is the same as given for iClock.
• iPrefix: takes an <instance or null> parameter to specify partial path hierarchy for
registers. Registers in a hierarchy may have long path names, like U3.MyCorpBist.
BistEngine.config_reg. An iPrefix command is used to specify some or all of the
prepended instance names to reduce the clutter in PDL code. If the <instance or
null> parameter is a dash (–) then an existing defined prefix is erased.

11.5.4.3 Test Execution

Test execution commands appear within iProc procedures. Note that except for iAp-
ply, these commands do not cause tester hardware to manipulate UUT signals. They
set up the register image with data to either write and/or expect. It may take a num-
ber of iWrite, iRead and iScan calls to set up this data before the iApply command
takes charge and causes hardware activity.
11.5 The New “Procedural Description Language” (PDL) 443

• iWrite: takes two parameters, a <register_inst> and <write_value>. The first

parameter is a <field_instance> or <TDR_spec>. A <field_instance> is a <full_
field_name>, possibly prepended with period-separated set of prefixes. A <TDR_
spec> is TDR name possibly followed by an <array_index_list>, which itself is
one or more comma-separated integers or <dec_range> enclosed in parenthesis.
A <dec_range> is an “<integer> <colon> <integer> specification. Finally, a
<full_field_name> is <extended_field_name> possibly followed by its own
<array_index_list>. An <extended_field_name> is a field name possibly pre-
pended with a prefix string. The iWrite command is used to insert data within a
register image in memory for eventual shifting into the TDI of a chain. The data
inserted is the <write_value> which may be a numeric expression (binary, hexa-
decimal, decimal), or a mnemonic identifier for such data, or, one of three option
words: -reset, -default, or –safe. (See more about this below.) If the data pattern
is shorter than the number of bits in the register, it is right-justified (to TDO) and
the higher bits are padded with 0’s.
• iRead: takes the same parameters as iWrite—see above. The iRead command
is used to insert data into the register image in memory for eventual shifting
out and comparing with TDO data. If the expected data pattern is shorter than
the number of bits in the register, it is right-justified (to TDO) and the higher
bits are padded with X’s (i.e., don’t cares). Before the first iRead is encoun-
tered and after each iApply command, the expected data pattern is reset to: (1)
capture values mandated by 1149.1, or (2) values specified with the CAPTURES
expression in a register access or register field definition, or (3) a don’t care
value of ‘X’.
• iScan: takes a <reg_inst> parameter (see iWrite above), an integer <length>, and
a scan data in phrase and a scan data out phrase. The <length> must equal the
length of <reg_inst>. The scan data in phrase is keyword –si followed by a pat-
tern (binary or hexadecimal) and the scan data out phrase is keyword –so also
followed by binaryX or hexadecimalX pattern, which means “X’ characters for
“unknown” or “don’t care” are allowed. The iScan command thus specifies both
shift-in and shift-out data in a single command. It is intended for passing data in
and out of registers that are not well documented in BSDL, perhaps we only
know the name and length, but no more. Note that the scan data must not have a
significant bit set in a location that exceeds the register length. However, patterns
that are shorter are left-padded with zeros for scan-in data, and left-padded with
X’s for scan-out data.
• iApply: takes zero to three options, -nofail, -skipRTI and –shiftPause, and then
an optional label, which is a PDL identifier. The iApply command marks the end
of a set of iWrite, iRead and iScan statements, and causes tester action. Note that
all of the previous statements must have targeted a single data register. The iAp-
ply command clears the local fail flag before performing a data shift. While data
is being shifted, any compare data that mismatches the data shifted out will set
the local and accumulating fail flags unless a –nofail option was specified on
the command. If the TDR to be shifted by iApply is part of a register constraint
444 11 IEEE 1149.1: The 2013 Revision

(see Sect. 11.4.22) and if the constraint evaluates to True, with a severity level of
error,50 then the shifting is not performed and the test is halted.
In the iWrite command, we saw keywords -reset, -default, or –safe. These have
to do with specific cases in certain registers. If the register being written to is the
Boundary register and the keyword is -reset, then if a cell being written is of type
ControlR, then the <safe bit> for that cell is inserted (see Sect. 2.3.13). If a
Boundary register cell is specified and either –default or –safe is specified, then the
<safe bit> for that cell is inserted. If the register being written to has been specified
with a <value assignment> (see Sect. 11.4.20) of RESET, SAFE or DEFAULT, then
the specified value is inserted.
The iApply command keeps track of the current TAP state (see Sect. 1.3.1) and
maneuvers through the TAP state diagram like so: When there is a –shiftPause
option on the command for the first time, the TDR is shifted in/out and the TAP is
left in the Pause-DR state, where a subsequent iApply would resume shifting more
data using the Exit2-DR and Shift-DR TAP states. This can be useful when you are
trying to test a register that has a “length problem”, for example, some excludable
segment is missing. If –shiftPause is not specified, the TAP is left in the Run-Test/
Idle TAP state, unless the –skipRTI option is specified. Some instructions use the
Run-Test/Idle TAP state to perform actions that take some number of clocks and/or
time to occur, and we would want to control these actions explicitly. But when –
shiftPause is not present and –skipRTI is, the standard requires the iApply com-
mand to stop in the Pause-DR state anyway.
The iApply command is charged not only with shifting data into a TDR, but with
managing the instruction register and any selection or exclusion controls needed to
get data to a register. (This is laid out in detail in Annex E of 1149.1-2013.) This can
get complicated. For example, say an iWrite has specified a data field in a TDR that
resides inside an excludable segment. The tool reading the PDL would have to sense
this, and figure out where the exclusion control bits are; and let’s assume they are in
some other register. So, the iApply will have to go to that register and set (a virtual
iWrite) the control bits. But before it can shift that data, it has to load the instruction
register with an instruction that accesses that TDR, so an IR-shift operation first
happens, then the data shift can be done to get the excludable segment included
(back in that first register). Now, we have to do another IR-shift to get the first
instruction back again to access that first register. Now, we can finally do a data scan
to the formerly excluded segment. So what seemed like a single TDR scan turned
into an IR-scan, followed by a DR-scan, followed by another IR-scan and finally,
the DR-scan we originally wanted.
The iApply command can appear in a Level-1 PDL routine. When it does, it also
manages the two addition registers shown in Fig. 11.16, the raw output data from
the device, and a pass/fail indication register showing the bits that mis-compared.

50
If the severity level is warning or info, then the action taken is left to the tool’s discretion.
11.5 The New “Procedural Description Language” (PDL) 445

Another caveat about iApply needs to be stated. The standard says little about the
“end state” of iApply activities. Indeed, the term “ending state” is used in Annex E
without definition. Now in the –skipRTI and –shiftPause forms of iApply, the end
state is defined as Pause-DR. However, the standard is silent on what the end state
would be for a “naked” iApply statement (no option given). This can matter to the
author of PDL, especially if the execution engine (the tester) being driven by PDL
has its own definition of “ending state”. For example, one form of tester may be able
to stop TCK (in the low state) while decisions are made about where to go next in
the state diagram. Thus, it could stop in Update-DR, where it could restart after
choosing to go to Run-Test/Idle, or Select-DR-Scan. This means that iApply would
perform a full Capture-Shift-Update sequence. But on a tester that always has TCK
free running, it can only stop in a Pause-xR state or Run-Test/Idle. In the first case,
the final Update-xR state passage occurs on the next iApply (or trip to Test-Logic-
Reset). In the second case, the state machine passes Update-DR and is spinning in
Run-Test/Idle, which for some instructions means something is getting clocked by
TCK. So, it may be problematic to be casual about this end state issue. Knowing
what your hardware will do may make a difference in how you code your PDL. What
then do you as (say) an IP provider do when you don’t know the target machine? It
may behoove those in such situations to write very simple PDL, complete with
warnings to the user about end-state assumptions.

11.5.4.4 Flow Control

Flow control commands appear within iProc procedures.

• iCall: is used to call (i.e., transfer control to) a named procedure (iProc). There
is an optional –direct option, followed by a <proc_string> and an <argument
value> enclosed in curly braces. The <argument value> is a text string (possibly
blank) which contains words that will be processed by the called procedure. The
<proc_string> is a <proc_name> possibly prepended with an <instance path>,
made up of period-separated <instance identifiers>. The <proc_name> is a PDL
identifier and the <instance path> tells us where to find the name in a hierarchy
if one exists. A –direct option tells the call to use the current instance.
• iRunLoop: takes a single <delayspec> string as a parameter, which is either a
<time_spec> or a <cycle_count>. A <time_spec> is –time <seconds> followed
optionally with –tck_off. Seconds is a real number that specifies a waiting time.
The –tck_off keyword says the TCK should not be running for that wait interval.
A <cycle_count> delay specification is –sck <clock> followed optionally with
–tck_off. The <clock> is either a <src_clock> or <int_clock>. A <src_clock> is
the port name of a system clock pin. An <int_clock> is a PDL identifier <clock
name> declared in an earlier iClock command or an <int_clock> declared in an
earlier iClockOverride command. (See above in Test Setup commands.) The pur-
pose of iRunLoop is to stop a set of actions for a specific delay interval, timed by
some number of clocks, or a waiting time.
446 11 IEEE 1149.1: The 2013 Revision

• iLoop: This command is paired with the iUntil command (next). The two com-
mands enclose a block of commands that are to be executed at least once and
possibly more times until a termination condition occurs, as determined by the
iUntil command. The iLoop command has no parameters.
• iUntil: This command is paired with the iLoop command (above), and deter-
mines if the commands between iLoop and iUntil will be executed again, succes-
sively until a termination condition is met. When met, commands following the
iUntil are executed next. The iUntil command is followed by a <condition> and
an optional <timeout> specification. The <condition> is either the –match or –
mismatch keyword. The <timeout> specification is the keyword –maxloop fol-
lowed by a <maxcnt> and optional text string. The <maxcnt> is an integer
specifying the maximum times the loop will be executed before stopping with a
“Fail” indication. If a loop times out, the optional text string will be passed to the
user as an explanation. The commands between iLoop and iUntil must have
included at least one iRead or iScan, with an iApply called to possibly set the fail
flag. On a –match condition, the loop will execute again if the iApply set the
local fail flag. On a –mismatch condition, the loop will execute again if the local
fail flag is not set. Note the commands between iLoop and iUntil may not be
conditional (iLoop, iUntil, ifTrue, ifFalse or ifEnd) nor low-level commands
(iTMSreset, iTRST and iTMSidle). Timeout conditions protect against the pos-
sibility of an infinite loop.
• ifTrue: The ifTrue command heads a list of commands, followed by either an
ifEnd command, or an ifFalse command which head a list of commands followed
by an ifEnd command. (See ifFalse next.) The ifTrue command checks for the
state of the local fail flag being True, and executes the following commands
when it is True.
• ifFalse: The ifFalse command heads a list of commands, followed by either an
ifEnd command, or an ifTrue command which head a list of commands followed
by an ifEnd command. (See ifEnd next.) The ifFalse command checks for the
state of the local fail flag being False, and executes the following commands
when it is False.
• ifEnd: The set of three “if” commands are used to form classic “if statements”
and “if-then-else statements. Either ifTrue or ifFalse may be paired with subse-
quent ifEnd command. Or, both an ifTrue and ifFalse may precede an ifEnd
command. No other mix is allowed (no nesting), nor is a iLoop/iUntil structure.
When a set of commands is to be skipped, all of them until the following “if”
command are skipped. Clearly, a command (like iApply or an iProc containing
an iApply) that sets or clears the local fail flag must have been executed ahead of
an “if” structure for it to be useful. No “if” commands are allowed within an
iMerge block (see Optimization commands).
Here is an example of some flow control where we are looking for an event to
occur in response to a stimulus. If the event does not occur, we time out.
11.5 The New “Procedural Description Language” (PDL) 447

iProc TurnOnVref { } {
iLoop ; # Loop until non-zero voltage appears
iWrite ADDRESS VREF_ADDR
iWrite WE 0
iApply
iWrite WE 1
iApply
iRead VREF-VOLTAGE 0x00;# Loop until VREF is ON
;# (a non-zero value)
iApply –nofail; # don’t accumulate fails
iUntil -mismatch -maxloop 10 “VREF never turned on”
}

Here is an example of if-then-else control. Imagine an IC which contains a fuse

that is set during its manufacture, to indicate a difference in internal functions it
supports.

iProc initial { } {
iRead fuse(0) 0b0
iApply –nofail; # Don’t accumulate failure
ifTrue ; # Rev 0 has a limited feature set
iCall init_setup1; # Setup for Fuse = 0
ifFalse; # Rev 1 has larger feature set
iCall init_setup2; # Setup for Fuse = 1
ifEnd
}

11.5.4.5 Optimization

Optimization commands appear within iProc procedures. These allow a PDL pro-
grammer to “offer guidance” for tools that can optimize execution performance. As
such, they are useful in a given tool environment where a PDL programmer is con-
fidently familiar with how optimization is performed. Optimization cues placed in
PDL code in one tool environment might not be effective in another tool environ-
ment with different optimization capabilities. The tool environment may have on/
off controls for optimization to help in cases where test outputs seem to be affected
by optimization, which may prove difficult to debug.
• iMerge: The iMerge command has two options, -begin and -end, and are used
in begin-end pairs to surround a block of PDL code that can be executed in
parallel. For example, imagine an IC which contains two instances of an IP
block that have an internal BIST function. The designer knows these two func-
tions can be executed in parallel, so before the two iCall statements are written
to call those functions, an iMerge –begin is written, and after the second func-
tion call, an iMerge –end is written. The optimizer would then wind its way
448 11 IEEE 1149.1: The 2013 Revision

into the two called procedures and line up the various iWrite, iRead, iScan and
iApply statements it finds to execute them in parallel. Note that the iRunLoop
statements in the two routines can be executed in parallel, saving overall run
time. However, conditional statements are not allowed within an iMerge block.
• iTake: The iTake command claims a resource, which a later iRelease command
can release. The idea is that if procedures are being merged, a portion of code
inside an iTake/iRelease pair (with the same resource) within each procedure are
not to be merged, but executed separately. This allows some fine tuning of a
merge operation to be specified by a PDL programmer. See iRelease for more
discussion on resources.
• iRelease: This command releases a resource claimed by iTake, above. A resource
may have three forms: a –register resource, a –port resource, or it can be a –
name resource. The word following these keywords is a register name, port ID
or a PDL identifier, respectively. Register or port names may be a fully qualified
path passed to the procedure it is in or as established by iPrefix commands. Note
that iTake and iRelease commands of a given resource must both appear inside a
procedure. A name resource is a PDL identifier that is the same when used in a
set of PDL procedures for a UUT. (It does not appear in BSDL.)

11.5.4.6 Miscellaneous

Miscellaneous commands appear within iProc procedures.

• iSetFail: The iSetFail command is used to set the test failure flag “manually” as
a result of some condition that the test hardware itself is not monitoring for pass/
fail results. An optional –quit option can be specified, telling the test to stop,
rather than continuing—if there is concern about some damage occurring.
A trailing text string in double quotes or curly braces can be provided as a diag-
nostic message regarding the failure. As an example of how this could be used,
imagine an IC with some programmable I/O parameters. A PDL routine could
contain a check on a parameter to prevent its running if a certain parameter value
is passed to it. The iSetFail command might read iSetFail –quit “Voltage $swing
can cause device damage.”. Here, a quoted string is used so that parameter
substitution for $swing will show us the offending voltage.
• iNote: An iNote command gives an “active comment” capability. PDL already
has ordinary commenting, where a string delimited with hashmark (#) and new-
line is inserted in PDL code to document the purposes of various structures. An
iNote command, qualified by either –comment or –status options, is used to pass
a trailing text string on to the output for display. For example, if a PDL routine is
producing a set of test vectors, iNote commands can be used to lace the output
with comments about test purpose (comment) or test flow milestones (status).
Here are some examples of these command calls:
iSetFail -quit {Chip temperature too high, quitting.}

iNote -status "Completed writing init data to I/O\n"

11.5 The New “Procedural Description Language” (PDL) 449

11.5.4.7 Low-level

Low-level commands appear within iProc procedures. These allow some detailed,
low level operations to be controlled. For the most part, PDL shields the user from
most of the details of 1149.1 hardware execution, for example, what the current
TAP state is, or what trajectory through the TAP state diagram is taken. But occa-
sionally, a user might want to gain control of some choices. Note the two reset com-
mands will affect the stored data image of device registers, as those with RESETVAL
specification in their BSDL will determine what values they contain as a result of
being reset. Note that device instruction registers are also set to a reset instruction,
as specified in BSDL.
• iTRST: This command tells the tester hardware to assert the TRST* output,
which would be connected to a device (or chain of devices) that possess this pin.
The command has –on and –off options, the idea being you assert (-on) TRST*
and then let some time pass (use iRunLoop) before de-asserting TRST* (-off).
• iTMSreset: This command tells the tester hardware to execute a TAP synchro-
nizing sequence—TMS held high for five cycles of TCK, to force a device (or
chain of devices) into the Test-Logic-Reset TAP state.
• iTMSidle: This command tells the tester hardware to move the TAP state
machine to the Run-Test/Idle TAP state. Then if an iRunLoop command is exe-
cuted, the TAP will loop in the Run-Test/Idle state for the number of TCKs
specified.
Note that iTRST and iTMSreset commands would be used by top level PDL
code, and would not appear in low-level procedures, since executing either would
reset registers and change instructions as (rather drastic) side effects. PDL proce-
dures intended for re-use would typically never contain these resets.

11.5.5 PDL Level-1 Command Reference

PDL Level-1 has more data available to it, in that it manages raw (unprocessed)
TDO capture data and TDO fail data to be saved, accessed and acted upon. This data
is shown in Fig. 11.16. Thus, the iApply command is a superset of the iApply com-
mand in Level-0 PDL. All other Level-0 PDL commands behave the same in Level-
1. PDL Level-1 provides two new commands, iGet and iGetStatus. Unlike Level-0
commands, these commands return values that can be save and operated upon.
It is important to note that Level-0 PDL code may be interpreted, meaning it can
maintain data records shown in Fig. 11.15 and this data would be available to
Level-1 PDL. However, if PDL Level-0 code is compiled or otherwise translated
into code that runs on a specific tester architecture, then this data may not be avail-
able. Such testers have the advantage of being “fast”, as seen at the UUT pins,
whereas interpreted code may be considerably slower, with significant latencies
between bursts of pin activity.
450 11 IEEE 1149.1: The 2013 Revision

• iGetStatus: This command returns a four-character string, either “PASS” or

“FAIL”, representing the status of the accumulated Pass/Fail flag since it was last
cleared. A –clear command option, if provided, will clear the flag (set it to
“PASS”) after retrieving it. The accumulated Pass/Fail flag is set to PASS if all
iApply commands that have been executed since the last flag clearing have seen
no mis-compares. The accumulated Pass/Fail flag is automatically set to “PASS”
at the beginning of the top-level PDL program. The accumulated Pass/Fail flag
can also be set by the iSetFail command.
• iGet: This command takes up to two optional specifications, called data source
and format, followed by a register designator. The data source specification is a
keyword from the list –si, -so, -expect, and –fail, and –so is assumed if no data
source is specified. The format specification comes from the keyword list –hex,
-bin, -dec and –mnem, and –hex is assumed if no format is specified. The regis-
ter passed may be a field or full register. The result of iGet is a TCL string that
represents data extracted from the specified register. Here is what iGet returns as
specified by the keywords:
– –bin: the returned string starts with “0b” and contains one or more binary 0/1
or “X” bits.
– –hex: the returned string starts with “0x” and contains one or more hexadeci-
mal characters. If the register accessed is not a multiple of 4 in length, then the
leftmost hex character will have a value that does not exceed the position of
the most significant bit. (Its binary value is left-padded with zeros.) If the
register contains any “X” bits, then the hex character in that position will be
replaced with a “U” character, meaning “undefined”.
– –dec: the returned string is a positive decimal integer less than 232, unless
there were “X” bits in the register, for which a string with a single “U” is
returned, for “undefined”.
– –mnem: the returned string is a mnemonic identifier for the data in the regis-
ter at that location. The mnemonic’s value must have been provided in a mne-
monic definition for that register. Any “X” in the mnemonic value will match
any value in the corresponding location in the register. The most significant
“1” bit in the mnemonic value must fit within the length of the register, and the
mnemonic value, when its length is less than the register, is right-justified and
0-padded on the left before the comparison is done. If the register data does
not match a mnemonic value, the returned string is the single character “U”.
– –si: the data returned is derived from the “shift in” data of the specified regis-
ter, as set up by iWrite commands.
– –so: the data returned is derived from the “capture data” register, which is the
raw response data shifted out on TDO.
– –expect: the data returned is derived from the “expect data” of the specified
register, as set up by iRead commands. Note that the iApply command will
initialize some register content and erase some content that was set up before
the iApply.
11.5 The New “Procedural Description Language” (PDL) 451

– –fail: the data returned is derived from “fail data” register, with a “0” indicat-
ing no failure and a “1” indicating failure, of that bit location, after comparing
expected data with actual shifted out data. Some data is “0” because the
expect data at that location was “X”.
It is useful to look at some examples of PDL iGet and iGetStatus calls. First,
consider a 4-bit register Reg1 which always captures 0b0101. The following code
will fail, and we can see that and put out a message (with the “puts” TCL output
command).
iWrite Reg1 0b1111; #Data to scan in
iRead Reg1 0b0000; #Will fail, Reg1 captures 0b0101
iApply; #Scan in data, expect zeros out
set result [ iGetStatus –clear ]
#Fail flag is copied into local variable “result”
if { $result == “FAIL” } { puts “Test failed” }

In this example, the iGetStatus call was enclosed in square brackets [ ]. This is
TCL syntax that tells the interpreter to evaluate the enclosed command first before
analyzing the overall command. Here is an example of code to examine a device ID
register inside a device called U1.
iWrite U1.device_id 0x55555555; #alternating 01 bits
iRead U1.device_id ; #Initialized to value in BSDL
iApply; # This device captures ID = 14366603
set rslt_a [iGet U1.device_id]; # –so –hex default
set rslt_b [iGet –si U1.device_id]; # -hex default
puts “The Device ID is $rslt_a”
puts “$rslt_b was scanned into Device ID”

When executed this code produces two messages: “The Device ID is 0x14366603”
and “0x55555555 was scanned into Device ID”.
Now consider an example using mnemonics. Here assume two register fields
within a register exist called “swing” and “protocol” and that swing has mnemonics
“500mv”, and “1500mv”, while protocol has mnemonics “SATA” and “SRIO”.
This code could be used to check for a compatibility problem.
set val_a [iGet –si –mnem swing]
set val_b [iGet –si –mnem protocol]
if {$val_a == “500mv” && $val_b == “SRIO”} {
puts “Error, SRIO does not support 500mv swing”
}

This code could cause an exit before an iApply was executed, to prevent setting
up the incompatible pair of parameters. The use of mnemonics greatly improves
code readability here. The two iGet statements find the bit patterns in the register
fields, and look up the associated mnemonic names, which are then passed back.
452 11 IEEE 1149.1: The 2013 Revision

There is one fine point about iGet which is believed to be true,51 but it is not
explicitly stated in the 2013 revision. If you have a register field that has never been
written to, and it does not have an associated reset value either, then it could be
thought of as containing ‘X’ values, even for a write-only (e.g., binary) register.
Thus, say an iGet -mnem command is executed to a single-bit field with an “ON”
and “OFF” value of ‘1’ and ‘0’. What gets returned? If the field was never accessed
(and doesn’t have a reset value), it is believed to be ‘X’ and thus the iGet should
return an error, rather than “ON” or “OFF”. Those tools that don’t adhere to this
belief would not produce an error.

11.5.6 Integrated Example BSDL/PDL

Please refer to Sect. 12.5 for an integrated example of BSDL and PDL, for a pair of
ICs that contain IP blocks. This example is for 1149.6 devices, but the example
serves well as an example for both standards. It is a comprehensive example, so it
takes a bit of space to present.

11.6 Design for IEEE 1149.1 Testability

The new Electronic Chip IDCODE feature (see Sect. 11.3.4.1) allows an IC vendor
to embed useful design tradeoff information and various manufacturing details
unique to each IC produced. Some of this would surely be proprietary, so those
details could be encrypted. The idea here is to give an IC user a way to extract this
information and send it back to the IC vendor for analysis.
DFT-52: Consider implementing the ECID_CODE instruction and ECID
register, to capture design specifics and manufacturing details for later support
evaluation.
The new Init_Data register (see Sect. 11.3.4.2) and its associated instructions
allow easy and transparent access to initialization parameters needed for testing to
perform correctly. The days of “secret registers” with “special instructions” to
access them are now a thing of the past. We should no longer be passing around
“secret pattern” sets to set up drivers and receivers. Also, liberal use of register
fields and mnemonics should be included in BSDL to describe all these parameters
and label their values.

51
This assertion was made by C. J. Clark, the chairman of the 2013 revision. The concept appar-
ently was discussed but did not get written into the standard. It could be added in a future revision.
I share it here in case you run into tools that have implemented this behavior. It affects error-
checking of values returned from iGet.
11.6 Design for IEEE 1149.1 Testability 453

DFT-53: Consider implementing the Init_Data register for storing key

parameters that make drivers and receivers compatible.
DFT-54: Use register fields and mnemonics in BSDL to provide human-
friendly descriptions of registers and values they may be given.
The new concept of Test Mode Persistence (see Sect. 11.3.1) allows us to keep
an IC in test mode after a test sequence completes, rather than having it reflexively
return to an unknown system mode when the TAP returns to the Test-Logic-Reset
state. Many complex ICs today could very easily be damaged by the chaotic events
that might unfold. There are examples, indeed, of board damage occurring after a
test completes [Park11]. The irony is, the test may have passed, just before it smoked
the board.
DFT-55: Consider implementing the Test Mode Persistence controller in an
IC, particularly in those that manage power regulation on-chip, or for other
ICs on a board.
ICs are now more common that have on-chip power domains, and some of these
may include some I/O pins. This means some I/Os may at times be powered down.
Since the Boundary register is a crucial part of an 1149.1 implementation, it is
essential that register segmentation and exclusion be implemented precisely as
mandated by 1149.1-2013.
DFT-56: Survey the portions of an IC that may undergo power management
and assure that any 1149.1 resources within such domains are properly imple-
mented according to the standard.
At the board and system levels, designers should also be aware of those IC fea-
tures such a test mode persistence and excludable register segments so as to prop-
erly plan to use them, or avoid complications caused by their existence. If a board
or system designer could make use of (say) test mode persistence to protect a board
during testing, this should be highlighted in the hopes that such features are avail-
able in key ICs being considered in the design.
DFT-57: Survey your board/system designs to assure safety during test, and
at test completion.
Chapter 12
IEEE 1149.6: The 2015 Revision

IEEE Standard 1149.6 underwent a significant revision [IEEE15] which appeared in

2015. This was driven by two forces; the changes to the underlying 1149.1 standard
provided by the 2013 release of that standard, and a collection of experiences
compiled by users of the 1149.6 standard over 12 years.

12.1 The 2013 Revision of IEEE Std 1149.1,

the Principle Driver

The 1149.1 standard was given a major upgrade in the 2013 release, which is cov-
ered at length in Chap. 11. Several of these upgrades are capability additions such
as new abilities to describe registers in great detail in terms of fields within them,
and data content described with human-friendly mnemonic names.
The 2013 revision adopted the idea of “data initialization” which was actually
proposed in the 2003 edition of 1149.6 [IEEE03] (see Annex E). The overall data
initialization problem really does belong in 1149.1, since it is common to both
standards, and others to come. See Sect. 11.3.3.2.
The 2013 revision of 1149.1 greatly expands the ability of Intellectual Property
(IP) to be used and described, when that IP implements test circuitry needed for
1149.x implementations. It is now possible that a BSDL file that describes an IC’s
1149.x implementation will refer to (that is: “use”) information packages supplied
by IP vendors. Thus a BSDL file may actually be a compressed (“zipped”) file
containing a number of coordinated files.1

1
In principle, one could “flatten” a BSDL file that uses package information to restore the model
of one file describes one IC. However, that invites the introduction of errors at the IC vendor’s
site—and what happens if the IP vendor sends out an updated package? The IC vendor would have
to find the updated information and where it became incorporated into a BSDLto make concomi-
tant changes.

© Springer International Publishing Switzerland 2016 455

K.P. Parker, The Boundary-Scan Handbook, DOI 10.1007/978-3-319-01174-5_12
456 12 IEEE 1149.6: The 2015 Revision

One rather startling change introduced in the 2013 revision of 1149.1 was the
concept of register segmentation.2 Register segmentation (see Sect. 11.3.5.1), is
where a register may contain segments that can be included or excluded, and this
could change from time to time, hopefully under the control of users. Register seg-
mentation can be found in the two key registers that affect 1149.6, namely the
Boundary register and Init_data register (see Sect. 11.3.4.2).
The last “big deal” that is provided by the 2013 revision is the introduction of
Procedural Description Language (PDL). This new language (see Sect. 11.5) is
adopted by 1149.6 as a means of documenting how to access/manipulate certain test
features provided by 1149.6. This indeed is the intention of PDL, and 1149.6 is the
first standard to make use of this facility.

12.1.1 Intellectual Property Packages

More than ever, intellectual property (IP) is used by IC designers to implement spe-
cial functions. This is often true for I/O pins that have high performance criteria for
speed and/or protocols that are supported. Since 1149.6 specifically involves
“advanced I/O”, this means that 1149.6 functionality is likely to be supplied as part
of an externally supplied IP package.
The supplier of IP that contains some 1149.6 capabilities documents this in a
user package. This in turn is read as part of the IC’s BSDL when it is referenced by
a “use statement” which would be given near the top of the BSDL, after the “stan-
dard use statement” appears. In the 2003 version of 1149.6, only new Boundary
register cell definitions might be provided in a user package. Now, several descrip-
tive attributes may also appear. These are described in Sect. 1.3.1.

12.1.2 Register Descriptions

With the 2013 revision of 1149.1 and BSDL, we now have advanced capabilities to
describe registers, the register fields that they may contain, and register mnemonics
that give human-friendly names to data patterns. (See Sects. 11.4.19 to 11.4.23)
This is quite useful for the 2015 release of 1149.6 since it allows us to describe the
many register fields that make up the parametric control of 1149.6 features. These
fields are to be found in the Init_Data register (see Sect. 11.3.4.2). See examples
given in 12.3 below.

2
It also introduced register selection, but this feature is not adopted in 1149.6.
12.2 Fixes to 1149.6 Driven by Experience 457

12.1.3 Register Segmentation

Also with the 2013 revision of BSDL, we can describe registers that are segmented,
with the ability to exclude a segment. Register segmentation is the only “dynamic”
feature3 allowed for the Boundary register and Init_data registers, which are those
used by 1149.6. Register segmentation support causes some changes in the “behavior”
attribute where AIO pins are described. This is because a dynamically reconfigurable
register does not have permanently mapped cell numbers. See Sect. 12.3.4 below.

12.1.4 Initialization Capabilities

A long overdue improvement brought by the 2013 release of 1149.1 is the introduc-
tion of “Initialization”, with the Init_data and Init_status registers that contain initial-
ization data (see Sect. 11.3.4.2), and new instructions (Init_Setup, Init_ _Clamp and
Init_Run) that target these registers (see Sect. 11.3.3.2). The initialization capability
allows IC designers to bring out parametric controls into the user’s view where before
they were hidden away, with each IC vendor hiding them in some different place (see
Sect. 12.2 below). Now, they aren’t hidden, and we have a standardized way of see-
ing them and setting them up. The 1149.6 standard was the first to really force this
need, since more and more, its operation depends on properly setup parameters.

12.1.5 The Addition of PDL Routines

The 2013 revision of 1149.1 recognized that while BSDL is critical for describing
the structure and resources of an 1149 implementation, there was a new need to
describe procedures for using these resources. This is the Procedural Description
Language, or PDL. PDL is a way to describe how to load certain registers or fields
therein, with data patterns that set up parameters, and when to scan such data in/out
of a chain. The 1149.6 standard now utilizes PDL to describe how to initialize AC
parameters within a device, going so far as to enumerate a set of named routines that
perform such actions. It is expected that these routines will be provided with each
IC that a vendor provides to users. These are described in Sect. 1.4 below.

12.2 Fixes to 1149.6 Driven by Experience

As the 1149.6 standard became available in ICs, users began finding problems and
idiosyncrasies in the devices that implemented it. When they contacted the IC ven-
dors for help, they would sometimes be told that the IC needed some “setup” before
the ICs would perform correctly. Typically, this amounted to setting up some

3
The other dynamic feature is that of “selectable registers” which is not adopted by 1149.6.
458 12 IEEE 1149.6: The 2015 Revision

parameters in drivers and/or test receivers such that they would cooperate in sending
data across the board from one to another. This in turn led to sets of undocumented
pattern sets being passed around—you would hear about a pattern set in your Puerto
Rico factory that would make a test work, and have that sent to your Chinese con-
tractor to see if it would work there. Nobody really knew what the patterns did, but
they had to be applied between powering up a board and beginning an 1149.6 test.
Also, some devices might have radical mismatches in (say) driver parameters ver-
sus what the receivers need. This is one reason for (board level) capacitive coupling—
to remove some DC offset that prevents data reception. But if you use EXTEST to test
for testing for shorted board capacitors (see Sect. 8.4) it might turn out that when the
short occurs, the mismatch between driver and receiver frustrates the test.
Some devices have on-chip series coupling capacitors. But now, such capacitors
might be provided by a bypass link that can be switched on/off, again by some bits
that are passed in before testing. Thus the capacitor may be in-line for normal opera-
tion, but can be “shorted” if desired to provide a DC path to a pin. If this capability
is available, then a test for a board-level capacitor4 may be enabled.

12.2.1 Voltage Variations, Scaling and Programmability

Since the 2003 introduction of 1149.6, we have found that many parameters of I/O
pins are basically variable, with some being programmable and others scaled—by
being a function of (say) a power pin which can be connected to one of several volt-
ages. For example, in one device, a driver’s output voltage swing might be (say)
80% of the VDD value that driver is connected to. On programmable devices like
FPGAs, a given driver may have a programmable voltage swing that can be selected
at will from several possibilities. While it is likely in a given application such a
driver would be “frozen” at some configuration, this programming may not be
applied before we want to use the driver in a test. Thus, we have to set up the driver,
and likely, its downstream receivers to be compatible for data transport.
The 1149.6 standard embraces the concept of making such initialization trans-
parent and easy to perform. The Init_data register is central to this. New BSDL
features are essential to making this visibility practical and usable.

12.2.2 Improved Detection of Shorted Capacitors

Board level capacitors in I/O pathways are one of the principle reasons that 1149.6
exists. They block DC signals. They are critical to a path’s transmission success.
Thus we want to test that they are there, with no open pins, and, no shorts across

4
It might seem strange to have a board-level capacitor present when the IC has an on-chip capaci-
tor as well, but it happens. One explanation might be how much voltage difference an on-chip
capacitor can tolerate. A board-level capacitor can tolerate a large difference.
12.2 Fixes to 1149.6 Driven by Experience 459

them. The 2003 1149.6 standard envisioned using EXTEST to test for these shorts.
The idea was that EXTEST’s DC transmission of data would be blocked by a (non-
shorted) capacitor. Thus, we could set up the hysteretic memory of a test receiver
with a ‘0’ value, and have EXTEST transmit a ‘1’ across the net. If the ‘0’ was still
there after this transmission, then the capacitor must have been blocking the DC, that
is, it was not shorted. A robust test would run twice, with opposite data values, so that
some other defect, (like a shorted receiver pin) would not confuse the result – that is,
a shorted capacitor would transmit both polarities and be reliably diagnosable.
Alas, that view was tripped up by reality, as was found out by experience. If a
driver on one side of the capacitor had radical voltage levels, then perhaps only one
polarity of the test would “fail” (meaning the bit was transmitted) while the other
would not. For example, if a 3.5 volt driver was capacitively coupled to a 1.2 volt
receiver, then there is a chance that either of the drivers voltage levels might look
like a ‘1’ to the receiver, when a short inserted DC coupling.
The 2015 revision addresses two ways. First, it allows the IC designer who
designs a test receiver to anticipate the issue and choose a receiver threshold (for DC
testing) that is near a power volgage (Vdd or Gnd). He then documents this with a
keyword in the BSDL description of the test receiver, which basically tells test gen-
eration software that only one polarity of the test will work. This will save some
time in debug, since you will not be trying to figure out why your test isn’t passing
both polarities, you already know.

12.2.3 On-chip Coupling and Bypassing Thereof

The concept of on-chip capacitive coupling has been around since 2003, but the
2015 standard allows for the case where this capacitor can be bypassed (deliberately
shorted) so as to re-instate DC coupling. Indeed, there are cases where, when
EXTEST is loaded, this bypass is automatically enabled, and when an AC EXTEST
instruction is loaded, the capacitor is in place and blocking DC. Several new key-
words have been added to the 1149.6 BSDL extension to describe these cases. See
Sect. 1.3.3 below.

12.2.4 Allowing EXTEST_PULSE to Not Work

on Certain Pins

The 2003 version of 1149.6 requires EXTEST_PULSE and EXTEST_TRAIN to be

implemented, but it considers the pulse version to be the main workhorse, and the
train version is added as a backstop in case some pins with dynamic behavior cannot
be “booted up” enough by two edges to work properly. In reality, sometimes it is not
really possible (practically) to reliably implement the pulse capability and the train
capability should be preferred on some pin(s). The 2015 version allows this to be
documented with a BSDL keyword attached to the affected AIO pins.
460 12 IEEE 1149.6: The 2015 Revision

12.2.5 SAMPLE Incompatibility

The new version of 1149.6 recognizes that the SAMPLE instruction’s ability to
actually capture high-speed data on a pin5 is basically a fiction. Therefore, this is
recognized by allowing a Boundary register cell, during SAMPLE, to capture a
static ‘0’ or ‘1’. Two new Boundary register cells (AC_40 and AC_41) are intro-
duced in the STD_1149_6_2015 package to implement this. Now, a designer is
encouraged to put in a redundant observe cell on a differential receiver’s output,
where SAMPLE might be attempted, particularly if there is a “slow” or “single-
cycle” operational mode.

12.2.6 New AC Boundary Register Cells

As just mentioned above, SAMPLE may not work on some signals. Therefore, two
new cells are introduced that look like the BC_4 design (see Sect. 2.6.3) and are
coded in STD_1149_6_2015 as this:

constant AC_40 : Cell_Info :=

-- Observe-only cell that captures 0 during SAMPLE
((OBSERVE_ONLY, EXTEST, PI), -- All EXTEST inst
(OBSERVE_ONLY, SAMPLE, ZERO));

constant AC_41 : Cell_Info :=

-- Observe-only cell that captures 1 during SAMPLE
((OBSERVE_ONLY, EXTEST, PI), -- All EXTEST inst
(OBSERVE_ONLY, SAMPLE, ONE));

These do not support INTEST.

12.3 Changes to BSDL for 1149.6

There are some important changes to the BSDL extension that describe 1149.6 fea-
tures as of the 2015 release. See the syntax description in A.5. Most of these changes
are contained in the AIO_Pin_Behavior attribute. A new attribute called AIO_Port_
Behavior is introduced to allow the specification of “port links” which are place-
holder names for features provided by IP packages, which will later be referenced
at the entity level when describing port behavior. This reflects how, at the IP level,
it is not yet known what the entity ports are going to be.

5
Imagine a device with a 10 MHz TCK monitoring an I/O pin transmitting 10 Gbps data. The TCK
skews alone would amount to dozens of data bits passing by before SAMPLE captured something.
12.3 Changes to BSDL for 1149.6 461

12.3.1 Support for IP Packages

The 2015 release of 1149.6 recognizes the increased prevalence and importance of
Intellectual Property contributions to IC design. It is anticipated that there may be
several, maybe even many, IP packages needed to convey information relevant to an
1149.6 implementation at the IC level, that come from IP. Therefore, a user package
for 1149.6 may contain much more information that such a package would have
contained at the 2003 version of the standard. In the earlier version, it was possible
to convey the existence of a new Boundary register cell design, such as “My_AC_
Cell”, if a unique 1149.6-supporting cell was included in an IC design. However,
this was the extent of what was conveyed.
With the 2015 revision, a user package can still include and describe new AC
cells, but it can also include between one and four extension attributes, as described
in A.5. They describe component conformance, EXTEST_PULSE and EXTEST_
TRAIN descriptions (optionally), and port links (optionally). The port link concept
is described below in Sect. 12.3.6.

12.3.2 Support for Describing AC Parameters

The extension for 1149.6 BSDL now contains an enlarged list of AC parameters for
drivers and test receivers. A few “limits” are also now described, such as whether a
pin can support EXTEST_PULSE, or what a driver’s limits are for EXTEST perfor-
mance. The list of described AC parameters come in groups: time constants, and
voltage parameters. A few others pertain to in-line on-chip capacitors. The syntax for
AC parameter specification is given in A.5.3. There you see numerous keywords:
• LP_time and Edge_detect_time: used to describe an LP time constant of a test
receiver. Example: “ LP_Time = 5.0e-9”.
• HP_time and Coupling_time: used to describe an HP time constant of a test
receiver. There may be a trailing<cap spec>and/or a trailing<detection modi-
fier>. Examples: “HP_Time = 1.5e-8”, “HP_Time = 2.2e-8 On_Chip”, and
“HP_Time = 1.7e-8 Detect_EXTEST_High”.
• On_Chip, On_Chip_AC: These are<cap spec>words, the first describes an on-
chip in-line capacitor which is always present. The second describes an on-chip
capacitor that is switched out when EXTEST is the effective instruction.
• On_Chip_Programmable, On_Chip_AC_Programmable: these are<cap
spec>words, the first says there is a programmable shunt to switch out the on-
chip capacitor. The second says the on-chip capacitor is shunted out by EXTEST,
or by programming.
• On_Chip_Bus_Programmable, On_Chip_AC_Bus_Programmable: these
are also<cap spec>words that are followed by a group name enclosed in paren-
thesis. Both say there is a group-programmable shunt for the capacitor (shared
with others) and the second says that EXTEST also shunts the capacitor.
462 12 IEEE 1149.6: The 2015 Revision

• There are four <detection modifier> keywords, Detect_EXTEST_High,

Detect_EXTEST_Low, Detect_EXTEST_Both and Detect_EXTEST_Both_
Grouped. These tell us about a level detection limitation imposed by test receiver
design when EXTEST is in effect. The first says that the test receiver can detect
a driven high level, but not a low. Vice versa for the second keyword, the third
says both levels are detectable, and the fourth says both levels are detectable, but
for the special case of a grouped differential input pair, where both test receivers
connected to the pair will detect both levels. These keywords are only used when
option 2) of rule 6.2.2.1a) in 1149.6 is chosen during test receiver design.
• The voltage parameters come in two groups of two each. For drivers, there is the
common mode voltage keyword AIO_VCM and driver voltage swing keyword
AIO_VPP. For test receivers, there is the threshold voltage keyword AIO_VTH
and the hysteresis voltage keyword AIO_VHyst. A driven pin will have the two
driver keywords and a receiving pin will have the two receiver keywords. A bidi-
rectional pin will have all four. Each keyword will have, at the least, a voltage
specified as an integer number of millivolts. They can be followed by additional
keywords like Programmable and Bus_Programmable, with the same meaning
seen above. The AIO_VTH key can be additionally followed by AIO_VCM, mean-
ing the receiver threshold voltage is the same as the AIO_VCM of its driver (for
bidirectionals). The AIO_VTH key can also be followed by the keyword external,
meaning the threshold is provided by an external source (which means a PDL pro-
cedure is expected to set it up). Examples: “AIO_VTH = 500 AIO_Vhyst = 90”,
“AIO_VCM = programmable AIO_VPP = 350” and “AIO_VCM = program-
mable AIO_VPP = 250 AIO_VTH = AIO_VCM AIO_Vhyst = 90”.
• No_pulse: indicates the pin may not (reliably) work when the EXTEST_PULSE
instruction is in effect, and this pin may not support reliable tests in such case.
This keyword is always given last.
See Sect. 12.3.7 for some integrated examples of how 1149.6 features are
described in BSDL.

12.3.3 Support for Programmable Features

The new 1149.6 revision makes it possible for programmable features to be sup-
ported and their existence to be described. It is not mandated that circuit designers
make these features “TAP accessible” but the standard heartily encourages design-
ers to do so. Users will undoubtedly want access to them to “tune” their tests for best
performance. In the past, if such features were programmable, a user had to discover
this, and then entreat the IC vendor to tell him “the secret” to getting access to it.
This can become an ugly support problem for the IC vendor.
Programmable features include:
• Driver high/low voltage levels, where more than one can be selected,
• Driver common-mode voltage levels,
• Receiver reference thresholds, where more than one can be selected,
12.3 Changes to BSDL for 1149.6 463

• Hysteresis voltages for receivers,

• In-line on-chip capacitors that can be switched in/out of a signal path.
The standard also recognized “bus programmability”, where several drivers or
receivers are members of a group that can be programmed as a group with one set-
ting of a control register field. Of course, other drivers or receivers may be individu-
ally programmed, if so implemented. The actual setting of programmable features
is provided by PDL routines supplied by the IC vendor.
Bus programmability may be stated for a group of ports (that is, described as a
“bit_vector”) just by referencing the bit vector’s name. In other cases, multiple ports
that are not part of a bit_vector (i.e., just “bit”), or members of multiple bit_vectors
can be tagged with a group name (in parentheses) that act as a label on the shared
control field that determines the programmed value.

12.3.4 Support for Boundary Register Segmentation

With the 2013 version of 1149.1, we have the concept of a segmented Boundary
register and indeed, some segments could even be excludable. This has affected the
1149.6 standard where pin behavior is concerned, and nowhere else.
AIO pin behavior is described by the AIO_Pin_Behavior attribute (see next sec-
tion, Sect. 12.3.5) and it makes reference to Boundary register cell numbers. When
a BSDL describes a segmented Boundary register, there may be several instances of
a cell number scattered across several cell tables listed for the segments. Thus, cell
numbers may be prefaced with a segment name to indicate their segment of resi-
dence. See an example of this in Sect. 12.3.7.

12.3.5 Pin Behavior Description (Entity)

AIO Pin behavior at the entity level is described by an AIO_Pin_Behavior attribute

(see syntax in A.5.1). Pin behavior description changed due to two major factors; 1)
a Boundary register is now allowed to have excludable segments, and I/O pins may
be affected by the exclusion; and 2) a larger set of AC parameters is now expressible
for pins (see Sect. 12.3.2).
This attribute provides information about AC pins, as they are understood by the
1149.6 standard. Provided are:
• AC/DC select cells (if any) for these pins, and
• Time constants for edge detection or high-pass filtering (when implemented),
and
• The presence of an in-line capacitor on-chip (if any) and whether it may be
bypassed, and
• Common-mode and minimum voltage swings for drivers, and threshold and hys-
teresis voltage for receivers, and
• Receiver EXTEST detection behavior limitations (see Sect. 12.2.2).
464 12 IEEE 1149.6: The 2015 Revision

Note that a pin behavior description may reference “port links”, which are
described by a port link behavior description (see Sect. 12.3.6 and A.5.2) in a pack-
age referenced in a BSDL use statement. Examples of pin behavior description are
given in Sect. 12.3.7.

12.3.6 Port Link Description (Package)

The 2013 release of 1149.6 allows for pin circuitry to be supplied as IP from an IP
vendor. This would be documented in a supporting user package. By definition, the
IP supplier cannot know the pin names that an IC vendor will attach the IP to.
Therefore a “port link” mechanism is provided for packages to document port
behavior that will be associated later with pins at the IC level.
The AIO_Port_Behavior attribute is used to document the parametric behavior
of “ports” in an IP block. The syntax for this is shown in A.5.2. Basically, this attri-
bute starts with a port link declaration that gives temporary names to ports and
identifies their I/O nature. Following this is a list of ports and what their AC param-
eters are. Sometimes, not all the parameters may be known at the IP level, so these
are indicated by the external keyword, meaning, they well be provided by the IC
that the IP gets embedded in. At that point, the IC vendor will describe that param-
eter as that of a pin on his device. There is an example of this below in Sect. 12.3.7.

12.3.7 Examples of 1149.6 Package and Entity BSDL

Here are some examples of portions of BSDL that describe 1149.6 AC pins, both
those at an entity level, and those that come from IP user packages.
First, consider an entity with four bidirectional AC pins, described with the name
Bidir which is a bit_vector(1 to 4) of inout ports:

attribute AIO_Pin_Behavior of ACDEV1:entity is

"Bidir[13,15,17,9]:AC_Select=22 "&
"LP_Time=5.0e-9 HP_Time=15.0e-9 "&
"AIO_VCM=programmable AIO_VPP=250 "&
"AIO_VTH=AIO_VCM AIO_Vhyst=90 ";

Here the four drivers have a programmable common-mode voltage, so the IC

vendor should supply a PDL routine to set the common-mode voltage. The receiver
threshold voltage tracks the driver common mode voltage. The driver’s swing is a
fixed 250 mv and the receiver has a hysteresis voltage of 90 mv. The four pins can
have AC performance turned off (DC only) under control of cell 22. Cells 13, 15, 17
and 9 are monitoring test receivers using the stated time constants. This attribute is
different from the 2003 version in that it provides the voltage parameters of the driv-
ers/receivers. This can help a test engineer figure out problems that may occur in
data transmission between these pins and others on his board (which may also have
12.3 Changes to BSDL for 1149.6 465

these parameters listed). They may be incompatible, or may need programming to

get the right matchups.
Next, consider an IP block that provides some 1149.6 capability. Here the IP is
providing “I/O Lanes”, consisting of a single transmitter called Lane(0) and a single
receiver (with test receiver) called Lane(1). This IP could be instantiated in many
places in the IC, but the IP supplier needs to supply a port behavior description for
the two lanes, in the form of a user package. The IP supplier has no idea what IC
pins this IP might ultimately be connected to. He just describes it with “port links”
that are later mapped into the entity BSDL. It could look like this:

attribute AIO_Port_Behavior of ACPKG:package is

"port_link_list(Lane:out bit_vector(0 to 0); "&
"Lane:in bit_vector(1 to 1)); "&
"Lane(0):AIO_VCM=programmable AIO_VPP=320; "&
"Lane(1):HP_Time=18.0e-9 on_chip_programmable " &
"Detect_EXTEST_High AIO_VTH=external "&
"AIO_Vhyst=80 ";

Here we see a port link list with two link members, both named “Lane”, with one
being “out bit_vector(0 to (0)” and the other being “in bit_vector (1 to 1)”. These
port links are later referenced in the package and subsequent entity BSDL. Lane(0) is
the transmit lane with a programmable common-mode voltage and a swing of 320
mv. The receive lane has a bypassable on-chip capacitor, only detects DC levels in the
high state, has an externally supplied threshold voltage and a hysteresis voltage of 80
mv. The IP supplier will need to provide a PDL routine for accessing the on-chip
capacitor bypass and another routine for setting the driver common-mode voltage.
Now, consider an IC that uses the IP from the previous example and refers to the
ACPKG package that contains the port description we just saw. This IC has a set of
four outputs called TX_Nibble out bit_vector (3 downto 0) and a set of four inputs
called RX_Nibble in bit_vector (3 downto 0). The two nibbles will reference the
links set up in ACPKG, like this:

attribute AIO_Pin_Behavior of ACDev2 : entity is

"TX_Nibble:package ACPKG:Lane(0); "&
"RX_Nibble:package ACPKG:Lane(1) "&
"AIO_VTH=bus_programmable ";

Notice here that both TX_Nibble and RX_Nibble are not qualified with sub-
scripts or ranges, so the entire bit_vector in each case is assigned values obtained by
following the path “package ACPKG” down to a link name—Lane(1) and Lane(0)
respectively. So we have now described the AC parameters of four outputs and four
inputs, very compactly. Notice that RX_Nibble has a “bus_programmable” thresh-
old voltage, and the ACPKG:Lane(1) specification showed the threshold was com-
ing from an external source. The IC vendor will supply a PDL routine to set up this
voltage, since only they know how that got wired up, and under what control. The
IC might have other AC pins to document from the entity level. These would appear
466 12 IEEE 1149.6: The 2015 Revision

in the same attribute as additional lines of definition, separated by semicolons. It

could have other AC pins that are connected to other IP packages, so those would
show up too, with the appropriate package paths.
Now what happens when a device has a segmented Boundary register? For
example, say a Boundary register is made up of two segments, Top (near TDI) and
Bottom (near TDO), and the Bottom segment is excludable. This means that earlier
in the entity BSDL there was a Boundary_Segment description (see Sect. 11.4.15)
which listed the segments and cell tables for each segment. With no segmentation,
there is only one cell table, with one static set of cell numbers. When segments exist,
there are multiple tables and the same cell number could exist in many of them. So,
additional syntax allows us to describe each particular cell of interest. Here is the
first example, repeated with segment references:

attribute AIO_Pin_Behavior of ACDEV3:entity is

"Bidir[Bottom:13,15,17,9]:AC_Select=Bottom:22 "&
"LP_Time=5.0e-9 HP_Time=15.0e-9 "&
"AIO_VCM=programmable AIO_VPP=250 "&
"AIO_VTH=AIO_VCM AIO_Vhyst=90 ";

In the list of Bidir’s cell numbers, the first is prefaced with the segment name and
colon, and the rest are understood to be in that same segment. The AC_Select phrase
is also so qualified so we know where to find the select cell. A rule in 1149.6 requires
the AC_Select cell to be in the same segment as the cells it controls.

12.3.8 STD_1149_6_2015

The standard package for defining 1149.6 attributes (extensions) is provided here,
but not in its totality since it is very similar to the original package definition
(STD_1149_6_2003) shown in Sect. 8.6.2. Therefore, just the few changes, all
additive, are shown here.
At around lines 4-7 of the 2003 package we see four attribute extension defini-
tions, the last of which is:
Attribute AIO_Pin_Behavior: BSDL_Extension;
The 2015 package adds this new definition after the above:
Attribute AIO_Port_Behavior: BSDL_Extension;
Following the extension definitions, there are a number of “constant” definitions
which define AC Boundary register cells, such as AC_SelX, AC_SelU, AC_1,
AC_2, up to AC_10. The 2015 revision adds two new cell constant definitions after
these, and they are:

constant AC_40:Cell_Info; --BC_4 that captures '0' in SAMPLE

constant AC_41:Cell_Info; --BC_4 that captures '1' in SAMPLE
12.4 PDL Support for Programmable Pins 467

Next comes the package body description, where the actual cell information for
each constant is populated. In the 2003 package, the last cell defined is AC_10.
In the 2015 version, the two new AC_40 and AC_41 cells are populated directly
after the AC_10 cell. Those are already shown above in Sect. 1.2.6. These are the
only changes to the 1149.6 support package driven by the 2015 revision.

12.4 PDL Support for Programmable Pins

The 2015 revision of 1149.6 allows for the BSDL specification of I/O pin parame-
ters of common-mode voltage (VCM) and driver swing (VPP) on driven ports, and
comparison threshold voltage (VTH) and hysteresis voltage (VHyst) for test receiv-
ers. For some ports, these may be programmable from a menu of selections. When
programmable in-line on-chip capacitors are present, these are indicated in BSDL,
and some of these may have programmable shunts.
With the 2015 revision, an IC vendor is now required to document all program-
mable features with a set of pre-named6 PDL procedures. These are listed in
Table 12.1. Each programmable voltage parameter requires three procedures, “Set”,
“Get” and “Getall”—the programmable capacitors require two, just “Set” and “Get”.
The voltage “Set” procedures are used to set a voltage parameter on a port to a
valid value, with a possible scale factor. The scale factor is used to account for volt-
age values that may scale7 with the power supply voltage a device is connected to.
Basically, the routine is given a voltage value to set, and a scale factor (defaults to
“1.0”) that is used to divide the requested voltage before the routine uses it to look
up how to set the requested voltage. The port parameter in the call is used to look up
what the choices are for setting a voltage. Note, if a port is misspelled or otherwise
does not have a settable voltage, an error occurs. All errors encountered by any of
these routines will cause an error string to be returned, which is “AIO_ERROR”.
The routine is responsible for checking the parameters for errors, and can issue mes-
sages (using the output command “puts”) that explain what caused the error.

Table 12.1 Pre-defined PDL procedure names for pin parameters

Parameter Set iProcs Get iProcs Getall iProcs
VCM = programmable AIO_set_VCM AIO_get_VCM AIO_getALL_VCM
VPP = programmable AIO_set_VPP AIO_get_VPP AIO_getALL_VPP
VTH = programmable AIO_set_VTH AIO_get_VTH AIO_getALL_VTH
VHyst = programmable AIO_set_VHyst AIO_get_VHyst AIO_getALL_VHyst
On_chip_programmable AIO_set_DC_couple AIO_get_DC_couple N/A
On_chip_ac_programmable AIO_set_DC_couple AIO_get_DC_couple N/A

6
Remember PDL is case-sensitive, so the names have the indicated required spellings.
7
The scaling may be non-linear so a table lookup may be needed.
468 12 IEEE 1149.6: The 2015 Revision

The voltage “Set” procedures all look like this:

iProc AIO_set_*<AIO_proc_option>
<L_brace>voltage<L_brace>port ""<R_brace>
<L_brace>vscale "1.0"<R_brace><R_brace><executables>

Above, AIO_set_* is one of the four voltage “set” routines from Table 12.1.
The<AIO_proc_option>is zero or more of –export, -mission or –info<text>. Then
comes the first parameter named voltage (an integer in millivolts), followed by the
second parameter port, which is provided in-line with a default of the null string
"". Next is the third parameter vscale (a real number) which is provided with an
in-line default of "1.0". After that is a set of executable PDL/Tcl commands, with
the set enclosed in a pair of curly braces. These commands are the processing code
needed to set a given port or ports to the proper voltage. Basically, the routine code
checks the value of $port8 against a list of valid port names for a match, then checks
the requested (possibly scaled) $voltage to see if the port will support it. If all this
is correct, then the code issues iWrite calls to set the port voltage. Note the PDL
code may “group” port names into named groups, and if a group name is passed into
the routine, it can then process the command for all the group members. Thus, if a
port name is part of a bus programmable set of ports, then setting just one port will
have the effect of setting them all, since this is also what the hardware will do. When
all this work is completed, then the procedure passes back a string containing the
names of all ports (or group names) that had their voltage set. Any error encoun-
tered will result in the string “AIO_ERROR” being passed back.
The voltage “Get” routines all look like this:

iProc AIO_get_*<AIO_proc_option>
<L_brace><L_brace>port ""<R_brace>
<L_brace>vscale "1.0"<R_brace><R_brace><executables>

Above, AIO_get_* is one of the four voltage “Get” routines from Table 12.1.
The<AIO_proc_options>are the same as before. The first parameter is port with a
"" default value. The second parameter is vscale, same as for the “Set” procedures.
A “Get” procedure takes a port (or group) name and looks it up. It then issues an
iRead to find out what voltage that port (or group) was set to, using the scaling fac-
tor to account for how the voltage originally “Set” was scaled. The routine passes
back a string with the port’s voltage setting in integer millivolts. If an error is
encountered in all of this processing, it returns the string “AIO_ERROR”.
The voltage “Getall” procedures are nearly identical with the “Get” set. They
look like this:

iProc AIO_getALL_*<AIO_proc_option>
<L_brace><L_brace>port ""<R_brace>
<L_brace>vscale "1.0"<R_brace><R_brace><executables>

8
Inside a procedure, the “$” indicates a reference to a parameter’s value.
12.5 Integrated BSDL-PDL Example 469

Above, AIO_getALL_* is one of the four voltage “Getall” routines from

Table 12.1. This routine passes back a string listing all of the possible voltages the
passed port parameter could be set to, taking scaling into account. This routine need
not perform any iRead operations since it is looking up information provided in BSDL.
There are two routines used to “set” or “get” the states (“ON”/”OFF”) of and
capacitor bypasses that are programmable. The “set” routine look like this:

iProc AIO_set_DC_couple<AIO_proc_option>
<L_brace>state<L_brace>port ""<R_brace>
<R_brace><executables>

This routine is used to turn capacitor bypasses “ON” (meaning DC coupling) or

“OFF” (meaning AC coupling) as specified in the state parameter. Like the voltage
“set” routines, it takes a port parameter and looks up the port (or group) that is to
be set and performs the necessary iWrite to set this up. This routine passes back a
string containing the port (or ports or group) that was modified.
The “get” routine for capacitor bypassing looks like this:

iProc AIO_get_DC_couple<AIO_proc_option>
<L_brace><L_brace>port ""<R_brace>
<R_brace><executables>

This routine is used to return the “ON”/”OFF” state of a port (or group)
parameter.
All of these procedures are to be supplied by the component vendor for all param-
eters that are programmable. The calling sequences are all that can be mandated,
since each port’s attributes may be implemented in numerous ways. Therefore the
code within a given routine will likely be unique to a given device implementation.

12.5 Integrated BSDL-PDL Example

This section shows an example9 of a board containing two ICs, each of which con-
tain an IP block. IC1 contains IP-A and IC2 contains IP-B as seen in Fig. 12.1.
These two IC communicate across two board nets with on-board capacitors in the
paths. IC1 is driving the two differentially, and IC2 is receiving them. Both ICs are
implementing 1149.6-2015 on these pins.
The circuitry for IP block A is shown next in Fig. 12.2. Note the figure omits
details such as the TAP signals. The differential driver has a “swing” selection
which controls the output voltage swing to one of four levels, as selected by the two
bottom bits in the Init_Data register segment. The next bit up is a power control bit,

9
This example is adapted from 1149.6 to 2015, which has several other examples as well.
 Board

IC 1 IC 2
Board
Capacitors IP
IP
A B

AB-Board

Fig. 12.1 Board with two ICs containing IP blocks A and B

Clock In

SO

BC_1
C U
EN
Boundary
Register
AC_1
Segment Data
C U

SI

SO
BC_4
C
Swing
BC_4 Control
C
BC_1
Init Data
Register C U Power
Segment

BC_4 Mission +
0
VCM
C 1
CMV -

SEL
C U
BC_1
SI

IP-TX

Fig. 12.2 IP block A is a programmable differential driver

12.5 Integrated BSDL-PDL Example 471

which is used to completely remove power from the driver, as differentiated from
just disabling the driver. When power is enabled, the INIT_RUN instruction must
be used to provide clocking (TCK) for the driver to become ready.
The next bit up from there is a “CMV” bit used to select one of two possible
common-mode voltages (VCM) on the driven outputs. Finally, there is a select bit
that allows us to choose whether to use the “mission” VCM or the value in the CMV
bit on the driver. This would allow us to use mission mode driver behavior for some
functional testing if desired.
The IP block A also contains a two-bit segment of the Boundary register, a driver
data bit and driver enable bit. The data bit is an 1149.6 AC_1 cell to enable
EXTEST_PULSE and EXTEST_TRAIN performance. All these bits together allow
us to power, enable, set data bits, set data voltage levels and common-mode volt-
ages on the differential driver.
The circuitry for IP block B is shown in Fig. 12.3. Again, the figure omits details
such as TAP connections. This block contains three bits of the Init_Data register.
The bottom two bits are a VTH selection control which select one of four VTH
levels, and corresponding VBias levels on the mission receiver. The VTH voltage
determines the 0/1 voltage threshold used by the two test receivers that monitor the
input pins. The higher bit is a select bit to allow test VTH bits to control VTH gen-
eration, or, to let the device’s mission circuitry do it. Again, this could be useful
during functional testing that uses mission behavior. There is a three-bit segment of
the Boundary register in this block, with the bottom two bits receiving the test
receiver results and the upper bit monitoring the mission receiver result.
The two IP providers supply a BSDL user package and some PDL for their
IP. The use of register fields and mnemonics makes this very readable and friendly.
Here is the code provided by IP vendor A. Note the use of ellipses (…) in the code
to shorten it by skipping over some code that is not essential to this example.

BSDL User Package from IP Vendor A

package SerdesA is
use STD_1149_1_2013.all;
end SerdesA;
package body SerdesA is
use STD_1149_1_2013.all;
use STD_1149_6_2015.all;
… -- other statements skipped
attribute REGISTER_MNEMONICS of SerdesA:package is
"ONOFF(ON (1) <enable>, "&
"OFF(0) <off>), "&
"CMV( 0V (1) <Low power mode>, "&
"500mV(0) <Mission mode common-mode voltage>), "&
"SWING(900mV(0b11) <Driver Output Swing in mV>, "&
"800mV(0b10), "&
"700mV(0b01), "&
"600mV(0b00))" ;
472 12 IEEE 1149.6: The 2015 Revision

SO
BC_4
Test
Receiver C

BC_4 Boundary
Test
Receiver C Register
Segment

++ BC_1
C U
_-
SI

+
VTH
2
-
+
VBias
2
-

SO

C Mission 0
2
VTH 1 Init_Data
Control 2 Register
C
Segment

C U SEL

SI
IP-RX

Fig. 12.3 IP block B is a programmable differential receiver

attribute REGISTER_FIELDS of SerdesA : package is

"init_data[5]( "& -- 5 bits of init_data, give fields
"(SEL [1] IS (4) DEFAULT(ONOFF(OFF)) "& -- TDI
" RESETVAL(ONOFF(OFF))), "&
"(CMV [1] IS (3) DEFAULT(CMV(0V)) NOPI NOUPD), "&
12.5 Integrated BSDL-PDL Example 473

"(POWER[1]IS (2) DEFAULT(ONOFF(OFF)) "&

" RESETVAL(ONOFF(OFF))), "&
"(SWING[2] IS(1 DOWNTO 0) DEFAULT(SWING(800mV)) "&
" NOPI NOUPD) "& -- TDO
" )";
attribute AIO_Port_Behavior of SerdesA : package is
"port_link_list (TX_A out bit); "&
"TX_A : AIO_VCM=programmable AIO_VPP=programmable " ;
… -- other statements skipped
end SerdesA;

This package defined three sets of mnemonics (ONOFF, CMV and SWING) and
within each, provides mnemonic names and values for each. For example, in
SWING, we see the name “700mv” given a 2-bit value of “0b01”. Later, in the
register field description, we see a 2-bit field (also) called SWING which uses the
SWING mnemonics, with a DEFAULT set to “800mv”, which is “0b10”. This
means the 2-bit SWING register field will be defaulted to the 800mv selection until
an iWrite statement overrides that with some other value.
Finally, this package defines a port_link_list which names the (one) out bit port
called TX_A. This port link will be used later in other BSDL and PDL since the IP
vendor does not know what IC pin this circuitry will ultimately drive. The port
behavior of TX_A is listed as programmable for both AIO_VCM and AIO_VPP,
under control of the Init_Data register. Note that the POWER bit is documented but
its existence is not conveyed by the port behavior attribute. The routines below will
set and/or interrogate POWER.
Next, IP Vendor A provides PDL code for setting the VPP and VCM values of
the circuitry. You will see “PDL_CONTEXT_PATH” in the code. This is a string
provided by IEEE 1149.1-2013 that gets used in “puts” commands in the code to
produce error messages that identify the IC that has produced an error message.
This example code defines a total of six routines, for “get”, “set” and “getall” rou-
tines of the two driver voltages. Please note the code checks for calling errors in
passed parameters, and this accounts for much of the length of the code. This should
cut down on support calls to the IP vendor if their customers use the PDL routines
but make mistakes when calling them.
Some of these routines perform iWrite commands to fields within their portion
of the Init_Data register. These routines do not perform iApply operations. This is
because these are the lowest level routines, and at the IC or board levels, there may
be other calls to initialize data that we would want to apply in parallel to these. Note
too that because of the POWER function on the driver, the outer level routines will
be in charge of executing INIT_RUN to get the power on this pin (and others that
might also be instantiated as well) correctly set up.
474 12 IEEE 1149.6: The 2015 Revision

PDL routines from IP Vendor A as mandated by 1149.6-2015

#######################################################
# PDL procedures for SERDESA IP transmitter.
# NOTE: The programmable parameters of this transmitter
# vary as VDD_IO varies, non-linearly. The nominal
# value for VDD_IO for this component is 1500mv. Use
# the following values for the ‘vscale’ argument when
# calling these procedures:
# VDD_IO vscale
# 1800mv 1.28
# 1500mv 1.00
# 1200mv 0.92
#######################################################
iPDLLevel 1 –version STD_1149_1_2013
iProcGroup SerdesA
#######################################################
# VCM Routines:
# The VCM parameter is affected by the value of VDD_IO,
# so scaling is used. These routines check $port to be
# sure it was called with “TX_A” (not case sensitive).
# There are no iApply commands in these routines.
#######################################################
# AIO_set_VCM returns a port.
iProc AIO_set_VCM {voltage {port "" } {vscale "1.0"}} {
set ucport [string toupper $port]; #Uppercase port
if {$ucport != "TX_A" && $port != ""} {
puts "SERDESA port $PDL_CONTEXT_PATH.$port is\
not recognized.\n"
return "AIO_ERROR"
}
# Convert the actual voltage requested to the nominal
# voltage using vscale.
set adj_volt [expr {$voltage / $vscale}]
# Test for a range around each value to allow for
# arithmetic rounding, then set VTH register.
if {$adj_volt <= 5} {
iWrite CMV 0V
} elseif {$adj_volt <= 505 && $adj_volt >= 495} {
iWrite CMV 500mV
} else {
puts "The requested common-mode voltage $voltage\
mv is unsupported on $PDL_CONTEXT_PATH.$port.\n"
return "AIO_ERROR"
}
12.5 Integrated BSDL-PDL Example 475

iWrite SEL ON ; # Assure driver is in test mode.

# Driver power turned on by AIO_set_VPP
return "TX_A"
}; # End AIO_set_VCM procedure
######################################################
# AIO_get_VCM, returns a voltage.
iProc AIO_get_VCM {{port "" } {vscale "1.0"}} {
set ucport [string toupper $port] ;# Uppercase port
if {$ucport != "TX_A" && $port != ""} {
puts "SERDESA port $PDL_CONTEXT_PATH.$port is\
not recognized.\n"
return "AIO_ERROR"
}
# Only valid if POWER is set to ON.
set ponoff [iGet –si –mnem POWER]
if {$ponoff == "OFF"} {
puts "Warning, driver power is off for SERDESA\
port $PDL_CONTEXT_PATH.$port\n"
# Only valid if SEL is set to ON.
set selonoff [iGet –si –mnem SEL]
if {$selonoff == "OFF"} {
puts "Warning, driver in mission mode for SERDESA\
port $PDL_CONTEXT_PATH.$port\n"
# Note: the returned value of the VCM is only correct
# if SEL is set to 1, selecting the TDR field instead of
# the mission-mode logic.
set common [iGet -si -mnem CMV]
if {$common == "0V"} {
return "0"
} elseif {$common == "500mV"} {
return [expr {round(500*$vscale)}]
} ; # One of the above returns was taken.
}; # End AIO_get_VCM procedure
#######################################################
# AIO_getALL_VCM returns list of legal, scaled voltages
iProc AIO_getALL_VCM {{port ""} {vscale "1.0"}} {
set ucport [string toupper $port] ;#Uppercase port
if {$ucport != "TX_A" && $port != ""} {
puts "SERDESA Port $PDL_INSTANCE_PATH.$port is\
not recognized.\n"
return "AIO_ERROR"
}
return "0 [expr {round(500*$vscale)}]"
}; # End AIO_getALL_VCM procedure
#######################################################
476 12 IEEE 1149.6: The 2015 Revision

# VPP routines:
# The VPP parameter is affected by the value of VDD_IO,
# so scaling is used. There are no iApply commands.
#######################################################
# AIO_set_VPP returns a port
iProc AIO_set_VPP {voltage {port ""} {vscale "1.0"}} {
set ucport [string toupper $port] ; #Uppercase port
if {$ucport != "TX_A" && $port != ""} {
puts "SERDESA port $PDL_CONTEXT_PATH.$port is\
not recognized.\n"
return "AIO_ERROR"
}
# calculate the scaled voltage
set adj_volt [expr {$voltage / $vscale}]
if {$adj_volt >= 595 && $adj_volt <= 605} {
iWrite SWING 600mV
} elseif {$adj_volt >= 695 && $adj_volt <= 705} {
iWrite SWING 700mV
} elseif {$adj_volt >= 795 && $adj_volt <= 805} {
iWrite SWING 800mV
} elseif {$adj_volt >= 895 && $adj_volt <= 905} {
iWrite SWING 900mV
} else {
puts "The requested peak-to-peak voltage $voltage\
mv is unsupported for SERDESA port\
$PDL_CONTEXT_PATH.$port.\n"
return "AIO_ERROR"
}
iWrite SEL ON ; # Assure driver is in test mode.
iWrite POWER ON ; # Assure driver is powered.
# Note a higher level routine should do an iApply to set
# the power on, and then invoke INIT_RUN to finish the
# power turnon.
return "TX_A"
}; # End AIO_set_VPP procedure
#######################################################
# AIO_get_VPP returns a voltage.
iProc AIO_get_VPP {{port "" } {vscale "1.0"}} {
set ucport [string toupper $port] ; #Uppercase port
if {$ucport != "TX_A" && $port != ""} {
puts "SERDESA port $PDL_CONTEXT_PATH.$port is\
not recognized.\n"
return "AIO_ERROR"
}
12.5 Integrated BSDL-PDL Example 477

# Only valid if POWER is set to ON.

set ponoff [iGet –si –mnem POWER]
if {$ponoff == "OFF"} {
puts "Warning, driver power is off for SERDESA\
port $PDL_CONTEXT_PATH.$port\n"
# Only valid if SEL is set to ON.
set selonoff [iGet –si –mnem SEL]
if {$selonoff == "OFF"} {
puts "Warning, driver in mission mode for SERDESA\
port $PDL_CONTEXT_PATH.$port\n"
set deltaV [iGet -si -mnem SWING]
if {$deltaV == "600mV"} {
return [expr {round(600 * $vscale)}]
} elseif {$deltaV == "700mV" } {
return [expr {round(700 * $vscale)}]
} elseif {$deltaV == "800mV" } {
return [expr {round(800 * $vscale)}]
} elseif {$deltaV == "900mV" } {
return [expr {round(900 * $vscale)}]
} ; # One of the returns above is taken.
}; # End AIO_get_VPP procedure
#######################################################
# AIO_getALL_VPP returns a list of voltages.
iProc AIO_getALL_VPP {{port ""} {vscale "1.0"}} {
set ucport [string toupper $port] ; #Uppercase port
if {$ucport != "TX_A" && $port != ""} {
puts "SERDESA port $PDL_CONTEXT_PATH.$port is\
not recognized.\n"
return "AIO_ERROR"
}
return "[expr {round(600*$vscale)}]\
[expr {round(700*$vscale)}]\
[expr {round(800*$vscale)}]\
[expr {round(900*$vscale)}]"
}; # End AIO_getALL_VPP procedure
# END iProcGroup SerdesA
#######################################################

Some of the above routines check to see if the driver is in mission mode and
powered up. If not so, warnings are issued, but the routine completes its job without
error. The first call to AIO_set_VPP will set the driver in test mode and enable its
power.
Now let’s look at the BSDL and PDL from IP Supplier B (for the IP shown in
Fig. 12.3). This is a receiver design.
478 12 IEEE 1149.6: The 2015 Revision

BSDL User Package from IP Vendor B

package SerdesB is
use STD_1149_1_2013.all;
end SerdesB;
package body SerdesB is
use STD_1149_1_2013.all;
use STD_1149_6_2015.all;
… -- skipped lines
attribute REGISTER_MNEMONICS of SerdesB:package is
"Select (Enable (1) <enable>, " &
" Disable (0) <off>), " &
"CV ( 0V (0) <Low power mode>, " &
" 500mV (1), " &
" 750mV (2), " &
" 1V (3) )";
attribute REGISTER_FIELDS of SerdesB:package is
"init_data[3] ( "&
"(SEL[1] IS (2) DEFAULT(Select(Disable)) "& -- TDI
"RESETVAL(Select(Disable)) "&
"TAPReset), "&
"(VTH[2] IS (1 downto 0) DEFAULT(CV(0V)) NOPI NOUPD)"&
" )"; -- TDO
attribute AIO_Port_Behavior of SerdesB:package is
"port_link_list (RX_B in bit); "&
"RX_B : HP_time=1.0e-9 AIO_VTH=programmable "&
"AIO_VHyst=560 " ;
... -- skipped lines
end package SerdesB ;

Next, Vendor B supplies PDL three routines for setting/getting programmable

parameter VTH controlled by a field in the Init_Data register. Note there is a “SEL”
field to select either test or mission behavior of the threshold voltage. This field is
also managed here.

PDL routines from IP Vendor B as mandated by 1149.6-2015

#######################################################
# PDL procedures for SERDESB IP receiver. These routines
# do not perform iApply commands.
# NOTE: The programmable parameter VTH of this
# receiver varies linearly as VDD_IO varies.
# The nominal value for VDD_IO for this component is
# 1200mv. Use the following equation for the ‘vscale’
# argument when calling these procedures:
# vscale = VDD_IO / 1200
#######################################################
12.5 Integrated BSDL-PDL Example 479

iPDLLevel 1 –version STD_1149_1_2013

iProcGroup SerdesB
#######################################################
# AIO_set_VTH returns a port.
iProc AIO_set_VTH {voltage {port ""} {vscale "1.0"}} {
set ucport [string toupper $port] ; #Uppercase port
if {$port == ""} {
set ucport "RX_B" ; # if default "", add port name
}
if {$ucport != "RX_B"} {
puts "SerdesB port $PDL_CONTEXT_PATH.$port is\
not recognized for setting VTH.\n"
return "AIO_ERROR"
}
# calculate the scaled voltage
set adj_volt [expr {$voltage / $vscale}]
if {$adj_volt <= 10} {
iWrite VTH 0V
} elseif {$adj_volt >= 495 && $adj_volt <= 505} {
iWrite VTH 500mV
} elseif {$adj_volt >= 745 && $adj_volt <= 755} {
iWrite VTH 750mV
} elseif {$adj_volt >= 995 && $adj_volt <= 1005} {
iWrite VTH 1V
} else {
puts "The threshold voltage $voltage and scaling\
factor $vscale are unsupported for IP SERDESB port\
$PDL_CONTEXT_PATH.$port.\n"
return "AIO_ERROR"
}
iWrite SEL Enable ; # Assure not in mission mode.
return "RX_B"
}; # End AIO_set_VTH procedure
#######################################################
# AIO_get_VTH returns a voltage.
iProc AIO_get_VTH {{port ""} {vscale "1.0"}} {
set ucport [string toupper $port] ; #Uppercase port
if {$port == ""} {
set ucport "RX_B" ; # if default "", add port name
}
if {$ucport != "RX_B"} {
puts "SERDESB port $PDL_CONTEXT_PATH.$port is \
not recognized for getting VTH.\n"
return "AIO_ERROR"
}
480 12 IEEE 1149.6: The 2015 Revision

# Only valid if SEL is set to Enable.

set selenable [iGet –si –mnem SEL]
if {$selenable != "Enable"} {
puts "Warning, receiver in mission mode for SERDESA\
port $PDL_CONTEXT_PATH.$port\n"

set currVoltage [iGet -si -mnem VTH]

if {$currVoltage == "0V"} {
return "0"
} elseif {$currVoltage == "500mV"} {
return [expr {round(500 * $vscale)}]
} elseif {$currVoltage == "750mV"} {
return [expr {round(750 * $vscale)}]
} elseif {$currVoltage == "1V"} {
return [expr {round(1000 * $vscale)}]
} ; # One return above taken.
}; # End AIO_get_VTH procedure
#######################################################
# AIO_getALL_VTH returns a voltage list.
iProc AIO_getALL_VTH {{port ""} {vscale "1.0"}} {
set ucport [string toupper $port] ; #Uppercase port
if {$port == ""} {
set ucport "RX_B" ; # if default "", add port name
}
if {$ucport != "RX_B"} {
puts "SERDESB port $PDL_CONTEXT_PATH.$port is\
not recognized for getting VTH.\n"
return "AIO_ERROR"
} else {
return "0 [expr {round(500*$vscale)}]\
[expr {round(750*$vscale)}]\
[expr {round(1000*$vscale)}]"
}
}; # End AIO_getALL_VTH procedure
# END iProcGroup SerdesB
#######################################################

Next, component vendors of IC1 and IC2 take IPs A and B respectively and inte-
grate them into their chips as seen in Fig. 12.1. In this example each IP is included
only once, but, they could have been instantiated in many places, per the IC ven-
dor’s design requirement. Each IC vendor then provides supporting BSDL entity
descriptions and PDL for these programmable resources. Again, note the use of
ellipses (…) where code irrelevant to the example is omitted.
12.5 Integrated BSDL-PDL Example 481

BSDL Entity from IC Vendor 1, using IP block A

entity Part_1 is
generic (PHYSICAL_PIN_MAP:string) ;
port (
... -- Many IC pins omitted.
Diff_Drvr_P, Diff_Drvr_N:out bit; --Connected to IP-A
... -- More IC pins omitted.
);
use STD_1149_1_2013.all;
use STD_1149_6_2015.all;
use SerdesA.all; -- Get mnemonics and registers of IP-A
attribute COMPONENT_CONFORMANCE of Part_1:entity is
"STD_1149_1_2013";
attribute PIN_MAP of Part_1:entity is PHYSICAL_PIN_MAP;
attribute PORT_GROUPING of Part_1:entity is
...
"DIFFERENTIAL_VOLTAGE ((Diff_Drvr_P,Diff_Drvr_N))" ;
...
attribute REGISTER_ASSEMBLY of Part_1:entity is
"init_data("& --Some of Part_1 init_data from IP-A
... -- TDI
" (i13 is PACKAGE SerdesA:init_data), "&
... ), "& --TDO
"Boundary("& -- Some of Part_1 Boundary from IP-A
... TDI
" (b13 is PACKAGE SerdesA:boundary), "&
... -- TDO
")";
attribute AIO_COMPONENT_CONFORMANCE of Part_1:entity is
"STD_1149_6_2015";
attribute AIO_Pin_Behavior of Part_1:entity is
... --Some other Part_1 1149.6 pins omitted
--Now include the IP-A driver linked by "TX_A"
"Diff_Drvr_P : PACKAGE SerdesA:TX_A ";
end entity Part_1;

In this BSDL, we see four references to the SerdesA BSDL package content. The
first is a “use” statement that reads the SerdesA content. The second is a reference
to “SerdesA:init_data”, which assigns the portion of Init_Data delivered by the IP
block to “i13”, a segment in the assembled Init_Data register of the IC itself. The
third reference is to “SerdesA:boundary”, which brings the IP block’s portion of the
Boundary register into the assembly as “b13”. The last is a reference to
“SerdesA:TX_A”. This reference is to a port link (TX_A) defined in the IP BSDL
package. This assigns the AIO_Port_Behavior of the port link to the IC’s pin “Diff_
Drvr_P” AIO_Pin_Behavior.
482 12 IEEE 1149.6: The 2015 Revision

Next are the PDL procedures created by IC Vendor 1, which utilize iCall com-
mands to iProcs in the IP-A PDL code. They have error checks in them.

PDL routines from IC Vendor 1, using IP block A

#######################################################
iPDLLevel 1 –version STD_1149_1_2013
iProcGroup Part_1
#######################################################
# VCM Routines
#######################################################
# AIO_set_VCM returns a port.
iProc AIO_set_VCM -export {voltage {port ""}\
{vscale "1.0"}} {
set ucport [string toupper $port];# Uppercase port
if {$ucport == "DIFF_DRVR_P"} {
# Change port name to port-link name per
# AIO_Pin_Behavior attribute
set ret [iCall i13.AIO_set_VCM $voltage\
"TX_A" $vscale]
if {$ret == "TX_A" } {
return $port
} else {
return $ret
}
# ... Handle other AIO ports on the IC.
} elseif {$port == ""} {
puts "A port must be specified when setting the\
common-mode voltage on component $PDL_CONTEXT_PATH.\n"
return "AIO_ERROR"
} else {
puts "Setting the common-mode voltage is not\
supported on port $PDL_CONTEXT_PATH.$port.\n"
return "AIO_ERROR"
}
}; # End AIO_set_VCM procedure
#######################################################
# AIO_get_VCM returns a voltage.
iProc AIO_get_VCM –export {{port ""} {vscale "1.0"}} {
set ucport [string toupper $port];# Uppercase port
if {$ucport == "DIFF_DRVR_P"} {
set ret [iCall i13.AIO_get_VCM "TX_A" $vscale]
# ... Handle any other AIO ports.
} elseif {$port == ""} {
puts "A port must be specified when getting the\
12.5 Integrated BSDL-PDL Example 483

common-mode voltage on component $PDL_CONTEXT_PATH.\n"

set ret "AIO_ERROR"
} else {
puts "Getting the common-mode voltage\
is unsupported on pin $port.\n"
set ret "AIO_ERROR"
}
return $ret
}; # End AIO_get_VCM procedure
##########################################################
# AIO_getALL_VCM returns a voltage list.
iProc AIO_getALL_VCM -export { { port "" } { vscale
"1.0" } } {
set ucport [string toupper $port]
if {$ucport == "DIFF_DRVR_P"} {
set ret [iCall i13.AIO_getALL_VCM "TX_A" $vscale]
# ... Handle any other AIO ports.
} elseif {$port == ""} {
puts "A port must be specified when getting the common-
mode \
voltage list on component $PDL_CONTEXT_PATH.\n"
set ret "AIO_ERROR"
} else {
puts "Getting the common-mode voltage is unsupported on port \
$PDL_CONTEXT_PATH.$port.\n"
set ret "AIO_ERROR"
}
return $ret
}; # End of AIO_getALL_VCM
#######################################################
# VPP Routines
#######################################################
# AIO_set_VPP returns a port.
iProc AIO_set_VPP -export {voltage {port ""}\
{vscale "1.0"}} {
set ucport [string toupper $port];# Uppercase port
if {$ucport == "DIFF_DRVR_P"} {
# Change port name to port-link name per
# AIO_Port_Behavior attribute
set ret [iCall i13.AIO_set_VPP $voltage\
"TX_A" $vscale]
if {$ret == "TX_A" } {
return $port
} else {
return $ret
}
484 12 IEEE 1149.6: The 2015 Revision

# ... Handle other AIO ports.

} elseif {$port == ""} {
puts "A port must be specified when setting the\
peak-to-peak voltage on component $PDL_CONTEXT_PATH.\n"
return "AIO_ERROR"
} else {
puts "Setting the peak-to-peak voltage is not\
supported on port $PDL_CONTEXT_PATH.$port.\n"
return "AIO_ERROR"
}
}; # End AIO_set_VPP procedure
#######################################################
# AIO_get_VPP returns a voltage.
iProc AIO_get_VPP -export {{port ""} {vscale "1.0"}} {
set ucport [string toupper $port];# Uppercase port
if {$ucport == "DIFF_DRVR_P"} {
set ret [iCall i13.AIO_get_VPP "TX_A" $vscale]
# ... Handle any other AIO ports.
} elseif {$port == ""} {
puts "A port must be specified when getting the\
peak-to-peak voltage on component $PDL_CONTEXT_PATH.\n"
set ret "AIO_ERROR"
} else {
puts "Getting the peak-to-peak voltage is\
unsupported on pin $PDL_CONTEXT_PATH.$port.\n"
set ret "AIO_ERROR"
}
return $ret
}; # End AIO_get_VPP procedure
#######################################################
# AIO_getALL_VPP returns a voltage list.
iProc AIO_getALL_VPP -export {{port ""} {vscale "1.0"}}{
set ucport [string toupper $port];# Uppercase port
if {$ucport == "DIFF_DRVR_P"} {
set ret [iCall i13.AIO_getALL_VPP "TX_A" $vscale]
# ... Handle any other AIO ports.
} elseif {$port == ""} {
puts "A port must be specified when getting the\
peak-to-peak voltage list on component\
$PDL_CONTEXT_PATH.\n"
set ret "AIO_ERROR"
} else {
puts "Getting the peak-to-peak voltage is\
12.5 Integrated BSDL-PDL Example 485

unsupported on port $PDL_CONTEXT_PATH.$port.\n"

set ret "AIO_ERROR"
}
return $ret
};
# End of AIO_getALL_VPP
# END iProcGroup Part_1
#######################################################
Next is the BSDL entity from IC Vendor 2 that will reference the IP Package for
IP block B.

BSDL Entity from IC Vendor 2, using IP block B

entity Part_2 is
generic (PHYSICAL_PIN_MAP:string);
port(
... -- Many IC pins omitted.
Diff_Rcvr_P, Diff_Rcvr_N:out bit;
...-- More IC pins omitted.
);
use STD_1149_1_2013.all;
use STD_1149_6_2015.all;
use SerdesB.all; -- Get mnemonics and registers of IP-B
attribute COMPONENT_CONFORMANCE of Part_2:entity is
"STD_1149_1_2013";
attribute PIN_MAP of Part_2:entity is PHYSICAL_PIN_MAP;
-- Port grouping not required for inputs, so both pins
-- are listed in AIO_Pin_Behavior below.
...
attribute REGISTER_ASSEMBLY of Part_2:entity is
"init_data("& --Some of Part_2 init_data from IP-B
... -- TDI
" (i11 is PACKAGE SerdesB:init_data), "&
... – TDO
"Boundary("& -- Some of Part_2 Boundary from IP-B
... -- TDI
" (b11 is PACKAGE SerdesB:Boundary), "&
... – TDO
")";
attribute AIO_COMPONENT_CONFORMANCE of Part_2:entity is
"STD_1149_6_2015";
attribute AIO_Pin_Behavior of Part_2:entity is
...--Some other Part_2 1149.6 pins omitted
--Now include the IP-B receiver linked by "RX_B"
"Diff_Rcvr_P, Diff_Rcvr_N:PACKAGE SerdesB:RX_B ";
...
end entity Part_2;
486 12 IEEE 1149.6: The 2015 Revision

As before we see four references to “SerdesB” information, the first to read the
package, the second to bring the IP-B Init_Data segment into the ICs Init_Data
register, the third to bring the IP-B Boundary register segment into the IC’s Boundary
register and finally, the attachment of the “RX_B” port link behavior to two IC pins,
the differential pair Diff_Rcvr_P and Diff_Rcvr_N. Both of these are linked as they
have independent 1149.6 test facilities, which is why they did not appear in a port
grouping attribute.
Next, see the PDL delivered by IC Vendor 2 for an IC using IP block B. Again
there is a lot of error checking.

PDL routines from IC Vendor 2, using IP block B

###################### PDL for receiver ###############
iPDLLevel 1 –version STD_1149_1_2013
iProcGroup Part_2
#######################################################
# AIO_set_VTH returns a list of ports.
iProc AIO_set_VTH –export {voltage {port ""}\
{vscale "1.0"}}{
set ucport [string toupper $port];# Uppercase port
if {$ucport == "DIFF_RCVR_P ||\
$ucport == "DIFF_RCVR_N" } {
set ret [iCall i11.AIO_set_VTH "RX_B" $vscale]
if {$ret == "RX_B} {
set ret "Diff_Rcvr_P Diff_Rcvr_N"}
} elseif {$port == ""} {
puts "A pin must be specified when setting VTH.\n"
set ret "AIO_ERROR"
} else {
puts "Setting the threshold voltage is not\
supported on pin $PDL_CONTEXT_PATH.$port.\n"
set ret "AIO_ERROR"
}
return $ret
}; # End AIO_set_VTH procedure
#######################################################
# AIO_get_VTH returns a voltage.
iProc AIO_get_VTH –export {{port ""} {vscale "1.0"}} {
set ucport [string toupper $port];# Uppercase port
# Convert pin name to port link name and call IP PDL
if {$ucport == "DIFF_RCVR_P ||\
$ucport == "DIFF_RCVR_N" } {
set ret [iCall i11.AIO_get_VTH "RX_B" $vscale]
12.5 Integrated BSDL-PDL Example 487

} elseif {$port == ""} {

puts "A pin must be specified when getting VTH.\n"
set ret "AIO_ERROR"
} else {
puts "Getting the threshold voltage is not\
supported on pin $PDL_CONTEXT_PATH.$port.\n"
set ret "AIO_ERROR"
}
return $ret
}; # End AIO_get_VTH procedure
#######################################################
# AIO_getALL_VTH returns a voltage list.
iProc AIO_getALL_VTH -export {{port ""} {vscale "1.0"}}{
set ucport [string toupper $port];# Uppercase port
if {$ucport == "DIFF_RCVR_P ||\
$ucport == "DIFF_RCVR_N" } {
set ret [iCall i11.AIO_getALL_VTH "RX_B" $vscale]
} elseif {$port == ""} {
puts " A pin must be specified when getting VTH.\n"
set ret "AIO_ERROR"
} else {
puts "Getting the threshold voltage is not\
supported on pin $PDL_CONTEXT_PATH.$port.\n"
set ret "AIO_ERROR"
}
return $ret
}; # End AIO_getALL_VTH procedure
# END iProcGroup Part_2
#######################################################

Now, imagine you have the board shown in Fig. 12.1 and you want to run
Boundary-Scan tests on it. Your first task is to round up the BSDLs for all the ICs
on the board. You notice IC1 and IC2 come with supporting BSDL packages, and
also, some supporting PDL code. You must look into these to see if they too have
supporting BSDL/PDL from IP suppliers, which indeed these ICs do. Now you can
do some strategy thinking.
The BSDL shows you that the two nets driven from IC1 to IC2 will need to have
programmable voltages set for them, and this means checking what driver parame-
ters to set, and what parameters the receiver should have to work properly. Note
these might be different levels for AC testing (with EXTEST_PULSE) versus DC
testing for the board-level capacitor shorts tests, using EXTEST. You also note the
PDL mentions scaling must be accounted for if the devices are connected to a non-
nominal VDD voltage. You check that first, and find the nominal voltages are con-
nected, so scaling is not an issue. If it were, you would need to figure out the scale
factors for the PDL calls. When this research is done, you have some choices
488 12 IEEE 1149.6: The 2015 Revision

prepared for programmable voltages. You noticed during this study that all the
PDLs did not do any iApply commands, but left that step for you. This allows you
to call several PDL routines to set up parameter values inside the Init_Data register,
and then issue a single iApply that will scan all the values in (along with loading the
INIT_SETUP instruction) only one time, which will improve throughput.
You also noticed that INIT_RUN is required sometime after the AIO_set_VPP
routine is called, to “finish the job” of turning driver power on, before the driver will
produce correct voltages. This will be simple, just load INIT_RUN and wait for the
specified number of TCK cycles to pass. A data sheet tells you it needs 500 cycles.
And the action is deterministic so the INIT_STATUS register does not need to be
sampled for completion. Great!
But before you do that, your board testing tool needs a model of the Boundary-
Scan chain as it exists on the board. So you run it in the mode where it picks up the
board netlist data and finds all the devices, device pins and interconnection data for
the board. It also picks up all the BSDL files that you have obtained for the devices.
Using this data, it automatically figures out the chain of Boundary-Scan devices and
their ordering in the chain. It can then build an image of the board’s complete set of
Boundary-Scan data registers. These form a data image that a PDL interpreter for a
board could use to manage a board test. We assume this board data is named “Chain”,
and we have a hierarchy. For example, “Chain.IC_1” is how to refer to IC_1, which
is a “Part_1” device. (There could be multiple instances of Part_1 on a board.)
So now you can write some PDL that sets up the driver/receiver pair. You’ve
picked a driver VPP of 800mv, a driver common-mode voltage of 500mv and the
receiver threshold also to be 500mv. This should work for both AC and DC testing
which is good too. So here it is:

# PDL Code to initialize IC-1 and IC-2 for communication

# Both chip VDDs for I/O are nominal, vscale is allowed
# to default to 1.0 for all the calls
iTMSReset; # Synchronize the chain of devices to TLR
# This sets IRs to their default instructions. Now set
# up data in IC_1 and IC_2 for communicating.
iCall IC_1.Part_1.AIO_set_VPP 800 "Diff_Drvr_P"
iCall IC_1.Part_1.AIO_set_VCM 500 "Diff_Drvr_P"
iCall IC_2.Part_2.AIO_set_VTH 500 "Diff_Rcvr_P"
# The Part_2 call will set both Rcvr_P and Rcvr_N
# Now the relevant Init_Data fields of Part_1 and
# Part_2 are ready. Scan the chain of ICs.
iApply; # Scan Init_Data contents to the board
# This board-level iApply uses INIT_SETUP in IC_1
# and IC_2. Other devices stay with default IR.
iRead IC_1.Part_1.Init_Status ;# Nothing expected.
iApply; # This puts IC_1 into INIT_RUN.
iRunLoop 500; # Wait 500 TCKs for driver to get ready
... ;# Continue with test.
12.6 Design for IEEE 1149.6-2015 Testability 489

Close analysis shows that the second iApply must also do an instruction load in
the chain, so all the devices except IC_1 get the same instruction loaded as before,
but IC_1 gets INIT_RUN loaded. Note that IC_2 still has INIT_SETUP loaded, so
its data (unchanged) will get scanned in again. No harm, but good to be aware of.
This example is (of course) for a fictional tester. Real testers do exist, but they
likely have their own operating environment and might use PDL code as a start to
creating a test, after translating it into their realm. They might take in this infor-
mation, and display all the activities it causes, in some form of graphical display
for the test engineer to view. It might display the coupled I/O driver/receiver com-
binations on the board and show the engineer what fixed parameters are at work,
and where parameters might be selectable. It could “suggest” voltage parameters
that could work, but allow the engineer to fine tune or override those selections. It
could also display what connections are likely to be problematic, so the engineer
can see what portions of the board networks might not be testable or need an
alternative approach. Finally, it could show the engineer where some activities
could be run in parallel. In the example, above, two registers in IC_1 and one
register in IC_2 are all scanned with a single data scan to set up voltage parame-
ters. However, they could have been done individually (though less efficiently) by
having an iApply after each call. A good tester operating system will look for
such opportunities for parallelism and offer them to the engineer. In most cases
they would make sense, but sometimes, for special instructions or functional tests,
it might be important to sequence activities in a preordained order under the con-
trol of the test engineer.
This has been a long example, but of a relatively simple case of two IP blocks
and two ICs. The 1149.6-2015 standard offers other, more complex examples. In
particular, see the example given in Sect. 7.8.2 of a custom programmable I/O IP
block with several bus-programmable parameters, instantiated four times into an
IC. The IP BSDL/PDL, and the IC BSDL/PDL is presented in the space of about 15
pages. It’s good we have computerized tools to help us deal with this information.
Though it may seem daunting, we are benefiting from having such data that was so
difficult to see and/or obtain in the past.

12.6 Design for IEEE 1149.6-2015 Testability

Here are two DFT rules that should be considered by device designers.
DFT-58: For all selectable features of an 1149.6 I/O pin, assure they are
controlled by fields within the Init_Data register and supply a BSDL register
fields description for them, with friendly register mnemonics to help users
identify them.
The 2015 release should make the features of an IC’s 1149.6 implementation
much more transparent and useable. This will pay off for the IC vendor in a reduc-
tion of support issues from their customers.
490 12 IEEE 1149.6: The 2015 Revision

DFT-59: If there are on-chip in-line capacitors, consider supplying pro-

grammable bypasses (shunts) for them, or in the least, automatically shunt
them when EXTEST is the effective instruction. Show these choices in the
BSDL with the On_Chip_AC, On_Chip_Programmable or On_Chip_AC_
Programmable keywords.
This allows the test engineer the ability to use EXTEST to test board-mounted
coupling capacitors. Otherwise, the on-chip capacitor isolates the test receiver from
DC levels coming on-chip from a potentially shorted board-mounted capacitor
under test, frustrating the purpose of the test.
Appendix A
BSDL Syntax Specifications

This Appendix is a condensed listing of 2001 BSDL lexicography and syntax.

It does not include the myriad semantic rules found in the BSDL specification as
provided by the IEEE [IEEE01]. This information may be helpful to someone
contemplating writing a BSDL parser, or to someone needing a quick reference
guide for BSDL syntax when writing a BSDL description. It is assumed the reader
is familiar with formalized specification of language.

A.1 Conventions

All reserved words, predefined words, and punctuation are shown in Courier New
type within this document. VHDL reserved and predefined words will be shown in
lowercase letters, and BSDL reserved words will be shown in UPPERCASE letters.
(BSDL itself is case-insensitive; this convention is adopted for descriptive clarity.)

A.2 Lexical Elements of BSDL

The lexical elements of BSDL are a subset and standard practice of those of VHDL
as defined in IEEE Std 1076-1993. The following sections enumerate the lexical
elements needed to understand the BSDL language definition.

A.2.1 Character Set

• Upper- and lowercase letters: A to Z and a to z (the language is not case

sensitive).

© Springer International Publishing Switzerland 2016 491

K.P. Parker, The Boundary-Scan Handbook, DOI 10.1007/978-3-319-01174-5
492 A BSDL Syntax Specifications

• Digits: 0–9.
• Special characters: " & ‘ ( ) * , - . : ; < = >
• Logical separators: The space character, horizontal tabulation, vertical tabulation,
carriage return, line feed, and form feed.

A.2.2 Identifiers

Identifiers are user-supplied names and reserved words functioning as names.

Identifiers start with a letter and may contain letters, digits, or the underscore
character. For example, the following are valid identifiers:

Boundary_Scan
IEEE_Std_1149_1

There is no limit to the number of characters in an identifier. The underscore

character (_) is not allowed as the last character in an identifier (by VHDL).

IEEE_STD_1149_ -- This is not a legal identifier.

Adjacent underscore characters (_ _) are not allowed.

A.2.3 BSDL Reserved Words

The identifiers listed in this section are BSDL reserved words with a fixed signifi-
cance in the language. These identifiers cannot be used for any other purpose in a
BSDL description. For example, a reserved word cannot be used as an explicitly
declared identifier. BC_0 to BC_99 are variable names used in the Standard VHDL
Package. Names BC_0 through BC_10 are used today, while BC_11 through BC_99
are reserved for future use. Similarly, the names STD_1149_1_1990,
STD_1149_1_1993, STD_1149_1_1994 and STD_1149_1_2001 have been
reserved, with the potential for new names to be added later. Therefore, avoid using
identifiers that start with “STD_1149_”.

AT_PINS INTERNAL
BC_0 to BC_99 INTEST
BIDIR INTEST_EXECUTION
BIDIR_IN KEEPER
BIDIR_OUT LOW
BOTH OBSERVE_ONLY
BOUNDARY OBSERVING
BOUNDARY_LENGTH ONE
BOUNDARY_REGISTER OUTPUT2
A.2 Lexical Elements of BSDL 493

BSCAN_INST OUTPUT3
BSDL_EXTENSION PHYSICAL_PIN_MAP
BYPASS PI
CAP PIN_MAP
CAP_DATA PIN_MAP_STRING
CAPTURES PO
CELL_DATA PORT_GROUPING
CELL_INFO PRELOAD
CELL_TYPE PULL0
CLAMP PULL1
CLOCK REGISTER_ACCESS
CLOCK_INFO RUNBIST
CLOCK_LEVEL RUNBIST_EXECUTION
COMPLIANCE_PATTERNS SAMPLE
COMPONENT_CONFORMANCE STD_1149_1_1990
CONTROL STD_1149_1_1993
CONTROLR STD_1149_1_1994
DESIGN_WARNING STD_1149_1_2001
DEVICE_ID TAP_SCAN_CLOCK
DIFFERENTIAL_CURRENT TAP_SCAN_IN
DIFFERENTIAL_VOLTAGE TAP_SCAN_MODE
EXPECT_DATA TAP_SCAN_OUT
EXTEST TAP_SCAN_RESET
HIGHZ UPD
ID_BITS USERCODE
ID_STRING USERCODE_REGISTER
IDCODE WAIT_DURATION
IDCODE_REGISTER WEAK0
INPUT WEAK1
INSTRUCTION_CAPTURE X
INSTRUCTION_LENGTH Z
INSTRUCTION_OPCODE ZERO
INSTRUCTION_PRIVATE

A.2.4 VHDL Reserved and Predefined Words

The identifiers listed below are called VHDL (IEEE Standard 1076-1993) reserved
and predefined words with a fixed significance in the language. These identifiers
may not be used for any other purpose in a BSDL description. For example, a
reserved word cannot be used as an explicitly declared identifier. Reserved words
shown in the list below in lowercase letters are part of the BSDL subset of
VHDL. Those in uppercase letters are not part of BSDL, but should not be used as
494 A BSDL Syntax Specifications

identifiers. The latest edition of the VHDL standard [IEEE93b] shall be consulted as
the final authority.

ABS GUARDED REGISTER

ACCESS IF REJECT
AFTER IMPURE REM
ALIAS in REPORT
all INERTIAL RETURN
AND inout ROL
ARCHITECTURE is ROR
array LABEL SELECT
ASSERT LIBRARY SEVERITY
attribute linkage SHARED
BEGIN LITERAL signal
bit LOOP SLA
bit_vector MAP SLL
BLOCK MOD SRA
body NAND SRL
buffer NEW string
BUS NEXT subtype
CASE NOR THEN
COMPONENT NOT to
CONFIGURATION NULL TRANSPORT
constant of true
DISCONNECT ON type
downto OPEN UNAFFECTED
ELSE OR UNITS
ELSIF OTHERS UNTIL
end out use
entity package VARIABLE
EXIT port WAIT
false positive WHEN
FILE POSTPONED WHILE
FOR PROCEDURE WITH
FUNCTION PROCESS XNOR
GENERATE PURE XOR
generic range
GROUP record

A.2.5 Strings

A string is defined as a sequence of zero or more characters enclosed between quo-

tation marks. A quotation mark character is not allowed within a string in BSDL. For
example,
A.3 Notes on Syntax Definition 495

"Mary had a little lamb" -- Allowed

"Fred said ""HELP""" -- Not allowed

Strings are used extensively in BSDL. Because many of the BSDL strings are
potentially much longer than a single line, the concatenation operator & is used to
break them into manageable pieces. For example,

"Jack be nimble," &

" Jack be quick."

is a single string, identical to

"Jack be nimble, Jack be quick."

BSDL does not permit replacement of the quotation mark with any other charac-
ter. A string literal must fit on one line since it is a lexical element.

A.2.6 Comments

Any text between a double dash (--) symbol and the end of a line is treated as a
comment. The text is allowed to contain any characters allowed by VHDL. Comments
syntactically terminate a line of a description. Comments may be interspersed with
lexical elements. For example, the following represents a single VHDL string:

"This is" & -- An example of a string split by a comment

" a single string"

A.3 Notes on Syntax Definition

A.3.1 BNF Conventions

• Any item enclosed in chevrons (i.e., between the character “<” and the character
“>”) is the name of a syntax item that will be defined in this appendix.
• Items enclosed by braces (i.e., between the character “{” and the character “}”)
may be omitted or included one or more times.
• Items enclosed between square brackets (i.e., between the character “[” and the
character “]”) may be omitted or included only one time.
• Items enclosed between the symbols “→” and “←” may appear in any order.
• Except with regard to case, text shown in Courier New type font has to be
included exactly as it is presented in this appendix.
• Alternative syntaxes are separated by a vertical bar (“|” ).
• The symbol “::=” should be read as “is defined as.” Note that the non-boldface
“::=” is only part of a BNF description; in the BSDL file, the boldface characters
“:=” are used to indicate assignment.
496 A BSDL Syntax Specifications

• White space (spaces, tabulation, carriage returns, etc.) is used in these BNF
descriptions to enhance readability and is not part of the syntax. However, white
space needed for resolving lexical ambiguity is required.

A.3.2 Lexical Atoms

• A <VHDL identifier> is a valid identifier, chosen as a name for an item.

• An <integer> is an unsigned VHDL integer made up of an unsigned numeric
character sequence not containing an underscore (_) character and not using an
exponent field.
• A <real number> is a VHDL real number of the form <integer>.<integer> or
<integer>.<integer>E<integer> all written contiguously without spaces or for-
mat effectors. Note 1E3 is not real because it does not contain a decimal point.
The number 20.0E6 is real, as is 20000000.0.
• A <pattern> is a contiguous sequence of one or more 0, 1, and X characters con-
taining no spaces. For example, 001X00 and XX010X are legal. However, 100
X00 is not legal because of the embedded space. A low state is denoted by 0, a
high state is denoted by 1, and a don’t-care value is denoted by X.
• A <32-bit pattern> is a <pattern> with exactly 32 characters in its character
sequence.
• A <left bracket> is the left bracket character ([).
• A <right bracket> is the right bracket character (]).
Lexical ambiguity exists in certain situations and has to be resolved by context.
For example, a <pattern> that starts with an X has to be differentiated from a <VHDL
identifier> by context derived from the syntax. Similarly, a <pattern> that does not
contain an X has to be differentiated from an integer such as 100 (one hundred).

A.3.3 Commonly Used Syntactic Elements

• A <port ID> identifies a component signal that may be used to interface to exter-
nal signals. A port may be dimensioned as a bit or a bit_vector. Subscripted
names are allowed only when bit_vector-dimensioned port signals are used.

<port ID>::= <port name> | <subscripted port name>

<port name>::= <VHDL identifier>
<subscripted port name>::= <VHDL identifier> (<subscript>)
<subscript>::= <integer>

• An <instruction name> is an instruction name defined in this standard or a name

given to an instruction by the manufacturer of a component.

<instruction name>::= BYPASS | CLAMP | EXTEST | HIGHZ |

IDCODE | INTEST | PRELOAD |RUNBIST |
SAMPLE | USERCODE | <VHDL identifier>
A.4 BSDL Syntax 497

A.4 BSDL Syntax

The BSDL entity description must have the following structure:

<BSDL description>::=
entity <component name> is
<generic parameter>
<logical port description>
<standard use statement>
{<use statement>}
<component conformance statement>
<device package pin mappings>
[<grouped port identification>]
<scan port identification>
[<compliance enable description>]
<instruction register description>
[<optional register description>]
[<register access description>]
<boundary-scan register description>
[<runbist description>]
[<intest description>]
{<BSDL extensions>}
[<design warning>]
end <component name>;

<component name>::= <VHDL identifier>

<generic parameter>::=
generic (PHYSICAL_PIN_MAP: string); |
generic (PHYSICAL_PIN_MAP: string :=
<default device package type>);
<default device package type>::= " <VHDL identifier> "
<logical port description>::= port (<pin spec>
{; <pin spec>});
<pin spec>::= <identifier list>: <pin type> <port dimension>
<identifier list>::= <port name> {,<port name>}
<pin type>::= in | out | buffer | inout | linkage
<port dimension>::= bit | bit_vector (<range>)
<range>::= <integer_1> to <integer_2> |
<integer_2> downto <integer_1>
<integer_1>::= <integer>
<integer_2>::= <integer>
<standard use statement>::=
use <standard VHDL package identifier>.all;
<standard VHDL package identifier>::= STD_1149_1_1990 |
STD_1149_1_1994 | STD_1149_1_2001 |
<other package identifier>
<other package identifier>::= <VHDL identifier>
498 A BSDL Syntax Specifications

<use statement>::= use <user VHDL package identifier>.all;

<user VHDL package identifier>::= <VHDL identifier>
<component conformance statement>::=
attribute COMPONENT_CONFORMANCE of
<component name>: entity is <conformance string>;
<conformance string>::= " <conformance identification> "
<conformance identification>::=
STD_1149_1_1990 | STD_1149_1_1993 | STD_1149_1_2001
<device package pin mappings>::=
<pin map statement> <pin mappings>
<pin map statement>::=
attribute PIN_MAP of <component name>: entity is
PHYSICAL_PIN_MAP;
<pin mappings>::= <pin mapping> {<pin mapping>}
<pin mapping>::=
constant <pin mapping name>: PIN_MAP_STRING:=
<map string>;
<pin mapping name>::= <VHDL identifier>
<map string>::= " <port map> {, <port map>} "
<port map>::= <port name>: <pin list>
<pin list>::= <pin ID> | (<pin ID> {, <pin ID>})
<pin ID>::= <VHDL identifier> | <integer>
<grouped port identification>::=
attribute PORT_GROUPING of <component name>: entity is
<group table string>;
<group table string>::= " <group table> "
<group table>::= <twin group entry> {, <twin group entry>}
<twin group entry>::= <twin group type> (<twin group list>)
<twin group type>::= DIFFERENTIAL_VOLTAGE |
DIFFERENTIAL_CURRENT
<twin group list>::= <twin group> {, <twin group>}
<twin group>::= (<representative port>, <associated port>)
<representative port>::= <port ID>
<associated port>::= <port ID>
<scan port identification>::= → <TCK stmt> <TDI stmt>
<TMS stmt> <TDO stmt> [<TRST stmt>] ←
<TCK stmt>::=
attribute TAP_SCAN_CLOCK of <port ID> : signal is
(<clock record>);
<TDI stmt>::=
attribute TAP_SCAN_IN of <port ID> : signal is true;
<TMS stmt>::=
attribute TAP_SCAN_MODE of <port ID>: signal is true;
<TDO stmt>::=
attribute TAP_SCAN_OUT of <port ID>: signal is true;
A.4 BSDL Syntax 499

<TRST stmt>::=
attribute TAP_SCAN_RESET of <port ID> : signal is true;
<clock record>::= <real number> , <halt state value>
<halt state value>::= LOW | BOTH
<compliance enable description>::=
attribute COMPLIANCE_PATTERNS of <component name> :
entity is <compliance pattern string> ;
<compliance pattern string>::= " ( <compliance port list> )
( <pattern list> )"
<compliance port list>::= <port ID> { , <port ID>}
<pattern list>::= <pattern> { , <pattern> }
<instruction register description>::=
<instruction length stmt>
<instruction opcode stmt>
<instruction capture stmt>
[<instruction private stmt>]
<instruction length stmt>::=
attribute INSTRUCTION_LENGTH of <component name>
: entity is <integer>;
<instruction opcode stmt>::=
attribute INSTRUCTION_OPCODE of <component name> :
entity is <opcode table string>;
<instruction capture stmt>::=
attribute INSTRUCTION_CAPTURE of <component name> :
entity is <pattern list string>;
<instruction private stmt>::=
attribute INSTRUCTION_PRIVATE of <component name> :
entity is <instruction list string>;
<opcode table string>::=
" <opcode description> {, <opcode description>} "
<pattern list string>::=" <pattern list> "
<pattern list>::= <pattern> {, <pattern>}
<instruction list string>::= " <instruction list> "
<instruction list>::= <instruction name>
{, <instruction name>}
<opcode description>::=<instruction name> (<pattern list>)
<optional register description>::=
→ <idcode statement> [<usercode statement>] ←
<idcode statement>::=
attribute IDCODE_REGISTER of <component name>: entity is
<32-bit pattern list string>;
<usercode statement>::=
attribute USERCODE_REGISTER of <component name>
: entity is <32-bit pattern list string>;
<32-bit pattern list string>::= " <32-bit pattern list> "
500 A BSDL Syntax Specifications

<32-bit pattern list>::= <32-bit pattern>

{, <32-bit pattern>}
<register access description>::=
attribute REGISTER_ACCESS of <component name>: entity is
<register string>;
<register string>::=
" <register association> {, <register association>} "
<register association>::=
<register> (<instruction capture list>)
<instruction capture list>::=
<instruction capture> {, <instruction capture>}
<instruction capture>::=
<instruction name> [CAPTURES <pattern>]
<register>::= BOUNDARY | BYPASS | DEVICE_ID |
<VHDL identifier> <left bracket> <register length>
<right bracket>
<register length>::= <integer>
<boundary-scan register description>::=
<boundary length stmt> <boundary register stmt>
<boundary length stmt>::=
attribute BOUNDARY_LENGTH of <component name>: entity is
<integer>;
<boundary register stmt>::=
attribute BOUNDARY_REGISTER of <component name>
: entity is <cell table string>;
<cell table string>::= " <cell table> "
<cell table>::= <cell entry> { , <cell entry> }
<cell entry>::= <cell number> ( <cell info> )
<cell number>::= <integer>
<cell info>::= <cell spec> [ , <disable spec> ]
<cell spec>::= <cell name> , <port ID or null> , <function> ,
<safe bit>
<cell name>::= <VHDL identifier>
<port ID or null>::= <port ID> | *
<function>::= INPUT | OUTPUT2 | OUTPUT3 | CONTROL |
CONTROLR | INTERNAL | CLOCK | BIDIR | OBSERVE_ONLY
<safe bit>::= 0 | 1 | X
<disable spec>::= <ccell> , <disable value> ,
<disable result>
<ccell>::= <integer>
<disable value>::= 0 | 1
<disable result>::= Z | WEAK0 | WEAK1 | PULL0 |
PULL1 | KEEPER
<runbist description>::=
attribute RUNBIST_EXECUTION of <component name>
A.5 User Package Syntax 501

: entity is " <runbist spec> ";

<runbist spec>::= <wait spec> , <pin spec> , <signature spec>
<wait spec>::= WAIT_DURATION (<duration spec>)
<duration spec>::= <clock cycles list> |
<time> [ , <clock cycles list> ]
<clock cycles list>::= <clock cycles> { , <clock cycles> }
<time>::= <real number>
<clock cycles>::= <port ID> <integer>
<pin spec>::= OBSERVING <condition> AT_PINS
<condition>::= HIGHZ | BOUNDARY
<signature spec>::= EXPECT_DATA <det pattern>
<det pattern>::= <bit> { <bit> }
<bit>::= 0 | 1
<intest description>::=
attribute INTEST_EXECUTION of <component name>
: entity is " <intest execution sequence> ";
<intest execution sequence>::= <wait spec> , <pin spec>
<BSDL extensions>::= <BSDL extension> { <BSDL extension> }
<BSDL extension>::= <extension declaration> |
<extension definition>
<extension declaration>::=
attribute <extension name> : BSDL_EXTENSION;
<extension definition>::= attribute <extension name> of
<component name> : entity is
<extension parameter string>;
<extension name>::= <entity defined name> |
<VHDL package defined name>
<entity defined name>::= <VHDL identifier>
<VHDL package defined name>::= <VHDL identifier>
<extension parameter string>::= <string>
<design warning>::=
attribute DESIGN_WARNING of <component name> : entity is
<string> ;

A.5 User Package Syntax

<user package>::= package <user package name> is

<standard use statement>
{ <extension declaration> }
{ <deferred constant> }
end <user package name> ;

<user package body>::= package body <user package name> is

502 A BSDL Syntax Specifications

<standard use statement>

{ <cell description constant> }
end <user package name> ;

<user package name>::= <VHDL identifier>

<deferred constant>::= constant <cell name> : CELL_INFO;
<cell name>::= <VHDL identifier>
<cell description constant>::=
constant <cell name> : CELL_INFO := (
<capture descriptor list> ) ;
<cell name>::= <VHDL identifier>
<capture descriptor list>::= <capture descriptor>
{ , <capture descriptor> }
<capture descriptor>::= ( <cell context> ,
<capture instruction> , <data source> )
<cell context>::= INPUT | OUTPUT2 | OUTPUT3 |
INTERNAL | CONTROL | CONTROLR | CLOCK |
BIDIR_IN | BIDIR_OUT | OBSERVE_ONLY
<capture instruction>::= EXTEST | SAMPLE | INTEST
<data source>::= PI | PO | CAP | UPD | ZERO | ONE | X

A.6 1149.6 Extention Attribute Syntax

The 1149.6 extension contains some new attributes with a specific syntax that needs
to be recognized by tools that support 1149.6. An example is shown in Sect. 8.6.3
on page 331. This syntax is listed here:

<AIO Extension> ::=

<AIO component conformance statement>
→ [<AIO optional EXTEST_PULSE description>]
[<AIO optional EXTEST_TRAIN description>]←
[<AIO optional pin behavior description>]

<AIO component conformance statement> :: =

attribute AIO_Component_Conformance of
<component name> : entity is <AIO conformance string> ;
<AIO conformance string> ::=
" <AIO conformance identification> "
<AIO conformance identification> ::= STD_1149_6_2003

<AIO optional EXTEST_PULSE description> :: =

attribute AIO_EXTEST_Pulse_Execution of
<component name> : entity is <AIO EXTEST_Pulse string> ;
<AIO EXTEST_Pulse string> ::= " <AIO EXTEST_Pulse spec> "
A.6 1149.6 Extention Attribute Syntax 503

<AIO EXTEST_Pulse spec> ::= wait_duration <time spec>

<time spec> ::= <real number> | <clock cycles>
<clock cycles> ::= <port ID> <integer>

<AIO optional EXTEST_TRAIN description> :: =

attribute AIO_EXTEST_Train_Execution of
<component name> : entity is <AIO EXTEST_Train string> ;
<AIO EXTEST_Train string> ::= " <AIO EXTEST_Train spec> "
<AIO EXTEST_Train spec> ::= <min pulse count>
[ , <max time spec> ]
<min pulse count> ::= train <pulse count>
<max time spec> ::= maximum_time <real number>
<pulse count> ::= <integer>

<AIO optional pin behavior description> :: =

attribute AIO_Pin_Behavior of
<component name> : entity is <AC pin string> ;
<AC pin string> ::= " <AC pin info list> "
<AC pin info list> ::= <AC pin info> { ; <AC pin info> }
<AC pin info> :: = <AC port list>
[ : [<AC/DC select cell> ][ <time constants> ]]
<AC port list> ::= <AC port> { , <AC port> }
<time constants> ::= [ <LP time constant> ]
[ <HP time constant> ]
<AC port> ::= <port ID> [ <input cell list> ]
<input cell list> ::= <left bracket> <cell number list>
<right bracket>
<cell number list> ::= <cell number> { , <cell number> }
<AC/DC select cell> ::= AC_Select = <cell number>
<LP time constant> ::= LP_time = <time constant>
<HP time constant> ::= HP_time = <time constant>[ On_chip ]
<time constant> ::= <real number>
Appendix B
2013 BSDL Syntax Revisions

This Appendix is a compendium of changes to the 2001 version of BSDL lexicog-

raphy and syntax which were introduced in the 2013 version of the 1149.1 standard.
It does not include the myriad semantic rules found in the BSDL specification as
provided by the IEEE [IEEE13]. This information supplements that found in
Appendix A and follows the same conventions. It also completes the introductory
information in Chap. 11 which serves to motivate why these changes exist.

B.1 Reserved Word Changes

There are two categories of reserved words in BSDL; first are those inherited from
VHDL (see Sect. A.2.4) and second are those defined by BSDL itself (see
Sect. A.2.3).

B.1.1 VHDL Reserved Words

In Sect. A.2.4 there is a table of VHDL reserved words. These are divided into two
groups with one group (in lowercase letters) being a set of reserved words from
VHDL that have specific meaning in BSDL. The second group (in uppercase letters)
were other VHDL reserved words not adopted by BSDL. These were considered
reserved anyway and BSDL code was not to use them, since that would prevent

© Springer International Publishing Switzerland 2016 505

K.P. Parker, The Boundary-Scan Handbook, DOI 10.1007/978-3-319-01174-5
506 B 2013 BSDL Syntax Revisions

such code from being parsed by a VHDL tool. That is no longer the case with the
2013 release, so the only VHDL reserved words are shown in this abbreviated table.

All Entity Positive

Array Generic Range
Attribute In Record
Bit Inout Signal
Bit_vector Is String
Body Of Subtype
Buffer Others To
Constant Out True
Downto Package Type
End Port Use

B.1.2 BSDL Reserved Words

In Sect. A.2.3 there is a table of BSDL reserved words. This list has been lengthened
by adding the following 66 reserved words.

Broadcastfield Open0
Broadcastvalues Open1
Clamp_hold OpenX
Clamp_release Power_0
Default Power_pos
DelayPO Power_neg
Domain Power_port_association
Domain_external Pulse0
Domctrl Pulse1
Dompor Register_access
ECID Register_assembly
ECIDcode Register_association
Expect0 Register_constraints
Expect1 Register_fields
Hierreset Register_mnemonics
IC_reset Reset_select
Init_data Resetval
Init_run Segment
Init_setup Segmux
Init_setup_clamp Segsel
Init_Status Segstart
Linkage_buffer Selectmux
Linkage_in Selectfield
Linkage_inout Selectvalues
Linkage_mechanical Shared
B.1 Reserved Word Changes 507

Linkage_out TAPreset
Mon Tie0
NoPI Tie1
NoPO TMP_Status
Noretain TRSTreset
NoUPD User
One_hot Vref_in
Open Vref_out

B.1.3 Numeric Literals

Appendix A lists several numeric literals: <integer>, <real number>, <pattern> and
<32-bit pattern> (see Sect. A.3.2). The 2013 revision of BSDL adds three new
numeric literal types:
• <binary pattern> is a contiguous string starting with 0b or 0B, followed by one
character from the set [01xX] and zero or more characters from the set [01xX_].
No spaces or format effectors1 may be embedded.
• <hex pattern> is a contiguous string starting with 0x or 0X, followed by one
character from the set [0-9a-fA-F] followed by zero or more characters from the
set [0-9a-fA-F_]. No spaces or format effectors may be embedded.
• <decimal pattern> is an unsigned contiguous string of characters from the set
[0-9], that does not have ‘0’ for the most significant (leftmost) digit of a multi-
digit number, contains no spaces or format effectors, and has a binary representa-
tion that fits within a 32-bit binary field.2

B.1.4 Identifiers

Identifiers are user-supplied names with the syntax token of <VHDL identifier>
(see Sect. A.2.2). The 2013 revision of BSDL adds the concept of a <mnemonic
identifier> and it is formed according a list of requirements. It also defines <prefix
identifier>.
A <mnemonic identifier> any combination of alphabetic characters (case insen-
sitive), digits and certain special characters such that:
• It contains at least one alphabetic character.
• It cannot be resolved to a <real>, <integer>, <binary pattern> <hex pattern>,
<decimal pattern> or <pattern> value.
• It is not the single character “U” (or “u”).

1
Format effectors include carriage returns, tab characters, line feeds, page ejects, etc.
2
This means the decimal number must be less than or equal to 232-1, which is 4,294,967,295.
508 B 2013 BSDL Syntax Revisions

• It cannot start with, or contain the BSDL comment characters, that is, double-
dash “--”.
• It may include these special characters:
– At-sign (@)
– Asterisk (*)
– Underscore (_)
– Minus sign (−)
– Plus sign (+)
– Vertical bar (|)
– Percent sign (%)
– Tilde (~)
– Period (.)
• It may be a valid <VHDL identifier>.
A <prefix identifier> is any combination of letters (case insensitive), digits and
the underscore character, not starting with a digit. A valid <VHDL identifier> may
serve as a <prefix identifier>. (With the exception of case insensitivity, a <prefix
identifier> follows the rules for Verilog identifiers.3) Prefix identifiers are used in
<register fields statement> descriptions (see Sect. 11.4.20) and certain PDL state-
ments (see Sect. 11.5).

B.1.5 Information Tags

An <information tag> is a nearly free-form string of zero or more characters with

very few restrictions. They are used to convey descriptive information, more like
comment text rather than strict syntax.
An <information tag> is:
• Zero or more characters contained between enclosing chevrons (< >).
• The enclosed characters may not include the right chevron (>), quotation mark
(“), double-dash (--) or format effectors.
An <information tag> cannot contain a BSDL comment and though it appears in
BSDL strings, it cannot itself contain a quotation mark. Since BSDL strings can be
expressed as concatenated smaller strings, a long information tag can be broken up
with the string concatenation method.

B.1.6 Port Types

The definition of <port type> is greatly expanded. These new types were added to
replace the LINKAGE type: LINKAGE_BUFFER, LINKAGE_IN, LINKAGE_
INOUT, LINKAGE_MECHANICAL, LINKAGE_OUT, POWER_0,

3
Verilog is a hardware description language alternative to VHDL in common use.
B.2 BSDL Syntax 509

POWER_NEG, POWER_POS, VREF_IN and VREF_OUT. See 11.4.7 for a

discussion of what these terms mean.

B.1.7 Pin Description

In Sect. A.4 you will see pins identified by <pin ID> tokens, and these can be either
<integer> values, or <VHDL identifier> values, reflecting pins that are numbered (33,
52, etc.), or have alphanumeric names like G13 or B7. This has been expanded in the
2013 revision so <pin ID> has been recast as <pin desc> and we see this syntax:

<pin desc> ::= <pin ID> | OPEN | TIE0 | TIE1

<pin ID>::= <VHDL identifier> | <integer>

These keywords allow a bit more descriptive information to be associated with

ports that touch the Boundary register, but are not bonded out of the package in
some of the packaging options. The details of pin descriptions are given in Sect.
11.4.11.

B.1.8 Instructions

In Sect. A.3.3 we see a definition of <instruction name>. This has been expanded
with the 2013 release of BSDL.

<instruction name>::= BYPASS | CLAMP | EXTEST | HIGHZ |

IDCODE | INTEST | PRELOAD |RUNBIST |
SAMPLE | USERCODE | ECIDCODE | CLAMP_HOLD |
CLAMP_RELEASE | TMP_STATUS |IC_RESET | INIT_SETUP |
INIT_SETUP_CLAMP | INIT_RUN | <VHDL identifier>

The new instructions are only defined for the 2013 release, so the conformance
identification must be STD_1149_1_2013 for them to appear.

B.2 BSDL Syntax

A BSDL entity description documents an IC at the die level, and also includes infor-
mation about one or more packaging alternatives, including just a bare die, if it is
ever operated as such.4 The 2013 revision of BSDL added a number of new descrip-
tive attributes to the language, and made some other changes. Those are shown

4
For example, if the Boundary-Scan circuitry is tested on an IC tester before packaging, the die pad
mapping will be needed.
510 B 2013 BSDL Syntax Revisions

below and are commented on the right side of the page. The comments are not part
of the description.
The BSDL entity description must have the following structure:

<BSDL description>::=
entity <component name> is
<generic parameter>
<logical port description> --changed at 2013
<standard use statement>
{<use statement>}
<component conformance statement>
<device package pin mappings> --changed at 2013
[<grouped port identification>]
<scan port identification>
[<compliance enable description>]
<instruction register description>
[<optional register description>]
[<register access description>] --changed at 2013
<boundary-scan register description> --changed at 2013
[<runbist description>]
[<intest description>]
[<system clock description>] --added at 2013
{<register mnemonics description>} --added at 2013
{<register fields description>} --added at 2013
{<register assembly description>} --added at 2013
{<register constraints description>} --added at 2013
{<register association description>} --added at 2013
{<power port association description>} --added at 2013
{<BSDL extensions>}
[<design warning>]
end <component name>;

The changed or added syntax structures are described in the remainder of this
section.

B.2.1 Logical Port Description

The <logical port description> syntax has undergone a few simple changes, in the
area of <pin type>:

<logical port description>::= port <left paren> <pin spec>

{ <semicolon> <pin spec> } <right paren> <semicolon>
<pin spec>::= <identifier list> <colon> <pin type> <port dimension>
<identifier list>::= <port name> { <comma> <port name>}
B.2 BSDL Syntax 511

<pin type>::= in | out | buffer | inout | LINKAGE_INOUT |

LINKAGE_BUFFER | LINKAGE_IN | LINKAGE_OUT |
LINKAGE_MECHANICAL | POWER_0 | POWER_POS |
POWER_NEG | VREF_IN | VREF_OUT
<port dimension>::= bit | <bit vector spec>
<bit vector spec> ::= bit_vector <left paren> <range> <right paren>
<range>::= <up range> | <down range>
<up range> ::= <integer1> to <integer2>
<down range> ::= <integer2> downto <integer1>
<integer1>::= <integer>
<integer2>::= <integer>

The pin type assignments are expanded. See Sect. 11.4.7 for their meanings.

B.2.2 Device Package Mappings

Some new detail is provided by the <device package pin mappings> area of
BSDL. This is <pin desc> information and is described in Sect. 11.4.11.

<device package pin mappings>::= <pin map statement> <pin mappings>

<pin map statement>::= attribute PIN_MAP of <component name>
<colon>
entity is PHYSICAL_PIN_MAP <semicolon>
<pin mappings>::= <pin mapping> { <pin mapping> }
<pin mapping>::= constant <pin mapping name> <colon>
PIN_MAP_STRING := <map string> <semicolon>
<pin mapping name>::= <VHDL identifier>
<map string>::= <quote> <port map> { <comma> <port map> } <quote>
<port map>::= <port name> <colon> <pin or list>
<pin or list>::= <pin desc> | <pin list>
<pin list> ::= <left paren> <pin desc> { <comma> <pin desc>} <right
paren>
<pin desc> ::= <pin ID> | OPEN | TIE0 | TIE1
<pin ID>::= <VHDL identifier> | <integer>

B.2.3 Register Access Description

The original <register access description appears as part of Sect. A.4. It has been
expanded as shown here:

<register access description> ::= attribute REGISTER_ACCESS of

<component name> <colon> entity is <register access string>
<semicolon>
512 B 2013 BSDL Syntax Revisions

<register access string>::= <quote> <register association>

{ <comma> <register association> } <quote>
<register association>::= <register> <left paren> <instruction
capture list>
<right paren>
<instruction capture list>::= <instruction capture> { <comma>
<instruction capture> }
<instruction capture>::= <instruction name> [ CAPTURES <pattern> ]
<register>::= <std fixed register> | <std var register> | <design
specific register>
<std fixed register>::= BOUNDARY | BYPASS | DEVICE_ID | TMP_STATUS
<std var register>::= <std var reg name> [ <left bracket>
<reg length> <right bracket> ]
<std var reg name>::= ECID | INIT_DATA | INIT_STATUS | RESET_SELECT
<design specific register>::= <VHDL identifier> [ <left bracket>
<reg length> <right bracket> ]
<reg length>::= <integer> | <asterisk>

B.2.4 Boundary-Scan Register Description

The Boundary-Scan register syntax has been expanded to describe both the pre-
2013 “static” or “fixed” register and the new “segmented” register form. More
descriptive detail for individual cells is also included, as discussed in Sect. 11.4.13.
The syntax of Boundary register description starts out like this:

<boundary-scan register description> ::= <fixed boundary stmts> |

<segment boundary stmts>
<fixed boundary stmts> ::= <boundary length stmt> <boundary
register stmt>
<segment boundary stmts> ::= <assembled boundary length stmt>
<boundary register segments>

Here we see the two forms, fixed and segmented. Each has a length statement
followed by the register description, either fixed or segmented. First let’s look at the
fixed form, discussed in Sect. 11.4.14.
<boundary length stmt> ::= attribute BOUNDARY_LENGTH of
<component name> <colon> entity is <register length> <semicolon>
<register length> ::= <integer>
<boundary register stmt> ::= attribute BOUNDARY_REGISTER of
<component name> <colon> entity is <cell table string>
<semicolon>
<cell table string> ::= <quote> <cell table> <quote>
<cell table> ::= <cell entry> { <comma> <cell entry> }
B.2 BSDL Syntax 513

<cell entry> ::= <cell number> <left paren> <cell info> <right
paren>
<cell number> ::= <integer>
<cell info> ::= <cell spec> [ <comma> <input or disable spec> ]
<cell spec> ::= <cell name> <comma> <port ID or null> <comma>
<function>
<comma> <safe bit>
<cell name> ::= <VHDL identifier>
<port ID or null> ::= <port ID> | <asterisk>
<function> ::= INPUT | OUTPUT2 | OUTPUT3 | CONTROL | CONTROLR |
INTERNAL | CLOCK | BIDIR | OBSERVE_ONLY
<safe bit>::= 0 | 1 | X
<input or disable spec> ::= <input spec> | <disable spec>
<input spec> :: = EXTERN0 | EXTERN1 | PULL0 | PULL1 | OPEN0 |
OPEN1 | KEEPER | OPENX | EXPECT1 | EXPECT0
<disable spec>::= <ccell> <comma> <disable value> <comma> <disable
result>
<ccell>::= <integer>
<disable value>::= 0 | 1
<disable result>::= WEAK0 | WEAK1 | PULL0 | PULL1 | OPEN0 |
OPEN1 | KEEPER | Z
Note above that both <input spec> and <disable result> have expanded lists of
keywords, as discussed in Sect. 11.4.13. Also note that a token called <input or dis-
able spec> has been inserted into the <cell info> syntax. This accounts for the new
<input spec> that may appear in a cell entry.
Next, here is the syntax for segmented Boundary register description, discussed
in Sect. 11.4.15.
<assembled boundary length stmt> ::= attribute
ASSEMBLED_BOUNDARY_LENGTH of <component name>
<colon> entity is <left paren> <reset length> <comma>
<register length> <right paren> <semicolon>
<reset length> ::= <integer>
<boundary register segments> ::= <boundary register segment>
{ <boundary register segment> }
<boundary register segment> ::= attribute BOUNDARY_SEGMENT of
<component name> <colon> entity is
<boundary segment string> <semicolon>
<boundary segment string>::= <quote> <boundary segment list>
{ <comma> <boundary segment list> } <quote>
<boundary segment list>::= <boundary segment name>
<left bracket> <boundary segment length> <right bracket>
<left paren> <cell table> <right paren>
<boundary segment name> ::= <VHDL identifier>
<boundary segment length> ::= <integer>
514 B 2013 BSDL Syntax Revisions

Note that <register length> and <cell table> definitions are given up in the fixed
register syntax, and is the same. The length statement differs in that it gives two
numbers for the Boundary register length, a “reset length” followed by a “register
length”. This is also discussed in Sect. 11.4.15.

B.2.5 System Clock Description

In some cases, an instruction will not work without a system clock being supplied
for its operation. The 1149.1 working group has provided a way in BSDL to describe
where such clocking is needed. This is the new SYSCLOCK_REQUIREMENTS
attribute. Here is the syntax:

<system clock description> ::= attribute SYSCLOCK_REQUIREMENTS

of <entity target> is <system clock description string> <semicolon>
<system clock description string>::= <quote> <system clock
requirement>
{ <comma> <system clock requirement> } <quote>
<system clock requirement>::= <left paren> <port ID> <comma> <min
freq>
<comma> <max freq> <comma> <clocked instructions> <right paren>
<min freq> ::= <real>
<max freq> ::= <real>
<clocked instructions> ::= <clocked instruction>
{ <comma> <clocked instruction> }
<clocked instruction> ::= RUNBIST | INTEST | INIT_SETUP | INIT_RUN |
INIT_SETUP_CLAMP | ECIDCODE | IC_RESET |
<VHDL identifier>

The <port ID> must refer to a port with an input capability (IN, INOUT,
LINKAGE_IN or LINKAGE_INOUT) and if it is a differential clock input pair, the
representative port is identified. Note that if the compliance level of the device is
pre-2013, then only RUNBIST or INTEST may be the clocked instruction. If the
device is a 2013-compliant device, then more standard instructions are allowed (see
<clocked instruction> above) but not those like EXTEST, BYPASS, SAMPLE,
PRELOAD, etc. These instructions use only TCK for clocking. Designer-specified
instructions that require clocking are provided by their <VHDL identifier>. See
more discussion and an example in Sect. 11.4.17.

B.2.6 Register Mnemonics Description

Register Mnemonics are a way in BSDL to associate names (called <mnemonic

identifiers>, see Sect. A.1.4) with numeric bit patterns (binary, hexadecimal, or
decimal) and also attach an optional descriptive <information tag> (see Sect. A.1.5)
with them. See usage detail and examples in Sect. 11.4.18.
B.2 BSDL Syntax 515

This is the register mnemonic description syntax:

<register mnemonics description>::= attribute REGISTER_MNEMONICS of

<target> is <register mnemonics string> <semicolon>
<target>::= <entity target> | <package target>
<entity target>::= <component name> <colon> entity
<package target>::= <user package name> <colon> package
<register mnemonics string>::= <quote> <mnemonic definition>
{ <comma> <mnemonic definition> } <quote>
<mnemonic definition>::= <mnemonic group name> <left paren>
<mnemonic list> <right paren>
<mnemonic group name>::= <VHDL identifier>
<mnemonic list>::= <mnemonic assignment>
{ <comma> <mnemonic assignment> }
<mnemonic assignment>::= <mnemonic identifier> <left paren>
<pattern specification> <right paren> [ <information tag> ]
<pattern specification>::= <binary pattern> | <hex pattern> |
<decimal pattern> | others

A <register mnemonics description is basically a comma-separated list of

<mnemonic definition> terms, each consisting of a group name <VHDL identi-
fier> followed by a parentheses-enclosed list of comma-separated <mnemonic
assignment> terms. Each such <mnemonic assignment> associates a <mnemonic
identifier> with a <pattern specification> followed, optionally, with an <informa-
tion tag>. All <mnemonic group name> elements must be unique within its con-
taining entity or package description. All <mnemonic identifier> elements that
appear in a <mnemonic list> must be unique within that list, but duplicates could
appear across multiple <mnemonic list> elements if more than one exists. Each
<mnemonic list> must contain at least one <mnemonic assignment> containing a
<binary pattern>, <hex pattern> or <decimal pattern>. This means you cannot have
a <mnemonic list> containing only one <mnemonic assignment> which contains
the keyword others.
When listing patterns in a <mnemonic list>, regardless of their being expressed
in binary, hex or decimal, they must be unique; however, all possible patterns do not
need to be specified. Note that “X” bits may exist in (only) a binary pattern. This
indicates that bit position may have either a ‘0’ or ‘1’ bit present, implying multiple
patterns. When such a binary pattern is used, all of its implied patterns belong to the
associated <mnemonic identifier> and must not be found in another portion of the
<mnemonic list>.
Unused pattern values may be referenced with the others keyword, and if this
keyword is listed in a <mnemonic list>, it must be the last one listed. When a <mne-
monic identifier> is associated with the others keyword, then all the patterns not
otherwise specified earlier in the list have that <mnemonic identifier> and that
(optional) <information tag>.
516 B 2013 BSDL Syntax Revisions

B.2.7 Register Fields Description

The register fields description is used to describe a data register and any segments that
make it up. The overall length of a register is given, followed by a listing of its seg-
ments, also named and with lengths provided. Note that not all bits of the data register
may be described within some segment, that is, some may be left undefined. The
syntax is given next, but, is divided into two portions. The first portion is unique to
the register fields attribute. The second is used by both the register fields and register
assembly attribute (see Sect. A.2.8) and it provides definitions of items like <value
assignment>, <type assignment> and <reset assignment>. The first syntax portion is:

<register fields description> ::= attribute REGISTER_FIELDS of

<target> is
<register fields string> <semicolon>
<register fields string>::= <quote> <register field list>
{ <comma> <register field list> } <quote>
<register field list>::= <reg or seg name> <left bracket> <reg or
seg length>
<right bracket> <left paren> <register fields> <right paren>
<reg or seg name>::= <TDR> | <segment name>
<TDR>::= BOUNDARY | BYPASS | DEVICE_ID | TMP_STATUS |
ECID | INIT_DATA | INIT_STATUS | RESET_SELECT |
<design specific TDR name>
<segment name>::= <VHDL identifier>
<design specific TDR name>::= <VHDL identifier>
<reg or seg length>::= <integer>
<register fields>::= <left paren> <register field element> <right
paren>
{ <comma> <left paren> <register field element> <right paren> }
<register field element>::= <register field> | <prefix statement>
<register field>::= <extended field name> <field length> is <bit list
and options>
<extended field name> ::= <prefix string> <field name>
<prefix string>::= { <prefix identifier> <period> }
<field name>::= <VHDL identifier>
<field length>::= <left bracket> <integer> <right bracket>
<bit list and options>::= <bit list> { <field options> }
<field options> ::= <type assignment> | <value assignment> | <reset
assignment>
<bit list>::= <left paren> [ <bit field> { <comma> <bit field> } ]
<right paren>
<bit field>::= <range> | <integer>
<prefix statement>::= PREFIX <integer> <prefix name>
<prefix name> ::= <prefix identifier> | <minus sign>

The definition of <range> is found in Sect. A.4. The definition of <prefix identi-
fier> is found in Sect. A.1.4. When a <reg or seg name> is that defined by the stan-
B.2 BSDL Syntax 517

dard (e.g., DEVICE_ID, BOUNDARY, etc.) then the value of <reg or seg length>
must equal the length of the register as already provided. Any bit number listed in a
<bit list> must be less than the <reg or seg length> for that <reg field list>. The bit
number zero is closest to TDO. When one or more <prefix statement> elements are
first found in a <register field list>, then they must be listed in numerical order start-
ing with Prefix 0. If a <prefix statement> is found in a subsequent <register field
list>, then it will overwrite the previous <prefix statement> with the same number
and erase all statements with larger numbers. If a <prefix statement> is given with a
name of <minus sign> that will erase all previously defined prefixes. When an
<extended field name> is encountered and there are defined prefixes, then that name
will have all of the prefixes prepended in their numerically ascending order, sepa-
rated with ‘.’ characters. All <extended field name> elements must be unique within
a BSDL entity or package. When a <field length> is zero, then the associated <bit
list> must be empty “()”. A test register bit number may be referenced in more than
one <register field>, but within a given <register field>, it may only appear once.
See examples in Sect. 11.4.20.
Next is the second portion of syntax, shared with the register assembly attribute:

<value assignment>::= <value keyword> <left paren> <assignment>

<right paren>
<value keyword>::= CAPTURES | DEFAULT | SAFE | RESETVAL |
<user extension>
<user extension>::= USER <colon> <user keyword>
<user keyword>::= <VHDL identifier>
<assignment>::= <assignment value> | <asterisk> | <minus sign>
<assignment value>::= <binary pattern> | <hex pattern> | <decimal
pattern> |
<mnemonic association>
<mnemonic association>::= [ PACKAGE <package hierarchy> <colon> ]
<mnemonic group name> <left paren> <mnemonic default> <right paren>
<mnemonic default>::= <mnemonic identifier> | <asterisk> | <minus
sign>
<type assignment>::= NOPI | NOPO | NOUPD | MON | PULSE0 |
PULSE1 | DELAYPO | NORETAIN | SHARED |
<user extension>
<reset assignment>::= PORRESET | TRSTRESET | TAPRESET | CHRESET |
DOMPOR | HIERRESET | <local reset assignment>
<local reset assignment>::= <reset type> <left paren> <reset ident>
<right paren>
<reset type::= RESETOUT | RESETIN
<reset ident>::= <VHDL identifier>
<domain assignment>::= <association type> <left paren> <associa-
tion name>
<right paren>
<association type>::= DOMAIN | DOMAIN_EXTERNAL | SEGMENT
<association name>::= <VHDL identifier>
518 B 2013 BSDL Syntax Revisions

B.2.8 Register Assembly Description

The register assembly description is used to define registers or segments of registers

by the concatenation of segments and/or fields in a specified order. Yes, this attri-
bute is complex. The syntax for this is as follows:

<register assembly description> ::= attribute REGISTER_ASSEMBLY of

<target> is <register assembly string> <semicolon>
<register assembly string>::= <quote> <register assembly list>
{ <comma> <register assembly list> } <quote>
<register assembly list>::= <reg or seg name>
<left paren> <register assembly elements> <right paren>
<register assembly elements>::= <left paren> <register element>
<right paren>
{ <comma> <left paren> <register element> <right paren> }
<register element> ::= <instance and options> | <field and options> |
<instance reference> |
<selected segment element> | <boundary instance> | <using
statement>
<instance and options> ::= <instance definition> { <field assign-
ments> }
<instance definition> ::= <instance ident> is
[ PACKAGE <package hierarchy> <colon> ] <reg or seg name>
<instance ident> ::= <segment ident> | <array ident>
<segment ident> ::= <VHDL identifier>
<array ident>::= ARRAY <array segment ident>
<left paren> <range> <right paren>
<array segment ident>::= <VHDL identifier>
<field assignments> ::= <field value assignment> | <field reset
assignment> |
<field domain assignment> | <field selection assignment>
<field value assignment> ::= [ <field ident> <colon> ] <value
assignment>
<field reset assignment> ::= [ <field ident> <colon> ] <reset
assignment>
<field domain assignment> ::= [ <field ident> <colon> ] <domain
assignment>
<field ident> ::= { <instance name> <period> } <field name>
<instance name> ::= <segment ident> | <array instances>
<array instances> ::= <array segment ident> <bit list>
<field and options>::= <field name> <field length> { <field options> }
<instance reference> ::= <segment ident> | <array instance>
<array instance> ::= <array segment ident> <left paren> <index>
<right paren>
<index> ::= <integer>
B.2 BSDL Syntax 519

<selected segment element> ::= SELECTMUX

<left paren> <selectable segment> <right paren>
{ <comma> <left paren> <selectable segment> <right paren> }
<field selection assignment>
<selectable segment> ::= <instance and options> | <instance
reference>
<field selection assignment> ::= <selection field> <selection
values>
[ <broadcast field> <broadcast values> ]
<selection field> ::= SELECTFIELD <left paren> <field reference>
<right paren>
<field reference> ::= { <instance reference> <period> } <field name>
<selection values> ::= SELECTVALUES <left paren> <segment
selection>
{ <segment selection> } <right paren>
<segment selection> ::= <left paren> <instance reference> <colon>
<field value>
{ <comma> <field value> } <right paren>
<field value> ::= <mnemonic identifier> | <binary pattern> |
<hex pattern> | <decimal pattern>
<broadcast field> ::= BROADCASTFIELD
<left paren> <field reference> <right paren>
<broadcast values> ::= BROADCASTVALUES
<left paren> <broadcast selection> { <broadcast selection> } <right
paren>
<broadcast selection> ::= <left paren> <instance reference>
{ <comma> <instance reference> } <colon> <field value>
{ <comma> <field value> } <right paren>
<boundary instance> ::= <segment ident> is
[ PACKAGE <package hierarchy> <colon> ] <boundary segment name>
<using statement>::= USING <package prefix>
<package prefix> ::= <package hierarchy> | <minus sign>
<package hierarchy>::= <user package name> { <period> <user pack-
age name> }

The <register assembly elements> are ordered with the first being closest to TDI
and the last being closest to TDO. If the <reg or seg name> is that of a standard
register (e.g., Device_ID) then the length must be what is specified in the standard
(e.g., 32) or what has been described before in a register access statement. In the
case of the Boundary register, it must match either the length given in <boundary
length stmt> or the minimum length given in an <assembled boundary length stmt>.
Otherwise, the specified length is used for a register that has a deferred length speci-
fication [*]. For user registers specified in a <package target> the length shall be the
sum of the lengths of the non-excludable segments in the <register assembly>.
520 B 2013 BSDL Syntax Revisions

In a <field and options> segment, the <field name> must be unique in any <reg-
ister assembly list>. Also, all <segment ident> and <array segment ident> elements
within a <register assembly list> must be unique within an entity or package. A <reg
or seg name> in an <instance definition> must be defined in a <register field list> or
<register assembly list> contained in the current entity or package, or in a package
the <package hierarchy> given by the most recent “USING” statement.
Between a SEGSEL (or SEGSTART5) element and a SEGMUX element that are
associated with the same segment <association name>, all register assembly ele-
ments listed are excludable as a unit.
Between a SELECTMUX element and a SELECTFIELD element, all register
assembly elements listed are members of a parallel group of segments, of which
only one is selected by the SELECTVALUES element to drive out towards
TDO. Optionally, following the selection elements there may be a
BROADCASTFIELD and BROADCASTVALUES element pair that enumerate
which of the parallel segments, receive TDI data in parallel for a given selection
value. In both cases, all segments mentioned between SELECTMUX and
SELECTFIELD must appear as selectable segments in the SELECTVALUE and
BROADCASTVALUE lists.
When multiple <array ident> statements have the same <array segment ident>
then all associated <range> specification must not have any duplicated indices, and
all indices must be present or implied within the total range specification.
The definition of the <field reference> register used in a SELECTFIELD or
BROADCASTFIELD element must have a RESETVAL specification, so the
selected segment upon reset is known.
When the register being assembled is the Boundary register, then it must be com-
posed only of instances of DOMCTRL, SEGSEL, SEGSTART or SEGMUX regis-
ter fields, which are defined in the standard package STD_1149_1_2013 (see
Sect. A.3), or defined <boundary segment name> elements defined found in a
Boundary_Segment attribute (see Sect. A.2.4). Note that any excludable segment in
a Boundary register must have a DOMCTRL and SEGSEL field associated with
that segment in the same register assembly list. This does not preclude having other
such controls in (say) the Init_Data register, but these are duplicates.6
Any excludable segments in the Init_Data register must be controlled by
DOMCTRL and SEGSEL fields in the Init_Data register. All excludable seg-
ments in a public TDR (standard or design-specific) must have DOMCTRL and
SEGSEL fields in that same TDR, or, in another public TDR that is not the
Boundary register. This means all such exclusion controls for public registers
must be visible (public).

5
SEGSEL represents a 1-bit register cell that directly precedes an excludable segment, In the case
where this bit exists in a different register, then SEGSTART, a zero-length segment indicator starts
the excludable segment. All must have the same <association name>.
6
In effect, the duplicate bits are OR-ed with those in the Boundary register to control the power/
exclusion mechanism. Thus, to exclude a segment, you should be aware of any duplicate bits else-
where and manage them along with the bits in the Boundary register.
B.2 BSDL Syntax 521

The <package hierarch> construct is used to point to a specific name (<mne-

monic group name>, <reg or seg name>, or <boundary segment name>) to remove
any ambiguity when there may be identical names a more than one hierarchical
level. A <using statement> is available to shorten name references by being a prefix
prepended to a name. The “USING (-)” form erases an existing prefix.
Note that the 2013 revision of BSDL can be used to describe an older compo-
nent, but since the concept of domains and excludable segments were not supported
before 2013, a register assembly for a pre-2013 component may not contain
DOMCTRL, SEGSEL, SEGSTART or SEGMUX fields. This is known from the
<component conformance> statement (see Sect. A.4 referring to a pre-2013 level of
conformance.

B.2.9 Register Constraints Description

The register constraints attribute allows the description of register contents that
should be avoided—for example, where two domain control cells that turn on power
to two domains should not be both turned on at the same time (see example in Sect.
11.4.22) because the hardware itself cannot support this. Here is the register con-
straints syntax:

<register constraints description> ::= attribute REGISTER_CONSTRAINTS

of <target> is <constraints string> <semicolon>
<constraints string>::= <quote> <constraints list>
{ <comma> <constraints list> } <quote>
<constraints list>::= <constraint domain>
<left paren> <constraint checks> <right paren>
<constraint domain> ::= <reg or seg name> | entity | package
<constraint checks>::= <left paren> <check expression> <right
paren>
<constraint severity> <information tag>
{ <comma> <left paren> <check expression> <right paren>
<constraint severity> <information tag> }
<constraint severity> ::= error | warning | info
<check expression> ::= <short expression> | <binary expr>
<short expression> ::= <nested expr> | <unary expr> |
<field reference> | <oper val>
<nested expr> ::= <left paren> <check expression> <right paren>
<unary expr> ::= <logical inv expr> | <bit-wise inv expr> | <one
hot expr>
<logical inv expr> ::= <logical inversion> <short expression>
<bit-wise inv expr> ::= <bit-wise inversion> <short expression>
<one hot expr> ::= <one hot> <nested expression>
<binary expr> ::= <short expression> <binary operator> <check
expression>
522 B 2013 BSDL Syntax Revisions

<binary operator> ::= <exponentiation> | <multiplication> | <divi-

sion> |
<remainder> | <addition> | <subtraction> | <right shift> |
<left shift> | <less than> | <greater than> | <equals> |
<less than or equal> | <greater than or equal> | <not equals> |
<bit-wise and> | <bit-wise xor> | <bit-wise or> |
<logical and> | <logical or>
<oper val> ::= <mnemonic pattern> | <binary pattern> | <hex pat-
tern> |
<decimal pattern>
<mnemonic pattern> ::= [ [ PACKAGE <package hierarchy> <colon> ]
<mnemonic group name> ]
<left brace> <mnemonic identifier> <right brace>

The logical expression formulation is a subset adopted from section Sect. 11.2 of
SystemVerilog [IEEE12a].
The definition of <target> is found in Sect. A.2.6. A <constraint domain> of
PACKAGE or ENTITY must match the type of <target>. The <field reference>
must be a previously defined register or register field, as provided by the standard
(e.g., Boundary or ECID) or by a register access, register fields or register assembly
definition. A <mnemonic pattern> must resolve to previously defined mnemonic
value given in a register mnemonics definition.
A <check expression> must contain at least one <field reference>. (For example,
the expression “2 < 3” does not meet this requirement.) The field length of a <field
reference> must be greater than zero. Operator meanings, precedence and symbols
are given in below in Table A.1. The logical value of zero if FALSE, and the logical
value of a non-zero number is TRUE. Note a binary number with ‘x’ bits is consid-
ered non-zero. Arithmetic operators do not operate on ‘x’ bits, only ‘1’ and ‘0’ bits
are allowed in operands.
Operators of higher precedence (that is, lower precedence number) are evaluated
before those of lower precedence. Operators of the same precedence are evaluated
left-to-right.

B.2.10 Register and Power Port Association Description

These two new optional attributes are described together since they share some
syntax definitions and rules of use. These attributes allow ports of an IC to have
associated information that may be quite helpful during test debugging or defect
diagnosis.

<register association description> ::= attribute REGISTER_ASSOCIATION

of <target> is <register association string> <semicolon>
<register association string>::= <quote> <register association
list>
B.2 BSDL Syntax 523

Table A.1 Constraint operator definitions

Precedence Operator token Operator Type (comments)
1 <logical inversion> ! Logical
<bit-wise inversion> ~ Bit-wise
<one hot> One_hot Logical result, true if exactly one
operand bit is ‘1’
(Binds to nested expression on its right)
2 <exponentiation> ** Arithmetic
3 <multiplication> * Arithmetic
<division> /
<remainder> %
4 <addition> + Arithmetic
<subtraction> −
5 <left shift> << Arithmetic (Right operand is the
<right shift> >> number of shifts)
6 <left than> < Arithmetic
<greater than> > (Result is logical)
<less than or equal> <=
<greater than or equal> =>
7 <equals> == Bit-wise (Result is logical)
<not equal> !=
8 <bit-wise and> & Bit-wise
9 <bit-wise xor> ^ Bit-wise
10 <bit-wise or> | Bit-wise
11 <logical and> && Logical
12 <logical or> || Logical

{ <comma> <register association list> } <quote>

<register association list>::= <reg field or instance> <colon>
<association list>
{ <association list> }
<reg field or instance> ::= <field or instance name>
[ <left paren> <index> <right paren> ]
<field or instance name> ::= <extended field name> | <segment ident> |
<array segment ident> | <TDR>
<association list> ::= <port list> | <info list> | <clock list> |
<user list> | <unit>
<port list> ::= port <port association list>
<port association list> ::= <left paren> <port ID>
{ <comma> <port ID> } <right paren>
<info list> ::= info <left paren> <information tag>
{ <comma> <information tag> } <right paren>
<clock list> ::= sysclock <left paren> <port ID>
{ <comma> <port ID> } <right paren>
<user list> ::= user <user list name>
<left paren> <single or multi list> <right paren>
524 B 2013 BSDL Syntax Revisions

<user list name> ::= <VHDL identifier>

<single or multi list> ::= <single word user list> | <multi-word
user list>
<single word user list> ::= <VHDL identifier> { <comma> <VHDL iden-
tifier> }
<multi-word user list> ::= <information tag> { <comma> <informa-
tion tag> }
<unit> ::= unit <left paren> <unit name> <unit definition> <right
paren>
<unit definition> ::= <left brace> <unit value> [ <unit scale> ]
[ <unit link> ] <right brace>
<unit name> ::= <VHDL identifier>
<unit value> ::= <hex pattern>
<unit scale> ::= <real>
<unit link> ::= <information tag>
<power port association description> ::= attribute
POWER_PORT_ASSOCIATION of <entity target> is
<power port association string> <semicolon>
<power port association string>::= <quote> <power port association
list>
{ <comma> <power port association list> } <quote>
<power port association list>::= <power port id> <colon> <port
association list>
<power port id> ::= <port ID>

Any field reference must be a previously defined register or register field, as

provided by the standard (e.g., Boundary or ECID) or by a register access, register
fields or register assembly definition. A <field or instance name> must appear only
once in a <register association list>. The value of an integer <index> associated
with a <field name> must be less than the <field length> of the register field (see
Sect. A.2.7). When an <index> is associated with a <array segment ident>, it must
be a valid index into the <range> of an <array ident> described in a Register_
Assembly attribute. An <index> can only be associated with a <power port id>
when that <port ID> was defined as a bit_vector and the index is a valid member of
the <range> of the <port ID>.
All <port ID> elements listed in a <port association list> must be previously
defined in a <logical port description> (see Sect. A.4), and shall appear only once in
that list.
An <association list> contains, within parenthesis, either a single entry which is
associated with all of the bits contained in a <reg field or instance>, or it must con-
tain a comma-separated list of entries with length equal to the number of bits con-
tained in the <reg field or instance>, associated with those bits in TDI-to-TDO order.
Any <port ID> in a <clock list> must have been identified as a system clock in a
SYSCLOCK_REQUIREMENTS attribute (see Sect. A.2.5). Each <user list name>
must be unique within a <register association list>.
B.3 The STD_1149_1_2013 Standard Package 525

A <unit> appearing in an <association list> allows the naming of a <unit value>,

which is a <hex pattern> of 22 characters as defined in section Sect. 4.11 of IEEE
Std 1451.0-2007 [IEEE07]. Any <unit link> supplied must be a valid file (file://…)
or Internet (http://…) URL locating a transducer electronic data sheet (TED) as
defined in IEEE Std 1451.
A <power port id> must be a <port ID> in the <logical port description> with a
<pin type> of POWER_POS, POWER_NEG, POWER_0 or VREF_IN.

B.3 The STD_1149_1_2013 Standard Package

The 2013 BSDL standard package has some changes from the previous (2001) ver-
sion. The package comes in two sections, the “package” and then the “package
body”. The 2013 package body contains cell descriptions that are very similar to the
previous package body so to conserve space, refer to the 2001 package body seen in
Sect. 2.6.1 for those cell descriptions.
The first section in the standard package is essentially a set of data and type dec-
larations. These were used to support VHDL compilers so that they could understand
data structures in BSDL. There are additions that come with the 2013 version. These
are shown next. Those statements that have been added by the 2013 revision are
commented at the right side of the page.

-- STD_1149_1_2013 BSDL Package and Package Body

--
-- source : IEEE Std 1149.1-2013, B.9
--
-- NOTE-Where figures from the standard are cited,
-- the suffix ‘c’ denotes a control cell, and ‘d’
-- denotes a data cell.
--
package STD_1149_1_2013 is
-- Give component conformance declaration.
attribute COMPONENT_CONFORMANCE : string;
-- Give pin mapping declarations
attribute PIN_MAP : string;
subtype PIN_MAP_STRING is string;
-- Give TAP control declarations
type CLOCK_LEVEL is (LOW, BOTH);
type CLOCK_INFO is record
FREQ : real;
LEVEL: CLOCK_LEVEL;
end record;
attribute TAP_SCAN_IN : boolean;
attribute TAP_SCAN_OUT : boolean;
526 B 2013 BSDL Syntax Revisions

attribute TAP_SCAN_CLOCK: CLOCK_INFO;

attribute TAP_SCAN_MODE : boolean;
attribute TAP_SCAN_RESET: boolean;
-- Give instruction register declarations
attribute INSTRUCTION_LENGTH : integer;
attribute INSTRUCTION_OPCODE : string;
attribute INSTRUCTION_CAPTURE : string;
attribute INSTRUCTION_PRIVATE : string;
-- Give ID and USER code declarations
type ID_BITS is ('0', '1', 'x', 'X');
type ID_STRING is array (31 downto θ) of ID_BITS;
attribute IDCODE_REGISTER : ID_STRING;
attribute USERCODE_REGISTER: ID_STRING;
-- Give register declarations
attribute REGISTER_ACCESS : string;
attribute REGISTER_MNEMONICS : string;
attribute REGISTER_FIELDS : string;
attribute REGISTER_ASSEMBLY : string;
attribute REGISTER_CONSTRAINTS : string;
attribute POWER_PORT_ASSOCIATION : string;
attribute REGISTER_ASSOCIATION : string;
-- Give boundary cell declarations
type BSCAN_INST is (EXTEST, SAMPLE, INTEST);
type CELL_TYPE is (INPUT, INTERNAL, CLOCK, OBSERVE_ONLY,
CONTROL, CONTROLR, OUTPUT2, OUTPUT3,
BIDIR_IN, BIDIR_OUT);
type CAP_DATA is (PI, PO, UPD, CAP, X, ZERO, ONE);
type CELL_DATA is record
CT : CELL_TYPE;
I : BSCAN_INST;
CD : CAP_DATA;
end record;
type CELL_INFO is array (positive range <>) of CELL_DATA;
-- Boundary cell deferred constants (see package body)
constant BC_0 : CELL_INFO;
constant BC_1 : CELL_INFO;
constant BC_2 : CELL_INFO;
constant BC_3 : CELL_INFO;
constant BC_4 : CELL_INFO;
constant BC_5 : CELL_INFO; -- BC_6 omitted in 2013
constant BC_7 : CELL_INFO;
constant BC_8 : CELL_INFO;
constant BC_9 : CELL_INFO;
constant BC_10 : CELL_INFO;
-- Boundary-scan register declarations
attribute BOUNDARY_LENGTH : integer;
B.3 The STD_1149_1_2013 Standard Package 527

attribute BOUNDARY_REGISTER : string;

attribute ASSEMBLED_BOUNDARY_LENGTH : array (0 to 1) of
integer; -- added 2013
attribute BOUNDARY_SEGMENT : string; -- added 2013
-- Miscellaneous
attribute PORT_GROUPING : string;
attribute RUNBIST_EXECUTION : string;
attribute INTEST_EXECUTION : string;
attribute SYSCLOCK_REQUIREMENTS : string; -- added 2013
subtype BSDL_EXTENSION is string;
attribute COMPLIANCE_PATTERNS : string;
attribute DESIGN_WARNING : string;
end STD_1149_1_2013; -- End of 1149.1-2013 Package

The standard package body follows here. The cell descriptions are substantially
unchanged from 2001 (see Sect. 2.6.1). These are omitted for brevity.

package body STD_1149_1_2013 is

--Standard boundary cells

… cell descriptions omitted …

… the next two attributes added at 2013 …

attribute REGISTER_MNEMONICS of STD_1149_1_2013:package

is
"STD_MUX(Include (1) <chain segment is included>,"&
"Exclude (0) <chain segment not included>),"&
"STD_POWER(On (1) <Domain is functionally on>, " &
" Off (0) <Domain is functionally off>), " &
"STD_DOMSET(Override (1) <Force domain ON>, " &
"Normal (0) <Domain in normal mode>) ";

attribute REGISTER_FIELDS of STD_1149_1_2013:package is

"DOMCTRL[1] ((DOMCTRL[1] IS (0) MON " &
" DEFAULT(STD_DOMSET(Normal)) " &
" RESETVAL(STD_DOMSET(Normal))) "&
-- A reset type must be specified where this
-- is instantiated
")," &
"SEGSEL[1] ((SEGSEL[1] IS (0) DELAYPO " &
" DEFAULT(STD_MUX(Exclude)) "&
" RESETVAL(STD_MUX(Exclude)) "&
-- A reset type must be specified where this
-- is instantiated
" CAPTURES(STD_POWER(-)) ))," &
"SEGMUX[0] ((SEGMUX [0] IS ()) )," &
"SEGSTART[0] ((SEGSTART [0] IS ()) )";
end STD_1149_1_2013; -- End of IEEE STD 1149.1-2013
-- Package Body
528 B 2013 BSDL Syntax Revisions

B.4 User Package Syntax

The syntax for a user package is expanded to account for nesting of IP packages and
register mnemonics, fields, assembly, constraints and association descriptions. The
syntax below has comment in the right sides of lines that are added by the 2013
revision. (These comments are not part of the description.)

<user package> ::= <user package stmt> <user package body>

<user package stmt>::= package <user package name> is

<standard use statement>
{ <extension declaration> }
{ <deferred constant> }
end <user package name> ;
<user package body>::= package body <user package name> is
<standard use statement>
{ <use statement> } --added 2013
{ <cell description constant> }
{ <register mnemonics description> } --added 2013
{ <register fields description> } --added 2013
{ <register constraints description> } --added 2013
{ <register association description> } --added 2013
{ <extension definition> } --added 2013
[ <design warning> ] --added 2013
end <user package name> ;

<user package name>::= <VHDL identifier>

<deferred constant>::= constant <cell name> : CELL_INFO;
<cell name>::= <VHDL identifier>
<cell description constant>::=
constant <cell name> : CELL_INFO := (
<capture descriptor list> ) ;
<cell name>::= <VHDL identifier>
<capture descriptor list>::= <capture descriptor>
{ , <capture descriptor> }
<capture descriptor>::= ( <cell context> ,
<capture instruction> , <data source> )
<cell context>::= INPUT | OUTPUT2 | OUTPUT3 |
INTERNAL | CONTROL | CONTROLR | CLOCK |
BIDIR_IN | BIDIR_OUT | OBSERVE_ONLY
<capture instruction>::= EXTEST | SAMPLE | INTEST
<data source>::= PI | PO | CAP | UPD | ZERO | ONE | X

The various register descriptions used above are defined in this Appendix. The
addition of a design warning inside a user package will allow IP providers to alert
their users to any special considerations their IP requires.
B.5 Modified 1149.6 Extention Attribute Syntax 529

B.5 Modified 1149.6 Extention Attribute Syntax

The 1149.6 extension contains syntax that defines 1149.6 attributes. This syntax
may appear in the extension area of an entity (chip) description, or in the extension
area of a user package. Note that the two extensions differ in that for an entity exten-
sion, the <AIO port link behavior description> syntax may not appear, and in a user
package extension, a <AIO optional pin behavior description> may not appear.
Both of these items appear in the following syntax description since they make use
of some common elements. Three of the five statements are identical to the 2003
version and the comments point to their definition in Sect. A.6.

<AIO Extension> ::=

<AIO component conformance statement> (see Sect. A.6)
[<AIO optional EXTEST_PULSE description>] (see Sect. A.6)
[<AIO optional EXTEST_TRAIN description>] (see Sect. A.6)
[<AIO optional pin behavior description>] (see Sect. A.5.1)
[<AIO port link behavior description>] (see Sect. A.5.2)

The value of a conformance identification has been expanded in 2015 to have

two values: STD_1149_6_2003 and STD_1149_6_2015. Note that when confor-
mance is claimed for the 2015 level, then the conformance attribute of the entity
BSDL must be STD_1149_1_2013 or later.
There is a restriction for Extest_Pulse descriptions that appear in a user package;
the clock specification refers to a time only, not a <port ID>, since ports are not
known at the package level.

B.5.1 Pin Behavior Description (Entity)

AIO Pin behavior at the entity level is described by an AIO_Pin_Behavior attribute.

The documentation of the AC parameters of a pin are given in Sect. A.5.3.
Note that a pin behavior description may reference “port links”, which are
described by a port link behavior description (see Sect. A.5.2) in a package refer-
enced in a BSDL use statement. Here is the syntax for pin behavior description.

<AIO optional pin behavior description> :: =

attribute AIO_Pin_Behavior of <entity target> is
<quote> <AC entity info list> <quote> <semicolon>
<AC entity info list> ::= <entity pin info> { <semicolon> <entity
pin info> }
<entity pin info> ::= <AC port list> <colon> [ <AC/DC select cell> ]
<AC parameters>
<AC port list> ::= <AC ports> { <comma> <AC ports> }
<AC ports> ::= <AC port> [ <input cell list> ]
530 B 2013 BSDL Syntax Revisions

<AC port> ::= <port name> | <subscripted port name > |

<ranged port name>
<subscripted port name> ::= <port name> <left paren> <integer> <right
paren>
<ranged port name> ::= <port name> <left paren> <range> <right paren>
<input cell list> ::= <left bracket> <cell number list> <right bracket>
<cell number list> ::= <cell reference> { <comma> <cell number> }
<cell reference> ::= [ <boundary segment name> <colon> ] <cell
number>
<AC/DC select cell> ::= AC_Select <equal> <cell reference>
<AC parameters> ::= <AC parameter list> | <AC port link list>

NOTE— The definition of <AC parameter list> is given in A.5.3.

<AC port link list> ::= [ PACKAGE <package hierarchy> <colon> ]
<port link reference list>
<port link reference list> ::= <port link reference>
{ <comma> <port link reference> }
<port link reference> ::= <port link name ref> [ <input threshold> ]

NOTE— The <input threshold> element is defined in A.5.3

<port link name ref> ::= <port link name> | <subscripted port link
name> |
<ranged port link name>
<subscripted port link name> ::= <port link name>
<left paren> <integer> <right paren>
<ranged port link name> ::= <port link name> <left paren>
<range> <right paren>
<port link name> ::= <VHDL identifier>

See discussion about Pin Behavior Description in Sect. 12.3.5.

B.5.2 Port Link Behavior Description (Package)

AIO Port Link behavior at the package level is described by an AIO_Port_Behavior

attribute. The documentation of the AC parameters of a port link is given in Sect.
A.5.3. Here is the syntax for port link behavior description.

<AIO port link behavior description> :: = attribute AIO_Port_

Behavior of
<package target> is <quote> <port link declaration list >
<AC package info list> <quote> <semicolon>
<port link declaration list>::=port_link_list <left paren> <port
link declaration>
{ <semicolon> <port link declaration> } <right paren> <semicolon>
<port link declaration> ::= <port links> <colon> <port link type>
<port dimension>
B.5 Modified 1149.6 Extention Attribute Syntax 531

<port links> ::= <port link name> { <comma> <port link name> }
<port link name> ::= <VHDL identifier>
<port link type> ::= in | buffer | out | inout
<AC package info list> ::= <package pin info>
{ <semicolon> <package pin info> }
<package pin info> ::= <port link list> <colon> <AC parameter list>

NOTE— The definition of <AC parameter list> is given in Sect. A.5.3.

<port link list> ::= <port link> { <comma> <port link> }

<port link> ::= <port link name> | <subscripted port link name> |
<ranged port link name>

NOTE – The definitions of <port link name>, <subscripted port link name>
and <ranged port link name> were given above in Sect. A.5.1.

See discussion about Port Behavior Description in Sect. 12.3.6.

B.5.3 AC Parameters Description

AC parameters document the characteristics of AC pin drivers or test receivers that

may be important to board test debugging and efficacy, and diagnostic processing.
In the pre-2015 years, we did not have this information in machine readable form
and if a test engineer was having trouble debugging a test, it may have been due to
a mismatch of AC parameters that he might have found out about by reading some
obscure data sheet. Now these are brought out into view in BSDL, and in principle,
some debugging can even be enhanced automatically, with software able to look at
drivers and attached receivers and see if any problematic AC parameter mismatches
are possible. This is even more important as we see more driver/receiver parameters
than are programmable—are they programmed to be compatible?
AC parameter syntax appears below. Note the numerous keywords—these are
explained in Sect. 12.3.2.

<AC parameter list> ::= [ <LP time constant> ] [ <HP time constant> ]
<voltage parameters> [No_pulse]
<voltage parameters> ::= <voltage parm> <voltage parm>
[ <voltage parm> <voltage parm> ]
<voltage parm> ::= <output VCM> | <output VPP> | <input threshold> |
<input hysteresis>
<LP time constant> ::= <LP key> <equal> <time constant>
<LP key> ::= LP_time | edge_detect_time
<HP time constant> ::= <HP key> <equal> <time constant> [ <cap spec> ]
[ <detection modifier> ]
<HP key> ::= HP_Time | coupling_time
<time constant> ::= <real>
<cap spec> ::= On_Chip | On_Chip_Programmable | On_Chip_AC |
On_Chip_AC_Programmable | <group on-chip>
532 B 2013 BSDL Syntax Revisions

<group on-chip> ::= <group keyword> <left paren> <group name>

<right paren>
<group keyword> ::= On_Chip_Bus_Programmable |
On_Chip_AC_Bus_Programmable
<detection modifier> ::= Detect_EXTEST_High | Detect_EXTEST_Low |
Detect_EXTEST_Both | Detect_EXTEST_Both_Grouped
<output VCM> ::= AIO_VCM <equal> <Volt choice>
<Volt choice> ::= <millivolts> | programmable | <group programmable>
<group programmable> ::= bus_programmable <left paren>
<group name> <right paren>
<output VPP> ::= AIO_VPP <equal> <Volt choice>
<input threshold> ::= AIO_VTH <equal> <VTH choice>
<VTH choice> ::= <millivolts> | <source pin> | programmable |
<group programmable> | AIO_VCM | external
<input hysteresis> ::= AIO_VHyst <equal> <Volt choice>
<millivolts> ::= <integer> | <negative integer>
<source pin> ::= <port_ID>
<group name> ::= <VHDL identifier>
References

[Agra88] “Test Generation for VLSI Chips”, V. D. Agrawal and S. C. Seth, IEEE Computer
Society Press, Los Alamitos CA, 1988
[Albe01] “A Practical Guide to Combining ICT and Boundary-Scan Testing”, A. Albee,
Proceedings, International Test Conference, Baltimore MD, pp 487–494, Oct 2001
[AMD91] “Am29030 and Am29035 Microprocessors User's Manual and Data Sheet”, Advanced
Micro Devices, Inc. 1991
[Avra87] “A VHSIC ETM-Bus Compatible Test and Maintenance Interface”, L. Avra,
Proceedings, International Test Conference, pp 964–971, Washington DC, 1987
[Ball89] “Board-Level Boundary-Scan: Regaining Observability with an Additional IC”,
W. D. Ballew and L. Streb, Proceedings, International Test Conference, pp 182–189,
Washington DC, Aug 1989
[Barr00] “End-to-End Testing for Boards and Systems Using Boundary-Scan”, R. Barr and
E. Wallace, Proceedings, International Test Conference, Atlantic City NJ, pp 585–
591, Oct 2000
[Been85] “Systematic and Structured Methods of Digital Board Testing”, F. P. M. Beenker,
Proceedings, International Test Conference, pp 380–385, Philadelphia, Nov 1985
[Blee93] “Boundary-Scan Test: A Practical Approach”, H. Bleeker, P. van den Eijnden and F.
de Jong, Kluwer Academic Publishers, Norwell MA, 1993
[Breu88] “A Test and Maintenance Controller for a Module Containing Testable Chips”, M. A.
Breuer and J. C. Lien, Proceedings, International Test Conference, Washington DC,
pp 502–513, 1988
[Bruc91] “Implementing 1149.1 on CMOS Microprocessors”, W. C. Bruce, M. G. Gallup,
G. Giles and T. Munns, Proceedings, International Test Conference, Nashville TN,
pp 879–886, Oct 1991
[Bull87] “Designing SMT Boards for In-Circuit Testability”, M. Bullock, Proceedings,
International Test Conference, pp 606–613, Washington DC, Sept 1987
[Bush84] “Measuring Thermal Rises Due to Digital Device Overdriving”, G. S. Bushanam
et al, Proceedings, International Test Conference, pp 400–407, Philadelphia PA. Oct
1984
[Cald92] “Is IEEE 1149.1 Boundary-Scan Cost Effective: A Simple Case Study”, B. Caldwell,
T. Langford, Proceedings, International Test Conference, pp 106–109, Baltimore
MD, Sept 1992
[Chil91] “Using Boundary-Scan Description Language in Design”, D. Chiles and J. DeJaco,
Proceedings, International Test Conference, pp 865–868, Nashville TN. Oct 1991
[Chun01] “AC-JTAG: Empowering JTAG Beyond Testing DC Nets”, S. Chung, S. Baeg,
Proceedings, International Test Conference, pp 30–37, Baltimore MD, Oct 2001

© Springer International Publishing Switzerland 2016 533

K.P. Parker, The Boundary-Scan Handbook, DOI 10.1007/978-3-319-01174-5
534 References

[Clar10] “Solutions for Undetected Shorts on IEEE 1149.1 Self-Monitoring Pins”, Clark,
C. J., Dubberke, D., Parker, K. P., Tuthill, B., Proceedings, International Test
Conference, Paper 19.1, Austin TX, Oct 2010
[Cogs02] “A Structured Graphical Tool for Analyzing Boundary-Scan Violations”,
M. Cogswell, S. Mardhani, K. Melocco and H. Arora, Proceedings, International
Test Conference, Baltimore MD, 755–762, Oct 2002
[Coom95] “Printed Circuits Handbook, 5th Edition”, C. F. Coombs, Editor, McGraw-Hill,
New York, 2001
[Covi92] “Boundary-Scan Testing with ATEs”, R. R. Covington, R. C. Goodwin, T. A. Reed,
Proceedings, ATE&I Conference, pp 32–37, Anaheim CA. Jan 1992
[Croo79] “Analog In-Circuit Component Measurements: Problems and Solutions”, D. T.
Crook, Hewlett-Packard Journal, vol 30, No. 3, March 1979
[Crou94] “Low Power Mode and IEEE 1149.1 Compliance: A Low Power Solution”, A. L.
Crouch, R. Ramus, C. Maunder, Proceedings, International Test Conference, pp 660–
669, Washington DC, Oct 1994
[Dahb89] “An Optimal Test Sequence for the JTAG Boundary-Scan Controller”, A. Dahbura,
M. U. Uyar and C. W. Yau, Proceedings, International Test Conference, Washington
DC, pp 55–62, Aug 1989
[DeJo91] “Testing the Integrity of the Boundary-Scan Test Infrastructure”, F. de Jong and F.
van der Heyden, Proceedings, International Test Conference, Nashville TN, pp 106–
112, Oct 1991
[DeJo00] “Power Pin Testing: Making the Test Coverage Complete”, F. de Jong and R. Schuttert,
Proceedings, International Test Conference, Atlantic City NJ, pp 575–584, Oct 2000
[DeJo01] “Testing and Programming Flash Memories on Assemblies During High Volume
Production”, F. de Jong, A. S. Biewenga, D. van Geest and T. F. Waayers, Proceedings,
International Test Conference, Baltimore MD, 470–479, Oct 2001
[Derv88] “Using Scan Technology for Debug and Diagnostics in a Workstation Environment”,
B. I. Dervisoglu, Proceedings, International Test Conference, Washington DC,
pp 976–986, 1988
[Dubb08] “Solving In-Circuit Defect Coverage Holes with a Novel Boundary-Scan
Application”, D. Dubberke, J. J. Grealish, B. van Dick, Proceedings, International
Test Conference, paper 11.2, Santa Clara, CA, Oct 2008
[EDIF91] “EDIF Test Technical Subcommittee Test Extension”, Version 2 0 32, EDIF Test
Technical Subcommittee, Oct 1991
[Eklo01] “Unsafe Board States During PC-Based Boundary-Scan Testing”, B. Eklow,
R. Sedmak and D. Singletary, Proceedings, International Test Conference, Baltimore
MD, pp 615–623, Oct 2001
[Eklo02] “IEEE P1149.6: A Boundary-Scan Standard for Advanced Digital Networks”,
B. Eklow, C. F. Barhart, K. P. Parker, Proceedings, International Test Conference,
pp 1056–1065, Baltimore MD, Oct 2002
[Eklo05] "An update on IEEE 1149.6 - successes and issues", B. Eklow, Proceedings,
International Test Conference, Austin TX, Nov 2005
[Fasa89] “ASIC Testing in a Board/System Environment”, F. P. Fasang, IEEE Custom
Integrated Circuits Conference, New York NY, pp 22.4.1–22.4.4, 1989
[Fout06] “Automation of IEEE 1149.6 Boundary Scan Synthesis in an ASIC Methodology”,
B. Foutz, V. Chickermane, B. Li, H. Linzer, G. Kunzelman, 15th Asian Test Symposium,
Fukuoka Japan, Nov 2006
[Gall90] “The Testability Features of the 68040”, M. Gallup et al, Proceedings, International
Test Conference, pp 749–757, Washington DC, Sept 1990
[Gree93] “Benefits of Boundary-Scan to In-Circuit Test”, D. A. Greene, Proceedings,
International Test Conference, p 263, Baltimore MD, Oct 1993
[Gols00] “Test and On-Line Debug Capabilities of IEEE Std 1149.1 in UltraSparc(TM)-III
Microprocessor”, F. Golshan, Proceedings, International Test Conference, Atlantic
City NJ, pp 141–150, Oct 2000
References 535

[Hall89] “Prototype Testing Simplified by Scannable Buffers and Latches”, A. Halliday,

G. Young and A. Crouch, Proceedings, International Test Conference, pp 174–181,
Washington DC, Aug 1989
[Hans89a] “The Impact of Boundary-Scan on Board Test Strategies”, P. Hansen, Proceedings,
ATE&I Conference, Boston MA. pp 35–40, June 1989
[Hans89b] “Testing Conventional Logic and Memory Clusters Using Boundary-Scan Devices as
Virtual ATE Channels”, P. Hansen, Proceedings, International Test Conference,
Washington DC, pp 166–173, Aug 1989
[Harr01] “Hierarchical Boundary-Scan: A Scan Chip-Set Solution”, S. Harrison, G. Noeninckx,
P. Horwood and P. Collins, Proceedings, International Test Conference, Baltimore
MD, pp 480–486, Oct 2001
[Hawk85] “Electrical Characteristics and Testing Considerations for Gate Oxide Shorts in
CMOS ICs”, C. F. Hawkins and J. M. Soden, Proceedings, International Test
Conference, pp 544–555, Philadelphia, Nov 1985
[Hill92] “Boundary-Scan Testing for Multichip Modules”, S. C. Hilla, Proceedings,
International Test Conference, pp 224–231, Baltimore MD, Sept 1992
[Hird02] “Test Coverage: What Does It Mean When a Board Test Passes?”, K. Hird, K. P.
Parker and B. Follis, Proceedings, International Test Conference, Baltimore MD,
1066–1074, Oct 2002
[Hewl85] “SAFEGUARD In-Circuit, a Description of HP's Safe Implementation of Digital
In-Circuit Test”, Product Note 3065-2, Hewlett-Packard Manufacturing Test Division,
Loveland CO. Sept 1985
[Huan97] “Analog Fault Diagnosis for Unpowered Circuit Boards”, J. L. Huang and K. T.
Cheng, Proceedings, International Test Conference, pp 640–648, Washington DC,
Nov 1997
[IEEE90] “IEEE Standard Test Access Port and Boundary-Scan Architecture”, IEEE Standard
1149.1–1990, IEEE Standards Board, 345 East 47th St. New York NY 10017, May
1990
[IEEE92] “Extended Digital Serial Subset”, Proposed IEEE Standard P1149.2/D0.2, IEEE
Standards Board, 345 East 47th St. New York NY 10017, Feb 1992
[IEEE93a] “IEEE Standard 1149.1 Draft Supplement”, IEEE Standard 1149.1a-1993, IEEE
Standards Board, 345 East 47thSt. New York NY 10017, 1993 (Now included in
[IEEE01])
[IEEE93b] “IEEE Standard VHDL Language Reference”, IEEE Standard 1076-1987, IEEE
Standards Board, 345 East 47th St. New York NY 10017, 1993
[IEEE94] “IEEE Standard 1149.1 Draft Supplement”, IEEE Standard 1149.1b-1994, IEEE
Standards Board, 345 East 47thSt. New York NY 10017, 1994 (Now included in
[IEEE01])
[IEEE95] “IEEE Standard Module Test and Maintenance (MTM) Bus Protocol”, IEEE
Standard 1149.5-1995, IEEE Standards Board, 345 East 47th St. New York NY
10017, 1995
[IEEE99] “IEEE Standard for a Mixed Signal Test Bus”, IEEE Standard 1149.4-1999, IEEE
Standards Board, 345 East 47th St. New York NY 10017, 1999
[IEEE01] “IEEE Standard Test Access Port and Boundary-Scan Architecture”, IEEE Standard
1149.1-2001, IEEE Standards Board, 345 East 47th St. New York NY 10017, 2001
[IEEE02] “IEEE Standard for In-System Configuration of Programmable Devices”, IEEE Standard
1532-2002, IEEE Standards Board, 345 East 47th St. New York NY 10017, 2003
[IEEE03] “IEEE Standard for Boundary-Scan Testing of Advanced Digital Networks”, IEEE
Standard 1149.6-2003, IEEE Standards Board, 345 East 47th St. New York NY
10017, 2003
[IEEE07] “IEEE Standard for a Smart Transducer Interface for Sensors and Actuators—
Common Functions, Communication Protocols, and Transducer Electronic Data
Sheet (TEDS) Formats”, IEEE Standard 1451.0-2007, IEEE-SA Standards Board, 3
Park Avenue, New York, NY 10016-5997, 2007
536 References

[IEEE12] “IEEE Standard for Boundary-Scan-Based Stimulus of Interconnections to Passive

and/or Active Components”, IEEE Standard 1149.8.1-2012, IEEE-SA Standards
Board, 3 Park Avenue, New York, NY 10016-5997, 2012
[IEEE12a] “IEEE Standard for SystemVerilog--Unified Hardware Design, Specification, and
Verification Language”, IEEE Standard 1800-2012, IEEE-SA Standards Board, 3
Park Avenue, New York, NY 10016-5997, 2012
[IEEE13] “IEEE Standard Test Access Port and Boundary-Scan Architecture”, IEEE Standard
1149.1–2013, IEEE Standards Board, 3 Park Avenue, New York NY 10016-5997,
2013
[IEEE15] “IEEE Standard for Boundary-Scan Testing of Advanced Digital Networks”, IEEE
Standard 1149.6-2015, IEEE Standards Board, 345 East 47th St. New York NY
10017, 2015
[Inte91] “Intel486 DX Microprocessor Data Book”, Intel Corporation, June 1991
[Jaco03] “The In-System Configuration Handbook: A Designer’s Guide to ISC”, N. Jacobson,
Kluwer Academic Publishers, Norwell MA, (to appear 2003)
[Jarw89] “A Unified Theory for Designing Optimal Test Generation and Diagnosis Algorithms
for Board Interconnects”, N. Jarwala and C. W. Yau, Proceedings, International Test
Conference, pp 71–77, Washington DC, Aug 1989
[Jarw94] “Designing ‘Dual Personality’ IEEE 1149.1 Compliant Multi-Chip Modules”,
N. Jarwala, Proceedings, International Test Conference, pp 446–455, Washington
DC, Oct 1994
[JEDE86] “Standard Manufacturer's Identification Code”, Joint Electron Device Engineering
Council, JEDEC Publication 106-A, Washington DC, 1986
[Jose93] “Test Features of the HP PA7100LC Processor”, D. D. Josephson, D. J. Dixon and
B. J. Arnold, Proceedings, International Test Conference, pp 764–772, Baltimore
MD, Oct 1993
[Kaji92] “Practical Test Generation with IEEE 1149.1 Boundary-Scan”, H. Kajitani, H. Sato,
H. Saito and S. Oresjo, Proceedings, ATE&I Conference, pp 10–17, Anaheim CA. Jan
1992
[Kaut74] “Testing of Faults in Wiring Interconnects”, W. K. Kautz, IEEE Transactions on
Computers, vol C-23, No. 4, pp 358–363, April 1974
[Ke96] “Backplane Interconnect Test in a Boundary-Scan Environment”, W. Ke, Proceedings,
International Test Conference, Washington DC, pp 717–724, Oct 1996
[Kim01] “Frequency Detection-Based Boundary-Scan Testing of AC Coupled Nets”, Y. Kim,
B. Lai, K. P. Parker, J. Rearick, Proceedings, International Test Conference, pp 46–53,
Baltimore MD, Oct 2001
[Kris02] “Improved Digital I/O Ports Enhance Testability of Interconnections”, A. Kristof,
Proceedings, International Test Conference, Baltimore MD, 763–772, Oct 2002
[Lage89] “Testing Multiple Power Connections with Boundary-Scan”, D. van de Lagemaat,
Proceedings, European Test Conference, pp 127–130, Paris Fr., April 1989
[Lang93] “Utilizing Boundary-Scan to Implement BIST”, T. Langford, Proceedings,
International Test Conference, pp 167–173, Baltimore MD, Oct 1993
[Lavo00] “A Good Excuse for Reuse: 'Open' TAP Controller Design”, D. Lavo, Proceedings,
International Test Conference, Atlantic City NJ, pp 1090–1099, Oct 2000
[Lefe90] “Functional Test and Diagnosis: A Proposed JTAG Sample Mode Scan Tester”, M. F.
Lefebvre, Proceedings, International Test Conference, pp 294–303, Washington DC,
Sept 1990
[Lofs96a] “A Demonstration IC for the P1149.4 Mixed-Signal Test Standard”, K. Lofstrom,
Proceedings, International Test Conference, pp 92–98, Washington DC, Oct 1996
[Lofs96b] “Early Capture for Boundary-Scan Timing Measurements”, K. Lofstrom,
Proceedings, International Test Conference, pp 417–422, Washington DC, Oct 1996
[Liu91] “Testing and Diagnosis of Analog Circuits and Systems”, R. Liu, Van Nostrand
Reinhold, New York, 1991
References 537

[Maun87] “Boundary-Scan — A Framework for Structured Design for Test”, C. M. Maunder

and F. P. M. Beenker, Proceedings, International Test Conference, pp 714–723,
Washington DC, Sept 1987
[Maun90] “The Test Access Port and Boundary-Scan Architecture”, C. M. Maunder and R. E.
Tulloss, IEEE Computer Society Press, Los Alamitos CA, Sept 1990
[McDe98a] “Limited Access Testing: Ability and Requirements”, J. McDermid, Proceedings,
NEPCON 1998, Anaheim CA, Feb 1998
[McDe98b] “Solving Limited Access Constraints in ICT”, J. McDermid, Electronics Engineer,
July 1998
[McDe98c] “Limited Access Testing: 1149.4 Instrumentation and Methods”, J. McDermid,
Proceedings, International Test Conference, Washington DC, Oct 1998
[Milo95] “Success with Boundary-Scan, A Case Study”, P. Milo, Evaluation Engineering,
pp 72–74, Feb 1995
[Muri90] “Integrating Boundary-Scan Test into an ASIC Design Flow”, M. Muris, Proceedings,
International Test Conference, pp 472–477, Washington DC, Sept 1990
[Muri93] “Using Boundary-Scan to Test Random Access Memory Clusters”, M. Muris and
A. Biewenga, Proceedings, International Test Conference, pp 174–179, Baltimore
MD, Oct 1993
[Nade95] “A New Hardware Fault Insertion Scheme for System Diagnostics Verification”,
B. Nadeau-Dostie, H. Hulvershorn and S. M. I. Adham, Proceedings, International
Test Conference, pp 994–1002, Washington DC, Oct 1995
[Nadi77] “Signature Analysis - Concepts, Examples and Guidelines”, H. J. Nadig, Hewlett-
Packard Journal, pp 15–21, May 1977
[Norr08] “Augmenting Boundary-Scan Tests for Enhanced Defect Coverage”, D. Norrgard
and K.P. Parker, Proceedings International Test Conference, paper 11.3, Oct 2008
[Nuri97a] “The Trend of Technology and Standardization in Boundary-Scan Test Technology”,
K. Nuriya, K. Hirayama, K. P. Parker, and M. Kawai, Journal of Japan Institute for
Interconnecting and Packaging Electronic Circuits, Vol. 12, No. 1, pp 4–5, Jan 1997
(In Japanese)
[Nuri97b] “Moving Towards 100% Manufacturing Defect Coverage for Mixed-Signal Boards”,
K. Nuriya, A. Kukutsu, A. Matsuzawa, K. Hirayama, and K. P. Parker, Nikkei
Electronics No. 685, pp 183–198, March 1997 [In Japanese]
[Oakl00] “Considerations for Implementing IEEE 1149.1 on System-on-a-Chip Integrated
Circuits”, S. Oakland, Proceedings, International Test Conference, Atlantic City NJ,
pp 628–637, Oct 2000
[Ores92] “Board Test Issues when Implementing Boundary-Scan IEEE 1149.1”, S. Oresjo and
J. Stoltman, Proceedings, ATE&I Conference, pp 207–213, Anaheim CA. Jan 1992
[Osse99] “The 1149.4 Mixed-Signal Test Bus”, A. Osseiran Ed., Kluwer Academic Publishers,
Norwell MA, 1999
[Park87] “Integrating Design and Test: Using CAE Tools for ATE Programming”, K. P. Parker,
IEEE Computer Society Press, Los Alamitos CA, 1987
[Park89] “The Impact of Boundary-Scan on Board Test”, K. P. Parker, IEEE Design and Test
of Computers, vol 6, pp 18–30, August 1989
[Park90a] “Production Board Testing in a Boundary-Scan Environment”, K. P. Parker,
Proceedings, ATE&I Conference, Anaheim CA. pp 11–18, Jan 1990
[Park90b] “A Language for Describing Boundary-Scan Devices”, K. P. Parker and S. Oresjo,
Proceedings, International Test Conference, pp 222–234, Washington DC, Sept 1990
[Park91] “A Language for Describing Boundary-Scan Devices”, K. P. Parker and S. Oresjo,
Journal of Electronic Testing; Theory and Applications, vol 2, no. 1, pp 43–75,
March 1991
[Park93] “Structure and Metrology for an Analog Testability Bus”, K. P. Parker, J. E.
McDermid, S. Oresjo, Proceedings, International Test Conference, pp 309–322,
Baltimore MD, Oct 1993
538 References

[Park97] “Design, Fabrication and Use of Mixed-Signal IC Testability Structures”, K. P.

Parker, J. E. McDermid, R. A. Browen, K. Nuria, K. Hirayama, A. Matsuzawa,
Proceedings, International Test Conference, pp 489–498, Washington DC, Nov 1997
[Park00] “System Issues with Boundary-Scan Board Test”, K. P. Parker, Proceedings,
International Test Conference, pp 724–728, Atlantic City NJ, Oct 2000
[Park03] "Defect Coverage of Boundary-Scan Tests: What does it mean when a Boundary-
Scan Test Passes?", Parker, K. P., Proceedings, International Test Conference,
Charlotte NC, Sep 2003
[Park04] “A New Probing Technique for High-Speed/High-Density Printed Circuit Boards”,
Parker, K. P., Proceedings, International Test Conference, paper 13.1, Charlotte NC,
Oct 2004
[Park05] "The Effects of Defects on High-Speed Boards", Parker, K. P., Proceedings,
International Test Conference, Austin TX, Nov 2005
[Park05a] “Bead Probes in Practice”, Parker, K. P., Proceedings, International Test Conference,
Austin TX, Nov 2005
[Park08] "Boundary-Scan Testing of Power/Ground Pins", Parker, K. P. and Jacobson, N. G.,
Proceedings, International Test Conference, Santa Clara CA, Oct 2008
[Park10] “Surviving State Disruptions Caused by Test: the “Lobotomy Problem”, Parker,
K. P., Proceedings, International Test Conference, paper 19.2, Austin TX, Oct 2010
[Park11] “Surviving State Disruptions Caused by Test: A Case Study”, Parker, K. P.,
Kameyama, S., Dubberke, D., Proceedings, International Test Conference, Paper 5.2,
Anaheim CA, Sept 2011
[Park12] “Capacitive Sensing Testability in Complex Memory Devices”, Parker, K. P.,
Proceedings, International Test Conference, Paper 13.1, Anaheim CA, Nov 2012
[Poss91] “A Design-For-Testability Architecture for Multichip Modules”, K. E. Posse,
Proceedings, International Test Conference, pp 113–121, Nashville TN, Oct 1991
[Pyro95] “Implementing 1149.1 in the PowerPCTM RISC Microprocessor Family”, C. Pyron
and W. C. Bruce, Proceedings, International Test Conference, pp 844–850,
Washington DC, Oct 1995
[Raym95] “Algorithmic Extraction of BSDL from 1149.1-Compliant Sample ICs”, D. W.
Raymond, D. E. Wedge, P. J. Stringer, H. W. Ng, S. T. Jennings, C. T. Pynn, W. Soule,
Proceedings, International Test Conference, pp 561–568, Washington DC, Oct 1995
[Reed95] “Improving Board and System Test: A Proposal to Integrate Boundary-Scan and
IDDQ”, D. Reed, J. Doege and A. Rubio, Proceedings, International Test Conference,
pp 577–585, Washington DC, Oct 1995
[Robi83] “Investigation of Potential Damage Resulting from Digital In-Circuit Testing”,
R. Robinson, Proceedings, ATE East Conference, Boston MA. Jan 1983
[Robi90] “Interconnect Testing of Boards with Partial Boundary-Scan”, G. D Robinson, J. G.
Deshayes, Proceedings, International Test Conference, pp 572–581, Washington DC,
Sept 1990
[Robi93a] “Technology-Independent Boundary-Scan Synthesis (Design Flow Issues)”, M. F.
Robinson, Proceedings, European Design Automation Conference, Hamburg
Germany, Sept 1993
[Robi93b] “Technology-Independent Boundary-Scan Synthesis (Technology and Physical
Issues)”, M. F. Robinson, F. Mailhot and J. Konsevich, Proceedings, International
Test Conference, pp 157–166, Baltimore MD, Oct 1993
[Shar92] “Test Generation for Structural Testing with Boundary-Scan”, R. Sharma,
Proceedings, ATE&I Conference, pp 194–205, Anaheim CA. Jan 1992
[Sing97] “A Symbolic Simulation-Based ANSI/IEEE Std 1149.1 Compliance Checker and
BSDL Generator”, H. Singh, G. Patankar, J. Beausang, Proceedings, International
Test Conference, pp 256–264, Washington DC, Nov 1997
[Sobo82] “The Effects of Backdriving Digital Integrated Circuits During In-Circuit Testing”,
L. J. Sobotka, Proceedings, International Test Conference, pp 269–286, Philadelphia
PA. Oct 1982
References 539

[Stan02] “An Implementation of IEEE 1149.1 to Avoid Timing Violations and Other Practical
In-compliance Improvements”, D. Stang and R. Dandapani, Proceedings,
International Test Conference, Baltimore MD, 746–753, Oct 2002
[Sunt95] “The P1149.4 Mixed-Signal Test Bus: Costs and Benefits”, Proceedings, International
Test Conference, pp 444–450, Washington DC, Oct 1995
[Sunt96] “Cost/benefit Analysis of the P1149.4 Mixed-Signal Test Bus”, S. Sunter, IEEE
Proceedings, Circuits, Devices, and Systems, December 1996, pp 393–398.
[Sunt01] “A General Purpose 1149.4 IC with HF Analog Test Capabilities”, S. Sunter,
K. Filliter, J. Woo, P. McHugh, Proceedings, International Test Conference, Baltimore
MD, Oct. 2001, pp 38–45
[Sunt02] “Complete, Contactless I/O Testing - Reaching the Boundary in Minimizing Digital
IC Testing Cost”, S. Sunter, B. Nadeau-Dostie, Proceedings, International Test
Conference, Baltimore MD, Oct 2002
[Sunt09] "Testing Bridges to Nowhere - Combining Boundary-Scan and Capacitive Sensing",
Sunter, S. and Parker, K. P., Proceedings, International Test Conference, Austin TX,
Nov 2009
[Swee88] “JTAG Boundary-Scan: Diagnosing Module Level Functional Failures”, J. Sweeney,
National Communications Conference, 1988, pp 1801–1804
[Swen86] “Thermal Analysis of Backdriven Output Transistors”, R. L. Swent and M. J. Ward,
Proceedings, International Test Conference, pp 295–303, Washington DC, Sept 1986
[Tege96] “Opens Board Test Coverage: When is 99% Really 40%?”, M. V. Tegethoff, K. P.
Parker and K. Lee, Proceedings, International Test Conference, pp 333–339,
Washington DC, Oct 1996
[Tell52] “A General Network Theorem with Applications”, B. D. H. Tellegen, Phillips
Research Report No. 7, pp 259–269, 1952
[Texa90] “ASSET Diagnostic System Overview”, (Literature SATT113), Texas Instruments,
Inc., 1990
[Texa91a] “54BCT8244/74BCT8244 Octal Buffer with Boundary-Scan”, Texas Instruments,
Inc., 1991
[Texa91b] “54BCT8374/74BCT8374 Octal D Flip-Flop with Boundary-Scan”, Texas
Instruments, Inc., 1991
[That93] “Towards a Test Standard for Board and System Level Mixed-Signal Interconnects”,
C. W. Thatcher and R. E. Tulloss, Proceedings, International Test Conference,
pp 300–308, Baltimore MD, Oct 1993
[USP93] “Powered Testing of Mixed Conventional/Boundary-Scan Logic”, United States
Patent 5,260,649, Nov 1993
[Verm02] “IEEE 1149.1-Compliant Access Architecture for Multiple Core Debug on Digital
System Chips”, B. Vermeulen, T. Waayers, S. Bakker, Proceedings, International
Test Conference, pp 55–63, Baltimore MD, Oct 2002
[Vinn98] “Analog and Mixed-Signal Test”, B. Vinnakota, Editor, Prentice Hall, Upper Saddle
River, NJ, 1998
[Wagn87] “Interconnect Testing with Boundary-Scan”, P. T. Wagner, Proceedings, International
Test Conference, pp 52–57, Washington DC, Sept 1987
[Wagn88] “Design for Testability of Mixed-Signal Integrated Circuits”, K. D. Wagner and T. W.
Williams, Proceedings, International Test Conference, pp 823–828, Washington DC,
Oct 1988
[Wagn91] “Enhancing Board Functional Self-Test by Concurrent Sampling”, K. D. Wagner and
T. W. Williams, Proceedings, International Test Conference, pp 633–640, Nashville
TN, Oct 1991
[Whet90] “Event Qualification: a Gateway to At-Speed System Testing”, L. Whetsel,
Proceedings, International Test Conference, pp 135–141, Washington DC, Sept 1990
[Whet92] “A Proposed Method of Accessing 1149.1 in a Backplane Environment”, L. Whetsel,
Proceedings, International Test Conference, pp 206–216, Baltimore MD, Sept 1992
540 References

[Whet95] “Improved Boundary Scan Design”, L. Whetsel, Proceedings, International Test

Conference, pp 851–860, Washington DC, Oct 1995
[Whet97] “An IEEE 1149.1 Based Test Access Architecture for ICs with Embedded Cores”,
L. Whetsel, Proceedings, International Test Conference, pp 69–78, Washington DC,
Nov 1997
[Wibl99] “Design a Production and Test Strategy for PLD-based PCBs”, K. Wible, Test and
Measurement World, pp 37–44, March 1999
[Will83] “Design for Testability — A Survey”, T. W. Williams and K. P. Parker, Proceedings
of the IEEE, vol. 71, No. 1, Jan 1983
[Xili90] “XC 4000 Logic Cell Array Family”, Xilinx Inc. 1990
[Xili92] “Boundary-Scan Emulator for XC 3000”, Application Note XAPP-007.0, Xilinx Inc.
1992
[Xili98] “The Programmable Logic Data Book”, Xilinx Inc, 1998
[Yau89] “A New Framework for Analyzing Test Generation and Diagnosis Algorithms for
Wiring Interconnects”, C. W. Yau and N. Jarwala, Proceedings, International Test
Conference, pp 63–70, Washington DC, Aug 1989
Index

A AT2, 233, 235–237

ABM. See Analog boundary module (ABM)
AC/DC selection cells, 286–287, 305, 312,
316, 317
AC EXTEST, 269, 283, 284, 287, 290, 298,
301, 303, 306, 459
AC EXTEST instruction
EXTEST_PULSE, 283, 284
EXTEST_TRAIN, 283, 284
AC EXTEST working group, 269
AC parameter description, 461–462, 465
AC pins
defined, 281
drivers, 283–287
test facilities, 282–288
AC test mode, 282, 298, 303
Addressable shadow port, 200
Advanced I/O
AC pins, 282–289, 315–318
BSDL example, 423
DC pins, 281–283, 287, 312
defects, 288–292, 300, 318–320
definition, 280
example, 270, 273, 274, 277, 279, 280
inter-IC communication, 270–275
problem, 270–280
testing, 269–320
Agilent HDMP-2689, 45, 377
Aliasing, 131–134, 176
Ambiguity Class, 221, 223
Am29035, 163
Analog boundary module (ABM), 231, 232, 234,
242–250, 253, 254, 257, 262, 376
Analog boundary-scan, 203, 227–267
Analog test access port (ATAP)
AT1, 233, 236, 237
AT1N, 233, 256
AT2N, 233, 256
Analog test bus
AB1, 234
AB2, 234
AB1N, 234
AB2N, 234
Anti-aliasing PTV, 134
Application specific integrated circuit (ASIC),
46, 118–120, 151
ATAP. See Analog test access port (ATAP)
ATE. See Automatic test equipment (ATE)
ATPG. See Automatic test program generation
(ATPG)
AT&T 479AA, 195
Automatic test equipment (ATE), 4, 5, 8, 15, 17,
32, 40, 45, 49, 52, 53, 99, 117–120,
122, 125, 130, 131, 141–143, 147,
148, 156, 164, 167, 172, 178, 179,
196, 208–212, 215, 218, 226–228,
250, 251, 256, 265, 335, 340, 341, 436
Automatic test program generation (ATPG),
93, 97, 119, 146
B
Ball-grid array (BGA), 65, 133, 163, 169, 171,
224, 225
Basic test algorithm, 115–116, 120, 122, 129,
130, 353
BILBO. See Built-in logic block
obser(BILBO)
Blind interrogation, 35, 199
Boundary register, 4, 50, 112, 151, 173, 231,
282, 330, 347, 382, 456

© Springer International Publishing Switzerland 2016 541

K.P. Parker, The Boundary-Scan Handbook, DOI 10.1007/978-3-319-01174-5
542 Index

Boundary register cell self-monitoring output, 89, 101, 182, 239,

ABM, 231, 234, 242–247 310, 311, 357
abstraction of, 90, 91 shift in, 23, 168, 305
AC_1, 306, 309, 310, 315, 466 shift out, 23, 338
AC_2, 306, 309, 310, 466 signal inversion, 25
AC_7, 306, 307, 309, 310 single-cell bidirectional, 182, 331
AC_8, 306, 308–310 ST_10, 357
AC_9, 308–310 test receiver, 304
AC_10, 309, 311, 466, 467 three-cell bidirectional, 359
AC_40, 460, 466, 467 two-cell bidirectional, 182, 245
AC_41, 460, 466, 467 Boundary-scan description language (BSDL)
AC_SelU, 305, 309, 310, 315, 466 attribute (see Boundary-scan description
AC_SelX, 305, 309, 310, 466 language (BSDL) attribute)
BC_0, 86, 87 automated creation, 201
BC_1, 73, 80, 81, 84, 86, 87, 90, 92–93, boundary-scan register descriptions
101, 106, 168 boundary register assembly, 412–486
BC_2, 81, 86, 309, 310 fixed boundary register description,
BC_3, 86, 88 409–410
BC_4, 86, 88, 460, 466 segmented boundary register
BC_5, 86, 88, 96, 97, 184 description, 410–412
BC_6, 86, 88, 106 cell description constants, 89–92
BC_7, 86, 89, 309, 310, 331, 409 certifying, 187
BC_8, 86, 89, 92, 99–102, 306, 309, 310, 351 comment, 49, 58–60, 89, 105, 315, 404
BC_9, 86, 89, 92, 101, 181, 308–310 component conformance, 64–65, 83, 85, 105
BC_10, 86, 89, 92, 99–101, 106, 308, 309, damaged by electronic mail, 60
311, 356–358 design warnings, 61, 78, 84, 87, 106
BC_99, 92 device package pin mapping, 61, 65–66, 313
bidir, 80 entity, 59, 480–486
bidir_in, 91, 92 extensions, 61, 64, 77, 84, 87, 104, 106,
bidir_out, 91, 92 304–318, 459, 460, 466
capture data, 90, 91, 102, 114, 124, 180, extensions for 1149., 304–318
437, 438, 450 generic parameter, 58, 61–62, 65, 66, 105, 312
cell count, 23, 79, 99, 182 grouped port identification, 61, 66–67, 83,
clock, 41–42 314
constant “0/1” capture, 70, 102, 287 identifier, 58, 61, 62, 65, 105, 403, 415–417
control, 30, 39, 42 IEEE version, 50, 51, 64, 107
controlr, 74, 411–413 information tag, 404, 415, 416, 418, 432, 433
DBM, 31, 231, 247–248 initial (1990) version, 50
flawed design, 25 instruction register description, 61, 69–70, 314
general design, 53 INTEST execution description, 76–77
hardware fault insertion, 167–168 ISC algorithms, 322
input, 25, 27, 93 linkage, 62, 63, 66, 75, 83, 312
internal, 26, 29, 32 logical port, 61–63, 66, 312, 405
internal cell, 26, 32, 90, 92, 94, 102, 286, mnemonic identifiers, 403, 415–417
305, 316 numeric literals, 403
logical symbol, 27, 28, 41 pad-to-pin mapping, 57
merged cells, 78–81 PHYSICAL_PIN_MAP, 61, 62, 65, 83,
observe_only, 74, 86, 88, 460 312, 313, 407, 481, 485
optimizing, 28–29 pin description, 62–63
output2, 80, 88 PIN_MAP, 61, 62, 65, 83, 85, 312, 313,
output3, 81 407, 481, 485
parallel in, 20, 23, 91, 120 port types, 66, 404–407
parallel out, 23, 37, 91, 92, 94, 182, 334, 420 power port association description,
reversible cell, 88, 92 433–434
Index
pre-defined constants, 85
prefix identifiers, 403
register assembly description, 407, 410,
412, 421, 424–431
register association description, 433–434
register constraint description, 431–433
register fields description, 416–425, 489
register mnemonics description, 415–417
2013 revisions, 57, 377
RUNBIST execution description, 76
safe bit, 81
scope, 51–57
standard use statement, 61, 63–64, 105,
309, 405, 406
STD_1149_1_2013 standard package, 405
string, 58, 59
structure, 57–60
subset and standard practice of VHDL, 50, 57
system clock requirements attribute, 414
syntax, 505–532
TAP port identification, 67–68, 315
to/from synthesis systems, 57
type CELL_INFO, 86, 89
use as test driver, 52
user defined boundary cells, 101–104
user defined package, 64, 85, 102, 104, 105
user extensions, 77
user package syntax (2013), 461
use statements, 58, 63–64, 73, 85, 104–106,
181, 309, 312, 315, 402, 405, 406,
456, 464, 481
verification, 186, 187
verification test, 186, 187
version control, 107
Version 0.0 parser, 107
VHDL package, 58, 63, 85, 181, 304
VHDL package body, 58
writing, 53, 105–107
Boundary-scan description language (BSDL)
attribute
BOUNDARY_LENGTH, 72, 73, 80, 84,
86, 314, 409
BOUNDARY_REGISTER, 73, 79, 80, 84,
86, 91, 116, 120, 181, 186, 314, 409
BSDL_EXTENSION, 77, 87, 104, 310, 466
COMPLIANCE_PATTERNS, 68, 87
COMPONENT_CONFORMANCE, 64,
83, 85, 310, 313, 315, 481, 485
DESIGN_WARNING, 78, 87, 106
IDCODE_REGISTER, 71, 86, 184, 314
INSTRUCTION_CAPTURE, 69, 70, 84,
86, 106, 112, 124, 179, 314
INSTRUCTION_LENGTH, 69, 70, 83, 86,
105, 314
543
INSTRUCTION_OPCODE, 69–71, 83, 86,
105, 314
INSTRUCTION_PRIVATE, 69, 70, 72, 86,
106
INTEST_EXECUTION, 77, 87
PIN_MAP, 65, 83, 85, 313, 407, 481, 485
PORT_GROUPING, 66, 87, 160, 314, 481
REGISTER_ACCESS, 71, 72, 76, 84, 86,
106, 314, 421
RUNBIST_EXECUTION, 76, 87
TAP_SCAN_CLOCK, 67, 83, 86, 314
TAP_SCAN_IN, 67, 83, 86, 314
TAP_SCAN_MODE, 67, 83, 86, 314
TAP_SCAN_OUT, 67, 68, 83, 86, 314
TAP_SCAN_RESET, 67, 86
USERCODE_REGISTER, 71, 84, 86
Boundary-Scan master, 15, 16, 190, 195–197
Buffer. See Boundary-scan description
language (BSDL), logical port
Built-in logic block observer (BILBO), 172
Bus, 9, 10, 39, 42, 48, 62, 63, 135, 136, 138,
139, 151, 162, 188, 189, 196, 200,
208, 227, 234, 237–242, 246, 250,
251, 256, 258, 261, 263, 266,
270–272, 274–276, 351, 383,
461–463, 465, 468, 489
single-ended, 271, 276
Bypass register, 12, 22, 31, 34, 40–42, 52,
112, 125, 162, 186, 199, 234, 252,
336, 407
capture bit, 125
C
Capture flip-flop (CAP), 23, 27, 28, 36, 37, 78,
86, 90, 91, 93, 94, 102, 112, 152, 153,
167, 184, 186, 303, 353, 358, 419
Chains
analog busing, 234
broken, 124, 290, 397
chain ordering, 190
configurations, 33, 187–190
conjoined, 33, 123, 188, 189
dynamically reconfigurable, 188
extra shift stages (pad bits), 197
integrity, 22, 124–126, 143, 173, 201
linked, 123, 188, 197
multidrop system, 198–200
multiple simple, 33, 123
simple, 32, 33, 123, 124, 187, 188,
190–192, 196–198, 236
testing, 123–145
Chip-on-board (COB), 171, 225
Chip-scale packaging, 225
544
Common mode noise, 66, 257, 273
Comparator, 292, 293, 295, 296, 298–300
Complex programmable logic device (CPLD),
118, 164, 201, 334
Compliance enable pins, 43, 51, 56, 68, 69,
75, 105, 117, 194, 195
Compliance limit
current, 206, 207
voltage, 206, 207
Concurrent programming, 322, 338–340
Confounding, 131–134
Counting sequence, 127, 131, 133, 134, 142
CPLD. See Complex programmable logic
device (CPLD)
Crosstalk, 263, 295
D 34–36, 52, 70
Data register
boundary register, 22
bypass, 22, 34
capture data, 20, 90, 91, 437, 450
device identification, 22
dynamic data register, 385, 397–401
ECID, 23
halt shifting, 15
Init_data, 384, 392, 394–395, 397, 400,
415, 416, 424–427, 432, 433, 441,
452, 453, 456–458, 469, 471, 473,
478, 481, 486, 488, 489
init_status
busy/done bit, 395
pass/fail bit, 123
mode of operation, 12
parallel hold latches, 20
reset selection
reset-control bit, 396
reset-enable bit, 396
reset-hold bit, 396, 397
segmented data register, 400
shift portion, 17, 112
shift ripple, 18
target register, 112, 113
TMP_status
bypass-escape bit, 386, 392, 395, 396
TMP-status bit, 392, 395, 396, 417
toggle_control, 354, 358, 366
user-defined, 22, 42, 72, 106, 429
DBM. See Digital boundary module (DBM)
DC pins, 281–283, 287, 312, 350
DC test mode, 282
Defects
detectable with 1149.6, 290
masking, 421
Index
missing capacitor, 290, 291
model, 110, 148, 288–291
open circuit, 292
open solder joint, 291
shorted capacitor, 319, 458–459
shorted driver, 132, 133, 291
shorted receiver, 459
Designated driver, 130–132, 134–136, 139
Design for testability (DFT)
board level, 187–198, 263, 319, 375
built-in logic block observer, 172
device programming, 14, 31, 335, 341
integrated circuit level, 173–187, 263, 318,
374
LSSD, 172
system level, 173, 186, 189, 198–200
Device identification register, 12, 13, 20, 22,
capture pattern, 106, 178, 179, 184, 186
Device under test (DUT), 5, 7, 144, 207,
343–345, 348, 366
DFT. See Design for testability (DFT)
Differential
AC coupled, 269, 277
current balancing, 273
driver, 66, 159, 161, 178, 257, 258, 273,
274, 282, 291, 316, 354–356, 360,
361, 363, 364, 408, 435, 469–471
receiver, 161, 257, 258, 273, 282, 288, 292,
295, 296, 312, 408, 435, 460, 472
signals, 66, 105, 159–161, 256–258, 266,
273, 277, 278, 281, 282, 287, 288,
297, 318, 319, 348, 353–356, 375,
383, 384
testing, 256, 367
transmission, 269, 271
unbalancing, 354–356
Differential signaling
EXTEST paradox, 258
noise rejection, 257, 258
Digital boundary module (DBM), 31, 231,
233, 247–248
DRAM. See Dynamic random access memory
(DRAM)
Drive conflicts
board level, 136
duration, 129
Driver
asymmetrical, 40, 75, 78, 81
clear the throat, 303
damage resistant, 179–180
disabling, 78, 471
ECL open emitter, 40, 75
“Keepers”, 75
Index 545

single-ended, 161, 272, 275 analog, 209, 218, 226

TTL open collector, 40, 75 digital, 41
Dual-slope integrator, 213–216 errors, 209–212
DUT. See Device under test (DUT)
Dynamic random access memory (DRAM),
344, 365, 375 H
Hardware description language
verilog, 56
E VHDL, 50, 401
Electronic design automation, 47, 172 Hardware fault insertion, 167–168
Electrostatic discharge (ESD), 109, 125, 207, High-pass filter, 292–294, 296, 299–301, 463
247, 263 Homing sequence, 157
Emulation, 9, 42, 163, 232, 266 Hyper-text markup language (HTML), 185
Entity pin behavior description, 463–464 Hysteresis
ESD. See Electrostatic discharge (ESD) delay, 299, 301
Extended interconnect, 229–232, 242, 244, voltage, 295, 298
249, 257, 267 Hysteretic comparator, 298
EXTEST paradox, 258 Hysteretic memory, 296, 300, 302–304, 459
initializing and capturing, 302–304

F
Fault I
detected, 408 ICT. See In-circuit test (ICT)
dictionary, 120 IEEE/ANSI standard 1149.1-1990
failure mechanism, 5 supplement A, 4
model, 5 supplement B, 4
Field-programmable gate array (FPGA), 26, IEEE standard 1076, 50
118, 164, 189, 201, 334, 390, 391, IEEE standard 1149, 25, 48, 58, 63, 64, 73, 83,
394, 458 85–89, 103, 104, 106, 305,
Field-programmable IC 309–313, 315, 322, 405, 406, 424,
blank page, 31 440, 441, 455, 457, 460, 466, 471,
in chains, 189 474, 478, 479, 482, 485, 486
cook time, 165 IEEE standard 1149.1
hard-wired, 31, 32 architecture summary, 19
input/output blocks (IOBs), 31 automation, 46, 49, 382, 388, 389, 422
parallel programming, 32 basic architecture, 10–33
programming, 31, 32, 43, 189 benefits, 43–48
Fine-pitch, 7 conformance and documentation
Fixed system pins, 323 requirements, 49
FLASH RAM, 165–167, 321 costs, 43–48
programming, 166–167 critical mission, 38
FPGA. See Field-programmable gate array ensuring compliance, 53
(FPGA) extensibility, 85
Framescan, 343 gate overhead, 44
increased design time, 45
inserted delay, 44, 45
G lack of discipline, 45
Gallium arsenide, 180 lack of hierarchy, 162
Garbage In, Garbage Out, 3, 267 non-invasive mode, 9, 151, 183
3GIO, 272 pad overhead, 44
Grandfathering, 64, 65 pin-permission mode, 9, 10, 183
Ground-bounce, 174, 175, 178, 295 private instructions, 69
Guardband, 205 public instructions, 42
Guarding reuse of tests, 46
546 Index

IEEE standard 1149.1 (cont.) Intel 80486DX, 187

standardized access, 39 Intellectual property (IP), 1, 382, 455, 456, 461
subordination, 43 Interconnect
trends, 47–48, 381 adjacent nodes, 143
user-defined instructions, 42 counting sequence, 134
yield loss, 44 differential, 229
IEEE standard 1149.4 extended, 229–232, 242, 244, 249,
analog boundary modules, 231, 242–247 257, 267
analog test access port, 233, 236–237 interaction test, 140–144
contrasted with 1149.6, 271 logical, 229
digital boundary modules, 233 opens, 365
general architecture, 233–248 physical, 229
TBIC, 234, 237–242 pin-level diagnostic (shorts), 144
IEEE standard 1149.5, 9, 48, 189, 199, 200 shorting radius, 143
IEEE standard 1149.6 shorts, 129–130, 135, 136, 138, 142, 182
AC pins, 281–288, 463, 464, 466 testing, 127, 132, 140, 141, 158, 187, 191,
compatibility with 1149.1, 280 228, 232, 257, 279, 441
DC pins, 281, 282, 287, 312 test length, 129
testing differential I/O, 256 undetected opens, 130, 136
IEEE standard 1149.8.1, 343, 350–352 walking-bit sequence, 131
IEEE Standard 1532, 4, 14, 31, 165, 286, I/O Pads, 270, 384
321–342, 376–378 ISC. See In-system configuration (ISC)
IEEE 1149 testability bus standards, 48 ISC instruction
in bit. See Boundary-scan description language ISC_DISABLE, 165, 325, 326, 328,
(BSDL), logical port 338–340
in bit_vector. See Boundary-scan description ISC_ENABLE, 165, 325–330, 333, 334,
language (BSDL), logical port 338, 339, 377
In-circuit test (ICT) ISC_NOOP, 339, 340
analog, 203–217 ISC_PROGRAM, 165, 336–340
bed-of-nails, 203, 217, 344 ISC_PROGRAM_SECURITY, 339
fixturing, 375 ISC_READ, 336–339
multiplexed resources, 120 ISC signals
overdrive damage, 40 ISC_Disable_Completing, 326
Inout. See Boundary-scan description ISC_Done, 326–328, 337
language (BSDL), logical port ISC_Enabled, 165, 325–330, 333, 334,
In-situ configuration. See In-system 338, 339, 377
configuration (ISC) ISC system pins, 323–324
Institute of Electrical and Electronics Engineers
(IEEE), 3, 49, 117, 161, 172, 203,
227, 269, 321, 343, 381, 455 J
Instruction mode, 9, 12, 93–95, 97–98, Joint electron device engineering council
100–102, 240 (JEDEC), 35
Instruction register Joint test action group (JTAG), 3, 117
capture pattern, 69, 106, 175, 178, 186
halt shifting, 15
length, 315 K
opcodes, 69 Kelvin measurement, 211
parallel hold rank, 18–20
sample cell design, 21
shifting, 340 L
shift rank, 18 Large scale integration (LSI), 6
shift ripple, 18, 94 Level-sensitive scan design (LSSD), 68, 172
In-system configuration (ISC), 149, 164–166, LFSR. See Linear feedback shift register
321–342 (LFSR)
Intel 8008, 6 Linear feedback shift register (LFSR), 42, 144
Index 547

Linkage. See Boundary-scan description O

language (BSDL), logical port
Lobotomy problem, 9, 37, 183, 386
Logic simulator, 5
Low-pass filter, 281, 293, 298, 301, 317
LSSD. See Level-sensitive scan design
(LSSD)
On-chip coupling and bypassing, 459
Opens express, 343
Operational amplifier, 212–214
Out bit. See Boundary-scan description
language (BSDL), logical port

P
M P1149.2, 48
Manufacturing faults P1149.3, 48
dead component, 172 Package port link description, 464
missing component, 172 Packaging hierarchy, 162, 200, 422, 423, 436,
open solder, 291 442, 445, 488
solder shorts, 143 Parallel test vector (PTV), 115, 116, 130
wrong component, 172, 229 Parasitic devices, 204, 205, 239, 241, 246,
Matsushita electric industries, 47 253, 258, 263, 264
MCM. See Multi-chip module (MCM) PCI express, 272
Measurement errors, 212 PDL commands (Level-0)
Measuring impedance iApply, 437–439, 442–451, 473, 488, 489
imaginary waveform, 215–217 iCall, 440, 445, 447, 482
reactive devices, 216 iClock, 442, 445
real waveform, 217 iCLockOverride, 442, 445
6-wire measurement, 212 ifEnd, 446
Measuring operational amplifier (MOA), 212 ifFalse, 446
Mixed logic families, 191–193 ifTrue, 446
Mixed-signal, 158, 159, 195, 223–226, iLoop, 446
228–231, 267 iMerge, 446–448
Modes of operation iNote, 448
extensible, 10 iPDLLevel, 441
non-invasive, 9, 10 iPrefix, 442, 448
pin-permission, 9, 10 iProc, 441, 442, 445–449, 467, 482
Monte carlo simulations, 219 iProcGroup, 442
Moore’s law, 48, 270, 272, 274, 275, 334, 359, iRead, 437, 438, 442, 443, 446, 448, 450,
381–382, 384 468, 469
Motorola 68040, 44 iRelease, 448
Multi-chip module (MCM), 47, 161–162, 171, iRunLoop, 445, 448, 449
201 iScan, 442, 443, 446, 448
Multidrop systems, 198–200 iSetFail, 448, 450
Multiple IDCODEs, 71 iSetInstruction, 442
iSource, 441
iTake, 448
N iTMSidle, 446, 449
Node voltage analysis, 218–219, 221, 252 iTMSreset, 446, 449
limited access, 217–223 iTRST, 446, 449
Noise iUntil, 446
common mode, 66, 257 iWrite, 437, 439, 442–444, 448, 450, 468,
crosstalk, 295 469, 473
ground-bounce, 295 PDL commands (Level-1)
immunity, 66, 266, 277 iGet, 449–452
I/O, 273 iGetStatus, 449–451
radiated interference, 273 PDL_CONTEXT_PATH, 473
rejection, 257, 258, 295 PDL use model
small signal, 297, 299 data flow (iApply), 437
Normal system pins, 350 PDL scan frame, 437, 438
548
Performance tests, 204
PLD. See Programmable logic device (PLD)
Power
applying, 9, 127, 133, 139
cycling (reset), 34, 38
distribution, 169, 174, 178, 193, 195, 271, 273
removal (safety), 130, 180, 438, 471
separate analog and digital, 195
Powered capacitive opens testing, 343, 344,
346–350
Power/ground distribution, 174–178
Private instructions, 42, 69, 70, 186, 256, 435
Procedural description language (PDL)
level-0 PDL, 436, 438–440, 449
level-1 PDL, 436, 444, 449
PDL procedures, 440–442, 448, 449, 467,
482
TCL, 436, 440, 468
Programmable feature description, 462, 463, 467
Programmable logic device (PLD)
complex programmable logic device, 118,
164, 334
FPGA, 26, 118, 164, 189, 201, 390, 391,
394, 458
non-volatile, 31, 165, 190, 321, 326, 328,
334–336, 340
volatile, 31, 189, 326, 334, 335
PTV. See Parallel test vector (PTV)
R 356, 358–360, 362, 363, 366, 368
Receiver, 5, 109, 161, 182, 257, 273, 361,
390, 458
differential, 66, 161, 257, 258, 273, 282, 288,
292, 295, 296, 312, 408, 432, 460, 472
Reed relay
area, 29, 44, 99, 129, 151, 221, 224, 226,
228, 235, 244, 263, 264, 283, 305,
357, 375, 386, 399, 408, 418
off-resistance, 235
on-resistance, 235
switching time, 235
Reference voltages
G, 208, 234
VH, 234, 237, 242–245, 249, 257, 262, 264
VL, 234, 237, 242–245, 249, 252, 257, 262,
264
VTH, 237, 242, 264
S Synchronizing sequence, 12, 111, 449
Scan-path linker, 196, 197
Segmented data register, 394
Index
Selective toggle system pins (“ST” system
pins ), 349
Self-monitoring output, 38, 101, 181, 182,
239, 308, 357
Self-referenced comparison, 293, 298
Sentinel bits, 125, 126
Sequential response vector (SRV), 116, 129
Sequential test vector (STV), 116, 129, 130,
132, 296, 303, 319
SERDES, 45, 275–277, 320, 377, 414
SERialize/DESerialize. See SERDES
Serial vector format (SVF), 147
Shorted capacitor testing, 290, 291, 319, 458,
459
Shorting radius, 143
Silicon switches
area, 235
bipolar, 235, 262
conceptual, 242, 244
crummy, 236
leakage, 263, 264
off-resistance, 235
on-resistance, 235
parasitic coupling, 264
switching time, 208, 235, 290
symbols, 235, 236
“T” switch, 263, 264
Simple interconnect, 129, 228, 229, 257
Single-ended, 161, 271, 272, 274–276, 280,
281, 288, 291, 298, 303, 316, 317,
Single Stuck-at fault model, 5
SMT. See Surface-mount technology (SMT)
SOC. See System-on-chip (SOC)
Source
current, 141, 206, 207, 218, 250, 252, 355
voltage, 206–208, 210, 216, 217, 243, 299
SRV. See Sequential response vector (SRV)
1149.6 Standard PDL procedures
programmable “GetALL” iProcs, 467
programmable “Get” iProcs, 467
programmable “Set” iProcs, 467
STD_1149_1_1990, 58, 64
STD_1149_1_1993, 64
STD_1149_1_1994, 58, 59
STD_1149_1_2001, 63, 64, 73, 85–89, 305
STD_1149_6_2003, 305, 309–311, 466
defined, 466
STV. See Sequential test vector (STV)
Surface-mount technology (SMT), 7, 46, 171
System logic, 9, 30, 32, 34, 36–39, 41, 43, 48,
50, 53, 56, 78, 79, 81, 82, 91,
Index
120–122, 151, 178–180, 183, 186,
198, 325, 366, 386, 393, 398, 419
System modal state
ISC accessed, 325, 328–330, 338
ISC complete, 325, 326, 328, 330, 340
operational, 326, 327, 330, 340
unprogrammed, 326, 330, 337
System-on-chip (SOC), 45, 161, 171, 377
T 70, 72, 90, 93–95, 97, 98, 100–102,
TAP. See Test access port (TAP)
TAP controller
asynchronous reset, 10
data column states, 12, 13, 113, 144, 199
finite state machine, 11, 12
instruction column states, 12, 13, 175
power-up reset, 420
state diagram, 12, 20, 33, 48, 52, 56, 110,
111, 113, 123, 167, 174, 179, 186,
223, 283, 385, 444, 449
state transitions, 12, 13
synchronizing sequence, 12, 111, 449
temporary state, 14–17
TAP controller state
capture-DR, 14, 16–18, 22, 34–40, 52, 70,
72, 90, 112, 122, 142, 143, 152,
154, 155, 181, 186, 279, 297, 303,
305, 354, 394, 419, 420, 436
capture-IR, 14, 17–20, 53, 70, 106, 112,
124, 175, 178, 179
Exit1-DR, 16–18, 112, 300
Exit2-DR, 16, 17, 300, 444
Exit1-IR, 14, 15, 17, 18, 20, 112, 179
Exit2-IR, 15, 20
pause-DR, 16, 17, 188, 444, 445
pause-IR, 15, 20, 188
run-test/idle, 13–14, 16, 17, 40, 76, 113,
122, 125, 144, 283–285, 291, 300,
303, 317, 318, 325–328, 336–340,
351–353, 357, 358, 444, 445, 449
select-DR-scan, 13, 14, 16, 17, 152, 174,
175, 283, 351, 445
select-IR-scan, 14, 113, 175
shift-DR, 16, 17, 38, 112, 125, 144, 354,
391, 420, 444
shift-IR, 14, 15, 17, 18, 20, 111, 112
test-logic-reset, 12–14, 20, 33, 35, 37, 57,
74, 90, 111, 116, 122, 123, 125,
165, 168, 183, 186, 199, 326, 328,
338–340, 366, 386, 387, 394, 397,
420, 445, 449, 453
549
update-DR, 16–18, 28, 37–39, 112, 113,
129, 155, 167, 168, 174, 175, 278,
279, 283, 296, 297, 300, 330, 353,
387, 393, 396, 420, 421, 436, 445
update-IR, 15–20, 28, 37, 40, 41, 71,
112–114, 116, 120, 122, 174, 179,
186, 303, 324, 328, 352, 386, 394
Tape automated bonding (TAB), 171
TAP instruction
BYPASS, 13, 20, 22, 34, 35, 37, 38, 57,
107, 110, 112, 125, 144, 155, 162,
165, 167, 179, 186, 190, 192, 198,
199, 240, 241, 246, 249, 252, 261,
282, 326, 328, 340, 386, 387, 392
CLAMP, 41, 57, 93–95, 97, 98, 100–102,
110, 155, 165, 186, 240, 252–254,
282, 306, 329, 330, 342, 387,
391–393, 442
CLAMP_HOLD, 386, 387, 392, 395, 396
CLAMP_RELEASE, 386, 387, 392, 395,
396
ECID_CODE, 389–390, 394, 421, 441,
452
EXTEST, 28, 38, 39, 41, 57, 70, 72, 90,
93–95, 97–103, 107, 110, 112–115,
121, 151, 155, 157, 166, 167, 175,
179–181, 183, 184, 186, 190, 191,
240, 241, 246, 248–252, 258, 261,
283, 284, 286, 287, 290, 291,
295–297, 301, 306, 319, 329, 330,
342, 347, 352, 353, 358, 366, 369,
370, 373, 375–377, 386, 387, 390,
395, 435, 442, 458, 459, 461, 463,
487, 490
EXTEST_PULSE (see AC EXTEST
Instruction)
EXTEST_TRAIN (see AC EXTEST
Instruction)
HIGHZ, 40, 57, 76, 98, 99, 151, 155, 165,
186, 240, 241, 245, 246, 249,
252–254, 261, 282, 306, 329–334,
342
IC_RESET, 393, 396, 397
IDCODE, 12, 20, 22, 34–37, 70–72, 90,
94, 95, 97, 98, 100–102, 107, 110,
112, 125, 184, 186, 199, 240, 249,
282, 315, 326, 387, 389, 452
INIT_CLAMP, 390–392, 394
INITIALIZE, 366, 379
INIT_RUN, 390–393, 395, 414, 441, 457,
471, 473, 488, 489
550 Index

TAP instruction (cont.) TDO, 10

INIT_SETUP, 390–392, 394, 441, 457,
488, 489
INTEST, 38–42, 44, 53, 57, 70, 74–77, 81,
90, 92–102, 106, 110, 120–122,
165, 179, 240, 244, 248, 249,
254–256, 258, 264, 266, 282, 288,
303, 306, 308, 316, 329, 460
ISC_DISABLE, 165, 325, 326, 328,
338–340
ISC_ENABLE, 165, 325–328, 330, 338,
339, 377
ISC_PROGRAM, 165, 336–340
PRELOAD, 28, 36, 37, 40, 41, 57, 70, 76,
93–95, 97, 98, 100–102, 110, 114,
116, 122, 165, 168, 189, 240, 249,
282, 303, 306, 330, 352, 353, 358,
366, 387, 391, 392, 442
PROBE, 240, 241, 244, 246, 248, 253,
256, 261, 264
RUNBIST, 14, 39–42, 76, 77, 93–95,
97–102, 106, 122–123, 172, 181,
183, 186, 187, 240, 248, 253–254,
306, 326, 329, 435
SAMPLE, 36, 151, 249, 460
SELECTIVE_TOGGLE, 352, 353, 355,
358–360, 366
SHUTDOWN, 378
TMP_STATUS, 387, 392, 395
TOGGLE_SETUP, 352, 354
USERCODE, 22, 36, 70, 93–95, 97, 98,
100–102, 186, 240, 249, 282
user-defined, 12, 42, 71, 72, 106, 144, 185
TAP state
capture-DR, 14, 16–18, 22, 34–40, 52, 70,
72, 90, 112, 122, 142, 143, 152,
154, 155, 181, 186, 279, 297, 303,
305, 354, 394, 419, 420, 436
run-test/idle, 13–14, 16, 17, 40, 76, 113,
122, 125, 144, 283–285, 291, 300,
303, 317, 318, 325–328, 336–340,
351–353, 357, 358, 444, 445, 449
update-DR, 16–18, 28, 37–39, 112, 113,
129, 155, 167, 168, 174, 175, 278,
279, 283, 296, 297, 300, 330, 353,
387, 393, 396, 420, 421, 436, 445
Target register, 17, 21, 34, 39, 40, 57, 76, 112,
175, 336, 337, 435, 436
TBIC. See Test Bus Interface Circuit (TBIC)
Test access port (TAP)
compatibility with 1149.4, 48
TCK, 10
TDI, 10
TMS, 10
TRST, 10
Test bus interface circuit (TBIC), 234, 235,
237–242, 245, 247, 250–253, 256,
259–262
Test clock (TCK)
buffered, 190–192
cycles in Run-Test/Idle, 326, 336, 337
falling edge, 12, 13, 16–18, 30, 112, 174,
284, 296–300, 303, 317, 324, 328,
330, 351, 353, 393
ground bounce, 174, 175, 178, 271–273,
295
level translation, 191
maximum clock frequency, 317
rising edge, 12–18, 152, 186, 297, 303,
305
stop state, 68
Test data in (TDI)
pin placement, 173–174
shorted to TDO, 124, 126
Test data out (TDO)
actively driving, 63, 81
disabled, 15
shifting data, 20
Testing
Ad-Hoc, 3
analog in-circuit, 203–217
background system diagnostics, 168
basic BIST test algorithm, 122–123
basic test algorithm, 115–116, 120, 122,
129, 130, 353
BIST, 9, 22, 39, 42, 109, 118, 122, 123,
144–145, 162, 198, 393, 431, 434,
441, 447
board-level self-test, 42
boundary-scan chains, 32–33, 53, 99,
123–145, 165, 187, 192, 197, 198,
365, 488
chain integrity, 22, 124–126, 143, 173
CMOS IDDQ, 10
concurrent monitoring, 154–155
connection, 126, 139–140
control of critical nodes, 194–195
customized, 230
DC parametric (IC), 149–151
differential pins, 367
edge connector functional, 4–6, 171
emulation functions, 9
fault dictionary, 120
hardware development support, 163
high frequency, 227
Index 551

hot mock-ups, 4, 5 cell mapping, 304

hybrid digital/analog, 42 data capture, 154
IC, 7, 19, 39, 53, 120–122, 159, 354, 382 DC-coupled response, 294
IC BIST, 122–123 DC response, 295–298
In-Circuit, 6–8, 31, 40, 41, 47, 116–120, defect detection, 288
129, 146–148, 164, 171, 179, documented in BSDL, 66, 68
203–218, 226, 280, 344, 347 edge detection, 301
in-circuit boundary-scan, 118–120, 139 edge sensitive, 287
interaction, 140–144, 147 guaranteed AC-coupling, 301
interconnect, 65, 126–141, 144, 148, 158, initial state, 296, 297
187, 191, 194, 198, 228, 230, 232, integrated AC/DC, 302
237, 239–246, 249, 250, 257, 266, low-pass time constant, 300
267, 279, 356, 366, 441 memory, 296, 297, 300, 303
interconnect opens, 134–139 noise rejection, 257, 258, 295
interconnect shorts, 129–130, 135, 136, output, 288, 299, 300
138, 142, 182 self-referenced, 280, 288, 293, 298
limited access, 217–223 silicon overhead, 320
limited access node voltage, 221–223 single-ended, 287
logic analyzer, 36, 151 transparent, 287
mixed digital/analog, 109, 158–161 Test reset (TRST), 10–13, 20, 33, 44, 57, 67,
module, 48, 200 105, 111, 123, 187, 194, 195, 233,
multi-chip modules, 161–162 326, 328, 386, 390, 393, 396, 407,
node voltage, 220–223 420, 440, 449
noise rejection, 257, 258, 295 assertion, 12, 18, 33, 123, 326
non-digital devices, 158 Texas instruments 74ABT8996, 200
non-scan ICs, 155–157 Texas instruments 74ACT8990, 195
parallel impedances, 209 Texas instruments 74ACT8997, 189, 196, 197,
performance, 162, 204 200
personal tester, 117–118 Texas instruments 74ACT8999, 189, 196, 200
personal tester within ATE, 117–118 Texas instruments 74BCT8244, 42, 44
printed circuit board, 3, 7, 32, 224, 272, 343 Texas instruments 74BCT8373, 178
pseudo-random patterns, 42, 144 Texas instruments 74BCT8374, 58, 61, 78, 82,
RAM arrays, 23 178
sample mode, 149, 151–154 Through-hole pin, 7
self-test, 14, 22, 39, 40, 42, 144, 172, 265 Time constant
signature analysis, 42, 144, 171 decay, 278, 279, 295, 301
simulator-based functional, 6 high-pass, 293, 300, 301, 317
stop-on-first-fail, 116, 436 low-pass, 293, 300, 301, 317
system level, 148, 189, 198, 266 TMP operational modes
undetectable shorts, 157 persistence off, 392, 420
unpowered analog, 209 persistence on, 393, 396, 420
unpowered shorts testing, 119, 126, 139 Toggle control register, 351–354, 358, 366
X-ray laminography, 133, 375 Tolerance
TestJet, 343 of component values, 205
Test mode persistence (TMP), 10, 12, 38, 198, distribution, 205
324, 385–387, 392, 394–397, 420, nominal values, 205
453 Transition
Test mode select (TMS) defined, 293
buffered, 190, 192 detecting, 283
level translation, 191 edge speed, 285, 286
Test receiver generating, 283
AC-coupled response, 294–295 invalid, 294, 295, 300
AC Response, 298–301 noise, 272, 299
552
Transition (cont.)
use of mission driver, 285
valid, 295, 298–300, 303, 319
U blind, 171
Unpowered capacitive opens detection, 343
sense plate, 344–347
Update flip-flop (UPD), 23, 27, 28, 37–39, 41,
74, 91, 96, 112, 167, 180, 181, 283,
303, 353, 358, 387, 389, 398
UUT. See Device Under Test
V
Very large-scan integration (VLSI), 44, 119,
171, 174
VHDL identifiers. See Boundary-scan
description language (BSDL),
identifier
Index
VHSIC hardware description language
(VHDL), 50, 51, 56–58, 61–63, 65,
68, 85, 90, 105, 181, 304, 401–403,
405, 419, 440
Vias, 7, 8, 171, 224, 225
Voltage programmability, 458
Voltage scaling, 458
Voltage variations, 458
W
Walking-bit sequence, 131, 133
X
Xilinx 4005, 31, 32
Xilinx XC9500, 31
X-ray laminography, 133, 375
X-Y coordinate location data, 8