Test memories at-speed with a slow clock

By Tessent Solutions

By Martin Keim, Mentor Graphics

Most memory tests don’t depend on the high-speed clock


Recently, I was involved in supporting an MBIST (memory built-in self-test) user. Because of an error in the design, the engineer couldn’t run a memory test because the high-speed system clock wasn’t available. In this case, only the relatively slow test clock was available. Of course, the user was very concerned about the quality of the memory test and was even more concerned about the potential increased DPPM (defective parts per million) number of his product. Fortunately, most memory tests aren’t dependent on the high-speed clock signal.


Using a slow-speed clock, the chance of detecting memory defects reduces very little, which results in slightly higher DPPM levels. Whether this higher DPPM level is significant for the product depends more on the product’s application than on the test. For automotive or medical products, even the slightest increase in DPPM is unacceptable, but the same DPPM increase for low-cost consumer electronics might very well be within the contractual obligations.


The ability of modern memories to self-time is at the core of the mystery. Self-timing is the ability to execute a read or write operation at a certain speed without dependency on an external clock stimuli. The time starts when a change of certain memory control input ports signal the start of a read or write operation. The time then stops when the operation is complete.


There are two important paths in the memory that determine the test: the path the data needs to take and the self-timing path. The purpose of the self-timing path is to always produce the same delay, within margins, and then trigger the sensing of the data coming out of the memory array. Together, these paths set the speed at which a system’s memory operates reliably.


To be precise for the context here, synchronous, embedded SRAM (Static Random Access Memory), used in today’s microelectronics, are virtually all self-timed. Figure 1 depicts a self-timed memory. The blocks and gates shaded gray are the key components of the self-timing feature. The delay through the Model Row and Column Decode logic determines how long the write drivers are turned on during a write operation and when the latches should capture the output of the sense amplifiers during a read operation, after the occurrence of a rising clock edge. Once the operation is complete, the address precoders are reset and the bit lines are precharged in preparation for the next memory access.

MK_Test Memories_Fig 1

Figure 1. Diagram of a self-timed memory.


Memory test algorithms, like the so-called “Serial March” algorithm, are essentially a very specific sequence of writing to and reading from memory cells. For example, such a memory test algorithm may write a logic 1 into cell “a,” then write a logic 0 into cell “b.” If everything is OK, reading from cell “a” should result in a 1. Reading a 0 indicates a defect.


If the time that a read or write operation takes depends only on the memory itself, why do we need a high-speed clock in the first place? The speed of the clock becomes important for the MBIST logic itself. That is, it determines the speed at which the test logic can fire off these read and write commands at consecutive clock cycles towards the memory. That creates a specific sequence of operations, which forms the memory-test algorithm.


Based on this information, let’s analyze the quality implications for testing a memory through MBIST running off a slow clock and then for running off a fast clock. With a slow clock, you have to look out for defects that require consecutive read/write operations fired off quickly; those defects aren’t detectable by MBIST when using a slow clock. Table 1 shows a list of typical defect types and the expected coverage with a slow clock. Most defects are very well covered thanks to the memory’s self-timing.

MK-Memories Test_Table

Table 1. Defect coverage of the “SMarchCHKBcil” Algorithm under slow-speed test clock assumption.


Look at two examples from the Table. (1) A Dynamic Coupling defect is a defect where writing a value 0 to one cell forces another cell to assume a 0 as well (analogously for 1). This defect doesn’t depend on how quickly the read follows the write. Thus, this type of defect is fully detectable. (2) A Write Recovery fault occurs when a value is read from a cell just after the opposite value has been written to a cell (along the same column and the bitline precharge has not been performed correctly). Obviously, the read operation must immediately follow the write operation. Therefore, Write Recovery faults aren’t detectable using MBIST off a slow clock.


You might have noticed that the entire argument hinges off the memory’s self-timing aspect. What if this self-timing logic itself is defective, such that the speed of the memory is reduced only a little, not enough to cause a catastrophic test outcome of the memory? There are three ways of answering the question. The first involves looking at the statistical defect distribution. Given the size and density of the memory array itself, the relative probability of a defect with exactly these properties in the self-timing logic is very, very small.


The second answer is that you may be able to place two edges of the slow test clock so close to each other that you effectively get an at-speed clock effect lasting exactly two pulses. This will give you some confidence that the self-timing logic is operational, but the availability of this solution depends on the capabilities of the ATE (Automated Test Equipment).


Lastly, if the memory has such a speed-reducing global defect, even the simplest functional test will uncover its presence. So, we are pretty well covered at this end as well.


Special thanks to Dr. Benoit Nadeau-Dostie, Chief Architect at Mentor Graphics Corporation, for his contribution and discussion.


LinkedIn Button

Liked this article? Then try this –

White Paper: A Guide to Power-Aware Memory Repair


This article was originally published on

Leave a Reply

This article first appeared on the Siemens Digital Industries Software blog at