Keysight i3070 In-Circuit Test System

Digital Testing

Digital Theory and Testing

Digital Testing Overview 1-2

BT-Basic Statements Used In Digital Testing 1-10
Running Digital Tests 1-12
Safeguard Protection 1-14
Power Monitoring Circuit 1-21
1 Digital Theory and Testing

Digital Testing Overview

The i3070 In-Circuit Test System tests a digital circuit by:
• applying a known set of test patterns to the circuit's inputs
• monitoring the responses from its outputs
The system compares the actual responses it receives to a set of expected
responses. If they are the same, the circuit passes the test; if they are different, the
circuit fails.

Testing Devices and Clusters

The digital part of the testplan consists of a series of test statements, each of which
causes one device or circuit, (called a cluster) to be tested. The actual in-circuit for
each digital device or cluster resides in the test files for the PC board under test.
The standard i3070 In-Circuit Test Software includes a library of digital tests for
over 5,000 ICs. If you need to test circuits or devices that are not in the standard
library, you must write those tests and save them in a custom library. A custom
library is structured like the standard library, but the tests in it can be modified.
The testing process works as follows:
1 You to input information about the digital devices and clusters on the board —
their names, the nodes they are connected to on the PC board, and the names
of the library files that contain their tests.
2 Based on the information, the i3070 In-Circuit Test Software automatically
generates the required tests from the libraries. It does the following:
• evaluates electrical interactions
• modifies the tests as appropriate
• saves the modified, executable tests
3 The software then assigns the system resources (such as drivers and receivers)
and generates the fixturing information.
4 Finally, the software writes the testplan, which will contain a test statement for
each digital in-circuit test.
For more information, see:
• Testing a Device
• Types of Digital Tests
• Example Board Test

1-2 Digital Testing

 Digital Theory and Testing 1

Testing a Device
The circuit diagram in Figure 1-1 shows how a device is connected to the test
system for testing. This also applies to clusters, because they are tested the same
way. The testhead contains drivers and receivers that connect to the device under
test through the fixture.
To simplify the figure, the drivers are shown as amplifiers, D1 through D4, and the
receivers are shown as exclusive-OR gates, R1 and R2. The drivers drive signals to
the device under test, and the receivers receive signals from the device under test.

Figure 1-1 System circuits access the device through the fixture
Device Under Test

Fixture Probe

PCB Under Test

Test System

Actual
Receive
D1 States Receivers
Pass/Fail
R1
D2
Drive
States Pass/Fail
D3 R2
0 = Pass
Expected 1 = Fail
D4 Receive
Drivers States

The receivers are comparators that receive each actual state and compare it to an
expected state to determine whether the device has passed or failed the test. The
states to be driven to the device (the drive states) and the states that are expected
to be received (the expected receive states) are combined in the test into
bit-patterns are referred to as vectors. Each time a vector is to be applied, the
system sets up the drivers to drive the required states and the receivers to expect
the required states. The system then applies the vector by first strobing the drivers
and then, a short time later, strobing the receivers.
For more details, see:
• Applying Vectors
• Timing in Vectors
• Cyclic Redundancy Checks (CRCs)
• Overdriving

Digital Testing 1-3

1 Digital Theory and Testing

Applying Vectors
Following is a partial set of vectors that could be used to test the device shown in
Figure 1-2 on page 1-4. In this example, the vectors are named Vector 1,
Vector 2, and so on through Vector n; the states in each vector are listed
horizontally. The first four columns represent the sequence of states to be driven to
the device. The last two columns represent the states the system expects to receive
from the device in response to the driven states.
D1 D2 D3 D4 R1 R2
Vector 1: 1 0 1 1 1 0
Vector 2: 0 0 1 0 1 1
. . . . . .
. . . . . .
Vector n: 1 1 1 1 0 0
To test the device, the vectors are applied to it in sequence. In its simplest form, a
vector consists of a set of bits (1s and 0s). Each vector has two parts: a pattern of
bits to send in parallel to the device, and the pattern of bits it expects to receive in
response from the device. In the example, the first four bits are sent via drivers D1
through D4, and the fifth and sixth bits are received by receivers R1 and R2.

Timing in Vectors
Figure 1-2 on page 1-4 shows the timing for each vector. The first vector starts at
time t0; the drivers are strobed and the bits are sent, in parallel, to the inputs of the
device. After a short delay to allow the device to settle, the receivers are strobed, at
time t1, to receive the actual responses from the device and compare them to the
expected responses contained in the vector in the device test. The next vector then
starts at time t2.
The delay between driving and receiving is referred to as the receive delay. The
length of the vector, that is the time between driving one vector and the next, is
referred to as the vector cycle time. At the end of the vector, the next vector starts.
Both the vector cycle time and the receive delay are programmable.
Once the drivers are strobed, they maintain their states until the next vector starts.
After the receive delay, the receivers return pass/fail information to the controller.
If a failure occurs, what happens next depends on the statements in the testplan.

Figure 1-2 Timing in a vector

Vector 1 Vector 2

Vector Cycle Time

Receive Delay

t0 t1 t2 t3

Strobe Strobe Strobe Strobe

Drivers Receivers Drivers Receivers

1-4 Digital Testing

 Digital Theory and Testing 1

Cyclic Redundancy Checks (CRCs)

If you have to test a device that is sufficiently complex that it is not practical to
predict the responses to the bit patterns, then you can use CRCs (Cyclic
Redundancy Checks). An example of a device you might want to use CRCs on is a
pre-programmed memory device like a PROM or Flash RAM. To generate CRCs, the
vector bit patterns are sent to the device’s input pins on a known-good board and
the output pin responses are collected and algorithmically compressed and stored
in the test object file. When a production board is tested, the same vectors applied
to that device should produce the same CRCs. If they do not, the device is failed.

Overdriving
The drive states are sent to a device by a technique referred to as overdriving; it is
sometimes called backdriving or pulsing, but all three terms refer to the same
process. Overdriving enables you to do an in-circuit test on the device: that is, to
isolate the device electrically from the effects of upstream devices so that you can
test the device without removing it from the circuit.
Overdriving implies driving each input pin of a device with a high current, narrow
pulse. The purpose of using a high current pulse is to overcome the states on the
outputs of any other devices that are connected to the input pin being driven. This
effectively isolates that input pin from the devices that normally drive it; the state
of that pin is determined only by the driving pulse, regardless of the states of any
overdriven outputs connected to that pin. While the pulse is applied, the overdriven
outputs must sink (or source) the high current. The purpose of using narrow pulses
is to help prevent pins from being overdriven too long and subsequently damaged
by heat.
Overdriving upstream devices can be used with node library testing as well as with
device testing.
As well as using very narrow pulses to protect overdriven devices, each test also has
a built-in timeout that prevents the test from running too long to prevent damage
to the upstream device. The timeout for each test is calculated individually, based
on the actual topology of the PC board being tested. During the board test
generation process, the Keysight SAFEGUARD safety analysis routines use the data
in the board file and the safety data for each device in the library, to set a time that
each device test can run without damaging any overdriven devices (refer to
Safeguard Protection on page 1-14).
One disadvantage of overdriving is that supplying large currents tends to degrade
high-speed signals. Therefore, do not overdrive pin cards that are designed for
higher-speed applications. If required, on Mux systems, different combinations of
cards can be installed to meet individual requirements.

Digital Testing 1-5

1 Digital Theory and Testing

Types of Digital Tests

Digital tests can be written to achieve different objectives and can be structured in
different ways. However, within the test system itself, there are only two sets of
criteria to distinguish between the different types of tests. The test is either:
• An in-circuit test
• A pin-oriented test or a node-oriented test
If the inputs/outputs of the device or circuit are identified by pin numbers, the
test is pin-oriented; if they are identified by the node names on the PC board,
the test is node-oriented.
Pin-oriented tests are intended to be reusable and used in many board tests.
Node-oriented tests are intended to be used only once, on a specific device or
cluster in a specific board test.
Most tests fall into two categories: tests for devices and tests for clusters.
• device tests are defined as in-circuit, pin-oriented tests
• node library tests are node-oriented tests
Regardless of the test type, a test is generally saved in a library file. A library file is
any file that contains a digital test that is compiled with the library option. The file
can be located anywhere in the file system. A library test cannot be executed — it
serves as a model that the automatic program generators can read to generate an
executable version of that test.

In-Circuit vs. Node Library Tests

In the test system, the term in-circuit implies that the test is for a real device, usually
an IC device that is attached to a printed circuit board.
A node library test is a digital test that encompasses multiple digital devices. The
node library test defines nodes on a printed circuit board that tests a function of that
board. Another way to define a node library test is through the use of a “black box”.
A “black box” is a portion of the board’s circuitry that has inputs and output. These
inputs and outputs can go to or come from several digital devices.
Node library tests are complicated to write and understand. They are custom
tests that are outside the realm of normal “in-circuit” testing. It is recommended
that if you define any node library tests on the board, keep the number of
devices in the cluster to a minimum.

The following summarizes the differences between the two types of tests, and the
reasons for making them.
• In-circuit test
Device test of a digital component on the printed circuit board. This test is
written such that it can be used across multiple boards.

1-6 Digital Testing

 Digital Theory and Testing 1

• Node library test

A digital test that encompasses multiple devices. The test can be described by
using either pins of a “black box” devices or as node names on the board. This
type of test is generally specific to a single board.
The processes for entering digital tests and creating custom library tests are
described in Test Development Process.

Preconditioning
When a test for a device or cluster is generated, surrounding devices must be
disabled or conditioned if they would otherwise interfere with that test. To
determine how to precondition these devices, the program generators look for
preconditioning data in the library tests for those devices. The individual devices in
a cluster can be preconditioned, provided their in-circuit library tests contain
preconditioning information, but the cluster itself cannot be preconditioned.

Location of Executable Tests

During the test generation process, when the executable versions of the tests are
generated, the tests are placed in different directories under the board directory. An
in-circuit test is placed in a file under directory digital; the file has the device
name that was entered in the i3070 In-Circuit Test Software — for a device, this is
usually the reference designator. For example, if the designator for the device is
U232, the executable test is placed in the file, digital/u232.
Even when the test is for a cluster, it is treated as an in-circuit test and placed under
the digital directory.
The digital part of a mixed test has to be paired with the analog part and is saved
under a separate directory, mixed.
For more information on mixed tests, see Mixed Tests on page 2-76.

Example Board Test

Figure 1-3 shows a simple PC board. Assume that each gate is a separate device
and that an in-circuit test for each device exists in the system library. The nodes on
the board are named A through I.
The tests that could be performed on this board include:
• Individual in-circuit tests for each device
• A node library test
The node library test is included only if it is necessary to ensure that the two
components worked together properly.

Digital Testing 1-7

1 Digital Theory and Testing

Figure 1-3 Example board test strategy

BOARD Node Library

A 1 2 F 1 H I
U1 U2 4 1 2
2 U3
EN
3
B
Fixture Probes

C 1 U4 2 G

D 1 U5 3
EN
2
E

Table 1-1 contains summaries of each of the tests that could be performed. The test
system is set to combinational mode to generate these tests.

Table 1-1 Board test summary

Test Description
U1 in-circuit device test
pin-oriented — U1.1, U1.2
no effect on other devices
U2 in-circuit device test
pin-oriented — U2.1, U2.2, U2.3, U2.4
overdrive — U1.2, U4.2
safeguard — U1, U4
disable — U5
U3 in-circuit device test
pin-oriented — U3.1, U3.2
upstream disable — U2, U5
safeguard — U2, U5
U4 in-circuit device test
pin-oriented — U4.1, U4.2
no effect on other devices
U5 in-circuit device test
pin-oriented — U5.1, U5.2, U5.3
disable — U2

1-8 Digital Testing

 Digital Theory and Testing 1

Table 1-1 Board test summary (continued)

Test Description
Node library node library test
node-oriented — F, B, C, H
overdrive — U1.2
safeguard — U1
disable — U5
Board node library test
node-oriented — A, B, C, D, E, I

Digital Testing 1-9

1 Digital Theory and Testing

BT-Basic Statements Used In Digital Testing

BT-Basic statements generate the digital device and node library tests. BT-Basic
statements are also used in the testplan to run and control the tests, and to
establish the environment in which they operate.
The BT-Basic statements most commonly used with digital tests are described in
Table 1-2, Table 1-3, and Table 1-4.

Table 1-2 Digital editing statements

Statement Description
compile Compiles the VCL program. If you specify the library option, the object
(compiled) code is placed in a file in a digital library. If you do not specify
library, then executable object code is produced, and placed in a file under
the board test directory. Also use the debug and map options if test data is
required for debugging purposes.
d igital Selects digital mode, which clears the workstation workspace and turns on
VCL syntax checking. This mode is used only for writing and editing digital device
and node library tests. After compiling, the tests are run by the BT-Basic test
statement.
load board Use this statement to load the board data from the board test files into the system
memory before running any tests.
safeguard Selects safeguard mode. Clears the workspace and turns on SAFEGUARD
syntax checking.

Table 1-3 Digital test setup statements

Statement Description
acknowledge all failures, These statements specify that, if a device test fails, the failures are
acknowledge d igital failures reported. acknowledge all failures applies to all types of
tests; acknowledge digital failures applies only to
digital (VCL) tests. In either case, if a digital test fails, the test
halts and program control returns to the testplan (see the halt
statement).
cps, sps, dps These three statements, respectively, connect DUT power
supplies, set up the required voltages, and turn off the power
supplies and disconnect them.
ignore all failures, These statements, respectively, turn off acknowledge all
ignore d igital failures failures and acknowledge digital failures (if on) so
that, if a failure occurs, error reporting does not occur. As before,
if a failure occurs during a digital test, the test halts and program
control returns to the testplan (also see the halt statement).

1-10 Digital Testing

 Digital Theory and Testing 1

Table 1-3 Digital test setup statements (continued)

Statement Description
powered Prepares the test system to test devices and circuits with power
applied to the board under test. The unpowered statement is
used mostly for passive testing of analog components.
safeguard <type> Establishes the SAFEGUARD protection level (none, cool,
digital or all) to be used during a digital test.

Table 1-4 Digital test control statements

Statement Description
learn on/off Sets a learn flag before running a test. The program learns the CRCs
for any digital test that contains VCL compress statements, and stores
the result (for future testing) with the object code for the test. (Also used to
learn some analog tests.)
test Loads the object code for a VCL test into memory and starts the test.
test cont Continues executing a digital test that was halted or paused. You cannot
continue a test that stopped because of an error.

Digital Testing 1-11

1 Digital Theory and Testing

Running Digital Tests

A digital device or node library test is executed by the test statement. When test
is executed, it loads the object code for the selected device test into memory and
runs that test. When the test is finished, control returns to BT-Basic — to the
command line if you are running the tests individually, or, if you are running the
testplan, to the statement immediately following the last test statement that was
executed.
In the testplan, the test statements for the digital, in-circuit device tests are placed
by the program generator in a subroutine called Digital_Tests.
The call statements that call these subroutines are preceded by the general
purpose statements, which prepare the test system to do digital testing. These
include the setup statements listed above, such as powered and acknowledge
digital failures, and statements to set the power supplies for the board under
test to the proper voltage, and to turn them on, such as cps and sps. Other setup
activities, such as loading the board data (load board) and turning on the fixture
vacuum (faon, fbon, etc.) are usually placed before the shorts tests in the testplan.
The testplan is a BT-Basic program, and it can be run like any other program — that
is, brought into the workspace (get or load statement) and then run (run
statement). In the board test environment, the program is usually started
automatically by autofiling software, which reads a code from the fixture to
determine which program to load and run.
If any of the digital device tests use CRCs (Cyclic Redundancy Checks), then they
must be run the first time with the learn flag on (see the learn statement) to learn
the CRCs. Once the CRCs have been learned, learning remains off while the boards
are tested.

Debugging Digital Tests

If the test fails when it is run, the test could be wrong, the device under test could
be faulty, or there could be something on the board or fixture that is causing the
device to apparently fail.
If a test fails, debug the executable test and make changes to the VCL source code
if necessary.
If the test does not compile, messages from the compiler tell you why. Usually the
problem is a syntax error or inconsistent values being specified. If the test compiles
but fails to run properly, then use the digital debug software to determine the cause
of the failure. The debug software displays test data either as waveforms or as a
series of bits (e.g., using 1, 0 and X). If the test was compiled with the debug option,
then data correlating the numbers of the executed vectors with the numbers of the
vectors as they were defined in the test will be available to the debug software.
For more information on debugging, see Debugging Digital Tests.

1-12 Digital Testing

 Digital Theory and Testing 1

You can use the debug software to look at the expected and actual state changes
on the input and output pins. You can also temporarily change many of the test's
parameters, such as the vector timing, and, as long as you do not exit debug, rerun
the test without recompiling it.
As well as using debug, you can use the halt and pause statements in the VCL test,
and the test cont statement in the testplan, as aids in debugging the test. Also,
the sync parameter can be used in the test to synchronize an oscilloscope so that
you can observe waveforms, rise times, etc. Other BT-Basic statements that are
helpful in debugging include ignore digital failures, and safeguard none or
safeguard cool; however, care should be exercised if safeguarding is turned off
because of the possibility of damaging the board under test (see Safeguard
Protection on page 1-14).
When debugging, if you make any permanent changes to a digital test, that test
must be re-compiled. You can recompile the test or you can allow the i3070
In-Circuit Test Software to do the compiling. You can run the recompiled test (test
statement) without loading the complete board data again (load board statement)
as long as no changes were made to the board topology data. If there are any
topology changes, then you must reload the board data.

Updating Existing Tests

If an existing board test is changed, it may be necessary to update and recompile
supporting files. Because of this, it is best to allow the i3070 In-Circuit Test
Software to make the changes to the files rather than doing it manually.
If you change a digital test, you must make the changes to the VCL test – but again,
you should use the automatic software to make the necessary changes to the board
test.
Do not forget to relearn the CRCs if any test that uses them changed.

Digital Testing 1-13

1 Digital Theory and Testing

Safeguard Protection
If testing is not properly controlled, it can place abnormal stress on the devices that
are immediately upstream of the device under test — that is, devices connected to
the inputs of the device under test that must be overdriven. Devices that are
overdriven are subject to potential damage from overheating. Keysight
SAFEGUARD safety analysis protects your PC boards from such damage.
This section covers:
• What is SAFEGUARD?
• SAFEGUARD Analysis and Implementation
• SAFEGUARD Files
• SAFEGUARD Statements

What is SAFEGUARD?
The safety protection is an automatic feature of digital testing on the i3070
In-Circuit Test System. It establishes time limits for tests, thus guarding against
accidental damage to you PC board, caused by overstressing overdriven devices.
The time limit is referred to as a timeout; it automatically stops the test if the time
limit is reached. Rather than dictating some arbitrary limit on the time that tests can
run, the SAFEGUARD safety analysis routines calculate a separate time for each
digital test.

Test Timeout
To calculate a realistic timeout for each test, the safety routines consider the
physical characteristics of each device being overdriven and the topology of the PC
board. From this data, they calculate a safe time that the test can run (i.e., without
damaging overdriven devices). The safety routines also calculate an estimated
normal time that the test is expected to run. The normal time (plus a small margin
for error) then becomes the timeout, unless it is longer than the safe time, in which
case the test is inhibited from running. When a test is inhibited, you can run it if you
first specify safeguard cool or safeguard none.
Inhibited tests can be run if you execute safeguard none or safeguard cool; the
latter enforces cooldown delays between tests. However, if you execute either
statement, it is your responsibility as the test developer to ensure that the tests
do not damage devices on the board.

There are two timeout timers in the test system: the safeguard timer just described,
and a watchdog timer. The safeguard timer starts any time a digital test is run,
unless safeguard none or cool was specified. The watchdog timer is set to
approximately one and a half times the safeguard timer. It always starts when a
digital test is run, regardless of the safeguard status.

1-14 Digital Testing

 Digital Theory and Testing 1

Cooldown Delays: Normal & Steady State

In addition to the timeout calculations, the safety analysis routines also calculate a
delay time to allow devices affected by a test to cool down before they are again
stressed by the next test. The delays are automatically inserted between device
tests and are referred to as cooldown delays.
There are two types of cooldown delays: normal delay and steady state delay.
Steady state delay is usually longer than normal delay. It is used if a test is repeated.
Otherwise the normal delay is used between tests.

SAFEGUARD Analysis and Implementation

The SAFEGUARD data for each device is contained in SAFEGUARD files in the
digital device libraries (see SAFEGUARD Files on page 1-16). This data
characterizes the physical characteristics of the device, based on data published by
the manufacturer of the device. (Refer to the individual statements under
SAFEGUARD Statements on page 1-19 for more details about the characteristics.)
During the board test generation process, the program generators gather the safety
data for the digital devices on the PC board. No data is gathered for any device that
has safeguard turned off in the i3070 In-Circuit Test Software. The data is then
saved in file safeguard under the board test directory (the file is created
automatically if it does not already exist). An error occurs if safeguard is on for a
digital device on the board but there is no safety data for that device. If you need
to, you can edit and change file safeguard before it is compiled, into safeguard.o
(see SAFEGUARD Statements on page 1-19 for information about the statements).
When the digital device and node library tests are compiled, the SAFEGUARD
safety analysis routines extract safety-related data from the following files: board.o,
safeguard.o, wirelist.o, and the executable test objects.

See:
• Inhibited Tests
• Dealing with Inhibited Tests

Inhibited Tests
The safety analysis calculates the timeout for each test, based on the device, or
cluster of devices, being tested, and on the surrounding devices. If the test is too
long to safely overdrive upstream devices, it is inhibited, in which case you may
need to alter the test.
There are several other reasons why a test can be inhibited. If the test affects
non-digital devices, such as FETs and transistors which potentially could be
damaged, again SAFEGUARD inhibits the test. (Items identified as nondigital in the
test itself do not cause the test to be inhibited.) Also, a test is inhibited if it would
cause unsafe levels of current to be driven through a device pin.

Digital Testing 1-15

1 Digital Theory and Testing

If the normal test time cannot be calculated, because of pauses or uncounted

loops, or, in the case of a mixed test, because an analog test is to be run, then the
test itself must specify the estimated time, otherwise the test is automatically
inhibited. An estimated test time must also be specified in the test if the test has a
DUT clock running on a pin that can overdrive. (Refer to Test Time on page 3-7 for
more information.)

Dealing with Inhibited Tests

Even though a test is inhibited, it is still generated and can be executed provided
that you, as the test developer, add the appropriate BT-Basic safeguard <type>
statements to the testplan. The options for the statement are described in Table 1-5
on page 1-20.
Unless you fully understand the characteristics of your devices, we recommend that
you do not change the SAFEGUARD file for a board test. If you decide to do so, then
you must ensure that the device itself, and the surrounding digital and non-digital
devices, are not subject to excessive current. Things to consider are the length of
time each test runs, the length of time that a steady 1 or 0 state is maintained over
many vectors (drivers are not three-stated between vectors), and the duration of
the vector (VCL vector cycle statement).
In the VCL test, device input pins that are not required for a particular vector should
not be specified in that vector. This ensures that the drivers to those pins are
three-stated until the pin is required again for testing. However, a pin is not
three-stated if some other default state was specified in the assign statements at
the beginning of the VCL test.
If a test is inhibited because of an upstream part, and that part cannot be disabled
for any reason, try to set that part to states that will at least minimize the possibility
of damage. With many device families, one state usually requires less current to
overdrive than the opposite state. For example, TTL outputs can be set to the 1
state. When overdriving a TTL device, it takes less current to force a 1 state to a 0
than it takes to force a 0 to 1.
Many factors combine to affect the time that a device pin might be overdriven.
Among other things to consider in the VCL test are the presence of pause, halt,
delay for cooling, or disabled statements, the voltage levels on the pins,
together with the slew rate, and whether the test is to be recycled, etc.

SAFEGUARD Files
The SAFEGUARD files contain the safety data used by the compiler to calculate safe
test times for digital tests, to inhibit digital tests, and to determine the appropriate
delays to place between digital tests. The SAFEGUARD data consists of
package-dependent parameters that describe the susceptibility of a particular
package and device class to damage from overdriving.

1-16 Digital Testing

 Digital Theory and Testing 1

Each of the library directories that contain in-circuit, digital device tests has a
SAFEGUARD source file, called safeguard, together with its compiled object file
(safeguard.o). This file must contain the SAFEGUARD data for every device test in
that directory. The test generators look for that data for each device; if the data for
any device is not there, then the board file is not compiled.
The SAFEGUARD file also applies to the digital part of a mixed test.

Figure 1-4 Locating a SAFEGUARD file in a library directory

my_lib

ram

safeguard
digital
test_1
analog
test_2

Figure 1-4 shows a custom library directory, my_lib, with a SAFEGUARD file
safeguard (the object files have been omitted, to simplify the figure). The library
contains two in-circuit digital tests (test_1 and test_2), and a mixed test (ram) with
a digital part and an analog part. File safeguard contains the following entries for
the two in-circuit tests and the digital part of the mixed test:
use parameters "default" for "test_1"
use parameters "default" for "test_2"
use parameters "default" for "ram"
These statements associate the default SAFEGUARD parameters with the three
tests (see An Example Safeguard File). Notice that the in-circuit tests are referenced
by their file names, but the mixed test is referenced by its directory name, ram.
The data gathered for all of the devices in the board test are placed in a file by the
program generators and saved as safeguard under the board test directory. The
compiled version of this file (safeguard.o) is used by the safety analysis routines to
calculate the timeout and cooldown delays for each test.

An Example Safeguard File

An example of a SAFEGUARD file as it might appear in a custom library is shown in
Example 1-1 on page 1-18. The file contains the entries for several arbitrary tests
and for the three tests shown in Figure 1-4. File safeguard under the board test
directory would be similar. You can edit a SAFEGUARD file in the safeguard mode;
the statements are listed and described later in this chapter (see SAFEGUARD
Statements on page 1-19).
The file contains blocks of parameters, with each block bounded by the parameters
and end parameters statements. Each block contains the parameter values that
characterize a specific family of devices. If a parameter is not specified in a

Digital Testing 1-17

1 Digital Theory and Testing

particular block, then that parameter's default values are automatically assumed in
that block.
The parameter blocks are associated with specific device tests by the use
parameters statements (e.g., use parameters default for test_1). As indicated
above, every device test in each library directory must be referenced in that
directory's SAFEGUARD file. A use parameters statement can appear anywhere in
the file, except that it cannot be located in a parameter block and it cannot precede
the block it references.
In the standard libraries, each block of safeguard parameters resides in its own file
under directory $AgilentICT_ROOT/standard/safeguard. For example, the
parameters for standard TTL are in file
$AgilentICT_ROOT/standard/safeguard/standard_ttl. Each safeguard file in the
standard libraries then uses include statements to reference the standard blocks.
For example, file $AgilentICT_ROOT/library/ttl/safeguard contains the
statement to include the standard TTL block:
include "standard_ttl"

Example 1-1
! Safeguard file for custom library "my_lib"
! The first parameter block has the default values for all
parameters;
! because default values are assumed, the same block could be
written as:
! parameters "default"
! end parameters
parameters "default"
backdrive current of 0.720 for "0", 0.720 for "1"
bondwire 2540 by 25.4
heat source 50 by 10, 1 per output
operating temperature 40
overdrive power 2.88, 2.88 dissipated by heat source
package ceramic
thermal resistance 60
end parameters
! devices associated with the "default" parameters
use parameters "default" for "test_1"
use parameters "default" for "test_2"
use parameters "default" for "ram"
parameters "standard TTL"
backdrive current of 0.100 for "0", 0.275 for "1"
bondwire 2540 by 25.4
heat source 50 by 10, 2 per output
operating temperature 40
overdrive power 0.97, 0.60 dissipated by heat source
package ceramic
thermal resistance 60
end parameters
! devices associated with the "standard TTL" parameters
use parameters "standard TTL" for "7400"
use parameters "standard TTL" for "7404"
use parameters "standard TTL" for "7408"
use parameters "standard TTL" for "7410"

1-18 Digital Testing

 Digital Theory and Testing 1

parameters "high output TTL"

backdrive current of 0.250 for "0", 0.500 for "1"
heat source 100 by 10, 2 per output
operating temperature 40
overdrive power 1.75, 1.25 dissipated by heat source
package ceramic
! "bond wire" and "thermal resistance" default
end parameters
! devices associated with the "high output TTL" parameters
use parameters "high output TTL" for "7411"
use parameters "high output TTL" for "7428"
use parameters "high output TTL" for "7437"
! miscellaneous devices
use parameters "default" for "72wb88"
use parameters "standard TTL" for "7130"
use parameters "high output TTL" for "74128"
use parameters "standard TTL" for "74144"
! ***** END OF FILE *****

Custom Safeguard Files

If you develop custom libraries, such as the one shown in Figure 1-4 on page 1-17,
be sure to add a SAFEGUARD file to each directory that contains device tests and
mixed tests — the file must always be named safeguard. Every device test in each
directory must be associated with a parameter block (use parameters statement)
in the safeguard file that resides in the same directory. Mixed library tests may or
may not need a SAFEGUARD file, depending on the nature of the circuit being
tested. For example, a SAFEGUARD file is not needed for a mixed test that tests the
complete board from the edge-connector only. After saving the SAFEGUARD
source file, it must be compiled. For example:
compile "my_lib/safeguard"; library
If you wish, you can generate your SAFEGUARD files by copying the standard
SAFEGUARD files from the standard libraries and editing the copies. Note that
those files do not actually contain the test parameters; instead, they use include
statements to reference the blocks of parameters saved in files under
$AgilentICT_ROOT/standard/safeguard.

SAFEGUARD Statements
The SAFEGUARD statements are used in safeguard files to define the damage
parameters for classes of devices, as shown in the example file listed above. If a
parameter is not defined in a specific block, then that parameter is automatically
assumed to have its default value in that block.
The safeguard mode must be selected (execute the BT-Basic statement
safeguard) to write or edit the safeguard statements; syntax checking is on while
the mode is selected. Similarly to the other modes in the system, the safeguard
mode is associated with the source file when it is saved.

Digital Testing 1-19

1 Digital Theory and Testing

The SAFEGUARD statements are briefly described in Table 1-6.

Table 1-5 Options for the safeguard <type> statement

Option Description
safeguard none Turns off safeguarding and allows all inhibited tests to run. Do not use this
unless there is no reasonable alternative.
safeguard cool * Allows digital tests to run, but cooldown delays between tests are enforced.
safeguard d igital Tests that are inhibited because of non-digital devices are allowed to run.
safeguard all Prevents inhibited tests from running (the default in testplans that have no
safeguard <type> statements).

* Inhibited tests can be run if you execute safeguard none or safeguard cool; the
latter enforces cooldown delays between tests. However, if you execute either
statement, it is your responsibility as the test developer to ensure that the tests
do not damage devices on the board.

Table 1-6 SAFEGUARD statements

Statement Description
backdrive current Specifies the amount of current that flows through a power (or ground) pin
when one of the device's output pins is overdriven.
bond wire Specifies the size (i.e., length and diameter) of the device's bond wires.
end parameters Marks the end of a parameters block.
heat source Describes that portion of a digital device that is heated by overdriving.
include Enables you to merge object code from another file into the SAFEGUARD
object file when it is compiled.
model Specifies the name of the standard on which the SAFEGUARD analysis
routines are based.
operating Specifies the operating temperature of the digital device under test.
temperature
overdrive power Specifies the worst case power absorbed by an output pin when it is
overdriven.
package Specifies the package material (plastic or ceramic) of the device.
parameters Marks the start of a parameter block, which contains the SAFEGUARD
characteristics of a family of devices.
thermal resistance Specifies the thermal junction-to-case resistance of the device.
use parameters Associates a specific device test or mixed test with a specific parameter
block.

1-20 Digital Testing

 Digital Theory and Testing 1

Power Monitoring Circuit

The Power Monitoring Circuit (PMC) on the ASRU Revision N Card is used to
monitor the built-in power surge regulator on the DUT board. It can measure/detect
up to three outputs of the board DC voltage during power-up tests. The circuit can
monitor a voltage level range of 1.8 V to 50 V and send an undervoltage alert to the
system if the monitored voltage is lower than the expected value.
If the software detects an interrupt, the hardware will trigger the MFAIL~ signal and
send it to the Module Control Card. The signal will halt the sequencer, and interrupt
the power immediately.
If no interrupt is detected upon power failure, testing of the device is halted to
prevent the backdrive current damaging the device. Testing then continues with the
next device.
Up to three DUT power supply voltages per ASRU-N card can be monitored during
digital testing. Different voltage limits can be set for each channel.
For details, see the following sections:
• Using PMC
• Wiring Specifications

Using PMC
• The PMC channels have to be manually wired to the proper locations (see
Wiring Specifications).
• The ASRU Revision N Card must be declared in the board config file.
• There is no automatic test or fixture generation for this feature.
• The PMC_ON flag in sub Set_Custom_Options in the testplan must be set to true
to enable the PMC (see Example 1-2).
• In the testplan, also uncomment the statements in sub Setup_Power_Supplies
and sub Disconnect_Power_On_Board to use the PMC (see Example 1-3; a
sample implementation is shown in Example 1-4).
• Testplans generated prior to 08.00p software release – BT-Basic commands
for configuring and controlling PMC channels have to be manually added to
the testplan; and also the commands to initiate action upon detection of a
power failure.

Example 1-2 PMC_ON statement in testplan

PMC_On = False ! Choose {True} to enable PMC,
! {False} to disable PMC

Digital Testing 1-21

1 Digital Theory and Testing

Example 1-3 Commented PMC statements in testplan

sub Setup_Power_Supplies (Status_Code, Message$)
global PMC_On
...
...
if PMC_On then
! Turn on PMC here
! spmc <Channel Id >,<Voltage Lower Limit>
! spmc reset
! spmc interrupt <on/off>
! rpmc <Channel Id>,<failure flag variable>
end if
subend

sub Disconnect_Power_On_Board
dps
...
if PMC_On then
! Turn off PMC for all or selected channels here
! spmc <Channel Id> off
! spmc off
end if
subend

In Example 1-4, channel 4 is used to monitor voltage “+3.3V”, with interrupt on

when the voltage falls below the voltage limit.

Example 1-4 Example of PMC usage

if PMC_On then
! Turn on PMC here
spmc 4, 3.1
! spmc reset
spmc interrupt on
! rpmc <Channel Id>,<failure flag variable>
end if

if PMC_On then
! Turn off PMC for all or selected channels here
spmc off ! turn off all PMC
! spmc <Channel Id> off
end if

1-22 Digital Testing

 Digital Theory and Testing 1

Wiring Specifications
Table 1-7 shows the channel to MINT pin mapping on the ASRU Revision N Card.
Table 1-8 shows the brc designations for the PMC pins (side facing the operator).

Table 1-7 Channel to MINT pin mapping

Pins
Module 173–174 175–176 177–178
Module 3 1 2 3
Module 2 4 5 6
Module 1 7 8 9
Module 0 10 11 12

Table 1-8 brc for PMC pins

Module brc
Module 3 213173 to 213178
Module 2 201173 to 201178
Module 1 123101 to 123106
Module 0 111101 to 111106

Digital Testing 1-23

1 Digital Theory and Testing

1-24 Digital Testing