3 Scan Port Driver

Medalist i3070 In-circuit Test System
Boundary-Scan Testing
3
Scan Port Driver
Overview 3-2
SPD Features 3-3
Using SPD 3-7
Test Development with SPD 3-23
Getting The Source Code Into Your Board Test 3-30
Sample VCL Source Code File 3-31
3-1
3 Scan Port Driver
Overview
When you use Agilent Boundary- Scan Software to develop custom tests for
your individual boundary- scan devices, you will use the Scan Port Driver
(SPD) software.
SPD provides macros which can be used to develop a complete test for
most devices. A typical test session includes the following steps:
1 Start SPD and specify the BSDL input file and VCL output file.
2 Select the Default Device and Specify Family macros if needed.
3 Select the Bypass Test macro.
4 Select the ID Code Test macro.
5 Select the Running Toggle macro.
Also select the Add Comment macro as needed.
See Using SPD Macros for descriptions of the macros.
Sometimes you will want to develop tests that are not included in the
macros. This requires custom programming and the use of the TAP
Controller State Diagram. See Using the TAP Controller State Diagram for
details on generating custom tests.
Spend some time familiarizing yourself with the basic concepts of IEEE
Standard 1149.1 (see IEEE BSDL) before you read this chapter. You also
need to understand Vector Control Language (VCL) and the test generation
process.
3-2 Boundary-Scan Testing

Scan Port Driver 3
SPD Features
• How SPD Works
• The SPD Menus
• The SPD Workspace
How SPD Works

The Scan Port Driver (SPD) software verifies adherence to IEEE Standard
1149.1, examines BSDL specifications, and generally supervises the test
generation process. SPD has an integrated understanding of the IEEE
Standard and BSDL.
When you specify a BSDL input file, SPD retrieves the source file, checks
the syntax and compliance with the IEEE Standard, then waits for your
input to generate the tests needed. SPD takes these inputs, refers to the
IEEE Standard information and the BSDL input file, and generates the
vectors (VCL in Pattern Capture Format or PCF) that your board test uses.
Figure 3- 1 illustrates how SPD takes these elements and generates your
tests.
Figure 3-1 Test Generation by SPD
BSDL Source File
Scan Port Driver (SPD)

SPD interface
Input Data
SPD has integrated Macro-Programming
understanding of IEEE 1149.1 Micro-Programming
and BSDL Display Status spd.log File
VCL source code

library or executable
Boundary-Scan Testing 3-3

3 Scan Port Driver
The SPD Menus

The SPD functions are provided on two menus: File and Macros.
File menu
The options on the File menu are:
• Open - Starts a test session for a new device.
• Save - Saves the VCL output file.
• Exit - Quits SPD.
Macros menu
The macros on this menu automatically generate vectors for common
functions. The macros provided are:
• Specify Family
• Default Device
• Reset TAP
• Bypass Test
• ID Code Test
• User Code Test
• Parallel Toggle
• Running Toggle
• Toggle Pins
• Extest
• Simple Setup
• Setup & Disable
• Add Comment
• Verify BSDL
• Include File
See Using SPD Macros for descriptions of the macros.

Scan Port Driver 3
The SPD Workspace

The workspace is your main interface for writing a test program for your
device. The workspace contains three areas:
• Status Area
• Working model of the TAP Controller State Diagram
• User Text Input Area
Figure 3-2 SPD Workspace
Status Area
Tap Controller State Diagram

Allows selection and displays
current “state”
User Text Input Area

For text and data input
SPD Status Area

The Status Area shows the current status of the SPD. The status is
updated after each state change or macro selection, and helps you keep
track of the test generation process.
Except where noted, SPD extracts this information from the BSDL input
file, and by using its integrated knowledge of IEEE 1149.1. The following
details are provided in the Status Area:
• Target Register. The register targeted by the current instruction. This is
the name of the register that will be placed between TDI and TDO to
perform the current instruction, or to receive the instruction bits.
• Current Instruction. The instruction that is in effect while the TAP
Controller is in the current state.

3 Scan Port Driver
• Pending Instruction. The instruction that will become the current

instruction when the TAP Controller passes through the UPDATE- IR
state.
• Length. The length of the target register.
• Unit #. The current VCL unit number for the test being generated. This
information is generated by SPD.
• Vector. The current length of the test being developed in vector cycles.
This information is generated by SPD.
The fields in the Status Area are updated as you move through the TAP
Controller State Diagram, to show changes in the state, units and vector
count increase, current and pending instructions, and target register.
SPD TAP Controller State Diagram

The TAP Controller State Diagram is used to create custom tests for your
device. Each state in the diagram is a button. When you click on a state,
SPD determines the shortest path from the current state to the selected
state, and writes the necessary vectors to complete the transition.
If you need to create custom tests, you should be familiar with the
function and operation of the TAP Controller State Diagram (refer to IEEE
Standard 1149.1 for details).
SPD User Text Input Area

The user input area is highlighted when SPD requires information to
continue the test generation process. A message prompts you for the
information needed, such as:
• the data bits to shift into a register
• the drive states to issue for a test
• the receive states to expect from a test
• the comment to annotate the VCL code
The type of information you may need to provide are explained in Using
SPD Macros and Using the TAP Controller State Diagram.
The Input field allows you to enter up to 75 bits. If you need to enter
more, press Enter after the first 75 bits before continuing.

Scan Port Driver 3
Using SPD
• Launching SPD
• Using SPD Macros
• Using the TAP Controller State Diagram
Launching SPD
You can launch SPD in any of the following ways:
• UnMux systems: from the Developer Interface, select Launch > Boundary
Scan.
• Mux systems: from Agilent IPG Test Consultant, select Programs >
Boundary Scan.
• From a BT- Basic window, as described below.
When you launch SPD, the I/O Specification Form appears for you to
specify the following:
• The device’s BSDL file.
• The VCL output file to write the output to.
• An alternative package for the device when it has more than one
package option. Specifying a package here overrides the default package
specified by the BSDL input file.
Whenever you run SPD from the Developer Interface or Test

NOTE
Consultant, ensure that the current directory is your board directory so
that the VCL source code generated will be saved under the correct
directory.
Run SPD from a BT-Basic Window

Use the execute statement to run SPD from a BT- Basic window. The
syntax is:
execute "spdif [option] BSDL_input_filename VCL_output_filename"
For example:
execute "spdif 74bct8374 vcl_out1"
If you do not specify the input or output filename, the I/O Specification
Form is displayed for you to select the files.
The option allowed in the execute statement is -pNAME, which specifies
the package name to use for pin mapping. For example:
execute "spdif -pDW_PACKAGE 74bct8374 VCL_OUT1"

3 Scan Port Driver
Using SPD Macros

This section describes each macro, the message displayed in the User
Input Area when the macro is selected, and the data you need to provide.
Many of the prompts described in this section ask you to enter the states
for device inputs or outputs. For this purpose, we define states as 0, 1, or
Z for inputs and H, L, or X for outputs.
Several macro descriptions refer to the Sample VCL Source Code File, to
show where the generated code may be found.
The macros automatically generate vectors for common functions. The
macros provided on the Macros menu are:
• Specify Family
• Default Device
• Reset TAP
• Bypass Test
• ID Code Test
• User Code Test
• Parallel Toggle
• Running Toggle
• Toggle Pins
• Extest
• Simple Setup
• Setup & Disable
• Add Comment
• Verify BSDL
• Include File
Specify Family
This macro specifies the family (TTL, CMOS) for the device.
Message displayed in User Input Area:
Enter family (for example, CMOS) for this device:
If no family is entered, SPD defaults to TTL. In the source code, the family
specification appears in the header area (line 16 in the Sample VCL
Source Code File).
If you want to specify a default device, you must do so before you start
developing your device test vectors.

Scan Port Driver 3
The SPD Interface allows you to specify logic families, but does not
NOTE
make provisions for multiple logic families. You will have to manually
edit the VCL library file and add statements for additional logic
families.
The family specifer included in the node statement must appear after
the node name and before any (optional) channel specifications.
In addition, a setup library test must be provided for the boundary-scan
devices. This test must include the proper family information for the
device.
Default Device
This macro specifies a designator to assign to the device.
Enter name (for example, U102) to be used for Default Device:
Assigning a default device designator causes SPD to create an executable
source file. If you do not assign a default device, SPD assigns u1 and
generates a library source file; the creation of the executable test is left to
the development software. In the source code, the default device
specification appears in the header area, as shown in Sample VCL Source
Code File.
Notice that the power pins are starred when you assign a default device. If
you want to specify a default device, you must do so before you start
developing your device test vectors.
Reset TAP
This macro generates 10 vectors to ensure that SPD is in the
TEST- LOGIC- RESET state regardless of where you were last in the TAP
Controller State Diagram.
Bypass Test
This macro generates a series of vectors that causes the device to execute
the BYPASS function. You can use this function to exercise the Bypass
Register and to verify that the TAP is operating properly.
It is recommended that you execute this test before developing any

NOTE
other test on your device. If this test fails, no other test can pass.

3 Scan Port Driver
ID Code Test
This macro generates a series of vectors that loads the IDCODE instruction
and reads the ID code, if an identification register exists, and compares
the code against the one found in the BSDL description.
If an identification register does not exist, the macro will generate vectors
that load the BYPASS instruction, which proves that the device does not
support an IDCODE function.
User Code Test

This macro generates a series of vectors that loads the USERCODE
instruction and reads the user- programmed code, if it exists, and
compares it against what is in the BSDL description.
If a USERCODE instruction does not exist, SPD will do nothing.
Parallel Toggle
This macro generates a series of vectors that toggles all input and output
pins in parallel. This is a high- level macro that uses two lower- level
macros, Extest and Reset Tap.
Essentially, the Parallel Toggle macro comprises six units: an initialization
unit, two units that test input pins, two units that test output pins, and a
unit that resets the TAP. Example 3- 1 summarizes what each unit does.
Example 3-1
unit "Init_Parallel_Toggle"
Sample/Preload function to load "safe" bits
unit "Inputs_0_1"
drive all input pins to 01010101 ... and verify on TDO
EXTEST macro
unit "Inputs_1_0"
drive all input pins to 10101010 ... and verify on TDO
EXTEST macro
unit "Outputs_High_Low"
set all output pins to HLHLHLHL ... and verify
EXTEST macro
unit "Outputs_Low_High"
set all output pins to LHLHLHLH ... and verify
EXTEST macro
unit "Reset Parallel Toggle"
Reset TAP macro
You can use the Parallel Toggle macro when you know that there are no
constraints on the input pins, such as two input pins tied together or an
input pin tied to ground.

Scan Port Driver 3
When the source code is sent to the development software, units

containing vectors that would cause problems due to the constraints
explained above would be commented out. This macro also works for
devices with bidirectional pins acting as inputs. A primary benefit of this
test is that it is short. It can be executed quickly and it provides a
thorough test of the device input and output pins. However, it relies on
the device having no topological constraints. And the test can fail if the
device and board are not designed to support all pins transitioning
simultaneously.
The test will report an individual failing input pin as TDO data is shifted
out. The test is in "stop on first failing vector mode" so the first failing
input pin shifted out on TDO will stop the test. The failed pin will be
reported with a message such as "Pin 17 failed high". If all input pins
pass, the test continues by setting up drivers to drive out parallel bits. If
one or more of these are seen to fail by the parallel receivers, all are
reported and the test stops.
Running Toggle
This macro generates a series of vectors that causes the device to toggle
the input and output pins. This macro is similar to Parallel Toggle except
it generates one unit for each input pin, which makes it a longer test.
This macro generates the following units for bidirectional pins acting as
inputs:
unit "Switch_Bidirs_To_Input"
switches dir. of bidirectional pins to inputs
unit "Bidirs_In_1_0"
drive all bidirectional pins to 10101010 ...
unit "Bidirs_In_0_1"
drive all bidirectional pins to 01010101 ...
The bidirectional pins are tested in parallel. The initialization, output, and
reset units described in the Parallel Toggle macro apply to this macro,
except that the output units also test bidirectional pins as outputs. The
input units are also similar, except that a unit is generated for each input
pin and the vectors in those units toggle each input pin individually.
The Running Toggle macro treats all input pins (and any bidirectional pins
acting as inputs) independently. Each is given a test unit that drives the
pin high and shifts out data on TDO to verify this. Then the unit drives
the pin low and shifts out TDO to verify this. All other input pins are
ignored during this unit.
Input pin test units are created until all inputs (and bidirectional pins
tested as inputs) are tested. If any input pin test unit should fail, the test
will stop at that point.

3 Scan Port Driver
The macro then creates units that consider device outputs (and
bidirectional pins acting as outputs). One causes all outputs to have an
alternating 0- 1 pattern on the outputs, and the second causes the opposite
pattern on the outputs. These are monitored by parallel receivers for
correct values.
This feature applies to single device tests only; to test device chains, you
need the optional Agilent InterconnectPlus software.
Toggle Pins
This macro generates a series of vectors that causes the device to toggle
only the pins specified. This macro uses the same units as Running Toggle
on the pins specified.
Enter pins one per line (multiple pins terminate with empty line):
You must enter the pin numbers that you want to test. Enter each pin
number and press Enter. When you have entered all pins to be tested, press
Enter once more to let SPD know that you have finished entering pin
numbers.
The test will report an individual failing input pin. The test stops when
the first failing pin occurs. This feature applies to single device tests only;
to test device chains, you need the optional Agilent InterconnectPlus
software.
Extest
This macro generates a series of vectors that automatically load the
EXTEST instruction if EXTEST is not currently in effect. You would
typically use this lower- level macro when you develop a more complex
test, such as the Toggle macros, or when performing a one- time
experiment during debug.
Whenever you plan to execute the Extest macro or other lower-level

NOTE
functions within SPD, you should first run SPD on your BSDL input file,
exit without developing the test further, and print out the VCL output
file so that you will know the order of the device pins, which is found
in the VCL source code header. You will need this order to develop your
test. Refer to the Sample VCL Source Code File to see what this order
can look like.

Enter N states driven to inputs (not including TAP).
Enter the data for the tester to drive to the device input pins.

Scan Port Driver 3
If your device has bidirectional pins, this message is displayed:

Enter N states for bidirectional pins (0,1,Z = in H, L, X = out).
Enter the states at which the tester should set the device bidirectional
pins.
When you have entered these states, another message appears:
Enter N states to be received from outputs (not including TAP).
Enter the data that the tester should receive from the device output pins.
Extest has several requirements that must be adhered to for the macro to
perform as you intend. The value of N equals the number of inputs or
outputs for the device. You must enter exactly N states when prompted;
more or fewer than N states entered causes SPD to change the input data
to all Zs or the output data to all Xs.
SPD loads the bits in the order specified, so you must know what bits you
want to drive on which input pins or receive from which output pins.
Refer to the Sample VCL Source Code File: lines 46- 50 specify the device
inputs and outputs, while lines 55- 61 specify the sequence of the data bits
in the vector. You must consider this mapping before you enter the drive
and receive states.
Simple Setup
This macro generates setup- only library tests for Boundary- scan devices.
The setup- only library test includes pin assignment, pin definition, and
family information sections.
To use the Simple Setup macro, it must be the first macro you select from
the menu.
See also the Setup & Disable macro.
Setup & Disable

This macro generates setup- only library tests for Boundary- scan devices.
The setup- only library test includes pin assignment, pin definition, family
information, and a unit disable method. The disable method is determined
by the HIGHZ or INSTRUCTION DISABLE keywords in the BSDL file; if
neither keyword is included in the BSDL file, the EXTEST disable method
is used.
This macro is the same as the Simple Setup macro with the addition of
the unit disable method.
To use the Setup & Disable macro, it must be the first macro that you
select from the menu.

3 Scan Port Driver

Disable units created this way for multiple devices chained together
NOTE
will conflict with one another. The best option is to use Simple Setup
in conjunction with InterconnectPlus Boundary-Scan with the
Boundary-Scan Disables flag set.
Otherwise, another option would be to use the device’s output disable
pins (if any) to specify disabling rather than disabling via the
Boundary-Scan chain. Disabling via the output disable pin must be
done manually in the VCL file after finishing the SPD generation.
Add Comment
This macro lets you add comments to the source code. The comment will
appear in the source code at the point in the test where you selected the
macro. You can use comments to explain the intent of a test or to help
you during debug.
Type text of comment (multiple lines terminated with empty line):
You can enter multiple lines of comments. Type each line and press Enter.
At the end, press Enter one more time.
Verify BSDL
While the other macros test for manufacturing faults, Verify BSDL tests
the contents of the BSDL file and the 1149.11 standard against the silicon
of the device. For the device tests generated by Agilent Boundary- Scan
software to execute properly, the BSDL descriptions of the device must
match the device's actual silicon.
Because the BSDL verification test of a device can be quite long, it is not
intended to be used in production testing. For example, the verification
test for the sample device 74bct8374 is over 4200 vectors long. In
comparison, Running Toggle is just over 1000 vectors long. The difference
gets rapidly worse with more complex devices.
The macro first generates vectors that test the IDCODE: it verifies the
IDCODE if one exists, or if the BSDL does not describe an IDCODE, it
verifies that one does not exist.
The macro then goes through an iterative process that verifies every
opcode specified in the BSDL file. It verifies the mapping from the
instructions to their respective registers. When a given instruction
specified in the BSDL is loaded into the IR, a particular register should be
placed between TDI and TDO.

Scan Port Driver 3
Op codes (such as HIGHZ) to tristate the output pins are run, but the
NOTE
outputs are not checked to be tristated.
For example, when the instruction OPCODE 11111111 for the 74bct8374 is
loaded into the IR, the Bypass Register should be placed between TDI and
TDO upon passing through UPDATE- IR. As this test is being executed, the
operation of the TAP is checked for each and every TAP state.
Next, the macro places the device in EXTEST to verify the mapping
between device input and output pins to their respective Boundary
Register cells. Pins are tested one at a time, using a walking- ones test to
ensure that pins are not cross- mapped. Bidirectional pins are tested the
same way as the I/Os, with the added step of testing the pin once as an
input then once as an output.
Boundary- scan control cells are then tested. Again, these cells are tested
one at a time, using a walking- ones- type test. This portion of the test
ensures that the control cells perform as described in the BSDL file. For
example, in the sample device 74bct8374, cell 16 is a control cell that
enables the outputs on cell 0- 7. Proper operation of this cell is verified by
executing one unit for each of the output cells tied to the control cell.
After testing has been completed, the macro writes a final unit to take the
device through TEST- LOGIC- RESET.
The patterns generated by this macro can be run on an Agilent 93000
digital IC tester, or they can be translated to run on similar systems.
An alternative to using an IC tester is building a simple fixture in which
the device(s) can be individually tested. Also, you can translate the VCL
into a form compatible with a Logic Simulator.
The test will report an individual failing input pin. The test stops when
the first failing pin occurs. This feature applies to single device tests only;
to test device chains, you need the optional Agilent InterconnectPlus
software.
Include File
This macro specifies a file of interface commands to include for the test.
Enter name of file to include:
Enter the name of the file to include. This file is typically one that you
would develop from the spd.log file. See Using the spd.log File for Test
Generation for more information.

3 Scan Port Driver
Using the TAP Controller State Diagram

Use the TAP Controller State Diagram in SPD to create custom tests for
your device. Each state in the diagram is a button. When you click on a
state, SPD determines the shortest path from the current state to the
selected state, and writes the necessary vectors to complete the transition.
The small boxes containing asterisks (*) are also buttons. These iterator
buttons, attached to the RUN-TEST-IDLE, SHIFT-DR, and SHIFT-IR states,
perform different functions, but all are used to speed up test development
because they allow you to enter codes or data all at once. When you click
on an iterator button, you will be prompted to enter information
associated with the state's function. The following describe the use of the
iterator buttons:
• RUN- TEST- IDLE
• SHIFT- DR
• SHIFT- IR
Sometimes, however, you may need to take a lower- level approach in
developing your test. You may need to move through the TAP Controller
state by state. As you click the other buttons in the TAP Controller State
Diagram, you will also be prompted for data. The following describe the
use of the controller state buttons:
• SHIFT- IR and EXIT1- IR
• EXIT1- DR
• SHIFT- DR
See also the discussion on TAP Signal Changes, which describe the
changes in the TAP signals as you pass through the controller states.
Note that many of the prompts described in this section ask you to enter
the states for device inputs or outputs. For this purpose, we define states
as 0, 1, or Z for inputs and H, L, or X for outputs.

Scan Port Driver 3
Figure 3-3 Tap Controller State Diagram
RUN-TEST-IDLE
Click the iterator button to specify the total number of TCK clocks to
apply for a given test.
Enter the number of Run-Test/Idle clocks to issue:
Enter the number of test clocks needed to execute your test. This
information is usually found in the data sheet for the device. Two vectors
are generated for each clock, one for the rising edge of TCK, and one for
the falling edge. In the VCL, a repeat loop is built in to conserve vector
space.
SHIFT-DR
Click the iterator button to enter all drive states and update data at one
time.
Before passing to SHIFT- DR, you may first pass through CAPTURE- DR.
Based on the instruction loaded (for example, EXTEST will cause this) you
may see the following two prompts:
Enter N states driven to inputs (not including TAP).
Enter the data for the tester to drive to the device input pins.

3 Scan Port Driver
If your device has bidirectional pins, the message displayed is:

Enter N states driven to the bidirectional pins.
Enter the data for the tester to drive to the device bidirectional input
pins. SPD has several requirements that must be adhered to for the device
to perform as you intend. The value of N is the number of input, output,
or bidirectional pins. You must enter exactly N states when prompted;
more or fewer than N states entered causes SPD to change the input data
to all Zs or the output data to all Xs.
SPD loads the bits in the order specified, so you must know what bits you
want to drive on which input pins or receive from which output pins.
Refer to the Sample VCL Source Code File: lines 46- 50 specify the device
inputs and outputs, while lines 55- 61 specify the sequence in which data
bits are ordered for the vector. You must consider this mapping before you
enter the drive and receive states. (Run SPD and perform a simple macro
such as Reset_Tap. Print out the VCL to see the order of Input, BiDir, and
Output bits. Keep this for reference.)
When you have entered the drive states, if required, another message
appears:
Enter update data to be shifted into REGISTER [N]
The name for REGISTER is the target register for the current instruction.
The value of N is the length of the register. Enter the data to shift into
the target register that will later be latched onto the update flip- flops for
that register. This data is typically found in the data sheet.
SHIFT-IR
Click the iterator button to enter the entire bit pattern for an instruction
at one time.
Enter the instruction code to be scanned into the TAP:
Enter the binary code for the instruction that you want to execute.
Alternatively, you can enter the name of the instruction you want to
execute provided it is described in the BSDL input file. For example, for
the sample device 74bct8374, you can enter 10001111 or SCANCT.

Scan Port Driver 3
SHIFT-IR and EXIT1-IR

When you click on SHIFT- IR (not the iterator) for the first time (while in
some other state) you get no prompt because you have just entered the
state and no shifting occurs on the first entry. Any click on SHIFT- IR
after entering, or on EXIT- IR when you want to exit, causes a prompt for
a shift bit in the User Input Area:
Enter a Bit (0 or 1) to shift into TDI
Notice that the TAP Controller State Diagram becomes inactive until you
enter the requested bit. You must enter the data bits for the instruction
that you want to load into the instruction register one bit at a time, the
last bit is entered when you pass out of SHIFT- IR and into EXIT1- IR.
Typically you would not enter instruction bits one at a time, you would
NOTE
use the instruction iterator button. This description is included to
show what occurs should you decide to step through the IR column
state-by-state.
EXIT1-DR
Clicking this state ends a SHIFT-IR (non- iterator) sequence and displays a
prompt for the last bit to be shifted in the User Input Area:
Enter the bit that you want to load into the target register.
SHIFT-DR
Different input may be required during this state, depending on the
instructions supported by the device, and the target register of the current
instruction. Typically, you will see one of the following messages:
• The drive and receive prompts described above under Extest.
• Enter update data to be shifted into REGISTER [N]:
Enter the binary code that you want to shift into the target register
when passing through the UPDATE- DR state. This is typically used to
PRELOAD a register for the next test function. The name given to
REGISTER is the target register for the update data. The value for N is
the size of the target register.
• Enter data captured in REGISTER [N]: (return -> none)
Enter the binary code that will be captured from the parallel inputs to
the target register when passing through the CAPTURE- DR state. This
could be information provided in the manufacturer's device data sheet.
The name given to REGISTER is the target register for the capture data.
The value for N is the size of the target register.

3 Scan Port Driver
TAP Signal Changes

This section describes the changes in the TAP signals during the controller
states.
Figure 3- 4 illustrates the sequence and timing of events with respect to
TCK and TMS. Note that this is not real time, but time in reference to
clicks on the SHIFT-DR and EXIT1-DR buttons.
As Figure 3- 4 shows, when you first click on SHIFT-DR no shifting occurs,
but the TAP controller is set to change from the CAPTURE- DR state to the
SHIFT- DR state on the next rising edge of TCK. (Nothing happens on
screen, where you might expect to see a messasge in the Input area.)
On the second and all subsequent clicks on the SHIFT-DR button, TDI is set
up such that the next valid data bit will be stable when the next rising
edge of TCK occurs. On each rising edge of TCK (with TMS at logic 0),
while in SHIFT- DR, prompts appear in the User Input Area, then data is
shifted in TDI.
At the same time, TDO is enabled so that valid bits can be shifted out on
the next falling edge of TCK. On each falling edge of TCK, while in
SHIFT- DR, data is shifted out TDO; notice that the TDO receiver (in the
tester) is inactive on rising edges of TCK. Note that the tester actually
measures TDO somewhere in the middle of the vector cycle as a result of
a receive delay.
When you are ready to shift the last input bit in TDI, you click on the
state. This causes TMS to go high (logic 1) and the last output bit is
shifted out TDO on the falling edge of TCK. The last input bit is then
shifted in TDI on the next rising edge of TCK.

Scan Port Driver 3
Figure 3-4 Timing Diagram Showing Shift Events and TAP Signal Relationship
First click on Click on
Shift-DR 2nd Nth Exit1-DR
TCK
TMS
CAPTURE-DR SHIFT-DR EXIT1-DR
TDI VALID VALID VALID

Legend:
VALID = Valid Data Bit

TDO VALID VALID VALID XXX = Don’t Care
Notice that on the first falling edge, data can be shifted out of TDO even
though nothing has been shifted in TDI. In this way, the IEEE Standard
assures that data shifting out TDO of one device is set up properly for TDI
on the next device. Mandating that TDO shifts lead TDI shifts by a
half- cycle guarantees that the two devices would not be in a race
condition.
If you look at Figure 3- 5, you will see a flip- flop just before the TDO
output that is enabled by the signal TCK* (an active- low signal). When
TCK goes low during a shift phase (note also the shift enable at the
output in Figure 3- 5), the data present in the target register's cell closest
to TDO will be shifted out.

3 Scan Port Driver
Figure 3-5 Block Diagram of a Boundary-Scan Device
Test Data Registers
Boundary Register
Device Inputs Device Outputs

Internal Logic
Device Identification Register

Design-Specific Data Registers MUX
Bypass Register
G1
ModeN
Mode1
Mode3
Mode2
Select
MUX 1D TDO
1 EN
C1
1
TDI Instruction Decode
Instruction Bits
Shift Register
Instruction Register
Reset*
ClockDR
ShiftDR Reset*
ClockIR
UpdateDR
ShiftIR
TMS TAP UpdateIR
Controller
TCK Select
TRST* (16-state TCK*
machine) Shift * Active-Low Signal

Scan Port Driver 3
Test Development with SPD

You can develop a device test in SPD by using one or more of these
methods:
• macro- programming
• micro- programming
• working with the spd.log file
Whenever you develop a device you should first run SPD on your
NOTE
BSDL input file and print out the VCL output file so that you will know
the order of the device pins. You will need this order to develop your
test. You should also have other items at hand, such as the
manufacturer's device data sheet and a copy of the BSDL input file,
that will affect how you test the device. For example, the data sheet
might provide a table that describes the opcodes needed for the
device to perform various functions.
Using Macro-programming for Test Generation

Macro- programming is a high- level programming technique. You need only
be concerned with the type of instruction that you want to include in your
test.
SPD provides the macros that automatically generate the vectors needed
for a specific instruction. They can be used to develop a complete test for
most devices.
The macros are described in Using SPD Macros.
A Sample Macro-programming Session

A typical test generation session includes the following steps:
1 Specifying the BSDL input and VCL output files.
2 Selecting the Default Device and Specify Family macros if needed.
3 Selecting the Bypass Test macro.
4 Selecting the ID Code Test macro.
5 Selecting the Running Toggle macro.
You may also select the Add Comment macro as needed.

3 Scan Port Driver
The following process generates a test for the sample device 74bct8374.
1 Launch SPD.
2 In the I/O Specification Form, select the BSDL Input File. Use the
following sample file:
$AgilentICT_Root\library\supplemental\bsdl\74bct8374
3 Type a name for the VCL Output File and click OK. (Use a name that
will not affect actual board files. You can include the path or let the
software save the file to the current directory.)
SPD compiles the BSDL input file.
4 From the Macros menu, select Add Comment and type the following
comment:
This begins the sample macro-program test session. BYPASS test
will be executed first.
5 From the Macros menu, select Bypass Test.
The values in the Status Area change: BYPASS is listed as the target
register with length 1; the current instruction is 11111111; the pending
instruction is 11111111; and one unit and 36 vector cycles are created.
As you continue with this session, observe what occurs in the Status
Area. From the Macros menu, select ID Code Test. You should see that the
target register does not change, but the other status entries do. The fact
that the target register remains BYPASS proves that this device does not
support the ID Code Test function.
comment:
Ready to begin EXTEST.
7 From the Macros menu, select Extest and type 1111111111 in the Input
field.
You will see the following prompt:
Enter 8 states to be received from outputs (not including TAP).
Now enter 00000000 in the Input field.
Note that when you use the macro function, the test focuses on the
device by asking for states for the inputs and outputs.
8 This completes the sample session. From the File menu, select Save.
Print the output file so that you can examine its contents. Note where the
comments appear in the file. For details about what appears in the file,
refer to the Sample VCL Source Code File.

Scan Port Driver 3
Using Micro-programming for Test Generation

To develop unique tests for your device or tests to access user- developed
functions that comply with the IEEE standard, use the TAP Controller
State Diagram in SPD.
Move through the model of the TAP Controller State Diagram just as the
test you are generating must when it executes the instruction you need to
implement. As you click on each state and enter the instructions and
codes, SPD takes your inputs and generates the vectors needed the test.
You can speed up the generation process by skipping states. For example,
if the current state position is TEST-LOGIC-RESET, and you want to move
through the TAP Controller State Diagram to CAPTURE-DR, you can simply
click the destination state. SPD will automatically generate the test vectors
needed to complete the sequence.
Note that SPD will take the shortest path from the original state to the
destination state. For example, if you move from CAPTURE-IR to UPDATE-IR,
SPD will generate vectors that moves you through EXIT1-IR, the shortest
path, to UPDATE-IR. Be sure that a sequence for the shortest route is what
you want before using this method.
A Sample Micro-programming Session

The following process generates a test for the sample device 74bct8374.
1 Launch SPD.
2 In the I/O Specification Form, select the BSDL Input File. Use the
following sample file:
$AgilentICT_Root\library\supplemental\bsdl\74bct8374
3 Type a name for the VCL Output File and click OK. (Use a name that
will not affect actual board files.)
SPD compiles the BSDL input file.
comment:
This begins the sample micro-program test session. BYPASS test
will be executed first.
5 Click on the SHIFT-IR iterator button and type 11111111 in the Input
field. (For information on SHIFT- IR, see SHIFT- IR on page 3- 18.)
This code should appear in the Pending Instruction field in the Status
Area.
6 Click on the UPDATE-IR state.
Notice that only the Vector field in the Status Area changes.

3 Scan Port Driver
7 Click on the SELECT-DR-SCAN state.

The current instruction is now the same as the pending instruction and
that the target register is now BYPASS.
8 Click on the SHIFT-IR iterator button again and type EXTEST in the Input
field.
The pending instruction changes to 00000000, the code for EXTEST.
Whenever you work in the IR column, the Instruction Register is the
target register.
9 Click on the SELECT-DR-SCAN state.
The current instruction changes to 00000000 and the target register
changes to BOUNDARY with a length of 18.
10 Click on the SHIFT-DR iterator button and type 1111111111 in the Input
field. (For information on SHIFT- DR, see SHIFT- DR on page 3- 19.)
The message in the Input area will show:
Enter update data to be shifted into BOUNDARY [18]
Enter 101010101010101010 in the Input field.
Note that at this level, the test focuses on the target register.
11 Click on the SHIFT-IR state twice (not the iterator button).
At the second click, the message in the Input area will show:
Enter a Bit (0 or 1) to shift into TDI
Enter 1 in the text field.
(For more information, see SHIFT- IR and EXIT1- IR on page 3- 19.)
12 You will now enter the BYPASS instruction one bit at a time. Click on
the SHIFT-IR state six more times and enter a 1 in the Input field at each
prompt. Notice how the 1s shift their way through the pending
instruction each time you enter a bit.
13 Click on the EXIT1-IR state. You will be prompted once again for a bit to
shift into TDI. This occurs because you must shift the last bit of the
instruction in when you pass out of SHIFT-IR.
Enter a 1 once more.
14 Click on the SELECT-DR-SCAN state. Notice that the pending instruction
becomes the current instruction, and the target register changes to
BYPASS.
15 Click on the SHIFT-IR iterator button once again. In the Input field, enter
SCANCT (a user- defined function). Notice the pending instruction.
16 Click on the SELECT-DR-SCAN state. Notice that the pending instruction
becomes the current instruction, and the target register changes to BCR,
a user- defined register with two cells.
17 Click on the SHIFT-DR iterator. This prompt should appear in the User
Input Area:

Scan Port Driver 3
The message in the Input area will show:

Enter the data captured in BCR [2]: (return -> none)
Press Enter because the data sheet does not tell you what is captured.
This message will appear:
Enter update data to be shifted into BCR [2]:
Enter 10 in the Input field. This code is listed in the device's data sheet
and causes the device to run a parallel signature analysis (PSA).
18 Click on the TEST-LOGIC-RESET state to reset the device's TAP controller.
This completes the test session.
Print the output file so that you can examine its contents. Note where the
comment appears in the file. For details about what appears in the file,
refer to the Sample VCL Source Code File.
Using the spd.log File for Test Generation

When you run SPD, every action taken during your test session is
recorded in a file called spd.log. Each time you run SPD, it overwrites
the spd.log file. You can use the spd.log file to develop your
boundary- scan device test. Example 3- 2 shows the spd.log file that was
generated for the Sample VCL Source Code File.
Example 3-2 Sample spd.log file

reset_tap
extest_cycle
1010101010
01010101
end
Listing 4-1. The spd.log File Generated for the Sample VCL Source
Code
This listing shows you how simple the test session for the sample VCL
source code really is. During the test session, we executed the Reset TAP
macro and the Extest macro, where we entered the 10 drive states and
eight receive states for the device. (Receive states are converted to H and
L characters by the interface.) Then we ended the session. The spd.log
file for this session recorded all of the actions taken.
We can use this simple test as a template to construct a more complex
test. We can see from this listing what SPD needs to execute a test; and
we can copy the format and assemble a new test. Figure 3- 6 shows how
the test was expanded simply by following the format of the original test
and adding new patterns.

3 Scan Port Driver
Figure 3-6 Expanded Test
reset_tap
extest_cycle Original test cycle

1010101010
01010101
extest_cycle
1111111111 Added test cycle
00000000
extest_cycle
0101010101 Added test cycle
10101010
end
Listing 4-2. A New spd.log File Generated by Using the

Sample VCL Source Code's spd.log File as a Template.
This type of test development can be useful when you have data in
another database that you want to import into your boundary- scan test.
You might want to write an extraction program and feed the information
through SPD to automatically serialize the data into a form the tester can
use. This information could be hundreds of vectors deep and would take
much longer to complete using the macros or the TAP Controller State
Diagram.
Once you have developed the template for your test, you could use your
extraction program to feed the bits into the template and generate the
test.
A Sample spd.log File Test Generation Session

Run a quick macro test session to obtain the template with which you will
work. Refer to A Sample Macro- programming Session if you need help. Do
only one iteration of the Extest macro for this exercise. Then locate the
spd.log file, which will be your template in the following session.
1 Open a BT- Basic window.

2 When the BT- Basic window appears, make sure that you are in the
correct directory. Rename the spd.log file for the macro test that you
just ran. Type:
rename "spd.log" to "temp"
Rename the file so that it will not be overwritten if you run a new test
session. Remember that SPD overwrites the spd.log file with each new
test session.

Scan Port Driver 3
3 Retrieve the file now by typing:

get "temp"
Look at the contents of the file and find the extest cycle. For this
function, you will find the label extest_cycle followed by two lines of
code.
4 Add several lines (three for each new extest cycle) below the second
line of data bits. On the first line, type:
extest_cycle
followed by your choice of code, for example:
1111111111
00000000
Remember that this file is a template you must follow for the new test
to work properly. For example, if your device has ten input pins, and
the template shows ten bits specified for them, your modifications must
also have ten bits. You must also ensure that the sequence of bits
matches that specified in the BSDL source file.
5 Delete the end command from the template. This will allow you to
develop other functions for the device test when you run the modified
test in SPD.
If you do not remove the end command and you run the modified test,
when SPD reaches the end command, the test development will stop
and SPD will close.
6 On the command line, type:
resave
7 Then exit the BT- Basic window.
8 Run SPD. Specify the BSDL input file for the device for which you
developed the modified test, and the VCL output file. Add comments as
you progress to annotate your process for examination later.
9 From the Macros menu, select Include File. In the Users Input Area, type:
temp
SPD will read the file and generate the necessary vectors for the VCL
output file. When SPD has stopped running, you can continue to
develop the device test.
10 When you have completed the test, exit SPD.
You can now print the VCL output file and examine the new code.

3 Scan Port Driver
Getting The Source Code Into Your Board Test

When you specify the path of the VCL output file in the I/O Specification
Form, you should give the path to your board test directory. Then the VCL
source code file that SPD generates will automatically be included in the
proper directory.
Because SPD generates a digital source code, the file is given the type src
(source) digital and checksummed, so it is complete and ready to be
compiled. The first line (identified by exclamation marks !!!!) in the sample
source code includes a code that tells the tester the file is a digital source
code. This line is included with all VCL output files for the Agilent
In- circuit Test System.

Scan Port Driver 3
Sample VCL Source Code File

Example 3- 3 shows the test program generated for the sample device
74bct8374, a single device.
Note that the line numbers on the left do not appear in the actual
NOTE
source code; they have been added here to aid in explaining the
contents of this file.
• VCL Source Code Explained

• Sample Device 74bct8374
Example 3-3 Sample VCL Source Code for Boundary-Scan Device 74bct8374
!!!! 6 0 1 661727748 V38fe
1 ! VCL code created from BSDL (Version 0.0) file 74bct8374
2 ! Date: Mon Dec 03 08:44:32 1990
3 ! IEEE Std 1149.1-1990
4
5 !! Writing code for Agilent In-circuit Test System
6
7 ! Parameters for Entity TTL74BCT8374:
8 ! Instruction Length 8
9 ! Boundary Register Length 18
10 ! Device Inputs 10
11 ! Device Outputs 8
12 ! Device Bidirectionals 0
13
14 sequential
15
16 family TTL !! Warning, Defaulted family
17 device 'u105'
18 ! The following assignments are derived from Pin-Mapping DW_PACKAGE
19
20 assign CLK to pins "1"
21 assign D_01 to pins "23"
28 assign D-08 to pins "15"
29 assign GND to pins *
30 assign OC_NEG to pins "24"
31 assign Q_01 to pins "2"

3 Scan Port Driver

39 assign TCK to pins "13"
40 assign TDI to pins "14"
41 assign TDO to pins "11"
42 assign TMS to pins "12"
43 assign VCC to pins *
44
45 power GND, VCC
46 inputs CLK, D_01, D_02, D_03, D_04
47 inputs D_05, D_06, D_07, D_08, OC_NEG
48 inputs TCK, TDI, TMS
49 outputs Q_01, Q_02, Q_03, Q_04, Q_05
50 outputs Q_06, Q_07, Q_08, TDO
51 !
52 vector cycle 400n
53 receive delay 300n
54
55 pcf order default Parallel is TCK, TMS, TDI, TDO
56 pcf order default Parallel
is CLK, D_01, D_02, D_03, D_04
is D_05, D_06, D_07, D_08, OC_NEG
is Q_01, Q_02, Q_03, Q_04, Q_05
59 pcf order default Parallel is Q_06, Q_07, Q_08
60 !
61 pcf order Scan is TCK, TMS, TDI, TDO
62
63 ! Column-to-signal Map, signals 1 to 22
64 ! TTTTCDDDDDDDDOQQQQQQQQ !
65 ! CMDDL________C________ !
66 ! KSIOK_________________ !
67 ! 00000000N00000000 !
68 ! 12345678E1245678 !
69 ! G !
70 ! !
71 !! This is the beginning of the TAP Controller reset routine.
72 UNIT "Scan_Test" ! Vector 1
73 pcf
74 use pcf order Parallel
75 "01ZXZZZZZZZZZZXXXXXXXX"
76 use pcf order Scan
77 "11ZX"
78 "01ZX"
79 "11ZX"
80 "01ZX"
81 "11ZX"
82 "01ZX"
83 "11ZX"
84 "01ZX"

Scan Port Driver 3
85 "11ZX" ! Test-Logic-Reset
85 ! Current instruction BYPASS (11111111), target register BYPASS[1].
87 "00ZX"
88 "10ZX" ! Run-Test/Idle
92 "11ZX" ! Select-DR-Scan
93 "01ZX"
94 "11ZX" ! Select-IR-Scan
95 "00ZX"
96 "10ZX" ! Capture-IR
97 ! Instruction register loaded with 10000001 (BYPASS)
98 "00ZX"
99 "10ZX" ! Shift-IR
100 "000H" ! 0
101 "100X"
102 "000L" ! 1
103 "100X"
104 ! Vector 25
105 "000L" ! 2
106 "100X"
107 "000L" ! 3
108 "100X"
109 "000L" ! 4
110 "100X"
111 "000L" ! 5
112 "100X"
113 "000L" ! 6
114 "100X"
115 "010H" ! 7
116 "110X" ! Exit1-IR
117 "01ZX"
118 "11ZX" ! UPDATE-IR
121 ! Current instruction EXTEST (00000000), target register BOUNDARY [18]
122 "11ZXZZZZZZZZZZXXXXXXXX" ! Select-DR-Scan
125 "10ZX" ! CAPTURE-DR
127 "00ZX1010101010XXXXXXXX"
128 "10ZX1010101010XXXXXXXX" ! SHIFT-DR
129 ! Target BOUNDARY[18] = 1001010101XXXXXXXX
130 "001XZZZZZZZZZZXXXXXXXX" ! 0
132 "101X"
133 "000X" ! 1
134 "100X"
135 "001X" ! 2
136 ! Vector 50

3 Scan Port Driver
137 "101X"
138 "000X" ! 3
139 "100X"
140 "001X" ! 4
141 "101X"
142 "000X" ! 5
143 "100X"
144 "001X" ! 6
145 "101X"
146 "000X" ! 7
147 "100X"
148 "00ZH" ! 8
149 "10ZX"
150 "00ZL" ! 9
151 "10ZX"
152 "00ZH" ! 10
153 "10ZX"
154 "00ZL" ! 11
155 "10ZX"
156 "00ZH" ! 12
157 "10ZX"
158 "00ZL" ! 13
159 "10ZX"
160 "00ZH" ! 14
161 "10ZX"
162 ! Vector 75
163 "00ZL" ! 15
164 "10ZX"
165 "000L" ! 16
166 "100X"
167 "01ZH" ! 17
168 "11ZX" ! EXIT1-DR
169 ! Target BOUNDARY[18] = X0XXXXXXXX01010101
173 "11ZX" ! Update-DR
175 "01ZXZZZZZZZZZZLHLHLHLH"
176 "11ZXZZZZZZZZZZXXXXXXXX" ! Select-DR-Scan
178 "01ZX"
179 "11ZX" ! Select-IR-Scan
183 "11ZX" ! Test-Logic-Reset
184 ! Current instruction BYPASS (11111111), target register BYPASS[1]
185
186 end pcf
187 end unit ! Scan_Test Vector 88
188

Scan Port Driver 3
189 ! Vectors with TDI High: 8, (3.2e-06 sec)

190 ! Vectors with TDI Low: 26, (1.0e-05 sec)
191 ! Total time for test: (3.5e-05 sec)
VCL Source Code Explained

Lines 1-17
These lines contain header information and the device description. They
tell you what entity and tester the code was written for. They also tell you
if a library or an executable source code was written.
If any design warnings were included in the BSDL input file, they will also
appear in this section. Design warnings appear just before the Writing
code for xxx line (line 5). Example 3- 3 does not include a warning. If
your device does include a warning, it will appear in the VCL source code
in this format:
!!!
!!! Design Warning found in BSDL description
!!!
!!! Design warning text body
!!! . . .
!!! . . .
!!!
!!! End of Design Warning
!!!
Lines 18-53
These lines contain the normal VCL declaration statements where pins,
power, inputs, and outputs are assigned.
Lines 55-61
These lines contain the PCF order statements that describe how the
signals are organized in a PCF vector. The PCF order can be parallel for
TAP signals, and device inputs and outputs, or scan for TAP signals only.
Lines 63-71
These lines contain comments that, when read vertically, tell you the
names of the signals; the lines are a column- to- signal map. You can copy
and move this map as you like, so that you can read another part of the
code more easily.

3 Scan Port Driver
Lines 72-85
These lines contain ten vectors that initialize the device and place the
device in the TEST- LOGIC- RESET state. The current instruction is BYPASS
and is loaded by the device hardware. Note that if the device features an
identification register, the current instruction will be IDCODE.
Lines 87-88
These lines contain the TAP signals to move the device to the
RUN- TEST/IDLE state. Note the TMS sequence: on the rising edge of TCK
(logic 1 on line 88) TMS is a logic 0, which moves the TAP Controller to
the RUN- TEST/IDLE state.
Lines 89-97
These lines contain the code that moves the TAP controller to the
CAPTURE- IR state. The IEEE Standard mandates that a bit pattern be
loaded into the Instruction Register by the IC each time you pass through
CAPTURE- IR. The data found in the devices BSDL source code, under the
Instruction_Capture attribute, provide the code (10000001 or BYPASS in
this case) to be loaded by the device into the Instruction Register.
If you look at the BSDL source code for the sample device (see Sample
BSDL Description on page 2- 68), you will see this bit pattern in the
Instruction_Capture attribute. This pattern is also shown as a comment in
the VCL source code (line 97).
Lines 98-118
These lines contain the code that loads the EXTEST instruction and shifts
out the BYPASS instruction 10000001. Notice that TMS is a logic 0 all
during the SHIFT phase.
At lines 116- 118, TCK goes high and with TMS a logic 1, which moves the
TAP Controller to EXIT1- IR and then to UPDATE- IR where the instruction
bits latch onto the instruction decode part of the Instruction Register and
become the current instruction.
Lines 119-129
These lines contain code that sets up the pcf order for the data to be
applied to the inputs and captured, that was defined by the test developer.
EXTEST is in effect, and the instruction targets the Boundary Register.
These bits are latched onto the input cells of the Boundary Register in
this example.
Notice that the drivers are off at lines 120 and 122, turned on at lines 127
and 128 to drive in the data bits, then turned off again at line 130, for a
total duration of two vectors. This reduces the overdrive time on upstream
devices.

Scan Port Driver 3
Lines 130-168
These lines contain the code that shifts the data bits through the target
register. You can see how the data is shifted through the register by
looking at the code on line 129 and comparing it to the bits shifted out at
each line.
For example, at line 130 you see the first "X" bit
"001XZZZZZZZZZZXXXXXXXX" that is shifted out TDO. TCK is low (0) and
TMS is low (0). You can follow the shifting of all subsequent bits line by
line.
The lines commented from ! 0 to ! 17 show the bits shifted out TDO. If
you look at Figure 3- 7 you can see that these comments (0- 17) map
directly to the cells in the Boundary Register for this device.
At line 132, you see the first 1 bit 001X that is shifted in TDI to the
register. TCK is high (1) when these bits are shifted in. Because the
instruction in effect here is EXTEST, the test developer specified the bits
when the interface asked for eight states to be received from the outputs.
If you examine the TDI bit starting at line 132, you will see when you
reach line 147 that the pattern entered was 10101010. Remember that the
TDI data is valid for two vectors, and the TDO data is valid for one vector,
as illustrated by the timing diagram in Figure 3- 4 on page 3- 21, but that
TDI data is only shifted in when TCK is high (1) and TDO data is only
shifted out when TCK is low (0). In subsequent vectors, shown by lines
150- 167, this bit pattern is shifted out TDO and measured at line 175.
Figure 3- 7 shows cell 16 is a control cell. If you look at line 166 of the
VCL code you see that 0 is shifted in; before this point, Zs have been
shifted in. The 0 shifted in here enables the output drivers so the data
present at the outputs can be sent out in parallel as shown by lines
169- 175.
Lines 169-175
These lines contain the code that tells the tester what should be measured
on the parallel outputs of the device. The data bits are loaded onto the
parallel outputs of the target register (Boundary Register for this
example), then latched out for examination. Note that the bits in the
example code (see lines 169 and 175) appear to be ordered. You should
understand that these bits might be scrambled for other devices,
depending on the construction of the Boundary Register and its mapping
to I/O pins.
Lines 176-184
These lines contain the code that places the TAP controller back into the
TEST- LOGIC- RESET state.

3 Scan Port Driver
Lines 186-187
These lines mark the end of the pcf block and unit.
Lines 189-191
These lines contain information that tells you how often and for how long
TDI is held at high and low states for this device test. You can use this
information to manually modify your safeguard files to safely run this test
when you overdrive an upstream device’s TDO signal.
Sample Device 74bct8374
Figure 3-7 Device Used for Sample VCL Source Code

74BCT8374 DW PACKAGE
D8 15 8 D Q 0 10 Q8
D7 16 9 D Q 1 9 Q7
10 2
D6 17 D Q 8 Q6
D5 19 11 D Q 3 7
Q5
D4 20 12 D Q 4 5
Q4
4
D3 21 13 D Q 5
Q3
D2 22 14 D Q 6 3 Q2
2
D1 23 15 D Q 7 Q1
OC- 24 16
CLK 1 17
Instruction
Register 11
TDO
TDI 14
13 12
TCK TAP Controller TMS

3 Scan Port Driver

Uploaded by

Copyright:

Available Formats

3 Scan Port Driver

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

3 Scan Port Driver

Uploaded by

Copyright:

Available Formats

Medalist i3070 In-circuit Test System

3-2 Boundary-Scan Testing

How SPD Works

Figure 3-1 Test Generation by SPD

BSDL Source File

Scan Port Driver (SPD)

VCL source code

Boundary-Scan Testing 3-3

The SPD Menus

3-4 Boundary-Scan Testing

The SPD Workspace

Figure 3-2 SPD Workspace

Tap Controller State Diagram

User Text Input Area

SPD Status Area

Boundary-Scan Testing 3-5

• Pending Instruction. The instruction that will become the current

SPD TAP Controller State Diagram

SPD User Text Input Area

3-6 Boundary-Scan Testing

Whenever you run SPD from the Developer Interface or Test

Run SPD from a BT-Basic Window

Boundary-Scan Testing 3-7

Using SPD Macros

3-8 Boundary-Scan Testing

It is recommended that you execute this test before developing any

Boundary-Scan Testing 3-9

User Code Test

3-10 Boundary-Scan Testing

When the source code is sent to the development software, units

Boundary-Scan Testing 3-11

Whenever you plan to execute the Extest macro or other lower-level

Message displayed in User Input Area:

3-12 Boundary-Scan Testing

If your device has bidirectional pins, this message is displayed:

Setup & Disable

Boundary-Scan Testing 3-13

Message displayed in User Input Area:

3-14 Boundary-Scan Testing

Boundary-Scan Testing 3-15

Using the TAP Controller State Diagram

3-16 Boundary-Scan Testing

Figure 3-3 Tap Controller State Diagram

Boundary-Scan Testing 3-17

If your device has bidirectional pins, the message displayed is:

3-18 Boundary-Scan Testing

SHIFT-IR and EXIT1-IR

Boundary-Scan Testing 3-19

TAP Signal Changes

3-20 Boundary-Scan Testing

CAPTURE-DR SHIFT-DR EXIT1-DR

TDI VALID VALID VALID

VALID = Valid Data Bit

Boundary-Scan Testing 3-21

Figure 3-5 Block Diagram of a Boundary-Scan Device

Test Data Registers

Device Inputs Device Outputs

Device Identification Register

TDI Instruction Decode