How signature testers work:
A signature tester can generate a large sequence of pseudo-random test vectors. Some signature testers have several such sequences to choose from. One sequence is run against the device under test, and the outputs are combined in a signature word. If the signature matches one of the previously determined "correct" signatures for this device, the device passes. Otherwise it fails. The tester is programmed by taking several "known good" devices, running them to compute their signatures, and entering their signatures into the "good signature list". Please don't ask how you are supposed to know that these initial devices are "known good" before running them on the tester.
How stored pattern testers work:
A stored pattern tester applies a user-specified set of vectors, typically a few hundred to a few thousand for PLDs. These vectors specify both input and output states. If all the output states from the device match the output states in the test vectors, the device passes. The input vectors are typically created manually or with automatic test generation software, and then simulated to determine the output states. ACUGEN® Software's ATGEN® test generators will also fault grade the vectors and report the fault detection percentage. Vectors produced by ATGEN software are free of races, I/O conflicts, and initialization problems.
Initialization problems with signature testers:
Some PLD designs are difficult to initialize. For example, let's consider a 10-input PLD that can be initialized if all inputs are 1001110101 for 5 clocks in a row. The probability of a random number sequence having 1001110101 in a particular vector is 1 in 1,024. The probablility of getting this vector 5 times in a row starting on vector one is roughly 1 in 1,000,000,000,000,000. The probablility of getting this vector 5 times in a row starting on any vector in a 10,000,000 vector sequence is roughly 1 in 100,000,000.
A signature tester often can run an initializion vector sequence prior to starting the signature collection sequence. If this initialization sequence does not reliably initialize the device, then the final signature will depend on the starting state. This can be dealt with by storing multiple "correct" signatures -- one for each possible initialization state. If you are testing a 10-bit state machine, there could be 1024 different powerup states, which means you would need 1024 different "correct" signatures. Most people don't have the patience to collect all of these. If there are any "correct" signatures not on the list, the tester may fail good parts, and parts that pass one day at one temperature might fail under other conditions. Parts from one vendor might pass, and parts from another vendor might fail.
One solution to the initialization problem is for the signature tester to use preload or other supervoltage technique to force an initial state. The main problem with this approach is it limits your second-sourcing options when buying devices, since each vendor has its own way for dealing with supervoltages.
Race problems with signature testers:
Signature testers apply a long sequence of vectors without knowing anything about the logic design inside the PLD. If the PLD has a memory element built by feedback around a combinatorial pin, or if it has programmable clock and/or reset lines, then the vector sequence is likely to cause races. A race is caused when the tester changes two inputs to a memory element close together, and the order of the pin changes is important to the device (e.g. clock should change before data). If the device sees one input change first, it will give one answer. If it sees the other input change first, the output states will be different. The outcome of the race will depend on tester skew, temperature, chip vendor and chip lot purchased. You could get around this problem by running a large number of "known good" devices and adding their signatures to the correct signature list. If you omit any of the "correct" signatures, you will experience failures on good devices.
I/O contention problems with signature testers:
Since the signature tester does not know the internal logic in the device, it does not know which pins are inputs and which are outputs at any given time. PLDs typically have many bidirectional pins. The signature tester presumably gets around this problem by weakly driving all bidirectional pins on all vectors. Depending on the characteristics of the device under test, and the strength and voltage of the tester drivers, this I/O contention could affect the behavior of the device under test.
Manufacturing integration problems with signature testers:
The vectors used on the signature tester cannot be used on other testers, such as an in-circuit board tester. In-circuit board testers generally use stored patterns. If your board test operation discovers a failure that was missed during testing on the signature tester, it is not possible to add a few hand-crafted vectors to the signature test in order to catch the missing fault. On a stored pattern tester, you can add a few more vectors and improve the test based on experience from board test.
Fault coverage unknown when using signature testers:
Manufacturers of high volume complex electronics and military manufacturers need to know the fault coverage of their tests. It is not enough to say "It must be good because we used X-zillion pseudo-random vectors". These manufacturers need to know what the coverage is, and what faults were missed and need further testing. Without this fault coverage measurement and reporting, manufacturing quality cannot be reliably and methodically improved.