You are on page 1of 315

THE BOUNDARY-SCAN HANDBOOK

SECOND EDITION
Analog and Digital

This page intentionally left blank

THE BOUNDARY-SCAN HANDBOOK


SECOND EDITION
Analog and Digital

by
Kenneth P. Parker
Hewlett-Packard Company

KLUWER ACADEMIC PUBLISHERS


NEW YORK, BOSTON, DORDRECHT, LONDON, MOSCOW

eBook ISBN:
Print ISBN:

0-306-47656-8
0-7923-8277-3

2002 Kluwer Academic Publishers


New York, Boston, Dordrecht, London, Moscow
Print 1998 Kluwer Academic Publishers
Dordrecht
All rights reserved
No part of this eBook may be reproduced or transmitted in any form or by any means, electronic,
mechanical, recording, or otherwise, without written consent from the Publisher
Created in the United States of America
Visit Kluwer Online at:
and Kluwer's eBookstore at:

http://kluweronline.com
http://ebooks.kluweronline.com

Dedication

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

This page intentionally left blank

TABLE OF CONTENTS
List of Figures
List of Tables
List of Design-for-Test Rules
Preface to the First Edition
Preface to the Second Edition
Acknowledgement
1 Boundary-Scan Basics and Vocabulary
1.1 Digital Test Before Boundary-Scan

1.1.1 Edge-Connector Functional Testing


1.1.2 In-Circuit Testing
1.2 The Philosophy of 1149.1-1990
1.3 Basic Architecture

1.3.1
1.3.2
1.3.3
1.3.4
1.3.5
1.3.6
1.3.7
1.3.8

The TAP Controller


The Instruction Register
Data Registers
The Boundary Register
Optimizing a Boundary Register Cell Design
Architecture Summary
Field-Programmable IC Devices
Boundary-Scan Chains

1.4 Non-Invasive Operational Modes

1.4.1
1.4.2
1.4.3
1.4.4
1.4.5

BYPASS
IDCODE
USERCODE
SAMPLE
PRELOAD

1.5 Pin-Permission Operational Modes

1.5.1
1.5.2
1.5.3
1.5.4
1.5.5
1.5.6

EXTEST
INTEST
RUNBIST
HIGHZ
CLAMP
Exceptions Due to Clocking

1.6 Extensibility
1.7 Subordination of IEEE 1149.1
1.8 Costs and Benefits

1.8.1 Costs
1.8.2 Benefits
1.8.3 Trends
1.9 Other Testability Standards

xiii
xviii
xix
xxi
xxiii
xxv
1
2
2
4
7
8
10
16
20
21
27
29
30
31
32
33
33
34
35
35
36
36
37
38
39
39
39
40
41
42
42
43
45
46

Boundary-Scan Description Language (BSDL)


2.1 The Scope of BSDL
2.1.1 Testing
2.1.2 Compliance Assurance
2.1.3 Synthesis
2.2 Structure of BSDL
2.3 Entity Descriptions
2.3.1 Generic Parameter
2.3.2 Logical Port Description
2.3.3 Standard USE Statement
2.3.4 Use Statements
2.3.5 Component Conformance Statement
2.3.6 Device Package Pin Mappings
2.3.7 Grouped Port Identification
2.3.8 TAP Port Identification
2.3.9 Compliance Enable Description
2.3.10 Instruction Register Description
2.3.11 Optional Register Description
2.3.12 Register Access Description
2.3.13 Boundary-Scan Register Description
2.3.14 RUNBIST Execution Description
2.3.15 INTEST Execution Description
2.3.16 User Extensions to BSDL
2.3.17 Design Warnings
2.4 Some advanced BSDL Topics
2.4.1 Merged Cells
2.4.2 Asymmetrical Drivers
2.5 BSDL Description of 74BCT8374
2.6 Packages and Package Bodies
2.6.1 STD_1149_1_1999
2.6.2 Cell Description Constants
2.6.3 Basic Cell Definitions BC_0 to BC_7
2.6.4 User-Defined Boundary Cells
2.6.5 Definition of BSDL Extensions
2.7 Writing BSDL
2.8 Summary
3 Boundary-Scan Testing
3.1 Basic Boundary-Scan Testing
3.1.1 The 1149.1 Scanning Sequence
3.1.2 Basic Test Algorithm
3.1.3 The Personal Tester Versus ATE
3.1.4 In-Circuit Boundary-Scan
3.1.5 IC Test
3.1.6 IC BIST

viii

49
52
52
53
55
57
61

62
62
63
64
64
65
66
67
68
69
70
71
72
75
76
77
77
78
78
80
80
84
85
89
91
99
100
101
103
105
106
106
112
113
114
116
118

3.2 Testing with Boundary-Scan Chains


3.2.1 1149.1 Chain Integrity
3.2.2 Interconnect Test
3.2.3 Connection Tests
3.2.4 Interaction Tests
3.2.5 BIST and Custom Tests
3.3 Porting Boundary-Scan Tests
3.4 Summary
4 Advanced Boundary-Scan Topics
4.1 DC Parametric IC Tests
4.2 Sample Mode Tests
4.3 Concurrent Monitoring
4.4 Non-Scan IC Testing
4.5 Non-Digital Device Testing
4.6 Mixed Digital/Analog Testing
4.7 Multi-Chip Module Testing
4.8 Firmware Development Support
4.9 In-System Configuration
4.10 Hardware Fault Insertion
5 Design for Boundary-Scan Test
5.1 Integrated Circuit Level DFT
5.1.1 TAP Pin Placement
5.1.2 Power and Ground Distribution
5.1.3 Instruction Capture Pattern
5.1.4 Damage Resistant Drivers
5.1.5 Output Pins
5.1.6 Bidirectional Pins
5.1.7 Post-Lobotomy Behavior
5.1.8 IDCODEs
5.1.9 User-Defined Instructions
5.1.10 Creation and Verification of BSDL
5.2 Board-Level DFT
5.2.1 Chain Configurations
5.2.2 TCK/TMS Distribution
5.2.3 Mixed Logic Families
5.2.4 Board Level Conflicts
5.2.5 Control of Critical Nodes
5.2.6 Power Distribution
5.2.7 Boundary-Scan Masters
5.2.8 Post-Lobotomy Board Behavior
5.3 System-Level DFT
5.3.1 The MultiDrop Problem
5.3.2 Coordination with Other Standards
5.4 Summary
ix

119
119
122
136
138
141
142
144
145
146
147
150
151
154
155
157
159
160
163
167
169
169
170
174
175
176
177
178
178
179
180
182
182
185
186
187
188
190
190
192
193
194
195
195

Analog Measurement Basics


6.1 Analog In-Circuit Testing
6.1.1 Analog Failures
6.1.2 Measuring an Impedance
6.1.3 Errors and Corrections
6.1.4 Measurement Hardware
6.2 Limited Access Testing
6.2.1 Node Voltage Analysis
6.2.2 Testing With Node Voltages
6.2.3 Limited Access Node Voltage Testing
6.3 The Mixed-Signal Test Environment
6.4 Summary
7 IEEE 1149.4 Analog Boundary-Scan
7.1 1149.4 Vocabulary and Basics
7.1.1 The Target Fault Spectrum
7.1.2 Extended Interconnect
7.1.3 Digital Pins
7.1.4 Analog Pins
7.2 General Architecture of an 1149.4 IC
7.2.1 Silicon Switches
7.2.2 The Analog Test Access Port (ATAP)
7.2.3 The Test Bus Interface Circuit (TBIC)
7.2.4 The Analog Boundary Module (ABM)
7.2.5 The Digital Boundary Module (DBM)
7.3 The 1149.4 Instruction Set
7.3.1 The EXTEST Instruction
7.3.2 The CLAMP Instruction
7.3.3 The HIGHZ Instruction
7.3.4 The PROBE Instruction
7.3.5 The RUNBIST Instruction
7.3.6 The INTEST Instruction
7.4 Other Provisions of 1149.4
7.4.1 Differential ATAP Port
7.4.2 Differential I/O
7.4.3 Partitioned Internal Test Buses
7.4.4 Specifications and Limits
7.5 Design for 1149.4 Testability
7.5.1 Integrated Circuit Level
7.5.2 Board Level
7.5.3 System Level
7.6 Summary
7.7 Epilog: What Next for 1149.1/1149.4?

197
197
198
200
204
206
211
212
213
215
217
220
221
222
223
223
225
226
227
229
230
231
236
242
243
244
247
247
247
248
248
250
250
251
253
256
257
257
259
260
261
262

APPENDIX A: BSDL Syntax Specifications


A.1 Conventions
A.2 Lexical elements of BSDL
A.3 Notes on syntax definition
A.4 BSDL Syntax
A.5 User Package Syntax
Bibliography

263
263
264
267
269
273
275

Index

281

xi

This page intentionally left blank

List of Figures
Figure 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.
5
Figure 1-2: Cutaway drawing of a board resting on top of an In-Circuit, vacuumactuated 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.
6
Figure 1-3: General, simplified architecture of an 1149.1 compliant Integrated
Circuit.
9
11
Figure 1-4: State transition diagram of the sixteen-state TAP controller.
Figure 1-5: Architecture detail of a typical Boundary-Scan register with shift and
17
parallel hold ranks.
Figure 1-6: Example of an instruction register cell design. The expanded cell shows
several control signals generated by the TAP state machine.
19
Figure 1-7: A Typical Boundary Register Cell.
22
Figure 1-8: A Bidirectional pin with separate input and output Boundary Register
cells.
23
Figure 1-9: A Bidirectional pin served by a reversible Boundary Register cell.
25
Figure 1-10: Compensating inversions in an input Boundary Register cell that
monitors an inverting input buffer.
26
Figure 1-11: Compensating inversion in an output Boundary Register cell connected
26
to an inverting output buffer.
Figure 1-12: Two logical symbols for typical boundary cells, one with an Update
27
(UPD) flip-flop (A) and one without (B).
Figure 1-13: An example (adapted from [Whet95]) of an output cell design that
28
eliminates both a discrete register stage and a multiplexer delay.
Figure 1-14: Block Diagram of a Boundary-Scan IC.
29
Figure 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
31
input or output only.
32
Figure 1-16: A simple chain of Boundary-Scan ICs.
Figure 1-17: Code bit allocation in a Device Identification Register accessed by
34
IDCODE.
40
Figure 1-18: Observe-Only Boundary Register cell for inputs.
Figure 1-19: Product introductions by Companies X and Y, and their relative
44
performance.
51
Figure 2-1: BSDL use model within or outside of a VHDL environment.
53
Figure 2-2: BSDL used as a test driver.
54
Figure 2-3: A process for checking the compliance of an IC with the Standard.
56
Figure 2-4: An 1149.1 synthesis system that both creates and uses BSDL.
Figure 2-5: The relationship of a BSDL entity to the standard package and package
59
body.
78
Figure 2-6: Candidate for merged cell design.
Figure 2-7: Design with input and control cells merged.
79
81
Figure 2-8: A design illustrating several merged cell situations.
Figure 2-9: Texas Instruments 74BCT8374 Octal D Flip-Flop with Boundary-Scan. 82

Figure 2-10: An abstraction of a Boundary Register cell showing capture data sources.

90
92
Figure 2-11: Cell architecture BC_1, a basic but very flexible design.
Figure 2-12: Cell architecture BC_2. This cell can capture its own Update latch
93
content.
94
Figure 2-13: Cell architecture BC_3, an input cell with no Update latch.
Figure 2-14: Cell architecture BC_4, a cell with no Update latch and no series
95
multiplexer.
Figure 2-15: Cell architecture BC_5, a control cell that can support HIGHZ-type
95
behavior.
Figure 2-16: Cell architecture BC_7 (see the circuitry in the dotted line box) which
97
supports bidirectional data flow.
Figure 2-17: A cell that captures a constant 1 during EXTEST.
99
Figure 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.
106
Figure 3-2: TAP Controller state diagram showing path taken to shift an N-bit
instruction into the Instruction Register.
108
Figure 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.
109
Figure 3-4: Sequence of states traversed to capture data and shift it out while at the
same time entering new data.
110
Figure 3-5: Completing a data shifting operation and updating the parallel hold portion
of a data register.
111
117
Figure 3-6: An IC undergoing an INTEST function while loaded on a board.
Figure 3-7: A chain that has just passed CAPTURE-IR, loading all Instruction
120
Registers with 01.
Figure 3-8: A Boundary-Scan chain of ICs with four interconnect nodes.
123
Figure 3-9: Interconnect test drives unique patterns assigned to each node from drivers
124
to receivers. A short is shown that creates a Wired-OR result.
Figure 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.
125
Figure 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. Note two nodes are bussed.
126
Figure 3-12: Three examples of bus wire driver opens not detected by interconnect
132
shorts test.
Figure 3-13: Control cell fanout combined with board topology that results in
133
undetected opens.
Figure 3-14: Parallel testing of two bussed nodes.
134
Figure 3-15: A case where four buses containing different numbers of drivers are
tested in parallel.
135
Figure 3-16: A circuit where not all Boundary-Scan pins can be tested via interconnect
test.
137
Figure 3-17: Example of potential interactions between a Boundary-Scan node and
two non-scanned nodes.
138
xiv

Figure 3-18: Boundary-Scan nodes B and C that can interact (by shorting) with
nodes A, D or F.
139
Figure 3-19: Two cooperating components provide stimulus vectors and capture a
signature response for data path logic.
141
Figure 3-20: Developing and porting a manually generated test for similar
applications.
142
Figure 3-21: Developing a Boundary-Scan test for similar applications.
143
Figure 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.
147
Figure 4-2: A simple circuit and its timing diagram showing setup and hold times, and
the effects of system clock skew.
148
Figure 4-3: Simple circuit showing the relationships between the system clock and
TCK during SAMPLE operation.
149
Figure 4-4: Concurrent sampling of component I/Os during system diagnostics, with
sampled data compressed in a multiple-input signature analysis register (MISR).

151
Figure 4-5: Testing a non-scan IC U7 with a combination of physical nails and
Boundary-Scan pins.
152
Figure 4-6: A timing diagram that shows how Boundary-Scan resources must be
coordinated with the resources of a host ATE system.
153
Figure 4-7: Shorted inputs on a NAND gate that may not be detectable when tested by
154
ordinary Boundary-Scan drivers.
Figure 4-8: A Boundary-Scan testable node that has a termination resistor to eliminate
154
noise.
Figure 4-9: A mixed digital/analog IC with the Boundary Register partitioning the
digital from the analog.
155
Figure 4-10: Two digital ICs that communicate by differential signaling, an analog
technique.
156
Figure 4-11: Three examples of unusual differential signaling applications.
157
Figure 4-12: Multi-Chip Module shown in cross section. This example shows a multilayer ceramic PGA made of multiple dielectric and metalization layers. Bare IC
die and other discrete components are mounted on the top surface.
158
Figure 4-13: Four macro states an FPGA/CPLD can be in and the transitions
between them.
162
Figure 4-14: A BC_1 Boundary Register cell modified to support fault insertion. 164
Figure 5-1: Three pin layouts for TDI and TDO.
169
Figure 5-2: An oscillograph of a Ground-Bounce induced clock cycle on TCK during
UPDATE-DR, measured at the package TCK pin referenced to component
ground.
170
Figure 5-3: A high pincount IC with two 32-bit buses.
172
Figure 5-4: The transition timing for activities on the two buses in Figure 5-3.
172
Figure 5-5: Deliberately inserted delays in the Boundary Register control signal
paths can be used to distribute driver edge placements in time.
173
Figure 5-6: A Boundary Register output cell design with the capability of monitoring
its driver output pad during EXTEST.
176
Figure 5-7: A Siamese chain pair with common TCK and TMS signals, but
independent data paths. Any number of chains could be linked in parallel this
183
way.
xv

Figure 5-8: A Siamese chain pair with separate TMS lines, common TCK, and shared
184
board-level TDI and TDO signals.
Figure 5-9: A simple chain with buffered TCK and TMS signals needed to avoid
185
overloading.
Figure 5-10: A low-skew clock buffer with 50% duty cycle preserved by utilizing
186
inversion.
Figure 5-11: A simple Boundary-Scan chain containing ICs from different logic
186
families. Logic level conversion must be made between them.
Figure 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
187
conversion.
Figure 5-13: A Boundary-Scan IC during test can set two normally complementary
outputs to the same state, exciting conflicts in conventional ICs downstream. 188
Figure 5-14: Two Boundary-Scan nodes A and B need additional support from tester
189
resources to enable proper testing.
Figure 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,
190
reflecting mastership.)
Figure 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
192
the end of the chain.
Figure 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
194
would be broken at an empty slot.
Figure 6-1: A simple filter circuit and the actual circuit when parasitic capacitance is
198
included.
Figure 6-2: Distribution of resistance values for a 4.7 Kohm resistors with a
199
tolerance of 5%.
Figure 6-3: Measuring impedance with current source stimulus (A) and with voltage
201
source stimulus (B).
Figure 6-4: Measuring the impedance of a device on a board, connected to a silicon
202
device (A), and as seen by an ATE system (B).
Figure 6-5: Devices may be connected into networks providing parallel pathways for
203
currents.
Figure 6-6: Some sources of error in an ATE setup for measuring a simple
impedance.
205
Figure 6-7: Error impedances for a delta measurement (A) and a 6-wire
206
measurement configuration (B).
Figure 6-8: An operational amplifier with feedback resistor used as a current meter.

207
Figure 6-9: An operational amplifier setup to integrate a DC voltage V over time.207
208
Figure 6-10: An operational amplifier setup for DC Dual Slope Integration.
Figure 6-11: A dual slope integrator modified for AC measurements.
209
Figure 6-12: A dual slope integrator used to measure a reactive component.
210
Figure 6-13: Imaginary voltage waveform seen when measuring a capacitor.
211
Figure 6-14: A simple network containing four resistors with full nodal access. 212
213
Figure 6-15: Three-dimensional coordinates for graphing voltage differences.
xvi

Figure 6-16: Three-dimensional plots where only some components are potentially
214
faulty at any one time.
Figure 6-17: Example circuit with access to node B removed.
215
Figure 6-18: Projecting the shadow of a three-dimensional object onto a plane. 215
Figure 6-19: Projections of failure spaces for R2 and R3 onto two of the voltage
216
planes.
217
Figure 6-20: A mixed-signal printed circuit board.
Figure 6-21: Key to the color photograph appearing on the cover of this book. 219
Figure 6-22: Comparison of relative sizes of various features.
220
223
Figure 7-1: A mixed-signal circuit with some possible defects.
224
Figure 7-2: Examples of interconnections seen in mixed-signal circuits.
227
Figure 7-3: General (minimal) architecture of an 1149.4 compliant IC.
Figure 7-4: Detail of 1149.4 data register structure.
228
Figure 7-5: Symbols used for opened and closed switches.
230
Figure 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.
231
Figure 7-7: A TBIC switching structure inserted between AT1/AT2 and AB1/AB2.
232
Note one-bit digitized values of the AT1/AT2 signals are generated.
234
Figure 7-8: Control structure for the switches shown in Figure 7-7.
237
Figure 7-9: ABM design detail for a generalized analog function pin.
239
Figure 7-10: Control structure for the switches shown in Figure 7-9.
Figure 7-11: ESD protection circuit for a typical pin (A) and an 1149.4 pin (B). 242
Figure 7-12: Alternative forms for the Boundary Register depending on whether
243
INTEST and/or RUNBIST are supported.
Figure 7-13: An ATE system set up to utilize 1149.4 resources in an IC to measure
244
an externally connected impedance.
Figure 7-14: Two measurements (A) and (B) used to find the voltage across Z for a
245
known current.
Figure 7-15: Testing the digital core using INTEST. The analog core is not directly
249
tested.
Figure 7-16: The analog core can be tested by patterns supplied at the D/A interface
250
and by signals supplied or controlled by the ABMs.
252
Figure 7-17: An example implementation for differential inputs and outputs.
253
Figure 7-18: Example of a TBIC structure with one extension (k=2).
Figure 7-19: Control structure for the extended TBIC switches in Figure 7-18. 254
Figure 7-20: A conventional transmission gate switch and a shunting T switch
258
structure that reduces coupling when the switch is off.
260
Figure 7-21: Degrees of guarding between two ATn signals.

xvii

List of Tables
18
Table 1-1: Instruction Register operation during each TAP Controller state.
63
Pin
types
in
a
BSDL
logical
port
description.
Table 2-1:
74
Table 2-2: Function symbols and their meanings.
75
Table 2-3: Definition of Disable Result field symbols.
89
Table 2-4: Definitions of allowable CELL_TYPE symbols.
90
Table 2-5: Definitions of CAP_DATA symbols.
92
Table 2-6: Mode signal assignment for cell BC_1 used in any context.
Table 2-7: Mode signal assignments for cell BC_2 in the context of use. See text for
93
an exception regarding INTEST.
94
Table 2-8: Mode signal assignment for cell BC_3.
96
Table 2-9: Mode signal assignments for cell BC_5.
Table 2-10: Mode signal assignments for BC_7 and its related BC_5 control cell. 98
Table 3-1: Example data bits for chains shown in Figure 3-7. The bits for IC7 are the
120
first to appear at TDO.
Table 3-2: Data streams from chains shown in Figure 3-7 with IC4 TDI and TDO
122
shorted together, producing a Wired-AND.
Table 3-3: Sequential Test Vectors for a set of nodes. The rows are STVs and the
129
columns are PTVs.
Table 3-4: A set of test PTVs (the columns) for interconnect test. (The Notes are
131
explained in the text.)
134
Table 3-5: Parallel test data for two bussed nodes.
136
Table 3-6: Test data required for bus wires with different numbers of drivers.
Table 6-1: Node voltages for the circuit in Figure 6-14 when the component values
212
vary from nominal.
229
Table 7-1: Comparison of parameters of various switches.
Table 7-2: TBIC switching patterns (P0 through P9) for the switches shown in
Figure 7-7.
233
Table 7-3: Assignment of TAP instructions to mode signal values for the TBIC. 234
Table 7-4: Selection of TBIC switch patterns versus Boundary Register cell content.
235
236
Table 7-5: Logic equations for TBIC switch control.
Table 7-6: ABM switching patterns (P0 through P19) for the switches shown in
Figure 7-9.
238
Table 7-7: Selection of ABM switch patterns versus Boundary Register cell content.
240
241
Table 7-8: Logic equations for ABM switch control.
Table 7-9: TBIC extension switching patterns for the switches in Figure 7-18 for
extension k.
254
Table 7-10: Selection of TBIC extension switch patterns versus Boundary Register
cell content.
255
Table 7-11: Logic equations for TBIC extension switch control.
256

xviii

List of Design-for-Test Rules


DFT-l: Place TDI and TDO pins on the end or the corner of a package to reduce
their likelihood of being bridged by solder.
170
DFT-2: When possible, place power pins between TDI and TDO pins and other
signal pins.
170
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.
174
DFT-4: Use higher-order bits of the Instruction Register capture pattern to
implement an informal ID code. The bits captured must be predictable 0s and
ls.
174
DFT-5: If design-dependent bits are captured in the Instruction Register, then any
combination of these bits should decode to the same operation.
175
DFT-6: Specify a tolerance period that drivers can withstand shorts to each other or
to Power/Ground voltages.
176
DFT-7: Use self-monitoring output cells in the Boundary Register to improve
Boundary-Scan diagnosis of shorts and opens.
177
DFT-8: For bidirectional pins, utilize a single-cell bidirectional design with a selfmonitoring capability (such as cell BC_7).
178
DFT-9: When the 1149.1 logic executes a pin-permission instruction, the system
logic should be forced into a state that prevents internal conflicts.
178
DFT-10: When the 1149.1 logic returns to non-invasive mode, the system logic
178
should stay in a state that will not conflict with board level signals.
DFT-l1: Use formal or informal ID codes to differentiate similar components or
revisions of components.
179
DFT-l2: Consider board-level testing problems that will require user-defined
instructions for their solutions, before final implementation of the 1149.1 logic.

180
DFT-13: Verify that a BSDL description matches the silicon implementation of
1149.1 on every component.
181
DFT-14: Before designing a board-level chain configuration, be sure that the
184
software that will be used during testing will support it.
DFT-15: 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
184
chain.
DFT-l6: Utilize simple buffering (where possible) of the broadcast TCK/TMS
signals. Document the enabling and initialization requirements needed to
185
preserve the 1149.1 protocol through TCK/TMS distribution.
186
DFT-17: Do not allow logical inversion in the TCK or TMS pathways.
DFT-l8: When mixed logic families are used on a board, use scanned level
converters for the parallel signals and a non-scanned level conversion for
187
TCK/TMS distribution.
DFT-l9: 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
188
testing activity.
DFT-20: Provide for the ability of a tester to disable conventional ICs whose outputs
would otherwise conflict with nodes involved in Boundary-Scan tests.
189

xix

DFT-21: Provide for the ability of a tester to create strong drive values on weak
189
nodes.
DFT-22: Make sure you locate and condition all Test Reset (TRST*) pins and all
189
compliance enable pins before executing any Boundary-Scan tests.
DFT-23: Design analog and digital subsystems such that the analog power can be
shut off while Boundary-Scan testing is being done.
190
DFT-24: 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 masters interface. 191
DFT-25: Ensure that a board, after any 1149.1 operation completes, will have safe
states on all components and nodes.
193
DFT-26: Restrict 1149.1 implementations for system tests to simple system
195
architectures not containing a multidrop scheme.
DFT-27: Eliminate all common conductive paths between a system pin pad and the
ATn switches (SB1 and SB2).
258
DFT-28: Partition internal analog test buses (per section 7.4.3) to control on-chip
cross talk, leakage, and capacitance.
258
DFT-29: 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.
258
DFT-30: Analyse the layout of the ATn pins with respect to leakage and parasitic
effects between them and other signals.
259
DFT-31: Group compatible ATAPs together on common ATn buses. Be prepared to
accommodate more ATAP buses than there are TAP chains.
259
DFT-32: For ATn ports expected to be used in measurements of very high
impedances, place a board-level guard wire between the ATn signals.
260
DFT-33: Consider which of all ATn ports in a system will be needed for system test
and provide access to them.
260
DFT-34: Consider if noise-immunity testing of differential signaling is required in
the system.
261

xx

Preface to the First Edition


In February of 1990, the balloting process for the IEEE proposed standard P1149.1
was completed creating IEEE Std 1149.1-1990. Later that summer, in record time,
the standard won ratification as an ANSI standard as well. This completed over six
years of intensive cooperative effort by a diverse group of people who share a vision
on solving some of the severe testing problems that exist now and are steadily
getting worse.
Early in this process, someone asked me if I thought that the P1149.1 effort
would ever bear fruit. I responded somewhat glibly that it was anyones guess.
Well, it wasnt anyones guess, but rather the faith of a few individuals in the
proposition that many testing problems could be solved if a multifaceted industry
could agree on a standard for all to follow. Four of these individuals stand out; they
are Harry Bleeker, Colin Maunder, Rodham Tulloss, and Lee Whetsel. In that I am
convinced that the 1149.1 standard is the most significant testing development in the
last 20 years, I personally feel a debt of gratitude to them and all the people who
labored on the various Working Groups in its creation.
Why do I feel that 1149.1 is more significant than, say, In-Circuit testing (mid
1970s) or the various scan design approaches (mid 70s again) such as LSSD?
Surely these were very significant. However, the In-Circuit test technique, while the
basis of several trillion dollars
worth of electronics production, is basically an
Ad-Hoc technique where the creation of a board test is only partially automatable and
subject to potentially severe debugging problems. In short, every new board is an
adventure. The various scan approaches were very significant in their ability to lead to
the automation of test development. However, they were most successful when carried
out within large, vertically integrated electronics companies. As such, they did not
contribute to testing problem solutions of the electronics industry at large.
A major contribution of 1149.1 is that it provides a standard mechanism for
dissimilar segments of the electronics industry to provide support for testing
problems without requiring them to understand all those various problems. As an
example, members of the IC Merchant community have virtually no concept of the
problems of board level testing; nor should they have to if they will provide the
1149.1 capability in their devices.
Another major contribution of 1149.1 is revealed in the first half of its formal
name, Standard Test Access Port. This Port is an I/O and control protocol as
surely as RS-232 and Ethernet are. Combined with the open-ended extensibility of
the standard, the 1149.1 standard is a gateway to new testing approaches.
Built-In-Self-Test (BIST) immediately comes to mind. It is this particular focus that
suddenly makes the standard attractive to IC designers. They say, well, I am being
forced to add these four pins and some overhead, but, look at the neat things I could
then do with it. These things are not limited to the field of testing.
This book is aimed at professionals in the electronics industry who are concerned
with the practical problems of competing successfully in the face of rapid-fire
technological change. Since many of these changes affect our ability to do testing and
hence cost-effective production, the advent of the 1149.1 standard is rightly looked
upon as a major breakthrough. However, there is a great deal of misunderstanding about

what to expect of 1149.1 and how to use it. Because of this, this book is not a re-hash of
the 1149.1 standard nor does it intend to be a tutorial on the basics of its workings. The
standard itself should always be consulted for this, being careful to follow supplements
issued by the IEEE that clarify and correct it. Rather, this book attempts to motivate
proper expectations and explain how to use the standard successfully.

xxii

Preface to the Second Edition


I was delighted when Carl Harris of Kluwer asked me to consider producing this
second edition. This indicated that he believed 1149.1 and the newly emerging
1149.4 standards are of continuing interest to the engineering profession.
IEEE standards, when embraced by practicing engineers, are living entities that
grow and change quickly. That justifies this edition, but also should serve as a
warning that the material in this book may be superceded by upcoming changes in
the standards. Always consult the most recent editions of the standards themselves
for information needed for implementation. This book is intended to describe these
standards in simple English rather than the strict and pedantic legalese encountered
in the standards. After reading this book, it is my hope the reader will find it easier to
follow the course of the standards themselves.
Since the first edition of this book became available, the IEEE has formalized the
Boundary-Scan Description Language (BSDL) and made it a part of the standard.
Indeed, to be compliant, devices must now be documented in BSDL so that
computer applications can use their features.
The 1149.1 standard is now over eight years old and has a large infrastructure of
support in the electronics industry. Today, the majority of custom ICs and
programmable devices contain 1149.1. New applications for the 1149.1 protocol
have been introduced, most notably the In-System Configuration (ISC) capability
for Field Programmable Gate Arrays (FPGAs).
This book also introduces the very recently balloted standard, IEEE 1149.4
Mixed-Signal Test Bus. This standard builds upon the base created by 1149.1. In
1990, it was not at all clear how analog pins in mixed-signal devices should be
treated by a testability standard. Now that 1149.4 exists, the two Working Groups
have begun the process of reconciling the two, with the possibility that the two
documents will be merged together. Be alert for this event since it will mean more
change in the future.
Finally, the cover of this book shows a picture of what is driving our industry
today. (See Figure 6-21 on page 219 for a key and discussion of this photograph.)
Miniaturization is rampant in many sectors of our industry. Two examples are
cellular telephones and handheld video cameras. A trend in our industry is that
miniaturized components are becoming the low-cost alternative because of the
volumes that consumer applications demand. Thus, those portions of industry that
dont need these components for reasons of density will still find it attractive to
adopt them. This portends an increase in testing problems that 1149.1 and 1149.4 are
meant to solve. It is my sincere hope that this book will be of some use in solving
these problems.

This page intentionally left blank

Acknowledgment
Id 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. Beth Eikenbary made management support happen.
Others who influenced this work were Colin Maunder, Rod Tulloss, Chi Yau, Najmi
Jarwala, Lee Whetsel, Gordon Robinson, 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, 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.
Reviews of various manuscripts were conducted by Anne Dudfield and John
McDermid of Hewlett-Packard, Ben Bennetts of Bennetts Associates, Colin
Maunder of British Telecom and Keith Lofstrom of KLIC Incorporated, directed by
Carl Harris of Kluwer Academic Publishers. All errors and omissions that survived
their careful efforts are my own.
I am indebted to my wife Jana, and my eight and six-year-old 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. I
thank them. Now that this is finished, I look forward to making it up to them.

Fort Collins, Colorado

This page intentionally left blank

CHAPTER

Boundary-Scan Basics and Vocabulary

Boundary-Scan, formally known1 as IEEE/ANSI Standard 1149.1-1990 [IEEE90,


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
complex 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
computing: Garbage In, Garbage Out. The net result will be difficulty or even
1

Informally, the Standard is often referred to as the JTAG proposal, due to its history of
development. 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.

Boundary-Scan Basics and Vocabulary

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 five years, a
standard be updated if necessary and balloted again. When it passes ballot, it gets a
new suffix. During the five-year cycle, up to two Supplements may be issued as
separate documents that give clarifications and/or corrections to the standard. The
original Standard [IEEE90] was issued in 1990. Supplement A appeared in 1993
[IEEE93] and contained 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
Chapter 2) known as BSDL. At this writing, the next reissue of the Standard is being
brought to ballot. This should end up with a 1999 suffix. 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 and 1149.4 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
economical 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 mockups. 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
2

In this portion of this book, the term Standard shall refer to 1149.1. Later we will switch
our attention to 1149.4.
3

There were many examples of proprietary test systems in existence well before this time,
typically at the larger, vertically integrated electronics manufacturers.

The Boundary-Scan Handbook

newly manufactured boards and indeed, this is still widely in use today for final
4
assurance 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, edgeconnector 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 observation 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
possible6 within a circuit.7 Worse, it is often the case that the original designer was
4

The quality of this assurance varies wildly from place to place. In some instances, the
effectiveness is good. In other cases, this last test step may be nearly useless, serving mainly
as a psychological comfort, or the fulfillment of some contractual agreement.
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.

Boundary-Scan Basics and Vocabulary

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.
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, todays simulation tools have made significant strides in
catching up with IC technology; second, the successor to functional testing (InCircuit 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


latter 1970s; In-Circuit testing. The key concept (shown in Figure 1-1) was that
accessing the circuit via the edge-connector was too limiting. What if we could
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 InCircuit 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.)

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.

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 todays logic families.

The Boundary-Scan Handbook

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
Figure 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-holemounted 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 InCircuit 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 further

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. Todays nails are usually
targeted at specific test pads and have a single (very) sharp point.

Boundary-Scan Basics and Vocabulary

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-

The Boundary-Scan Handbook

layer vias10 or deliberately placed test pads. (See [Bull87] for a practical analysis of
SMT probing.) This necessitates having precise X-Y coordinate location data for all
test points and vias, not just the package pins.
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-1990

IEEE Standard 1149.1-1990 [IEEE90] 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
independent 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.
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
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.

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.

Boundary-Scan Basics and Vocabulary

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
fashion. 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.)
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 necessary
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 Chapter 4, 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 Figure 1-3. First, four (optionally, five) new
package 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 onchip Boundary-Scan logic.

The Boundary-Scan Handbook

10

Boundary-Scan Basics and Vocabulary

The protocol is driven by two of the pins (three if the optional Test Reset
TRST*12 input pin is included 13). 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 high14 if they are unconnected
(intentionally or due to a fault). This requirement enhances system reliability (as will
be seen) since these 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 communication 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
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 userdefined data registers.

1.3.1

The TAP Controller

The TAP controller is a finite state machine with a state diagram containing
sixteen (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.
12

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.

13

Making TRST* optional allows the tradeoff of having an asynchronous reset for the TAP
versus the cost of adding a fifth pin.

14

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.

The Boundary-Scan Handbook

11

The state transition diagram is shown in Figure 1-4. It is the fundamental


roadmap 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 TESTLOGIC-RESET state.

Looking at Figure 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.

12

Boundary-Scan Basics and Vocabulary

They behave in an otherwise identical fashion that greatly simplifies understanding


them. The purpose of each state follows.

TEST-LOGIC-RESET
This is the reset state. In this controller state, the test logic is disabled so that normal
operation of the ICs system circuitry can proceed unhindered. The Instruction
Register is initialized to contain the IDCODE instruction (described in 1.4.2) if the
component contains a Device Identification Register or the BYPASS instruction (see
1.4.1) if the component does not contain a Device Identification Register. Regardless
of the controller's original state, it will enter TEST-LOGIC-RESET when TMS is
held high for at least five rising edges of TCK15(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.

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-DRSCAN state.
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
1.5.3) causes a self-test on the ICs system circuitry to execute. Self-tests selected by
other instructions can also be designed to execute in this state. For instructions that
do not cause functions to execute in this state, all test data registers selected by the
current instruction retain their previous states.

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.

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.

15

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.

The Boundary-Scan Handbook

13

CAPTURE-IR
In this controller state, the shift-register16 contained in the Instruction Register
parallel loads a pattern of fixed logic values on the rising edge of TCK. The two
least significant bits17 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 Chapters 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.

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 EXIT1IR state if TMS is high or remains in the SHIFT-IR state if TMS is low. By staying
in SHIFT-IR, a long sequence of instruction bits can be shifted into the instruction
register.
As can be seen by examining Figure 1-4, it is possible to return to SHIFT-IR by
passing to the EXIT1-IR, PAUSE-IR and EXIT2-IR states. This is important if an
external controller (called a Boundary-Scan master, see section 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-IR 18 while the next portion of shift data is prepared.

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
process. If TMS is held low, the controller enters the PAUSE-IR state.

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 tester

16

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.
17

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.
18

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.

14

Boundary-Scan Basics and Vocabulary

memory. The controller remains in this state while TMS is low. When TMS goes
high, the controller moves on to the EXIT2-IR state.

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.

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.

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.

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 Figure 1-4, it is possible to return to SHIFT-DR by
passing to the EXIT1-DR, PAUSE-DR and EXIT-DR states. This is important if an
external controller (called a Boundary-Scan master, see section 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-DR 19 while the next portion of shift data is prepared.

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.
19

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.

The Boundary-Scan Handbook

15

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.

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.

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
transferring data from the shift portion of the shift register to the hold rank
occurs on the falling edge of TCK. Thus, a write operation20 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.
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:
20

The meaning of "write" operation will become clearer in the description of the Boundary
Register.

16

Boundary-Scan Basics and Vocabulary


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.

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 Figure 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
21
output latch . 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.)
Many 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.

21

The parallel output stage can be implemented with a simpler latch. The shift register
element must be a full edge-triggered design.

The Boundary-Scan Handbook

17

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 section 3.2.1 on page 119.) 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.

18

Boundary-Scan Basics and Vocabulary

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 higherorder 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 fix
at least some of the higher-order bits. (See section 3.2.1 on Integrity Testing in
Chapter 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 TESTLOGIC-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.

The Boundary-Scan Handbook

19

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

20

Boundary-Scan Basics and Vocabulary

input and output of the Instruction Registers 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.3

Data Registers

All Boundary-Scan instructions set operational modes that place a selected data
register between TDI and TDO.22 This register is referred to as the target register.
This preserves a fundamental notion of Boundary-Scan; that TDI and TDO always
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 Figure 1-5 on page 17. Some data
registers 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.

Bypass Register
One mandatory register is the Bypass Register. The Bypass Register is a simple
register that doesnt require a parallel hold rank. This register consists of only one
scan cell. When selected by the BYPASS instruction (see 1.4.1), the Bypass Register
shortens the shift path within an IC to a single cell. This is useful for reducing 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 section 3.2.1).

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 1.4.2) and USERCODE
instruction (see 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 assignment of this code is discussed in sections 1.4.2 and 1.4.3. This code
will be useful for chain integrity testing (see 3.2.1) as well as for simply identifying
the IC.
22

However, if an instruction is marked private then the size and purpose of a target register
may or may not be documented. (See section 2.3.12.)

The Boundary-Scan Handbook

21

Boundary register
Most important is the Boundary Register, which has a boundary-scan cell 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 ICs input and output pins.
The Boundary Register is a mandatory feature of IEEE 1149.1 and is covered in
more detail in section 1.3.4 that follows.

User-Defined Registers
The standard also allows designers to implement user-defined registers. These
registers 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.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 Figure 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.

22

Boundary-Scan Basics and Vocabulary

In Figure 1-7 the signals labeled Shift In and Shift Out are the serial inputs
and outputs of the Boundary Register forming the shift path. All other signals route
control signals from the TAP Controller into the cell.

The Boundary-Scan Handbook

23

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 Figure 1-8. Second, you can use a single, somewhat more
complex cell to perform both functions as shown in the lower half of Figure 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

24

Boundary-Scan Basics and Vocabulary

a single control cell to fan out to multiple driver enables, though when this is done,
23
all drivers must behave identically to the value stored in the control cell.
Ignoring the control cell, the reversible cell shown in Figure 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 Figure 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 beneficial.
Shorter registers take less time (and disc space!) to load and unload.
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 programmed
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 Figure 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
24
bidirectional cell design now considered flawed because it lacked this important
capability. Supplement A [IEEE93] 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. The cell design in Figure 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 Figure 1-11 will compensate for
an inverting output buffer.

23

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

The flawed cell is named BC_6 in BSDL. The improved cell is called BC_7.

The Boundary-Scan Handbook

25

26

Boundary-Scan Basics and Vocabulary

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, FPGA, (see section 1.3.7) where bidirectional
Boundary Register resources are allocated to 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
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 Figure 1-12 to denote a Boundary Register cell.

The Boundary-Scan Handbook

27

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 observeonly cell that does not have an update flip-flop.

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 conceivably myriad 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 Figure 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 Figure 1-13.

28

Boundary-Scan Basics and Vocabulary

This design is essentially the same as that in Figure 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 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,
converting it into a latch that serves as the update latch (UPD).25 The claim is made
(arguably) that if you didnt know this was the actual implementation, you would
conclude that the structure of Figure 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
stressful endeavor. However, a momentary glitch presented to the Whetsel output
26
(perhaps even a line reflection) could conceivably cause the output to toggle. 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 deliberately ignoring the figures in 1149.1 and synthesizing a cell from the rules
alone.
25

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.

26

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 successively 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.

The Boundary-Scan Handbook

1.3.6

29

Architecture Summary

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


There is a Test Access Port (TAP) Controller, consisting of a sixteen-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 machinethe one the designer originally
created. A block diagram of this overall architecture is given in Figure 1-14.

30

Boundary-Scan Basics and Vocabulary

Notice also in Figure 1-14 that TDO is synchronized by an additional register


stage clocked by the falling edge of TCK. This ensures that all transitions on TDO
occur TCK cycle after TDI bits are read in.

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 memory. If
desired, new logic can be programmed in at any time. (At this writing, there is a
standardization working group defining an 1149.1-based protocol for programming
these devices discussed in section 4.9.)
Field-programmable ICs often cause severe testing problems for board test. By
their very nature, their logic is fluid and changeable. Preparation of conventional InCircuit 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.
Field-programmable ICs seem to 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 hardwired Boundary-Scan facility.
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 subsequent
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 Figure 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)27 which are
general 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.
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
27

See also the notion of a Digital Boundary Module introduced in section 7.2.5 on page 242
by the 1149.4 standard.

The Boundary-Scan Handbook

31

Boundary Register cells to become internal cells. For example, if an IOB is


programmed 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 section 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 Figure 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
implement 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.
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 Chapter 4.

32

Boundary-Scan Basics and Vocabulary

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.28
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
multiple chains.

The Standard issued in 1990 shows some additional chain configurations that we
call Siamese 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.

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,
28

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*.

The Boundary-Scan Handbook

33
29

board or system, as long as we utilize only the Non-Invasive modes 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
register 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
30
patterns may also decode to BYPASS 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 Figure 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 (sixteen bits) are a part number assigned by the
manufacturer. Bits 11 to 1 (eleven bits) are a manufacturers identity number31
derived [IEEE90] from the JEDEC (the Joint Electron Device Engineering Council)
code32 [JEDE86]. The IDCODE instruction allows a component to be identified via
the Boundary-Scan port.

29

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.
30

The Standard also states that all unused instruction codes not declared to be private must
also decode to BYPASS.
31

There is a code (00001111111) reserved by 1149.1 and considered an illegal


manufacturers 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.
32

The actual list of manufacturers 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.

34

Boundary-Scan Basics and Vocabulary

What about second-source manufacturers? It is expected that a second-sourced


IC will have a different IDCODE value33 (at least different in the manufacturers
identification) than the original IC. There is provision in the BSDL language (see
section 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 reverseengineered 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 12) 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 interrogation of a component or chain of components. Blind
interrogation can be done with no knowledge of any Boundary-Scan devices
instruction register implementation or opcode assignments. Those possessing
IDCODEs indicate so by first shifting 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.

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
instruction 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 manufacture
of the IC (or board or system), the USERCODE function can be used to identify the
33

This is much easier to accomplish if a secondsource agreement is based upon the exchange
of design data (that can be re-synthesized) rather than based upon exchanging mask data.

35

The Boundary-Scan Handbook

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
34

The SAMPLE instruction is a mandatory instruction , 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 Figure 1-7
(page 22); 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 functionality in a digital system using SAMPLE. (See the
discussion in section 4.2 for some practical issues regarding the use of SAMPLE.)

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 Figure 1-7 (page 22); 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 Figure 1-7, page 22) 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
section 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
34

SAMPLE and PRELOAD, in previous releases of the Standard since the beginning
[IEEE90], were one instruction with one opcode. (They were called SAMPLE/PRELOAD.)
In a long ranging debate, the 1149.1 Working Group has now divorced the two instructions so
that each can be independently 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 subtle 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.

36

Boundary-Scan Basics and Vocabulary

functionality of PRELOAD to be merged with the functionality of SAMPLE such


that the two instructions need only consume one instruction bit pattern. (See the
discussion in footnote 34.)

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 ICs test logic back into non-invasive mode.
What happens to an IC that has been held in a safe RESET state when the PinPermission mode is departed; for example, when TEST-LOGIC-RESET is entered?
This is a serious problem (the Lobotomy problem) 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 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
pins 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 allzero 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 zeros into one (or more) ICs 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 Boundary-Scan Handbook

37

The EXTEST instruction targets the Boundary Register between TDI and TDO.
At the CAPTURE-DR state, all IC inputs35 are captured in their respective Boundary
Register cells.36 Looking at Figure 1-7 on page 22, the multiplexer Mode signal is set
to 1. Because the cell output multiplexers are reading the UPD flip-flops, all IC
outputs 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.

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 values37 while the System Logic is being tested. The second
choice is to place all system outputs (including 2-state drivers) in a disabled, nondriving state. Whichever option is chosen, it must be applied uniformly to all IC
pins.
INTEST can be used to apply IC tests38 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 Register39 if the first output
35

Also, input cells on bidirectional I/O pins will capture their states.

36

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 section 5.1.5 on
page 176) if INTEST is not implemented.
37

This option must be chosen if a merger of EXTEST and INTEST behavior is desired.

38

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.
39

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.

38

Boundary-Scan Basics and Vocabulary

control 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. 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
specify 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.
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
operation. 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.

The Boundary-Scan Handbook

1.5.4

39

HIGHZ

The HIGHZ instruction was introduced with the 1993 supplement to the Standard
[IEEE93]. It is an optional instruction and the Standard makes no requirement 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 OpenEmitter drivers, the non-driving state is selected.) In this condition, In-Circuit
overdrive is not needed to gain control of the ICs output pins. This switching to a
disabled state occurs when HIGHZ becomes effective, upon passing through
UPDATE-IR.

1.5.5

CLAMP

The CLAMP instruction was introduced with the 1993 supplement of the Standard
[IEEE93]. 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 ICs 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
necessary to force static 0s or ls on selected nodes in order to set up testable
conditions 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 performed
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
example. 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 Figure l-12(b)
on page 27.
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.

40

Boundary-Scan Basics and Vocabulary

The Standard does allow an exception; if a component pin is a clock then a observeonly 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 function
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
properly documented (see section 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 conditions 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.
40

Consider the Texas Instruments 74BCT8244 [Texa91 ]. 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
40

This IC is one of several in a family (called the SCOPE octals) that all implement the same
extensions. SCOPE is a trademark of Texas Instruments.

The Boundary-Scan Handbook

41

activate. For example, the Boundary Register can be configured as a Linear


Feedback Shift Register 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
communications 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 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 [IEEE93], that other
testing technologies might exist within an IC. Notably, internal scan methodologies
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 IBMs 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 section
2.3.9.) Today, compliance enabling is a recognized condition for some ICs and

42

Boundary-Scan Basics and Vocabulary

software should be able, when notified, to handle many of the implications. See
section 5.2.5 for more discussion.

1.8

COSTS AND BENEFITS

On first examination of the structure in Figure 1-14 (page 29), it certainly looks like
the System Logic is dwarfed by Boundary-Scan circuit overhead. Indeed, early
criticism 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 BoundaryScan, you can get a feel for what the overhead penalties are.

1.8.1

Costs

First, consider the Texas Instruments 74BCT8244 Octal Buffer with Boundary-Scan
[Texa91]. 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 twenty-four 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
implementation. 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 percent. For dense IC
designs such as CMOS VLSI, the gate overhead41 due to Boundary-Scan will be
small.

41

Another concern is the routing of global signals such as ClockDR, ShiftDR, UpdateDR and
Mode (see Figure 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.

The Boundary-Scan Handbook

43

Consider the problem of inserted delay. Figure 1-7 (page 22) 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
42
multiplexer to be eliminated. 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.
In reality, merging its function with the output driver can minimize the multiplexer
delay. That is, the multiplexer shown in Figure 1-7 (page 22) is a logical
representation of the cell design and not 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, including
the Pentium Pro has contained 1149.1. IC designers committed to implementing
Boundary-Scan successfully can greatly reduce the inserted delay penalty by clever
design.
Another cost of Boundary-Scan is increased design time. This has been
aggravated by the lack of tools that support Boundary-Scan designs. This problem is
being solved today, as several EDA design tool vendors such as Cadence, Compass
Design, LogicVision, Mentor Graphics and Synopsys, to name five. The ATE
community has been offering test equipment and supporting software for BoundaryScan 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
manufacturer 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 hasnt 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.43

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
42

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.
43

Indeed, if more people are wary, improvements will come faster!

44

Boundary-Scan Basics and Vocabulary

economics of producing products. Lab prototypes of a new product may promise


incredible performance for a modest price, but the realities of volume production
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:
44

Don't be silicon-wise, but system-foolish.


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 SurfaceMount Technology (SMT), Application Specific ICs, and they are increasing
component 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
Figure 1-19 for a possible scenario.

In this scenario, company X introduces its next product (2), without BoundaryScan, promptly in 1997. These are followed regularly every year by products (3)
44

I am told that Vishwani Agrawal originated this phrase. It beautifully sums up the fact that
placing 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.

The Boundary-Scan Handbook

45

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 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 Ys 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 old way, and has
little time to try new approaches. Company Y introduces products (D) through (F) in
rapid succession, which exceed both the performance and the schedule of company
X.
Does this scenario seem far-fetched. I think not. Other revolutions in the
electronics 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
process 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 eight years now since the ratification of the first IEEE 1149.1 Standard
[IEEE90]. 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 section 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 increasing 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

46

Boundary-Scan Basics and Vocabulary

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
competitive,45 yet they see Boundary-Scan as a way to get ahead in the long term.
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 Moores 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 wasnt
we see today. Yet at this
level, Boundary-Scan technology is quite affordable [Park97]. It can only be getting
cheaper with
and
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
completed in 1995. The brand new IEEE 1149.4, is covered later in this book (see
Chapter 7). The P1149.3 (a system test bus) has long been defunct. In 1997 the
P1149.2 [IEEE92] effort decided to end its quest.
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 control 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 fundamental problem. The work done by Lee Whetsel [Whet95]
(see section 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.
45

MEI is the worlds second largest electronics manufacturer, participating in many consumer
markets with products like handheld video cameras, VCRs, laptop computers, etc.

The Boundary-Scan Handbook

47

The 1149.5 standard is a bus protocol that focuses on high-level systems


testability. 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 section 5.3.1).

This page intentionally left blank

CHAPTER

Boundary-Scan Description Language


(BSDL)

The chapter of IEEE/ANSI Standard 1149.1 titled "Conformance and


Documentation Requirements," [IEEE99] 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 utilizing this data. Software cannot read specification documents
generated by randomly chosen designers, each with a unique interpretation of the
documentation requirements, each with a unique style. On top of this, the propensity
of humans to overlook 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

50

Boundary-Scan Description Language (BSDL)

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
vendors, 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
description 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 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 language
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
languages. 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
practice 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
environments. A BSDL source can be consumed by a VHDL analyzer, which
converts it into a compiled design library. From here, tools specific to BoundaryScan can be created that access the compiled design information. Other tools are free
to access this information (as well as any other information present) to perform
simulation, logic synthesis, 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
1

Even within the VHDL world, there are full and partial implementations of the VHDL
language.

The Boundary-Scan Handbook

51

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 [IEEE93] called IEEE Std
1149.1a-1993 concentrated on improving the clarity of the rules for implementing
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].

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
applications 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 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 section 2.3.3.

The older version of BSDL lacks certain capabilities that may be crucial to your success. For
example, compliance enable pins (see section 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 complex debugging problems. In such cases, you should convert the older BSDL to
the new IEEE form.

52

Boundary-Scan Description Language (BSDL)

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
knowledge 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.
The BSDL description of a compliant components 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 Figure 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 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. 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 Chapter 3.)

The term node refers to an interconnection of component pins. Frequently used synonyms
for node are net, network, signal, trace, track and wire.

The Boundary-Scan Handbook

2.1.2

53

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
compliance. One approach for this is shown in Figure 2-3. In this process, the IC is
conceived and the 1149.1 facility is then added. The full and perfected
implementation of the ICs 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

54

Boundary-Scan Description Language (BSDL)

pattern 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 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 section 5.1.10 on page 180 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 Boundary-Scan Handbook

55

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
purporting to judge compliance.
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
revisions are planned for clarifications. Questions of interpretation are formally
collected 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.
pass this description through a checker and/or test generator from one or more
independent sources.
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
compliance 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
happening. Let us examine one of the first reported synthesis systems [Chil91],
which is diagramed in Figure 2-4.
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.1compliant 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 organization
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.

56

Boundary-Scan Description Language (BSDL)

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
overhead 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
program. 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

The Boundary-Scan Handbook

57

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
compliance enable pins and one compliance enable pattern.
Phase 1 extracts the TAP and verifies the TAP state diagram and timing. It
verifies TAP synchronization and whether the TCK signal can be halted per
the rules. 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
register and various data registers. It does this by a series of deductions driven
by loading the instruction register with required opcodes,4 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 mapping 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.
As you can see, weve come a long way since 1991.

2.2

STRUCTURE OF BSDL

IEEE Std 1149.1b-19945 [IEEE94] describes BSDL in minute detail. (The Appendix
of this book contains a syntax summary of the language.) 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 VHDL [IEEE93b].

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.
5

This supplement to the Standard is included whenever you order a copy of the 1149.1
Standard from the IEEE.

58

Boundary-Scan Description Language (BSDL)

Before jumping in, Ill 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.6 An entity can be
passed formal parameters, again like a subroutine.7 These are called generic
parameters (literally generic). An entity can incorporate external definitions, like the
include process 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_1994. The standard package contains definitions of the
elements 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 [IEEE99] and likely to be adopted by
designers. 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]. 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.
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.

6
7

This is an important point; BSDL is not an executable language, but rather a description.
Again, BSDL uses a generic, but it is used to select among several descriptive options.

The Boundary-Scan Handbook

59

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."

60

Boundary-Scan Description Language (BSDL)

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 "
"that just fits a line."

&

-- shorter string
-- remaining string

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
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 systems 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 systems 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 systems 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 to 65 characters. When
you start getting near 70+ characters, you will find some electronic information

The Boundary-Scan Handbook

61

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;

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
tt174bct8374, reflecting the VHDL requirement that identifiers must start with an
alphanumeric character.) Other statements within the entity body will reference 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>
<logical port description>
<standard use statement>
{<use statements>}
<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>;

The next few subsections describe these statements.

------------------

(see
(see
(see
(see
(see
(see
(see
(see
(see
(see
(see
(see
(see
(see
(see
(see
(see

section
section
section
section
section
section
section
section
section
section
section
section
section
section
section
section
section

2.3.1)
2.3.2)
2.3.3)
2.3.4)
2.3.5)
2.3.6)
2.3.7)
2.3.8)
2.3.9)
2.3.10)
2.3.11)
2.3.12)
2.3.13)
2.3.14)
2.3.15)
2.3.16)
2.3.17)

62

2.3.1

Boundary-Scan Description Language (BSDL)

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
defaults to the string value like "DW" in this example. 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 18x18 pin grid array, then
you could use PGA_18x18 as the value, which obeys the requirements of a VHDL
identifier (for the reason see 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 indicates 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

The Boundary-Scan Handbook

63

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 section 2.3.6) we will see how
these ports are associated with a devices 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.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_1994.all; -- Get Std 1149.1-1994 definitions
This standard use statement must appear in any BSDL description, and must appear
before any other use statement (see 2.3.4). It instructs a VHDL analyzer to look into a
VHDL package named STD_1149_1_1994 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_1994 appears in section 2.6.1 starting on
page 85.)
VHDL, and thus BSDL, is a case-insensitive language. However, practical
limitations 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
computers file system. Thus, the fact that the host computer is running under
Windows-NT (which is case-insensitive) versus UNIX8 (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-

Windows-NT and UNIX are trademarks of their respective owners.

64

Boundary-Scan Description Language (BSDL)

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 package.
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. Todays version
may contain new constructs that did not exist in a previous version. In some cases, a
9
construct may be obsoleted, as has actually happened. 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 more than one may be added. If a designer were to
invent new cell definitions, these could be placed in a new package and referenced
with a use statement, like so.
use My_New_Cells.all;

-- Get new Boundary Register cell info

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

2.3.5

Component Conformance Statement

The component conformance statement10 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 and STD_1149_1_1999 reflecting the 1993
Supplement A and the most current issue of the standard.11 Future releases of BSDL
will most likely be coordinated with any future changes or additions to the Standard

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.
10

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.

11

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.

The Boundary-Scan Handbook

65

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
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.12 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
packages. 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(l) 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
12

Fortunately, this feature was quite rare. If it had proliferated, it would have seriously
compromised the ability of 1149.1 to support interconnection tests.

66

Boundary-Scan Description Language (BSDL)

identifiers. They cannot be named 13H or 7B because these are not legal VHDL
identifiers.
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 ports may be handled this way; all other pins
must be accounted for in all pin mappings. It is highly recommended 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 pins13 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 immunity 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
(considerable) cost of doubling the pin count.
Differential signaling needs special consideration in Boundary-Scan
implementations. 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. BSDLs 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)))," &
"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))) ";
13

The 1149.1 Standard makes no provision for differential TAP pins.

The Boundary-Scan Handbook

67

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 mentioned in a
pair is the plus pin and the second is the minus pin.14 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 section 2.3.13 on page 72). 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. This reflects the fact that
only one Boundary Register cell is associated with each pair of differential pins. (See
Figure 4-10 on page 156.) 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
attribute
attribute
attribute

TAP_SCAN_IN
TAP_SCAN_MODE
TAP_SCAN_OUT
TAP_SCAN_CLOCK

of
of
of
of

TDI
TMS
TMS
TCK

:
:
:
:

signal
signal
signal
signal

is
is
is
is

true;
true;
true;
(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;
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 identifies it as
being the Test Data Output (TDO). There is no significance to these attributes 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
containing two fields. The first (a real number) is the maximum TCK clocking
14

The choice of port names used here helps a reader maintain the plus and minus
relationship, but is not required by BSDL.

68

Boundary-Scan Description Language (BSDL)

frequency15 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
compliant implementation may not specify HIGH as the only allowable stop state.

2.3.9

Compliance Enable Description

Compliance enable pins were described in section 1.7 on page 41. 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
subordinate 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 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 2.3.8) nor can they
appear in the subsequent Boundary Register description (see 2.3.13).
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 example
is the programming control pins on Field-Programmable devices.16 The compliance
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.

15

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 devices 1149.1 circuitry to
perform at the same frequency as the mission circuitry.

16

Field-Programmable devices are now receiving special attention in 1149.1 circles, see
section 4.9 on page 160.

The Boundary-Scan Handbook

2.3.10

69

Instruction Register Description

The next major piece of information required in a BSDL description covers the TAP
instructions that are implemented by the ICs 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 capture 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
-- BCR Scan test
"SCANCT (00001111, 10001111) ";
attribute INSTRUCTION_CAPTURE of ttl74bct8374 : entity is
"10000001";
attribute INSTRUCTION_PRIVATE of ttl74bct837417 : entity is
"CELLTST";

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


Register, which must be two or greater. Next, the instruction mnemonics are identified
and the bit patterns (opcodes) that decode to them are listed in the
INSTRUCTIONJDPCODE attribute. There may be more than one opcode listed for
one mnemonic18. 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
documenting what is mandated by the Standard, BYPASS documentation for the allone opcode could be left out. The Standard, in its initial release, specified that
17

The 74bct8374 in reality does not have any private instructions. This example is used to
illustrate the syntax.
18
It may be necessary to use "x" characters to specify dont care locations in an opcode. When
this is done, software that consumes BSDL must check that ambiguous decodes have not been
erroneously specified. In this example, the line defining EXTEST could be written "EXTEST
(x0000000),".

Boundary-Scan Description Language (BSDL)

70

19

EXTEST must have an all-zero opcode but this was relaxed in [IEEE99]. Because
EXTEST, SAMPLE and PRELOAD20 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
optionally 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. (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
"0011" &
"1111000011110000" &
"00000000111" &
"1";

of
-----

My_IC : entity is
4-bit version number
16-bit part number
11-bit manufacturer's number
mandatory LSB of 1

attribute USERCODE_REGISTER of My_IC : entity is


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

19

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.
20

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 [IEEE99]
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).

The Boundary-Scan Handbook

71

The character X may appear in the 32-bit fields indicating dont care bit positions.
This could be used, for example, to null out some of the manufacturers 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 examples 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"
"0000"
"0011"
"0000"

2.3.12

&
&
&
&

"1010"
"0000"
"1000"
"0000"

&
&
&
&

"0001"
"1111"
"0001"
"1111"

&
&
&
&

"1011" &
"1111," &
"1011" &
"0011";

-- First code
-- Second code

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)";

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.21 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 bits22 that a
register captures (when passing the CAPTURE-DR state) for a given instruction.
21

The Standard states that designers may add new data registers, or they may access existing
registers, 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.

22
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 omitted altogether.

72

Boundary-Scan Description Language (BSDL)

Looking at the example above, the two-bit BCR register captures a 0x pattern23
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 capture 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 section 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
applications 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.
The second attribute, BOUNDARY_REGISTER, is an array of data records. Each
record has a cell number field 24 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 information
for cells devoted to IC outputs regarding how those outputs are disabled. This is how
these attributes look for the example component.

23

Using the established BSDL convention, the capture pattern has its rightmost bit closest to
TDO and the leftmost bit closest to TDI.
24

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.

The Boundary-Scan Handbook

73

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,
X)," &
input,
"16 (BC_1, OC_NEG, input,
X)," & -- Merged In/Cntrl
"16 (BC_1, *,
control, 0)," & -- See section 2.4
X)," &
"15 (BC_1, D(l),
input,
X)," &
"14 (BC_1, D(2),
input,
X)," &
"13 (BC_1, D(3),
input,
"12 (BC_1, D(4),
X)," &
input,
"11 (BC_1, D(5),
X)," &
input,
X)," &
input,
"10 (BC_1, D(6),
input,
X)," &
"9 (BC_1, D(7),
&
input,
X),
"8 (BC_1, D(8),
"7 (BC_1, Q(1),
output3, X, 16, 0, Z)," &
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),
"1 (BC_1, Q(7),
output3, X, 16, 0, Z)," &
output3, X, 16, 0, Z)";
"0 (BC_1, Q(8),

The fields in Boundary Register description structure are defined in the following
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 sections 2.3.3 and 2.3.4 beginning on page 63.) In this example, cell
design BC_1 is referenced from the standard package STD_1149_1_1999.
Field 2: This is the port field where a signal from the port statement25 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,
output3, 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
algorithm. An x indicates that it doesnt 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.
25

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).

74

Boundary-Scan Description Language (BSDL)

This ends the first four fields required of every cell description record. Some
records will have the next three fields as well.
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 section 2.4 on
page 78 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

The Boundary-Scan Handbook

75

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 section 2.3.8).
Compliance enable pins (see section 2.3.9).
Negative (or Minus) representatives of grouped port pins. (See section
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
common sense. For more intricate designs, you should take BSDL guidance directly
from the Standard.

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.

76

Boundary-Scan Description Language (BSDL)

The RUNBIST_EXECUTION attribute is optional, even if RUNBIST


functionality is implemented in an IC. It contains three pieces of information as
shown in this example:
attribute RUNBIST_EXECUTION of BIST_IC : entity is
"ait_Duration (1. 0e-4) , "
-- Duration of test
-- Condition of Output pins
"Observing HIGHZ At_Pins,"
-- Result of passing test
"Expec t_Data 0011001";
The first piece of information is the duration of test clause. A RUNBIST instruction
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
example was
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 (l.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, or they take on states defined by the Boundary Register,
which should be initialized by a PRELOAD operation before RUNBIST is executed.
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 section 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,


particularly 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 a INTEST sequence is derived from a BSDL
description.
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

26

All pins, including those whose system nature is to be 2-state pins.

The Boundary-Scan Handbook

77

These two pieces of information are identical to those used by the description of
RUNBIST execution (see 2.3.14).
The actual patterns that one would apply via INTEST must come from an
external source such as the design verification tests for an IC. BSDL does not
provide a means of describing these patterns. The INTEST_EXECUTION attribute
documents 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 include 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 section 2.6.5 on page 100) 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
processing 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.

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.";

78

Boundary-Scan Description Language (BSDL)

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
asymmetrical 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 73)
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.

The Boundary-Scan Handbook

79

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 .
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.
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),"&
3,
Z)," &
"2 (BC_6, BIDIR1, bidir,
X,
0,
"3 (BC_2, *
control,
0)," &
"4 (BC_1, *
control,
0)," &
"5 (BC_1, BIDIR3, input,
X) ," &
"5 (BC_1, BIDIR2, output3,
Z)," &
X,
7,
1,
"6 (BC_1, BIDIR2, input,
X)," &
4,
Z)," &
"6 (BC_1, BIDIR3, output3,
X,
0,
"7 (BC_1, * /
control,
1)," &
"8 (BC_1, IN2,
input,
X)," &
"9 (BC_1, IN1,
input,
X)," &
"9 (BC_1, OUT1,
Z)";
output3,
X,
0,
0,

27

In section 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

Boundary-Scan Description Language (BSDL)

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 figure Figure 1-9 on page 25) used on the bidirectional signal BIDIR1.
Cell 1 is discussed in the next section (2.4.2).
Cell 2 is the bidirectional cell in the lower half of Figure 1-9 on page 25. 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 section 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 Figure 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 Figure 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.

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 simple octal
transceiver will be quite similar to that of a large 32-bit microprocessor.

The Boundary-Scan Handbook

81

82

Boundary-Scan Description Language (BSDL)

The example BSDL description for Texas Instruments 74BCT8374 shown in


Figure 2-9 looks like this in its entirety.

The Boundary-Scan Handbook

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_1999.all;

-- Get Std 1149.1-1999 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
attribute
attribute
attribute

TAP_SCAN_IN
TAP_SCAN_MODE
TAP_SCAN_OUT
TAP_SCAN_CLOCK

of
of
of
of

TDI
TMS
TOO
TCK

:
:
:
:

signal
signal
signal
signal

is
is
is
is

true;
true;
true;
(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 are merged
"SAMPLE (00000010, 10000010),
&
"INTEST (00000011, 10000011),
&
"HIGHZ (00000110, 10000110),
Boundary Hi-Z
&
"CLAMP (00000111, 10000111) ,
Boundary 1/0/Z
&
"RUNT
Boundary run test
(00001001, 10001001),
Boundary read
&
"READBN (00001010, 10001010) ,
&
Boundary read test
"READBT (00001011, 10001011),
"CELLTST (00001100, 10001100) ,
Boundary self test
&

84

Boundary-Scan Description Language (BSDL)


"TOPHIP (00001101, 10001101),"
"SCANCN (00001110, 10001110),"
"SCANCT (00001111, 10001111)";

&
&

-- Boundary toggle out


-- BCR Scan normal
-- 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,
& -- Merged In/Cntrl
X),"
"16 (BC_1, *
control, 0)," & -- Merged In/Cntrl
"15 (BC_1, D(1),
input,
X)," &
"14 (BC_1, D(2),
&
input,
X),"
X)," &
"13 (BC_1, D(3),
input,
"12 (BC_1, D(4),
input,
X)," &
"11 (BC_1, D(5),
X),"
input,
&
X),"
"10 (BC_1, D(6),
input,
&
"9 (BC_1, D(7),
input,
X)," &
"8 (BC_1, D(8),
input,
X)," &
"7 (BC_1, Q(1),
outputs, x, 16, 0, Z)," &
"6 (BC_1, Q(2),
outputs, X, 16, 0, Z)," &
"5 (BC_1, Q(3),
outputs, x, 16, 0, Z)," &
"4 (BC_1, Q(4),
outputs, x, 16, 0, Z)," &
"3 (BC_1, Q(5),
outputs, x, 16, 0, Z), " &
"2 (BC_1, Q(6),
outputs, x, 16, 0, Z)," &
"1 (BC_1, Q(7),
outputs, 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


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 section 2.3. There, the statement "use

The Boundary-Scan Handbook

85

STD_1149_l_1999.all (section 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 (reanalyzed 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 constants contents is
changed, everything that references the associated package does not have to be reanalyzed. 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_1999, which has an associated package
body that contains (to date) seven 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_1999

The information contained in STD_1149_1_1999 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.
package STD_1149_1_1999 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
attribute
attribute
attribute
attribute

TAP_SCAN_IN
:
TAP_SCAN_OUT :
TAP_SCAN_CLOCK :
TAP_SCAN_MODE :
TAP_SCAN_RESET:

boolean;
boolean;
CLOCK_INFO;
boolean;
boolean;

86

Boundary-Scan Description Language (BSDL)

-- 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
constant
constant
constant
constant
constant
constant
constant

BC_0
BC_1
BC_2
BC_3
BC_4
BC_5
BC_6
BC_7

CELL_INFO;
CELL_INFO;
CELL_INFO;
CELL_INFO;
CELL_INFO;
CELL_INFO;
CELL_INFO;
CELL_INFO;

-- Boundary register declarations


attribute BOUNDARY_LENGTH : integer;
attribute BOUNDARY_REGISTER : string;
-- Miscellaneous
attribute PORT_GROUPING : string;
attribute RUNBIST_EXECUTION : string;
attribute INTEST_EXECUTION : string;

The Boundary-Scan Handbook

87

subtype BSDL_EXTENSION is string;


attribute COMPLIANCE_PATTERNS : string;
attribute DESIGN_WARNING : string;
end STD_1149_1_1999;

-- End of 1149.1-1999 Package

package body STD_1149_1_1999 is

-- Standard boundary cells

-- Generic cell capturing minimum allowed data


constant BC_0 : CELL_INFO :=
((INPUT,
EXTEST, PI),
(INPUT,
SAMPLE, PI),
(INPUT,
INTEST, X),
(OUTPUT3, EXTEST, X),
(OUTPUT3, SAMPLE, PI),
(OUTPUT3, INTEST, PI),
(CONTROL, EXTEST, X),
(CONTROL, SAMPLE, PI),
(CONTROL, INTEST, PI),
(BIDIR_IN,EXTEST, PI),
(BIDIR_IN,SAMPLE, PI),
(BIDIR_IN,INTEST, X ),
(OBSERVE_ONLY, SAMPLE, PI),

(OUTPUT2, EXTEST, X),


(OUTPUT2, SAMPLE, PI),
(OUTPUT2, INTEST, PI),
(INTERNAL, EXTEST, X),
(INTERNAL, SAMPLE, X),
(INTERNAL, INTEST, X),
(CONTROLR, EXTEST, X),
(CONTROLR, SAMPLE, PI),
(CONTROLR, INTEST, PI),
(BIDIR_OUT, EXTEST, X ),
(BIDIR_OUT, SAMPLE, PI),
(BIDIR_OUT, INTEST, PI),
(OBSERVE_ONLY, EXTEST, PI) );

-- Description for the cell shown in Figure 2-11 on page 92.


constant BC_1 : CELL_INFO :=
((INPUT,
EXTEST, PI), (OUTPUT2,
(INPUT,
SAMPLE, PI), (OUTPUT2,
(INPUT,
INTEST, PI), (OUTPUT2,
(OUTPUT3, EXTEST, PI), (INTERNAL,
(OUTPUT3, SAMPLE, PI), (INTERNAL,
(OUTPUT3, INTEST, PI), (INTERNAL,
(CONTROL, EXTEST, PI), (CONTROLR,
(CONTROL, SAMPLE, PI), (CONTROLR,
(CONTROL, INTEST, PI), (CONTROLR,

EXTEST, PI),
SAMPLE, PI),
INTEST, PI),
EXTEST, PI),
SAMPLE, PI),
INTEST, PI),
EXTEST, PI),
SAMPLE, PI),
INTEST, PI) );

-- Description for the cell shown in Figure 2-12 on page 93.


constant BC_2 : CELL_INFO
((INPUT,
EXTEST, PI),
(INPUT,
SAMPLE, PI),
(INPUT,
INTEST, UPD),
(OUTPUT3, EXTEST, UPD),
(OUTPUT3, SAMPLE, PI),
(OUTPUT3, INTEST, PI),
(CONTROL, EXTEST, UPD),
(CONTROL, SAMPLE, PI),
(CONTROL, INTEST, PI),

:=
(OUTPUT2, EXTEST,
UPD),
(OUTPUT2, SAMPLE,
PI),
-- Intest on output2 not supported
(INTERNAL, EXTEST, PI),
(INTERNAL, SAMPLE, PI),
(INTERNAL, INTEST, UPD),
(CONTROLR, EXTEST, UPD),
(CONTROLR, SAMPLE, PI),
(CONTROLR, INTEST, PI) );

-- Description for the cell shown in Figure 2-13 on page 94.

88

Boundary-Scan Description Language (BSDL)

constant BC_3 : CELL_INFO :=


((INPUT, EXTEST, PI),
(INTERNAL, EXTEST,
(INPUT, SAMPLE, PI),
(INTERNAL, SAMPLE,
(INPUT, INTEST, PI),
(INTERNAL, INTEST,

PI),
PI),
PI) );

-- Description for the cell shown in Figure 2-14 on page 95.


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 the cell shown in Figure 2-15 on page 95.
constant BC_5 : CELL_INFO
((INPUT, EXTEST, PI),
(INPUT, SAMPLE, PI),
(INPUT, INTEST, UPD),

:=
(CONTROL, EXTEST, PI),
(CONTROL, SAMPLE, PI),
(CONTROL, INTEST, UPD) );

-- Description for a reversible cell. Used for backward


-- compatibility only.
-- !! 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) );
-- !! Recommended over cell BC_6!!
-- The BC_7 design will always monitor the driver output,
-- as shown in Figure 2-16 on page 97.
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) );
end STD_1149_1_1999;

-- End of IEEE Std 1149.1-1999 Body

In the above set of definitions for Boundary Register cells (in the package body)
you will see comments that call out figure drawings 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 section 2.6.3, and a detailed discussion of how
Boundary Register cells are described in BSDL is given in the next section.

The Boundary-Scan Handbook

2.6.2

89

Cell Description Constants

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


such as STD_1149_1_1999 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 constant is
28
defined. Each CELL_DATA record contains three fields that define how the cell
behaves upon passing through CAPTURE-DR. Each field is an enumerated 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.
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 Figure 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
package.) 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.
28

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.

90

Boundary-Scan Description Language (BSDL)

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 Figure 2-10.

match the capture data sources shown in Figure 2-10. Two of these symbols, PI
(parallel 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 interpreted 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.

The Boundary-Scan Handbook

91

For a bidirectional such as shown in Figure 2-16, the context is complicated 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 operating 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 description, the
function field (see Table 2-2 on page 74) 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 section (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
introduced in the future. 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
architectures 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 ICs 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
reduction 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.

Cell BC_1
This cell architecture is shown in Figure 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
multiplexer in the system signal path that is placed at the exit of the cell to the
Parallel Output.

92

Boundary-Scan Description Language (BSDL)

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 Figure 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 logic29 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.30 (The BC_1 design does require that the system circuitry be
involved in testing these same portions of an input Boundary Register cell.)

29

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 section 1.7 on page 41), then the testability of a given cell design in
1149.1 operation may not be an issue.
30

This feature may not be utilized by ATPG software however. You should investigate the
capabilities of an ATPG algorithm if this feature will be important to you.

The Boundary-Scan Handbook

93

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 support 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.

Cell BC_3
Cell BC_3 shown in Figure 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
circuitry where it might have unwanted effects. However, for some system circuitry
(notably, combinatorial circuitry) this shift noise would have no harmful effects nor

94

Boundary-Scan Description Language (BSDL)

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.

Cell BC_4
Cell BC_4 shown in Figure 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
eliminating 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
31
on any input pin except a system clock input.

31

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.

The Boundary-Scan Handbook

95

Cell BC_4 has no mode signal supplied by the TAP instruction decoder.

Cell BC_5
Cell BC_5 is shown in Figure 2-15. This cell is virtually identical to the BC_2
architecture, but is only used for controlling output driver enables. The difference is
due to the AND function that inserts another control variable (shown as Mode3) into
the signal used to turn a driver on or off.

96

Boundary-Scan Description Language (BSDL)

This new mode signal comes from the TAP instruction decoder just as other
mode signals do. In this example, when Mode3 is low, the associated driver is
disabled. This is used to implement the HIGHZ instruction and the HIGHZ-type
Boundary Register control feature that INTEST and RUNBIST may exhibit32 as
well.

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 discouraging its
further use in Boundary-Scan implementations. The cell architecture called BC_7
should be used in its place.
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 pins driver
is enabled to drive data out. Pin monitoring capability is inherently available in
multi-cell bidirectional structures we saw in Figure 1-8 (page 23) 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 [IEEE93] it has been
discouraged. If you have an older design for Boundary Register cells supporting
bidirectional pins, you should examine them to see if they are indeed utilizing the
33
BC_6 architecture. If so, you should convert them to the BC_7 architecture.
32

HIGHZ behavior also controls two-state outputs which implies a special mode signal for
them as well. However there is no explicit cell design showing this in BSDL since the mode
signal would be passed directly to the output driver rather than the upstream Boundary
Register cell.
33

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 bidirectional 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.

The Boundary-Scan Handbook

97

Cell BC_7
The BC_7 Boundary Register cell architecture shown in Figure 2-16 (in the dotted
line box) is a single data cell that supports bidirectional system pins.

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
lacking in the BC_6 architecture just documented. and is a feature inherent in the
double-celled implementation for a bidirectional pin shown in Figure 1-8 on page
23. 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

98

Boundary-Scan Description Language (BSDL)

requested pin state. This is doubly important when the signal being driven does not
travel to other Boundary-Scan ICs.

The sea of multiplexers in Figure 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 contains
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
34
users of bidirectional pins, you could see savings in cell counts 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 space35 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.

34

The variability in savings is influenced by the number of control cells included to enable
collections of bidirectional pin drivers.
35

It also influences the length of the BSDL used to describe the IC, which you may have to
write!

The Boundary-Scan Handbook

99

Note that the control cell circuitry shown above the dotted line box shown in
Figure 2-16 is a BC_5 control cell design. The entire structure shown is capable of
supporting a complete set of instructions. If, for example, INTEST were not of
36
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 in the BC_5 structure which reduces it to
BC_2.

2.6.4

User-Defined Boundary Cells

Suppose a designer wanted to implement a component that could give an informal selfidentification rather than suffer the overhead of the IDCODE instruction. The designer
could do this by implementing a cell structure such as in Figure 2-17 where a 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
37
cell 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 section 2.3.13 on page 72). BSDL-based software then knows
from the package body that during EXTEST, the cells capture their respective
constants.
36

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.
37

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.

Boundary-Scan Description Language (BSDL)

100

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_1999.all;

constant USER_0
constant USER_1

-- Get definition of "Cell_Info"

: CELL_INFO;
: CELL_INFO;

end USER_PACKAGE;

-- End of User Package

package body USER_PACKAGE is

-- User Boundary Cells

use STD_1149_1_1999.all;
constant USER_0 : CELL_INFO :=
((OUTPUT2, EXTEST, ZERO), (OUTPUT2,
(OUTPUT2, INTEST, PI),
(OUTPUT2,
(OUTPUT3, EXTEST, ZERO), (INTERNAL,
(OUTPUT3, SAMPLE, PI),
(INTERNAL,
(OUTPUT3, INTEST, PI),
(INTERNAL,
(OUTPUT3, RUNBIST, PI),
(INTERNAL,
(CONTROL, EXTEST, ZERO), (CONTROLR,
(CONTROL, SAMPLE, PI),
(CONTROLR,
(CONTROL, INTEST,
(CONTROLR,
PI),
(CONTROL, RUNBIST, PI),
(CONTROLR,

SAMPLE,
RUNBIST,
EXTEST,
SAMPLE,
INTEST,
RUNBIST,
EXTEST,
SAMPLE,
INTEST,
RUNBIST,

PI),
PI),
ZERO),
PI),
PI),
PI),
ZERO),
PI),
PI),
PI) ) ;

constant USER_1 : CELL_INFO :=


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

SAMPLE,
RUNBIST,
EXTEST,
SAMPLE,
INTEST,
RUNBIST,
EXTEST,
SAMPLE,
INTEST,
RUNBIST,

PI),
PI),
ONE),
PI),
PI),
PI),
ONE),
PI),
PI),

end USER_PACKAGE;

2.6.5

PI) );

-- End of User Package Body

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 sections 2.3.4 and
2.3.16) the declarations of the extensions become available to a BSDL description.
Consider this example:

The Boundary-Scan Handbook

101

Package Global_Def is
-- An example BSDL extension package
-- Does not define boundary cells, just extensions
use STD_1149_1_1999.all;
-- Deferred constant declarations go here, if any
attribute First_extension : BSDL_EXTENSION;
attribute Second_extension : BSDL_EXTENSION;
attribute Third_extension : BSDL_EXTENSION;

-- Declare BSDL
-- extensions
-- here.

end Global_Def;
package body Global_Def is
use STD_1149_1_1999.all;
-- Deferred constant definitions go here, if any
end Global_Def;

Any of the three extensions declared in this package are now available for reference
in BSDL descriptions that use this package.

2.7

WRITING BSDL

How does one go about writing a BSDL description? First, you must gather
information 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 template
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
2.3.2) for the entity. You may choose to use the bit_vector shorthand for buses,
or give each pin a unique name.

102

Boundary-Scan Description Language (BSDL)

4.

After the port statement, write the standard use statement (see 2.3.3). You
may need to come back to this spot later to add a user-defined package use
statement (see 2.3.4) if step 13 below turns up any user-defined cell designs.
Write the component conformance statement (see 2.3.5). Remember that this
identifies the release of the Standard that governed the design of the IC.
Write the pin mapping constants for all package configurations (see 2.3.6).
Name these constants with recognizable names such as "PGA_18xl8" or
"PQFP_64." If there is only one constant, consider making the generic
parameter default to this value (see 2.3.1).
Does this device have any differential signals? If so, use a grouped port
statement to describe them (see 2.3.7).
Identify the TAP Port pins. Write the TAP pin attributes. Dont forget TRST*
if it exists. (See 2.3.8.)
This step is very important; if this device has any compliance enable pins, be
sure to document them (see 2.3.9). Lack of this information can cause ugly
debugging problems later.
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 2.3.10.)
Find the Instruction Register capture pattern, the bits it captures at CAPTUREIR. 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
2.3.11.) If any of the instructions are considered private, then write an
Instruction_Private attribute that identifies them.
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 userdefined registers. If any of the user-defined registers capture static bits, denote
this with a captures clause. (See 2.3.12.) If any instructions were marked
private in step 10 above, you may choose to omit them from this attribute.
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_1999, then you will need to write a user-defined supporting
package that gives their behavior (see section 2.6.4 on page 99). This package
might already exist if the IC reuses cell designs from other ICs. Dont forget to
add another "use" statement (see step 4 and 2.3.4) to refer to this new package.
Write the two attributes that describe the Boundary Register (see 2.3.13). They
are Boundary_Length and Boundary_Register.
Does this device support RUNBIST and/or INTEST? Then consider
documenting their behavior with the associated execution statements (see
2.3.14 and 2.3.15).

5.
6.

7.
8.
9.

10.

11.

12.

13.

14.
15.

The Boundary-Scan Handbook

103

16. Do you wish to document any additional data beyond the current definition of
BSDL? If so, consider using BSDL extensions (see 2.3.16) to place this
information within your BSDL file.
17. Does any design-specific information need to be documented so that other
people using this description will be alerted to its existence? If so, consider
adding a Design_Warning attribute (see 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 Chapter
5.
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
38
work reported in [Raym95]. Here, they used a hardware simulation 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 mapping. 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 discover
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 will be essential. Third, this
software will come from many sources crossing boundaries among industry segments.
A standardized description language serves as a canonical form for 1149.1
information. 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.

38

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.

104

Boundary-Scan Description Language (BSDL)


39

At this writing 459 copies of the BSDL Version 0.0 parser have been directly
distributed by Hewlett-Packard to people in countries ranging from Australia to
Yugoslavia. The desire for effortless interchange of 1149.1 data is real.

39

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 augment 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.

CHAPTER

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
outward 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
manufacturing, 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 degrees 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.

106

Boundary-Scan Testing

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 SelfTest 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 BoundaryScan testing will find this problem. If a solder joint is marginal but continuity still
exists, Boundary-Scan will not see a problem.
Boundary-Scan testing is primarily aimed at finding and diagnosing major
manufacturing defects; bad devices, rotated devices, bad solder joints, blown drivers,
and so on. It is not able (without the addition of optional or user-defined capabilities)
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 manufacturing
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 Boundary-Scan Handbook

107

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.
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.
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 attribute INSTRUCTION_CAPTURE. If the
instruction register is N bits long, we cycle back to SHIFT-IR N-1 times, each time
1
presenting a new bit of the instruction code to TDI. The
bit is shifted while
taking the transition to EXIT1-IR..

The bits are shifted in via TDI, starting with the least significant bit.

108

Boundary-Scan Testing

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. 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.

The Boundary-Scan Handbook

109

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.

110

Boundary-Scan Testing

We are then ready to shift this register as shown in Figure 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
2
state. Typically, we want to shift N bits where N is the length of the target register.
While this shifting is occurring, the captured bits are transmitted out by TOO 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
2

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.

The Boundary-Scan Handbook

111

transferred to the parallel hold portion of the target register at UPDATE-DR as in


Figure 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 1.3.3 on page 20 for the construction of a data register.)

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 Figure 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

112

Boundary-Scan Testing

then may shift this data out for examination. The update (write) part of the process
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 to
3
write data on board-level nodes . 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.

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
component 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 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
individual node. A Sequential Response Vector is a set of states received (captured)
sequentially by a Boundary-Scan receiver listening to a node.
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 pinpermission.
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.

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.

The Boundary-Scan Handbook

113

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?
otherwise go to step 5.

If so, go to step 9;

Step 9: Capture (read) the last response pattern.


4

Step 10: Shift in a safe stimulus pattern 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.

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
5
special (inexpensive) I/O card 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.
To some degree, the concept of a Personal Tester is viable and the ASSET
6
System from Asset Intertech is one actual example. This system is positioned as a
useful tool for prototype development as well as a way to learn about 1149.1 designs

A typical safe pattern would use the data from the BSDL description safe field (see 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.
5
6

Indeed, some people have used a standard 16-bit parallel I/O card for this purpose.

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, Intellitech and JTAG
Technologies, to name three more. They all can be found on the World Wide Web.

114

Boundary-Scan Testing

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
7
5) signals to make Boundary-Scan work for practical board testing. 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
question. 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
acceptable, the personal tester is a successful approach, but it can quickly become
impractical 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 problem can be
addressed with clip leads or by simply ignoring the affected nodes. Indeed,
Boundary-Scan has proven quite useful for rapid prototyping as it is called at
8
companies that use it.

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
9
Application Specific Integrated Circuit (ASIC).

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. The complicated support software behind this capability is not likely to
be available on personal testers even if some control 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.
8

Interestingly, rapid prototyping is sometimes performed on personal testers, but with tests
developed 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.
9

The meaning of Application Specific has a very narrow definition in the industry. For the
purpose of this discussion on the difficulty of testing, an ASIC could mean any one-of-a-kind
design, including Field-Programmable Gate Arrays (FPGAs), Complex Programmable Logic
Devices (CPLDs) and the like.

The Boundary-Scan Handbook

115

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
10
formidable test generation problems [Agra88]. Add to this the fact that an ASIC
might undergo a design change at the last minute that would most likely obsolete a
painstakingly 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
todays 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, In11
12
Circuit unpowered shorts testing to find shorts. This still leaves opens testing 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 ASICs 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
(section 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.

10

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.

11

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.

12

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.

116

Boundary-Scan Testing

In steps four and seven of our basic test algorithm (on page 112) 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
component 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.
13
This capability is difficult 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 subsets
of pins in succession, taking advantage of an In-Circuit ATE systems multiplexed
resources. Thus, we can multiply the value of our resources at the expense of testing
time. The concept of testing portions of a ICs I/O pins would not be possible 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 constraint 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 two-week In-Circuit
programming problem and solve it in less than ten seconds, 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 Figure 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
connection 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
ICs I/O pins are disconnected from the System Circuitry, and the Boundary Register
takes control of it. The ICs output drivers also can be controlled by the Boundary
13

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 usually
give no diagnosis, or a false diagnosis.

The Boundary-Scan Handbook

117

14

Register . This control allows us to set safe values on the ICs outputs while
INTEST in functioning.

To do an INTEST, we make use of the basic testing algorithm (section 3.1.2)


with the following modifications:
The stimulus pattern is being written to the System Logic inputs rather than
to the component output pins.
Component outputs can be held at safe or disabled states by adding these
values to each stimulus pattern.
The captured (read) response is that of the of System Logic outputs, including
output enable signals.
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.
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
standpoints: 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.
14

As noted in Chapter 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.

118

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 controlled 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 problem 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.

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.
15

Step 3: Shift a safe pattern into the Boundary Register. This pattern will
prevent 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 cycles16 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.
Step 7: Shift out the BIST result pattern for verification.
Step 8: Go to TEST-LOGIC-RESET and halt the test.

15

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.

16

The same clocking complications noted in section 3.1.5 concerning just what is a clock
apply here as well.

The Boundary-Scan Handbook

119

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 (nonconflicting) 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 diagnostic
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 Siamese 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
Siamese chains, operation becomes more difficult (see 5.2.1). Here we will restrict
our discussions to individual simple chains.
As mentioned in Chapter 1, a simple chain of Boundary-Scan ICs are always in
17
the same TAP state . 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
dimensions 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 Siamese 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
operational 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.

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.
17

Again, assume that no assertion of an optional TRST* signal occurs that would drive some
chain members to TEST-LOGIC-RESET independently.

120

Boundary-Scan Testing

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
18
integrity test will find only the problem closest to the TDO end of 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 Figure 3-7), we would see
the following concatenated data for a good chain (of seven ICs) and one example of
a failed chain. (Remember the rightmost bits, the least significant, 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
18

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.

The Boundary-Scan Handbook

121

subsequent 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
19
receiver 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
likelihood 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 limitationit 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 instruction 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
20
BYPASS . 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.
One fairly insidious problem (see DeJo91]) can cause difficulty in diagnosing chain
integrity. If several identical components are chained in series, then the patterns they
capture in their Instruction Registers are also identical. Now, imagine mat TDI and
TDO of IC 4 are shorted together and assume a Wired-AND occurs (see Figure 3-7).
This creates the AND of the TDO signals in ICs 3 and 4. Using our improved test

19

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 DischargeESD for example) are our main concerns.

20

Alert readers may wonder why we would program these instructions when the TESTLOGIC-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.

122

Boundary-Scan Testing

sequence with a prepended sentinel 10 attached, we see the following data


propagated from TDO.

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 InCircuit 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
21
is physically distant from TDO on the package pins (see 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 section 3.2.4 for interactions between
22
Boundary-Scan nodes and other nodes ). 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 section 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.

21

We are taking advantage of the fact that the vast majority of shorts are caused by improper
connections (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.

22

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 not appear to be a logic 0 or 1
value.

The Boundary-Scan Handbook

123

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.

124

Boundary-Scan Testing

Interconnect testing usually lumps the testing for shorts and opens into one topic.
Here, we will split the two problems apart. Shorts (see Figure 3-9) are a very
destructive problem in that they can confuse diagnostic procedures and hide the
occurrence of other failures.

The Boundary-Scan Handbook

125

Opens, on the other hand (see Figure 3-10) are a relatively simple problem to
diagnose. 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
23
applying power 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 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 stabilization 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 drivers
23

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!

126

Boundary-Scan Testing

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.

Interconnect Shorts Test


Interconnect shorts testing is done by utilizing our basic test algorithm (section 3.1.2).
It is used to transmit Sequential Test Vectors (STVs) onto nodes to be received by
Boundary-Scan input pins (see Figure 3-11). The data received at Boundary-Scan
input pins are called Sequential Response Vectors (SRVs). If a given node is operating
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 BoundaryScan 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 discussion.)
Step 3: Assign a unique Sequential Test Vector (STV) to each node. (See
discussion.)

The Boundary-Scan Handbook

127

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.

Discussion
Step 2 selects a designated driver for a node. This driver is frozen for the entire
interconnect test; no other driver is used. This means that for nodes with multiple
drivers (buses), there are 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 Interconnect Opens Test on page131).
In that discussion, we will examine several cases where opens are missed by
interconnect shorts testing.
The main reason for selecting and freezing a 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 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

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

128

Boundary-Scan Testing
24

cycles. 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 0s (1s). For N nodes, each PTV is N bits long with only
the bit set to 1 (0) among them. This makes a much longer test, on the order of

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
continuum of test patterns, as studied by Yau and Jarwala. They trade length for
diagnostic 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 stimulus portion
of the first test cycle, a PTV. We then look for every receiving cell connected 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-onfirst-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 cells SRV does not match the designated drivers STV. This
indicates an interconnect failure.

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 1s or 0s,
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 drivers 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) is may not be
24

The order of a problems 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.

The Boundary-Scan Handbook

129

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 phenomenon
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.
A key assumption here is that the destination pins of each node are indeed visible for
25
inspection. 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.
25

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.

130

Boundary-Scan Testing

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 probability
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 relatively
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, wiredOR or strong-driver behavior with known and deterministic results. If this
26
deterministic assumption is ever violated by a real fault, then we are using adaption in
an unpredictable or unrepeatable environment. Imagine, during test development, 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 interesting 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 diagnoses with
little irritation due to aliasing. The preset requirement means the test never changes,
which is a great help during debugging. The brief requirement 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. 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

26

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.

The Boundary-Scan Handbook

131

constant SRV (all 1s or 0s) 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 complement 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 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.

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 has
27
been verified for opens. The others were never activated , so we have not tested for
opens on them. We need to do an interconnect opens test that will finish the job.

27

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.

132

Boundary-Scan Testing

Figure 3-12A shows the basic configuration used during interconnect shorts
testing. There you see three ICs that drive the node and one that receives. U2 was
arbitrarily chosen to be the designated driver during interconnect shorts test, but that
leaves both U1 and U3 untested for driver 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 designate
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

The Boundary-Scan Handbook

133

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 Figure 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
component 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.
If we had a single bussed wire with N drivers we could test it very simply with 2*N
28
PTVs, N pairs that turn on just one driver and set it to 0 and 1 successively.

28

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.

134

Boundary-Scan Testing

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.

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.

The Boundary-Scan Handbook

135

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
parallel, 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 dont care.

136

Boundary-Scan Testing

In either case just shown in Figure 3-14 and Figure 3-15, the fanned-out, control
cell structure that we saw in Figure 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
29
cell enables two drivers, they must be enabled or disabled simultaneously . 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 designated
driver.

3.2.3

Connection Tests

Connection tests are similar to In-Circuit Boundary-Scan tests. They test the
connectivity of nailed nodes to Boundary-Scan components. The circuit in Figure 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 edgeconnector 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.
29

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 standard allowed them to be different, causing obvious problems for test algorithms.

The Boundary-Scan Handbook

137

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 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 0s or ls.
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 separate
tests, we can multiplex and reuse these resources. Indeed, if one IC were particularly
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.

138

3.2.4

Boundary-Scan Testing

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 preference, a
Boundary-Scan node could be shorted to a non-scan node. These interactions can cause
some special testing problems [Robi90].

Figure 3-17 shows a simple example of potential interactions between a BoundaryScan 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 conventional 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
30
allows our ATE system to place a strong 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 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.
30

The ATE driver must be strong enough to overdrive node C and node B simultaneously.

The Boundary-Scan Handbook

139
31

Once we have ATE resources available 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 BoundaryScan 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 nonscanned 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 Figure 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.

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

31

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.

140

Boundary-Scan Testing

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
relationship 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 numbers.
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 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 adjacent
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 Figure 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
32
then drive node F in the second. If a failure 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
successive applications, if they are multiplexed. Finally, it is possible when producing
33
the diagnostic report, to report the adjacent pins of the shorted nodes. These pins are

32

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.
33

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 BoundaryScan 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.

The Boundary-Scan Handbook

141

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

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
34
RUNBIST (and the rest with BYPASS) and in principle, 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 [Texa91] can be made to cooperate for testing
circuitry and interconnect between them as shown in Figure 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 signature. (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 diagnostic information.

34

This parallel operation may not be possible if the allowable variations in how the ICs are
clocked are not mutually compatible.

142

3.3

Boundary-Scan Testing

PORTING BOUNDARY-SCAN TESTS

The question sometimes arises, Can I port a Boundary-Scan test from one
application to another? This usually happens when someone creates a BoundaryScan 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
35
(typically, for individual ICs) manually 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
recognizes 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 important
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.
With Boundary-Scan you have Automatic Test Program Generation (ATPG)
software 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 difference. The second comes from the realization that the manually generated
test does not have diagnostic information accompanying it. It is essentially a go/nogo 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
35

Automated test generation for general ICs is fairly youthful, and it tends to generate tests of
horrific size, unsuited for board/system test purposes.

The Boundary-Scan Handbook

143

test will give a much more thorough diagnostic that can include input pin
36
diagnostics.

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
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.37 This language can be used to port vectors among applications, although with the problems mentioned above. This language will allow the
porting of (many) Boundary-Scan tests and also has the advantage of being
38
comparatively terse and thus frugal with disc space.
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 section 5.1.10 (page 180) 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
36

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.
37
38

Try the site map at www.asset-intertech.com to find a specification for SVF.

This terseness also means that it is highly unreadable by humans, so dont expect to debug a
test written in SVF. It is advised that only mature, fully debugged tests be converted to SVF.

144

Boundary-Scan Testing

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 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.

CHAPTER

Advanced Boundary-Scan Topics

As this book goes to press, the 1149.1 Standard is in its ninth 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,
individual ICs can be tested during production for DC parametric performance (see
4.1). A system can be unobtrusively observed during its operation using Sample
Mode test (see 4.2 and 4.3). Devices that do not themselves contain Boundary-Scan
can be tested by surrounding Boundary-Scan devices (see 4.4 and 4.5). Multi-Chip
Modules and other packaging hierarchies can be tested (see 4.7).
However, some of these topics, such as firmware development support (see 4.8)
and In-System Configuration (see 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.

146

4.1

Advanced Boundary-Scan Topics

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 ICs 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
and
respectively.
Output voltage levels; verify that voltages produced on outputs are within
specifications for logic 0 and logic 1. These parameters are termed
and
respectively.
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
parameters are termed
or
respectively.
Disabled output leakage; verify that an IC output, when disabled, has a
leakage current
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 Figure 4-1, routinely
perform these tests on ICs at wafer test or package test as appropriate. These
parameters are typically not tested any other time.
A difficulty is that some of these parameters relate to specific conditions at
output 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
and
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.
Boundary-Scan ICs can avoid many of these difficulties since the Boundary-Scan
1
facility has direct control of IC outputs and can observe IC inputs . For example, it is
a simple matter (using HIGHZ or EXTEST instructions) to turn off output drivers
for
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
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.

The Boundary-Scan Handbook

147

designs is currently a challenge. Indeed, they may actually be able to save their
customers time and money because of 1149.1 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 shifts out the sampled data. We can sample on many components 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
second 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.

148

Advanced Boundary-Scan Topics

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
2
distribution of SYSCLK, skews are introduced into the resulting buffered clock
signals CK1 and CK2, shown as skew1 and skew2. When a rising edge occurs on
SYSCLK, both Q1 an Q2 retain their data for time thold1 and thold2, then become
unpredictable until times tprop1 and tprop2the flip-flop propagation delayshave
expired. Then, to properly set up the data before the next SYSCLK occurs, times
tsetup1 and tsetup2 must be observed.
Now consider Figure 4-3 where we have added TCK distribution to the same
simple 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.

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.

The Boundary-Scan Handbook

149

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

150

Advanced Boundary-Scan Topics

proceed 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 Figure 4-3, there is not enough setup time for
Q2 to be properly sampled by TCK1.
During SAMPLE mode, it is quite possible that the setup and hold time
requirements 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 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
instruction 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 of IBM, [Wagn91]


utilizes the 1149.1 SAMPLE mode and pays special attention to the clocking
problems discussed in section 4.2. The technique uses the SAMPLE mode operation
of 1149.1 in conjunction with diagnostic procedures (for example, test microcode) in
a coordinated 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 circuits operation.
The basic concept, shown in Figure 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
3
collected in a signature collector, a multiple-input signature register (MISR) in this
case. The resulting signature is then compared against an expected-good signature
calculated by simulation or learned from a known-good board.
3

Note that the IBM 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.

The Boundary-Scan Handbook

151

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.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 Figure 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
contribution 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

152

Advanced Boundary-Scan Topics

CAPTURE-DR as in Figure 4-5. In this way, we can approximate fairly closely a


4
simple unformatted truth table test for U7.

This cannot hope to approach the 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.

The Boundary-Scan Handbook

153

Some problems with this approach do exist:


If the component under test is not synchronizable and requires a homing
5
sequence, this will introduce considerable complication into the BoundaryScan 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 Figure 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 5.1.5 on
page 176) during EXTEST, then this short can be detected.

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 decision logic.

154

Advanced Boundary-Scan Topics

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.

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 Figure 4-8 is to be tested. Here, resistor
is used to match the line impedance to eliminate nodal noise caused by signal
reflections. In a DC sense, the node could perform perfectly even with the resistor
missing. 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

One approach might be to add a new instruction to the Boundary-Scan


instruction decoder in U1 (we could call it LEAK) that causes a small current flow

The Boundary-Scan Handbook

155

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
shown in Figure 4-9. (Note, mixed-signal ICs can also be implemented with 1149.4
technology as described in Chapter 7.)
By partitioning the digital logic from the analog circuitry with the Boundary
Register, it is possible to write tests that can test the digital portion of the component
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 variations 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 domain of operation

156

Advanced Boundary-Scan Topics

of the analog circuitry. For example, an analog filter front end to a digital circuit
might not be able to slew from an all zeros digital value to an all ones value in
two successive tests.

Figure 4-10 shows two ICs with Boundary-Scan that communicate by differential
signaling. Differential signaling is an analog technology,6 but is a common
technique 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
problem because we have two signals controlled or observed by single cells. These
signals can suffer opens and shorts like any others. Todays consensus is that this
problem should be treated as follows:
design differential structures with Boundary-Scan as shown in Figure 4-10.
use the PORT_GROUPING attribute in a BSDL description (see 2.3.2 on page
62) 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.
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.

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 Figure 4-9.

The Boundary-Scan Handbook

157

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


positive 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
positive leg of a differential receiver while the negative leg is driven by an active
reference 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 Figure 4-11B. The differential
question is revisited in Chapter 7 where 1149.4 resources are used to implement
tests.

4.7

MULTI-CHIP MODULE TESTING

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


7
Integrated Circuit die upon a single substrate within one package as shown in Figure
4-12. MCMs have been used for many specialized applications for a long time. For
example, Hewlett-Packard has used mixed analog/digital MCMs as the front end of
7

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.

158

Advanced Boundary-Scan Topics

digital voltmeters for over twenty years. Today the desire is great to utilize MCMs
8
much more broadly in many new applications . Because testing is a large contributor
to the cost of an MCM, 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-Scanas 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
documented with its own netlist9 and set of BSDL descriptions. Note in the late
1990s we have seen the advent of silicon core technology, where several entire
8

MCMs are expensive today, but offer decreased size/weight, higher reliability, and higher
operating frequencies (when properly utilized). The workstation (performance) and the
laptop/palmtop computer (size/weight) marketplaces are two areas where MCMs hold good
interest.
9

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
sufficient 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.

The Boundary-Scan Handbook

159

ICs may be laid down on a monolithic piece of silicon. Some research [Jarw94] has
10
been done for this problem, but it looks like we will have the same result as we
have see 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.

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
measurements taken from important system signals (by clip-on probes) and you can
appreciate the power of such a tool. Indeed, a new microprocessor entering the
marketplace without such support available is likely to be unsuccessful.
The hardware development system is usually interposed between the
microprocessor 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
11
processor pin counts make sockets 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, yesterdays single
processor is todays 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. 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

10
11

Jarwalas work specifically addressed MCMs but the problem discussed is the same.

Packaging techniques such as Surface Mount Technology (SMT) and Ball-Grid Arrays are
rapidly making sockets obsolete.

160

Advanced Boundary-Scan Topics

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
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

Field-programmable gate arrays (FPGAs) and complex programmable logic devices


(CPLDs) have become increasingly 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
reprogramming 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 pre12
programmed devices. This lowers your Work-in-Progress expenses. Third,
13
handling blank devices 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 section 1.1.1 on page 2.
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, FPGA/CPLD 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
12

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.
13

These devices are themselves becoming quite large with high pincounts, which aggravates
handling difficulty.

The Boundary-Scan Handbook

161

delights me to say this group has now become a formal part of the 1149.1 Working
Group and has decided (after some initial misgivings) that full compliance with
1149.1 is desirable. Thus this group, as this book goes to press, is working on a set
of common protocols that will allow users to program multiple devices with some
degree of device family independence and vendor independence.
There are several underlying technologies used in FPGA/CPLD devices. Some
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
14
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
15
set up their output drivers for a benign condition.
Step 3: Load the ISC device instruction registers with the ISC_ENABLE
16
instruction 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 dont 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.

14

The ISC Working Group has not finalized this information, so be ready to obtain the final
document when it becomes available.
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 section 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.

162

Advanced Boundary-Scan Topics

Step 9: Proceed to TEST-LOGIC-RESET to bring the ISC devices into their


17
programmed operational states.
Other programming activities, such as readback verification of the programmed
content or device erasure are supported in a similar fashion. An FPGA/CPLD device
can be thought of as being in one of four macro states during its existence. These are
shown in Figure 4-13.

Macro state 1 (Blank) is the macro state the device is in when first manufactured.
In this macro state, the device has no programming (or at least it acts that way). The
Boundary-Scan facility is fully functional however and the Boundary Register can
18
control any I/O pin (for example, with EXTEST) as a fully bidirectional pin. In this
macro state there is no System Circuitry, so INTEST, if offered, would act
accordingly. Vendors of these devices usually force the output drivers of blank
components to a disabled state. This is the system behavior of the outputs, so when
non-invasive instructions like BYPASS or IDCODE are executed, the drivers will
remain disabled.
Macro state 2 (Being Programmed) is entered when the device, not currently
enabled for programming, is now enabled by the ISC_ENABLE instruction
sequence. As in macro state 1, the Boundary-Scan facility is fully functional (for
example, using EXTEST) and the Boundary Register can control any I/O pin as a
fully bidirectional pin. The ISC_ENABLE instruction itself has one of two options
for controlling the states of the I/O pins; either it disables all output drivers
independently of the content of the Boundary Register, or the Boundary Register
itself (as set up by a PRELOAD sequence) has control of the I/O pins. We call these
two options HIGHZ behavior (see section 1.5.4) or CLAMP behavior (see
17

Note you can bring the ISC devices into their operational states in a particular sequence by
loading their instruction registers with the BYPASS instruction one-by-one while the others
remain in ISC_DISABLE.
18

By customizing the BSDL description, any bidirectional pin can be pared down in scope to
a simple input or output only to fit the ultimate board application, if desired.

The Boundary-Scan Handbook

163

section 1.5.5), because they mirror those two instructions, including targeting the
BYPASS register. Note that all subsequent ISC instructions for any one device will
use the same option for controlling output drivers.
If while in macro state 2 a normal 1149.1 instruction is executed, it will behave
exactly as it is specified by the Standard. If another PRELOAD sequence is executed
for example, this will change the state of the Boundary Register content, which could
change the state of the output drivers when an ISC instruction is restored to the
instruction register. The system state of the device with respect to INTEST, for
example, is still blank.
Macro state 3 (Programmed) is entered when an ISC_DISABLE instruction is
sequence is performed. This does not cause the device to take on its programmed
behavior (that happens in macro state 4) but rather, it is still behaving as a blank
device including its I/O behavior. The device can return to macro state 2 for other
programming activities if another ISC_ENABLE sequence is performed. Thus the
device could progress from a programming process to a readback process without
ever being in its system operational state. The device can also proceed to macro state
1 (blank) if an ISC erasure procedure is executed or the TAP is reset. Macro state 3
will persist until the instruction register (currently loaded with ISC_DISABLE) has
that instruction displaced by a non-ISC instruction.
Macro state 4 (Operational as programmed) is entered by displacing the
ISC_DISABLE instruction from the instruction register with a non-ISC instruction.
This can be done simply by putting the TAP in the TEST-LOGIC-RESET state, or by
deliberately loading an instruction such as BYPASS. This choice allows selected
devices in the chain to be brought into operational status in a particular sequence if
desired, or they can all be made operational simultaneously. Now, in contrast to the
previous three macro states, a non-invasive instruction such as BYPASS or IDCODE
would behave as you would expect for a conventional logic device; the devices
newly programmed system logic would control the output drivers and respond to the
inputs.

4.10 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
multiplexor function that most Boundary-Scan cells have between the Update FlipFlop (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 content 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

164

Advanced Boundary-Scan Topics

to selectively apply this fault value to an I/O pin. This is done with the a simple
19
modification to a classic Boundary Register cell shown in Figure 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 FlipFlop is clocked by the Update-DR clock signal. But for a new instruction (lets 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 normal
Update register.
The content of the Update-FI Flip-Flop is ORed 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 FlipFlop 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
20
a set of stuck-at 0 or 1 values for any pin(s) of interest, both input and output.
(Note you must to assign a 0 or 1 to all cells, but only those later fault insertion
19

This modification is simpler than that shown in [Nade95]. The design in Figure 4-14 does
not support 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.

20

Note, if this cell design is applied to output enable control cells, then you can fault a 3state driver, causing it to be stuck-at-enabled or stuck-at-disabled.

The Boundary-Scan Handbook

165

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
diagnostic tests. This was a principle motivation for the [Nade95] work , done for the
telecommunications industry. The ability to add fault insertion Boundary-Scan cells
is offered by at least one EDA vendor, LogicVision as part of their icBist tool.

This page intentionally left blank

CHAPTER

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 enumeration
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 numbers
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, and Multi-chip Modules are some of the factors
that threaten existing board testing technology. The phrase yesterdays system is
todays board is quite true.

168

Design for Boundary-Scan Test

One complaint I have had about DFT literature (for which I am partly
responsible) 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 anticipated. 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.
Along with the type of testing, we must not forget the target failure mechanisms,
the real faults 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,
supported 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 faultsthe
havoc of the production processaffecting 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.1 For
example, 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 Electronics Design
1

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.)

The Boundary-Scan Handbook

169

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.

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 section 3.2.1 on page 119) 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 likelihood that a short could occur between them. This type of layout should be avoided.
Figure 5-1B and Figure 5-1C show preferred layouts that reduce the probability of
their shorting2. This leads to our first DFT rule.

The main cause of board shorts is the bridging of solder between adjacent pins, particularly
with fine-pitch spacing.

170

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
Figure 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: When possible, 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.3 A typical


VLSI component may have many power and ground pins to distribute lead
inductance over many parallel pathways. If this distribution is not handled carefully,
the result could be Ground-Bounce.

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.

The Boundary-Scan Handbook

171

Ground-Bounce occurs when inductance and/or resistance in the power


distribution 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-volt bounce, approximately 25
nanoseconds wide, is sufficient to add a new TCK cycle. The voltage 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:

When a Ground-Bounce on TCK occurs, it is most 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
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.

172

Design for Boundary-Scan Test

Consider the example shown in Figure 5-3. Here a large IC generates signals on a
pair of 32-bit buses. In this ICs normal usage, the two buses are never active at the
same time, as shown in Figure 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
produce transitions at the same time. In the worst case, guaranteed to occur in the
interconnect test algorithm4 shown in section 3.1.2 on page 112, all 64 drivers will
change at the same time.5

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 Figure 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,
perhaps only a few nanoseconds apiece, are used to deliberately skew driver
4

The Standard specifically disallows designers from specifying some maximum number of
simultaneously switching drivers that is less than all drivers. Further, designers may not
attempt to outlaw certain combinations of states driven by drivers.

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.

The Boundary-Scan Handbook

173

transitions in time so that the required supply current demands do not change as
quickly in 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 Figure 5-5 is not compromised by grouping your control cells next to each
other in the Boundary Register.

174

Design for Boundary-Scan Test

It is thus very important to do a worst-case analysis6 of Ground-Bounce


accounting for the maximum number of drivers switching states. It will also be
important to separate 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 surges 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.

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 Chapter 3 in the discussion of 1149.1
Integrity testing. 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-4: Use higher-order bits of the Instruction Register capture pattern
to implement an informal ID code. The bits captured must be predictable
0s and 1s.
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 capture
patterns. Thus, if one IC is misloaded in place of the other, we cannot discover 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 ICs
system logic7 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 (dont know bits) in the INSTRUCTION_CAPTURE attribute of
BSDL. The capture of design-specific data is sometimes done to increase visibility
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 previously
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 a
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.

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.
7

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).

The Boundary-Scan Handbook

175

DFT-5: 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. Twenty-five 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 abuse8 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
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
durations 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 reduced power voltages (such as 3.3 volts) make
damage less probable? 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 option9 . Of course, we could continue with a fourth policy often followed
in the past: ignore the problem.

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.
9

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
navigation systems as examples.

Design for Boundary-Scan Test

176

I prefer a mix of choices 1 and 2. Study (theoretically and empirically) the


tolerance 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 test10, and remove power. Then double that result. Times in the range
of several seconds are quite possible.
DFT-6: 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 [IEEE99], 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 Logic11, or the Update (UPD) flip-flop.
However, 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 design
as shown in Figure 5-6.

The self-monitoring output cell design (Figure 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 conditions:
first, the driver is intentionally Wire-ANDed or Wired-ORed (2-state case) with
some other driver(s) on the board. Second, the driver is not enabled (3-state case);
and third, a defect in the driver or a board-level fault such as a short prevents the
10

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
multiplying the TCK cycle time by the number of TCK cycles in the longest expected test.

11

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.

The Boundary-Scan Handbook

177

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 follows12:
constant SMOC:CELL_INFO := --((OUTPUT2, EXTEST, PO),
(OUTPUT2, INTEST, PI),
(OUTPUT2, SAMPLE, PI),
(OUTPUT2, RUNBIST, PI),

Define a Self-Monitoring
Output Cell (SMOC)
(OUTPUT3, EXTEST, PO),
(OUTPUT3, INTEST, PI),
(OUTPUT3, SAMPLE, PI),
(OUTPUT3, RUNBIST, PI));

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 situation, 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 routines to
differentiate between a node shorted to Power/Ground and an open solder connection.
This leads us to our next DFT rule.
DFT-7: 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 2cell 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 application rates. The
advantage of the 2-cell design, before Supplement A [IEEE93] 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 design13 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 section
5.1.5 above) combined with reduced Boundary Register length.

12

This description would be part of a user-defined VHDL package for cell design description
as described in section 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 section 2.3.13 on page 72).

13

The bidirectional cell that has the lack of pin monitoring is known in BSDL as cell BC_6
(see section 2.6.3 on page 91). 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.

Design for Boundary-Scan Test

178

DFT-8: For bidirectional pins, utilize a single-cell bidirectional design with


a self-monitoring capability (such as cell BC_7).
The BSDL description of such a cell looks as follows:
constant BC_7:CELL_INFO :=
((BIDIR_IN,
(BIDIR_IN,
(BIDIR_IN,
(BIDIR_IN,

EXTEST,
INTEST,
SAMPLE,
RUNBIST,

PI),
PI),
PI),
UPD),

-- Self-Monitoring
-- Bidirectional Cell
(BIDIR_OUT,
(BIDIR_OUT,
(BIDIR_OUT,
(BIDIR_OUT,

EXTEST, PO),
INTEST, PO),
SAMPLE, PI),
RUNBIST, UPD));

The triple (BIDIR_IN, EXTEST, PI), for example, shows (see section 2.6.2 on
page 89) 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 behaving
as an output during EXTEST, the cell captures data from the pad driver (PO = parallel
output). In the original issue of the Standard ([IEEE90], figure 10-22), the cell BC_6
captured System Logic data (PI).

5.1.7

Post-Lobotomy Behavior

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


pin-permission to an instruction such as EXTEST, will lose contact with its companion
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. 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 problem. 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-9: When the 1149.1 logic executes a pin-permission instruction, the
system logic should be forced into a state that prevents internal conflicts.
DFT-10: 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 operation. Note
that RUNBIST may not operate correctly in a lobotomized component, requiring a
reset of the system logic.

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

The Boundary-Scan Handbook

179

similar components or different revisions of the same component are misloaded on a


board14.
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 section 5.1.3). Another
opportunity exists to differentiate an IC informally, by having certain cells in the
Boundary Register capture constant 0s and 1s.
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 section 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-flop15. 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 informal
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 0s and ls


in the Boundary Register that form an informal ID code.
DFT-11: Use formal or informal ID codes to differentiate similar
components or revisions of components.

5.1.9

User-Defined Instructions

We have already seen a case (see section 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
14

In the case where different revisions or manufacturing codes are permissible, you can edit
the BSDL attribute INSTRUCTION_CAPTURE to describe multiple device identification bit
strings. (See section 2.3.10 on page 69.)

15

If the control cell has been merged with an input cell, then it must capture the input pin state
in that case.

180

Design for Boundary-Scan Test

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-12: Consider board-level testing problems that will require userdefined 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 HTML16 formatting information is included in the BSDL, causing syntax errors.17 Measures as simple as
limiting line lengths in your BSDL to less than 70 characters can often avoid some
of these problems.
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 tester18 before the
component is used in a board or system test. A BSDL verification test should contain
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.
16

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>.
17

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.
18

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.

The Boundary-Scan Handbook

181

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.19
verification of the mapping20 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
bidirectional pins acting as inputs.21
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-DR state.
Verification that CLAMP, if it exists, targets the BYPASS register and controls
all IC outputs upon passing the UPDATE-DR state with a pattern set up by
PRELOAD.
verification of the RUNBIST function if it exists. (Note, this will require
components that both pass and fail RUNBIST.)
BSDL verification tests can be very long, with the mapping verification being an
complexity problem. 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 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 7,000 TCK cycles, again
excluding RUNBIST. (The RUNBIST function takes over 1,250,000 TCK and CLK
cycles.)
DFT-13: 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
19

Private instructions may be omitted from this test.

20

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.
21

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.

182

Design for Boundary-Scan Test

IC vendors still do not have a good process for creating, certifying and maintaining
BSDL. You should not assume that a vendors 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-12) with thought towards
their solution.

5.2.1

Chain Configurations

Most of the discussion about Boundary-Scan chains has been in the context of simple
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 software
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
component, 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 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 Figure 5-7. This is the first
example of a Siamese chain.
The Siamese chain of Figure 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 Boundary-Scan Handbook

183

The second form of Siamese chain (shown in Figure 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 whenever
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 Siamese chain in Figure 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 essentially
a set of simple chains that have their TDI/TDO data paths linked together by
22
multiplexers or more complex switching networks . 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.

22

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.

184

Design for Boundary-Scan Test

DFT-14: 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 erased 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
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-15: 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.

23

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.

The Boundary-Scan Handbook

5.2.2

185

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 Figure 5-9. This example shows a simple chain with two logically identical
nodes (TCK1 and TCK2) for TCK and (TMS1 and TMS2) for TMS24.

Now, a pair of simple buffers has been shown in Figure 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
25
essentially interposes a complex function 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 Figure 5-9 is really two
26
separate simple chains. This is because it has no way of determining (without
intervention) that TCK1 and TCK2 are really buffered copies of TCK, and similarly
for TMS. This leads us to another DFT consideration.
DFT-16: 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.

24

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.
25

26

See also the discussion of Boundary-Scan Masters in section 5.2.7.

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.

186

Design for Boundary-Scan Test

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 components may
contain a buffer tree as shown in Figure 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-17: 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 Figure 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 converter in

The Boundary-Scan Handbook

187

Figure 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 Figure 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.
Figure 5-12 shows the same simple chain as in Figure 5-11, but with a BoundaryScan 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 non27
scanned component. This introduces the same problems we saw (in section 5.2.2 on
page 185) with respect to buffered TCK/TMS distribution.
DFT-18: When mixed logic families are used on a board, use scanned level
27
converters for the parallel signals and a non-scanned level conversion for
TCK/TMS distribution.

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 boards design will not be honored during Boundary-Scan

27

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.

188

Design for Boundary-Scan Test


28

testing. This can lead to conflicts if we are testing a mixture of scan and non-scanned
components, such as we see in Figure 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
29
these conflicts are of concern since they could damage 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
30
than be tested. 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 BoundaryScan signaling.
DFT-19: 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.

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.

28

Remember that these constraints will not be honored by failures either.

29

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.
30

If Boundary-Scan receivers are present on constrained nodes, then the constraints can be
captured and verified, yielding a partial test of the nodes.

The Boundary-Scan Handbook

189

First, Figure 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-20: Provide for the ability of a tester to disable conventional ICs
whose outputs would otherwise conflict with nodes involved in BoundaryScan tests.

Second, Figure 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-21: 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 be held high during testing. (In this respect, they can be thought of as compliance
enables too!) This leads to:
DFT-22: Make sure you locate and condition all Test Reset (TRST*) pins
and all compliance enable pins before executing any Boundary-Scan tests.

190

Design for Boundary-Scan Test

In these cases we are arguing for additional tester resources, and access to critical
board nodes. 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 random
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-23: 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 section 5.2.5 for a discussion of
this problem. If 1149.4 (see Chapter 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 analog
signals.

5.2.7

Boundary-Scan Masters

At least two examples exist in the commercial IC market of ICs called Boundary-Scan
31
masters . 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 conversion
directly in hardware from a common microprocessor interface as depicted in Figure
5-15. They also contain some hardware support for testing functions.

31

They are the Texas Instruments 74ACT8990 and the AT&T 479AA.

The Boundary-Scan Handbook

191

From a board-test point of view, Boundary-Scan masters have a completely


different 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
32
protocol, 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-24: 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 masters
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.

32

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 software is usually not of general use outside of this environment.

192

Design for Boundary-Scan Test

Once the path is set up as shown in Figure 5-16, it will behave as one expects an
1149.1 chain to act, with the following exceptions: the start of a linked or
multiplexed simple chain is prepended with a single, additional shift-register stage
33
and a selected register 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-24, applies here as well.

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
33

The selected register is a function of the instruction loaded into the TAP Instruction
Register of the Linker/Selector IC.

The Boundary-Scan Handbook

193

Boundary-Scan chain has lobotomized the board. Assuming the 1149.1 components
take care of themselvesfor example, by staying in a quiescent state after a BoundaryScan operation completeswe 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-25: 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 the
34
start 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 SelfTests 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.

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.

34

Of course, the access to nodes needed for this capability should have been provided as noted
in rule DFT-20.

194

5.3.1

Design for Boundary-Scan Test

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.

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 purpose
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 (perhaps 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 section 5.3.2.

The Boundary-Scan Handbook

195

DFT-26: Restrict 1149.1 implementations for system tests to simple system


architectures not containing a multidrop scheme.

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.1based boards. It allowsvia an 1149.5 busthe 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 a 1149.5
controlling IC on each board, as well as one other such IC in the test and
maintenance 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
backplane 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 example,
see [Avra87], [Breu88] and [Derv88]). The work reported by Dervisoglu35 [Derv88]
gives a case study of a real implementation successfully carried out for a workstation
product.
It is interesting to note that the hierarchy problem is also occurring in the
microcosm 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
suggestions; it is too early yet to see where the industry is going with this situation.
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!

5.4

SUMMARY

Boundary-Scan offers great potential to solve emerging test problems that have
staggered yesterdays testing technology. Many companies are well into 1149.1

35

The scan-based architecture reported by Dervisoglu predates the 1149.1 Standard and is
significantly different in the details.

196

Design for Boundary-Scan Test

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,
particularly among the larger ICs. Formerly troublesome FPGA/CPLD ICs are now
standardizing 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 questionable. IEEE 1149.1 has become a vital contributor to the progress 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
technology 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) technology.

CHAPTER

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
measurements used today in In-Circuit testers. While 1149.4 does have significant
differences 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 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
of these boards have been tested with In-Circuit techniques. So how have these
several hundred billion components been tested? It serves as excellent 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 Figure 1-2 on page 6.

198

Analog Measurement Basics

This fixture gives us nodal access to every terminal of each analog device. But
before we jump into the discussion of testing these components, lets first agree on
what it is we are testing for.

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 Figure 6-1, a filters performance may depend on parasitic


capacitance
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
parasitic 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
networks, 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
components 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
outermost 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

The Boundary-Scan Handbook

199

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 requirement). Such a test may require a new process step such as visual
inspection of the 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 constructed capacitor may be used from an alternate source.

In-Circuit test is able to measure the value of analog components such as


resistors, 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 Kohms, 5%. Thus if we measure the resistor we expect it to have a
value of 4.7 Kohms 235 ohms. In a sample of these resistors, we might expect to
see a truncated bell curve for the distribution of values as seen in Figure 6-2.
What if we measure this resistor and see a value that is high or low by 240 ohms?
Is this a failure? The answer is clouded by the fact that the measurement process
itself may inject errors (see section 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
guardband 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
construction 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

Real components, not parasitics.

200

Analog Measurement Basics

values that may be tested. As we see in section 6.1.3, combinations of components in


certain interconnection topologies may be difficult to test.

6.1.2

Measuring an Impedance

To measure the value of an impedance R, we make use of Ohms law in one of the
two configurations shown in Figure 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
measured 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
ohms, 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
2
could also damage diode junctions by causing voltage breakdown. 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 Figure 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
3
different (lower) current should be tried. This process should eventually converge
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.)

As we will see later in this section, we also have to be careful of other devices surrounding
the device we are testing.

There is the case where the impedance is infinite because of an open circuit. In this case the
process of finding a current setting will converge on zero.

The Boundary-Scan Handbook

201

Another stimulus/measurement configuration is shown in Figure 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
impedance, 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
4
voltage source that does not cause a compliance condition, 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 Figure 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 Figure 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
5
that will not turn on a diode, perhaps less than 0.2 volts, 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.
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.

202

Analog Measurement Basics

Figure 6-4B shows the elements of a typical In-Circuit tester. Nails from the bedof-nails fixture touch the nodes A and G on either side of resistor R. Within the
fixture, 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
ohms. Second, when reed relays are
open, they have very high off resistance, perhaps
ohms. They come close to
6
being perfect switches.
From the measurement buses (Figure 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 measurement 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 Figure 6-3B. The voltage source is set to less than 0.2 volts to prevent the silicon
junctions in U1 from turning on. (Not shown in Figure 6-4B are any control
functions for the relays and instrumentation.) With all of this complexity in the
measurement path it should not be surprising that we have new sources of error. This

The switching time from open to closed is less than perfect, in the neighborhood of 500
microseconds. They often take longer to open.

The Boundary-Scan Handbook

203

will be covered in section 6.1.3, but next we examine complications in


measurements due to parallel device topologies such as seen in Figure 6-5.

The parallel impedance problem is personified by the delta configuration of


impedances shown in Figure 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
and
are present, we need something more to deal with the parallel path
problem. This is shown in Figure 6-5B.
In Figure 6-5B we see the familiar voltage forcing configuration on nodes B and
A seen originally in Figure 6-3B, but with a new addition; a third node C is

204

Analog Measurement Basics

grounded using a third nail. This is called guarding. Guarding uses low impedance
7
paths through reed relays to insert grounded points into the circuit. If you examine
Figure 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 voltage
across
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 Figure 6-4B, we find impedances
8
inserted along measurement pathways contributed by relays, nail contacts and
wiring. This is shown in Figure 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 Figure 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
9
measurement 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 Figure
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.
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 carries
current. The cost, however, is significant because we now need two additional In7

An example at the macroscopic level of Heisenbergs 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
ohms 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.

The Boundary-Scan Handbook

205

Circuit nails. This configuration is rarely used unless we need a very precise
measurement of a very small resistance R.

206

Analog Measurement Basics

Similarly, the delta configuration of Figure 6-5 will also suffer from voltage
errors caused by currents traveling through relays, wires and nails. These are shown
in Figure 6-7A. Of particular concern is the error impedance in the guard path
which raises the voltage at node C above ground. This allows an error current to
flow into
and subsequently through
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
if
is 1 ohm and R is 10 Kohms while
and
are both 10
ohms, the calculated value of R would be about 100 ohms. This is because the
current circumventing R is nearly 100 times as great as that traveling through R.
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 Figure 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 InCircuit 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 Figure 6-8, where it is monitoring the same delta

The Boundary-Scan Handbook

207

configuration we have used in other examples. In this configuration (often called a


Measuring Operational Amplifier or MOA) the op-amp combined with the feedback
resistor
will endeavor to keep node A at zero volts.

The value of R is calculated by this formula:


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 Figure 6-9.

This integrator is made from an operational amplifier with a high quality


10
will be a highly linear ramp
capacitor C in the feedback path. The voltage
given a DC input V, which is the solution to this equation:

which is both a function of V and the time constant of the system defined by the
product of R and C.
10

This capacitor doesnt need to be accurate (only stable over the period of measurement) but
it should have excellent characteristics with respect to dielectric absorption.

208

Analog Measurement Basics

A dual slope integrator is similar, as shown in Figure 6-10. It integrates the


unknown voltage
for a period of time T which produces a positive voltage
Then a known negative reference voltage
is switched in place of
which
causes a downward ramp on
The time X to reach zero volts is recorded. The
dual slope integrator is a physical solution to the equation:

This equation, when solved for the unknown

yields:

which is the product of the known


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 component used.
As always, we do have to be wary of the non-ideal. Since we may not know the
approximate value of
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
will occur with
an accuracy penalty. If our guess is too long, our integrator may ramp
beyond
11
the linear region of the integrators 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
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
12
amplification, and/or R and C, until a suitable ramp has been found.

11
12

This region will be within the power supply rail voltages of the operational amplifier.

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.

The Boundary-Scan Handbook

209

The dual slope integrator can also be used to measure AC voltages. We will
confine 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 Figure 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 Figure 6-11A, this is the purpose of switches D and
13
E. 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
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.

210

Analog Measurement Basics

and whether the unity-gain inverter complements that portion. The DC reference
voltage source serves the same function we saw in Figure 6-10 for DC
measurements.
To measure an unknown AC signal
first we integrate several full cycles of
(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
is switched into the integrator replacing
causing a downward ramp.
The integrated waveforms yielding
are shown in Figure 6-11C. As with the DC
case, the process continues until
returns to zero while we measure time interval
X. As before, the measured value of
is computed as:

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 A and B, we can select a phase
offset for a measurement. If we offset a measurement by 90 we can measure the
14
imaginary 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
networks. See the example in Figure 6-12.

In Figure 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
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
Note however that we
will offset the measurement by 90 with respect to the stimulus voltage source so
that we measure the imaginary voltage as shown in Figure 6-13. We then compute
the imaginary current through the known resistor. This plus the imaginary voltage

14

Imaginary signal detection is sometimes called a quadrature measurement.

The Boundary-Scan Handbook


across the capacitor (the measurement at the top of
value of C.

211
allows us to calculate the

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
compromised. 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 problem 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
functional test techniques. However, this is unsatisfactory if you want to retain
diagnostic 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 high-quality diagnoses has led to new research in In-Circuit test
[Huan97, McDe98a, McDe98b]. Todays In-Circuit approach tests analog networks
with board power turned off. Tomorrows 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.

212

6.2.1

Analog Measurement Basics

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 Figure 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
and so on. (All
voltages 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 section 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
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.

This example was carefully chosen to have three voltage differences so that they
15
can be plotted in a three-dimensional coordinate system such as shown in Figure
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 Figure 6-14. Each simulation starts with a randomly selected set of
variations for the four resistors and then computes the resulting node voltages. These
15

The techniques shown here work for higher numbers of nodes and components. However it
is difficult to visualize higher-order dimensions.

The Boundary-Scan Handbook

213

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 resistor 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.

6.2.2

Testing With Node Voltages

Node voltages can be used to test a circuit. One simple idea is to measure all the
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 Figure 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, Figure 6-16B is a plot where only R2 is outside its tolerance limits. 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 failure of

214

Analog Measurement Basics

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-of16
tolerance 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

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
components look the same and do not have enough space on them for labels.

The Boundary-Scan Handbook

215

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
Figure 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 Figure 6-18.

In this case, losing access to node B means we cannot measure


for this
node. Figure 6-19A shows the shadows of the clouds for R2 and R3 projected onto
the plane of voltages for
and
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
The
shadows of the R2 and R3 clouds onto the plane of voltages for
and
are

216

Analog Measurement Basics

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.

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 accessible. The
largest ambiguity class contained three components. The CPU time (on a modest
17
CPU) to construct a test for this 20-dimensional problem was about two minutes.
(This is a one-time investment.) Nodal access was chosen by the manufacturer of the
circuit and was not optimal.

17

One node is always used as the reference node for voltage measurements.

The Boundary-Scan Handbook

217

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
18
that are analog.
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
19
signals convey information via continuous states of voltage and current. For
example, the signal representing a singers voice, as converted to electrical form by a
microphone, 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
information is represented.

Analog designers quickly point out that all circuits are analog. Its just that socalled 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
18

Indeed, it is possible to have a single signal with both natures. Consider for example the
encoding 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.

218

Analog Measurement Basics

operating frequencies increase and noise margins decrease, most digital designers
tend to agree with the analog designers viewpoint! This is because yesterdays
digital designs could ignore parametric factors such as impedance matching, signal
reflections and ringing. Tomorrows designs must be concerned with these analog
problems. Often the solution to these problems involves adding extra discrete analog
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
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
juxtaposition of In-Circuit nails with old and new devices against a backdrop of a
common coin, a US Lincoln penny. A key to this photograph is presented in Figure
6-21. If you have a penny, it is instructive to examine it.
20

The lettering on this penny is done with 10 mil lines. 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
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 Figure 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 Lincolns 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
20

Printed circuit dimensions are often specified in English (Imperial) units. A mil is 0.001
inch, or about 25 micrometers.

The Boundary-Scan Handbook

219

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
mechanical 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 areas, and remember that each nail is a spring-loaded assembly that contacts

220

Analog Measurement Basics


21

the board with a notable 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 4 times the size of a modern signal trace and about the same size of todays
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; todays more advanced IC geometries are based on


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 testing
by IEEE 1149.4. It will certainly be the case that todays In-Circuit test techniques
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 technique
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 pounds of spring force. That comes to
2000 pounds (nearly 1 metric ton) of spring force distributed across a board and fixture.

CHAPTER

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
integrated a portion of an ATE systems 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
consideration 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 testing could be facilitated with a standardized approach. This group had
extensive debates on just what it was they were trying to standardize. This debate
1

Caution: The 1149.4 Standard draft is being completed as this book goes to press. The author
believes that the material presented here is substantially similar to that ultimately published by
the IEEE. However, you should obtain the latest IEEE document.

222

IEEE 1149.4 Analog Boundary-Scan

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 lower2 frequencies; from DC to around 1 MHz. If this seems
like a serious limitation, consider the fact that virtually all the boards tested with InCircuit test equipment over the last 25 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 significantly
higher3 than those achieved by relays and wire. This immediately rules out testing
activities based upon traditional guarding techniques seen in section 6.1.3 on page
204. IEEE 1149.4 does not support brute-force insertion of virtual grounds. Thus,
new metrologies [Park93, McDe98] 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
2

This isnt to say you could not engineer an 1149.4 implementation to function at higher
frequencies. You can add special functions that have elevated performance, though this could
be expensive.
3

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 1998 technologies, you should expect to see
economical silicon switches with on-impedances from hundreds to thousands of ohms.

The Boundary-Scan Handbook

223

described in Chapter 1 (see section 1.3.1 beginning on page 10). An 1149.4


compliant IC can participate cooperatively with 1149.1 ICs to perform interconnect
testing such as described in Chapter 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
functions 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. Just as is the case with
1149.1, the 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 section 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,
typically series termination resistors, between IC pins rather than simple wiring. This
leads to the necessity of viewing interconnect in two forms, logical and

224

IEEE 1149.4 Analog Boundary-Scan

physical. 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
interconnections, 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
component such as a resistor, inductor or capacitor. 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
constructing 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 Figure 7-2 may have an initial stored voltage that could be added into
4
subsequent test signals, causing confusion 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
4

Voltage addition by the capacitor could also cause signals to go out of normal operating
range with possibly damaging effect.

The Boundary-Scan Handbook

225

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.
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
connecting 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
networks 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 section 7.2.5).
A DBM may contain one or more Boundary Register cells as discussed at length
in Chapter 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.

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.

226

7.1.4

IEEE 1149.4 Analog Boundary-Scan

Analog Pins

IEEE 1149.4 directly addresses analog pins, rather than ignoring them as IEEE
1149.1 has done for over eight years. Analog pins are assigned test resources
contained in an Analog Boundary Module, or ABM, covered in section 7.2.4. As
just discussed, an ABM will contain Boundary Register cells which are not
constrained 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
additional 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
emulation 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
capability 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.1type interconnect tests, then the 1149.1 emulation will not be usable for
interconnection 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 Figure 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 capacitors
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
frequency 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.

The Boundary-Scan Handbook

227

An ABM also provides new test capabilities in support of analog test that are
covered extensively in section 7.2.4. It could happen that these new resources are not
needed because (in a particular application) there are no analog components or
parameters 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 1149.1-style interconnect testing as well as
supporting analog tests.

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. This 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
familiar four (optionally five) TCK, TMS, TDI, TDO (and TRST*) signals.
These elements are described completely by 1149.1 (see section 1.3 beginning
on page 8).

228

IEEE 1149.4 Analog Boundary-Scan


Digital I/O pins served by Digital Boundary Modules (DBMs) made up of
1149.1 Boundary Register cells as described in section 1.3.4 starting on page
21. DBMs are discussed in 7.2.5 on page 242.
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 section
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 section 7.4.1 on page 250.)
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 section 7.2.3 on page 231.) 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 section 7.4.1
on page 250.) A separate option allows a TBIC to generate a partitioned
internal analog bus structure to improve internal loading and noise
characteristics. (See section 7.4.3 on page 253.)
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
voltages labeled
and G. (See section 7.2.4 on page 236.)

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.

The Boundary-Scan Handbook

229

Just as is the case with 1149.1, the 1149.4 standard connects selected registers
between TDI and TDO as shown in Figure 7-4. Mandatory registers include the
Instruction Register (described in section 1.3.2 on page 16), the Bypass Register
(described in section 1.3.3 on page 20) and a Boundary Register. The Boundary
Register is identical in nature to that described in 1149.1 (see section 1.3.4 on page
21) but contains additional cells that are used to control the actions of ABMs and the
TBIC.

7.2.1

Silicon Switches

Throughout this chapter we will be using switching structures implemented in


silicon to perform test functions. The TBIC and ABMs contain these switches in
specifically 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 4 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 doesnt have an onresistance.8 In an 1149.4 implementation implemented in a bipolar process, some
(buffer) switches are required to conduct current (the AT1 and AB1 paths) and
others (the AT2 and AB2 paths) are required to convey voltage. (The 1149.4
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.

230

IEEE 1149.4 Analog Boundary-Scan

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
impedance for practical purposes. However, when closed, it has non-negligible series
impedance that is represented with the integral resistor shown. This symbolism 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 Figure 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 Figure 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
environment, 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

To this day 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.

The Boundary-Scan Handbook

7.2.3

231

The Test Bus Interface Circuit (TBIC)

The TBIC function first introduced in Figure 7-3 (on page 227) 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
characterization11 processes that may be needed to improve the accuracy of analog
measurements. A switching structure meeting the requirements of 1149.4 is shown
in Figure 7-7.
Switches S1 through S4, along with the one-bit digitizers that generate signals
and
are used to support 1149.1-style interconnect tests. (The destination
of these digitized signals is found in Figure 7-8.) The digitization is performed in
relation to some threshold voltage shown as
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,
with the additional goal that a short between
AT1 and AT2 will not produce an intermediate voltage that approximates

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 calibrated, 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.

232

IEEE 1149.4 Analog Boundary-Scan

It is an interesting feature of 1149.4 that it can execute a conventional BoundaryScan 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 S7 (or S6 and S8) allow us to characterize the AT1/AT2 pathway
via a loopback test. This characterization will allow us to correct for the many
parasitic 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.

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 section 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.

The Boundary-Scan Handbook

233

The (minimal) TBIC control structure14 for the switches in Figure 7-7 is shown in
Figure 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
and
signals
generated within the switching structure shown in Figure 7-7. (The capture stages of
cells Ca and Co are uncommitted.17) Cells Co, D1 and D2 form a pair of selfmonitoring output cells with a shared control cell that can be used for 1149.1-style
interconnect tests of the AT1/2 pins.

14

See section 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.

234

IEEE 1149.4 Analog Boundary-Scan

The next question is what is the TBIC Control Decode Logic in Figure 7-8.
This logic is used to select from the switching patterns (P0 through P9) given in
Table 7-2 for the switches in Figure 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 section 7.3 where their effects in an 1149.4
environment 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.

The Boundary-Scan Handbook

235

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
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
monitoring the pin state. In this mode, D1 is a bidirectional data cell for AT1
18

The following list of statements assumes Model 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.
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.

236

IEEE 1149.4 Analog Boundary-Scan

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 section 7.4.1 on page 250) which may be used to
support differential measurements (if desired) on ICs that have differential I/O. The
TBIC can also be expanded to support partitioned internal ABn buses (see section
7.4.3 on page 253) when an IC designer desires to separate potential parasitic
coupling between (for example) sensitive input amplifiers and large signal output
buffers.

7.2.4

The Analog Boundary Module (ABM)

The ABM function first introduced in Figure 7-3 (on page 227) is used for two major
purposes. First, it supports 1149.1-style interconnect tests. Second, it supports analog
test metrologies aimed at testing off-chip analog components in extended
interconnect. Figure 7-9 shows a structure of an ABM meeting the requirements of
20
1149.4 that may be used at any analog system pin.
Starting on the left side of Figure 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
20

Note, the AT1/AT2 pins are not analog system pins, but part of the 1149.4 test resource set.

The Boundary-Scan Handbook

237

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 Figure 7-9 we see a one-bit digitizer that creates a digital interpretation
of the voltage on the analog I/O pin. This signal
will appear later in Figure 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
Because this digitization 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,
with the additional goal that a short
between neighboring analog pins should not produce an intermediate voltage that
approximates
Also in Figure 7-9 we see three DC voltages labeled
and
which can be
connected to the analog pin with three switches respectively labeled SL, SH and SG.
Voltages
and
are used to create digital voltage levels on the analog pin in
support of 1149.1-style interconnect tests. Voltage
is used in support of analog
metrology. Therefore
should be a reference quality voltage, which means it is a
voltage source capable of sourcing or sinking current over a defined range without 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
If
either
or
has the reference quality property, then it may be used as
Switches SH and SL may also be conceptual if, for example, there is already a
pin driver present that can produce both
and
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 ICs area. If a
pin driver is capable of driving (say) a 50 ohm 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

238

IEEE 1149.4 Analog Boundary-Scan

(cheap) switches could drive such a load, making it impossible for that pin to
21
participate in 1149.1-style interconnect tests.
Next in Figure 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 twenty switch settings (labeled P0 through P19)
for the switches shown in Figure 7-9. These are shown in Table 7-6.

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.

The Boundary-Scan Handbook

239

In Table 7-6, only 20 of the possible 64 switch settings are listed. This is because
many settings are nonsensical, such as connecting
and
simultaneously to a
pin. The rational for these settings are:
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
P6 and P7 can be used to characterize the quality of the
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
and
sources, or biasing external devices while measurements are made.
P16 connects the pin to the core and disconnects all test circuitry. Used for
mission mode operation of the pin.
P17 through P19 are used to support the requirements of the PROBE and
INTEST instructions (see sections 7.3.4 and 7.3.6, on pages 247 and 248).

The ABM control structure for the switches shown in Figure 7-9 is shown in
Figure 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).

240

IEEE 1149.4 Analog Boundary-Scan

Note that the capture stage of D captures the state of the


signal generated in
Figure 7-9. The C and D cells form a two-cell bidirectional structure (full pin
monitoring) 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
Figure 7-10. Table 7-7 shows how the four Boundary Register cells C, D, B1 and B2
are used to select from the twenty 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 234, 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.

The Boundary-Scan Handbook

241

When cell C = 0 (the first 8 rows), cell D determines whether the


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.

There is one last detail shown in Figure 7-9 on page 237. 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
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 metalization 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
instruction 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.

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.1style testing. Cell D should also be set to 0 when the 1149.1 driver is not enabled, to
prevent the
reference from being connected to the pin.

242

7.2.5

IEEE 1149.4 Analog Boundary-Scan

The Digital Boundary Module (DBM)

Digital Boundary Modules can be constructed in many ways, as discussed in section


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.
The philosophy behind DBM design is different that 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
bidirectional DBMs. In 1149.4 you see a standardized ABM, though the
implementation 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 digitalto-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 Figure 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.

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
section 2.4.1) to further cloud this concept. Neither concept exists for cells in TBIC or ABM
structures governed by 1149.4.

The Boundary-Scan Handbook

243

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 section 7.3.3.
Second, the instructions that target the Boundary Register such as EXTEST (section
7.3.1) and INTEST (section 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
25
the analog pins. The remaining instructions described in the following sections
deserve a bit more discussion.
25

Both HIGHZ and SAMPLE act upon the ATn pins as if they were system digital pins.

244

7.3.1

IEEE 1149.4 Analog Boundary-Scan

The EXTEST Instruction

The mandatory EXTEST instruction (see section 1.5.1 on page 36) is still the
fundamental workhorse of 1149.4. It is used in the familiar role of implementing
1149.1-style interconnect tests. (See Chapter 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,
or
(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 prevents
them from emulating digital signals. In one case, the external impedance (for
example, a 50 ohm 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 Figure 7-2 on page 224 we
saw two analog pins connected through a capacitor. If this capacitor is (say) 100
picofarads, 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 Chapter
3. This works because an ABM has bidirectional capability, allowing it to
simultaneously control and observe its pin.

The Boundary-Scan Handbook

245

When EXTEST is used to support analog measurements, then a given ABM


26
involved in this process 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 Figure 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.

26

The TBIC must also be set up to connect one or both of ATn to ABn signals as needed.

246

IEEE 1149.4 Analog Boundary-Scan

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 Figure 7-14.
To measure impedance Z we first instruct the ATE systems current source to
produce a small current. This current proceeds along AT1 to the ICs 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
This reference completes
the path back through the IC ground and the current source.
Now that a known current is flowing through impedance Z, we need to measure
the voltage across it so we can uses Ohms law to calculate Z. Figure 7-14A shows
that the ATE systems voltmeter is connected to AT2. From there, the TBIC
connects AT2 to internal bus AB2. ABM1 connects AB2 to pin 1, completing the
voltage measurement circuit (ground referenced). This allows the ATE system to
record the voltage at pin 1. Similarly, in Figure 7-14B (for the same current stimulus
configuration) 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 ohms
and that the pathway impedance through the switches is much larger, totaling 5000
ohms. A 50 microampere DC current is used which develops a voltage of 0.2525
volts at the AT1 terminal and only 2.5 millivolts across Z. Assuming a 4 digit
voltmeter with a 10 microvolt resolution, there will be 20 microvolts of potential
error in the two voltage measurements. This translates to +/- 0.4 ohms of error, or
0.8 percent in the final calculated value of Z.
Ther e 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,
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 example, 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
measurements. The node voltage analysis technique [McDe98a, McDe98b]
presented in section 6.2.1 on page 212 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
27

This 1993 work was based on an extremely useful network analysis theorem given by
Tellegen [Tell52].

The Boundary-Scan Handbook

247

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 section 1.5.5 on page 39) 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)
or you
could even have a measurement setup frozen if it doesnt 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 section 1.5.4 on page 39) 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 Figure 7-9 on page 237) and
disconnecting all test resources. The TBIC is also disabled.

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
28
one of the analog pins can be sampled at one time. 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
Figure 7-9, page 237) are closed so that all analog pins are connected to the core
circuitry. 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
instruction to connect none, one or both of the ABn lines to an analog pin. If AB2 is
connected (and AB2 is connected to AT2 by the TBIC) then the voltage appearing
29
on any analog pin can be monitored at AT2 in real time. In all other respects the IC
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.

248

IEEE 1149.4 Analog Boundary-Scan

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
(attenuated) 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 measure30
ments.

7.3.5

The RUNBIST Instruction

The optional RUNBIST instruction (see section 1.5.3 on page 38) 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.
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 section 1.5.2 on page 37) 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 Figure 7-12B back
on page 243. This is because this interface contains I/O for both the digital and
analog 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
second 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 Figure 7-9 on page 237). Further, each
31
analog pin may be connected to none, one, or both of ABn as controlled by the
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.
31

Connecting either AB1 or AB2 requires that the TBIC also be controlled to connect the
appropriate ATn pins.

The Boundary-Scan Handbook

249

content of the ABM control bits. (Switch patterns P16 through P19 in Table 7-6,
page 238, 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
shifted out (see section 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 Figure 7-15.

In 1149.4, INTEST can also be used to test the analog core as depicted in Figure
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, 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.
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.
33

Two pins (each) may be tested if the differential option (see section 7.4.1) is implemented.

250

IEEE 1149.4 Analog Boundary-Scan

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
section 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
connected 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

The Boundary-Scan Handbook

251
34

ABnN bus service the negative side. 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. 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 Figure 4-10 on page
156).
The 1149.4 Working Group had the charter for dealing with analog pins, so this
group couldnt 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
35
opposite states on their pin pairs. Since 1149.4 can emulate 1149.1 for interconnect
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 differential
driver design may be quite difficult (costly).
Debate Item 2: Placing ABMs on differential pin pairs may be fine for
manufacturing 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 Figure 4-10 (page 156). Thus an ABM that simply
disconnects (or places into a high impedance state) the differential driver and
substitutes 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
36
be disconnected on demand by the core disconnect signal. In scenario two, there is
extended interconnect between the differential driver and receiver, typically, lowvalued termination resistors. An ABMs weak drive high/low capability would be
34

A designer may also opt to add the second TBIC to provide for differential access to private
functions governed by private instructions.
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 govern this behavior.

252

IEEE 1149.4 Analog Boundary-Scan

insufficient to create logic states into this loading. We can try to design the
differential driver to act as the source of
and
for the ABM as 1149.4 allows if
that is practical. If not, we will have to omit these differential signals from 1149.1style interconnect testing. This means we will have to determine the integrity of the
interconnect 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
differential signaling. For this discussion, examine Figure 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
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
differential pathway using EXTEST!
There is a solution. If you examine Figure 7-17 closely, you will notice that it
conforms to the general concept of separating analog and digital cores that was
shown in Figure 7-16. In essence there is no analog core per se, just the digitalanalog interface. Note too that Figure 7-16 illuminates the behavior of INTEST. This
is our solution; use INTEST to test for noise rejection of differential signaling.
To do this, set U1 and U2 in Figure 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

The Boundary-Scan Handbook

253

meaning of INTEST, you may ask? Id have to say yes, but I can also hedge by
saying 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 largesignal 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.
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 section 7.2.3 beginning on page 231. 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.

254

IEEE 1149.4 Analog Boundary-Scan

The Boundary-Scan Handbook

255

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
the first set of switches S5 through S10 (all given the suffix a). The control
structure (for a single extension) is depicted in Figure 7-19. Additional extensions
may be added in similar fashion.
The control for partition a (the main body) is identical to that shown in Figure
7-8 (page 234), 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
extension.
Then Table 7-10 describes how Boundary Register cells Ca plus two additional
cells D1k and D2k in the
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
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 governs 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

37

TBIC extention.

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.

256

IEEE 1149.4 Analog Boundary-Scan

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
carrying 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.
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 Kohms; or an impedance that will allow
to flow through the path when the voltage drop across the path is
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 Kohms.
The impedance of the switch that connects
or
to a pin (when switches
are used) should be less that 10 Kohms.
The impedance of the switch that connects VG to a pin is the lesser of 10
Kohms or an impedance that will allow
to flow through the path
when the voltage drop across the path is
This measurement
is made with a
1 KHz AC source.
These expectations of perhaps thousands of ohms in the pathways used for
analog 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
38
39

Others are beyond the scope of the author!


See [Vinn98], Chapter 7, where Steve Sunter gives additional guidance on characterization.

The Boundary-Scan Handbook

257

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 one percent.
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
to
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
and
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

We have precious little experience (at this writing) on which to build a Design for
Test lore for the 1149.4 standard. However, 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 Figure 7-11 (page 242) we saw that we need to take care in laying out ESD
protection 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 metalization paths become narrower with decreases in
IC geometries. This leads us to our first rule.

258

IEEE 1149.4 Analog Boundary-Scan


DFT-27: Eliminate all common conductive paths between a system pin
pad and the ATn switches (SB1 and SB2).

In section 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-28: Partition internal analog test buses (per section 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
Figure 7-20. On a local scale of a single switch, this is similar to the effect we are
pursuing via bus partitioning examined in the previous DFT rule (DFT-28).

As IC feature geometries continue to shrink, the leakage in these switch structures 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.
DFT-29: 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 ICs 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
reference voltage pin
between them since subsequent measurements will use this voltage reference.

The Boundary-Scan Handbook

259

DFT-30: 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-34 on page 261).

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 voltages
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 Figure 7-6 (page 231) we saw ICs with their respective TAP and ATAP pins
connected together. It may turn out that the TAPs are all implemented in a common
technology, (say, 3.3 volt CMOS) but that
and
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
necessary, then plan on grouping compatible ATAPs together with common wiring,
independently of how the TAPs are chained. This will necessitate test access to
multiple 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 additional ATn ports will have to be accommodated, perhaps with
multiplexing to the board level stimulus and measurement resources.
DFT-31: Group compatible ATAPs together on common ATn buses. Be
prepared to accommodate more ATAP buses than there are TAP chains.
With respect to leakage between ATn signals, an extension of DFT-30 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 Figure 7-21. Board leakage may be exacerbated by noclean board manufacturing processes where ionic contamination from manufacturing (typically soldering) is often still present.

40

In extreme cases, for example, ultra-high resolution voltmeters, this guard wire completely
surrounds 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 circuitry 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.

260

IEEE 1149.4 Analog Boundary-Scan

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 Figure 7-21, guards are
shown connected to ground. In general, the board node connected to an ICs
pin
is what should be used for the guard. It is possible that two identical ICs on the same
board may have their
pins connected to different voltages. If guard wires are
needed for both ICs, then they should probably have independent ATn ports.
DFT-32: 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
overkill at system test. This will determine how many ATn ports need to be made
accessible 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 connectors)
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-33: Consider which of all ATn ports in a system will be needed for
system test and provide access to them.
Finally, at system test, we may want to test differential signaling and its
immunity to system noise. This is a digital test, but requires the 1149.4 resource for

The Boundary-Scan Handbook

261

differential testing provided by the INTEST instruction (see section 7.4.2 on page
251). This gives us our last DFT rule.
DFT-34: 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 very
new and we have much yet to learn from experiences with it. Test ICs [Lofs96a,
Nuri97b, Park97] have been invaluable for proving concepts and gaining experience.
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 digital interconnect tests (even in extended interconnect cases) with
1149.4 using todays 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
standard 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 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 book with
the same warning that appeared on the first page, 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
strategic opportunity. I find it interesting that globally, 1149.1 was adopted last in

262

IEEE 1149.4 Analog Boundary-Scan

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.

7.7

EPILOG: WHAT NEXT FOR 1149.1/1149.4?

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 implementation was not much different in cost to a seemingly cheaper design that integrated
(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.41 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.
As this book goes to press, this process is still under way. I cannot reliably
predict what the final result will be. In one case, we could see both 1149.1 and
1149.4 stay they way they are, with one ignoring analog pins and the other filling
that gap. In another scenario, 1149.1 will become the interconnect test standard for
all wiring, and 1149.4 will be the analog metrology standard. In either case, you
should expect that the two will continue their shared goals of interoperability.
Indeed, they will likely become inseparably bound together when printed by the
IEEE. One last time I urge the reader to keep up-to-date with the two Standards, as
change is to be expected as we learn more about testing digital, analog and mixed
signal designs.

41

This idea had been hypothesized for some time. Lee proposed the actual Boundary Register
cell designs within 1149.1 that could make this happen. These proposal cells were
immediately called Whet-cells by the two working groups.

APPENDIX A

BSDL Syntax Specifications

This Appendix is a condensed listing of 19991 BSDL lexicography and syntax. It


does not include the myriad semantic rules found in the BSDL specification as
provided by the IEEE. 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.)
1

Caution: A revision to IEEE 1149.1, including BSDL, is being completed as this book goes
to press. The author believes that the material presented here is substantially similar to that
ultimately published by the IEEE. However, you should obtain the latest IEEE document.

264

BSDL Syntax Specifications

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)
Digits: 0 to 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
significance 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_7 are used today, while BC_8 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_1999 have been
reserved, with the potential for new names to be added later. Therefore, avoid using
identifiers that start with STD_1149_.

The Boundary-Scan Handbook

A.2.4

265

VHDL reserved and predefined words

The identifiers listed below are called VHDL (IEEE Std 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

266

BSDL Syntax Specifications

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 identifiers. The latest edition
of the VHDL standard [IEEE93b] shall be consulted as the final authority.

A.2.5

Strings

A string is defined as a sequence of zero or more characters enclosed between


quotation marks. A quotation mark character is not allowed within a string in BSDL.
For example,
"Mary had a little lamb"
"Fred said ""HELP"""

-- Allowed
-- Not allowed

The Boundary-Scan Handbook

267

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
character. 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.
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.

268

BSDL Syntax Specifications

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
format 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
containing 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 dont-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


external 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>

The Boundary-Scan Handbook

A.4

269

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_1999 |
<other package identifier>
<other package identifier>::= <VHDL identifier>
<use statement>::= use <user VHDL package identifier>.all;
<user VHDL package identifier>::= <VHDL identifier>

270

BSDL Syntax Specifications

<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_1999
<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;
<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> )"

The Boundary-Scan Handbook

271

<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> "
<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>

272

BSDL Syntax Specifications

<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>
: 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>;

The Boundary-Scan Handbook

273

<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
<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

This page intentionally left blank

BIBLIOGRAPHY

Test Generation for VLSI Chips, V. D. Agrawal and S. C. Seth, IEEE Computer
Society Press, Los Alamitos CA, 1988
[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
[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
[Agra88]

276
[Bull87]
[Bush84]

[Cald92]

[Chil91]

[Coom95]
[Covi92]
[Crou94]

[Dahb89]

[DeJo91]

[Derv88]

[EDIF91]
[Fasa89]
[Gall90]
[Gree93]
[Hall89]

[Hans89a]
[Hans89b]

[Hawk85]

[Hill92]

Bibliography
Designing SMT Boards for In-Circuit Testability, M. Bullock, Proceedings,
International Test Conference, pp 606-613, Washington DC, Sept 1987
Measuring Thermal Rises Due to Digital Device Overdriving, G. S. Bushanam
et al, Proceedings, International Test Conference, pp 400-407, Philadelphia PA.
Oct 1984
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
Using Boundary-Scan Description Language in Design, D. Chiles and J.
DeJaco, Proceedings, International Test Conference, pp 865-868, Nashville TN.
Oct 1991
Printed Circuits Handbook,
Edition, C. F. Coombs, Editor, McGraw-Hill,
New York, 1995
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
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
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
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
Using Scan Technology for Debug and Diagnostics in a Workstation
Environment, B. I. Dervisoglu, Proceedings, International Test Conference,
Washington DC, pp 976-986, 1988
EDIF Test Technical Subcommittee Test Extension, Version 2 0 32, EDIF Test
Technical Subcommittee, Oct 1991
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
The Testability Features of the 68040, M. Gallup et al, Proceedings,
International Test Conference, pp 749-757, Washington DC, Sept 1990
Benefits of Boundary-Scan to In-Circuit Test, D. A. Greene, Proceedings,
International Test Conference, p 263, Baltimore MD, Oct 1993
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
The Impact of Boundary-Scan on Board Test Strategies, P. Hansen,
Proceedings, ATE&I Conference, Boston MA. pp 35-40, June 1989
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
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
Boundary-Scan Testing for Multichip Modules, S. C. Hilla, Proceedings,
International Test Conference, pp 224-231, Baltimore MD, Sept 1992

The Boundary-Scan Handbook


[Hewl85]

[Huan97]

[IEEE90]

[IEEE92]
[IEEE93a]

[IEEE93b]
[IEEE94]

[IEEE95]

277

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
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
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
Extended Digital Serial Subset, Proposed IEEE Standard P1149.2/D0.2, IEEE
Standards Board, 345 East 47th St. New York NY 10017, Feb 1992
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
[IEEE90])
IEEE Standard VHDL Language Reference, IEEE Standard 1076-1987, IEEE
Standards Board, 345 East 47th St. New York NY 10017, 1993
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
[IEEE90])
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]1 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
[Inte91]
Intel486 DX Microprocessor Data Book, Intel Corporation, June 1991
[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
[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

Date expected to appear.

278

Bibliography

[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
[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] Limited Access Testing: 1149.4 Instrumentation and Methods, J. McDermid,
Proceedings, International Test Conference, to appear, 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
[Nadi77] Signature Analysis - Concepts, Examples and Guidelines, H. J. Nadig, HewlettPackard Journal, pp 15-21, May 1977
[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
[Nuri97a]2 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. l, pp 4-5, Jan 1997
[Nuri97b]2 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
[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
[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
2

In Japanese.

The Boundary-Scan Handbook


[Park90a]
[Park90b]

[Park91]

[Park93]

[Park97]

[Poss91]
[Pyro95]

[Raym95]

[Reed95]

[Robi83]
[Robi90]

[Robi93a]

[Robi93b]

[Shar92]
[Sing97]

[Sobo82]

[Sunt95]

279

Production Board Testing in a Boundary-Scan Environment, K. P. Parker,


Proceedings, ATE&I Conference, Anaheim CA. pp 11-18, Jan 1990
A Language for Describing Boundary-Scan Devices, K. P. Parker and S. Oresjo,
Proceedings, International Test Conference, pp 222-234, Washington DC, Sept
1990
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
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
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
A Design-For-Testability Architecture for Multichip Modules, K. E. Posse,
Proceedings, International Test Conference, pp 113-121, Nashville TN, Oct 1991
Implementing 1149.1 in the PowerPC RISC Microprocessor Family, C.
Pyron and W. C. Bruce, Proceedings, International Test Conference, pp 844-850,
Washington DC, Oct 1995
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
Improving Board and System Test: A Proposal to Integrate Boundary-Scan and
D. Reed, J. Doege and A. Rubio, Proceedings, International Test
Conference, pp 577-585, Washington DC, Oct 1995
Investigation of Potential Damage Resulting from Digital In-Circuit Testing, R.
Robinson, Proceedings, ATE East Conference, Boston MA. Jan 1983
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
Technology-Independent Boundary-Scan Synthesis (Design Flow Issues), M. F.
Robinson, Proceedings, European Design Automation Conference, Hamburg
Germany, Sept 1993
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
Test Generation for Structural Testing with Boundary-Scan, R. Sharma,
Proceedings, ATE&I Conference, pp 194-205, Anaheim CA. Jan 1992
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
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
The P1149.4 Mixed-Signal Test Bus: Costs and Benefits, Proceedings,
International Test Conference, pp 444-450, Washington DC, Oct 1995

280

Bibliography

[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
[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
[Vinn98] Analog and Mixed-Signal Test, B. Vinnakota, Editor, Prentice Hall, Upper
Saddle River, NJ, 1998
[Wagn91] Enhancing Board Functional Self-Test by Concurrent Sampling, K. D. Wagner
and T. W. Williams, Proceedings, International Test Conference, pp 633-640,
NashvilleTN, 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
[Whet95] Improved Boundary Scan Design, L. Whetsel, Proceedings, International Test
Conference, pp 851-860, Washington DC, Oct 1995
[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

1149
1149.1
1149.4
1149.5

46
2
2, 197
46, 195

A
Addressable Shadow Port
195
Aliasing
128
Ambiguity Class
215, 216
AMD Am29030
160
Analog Boundary Module (ABM) 226, 227,
236, 238-242, 244, 245, 247, 249,
256
221
Analog Boundary-Scan
Analog Test Access Port (ATAP) 228, 230,
232, 236, 250
AT1
228-233, 235, 236, 246, 248,
254, 256, 257
AT1N
228, 250
228-233, 235,236, 246,
AT2
247, 254, 256, 257

AT2N
228, 250
Analog Test Bus
AB1 228, 229, 231-233, 238, 241,
246,
248, 254, 256
AB1N
228, 250
228, 229, 231-233, 238, 241,
AB2
246, 247, 248, 254, 256
AB2N
228, 250
Anti-aliasing PTV
131
114-116,
Application Specific IC (ASIC)
146
190
AT&T 479AA
Automatic Test Equipment (ATE)
2, 3,6,
13, 15, 31, 39, 43, 49, 50, 52, 98,
113-116, 118, 127, 138, 153, 160,
168, 169, 175, 191, 202, 204, 206,
209, 220-222, 249
Automatic Test Program Generation (ATPG)
144

Index

282
B
65, 129, 159, 167, 218
Ball-Grid Array
34, 194
Blind Interrogation
Boundary Register 2, 15, 21, 30, 37, 42, 229
Boundary Register Cell
90
abstraction of
226
Analog Boundary Module
87, 91, 264, 265
BC_0
BC_1 73,79, 87, 89, 91, 92, 102, 164,
176
BC_2
79, 87, 92, 93, 95, 99, 176
88, 93, 94
BC_3
88, 94, 95
BC_4
88, 95, 96, 98, 99
BC_5
79, 88, 96, 97, 102, 176
BC_6
BC_7 88, 93, 96, 97, 98, 177, 178, 264
91
BC_99
74
bidir
89
bidir_in
89
bidir_out
90
capture data
24, 79, 177
cell count
74, 89
clock
constant "0/1" capture
179
23, 74, 89
control
controlr
74, 89
Digital Boundary Module
225
24
flawed design
21
general design
hardware fault insertion
163
74, 89
input
31,74, 89
internal
26
internal cell
26
logical symbol
78
merged cells
observe_only
27, 39, 74, 80, 89
optimizing
27
74, 89
output2
74, 89
output3
21, 27
parallel in
21, 27
parallel out
24
reversible cell
self-monitoring output
176
22
shift in
22
shift out
24
signal inversion
23
single-cell bidirectional
26
three-cell bidirectional
23
two-cell bidirectional
Boundary-Scan
Description
Language
(BSDL)
2, 24, 34, 41, 43, 49
182
certifying

damaged by electronic mail


180
180
verification
180
verification test
190
Boundary-Scan master
BSDL
See BSDL Attribute below
attribute
103
automated creation
Boundary-Scan Register Description 72,
102
89
Cell Description Constants
58
comment
64, 102
component conformance
damaged by electronic mail
60
77
Design Warnings
65
Device Package Pin Mapping
58, 61, 101
entity
100
extensions
62
generic parameter
grouped port identification 66, 75, 102
58
Identifier
IEEE version
51, 64, 68, 71
initial (1990) version
51
Instruction Register description 69, 102
76
INTEST Execution Description
62
logical port
57
pad-to-pin mapping
62
PHYSICAL_PIN_MAP
62
PIN_MAP
85
pre-defined constants
75
RUNBIST Execution Description
73, 113
safe bit
52
scope
63
standard use statement
string
58
57
structure
subset and standard practice of VHDL 50
67, 102
TAP port identification
55
to/from synthesis systems
176
type CELL_INFO
52
use as test driver
64, 102
Use statements
user defined boundary cells
177
user defined package
177
77
User Extensions
104
Version 0.0 parser
64
version control
58, 84
VHDL package
58, 84
VHDL package body
writing
101
BSDL Attribute
BOUNDARY_LENGTH 72, 73, 75, 86,
265, 272

The Boundary-Scan Handbook


BOUNDARY_REGISTER 72, 73, 78,
79, 86, 91, 113, 116, 181, 265, 272
BSDL_EXTENSION
101
COMPLIANCE_PATTERNS
68, 87,
265, 270
COMPONENT_CONFORMANCE 64,
85, 265, 270
DESIGN_WARNING 77, 87, 265, 273
IDCODE_REGISTER 70, 86, 265, 271
INSTRUCTION_CAPTURE 69,70, 86,
107,120,174,179, 265, 271
INSTRUCTION_LENGTH 69, 86, 265,
271
INSTRUCTION_OPCODE 69, 70, 86,
265, 271
INSTRUCTION_PRIVATE 69, 70, 72,
86, 265, 271
INTEST_EXECUTION
76, 86, 265,
272
PIN_MAP
65, 85, 265, 269,
270
PORT_GROUPING
66, 86, 156, 265,
270
REGISTER_ACCESS
71, 72, 76, 86,
265, 271
RUNBIST_EXECUT1ON
76, 86, 265,
272
TAP_SCAN_CLOCK 67, 85, 265, 270
67, 85, 265, 270
TAP_SCAN_IN
TAP_SCAN_MODE
67, 85, 265, 270
TAP_SCAN_OUT
67, 85, 265, 270
TAP_SCAN_RESET
67, 85, 265, 270
USERCODE_REGISTER 70, 86, 265,
271
buffer
See BSDL, logical port
Bypass Register
10, 20, 30, 33, 39, 52,
121, 229
capture bit
20

C
Capture Flip-Flop (CAP)
21, 27, 35, 89,
90, 99, 111, 150, 179
31
Chains
analog busing
230
194
broken
chain ordering
184
configurations
182
dynamically reconfigurable
183
192
extra shift stages (pad bits)
119
integrity
192
linked
193, 195
multidrop system
32
multiple simple

283
Siamese
32, 119, 182-184
simple 31, 119, 182, 185, 192, 193,230
testing
119
167, 218
Chip-on-Board
Chip-Scale Packaging
218
Complex Programmable Logic Device
114, 160, 161, 162, 196
(CPLD)
Compliance Enable Pins
41, 68, 75, 102,
189
Compliance limit
current
201
voltage
200, 246
Confounding
128
Counting Sequence
123, 130, 131

D
Data Register
10, 11, 20
Boundary Register 2, 15, 21, 30, 37, 42,
72
Bypass 10, 20, 30, 33, 39, 52, 121, 229
14
capture data
Device Identification 10, 12, 18, 20, 33,
34, 52, 70
15
halt shifting
10
mode of operation
15
parallel hold latches
14
shift portion
93
shift ripple
20
target register
21
user-defined
167
Design for Testability (DFT)
182
board level
Built-in Logic Block Observer (BILBO)
168
169
Integrated Circuit level
Level Sensitive Scan Design (LSSD) 168
193
system level
Designated driver
126, 127
10, 12, 18,
Device Identification Register
20, 33, 34, 52, 70, 71, 72
20
capture pattern
3, 5
Device Under Test (DUT)
66, 156, 251
Differential Signaling
252
EXTEST Paradox
252
noise rejection
Digital Boundary Module (DBM) 225, 227,
242
118, 119, 125
Drive conflicts
187
board level
duration
125, 188
Driver
74
"Keepers"
39, 74, 75, 78, 80
asymmetrical

Index

284
damage resistant
Disable Result
disabling
ECL Open Emitter
TTL Open Collector
Dual-Slope Integrator

175
See Table 2-3
188
75
75
207-209

E
43,
Electronic Design Automation (EDA)
45, 50, 169
Electrostatic Discharge (ESD) 105, 121, 241
Emulation
7,41
Extended Interconnect
223
252
EXTEST Paradox

F
Fault
3
detected
116
dictionary
3
failure mechanism
3
model
Field-Programmable Gate Array (FPGA) 26,
114, 160, 161, 162, 196
Field-Programmable IC
26, 30, 45, 68
cook time
161
30
blank page
hard-wired
30
184
in chains
30
input/output blocks (IOBs)
161
parallel programming
41, 160
programming
6
Fine-Pitch

G
175
Gallium Arsenide
1, 261
Garbage In, Garbage Out
Grandfathering
65
170
Ground-Bounce
199
Guardband
Guarding
204, 212, 220, 222
analog
digital
39
206
errors

H
57
Hardware Description Language
57
Verilog
57
VHDL
163
Hardware Fault Insertion
153
Homing sequence
Hyper-Text Markup Language (HTML) 180

I
46
IEEE 1149 Testability Bus Standards
50
IEEE Standard 1076
IEEE Standard 1149.1 1, 7, 16, 46, 52, 168
29
architecture summary
44
automation
8
Basic Architecture
Benefits
43
Conformance
and
Documentation
49
Requirements
42
Costs
36
critical mission
53
ensuring compliance
40
Extensibility
42, 79
gate overhead
43
increased design time
inserted delay
43,79
43
lack of discipline
lack of hierarchy
158
33
Non-Invasive Mode
42
pad overhead
36
Pin-Permission Mode
40
private instructions
40
public instructions
44
reuse of tests
44
standardized access
41
Subordination
45
Trends
40
user-defined instructions
42
yield loss
IEEE Standard 1149.4
46, 221
Analog Boundary Modules
228
228
Analog Test Access Port
228
Digital Boundary Modules
227
general architecture
Test Bus Interface Circuit
228
IEEE Standard 1149.5 7, 46, 47, 183, 194,
195
IEEE/ANSI Standard 1149.1
96
Supplement A
IEEE/ANSI Standard 1149.1-1990
168
Supplement A
2, 24, 64, 136, 177
2
Supplement B
in bit See BSDL, logical port
in bit_vector
See BSDL, logical port
In-Circuit Test
197
analog
Bed-of-Nails
5-7, 115, 122, 137, 138,
151, 152, 154, 155, 191, 197,
202-206, 210-212, 218-221
Fixturing 5, 6, 114, 197, 202, 204, 220
multiplexed resources
116

The Boundary-Scan Handbook

285

overdrive damage
39, 125, 153
inout
See BSDL, logical port
Institute of Electrical and Electronics
2
Engineers (IEEE)
10
Instruction Mode
10-14,
Instruction Register
16-19, 29, 30, 33-35, 53, 69, 70, 102,
107, 108, 110, 112, 116, 118, 120,
121, 158, 171, 174, 175, 180, 192,
229
capture pattern 13, 17, 69, 107, 171, 174
halt shifting
13
69
length
69
opcodes
parallel hold rank
16
sample cell design
19
16
shift rank
shift ripple
13, 16
13
shifting
In-System Configuration (ISC) 41, 145, 160
4
Intel 8008
Intel 80486DX
43, 181
43
Intel Pentium Pro
Interconnect
140
adjacent nodes
counting sequence
123
differential
224
224
extended
interaction test
138
223
logical
105, 125, 131
opens
224
physical
pin-level diagnostic (shorts)
141
shorting radius
140
shorts
105, 124, 126
test length
127, 128
122
testing
undetected opens
133
walking-bit sequence
128

206-208
Operational amplifier
out bit
See BSDL, logical port

Joint Electron Device Engineering Council


(JEDEC)
33
Joint Test Action Group (JTAG)
1,113

K
204

Kelvin measurement

L
4
Large Scale Integration (LSI)
Level-Sensitive Scan Design (LSSD) 41, 68,
92, 168
Linear Feedback Shift Register (LFSR) 41,

141
linkage
Lobotomy Problem
Logic Simulator

See BSDL, logical port


8, 36, 178, 192
3

M
Manufacturing Faults
222
dead component
168
168
missing component
168
open solder
168
solder shorts
wrong component
168, 174
Matsushita Electric Industries
46
204
Measurement errors
Measuring impedance
200
6-wire measurement
206
imaginary waveform
210
reactive devices
210
real waveform
210
Measuring Operational Amplifier (MOA)207
Mixed Logic Families
186
Mixed-Signal
217
Modes of Operation
Extensible
8
Non-Invasive
7, 147, 178
Pin-Permission
7, 108, 178, 192
212
Monte Carlo simulations
42
Motorola 68040
Multi-Chip Module (MCM) 145, 157, 158,
167, 196
Multidrop Systems
193
Multiple IDCODEs
71

N
Node Voltage Analysis
Limited Access

212, 213
215

P1149.2
P1149.3
Packaging Hierarchy
Parallel Test Vector (PTV)
Parasitic devices
Performance Tests
Power
Applying
Cycling (reset)
distribution
Removal (safety)

46
46
145
112, 127
198
198

125, 176
193
190
176

Index

286
separate analog and digital
Power/Ground Distribution
Private Instructions

190
170
70

R
202, 204, 222
229
202, 229
202, 229
229
228
228
228, 231
228, 231
231

Reed relay
area
off-resistance
on-resistance
switching time
Reference voltages
G
VH
VL
VTH

S
Scan-Path Linker
191
Self-Monitoring Output
37
121, 122
Sentinel bits
Sequential Response Vector (SRV) 112, 126
Sequential Test Vector (STV) 112, 126, 127,
128
Serial Vector Format (SVF)
144
shorting radius
140
229
Silicon switches
T switch
258
area
229
bipolar
229
conceptual
237
crummy
230
leakage
258
off-resistance
229
on-resistance
229
parasitic coupling
258
switching time
229
230
symbols
224
Simple Interconnect
3
Single Stuck-at fault model
Source
200, 201, 212, 246
current
201, 202, 204, 210, 237
voltage
64, 83
STD_1149_1_1990
64
STD_1149_1_1993
58
STD_1149_1_1994
STEM 149_1_1999
64, 85, 89
Surface-Mount Technology (SMT) 5, 6, 44,
45, 159, 167, 218, 229
Synchronizing Sequence
10, 107
System Logic
7, 8, 29, 33, 35-39,
42, 79, 116-118, 147

T
TAP Controller
10, 12-16, 18, 20, 22, 32,
41, 108, 174, 233, 239
asynchronous reset
10
data column states
11,12
finite state machine
10
instruction column states
11, 12
12
power-up reset
state diagram
10, 11, 107
state transitions
11
synchronizing sequence
10
temporary state
12, 13, 14
TAP Controller State
CAPTURE-DR 14, 15, 16, 52, 72, 109,
139, 150, 176
CAPTURE-IR
13, 15, 16, 18, 70,107,
120, 174
EXIT1-DR
14, 15, 110
EXIT1-IR
13, 15, 18, 107
EXIT2-DR
15
EXIT2-IR
14, 18
PAUSE-DR
15
13, 18
PAUSE-IR
RUN-TEST/IDLE
12, 111, 118, 141,
161
SELECT-DR-SCAN
12, 171
SELECT-IR-SCAN
12, 111
14, 15, 109, 141
SHIFT-DR
SHIFT-IR
13, 16, 18, 107
TEST-LOGIC-RESET 12, 18, 57, 107,
162, 178
164
Update-DR
UPDATE-DR
15, 111, 171
UPDATE-IR
14-18, 71, 108, 171
TAP Instruction
BYPASS 12, 18, 20, 33, 34, 36, 57, 69,
71, 103, 106, 109, 121, 141, 151,
158, 161-163, 175, 181, 187, 193,
194, 243, 265, 268, 271
39, 106, 151, 161, 162, 181,
CLAMP
247, 265, 268
EXTEST 36, 37, 39, 57, 69, 70, 71, 89,
99, 103, 106, 109, 111, 112,117,
146, 151, 153, 162, 176, 179, 185,
244, 246, 265, 268, 273
39, 76, 96, 99, 106, 146, 151,
HIGHZ
161, 162, 181, 240, 243, 247, 265,
268, 272
IDCODE 12, 18, 20, 33, 34, 36, 70-72,
99, 103, 106, 109, 121, 162,163,
178-180, 194, 243, 265, 268, 271
INTEST 37, 38, 39, 43, 54, 74-76, 89,

The Boundary-Scan Handbook


92-94, 96, 102, 106, 116-118,
161-163, 174, 242, 248, 249, 250,
265, 268, 272, 273
161, 163
ISC_DISABLE
ISC_ENABLE
161, 162
ISC_PROGRAM
161
PRELOAD 35, 38, 39, 57, 70, 76, 106,
112, 118, 161, 162, 163, 164, 181,
243, 265, 268
PROBE
239, 243, 247, 248, 250, 258
RUNBIST
12, 38, 39, 75, 96, 99, 102,
106, 118, 119, 141, 168, 178, 181,
242, 248, 265, 268, 272
SAMPLE 35, 36, 57, 70, 89, 103, 106,
147-150, 181, 243, 248, 265, 268,
273
USERCODE 20, 34, 70, 181, 243, 265,
268, 271
21,71, 102, 179
user-defined
167
Tape Automated Bonding (TAB)
Target Register 15, 20, 33, 38, 57, 76, 110,
171
TCK
185
buffered
11, 14-16, 171
falling edge
171
ground bounce
187
level translation
maximum clock frequency
68
10, 13-15
rising edge
68
stop state
10
Test Clock
TDI
pin placement
169
120, 169
shorted to TDO
10
Test Data In
TDO
actively driving
15
15
disabled
shifting data
15
10
Test Data Out
Test Access Port (TAP)
8, 29, 159, 230
222
compatibility with 1149.4
10
Test Clock (TCK)
10
Test Data In (TDI)
10
Test Data Out (TDO)
10
Test Mode Select (TMS)
10
Test Reset (TRST*)
Test Bus Interface Circuit (TBIC) 228, 229,
231, 233-236, 245, 247, 248, 250,
251, 253, 255
189
Test Reset (TRST*)

287
Testing
1
Ad-Hoc
197
analog In-Circuit
background system diagnostics
165
118
Basic BIST Test Algorithm
112, 126
Basic Test Algorithm
41
board-level self-test
119
Boundary-Scan chains
Built-in Self-Test (BIST) 118, 141, 193
chain integrity 13, 17, 18, 119, 169, 174
10
CMOS IDDQ
150
Concurrent Monitoring
122, 136
Connection
control of critical nodes
188
Customized
141
146
DC parametrics (IC)
differential pins
251
Edge Connector Functional 2, 168, 211
159
Emulationfunctions
116
fault dictionary
hardware development support
159
high frequency
222
2, 3
Hot Mock-Ups
hybrid digital/analog
41
7, 116
IC
IC BIST
118
4, 46, 113
In-Circuit
114, 115
In-Circuit Boundary-Scan
138
Interaction
122
Interconnect
Interconnect Opens
131
126
Interconnect Shorts
211, 215,218,261
Limited Access
215
Limited Access Node Voltage
35
logic analyzer
155
Mixed Digital/Analog
7
Module
157
Multi-chip Modules
node voltage
213
252
noise rejection
154
Non-Digital devices
151
Non-Scan ICs
203
parallel impedances
198
performance
113
personal tester
7
Printed Circuit Board
141
pseudo-random patterns
147
Sample mode
12, 38
self-test
41, 141, 150, 167
Signature Analysis
4
Simulator-based Functional
113, 128
stop-on-first-fail

Index

288
System Level
7
undetectable shorts
153
unpowered analog
201
unpowered shorts testing
115, 137
X-Ray Laminography
129
Texas Instruments 74ABT8996
195
190
Texas Instruments 74ACT8990
Texas Instruments 74ACT8997
183, 191,
195
Texas Instruments 74ACT8999
183, 191.
195
Texas Instruments 74BCT8244
40, 42
Texas Instruments 74BCT8373
174
Texas Instruments 74BCT8374 58, 70, 78,
80, 174
Through-Hole Pin
5
TMS
buffered
185
level translation
187
Test Mode Select
10
Tolerance
distribution
199
nominal values
199
of component values
199, 204, 214
TRST*

10
10

assertion
Test Reset

U
Update Flip-Flop (UPD) 21, 27, 35-37, 39,
73, 90, 163, 176
Update Flip-Flop (UPD)
111
UUT
See Device Under Test (DUT)

V
Very Large-Scan Integration (VLSI)
42,
115, 167, 170, 171
VHDL identifiers
See BSDL, identifier
VHSIC Hardware Description Language
(VHDL)
50
Vias
7
167
blind

W
128, 130

Walking-bit sequence

X
X-Ray Laminography
X-Y Coordinate Location Data

129
7, 140

You might also like