Bscan 05

5
In this chapter...
Agilent Technologies 2002, 2003
Testing Boundary-Scan Device Chains
Overview, 5-2
Introduction To Testing Device Chains, 5-3
InterconnectPlus, 5-18
Generating Tests For Boundary-Scan Chains, 5-53
Results Analysis Routine, 5-112
Debugging Boundary-Scan Tests, 5-120
Silicon Nails Automation, 5-128
InterconnectPlus Test Language (ITL), 5-158
VCL/ITL Pass-Thru Statements, 5-176
VCL Source Code For Chain Tests, 5-179
Summary: Sample Test Generation Session, 5-184
Sample Boundary-Scan Device Chain, 5-187
Boundary-Scan Guide
06/2003
5-1
Chapter 5: Testing Boundary-Scan Device Chains
NOTE
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 the advanced feature of
Agilent Boundary-Scan software,
Agilent InterconnectPlus, accomplishes this task. The
software develops and executes powered shorts, TAP
integrity, 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. All of this is created
automatically when you specify your boundary-scan
devices during the normal test development process.
We suggest that you refresh your understanding of the
basic concepts of IEEE Standard 1149.1 (Chapter 1) and
Boundary-Scan Description Language (BSDL,
Chapter 2) before you read this chapter. You also need
to understand Vector Control Language (VCL) and the
general, board test generation process. The latter two
topics are described in the users' documentations; refer
to the Master Index for particular references.
Boundary-Scan Guide
This chapter describes InterconnectPlus, which is

the optional, advanced boundary-scan product for
the 3070 Series II of board test systems. For this
product to work, you must set the enable
statement in your board configuration file to turn
on advanced boundary-scan. For more
information about the enable statement, refer to
the Syntax Reference documentations.
Several sections in this chapter refer you to a sample
circuit when examples are provided for each topic. The
circuit uses a chain of the same Texas Instruments
device, (74bct8374 Octal) that we have used as an
example in the earlier chapters of this documentation.
You can refer back to earlier chapters for examples of
VCL source code and the BSDL file for the device. Note
that this source code and BSDL file apply to single
devices only.
5-2
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 as shown in Figure 5-1.
Figure 5-1
A simple boundary-scan chain
u2
u1
TAP
TDI
TDO
TDI
TAP
u6
TDO
TMS
TCK
TDI
TAP
u7
u4
u3
TDO
TDI
TAP
TDO
u5
Boundary-Scan Guide
5-3
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.
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.
devices in the chain have common TCK and TMS lines

(TRST is optional for each device in the chain).
This chapter explores the practical application of testing

boundary-scan chains, and describes the process for
developing an optimum test strategy for your board.
Understand that 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 access be provided whenever possible to ensure
maximum fault coverage. For guidance on evaluating
when to remove probes, refer to Removing Physical
Probes on page 5-104.
While fault 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:
Boundary-Scan Guide
5-4
Figure 5-2
Example of a chain of boundary-scan devices
u1
u2
u3
TDO
TDI
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.
example, Table 5-1 shows what the register lengths for

the devices in Figure 5-2 could be.
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
Device
Instruction
Register Length
Boundary
Register Length
u1
6 bits
24 cells
u2
6 bits
24 cells
u3
10 bits
30 cells
Boundary-Scan Guide
Table 5-1
Example register lengths
5-5
Table 5-1
Example register lengths (continued)
Device
Instruction
Register Length
Boundary
Register Length
Register
length for
entire chain
22 bits
78 cells
Table 5-2
Table 5-2 shows what the concatenated EXTEST

instructions for this chain might be.
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 listed in Table 5-2, you see in Figure 5-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: 24 cells +
u2/u3 Bypass Registers: 1 cell each). Shifting in a new
set of instructions can change the active registers and
therefore the length of the chain's Data Register.
Boundary-Scan Guide
5-6
Figure 5-3
Devices loaded with different instructions

EXTEST
u1
TDI
BYPASS
u2
BYPASS
u3
TDO
TCK
TMS
TRST
From this you can see that the length of the Instruction
Register for the chain is fixed: 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: 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
Boundary-Scan Guide
BSDL file tells the software the length of the registers

targeted for each instruction.
Keeping TAP-only Devices in the Chain
A TAP-only device is 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
5-7
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 5-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 Your
Boundary-Scan Device on page 5-55.
Boundary-Scan Guide
5-8
Figure 5-4
Keeping TAP-only devices in the chain prevents having to break chains

u3
TAP
Only
u4
u5
u2
u1
TD1
TAP Override Form

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 treats boundary-scan devices
on opposite sides of such a split signal as separate
Boundary-Scan Guide
u6
TDO
chains. For example, Figure 5-5 shows a circuit where

the TMS and TCK lines have buffers. InterconnectPlus
software sees two distinct chains: a chain consisting of
U1 and U2, and a chain consisting of U3, U4, and U5.
5-9
Figure 5-5
A single boundary-scan chain split into two chains
As of software version B.03.00, there is a TAP Override

Form (Figure 5-5) that 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. You can use this ability to
override nodes so that InterconnectPlus software will
see devices with logically equivalent TAP signal nodes
as a single chain. You would enter data in the TAP
Override Form as Figure 5-5 show for devices U3, U4,
and U5 to accommodate the chain Figure 5-4 shows.
Figure 5-6
TAP Override Form
You invoke the TAP Override Form from a button on the

Device Entry Form (Figure 5-6).
Boundary-Scan Guide
5-10
The TAP Override Form allows you to override any

TAP signal node for any device being tested with
InterconnectPlus. However, you generally should not
change the TDI node for any device but the first one in a
chain, and you generally should not 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 of Figure 5-7, but not allowed between U1 and
U2 or U3 and U4.
Boundary-Scan Guide
Figure 5-7
TAP signal overrides button: device entry form
5-11
Figure 5-8
TDI or TDO override allowed between U2 and U3
The TAP Override Form cannot be used to work around

pad bits in boundary-scan linkers, and you should refer
to section Using Chain Override on page 5-12 for
details on handling such situations.
Using Chain Override
Multiple TMS and TCK connections, as Figure 5-9
shows, makes the software treat the board as if it had
two chains. If you intend for 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, as shown in section 5.1.1.3, providing a physical
connection. Software revision B.02.00, or later, allows
you to override the board compilers view of the chain
construction.
Boundary-Scan Guide
5-12
Figure 5-9
Multiple TMS/TCK lines cause multiple chains
u1
TDI
TCK
u2
u3
TDO
TCK1
TMS1
TRST
TMS
TCK2
TMS2
When you run IPG Test Consultant, you might discover

that there are more tests generated than you have chains
existing on the board. This fact would show up in the
IPG summary or in digital directories. With software
revision B.02.00, or later, 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 turning Boundary-Scan Chain Override ON. This is
accomplished by turning on a flag in the board global
options section. (See Testing Boundary-Scan Device
Boundary-Scan Guide
Chains on page 5-1.). This flag can only be turned on

for revision B (Series II) systems.
Figure 5-10 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,
which is the case, unless you refer back to the inputs of
buffers A and B. By overriding, you tell the software
that there is only one chain.
5-13
Figure 5-10
Logical chain that will be treated as two chains. (A candidate for chain override.)
TDO_TDI
TDI
U1
TCK
TDO
U2
TCK1
A
TCK2
TMS1
TMS
TMS2
Consider an example where the testability report shows

two chains on a board as Figure 5-10 shows:
BOUNDARY SCAN CHAINS
U1_U1
TDI TDI
TDO TDO_TDI
TCK TCK1
TMS TMS1
DEVICES
u1;
u2_u2
TDI TDO_TDI
Boundary-Scan Guide
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, you first edit the global
section of the board file to add the statement
5-14
Boundary Scan Chain Override ON
to the global flag section. 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 itself.
You must then go to the board file and edit in the chain
Example 5-1
Edited chain

! 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
Turning Two Interconnected Chains into One Chain

When the devices in two different chains are
interconnected as shown in Figure 5 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.
descriptions (at the end of the file) that describe the

actual chain construction. The edited chain looks like
Example 5-1, with comments added to describe the
syntax.
Boundary-Scan Guide
name>
TMS TMS
! TMS <node
name>
DEVICES
devices in the chain
u1, u2;
nearest TDI
! now name
! first device
! last device
nearest TDO, ";" terminated
NOTE
For more information about using GP relays, refer
to the Cards in the Testhead documentation, and
Development3.
5-15
Figure 5-11
Connecting jumpers or GP relays to make alarger chain

C ha in 2
C ha in 1
u2
u1
u2
u1
TDI
TDI
u3
u4
u3
TDO
u4
TDO
You should not jumper non-compliant devices as shown

in Figure 5-12 solely for the purpose of making a larger
chain. This can result in overdriving difficulties, or other
testing problems.
Boundary-Scan Guide
5-16
Figure 5-12
Connecting a jumper to make a longer chain around non-compliant devices is not recommended
u10
u11
TDI
N.C.
u13
u20
u21
TDO
The dotted line shown above represents a jumper used

to circumvent the non-compliant (NC) device, u13. This
might seem like a reasonable solution, however, a closer
study reveals 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, it would be better to 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.
Boundary-Scan Guide
5-17
Table 5-3
InterconnectPlus
Chain Testing
InterconnectPlus software's chain testing comprises
powered shorts, TAP integrity, interconnect, buswire,
connect tests, and the ability to do Silicon Nails1 testing.
Through the use of the IEEE 1149.1-1990 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 testhead access is
provided.
Sequence
Table 5-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 5-3
Type
Method
TAP Integrity Test
Boundary-Scan
Automatic
Powered Shorts Test
Boundary-Scan
Automatic
Interconnect Test
Boundary-Scan
Automatic
Buswire Test
Boundary-Scan
Automatic
Connect Test
Boundary-Scan
Automatic
Digital In-circuit Test
Conventional
Automatic
Silicon Nails Test
Boundary-Scan
Interactive
Power Applied to Board
Power Removed from Board, then Re-applied

BIST, INTEST, User
Functions
Boundary-Scan
Interactive
Board test sequence showing position of

boundary-scan tests
Sequence
Type
Method
Board Test Sequence -- Unpowered
Board test sequence showing position of

boundary-scan tests (continued)
Shorts Tests
Conventional
Automatic
Analog In-circuit Tests
Conventional
Automatic
Boundary-Scan Guide
Shorts and analog in-circuit tests are described in detail

in the Test Methods: Analog documentation. Executing
these tests should identify the majority of shorts that
occur across physically accessed nodes, which
minimizes potential damage to your board.
5-18
Digital in-circuit tests are described in detail in the Test

Methods: Digital documentation. BIST and INTEST
are described in chapter 1 of this documentation. Silicon
Nail test theory is discussed later in this chapter.
The primary purpose of this section is to examine the
following tests:
Powered Shorts TestTests 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.
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.
NOTE
The exceptions are power and ground nodes,
disable nodes, and TAP nodes. Shorts to power or
ground are detected by interconnect test. Most
shorts to TAP nodes are detected by integrity test
TAP Integrity TestVerifies that the Test Access

Port (TAP) of all the boundary-scan devices in the
Boundary-Scan Guide
chain operate properly. If this test fails, testing

stops, and power is removed from the board. This
test is a preamble to all other boundary-scan tests:
it is an integral part of each test and is executed
before each test runs.
Interconnect TestTests 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).
NOTE
If device disabling or conditioning is necessary
for other devices on the board, additional drivers
might be required.
5-19
One interconnect test is generated for each

boundary-scan chain on the board. This test
verifies the connections between devices in the
same chain only.
Buswire TestCreated when bussed drivers are

present in the chain.
Under certain circumstances, interconnect test
must be executed with multiple device outputs
driving test patterns onto the same (bussed) node.
If one of the drivers was disconnected from the
node, it would go undetected. Interconnect test
could also be executed with two or more drivers
connected to one node, but with only one driver
enabled. For these reasons, 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 larger devices that exceed the available

number of testhead resourcesfor example,
testing a 300-pin ASIC when only 200 resources
are availableyou can (manually) split the
connect test into two or more smaller tests.
Connect TestTests for opens on each device,

one at a time (u1, . . . uy), until the entire chain has
been tested. 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
one or more I/O pins accessible from the testhead.
Boundary-Scan Guide
Connect test verifies the operation of bidirectional

pins by generating separate vectors to check their
operation as drivers, then as receivers.
InterconnectPlus Test Files

Each of these tests has five files of which you should be
aware.
InterconnectPlus Test Language (ITL) source

fileA permanent, intermediate file input to the
MSPD serializer that contains, essentially the
boundary-scan test source code generated by IPG
using the InterconnectPlus software.
Vector Control Language (VCL) source fileA

permanent, intermediate file created by the MSPD
Serializer that contains the device test; it is an
input to the VCL compiler.
Test dictionary (.x) fileA permanent 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.
5-20
Test requirements (.r) fileA temporary file

generated by the VCL compiler to identify
testhead resources needed for the test.
Test object (.o) fileThe compiled VCL file

(non-editable).
are mounted closely together. Also mounted closely to

these devices are several SMT analog devices.
Complete X-Y data would tell the 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.
All of these files are located in the board's digital

directory. Each of these files is 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 5-13 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
Boundary-Scan Guide
5-21
Figure 5-13
Circuit Board with Tight-Pack Design
Shorts that can occur between physically adjacent devices

are automatically accounted for if complete XY data
is provided.
Powered Shorts Test

Figure 5-14 illustrates connections between two devices
for which a powered shorts test would be generated.
Remember that this test is created automatically, and in
most cases will work without debug.
Boundary-Scan Guide
The information in this section is provided for

background.
5-22
Figure 5-14
Powered shorts Ttest checks for shorts between unnailed boundary-scan nodes and any other nailed node
VCC
IN_17
IN_18
VCC
1
u3
24
U3_3
U3_2
*Potential Short
*Potential Short
9
10
12
1
24
22
u4
23
*Potential Short
8
u5
11
13
*Potential Short
Note that the pin numbers were added to this drawing to

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.
Boundary-Scan Guide
*Nodes are physically adjacent on actual board.
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 parameters for
5-23
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, IPG analyzes it and
looks for un-nailed boundary-scan nodes. It then
examines the X-Y data for powered shorts situations to
adjacent nodes. IPG then writes the ITL for the powered
shorts test.
information in this section is provided for background.

This test 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 test 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.
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.
TAP Integrity Test

Figure 5-15 illustrates the boundary-scan TAP integrity
test. Remember that this test is created automatically,
and in most cases will work without debug. The
Boundary-Scan Guide
5-24
Figure 5-15
Boundary-scan TAP Integrity Test checks the TAP of each device
u1
u2
TDI
u4
u3
TDO
Integrity test looks for the basic integrity of the devices'

TAP controllers and the boundary-scan chain. Examples
of problems that could be encountered include:
a wrong device was loaded
one of the TDI or TDO connections is bad (for

example, an open between u3 and u4)
one of the devices is bad: simply does not work
Boundary-Scan Guide
5-25
TCK is disconnected from one or more devices
Integrity tests are an integral part of every chain test.

Integrity test occurs before each powered shorts test,
before each interconnect test, before each buswire test,
and before 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 these 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,
Boundary-Scan Guide
in this case, implies proper devices loaded, and devices

that are basically functional.
Any failure during TAP Integrity test causes the board to
power down 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. Also, 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.
Interconnect Test
most cases will work without debug. The information in
this section is provided for background. Interconnect
test allows you to test the circuitry that connects one
boundary-scan device to another. Interconnect test
primarily looks for shorts, then most opens. (A buswire
test might be necessary to detect opens missed by
interconnect test.) Only the connections between
devices in the same boundary-scan chain can be
verified.
5-26
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 5-16 illustrates interconnect test.
Because damaging devices during powered testing is an
important issue, InterconnectPlus software takes the
following approach to interconnect test.
Looks for shorts and most opens.
Concentrates on finding shorts as fast as possible.

NOTE
A silicon node is a node on which no physical test
probe is used. An 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.
Boundary-Scan Guide
5-27
Figure 5-16
Interconnect Test checks connections between two or more boundary-scan devices connected in a chain
u1
u2
TDI
Nodes Tested in
Interconnect
u4
u3
TDO
Frames and Signatures

Before you explore interconnect test, you need to
understand the concepts of frames and signatures. For
the circuit in Figure 5-16, the example data pattern is
set up as shown in Table 5-4.
Boundary-Scan Guide
Table 5-4
A
Rows form signatures
5-28
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 frame is two times the size of the active register
because two vectors are needed for each clock cycle.
The rows of bits from the corresponding positions in
each frame 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 5-17. For more information about the frame
and end frame statements, refer to the Syntax Reference
documentation.
frame 0 1
000X
100X
001X
101X
001X
101X
000X
100X
01XX
end frame
Boundary-Scan Guide
5-29
Figure 5-17
Interconnect Test uses frames and signatures

A 0 1 0 0 1
u1
u2
0 1 0 1 0
B
C
0 1 0 1 1
TDI
u3
u4
B
D
0 1 1 0 1
TDO
Frame
1 2 3 4 5
To create an interconnect test of five bits per signature,

as Figure 5-17 shows, we can use the five frames shown
Boundary-Scan Guide
on the preceding page.
5-30
The frame positions that correspond to the drivers, at

UPDATE-DR, for each node contain the bits that make
up the signatures (IDs) for those nodes. When the
devices pass through CAPTURE-DR, the receivers
connected to the corresponding node should capture the
bits of that node's ID.
How Software Designates a Driver for Interconnect Test
As we mentioned earlier, 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
(affectionately called the designated driver) as the one
that will be used to drive the node during interconnect
test. All other drivers connected to the node are
disabled. These drivers are tested later during buswire
test.
Boundary-Scan Guide
5-31
When bus drivers share control cells, a single driver

cannot be designated
11
u1
u2
12
13
TDI
C o nt ro l C el l
u3
u4
10
TDO
Con tro l Ce ll
Several circumstances can prevent the software from

designating only one driver. Figure illustrates one
situation where bussed drivers share the same control
Boundary-Scan Guide
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.
5-32
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 have multiple drivers.
This situation must occur because interconnect test
needs to drive these nodes during its test. 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.
Executing Interconnect Test
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 shown
in 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.
Boundary-Scan Guide
NOTE
The exception to this is a TAP-only device, which
is always in BYPASS during testing.
When the devices pass through UPDATE-IR, the driver
cells drive the SAMPLE/PRELOAD data bits to 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 receive cells, which are then shifted out
for examination. Data shifted out should correspond to
the signatures 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 specified in the BSDL file provide the
value that the device's designer prefers to have loaded
into the associated cell's UPDATE flip-flop when
software might otherwise randomly choose a value. For
more information and examples of safe bits, refer to
chapter 2 in this documentation.
5-33
NOTE
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 Guide
5-34
Figure 5-18
PRELOAD zeroes (0) shifted in to drive cells

A
u1
B
C
u3
u2
0
0
u4
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
Boundary-Scan Guide
5-35
Figure 5-19
.Interconnect Test finding an open on a receiver

Open
A
u1
B
C
1 A
0
0
0
u2
TDI
u3
B
D
0
0
0
u4
TDO
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.
Boundary-Scan Guide
5-36
Figure 5-20
Interconnect Test finding an open on a driver
u1
B
C
0
0
0
Open
1 A
u2
TDI
u3
B
D
A 0
0
0
1 A
u4
TDO
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.
Boundary-Scan Guide
5-37
Table 5-5
Frames
Node
Power Bits
Eliminates Aliasing
to Ground or VCC
Counting Bits
Primarily Distinguishes one
Node From Another
The enhanced counting sequence first assigns a 01 bit

combination that we'll call the power bits. These bits
verify that the node is not shorted to ground or VCC.
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.
Boundary-Scan Guide
Complement Bits
Reduces Incidence of Aliasing
Between Active Nodes
shows how a short is detected by comparing the

expected signature of a particular node with the one
captured during testing.
5-38
Figure 5-21
.Interconnect Test uses signatures to check for shorts and opens. In this example, a short is detected
Expe cte d
S i g n a t u re s
Cap t ure d
S i g n a t u re s
0 1 0
0 0 1
0 1 1
0 1 1
u1
B
C
u2
TDI
u3
u4
D
TDO
Testing Bidirectional Pins
Interconnect Test and Bussed Devices
Interconnect test fixes the direction in which it tests

bidirectional cells. An internal routine determines
whether to test bidirectional cells as drivers or as
receivers.
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.
Boundary-Scan Guide
5-39
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
Figure 5-22
interconnect test, which allows shorts to be detected as

soon as possible. Buswire testing is discussed in more
detail in the next section.
Software breaks out buswire tests from Interconnect Test

u1
11
12
13
u2
T DI
Con trol Ce ll
u3
8
9
10
u4
TDO
C o nt ro l C ell
Buswire Test
Boundary-Scan Guide

this section is provided for background. During
5-40
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. Buswire test is
Figure 5-23
derived from the connectivity information used to

generate the interconnect test. If IPG sees that the chain
has bussed devices, it generates the buswire test. Figure
5-23 illustrates buswire test.
Buswire Test verifies connections on bussed nodes

u2
u1
TDI
u3
u4
T DO
Boundary-Scan Guide
5-41
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 5-24 shows several examples where opens could
be missed during interconnect testing in the case of
bussed devices. These examples are briefly described
below.
AIf only one driver per bussed wire is enabled during
interconnect test, opens on the disabled drivers would
not be detected.
BIf two or more drivers must be enabled to satisfy
interconnect test and they drive the same node, an open
on one of these drivers would not be detected.
CIf 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.
Boundary-Scan Guide
5-42
Figure 5-24
Example cases where opens could go undetected on bussed wires

B
A
OFF
ON
ON
ON
OFF
U nd ete ct ed F a ilures
Un de t ec te d F a ilu res
Co n tro l C el l t o O t he r F a n Dr iv e rs
C
ON
ON
U nd et e ct ed F a il ure s
Drivers Ganged For Increasing Current
(This Failure Cannot be Detected by Any Method)
Testing Parallel Busses
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.
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.
Boundary-Scan Guide
5-43
Because the sample chain includes two pairs of bussed

wires (A and B in Figure 5-25), each separate,
independent bus can be tested in parallel.
Table 5-6
Device.Pin
Node
Bit Pattern
u1.10
01
ZZ
u3.10
ZZ
01
u1.9
01
ZZ
u3.9
ZZ
01
Boundary-Scan Guide
5-44
Figure 5-25
Parallel testing for separate bussed nodes

A
10
u1 9
8
B
C
TDI
TDO
If the chain included a third driver on wire B, as shown

in Figure 5-26 on page 5-47, a third pair of frames
would be needed to test this wire. The number of frames
Boundary-Scan Guide
5-45
in a buswire test is equal to two times the size of the bus

with the largest number of devices connected to it.
Table 5-7
Device.Pin
Node
Bit Pattern
u1.10
01
ZZ
ZZ
u3.10
ZZ
01
ZZ
u1.9
01
ZZ
ZZ
u5.5
ZZ
01
ZZ
u3.9
ZZ
ZZ
01
Boundary-Scan Guide
5-46
Figure 5-26
Multiple drivers on one bus require additional frames
TDI
TDO
Connect Test
this section is provided for background.
InterconnectPlus connect test allows you to test for
Boundary-Scan Guide
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
5-47
(uY) until all devices have been tested. All other devices
in the chain are placed in BYPASS. One connect test is
generated for each device in the boundary-scan chain
Figure 5-27
with testhead access. Figure 5-27 illustrates

boundary-scan connect test.
Connect Test checks the connections of each device in a chain
TDI
TDO
Boundary-Scan Guide
5-48
NOTE
If an upstream device that is in BYPASS has
outputs that affect the DUT, IPG will generate the
required disabling methods to eliminate conflicts
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.
Connect test employs the Parallel Toggle macro.
Complimentary 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.
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.
Boundary-Scan Guide
A connect test can fail in one of two manners:
the TAP Integrity procedure could detect a

problem.
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 are 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. 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.
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.
5-49
NOTE
NOTE
Datalogging software logs opens on bidirectional

pins only during the output part of the test. Input
failures of bidirectional pins are not logged to
prevent duplication of failure information.
Boundary-scan in-circuit test is discussed in

chapter 1 as the EXTEST stand-alone function.
Comparing Connect Test with Boundary-Scan In-circuit

Test
Boundary-scan in-circuit test is similar to connect test
and is performed on boundary-scan devices that are not
connected in a chain. Boundary-scan software treats
these cases differently from those devices that are
connected in a chain.
Devices not connected in a chainIn-circuit test

performed on the devices in a stand-alone fashion.
All device pins require physical probes (including
TAP pins) and all pins are tested. Boundary-scan
in-circuit test is pin-oriented.
Devices connected in a chainConnect test

performed on one device at a time; other devices
in chain are in BYPASS. Only those nodes that
have physical probes assigned are tested.
Boundary-scan connect test is node-oriented.
Connect test also 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.
Boundary-Scan Guide
5-50
Figure 5-28
Comparing boundary-scan in-circuit and connect tests
TDI
De vic es N o t Con ne ct ed
in a Chain
Ph y s i c a l P ro b e
TDO
D evi ce s Con nec t ed i n a C h a i n
(A ll C o nne c t Tes t Nod es Mu st h av e Pro b es
Custom Boundary-Scan Tests

Custom boundary-scan tests are used to access those
instructions (listed in the devices' BSDL files) that can
be used for special test purposes beyond those supported
Boundary-Scan Guide
by EXTEST, such as powered shorts, interconnect,

buswire, or connect test. These tests perform specific
functions that are not added to your board test as part of
the automatic test generation process.
5-51
Like the standard Boundary-Scan software,

InterconnectPlus features an interactive user interface
that helps you develop custom boundary-scan tests for
your device chains. Chapter 6, Multichip Scan Port
Driver and the MSPD Interface, describes this interface
and how to use it.
An important issue to consider is when to use the
interface to develop custom tests. If you know that you
want to generate custom tests, you should write an ITL
file that describes each chain for which you plan to
develop custom tests. This strategy allows you to
develop the tests and create the custom library test file
that IPG will need when it generates your board test.
The alternative is to run IPG first, then copy and edit an
ITL file that it generates when you are ready to develop
the custom tests. After you have completed the custom
test, you must run IPG in incremental mode on the new,
custom library test file.
Chapter 6 provides detailed information about
performing this task regardless of the strategy that you
choose to employ.
Boundary-Scan Guide
5-52
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
Boundary-Scan Guide
The Test Generation Process

Figure 5-29 is a flow diagram of the process for
generating a chain test. The diagram starts in Board
Consultant where you enter information about each
device. The resulting test process happens automatically
and tests are generated automatically.
NOTE
The BSDL file for each device must be complete
and accurate before entering the test process.
Incomplete or inaccurate descriptions can result in
complicated debug later in the process. For more
information, refer to the section Confirming the
BSDL File found later in this chapter.
Internal compilers use board and location information to
generate the board files board and board_xy. These files
are then used by topology analysis software and IPG to
determine the devices in a chain and their locations on
the circuit board.
5-53
Figure 5-29
Process flow for generating a chain test

B O A R D C O N S U LTA N T
board_xy
board
Compiler
"board.o"
"board_xy.o"
TOPOLOGY
IPG
Creates 5 ITL Source Files
P o w e re d S h o r t s Te s t
(1 per chain)
uX_uY_ps
I n t e rc o n n e c t Te s t
(1 per chain)
uX_uY
See Note on the

next page.
P o w e r e d S h o r t s Te s t
uX_uY_ps.vcl
and
uX_uY_ps.vcl.x
B u s w i re Te s t
(1 per chain)
uX_uY_bus
C o n n e c t Te s t
(1 per device connected
to real nails)
uX_connect
S i l i c o n N a i l Te s t
(parallel test)
uX
MSPD -serializer
creates 4 VCL source files
I n t e r c o n n e c t Te s t
u X _ u Y. v c l
and
u X _ u Y. v c l . x
B u s w i re Te s t
uX_uY_bus.vcl
and
uX_uY_bus.vcl.x
uX_connect.vcl
and
uX_uY_connect.vcl
S e r i a l i z e d Te s t
uX_sn.vcl
and
uX.vcl.x
(executable)
uX_connect.r
or
uX_connect.o
S i l i c o n N a i l Te s t
uX_sn.o
(executable)
or
uX.r
Compiler
P o w e r e d S h o r t s Te s t
(executable)
uX_uY_ps.r
or
u X _ u Y. o
I n t e rc o n n e c t Te s t
(executable)
u X _ u Y. r
or
u X _ Y. o
B u s w i r e Te s t
(executable)
uX_uY_bus.r
or
uX_uY_bus.o
TESTHEAD
Boundary-Scan Guide
Results Analysis
5-54
NOTE
ITL source files contain references to BSDL files.
These files must have been compiled (creating .o
objects) in advance of compiling the ITL files.
IPG generates four preliminary test structures: powered
shorts, interconnect, buswire, and connect. IPG
generates one interconnect test for each chain, one
buswire test for each chain, one powered shorts test for
each chain, and one connect test for each device in the
chain connected to physical probes. The names assigned
to each test type by IPG 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
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
chain. For example: u1_u4_bus
Boundary-Scan Guide
connect test:
<device>_connect, where <device> is the name of
one device in the chain. For example: u3_connect
IPG then sends this information to the MSPD serializer,

which creates four types of VCL source files: powered
shorts test, interconnect test, buswire test, and connect
test.
NOTE
The Silicon Nail test path is shown in Figure 5-29
only to identify its relationship to standard, chain
test generation. Silicon Nail testing is discussed
later in this chapter.
These source files are sent to the VCL compiler, which
generates executable tests that can then be incorporated
into the testplan.
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 Your Boundary-Scan Device

To generate tests for a chain of boundary-scan devices,
you must tell IPG where it can find the BSDL files for
your devices, and you must describe your devices. Both
of these tasks are accomplished using Board Consultant.
5-55
Using the Library Path Names Form

Use this form, as Figure 5-30 shows, to tell IPG where
to look for the BSDL files for your devices.
1 Select Program > Run Board Consultant.
2 When the Board Consultant interface appears, either
create a new board file or load an existing board file.
3 Click on the View/Edit Library Data button in the

flowchart, then Enter Library Paths from the list at the
bottom of the flowchart.
4 When the Library Paths Form appears, type the
appropriate path in the Library Path's field.
5 When you finish entering new paths, click on the
Update button.
6 Click on the Close button to exit the form.
Figure 5-30
Use the library paths form to tell IPG where to find the BSDL files
Boundary-Scan Guide
5-56
Using the Device Entry Form

Figure 5-31 shows the device entry form for pin
libraries, where you enter information about your
boundary-scan devices.
1 Select the Program > Run Board Consultant.
2 When the Board Consultant interface appears, either
create a new board file or load an existing board file.
3 Click on View/Edit Board Description in the flowchart,
then Enter Pin Library from the list at the bottom of
the flowchart.
4 The basic Device Entry Form appears. Select Options
> Show Scan Library Test Options.
5 When the form appears, select Options > Maximize to
display the form shown in Figure 5-31.
The top half of the form provides you with a tool to
customize your board's files for test and fixture
generation. The use of these fields is described in
Tools2. The entries that you make in the fields in the
lower half of this form complete the description of your
chain for test development software.
NOTE
Refer to Tools2 for detailed information about
using the Board Consultant interface.
Boundary-Scan Guide
5-57
Figure 5-31
Board Consultant device entry form
Boundary-Scan Guide
5-58
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.
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

softwares 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.
Boundary-Scan Guide
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 3070 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
5-59
exactly as they are listed in this form; point_1 to

point_2 to ... to point_N.
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.
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).
Capture Graphic Device Outline: Click this

button to copy the polygon currently being used as
an outline for this 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.
Boundary-Scan Guide
5-60
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.
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 Connect Max on page 5-62
for an explanation of this feature.
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.
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.
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.
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
Boundary-Scan Guide
NOTE
After you have described your devices and added them

to your test, when you leave Board Consultant, the
board compiler runs and IPG Test Consultant 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,
particularly to provide IPG with pertinent disabling and
device family information. (Disabling information is not
needed for boundary-scan disabling. See Using
Boundary-Scan Disabling on page 5-71 for more
information.) 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.
Figure 5-32 on page 5-62 shows the device entry form
as it would appear for a TAP-only device. Remember
that specifying a device as TAP-only eliminates that
device from boundary-scan testing but allows you to
5-61
keep the device in the chain, which in turn allows for

better overall testing of the chain.
Figure 5-32
Verifying that your board test fits within your

tester configuration
The connect button must be set to No if you want to

specify the device as TAP-only. Setting the Connect Test
button 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 so desire. 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.
Connect Max
One of the standard parts of the test development
process is using Board Consultant to verify that your
board test will fit within the resources of your tester
(Figure 5-32). Sometimes, you encounter a situation
where you require more digital channels than your tester
has available (Figure 5-33). If this problem is the result
of a connect test on a large boundary-scan IC, the
Connect Max feature can often help.
Boundary-Scan Guide
5-62
Figure 5-33
A test requiring more channels than the tester

has available
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,
as in this example.
Whenever you specify a Connect Max setting, you
should also use the Device Entry Form to 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.
Understanding the Contents of the BSDL File

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
Boundary-Scan Guide
A key experience gained in early implementations of

boundary-scan is the importance of describing the
component correctly. Because the Boundary-Scan
5-63
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
Boundary-Scan Guide
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.
What are the problems that might be encountered if an

inaccurate BSDL file were provided for a device?
Consider Figure 5-34, an example of how interconnect
tests are executed.
5-64
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.
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.
Figure 5-34 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 mis-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 5-34
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.
Boundary-Scan Guide
5-65
Figure 5-34
Inaccurate BSDL descriptions cause testing problems
TDI
TDO
Internal*
Output
Control
TDI
TCK
TDO
TMS
Output* Control
* Cells Missing From BSDL
Boundary-Scan Guide
5-66
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 featured in the standard
Boundary-Scan software to automatically generate a test
for each device. The test generated can then be executed
by:
For more information about this macro, refer to

chapter 4 of this documentation.
Where to Place BSDL Files and Associated Packages
building a special test fixture for the

component...or
loading one board with only the boundary-scan

component and arranging access to all pins...or
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
/3070/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.
verifying the BSDL file at device test if the

semiconductor test supports BSDL-based
boundary-scan...or
Placing user-defined packages in the proper location is

of particular importance. When reading a BSDL file, the
system will look for associated packages:
translating the test to simulator input, then

simulating it against a model of the device
NOTE
Because this function is for a single device, you
must use the SPD Interface to find the Verify
BSDL macro; refer to chapter 4.
NOTE
Boundary-Scan Guide
in the same directory where the BSDL file itself

resides, and
in the standard location,

/3070/library/supplemental/bsdl
On the other hand, the main BSDL file belongs in the

board directorys 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
5-67
same names in different paths will not avoid such a

mistake.
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 5-71 for
more information.
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
Agilent IPG removes bussed nodes from boundary-scan

tests if the proper disabling cannot be done. HP IPG
cannot always accomplish the disables as needed. If a
disabling conflict arises, HP IPG rejects the disable
method, and reports in the source file that the node was
not disabled.
For conventional disabling, IPG 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 5-35 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
Boundary-Scan Guide
5-68
Figure 5-35
Disabling a device to maintain a stable test
Device must be disabled

when u1 and u2 share
data.
TDI
TDO
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
provide to IPG. To understand why this is necessary,
consider the following scenario as illustrated by Figure
5-36.
Boundary-Scan Guide
5-69
Figure 5-36
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.
Boundary-Scan Guide
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.
5-70
IPG 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 Digital2.
Fixed Node Considerations
If you know that your board has fixed nodestied to
power or grounduse Board Consultant to define them
in your board file. When IPG runs, it 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 5-2
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"
Boundary-Scan Guide
end nodes
end connect
You should understand that if IPG 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.
Using Boundary-Scan Disabling

InterconnectPlus lets you use boundary-scan resources
to disable device outputs.
To use this feature, set the Boundary-Scan Disable field
to On. This field is located in the IPG Global Options
Form in Board Consultant. The default value is Off to
permit backward compatibility with previous versions
of InterconnectPlus.
This feature is highly recommended for new tests (tests
not prepared under a previous version of
InterconnectPlus).
NOTE
When you set the Boundary-Scan Disable field to
On, the Boundary-Scan Overdrive field is
automatically set to Off.
5-71
By defining Boundary-Scan Disables in the board file,

you can control how devices in the chain that have
bussed pins will be disabled during connect tests of
other devices.
Boundary-Scan Disables 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 register will be loaded with the necessary

patterns to control the drivers for the bussed pins.
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-scansee
Limitations of Boundary-Scan Disabling on
page 5-74).
Minimizes the need for conventional disabling

(seeConventional Disabling of Boundary-Scan
Devices on page 5-68). 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.
Boundary-Scan Disables 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-Scan Guide
5-72
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 5-75 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 5-75 for more information.
The IPG verbosity modes give information about

boundary-scan disables.
Boundary-Scan Guide
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.
For multiple chains:

Boundary-scan disables occur for all chains
except the one being tested.
Boundary-scan tests take place for the current
chain.
The first two bullets are repeated for each
chain.
Boundary-scan disabling takes place for all
chains.
In-circuit tests are performed.
NOTE
Like all boundary-scan tests, the boundary-scan
disabling program can 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.
5-73
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
pins. If you disable boundary-scan pins, the

devices internal logic may go into an undefined
state and prevent a conventional disable from
working on the remaining pins (Figure 5-37). 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 devices
pins.
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
Boundary-Scan Guide
5-74
Figure 5-37
Boundary-scan disabling may leave a devices internal logic in an undefined state and prevent the conventional
disabling of non-boundary-scan pins
Int
er
un nal lo
def gi
ine c
d
Disabled boundary-scan pins
Non-boundary-scan pin
(non-compliant)
Disabled boundary-scan pins

BP
Non-boundary-scan pin
(non-compliant)
IR
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.
Boundary-Scan Guide
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 5-38).
5-75
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.
Also, after performing boundary-scan disables, the test
plan pauses and produces a screen message:
Test Programmer Action Reminder:
Evaluate, act, and then delete this pause
section.
Boundary-Scan Guide
5-76
Figure 5-38
TAP Controller State Diagram

1
Test-Logic-Reset
Normal boundary-scan tests end in this state
0
0
Run-Test/Idle
Select-DR-Scan
0
Boundary-scan
disabling places
the component
in this state
0
1
Capture-DR
Capture-IR
Shift-DR
Shift-IR
Exit1-DR
Pause-DR
Pause-IR
1
0
Exit2-IR
1
1
Update-DR
Boundary-Scan Guide
Exit2-DR
Data
Exit1-IR
Select-DR-Scan
Update-IR
0
Instruction
5-77
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
Example 5-3
pause statement. You can view them when you edit the
test program. Example 5-3 shows a sample message.
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.
Boundary-Scan Guide
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.)
5-78
4 If TCK and TMS are not quiescentsuch as when an

oscillator is connected to TCKeither:
Shut the oscillator off.
Connect TCK to a 3070 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 5-39).
If the oscillator is not gated, add the relay to

pull-down to TMS (Figure 5-39). As shown in the
state diagram (Figure 5-40), feeding a zero signal
to TMS keeps the TAP in Run-Test/Idle.
NOTE
If you use a GP relay to pull down a signal, the
relay must be closed when the testplan
implements boundary-scan disables.
Boundary-Scan Guide
5-79
Figure 5-39
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
with internal pull-up
resistors for TMS
Vcc
TCK
Oscillator
Vcc
GP
TCK
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 signalssuch as the two paralleled
serial chains with common TCK in Figure
5-40you may need multiple put-downs to the TMS
lines to maintain persistence.
Boundary-Scan Guide
5-80
Figure 5-40
Example of chain that requires multiple pulldowns

TDI
TDI
TDO
TDI
TDO
TMS
TCK
TMS
TCK
TMS1
TDO
TCK
TMS2
TCK
TDI
TMS
TDO
Overdriving Boundary-Scan Devices

When IPG generates a connect test, it tries to use all of
the chain. If you assign physical probes to each (or
specific individual) 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 do this, you would use the IPG Global
Options Form in Board Consultant and 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 Guide
TCK
TDI
TMS
TDO
the field set to Off and IPG would use the entire chain
rather than local TDI/TDO nodes.
The only entry that you would be concerned with in this
form (with respect to boundary-scan testing) is the
Boundary-Scan Overdrive field. The default setting is
Off. If you turn this setting On, IPG will use the local
TDI and TDO nodes for each device to be overdriven
provided probes exist on these nodes.
5-81
NOTE
When you set the Boundary-Scan Disable field
On, the Boundary-Scan Overdrive option is
automatically set to Off. See Using
Boundary-Scan Disabling on page 5-71 for more
information.
Refer to Tools2 for more information about this form.
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 bits 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.
Figure 5-41 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.
Boundary-Scan Guide
5-82
Figure 5-41
74ACT8997 Linker/MUX device linking chains A, B, and C
A1
TDI
A2
Ai
PAD
BIT
B1
B2
Bj
C1
C2
Ck
PAD
BIT
PAD
BIT
In the following example, 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 the
following:
1u1_1u4
Boundary-Scan Guide
8997
TDO
TDI 1TDI
TDO 1TDO
TCK 1TCK
TMS 1TMS
DEVICES
1u1, 1u2, 1u3, 1u4;
2u1_2u4
TDI 2TDI
TDO 2TDO
TCK 2TCK
TMS 2TMS
5-83
DEVICES
2u1, 2u2, 2u3, 2u4;
linker_linker
TDI TDI-LINKER
TDO TDO-LINKER
TCK TCK-LINKER
TMS TMS-LINKER
DEVICES
Example 5-4
linker;
END;
This could be hand edited with Boundary-Scan Chain

Override to connect the two chains and the linker into a
single chain, though without pad bits at this time.
Example 5-4 shows the resulting single chain
description.
Single chain description

1u1_linker
! put two chains and linker together
TDI TDI-LINKER
! specify linkers 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 looking
like Example 5-5.
Example 5-5
Chain description
chain "1u1_linker"
tdi "TDI_LINKER" channel;hybrid
tdo "TDO_LINKER" channel;hybrid
Boundary-Scan Guide
5-84
tms "TMS_LINKER" channel;hybrid

tck "TCK_LINKER" channel;hybrid
devices
"1u1", "custom/74bct8374", "DW_PACKAGE",
"linker", "custom/74act8997", "PQFP-48",
end devices
end chain
no
no
no
no
no
no
no
no
no
You then edit in the pad bits and optionally, the pointer
to the PCF fragment needed to configure the
linker/MUX chip.
Example 5-6
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
pad
Boundary-Scan Guide
no
no
no
no
no
5-85

"linker", "custom/74act8997", "PQFP-48",
end devices
insert "digital/linker_setup"
end chain
EXAMPLE 1:
You have just translated data from Computer Aided
Design (CAD) 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 by IPG. 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
Boundary-Scan Guide
no
no
no
no
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:
Following 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 (see below). The
PCF that is inserted is designed to program the
5-86
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 Guide
5-87
Example 5-7
--------------------------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",
"2u2", "custom/74bct8374",
"2u3", "custom/74bct8374",
"2u4", "custom/74bct8374",
"2u8", "custom/74act8997",
end devices
insert "digital/2u8_setup"
end chain
"DW_PACKAGE",
"DW_PACKAGE",
"DW_PACKAGE",
"DW_PACKAGE",
"DW", no
no
no
no
no
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
Boundary-Scan Guide
5-88
fixed low "1IN_16" test "2u3.24"

silicon node "2U1_2" test "2u1.2","2u2.23"
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"
end nodes
end interconnect
---------------------------
Following is the PCF fragment used to program the

MUX/Linker chip such that the (Secondary Scan Path 1)
SSP1 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
Boundary-Scan Guide
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 by 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
5-89
retained, discarding the rest. 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 the
ITL above.
Boundary-Scan Guide
5-90
Example 5-8
--------------------------! 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
Boundary-Scan Guide
5-91
"101X1"
"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"
"00ZX1"
"10ZX1"!Capture-DR
"00ZX1"
"10ZX1"!Shift-DR
! Loading device 2U8 register SELECTR[8] (for SCANSEL).
end pcf
message " (tck) 15"
message " (tms) 14"
message " (tdi) 16"
message " (tdo) 13"
pcf
use pcf order Scan
"001X1"!0+0
"101X1"
"001X1"!1
Boundary-Scan Guide
5-92
"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
---------------------------
Example 5-9 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
Boundary-Scan Guide
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
5-93
chain by the MUX/Linker. The test is appropriately

phased to account for the positions of all pad bits.
Boundary-Scan Guide
5-94
Example 5-9
--------------------------< source deleted >
!
!
!
!
!
!
!
!
Device
--------Pad Bit
2U1
2U2
2U3
2U4
2U8
Entity
-----------
Package
-----------
BSDL File
-----------------
TTL74BCT8374
TTL74BCT8374
TTL74BCT8374
TTL74BCT8374
SN74ACT8997T
DW_PACKAGE
DW_PACKAGE
DW_PACKAGE
DW_PACKAGE
DW
custom/74bct8374
custom/74bct8374
custom/74bct8374
custom/74bct8374
custom/74act8997
scan interconnect ! for MUX_2U1_2U8

< source deleted >
pcf order default Scan is
TCK,
pcf order Disable is D000, D001
TMS,
TDI,
TDO,
TRST
!Column-to-Node Map, Nodes 1 to 5

!22222!
!MMMMM!
!TTTTT!
!CMDDR!
!KSIOS!
!
T!
!
!
!
!
unit "Interconnect Test" ! Vector 1
pcf
use pcf order Scan
Boundary-Scan Guide
5-95
"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
!
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"
!
Boundary-Scan Guide
5-96
! Including PCF from file digital/2u8_setup.

!
! Begin insertion
"01ZX1"
"01ZX1"
"00ZX1"
"10ZX1"!Capture-IR
"00ZX1"
"10ZX1"!Shift-IR
end pcf
message " (tck) 15"
message " (tms) 14"
message " (tdi) 16"
message " (tdo) 13"
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
Boundary-Scan Guide
5-97
"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"
"00ZX1"
"10ZX1"!Capture-DR
"00ZX1"
"10ZX1"!Shift-DR
! Loading device 2U8 register SELECTR[8] (for SCANSEL).
end pcf
message " (tck) 15"
message " (tms) 14"
message " (tdi) 16"
message " (tdo) 13"
pcf
use pcf order Scan
"001X1"!0+0
"101X1"
"001X1"!1
"101X1"
"000X1"!2
Boundary-Scan Guide
5-98
"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"
! End of insert
!
! End of PCF from file digital/2u8_setup,
! 56 vectors inserted.
!
"01ZX1"
"01ZX1"
"00ZX1"
"10ZX1"!Capture-IR
"00ZX1"
"10ZX1"!Shift-IR
end pcf
Boundary-Scan Guide
5-99
message " (tck) 15"

message " (tms) 14"
message " (tdi) 16"
message " (tdo) 13"
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 " (tck) 13"
message " (tms) 12"
message " (tdi) 14"
message " (tdo) 11"
pcf
use pcf order Scan
"001H1"!6
"101X1"
Boundary-Scan Guide
5-100
"001L1"!7
"101X1"
"001L1"!10+0
"101X1"
"001L1"!1
"101X1"
"001L1"!2
"101X1"
"001L1"!3
"101X1"
"001L1"!4
"101X1"
"001H1"!5
"101X1"
end pcf
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"
"001L1"!18+0
"101X1"
"001L1"!1
"101X1"
"001L1"!2
"101X1"
Boundary-Scan Guide
5-101
"001L1"!3
"101X1"
"001L1"!4
"101X1"
"001H1"!5
"101X1"
end pcf
message " (tck) 13"
message " (tms) 12"
message " (tdi) 14"
message " (tdo) 11"
pcf
use pcf order Scan
"001H1"!6
"101X1"
"001L1"!7
"101X1"
"001L1"!26+0
"101X1"
"001L1"!1
"101X1"
"001L1"!2
"101X1"
"001L1"!3 Vector 150
"101X1"
"001L1"!4
"101X1"
"001H1"!5
"101X1"
end pcf
Boundary-Scan Guide
5-102

message " (tck) 13"
message " (tms) 12"
message " (tdi) 14"
message " (tdo) 11"
pcf
use pcf order Scan
"001H1"!6
"101X1"
"001L1"!7
"101X1"
"001L1"!34+0
"101X1"
"001L1"!1
"101X1"
"001L1"!2
"101X1"
"001L1"!3
"101X1"
"001L1"!4
"101X1"
"001H1"!5
"101X1"
"001X1"!6
"101X1"
"001L1"!7
"101X1"! Vector 175
! Shifting Pad Bit
"01ZH1"!42+0
"11ZX1"!Exit1-IR
"01ZX1"
"11ZX1"!Update-IR
end pcf
message ""
pcf
Boundary-Scan Guide
5-103
use pcf order Scan

"01ZX1"
"00ZX1"
< remainder deleted >
---------------------------
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
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 on this
topic, refer to Addressing Ground-Related Problems
on page 5-126.
Boundary-Scan Guide
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
5-104
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.
Figure 5-42
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.
Removing probes requires careful consideration

VCC
Analog Node
Clean Node
U3_3
U3_2
Partial Node
Digital
Figure 5-42 illustrates several situations that must be

considered before you remove physical probes. These
Boundary-Scan Guide
situations are based primarily on the type of node that

you are considering for removal. The following list
5-105
outlines 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 listed below:
Clean node: Node with only boundary-scan
inputs and outputs are good candidates for
probe removal.
Digital node: Node 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: Node 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.
Mixed node: Node 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
Boundary-Scan Guide
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.
NOTE
You should not remove probes from disable
control nodes. This action could restrict IPG'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.
Realize 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
5-106
I/O pins, but the board and the boundary-scan devices

do not necessarily pick up where they left off.
NOTE
For automatically generated boundary-scan tests,
the software writes 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.
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.
Boundary-Scan Node Testability Report

If you have the optional InterconnectPlus software, IPG
generates a testability report that includes
recommendations about probe requirements for nodes.
IPG determines if probe access is needed for each node
and whether the node already has probes assigned. To
make the changes that IPG recommends, you can easily
transfer the reported information into the board_xy file
and rerun IPG.
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;

assigned but probes are needed;

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 IPG, 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
Boundary-Scan Guide
5-107
Category 2, now belong to Category 4. You must be

careful about nodes that shift from Category 2 to
Category 4. These nodes are no longer tested by connect
testing and 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 the example report that follows.
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, execute the
following statement:
execute "fmt
ipg/raw
<file name>"
An Example Testability Report
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.
This section contains an example of a formatted

testability report for an interconnect test named u1_u4.
For example, to output the formatted information to the

screen for an interconnect test name u1_u4, you would
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, you would enter (on one line):
Boundary-Scan Guide
5-108
Example 5-10 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
!NODE IN_17
!NODE OUT_09
!NODE OUT_10
!NODE IN_16
!NODE IN_24
!NODE IN_23
!NODE IN_22
!NODE IN_21
!NODE IN_20
!NODE IN_19
Boundary-Scan Guide
5-109
!NODE U3_3
!NODE U3_2
!NODE IN_18
!NODE IN_04
!NODE OUT_04
!NODE OUT_05
!NODE OUT_06
!NODE IN_03
!NODE IN_12
!NODE IN_11
!NODE IN_10
!NODE IN_09
!NODE IN_08
!NODE IN_07
!NODE IN_06
Category 3 Nodes (Have no probes, and probes are not needed)
These nodes have the resources for Boundary-Scan Interconnect
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
NODE U1_U3_8
NODE U1_U3_7
NODE U1_5
NODE U1_4
NODE U1_3
NODE U1_2
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
NODE U4_9
NODE U4_8
Boundary-Scan Guide
5-110
NODE U4_7
NODE U4_5
NODE U4_4
NODE U7_6
NODE U7_5
NODE U2_10
NODE U2_9
NODE U2_8
NODE U2_7
NODE U2_5
NODE U6_3
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
Boundary-Scan Guide
5-111
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 (.0) 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 connect test, physical test probes on output pins are
used to capture data that is immediately analyzed by the
software for pass or fail.
Boundary-Scan Guide
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 5-8 were
shorted, the resulting IDs captured on these nodes
(00010) would indicate a short to node A (00010).
NOTE
For this discussion, the shorted nodes are ANDed
to produce the resulting IDs. Understand that
other situations, such as ORed shorts or strongest
drivers, could produce different results, but
similar problems.
5-112
Table 5-8
Selected IDs Used to Illustrate Aliasing
ID (00010000). This provides increased resolution for

the software to distinguish one node from another.
Table 5-9
A
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.
Results Analysis: Failures Causes and Messages
InterconnectPlus alleviates the aliasing and confounding

problems by using the enhanced counting sequence
(described earlier in this chapter) and adding a fixed
number of complementary bits that extend the IDs for
each node. Table 5-9 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
Results Analysis: Failure Causes
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.
There are four failure causes possible from the diagnosis

of the cell data:
Adding Complementary Data Bits Alleviates

Aliasing
Boundary-Scan Guide
Short to a fixed node

Short to a boundary-scan node
Open circuit
Unknown Failure
5-113
A short to one or more nodes that are also

solely under the control of the Boundary
Register.
These causes are deduced from the failure analysis of

the cell information discussed in the next section.
Understand that these causes might be due to a variety
of physical symptoms in the circuit itself. These
symptoms are discussed below.
A short to a non-boundary-scan node that

produces an ID that matches the ID of some
other boundary-scan node.
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:
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
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 node: This is

diagnosed whenever two or more nodes are
detected as having the same ID and that ID is not
all zeroes or all ones. The physical causes for this
could be:
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.
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:
Boundary-Scan Guide
5-114
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
Boundary-Scan Guide
packaged devices are used, but possible in the

case of Chip On Board or Multichip Module
technology using wirebond techniques).
Results Analysis: Messages
When a boundary-scan test fails, a message that
describes the failure is sent to the report device. This
message includes a list that provides the device and
pin(s), or the node(s) that failed. The following is one
example of such a message. Other examples are
provided at the end of this section, after the descriptions
of the messages that you could see during testing.
----------------------------------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
----------------------------------
Node <nodename> is stuck; probably shorted

to fixed node The identified node is not
toggling. The cause is probably a short to either
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.
5-115
A short has been detected between the

following nodes The node/pin list identifies all
nodes and pins associated with the failure. 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; Probably a short,
but the shorted node cannot be located. Pins
involved are: All of the inputs on a particular
node observe it toggling in the same manner, but
that manner is not correct. This is most probably
caused by a short to another node that is not
connected to a boundary-scan device. Check the
pin list to identify the most likely places for the
failure.
Node <nodename> is stuck; suspect open on

<device>.<pin>. However, these pins should
also be checked for a short to power or ground
The node is stuck, but the most probable cause
of the problem is an open on the device.pin
identified. The difference between this message
and the previous one is that the RA routine, in
analyzing the nodal activity, has determined that
the node probably is not shorted; however, it
cannot be sure, so you should check for a short to
power or ground.
Pin is stuck; check for open on <device>.<pin>

connected to node <nodename> The RA
Boundary-Scan Guide
routine has found that some of the pins on the

node are correctly toggling, but that the identified
pin is stuck. The cause is probably an open on this
pin alone.
Node <nodename> is stuck; probable open on

<device>.<pin> or <device>.<pin> The
failing node is stuck, and that node has only one
driver and one receiver connected to it. In this
case, no additional data is available from 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 open:

During a buswire test, all pins (that will always be
output or bidirectional 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
5-116
connect tests. It lists the input or bidirectional pins

detected as open (see the previous message for
further information).
Suspected open, but pin toggles:

<device>.<pin> The indicated pin on a node is
toggling, but not in the same manner as all 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 or TCK
(check for non-disabled device) Because it is
imperative that interconnect tests execute rapidly
so that if a short is detected power can be removed
from the board, no pin 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.
Boundary-Scan Guide
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.
Unexplained nodal activity; (check for

non-disabled device(s) Injected noise in the
circuit grounds cause the identified device to
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 unknown reason

The system detected a failure on this node, but
its cause cannot be 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.
NOTE
The following messages rarely appear, but have
been added to accommodate the unlikely
occurrence of testhead hardware failure.
5-117
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 Again, the most likely

cause is a failure in the testhead hardware.
Test Halted Due To Unknown Cause Again,

a hardware failure in the testhead.
The following are examples of device failure reports for

the example circuit found at the end of this chapter. 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
Boundary-Scan Guide
-----------------------------Thu Jan 09 17:50:06 1992

-----------------------------INTERCONNECT FAILURE DETECTED
FOR TEST
digital/bus_u1_u4
The following pins are
detected open:
u1.10
------------------------------
SWITCH 1.3
-----------------------------Thu Jan 09 17:50:06 1992
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
FOR TEST DIGITAL/u1_u4
Failing Vector #: 26
IEEE Std 1149.1-1990
Integrity Failure
Device U1 has failed,
suspect device or these
5-118
pins:
(tck) 13
(tms) 12
(tdi) 14
(tdo) 11
------------------------------
SWITCH 1.5
-----------------------------Thu Jan 09 17:50:06 1992
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.
Boundary-Scan Guide
5-119
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.
Boundary-Scan Guide
5-120
Figure 5-43
Boundary-Scan debug
Test Needs to be
Debugged
Yes
Verified BSDL
No
Do We Trust
1149.1
Compliance?
Yes
No
Perform
Verification
of BSDL
Perform
a Chain Debug
Test
Pass
Board
Debug
Fail
NOTE
Debugging Digital Tests on page 4-1.
For more information about digital debug, refer to
Boundary-Scan Guide
5-121
Is the BSDL verified? If yes, do you feel that

1149.1 is complied with? If no, a choice is
available:
If you have a good idea which device is bad,

perform Verification of 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 1149.1 is complied with, perform

the Board Debug test from the menu.
If you feel that 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 from the menu.
Debugging BSDL and Compliance Problems
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 this keyword to debug. Save the file
and recompile it.
NOTE
A Chain Debug test is not a production test. It is
only used for 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.
The Chain Debug test measures chain bit lengths two

ways:
The test measures the length of the combined

devices instruction registers and compares this
Boundary-Scan Guide
5-122
NOTE
When executed, a Chain Debug test DOES NOT
perform a TAP integrity 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 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 will pass. If you have concern
for the accuracy of the BSDL descriptions of your
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.
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
Boundary-Scan Guide
BSDL description. In this way, a failure is specific to

one device.
NOTE
Both checks of a Chain Debug test keep the chain
devices out of test mode by using only BYPASS
and SAMPLE instructions in the test.
Examples of a Chain Debug test failure report follows:
The following 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
----------------------------------------
The following 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
----------------------------------------
5-123
Debugging Executable Boundary-Scan Tests

The VCL files are permanent files created as
intermediate files between the MSPD serializer and
VCL. They are named as follows:
edit the ITL file
The ITL files are permanent files created as

intermediate files between IPG and the MSPD serializer.
They are named as follows:
powered shorts test<device X>_<device

Y>_ps.vcl
(u1_u4_ps.vcl)
powered shorts test <device x>_<device y>_ps

(for example, u1_u4_ps)
interconnect test<device X>_<device Y>.vcl

(u1_u4.vcl)
interconnect test<device X>_<device Y> (for

example, u1_u4)
buswire test<device X>_<device Y>_bus.vcl

(u1_u4_bus.vcl)
buswire test<device X>_<device Y>_bus (for

example, u1_u4_bus)
connect test<device X>_connect.vcl

(u1_connect.vcl)
connect test<device X>_connect (for example,

u1_connect)
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 pathname
The following guidelines should help you decide which

file to edit.
Edit the ITL file if you:
have problems with specific nodes.
want to add or correct device disable information.
NOTE
want to change the TAP-only setting (no to yes).
Uppercase letters are not permitted in source-file

names.
want to comment out a particular test or node that

is causing an unsolvable problem.
/user1/scan_brd/digital/u4_connect.vcl
identifies a connect test for u4.
Edit the VCL file if you:

To debug boundary-scan tests, you can:
use Pushbutton Debug, or edit the VCL source file

directly or
Boundary-Scan Guide
have problems with a particular bit in the

boundary-scan chain
want a fast, temporary solution to a problem

5-124
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 IPG Test Consultant, 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 run compile
using IPG Test Consultant.
NOTE
Both VCL and ITL tests are compiled from
BT-BASIC by using the compile command.
However, only ITL can be compiled from IPG
Test Consultant.
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.
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 between these two statements consists of the
information shifted out from the active, concatenated
registers of the chain during one phase of the test.
compile
digital/<device_name>_connect.vcl;debug
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).
in a BT-BASIC window. When the file has been

compiled, the test debug object will be created.
The number of frames in a test equals the number of

positions in the signature contained in the test
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:
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).
Boundary-Scan Guide
5-125
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 5-158.
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 Guide
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.
NOTE
You might want to consider using a XG-50 fixture
for these applications. The Building Board Test
Fixtures documentation provides some
information about XG-50 fixtures. Contact your
Sales representative for details.
Examine the board itself for sufficient ground

paths and ground routing schemes.
5-126
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 IPG will not
remove them during future test generations.
Boundary-Scan Guide
5-127
Silicon Nails
Automation
The Agilent 3070 can be used to perform Silicon Nails

tests on non-Boundary-Scan devices by generating an
ITL file (containing all vectors needed) that can be used
to test a digital device using a combination of physical
nails and Silicon Nails.
A Silicon Nails test uses the Boundary Register cells
instead of physical probes or nodes. The Boundary
Register cells act as drivers and receivers for
non-Boundary-Scan devices or small clusters of devices
located between boundary-scan devices.
In some cases, a Silicon Nails test takes too long to run.
To run a Silicon Nails test, the time it takes to run a
traditional in-circuit test will be multiplied (worst case)
by a factor of 2N, where N equals the length of the
Boundary Register.
Silicon Nails in Access Consultant

Access Consultant is an analysis and advisory tool that
allows Agilent 3070 users to optimize the use of test
probes in limited access situations. Silicon Nails in
Access Consultant enhances the current suite of Agilent
3070 software by automating the identification of nodes.
Using Access Consultant to test Silicon Nails devices,
customers will be able to:
Utilize the current Access Consultant use model.
To understand more on using Access Consultant for

Silicon Nails testing, see Chapter 2, Agilent Access
Consultant.
Silicon Nails Test Development Process

The test development process using Agilent 3070
software allows for testing devices for which there may
be access limitations. A Silicon Nails test, which tests a
digital pin library device through a boundary-scan chain
and 3070 resources, formerly had to be written
manually.
With the inclusion of Silicon Nails Automation, this step
has been automated. In cases where Silicon Nails tests
are a good choice for the components being tested, the
result is faster test development.
The flowchart in Figure 5-44 shows a typical use case
in which Silicon Nails Automation is employed. Each
step is explained in table Table 5-10 on page 5-129.
Analyze devices targeted for Silicon Nails test

technique and display nodes where access is
required or can be removed.
Boundary-Scan Guide
5-128
Figure 5-44
Test developer tasks with Silicon Nails Automation

Choose
strategy
Add SN keyword
to board file
Compile
board
Generate tests
using IPG
ITL File
4
Silicon Nails
Automation
Compile
tests
5
Tests
Test developer tasks are described in Table 5-10.

Table 5-10 Test development process steps and resources
Step
Information Resources
1 Choose a strategy (e.g., Silicon

Nails) for each device being tested.
The Silicon Nails Test Strategy section of the Boundary-Scan manual.
2 For each device being tested, enter

the appropriate option (e.g., SN
for Silicon Nails) to the board file.
Chapter 1 of the Data Formats manual, The Board File. See especially the Pin
Library section.
Boundary-Scan Guide
5-129
Table 5-10 Test development process steps and resources (continued)

Step
Information Resources
3 Compile the board.
The Test and Fixture Development manual, especially the section titled Compile
the Board and X-Y Data Files. NOTE: You can do this step using Board
Consultant, BT-Basic, or the command line.
4 Generate tests using IPG this

step creates ITL files. For devices
being tested using Silicon Nails,
part of this step runs Silicon Nails
Automation, which generates the
ITL files.
Chapter 1 of the Test Development Tools manual, Test Consultant.
5 Compile tests.
The Silicon Nails Test Strategy section of the Boundary-Scan manual.
Silicon Nails Test Strategy

Silicon Nails refers to the use of Boundary Register
cells to replace physical probes on nodes. The Boundary
Register cells act as drivers and receivers, as shown in
Figure 5-45. The device between the boundary-scan
devices is typically a non-boundary-scan part or a small
cluster. Silicon Nails will automatically generate a test
for digital devices with a library, but you have the option
to manually write a Silicon Nails test for other
scenarios.
Boundary-Scan Guide
NOTE
If a physical nail is present, a Silicon Nails test
will not allow you the option to use a silicon nail
in place of the nail.
You should be fully aware of the potential problems
when exercising this option (see Pros of Using Silicon
Nails and Cons of Using Silicon Nails on page 5-154).
If node access is a real problem, the best candidates for
node removal are nodes on which all components are
boundary-scan. If conventional components co-exist on
a node, a physical probe is recommended. For analog
5-130
components, analog in-circuit tests can then be

performed. Testing analog components without physical
access is a very difficult test situation (for further
information on this, see Agilent MagicTest.) For
conventional digital components Silicon Nails are an
alternative, but physical probes are still recommended.
If node access cannot be gained, the Silicon Nails
method is feasible, and credible diagnostic resolution
can be expected. However, the safety issue needs further
attention.
Without physical access to all nodes, power must be
turned on to find shorts. The concern is the potential for
damaging device outputs. If given a choice, a physical
test probe is preferred for long-term board reliability.
NOTE
Silicon Nails is a registered trademark of Agilent
Technologies.
Boundary-Scan Guide
5-131
Figure 5-45
Boundary register cells that replace physical probes are called silicon nails
"Silicon Nails"
Drivers
Employing Silicon Nails Tests

If you decide to employ Silicon Nails testing on a
non-boundary-scan device that is connected to one or
Boundary-Scan Guide
DUT
Receivers
more boundary-scan devices, you should consider a few

things.
First, the device should have a relatively simple test to
begin with (when it was in-circuit tested) because
5-132
converting to Silicon Nails testing multiplies the length

of the test by a factor of up to 2N, where N equals the
combined length of the active Boundary Registers.
The length of the active Boundary Register is
determined by the total length of the active registers of
the devices connected to the DUT, plus the Bypass
Registers of all the devices in the chain that are not used
for testing the DUT (connections between TDI and
TDO as shown in Figure 5-46).
So if silicon nodes Q, R, S, and T in Figure 5-46 are
connected to the DUT (u7), the length of the active
Boundary Register is as follows (this is approximate): (#
of DUT test vectors) x (length of u3 Boundary Register +
length of u4 Boundary Register + 2) where 2 is the bypass
length of u1 + u2 (or one per device).
Active Data Register = (u3 + u4 Boundary Registers) +
(u1 + u2 Bypass Registers)
Boundary-Scan Guide
5-133
Figure 5-46
Silicon Nails testing on a simple device

Bypass Mode
Bypass Mode
TDI
non-boundary-scan device D Flip-Flop
Extest Mode
Q
R
Extest Mode
S
T
TDO
Boundary-Scan Guide
5-134
NOTE
If from one vector to the next, only bits on nailed
nodes change, serialization may be skipped,
resulting in a shorter test. This scenario is
represented by J, K, L and M in Figure 5-46.
If the DUT is not a relatively simple device (for
example, a microprocessor), the Silicon Nails test
strategy is not recommended. One reason may be that
too many vectors would be needed to test the device.
Another case in which Silicon Nails testing may not be
optimal is when testing dynamic devices. When a
dynamic device receives vectors too slowly, the device
may not retain its internal memory status and tests will
appear to fail.
UPDATE-DR. At the same time, the vectors are changed

on the probed nodes driver.
During CAPTURE-DR, the output from the DUT is
captured on the silicon boundary-scan receivers. At the
same time, the probed node's receiver is turned on so the
software can do a compare. The probed node's data is
compared directly, but the boundary-scan receivers' data
must be shifted out.
The following failure messages show the actual
messages received when the Silicon Nails test and the
nail test are separately written tests.
Example 5-11 shows the Silicon Nails test failing a
silicon node.
Figure 5-47 shows the portion of the device being
tested.
How MSPD Coordinates Testing on Devices with

Silicon-Nails and Physical Probes
Often, a device, such as u7 shown in Figure 5-46, will
have both Silicon Nails and physical probes connected
to it. When your Silicon Nails test is generated, mspd
writes the test so that the testing of Silicon Nailed nodes
(silicon nodes) is coordinated with the testing of nodes
assigned physical probes (probed nodes).
Test patterns for the silicon node drivers are scanned in
to the appropriate drivers and presented during
Boundary-Scan Guide
5-135
Example 5-11 Silicon Nails test failing a silicon node
u6a HAS FAILED

SILICON NAIL FAILURE DETECTED FOR TEST
Failing Vector #: 498 (message follows)
Silicon Nail Test failed scanned output:
Vector 4 of pre-serialized test.
----------------------------------------Failed Boundary-Scan frame cell 11
at u1.15,
observing node: U6_3,
connected to pins
u1.15 u6.3
In this example:
u6 is the test name
498 is the vector number of the serialized test
4 is the vector number of ITL vectors
cell 11 is the failing Boundary-Scan cell
u1.15 is the B-Scan pin with cell 11 on pin 15
U6_3 is the node connected to pins u1.15 and u6_3.
Example 5-12 shows a test failing at a nailed node.
Boundary-Scan Guide
5-136
Example 5-12 Test failing at a nailed node
u6 HAS FAILED
SILICON NAIL FAILURE DETECTED FOR TEST
Failing Vector #: 522 (message follows)
Silicon Nail Test failed nailed output:
Vector 3 of pre-serialized test.
----------------------------------------Opens on Output or Bidir Pins
U6.6
-----------------------------------------
Figure 5-47
B
U6
11
3
U6_3
6
522 is the vector number of the serialized test

3 is the vector number of ITL vectors
U6_6 is the node with opens on the output or bidirectional
pins
Testing Devices Using Silicon Nails
-Silicon Nails diagnostic test example

15
In this example:
On device U6, the nailed output pin, 6, has failed.
U1
B-Scan
Figure 5-29 on page 5-54 illustrates the test generation

process and shows you where Silicon Nails testing fits
in the process.
You can do functional testing on individual digital
devices as well as digital device clusters using the
Silicon Nails of a boundary-scan chain.
NOTE
Note that ITL file generation is automated only
for single devices/pin libraries, not clusters.
Boundary-Scan Guide
5-137
During normal test development, you use IPG Test

Consultant to move you through the process. Syntax and
an example Silicon Nails ITL source code are shown
later in InterconnectPlus Test Language (ITL) on
page 5-158 and VCL/ITL Pass-Thru Statements on
page 5-176. The resources for your Silicon Nails test
will be assigned just as they are for other tests, and the
test will be added to the final testplan.
Generating Tests for Single Devices
The ITL test file is automatically generated by the
software. The automatically generated Silicon Nails test
(ITL source file) will include the following:
Description of the chain used for the Silicon Nails

test
Disabling information
Nodes and silicon nodes
pcf ordering
Test Vectors
NOTE
The testorder file and the testplan are also automatically

updated by the software. The test generation process is
as follows:
If you have a setup library, add vectors to the library,
then re-run IPG Test Consultant.
pcf Assignment Order
When writing test libraries for Silicon Nails, the pcf

assignment order determines the column order for the
ITL. The order of the pcf values generated in a Silicon
Nails test is based on the order of the assign statements
in the library source code used to generate the test. To
preserve your original statement order, you must edit the
library test syntax and assignment statements in a
specific order.
NOTE
There can be more than one pcf statement in your
library source code.
As shown in Example 5-13, the library source code is
used to generate the Silicon Nails Test.
A setup-only vector is generated if no test vectors

are found, if you only have a setup library (to
generate the fixture requirements file), or if all
library vectors are commented out.
Boundary-Scan Guide
5-138
Example 5-13 Library source code and Silicon Nails test

! Library source
assign
assign
assign
assign
assign
assign
DIR_1 to pins 1
OE_1_bar to pins 2
A1_1
to pins 3
A1_0
to pins 4
B1_1
to pins 5
B1_0
to pins 6
pcf order OE_1_bar,DIR_1,A1_0,A1_1,B1_0,B1_1

unit "TEST_ALL_A2B"
pcf
"0001LH" ! see order above
"0110HL"
end pcf
end unit
! Silicon Nail Test
nodes
node "NDIR_1" test "u13.1"
silicon node "NOE_1_bar" test "u13.2", "u23.U10"
silicon node "NA1_0" test "u13.4", "u23.V9"
silicon node "NA1_1" test "u13.3", "u23.U9"
silicon node "NB1_0" test "u13.6", "u23.V8"
silicon node "NB1_1" test "u13.5", "u23.U8"
inputs "NDIR_1"
inputs "NOE_1_bar"
bidirectionals "NA1_0"
bidirectionals "NB1_0"
Boundary-Scan Guide
5-139
pcf order statements
pcf order is nodes
pcf order is nodes
pcf order is nodes
pcf order is nodes
pcf order is nodes
pcf order is nodes
"NDIR_1"
"NOE_1_bar"
"NA1_1"
"NA1_0"
"NB1_1"
"NB1_0"
unit "TEST_ALL_A2B"
pcf
"0010HL" ! see order above
"1001LH"
end pcf
end unit
end nodes
NOTE
In Example 5-13 on page 5-139, the pcf order is
the same as the order of the assign statements in
the library file.
2 Arrange the assign statements in the library source to

match the pcf order statement.
Using the library source code, shown in Example 5-13,
the re-ordered code would look like that shown in
Example 5-14.
In Example 5-13 on page 5-139, the values in the pcf

statement are different in the two sources.
To preserve the pcf order in a Silicon Nails test, you
would do the following:
1 Edit the library source code.
Boundary-Scan Guide
5-140
Example 5-14 Re-ordered code

! Library source
assign
assign
OE_1_bar to pins 2
DIR_1 to pins 1
assign
assign
A1_0
A1_1
to pins 4
to pins 3
assign
assign
B1_0
B1_1
to pins 6
to pins 5
pcf order OE_1_bar,DIR_1,A1_0,A1_1,B1_0,B1_1

unit "TEST_ALL_A2B"
pcf
"0110HL"
end pcf
end unit
! Using this library source, the Silicon Nails Test would now be:
nodes
node "NDIR_1" test "u13.1"
silicon node "NOE_1_bar" test "u13.2", "u23.U10"
silicon node "NA1_0" test "u13.4", "u23.V9"
silicon node "NA1_1" test "u13.3", "u23.U9"
silicon node "NB1_0" test "u13.6", "u23.V8"
silicon node "NB1_1" test "u13.5", "u23.U8"
inputs "NDIR_1"
inputs "NOE_1_bar"
Boundary-Scan Guide
5-141
! the pcf order is the same as the assign statements in the library file.
pcf
pcf
pcf
pcf
pcf
pcf
order
order
order
order
order
order
is
is
is
is
is
is
nodes
nodes
nodes
nodes
nodes
nodes
"NOE_1_bar"
"NDIR_1"
"NA1_0"
"NA1_1"
"NB1_0"
"NB1_1"
! the pcf vectors match the pcf vectors in the library source
unit "TEST_ALL_A2B"
pcf
"0110HL"
end pcf
end unit
end nodes
NOTE
In Example 5-14 on page 5-141, the values in the
pcf statements are the same as in the two sources.
Adding Vectors to a Silicon Nails Test
Before Silicon Nails tests were automated, a test
developer would debug an in-circuit digital test (with
vectors removed by IPG) by editing the test source file
Boundary-Scan Guide
and uncommenting the section of the source that was to

be added. This was a useful form of debugging since
many of the library source files are independent of
topology conflicts.
With automated Silicon Nails testing, the digital source
file no longer exists. A digital library is provided, which
is exercised into an ITL file. This ITL file cannot be
modified in a similar fashion as the digital source file.
5-142
NOTE
If the ITL file were modified like the digital
source file, you would have a Silicon Nails test
that has no useful information for testing that
device.
ITL file) and u5.vtf (the VCL file). The original

u5 ITL file will not be touched until the
integrate option is executed to join the files.
The normal backup scheme allows for multiple
copies of the all files, including the itl and vcl
intermediate files
3 Edit the intermediate files as needed.
Automated Silicon Nails now provides you with two

intermediate files:
ITL declaration file (.itl)
VCL source file (.vtf)
If the node information is modified, it will need

to be modified in both intermediate files.
4 To join the files and generate the final ITL file, type
ipg on "u5";integrate
Both files are generated by IPG and assist you in

debugging Silicon Nails tests. The test developer will
need to edit the VCL source file similarly to how an
in-circuit digital test is edited.
The process is as follows:
1 In a BT-Basic window, access the ITL and VCL files
through the ipg on statement.
This statement has two options for separating and
joining the ITL and VCL files.
2 To separate and generate both the ITL and VCL files,
type
ipg on "u5";separate
The separate option will generate two files in

the digital directory. These files are u5.itl (the
Boundary-Scan Guide
5-143
Example 5-15 Automated Silicon Nails debug

+5V
+5V
1 VCC
GND 2
U1
A 7
U3
U1-7
bs005
4 In2
B 8
VCC OE 6
In1
lb005
U1-8
TDO 6
TDI
TMS
3
TCK
4
+5V
1 VCC
1K
bs001
Output 5
U3-5
5
U1-TDO
GND 2
U2
7 A
Gnd
2
U1-TDI
U3-6
TDI
TDO 6
TMS
3
TCK
4
U2-TDO
U1-TCK
U1-TMS
Example 5-15 shows a simple device U3 as a 2-input

device with a single output controlled by an output
enabled line OE. OE is tied low through a 1k-ohm
resistor and is inaccessible. The chain U1_U2 is used to
test device U3.
Example 5-16 shows an how the ITL file generated by
IPG would look for this device.
Boundary-Scan Guide
5-144
Example 5-16 ITL file generated by IPG U3

! IPG: rev 04.00u2 Wed Mar 28 16:51:12 2001
silicon nail "u3"
!IPG: User may add option statements here if needed.
family "TTL"
chain "u1_u2"
tdi "U1-TDI"
tdo "U2-TDO"
tms "U1-TMS"
tck "U1-TCK"
devices
"u1", "custom_lib/bs005", "DIP", no
end devices
end chain
!IPG: User may add VCL pass-through statements here if needed.
nodes
silicon node "U1-7" test "u3.3", "u1.7"
!IPG: NO PROBE node "U3-6" test "u3.6"
inputs "U1-8"
inputs "U1-7"
outputs "U3-5"
set terminators to on
pcf order is nodes "U1-7"
Boundary-Scan Guide
5-145

unit
pcf
"ZZX" !vector "Default"
end pcf
end unit
end nodes
end silicon nail
As is shown in the original file, node U3-6 is

inaccessible. This means that all of the vectors are
commented, leaving a default vector.
Example 5-17 on page 5-147 and Example 5-18 on
page 5-148 show how the files looks after running ipg
on u3; separate from BT-Basic.
Boundary-Scan Guide
5-146
Example 5-17 After separating files U3.itl

! IPG: rev 04.00u2 Wed Mar 28 16:51:44 2001
silicon nail "u3"
family "TTL"
chain "u1_u2"
tdi "U1-TDI"
tdo "U2-TDO"
tms "U1-TMS"
tck "U1-TCK"
devices
end devices
end chain

nodes
inputs "U1-8"
inputs "U1-7"
outputs "U3-5"
and VCL file (u3.vtf) are generated:
Boundary-Scan Guide
5-147
Example 5-18 After separating files U3.itf

! IPG: rev 04.00u2 Wed Mar 28 16:51:44 2001
!
LB005
!
Single input, single output, single disable, inverting
!
Single condition state
combinatorial
default device "u3"
assign VCC
to nodes *
assign GND
to nodes *
assign Ins
assign Out
to nodes "U1-7", "U1-8"

to nodes "U3-5"
assign Enable to nodes *

power VCC, GND
family TTL
inputs
outputs
Ins, Enable
Out
disable Out with Enable to "1"

vector V1
set Ins
to "11"
set Out
to "1"
set Enable to "0"
end vector
vector V2
Boundary-Scan Guide
5-148
set Ins
to "01"
set Out
to "0"
set Enable to "0"
end vector
vector V3
set Ins
to "10"
set Out
to "0"
set Enable to "0"
end vector
vector V4
set Ins
to "11"
set Out
to "0"
set Enable to "0"
end vector
unit
!IPG: Pin 6 is not
!*IPG* execute V1
!IPG: Pin 6 is not
!*IPG* execute V2
!IPG: Pin 6 is not
!*IPG* execute V3
!IPG: Pin 6 is not
!*IPG* execute V4
execute V1
execute V2
execute V3
execute V4
end unit
!
accessible.
accessible.
accessible.
accessible.
End of Test
Boundary-Scan Guide
5-149
The entries shown in red are changes to the file to allow

the vectors to be generated. After the command ipg on
U3;integrate is run form BT-Basic, the final
version of the ITL file U3 is shown (see Example 5-19).
Boundary-Scan Guide
5-150
Example 5-19
! IPG: rev 04.00u2 Wed Mar 28 16:51:44 2001
silicon nail "u3"
family "TTL"
chain "u1_u2"
tdi "U1-TDI"
tdo "U2-TDO"
tms "U1-TMS"
tck "U1-TCK"
devices
end devices
end chain

nodes
inputs "U1-8"
inputs "U1-7"
outputs "U3-5"
Boundary-Scan Guide
5-151

unit
pcf
"11H"
"01L"
"10L"
"11L"
end pcf
end unit
!vector
!vector
!vector
!vector
1
2
3
4
"V1"
"V2"
"V3"
"V4"
end nodes
end silicon nail
As shown in Example 5-19, all vectors have now been

generated for this test.
NOTE
The test developer must generate any additional
information that may be required. If additional
nodes are added to the ITL and VCL file, the
fixture files should be modified to ensure that any
resources deceived by adding nodes are not used
or will be used in the future.
Boundary-Scan Guide
NOTE
There is no source generation in the integrate
phase of the process in IPG. There is no additional
coverage information generated for these devices.
Writing a Silicon Nails Cluster Test
Clusters are tested just as they are during standard
functional testing, except that one or more physical
probes are eliminated. Figure 5-48 illustrates this
function. For more information about cluster testing,
refer to Digital Theory & Testing on page 1-1.
5-152
Figure 5-48
Testing devices within clusters
TD1
TDO
If you know that you will add Silicon Nails tests to your
board test, you should run IPG Test Consultant in
interactive mode. When you reach the Generate Tests
Using IPG step of this process, select Do and Stop. Then,
open a BT-BASIC window and write the ITL source file
for your test. Remember that you must include all
disabling and node information. Syntax and an example
Silicon Nails ITL source code are shown later in
InterconnectPlus Test Language (ITL) on page 5-158.
Boundary-Scan Guide
When you have written and compiled the test, you can
manually add pertinent test information to your testplan
by editing the testorder file. (Enter test scan for your
Silicon Nails test. No special syntax is required.) The
test file must be saved in your board's digital directory.
After you have edited the testorder file, close the
BT-BASIC window and return to IPG Test Consultant.
Continue with the Generate testplan step. The resources
5-153
for your Silicon Nails test will be assigned just as they

are for other tests, and the test will be added to the final
testplan.
Evaluating Candidate Devices for Silicon Nails

Testing
Making the right decision about using Silicon Nails
requires you to carefully examine the environment in
which you will test candidate devices.
There is still value in using a Silicon Nails test even
when all nodes are nailed. A Silicon Nails test can
contain embedded disabling processes that are more
robust than non-embedded Boundary-Scan disabling.
Cons of Using Silicon Nails

Early implementation of Silicon Nail tests have
identified several potential problems with this test
strategy. Some of these problems can be as minor as
having to modify library tests, while others could result
in failures in the field. This section describes some of
these problems in detail.
First, for a 7400 component (four NAND gates), the two
input pins of the same gate are shorted together, as
illustrated in
Pros of Using Silicon Nails

Using Silicon Nails will give you access to devices or
clusters where probes cannot be placed due to physical
restrictions. The pros of using Silicon Nails testing
include:
Fewer test resources needed
Fixture is less expensive to build
No capacitive loading on nodes
Ability to perform a test that otherwise might be

impossible
Boundary-Scan Guide
5-154
Figure 5-49
.Shorted inputs to a NAND gate could go undetected.
A test would PASS in spite of the defect. Using Table

5-11, you can examine the reason for this.
Table 5-11 Truth Table for a 2-input NAND Gate
Pin 1
Pin 2
Pin 3
Boundary-Scan Guide
A 2-input NAND gate has four possible combinations.

When both inputs are high (11) or both inputs are low
(00), the short does not create a conflict. When the two
inputs are driven to opposite states (01 and 10) the
output is expected to be high. To create a failure on the
output, both inputs must go over logic level 1. If that is
not the case, the NAND gate will show a correct
response.
The problem with this case is that it is also likely to pass
a system test and be shipped to the customer. However,
the two outputs are fighting each other when they are in
5-155
opposite states. This could result in a failure where it is

most expensive to repair: in the field.
For example, to test the output enable signal of a simple

buffer IC:
A limitation of Silicon Nails testing is the low, real

vector application rate to the DUT. For example,
running TDI with a rate of 5 MHz through a chain of
over 1,000 cells results in less than a 5 kHz real vector
application rate. This can be a problem if you are testing
dynamic components.
1 First, enable the outputs and pass 0s and 1s through

the buffer.
Another concern with this approach is that a

conventional component might have one input accessed
through a physical probe requiring that an upstream
device be backdriven. Because of the long test times, a
backdrive problem could occur.
A summary of the issues to consider include:
This vector should show 0s on the output.

The next vector disables the output and expects
to see the output go high. This is due to the
drivers being tri-stated and the pull-ups
creating the 1s.
If the outputs are tested with Silicon Nail receivers,
this last vector will probably fail because the pull-up
function is missing.
manual adjustment of the in-circuit library
fault detection limitations
Ensuring a Successful Implementation
limitations because of dynamic parts
potential backdrive problems
vector explosion (parallel test length multiplied by

Boundary Register length).
Carefully consider the issues discussed above before

you apply the Silicon Nails test strategy. Use physical
probes on conventional components where possible. If
you do use Silicon Nails strategy, you should ask
yourself these questions about your board:
In addition, a Silicon Nails test may not work correctly

when it is dependent upon 3070 resources that do not
exist when Silicon resources are substituted. An
illustration of this would be a test that is dependent on
3070 receiver loads (controlled by set load statements)
in order to work.
2 Then, set the data to (for example) all 0s and set the
receiver loads to pull the outputs up to 1s.
Boundary-Scan Guide
Do the nodes from which you want to remove

probes from connect to dynamic parts?
Are any of the candidate nodes connected to

analog parts you want to measure?
5-156
Are any of the candidate nodes connected to

devices that might present backdrive problems?
Is the pre-serialized test long (see discussion

below) or are there elements such as homing
sequences or timing sets in the pre-serialized test?
Figure 5-50
Pin State
Vector 1:
These elements will cause an IPG error. IPG will

continue to run, but a functional Silicon Nails test
will be not generated.
If you answer yes to any of these questions, you should
probably not use Silicon Nails testing on the affected
nodes.
Serialization, test length, and probe placement
Serialization of vectors is a necessary part of Silicon
Nails testing, although it increases test length. However,
strategic placement of one or more physical probes
(when possible) on a busy node can sometimes reduce
serialization and test length. Consider the following
example:
Boundary-Scan Guide
Placing probes on busy pins
(Silicon Node)
(Silicon Node)
(Nailed Node)
(Silicon Node)
(Silicon Node)
(Nailed Node)
Vector 2:
In this example, serialization is not necessary between

the first and second nodes, because there is no change of
state from Vector 1 to Vector 2. Placement of a physical
nail (when possible) at this busy node could eliminate
serialization of the second vector and decrease test
length.
5-157
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 IPG and are an input to
the MSPD serializer. These files contain the information
that describes powered shorts, interconnect, buswire,
connect, and (optionally) Silicon Nails testing for your
boundary-scan devices.
ITL Statement Descriptions and Syntax

This section contains all the statements used by ITL.
The statements are dealt with in alphabetical order;
however, you should note that ITL has a mandatory
structure, which is described (and shown by example)
below. Each description contains the statement's syntax,
descriptions of key parameters, and examples of how to
use the statement.
NOTE
NOTE
In the past, Silicon Nails tests had to be written

manually using ITL, then incorporated manually
into your testplan. An optional product automates
this ITL generation from library tests. For more
information, refer to Silicon Nails Test Strategy
on page 5-130.
Note that only new ITL statements are presented

here in detail. Statements that have been borrowed
from VCL are presented in the Syntax Reference
documentation. Both types are listed below.
New ITL Statements
The following pages describe the ITL syntax and

provide example files that were used to produce the
boundary-scan tests for the sample circuit found at the
end of this chapter.
A list of statements created specifically for ITL is

shown below. The descriptions for these statements can
be found on the following pages. The statements
include:
Example 5-20
tdi
tdo
tms
tck
trst
node
test
chain
Boundary-Scan Guide
devices
disables
nodes
end chain
end devices
end disables
end nodes
connect
fixed
silicon node
silicon nail
buswire
checkerboard test inputs only

custom
ground bounce suppression
disable
debug
interconnect powered shorts
5-158
ITL Statements Borrowed from VCL

A list of statements borrowed from VCL for use in ITL
is shown below. These statements behave similarly to
VCL. The descriptions for these statements can be
found in the Syntax Reference documentation. The
statements include:
unit
end unit pcf
inputs outputs
repeat end repeat
end pcf
bidirectional
pcf order is nodes
For more detail on this syntax statement see chain

(ITL) of the Syntax Reference documentation.
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
buswire (ITL)
connect (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.
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)
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.
Boundary-Scan Guide
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 type to be one to
debug the boundary scan chain. Normally, this is just
used in test development and not in production.
5-159
devices (ITL)
end chain (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.
The end chain statement marks the end of a chain block.

Refer to the chains statement for more information.
For more detail on this syntax statement see end chain
For more detail on this syntax statement see devices

end devices (ITL)

disable (ITL)
The disable statement declares the test type to be one to
disable 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.
The end devices statement marks the end of a devices

block. Refer to the devices statement for more
information.
For more detail on this syntax statement see end devices
end disables (ITL)

The end disables statement marks the end of a disables
block. Refer to the disables statement for more
information.
For more detail on this syntax statement see end
disables (ITL) of the Syntax Reference documentation.
For more detail on this syntax statement see disables

(ITL) of the Syntax Reference documentation
Boundary-Scan Guide
5-160
end nodes (ITL)

The end nodes statement marks the end of a nodes
block. Refer to the nodes statement for more
information.
For more detail on this syntax statement see end nodes
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 5-165
for sample ITL files.
For more detail on this syntax statement see end <test
type> (ITL) of the Syntax Reference documentation.
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
Boundary-Scan Guide
the state to either high or low and uncomment the

statement.
For more detail on this syntax statement see fixed (ITL)
of the Syntax Reference documentation.
ground bounce suppression (ITL)

The ground bounce suppression statement can be used
to change the test flow at 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.
5-161
For more detail on this syntax statement see node (ITL)

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 more detail on this syntax statement see nodes
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
tests ITL file had to be manually created; newer,
optional software can automatically create this file from
a library test.
silicon node (ITL)

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 more detail on this syntax statement see
performance port of the Syntax Reference
documentation.
Boundary-Scan Guide
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 more detail on this syntax statement see silicon
node (ITL) of the Syntax Reference documentation.
5-162
tck (ITL)
test (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.
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 more detail on this syntax statement see tck (ITL)

For more detail on this syntax statement see test (ITL)

tdi (ITL)
test inputs only (ITL)
The tdi statement identifies the test data in node of the

using the tdi statement.
tdo (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.
The tdo statement identifies the test data out node of the
using the tdo statement.
tms (ITL)
For more detail on this syntax statement see tdi (ITL) of

the Syntax Reference documentation.
For more detail on this syntax statement see tdo (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 more detail on this syntax statement see tms (ITL)
Boundary-Scan Guide
5-163
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 more detail on this syntax statement see trst (ITL)
Boundary-Scan Guide
5-164
ITL Syntax Structure
This section describes the structure for the

InterconnectPlus Test Language (ITL). Examples follow
the general syntax structure shown below. Parameters
are shown in brackets < >.
Boundary-Scan Guide
5-165
Example 5-21
<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> 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>
Boundary-Scan Guide
5-166
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>
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
The following pages contain example ITL source files

for sample circuit found at the end of this chapter. The
first example, shown below, is an ITL source file for a
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.
Boundary-Scan Guide
5-167
Example 5-22
powered shorts "u1_u4_ps"
chain "u1_u4"
tdi "TDI"
tdo "TDO"
tms "TMS"
tck "TCK"
devices
"u1", "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)
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"
Boundary-Scan Guide
5-168

!Untestable (Inaccessible): U3_TDO, u3.11 (near u3.10)
!Untestable (Disable): IN_26, u5.10 (near u5.11)
end nodes
end powered shorts
The following ITL source file is for the u1_u4

interconnect test.
Boundary-Scan Guide
5-169
Example 5-23
interconnect"u1_u4"
chain "u1_u4"
tdi "TDI"
tdo "TDO"
tms "TMS"
tck "TCK"
devices
"u1", "../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_5" test "u1.5","u2.20","u4.20"
Boundary-Scan Guide
5-170

end nodes
end interconnect
The following ITL source file is for the u1_u4 buswire

test.
Example 5-24
buswire"u1_u4_bus"
chain "u1_u4"
tdi "TDI"
tdo "TDO"
tms "TMS"
tck "TCK"
devices
end devices
end chain
nodes
end nodes
end buswire
The following ITL source file is for one connect test, u2,
of the u1_u4 chain. Connect test ITL source files for the
Boundary-Scan Guide
other devicesu1, u3, and u4are similar.
5-171
Example 5-25
connect "u2"
chain "u1_u4"
tdi "TDI"
tdo "TDO"
tms "TMS"
tck "TCK"
devices
"u1", "../demo_original/custom/74bct8374",
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"
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_5"
!IPG: node "U1_4"
!IPG: node "U1_3"
Boundary-Scan Guide
"DW_PACKAGE",
"DW_PACKAGE",
"DW_PACKAGE",
"DW_PACKAGE",
no
no
no
no
5-172
!IPG: node "U1_2"

end connect
Silicon Nails Test Example
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.
Boundary-Scan Guide
5-173
Example 5-26 ITL Source File for Silicon Nails Test

silicon nail "u6"
chain "chain_demo"
tdi "TDI"
tdo "TDO"
tms "TMS"
tck "TCK"
devices
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"
node "OUT_01" test "U6.6"
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"
Boundary-Scan Guide
5-174
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"
"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
Boundary-Scan Guide
5-175
VCL/ITL Pass-Thru
Statements
The following information covers the VCL syntax

available to be specified in the Interconnect Test
Language (ITL). This syntax is not used by the ITL
compiler for test generation algorithmic control. Rather,
these statements are just placed in the final VCL file.
set slew rate
set terminators
warning
on failure report
For complete syntax information on each statement, see

the Syntax Reference documentation.
Syntax Support for Pass-Thru Statements

There is a new category in syntax support for
pass-through statements. Pass thru statements are VCL
statements that are allowed in the ITL code to allow
information to pass directly into VCL with out being
changed by the ITL compiler (MSPD). These statements
can be automatically placed by the IPG test generation
process. They may also be entered manually. The ITL
compiler (MSPD) has been modified to handle these
new commands. These statements include:
disable device
conditioned device
vector cycle
receive delay
set load
set ref
Boundary-Scan Guide
disabled device (VCL) (ITL)

The disabled device (VCL) (ITL) statements are placed by
the program generator in the Declaration section of an
executable test to indicate which devices are disabled
while that test is being executed.
For more detail on this syntax statement see disabled
device (VCL) (ITL) of the Syntax Reference
documentation.
conditioned device (VCL) (ITL)

The program generator places conditioned device (VCL)
(ITL) statements in a tests Declaration section to indicate
which devices are conditioned while that 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,
5-176
you should modify the associated conditioned device

function accordingly and recompile the test.
For more detail on this syntax statement see
conditioned device (VCL) (ITL) of the Syntax
Reference documentation.
vector cycle (VCL) (ITL)

The vector cycle (VCL) (ITL) 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
Chapter 3, Advanced Testing With VCL..
For more detail on this syntax statement see receive

delay (VCL) (ITL) of the Syntax Reference
documentation.
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 more detail on this syntax statement see set load
(VCL) (ITL) of the Syntax Reference documentation.
set ref (VCL) (ITL)
For more detail on this syntax statement see vector

cycle (VCL) (ITL) of the Syntax Reference
documentation.
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.
receive delay (VCL) (ITL)
For more detail on this syntax statement see set ref

(VCL) (ITL) of the Syntax Reference documentation.
The receive delay (VCL) (ITL) 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.
set slew rate (VCL) (ITL)
Boundary-Scan Guide
The set slew rate statement is optional; you can use it in

the Declaration section of a VCL library test to change
5-177
the slew rate on selected drivers (inputs and

bidirectional pins) to the board under test.
For more detail on this syntax statement see set slew
rate (VCL) (ITL) in the Syntax Reference
documentation.
set terminators (VCL) (ITL)

The set terminators statement manipulates the
diode-clamp terminators in the receiver circuits on
HybridPlus pin cards. These clamps can be used to
enhance high-speed signal quality. The statement can
connect terminators (on in the syntax) or disconnect
them (off).
For more detail on this syntax statement see set
terminators (VCL) (ITL) in the Syntax Reference
documentation.
warning (VCL) (ITL)
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 more detail on this syntax statement see warning
(VCL) (ITL) in the Syntax Reference documentation.
on failure report (VCL) (ITL)

The on failure report (VCL) (ITL) function enables you to
specify a message that will be sent to 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 more detail on this syntax statement see on failure
report (VCL) (ITL) in the Syntax Reference
documentation.
The warning (VCL) (ITL) 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.
Boundary-Scan Guide
5-178
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 listed
below. They are followed by brief descriptions and
examples. For more detailed information about these
statements, refer to the Syntax Reference
documentations.
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
Boundary-Scan Guide
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
5-179
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.
Items that appear in the following partial example
(Example 5-27), the VCL source file shows where each
of these statements and the commented form of the test
dictionary would appear in an actual file.
Boundary-Scan Guide
5-180
Example 5-27 VCL source file

!!!!
6
0
1 698520684 Ve2f1
! Hewlett-Packard Advanced Boundary-Scan Software [920116]
! 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
!! Writing code for Agilent 3070 family.
! 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
Boundary-Scan Guide
5-181
pcf order Parallel is TCK, TMS, TDI, TDO , N000, N001, N002, N003
!Column-to-Node Map, Nodes 1 to 8
!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 " Device U4 has failed,"
. . .
compress
frame 0 1
pcf
"00ZXZZXX"!0+0
use pcf order Scan
"10ZX"
"00ZX"!1
"10ZX"
"00ZX"!2
. . .
"101X"
"01ZL"!17
"11ZX"!Exit1-DR
Boundary-Scan Guide
5-182
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
"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
! 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'
Boundary-Scan Guide
5-183
Summary: Sample
Test Generation
Session
This section provides a step-by-step summary of the

process used to generate tests for your boundary-scan
chains. During this session, you will use files for the
example circuit found at the end of this chapter. The
only tool that you need to run this session is an 3070
Series II workstation.
NOTE
If you wish to run the test generated from this
sample session, you will need a playpen fixture
and the boundary-scan demo board.
1 Start IPG Test Consultant so that you have the
starting point (the interface) that you will need to
complete the steps of this sample session.
2 Before you begin this session, ensure that the
example directory is properly prepared. Open a
BT-BASIC window from the Programs menu of the
IPG Test Consultant interface. Change to the
example directory by typing the following on the
command line:
msi "/3070/standard/tutorial/bscan"
To prepare the example directory, demo_circuit, type

the following on the command line:
Boundary-Scan Guide
get "init_demo"
This program removes all files from the demo_circuit

directory, then places the appropriate board and
configuration files needed to complete the steps of
the sample session. To execute this program, type the
following on the command line:
run
NOTE
To protect the integrity of the files needed to run
sample programming sessions, do not work within
the demo_original directory.
Keep the BT-BASIC window in your workspace for
later use.
3 Remember that InterconnectPlus is an option for the
3070 Series II of board test systems. For this product
to function, you must add the statement
enable advanced boundary scan
to your board config file. For this session, the config

file is in the demo_original directory. Use the
BT-BASIC window to verify that this statement is in
your board config file. Remove (iconify) the
BT-BASIC window from the workspace.
5-184
4 Acquire (or write) complete and accurate BSDL files

for each boundary-scan device type in your chain.
Remember that complete and accurate files are
essential to successful implementation of a
boundary-scan test. Refer to Understanding the
Contents of the BSDL File on page 5-63 for details.
These files are treated like normal library files and
are typically stored in the bsdl directory with the
following pathname:
/3070/library/supplemental/bsdl
For this example session, we will use the following

directory and pathname for the BSDL files needed:
/3070/standard/tutorial/bscan/demo_original/c
ustom
5 Describe your chain's devices and associated

pathnames using Board Consultant. Refer to
Describing Your Boundary-Scan Device on
page 5-55 for details.
Start Board Consultant from the Programs menu of
the IPG Test Consultant interface. When the Board
Consultant interface appears, click Load Existing
Board. The Board Specification Form appears. Enter
the following pathname in the Board Directory field:
Boundary-Scan Guide
/3070/standard/tutorial/bscan/demo_circuit
Click Load Board. The software informs you that it is

loading the board file.
Click View/Edit Library Data in the flowchart. A list
will appear at the bottom of the flowchart. Click
Enter Library Paths. The Library Paths Form appears.
The pathname ../demo_original/custom should
appear in the form. If not, add this pathname, then
click Update. Click Close to remove this form.
Click View/Edit Board Description in the flowchart. A
new list appears at the bottom of the flowchart. Click
Enter Pin Library. The Device Entry Form appears.
Place the cursor in the Designator field and click
once, then enter u1. Next, click the Find button. The
information describing u1 will be placed in each
field. You would use this form to describe new
devices or to change descriptions of existing devices
when you create an original board. For this session,
you can examine the entries for the devices on this
board, but do not change any of the entries. Select
Actions > Close to leave this form.
5-185
NOTE
You can also select the Maximize option if you
wish to view the entire form.
Click Final Compile/Verify in the flowchart. A new list
will appear at the bottom of the flowchart. Click
Compile board File. Click OK when the Confirm
Message window appears. Repeat these steps for the
board_xy file. Then click Save Board Files in the list
at the bottom of the flowchart.
Select File > Exit to leave Board Consultant.
6 Follow the standard test generation procedures for
developing a board test using IPG Test Consultant.
In the IPG Test Consultant interface, change to the
working directory:
/3070/standard/tutorial/bscan/demo_circuit
Select Actions > Develop Board Test. Then select

Actions > Begin Batch Development. You can watch
the IPG Test Consultant message window as the
software executes the test generation programs. This
process will take several minutes to complete.
been developed. From here, you would continue as

you would with any other board test.
A digital directory was created and ITL files created
by IPG were placed in this directory, along with other
digital test files. Copies of the ITL files are found in
InterconnectPlus Test Language (ITL) on
page 5-158. Portions of the VCL source code that are
pertinent to boundary-scan testing can be examined
in VCL Source Code For Chain Tests on
page 5-179. This includes a commented version of
the test dictionary (.x file). You can also use a
BT-BASIC window to examine the complete VCL
source for this test session.
You also have the option of developing custom tests
for your boundary-scan devices. These could include
such tests as BIST and INTEST, or Silicon Nails
tests. For more information about developing custom
tests, refer to Custom Boundary-Scan Tests on
page 5-51, and chapter 6, Multichip Scan Port
Driver and the MSPD Interface. Chapter 6 also
includes a sample session for developing INTEST for
the example circuit. For more information about
Silicon Nails tests, refer to Silicon Nails Test
Strategy on page 5-130.
When IPG has completed the test generation process,

you can examine the board directory
(/3070/standard/tutorial/bscan/demo_circuit) to see
that all files needed for your test and fixture have
Boundary-Scan Guide
5-186
Sample
Boundary-Scan
Device Chain
The following schematic diagram shows the example

circuit referred to in this chapter and in the sample test
generation session. The sample circuit is also referred to
by sections in chapter 6, Multichip Scan Port Driver
and the MSPD Interface.
If you have access to a playpen fixture and a
boundary-scan demo board, you can use the schematic
to prepare an actual demonstration of the boundary-scan
software features.
NOTE
You also have the option of building this demo
board by following the schematic. This should be
a viable option because of the simplicity of the
boards design
Boundary-Scan Guide
5-187

Bscan 05

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Bscan 05

Caricato da

Copyright:

Formati disponibili

5

Agilent Technologies 2002, 2003

Testing Boundary-Scan Device Chains

Introduction To Testing Device Chains, 5-3

Generating Tests For Boundary-Scan Chains, 5-53

Results Analysis Routine, 5-112

Debugging Boundary-Scan Tests, 5-120

Silicon Nails Automation, 5-128

InterconnectPlus Test Language (ITL), 5-158

VCL/ITL Pass-Thru Statements, 5-176

VCL Source Code For Chain Tests, 5-179

Summary: Sample Test Generation Session, 5-184

Sample Boundary-Scan Device Chain, 5-187

Chapter 5: Testing Boundary-Scan Device Chains

The next step toward full utilization of boundary-scan

Agilent Technologies 2002, 2003

This chapter describes InterconnectPlus, which is

Chapter 5: Testing Boundary-Scan Device Chains

A boundary-scan chain consists of two or more

A simple boundary-scan chain

Agilent Technologies 2002, 2003

Chapter 5: Testing Boundary-Scan Device Chains

Bit patterns can be shifted in through the initial TDI

All tests must be executed and diagnosed with

The diagnosis of some faults might be ambiguous.

Under certain circumstances, it might not be

devices in the chain have common TCK and TMS lines

This chapter explores the practical application of testing

Agilent Technologies 2002, 2003

Chapter 5: Testing Boundary-Scan Device Chains

Example of a chain of boundary-scan devices

Agilent Technologies 2002, 2003

Every device in the chain is always in the same TAP

example, Table 5-1 shows what the register lengths for

The registers for each device in the chain do not have to

Example register lengths

Chapter 5: Testing Boundary-Scan Device Chains

Example register lengths (continued)

Table 5-2 shows what the concatenated EXTEST

Example EXTEST instructions

Although the TAP states must be the same, the

Chapter 5: Testing Boundary-Scan Device Chains

Devices loaded with different instructions

Agilent Technologies 2002, 2003

BSDL file tells the software the length of the registers

Chapter 5: Testing Boundary-Scan Device Chains

allows you to label such a device as TAP-only so that its

Agilent Technologies 2002, 2003

Chapter 5: Testing Boundary-Scan Device Chains

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

TAP Override Form

Agilent Technologies 2002, 2003

chains. For example, Figure 5-5 shows a circuit where

Chapter 5: Testing Boundary-Scan Device Chains

A single boundary-scan chain split into two chains

As of software version B.03.00, there is a TAP Override

TAP Override Form

You invoke the TAP Override Form from a button on the

Agilent Technologies 2002, 2003

Chapter 5: Testing Boundary-Scan Device Chains

The TAP Override Form allows you to override any

Agilent Technologies 2002, 2003

TAP signal overrides button: device entry form