Medalist i3070 In-circuit Test System

Boundary-Scan Testing

4
Testing Boundary-Scan Device Chains
Overview 4-2
Introduction to Testing Device Chains 4-3
InterconnectPlus 4-13
Generating Tests for Boundary-Scan Chains 4-41
Results Analysis Routine 4-89
Debugging Boundary-Scan Tests 4-97
InterconnectPlus Test Language (ITL) 4-104
VCL/ITL Pass-Thru Statements 4-117
VCL Source Code For Chain Tests 4-119
Sample Boundary-Scan Device Chain 4-123

4-1
4 Testing Boundary-Scan Device Chains

Overview
The next step toward full utilization of boundary- scan technology involves
testing circuit boards that employ chains of boundary- scan devices. The
ability to test boundary- scan devices connected to one another can
significantly shorten test development time, and could result in a reduced
need for nodal access.
This chapter explains how an advanced feature of Agilent Boundary- Scan
software, Agilent InterconnectPlus, accomplishes this task. The software
develops and executes powered shorts, interconnect, buswire, and connect
tests, which are accompanied by a comprehensive results analysis routine
that diagnoses failures. This routine also features detailed messages that
help you to identify failures quickly and precisely. In addition, a disable
routine is available to disable the outputs of all the devices in a
boundary- scan chain. All of this is created automatically when you specify
your boundary- scan devices during the normal test development process.
Before you read this chapter, you should understand the basic concepts of
IEEE Standard 1149.1, Boundary- Scan Description Language (BSDL),
Vector Control Language (VCL) and the general board test generation
process.
InterconnectPlus is an optional, advanced boundary-scan product for
NOTE
the Agilent In-circuit Test System. For this product to work, you must
include the enable advanced boundary scan statement in your
board configuration file to turn on advanced boundary-scan. See
Syntax Reference for more information about the enable statement.

Several sections in this chapter refer to the sample device 74bct8374 Octal
(Figure 2- 9 on page 2- 68) when examples are needed. This is the same
device used in earlier sections of this documentation.

4-2 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Introduction to Testing Device Chains

A boundary- scan chain consists of two or more boundary- scan devices
with TDI and TDO pins connected in series and common TMD and TCK
signals, as shown in Figure 4- 1.
Devices in the chain have common TCK and TMS lines (TRST is optional
for each device in the chain).

Figure 4-1 A simple boundary-scan chain

u1 u2 u6

TAP TDO TDI TAP TDO

TDI
TMS
TCK

u7
u3 u4

TAP TDO TDI TAP

TDO
TDI

u5

Bit patterns can be shifted in through the initial TDI connection (u1 in
this case), shifted through every device in the chain, and shifted out the
final TDO connection (u4 in this case) for analysis. Theoretically, all
testing of interconnected nodes for the boundary- scan devices in the chain
can be accomplished using only four test probes: one on the initial TDI
node, one on the final TDO node, and one on each of the controls lines
TCK and TMS. Testing non- boundary- scan devices connected between
boundary- scan devices can also be accomplished using these four probes.
This chapter explores the practical application of testing boundary- scan
chains, and describes the process for developing an optimum test strategy
for your board. The practical application of boundary- scan technology
neither requires nor implies that all possible probes be eliminated.
Employing boundary- scan technology provides you with the option to
remove probes in many cases, however, we still recommend that testhead

Boundary-Scan Testing 4-3

4 Testing Boundary-Scan Device Chains

access be provided whenever possible to ensure maximum fault coverage

and diagnostic resolution. For guidance on evaluating when to remove
probes, refer to Removing Physical Probes on page 4- 82.
While fault detection and diagnosis using only the access to the
boundary- scan chain is possible, there are several disadvantages to this
type of testing. Among the disadvantages are:
• All tests must be executed and diagnosed with power applied, which
leaves devices vulnerable to damage if shorts exist on the board.
• The diagnosis of some faults might be ambiguous.
• Under certain circumstances, it might not be possible to isolate a
failure to a specific device pin.

Figure 4-2 Example of a chain of boundary-scan devices

u1 u2 u3

TDI TDO

TCK
TMS

TRST

Every device in the chain is always in the same TAP state: chips operate
in parallel in boundary- scan mode. For example, if u1 is in SHIFT- IR, so
are u2 and u3. One shift cycle causes all devices to shift one bit.
The registers for each device in the chain do not have to be the same
length (IR or DR). The BSDL files tell the system the length of the
registers in each device. These are added together to form, essentially, two
long IR and DR registers. The instructions (bits) for the registers are also
added together to control each register. For example, Table 4- 1 shows
what the register lengths for the devices in Figure 4- 2 could be.

4-4 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Table 4-1 Example register lengths

Device Instruction Register Length Boundary Register Length

u1 6 bits 24 cells
u2 6 bits 24 cells
u3 10 bits 30 cells
Register length for 22 bits 78 cells
entire chain

Table 4- 2 shows what the concatenated EXTEST instructions for this chain
might be. When bit patterns are written, the rightmost bit is closest to
TDO, that is, the first shifted in on TDI or out on TDO.

Table 4-2 Example EXTEST instructions

Device Extest Instruction Bypass Instruction

u1 000000 111111
u2 000000 111111
u3 0000000000 1111111111
Concatenated Instructions 0000000000000000000000 1111111111111111111111

Although the TAP states must be the same, the instructions need not be.
For example, using the instructions in Table 4- 2, you can see in
Figure 4- 3 that if you shift in the pattern 0000011111111111111111, upon
transition through UPDATE- IR, u1 will be in EXTEST, while u2, and u3
are in BYPASS.
Note that, in this case, the length of the Data Register becomes 26 cells
(u1 Boundary Register has 24 cells, plus the u2 and u3 Bypass Registers,
which have one cell each). Shifting in a new set of instructions can change
the active registers and therefore the length of the chain's Data Register.
From this you can see that the length of the Instruction Register for the
chain is fixed: it is the sum of the length of all the Instruction Registers in
the chain. However, the length of the chain's active Data Register is
dependent upon the current instructions for each device in the chain: it is
the sum of the length of the active Data Registers in the chain. This, in
turn, affects the length of the data bits that must be shifted for a given set
of tests.
InterconnectPlus software keeps track of these changes as you develop
your chain test. The information in the BSDL file tells the software the
length of the registers targeted for each instruction.

Boundary-Scan Testing 4-5

4 Testing Boundary-Scan Device Chains

Figure 4-3 Devices loaded with different instructions

EXTEST BYPASS BYPASS

u1
u2 u3

TDI TDO

TCK

TMS

TRST

Keeping TAP-only Devices in the Chain

A TAP- only device is specification for a boundary- scan device that, in
some way, does not fully comply with IEEE Standard 1449.1, or a device
that, for some reason, does not operate properly with the rest of the
boundary- scan chain; however, the device's TAP and its BYPASS function
operate properly. InterconnectPlus software allows you to label such a
device as TAP- only so that its Bypass Register can be used as part of the
chain.
The primary benefit of keeping a TAP- only device in the boundary- scan
chain is that it allows you to test a longer chain of devices, rather than
two or more smaller chains. For example, if device u3 in Figure 4- 4 were
a TAP- only device, you could keep this device in the chain to permit
testing of the other five devices in the chain.
The alternative is to break these apart into two chains by specifying the
device as non- compliant. In this case, you could do only the interconnect
tests associated with the smaller, individual chains. You could not test the
circuitry that connects one smaller chain to the other without using
physical probes. This results in a real loss in testing.
For more information about specifying a device as TAP- only or
non- compliant, refer to Describing the Boundary- Scan Device on
page 4- 44.

4-6 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Figure 4-4 Keeping TAP-only devices in the chain prevents having to break chains

u3 u4
TAP
Only

u2 u5

u1 u6

TD1 TDO

Using TAP Override

Sometimes a TAP signal (TDI, TDO, TCK, TMS, or TRST) will contain a
device that causes the signal to be split into multiple node names. The
device may be a buffer, a logic level converter, or a resistor with a value
above the IPG Digital Resistance Threshold. The InterconnectPlus software,
by default, treats boundary- scan devices on opposite sides of such a split
signal as separate chains.
For example, Figure 4- 5 shows a circuit where the TMS and TCK lines
have buffers. InterconnectPlus software, by default, would see two distinct
chains: a chain consisting of u1 and u2, and a chain consisting of u3, u4,
and u5.

Figure 4-5 A single boundary-scan chain split into two chains

The development software allows you to specify that certain nodes which
are logically equivalent to physical TAP signal connections should be used
in place of the physical TAP signal nodes. This enables you to override

Boundary-Scan Testing 4-7

4 Testing Boundary-Scan Device Chains

nodes so that InterconnectPlus software will see devices with logically

equivalent TAP signal nodes as a single chain. To accommodate the chain
shown in Figure 4- 4, you would enter data for devices u3, u4, and u5.
Each device has the same overrides for TCK and TMS. TCK is overridden
to node TCK1, and TMS is overridden to node TMS1.
Specify TAP overrides as follows:
• UnMux systems: From the Developer Interface, select Data Input > Board
Data > Boundary Scan.
• Mux systems: In Board Consultant, invoke the TAP Override Form from
the Device Entry Form.
The software allows you to override any TAP signal node for any device
being tested with InterconnectPlus. However, generally you should not
change the TDI node for any device but the first one in a chain, or change
TDO for any device but the last one in a chain. You may override TDI or
TDO in the middle of a chain only if the chain would otherwise be seen as
separate chains. For example, a TDI or TDO override is allowed between
U2 and U3 in Figure 4- 6, but not necessary between U1 and U2, or U3
and U4. In this case, only do one or the other: either override U3 TDI or
U2 TDO.

Figure 4-6 TDI or TDO override allowed between U2 and U3

TAP overrides are not necessary on TDO/TDI nodes connected by a series

resistor with a value below the IPG digital resistance threshold. However,
TAP overrides on the chain’s TDI and TDO may be necessary (if series
resistors of any value are present and test access should be through
them).
The TAP override cannot be used to work around pad bits in
boundary- scan linkers. Using Chain Override explains how to handle such
situations.

4-8 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Using Chain Override

When possible, it is preferable to use TAP overrides rather than chain

NOTE
override.

The following examples can and should all be addressed via TAP override.
The examples are merely used to explain the concepts of chain overrides
and do not show the typical cases in which it is the better choice (e.g.
when TAP overrides are not available with PDLs).
Multiple TMS and TCK connections (Figure 4- 7), makes the software treat
the board as if it had two chains. If you intend a configuration to look like
a single chain, you must make it look like one chain for the software. If
you have multiple connections, you can connect the TCK and TMS lines
together inside the fixture, providing a physical connection. The software
allows you to override the board compiler’s view of the chain construction.

Figure 4-7 Multiple TMS/TCK lines cause multiple chains

u1 u2 u3

TDI TDO

TCK TCK1
TMS1
TRST
TCK2
TMS TMS2

When you run the development software, you might discover that there are
more tests generated than you have chains existing on the board. On the
Mux systems, you can examine a testability report from Board Consultant
after data entry to see the chain structures found by the board compiler.
If you discover more chains than there actually are, you can edit the chain
description portion of the board file by setting the Boundary Scan Chain
Override on.
Figure 4- 8 is an example showing how the software could assume there
were two chains. TCK output from buffer A goes to two devices (U1 and
U2) in the chain. Since these outputs are on two different nodes on device
TCK/TMS pins, the software assumes two chains. By overriding, you tell
the software that there is only one chain.

Boundary-Scan Testing 4-9

4 Testing Boundary-Scan Device Chains

Figure 4-8 Logical chain that will be treated as two chains. (A candidate for chain
override.)

TDO_TDI
TDI TDO
U1 U2

TCK1
TCK A TCK2

TMS1
TMS B TMS2

Consider Example 4- 1 where the testability report shows two chains on

the board.

Example 4-1 Report shows two chains on the board

BOUNDARY SCAN CHAINS
U1_U1
TDI TDI
TDO TDO_TDI
TCK TCK1
TMS TMS1
DEVICES
u1;
u2_u2
TDI TDO_TDI
TDO TDO
TCK TCK2
TMS TMS2
DEVICES
u2;

In reality, signals TCK1 and TCK2 as well as TMS1 and TMS2 are logically
identical buffered signals coming from TCK and TMS. The compiler cannot
know this so it splits the logical chain into two chains. To put the two
chains together with an override, do the followng:
• UnMux systems: Manually define the chain(s) using the Boundary Scan
task in the Developer Interface (select Data Input > Board Data > Boundary
Scan).
• Mux systems: First edit the global section of the board file to add the
following statement to the global flag section:
Boundary Scan Chain Override ON

4-10 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

After saving and compiling, you can use list object on board.o to
generate a board file containing the chain(s) that the compiler found.
You must then edit the chain descriptions in the board file (found at
the end of the file), and describe the actual chain construction.
The edited chain looks like Example 4- 2.

Example 4-2 Edited chain

BOUNDARY SCAN CHAINS ! Board key phrase
u1_u2 ! <name of chain> followed by TAP signals
TDI TDI ! TDI <node name>
TDO TDO ! TDO <node name>
TCK TCK ! TCK <node name>
TMS TMS ! TMS <node name>
DEVICES ! now name devices in the chain
u1, u2; ! first device nearest TDI
! last device nearest TDO, ";" terminated

Turning Two Interconnected Chains into One Chain

When the devices in two different chains are interconnected as shown in
Figure 4- 9 and testing these interconnections becomes a problem, you can
connect the two chains to form one larger chain. Use a jumper wire within
the fixture, or assign general purpose (GP) relays to connect the TDO node
of the first chain to the TDI node of the second. You must also ensure that
the TMS and TCK lines are common to all devices in the chain; you can
jumper these lines if they are not currently connected.

Figure 4-9 Connecting jumpers or GP relays to make a larger chain

Chain 1 Chain 2

u1 u2 u5 u6
TDI
TDI

u3 u4 u7 u8

TDO TDO

You should not jumper around non- compliant devices (example shown in
Figure 4- 10) solely for the purpose of making a larger chain. This can
result in overdriving difficulties, or other testing problems.

Boundary-Scan Testing 4-11

4 Testing Boundary-Scan Device Chains

Figure 4-10 Connecting a jumper to make a longer chain around non-compliant devices is
not recommended

u10 u11 N.C. u20 u21

u13

TDI TDO

In Figure 4- 10 the dotted line represents a jumper used to circumvent the

non- compliant (NC) device, u13. This might seem like a reasonable
solution, however, a closer study will reveal that using a jumper does not
disconnect the device's TAP from the circuit and the connected TDOs
would fight. The activity of this device during test will be unpredictable.
In this case, determine if the non- compliant device satisfies the
requirements to be specified as TAP- only (see the description in Keeping
TAP- only Devices in the Chain on page 4- 6).
If this is not possible, then leave the chains separate, even if some
interconnect test capability is lost. You can regain the loss by assigning
physical probes to those nodes.
The best solution would be to do an ECO, or modify the design prior to
release.

4-12 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

InterconnectPlus
• Chain Testing with InterconnectPlus
• InterconnectPlus Test Files
• Powered Shorts Test
• TAP Integrity Check
• Interconnect Test
• Buswire Test
• Connect Test
• Custom Boundary- Scan Tests

Chain Testing with InterconnectPlus

Chain testing with InterconnectPlus software comprises powered shorts,
interconnect, buswire, connect and chain disable tests, and the ability to
do Silicon Nails testing. Through the use of the IEEE 1149.1 required
instruction set, many manufacturing faults can be detected and diagnosed.
This is accomplished by employing the EXTEST function for the detection
of faults in the interconnections of both bussed and non- bussed devices,
whether or not probe access is provided to the nodes being tested.
Table 4- 3 provides you with an understanding of where these tests fit in
your overall process. The table also identifies which tests are automatically
created by the boundary- scan software and which require test developer
interaction.

Table 4-3 Board test sequence showing position of boundary-scan tests

Sequence Type Method

Board Test Sequence -- Unpowered
Shorts Tests Conventional Automatic
Analog In-circuit Tests Conventional Automatic
Power Applied to Board
Powered Shorts Test Boundary-Scan Automatic
Interconnect Test Boundary-Scan Automatic
Buswire and Connect Tests Boundary-Scan Automatic
Digital In-circuit Test Conventional Automatic
Silicon Nails Test Boundary-Scan Interactive or Automatic1
Power Removed from Board, then Re-applied
BIST, INTEST, User Functions Boundary-Scan Interactive
1. Automatic creation requires a separate product, Automated Silicon Nails.

Boundary-Scan Testing 4-13

4 Testing Boundary-Scan Device Chains

Executing shorts and analog in- circuit tests should identify the majority of
shorts that occur across physically accessed nodes, which minimizes
potential damage to your board.
Shorts and analog in- circuit tests are described in detail in Analog Testing.
Digital in- circuit tests are described in Digital Testing. BIST and INTEST
are described in Introduction to Boundary- Scan. Silicon Nail test theory is
discussed in Automated Silicon Nails.
The primary purpose of this section is to examine the following tests:
• Powered Shorts Test - Tests for solder shorts on the connections
between boundary- scan nodes that do not have physical access and
conventional nodes of any other type that do have physical access, and
are physically close to each other.

The exceptions are power and ground nodes, disable nodes, and TAP
NOTE
nodes. Shorts to power or ground are detected by an interconnect
test. Most shorts to TAP nodes are detected by an integrity test.

Powered shorts test fixes the direction that bidirectional cells are
tested: those cells selected as drivers by the software are tested only as
drivers; those not selected are tested only as receivers.
One powered shorts test is generated for each boundary- scan chain on
the board. If this test fails, testing stops, and power is removed from
the board.
For more information, see Powered Shorts Test on page 4- 18.
• TAP Integrity Check - Verifies that the Test Access Port (TAP) of all
the boundary- scan devices in the chain operate properly. If this check
fails, testing stops, and power is removed from the board. This check is
a preamble to all other boundary- scan tests; it is an integral part of
each test and is executed before each test runs.
For more information, see TAP Integrity Check on page 4- 20.
• Interconnect Test - Tests the connections from one boundary- scan
device to the other boundary- scan devices in the chain. This test checks
primarily for shorts, but most opens will also be detected. If this test
fails, testing stops, and power is removed from the board. Interconnect
test attempts to use only one driver in the case of bussed nodes. This
helps keep tests shorter, helps diagnostics, prevents bus fights, and
minimizes the potential for device damage.
Interconnect test fixes the direction that bidirectional cells are tested:
those cells selected by the software as drivers are tested only as
drivers; those not selected are tested only as receivers.
Interconnect tests require the use of only four testhead resources; three
drivers (TMS, TCK, TDI) and one receiver (TDO).

4-14 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

If device disabling or conditioning is necessary for other devices on

NOTE
the board, additional drivers might be required.

One interconnect test is generated for each boundary- scan chain on the
board. This test verifies the connections among devices in the same
chain only.
For more information, see Interconnect Test on page 4- 22.
• Buswire Test - Created when bussed drivers are present in the chain.
On bussed nodes, interconnect test typically only enables one driver.
Under certain circumstances, interconnect test must be executed with
multiple device outputs driving identical test patterns onto the same
(bussed) node. If one of the output pins was disconnected from the
node (open), it would go undetected. For this reason, buswire test turns
drivers on one at a time to check for opens, and tests the operation of
all drivers. One buswire test is generated for each chain on the board.
Buswire test verifies the operation of bidirectional pins by generating
separate vectors to check their operation as drivers, then as receivers.
For more information, see Buswire Test on page 4- 33.
• Connect Test - Tests for opens on one device in the chain. This test
checks for opens on only the inputs and outputs of devices that have
physical probes assigned. One connect test is generated for each
boundary- scan device in the chain that has been specified to be
connect tested and that has one or more I/O pins accessible from the
testhead.
For larger devices that exceed the available number of testhead
resources (for example, testing a 300- pin ASIC when only 200 resources
are available), or to minimize ground bounce caused by too many
simultaneous transitions, you can automatically split the connect test
into two or more smaller tests by using the Connect Max feature.
Connect test verifies the operation of bidirectional pins by generating
separate vectors to check their operation as drivers, then as receivers.
For more information, see Connect Test on page 4- 37.
• Disable Test - Disables the outputs of all the devices in the chain to
the extent possible. If the Boundary Scan Disabling option is selected,
this test will be generated.

Boundary-Scan Testing 4-15

4 Testing Boundary-Scan Device Chains

InterconnectPlus Test Files

Each of these tests has the following files, of which you should be aware.
• InterconnectPlus Test Language (ITL) source file - An editable file
generated by the development software. It is a high- level specification
of the test to be generated.
• Vector Control Language (VCL) source file - An editable file created
from the ITL file by the MSPD serializer (the MSPD serializer is invoked
via the standard compile statement). It contains the full test with every
bit specified; it is an input to the VCL compiler.
Editing is not recommended because the edits are easily lost when the
ITL is recompiled.
• Test dictionary (.x) file - A file generated by the MSPD serializer that
contains the node identifier and the expected signature for that node. A
commented version of this file is documented at the end of the VCL
source file. Only to be edited in rare circumstances by experts.
• Test requirements (.r) file - A temporary file generated by the VCL
compiler to identify testhead resources needed for the test.
• Test object (.o) file - The compiled VCL file (non- editable).
• Test coverage (.xml) file - A file containing feed data for Coverage
Analyst. This is saved in ca_data/bscan under the board directory.
These files are located in the board's digital directory, except where
otherwise indicated. The files are discussed in more detail throughout this
chapter.

Importance of Providing Complete board_xy Files

It is strongly recommended that you acquire complete topology information
(X- Y location information) for your board so that the board_xy file used
to generate your test is complete. Topology provides the system with
valuable adjacency information used to build powered shorts tests, and all
pin data (preferably all solderable points) as well as node data should be
provided.
If complete board_xy files are not provided, the software will make
calculated assumptions about nodal adjacency, which could result in
inadequate or incomplete test coverage. When this information is provided,
you can rely on the software to provide complete coverage, and you can
focus on qualifying candidates for probe removal.
Figure 4- 11 is a physical representation of one section of a densely packed
circuit board. This board has a number of integrated circuits with gullwing
leads that are mounted closely together. Also mounted closely to these
devices are several SMT analog devices. Complete X- Y data would tell the

4-16 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

system software about the physical relationship of all these components,

and would allow InterconnectPlus to add the necessary powered shorts
test to cover all contigencies.

Figure 4-11 Circuit Board with Tight-Pack Design

Shorts that can occur between physically adjacent

devices are automatically accounted for
if complete XY data is provided

Boundary-Scan Testing 4-17

4 Testing Boundary-Scan Device Chains

Powered Shorts Test

This section is provided for reference only. The powered shorts test is
created automatically, and in most cases will work without debug. If this
test fails, debug all other tests first. Most problems will cause the other
tests to fail, and those tests will be easier to debug.
Figure 4- 12 illustrates connections between two devices for which a
powered shorts test would be generated.

Figure 4-12 Powered shorts test checks for shorts between unnailed boundary-scan nodes and any nearby
nailed node
VCC
IN_17 VCC
IN_18

1 1
24 u3 24
U3_3 u4
3 22

2 U3_2 23

*Potential Short
*Potential Short
*Potential Short

9 8
10
12 u5
11
13

*Potential Short * Nodes are physically adjacent on actual board.

The pin numbers in Figure 4- 12 illustrate the importance of providing a

complete board_xy file. The test software takes the data provided in your
board_xy file to determine the relative adjacencies for each device. The
adjacencies identify where shorts can occur with respect to boundary- scan
nodes.
Devices u3 and u4 are boundary- scan devices with two nodes, u3_3 and
u3_2, connected to a non- scan device, u5. Two input nodes, IN_17 and
IN_18, are also connected to u3 and u4. These pins (u3 pin 1 and u4 pin
24) are physically adjacent to u3 pin 2 and u4 pin 23. The test software
identifies these nodes as potential shorts for this circuit. Because the basic

4-18 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

parameters for powered shorts test are an un- nailed boundary- scan node
and a nailed node of any other type, InterconnectPlus software would
create a powered shorts test for this circuit.
Note that two adjacent pins on device u5, pins 10 and 11, would not be
added to the powered shorts test because pin 10 is a disable node that
must be held to a constant state during boundary- scan testing. Shorts on
this node would be found either during unpowered shorts testing, or
during the first phase of interconnect testing.
After you enter your board data, the development software analyzes it and
looks for un- nailed boundary- scan nodes. It then examines the X- Y data
for powered shorts situations to adjacent nailed nodes. The software then
writes the ITL for the powered shorts test.
When this test is executed, several subtests are run. Each subtest is a
cycle through a selected set of nailed nodes connected to multiplexed
hybrid drivers. Multiplexing is used to reduce the number of resources
needed for the complete test. A detailed diagnostics routine is executed
upon failure and results are reported to the print device.

Boundary-Scan Testing 4-19

4 Testing Boundary-Scan Device Chains

TAP Integrity Check

The TAP integrity check is a preamble to all other boundary- scan tests; it
is an integral part of each test and is executed before each test runs. It is
created automatically, and in most cases will work without debug. This
section is provided for reference only.
Figure 4- 13 illustrates the boundary- scan TAP integrity check. It verifies
that the chain is operable, and that the scan path is intact. This is done
by verifying the two least significant bits of the Instruction Register, which
are captured during the IR- CAPTURE state.
Whenever possible, this integrity check also verifies that the correct
devices have been loaded onto the board by checking their IDCODES, if
provided. If IDCODES are not provided, the data captured by the
Instruction Register during the CAPTURE- IR state is verified, which
provides some capability for device identification.

Figure 4-13 Boundary-scan TAP integrity check

u1 u2

TDI

u3 u4

TDO

The TAP integrity check looks for the basic integrity of the devices' TAP
controllers and the boundary- scan chain. Examples of problems that could
be encountered include:
• one of the devices is bad and simply does not work
• a wrong device was loaded
• one of the TDI or TDO connections is bad (for example, an open
between u3 and u4)
• TCK is disconnected from one or more devices

4-20 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Integrity checks are an integral part of every chain test. An integrity

check occurs at the beginning of each powered shorts test, at the
beginning of each interconnect test, at the beginning of each buswire test,
and at the beginning of each connect test.
When testing begins, the devices load a pre- determined pattern (BYPASS
or IDCODE as specified in the BSDL file) into the Instruction Registers.
The devices then all go through SHIFT- IR and new instruction bits are
shifted in through TDI. These bits are typically for the IDCODE
instruction, if a device includes this feature, or BYPASS.
When the devices go through CAPTURE- IR, the preloaded pattern is
captured. When new bits are shifted in, the preloaded bits are shifted out.
The software can examine this pattern for each device to see if the chain
is working. This first pass through the IR column of the TAP State
Diagram verifies the operation of the Instruction Register and the
TDI- to- TDO links. An operational chain, in this case, implies operational
TAPs for each device.
The devices then change over to their new instructions, and new data bits
are shifted in through TDI. When the devices pass through CAPTURE- DR,
the new bits are captured, then shifted out for examination. These bits
verify the IDCODES of the devices that feature them, or they tell the
software that the device successfully executed the BYPASS function. An
operational chain, in this case, implies proper devices loaded, and devices
that are basically functional.
Any failure during TAP integrity check causes the test to stop and the
board to power down (per the default in the testplan), and a general
failure message is generated. The message provides a diagnosis to the
general area (for example, to a device), but it does not say exactly where
the failure occurred. A failure could occur in a device upstream from the
device that the message cites as the starting point for looking for the
cause of the failure. The diagnosis is limited in its ability to pinpoint the
cause of the failure.
The type of failures detected during this test would prevent the chain
itself from working properly: if the chain is bad, you cannot do meaningful
testing. So the chain must be repaired before further testing can be done.

Boundary-Scan Testing 4-21

4 Testing Boundary-Scan Device Chains

Interconnect Test
This test is created automatically, and in most cases will work without
debug. This section is provided for reference only.
An Interconnect test allows you to test the circuitry that connects one
boundary- scan device to another. The Interconnect test primarily looks for
shorts, then most opens. (A buswire test might be necessary to detect
opens missed by the interconnect test.) Only the connections between
devices in the same boundary- scan chain can be verified.
Testhead access is required only for the TDI, TDO, TMS, and TCK nodes.
All other nodes located between the boundary- scan devices in the chain
can be silicon nodes. Figure 4- 14 illustrates an interconnect test.
Because damaging devices during powered testing is an important issue,
InterconnectPlus software takes the following approach to interconnect
tests.
• Looks for shorts and most opens.
• Concentrates on finding shorts as fast as possible.
• Nodes completely tested via connect tests are commented from the
interconnect ITL to minmize ground bounce.

A silicon node is a node on which no physical test probe is used. An

NOTE
adjacent Boundary Register cell acts as the test probe. Silicon Nails is
one test technique that employs silicon nodes. Note that if any
upstream control node or nodes must be conventionally disabled for
testing, it must have a physical probe assigned.

4-22 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Figure 4-14 Interconnect Test checks connections for most shorts and some opens within
the chain
A
u1 B u2
C

TDI

Nodes tested in
Interconnect

u3 u4

TDO

Frames and Signatures

Before you explore interconnect tests, you need to understand the
concepts of frames and signatures. For the circuit in Figure 4- 14, the data
pattern is set up as shown in Table 4- 4.

Table 4-4 Data pattern for sample circuit

Frame
Node 1 2 3 4 5
A 0 1 0 0 1
B 0 1 0 1 0
Rows form signatures
C 0 1 0 1 1
D 0 1 1 0 1

The columns of bits form frames. Frames are vectors that are shifted into
the chain serially (serialized vectors). The number of bits in a frame is
determined by the number of cells in the active, concatenated register. The
VCL frame is two times the size of the active register because two vectors
are needed for each clock cycle.

Boundary-Scan Testing 4-23

4 Testing Boundary-Scan Device Chains

The rows of bits form signatures, also called identification (ID) patterns,
for these nodes. Signatures (IDs) must be different for each node so
software can distinguish one node from another.
The frame statement found in the VCL source code tells the system's
deep- capture RAM to capture bits shifting out of TDO. The frame size tells
you how many bits are shifted into the deep- capture RAM each time a
frame is executed. The following example frame would be needed to shift
the fourth frame (0110) of the signatures for Figure 4- 15.

Example 4-3 Example frame

frame 0 1
000X
100X
001X
101X
001X
101X
000X
100X
01XX
end frame

To create an interconnect test of five bits per signature, as Figure 4- 15

shows, we can use the five frames shown above.
The frame position for each node is determined by the order of the drive
cells in the chain’s boundary register. The states are output at the
UPDATE- DR TAP state. When the devices pass through CAPTURE- DR, the
receivers connected to the corresponding node should capture the bits of
that node’s ID.

4-24 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Figure 4-15 Interconnect Test uses frames and signatures

A 0 1 0 0 1
u1 B 0 1 0 1 0 u2
C 0 1 0 1 1

TDI

A
u3 B u4
D 0 1 1 0 1

TDO

Frame 1 2 3 4 5

How the Software Designates a Driver for Interconnect Test

As mentioned earlier, the interconnect test attempts to use only one driver
for each bussed node if at all possible. The software examines the BSDL
files and the device connections, then identifies one driver (the designated
driver) as the one that will be used to drive the node during the
interconnect test. All other drivers connected to the node are disabled.
These drivers are tested later during buswire test.

Boundary-Scan Testing 4-25

4 Testing Boundary-Scan Device Chains

Figure 4-16 Bussed drivers share same control cell

11
u1 12 u2
13

TDI

Control Cell

8
u3 9 u4
10

TDO

Control Cell

Several circumstances can prevent the software from designating only one
driver. Figure 4- 16 illustrates one situation where bussed drivers share the
same control cell. For this example, let's say that the software looks for
and finds a driver for u1.13. It finds the only one available and designates
it as the driver for that node. Notice that this pin's control cell is also
connected to the drivers for u1.11 and u1.12.
By itself, this is not a problem. However, when the software moves on and
designates a driver for u3.10, the control cell for that pin also enables the
drivers for u3.8 and u3.9, which are connected to u1.11 and u1.12
respectively. The situation that now arises is that the two buswires (nodes
A and B) have multiple drivers.
This situation must occur because the interconnect test needs to drive
these nodes during testing. To eliminate bus fights, the software ensures
that the data on these drivers is the same. Fault masking, which can
result from this situation, is rectified during buswire test.

4-26 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Executing Interconnect Test

The Interconnect test first shifts the instruction bits into each device in
the chain to set up the SAMPLE/PRELOAD function. (These are labeled as
SAMPLE in the VCL source file because SAMPLE is a reserved word in
BSDL.) The data pattern for the first frame is then loaded in the drive
cells connected to nodes A- D. Figure 4- 17 on page 4- 28 shows an example
of all 0s shifted in.
The devices then go through UPDATE- IR to change to the EXTEST
function, where they will remain during testing.

The exception to this is a TAP-only device, which is always in BYPASS

NOTE
during testing.

When the devices pass through UPDATE- IR, the driver cells drive the
SAMPLE/PRELOAD data bits to the board nodes where the states can be
observed by the receive cells. As the devices pass through CAPTURE- DR,
the receive cells capture the data, and subsequently shift it out. When
these bits are being shifted out, new bits are shifted in. Subsequent passes
through UPDATE- DR drive new bits to the nodes and thus to the receive
cells, which are then captured and shifted out for examination. Data
captured on each receiver on each node should correspond to the
signature for each node.
Safe bits (described in the BSDL file) are shifted in for the last frame to
flush the Boundary Register and shift the final signature bits out. The safe
bits control the boundary register cell states (and thus the I/O pin states)
at the end of the test.
The examples that follow are simplified to provide a basic understanding
of how the software detects faults during test. The actual diagnosis is
more complex and is explained later in this chapter.

Boundary-Scan Testing 4-27

4 Testing Boundary-Scan Device Chains

Figure 4-17 PRELOAD zeroes (0) shifted in to drive cells

A 0
u1 B 0 u2
C 0

TDI

u3 u4
D 0

TDO

If, upon capture, the 0 loaded into driver u1.A was captured as a 0 on
u4.A, but as a 1 on u2.A, then the software would report a failure
(probably an open) on u2.A. See Figure 4- 18.

Figure 4-18 Interconnect Test finding an open on a receiver

Open
A 0 1 A
u1 B 0 B u2
C 0
TDI

A 0 0 A
u3 B 0 u4
D 0

TDO

4-28 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Similarly, if an open was present immediately downstream from u1.A,

receivers u2.A and u4.A would see consistent, errant data, which would
indicate an open, or a short to VCC on u1.A. See Figure 4- 19.

Figure 4-19 Interconnect Test finding an open on a driver

Open
A 0 1 A
u1 B 0 u2
C 0
TDI

A 0 1 A
u3 B 0 u4
D 0

TDO

Boundary-Scan Testing 4-29

4 Testing Boundary-Scan Device Chains

Enhanced Counting Sequence

InterconnectPlus software's interconnect test employs an enhanced
counting sequence test to search for opens and shorts. The frames below
provide an example of how this test is executed.

Table 4-5 Frames illustrate how test is executed

Frames
Node Power Bits Counting Bits Complement Bits
Eliminates Aliasing Primarily Distinguishes One Node Reduces Incidence of Aliasing
to Ground or VCC From Another Between Active Nodes
A 0 1 0 0 0 1 1 1 0
B 0 1 0 0 1 0 1 0 1
C 0 1 0 0 1 1 1 0 0
D 0 1 0 1 0 0 0 1 1

The enhanced counting sequence first assigns a 01 bit combination called

the power bits. These bits verify that the node is not shorted to VCC or
ground. They also eliminate aliasing to these power nodes. The counting bits
follow, and form the part of the node's signature that primarily
distinguishes one node from another; no two nodes can have the same
number. The above example shows four bits, but the length of these bits is
determined by the number of nodes in one frame. The last part of the
signature, the complement bits reduce the incidence of aliasing between
active nodes. The number of bits used here is a fixed percentage of the
number of counting bits used.
Figure 4- 20 shows how a short is detected by comparing the expected
signature of a particular node with the one captured during testing.

4-30 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Figure 4-20 Interconnect Test uses signatures to check for shorts and opens. In this example, a short is
detected
Expected Captured
Signatures Signatures
A
u1 B 0 1 0 0 1 1 u2
C 0 0 1 0 1 1

TDI

A
u3 B u4
D

TDO

Testing Bidirectional Pins

The Interconnect test fixes the direction in which it tests bidirectional
cells. An internal routine determines whether to test specific bidirectional
cells as drivers or as receivers.

Boundary-Scan Testing 4-31

4 Testing Boundary-Scan Device Chains

Interconnect Test and Bussed Devices

Opens on bussed devices is a class of problems that are not checked for in
interconnect tests. Safety is the main issue here because buswire tests
lengthen the time during which power is applied to the board; shorts
could damage devices during this time.
Buswire tests are drawn out of interconnect tests and made an
independent object, which alleviates this problem; it minimizes the number
of frames needed for interconnect test, which allows shorts to be detected
as soon as possible. For more information, see Buswire Test on page 4- 33.

Figure 4-21 Software breaks out buswire tests from Interconnect Test
11
u1 12 u2
13

TDI

Control Cell

8
u3 9 u4
10

TDO

Control Cell

4-32 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Buswire Test
This test is created automatically, and in most cases will work without
debug. This section is provided for reference only.
During the interconnect test, opens on bussed nodes could be missed for a
number of reasons. Because of the safety issues mentioned above,
attention to this class of faults is delegated to separate, buswire tests. The
buswire test is derived from the connectivity information used to generate
the interconnect test. If the development software sees that the chain has
bussed devices, it generates the buswire test. As with the interconnect
test, nodes completely tested via connect tests are commented from the
buswire ITL to minimize ground bounce. Figure 4- 22 illustrates a buswire
test.

Figure 4-22 Buswire Test verifies connections on bussed nodes

u1 u2

TDI

u3 u4

TDO

The buswire test looks only for opens on bussed devices. Shorts are not a
concern because these were tested for in the tests (shorts, powered shorts,
and interconnect) executed earlier. Drivers are tested one at a time to
ensure that all possible situations for which opens could occur are tested.
Figure 4- 23 shows several examples where opens could be missed during
interconnect testing in the case of bussed devices:
• A - If only one driver per bussed wire is enabled during the
interconnect test, opens on the disabled drivers would not be detected.
• B - If two or more drivers must be enabled to satisfy the interconnect
test and they drive the same node, an open on one of these drivers
would not be detected.

Boundary-Scan Testing 4-33

4 Testing Boundary-Scan Device Chains

• C - If two or more drivers must be enabled because they are connected

to the same control cell, an open on one of these drivers would not be
detected, even in the buswire test.

Figure 4-23 Example cases where opens could go undetected by interconnect test on
bussed wires

A. Typical case B. Multiple node devices from

control cell format design
undetected failure

OFF
ON

ON

OFF ON

undetected failure undetected failure

C. Ganged drivers
ON

ON

undetected failure
This failure is difficult to detect and diagnose by any electrical method.

Testing Bidirectional Pins

Bidirectional pins are tested, like other bussed wires, one at a time. Each
bidirectional pin is tested once as a driver, then once as a receiver to
ensure that both functions operate properly.

4-34 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Testing Parallel Busses

One other issue to consider when testing bussed devices is parallel busses.
InterconnectPlus was designed to handle these cases with minimal impact
on test size and execution time.
Because the sample chain includes two pairs of bussed wires (A and B in
Figure 4- 24), each separate independent bus can be tested in parallel.

Table 4-6

Device.Pin Node Bit Pattern

u1.10 A 01 ZZ
u3.10 A ZZ 01
u1.9 B 01 ZZ
u3.9 B ZZ 01

Figure 4-24 Parallel testing for separate bussed nodes

10 A 7
u1 9 B 6
u2
8 C
5

TDI

10 A 7
u1 9 B 6
u4
8 D 5

TDO

If the chain included a third driver on wire B, as shown in Figure 4- 25, a

third pair of frames would be needed to test this wire. The number of
frames in a buswire test is equal to two times the size of the bus with the
largest number of devices connected to it.

Boundary-Scan Testing 4-35

4 Testing Boundary-Scan Device Chains

Table 4-7

Device.Pin Node Bit Pattern

u1.10 A 01 ZZ ZZ
u3.10 A ZZ 01 ZZ
u1.9 B 01 ZZ ZZ
u5.5 B ZZ 01 ZZ
u3.9 B ZZ ZZ 01

Figure 4-25 Multiple drivers on one bus require additional frames

A
B
C

TDI

A
B
D

TDO

4-36 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Connect Test
This test is created automatically, and in most cases will work without
debug. This section is provided for reference only.
InterconnectPlus connect test allows you to test for opens on device inputs
and outputs that have physical probes assigned to them. Shorts between
pins with testhead access are detected by the unpowered shorts test.
Connect tests are run sequentially, from the first device in the chain (uX)
to the last device in the chain (uY) until all devices have been tested. All
other devices in the chain are placed in BYPASS. At least one connect test
is generated for each scan device specified to be connect tested. Multiple
tests will be generated if the Connect Max parameter is used. Figure 4- 26
illustrates a boundary- scan connect test.
If an upstream boundary- scan device in the same chain is in BYPASS and
it has outputs that affect the DUT, the development software will generate
the required disabling methods to eliminate conflicts if a library test is
available with a suitable disable construct.
More commonly, this is addressed by setting the Boundary- Scan Disables
flag in the board file, or by editing the chain definition in the ITL file to
disable the desired device.

Figure 4-26 Connect Test checks the connections of each device in a chain

TDI

TDO

Note that the nodes tested by a connect test would not have been tested
by interconnect test if they were not part of the interconnect circuitry.

Boundary-Scan Testing 4-37

4 Testing Boundary-Scan Device Chains

The connect test employs the Parallel Toggle macro. The default test
pattern is all ones and all zeros. The developer can change this to
alternating ones and zeros using the checkerboard keyword.
Complementary patterns are captured, shifted, and compared to check for
opens. A test is created for each boundary- scan device that:
• is not TAP ONLY (as indicated in the data entry phase), and
• has one or more of its pins connected to real testhead probes.
A connect test performs the following actions:
• Inputs are confirmed by placing an alternating 0/1 pattern on the
testhead nails and looking for this pattern on the device inputs.
• Outputs are confirmed by first placing all device outputs high, then low
(in alternating patterns), and looking for this pattern at the testhead
nails.
This output testing is skipped entirely if the test inputs only
command is put into the ITL file.
A connect test can fail in one of three ways:
• the TAP integrity procedure could detect a problem
• ground bounce can be detected
• the connect verification routines could detect a problem
Failure messages describing the exact nature of problems detected during
the TAP Integrity procedure are encoded directly in the VCL source itself.
The failing vector number is also printed on the repair ticket along with a
failure message. These two items provide you with a place to begin looking
for the problem.
Connect tests can be created for each device in each boundary- scan chain
if those devices have any input or output pins connected directly to the
testhead (that is, if those devices have any accessible nodes). These tests
do not check for shorts between nodes; they look for opens only.

Tests using checkerboard pattern will detect some shorts, but not all.
NOTE

Therefore, connect tests should not be executed until both the unpowered
shorts test and the (powered) interconnect test have been run. If this
procedure is not followed, undetected shorts could cause device damage
and inaccurate diagnosis.

4-38 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Testing Bidirectional Pins

The connect test verifies the operation of bidirectional pins by testing
them once as drivers, then once as receivers. Testhead resources are
allocated to permit testing these pins in both directions.

Datalogging software logs opens on bidirectional pins only during the

NOTE
output part of the test. Input failures of bidirectional pins are not
logged to prevent duplication of failure information.

Comparing Connect Test with Boundary-Scan In-circuit Test

A boundary- scan in- circuit test is similar to a connect test and is
performed on boundary- scan devices without regard for whether there is a
chain of boundary- scan devices. Connect tests are generated by the
InterconnectPlus software which treats each device as a part of a chain,
even if it is only a chain of one. Connect tests offer many options and
advantages over the in- circuit boundary- scan test.
• Devices not connected in a chain
An in- circuit test is performed on the devices in a stand- alone fashion.
All device pins to be tested require physical probes (especially TAP
pins). VCL “units” with inaccessible pins will be commented. In this
case, the running toggle macro will be ideal. A boundary- scan in- circuit
test is pin- oriented.
• Devices connected in a chain
A connect test is performed on one device at a time; other devices in
the chain are in BYPASS or HIGHL. Only those nodes that have physical
probes assigned are tested. A boundary- scan connect test is
node- oriented.
A connect test provides superior diagnostic resolution. The in- circuit test
normally finds only one faulty node, then stops the test. The connect test
can find multiple failures and reports on all of them.
The boundary- scan in- circuit test is discussed in Introduction to
Boundary- Scan as the EXTEST stand- alone function.

Boundary-Scan Testing 4-39

4 Testing Boundary-Scan Device Chains

Figure 4-27 Comparing boundary-scan in-circuit and connect tests

TDI

TDO
Devices treated as
stand-alone
Devices connected in a chain
Physical probe (all connect test nodes with probes are tested)

Custom Boundary-Scan Tests

Custom boundary- scan tests are used to access the instructions (listed in
the devices' BSDL files) that can be used for special test purposes beyond
those supported by EXTEST, such as powered shorts, interconnect,
buswire, or connect test. These custom tests perform specific functions
that are not added to your board test as part of the automatic test
generation process.
Like the standard Boundary- Scan software, InterconnectPlus features an
interactive user interface that helps you develop custom boundary- scan
tests for your device chains. Multichip Scan Port Driver describes how to
use the software.
The MSPD software requires a custom ITL file, of type “custom”, to base
its test generation on. It will then output a VCL file which will be the
actual test. It is usually best to modify the ITL file for the interconnect
test for the target chain. Change the keyword from “interconnect” to
“custom”.
See Developing Custom Tests (UnMux Systems) for instructions on creating
custom tests on UnMux systems.

4-40 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Generating Tests for Boundary-Scan Chains

Once you describe your boundary- scan devices and board topology to the
test system, test generation is automatic. Generation of boundary- scan
tests is integral to the test system software. The information that you
provide allows the system to identify boundary- scan devices and the types
of test needed for these devices.
Although the InterconnectPlus software generates tests automatically for
your boundary- scan devices, you should still understand how the test
system uses the information that you provide to generate your device
tests. This section provides a brief discussion of this test generation
process.
This section also describes:
• how to enter the information needed by the system.
• the importance of complete and accurate BSDL files; a critical link to
successful implementation of boundary- scan testing.
• disabling or overdriving devices that affect boundary- scan testing.
• best practices for developing boundary- scan tests.
• the boundary- scan testability report

The Test Generation Process

Figure 4- 28 is a flow diagram of the process for generating a chain test.
The process starts with the input of board information about each device.
The resulting tests are generated automatically.

The BSDL file for each device must be complete and accurate.
NOTE
Incomplete or inaccurate descriptions can result in complicated debug
later in the process. See Verifying BSDL Descriptions.

The board files board and board_xy are used by the development software
to determine the devices in a chain and their locations on the circuit
board.

ITL source files contain references to BSDL files. These files must be
NOTE
compiled (creating .o objects) before compiling the ITL files.

Boundary-Scan Testing 4-41

 Figure 4-28 Process flow for generating a chain test
4-42

4
Testing Boundary-Scan Device Chains
Test Development Software

“board” “board_xy”

Compiler
Notes:
ITL source files contain references to BSDL
files. These files must be compiled (creating
.o objects) before compiling the ITL files.
“board.o” “board_xy.o”
* Connect tests are optional for each device
in the chain. There will be more than one test
TOPOLOGY
per device if the Connect Max is used.
Test Development Software
creates ITL source files

Connect Test
Silicon Nail ITL Powered Shorts Test Interconnect Test Buswire Test Disable Test Silicon Nail Test
(0 or more* per device
(optional, multiple tests; (1 per chain) (1 per chain) (1 per chain) (optional, multiple tests) (optional, multiple tests)
connected to real nails)
manually written) uX_uY_ps uX_uY uX_uY_bus uX_uY_dis uX
uX_connect

Test Development Software

creates VCL source files

Powered Shorts Test Interconnect Test Buswire Test Connect Test Serialized Test
<testname>.xml <custom>.vcl uX_uY_ps.vcl uX_uY.vcl uX_uY_bus.vcl uX_connect.vcl uX.vcl Disable Test
and and and and and uX_uY_dis.vcl
uX_uY_ps.vcl.x uX_uY.vcl.x uX_uY_bus.vcl.x uX_uY_connect.vcl.x uX.vcl.x

Compiler

Powered Shorts Test Interconnect Test Buswire Test Connect Test Silicon Nail Test
(executable) (executable) uX.o Disable Test
<custom>.r (executable) (executable) uX_uY_dis.r
or uX_uY_ps.r uX_uY.r uX_uY_bus.r uX_connect.r (executable)
Boundary-Scan Testing

or or or or
<custom>.o or or uX_uY_dis.o
uX_uY_ps.o uX_Y.o uX_uY_bus.o uX_connect.o uX.r

TESTHEAD Results Analysis

 Testing Boundary-Scan Device Chains 4

The software generates multiple preliminary test structures: powered

shorts, interconnect, buswire, connect (optional), disable (optional), and
silicon nail (optional). The software generates the following tests:
• one interconnect test for each chain,
• one buswire test for each chain,
• one powered shorts test for each chain,
• zero, one or more connect tests for each device in the chain connected
to physical probes,
• one disable test, if selected, and
• multiple silicon nail tests, if selected.
The names assigned to each test type are:
• Powered shorts test:
<device_1>_<device_2>_ps
where <device_1> is the name of the first device in the chain and
<device_2> is the name of the last device in the chain.
For example: u1_u4_ps.
• Interconnect test:
<device_1>_<device_2>
where <device_1> is the name of the first device in the chain and
<device_2> is the name of the last device in the chain.
For example: u1_u4.
• Buswire test:
<device_1>_<device_2>_bus
where <device_1> is the name of the first device in the chain and
<device_2> is the name of the last device in the chain.
For example: u1_u4_bus.
• Connect test:
<device>_connect
where <device> is the name of one device in the chain.
For example: u3_connect.
If the Connect Max option is used, multiple connect tests will be
generated for each device. Naming is in the form
<device>_connect_<letter>.
For example: u3_connect_a.
The software then creates the corresponding types of VCL source files.
These source files are used in the generation of executable tests which can
then be incorporated into the testplan.

The Silicon Nail test path is shown in Figure 4-28 only to identify its
NOTE
relationship to standard chain test generation. Silicon Nail testing is
discussed in Automated Silicon Nails.

Boundary-Scan Testing 4-43

4 Testing Boundary-Scan Device Chains

The test can then be run on the circuit board. At this time, the Results
Analysis Routine interacts with the testhead to diagnose and report
failures.

Describing the Boundary-Scan Device

To generate tests for a chain of boundary- scan devices, you must tell the
software where it can find the BSDL files for your devices, and you must
describe your devices.
Refer to the process for your test system:
• Developing Tests on UnMux Systems
• Developing Tests on Mux Systems

Developing Tests on UnMux Systems

From the Developer Interface, perform the following tasks:
• Configuration > Board Configuration > Board Options
Set boundary- scan test options.
• Data Input > Library Search Paths
Tell the software where to look for the BSDL files for your devices.
• Data Input > Device Test Data > Pin Library Devices
Enter device data.
• Data Input > Board Data > Boundary Scan
Specify which devices are to be tested with boundary- scan, and define
boundary- scan chains.
After you have described your devices and added them to your test, the
software checks to see if a library model exists for the test. You should
have at least a setup- only test in the library at this time, to provide
pertinent disabling and device family information. (Disabling information is
not needed for boundary- scan disabling; see Using Boundary- Scan
Disabling.)
Remember that specifying a device as TAP- only eliminates that device
from boundary- scan testing but allows you to keep the device in the chain,
which in turn allows for better overall testing of the chain.
You can specify a library test to be performed on a TAP- only device if you
wish. Select the Library option in the Pin Library Devices task to indicate that
you want the software to generate a standard digital library test for your
TAP- only device. Remember that you must have physical probes assigned
to every node for each device that will have a standard digital library test
generated.

4-44 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Developing Tests on Mux Systems

Using the Library Path Names Form

Use the Library Paths Form (Figure 4- 29) to tell IPG where to look for the
BSDL files for your devices.
1 In Board Consultant, click on the View/Edit Library Data button in the
flowchart, then Enter Library Paths from the list at the bottom of the
flowchart.
2 When the Library Paths Form appears, type the appropriate path in the
Library Path field.
3 When you finish entering new paths, click Update.
4 Click Close to exit the form.

Figure 4-29 Library Paths form

Using the Device Entry Form

Figure 4- 30 shows the device entry form for pin libraries, where you enter
information about your boundary- scan devices.
1 In Board Consultant, click on View/Edit Board Description in the flowchart,
then Enter Pin Library from the list at the bottom of the flowchart.
2 The basic Device Entry Form appears. Select Options > Show Scan Library
Test Options.
3 When the form appears, select Options > Maximize to display the form
shown in Figure 4- 30.
The entries that you make in the fields in the lower half of this form
complete the description of your chain. The fields are described in
Table 4- 8.

Boundary-Scan Testing 4-45

4 Testing Boundary-Scan Device Chains

Figure 4-30 Device Entry form

Table 4-8 Fields in Device Entry form

Option Description
Testable Select Yes if the device is to be tested, or No if it is not. Yes is the default
selection.
Test Using TestJet Select Yes if TestJet will be used to test this device. No is the default selection. If
you select Future, holes for TestJet probe are partially drilled, but the wiring and
mux assignment is not made.
TestJet Probing Select the TestJet probing method. Select the default, Keepout Method, to use the
old keepout technique. The other selections perform the following tasks:
Auto Selection Uses the device outline to programmatically define the TestJet probe type and
where to drill the fixture to mount this probe.

4-46 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Table 4-8 Fields in Device Entry form

Option Description
Foam Override Uses the foam mounted probe regardless of the dimensions of the device. (This
option is not allowed if the device is on the bottom side of board.)
Spring Override Allows you to override the software’s automatically selected probing method. The
software will choose a small or standard probe automatically, based on the device
outline dimensions. Use one of the following new options to override the
automatic choice:
Small Spring Override Instructs the fixturing software to use a small TestJet probe normally used with
Polarity Check tests. Probe locations are directly across from each other.
Standard Spring Override Instructs the fixturing software to use a standard TestJet probe. Probe locations
are at two opposite corners of the active board.
Any devices with TestJet Probing set to something other than Keepout Method
must also have a device outline in order for the software to determine where to
place the probe or where to partially drill for a potential future probe. If a device
with a non-keepout TestJet Probing setting does not have an assigned device
outline, this error that will prevent compilation of board_xy.
Library Test Expected Select Yes if you want the standard digital library test for the designated device to
be generated along with the boundary-scan tests. To execute this test, your device
must have probes assigned to all nodes. No is the default selection.
Test Using Connect Check Select Yes if Connect Check will be used to test the device. The default is Yes.
Device Outline Enter the corners of the device outline area in the X Value and Y Value fields. If
only two device outline points are entered, these two points will be treated as
opposite corners of a rectangle. If more than two device outline points are
entered, the device outline will be a polygon whose vertices are the points
entered, ordered exactly as they are listed in this form; point_1 to point_2 to ... to
point_N.
The device outline must have at least two points, and can have up to 120 points. If
the last point listed is not identical to the first, that point will be assumed
automatically in order to close the polygon. The units of measurement are
tenth-mils.
While any device may be assigned an explicit device outline, outlines are truly
required only for devices to have a TestJet probe placed over them automatically
(now or in the future) for testing using TestJet or Polarity Check (i.e., devices
whose TestJet Probing attribute is set to something other than Keepout Method).

Boundary-Scan Testing 4-47

4 Testing Boundary-Scan Device Chains

Table 4-8 Fields in Device Entry form

Option Description
Capture Graphic Device Click this button to copy the polygon currently being used as an outline for this
Outline device into this form as the explicitly assigned device outline. If the device outline
shown in the graphic is rectangular, only two points will be copied into the form --
the upper left and lower right corners of the rectangle. Otherwise, all of the points
in the graphic polygon are copied, keeping their ordering.
The default outline used in the graphics window is a rough guess based on device
pin locations. If it is not close enough to the actual device profile to allow
adequate probe placement, edit the outline and adjust it before you select Replace
Device.
Clear Clears out all the X/Y values. Once you have assigned an outline to a device, it will
be used in the graphics window. Thereafter this button will simply copy that
outline back from the graphics window. To return to the default, estimated outline
originally used in the graphics window, select Clear Outline, then Replace Device,
and press this button again.
Testability Standard Click on the 1149_1 box if the designated device is a boundary-scan device. When
you click on the 1149_1 box, you enable the options and data entry fields in the
lower half of this form. If you do not click on the 1149_1 box, the test system will
not consider this to be a boundary-scan device. Clicking on this box does not imply
that the device is fully-compliant with IEEE 1149.1.
BSDL Part Number Enter the name of the BSDL file for the designated device. This file is treated as a
library file in that it is looked for in the same order as other library devices
specified in the Library Paths Form. If a BSDL file match cannot be made, the
compiler will generate an error.
Device Package Type Enter or change the package type for the designated device. If the package type
specified cannot be found, the compiler will generate an error.
Connect Test Select Yes if you want IPG to generate a boundary-scan connect test for the
designated device. A connect test is written for the device only if physical probes
are assigned to nodes for that device. The part must have an interconnect test to
perform a connect test. The default is Yes.
TAP Signal Overrides Brings up the TAP Override Form to allow you to specify the nodes for tdi, tdo, tck,
tms, and trst, which will affect how the chain is derived but does not represent a
change in connectivity.
Interconnect Test Select Full if you want IPG to generate a boundary-scan powered shorts and
interconnect test (and associated buswire test) for the designated device. Select
TAP only if the device is non-compliant in some way, but you do want to keep this
device in your chain. The default is Full.

4-48 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Table 4-8 Fields in Device Entry form

Option Description
Connect Max Enter a value between 1-999 to specify the maximum number of nodes to test in
any connect test. This value is not applicable if TAP only or Interconnect only are
selected. If a zero is entered, this field will be set to blanks.
The digital kernel of a powered shorts test is essentially identical to that of an
interconnect test with one addition: the surrounding (adjacent) nailed nodes are
also tested automatically when a powered shorts test is generated.
Connect Max cannot be used with versions. You can only change Connect Max
value in the base device. The Connect Max value will be the same for all versions.
See The Connect Max Option on page 4-50 for an explanation of this feature.
Note: If you use Connect Max to conserve channels, select No for the Library Test
Expected field. If this field is Yes, the system will assign resources for a standard
in-circuit test, whether or not Connect Max is selected.

After you have described your devices and added them to your test, the
software checks to see if a library model exists for the test. You should
have at least a setup- only test in the library at this time, to provide
pertinent disabling and device family information. (Disabling information is
not needed for boundary- scan disabling; see Using Boundary- Scan
Disabling.) Note that IPG cannot find the setup- only tests unless you mark
the Library Test Expected field in each corresponding library entry form as
Yes.
Remember that specifying a device as TAP- only eliminates that device
from boundary- scan testing but allows you to keep the device in the chain,
which in turn allows for better overall testing of the chain.
Connect Test must be set to No if you want to specify the device as
TAP- only. Setting Connect Test to Yes disallows a TAP- only setting, or
changes the Interconnect Test button to Full if you had previously set it to
TAP- only.
You can specify a library test to be performed on a TAP- only device if you
wish. Set the Library Test Expected button to Yes if you want IPG to generate
a standard digital library test for your TAP- only device. Remember that
you must have physical probes assigned to every node for each device that
will have a standard digital library test generated.

Boundary-Scan Testing 4-49

4 Testing Boundary-Scan Device Chains

The Connect Max Option

You can specify the maximum number of nodes to test in any connect test
(Connect Max option).
The digital kernel of a powered shorts test is essentially identical to that
of an interconnect test with one addition: the surrounding (adjacent)
nailed nodes are also tested automatically when a powered shorts test is
generated
One of the standard parts of the test development process is verifying that
your board test will fit within the resources of your test system.
Sometimes, you encounter a situation where you require more digital
channels than your test system has available. If this problem is the result
of a connect test on a large boundary- scan IC, the Connect Max feature
can often help.
The Connect Max feature allows you to test boards that otherwise would
have exceeded the channel count of your system. For example, you can
divide a connect test of 400 pins into eight small connect tests by setting
the Connect Max to 50. It is a good practice to set the Connect Max to an
even divisor of the number of pins.
Whenever you specify a Connect Max setting, you should also mark the
part as not expecting a library test. If a library test is expected, the test
will require the channels you otherwise would have saved by breaking
apart the connect test.
By using the Connect Max feature, you can use testers that are
appropriate to the number of nodes on the board, without having to add
pin cards to accommodate a large number of channels. You can determine
the number of channels used in the connect test (or any other digital test)
by the following procedure:
• Add the number of input pins to the number of bidirectional pins
• Add the number of output pins to the number of bidirectional pins.
• Select the larger of the two numbers determined above. This is the
channel count.

4-50 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Understanding the Contents of the BSDL File

Because the Boundary- Scan Description Language (BSDL) file is used to
create thousands of test vectors automatically, it is very important to make
sure that each BSDL file is complete and accurate before working with
scan chains. Accuracy in this description is very important for correct
fault diagnosis and minimal debug time.
Extra effort in this phase can save many hours, or even days, of debug in
later phases. In the early implementations of boundary- scan, many things
are unknown. A few crucial questions that must be answered include:
• Does the device meet the IEEE standard?
• Is the TAP controller standard- compliant?
• Does the BSDL description correctly describe the silicon?
Note that if the BSDL description is technically correct, but does not
exactly match the silicon implementation, then false faults will be
reported, and more time will be spent in debug.
Other unknowns include, but are not limited to:
• Does the person who writes the BSDL have correct information?
• Have any typographical errors been introduced?
The description of the boundary- scan characteristics of a device is
contained in the BSDL file for the device. If the BSDL descriptions of all
of the devices in a chain are correct, and the topological descriptions of
the circuit interconnections are correct, few things can negatively affect an
automatically- generated test.
The construction of the boundary- scan chain is extracted from the board
topology and the BSDL file for a device. That description is used to
determine such things as:
• The locations in the overall TDI- TDO chain that correspond to the
expected data for each cell connected to each pin on each device. This
tells the test generation and analysis routines where to find the bits
representing each node.
• Which cells in the boundary- scan chain are control cells, and what
outputs or bidirectional pins they control. This data is used to disable
pins that might interfere with the test.
• What the expected IDCODES for each device should be. The IDCODES
are verified during the TAP integrity test.
• What each cell in the Instruction Register captures when clocked in the
CAPTURE- IR state. The expected capture information is verified for
each device during the test.

Boundary-Scan Testing 4-51

4 Testing Boundary-Scan Device Chains

What are the problems that might be encountered if an inaccurate BSDL

file were provided for a device? Consider Figure 4- 31, an example of how
interconnect tests are executed.
Each of the interconnections between the two devices terminates at a
Boundary Register cell (either a driver or receiver). The test information
placed on the interconnections is shifted in through TDI. The results of
the test are shifted out from TDO and captured. The captured data is
subsequently examined.
Figure 4- 31 shows an extra internal cell that could be missed in the BSDL
file. If this were the case, the Boundary Register description for the device
would be incorrect, and data would be placed into or extracted from the
wrong positions in the chain. Not only would the information be wrong for
the device described, but if the length of the Boundary Register was
incorrect, every device in the chain between the wrongly described device
and TDI would be offset by the inaccuracy.
This would be catastrophic for the GO/NOGO test, and for the failure
analysis. Every pin on every device in the inaccurate area would fail
because the cells being examined would not be the ones containing the
expected data. Misrepresented registers can result in garbled signatures.
Now, consider the effects of failing to accurately describe the control cells
for a device. Figure 4- 31 shows two output control cells for one device. If
this device needed to be disabled, and the control information were
inaccurate, then the disable would not occur. The effect would be that
those nodes connected to the non- disabled pins would fail with a variety
of incorrect diagnoses.
For these and other reasons, we strongly recommend that the BSDL
descriptions of each device be thoroughly verified against the silicon itself;
once for each new device type.

4-52 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Figure 4-31 Inaccurate BSDL descriptions cause testing problems

u1 u2

TDI

u3 u4

TDO

Internal Cell*

Output
Control

Output Control*
TDI TDO
TCK TMS * Cells missing from BSDL

Verifying BSDL Descriptions

To eliminate as many of these potential problems as possible, you should
use an automatic tool to create BSDL files. If a verified automatic process
is not in place, you should test the BSDL file and the new component in a
stand- alone configuration, without interference from other components.
This can be done by using the Verify BSDL macro in the standard
Boundary- Scan software to automatically generate a test for each device.
The test generated can then be executed by doing one of the following:
• building a special test fixture for the component
• loading one board with only the boundary- scan component and
arranging access to all pins
• verifying the BSDL file at device test if the semiconductor test supports
BSDL- based boundary- scan
• translating the test to simulator input, then simulating it against a
model of the device
See Verify BSDL for more information about the macro.

Boundary-Scan Testing 4-53

4 Testing Boundary-Scan Device Chains

Where to Place BSDL Files and Associated Packages

Ideally, you should place all custom BSDL files and their associated
packages in one location so that they can be found easily by system
software. The pathname to the directory reserved for this function is
/Agilent_ICT/library/supplemental/bsdl. This path is guaranteed to be
where standard packages are. However, you may also place BSDL files in
library directories associated with the board directory. Be sure to provide
a library path to them.
Placing user- defined packages in the proper location is of particular
importance. When reading a BSDL file, the system will look for associated
packages:
• in the same directory where the BSDL file itself resides, and
• in the standard location, /Agilent_ICT/library/supplemental/bsdl
On the other hand, the main BSDL file belongs in the board directory’s
library path, which may or may not include ../supplemental/bsdl. Give
the BSDL file and digital library files for a device different names so the
system will not mistake one for the other. Having the same names in
different paths will not avoid such a mistake.

4-54 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Conventional Disabling of Boundary-Scan Devices

To disable boundary- scan devices, you can use the techniques described in
this section. You can also use boundary- scan resources to disable device
outputs. See Using Boundary- Scan Disabling on page 4- 58 for more
information.
For conventional disabling, the development software will take care of all
bus disabling for interconnect, buswire, and connect tests, just as it does
for standard digital tests. However, you must provide disable vectors for
Silicon Nail tests. Figure 4- 32 shows a circuit that requires bus disabling.
All disabling nodes must have physical probes assigned to them.
During a boundary- scan test, you can encounter several disable conflicts.
Some of these include:
• disabling a control node connected to an interconnect node
• disabling a control node connected to a connect test output
• a device output that cannot be disabled that is connected to a connect
test output
• a device output that cannot be disabled that is connected to an
interconnect node, except for tested boundary- scan outputs on devices
in the chain being tested
The development software removes bussed nodes from boundary- scan tests
if the proper disabling cannot be done. The software cannot always
accomplish the disables as needed. If a disabling conflict arises, the
software rejects the disable method, and reports in the source file that the
node was not disabled.

Figure 4-32 Disabling a device to maintain a stable test

Device must be disabled

when u1 and u2 share
data.

TDI TDO

Boundary-Scan Testing 4-55

4 Testing Boundary-Scan Device Chains

All boundary- scan devices should have at least setup- only files in a digital
library before you generate your fixture files so that disabling information
is provided. To understand why this is necessary, consider the scenario
illustrated by Figure 4- 33.

Figure 4-33 Boundary-scan devices set in BYPASS and needing disabling must use standard device disabling
methods

EXTEST BYPASS

TDI

BYPASS BYPASS

TDO

Bidirectional pins

The illustration shows a chain of boundary- scan devices with three

bidirectional pins bussed together. This bus also has a physical probe
assigned, so a connect test will be generated for each device. Remember
that when a connect test is executed, only one device is tested at any one
time. All other devices are placed in BYPASS.
The devices not being tested must be disabled so that they will not
interfere with the verification of the device under test. Because they are in
BYPASS, and the core logic is active, the bidirectional pins could be active.
Therefore, it is necessary to disable the devices in BYPASS by using
standard disable methods.
The software will do this automatically, but it must have at least a digital
library setup- only file that contains the disable information so it can
perform the required disabling.
For more information about conventional disabling, refer to Digital Testing.

4-56 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Fixed Node Considerations

If you know that your board has fixed nodes - tied to power or ground -
use the software to define them in your board file. The software will add
this information to the ITL source file. The example below shows an ITL
source file for a connect test that includes fixed node information.

Example 4-4 ITL source file with fixed node information

connect "u44"
chain "u57_u44"
tdi "TDI"
tdo "TDO"
tms "TMS"
tck "TCK"
trst "TRST"
devices
"u44", "users/scan_brd/digital/74bct8374", "FK_PACKAGE", no
end devices
end chain
nodes
fixed high "+5V" test "u44.7"
node "u44-8" hybrid test "u44.8"
end nodes
end connect

You should understand that if the software cannot identify a fixed node as
being high or low, it will still add this information to the ITL source file,
but the line will be commented out, and the state will be labeled
unknown. You will have to edit the ITL source file to describe the state as
high or low, then uncomment the line.

Boundary-Scan Testing 4-57

4 Testing Boundary-Scan Device Chains

Using Boundary-Scan Disabling

InterconnectPlus lets you use boundary- scan resources to disable device
outputs.
To use this feature, do the following:
• UnMux systems: From the Developer Interface, select Configuration >
Board Configuration > Board Options and set the Boundary- Scan Disabling
option on.
• Mux systems: From Board Consultant, set the Boundary- Scan Disable
option to On. This option is found in the IPG Global Options Form.

When you set Boundary-Scan Disabling on, Boundary-Scan Overdrive

NOTE
is automatically set to off.

By defining Boundary- Scan Disabling, you can control how devices in the
chain that have bussed pins will be disabled during connect tests of other
devices.

Boundary-Scan Disable Off

When a connect test is executed, only one device is tested at a time. All
other devices are placed in BYPASS. If bussed pins are to be tested, the
devices not being tested may need to be disabled so they will not interfere
with verification of the device under test. Because devices not being tested
are issued the BYPASS instruction, and the core logic may be active,
bidirectional pins could be active. Therefore, it might be necessary to
disable the devices in BYPASS by using standard disable methods.

Boundary-Scan Disable On
When a connect test is executed, only one device is tested at a time. If
other devices in the chain have bussed pins that need to be disabled in
order to test a pin of the selected device, the bussed devices will be issued
the HIGHZ instruction, instead of the BYPASS instruction, to allow testing
of the bussed pins.
If the HIGHZ instruction is not available for a device that needs to be
disabled, the device will be issued the CLAMP instruction during the
connect test, if it is available. If the CLAMP instruction is not available,
the device will be issued the EXTEST instruction, and its boundary
register will be loaded with the necessary patterns to control the drivers
for the bussed pins.

4-58 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Advantages of Boundary-Scan Disabling

Boundary- scan disabling offers these advantages:
• Works in any situation that requires an upstream disable for a test
(provided that the upstream device can be disabled with boundary- scan
- see Limitations of Boundary- Scan Disabling on page 4- 60).
• Minimizes the need for conventional disabling (see Conventional
Disabling of Boundary- Scan Devices on page 4- 55). This can decrease
the resource requirements for in- circuit tests. It also removes the need
to manually specify disable methods in device libraries, reducing the
opportunity for error.
• Speeds the disabling process.
• Increases the chance of successfully disabling devices.
• Relieves many conventional disable conflicts.
• Runs automatically once you have turned it on.

Effects of Boundary-Scan Disabling

Boundary- scan disabling has these effects:
• If the Boundary- scan library test does not include the HIGHZ
statement, only pins of type output and bidir are disabled. If the
Boundary- scan library test does include the HIGHZ statement, pins of
type buffer are also disabled.
• Adds a new ITL file with the suffix _dis for each chain.
• Adds a new VCL program with the suffix _dis for each chain.
• After boundary- scan disabling, boundary- scan device TAPs are placed
in the Run- Test/Idle state instead of the Test- Logic- Reset state. This
may create the need to add pull- down resistors to maintain the
Run- Test/Idle state during subsequent testing. See Maintaining
Persistence of Boundary- Scan Disables on page 4- 61 for more
information.
• After performing boundary- scan disables, the test plan pauses, displays
a message on the screen, and inserts a comment into the test program.
See Maintaining Persistence of Boundary- Scan Disables on page 4- 61
for more information.
• On Mux systems, the IPG verbosity modes give information about
boundary- scan disables.
Boundary- scan disabling may also affect testing order:
• For a single chain:
• Boundary- scan tests take place.
• Boundary- scan disabling occurs.
• In- circuit tests are performed.

Boundary-Scan Testing 4-59

4 Testing Boundary-Scan Device Chains

• For multiple chains:

• Boundary- scan disabling occurs for all chains except the one being
tested.
• Boundary- scan tests take place for the current chain.
• The two tasks above are repeated for each chain.
• Boundary- scan disabling takes place for all chains.
• In- circuit tests are performed.

Like all boundary-scan tests, the boundary-scan disabling program can

NOTE
fail because of bad chain integrity. The disable program checks chain
integrity before performing disables. If chain integrity is bad, you will
receive an error message. Subsequent tests that depend on the
boundary-scan disabling will not be performed.

Limitations of Boundary-Scan Disabling

Boundary- scan disabling will not work with all devices, pins, or chains.
You must use conventional disabling with:
• Tap- only devices, which are assumed to support BYPASS mode only
• Non- compliant output pins
• Hybrid chains such as multiple independent serial paths with common
TCK and TMS signals
• A chain without access to a TAP signal
Boundary- scan disabling is also limited in these situations:
• If you do a conventional in- circuit test on a boundary- scan device when
it is in boundary- scan disable mode, the device will ignore and fail the
test. To make the device work, you must reset the device. You can reset
by going to the Test- Logic- Reset state, by a normal Reset, or cycling the
power. (Which method to use depends on the component.)
• During manual debug, you must run VCL programs for boundary- scan
chain disables before running any target in- circuit tests. If you do not
run the disable programs first, the in- circuit tests may not work.
(Pushbutton Debug automatically executes the disables in the proper
order.)
• You cannot use boundary- scan disabling for boundary- scan devices that
have non- compliant pins. If you disable boundary- scan pins, the
device’s internal logic may go into an undefined state and prevent a
conventional disable from working on the remaining pins (Figure 4- 34).
If a boundary- scan device has any non- compliant pins, you must
declare the device to be TAP- only and use conventional disabling on all
the device’s pins.

4-60 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Figure 4-34 Boundary-scan disabling when there are non-compliant pins

Boundary-scan disabling may leave a device’s internal logic in an undefined state and
prevent the conventional disabling of non-boundary-scan pins

Disabled boundary-scan pins

ine ic
def log
d
un rnal
e
Int
Non-boundary-scan pin Disabled boundary-scan pins
(non-compliant)
BP

Non-boundary-scan pin
IR
(non-compliant)
TAP
CONTROLLER

Boundary-scan device with non-compliant pins

Maintaining Persistence of Boundary-Scan Disables

Some device and board designs may destroy boundary- scan disables. You
may thus need to take additional measures to maintain the disables for
subsequent tests.
Without boundary- scan disabling, boundary- scan device TAPs end testing
in the Test- Logic- Reset state. Boundary- scan disabling, however, parks
each TAP in the Run- Test/Idle state (Figure 4- 35).
TAP state machines in every device of the chain must be held in
Run- Test/Idle during any subsequent digital testing that depends on
boundary- scan disables. This is called persistence.
A standard boundary- scan device contains internal pull- up resistors on
TMS. These resistors may make the TAP go to the Test- Logic- Reset state
if:
• An oscillator is connected to the TCK input.
• Noise is generated by other parts of the board that couple into TCK.
The existence of these conditions should alert you to check the persistence
of boundary- scan disables.

Boundary-Scan Testing 4-61

4 Testing Boundary-Scan Device Chains

Also, after performing boundary- scan disables, the test plan pauses and
displays the message:
Test Programmer Action Reminder:
Evaluate, act, and then delete this 'pause' section.

Figure 4-35 TAP Controller State Diagram

Normal boundary-scan tests end in this state

Boundary-scan
disabling places
the component
in this state

Source: IEEE Standard 1149.1

The test plan inserts a comment into the test program that reminds you to
check the persistence of your boundary- scan disables. These comments
follow the pause statement. You can view them when you edit the test
program. Example 4- 5 shows a sample message.

4-62 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Example 4-5 Sample message

print "Test Programmer Action Reminder:"
print "Evaluate, act, and then delete this ’pause’ section."
pause ! Comment out pause and print statements above when evaluation complete.
!! This ’pause’ section is placed here to remind the test programmer
!! that the Boundary-Scan disable tests depend upon their respective
!! TCK/TMS signals being held in a stable state while other testing
!! is done. This assures that the disabled state of the Boundary-Scan
!! chain is not accidently lost. Board level circuitry may
!! interfere with the persistence of the disabled state. You may
!! need to take additional measures; for example, you may place your
!! own pullup/down resistor in the fixture to assure a stable TMS
!! and/or TCK, or utilize a GP relay to disable some TCK oscillator, etc.
!! For further explanation, see the Boundary-Scan Manual for the
!! section titled ’Maintaining Persistence of Boundary-Scan Disables’.
!!
!! When you have assured persistence of the disable state, you should
!! comment out the print/pause statements above. It would also be a
!! good idea to briefly document here the measures you may have taken
!! (if any were needed) to assure persistence of the disables.

As stated in the message, you should change the print and pause
statements to comments after you check persistence and debug the
program.
To check persistence:
1 Prepare the test with the Boundary- Scan Disabling field set to On.
2 Run the test until it pauses.
3 Examine the TCK and TMS signals to make sure they are in a stable
state. TMS and TCK should be held to a logic low level. (TCK could also
be held to a logic high level if all boundary- scan devices support a
stable state when TCK stops at 1.)
4 If TCK and TMS are not quiescent - such as when an oscillator is
connected to TCK - do one of the following:
• Shut the oscillator off.
• Connect TCK to a general purpose relay to a pull- down resistor
(typically 150 ohms to ground for TTL/CMOS). This keeps the TAP in
Run- Test/Idle. For example, the oscillator line may include an AND
gate to which you can connect the pull- down (Figure 4- 36).
• If the oscillator is not gated, add the relay to pull- down to TMS
(Figure 4- 36). As shown in the state diagram (Figure 4- 37), feeding a
zero signal to TMS keeps the TAP in Run- Test/Idle.

If you use a GP relay to pull down a signal, the relay must be closed
NOTE
when the testplan implements boundary-scan disables.

Boundary-Scan Testing 4-63

4 Testing Boundary-Scan Device Chains

Figure 4-36 Maintaining the persistence of a boundary-scan disable by adding a

pull-down or relay

TMS (should be held at a logic low level)

Boundary-scan devices GP
with internal pull-up Vcc Vcc
resistors for TMS

TCK TCK
Oscillator

AND
TCK should be held at a logic low level.
It can also be held at a logic high level
if all boundary-scan devices support a
stable state when TCK stops at “1”.

GP Optional general-purpose relay to

pulldown resistor (<= 150 ohms)

5 If you have multiple chains with a common TCK and different TMS
signals - such as the two paralleled serial chains with common TCK in
Figure 4- 37 - you may need multiple put- downs to the TMS lines to
maintain persistence.

Figure 4-37 Example of chain that requires multiple pulldowns

TDI TDI TDO TDI TDO

TMS TCK TMS TCK

TMS1

TCK TDO

TMS2

TCK TMS TCK TMS

TDI TDO TDI TDO

4-64 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Overdriving Boundary-Scan Devices

When the development software generates a connect test, it tries to use all
of the chain. If you assign physical probes to each (or specific) TDI/TDO
node, the system can overdrive these nodes, and an individual device can
be tested. This may shorten test time and provide better fault isolation.
To use this feature, do the following:
• UnMux systems: From the Developer Interface, select Configuration >
Board Configuration > Board Options and set the Boundary- Scan Overdrive
option on.
• Mux systems: Use the IPG Global Options Form in Board Consultant to
set the Boundary- Scan Overdrive on.
There is a potential problem with overdriving since the portion of the
chain not involved in the test is still being clocked. If you do not want to
overdrive upstream TDOs, you would leave Boundary- Scan Overdrive off
and the software would use the entire chain rather than local TDI/TDO
nodes.
If you turn Boundary- Scan Overdrive on, the software will use the local
TDI and TDO nodes for each device to be overdriven provided probes exist
on these nodes.

When you set Boundary-Scan Disables on, Boundary-Scan Overdrive

NOTE
is automatically set to off. See Using Boundary-Scan Disabling on
page 4-58 for more information.

Boundary-Scan Linker/MUX
Boundary- Scan Linker/MUX devices can create testing difficulties. For
example, these devices may appear in chains in up to five places. They
appear as the device itself, and also as pad bits1 in up to four places.
These pad bits are internal to the device but appear in the chain as well.
This causes a one bit delay per pad in the chain, causing the test to fail.
The solution is to combine these pad bits into the proper places in the
chain.

1. Pad bits are shift register cells (like 'internal' cells) that are inserted in the Boundary Register
chain at specific places. Each adds a new TCK shift cycle needed to move data through the chain.

Boundary-Scan Testing 4-65

4 Testing Boundary-Scan Device Chains

There are two ways in which this can be done, as illustrated in the
following examples:
• Method 1 - After IPG generates the ITL files, edit them to include the
necessary pad and insert keywords.
• Method 2 - A better alternative is to add the pad and insert keywords
in the board file, so that the ITL files are generated correctly by IPG.

Method 1
Figure 4- 38 shows a device linking simple chains A, B, and C. Pad bits are
inserted in the linked chain and are actually resident in the 74ACT8997
device. These pad bits appear in a normal 1149.1 form at the end of the
chain.

Figure 4-38 74ACT8997 Linker/MUX device linking chains A, B, and C

.

A1 A2 Ai

PAD
TDI BIT

B1 B2 Bj

PAD
BIT

C1 C2 Ck 8997

PAD
BIT TDO

The first running of the board compiler on a board containing a single

linker controlling two chains, would interpret the topology as those chains.
Either the new testability report or the result of a list object statement
on the board.o file (if Boundary- Scan Chain Override is on) will look like
Example 4- 6.

4-66 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Example 4-6 Testability Report

BOUNDARY SCAN CHAINS
1u1_1u4
TDI 1TDI
TDO 1TDO
TCK 1TCK
TMS 1TMS
DEVICES
1u1, 1u2, 1u3, 1u4;
2u1_2u4
TDI 2TDI
TDO 2TDO
TCK 2TCK
TMS 2TMS
DEVICES
2u1, 2u2, 2u3, 2u4;
linker_linker
TDI TDI-LINKER
TDO TDO-LINKER
TCK TCK-LINKER
TMS TMS-LINKER
DEVICES
linker;
END;

This could be edited to connect the two chains and the linker into a single
chain, though without pad bits at this time. Example 4- 7 shows the
resulting single chain description.

Example 4-7 Single chain description

BOUNDARY SCAN CHAINS
1u1_linker ! put two chains and linker together
TDI TDI-LINKER ! specify linker’s TAP signals
TDO TDO-LINKER ! drives the two chains’ TAPs
TCK TCK-LINKER
TMS TMS-LINKER
DEVICES
!!! PAD, ! Pad bit inside linker
1u1, 1u2, 1u3, 1u4, ! first chain, TDI-->TDO order
!!! PAD, ! Pad bit inside linker
2u1, 2u2, 2u3, 2u4, ! second chain, TDI-->TDO order
linker; ! ends

The system runs tpg, creating ITL files for the chain. These ITL files have
a chain description section that looks like Example 4- 8.

Boundary-Scan Testing 4-67

4 Testing Boundary-Scan Device Chains

Example 4-8 Chain description

chain "1u1_linker"
tdi "TDI_LINKER" channel;hybrid
tdo "TDO_LINKER" channel;hybrid
tms "TMS_LINKER" channel;hybrid
tck "TCK_LINKER" channel;hybrid
devices
"1u1", "custom/74bct8374", "DW_PACKAGE", no
"1u2", "custom/74bct8374", "DW_PACKAGE", no
"1u3", "custom/74bct8374", "DW_PACKAGE", no
"1u4", "custom/74bct8374", "DW_PACKAGE", no
"2u1", "custom/74bct8374", "DW_PACKAGE", no
"2u2", "custom/74bct8374", "DW_PACKAGE", no
"2u3", "custom/74bct8374", "DW_PACKAGE", no
"2u4", "custom/74bct8374", "DW_PACKAGE", no
"linker", "custom/74act8997", "PQFP-48", no
end devices
end chain

You then edit in the pad bits and optionally, the pointer to the PCF
fragment needed to configure the linker/MUX chip.

Example 4-9 Edited chain description

chain "1u1_1u4"
tdi "TDI_LINKER" channel;hybrid
tdo "TDO_LINKER" channel;hybrid
tms "TMS_LINKER" channel;hybrid
tck "TCK_LINKER" channel;hybrid
devices
pad
"1u1", "custom/74bct8374", "DW_PACKAGE", no
"1u2", "custom/74bct8374", "DW_PACKAGE", no
"1u3", "custom/74bct8374", "DW_PACKAGE", no
"1u4", "custom/74bct8374", "DW_PACKAGE", no
pad
"2u1", "custom/74bct8374", "DW_PACKAGE", no
"2u2", "custom/74bct8374", "DW_PACKAGE", no
"2u3", "custom/74bct8374", "DW_PACKAGE", no
"2u4", "custom/74bct8374", "DW_PACKAGE", no
"linker", "custom/74act8997", "PQFP-48", no
end devices
insert "digital/linker_setup"
end chain

See the following examples:

• Example 1
• Example 2

4-68 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Example 1
You have just translated CAD data and now have a board file. The
Boundary- Scan section of the testability report tells you that three
Boundary- Scan chains exist on the board when you thought there was
one. You discover a TI 74ACT8997 chip and two subchains on the board.
You decide to test the board with the chains and the linker all grafted
together. This means that you will need to turn on the Global
Boundary- Scan Chain Override.
The list object function generates a new board file with the chain structure
described at the very end. You edit the file as shown in the preceding
section to perform the graft. The program generation process continues
until the ITL files for Boundary- Scan are created. You edit the ITL files to
add in the pad bits and a pointer to the PCF fragment, called, for
example, linker_setup under the digital directory. You next create a text
file under the digital directory called linker_setup containing a PCF block
utilizing the scan PCF order for the TAP pins. This causes the linker to
configure itself to control two subchains linked as one, per the
TI74ACT8997 data sheet, as shown in the next example.
Now you compile the ITL files and move on in the normal board
development process. These files may be marked as permanent to retain
them if the tests are regenerated. No other intervention is required.

Example 2
• Example 4- 10 on page 4- 71 is the ITL source file for an interconnect
test, for a chain that consists of a MUX/Linker and one secondary
chain. Note that in the chain section, IC 2u8 is a linker/multiplexor IC.
The TAP port connections (including a TRST* pin) are all made to IC
2u8.
In the devices section, a pad keyword is inserted before the description
of device 2u1 to indicate that the MUX/Linker IC inserts a pad bit at
the beginning of the chain. If there had been other secondary chains
connected to the MUX/Linker IC, each of these is proceeded by a pad
keyword as well.
Just before the end of the chain description is an insertion statement
identifying a fragment of PCF code that is inserted into the generated
test. The PCF that is inserted is designed to program the
linker/multiplexor IC to connect the other ICs, 2u1 through 2u2, to the
first multiplexor port. The end result when this linkage is completed is
a chain of 5 devices, 2u1 through 2u8.
The rest of the ITL is unchanged from an interconnect description for a
normal chain.

Boundary-Scan Testing 4-69

4 Testing Boundary-Scan Device Chains

• Example 4- 11 on page 4- 72 is the PCF fragment used to program the

MUX/Linker chip such that the SSP1 (Secondary Scan Path 1) is
enabled. This fragment of PCF code assumes the MUX/Linker IC is
already in the Run- Test/Idle TAP state. The PCF fragment loads the
Mux/Linker Instruction Register with the SCANSEL instruction which
targets the SELECTR register. This 8- bit register is loaded with two- bit
fields that connect the desired Secondary Scan Paths (SSP1 in this
case). PCF vectors are then issued to update the SELECTR register and
the MUX/Linker TAP is brought back to the Run- Test/Idle state.
This fragment was prepared using the Scan Port Driver (SPD) program
with a BSDL description of the MUX/Linker IC, and developing a PCF
test program that loads SELECTR with the appropriate control bits as
specified by the data sheet. Then, just the portion (fragment) between
the two Run- Test/Idle states is retained, while the rest is discarded.
This saves the effort of programming the MUX/Linker manually.
Note that when the MUX/Linker has been reset, it does not connect any
SSP, and each SSP has its individual TMS held high so that they are
constantly being forced to Test- Logic- Reset while the MUX/Linker is
programmed. Just as the MUX/Linker is finishing being programmed,
the SSPs are allowed to move to the Run- Test/Idle state at the same
time the MUX/Linker is moving to Run- Test/Idle. This is how the ICs of
the newly linked chain(s) and the linker all end up synchronized
together in Run- Test/Idle.
The completed PCF fragment should be given a meaningful name, stored
in the digital directory, and referenced by the ITL insert statement as
shown in Example 4- 10.
• Example 4- 12 on page 4- 74 is a portion of the VCL source file created
by compiling the above ITL with the PCF fragment included.
The vectors start out by sending the MUX/Linker to Test- Logic- Reset.
When in this state, the SSPs are also held in Test- Logic- Reset. After the
disable vectors are applied and another Test- Logic- Reset sequence
(handy in the case where the disable has affected the MUX/Linker or a
Secondary Scan Path), you will see the inclusion of the PCF fragment
that programs the MUX/Linker at vector 28. After this, the test
continues from the Run- Test/Idle state, now with all the chain devices
being connected and synchronized. The rest of the test proceeds as
usual and has been deleted for brevity. One exception to this is the
addition of Pad Bit shift states (for example, see around vector 175).
This accounts for the position of a pad bit inserted in the chain by the
MUX/Linker. The test is appropriately phased to account for the
positions of all pad bits.

4-70 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Example 4-10 ITL source file for interconnect test

interconnect "mux_2u1_2u8"

chain "2u1_2u8"
tdi "2MTDI" channel;hybrid
tdo "2MTDO" channel;hybrid
tms "2MTMS" channel;hybrid
tck "2MTCK" channel;hybrid
trst "2MTRST" channel;hybrid
devices
pad
"2u1", "custom/74bct8374", "DW_PACKAGE", no
"2u2", "custom/74bct8374", "DW_PACKAGE", no
"2u3", "custom/74bct8374", "DW_PACKAGE", no
"2u4", "custom/74bct8374", "DW_PACKAGE", no
"2u8", "custom/74act8997", "DW", no
end devices
insert "digital/2u8_setup"
end chain

disables
node "2IN_26" channel;hybrid default "1"
node "2IN_28" channel;hybrid default "1"

pcf order is nodes "2IN_26","2IN_28"

unit "disable"
pcf
"11"
end pcf
end unit
end disables

nodes
fixed low "1IN_16" test "2u3.24"
silicon node "2U1_2" test "2u1.2","2u2.23"
silicon node "2U1_4" test "2u1.4","2u2.21"
silicon node "2U1_5" test "2u1.5","2u2.20","2u4.20"
silicon node "2U1_U3_7" test "2u1.7","2u2.19","2u3.7"
silicon node "2U1_U3_7" test "2u4.19"
silicon node "2U1_U3_8" test "2u1.8","2u2.17","2u3.8"
silicon node "2U1_U3_8" test "2u4.17"
silicon node "2U1_U3_9" test "2u1.9","2u2.16","2u3.9"
silicon node "2U1_U3_9" test "2u4.16"
silicon node "2U1_U3_10" test "2u1.10","2u2.15","2u3.10"
silicon node "2U1_U3_10" test "2u4.15"
silicon node "2U2_2" test "2u1.21","2u2.2"
silicon node "2U2_3" test "2u2.3","2u2.22"
silicon node "2U3_2" test "2u3.2","2u4.23"
silicon node "2U3_3" test "2u3.3","2u4.22"
silicon node "2U3_4" test "2u3.4","2u4.21"

Boundary-Scan Testing 4-71

4 Testing Boundary-Scan Device Chains

silicon node "2U4_2" test "2u1.20","2u4.2"

silicon node "2U4_3" test "2u3.21","2u4.3"
end nodes

end interconnect

Example 4-11 PCF fragment

! Begin insertion
"01ZX1"
"11ZX1"!Select-DR-Scan
"01ZX1"
"11ZX1"!Select-IR-Scan
"00ZX1"
"10ZX1"!Capture-IR
"00ZX1"
"10ZX1"!Shift-IR
end pcf
message "IEEE Std 1149.1-1990 Integrity Failure"
message " Device 2U8 has failed,"
message " suspect device or these pins:"
message " (tck) 15"
message " (tms) 14"
message " (tdi) 16"
message " (tdo) 13"
message " (trst) 26"
pcf
use pcf order Scan
"000H1"!0+0
"100X1"
"001L1"!1
"101X1"
! Loading device 2U8 with instruction SCANSEL(01111110).
"000L1"!2+0
"100X1"
"001X1"!1
"101X1"
"001L1"!2
"101X1"
"001L1"!3
"101X1"
"001L1"!4
"101X1"
"001X1"!5
"101X1"
"001L1"!6
"101X1"
"010H1"!7
"110X1"!Exit1-IR
"01ZX1"
"11ZX1"!Update-IR
end pcf

4-72 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

message ""
pcf
use pcf order Scan
"01ZX1"
"11ZX1"!Select-DR-Scan
"00ZX1"
"10ZX1"!Capture-DR
"00ZX1"
"10ZX1"!Shift-DR
! Loading device 2U8 register SELECTR[8] (for SCANSEL).
end pcf
message "IEEE Std 1149.1-1990 Integrity Failure"
message " Device 2U8 has failed,"
message " suspect device or these pins:"
message " (tck) 15"
message " (tms) 14"
message " (tdi) 16"
message " (tdo) 13"
message " (trst) 26"
pcf
use pcf order Scan
"001X1"!0+0
"101X1"
"001X1"!1
"101X1"
"000X1"!2
"100X1"
"000X1"!3
"100X1"
"000X1"!4
"100X1"
"000X1"!5
"100X1"
"000X1"!6
"100X1"
"010X1"!7
"110X1"!Exit1-DR
"01ZX1"
"11ZX1"!Update-DR
end pcf
message ""
pcf
use pcf order Scan
"00ZX1"
"10ZX1"!Run-Test/Idle
! End of insert

Boundary-Scan Testing 4-73

4 Testing Boundary-Scan Device Chains

Example 4-12 Portion of VCL source file from compiling ITL with PCF fragment
< source deleted >

! Device Entity Package BSDL File

! --------- ----------- ----------- -----------------
! Pad Bit
! 2U1 TTL74BCT8374 DW_PACKAGE custom/74bct8374
! 2U2 TTL74BCT8374 DW_PACKAGE custom/74bct8374
! 2U3 TTL74BCT8374 DW_PACKAGE custom/74bct8374
! 2U4 TTL74BCT8374 DW_PACKAGE custom/74bct8374
! 2U8 SN74ACT8997T DW custom/74act8997

scan interconnect ! for MUX_2U1_2U8

< source deleted >

pcf order default Scan is TCK, TMS, TDI, TDO, TRST

pcf order Disable is D000, D001

!Column-to-Node Map, Nodes 1 to 5

!22222!
!MMMMM!
!TTTTT!
!CMDDR!
!KSIOS!
! T!
! !
!
!
unit "Interconnect Test" ! Vector 1
pcf
use pcf order Scan
"01ZX0"!Reset via TRST* and synchronizing sequence
"11ZX0"
"01ZX1"
"11ZX1"
"01ZX1"
"11ZX1"
"01ZX1"
"11ZX1"
"01ZX1"
"11ZX1"
"01ZX1"
"11ZX1"!Test-Logic-Reset
!
! Disable Vectors
!
use pcf order Disable
"11"
!
! End of Disable Vectors

4-74 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

!
use pcf order Scan
"01ZX0"!Reset a second time via TRST* and synchronizing sequence
"11ZX0"!to assure that any now-enabled BScan devices also reset.
"01ZX1"
"11ZX1"
"01ZX1"
"11ZX1"
"01ZX1"
"11ZX1"
"01ZX1"
"11ZX1"
"01ZX1"
"11ZX1"!Test-Logic-Reset Vector 25
"00ZX1"
"10ZX1"!Run-Test/Idle
!
! Including PCF from file digital/2u8_setup.
!
! Begin insertion
"01ZX1"
"11ZX1"!Select-DR-Scan
"01ZX1"
"11ZX1"!Select-IR-Scan
"00ZX1"
"10ZX1"!Capture-IR
"00ZX1"
"10ZX1"!Shift-IR
end pcf
message "IEEE Std 1149.1-1990 Integrity Failure"
message " Device 2U8 has failed,"
message " suspect device or these pins:"
message " (tck) 15"
message " (tms) 14"
message " (tdi) 16"
message " (tdo) 13"
message " (trst) 26"
pcf
use pcf order Scan
"000H1"!0+0
"100X1"
"001L1"!1
"101X1"
! Loading device 2U8 with instruction SCANSEL(01111110).
"000L1"!2+0
"100X1"
"001X1"!1
"101X1"
"001L1"!2
"101X1"
"001L1"!3
"101X1"

Boundary-Scan Testing 4-75

4 Testing Boundary-Scan Device Chains

"001L1"!4
"101X1"
"001X1"!5
"101X1"
"001L1"!6
"101X1"
"010H1"!7
"110X1"!Exit1-IR
"01ZX1"
"11ZX1"!Update-IR
end pcf
message ""
pcf
use pcf order Scan
"01ZX1"
"11ZX1"!Select-DR-Scan
"00ZX1"
"10ZX1"!Capture-DR
"00ZX1"
"10ZX1"!Shift-DR
! Loading device 2U8 register SELECTR[8] (for SCANSEL).
end pcf
message "IEEE Std 1149.1-1990 Integrity Failure"
message " Device 2U8 has failed,"
message " suspect device or these pins:"
message " (tck) 15"
message " (tms) 14"
message " (tdi) 16"
message " (tdo) 13"
message " (trst) 26"
pcf
use pcf order Scan
"001X1"!0+0
"101X1"
"001X1"!1
"101X1"
"000X1"!2
"100X1"
"000X1"!3
"100X1"
"000X1"!4
"100X1"
"000X1"!5
"100X1"
"000X1"!6
"100X1"
"010X1"!7
"110X1"!Exit1-DR
"01ZX1"
"11ZX1"!Update-DR
end pcf
message ""

4-76 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

pcf
use pcf order Scan
"00ZX1"
"10ZX1"!Run-Test/Idle
! End of insert
!
! End of PCF from file digital/2u8_setup,
! 56 vectors inserted.
!
"01ZX1"
"11ZX1"!Select-DR-Scan
"01ZX1"
"11ZX1"!Select-IR-Scan
"00ZX1"
"10ZX1"!Capture-IR
"00ZX1"
"10ZX1"!Shift-IR
end pcf
message "IEEE Std 1149.1-1990 Integrity Failure"
message " Device 2U8 has failed,"
message " suspect device or these pins:"
message " (tck) 15"
message " (tms) 14"
message " (tdi) 16"
message " (tdo) 13"
message " (trst) 26"
pcf
use pcf order Scan
"000H1"!0+0
"100X1"
"001L1"!1
"101X1"
! Loading device 2U8 with instruction BYPASS(11111111).
"001L1"!2+0
"101X1"
"001X1"!1
"101X1"
"001L1"!2 Vector 100
"101X1"
"001L1"!3
"101X1"
"001L1"!4
"101X1"
"001X1"!5
"101X1"
end pcf
message "IEEE Std 1149.1-1990 Integrity Failure"
message " Device 2U4 has failed,"
message " suspect device or these pins:"
message " (tck) 13"
message " (tms) 12"
message " (tdi) 14"

Boundary-Scan Testing 4-77

4 Testing Boundary-Scan Device Chains

message " (tdo) 11"

pcf
use pcf order Scan
"001H1"!6
"101X1"
"001L1"!7
"101X1"
! Loading device 2U4 with instruction BYPASS(11111111).
"001L1"!10+0
"101X1"
"001L1"!1
"101X1"
"001L1"!2
"101X1"
"001L1"!3
"101X1"
"001L1"!4
"101X1"
"001H1"!5
"101X1"
end pcf
message "IEEE Std 1149.1-1990 Integrity Failure"
message " Device 2U3 has failed,"
message " suspect device or these pins:"
message " (tck) 13"
message " (tms) 12"
message " (tdi) 14"
message " (tdo) 11"
pcf
use pcf order Scan
"001H1"!6
"101X1"! Vector 125
"001L1"!7
"101X1"
! Loading device 2U3 with instruction BYPASS(11111111).
"001L1"!18+0
"101X1"
"001L1"!1
"101X1"
"001L1"!2
"101X1"
"001L1"!3
"101X1"
"001L1"!4
"101X1"
"001H1"!5
"101X1"
end pcf
message "IEEE Std 1149.1-1990 Integrity Failure"
message " Device 2U2 has failed,"
message " suspect device or these pins:"
message " (tck) 13"

4-78 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

message " (tms) 12"

message " (tdi) 14"
message " (tdo) 11"
pcf
use pcf order Scan
"001H1"!6
"101X1"
"001L1"!7
"101X1"
! Loading device 2U2 with instruction BYPASS(11111111).
"001L1"!26+0
"101X1"
"001L1"!1
"101X1"
"001L1"!2
"101X1"
"001L1"!3 Vector 150
"101X1"
"001L1"!4
"101X1"
"001H1"!5
"101X1"
end pcf
message "IEEE Std 1149.1-1990 Integrity Failure"
message " Device 2U1 has failed,"
message " suspect device or these pins:"
message " (tck) 13"
message " (tms) 12"
message " (tdi) 14"
message " (tdo) 11"
pcf
use pcf order Scan
"001H1"!6
"101X1"
"001L1"!7
"101X1"
! Loading device 2U1 with instruction BYPASS(11111111).
"001L1"!34+0
"101X1"
"001L1"!1
"101X1"
"001L1"!2
"101X1"
"001L1"!3
"101X1"
"001L1"!4
"101X1"
"001H1"!5
"101X1"
"001X1"!6
"101X1"
"001L1"!7

Boundary-Scan Testing 4-79

4 Testing Boundary-Scan Device Chains

"101X1"! Vector 175

! Shifting Pad Bit
"01ZH1"!42+0
"11ZX1"!Exit1-IR
"01ZX1"
"11ZX1"!Update-IR
end pcf
message ""
pcf
use pcf order Scan
"01ZX1"
"11ZX1"!Select-DR-Scan
"00ZX1"

< remainder deleted >

Method 2
Using BT- Basic, edit the board file and generate the tests. Add the insert
keyword (followed by the <PCF file path relative to the board dir>)
before the devices section of the corresponding Boundary- scan chain.
Add the pad keyword at the appropriate places in the devices section
(Example 4- 13). When generated, the ITL file will include the required
statements (Example 4- 14).

Example 4-13 Add pad and insert keywords in board file

BOUNDARY SCAN CHAINS
u100_u102
TDI "u100-tdi"
TDO "u102-tdo"
TCK "u100-tck"
TMS "u100-tms"
TRST "u28-4"
INSERT "rutabaga"
DEVICES
u100, pad, pad, u101, pad, pad, pad, pad, u102, pad, pad;

4-80 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Example 4-14 Generated ITL file

interconnect "u100_u102"

! IPG: User may add option statements here if needed.

family "TTL"

chain "u100_u102"
tdi "u100-tdi"
tdo "u102-tdo"
tms "u100-tms"
tck "u100-tck"
trst "U28-4"
devices
"u100", "custom_lib/bs001", "DIP", no
pad
pad
"u101", "custom_lib/bs005", "DIP", no
pad
pad
pad
pad
"u102", "custom_lib/bs001", "DIP", no
pad
pad
end devices
insert "rutabaga"
end chain

Boundary-Scan Testing 4-81

4 Testing Boundary-Scan Device Chains

Best Practices for Developing Boundary-Scan Tests

To ensure successful implementation of your boundary- scan tests, you
should examine the following sections to verify that you have considered
all possible areas that could cause testing problems.
• Proper Grounding
• Assigning Critical Attribute to TCK
• Removing Physical Probes
• Adding Power Cycling or Reset Sequence Where Needed

Proper Grounding
Make sure that your board and your test fixture have sufficient ground
paths and returns for the types of devices to be tested. In particular, you
should carefully consider boundary- scan devices that will employ connect
tests. If one of these devices has a large number of output pins that will
be exercised during a connect test, grounding should be increased to
prevent inadvertent state changes. For more information, refer to
Addressing Ground- Related Problems.

Assigning Critical Attribute to TCK

To ensure signal quality and fidelity, you should consider assigning the
CRITICAL attribute to the TCK node(s) when you describe your devices.
Assigning the critical attribute will increase the probability of having the
shortest possible wires assigned to this nodes. This is especially important
when one or more devices have a large number of pins tested during a
connect test.

Removing Physical Probes

Use the conservative approach to removing physical probes. Make sure that
all issues have been considered before removing probes. Some issues that
can influence the need to remove probes include:
• If many nodes are duplicated in connect/interconnect tests, and
grounding issues become a problem, some of these probes can be
eliminated so the connect test requires fewer testhead resources.
• If you have nodes that have only boundary- scan devices connected to
them (100% boundary- scan nodes), you could remove these probes to
free up resources for other needs.
• If you have nodes that have simple, non- boundary- scan devices
connected to them, and you are willing to write a Silicon Nails test for
these devices, you could remove these probes.

4-82 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

• If a node adjacent to a 100% boundary- scan node is sensitive (for

example, a boundary- scan node connected to a sensitive analog device),
you should ensure that particular boundary- scan node has a probe
assigned to it to detect shorts during standard, unpowered shorts
testing.

Figure 4-39 Removing probes requires careful consideration

VCC

Partial Node Clean Node Analog Node

U3_3
U3_2

Digital Node

Figure 4- 39 illustrates several situations that must be considered before

you remove physical probes. These situations are based primarily on the
type of node that you are considering for removal. The following are the
different types of nodes and their characteristics.
• Full boundary- scan node: Has a least one boundary- scan driver and at
least one boundary- scan receiver. Note that bidirectional, or output pins
with monitoring capability qualify a node as a full boundary- scan node.
Four types of full boundary- scan nodes that can occur on a given board
are:
• Clean node: Nodes with only boundary- scan inputs and outputs are
good candidates for probe removal.
• Digital node: Nodes with at least one conventional digital device (but
no analog devices) are also good candidates for probe removal if the
digital device is not a complicated device. Simpler digital devices can
still be tested using the Silicon Nails technique.
• Analog node: Nodes with at least one analog device (but no
conventional digital devices) can have probes removed, but you
would be trading off in- circuit test coverage. Probes are
recommended for these nodes.

Boundary-Scan Testing 4-83

4 Testing Boundary-Scan Device Chains

• Mixed node: Nodes with at least one each analog and conventional
digital devices are subject to the same conditions that apply to
digital and analog nodes. Removing probes from these nodes could
result in reduced fault coverage.
• Partial boundary- scan node: Has one or more boundary- scan drivers
or one or more boundary- scan receivers, but not both. Test probes are
recommended for all partial boundary- scan nodes.

You should not remove probes from disable control nodes. This action
NOTE
could restrict the test system’s ability to provide proper disable
methods for a test.

Adding Power Cycling or Reset Sequence Where Needed

You might need to add a power cycling or reset sequence procedure to
your testplan to ensure that your device chains are in the proper state for
testing.
When going into boundary- scan testing, the core logic of the devices in the
chain are disconnected from the rest of the board, which probably will
affect other devices operating in normal mode. Other devices exchanging
data with boundary- scan devices will consider the boundary- scan devices
inoperable.
Note that when the board comes out of boundary- scan mode, all the
boundary- scan devices go into BYPASS, and the core logic is reconnected
to the I/O pins, but the board and the boundary- scan devices do not
necessarily pick up where they left off.
To get the board back to normal operating mode, the board reset
procedure must be run, or board power must be cycled. You can do this
by adding a reset sequence or power cycling procedure to your testplan.
If you have multiple chains, be aware that interactions between chains can
be a problem. You might need to cycle power between tests to clear the
problems.
If you have problems with connect tests and/or disabling difficulties, you
should try adding a power cycling or reset sequence to your test.

4-84 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Boundary-Scan Node Testability Report

If you have the optional InterconnectPlus software, the development
software generates a testability report that includes recommendations
about probe requirements for nodes. the software determines if probe
access is needed for each node and whether the node already has probes
assigned. To make the recommended changes, you can easily transfer the
reported information into the board_xy file and rerun the development
software.

For automatically generated boundary-scan tests, the software writes

NOTE
the power cycling procedure for you. Reset sequence procedures
(particular to each board) and procedures for manually generated
tests must be added to the testplan manually.

Five categories of nodes are reported:

• Category 1: Nodes that have probes assigned but the probes can be
removed.
• Category 2: Nodes that have probes assigned and the probes should not
be removed.
• Category 3: Nodes that do not have probes assigned and probes are not
needed.
• Category 4: Nodes that do not have probes assigned but probes are
needed.
• Category 5: Nodes that do not have probes assigned but probes are
needed for powered shorts testing.
If you modify the board_xy file with the changes reported in the
testability report and rerun the software, a new testability report is
generated. You will notice a shift in how the nodes are categorized. That
is, nodes that previously belonged to Category 1, now belong to Category
3, and nodes that previously belonged to Category 4 or 5, now belong to
Category 2. You must be careful about nodes in Category 2. These nodes
may require user- written tests for fault coverage.
For each node category in the report there is an explanation of why the
nodes were included in that category (see Example 4- 15).

Boundary-Scan Testing 4-85

4 Testing Boundary-Scan Device Chains

Viewing the Testability Report

The testability report for boundary- scan nodes is contained in the
ipg/raw file, which must be formatted before you can read it. You can
execute the format program with the fmt statement in a BT- Basic window
to format the information in the ipg/raw file.
The following are some examples of how you can format the information:
• To output the formatted information to the screen for an interconnect
test name u1_u4, enter:
execute "fmt -t u1_u4_tr ipg/raw"; wait
Note that you must append the string _tr to the name of the
interconnect test to acquire the testability report for that test. The
information for the test u1_u4 is tagged in the ipg/raw file as u1_u4_tr.
• You can also direct the output to a file and then load or print that file
to view the information. To output the testability report for u1_u4 in a
file named u1_u4_details, enter (on one line):
execute "fmt -t u1_u4_tr ipg/raw u1_u4_details" |load
"u1_u4_details"
• To format the information about all tests in the ipg/raw file and place
the information in a file, enter:
execute "fmt ipg/raw <file name>"

Example 4- 15 shows a formatted testability report for an interconnect test

named u1_u4.

4-86 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Example 4-15 Formatted testability report

"u1_u4_tr"
BOUNDARY-SCAN NODE TESTABILITY REPORT.
|Comment key: "BSdvr" is the number of BScan drivers on a node, |
| "BSrcv" is the number of BScan receivers, |
| "dig" is the number of conventional digital pins, |
| "nondig" is the number of analog (etc.) pins. |
Category 1 Nodes (Have probes, and probes could be removed)
These nodes have the resources for Boundary-Scan Interconnect
testing and no other device pins exist that would require probes.
Be aware though that user-written tests might require probes on some
of these nodes or, some of these probes might be needed for unusual
disabling situations. The listing below lists the nodes in a
format that can easily be transferred into the board_xy file.
NODE U1_U3_10 NO_PROBE; ! BSdvr:2 BSrcv:2 dig:0 nondig:0
Category 2 Nodes (Have probes, and probes should be kept)
These nodes might not have the resources for Boundary-Scan Interconnect
testing or, other device pins exist on them that might require probes
to support their test. Removing probes from these nodes might reduce fault
coverage or cause the need for additional user-written tests. The
listing below lists the nodes in a format (commented) that can easily
be transferred into the board_xy file. Remove the comment (~!) to
remove the probe.
!NODE IN_05 NO_PROBE; ! BSdvr:0 BSrcv:2 dig:0 nondig:1
!NODE IN_17 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:1
!NODE OUT_09 NO_PROBE; ! BSdvr:1 BSrcv:0 dig:0 nondig:0
!NODE OUT_10 NO_PROBE; ! BSdvr:1 BSrcv:0 dig:0 nondig:0
!NODE IN_16 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:1
!NODE IN_24 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:0
!NODE IN_23 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:0
!NODE IN_22 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:0
!NODE IN_21 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:0
!NODE IN_20 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:0
!NODE IN_19 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:0
!NODE U3_3 NO_PROBE; ! BSdvr:1 BSrcv:1 dig:1 nondig:0
!NODE U3_2 NO_PROBE; ! BSdvr:1 BSrcv:1 dig:1 nondig:0
!NODE IN_18 NO_PROBE; ! BSdvr:0 BSrcv:2 dig:0 nondig:1
!NODE IN_04 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:1
!NODE OUT_04 NO_PROBE; ! BSdvr:1 BSrcv:0 dig:0 nondig:0
!NODE OUT_05 NO_PROBE; ! BSdvr:1 BSrcv:0 dig:0 nondig:0
!NODE OUT_06 NO_PROBE; ! BSdvr:1 BSrcv:0 dig:0 nondig:0
!NODE IN_03 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:1
!NODE IN_12 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:0
!NODE IN_11 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:0
!NODE IN_10 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:0
!NODE IN_09 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:0
!NODE IN_08 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:0
!NODE IN_07 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:0
!NODE IN_06 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:0
Category 3 Nodes (Have no probes, and probes are not needed)
These nodes have the resources for Boundary-Scan Interconnect

Boundary-Scan Testing 4-87

4 Testing Boundary-Scan Device Chains

testing and no other device pins exist that would require probes.
They have already had probes removed.
NODE U3_4 ! BSdvr:1 BSrcv:1 dig:0 nondig:0
NODE U1_U3_9 ! BSdvr:2 BSrcv:2 dig:0 nondig:0
NODE U1_U3_8 ! BSdvr:2 BSrcv:2 dig:0 nondig:0
NODE U1_U3_7 ! BSdvr:2 BSrcv:2 dig:0 nondig:0
NODE U1_5 ! BSdvr:1 BSrcv:2 dig:0 nondig:0
NODE U1_4 ! BSdvr:1 BSrcv:1 dig:0 nondig:0
NODE U1_3 ! BSdvr:1 BSrcv:1 dig:0 nondig:0
NODE U1_2 ! BSdvr:1 BSrcv:1 dig:0 nondig:0
Category 4 Nodes (Have no probes, and probes should be added)
These nodes might not have the resources for Boundary-Scan Interconnect
testing, or, other device pins exist on them that might require probes
to support their test. Adding probes will allow them to be tested.
Not adding probes will reduce fault coverage or cause the need for
additional user-written tests.
NODE U4_10 ! BSdvr:1 BSrcv:0 dig:1 nondig:0
NODE U4_9 ! BSdvr:1 BSrcv:0 dig:1 nondig:0
NODE U4_8 ! BSdvr:1 BSrcv:0 dig:1 nondig:0
NODE U4_7 ! BSdvr:1 BSrcv:0 dig:1 nondig:0
NODE U4_5 ! BSdvr:1 BSrcv:0 dig:1 nondig:0
NODE U4_4 ! BSdvr:1 BSrcv:0 dig:1 nondig:0
NODE U7_6 ! BSdvr:0 BSrcv:1 dig:1 nondig:0
NODE U7_5 ! BSdvr:0 BSrcv:1 dig:1 nondig:0
NODE U2_10 ! BSdvr:1 BSrcv:0 dig:1 nondig:0
NODE U2_9 ! BSdvr:1 BSrcv:0 dig:1 nondig:0
NODE U2_8 ! BSdvr:1 BSrcv:0 dig:1 nondig:0
NODE U2_7 ! BSdvr:1 BSrcv:0 dig:1 nondig:0
NODE U2_5 ! BSdvr:1 BSrcv:0 dig:1 nondig:0
NODE U6_3 ! BSdvr:0 BSrcv:1 dig:1 nondig:0
Category 5 Nodes (Have no probes, and probes should be added)
These nodes are capable of being shorted to Boundary-Scan nodes that
cannot be tested by the Powered Shorts algorithm for lack of
accessibility. These nodes are typically ordinary digital/analog
nodes, though some nodes here might also appear in category 4. Adding
probes will allow Powered Shorts testing. If probes are not added, then
coverage will be reduced or these shorts must be tested with some other
user-written test.
NODE U3_TDO
NODE U1_TDO

4-88 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Results Analysis Routine

Failures discovered when you run your device test are analyzed by a
built- in diagnostic tool. This tool features a rule- based results analysis
routine that uses deterministic analysis to evaluate the failure. Detailed
messages are then sent to the printing device and the testhead monitor.
The results analysis routine gets its data from:
• the testhead
• the board’s topology
• the test information object
The test information object, contained within the test object (.o) file,
consists of a compiled version of the source and .x (test dictionary) files.
It contains a description of the chain, failure messages to be printed under
certain circumstances, and the test dictionary descriptions of the expected
states on the various nodes to be tested.
The software employs an integrated rule set that helps determine the
problem. Diagnostics are better than traditional in- circuit testing because
of the added visibility on input pins of boundary- scan components.

Diagnostics
In a connect test, physical test probes on output pins are used to capture
data that is immediately analyzed by the software for pass or fail.
The diagnostics for all other tests depend on assembling all of the data
scanned out from the circuit. All frames must be assembled before analysis
can occur. All frame bits are held in the deep- capture RAM until the
entire signature has been built. The captured signatures are then compared
to the expected signatures found in the test dictionary. If a fault is
encountered, the software invokes a multi- level, rule- based diagnostics
program that examines the captured signature for various characteristics.
These characteristics determine the probable cause of the failure. Upon
determination of the probable failure cause, the software generates a
related message to help the operator identify the exact failure.

Aliasing
Aliasing occurs when the combined failures of two or more nodes results
in an ID of another node. For example, if nodes B and C shown in
Table 4- 9 were shorted, the resulting IDs captured on these nodes (00010)
would indicate a short to node A (00010).

For this discussion, the shorted nodes are ANDed to produce the
NOTE
resulting IDs. Other situations, such as ORed shorts or strongest
drivers, could produce different results, but similar problems.

Boundary-Scan Testing 4-89

4 Testing Boundary-Scan Device Chains

Table 4-9 Selected IDs Used to Illustrate Aliasing

A 0 0 0 1 0
B 0 0 1 1 0
C 0 1 0 1 0
D 1 0 0 1 1
E 0 1 1 1 0

If nodes D and E were also shorted, the resulting IDs captured on these
nodes (00010) would also indicate a short to node A (00010). This is
known as confounding because we cannot tell if these IDs reflect one or
two shorts.
InterconnectPlus alleviates the aliasing and confounding problems by using
the Enhanced Counting Sequence and adding a fixed number of
complementary bits that extend the IDs for each node. Table 4- 10 does
not show the enhanced counting sequence, but it does add the
complementary bits. This illustrates that shorting B and C now results in
a new ID (00010100) that no longer matches (aliases to) A (00010101);
shorting D and E also results in a unique ID (00010000). This provides
increased resolution for the software to distinguish one node from another.

Table 4-10 Adding Complementary Data Bits Alleviates Aliasing

A 0 0 0 1 0 1 0 1
B 0 0 1 1 0 1 0 0
C 0 1 0 1 0 1 0 1
D 1 0 0 1 1 0 0 1
E 0 1 1 1 0 1 0 0

4-90 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Results Analysis: Failures Causes and Messages

In conjunction with the deterministic analysis technique, the results
analysis routine comprises a list of failure causes, rules that are applied to
determine these causes, and messages related to the failure that help you
correct failures quickly.
• Results Analysis: Failure Causes
• Results Analysis: Messages

Results Analysis: Failure Causes

There are four failure causes possible from the diagnosis of the cell data:
• Short to a fixed node
• Short to a boundary- scan node
• Open circuit
• Unknown Failure
These causes are deduced from the failure analysis of the cell information
discussed in the next section. These causes might be due to a variety of
physical symptoms in the circuit itself. These symptoms are discussed in
Table 4- 11.

Table 4-11 Failure causes

Symptom Explanation
Short to a fixed node This is diagnosed whenever the symptoms are consistent with a short to a node
that is capable of holding the node under test to a fixed value. This will be
diagnosed if all data captured on a node is fixed and unchanging. The physical
causes for this could be:
• Damaged output driver on the device: ESD or other damage can cause the
driver not to change state under control of the Boundary Register.
• In the case where no cells are associated with the active driver (the output is
two-state or three-state only), an open circuit on the driver will also alias to
this problem. In this situation, the bus test will identify the problem more
accurately than the interconnect test.
Short to a boundary-scan This is diagnosed whenever two or more nodes are detected as having the same
node ID and that ID is not all zeroes or all ones. The physical causes for this could be:
• A short to one or more nodes that are also solely under the control of the
Boundary Register.
• A short to a non-boundary-scan node that produces an ID that matches the ID
of some other boundary-scan node.
• A short to a fixed node with a weak enough drive capability that it cannot hold
the node under test to a fixed level.
Note: This message tells you that the detected failure did not fit into one of the
other defined categories. Diagnosis is provided to the node level only.

Boundary-Scan Testing 4-91

4 Testing Boundary-Scan Device Chains

Table 4-11 Failure causes

Symptom Explanation
Open Circuit This is diagnosed whenever the driver is passing and one or more the receivers
connected to the node have a stuck-at fault.
Note: This will be diagnosed together with Short to a fixed node whenever the
active driver is not capable of monitoring its own output (for example, a two-state
or three-state driver).
The physical causes for Open Circuit could be:
• If all receivers are stuck-at, then it is probable that the active driver is not
connected to the node.
• If some of the receivers on the node receive good data, then it is probable that
the failing receivers are not connected to the node.
Unknown Failure This is diagnosed whenever the symptoms for a node are inconsistent with those
of a short circuit, an open circuit, or a combination of both. The physical causes for
this could be:
• A short circuit to a node has occurred, but the variations in the receiver
thresholds on the node under investigation are such that the receivers observe
different characteristics from the active drivers.
• A short circuit to a fixed node has occurred, but the drive capacity of the fixed
node is too weak to hold the node to a fixed level, but it is strong enough to
cause device receivers to see different data because of the variations in their
receive thresholds.
• A combination of shorts and opens exist on the node such that the variations
in the receive patterns is seen.
• A mis-wiring has occurred on the node and at least one of the receivers is
physically connected to the wrong node (not likely where packaged devices
are used, but possible in the case of Chip On Board or Multichip Module
technology using wirebond techniques).

4-92 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Results Analysis: Messages

When a boundary- scan test fails, a message that describes the failure is
sent to the report device. This message identifies the device and pin(s), or
the node(s) that failed. Example 4- 16 is one example of such a message.
Table 4- 12 explains the messages you may see.

Example 4-16
-----------------------------------
Thu Jan 09 17:54:33 1992
-----------------------------------
INTERCONNECT FAILURE DETECTED
FOR TEST digital/u1_u4
A short has been detected
between the following nodes:
U1_2 -- pins:
u1.2 u2.23
U1_3 -- pins:
u1.3 u2.22
-----------------------------------

Table 4-12 Failure messages

Message Explanation
Node <nodename> is stuck; The identified node is not toggling. The cause is probably a short to either
probably shorted to fixed node power or ground, but it is also possible that an open can cause this
diagnosis. Use the pin list associated with this message to check the
most probable locations for the problem.
A short has been detected between The node/pin list identifies all nodes and pins associated with the failure.
the following nodes Note that, with the use of the deterministic algorithm, if three or more
nodes are listed, it is possible (though unlikely) that one of the listed
nodes is not actually shorted (aliasing).
Node <nodename> is failing; All of the inputs on a particular node observe it toggling in the same
Probably a short, but the shorted manner, but that manner is not correct. This is most probably caused by a
node cannot be located. Pins short to another node that is not connected to a boundary-scan device.
involved are: Check the pin list to identify the most likely places for the failure.
Node <nodename> is stuck; The node is stuck, but the most probable cause of the problem is an open
suspect open on <device>.<pin>. on the device.pin identified. The difference between this message and
However, these pins should also be the previous one is that the RA routine, in analyzing the nodal activity,
checked for a short to power or has determined that the node probably is not shorted; however, it cannot
ground be sure, so you should check for a short to power or ground.
Pin is stuck; check for open on The RA routine has found that some of the pins on the node are correctly
<device>.<pin> connected to node toggling, but that the identified pin is stuck. The cause is probably an
<nodename> open on this pin alone.

Boundary-Scan Testing 4-93

4 Testing Boundary-Scan Device Chains

Table 4-12 Failure messages

Message Explanation
Node <nodename> is stuck; The failing node is stuck, and that node has only one driver and one
probable open on <device>.<pin> or receiver connected to it. In this case, no additional data is available from
<device>.<pin> other receivers on the node, so the problem cannot be diagnosed beyond
the two pins listed. A short to VCC or ground could also be the cause.
The following pins are detected During a buswire test, all pins (that will always be output or bidirectional
open: pins) have been detected open by the test.
Opens on Output or Bidir Pins During a connect test, all device outputs or bidirectional pins that have
failed are listed. Another diagnosis will list all inputs and bidirectional
pins that fail. Because bidirectional pins are verified in both directions, an
actual open should cause that pin to be listed both here and in the Opens
on Input or Bidir Pins diagnosis. If this does not occur, the most probable
cause of the problem is fixturing, or a failure in the I/O section of the
device being tested.
Opens on Input or Bidir Pins Like its companion message, this message occurs only for connect tests.
It lists the input or bidirectional pins detected as open (see the previous
message for further information).
Suspected open, but pin toggles: The indicated pin on a node is toggling, but not in the same manner as all
<device>.<pin> of the other pins on the same node. This indicates that the diagnosed pin
is receiving data, but not from the node under test. The cause is probably
a miswired fixture, or a pin bent such that it is disconnected from its
proper node and is making contact with an adjacent node.
Over Power Detected on TDI, TMS Because it is imperative that interconnect tests execute rapidly so that if
or TCK (check for non-disabled a short is detected power can be removed from the board, no pin
device) diagnosis of an over power condition on a testhead driver is performed.
These failures are extremely rare, but if one does occur, the cause is
probably that one of the listed nodes includes a device that is being
overdriven and is not disabled.
Safeguard Timeout Some tests (especially the interconnect test) are very long and it is
possible to get a safeguard timeout if upstream devices are being
overdriven. You should find a way to disable the upstream device.
Specifying safeguard none to resolve this condition could work, but
might risk device damage.
Over Power Detected On: Connect tests do not have the same execution time constraint as
interconnect tests. If this message is encountered, a driver pin list will
locate the exact point of the failure. The cause is probably a high-current
overdrive situation.

4-94 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Table 4-12 Failure messages

Message Explanation
Unexplained nodal activity; (check Injected noise in the circuit grounds cause the identified device to
for non-disabled device(s) perform in a completely unexpected fashion. This can occur if a device on
a boundary-scan node is not disabled and is (possibly) toggling
asynchronously with the testhead drivers. The message indicates that a
non-diagnosable failure has occurred.
Node <nodename> failed for The system detected a failure on this node, but its cause cannot be
unknown reason classified within any of the other categories. The test engineer should
look for a mis-wired fixture, noise on the node, non-disabled devices and
so on. We do know that the node identified is bad.
The following messages rarely appear, but have been added to accommodate the unlikely occurrence of
testhead hardware failure.
Test Exceeded Soft Timeout Limit A failure caused the test to greatly exceed its expected execution time.
The most likely cause is a hardware failure in the testhead.
Test Failed to Start The most likely cause is a failure in the testhead hardware.
Test Halted Due To Unknown Cause The most likely cause is a failure in the testhead hardware.

Examples of Device Failure Reports

The following are examples of device failure reports for the Sample
Boundary- Scan Device Chain. If you look closely at the schematic, you will
see several switches. These switches are used to insert failures into the
sample circuit. Closing or opening each switch (or a combination of
switches) produces various failures. This section explains what occurs
when selected switches are closed or opened by showing you what the
resulting failure messages are.
SWITCH 1.1
------------------------------
Thu Jan 09 17:50:06 1992
------------------------------
CONNECT FAILURE DETECTED FOR
DEVICE u1_connect
Test Name: digital/u1_connect
Opens on Input or Bidir Pins
u1.16
------------------------------
SWITCH 1.2
------------------------------
Thu Jan 09 17:50:06 1992
------------------------------
INTERCONNECT FAILURE DETECTED
FOR TEST digital/bus_u1_u4

Boundary-Scan Testing 4-95

4 Testing Boundary-Scan Device Chains

The following pins are

detected open:
u1.10
------------------------------
SWITCH 1.3
------------------------------
Thu Jan 09 17:50:06 1992
------------------------------
INTERCONNECT FAILURE DETECTED
FOR TEST digital/u1_u4
Node U1_5 is stuck;
suspect open on u1.5
However, these pins should
also be checked for a short
to power or ground:
u1.5 u2.20 u4.20
------------------------------
SWITCH 1.4
------------------------------
Thu Jan 09 17:50:06 1992
------------------------------
INTERCONNECT FAILURE DETECTED
FOR TEST DIGITAL/u1_u4
Failing Vector #: 26
IEEE Std 1149.1-1990
Integrity Failure
Device U1 has failed,
suspect device or these
pins:
(tck) 13
(tms) 12
(tdi) 14
(tdo) 11
------------------------------
SWITCH 1.5
------------------------------
Thu Jan 09 17:50:06 1992
------------------------------
INTERCONNECT FAILURE DETECTED
FOR TEST digital/u1_u4
Pin is stuck; check for open
on u2.20
connected to node U1_5.
------------------------------
Note that closing or opening other switches on the sample circuit produce
different failures and failure messages. If you have access to such a board
and fixture, you can test the board and insert these faults to see what the
resulting failures will be.

4-96 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Debugging Boundary-Scan Tests

Boundary- Scan tests use Agilent Pushbutton Debug just as standard digital
tests do. The source files associated with debug are the VCL files created
by MSPD.

Figure 4-40 Boundary-Scan debug

Test needs to be
debugged

Yes
Verified BSDL

No
Do we trust Yes
IEEE 1149.1
compliance?

No

Perform Board
Verify BSDL chain debug debug
test Pass

Fail

Figure 4- 40 shows the boundary- scan debug process.

• Is the BSDL verified? If it is, do you feel that IEEE 1149.1 is complied
with? If not, a choice is available:
• If you have a good idea which device is bad, verify BSDL on that
device. This requires full modal access to the device. A dedicated
fixture may be necessary, or the verification test can be ported to a
simulation model of the device.
• If you have no idea which device is bad, perform a chain debug test
to isolate a bad device and when isolated perform the verification of
BSDL test.
• If you trust that IEEE 1149.1 is complied with, perform the board
debug test.

Boundary-Scan Testing 4-97

4 Testing Boundary-Scan Device Chains

• If you feel that IEEE 1149.1 has not been complied with, perform either
the chain debug test or the verification of BSDL test.
• If the chain debug test passes, perform the board debug test.

Debugging BSDL and Compliance Problems

The Chain Debug test measures chain bit lengths in two ways:
• The test measures the length of the combined devices instruction
registers and compares this length with what the expected BSDL
lengths should be.
• The test measures the lengths of boundary registers iteratively and
compares this length with what the expected lengths should be.
A chain debug test can be created very simply from an existing ITL file.
For example, you suspect a problem with a chain of four devices called
U1_U4. Load the file into the Basic editor. The first keyword in the file
(for example, interconnect) identifies the type of test it will generate.
Change the keyword to debug. Save the file and recompile it.

A chain debug test is not a production test. It is only used for

NOTE
debugging purposes and should be deleted when debugging is
complete. Remember to restore the original test.

When the test compiles, it utilizes the fixture resources allocated to the
original test. When the chain debug test executes, it first measures the
length of the combined instruction registers of every IC in the chain.
When executed, a chain debug test does not perform a TAP integrity
NOTE
test. One reason for debugging chains is that you already know there
is an integrity problem and you are trying to get additional debug
information.

If the expected length of the instruction registers is different than what

the BSDL files for the ICs described, you will get a failure ticket saying
the measured length was too long or short. It cannot identify which device
has the incorrect length because IEEE 1149.1 cannot individually access
the instruction registers within a chain. If two devices are incorrect with
one device one bit too long and the other device one bit too short, then
the instruction length test may pass. If you are concerned about the
accuracy of the BSDL descriptions of the devices, you may want to
partition the chains into shorter segments (provided you have access to
TDI and TDO pins within the chain). This division will help remove
confusion.

4-98 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

The second check a chain debug test makes after measuring the
instruction registers is to iteratively measure the boundary register of each
IC. The IC to be tested is placed in SAMPLE while all others in the chain
are placed in BYPASS. The IC in SAMPLE has its boundary register
measured. Each IC is tested successively until one is found that does not
match its BSDL description. In this way, a failure is specific to one device.

Both checks of a chain debug test keep the chain devices out of test
NOTE
mode by using only BYPASS and SAMPLE instructions in the test.

The following are examples of failure reports from a chain debug test:
• This report indicates that the combined instruction register length is
shorter than expected from reading the BSDL descriptions:
u1_u4 HAS FAILED
vector = 232
Status: 15H
Pass/Fail error on following pins:
BRRCC NODE PIN
22203 TDO
Instruction Register string too short
-------------------------------------
• This report indicates that the boundary register in U1 is longer than
the BSDL specification states:
u1_u4 HAS FAILED
vector = 529
Status: 15H
Pass/Fail error on following pins:
BRRCC NODE PIN
22203 TDO
Boundary Reg. for U1 too long
-------------------------------------

Boundary-Scan Testing 4-99

4 Testing Boundary-Scan Device Chains

Debugging Executable Boundary-Scan Tests

The VCL files are named as follows:

Table 4-13 VCL file naming

Test Filename
Powered shorts test <device X>_<device Y>_ps.vcl
For example, u1_u4_ps.vcl
Interconnect test <device X>_<device Y>.vcl
For example, u1_u4.vcl
Buswire test <device X>_<device Y>_bus.vcl
For example, u1_u4_bus.vcl
Connect test <device X>_connect.vcl
For example, u1_connect.vcl

Debugging these tests relies on the VCL source for the test itself. This
source file can be found in the digital directory under the names shown
above. For example, the following pathname identifies a connect test for
u4: /user1/scan_brd/digital/u4_connect.vcl

Uppercase letters are not permitted in source file names.

NOTE

To debug boundary- scan tests, you can:

• use Pushbutton Debug, or edit the VCL source file directly or
• edit the ITL file
The ITL files are named as follows:

Table 4-14 ITL file naming

Test Filename
Powered shorts test <device x>_<device y>_ps
For example, u1_u4_ps
Interconnect test <device X>_<device Y>
For example, u1_u4
Buswire test <device X>_<device Y>_bus
For example, u1_u4_bus
Connect test <device X>_connect
For example, u1_connect

The following guidelines should help you decide which file to edit.

4-100 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Edit the ITL file if you:

• have problems with specific nodes
• want to add or correct device disable information
• want to change the TAP- only setting (no to yes)
• want to comment out a particular test or node that is causing an
unsolvable problem
Edit the VCL file if you:
• have problems with a particular bit in the boundary- scan chain
• want a fast, temporary solution to a problem
You should not alter the VCL file as a permanent solution except as a last
resort. Because the ITL file is compiled when you run the development
software, the VCL is re- created after each compile. If you want to make a
change permanent, you must compile the VCL file using BT- Basic, or edit
the ITL file so that the desired changes are made to the VCL file after you
compile using the software.

Both VCL and ITL tests are compiled from BT-Basic by using the
NOTE
compile command. However, only ITL can be compiled from the
development software.

Under no circumstances should you alter the length of the chain. You can
modify frame data as long as the modification does not alter the relative
position of the bits within the frame.
VCL files can be debugged using Pushbutton Debug. However, you must
compile the test with the debug option on (normally, this is not done
because of time and space limitations). To do this, type the following in a
BT- Basic window:
compile digital/<device_name>_connect.vcl;debug
When the file has been compiled, the test debug object will be created.
This digital test is in pattern capture format (PCF), and it is
well- commented so you can easily examine the test and determine what is
happening. Additionally, the contents of the test dictionary appear at the
end of the test as a comment. This information consists of the data to be
applied to the inputs of the device or the data expected from the outputs
of the device (input data is encoded as 1 or 0; expected output data is
encoded as H or L).
Accompanying each pattern set is the identification of the pin, node, and
boundary- register location associated with that data (the boundary- cell
number closest to TDO is 0, and increases as you approach TDI). In the
test itself, you will find frame and end frame statements. The data in

Boundary-Scan Testing 4-101

4 Testing Boundary-Scan Device Chains

between these two statements consists of the information shifted out from
the active, concatenated registers of the chain during one phase of the
test.
A chain location (listed in the test dictionary) corresponds to a location in
a particular frame. The relationship is determined as follows: A frame
consists of two vectors per cell (two clock edges are required to shift a
cell's contents out TDO). In each two- vector group, a comment that
identifies the cell number's position in the chain is placed to the right of
the vector that contains the expected data for that cell (the second vector
contains an X in this position).
The number of frames in a test equals the number of positions in the
signature contained in the test dictionary. The data from frame 1
represents the left- most position in the signature.
In most cases, the exact location of the first failing bit in a frame is
unavailable, because the entire signature must be assembled before failure
analysis is started. For this reason, it will often be necessary to use
debug's graphic display of vectors to search, vector by vector, for the first
occurrence of a bit failure.
If you cannot find the failure using the vector- by- vector search, you can
comment out the offending node(s) in the test source. For an example ITL
source file, refer to InterconnectPlus Test Language (ITL) on page 4- 104.

4-102 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Addressing Ground-Related Problems

If a device has a large number of outputs connected to testhead receivers,
and if all or most of those outputs transition at once, the receiver current
flowing into the testhead travels through a relatively small number of
ground returns. If these paths are long, the inductance associated with the
wiring can cause the ground references of the testhead and the device
under test to be at two different potentials during that short,
current- transition period. Because the testhead drivers are regulated with
respect to ground, this can result in an abrupt voltage level change that
can inadvertently drive device inputs. If one of the drivers is a clock
input, the device can go through an unwanted state change, which causes
the test to essentially run out of control and fail.
Boundary- scan connect tests are particularly susceptible to the problem
because, during one part of the test, all device outputs and bidirectional
pins transition together: first to 0 then to 1. The resulting
current- transition problem can occur exactly as described above because
connect test requires physical probes on all tested nodes. The change in
TAP state, which typically would occur on transition through UPDATE- DR,
would cause the test to fail. Subsequent tests would also fail because the
TAP would no longer follow the established testplan.
If you encounter this situation, one of the following solutions should solve
your problem.
• Examine the fixture's ground return scheme. For each device involved
in a connect test, the largest number of ground returns should be made
available. These grounds should be well distributed throughout the
modules used to test the device.
• Examine the board itself for sufficient ground paths and ground routing
schemes.
• Break the problem tests into smaller tests, each of which verifies a
percentage of the total nodes. You can do this by duplicating the
connect test source and removing all but the requisite number of nodes.
You can name the new sources as you wish, but they must be entered
into the testorder file as permanent tests so that the development
software will not remove them during future test generations.

Boundary-Scan Testing 4-103

4 Testing Boundary-Scan Device Chains

InterconnectPlus Test Language (ITL)

InterconnectPlus Test Language (ITL) is used in the intermediate files that
describe the high- level requirements for the boundary- scan tests for your
devices. The files are created by the development software. These files
contain the information that describes powered shorts, interconnect,
buswire, connect, and (optionally) Silicon Nails testing for your
boundary- scan devices.

In the past, Silicon Nails tests had to be written manually using ITL,
NOTE
then incorporated manually into your testplan. An optional product
automates this ITL generation from library tests. For more information,
refer to Automated Silicon Nails.

The following sections describe the ITL syntax and provide example files
that were used to produce the boundary- scan tests for the Sample
Boundary- Scan Device Chain.
• ITL Statement Descriptions and Syntax
• ITL Syntax Structure

ITL Statement Descriptions and Syntax

This section contains all the statements used by ITL, listed in alphabetical
order.
• New ITL Statements
• ITL Statements Borrowed from VCL

New ITL Statements

The statements listed in Table 4- 15 were created specifically for ITL. For
more information on the statements, refer to Syntax Reference.

Table 4-15 New ITL statements

Statement Description
buswire (ITL) The buswire statement declares the test type to be a buswire test. This extends
interconnect testing to examine each bussed driver to ensure connectivity and
operation.
chain (ITL) The chain statement marks the start of a chain block. The parameter following the
chain statement tells you which boundary-scan chain on the board (or which
target device for connect test) will be tested. The chain block contains the
description of the boundary-scan control signals, and provides the path names for
the software to retrieve the BSDL files for each device in the chain. For details on
this statement, see chain (ITL) in Syntax Reference.

4-104 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Table 4-15 New ITL statements

Statement Description
checkerboard (ITL) The checkerboard statement alters the connect test pattern set to be an
alternating pattern to reduce ground bounce and perhaps catch certain other
faults
connect (ITL) The connect statement declares the test type to be a connect test. This uses tester
nails to test to a single device in the scan chain.
custom (ITL) The custom statement declares the test type to be a custom test. This is a type of
interconnect test custom designed by the user. This test uses the MSPD interface
to create the test patterns.
debug (ITL) The debug statement declares the test to be one for debugging the boundary scan
chain. Normally, this is just used in test development and not in production.
devices (ITL) The devices statement marks the beginning of a devices block. The information in
this block provides the software with the descriptions of the devices in the chain,
and the path names to their BSDL files. For details on this statement, see devices
(ITL) in Syntax Reference.
disable (ITL) The disable statement declares the test to be one for disabling the boundary scan
devices in the targeted chain. This is normally done to allow testing of other digital
devices without bus conflicts.
disables (ITL) The disables statement (optional) marks the start of an optional disables block.
You can enter disable information if you know about disable needs for your test.
(This information might not be needed to develop your device test.) You do not
need to specify disable information for devices that can use boundary-scan
disabling. For details on this statement, see disables (ITL) in Syntax Reference.
end chain (ITL) The end chain statement marks the end of a chain block. Refer to the chains
statement for more information. For details on this statement, see end chain (ITL)
in Syntax Reference.
end devices (ITL) The end devices statement marks the end of a devices block. Refer to the devices
statement for more information. For details on this statement, see end devices
(ITL) in Syntax Reference.
end disables (ITL) The end disables statement marks the end of a disables block. Refer to the
disables statement for more information. For details on this statement, see end
disables (ITL) in Syntax Reference.
end nodes (ITL) The end nodes statement marks the end of a nodes block. Refer to the nodes
statement for more information. For details on this statement, see end nodes (ITL)
in Syntax Reference.

Boundary-Scan Testing 4-105

4 Testing Boundary-Scan Device Chains

Table 4-15 New ITL statements

Statement Description
end <test type> (ITL) The end <test type> statement marks the end of a test block. The <test type> can
be powered shorts, interconnect, buswire, connect, or custom. The <test type>
specified must match that specified to begin the block.
Refer to ITL Syntax Structure on page 4-108 for sample ITL files. For details on this
statement, see end <test type> (ITL) in Syntax Reference.
fixed (ITL) The fixed statement is used within a nodes block to declare fixed nodes. The fixed
statement includes the state of the node (high or low); if the state cannot be
determined, the statement is commented and the state is specified as unknown.
You need to edit the file to change the state to either high or low and uncomment
the statement. For details on this statement, see fixed (ITL) in Syntax Reference.
ground bounce The ground bounce suppression statement can be used to change the test flow at
suppression (ITL) either of the UPDATE states to reduce the potential for ground bounce to cause
failures. The statement is optional.
interconnect (ITL) The interconnect statement declares the test type to be an interconnection test of
the devices in the chain. This test only uses the TAP nodes, and disables, and
ignores nailed access to the interconnect nodes under test.
node (ITL) The node statement is used within a nodes or disables block to identify the node to
be tested or disabled. The node statement can be followed by a card list that tells
the system which type of resource to use to perform the test or disable task. For
details on this statement, see node (ITL) in Syntax Reference.
nodes (ITL) The nodes statement marks the beginning of a nodes block. This block can be
empty, but it must be present in every ITL source file (even if it is empty) to satisfy
the syntactic requirements of the parser.
For powered shorts tests, this block identifies the adjacency of the 100-percent
boundary-scan node (silicon node) to the nailed nodes of any other type. You
should notice in the ITL file for a powered shorts test that a silicon node entry is
followed by one or more node entries. For details on this statement, see nodes
(ITL) in Syntax Reference.
pcf order is nodes (ITL) The pcf order is nodes statement identifies the order in which a group of nodes will
be tested. This statement can appear within a nodes block or a disables block. For
details on this statement, see performance port in Syntax Reference.
powered shorts (ITL) The powered shorts statement declares the test type to be a test for shorts
between un-nailed boundary scan interconnect nodes and adjacent nailed nodes.
silicon nail (ITL) The silicon nail statement declares the test type to be a test of one or more
non-scan devices. The test can use a mixture of boundary scan resources (silicon
nails) or tester resources (regular nails). With early software, this test’s ITL file
had to be manually created; newer, optional software can automatically create this
file from a library test.

4-106 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Table 4-15 New ITL statements

Statement Description
silicon node (ITL) The silicon node statement is used within a nodes block to identify a
boundary-scan node to be tested via boundary-scan resources. This statement
typically appears in interconnect, buswire, powered shorts, or custom test blocks.
For details on this statement, see silicon node (ITL) in Syntax Reference.
tck (ITL) The tck statement identifies the test clock node of the boundary-scan chain. A
name is assigned to this node using the tck statement. For details on this
statement, see tck (ITL) in Syntax Reference.
tdi (ITL) The tdi statement identifies the test data in node of the boundary-scan chain. A
name is assigned to this node using the tdi statement. For details on this
statement, see tdi (ITL) in Syntax Reference.
tdo (ITL) The tdo statement identifies the test data out node of the boundary-scan chain. A
name is assigned to this node using the tdo statement. For details on this
statement, see tdo (ITL) in Syntax Reference.
test (ITL) The test statement is used within a nodes block in conjunction with the node
statement. The test statement identifies the node connections that will be tested.
For details on this statement, see test (ITL) in Syntax Reference.
test inputs only (ITL) The test inputs only statement is for optional usage in connect tests. It skips the
test frames that check outputs. It is intended for PLDs that have all pins defined as
bidirectional in BSDL, while the programmed function may be as an input only.
This creates unsolvable disable problems to IPG. The command makes the system
simply test the bidirectional in the input direction only and eliminates any bus
conflict problems. This is not suitable for a test containing output pins.
tms (ITL) The tms statement identifies the test mode select node of the boundary-scan
chain. A name is assigned to this node using the tms statement. For details on this
statement, see tms (ITL) in Syntax Reference.
trst (ITL) The trst statement identifies the test reset node of the boundary-scan chain (if one
exists). A name is assigned to this node using the trst statement. For details on
this statement, see trst (ITL) in Syntax Reference.

Boundary-Scan Testing 4-107

4 Testing Boundary-Scan Device Chains

ITL Statements Borrowed from VCL

The following statements were borrowed from VCL for use in ITL. These
statements behave similarly to VCL. The detailed descriptions for these
statements can be found in Syntax Reference.
• unit
• end unit
• pcf
• end pcf
• repeat
• end repeat
• inputs
• outputs
• bidirectional
• pcf order is nodes

ITL Syntax Structure

This section describes the structure for the InterconnectPlus Test Language
(ITL) and provides sample ITL source files for the Sample Boundary- Scan
Device Chain.
• General Structure of ITL
• ITL Source File for Powered Shorts Test
• ITL Source File for Interconnect Test
• ITL Source File for Buswire Test
• ITL Source File for Connect Test
• ITL Source File for Silicon Nails Test

4-108 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

General Structure of ITL

In the ITL structure below, parameters are shown in brackets < >.

Example 4-17 ITL Structure

<test type> <chain/device description> ! marks the start of a test block
<test type> can be: powered shorts
interconnect
buswire
connect
silicon nail
custom
<chain/device description> is a <string expression>
chain <chain description> ! marks the start of a chain block
tdi <signal description> <card list>
tdo <signal description> <card list>
tms <signal description> <card list>
tck <signal description> <card list>
trst <signal description> <card list>
<signal description> is a <string expression>
<card list> can be: channel ! "," indicates equal card preference
hybrid ! ";" indicates first choice preferred
channel, hybrid ! over second, but second may be
hybrid; channel ! used.
devices
<device description>,<BSDL pathname>,<package name>, <compliance problem>
<device description>,<BSDL pathname>,<package name>, <compliance problem>
<device description>,<BSDL pathname>,<package name>, <compliance problem>
. . .
<device description> is a <string expression>
<BSDL pathname> is a <string expression>
<package name> is a <string expression>
<compliance problem> can be: yes or no
end devices
end chain ! marks the end of a chain block
disables ! marks the start of a disables block
node <node name> <card list> default <state>
<node name> is a <string expression>
<state> can be: 0, 1, k, t
pcf order is nodes <node name>, <node name>,...<node name>
unit <unit name> ! marks the start of a unit block
<unit name> is a <string expression>
pcf ! marks the start of a pcf block
<drive vector>
<drive vector> is a <string expression>
end pcf ! marks the end of a pcf block
end unit ! marks the end of a unit block
end disables ! marks the end of a disables block
driver limit <integer> ! used with powered shorts test only
nodes ! marks the start of a nodes block
node <node name> test <device.pin>, <device.pin>,...<device.pin>

Boundary-Scan Testing 4-109

4 Testing Boundary-Scan Device Chains

node <node name> <card list> test <device.pin>, <device.pin>,...<device.pin>

silicon node <node name> test <device.pin>, <device.pin>,...<device.pin>
silicon node <node name> <card list> test <device.pin>,...<device.pin>
<device.pin> is a <string expression>
inputs <node name>, <node name>,...<node name>
outputs <node name>, <node name>,...<node name>
bidirectionals <node name>, <node name>,...<node name>
pcf order is nodes <node name>, <node name>,...<node name>
<node name> is a <string expression>
unit <unit name>
pcf
<drive vector>
end pcf
end unit
end nodes ! marks the end of a nodes block
end <test type> ! marks the end of a test block

4-110 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

ITL Source File for Powered Shorts Test

Note that the information in the nodes section describes the nodal
adjacency of the un- nailed boundary- scan nodes (silicon nodes) and the
conventional nailed nodes. These nodes do not appear to be adjacent when
you look at the schematic, however, they are physically adjacent in the
actual circuit.

Example 4-18 ITL source file for a powered shorts test

powered shorts "u1_u4_ps"
chain "u1_u4"
tdi "TDI"
tdo "TDO"
tms "TMS"
tck "TCK"
devices
"u1", "custom/74bct8374", "DW_PACKAGE", no
"u2", "custom/74bct8374", "DW_PACKAGE", no
"u3", "custom/74bct8374", "DW_PACKAGE", no
"u4", "custom/74bct8374", "DW_PACKAGE", no
end devices
end chain
disables
node "IN_26" hybrid default "1"
node "IN_28" hybrid default "1"
pcf order is nodes "IN_26","IN_28"
unit "disable"
pcf
"11"
end pcf
end unit
end disables
nodes
silicon node "U1_2" test "u1.2","u2.23"
node "IN_05" test "u1.1" ! (100 mils from u1.2)
node "IN_04" test "u2.24" ! (100 mils from u2.23)
silicon node "U1_3" test "u1.3","u2.22"
silicon node "U1_4" test "u1.4","u2.21"
silicon node "U1_5" test "u1.5","u2.20","u4.20"
silicon node "U1_U3_7" test "u1.7","u2.19","u3.7","u4.19"
silicon node "U1_U3_8" test "u1.8","u2.17","u3.8","u4.17"
silicon node "U1_U3_9" test "u1.9","u2.16","u3.9","u4.16"
silicon node "U1_U3_10" test "u1.10","u2.15","u3.10","u4.15"
!Untestable (Inaccessible): U3_TDO, u3.11 (near u3.10)
!Untestable (Inaccessible): U1_TDO, u1.11 (near u1.10)
!Untestable (Inaccessible): U3_TDO, u4.14 (near u4.15)
!Untestable (Inaccessible): U1_TDO, u2.14 (near u2.15)
silicon node "U3_2" test "u3.2","u4.23"
node "IN_25" test "u5.9" ! (100 mils from u5.8)
node "IN_18" test "u3.1" ! (100 mils from u3.2)
node "IN_17" test "u4.24" ! (100 mils from u4.23)

Boundary-Scan Testing 4-111

4 Testing Boundary-Scan Device Chains

silicon node "U3_3" test "u3.3","u4.22"

!Untestable (Disable): IN_26, u5.10 (near u5.11)
node "IN_27" test "u5.12" ! (100 mils from u5.11)
silicon node "U3_4" test "u3.4","u4.21"
end nodes
end powered shorts

ITL Source File for Interconnect Test

Example 4-19 ITL source file is for u1_u4 interconnect test

interconnect"u1_u4"
chain "u1_u4"
tdi "TDI"
tdo "TDO"
tms "TMS"
tck "TCK"
devices
"u1", "../demo_original/custom/74bct8374", "DW_PACKAGE", no
"u2", "../demo_original/custom/74bct8374", "DW_PACKAGE", no
"u3", "../demo_original/custom/74bct8374", "DW_PACKAGE", no
"u4", "../demo_original/custom/74bct8374", "DW_PACKAGE", no
end devices
end chain
disables
node "IN_26" hybrid
node "IN_28" hybrid
pcf order is nodes "IN_26","IN_28"
unit "disable"
pcf
"11"
end pcf
end unit
end disables
nodes
silicon node "U1_2" test "u1.2","u2.23"
silicon node "U1_3" test "u1.3","u2.22"
silicon node "U1_4" test "u1.4","u2.21"
silicon node "U1_5" test "u1.5","u2.20","u4.20"
silicon node "U1_U3_7" test "u1.7","u2.19","u3.7","u4.19"
silicon node "U1_U3_8" test "u1.8","u2.17","u3.8","u4.17"
silicon node "U1_U3_9" test "u1.9","u2.16","u3.9","u4.16"
silicon node "U1_U3_10" test "u1.10","u2.15","u3.10","u4.15"
silicon node "U3_2" test "u3.2","u4.23"
silicon node "U3_3" test "u3.3","u4.22"
silicon node "U3_4" test "u3.4","u4.21"
end nodes
end interconnect

4-112 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

ITL Source File for Buswire Test

Example 4-20 ITL source file for u1_u4 buswire test

buswire"u1_u4_bus"
chain "u1_u4"
tdi "TDI"
tdo "TDO"
tms "TMS"
tck "TCK"
devices
"u1", "../demo_original/custom/74bct8374", "DW_PACKAGE", no
"u2", "../demo_original/custom/74bct8374", "DW_PACKAGE", no
"u3", "../demo_original/custom/74bct8374", "DW_PACKAGE", no
"u4", "../demo_original/custom/74bct8374", "DW_PACKAGE", no
end devices
end chain
nodes
silicon node "U1_U3_7" test "u1.7","u2.19","u3.7","u4.19"
silicon node "U1_U3_8" test "u1.8","u2.17","u3.8","u4.17"
silicon node "U1_U3_9" test "u1.9","u2.16","u3.9","u4.16"
silicon node "U1_U3_10" test "u1.10","u2.15","u3.10","u4.15"
end nodes
end buswire

Boundary-Scan Testing 4-113

4 Testing Boundary-Scan Device Chains

ITL Source File for Connect Test

The following ITL source file is for one connect test, u2, of the u1_u4
chain. Connect test ITL source files for the other devices (u1, u3, and u4)
are similar.

Example 4-21 ITL source file is for one connect test, u2, of the u1_u4 chain
connect "u2"
chain "u1_u4"
tdi "TDI"
tdo "TDO"
tms "TMS"
tck "TCK"
devices
"u1", "../demo_original/custom/74bct8374", "DW_PACKAGE", no
"u2", "../demo_original/custom/74bct8374", "DW_PACKAGE", no
"u3", "../demo_original/custom/74bct8374", "DW_PACKAGE", no
"u4", "../demo_original/custom/74bct8374", "DW_PACKAGE", no
end devices
end chain
nodes
node "IN_04" hybrid test "u2.24"
node "IN_05" hybrid test "u2.1"
node "OUT_04" hybrid test "u2.4"
node "OUT_05" hybrid test "u2.3"
node "OUT_06" hybrid test "u2.2"
end nodes
!IPG: Inaccessible nodes
!IPG: node "U2_5"
!IPG: node "U2_7"
!IPG: node "U2_8"
!IPG: node "U2_9"
!IPG: node "U2_10"
!IPG: node "U1_U3_10"
!IPG: node "U1_U3_9"
!IPG: node "U1_U3_8"
!IPG: node "U1_U3_7"
!IPG: node "U1_5"
!IPG: node "U1_4"
!IPG: node "U1_3"
!IPG: node "U1_2"
end connect

4-114 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

ITL Source File for Silicon Nails Test

The following ITL source file is for a Silicon Nails test for device u6. The
test vector section (Element number 1 through Element number 4 in the
example) of Silicon Nails tests are written automatically.

Example 4-22 ITL Source File for Silicon Nails Test

silicon nail "u6"
chain "chain_demo"
tdi "TDI"
tdo "TDO"
tms "TMS"
tck "TCK"
devices
"u1", "../demo_original/custom/74bct8374", "DW_PACKAGE", no
"u2", "../demo_original/custom/74bct8374", "DW_PACKAGE", no
"u3", "../demo_original/custom/74bct8374", "DW_PACKAGE", no
"u4", "../demo_original/custom/74bct8374", "DW_PACKAGE", no
end devices
end chain
nodes
node "IN_01" test "U6.1"
node "IN_02" test "U6.2"
silicon node "U6_3" test "U1.15", "U6.3"
silicon node "U4_10" test "U4.10", "U6.4"
silicon node "U2_10" test "U2.10", "U6.5"
node "OUT_01" test "U6.6"
node "OUT_02" test "U6.8"
silicon node "U2_9" test "U2.9", "U6.9"
silicon node "U2_8" test "U2.8", "U6.10"
node "OUT_03" test "U6.11"
silicon node "U2_7" test "U2.7", "U6.12"
silicon node "U2_5" test "U2.5", "U6.13"
inputs "IN_01", "IN_02", "U4_10", "U2_10", "U2_9", "U2_8"
inputs "U2_7", "U2_5"
outputs "U6_3", "OUT_01", "OUT_02", "OUT_03"
pcf order is nodes "IN_01", "IN_02", "U4_10", "U2_10", "U2_9"
pcf order is nodes "U2_8", "U2_7", "U2_5", "U6_3", "OUT_01"
pcf order is nodes "OUT_02", "OUT_03"

This is the setup-only vector added for Silicon Nails Automation.

unit "Test"
pcf
! unit Element number 1
"11ZZZZZZLXXX"
"01ZZZZZZHXXX"
"00ZZZZZZHXXX"
"10ZZZZZZHXXX"
!end unit
! unit Element number 2
"ZZ11ZZZZXLXX"

Boundary-Scan Testing 4-115

4 Testing Boundary-Scan Device Chains

"ZZ01ZZZZXHXX"
"ZZ00ZZZZXHXX"
"ZZ10ZZZZXHXX"
!end unit
! unit Element number 3
"ZZZZ11ZZXXLX"
"ZZZZ01ZZXXHX"
"ZZZZ00ZZXXHX"
"ZZZZ10ZZXXHX"
!end unit
! unit Element number 4
"ZZZZZZ11XXXL"
"ZZZZZZ01XXXH"
"ZZZZZZ00XXXH"
"ZZZZZZ10XXXH"
!end unit
end pcf
end unit
end nodes
end silicon nail

4-116 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

VCL/ITL Pass-Thru Statements

Certain VCL statements can be specified in the Interconnect Test Language
(ITL). The statements are not used by the ITL compiler for test generation
algorithmic control. Rather, these pass- thru statements are VCL statements
that are allowed in the ITL code to allow information to pass directly into
VCL without being changed by the ITL compiler (MSPD). These statements
can be automatically placed by the test generation process. They may also
be entered manually. The ITL compiler (MSPD) has been modified to
handle these new commands.
The statements are briefly described in Table 4- 16. For complete
information on each statement, see Syntax Reference.

Table 4-16 Pass-thru statements

Statement Description
disabled device (VCL) The program generator places disabled device statements in the Declaration
(ITL) section of an executable test to indicate which devices are disabled while the test
is executed. For details on this statement, see disabled device (VCL) (ITL) in
Syntax Reference.
conditioned device (VCL) The program generator places conditioned device statements in the Declaration
(ITL) section of a test to indicate which devices are conditioned while the test runs.
They are used by the Agilent SAFEGUARD analysis routines to determine the safe
time that the test can run.
If you change the conditioning vectors in the executable test so that the
conditioned output states are changed, you should modify the associated
conditioned device function accordingly and recompile the test. For details on this
statement, see conditioned device (VCL) (ITL) in Syntax Reference.
vector cycle (VCL) (ITL) The vector cycle statement appears in the Declaration section of the test to
establish the vector cycle time; that is, the time between starting each vector.
Once established, the cycle time remains the same for all vectors throughout the
VCL test. The vector cycle function is not used in tests that have timing sets. For
details on this statement, see vector cycle (VCL) (ITL) in Syntax Reference.
receive delay (VCL) (ITL) The receive delay statement appears in the Declaration section of the test to
establish the delay time between driving a pattern of bits to the device or circuit
under test (i.e., starting a vector) and receiving (examining) the response from that
device or circuit. For details on this statement, see receive delay (VCL) (ITL) in
Syntax Reference.
set load (VCL) (ITL) The set load statement is optional; you can use it in the Declaration section of a
VCL test to change the pull-up or pull-down loads on the receiver nodes (nodes
with outputs and bidirectionals from the board under test). For details on this
statement, see set load (VCL) (ITL) in Syntax Reference.

Boundary-Scan Testing 4-117

4 Testing Boundary-Scan Device Chains

Table 4-16 Pass-thru statements

Statement Description
set ref (VCL) (ITL) The set ref statement is optional; you can use it in the Declaration section of a VCL
test to setup the digital driver and receiver high and low voltages on individual
nodes. For details on this statement, see set ref (VCL) (ITL) in Syntax Reference.
set terminators (VCL) The set terminators statement connects the RC networks in the receiver circuits
(ITL) on Hybrid pin cards. It can be used to enhance high-speed signal quality. The
statement can connect terminators (on in the syntax) or disconnect them (off). For
details on this statement, see set terminators (VCL) (ITL) in Syntax Reference.
warning (VCL) (ITL) The warning statement allows you to place warning messages in the test. The
messages will then appear in the summary report generated by program
generators, and in the compile listings for the test. Typically messages would
include reminders to adapt the test in some way to suit a device in a special
configuration.
The warning function can appear in the pass through part of the ITL test. In a
silicon nail test, it can also appear just after the pcf order is statement or
anywhere within the pcf vector block. For details on this statement, see warning
(VCL) (ITL) in Syntax Reference.
on failure report (VCL) The on failure report function enables you to specify a message that will be sent to
(ITL) the report is printer if the test fails. This message will be sent in addition to the
standard messages generated when a test fails.
The on failure report function can appear in the pass through part of the ITL test.
In a silicon nail test, it can also appear just after the pcf order is statement. For
details on this statement, see on failure report (VCL) (ITL) in Syntax Reference.

4-118 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

VCL Source Code For Chain Tests

Because an actual VCL source code for even a small boundary- scan chain
would be quite long, we will discuss only the differences between the
source code for a single device and that for a chain of devices. Sample
sections are provided to show what the code can look like.
The statements associated with chain testing are:
• scan powered shorts
• scan interconnect
• scan bus interconnect
• scan silicon nail
• scan debug
• scan connect
• inputs collapsed
• inputs scan clock
• inputs scan mode
• inputs scan reset
• inputs scan
• outputs scan
• general message
• frame
• end frame
The scan powered shorts, scan interconnect, scan bus interconnect, scan
connect, and scan silicon nail statements appear in the Declaration section
of a VCL test and specify a boundary- scan test type.
The inputs collapsed statement appears in the Declaration of a VCL test. It
describes a group of nodes, assigned to a single column, that will be tested
during a series of iterations for shorts testing.
The inputs scan clock, inputs scan mode, inputs scan reset, inputs scan,
and outputs scan statements appear in the Declaration section of a VCL
test. They identify particular boundary- scan resources needed to test
boundary- scan devices. These resources are commonly called TCK, TMS,
TRST, TDI, and TDO.
The message statement allows you to include custom messages that will be
output if the related vectors fail. Messages continue and are associated
with all subsequent vectors until a new (or show a null) message
statement is encountered.
The frame statement identifies the beginning of a block of pcf vectors used
in testing boundary- scan devices. The binary values of each vector are
shifted into the boundary- scan device via the Test Data In (TDI) port.
When the frame bits have been captured by chain receivers, they are
shifted out and stored in deep- capture RAM until all frames have been
executed. The bits are then reassembled into signatures and compared to

Boundary-Scan Testing 4-119

4 Testing Boundary-Scan Device Chains

determine if a node passes or fails a test. Every frame statement must

have an accompanying end frame statement. Every frame in a test must
also be the same length.
Appended to the end of the source code is a commented form of the test
dictionary that provides the frame and device cell correlation, node and
device.pin identification, and the expected signature for the node
identified.
For more detailed information about these statements, refer to Syntax
Reference.
Items that appear in the following partial example (Example 4- 23), the
VCL source file shows where each of these statements and the commented
form of the test dictionary would appear in an actual file.

Example 4-23 VCL source file

!!!! 6 0 1 698520684 Ve2f1
! IEEE Std 1149.1-1990, BSDL (Version 0.0)
! Test Specification Source: digital/u4_connect
! VCL created for chain: CHAIN_U4
! Date: Wed Feb 19 10:31:27 1992
! Chain Composition (TDI to TDO)
! Device Entity Package BSDL File
! --------- ----------- ----------- -----------------
! U4 TTL74BCT8374 DW_PACKAGE
/users/bscan/demo_original/custom/74bct8374
scan connect ! Test device U4 ... this could be scan powered shorts,
! scan interconnect, scan bus interconnect, or scan silicon nails
vector cycle 200n
receive delay 100n
default device "U4"
assign N000 to nodes "IN_17"
assign N001 to nodes "IN_18"
assign N002 to nodes "OUT_09"
assign N003 to nodes "OUT_10"
assign TCK to nodes "TCK"
assign TDI to nodes "TDI"
assign TDO to nodes "TDO"
assign TMS to nodes "TMS"
family TTL !! Warning, Defaulted family
inputs scan clock TCK
inputs scan mode TMS
inputs scan TDI
outputs scan TDO
inputs N000, N001
outputs N002, N003
use cards hybrid on N000, N001, N002, N003
pcf order default Scan is TCK, TMS, TDI, TDO
pcf order Parallel is TCK, TMS, TDI, TDO , N000, N001, N002, N003
!Column-to-Node Map, Nodes 1 to 8

4-120 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

!TTTTIIOO!
!CMDDNNUU!
!KSIO__TT!
! 11__!
! 7801!
! 90!
! !
unit "Connect Test" ! Vector 1
pcf
use pcf order Parallel
"01ZXZZXX"
use pcf order Scan
"11ZX"
. . .
"00ZX"
"10ZX"!Shift-IR
end pcf
message "IEEE Std 1149.1-1990 Integrity Failure"
message " Device U4 has failed,"
. . .
compress
frame 0 1
pcf
use pcf order Parallel
"00ZXZZXX"!0+0
use pcf order Scan
"10ZX"
"00ZX"!1
"10ZX"
"00ZX"!2
. . .
"101X"
"01ZL"!17
"11ZX"!Exit1-DR
end pcf
end frame
end compress
message " " ! example of a null message
. . .
! End of Connect Test for device U4
use pcf order Scan
"01ZX"
"11ZX"!Select-IR-Scan
use pcf order Parallel
"01ZXZZXX"
use pcf order Scan
"11ZX"!Test-Logic-Reset
end pcf
end unit ! Connect Test Vector 330
! Vectors with TDI High: 32, 6.4 microseconds
! Vectors with TDI Low: 40, 8.0 microseconds
! Total Vectors : 330, 66.0 microseconds

Boundary-Scan Testing 4-121

4 Testing Boundary-Scan Device Chains

! Connect Test Dictionary

! Frame Size 18
! FrCell DevCell Dev.Pin Node Signature
! 16 16 U4.24 IN_17 'LHXX'
! 17 17 U4.1 IN_18 'LHXX'

4-122 Boundary-Scan Testing

 Testing Boundary-Scan Device Chains 4

Sample Boundary-Scan Device Chain

Click here to see the sample circuit referred to in the examples in this
chapter.

Boundary-Scan Testing 4-123

4 Testing Boundary-Scan Device Chains

4-124 Boundary-Scan Testing