I CT Manual Data Loggin

Contents Data Formats
1 The Board File

Objectives .............................................................................................................................. 1-1
Prerequisites........................................................................................................................... 1-1
Required Tools and Materials................................................................................................ 1-1
Overview...................................................................................................................................... 1-2
Modifying or Viewing the Data in the board File ................................................................. 1-2
Board File Overview.................................................................................................................... 1-4
Where Does the Board File Come From?.............................................................................. 1-4
Programs that use the board and board.o Files ...................................................................... 1-5
BCF Syntax Structure .................................................................................................................. 1-6
Special Symbols..................................................................................................................... 1-6
Comments .............................................................................................................................. 1-7
Numerals ................................................................................................................................ 1-7
Identifiers (Reference Designators and Node Names) .......................................................... 1-8
Duplicate Entries.................................................................................................................. 1-11
Board File Structure................................................................................................................... 1-12
Include ................................................................................................................................. 1-13
Heading ................................................................................................................................ 1-13
Global Options ..................................................................................................................... 1-14
Device Options .................................................................................................................... 1-21
Family Options .................................................................................................................... 1-25
Card Options ........................................................................................................................ 1-28
Fixed Node Options ............................................................................................................. 1-29
GP Relay Options ................................................................................................................ 1-30
© Agilent Technologies 2001 Data Formats i

Table of Contents
Library Options.................................................................................................................... 1-32

Override ............................................................................................................................... 1-32
Device Definitions ............................................................................................................... 1-33
FET ...................................................................................................................................... 1-39
Jumper.................................................................................................................................. 1-45
Undefined............................................................................................................................. 1-62
Nodes ................................................................................................................................... 1-62
Pin_Map............................................................................................................................... 1-63
Unconnected Pin .................................................................................................................. 1-65
Connections ......................................................................................................................... 1-66
Dangling Pins....................................................................................................................... 1-67
Devices................................................................................................................................. 1-67
Critical Pins.......................................................................................................................... 1-67
Internal Structure ................................................................................................................. 1-68
Cross Checked Devices ....................................................................................................... 1-68
Cross Checked Nodes .......................................................................................................... 1-68
Disabling Information (Preconditioning)............................................................................. 1-68
Boundary Scan Chains......................................................................................................... 1-76
End ....................................................................................................................................... 1-77
Sample Board File ..................................................................................................................... 1-78
2 The board_xy File

Objectives .............................................................................................................................. 2-1
Prerequisites........................................................................................................................... 2-1
Overview...................................................................................................................................... 2-2
Modifying/ Viewing the Data in the board_xy File............................................................... 2-2
What is a board_xy File? ............................................................................................................. 2-4
Programs that Use the board_xy File........................................................................................... 2-7
© Agilent Technologies 2001 Data Formats ii

Table of Contents
board_xy File Syntax ................................................................................................................... 2-9

Scale....................................................................................................................................... 2-9
Units....................................................................................................................................... 2-9
Include ................................................................................................................................. 2-10
Placement............................................................................................................................. 2-10
Outline ................................................................................................................................. 2-11
Tooling................................................................................................................................. 2-12
Keepout ................................................................................................................................ 2-13
Node..................................................................................................................................... 2-14
Other .................................................................................................................................... 2-20
Group ................................................................................................................................... 2-25
Devices................................................................................................................................. 2-26
End ....................................................................................................................................... 2-26
Sample board_xy File ................................................................................................................ 2-27
3 The Testorder File

Objectives .............................................................................................................................. 3-1
Prerequisites........................................................................................................................... 3-1
Introduction.................................................................................................................................. 3-2
Modifying/Viewing the Data in the testorder File................................................................. 3-3
Testorder Syntax ......................................................................................................................... 3-4
Statement List ....................................................................................................................... 3-4
Testplan Generation On/Off .................................................................................................. 3-9
Sample Testorder File................................................................................................................ 3-10
4 The Wirelist File

Objectives .............................................................................................................................. 4-1
© Agilent Technologies 2001 Data Formats iii

Table of Contents
Prerequisites........................................................................................................................... 4-1
Overview...................................................................................................................................... 4-2
Viewing the Data in the wirelist File ..................................................................................... 4-2
The Wirelist Syntax ..................................................................................................................... 4-4
global ..................................................................................................................................... 4-4
end global............................................................................................................................... 4-5
ground .................................................................................................................................... 4-5
end ground ............................................................................................................................. 4-5
relay ....................................................................................................................................... 4-6
end relay................................................................................................................................. 4-6
strapping................................................................................................................................. 4-7
tie ........................................................................................................................................... 4-7
end strapping.......................................................................................................................... 4-7
unused .................................................................................................................................... 4-8
end unused ............................................................................................................................. 4-8
test .......................................................................................................................................... 4-8
device ................................................................................................................................... 4-10
end device ............................................................................................................................ 4-11
clock..................................................................................................................................... 4-12
asru module.......................................................................................................................... 4-12
timing module ...................................................................................................................... 4-13
stimulus module ................................................................................................................... 4-13
functional ............................................................................................................................. 4-15
include.................................................................................................................................. 4-15
subtest .................................................................................................................................. 4-15
end subtest............................................................................................................................ 4-16
wire ...................................................................................................................................... 4-16
group .................................................................................................................................... 4-21
end group ............................................................................................................................. 4-22
© Agilent Technologies 2001 Data Formats iv

Table of Contents
serial..................................................................................................................................... 4-22
interface ............................................................................................................................... 4-22
end interface......................................................................................................................... 4-23
Sample Wirelist File .................................................................................................................. 4-24
5 The Fixture Files

Objectives .............................................................................................................................. 5-1
Prerequisites........................................................................................................................... 5-1
Overview...................................................................................................................................... 5-2
Modify the Fixture File from Agilent Fixture Consultant ..................................................... 5-2
Modify the Fixture File from Agilent IPG Test Consultant .................................................. 5-2
Modify the Fixture File Manually ......................................................................................... 5-3
What is a Fixture File?................................................................................................................. 5-4
Fixture Description Block...................................................................................................... 5-5
Board Description Block ....................................................................................................... 5-6
Protected Unit Description Block .......................................................................................... 5-7
Programs that Use the Fixture File .............................................................................................. 5-8
Fixture File Syntax..................................................................................................................... 5-10
The Fixture Description Block ............................................................................................ 5-11
The Board Description Block .............................................................................................. 5-17
Protected Unit Description Block ........................................................................................ 5-38
End ....................................................................................................................................... 5-45
Sample Fixture File.................................................................................................................... 5-46
Fixture Defaults File .................................................................................................................. 5-51
Sample Fixture Defaults File ..................................................................................................... 5-53
The Options Sections ........................................................................................................... 5-55
© Agilent Technologies 2001 Data Formats v

Table of Contents
Keepout ................................................................................................................................ 5-55

Default Placement................................................................................................................ 5-55
Dividing Lines ..................................................................................................................... 5-56
Comments ............................................................................................................................ 5-56
User-Modifiable Fixture Components ....................................................................................... 5-57
Fixture Components Files Syntax.............................................................................................. 5-60
Fixture Kit Component File Syntax..................................................................................... 5-61
Comments ............................................................................................................................ 5-62
Sample Fixture Components Files ............................................................................................. 5-63
Standard and Advanced probe Spacing ..................................................................................... 5-66
6 Log Record Format

Objectives .............................................................................................................................. 6-1
Prerequisites........................................................................................................................... 6-1
What are Log Records?................................................................................................................ 6-2
About Log Record Prefixes ......................................................................................................... 6-3
Hierarchy of Log Records............................................................................................................ 6-8
Interpreting the Log Records ..................................................................................................... 6-10
A Note About Truncated Records ....................................................................................... 6-13
A Note About Process Steps ................................................................................................ 6-13
A Note About User-Defined Log Records .......................................................................... 6-14
How Log Records are Formatted............................................................................................... 6-15
Special Characters................................................................................................................ 6-15
Rules of Formatting ............................................................................................................. 6-15
Descriptions of the Log Records ............................................................................................... 6-17
Record @A-CAP: capacitor ................................................................................................ 6-17
© Agilent Technologies 2001 Data Formats vi

Table of Contents
Record @A-DIO: diode....................................................................................................... 6-18

Record @A-FUS: fuse......................................................................................................... 6-19
Record @A-IND: inductor .................................................................................................. 6-20
Record @A-JUM: jumper.................................................................................................... 6-21
Record @A-MEA: measure................................................................................................. 6-22
Record @A-NFE: nfetr........................................................................................................ 6-23
Record @A-NPN: npn......................................................................................................... 6-24
Record @A-PFE: pfetr ........................................................................................................ 6-25
Record @A-PNP: pnp.......................................................................................................... 6-26
Record @A-POT: potentiometer ......................................................................................... 6-27
Record @A-RES: resistor.................................................................................................... 6-28
Record @A-SWI: switch ..................................................................................................... 6-29
Record @A-ZEN: zener ...................................................................................................... 6-30
Record @AID: identify board causing real-time alarm....................................................... 6-31
Record @ALM: identify real-time alarm ............................................................................ 6-32
Record @ARRAY: digitizer results analysis ...................................................................... 6-33
Record @BATCH: identify a batch of boards..................................................................... 6-34
Record @BLOCK: identify a test block .............................................................................. 6-36
Record @BS-O: list of open pins ........................................................................................ 6-38
Record @BS-S: list of shorted pins ..................................................................................... 6-39
Record @BTEST: describe a board test .............................................................................. 6-40
Record @CCHK: Connect Check Test................................................................................ 6-44
Record @DPIN: list of device pins for a single device ....................................................... 6-45
Record @D-PLD: results of PLD programming -- success or failure................................. 6-46
Record @D-T: test digital.................................................................................................... 6-50
Record @GRP: group record............................................................................................... 6-51
Record @INDICT: indict record ......................................................................................... 6-52
Record @LIM2: high & low limits of analog test ............................................................... 6-54
Record @LIM3: nominal high/low ..................................................................................... 6-55
Record @M-CL: MAGICCLUSTER record....................................................................... 6-56
Record @NETV: network verification record..................................................................... 6-57
© Agilent Technologies 2001 Data Formats vii

Table of Contents
Record @NODE: list of nodes ............................................................................................ 6-58

Record @PCHK: Polarity Check Test................................................................................. 6-59
Record @PF: pinsfailed....................................................................................................... 6-60
Record @PIN: list of pins.................................................................................................... 6-61
Record @PRB: (partial) results of probing (failures).......................................................... 6-61
Record @RETEST: indicate a log clear for retest............................................................... 6-62
Record @RPT: messages logged by report ......................................................................... 6-62
Record @S-PROC: describe process in serial test .............................................................. 6-64
Record @TJET: TestJet Test ............................................................................................... 6-69
Record @TS: test shorts ...................................................................................................... 6-70
Record @TS-D: destination nodes shorted to source node ................................................. 6-71
Record @TS-O: opens found while shorts testing .............................................................. 6-72
Record @TS-P: phantoms found while shorts testing......................................................... 6-72
Record @TS-S: results of shorts testing from a source node .............................................. 6-73
7 The Board Defaults Files

Objectives .............................................................................................................................. 7-1
Prerequisites........................................................................................................................... 7-1
Overview...................................................................................................................................... 7-2
The board_defaults File ............................................................................................................... 7-3
The edge_
board_defaults File ................................................................................................................... 7-5
8 Part Description Language

Objectives .............................................................................................................................. 8-1
Prerequisites........................................................................................................................... 8-1
© Agilent Technologies 2001 Data Formats viii

Table of Contents
About Part Description Language................................................................................................ 8-2

Overview................................................................................................................................ 8-2
Structure of Part Description Language................................................................................. 8-2
Examples of Part Description Libraries................................................................................. 8-3
How Child Devices Inherit Traits From Parent Devices ....................................................... 8-9
A Shortcut for Denoting Non-Testable Devices.................................................................. 8-15
Restrictions on Nested Entries ............................................................................................. 8-15
Reference Description of PDL................................................................................................... 8-16
Additional Features for Manually Created PDL Files ......................................................... 8-16
capacitor............................................................................................................................... 8-16
connector.............................................................................................................................. 8-18
diode..................................................................................................................................... 8-20
external pins ......................................................................................................................... 8-22
fet ......................................................................................................................................... 8-24
fuse....................................................................................................................................... 8-26
inductor ................................................................................................................................ 8-28
Internal node ........................................................................................................................ 8-31
jumper .................................................................................................................................. 8-32
pin library............................................................................................................................. 8-34
potentiometer ....................................................................................................................... 8-36
resistor.................................................................................................................................. 8-38
switch ................................................................................................................................... 8-41
transistor............................................................................................................................... 8-43
zener..................................................................................................................................... 8-44
© Agilent Technologies 2001 Data Formats ix

1 The Board File
In this chapter... ■ Overview, 1-2
■ Board File Overview, 1-4
■ BCF Syntax Structure, 1-6
■ Board File Structure, 1-12
■ Sample Board File, 1-78
Objectives
When you finish reading this chapter, you should be
able to:
■ Understand the Board Files syntax structure and
the file structure, including the syntax of the
keywords
Prerequisites
There are no prerequisites associated with using this
chapter.
Required Tools and Materials

There are no required tools or materials associated with
using this chapter.
© Agilent Technologies 2001 Data Formats 1-1

Chapter 1: The Board File
Overview This chapter describes the structure of the Board 1 Modify the board file from Agilent Board
Configuration Format (BCF) syntax of the board file. Consultant.
The board file contains a description of the devices on
the board to be tested, their interconnections, and the a Modify entry forms.
test and fixture options. b Compile board file by clicking the left mouse
button on Final Compile/Verify.
NOTE
There are optional board file statements that are NOTE
not described in this chapter. These statements are See Chapter 2, Agilent Board Consultant in Test
available with optional software packages such as Development Tools for more information on
the Agilent PanelTest option. For information modifying entry forms.
about such statements, refer to the documentation
in the optional package.
2 Modify the board file from Agilent IPG Test
Modifying or Viewing the Data in the board File Consultant.
a Click the left mouse button on Edit.
NOTE
b Drag the mouse pointer to select View/Edit board
You should not edit board test files with shell File.
editors such as vi. These editors do not update the
file's header information, such as the time-stamp, IPG Test Consultant opens a BT-BASIC window
that Agilent 3070 programs use. Instead, use the and loads the board file into the BT-BASIC
BT-BASIC editor to edit board test files. workspace for you to edit.
3 Modify the board file manually.

a Open a BT-BASIC window.
b msi to the board test directory.

c Generate a board source file from the board.o

object file if the board source file doesn’t exist.
Type:
list object "board.o" to board
d Load the board file. Type:

load “board”
e Edit the board file.

f Save the board file. Type:
re-store "board"
This chapter gives you an overview of the board file, an

explanation of the syntax structure, a description of the
file structure including the syntax of the keywords, and
ends with a sample board file.
The information in the board file is created from the
entry forms of Board Consultant.
NOTE
Board Consultant is described in Chapter 3,
Creating Board Information in Test and Fixture
Development.

Board File Overview The board file contains the electrical description of a ■ Use Board Consultant to create and edit the entire
circuit board. This includes the information in Table board file. (Board Consultant is explained in
1-1. Chapter 3, Creating Board Information in Test
and Fixture Development.)
Table 1-1 Information in board file
■ Manually create the file using the structure and
Information Description syntax described in this chapter. If you manually
create your board file, we recommend that you
fixture options fixture parameters for the use the check board statement to check the
Fixture Generation Software syntax before you compile the file.
device options test parameters for Agilent
IPG NOTE
For information on using CAMCAD, refer to the
component values and device specifications for IPG
documentation for that software package.
tolerances
connectivity topology information for IPG
information
Where Does the Board File Come From?

There are four methods to produce the board file.
■ If you used CAMCAD to translate an X-Y data
file, CAMCAD outputs data into two files,
<file>.bxy and <file>.brd, for you. You will
then need to change the names of the files to
board_xy and board, respectively. Any
information not translated into these files must be
manually entered using Board Consultant.

Programs that use the board and board.o Files

Table 1-2 Programs that use the board and board.o files
Name Description
Board Used to edit the board file. Completing the board and board_xy files is part of the data capture process
Consultant described in Chapter 3, Creating Board Information in Test and Fixture Development.
Check Reads and verifies the syntax of the board file.
Board
IPG Uses device, topology, and test option information from the board.o file to generate device tests.
Fixture The Board Placement and Probe Select programs of the Fixture Generation Software read the board.o file
Generation to find the fixture options and any critical pins. Critical pins are entered in the Critical Pins Form of Board
Software Consultant; Fixture Options are part of the Global Options of Board Consultant. This information is passed on
to fixture.o. Module Pin Assignment also reads the board.o file for any general purpose relay
assignments.
Board_xy Uses the topology and fixture options to generate the board_xy.o file.
Compiler

NOTE
BCF Syntax This section is provided to help you understand the See Chapter 3, Creating Board Information in
Board Configuration Format (BCF) syntax of the board Test and Fixture Development for recommended
Structure file. Each keyword of the syntax is described in the next node naming and pin numbering conventions.
section.
The BCF syntax is divided into these categories: Special Symbols
■ Special Symbols There are two sets of special characters that you cannot
■ Comments use in part numbers and device names in the board file:
■ Identifiers ■ Characters that have special meaning in BCF.
■ Numerals ■ Characters that have special meaning in the shell.
■ Keywords The first set of special characters, BCF special
characters, and their meanings are described in Table
A BCF file is an ASCII file that is compiled by a 3070 1-3.
Family system and contains a description of the
topology of the board to be tested. Table 1-3 BCF special characters
You can use upper or lower case characters in the BCF
Character Description
syntax. The case that you use is preserved in the board
file; however, the device names in the board.o and . Separates the identifier for a device and pin.
board.l files will be lower case. Any device names
retrieved from board.o, such as in the test statement , Used as a delimiter, same as a space.
in the testplan, will be lower case. Note that quotes on ; Used to terminate a statement.
reference designators are optional.
% Used to separate a parent device from a child
device and panelized test.
: Used to separate a parent device from a child
device and panelized test.

Table 1-3 BCF special characters (continued) ! comment
Character Description Numerals

" Used to delineate a string. Numerals are legal BT-BASIC constants with a
! Indicates a comment; terminates at the end maximum of 20 characters. The suffixes in Table 1-4
are allowed with numerals and must follow the numeral
of the line.
with no space.
** Used as a default value placeholder.
Table 1-4 Suffixes allowed with numerals
The second set of special characters, shell characters, Suffix Description Exponent
are:
M Mega 106
* . " ' ` [ ] < > | & $ \
k kilo 103
/ blank ; ? ^ ( ) :
m milli 10-3
# - (in first character position)
u micro 10-6
Do not use these characters in part numbers and device
names. The underscore (_) works well in place of the n nano 10-9
period (.). p pico 10-12
Do not use the tilde (~) in device names, node names, or
failure messages.
NOTE
Comments
Refer to Chapter 2, Syntax Conventions and
A comment begins with an exclamation mark (!) and Definitions in Board Test Fundamentals for more
continues to the end of a physical line. For example: information on numeric constants.
resistor
R1 10 10 10 f; ! comment
R2 10 10 10 f message; ! comment

Identifiers (Reference Designators and Node $AGILENT3070_ROOT/standard. The Pin_Map can also
Names) be part of the board file. The pin name mapping table is
described more thoroughly under Pin_Map in the next
An identifier is the name of a device, pin, or node that section. Pin mapping takes place only once for both the
you are entering into Agilent Board Consultant. board and board_xy files.
Identifiers of devices and pins are called reference
designators. Identifiers for nodes are called node names. Keywords
Board Consultant accepts:
Keywords are not case-sensitive. BCF syntax keywords
■ Node names up to 40 characters long indicate:
■ Device designators up to 48 characters long ■ Headings
■ Device, global, test, GP relay, and fixture options
■ Pin names up to 8 characters long
■ The end of the device options
■ Path names up to 1024 characters long ■ Node messages
■ A Pin_Map table
Identifiers are not case-sensitive; the upper and
■ The end of a Pin_Map
lowercase of a letter is considered the same letter.
■ Component descriptions
Reference designators and node names can be
■ Node name for unconnected pins
optionally listed with quotes (e.g. “U101”). Note that
you must use quotes if the identifier contains any special ■ Node connections
■ Device connections
characters (e.g. "U 101"). We recommend not using
■ Critical pins
special characters in identifier names.
■ Cross checking
You can use a Pin_Map to translate device pin names. ■ Disabling information
This is useful when your CAD data file uses pin names ■ The end of a BCF file
other than what Board Consultant accepts. For example,
A component description keyword marks the beginning
your CAD data file may have specified transistor pins as
1, 2, and 3, instead of E, B, and C as required by Board of a list of component descriptions. The description can
Consultant. In this case, you can use a Pin_Map to consist of several elements (component name, value,
tolerances, etc.) which must be separated by at least one
translate the 1, 2, and 3 to E, B, and C. The Pin_Map can
space. The pins of a component are defined by the
be placed in the board_defaults file and can reside in
the local board directory, or under

Connections keyword, or the Devices keyword, or both. $AGILENT3070_ROOT/standard directory. The 3070
For example: system looks first under the local board directory and, if
capacitor
a board_defaults file does not exist, it then looks
C101 10.00p 10.00 10.00 F PN"0203-0098"; under the $AGILENT3070_ROOT/standard directory
which contains a board_defaults file. The Pin_Map
The component description keywords can appear in any table may exist in the board_defaults file or the board
order, however, they must precede the connections and file. The board file can be pin-mapped only once.
the devices keywords. After the board file is pin-mapped a flag will be set to
Each component description must follow the same identify that the file has already been pin-mapped.
syntax rules as its associated Board Consultant entry. Programs which read the board file first look for a
Pin_Map table in the board file. If a Pin_Map table does
There are two BCF configuration tools that you can use not exist in the board file, these programs look in the
to translate component information from a CAD data board_defaults file for a Pin_Map table.
file that is incomplete or does not match the syntax. The
two tools are described in Table 1-5. The BCF keywords are summarized in Table 1-6 and
explained in detail in the next section of this chapter.
Table 1-5 BCF configuration tools
Table 1-6 BCF keywords
Tool Description
Keyword Description
board_defaults Fills in information missing in the
board file by using the defaults capacitor Indicates a capacitor description.
contained in the card options Indicates card preference for resource
board_defaults file. assignment.
pin name mapping Uses the Pin_Map table to connections Lists the device.pins connected to
(keyword is translate pin names into names each node.
Pin_Map) required by the 3070 Family.
connector Indicates a connector description.
The board_defaults file can be located under the local

board directory or under the

Table 1-6 BCF keywords (continued) Table 1-6 BCF keywords (continued)
Keyword Description Keyword Description

critical pins Lists device pins that require short fixed node Lists the power supply nodes and the
wire lengths for sensitive or high options nodes that cannot or should not be
speed tests. driven in library tests. These are
specified in the Power Node Options
cross checked Records devices that have been
Form of Board Consultant.
devices cross-checked in Board Consultant.
fuse Indicates a fuse description.
cross checked Records nodes that have been
nodes cross-checked in Board Consultant. gp relay Lists general purpose relay
options connections.
devices Lists the node connected to each
device.pin. global options Specifies test and fixture information.
device options Specifies test information for a device. heading Includes a heading on the forms list
file.
diode Indicates a diode description.
include Includes the contents of the specified
disabling Specifies disabling and conditioning
file at this point in the board file.
information information for a device or node. This
is also referred to as preconditioning. inductor Indicates an inductor description.
end Marks the end of a BCF file, a internal Describes the internal elements of a
PIN_MAP table, or the device options. structure device package such as a resistor
pack.
family options The voltage reference levels for the
logic families. jumper Indicates a jumper description.
FET Indicates a field effect transistor library options Lists the path names of all library
description. directories that contain library tests of
devices on the board to be tested.

Table 1-6 BCF keywords (continued) Duplicate Entries

Keyword Description If two, or more, entries are made using the same
identifiers, an error will result. The following example
node library Indicates a node-based library/cluster is NOT acceptable and will generate an error:
description.
"R1" 10k 10 10 f;
nodes Lists all nodes with failure messages, "R1" 20k 10 10 f "message";
and all nodes that are not listed under
Devices or Connections.
override Changes one or more device options.
pin library Pin-based library/cluster description.
pin_map Marks the start of a Pin_Map table.
potentiometer Potentiometer description.
resistor Indicates a resistor description.
switch Indicates a switch description.
transistor Indicates a transistor description.
unconnected Specifies how unconnected pins are
pin labeled.
undefined Lists devices referenced by a
CONNECTION statement, but which
have not been defined by a device
definition.
zener Indicates a zener description.

Table 1-7 Board file modules (continued)

Board File Structure A board file can contain the modules in Table 1-7. Module See Section
Table 1-7 Board file modules PIN_MAP Pin_Map on page 1-63
Module See Section UNCONNECTED Unconnected Pin on page 1-65

PIN
INCLUDE Include on page 1-13
CONNECTIONS Connections on page 1-66
HEADING Heading on page 1-13
DANGLING PINS Dangling Pins on page 1-67
GLOBAL Global Options on page 1-14
OPTIONS DEVICES Devices on page 1-67
DEVICE OPTIONS Device Options on page 1-21 CRITICAL PINS Critical Pins on page 1-67
FAMILY OPTIONS Family Options on page 1-25 INTERNAL Internal Structure on page 1-68
STRUCTURE
CARD OPTIONS Card Options on page 1-28
CROSS Cross Checked Devices on
FIXED NODE Fixed Node Options on CHECKED page 1-68
OPTIONS page 1-29 DEVICES
GP RELAY GP Relay Options on page 1-30 CROSS Cross Checked Nodes on
OPTIONS CHECKED page 1-68
LIBRARY Library Options on page 1-32 NODES
OPTIONS DISABLING Disabling Information
OVERRIDE Override on page 1-32 INFORMATION (Preconditioning) on page 1-68
Device Device Definitions on page 1-33 END End on page 1-77

Definitions
NODES Nodes on page 1-62

■ fixed nodes (if any)

NOTE ■ gp relay options (if any)
Agilent Multiple Board Versions includes a ■ library options (if any)
VERSIONS section and versions parameters ■ device definitions
throughout the board file that are not included in ■ critical pins (if any)
this chapter; see Chapter 5, Multiple Board ■ connections/devices
Versions in Optional Board Test Applications for ■ internal structure (if any)
details.
Include
You can specify a listing format for the board file. Use The optional, include statement allows the contents of
the bcf list format field of the Global Options Entry a specified file to be inserted at this point in the board
Form of Board Consultant to specify the listing formats file. include statements can be nested to any depth; this
in Table 1-8. is useful for incorporating standard options and
configurations into new board files. When the new file
Table 1-8 bcf list format field options is stored, the information from the included file
becomes part of the new file. The included filename can
Option Description be a relative or an absolute pathname. The filename
device Specifies a device format listing. must be enclosed in quotes. For example:
INCLUDE "/board/std_options";
node Specifies a node format listing.
both The format to include devices and nodes. Heading
The heading keyword enables you to include a heading
A board file, capable of enabling test and fixture on the board file listing, board.l. The heading can be
generation, must include at least: up to 80 characters in length, must be enclosed in
quotes, and is terminated by a semicolon. For example:
■ global options
■ device options HEADING
■ family options (if any) "Amplifier Board Configuration File";
■ card options (if any)

Global Options The global options are used by the Fixture Generation
software and IPG. These are the global options that are
The Global Options module contains test and fixture used in BCF; the default values can be changed in the
information. This information is described in Table 1-9 board_defaults file.
on page 1-14. If a value is not specified for an option,
the value specified in the board_defaults file is used.
Table 1-9 Global options
Option Description Syntax Default Example

Fixture Type The type of fixture. <type> can be: EXPRESS Fixture Type
<type> • SIMPLATE
EXPRESS;
• EXPRESS
• NO-WIRE
• CASSETTE
• XG-50
• XG-50
CASSETTE
• QuickPress
• JOT
Fixture Size The fixture size. <size> can be: FULL Fixture Size
<size> • BANK1
BANK1;
• BANK2
• FULL

Table 1-9 Global options (continued)

Top Probes Specifies if probes are <status> can be: OFF Top Probes
Allowed <status> allowed in the top side of the • ON
Allowed ON;
Agilent Express Cassette
• OFF
fixture.
Heavy Probe The pressure (in ounces) <force> is a 8 Heavy Probe

Force <force> exerted by a heavy weight <numeric constant> Force 8;
probe. The probe pressure is
used in calculating the
maximum probe density on
the board.
Light Probe Force The pressure (in ounces) <force> is a 4 Light Probe
<force> exerted by a light weight <numeric constant> Force 4;
probe. The probe pressure is
used in calculating the
maximum probe density on
the board.
Mechanical Maximum density (in ounces <value> is a 800 Mechanical
Density per square inch) for <numeric constant> Density
Threshold 65;
Threshold mechanically operated
<value> fixtures. This is used to
calculate the maximum
allowed probes per square
inch.


Vacuum Density Maximum density (in ounces <value> is a 104 Vacuum Density
Threshold per square inch) for vacuum <numeric constant> Threshold 50;
<value> operated fixtures. This is used
to calculate the maximum
allowed probes per square
inch.
Autofile <code> A numeric code to <code> is a autofile 2062;
automatically identify the <numeric constant>
fixture that is loaded on the
testhead. The range of
autofiles is 11 to 4094.
Test Strategy The test strategy being used <strategy> can be: COMBINATIONAL Test Strategy
<strategy> to test the board. The strategy • COMBINATIONAL
COMBINATIONAL;
chosen will affect the defaults
• EDGE
for node accessibility.
CONNECTOR
ONLY
WireWrapping Method of wirewrapping to be <method> can be: MANUAL WireWrapping

<method> performed on the fixture. Use • MANUAL
AUTO;
AUTO for semi or fully
• AUTO
automatic wirewrapping. Use
WIRELESS for PCB-type • WIRELESS
fixtures. • SEMI AUTO


Metric Units Indicates if metric units should <status> can be: OFF Metric Units
<status> be used in the reports and • ON
ON;
files written by the Fixture
• OFF
Generation Software.
Common Lead The typical resistance in the <ohms> is a 100m Common Lead
Resistance probe and trace to the device <numeric constant> Resistance
0.100;
<ohms> under test. The range of
acceptable values is 0.1m
ohm to 100 ohms. The default
is 0.1 ohms.
Common Lead The typical inductance in the <henries> is a 1u Common Lead
Inductance probe and trace to the device <numeric constant> Inductance 10u;
<henries> under test. The range of
acceptable values is 0.1n
Henry to 1m Henry. The
default is 1u Henry.
Capacitance Specifies whether or not to <status> can be: OFF Capacitance
Compensation use capacitance • ON
Compensation
ON;
<status> compensation for small
• OFF
capacitors.


IPG Digital The minimum threshold for <ohms> is a 42 IPG Digital
Resistance determining a digital device <numeric constant> Resistance
Threshold 50
Threshold short. The default value is 42
<ohms> ohms.
Precondition The number of levels that <n> is an <integer 1 Preconditioning
Levels <n> Agilent IPG should repeat constant greater Levels 2;
the preconditioning process of than 0>
devices that can affect the
device under test. Multiple
levels allow for additional
preconditioning for devices
that are not directly connected
to the DUT, but affect the
outputs of other
preconditioned devices.
Default is for one level.


Additional Board Specifies the MAXIMUM <n> is an <integer zero Additional
Voltage <n> applied or generated voltage constant between Board Voltage
20;
on the DUT from a source zero and 100>
other than the Agilent 3070
DUT power supplies. This
includes on board power
supplies, external power
sources, fixture electronics,
and dc-to-dc converters.
Use Agilent Use DriveThru Test, a <status> can be: OFF Use DriveThru
DriveThru Test Dynamic Test Access ON
ON
<status> technique that allows you to
test digital devices through OFF
resistors. enabled. If the
DriveThru feature is installed
and enabled, status is set to
ON. If you do not wish to use
DriveThru test techniques,
status can be set to OFF.


DriveThru Maximum impedance of <ohms> is a 10K DriveThru
Impedance devices that can be tested <numeric constant> Impedance 10000
Threshold through using DriveThru Test.
<ohms> This threshold can be applied
to resistors, capacitors, and
inductors. The default setting
is 10K Ohms.
Boundary Scan You can turn boundary-scan <status> can be: OFF Boundary Scan
Overdrive overdrive on if you have the Overdrive ON
ON
<status> Advanced Boundary-Scan
software on your system. OFF
Turning overdrive on allows
overdriving of the TDI/TDO
pins of a boundary-scan
device that is part of a chain of
boundary-scan devices.
Boundary Scan Enables automatic Boundary <status> can be: OFF Boundary Scan
Disables <status> Scan Disabling. If Boundary Disable ON
ON
Scan Disable is turned on,
Boundary Scan Overdrive is OFF
automatically set to OFF.


Boundary Scan Allows manual additions of <status> can be: OFF Boundary Scan
Chain Override chain descriptions to the Override ON
ON
<status> board file. Also includes
chain descriptions in the OFF
listing of the board file.
Ground Bounce OFF
Suppression
<status>
Powered Shorts 100
Shorting Radius
<mils (.001 in)
int.>
Device Options
The device options described in Table 1-10 on
page 1-22 affect how tests are generated for each
component. IPG uses these options to develop
component tests. These options remain in effect for all
component tests unless overridden, with the OVERRIDE
keyword, for an individual component. These are the
device options that are used in BCF; the default values
can be changed in the board_defaults file.

Table 1-10 Device options

Tolerance Indicates how accurate a <value> is a <numeric 5 Tolerance
Multiplier test you want IPG to write. constant from 0.1 to 10> Multiplier 5.0;
<value> The lower the value of
tolerance multiplier the
more accurate a test is
generated. More accurate
tests may require more
resources and more test
execution time.
Remote Specifies whether or not <status> can be: ON Remote Sensing ON;
Sensing IPG should use remote • ON
<status> sensing where needed.
• OFF
Remote sensing requires
no additional probes but
uses more testhead
resources.

Table 1-10 Device options (continued)

Fuse The resistance value, in <ohms> is a <numeric 10 fuse threshold 3.0;
Threshold ohms, used to determine constant>
<ohms> the presence of a fuse. If
the measured value is less
than, or equal to, the
specified threshold, the
fuse is considered present
and the test passes.
Diode Current Maximum value of current, <amps> is a <numeric 1m Diode Current 1m;
<amps> in amps, flowing through constant>
the diode while its voltage
is being measured.
Zener Current Maximum value of current, <amps> is a <numeric 1m Zener Current 0.5m;
<amps> in amps, flowing through constant>
the zener while its voltage
is being measured.


Adjust The test adjust option for <status> can be: ACCURATE Adjust ACCURATE;
<status> variable device tests. This • NONE (Never allow the
keyword can specify: no operator to adjust the
operator adjustment, device.)
adjustment every time, or
• ACCURATE (Require the
adjustment only when
operator to adjust the
needed.
device every time and
respond with the YES or
NO keypad.)
• FAST (Require the
operator to adjust the
device and respond with
YES or NO, only if the
initial device measurement
fails.)


Upstream Specifies whether or not <status> can be: OFF Upstream Disable
Disable IPG should try to disable • OFF (IPG does not try to
ON;
<status> devices that must be disable upstream devices.)
overdriven for digital
• ON (IPG tries to disable
device tests.
upstream devices.)
Upstream Specifies whether or not <status> can be: OFF Upstream Condition
Condition IPG should try to set • OFF (IPG does not try to
ON;
<status> upstream devices to the condition upstream
state specified in the devices.)
device test. If Upstream
• ON (IPG tries to condition
Disable is also turned on,
upstream devices.)
IPG tries to disable the
device first, if the device
cannot be disabled, IPG
then tries to condition the
device.
Family Options If there are no family options to be specified, include

only the FAMILY OPTIONS keyword followed by a
Family Options specify the reference level voltage semicolon. For example:
values to be used for the logic families present on the
board under test. Each option must be terminated with a FAMILY OPTIONS;
semi-colon (;). Each family option is described Table 1-11.

Table 1-11 Family options
Option Description Syntax Example

<Family-id> Name of the logic family <Family-id> is a <string constant> TTL
being defined. The name
must correspond to a logic
family named in a device
library.
Drive High <value> The voltage used to drive a <value> is a <numeric constant Drive High 3.5;
node to a logic 1. from -3.5 to 5>
Drive Low <value> The voltage used to drive a <value> is a <numeric constant Drive Low 0.8;
node to a logic 0. from -3.5 to 5>
Receive High <value> The lowest voltage that can <value> is a <numeric constant Receive High 2.0;
be considered a logic 1. from -3.5 to 5>
Receive Low <value> The highest voltage that <value> is a <numeric constant Receive Low 0.8;
can be considered a logic 0. from -3.5 to 5>
Edge Speed <value> The edge transition speed <value> is a <numeric constant> Edge Speed 100;
in volts per microsecond
rounded to the nearest
increment of 25. The range
of edge speed is 25 to 275
volts/uSec.

Table 1-11 Family options (continued)
Option Description Syntax Example

Open Input Default The logic level that an <level> can be: Open Input Default 0;
<level> unconnected input pin • 0
assumes. Valid values are
• 1
0, 1, or X for don't care.
• X
Load <value> The load to be placed on <value> can be: Load NONE;
outputs. There can be no • NONE
load, a pull up resistor, or a
• UP
pull down resistor.
• DOWN

Card Options
The card options specify which card or cards the Table 1-12 CARD OPTIONS
fixturing software uses to assign resources for a
particular logic family in digital testing. If no card Option Description
options are specified, the fixturing software assigns
<Family-id> Name of the logic family. The name must
HybridPlus Card resources only. The Card Options are
correspond to a logic family named in the
described in Table 1-12 on page 1-28.
family options.
Example 1-1 CARD OPTIONS syntax HYBRID; Only Hybrid Card resources should be
assigned. This is the default if no
CARD OPTIONS
<Family-id> preference for a logic family is specified.
<preference list>
CHANNEL; Only ChannelPlus Card resources should
<Family-id> is a <string constant> be assigned.
<preference list> can be:

HYBRID; Preference of Hybrid Card resources over
HYBRID; CHANNEL; ChannelPlus Card resources. Semicolons
CHANNEL; as separators indicate a preference.
HYBRID; CHANNEL;
CHANNEL; HYBRID; CHANNEL; Preference of ChannelPlus Card resources
HYBRID, CHANNEL; HYBRID; over Hybrid Card resources. Semicolons
CHANNEL, HYBRID; as separators indicate a preference.
Example: HYBRID, No card preference for selection of
CARD OPTIONS CHANNEL; resources. Commas as separators indicate
TTL equal preference.
CHANNEL; HYBRID;
CMOS CHANNEL, No card preference for selection of
HYBRID, CHANNEL;
HYBRID; resources. Commas as separators indicate
equal preference.

Fixed Node Options

Fixed Node Options can have two sections: a list of the Table 1-13 FIXED NODE OPTIONS
power supply nodes and a list of the fixed nodes. Fixed
nodes are any nodes that cannot or should not be driven Option Description
in library tests. Each fixed node must have a logic level
<node-id> Name of the node.
specified for all families connected to it. Each node
connected to a power supply, and any fixed nodes must <number> An integer that specifies the DUT power
be listed here. A fixed node can be a node connected to a supply.
power node through a jumper or very small resistor. You
must specify one ground node; you cannot specify more <voltage> A numeric constant that specifies the
than one ground node. The Fixed Node Options are output voltage of the power supply. The
described in Table 1-13 on page 1-29. voltage is specified in volts.
<current> A numeric constant that specifies the
Example 1-2 FIXED NODE OPTIONS syntax
maximum current output of the specified
power supply. The current is specified in
Power Nodes Section Syntax: amps.
<node-id> No_Supply
No_Supply Indicates that no DUT supply should be
<node-id> supply <number> at <voltage>
volts, <current> amps; connected to the node.
Fixed Nodes Section Syntax: <Family-id> Name of the logic family associated with
the node. The name should correspond to
<node-id> Family <Family-id> is <value>;
a logic family named in a device library.
Example of Fixed Node Options: ALL refers to all families.
FIXED NODE OPTIONS
<value> Can be 1, 0, or X to indicate the logic level.
VCC Family TTL is 1;
V+ Family ALL is 1;
GND Family ALL is 0;
VCC Supply 1 at 5.0 volts, 1.2 amps;
GND Ground;

GP Relay Options Example 1-3 GPRELAY OPTIONS syntax
The GP Relay Options Form assigns general purpose GPRELAY OPTIONS

(GP) relays to pairs of nodes or individual nodes. GP GP <node_id>;
relays are located on the Control Card and the <preference list>;
AccessPlus Card. If you have both cards in your board GP <node_id> <options>;
<preference list>;
configuration file, then you can specify a card GP <node_id> <options>, <second node_id>;
preference for assigning GP relays. The fixturing <preference list>;
software will consider your preference when assigning
the GP resources. If no preference is specified, the <node_id> and <second node_id) are <string
system assigns GP relays from the Control Card first. constants>
The GP Relay Options are described in Table 1-12 on
<options> can be:
page 1-28. is HIGH
is LOW
<preference list> can be:

CONTROL;
ACCESS;
CONTROL; ACCESS;
ACCESS; CONTROL;
CONTROL, ACCESS;
ACCESS, CONTROL;
Example:
GPRELAY OPTIONS
GP "U1-2", "U1-3";
CONTROL; ACCESS;
GP N10 is HIGH,N11;
CONTROL, ACCESS;
GP EXT1 is HIGH;
ACCESS;

Table 1-14 GPRELAY OPTIONS
Option Description
<node_id> Name of a node.
is HIGH Assigns the high contact of the GP relay pair to the node.
is LOW Assigns the low contact of the GP relay pair to the node.
<second node_id> Name of the second node of a node pair. The node name must be preceded by a comma.
CONTROL; Only Control Card GP relays should be assigned.
ACCESS; Only AccessPlus Card GP relays should be assigned.
CONTROL; ACCESS; A preference of a Control Card GP relay over an AccessPlus Card GP relay. This is the default if
no card preference is specified. Semicolons as separators indicate a preference.
ACCESS; CONTROL; A preference of an AccessPlus Card GP relay over a Control Card GP relay. Semicolons as
separators indicate a preference.
CONTROL, ACCESS; No card preference for selection of GP relay. Commas as separators indicate equal preference.
ACCESS, CONTROL; No card preference for selection of GP relay. Commas as separators indicate equal preference.

Library Options ■ Tolerance Multiplier

Library Options contains an ordered list of directories ■ Remote Sensing
that Agilent IPG searches to locate library tests on each ■ Threshold
device. List custom library directory pathnames first to
guarantee that they override any standard libraries. This ■ Diode Current
also decreases the amount of time for IPG to find ■ Adjust
custom libraries.
■ Zener Current
Example 1-4 LIBRARY OPTIONS syntax: ■ Upstream Condition
LIBRARY OPTIONS ■ Upstream Disable
<library pathname>
<library pathname> Specifies the pathname of

the library to be searched. Quotes are
optional.
Example:
LIBRARY OPTIONS
custom_lib
“$AGILENT3070_ROOT/library/ttl"
“$AGILENT3070_ROOT/library/cmos";
Override
Use the OVERRIDE keyword to change one or more
device options for a specific component; include only
the options you wish to change. The override statement
must be placed immediately after the device definition
line for that component. The device options that can be
overridden are:

Example 1-5 OVERRIDE syntax DP1 PN"74ls174"; ! This is a

diode pack part description library.
OVERRIDE <option> <new value> OVERRIDE
Tolerance Multiplier 5;
<option> can be: Diode Current 2m;
Tolerance Multiplier
Remote Sensing
Threshold
Device Definitions
Diode Current Device definitions supply information about the devices
Adjust
Zener Current
on the board. Each component has its own device
Upstream Disable definition. Components of identical type are grouped
Upstream Condition together under the keyword for that type of device. Each
device definition contains information such as the name
<new value> must be a legal parameter for the or id for that component, its value (if there is one),
device type. tolerances or high and low values (where applicable),
Examples:
and various other measurement parameters. Device
CAPACITOR definitions can also have part number and message
"C1" .01u 10 5 f; entries. The message entries are failure messages which
OVERRIDE Tolerance Multiplier 1.0; are reported on the report device if the device fails.
DIODE
"CR1" 800m 300m; Each component entry under a device definition
OVERRIDE Remote Sensing ON; keyword must be terminated by a semi-colon (;).
FUSE
"F1" 3
OVERRIDE Threshold 1.5;
NOTE
POTENTIOMETER Quotes (") are optional on reference designators.
"P1" 10K 10 10 "Input A reference designator identifies a device or a
Offset Adjust";
device.pin. For more information, see Identifiers
OVERRIDE Adjust Accurate;
PIN LIBRARY (Reference Designators and Node Names) on
U101 PN"74ls174"; page 1-8.
OVERRIDE Upstream Disable OFF;

The device definition keywords are: specify if the capacitor is to be tested with Agilent
■ CAPACITOR
Polarity Check and not to be tested with an analog
■ CONNECTOR in-circuit capacitor test. If you specify Polarity Check,
■ DIODE you must also indicate which pin (1 or 2) is the negative
■ FET pin. The CAPACITOR syntax is shown in Example 1-6.
■ FUSE The options are described in Table 1-15.
■ INDUCTOR
■ JUMPER
■ NODE LIBRARY
■ PIN LIBRARY
■ POTENTIOMETER
■ RESISTOR
■ SWITCH
■ TRANSISTOR
■ ZENER
Each keyword is described in this section.
NOTE
Multiple Board Versions includes version labels
and not placed (NP) parameters in the device
definitions that are not included in the following
sections; see Chapter 5, Multiple Board Versions
in Optional Board Test Applications for details.
Capacitor
The CAPACITOR keyword indicates a list of capacitor
entries. The entries must include the capacitor name, its
capacitance, plus and minus tolerances, and the
capacitor type (fixed or variable). The capacitor part
number and failure message are optional. You can also

Example 1-6 CAPACITOR syntax
CAPACITOR
<device> <value> <+tol> <-tol> <type>;
<device> <value> <+tol> <-tol> <type> <options>;
<device> <value> <+tol> <-tol> <type> <component>;
<device> <value> <+tol> <-tol> <type> <options> <component>;
<device> is a <string constant>
<value>, <+tol>, <-tol> are <numeric constants>
<type> can be:

F
V
<options> can be:

PC <#>
NT
PC <#> NT
<#> is an integer that indicates the negative terminal of the capacitor
<component> can be:

PN<part number>
<failure message>
PN<part number> <message>
<part number> & <failure message> are <string constants>
Examples:
CAPACITOR
C1 10p 10 10 NT F;
"C4" 0.01n 10 5 V PN"0667-9384" "varies integration time";

Table 1-15 CAPACITOR options
Option Description
<device> Name of the capacitor (48 characters maximum).
<value> Value of the capacitor.
<+tol> and <-tol> The plus and minus tolerances as percentages of the capacitor value; both are positive numbers.
F The capacitor value is fixed.
V The capacitor value is variable.
<options> PC <#> Indicates that the device will be tested with Polarity Check and an analog in-circuit capacitor
test; NT specifies that the device will not be tested; PC <#> NT specifies that the device will be tested
with Polarity Check only.
PN<part number> The part number of the capacitor (24 characters maximum, no spaces allowed, must be in quotes).
<failure message> Failure message associated with the capacitor (40 Characters maximum, must be in quotes).
Connector automatically specified. The Connector options are

described in Table 1-16.
The CONNECTOR keyword indicates a list of
connector entries. After the CONNECTOR keyword,
you can enter any number of connectors by specifying
the connector name and an optional failure message.
Each entry is terminated by a semicolon. IPG does not
generate tests for connectors. The connector must be
specified as Not Tested (NT). If the connector is not
specified as NT a warning is issued and NT is

Example 1-7 CONNECTOR syntax
CONNECTOR Table 1-16 CONNECTOR options

<device> <test>;
<device> <test> <part number>; Option Description
<device> <test> <failure message>;
<device> <test> <part number> <failure <device> Name of the connector (48
message>; characters maximum).
<test> can be: NT or TJ Specifies no test or TestJet test.
NT
TJ <part number> The part number of the device (24
characters maximum).
<failure Failure message associated with the
<part number> is a <string constant> message> connector (maximum 40
characters).
<failure message> is a <string constant>
Examples:
CONNECTOR
A1 NT;
"J5" TJ"J5 located on top edge";

Diode and low voltages, and an optional failure message or

note.
The DIODE keyword indicates a list of diode entries.
The diode descriptions include: the diode name, its high Each entry is terminated by a semicolon. The Diode
options are described in Table 1-17 on page 1-39.
Example 1-8 DIODE syntax
<device> <hi-value> <lo-value>;

<device> <hi-value> <lo-value> <options>;
<device> <hi-value> <lo-value> <component>;
<device> <hi-value> <lo-value> <options> <component>;
<hi-value> & <lo-value> are <numeric constants>
<options> can be:

NT
<component> can be:

PN<part number>
<failure message>
PN<part number> <failure message>
Examples:
DIODE
"D1" .8 .4;
D2 .8 .4 NT;
"D3" .8 .4 PN"1801-9016";
D4 .8 .4 "part of bridge rectifier";
"D5" .8 .4 NT PN"1801-9016";

Table 1-17 DIODE options
Option Description
<device> Name of the diode (48 characters maximum).
<hi-value> The upper test limit, in volts, for the diodes forward bias voltage.
<lo-value> The lower test limit, in volts, for the diodes forward bias voltage.
NT The device will not be tested.
PN<part number> Part number of the diode (24 characters maximum, no spaces allowed, must be in quotes).
<failure message> A failure message associated with the diode (40 characters maximum, must be in quotes).
FET
The FET keyword indicates a list of FET entries. The
device description includes: FET name, high and low
resistance limits, type, and an optional failure message.
Each entry is terminated by a semicolon. The FET

Example 1-9 FET syntax
<device> <hi-res> <lo-res> <type>;

<device> <hi-res> <lo-res> <type> <options>;
<device> <hi-res> <lo-res> <type> <component>;
<device> <hi-res> <lo-res> <type> <options> <component>;
<hi-res> & <lo-res> are <numeric constants>
<type> can be:

N
P
<options> can be:

NT
<component> can be:
PN<part number>
<failure message>
Examples:
FET
"Q1" 200 100 N;
Q2 200 100 P NT;
"Q4" 200 100 P "Q4 is located at B7";

Table 1-18 FET options
Option Description
<device> Name of the FET (48 characters maximum).
<hi-res> The high resistance limit in ohms.
<lo-res> The low resistance limit in ohms.
N Specifies an N-channel FET.
P Specifies a P-channel FET.
NT The device is not tested.
PN<part number> Part number of the FET (24 characters maximum, no spaces allowed, must be in quotes).
<failure message> Failure message associated with the FET (40 characters maximum, must be in quotes).
Fuse
The FUSE keyword indicates a list of fuse entries. The
device description includes: the fuse name, its
maximum allowed current for testing, and optionally its
part number or failure message. The Fuse options are

Example 1-10 FUSE syntax
<device> <max-current>;
<device> <max-current> <options>;
<device> <max-current> <component>;
<device> <max-current> <options> <component>;
<max-current> is a <numeric constant>
<options> can be:

NT
<component> can be:

PN<part number>
<failure message>
Examples:
FUSE
"F1" 1.5;
F2 1.25 NT "fuse for +5 V supply";

Table 1-19 FUSE options
Option Description
<device> Name of the fuse (48 characters maximum).
<max-current> Maximum value of current in amps.
NT Device is not tested.
PN<part number> Part number of the fuse (24 characters maximum, no spaces allowed, must be in quotes).
<failure message> Failure message associated with the fuse (40 characters maximum, must be in quotes).
Inductor
The INDUCTOR keyword indicates a list of inductor
entries. The device description includes: the inductor
name, its inductance, plus and minus tolerances, its
series resistance, the inductor type (fixed or variable).
It can optionally include the part number, or a failure
message. Each entry is terminated by a semicolon. The
Inductor options are described in Table 1-20 on
page 1-45.

Example 1-11 INDUCTOR syntax
<dev> <val> <+tol> <-tol> <series-R> <type>;

<dev> <val> <+tol> <-tol> <series-R> <type> <options>;
<dev> <val> <+tol> <-tol> <series-R> <type> <component>;
<dev> <val> <+tol> <-tol> <series-R> <type> <options> <component>;
<dev> is a <string constant>
<val>, <+tol>, <-tol> & <series-R> are <numeric constants>
<type> can be:

F
V
<options> can be:

NT
<component> can be:
PN<part number>
<failure message>
Examples:
INDUCTOR
L1 10p 5 5 10 F;
"L2" 10u 5 5 10 V NT PN"349211A" "Tuning inductor"

Table 1-20 INDUCTOR options
Option Description
<dev> Name of the inductor (48 characters maximum).
<val> The value of the inductor, in Henries.
<+tol> and <-tol> Specify the plus and minus tolerances of the inductor, as a percentage of its value; both are
specified as positive numbers.
<series-R> The value of the series resistance, in ohms, of the inductor.
F The inductor is fixed.
V The inductor is variable.
PN<part number> Part number of the inductor (24 characters maximum, no spaces allowed, must be in quotes).
<failure message> Failure message associated with the inductor (40 characters maximum, must be in quotes).
Jumper
The JUMPER keyword indicates a list of jumper entries.
The device description includes: the jumper name, if it
is closed or open, and optionally its part number, or a
failure message or both. The Jumper options are

Example 1-12 JUMPER syntax
<device> <type>;
<device> <type> <options>;
<device> <type> <component>;
<device> <type> <options> <component>;
<type> can be:

O or OPEN
C or CLOSED
<options> can be:

NT
<component> can be:

PN<part number>
<failure message>
Examples:
JUMPER
"JMP1" CLOSED;
JMP2 O NT;
"JMP3" OPEN NT PN"123-456" "Jumper installed later";

Table 1-21 JUMPER options
Option Description
<device> Name of the jumper (48 characters maximum).
O or OPEN The jumper is open.
C or CLOSED The jumper is closed.
PN<part number> Part number of the jumper (24 characters maximum, no spaces allowed, must be in quotes).
<failure message> Failure message associated with the jumper (40 characters maximum, must be in quotes).
Node Library
The NODE LIBRARY keyword indicates a list of
node-oriented library entries. The device description
includes the device name. To specify that no test should
be generated for the device set the no test (NT) flag. You
can optionally include the device's library path name
and a failure message. The part number of the device is
only optional if you set the no test flag. Other options
include setting the status of flags such as safeguard off.
The Node Library options are described in Table 1-22
on page 1-48.

Example 1-13 NODE LIBRARY syntax
<device>;
<device> <options>;
<device> <component>;
<device> <options> <component>;
<options> can be:

NT
NS
<component> can be:

PN<part number>
PN<path/part_number>
PN<path/part_number> <failure message>
<part number>, <path/part_number> & <failure message> are <string constants>
Example:
NODE LIBRARY
filter PN"custom_lib/filter"NS"functional device";
whole NS"functional device";
Table 1-22 NODE LIBRARY options
Option Description
<device> Name of the node-oriented library device (48 characters maximum).
NS Safeguard information is not needed for this device.

Table 1-22 NODE LIBRARY options (continued)
Option Description
PN<part number> Part number of the device (24 characters maximum, no spaces allowed, must be in quotes). If not
specified, the part number is assumed to be the device name.
PN<path/part_number> The path for library for the specified device (must be in quotes).
<failure message> Failure message associated with the device (40 characters maximum, must be in quotes).
Pin Library identified by BSDL<bsdl_id>. The Pin Library options

are described in Table 1-23 on page 1-51.
The PIN LIBRARY keyword indicates a list of
pin-oriented library entries. The device description
includes a device name. A no test (NT) flag can be set to NOTE
specify that no test should be generated for the device. There can be any combination of <options>, <part
However, for boundary-scan devices, if TAPONLY and number>, <interconnect test>, and <failure
NT are specified, the device can still be used as part of a message>, but they must appear in the order
test for a boundary-scan-part chain. You can optionally shown in the syntax description.
include the device's part number, its library path name
and a failure message. If the no test (NT) flag is not set,
a part number must be entered or a syntax error will
occur. Other options include setting the status of flags
such as safeguard off.
If you have purchased InterconnectPlus software, you
can specify additional parameters for the
InterconnectPlus tests. InterconnectPlus tests can have
two different files: a VCL library and a BSDL library.
The VCL library is identified by PN<part_id>. The
BSDL library (used only for InterconnectPlus tests) is

Example 1-14 PIN LIBRARY syntax
PIN LIBRARY
<device>;
<device> <options>;
<device> <options> PN<part number>;
<device> <options> PN<part number> <interconnect test>;
<device> <options> PN<part number> <interconnect test> <failure message>;
<options> can be: <option>

<option> <option>
<option> <option> ... <option>
<option> can be:
NT
NS
TJ
LIB
CC
<part number> can be:

<part number>
<path/part_number>
<part_number>, <path/part_number> are <string constants>
<interconnect test> can be:
TS"1149_1" <scan_type> BSDL<bsdl_id> PKG<pkg_type>
TS"1149_1" <scan_type> LIB BSDL<bsdl_id> PKG<pkg_type>
<scan_type> can be:
TAPONLY
INTERCONNECTONLY
SCAN
<bsdl_id> can be:

<bsdl_filename>
<path/bsdl_filename>
<bsdl_filename> & <path/bsdl_filename> are <string constants>
<pkg_type> is a <string constant>
<failure message> is a <string constant>

Example:
PIN LIBRARY
U28 PN"74wb989";
AND2 PN"7400" "AND2 located at A-3";
RP1 NT PN"/net/parts/library/852-93444" "RP1 FAILED";
CHA PN"/net/cluster/library/line"NS"Channel A FAILED";
U21 PN"su812" TS"1149_1" SCAN LIB BSDL "su812bsdl" PKG"dip22"
U1 NT PN"8374" TS"1149_1" TAPONLY BSDL"74ct8374" PKG"DW_PACKAGE"
Table 1-23 PIN LIBRARY options
Option Description
<device> Name of the device (48 characters maximum).
NT The device is not tested (VCL and boundary-scan tests are not generated).
NS Safeguard information is not needed for the VCL device.
TJ The device will be tested with TestJet.
LIB The device will also be tested with a library test. This is used for boundary scan and TestJet.
CC The device will be tested with Connect Check.
PN<part number> Part number of the VCL device (24 characters maximum, no spaces allowed, must be in quotes).
This field is optional if the device is not tested.
PN<path/part_number> The library path name for the VCL device. This field is optional if the device is not tested.
TS"1149_1" Specifies that test standard 1149_1 will be used for the InterconnectPlus test.
TAPONLY The device might be used as part of a boundary-scan-part chain, but no interconnect or connect
tests will be generated (Test Access Points ONLY).

Table 1-23 PIN LIBRARY options (continued)
Option Description
INTERCONNECTONLY Pins on the device can be used in the interconnect test for the boundary-scan-part chain; no
connect tests are generated.
SCAN Interconnect and connect tests will be generated.
<bsdl_id> Part number of the device library file and optional pathname.
<pkg_type> The package type of the device.
<failure message> Failure message associated with the device (40 characters maximum, must be in quotes).
Potentiometer
The POTENTIOMETER keyword indicates a list of
potentiometer entries. The device description includes:
the potentiometer name, its resistance, plus and minus
tolerances, and optionally its part number, or a failure
message, or both. The Potentiometer options are

Example 1-15 POTENTIOMETER syntax
<device> <value> <+tol> <-tol>;

<device> <value> <+tol> <-tol> <options>;
<device> <value> <+tol> <-tol> <component>;
<device> <value> <+tol> <-tol> <options> <component>;
<value>, <+tol> & <-tol> are <numeric constants>
<options> can be:

NT
<component> can be:

PN<part number>
<failure message>
Examples:
POTENTIOMETER
"R109" 10k 50 50;
R2 1000 10 10 "located at P11";
"R63" 100 5 5 NT"part of voltage divider";

Table 1-24 POTENTIOMETER options
Option Description
<device> Name of the potentiometer (48 characters maximum).
<value> The value of the potentiometer.
<+tol> and <-tol> Plus and minus tolerances of the potentiometer; both are specified as positive numbers.
PN<part number> Part number of the potentiometer (24 characters maximum, no spaces allowed, must be in
quotes).
<failure message> Failure message associated with the potentiometer (40 characters maximum, must be in quotes).
Resistor
The RESISTOR keyword indicates a list of resistor
entries. The device description includes: the resistor
name, its resistance, plus and minus tolerances, the
resistor type (fixed or variable), and optionally its part
number and failure message. The Resistor options are

Example 1-16 RESISTOR syntax
<device> <value> <+tol> <-tol> <type>;

<device> <value> <+tol> <-tol> <type> <options>;
<device> <value> <+tol> <-tol> <type> <component>;
<device> <value> <+tol> <-tol> <type> <options> <component>;
<value>, <+tol> & <-tol> are <numeric constants>
<type> can be:

F
V
<options> can be:

NT
<component> can be:

PN<part number>
<failure message>
Examples:
RESISTOR
"R1" 10k 5 5 F;
R2 10M 25 25 V PN"09837-88394";
"R3" 10M 25 25 V NT PN"09837-88394" "DO NOT adjust resistor";

Table 1-25 RESISTOR options
Option Description
<device> Name of the resistor (48 characters maximum).
<value> The value of the resistor, in ohms.
<+tol> and <-tol> Specify the plus and minus tolerances of the resistor; both are specified as positive numbers.
F The resistor is fixed.
V The resistor is variable.
PN<part number> Part number of the resistor (24 characters maximum, no spaces allowed, must be in quotes).
<failure message> Failure message associated with the resistor (40 characters maximum, must be in quotes).
Switch Switch options are described in Table 1-26 on

page 1-58.
The SWITCH keyword indicates a list of switch entries.
The device description includes: the switch name, the
common-pin, the contact-pin if the switch is closed, and
optionally its part number, or a failure message, or both.
The common-pin and contact-pin are assumed to be
shorted together. Using OFF in place of the contact-pin
implies that the switch is open. The switch entry shows
only the common pin shorted to one other pin
(<contact pin>), or the common pin open (OFF). The

Example 1-17 SWITCH syntax
<device> <common-pin> <contact>;

<device> <common-pin> <contact> NT;
<device> <common-pin> <contact> <component>;
<device> <common-pin> <contact> NT <component>;
<device> & <common-pin> are <string constants> (quotes optional)
<contact> can be:

<contact-pin>
OFF
<contact-pin> is a <string constant> (quotes optional)
<component> can be:

PN<part number>
<failure message>
Examples:
SWITCH
"SW1"12; ! Switch 1 closed pin 1 to pin 2.
SW2 1 OFF; ! Switch 2 open, no closed contacts.
SW3 1 2 NT "Channel Selector";! Switch 3 closed and not tested.

Table 1-26 SWITCH options
Option Description
<device> Name of the switch (48 characters maximum)
<common-pin> The COMMON pin in the switch.
<contact-pin> The CONTACT pin in the switch.
OFF The switch is OFF; the contacts are open.
PN<part number> Part number of the switch (24 characters maximum, no spaces allowed, must be in quotes).
<failure message> Failure message associated with the switch (40 characters maximum, must be in quotes).
Transistor
The TRANSISTOR keyword indicates a list of
transistor entries. The device description includes: the
transistor name, its high and low beta values, its type
(npn or pnp), and optionally a part number, or a failure
message, or both. The Transistor options are described
in Table 1-27 on page 1-60.

Example 1-18 TRANSISTOR syntax
TRANSISTOR
<device> <hi-beta> <lo-beta> <type>;
<device> <hi-beta> <lo-beta> <type> <options>;
<device> <hi-beta> <lo-beta> <type> <component>;
<device> <hi-beta> <lo-beta> <type> <options> <component>;
<hi-beta> & <lo-beta> are <numeric constants>
<type> can be:

N
P
<options> can be:

NT
<component> can be:

PN<part number>
<failure message>
Examples:
TRANSISTOR
"Q1" 200 50 N;
Q2 200 50 P "Q2 located at C5";
"Q3" 200 50 N PN"1854-0056" "pre-amp";
"Q4" 250 50 P NT "Not Tested in-circuit";

Table 1-27 TRANSISTOR options
Option Description
<device> Name of the transistor (48 characters maximum).
<hi-beta> and <lo-beta> Specify the high and low limits for the transistor beta.
N The transistor is an NPN.
P The transistor is a PNP.
PN<part number> Part number of the transistor (24 characters maximum, no spaces allowed, must be in quotes).
<failure message> Failure message associated with the transistor (40 characters maximum, must be in quotes).
Zener
The ZENER keyword indicates a list of zener entries.
The device description includes: the zener name, its
voltage, plus and minus tolerances, and optionally a part
number, or failure message, or both. The Zener options

Example 1-19 ZENER syntax
ZENER
<device> <voltage> <+tol> <-tol>;
<device> <voltage> <+tol> <-tol> <options>;
<device> <voltage> <+tol> <-tol> <component>;
<device> <voltage> <+tol> <-tol> <options> <component>;
<voltage>, <+tol> & <-tol> are <numeric constants>
<options> can be:

NT
<component> can be:

PN<part number>
<failure message>
Example:
ZENER
"CR50" 5.6 5 5 "located at A7";
Table 1-28 ZENER options
Option Description
<device> Name of the zener (48 characters maximum).
<voltage> The breakdown voltage, in volts, of the zener.
<+tol> and <-tol> Specify the plus and minus tolerances of the zener, as a percentage of the zener's value; both
are specified as positive numbers.

Table 1-28 ZENER options (continued)
Option Description
PN<part number> Part number of the zener (24 characters maximum, no spaces allowed, must be in quotes).
<failure message> Failure message associated with the zener (40 characters maximum, must be in quotes).
Undefined Nodes
This is a temporary block for devices which have not NODES lists all nodes that are not listed under Devices
been defined by a device definition. Undefined devices or Connections.
must be resolved before the board file can be compiled.
Example 1-21 NODES syntax:
Example 1-20 UNDEFINED syntax:
NODES
UNDEFINED <node_id>
<device name> NT <node_id>
<device name> Specifies the name of the <node_id> Specifies the name of the node.
device which has been referenced in a
connection statement, but has not been Examples:
defined by a device definition. NODES
VCC "Main Power Bus";
Example: V+ "Aux Power Bus";
UNDEFINED BIAS "Converter Reference Level";
U11 NT;
CR4 NT;

Pin_Map path names on both systems. For example, the

$AGILENT3070_ROOT factory default value is
You can use a Pin_Map to translate device pin names. C:/Agilent3070. In this document, only path
This is useful when your CAD data file used pin names names using the environment variable are used. If
other than what Agilent Board Consultant accepts. For you must use actual path names, refer to older
example, your CAD data file may have specified versions of the documentation. Please see The
transistor pins as 1, 2, and 3, instead of E, B, and C as Root Directory Environment Variable in
required by Board Consultant. In this case, use a Administering Agilent 3070 MS Windows Systems
Pin_Map to translate the 1, 2, and 3 to E, B, and C. The for further information.
Pin_Map can be placed in the board_defaults file
which can reside in the local board directory, or under
$AGILENT3070_ROOT/standard. The Pin_Map can also The PIN_MAP keyword indicates a pin name mapping
be part of the board file. If no pin name mapping table table. The pin naming conventions required by board
exists, and the pin names are invalid, the compiler forms and the board compiler are shown in Table 1-29.
generates an error for each invalid pin name. These
errors are included in the list file (board.l) when you Table 1-29 PIN_MAP keywords
compile the board file with the list option. Pin mapping
occurs only once for the board file. Either the board Keyword Pin
compiler or the check board program performs this Pin Library Must match the library pin names
operation. Pin mapping is not allowed to occur more (e.g., 1, 2, 3)
than once because the original pin map could
recursively re-map the pins to an invalid state. Capacitor 1, 2
Fuse 1, 2
NOTE
Inductor 1, 2
With Agilent 3070 software revision 3070
04.00pa, an environment variable was created so Jumper/Strap 1, 2
that files can be easily transferred between
Resistor 1, 2
UNIX® and MS Windows® controllers, which
have different file systems. The environment Potentiometer 1, W(iper), 2
variable, $AGILENT3070_ROOT, replaces the upper

Table 1-29 PIN_MAP keywords (continued)
Keyword Pin
Diode A(node), C(athode)
Zener A(node), C(athode)
Transistor E(mitter), B(ase), C(ollector)
FET S(ource), G(ate), D(rain)
Connector Flexible
Switch Flexible
The maximum length of the input name is 80 characters.

The new pin name must be 8 characters or less. An error
results if the pin mapping leads to an error in pin name
uniqueness. Also, an error results for all devices in
which the device type was unknown and therefore, the
device could not be mapped. These devices are included
in the compiler list file (board.l).
The names must be separated by one or more blanks and
each pin map entry is terminated by a semicolon. More
than one original pin name can be mapped to the same
new pin name.
NOTE
Each PIN_MAP entry must be terminated by a
semicolon.

Example 1-22 PIN_MAP syntax N 2;

POTENTIOMETER
PIN_MAP 3 W;
<device type> DIODE
<old pin-id> <new pin-id>; 1 A;
<old pin-id> <new pin-id>; + A;
. . . 2 C;
<device type> - C;
<old pin-id> <new pin-id>; TRANSISTOR
<old pin-id> <new pin-id>; 1 E;
. . . 2 B;
END 3 C;
FET
<old pin-id> & <new pin-id> are <string N-Source S;
constants> N-Gate G;
N-Drain D;
<device type> can be: END
CAPACITOR
CONNECTOR
DIODE
Unconnected Pin
FET The UNCONNECTED PIN keyword specifies a symbol
FUSE
INDUCTOR
for a pin that is deliberately left unconnected. Any
JUMPER unconnected pins must be declared before the devices
PIN LIBRARY and connections sections of the board file. Fixture
POTENTIOMETER verify does not report these pins as errors.
RESISTOR
SWITCH Example 1-23
TRANSISTOR
ZENER
unconnected pin NC;
EAXAMPLE
PIN_MAP
CAPACITOR
P 1;

Connections Example 1-24

The CONNECTIONS keyword starts a list of the device UNCONNECTED PIN NC;
pins that are connected to each node. It is the CONNECTIONS
complement of the DEVICES keyword. The board file VCC
can contain CONNECTIONS or DEVICES or both. The RP1.1
RP1.2
last segment of the CONNECTIONS block lists the RP1.3
known unconnected pins. An unconnected pin is a pin U101.10;
that is defined as having no connections to it. The DATA0
unconnected pins list is defined by the U101.6
UNCONNECTED PIN keyword. Another list of pins, RP1.6
called DANGLING PINS (no connection to anything) DATA1
U101.7
can be appended to the end of the CONNECTIONS RP1.7
block. Dangling pins are pins discovered by the DATA2
compiler that were not defined as unconnected or U101.8
connected pins. RP1.8
input0
U101.1;
input1
U101.2;
input2
U101.3;
GND
U101.5;
NC
U101.9;
DANGLING PINS
U101.4;

Dangling Pins (DANGLING PIN) shows an empty string ("") for its
node.
Dangling pins are pins that are not defined as being
connected or unconnected. Dangling pins can appear in Example 1-25
both the CONNECTIONS and DEVICES blocks. If a
board translator, such as translate cad cannot find a DEVICES
connection definition for a pin, this pin is defined as RP1
dangling. The DANGLING PINS category in the 1.VCC
CONNECTIONS block lists all the device.pins that are 2.VCC
3.VCC
not defined in the CONNECTIONS block. A dangling 4.VCC
pin in the DEVICES block appears as a pair of empty 5.DATA0
quotes (""). Dangling pins are treated as unconnected 6.DATA1
pins. For examples, see both Device Definitions on 7.DATA2
page 1-33 and Connections on page 1-66. 8.DATA3;
R2
1.NC
Devices 2."" ! A dangling pin
The DEVICES keyword starts a list of the nodes
connected to each device pin. It is the complementary Critical Pins
representation of CONNECTIONS. The board file can
contain the DEVICES list, or the CONNECTIONS list, The CRITICAL PINS keyword starts a list of the device
or both. pins that require short wire length due to sensitive or
high speed measurements.
The device pin and the node name are separated by a
period (.). All pin.node combinations must be separated Example 1-26
by at least one blank, and each device pin.node set is
terminated by a semicolon. CRITICAL PINS
U102.12
Pins that are defined as unconnected show the Y1.3;
UNCONNECTED PIN id for their nodes. Any pin that
was not defined as connected or unconnected

Internal Structure Cross Checked Devices

Internal structure describes the parent-child hierarchy of BCF uses the Cross Checked Devices list to record
composite devices. Composite devices can be device devices that have been crosschecked in Board
packages such as resistor packs, switch packs, etc. or Consultant. It is not intended to be entered manually.
clusters of devices. Each parent device must list all of its
child devices using the Internal Structure description. A Cross Checked Nodes
parent device must be a PIN LIBRARY or NODE
LIBRARY component. A child device can be any type BCF uses the Cross Checked Nodes list to record nodes
of component, including PIN LIBRARY or NODE that have been cross-checked in Board Consultant. It is
LIBRARY. The hierarchy can be continued to any not intended to be entered manually.
depth, but the final children must be non-composite, that
is, they can have not children. The internal structure Disabling Information (Preconditioning)
keyword is repeated for each parent device. Disabling information specifies the conditioning or
disabling of a device, pin, or node on the board for a test
Example 1-27 or group of tests. Conditioning and disabling are
INTERNAL STRUCTURE filter;
referred to as preconditioning. Preconditioning sets a
U101; pin, node, or device to some specific state, and holds it
U102; there, to minimize its effect on the device under test.
U103;
U104;
NOTE
Refer to Chapter 2, Vector Control Language
NOTE (VCL) in Test Methods: Digital for more
information about preconditioning.
See Chapter 3, Creating Board Information in
Test and Fixture Development for instructions on
entering internal devices with Board Consultant. Preconditioning information is listed in the
DISABLING INFORMATION block.

Example 1-28 Disabling information syntax
condition nodes <node list> on <node library> for <device list>

condition pins <pin list> on <pin library> for <device list>
condition device <library> for <device list>
disable nodes <node list> on <node library> for <device list>
disable pins <pin list> on <pin library> for <device list>
disable device <library> for <device list>
set <node-id> to <state> for <device list>
set <node-id> to <state> family <family-id> for <device list>
The order of the statements specifies the order in which Device Node Preconditioning
the operations are done. For example, refer to the
You can specify to disable or condition a node or a list
ordering of the following statements:
of nodes of a node-oriented device. Preconditioning
disable device U1 for U3 information about each node is defined in the device's
disable device U2 for U3 test. The Device Node Preconditioning options are
disable device U4 for U3
Disabling will occur for U1 first, followed by U2, and
finally disabling U4, for testing device U3.
If you are adding a DISABLING INFORMATION
block, it must be located as the last block in the board
file, before the END statement. The DISABLING
INFORMATION block uses the previous definitions
listed in the DEVICES, NODES, and CONNECTIONS
blocks.
Each of these preconditioning statements is described in
the following sections.

Example 1-29 Device node preconditioning syntax
condition nodes <node list> on <node library> for <device list>

disable nodes <node list> on <node library> for <device list>
<node list> can be:

<node-id>
<node-id>, <node-id>
<node-id>, <node-id>, . . . <node-id>
<device list> can be:

ALL
ALL BUT <device>, <device>, . . . <device>
<device>
<device>, <device>
<device>, <device>, . . . <device>
<node-id>, <device>, and <node library> are <string constants>
Examples:
disable nodes lda on custom_dev
condition nodes out1, out2, out3 on U1 for U2, U3
disable nodes "out1" on "U1" for U5, U6

Table 1-30 Device node preconditioning options
Option Description
<node-id> Node of a node library that will be preconditioned for the device under test.
<device> A digital device under test that requires preconditioning for testing.
ALL All devices tested require preconditioning.
ALL BUT All devices tested, except those listed, require preconditioning.
<node library> Digital device defined as a node library. This device will be preconditioned for the device under
test.
Device Pin Preconditioning

You can specify to disable or condition a pin or a list of
pins of a pin-oriented device. Preconditioning
information about each pin is defined in the device's
test. The Device Pin Preconditioning options are

Example 1-30 Device pin preconditioning syntax
condition pins <pin list> on <pin library> for <device list>

disable pins <pin list> on <pin library> for <device list>
<pin list> can be:

<pin-id>
<pin-id>, <pin-id>
<pin-id>, <pin-id>, . . . <pin-id>

ALL
<device>
<device>, <device>
<pin-id>, <device>, and <pin library> are <string constants>

Examples:
disable pins 1,9 on custom_dev
condition pins 1,2,3 on U1 for U2, U3
disable pins "1", "2" on "U1" for U5, U6

Table 1-31 Device pin preconditioning options
Option Description
<pin-id> Specifies a pin of a pin library that will be preconditioned for the device under test.
<device> This is a digital device under test that requires preconditioning for testing.
ALL All devices tested require preconditioning.
<pin library> The digital device that has been defined as a pin library. This device will be preconditioned for the
device under test.
Board-Level Device Preconditioning

You can specify to disable or condition an entire device,
located anywhere on the board, for the device under test.
The preconditioning information is defined in the
device's test. The Board-Level Device Preconditioning

Example 1-31 Board-level device preconditioning syntax
condition device <library> for <device Table 1-32 Board-level device preconditioning options
list>
disable device <library> for <device list> Option Description
<device list> can be: <device> Device under test requires preconditioning
ALL for testing.
<device> ALL All devices tested require preconditioning.
<device>, <device>
<device>, <device>, . . . <device> ALL BUT All devices tested, except those listed,
require preconditioning.
<device> and <library> are <string constants>
<library> Digital device that has been defined as
Examples: either a pin library or a node library. This
disable device U1 for U2, U3
device will be preconditioned for the device
condition device U5 for U2
disable device "U1" for "U2", "U3" under test.
Board-Level Preconditioning of Individual Nodes

You can set a specific node, located anywhere on the
board, to a specified state for the device under test. The
Board-Level Preconditioning of Individual Nodes

Example 1-32 Board-level preconditioning of individual nodes syntax
set <node-id> to <state> for <device list>

set <node-id> to <state> family <family-id> for <device list>

ALL
<device>
<device>, <device>
<family-id> and <device> are <string constants>
<state> can be:

1
0
T
Examples:
set "en_out" to "1" family TTL for U1, U2, U3
set en_out to 0 for U4
set "LGB" family CMOS to T for U5, U6
Table 1-33 Board-level preconditioning of individual nodes options
Option Description
<node-id> Specifies a node on the board that will be preconditioned for the device under test.
<state> The state that the node will be set to. T toggles the state of the node.
ALL All devices tested require preconditioning of the node.

Table 1-33 Board-level preconditioning of individual nodes options (continued)
Option Description
<family-id> Name of the logic family associated with the node.
Boundary Scan Chains Boundary Scan Override turned on the global options
and you need to list the board object file (board.o).
This section lists the boundary scan chains. To make this
section appear in the board file, you need to have
Example 1-33 BOUNDARY SCAN CHAINS syntax
BOUNDARY SCAN CHAINS

<name of chain>
<tap signal list>
DEVICES
<device list>;

<device>
<device>, <device>
Example:
BOUNDARY SCAN CHAIN
u1_u4
TDI C_TDI
TDO C_TDO
TCK C_TCK
TMS C_TMS
DEVICES
u1, u2, u3, u4;

End
The End keyword marks the end of the board file, the
pin mapping table, and the device options. It has no
parameters. If more commands follow the End keyword,
they are ignored by the system.

Sample Board File Example 1-34
HEADING
"This is an example of a 3070 Family BCF syntax";
GLOBAL OPTIONS
Fixture Type EXPRESS;
Fixture Size BANK2;
Top Probes Allowed OFF;
Heavy Probe Force 8;
Light Probe Force 4;
Mechanical Density Threshold 800;
Vacuum Density Threshold 104;
Autofile 2395;
Test Strategy COMBINATIONAL;
WireWrapping AUTO;
Metric Units OFF;
Common Lead Resistance 0.1;
!(ohms) from probe to component.
Common Lead Inductance 1u;
!(Henries) from probe to component.
Capacitance Compensation ON;
IPG Digital Resistance Threshold 50;
!(ohms)
Preconditioning Levels 2;
Additional Board Voltage 20;
Boundary Scan Overdrive OFF;
Boundary Scan Disable ON;
Boundary Scan Chain Override ON;
DEVICE OPTIONS
Tolerance Multiplier 5.0;
Remote Sensing ON;
Fuse Threshold 3.0;
Diode Current 1m;
Zener Current .5m;
Adjust ACCURATE;
Upstream Disable ON;
Upstream Condition OFF;
END
FAMILY OPTIONS
TTL

Drive High3.5;
Drive Low 0.2;
Receive High 2.0;
Receive Low 0.8;
Edge Speed 100;
Open Input Default X;
Load NONE;
FIXED NODE OPTIONS
gnd Family ttl is 0;
vcc1 Family ttl is 1;
gnd GROUND;
vcc1 Supply 1 At 5 Volts, 0.5 Amps;
GPRELAY OPTIONS
GP "U102-7", "gnd";
CONTROL; ACCESS;
LIBRARY OPTIONS
custom_lib
/standard/library/ttl
/standard/library/cmos;
CARD OPTIONS
TTL
CHANNEL; HYBRID;
UNCONNECTED PIN NC;
CAPACITOR
C101 2.2u 10 10 f "C101 failed";
OVERRIDE Tolerance Multiplier 1.0;
C102 10u 10 10 f "C102 failed";
CONNECTOR
CONN101 NT "Ground connector";
DIODE
LED101 800m 300m "Monitors output pulses";
JUMPER
J101 Closed "Jumper 101 failed";
NODE LIBRARY
pulse_width NS "Measure pulse width of the output signal";
PIN LIBRARY
U101 PN"74ls02" "quad NOR gate";
U102 PN"ne555" "P101 must be centered";
POTENTIOMETER
P101 50k 10 10 "Clock Frequency Adjust";
RESISTOR
R101 10k 5 5 f "Time constant for one-shot";

R102 2.2k 5 5 f;
R103 1k 5 5 f;
OVERRIDE Remote Sensing On;
R104 10k 10 10 f "Reference for timer";
R105 47 5 5 f "Pull-up";
SWITCH
S101 1 2 "Clock signal switch";
TRANSISTOR
Q101 100 40 n "2n4401";
NODES
VCC1 "Main Power Bus";
GND "Ground";
PIN_MAP
CAPACITOR
P 1
N 2;
DIODE
1 A
2 C;
POTENTIOMETER
3 W;
TRANSISTOR
1 E
2 B
3 C;
END
CONNECTIONS
"c101-2"
C101.2
R101.2
U101.5
U101.6;
clock1
S101.1
U102.3;
gnd
C102.2
CONN101.1
CONN101.2
CONN101.3
CONN101.4
CONN101.5

CONN101.6
CONN101.7
CONN101.8
Q101.E
U101.7
U102.1;
input1
S101.2
U101.3;
"led101-c"
J101.2
LED101.C;
output1
J101.1
Q101.C
R103.2;
"r102-2"
Q101.B
R102.2;
"r105-2"
LED101.A
R105.2;
"u101-1"
C101.1
U101.1;
"u101-4"
R102.1
U101.2
U101.4;
"u102-2"
C102.1
P101.W
U102.2
U102.6;
"u102-7"
P101.1
R104.2
U102.7;
vcc1
R101.1
R103.1
R104.1
R105.1

U101.14
U102.4
U102.8;
NC
U101.8
U101.9
U101.10
U101.11
U101.12
U101.13
U102.5
P101.2;
DEVICES
C101
1."u101-1"
2."c101-2";
C102
1."u102-2"
2.gnd;
CONN101
1.gnd
2.gnd
3.gnd
4.gnd
5.gnd
6.gnd
7.gnd
8.gnd;
LED101
A."r105-2"
C."led101-c";
J101
1.output1
2."led101-c";
U101
1."u101-1"
2."u101-4"
3.input1
4."u101-4"
5."c101-2"
6."c101-2"
7.gnd
8.NC

9.NC
10.NC
11.NC
12.NC
13.NC
14.vcc1;
U102
1.gnd
2."u102-2"
3.clock1
4.vcc1
5.NC
6."u102-2"
7."u102-7"
8.vcc1;
P101
1."u102-7"
2.NC
W."u102-2";
R101
1.vcc1
2."c101-2";
R102
1."u101-4"
2."r102-2";
R103
1.vcc1
2.output1;
R104
1.vcc1
2."u102-7";
R105
1.vcc1
2."r105-2";
S101
1.clock1
2.input1;
Q101
B."r102-2"
C.output1
E.gnd;
CRITICAL PINS
s101.1

q101.C;
DISABLING INFORMATION
SET "u101-1" TO 1 FOR ALL;
SET "u101-4" TO 0 FAMILY TTL FOR u102;
CONDITION PINS 2,4,5 ON u101 for ALL;
DISABLE DEVICE u102 for u101;
BOUNDARY SCAN CHAINS
u1_u4
TDI C_TDI
TDO C_TDO
TCK C_TCK
TMS C_TMS
DEVICES
u1, u2, u3, u4;
END

2 The board_xy File
■ What is a board_xy File?, 2-4
■ Programs that Use the board_xy File, 2-7
■ board_xy File Syntax, 2-9
■ Sample board_xy File, 2-27
Objectives
able to:
■ Understand the structure and syntax of the
board_xy file
Prerequisites
chapter.

using this chapter.

Chapter 2: The board_xy File
Overview This chapter describes the structure and syntax of the Modifying/ Viewing the Data in the board_xy File
board_xy file. This file contains X-Y data, such as
device pin and probe locations, of the circuit board to be NOTE
tested.
Do not edit board test files with shell editors such
as vi. These editors do not update the file's header
NOTE
information, such as the time-stamp, that Agilent
Using the board_xy file in the test generation 3070 programs use. Instead, use the BT-BASIC
process and to customize your test fixture files is editor to edit board test files.
described in Chapter 3, Creating Board
Information in Test & Fixture Development.
1 Modify the board_xy File from Board Consultant.
The Fixture Generation Software uses the X-Y data a Modify entry forms.
from the board_xy.o file to produce the fixture.o
file. b Compile board_xy file by clicking on Final
Compile/Verify.
The test generation (IPG) step of the test generation
process uses the node and location specifications of the
board_xy.o file.
NOTE
See Chapter 2, Agilent Board Consultant in Test
NOTE Development Tools for more information on
modifying entry forms.
Optional board_xy file statements are not
described in this chapter. These statements are
available with optional software packages such as
the PanelTest option. For information about such
statements, refer to the documentation in the
optional package.

2 Modify the board_xy File from IPG Test

Consultant.
a Click Edit.
b Select View/Edit board_xy File.
IPG Test Consultant opens a BT-BASIC window
and loads the board_xy file into the BT-BASIC
workspace for you to edit.
3 Modify the board_xy File manually.

c Generate a board_xy source file from the
board_xy.o object file if the board_xy source
file doesn’t exist. Type:
list object "board_xy.o" to "board_xy"
d Load the board_xy file. Type:

load "board_xy"
e Edit the board_xy file.

f Save the board_xy file. Type:
re-store "board_xy"

What is a board_xy The board_xy file contains X-Y data of the circuit OUTLINE
board to be tested. This data includes X-Y coordinates TOOLING
File? of the device pins, board outline, keepout areas, and KEEPOUT
NODE
tooling pin holes. X-Y locations of device.pins are listed ALTERNATES
in the OTHER section. X-Y locations that are associated EXTRAS
with a node are listed in the NODE section. Also OTHER
included in the board_xy file are probe type and ALTERNATES
location attributes. This data is in a special format used EXTRAS
by the 3070 family of board test systems. You can use GROUP
DEVICES
data from a CAD system, or from a digitize process. END
CamCAD translates X-Y location information into the
format used by the 3070 Family, and stores that data in The board_xy file may specify the data listed in Table
the <file>.brd and <file>.bxy files. You must then 2-1.
rename the <file>.brd and <file>.bxy files to board
and board_xy, respectively.
NOTE
CamCAD is explained in Chapter 3, Creating
Board Information in Test & Fixture
Development.
The following outline of a board_xy file shows the

keywords used in the file. Some of the keywords are
optional.
SCALE
UNITS
INCLUDE
PLACEMENT

Table 2-1 board_xy data
Data Description
Board OUTLINE The points that define the corners, at the maximum extents, of the board. The coordinates of the
points can be listed in either a clockwise or counterclockwise direction starting at the lower left
corner.
TOOLING hole A list of all tooling hole locations.
locations
Board PLACEMENT The position of the board on the test fixture as X and Y offsets from the fixture origin to the board
origin. The placement specification also includes a rotation of the board.
KEEPOUT areas Areas where no personality pins or probes should be placed due to something (such as a device
on the board) blocking that area of the fixture. Keepout areas are specified as coordinates of the
outside points (at least three) of a polygon that describes the area. The coordinates of the points
can be listed in either a clockwise or counterclockwise direction starting at the lower left corner.
NO_PROBE nodes and Nodes and locations that cannot, or should not, be probed by the fixture.
locations
NO_MANUAL nodes Nodes and locations that are not accessible with the guided probe.
and locations
NO_ACCESS nodes Nodes and locations that cannot, or should not, be probed by the fixture, and are not accessible
and locations with the guided probe. EXTRA locations cannot be specified as NO_ACCESS.
LONG probes Nodes that require long probes for dual-stage testing (not allowed for the SimPlate fixture).
50MIL probes Specifies a 50 mil probe. In the case of long probes, 100 mil probes will be used even if 50 mil is
specified.

Table 2-1 board_xy data (continued)
Data Description
CRITICAL nodes and Nodes and locations that require short wire lengths due to sensitive or high-speed
locations measurements. Nodes probed from the top side of an Express Cassette fixture cannot be
specified as CRITICAL.
MANDATORY locations Forces the use of the location with this attribute. You can specify multiple MANDATORY locations
on a node; all mandatory locations on a node will be wired to the same personality pins. If Probe
Select cannot use the mandatory location, it will use another of the alternates and issue a notice.
PREFERRED locations This location should be used unless it causes a mechanical conflict such as density or
accessibility. PREFERRED overrides all electrical considerations. You can specify more than one
location as PREFERRED. Probe Select will choose from these preferred locations first before
selecting an alternate location.
EXTRA locations Locations that are labeled as EXTRA will not be used for probe locations but will be passed on to
fixture.o as alternates so that they can be considered for use in the future.
TOP locations Probe locations that are only accessible from the top side of the board under test. Nodes which
are probed from the top side of the fixture cannot be specified as CRITICAL.
UNRELIABLE locations Probe locations that should only be used if no others are available. These locations are physically
unreliable.
BOTH locations Probe locations that are accessible from the top and bottom sides of the board under test.
GROUP Groups of device.pins that are to be wired together. Groups must be labeled MANDATORY.

Programs that Use The test and fixture generation process for the Agilent Because X-Y locations are not used for the SimPlate
No-Wire Technology, XG-50, SimPlate Express, XG-50 fixture, you can use asterisks, **, in place of X-Y
the board_xy File Cassette, and the Express Cassette fixtures requires a locations in the board_xy file. See the syntax definition
board_xy file. You can optionally use a board_xy file of the ALTERNATES - (OTHER),
to generate the fixture files and reports for the SimPlate EXTRAS - (OTHER), and GROUPS statements later in
fixture to specify nodes that cannot, or should not, be this chapter.
probed.
The programs listed in Table 2-2 create or use the
If you want to develop an edge connector only test or board_xy and board_xy.o files during the test and
use Groups for special wiring, you must provide a fixture generation process.
board_xy file no matter which fixture you are using.
Table 2-2 Programs that use the board_xy file
Program Description
CamCAD Translates X-Y location information into the format used by the 3070 Family, and stores that data in the
<file>.brd and <file>.bxy files. (You must rename the <file>.brd and <file>.bxy files to
board and board_xy, respectively.)
BOARD Determines the position (X-Y placement) of the board on the fixture using the board outline coordinates
PLACEMENT from the board_xy file. You can manually specify a board placement in the board_xy file. If Board
Placement finds a placement specified in board_xy it will use it; otherwise, Board Placement will place the
board automatically.
PROBE Uses location and probe information from board_xy, and board information from board to determine the
SELECT best type of probe and probing location for each node. You can influence the selection of probes and
locations by editing the board_xy file.

Table 2-2 Programs that use the board_xy file (continued)
Program Description
IPG Uses node accessibility information when writing device tests.
PLOT Creates a file from the data in the board_xy file that you can copy to a plotter to verify the data in the
GENERATOR board_xy file.
WEB
SERVICE

board_xy File This section describes the syntax of the board_xy file. would specify units as inches, and scale as 0.01. The
The syntax of the board_xy file is not case sensitive and SCALE and UNITS values will be used when the
Syntax each line of information (not list headings) must end board_xy file is compiled to convert all units to tenth
with a semicolon. Node and device.pin names cannot mils for the board_xy.o file. If you don't specify any
contain colons (:) or tildes (~). The board_xy syntax scale, a scale of 1 will be used.
includes these keywords:
Scale Syntax:
■ SCALE scale <value>;
■ UNITS <value> = scale factor for the numeric
■ INCLUDE values read from the input file.
■ PLACEMENT
Example:
■ OUTLINE
■ TOOLING scale .01;
■ KEEPOUT
■ NODE Units
■ ALTERNATES (NODE)
■ EXTRAS (NODE) The UNITS keyword specifies the units of the X and Y
■ OTHER coordinates. The SCALE and UNITS values will be
■ ALTERNATES (OTHER) used when the board_xy file is compiled to convert all
■ EXTRAS (OTHER) units to tenth mils for the board_xy.o file. If you don't
■ GROUP specify any units, inches will be used.
■ DEVICES Units Syntax:
■ END
UNITS <unit>;
Scale
<unit> can be:
The SCALE keyword specifies a scale factor that the inches
input coordinates will be multiplied by, to put them in mils
the specified units. For example, if the input data is in cm
hundredths of inches (500 = 5.00 inches), then you mm

Example: <filename> Specifies the name of the file whose

units inches;
contents are to be included in the board_xy file.
Include Placement
The INCLUDE keyword allows the contents of a Use the PLACEMENT keyword to instruct Board
specified file to be inserted at that point in the file. Placement where to position the board on the fixture.
Include statements can be nested to any depth; this is
useful for incorporating standard options and NOTE
configurations into new board files. When the new file For more information, see Chapter 4, Generating
is stored, the information from the include file becomes Tests and Fixture Files in Test & Fixture
part of the new file, and the link to the include file is Development.
lost. The include filename can be a relative or an
absolute pathname. The filename must be enclosed in
quotes. The PLACEMENT keyword specifies the position of
the board as X and Y offsets from the fixture origin to
Include Syntax: the board origin. The PLACEMENT keyword also
INCLUDE <filename>; specifies the rotation of the board. The placement
specification in the board_xy file must include all three
<filename> is a <string expression> parameters X offset, Y offset, and rotation. The rotation
Example: is applied first, then the X and Y offsets. Placement
options are described in Table 2-3.
Example 2-1 PLACEMENT syntax
PLACEMENT <x_offset>, <y_offset> <rotation>;
<x_offset>, <y_offset>, and <rotation> are <numeric constants>

Example:
PLACEMENT 70362, -10198 90;

Outline
Table 2-3 PLACEMENT options The OUTLINE keyword specifies a series of points that
define the corners, at the maximum extents, of the
Option Description board. List the bottom left corner of the board first; then
continue listing the coordinates of the corners in either a
<x_offset> x_offset of the board origin with respect to
clockwise or counterclockwise around the board.
the fixture origin.
You do not need to list the origin again at the end; the
<y_offset> y_offset of the board origin with respect to compiler automatically completes the polygon. Circular
the fixture origin. board outlines must be entered as polygons. Table 2-4
<rotation> Rotation of the board in degrees. The describes Outline options.
positive X axis is 0 degrees. See Figure
2-1. Example 2-2 OUTLINE syntax
OUTLINE
Figure 2-1 <x_coord>, <y_coord>
<x_coord>, <y_coord>
. . . . , . . . .
. . . . , . . . .
<x_coord>, <y_coord>;
<x_coord> & <y_coord> are <numeric constants>
Example:
OUTLINE
0, 0
150000, 0
150000, 120000
60000, 120000
60000, 110000
0, 110000;

Figure 2-2
(60000, 120000) (150000, 120000) Table 2-4 OUTLINE options

(0, 110000)
(60000, 110000) Option Description
<x_coord> x_coordinate of the outline point.
<y_coord> y_coordinate of the outline point.
Tooling
The TOOLING keyword marks the beginning of a list of
all tooling holes. This list is needed to avoid conflicts
with personality pins. Tooling options are described in
(0, 0) (150000, 0) Table 2-5.
Example 2-3 TOOLING syntax
TOOLING
<size> <x_coord>, <y_coord>;
. . . . . . , . . . .
. . . . . . , . . . .
<size>, <x_coord>, and <y_coord> are <numeric constants>

Example:
TOOLING
3750 2010,2000;
3750 2000,13000;
Table 2-5 TOOLING options
Option Description
<size> Diameter of the tooling pin hole. This value can be 2000 or 3750.
<x_coord> x_coordinate of the tooling hole.
<y_coord> y_coordinate of the tooling hole.
Keepout one keepout area. Keepout options are described in

Table 2-6.
The KEEPOUT keyword specifies a series of points that
define a polygon (at least three non-collinear points) Table 2-6 KEEPOUT options
that describe an area of the board where no personality
pins or probes can be placed. The points can be listed in Option Description
either a clockwise or counterclockwise direction starting
<x_coord> x_coordinate of the keepout point.
at any corner. The Fixture Generation Software reads
this information from the board_xy file and places it in <y_coord> y_coordinate of the keepout point.
the fixture.o file. Each KEEPOUT keyword specifies
BOTTOM Designates a keepout area on the
bottom probe plate. When no side is
specified, bottom is the default.

Table 2-6 KEEPOUT options (continued) Example:

KEEPOUT BOTH
Option Description
20000, 20000
TOP Designates a keepout area on the top 40000, 20000
40000, 40000
probe plate. 20000, 40000;
BOTH Designates a keepout area on both the
top and bottom probe plates. Node
The NODE keyword identifies the node for which X-Y
Example 2-4 KEEPOUT syntax probe locations will be given as alternate locations to
probe. You can specify some attributes of the node. The
KEEPOUT NODE keyword marks the beginning of a list of all
alternate probe locations for that node which are
. . . . , . . . . associated with a node, but not with a device.pin. The
. . . . , . . . . Node options are described in Table 2-7.
<x_coord>, <y_coord>;
KEEPOUT <attribute> Example 2-5 NODE syntax
<x_coord>, <y_coord> NODE <node_id>
. . . . , . . . . NODE <node_id> <attributes>
. . . . , . . . .
<x_coord>, <y_coord>; <node-id> is a <string constant>
<attributes> can be:

<attribute> can be:
<attribute>
BOTTOM <attribute> <attribute>
TOP <attribute> <attribute> . . . <attribute>
BOTH <attribute> can be:
<x_coord> & <y_coord> are <numeric NO_PROBE
constants> NO_MANUAL
NO_ACCESS

LONG Table 2-7 NODE options (continued)

CRITICAL
Option Description
Example:
NODE "HI-Z" NO_PROBE LONG This node requires a long probe for dual
NODE "NODE_A" NO_MANUAL stage testing.
NODE "NODE_B" NO_ACCESS
NODE "R1-2" CRITICAL CRITICAL This node requires a short wire due to a
NODE "SW2-3" LONG sensitive or high speed measurement.
NODE "SW3-4" CRITICAL LONG
NODE "SW3-5" CRITICAL NO_MANUAL
Alternates - (Node)
The ALTERNATES keyword, when used in conjunction
with NODE keyword, declares possible probe locations
Table 2-7 NODE options associated with that node, but not associated with a
device.pin. Alternates options are described in Table
Option Description
2-8 on page 2-17.
<node-id> Node name.
NO_PROBE Node should not, or cannot, be probed
by the fixture even if the X-Y location
information is available.
NO_MANUAL Node is not accessible with the guided
probe.
NO_ACCESS Node should not, or cannot, be probed
by the fixture, and is not accessible with
the guided probe.

Example 2-6 ALTERNATES syntax
ALTERNATES
<alternate_info>;
. . .
<alternate_info>;
<alternate_info> can be:
<x_coord>, <y_coord> <options>
<options> can be:

<side>
<size>
<status>
<side> <size>
<side> <status>
<size> <status>
<side> <size> <status>
<side> can be:

TOP
BOTH
<size> can be:

50MIL
<status> can be:

<probe access>
NO_MANUAL
<probe access> NO_MANUAL
<probe access> can be:

NO_PROBE
NO_ACCESS
UNRELIABLE
PREFERRED
MANDATORY
CRITICAL
EXTRA
Example:
NODE Data0
ALTERNATES
23400,56700 BOTH;
34500,67800 MANDATORY;
45600,78900 NO_PROBE;
55600,78900 PREFERRED NO_MANUAL;
65600,78900 NO_ACCESS;
Table 2-8 ALTERNATES options
Option Description
<x_coord> x_coordinate of the node with respect to the board origin.
<y_coord> y_coordinate of the node with respect to the board origin.
TOP Location is accessible only from the top side of the board.
BOTH Location is accessible from the top and bottom sides of the board.
50MIL Forces the use of a 50 mil probe instead of a 100 mil probe for that location. If the same location
is specified as LONG, a 100 mil probe is used even if 50 mil is specified and a notice is issued.
NO_PROBE This location cannot, or should not, be probed.
NO_MANUAL Location is not accessible with the guided probe.

Table 2-8 ALTERNATES options (continued)
Option Description
NO_ACCESS Location should not, or cannot, be probed by the fixture, and is not accessible with the guided
probe.
UNRELIABLE Location that should be used only if no other locations are available. These locations are
physically unreliable.
PREFERRED This location should be used unless it causes a mechanical conflict such as density or
accessibility; preferred overrides all electrical considerations. You can specify more than one
location as preferred; Probe Select will choose from the preferred locations first. If a preferred
location cannot be used, Probe Select will use another alternate location.
MANDATORY Forces the use of the location with this attribute. You can specify multiple mandatory locations
on a node; all mandatory locations on a node will be wired to the same personality pins. You can
force the use of a top side location by specifying it as mandatory. If Probe Select cannot use the
mandatory location, it will use another alternate location and issue a notice.
CRITICAL Location requires a short wire due to a sensitive or high-speed measurement.
EXTRA Locations that are labeled as extra will not be used for probe locations but will be passed on to
Extras - (Node) considered for future use. The Extras options are
The EXTRAS keyword, when used in conjunction with
NODE keyword, declares extra probe locations
associated with that node, but not associated with a
device.pin. Extra locations are not used for probes, but
are passed on to fixture.o as alternates to be

Example 2-7 EXTRAS syntax
EXTRAS
<extra_info>;
<extra_info>;
. . .
<extra_info>;
<extra_info> can be: <x_coord>, <y_coord>

<options> can be:
<side>
<size>
<side> <size>
NO_MANUAL
<side> can be:
TOP
BOTH
<size> can be: 50MIL
Example:
NODE Data0
EXTRAS
12300,45600;
23400,56700 BOTH;
34500,67800 TOP;
45600,78900 50MIL;
55600,78900 NO_MANUAL

Table 2-9 EXTRAS options
Option Description
<x_coord> <y_coord> X and Y coordinates of the node with respect to the board origin.
Other are associated with device.pins. The Alternates options

The OTHER keyword marks the beginning of a list of
X-Y locations that are associated with a device.pin. The
only items that can be included in this list are
ALTERNATES and EXTRAS.
Other Syntax:
OTHER
The OTHER keyword has no parameters.
Alternates - (Other)
The ALTERNATES keyword, when used in conjunction
with the OTHER keyword, marks the beginning of a list
containing X-Y locations, and their accessibility, which

Example 2-8 ALTERNATES syntax
ALTERNATES
<alternate_info>;
. . .
<alternate_info>;
<alternate_info> can be:<x_coord>, <y_coord>
<x_coord>, <y_coord> <dev.pin>
<x_coord>, <y_coord> <dev.pin> <options>
<x_coord> and <y_coord> are <numeric constants>
<dev.pin> is a <string constant>
<options> can be:
<side>
<size>
<status>
<side> <size>
<side> <status>
<size> <status>
<side> <size> <status>
<side> can be:
TOP
BOTH
<size> can be:

50MIL
<status> can be:

<probe access>
NO_MANUAL
<probe access> NO_MANUAL
<probe access> can be:

NO_PROBE
NO_ACCESS
UNRELIABLE
PREFERRED
MANDATORY
CRITICAL
EXTRA
Example:
OTHER
ALTERNATES
10000, 20000 U101.1 NO_PROBE;
10000, 21000;
10000, 22000 U101.3 UNRELIABLE;
10000, 23000 U101.4 NO_ACCESS;
20000, 23000 U101.5 MANDATORY;
OTHER
ALTERNATES
7000, 9000 U5.1;
** U6.1;
Option Description
<x_coord> X andY coordinates of the node with respect to the board origin. For the SimPlate fixture you can specify
<y_coord> a default location by using asterisks (**) for the X and Y coordinates.
50MIL Forces the use of a 50 mil probe instead of a 100 mil probe for that location. If the same location is
specified as LONG, a 100 mil probe is used even if 50 mil is specified and a notice is issued.
NO_PROBE This location cannot, or should not, be probed by the fixture.

Table 2-10 ALTERNATES options (continued)
Option Description
NO_ACCESS Location should not, or cannot, be probed by the fixture, and is not accessible with the guided probe.
UNRELIABLE Location that should be used only if no other location is available. These locations are physically
unreliable.
PREFERRED This location should be used unless it causes a mechanical conflict such as density or accessibility;
PREFERRED overrides all electrical considerations. You can specify more than one location as
PREFERRED; Probe Select will choose from preferred locations first. If a preferred location cannot be
used, Probe Select will use another alternate location.
MANDATORY Forces the use of the location with this attribute. You can specify multiple MANDATORY locations on a
node; all mandatory locations on a node are wired to the same personality pins. You can force the use of
a top side location by specifying it as MANDATORY. If Probe Select cannot use the mandatory location, it
uses another alternate location and issues a notice.
CRITICAL Location requires a short wire due to a sensitive or high-speed measurement.
EXTRA Locations that are labeled as EXTRA will not be used for probe locations but will be passed on to
Extras - (Other)
The EXTRAS keyword, when used in conjunction with
the OTHER keyword, marks the beginning of a list
containing X-Y locations of extra device.pins and their
accessibility. These locations will be passed on to
fixture.o as alternates to be considered for probing
locations in the future. The Extras options are described

Example 2-9 EXTRAS syntax
EXTRAS
<extra_info>;
. . .
<extra_info>;
<extra_info> can be:
<x_coord>, <y_coord> <dev.pin>
<x_coord>, <y_coord> <dev.pin> <options>
<options> can be:
<side>
<size>
<side> <size>
NO_MANUAL
<side> can be:
TOP
BOTH
<size> can be:50MIL
Examples:
OTHER
EXTRAS
10000, 20000 U101.1 TOP;
10000, 21000;
10000, 22000 U101.3 BOTH;
10000, 23000 U101.4 NO_MANUAL;
20000, 23000 U101.5 50MIL;
OTHER
EXTRAS
4000, 5000 U7.1;
** U8.1;

Table 2-11 EXTRAS options
Option Description
<x_coord> <y_coord> X and Y coordinates of the node with respect to the board origin. For the SimPlate fixture you can
specify a default location by using asterisks (**) for the X and Y coordinates.
Group group. The maximum separation for a COAX group is

0.5 inches; the maximum separation for a TWISTED
The GROUP keyword marks the beginning of a list, or group is 1.0 inch. The Group options are described in
lists, of device.pins that are to be wired in matched Table 2-12.
pairs. The GROUP keyword also specifies the type of
wiring to be used. Device.pins of a group are separated Example 2-10 GROUP syntax
by a comma (,). Groups are separated by a semicolon (;).
Because the GROUP keyword specifies the type of wire GROUP <wire type> MANDATORY
to be used, only groups of the type specified can be <dev.pin>, <dev.pin>;
listed under that keyword. .
.
Groups must consist of two device.pins that are located .
on the bottom of the board. The board_xy compiler will <dev.pin>, <dev.pin>;
determine if the distance between the device.pins <wire type> can be:
specified in a group is too great for the wire type of that

TWISTED of the board; top side devices are not listed. This is for
COAX TestJet and for Board Graphics.
Example:
Examples:
DEVICES
GROUP TWISTED MANDATORY u3 bottom;
u1.1, u2.1; u20 bottom;
u2.2, u3.2;
GROUP COAX MANDATORY
u1.4, u2.4; End
The END keyword marks the end of the board_xy file.
End Syntax:
Table 2-12 GROUP options END
Option Description
TWISTED The grouped locations be wired with a
twisted-pair cable.
COAX The grouped locations be wired with a
coaxial cable.
Devices
The DEVICES keyword marks the beginning of a list of
devices that were designated as being on the bottom side

Sample board_xy Listed below is a sample board_xy file: OTHER

ALTERNATES
File OUTLINE 10000, 20000 U101.1 NO_PROBE;
0, 0 10000, 21000 U101.2 MANDATORY;
150000, 0 10000, 22000 U101.3 UNRELIABLE;
150000, 120000 10000, 23000 U101.4 NO_ACCESS;
60000, 120000 10000, 24000 U101.5 MANDATORY;
60000, 110000 10000, 25000 U101.6 MANDATORY;
0, 110000; 10000, 26000 U101.7 MANDATORY;
TOOLING 10000, 27000 U101.8 MANDATORY;
3750 2000, 2000; 20000, 27000 U101.9 MANDATORY;
3750 2000, 108000; 20000, 26000 U101.10 MANDATORY;
KEEPOUT 20000, 25000 U101.11;
20000, 20000 EXTRAS
40000, 20000 95600, 12300 Y1.1 TOP;
40000, 40000 96600, 12500 U102.1 NO_MANUAL;
20000, 40000; 96600, 13500 U102.2 BOTH;
NODE "HI-Z" NO_PROBE 96600, 14500 U102.3 50MIL;
NODE BIAS GROUP TWISTED MANDATORY
ALTERNATES U101.2, U101.5;
32500, 76900; U101.6, U101.7;
NODE Clock GROUP COAX MANDATORY
ALTERNATES U101.9, U101.10;
10490, 24980; DEVICES
10490, 24980 TOP; U10 bottom;
NODE Data0 U11 bottom;
ALTERNATES U12 bottom;
12300, 45600; END
23400, 56700 BOTH;
34500, 67800 NO_PROBE;
44500, 78900 NO_ACCESS;
EXTRAS
45600, 78900;
55600, 88900 NO_MANUAL;

3 The Testorder File
In this chapter... ■ Introduction, 3-2
■ Testorder Syntax, 3-4
■ Sample Testorder File, 3-10
Objectives
able to:
testorder file
Prerequisites
chapter.

There are no required tools and materials associated
with this chapter.
© Agilent Technologies 2002, 2003 Data Formats 3-1

06/2003
Chapter 3: The Testorder File
Introduction The testorder file contains a list of all tests that are a You can edit the testorder file also to influence test
part of this board. The entry for each test includes the generation as shown in Table 3-1.
type of test (resistor, digital, mixed...), the name of the
test, and optional test attributes such as permanent, Table 3-1 Test generation commands
nulltest, and power.
Command Description
The testorder file is an output of IPG. You can,
however, manually create or edit this file. IPG Instructs IPG which tests to not
re-generate during incremental runs. IPG
The testorder file is an input to: IPG, IPG Test will not re-generate tests that are labeled
Consultant, Testplan Generator (TPG), and Module Pin with the permanent keyword.
Assignment (MPA).
Testplan Instructs TPG which tests to include in the
The tests in each category (analog in-circuit, digital...)
Generator testplan. The optional testplan
will be executed in the order in which they are listed in
the testorder file. However, the different categories of (TPG) generation on/off statement also
tests may be listed in different orders depending on how instructs TPG whether or not to generate
the file was generated. a new testplan.
You can edit the testorder file prior to generating the IPG Test Provides a list of tests for which to
testplan to force a testing order. For instance, if the Consultant schedule generation and compilation. IPG
test for R1 would charge a capacitor which would cause Test Consultant will not schedule
the test for R2 to fail, you can force R2 to be tested prior generation or compilation for any tests not
to R1. To do this, edit the testorder file to list resistor listed in the testorder file.
R2 before resistor R1.
Module Pin Provides a list of tests for which resources
Assignment need to be assigned. MPA will not assign
(MPA) resources to any tests not listed in the
testorder file.

Modifying/Viewing the Data in the testorder File d Edit the testorder file.
This chapter describes the syntax of the testorder file
NOTE and shows an example file at the end.
Do not edit board test files with shell editors such
as vi. These editors do not update the file's header NOTE
information, such as the time-stamp, that Agilent Optional testorder file statements (available with
3070 programs use. Instead, use the BT-BASIC optional software packages such as the PanelTest
editor to edit board test files. Option) are not described in this chapter. For
information about such statements, refer to the
documentation in the optional package.
1 Modify the testorder file from IPG Test
Consultant.
a Click the left mouse button on Edit.
b Drag the mouse pointer to select View/Edit
testorder File.
and loads the testorder file into the BT-BASIC
workspace for you to edit.
2 Modify the testorder File manually.

c Load the testorder file. Type:
get "testorder"

Testorder Syntax The syntax of the testorder consists of two Statement List
statements; the <statement list> statement, and the
testplan generation on/off statement.
The <statement list> statement consists of one
syntax for all test types. The Statement List options are
NOTE
Multiple Board Versions adds skip statements
and version parameters to the testorder file to
control the testing of devices on the versions of a
PC board. These statements and parameters are
not included in this chapter; see Chapter 5,
Multiple Board Versions in Optional Board Test
Applications for details.
Example 3-1 <statement list> syntax
<statement list>
<statement list> can be:

<pins test statement>
<shorts test statement>
<analog test statement>
<digital test statement>
<boundary-scan test statement> ! InterconnectPlus must be installed on your system to use this statement.
<scanworks test statement>
<analog powered test statement>
<mixed test statement>
<testjet test statement>
<polarity check test statement>
<connect check test statement>

<pins test statement> can be:

test pins <test name>
test pins <test name>; <options>
<shorts test statement> can be:
test shorts <test name>
test shorts <test name>; <options>
<analog test statement> can be:
test capacitor <test name>
test capacitor <test name>; <options>
test diode <test name>
test diode <test name>; <options>
test fet <test name>
test fet <test name>; <options>
test fuse <test name>
test fuse <test name>; <options>
test inductor <test name>
test inductor <test name>; <options>
test jumper <test name>
test jumper <test name>; <options>
test potentiometer <test name>
test potentiometer <test name>; <options>
test resistor <test name>
test resistor <test name>; <options>
test switch <test name>
test switch <test name>; <options>
test transistor <test name>
test transistor <test name>; <options>
test zener <test name>
test zener <test name>; <options>
<digital test statement> can be:
test digital <test name>
test digital <test name>; <options>
<boundary-scan test statement> can be:
test scan connect <test name>

test scan connect <test name>; <options>

test scan interconnect <test name>
test scan interconnect <test name>; <options>
test scan disable <test name>
test scan disable <test name>; <options>
test scan powered shorts <test name>
test scan powered shorts <test name>; <options>
<scanworks test statement> can be:

test scanworks asp <test name>
test scanworks scan path verify <test name>
test scanworks dr verify <test name>
test scanworks ir verify <test name>
test scanworks svf <test name>
test scanworks svf <test name>; pretest
test scanworks jam <test name>
test scanworks jam <test name>; pretest
test scanworks stapl <test name>
test scanworks stapl <test name>; pretest
test scanworks interconnect <test name>
test scanworks memory access verify <test name>
test scanworks memory interconnect <test name>
test scanworks cluster <test name>
test scanworks memory bist <test name>
test scanworks flash <test name>
test scanworks discrete io <test name>
test scanworks macro <test name> !(generates commented test statement)
scanworks input <test name>
scanworks input <test name> “<string constant>”
scanworks display <test name>
scanworks display <test name> “<string constant>”
test scanworks reset <test name>
<test name>, for ScanWorks tests, is a string constant <PROJECTS>.<DESIGN>.<ACTION>

with this format:

<analog powered test statement> can be:

test analog powered <test name>
test analog powered <test name>; <options>
<mixed test statement> can be:
test mixed <test name>
test mixed <test name>; <options>
<testjet test statement> can be:
test testjet <test name>
<polarity check test statement> can be:

test polarity <test name>
<connect check test statement> can be:

test connect check <test name>
<test name> is a <string literal>
<options> can be:
<option>
<option>, <option>
<option>, <option>, . . ., <option>

<option> can be:

preshorts
power
permanent
characterize
comment
nulltest
pretest
<mixed option>
<path name>
<mixed option> can be:

digital, analog
digital, serial
digital, analog, serial
<path name> is a <string literal>
<text> can be:

<string literal>
Examples:
test jumper "j1"; preshorts
test shorts "shorts"
test capacitor "c1"; characterize
test capacitor "c2"; characterize, permanent
test resistor "r2"
test resistor "r3"; comment
test analog functional "vr1"; power
test digital "u1"; nulltest
test digital "u2"
test connect "u3"; permanent
test analog functional "op_amp"; "special_directory"
test mixed "d_to_a"; permanent
test mixed "u10"; digital, analog, serial, comment
test mixed "u11"; digital, serial

Testplan Generation On/Off

You can use the testplan generation on/off
statement in the testorder file to instruct TPG whether
or not to generate a testplan.
If you have made changes to your testplan and are
running TPG incrementally, you might not want TPG to
overwrite your testplan. Use the testplan
generation off statement to instruct TPG to not
generate a new testplan.
If no testplan generation on/off statement is
specified in the testorder file, the system assumes
testplan generation on.
Example 3-2 testplan syntax
testplan generation on
testplan generation off
Example:
testplan generation off
test analog functional "vr2"
test analog functional "op_amp"; permanent
.
.
.
test capacitor "c1"
test pins "pins"

Sample Testorder Example 3-3 testorder file
File testplan generation on

test mixed "ser_u5"; digital, serial
test scan interconnect "b_scan"
test analog powered "op2"
test analog powered "op_amp"; permanent
test digital "u1"
test digital "u2"
test digital "u3"; nulltest
test analog powered "vr2"; power
test zener "vr1"
test transistor "q1"
test switch "sw1"; preshorts
test resistor "r1"
test resistor "r2"
test resistor "r3"; comment
test potentiometer "rpot1"; preshorts
test jumper "j1"; preshorts
test inductor "l1"
test fet "qf4
test diode "cr1"
test capacitor ".discharge"
test capacitor "c1"
test pins "pins"
test scanworks interconnect "sci 3_2.main.interconnect1"
test scanworks scan path verify "sci 3_2.main.scan path verify1"
test scanworks svf "sci 3_2.main.svf erase program verify u2"

4 The Wirelist File

■ The Wirelist Syntax, 4-4
■ Sample Wirelist File, 4-24
Objectives
able to:
wirelist file
Prerequisites
chapter.

using this chapter.

Chapter 4: The Wirelist File
Overview The wirelist.o file contains the fixture wire Viewing the Data in the wirelist File
connections from nodes to the module interface pins.
This file is an output of Module Pin Assignment (MPA) NOTE
and is stored under the local board directory.
Do not edit board test files with editors such as vi.
During fixture generation, MPA assigns nodes to These editors do not update the file's header
module interface pins. These assignments are stored in information, such as the time-stamp, that Agilent
the wirelist.o file. These assignments are listed as 3070 programs use. Use the BT-BASIC editor to
wires from the nodes to the brc location of the interface edit board test files.
pins. Each listing includes the type of resource for the
interface pin.
Viewing the wirelist File from IPG Test Consultant
The wirelist.o file is structured in blocks. There is
one wirelist test block for each test in the testorder a Click the left mouse button on Edit.
file. Each block contains the wire assignments used for
b Drag the mouse pointer to select View/Edit wirelist
that test.
File.
The fixture generation process creates only the object
file, wirelist.o; it does not generate a source file.
and loads the wirelist file into the BT-BASIC
However, you can create a source file, wirelist, from
workspace.
the object file.
Viewing the wirelist File Manually
c Generate a wirelist source file from the
wirelist.o object file if the wirelist source
file doesn’t exist. Type:
list object "wirelist.o" to "wirelist"

d Load the wirelist file. Type:

get "wirelist"
If a wirelist source file already exists in the local

board directory, MPA will update both the source and
object files.
The syntax of the wirelist is explained in this chapter,
and an example wirelist is provided at the end.
NOTE
MPA is explained in Chapter 4, Generating Tests
and Fixture Files in Test & Fixture Development.

The Wirelist Syntax This section describes the syntax of the wirelist file. ■ wire
■ serial
■ group
ADVICE ■ end group
We recommend you do not edit the wirelist file. ■ strapping
■ end strapping
■ asru module
The multiplexing done by MPA in allocating resources ■ tie
■ ground
for a test is relatively complex. Manually editing this
■ end ground
file could cause problems later on in the board ■ unused
development process. If a modification is required on ■ end unused
the board, use Fixture Consultant to make the changes, ■ interface
modify the specific test, or modify the information in ■ end interface
Board Consultant. Then use IPG Test Consultant to ■ stimulus module
update the board and fixture information. Let the
software manage the system's resources. global
The keywords used in the wirelist syntax are: The global statement marks the beginning of a wirelist
global block. There can be only one global block in a
■ global
■ end global wirelist file; the global block is listed prior to any test
■ relay blocks.
■ end relay
■ test
The end global statement terminates the global block.
■ end test See the definition of the end global statement in this
■ device chapter.
■ end device
■ clock
■ timing module
■ functional
■ include
■ subtest
■ end subtest

Example 4-1 global syntax ground

global The ground block lists brcs that will be switched to
ground at the beginning of powered test. These brcs are
Example: located in the second row on a hybrid double density pin
global card. They occupy the same locations as the extended
relay ground pins located on the 20 MP/s hybrid high
wire "R1-2" to 11818 general accuracy card. Physically the switched ground brcs are
wire "BB6-8" to 11819 general
end relay
the even numbered pins below pin 39 and the odd
end global numbered pins above pin 39. Only ground resource
types are allowed. Typically the ground block is used for
fixture adaptability. The ground block can only appear
end global in the global section.
The end global statement terminates a wirelist global
block. The global statement marks the beginning of the Example 4-3 ground syntax
global block. See the definition of the global statement
ground
in this chapter.
Example:
Example 4-2 end global syntax
global
ground
end global wire "GND" to 101102 ground
Example: wire "GND" to 101104 ground
wire "GND" to 223177 ground
global wire "GND" to 223175 ground
relay end ground
wire "Node_1" to 11818 general end global
wire "Node_2" to 11819 general
end relay
end global end ground
The end ground statement marks the end of a ground
block. See the ground statement in this chapter.

relay The end relay statement terminates the relay block.

See the definition of the end relay statement in this
The relay statement marks the beginning of a wirelist chapter.
relay block. A relay block contains wire statements for
GP relay connections.
Example 4-4 relay syntax
relay
Example:
global
relay
wire "R1-2" to 11818 general
end relay
relay
wire "Node_3" to 10152 general using access
end relay
end global
end relay Example 4-5 end relay syntax
The end relay statement terminates a wirelist relay end relay

block. The relay statement marks the beginning of the
relay block. See the definition of the relay statement in Example:
this chapter. global
relay
end relay
end global

strapping Example 4-7 tie syntax
The strapping statement begins a block of information tie <brc> to <brc>

that describes externally hardwired connections between
brc pins. The external connections are made either in the <brc> is a <numeric constant>
fixture or fixture adapter. Only one strapping block is <brc> An integer that identifies the
bank-row-column position of a
allowed in the wirelist file and it must appear in the module interface pin.
global section.
Example:
Example 4-6 strapping syntax strapping
tie 10442 to 104142
strapping tie 106122 to 10622
end strapping
Example:
global
strapping end strapping
tie 10101 to 101101
The end strapping statement terminates a strapping
tie 10201 to 102101
end strapping block.
end global
Example 4-8 end strapping syntax
tie end strapping

The tie statement describes a hardwired connection Example:
between two brcs in the fixture or fixture adapter.
global
Typically, tie connections are used to describe strapping
non-standard paths to card resources. Only brcs of tie 10201 to 102101
double-density pin cards can be used and any of these tie 10217 to 102117
brcs can only be specified once in a strapping block. end strapping
end global

unused Example 4-9 unused syntax
The unused statement begins an unused wiring block unused

and ends with an end unused statement. Only one
unused wiring block can exist in the wirelist and it must Example:
appear in the global section. global
unused
Probe Select, MPA, and other board compilers store wire "U15_1" to 10102 none
wiring information here about wires that continue to wire "VER_3" to 10104 none
exist in the fixture, but are not currently being used by end unused
any test in the wirelist. If the fixture is modified at a end global
later time, such as for an Engineering Change Order
(ECO), the fixture generation software tries reassigning end unused
personality pins and wires listed here before requesting
a new personality pin be drilled. This process minimizes The end unused statement terminates an unused wire
the need to redrill the fixture to add new personality pins block. See the unused statement for more information.
or wires if resources already exist in the unused section.
test
CAUTION The test statement marks the beginning of a wirelist
✸Do not add or modify any information listed in the

unused section. Because the fixture generation
test block and specifies the test type. It also specifies the
test name, if there is one.
software modifies this section for its own use, any
If no test type is specified, digital is assumed. The end
user modification could potentially get deleted or test statement terminates the test block. See the
invalidate the fixture. definition of the end test statement in this chapter. The
Test options are described in Table 4-1 on page 4-10.
Note that wire statements in the unused block use the
resource type none. This parameter specifies that no
resource is assigned to the wire. All wires in the unused
block must use this resource type.

Example 4-10 test syntax
test <test name>

test <test name> <version label>
test <test type> <test name>
test <test type> <test name> <version label>
test mixed <test name>; <mixed option>
test mixed <test name>; <mixed option> <version label>
<test type> can be:
digital
analog
mixed
shorts
testjet
polarity
connectcheck
<test name> is a string constant

<mixed option> can be:
digital, analog
digital, serial
digital, analog, serial
Example:
test analog "central_analog_components"
wire "R1-2" to 11422 i
wire "R1-2" to 11431 b
wire "BB6-8" to 11442 g
wire "BB6-10" to 11451 l
end test

Table 4-1 test options
Option Description
<test type> Type of test (digital, analog, mixed, shorts, testjet test. . .)
<test name> Test name.
<mixed option> In a mixed test, specifies the type of resources used. If no option is specified, digital, analog is the
default.
<version label> Version for Multiple Board Versions.
The end test statement terminates a wirelist test block. device

The test statement marks the beginning of the test
block. See the definition of the test statement in this The device statement marks the beginning of a device
chapter. block within a wirelist test block. The device statement
specifies the device designator and mux card address.
Example 4-11 end test syntax The mux card address includes: the side of the fixture,
mux address, and port number. The end device
end test statement terminates the device block. See the definition
of the end device statement in this chapter. The Device
Example: options are described in Table 4-2 on page 4-11.
wire "R1-2" to 11422 i
wire "R1-2" to 11431 b
wire "BB6-8" to 11442 g
wire "BB6-10" to 11451 l
end test

Example 4-12 device syntax
device <device designator>; <side> mux <address number> port <port number>
<device designator> is a string expression

<side> can be:
top
bottom
<address number> is: <integer from 1 to 15>
<port number> is: <integer from 1 to 64>
Example:
device "u150"; top mux 2 port 5
wire "gnd" to 22365 g
wire "u150-1" to 22321 g
wire "u150-2" to 22322 g
. . .
end device
Table 4-2 device options (continued)
Table 4-2 device options Option Description
Option Description <address number> Address of the mux card.
<device Device under test. <port> Number of the port on the mux
designator> card.
<side> Side of the fixture—top or bottom.

end device
The end device statement terminates a device block
within a wirelist test block. The device statement marks

the beginning of the device block. See the definition of <type> can be:
the device statement in this chapter. internal
external
Example 4-13 end device syntax
Example:
end device test digital "U101"
Example: timing module 0
clock internal
device "u150"; top mux 2 port 5 wire "U101-4" to 20221 drive
wire "gnd" to 22365 g .
wire "u150-1" to 22321 g .
wire "u150-2" to 22322 g .
. . . end test
end device
clock
Table 4-3 clock options
The clock statement describes the type of clock used
for a test. The clock statement is only valid within a Option Description
wirelist test block. If no clock statement is present in
the wirelist test block, it is assumed that no clock is <internal> Clock is generated internally.
needed. This statement is required for the digital, and <external> Clock is generated externally.
mixed test types. The clock statement must follow the
test statement, and precede any wire or subtest
statements. The Clock options are described in Table asru module
4-3 on page 4-12.
The asru module statement specifies which module
Example 4-14 clock syntax contains the master asru card used for the test. It allows
SIGLAB signals to be routed between the master asru
clock <type> and hybrid pin cards of any module. asru module can
only be used with ASRU revision C cards and is valid
only for analog, analog functional, and mixed tests. The

statement must follow any functional and test Example 4-16 timing module syntax
statements, and precede any wire or subtest
statements. timing module <module number>
<module number> represents the module that contains <module number> is an <integer from 0 to 3>
the master asru cards.
Example:
Example 4-15 asru module syntax test digital "ram test"
timing module 3
asru module <module number> clock internal
wire "D0" to 21441 drive
<module number> is: <integer from 0 to 3> wire "D0" to 21441 receive
.
Example: .
test analog "r1" .
asru module 1 wire "D3" to 21470 drive
wire "r1.1" to 10968 s wire "D3" to 21470 receive
wire "r1.2" to 11367 i end test
end test
stimulus module
timing module The stimulus module statement specifies the pin card
The timing module statement specifies which module to be wired to ground for each module. It is only valid
is the master timing module for the test. This statement for the connectcheck test type.
is only valid for digital, and mixed test types. The Stimulus module statements must follow functional
timing module statement must follow any functional and test statements, and precede wire statements. The
and test statements, and precede any wire or subtest options are described in Table 4-4 on page 4-15.
statements.
<module number> represents the module that provides
the master timing for the test.

Example 4-17 stimulus module syntax
stimulus module <module number> card <slot number>

<module number> is an <integer from 0 to 3>
<slot number> is an <integer>
Example:
test connectcheck "connectcheck"
timing module 2
bottom mux 1
stimulus module 0 card 5! Which card to wire to ground, in each module,
stimulus module 1 card 3! for Connect Check tests.
wire "+5V" to 22362 ccguard
wire "ground" to 22370 ccground
device "u101"
wire "~ccmux" to 20278 ccrefnode
wire "ground" to 20262 ccrefret
wire "node_1" to 21631 g
.
.
.
end device
end test

wire “clock” to 21937 receive frequency

end test
Table 4-4 stimulus module options
include
Option Description
The include statement is used in the wirelist file to
<module number> Module used for the Connect
reference another file. The statement instructs the
Check test.
compiler to read the code from that other file and treat it
<slot number> Slot number of the card to be wired as if it were a part of the original file. The object code
to ground the Connect Check test. from the included file is merged in the object code of the
original file.
<file id> is the identifier of the wirelist file to be
functional included.
The functional statement modifies the test type, which
is specified by the test statement, in a wirelist test Example 4-19 include syntax
block. The functional statement specifies analog
functional, or mixed functional test types. Note that the include <file id>
functional statement is optional for analog and digital
test types, but is always required for mixed tests. The <file id> is a string constant
functional statement must follow the test statement,
Example:
and precede any wire, clock, timing module, or
subtest statements. include "wirelist/test_U100"
Example 4-18 functional syntax subtest

functional The subtest statement marks the beginning, and
specifies the name, of a subtest within a wirelist test
Example:
block. The subtest name must not exceed 16 characters.
test analog "y301" The subtest statement is only valid with analog, analog
functional functional, and mixed functional test types. This
wire “gnd” to 21661 detector

statement can only be used within a wirelist test block, beginning of the subtest. See the definition of the
and must be terminated by the end subtest statement. subtest statement in this chapter.
The end subtest statement terminates the subtest. See
the syntax description of the end subtest statement in Example 4-21 end subtest syntax
this chapter.
end subtest
Example 4-20 subtest syntax Example:
subtest <subtest name> test analog "central_analog_components"
wire "R1-2" to 11422 i
wire "R1-2" to 11431 b
<subtest name> is a string constant wire "BB6-8" to 11442 g
wire "BB6-10" to 11451 l
Example: subtest "card 0"
test analog "central_analog_components" wire "BB6-3" to 11976 a
wire "R1-2" to 11422 i wire "BB6-3" to 11918 s
wire "R1-2" to 11431 b end subtest
wire "BB6-8" to 11442 g subtest "card 1"
wire "BB6-10" to 11451 l wire "BB6-4" to 11976 a
subtest "card 0" wire "BB6-4" to 11917 s
wire "BB6-3" to 11976 a end subtest
wire "BB6-3" to 11918 s end test
end subtest
subtest "card 1"
wire "BB6-4" to 11976 a
wire
wire "BB6-4" to 11917 s The wire statement describes a wire for a test or subtest.
end subtest
end test
Each wire statement identifies a node and a brc that are
wired together. It also indicates the resource type used.
A wire that is specified within a wirelist test block is
end subtest used for that test and all subtests. A wire that is specified
The end subtest statement terminates a subtest in a within a subtest is only used for that subtest. The
general resource is allowed only inside a block
wirelist test block. The subtest statement marks the
delimited by the relay and end relay statements.

Each <brc> can be connected to one of two X-bus paths by the digital compiler of tests which use the
on double-density pin cards if the resource type used is ControlXTP Card, to instruct MPA to assign brc’s in the
s, i, l, a, b, aux, detector high, detector low, or source. same testhead module. See in module <x> (DIGITAL).
One path is called the primary X-bus, which typically is
the path used. The other path is called the alternate CAUTION
X-bus, which can be used if the primary X-bus path is
not available. Each primary X-bus has one alternate.
The following list shows the primary X-bus and its
✸ Do NOT add in module <x> syntax to wire
syntax. Program errors will result.
corresponding alternate in the form (primary, alternate):
(X1, X3), (X2, X4), (X3, X5), (X4, X6), (X5, X7),
(X6, X8), (X7, X1), (X8, X2). Specifying alternate
changes the signal path from using the primary X-bus to
using its alternate X-bus.
Adding via <group brc> to <via brc> in the wiring
statement specifies an extended path using an external
connection in the fixture or fixture adapter between two
brcs. Both brcs must previously be defined in a tie
statement. The extended signal path is as follows:
<node> to <brc>, <brc> to <group brc>, <group brc> to
external connection, external connection to <via brc>,
<via brc> to pin card resource. The <group brc> must be
in the same channel as the <brc> to use this extended
path. If alternate is specified when the statement
contains via <group brc> to <via brc>, the
alternate X-bus applies only to the <via brc>, not <brc>.
The Wire options are described in Table 4-5 on
page 4-20.
The in module <x> syntax is used by the On-Board
Programming (OBP) software in conjunction with the
ControlXTP card. The in module <x> syntax is added

Example 4-22 wire syntax
wire <node> to <brc> <resource>

wire <node> to <brc> <resource> in module <x>
wire <node> to <brc> <resource> alternate
wire <node> to <brc> <resource> alternate in module <x>
wire <node> to <brc> <resource> via <group brc> to <via brc>
wire <node> to <brc> <resource> via <group brc> to <via brc> in module <x>
wire <node> to <brc> <resource> via <group brc> to <via brc> alternate
wire <node> to <brc> <resource> via <group brc> to <via brc> alternate in module <x>
wire <node> to <brc> <resource> using <card type>
wire <node> to <brc> <resource> alternate using <card type>
wire <node> to <brc> <resource> via <group brc> to <via brc> using <card type>
wire <node> to <brc> <resource> via <group brc> to <via brc> alternate using <card type>
<node> is a string constant
<brc>, <group brc>, and <via brc> are numeric constants
<resource> can be:
s
i
g
l
l on xl
a
b
gl
aux
detector high
detector low
source
drive
drive on receive bus
dynamic
none
receive
receive on drive bus
receive <class>
receive <class> on drive bus
serial1

serial2
serial3
serial4
serial5
serial6
serial7
serial8
serial9
serial10
serial11
serial12
serial clock
serial clock receive
clock
clock receive
clock receive frequency
fast clock
trigger
ext <ext#>
acc <acc#> <connection>
general
ground
ccguard
ccground
ccrefnode
ccrefret
<x> can be: letter from A to Z - always at the end of specified wire <node> ... in module <x> statement
<card type> can be:
access
analog
channel
control
hybrid
<ext#> can be: 1, 2, 3, 4, 5, 6, 7, or 8
<acc#> is a numeric constant
<class> can be:

fixed ! For digital test types.

frequency ! For mixed and analog functional test types.
interval ! For mixed and analog functional test types.
<connection> can be:
high
high direct
low
low shield
low direct
low shield direct
Examples:
test digital "X"
timing module 1
clock external
wire "X1" to 20606 trigger
wire "X0" to 11876 clock receive
wire "X4" to 21816 fast clock
wire "X0" to 21401 drive
wire "X2" to 21421 receive
wire "X3" to 21430 receive
end test
Table 4-5 wire options
Option Description
<node_name> The name of the node specified in the board file. For Connect Check, ~ccmux specifies that the
wire needs to be connected to the mux card.
<brc> The bank-row-column designation of the module interface pin connected to a node.

Table 4-5 wire options (continued)
Option Description
<group brc> A brc located in the same channel as <brc>. The <group brc> allows the signal to be routed to an
external connection in the fixture which is then tied to another resource of the same card or
another double-density pin card.
<via brc> This brc connects a resource to an external connection, which routes the signal path to a <group
brc> on the same card or another double-density pin card.
<resource> The type of resource the wire connects to for the test or global block. Some resources can be
specified to use a different bus with the on keyword. Available only to the L resource is an
alternate bus called the XL-bus, which can be specified by adding on xl after the l resource
syntax. In digital or mixed signal tests, the drive resource can be routed through the receive bus.
Similarly, the receive resource can be routed through the drive bus. Typically these types of
assignments are used for fixture adapter applications.
The ccguard, ccground, ccrefnode, and ccrefret resources are for an Connect Check
test.
in module <x> <x> can have a value from A to Z. All wires (brc) with the same letter are placed by the MPA
(Module Pin Assignment program) in the same module (0 or 1 or 2 or 3).
Please refer to the sample wirelist file in Sample information associated with serial test card resources.
Wirelist File on page 4-24 for additional examples of The end group statement terminates the group block.
wire statements.
Example 4-23 group syntax
group
group <group id>
The group statement marks the beginning of a wirelist
group block. A group block contains all connection <group id> is a string constant

Example: Example 4-25 serial syntax

group "stream1"
serial clock
serial sbus using 2
serial <class> using <count>
wire "GND" to 12216 serial1
wire "/1MBINIT*" to 12221 serial2
end group <class> can be:
sbus
end group ubus
ttl<#>
The end group statement terminates a wirelist group <#> can be <1-6>
block. <count> is a <numeric constant>
Example:
Example 4-24 end group syntax
group
end group serial clock
wire "/BOARD_CLKDR" to 12209 serial clock
Example: wire "/BOARD_CLKRC" to 12202 serial clock
receive
group "stream1"
end group
serial sbus using 2
wire "/1MBINIT*" to 12221 serial2 interface
end group
The interface statement marks the beginning of the
serial wirelist interface block. The interface block contains
information used for fixture interfaces; this includes a
The serial statement defines all of the serial stream list of wire statements and a pairs/end pairs block.
attributes of a group block's associated wire statements.
The list of wire statements define the node-to-brc
This statement can only be specified within a group
mapping of wires. Each wire statement has a resource
block and must follow the group statement.
type of none. The pairs/end pairs block contains tie
statements for pairs of brc’s.

Example 4-26 interface syntax wire "Node_2" to 10201 none

pairs
interface tie 10101 to 10222
wire <node name> to <brc> none tie 10102 to 10221
pairs end interface
tie <brc> to <brc>
end pairs
end interface
<node name> is a <string expression>

<brc> is a <numeric expression>
Example:
interface"
wire "Node_1" to 10200 none
pairs
tie 10101 to 10222
tie 10102 to 10221
end interface
end interface
The end interface statement terminates the wirelist
interface block.
Example 4-27 end interface syntax
end interface
Example:
interface"

Sample Wirelist File Example 4-28 Sample wirelist file
global
relay
wire "R1-2" to 11818 general
end relay
relay
end relay
strapping
tie 21021 to 210121
tie 21023 to 210123
tie 21001 to 210101
tie 21041 to 210141
tie 21043 to 210143
end strapping
end global
test analog "r20"
wire "R20-1" to 101117 s
wire "R20-2" to 101116 i
wire "U20-2" to 101118 g
wire "R17-2" to 10118 l on xl
wire "R20-1" to 10117 a alternate
wire "R20-2" to 10116 b alternate
end test
test analog "r21"
wire "R21-1" to 21025 s via 21021 to 210121
wire "R21-2" to 20923 i
end test
test analog "r19"
asru module 1
wire "R19-1" to 11001 s

wire "R19-2" to 11312 i

end test
test "X"
timing module 1
clock external
wire "X0" to 11876 clock receive
wire "X2" to 21421 receive fixed
wire "X3" to 21430 receive fixed
wire "X4" to 21816 fast clock
end test
test digital "ram_test"
timing module 3
clock internal
wire "D0" to 21441 receive
wire "DATA_STROBE" to 21471 receive fixed
end test
test digital "jbc1"
timing module 3
clock internal
wire "CLK" to 21522 drive in module A
wire "CLK_DISABLE" to 21521 drive
wire "IN" to 21503 drive in module A
wire "MOD" to 21502 drive in module A
wire "OUT" to 21501 receive in module A

end test
wire "R1-2" to 11422 i
wire "R1-2" to 11431 b
wire "BB6-8" to 11442 g
wire "BB6-10" to 11451 l
wire "CH1_H" to 22277 acc18 high direct
wire "CH1_L" to 22278 acc18 low direct
wire "GND" to 22228 acc13 low
wire "CONTR" to 22227 acc 13 high
subtest "card 0"
wire "BB6-3" to 11976 a
wire "BB6-3" to 11918 s
end subtest
subtest "card 1"
wire "BB6-4" to 11976 a
wire "BB6-4" to 11917 s
end subtest
end test
test analog "side_analog_components"
wire "R19-2" to 11512 g
wire "R19-1" to 11501 gl
wire "R20-1" to 11521 s
wire "R20-1" to 11530 a
wire "R20-2" to 11541 i
wire "R20-2" to 11550 b
end test
test digital "ttl_logic"
timing module 2
clock external
wire "U1-1" to 20201 drive
wire "U1-1" to 20602 clock receive
wire "U1-2" to 20606 trigger
wire "U1-3" to 20207 receive


end test
test mixed "mixed"
functional
timing module 0
clock internal
wire "R2-1" to 22201 ext1
wire "R2-2" to 22313 ext2
wire "DAC-OUT" to 22249 receive frequency
end test
test analog "analog_section_1"
functional
wire "ANA_FUNC.1" to 21601 detector low
wire "ANA_FUNC.2" to 21610 detector high
wire "ANA_FUNC.3" to 21621 aux
wire "ANA_FUNC.4" to 21630 receive interval
wire "ANA_FUNC.5" to 21641 receive interval
end test
wire "U9-1" to 21650 g
wire "U9-2" to 21661 g
end test
test mixed "serial_6an"; digital, serial
functional
timing module 1
clock internal
wire "DTR0-" to 20968 drive
wire "RTS0-" to 21067 drive
wire "SOUT0" to 21068 drive
group "stream1"
serial sbus using 2

end group
group "stream2"
serial ttl4 using 331
end group
group
serial clock
wire "/BOARD_CLKDR" to 12209 serial clock
wire "/BOARD_CLKRC" to 12202 serial clock receive
end group
end test
test testjet "testjet"
timing module 3
device "u50"; top mux 1 port 1
wire "u50-1" to 22321 g
wire "u50-2" to 22322 g
wire "u50-3" to 22323 g
wire "u50-4" to 22324 g
wire "u50-5" to 22361 g
wire "u50-6" to 22362 g
wire "u50-7" to 22363 g
wire "u50-8" to 22364 g
end device
device "u100"; bottom mux 2 port 1
wire "u100-1" to 22321 g
wire "u100-2" to 22322 g
wire "u100-3" to 22323 g
wire "u100-4" to 22324 g
wire "u100-5" to 22361 g
wire "u100-6" to 22362 g
wire "u100-7" to 22363 g
wire "u100-8" to 22364 g

end device
end test
test polarity "polarity"
timing module 1
device "c1"; top mux 1 port 1
wire "node_1" to 22321 s
wire "node_1" to 22322 a
wire "node_2" to 22365 i
wire "node_2" to 22366 b
end device
device "c2"; bottom mux 2 port 1
wire "node_3" to 22421 s
wire "node_3" to 22422 a
wire "node_4" to 22465 i
wire "node_4" to 22466 b
end device
end test
test connectcheck "connectcheck"
timing module 2
bottom mux 1
ground module 0 card 5 ! Which card to wire to ground, in each module,
ground module 1 card 3 ! for Connect Check tests.
wire "+5V" to 22362 ccguard ! Four guard wires connected to a
wire "+5V" to 22364 ccguard ! guarded node.
wire "ground" to 22370 ccground ! Five guard wires connected to
wire "ground" to 22372 ccground ! the board ground node.
device "u101"
wire "~ccmux" to 20278 ccrefnode! Wire to the mux card.
wire "ground" to 20262 ccrefret! Wire to the board ground node.

.
.
.
end device
end test

5 The Fixture Files
In this chapter... ■ Overview, 5-2 Prerequisites

■ What is a Fixture File?, 5-4
There are no prerequisites associated with this chapter.
■ Programs that Use the Fixture File, 5-8
■ Fixture File Syntax, 5-10 Required Tools and Materials
■ Sample Fixture File, 5-46 There are no required tools or materials associated with
■ Fixture Defaults File, 5-51 using this chapter.
■ Sample Fixture Defaults File, 5-53
■ User-Modifiable Fixture Components, 5-57

■ Fixture Components Files Syntax, 5-60
■ Sample Fixture Components Files, 5-63
■ Standard and Advanced probe Spacing, 5-66
Objectives
able to:
■ Describe the structure and syntax of the fixture
file.
■ Explain the use of the fixture defaults file.
■ Understand and use fixture components files.

06/2003
Chapter 5: The Fixture Files
NOTE
Overview This chapter describes the structure and syntax of the Do not edit board test files with editors such as vi.
fixture, the fixture defaults files and the fixture These editors do not update the file's header
component files. information, such as the time-stamp, that Agilent
3070 programs use. Use the BT-BASIC editor to
NOTE edit fixture files.
The fixture file is used by the Fixture Generation
Software and is explained in Chapter 6, The following sections explain how to modify the
Completing and Debugging Tests in Test & fixture files.
Fixture Development.
Modify the Fixture File from Agilent Fixture
The Fixture Generation Software produces the Consultant
fixture.o file and the reports and files necessary to
a Change probe locations.
build a test fixture.
b Unblock resources.
The fixture file can be initialized with a fixture defaults
file, if desired. The probe attributes can be changed by c Modify wiring.
making changes to the fixture component files.
d Add fixture electronics.
NOTE Modify the Fixture File from Agilent IPG Test

Refer to Fixture Defaults File on page 5-51 for Consultant
more information.
a Click Edit.
The Fixture Generation Software creates only the object b Select View/Edit Fixture File.
file, fixture/fixture.o; it does not generate a source IPG Test Consultant opens a BT-BASIC window
file. However, you can create a source file, and loads the fixture file into the BT-BASIC
fixture/fixture, from the object file. workspace for you to edit. If only the fixture.o

object file exists, Test Consultant automatically

generates a fixture file from that object file.
Modify the Fixture File Manually

c Generate a fixture source file from the fixture.o
object file if the fixture source file doesn’t exist.
Type:
list object "fixture/fixture.o" to
“fixture/fixture”
d Load the fixture file. Type:

get “fixture/fixture”
If a fixture source file already exists in the fixture

directory, the Fixture Generation Software
updates both the source and object files.

What is a Fixture The fixture file is made up of two or more blocks. The Example 5-1
first block is the fixture description block; it contains
File? information about fixture keepouts, holes, and other OPTIONS
options that effect the fixture. The fixture description Fixture Type
Fixture Size
block is followed by one or more board description Fixture Part Number
blocks. Board description blocks are not allowed within Top Probes Allowed
a fixture defaults file. Each board description block Density Threshold
contains board_xy information, board placement, probe Heavy Probe Force
attributes, and node attributes for a board to be tested on Light Probe Force
the fixture. The last block is called the protected unit Autofile
Metric Units
block. This optional block contains wiring and node WireWrapping
information typically used to describe connections and KEEPOUT
attributes for fixture electronics or for other custom INCLUDE
applications. HOLES
BOARD
INCLUDE
NOTE PLACEMENT
The fixture file, fixture.o, is created by the OUTLINE
fixture generation software, which is run by IPG TOOLING
KEEPOUT
Test Consultant, during board test development.
NODE
For more information, see Chapter 4, Generating ALTERNATES
Tests and Fixture Files in Test & Fixture OTHER
Development. ALTERNATES
GROUP
END BOARD
Example 5-1 shows an example fixture file with two BOARD
boards and a protected area that can be used for fixture INCLUDE
PLACEMENT
electronics:
OUTLINE
TOOLING
KEEPOUT

NODE WIRES
PINS END UNIT
PROBES END
ALTERNATES
WIRES
OTHER Fixture Description Block
ALTERNATES
GROUP The fixture description block of the fixture file
END BOARD contains global information about the fixture. This
PROTECTED UNIT information includes: fixture options, fixture keepout
NODE areas, and fixture holes. Fixture description block
PINS information is listed at the beginning of the file.
WIRES
OTHER Fixture options are listed in the OPTIONS block. This
PINS includes the information shown in Table 5-1.
Table 5-1 Fixture description block
Information Description
Fixture Type Type of fixture to be used. This option can be: SIMPLATE, EXPRESS, NO-WIRE, CASSETTE,
XG-50, XG-50 CASSETTE, QUICKPRESS, or JOT.
Fixture Size Size of the fixture to be used. This option can be: BANK1, BANK2, or FULL
Fixture Handler Identifies the type of fixture handling hardware; otherwise, it is not present. Options include QPT
(QuickPress) or JOT.
Fixture Part Exact type of fixture to be used. Unlike the other options, this number is automatically placed in the file
Number by the software.
Top Probes Indicates if top side probes can be used. This option can be ON or OFF.
Allowed

Table 5-1 Fixture description block (continued)
Information Description
Density Threshold Specifies the maximum probe force in ounces per square inch allowed on the board. A value of 80
would limit the number of eight ounce probes to ten per square inch.
Heavy Probe Probe force, in ounces, of the heavy weight probes that are to be used in the fixture.
Force
Light Probe Force Probe force, in ounces, of the light weight probes that are to be used in the fixture.
Autofile A numeric code that is wired into the test fixture for automatic identification of the fixture.
Metric Units The fixture reports are to be printed with metric units. This option can be ON or OFF.
WireWrapping Type of wirewrapping that will be performed on the fixture. This option can be AUTO, SEMI AUTO,
WIRELESS, or MANUAL.
KEEPOUT Defines an area of the fixture where pins and probes cannot be placed.
HOLES Lists optional hardware holes in a probe plate of the fixture.
Board Description Block Each board description contains information such as:
The board description block contains information about ■ The placement of the board on the fixture.
each board to be tested on the fixture. If a fixture is used ■ The X-Y coordinates of the board outline vertices.
to test only one board, there will be only one board
description in the file; if, however, the fixture is used to ■ A list of tooling holes.
test more than one board, there will be a board ■ A list of nodes and their attributes.
description block for each board in the fixture file.
■ A list of fixture components that have not been
assigned to any nodes.

This information is read from the board_xy.o file, for We leave it to you to determine whether the pins you
each board, and is modified by the fixture generation select are valid and that they do not conflict with any
software. keepout areas, tooling pins, or other obstructions.
In addition, this block is used by the 3070 software to
NOTE describe BSI nodes for boards with ScanWorks actions.
Board description blocks are not allowed in You should not remove these nodes. The BSI Pin Data
fixture default files. Format is:
_<BSI Channel>_<BSI Signal Name>_<Performance
Port Address>_<BSI Pin Number>
Protected Unit Description Block
Typical nodes look like:
The protected unit description block is used to reserve
personality pins and external nodes in the fixture for _BSI1_SW_GND_L2_12
_BSI1_TP1_TCK_L2_11
custom applications. Because all information in this
block is protected, it will not be removed or modified by Any nodes with this format should not be deleted.
the fixture generation software. Typically, you use this
block to describe nodes that will be used for fixture
electronics or to describe other wiring in the fixture that
must not change when IPG Test Consultant is run during
board test development or an ECO. This block lets you:
■ Describe external nodes used in custom fixture
electronics. These nodes can be wired to probes or
personality pins used by a board test. You can also
specify wire lengths and color to be used.
■ Reserve personality pins for custom electronics or
other external functionality in the board test.
Because these resources are reserved, the fixture
generation software will not automatically
re-assign them in board tests.

Programs that Use Several programs retrieve and modify data from the
fixture.o file during the fixture generation process.
the Fixture File
Table 5-2 Programs that use the Fixture/Fixture Defaults files
Program Description
BOARD PLACEMENT Creates the fixture directory and the fixture.o file. Alternatively, the Board Placement uses a
fixture defaults file to create the fixture.o file. Board Placement decides the X-Y placement of
the board on the fixture using the board outline coordinates from the board_xy.
You can manually specify board placement in the board_xy file. If Board Placement finds a
placement specified in board_xy it will use it; otherwise, it will check the fixture default file
object, if it exists, and use the placement specified. If the fixture default object does not exist,
Board Placement will place the board automatically.
PROBE SELECT Uses probe location information from the board_xy file, node and electrical information from the
boards file, and probe attribute information from the fixture component files to determine
the best type of probe and probing location for each node. You can influence the selection of
probes and locations by editing the board_xy file and the fixture component files.
MODULE PIN Assigns module card resources, such as sources, detectors, drivers, and receivers, to the
ASSIGNMENT (MPA) probes. MPA assigns resources close to the probes to minimize wire lengths. It stores these
assignments in a file called wirelist.o. Only the object wirelist, wirelist.o, is maintained in
the local board directory. To create a source wirelist, type:
list object "wirelist.o" to "wirelist"
on the BT-BASIC command line and press Return.

Table 5-2 Programs that use the Fixture/Fixture Defaults files (continued)
Program Description
FIXTURE TOOLING Adds power supply wiring and places all pin and wire assignment information into the
fixture.o file. Fixture tooling creates the reports and files necessary for building your test
fixture. Fixture tooling will also use the probe drill descriptions found in the fixture component files
to annotate the drill files.
PLOT GEN Uses the fixture.o file to generate plots of the fixture.

Fixture File Syntax This section describes the syntax of the fixture file. The board description block can contain keywords:
■ BOARD
NOTE ■ INCLUDE
The syntax of the fixture file is not case-sensitive. ■ PLACEMENT
■ OUTLINE
■ TOOLING
Each line of information, except list headings, must end ■ KEEPOUT
with a semicolon. Board, node, and device.pin names ■ NODE
must not contain colons (:) or tildes (~). The fixture ■ PINS - (NODE)
description block can contain these keyword list ■ PROBES - (NODE)
headings: ■ ALTERNATES - (NODE)
■ OPTIONS ■ TRANSFERS - (NODE)
■ HOLES ■ WIRES - (NODE)
■ KEEPOUT ■ OTHER
■ INCLUDE ■ PINS - (OTHER)
■ DEFAULT PLACEMENT ■ PROBES - (OTHER)
■ ALTERNATES - (OTHER)
The OPTIONS block contains keywords: ■ TRANSFERS - (OTHER)
■ Fixture Type ■ WIRES - (OTHER)
■ Fixture Size ■ GROUP
■ Fixture Part Number ■ END BOARD
■ Top Probes Allowed
■ Heavy Probe Force The protected unit description block can contain
■ Light Probe Force keywords:
■ Density Threshold
■ Autofile ■ PROTECTED UNIT
■ Wirewrapping ■ NODE
■ Metric Units ■ PINS - (NODE)
■ WIRES - (NODE)

■ OTHER Heavy Probe Force <force>;(8)

■ PINS - (OTHER) Light Probe Force <force>;(4)
Density threshold <value>;
■ WIRES - (OTHER)
Autofile <code>;
■ END UNIT Wirewrapping <type>; (MANUAL)
The last line of the fixture file contains the END Metric Units <status>; (OFF)
INCLUDE
keyword, which indicates the end of fixture information. KEEPOUT
HOLES
The Fixture Description Block
Options
This block contains three sections: options, keepout, and
holes. The options section describes attributes of the The OPTIONS keyword marks the beginning of a block
fixture. Typically, you enter all these parameters, except of global options for the fixture (See above). The
the Fixture Part Number, in Board Consultant or load OPTIONS keyword contains no parameters.
them from the fixture defaults file. When Board
Options Syntax:
Placement runs later, it reads the options from the
fixture defaults file object, if it exits. If the fixture OPTIONS
defaults file object is not present, it reads the options
contained in the board file. These options are then Fixture Type
placed in the fixture.o file. For any option not Fixture Type specifies the type of test fixture that you
specified, the values shown in parentheses are used. The are using. Eight types of fixtures are available.
keepout and holes sections describe areas of the fixture
to be used for custom applications. Typically you enter
these attributes using Fixture Consultant. NOTE
Chapter 6, Completing and Debugging Tests in
The fixture description block is organized as follows: Test & Fixture Development describes each fixture
OPTIONS type.
Fixture Type <type>; (EXPRESS)
Fixture Size <size>; (FULL)
Fixture Handler <type>;(QPT) For the fixture file syntax, the fixture types are
Fixture Part Number <number>; specified with one-word designations. The Fixture Type
Top Probes Allowed <status>;(OFF)

Example 5-2 Fixture Type syntax Table 5-3 Fixture Type options (continued)
Fixture Type <type>; Option Description

<type> can be: QuickPress QuickPress fixture.
SIMPLATE JOT JOT fixture.
EXPRESS
NO-WIRE
CASSETTE Fixture Size
XG-50
XG-50 CASSETTE Fixture Size specifies the area of the testhead that the
QUICKPRESS fixture will cover. BANK1 implies that the fixture will be
JOT
installed on bank 1 of the testhead (over modules 0 and
1). BANK2 implies that the fixture will be installed on
bank 2 of the testhead (over modules 2 and 3). FULL
implies that the fixture will be installed on both banks 1
Table 5-3 Fixture Type options and 2, covering the full testhead.
Option Description <size> Specifies the size of the fixture. BANK1 and
BANK2 are half-size fixtures, covering half the testhead.
SIMPLATE SimPlate fixture. FULL is a full-size fixture, covering all four modules.
EXPRESS SimPlate Express fixture. FULL cannot be used with the Express Cassette fixtures.
NO-WIRE Agilent No-Wire Technology Example 5-3 Fixture Size syntax

fixture.
Fixture Size <size>;
CASSETTE Express Cassette fixture.
<size> can be:
XG-50 SimPlate XG-50 fixture.
BANK1
XG-50 CASSETTE XG-50 Cassette fixture. BANK2
FULL

Fixture Part Number Example 5-5 Heavy probe force syntax
Identifies the exact type of fixture to be used. Unlike the Heavy probe force <force>;
other options, the fixture part number is automatically <force> is a <numeric constant>
placed in the file by the software. The Fixture Part
Number options are accessible via Agilent’s website.
Light Probe Force
Top Probes Allowed Light probe force specifies the force, in ounces, of the
light weight probes to be used in the fixture.
Top Probes Allowed specifies whether top electrical
probes are allowed in the fixture. This attribute has no <force> Specifies the spring force of the probe, in
effect on TestJet probes. ounces.
ON specifies that top probes are allowed (the fixture
Example 5-6 Light probe force Syntax
must have a top plate). OFF specifies that top probes are
not allowed. If you don't specify this, the system will Light probe force <force>;
assume OFF. <force> is a <numeric constant>
Example 5-4 Top Probes Allowed syntax

Density Threshold
Top Probes Allowed <status>; Density threshold is the maximum amount of probe
<status> can be: force (ounces per square inch) allowed to probe the
board. The value specified for density threshold is used
ON to calculate the maximum number of probes per square
OFF
inch that can probe the board. If you don't specify a
density threshold, the system uses a value of 800 for
Heavy Probe Force mechanical fixtures such as the Express Cassette fixture
Heavy probe force specifies the force, in ounces, of the or a value of 104 for vacuum fixtures such as the
heavy weight probes to be used in the fixture. SimPlate fixture.
<force> Specifies the spring force of the probe, in For example, suppose you are using probes which are
ounces. rated at 8 oz. of force each and the density threshold is
set to 80. This means that you can have a maximum of

10 probes per square inch on the board. The probes per Semi Auto if the fixture is to be wired with either, an
square inch value is calculated by Probe Select. automatic, or a semi-automatic machine. If the fixture
will be wired by hand, you need to specify MANUAL. If
<value> Specifies the maximum force in ounces per
you use AUTO, the fixture wiring report will be sorted by
square inch from the probes within that area to probe the
color, gauge, and length of wire. Locations will be
board.
specified in X-Y coordinates. If you specify MANUAL, the
fixture wiring report will be sorted to avoid having to
Example 5-7 Density Threshold syntax
wire areas that are already covered by other wires.
Density Threshold <value>; Locations will be specified in brc (bank-row-column),
<value> is a <numeric constant> format.
Specifying WIRELESS tells Probe Select not to block
Autofile P-Pins. Fixture tooling also produces a nets file that can
be used to produce files for most auto-routing
Autofile specifies the identification number that should
equipment.
be wired into the fixture for auto-identification. This
allows the correct board program(s) to be loaded when <option> Specifies the format of the fixture reports.
the operator loads the fixture. AUTO implies a fully automatic, or a semi-automatic
wire-wrapping system. MANUAL implies that the operator
<code> This is the identification number of the fixture,
must find the location and apply the wire-wrap.
it is an integer value in the range from 11 to 4094. If you
do not specify an autofile, Fixture Tooling will
Example 5-9 WireWrapping syntax
automatically assign a unique one.
WireWrapping <option>;
Example 5-8 Autofile syntax
<option> can be:
Autofile <code>;
AUTO
<code> is an <integer>
MANUAL
SEMI AUTO
WireWrapping WIRELESS
The WIREWRAPPING keyword describes the technology

used to wire the fixture. You need to specify AUTO or

Metric Units <filename> Specifies the name of the file whose

contents are to be included in the fixture file.
Metric Units specifies if metric units are to be used in
the fixture reports.
Example 5-11 INCLUDE syntax
<option> Specifies if metric units are to be used. OFF
specifies units as tenth mils (thousandths of an inch) INCLUDE <filename>;
<filename> is a <string expression>

Example 5-10 Metric Units syntax
Example:
Metric Units <option>;
<option> can be:
ON Keepout - (Fixture)
OFF
define a polygon (at least three non-colinear points).
Include This polygon identifies an area of the fixture where no
The INCLUDE keyword allows the contents of a specified personality pins or probes can be placed. The points are
file to be inserted at that point in the file. Include described by their X-Y coordinates with respect to the
statements may be nested to any depth; this is useful for fixture origin. The points can be listed in either a
incorporating standard options and configurations into clockwise or counter-clockwise direction starting at the
new board files. When the new file is stored, the lower left corner of the area. Each KEEPOUT keyword
information from the include file becomes part of the specifies one keepout area.
new file, and the link to the include file is lost. The Each keepout area can specify a side attribute. This
include filename can be a relative or an absolute attribute indicates which probe plate contains the
pathname. The filename should be enclosed in quotes. keepout area. If no side attribute is specified, the
keepout area applies to the bottom probe plate.
Do not confuse a fixture keepout area with a board
keepout area. A fixture keepout area is fixed relative
to the fixture tooling origin. A board keepout area is

relative to the board origin and can change if the board Fixture Size BANK2
orientation changes. Also, each fixture keepout area is . . . .
. . . .
specified following the OPTIONS statement but before
Wirewrapping MANUAL;
the first BOARD statement. A board keepout area is KEEPOUT BOTH
specified only after a BOARD statement. For more 20000, 20000
information about board keepouts, see the KEEPOUT 40000, 20000
statement listed in Board Description Block on 40000, 40000
page 5-6 section. The Keepout options are described in 20000, 40000;
BOARD board1
Table 5-4 on page 5-16.
. . .
. . .
Example 5-12 KEEPOUT syntax
KEEPOUT Table 5-4 KEEPOUT options

<x_coord>, <y_coord> Option Description
. . . .
<x_coord>, <y_coord>; <x_coord> X_coordinate of a keepout point.
KEEPOUT <attribute> <y_coord> Y_coordinate of a keepout point.

BOTTOM Keepout area on the bottom probe plate.
. . . . When no side is specified, bottom is the
<x_coord>, <y_coord>; default.
<attribute> can be: TOP Keepout area on the top probe plate.
BOTTOM BOTH Keepout area on both the top and bottom
TOP
BOTH
probe plates.
Example:
OPTIONS

Holes The Default Placement options are shown in Table 5-6

on page 5-19.
The HOLES keyword indicates a list of hardware holes in
the probe plates of a fixture. Holes options are described
in Table 5-5. Table 5-5 HOLES options
Example 5-13 HOLES syntax Option Description
HOLES <diameter> Diameter of the hole in tenth mils.

<diameter>, <X coord> <Y coord>;
<X coord> and Specify the location of the hole.
<diameter>, <X coord> <Y coord> <side>;
<Y coord>
<diameter> is a constant
<X coord> and <Y coord> are constants
<side> The TOP keyword specifies that the
hole is in the top probe plate; the
side> can be: bottom keyword specifies that the hole
BOTTOM is in the bottom probe plate; the BOTH
TOP keyword specifies that the hole is in
BOTH
both probe plates. If no side is
Example: specified, the hole is in the bottom
HOLES probe plate only.
2500, 145000 -70000;
2500, 145000 70000 TOP;
2500, 155000 70000; The Board Description Block
2500, 155000 -7000 BOTH;
Each board description block describes the fixturing for
a board that is to be tested on the fixture. There is one
Default Placement board description block for each board. The following
sections describe the keywords used.
The default placement is restricted syntax and can only
be used in fixture default files. This placement will
override Board Placement's internal default placement.

The board description block is organized as follows: Example 5-15 BOARD syntax
Example 5-14 BOARD description block BOARD <board_id>

<board_id> is a <string expression>
BOARD
INCLUDE Include
PLACEMENT
OUTLINE The INCLUDE keyword allows the contents of a specified
TOOLING file to be inserted at that point in the file. Include
KEEPOUT statements may be nested to any depth; this is useful for
NODE
PINS
incorporating standard options and configurations into
PROBES new board files. When the new file is stored, the
ALTERNATES information from the include file becomes part of the
TRANSFERS new file, and the link to the include file is lost. The
WIRES include filename can be a relative or an absolute
. . . pathname. The filename should be enclosed in quotes.
OTHER
PINS <filename> Specifies the name of the file whose
PROBES contents are to be included in the fixture file.
ALTERNATES
TRANSFERS
WIRES Example 5-16 INCLUDE syntax
GROUP
INCLUDE <filename>;
END BOARD
<filename> is a <string expression>
Board Example:
The BOARD keyword marks the start of the description of INCLUDE "/board/std_options";
all the pieces of the specified board.
<board_id> specifies the name of the board to be
described.

Placement Figure 5-1 Board placement rotation

The PLACEMENT keyword, supplied by Board Placement,
specifies the board's position on the fixture as X and Y
offsets from the fixture's tooling origin to the board
origin. The placement also specifies the rotation of the
board. The rotation is applied to the board first, then the
X and Y offsets. Placement options are described in
Table 5-6.
Example 5-17 PLACEMENT syntax
PLACEMENT <x_offset>, <y_offset> <rotation>;

<x_offset>, <y_offset> <rotation> are
<numeric constants>
Outline
Example:
The OUTLINE keyword specifies a series of points that
PLACEMENT 70362, -10198 90;
define the board’s corners, at the maximum extents. At
least three unique, non-colinear points define the shape
Table 5-6 PLACEMENT options of the board as a polygon. List the coordinates of each
corner in either a clockwise or counter-clockwise
Option Description direction from the starting point coordinate. Do not
<x_offset> X_offset, in tenth mils, of the board origin re-list the starting point again at the end; the compiler
automatically completes the polygon. If your board has
with respect to the fixture origin.
a circular outline, specify the outline as a polygon. The
<y_offset> Y_offset, in tenth mils, of the board origin Outline options are described in Table 5-7 on page 5-20.
with respect to the fixture origin.
Example 5-18 OUTLINE syntax
<rotation> Rotation of the board in degrees. The
positive X axis is 0 degrees. See Figure OUTLINE
5-1. <x_coord>,<y_coord>
<x_coord>,<y_coord>

<x_coord>,<y_coord> Figure 5-2

. . . . , . . . .
. . . . , . . . . (60000, 120000) (150000, 120000)
<x_coord>,<y_coord>; (0, 110000)
(60000, 110000)
<x_coord>,<y_coord> are <numeric constants>
Example:
OUTLINE
0, 0
150000, 0
150000, 120000
60000, 120000
60000, 110000
0, 110000;
(0, 0) (150000, 0)
Table 5-7 OUTLINE options
Option Description
<x_coord> X_coordinate, in tenth mils, of outline
point.
<y_coord> Y_coordinate, in tenth mils, of outline
point.
Tooling
The TOOLING keyword marks the beginning of a list of
all tooling holes. The list is needed to avoid conflicts

with personality pins. The Tooling options are described Keepout - (Board)
define a polygon (at least three non-colinear points) that
Example 5-19 TOOLING syntax
describes an area of the fixture (above or below the
TOOLING board's placement) where no personality pins or probes
<size> <x_coord>,<y_coord>; can be placed. The points can be listed in either a
<size> <x_coord>,<y_coord>; clockwise or counterclockwise direction starting at the
<size> <x_coord>,<y_coord>; lower left corner of the area. Each KEEPOUT keyword
. . . . . . . . . . specifies one keepout area.
. . . . . . . . . .
<size> <x_coord>,<y_coord>; Each keepout area can specify a side attribute. This
attribute indicates which probe plate of the fixture
<size> <x_coord>,<y_coord> are <numeric contains the keepout area. If no side attribute is
constants>
specified, the keepout area applies to the bottom probe
Example: plate.
TOOLING Board keepouts should not be confused with fixture
3750 30650, 30700; keepouts. A board keepout area can change relative to
3750 72500, 36250;
the fixture tooling origin if the board placement
changes. A fixture keepout remains fixed relative to
Table 5-8 TOOLING options the fixture tooling origin and does not change if the
board placement is modified. For information about
Option Description fixture keepouts, refer to Keepout - (Fixture) on
<size> Diameter of tooling hole in ten thousandths page 5-15. The Keepout options are described in Table
of an inch. This value can be 2000 or 3750. 5-9 on page 5-22.
<x_coord> X_coordinate, in tenth mils, of tooling hole. Example 5-20

<y_coord> Y_coordinate, in tenth mils, of tooling hole. KEEPOUT
<x_coord>,<y_coord>
<x_coord>,<y_coord>
<x_coord>,<y_coord>

. . . . Table 5-9 KEEPOUT options (continued)

. . . .
<x_coord>,<y_coord>; Option Description
KEEPOUT <attribute>
<x_coord>,<y_coord> BOTTOM Keepout area on the bottom probe plate.
<x_coord>,<y_coord> When no side is specified, bottom is the
<x_coord>,<y_coord>
. . . .
default.
. . . . TOP Keepout area on the top probe plate.
<x_coord>,<y_coord>;
BOTH Keepout area on both the top and bottom
<attribute> can be:
probe plates.
BOTTOM
TOP
BOTH Node - (Board)
The NODE keyword marks the beginning of a list of all
Example: pins, probes, and wires that connect to the node used in
KEEPOUT TOP a board test. Items that can be included in the list are:
20000, 20000 PINS, PROBES, ALTERNATES, TRANSFERS, and
40000, 20000 WIRES. CRITICAL specifies that the shortest possible
40000, 40000
wire must be used for this node. The Node options are
20000, 40000;
Table 5-9 KEEPOUT options
Option Description
<x_coord> X_coordinate of a keepout point.
<y_coord> Y_coordinate of a keepout point.

Example 5-21 NODE syntax
NODE <node_id> NODE <node_id> <usage> CRITICAL

NODE <node_id> <usage>
NODE <node_id> CRITICAL <node-id> is a <string constant>
<usage> can be:

FUNCTIONAL
GROUND
POWER <supply> <V> ;
POWER <supply> <V> <mux>;
OWER <supply> <V> ; . . . <supply> <V> ;
POWER <supply> <V> <mux>; . . . <supply> <V> <mux>;
<supply> is an <integer constant>
<V> & are <numeric constants>
<mux> can be:MULTIPLEXED
Example:
NODE clock CRITICAL
NODE +5V POWER
1 5.00 3.00 MULTIPLEXED;
Table 5-10 NODE options
Option Description
<node-id> Node name.
CRITICAL The shortest possible wire must be used for the node.
<supply> The power supply connected to the specified node; supplies are in the range 1 to 24.
<V> Programmed voltage of the power supply.

Table 5-10 NODE options (continued)
Option Description
 Programmed current of the power supply.
<mux> Allows the power supplies to be multiplexed through the relays to the boards-under-test. This option is
useful in some cases of multiple board fixtures and multiple board panels. The MULTIPLEXED keyword
forces fixture tooling to insert personality pins into the fixture to access the asru card supplies. However,
fixture tooling is not allowed to wire the pins to the power nodes. Parallel supplies can also use the
multiplexing option.
GROUND The node is used for ground.
POWER The node is used for power.
Pins <pin_info> can be:

The PINS keyword, when used in conjunction with the <dy>
NODE keyword in a board description block, marks the OVERRIDE
OVERRIDE <dy>
beginning of a list of all the personality pins used for the
OVERRIDE <dy> <dx>
specified node. OVERRIDE is used to mark a pin that
would normally be BLOCKED, but which is being used <pin_id> is an <integer>
anyway by installing a special personality pin. The Pins <dy> and <dx> are <numeric constants>
Example:
Example 5-22 PINS syntax
PINS
PINS 11656;
<pin_id> <pin_info>; 10834 25,0;
<pin_id> <pin_info>; 10730 OVERRIDE 10 20;
. . . .
<pin_id> <pin_info>;

probes due to gaps in the numbering. Normal probes are

prefixed with P; transfer probes with T. Probes options
Table 5-11 PINS options are described in Table 5-12.
Option Description Table 5-12 PROBES options
<pin_id> The personality pin expressed as a Option Description
bank,row,column, brc.
50MIL Probe diameter.
<dy> Offset, in tenth mils, used for personality
pins that are bent to avoid probes on the 75MIL Probe diameter.
board. The offset is added to the 100 mil probes will be used if no other option is specified.
personality pin base location to get its
actual fixture location. This offset is in the Y LONG Probe length, if LONG is not specified the
direction only. length is assumed to be short.
<dx> Offset, in tenth mils, in the X direction. It is <dev.pin> The device-pin on which the specified
added to the X-coordinate of the node is to be placed.
personality pin's base location. Use this TOP The probe is to be on the top side of the
when specifying special personality pins fixture.
with the OVERRIDE option.
LWT The probe is light force, if LWT is not
OVERRIDE Marks a pin that would normally be specified then the probe is assumed to be
BLOCKED, but will be used. heavy force. This attribute is assigned only
by Probe Select.
Probes
The PROBES keyword, when used in conjunction with Example 5-23 PROBES syntax
the NODE keyword in a board description block, marks
the beginning of a list of probes connected to the PROBES
<probe_id> <x_coord>,<y_coord> <options>;
specified node. Probes are numbered starting with one. <probe_id>;
Probe numbers may be greater than the number of

. . . in normalized fixture file coordinates. The Alternates

<probe_id>; options are described in Table 5-13.
<probe_id> is an <alpha-numeric expression>
<x_coord> <y_coord> are <numeric constants>
<options> can be:
<dev.pin>
Option Description
TOP <x_coord> X_coordinate, in tenth mils, of the node
<probe_info>
<dev.pin> TOP with respect to the board origin.
<dev.pin> <probe_info>
<y_coord> Y_coordinate, in tenth mils, of the node
TOP <probe_info>
<probe_info> can be: with respect to the board origin.
LWT
<size>
TOP Probe location is on the fixture top plate.
LWT <size> <dev.pin> Device-pin that the node is connected to.
<size> can be:
50MIL 50MIL 50 mil probe.
75MIL
LONG 75MIL 75 mil probe.
Example:
PROBES
P12 34750, 84820 LWT; Example 5-24 ALTERNATES syntax
P23 16080, 12946 Y1.3 TOP;
ALTERNATES
Alternates <x_coord>,<y_coord> <options>;
The ALTERNATES keyword, when used in conjunction . . .
with the NODE keyword in a board description block, <x_coord>,<y_coord>;
marks the beginning of a list containing the X-Y <options> can be:
locations where the previously specified node can be
probed; these are potential locations on the node listed TOP
<dev.pin>
in order of desirability. Any of these can be chosen to be
TOP <dev.pin>
an actual probing location. The X-Y locations should be <size>

<x_coord>, <y_coord> are <numeric constants>

<size> can be:

50MIL
75MIL
Example:
ALTERNATES
25820, 96740 U1.5;
28820, 96740 U2.5 TOP;
31820, 96740 U3.5 50MIL;
Transfers
The TRANSFERS keyword, when used in conjunction
with the NODE keyword in a board description block,
marks the beginning of a list of transfer probes used to
carry signals from the bottom of the fixture to the top
plate. It should only exist if top-probes-allowed is set to
ON. The Transfers options are described in Table 5-14
on page 5-28.

Example 5-25 TRANSFERS syntax
TRANSFERS
<transfer_info>;
<transfer_info>;
. . .
<transfer_info>;
<transfer_info> can be:<probe_id> <x_coord>,<y_coord>

<probe_id> is a <string expression>
Example:
TRANSFERS
T56 98700,38760;
Table 5-14 TRANSFERS options
Option Description
<probe_id> A number from 1 to N where N is number of probes in the fixture. The probe_id will be prefixed by
a T (to indicate that it is a transfer probe).
<x_coord> X_coordinate, in tenth mils, of the node with respect to the board origin.
<y_coord> Y_coordinate, in tenth mils, of the node with respect to the board origin.
Wires pin, or pin to pin. As wires are added to the fixture, they
provide information associating other components of
The WIRES keyword, when used in conjunction with the
the fixture with the specified node. When listing the
NODE keyword in a board description block, marks the
wires attributes: color, gauge, and length, you must list
beginning of a list of wires, used to connect other
all, or none, of them; you cannot list just one or two of
components of the specified node together. Wires may
them. If the wire is included in a GROUP, the WIRES
be specified as connected from: pin to probe, probe to
statement includes the group designation and the type of

wire. The Wires options are described in Table 5-15 on

page 5-30.
Example 5-26 WIRES syntax
WIRES
<wire_info>;
<wire_info>;
. . .
<wire_info>;
<wire_info> can be:

<id> TO <id>
<id> TO <id> <color> <gauge> <length>
<id> TO <id> <type> <gauge> <length> <group des>
<color> is a <string constant>

<gauge> is an <integer>
<length> is a <numeric constant>
<id> can be:

<probe_id>
<pin_id>
<type> can be:
"Tw-pr"
Coax
<probe_id> & <pin_id> are <string expressions>

Example:
WIRES
P23 to T56;
11656 to T56;
10834 to P12;
22301 to P814 Coax 28 1.00, G1;
22377 to P814 "Tw-pr" 28 1.00, G2;
Table 5-15 WIRES options
Options Description
<probe_id> Probe that one end of the wire connects to.
<pin_id> Bank-row-column position of the pin that one end of the wire is connected to.
<color> Color of the wire, this is an arbitrary name of up to 20 characters.
<gauge> Gauge of the wire.
<length> Length of the wire.
<type> Type of wire to be used on the group — twisted pair or coaxial.
<group des> The group. Fixture Tooling assigns group designators as G# where # is a number. The first group
is assigned G1; the second group is assigned G2, and so on.
Other Items that can be included in the list are: PINS,

PROBES, ALTERNATES, TRANSFERS, and WIRES.
The OTHER keyword in a board description block marks
the beginning of a list of information about fixture
components that have not been associated with a node.

Syntax: Example:
OTHER PINS
13456 DRILLED;
The OTHER keyword has no parameters. 13457 SOCKETED;
11608 -15;
Pins 10417 BLOCKED;
12110 OVERRIDE -10 20;
The PINS keyword, when used in conjunction with the
OTHER keyword in a board description block, marks the
beginning of a list of personality pins that have some Table 5-16 PINS options
attributes, or which have not been assigned to any
Option Description
nodes. The Pins options are described in Table 5-16 on
page 5-31. <pin_id> Name of the device-pin.
Example 5-27 PINS syntax <dy> Offset, in tenth mils, used for personality
pins that are bent to avoid probes on the
PINS board. The offset is added to the
<pin_id>; personality pin base location to get its
<pin_id> <dy>;
actual fixture location.
<pin_id> <status>;
<pin_id> <status> <dy>; <dx> Offset, in tenth mils, in the X direction. It
<pin_id> OVERRIDE <dy>;
<pin_id> OVERRIDE <dy> <dx>;
is added to the X-coordinate of the
personality pin's base location. Use this
<pin_id> is a <string expression> when specifying special personality pins
<dy> and <dx> are <numeric constants> with the OVERRIDE option.
<status> can be: DRILLED Refers to a location that has been drilled,
DRILLED but does not have a pin installed.
SOCKETED
BLOCKED SOCKETED Refers to a location that has a personality
pin installed.

Table 5-16 PINS options (continued) Probes
Option Description The PROBES keyword, when used in conjunction with

the OTHER keyword in a board description block, marks
BLOCKED Refers to a personality pin which cannot the beginning of a list of unused probes. In general, they
be used due to interference with a probe. are probes that once contacted a node, but which
through a board change no longer are physically under a
OVERRIDE Marks a pin that would normally be
node. The probe-id is kept so that the probe may be
BLOCKED. referred to by a wire. Probes options are described in
Table 5-17.
Table 5-17 PROBES options
Option Description
<probe_id> The name of the probe. Probes and transfer pins are automatically numbered in the same sequence by
Test Consultant, using numbers from 1 to N where N is the total number of probes and transfer pins in the
fixture. The probe_id for a regular probe will by prefixed by a P; the probe_id for a transfer pin will be
prefixed by a T. Probes are always assigned numbers before transfer pins are assigned numbers. For
example, The 3070 will assign probes numbers P1 - P100, and transfer pins T101 - T150. When
assigning probe names manually, be sure to assign numbers not already assigned to probes or
transfer pins.
<x_coord> X_coordinate, in tenth mils, of the probe with respect to the board origin.
<y_coord> Y_coordinate, in tenth mils, of the probe with respect to the board origin.
TOP Probe is on the top side of the fixture.
LWT Light weight probe. Probe Select uses the density threshold and probe force specifications from Global
Options to determine the need for light weight probes.

Table 5-17 PROBES options (continued)
Option Description
50MIL 50 mil probe instead of a 100 mil probe.
75MIL 75 mil probe instead of a 100 mil probe.
LONG Long probe for dual stage testing.
Example 5-28 PROBES syntax <size> can be:

50MIL
PROBES
75MIL
<probe_id> <x_coord>,<y_coord> <options>;
LONG
<probe_id>;
. . . Example:
<probe_id>;
PROBES
<probe_id> is an <alpha numeric expression> P1 66970, 32670;
<x_coord>, <y_coord> are <numeric constants> P2 66800, 32500 TOP;
P3 22520, 76920 LONG;
<options> can be: P4 22400, 76800 LWT;
<dev.pin>
TOP Alternates
<probe_info>
<dev.pin> TOP The ALTERNATES keyword, when used in conjunction
<dev.pin> <probe_info> with the OTHER keyword in a board description block,
TOP <probe_info> marks the beginning of a list of unused probe locations.
<probe_info> can be: In general, these locations were once candidates for
probing but were not selected during the probe selection
LWT process. These locations are physically no longer under
<size>
LWT <size>
a node. These locations are partially drilled, but do not

contain a probe receptacle. The Alternates options are <options> can be:
described in Table 5-18. TOP
<dev.pin>
Table 5-18 ALTERNATES options TOP <dev.pin>
<size>
Option Description <x_coord>, <y_coord> are <numeric constants>
<x_coord> X_coordinate, in tenth mils, of the node
with respect to the board origin. <size> can be:
<y_coord> Y_coordinate, in tenth mils, of the node 50MIL

75MIL
with respect to the board origin.
Example:
<dev.pin> Device pin the probe will contact if
installed. ALTERNATES
92200, 85600 50MIL;
TOP Probe is located on the top side of the
fixture. Transfers
50MIL 50 mil probe. The TRANSFERS keyword, when used in conjunction
with the OTHER keyword in a board description block,
75MIL 75 mil probe.
marks the beginning of a list of transfer probes that are
not associated with any node. They are kept with this
Example 5-29 ALTERNATES syntax board because that is where they were created, but they
could be used for any other board on the fixture. TestJet,
ALTERNATES QuickPress, and ConnectCheck transfer pins are
<x_coord>,<y_coord> <options>; included in this section.
. . . When manually adding transfer pins, do not assign pin
<x_coord>,<y_coord>; numbers that are already used for probes or other
transfer pins. If you do, you will get a compilation error
such as those that follow:

• A transfer probe was defined previously. should run Board Place again. (WARNING
Each transfer probe should appear in the FDF2)
FDF source once in a TRANSFERS statement.
It may appear in WIRES statements as often To avoid these errors, assign numbers at T10000 and
as necessary. (ERROR FDF29) above (numbers up to 1 million are available).
• Transfer probe conflicts with a personality
pin. The board has been placed in such a The Transfers options are described in Table 5-19.
position that a transfer probe interferes
with a personality pin directly below it.
This wastes both resources. Perhaps you
Table 5-19 TRANSFERS options
Option Description
<transfer_id> Probes and transfer pins are automatically numbered in the same sequence by Test Consultant using
numbers from 1 to N where N is the total number of probes and transfer pins in the fixture. The probe_id
for a regular probe will by prefixed by a P; the probe_id for a transfer pin will be prefixed by a T. Probes
are always assigned numbers before transfer pins are assigned numbers. For example, The 3070 will
assign probes numbers P1 - P100, and transfer pins T101 - T150. When you assign transfer pin
numbers manually, we recommend you start at T10000 so that you are sure to assign a number that
is not yet used.
<x_coord> X_coordinate, in tenth mils, of the node with respect to the board origin.
<y_coord> Y_coordinate, in tenth mils, of the node with respect to the board origin.
<probe_type> Whether or not a probe is installed.
DRILLED Implies that only a hole exists at that location.
SOCKETED Implies that a regular transfer probe is installed.

Example 5-30 TRANSFERS syntax and its other end are moved to that node, in the NODE list.
Table 5-20 describes Wires options.
TRANSFERS
<probe_id> <transfer_info>; Example 5-31 WIRES syntax
<probe_id> <transfer_info>;
. . .
WIRES
<probe_id> <transfer_info>;
<wire_info>;
<wire_info>;
<probe_id> is a <string expression>
. . .
<transfer_info> can be: <wire_info>;
<x_coord>,<y_coord> <wire_info> can be:

<x_coord>,<y_coord> <probe_type>
<pin_id> to <pin_id>
<pin_id> to <pin_id> <color> <gauge>
<length>
<probe_type> can be: <pin_id> in an <alpha-numeric sting>
DRILLED <gauge> is an <integer>
SOCKETED <length> is a <numeric constant>
Example: Example:
TRANSFERS WIRES
T57 10780, 34920 SOCKETED; 21325 to 20125 black 28 8.00;
90880, 65840;
Wires
OTHER keyword in a board description block, marks the
beginning of a list of wires that connect fixture
components that are not on a node. A wire may only be
specified as connected from pin to pin. If either of its
ends connects to a component that is on a node, the wire

exceeded. The Group options are described in Table

5-21 on page 5-38.
Example 5-32 GROUP syntax
Option Description
GROUP <group des> <wire type>
<pin_id> Name of the pin that one end of the wire is
NODE <node name>
connected to. PIN
<pin name>;
<color> Color of the wire, this is an arbitrary name of PROBE
up to 20 characters. <probe name>;
NODE <node name>
<gauge> Gauge of the wire. PIN
<pin name>;
PROBE
<probe name>;
<group des> is a <string constant>
Group
<wire type> can be:
The GROUP keyword marks the beginning of a list of
probes that are to be wired as a group. The GROUP TWISTED
COAX
keyword also specifies the group designator and the
type of wiring to be used. Pins and probes of a group are <node name> is a <string constant>
separated with a semicolon (;). Only one group may be <pin name> is a <numeric constant>
specified under each GROUP keyword. <probe name> is an <alpha numeric constant>
Groups must consist of two nodes that are probed on the

bottom of the board. The compiler determines if the Examples:
distance between the probes specified in a group is too GROUP G1 TWISTED
great for the wire type of that group. The maximum NODE "+5BATT"
separation for a COAX group is 0.5 inches; the maximum PIN
separation for a TWISTED group is 1.0 inch. The 22377;
compiler generates a warning if this distance is PROBE
P814;

NODE "16.0MHZ" End Board

PIN
22378; This keyword marks the end of a board description
PROBE block.
P3;
GROUP G2 COAX END BOARD syntax:
NODE "U1-1" END BOARD
PIN
22301;
PROBEP Protected Unit Description Block
813;
NODE "U1-2" This optional block is used to reserve personality pins,
PIN or BRCs, for custom applications. This block can also
22302; define nodes to be used externally for fixture
PROBE electronics. Because all entries in this block are
P4; protected from modification, the fixture generation
software cannot re-assign any resources already
Table 5-21 GROUP options allocated in this block. You can also use this block as a
place to describe how to wire your custom application,
Option Description which is later provided to the fixture builder in the
wiring report. Typically, you will use Fixture Consultant
<group des> A group of wires.
to create this information.
<node name> Name of one node in the group.
The protected unit description block is organized as
<pin name> Bank-row-column position of a pin follows:
used with a node.
Example 5-33
<probe name> Probe number used with a node.
PROTECTED UNIT
<wire type> Wire to use: coaxial or twisted pair. NODE
PINS
WIRES
OTHER
PINS

WIRES <node-id> is a <string constant>

END UNIT
<usage> can be:
Protected Unit FUNCTIONAL
GROUND
This keyword identifies the beginning of a protected POWER <supply> <V> ;
unit description block. If used, this block must follow POWER <supply> <V> <mux>;
the last board description block in the fixture file. Only POWER <supply> <V> ; . . . <supply> <V>
;
one protected unit block is allowed. The end of the POWER <supply> <V> <mux>; . . .
block is identified by the END UNIT keyword. <supply> <V> <mux>;
<supply> is an <integer constant>
Protected unit syntax:
<V> & are <numeric constants>
PROTECTED UNIT <mux> can be: MULTIPLEXED
The PROTECTED UNIT keyword has no parameters. Examples:

NODE "WIRE 10K RESISTOR TO PROBE"
Node - (External) WIRES
P10 TO TERMINAL;
The NODE keyword in a protected unit marks the NODE "WIRE 10K RESISTOR TO BRC"
beginning of a list of pins and wires that connect to an WIRES
external node. This external node can then be used for 218137 TO TERMINAL;
custom applications or fixture electronics. The node
name must be unique; it must not conflict with any other
node name specified in the fixture file. The Node
Example 5-34 NODE syntax
NODE <node_id>
NODE <node_id> <usage>
NODE <node_id> CRITICAL
NODE <node_id> <usage> CRITICAL

Table 5-22 NODE options
Option Description
<node-id> External node name.
CRITICAL The shortest possible wire must be used for the node.
<supply> The power supply connected to the specified node; supplies are in the range 1 to 24.
<V> Programmed voltage of the power supply.
 Programmed current of the power supply.
<mux> Allows the power supplies to be multiplexed through the relays to the boards-under-test. This
option is useful in some cases of multiple board fixtures and multiple board panels. The
MULTIPLEXED keyword forces fixture tooling to insert personality pins into the fixture to access
the asru card supplies. However, fixture tooling is not allowed to wire the pins to the power nodes.
Parallel supplies can also use the multiplexing option.
GROUND The node is used for ground.
POWER The node is used for power.
Pins used anyway by installing a special personality pin. The

Pins options are described in Table 5-23 on page 5-41.
The PINS keyword, when used in conjunction with the
NODE keyword in a protected unit, marks the beginning
of a list of all personality pins reserved for use with the
specified external node. OVERRIDE is used to mark a pin PINS
that would normally be BLOCKED, but which is being <pin_id> <pin_info>;

. . . Table 5-23 PINS options (continued)

Option Description
<pin_info> can be: <dx> Offset, in tenth mils, in the X direction. It is
• <dy> added to the X-coordinate of the
• OVERRIDE personality pin's base location. Use this
• OVERRIDE <dy>
when specifying special personality pins
• OVERRIDE <dy> <dx>
<pin_id> is an <integer> with the OVERRIDE option.
<dy> and <dx> are <numeric constants>
OVERRIDE Marks a pin that would normally be
Examples: BLOCKED, but will be used.
PINS
11656;
10834 25,0;
Wires
10730 OVERRIDE 10 20; The WIRES keyword, when used in conjunction with the
NODE keyword in a protected unit, marks the beginning
of a list of wires used to connect other components to
the external node. As wires are added, they provide
Table 5-23 PINS options information associating other components in the fixture
with the external node. When specifying wire attributes:
Option Description color, gauge, and length, you must list all, or none, of
<pin_id> The personality pin expressed as a them. The Wires options are described in Table 5-24 on
bank,row,column, brc. page 5-42.
<dy> Offset, in tenth mils, used for personality Example 5-36 WIRES syntax
pins that are bent to avoid probes on the
board. The offset is added to the WIRES
<wire_info>;
personality pin base location to get its
<wire_info>;
actual fixture location. This offset is in the Y . . .
direction only. <wire_info>;

<wire_info> can be:

<id> to <id>
<id> to TERMINAL
<id> to <id> <color> <gauge> <length>
<id> to TERMINAL <color> <gauge> <length> Option Description
<id> can be: <probe_id> Name of probe that one end of the wire
is connected to.
<pin_id>
<probe_id> <pin_id> Bank-row-column position of the pin
that one end of the wire is connected
<gauge> is an <integer> to. If pin_id to pin_id wiring is specified,
<length> is a <numeric constant> both pins must only appear in the
<probe_id> & <pin_id> are <string protected unit section.
expressions>
TERMINAL Specifies that one end of the wire is to
Examples:
be left unconnected in the wiring
WIRES instructions. This open ended wire can
P23 to T56;
later be used to connect to fixture
11646 to TERMINAL;
10834 to P12; electronics or some other custom
P14 to TERMINAL BLACK 28 10.0; application.
<color> Color of the wire, this is an arbitrary
name of up to 20 characters.

Other <pin_id> is a <string expression>

<dy> and <dx> are <numeric constants>
The OTHER keyword, when used in a protected unit,
marks the beginning of a list of pins and wires that have <status> can be:
not been associated with an external node. DRILLED
SOCKETED
OTHER syntax: BLOCKED
OTHER
Examples:
The OTHER keyword has no parameters. PINS
13456 DRILLED;
Pins 13457 SOCKETED;
11608 -15;
The PINS keyword, when used in conjunction with the 10417 BLOCKED;
OTHER keyword in a protected unit, marks the beginning 12110 OVERRIDE -10 20;
of a list of reserved personality pins that have some
attributes, or which have not been assigned to any
Table 5-25 PINS options
external nodes. Because these pins are not assigned to a
node, they can be re-claimed for other resource requests, Option Description
even though they appear in the protected block, unless
they are marked DRILLED or SOCKETED. Table 5-25 on <pin_id> Name of the device-pin.
page 5-43 describes Pins options.
<dy> Specifies an offset, in tenth mils, used for
personality pins that are bent to avoid
probes on the board. The offset is added
PINS to the personality pin base location to get
<pin_id>; its actual fixture location.
<pin_id> <dy>;
<pin_id> <status>;
<pin_id> <status> <dy>;
<pin_id> OVERRIDE <dy>;
<pin_id> OVERRIDE <dy> <dx>;

Table 5-25 PINS options (continued) that external node, in the node list of the protected unit.
Table 5-26 on page 5-45 describes Wires options.
Option Description
<dx> Specifies an offset, in tenth mils, in the X Example 5-38 WIRES syntax
direction. It is added to the X-coordinate of WIRES
the personality pin's base location. Use <wire_info>;
this when specifying special personality <wire_info>;
pins with the OVERRIDE option. . . .
<wire_info>;
DRILLED Refers to a location that has been drilled,
<wire_info> can be:
but does not have a pin installed.
<pin_id> to <pin_id>
SOCKETED Refers to a location that has a personality <pin_id> to TERMINAL
pin installed. TERMINAL to <pin_id>
<pin_id> to <pin_id> <color> <gauge>
BLOCKED Refers to a personality pin which cannot <length>
be used due to interference with a probe. <pin_id> to TERMINAL <color> <gauge>
<length>
OVERRIDE Is used to mark a pin that would normally TERMINAL to <pin_id> <color> <gauge>
be BLOCKED. <length>
<pin_id> is a <string expressions>
Wires <gauge> is an <integer>
<length> is a <numeric constant>
Examples:
OTHER keyword in a protected unit, marks the beginning
of a list of wires that connect fixture components that WIRES
are not on an external node. A wire can only be 21325 to 20125 black 28 8.00;
TERMINAL to 14125 BLUE 28 5.00;
specified as connected from pin to pin or pin to terminal.
If either of its ends connects to a component is an
external node, the wire and its other end are moved to

End
Table 5-26 WIRES options The END keyword identifies the end of the fixture file.
END syntax:
Option Description
END
<pin_id> Pin that one end of the wire connects to. If
pin_id to pin_id wiring is specified, both pins The END keyword has no parameters.
must only appear in the protected unit
section.
TERMINAL One end of the wire is to be left
unconnected in the wiring instructions. This
open ended wire can later be used to
connect to fixture electronics or some other
custom application.
<color> Color of the wire, this is an arbitrary name of
up to 20 characters.
End Unit
Marks the end of the protected unit description block.
END UNIT syntax:
END UNIT
The END UNIT keyword has no parameters.

Sample Fixture File Example 5-39 Sample fixture file

OPTIONS
Fixture Type CASSETTE;
Fixture Size BANK1;
Fixture Part Number 44201SEC;
Top Probes Allowed ON;
Density Threshold 500;
Heavy Probe Force 8;
Light Probe Force 4;
Autofile 3078;
Metric Units ON;
WireWrapping MANUAL;
KEEPOUT BOTH !! Fixture keepout area
65000, -23000
70000, -23000
70000, -12000
65000, -12000;
BOARD Sample
PLACEMENT 70362, -10198 90;
OUTLINE
0,0 150000,0 150000,120000 60000,120000 60000,110000 0,110000;
TOOLING
3750 2000, 2000;
3750 2000, 108000;
KEEPOUT BOTTOM !! Board keepout area
20000, 20000
40000, 20000
40000, 40000
20000, 40000;
NODE clock CRITICAL
PINS
11656;
10834 OVERRIDE 25 -10;

PROBES
P12 34750, 84820 LWT;
P23 16080, 12946 Y1.3 TOP;
ALTERNATES
25820, 96740 U1.5;
28820, 96740 U2.5 75MIL;
31820, 96740 U3.5 50MIL;
TRANSFERS
T56 98700,38760;
. . .
WIRES
P23 to T56;
11656 to T56;
10834 to P12;
NODE VCC
POWER
1 5 8 MULTIPLEXED;
2 5 8;!! Two supplies in parallel
PINS
10101;
10102;
10103;
PROBES
P121 98750, 76920;
P122 84500, 67800;
P123 94000, 12789;
ALTERNATES
12320, 56780;
23450, 67890;
WIRES
10101 to P121;
10102 to P122;
10103 to P123;

NODE +5BATT
PINS
22377;
PROBES
P814 48750, 36920;
WIRES
12101 to P814 "Tw-pr" 28 1.00 G1;
NODE 16.0MHZ
PINS
22378;
PROBES
P3 68750, 56920;
WIRES
11101 to P3 "Tw-pr" 28 1.00 G1;
NODE U1-1
PINS
22301;
PROBES
P813 58750, 46920;
WIRES
10201 to P813 Coax 28 1.00 G2;
. . .
NODE U1-2
PINS
22302;
PROBES
P4 38750, 26920;
WIRES
14201 to P4 Coax 28 1.00 G2;
. . .
OTHER

PINS
13456 DRILLED;
13457 SOCKETED;
11608 -15;
10417 BLOCKED;
PROBES
P1 66970, 32670;
P2 66800, 32500;
P3 22520, 76920;
P4 22400, 76800;
P359 68970, 34670;
P248 24520, 78920 TOP;
ALTERNATES
92200, 85600 50MIL;
TRANSFERS
T57 10780, 34920 SOCKETED;
90880, 65840;
WIRES
10126 to 11326 black 28 8.00;
. . .
GROUP G1 TWISTED
NODE "+5BATT"
PIN
22377;
PROBE
P814;
NODE "16.0MHZ"
PIN
22378;
PROBE
P3;
. . .
GROUP G2 COAX
NODE "U1-1"
PIN
22301;

PROBE
P813;
NODE "U1-2"
PIN
22302;
PROBE
P4;
END BOARD
END

Fixture Defaults File The fixture defaults file is an optional file that provides ■ may copy a standard template into a file named
a template to initialize the fixture object. This gives the fixture_defaults in the board directory and
test developer more control over fixture options; ensures modify it for use with the specific board; or
the fixture object meets the requirements of the board
■ may manually create a file named
being tested; and reduces the need for interactive fixture
fixture_defaults in the board directory.
development.
There are 18 fixture templates in the
Without a fixture defaults file, the development process
$AGILENT3070_ROOT/standard/fixture/defaults/
initializes the fixture object by moving data and options
directory, named after the type and size of fixture they
into the fixture object from the .hp3070 file, the config
support. They include the following:
object file, the board object file, and the board_xy object
file. The test developer might add other information, • express_bank1
such as fixture keepouts, by manually listing, editing • express_bank2
and recompiling the initialized fixture file during an • express_full
interactive development cycle. When a fixture defaults • express_dual_well
file is used, data from the usual sources will be ignored • no_wire_bank1
(except the .hp3070 file) and information in the fixture • no_wire_bank2
defaults object file is used instead. • no_wire_full
The fixture defaults file is created and compiled before • no_wire_dual_well
Test Consultant begins the automatic test generation • cassette_bank1
process. The test developer • cassette_bank2
■ may use an Agilent-supplied standard fixture • JOT_bank1
defaults file template; • JOT_bank2
• JOT_full
■ may modify an Agilent-supplied standard • JOT_dual_well
template for general use;
• QPT_bank1
• QPT_bank2
• QPT_full

• QPT_dual_well
ADVICE
A fixture defaults file must be compiled before it can be
The size and type specified in any fixture default
used. Use the following BT-BASIC command to
file must match what is in the board file. If they do
compile the file when in the standard/fixture/defaults
not match, an error will be generated when the
subdirectory:
Board Placement program is executed.
compile <template name>; defaults
CAUTION If a fixture defaults object file is not found as

fixture_defaults.o in the board directory or with the
✸When a < template name.o> is located in the
$AGILENT3070_ROOT/standard/fixture
required name in the $AGILENT3070_ROOT/standard
/fixture/defaults/, the fixture information from the other
/defaults subdirectory, it will be used for all board directory files will be used to initialize the fixture
fixtures of that type, unless a local object.
fixture_defaults.o file is found.
When a <boards>/<board name>/fixture_defaults

file exists, it must be compiled in the local board
directory.
compile fixture_defaults; defaults
ADVICE
Failure to compile the fixture defaults file will
cause the software to ignore the optional fixture
defaults files. This was done for backward
compatibility.

Sample Fixture This section describes the syntax of the fixture defaults
file.
Defaults File
Example 5-40 Fixture defaults (express_full) format
!!!! 13 0 1 971791024 0000

!---------------------------------------------------------------------------
!FIXTURE DESCRIPTION LISTER Tue Oct 17, 2000 07:57:28 AM
!
!express_full
!---------------------------------------------------------------------------
! To activate this fixture default file, compile it with the fixture compiler
! using the default option. The BT-basic command is
!
! compile <fixture>; fixture,defaults
!
! You can override the global fixture default files by making a copy of the
! applicable file and placing it in the board directory as “fixture_defaults”
! with the desired changes. You must then compile the file using the command
! above before the software will use it to initialize the fixture.
!
!
! Mandatory fields for a default file
!
OPTIONS
Fixture Size FULL;
Top Probes Allowed OFF;

Density Threshold 104.0;

Heavy Probe Force 8.0;
Light Probe Force 4.0;
Metric Units OFF;
Wirewrapping AUTO;
!
! Optional fields for a default file
!
!OPTIONS
! Fixture Part Number
! Autofile
! The customer may also include fixture keepouts to reserve space for fixture
! electronics or hardware. Fixture keepouts must use fixture coordinates
! which uses the left most fixture alignment pin as the origin. A typical
! example might be
!
KEEPOUT
200000, 15000
200000, 35000
240000, 35000
240000, 15000;
!
! New feature
!
! This allows you to define your own default placement instead of using the
! placement built into Board Placement.
!
! Precedence for using placements is from highest to lowest: board_xy placement,
! the Default Placement noted below, and last, the built in placement used by
! Board Placement.

! Default Placement 30198, -77677 0.0;
END
The Options Sections ■ Metric Units specifies if metric units are to be

used in the fixture reports.
The mandatory fields list the fixture settings that are
translated to Board Consultant. Options include the ■ WireWrapping describes the technology used to
following: wire the fixture.
■ Fixture Type refers to the type of fixture. Options ■ The optional fields include those settings that are
include Cassette, Express, No-Wire, software-generated and include the following:
QuickPress, and JOT. ■ Fixture Part Number identifies the type of
■ Fixture Size specifies the area of the testhead that fixture. This number is automatically placed in the
the fixture will cover. Options include file by the software.
Dual_well, Full, Bank1, and Bank2. ■ Autofile specifies the identification number that
■ Fixture Handler identifies the fixture handling auto-identifies the fixture. If you do not specify an
hardware. This option will not be present in the autofile, Fixture Tooling will automatically assign
file if no fixture handler is used. Options include a unique one.
QPT (QuickPress) or JOT.
Keepout
■ Top Probes Allowed specifies if probes will be
used for testing the top of the board. The Keepout - (Fixture) option specifies the area of the
fixture in which probes cannot be placed.
■ Density Threshold is the maximum amount of
probe force allowed to probe the board.
Default Placement
■ Heavy Probe Force specifies the force, in ounces,
of the heavy weight probes. This option identifies where the board is placed on the
fixture, and overrides the built-in default placement for
■ Light Probe Force specifies the force, in ounces, board placement, but not the placement specified in the
of the light weight probes. board_xy.

Dividing Lines
The fixture defaults file can contain dividing lines to
improve the readability of the file. A dividing line is
defined to be:
■ a blank line or
■ a line of dashes preceded by an exclamation point.
Comments
Any items preceded by an exclamation point are treated
as a comment.

User-Modifiable The standard fixturing software in the Agilent3070 is parameters. The result of this is that nodal access is
well suited to the majority of boards being tested by the increased by allowing closer probe spacing.
Fixture system. However, in some cases the standard parameters
Two options are available for determining the minimum
Components used to generate fixture build files may not be optimal.
probe spacing. If the board config file does not specify
New probe types are being introduced to the test
enable advanced fixturing, then the standard
industry as loaded board technology advances. Fixture
(conservative) probe spacing algorithm will be used. If
vendors are providing enhancements to fixture kits to
the board config file specifies enable advanced
suit the special needs of advanced users. Both of these
fixturing, the advanced (aggressive) probe spacing
trends have created requirements for more flexibility in
algorithm will be used. Contact your fixture vendor to
defining fixtures and fixture components.
ensure they can construct a fixture with the tighter
To meet this need, the Agilent3070 test system offers an spacing. The standard probe spacing and the advanced
advanced fixturing feature called User-Modifiable probe spacing provided by the Agilent-supplied
Fixture Components. This feature moves key attributes component files are shown in the Table 5-27- Table
of fixture kits, probes and tooling pins into files that can 5-29 at the end of this section. The algorithms for each
be edited by the test developer to create custom type of spacing are shown in Understanding Probe
fixturing applications. Spacing in Chapter 3 of the Test and Fixture
Development documentation.
The user-modifiable fixture and probes files, also called
fixture component files, are files that define specific In most cases, you will know before hand that special
attributes of fixture kits, probes and tooling pins. The components are needed. For example, if you are
test developer may create custom versions of these files targeting a non-Agilent standard size probe, you know
to redefine attributes as needed for particular that all the probes have different characteristics. Or, if
applications. you have a board that is physically too large for the
standard Agilent fixture kits, you can work with your
Fixture component files are used to define oversize
fixture vendor to define a custom oversize fixture for the
fixture kits and change the minimum spacing between
board. In these situations, copy the appropriate fixture
probes. For example to use probes without sockets, you
component files to a specific sub-directory in the local
could modify the 100-, 75- and 50-mil component files
board directory and modify them as needed.
with updated probe sizes, probe spacing and drilling

In other cases, you may discover during test In general terms, the test developer will copy a standard
development that probe spacing is too close or that fixture component file for the component requiring
tooling pins are blocking resources. Correcting this modification into the local board directory, and then edit
requires the test developer to copy and modify the this file to change one or more of the attributes. This is
appropriate component files, then restart test very much like copying a standard digital library to the
development from the process step, described in local board directory and modifying it for use with this
Chapter 4, Generating Tests and Fixture Files in the board.
Test and Fixture Development documentation.
ADVICE
CAUTION All probes on the fixture using a given modified
✸You will need to remove the /<board
name>/fixture directory before restarting the test
probe file are affected. There is not a way to
modify a single probe’s attributes. However, if a
development process. given probe has minimal usage, for example 50
Mil probes, you could minimize the impact by
modifying that probe file.
CAUTION
✸You should consult with your fixture vendor

before making any changes to fixture component
The fixturing software will look in various defined
directories to locate the needed fixture component files.
files. Failure to do so could result in drill probe If the software finds none in the local board directory, it
plates that cannot be populated with probes or will use the standard files. Users may also change the
may add significant costs to building the fixture. standard files, but those changes will then apply to all
fixtures developed on that system when the advanced
fixturing feature is enabled.
NOTE The fixture component files are modeled after the
The fixture defaults and fixture/components must library files in structure, usage and file location.
be defined during the Creating Board The fixture component files may be copied from the
Information process, prior to generating tests and $AGILENT3070_ROOT/standard/fixture/components
fixture files. subdirectory to alternate locations before Test

Consultant begins the automatic test generation process.

The test developer: CAUTION
■ may use Agilent-supplied component files; ✸ If the $AGILENT3070_ROOT/standard

/fixture/components files are modified, those
■ may modify Agilent-supplied component files for changes will then apply to all fixtures developed
general use; on that system when the advanced fixturing
feature is enabled in the board config file.
■ may copy $AGILENT3070_ROOT
/standard/components files into a board
subdirectory called custom_fix and modify them There are 13 fixture components templates in the
for use with the specific board. $AGILENT3070_ROOT/standard/fixture/components/
directory, named after the type of fixturing component
NOTE they support. They include the following:
Place the fixture component files in a board • 100MilLongProbe
subdirectory called custom_fix to prevent them • 100MilProbe
from being deleted with the fixture directory • 75MilProbe
during iterative test development. • 50MilProbe
• 39MilProbe
See Define the custom_fix Directory on page 3-8 in • ToolingPin200
the Test and Fixture Development documentation for • ToolingPin375
more information. • ExpressBank1Fixture
• ExpressBank2Fixture
CAUTION • ExpressFullFixture
• No-WireBank1Fixture
✸Component file names CANNOT be changed.
Software errors will result. Only file contents can • No-WireBank2Fixture
be modified. • No-WireFullFixture
It is not necessary to compile these files.

Fixture Probe Fixture Component Files Syntax CollisionDiameterMils - Diameter in thousandths of

an inch of the clear space required for this probe. Used
Components Files There are ten fields defined in the fixture component
by Probe Select.
files for probes:
Syntax ProbePlateDrill - Size and style of drill for drilling
NOTE the probe plate.
All fields are used by Fixture Tooling except SupportPlateDrill - Size and style of drill for drilling
where noted. the support plate.
GroundPlateDrill - Size and style of drill for drilling
Name- Comment field - not used by the software (for the ground plane (XG-50).
compatibility with "special" software) GroundPlateShallowDrill - Size and style of drill for
Usage - Describes how this probe type should be drilling the ground plane.
selected: Used by Probe Select. GroundPlateClearance - Size and style of drill for
■ preferred - use this probe type if at all possible drilling the ground plane.
■ acceptable - use this probe type only as needed See Example 5-41 on page 5-63 through Example 5-45
on page 5-64 for default syntax.
■ minimize - don't use this probe type unless
absolutely necessary Tooling Pin Fixture Component Files Syntax
■ unavailable - do not use this probe type at all There are six fields defined in the fixture component
WireWrapCount - Describes the number of wrapped files for tooling pins:
wires that this probe can accommodate.
NOTE
DiameterMils - Diameter in thousandths of an inch of
the probe socket. Used by Probe Select. All fields are used by Fixture Tooling except
where noted.

Name- Comment field - not used by the software (for right of the left edge and 8.5275" up from the bottom of
compatibility with "special" software) a standard Agilent3070 fixture.
DiameterMils - Diameter in thousandths of an inch of
the pin. Used by Probe Select. NOTE
Logically, the probe plate size should be larger
CollisionDiameterMils - Diameter in thousandths of
than the maximum board size which should be
an inch of the clear space required for this pin. Used by
larger than the probe area. However, the software
Probe Select.
will NOT check for these relationships.
ProbePlateHoleMils - Diameter in thousandths of an
inch for probe plate hole.
ProbePlateMinX - The location of the left edge of the
ProbePlateDrill - Size and style of drill for drilling probe plate referenced to "fixture zero".
the probe plate
ProbePlateMaxX - The location of the right edge of the
SupportPlateDrill - Size and style of drill for drilling probe plate referenced to "fixture zero".
the support plate
ProbePlateMinY - The location of the lower (front)
See Tooling Pin Fixture component defaults in Example edge of the probe plate referenced to "fixture zero".
5-46 on page 5-64 and Example 5-47 on page 5-64.
ProbePlateMaxY - The location of the upper (top) edge
Fixture Kit Component File Syntax of the probe plate referenced to "fixture zero".
BoardMaxX - The maximum width of a board that will fit
There are ten fields defined in the fixture component
on this fixture (not referenced to fixture zero).
files for fixture kits:
BoardMaxY - The maximum height of a board that will
All fields are used by all fixturing software.
fit on this fixture (not referenced to fixture zero).
Note: Probe Plate and Probe Area dimensions are
ProbeAreaMinX - The location of the left edge of the
referenced to the "fixture zero" of a standard
area in which probes can be placed in this fixture,
Agilent3070 fixture. Fixture zero should be thought of
referenced to "fixture zero".
as a fixed location on the testhead. The dimensions
describe the fixture dimensions in relation to that fixed
location. For reference, fixture zero is 0.1889" to the

ProbeAreaMaxX - The location of the right edge of the

ProbeAreaMinY - The location of the lower edge of the
ProbeAreaMaxY - The location of the upper edge of the
See Example 5-48 on page 5-64 through Example 5-53
on page 5-65 for default syntax.
Comments
Any items preceded by an exclamation point are treated
as a comment.

Sample Fixture This section describes the syntax of the fixture Example 5-43 75MilProbe file
components files.
Components Files Name: 75 mil
Example 5-41 100MilLongProbe file Usage: preferred
DiameterMils: 52
WireWrapCount: 3
Name: LONG
CollisionDiameterMils: 88
Usage: preferred
ProbePlateDrill: 0.055in.,Long,Flute
DiameterMils: 79
SupportPlateDrill: 2.30mm,Long,Flute
WireWrapCount: 3
GroundPlateDrill: 0.0625in,Std.,Flute
GroundPlateClearance: 0.080in,Std.,Flute
ProbePlateDrill: 2.10mm,Long,Flute
SupportPlateDrill: 2.60mm,Std.,Flute
GroundPlateDrill: 0.0625in,Std.,Flute Example 5-44 50MilProbe file
Name: 50 mil
Example 5-42 100MilProbe file Usage: minimize
DiameterMils: 36
WireWrapCount: 1
Name: 100 mil
Usage: preferred
ProbePlateDrill: 0.037in,Long,Flute
DiameterMils: 66
SupportPlateDrill: .043,in.,Std,Flute
WireWrapCount: 3
ProbePlateDrill: 1.75mm,Long,Flute
SupportPlateDrill: 2.30mm,Long,Flute

Example 5-45 39MilProbe file Example 5-48 ExpressBank1Fixture file
Name: 39 mil ProbePlateMinX: -0.1889

Usage: unavailable ProbePlateMaxX: 15.6611
DiameterMils: 32 ProbePlateMinY: -8.5275
WireWrapCount: 1 ProbePlateMaxY: 9.4725
CollisionDiameterMils: 46 BoardMaxX: 15.6000
ProbePlateDrill: 0.0312in,Long,Flute BoardMaxY: 17.7000
SupportPlateDrill: .039,in.,Std,Flute ProbeAreaMinX: 0.5611
GroundPlateDrill: 0.0625in,Std.,Flute ProbeAreaMaxX: 14.9111
GroundPlateClearance: 0.080in,Std.,Flute ProbeAreaMinY: -7.6430
ProbeAreaMaxY: 8.5870
Example 5-46 ToolingPin200 file
Example 5-49 ExpressBank2Fixture file
Name: Tooling
DiameterMils: 200 ProbePlateMinX: -0.1889
CollisionDiameterMils: 220 ProbePlateMaxX: 15.6611
ProbePlateDrill: 3.6mm,Long,Flute ProbePlateMinY: -8.5275
SupportPlateDrill: .125in.,Std,Flute ProbePlateMaxY: 9.4725
BoardMaxX: 15.6000
BoardMaxY: 17.7000
Example 5-47 ToolingPin375 file ProbeAreaMinX: 0.5611
ProbeAreaMaxX: 14.9111
Name: Tooling ProbeAreaMinY: -7.6430
DiameterMils: 490 ProbeAreaMaxY: 8.5870
ProbePlateDrill: 0.25in.,Long,Flute
SupportPlateDrill: 4.75mm,Std,Flute

Example 5-50 ExpressFullFixture file Example 5-52 No-WireBank2Fixture file
ProbePlateMinX: -0.1889 ProbePlateMinX: -0.1889

ProbePlateMaxX: 29.9111 ProbePlateMaxX: 15.6611
ProbePlateMinY: -8.5275 ProbePlateMinY: -8.5275
ProbePlateMaxY: 9.4725 ProbePlateMaxY: 9.4725
BoardMaxX: 29.8000 BoardMaxX: 15.6000
BoardMaxY: 17.7000 BoardMaxY: 17.7000
ProbeAreaMinX: 0.5611 ProbeAreaMinX: 0.3360
ProbeAreaMaxX: 29.1611 ProbeAreaMaxX: 15.1360
ProbeAreaMinY: -7.6430 ProbeAreaMinY: -7.9030
ProbeAreaMaxY: 8.5870 ProbeAreaMaxY: 8.8470
Example 5-51 No-WireBank1Fixture file Example 5-53 No-WireFullFixture file
ProbePlateMinX: -0.1889 ProbePlateMinX: -0.1889

ProbePlateMaxX: 15.6611 ProbePlateMaxX: 29.9111
ProbePlateMinY: -8.5275 ProbePlateMinY: -8.5275
ProbePlateMaxY: 9.4725 ProbePlateMaxY: 9.4725
BoardMaxX: 15.6000 BoardMaxX: 29.8000
BoardMaxY: 17.7000 BoardMaxY: 17.7000
ProbeAreaMinX: 0.3360 ProbeAreaMinX: 1.1360
ProbeAreaMaxX: 15.1360 ProbeAreaMaxX: 28.5860
ProbeAreaMinY: -7.9030 ProbeAreaMinY: -7.9030
ProbeAreaMaxY: 8.8470 ProbeAreaMaxY: 8.8470

Table 5-27 Probe to Probe Spacing

Standard and This section shows the probe to probe spacing, probe to Probe Size Standard Advanced
tooling pin spacing and probe to personality pin spacing
Advanced probe for standard fixturing and advanced fixturing as defined 39-Mil to 50-Mil 41.0 41.0
Spacing in the Agilent-supplied component files. All dimensions 39-Mil to 39-Mil 39.0 39.0
are center-to-center spacing and are in mils (0.001”).
Table 5-27 Probe to Probe Spacing Table 5-28 Probe to Tooling Pin Spacing
Probe Size Standard Advanced Probe/Tooling Pin size Standard Advanced
Long 100-Mil to Long 100.0 100.0 Long to 0.375” Tooling 291.0 289.5
100-Mil to Long 100-Mil 95.0 91.5 100-Mil to 0.375” Tooling 285.0 283.0
100-Mil to 100-Mil 85.0 85.0 75-Mil to 0.375” Tooling 278.0 276.0
75-Mil to 75-Mil 70.0 70.0 Long to 0.200” Tooling 160.0 149.5
39-Mil to Long 100-Mil 62.5 62.5
39-Mil to 100-Mil 56.0 56.0
39-Mil to 75-Mil 49.0 49.0

Table 5-29 Probe to Personality Pin Spacing (These values

can not be changed)
Probe Size to P-Pin Standard Advanced

Long 100-Mil 125.0 125.0
100-Mil 100.0 100.0
75-Mil 93.0 93.0
50-Mil 85.0 85.0
39-Mil 83.0 83.0

6 Log Record Format
In this chapter... ■ What are Log Records?, 6-2 Prerequisites

■ About Log Record Prefixes, 6-3
■ Hierarchy of Log Records, 6-8 chapter.
■ Interpreting the Log Records, 6-10
■ How Log Records are Formatted, 6-15
■ Descriptions of the Log Records, 6-17
using this chapter.
This chapter describes the format of the standard log
records generated by your test system for use by
Pushbutton Q-STATS. Although an in-depth
understanding of log records is not necessary for general
users of your test system, it is essential for those who
wish to integrate Agilent board test data with
non-Agilent (custom) applications.
Objectives
able to:
■ Understand the structure and syntax of the log
records

Chapter 6: Log Record Format
What are Log Test data is stored in files as a series of formatted

records called log records. Each record consists of a
Records? character string which represents information. Because
the records must be read and interpreted by programs,
the characters in each record are arranged in precise
formats. You must be familiar with these formats if you
wish to interpret existing log records or generate your
own from scratch.
NOTE
Because log records are simply strings of ASCII
characters, you can load a log record file into the
BT-BASIC workspace and examine it. Or, if you
are familiar with the shell, you can examine log
records with the more command or an editor such
as vi. See Chapter 2, Datalogging in Information
Management to determine where the log files are
located.

About Log Record All standard log records generated by your test system Although there can be any number of @BLOCK log
contain a prefix that consists of the @ symbol followed records generated, only one type of log record can begin
Prefixes by several descriptive characters that uniquely identify with an @BLOCK prefix.
the type of record. For example, prefix @BLOCK indicates
The records are described in Table 6-1.
that the record describes a block, or group of tests.
Table 6-1 Log record prefixes
Prefix Purpose Generated by

@A-CAP capacitor test results capacitor
@A-DIO diode test results diode
@A-FUS fuse test results fuse
@A-IND inductor test results inductor
@A-JUM jumper test results jumper
@A-MEA measurement results measure
@A-NFE N-channel FET test results nfetr
@A-NPN NPN transistor test results npn
@A-PFE P-channel FET test results pfetr
@A-PNP PNP transistor test results pnp
@A-POT potentiometer test results potentiometer
@A-RES resistor test results resistor
@A-SWI switch test results switch

Table 6-1 Log record prefixes (continued)

@A-ZEN zener test results zener
@ALM identify a real-time alarm alarm program
@AID identify board causing an alarm alarm program
@ARRAY digitizer results analysis digitizer

report analog
@BATCH batch identifier log board
@BLOCK test block identifier test
test analog
@BS-CON describe boundary-scan test Boundary-Scan
@BS-O list of open pins (boundary-scan) Boundary-Scan
@BS-S list of shorted pins (boundary-scan) Boundary-Scan
@BTEST describes board test log board start
log board end
@CCHK Connect Check test results test
@DPIN list failing pins for one device cont digital
probe
test


@D-PLD PLD programming results log is, log out, log failure, and other
BT-BASIC logging functions
@D-T digital shorts test results test
@GRP group of related subrecords log level is indictments
@INDICT list potentially failing devices log level is indictments
@LIM2 analog test high/low limits current
diode
fuse
jumper
measure
nfetr
npn
pfetr
pnp
switch


@LIM3 analog test nom. & tol. limits capacitor
inductor
potentiometer
resistor
zener
@M-CL status of a cluster test log level is failures
log level is all
@NETV network verification record prsetup program
@NODE list of nodes probe
probe failures
@PCHK Polarity Check test results test
@PIN list of pins pinsfailed
@PF pins failure results test
@PRB probe failure results probe
@RETEST indicates log clear for retest log clear for retest
@RPT messages logged by report report
@S-PROC describes process in a serial test test


@TJET TestJet test results test
@TS shorts test results (destination) test shorts
@TS-D list of shorted nodes test shorts
@TS-O list of open nodes test shorts
@TS-P list of phantoms test shorts
@TS-S shorts test results (source) test shorts
Note that several groups of prefixes exist. For example,

records beginning with @A- are generated by analog test
statements, records beginning with @D- are generated by
digital test statements, and so on. If you are generating
custom log records, you may want to create your own
prefix groups.
NOTE
To keep log records to a manageable size, avoid
making custom prefixes excessively long.

Hierarchy of Log This section shows how groups of log records are statement). The results of the resistor test appear in an
arranged to form log data files. To keep the examples record (which is preceded by an @BLOCK record
Records simple, each record is represented by its prefix and not
@A-RES
to identify the beginning of a block of tests), like this:
by the actual data it contains. The internal structure of @BATCH
each log record is explained later in Interpreting the @BTEST
Log Records on page 6-10. @BLOCK
@A-RES
Log records are arranged in a hierarchy of records and
subrecords, where a subrecord is simply an additional Thus, the @A-RES record appears as a subrecord of an
record which further describes whatever precedes it. For @BLOCK record, which is a subrecord of an @BTEST
example, a group of log records (presumably a log data record, which is a subrecord of an @BATCH record.
file) might begin with an @BATCH record containing To make the structure of records and subrecords more
information to identify a batch of boards that were obvious, we will begin indenting the examples, like this:
tested:
@BATCH
@BATCH @BTEST
And the @BATCH record might be followed by an @BTEST @BLOCK
@A-RES
record to identify the testing of an individual board:
@BATCH
This way of presenting examples clearly shows the
@BTEST hierarchy of records and subrecords. Note that these
indents are for illustration purposes only; they do not
Because the @BTEST record further describes the @BATCH appear within actual log data files.
record by identifying a unique board within the batch, it
is a subrecord of—i.e., subordinate to—the @BATCH Suppose we test two more boards, each with one resistor
record. The @BATCH record by itself is incomplete; it test. The log data file now looks like this:
becomes complete only when followed by an @BTEST @BATCH
record. @BTEST
@BLOCK
Suppose the board described in the @BTEST subrecord @A-RES
had a resistor test performed on it (by a resistor @BTEST

@BLOCK
@A-RES
@BTEST
@BLOCK
@A-RES
Completing the current batch of boards and beginning a

new one gives us:
@BATCH
@BTEST
@BLOCK
@A-RES
@BTEST
@BLOCK
@A-RES
@BTEST
@BLOCK
@A-RES
@BATCH
@BTEST
@BLOCK
@A-RES
In a similar fashion, other records and subrecords can be

assembled into files of log data describing how boards
were tested.

NOTE
Interpreting the Log Up until now, all of the examples have shown only the Look in the descriptions of the individual log
record prefixes, and not the test data each record records for the names of the fields associated with
Records contains. This section describes the format of data as it each log record.
appears within log records and then expands upon the
preceding section by showing how actual log records
are grouped into log data files. If we replace the names of the fields with typical data,
an @A-CAP record might look like this:
NOTE {@A-CAP|1|1.246700E+01|C1}
Although the following examples illustrate the If a field is optional, the separator character must still
structure of actual log records, the samples shown appear as a place holder. For example, if the @A-CAP
are not necessarily complete. Refer to the record above had no value assigned to the measured
descriptions of the individual log records for value field, it would look like this:
complete details. {@A-CAP|1||C1}
Notice that the vertical bars still reserve a space between

Each log record is enclosed in braces. The record begins the contents of the test status and subtest
with { immediately followed by the prefix, and ends designator fields for the empty measured value field.
with }. For example, the @A-CAP record, which
describes a capacitor test, looks like this when
simplified:
{@A-CAP. . . data fields . . .}
The prefix is followed by one or more variable length

data fields containing descriptive information. A
vertical bar, |, is used as a separator between fields.
Adding the names of the fields to the example above
gives us:
{@A-CAP|test status|measured value|subtest
designator}

Each field must contain a certain type of information.

The log record descriptions denote these beneath TYPE
as shown in Table 6-2.
Table 6-2 Log record types
Type Description
bool a boolean, which can have either a true value (1 or Y) or a false value (0 or N)
fp floating point number, which is an integer optionally followed by a decimal point and any number of consecutive
digits, all optionally followed by the letter E (upper- or lowercase) and an integer
int integer number, which is an optional sign character (+ or -) followed by one or more consecutive digits
str string value, which is any number of characters of any type (unless otherwise noted)
If left empty, most fields default to some predefined {@NODE\node list|item 1|item 2| . . etc.}
value. The log record descriptions denote these beneath Substituting values in place of the field names gives us:
DEFAULT as:
{@NODE\2|Node53|+5Volts}
■ 0, 1, etc. a default numeric value
The first entry in a list tells how many items appear in
■ "" a null string the list. Thus, the 2 following the \ indicates there are
Fields for which a default value would be two items in the list: Node53 and +5Volts.
meaningless—that is, fields in which a reported value is Some log records are followed by one or more
mandatory—have a question mark (?) beneath DEFAULT. subrecords containing additional information. For
Some log records contain a data list. In this case, the example, the @PF record can be followed by an @PIN
initial separator character (to indicate that a list follows) record which contains a list of pins:
is a backslash, \, and individual items within the list are {@PF|2
separated by a vertical bar. For example, the @NODE log {@PIN\2|11434|22216}
record contains a list of node identifiers: }

In other words, the @PF record is further described by }

the @PIN record that follows it. {@TS-O|Node43|Node14|-1.500000E+00}
{@TS-S|0|1|Node38
Notice the hierarchy of braces—i.e., the @PIN record has {@TS-P|-1.243853E+02}
its own pair of beginning and ending braces ({ and }) }
within the @PF record's overall pair of braces. Also }
notice that the closing brace for the @PF record was In this case an overall @TS log record contains three
dropped onto a new line, and the @PIN record was subrecords, one each to report shorts, opens, and
indented, to make the structure of the overall record phantoms associated with the shorts test reported by the
more obvious. Indents and new lines are shown here for entire @TS log record. Two of the @TS record's
illustration purposes only; they do not necessarily subrecords contain subrecords which further describe
appear within actual log data files. them. Notice the pairing of braces; for each opening
If you examine actual log data produced by an Agilent brace, there is a closing brace.
3070 system, you will see that in some cases subrecords So far we have mentioned four special characters which
appear on the same line as the records with which they can appear in log records: {, }, |, and \. But suppose
are associated, and in other cases they do not. The that one or more of these characters must appear within
important thing to keep in mind is that log records must a data field and not be interpreted as data field
appear in the correct order and that they must be delimiters. Another special character, the tilde (~), is
accurately defined by braces. used to identify a data field that should be interpreted
Without the indents and new lines, the actual log record literally—i.e., a literal field. Unlike a normal field,
looks like this: which is variable length, this literal field must have its
length precisely defined. For example:
{@PF|2{@PIN\2|11434|22216}}
~12|!$%(test)|!|
This same hierarchy of braces and indents also applies
to more complex, nested groups of log records. The actual data in this field is !$%(test)|!|. The ~
Consider the following example: identifies the field as a special case, the 12 denotes the
field's length as twelve characters, and the |
{@TS|1|2|1|1| immediately following the 12 delimits the length
{@TS-S|2|0|Node12
specification from the data.
{@TS-D|Node25|1.678850E+00}
{@TS-D|Node26|2.543211E+00}

If this field appeared in a log record, it might look like

this: NOTE
{@RPT~12|!$%(test)|!|} The exception to this is that the truncation
character can appear in a literal field denoted with
Notice that the ~ at the beginning of the literal field a tilde (~); this does not indicate a truncated
replaces the usual | delimiter; do not use both record.
delimiters.
If you generate custom log records containing the line The data preceding the truncation character is
feed character, an ASCII 10 (CTRL-J), you must put the considered to be valid, and any subsequent log records
line feed character in a literal field; if you do not, it will will be considered normal provided they do not contain
be misinterpreted as an optional delimiter between a the truncation character.
record and a subrecord.
If you need to manipulate log records with BT-BASIC, A Note About Process Steps
you should use free-field formatting to input a record's
individual fields into variables. In addition to type and serial number, boards can be
identified by a process step. The process step is simply
at which step in the manufacturing process—for
NOTE example, in-circuit or functional—the board is being
Note that this is different from how 3065 log tested. The @BATCH log record contains a process step
records are handled in an imaged format. data field in which you can place a brief code to identify
at which step in the test process a board was tested.
A Note About Truncated Records Note that Pushbutton Q-STATS does not make use of
process steps. However, if you are generating custom
If you are using custom datalogging routines, be aware log records and ever expect to use the optional
that the presence of a truncation character, an ASCII 4 Q-STATS II quality management software (which does
(CTRL-D), in the data will be interpreted to mean that use process steps), you may want to begin acquiring
the log data was unexpectedly interrupted and that the process step information now.
current log record has ended.

A Note About User-Defined Log Records

The log and log using statements allow you to create
user-defined log records in free-field and imaged
formats, respectively. User-defined log records can
emulate existing log records, or they can be created
from scratch for custom applications (which require
custom routines to process the non-standard log
records).

Table 6-3 Special characters (continued)

How Log Records The next two topics summarize how log records are Character Description
formatted. These topics are useful if you are creating
are Formatted your own custom log records. ASCII 4 Identifies a truncated (incomplete) log record
(CTRL-D)
Special Characters ASCII 10 Line feed character (new line). Denotes the
The characters shown in Table 6-3 that have special (CTRL-J) end of the data fields for the current record,
significance—that is, they are interpreted to mean and should only be followed by an end of
something other than their normal ASCII value—when record character (}) or beginning of a new
they appear in a log record. record or subrecord ({).
Table 6-3 Special characters
Character Description
If you use custom log records or custom datalogging
{ Begins a log record routines, be sure that none of these characters appear in
normal data unless they are within a literal field.
} Ends a log record
| Begins a normal data field Rules of Formatting
~ Begins a literal field The following list contains the formatting rules used to
build log records (or subrecords).
\ Begins a list of fields
■ Each log record begins with { followed by a series
of printable characters that uniquely identify the
log record type. The convention for log record
types supplied by Agilent is that they begin with
@. No other log records should begin with this
character.

■ The record type is followed by one or more data • The characters which are to be interpreted
fields. literally
■ Each data field begins with one of the following ■ Each log record ends with }
characters:
■ Some record types can contain nested subrecords.
| — Begins a normal data field, which must not A record becomes a subrecord when it occurs
contain special characters unless they appear after the preceding record's data fields but before
within a literal field. A normal data field is ended the final } for the preceding record.
by the appearance of the next special character. If
you are creating custom log records: Since a
special character ends a data field, every data field
should be followed by some special character to
terminate it.
\— Begins a data field that contains a list, which
must not contain any special characters unless
they appear within a literal field. This character is
followed by:
• A number showing how many items are in the
list
• The items (data) in the list. Each item is itself a
data field, and usually begins with |.
~ — Begins a literal field, which is the only way
to include special characters inside a log record
and not have them interpreted as special. This
character is followed by:
• A number showing how many characters are in
the field
• A single |

Descriptions of the Record @A-CAP: capacitor

Log Records This record describes a capacitor test. When limits are
being logged, it is followed by a subrecord containing
additional information.
Table 6-4 @A-CAP
Format: {@A-CAP|test status|measured value|subtest designator}

Field Type Default Comments
test status int 0 0 = passed
1 = failed
2 = failed (compliance limit)
3 = failed (detector timeout)
11 = aborted by operator
measured value fp 0 The actual value measured.
subtest str "" Comes from the optional designator parameter of the capacitor statement
designator
■ Generated by: capacitor statement Example 6-1

■ Subrecords: @LIM3 is generated when logging {@A-CAP|1|1.246700E+01}
limits information. Contains nominal value and
high/low limits for test.
■ Corresponds to: 12 record on a 3065 system.

Record @A-DIO: diode

This record describes a diode test. When limits are being
logged, it is followed by a subrecord containing
Table 6-5 @A-DIO
Format: {@A-DIO|test status|measured value|subtest designator}

1 = failed
subtest designator str "" Comes from the optional designator parameter of the diode statement.
■ Generated by: diode statement Example 6-2

■ Subrecords: @LIM2 is generated when logging {@A-DIO|1|1.246700E+01}
limits information. Contains high/low limits for
test.

Record @A-FUS: fuse

This record describes a fuse test. When limits are being
logged, it is followed by a subrecord containing
Table 6-6 @A-FUS
Format: {@A-FUS|test status|measured value|subtest designator}

1 = failed
subtest designator str "" Comes from the optional designator parameter of the fuse statement.
■ Subrecords: @LIM2 is generated when logging

test.
Example 6-3
{@A-FUS|1|1.246700E+01}

Record @A-IND: inductor

This record describes an inductor test. When limits are
Table 6-7 @A-IND
Format: {@A-IND|test status|measured value|subtest designator}

1 = failed
subtest designator str "" Comes from the optional designator parameter of the inductor
statement.
■ Generated by: inductor statement Example 6-4

■ Subrecords: @LIM3 is generated when logging {@A-IND|1|1.246700E+01}

Record @A-JUM: jumper

This record describes a jumper test. When limits are
Table 6-8 @A-JUM
Format: {@A-JUM|test status|measured value|subtest designator}

1 = failed
subtest designator str "" Comes from the optional designator parameter of the jumper statement.
■ Generated by: jumper statement

test.
Example 6-5
{@A-JUM|1|1.246700E+01}

Record @A-MEA: measure

This record describes a measurement. When limits are
Table 6-9 @A-MEA
Format: {@A-MEA|test status|measured value|subtest designator}

1 = failed
subtest designator str "" Comes from the name of the subtest block in which the measurement
occurred.
■ Generated by: measure statement Example 6-6

■ Subrecords: @LIM2 is generated when logging {@A-MEA|1|1.246700E+01}
test.

Record @A-NFE: nfetr

This record describes an N-channel FET test. When
limits are being logged, it is followed by a subrecord
containing additional information.
Table 6-10 @A-NFE
Format: {@A-NFE|test status|measured value|subtest designator}

1 = failed
subtest designator str "" Comes from the optional designator parameter of the nfetr statement.
■ Generated by: nfetr statement Example 6-7

■ Subrecords: @LIM2 is generated when logging {@A-NFE|1|1.246700E+01}
test.

Record @A-NPN: npn

This record describes an NPN transistor test. When
limits are being logged, it is followed by a subrecord
Table 6-11 @A-NPN
Format: {@A-NPN|test status|measured value|subtest designator}

1 = failed
subtest designator str "" Comes from the optional designator parameter of the npn statement.
■ Generated by: npn statement Example 6-8

■ Subrecords: @LIM2 is generated when logging {@A-NPN|1|1.246700E+01}
test.

Record @A-PFE: pfetr

This record describes a P-channel FET test. When limits
are being logged, it is followed by a subrecord
Table 6-12 @A-PFE
Format: {@A-PFE|test status|measured value|subtest designator}

1 = failed
subtest designator str "" Comes from the optional designator parameter of the pfetr statement.
■ Generated by: pfetr statement Example 6-9

■ Subrecords: @LIM2 is generated when logging {@A-PFE|1|1.246700E+01}
test.

Record @A-PNP: pnp

This record describes a PNP transistor test. When limits
Table 6-13 @A-PNP
Format: {@A-PNP|test status|measured value|subtest designator}

1 = failed
subtest designator str "" Comes from the optional designator parameter of the pnp statement.
■ Generated by: pnp statement Example 6-10

■ Subrecords: @LIM2 is generated when logging {@A-PNP|1|1.246700E+01}
test.

Record @A-POT: potentiometer

This record describes a potentiometer test. When limits
Table 6-14 @A-POT
Format: {@A-POT|test status|measured value|subtest designator}

1 = failed
subtest designator str "" Comes from the optional designator parameter of the potentiometer
statement.
■ Generated by: potentiometer statement Example 6-11

■ Subrecords: @LIM3 is generated when logging {@A-POT|1|1.246700E+01}

Record @A-RES: resistor

This record describes a resistor test. When limits are
Table 6-15 @A-RES
Format: {@A-RES|test status|measured value|subtest designator}

1 = failed
subtest designator str "" Comes from the optional designator parameter of the resistor
statement.
■ Generated by: resistor statement Example 6-12

■ Subrecords: @LIM3 is generated when logging {@A-RES|1|1.246700E+01}

Record @A-SWI: switch

This record describes a switch test. When limits are
Table 6-16 @A-SWI
Format: {@A-SWI|test status|measured value|subtest designator}

1 = failed
subtest designator str "" Comes from the optional designator parameter of the switch statement.
■ Generated by: switch statement

test.
Example 6-13
{@A-SWI|1|1.246700E+01}

Record @A-ZEN: zener

This record describes a Zener diode test. When limits
Table 6-17 @A-ZEN
Format: {@A-ZEN|test status|measured value|subtest designator}

1 = failed
subtest designator str "" Comes from the optional designator parameter of the zener statement.
■ Generated by: zener statement Example 6-14

■ Subrecords: @LIM3 is generated when logging {@A-ZEN|1|1.246700E+01}

Record @AID: identify board causing real-time

alarm
This record appears as a subrecord of the @ALM record; it
identifies the board that caused the real-time alarm
described in the @ALM record.
Table 6-18 @AID
Format: {@AID|time detected|serial number}

datetime detected str "" Date and time of alarm in YYMMDDHHMMSS format (datetime$).
subtest designator str "" The unique serial number of the board that caused the real-time alarm.
■ Generated by: alarm program

■ Corresponds to: A2 record on a 3065 system that
has PR PLUS installed.
Example 6-15
{@AID|890615094418|12306743}

Record @ALM: identify real-time alarm

This record describes a specific real-time alarm. It is
followed by an @AID subrecord that identifies which
board caused the real-time alarm.
Table 6-19 @ALM
Format: {@ALM|alarm type|alarm status|time detected|board type|board type rev|alarm limit|detected

value|controller|testhead number}
alarm type int 1 1 = consecutive failure; 2 = sample yield; 3 = overall yield
alarm status bool 0 0 = off, 1 = on
datetime detected str "" Date and time of alarm in YYMMDDHHMMSS format (datetime$).
board type str "" The board type associated with the alarm.
board type rev str "" The revision of the board type associated with the alarm.
alarm limit int ? The alarm limit (threshold) that was exceeded.
detected value int ? The detected value that exceeded the alarm limit.
controller str "" Which controller the alarm occurred on.
testhead number int 1 (th$) a positive integer.
■ Generated by: alarm program ■ Subrecords: @AID Logged for any real-time alarm
that is detected; identifies the board that caused
the real-time alarm.

■ Corresponds to: A1 record on an 3065 system that

has PR PLUS installed.
Example 6-16
{@ALM|1|1|890516145512|proc_bd|2|10|15|alpha|1}
Record @ARRAY: digitizer results analysis

This record describes the results of a measure statement
for the digitizer or the results of an array-format report
analog statement.
Table 6-20 @ARRAY
Format: {@ARRAY|subtest designator|status|failure count|samples}

subtest designator str "" Comes from the digitizer or from the optional designator parameter of the
report analog statement.
status int 0 0 = pass

1 = fail
7 = error occurred
failure count int 0 The number of failures.
samples int 1024 The number of samples tested.

■ Generated by: digitizer, report analog Record @BATCH: identify a batch of boards
statement
This record identifies a unique batch of boards; i.e., a
Example 6-17 number of boards which are treated as a group for test
purposes.
{@ARRAY|""|1|5|1024}
Table 6-21 @BATCH
Format: {@BATCH|UUT type|UUT type rev|fixture id|testhead number|testhead type|process step|batch id|operator
id|controller|testplan id|testplan rev|parent panel type|parent panel type rev}
UUT type str "" The type of unit under test, not including the revision. This can be a board
type or a panel type.
UUT type rev str "" The board type revision or panel type revision.
fixture id int 0 The decimal autofile code.
testhead number int 1 (th$) a positive integer.
testhead type str "" Which type of testhead. (This is currently not used.)
process step str "" Which step in the manufacturing process.
batch id str "" ID of current batch of boards.
operator id str "" Which operator.
controller str "" Which controller.
testplan id str "" Name of testplan.

Table 6-21 @BATCH (continued)
Format: {@BATCH|UUT type|UUT type rev|fixture id|testhead number|testhead type|process step|batch id|operator
id|controller|testplan id|testplan rev|parent panel type|parent panel type rev}
testplan rev str "" Revision of testplan.
parent panel type str "" Type of the panel that contains this board.
parent panel type rev str "" Revision of the type of panel that contains this board.
version label str "" Multiple Board version.
■ Generated by: log board statement record which in turn has only one @BTEST
subrecord.
■ Subrecords:
• other The log and log using statements can
• @BTEST Generated for each board within a
be used to generate other subrecords.
batch. When one log data file is generated per
board tested, the file has only one @BATCH ■ Corresponds to: 01 and 04 records on an 3065
system.
Example 6-18
{@BATCH|998457-146|0|2550|1||btest|891131172938|pete|achilles|MaxWellBT|7|A_panel|2}

Record @BLOCK: identify a test block .

This record identifies a named block of analog, digital, Table 6-23 BLOCK subrecords
serial, or mixed test statements.
Subrecord Generated by
Table 6-22 @BLOCK
@A-CAP capacitor statement
Format: {@BLOCK|block designator|block status}
@A-DIO diode statement
@A-FUS fuse statement
block str "" Name of this test
@A-IND inductor statement
designator block.
@A-JUM jumper statement
block int 0 0 = all statements
status passed. If a statement @A-MEA measure statement
failed, the status of
@A-NFE nfetr statement
the failing test is
shown. @A-NPN npn statement
@A-PFE pfetr statement

■ Generated by: test, test analog statements @A-PNP pnp statement
■ Subrecords: Subrecords are shown in Table 6-23. @A-POT potentiometer statement
Example 6-19 @A-RES resistor statement
{@BLOCK|R12|1 @A-SWI Generated by switch statement

{@A-RES||1|1.006789E+01}
@A-ZEN zener statement
}
@D-T test statement

Table 6-23 BLOCK subrecords (continued) ■ Generated by: Boundary-Scan Software
Subrecord Generated by ■ Subrecords:
@S-PROC test statement • @BS-O is generated when opens count is

greater than zero and the log level is not set to
@TJET test statement without pins.
• @BS-S is generated when shorts count is

greater than zero and the log level is not set to
without pins.
Table 6-24 @BS-CON
Example 6-20
Format: {@BS-CON|test designator|status|shorts
count|opens count} {@BS-CON|9c_connect|1|0|2
{@BS-O|9C|43}
Field Type Default Comments {@BS-O|9C|41|9C|58}
}
test str "" Designator for a
{@BS-CON|27c_connect|1|0|1
designator boundary-scan connect {@BS-S|S{@NODE\2|179|112}}
or interconnect test. }
status int 0 0 = pass

1 = fail
7 = chain failure
shorts int 0 How many shorts
count occurred during the
boundary-scan test.
opens int 0 How many opens
count occurred during the
boundary-scan test.

Record @BS-O: list of open pins

This subrecord follows a @BS-CON log record and further
describes that record by listing open pins that were
found during a failing boundary-scan test.
Table 6-25 @BS-O
Format: {@BS-O|first device|first pin|second device|second pin}

first device name str "" Name of the first device.
first device pin int 1 Number of open pin on the first device.
second device str "" (optional) Name of the second device.
name
second device pin int 1 (optional) Number of open pin on the second device.
■ Generated by: Boundary-Scan Software
Example 6-21
{@BS-O|9C|43}
{@BS-O|9C|41|9C|58}

Record @BS-S: list of shorted pins

This subrecord follows an @BS-CON log record and
further describes that record by listing a shorted pin that
was found during a failing boundary-scan test.
Table 6-26 @BS-S
Format: {@BS-S|cause|node list}

cause str S S = known short
U = unknown short
0 = stuck at 0
1 = stuck at
node list str "" A list of indicted nodes.
■ Generated by: Boundary-Scan Software
Example 6-22
{@BS-S|S{@NODE\2|179|112}}

Record @BTEST: describe a board test

This record describes the overall testing of a single
board. It is followed by subrecords which report the
results of individual tests performed on the board.
Table 6-27 @BTEST
Format: {@BTEST|board id|test status|start datetime|duration|multiple test|log level|log set|learning|known good|end

datetime|status qualifier|board number|parent panel id}
board id str "" Serial number of this board.
1 = uncategorized failure
2 = failed pin test
3 = failed in learn mode
4 = failed shorts test
5 = (reserved)
6 = failed analog test
7 = failed power supply test
8 = failed digital or boundary scan test
9 = failed functional test
10 = failed pre-shorts test
11 = failed in board handler

Table 6-27 @BTEST (continued)

12 = failed barcode
13 = X’d out (board on panel not tested or missing) : maintained, but not logged.
14 = failed in TestJet
15 = failed in polarity check
16 = failed in ConnectCheck
17 = failed in analog cluster test
18-79 = reserved
80 = runtime error
81 = aborted (STOP)
82 = aborted (BREAK)
83-89 = reserved
90-99 = user-definable
start datetime int 0 Start of board test in YYMMDDHHMMSS format (datetime$).
duration int 0 Test duration in seconds.
multiple test bool 0 Is this the same as the previous board? 0 = NO, 1 = YES
log level str "" Current value of lli$.
log set int 0 Current default logging set. (This is not currently used.)

Table 6-27 @BTEST (continued)

learning bool 0 Is learning on? N = NO, Y = YES
known good bool 0 Is this a known good board? N = NO, Y = YES
end datetime int 0 End of board test in YYMMDDHHMMSS format (datetime$).
status qualifier str "" Comment string from log board end.
board number int 1 The number of the board being tested, as determined by a board number is
statement. When not using multiple log buffers (board number is *), this value is
reported as 1 even though it is actually zero.
parent panel id str "" Value derived from the optional <ParentPanelId> parameter of a log board
start statement.
■ Generated by:
NOTE
• log board start statement begins this
The test status constants (above) are defined in the
record.
test plan, and are used by statistical analysis and
quality control programs such as PushButton • log board end statement ends this record.
QStats and other packages. These tools respond ■ Corresponds to: 02 and 03 records on a 3065
primarily to the category of PASS/FAIL/BOGUS, system.
though they do sometimes recognize that the
value 2 is special. Pins test failure can be a bad Pushbutton Q-STATS and Q-STATS II interpret a
board, or a problem with the fixture. test status of 1 through 10 as a failing board, while

values 11 through 99 are considered bogus; i.e.,

they are neither passing nor failing.
Example 6-23
{@BTEST|99538-135|8|891131172855|43|0|failures||n|n|891131172938|4|99538-130
. . .
{test results subrecords}
. . .
}
Subrecords:
Table 6-28 BTEST subrecords
@BLOCK test and test analog statements
@BS-CON Boundary-Scan connect and interconnect tests

@D-LOG log digital statement
@D-T test statement
@PF pinsfailed function
@PRB probe or probe failures statements
@RETEST log clear for retest statement
@RPT any of the report statements; i.e., report (ANALOG), report (BT-BASIC), or report
(SHORTS)

Table 6-28 BTEST subrecords (continued)
@TS test shorts statement
other The log and log using statements can be used to generate other subrecords
Record @CCHK: Connect Check Test

This record that describes the results of Connect Check
tests.
Table 6-29 @CCHK
Format: {@CCHK|test status|pin count|test designator}

test status int 00 00 = pass
01 = fail
07 = fatal error
pin count int 0000 number of failing pins
device designator str ""
■ Generated by: test statement Example 6-24

■ Subrecords: @DPIN is generated when logging pins {@CCHK|01|0008|u34}
to list the failing device pins.

Record @DPIN: list of device pins for a single

device
This record contains a list of device pins for a single
device.
Table 6-30 @DPIN
Format: {@DPIN|device name|node pin list} or {@DPIN|device name|node pin list|thru devnode list} with DriveThru
device str "" Name of device, or test designator when device name is not available.
name
node pin str or ""/0 List of items. Items alternate to give two separate items of information about each pin.
list int The odd items are the node id strings. Following them (even items) are the optional
device pin strings to indicate which pins of this device are connected to the node
id's. Device pins should be included whenever possible. The number of list items
will always be even—i.e., twice the number of device pins.
thru str or "" This field is a list of DriveThru devices and nodes, ordered in pairs. Two items alternate
devnode list int information about each driven through device and node. The odd items are the node id
strings. Following them (even items) are the device id strings to indicate which device
is connected to the node id's. The number of list items will always be even—i.e., twice
the number of nodes driven through.

■ Generated by:
• test statement
Tests for digital devices produce an @DPIN
record as a subrecord for @D-T (digital powered
test) and for @TJET (TestJet test) whenever pins
are being logged.
• probe statement, probe failures statement
These statements may produce @DPIN records,
but as subrecords of the @PRB record when
logging pins.
Example 6-25
{@DPIN|U12\4|Node17|8|GND|3}
!No DriveThru Node{@DPIN|U6809\6|TCLK|18|U6809-12|12|BDRV|18}
!With DriveThru Node
Record @D-PLD: results of PLD programming -- and the outcome of the action performed. Each block
success or failure record also contains a digital sub-record describing the
outcome of the digital test portion of the test. Each
Data logging for PLD ISP is supported and controlled D-PLD record may contain NOTE and EXPRT
similarly to that of other test data types. Log record sub-records.
control is enabled via the BT-BASIC logging functions,
A record is produced for a successful run with log
such as “log is”, “log out”, and “log failure”.
level all or a failing execution with log level is
Log records produced for a PLD ISP test type are failures. Otherwise no log is produced with the
grouped into a digital test block record (@BLOCK). possible exception of using the log devices
Every play statement in the digital test generates a mechanism.
sub-record within the block that describes information

Table 6-31 @D-PLD
Format: {@D-PLD|<Filename> | <Action> | <Action return code> | <Result message string> | <Player program
counter> | }
Filename str ““ Identifies the name of the compiled program file used by the test.
Action str ““ Identifies the STAPL source action taken by the play statement. SVF and Jam files use
a default name because procedural actions are not supported in these file types.
Action int 0 Specifies the return code as a result of running the action. A zero (or empty parameter)
return code designates a passing condition.
Result str ““ Describes the error condition code.
message
string
Player int 0 Indicates the JBC opcode index where the failure occurred.
program
counter
D-PLD may have one or more @EXPRT subrecords, a

shown in Table 6-32. These are Generated by the use of
STAPL export commands in the programming file.

Table 6-32 @EXPRT
Format: {@EXPRT | <Key> | <Field> }

Key str ““ Value that identifies the name of the variable exported.
Field int 0 Represents the value of the variable when exported.
D-PLD may also have one or more @NOTE subrecords use of note header commands within the STAPL source
as shown in Table 6-33. This record is generated by the file.
Table 6-33 @NOTE
Format: {@NOTE | <Note name> | <Note string> }

Note name str ““ Identifies a keyword name for the note field returned.
Note string str ““ Represents the contents of the note field returned.
■ Generated by: play statement

■ Subrecords: @EXPRT and @NOTE

Example 6-26
The following example shows a record produced from a STAPL read ID code test program:
{@BLOCK|d3_18v04|00
{@D-PLD|digital/idtest.jam.jbc|read_idcode||||
{@EXPRT|Expected is: |1BBBB44444444445555555AAAA4321}
{@EXPRT|Got >> nd : |01BBB44444444445555555AAAA4321}
{@NOTE|CREATOR|Altera Chain Interrogation Version 2.02--Debug pipe mode}
{@NOTE|DATE|2001/04/30}
{@NOTE|ALG_VERSION|1}
{@NOTE|STAPL_VERSION|JESD71}
{@NOTE|MAX_FREQ|10000000}
}
{@D-T|0|384||0|d3_18v04}
}

Record @D-T: test digital

This record describes the results of a digital test. When
pin logging is in effect, it is followed by a subrecord
Table 6-34 @D-T
Format: {@D-T|test status|test substatus|failing vector number|pin count|test designator}

1 = failed (see test substatus for reason)
5 =CRC related failure
7 = fatal error (test did not complete)
test substatus int 0 Decimal equivalent of a 6-bit binary value; a bit is set to 1 if the event occurred;
to 0 if it did not occur. The bit meanings (lsb to msb) are:
• bit 0 fail
• bit 1 SAFEGUARD timeout
• bit 2 hardware error
• bit 3 pause
• bit 4 halt
• bit 5 overvoltage
failing vector int 0 Which vector failed.
number

Table 6-34 @D-T (continued)
Format: {@D-T|test status|test substatus|failing vector number|pin count|test designator}

pin count int 0 How many pins failed.
test designator str "" Designator (name) of test.
■ Generated by: test statement log level is statement is set to indictments (or
some higher level). When these conditions are met, the
■ Subrecords: @DPIN is generated when logging pins
@GRP record groups the indict (@INDICT) records to
to list the failing device pins.
show those that are believed to be faulty.
As shown in the example below, the group record is
nested as a subrecord of MAGICCLUSTER (@M-CL) records
Example 6-27
and other group (@GRP) records. Indict (@INDICT)
{@D-T|1|1|39|3|U18}
NOTE
Flash ISP tests are logged like a normal digital
test.
Record @GRP: group record

This record is used with MagicTest to indicate the
grouping and relationship of the subrecords of a
particular log record. This record is generated only
when the MagicTest cluster test fails, and only when the

records can also be nested as a subrecord of group {@INDICT|MT\1|R3}

records. {@INDICT|MT\1|C4}
}
Table 6-35 @GRP }
{@GRP|AND
Format: {@GRP|relationship} {@INDICT|MT|0.333\1|R4|4.234291E+01|||R}
{@GRP|OR
Field Type Default Comments {@INDICT|MT|0.167\1|C2}
{@INDICT|MT|0.167\1|R5}
relationship str "" Describes how }
subrecords are related, }
{@GRP|AND
or what causes them to {@INDICT|MT|0.333\1|R6}
be grouped: {@GRP|OR
• AND indicates all of {@INDICT|MT\1|R3}
{@INDICT|MT\1|C4}
the subrecords }
• OR indicates one or }
}
more of the
}
subrecords.
Record @INDICT: indict record

■ Generated by: test statement
This record is used with DriveThru and MagicTest. This
Example 6-28 record contains a list of devices indicted by the
respective test as either a potential failure or a known
{@M-CL|1|cluster_C4 failure, and is generated when the log level is
{@GRP|OR statement is set to indictments (or some higher level).
{@GRP|AND When using DriveThru, this record is nested as a
{@GRP|OR
{@INDICT|MT\1|R1}
{@INDICT|MT\1|R2}
}
{@GRP|OR

subrecord of CPROBE (@TJET). When using MagicTest,

this record is nested as a subrecord of a MAGICCLUSTER
(@M-CL) or a GROUP (@GRP) record.
Table 6-36 @INDICT
Format: {@INDICT|technique\device list|est resistance|est capacitance|est induct|est model}

technique str "" Always either DT to indicate DriveThru or MT to indicate MagicTest.
device list str The device list shows the reference designators for the indicted devices. When using
MagicTest, the record contains one device name. When using DriveThru, the record
can contain multiple device names (separated by a colon). For more information see
the examples below, and refer to Interpreting the Log Records on page 6-10.
est resistance fp (optional) This is sometimes present for MagicTest to show the estimated resistance.
Not used for DriveThru.
est fp (optional) This is sometimes present for MagicTest to show the estimated
capacitance capacitance. Not used for DriveThru.
est inductance fp (optional) This is sometimes present for MagicTest to show the estimated
inductance. Not used for DriveThru.
est model str "" (optional) String identifying the model used for deriving the estimates (if any) for
MagicTest. The letters in the main portion of the string indicate that a particular
parameter has been estimated: R, L, or C. If there is more than one such letter, then
there will also be a suffix of either -S for in series or -P for in parallel.
Expected values are R, L, C, RC-P, RC-S, RL-P, and RL-S. L and C are not
combined.

Example 6-29
MagicTest examples:
{@INDICT|MT\1|r40809|+5.179527E+03|||R}
{@INDICT|MT\1|c40233|+6.937080E+03|+8.442845E-10||RC-P}
{@INDICT|MT\1|R40554|+5.653664E+05||+1.074852E+01||RL-P}
{@INDICT|MT\1|c40812}
DriveThru examples:
{@INDICT|DT\1|r12}
{@INDICT|DT\3|rp6:r2|c412|r22}
Record @LIM2: high & low limits of analog test

This record contains the high and low limits for an
analog test. When limits are being logged, it is followed
by a subrecord containing additional information.
Table 6-37 @LIM2
Format: {@LIM2|high limit|low limit}

high limit fp 0 Upper limit for allowable range.
low limit fp 0 Lower limit for allowable range.
■ Generated by: • diode statement

• fuse statement Example 6-30

• jumper statement
• measure statement {@LIM2|8.666667E+01|2.000000E+00}
• nfetr statement
• npn statement Record @LIM3: nominal high/low
• pfetr statement
This record is logged by statements which optionally
• pnp statement
log a component's nominal value and its high and low
• switch statement value limits. The limits are calculated from the nominal
■ Corresponds to: 08 record on a 3065 system. value, the plus and minus tolerance limits, and any
margin in effect from a tolerance margin statement.
The record is not generated if the log level was specified
as without nhls.
Table 6-38 @LIM3
Format: {@LIM3|nominal value|high limit|minus tolerance}

nominal value fp 0 The nominal value.
high limit fp 0 Upper limit: The sum of the nominal value plus the allowed positive deviation
from the nominal value.
low limit fp 0 Lower limit: The sum of the nominal value plus the allowed negative deviation
from the nominal value.
■ Generated by: • potentiometer statement

• resistor statement
• capacitor statement
• zener statement
• inductor statement

■ Corresponds to: 07 record on a 3065 system. ■ Generated by: test statement
Example 6-31 Example 6-32
{@LIM3|22|1.500000E+00|2.000000E+00} {@M-CL|1|cluster_C4
{@GRP|OR
{@GRP|AND
Record @M-CL: MAGICCLUSTER record {@GRP|OR
{@INDICT|MT\1|R1}
This record is used with MagicTest to return the status {@INDICT|MT\1|R2}
of a cluster test. This record is generated when the }
MagicTest cluster test fails, and when the log level {@GRP|OR
is statement is set to failures (or some higher level). {@INDICT|MT\1|R3}
This record is nested within the @BTEST record and {@INDICT|MT\1|C4}
}
indicates the pass/fail status of an analog cluster test.
}
MAGICCLUSTER records sometimes contain the following {@GRP|AND
subrecords: GROUP (@GRP) records, INDICT (@INDICT) {@INDICT|MT|0.333\1|R4|4.234291E+01|||R}
records, or no subrecords. {@GRP|OR
{@INDICT|MT|0.167\1|C2}
Table 6-39 @M-CL {@INDICT|MT|0.167\1|R5}
}
Format: {@M-CL|status|cluster_name} }
{@GRP|AND
Field Type Default Comments {@INDICT|MT|0.333\1|R6}
{@GRP|OR
status int 0 0 = passed {@INDICT|MT\1|R3}
1 = failed {@INDICT|MT\1|C4}
7 = indeterminate }
}
test due to
}
measurement error }
cluster_name str "" Name of this cluster.

Record @NETV: network verification record

This record is used to verify the integrity of the network
link to whichever system is specified.
Table 6-40 @NETV
Format: {@NETV|datetime|test system|repair system|source}

datetime str 0 Date and time of verification request in YYMMDDHHMMSS format
(datetime$).
test system str "" Identifier of test system.
repair system str "" Identifier of repair system.
source bool 0 This field contains 0 when generated by prsetup, and changes to a 1 when
the record is processed by alarm.
■ Generated by: prsetup program

Example 6-33
{@NETV|890530102019|alpha|beta|1}

Record @NODE: list of nodes

This record contains a list of nodes. It appears as a
subrecord to further describe whichever record precedes
it.
Table 6-41 @NODE
Format: {@NODE\node list}

node list str "" Each item in the list specifies a node by its node id.
■ Generated by:
• probe statement
• probe failures statement
Example 6-34
{@NODE\2|Node53|+5Volts}

Record @PCHK: Polarity Check Test

This record describes the results of a test made by an
Polarity Check test.
Table 6-42 @PCHK
Format: {@PCHK|test status|test designator}

test status int 00 00 passed
01 failed
07 fatal error (test did not complete)
test designator str ""
Example 6-35
{@PCHK|01|c34}

Record @PF: pinsfailed

This record contains the results of a test statement. It is
followed by a one or more subrecords containing a list
of pins.
Table 6-43 @PF
Format: {@PF|designator|test status|total pins}

designator str "" An optional designator that identifies the file containing the source code for the
pins test. This comes from the <file id> parameter in the test statement.
test status int 0 0 = testing passed
1 = testing failed
total pins int 0 Total number of failing pins.

■ Subrecords: @PIN: Contains a list of pins acquired
in test mode
Example 6-36
{@PF||1|4
{@PIN\4|10472|12235|21612|11302}
}

Record @PIN: list of pins

This record contains a list of pins. It appears as a
subrecord to further describe to whichever record
precedes it.
Table 6-44 @PIN
Format: {@PIN\pin list}

pin list str "" Each item in the list specifies a pin in BRRCC format.
■ Generated by: pinsfailed statement Record @PRB: (partial) results of probing

■ Corresponds to: 06 record on a 3065 system. (failures)
This record contains the results of the probe and probe
Example 6-37 failures statements. It can be followed by subrecords
{@PIN\5|11571|20314|12065|20508|11443}
containing a list of failing pins.
Table 6-45 @PRB
Format: {@PRB|test status|pin count|test designator}

test status int 0 0 = passed; 1 = failed
pin count int 0 How many pins failed.
test designator str "" The test designator (name of failing device).

■ Generated by:
NOTE
• probe statement
One probe record is generated for each device
• probe failures statement
tested.
■ Subrecords: @DPIN is generated when logging pins Each probe failures statement generates
to list failing device pins subrecords to report all of the failing nodes.
Example 6-38 Corresponds to: 51 record on a 3065 system.
{@PRB|1|2|U23
{@DPIN|\2|Node63||Node22|} Record @RETEST: indicate a log clear for retest
}
The presence of this record indicates that a log clear
for retest occurred. A log clear for retest
removes data which was logged and later found to be
bogus by a pinsfailed function being true.
Table 6-46 @RETEST
Format: {@RETEST|datetime}
datetime str "" Date and time of a log clear for retest in YYMMDDHHMMSS format
(datetime$).
■ Generated by: log clear for retest statement Record @RPT: messages logged by report
Example 6-39 This record contains the text string produced by
executing any of the report statements—i.e., report
{@RETEST|890819184413}

(ANALOG), report (BT-BASIC), or report

(SHORTS)—whenever the report level is log or all.
Table 6-47 @RPT
Format: {@RPT|message}
message str "" The string given in a report statement.
■ Generated by: report statements

The location at which this record is nested inside
@BLOCK records may vary; for example, an @RPT
record associated with a specific test may appear
nested inside the @BLOCK record associated with a
different test. This causes no problem for the
standard software packages that use log data, such
as Pushbutton Q-STATS.
Example 6-40
{@RPT|U91 failed}

Record @S-PROC: describe process in serial test

This record describes a process in a serial test. Each
process in the test generates its own log record that
contains information about that process.
Table 6-48 @S-PROC
Format: {@S-PROC|process|test status|fail location|process status|process substatus}

process str "" Identifier of the process. Or, when not using a debug object, a name having
the form MSSP, where:
• M module
• SS slot
• P process
test status int 0 The status of the test, where:
• 0 pass
• 1 fail
fail location int 0 Line number where the process failed. Or, when not using a debug object, this
is a negative value equal to the program counter when the failure occurred.
process status int 0 A number that indicates why the test failed. Possible values are:
• 4 Bit index must be between 0 and 23
• 5 Received frame comparison failed

Table 6-48 @S-PROC (continued)

• 6 Received more bits than expected
• 7 Received fewer bits than expected
• 8 Function "itf$" frame assignment overflow
• 9 Function "itf$" length value is invalid
• 10 Overflow in frame to integer conversion
• 11 Illegal use of null frame
• 12 Trigger state value is invalid
• 13 Cannot mod, div, or / by 0 error
• 14 Receive buffer overflow
• 15 Halted by another process
• 16 Recursive subroutine calls are not allowed
• 17 Function "berreceive" received a frame of incorrect length
• 18 Channel value is invalid
• 19 Cannot transmit fewer than two bits
• 20 User halted serial failing
• 21 User halted process
• 30 Running normally
• 31 Completed normally
• 32 Timeout waiting for digital trigger


• 33 Timeout waiting for receive frame sync
• 34 Timeout waiting for transmit frame sync
• 35 Timeout waiting for receive clock
• 40 Subframe start error
• 41 Subframe temp-variable start error
• 42 Subframe length error
• 43 Subframe temp-variable length error
• 44 Frame assignment overflow
• 45 Frame temp-variable assignment overflow
• 70 internal error: Reset interrupt
• 71 internal error: Stack error interrupt
• 72 internal error: Trace interrupt
• 73 internal error: SWI interrupt
• 74 internal error: III interrupt
• 75 internal error: Extra interrupt
• 76 internal error: SSIWEX interrupt
• 80 STC transmit data underrun
• 81 STC receive data overrun
• 82 STC receive frame overrun


• 83 Undefined stream, substream or filter error occurred
• 84 internal error: unexpected LCA interrupt occurred
• 411 Transmit data underrun
• 412 XDLC filter FCS error
• 413 Overcurrent detected on stream connected to this process
test substatus int 0 A set of bits whose bits, when set, indicate the following low-level conditions:
• bits 0 - 9 not used
• bit 10 PLL out-of-lock was detected on the Serial Test Card used by this
process
• bit 11 not used
• bit 12 overcurrent occurred on the stream attached to this process
• bit 13 overvoltage occurred on the stream attached to this process
• bit 14 too many digital triggers were received from the digital sequencer
• bit 15 not used

Example 6-41
NOTE
Example of output from failing mixed test func1. This The contents of two fields, process and fail
location, depend not only on the failure but also
test has three processes: RECEIVE, FILTER, and FBMON.
The first two processes are failing, while the last passes. on whether there is a debug object present for that
test. Alternating between having and not having a
{@BLOCK|func1|1 debug object will cause inconsistent naming
{@D-T|1|4161|41|0|func1} schemes to be used by statistical quality control
{@S-PROC|RECEIVE|1|82|3|19}
{@S-PROC|FILTER|1|996|12|3}
packages, such as Pushbutton Q-STATS. Thus,
{@S-PROC|FBMON|7|0} once a test is in production, it probably is best to
} always have the debug object present.
Example of output from passing mixed test func2. In Note to the System Administrator: You can
this test all processes are passing. control this by specifying yes or no for the
Mcomp.Debug variable in the .hp3070 file
{@BLOCK|func2|0
{@D-T|0|384||0|stl01} associated with the user login.
{@S-PROC|RECEIVE|0}
{@S-PROC|FILTER|0}
{@S-PROC|CAR1|0}
{@S-PROC|CAR2|0}
{@S-PROC|FBMON|0}
}

Record @TJET: TestJet Test

This record that describes the results of TestJet tests.
Table 6-49 @TJET
Format: {@TJET|test status|pin count|test designator}

test status int 00 00 = pass
01 = fail
07 = fatal error
pin count int 0000 number of failing pins
test designator str ""

■ Subrecords: @DPIN is generated when logging
pins to list the failing device pins.
Example 6-42
{@TJET|01|0008|u34}

Record @TS: test shorts

This record describes a shorts test.
Table 6-50 @TS
Format: {@TS|test status|shorts count|opens count|phantoms count|designator}

test status int 0 0 passed; 1 failed; 20 learning passed
shorts count int 0 How many nodes were unexpectedly shorted to some short-source node.
opens count int 0 How many nodes were unexpectedly open.
phantoms count int 0 How many phantoms were encountered.
designator str "" (optional) Designator that identifies the file containing the source code for the shorts
test. This comes from the <file id> parameter in the test shorts statement.
■ Generated by: test shorts statement Example 6-43

■ Subrecords: {@TS|1|2|1|1|
• @TS-O is generated for each unexpectedly open {@TS-S|2|0|Node12
{@TS-D|Node25|1.678853E+00}
node pair. {@TS-D|Node26|2.543216E+00}
• @TS-S is generated for each unexpectedly }
{@TS-O|Node43|Node14|-1.500000E+00}
shorted short-source node. Contains @TS-D
{@TS-S|0|1|Node38
subrecords to identify which destination {@TS-P|-1.243853E+02}
node(s) the source node was shorted to, or }
@TS-P subrecords to identify phantom shorts. }
■ Corresponds to: 41 statement on an 3065 system.

Record @TS-D: destination nodes shorted to

source node
This record describes destination nodes which are
shorted to a source node.
Table 6-51 @TS-D
Format: {@TS-D\destination list}

destination list str/fp ""/0 A list of items which are paired into two fields for each destination
node, as follows:
• node id the id of this destination node.
• deviation the difference M - T, where M is this destination node's
measured value and T is the threshold.
■ Generated by: test shorts statement ■ Corresponds to: 06 record on an 3065 system
when preceded by a 42 record whose field 5-8 has
the value 01.
Example 6-44
{@TS-D\4|Node7|1.398537E+02|Node15|4.138792E+01}

Record @TS-O: opens found while shorts testing

This record describes open found while shorts testing.
Table 6-52 @TS-O
Format: {@TS-O|source node|destination node|deviation}

source node str "" The open-source node id.
destination node str "" The open-destination node id.
deviation fp 0 The difference M - T, where M is the measured value and T is the threshold.
■ Generated by: test shorts statement Record @TS-P: phantoms found while shorts
■ Corresponds to: 42 record on a 3065 system with testing
a value of either 2 or 3 in field 3-4. This record describes phantoms found while shorts
testing.
Example 6-45
{@TS-O|Node85|Node14|-1.510000E+00}
Table 6-53 @TS-P
Format: {@TS-P|deviation}
deviation fp 0 The difference M - T, where M is the measured value and T is the threshold.

■ Generated by: test shorts statement Record @TS-S: results of shorts testing from a
■ Corresponds to: 42 record on a 3065 system with source node
a value of 4 in field 3-4. This record describes a shorts test from a source node.
Example 6-46
{@TS-P|-1.243853E+02}
Table 6-54 @TS-S
Format: {@TS-S|shorts count|phantoms count|source node}

shorts count int 0 How many destination nodes were unexpectedly shorted to the source node.
phantoms count int 0 How many phantoms were encountered from the source node.
source node str "" The source node id. If the source is actually a set of siamese nodes, then the
node id given is representative of the set—probably just the first one in the list.
■ Generated by: test shorts statement Example 6-47

■ Subrecords: {@TS-S|2||Node43
• @TS-D is generated for each destination that is {@TS-D|Node14|1.678859E+00}
{@TS-D|Node32|6.182541E+01}
unexpectedly shorted. }
• @TS-P is generated for each phantom
encountered.
■ Corresponds to: 42 record on a 3065 system with
a value of 0 or 1 in field 3-4.

7 The Board Defaults Files

■ The board_defaults File, 7-3
■ The edge_ board_defaults File, 7-5
Objectives
able to:
■ Understand the content the board defaults files
Prerequisites
chapter.

using this chapter.

Chapter 7: The Board Defaults Files
Overview The board defaults file, board_defaults, provides Two versions of board defaults files are in the standard
Board Consultant with values to use in the board file directory:
when those values are not provided by data files or by
■ The board_defaults file, $AGILENT3070_ROOT/
data entry.
standard/board_defaults, contains values that
Board Consultant looks for a board_defaults file in are typical for a combinational test strategy.
the local board directory. If there is no board_defaults
■ The edge_board_defaults file, $AGILENT3070_
file in the local board directory, Board Consultant looks
ROOT/standard/edge_board_defaults,
under $AGILENT3070_ROOT/standard.
contains values that are typical for an
edge-connector-only test strategy.
NOTE
You can copy one of the standard board defaults files to
your local directory, modify it to fit your exact needs,
04.00pa, an environment variable was created so
and re-save it as board_defaults. However there are
some restrictions when modifying the default file:
UNIX® and MS Windows® controllers, which
have different file systems. The environment ■ Entries are not allowed for nodes, internal
variable, $AGILENT3070_ROOT, replaces the upper devices, device options, or critical pins.
path names on both systems. For example, the
■ Cross-checking of the default board is not
$AGILENT3070_ROOT factory default value is
allowed.
C:/Agilent3070. In this document, only path
names using the environment variable are used. If If you are developing an edge-connector-only test, you
you must use actual path names, refer to older should copy the edge_board_defaults file to your
versions of the documentation. Please see The local board directory and rename it board_defaults
Root Directory Environment Variable in before performing data entry.
Administering Agilent 3070 MS Windows Systems
for further information.

The board_defaults Example 7-1 Board defaults specified in the board_defaults file
File HEADING Open Input DefaultX;
"These are the board defaults"; Load NONE;
GLOBAL OPTIONS TTL
Fixture Type EXPRESS; Drive High 3.5;
Fixture Size FULL; Drive Low 0.2;
Top Probes AllowedOFF; Receive High 2;
Heavy Probe Force8; Receive Low 0.8;
Light Probe Force4; Edge Speed 100;
Mechanical Density Threshold800; Open Input DefaultX;
Vacuum Density Threshold104; Load UP;
Test Strategy COMBINATIONAL; ECL
WireWrapping MANUAL; Drive High -0.5;
Metric Units OFF; Drive Low -2.7;
Common Lead Resistance0.5; Receive High -1.2;
Common Lead Inductance1u; Receive Low -1.5;
Capacitance CompensationON; Edge Speed 150;
DEVICE OPTIONS Open Input Default0;
Tolerance Multiplier5; Load DOWN;
Remote Sensing ON; CARD OPTIONS
Fuse Threshold 10; CMOS
Diode Current 5m; HYBRID;
Zener Current 10m; TTL
Adjust FAST; HYBRID;
Upstream Disable OFF; ECL
Upstream ConditionOFF; HYBRID;
FAMILY OPTIONS
CMOS LIBRARY OPTIONS
Drive High 4; “$AGILENT3070_ROOT/library/ttl"
Drive Low 0.8; “$AGILENT3070_ROOT/library/lsi"
Receive High 3.6; “$AGILENT3070_ROOT/library/cmos"
Receive Low 1.3; “$AGILENT3070_ROOT/library/ecl"
Edge Speed 50; “$AGILENT3070_ROOT/library/setup"

CAPACITOR PIN LIBRARY

C ** ** ** f; U;
CONNECTOR POTENTIOMETER
J NT; P ** ** **;
DIODE RESISTOR
CR ** **; R ** ** ** f;
FET SWITCH
QF ** ** n; S ** OFF;
FUSE TRANSISTOR
F 1; Q ** ** n;
INDUCTOR ZENER
L ** ** ** 1 f; DS ** ** **;
JUMPER END
JP Closed;

The edge_ Example 7-2 Board defaults specified in the edge_board_defaults file
board_defaults File HEADING Receive Low 1.3;
"These are the board defaults for Edge Speed 50;
edge connector use only"; Open Input Default X;
GLOBAL OPTIONS Load NONE;
Fixture Type EXPRESS; TTL
Fixture Size FULL; Drive High 3.5;
Top Probes Allowed OFF; Drive Low 0.2;
Heavy Probe Force 8; Receive High 2;
Light Probe Force 4; Receive Low 0.8;
Mechanical Density Threshold800; Edge Speed 100;
Vacuum Density Threshold 104; Open Input Default X;
Test Strategy EDGE CONNECTOR Load UP;
ONLY; ECL
WireWrapping MANUAL; Drive High -0.5;
Metric Units OFF; Drive Low -2.7;
Common Lead Resistance 0.5; Receive High -1.2;
Common Lead Inductance 1u; Receive Low -1.5;
Capacitance Compensation ON; Edge Speed 150;
DEVICE OPTIONS Open Input Default 0;
Tolerance Multiplier5; Load DOWN;
Remote Sensing ON; CARD OPTIONS
Fuse Threshold 10; CMOS
Diode Current 5m; HYBRID;
Zener Current 10m; TTL
Adjust FAST; HYBRID;
Upstream Disable OFF; ECL
Upstream Condition OFF; HYBRID;
FAMILY OPTIONS LIBRARY OPTIONS
CMOS “$AGILENT3070_ROOT/library/ttl"
Drive High 4; “$AGILENT3070_ROOT/library/lsi"
Drive Low 0.8; “$AGILENT3070_ROOT/library/cmos"
Receive High 3.6; “$AGILENT3070_ROOT/library/ecl"

“$AGILENT3070_ROOT/library/setup" NODE LIBRARY

CAPACITOR U NT NS;
C ** ** ** f NT; POTENTIOMETER
CONNECTOR P ** ** ** NT;
J NT; RESISTOR
DIODE R ** ** ** f NT;
CR ** ** NT; SWITCH
FET S ** OFF NT;
QF ** ** n NT; TRANSISTOR
FUSE Q ** ** n NT;
F 1 NT; ZENER
INDUCTOR DS ** ** ** NT;
L ** ** ** 1 f NT; UNCONNECTED PIN NC;
JUMPER END
JP ClosedNT;

8 Part Description Language
In this chapter... ■ About Part Description Language, 8-2

■ Reference Description of PDL, 8-16
Objectives
able to:
■ Understand the Part Description Language (PDL),
which is the language used to describe devices in
a part description library.
Prerequisites
chapter.

using this chapter.

Chapter 8: Part Description Language
About Part Overview This statement describes a fixed resistor (f) denoted r1.
Its nominal value is 10k ohms, and it has a tolerance of
Description Part Description Language has statements that describe +/- 5%. nr means the resistor is not individually
Language devices. These statements are stored in files, one file per replaceable; it is a child device within a parent device. If
part, in library directories. When you use the Part r1 fails during board test, a replaceable device that
Description Editor it automatically creates files precedes it in the hierarchy must be replaced.
containing the required PDL statements. Thus, test
developers will usually not need to know much about Each part description library has PDL statements like
PDL. these stored in a file. The next section provides
examples that show how these statements are used
Structure of Part Description Language together to form libraries.
Like other programming languages, PDL has a specific Look in directory $AGILENT3070_ROOT/library/
syntax. To read files containing descriptions of parts template/part_library for examples of part
written in PDL, you must understand this syntax. description library files. For complete descriptions of
Sometimes PDL describes the relationship between a the syntax of PDL, see Reference Description of PDL
parent device and its child devices. For example, on page 8-16.
external pins 1
device "u1" pins 2
NOTE
describes the connection between the external pin 1 on
04.00pa, an environment variable was created so
the parent device and pin 2 on child device u1.
In other cases, PDL has keywords followed by UNIX® and MS Windows® controllers, which
parameters (some of which may be optional) that have different file systems. The environment
describe a child device. For example, the keyword variable, $AGILENT3070_ROOT, replaces the upper
resistor would be followed by a list of parameters that path names on both systems. For example, the
describe a specific resistor, like this: $AGILENT3070_ROOT factory default value is
resistor "r1", 10k, 5, 5, f, nr
C:/Agilent3070. In this document, only path
names using the environment variable are used. If

you must use actual path names, refer to older Examples of Part Description Libraries
versions of the documentation. Please see The
Root Directory Environment Variable in Shown below are several examples of how PDL is used
Administering Agilent 3070 MS Windows Systems to create entries in a part description library.
for further information.
Simple Example: A Resistor Pack
Suppose you were writing a part description library for
the resistor pack shown in Figure 8-1.
Figure 8-1 Internal structure of a resistor pack
Notice that the internal devices in the figure above have describe connections between internal devices and
arbitrarily assigned pin numbers. These are needed to external pins.

Before you can use a part description library in a board A part description library file (named rpack_type123,
test, you must invoke the Pin Library Device Entry as shown in the board file) describing this device might
Form in Board Consultant (described in Chapter 2, look like this:
Agilent Board Consultant in Test Development Tools)
and make a corresponding entry there. Use the form to Example 8-2
specify the associations between device pins on the
parent part and nodes at the board level. ! Excerpt from part description library
!
After using the Pin Library Device Entry Form, the resistor "r1", 10k, 5, 5, f, nr
board file entry for the example above might look like resistor "r2", 10k, 5, 5, f, nr
this: resistor "r3", 10k, 5, 5, f, nr
external pins 1
device "r1" pins 1
Example 8-1 external pins 2
device "r2" pins 1
! Excerpt from board file external pins 3
! device "r3" pins 1
PIN LIBRARY external pins 4
rp1 PN"RPACK_TYPE123" device "r1" pins 2
CONNECTIONS device "r2" pins 2
NODE_A device "r3" pins 2
rp1.1;
NODE_B
rp1.2; Because they cannot be individually replaced, the
NODE_C internal resistors—r1 through r3—are denoted nr for
rp1.3; non-replaceable. The number following the external
NODE_D pins statement is a designator that refers to a pin
rp1.4;
number on the package, which must be an external node
that is accessible for probing.
Each pair of entries beneath the connections keyword
associates a pin on the library device with a node to be
tested. For example, NODE_A is associated with rp1.1,
which is pin 1 on rp1, NODE_B is associated with pin 2
on rp1 (rp1.2), etc.

IPG will use the part description library and information rp1%r1 nr;
entered in Board Forms to create three analog test files
during the test development process. These files are: Although this expanded listing is useful for verifying
■ rp1%r1 the contents of the board file, it is not a valid source file
because it contains percent signs, which are not allowed
■ rp1%r2 in device names. You must not replace your original
■ rp1%r3 board source file with this file.
If a resistor inside the resistor pack fails during testing, The pin designators were numbers in the preceding
the failure message associated with it will identify example, but they also could have been strings to denote
which one failed—for example, rp1%r1—and that the pins on a device whose pin designators are not strictly
entire package—rp1—must be replaced. numeric. For example, the entry in the board file:
If desired, you can list the compiled board file to Example 8-4
examine its contents. This lets you verify that the library
test was created. You use the BT-BASIC list object ! Excerpt from board file
statement to create a source listing of an object file. !
PIN LIBRARY
For example, executing rp1 PN"RPACK_TYPE123"
CONNECTIONS
list object 'board.o'
NODE_A
produces a source file listing that includes the rp1."R1"; ! Note the use of strings
following: ! for pin designators that
! were numbers in the
NODE_B ! previous example.
Example 8-3 rp1."R2";
NODE_C
resistor rp1."R3";
rp1%r1 10k 5 5 f; NODE_D
rp1%r1 10k 5 5 f; rp1."COMMON";
rp1%r1 10k 5 5 f;
internal structure rp1;
rp1%r1 nr; matches this part description library:
rp1%r1 nr;

Example 8-5
! Excerpt from part description library

!
external pins "r1"
! Each pin designator in
! an "external pins" statement
! must match its counterpart
! in the board file.
device "r1" pins 1
external pins "r2"
device "r2" pins 1
external pins "r3"
device "r3" pins 1
external pins "common"
device "r1" pins 2
device "r2" pins 2
device "r3" pins 2
Whichever method you use, numbers or strings, the pin

designator following the external pins statement
must match the corresponding pin designator in the
board file.
Complex Example: A Package Device

Figure 8-2 shows a more complex parent device,
followed by a correspondingly more complex example
of a part description library file.

Figure 8-2 Internal structure of a package device
A part description library file describing this parent external pins 2

device might look like this: device "u1" pins 2
external pins 3
device "u1" pins 3
device "u1" pins 4
! Part description library for external pins 5
! package1 device "rp1" pins 1
pin library "u1", nr, pn"7705" external pins 6
pin library "rp1", nr, pn"rpack_type123" device "rp1" pins 2
resistor "r1", 10k, 5, 5, f, nr external pins 7
capacitor "c1", 100p, 10, 10, f, nr device "r1" pins 1
external pins 1 external pins 8; noconnect
device "u1" pins 1

external pins 9; noconnect ■ External pins 8 and 9 are denoted noconnect

external pins 10 because, although they exist physically, they do
device "c1" pins 2
not electrically connect to a device within
external pins 11
device "rp1" pins 3 package1.
external pins 12 ■ There is one internal (not externally accessible)
device "rp1" pins 4
external pins 13
node, internal_c1_r1, which is the connection
device "u1" pins 5 between c1 and r1. It is denoted nomanual
external pins 14 because it cannot be manually probed by the
device "u1" pins 6 board test operator.
external pins 15
device "u1" pins 7 After the part description library has been created, the
external pins 16 internal devices in package1 can be referenced as
device "u1" pins 8 follows:
node "internal_c1_r1"; nomanual
device "c1" pins 1 ■ package1%u1 is a non-replaceable library device
device "r1" pins 2 whose type is 7705.
■ package1%rp1 is a non-replaceable resistor pack.
Suppose the device for which this file was written is It is a library device whose type is
called package1. A part description library file begins rpack_type123.
with a list of child devices within the parent device. The
library statements at the beginning of the file specify ■ package1%r1 is a 10K resistor.
two child devices, u1 and rp1, inside package1. Note ■ package1%c1 is a 100 picofarad capacitor.
that each of these child devices is itself a parent device
(that is, it contains child devices) with its own library Because r1 and c1 are connected to an internal node,
file. A resistor statement and a capacitor statement which is not accessible via the fixture, IPG will not
specify two additional child devices within package1. write a test for them.
Following the list of child devices within package1 is a

list of pin specifications that describes the associations
between internal pins and external pins. Examine these
specifications and notice the following:

How Child Devices Inherit Traits From Parent Using Inherited Traits to Model Devices
Devices Figure 8-3 shows one section of a hypothetical device
called PK1. Suppose PK1 already has a library test (but
If you enter an asterisk (*) as a designator for a child
not a part description library) written for it. That library
device in a part description library, that occurrence of
the child device will be aliased or associated with its test describes the device so that IPG can generate a test
parent device. An aliased child device inherits several for PK1. But the library test does not help when
traits from its parent, including the parent's name, modeling the effect that PK1 has on adjacent circuitry.
replaceability attribute, testability attribute,
SAFEGUARD attribute, device options, and
(optionally) failure message. Except for a failure
message, you should never specify any of these options
for an aliased device. You can alias one child device per
part description library.
NOTE
If you have one part description library inside
another part description library, each of them can
have one aliased device, etc.
This inheritance of traits has the following uses:

■ It aids you in defining the internal analog
characteristics of digital devices, which improves
the accuracy of tests.
■ It simplifies the entry of data in Board Consultant.
Each of these applications is individually described
below.

Figure 8-3 Modeling a pull-up resistor inside a library device
Notice that PK1 has an internal pull-up resistor, r1,

connected between the collector of an output transistor
(which we will say is part of driver circuit driver_xyz)
and power supply VCC.
Seen from an external viewpoint, PK1 looks like Figure
8-4.

Figure 8-4 An external view of device PK1
Because of pull-up resistor r1 inside driver_xyz, it library entry for this device in the board file might look
appears as if a 5K resistor is connected across pins 4 and like this:
10 of device PK1. The resistor provides a shunt
resistance across any external circuitry connected Example 8-7
between VCC and pin 4 of PK1. If IPG does not know
about the presence of r1, it may not be able to write an ! Excerpt from board file
accurate test for circuitry external to PK1. !
PIN LIBRARY
You can fix this problem by writing a part description pk1 PN"pk1_internal"
library that describes the analog characteristics of PK1 CONNECTIONS
. . .
as they relate to device driver_xyz. Suppose we call
NODE_D
this library test pk1_internal. An excerpt from the

pk1.4; inheritance of traits, part description library

. . . driver_xyz will be identified as pk1 if it fails.
NODE_J
pk1.10; Notice that each external pins statement is followed
. . . by two device statements—one for device * (the alias
for driver_xyz) and one for a connection to resistor r1.
An excerpt from the corresponding part description For example, external pin 10 of parent device PK1 is
library file (pk1_internal) might look like this: connected to pin 1 of child device r1 and pin 4 of child
device *. These descriptions show that resistor r1 is in
Example 8-8 parallel with pins on device *.
If you prefer a more specific failure message associated
! "pk1_internal" with the part description library—for example, to
pin library *, pn"driver_xyz" identify accurately why PK1 fails—simply specify an
! Notice the asterisk as a alternate failure message, like this:
! device designator
. . .! in this example.
resistor "r1", 5k, 5, 5, f, nt
. . .
external pins 4
device "r1" pins 2
device * pins 5
. . .
external pins 10
device "r1" pins 1
device * pins 4
The use of an asterisk as a part designator aliases the

name of this occurrence of child device driver_xyz
with its parent device, PK1. The traits the part
description library inherits from its parent include the
parent's name and failure message. Because of this

Example 8-9

!
pin library *, pn"driver_xyz", "Pullup resistor inside driver_xyz failed."
resistor "r1", 5K, 5, 5, f, nt
. . .
external pins 4
device "r1" pins 2
device * pins 5
. . .
external pins 10
device "r1" pins 1
device * pins 4
Simplifying Data Entry Because a part description library contains the same
information you enter to describe devices, it provides a
Creating a part description library for each part you use
shortcut you can use to keep from manually entering all
can greatly reduce the amount of data you must
this redundant information. Instead of repeatedly
manually enter in Board Consultant (or in Board
describing resistor R789 in the Resistor Device Entry
Forms). For example, suppose your company uses 500
Form, you can create a single part description library
different resistors to build its circuit boards. Each of
and then simply refer to it by name in the Pin Library
these resistors has characteristics such as its nominal
Device Entry Form. After you have done this, entering
value, its plus and minus tolerances, and whether it is
only one item—the name of the library device—in the
fixed or variable.
Pin Library Device Entry Form is equivalent to entering
Suppose one of these resistors is type R789. Each time the full characteristics of the device in the Resistor
you use a type R789 resistor on a board, you must Device Entry Form.
re-enter its characteristics—nominal value, fixed or
Suppose resistor type R789 is denoted as r1 on a board
variable, tolerances—in the Resistor Device Entry
to be tested. The library entry for r1/R789 in the board
Form. If you use the same type R789 resistor 50 times
file might look like this:
on a single board (as a pull-up resistor, perhaps), you
must describe its characteristics 50 times.

Example 8-10 alternate name with this occurrence of the child device.
This lets this instance of the aliased child device inherit
! Excerpt from board file the name of the parent device from the board file. The
! corrected file now looks like this:
PIN LIBRARY
r1 PN"R789"
CONNECTIONS Example 8-12
NODE_A
r1.1; ! Excerpt from part description library
NODE_B !
r1.2; resistor *, 10, 5, 5, f
! Notice the asterisk as a
! device designator
Initially, you might think the PDL file for the example ! throughout this example.
should look like this: external pins 1
device * pins 1
device * pins 2
! If this library device fails, the cause will be accurately
resistor "r1", 10, 5, 5, f identified as r1.
external pins 1
device "r1" pins 1 Although this simple example showed a resistor, you
external pins 2 can use this method to reduce the amount of data
device "r1" pins 2
entered for other devices. The more complex the device,
the more effort you can save by creating a part
But describing resistor r1 this way causes a problem. A description library for it.
failing test will identify the cause of the failure as
r1%r1; that is, this file describes a child device within a
You probably will not want to create part description
parent device, which does not match the real case of a libraries for all devices, especially those that are
single device with no internal devices. described elsewhere. For example, the description of a
voltage regulator IC probably belongs in an analog
To prevent this anomaly, enter an asterisk (*) instead of functional library test, and not here.
a device designator. The asterisk associates an alias or

A Shortcut for Denoting Non-Testable Devices Note that you also can make a part description library
device untestable by specifying the nt option for each
Suppose you have created a part description library for a device inside the library. But then you can never test that
parent device that contains child devices that should not library device. The best way to control the testability of
be tested. Perhaps you are using a part description a library device is by modifying the testability of the
library to model the internal characteristics of a device. parent device in the board file.
Here, the part description library is used solely to
improve the accuracy of tests of the surrounding Restrictions on Nested Entries
circuitry and you do not want to test the library device
itself. A part description library can contain other library
devices if the nesting or layering of libraries within
The best way to denote an entire part description library
libraries does not exceed 16. For example, one part
as untestable is to specify NT for the parent device in the
description library can contain any number of library
board file, which makes its contents (the child devices)
devices. But those library devices may contain other
non-testable. The following excerpt from a library entry
library devices, which may contain other library
in the board file shows NT used to declare a library
devices, etc. This nesting of library entries must not
device and its child devices as non-testable.
exceed 16 levels.
Example 8-13 Another restriction on nesting is that you cannot use an
asterisk (*) to alias a part description library device that
! Excerpt from board file is inside another part description library. For example,
! the following statement is not valid
PIN LIBRARY
vr1 NT PN"LM_XYZ" pin library *, pn"part_description_library"
. . .
when the part number (pn) references another part
description library. This restriction is necessary because
This global definition for testability in the board file inherited traits may cause problems when nested part
overrides the individual definitions for testability in a description libraries contain duplicate designators for
PDL file. None of the child devices will be tested, but devices.
IPG will still use the characteristics of the child devices
when writing other tests.

Reference The following topics list the full syntax of the ■ You can specify that a pin on a child device is
statements that comprise PDL. Because part description simultaneously connected to more than one pin on
Description of PDL library files are automatically created whenever you use its parent device—that is, you can manually
the Part Description Editor, you do not need to specify:
understand PDL syntax to this level of detail in order to external pins 1,2
use part description libraries. device "r1" pins 2
! Pin 2 of "r1" connects to two external pins
The syntaxes below are shown in the same format used
for the programming statements described in the Syntax The Part Description Editor lets you specify only the
Reference documentation. With the exception of items following association between pins:
enclosed in quotes—that is, string constants—PDL
external pins 1
syntax is case-sensitive. Thus, C1 and c1 are both valid, device "r1" pins 2
but NT is not a valid alternate for nt. ! Pin 2 of "r1" connects to one external pin
Additional Features for Manually Created PDL capacitor

Files
The capacitor keyword precedes a list of parameters
The values you enter in the Part Description Editor's described in Table 8-1 on page 8-18 that describes an
data entry fields are automatically merged with PDL individual capacitor.
statements to create part description libraries. In most
cases, this is the best way to create part description
libraries. But manually creating PDL files in part mode
provides several features that are not available when
you use the Part Description Editor. The additional
features are:
■ You can specify the ns (no safeguard) option for a
pin library, which disables SAFEGUARD
checking for that library.

Example 8-14
Syntax:
capacitor <designator>, <value>, <+tol>, <-tol>, <type>
capacitor <designator>, <value>, <+tol>, <-tol>, <type>, <options>
capacitor <designator>, <value>, <+tol>, <-tol>, <type>, <message>
capacitor <designator>, <value>, <+tol>, <-tol>, <type>, <options>, <message>
capacitor *, <value>, <+tol>, <-tol>, <type>
capacitor *, <value>, <+tol>, <-tol>, <type>, <message>
<designator> and <message> are <string constants>

<type> can be:
f
v
<options> can be one or more of the following, separated by commas:
nt
nr
pn<part number>
<part number> is a <string constant>
Example:
capacitor "c1", 10u, 10, 10, f, nr
capacitor "c23", 100p, 20, 20, v, pn"123-456", "Varies integration time"
capacitor *, 100p, 20, 20, v! Asterisk lets child device inherit traits from parent device

Table 8-1 capacitor parameters
Parameter Description
<designator> A unique name that identifies a specific capacitor; for example, c1. A <designator> cannot be longer
than 48 characters.
* Specifying an asterisk as a <designator> aliases a child device, which lets it inherit traits from its parent
device. You can alias one child device per part description library.
<value> The nominal value of the capacitor in farads.
<+tol>, <-tol> The plus and minus tolerances as percentages of the capacitor value. Both are positive numbers.
<type> Can be f or v to denote whether the capacitor is fixed or variable.
nt (no test) Instructs IPG not to write a test for the capacitor.
nr Denotes the capacitor as non-replaceable; that is, the capacitor is a child device inside a parent device
and cannot be individually replaced. If you specify nr for a capacitor and its test fails, you will be told to
replace its parent. If you leave the <options> field blank, the options default to nr.
pn<part number> The part number—such as the vendor's part number or your internal part number—of the capacitor. A
part number is used for reference purposes only and cannot be longer than 24 characters.
<message> A message associated with the capacitor. A <message> cannot be longer than 40 characters.
connector testable; enter them in part description libraries simply

for documentation purposes.
The connector keyword precedes a list of parameters
described in Table 8-2 on page 8-19 that describes an
individual connector. Note that connectors are not

Example 8-15
Syntax:
connector <designator>
connector <designator>, <options>
connector <designator>, <message>
connector <designator>, <options>, <message>
connector *
connector *, <message>

nt
nr
pn<part number>

Example:
connector "j5", nr, nt! Connectors cannot be tested.
connector "j1", pn"A678", nt, "j1 located near PK2"
connector * ! Asterisk lets child device inherit traits from parent device.
Table 8-2 connector parameters
<designator> A unique name that identifies a specific connector; for example, j10. A <designator> cannot be
longer than 48 characters.

Table 8-2 connector parameters (continued)
nt (no test) Instructs IPG not to write a test for the connector. If you leave the <options> field blank, the
options default to nt.
nr Because a connector is not testable, this option is not used.
pn<part number> The part number—such as the vendor's part number or your internal part number—of the connector. A
<message> A message associated with the connector. A <message> cannot be longer than 40 characters.
diode
The diode keyword precedes a list of parameters shown
in Table 8-3 on page 8-21 that describes an individual
diode.

Example 8-16
Syntax:
diode <designator>, <high value>, <low value>
diode <designator>, <high value>, <low value>, <options>
diode <designator>, <high value>, <low value>, <message>
diode <designator>, <high value>, <low value>, <options>, <message>
diode *, <high value>, <low value>
diode *, <high value>, <low value>, <message>
<high value>, <low value> are <numeric constants>

nt
nr
pn<part number>
Example:
diode "cr1", nt
diode "cr2", .8, .4, pn"D123-3", "Located next to transformer t1"
diode *, .8, .4 ! Asterisk lets child device inherit traits from parent device.
Table 8-3 diode parameters
<designator> A unique name that identifies a specific diode; for example, cr1. A <designator> cannot be longer than 48
characters.

Table 8-3 diode parameters (continued)
<high value> Specifies the upper test limit, in volts, for the voltage drop across the diode when it is forward biased.
<low value> Specifies the lower test limit, in volts, for the voltage drop across the diode when it is forward biased.
nt (no test) Instructs IPG not to write a test for the diode.
nr Denotes the diode as non-replaceable; that is, the diode is a child device inside a parent device and cannot
be individually replaced. If you specify nr for a diode and its test fails, you will be told to replace its parent.
If you leave the <options> field blank, the options default to nr.
pn<part The part number—such as the vendor's part number or your internal part number—of the diode. A part
number> number is used for reference purposes only and cannot be longer than 24 characters.
<message> A message associated with the diode. A <message> cannot be longer than 40 characters.
external pins
The external pins keyword precedes a list of pins on
a part description library device that are accessible via
the fixture. Unless the external pin is denoted
noconnect because it does not connect to anything,
external pins is followed by a list of child devices
and pins to which the external pin(s) connects.
Parameters are shown in Table 8-4 on page 8-24

Example 8-17
Syntax:
external pins<pin list>; noconnect
external pins<pin list>
<device pin list>
<pin list> can be:
<pin name>
<pin name>, . . . <pin name>
<device pin list> consists of: device <device name> pin <pin name>
<device name> is a <string constant>
<pin name> can be a <numeric constant> or a <string constant>
Example:
external pins 5 ! External pin 5 on the parent device is connected
device "r5" pins 2 ! to pin 2 on child device r5.
external pin 8; noconnect ! The pin does not connect to a child device.
external pins 1, 20 ! External pins 1 and 20 on the parent device are
device "c3" pins 1 ! connected to pins on three child devices.
device "cr1" pins "a"
device "r9" pins 2
Notice that an external pins keyword can be

followed by more than one <device pin list>. Each
additional <device pin list> begins on a new line.

Table 8-4 external pins parameters
<pin name> The name or number of one or more external pins on a part description library device.
noconnect Denotes the pin as accessible via the fixture but not connected to anything inside the library
device.
<device pin list> A list of pins associated with <device name>.
<device name> The identifier of a child device associated with the external pin.
fet
The fet keyword precedes a list of parameters shown in
Table 8-5 on page 8-25 that describes an individual
field-effect transistor.
Example 8-18
Syntax:
fet <designator>, <high value>, <low value>, <type>
fet <designator>, <high value>, <low value>, <type>, <options>
fet <designator>, <high value>, <low value>, <type>, <message>
fet <designator>, <high value>, <low value>, <type>, <options>, <message>
fet *, <high value>, <low value>, <type>
fet *, <high value>, <low value>, <type>, <message>

<type> can be:

n
p
nt
nr
pn<part number>
Examples:
fet "qf1", 200, 100, n
fet "qf2", 300, 150, p, pn"234", "qf2 is located near j3"
fet *, 300, 150, p ! Asterisk lets child device inherit traits from parent device.
Table 8-5 fet parameters
<designator> A unique name that identifies a specific field-effect transistor; for example, qf1. A <designator>
cannot be longer than 48 characters.
* Specifying an asterisk as a <designator> aliases a child device, which lets it inherit traits from its
parent device. You can alias one child device per part description library.
<high value> Specifies, in ohms, the high test limit for the channel resistance (Ron).
<low value> Specifies, in ohms, the low test limit for the channel resistance (Ron).
<type> Can be n or p to denote whether the FET is an n-channel or p-channel device.
nt (no test) Instructs IPG not to write a test for the FET.
nr Denotes the FET as non-replaceable; that is, the FET is a child device inside a parent device and
cannot be individually replaced. If you specify nr for a FET and its test fails, you will be told to

Table 8-5 fet parameters (continued)
pn<part number> The part number—such as the vendor's part number or your internal part number—of the FET. A
<message> A message associated with the FET. A <message> cannot be longer than 40 characters.
fuse
The fuse keyword precedes a list of parameters shown
fuse.

Example 8-19
Syntax:
fuse <designator>, <max current>
fuse <designator>, <max current>, <options>
fuse <designator>, <max current>, <message>
fuse <designator>, <max current>, <options>, <message>
fuse *, <max current>
fuse *, <max current>, <message>
<max current> is a <numeric constant>
nt
nr
pn<part number>
Example:
fuse "f1", 2, nr
fuse "f3", 1.5, pn"89-124", "Fuse for +5 volt supply"
fuse *, 1.5 ! Asterisk lets child device inherit traits from parent device.
Table 8-6 fuse parameters
<designator> A unique name that identifies a specific fuse; for example, f1. A <designator> cannot be longer
than 48 characters.

Table 8-6 fuse parameters (continued)
<max current> The maximum permissible current in amps.
nt (no test) Instructs IPG not to write a test for the fuse.
nr Denotes the fuse as non-replaceable; that is, the fuse is a child device inside a parent device and
cannot be individually replaced. If you specify nr for a fuse and its test fails, you will be told to
pn<part number> The part number—such as the vendor's part number or your internal part number—of the fuse. A
<message> A message associated with the fuse. A <message> cannot be longer than 40 characters.
inductor
The inductor keyword precedes a list of parameters
shown in Table 8-7 on page 8-30 that describes an
individual inductor.

Example 8-20
Syntax:
inductor <designator>, <value>, <+tol>, <-tol>, <resistance>, <type>
inductor <designator>, <value>, <+tol>, <-tol>, <resistance>, <type>, <options>
inductor <designator>, <value>, <+tol>, <-tol>, <resistance>, <type>, <message>
inductor <designator>, <value>, <+tol>, <-tol>, <resistance>, <type>, <options>, <message>
inductor *, <value>, <+tol>, <-tol>, <resistance>, <type>
inductor *, <value>, <+tol>, <-tol>, <resistance>, <type>, <message>
<value>, <+tol>, <-tol>, <resistance> are <numeric constants>
<type> can be:
f
v
nt
nr
pn<part number>
Example:
inductor "l1", 1.5, 5, 5, 10, f
inductor "l2", 20u, 10, 10, 2, v, "pn8A9", "Tuning inductor"
inductor *, 20u, 10, 10, 2, v! * lets child device inherit traits from parent device.

Table 8-7 inductor parameters
<designator> A unique name that identifies a specific inductor; for example, l1. A <designator> cannot be longer
than 48 characters.
<value> The nominal value of the inductor in Henries.
<+tol>, <-tol> The plus and minus tolerances as percentages of the inductor value. Both are positive numbers.
<resistance> The series resistance of the inductor in ohms.
<type> Can be f or v to denote whether the inductor is fixed or variable.
nt (no test) Instructs IPG not to write a test for the inductor.
nr Denotes the inductor as non-replaceable; that is, the inductor is a child device inside a parent device
and cannot be individually replaced. If you specify nr for an inductor and its test fails, you will be told
to replace its parent. If you leave the <options> field blank, the options default to nr.
pn<part number> The part number—such as the vendor's part number or your internal part number—of the inductor. A
<message> A message associated with the inductor. A <message> cannot be longer than 40 characters.

Internal node Notice that an internal node keyword can be followed

by more than one <device pin list>. Each additional
The internal node keyword specifies nodes within a <device pin list> begins on a new line.
part description library device that are not accessible via
the fixture. Although these nodes are inaccessible, you
must specify them so the part description library
accurately describes the structure of a library device.
Parameters are shown in Table 8-8 on page 8-32.
Example 8-21
Syntax:
internal node<node name>
<device pin list>
internal node<node name>; nomanual
<device pin list>
<node name> can be a <numeric constant> or a <string constant>
<device pin list> consists of: device <device name> pins <pin name>
<device name> is a <string constant>
<pin name> can be a <numeric constant> or a <string constant>
Example:
internal node "c7r15" ! Internal node is a connection between pin 1 of
device "c7" pins 1 ! c7 and pin 2 of r15.
device "r15" pins 2
internal node "c4c6r12r13" ! Internal node connects together the pins
device "c4" pins 1 ! on four devices.
device "c6" pins 2
device "r12" pins 2
device "r13" pins 1

Table 8-8 internal node parameters
<node name> The identifier of an internal node inside a part description library device. This is a node that is not
accessible via the fixture.
<device pin list> A list of pins associated with <device name>.
<device name> The identifier of a device associated with the internal node.
<pin name> The name (or number) of the pin(s) associated with <device name>.
nomanual Denotes the node as inaccessible to the operator; that is, manual probing is not possible
jumper
The jumper keyword precedes a list of parameters
individual jumper.

Example 8-22
Syntax:
jumper <designator>, <status>
jumper <designator>, <status>, <options>
jumper <designator>, <status>, <message>
jumper <designator>, <status>, <options>, <message>
jumper *, <status>
jumper *, <status>, <message>
<status> can be:
open
closed

nt
nr
pn<part number>
Examples:
jumper "jp1", closed
jumper "jp2", open, nt, "Jumper will be installed later."
jumper *, open ! Asterisk lets child device inherit traits from parent device.

Table 8-9 jumper parameters
<designator> A unique name that identifies a specific jumper; for example, jp1. A <designator> cannot be longer
than 48 characters.
<status> Can be open or closed to denote the status of the jumper when it is tested.
nt (no test) Instructs IPG not to write a test for the jumper.
nr Denotes the jumper as non-replaceable; that is, the jumper is a child device inside a parent device
and cannot be individually replaced. If you specify nr for a jumper and its test fails, you will be told to
pn<part number> The part number—such as the vendor's part number or your internal part number—of the jumper. A
<message> A message associated with the jumper. A <message> cannot be longer than 40 characters.
pin library identifiers for these other library devices. Parameters are
shown in Table 8-10 on page 8-35
The library keyword precedes a list of component
designators that identify other pin library devices that
appear in a part description library. For example, a
custom device called device1 might contain child
devices that are library devices. Thus, the part
description library for device1 must also include

Example 8-23
Syntax:
pin library <designator>, pn<part number>
pin library <designator>, pn<part number>, <message>
pin library <designator>, <options>, pn<part number>
pin library <designator>, <options>, pn<part number>, <message>
pin library *, pn<part number>
pin library *, pn<part number>, <message>
<designator>, <part number>, and <message> are <string constants>

<options> can be:
nr
ns
nt
Example:
pin library "u1", nt, pn"7705"
pin library "rp1", nr, pn"rpack_type123", "Resistor pack on PACKAGE1"
pin library *, pn"HYBRID2"! Asterisk lets child device inherit traits from parent device.
Table 8-10 pin library parameters
<designator> A unique name that identifies a specific pin library device. A <designator> cannot be longer than
48 characters.

Table 8-10 pin library parameters (continued)
nr Denotes the library device as non-replaceable; that is, the library device is a child device inside a
parent device and cannot be individually replaced. If you specify nr for a library device and its
test fails, you will be told to replace its parent. If you leave the <options> field blank, the options
default to nr.
ns Denotes no safeguard for this library device—that is, SAFEGUARD is disabled.
nt (no test) Instructs IPG not to write a test for the library device.
pn<part number> The part number—such as the vendor's part number or your internal part number—of the library
device. A part number is used for reference purposes only and cannot be longer than 24
characters.
<message> A message associated with the library device. A <message> cannot be longer than 40
characters.
potentiometer
The potentiometer keyword precedes a list of
parameters shown in Table 8-11 on page 8-37 that
describes an individual potentiometer.

Example 8-24
Syntax:
potentiometer <designator>, <value>, <+tol>, <-tol>
potentiometer <designator>, <value>, <+tol>, <-tol>, <options>
potentiometer <designator>, <value>, <+tol>, <-tol>, <message>
potentiometer <designator>, <value>, <+tol>, <-tol>, <options>, <message>
potentiometer *, <value>, <+tol>, <-tol>
potentiometer *, <value>, <+tol>, <-tol>, <message>
nt
nr
pn<part number>
<part number> is <string constant>
Example:
potentiometer "p1", 1M, 20, 20, nr
potentiometer "p2", 10k, 10, 10, nt, pn"R2A-34", "Gain adjustment"
potentiometer *, 10K, 10, 10! * lets child device inherit traits from parent device.
Table 8-11 potentiometer parameters
<designator> A unique name that identifies a specific potentiometer; for example, p1. A <designator> cannot be

Table 8-11 potentiometer parameters (continued)
<value> The nominal value of the potentiometer in ohms.
<+tol>, <-tol> The plus and minus tolerances as percentages of the potentiometer value. Both are positive
numbers.
nt (no test) Instructs IPG not to write a test for the potentiometer.
nr Denotes the potentiometer as non-replaceable; that is, the potentiometer is a child device inside a
parent device and cannot be individually replaced. If you specify nr for a potentiometer and its test
fails, you will be told to replace its parent. If you leave the <options> field blank, the options default to
nr.
pn<part number> The part number—such as the vendor's part number or your internal part number—of the
potentiometer. A part number is used for reference purposes only and cannot be longer than 24
characters.
<message> A message associated with the potentiometer. A <message> cannot be longer than 40 characters.
resistor
The resistor keyword precedes a list of parameters
individual resistor.

Example 8-25
Syntax:
resistor <designator>, <value>, <+tol>, <-tol>, <type>
resistor <designator>, <value>, <+tol>, <-tol>, <type>, <options>
resistor <designator>, <value>, <+tol>, <-tol>, <type>, <message>
resistor <designator>, <value>, <+tol>, <-tol>, <type>, <options>, <message>
resistor *, <value>, <+tol>, <-tol>, <type>
resistor *, <value>, <+tol>, <-tol>, <type>, <message>
<type> can be:
f
v
nt
nr
pn<part number>
Example:
resistor "r1", 4.7, 5, 5, f
resistor "r2", 5k, 10, 10, v, pn"325-5", "Located near connector"
resistor *, 5k, 10, 10, v! Asterisk lets child device inherit traits from parent device.

Table 8-12 resistor parameters
<designator> A unique name that identifies a specific resistor; for example, r1. A <designator> cannot be
<value> The nominal value of the resistor in ohms.
<+tol>, <-tol> The plus and minus tolerances expressed as percentages of the resistor value. Both are positive
numbers.
<type> Can be f or v to denote whether the resistor is fixed or variable.
nt (no test) Instructs IPG not to write a test for the resistor.
nr Denotes the resistor as non-replaceable; that is, the resistor is a child device inside a parent device
and cannot be individually replaced. If you specify nr for a resistor and its test fails, you will be told to
pn<part number> The part number—such as the vendor's part number or your internal part number—of the resistor. A
<message> A message associated with the resistor. A <message> cannot be longer than 40 characters.

switch
The switch keyword precedes a list of parameters
(shown in Table 8-13 on page 8-42) that describe an
individual switch.
Example 8-26
Syntax:
switch <designator>, <common pin>, <contact pin>
switch <designator>, <common pin>, <contact pin>, <options>
switch <designator>, <common pin>, <contact pin>, <message>
switch <designator>, <common pin>, <contact pin>, <options>, <message>
switch *, <common pin>, <contact pin>
switch *, <common pin>, <contact pin>, <message>
<designator>, <common pin>, and <message> are <string constants>

<contact pin> can be:
<contact pin>
OFF
<contact pin> is a <string constant>
nr
nt
pn<part number>
Example:
switch "s1", "1", "3", nr ! Switch s1 closed, pin 1 to pin 3
switch "s1", "1", OFF ! Switch s1 open; no closed contacts
switch "s2", "1", "2", nt, pn"GH12-7A", "Channel selector”
! Switch s2 closed and not tested
switch *, "1", "2" ! Asterisk lets child device inherit traits
! from parent device.

Table 8-13 switch parameters
<designator> A unique name that identifies a specific switch; for example, s1. A <designator> cannot be longer than
48 characters.
<common pin> Specifies the common pin in a switch.
<contact> Specifies the contact pin in a switch. This can be OFF (the switch is open) or the identifier of a pin to
which the common pin is connected during the test.
<contact pin> The identifier of a pin to which the common pin is connected during the test.
nt (no test) Instructs IPG not to write a test for the switch.
nr Denotes the switch as non-replaceable; that is, the switch is a child device inside a parent device and
cannot be individually replaced. If you specify nr for a switch and its test fails, you will be told to replace
its parent. If you leave the <options> field blank, the options default to nr.
pn<part number> The part number—such as the vendor's part number or your internal part number—of the switch. A part
number is used for reference purposes only and cannot be longer than 24 characters.
<message> A message associated with the switch. A <message> cannot be longer than 40 characters.

transistor
The transistor keyword precedes a list of parameters
individual bipolar transistor.
Example 8-27
Syntax:
transistor <designator>, <high value>, <low value>, <type>
transistor <designator>, <high value>, <low value>, <type>, <options>
transistor <designator>, <high value>, <low value>, <type>, <message>
transistor <designator>, <high value>, <low value>, <type>, <options>, <message>
transistor *, <high value>, <low value>, <type>
transistor *, <high value>, <low value>, <type>, <message>

<type> can be:

n
p

nr
nt
pn<part number>
Example:
transistor "q1", 200, 50, n, nr
transistor "q2", 100, 20, p, "pn1245-25", "Part of preamplifier"
transistor *, 100, 20 ! Asterisk lets child device inherit traits from parent device.

Table 8-14 transistor parameters
<designator> A unique name that identifies a specific bipolar transistor; for example, q1. A <designator> cannot be
<high value> The upper test limit specified as a DC beta value.
<low value> The lower test limit specified as a DC beta value.
<type> Can be n or p to denote whether the bipolar transistor is an npn or a pnp device.
nt (no test) Instructs IPG not to write a test for the transistor.
nr Denotes the transistor as non-replaceable; that is, the transistor is a child device inside a parent device
and cannot be individually replaced. If you specify nr for a transistor and its test fails, you will be told to
pn<part number> The part number—such as the vendor's part number or your internal part number—of the transistor. A
<message> A message associated with the transistor. A <message> cannot be longer than 40 characters.
zener
The zener keyword precedes a list of parameters shown
Zener diode.

Example 8-28
Syntax:
zener <designator>, <value>, <+tol>, <-tol>
zener <designator>, <value>, <+tol>, <-tol>, <options>
zener <designator>, <value>, <+tol>, <-tol>, <message>
zener <designator>, <value>, <+tol>, <-tol>, <options>, <message>
zener *, <value>, <+tol>, <-tol>
zener *, <value>, <+tol>, <-tol>, <message>

nr
nt
pn<part number>
Example:
zener "ds1", 5.6, 5, 5, nr
zener "ds2", 8.2, 10, 10, pn"z89-1", "Located near power transformer"
zener *, 8.2, 10, 10 ! Asterisk lets child device inherit traits from parent device.
Table 8-15 zener parameters
<designator> A unique name that identifies a specific Zener diode; for example, ds1. A <designator> cannot be

Table 8-15 zener parameters (continued)
<value> The nominal value in volts.
<+tol>, <-tol> The plus and minus tolerances expressed as percentages of the Zener value. Both are positive
numbers.
nt (no test) Instructs IPG not to write a test for the Zener diode.
nr Denotes the Zener diode as non-replaceable; that is, the Zener diode is a child device inside a parent
device and cannot be individually replaced. If you specify nr for a Zener diode and its test fails, you will
be told to replace its parent. If you leave the <options> field blank, the options default to nr.
pn<part number> The part number—such as the vendor's part number or your internal part number—of the Zener diode.
A part number is used for reference purposes only and cannot be longer than 24 characters.
<message> A message associated with the Zener diode. A <message> cannot be longer than 40 characters.

■
Numerics A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Index
A defining a FET, 1-39

defining a fuse, 1-41
Additional Board Voltage, 1-19 defining a jumper, 1-45
additional features in PDL, 8-16 defining a node library, 1-47
aliasing defining a pin library, 1-49
child devices with parent devices, 8-9 defining a potentiometer, 1-52
asterisk (*) defining a resistor, 1-54
used to alias child devices with parent devices, 8-9 defining a switch, 1-56
autofile defining a transistor, 1-58
fixture file syntax, 5-6, 5-14 defining a Zener, 1-60
defining an inductor, 1-43
device options, 1-21
B disabling information, specifiying, 1-68
duplicate entry errors, 1-11
bcf syntax, 1-6 family options, 1-25
board configuration format syntax (BCF), 1-6 fixed or power supply nodes, specifying, 1-28, 1-29
board file global options, editing, 1-14
associating a failure message with a node, 1-62 GP relay, assigning, 1-30
card options, 1-28 identifiers, 1-8
critical pins, specifying, 1-67 including an optional file, 1-13
dangling pins, 1-67 keywords, 1-8
defaults, 1-9 library directories, specifying, 1-32
defining a capacitor, 1-34 overriding device options, 1-32
defining a connector, 1-36 overview, 1-4
defining a diode, 1-38 parent devices, 1-68

Index ■ Bookshelf
■ Syntax Reference
■ Master Index
preconditioning, 1-68 comment
specifying a heading, 1-13 commenting a test for test generation, 3-4
specifying connections to device pins, 1-66, 1-67
symbols, 1-6
translating device pin names with a pin map, 1-63 D
unconnected pin, identifying, 1-65
undefining devices, 1-62 dangling pin, 1-67
board placement datalogging
board_xy file syntax, 2-10 format of the log records, 6-1
board.o file denoting part description libraries as untestable, 8-15
listing the object file, 1-3, 2-3 Density Threshold, 5-6
board_defaults file, 7-2, 7-3 device test
board file usage, 1-9 controlling test generation in the ’testorder’ file, 3-4
board_xy file
including another file, 2-10
scaling the input coordinates, 2-9 E
specifying a board keepout area, 2-13 edge_board_defaults file, 7-2, 7-5
specifying a board outline, 2-11
specifying alternate node locations, 2-14
specifying bottom side devices, 2-26
specifying the board placement, 2-10 F
boundary scan chains file
board file, 1-76 board_defaults file, 7-3
edge_board_defaults file syntax, 7-5
fixture
C electronics, 5-38
part numbers, 5-5, 5-13
CAD Format Translator
duplicate entry error in the board file, 1-11 fixture defaults, 5-51
operation on the board ’file’, 1-9 fixture file
© Agilent Technologies 2001 Agilent 3070 / 79000 Data Formats 1-2

Index ■ Bookshelf
■ Master Index
board keepout area, 5-21 I
board outline, 5-19
board placement, 5-19 inheritance of traits in part description libraries, 8-9
describing board attributes, 5-6 used to model devices, 8-9
describing fixture attributes, 5-5, 5-11 used to simplify data entry, 8-13
fixture keepout areas, 5-15 interpreting log records, 6-10
including another file, 5-15, 5-18
tooling holes, 5-20
top side electrical probing, enabling, 5-13 K
Fixture Handler, 5-5 KEEPOUT, 5-6
fixture keepout areas keepout area
specifying, 5-15 syntax of specifying a board keepout area, 2-13
Fixture Size, 5-5 keepout areas
fixture templates, 5-51 specifying a fixture keepout, 5-15
Fixture Type, 5-5
fixture.o, 5-3
fixture_defaults.o, 5-52 L
Flash ISP, 6-51 Light Probe Force, 5-6
formatting log records, 6-15 log record, 6-2
hierarchy, 6-8
interpreting, 6-10
H prefixes, 6-3
Heavy Probe Force, 5-6 process steps in, 6-13
rules of formatting, 6-15
hierarchy
special characters in, 6-15
of log records, 6-8
truncated, 6-13
HOLES, 5-6 user-defined, 6-14
holes log records
fixture file syntax, 5-16 A-CAP, 6-17

Index ■ Bookshelf
■ Master Index
A-DIO, 6-18 PCHK, 6-59
A-FUS, 6-19 PF, 6-60
AID, 6-31 PIN, 6-61
A-IND, 6-20 PRB, 6-61
A-JUM, 6-21 RETEST, 6-62
ALM, 6-32 RPT, 6-62
A-MEA, 6-22 S-PROC, 6-64
A-NFE, 6-23 TJET, 6-69
A-NPN, 6-24 TS, 6-70
A-PFE, 6-25 TS-D, 6-71
A-PNP, 6-26 TS-O, 6-72
A-POT, 6-27 TS-P, 6-72
A-RES, 6-28 TS-S, 6-73
ARRAY, 6-33
A-SWI, 6-29
A-ZE, 6-30 M
BATCH, 6-34
BLOCK, 6-36 Metric Units, 5-6
BS-O, 6-38
BS-S, 6-39
BTEST, 6-40 O
CCHK, 6-44 objectives, 1-1, 2-1, 3-1, 4-1, 5-1, 6-1, 7-1, 8-1
DPIN, 6-45, 6-46
D-T, 6-50
GROUP, 6-51
INDICT, 6-52 P
LIM2, 6-54 Part Description Language
LIM3, 6-55 overview, 8-2
MAGICCLUSTER, 6-56 reference description, 8-16
NETV, 6-57 syntax, 8-2
NODE, 6-58

Index ■ Bookshelf
■ Master Index
part number S
fixture, 5-5
Shorting Radius, 1-21
PDL -- See Part Description Language
special characters
permanent
in log records, 6-15
marking a test permanent, 3-4
personality pin
connected nodes in the fixture file, 5-24, 5-40
T
pin mapping
board file, 1-9 testorder file
Precondition Levels, 1-18 scanworks test statement, 3-6
preconditioning testplan
board file syntax, 1-68 enabling testplan generation in the ’testorder’ file, 3-9
prefix tools and materials, 1-1, 2-1, 3-1, 4-1, 5-1, 6-1, 7-1, 8-1
for log records, 6-3 truncated log records, 6-13
prerequisites, 1-1, 2-1, 3-1, 4-1, 5-1, 6-1, 7-1, 8-1
probe plate
fixture file syntax for specifying holes, 5-16 U
process user-definable
steps in log records, 6-13 log records, 6-14
R W
Records wirelist.o file
test digital, 6-50 list the object, 4-2
reference description of PDL, 8-16 wirewrapping, 5-6
restrictions on nested entries in part description libraries, 8-15
rotating the board
syntax in the board_xy file, 2-10

I CT Manual Data Loggin

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

I CT Manual Data Loggin

Uploaded by

Copyright:

Available Formats

Contents Data Formats

1 The Board File

© Agilent Technologies 2001 Data Formats i

Library Options.................................................................................................................... 1-32

2 The board_xy File

© Agilent Technologies 2001 Data Formats ii

board_xy File Syntax ................................................................................................................... 2-9

3 The Testorder File

4 The Wirelist File

© Agilent Technologies 2001 Data Formats iii

© Agilent Technologies 2001 Data Formats iv

5 The Fixture Files

© Agilent Technologies 2001 Data Formats v

Keepout ................................................................................................................................ 5-55

6 Log Record Format

© Agilent Technologies 2001 Data Formats vi

Record @A-DIO: diode....................................................................................................... 6-18

© Agilent Technologies 2001 Data Formats vii

Record @NODE: list of nodes ............................................................................................ 6-58

7 The Board Defaults Files

8 Part Description Language

© Agilent Technologies 2001 Data Formats viii

About Part Description Language................................................................................................ 8-2

© Agilent Technologies 2001 Data Formats ix

In this chapter... ■ Overview, 1-2

■ Board File Overview, 1-4

■ BCF Syntax Structure, 1-6

■ Board File Structure, 1-12

■ Sample Board File, 1-78

Required Tools and Materials

© Agilent Technologies 2001 Data Formats 1-1

3 Modify the board file manually.

© Agilent Technologies 2001 Data Formats 1-2

c Generate a board source file from the board.o

d Load the board file. Type:

e Edit the board file.

This chapter gives you an overview of the board file, an

© Agilent Technologies 2001 Data Formats 1-3

Where Does the Board File Come From?

© Agilent Technologies 2001 Data Formats 1-4

Programs that use the board and board.o Files

© Agilent Technologies 2001 Data Formats 1-5

© Agilent Technologies 2001 Data Formats 1-6

Table 1-3 BCF special characters (continued) ! comment

Character Description Numerals

© Agilent Technologies 2001 Data Formats 1-7

© Agilent Technologies 2001 Data Formats 1-8

The board_defaults file can be located under the local

© Agilent Technologies 2001 Data Formats 1-9

Keyword Description Keyword Description

© Agilent Technologies 2001 Data Formats 1-10

Table 1-6 BCF keywords (continued) Duplicate Entries

© Agilent Technologies 2001 Data Formats 1-11

Table 1-7 Board file modules (continued)

Module See Section UNCONNECTED Unconnected Pin on page 1-65

Device Device Definitions on page 1-33 END End on page 1-77

© Agilent Technologies 2001 Data Formats 1-12

■ fixed nodes (if any)

© Agilent Technologies 2001 Data Formats 1-13

Table 1-9 Global options

Option Description Syntax Default Example

© Agilent Technologies 2001 Data Formats 1-14

Table 1-9 Global options (continued)