Embedded EE Array Grows a BISTy Core

Embedded EE Array Grows a BISTy Core
By Clifford R. Warren, Integrated System Design
March 1, 2002 (12:29 p.m. EST)
URL: http://www.eetimes.com/story/OEG20020227S0053

MI Semiconductor has developed for its smaller-geometry processes several types of nonvolatile memory macrocells, including a nonvolatile latch for situations that require a very small amount of nonvolatile memory; a serial array; and a full EE array with cells organized in rows and columns, much like a typical SRAM. A special "no-added-fab-steps" technique allows this to be done in a low-cost manner. Electrically erasable memory technology holds several advantages over flash memory when embedded in an ASIC. While flash memory has a higher density, the added processing step and lowered reliability limit its use in ASIC designs. Typical SRAM and DRAM designs can have millions of bits, and the algorithms used to test them are commonly called "March tests." However, the long programming times of an EE array severely limit the use of these tests. These nonvolatile memory devices require high voltages (around 20 V) and long programming times to write data t o the core. This can be on the order of 10 milliseconds. If we assume that the typical write time to an SRAM is on the order of 10 nanoseconds, then the program times for the array are 1 million times longer. The length of this programming time requires a new approach to test.

As the EE array is embedded into a highly customized chip, test becomes an issue that must be dealt with. When an embedded macrocell is used, the inputs and outputs of the cell are likely to be buried deeply within the chip. In cases like these, built-in self-test is used to test these structures, much as BIST is the technology of choice to test embedded SRAM and DRAM.

This article presents a "distributed-test" approach that tests several portions of the array separately. For example, we will test the row address decoders, column address decoders and control circuitry without using programming steps. When writing to the core, we will make use of several programming modes that allow us to program large portions of the array in ju st one programming step. As in most good approaches to test, the capability to test begins with the design of the device to be tested.

Design built in
The EE array has a 4-bit mode selector. These modes are summarized in Table 1. Several of the modes have been created specifically to aid in the testing of the array. For example, modes 6 and 7, "Read Test ROM Rows" and "Read Test ROM Columns," are provided to enable quick testing of the address circuitry, large portions of the control circuitry and of the sense amps. The "even/odd page write and erase" and "block write and erase" functions will also be used to aid testing. These special functions are critical to achieving an efficient test.

The array allows for independent testing of the data latches (scratchpad RAM) separately from the core. In the BIST, the data latches are completely verified before processing to the more lengthy tests of the core.

One page at a time
The AMIS 8Kx8 EE array is arranged into 256 rows and 256 columns. Each row is referred to as a "page," and in normal use the array is written to one page at a time. The array macro includes a 32 x 8 scratch RAM (256 bits) that can be written to like a typical SRAM, and this data can then be programmed into one page of the array.

But in addition to the 256 rows and 256 columns, this design includes an extra four rows (two on the top, two on the bottom) and four columns (two on each side) of ROM (see Fig. 1). This ROM is used to test the row and column addressing. By carefully selecting the data that is stored in these ROMs, and using the existing row and column address decoding to select this data, we can determine the correctness of the row and column circuitry. Of course, since this is a ROM, this test is now performed without the need for lengthy program cycles. The ROM can be tested with the BIST method, by using typical ROM BIST techniques.

The 8Kx8 array makes use of a 32 x 8 s cratchpad RAM. This 256-bit RAM can be written to at high speed, like a normal SRAM. In normal operation, the user would write data to this RAM, then use a lengthy programming step to write a page (a 256-bit row) to the array. The next step in our strategy is to verify this small RAM.

We accomplish this with our BIST approach by writing a pattern and reading it by using normal RAM BIST techniques. Note that the mode selection of the array macro allows this-that is, it allows one to read from the latch-based RAM directly. Thus, we write and read checkerboard and inverse-checkerboard patterns from the RAM.

Now, with addressing tests complete and the latch-based RAM tests complete, we turn our attention to the array core. Again, the following special modes to aid in testing are built into the EE array:

Block erase, which resets the entire array to a logic 1. All bits in the core are set to 1 after this step.

Block writ e, which writes the data in the latch-based RAM to all the pages, not just one.

Even/odd page write, which writes the data in the latches to all the even or all of the odd pages, based on the value of one of the address bits.

With the help of these modes, we can proceed with a test of the core. The following is an example of a test sequence:

Do a block erase, then read the entire array. (In this case, this is 8k words of 8 bits each.) This step checks that all bits can be set to 1 and are not stuck at 0. It also checks the block-erase function.
Write all zeros to the data latches, and do a block write. Read the array, checking for all zeros. This checks that the core can be set to 0 and is not stuck at 1. Also, this checks that each cell can make a 1-to-0 transition.
Write all ones to the data latches and do a block write. Read the array. This ensures that the cells can do a 0-to-1 transition.
Now, we have an indication that the basic core cells are functioni ng as intended. We should do a test of the coupling between cells. This could be accomplished, to some degree, by some sort of checkerboard test on the core. Such a test must be limited in relation to a true March test because of the long programming times previously mentioned. But we can take advantage of the even/odd page write mode to quickly create a checkerboard pattern in the array:
Write a "10101010 . . ." pattern into the latch-based RAM, and do a program of the odd-numbered rows.
Write a "01010101 . . ." pattern into the RAM and do a program of the even rows. A checkerboard pattern is now in the array, with only two programming steps.
Read and check the contents.
Do a block erase. Repeat steps four, five and six, but create the inverse checkerboard pattern.

As one can see, the key to an efficient BIST test of an EE array is in the design of the array, and in working toward a distributed test. By making use of special test ROM, and also special programming mod es that allow a lot of testing to take place, we can minimize the number of time-consuming programming steps. It is then possible to use typical RAM and ROM BIST techniques to create a BIST approach that does a fairly extensive test while minimizing the number of time-consuming programming steps. As an example, implementing the steps described here would require only eight programming steps.

BIST EE array
As mentioned already, these test techniques provide for the ability to create a built-in self-test around the array (see Fig. 2). The BIST test consists of a BIST controller, which supplies the test vectors and evaluates the output, and a mux that switches the array inputs between regular mode and BIST mode.

Five basic signals are important in the implementation of the EE array BIST: test mode, bist_clk, done, good and sig_out. If "test mode" is high, then the array is in BIST mode and is controlled by the BIST cont roller. The "good" output is an indicator of the status of the test, throughout the test and at the end, for everything except the ROM checking, which must be done by signature analysis.

The "sig_out" signal is the result of reading the test ROM and doing data compression (signature analysis), and must be checked by the automated test equipment at the end of the test. The "done" output goes high when the BIST test is complete.

In some cases it may make sense to do the ROM signature checking within the BIST test and eliminate the "sig_out" signal. This can be done by checking the result of the signature to a known constant, and combining that result with the "good" signal output. If the user is confident that the ROM code will not change, this is a safe course to take.

The "bist_clk" input is a free-running clock. The speed of this clock must be set precisely, to enable adequate programming times. That is, during programming steps, which are on the order of 10 ms, the BIST goes through a counter w hile waiting for the program to occur. Of course, the time that this step takes is dependent on the speed of bist_clk. For the 8k x 8 array in the 0.5-micron process, at 5 V, the frequency needed for bist_clk is 6.5 MHz.

The array makes use of an on-chip VPP generator (a charge pump) to generate the ~20 volts needed for programming. Without the BIST approach, this VPP generator is not completely necessary (the 20 V could come from off-chip), but with BIST it is needed.

The VPP generator allows for the generation of the 20 V by way of a logic-level signal. As it is necessary for the BIST to control all of the inputs to the device under test, the inclusion of the VPP generator is required when the BIST is used.

---
Clifford R. Warren, a design-for-test engineer at AMI Semiconductor (Pocatello, Idaho), graduated from Utah University in 1990 with a BSEE. His currentresponsibilities include memory BIST and design-for-testability strategies.