SINCE THE PUBLICATION of the ANSI/IEEE

1149.1 boundary-scan standard in 1990,

1
the
electronics manufacturing industrys accep-
tance of boundary-scan technology has
grown steadily. Initially, the industry focused
on applying boundary scan to board manu-
facturing test, particularly boards with limit-
ed access by traditional, in-circuit bed-of-nails
testers. The increasing use of ball-grid-array
packaging and other difcult-to-access de-
vice-packaging styles, such as thin-shrink
small-outline, accelerated the adoption of
boundary scan. The technology is now clear-
ly in the mainstream.
Recently, in-system-programming appli-
cations have further increased interest in the
standard. The advantages of in-system pro-
gramming are many:
2
I It simplifies inventory management.
I It reduces or eliminates the need for sep-
arate programming stations.
I It enables rapid prototype conguration
and reconguration (design exibility).
I It eliminates the need for on-board
sockets.
I It reduces risk of damage from me-
chanical handling and electrostatic
discharge.
I It allows upgrades for system and eld-
service debugging.
Many CPLD and FPGA suppliers support the
use of 1149.1 as a gateway to in-system pro-
gramming and reprogramming of their
devices.
Clearly, however, boundary scan does
much more than solve board test and in-
system-programming problems. A decision
to use boundary scan for either of these pur-
poses usually opens a discussion about a
products life-cycle test requirements and
test strategy. Because boundary scan allows
reuse access to other test structures such as
internal scan and built-in self-test, INSCAN
(scan through test access port) and RUN-
BIST instructions are now common require-
ments of complex full-custom devices.
These instructions, which can be invoked at
any time during a products life, have
tremendous diagnostic value during system
integration and eld-service operations. An
early example of this use of boundary scan
is the design of the electronic systems in the
Iridium satellites.
3
A more-recent example is
Stratus Computers fault-tolerant computers.
4
Additionally, we are now seeing the migra-
tion of boundary-scan concepts from boards
to system-on-chip devices. With its ideas of test-
access mechanisms and core wrappers, the
IEEE P1500 Embedded-Core Test Standard ac-
tivity is moving very close to 1149.1 structures.
5
In effect, by allowing various forms of de-
sign-for-test structures to be connected for
reuse, boundary-scan technology makes
possible an Internet of Test (an idea sug-
gested by Johan Renberg of Integrated
Systems Scandinavia, Sweden). This article
explores this aspect of boundary scan and
describes the technologys role in prototype
board debugging, volume board manufac-
turing, system integration, and eld service.
Bounda r y Sca n:
The Internet of Test
BOUNDARY SCAN
34 0740-7475/99/$10.00 1999 IEEE IEEE DESIGN & TEST OF COMPUTERS
Bounda ry sca n ena bles
us to reuse tests
developed a t different
design levels a nd in
different life-cycle
pha ses. By fa cilita ting
communica tion betw een
previously isola ted
a rea s, built-in bounda ry
sca n becomes w ha t the
a uthors ca ll the Internet
of Test.
MIKE W ON DOLOW SKI
Network Equipment
Technologies
BEN BEN N ETTS
Bennetts Associates
ADAM LEY
Asset InterTech
J ULYSEPTEMBER 1999 35
Bounda r y-sca n test
The 1149.1 standard denes a simple serial test bus that
we can implement hierarchically at all levels: chip, multi-
chip module, board, and system. At each level, we daisy-
chain all 1149.1-compliant (or boundary-scannable) devices
to form a long scan chain, which is available at the next-
higher level. For example, we daisy-chain all the boundary-
scannable chips on a board by connecting the Test Data Out
(TDO) of one chip to the Test Data In (TDI) of the next. We
place the rst chips TDI and the last chips TDO off board
to be used at the next level.
At the lowest level is the boundary-scannable chip (Figure
1). On the chip, special test logic is associated with each I/O
pin, as dened in the 1149.1 standard. This logic enables the
1149.1 test bus to scan in data for each I/O pin and to scan
in a pattern that determines which I/O pins will be enabled
to drive their data out. Once a test is set up, a capture caus-
es the chip to store the values on each of its I/O pins. This re-
sult can be scanned out of the chip for analysis.
Thus, boundary scan gives us controllability and observ-
ability of each I/O pin of each boundary-scannable chip on
the board, which is very useful for testing the board. Access
to these nets by a test probe is unnecessary. For a board con-
taining only boundary-scannable components, we can sim-
plify or even eliminate the test fixture and reduce or
eliminate the physical intrusion of the test probe.
However, a fully boundary-scannable board is difcult to
realize. Many standard digital components lack 1149.1 sup-
port, and most boards also have some analog and discrete
components. Nevertheless, partially boundary-scannable
boards can also be tested with 1149.1. On a partially
scannable board (Figure 2), we daisy-chain the 1149.1-
compliant devices to form the boards scan chain and hook
up the non-1149.1 devices in their normal conguration. The
boards nets can be divided into different sets depending
on their connectivity to 1149.1 and non-1149.1 devices. The
number of nets in each set determines how much coverage
1149.1 testing can achieve.
Grow th of PC-ba sed testers
To take full advantage of boundary scan throughout a
products life cycle requires supporting test technology that
is both versatile and portable. During the latter days of JTAG,
the organization that created the standard, several compa-
nies began to program PCs with the boundary-scan integri-
ty and interconnect algorithms. Indeed, they even
considered the parallel printer port to be a crude form of
driver/sensor channels!
Today, a variety of low-cost, portable boundary-scan
testers are available, based on the PC as a hardware plat-
form and equipped with a wide range of test capability. Their
hardware usually consists of a PC, either a PC card or ex-
pansion-slot driver/sensor channel card, and a buffer inter-
face to the board under test.
On the software side, these testers come equipped to han-
dle both boundary-scan and non-boundary-scan compo-
nents on the board, where the testers can access the latter
components via the boundary-scan components. Test pro-
grams consist of the following ve stages:
Board-level boundary-scan-chain integrity test (test-
ing the tester). This tests purpose is to ensure the boundary-
scan infrastructures integritythe correct distribution of
TCK, TMS, and TRST* signals, as well as the soundness of the
device-TDO to device-TDI interconnects. This test usually en-
tails either loading and executing the default instruction on
Core
Scan in
Scan out
Boundary-scan cell
Data in
Data out
F
l
i
p
-
f
l
o
p
F
l
i
p
-
f
l
o
p
TDI TDO
Figure 1 . Boundary-scannable chip. An 1149.1-compliant
component has one scan chain each for inputs, outputs, and
enables.
TDI TDO
Non-
1149.1
device
Non-
1149.1
device
1149.1 device 1149.1 device
Figure 2 . Partially scannable board.
BOUNDARY SCAN
36 IEEE DESIGN & TEST OF COMPUTERS
power-up (IDCODE or BYPASS) or loading and scanning out
the 01 checkerboard sequence in the instruction register.
6
The rst technique has the advantages of not requiring a pin-
permission instruction and allowing identication of the cor-
rect device for devices that have an identication register.
The second technique allows PRELOAD to set up safe con-
ditions prior to the use of EXTEST for interconnect testing.
Interconnect tests. To compute interconnect tests, most
commercial PC-based tester products use the enhanced bi-
nary count algorithm, augmented by the all-1s and all-0s pat-
terns.
7, p. 130
This algorithm works ne for both detection and
diagnosis on pure interconnectsthose that both start and
end with boundary-scan cells. Difculty arises when the in-
terconnect is between a boundary-scan and a non-
boundary-scan device. In fact, in creating board-level
interconnect tests, test programmers spend most of the time
trying to enhance the algorithms performance by provid-
ing additional information about the nature of the ports on
the non-boundary-scan device. For example, is the port an
input, an output, a three-state output, or a bidirectional port?
If three-state, what control value will constrain it to high-Z
(high impedance)? If bidirectional, what control values will
constrain it to input or output? In either case, can we estab-
lish constraint values from other boundary-scan cells? This
information, known as characteristic data, allows the algo-
rithm to determine safe ways of testing for faults on nets that
connect boundary-scan and non-boundary-scan devices.
See Flint
8
for further discussion of this topic, including an
interesting example of interaction issues.
Ultimately, the lack of controllability and observability of
the non-boundary-scan nets becomes the limiting factor in
coverage of board opens and shorts by interconnect test al-
gorithms. This factor could well justify the careful use of real
nails. On a limited-access board, where, typically, only 40%
to 60% of the interconnects are routed on the surface, a com-
bined real-nail, virtual-nail test strategy is an effective way
of improving fault coverage.
Device existence tests. The preceding two stages make
no use of the core functionality of the device itselfjust the
1149.1 structures around the device. Usually, we perform a
brief existence testare you who I think you are?to en-
sure that the correct device is in place, rather than, say, a
pin-for-pin alternative. These confidence tests are usually
based on INTEST, INSCAN, IDCODE, or RUNBIST types of
instructions.
Testing non-boundary-scan devices with boundary-
scan devices. In some cases, a non-boundary-scan device,
or cluster of devices, is fully controllable and observable by
boundary-scan devices (known as a fully embraced clus-
ter). We can apply tests to the cluster to determine the pres-
ence or absence of opens and shorts within the cluster. Such
tests are usually generated manually or derived from simu-
lation test benches. Application of these tests is relatively
slow, but their purpose is to test for opens and shorts, not
for correct functional behavior. Again, we use characteris-
tic data to prevent adverse interactions between boundary-
scan and non-boundary-scan devices during testing.
Testing on-board memory devices. The nal stage is
testing on-board memory devices such as RAM and ROM for
opens and shorts. If the board contains a microprocessor, it
is often used to apply simple sequences to the RAMs and
carry out a read and data compaction on the ROM content.
If there is no microprocessor, we can apply RAM tests via a
boundary-scan interfacein effect, using boundary scan to
write data into the RAM and read it back. The data, designed
to detect open and short faults, is usually based on checker-
board and inverse-checkerboard patterns.
Prototype-boa rd debug
In the manufacturing process, boundary scan supple-
ments or replaces bed-of-nails testing that would otherwise
be necessary to verify the electrical connectivity of the
boards components. However, we frequently overlook an-
other major benet. Using boundary-scan testing on proto-
type boards in the development lab is at least as important
as using it for testing production boards.
9,10
Manufacturing a board is a complex process subject to a
variety of problems that result in a less-than-perfect final
board. Wrong components may be installed, or correct com-
ponents may be installed with the wrong orientation. The
soldering of ne-pitch parts can result in various shorts be-
tween pins or opens on a given pin. Cuts or wires added to
the board are also subject to problems. Board testing gen-
erally means detecting these problems to ensure that the
manufactured board matches the board we intended to
manufacture. This fault detection requires some sort of struc-
tural testing.
Prototype boards have all the manufacturing problems
that a production board has. However, prototype-board test-
ing must go further. The purpose of prototype boards is to
verify the design itself. Thus, in addition to fault detection,
prototype-board testing must include design verification.
We accomplish this with simple functional testing and/or
verication of the board as part of a larger system.
Often, prototype boards are manufactured and delivered
to the development engineers with minimal or no structural
testing, and so they are not guaranteed fault free. Early proto-
type boards may also have serious design aws. The devel-
opment engineers job is to sort out the manufacturing aws
from the design errors. This complicates the prototype-debug
J ULYSEPTEMBER 1999 37
effort tremendously. The de-
velopment engineer might
chase down a bug for days,
only to nd that it is really just
a bad solder joint. Or the en-
gineer might isolate the same
bug more than once, simply
because the wire installed to
x it came loose. These situa-
tions result in exchanges such
as Its a software problem!
No, its a hardware prob-
lem! Oops, its just a bad boardsorry!
This unfortunate combination of fault detection and de-
sign verication occurs because of deciencies in prototype
manufacturing test. Specifically, building the usual pro-
duction-quality test fixture is prohibitive since only a few
prototype boards will be built, and they are likely to under-
go postproduction changes (cuts and wires) that will also
need verifying.
Obviously, much can be gained from separating fault de-
tection from design verication on prototype boards. The
rst step is to guarantee that the manufactured or reworked
boards are fault free. This requires running a full structural
test after a board is manufactured or reworked. Then, the
engineer can perform design verication knowing that any
problems are likely to be related to design, not to bad
boards. This saves the wasted time of checking that bad be-
havior is not due to a manufacturing aw.
Performing design verication on prototype boards guar-
anteed to be fault free is benecial no matter how we per-
form the structural testing. Whats important is that the
structural testing is done. The traditional test method in-
volving a test fixture generally is not a reasonable invest-
ment at the prototype phase, even if it does simplify
prototype debugging. Boundary-scan testing is an alterna-
tive method that addresses the major objections to building
a test xture for prototypes (Table 1). The reason for the nor-
mal practice of skipping a thorough structural test on pro-
totype boards is not that such a test isnt benecial. Rather,
the only method previously available caused more trouble,
time, and cost than it was worth.
Amortization of a test xtures cost over high production
volumes may make the expense bearable. However, test x-
tures are rarely cost-effective for prototype boards. Even if a
test xture is built, when a wire is added or a trace is cut on
the prototype, the xture may need modication. But if the
prototype board supports boundary scan, engineers can eas-
ily test and retest it. They can regenerate the boundary-scan
tests and rerun them to verify board changes. This allows
engineers to spend time debugging the design, not chasing
after manufacturing aws.
Today, many standard ICs have built-in 1149.1, and cus-
tomers do not have the option of buying the IC without it.
This is often because the IC manufacturer uses the 1149.1
bus to test the device after fabrication and/or packaging.
Many larger devices (such as microprocessors) have pro-
prietary built-in self-test (BIST) functions that the manufac-
turer accesses via the 1149.1 bus. As silicon size and the
number of pins on a package increase, the overhead for
1149.1 support decreases as a percentage of logic and num-
ber of pins. Thus, silicon vendors are becoming more will-
ing to provide 1149.1 support.
Other ICs, such as bus transceivers, are available in both
1149.1 and non-1149.1 versions. Of course, many other de-
vices provide no 1149.1 support at all.
To build 1149.1 into a board, manufacturers connect de-
vices with 1149.1 support to a scan chain accessible from
the board edge. To add test points to otherwise unscannable
areas, manufacturers add special devices to the board de-
sign. These devices dont change the boards behavior in
normal operation, but in test mode, they insert scan regis-
ters into otherwise inaccessible nets. Once a board has built-
in 1149.1 support, we must somehow control the scan chain
at the board level. This control could come from the next-
higher level, with ultimately a single 1149.1 test bus at the
system level controlling all boards. But a PC-based tester at
the board level could handle the control function just as
well, and board-level control is most convenient for proto-
type-board testing.
A PC-based tester enables users to control and observe
scannable signals on the board at the register, bus, or pin lev-
el. Thus, users can work in the conceptual world of 1149.1
instructions and data values. They need not worry about the
number of TCKs or the bit sequence on TMS necessary to
transition the test access port (TAP) state machine into the
Shift-DR state. Further, the PC-based tester enables automat-
ic test-pattern generation and fault isolation to the specic
pin on a fully scannable net. It also analyzes the fault cover-
age of tests.
To provide the high-level functions that insulate the user
from the bit sequence details, the PC-based tester needs cer-
Ta ble 1 . Structural testing of prototypes.
Tra ditiona l testing 1 1 4 9 . 1 testing
Requires expensive xture Requires no test xture
Fixture not easily modied for Tests easily modied for design changes
design changes
Fixture unusable for production Prototype tests often directly portable
test unless design is perfect to production boards
Generally not done Seems like a good idea
BOUNDARY SCAN
38 IEEE DESIGN & TEST OF COMPUTERS
tain input. First, the tester requires BSDL (Boundary-Scan
Description Language) models for each device in the scan
chain. These models dene how the scan chain in each de-
vice is hooked up and what 1149.1 functions the device sup-
ports. Next, to know how all components on the board
(both boundary-scannable and not) interconnect, the tester
needs the board-level netlist. Finally, to understand how
the board-level scan chain is hooked up, the tester requires
an HSDL (Hierarchical Scan Description Language) model
of the scan chain. Once we provide these inputs, the gen-
eral test sequence proceeds as described earlier.
On a board with partial scan, we can separate the nets
into different sets or classes based on the level of scan test-
ing available for the net (Table 2). The ideal net is one in
which every connection is scannable. In these nets, all opens
and shorts can be detected. On the other end are nets in
which no connection is scannable. Obviously, scan testing
provides no benet for these nets. In between are three class-
es of nets with varying levels of fault detection capability,
depending on their types of scan and nonscan connections.
Obviously, the level of fault coverage achieved depends
strongly on the number of nets in each class. Therefore, in
designing a board, we must consider how the nets fall into
these classes. This is why a designer might choose to add a
device such as the QuickScan JTAG Access Port,
11
even
though such a device contributes no functionality in oper-
ational mode.
Of course, in addition to unscannable devices, most
boards include analog components as well as digital com-
ponents that are directly testable by 1149.1 testing. A stan-
dard based on the work of the IEEE P1149.4 Mixed-Signal
Test Bus Project
12
is emerging to address these issues. In fact,
the project has completed balloting and submitted a draft to
the IEEE, which will likely approve the standard by the time
of this publication.
Like 1149.1, the P1149.4 standard lays the foundation of
an extensible framework. First, it reuses the 1149.1 test log-
ic architecture, including the TAP and instruction and data
register structures. It augments this basic infrastructure with
a facility for static interconnect test at analog signal pins and
with an analog test bus to bring continuous and/or dynam-
ic signals on chip for internal or external test.
Again like 1149.1, the primary focus of P1149.4 has been
on interconnect testing. By its very denition, P1149.4 has
had to consider the inclusion of analog signal pins in the in-
terconnect test process, unlike 1149.1, which essentially ig-
nored such pins altogether, as Figure 3a shows. P1149.4 also
took on the task of providing test facilities capable of test-
ing extended interconnect. Many analog signal pins do not
directly connect to the pins of other ICs. The concept of ex-
tended interconnect includes passive components (such as
resistors, capacitors, and inductors), which are typically in-
line between analog pins.
To extend interconnect testing to analog signal pins,
P1149.4 includes a complete pin-boundary collar, a bound-
ary-scan register that provides pin-based test facilities at all
pins, analog as well as digital. P1149.4 extends the EXTEST
instruction to analog signal pins, using digital values in the
boundary-scan register to control each analog pin to one of
three states: VH, a pin-specic, static high-voltage level; VL,
a pin-specic, static low-voltage level; and high impedance.
Additionally, P1149.4 uses the boundary-scan register to cap-
ture a single-bit digital representation of the voltage present
at each analog signal pin. In this manner, the analog pins
participate fully in testing for board shorts and for opens in
simple interconnects (which appear as a wire to the static
test method). Figure 3b shows the complete boundary-scan
register consisting of DBMs and ABMs.
On the other hand, testing extended interconnect requires
the ability to inject an analog stimulus (continuous versus
discrete-valued and/or dynamic versus static). For example,
we cannot test a capacitor in series between two analog pins
by the static EXTEST method. We can test it, however, if we
can inject a dynamic stimulus (such as a sine wave) at one
pin and observe the dynamic response (sine wave) at the
other. Although the metrology for this testing is beyond the
scope of this article, note that it is also possible to test for
the value of the extended interconnect (capacitance, for ex-
Ta ble 2 . Fault coverage classes.
Cla ss Denition
(1) Pure scan nets 100%detection of opens and shorts
(2) Partial scan nets with at least one scan driver and one
scan receiver on a nonscan device lead 100%detection of shorts and partial detection of opens
(3) Nets in which scan pin connects to nonscan pin(s) Partial detection of shorts
(4) Boundary-scan inputs connected to power or ground Partial detection of opens
(5) Nonscan nets with no tester access No detection
(6) TAP nets 100%detection by scan path test
J ULYSEPTEMBER 1999 39
ample).
7
Figure 3c shows how we can measure the value of
an external resistor by injecting a DC current I from one ABM
(via AT1 to AB1). This is followed by two consecutive read-
ings of voltages V1 and V2, using AB2 and AT2.
What P1149.4 defines is an analog test bus, AT1/AT2,
which we can route globally to all chips on a board to con-
nect the chips to an off-board source of analog stimulus and
response-measurement instrument. It also defines an on-
chip switching matrix on each mixed-signal IC that can be
used to connect given pins to the AB1/AB2 bus. Of course,
the source of programming control for the on-chip switching
matrix is none other than the chips boundary-scan register.
DBM
DBM
DBM
TDI
TMS
TCK
TDO
External resistor
Analog
section
DBM
DAC ADC
Analog
outputs
Digital
outputs
Analog
inputs
Digital
inputs
1149.1 test access port
Digital
section
DBM
DBM
TDI
TMS
TCK
TDO
DBM
ABM
AT1
AT2
ATAP
AB1
AB2
Test data in (1149.1)
Test mode select (1149.1)
Test clock (1149.1)
Test data out (1149.1)
Digital boundary module
(boundary-scan cell)
Analog boundary module
Analog test 1 stimulus bus
(P1149.4)
Analog test 2 response bus
(P1149.4)
Analog test access port
(=AT1 +AT2)
Analog bus 1 (core internal)
Analog bus 2 (core internal)
(a)
DBM
DBM
TDI
TMS
TCK
TDO
External resistor
ABM
ABM
Analog
outputs
Digital
outputs
Analog
inputs
Digital
inputs
1149.1 test access port
DBM
DBM
ABM
ABM
(b)
Analog
section
Digital
section
DBM
DBM
TDI
AT1
(ATAP)
AT2
(ATAP)
TMS
TCK
TDO
External resistor
ABM
ABM
Analog
outputs
Digital
outputs
Analog
inputs
Digital
inputs
1149.1 test access port
DBM
DBM
ABM
ABM
(c)
Analog
section
Digital
section
Test bus
interface circuit
AB1 AB2
V1 V2
I
Figure 3 . Handling analog pins: pre-P1149.4 (a ); P1149.4 digital output stimulus/ digital input response (b); P1149.4 analog
output stimulus/ analog input response (c).
BOUNDARY SCAN
40 IEEE DESIGN & TEST OF COMPUTERS
Tra nsla tion to volume production
Once development engineering has (nally!) nished de-
bugging a new board prototype, the responsibility for man-
ufacturing and testing the board for volume production
moves to the manufacturing group. From manufacturings
point of view, the ideal board is one designed for high fault
coverage during test. Providing the necessary test points on
the board for test-xture probing is an important part of this
design. Manufacturing also wants a board that requires the
least expensive test xture. Features such as very ne pitch
parts and double-sided boards can add to the cost of a test
xture. Further, minimizing the complexity of creating and
running the manufacturing tests is very important.
A board with built-in 1149.1 provides full test access to all
scannable nodes. Built-in 1149.1 eliminates the need to probe
these nodes with a test xture, even though some other nodes
may still require probing. Even more compelling is the pos-
sibility that board-level structural tests developed for the pro-
totype can be reused on the production board. Generating
the tests in high-level algorithmic terms, and not as clock-by-
clock serialized vectors, enhances this possibility.
So manufacturing should embrace the use of 1149.1 for
board-level testing, right? Remarkably, resistance to incor-
porating boundary-scan testing often comes from the man-
ufacturing area. There are a number of reasons for this, some
quite valid, and some not so valid. Changing a functioning
process flow is warranted only when it is clear that the change
will result in a lower overall cost per unit. Introducing new
technologies or tools into a manufacturing environment of-
ten meets resistance, especially when the technologies or
tools are not applicable to all products being produced.
A not-so-valid reason for resisting the adoption of 1149.1 as
a test methodology is the knee-jerk response Weve always
done it this way. The traditional test methodologies are of-
ten adequate for boards currently in production. But we must
remember that the design of those boards began two, ve, or
even more years earlier. For design cycles starting today, de-
vice technology has advanced signicantlymost notably
for board test, device-packaging density. For new designs, the
old test methodologies may not be adequate, and new ones
may be necessary whether its convenient or not.
Development engineers do not control how their com-
pany tests production boards, but they do control how they
test their own prototype boards. If building 1149.1 into a pro-
totype board is cost-effective and benecial solely in the de-
velopment lab, it doesnt matter whether we can persuade
anyone else to use the new methodology. However, success
at the prototype level can be the most convincing argument
for changing manufacturing processes.
Introducing a new technology or tool is never without
challenges, and incorporating 1149.1 into the development
process is no different. The first barrier is that building a
board with 1149.1 requires 1149.1-compliant components.
Many major components are available in 1149.1-compliant
versions, but many others are not. This problem can stop
the show before it starts.
Beyond this issue, the subsequent obstacles are not in-
surmountable, even if a little painful. A frequent problem is
either the unavailability or the inaccuracy of BSDL les for
the components. Other obstacles are related to the purchase
and use of new tools. Justifying the purchase of a tool, such
as a PC-based tester, that was not required on a previous pro-
ject may not be easy. Once the tool is in house, users face the
inevitable learning curve, as with any new tool. Finally, in-
tegration issues always seem to come up when engineers
use tools and/or data from multiple vendors. Again, we can
work through these issues, but doing so is time consuming.
Just as 1149.1 is useful for structural test of a board in the
prototype debug phase, it is also a useful tool in the volume
production environment. For volume production, 1149.1 in-
creases test coverage and reduces test development effort,
resulting in significant savings. Prototype and production
testing are fundamentally separate areas of benefit; each
alone justifies the incorporation of 1149.1 into a board.
Together, the benets should be even greater.
Extension to system integra tion
Of course, the product life cycle doesnt end at board
manufacturing test. After structural testing, an electronics
assembly (board) must be tested for suitability to a system
environment (board functional test). Then, unless the board
is the nal product, it must be integrated with other boards
and assemblies to form a complete system.
As those responsible know all too well, system integration
is not a trivial task. However, boundary scan stands ready
to make the task a bit more manageable, if we provide the
appropriate access mechanisms.
The basic proposition is simple: System integration can
benet from the same chip-level and board-level test facili-
ties that boundary scan provides to prototype and produc-
tion testing. To build internal and external test facilities into
our chips, we merely hook up boundary scan on our boards
to provide board-level test capability. Thus, to provide sys-
tem-level test capability, we need merely hook up bound-
ary scan in our systems.
For example, if a fully integrated system does not func-
tion, we would rst like to know whether all the subassem-
blies are in place. Then we want to know whether they are
properly interconnected and, nally, whether they are per-
forming their intended functions. Note the parallels to board
structural test. Boundary-scan test facilities built into our
chips and boards can address each of these test needs if we
provide a system-level test access mechanism.
We are already familiar with the concept of using bound-
J ULYSEPTEMBER 1999 41
ary scan for board-level interconnect test. Extending this
concept to the system level requires that we think in terms
of testing the wires (PWB traces or cables) that connect one
board to another. However, we should also consider that
these wires might be subject to delay faults in addition to
static faults, so at-speed-testing capability is desirable.
For testing board function, we might use a proof-of-
construction method. That is, we would apply chip tests and
then board interconnect tests with the presumption that if
the chips are good and the interconnects are good, the board
should function. Ideally, these chip and interconnect tests
should be performed at rated functional speeds. Another ap-
proach is to encapsulate the board functional test in a board-
level BIST (again, this should include at-speed testing).
To extend board-level test access to the system level, we
may be tempted to adopt the same paradigm we used to ex-
tend chip-level access to the board. That is, at board level,
we extend boundary-scan access from one chip to the next
simply by chaining the devices together from TDO to TDI.
Why not adopt a similar approach for systemsthat is, chain
one board TDO to the next board TDI to create a monolith-
ic system-level scan chain?
The unsurprising answer to this question arises from the
inherent differences in physical partitioning of systems and
boards. In the case of most boards, the conguration of the
component chips is xed at the time of manufacture. On the
other hand, most multiboard systems are designed to be ful-
ly recongurable at the discretion of the user or system in-
tegrator. These systems include several board slots that may
or may not be populated in the user conguration. Thus, a
simple system scan path that chains board slots from TDO
to TDI may be incomplete and unusable.
This system-level access problem is known as the mul-
tidrop problem. Generally, system-level access requires a
multidrop test access mechanism. The necessary funda-
mental characteristic of this mechanism is tolerance of
boards or subsystems that are not present; that is, it must not
rely on a single coherent scan chain. Extending our Internet
analogy, such mechanisms serve as the routers and switch-
es that direct test trafc to the desired target.
In most cases, each system serial data signal, input and
output, is wired in common across all modules to be ac-
cessed. The multidrop mechanism uses some form of ad-
dressing to select the module to be scanned. This
mechanisms advantage is that a missing module does not
interrupt the systems serial data path. However, only one
module can scan out data at a given time (but a given test
includes more than one scan operation and can usually be
modied to accommodate mixed scans of various chains).
Over the years since the adoption of IEEE Std 1149.1, sev-
eral alternative multidrop-access mechanisms have
emerged. They fall into three categories:
I mechanisms that use 1149.1 protocols for data transfer,
with a separate addressing layer
I mechanisms that use 1149.1 protocols for data transfer
and a superset protocol (on the same multidrop 1149.1
wires) for addressing
I mechanisms that use completely separate protocols for
data transfer and addressing, thus requiring a protocol
bridge
Solutions of the rst type are usually ad hoc implemen-
tations by the system designer. Alternatives in this category
include binary-addressable (decoded on board) and one-
hot multiplexing. These methods typically require more than
ve wires for full system-level test access. Since these are ad
hoc implementations, support from test solution providers
may be limited.
The second group includes separate commercial offer-
ings such as Texas Instruments Addressable Scan Port
13
and
Fairchild/National Semiconductors Scan Bridge.
14
Both im-
plementations require that the multiplexer function reside
on each module to be addressed. Both effectively reuse the
TDI wire to serially transmit the selected boards address,
providing system-level test access on ve wires. Once a giv-
en board is addressed, both implementations use 1149.1 pro-
tocols to advance state and transmit serial data. Both also
allow simultaneous (multicast) scanning of a data stream
into multiple modules.
An interesting distinction lies in the actual addressing
method. The TI Addressable Scan Port uses a 10-bit shadow
protocol that is completely transparent to 1149.1. Once a board
is selected, there are no special requirements that the 1149.1
data stream must meet to maintain the board selection. Thus,
a serial board test set developed for a stand-alone board can
be reapplied at the system level without modication. The
Fairchild/National Scan Bridge, on the other hand, uses 1149.1
instruction scans to carry the addressing information.
Therefore, after a board has been addressed, subsequent in-
struction scans must repeat the addressing information.
The third group is effectively a group of one: IEEE Std
1149.5, Module Test and Maintenance (MTM) Bus Protocol.
15
System integra tion ca n benet
from the sa me chip-level a nd
boa rd-level test fa cilities tha t
bounda r y sca n provides to
prototype a nd production testing.
BOUNDARY SCAN
42 IEEE DESIGN & TEST OF COMPUTERS
This approach, shown in Figure 4, uses a different protocol
and a different ve-wire set for addressing and data transfer.
The MTM bus protocol has advanced features such as inter-
rupts and error checking. However, although the document
species standard mechanisms for initiating 1149.1 testing on
target modules and for streaming data for this testing, the dif-
ferent protocol requires a bridging function. Therefore, this
approach requires some intelligence on the target modules,
which otherwise would not be necessary.
The 1149.5 MTM bus also suffers from a lack of commer-
cial IC offerings suitable for embedded implementations of
either bus master or bus slave. In contrast, the 1149.1-based
solutions reuse preexisting IC building blocks for the bus
master. The commercially available ICs discussed previously
(ASP, Scan Bridge) implement the bus slave. Overall, an im-
plementation based on 1149.5 will be considerably more
costly in terms of silicon and software.
Extension to eld ser vice
The life cycle of any product worth manufacturing doesnt
end at nal system integration. We certainly hope that our
product will attract a paying customer and go into service.
Will the benets of boundary scan then continue? Many who
have implemented boundary scan at the system level have
found that it does indeed continue to reap benets.
16
Since a fair portion of system failures are attributable to
faulty interconnects, it is easy to see the usefulness of bound-
ary scan. Also, technicians correct many system failures by
replacing a board, with the unsatisfying result that retesting
the returned board nds no fault. In other words, the system
failure cannot be replicated outside the environment in
which it occurred.
With a system-level test infrastructure in place, we can
reuse this infrastructure in the eld for better testing and di-
agnostics. This results in better system availability for the
customer and lower maintenance cost for the service
provider and/or system manufacturer. Reuse in the eld en-
vironment generally takes one of the following forms:
I a dumb test infrastructure. The diagnostic test port on
the system simply wires up the system-level test bus.
Thus, a qualified service technician with appropriate
equipment (such as a PC-based tester) can initiate the
boundary-scan diagnostic tests on site.
I an intelligent test infrastructure. That is, some form of
built-in mastering of the system-level test bus is provid-
ed. The diagnostic tests may be built in, remotely ac-
cessible, or both.
Of course, many systems require upgrading during their
time of service. Although we often upgrade systems via soft-
ware, the increasing use of reconfigurable logic devices
makes increased hardware customization possible. Since
in-system programming for most reconfigurable logic is
1149.1-accessible, the same system-level infrastructure that
supports on-site or remote diagnostics can also support on-
site or remote logic upgrades.
MANUFACTURERS ARE INCORPORATING boundary scan
into a steadily increasing number of products, in some cas-
es by choice and in others out of necessity. The need to per-
form manufacturing test on hard-to-probe boards built with
impossible-to-probe chips drives the inclusion of boundary
scan. Once we include boundary scan at one level of a de-
sign for one phase of the
product life cycle, there is
little or no barrier to porting
the same tests to another de-
sign level or life-cycle phase.
The avoidance of redun-
dant test development is
compelling from an effi-
ciency viewpoint. It is even
more impressive when we
consider how many bugs
we avoid by porting known-
good tests instead of creat-
ing new tests from scratch.
The result is a network of
tests implemented across
the chip, board, and system
levels, from prototype de-
velopment to eld service
the Internet of Test.
Test control
master
Slave 1 Slave 2 Slave n
External
clock
MMD (command +data)
MCTL
MSD (data +interrupt)
MPR
MCLK
Test
controller
Test
controller
Test
controller
MMD
MCTL
MSD
MPR
MCLK
MTM master data
MTM control
MTM slave data
MTM pause request
(optional for slaves)
MTM clock
Figure 4 . The 1149.5 multidrop architecture.
J ULYSEPTEMBER 1999 43
References
1. ANSI/IEEE Std 1149.1-1990 Standard Test Access Port and
Boundary-Scan Architecture (includes IEEE Std 1149.1a-1993
and IEEE Std 1149.1b-1994), IEEE Standards, Piscataway, N.J.
2. D. Bonnett, Design for In-System Programming, Proc. IEEE
Intl Test Conf., IEEE Computer Society Press, Los Alamitos,
Calif., 1999, paper 10.3.
3. C. Champlin, Iridium Satellite: A Large System Application of
Design for Testability, Proc. IEEE Intl Test Conf., IEEE CS Press,
1993, pp. 392-398.
4. M. Boutin and P. Dziel, Application of Boundary Scan in a
Fault-Tolerant Computer System, Proc. IEEE Intl Test Conf.,
IEEE CS Press, 1996, pp. 809-817.
5. Y. Zorian and E.-J. Marinissen, Testing Embedded-Core Based
System Chips, Proc. IEEE Intl Test Conf., IEEE CS Press, 1998,
pp. 130-143; http://grouper.ieee.org/groups/1500.
6. F. de Jong and F. van der Heyden, Testing the Integrity of the
Boundary-Scan Test Infrastructure, Proc. IEEE Intl Test Conf.,
IEEE CS Press, 1991, pp. 106-112.
7. K. Parker, The Boundary Scan Handbook: Analog and Digital,
2nd ed., Kluwer Academic Press, Norwell, Mass., 1998.
8. A. Flint, A Simulation-Based JTAG ATPG Optimized for MCMs,
Proc. IEEE Intl Test Conf., IEEE CS Press, 1997, pp. 101-105.
9. M. Wondolowski, Introducing IEEE Std 1149.1 Boundary Scan
into the Board-Level Development Process, Proc. DesignCon99,
Intl Engineering Consortium, Chicago, 1999, pp. 219-230.
10. A. Ley, A Look at Boundary Scan from a Designers Perspective,
Proc. Electronic Design Automation and Test Conf., Asia, Asian
Sources Media Group, Taipei, 1994.
11. Quality Semiconductor, QuickScan 8-bit Universal JTAG Ac-
cess Port (QS3J245) Data Sheet, MDSL-00091-03, http://www.
qualitysemi.com/products/quickswitch/sf_jtag.html.
12. IEEE P1149.4, Draft Standard for a Mixed-Signal Test Bus, IEEE
Standards, Piscataway, N.J.
13. Texas Instruments, 10-Bit Addressable Scan Port (ABT8996)
Data Sheet, SCBS489, http://www.ti.com/sc/jtag.
14. Fairchild Semiconductor, SCAN Bridge Hierarchical and Mul-
tidrop Addressable JTAG Port (SCANPSC110) Data Sheet,
DS011570, http://www.fairchildsemi.com/catalog/digital_
boundary.html.
15. IEEE Std 1149.5-1995, Standard for Module Test and Maintenance
Bus (MTM-Bus) Protocol, IEEE Standards, Piscataway, N.J.
16. R. Gage 1149.1 Scan Control Transport Levels, Proc. IEEE Intl
Test Conf., IEEE CS Press, 1994, p. 1022.
Mike Wondolowski is a senior hardware en-
gineer at Network Equipment Technologies,
with responsibility for board-level and
FPGA/CPLD design and debug for communi-
cation systems. His previous experience in-
cludes ASIC design with responsibility for
built-in self-test and boundary scan at both the
ASIC and multichip module levels. He received a BS from the Uni-
versity of California, Berkeley, and an MS from the University of
California, Santa Barbara. He is a member of the IEEE, the Com-
puter Society, and the ACM.
Ben Bennettss biography and photo appear on page 22.
Adam Ley is the director of corporate appli-
cations for Asset InterTech, Inc., a supplier of
boundary-scan solutions. He has been in-
volved with boundary scan since 1991. Previ-
ously, he worked at Texas Instruments, where
he was the technical leader in logic products
to drive boundary-scan bus interface and scan
support products. Ley is a member of the IEEE 1149.1 Working
Group and serves as the technical editor for the group. He holds a
BSEE from Oklahoma State University.
Send questions and comments to Ben Bennetts, Bennetts Asso-
ciates, Burridge Farm, Burridge, Southampton, SO31 1BY, UK;
ben@dft.co.uk.