The IMS-1000 is a VLSI verification tester capable of driving and sensing test vectors up to 16K words long to several hundred pins on a test device. The system is somewhat flexible in it's ability to trade off drive channels for sense channels, and can be expanded by the purchase of additional resources for the system. The tester operates at speeds up to 20 MHz, has six programmable output modes (NRZ, DNRZ, RZ, R1, RC, RI), and programmable input sample times. With the addition of (expensive) programmable pods the output high and low levels and input sample voltage can be programmed as well.

At the top level of the IMS tester system are the mainframes. Each mainframe contains twelve slots into which various boards are inserted to create either Force or Acquire tester channels. A collection of sixteen Force channels occupies one slot, while the same number of Acquire channels occupies two slots. Throughout the system, these collections of sixteen Force or Acquire channels are referred to as a single Board (capital 'B), even though they may occupy more than one slot in the mainframe. At the beginning of each test, each slot of the two mainframes is interrogated to determine the number of Force and Acquire Boards in the system. These Boards are numbered starting at 0 based on the order in which they're located, starting at the top slot of the master mainframe (the one on the right, as viewed from the front), and ending at the bottom slot of the slave mainframe. Force and Acquire boards are numbered independently.

Force Boards and Acquire Boards both terminate at the end of a six foot cable in a Pod. The pod is where the actual data drivers or receivers are located and is where the connection is made between the Device Under Test (DUT) and the IMS. At the Pod, the sixteen channels of a Board are further divided into two Bytes, named A and B. Within each Byte there are eight data channels and one timing channel. It is possible to employ the timing channel as a data channel, but since it is not usable in four out the the five possible output formats, it is virtually never used and you can forget it even exists (though the software does provide access)

Thus far, only the hardware groupings of the IMS have been described. The IMS has an additional abstract notion of something called Groups. Groups are used to deal with a collection of data channels in a structured way. A data bus of 32 wires for example would all be assigned to the same group so that values could be assigned to it with a eight digit hex number rather than a collection of 32 boolean values. Part of the process of writing a test program is to describe the Groups so that they can be downloaded into the IMS before the test is run. More on this later. The notion of Group carries additional meaning as well as just data structure which necessitates rigorous definition:

This is a very important concept, and a source of endless confusion. It is moderately difficult to change the assignment of DUT pins to Groups (it involves re-wiring a configuration jumper). Therefore, when making group selections it is very important to think about any future need for independent control of DUT pins. For example, if a single tester pin must go into Tri-State mode independently of any other pin on the DUT, then that pin must be assigned to it's own separate Group. If you have ten signals in a Group and you think that some time in the future you may like to delay five of them by 10 nS and the other five by 20 nS then you must assign each collection of five signals to a separate Group. The problem with this is that the minimum tester resource that can be assigned to a Group is a Byte. Thus, in the Tri-State example above, channel 0 of the a Byte would be used to drive the Tri-State pin and the other seven channels would be wasted. If there were two such pins which Tri-Stated always at the same time, then both of these pins could be assigned to the same Byte and only six channels would be wasted. Make sure you understand this or you'll regret it later.

Groups can span both Bytes and Boards. They do not need to be sequentially allocated. So, for example, a single group can utilize resources from Bytes A and B on Board 1, and then skip to Byte B on Board 5.

The Pods contain the necessary electronics to drive or receive pin stimulus from the DUT. The output pin electronics can be programmed to drive in one of six modes:

Delay times vary from 0 to 31uS in 1nS steps. Width times vary from 0 to 31uS in 10nS steps. Sample times vary from 0 to 31uS in 1nS steps.

A hardware setup has been built to connect the IMS to a probe station. This describes the way that it currently works, but it is likely to change. Also, since this part of the system was built in-house, you could build your own if you feel overly constrained by it.

There are several pieces involved in connecting the IMS to a test device on a wafer. Starting at the device, there is the probe card itself which can either be a custom probe card, purchased from an external vendor and custom made for each chip type, or it can be a packaged part probe card. (currently we have only 20-pin DIP and 144 pin PGA, but these are not terribly difficult to make more). Due to the nature of the probe cards that we currently use, the number of pins available on the probe card is limited to 240. This is a fairly hard number.

The probe card plugs into the probe card motherboard. The motherboard provides mechanical support for the probe card, a ribbon cable interface to the IMS, and a decent quality power environment for the DUT. Each pin of the DUT is connected to a stake on the motherboard. Each of these signal stakes is located between a Vdd and Gnd stake. In order to connect power and ground to pins of the DUT it is only necessary to add a push-on jumper between the appropriate pins on the motherboard. Four additional rows of pins are available to wire-wrap to if other voltages are needed. The motherboard contains the necessary bypass capacitors for power supply decoupling.

The other end of the ribbon cables connected to the motherboard are plugged into the IMS verification station. This is just a box which conveniently holds all of the Pods coming from the Force and Acquire Boards in one place. IMS's view of the world is that you wire up your packaged part on the front of this box to do your testing. This has some advantages for doing speed testing for instance, but for wafer testing we only use this box as a rack for the Pods and a place to interface the Pods the the ribbon cable. At some time in the future it would be nice to make a general purpose fixture for speed testing packaged parts on the verification station (volunteers?).

The Pod to ribbon cable mapping is a two step process. A Pod may be plugged into the verification station in one of 24 slots (not to be confused with mainframe slots). These are labeled Left [A..L] and Right [A..L]. The important thing to remember about the slots is that adjacent pairs of slots (AB, CD, EF, etc.) are wired together in the verification station. This allows a Pod containing 16 Force channels to be plugged in adjacent to a Pod containing 16 Acquire channels to make up 16 bi-directional channels. If a Pod is to be Force or Acquire only however, the companion slot must be left empty. It is convenient to find out how other people have assigned Pods to positions in the verification station as many times these assignments are compatible from one chip type to another avoiding the hassle of moving pods around each time a different device is to be tested.

The last step in connecting the IMS to the probe station is the configurator. This is wire-wrap card that connects one data channel on a particular Pod in a particular slot of the verification station to a pin on the probe card. This is a totally random wiring to allow signals which have been defined as adjacent pins in a Group to be wired to any pins on the DUT. The wire list for the configurator is program generated from the data base defined in the next section.

Suppose that you have already simulated your chip from the pads using Rosemary and Rosemary TestProcs (NOT Oracle testing). What additional information is necessary to test the actual part on the IMS? ICTest provides an interface to the IMS that is very close to the Rosemary interface. In fact, Rosemary TestProcs can be used directly to create IMS vectors with no modification. The main effort required is to create the Group and Pin assignments. As any good programmer knows, the best way to start is to look at an existing example.

is a good example. The EU and BIC chips are around also. The first thing to do is to sit down and decide what signals should be collected into Groups. Remember, the more Groups that you use, the more flexible your test setup will be later, but also the more tester resources you consume.

There are two data types that you must be concerned with when setting up Group and Pin assignments. The Group data types looks like this:

The pin assignment data types looks like this:

These types are presented here to give the flavor of what is involved in creating Group and Pin assignments. For details on what all of the types mean see the interface ICTest.mesa

ICTest requires two LISTs of elements, one of TYPE Group and one of TYPE Assignment. These two lists define how all of the IMS resources are allocated. For each pin on the DUT you should create one Assignment RECORD. For each Group you should create one Group record (technical detail: the compiler is very slow about handling long compile time initialized LISTs. The best way to make Group and Assignment LISTs is to make a number of procedure calls that create the list at runtime. See the IFU example cited above).

Each Group is given a unique number which also appears in the pin assignment. The number zero is special. Group zero is reserved for signals like Vdd and Gnd which don't come from the tester, but rather are wired in at the motherboard. Group zero is ignored by the configurator wirelist generator as well.

The directionality of a Group may be force, acquire, or biDirectional. If biDirectional then Pods must be assigned to companion slots.

Once you have defined all of your Groups and pins, the best thing to do is to run a simple TestProc. This will cause ICTest to examine the Group and Assignment LISTs and verify that there are no conflicts.

In a Rosemary TestProc you can assign many different values to a Port drive. ICTest only recognizes a subset of these:

Also in a Rosemary TestProc it is possible to set some elements of a Group to different drive levels, e.g. some elements to `force' and some to `none'. ICTest will complain about this at run time.

In the Assignment list there are two fields for testerHeader and dUTHeader. These are the pin numbers of the two wire-wrap pins on the configurator. When making the initial Assignment list, fill these fields in with 001. Once you have verified and compiled and run the program to generate the list, you can fill in these fields by saying in the Command Tool (substitute your names of course):

This will produce a file named IFU.assignments on the local directory which is an ascii file of assignment statements with the testerHeader and dUTHeader fields filled in in the appropriate manner. Note that the format used is the same format found in IFUChipTest, EU, BIC, etc. so it's a good idea to stick with that format. Once you have done this you can generate a wire list for the configurator by saying:

This will write a file named IFU.wires in the format that Mike Overton likes. Print the wirelist and give it to Mike and he will wrap the board for you.

These are the resources that we have in CSL as of August 20, 1987.