Bscan_05

© Agilent Technologies 2002, 2003 Boundary-Scan Guide 5-1 06/2003

5 Testing Boundary-Scan Device Chains

In this chapter... ■ 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

© Agilent Technologies 2002, 2003 Boundary-Scan Guide 5-2

Chapter 5: Testing Boundary-Scan Device Chains

Overview The next step toward full utilization of boundary-scan technology involves testing circuit boards that employ chains of boundary-scan devices. The ability to test boundary-scan devices connected to one another can significantly shorten test development time, and could result in a reduced need for nodal access.

This chapter explains how 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.

NOTEThis 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.



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

TDITDOTDI

TDOTDITDOTDI

TMSTCK

TDO

u1

TAP

u4u3

u2

TAP

TAP TAP

u6

u5

u7



Bit patterns can be shifted in through the initial TDI connection (u1 in this case), shifted through every device in the chain, and shifted out the final TDO connection (u4 in this case) for analysis. Theoretically, all testing of interconnected nodes for the boundary-scan devices in the chain can be accomplished using only four test probes: one on the initial TDI node, one on the final TDO node, and one on each of the controls lines TCK and TMS. Testing non-boundary-scan devices connected between boundary-scan devices can also be accomplished using these four probes.

This chapter explores the practical application of testing boundary-scan chains, and describes the process for developing an optimum test strategy for your board. Understand that practical application of boundary-scan technology neither requires nor implies that all possible probes be eliminated. Employing boundary-scan technology provides you with the option to remove probes in many cases, however, we still recommend that testhead access be provided whenever possible to ensure maximum fault coverage. For guidance on evaluating when to remove probes, refer to Removing Physical Probes on page 5-104.

While fault diagnosis using only the access to the boundary-scan chain is possible, there are several disadvantages to this type of testing. Among the disadvantages are:

■ All tests must be executed and diagnosed with power applied, which leaves devices vulnerable to damage if shorts exist on the board.

■ The diagnosis of some faults might be ambiguous.

■ Under certain circumstances, it might not be possible to isolate a failure to a specific device pin.

devices in the chain have common TCK and TMS lines (TRST is optional for each device in the chain).



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

Every device in the chain is always in the same TAP state: chips operate in parallel in boundary-scan mode. For example, if u1 is in SHIFT-IR, so are u2 and u3. One shift cycle causes all devices to shift one bit.

The registers for each device in the chain do not have to be the same length (IR or DR). The BSDL files tell the system the length of the registers in each device. These are added together to form, essentially, two long IR and DR registers. The instructions (bits) for the registers are also added together to control each register. For

example, Table 5-1 shows what the register lengths for the devices in Figure 5-2 could be.

TDI TDO

TRST

TMS

TCK

u1 u2 u3

Table 5-1 Example register lengths

Device Instruction Register Length

Boundary Register Length

u1 6 bits 24 cells

u2 6 bits 24 cells

u3 10 bits 30 cells



Table 5-2 shows what the concatenated EXTEST instructions for this chain might be.

Although the TAP states must be the same, the instructions need not be. For example, using the instructions listed in Table 5-2, you see in Figure 5-3 that if you shift in the pattern 0000011111111111111111, upon transition through UPDATE-IR, u1 will be in EXTEST, while u2, and u3 are in BYPASS.

Note that, in this case, the length of the Data Register becomes 26 cells (u1 Boundary Register: 24 cells + u2/u3 Bypass Registers: 1 cell each). Shifting in a new set of instructions can change the active registers and therefore the length of the chain's Data Register.

Register length for entire chain

22 bits 78 cells

Table 5-1 Example register lengths (continued)

Device Instruction Register Length

Boundary Register Length

Table 5-2 Example EXTEST instructions

Device Extest Instruction Bypass Instruction

u1 000000 111111

u2 000000 111111

u3 0000000000 1111111111

Concatenated Instructions 0000000000000000000000 1111111111111111111111



Figure 5-3 Devices loaded with different instructions

From this you can see that the length of the Instruction Register for the chain is fixed: the sum of the length of all the Instruction Registers in the chain. However, the length of the chain's active Data Register is dependent upon the current instructions for each device in the chain: the sum of the length of the active Data Registers in the chain. This, in turn, affects the length of the data bits that must be shifted for a given set of tests.

InterconnectPlus software keeps track of these changes as you develop your chain test. The information in the

BSDL file tells the software the length of the registers targeted for each instruction.

Keeping TAP-only Devices in the ChainA TAP-only device is a boundary-scan device that, in some way, does not fully comply with IEEE Standard 1449.1, or a device that, for some reason, does not operate properly with the rest of the boundary-scan chain; however, the device's TAP and its BYPASS function operate properly. InterconnectPlus software

BYPASSBYPASSEXTEST

TDOTDI

TRST

TMS

TCK

u1u2 u3



allows you to label such a device as TAP-only so that its Bypass Register can be used as part of the chain.

The primary benefit of keeping a TAP-only device in the boundary-scan chain is that it allows you to test a longer chain of devices, rather than two or more smaller chains. For example, if device u3 in Figure 5-4 were a TAP-only device, you could keep this device in the chain to permit testing of the other five devices in the chain.

The alternative is to break these apart into two chains by specifying the device as non-compliant. In this case, you could do only the interconnect tests associated with the smaller, individual chains. You could not test the circuitry that connects one smaller chain to the other without using physical probes. This results in a real loss in testing.

For more information about specifying a device as TAP-only or non-compliant, refer to Describing Your Boundary-Scan Device on page 5-55.



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

TAP Override FormSometimes a TAP signal (TDI, TDO, TCK, TMS, or TRST) will contain a device that causes the signal to be split into multiple node names. The device may be a buffer, a logic level converter, or a resistor with a value above the IPG Digital Resistance Threshold. The InterconnectPlus software treats boundary-scan devices on opposite sides of such a split signal as separate

chains. For example, Figure 5-5 shows a circuit where the TMS and TCK lines have buffers. InterconnectPlus software sees two distinct chains: a chain consisting of U1 and U2, and a chain consisting of U3, U4, and U5.

TDOTD1

u1

u2

u3 u4

u5

u6

TAPOnly



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

As of software version B.03.00, there is a TAP Override Form (Figure 5-5) that allows you to specify that certain nodes which are logically equivalent to physical TAP signal connections should be used in place of the physical TAP signal nodes. You can use this ability to override nodes so that InterconnectPlus software will see devices with logically equivalent TAP signal nodes as a single chain. You would enter data in the TAP Override Form as Figure 5-5 show for devices U3, U4, and U5 to accommodate the chain Figure 5-4 shows.

Figure 5-6 TAP Override Form

You invoke the TAP Override Form from a button on the Device Entry Form (Figure 5-6).



The TAP Override Form allows you to override any TAP signal node for any device being tested with InterconnectPlus. However, you generally should not change the TDI node for any device but the first one in a chain, and you generally should not change TDO for any device but the last one in a chain. You may override TDI or TDO in the middle of a chain only if the chain would otherwise be seen as separate chains. For example, a TDI or TDO override is allowed between U2 and U3 of Figure 5-7, but not allowed between U1 and U2 or U3 and U4.

Figure 5-7 TAP signal overrides button: device entry form



Figure 5-8 TDI or TDO override allowed between U2 and U3

The TAP Override Form cannot be used to work around pad bits in boundary-scan linkers, and you should refer to section Using Chain Override on page 5-12 for details on handling such situations.

Using Chain OverrideMultiple TMS and TCK connections, as Figure 5-9 shows, makes the software treat the board as if it had two chains. If you intend for a configuration to look like a single chain, you must make it look like one chain for the software. If you have multiple connections, you can connect the TCK and TMS lines together inside the fixture, as shown in section 5.1.1.3, providing a physical connection. Software revision B.02.00, or later, allows you to override the board compiler�s view of the chain construction.



Figure 5-9 Multiple TMS/TCK lines cause multiple chains

When you run IPG Test Consultant, you might discover that there are more tests generated than you have chains existing on the board. This fact would show up in the IPG summary or in digital directories. With software revision B.02.00, or later, you can examine a testability report from Board Consultant after data entry to see the chain structures found by the board compiler.

If you discover more chains than there actually are, you can edit the chain description portion of the board file by turning Boundary-Scan Chain Override ON. This is accomplished by turning on a flag in the board global options section. (See Testing Boundary-Scan Device

Chains on page 5-1.). This flag can only be turned on for revision B (Series II) systems.

Figure 5-10 is an example showing how the software could assume there were two chains. TCK output from buffer A goes to two devices (U1 and U2) in the chain. Since these outputs are on two different nodes on device TCK/TMS pins, the software assumes two chains, which is the case, unless you refer back to the inputs of buffers A and B. By overriding, you tell the software that there is only one chain.

TDI TDO

TCK1TMS1

TRSTTCK2TMS2

u1 u2 u3

TCK

TMS



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

Consider an example where the testability report shows two chains on a board as Figure 5-10 shows:

BOUNDARY SCAN CHAINSU1_U1

TDI TDITDO TDO_TDITCK TCK1TMS TMS1DEVICES

u1;u2_u2

TDI TDO_TDI

TDO TDOTCK TCK2TMS TMS2DEVICES

u2;

In reality, signals TCK1 and TCK2 as well as TMS1 and TMS2 are logically identical buffered signals coming from TCK and TMS. The compiler cannot know this so it splits the logical chain into two chains. To put the two chains together with an override, you first edit the global section of the board file to add the statement

U1 U2

TDO_TDITDI TDO

TCK

TMS

A

B

TCK1

TCK2

TMS1TMS2



Boundary Scan Chain Override ON

to the global flag section. After saving and compiling, you can use list object on board.o to generate a board file containing the chain(s) that the compiler found itself. You must then go to the board file and edit in the chain

descriptions (at the end of the file) that describe the actual chain construction. The edited chain looks like Example 5-1, with comments added to describe the syntax.

Example 5-1 Edited chain

BOUNDARY SCAN CHAINS ! Board keyphrase

u1_u2 ! <name ofchain> followed by TAP signals

TDI TDI ! TDI <nodename>

TDO TDO ! TDO <nodename>

TCK TCK ! TCK <node

name>TMS TMS ! TMS <node

name>DEVICES ! now name

devices in the chainu1, u2; ! first device

nearest TDI! last device

nearest TDO, ";" terminated

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

NOTEFor more information about using GP relays, refer to the Cards in the Testhead documentation, and Development�3.



Figure 5-11 Connecting jumpers or GP relays to make alarger chain

You should not jumper non-compliant devices as shown in Figure 5-12 solely for the purpose of making a larger chain. This can result in overdriving difficulties, or other testing problems.

Chain 2Chain 1

TDITDI

TDOTDO

u1 u2

u3 u4

u1 u2

u4u3



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

The dotted line shown above represents a jumper used to circumvent the non-compliant (NC) device, u13. This might seem like a reasonable solution, however, a closer study reveals that using a jumper does not disconnect the device's TAP from the circuit and the connected TDOs would fight. The activity of this device during test will be unpredictable.

In this case, it would be better to leave the chains separate, even if some interconnect test capability is lost. You can regain the loss by assigning physical probes to those nodes.

The best solution would be to do an ECO, or modify the design prior to release.

TDI TDO

u10 u21u20u13N.C.u11



InterconnectPlus Chain TestingInterconnectPlus software's chain testing comprises powered shorts, TAP integrity, interconnect, buswire, connect tests, and the ability to do Silicon Nails1 testing. Through the use of the IEEE 1149.1-1990 required instruction set, many manufacturing faults can be detected and diagnosed. This is accomplished by employing the EXTEST function for the detection of faults in the interconnections of both bussed and non-bussed devices, whether or not testhead access is provided.

Table 5-3 provides you with an understanding of where these tests fit in your overall process. The table also identifies which tests are automatically created by the boundary-scan software and which require test developer interaction.

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

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

Sequence Type Method

Board Test Sequence -- Unpowered

Shorts Tests Conventional Automatic

Analog In-circuit Tests Conventional Automatic

Power Applied to Board

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 Removed from Board, then Re-applied

BIST, INTEST, User Functions

Boundary-Scan Interactive

Table 5-3 Board test sequence showing position of boundary-scan tests (continued)

Sequence Type Method



Digital in-circuit tests are described in detail in the Test Methods: Digital documentation. BIST and INTEST are described in chapter 1 of this documentation. Silicon Nail test theory is discussed later in this chapter.

The primary purpose of this section is to examine the following tests:

■ Powered Shorts 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.

Powered shorts test fixes the direction that bidirectional cells are tested: those cells selected as drivers by the software are tested only as drivers; those not selected are tested only as receivers.

One powered shorts test is generated for each boundary-scan chain on the board.

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

■ TAP Integrity Test�Verifies that the Test Access Port (TAP) of all the boundary-scan devices in the

chain operate properly. If this test fails, testing stops, and power is removed from the board. This test is a preamble to all other boundary-scan tests: it is an integral part of each test and is executed before each test runs.

■ Interconnect Test�Tests the connections from one boundary-scan device to the other boundary-scan devices in the chain. This test checks primarily for shorts, but most opens will also be detected. If this test fails, testing stops, and power is removed from the board. Interconnect test attempts to use only one driver in the case of bussed nodes. This helps keep tests shorter, helps diagnostics, prevents bus fights, and minimizes the potential for device damage.

Interconnect test fixes the direction that bidirectional cells are tested: those cells selected by the software as drivers are tested only as drivers; those not selected are tested only as receivers.

Interconnect tests require the use of only four testhead resources; three drivers (TMS, TCK, TDI) and one receiver (TDO).

NOTEIf device disabling or conditioning is necessary for other devices on the board, additional drivers might be required.



One interconnect test is generated for each boundary-scan chain on the board. This test verifies the connections between devices in the same chain only.

■ Buswire Test�Created when bussed drivers are present in the chain.

Under certain circumstances, interconnect test must be executed with multiple device outputs driving test patterns onto the same (bussed) node. If one of the drivers was disconnected from the node, it would go undetected. Interconnect test could also be executed with two or more drivers connected to one node, but with only one driver enabled. For these reasons, buswire test turns drivers on one at a time to check for opens, and tests the operation of all drivers. One buswire test is generated for each chain on the board.

Buswire test verifies the operation of bidirectional pins by generating separate vectors to check their operation as drivers, then as receivers.

■ Connect Test�Tests for opens on each device, one at a time (u1, . . . uy), until the entire chain has been tested. This test checks for opens on only the inputs and outputs of devices that have physical probes assigned. One connect test is generated for each boundary-scan device in the chain that has one or more I/O pins accessible from the testhead.

For larger devices that exceed the available number of testhead resources�for example, testing a 300-pin ASIC when only 200 resources are available�you can (manually) split the connect test into two or more smaller tests.

Connect test verifies the operation of bidirectional pins by generating separate vectors to check their operation as drivers, then as receivers.

InterconnectPlus Test FilesEach of these tests has five files of which you should be aware.

■ InterconnectPlus Test Language (ITL) source file�A permanent, intermediate file input to the MSPD serializer that contains, essentially the boundary-scan test source code generated by IPG using the InterconnectPlus software.

■ Vector Control Language (VCL) source file�A permanent, intermediate file created by the MSPD Serializer that contains the device test; it is an input to the VCL compiler.

■ Test dictionary (.x) file�A permanent file generated by the MSPD Serializer that contains the node identifier and the expected signature for that node. A commented version of this file is documented at the end of the VCL source file.



■ Test requirements (.r) file�A temporary file generated by the VCL compiler to identify testhead resources needed for the test.

■ Test object (.o) file�The compiled VCL file (non-editable).

All of these files are located in the board's digital directory. Each of these files is discussed in more detail throughout this chapter.

Importance of Providing Complete board_xy FilesIt is strongly recommended that you acquire complete topology information (X-Y location information) for your board so that the board_xy file used to generate your test is complete. Topology provides the system with valuable adjacency information used to build powered shorts tests, and all pin data (preferably all solderable points) as well as node data should be provided.

If complete board_xy files are not provided, the software will make calculated assumptions about nodal adjacency, which could result in inadequate or incomplete test coverage. When this information is provided, you can rely on the software to provide complete coverage, and you can focus on qualifying candidates for probe removal.

Figure 5-13 is a physical representation of one section of a densely packed circuit board. This board has a number of integrated circuits with gullwing leads that

are mounted closely together. Also mounted closely to these devices are several SMT analog devices. Complete X-Y data would tell the system software about the physical relationship of all these components, and would allow InterconnectPlus to add the necessary powered shorts test to cover all contigencies.



Figure 5-13 Circuit Board with Tight-Pack Design

Powered Shorts TestFigure 5-14 illustrates connections between two devices for which a powered shorts test would be generated. Remember that this test is created automatically, and in most cases will work without debug.

The information in this section is provided for background.

Shorts that can occur between physically adjacent devicesare automatically accounted for if complete XY datais provided.



Figure 5-14 Powered shorts Ttest checks for shorts between unnailed boundary-scan nodes and any other nailed node

Note that the pin numbers were added to this drawing to illustrate the importance of providing a complete board_xy file. The test software takes the data provided in your board_xy file to determine the relative adjacencies for each device. The adjacencies identify where shorts can occur with respect to boundary-scan nodes.

Devices u3 and u4 are boundary-scan devices with two nodes, u3_3 and u3_2, connected to a non-scan device, u5. Two input nodes, IN_17 and IN_18, are also connected to u3 and u4. These pins (u3 pin 1 and u4 pin 24) are physically adjacent to u3 pin 2 and u4 pin 23. The test software identifies these nodes as potential shorts for this circuit. Because the basic parameters for

u5

910

12

13

8

11

IN_17IN_18

u3 u4

*Potential Short

*Potential Short

*Potential Short*Potential Short

124

3

2

U3_3

U3_2

*Nodes are physically adjacent on actual board.

124

2223

VCCVCC



powered shorts test are an un-nailed boundary-scan node and a nailed node of any other type, InterconnectPlus software would create a powered shorts test for this circuit.

Note that two adjacent pins on device u5, pins 10 and 11, would not be added to the powered shorts test because pin 10 is a disable node that must be held to a constant state during boundary-scan testing. Shorts on this node would be found either during unpowered shorts testing, or during the first phase of interconnect testing.

After you enter your board data, IPG analyzes it and looks for un-nailed boundary-scan nodes. It then examines the X-Y data for powered shorts situations to adjacent nodes. IPG then writes the ITL for the powered shorts test.

When this test is executed, several subtests are run. Each subtest is a cycle through a selected set of nailed nodes connected to multiplexed hybrid drivers. Multiplexing is used to reduce the number of resources needed for the complete test. A detailed diagnostics routine is executed upon failure and results are reported to the print device.

TAP Integrity TestFigure 5-15 illustrates the boundary-scan TAP integrity test. Remember that this test is created automatically, and in most cases will work without debug. The

information in this section is provided for background. This test verifies that the chain is operable, and that the scan path is intact. This is done by verifying the two least significant bits of the Instruction Register, which are captured during the IR-CAPTURE state.

Whenever possible, this test also verifies that the correct devices have been loaded onto the board by checking their IDCODES, if provided. If IDCODES are not provided, the data captured by the Instruction Register during the CAPTURE-IR state is verified, which provides some capability for device identification.



Figure 5-15 Boundary-scan TAP Integrity Test checks the TAP of each device

Integrity test looks for the basic integrity of the devices' TAP controllers and the boundary-scan chain. Examples of problems that could be encountered include:

■ one of the devices is bad: simply does not work

■ a wrong device was loaded

■ one of the TDI or TDO connections is bad (for example, an open between u3 and u4)

TDI

TDO

u1 u2

u3 u4



■ TCK is disconnected from one or more devices

Integrity tests are an integral part of every chain test. Integrity test occurs before each powered shorts test, before each interconnect test, before each buswire test, and before each connect test.

When testing begins, the devices load a pre-determined pattern (BYPASS or IDCODE as specified in the BSDL file) into the Instruction Registers. The devices then all go through SHIFT-IR and new instruction bits are shifted in through TDI. These bits are typically for the IDCODE instruction, if a device includes this feature, or BYPASS.

When the devices go through CAPTURE-IR, the preloaded pattern is captured. When these bits are shifted in, the preloaded bits are shifted out. The software can examine this pattern for each device to see if the chain is working. This first pass through the IR column of the TAP State Diagram verifies the operation of the Instruction Register and the TDI-to-TDO links. An operational chain, in this case, implies operational TAPs for each device.

The devices then change over to their new instructions, and new data bits are shifted in through TDI. When the devices pass through CAPTURE-DR, the new bits are captured, then shifted out for examination. These bits verify the IDCODES of the devices that feature them, or they tell the software that the device successfully executed the BYPASS function. An operational chain,

in this case, implies proper devices loaded, and devices that are basically functional.

Any failure during TAP Integrity test causes the board to power down and a general failure message is generated. The message provides a diagnosis to the general area (for example, to a device), but it does not say exactly where the failure occurred. A failure could occur in a device upstream from the device that the message cites as the starting point for looking for the cause of the failure. Also, the diagnosis is limited in its ability to pinpoint the cause of the failure.

The type of failures detected during this test would prevent the chain itself from working properly: if the chain is bad, you cannot do meaningful testing. So the chain must be repaired before further testing can be done.

Interconnect TestRemember that this test is created automatically, and in most cases will work without debug. The information in this section is provided for background. Interconnect test allows you to test the circuitry that connects one boundary-scan device to another. Interconnect test primarily looks for shorts, then most opens. (A buswire test might be necessary to detect opens missed by interconnect test.) Only the connections between devices in the same boundary-scan chain can be verified.



Testhead access is required only for the TDI, TDO, TMS, and TCK nodes. All other nodes located between the boundary-scan devices in the chain can be silicon nodes. Figure 5-16 illustrates interconnect test.

Because damaging devices during powered testing is an important issue, InterconnectPlus software takes the following approach to interconnect test.

■ Looks for shorts and most opens.

■ Concentrates on finding shorts as fast as possible.

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



Figure 5-16 Interconnect Test checks connections between two or more boundary-scan devices connected in a chain

Frames and SignaturesBefore you explore interconnect test, you need to understand the concepts of frames and signatures. For the circuit in Figure 5-16, the example data pattern is set up as shown in Table 5-4.

Nodes Tested in Interconnect

TDI

TDO

u1 u2

u3 u4

Table 5-4

A 0 1 0 0 1

B 0 1 0 1 0

C 0 1 0 1 1 Rows form signatures

D 0 1 1 0 1



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

The rows of bits from the corresponding positions in each frame form signatures, also called identification (ID) patterns, for these nodes. Signatures (IDs) must be different for each node so software can distinguish one node from another.

The frame statement found in the VCL source code tells the system's deep-capture RAM to capture bits shifting out of TDO. The frame size tells you how many bits are shifted into the deep-capture RAM each time a frame is executed. The following example frame would be needed to shift the fourth frame (0110) of the signatures for Figure 5-17. For more information about the frame and end frame statements, refer to the Syntax Reference documentation.

frame 0 1000X100X001X101X001X101X000X100X01XX

end frame



Figure 5-17 Interconnect Test uses frames and signatures

To create an interconnect test of five bits per signature, as Figure 5-17 shows, we can use the five frames shown

on the preceding page.

Frame 1 2 3 4 5

TDI

TDO

A

BC

0

0

0

0

00

0

0

11

1 1111

1 1 100

A

B

D

u1 u2

u3 u4



The frame positions that correspond to the drivers, at UPDATE-DR, for each node contain the bits that make up the signatures (IDs) for those nodes. When the devices pass through CAPTURE-DR, the receivers connected to the corresponding node should capture the bits of that node's ID.

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



When bus drivers share control cells, a single driver cannot be designated

Several circumstances can prevent the software from designating only one driver. Figure illustrates one situation where bussed drivers share the same control

cell. For this example, let's say that the software looks for and finds a driver for u1.13. It finds the only one available and designates it as the driver for that node.

Control Cel l

Control Cell

TDO

TDI

u1 u2

u3 u4

11

1213

8

910



Notice that this pin's control cell is also connected to the drivers for u1.11 and u1.12.

By itself, this is not a problem. However, when the software moves on and designates a driver for u3.10, the control cell for that pin also enables the drivers for u3.8 and u3.9, which are connected to u1.11 and u1.12 respectively. The situation that now arises is that the two buswires have multiple drivers.

This situation must occur because interconnect test needs to drive these nodes during its test. To eliminate bus fights, the software ensures that the data on these drivers is the same. Fault masking, which can result from this situation, is rectified during buswire test.

Executing Interconnect TestInterconnect test first shifts the instruction bits into each device in the chain to set up the SAMPLE/PRELOAD function. ( These are labeled as SAMPLE in the VCL source file because SAMPLE is a reserved word in BSDL.) The data pattern for the first frame is then loaded in the drive cells connected to nodes A-D shown in shows an example of all 0s shifted in.

The devices then go through UPDATE-IR to change to the EXTEST function, where they will remain during testing.

NOTEThe exception to this is a TAP-only device, which is always in BYPASS during testing.

When the devices pass through UPDATE-IR, the driver cells drive the SAMPLE/PRELOAD data bits to the receive cells. As the devices pass through CAPTURE-DR, the receive cells capture the data, and subsequently shift it out. When these bits are being shifted out, new bits are shifted in. Subsequent passes through UPDATE-DR drive new bits to the receive cells, which are then shifted out for examination. Data shifted out should correspond to the signatures for each node.

Safe bits (described in the BSDL file) are shifted in for the last frame to flush the Boundary Register and shift the final signature bits out.

The safe bits specified in the BSDL file provide the value that the device's designer prefers to have loaded into the associated cell's UPDATE flip-flop when software might otherwise randomly choose a value. For more information and examples of safe bits, refer to chapter 2 in this documentation.



NOTEThe 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.



Figure 5-18 PRELOAD zeroes (0) shifted in to drive cells

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

u1 u2

u3 u4

A

BC

0

00

D 0



Figure 5-19 .Interconnect Test finding an open on a receiver

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.

TDI

Open

TDO

u4u3

u2u1A

BC

000

AB

1

AB

D

000

0 A



Figure 5-20 Interconnect Test finding an open on a driver

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

TDI

Open

TDO

AB

C

000

1 A

1 AAB

D

000

u1 u2

u3 u4



The enhanced counting sequence first assigns a 01 bit combination that we'll call the power bits. These bits verify that the node is not shorted to ground or VCC. They also eliminate aliasing to these power nodes. The counting bits follow, and form the part of the node's signature that primarily distinguishes one node from another; no two nodes can have the same number. The above example shows four bits, but the length of these bits is determined by the number of nodes in one frame. The last part of the signature, the complement bits reduce the incidence of aliasing between active nodes. The number of bits used here is a fixed percentage of the number of counting bits used.

shows how a short is detected by comparing the expected signature of a particular node with the one captured during testing.

Table 5-5

Frames

Node Power BitsEliminates Aliasing to Ground or VCC

Counting BitsPrimarily Distinguishes one Node From Another

Complement BitsReduces Incidence of Aliasing Between Active Nodes

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



Figure 5-21 .Interconnect Test uses signatures to check for shorts and opens. In this example, a short is detected

Testing Bidirectional PinsInterconnect test fixes the direction in which it tests bidirectional cells. An internal routine determines whether to test bidirectional cells as drivers or as receivers.

Interconnect Test and Bussed DevicesOpens on bussed devices is a class of problems that are not checked for in interconnect tests. Safety is the main issue here because buswire tests lengthen the time during which power is applied to the board; shorts could damage devices during this time.

Expected Signatures

Captured Signatures

TDO

TDI

A

BC

00 0

011

AB

D

u10 1 10 1 1

u2

u4u3



Buswire tests are drawn out of interconnect tests and made an independent object, which alleviates this problem; it minimizes the number of frames needed for

interconnect test, which allows shorts to be detected as soon as possible. Buswire testing is discussed in more detail in the next section.

Figure 5-22 Software breaks out buswire tests from Interconnect Test

Buswire TestRemember that this test is created automatically, and in

most cases will work without debug. The information in this section is provided for background. During

Control Cell

Control Cell

TDI

TDO

u2

u48

910

u3

u111

1213



interconnect test, opens on bussed nodes could be missed for a number of reasons. Because of the safety issues mentioned above, attention to this class of faults is delegated to separate, buswire tests. Buswire test is

derived from the connectivity information used to generate the interconnect test. If IPG sees that the chain has bussed devices, it generates the buswire test. Figure 5-23 illustrates buswire test.

Figure 5-23 Buswire Test verifies connections on bussed nodes

TDI

TDO

u1 u2

u3 u4



The buswire test looks only for opens on bussed devices. Shorts are not a concern because these were tested for in the tests (shorts, powered shorts, and interconnect) executed earlier. Drivers are tested one at a time to ensure that all possible situations for which opens could occur are tested.

Figure 5-24 shows several examples where opens could be missed during interconnect testing in the case of bussed devices. These examples are briefly described below.

AIf only one driver per bussed wire is enabled during interconnect test, opens on the disabled drivers would not be detected.

BIf two or more drivers must be enabled to satisfy interconnect test and they drive the same node, an open on one of these drivers would not be detected.

CIf two or more drivers must be enabled because they are connected to the same control cell, an open on one of these drivers would not be detected, even in the buswire test.



Figure 5-24 Example cases where opens could go undetected on bussed wires

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

Testing Parallel BussesOne other issue to consider when testing bussed devices is parallel busses. InterconnectPlus was designed to handle these cases with minimal impact on test size and execution time.

Drivers Ganged For Increasing Current

(This Failure Cannot be Detected by Any Method)

C

Undetected Failures

Undetected FailuresUndetected Fai lures

Control Cel l to Other Fan Drivers

ON

ON

A

OFF

ON

OFF

B

ON

ON



Because the sample chain includes two pairs of bussed wires (A and B in Figure 5-25), each separate, independent bus can be tested in parallel.

Table 5-6

Device.Pin Node Bit Pattern

u1.10 A 01 ZZ

u3.10 A ZZ 01

u1.9 B 01 ZZ

u3.9 B ZZ 01



Figure 5-25 Parallel testing for separate bussed nodes

If the chain included a third driver on wire B, as shown in Figure 5-26 on page 5-47, a third pair of frames would be needed to test this wire. The number of frames

TDO

TDI

u110

98

A

BC



in a buswire test is equal to two times the size of the bus with the largest number of devices connected to it.

Table 5-7

Device.Pin Node Bit Pattern

u1.10 A 01 ZZ ZZ

u3.10 A ZZ 01 ZZ

u1.9 B 01 ZZ ZZ

u5.5 B ZZ 01 ZZ

u3.9 B ZZ ZZ 01



Figure 5-26 Multiple drivers on one bus require additional frames

Connect TestRemember that this test is created automatically, and in most cases will work without debug. The information in this section is provided for background. InterconnectPlus connect test allows you to test for

opens on device inputs and outputs that have physical probes assigned to them. Shorts between pins with testhead access are detected by the unpowered shorts test. Connect tests are run sequentially, from the first device in the chain (uX) to the last device in the chain

TDI

TDO



(uY) until all devices have been tested. All other devices in the chain are placed in BYPASS. One connect test is generated for each device in the boundary-scan chain

with testhead access. Figure 5-27 illustrates boundary-scan connect test.

Figure 5-27 Connect Test checks the connections of each device in a chain

TDO

TDI



NOTEIf an upstream device that is in BYPASS has outputs that affect the DUT, IPG will generate the required disabling methods to eliminate conflicts

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

Connect test employs the Parallel Toggle macro. Complimentary patterns are captured, shifted, and compared to check for opens. A test is created for each boundary-scan device that:

■ is not TAP ONLY (as indicated in the data entry phase)

AND

■ has one or more of its pins connected to real testhead probes.

Connect test performs the following actions:

■ Inputs are confirmed by placing an alternating 0/1 pattern on the testhead nails and looking for this pattern on the device inputs.

■ Outputs are confirmed by first placing all device outputs high, then low (in alternating patterns), and looking for this pattern at the testhead nails.

A connect test can fail in one of two manners:

■ the TAP Integrity procedure could detect a problem.

■ the connect verification routines could detect a problem.

Failure messages describing the exact nature of problems detected during the TAP Integrity procedure are encoded directly in the VCL source itself. The failing vector number is also printed on the repair ticket along with a failure message. These two items provide you with a place to begin looking for the problem.

Connect tests are created for each device in each boundary-scan chain if those devices have any input or output pins connected directly to the testhead (that is, if those devices have any accessible nodes). These tests do not check for shorts between nodes; they look for opens only. Therefore, connect tests should not be executed until both the unpowered shorts test and the (powered) interconnect test have been run. If this procedure is not followed, undetected shorts could cause device damage and inaccurate diagnosis.

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



NOTEDatalogging software logs opens on bidirectional pins only during the output part of the test. Input failures of bidirectional pins are not logged to prevent duplication of failure information.

Comparing Connect Test with Boundary-Scan In-circuit TestBoundary-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. All device pins require physical probes (including TAP pins) and all pins are tested. Boundary-scan in-circuit test is pin-oriented.

■ Devices connected in a chain�Connect test performed on one device at a time; other devices in chain are in BYPASS. Only those nodes that have physical probes assigned are tested. Boundary-scan connect test is node-oriented.

Connect test also provides superior diagnostic resolution. The in-circuit test normally finds only one faulty node, then stops the test. The connect test can find multiple failures and reports on all of them.

NOTEBoundary-scan in-circuit test is discussed in chapter 1 as the EXTEST stand-alone function.



Figure 5-28 Comparing boundary-scan in-circuit and connect tests

Custom Boundary-Scan TestsCustom 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

by EXTEST, such as powered shorts, interconnect, buswire, or connect test. These tests perform specific functions that are not added to your board test as part of the automatic test generation process.

TDO

TDI

Devices Connected in a Chain(All Connect Test Nodes Must have ProbesPhysical Probe

Devices Not Connected in a Chain



Like the standard Boundary-Scan software, InterconnectPlus features an interactive user interface that helps you develop custom boundary-scan tests for your device chains. Chapter 6, �Multichip Scan Port Driver and the MSPD Interface,� describes this interface and how to use it.

An important issue to consider is when to use the interface to develop custom tests. If you know that you want to generate custom tests, you should write an ITL file that describes each chain for which you plan to develop custom tests. This strategy allows you to develop the tests and create the custom library test file that IPG will need when it generates your board test.

The alternative is to run IPG first, then copy and edit an ITL file that it generates when you are ready to develop the custom tests. After you have completed the custom test, you must run IPG in incremental mode on the new, custom library test file.

Chapter 6 provides detailed information about performing this task regardless of the strategy that you choose to employ.



Generating Tests For Boundary-Scan Chains

Once you describe your boundary-scan devices and board topology to the test system, test generation is automatic. Generation of boundary-scan tests is integral to the test system software. The information that you provide allows the system to identify boundary-scan devices and the types of test needed for these devices.

Although the InterconnectPlus software generates tests automatically for your boundary-scan devices, you should still understand how the test system uses the information that you provide to generate your device tests. This section provides a brief discussion of this test generation process.

This section also describes:

■ how to enter the information needed by the system.

■ the importance of complete and accurate BSDL files; a critical link to successful implementation of boundary-scan testing.

■ disabling or overdriving devices that affect boundary-scan testing.

■ best practices for developing boundary-scan tests.

■ the boundary-scan testability report

The Test Generation ProcessFigure 5-29 is a flow diagram of the process for generating a chain test. The diagram starts in Board Consultant where you enter information about each device. The resulting test process happens automatically and tests are generated automatically.

NOTEThe BSDL file for each device must be complete and accurate before entering the test process. Incomplete or inaccurate descriptions can result in complicated debug later in the process. For more information, refer to the section �Confirming the BSDL File� found later in this chapter.

Internal compilers use board and location information to generate the board files board and board_xy. These files are then used by topology analysis software and IPG to determine the devices in a chain and their locations on the circuit board.



Figure 5-29 Process flow for generating a chain test

"board.o"

IPGCreates 5 ITL Source Files

MSPD -ser ia l i ze rcreat es 4 VCL source f i l e s

C ompi l er

Se r ia l i z ed Te s tuX_sn .vc l

anduX.vc l .x

BOA RD CONSULTA NT

C ompi l er

TESTHEAD

See Note on the

TOPOLOGY

�board� �boar d_xy�

Powe re d Shor t s Te s t(1 per cha in )

uX_uY_ps

Inte rc onnec t Te s t( 1 per cha in)

uX_uY

Buswire Tes t(1 per cha in ) uX_uY_bus

Connec t Te s t S i l i con N ai l Tes t(para l l e l t e s t )

uX

(1 per dev ice connect ed to rea l na i l s )uX _connec t

Pow ered Short sTes tuX_uY_ps .vc l

anduX_uY_ps .vc l . x

Int erconnec t Tes tuX _uY.vc l

anduX_uY.vc l .x

Buswire Te stuX_uY_bus .vc l

anduX _uY_bus .vc l .x

Connec t Tes tuX _c onnec t .vc l

anduX _uY_c onnec t .vc l

Powered Short s Tes t(e xecutab le )uX_uY_ps .r

oruX_uY.o

Inte rc onnect Te st( exec ut able )

uX_uY.ror

uX_Y.o

Buswire Te s t(exe cutab le )

uX_uY_bus . ror

uX_uY_bus .o

Conne ct Tes t( exec ut able )

uX_conne ct . ror

uX_conne ct .o

S i l i con Na i l Te s tuX_sn .o

(exe cutab le )or

uX.r

R esul t s A na lys i s

next page.

"board_xy.o"



NOTEITL source files contain references to BSDL files. These files must have been compiled (creating .o objects) in advance of compiling the ITL files.

IPG generates four preliminary test structures: powered shorts, interconnect, buswire, and connect. IPG generates one interconnect test for each chain, one buswire test for each chain, one powered shorts test for each chain, and one connect test for each device in the chain connected to physical probes. The names assigned to each test type by IPG are:

■ powered shorts test: <device_1>_<device_2>_ps, where <device_1> is the name of the first device in the chain and <device_2> is the name of the last device in the chain. For example: u1_u4_ps

■ interconnect test: <device_1>_<device_2>, where <device_1> is the name of the first device in the chain and <device_2> is the name of the last device in the chain. For example: u1_u4

■ buswire test: <device_1>_<device_2>_bus, where <device_1> is the name of the first device in the chain and <device_2> is the name of the last device in the chain. For example: u1_u4_bus

■ connect test:<device>_connect, where <device> is the name of one device in the chain. For example: u3_connect

IPG then sends this information to the MSPD serializer, which creates four types of VCL source files: powered shorts test, interconnect test, buswire test, and connect test.

NOTEThe Silicon Nail test path is shown in Figure 5-29 only to identify its relationship to standard, chain test generation. Silicon Nail testing is discussed later in this chapter.

These source files are sent to the VCL compiler, which generates executable tests that can then be incorporated into the testplan.

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

Describing Your Boundary-Scan DeviceTo generate tests for a chain of boundary-scan devices, you must tell IPG where it can find the BSDL files for your devices, and you must describe your devices. Both of these tasks are accomplished using Board Consultant.



Using the Library Path Names FormUse this form, as Figure 5-30 shows, to tell IPG where to look for the BSDL files for your devices.

1 Select Program > Run Board Consultant.

2 When the Board Consultant interface appears, either create a new board file or load an existing board file.

3 Click on the View/Edit Library Data button in the flowchart, then Enter Library Paths from the list at the bottom of the flowchart.

4 When the Library Paths Form appears, type the appropriate path in the Library Path's field.

5 When you finish entering new paths, click on the Update button.

6 Click on the Close button to exit the form.

Figure 5-30 Use the library paths form to tell IPG where to find the BSDL files



Using the Device Entry FormFigure 5-31 shows the device entry form for pin libraries, where you enter information about your boundary-scan devices.

1 Select the Program > Run Board Consultant.

2 When the Board Consultant interface appears, either create a new board file or load an existing board file.

3 Click on View/Edit Board Description in the flowchart, then Enter Pin Library from the list at the bottom of the flowchart.

4 The basic Device Entry Form appears. Select Options > Show Scan Library Test Options.

5 When the form appears, select Options > Maximize to display the form shown in Figure 5-31.

The top half of the form provides you with a tool to customize your board's files for test and fixture generation. The use of these fields is described in Tools�2. 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.

NOTERefer to Tools�2 for detailed information about using the Board Consultant interface.



Figure 5-31 Board Consultant device entry form



■ Testable: Select Yes if the device is to be tested, or No if it is not. Yes is the default selection.

■ Test Using TestJet: Select Yes if TestJet will be used to test this device. No is the default selection. If you select Future, holes for TestJet probe are partially drilled, but the wiring and mux assignment is not made.

■ TestJet Probing: Select the TestJet probing method: Select the default, Keepout Method, to use the old keepout technique. The other selections perform the following tasks:

■ Auto Selection: Uses the device outline to programmatically define the TestJet probe type and where to drill the fixture to mount this probe.

■ Foam Override: Uses the foam mounted probe regardless of the dimensions of the device. (This option is not allowed if the device is on the bottom side of board.)

■ Spring Override: Allows you to override the software�s automatically selected probing method. The software will choose a small or standard probe automatically, based on the device outline dimensions. Use one of the following new options to override the automatic choice:

■ Small Spring Override: Instructs the fixturing software to use a small TestJet probe normally used with Polarity Check tests. Probe locations are directly across from each other.

■ Standard Spring Override: Instructs the fixturing software to use a standard TestJet probe. Probe locations are at two opposite corners of the active board.

Any devices with TestJet Probing set to something other than Keepout Method must also have a device outline in order for the 3070 software to determine where to place the probe or where to partially drill for a potential future probe. If a device with a non-keepout TestJet Probing setting does not have an assigned device outline, this error that will prevent compilation of board_xy.

■ Library Test Expected: Select Yes if you want the standard digital library test for the designated device to be generated along with the boundary-scan tests. To execute this test, your device must have probes assigned to all nodes. No is the default selection.

■ Test Using Connect Check: Select Yes if Connect Check will be used to test the device. The default is Yes.

■ Device Outline: Enter the corners of the device outline area in the X Value and Y Value fields. If only two device outline points are entered, these two points will be treated as opposite corners of a rectangle. If more than two device outline points are entered, the device outline will be a polygon whose vertices are the points entered, ordered



exactly as they are listed in this form; point_1 to point_2 to ... to point_N.

The device outline must have at least two points, and can have up to 120 points. If the last point listed is not identical to the first, that point will be assumed automatically in order to close the polygon. The units of measurement are tenth-mils.

While any device may be assigned an explicit device outline, outlines are truly required only for devices to have a TestJet probe placed over them automatically (now or in the future) for testing using TestJet or Polarity Check (i.e., devices whose TestJet Probing attribute is set to something other than Keepout Method).

■ Capture Graphic Device Outline: Click this button to copy the polygon currently being used as an outline for this device into this form as the explicitly assigned device outline. If the device outline shown in the graphic is rectangular, only two points will be copied into the form -- the upper left and lower right corners of the rectangle. Otherwise, all of the points in the graphic polygon are copied, keeping their ordering.

The default outline used in the graphics window is a rough guess based on device pin locations. If it is not close enough to the actual device profile to allow adequate probe placement, edit the outline and adjust it before you select Replace Device.

■ Clear: Clears out all the X/Y values. Once you have assigned an outline to a device, it will be used in the graphics window. Thereafter this button will simply copy that outline back from the graphics window. To return to the default, estimated outline originally used in the graphics window, select Clear Outline, then Replace Device, and press this button again.

■ Testability Standard: Click on the 1149_1 box if the designated device is a boundary-scan device. When you click on the 1149_1 box, you enable the options and data entry fields in the lower half of this form. If you do not click on the 1149_1 box, the test system will not consider this to be a boundary-scan device. Clicking on this box does not imply that the device is fully-compliant with IEEE 1149.1.

■ BSDL Part Number: Enter the name of the BSDL file for the designated device. This file is treated as a library file in that it is looked for in the same order as other library devices specified in the Library Paths Form. If a BSDL file match cannot be made, the compiler will generate an error.

■ Device Package Type: Enter or change the package type for the designated device. If the package type specified cannot be found, the compiler will generate an error.



■ Connect Test: Select Yes if you want IPG to generate a boundary-scan connect test for the designated device. A connect test is written for the device only if physical probes are assigned to nodes for that device. The part must have an interconnect test to perform a connect test. The default is Yes.

■ TAP Signal Overrides: Brings up the TAP Override Form to allow you to specify the nodes for tdi, tdo, tck, tms, and trst, which will affect how the chain is derived but does not represent a change in connectivity.

■ Interconnect Test: Select Full if you want IPG to generate a boundary-scan powered shorts and interconnect test (and associated buswire test) for the designated device. Select TAP only if the device is non-compliant in some way, but you do want to keep this device in your chain. The default is Full.

■ Connect Max: Enter a value between 1-999 to specify the maximum number of nodes to test in any connect test. This value is not applicable if TAP only or Interconnect only are selected. If a zero is entered, this field will be set to blanks.

The digital kernel of a powered shorts test is essentially identical to that of an interconnect test with one addition: the surrounding (adjacent) nailed nodes are also tested automatically when a powered shorts test is generated

Connect Max cannot be used with versions. You can only change Connect Max value in the base device. The Connect Max value will be the same for all versions. See Connect Max on page 5-62 for an explanation of this feature.

NOTEIf you use Connect Max to conserve channels, select No for the Library Test Expected field. If this field is Yes, the system will assign resources for a standard in-circuit test, whether or not Connect Max is selected.

After you have described your devices and added them to your test, when you leave Board Consultant, the board compiler runs and IPG Test Consultant checks to see if a library model exists for the test. You should have at least a setup-only test in the library at this time, particularly to provide IPG with pertinent disabling and device family information. (Disabling information is not needed for boundary-scan disabling. See Using Boundary-Scan Disabling on page 5-71 for more information.) Note that IPG cannot find the setup-only tests unless you mark the Library Test Expected field in each corresponding library entry form as Yes.

Figure 5-32 on page 5-62 shows the device entry form as it would appear for a TAP-only device. Remember that specifying a device as TAP-only eliminates that device from boundary-scan testing but allows you to



keep the device in the chain, which in turn allows for better overall testing of the chain.

The connect button must be set to No if you want to specify the device as TAP-only. Setting the Connect Test button to Yes disallows a TAP-only setting, or changes the Interconnect Test button to Full if you had previously set it to TAP-only.

You can specify a library test to be performed on a TAP-only device if you so desire. Set the Library Test Expected button to Yes if you want IPG to generate a standard digital library test for your TAP-only device. Remember that you must have physical probes assigned to every node for each device that will have a standard digital library test generated.

Connect MaxOne of the standard parts of the test development process is using Board Consultant to verify that your board test will fit within the resources of your tester (Figure 5-32). Sometimes, you encounter a situation where you require more digital channels than your tester has available (Figure 5-33). If this problem is the result of a connect test on a large boundary-scan IC, the Connect Max feature can often help.

Figure 5-32 Verifying that your board test fits within your tester configuration



Figure 5-33 A test requiring more channels than the tester has available

The Connect Max feature allows you to test boards that otherwise would have exceeded the channel count of your system. For example, you can divide a connect test

of 400 pins into eight small connect tests by setting the Connect Max to 50. It is a good practice to set the Connect Max to an even divisor of the number of pins, as in this example.

Whenever you specify a Connect Max setting, you should also use the Device Entry Form to mark the part as not expecting a library test. If a library test is expected, the test will require the channels you otherwise would have saved by breaking apart the connect test.

By using the Connect Max feature, you can use testers that are appropriate to the number of nodes on the board, without having to add pin cards to accommodate a large number of channels. You can determine the number of channels used in the connect test (or any other digital test) by the following procedure:

■ Add the number of input pins to the number of bidirectional pins

■ Add the number of output pins to the number of bidirectional pins.

■ Select the larger of the two numbers determined above. This is the channel count.

Understanding the Contents of the BSDL FileA key experience gained in early implementations of boundary-scan is the importance of describing the component correctly. Because the Boundary-Scan



Description Language (BSDL) file is used to create thousands of test vectors automatically, it is very important to make sure that each BSDL file is complete and accurate before working with scan chains. Accuracy in this description is very important for correct fault diagnosis and minimal debug time.

Extra effort in this phase can save many hours, or even days, of debug in later phases. In the early implementations of boundary-scan, many things are unknown. A few crucial questions that must be answered include:

■ Does the device meet the IEEE standard?

■ Is the TAP controller standard-compliant?

■ Does the BSDL description correctly describe the silicon?

Note that if the BSDL description is technically correct, but does not exactly match the silicon implementation, then false faults will be reported, and more time will be spent in debug.

Other unknowns include, but are not limited to:

■ Does the person who writes the BSDL have correct information?

■ Have any typographical errors been introduced?

The description of the boundary-scan characteristics of a device is contained in the BSDL file for the device. If the BSDL descriptions of all of the devices in a chain

are correct, and the topological descriptions of the circuit interconnections are correct, few things can negatively affect an automatically-generated test.

The construction of the boundary-scan chain is extracted from the board topology and the BSDL file for a device. That description is used to determine such things as:

■ The locations in the overall TDI-TDO chain that correspond to the expected data for each cell connected to each pin on each device. This tells the test generation and analysis routines where to find the bits representing each node.

■ Which cells in the boundary-scan chain are control cells, and what outputs or bidirectional pins they control. This data is used to disable pins that might interfere with the test.

■ What the expected IDCODES for each device should be. The IDCODES are verified during the TAP integrity test.

■ What each cell in the Instruction Register captures when clocked in the CAPTURE-IR state. The expected capture information is verified for each device during the test.

What are the problems that might be encountered if an inaccurate BSDL file were provided for a device? Consider Figure 5-34, an example of how interconnect tests are executed.



Each of the interconnections between the two devices terminates at a Boundary Register cell (either a driver or receiver). The test information placed on the interconnections is shifted in through TDI. The results of the test are shifted out from TDO and captured. The captured data is subsequently examined.

Figure 5-34 shows an extra internal cell that could be missed in the BSDL file. If this were the case, the Boundary Register description for the device would be incorrect, and data would be placed into or extracted from the wrong positions in the chain. Not only would the information be wrong for the device described, but if the length of the Boundary Register was incorrect, every device in the chain between the mis-described device and TDI would be offset by the inaccuracy.

This would be catastrophic for the GO/NOGO test, and for the failure analysis. Every pin on every device in the inaccurate area would fail because the cells being examined would not be the ones containing the expected data. Misrepresented registers can result in garbled signatures.

Now, consider the effects of failing to accurately describe the control cells for a device. Figure 5-34 shows two output control cells for one device. If this device needed to be disabled, and the control information were inaccurate, then the disable would not occur. The effect would be that those nodes connected to the non-disabled pins would fail with a variety of incorrect diagnoses.

For these and other reasons, we strongly recommend that the BSDL descriptions of each device be thoroughly verified against the silicon itself; once for each new device type.



Figure 5-34 Inaccurate BSDL descriptions cause testing problems

Internal*

TDO

TDI

* Cells Missing From BSDL

TCK

TDI Output* Control

Output Control

TMSTDO



Verifying BSDL DescriptionsTo eliminate as many of these potential problems as possible, you should use an automatic tool to create BSDL files. If a verified automatic process is not in place, you should test the BSDL file and the new component in a stand-alone configuration, without interference from other components. This can be done by using the Verify BSDL macro featured in the standard Boundary-Scan software to automatically generate a test for each device. The test generated can then be executed by:

■ building a special test fixture for the component...or

■ loading one board with only the boundary-scan component and arranging access to all pins...or

■ verifying the BSDL file at device test if the semiconductor test supports BSDL-based boundary-scan...or

■ translating the test to simulator input, then simulating it against a model of the device

NOTEBecause this function is for a single device, you must use the SPD Interface to find the Verify BSDL macro; refer to chapter 4.

NOTEFor more information about this macro, refer to chapter 4 of this documentation.

Where to Place BSDL Files and Associated PackagesIdeally, you should place all custom BSDL files and their associated packages in one location so that they can be found easily by system software. The pathname to the directory reserved for this function is /3070/library/supplemental/bsdl This path is guaranteed to be where standard packages are. However, you may also place BSDL files in library directories associated with the board directory. Be sure to provide a library path to them.

Placing user-defined packages in the proper location is of particular importance. When reading a BSDL file, the system will look for associated packages:

■ in the same directory where the BSDL file itself resides, and

■ in the standard location, /3070/library/supplemental/bsdl

On the other hand, the main BSDL file belongs in the board directory�s library path, which may or may not include ../supplemental/bsdl. Give the BSDL file and digital library files for a device different names so the system will not mistake one for the other. Having the



same names in different paths will not avoid such a mistake.

Conventional Disabling of Boundary-Scan DevicesTo disable boundary-scan devices, you can use the techniques described in this section. You can also use boundary-scan resources to disable device outputs. See Using Boundary-Scan Disabling on page 5-71 for more information.

For conventional disabling, IPG will take care of all bus disabling for interconnect, buswire, and connect tests, just as it does for standard digital tests. However, you must provide disable vectors for Silicon Nail tests. Figure 5-35 shows a circuit that requires bus disabling.

All disabling nodes must have physical probes assigned to them.

During a boundary-scan test, you can encounter several disable conflicts. Some of these include:

■ disabling a control node connected to an interconnect node

■ disabling a control node connected to a connect test output

■ a device output that cannot be disabled that is connected to a connect test output

■ a device output that cannot be disabled that is connected to an interconnect node, except for tested boundary-scan outputs on devices in the chain being tested

Agilent IPG removes bussed nodes from boundary-scan tests if the proper disabling cannot be done. HP IPG cannot always accomplish the disables as needed. If a disabling conflict arises, HP IPG rejects the disable method, and reports in the source file that the node was not disabled.



Figure 5-35 Disabling a device to maintain a stable test

All boundary-scan devices should have at least setup-only files in a digital library before you generate your fixture files so that disabling information is provide to IPG. To understand why this is necessary, consider the following scenario as illustrated by Figure 5-36.

Device must be disabled when u1 and u2 share data.

TDI TDO



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

The illustration shows a chain of boundary-scan devices with three bidirectional pins bussed together. This bus also has a physical probe assigned, so a connect test will be generated for each device. Remember that when a connect test is executed, only one device is tested at any one time. All other devices are placed in BYPASS.

The devices not being tested must be disabled so that they will not interfere with the verification of the device under test. Because they are in BYPASS, and the core logic is active, the bidirectional pins could be active. Therefore, it is necessary to disable the devices in BYPASS by using standard disable methods.

-b id irec t i ona l p ins

BYPASS

TDI

EXTEST BYPASS

BYPASS

TDO



IPG will do this automatically, but it must have at least a digital library setup-only file that contains the disable information so it can perform the required disabling.

For more information about conventional disabling, refer to Digital�2.

Fixed Node ConsiderationsIf you know that your board has fixed nodes�tied to power or ground�use Board Consultant to define them in your board file. When IPG runs, it will add this information to the ITL source file. The example below shows an ITL source file for a connect test that includes fixed node information.

Example 5-2 ITL source file with fixed node information

connect "u44"chain "u57_u44"

tdi "TDI"tdo "TDO"tms "TMS"tck "TCK"trst "TRST"devices

"u44","users/scan_brd/digital/74bct8374","FK_PACKAGE", no

end devicesend chainnodes

fixed high "+5V" test "u44.7"node "u44-8" hybrid test "u44.8"

end nodesend connect

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

Using Boundary-Scan DisablingInterconnectPlus lets you use boundary-scan resources to disable device outputs.

To use this feature, set the Boundary-Scan Disable field to On. This field is located in the IPG Global Options Form in Board Consultant. The default value is Off to permit backward compatibility with previous versions of InterconnectPlus.

This feature is highly recommended for new tests (tests not prepared under a previous version of InterconnectPlus).

NOTEWhen you set the Boundary-Scan Disable field to On, the Boundary-Scan Overdrive field is automatically set to Off.



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

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

Boundary-Scan Disables OnWhen a connect test is executed, only one device is tested at a time. If other devices in the chain have bussed pins that need to be disabled in order to test a pin of the selected device, the bussed devices will be issued the HIGHZ instruction, instead of the BYPASS instruction, to allow testing of the bussed pins.

If the HIGHZ instruction is not available for a device that needs to be disabled, the device will be issued the CLAMP instruction during the connect test, if it is available. If the CLAMP instruction is not available, the device will be issued the EXTEST instruction, and its

boundary register will be loaded with the necessary patterns to control the drivers for the bussed pins.

Advantages of Boundary-Scan DisablingBoundary-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).

■ Minimizes the need for conventional disabling (seeConventional Disabling of Boundary-Scan Devices on page 5-68). This can decrease the resource requirements for in-circuit tests. It also removes the need to manually specify disable methods in device libraries, reducing the opportunity for error.

■ Speeds the disabling process.

■ Increases the chance of successfully disabling devices.

■ Relieves many conventional disable conflicts.

■ Runs automatically once you have turned it on.



Effects of Boundary-Scan DisablingBoundary-scan disabling has these effects:

■ If the Boundary-scan library test does not include the HIGHZ statement, only pins of type output and bidir are disabled. If the Boundary-scan library test does include the HIGHZ statement, pins of type buffer are also disabled.

■ Adds a new ITL file with the suffix _dis for each chain

■ Adds a new VCL program with the suffix _dis for each chain

■ After boundary-scan disabling, boundary-scan device TAPs are placed in the Run-Test/Idle state instead of the Test-Logic-Reset state. This may create the need to add pull-down resistors to maintain the Run-Test/Idle state during subsequent testing. See Maintaining Persistence of Boundary-Scan Disables on page 5-75 for more information.

■ After performing boundary-scan disables, the test plan pauses, displays a message on the screen, and inserts a comment into the test program. See Maintaining Persistence of Boundary-Scan Disables on page 5-75 for more information.

■ The IPG verbosity modes give information about boundary-scan disables.

Boundary-scan disabling may also affect testing order:

■ For a single chain:

� Boundary-scan tests take place.� Boundary-scan disabling occurs.� In-circuit tests are performed.

■ For multiple chains:

� Boundary-scan disables occur for all chains except the one being tested.

� Boundary-scan tests take place for the current chain.

� The first two bullets are repeated for each chain.

� Boundary-scan disabling takes place for all chains.

� In-circuit tests are performed.

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



Limitations of Boundary-Scan DisablingBoundary-scan disabling will not work with all devices, pins, or chains. You must use conventional disabling with:

■ Tap-Only devices� which are assumed to support BYPASS mode only

■ Non-compliant output pins■ Hybrid chains such as multiple independent serial

paths with common TCK and TMS signals■ A chain without access to a TAP signal

Boundary-scan disabling is also limited in these situations:

■ If you do a conventional in-circuit test on a boundary-scan device when it is in boundary-scan disable mode, the device will ignore and fail the test. To make the device work, you must reset the device. You can reset by going to the Test-Logic-Reset state, by a normal Reset, or cycling the power. (Which method to use depends on the component.)

■ During manual debug, you must run VCL programs for boundary-scan chain disables before running any target in-circuit tests. If you do not run the disable programs first, the in-circuit tests may not work. (Pushbutton Debug automatically executes the disables in the proper order.)

■ You cannot use boundary-scan disabling for boundary-scan devices that have non-compliant

pins. If you disable boundary-scan pins, the device�s internal logic may go into an undefined state and prevent a conventional disable from working on the remaining pins (Figure 5-37). If a boundary-scan device has any non-compliant pins, you must declare the device to be TAP Only and use conventional disabling on all the device�s pins.



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

Maintaining Persistence of Boundary-Scan DisablesSome device and board designs may destroy boundary-scan disables. You may thus need to take additional measures to maintain the disables for subsequent tests.

Without boundary-scan disabling, boundary-scan device TAPs end testing in the Test-Logic-Reset state. Boundary-scan disabling, however, parks each TAP in the Run-Test/Idle state (Figure 5-38).

BP

IR

TAPCONTROLLER

Disabled boundary-scan pins

Disabled boundary-scan pinsNon-boundary-scan pin

Non-boundary-scan pin

Inter

nal l

ogic

unde

fined

(non-compliant)

(non-compliant)

Boundary-scan device with non-compliant pins



TAP state machines in every device of the chain must be held in Run-Test/Idle during any subsequent digital testing that depends on boundary-scan disables. This is called persistence.

A standard boundary-scan device contains internal pull-up resistors on TMS. These resistors may make the TAP go to the Test-Logic-Reset state if:

■ An oscillator is connected to the TCK input.

■ Noise is generated by other parts of the board that couple into TCK.

The existence of these conditions should alert you to check the persistence of boundary-scan disables.

Also, after performing boundary-scan disables, the test plan pauses and produces a screen message:

Test Programmer Action Reminder:Evaluate, act, and then delete this ‘pause’

section.



Figure 5-38 TAP Controller State Diagram

01

1

Update-DR Update-IR

01

1

Exit2-IR0

Exit2-DR0

11

0Pause-DR Pause-IR 0

00

1

1

Exit1-IR1

Exit1-DR

0

1

0

0

Shift-IR

0

Shift-DR

11Capture-IRCapture-DR

00

1Select-DR-Scan Select-DR-Scan

1

Data Instruction

10

0

1

Run-Test/Idle

Test-Logic-Reset

Normal boundary-scan tests end in this state

Boundary-scandisabling placesthe componentin this state



The test plan inserts a comment into the test program that reminds you to check the persistence of your boundary-scan disables. These comments follow the

pause statement. You can view them when you edit the test program. Example 5-3 shows a sample message.

Example 5-3 Sample message

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

As stated in the message, you should change the print and pause statements to comments after you check persistence and debug the program.

To check persistence:

1 Prepare the test with the Boundary-Scan Disabling field set to On.

2 Run the test until it pauses.

3 Examine the TCK and TMS signals to make sure they are in a stable state. TMS and TCK should be held to a logic low level. (TCK could also be held to a logic high level if all boundary-scan devices support a stable state when TCK stops at 1.)



4 If TCK and TMS are not quiescent�such as when an oscillator is connected to TCK�either:

■ Shut the oscillator off.

■ Connect TCK to a 3070 general purpose relay to a pull-down resistor (typically 150 ohms to ground for TTL/CMOS). This keeps the TAP in Run-Test/Idle. For example, the oscillator line may include an AND gate to which you can connect the pull-down (Figure 5-39).

■ If the oscillator is not gated, add the relay to pull-down to TMS (Figure 5-39). As shown in the state diagram (Figure 5-40), feeding a zero signal to TMS keeps the TAP in Run-Test/Idle.

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



Figure 5-39 Maintaining the persistence of a boundary-scan disable by adding a pull-down or relay.

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.

Oscillator

AND

VccBoundary-scan deviceswith internal pull-up resistors for TMS

TMS (should be held at a logic low level)

TCK TCK

GP

Optional general-purpose relay topulldown resistor (<= 150 ohms)

Vcc

GP

TCK should be held at a logic low level.It can also be held at a logic high levelif all boundary-scan devices support astable state when TCK stops at �1�.



Figure 5-40 Example of chain that requires multiple pulldowns

Overdriving Boundary-Scan DevicesWhen IPG generates a connect test, it tries to use all of the chain. If you assign physical probes to each (or specific individual) TDI/TDO node, the system can overdrive these nodes, and an individual device can be tested. This may shorten test time and provide better fault isolation. To do this, you would use the IPG Global Options Form in Board Consultant and set the Boundary-Scan Overdrive on. There is a potential problem with overdriving since the portion of the chain not involved in the test is still being clocked. If you do not want to overdrive upstream TDOs, you would leave

the field set to Off and IPG would use the entire chain rather than local TDI/TDO nodes.

The only entry that you would be concerned with in this form (with respect to boundary-scan testing) is the Boundary-Scan Overdrive field. The default setting is Off. If you turn this setting On, IPG will use the local TDI and TDO nodes for each device to be overdriven provided probes exist on these nodes.

TDI

TMS2

TCK TDO

TDI TDO

TMS TCK

TDI TDO

TMS TCK

TDI TDO

TMSTCK

TDI TDO

TMSTCK

TMS1



NOTEWhen you set the Boundary-Scan Disable field On, the Boundary-Scan Overdrive option is automatically set to Off. See Using Boundary-Scan Disabling on page 5-71 for more information.

Refer to Tools�2 for more information about this form.

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

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



Figure 5-41 74ACT8997 Linker/MUX device linking chains A, B, and C.

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 CHAINS1u1_1u4

TDI 1TDITDO 1TDOTCK 1TCKTMS 1TMSDEVICES

1u1, 1u2, 1u3, 1u4;2u1_2u4

TDI 2TDITDO 2TDOTCK 2TCKTMS 2TMS

TDO

8997CkC2C1

B1 B2 Bj

AiA2A1

TDI PADBIT

PADBIT

PADBIT



DEVICES2u1, 2u2, 2u3, 2u4;

linker_linkerTDI TDI-LINKERTDO TDO-LINKERTCK TCK-LINKERTMS TMS-LINKERDEVICES

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.

Example 5-4 Single chain description

BOUNDARY SCAN CHAINS1u1_linker ! put two chains and linker together

TDI TDI-LINKER ! specify linker’s TAP signalsTDO TDO-LINKER ! drives the two chains’ TAPsTCK TCK-LINKERTMS TMS-LINKERDEVICES

!!! PAD, ! Pad bit inside linker1u1, 1u2, 1u3, 1u4,! first chain, TDI-->TDO order

!!! PAD, ! Pad bit inside linker2u1, 2u2, 2u3, 2u4,! second chain, TDI-->TDO orderlinker; ! 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;hybridtdo "TDO_LINKER" channel;hybrid



tms "TMS_LINKER" channel;hybridtck "TCK_LINKER" channel;hybriddevices

"1u1", "custom/74bct8374", "DW_PACKAGE", no"1u2", "custom/74bct8374", "DW_PACKAGE", no"1u3", "custom/74bct8374", "DW_PACKAGE", no"1u4", "custom/74bct8374", "DW_PACKAGE", no"2u1", "custom/74bct8374", "DW_PACKAGE", no"2u2", "custom/74bct8374", "DW_PACKAGE", no"2u3", "custom/74bct8374", "DW_PACKAGE", no"2u4", "custom/74bct8374", "DW_PACKAGE", no"linker", "custom/74act8997", "PQFP-48", no

end devicesend chain

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;hybridtdo "TDO_LINKER" channel;hybridtms "TMS_LINKER" channel;hybridtck "TCK_LINKER" channel;hybriddevices

pad"1u1", "custom/74bct8374", "DW_PACKAGE", no"1u2", "custom/74bct8374", "DW_PACKAGE", no"1u3", "custom/74bct8374", "DW_PACKAGE", no"1u4", "custom/74bct8374", "DW_PACKAGE", nopad"2u1", "custom/74bct8374", "DW_PACKAGE", no



"2u2", "custom/74bct8374", "DW_PACKAGE", no"2u3", "custom/74bct8374", "DW_PACKAGE", no"2u4", "custom/74bct8374", "DW_PACKAGE", no"linker", "custom/74act8997", "PQFP-48", no

end devicesinsert "digital/linker_setup"

end chain

EXAMPLE 1:

You have just translated data from Computer Aided Design (CAD) and now have a board file. The Boundary-Scan section of the testability report tells you that three Boundary-Scan chains exist on the board when you thought there was one. You discover a TI 74ACT8997 chip and two subchains on the board. You decide to test the board with the chains and the linker all grafted together. This means that you will need to turn on the Global Boundary-Scan Chain Override.

The list object function generates a new board file with the chain structure described at the very end. You edit the file as shown in the preceding section to perform the graft. The program generation process continues until the ITL files for Boundary-Scan are created by IPG. You edit the ITL files to add in the pad bits and a pointer to the PCF fragment, called, for example, linker_setup under the digital directory. You next create a text file under the digital directory called linker_setup containing a PCF block utilizing the scan PCF order for the TAP pins. This causes the linker to configure itself to control two subchains linked as one, per the

TI74ACT8997 data sheet, as shown in the next example. Now, you compile the ITL files and move on in the normal board development process. These files may be marked as permanent to retain them if the tests are regenerated. No other intervention is required.

EXAMPLE 2:

Following is the ITL source file for an interconnect test, for a chain that consists of a MUX/Linker and one secondary chain. Note that in the chain section, IC 2u8 is a linker/multiplexor IC. The TAP port connections (including a TRST* pin) are all made to IC 2u8.

In the devices section, a pad keyword is inserted before the description of device 2u1 to indicate that the MUX/Linker IC inserts a pad bit at the beginning of the chain. If there had been other secondary chains connected to the MUX/Linker IC, each of these is proceeded by a pad keyword as well.

Just before the end of the chain description is an insertion statement identifying a fragment of PCF code that is inserted into the generated test (see below). The PCF that is inserted is designed to program the



linker/multiplexor IC to connect the other ICs, 2u1 through 2u2, to the first multiplexor port. The end result when this linkage is completed is a chain of 5 devices, 2u1 through 2u8.

The rest of the ITL is unchanged from an interconnect description for a normal chain.



Example 5-7

---------------------------interconnect "mux_2u1_2u8"

chain "2u1_2u8"tdi "2MTDI" channel;hybridtdo "2MTDO" channel;hybridtms "2MTMS" channel;hybridtck "2MTCK" channel;hybridtrst "2MTRST" channel;hybriddevices

pad"2u1", "custom/74bct8374", "DW_PACKAGE", no"2u2", "custom/74bct8374", "DW_PACKAGE", no"2u3", "custom/74bct8374", "DW_PACKAGE", no"2u4", "custom/74bct8374", "DW_PACKAGE", no"2u8", "custom/74act8997", "DW", no

end devicesinsert "digital/2u8_setup"

end chain

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

pcf order is nodes "2IN_26","2IN_28"unit "disable"pcf"11"end pcfend unit

end disables

nodes



fixed low "1IN_16" test "2u3.24"silicon node "2U1_2" test "2u1.2","2u2.23"silicon node "2U1_4" test "2u1.4","2u2.21"silicon node "2U1_5" test "2u1.5","2u2.20","2u4.20"silicon node "2U1_U3_7" test "2u1.7","2u2.19","2u3.7"silicon node "2U1_U3_7" test "2u4.19"silicon node "2U1_U3_8" test "2u1.8","2u2.17","2u3.8"silicon node "2U1_U3_8" test "2u4.17"silicon node "2U1_U3_9" test "2u1.9","2u2.16","2u3.9"silicon node "2U1_U3_9" test "2u4.16"silicon node "2U1_U3_10" test "2u1.10","2u2.15","2u3.10"silicon node "2U1_U3_10" test "2u4.15"silicon node "2U2_2" test "2u1.21","2u2.2"silicon node "2U2_3" test "2u2.3","2u2.22"silicon node "2U3_2" test "2u3.2","2u4.23"silicon node "2U3_3" test "2u3.3","2u4.22"silicon node "2U3_4" test "2u3.4","2u4.21"silicon node "2U4_2" test "2u1.20","2u4.2"silicon node "2U4_3" test "2u3.21","2u4.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. This fragment of PCF code assumes the MUX/Linker IC is already in the Run-Test/Idle TAP state. The PCF fragment loads the Mux/Linker Instruction Register with the SCANSEL instruction which targets the SELECTR register. This 8-bit register is loaded with two-bit fields that connect the desired Secondary Scan Paths (SSP1 in this case). PCF vectors

are then issued to update the SELECTR register and the MUX/Linker TAP is brought back to the Run-Test/Idle state.

This fragment was prepared by using the Scan Port Driver (SPD) program with a BSDL description of the MUX/Linker IC, and developing a PCF test program that loads SELECTR with the appropriate control bits as specified by the data sheet. Then, just the portion (fragment) between the two Run-Test/Idle states is



retained, discarding the rest. This saves the effort of programming the MUX/Linker manually. Note that when the MUX/Linker has been reset, it does not connect any SSP, and each SSP has its individual TMS held high so that they are constantly being forced to Test-Logic-Reset while the MUX/Linker is programmed. Just as the MUX/Linker is finishing being programmed, the SSPs are allowed to move to the Run-Test/Idle state at the same time the MUX/Linker is moving to Run-Test/Idle. This is how the ICs of the newly linked chain(s) and the linker all end up synchronized together in Run-Test/Idle.

The completed PCF fragment should be given a meaningful name, stored in the digital directory, and referenced by the ITL insert statement as shown in the ITL above.



Example 5-8

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



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



"101X1""000X1"!2"100X1""000X1"!3"100X1""000X1"!4"100X1""000X1"!5"100X1""000X1"!6"100X1""010X1"!7"110X1"!Exit1-DR"01ZX1""11ZX1"!Update-DRend pcfmessage ""pcfuse pcf order Scan"00ZX1""10ZX1"!Run-Test/Idle! End of insert

---------------------------

Example 5-9 is a portion of the VCL source file created by compiling the above ITL with the PCF fragment included.

The vectors start out by sending the MUX/Linker to Test-Logic-Reset. When in this state, the SSPs are also held in Test-Logic-Reset. After the disable vectors are applied and another Test-Logic-Reset sequence (handy in the case where the disable has affected the MUX/Linker or a Secondary Scan Path), you will see

the inclusion of the PCF fragment that programs the MUX/Linker at vector 28. After this, the test continues from the Run-Test/Idle state, now with all the chain devices being connected and synchronized. The rest of the test proceeds as usual and has been deleted for brevity. One exception to this is the addition of Pad Bit shift states (for example, see around vector 175). This accounts for the position of a pad bit inserted in the



chain by the MUX/Linker. The test is appropriately phased to account for the positions of all pad bits.



Example 5-9

---------------------------

< source deleted >

! Device Entity Package BSDL File! --------- ----------- ----------- -----------------! Pad Bit! 2U1 TTL74BCT8374 DW_PACKAGE custom/74bct8374! 2U2 TTL74BCT8374 DW_PACKAGE custom/74bct8374! 2U3 TTL74BCT8374 DW_PACKAGE custom/74bct8374! 2U4 TTL74BCT8374 DW_PACKAGE custom/74bct8374! 2U8 SN74ACT8997T DW custom/74act8997

scan interconnect ! for MUX_2U1_2U8

< source deleted >

pcf order default Scan is TCK, TMS, TDI, TDO, TRSTpcf order Disable is D000, D001

!Column-to-Node Map, Nodes 1 to 5!22222!!MMMMM!!TTTTT!!CMDDR!!KSIOS!! T!! !!!unit "Interconnect Test" ! Vector 1pcfuse pcf order Scan



"01ZX0"!Reset via TRST* and synchronizing sequence"11ZX0""01ZX1""11ZX1""01ZX1""11ZX1""01ZX1""11ZX1""01ZX1""11ZX1""01ZX1""11ZX1"!Test-Logic-Reset!! Disable Vectors!use pcf order Disable"11"!! End of Disable Vectors!use pcf order Scan"01ZX0"!Reset a second time via TRST* and synchronizing sequence"11ZX0"!to assure that any now-enabled BScan devices also reset."01ZX1""11ZX1""01ZX1""11ZX1""01ZX1""11ZX1""01ZX1""11ZX1""01ZX1""11ZX1"!Test-Logic-Reset Vector 25"00ZX1""10ZX1"!Run-Test/Idle!



! Including PCF from file digital/2u8_setup.!! Begin insertion"01ZX1""11ZX1"!Select-DR-Scan"01ZX1""11ZX1"!Select-IR-Scan"00ZX1""10ZX1"!Capture-IR"00ZX1""10ZX1"!Shift-IRend pcfmessage "IEEE Std 1149.1-1990 Integrity Failure"message " Device 2U8 has failed,"message " suspect device or these pins:"message " (tck) 15"message " (tms) 14"message " (tdi) 16"message " (tdo) 13"message " (trst) 26"pcfuse pcf order Scan"000H1"!0+0"100X1""001L1"!1"101X1"! Loading device 2U8 with instruction SCANSEL(01111110)."000L1"!2+0"100X1""001X1"!1"101X1""001L1"!2"101X1""001L1"!3"101X1""001L1"!4



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



"100X1""000X1"!3"100X1""000X1"!4"100X1""000X1"!5"100X1""000X1"!6"100X1""010X1"!7"110X1"!Exit1-DR"01ZX1""11ZX1"!Update-DRend pcfmessage ""pcfuse pcf order Scan"00ZX1""10ZX1"!Run-Test/Idle! End of insert!! End of PCF from file digital/2u8_setup,! 56 vectors inserted.!"01ZX1""11ZX1"!Select-DR-Scan"01ZX1""11ZX1"!Select-IR-Scan"00ZX1""10ZX1"!Capture-IR"00ZX1""10ZX1"!Shift-IRend pcfmessage "IEEE Std 1149.1-1990 Integrity Failure"message " Device 2U8 has failed,"message " suspect device or these pins:"



message " (tck) 15"message " (tms) 14"message " (tdi) 16"message " (tdo) 13"message " (trst) 26"pcfuse pcf order Scan"000H1"!0+0"100X1""001L1"!1"101X1"! Loading device 2U8 with instruction BYPASS(11111111)."001L1"!2+0"101X1""001X1"!1"101X1""001L1"!2 Vector 100"101X1""001L1"!3"101X1""001L1"!4"101X1""001X1"!5"101X1"end pcfmessage "IEEE Std 1149.1-1990 Integrity Failure"message " Device 2U4 has failed,"message " suspect device or these pins:"message " (tck) 13"message " (tms) 12"message " (tdi) 14"message " (tdo) 11"pcfuse pcf order Scan"001H1"!6"101X1"



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



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



message " suspect device or these pins:"message " (tck) 13"message " (tms) 12"message " (tdi) 14"message " (tdo) 11"pcfuse 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-IRend pcfmessage ""pcf



use pcf order Scan"01ZX1""11ZX1"!Select-DR-Scan"00ZX1"

< remainder deleted >---------------------------

Best Practices for Developing Boundary-Scan TestsTo ensure successful implementation of your boundary-scan tests, you should examine the following sections to verify that you have considered all possible areas that could cause testing problems.

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

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

Removing Physical ProbesUse the conservative approach to removing physical probes. Make sure that all issues have been considered before removing probes. Some issues that can influence the need to remove probes include:

■ If many nodes are duplicated in connect/interconnect tests, and grounding issues become a problem, some of these probes can be eliminated so the connect test requires fewer testhead resources.

■ If you have nodes that have only boundary-scan devices connected to them (100% boundary-scan



nodes), you could remove these probes to free up resources for other needs.

■ If you have nodes that have simple, non-boundary-scan devices connected to them, and you are willing to write a Silicon Nails test for these devices, you could remove these probes.

■ If a node adjacent to a 100% boundary-scan node is sensitive (for example, a boundary-scan node connected to a sensitive analog device), you should ensure that particular boundary-scan node has a probe assigned to it to detect shorts during standard, unpowered shorts testing.

Figure 5-42 Removing probes requires careful consideration

Figure 5-42 illustrates several situations that must be considered before you remove physical probes. These

situations are based primarily on the type of node that you are considering for removal. The following list

Dig i ta l

U3_2

U3_3

Clean NodeAnalog Node

Partial Node

VCC



outlines the different types of nodes and their characteristics.

■ Full boundary-scan node: Has a least one boundary-scan driver and at least one boundary-scan receiver. Note that bidirectional, or output pins with monitoring capability qualify a node as a full boundary-scan node. Four types of full boundary-scan nodes that can occur on a given board are listed below:

� Clean node: Node with only boundary-scan inputs and outputs are good candidates for probe removal.

� Digital node: Node with at least one conventional digital device (but no analog devices) are also good candidates for probe removal if the digital device is not a complicated device. Simpler digital devices can still be tested using the Silicon Nails technique.

� Analog node: Node with at least one analog device (but no conventional digital devices) can have probes removed, but you would be trading off in-circuit test coverage. Probes are recommended for these nodes.

� Mixed node: Node with at least one each analog and conventional digital devices are subject to the same conditions that apply to digital and analog nodes. Removing probes

from these nodes could result in reduced fault coverage.

■ Partial boundary-scan node: Has one or more boundary-scan drivers or one or more boundary-scan receivers, but not both. Test probes are recommended for all partial boundary-scan nodes.

NOTEYou should not remove probes from disable control nodes. This action could restrict IPG's ability to provide proper disable methods for a test.

Adding Power Cycling or Reset Sequence Where NeededYou might need to add a power cycling or reset sequence procedure to your testplan to ensure that your device chains are in the proper state for testing.

When going into boundary-scan testing, the core logic of the devices in the chain are disconnected from the rest of the board, which probably will affect other devices operating in normal mode. Other devices exchanging data with boundary-scan devices will consider the boundary-scan devices inoperable.

Realize that when the board comes out of boundary-scan mode, all the boundary-scan devices go into BYPASS, and the core logic is reconnected to the



I/O pins, but the board and the boundary-scan devices do not necessarily pick up where they left off.

To get the board back to normal operating mode, the board reset procedure must be run, or board power must be cycled. You can do this by adding a reset sequence or power cycling procedure to your testplan.

If you have multiple chains, be aware that interactions between chains can be a problem. You might need to cycle power between tests to clear the problems.

If you have problems with connect tests and/or disabling difficulties, you should try adding a power cycling or reset sequence to your test.

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

NOTEFor automatically generated boundary-scan tests, the software writes the power cycling procedure for you. Reset sequence procedures (particular to each board) and procedures for manually generated tests must be added to the testplan manually.

Five categories of nodes are reported:

■ Category 1: Nodes that have probes assigned but the probes can be removed;

■ Category 2: Nodes that have probes assigned and the probes should not be removed;

■ Category 3: Nodes that do not have probes assigned and probes are not needed;

■ Category 4: Nodes that do not have probes assigned but probes are needed;

■ Category 5: Nodes that do not have probes assigned but probes are needed for powered shorts testing.

If you modify the board_xy file with the changes reported in the testability report and rerun IPG, a new testability report is generated. You will notice a shift in how the nodes are categorized. That is, nodes that previously belonged to Category 1, now belong to Category 3, and nodes that previously belonged to



Category 2, now belong to Category 4. You must be careful about nodes that shift from Category 2 to Category 4. These nodes are no longer tested by connect testing and require user-written tests for fault coverage.

For each node category in the report there is an explanation of why the nodes were included in that category. See the example report that follows.

Viewing the Testability ReportThe testability report for boundary-scan nodes is contained in the ipg/raw file, which must be formatted before you can read it. You can execute the format program with the fmt statement in a BT-BASIC window to format the information in the ipg/raw file.

For example, to output the formatted information to the screen for an interconnect test name u1_u4, you would enter:execute "fmt -t u1_u4_tr ipg/raw"; wait

Note that you must append the string _tr to the name of the interconnect test to acquire the testability report for that test. The information for the test u1_u4 is tagged in the ipg/raw file as u1_u4_tr.You can also direct the output to a file and then load or print that file to view the information. To output the testability report for u1_u4 in a file named u1_u4_details, you would enter (on one line):

execute "fmt -t u1_u4_tr ipg/rawu1_u4_details" |load "u1_u4_details"

To format the information about all tests in the ipg/raw file and place the information in a file, execute the following statement:

execute "fmt ipg/raw <file name>"

An Example Testability ReportThis section contains an example of a formatted testability report for an interconnect test named u1_u4.



Example 5-10 Formatted testability report

"u1_u4_tr"BOUNDARY-SCAN NODE TESTABILITY REPORT.

|Comment key: "BSdvr" is the number of BScan drivers on a node, || "BSrcv" is the number of BScan receivers, || "dig" is the number of conventional digital pins, || "nondig" is the number of analog (etc.) pins. |

Category 1 Nodes (Have probes, and probes could be removed)These nodes have the resources for Boundary-Scan Interconnecttesting and no other device pins exist that would require probes.Be aware though that user-written tests might require probes on someof these nodes or, some of these probes might be needed for unusualdisabling situations. The listing below lists the nodes in aformat that can easily be transferred into the board_xy file.NODE U1_U3_10 NO_PROBE; ! BSdvr:2 BSrcv:2 dig:0 nondig:0

Category 2 Nodes (Have probes, and probes should be kept)These nodes might not have the resources for Boundary-Scan Interconnecttesting or, other device pins exist on them that might require probesto support their test. Removing probes from these nodes might reduce faultcoverage or cause the need for additional user-written tests. Thelisting below lists the nodes in a format (commented) that can easilybe transferred into the board_xy file. Remove the comment (~!) toremove the probe.!NODE IN_05 NO_PROBE; ! BSdvr:0 BSrcv:2 dig:0 nondig:1!NODE IN_17 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:1!NODE OUT_09 NO_PROBE; ! BSdvr:1 BSrcv:0 dig:0 nondig:0!NODE OUT_10 NO_PROBE; ! BSdvr:1 BSrcv:0 dig:0 nondig:0!NODE IN_16 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:1!NODE IN_24 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:0!NODE IN_23 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:0!NODE IN_22 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:0!NODE IN_21 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:0!NODE IN_20 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:0!NODE IN_19 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:0



!NODE U3_3 NO_PROBE; ! BSdvr:1 BSrcv:1 dig:1 nondig:0!NODE U3_2 NO_PROBE; ! BSdvr:1 BSrcv:1 dig:1 nondig:0!NODE IN_18 NO_PROBE; ! BSdvr:0 BSrcv:2 dig:0 nondig:1!NODE IN_04 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:1!NODE OUT_04 NO_PROBE; ! BSdvr:1 BSrcv:0 dig:0 nondig:0!NODE OUT_05 NO_PROBE; ! BSdvr:1 BSrcv:0 dig:0 nondig:0!NODE OUT_06 NO_PROBE; ! BSdvr:1 BSrcv:0 dig:0 nondig:0!NODE IN_03 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:1!NODE IN_12 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:0!NODE IN_11 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:0!NODE IN_10 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:0!NODE IN_09 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:0!NODE IN_08 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:0!NODE IN_07 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:0!NODE IN_06 NO_PROBE; ! BSdvr:0 BSrcv:1 dig:0 nondig:0

Category 3 Nodes (Have no probes, and probes are not needed)These nodes have the resources for Boundary-Scan Interconnecttesting and no other device pins exist that would require probes.They have already had probes removed.NODE U3_4 ! BSdvr:1 BSrcv:1 dig:0 nondig:0NODE U1_U3_9 ! BSdvr:2 BSrcv:2 dig:0 nondig:0NODE U1_U3_8 ! BSdvr:2 BSrcv:2 dig:0 nondig:0NODE U1_U3_7 ! BSdvr:2 BSrcv:2 dig:0 nondig:0NODE U1_5 ! BSdvr:1 BSrcv:2 dig:0 nondig:0NODE U1_4 ! BSdvr:1 BSrcv:1 dig:0 nondig:0NODE U1_3 ! BSdvr:1 BSrcv:1 dig:0 nondig:0NODE U1_2 ! BSdvr:1 BSrcv:1 dig:0 nondig:0

Category 4 Nodes (Have no probes, and probes should be added)These nodes might not have the resources for Boundary-Scan Interconnecttesting, or, other device pins exist on them that might require probesto support their test. Adding probes will allow them to be tested.Not adding probes will reduce fault coverage or cause the need foradditional user-written tests.NODE U4_10 ! BSdvr:1 BSrcv:0 dig:1 nondig:0NODE U4_9 ! BSdvr:1 BSrcv:0 dig:1 nondig:0NODE U4_8 ! BSdvr:1 BSrcv:0 dig:1 nondig:0



NODE U4_7 ! BSdvr:1 BSrcv:0 dig:1 nondig:0NODE U4_5 ! BSdvr:1 BSrcv:0 dig:1 nondig:0NODE U4_4 ! BSdvr:1 BSrcv:0 dig:1 nondig:0NODE U7_6 ! BSdvr:0 BSrcv:1 dig:1 nondig:0NODE U7_5 ! BSdvr:0 BSrcv:1 dig:1 nondig:0NODE U2_10 ! BSdvr:1 BSrcv:0 dig:1 nondig:0NODE U2_9 ! BSdvr:1 BSrcv:0 dig:1 nondig:0NODE U2_8 ! BSdvr:1 BSrcv:0 dig:1 nondig:0NODE U2_7 ! BSdvr:1 BSrcv:0 dig:1 nondig:0NODE U2_5 ! BSdvr:1 BSrcv:0 dig:1 nondig:0NODE 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 thatcannot be tested by the Powered Shorts algorithm for lack ofaccessibility. These nodes are typically ordinary digital/analognodes, though some nodes here might also appear in category 4. Addingprobes will allow Powered Shorts testing. If probes are not added, thencoverage will be reduced or these shorts must be tested with some otheruser-written test.NODE U3_TDONODE U1_TDO



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.

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.

AliasingAliasing 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).

NOTEFor 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.



If nodes D and E were also shorted, the resulting IDs captured on these nodes (00010) would also indicate a short to node A (00010). This is known as confounding because we cannot tell if these IDs reflect one or two shorts.

InterconnectPlus alleviates the aliasing and confounding problems by using the enhanced counting sequence (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

ID (00010000). This provides increased resolution for the software to distinguish one node from another.

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

Results Analysis: Failure CausesThere are four failure causes possible from the diagnosis of the cell data:

■ Short to a fixed node■ Short to a boundary-scan node■ Open circuit■ Unknown Failure

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

Table 5-9 Adding Complementary Data Bits Alleviates Aliasing

A 0 0 0 1 0 1 0 1

B 0 0 1 1 0 1 0 0

C 0 1 0 1 0 1 0 1

D 1 0 0 1 1 0 0 1

E 0 1 1 1 0 1 0 0



These causes are deduced from the failure analysis of the cell information discussed in the next section. Understand that these causes might be due to a variety of physical symptoms in the circuit itself. These symptoms are discussed below.

■ Short to a fixed node: This is diagnosed whenever the symptoms are consistent with a short to a node that is capable of holding the node under test to a fixed value. This will be diagnosed if all data captured on a node is fixed and unchanging. The physical causes for this could be:

� Damaged output driver on the device: ESD or other damage can cause the driver not to change state under control of the Boundary Register.

� In the case where no cells are associated with the active driver (the output is two-state or three-state only), an open circuit on the driver will also alias to this problem. In this situation, the bus test will identify the problem more accurately than the interconnect test.

■ Short to a boundary-scan node: This is diagnosed whenever two or more nodes are detected as having the same ID and that ID is not all zeroes or all ones. The physical causes for this could be:

� A short to one or more nodes that are also solely under the control of the Boundary Register.

� A short to a non-boundary-scan node that produces an ID that matches the ID of some other boundary-scan node.

� A short to a fixed node with a weak enough drive capability that it cannot hold the node under test to a fixed level.

NOTEThis message tells you that the detected failure did not fit into one of the other defined categories. Diagnosis is provided to the node level only.

■ Open Circuit: This is diagnosed whenever the driver is passing and one or more the receivers connected to the node have a stuck-at fault.

NOTEThis will be diagnosed together with Short to a fixed node whenever the active driver is not capable of monitoring its own output (for example, a two-state or three-state driver).

The physical causes for Open Circuit could be:



� If all receivers are stuck-at, then it is probable that the active driver is not connected to the node.

� If some of the receivers on the node receive good data, then it is probable that the failing receivers are not connected to the node.

■ Unknown Failure: This is diagnosed whenever the symptoms for a node are inconsistent with those of a short circuit, an open circuit, or a combination of both. The physical causes for this could be:

� A short circuit to a node has occurred, but the variations in the receiver thresholds on the node under investigation are such that the receivers observe different characteristics from the active drivers.

� A short circuit to a fixed node has occurred, but the drive capacity of the fixed node is too weak to hold the node to a fixed level, but it is strong enough to cause device receivers to see different data because of the variations in their receive thresholds.

� A combination of shorts and opens exist on the node such that the variations in the receive patterns is seen.

� A mis-wiring has occurred on the node and at least one of the receivers is physically connected to the wrong node (not likely where

packaged devices are used, but possible in the case of Chip On Board or Multichip Module technology using wirebond techniques).

Results Analysis: MessagesWhen a boundary-scan test fails, a message that describes the failure is sent to the report device. This message includes a list that provides the device and pin(s), or the node(s) that failed. The following is one example of such a message. Other examples are provided at the end of this section, after the descriptions of the messages that you could see during testing.

-----------------------------------Thu Jan 09 17:54:33 1992-----------------------------------INTERCONNECT FAILURE DETECTEDFOR TEST digital/u1_u4A short has been detectedbetween the following nodes:U1_2 -- pins:

u1.2 u2.23U1_3 -- pins:

u1.3 u2.22-----------------------------------

■ Node <nodename> is stuck; probably shorted to fixed node � The identified node is not toggling. The cause is probably a short to either power or ground, but it is also possible that an open can cause this diagnosis. Use the pin list associated with this message to check the most probable locations for the problem.



■ A short has been detected between the following nodes � The node/pin list identifies all nodes and pins associated with the failure. Note that, with the use of the deterministic algorithm, if three or more nodes are listed, it is possible (though unlikely) that one of the listed nodes is not actually shorted (aliasing).

■ Node <nodename> is failing; Probably a short, but the shorted node cannot be located. Pins involved are: � All of the inputs on a particular node observe it toggling in the same manner, but that manner is not correct. This is most probably caused by a short to another node that is not connected to a boundary-scan device. Check the pin list to identify the most likely places for the failure.

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

■ Pin is stuck; check for open on <device>.<pin> connected to node <nodename> � The RA

routine has found that some of the pins on the node are correctly toggling, but that the identified pin is stuck. The cause is probably an open on this pin alone.

■ Node <nodename> is stuck; probable open on <device>.<pin> or <device>.<pin> � The failing node is stuck, and that node has only one driver and one receiver connected to it. In this case, no additional data is available from other receivers on the node, so the problem cannot be diagnosed beyond the two pins listed. A short to VCC or ground could also be the cause.

■ The following pins are detected open: � During a buswire test, all pins (that will always be output or bidirectional pins) have been detected open by the test.

■ Opens on Output or Bidir Pins � During a connect test, all device outputs or bidirectional pins that have failed are listed. Another diagnosis will list all inputs and bidirectional pins that fail. Because bidirectional pins are verified in both directions, an actual open should cause that pin to be listed both here and in the Opens on Input or Bidir Pins diagnosis. If this does not occur, the most probable cause of the problem is fixturing, or a failure in the I/O section of the device being tested.

■ Opens on Input or Bidir Pins � Like its companion message, this message occurs only for



connect tests. It lists the input or bidirectional pins detected as open (see the previous message for further information).

■ Suspected open, but pin toggles: <device>.<pin> � The indicated pin on a node is toggling, but not in the same manner as all of the other pins on the same node. This indicates that the diagnosed pin is receiving data, but not from the node under test. The cause is probably a miswired fixture, or a pin bent such that it is disconnected from its proper node and is making contact with an adjacent node.

■ Over Power Detected on TDI, TMS or TCK (check for non-disabled device) � Because it is imperative that interconnect tests execute rapidly so that if a short is detected power can be removed from the board, no pin diagnosis of an over power condition on a testhead driver is performed. These failures are extremely rare, but if one does occur, the cause is probably that one of the listed nodes includes a device that is being overdriven and is not disabled.

■ Safeguard Timeout � Some tests (especially the interconnect test) are very long and it is possible to get a safeguard timeout if upstream devices are being overdriven. You should find a way to disable the upstream device. Specifying safeguard none to resolve this condition could work, but might risk device damage.

■ Over Power Detected On: � Connect tests do not have the same execution time constraint as interconnect tests. If this message is encountered, a driver pin list will locate the exact point of the failure. The cause is probably a high-current overdrive situation.

■ Unexplained nodal activity; (check for non-disabled device(s) � Injected noise in the circuit grounds cause the identified device to perform in a completely unexpected fashion. This can occur if a device on a boundary-scan node is not disabled and is (possibly) toggling asynchronously with the testhead drivers. The message indicates that a non-diagnosable failure has occurred.

■ Node <nodename> failed for unknown reason � The system detected a failure on this node, but its cause cannot be classified within any of the other categories. The test engineer should look for a mis-wired fixture, noise on the node, non-disabled devices and so on. We do know that the node identified is bad.

NOTEThe following messages rarely appear, but have been added to accommodate the unlikely occurrence of testhead hardware failure.



■ Test Exceeded Soft Timeout Limit � A failure caused the test to greatly exceed its expected execution time. The most likely cause is a hardware failure in the testhead.

■ Test Failed to Start � Again, the most likely cause is a failure in the testhead hardware.

■ Test Halted Due To Unknown Cause � Again, a hardware failure in the testhead.

The following are examples of device failure reports for the example circuit found at the end of this chapter. If you look closely at the schematic, you will see several switches. These switches are used to insert failures into the sample circuit. Closing or opening each switch (or a combination of switches) produces various failures. This section explains what occurs when selected switches are closed or opened by showing you what the resulting failure messages are.

SWITCH 1.1------------------------------Thu Jan 09 17:50:06 1992------------------------------CONNECT FAILURE DETECTED FORDEVICE u1_connectTest Name: digital/u1_connectOpens on Input or Bidir Pinsu1.16------------------------------

SWITCH 1.2

------------------------------Thu Jan 09 17:50:06 1992------------------------------INTERCONNECT FAILURE DETECTEDFOR TEST digital/bus_u1_u4The following pins aredetected open:u1.10------------------------------

SWITCH 1.3------------------------------Thu Jan 09 17:50:06 1992------------------------------INTERCONNECT FAILURE DETECTEDFOR TEST digital/u1_u4Node U1_5 is stuck;suspect open on u1.5However, these pins shouldalso be checked for a shortto power or ground:u1.5 u2.20 u4.20------------------------------

SWITCH 1.4------------------------------Thu Jan 09 17:50:06 1992------------------------------INTERCONNECT FAILURE DETECTEDFOR TEST DIGITAL/u1_u4Failing Vector #: 26IEEE Std 1149.1-1990Integrity FailureDevice U1 has failed,suspect device or these



pins:(tck) 13(tms) 12(tdi) 14(tdo) 11------------------------------

SWITCH 1.5------------------------------Thu Jan 09 17:50:06 1992------------------------------INTERCONNECT FAILURE DETECTEDFOR TEST digital/u1_u4Pin is stuck; check for openon u2.20connected to node U1_5.------------------------------

Note that closing or opening other switches on the sample circuit produce different failures and failure messages. If you have access to such a board and fixture, you can test the board and insert these faults to see what the resulting failures will be.



Debugging Boundary-Scan Tests

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



Figure 5-43 Boundary-Scan debug

NOTEFor more information about digital debug, refer to

Debugging Digital Tests on page 4-1.

Test Needs to be Debugged

Verified BSDL

Do We Trust1149.1

Compliance?

Perform a Chain Debug

Test

PerformVerificationof BSDL

BoardDebug

Yes

YesNo

No

Pass

Fail



■ Is the BSDL verified? If yes, do you feel that 1149.1 is complied with? If no, a choice is available:

² If you have a good idea which device is bad, perform Verification of BSDL on that device. This requires full modal access to the device. A dedicated fixture may be necessary, or the Verification test can be ported to a simulation model of the device.

² If you have no idea which device is bad, perform a Chain Debug test to isolate a bad device and when isolated perform the Verification of BSDL test.

■ If you trust that 1149.1 is complied with, perform the Board Debug test from the menu.

■ If you feel that 1149.1 has not been complied with, perform either the Chain Debug test or the Verification of BSDL test.

■ If the Chain Debug test passes, perform the Board Debug test from the menu.

Debugging BSDL and Compliance ProblemsThe Chain Debug test measures chain bit lengths two ways:

■ The test measures the length of the combined devices instruction registers and compares this

length with what the expected BSDL lengths should be.

■ The test measures the lengths of boundary registers iteratively and compares this length with what the expected lengths should be.

A Chain Debug test can be created very simply from an existing ITL file. For example, you suspect a problem with a chain of four devices called U1_U4. Load the file into the Basic editor. The first keyword in the file (for example, interconnect) identifies the type of test it will generate. Change this keyword to debug. Save the file and recompile it.

NOTEA Chain Debug test is not a production test. It is only used for debugging purposes and should be deleted when debugging is complete. Remember to restore the original test.

When the test compiles, it utilizes the fixture resources allocated to the original test. When the Chain Debug test executes, it first measures the length of the combined instruction registers of every IC in the chain.



NOTEWhen executed, a Chain Debug test DOES NOT perform a TAP integrity test. One reason for debugging chains is that you already know there is an integrity problem and you are trying to get additional debug information.

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

The second check a Chain Debug test makes after measuring the instruction registers is to iteratively measure the boundary register of each IC. The IC to be tested is placed in SAMPLE while all others in the chain are placed in BYPASS. The IC in SAMPLE has its boundary register measured. Each IC is tested successively until one is found that does not match it�s

BSDL description. In this way, a failure is specific to one device.

NOTEBoth checks of a Chain Debug test keep the chain devices out of test mode by using only BYPASS and SAMPLE instructions in the test.

Examples of a Chain Debug test failure report follows:

The following report indicates that the combined instruction register length is shorter than expected from reading the BSDL descriptions

u1_u4 HAS FAILEDvector = 232Status: 15HPass/Fail error on following pins:BRRCC NODE PIN22203 TDOInstruction Register string too short----------------------------------------

The following report indicates that the boundary register in U1 is longer than the BSDL specification states.

u1_u4 HAS FAILEDvector = 529Status: 15HPass/Fail error on following pins:BRRCC NODE PIN22203 TDOBoundary Reg. for U1 too long----------------------------------------



Debugging Executable Boundary-Scan TestsThe VCL files are permanent files created as intermediate files between the MSPD serializer and VCL. They are named as follows:

■ powered shorts test<device X>_<device Y>_ps.vcl (u1_u4_ps.vcl)

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

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

■ connect test<device X>_connect.vcl (u1_connect.vcl)

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

identifies a connect test for u4.

NOTEUppercase letters are not permitted in source-file names.

To debug boundary-scan tests, you can:

■ use Pushbutton Debug, or edit the VCL source file directly or

■ edit the ITL file

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

■ powered shorts test <device x>_<device y>_ps (for example, u1_u4_ps)

■ interconnect test<device X>_<device Y> (for example, u1_u4)

■ buswire test<device X>_<device Y>_bus (for example, u1_u4_bus)

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

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

Edit the ITL file if you:

■ have problems with specific nodes.

■ want to add or correct device disable information.

■ want to change the TAP-only setting (no to yes).

■ want to comment out a particular test or node that is causing an unsolvable problem.

Edit the VCL file if you:

■ have problems with a particular bit in the boundary-scan chain

■ want a fast, temporary solution to a problem



You should not alter the VCL file as a permanent solution except as a last resort. Because the ITL file is compiled when you run IPG Test Consultant, the VCL is re-created after each compile. If you want to make a change permanent, you must compile the VCL file using BT-BASIC, or edit the ITL file so that the desired changes are made to the VCL file after you run compile using IPG Test Consultant.

NOTEBoth VCL and ITL tests are compiled from BT-BASIC by using the compile command. However, only ITL can be compiled from IPG Test Consultant.

Under no circumstances should you alter the length of the chain. You can modify frame data as long as the modification does not alter the relative position of the bits within the frame.

VCL files can be debugged using Pushbutton Debug. However, you must compile the test with the debug option on (normally, this is not done because of time and space limitations). To do this, type:

compiledigital/<device_name>_connect.vcl;debug

in a BT-BASIC window. When the file has been compiled, the test debug object will be created.

This digital test is in pattern capture format (PCF), and it is well-commented so you can easily examine the test and determine what is happening. Additionally, the contents of the test dictionary appear at the end of the test as a comment. This information consists of the data to be applied to the inputs of the device or the data expected from the outputs of the device (input data is encoded as 1 or 0; expected output data is encoded as H or L).

Accompanying each pattern set is the identification of the pin, node, and boundary-register location associated with that data (the boundary-cell number closest to TDO is 0, and increases as you approach TDI). In the test itself, you will find frame and end frame statements. The data in between these two statements consists of the information shifted out from the active, concatenated registers of the chain during one phase of the test.

A chain location (listed in the test dictionary) corresponds to a location in a particular frame. The relationship is determined as follows: A frame consists of two vectors per cell (two clock edges are required to shift a cell's contents out TDO). In each two-vector group, a comment that identifies the cell number's position in the chain is placed to the right of the vector that contains the expected data for that cell (the second vector contains an X in this position).

The number of frames in a test equals the number of positions in the signature contained in the test



dictionary. The data from frame 1 represents the left-most position in the signature.

In most cases, the exact location of the first failing bit in a frame is unavailable, because the entire signature must be assembled before failure analysis is started. For this reason, it will often be necessary to use debug's graphic display of vectors to search, vector by vector, for the first occurrence of a bit failure.

If you cannot find the failure using the vector-by-vector search, you can comment out the offending node(s) in the test source. For an example ITL source file, refer to InterconnectPlus Test Language (ITL) on page 5-158.

Addressing Ground-Related ProblemsIf a device has a large number of outputs connected to testhead receivers, and if all or most of those outputs transition at once, the receiver current flowing into the testhead travels through a relatively small number of ground returns. If these paths are long, the inductance associated with the wiring can cause the ground references of the testhead and the device under test to be at two different potentials during that short, current-transition period. Because the testhead drivers are regulated with respect to ground, this can result in an abrupt voltage level change that can inadvertently drive device inputs. If one of the drivers is a clock input, the device can go through an unwanted state change, which causes the test to essentially run out of control and fail.

Boundary-scan connect tests are particularly susceptible to the problem because, during one part of the test, all device outputs and bidirectional pins transition together: first to 0 then to 1. The resulting current-transition problem can occur exactly as described above because connect test requires physical probes on all tested nodes. The change in TAP state, which typically would occur on transition through UPDATE-DR, would cause the test to fail. Subsequent tests would also fail because the TAP would no longer follow the established testplan.

If you encounter this situation, one of the following solutions should solve your problem.

■ Examine the fixture's ground return scheme. For each device involved in a connect test, the largest number of ground returns should be made available. These grounds should be well distributed throughout the modules used to test the device.

NOTEYou might want to consider using a XG-50 fixture for these applications. The Building Board Test Fixtures documentation provides some information about XG-50 fixtures. Contact your Sales representative for details.

■ Examine the board itself for sufficient ground paths and ground routing schemes.



■ Break the problem tests into smaller tests, each of which verifies a percentage of the total nodes. You can do this by duplicating the connect test source and removing all but the requisite number of nodes. You can name the new sources as you wish, but they must be entered into the testorder file as permanent tests so that IPG will not remove them during future test generations.



Silicon Nails Automation

The Agilent 3070 can be used to perform Silicon Nails tests on non-Boundary-Scan devices by generating an ITL file (containing all vectors needed) that can be used to test a digital device using a combination of physical nails and Silicon Nails.

A Silicon Nails test uses the Boundary Register cells instead of physical probes or nodes. The Boundary Register cells act as drivers and receivers for non-Boundary-Scan devices or small clusters of devices located between boundary-scan devices.

In some cases, a Silicon Nails test takes too long to run. To run a Silicon Nails test, the time it takes to run a traditional in-circuit test will be multiplied (worst case) by a factor of 2N, where N equals the length of the Boundary Register.

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

■ Analyze devices targeted for Silicon Nails test technique and display nodes where access is required or can be removed.

■ Utilize the current Access Consultant use model.

To understand more on using Access Consultant for Silicon Nails testing, see Chapter 2, Agilent Access Consultant.

Silicon Nails Test Development ProcessThe test development process using Agilent 3070 software allows for testing devices for which there may be access limitations. A Silicon Nails test, which tests a digital pin library device through a boundary-scan chain and 3070 resources, formerly had to be written manually.

With the inclusion of Silicon Nails Automation, this step has been automated. In cases where Silicon Nails tests are a good choice for the components being tested, the result is faster test development.

The flowchart in Figure 5-44 shows a typical use case in which Silicon Nails Automation is employed. Each step is explained in table Table 5-10 on page 5-129.



Figure 5-44 Test developer tasks with Silicon Nails Automation

Test developer tasks are described in Table 5-10.

1 2 3 4

5

ITL FileCompileboard

Add SN keywordto board file

Choosestrategy

Generate testsusing IPG

Tests

Compiletests

Silicon NailsAutomation

Table 5-10 Test development process steps and resources

Step Information Resources

1 Choose a strategy (e.g., Silicon Nails) for each device being tested.

The Silicon Nails Test Strategy section of the Boundary-Scan manual.

2 For each device being tested, enter the appropriate option (e.g., �SN� for Silicon Nails) to the board file.

Chapter 1 of the Data Formats manual, �The Board File.� See especially the Pin Library section.



Silicon Nails Test Strategy Silicon Nails refers to the use of Boundary Register cells to replace physical probes on nodes. The Boundary Register cells act as drivers and receivers, as shown in Figure 5-45. The device between the boundary-scan devices is typically a non-boundary-scan part or a small cluster. Silicon Nails will automatically generate a test for digital devices with a library, but you have the option to manually write a Silicon Nails test for other scenarios.

NOTEIf a physical nail is present, a Silicon Nails test will not allow you the option to use a silicon nail in place of the nail.

You should be fully aware of the potential problems when exercising this option (see Pros of Using Silicon Nails and Cons of Using Silicon Nails on page 5-154).

If node access is a real problem, the best candidates for node removal are nodes on which all components are boundary-scan. If conventional components co-exist on a node, a physical probe is recommended. For analog

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

4 Generate tests using IPG � this step creates ITL files. For devices being tested using Silicon Nails, part of this step runs Silicon Nails Automation, which generates the ITL files.

Chapter 1 of the Test Development Tools manual, �Test Consultant.�

5 Compile tests. The Silicon Nails Test Strategy section of the Boundary-Scan manual.

Table 5-10 Test development process steps and resources (continued)

Step Information Resources



components, analog in-circuit tests can then be performed. Testing analog components without physical access is a very difficult test situation (for further information on this, see Agilent MagicTest.) For conventional digital components Silicon Nails are an alternative, but physical probes are still recommended. If node access cannot be gained, the Silicon Nails method is feasible, and credible diagnostic resolution can be expected. However, the safety issue needs further attention.

Without physical access to all nodes, power must be turned on to find shorts. The concern is the potential for damaging device outputs. If given a choice, a physical test probe is preferred for long-term board reliability.

NOTESilicon Nails is a registered trademark of Agilent Technologies.



Figure 5-45 Boundary register cells that replace physical probes are called silicon nails

Employing Silicon Nails TestsIf you decide to employ Silicon Nails testing on a non-boundary-scan device that is connected to one or

more boundary-scan devices, you should consider a few things.

First, the device should have a relatively simple test to begin with (when it was in-circuit tested) because

ReceiversDrivers

"Silicon Nails"

DUT



converting to Silicon Nails testing multiplies the length of the test by a factor of up to 2N, where N equals the combined length of the active Boundary Registers.

The length of the active Boundary Register is determined by the total length of the active registers of the devices connected to the DUT, plus the Bypass Registers of all the devices in the chain that are not used for testing the DUT (connections between TDI and TDO as shown in Figure 5-46).

So if silicon nodes Q, R, S, and T in Figure 5-46 are connected to the DUT (u7), the length of the active Boundary Register is as follows (this is approximate): (# of DUT test vectors) x (length of u3 Boundary Register + length of u4 Boundary Register + 2) where 2 is the bypass length of u1 + u2 (or one per device).

Active Data Register = (u3 + u4 Boundary Registers) + (u1 + u2 Bypass Registers)



Figure 5-46 Silicon Nails testing on a simple device

TDO

D Flip-Flop

T

S

R

Q

TDI

J

K

L

M

Extest ModeExtest Mode

non-boundary-scan device

Bypass Mode Bypass Mode



NOTEIf from one vector to the next, only bits on nailed nodes change, serialization may be skipped, resulting in a shorter test. This scenario is represented by J, K, L and M in Figure 5-46.

If the DUT is not a relatively simple device (for example, a microprocessor), the Silicon Nails test strategy is not recommended. One reason may be that too many vectors would be needed to test the device. Another case in which Silicon Nails testing may not be optimal is when testing dynamic devices. When a dynamic device receives vectors too slowly, the device may not retain its internal memory status and tests will appear to fail.

How MSPD Coordinates Testing on Devices withSilicon-Nails and Physical ProbesOften, a device, such as u7 shown in Figure 5-46, will have both Silicon Nails and physical probes connected to it. When your Silicon Nails test is generated, mspd writes the test so that the testing of Silicon Nailed nodes (silicon nodes) is coordinated with the testing of nodes assigned physical probes (probed nodes).

Test patterns for the silicon node drivers are scanned in to the appropriate drivers and presented during

UPDATE-DR. At the same time, the vectors are changed on the probed nodes driver.

During CAPTURE-DR, the output from the DUT is captured on the silicon boundary-scan receivers. At the same time, the probed node's receiver is turned on so the software can do a compare. The probed node's data is compared directly, but the boundary-scan receivers' data must be shifted out.

The following failure messages show the actual messages received when the Silicon Nails test and the nail test are separately written tests.

Example 5-11 shows the Silicon Nails test failing a silicon node.

Figure 5-47 shows the portion of the device being tested.



Example 5-11 Silicon Nails test failing a silicon node

Example 5-12 shows a test failing at a nailed node.

u6a HAS FAILEDSILICON NAIL FAILURE DETECTED FOR TESTFailing Vector #: 498 (message follows)Silicon Nail Test failed scanned output:Vector 4 of pre-serialized test.-----------------------------------------Failed Boundary-Scan frame cell 11at u1.15,observing node: U6_3,connected to pins

u1.15 u6.3

In this example:

� u6 is the test name

� 498 is the vector number of the serialized test

� 4 is the vector number of ITL vectors

� cell 11 is the failing Boundary-Scan cell

� u1.15 is the B-Scan pin with cell 11 on pin 15

� U6_3 is the node connected to pins u1.15 and u6_3.



Example 5-12 Test failing at a nailed node

Figure 5-47 -Silicon Nails diagnostic test example Testing Devices Using Silicon NailsFigure 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.

NOTENote that ITL file generation is automated only for single devices/pin libraries, not clusters.

u6 HAS FAILEDSILICON NAIL FAILURE DETECTED FOR TESTFailing Vector #: 522 (message follows)Silicon Nail Test failed nailed output:Vector 3 of pre-serialized test.-----------------------------------------Opens on Output or Bidir PinsU6.6-----------------------------------------

In this example:

� On device U6, the nailed output pin, 6, has failed.

� 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

A

B

11

3

6

15

U6_3

U6

U1B-Scan



During normal test development, you use IPG Test Consultant to move you through the process. Syntax and an example Silicon Nails ITL source code are shown later in InterconnectPlus Test Language (ITL) on page 5-158 and VCL/ITL Pass-Thru Statements on page 5-176. The resources for your Silicon Nails test will be assigned just as they are for other tests, and the test will be added to the final testplan.

Generating Tests for Single DevicesThe 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

NOTEA setup-only vector is generated if no test vectors are found, if you only have a setup library (to generate the fixture requirements file), or if all library vectors are commented out.

The testorder file and the testplan are also automatically updated by the software. The test generation process is as follows:

If you have a setup library, add vectors to the library, then re-run IPG Test Consultant.

pcf Assignment Order

When writing test libraries for Silicon Nails, the pcf assignment order determines the column order for the ITL. The order of the pcf values generated in a Silicon Nails test is based on the order of the assign statements in the library source code used to generate the test. To preserve your original statement order, you must edit the library test syntax and assignment statements in a specific order.

NOTEThere can be more than one pcf statement in your library source code.

As shown in Example 5-13, the library source code is used to generate the Silicon Nails Test.



Example 5-13 Library source code and Silicon Nails test

! Library source

assign DIR_1 to pins 1assign OE_1_bar to pins 2assign A1_1 to pins 3assign A1_0 to pins 4assign B1_1 to pins 5assign B1_0 to pins 6

pcf order OE_1_bar,DIR_1,A1_0,A1_1,B1_0,B1_1

unit "TEST_ALL_A2B"pcf

"0001LH" ! see order above"0110HL"

end pcfend unit

! Silicon Nail Test

nodesnode "NDIR_1" test "u13.1"silicon node "NOE_1_bar" test "u13.2", "u23.U10"silicon node "NA1_0" test "u13.4", "u23.V9"silicon node "NA1_1" test "u13.3", "u23.U9"silicon node "NB1_0" test "u13.6", "u23.V8"silicon node "NB1_1" test "u13.5", "u23.U8"

inputs "NDIR_1"inputs "NOE_1_bar"bidirectionals "NA1_0"bidirectionals "NA1_1"bidirectionals "NB1_0"



bidirectionals "NB1_1"

pcf order statementspcf order is nodes "NDIR_1"pcf order is nodes "NOE_1_bar"pcf order is nodes "NA1_1"pcf order is nodes "NA1_0"pcf order is nodes "NB1_1"pcf order is nodes "NB1_0"


"0010HL" ! see order above"1001LH"

end pcfend unit

end nodes

NOTEIn Example 5-13 on page 5-139, the pcf order is the same as the order of the assign statements in the library file.

In Example 5-13 on page 5-139, the values in the pcf statement are different in the two sources.

To preserve the pcf order in a Silicon Nails test, you would do the following:

1 Edit the library source code.

2 Arrange the assign statements in the library source to match the pcf order statement.

Using the library source code, shown in Example 5-13, the re-ordered code would look like that shown in Example 5-14.



Example 5-14 Re-ordered code

! Library source

assign OE_1_bar to pins 2assign DIR_1 to pins 1

assign A1_0 to pins 4assign A1_1 to pins 3

assign B1_0 to pins 6assign B1_1 to pins 5

pcf order OE_1_bar,DIR_1,A1_0,A1_1,B1_0,B1_1



end pcfend unit

! Using this library source, the Silicon Nails Test would now be:

nodesnode "NDIR_1" test "u13.1"silicon node "NOE_1_bar" test "u13.2", "u23.U10"silicon node "NA1_0" test "u13.4", "u23.V9"silicon node "NA1_1" test "u13.3", "u23.U9"silicon node "NB1_0" test "u13.6", "u23.V8"silicon node "NB1_1" test "u13.5", "u23.U8"

inputs "NDIR_1"inputs "NOE_1_bar"bidirectionals "NA1_0"



bidirectionals "NA1_1"bidirectionals "NB1_0"bidirectionals "NB1_1"

! the pcf order is the same as the assign statements in the library file.

pcf order is nodes "NOE_1_bar"pcf order is nodes "NDIR_1"pcf order is nodes "NA1_0"pcf order is nodes "NA1_1"pcf order is nodes "NB1_0"pcf order is nodes "NB1_1"

! the pcf vectors match the pcf vectors in the library source



end pcfend unit

end nodes

NOTEIn 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 TestBefore 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

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.



NOTEIf 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.

Automated Silicon Nails now provides you with two intermediate files:

■ ITL declaration file (.itl)

■ VCL source file (.vtf)

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

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.

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, typeipg on "u5";integrate



Example 5-15 Automated Silicon Nails debug

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.

5

lb005

1VCC

2Gnd

In1

Output

3

4 In2

6OE

U1 U3

U3-5

U1-TDI

U1-TMSU1-TCK

+5V

+5V

bs001

1

7

2

5

3 4

6

VCC GND

A

TDI TDO

TMS TCK

+5V

U2

U1-TDOU2-TDO

bs005

1

7

2

5

3 4

6

VCC GND

A

TDI TDO

TMS TCK

8B

1K

U1-7

U1-8

U3-6



Example 5-16 ITL file generated by IPG �U3�

! IPG: rev 04.00u2 Wed Mar 28 16:51:12 2001

silicon nail "u3"!IPG: User may add option statements here if needed.

family "TTL"

chain "u1_u2"tdi "U1-TDI"tdo "U2-TDO"tms "U1-TMS"tck "U1-TCK"devices

"u1", "custom_lib/bs005", "DIP", no"u2", "custom_lib/bs001", "DIP", no


!IPG: User may add VCL pass-through statements here if needed.

nodessilicon node "U1-7" test "u3.3", "u1.7"silicon node "U1-8" test "u3.4", "u1.8"silicon node "U3-5" test "u3.5", "u2.7"

!IPG: NO PROBE node "U3-6" test "u3.6"inputs "U1-8"inputs "U1-7"outputs "U3-5"set terminators to on

pcf order is nodes "U1-7"



pcf order is nodes "U1-8"pcf order is nodes "U3-5"

unitpcf

"ZZX" !vector "Default"end pcf

end unit

end nodesend silicon nail

As is shown in the original file, node U3-6 is inaccessible. This means that all of the vectors are commented, leaving a default vector.

Example 5-17 on page 5-147 and Example 5-18 on page 5-148 show how the files looks after running ipgon “u3”; separate from BT-Basic.



Example 5-17 After separating files �U3.itl�

! IPG: rev 04.00u2 Wed Mar 28 16:51:44 2001


family "TTL"






!IPG: NO PROBE node "U3-6" test "u3.6"inputs "U1-8"inputs "U1-7"outputs "U3-5"

and VCL file (u3.vtf) are generated:



Example 5-18 After separating files �U3.itf�

! IPG: rev 04.00u2 Wed Mar 28 16:51:44 2001! LB005! Single input, single output, single disable, inverting! Single condition state

combinatorial

default device "u3"set terminators to onassign VCC to nodes *assign GND to nodes *

assign Ins to nodes "U1-7", "U1-8"assign Out to nodes "U3-5"

assign Enable to nodes *

power VCC, GND

family TTL

inputs Ins, Enableoutputs Out

disable Out with Enable to "1"

vector V1set Ins to "11"set Out to "1"set Enable to "0"

end vector

vector V2



set Ins to "01"set Out to "0"set Enable to "0"

end vector


end vector


end vector

unit!IPG: Pin 6 is not accessible.!*IPG* execute V1!IPG: Pin 6 is not accessible.!*IPG* execute V2!IPG: Pin 6 is not accessible.!*IPG* execute V3!IPG: Pin 6 is not accessible.!*IPG* execute V4

execute V1execute V2execute V3execute V4

end unit

! End of Test



The entries shown in red are changes to the file to allow the vectors to be generated. After the command ipg on

“U3”;integrate is run form BT-Basic, the final version of the ITL file U3 is shown (see Example 5-19).



Example 5-19

! IPG: rev 04.00u2 Wed Mar 28 16:51:44 2001


family "TTL"






!IPG: NO PROBE node "U3-6" test "u3.6"inputs "U1-8"inputs "U1-7"outputs "U3-5"set terminators to on



pcf order is nodes "U1-7"pcf order is nodes "U1-8"pcf order is nodes "U3-5"

unitpcf

"11H" !vector 1 "V1""01L" !vector 2 "V2""10L" !vector 3 "V3""11L" !vector 4 "V4"

end pcfend unit

end nodesend silicon nail

As shown in Example 5-19, all vectors have now been generated for this test.

NOTEThe test developer must generate any additional information that may be required. If additional nodes are added to the ITL and VCL file, the fixture files should be modified to ensure that any resources deceived by adding nodes are not used or will be used in the future.

NOTEThere is no source generation in the integrate phase of the process in IPG. There is no additional coverage information generated for these devices.

Writing a Silicon Nails Cluster TestClusters are tested just as they are during standard functional testing, except that one or more physical probes are eliminated. Figure 5-48 illustrates this function. For more information about cluster testing, refer to Digital Theory & Testing on page 1-1.



Figure 5-48 Testing devices within clusters

If you know that you will add Silicon Nails tests to your board test, you should run IPG Test Consultant in interactive mode. When you reach the Generate Tests Using IPG step of this process, select Do and Stop. Then, open a BT-BASIC window and write the ITL source file for your test. Remember that you must include all disabling and node information. Syntax and an example Silicon Nails ITL source code are shown later in InterconnectPlus Test Language (ITL) on page 5-158.

When you have written and compiled the test, you can manually add pertinent test information to your testplan by editing the testorder file. (Enter test scan for your Silicon Nails test. No special syntax is required.) The test file must be saved in your board's digital directory.

After you have edited the testorder file, close the BT-BASIC window and return to IPG Test Consultant. Continue with the Generate testplan step. The resources

TDO

TD1



for your Silicon Nails test will be assigned just as they are for other tests, and the test will be added to the final testplan.

Evaluating Candidate Devices for Silicon Nails TestingMaking the right decision about using Silicon Nails requires you to carefully examine the environment in which you will test candidate devices.

There is still value in using a Silicon Nails test even when all nodes are nailed. A Silicon Nails test can contain embedded disabling processes that are more robust than non-embedded Boundary-Scan disabling.

Pros of Using Silicon NailsUsing Silicon Nails will give you access to devices or clusters where probes cannot be placed due to physical restrictions. The pros of using Silicon Nails testing include:

■ Fewer test resources needed

■ Fixture is less expensive to build

■ No capacitive loading on nodes

■ Ability to perform a test that otherwise might be impossible

Cons of Using Silicon NailsEarly implementation of Silicon Nail tests have identified several potential problems with this test strategy. Some of these problems can be as minor as having to modify library tests, while others could result in failures in the field. This section describes some of these problems in detail.

First, for a 7400 component (four NAND gates), the two input pins of the same gate are shorted together, as illustrated in



Figure 5-49 .Shorted inputs to a NAND gate could go undetected.

A test would PASS in spite of the defect. Using Table 5-11, you can examine the reason for this.

A 2-input NAND gate has four possible combinations. When both inputs are high (11) or both inputs are low (00), the short does not create a conflict. When the two inputs are driven to opposite states (01 and 10) the output is expected to be high. To create a failure on the output, both inputs must go over logic level 1. If that is not the case, the NAND gate will show a correct response.

The problem with this case is that it is also likely to pass a system test and be shipped to the customer. However, the two outputs are fighting each other when they are in

Table 5-11 Truth Table for a 2-input NAND Gate

Pin 1 Pin 2 Pin 3

0 0 H

0 1 H

1 0 H

1 1 L



opposite states. This could result in a failure where it is most expensive to repair: in the field.

A limitation of Silicon Nails testing is the low, real vector application rate to the DUT. For example, running TDI with a rate of 5 MHz through a chain of over 1,000 cells results in less than a 5 kHz real vector application rate. This can be a problem if you are testing dynamic components.

Another concern with this approach is that a conventional component might have one input accessed through a physical probe requiring that an upstream device be backdriven. Because of the long test times, a backdrive problem could occur.

A summary of the issues to consider include:

■ manual adjustment of the in-circuit library

■ fault detection limitations

■ limitations because of dynamic parts

■ potential backdrive problems

■ vector explosion (parallel test length multiplied by Boundary Register length).

In addition, a Silicon Nails test may not work correctly when it is dependent upon 3070 resources that do not exist when Silicon resources are substituted. An illustration of this would be a test that is dependent on 3070 receiver loads (controlled by set load statements) in order to work.

For example, to test the output enable signal of a simple buffer IC:

1 First, enable the outputs and pass 0s and 1s through the buffer.

2 Then, set the data to (for example) all 0s and set the receiver loads to pull the outputs up to 1s.

� This vector should show 0s on the output.

� The next vector disables the output and expects to see the output go high. This is due to the drivers being tri-stated and the pull-ups creating the 1s.

If the outputs are tested with Silicon Nail receivers, this last vector will probably fail because the pull-up function is missing.

Ensuring a Successful ImplementationCarefully consider the issues discussed above before you apply the Silicon Nails test strategy. Use physical probes on conventional components where possible. If you do use Silicon Nails strategy, you should ask yourself these questions about your board:

■ 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?



■ 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?

These elements will cause an IPG error. IPG will continue to run, but a functional Silicon Nails test will be not generated.

If you answer yes to any of these questions, you should probably not use Silicon Nails testing on the affected nodes.

Serialization, test length, and probe placementSerialization of vectors is a necessary part of Silicon Nails testing, although it increases test length. However, strategic placement of one or more physical probes (when possible) on a �busy� node can sometimes reduce serialization and test length. Consider the following example:

Figure 5-50 Placing probes on busy pins

In this example, serialization is not necessary between the first and second nodes, because there is no change of state from Vector 1 to Vector 2. Placement of a physical nail (when possible) at this �busy� node could eliminate serialization of the second vector and decrease test length.

Vector 1:1

0

1

1

0

0

Vector 2:

Pin State

(Silicon Node)

(Silicon Node)

(Nailed Node)

(Silicon Node)

(Silicon Node)

(Nailed Node)



InterconnectPlus Test Language (ITL)

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

NOTEIn the past, Silicon Nails tests had to be written manually using ITL, then incorporated manually into your testplan. An optional product automates this ITL generation from library tests. For more information, refer to Silicon Nails Test Strategy on page 5-130.

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.

ITL Statement Descriptions and SyntaxThis section contains all the statements used by ITL. The statements are dealt with in alphabetical order; however, you should note that ITL has a mandatory structure, which is described (and shown by example) below. Each description contains the statement's syntax, descriptions of key parameters, and examples of how to use the statement.

NOTENote that only new ITL statements are presented here in detail. Statements that have been borrowed from VCL are presented in the Syntax Reference documentation. Both types are listed below.

New ITL StatementsA list of statements created specifically for ITL is shown below. The descriptions for these statements can be found on the following pages. The statements include:

Example 5-20

tdi trst devices end devices fixed checkerboard test inputs onlytdo node disables end disables silicon node custom ground bounce suppressiontms test nodes end nodes silicon nail disable debugtck chain end chain connect buswire interconnect powered shorts



ITL Statements Borrowed from VCLA list of statements borrowed from VCL for use in ITL is shown below. These statements behave similarly to VCL. The descriptions for these statements can be found in the Syntax Reference documentation. The statements include:

unit end unit pcf end pcfinputs outputs bidirectionalrepeat end repeat pcf order is nodes

buswire (ITL)The buswire statement declares the test type to be a buswire test. This extends interconnect testing to examine each bussed driver to ensure connectivity and operation.

chain (ITL)The chain statement marks the start of a chain block. The parameter following the chain statement tells you which boundary-scan chain on the board (or which target device for connect test) will be tested. The chain block contains the description of the boundary-scan control signals, and provides the path names for the software to retrieve the BSDL files for each device in the chain.

For more detail on this syntax statement see chain (ITL) of the Syntax Reference documentation.

checkerboard (ITL)The checkerboard statement alters the connect test pattern set to be an alternating pattern to reduce ground bounce and perhaps catch certain other faults

connect (ITL)The connect statement declares the test type to be a connect test. This uses tester nails to test to a single device in the scan chain.

custom (ITL)The custom statement declares the test type to be a custom test. This is a type of interconnect test custom designed by the user. This test uses the MSPD interface to create the test patterns.

debug (ITL)The debug statement declares the test type to be one to debug the boundary scan chain. Normally, this is just used in test development and not in production.



devices (ITL)The devices statement marks the beginning of a devices block. The information in this block provides the software with the descriptions of the devices in the chain, and the path names to their BSDL files.

For more detail on this syntax statement see devices (ITL) of the Syntax Reference documentation.

disable (ITL)The disable statement declares the test type to be one to disable the boundary scan devices in the targeted chain. This is normally done to allow testing of other digital devices without bus conflicts.

disables (ITL)The disables statement (optional) marks the start of an optional disables block. You can enter disable information if you know about disable needs for your test. (This information might not be needed to develop your device test.) You do not need to specify disable information for devices that can use boundary-scan disabling.

For more detail on this syntax statement see disables (ITL) of the Syntax Reference documentation

end chain (ITL)The end chain statement marks the end of a chain block. Refer to the chains statement for more information.

For more detail on this syntax statement see end chain (ITL) of the Syntax Reference documentation.

end devices (ITL)The end devices statement marks the end of a devices block. Refer to the devices statement for more information.

For more detail on this syntax statement see end devices (ITL) of the Syntax Reference documentation.

end disables (ITL)The end disables statement marks the end of a disables block. Refer to the disables statement for more information.

For more detail on this syntax statement see end disables (ITL) of the Syntax Reference documentation.



end nodes (ITL)The end nodes statement marks the end of a nodes block. Refer to the nodes statement for more information.

For more detail on this syntax statement see end nodes (ITL) of the Syntax Reference documentation.

end <test type> (ITL)The end <test type> statement marks the end of a test block. The <test type> can be powered shorts, interconnect, buswire, connect, or custom. The <test type> specified must match that specified to begin the block. Refer to ITL Syntax Structure on page 5-165 for sample ITL files.

For more detail on this syntax statement see end <test type> (ITL) of the Syntax Reference documentation.

fixed (ITL)The fixed statement is used within a nodes block to declare fixed nodes. The fixed statement includes the state of the node (high or low); if the state cannot be determined, the statement is commented and the state is specified as unknown. You need to edit the file to change

the state to either high or low and uncomment the statement.

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

ground bounce suppression (ITL)The ground bounce suppression statement can be used to change the test flow at either of the UPDATE states to reduce the potential for ground bounce to cause failures. The statement is optional.

interconnect (ITL)The interconnect statement declares the test type to be an interconnection test of the devices in the chain. This test only uses the TAP nodes, and disables, and ignores nailed access to the interconnect nodes under test.

node (ITL)The node statement is used within a nodes or disables block to identify the node to be tested or disabled. The node statement can be followed by a card list that tells the system which type of resource to use to perform the test or disable task.



For more detail on this syntax statement see node (ITL) of the Syntax Reference documentation.

nodes (ITL)The nodes statement marks the beginning of a nodes block. This block can be empty, but it must be present in every ITL source file (even if it is empty) to satisfy the syntactic requirements of the parser.

For powered shorts tests, this block identifies the adjacency of the 100-percent boundary-scan node (silicon node) to the nailed nodes of any other type. You should notice in the ITL file for a powered shorts test that a silicon node entry is followed by one or more node entries.

For more detail on this syntax statement see nodes (ITL) of the Syntax Reference documentation.

pcf order is nodes (ITL)The pcf order is nodes statement identifies the order in which a group of nodes will be tested. This statement can appear within a nodes block or a disables block.

For more detail on this syntax statement see performance port of the Syntax Reference documentation.

powered shorts (ITL)The powered shorts statement declares the test type to be a test for shorts between un-nailed boundary scan interconnect nodes and adjacent nailed nodes.

silicon nail (ITL)The silicon nail statement declares the test type to be a test of one or more non-scan devices. The test can use a mixture of boundary scan resources (silicon nails) or tester resources (regular nails). With early software, this test�s ITL file had to be manually created; newer, optional software can automatically create this file from a library test.

silicon node (ITL)The silicon node statement is used within a nodes block to identify a boundary-scan node to be tested via boundary-scan resources. This statement typically appears in interconnect, buswire, powered shorts, or custom test blocks.

For more detail on this syntax statement see silicon node (ITL) of the Syntax Reference documentation.



tck (ITL)The tck statement identifies the test clock node of the boundary-scan chain. A name is assigned to this node using the tck statement.

For more detail on this syntax statement see tck (ITL) of the Syntax Reference documentation.

tdi (ITL)The tdi statement identifies the test data in node of the boundary-scan chain. A name is assigned to this node using the tdi statement.

For more detail on this syntax statement see tdi (ITL) of the Syntax Reference documentation.

tdo (ITL)The tdo statement identifies the test data out node of the boundary-scan chain. A name is assigned to this node using the tdo statement.

For more detail on this syntax statement see tdo (ITL) of the Syntax Reference documentation.

test (ITL)The test statement is used within a nodes block in conjunction with the node statement. The test statement identifies the node connections that will be tested.

For more detail on this syntax statement see test (ITL) of the Syntax Reference documentation.

test inputs only (ITL)The test inputs only statement is for optional usage in connect tests. It skips the test frames that check outputs. It is intended for PLDs that have all pins defined as bidirectional in BSDL, while the programmed function may be as an input only. This creates unsolvable disable problems to IPG. The command makes the system simply test the bidirectional in the input direction only and eliminates any bus conflict problems. This is not suitable for a test containing output pins.

tms (ITL)The tms statement identifies the test mode select node of the boundary-scan chain. A name is assigned to this node using the tms statement.

For more detail on this syntax statement see tms (ITL) of the Syntax Reference documentation.



trst (ITL)The trst statement identifies the test reset node of the boundary-scan chain (if one exists). A name is assigned to this node using the trst statement.

For more detail on this syntax statement see trst (ITL) of the Syntax Reference documentation.



ITL Syntax Structure This section describes the structure for the InterconnectPlus Test Language (ITL). Examples follow the general syntax structure shown below. Parameters are shown in brackets < >.



Example 5-21

<test type> <chain/device description>! marks the start of a test block<test type> can be:powered shorts

interconnectbuswireconnectsilicon nailcustom

<chain/device description> is a <string expression>chain <chain description> ! marks the start of a chain block

tdi <signal description> <card list>tdo <signal description> <card list>tms <signal description> <card list>tck <signal description> <card list>trst <signal description> <card list>

<signal description> is a <string expression><card list> can be:channel! "," indicates equal card preference

hybrid ! ";" indicates first choice preferredchannel, hybrid! over second, but second may behybrid; channel! used.

devices<device description>,<BSDL pathname>,<package name>, <compliance problem><device description>,<BSDL pathname>,<package name>, <compliance problem><device description>,<BSDL pathname>,<package name>, <compliance problem>

. . .<device description> is a <string expression><BSDL pathname> is a <string expression><package name> is a <string expression><compliance problem> can be: yes or no

end devicesend chain ! marks the end of a chain blockdisables ! marks the start of a disables block

node <node name> <card list>default <state><node name> is a <string expression><state> can be: 0, 1, k, t

pcf order is nodes <node name>, <node name>,...<node name>unit <unit name> ! marks the start of a unit block

<unit name> is a <string expression>pcf ! marks the start of a pcf block

<drive vector><drive vector> is a <string expression>



end pcf ! marks the end of a pcf blockend unit ! marks the end of a unit block

end disables ! marks the end of a disables blockdriver limit <integer> ! used with powered shorts test onlynodes ! marks the start of a nodes block

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

<device.pin> is a <string expression>inputs <node name>, <node name>,...<node name>outputs <node name>, <node name>,...<node name>bidirectionals <node name>, <node name>,...<node name>pcf order is nodes <node name>, <node name>,...<node name>

<node name> is a <string expression>unit <unit name>

pcf<drive vector>

end pcfend unit

end nodes ! marks the end of a nodes blockend <test type> ! marks the end of a test block

The following pages contain example ITL source files for sample circuit found at the end of this chapter. The first example, shown below, is an ITL source file for a powered shorts test. Note that the information in the nodes section describes the nodal adjacency of the un-nailed boundary-scan nodes (silicon nodes) and the conventional nailed nodes. These nodes do not appear to be adjacent when you look at the schematic, however, they are physically adjacent in the actual circuit.



Example 5-22

powered shorts "u1_u4_ps"chain "u1_u4"

tdi "TDI"tdo "TDO"tms "TMS"tck "TCK"devices

"u1", "custom/74bct8374", "DW_PACKAGE", no"u2", "custom/74bct8374", "DW_PACKAGE", no"u3", "custom/74bct8374", "DW_PACKAGE", no"u4", "custom/74bct8374", "DW_PACKAGE", no

end devicesend chaindisables

node "IN_26" hybrid default "1"node "IN_28" hybrid default "1"pcf order is nodes "IN_26","IN_28"unit "disable"pcf"11"end pcfend unit

end disablesnodes

silicon node "U1_2" test "u1.2","u2.23"node "IN_05" test "u1.1" ! (100 mils from u1.2)node "IN_04" test "u2.24" ! (100 mils from u2.23)

silicon node "U1_3" test "u1.3","u2.22"silicon node "U1_4" test "u1.4","u2.21"silicon node "U1_5" test "u1.5","u2.20","u4.20"silicon node "U1_U3_7" test "u1.7","u2.19","u3.7","u4.19"silicon node "U1_U3_8" test "u1.8","u2.17","u3.8","u4.17"silicon node "U1_U3_9" test "u1.9","u2.16","u3.9","u4.16"



silicon node "U1_U3_10" test "u1.10","u2.15","u3.10","u4.15"!Untestable (Inaccessible): U3_TDO, u3.11 (near u3.10)!Untestable (Inaccessible): U1_TDO, u1.11 (near u1.10)!Untestable (Inaccessible): U3_TDO, u4.14 (near u4.15)!Untestable (Inaccessible): U1_TDO, u2.14 (near u2.15)

silicon node "U3_2" test "u3.2","u4.23"node "IN_25" test "u5.9" ! (100 mils from u5.8)node "IN_18" test "u3.1" ! (100 mils from u3.2)node "IN_17" test "u4.24" ! (100 mils from u4.23)

silicon node "U3_3" test "u3.3","u4.22"!Untestable (Disable): IN_26, u5.10 (near u5.11)

node "IN_27" test "u5.12" ! (100 mils from u5.11)silicon node "U3_4" test "u3.4","u4.21"

end nodesend powered shorts

The following ITL source file is for the u1_u4 interconnect test.



Example 5-23

interconnect"u1_u4"chain "u1_u4"


"u1", "../demo_original/custom/74bct8374", "DW_PACKAGE", no"u2", "../demo_original/custom/74bct8374", "DW_PACKAGE", no"u3", "../demo_original/custom/74bct8374", "DW_PACKAGE", no"u4", "../demo_original/custom/74bct8374", "DW_PACKAGE", no

end devicesend chaindisables

node "IN_26" hybridnode "IN_28" hybridpcf order is nodes "IN_26","IN_28"unit "disable"pcf"11"end pcfend unit

end disablesnodes

silicon node "U1_2" test "u1.2","u2.23"silicon node "U1_3" test "u1.3","u2.22"silicon node "U1_4" test "u1.4","u2.21"silicon node "U1_5" test "u1.5","u2.20","u4.20"silicon node "U1_U3_7" test "u1.7","u2.19","u3.7","u4.19"silicon node "U1_U3_8" test "u1.8","u2.17","u3.8","u4.17"silicon node "U1_U3_9" test "u1.9","u2.16","u3.9","u4.16"silicon node "U1_U3_10" test "u1.10","u2.15","u3.10","u4.15"silicon node "U3_2" test "u3.2","u4.23"



silicon node "U3_3" test "u3.3","u4.22"silicon node "U3_4" test "u3.4","u4.21"

end nodesend interconnect

The following ITL source file is for the u1_u4 buswire test.

Example 5-24

buswire"u1_u4_bus"chain "u1_u4"




silicon node "U1_U3_7" test "u1.7","u2.19","u3.7","u4.19"silicon node "U1_U3_8" test "u1.8","u2.17","u3.8","u4.17"silicon node "U1_U3_9" test "u1.9","u2.16","u3.9","u4.16"silicon node "U1_U3_10" test "u1.10","u2.15","u3.10","u4.15"

end nodesend buswire

The following ITL source file is for one connect test, u2, of the u1_u4 chain. Connect test ITL source files for the

other devices�u1, u3, and u4�are similar.



Example 5-25

connect "u2"chain "u1_u4"




node "IN_04" hybrid test "u2.24"node "IN_05" hybrid test "u2.1"node "OUT_04" hybrid test "u2.4"node "OUT_05" hybrid test "u2.3"node "OUT_06" hybrid test "u2.2"

end nodes!IPG: Inaccessible nodes!IPG: node "U2_5"!IPG: node "U2_7"!IPG: node "U2_8"!IPG: node "U2_9"!IPG: node "U2_10"!IPG: node "U1_U3_10"!IPG: node "U1_U3_9"!IPG: node "U1_U3_8"!IPG: node "U1_U3_7"!IPG: node "U1_5"!IPG: node "U1_4"!IPG: node "U1_3"



!IPG: node "U1_2"end connect

Silicon Nails Test Example

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



Example 5-26 ITL Source File for Silicon Nails Test

silicon nail "u6"chain "chain_demo"




node "IN_01" test "U6.1"node "IN_02" test "U6.2"silicon node "U6_3" test "U1.15", "U6.3"silicon node "U4_10" test "U4.10", "U6.4"silicon node "U2_10" test "U2.10", "U6.5"node "OUT_01" test "U6.6"node "OUT_02" test "U6.8"silicon node "U2_9" test "U2.9", "U6.9"silicon node "U2_8" test "U2.8", "U6.10"node "OUT_03" test "U6.11"silicon node "U2_7" test "U2.7", "U6.12"silicon node "U2_5" test "U2.5", "U6.13"inputs "IN_01", "IN_02", "U4_10", "U2_10", "U2_9", "U2_8"inputs "U2_7", "U2_5"outputs "U6_3", "OUT_01", "OUT_02", "OUT_03"pcf order is nodes "IN_01", "IN_02", "U4_10", "U2_10", "U2_9"pcf order is nodes "U2_8", "U2_7", "U2_5", "U6_3", "OUT_01"pcf order is nodes "OUT_02", "OUT_03"



This is the setup-only vector added for Silicon Nails Automation.unit "Test"pcf! unit Element number 1

"11ZZZZZZLXXX""01ZZZZZZHXXX""00ZZZZZZHXXX""10ZZZZZZHXXX"

!end unit! unit Element number 2

"ZZ11ZZZZXLXX""ZZ01ZZZZXHXX""ZZ00ZZZZXHXX""ZZ10ZZZZXHXX"


"ZZZZ11ZZXXLX""ZZZZ01ZZXXHX""ZZZZ00ZZXXHX""ZZZZ10ZZXXHX"


"ZZZZZZ11XXXL""ZZZZZZ01XXXH""ZZZZZZ00XXXH""ZZZZZZ10XXXH"

!end unitend pcfend unitend nodesend silicon nail



VCL/ITL Pass-Thru Statements

The following information covers the VCL syntax available to be specified in the Interconnect Test Language (ITL). This syntax is not used by the ITL compiler for test generation algorithmic control. Rather, these statements are just placed in the final VCL file.

For complete syntax information on each statement, see the Syntax Reference documentation.

Syntax Support for Pass-Thru StatementsThere is a new category in syntax support for pass-through statements. Pass thru statements are VCL statements that are allowed in the ITL code to allow information to pass directly into VCL with out being changed by the ITL compiler (MSPD). These statements can be automatically placed by the IPG test generation process. They may also be entered manually. The ITL compiler (MSPD) has been modified to handle these new commands. These statements include:

■ disable device

■ conditioned device

■ vector cycle

■ receive delay

■ set load

■ set ref

■ set slew rate

■ set terminators

■ warning

■ on failure report

disabled device (VCL) (ITL)The disabled device (VCL) (ITL) statements are placed by the program generator in the Declaration section of an executable test to indicate which devices are disabled while that test is being executed.

For more detail on this syntax statement see disabled device (VCL) (ITL) of the Syntax Reference documentation.

conditioned device (VCL) (ITL)The program generator places conditioned device (VCL) (ITL) statements in a test�s Declaration section to indicate which devices are conditioned while that test runs.They are used by the Agilent SAFEGUARD analysis routines to determine the safe time that the test can run.

If you change the conditioning vectors in the executable test so that the conditioned output states are changed,



you should modify the associated conditioned device function accordingly and recompile the test.

For more detail on this syntax statement see conditioned device (VCL) (ITL) of the Syntax Reference documentation.

vector cycle (VCL) (ITL)The vector cycle (VCL) (ITL) statement appears in the Declaration section of the test to establish the vector cycle time; that is, the time between starting each vector. Once established, the cycle time remains the same for all vectors throughout the VCL test. The vector cycle function is not used in tests that have timing sets Chapter 3, Advanced Testing With VCL..

For more detail on this syntax statement see vector cycle (VCL) (ITL) of the Syntax Reference documentation.

receive delay (VCL) (ITL)The receive delay (VCL) (ITL) statement appears in the Declaration section of the test to establish the delay time between driving a pattern of bits to the device or circuit under test (i.e., starting a vector) and receiving (examining) the response from that device or circuit.

For more detail on this syntax statement see receive delay (VCL) (ITL) of the Syntax Reference documentation.

set load (VCL) (ITL)The set load statement is optional; you can use it in the Declaration section of a VCL test to change the pull-up or pull-down loads on the receiver nodes (nodes with outputs and bidirectionals from the board under test).

For more detail on this syntax statement see set load (VCL) (ITL) of the Syntax Reference documentation.

set ref (VCL) (ITL)The set ref statement is optional; you can use it in the Declaration section of a VCL test to setup the digital driver and receiver high and low voltages on individual nodes.

For more detail on this syntax statement see set ref (VCL) (ITL) of the Syntax Reference documentation.

set slew rate (VCL) (ITL)The set slew rate statement is optional; you can use it in the Declaration section of a VCL library test to change



the slew rate on selected drivers (inputs and bidirectional pins) to the board under test.

For more detail on this syntax statement see set slew rate (VCL) (ITL) in the Syntax Reference documentation.

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

warning (VCL) (ITL)The warning (VCL) (ITL) statement allows you to place warning messages in the test. The messages will then appear in the summary report generated by program generators, and in the compile listings for the test. Typically messages would include reminders to adapt the test in some way to suit a device in a special configuration.

The warning function can appear in the pass through part of the ITL test. In a silicon nail test, it can also appear just after the pcf order is statement or anywhere within the pcf vector block.

For more detail on this syntax statement see warning (VCL) (ITL) in the Syntax Reference documentation.

on failure report (VCL) (ITL)The on failure report (VCL) (ITL) function enables you to specify a message that will be sent to the report is printer if the test fails. This message will be sent in addition to the standard messages generated when a test fails.

The on failure report function can appear in the pass through part of the ITL test. In a silicon nail test, it can also appear just after the pcf order is statement

For more detail on this syntax statement see on failure report (VCL) (ITL) in the Syntax Reference documentation.



VCL Source Code For Chain Tests

Because an actual VCL source code for even a small boundary-scan chain would be quite long, we will discuss only the differences between the source code for a single device and that for a chain of devices. Sample sections are provided to show what the code can look like.

The statements associated with chain testing are listed below. They are followed by brief descriptions and examples. For more detailed information about these statements, refer to the Syntax Reference documentations.

■ scan powered shorts■ scan interconnect■ scan bus interconnect■ scan silicon nail■ scan debug■ scan connect■ inputs collapsed■ inputs scan clock■ inputs scan mode ■ inputs scan reset■ inputs scan■ outputs scan■ general message■ frame■ end frame

The scan powered shorts, scan interconnect, scan bus interconnect, scan connect, and scan silicon nail statements appear in the Declaration section of a VCL test and specify a boundary-scan test type.

The inputs collapsed statement appears in the Declaration of a VCL test. It describes a group of nodes, assigned to a single column, that will be tested during a series of iterations for shorts testing.

The inputs scan clock, inputs scan mode, inputs scan reset, inputs scan, and outputs scan statements appear in the Declaration section of a VCL test. They identify particular boundary-scan resources needed to test boundary-scan devices. These resources are commonly called TCK, TMS, TRST, TDI, and TDO.

The message statement allows you to include custom messages that will be output if the related vectors fail. Messages continue and are associated with all subsequent vectors until a new (or show a null) message statement is encountered.

The frame statement identifies the beginning of a block of pcf vectors used in testing boundary-scan devices. The binary values of each vector are shifted into the boundary-scan device via the Test Data In (TDI) port. When the frame bits have been captured by chain receivers, they are shifted out and stored in deep-capture RAM until all frames have been executed. The bits are then reassembled into signatures and compared to



determine if a node passes or fails a test. Every frame statement must have an accompanying end frame statement. Every frame in a test must also be the same length.

Appended to the end of the source code is a commented form of the test dictionary that provides the frame and device cell correlation, node and device.pin identification, and the expected signature for the node identified.

Items that appear in the following partial example (Example 5-27), the VCL source file shows where each of these statements and the commented form of the test dictionary would appear in an actual file.



Example 5-27 VCL source file

!!!! 6 0 1 698520684 Ve2f1! Hewlett-Packard Advanced Boundary-Scan Software [920116]! IEEE Std 1149.1-1990, BSDL (Version 0.0)! Test Specification Source: digital/u4_connect! VCL created for chain: CHAIN_U4! Date: Wed Feb 19 10:31:27 1992!! Writing code for Agilent 3070 family.! Chain Composition (TDI to TDO)! Device Entity Package BSDL File! --------- ----------- ----------- -----------------! U4 TTL74BCT8374 DW_PACKAGE /users/bscan/demo_original/custom/74bct8374scan connect ! Test device U4 ... this could be scan powered shorts, scan interconnect, scanbus interconnect, or scan silicon nailsvector cycle 200nreceive delay 100ndefault device "U4"assign N000 to nodes "IN_17"assign N001 to nodes "IN_18"assign N002 to nodes "OUT_09"assign N003 to nodes "OUT_10"assign TCK to nodes "TCK"assign TDI to nodes "TDI"assign TDO to nodes "TDO"assign TMS to nodes "TMS"family TTL !! Warning, Defaulted familyinputs scan clock TCKinputs scan mode TMSinputs scan TDIoutputs scan TDOinputs N000, N001outputs N002, N003use cards hybrid on N000, N001, N002, N003pcf order default Scan is TCK, TMS, TDI, TDO



pcf order Parallel is TCK, TMS, TDI, TDO , N000, N001, N002, N003!Column-to-Node Map, Nodes 1 to 8!TTTTIIOO!!CMDDNNUU!!KSIO__TT!! 11__!! 7801!! 90!! !unit "Connect Test" ! Vector 1pcfuse pcf order Parallel"01ZXZZXX"use pcf order Scan"11ZX". . ."00ZX""10ZX"!Shift-IRend pcfmessage "IEEE Std 1149.1-1990 Integrity Failure"message " Device U4 has failed,". . .compressframe 0 1pcfuse pcf order Parallel"00ZXZZXX"!0+0use pcf order Scan"10ZX""00ZX"!1"10ZX""00ZX"!2. . ."101X""01ZL"!17"11ZX"!Exit1-DR



end pcfend frameend compressmessage " " ! example of a null message. . .! End of Connect Test for device U4use pcf order Scan"01ZX""11ZX"!Select-IR-Scanuse pcf order Parallel"01ZXZZXX"use pcf order Scan"11ZX"!Test-Logic-Resetend pcfend unit ! Connect Test Vector 330! Vectors with TDI High: 32, 6.4 microseconds! Vectors with TDI Low: 40, 8.0 microseconds! Total Vectors : 330, 66.0 microseconds! Connect Test Dictionary! Frame Size 18! FrCell DevCell Dev.Pin Node Signature! 16 16 U4.24 IN_17 'LHXX'! 17 17 U4.1 IN_18 'LHXX'



Summary: Sample Test Generation Session

This section provides a step-by-step summary of the process used to generate tests for your boundary-scan chains. During this session, you will use files for the example circuit found at the end of this chapter. The only tool that you need to run this session is an 3070 Series II workstation.

NOTEIf you wish to run the test generated from this sample session, you will need a playpen fixture and the boundary-scan demo board.

1 Start IPG Test Consultant so that you have the starting point (the interface) that you will need to complete the steps of this sample session.

2 Before you begin this session, ensure that the example directory is properly prepared. Open a BT-BASIC window from the Programs menu of the IPG Test Consultant interface. Change to the example directory by typing the following on the command line:

msi "/3070/standard/tutorial/bscan"

To prepare the example directory, demo_circuit, type the following on the command line:

get "init_demo"

This program removes all files from the demo_circuit directory, then places the appropriate board and configuration files needed to complete the steps of the sample session. To execute this program, type the following on the command line:

run

NOTETo protect the integrity of the files needed to run sample programming sessions, do not work within the demo_original directory.

Keep the BT-BASIC window in your workspace for later use.

3 Remember that InterconnectPlus is an option for the 3070 Series II of board test systems. For this product to function, you must add the statement

enable advanced boundary scan

to your board config file. For this session, the config file is in the demo_original directory. Use the BT-BASIC window to verify that this statement is in your board config file. Remove (iconify) the BT-BASIC window from the workspace.



4 Acquire (or write) complete and accurate BSDL files for each boundary-scan device type in your chain. Remember that complete and accurate files are essential to successful implementation of a boundary-scan test. Refer to Understanding the Contents of the BSDL File on page 5-63 for details.

These files are treated like normal library files and are typically stored in the bsdl directory with the following pathname:

/3070/library/supplemental/bsdl

For this example session, we will use the following directory and pathname for the BSDL files needed:

/3070/standard/tutorial/bscan/demo_original/custom

5 Describe your chain's devices and associated pathnames using Board Consultant. Refer to Describing Your Boundary-Scan Device on page 5-55 for details.

Start Board Consultant from the Programs menu of the IPG Test Consultant interface. When the Board Consultant interface appears, click Load Existing Board. The Board Specification Form appears. Enter the following pathname in the Board Directory field:

/3070/standard/tutorial/bscan/demo_circuit

Click Load Board. The software informs you that it is loading the board file.

Click View/Edit Library Data in the flowchart. A list will appear at the bottom of the flowchart. Click Enter Library Paths. The Library Paths Form appears. The pathname ../demo_original/custom should appear in the form. If not, add this pathname, then click Update. Click Close to remove this form.

Click View/Edit Board Description in the flowchart. A new list appears at the bottom of the flowchart. Click Enter Pin Library. The Device Entry Form appears. Place the cursor in the Designator field and click once, then enter u1. Next, click the Find button. The information describing u1 will be placed in each field. You would use this form to describe new devices or to change descriptions of existing devices when you create an original board. For this session, you can examine the entries for the devices on this board, but do not change any of the entries. Select Actions > Close to leave this form.



NOTEYou can also select the Maximize option if you wish to view the entire form.

Click Final Compile/Verify in the flowchart. A new list will appear at the bottom of the flowchart. Click Compile board File. Click OK when the Confirm Message window appears. Repeat these steps for the board_xy file. Then click Save Board Files in the list at the bottom of the flowchart.

Select File > Exit to leave Board Consultant.

6 Follow the standard test generation procedures for developing a board test using IPG Test Consultant.

In the IPG Test Consultant interface, change to the working directory:

/3070/standard/tutorial/bscan/demo_circuit

Select Actions > Develop Board Test. Then select Actions > Begin Batch Development. You can watch the IPG Test Consultant message window as the software executes the test generation programs. This process will take several minutes to complete.

When IPG has completed the test generation process, you can examine the board directory (/3070/standard/tutorial/bscan/demo_circuit) to see that all files needed for your test and fixture have

been developed. From here, you would continue as you would with any other board test.

A digital directory was created and ITL files created by IPG were placed in this directory, along with other digital test files. Copies of the ITL files are found in InterconnectPlus Test Language (ITL) on page 5-158. Portions of the VCL source code that are pertinent to boundary-scan testing can be examined in VCL Source Code For Chain Tests on page 5-179. This includes a commented version of the test dictionary (.x file). You can also use a BT-BASIC window to examine the complete VCL source for this test session.

You also have the option of developing custom tests for your boundary-scan devices. These could include such tests as BIST and INTEST, or Silicon Nails tests. For more information about developing custom tests, refer to Custom Boundary-Scan Tests on page 5-51, and chapter 6, �Multichip Scan Port Driver and the MSPD Interface.� Chapter 6 also includes a sample session for developing INTEST for the example circuit. For more information about Silicon Nails tests, refer to Silicon Nails Test Strategy on page 5-130.



Sample Boundary-Scan Device Chain

The following schematic diagram shows the example circuit referred to in this chapter and in the sample test generation session. The sample circuit is also referred to by sections in chapter 6, �Multichip Scan Port Driver and the MSPD Interface.�

If you have access to a playpen fixture and a boundary-scan demo board, you can use the schematic to prepare an actual demonstration of the boundary-scan software features.

NOTEYou also have the option of building this demo board by following the schematic. This should be a viable option because of the simplicity of the board�s design

Bscan_05

Documents

Transcript of Bscan_05