Prober Drivers

A prober driver is a set of USERC functions designed to control an IC wafer prober from an IC-CAP macro program. There are 3 types of probers (an initial call declares which type is in use) with these symbolic names:

These probers share the same driver functions. External user functions and internal design functions, as well as prober settings and commands, are described in this section.

Additional TIS prober drivers required the renaming of native IC-CAP prober functions from prober_xxxx() to icprober_xxxx(). This only affects systems where the prober.c file has been customized in the OMI environment, and will not affect previously-written macros. See the Readme file in $ICCAP_ROOT/src/README for information about these functions.

To provide easier manipulation of a raw GPIB device file, IC-CAP offers a set of low-level I/O functions named ice_hpib_xxxx. The declarations of these functions are found in icedil.h; their definitions are in icedil.c. Both files are provided as C source files. For more information on these I/O functions, see Appendix I, "icedil Functions" in online help. Driver functions are contained in the directory $ICCAP_ROOT/src in the files shown in the following table.

Table 42 Prober Driver Source Files

File Name	Description
prober.h	Prober call prototypes for userc.c
prober.c	Actual code for each prober function
icedil.h	Low level I/O call prototypes for prober.c
icedil.c	Actual code for each ice_hpib_xxxx call
testprob.c	Small interactive program to test the driver
run_testprob	Properly sets your shared library lookup path and runs ./testprob if it exists, otherwise it runs $ICCAP_ROOT/bin/testprob. ICCAP_ROOT must be properly set in your environment for run_testprob to work.

A custom driver can be added by editing prober.c in $ICCAP_ROOT/src and generating a new shared library file, libicuserc.<ext> (where ext is a platform-specific extension) because all prober drivers are written in C and treated as library functions.

Source code is provided with this open interface. Recompilation and relinking are necessary if this driver is user-modified.

External Prober User Functions

This section describes the external user functions.

Prober_debug    This function takes 2 arguments and sets the internal flags. The first argument defines the debug flag; when it is 1, all debugging information is displayed in the Status window. The second argument defines the stop flag; when it is 1, the Macro execution stops when an error is detected. After Prober_init(), the debug flag is off (0) and the stop flag is on (1). This function does not exist in TIS. This function always returns 0. An example call is:

 x = Prober_debug (1, 0);

Every function looks at this internal debug flag and prints out any GPIB commands it is going to send, or a string it just received from the prober.

Prober_init    This function must be called before any other prober calls are made in a Macro program. This function takes a GPIB address of the prober, flat orientation, prober type name, and a raw GPIB interface name to which the prober is connected. The flat orientation is usually 0, 90, 180, or 270. The function returns 0 when prober initialization is successful and -1 when it fails. The following table lists the GPIB configuration recommended for HP 4062UX.

Table 43 Standard HP 4062UX Configuration

Select Code	Devices
7 or 27	Instruments and Switching Matrix
25	Wafer Prober

For a Sun SPARC computer, use the following call because a National Instruments GPIB card has this name by default:

 x = Prober_init (1, 0, "EG1034X", "/dev/gpib0");

For an HP 700 Series computer, use the following call because it involves a symbolic name rather than a GPIB interface filename:

 x = Prober_init (1, 0, "EG1034X", "hpib");

This function also checks the prober type and sets the internal prober type flag for subsequent driver calls. It closes its private unit descriptor from any previous prober access, opens the given GPIB interface file and keeps a new entity id. It then calls an appropriate subfunction, which does the prober-dependent initialization.

Prober_reset    This function takes no arguments and sets the prober to Local mode. It returns 0 when successful and -1 when it fails. This function is not available for EG1034X (for which it is a no-operation). An example call is:

 x = Prober_reset ();

This function clears the interface file and sends a selected device clear command to the prober.

Prober_status    This function takes no arguments and returns 3 Real values in 1 array. The first element of the array indicates whether the prober is Remote (1) or Local (0). The second element indicates whether the edge contact is detected (1) or not (0). The last element indicates whether the Cassette is empty (1) or not (0). An example call is:

 status = Prober_status ();
if (status[0] == 1) then ...

This function sends a query command to the prober and receives information about Remote/Local state as well as the edge sensor output. The Cassette Empty error is detected in the function Phome and referred by this function, which keeps these states and returns them back in an array of Real values.

Pdown    This function takes no arguments and lowers the chuck of the wafer prober. It returns 0 when successful and -1 when it fails. An example call is:

 x = Pdown ();

Phome    This function takes no arguments and performs several tasks depending on the prober type. It returns 0 when successful and -1 when it fails. When it detects a Cassette Empty error, it returns 1. An example call is:

 x = Phome ();

This function calls a subfunction based on the prober type. A subfunction actually does the prober-dependent operation appropriate for Phome.

Pimove    Like Pmove, this function takes 2 arguments and moves the chuck relative to the current position. It returns 0 when successful and -1 when it fails. An example call is:

 x = Pimove (1, 0);

Pink    This function takes 1 argument and triggers the specified inker. It returns 0 when successful or -1 when it fails. EG1034X and SUMMIT10K probers do not support an inker, so this function is a no-operation for them. An example call is:

 x = Pink (1);

Pmove    This function takes 2 arguments and moves the chuck to the specified absolute coordinates established by Pscale and Porig. The first argument specifies the new X position and the second specifies the new Y position. It returns 0 when successful and -1 when it fails. An example call is:

 x = Pmove (2, 4);

This function calculates how many machine units the chuck must move relative to the current position, and sends an appropriate GPIB command to move the chuck. It also updates its internal variables to keep track of the position.

Porig    This function takes 2 numbers and defines these numbers as X and Y coordinates of the current chuck position. This function must be called before any Pmove or Pimove functions. It always returns 0. An example call is:

 x = Porig (0, 0);

This function stores the given numbers in its private variables.

Ppos    This function takes no arguments and returns 2 Real values in an array, indicating the current die X and Y position being probed. The first element of the array is the X coordinate and the second is the Y coordinate. An example call is:

 position = Ppos ();
print "X = "; position[0], "Y = "; position[1];

This function copies its private variables (which indicate the current position) and returns them.

Pscale    This function takes the die X and Y dimensions in micrometers. These numbers are later used in Pmove, Porig, and Pimove functions. It always returns 0. An example call is:

 x = Pscale (5000, 5000);

This function stores the given numbers in its private variables.

Pup    This function takes no arguments and raises the chuck of the wafer prober so that probe pins come in contact with the wafer. It returns 0 when successful and -1 when it fails. An example call is:

 x = Pup ();

Internal Prober Functions

Several internal functions support the user functions to customize the prober driver. For each algorithm, refer to the prober.c source file.

prober_get_err    This function takes 1 argument and calls a subfunction depending on the prober type. Each subfunction reads any error status from the prober. If it encounters an unknown error, it prints out the given number with an error message to the Status window. It always returns 0. An example call is:

 ret = prober_get_err(n);

prober_get_srq    This function takes no arguments and returns 0 (no SRQ) or 1 (SRQ) depending on the SRQ line of the device file. An example call is:

 ret = prober_get_srq();

prober_message    This function takes 1 argument, a pointer to a string, and prints an error message to the Status window such as <name>: unknown prober type, where <name> is replaced with the given string. An example call is:

 ret = prober_message("Prober_reset");

prober_precheck    This function takes no arguments and checks prober state such as Remote/Local and SRQ. It returns 0 when successful and -1 when it fails. An example call is:

 ret = prober_precheck();

prober_response    This function takes 1 argument that is either a pointer to a character array or null. It calls a subfunction depending on the prober type and each subfunction reads any status information from the prober. Internal flags are set according to the status and any errors are reported. It returns 0 if there is no error. If a non-null pointer is given, a received string from the prober is returned using this pointer. An example call is:

 char buffer[PSIZE];
ret = prober_response(buffer);

prober_spoll    This function takes no arguments and performs serial polls in a prober-dependent way that may be different from the standard IEEE 488 implementation. It returns a status byte from the prober. An example call is:

 ret = prober_spoll();

prober_wait_srq    This function takes 1 argument that is a timeout value in seconds, and waits for SRQ to be asserted. It returns 0 when SRQ is detected and -1 when a timeout or error occurs. An example call is:

 ret = prober_wait_srq(60.0);   /* 60 sec */

Prober Settings and Commands

This section describes the correct IC-CAP wafer prober settings and their associated GPIB commands.

EG1034X

This simple manual prober uses 2 settings. (Note that IC-CAP uses SRQ whereas HP 4062UX does not.)

The following table lists the EG1034X GPIB commands. (Note that IC-CAP uses the MM command to move the chuck; HP 4062UX uses the MO commands for the EG1034X.)

Table 44 EG1034X GPIB Commands

Item	Command	Reply	Item	Command	Reply
Move Chuck	MM	MC	Chuck Home	HO	MC
Chuck Up	ZU	MC	Chuck Status	?S	SZ...
Chuck Down	ZD	MC

EG2001X

This driver is tested with a prober software version called AC. The parameters listed in the following table must be set to control this prober. Note that the I/O PROTOCOL is different from the one for HP 4062UX. The Die Size is optional, but is included because IC-CAP does not set the size for manual operations.

Table 45 EG2001X Settings 

Parameter	Value	Parameter	Value
METRIC/ENGLISH	METRIC	AUTO LOAD	ENB if available
DIE X and Y SIZE	Any	AUTO ALIGN	ENB if available
AUTO PROBER PAT.	EXTERNAL	AUTO PROFILE	ENB if available
AUTO DIAMETER	ENB	MF/MC on X-Y	ENB
Z-TRAVELING MODE	EDGE-SEN	MF/MC on Z	DIS
I/O PROTOCOL	ENHANCED	MF/MC on OPT.	ENB
I/O PORT	GPIB-SP	MF/MC on others	DIS
GPIB ADDRESS	Any
SRQ SWITCH	ENB

The following table lists the EG2001X GPIB commands. Note that Chuck Home uses both UL and LO commands (HP 4062UX uses LO).

Table 46 EG2001X GPIB Commands

Item	Command	Reply	Item	Command	Reply
Move Chuck	MM	MC or MF	Auto Profile	PZ	MC or MF
Chuck Up	ZU		Auto Align	AA	MC or MF
Chuck Down	ZD		Trigger Inker	IK	MC or MF
Chuck Home	UL/LO	MC or MF	Chuck Status	?S	SZ...

APM3000A, APM6000A, APM7000A

This prober uses the following settings:

The following table lists the commands.

Table 47 APM3000A, APM6000A, and APM7000ACommands

Item	Command	Reply	Item	Command	Reply
Move Chuck	A	65	CPU Halt	T
Chuck Up	Z	67 or 73	Trigger Inker	M	69
Chuck Down	D	68	Chuck Home	L	70 or 76

SUMMIT10K

This driver waits for an SRQ for an operation completed. With Summit Software version 2.10, the F10 key enables Remote mode. This prober uses the following settings.

SUSS PA 150, PA 200

The SUSS ProberBench Interface developed by Karl Suss for IC-CAP is provided as a convenience, but is not supported by Agilent Technologies. The prober driver supports all functions described in External Prober User Functions and Internal Prober Functions except prober_spoll(), prober_get_srq(), and prober_wait_srq(). In addition to these IC-CAP functions, you can use the complete ProberBench command set (150 functions) to enhance operation. For information on these functions, refer to the ProberBench User Manual. For information on writing macros to control the prober, refer to Writing a Macro.

The SUSS PA 150 and PA 200 Semiautomatic Probers utilize a Microsoft Windows-based user interface running on an IBM-compatible PC. The IC-CAP environment communicates with the prober via a macro over the IEEE 488 bus.

The required PC IEEE488 control hardware is: IOtech Personal488/AT.

The PC configuration must use the following values for the settings shown; all other settings use default values:

Interface Type:	GP488B
Name:	IEEE
IEEE Bus Address:	22
System Controller:	Off
Time-out (ms):	3000
Interface Bus Address:	02E1
DMA Channel:	None
Interrupt:	None