Professional Documents
Culture Documents
SECOND EDITION
Analog and Digital
by
Kenneth P. Parker
Hewlett-Packard Company
eBook ISBN:
Print ISBN:
0-306-47656-8
0-7923-8277-3
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
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.3.1
1.3.2
1.3.3
1.3.4
1.3.5
1.3.6
1.3.7
1.3.8
1.4.1
1.4.2
1.4.3
1.4.4
1.4.5
BYPASS
IDCODE
USERCODE
SAMPLE
PRELOAD
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
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
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
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
263
263
264
267
269
273
275
Index
281
xi
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
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
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
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.
CHAPTER
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.
1.1
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
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.
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.
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
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.
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.
packing density, ICs might be mounted on both sides of the board. This all led to
access problems; some board nodes may be inaccessible to In-Circuit nails.
Notice I did not list fine-pitch package leads as a problem. One of the fallacies of
SMT testing is that fine-pitch packages are automatically inaccessible to nails. This
is a carryover from the days when In-Circuit nails were targeted at package pins.
With fine pitch packages, this is not feasible. What must be done is to target inter-
layer vias10 or deliberately placed test pads. (See [Bull87] for a practical 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
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.
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
10
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 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.
11
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
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
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
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.
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
1.3.2
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.
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
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.
19
20
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).
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.)
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
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
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.
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
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.
25
26
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.
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
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
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.
1.3.6
29
Architecture Summary
30
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.
31
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
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
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*.
33
29
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
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
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
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
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.
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
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.
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
40
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
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.
41
1.7
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
software should be able, when notified, to handle many of the implications. See
section 5.2.5 for more discussion.
1.8
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.
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
44
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.
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
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
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.
47
CHAPTER
50
Even within the VHDL world, there are full and partial implementations of the VHDL
language.
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
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.
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
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.
55
2.1.3
Synthesis
56
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
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
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.
59
60
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'
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
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>;
------------------
(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
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
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
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
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-
64
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;
(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
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.
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
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
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
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
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
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);
The choice of port names used here helps a reader maintain the plus and minus
relationship, but is not required by BSDL.
68
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 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.
2.3.10
69
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 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),".
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
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
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).
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
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
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
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.
73
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
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
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
76
2.3.15
26
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
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 "
&
&
78
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
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.
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
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
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.
81
82
83
STD_1149_1_1999.all;
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);
84
&
&
85
2.6.1
STD_1149_1_1999
TAP_SCAN_IN
:
TAP_SCAN_OUT :
TAP_SCAN_CLOCK :
TAP_SCAN_MODE :
TAP_SCAN_RESET:
boolean;
boolean;
CLOCK_INFO;
boolean;
boolean;
86
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;
87
EXTEST, PI),
SAMPLE, PI),
INTEST, PI),
EXTEST, PI),
SAMPLE, PI),
INTEST, PI),
EXTEST, PI),
SAMPLE, PI),
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) );
88
PI),
PI),
PI) );
:=
(CONTROL, EXTEST, PI),
(CONTROL, SAMPLE, PI),
(CONTROL, INTEST, UPD) );
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.
2.6.2
89
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
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.
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
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
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.
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
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.
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
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.
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
requested pin state. This is doubly important when the signal being driven does not
travel to other Boundary-Scan ICs.
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!
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
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.
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.
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
: CELL_INFO;
: CELL_INFO;
end USER_PACKAGE;
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) ) ;
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) );
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
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.
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
104
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
106
Boundary-Scan Testing
3.1
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
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
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.
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.
111
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
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.
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 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
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
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.
115
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
117
14
Register . This control allows us to set safe values on the ICs outputs while
INTEST in functioning.
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.
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.
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
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
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.
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
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.
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.
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.
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
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.
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.
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.
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.
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
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.
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.
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
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.
139
31
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.
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
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.
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
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.
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
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
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
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
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
148
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.
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
4.3
CONCURRENT MONITORING
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.
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
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.
153
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
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
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
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
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.
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.
4.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
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.
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
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
4.9
IN-SYSTEM CONFIGURATION
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.
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
162
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.
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.
164
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.
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.
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.
CHAPTER
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
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.)
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
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
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
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
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.
171
172
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.
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
5.1.3
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).
175
5.1.4
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.
176
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.
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.
178
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
5.1.8
IDCODEs
179
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
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
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.
181
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
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.
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
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.
5.2.2
185
TCK/TMS Distribution
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
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
5.2.3
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
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
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
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
28
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.
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
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
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.
191
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
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
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.
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
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.
195
5.3.2
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
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
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
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
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
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.
200
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.
201
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
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.
203
204
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
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.
205
Circuit nails. This configuration is rarely used unless we need a very precise
measurement of a very small resistance R.
206
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
207
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
yields:
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.
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.
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
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
211
allows us to calculate the
212
6.2.1
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.
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
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
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.
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
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.
216
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.
17
One node is always used as the reference node for voltage measurements.
217
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
218
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.
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
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.
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 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
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.
223
7.1.1
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
Voltage addition by the capacitor could also cause signals to go out of normal operating
range with possibly damaging effect.
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
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.
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.
228
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.
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
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
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 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
7.2.3
231
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
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.
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
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.
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
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 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.
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
(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.
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
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.
241
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
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.
243
Both HIGHZ and SAMPLE act upon the ATn pins as if they were system digital pins.
244
7.3.1
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.
245
26
The TBIC must also be set up to connect one or both of ATn to ABn signals as needed.
246
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].
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 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
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 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
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 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 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.
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
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.1
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
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
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
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
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
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
With this control structure, any extension can be connected to the ATn lines, and,
any ABn bus can be characterized independently.
7.4.4
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
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
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
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
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.
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
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
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
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
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
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
A.2.1
Character set
"&()*,-.:;
< = >
A.2.2
Identifiers
A.2.3
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_.
A.2.4
265
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
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
-- Allowed
-- Not allowed
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"
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
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
A.3.2
Lexical atoms
A.3.3
A.4
269
BSDL SYNTAX
270
271
272
273
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
[Huan97]
[IEEE90]
[IEEE92]
[IEEE93a]
[IEEE93b]
[IEEE94]
[IEEE95]
277
[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
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.
[Park91]
[Park93]
[Park97]
[Poss91]
[Pyro95]
[Raym95]
[Reed95]
[Robi83]
[Robi90]
[Robi93a]
[Robi93b]
[Shar92]
[Sing97]
[Sobo82]
[Sunt95]
279
280
Bibliography
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
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
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
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
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,
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