You are on page 1of 187

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.

© Agilent Technologies 2002, 2003

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

Chapter 5: Testing Boundary-Scan Device Chains

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

© Agilent Technologies 2002, 2003

Boundary-Scan Guide

5-3

Chapter 5: Testing Boundary-Scan Device Chains Bit patterns can be shifted in through the initial TDI connection (u1 in this case). and describes the process for developing an optimum test strategy for your board. For guidance on evaluating when to remove probes. and shifted out the final TDO connection (u4 in this case) for analysis. refer to Removing Physical Probes on page 5-104. While fault diagnosis using only the access to the boundary-scan chain is possible. ■ The diagnosis of some faults might be ambiguous. This chapter explores the practical application of testing boundary-scan chains. Theoretically. it might not be possible to isolate a failure to a specific device pin. however. there are several disadvantages to this type of testing. Among the disadvantages are: © Agilent Technologies 2002. devices in the chain have common TCK and TMS lines (TRST is optional for each device in the chain). ■ Under certain circumstances. ■ All tests must be executed and diagnosed with power applied. shifted through every device in the chain. and one on each of the controls lines TCK and TMS. 2003 Boundary-Scan Guide 5-4 . which leaves devices vulnerable to damage if shorts exist on the board. 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. Understand that practical application of boundary-scan technology neither requires nor implies that all possible probes be eliminated. Testing non-boundary-scan devices connected between boundary-scan devices can also be accomplished using these four probes. we still recommend that testhead access be provided whenever possible to ensure maximum fault coverage. one on the final TDO node. Employing boundary-scan technology provides you with the option to remove probes in many cases.

essentially. The registers for each device in the chain do not have to be the same length (IR or DR). 2003 Every device in the chain is always in the same TAP state: chips operate in parallel in boundary-scan mode. if u1 is in SHIFT-IR. example. For example. One shift cycle causes all devices to shift one bit. 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 . so are u2 and u3. Table 5-1 shows what the register lengths for the devices in Figure 5-2 could be. two long IR and DR registers.Chapter 5: Testing Boundary-Scan Device Chains Figure 5-2 Example of a chain of boundary-scan devices u1 u2 u3 TDO TDI TCK TMS TRST © Agilent Technologies 2002. The BSDL files tell the system the length of the registers in each device. These are added together to form. The instructions (bits) for the registers are also added together to control each register.

Shifting in a new set of instructions can change the active registers and therefore the length of the chain's Data Register. 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. using the instructions listed in Table 5-2. u1 will be in EXTEST.Chapter 5: Testing Boundary-Scan Device Chains 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. For example. you see in Figure 5-3 that if you shift in the pattern 0000011111111111111111. the instructions need not be. © Agilent Technologies 2002. 2003 Boundary-Scan Guide 5-6 . the length of the Data Register becomes 26 cells (u1 Boundary Register: 24 cells + u2/u3 Bypass Registers: 1 cell each). and u3 are in BYPASS. in this case. Note that. upon transition through UPDATE-IR. while u2.

in some way. for some reason. 2003 Boundary-Scan Guide BSDL file tells the software the length of the registers targeted for each instruction. affects the length of the data bits that must be shifted for a given set of tests. 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. however. InterconnectPlus software keeps track of these changes as you develop your chain test.Chapter 5: Testing Boundary-Scan Device Chains 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. or a device that. Keeping TAP-only Devices in the Chain A TAP-only device is a boundary-scan device that. the device's TAP and its BYPASS function operate properly. The information in the © Agilent Technologies 2002.1. in turn. This. does not fully comply with IEEE Standard 1449. does not operate properly with the rest of the boundary-scan chain. However. InterconnectPlus software 5-7 .

you could do only the interconnect tests associated with the smaller. © Agilent Technologies 2002. In this case. 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. if device u3 in Figure 5-4 were a TAP-only device. rather than two or more smaller chains. The alternative is to break these apart into two chains by specifying the device as non-compliant. For example. For more information about specifying a device as TAP-only or non-compliant. refer to Describing Your Boundary-Scan Device on page 5-55.Chapter 5: Testing Boundary-Scan Device Chains allows you to label such a device as TAP-only so that its Bypass Register can be used as part of the chain. you could keep this device in the chain to permit testing of the other five devices in the chain. individual chains. This results in a real loss in testing. 2003 Boundary-Scan Guide 5-8 . You could not test the circuitry that connects one smaller chain to the other without using physical probes.

InterconnectPlus software sees two distinct chains: a chain consisting of U1 and U2. TMS. U4. The InterconnectPlus software treats boundary-scan devices on opposite sides of such a split signal as separate © Agilent Technologies 2002.Chapter 5: Testing Boundary-Scan Device Chains 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. or a resistor with a value above the IPG Digital Resistance Threshold. and U5. 2003 Boundary-Scan Guide u6 TDO chains. For example. and a chain consisting of U3. TDO. 5-9 . The device may be a buffer. or TRST) will contain a device that causes the signal to be split into multiple node names. Figure 5-5 shows a circuit where the TMS and TCK lines have buffers. a logic level converter. TCK.

You would enter data in the TAP Override Form as Figure 5-5 show for devices U3.03. © Agilent Technologies 2002. 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. 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.Chapter 5: Testing Boundary-Scan Device Chains Figure 5-5 A single boundary-scan chain split into two chains As of software version B. and U5 to accommodate the chain Figure 5-4 shows. U4. Figure 5-6 TAP Override Form You invoke the TAP Override Form from a button on the Device Entry Form (Figure 5-6).00. 2003 Boundary-Scan Guide 5-10 .

However. For example. 2003 Boundary-Scan Guide Figure 5-7 TAP signal overrides button: device entry form 5-11 . © Agilent Technologies 2002. and you generally should not change TDO for any device but the last one in a chain. a TDI or TDO override is allowed between U2 and U3 of Figure 5-7. You may override TDI or TDO in the middle of a chain only if the chain would otherwise be seen as separate chains.Chapter 5: Testing Boundary-Scan Device Chains The TAP Override Form allows you to override any TAP signal node for any device being tested with InterconnectPlus. you generally should not change the TDI node for any device but the first one in a chain. but not allowed between U1 and U2 or U3 and U4.

02.00. you must make it look like one chain for the software.1. and you should refer to section Using Chain Override on page 5-12 for details on handling such situations. or later. allows you to override the board compiler’s view of the chain construction. as Figure 5-9 shows. If you have multiple connections. as shown in section 5. Using Chain Override Multiple TMS and TCK connections.1. If you intend for a configuration to look like a single chain. Software revision B. you can connect the TCK and TMS lines together inside the fixture. © Agilent Technologies 2002. makes the software treat the board as if it had two chains. providing a physical connection.3.Chapter 5: Testing Boundary-Scan Device Chains 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. 2003 Boundary-Scan Guide 5-12 .

Figure 5-10 is an example showing how the software could assume there were two chains. the software assumes two chains. With software revision B.Chapter 5: Testing Boundary-Scan Device Chains 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. or later. unless you refer back to the inputs of buffers A and B. This fact would show up in the IPG summary or in digital directories. 2003 Boundary-Scan Guide Chains on page 5-1. (See Testing Boundary-Scan Device © Agilent Technologies 2002.00. TCK output from buffer A goes to two devices (U1 and U2) in the chain. If you discover more chains than there actually are.02. you tell the software that there is only one chain.). you can examine a testability report from Board Consultant after data entry to see the chain structures found by the board compiler. By overriding. This flag can only be turned on for revision B (Series II) systems. Since these outputs are on two different nodes on device TCK/TMS pins. 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. you might discover that there are more tests generated than you have chains existing on the board. 5-13 . which is the case.

) TDO_TDI TDI U1 TCK TDO U2 TCK1 A TCK2 TMS1 TMS B 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. (A candidate for chain override. signals TCK1 and TCK2 as well as TMS1 and TMS2 are logically identical buffered signals coming from TCK and TMS. To put the two chains together with an override. In reality. u2_u2 TDI TDO_TDI © Agilent Technologies 2002. The compiler cannot know this so it splits the logical chain into two chains. 2003 Boundary-Scan Guide TDO TDO TCK TCK2 TMS TMS2 DEVICES u2. you first edit the global section of the board file to add the statement 5-14 .Chapter 5: Testing Boundary-Scan Device Chains Figure 5-10 Logical chain that will be treated as two chains.

with comments added to describe the syntax.o to generate a board file containing the chain(s) that the compiler found itself. refer to the Cards in the Testhead documentation. You must also ensure that the TMS and TCK lines are common to all devices in the chain. u2. The edited chain looks like Example 5-1.Chapter 5: Testing Boundary-Scan Device Chains Boundary Scan Chain Override ON to the global flag section. you can connect the two chains to form one larger chain. After saving and compiling. or assign general purpose (GP) relays to connect the TDO node of the first chain to the TDI node of the second. you can use list object on board. ". and Development–3. 2003 descriptions (at the end of the file) that describe the actual chain construction. Use a jumper wire within the fixture. 5-15 . © Agilent Technologies 2002. You must then go to the board file and edit in the chain Example 5-1 Edited chain BOUNDARY SCAN CHAINS ! Board key phrase u1_u2 ! <name of chain> followed by TAP signals TDI TDI ! TDI <node name> TDO TDO ! TDO <node name> TCK TCK ! TCK <node 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. Boundary-Scan Guide name> TMS TMS ! TMS <node name> DEVICES devices in the chain u1. nearest TDI ! now name ! first device ! last device nearest TDO. you can jumper these lines if they are not currently connected." terminated NOTE For more information about using GP relays.

© Agilent Technologies 2002. or other testing problems. This can result in overdriving difficulties.Chapter 5: Testing Boundary-Scan Device Chains 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. 2003 Boundary-Scan Guide 5-16 .

Chapter 5: Testing Boundary-Scan Device Chains Figure 5-12 Connecting a jumper to make a longer chain around non-compliant devices is not recommended u10 u11 TDI N. © Agilent Technologies 2002. however. This might seem like a reasonable solution. even if some interconnect test capability is lost. You can regain the loss by assigning physical probes to those nodes. 2003 Boundary-Scan Guide 5-17 . u13 u20 u21 TDO The dotted line shown above represents a jumper used to circumvent the non-compliant (NC) device. The best solution would be to do an ECO. it would be better to leave the chains separate. or modify the design prior to release. a closer study reveals that using a jumper does not disconnect the device's TAP from the circuit and the connected TDOs would fight. u13. The activity of this device during test will be unpredictable. In this case.C.

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. buswire. connect tests. 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.Unpowered © Agilent Technologies 2002. which minimizes potential damage to your board. Executing these tests should identify the majority of shorts that occur across physically accessed nodes. then Re-applied BIST.1-1990 required instruction set. whether or not testhead access is provided.Chapter 5: Testing Boundary-Scan Device Chains Table 5-3 InterconnectPlus Chain Testing InterconnectPlus software's chain testing comprises powered shorts. INTEST. Through the use of the IEEE 1149. interconnect. 2003 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. User Functions Boundary-Scan Interactive Board test sequence showing position of boundary-scan tests Sequence Type Method Board Test Sequence -. TAP integrity. The table also identifies which tests are automatically created by the boundary-scan software and which require test developer interaction. 5-18 . Sequence Table 5-3 provides you with an understanding of where these tests fit in your overall process. and the ability to do Silicon Nails1 testing.

and TAP nodes. TCK. testing stops. disable nodes. and power is removed from the board. This test checks primarily for shorts. testing stops. 5-19 .Chapter 5: Testing Boundary-Scan Device Chains Digital in-circuit tests are described in detail in the Test Methods: Digital documentation. 2003 TAP Integrity Test—Verifies that the Test Access Port (TAP) of all the boundary-scan devices in the Boundary-Scan Guide chain operate properly. BIST and INTEST are described in chapter 1 of this documentation. ■ Interconnect Test—Tests the connections from one boundary-scan device to the other boundary-scan devices in the chain. but most opens will also be detected. If this test fails. One powered shorts test is generated for each boundary-scan chain on the board. NOTE The exceptions are power and ground nodes. If this test fails. additional drivers might be required. those not selected are tested only as receivers. Silicon Nail test theory is discussed later in this chapter. Most shorts to TAP nodes are detected by integrity test ■ © Agilent Technologies 2002. This helps keep tests shorter. TDI) and one receiver (TDO). three drivers (TMS. 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 test fixes the direction that bidirectional cells are tested: those cells selected by the software as drivers are tested only as drivers. Interconnect tests require the use of only four testhead resources. and minimizes the potential for device damage. Shorts to power or ground are detected by interconnect test. Interconnect test attempts to use only one driver in the case of bussed nodes. helps diagnostics. 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. The primary purpose of this section is to examine the following tests: ■ Powered Shorts Test—Tests for solder shorts on the connections between boundary-scan nodes that do not have physical access and conventional nodes of any other type that do have physical access. prevents bus fights. and power is removed from the board. NOTE If device disabling or conditioning is necessary for other devices on the board.

A commented version of this file is documented at the end of the VCL source file. If one of the drivers was disconnected from the node. For these reasons. it would go undetected. . buswire test turns drivers on one at a time to check for opens. 2003 For larger devices that exceed the available number of testhead resources—for example. ■ Vector Control Language (VCL) source file—A permanent. ■ Buswire Test—Created when bussed drivers are present in the chain. then as receivers. uy). Interconnect test could also be executed with two or more drivers connected to one node.Chapter 5: Testing Boundary-Scan Device Chains One interconnect test is generated for each boundary-scan chain on the board. intermediate file input to the MSPD serializer that contains. ■ InterconnectPlus Test Language (ITL) source file—A permanent. until the entire chain has been tested. one at a time (u1. Under certain circumstances. . interconnect test must be executed with multiple device outputs driving test patterns onto the same (bussed) node. 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. and tests the operation of all drivers. intermediate file created by the MSPD Serializer that contains the device test. . it is an input to the VCL compiler. This test checks for opens on only the inputs and outputs of devices that have physical probes assigned. but with only one driver enabled. ■ Test dictionary (. essentially the boundary-scan test source code generated by IPG using the InterconnectPlus software. InterconnectPlus Test Files Each of these tests has five files of which you should be aware. 5-20 .x) file—A permanent file generated by the MSPD Serializer that contains the node identifier and the expected signature for that node. This test verifies the connections between devices in the same chain only. testing a 300-pin ASIC when only 200 resources are available—you can (manually) split the connect test into two or more smaller tests. ■ © Agilent Technologies 2002. Boundary-Scan Guide Connect test verifies the operation of bidirectional pins by generating separate vectors to check their operation as drivers. Buswire test verifies the operation of bidirectional pins by generating separate vectors to check their operation as drivers. One buswire test is generated for each chain on the board. then as receivers. Connect Test—Tests for opens on each device.

If complete board_xy files are not provided. and you can focus on qualifying candidates for probe removal. All of these files are located in the board's digital directory. When this information is provided. and all pin data (preferably all solderable points) as well as node data should be provided.Chapter 5: Testing Boundary-Scan Device Chains ■ Test requirements (. 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. Complete X-Y data would tell the system software about the physical relationship of all these components. the software will make calculated assumptions about nodal adjacency. which could result in inadequate or incomplete test coverage. and would allow InterconnectPlus to add the necessary powered shorts test to cover all contigencies. This board has a number of integrated circuits with gullwing leads that © Agilent Technologies 2002. Figure 5-13 is a physical representation of one section of a densely packed circuit board. Each of these files is discussed in more detail throughout this chapter.r) file—A temporary file generated by the VCL compiler to identify testhead resources needed for the test. 2003 Boundary-Scan Guide 5-21 . you can rely on the software to provide complete coverage. Also mounted closely to these devices are several SMT analog devices.o) file—The compiled VCL file (non-editable). are mounted closely together. ■ Test object (. Topology provides the system with valuable adjacency information used to build powered shorts tests.

5-22 . © Agilent Technologies 2002. Powered Shorts Test Figure 5-14 illustrates connections between two devices for which a powered shorts test would be generated. and in most cases will work without debug.Chapter 5: Testing Boundary-Scan Device Chains 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. Remember that this test is created automatically. 2003 Boundary-Scan Guide The information in this section is provided for background.

IN_17 and IN_18.Chapter 5: Testing Boundary-Scan Device Chains 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 3 U3_2 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. connected to a non-scan device. These pins (u3 pin 1 and u4 pin 24) are physically adjacent to u3 pin 2 and u4 pin 23. 2003 Boundary-Scan Guide *Nodes are physically adjacent on actual board. The test software takes the data provided in your board_xy file to determine the relative adjacencies for each device. u5. © Agilent Technologies 2002. Devices u3 and u4 are boundary-scan devices with two nodes. u3_3 and u3_2. are also connected to u3 and u4. Because the basic parameters for 5-23 . Two input nodes. The test software identifies these nodes as potential shorts for this circuit. The adjacencies identify where shorts can occur with respect to boundary-scan nodes.

This test verifies that the chain is operable. It then examines the X-Y data for powered shorts situations to adjacent nodes. Each subtest is a cycle through a selected set of nailed nodes connected to multiplexed hybrid drivers. Whenever possible. several subtests are run. or during the first phase of interconnect testing. Remember that this test is created automatically. After you enter your board data. The © Agilent Technologies 2002. which provides some capability for device identification. IPG analyzes it and looks for un-nailed boundary-scan nodes. if provided. Multiplexing is used to reduce the number of resources needed for the complete test. this test also verifies that the correct devices have been loaded onto the board by checking their IDCODES. 2003 Boundary-Scan Guide 5-24 . the data captured by the Instruction Register during the CAPTURE-IR state is verified.Chapter 5: Testing Boundary-Scan Device Chains powered shorts test are an un-nailed boundary-scan node and a nailed node of any other type. Shorts on this node would be found either during unpowered shorts testing. IPG then writes the ITL for the powered shorts test. InterconnectPlus software would create a powered shorts test for this circuit. Note that two adjacent pins on device u5. and in most cases will work without debug. A detailed diagnostics routine is executed upon failure and results are reported to the print device. pins 10 and 11. This is done by verifying the two least significant bits of the Instruction Register. information in this section is provided for background. If IDCODES are not provided. TAP Integrity Test Figure 5-15 illustrates the boundary-scan TAP integrity test. When this test is executed. which are captured during the IR-CAPTURE state. 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. and that the scan path is intact.

2003 ■ a wrong device was loaded ■ one of the TDI or TDO connections is bad (for example.Chapter 5: Testing Boundary-Scan Device Chains 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. an open between u3 and u4) one of the devices is bad: simply does not work Boundary-Scan Guide 5-25 . Examples of problems that could be encountered include: ■ © Agilent Technologies 2002.

Also. An operational chain. before each interconnect test. and in most cases will work without debug. the diagnosis is limited in its ability to pinpoint the cause of the failure. Interconnect Test Remember that this test is created automatically. When these bits are shifted in.) Only the connections between devices in the same boundary-scan chain can be verified. if a device includes this feature. Any failure during TAP Integrity test causes the board to power down and a general failure message is generated. you cannot do meaningful testing. When testing begins. When the devices go through CAPTURE-IR. the devices load a pre-determined pattern (BYPASS or IDCODE as specified in the BSDL file) into the Instruction Registers. the new bits are captured. These bits verify the IDCODES of the devices that feature them. 5-26 . then most opens.Chapter 5: Testing Boundary-Scan Device Chains ■ TCK is disconnected from one or more devices Integrity tests are an integral part of every chain test. 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. or BYPASS. and new data bits are shifted in through TDI. the preloaded pattern is captured. A failure could occur in a device upstream from the device that the message cites as the starting point for looking for the cause of the failure. the preloaded bits are shifted out. to a device). The type of failures detected during this test would prevent the chain itself from working properly: if the chain is bad. and before each connect test. in this case. The devices then change over to their new instructions. An operational chain. Interconnect test allows you to test the circuitry that connects one boundary-scan device to another. and devices that are basically functional. The information in this section is provided for background. or they tell the software that the device successfully executed the BYPASS function. © Agilent Technologies 2002. but it does not say exactly where the failure occurred. These bits are typically for the IDCODE instruction. Integrity test occurs before each powered shorts test. The devices then all go through SHIFT-IR and new instruction bits are shifted in through TDI. implies operational TAPs for each device. before each buswire test. 2003 Boundary-Scan Guide in this case. (A buswire test might be necessary to detect opens missed by interconnect test. The message provides a diagnosis to the general area (for example. So the chain must be repaired before further testing can be done. then shifted out for examination. When the devices pass through CAPTURE-DR. implies proper devices loaded. The software can examine this pattern for each device to see if the chain is working. Interconnect test primarily looks for shorts.

Figure 5-16 illustrates interconnect test. TDO. An adjacent Boundary Register cell acts as the test probe. All other nodes located between the boundary-scan devices in the chain can be silicon nodes. Because damaging devices during powered testing is an important issue.Chapter 5: Testing Boundary-Scan Device Chains Testhead access is required only for the TDI. and TCK nodes. it must have a physical probe assigned. NOTE A silicon node is a node on which no physical test probe is used. © Agilent Technologies 2002. Silicon Nails is one test technique that employs silicon nodes. 2003 Boundary-Scan Guide 5-27 . TMS. InterconnectPlus software takes the following approach to interconnect test. ■ Concentrates on finding shorts as fast as possible. ■ Looks for shorts and most opens. Note that if any upstream control node or nodes must be conventionally disabled for testing.

© Agilent Technologies 2002. 2003 Boundary-Scan Guide Table 5-4 A 0 1 0 0 1 B 0 1 0 1 0 C 0 1 0 1 1 D 0 1 1 0 1 Rows form signatures 5-28 . you need to understand the concepts of frames and signatures. For the circuit in Figure 5-16.Chapter 5: Testing Boundary-Scan Device Chains 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. the example data pattern is set up as shown in Table 5-4.

refer to the Syntax Reference documentation. The frame size tells you how many bits are shifted into the deep-capture RAM each time a frame is executed. also called identification (ID) patterns. frame 0 1 000X 100X 001X 101X 001X 101X 000X 100X 01XX end frame © Agilent Technologies 2002. The rows of bits from the corresponding positions in each frame form signatures. Frames are vectors that are shifted into the chain serially (serialized vectors). for these nodes. The frame statement found in the VCL source code tells the system's deep-capture RAM to capture bits shifting out of TDO. For more information about the frame and end frame statements. The frame is two times the size of the active register because two vectors are needed for each clock cycle.Chapter 5: Testing Boundary-Scan Device Chains The columns of bits form frames. concatenated register. The following example frame would be needed to shift the fourth frame (0110) of the signatures for Figure 5-17. 2003 Boundary-Scan Guide 5-29 . Signatures (IDs) must be different for each node so software can distinguish one node from another. The number of bits in a frame is determined by the number of cells in the active.

2003 Boundary-Scan Guide on the preceding page. as Figure 5-17 shows. we can use the five frames shown © Agilent Technologies 2002.Chapter 5: Testing Boundary-Scan Device Chains 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 A 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. 5-30 .

© Agilent Technologies 2002. at UPDATE-DR. then identifies one driver (affectionately called the designated driver) as the one that will be used to drive the node during interconnect test. When the devices pass through CAPTURE-DR. interconnect test attempts to use only one driver for each bussed node if at all possible. These drivers are tested later during buswire test. 2003 Boundary-Scan Guide 5-31 . for each node contain the bits that make up the signatures (IDs) for those nodes. the receivers connected to the corresponding node should capture the bits of that node's ID. The software examines the BSDL files and the device connections. All other drivers connected to the node are disabled.Chapter 5: Testing Boundary-Scan Device Chains The frame positions that correspond to the drivers. How Software Designates a Driver for Interconnect Test As we mentioned earlier.

Chapter 5: Testing Boundary-Scan Device Chains 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 8 u3 9 u4 10 TDO Con tro l Ce ll Several circumstances can prevent the software from designating only one driver. It finds the only one available and designates it as the driver for that node.13. 5-32 . 2003 Boundary-Scan Guide cell. For this example. let's say that the software looks for and finds a driver for u1. Figure illustrates one situation where bussed drivers share the same control © Agilent Technologies 2002.

the receive cells capture the data.12 respectively. refer to chapter 2 in this documentation. is rectified during buswire test. 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. Fault masking. which can result from this situation. 2003 Boundary-Scan Guide NOTE The exception to this is a TAP-only device.11 and u1. which are connected to u1. ( These are labeled as SAMPLE in the VCL source file because SAMPLE is a reserved word in BSDL.9.10.Chapter 5: Testing Boundary-Scan Device Chains Notice that this pin's control cell is also connected to the drivers for u1. 5-33 . which are then shifted out for examination. Data shifted out should correspond to the signatures for each node. 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. By itself. and subsequently shift it out. where they will remain during testing. new bits are shifted in.11 and u1. Executing Interconnect Test Interconnect test first shifts the instruction bits into each device in the chain to set up the SAMPLE/PRELOAD function. As the devices pass through CAPTURE-DR. © Agilent Technologies 2002. the control cell for that pin also enables the drivers for u3. When the devices pass through UPDATE-IR. The devices then go through UPDATE-IR to change to the EXTEST function. When these bits are being shifted out.8 and u3. To eliminate bus fights. which is always in BYPASS during testing.12.) 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 driver cells drive the SAMPLE/PRELOAD data bits to the receive cells. This situation must occur because interconnect test needs to drive these nodes during its test. the software ensures that the data on these drivers is the same. Subsequent passes through UPDATE-DR drive new bits to the receive cells. this is not a problem. The situation that now arises is that the two buswires have multiple drivers. For more information and examples of safe bits. However. when the software moves on and designates a driver for u3.

Chapter 5: Testing Boundary-Scan Device Chains

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.

© Agilent Technologies 2002, 2003

Boundary-Scan Guide

5-34

Chapter 5: Testing Boundary-Scan Device Chains

Figure 5-18

PRELOAD zeroes (0) shifted in to drive cells
A

u1

B
C

u3

D

0

0

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

© Agilent Technologies 2002, 2003

Boundary-Scan Guide

5-35

Chapter 5: Testing Boundary-Scan Device Chains

Figure 5-19

.Interconnect Test finding an open on a receiver
Open
A

u1

B
C

1 A

0
0
0

B

u2

TDI

A

u3

B
D

0
0
0

0

A

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.

© Agilent Technologies 2002, 2003

Boundary-Scan Guide

5-36

2003 Boundary-Scan Guide 5-37 .Chapter 5: Testing Boundary-Scan Device Chains Figure 5-20 Interconnect Test finding an open on a driver A 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. © Agilent Technologies 2002. The frames below provide an example of how this test is executed.

The above example shows four bits. They also eliminate aliasing to these power nodes. and form the part of the node's signature that primarily distinguishes one node from another. 2003 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. The last part of the signature. but the length of these bits is determined by the number of nodes in one frame. These bits verify that the node is not shorted to ground or VCC. The counting bits follow. 5-38 . no two nodes can have the same number. The number of bits used here is a fixed percentage of the number of counting bits used.Chapter 5: Testing Boundary-Scan Device Chains Table 5-5 Frames Node Power Bits Eliminates Aliasing to Ground or VCC Counting Bits Primarily Distinguishes one Node From Another A 0 1 0 0 0 1 0 1 1 B 0 1 0 0 1 0 1 0 1 C 0 1 0 0 1 1 0 0 1 D 0 1 0 1 0 0 1 1 0 The enhanced counting sequence first assigns a 01 bit combination that we'll call the power bits. the complement bits reduce the incidence of aliasing between active nodes. © Agilent Technologies 2002.

Interconnect Test uses signatures to check for shorts and opens. Boundary-Scan Guide 5-39 . In this example. shorts could damage devices during this time.Chapter 5: Testing Boundary-Scan Device Chains Figure 5-21 . 2003 Testing Bidirectional Pins Interconnect Test and Bussed Devices Interconnect test fixes the direction in which it tests bidirectional cells. 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 A u1 B C u2 TDI A u3 B u4 D TDO © Agilent Technologies 2002. 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.

and in © Agilent Technologies 2002. it minimizes the number of frames needed for Figure 5-22 interconnect test. The information in this section is provided for background. 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 Remember that this test is created automatically. During 5-40 . which alleviates this problem. which allows shorts to be detected as soon as possible. 2003 Boundary-Scan Guide most cases will work without debug.Chapter 5: Testing Boundary-Scan Device Chains Buswire tests are drawn out of interconnect tests and made an independent object.

Chapter 5: Testing Boundary-Scan Device Chains interconnect test. attention to this class of faults is delegated to separate. If IPG sees that the chain has bussed devices. Buswire Test verifies connections on bussed nodes u2 u1 TDI u3 u4 T DO © Agilent Technologies 2002. it generates the buswire test. 2003 Boundary-Scan Guide 5-41 . Because of the safety issues mentioned above. opens on bussed nodes could be missed for a number of reasons. Figure 5-23 illustrates buswire test. Buswire test is Figure 5-23 derived from the connectivity information used to generate the interconnect test. buswire tests.

Shorts are not a concern because these were tested for in the tests (shorts. an open on one of these drivers would not be detected. 2003 Boundary-Scan Guide 5-42 .Chapter 5: Testing Boundary-Scan Device Chains The buswire test looks only for opens on bussed devices. an open on one of these drivers would not be detected. opens on the disabled drivers would not be detected. Drivers are tested one at a time to ensure that all possible situations for which opens could occur are tested. BIf two or more drivers must be enabled to satisfy interconnect test and they drive the same node. 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. powered shorts. © Agilent Technologies 2002. and interconnect) executed earlier. CIf two or more drivers must be enabled because they are connected to the same control cell. even in the buswire test.

One other issue to consider when testing bussed devices is parallel busses. one at a time.Chapter 5: Testing Boundary-Scan Device Chains 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) © Agilent Technologies 2002. Boundary-Scan Guide 5-43 . like other bussed wires. InterconnectPlus was designed to handle these cases with minimal impact on test size and execution time. then once as a receiver to ensure that both functions operate properly. Each bidirectional pin is tested once as a driver. 2003 Testing Bidirectional Pins Testing Parallel Busses Bidirectional pins are tested.

9 B ZZ 01 Boundary-Scan Guide 5-44 .Pin Node Bit Pattern u1.10 A 01 ZZ u3.Chapter 5: Testing Boundary-Scan Device Chains Because the sample chain includes two pairs of bussed wires (A and B in Figure 5-25).9 B 01 ZZ u3. independent bus can be tested in parallel.10 A ZZ 01 u1. Table 5-6 © Agilent Technologies 2002. 2003 Device. each separate.

2003 Boundary-Scan Guide 5-45 . a third pair of frames would be needed to test this wire. The number of frames © Agilent Technologies 2002. as shown in Figure 5-26 on page 5-47.Chapter 5: Testing Boundary-Scan Device Chains 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.

10 A 01 ZZ ZZ u3.Pin Node Bit Pattern u1. 2003 Device.9 B 01 ZZ ZZ u5. Table 5-7 © Agilent Technologies 2002.Chapter 5: Testing Boundary-Scan Device Chains in a buswire test is equal to two times the size of the bus with the largest number of devices connected to it.10 A ZZ 01 ZZ u1.5 B ZZ 01 ZZ u3.9 B ZZ ZZ 01 Boundary-Scan Guide 5-46 .

from the first device in the chain (uX) to the last device in the chain 5-47 . Connect tests are run sequentially. 2003 Boundary-Scan Guide opens on device inputs and outputs that have physical probes assigned to them. and in most cases will work without debug. InterconnectPlus connect test allows you to test for © Agilent Technologies 2002. Shorts between pins with testhead access are detected by the unpowered shorts test.Chapter 5: Testing Boundary-Scan Device Chains Figure 5-26 Multiple drivers on one bus require additional frames TDI TDO Connect Test Remember that this test is created automatically. The information in this section is provided for background.

Chapter 5: Testing Boundary-Scan Device Chains (uY) until all devices have been tested. Connect Test checks the connections of each device in a chain TDI TDO © Agilent Technologies 2002. 2003 Boundary-Scan Guide 5-48 . Figure 5-27 illustrates boundary-scan connect test. One connect test is generated for each device in the boundary-scan chain Figure 5-27 with testhead access. All other devices in the chain are placed in BYPASS.

Connect test employs the Parallel Toggle macro. connect tests should not be executed until both the unpowered shorts test and the (powered) interconnect test have been run. ■ the connect verification routines could detect a problem. Therefore. and looking for this pattern at the testhead nails. Outputs are confirmed by first placing all device outputs high. Complimentary patterns are captured. 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. Boundary-Scan Guide A connect test can fail in one of two manners: ■ the TAP Integrity procedure could detect a 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.Chapter 5: Testing Boundary-Scan Device Chains NOTE If an upstream device that is in BYPASS has outputs that affect the DUT. 5-49 . Testing Bidirectional Pins Connect test verifies the operation of bidirectional pins by testing them once as drivers. 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. then low (in alternating patterns). Connect test performs the following actions: ■ ■ © Agilent Technologies 2002. These tests do not check for shorts between nodes. undetected shorts could cause device damage and inaccurate diagnosis. they look for opens only. If this procedure is not followed. and compared to check for opens. if those devices have any accessible nodes). Testhead resources are allocated to permit testing these pins in both directions. shifted. then once as receivers. The failing vector number is also printed on the repair ticket along with a failure message. 2003 Inputs are confirmed by placing an alternating 0/1 pattern on the testhead nails and looking for this pattern on the device inputs. These two items provide you with a place to begin looking for the problem. Failure messages describing the exact nature of problems detected during the TAP Integrity procedure are encoded directly in the VCL source itself.

Boundary-scan connect test is node-oriented. 2003 Boundary-Scan Guide 5-50 .Chapter 5: Testing Boundary-Scan Device Chains NOTE NOTE Datalogging software logs opens on bidirectional pins only during the output part of the test. Only those nodes that have physical probes assigned are tested. Boundary-scan in-circuit test is discussed in chapter 1 as the EXTEST stand-alone function. The in-circuit test normally finds only one faulty node. ■ Devices connected in a chain—Connect test performed on one device at a time. 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 chain—In-circuit test performed on the devices in a stand-alone fashion. Input failures of bidirectional pins are not logged to prevent duplication of failure information. other devices in chain are in BYPASS. © Agilent Technologies 2002. Boundary-scan in-circuit test is pin-oriented. All device pins require physical probes (including TAP pins) and all pins are tested. The connect test can find multiple failures and reports on all of them. then stops the test. Connect test also provides superior diagnostic resolution.

buswire. These tests perform specific functions that are not added to your board test as part of the automatic test generation process. 2003 Boundary-Scan Guide by EXTEST.Chapter 5: Testing Boundary-Scan Device Chains 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 © Agilent Technologies 2002. or connect test. 5-51 . interconnect. such as powered shorts.

then copy and edit an ITL file that it generates when you are ready to develop the custom tests. you must run IPG in incremental mode on the new.” describes this interface and how to use it. Chapter 6. © Agilent Technologies 2002.Chapter 5: Testing Boundary-Scan Device Chains Like the standard Boundary-Scan software. custom library test file. “Multichip Scan Port Driver and the MSPD Interface. An important issue to consider is when to use the interface to develop custom tests. After you have completed the custom test. Chapter 6 provides detailed information about performing this task regardless of the strategy that you choose to employ. InterconnectPlus features an interactive user interface that helps you develop custom boundary-scan tests for your device chains. If you know that you want to generate custom tests. 2003 Boundary-Scan Guide 5-52 . 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.

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. a critical link to successful implementation of boundary-scan testing. ■ disabling or overdriving devices that affect boundary-scan testing. ■ 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.Chapter 5: Testing Boundary-Scan Device Chains Generating Tests For Boundary-Scan Chains Once you describe your boundary-scan devices and board topology to the test system. ■ best practices for developing boundary-scan tests. The information that you provide allows the system to identify boundary-scan devices and the types of test needed for these devices. This section also describes: © Agilent Technologies 2002. test generation is automatic. ■ the importance of complete and accurate BSDL files. For more information. Although the InterconnectPlus software generates tests automatically for your boundary-scan devices. Generation of boundary-scan tests is integral to the test system software. you should still understand how the test system uses the information that you provide to generate your device tests. NOTE The BSDL file for each device must be complete and accurate before entering the test process. Internal compilers use board and location information to generate the board files board and board_xy. 2003 ■ how to enter the information needed by the system. This section provides a brief discussion of this test generation process. refer to the section “Confirming the BSDL File” found later in this chapter. The resulting test process happens automatically and tests are generated automatically. The diagram starts in Board Consultant where you enter information about each device. Incomplete or inaccurate descriptions can result in complicated debug later in the process. 5-53 .

vcl and uX_uY_connect.r or uX_uY_bus. v c l and u X _ u Y.o (executable) or uX.x C o n n e c t Te s t (executable) uX_connect.vcl and uX_uY_ps. P o w e r e d S h o r t s Te s t uX_uY_ps.r or uX_connect.o" "board_xy.o S i l i c o n N a i l Te s t uX_sn.vcl. 2003 Boundary-Scan Guide Results Analysis 5-54 . v c l .vcl S e r i a l i z e d Te s t uX_sn.vcl and uX.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.r Compiler P o w e r e d S h o r t s Te s t (executable) uX_uY_ps.x C o n n e c t Te s t uX_connect.vcl and uX_uY_bus.vcl.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. x B u s w i re Te s t uX_uY_bus.o TESTHEAD © Agilent Technologies 2002.Chapter 5: Testing Boundary-Scan Device Chains 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.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.vcl. r or u X _ Y. o B u s w i r e Te s t (executable) uX_uY_bus.

chain test generation. buswire test. one powered shorts test for each chain. and connect. 5-55 . the Results Analysis Routine interacts with the testhead to diagnose and report failures.o objects) in advance of compiling the ITL files. For example: u1_u4_bus Boundary-Scan Guide ■ connect test: <device>_connect. The names assigned to each test type by IPG are: ■ ■ ■ © Agilent Technologies 2002. 2003 powered shorts test: <device_1>_<device_2>_ps. and one connect test for each device in the chain connected to physical probes. These files must have been compiled (creating . 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. and you must describe your devices. you must tell IPG where it can find the BSDL files for your devices. IPG generates four preliminary test structures: powered shorts. The test can then be run on the circuit board. NOTE The Silicon Nail test path is shown in Figure 5-29 only to identify its relationship to standard. Silicon Nail testing is discussed later in this chapter. Describing Your Boundary-Scan Device To generate tests for a chain of boundary-scan devices. where <device> is the name of one device in the chain. buswire. interconnect test.Chapter 5: Testing Boundary-Scan Device Chains NOTE ITL source files contain references to BSDL files. For example: u1_u4 buswire test: <device_1>_<device_2>_bus. and connect test. IPG generates one interconnect test for each chain. which generates executable tests that can then be incorporated into the testplan. interconnect. Both of these tasks are accomplished using Board Consultant. one buswire test for each chain. For example: u1_u4_ps interconnect test: <device_1>_<device_2>. where <device_1> is the name of the first device in the chain and <device_2> is the name of the last device in the chain. At this time. which creates four types of VCL source files: powered shorts test. For example: u3_connect IPG then sends this information to the MSPD serializer. These source files are sent to the VCL compiler. 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.

Chapter 5: Testing Boundary-Scan Device Chains Using the Library Path Names Form Use this form. then Enter Library Paths from the list at the bottom of the flowchart. either create a new board file or load an existing board file. type the appropriate path in the Library Path's field. 4 When the Library Paths Form appears. to tell IPG where to look for the BSDL files for your devices. 1 Select Program > Run Board Consultant. 3 Click on the View/Edit Library Data button in the flowchart. as Figure 5-30 shows. click on the Update button. 6 Click on the Close button to exit the form. 2 When the Board Consultant interface appears. Figure 5-30 © Agilent Technologies 2002. 5 When you finish entering new paths. 2003 Use the library paths form to tell IPG where to find the BSDL files Boundary-Scan Guide 5-56 .

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

2003 Board Consultant device entry form Boundary-Scan Guide 5-58 .Chapter 5: Testing Boundary-Scan Device Chains Figure 5-31 © Agilent Technologies 2002.

To execute this test. holes for TestJet probe are partially drilled.Chapter 5: Testing Boundary-Scan Device Chains ■ Testable: Select Yes if the device is to be tested. ■ Test Using Connect Check: Select Yes if Connect Check will be used to test the device. Keepout Method. The default is Yes. Yes is the default selection. 2003 Spring Override: Allows you to override the software’s automatically selected probing method. but the wiring and mux assignment is not made. The software will choose a small or standard probe automatically.) ■ ■ © Agilent Technologies 2002. ■ Test Using TestJet: Select Yes if TestJet will be used to test this device. this error that will prevent compilation of board_xy. No is the default selection. If only two device outline points are entered. If more than two device outline points are entered. ■ 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. ordered 5-59 . ■ Device Outline: Enter the corners of the device outline area in the X Value and Y Value fields. ■ TestJet Probing: Select the TestJet probing method: Select the default. (This option is not allowed if the device is on the bottom side of board. ■ Foam Override: Uses the foam mounted probe regardless of the dimensions of the device. 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. your device must have probes assigned to all nodes. these two points will be treated as opposite corners of a rectangle. 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. or No if it is not. Probe locations are directly across from each other. to use the old keepout technique. Probe locations are at two opposite corners of the active board. based on the device outline dimensions. If you select Future. No is the default selection. 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. the device outline will be a polygon whose vertices are the points entered. Boundary-Scan Guide ■ Standard Spring Override: Instructs the fixturing software to use a standard TestJet probe.

point_1 to point_2 to . If you do not click on the 1149_1 box. ■ 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. When you click on the 1149_1 box. 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. it will be used in the graphics window. Thereafter this button will simply copy that outline back from the graphics window. © Agilent Technologies 2002. 2003 Boundary-Scan Guide 5-60 .1. ■ BSDL Part Number: Enter the name of the BSDL file for the designated device. While any device may be assigned an explicit device outline. all of the points in the graphic polygon are copied. ■ Device Package Type: Enter or change the package type for the designated device. estimated outline originally used in the graphics window. Clicking on this box does not imply that the device is fully-compliant with IEEE 1149. devices whose TestJet Probing attribute is set to something other than Keepout Method). 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. Once you have assigned an outline to a device. If the device outline shown in the graphic is rectangular.the upper left and lower right corners of the rectangle. If the package type specified cannot be found. ■ Clear: Clears out all the X/Y values. edit the outline and adjust it before you select Replace Device. If the last point listed is not identical to the first. and press this button again. To return to the default. that point will be assumed automatically in order to close the polygon..Chapter 5: Testing Boundary-Scan Device Chains exactly as they are listed in this form. only two points will be copied into the form -. ■ Testability Standard: Click on the 1149_1 box if the designated device is a boundary-scan device. and can have up to 120 points. Otherwise. to point_N. keeping their ordering. the compiler will generate an error. The units of measurement are tenth-mils. then Replace Device. The default outline used in the graphics window is a rough guess based on device pin locations. If a BSDL file match cannot be made. If it is not close enough to the actual device profile to allow adequate probe placement. the compiler will generate an error. the test system will not consider this to be a boundary-scan device. select Clear Outline.e. The device outline must have at least two points. you enable the options and data entry fields in the lower half of this form...

See Using Boundary-Scan Disabling on page 5-71 for more information. The Connect Max value will be the same for all versions. tdo. (Disabling information is not needed for boundary-scan disabling. which will affect how the chain is derived but does not represent a change in connectivity.Chapter 5: Testing Boundary-Scan Device Chains Connect Test: Select Yes if you want IPG to generate a boundary-scan connect test for the designated device. The default is Full. If a zero is entered. and trst. If this field is Yes. but you do want to keep this device in your chain. ■ ■ Connect Max: Enter a value between 1-999 to specify the maximum number of nodes to test in any connect test. the system will assign resources for a standard in-circuit test. tms. Connect Max cannot be used with versions. the board compiler runs and IPG Test Consultant checks to see if a library model exists for the test. If you use Connect Max to conserve channels. You should have at least a setup-only test in the library at this time. 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 © Agilent Technologies 2002. whether or not Connect Max is selected. ■ TAP Signal Overrides: Brings up the TAP Override Form to allow you to specify the nodes for tdi. select No for the Library Test Expected field. This value is not applicable if TAP only or Interconnect only are selected. tck. Figure 5-32 on page 5-62 shows the device entry form as it would appear for a TAP-only device. Select TAP only if the device is non-compliant in some way. See Connect Max on page 5-62 for an explanation of this feature. this field will be set to blanks. The default is Yes. Remember that specifying a device as TAP-only eliminates that device from boundary-scan testing but allows you to 5-61 . You can only change Connect Max value in the base device. The part must have an interconnect test to perform a connect test.) 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. A connect test is written for the device only if physical probes are assigned to nodes for that device. when you leave Board Consultant. particularly to provide IPG with pertinent disabling and device family information. 2003 Boundary-Scan Guide NOTE After you have described your devices and added them to your test. ■ 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.

Chapter 5: Testing Boundary-Scan Device Chains keep the device in the chain. which in turn allows for better overall testing of the chain. you encounter a situation where you require more digital channels than your tester has available (Figure 5-33). You can specify a library test to be performed on a TAP-only device if you so desire. Remember that you must have physical probes assigned to every node for each device that will have a standard digital library test generated. or changes the Interconnect Test button to Full if you had previously set it to TAP-only. If this problem is the result of a connect test on a large boundary-scan IC. 2003 Boundary-Scan Guide 5-62 . © Agilent Technologies 2002. Sometimes. the Connect Max feature can often help. Set the Library Test Expected button to Yes if you want IPG to generate a standard digital library test for your TAP-only device. 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. 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). Setting the Connect Test button to Yes disallows a TAP-only setting.

If a library test is expected. 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. without having to add pin cards to accommodate a large number of channels. By using the Connect Max feature. you can use testers that are appropriate to the number of nodes on the board. ■ Select the larger of the two numbers determined above. 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. you can divide a connect test © Agilent Technologies 2002. the test will require the channels you otherwise would have saved by breaking apart the connect test. This is the channel count. you should also use the Device Entry Form to mark the part as not expecting a library test. Because the Boundary-Scan 5-63 . Whenever you specify a Connect Max setting. 2003 Boundary-Scan Guide A key experience gained in early implementations of boundary-scan is the importance of describing the component correctly. as in this example. For example.Chapter 5: Testing Boundary-Scan Device Chains 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.

Chapter 5: Testing Boundary-Scan Device Chains Description Language (BSDL) file is used to create thousands of test vectors automatically. or even days. In the early implementations of boundary-scan. ■ What the expected IDCODES for each device should be. This tells the test generation and analysis routines where to find the bits representing each node. then false faults will be reported. The construction of the boundary-scan chain is extracted from the board topology and the BSDL file for a device. an example of how interconnect tests are executed. What are the problems that might be encountered if an inaccurate BSDL file were provided for a device? Consider Figure 5-34. and what outputs or bidirectional pins they control. The expected capture information is verified for each device during the test. 5-64 . The IDCODES are verified during the TAP integrity test. few things can negatively affect an automatically-generated test. many things are unknown. and more time will be spent in debug. Other unknowns include. Extra effort in this phase can save many hours. 2003 Boundary-Scan Guide are correct. 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. but does not exactly match the silicon implementation. ■ What each cell in the Instruction Register captures when clocked in the CAPTURE-IR state. If the BSDL descriptions of all of the devices in a chain © Agilent Technologies 2002. and the topological descriptions of the circuit interconnections are correct. it is very important to make sure that each BSDL file is complete and accurate before working with scan chains. 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. Accuracy in this description is very important for correct fault diagnosis and minimal debug time. of debug in later phases. ■ Which cells in the boundary-scan chain are control cells. This data is used to disable pins that might interfere with the test. 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.

and data would be placed into or extracted from the wrong positions in the chain. then the disable would not occur. and for the failure analysis. The test information placed on the interconnections is shifted in through TDI. Misrepresented registers can result in garbled signatures. Now. © Agilent Technologies 2002. If this were the case. For these and other reasons. Figure 5-34 shows two output control cells for one device. but if the length of the Boundary Register was incorrect. The results of the test are shifted out from TDO and captured.Chapter 5: Testing Boundary-Scan Device Chains Each of the interconnections between the two devices terminates at a Boundary Register cell (either a driver or receiver). If this device needed to be disabled. once for each new device type. we strongly recommend that the BSDL descriptions of each device be thoroughly verified against the silicon itself. 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. This would be catastrophic for the GO/NOGO test. every device in the chain between the mis-described device and TDI would be offset by the inaccuracy. The effect would be that those nodes connected to the non-disabled pins would fail with a variety of incorrect diagnoses. the Boundary Register description for the device would be incorrect. 2003 Boundary-Scan Guide 5-65 . and the control information were inaccurate. Not only would the information be wrong for the device described. consider the effects of failing to accurately describe the control cells for a device. Figure 5-34 shows an extra internal cell that could be missed in the BSDL file. The captured data is subsequently examined.

Chapter 5: Testing Boundary-Scan Device Chains Figure 5-34 Inaccurate BSDL descriptions cause testing problems TDI TDO Internal* Output Control TDI TCK TDO TMS Output* Control * Cells Missing From BSDL © Agilent Technologies 2002. 2003 Boundary-Scan Guide 5-66 .

refer to chapter 4 of this documentation.Chapter 5: Testing Boundary-Scan Device Chains Verifying BSDL Descriptions To eliminate as many of these potential problems as possible.. you should use an automatic tool to create BSDL files.. 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./supplemental/bsdl. you may also place BSDL files in library directories associated with the board directory. you must use the SPD Interface to find the Verify BSDL macro. 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. the main BSDL file belongs in the board directory’s library path. 2003 NOTE Boundary-Scan Guide ■ in the same directory where the BSDL file itself resides. you should place all custom BSDL files and their associated packages in one location so that they can be found easily by system software. you should test the BSDL file and the new component in a stand-alone configuration. The test generated can then be executed by: For more information about this macro.. The pathname to the directory reserved for this function is /3070/library/supplemental/bsdl This path is guaranteed to be where standard packages are. /3070/library/supplemental/bsdl On the other hand. When reading a BSDL file. © Agilent Technologies 2002. then simulating it against a model of the device NOTE Because this function is for a single device. However.or Placing user-defined packages in the proper location is of particular importance.. If a verified automatic process is not in place. without interference from other components. the system will look for associated packages: ■ translating the test to simulator input. refer to chapter 4. and ■ in the standard location. Having the 5-67 . Be sure to provide a library path to them.. which may or may not include .or Ideally. ■ verifying the BSDL file at device test if the semiconductor test supports BSDL-based boundary-scan.. Give the BSDL file and digital library files for a device different names so the system will not mistake one for the other.

just as it does for standard digital tests.Chapter 5: Testing Boundary-Scan Device Chains same names in different paths will not avoid such a mistake. IPG will take care of all bus disabling for interconnect. If a disabling conflict arises. See Using Boundary-Scan Disabling on page 5-71 for more information. buswire. and connect tests. you can encounter several disable conflicts. However. 2003 ■ 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 . For conventional disabling. Some of these include: © Agilent Technologies 2002. During a boundary-scan test. You can also use boundary-scan resources to disable device outputs. HP IPG rejects the disable method. Figure 5-35 shows a circuit that requires bus disabling. and reports in the source file that the node was not disabled. ■ a device output that cannot be disabled that is connected to an interconnect node. HP IPG cannot always accomplish the disables as needed. you must provide disable vectors for Silicon Nail tests. Conventional Disabling of Boundary-Scan Devices To disable boundary-scan devices. you can use the techniques described in this section. All disabling nodes must have physical probes assigned to them. 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.

consider the following scenario as illustrated by Figure 5-36.Chapter 5: Testing Boundary-Scan Device Chains 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. 2003 Boundary-Scan Guide 5-69 . © Agilent Technologies 2002. To understand why this is necessary.

Therefore. Because they are in BYPASS. © Agilent Technologies 2002. This bus also has a physical probe assigned. it is necessary to disable the devices in BYPASS by using standard disable methods. the bidirectional pins could be active. only one device is tested at any one time. Remember that when a connect test is executed. All other devices are placed in BYPASS.Chapter 5: Testing Boundary-Scan Device Chains 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. 2003 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. and the core logic is active. so a connect test will be generated for each device. 5-70 .

The example below shows an ITL source file for a connect test that includes fixed node information. it will add this information to the ITL source file.Chapter 5: Testing Boundary-Scan Device Chains IPG will do this automatically. You will have to edit the ITL source file to describe the state as high or low. The default value is Off to permit backward compatibility with previous versions of InterconnectPlus. NOTE When you set the Boundary-Scan Disable field to On.8" © Agilent Technologies 2002. To use this feature. For more information about conventional disabling. "FK_PACKAGE". it will still add this information to the ITL source file. but it must have at least a digital library setup-only file that contains the disable information so it can perform the required disabling. This feature is highly recommended for new tests (tests not prepared under a previous version of InterconnectPlus). refer to Digital–2. 2003 Boundary-Scan Guide end nodes end connect You should understand that if IPG cannot identify a fixed node as being high or low. then uncomment the line. "users/scan_brd/digital/74bct8374". the Boundary-Scan Overdrive field is automatically set to Off. Fixed Node Considerations If you know that your board has fixed nodes—tied to power or ground—use Board Consultant to define them in your board file. 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". no end devices end chain nodes fixed high "+5V" test "u44. Using Boundary-Scan Disabling InterconnectPlus lets you use boundary-scan resources to disable device outputs. but the line will be commented out. This field is located in the IPG Global Options Form in Board Consultant. When IPG runs. and the state will be labeled unknown. 5-71 . set the Boundary-Scan Disable field to On.7" node "u44-8" hybrid test "u44.

to allow testing of the bussed pins. If bussed pins are to be tested. only one device is tested at a time. it might be necessary to disable the devices in BYPASS by using standard disable methods. If the CLAMP instruction is not available. ■ Runs automatically once you have turned it on. ■ Speeds the disabling process. the device will be issued the EXTEST instruction. Boundary-Scan Disables On When a connect test is executed. if it is available. Advantages of Boundary-Scan Disabling Boundary-scan disabling offers these advantages: ■ Works in any situation that requires an upstream disable for a test (provided that the upstream device can be disabled with boundary-scan—see Limitations of Boundary-Scan Disabling on page 5-74). and the core logic may be active. the bussed devices will be issued the HIGHZ instruction. instead of the BYPASS instruction. 2003 Boundary-Scan Guide 5-72 . ■ Relieves many conventional disable conflicts. reducing the opportunity for error. and its © Agilent Technologies 2002. Therefore. ■ Minimizes the need for conventional disabling (seeConventional Disabling of Boundary-Scan Devices on page 5-68). the device will be issued the CLAMP instruction during the connect test. If the HIGHZ instruction is not available for a device that needs to be disabled. boundary register will be loaded with the necessary patterns to control the drivers for the bussed pins. ■ Increases the chance of successfully disabling devices. Because devices not being tested are issued the BYPASS instruction. If other devices in the chain have bussed pins that need to be disabled in order to test a pin of the selected device.Chapter 5: Testing Boundary-Scan Device Chains By defining Boundary-Scan Disables in the board file. only one device is tested at a time. bidirectional pins could be active. This can decrease the resource requirements for in-circuit tests. Boundary-Scan Disables Off When a connect test is executed. All other devices are placed in BYPASS. It also removes the need to manually specify disable methods in device libraries. the devices not being tested may need to be disabled so they will not interfere with verification of the device under test. you can control how devices in the chain that have bussed pins will be disabled during connect tests of other devices.

This may create the need to add pull-down resistors to maintain the Run-Test/Idle state during subsequent testing. you will receive an error message. The disable program checks chain integrity before performing disables. the test plan pauses. • Boundary-scan tests take place for the current chain. and inserts a comment into the test program. Subsequent tests that depend on the boundary-scan disabling will not be performed. See Maintaining Persistence of Boundary-Scan Disables on page 5-75 for more information. only pins of type output and bidir are disabled. boundary-scan device TAPs are placed in the Run-Test/Idle state instead of the Test-Logic-Reset state. • In-circuit tests are performed. displays a message on the screen. ■ For multiple chains: • Boundary-scan disables occur for all chains except the one being tested. ■ The IPG verbosity modes give information about boundary-scan disables. NOTE Like all boundary-scan tests. If the Boundary-scan library test does include the HIGHZ statement. • Boundary-scan disabling takes place for all chains. ■ 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 disabling occurs.Chapter 5: Testing Boundary-Scan Device Chains Effects of Boundary-Scan Disabling Boundary-scan disabling has these effects: ■ © Agilent Technologies 2002. pins of type buffer are also disabled. Boundary-Scan Guide Boundary-scan disabling may also affect testing order: ■ For a single chain: • Boundary-scan tests take place. If chain integrity is bad. See Maintaining Persistence of Boundary-Scan Disables on page 5-75 for more information. the boundary-scan disabling program can fail because of bad chain integrity. 5-73 . • In-circuit tests are performed. 2003 If the Boundary-scan library test does not include the HIGHZ statement. • The first two bullets are repeated for each chain. ■ After performing boundary-scan disables.

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. pins. 2003 ■ If you do a conventional in-circuit test on a boundary-scan device when it is in boundary-scan disable mode. (Pushbutton Debug automatically executes the disables in the proper order.) ■ During manual debug. by a normal Reset. or chains. you must run VCL programs for boundary-scan chain disables before running any target in-circuit tests. You can reset by going to the Test-Logic-Reset state. you must declare the device to be TAP Only and use conventional disabling on all the device’s pins. If you disable boundary-scan pins. Boundary-scan disabling is also limited in these situations: © Agilent Technologies 2002. To make the device work.) ■ You cannot use boundary-scan disabling for boundary-scan devices that have non-compliant Boundary-Scan Guide 5-74 .Chapter 5: Testing Boundary-Scan Device Chains Limitations of Boundary-Scan Disabling Boundary-scan disabling will not work with all devices. If a boundary-scan device has any non-compliant pins. the device’s internal logic may go into an undefined state and prevent a conventional disable from working on the remaining pins (Figure 5-37). the in-circuit tests may not work. the device will ignore and fail the test. (Which method to use depends on the component. you must reset the device. or cycling the power. If you do not run the disable programs first.

You may thus need to take additional measures to maintain the disables for subsequent tests. boundary-scan device TAPs end testing in the Test-Logic-Reset state. © Agilent Technologies 2002. 2003 Boundary-Scan Guide Without boundary-scan disabling. however. 5-75 .Chapter 5: Testing Boundary-Scan Device Chains Figure 5-37 Boundary-scan disabling may leave a device’s 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. Boundary-scan disabling. parks each TAP in the Run-Test/Idle state (Figure 5-38).

These resistors may make the TAP go to the Test-Logic-Reset state if: ■ An oscillator is connected to the TCK input. act. 2003 Boundary-Scan Guide 5-76 . after performing boundary-scan disables. Also. © Agilent Technologies 2002. and then delete this ‘pause’ section. This is called persistence. The existence of these conditions should alert you to check the persistence of boundary-scan disables. A standard boundary-scan device contains internal pull-up resistors on TMS.Chapter 5: Testing Boundary-Scan Device Chains 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. the test plan pauses and produces a screen message: Test Programmer Action Reminder: Evaluate. ■ Noise is generated by other parts of the board that couple into TCK.

Chapter 5: Testing Boundary-Scan Device Chains Figure 5-38 TAP Controller State Diagram 1 Test-Logic-Reset Normal boundary-scan tests end in this state 0 0 Run-Test/Idle 1 1 Select-DR-Scan 0 Boundary-scan disabling places the component in this state 1 0 1 Capture-DR Capture-IR 0 0 Shift-DR Shift-IR 0 1 Exit1-DR 0 Pause-DR Pause-IR 0 1 0 Exit2-IR 1 1 Update-DR © Agilent Technologies 2002. 2003 Boundary-Scan Guide 0 1 Exit2-DR Data 1 Exit1-IR 0 1 0 1 1 0 1 Select-DR-Scan Update-IR 0 1 0 Instruction 5-77 .

!! 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. !! !! When you have assured persistence of the disable state. © Agilent Technologies 2002. act. You can view them when you edit the test program. you may place your !! own pullup/down resistor in the fixture to assure a stable TMS !! and/or TCK. TMS and TCK should be held to a logic low level. 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. To check persistence: 1 Prepare the test with the Boundary-Scan Disabling field set to On. Board level circuitry may !! interfere with the persistence of the disabled state. etc. 2003 Boundary-Scan Guide 2 Run the test until it pauses. !! For further explanation. for example. These comments follow the Example 5-3 pause statement.” pause ! Comment out pause and print statements above when evaluation complete. 3 Examine the TCK and TMS signals to make sure they are in a stable state.) 5-78 . This assures that the disabled state of the Boundary-Scan !! chain is not accidently lost. Example 5-3 shows a sample message. you should !! comment out the print/pause statements above. Sample message print “Test Programmer Action Reminder:” print “Evaluate. (TCK could also be held to a logic high level if all boundary-scan devices support a stable state when TCK stops at 1. As stated in the message. you should change the print and pause statements to comments after you check persistence and debug the program. see the Boundary-Scan Manual for the !! section titled ‘Maintaining Persistence of Boundary-Scan Disables’. You may !! need to take additional measures. or utilize a GP relay to disable some TCK oscillator.Chapter 5: Testing Boundary-Scan Device Chains The test plan inserts a comment into the test program that reminds you to check the persistence of your boundary-scan disables. and then delete this ‘pause’ section.

the relay must be closed when the testplan implements boundary-scan disables. feeding a zero signal to TMS keeps the TAP in Run-Test/Idle. As shown in the state diagram (Figure 5-40). the oscillator line may include an AND gate to which you can connect the pull-down (Figure 5-39). add the relay to pull-down to TMS (Figure 5-39). © Agilent Technologies 2002. ■ Connect TCK to a 3070 general purpose relay to a pull-down resistor (typically 150 ohms to ground for TTL/CMOS).Chapter 5: Testing Boundary-Scan Device Chains 4 If TCK and TMS are not quiescent—such as when an oscillator is connected to TCK—either: ■ Shut the oscillator off. NOTE If you use a GP relay to pull down a signal. This keeps the TAP in Run-Test/Idle. For example. ■ If the oscillator is not gated. 2003 Boundary-Scan Guide 5-79 .

It can also be held at a logic high level if all boundary-scan devices support a stable state when TCK stops at “1”. 2003 Boundary-Scan Guide 5-80 . 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. GP Optional general-purpose relay to pulldown resistor (<= 150 ohms) 5 If you have multiple chains with a common TCK and different TMS signals—such as the two paralleled serial chains with common TCK in Figure 5-40—you may need multiple put-downs to the TMS lines to maintain persistence. © Agilent Technologies 2002.Chapter 5: Testing Boundary-Scan Device Chains Figure 5-39 Maintaining the persistence of a boundary-scan disable by adding a pull-down or relay.

This may shorten test time and provide better fault isolation. To do this. IPG will use the local TDI and TDO nodes for each device to be overdriven provided probes exist on these nodes. If you do not want to overdrive upstream TDOs. The only entry that you would be concerned with in this form (with respect to boundary-scan testing) is the Boundary-Scan Overdrive field. you would leave © Agilent Technologies 2002. 5-81 . There is a potential problem with overdriving since the portion of the chain not involved in the test is still being clocked. you would use the IPG Global Options Form in Board Consultant and set the Boundary-Scan Overdrive on. If you turn this setting On. and an individual device can be tested. If you assign physical probes to each (or specific individual) TDI/TDO node. the system can overdrive these nodes. The default setting is Off.Chapter 5: Testing Boundary-Scan Device Chains 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. 2003 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. it tries to use all of the chain.

Figure 5-41 shows a device linking simple chains A. and also as pad bits in up to four places. the Boundary-Scan Overdrive option is automatically set to Off. These pad bits appear in a normal 1149. This causes a one bit delay per pad in the chain causing the test to fail. For example.1 form at the end of the chain. They appear as the device itself. © Agilent Technologies 2002. Boundary-Scan Linker/MUX Boundary-Scan Linker/MUX devices can create testing difficulties. 2003 Boundary-Scan Guide 5-82 .Chapter 5: Testing Boundary-Scan Device Chains NOTE When you set the Boundary-Scan Disable field On. See Using Boundary-Scan Disabling on page 5-71 for more information. B. these devices may appear in chains in up to five places. and C. The solution is to combine these pad bits into the proper places in the chain. Pad bits are inserted in the linked chain and are actually resident in the 74ACT8997 device. Refer to Tools–2 for more information about this form. These pad bits are internal to the device but appear in the chain as well.

Chapter 5: Testing Boundary-Scan Device Chains

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:
BOUNDARY SCAN CHAINS
1u1_1u4

© Agilent Technologies 2002, 2003

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

Chapter 5: Testing Boundary-Scan Device Chains

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

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

The system runs tpg creating ITL files for the chain.
These ITL files have a chain description section looking
like Example 5-5.
Example 5-5

Chain description

chain "1u1_linker"
tdi "TDI_LINKER" channel;hybrid
tdo "TDO_LINKER" channel;hybrid

© Agilent Technologies 2002, 2003

Boundary-Scan Guide

5-84

Chapter 5: Testing Boundary-Scan Device Chains

tms "TMS_LINKER" channel;hybrid
tck "TCK_LINKER" channel;hybrid
devices
"1u1", "custom/74bct8374", "DW_PACKAGE",
"1u2", "custom/74bct8374", "DW_PACKAGE",
"1u3", "custom/74bct8374", "DW_PACKAGE",
"1u4", "custom/74bct8374", "DW_PACKAGE",
"2u1", "custom/74bct8374", "DW_PACKAGE",
"2u2", "custom/74bct8374", "DW_PACKAGE",
"2u3", "custom/74bct8374", "DW_PACKAGE",
"2u4", "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
"1u1", "custom/74bct8374", "DW_PACKAGE",
"1u2", "custom/74bct8374", "DW_PACKAGE",
"1u3", "custom/74bct8374", "DW_PACKAGE",
"1u4", "custom/74bct8374", "DW_PACKAGE",
pad
"2u1", "custom/74bct8374", "DW_PACKAGE",

© Agilent Technologies 2002, 2003

Boundary-Scan Guide

no
no
no
no
no

5-85

Chapter 5: Testing Boundary-Scan Device Chains "2u2". You decide to test the board with the chains and the linker all grafted together. These files may be marked as permanent to retain them if the tests are regenerated. 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. No other intervention is required. "PQFP-48". "2u3". "custom/74bct8374". 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. "DW_PACKAGE". you compile the ITL files and move on in the normal board development process. 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. The TAP port connections (including a TRST* pin) are all made to IC 2u8. 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. each of these is proceeded by a pad keyword as well. "custom/74bct8374". The PCF that is inserted is designed to program the 5-86 . This means that you will need to turn on the Global Boundary-Scan Chain Override. IC 2u8 is a linker/multiplexor IC. per the © Agilent Technologies 2002. "custom/74bct8374". "DW_PACKAGE". If there had been other secondary chains connected to the MUX/Linker IC. 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). In the devices section. for a chain that consists of a MUX/Linker and one secondary chain. called. EXAMPLE 2: Following is the ITL source file for an interconnect test. The list object function generates a new board file with the chain structure described at the very end. You discover a TI 74ACT8997 chip and two subchains on the board. for example. Now. This causes the linker to configure itself to control two subchains linked as one. You edit the ITL files to add in the pad bits and a pointer to the PCF fragment. "linker". "2u4". Note that in the chain section. linker_setup under the digital directory. You edit the file as shown in the preceding section to perform the graft. 2003 Boundary-Scan Guide no no no no TI74ACT8997 data sheet. The program generation process continues until the ITL files for Boundary-Scan are created by IPG. "DW_PACKAGE". as shown in the next example. "custom/74act8997".

The rest of the ITL is unchanged from an interconnect description for a normal chain. 2003 Boundary-Scan Guide 5-87 . The end result when this linkage is completed is a chain of 5 devices. 2u1 through 2u2. © Agilent Technologies 2002. to the first multiplexor port. 2u1 through 2u8.Chapter 5: Testing Boundary-Scan Device Chains linker/multiplexor IC to connect the other ICs.

"2IN_28" unit "disable" pcf "11" end pcf end unit end disables nodes © Agilent Technologies 2002. "custom/74bct8374".hybrid tdo "2MTDO" channel. "2u2".Chapter 5: Testing Boundary-Scan Device Chains Example 5-7 --------------------------interconnect "mux_2u1_2u8" chain "2u1_2u8" tdi "2MTDI" channel.hybrid trst "2MTRST" channel.hybrid default "1" pcf order is nodes "2IN_26". "custom/74act8997". no no no no no disables node "2IN_26" channel. "DW". "2u4".hybrid tck "2MTCK" channel. "custom/74bct8374". 2003 Boundary-Scan Guide 5-88 .hybrid default "1" node "2IN_28" channel. end devices insert "digital/2u8_setup" end chain "DW_PACKAGE".hybrid devices pad "2u1". "DW_PACKAGE". "DW_PACKAGE". "DW_PACKAGE".hybrid tms "2MTMS" channel. "custom/74bct8374". "2u8". "custom/74bct8374". "2u3".

2".2" silicon node "2U4_3" test "2u3.16"."2u4.20" silicon node "2U1_U3_7" test "2u1.22" silicon node "2U3_2" test "2u3.23" silicon node "2U1_4" test "2u1.9" silicon node "2U1_U3_9" test "2u4."2u3. This 8-bit register is loaded with two-bit fields that connect the desired Secondary Scan Paths (SSP1 in this case). PCF vectors © Agilent Technologies 2002."2u2."2u4."2u3. Then. The PCF fragment loads the Mux/Linker Instruction Register with the SCANSEL instruction which targets the SELECTR register. just the portion (fragment) between the two Run-Test/Idle states is 5-89 .3"."2u4.21" silicon node "2U4_2" test "2u1.4".17".5".7" silicon node "2U1_U3_7" test "2u4.3". This fragment of PCF code assumes the MUX/Linker IC is already in the Run-Test/Idle TAP state. 2003 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.16" silicon node "2U1_U3_10" test "2u1.4".19" silicon node "2U1_U3_8" test "2u1."2u4.22" silicon node "2U3_4" test "2u3."2u4.10".15" silicon node "2U2_2" test "2u1.15".3" 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."2u3."2u2."2u2.20".19"."2u3.20"."2u2."2u2. and developing a PCF test program that loads SELECTR with the appropriate control bits as specified by the data sheet.10" silicon node "2U1_U3_10" test "2u4. This fragment was prepared by using the Scan Port Driver (SPD) program with a BSDL description of the MUX/Linker IC."2u2."2u2.2".Chapter 5: Testing Boundary-Scan Device Chains fixed low "1IN_16" test "2u3.23" silicon node "2U3_3" test "2u3.21"."2u4.9".21".7"."2u2.8" silicon node "2U1_U3_8" test "2u4."2u2.21" silicon node "2U1_5" test "2u1.17" silicon node "2U1_U3_9" test "2u1.24" silicon node "2U1_2" test "2u1.2" silicon node "2U2_3" test "2u2.8".

© Agilent Technologies 2002. it does not connect any SSP. 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. discarding the rest.Chapter 5: Testing Boundary-Scan Device Chains retained. stored in the digital directory. and referenced by the ITL insert statement as shown in the ITL above. This saves the effort of programming the MUX/Linker manually. 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. Note that when the MUX/Linker has been reset. 2003 Boundary-Scan Guide 5-90 . The completed PCF fragment should be given a meaningful name. Just as the MUX/Linker is finishing being programmed. This is how the ICs of the newly linked chain(s) and the linker all end up synchronized together in Run-Test/Idle.

2003 Boundary-Scan Guide 5-91 . "000L1"!2+0 "100X1" "001X1"!1 "101X1" "001L1"!2 "101X1" "001L1"!3 © Agilent Technologies 2002.Chapter 5: Testing Boundary-Scan Device Chains 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." 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).1-1990 Integrity Failure" message " Device 2U8 has failed.

" message " suspect device or these pins:" message " (tck) 15" message " (tms) 14" message " (tdi) 16" message " (tdo) 13" message " (trst) 26" pcf use pcf order Scan "001X1"!0+0 "101X1" "001X1"!1 © Agilent Technologies 2002. end pcf message "IEEE Std 1149.Chapter 5: Testing Boundary-Scan Device Chains "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" "11ZX1"!Select-DR-Scan "00ZX1" "10ZX1"!Capture-DR "00ZX1" "10ZX1"!Shift-DR ! Loading device 2U8 register SELECTR[8] (for SCANSEL). 2003 Boundary-Scan Guide 5-92 .1-1990 Integrity Failure" message " Device 2U8 has failed.

the test continues from the Run-Test/Idle state. the SSPs are also held in Test-Logic-Reset.Chapter 5: Testing Boundary-Scan Device Chains "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. When in this state. you will see © Agilent Technologies 2002. The rest of the test proceeds as usual and has been deleted for brevity. now with all the chain devices being connected and synchronized. 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). One exception to this is the addition of Pad Bit shift states (for example. see around vector 175). The vectors start out by sending the MUX/Linker to Test-Logic-Reset. This accounts for the position of a pad bit inserted in the 5-93 . After this. 2003 Boundary-Scan Guide the inclusion of the PCF fragment that programs the MUX/Linker at vector 28.

2003 Boundary-Scan Guide 5-94 . © Agilent Technologies 2002. The test is appropriately phased to account for the positions of all pad bits.Chapter 5: Testing Boundary-Scan Device Chains chain by the MUX/Linker.

TRST !Column-to-Node Map. 2003 Boundary-Scan Guide 5-95 . TDI. pcf order Disable is D000. Nodes 1 to 5 !22222! !MMMMM! !TTTTT! !CMDDR! !KSIOS! ! T! ! ! ! ! unit "Interconnect Test" ! Vector 1 pcf use pcf order Scan © Agilent Technologies 2002. TDO.Chapter 5: Testing Boundary-Scan Device Chains 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. D001 TMS.

2003 Boundary-Scan Guide 5-96 .Chapter 5: Testing Boundary-Scan Device Chains "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" "10ZX1"!Run-Test/Idle ! © Agilent Technologies 2002.

"000L1"!2+0 "100X1" "001X1"!1 "101X1" "001L1"!2 "101X1" "001L1"!3 "101X1" "001L1"!4 © Agilent Technologies 2002." 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). ! ! 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. 2003 Boundary-Scan Guide 5-97 .Chapter 5: Testing Boundary-Scan Device Chains ! Including PCF from file digital/2u8_setup.1-1990 Integrity Failure" message " Device 2U8 has failed.

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

" message " suspect device or these pins:" © Agilent Technologies 2002.1-1990 Integrity Failure" message " Device 2U8 has failed.Chapter 5: Testing Boundary-Scan Device Chains "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 ! ! End of PCF from file digital/2u8_setup. 2003 Boundary-Scan Guide 5-99 . ! 56 vectors inserted. ! "01ZX1" "11ZX1"!Select-DR-Scan "01ZX1" "11ZX1"!Select-IR-Scan "00ZX1" "10ZX1"!Capture-IR "00ZX1" "10ZX1"!Shift-IR end pcf message "IEEE Std 1149.

1-1990 Integrity Failure" message " Device 2U4 has failed.Chapter 5: Testing Boundary-Scan Device Chains message " (tck) 15" message " (tms) 14" message " (tdi) 16" message " (tdo) 13" message " (trst) 26" pcf use pcf order Scan "000H1"!0+0 "100X1" "001L1"!1 "101X1" ! Loading device 2U8 with instruction BYPASS(11111111)." message " suspect device or these pins:" message " (tck) 13" message " (tms) 12" message " (tdi) 14" message " (tdo) 11" pcf use pcf order Scan "001H1"!6 "101X1" © Agilent Technologies 2002. "001L1"!2+0 "101X1" "001X1"!1 "101X1" "001L1"!2 Vector 100 "101X1" "001L1"!3 "101X1" "001L1"!4 "101X1" "001X1"!5 "101X1" end pcf message "IEEE Std 1149. 2003 Boundary-Scan Guide 5-100 .

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

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

2003 Boundary-Scan Guide 5-103 .Chapter 5: Testing Boundary-Scan Device Chains message " suspect device or these pins:" message " (tck) 13" message " (tms) 12" message " (tdi) 14" message " (tdo) 11" pcf use pcf order Scan "001H1"!6 "101X1" "001L1"!7 "101X1" ! Loading device 2U1 with instruction BYPASS(11111111). "001L1"!34+0 "101X1" "001L1"!1 "101X1" "001L1"!2 "101X1" "001L1"!3 "101X1" "001L1"!4 "101X1" "001H1"!5 "101X1" "001X1"!6 "101X1" "001L1"!7 "101X1"! Vector 175 ! Shifting Pad Bit "01ZH1"!42+0 "11ZX1"!Exit1-IR "01ZX1" "11ZX1"!Update-IR end pcf message "" pcf © Agilent Technologies 2002.

If one of these devices has a large number of output pins that will be exercised during a connect test. you should carefully consider boundary-scan devices that will employ connect tests. refer to Addressing Ground-Related Problems on page 5-126. you should consider assigning the CRITICAL attribute to the TCK node(s) when you describe your devices. and grounding issues become a problem. grounding should be increased to prevent inadvertent state changes. 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. 2003 Boundary-Scan Guide Assigning Critical Attribute to TCK To ensure signal quality and fidelity.Chapter 5: Testing Boundary-Scan Device Chains use pcf order Scan "01ZX1" "11ZX1"!Select-DR-Scan "00ZX1" < remainder deleted > --------------------------- Best Practices for Developing Boundary-Scan Tests To ensure successful implementation of your boundary-scan tests. Removing Physical Probes Use the conservative approach to removing physical probes. some of these probes can be eliminated so the connect test requires fewer testhead resources. In particular. Make sure that all issues have been considered before removing probes. 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. © Agilent Technologies 2002. ■ If you have nodes that have only boundary-scan devices connected to them (100% boundary-scan 5-104 . For more information on this topic. Some issues that can influence the need to remove probes include: ■ If many nodes are duplicated in connect/interconnect tests.

non-boundary-scan devices connected to them. 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).Chapter 5: Testing Boundary-Scan Device Chains nodes). 2003 Boundary-Scan Guide situations are based primarily on the type of node that you are considering for removal. you could remove these probes. and you are willing to write a Silicon Nails test for these devices. you should ensure that particular boundary-scan node has a probe assigned to it to detect shorts during standard. These © Agilent Technologies 2002. you could remove these probes to free up resources for other needs. ■ ■ If you have nodes that have simple. 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. The following list 5-105 . unpowered shorts testing.

but you would be trading off in-circuit test coverage. • 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. the core logic of the devices in the chain are disconnected from the rest of the board. This action could restrict IPG's ability to provide proper disable methods for a test. Simpler digital devices can still be tested using the Silicon Nails technique. Probes are recommended for these nodes. Test probes are recommended for all partial boundary-scan nodes. and the core logic is reconnected to the 5-106 . 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. or output pins with monitoring capability qualify a node as a full boundary-scan node. Removing probes © Agilent Technologies 2002. 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. ■ Full boundary-scan node: Has a least one boundary-scan driver and at least one boundary-scan receiver. ■ Partial boundary-scan node: Has one or more boundary-scan drivers or one or more boundary-scan receivers. 2003 Boundary-Scan Guide from these nodes could result in reduced fault coverage. which probably will affect other devices operating in normal mode. • Analog node: Node with at least one analog device (but no conventional digital devices) can have probes removed. all the boundary-scan devices go into BYPASS.Chapter 5: Testing Boundary-Scan Device Chains outlines the different types of nodes and their characteristics. Other devices exchanging data with boundary-scan devices will consider the boundary-scan devices inoperable. • 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. but not both. NOTE You should not remove probes from disable control nodes. Realize that when the board comes out of boundary-scan mode. When going into boundary-scan testing. Note that bidirectional.

■ Category 4: Nodes that do not have probes assigned but probes are needed. you should try adding a power cycling or reset sequence to your test. IPG determines if probe access is needed for each node and whether the node already has probes assigned. or board power must be cycled. but the board and the boundary-scan devices do not necessarily pick up where they left off. now belong to Category 3. ■ Category 3: Nodes that do not have probes assigned and probes are not needed. You will notice a shift in how the nodes are categorized. If you have multiple chains. a new testability report is generated. You might need to cycle power between tests to clear the problems. If you have problems with connect tests and/or disabling difficulties. nodes that previously belonged to Category 1. 2003 Boundary-Scan Guide 5-107 . you can easily transfer the reported information into the board_xy file and rerun IPG. the software writes the power cycling procedure for you. To make the changes that IPG recommends. the board reset procedure must be run. and nodes that previously belonged to © Agilent Technologies 2002. If you modify the board_xy file with the changes reported in the testability report and rerun IPG. ■ Category 5: Nodes that do not have probes assigned but probes are needed for powered shorts testing. ■ Category 2: Nodes that have probes assigned and the probes should not be removed. That is. Five categories of nodes are reported: ■ Category 1: Nodes that have probes assigned but the probes can be removed.Chapter 5: Testing Boundary-Scan Device Chains I/O pins. be aware that interactions between chains can be a problem. Reset sequence procedures (particular to each board) and procedures for manually generated tests must be added to the testplan manually. NOTE For automatically generated boundary-scan tests. IPG generates a testability report that includes recommendations about probe requirements for nodes. Boundary-Scan Node Testability Report If you have the optional InterconnectPlus software. To get the board back to normal operating mode. You can do this by adding a reset sequence or power cycling procedure to your testplan.

This section contains an example of a formatted testability report for an interconnect test named u1_u4. you would enter: execute "fmt -t u1_u4_tr ipg/raw".Chapter 5: Testing Boundary-Scan Device Chains Category 2. For each node category in the report there is an explanation of why the nodes were included in that category. 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. to output the formatted information to the screen for an interconnect test name u1_u4. 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. You can also direct the output to a file and then load or print that file to view the information. These nodes are no longer tested by connect testing and require user-written tests for fault coverage. 2003 Boundary-Scan Guide 5-108 . To output the testability report for u1_u4 in a file named u1_u4_details. You can execute the format program with the fmt statement in a BT-BASIC window to format the information in the ipg/raw file. You must be careful about nodes that shift from Category 2 to Category 4. which must be formatted before you can read it. you would enter (on one line): © Agilent Technologies 2002. For example. now belong to Category 4. The information for the test u1_u4 is tagged in the ipg/raw file as u1_u4_tr. wait Note that you must append the string _tr to the name of the interconnect test to acquire the testability report for that test.

! BSdvr:0 BSrcv:1 dig:0 nondig:0 !NODE IN_23 NO_PROBE. ! BSdvr:0 BSrcv:1 dig:0 nondig:0 © Agilent Technologies 2002. ! BSdvr:0 BSrcv:1 dig:0 nondig:0 !NODE IN_21 NO_PROBE. |Comment key: "BSdvr" is the number of BScan drivers on a node. The listing below lists the nodes in a format that can easily be transferred into the board_xy file. | | "nondig" is the number of analog (etc. and probes should be kept) These nodes might not have the resources for Boundary-Scan Interconnect testing or. | Category 1 Nodes (Have probes. ! BSdvr:2 BSrcv:2 dig:0 nondig:0 Category 2 Nodes (Have probes.Chapter 5: Testing Boundary-Scan Device Chains Example 5-10 Formatted testability report "u1_u4_tr" BOUNDARY-SCAN NODE TESTABILITY REPORT.) pins. ! BSdvr:1 BSrcv:0 dig:0 nondig:0 !NODE OUT_10 NO_PROBE. 2003 Boundary-Scan Guide 5-109 . Remove the comment (~!) to remove the probe. NODE U1_U3_10 NO_PROBE. The listing below lists the nodes in a format (commented) that can easily be transferred into the board_xy file. Removing probes from these nodes might reduce fault coverage or cause the need for additional user-written tests. !NODE IN_05 NO_PROBE. ! BSdvr:0 BSrcv:2 dig:0 nondig:1 !NODE IN_17 NO_PROBE. ! BSdvr:0 BSrcv:1 dig:0 nondig:0 !NODE IN_22 NO_PROBE. ! BSdvr:0 BSrcv:1 dig:0 nondig:0 !NODE IN_20 NO_PROBE. Be aware though that user-written tests might require probes on some of these nodes or. other device pins exist on them that might require probes to support their test. ! BSdvr:0 BSrcv:1 dig:0 nondig:0 !NODE IN_19 NO_PROBE. | | "BSrcv" is the number of BScan receivers. 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. some of these probes might be needed for unusual disabling situations. ! BSdvr:0 BSrcv:1 dig:0 nondig:1 !NODE OUT_09 NO_PROBE. | | "dig" is the number of conventional digital pins. ! BSdvr:0 BSrcv:1 dig:0 nondig:1 !NODE IN_24 NO_PROBE. ! BSdvr:1 BSrcv:0 dig:0 nondig:0 !NODE IN_16 NO_PROBE.

! BSdvr:1 BSrcv:0 dig:0 nondig:0 !NODE OUT_06 NO_PROBE. ! BSdvr:0 BSrcv:1 dig:0 nondig:0 !NODE IN_11 NO_PROBE. NODE U3_4 ! BSdvr:1 BSrcv:1 dig:0 nondig:0 NODE U1_U3_9 ! BSdvr:2 BSrcv:2 dig:0 nondig:0 NODE U1_U3_8 ! BSdvr:2 BSrcv:2 dig:0 nondig:0 NODE U1_U3_7 ! BSdvr:2 BSrcv:2 dig:0 nondig:0 NODE U1_5 ! BSdvr:1 BSrcv:2 dig:0 nondig:0 NODE U1_4 ! BSdvr:1 BSrcv:1 dig:0 nondig:0 NODE U1_3 ! BSdvr:1 BSrcv:1 dig:0 nondig:0 NODE U1_2 ! BSdvr:1 BSrcv:1 dig:0 nondig:0 Category 4 Nodes (Have no probes. ! BSdvr:1 BSrcv:0 dig:0 nondig:0 !NODE OUT_05 NO_PROBE. other device pins exist on them that might require probes to support their test. NODE U4_10 ! BSdvr:1 BSrcv:0 dig:1 nondig:0 NODE U4_9 ! BSdvr:1 BSrcv:0 dig:1 nondig:0 NODE U4_8 ! BSdvr:1 BSrcv:0 dig:1 nondig:0 © Agilent Technologies 2002. ! BSdvr:0 BSrcv:1 dig:0 nondig:0 !NODE IN_06 NO_PROBE. 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. Adding probes will allow them to be tested. Not adding probes will reduce fault coverage or cause the need for additional user-written tests. ! BSdvr:0 BSrcv:1 dig:0 nondig:0 !NODE IN_10 NO_PROBE. ! BSdvr:1 BSrcv:1 dig:1 nondig:0 !NODE IN_18 NO_PROBE.Chapter 5: Testing Boundary-Scan Device Chains !NODE U3_3 NO_PROBE. and probes should be added) These nodes might not have the resources for Boundary-Scan Interconnect testing. ! BSdvr:0 BSrcv:2 dig:0 nondig:1 !NODE IN_04 NO_PROBE. ! BSdvr:1 BSrcv:0 dig:0 nondig:0 !NODE IN_03 NO_PROBE. ! BSdvr:0 BSrcv:1 dig:0 nondig:0 Category 3 Nodes (Have no probes. ! BSdvr:0 BSrcv:1 dig:0 nondig:1 !NODE OUT_04 NO_PROBE. ! BSdvr:0 BSrcv:1 dig:0 nondig:0 !NODE IN_07 NO_PROBE. or. ! BSdvr:0 BSrcv:1 dig:0 nondig:0 !NODE IN_08 NO_PROBE. ! BSdvr:1 BSrcv:1 dig:1 nondig:0 !NODE U3_2 NO_PROBE. ! BSdvr:0 BSrcv:1 dig:0 nondig:1 !NODE IN_12 NO_PROBE. They have already had probes removed. ! BSdvr:0 BSrcv:1 dig:0 nondig:0 !NODE IN_09 NO_PROBE. 2003 Boundary-Scan Guide 5-110 .

Chapter 5: Testing Boundary-Scan Device Chains

NODE U4_7
! BSdvr:1 BSrcv:0 dig:1 nondig:0
NODE U4_5
! BSdvr:1 BSrcv:0 dig:1 nondig:0
NODE U4_4
! BSdvr:1 BSrcv:0 dig:1 nondig:0
NODE U7_6
! BSdvr:0 BSrcv:1 dig:1 nondig:0
NODE U7_5
! BSdvr:0 BSrcv:1 dig:1 nondig:0
NODE U2_10
! BSdvr:1 BSrcv:0 dig:1 nondig:0
NODE U2_9
! BSdvr:1 BSrcv:0 dig:1 nondig:0
NODE U2_8
! BSdvr:1 BSrcv:0 dig:1 nondig:0
NODE U2_7
! BSdvr:1 BSrcv:0 dig:1 nondig:0
NODE U2_5
! BSdvr:1 BSrcv:0 dig:1 nondig:0
NODE U6_3
! BSdvr:0 BSrcv:1 dig:1 nondig:0
Category 5 Nodes (Have no probes, and probes should be added)
These nodes are capable of being shorted to Boundary-Scan nodes that
cannot be tested by the Powered Shorts algorithm for lack of
accessibility. These nodes are typically ordinary digital/analog
nodes, though some nodes here might also appear in category 4. Adding
probes will allow Powered Shorts testing. If probes are not added, then
coverage will be reduced or these shorts must be tested with some other
user-written test.
NODE U3_TDO
NODE U1_TDO

© Agilent Technologies 2002, 2003

Boundary-Scan Guide

5-111

Chapter 5: Testing Boundary-Scan Device Chains

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.

© Agilent Technologies 2002, 2003

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

Chapter 5: Testing Boundary-Scan Device Chains

Table 5-8

Selected IDs Used to Illustrate Aliasing

A

0

0

0

1

0

B

0

0

1

1

0

C

0

1

0

1

0

D

1

0

0

1

1

E

0

1

1

1

0

ID (00010000). This provides increased resolution for
the software to distinguish one node from another.
Table 5-9
A

0

0

0

1

0

1

0

1

B

0

0

1

1

0

1

0

0

C

0

1

0

1

0

1

0

1

D

1

0

0

1

1

0

0

1

E

0

1

1

1

0

1

0

0

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:



© Agilent Technologies 2002, 2003

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

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. Diagnosis is provided to the node level only. In this situation. 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. 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. an open circuit on the driver will also alias to this problem. 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. 2003 Boundary-Scan Guide 5-114 . 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. These causes are deduced from the failure analysis of the cell information discussed in the next section. • In the case where no cells are associated with the active driver (the output is two-state or three-state only). Understand that these causes might be due to a variety of physical symptoms in the circuit itself. ■ 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. the bus test will identify the problem more accurately than the interconnect test. a two-state or three-state driver). 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. The physical causes for Open Circuit could be: © Agilent Technologies 2002.Chapter 5: Testing Boundary-Scan Device Chains • A short to one or more nodes that are also solely under the control of the Boundary Register. This will be diagnosed if all data captured on a node is fixed and unchanging. ■ 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.

but the variations in the receiver thresholds on the node under investigation are such that the receivers observe different characteristics from the active drivers. Use the pin list associated with this message to check the most probable locations for the problem. or the node(s) that failed. but the drive capacity of the fixed node is too weak to hold the node to a fixed level. Other examples are provided at the end of this section. probably shorted to fixed node — The identified node is not toggling. ----------------------------------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 -. an open circuit. • A short circuit to a fixed node has occurred.3 u2. after the descriptions of the messages that you could see during testing. but it is strong enough to cause device receivers to see different data because of the variations in their receive thresholds.23 U1_3 -. This message includes a list that provides the device and pin(s). then it is probable that the failing receivers are not connected to the node.pins: u1. but possible in the case of Chip On Board or Multichip Module technology using wirebond techniques). ■ Unknown Failure: This is diagnosed whenever the symptoms for a node are inconsistent with those of a short circuit. or a combination of both.22 ----------------------------------■ Node <nodename> is stuck. • If some of the receivers on the node receive good data.Chapter 5: Testing Boundary-Scan Device Chains • If all receivers are stuck-at.pins: u1. then it is probable that the active driver is not connected to the node. 2003 Boundary-Scan Guide packaged devices are used. 5-115 . a message that describes the failure is sent to the report device. • A combination of shorts and opens exist on the node such that the variations in the receive patterns is seen. The following is one example of such a message. but it is also possible that an open can cause this diagnosis. The cause is probably a short to either power or ground. Results Analysis: Messages When a boundary-scan test fails. • 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 © Agilent Technologies 2002.2 u2. The physical causes for this could be: • A short circuit to a node has occurred.

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.<pin> — The failing node is stuck. these pins should also be checked for a short to power or ground — The node is stuck.Chapter 5: Testing Boundary-Scan Device Chains ■ ■ © Agilent Technologies 2002. if three or more nodes are listed. ■ Node <nodename> is stuck. but the shorted node cannot be located. so the problem cannot be diagnosed beyond the two pins listed. but the most probable cause of the problem is an open on the device. it is possible (though unlikely) that one of the listed nodes is not actually shorted (aliasing). but that the identified pin is stuck. it cannot be sure. 2003 A short has been detected between the following nodes — The node/pin list identifies all nodes and pins associated with the failure. The cause is probably an open on this pin alone. and that node has only one driver and one receiver connected to it. the most probable cause of the problem is fixturing. probable open on <device>. all pins (that will always be output or bidirectional pins) have been detected open by the test. Probably a short. Another diagnosis will list all inputs and bidirectional pins that fail. in analyzing the nodal activity. no additional data is available from other receivers on the node. Because bidirectional pins are verified in both directions. Pins involved are: — All of the inputs on a particular node observe it toggling in the same manner. 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.pin identified. The difference between this message and the previous one is that the RA routine. In this case. A short to VCC or ground could also be the cause. all device outputs or bidirectional pins that have failed are listed. Node <nodename> is failing. ■ Pin is stuck. suspect open on <device>. an actual open should cause that pin to be listed both here and in the Opens on Input or Bidir Pins diagnosis. has determined that the node probably is not shorted. If this does not occur.<pin>. this message occurs only for 5-116 .<pin> or <device>. ■ Opens on Input or Bidir Pins — Like its companion message. with the use of the deterministic algorithm. ■ Node <nodename> is stuck. or a failure in the I/O section of the device being tested. ■ Opens on Output or Bidir Pins — During a connect test. ■ The following pins are detected open: — During a buswire test. so you should check for a short to power or ground. However. Check the pin list to identify the most likely places for the failure. however. Note that.

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. non-disabled devices and so on. It lists the input or bidirectional pins detected as open (see the previous message for further information). ■ Unexplained nodal activity. Over Power Detected on TDI. a driver pin list will locate the exact point of the failure. but have been added to accommodate the unlikely occurrence of testhead hardware failure. or a pin bent such that it is disconnected from its proper node and is making contact with an adjacent node. but if one does occur. ■ ■ ■ © Agilent Technologies 2002. Specifying safeguard none to resolve this condition could work. This can occur if a device on a boundary-scan node is not disabled and is (possibly) toggling asynchronously with the testhead drivers. NOTE The following messages rarely appear. We do know that the node identified is bad. but its cause cannot be classified within any of the other categories. These failures are extremely rare.Chapter 5: Testing Boundary-Scan Device Chains connect tests. The test engineer should look for a mis-wired fixture. 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. The cause is probably a high-current overdrive situation. Boundary-Scan Guide ■ Over Power Detected On: — Connect tests do not have the same execution time constraint as interconnect tests. (check for non-disabled device(s) — Injected noise in the circuit grounds cause the identified device to perform in a completely unexpected fashion. ■ Node <nodename> failed for unknown reason — The system detected a failure on this node. no pin diagnosis of an over power condition on a testhead driver is performed. This indicates that the diagnosed pin is receiving data. 2003 Suspected open.<pin> — The indicated pin on a node is toggling. noise on the node. the cause is probably that one of the listed nodes includes a device that is being overdriven and is not disabled. but pin toggles: <device>. but might risk device damage. The cause is probably a miswired fixture. If this message is encountered. but not from the node under test. but not in the same manner as all of the other pins on the same node. The message indicates that a non-diagnosable failure has occurred. You should find a way to disable the upstream device. 5-117 .

10 ------------------------------ SWITCH 1.5 However. these pins should also be checked for a short to power or ground: u1. a hardware failure in the testhead.20 ------------------------------ SWITCH 1. ■ Test Failed to Start — Again.2 © Agilent Technologies 2002. This section explains what occurs when selected switches are closed or opened by showing you what the resulting failure messages are. ■ Test Halted Due To Unknown Cause — Again. The most likely cause is a hardware failure in the testhead.Chapter 5: Testing Boundary-Scan Device Chains ■ Test Exceeded Soft Timeout Limit — A failure caused the test to greatly exceed its expected execution time. SWITCH 1.16 ------------------------------ SWITCH 1.5 u2. suspect open on u1. suspect device or these 5-118 .1-1990 Integrity Failure Device U1 has failed. the most likely cause is a failure in the testhead hardware.4 -----------------------------Thu Jan 09 17:50:06 1992 -----------------------------INTERCONNECT FAILURE DETECTED FOR TEST DIGITAL/u1_u4 Failing Vector #: 26 IEEE Std 1149. you will see several switches. If you look closely at the schematic. These switches are used to insert failures into the sample circuit. The following are examples of device failure reports for the example circuit found at the end of this chapter.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.3 -----------------------------Thu Jan 09 17:50:06 1992 -----------------------------INTERCONNECT FAILURE DETECTED FOR TEST digital/u1_u4 Node U1_5 is stuck. 2003 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. Closing or opening each switch (or a combination of switches) produces various failures.20 u4.

If you have access to such a board and fixture.5 -----------------------------Thu Jan 09 17:50:06 1992 -----------------------------INTERCONNECT FAILURE DETECTED FOR TEST digital/u1_u4 Pin is stuck. you can test the board and insert these faults to see what the resulting failures will be. 2003 Boundary-Scan Guide 5-119 . © Agilent Technologies 2002.20 connected to node U1_5. check for open on u2. ------------------------------ Note that closing or opening other switches on the sample circuit produce different failures and failure messages.Chapter 5: Testing Boundary-Scan Device Chains pins: (tck) 13 (tms) 12 (tdi) 14 (tdo) 11 ------------------------------ SWITCH 1.

The source files associated with debug are the VCL files created by MSPD. 2003 Boundary-Scan Guide 5-120 . © Agilent Technologies 2002.Chapter 5: Testing Boundary-Scan Device Chains Debugging Boundary-Scan Tests Boundary-Scan tests use Agilent Pushbutton Debug just as standard digital tests do.

Chapter 5: Testing Boundary-Scan Device Chains Figure 5-43 Boundary-Scan debug Test Needs to be Debugged Yes Verified BSDL No Do We Trust 1149. For more information about digital debug. refer to © Agilent Technologies 2002. 2003 Boundary-Scan Guide 5-121 .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.

NOTE A Chain Debug test is not a production test. The Chain Debug test measures chain bit lengths two ways: ■ © Agilent Technologies 2002. When the test compiles. Change this keyword to debug. The first keyword in the file (for example.1 has not been complied with. ■ If the Chain Debug test passes. 2003 The test measures the length of the combined devices instruction registers and compares this Boundary-Scan Guide 5-122 . perform the Board Debug test from the menu. Remember to restore the original test. it first measures the length of the combined instruction registers of every IC in the chain. For example. When the Chain Debug test executes.1 is complied with? If no. ■ If you feel that 1149. It is only used for debugging purposes and should be deleted when debugging is complete. perform either the Chain Debug test or the Verification of BSDL test. A dedicated fixture may be necessary. This requires full modal access to the device.Chapter 5: Testing Boundary-Scan Device Chains ■ Is the BSDL verified? If yes. If you have no idea which device is bad. or the Verification test can be ported to a simulation model of the device.1 is complied with. a choice is available: ² ² If you have a good idea which device is bad. Debugging BSDL and Compliance Problems length with what the expected BSDL lengths should be. Load the file into the Basic editor. perform Verification of BSDL on that device. Save the file and recompile it. you suspect a problem with a chain of four devices called U1_U4. do you feel that 1149. it utilizes the fixture resources allocated to the original test. ■ If you trust that 1149. A Chain Debug test can be created very simply from an existing ITL file. ■ The test measures the lengths of boundary registers iteratively and compares this length with what the expected lengths should be. perform the Board Debug test from the menu. interconnect) identifies the type of test it will generate. perform a Chain Debug test to isolate a bad device and when isolated perform the Verification of BSDL test.

for U1 too long ---------------------------------------- 5-123 . 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. This division will help remove confusion. you may want to partition the chains into shorter segments (provided you have access to TDI and TDO pins within the chain). a failure is specific to one device. a Chain Debug test DOES NOT perform a TAP integrity test. The IC in SAMPLE has its boundary register measured. then the instruction length test will pass. 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. you will get a failure ticket saying the measured length was too long or short.Chapter 5: Testing Boundary-Scan Device Chains NOTE When executed. The second check a Chain Debug test makes after measuring the instruction registers is to iteratively measure the boundary register of each IC. It cannot identify which device has the incorrect length because 1149. One reason for debugging chains is that you already know there is an integrity problem and you are trying to get additional debug information. u1_u4 HAS FAILED vector = 529 Status: 15H Pass/Fail error on following pins: BRRCC NODE PIN 22203 TDO Boundary Reg. If the expected length of the instruction registers is different than what the BSDL files for the ICs described.1 cannot individually access the instruction registers within a chain. The IC to be tested is placed in SAMPLE while all others in the chain are placed in BYPASS. In this way. Each IC is tested successively until one is found that does not match it’s © Agilent Technologies 2002. If two devices are incorrect with one device one bit too long and the other device one bit too short. 2003 Boundary-Scan Guide BSDL description. If you have concern for the accuracy of the BSDL descriptions of your devices.

vcl (u1_u4. temporary solution to a problem 5-124 . Edit the VCL file if you: To debug boundary-scan tests. Uppercase letters are not permitted in source-file names.vcl identifies a connect test for u4. NOTE ■ want to change the TAP-only setting (no to yes). u1_connect) Debugging these tests relies on the VCL source for the test itself. the pathname The following guidelines should help you decide which file to edit. u1_u4) ■ buswire test<device X>_<device Y>_bus.vcl) ■ connect test<device X>_connect (for example.vcl) ■ interconnect test<device X>_<device Y> (for example. you can: ■ © Agilent Technologies 2002. ■ want to comment out a particular test or node that is causing an unsolvable problem.vcl) ■ buswire test<device X>_<device Y>_bus (for example. u1_u4_ps) ■ interconnect test<device X>_<device Y>. /user1/scan_brd/digital/u4_connect.vcl (u1_connect. This source file can be found in the digital directory under the names shown above. u1_u4_bus) ■ connect test<device X>_connect. For example. 2003 use Pushbutton Debug.Chapter 5: Testing Boundary-Scan Device Chains 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.vcl (u1_u4_ps.vcl (u1_u4_bus.vcl) ■ powered shorts test <device x>_<device y>_ps (for example. ■ want to add or correct device disable information. Edit the ITL file if you: ■ have problems with specific nodes. They are named as follows: ■ powered shorts test<device X>_<device Y>_ps. 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.

compile digital/<device_name>_connect. type: © Agilent Technologies 2002. you will find frame and end frame statements. 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). When the file has been compiled. The data in between these two statements consists of the information shifted out from the active. the contents of the test dictionary appear at the end of the test as a comment. Boundary-Scan Guide 5-125 . 2003 This digital test is in pattern capture format (PCF). However. NOTE Both VCL and ITL tests are compiled from BT-BASIC by using the compile command. However.vcl. the test debug object will be created. and increases as you approach TDI). Additionally. 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. and it is well-commented so you can easily examine the test and determine what is happening. concatenated registers of the chain during one phase of the test. node. Because the ITL file is compiled when you run IPG Test Consultant. only ITL can be compiled from IPG Test Consultant. 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).Chapter 5: Testing Boundary-Scan Device Chains You should not alter the VCL file as a permanent solution except as a last resort. If you want to make a change permanent. Under no circumstances should you alter the length of the chain. in a BT-BASIC window. and boundary-register location associated with that data (the boundary-cell number closest to TDO is 0. 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. or edit the ITL file so that the desired changes are made to the VCL file after you run compile using IPG Test Consultant. you must compile the test with the debug option on (normally. To do this. this is not done because of time and space limitations). Accompanying each pattern set is the identification of the pin. you must compile the VCL file using BT-BASIC. the VCL is re-created after each compile.debug A chain location (listed in the test dictionary) corresponds to a location in a particular frame. expected output data is encoded as H or L). In each two-vector group. In the test itself. You can modify frame data as long as the modification does not alter the relative position of the bits within the frame.

■ Examine the board itself for sufficient ground paths and ground routing schemes. If these paths are long. In most cases. Because the testhead drivers are regulated with respect to ground. For each device involved in a connect test. The resulting current-transition problem can occur exactly as described above because connect test requires physical probes on all tested nodes. The Building Board Test Fixtures documentation provides some information about XG-50 fixtures. all device outputs and bidirectional pins transition together: first to 0 then to 1. the largest number of ground returns should be made available. © Agilent Technologies 2002. For an example ITL source file. These grounds should be well distributed throughout the modules used to test the device. the receiver current flowing into the testhead travels through a relatively small number of ground returns. which typically would occur on transition through UPDATE-DR. The data from frame 1 represents the left-most position in the signature. it will often be necessary to use debug's graphic display of vectors to search. 2003 Boundary-Scan Guide Boundary-scan connect tests are particularly susceptible to the problem because. the device can go through an unwanted state change. would cause the test to fail. one of the following solutions should solve your problem. vector by vector.Chapter 5: Testing Boundary-Scan Device Chains dictionary. for the first occurrence of a bit failure. 5-126 . The change in TAP state. you can comment out the offending node(s) in the test source. ■ Examine the fixture's ground return scheme. because the entire signature must be assembled before failure analysis is started. Contact your Sales representative for details. current-transition period. and if all or most of those outputs transition at once. If you encounter this situation. 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. this can result in an abrupt voltage level change that can inadvertently drive device inputs. Subsequent tests would also fail because the TAP would no longer follow the established testplan. refer to InterconnectPlus Test Language (ITL) on page 5-158. which causes the test to essentially run out of control and fail. the exact location of the first failing bit in a frame is unavailable. If you cannot find the failure using the vector-by-vector search. Addressing Ground-Related Problems If a device has a large number of outputs connected to testhead receivers. For this reason. NOTE You might want to consider using a XG-50 fixture for these applications. If one of the drivers is a clock input. during one part of the test.

2003 Break the problem tests into smaller tests. each of which verifies a percentage of the total nodes. You can name the new sources as you wish.Chapter 5: Testing Boundary-Scan Device Chains ■ © Agilent Technologies 2002. You can do this by duplicating the connect test source and removing all but the requisite number of nodes. 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 .

the time it takes to run a traditional in-circuit test will be multiplied (worst case) by a factor of 2N. The Boundary Register cells act as drivers and receivers for non-Boundary-Scan devices or small clusters of devices located between boundary-scan devices. the result is faster test development. 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. Using Access Consultant to test Silicon Nails devices. In cases where Silicon Nails tests are a good choice for the components being tested. A Silicon Nails test. Silicon Nails Test Development Process The test development process using Agilent 3070 software allows for testing devices for which there may be access limitations. this step has been automated. A Silicon Nails test uses the Boundary Register cells instead of physical probes or nodes. The flowchart in Figure 5-44 shows a typical use case in which Silicon Nails Automation is employed. a Silicon Nails test takes too long to run. Each step is explained in table Table 5-10 on page 5-129. customers will be able to: ■ © Agilent Technologies 2002. In some cases. Silicon Nails in Access Consultant enhances the current suite of Agilent 3070 software by automating the identification of nodes. Analyze devices targeted for Silicon Nails test technique and display nodes where access is required or can be removed. With the inclusion of Silicon Nails Automation. formerly had to be written manually. where N equals the length of the Boundary Register.Chapter 5: Testing Boundary-Scan Device Chains 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. To understand more on using Access Consultant for Silicon Nails testing. which tests a digital pin library device through a boundary-scan chain and 3070 resources. Agilent Access Consultant. To run a Silicon Nails test. 2003 ■ Utilize the current Access Consultant use model. see Chapter 2. Boundary-Scan Guide 5-128 .

Chapter 1 of the Data Formats manual. enter the appropriate option (e. Boundary-Scan Guide 5-129 .g.” See especially the Pin Library section.g. “SN” for Silicon Nails) to the board file. The Silicon Nails Test Strategy section of the Boundary-Scan manual. 2 For each device being tested. Table 5-10 Test development process steps and resources © Agilent Technologies 2002. 2003 Step Information Resources 1 Choose a strategy (e. Silicon Nails) for each device being tested. “The Board File...Chapter 5: Testing Boundary-Scan Device Chains Figure 5-44 Test developer tasks with Silicon Nails Automation Choose strategy 1 Add SN keyword to board file 2 Compile board 3 Generate tests using IPG ITL File 4 Silicon Nails Automation Compile tests 5 Tests Test developer tasks are described in Table 5-10.

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). especially the section titled “Compile the Board and X-Y Data Files.” NOTE: You can do this step using Board Consultant. 4 Generate tests using IPG — this step creates ITL files. “Test Consultant. 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. or the command line. which generates the ITL files. as shown in Figure 5-45. For devices being tested using Silicon Nails. BT-Basic. The device between the boundary-scan devices is typically a non-boundary-scan part or a small cluster. 2003 Boundary-Scan Guide NOTE If a physical nail is present. The Boundary Register cells act as drivers and receivers. © Agilent Technologies 2002. If node access is a real problem. If conventional components co-exist on a node. Chapter 1 of the Test Development Tools manual. For analog 5-130 . part of this step runs Silicon Nails Automation.” 5 Compile tests.Chapter 5: Testing Boundary-Scan Device Chains Table 5-10 Test development process steps and resources (continued) Step Information Resources 3 Compile the board. Silicon Nails will automatically generate a test for digital devices with a library. the best candidates for node removal are nodes on which all components are boundary-scan. but you have the option to manually write a Silicon Nails test for other scenarios. a physical probe is recommended. a Silicon Nails test will not allow you the option to use a silicon nail in place of the nail. The Test and Fixture Development manual.

a physical test probe is preferred for long-term board reliability. If node access cannot be gained. NOTE Silicon Nails is a registered trademark of Agilent Technologies. see Agilent MagicTest. analog in-circuit tests can then be performed. However. Without physical access to all nodes. 2003 Boundary-Scan Guide 5-131 . the safety issue needs further attention. © Agilent Technologies 2002. The concern is the potential for damaging device outputs. the Silicon Nails method is feasible. If given a choice. power must be turned on to find shorts.) For conventional digital components Silicon Nails are an alternative.Chapter 5: Testing Boundary-Scan Device Chains components. but physical probes are still recommended. Testing analog components without physical access is a very difficult test situation (for further information on this. and credible diagnostic resolution can be expected.

Chapter 5: Testing Boundary-Scan Device Chains 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 © Agilent Technologies 2002. 2003 Boundary-Scan Guide DUT Receivers more boundary-scan devices. the device should have a relatively simple test to begin with (when it was in-circuit tested) because 5-132 . First. you should consider a few things.

where N equals the combined length of the active Boundary Registers.Chapter 5: Testing Boundary-Scan Device Chains converting to Silicon Nails testing multiplies the length of the test by a factor of up to 2N. 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). Active Data Register = (u3 + u4 Boundary Registers) + (u1 + u2 Bypass Registers) © Agilent Technologies 2002. The length of the active Boundary Register is determined by the total length of the active registers of the devices connected to the DUT. 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). 2003 Boundary-Scan Guide 5-133 . So if silicon nodes Q. R. and T in Figure 5-46 are connected to the DUT (u7). S.

Chapter 5: Testing Boundary-Scan Device Chains Figure 5-46 Silicon Nails testing on a simple device Bypass Mode Bypass Mode TDI non-boundary-scan device D Flip-Flop L J M K Extest Mode Q R Extest Mode S T TDO © Agilent Technologies 2002. 2003 Boundary-Scan Guide 5-134 .

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).Chapter 5: Testing Boundary-Scan Device Chains NOTE If from one vector to the next. L and M in Figure 5-46. the output from the DUT is captured on the silicon boundary-scan receivers. but the boundary-scan receivers' data must be shifted out. At the same time. a device. During CAPTURE-DR. The following failure messages show the actual messages received when the Silicon Nails test and the nail test are separately written tests. a microprocessor). Test patterns for the silicon node drivers are scanned in to the appropriate drivers and presented during © Agilent Technologies 2002. The probed node's data is compared directly. serialization may be skipped. One reason may be that too many vectors would be needed to test the device. such as u7 shown in Figure 5-46. resulting in a shorter test. How MSPD Coordinates Testing on Devices with Silicon-Nails and Physical Probes Often. Another case in which Silicon Nails testing may not be optimal is when testing dynamic devices. K. the Silicon Nails test strategy is not recommended. will have both Silicon Nails and physical probes connected to it. the vectors are changed on the probed nodes driver. Example 5-11 shows the Silicon Nails test failing a silicon node. UPDATE-DR. only bits on nailed nodes change. 2003 Boundary-Scan Guide 5-135 . the probed node's receiver is turned on so the software can do a compare. the device may not retain its internal memory status and tests will appear to fail. This scenario is represented by J. If the DUT is not a relatively simple device (for example. At the same time. Figure 5-47 shows the portion of the device being tested. When your Silicon Nails test is generated. When a dynamic device receives vectors too slowly.

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. observing node: U6_3. Example 5-12 shows a test failing at a nailed node. connected to pins u1. ----------------------------------------Failed Boundary-Scan frame cell 11 at u1.Chapter 5: Testing Boundary-Scan Device Chains 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. © Agilent Technologies 2002.15 and u6_3. 2003 Boundary-Scan Guide 5-136 .15 is the B-Scan pin with cell 11 on pin 15 • U6_3 is the node connected to pins u1.15.

NOTE Note that ITL file generation is automated only for single devices/pin libraries.6 ----------------------------------------- Figure 5-47 A 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. 6. 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. ----------------------------------------Opens on Output or Bidir Pins U6. 2003 Boundary-Scan Guide 5-137 . © Agilent Technologies 2002. not clusters.Chapter 5: Testing Boundary-Scan Device Chains 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. the nailed output pin. has failed.

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. then re-run IPG Test Consultant. 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 resources for your Silicon Nails test will be assigned just as they are for other tests. pcf Assignment Order When writing test libraries for Silicon Nails. and the test will be added to the final testplan. © Agilent Technologies 2002. or if all library vectors are commented out. you use IPG Test Consultant to move you through the process.Chapter 5: Testing Boundary-Scan Device Chains During normal test development. the pcf assignment order determines the column order for the ITL. As shown in Example 5-13. NOTE There can be more than one pcf statement in your library source code. The test generation process is as follows: If you have a setup library. 2003 Boundary-Scan Guide 5-138 . A setup-only vector is generated if no test vectors are found. add vectors to the library. if you only have a setup library (to generate the fixture requirements file). 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. you must edit the library test syntax and assignment statements in a specific order. To preserve your original statement order. the library source code is used to generate the Silicon Nails Test.

6". 2003 Boundary-Scan Guide 5-139 .U8" inputs "NDIR_1" inputs "NOE_1_bar" bidirectionals "NA1_0" bidirectionals "NA1_1" bidirectionals "NB1_0" © Agilent Technologies 2002. "u23.V8" silicon node "NB1_1" test "u13.A1_0. "u23.U9" silicon node "NB1_0" test "u13.A1_1.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.5".4". "u23.2".V9" silicon node "NA1_1" test "u13. "u23.U10" silicon node "NA1_0" test "u13. "u23.B1_0.DIR_1.Chapter 5: Testing Boundary-Scan Device Chains 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.1" silicon node "NOE_1_bar" test "u13.3".

the values in the pcf statement are different in the two sources. 2003 Boundary-Scan Guide 5-140 . To preserve the pcf order in a Silicon Nails test. shown in Example 5-13. Using the library source code. In Example 5-13 on page 5-139. you would do the following: 1 Edit the library source code. the re-ordered code would look like that shown in Example 5-14. the pcf order is the same as the order of the assign statements in the library file. © Agilent Technologies 2002. 2 Arrange the assign statements in the library source to match the pcf order statement.Chapter 5: Testing Boundary-Scan Device Chains bidirectionals "NB1_1" 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.

5".3".DIR_1.B1_0. "u23.2".B1_1 unit "TEST_ALL_A2B" pcf "0001LH" ! see order above "0110HL" end pcf end unit ! Using this library source. "u23.V9" silicon node "NA1_1" test "u13.6".Chapter 5: Testing Boundary-Scan Device Chains 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.U8" inputs "NDIR_1" inputs "NOE_1_bar" bidirectionals "NA1_0" © Agilent Technologies 2002.A1_0. "u23.V8" silicon node "NB1_1" test "u13.U10" silicon node "NA1_0" test "u13.A1_1. "u23. 2003 Boundary-Scan Guide 5-141 .U9" silicon node "NB1_0" test "u13.1" silicon node "NOE_1_bar" test "u13. the Silicon Nails Test would now be: nodes node "NDIR_1" test "u13.4". "u23.

Chapter 5: Testing Boundary-Scan Device Chains

bidirectionals "NA1_1"
bidirectionals "NB1_0"
bidirectionals "NB1_1"
! 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
"0001LH" ! see order above
"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

© Agilent Technologies 2002, 2003

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

Chapter 5: Testing Boundary-Scan Device Chains

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

© Agilent Technologies 2002, 2003

Boundary-Scan Guide

5-143

Chapter 5: Testing Boundary-Scan Device Chains

Example 5-15 Automated Silicon Nails debug
+5V

1

+5V

1 VCC

GND 2

U1

A 7

3

U3

U1-7

bs005

4 In2
B 8

VCC OE 6

In1

lb005

U1-8

5

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.

© Agilent Technologies 2002, 2003

Boundary-Scan Guide

5-144

"u1.3".Chapter 5: Testing Boundary-Scan Device Chains Example 5-16 ITL file generated by IPG “U3” ! IPG: rev 04. 2003 Boundary-Scan Guide 5-145 . "DIP".4". "custom_lib/bs005".6" inputs "U1-8" inputs "U1-7" outputs "U3-5" set terminators to on pcf order is nodes "U1-7" © Agilent Technologies 2002.7" !IPG: NO PROBE node "U3-6" test "u3.7" silicon node "U1-8" test "u3.5". "u1. no "u2". nodes silicon node "U1-7" test "u3.8" silicon node "U3-5" test "u3. family "TTL" chain "u1_u2" tdi "U1-TDI" tdo "U2-TDO" tms "U1-TMS" tck "U1-TCK" devices "u1". no end devices end chain !IPG: User may add VCL pass-through statements here if needed. "u2.00u2 Wed Mar 28 16:51:12 2001 silicon nail "u3" !IPG: User may add option statements here if needed. "DIP". "custom_lib/bs001".

2003 Boundary-Scan Guide 5-146 . © Agilent Technologies 2002. separate from BT-Basic. node U3-6 is inaccessible. This means that all of the vectors are commented. 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”. leaving a default vector.Chapter 5: Testing Boundary-Scan Device Chains pcf order is nodes "U1-8" pcf order is nodes "U3-5" unit pcf "ZZX" !vector "Default" end pcf end unit end nodes end silicon nail As is shown in the original file.

4". no end devices end chain !IPG: User may add VCL pass-through statements here if needed. "u2.6" inputs "U1-8" inputs "U1-7" outputs "U3-5" and VCL file (u3. nodes silicon node "U1-7" test "u3. "u1. no "u2". "DIP". 2003 Boundary-Scan Guide 5-147 .vtf) are generated: © Agilent Technologies 2002.5".8" silicon node "U3-5" test "u3.3". family "TTL" chain "u1_u2" tdi "U1-TDI" tdo "U2-TDO" tms "U1-TMS" tck "U1-TCK" devices "u1". "custom_lib/bs001". "custom_lib/bs005".7" !IPG: NO PROBE node "U3-6" test "u3.00u2 Wed Mar 28 16:51:44 2001 silicon nail "u3" !IPG: User may add option statements here if needed. "DIP". "u1.itl” ! IPG: rev 04.Chapter 5: Testing Boundary-Scan Device Chains Example 5-17 After separating files “U3.7" silicon node "U1-8" test "u3.

itf” ! IPG: rev 04. single disable.Chapter 5: Testing Boundary-Scan Device Chains Example 5-18 After separating files “U3. 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 © Agilent Technologies 2002.00u2 Wed Mar 28 16:51:44 2001 ! LB005 ! Single input. "U1-8" to nodes "U3-5" assign Enable to nodes * power VCC. single output. GND family TTL inputs outputs Ins. inverting ! Single condition state combinatorial default device "u3" set terminators to on assign VCC to nodes * assign GND to nodes * assign Ins assign Out to nodes "U1-7". 2003 Boundary-Scan Guide 5-148 .

Chapter 5: Testing Boundary-Scan Device Chains 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 ! © Agilent Technologies 2002. accessible. 2003 accessible. accessible. End of Test Boundary-Scan Guide 5-149 . accessible.

© Agilent Technologies 2002. After the command ipg on “U3”. 2003 Boundary-Scan Guide 5-150 . the final version of the ITL file U3 is shown (see Example 5-19).integrate is run form BT-Basic.Chapter 5: Testing Boundary-Scan Device Chains The entries shown in red are changes to the file to allow the vectors to be generated.

"DIP".7" silicon node "U1-8" test "u3. "custom_lib/bs005". "custom_lib/bs001". 2003 Boundary-Scan Guide 5-151 .8" silicon node "U3-5" test "u3. family "TTL" chain "u1_u2" tdi "U1-TDI" tdo "U2-TDO" tms "U1-TMS" tck "U1-TCK" devices "u1". nodes silicon node "U1-7" test "u3. no end devices end chain !IPG: User may add VCL pass-through statements here if needed.3".Chapter 5: Testing Boundary-Scan Device Chains Example 5-19 ! IPG: rev 04.00u2 Wed Mar 28 16:51:44 2001 silicon nail "u3" !IPG: User may add option statements here if needed. "u1. "u1. no "u2".4".6" inputs "U1-8" inputs "U1-7" outputs "U3-5" set terminators to on © Agilent Technologies 2002.7" !IPG: NO PROBE node "U3-6" test "u3. "u2. "DIP".5".

If additional nodes are added to the ITL and VCL file. except that one or more physical probes are eliminated. 2003 Boundary-Scan Guide NOTE There is no source generation in the integrate phase of the process in IPG. NOTE The test developer must generate any additional information that may be required. There is no additional coverage information generated for these devices. Figure 5-48 illustrates this function. © Agilent Technologies 2002. 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.Chapter 5: Testing Boundary-Scan Device Chains pcf order is nodes "U1-7" pcf order is nodes "U1-8" pcf order is nodes "U3-5" 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. Writing a Silicon Nails Cluster Test Clusters are tested just as they are during standard functional testing. For more information about cluster testing. all vectors have now been generated for this test. 5-152 . refer to Digital Theory & Testing on page 1-1.

(Enter test scan for your Silicon Nails test. Remember that you must include all disabling and node information. When you reach the Generate Tests Using IPG step of this process. you should run IPG Test Consultant in interactive mode. The resources 5-153 . close the BT-BASIC window and return to IPG Test Consultant. No special syntax is required. Syntax and an example Silicon Nails ITL source code are shown later in InterconnectPlus Test Language (ITL) on page 5-158. © Agilent Technologies 2002. After you have edited the testorder file. you can manually add pertinent test information to your testplan by editing the testorder file. open a BT-BASIC window and write the ITL source file for your test. 2003 Boundary-Scan Guide When you have written and compiled the test. Continue with the Generate testplan step. select Do and Stop.Chapter 5: Testing Boundary-Scan Device Chains Figure 5-48 Testing devices within clusters TD1 TDO If you know that you will add Silicon Nails tests to your board test.) The test file must be saved in your board's digital directory. Then.

2003 ■ 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 . This section describes some of these problems in detail. A Silicon Nails test can contain embedded disabling processes that are more robust than non-embedded Boundary-Scan disabling. The pros of using Silicon Nails testing include: © Agilent Technologies 2002. First. and the test will be added to the final testplan. Cons of Using Silicon Nails Early implementation of Silicon Nail tests have identified several potential problems with this test strategy. 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. the two input pins of the same gate are shorted together. while others could result in failures in the field.Chapter 5: Testing Boundary-Scan Device Chains for your Silicon Nails test will be assigned just as they are for other tests. There is still value in using a Silicon Nails test even when all nodes are nailed. 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. for a 7400 component (four NAND gates). Some of these problems can be as minor as having to modify library tests.

the short does not create a conflict. The problem with this case is that it is also likely to pass a system test and be shipped to the customer. When the two inputs are driven to opposite states (01 and 10) the output is expected to be high.Chapter 5: Testing Boundary-Scan Device Chains Figure 5-49 . 2003 Pin 1 Pin 2 Pin 3 0 0 H 0 1 H 1 0 H 1 1 L Boundary-Scan Guide A 2-input NAND gate has four possible combinations.Shorted inputs to a NAND gate could go undetected. To create a failure on the output. the two outputs are fighting each other when they are in 5-155 . However. If that is not the case. the NAND gate will show a correct response. A test would PASS in spite of the defect. you can examine the reason for this. Using Table 5-11. Table 5-11 Truth Table for a 2-input NAND Gate © Agilent Technologies 2002. When both inputs are high (11) or both inputs are low (00). both inputs must go over logic level 1.

enable the outputs and pass 0s and 1s through the buffer. a backdrive problem could occur. This can be a problem if you are testing dynamic components. This is due to the drivers being tri-stated and the pull-ups creating the 1s. real vector application rate to the DUT.000 cells results in less than a 5 kHz real vector application rate. 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. A summary of the issues to consider include: • This vector should show 0s on the output. Because of the long test times. If you do use Silicon Nails strategy. you should ask yourself these questions about your board: In addition. this last vector will probably fail because the pull-up function is missing. Use physical probes on conventional components where possible. This could result in a failure where it is most expensive to repair: in the field. If the outputs are tested with Silicon Nail receivers. a Silicon Nails test may not work correctly when it is dependent upon 3070 resources that do not exist when Silicon resources are substituted. ■ 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). set the data to (for example) all 0s and set the receiver loads to pull the outputs up to 1s. For example. 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 . • The next vector disables the output and expects to see the output go high. An illustration of this would be a test that is dependent on 3070 receiver loads (controlled by set load statements) in order to work. 2003 2 Then.Chapter 5: Testing Boundary-Scan Device Chains opposite states. running TDI with a rate of 5 MHz through a chain of over 1. 1 First. For example. to test the output enable signal of a simple buffer IC: A limitation of Silicon Nails testing is the low. Carefully consider the issues discussed above before you apply the Silicon Nails test strategy. © Agilent Technologies 2002.

Serialization. although it increases test length.Chapter 5: Testing Boundary-Scan Device Chains ■ 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. serialization is not necessary between the first and second nodes. and probe placement Serialization of vectors is a necessary part of Silicon Nails testing. Consider the following example: © Agilent Technologies 2002. but a functional Silicon Nails test will be not generated. IPG will continue to run. 5-157 . because there is no change of state from Vector 1 to Vector 2. 2003 Boundary-Scan Guide Placing probes on busy pins (Silicon Node) 1 (Silicon Node) 0 (Nailed Node) 1 (Silicon Node) 1 (Silicon Node) 0 (Nailed Node) 0 Vector 2: In this example. However. test length. strategic placement of one or more physical probes (when possible) on a “busy” node can sometimes reduce serialization and test length. If you answer yes to any of these questions. Placement of a physical nail (when possible) at this “busy” node could eliminate serialization of the second vector and decrease test length. you should probably not use Silicon Nails testing on the affected nodes.

and examples of how to use the statement. Note that only new ITL statements are presented here in detail.Chapter 5: Testing Boundary-Scan Device Chains InterconnectPlus Test Language (ITL) InterconnectPlus Test Language (ITL) is used in the intermediate files that describe the high-level requirements for the boundary-scan tests for your devices. Both types are listed below. The descriptions for these statements can be found on the following pages. Statements that have been borrowed from VCL are presented in the Syntax Reference documentation. you should note that ITL has a mandatory structure. The statements include: Example 5-20 tdi tdo tms tck © Agilent Technologies 2002. 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. refer to Silicon Nails Test Strategy on page 5-130. The files are created by IPG and are an input to the MSPD serializer. which is described (and shown by example) below. then incorporated manually into your testplan. ITL Statement Descriptions and Syntax This section contains all the statements used by ITL. interconnect. The statements are dealt with in alphabetical order. An optional product automates this ITL generation from library tests. NOTE NOTE In the past. Silicon Nails tests had to be written manually using ITL. however. Each description contains the statement's syntax. For more information. These files contain the information that describes powered shorts. and (optionally) Silicon Nails testing for your boundary-scan devices. descriptions of key parameters. connect. buswire. A list of statements created specifically for ITL is shown below. 2003 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 .

debug (ITL) The debug statement declares the test type to be one to debug the boundary scan chain. This extends interconnect testing to examine each bussed driver to ensure connectivity and operation. and provides the path names for the software to retrieve the BSDL files for each device in the chain. 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. custom (ITL) chain (ITL) The chain statement marks the start of a chain block. The connect statement declares the test type to be a connect test. Normally. 2003 Boundary-Scan Guide The custom statement declares the test type to be a custom test.Chapter 5: Testing Boundary-Scan Device Chains ITL Statements Borrowed from VCL A list of statements borrowed from VCL for use in ITL is shown below. The chain block contains the description of the boundary-scan control signals. © Agilent Technologies 2002. 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. This test uses the MSPD interface to create the test patterns. 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 is just used in test development and not in production. This is a type of interconnect test custom designed by the user. This uses tester nails to test to a single device in the scan chain. These statements behave similarly to VCL. 5-159 . The descriptions for these statements can be found in the Syntax Reference documentation.

Refer to the disables statement for more information. You can enter disable information if you know about disable needs for your test. The end devices statement marks the end of a devices block. and the path names to their BSDL files. disables (ITL) The disables statement (optional) marks the start of an optional disables block. Refer to the chains statement for more information. 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. The information in this block provides the software with the descriptions of the devices in the chain. For more detail on this syntax statement see end chain (ITL) of the Syntax Reference documentation. For more detail on this syntax statement see disables (ITL) of the Syntax Reference documentation © Agilent Technologies 2002. For more detail on this syntax statement see end devices (ITL) of the Syntax Reference documentation.) You do not need to specify disable information for devices that can use boundary-scan disabling.Chapter 5: Testing Boundary-Scan Device Chains devices (ITL) end chain (ITL) The devices statement marks the beginning of a devices block. For more detail on this syntax statement see devices (ITL) of the Syntax Reference documentation. For more detail on this syntax statement see end disables (ITL) of the Syntax Reference documentation. (This information might not be needed to develop your device test. 2003 Boundary-Scan Guide 5-160 . The end chain statement marks the end of a chain block. Refer to the devices statement for more information. end disables (ITL) The end disables statement marks the end of a disables block.

Refer to the nodes statement for more information. or custom. The <test type> can be powered shorts. and ignores nailed access to the interconnect nodes under test. interconnect. For more detail on this syntax statement see end nodes (ITL) of the Syntax Reference documentation. interconnect (ITL) The interconnect statement declares the test type to be an interconnection test of the devices in the chain. fixed (ITL) The fixed statement is used within a nodes block to declare fixed nodes. the statement is commented and the state is specified as unknown. if the state cannot be determined. 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. The fixed statement includes the state of the node (high or low). The statement is optional. 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. This test only uses the TAP nodes. 5-161 .Chapter 5: Testing Boundary-Scan Device Chains end nodes (ITL) The end nodes statement marks the end of a nodes block. node (ITL) The node statement is used within a nodes or disables block to identify the node to be tested or disabled. 2003 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. buswire. 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. and disables. You need to edit the file to change © Agilent Technologies 2002. connect. end <test type> (ITL) The end <test type> statement marks the end of a test block. For more detail on this syntax statement see end <test type> (ITL) of the Syntax Reference documentation.

The test can use a mixture of boundary scan resources (silicon nails) or tester resources (regular nails). For powered shorts tests. This statement can appear within a nodes block or a disables block. powered shorts. With early software. this test’s ITL file had to be manually created. 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. 5-162 . optional software can automatically create this file from a library test. This statement typically appears in interconnect. silicon nail (ITL) The silicon nail statement declares the test type to be a test of one or more non-scan devices. but it must be present in every ITL source file (even if it is empty) to satisfy the syntactic requirements of the parser.Chapter 5: Testing Boundary-Scan Device Chains For more detail on this syntax statement see node (ITL) of the Syntax Reference documentation. © Agilent Technologies 2002. this block identifies the adjacency of the 100-percent boundary-scan node (silicon node) to the nailed nodes of any other type. For more detail on this syntax statement see performance port of the Syntax Reference documentation. nodes (ITL) The nodes statement marks the beginning of a nodes block. This block can be empty. 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. 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. newer. buswire. 2003 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. or custom test blocks. For more detail on this syntax statement see silicon node (ITL) of the Syntax Reference documentation. For more detail on this syntax statement see nodes (ITL) of the Syntax Reference documentation.

A name is assigned to this node using the tms statement. The tdo statement identifies the test data out node of the boundary-scan chain. tdi (ITL) test inputs only (ITL) The tdi statement identifies the test data in node of the boundary-scan chain. It skips the test frames that check outputs. tdo (ITL) The test inputs only statement is for optional usage in connect tests. For more detail on this syntax statement see tms (ITL) of the Syntax Reference documentation. The tms statement identifies the test mode select node of the boundary-scan chain. The test statement identifies the node connections that will be tested. A name is assigned to this node using the tdi statement. 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. For more detail on this syntax statement see test (ITL) of the Syntax Reference documentation.Chapter 5: Testing Boundary-Scan Device Chains 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. 2003 Boundary-Scan Guide 5-163 . This creates unsolvable disable problems to IPG. For more detail on this syntax statement see tck (ITL) of the Syntax Reference documentation. tms (ITL) For more detail on this syntax statement see tdi (ITL) of the Syntax Reference documentation. © Agilent Technologies 2002. A name is assigned to this node using the tdo statement. For more detail on this syntax statement see tdo (ITL) of the Syntax Reference documentation. while the programmed function may be as an input only. The test statement is used within a nodes block in conjunction with the node statement. It is intended for PLDs that have all pins defined as bidirectional in BSDL.

A name is assigned to this node using the trst statement.Chapter 5: Testing Boundary-Scan Device Chains trst (ITL) The trst statement identifies the test reset node of the boundary-scan chain (if one exists). 2003 Boundary-Scan Guide 5-164 . For more detail on this syntax statement see trst (ITL) of the Syntax Reference documentation. © Agilent Technologies 2002.

Examples follow the general syntax structure shown below. 2003 Boundary-Scan Guide 5-165 . © Agilent Technologies 2002. Parameters are shown in brackets < >.Chapter 5: Testing Boundary-Scan Device Chains ITL Syntax Structure This section describes the structure for the InterconnectPlus Test Language (ITL).

2003 Boundary-Scan Guide 5-166 . k." indicates equal card preference hybrid ! ".<package name>. channel! used. <compliance problem> <device description>.<package 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> © Agilent Technologies 2002.<BSDL pathname>." indicates first choice preferred channel. devices <device description>. but second may be hybrid.<BSDL pathname>. . t pcf order is nodes <node name>. <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. <compliance problem> .Chapter 5: Testing Boundary-Scan Device Chains 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! ".. .<BSDL pathname>. 1.<package name>. <compliance problem> <device description>. <node name>.. hybrid! over second..

<device. shown below. <device.<node name> bidirectionals <node name>.pin>..pin> <device..<node name> outputs <node name>.... however. 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. <device.Chapter 5: Testing Boundary-Scan Device Chains 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>..pin>. The first example. 2003 Boundary-Scan Guide 5-167 .<device. © Agilent Technologies 2002. These nodes do not appear to be adjacent when you look at the schematic..<device.....pin> silicon node <node name> test <device. <node name>...pin>... they are physically adjacent in the actual circuit.<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.pin> silicon node <node name> <card list> test <device..pin>....pin> node <node name> <card list> test <device.pin> is a <string expression> inputs <node name>.<device.<node name> pcf order is nodes <node name>.pin>. is an ITL source file for a powered shorts test... <node name>.pin>.. <device. <node name>.. <node name>.

19" silicon node "U1_U3_8" test "u1.8". 2003 Boundary-Scan Guide 5-168 . no "u3"."u2."u4."IN_28" unit "disable" pcf "11" end pcf end unit end disables nodes silicon node "U1_2" test "u1. "custom/74bct8374".20" silicon node "U1_U3_7" test "u1. "custom/74bct8374".16".9"."u3. no end devices end chain disables node "IN_26" hybrid default "1" node "IN_28" hybrid default "1" pcf order is nodes "IN_26".21" silicon node "U1_5" test "u1."u4.19".Chapter 5: Testing Boundary-Scan Device Chains Example 5-22 powered shorts "u1_u4_ps" chain "u1_u4" tdi "TDI" tdo "TDO" tms "TMS" tck "TCK" devices "u1".22" silicon node "U1_4" test "u1."u4. no "u4".23) silicon node "U1_3" test "u1."u2. "custom/74bct8374".9"."u2.7".7"."u3."u2."u2. "DW_PACKAGE"."u4. "DW_PACKAGE".2) node "IN_04" test "u2.1" ! (100 mils from u1."u2."u2. "DW_PACKAGE".2".17" silicon node "U1_U3_9" test "u1. "DW_PACKAGE".23" node "IN_05" test "u1.20".16" © Agilent Technologies 2002.5".17".3". "custom/74bct8374".4".8"."u3.24" ! (100 mils from u2. no "u2".

"u2.15) !Untestable (Inaccessible): U1_TDO."u3.2) node "IN_17" test "u4.14 (near u2."u4. u5.11) silicon node "U3_4" test "u3.14 (near u4.10 (near u5.15".2".Chapter 5: Testing Boundary-Scan Device Chains silicon node "U1_U3_10" test "u1.11) node "IN_27" test "u5. © Agilent Technologies 2002.21" end nodes end powered shorts The following ITL source file is for the u1_u4 interconnect test.1" ! (100 mils from u3."u4. u3.22" !Untestable (Disable): IN_26. 2003 Boundary-Scan Guide 5-169 .10".3".4".15) silicon node "U3_2" test "u3. u4.15" !Untestable (Inaccessible): U3_TDO.24" ! (100 mils from u4.12" ! (100 mils from u5."u4.10".23) silicon node "U3_3" test "u3.11 (near u1.23" node "IN_25" test "u5."u4.8) node "IN_18" test "u3.10) !Untestable (Inaccessible): U1_TDO.11 (near u3.10) !Untestable (Inaccessible): U3_TDO. u2. u1.9" ! (100 mils from u5.

no end devices end chain disables node "IN_26" hybrid node "IN_28" hybrid pcf order is nodes "IN_26". 2003 Boundary-Scan Guide 5-170 ."u4. "."u2."u2.2"."u3."u2.23" silicon node "U1_3" test "u1./demo_original/custom/74bct8374".15" silicon node "U3_2" test "u3.4". "DW_PACKAGE"./demo_original/custom/74bct8374".Chapter 5: Testing Boundary-Scan Device Chains Example 5-23 interconnect"u1_u4" chain "u1_u4" tdi "TDI" tdo "TDO" tms "TMS" tck "TCK" devices "u1".22" silicon node "U1_4" test "u1."u2.9"."u2.19".20" silicon node "U1_U3_7" test "u1.."u3. no "u2".21" silicon node "U1_5" test "u1. ".17". ".8"./demo_original/custom/74bct8374".8".17" silicon node "U1_U3_9" test "u1. ".9". "DW_PACKAGE".16".23" © Agilent Technologies 2002. no "u3".10"."u2.7".10".."u3.."u4."u4.2".7".16" silicon node "U1_U3_10" test "u1. no "u4"."u2."u4.19" silicon node "U1_U3_8" test "u1."u3.20"."u4.15"."u4. "DW_PACKAGE"."u2..5". "DW_PACKAGE"./demo_original/custom/74bct8374"."IN_28" unit "disable" pcf "11" end pcf end unit end disables nodes silicon node "U1_2" test "u1.3".

5-171 . 2003 Boundary-Scan Guide other devices—u1.."u4."u3."u3.19" silicon node "U1_U3_8" test "u1.9"."u4.10"."u4.9"."u3."u3."u2./demo_original/custom/74bct8374".7". "DW_PACKAGE"."u4."u4.8".15". "DW_PACKAGE". ". and u4—are similar.17".3". "DW_PACKAGE"./demo_original/custom/74bct8374".7"./demo_original/custom/74bct8374".22" silicon node "U3_4" test "u3.Chapter 5: Testing Boundary-Scan Device Chains silicon node "U3_3" test "u3. no "u4".10".16" silicon node "U1_U3_10" test "u1."u2. u3. Connect test ITL source files for the © Agilent Technologies 2002..19"."u2. no "u3".15" end nodes end buswire The following ITL source file is for one connect test. no "u2"..17" silicon node "U1_U3_9" test "u1. ". ".4". no end devices end chain nodes silicon node "U1_U3_7" test "u1.8"."u2."u4. u2.. of the u1_u4 chain./demo_original/custom/74bct8374".21" end nodes end interconnect The following ITL source file is for the u1_u4 buswire test. "DW_PACKAGE". Example 5-24 buswire"u1_u4_bus" chain "u1_u4" tdi "TDI" tdo "TDO" tms "TMS" tck "TCK" devices "u1".16". ".

3" node "OUT_06" hybrid test "u2. 2003 Boundary-Scan Guide "DW_PACKAGE". "./demo_original/custom/74bct8374"...4" node "OUT_05" hybrid test "u2./demo_original/custom/74bct8374". "u4"./demo_original/custom/74bct8374". ". "DW_PACKAGE"../demo_original/custom/74bct8374"..2" end nodes !IPG: Inaccessible nodes !IPG: node "U2_5" !IPG: node "U2_7" !IPG: node "U2_8" !IPG: node "U2_9" !IPG: node "U2_10" !IPG: node "U1_U3_10" !IPG: node "U1_U3_9" !IPG: node "U1_U3_8" !IPG: node "U1_U3_7" !IPG: node "U1_5" !IPG: node "U1_4" !IPG: node "U1_3" © Agilent Technologies 2002. ". "u3". no no no no 5-172 . ".Chapter 5: Testing Boundary-Scan Device Chains Example 5-25 connect "u2" chain "u1_u4" tdi "TDI" tdo "TDO" tms "TMS" tck "TCK" devices "u1". "DW_PACKAGE". "DW_PACKAGE".24" node "IN_05" hybrid test "u2. end devices end chain nodes node "IN_04" hybrid test "u2. "u2".1" node "OUT_04" hybrid test "u2.

© Agilent Technologies 2002. 2003 Boundary-Scan Guide 5-173 . The test vector section (Element number 1 through Element number 4 in the example) of Silicon Nails tests are written automatically.Chapter 5: Testing Boundary-Scan Device Chains !IPG: node "U1_2" end connect Silicon Nails Test Example The following ITL source file is for a Silicon Nails test for device u6.

4" silicon node "U2_10" test "U2. "OUT_03" © Agilent Technologies 2002. "U2_7". "DW_PACKAGE". "U6. "U4_10".5" node "OUT_01" test "U6.9"./demo_original/custom/74bct8374". "DW_PACKAGE". "U2_10". no "u4". no end devices end chain nodes node "IN_01" test "U6. "OUT_01" pcf order is nodes "OUT_02".9" silicon node "U2_8" test "U2.1" node "IN_02" test "U6. no "u3". "IN_02"./demo_original/custom/74bct8374". "U6.10". "U2_9" pcf order is nodes "U2_8". "U4_10".Chapter 5: Testing Boundary-Scan Device Chains 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 "u1".. "U6.11" silicon node "U2_7" test "U2. ".2" silicon node "U6_3" test "U1.. "U6.15". "IN_02".6" node "OUT_02" test "U6.. "DW_PACKAGE". "U2_5" outputs "U6_3". "DW_PACKAGE".12" silicon node "U2_5" test "U2. ". 2003 Boundary-Scan Guide 5-174 . "U6.7".8".5". "U6. ".13" inputs "IN_01". "U6_3".10" node "OUT_03" test "U6. "OUT_03" pcf order is nodes "IN_01". "U2_8" inputs "U2_7".10".8" silicon node "U2_9" test "U2. "U2_5". ". no "u2"../demo_original/custom/74bct8374". "OUT_01". "U2_9". "U2_10". "OUT_02". "U6./demo_original/custom/74bct8374".3" silicon node "U4_10" test "U4.

2003 Boundary-Scan Guide 5-175 .Chapter 5: Testing Boundary-Scan Device Chains 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 © Agilent Technologies 2002.

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. These statements include: © Agilent Technologies 2002. Rather. For more detail on this syntax statement see disabled device (VCL) (ITL) of the Syntax Reference documentation.Chapter 5: Testing Boundary-Scan Device Chains VCL/ITL Pass-Thru Statements The following information covers the VCL syntax available to be specified in the Interconnect Test Language (ITL).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. The ITL compiler (MSPD) has been modified to handle these new commands. Syntax Support for Pass-Thru Statements There is a new category in syntax support for pass-through statements. This syntax is not used by the ITL compiler for test generation algorithmic control. These statements can be automatically placed by the IPG test generation process. They may also be entered manually. 5-176 . 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). conditioned device (VCL) (ITL) The program generator places conditioned device (VCL) (ITL) statements in a test’s Declaration section to indicate which devices are conditioned while that test runs. see the Syntax Reference documentation. 2003 ■ 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.

set ref (VCL) (ITL) For more detail on this syntax statement see vector cycle (VCL) (ITL) of the Syntax Reference documentation. you can use it in the Declaration section of a VCL library test to change 5-177 . Advanced Testing With VCL. set load (VCL) (ITL) The set load statement is optional. 2003 For more detail on this syntax statement see receive delay (VCL) (ITL) of the Syntax Reference documentation. 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). receive delay (VCL) (ITL) For more detail on this syntax statement see set ref (VCL) (ITL) of the Syntax Reference documentation. © Agilent Technologies 2002. For more detail on this syntax statement see conditioned device (VCL) (ITL) of the Syntax Reference documentation. the time between starting each vector. that is. The set ref statement is optional. 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.Chapter 5: Testing Boundary-Scan Device Chains you should modify the associated conditioned device function accordingly and recompile the test. starting a vector) and receiving (examining) the response from that device or circuit. Once established. For more detail on this syntax statement see set load (VCL) (ITL) of the Syntax Reference documentation. 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.e.. set slew rate (VCL) (ITL) Boundary-Scan Guide The set slew rate statement is optional. 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. vector cycle (VCL) (ITL) The vector cycle (VCL) (ITL) statement appears in the Declaration section of the test to establish the vector cycle time..

and in the compile listings for the test. 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. warning (VCL) (ITL) The warning function can appear in the pass through part of the ITL test. For more detail on this syntax statement see set slew rate (VCL) (ITL) in the Syntax Reference documentation. In a silicon nail test. The warning (VCL) (ITL) statement allows you to place warning messages in the test. The statement can connect terminators (on in the syntax) or disconnect them (off). For more detail on this syntax statement see warning (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. The messages will then appear in the summary report generated by program generators. This message will be sent in addition to the standard messages generated when a test fails. These clamps can be used to enhance high-speed signal quality.Chapter 5: Testing Boundary-Scan Device Chains the slew rate on selected drivers (inputs and bidirectional pins) to the board under test. Typically messages would include reminders to adapt the test in some way to suit a device in a special configuration. The on failure report function can appear in the pass through part of the ITL test. In a silicon nail test. © Agilent Technologies 2002. For more detail on this syntax statement see set terminators (VCL) (ITL) in the Syntax Reference documentation. 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. 2003 Boundary-Scan Guide 5-178 . it can also appear just after the pcf order is statement or anywhere within the pcf vector block.

and scan silicon nail statements appear in the Declaration section of a VCL test and specify a boundary-scan test type. For more detailed information about these statements. and TDO. scan interconnect. They are followed by brief descriptions and examples. The frame statement identifies the beginning of a block of pcf vectors used in testing boundary-scan devices. The message statement allows you to include custom messages that will be output if the related vectors fail. TMS. they are shifted out and stored in deep-capture RAM until all frames have been executed. The inputs collapsed statement appears in the Declaration of a VCL test. refer to the Syntax Reference documentations. ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ © Agilent Technologies 2002. The inputs scan clock. The binary values of each vector are shifted into the boundary-scan device via the Test Data In (TDI) port. scan bus interconnect. These resources are commonly called TCK. inputs scan mode. TRST. we will discuss only the differences between the source code for a single device and that for a chain of devices. It describes a group of nodes. The bits are then reassembled into signatures and compared to 5-179 . When the frame bits have been captured by chain receivers. 2003 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. and outputs scan statements appear in the Declaration section of a VCL test.Chapter 5: Testing Boundary-Scan Device Chains VCL Source Code For Chain Tests Because an actual VCL source code for even a small boundary-scan chain would be quite long. The statements associated with chain testing are listed below. inputs scan. assigned to a single column. They identify particular boundary-scan resources needed to test boundary-scan devices. that will be tested during a series of iterations for shorts testing. Sample sections are provided to show what the code can look like. inputs scan reset. Messages continue and are associated with all subsequent vectors until a new (or show a null) message statement is encountered. TDI. scan connect.

pin identification. 2003 Boundary-Scan Guide 5-180 . the VCL source file shows where each of these statements and the commented form of the test dictionary would appear in an actual file. node and device. Appended to the end of the source code is a commented form of the test dictionary that provides the frame and device cell correlation. Every frame statement must have an accompanying end frame statement. and the expected signature for the node identified. Items that appear in the following partial example (Example 5-27). Every frame in a test must also be the same length.Chapter 5: Testing Boundary-Scan Device Chains determine if a node passes or fails a test. © Agilent Technologies 2002.

! Chain Composition (TDI to TDO) ! Device Entity Package BSDL File ! --------. BSDL (Version 0. scan interconnect. N002. this could be scan powered shorts..Chapter 5: Testing Boundary-Scan Device Chains Example 5-27 VCL source file !!!! 6 0 1 698520684 Ve2f1 ! Hewlett-Packard Advanced Boundary-Scan Software [920116] ! IEEE Std 1149.. 2003 Boundary-Scan Guide 5-181 . Defaulted family inputs scan clock TCK inputs scan mode TMS inputs scan TDI outputs scan TDO inputs N000. N003 use cards hybrid on N000.----------. scan bus interconnect. TDI. N001 outputs N002. N003 pcf order default Scan is TCK. TMS.1-1990. TDO © Agilent Technologies 2002.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. N001.----------------! U4 TTL74BCT8374 DW_PACKAGE /users/bscan/demo_original/custom/74bct8374 scan connect ! Test device U4 .----------. 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.

Chapter 5: Testing Boundary-Scan Device Chains pcf order Parallel is TCK. N003 !Column-to-Node Map. N001." . . "00ZX" "10ZX"!Shift-IR end pcf message "IEEE Std 1149. compress frame 0 1 pcf use pcf order Parallel "00ZXZZXX"!0+0 use pcf order Scan "10ZX" "00ZX"!1 "10ZX" "00ZX"!2 . TDO . N002. . . N000. TDI. "101X" "01ZL"!17 "11ZX"!Exit1-DR © Agilent Technologies 2002. 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" . . TMS. .1-1990 Integrity Failure" message " Device U4 has failed. 2003 Boundary-Scan Guide 5-182 . .

6.0 microseconds ! Total Vectors : 330. 2003 Boundary-Scan Guide 5-183 . .0 microseconds ! Connect Test Dictionary ! Frame Size 18 ! FrCell DevCell Dev.Pin Node Signature ! 16 16 U4. 66.1 IN_18 'LHXX' © Agilent Technologies 2002. ! End of Connect Test for device U4 use pcf order Scan "01ZX" "11ZX"!Select-IR-Scan use pcf order Parallel "01ZXZZXX" use pcf order Scan "11ZX"!Test-Logic-Reset end pcf end unit ! Connect Test Vector 330 ! Vectors with TDI High: 32.Chapter 5: Testing Boundary-Scan Device Chains end pcf end frame end compress message " " ! example of a null message . .4 microseconds ! Vectors with TDI Low: 40.24 IN_17 'LHXX' ! 17 17 U4. 8.

demo_circuit. do not work within the demo_original directory. NOTE If you wish to run the test generated from this sample session. Remove (iconify) the BT-BASIC window from the workspace. For this session. 2 Before you begin this session. 5-184 . 2003 Boundary-Scan Guide get "init_demo" This program removes all files from the demo_circuit directory. you will use files for the example circuit found at the end of this chapter. Keep the BT-BASIC window in your workspace for later use. Open a BT-BASIC window from the Programs menu of the IPG Test Consultant interface. To execute this program. then places the appropriate board and configuration files needed to complete the steps of the sample session. For this product to function. Use the BT-BASIC window to verify that this statement is in your board config file. type the following on the command line: run NOTE To protect the integrity of the files needed to run sample programming sessions. the config file is in the demo_original directory.Chapter 5: Testing Boundary-Scan Device Chains 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. ensure that the example directory is properly prepared. 3 Remember that InterconnectPlus is an option for the 3070 Series II of board test systems. The only tool that you need to run this session is an 3070 Series II workstation. During this session. 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. Change to the example directory by typing the following on the command line: msi "/3070/standard/tutorial/bscan" To prepare the example directory. you will need a playpen fixture and the boundary-scan demo board. you must add the statement enable advanced boundary scan to your board config file. type the following on the command line: © Agilent Technologies 2002.

Click Close to remove this form. If not. 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. Refer to Understanding the Contents of the BSDL File on page 5-63 for details. Next.Chapter 5: Testing Boundary-Scan Device Chains 4 Acquire (or write) complete and accurate BSDL files for each boundary-scan device type in your chain. The Library Paths Form appears. The information describing u1 will be placed in each field. Refer to Describing Your Boundary-Scan Device on page 5-55 for details. For this session. then enter u1. The pathname . Click View/Edit Board Description in the flowchart. then click Update. Enter the following pathname in the Board Directory field: © Agilent Technologies 2002. A list will appear at the bottom of the flowchart. 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. you can examine the entries for the devices on this board. Select Actions > Close to leave this form. 2003 Boundary-Scan Guide /3070/standard/tutorial/bscan/demo_circuit Click Load Board. Remember that complete and accurate files are essential to successful implementation of a boundary-scan test./demo_original/custom should appear in the form. click the Find button. The software informs you that it is loading the board file. Click Enter Pin Library. Click View/Edit Library Data in the flowchart. You would use this form to describe new devices or to change descriptions of existing devices when you create an original board. 5-185 . When the Board Consultant interface appears. but do not change any of the entries. Place the cursor in the Designator field and click once. The Device Entry Form appears. Click Enter Library Paths.. The Board Specification Form appears. Start Board Consultant from the Programs menu of the IPG Test Consultant interface. A new list appears at the bottom of the flowchart. click Load Existing Board. add this pathname.

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. From here. Copies of the ITL files are found in InterconnectPlus Test Language (ITL) on page 5-158. You can also use a BT-BASIC window to examine the complete VCL source for this test session. been developed. For more information about developing custom tests. Click Compile board File. you can examine the board directory (/3070/standard/tutorial/bscan/demo_circuit) to see that all files needed for your test and fixture have © Agilent Technologies 2002. 6 Follow the standard test generation procedures for developing a board test using IPG Test Consultant.x file). Then select Actions > Begin Batch Development. along with other digital test files. refer to Custom Boundary-Scan Tests on page 5-51. change to the working directory: /3070/standard/tutorial/bscan/demo_circuit Select Actions > Develop Board Test. 2003 Boundary-Scan Guide 5-186 . and chapter 6. Select File > Exit to leave Board Consultant.” Chapter 6 also includes a sample session for developing INTEST for the example circuit. You also have the option of developing custom tests for your boundary-scan devices. A new list will appear at the bottom of the flowchart. you would continue as you would with any other board test. These could include such tests as BIST and INTEST. Then click Save Board Files in the list at the bottom of the flowchart. This process will take several minutes to complete. For more information about Silicon Nails tests. In the IPG Test Consultant interface. or Silicon Nails tests. This includes a commented version of the test dictionary (. Click Final Compile/Verify in the flowchart. You can watch the IPG Test Consultant message window as the software executes the test generation programs. “Multichip Scan Port Driver and the MSPD Interface. Repeat these steps for the board_xy file. Click OK when the Confirm Message window appears.Chapter 5: Testing Boundary-Scan Device Chains NOTE You can also select the Maximize option if you wish to view the entire form. refer to Silicon Nails Test Strategy on page 5-130. A digital directory was created and ITL files created by IPG were placed in this directory. When IPG has completed the test generation process.

NOTE You also have the option of building this demo board by following the schematic.Chapter 5: Testing Boundary-Scan Device Chains 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. 2003 Boundary-Scan Guide 5-187 . “Multichip Scan Port Driver and the MSPD Interface. you can use the schematic to prepare an actual demonstration of the boundary-scan software features. The sample circuit is also referred to by sections in chapter 6.” If you have access to a playpen fixture and a boundary-scan demo board. This should be a viable option because of the simplicity of the board’s design © Agilent Technologies 2002.