Testing VLSI products and specifically chips, modules, cards, and boards, is becoming more and more difficult in view of the ever increasing circuit speed, density and complexity of the logic. In the past, testing logic and arrays (also known as memory) was routinely performed on different testers; a first pass on a logic tester followed by a second pass on an array or (memory) tester. Two pass testing, though, is never ideal because it is expensive, cumbersome and time consuming. The advent of arrays embedded in logic brought an additional degree of complexity to testing, mainly because as embedded arrays become commonplace, logic designers were reluctant to take the necessary effort of segregating the logic from the array by assigning independent I/O's to each portion and incorporating in their designs a way of isolating the logic from the array.
Testing arrays differs radically from testing logic. Arrays, being highly structured, require highly regular test vectors. Logic, on the other hand, is more random in nature, and is usually tested by means of heuristic patterns, either deterministic in nature, pseudo-random or even fully random. To ensure adequate testability and fault coverage, certain design constraints, known as `design for testability` were introduced and subsequently extensively used. A good example of a typical design for testability is a scan design and, more particularly, a Level-Sensitive-Scan-Design (LSSD) well known to those familiar with the art, and fully described in U.S. Pat. No. 3,783,254 to E. K. Eichelberger. By constraining a designer to certain design rules, full testability of the product can be guaranteed.
In an LSSD design, data may be entered serially through a scan chain comprised of shift-registers and propagated through combinatorial logic to either another chain of shift registers or to the primary outputs. To facilitate testing embedded arrays, scan chains are used to isolate logic from the array.
It is known to those familiar with the art that embedded arrays necessitate highly regular and structured patterns. These patterns cannot be easily applied to the array inputs through the logic portion of the product unless means for controlling signals at the inputs of the embedded array is enforced through the use of special circuitry such as the above described LSSD shift-register chains.
Typical array testers contain a memory element capable of storing large volumes of test vectors to be applied to the array under test. This is particularly important since arrays may routinely require test vector sequences in the order of N.sup.2, where N is the memory size. Furthermore, since only one test vector can be read out of memory at each step, an array tester is inherently slow, e.g., 100 to 300 Mhz maximum, thus resulting in excessively long testing times.
Testers also commonly include address generating circuitry that provides a sequence of addresses to the memory. Each pin of the tester is additionally provided with electronic circuitry that includes one driver and one receiver per pin, and a plurality of multiplexers to multiplex addresses, data and controls.
Later generation testers have been modified to increase speed, flexibility and versatility. The most noted innovation has been making a tester truly `per-pin` whereby the electronics associated with each pin is self-contained, with all the elements present that provide a complete test to any I/O of the DUT (Device-Under-Test). Thus, each pin may be driven by electronic circuitry having its own pin memory circuit for storing instructions, control circuitry for decoding instructions and for generating next instruction addresses for the pin memory. These and other features are fully described in U.S. Pat. No. 4,931,723 to A. K. Jeffrey, et al.
An important characteristic of a `per-pin` tester design is its unique processing element, commonly referred to as a channel, which is connected to each input or bi-directional driver of the DUT. All the channels in such an architecture run concurrently in a pipelined configuration. Data, addresses, commands, and control signals for the DUT are loaded into the memory associated with each channel prior to running a test. Storing addresses into the channel's memory allows generating any sequence of addresses for a given test. However, this exhausts whatever available memory exists in the channel because of excessive volume.
The need to move large volumes of test data in and out of memory imposes serious limitations to the design of a tester apparatus as well as highly restrictive constraints to its speed. Creating test vectors algorithmically at the tester would clearly obviate the need for such large memories and correspondingly would improve the tester's performance. This would allow the application of data, commands and control sequences to many addresses in the Device-Under-Test (DUT) while keeping only one copy of the sequences stored in the channel. Typically, the algorithmic address generator, usually in the form of a counter, is repeated on each channel. Examples of various algorithmic test generators are found in U.S. Pat. No. 4,807,229 to Tetsuo Tada and in the IBM Technical Disclosure Bulletins, Vol. 31, No. 11 of April 1989, "Algorithmic Random Pattern Generator using Deterministic Seeds", pp. 160-161; in Vol. 32, No. 11, of April 1990, pp. 248-249, "Modified Logic Test Hardware Enhancement"; in Vol. 32, No. 6A, pp. 76-79, "Algorithmic Pattern Generation at the Tester", and in Vol. 30, No. 10, of March 1988, pp. 116-123, "Array Test Pattern Generation Algorithms for a Per-Pin Tester" . The above references commonly provide means for generating test patterns in software by taking a canonical or high-level representation of an array test pattern (e.g, walking or marching 0's and 1's, ripple word or bit, checkerboard, in which 0's and 1's alternate in a regular pattern, etc.) and exploding these patterns into a binary sequence of 0's and 1's. Of particular interest are those called `disturb test`, whereby a Home cell address is selected and every other (i.e., Away) cell location for each Home address is polled to determine whether or not it was disturbed.
In view of the aforementioned limitations presently found in the art, it is an object of the present invention to algorithmically generate test patterns in the tester hardware to test embedded arrays.
It is a further object of the present invention to build an algorithmic test pattern generator, sufficiently simple to be replicated at each pin of a `per-pin` tester.
It is yet another object of the invention to avoid the need of shifting long test sequences into a single LSSD shift register that isolates an array from logic by assigning an LSSD Array Pattern Generator (APG) generator to each tester pin, thus allowing the Device-Under-Test (DUT) to have several short registers.
It is a more particular object of the invention to use incrementing/decrementing counters to algorithmically create an array test pattern.
It is still a more particular object of the invention to select bits in one counter at which incrementing and decrementing will start and end.
It is yet a further object of the invention to transfer the contents of one counter to a second counter, while choosing which bits of the second counter will control the operation of the first counter, thus producing a compact and powerful APG (Array Pattern Generator).
These and other objects are achieved by the use of this present invention which produces a test pattern generator for testing embedded arrays in an integrated circuit, comprising: an integrated circuit having an embedded array thereon; LSSD circuitry for inputting and outputting test data, respectively, to and from the embedded array; and command-driven generators for creating binary test patterns for the embedded arrays.
USPTO Backgrounds
USPTO Backgrounds