Introduction

What could possibly be more important to a Test Engineer than the yields that his test programs produce? We all take pride in our work, and our effectiveness is measured by the quality of the product that leaves our tester proceeding to the next level of test. Our jobs also include making sure the program fault isolates properly, that it minimizes false failures, that it runs in an efficient manner, and a myriad of other duties.

The development costs do have a point of diminishing return. If you enjoy a 98% yield at the functional tester after testing your board at ICT, you should study the failures at FCT to determine if you can detect these faults at ICT. But how do you know when your program is completed? You could spend days implementing a test for a part that will never fail again! The FCT failure could be a device from a manufacturer that is being disqualified, and your test would be superfluous. You could even be chasing false failures from functional testing!

This paper will describe means of decreasing the test time and increasing the fault coverage, thereby improving the effectiveness of ICT. Streamlined means of implementing these tests can provide a way to perform this while decreasing the development time.

1.  Design for Testability

Let us start with the design of the board to ensure a proper springboard into a streamlined process of fixture and program development. If the board is designed properly with Design for Testability (DFT) criteria in mind, it can assist in decreasing the test and development times, as well as improving the fault coverage. Non-compliance to these DFT issues can cause latent defects in digital devices due to unnecessary backdriving, or it may cause devices to be untestable. A summary of the key DFT issues are:

(a)		Ensure you have 100% access to all active nodes if possible. This means that any network on the board connecting devices together will have an access point for ICT. Most users will also probe isolated nodes (unused outputs of digital devices, unused pins on connectors, etc.) to provide 100% coverage in shorts. I have seen boards with shorts on them that pass functional testing by having an output shorted to an unused input. This would have caused intermittent problems in the field because it was a short to an unused interrupt input!
(b)		Make the spacing between test probes at least 0.100" as an ideal, 0.075" when possible, and 0.050" as a last resort. Avoid placing devices too close to the edge of the board. Put switches and potentiometers on the component side of the board, not on the solder side! Put bar code labels in places that will not interfere with the test probes. Compliance to these issues will extend the life of the fixture, and make its operation more repeatable.
(c)		Large resistors in parallel with large capacitors will take up test time if they are testable at all. If the large resistor is divided into two series resistors, all devices would be easily and quickly testable. Similarly, load resistors across transformers are usually not testable because of the low impedance of a transformer. Use two series resistors to make the resistor circuit testable.
(d)		Design engineers need to provide pull-up and pull-down resistors in strategic places to ensure digital testability. Reset lines on processors, output enable pins on buffers, clear pins on counters, and other such control circuitry may not be useful to the design of the board, but it is imperative to us! The time to develop a program will be reduced, and the test coverage (and repeatability) of the program will be increased when ICT engineers can manipulate the control pins.

2.  Test Strategic Devices Before Power-Up

Some devices, such as relays and opto isolators, are often easier to test before board power is applied. I like to PGEN them into the program with the ADOF token so they are placed in the Power-Off/Analog section. This provides a way to test devices before board power is applied, since power device testing can be consuming in the test time or in the development time. Devices that I test in this manner are: Power-On-Reset devices (such as the DS1232 and the MC33064), opto couplers and opto isolators, relays, transformers, and voltage regulators. I have documented the tests for transformers and optical devices in previous Applications Papers, so I will use a relay as an example this time. (Refer to my Applications Paper presented at the 1996 TUG for details on implementing these tests.)

Using a 16 pin Dual-Pole / Dual-Throw relay as an example, I would implement the test as shown in the following process. I have a template library for these called R5V_DPDT, R12VDPDT, etc. The test is multiple pages, as follows:

(a)		Test the coil resistance. If it is the wrong value, the wrong relay has been installed, so jump to the next test step, thereby not testing the remainder of the device. (Notice that typical resistances for a relay coil are: 5V: 159?, 12V: 700??; 24V: 1.4K??; 48V: 2.8K??.)
(b)		Test the relay contact to ensure a low resistance on "Normally Closed" contacts, a high resistance on "Normally Open" contacts. Repeat this for dual pole relays.
(c)		Energize the relay with TVSVSV mode, applying the coil voltage across the relay coil (entering the other side of the coil as a Reference Pin), applying a rest voltage on the "Common" pin, and measuring for that test voltage on the "Normally Open" pin. Repeat this on dual pole relays.
(d)		Discharge the energy (with a Discharge Page) from the coil before proceeding.

3.  Testing Switches & Potentiometers in High-Volume Applications

To test time-consuming devices where operator intervention is required (such as a switch or a potentiometer), some users skip the tests or they spend too much time testing them. If these parts never fail, it would not be worth the test time to thoroughly test them. But mechanical devices do fail: switches have a tendency to stick on one position and for adjacent switches to connect together, and potentiometers sometimes have the wrong value loaded. Following are some ideas for testing such parts.

For switches, it is important to toggle each contact on and off to ensure "make" and "break". In piano-style switches, you often have 8 switches in a package, and many users have found it to be important to flip these switches individually to ensure the switches are not stuck together. (If the boards are washed, switches will rust if they get wet, and this becomes a very important step.) However, such thorough testing can be very time consuming. One solution for a very high-volume application is to automate this with robotic arms. Otherwise, you are stuck with a compromised test or with a long test time. A simple means of compromising the test that will give a fast test time and will provide a make and break test (but will not check the switches for individual operation) is to close the switches before the test, verifying the "make" contacts in the Jumper Section. You would follow that test after shorts in the Switch Section with a prompt for the operator to open the switches, and then test for the "break" operation. This way, you are only moving the switch once. This can be optimized for test time with the repeat page routines (built into the "PRE / Option Variables" menu, using a short delay, and a repeat mode of "while failing") since it will automatically proceed with the test when passing. Please notice that shorts tests are compromised when testing in this manner, and that, depending on how the switches are wired, you may be missing shorts with this approach. Extra tests with resistance measurements should be added when this is the case.

For potentiometers and rheostats, many users have found that the common faults are wrong parts because they are often hand-loaded because of their size. I recommend that rheostats be tested when tweaked almost fully open to verify their value. To save test time to minimize operator intervention, I would use wide tolerances. For example, a 10K? rheostat should be tested for 8.5K?? at about???????. I like to test potentiometers in the Discharge section by taking two resistance measurements: from pin 1 to pin 2 (the wiper), and from pin 1 to pin 3. Remember that you can guard pin 3 when testing from pins 1 and 2; you cannot guard pin 2 when testing pins 1 and 3. If these measurements are below your threshold for shorts testing, prompt the operator to tweak the pot. If they are above the shorts testing threshold, these tests are all that would be required. For example, pins 1 and 2 of a 5K? pot could be tested for LL 25? and UL 4.975K? (when shorts tests are at 25?), then test entire pot would be tested from pins 1 and 3 for the 5K?.

Another idea for streamlining the potentiometer and rheostat testing is to tweak the value of potentiometers (and rheostats if you like) to the approximate value needed at functional testing to save test time at that level of testing.

4.  Testing Operational Amplifiers and Voltage Comparitors

I have found that most users test Op Amps by toggling their inputs while measuring the outputs to drive near the power rails. However, this will not detect a difference between an Op Amp (such as an LM393) and a Voltage Comparitor (such as an LM339). If the board uses both devices, it would be common to see these devices interchanged, so it is important to test for it.

A linear test is needed to ensure the correct part is loaded. The test for a Voltage Comparitor will simply drive the input voltages to ensure the voltage on the "+" pins is higher than the "-" pin, which will cause the output to go to the "+" power rail. Then test with the opposite polarity, and the output will go to the "-" power rail.

The test of an Op Amp would be in two parts. First, test its operation to match that of a Voltage Comparitor. Remember that an Op Amp will not drive all the way to the power rails (but will be at least one diode drop below the rails). [For example, for an Op Amp powered to +/- 12V, when the "-" input is driven to a lower voltage than the "+" input, the output will go to a maximum of 11.3V.] Of course, repeat this for the opposite polarity to ensure the Op Amp will drive to both rails.

Secondly, perform a linear test. You will need to drive a test voltage using a series resistor on the input lead and a feedback resistor between the "-" input and the output; these are almost always on the board. Notice that virtual ground is very sensitive to ICT probes which can cause uncontrollable oscillation, and will sometimes require isolation through a fixture relay.

In order to ensure a Voltage Comparitor does not have an Op Amp inadvertently installed, I have placed feedback resistors in the fixture, applied a DC Voltage through a series resistor to ensure the test is NOT linear.

5.  Testing Memory Devices

Most users find that digital testing is much easier than unpowered analog or powered linear testing, so the test coverage is usually good especially when using the Fault Inject tools of the Z18XX. Digital tests are executed fast enough from a test time perspective that abbreviated tests usually do not appreciably help the test time. I will therefore only cover PROMs and RAMs to provide some test ideas for digital testing.

Testing RAMs can be very cumbersome if a full cell check is desired. The test time is fast (usually within a few milliseconds) compared to analog testing, but excessive test patterns can cause undue backdriving. A simple "Walking One" and "Walking Zero" test will detect the manufacturing defects. You will need to write unique patterns into each cell to really verify the proper addressing of the RAM. Many users like the idea of writing the address into the data, then reading it back out. This is very time-consuming from a backdriving standpoint, and can cause latent defects in your boards. You must determine if the extra testing is necessary by studying the failures from the field and from the functional testers to discern if simple "walking" tests would have sufficed.

Most users would test a PROM with Gray Code, applying the several frequencies on the address bus, and merely measuring for CRCs on the data bus. As PROM sizes have increased, we have seen that the 14 frequencies in the Z18XX cannot provide enough address inputs to thoroughly test each cell of the PROM. Let us take the 27C010 OTP as an example, which as 17 address lines. It would take 2 17 (= 130,000) vectors to fully test this PROM. Several options present themselves:

(a)		If you do not have bad PROMs, and you are testing only for manufacturing faults (such as unsoldered pins, wrong PROM, or missing PROM), you can test the PROM with the "Walking" tests like a RAM, thereby testing a 27C010 PROM with only 36 vectors. These vectors would be fired from the VP section, and would simply walk the Ones and Zeros across the address bus. The outputs would be learned.
(b)		If you have bad PROMs so that each cell must be verified, prepare for a long test. Gray Code only lets you test 14 address bits at a time, so you must test this in eight bursts in order to test each cell. Be aware that, even with the minimal clock divisor of unity, the test for one burst is 16 milliseconds; in some circuits this could be a dangerously long backdriving time. The means of implementing this is to apply frequencies F1 - F14 on Address A0 - A13 while latching A14 low, A15 low, and A16 low. Repeat this for A14 high, A15 low, and A16 low. Repeat this again for A14 low, A15 high, and A16 low. Continue to repeat this until all eight combinations for A14, A15 and A16 are used. Notice that this can be done with the Vector Processor, but the backdriving time would be excessive.
(c)		Option (b) can be compromised if it would suffice to test only a portion of the cells. This approach would put frequencies on address bit A0 - A13, latching address bits A14- A16 to a low, and learning the outputs. The second test would put frequencies on address bits A0 - A9 and A14 - A16, latching address bits A10 - A13 to a low, and learning the outputs. This pair of tests will apply active frequencies on all 17 address bits. However, it only tests 1/64th of the total number of cells.

6.  Tips Regarding Test Time

Following are a few ideas for reducing the test time for a board. These can be real cost-savers in the recurring costs at ICT.

(a)		The delay in PRGMVARS is somewhat unnecessary. I have seen some users program a 2,000 millisecond delay there! Teradyne provides this time to give the board time to settle on the test fixture. It is much better to have a test to verify that the right fixture is loaded, that the right board is loaded, and that vacuum is properly applied. Refer to an Applications Note written by this author for TUG '97 that shows how to implement this.
(b)		When generating the power supply tests in the power section, the tester will automatically add a 250 millisecond delay to wait for the power supply to settle. This delay on the first page can be reduced to 50 milliseconds, and the test for the right voltage at the UUT on the second page can be put into a loop using the repeat mode of "while failing". This can easily save half a second for every board tested.
(c)		When testing a large resistor in parallel to a large capacitor (like 1M? in parallel to 1?F), you know you will need a delay to allow the measurement for the resistor to settle. (A superior solution is provided in paragraph (c) in the Design-For-Testability section above to change the design to use two 500K? resistors in series.) Change the test to TVSI, applying about 100?A. This puts the resistor/capacitor in the feedback path of the measurement amplifier of the tester rather than in the input lead. You may be surprised how much better this will consistently measure the resistor without as much delay and without as much oscillation in the measurement.

When testing a large board on an in-circuit tester, we always dread the scenario when the board has more nodes than the tester. Some users have small pin count systems because 99% of their boards are under that threshold. What do you do with that 1%? Or what do you do when you have a tester pin limited to 1,023 nodes, but you are testing a board with 2,200 nodes?

The first and most obvious solution is to purchase more D/R cards or upgrade to a larger tester. However, most managers would reject this costly proposal. Another possible solution would involve building multiple fixtures, but this is not a feasible option for the following reasons:

• Testing with multiple fixtures will never cover shorts.
• If you have a low first-pass yield, you will need to swap fixtures several times to test one board so that you do not power the board without fully testing as much of shorts and of discrete devices as possible.
• The cost is much higher than a wired-or fixture.

The following procedure will show the means of implementing wired-or testing for digital boards. Examples of how this would be implemented with a tester with 1,024 pins and a board with 1,500 nodes will be provided within [brackets].

1.	Make a list of your digital guards. They must have dedicated pins. [I would use high node numbers (like from 1,000 to 1,023) for digital guards.]
2.	Make a list of the different logic levels. If the whole board is CMOS powered to +5V, you have no worries. However if you have an RS232 Driver (such as the 75C188) driving +/-12V, coupled with +5V logic, mingled with a few +3.3V devices, it is obvious that you will need to wire-or only the similar logic families. [Most boards would have only a few nodes at a different logic level from the main +5V lines. You could leave such nodes un-multiplexed by assigning them to nodes 900-999.]
3.	Design your node number assignment scheme as if you have a large number of pins in the tester. If using FabMaster or any other automated system, make the system think you have a very large tester. [In this example, you would probably use test pins 1-24 for power bus measurements, nodes 25-899 for digital testing, nodes 900-999 for non-5V logic families, nodes 1000-1,023 for guards, and nodes 1,025-1,500 for the remainder of the digital nodes. Notice that "Nodes 1,025 - 1,500" are pseudo-nodes that become nodes 25 - 500.]
4.	Perform the node assignment in a way that assigns wired-or pairs to pins that are physically and electrically separated from each other. This will allow for shorts test coverage to be almost 100%. Nodalize the schematic and mark the fixture map with these node numbers. Keep the pins of digital devices in one section. Analog devices would not matter since they are tested without the mask in place (unless you fall into the exception in Step 9). [This is of course the toughest part of all; this can be very tedious; it is also the most crucial step. It is often easier to allow your node assignment algorithm to run its routine, then change the nodes as needed.]
5.	Make sure that your node assignment does not have the outputs of two non-tristateable pins tied together. The outputs of "glue logic" devices such as Gates and Flip Flops should perhaps have their own non-multiplexed node numbers to avoid "wired-or backdriving". [You would typically only have a few of these that could be handled individually.]
6.	If there are too many conflicts among logic families, glue logic devices, passive devices and other considerations, you can build a Mask that will isolate each set rather than testing as wired-or. The use of the Mask will dramatically increase the test time. [Nodes 1 - 1,023 would be tested with "Mask 1"; nodes 1-25, 900-1,023, and 1,025-1,500 would be tested with "Mask 2".]
7.	Edit the IPL.DAT before running PGEN to use actual tester pin numbers rather than the large tester we simulated. [Nodes 1,025 - 1,500 would have to be edited to become nodes 25 - 500.]
8.	If using the Masks, you will have to run PGEN in two different directories to handle the two sets of devices. If not using Masks, you can generate the program into one directory as normal. [The "Mask 1" program would execute the "Mask 2" program as a sub-program. Another means of setting this up is to create a Master program that would call the "Mask 1" and "Mask 2" programs as sub-programs.]
9.	If using a Mask, perform all testing (if possible) without any Mask through power-up. This will ensure that the board is free of shorts and of analog failures. Make sure that all devices tested with a mask use nodes from just one section. [If you have many discrete devices (including resistor packs), it may not be possible to test without a mask, and the node assignment should be designed so that discrete devices are not in parallel through the wired-or.]
10.	If you are suffering many shorts on the board, you can use the Masks to help fault isolate the short. [For example, suppose that +12V uses node 12, and there is a short to node 200. Power nodes are not multiplexed, so we know the short is to +12V. The short could be the devices assigned to 200 or 1,200. Re-run the board with "Mask 1" in place to determine if the short is to 200 or to "1,200".]