Targeting SoC address decoder faults using functional patterns -

Targeting SoC address decoder faults using functional patterns


Even though you have thoroughly verified your SoC design during the development cycle, sometimes critical faults during manufacturing can lead to failure in the field, one of the most serious of which is the address decoder stuck-at fault [1].  This is a critical fault that must be tested for on each and every piece of silicon that needs to pass qualification for an industry standard [2].

Testing of RAM and other memories come under the scope of Design for Test (DFT). It is generally achieved by implementing a number of algorithms which are either part of MBIST (memory built-in self test) delivered by a third party or DFT patterns targeted for particular faults in memory [3]. Conventionally, no special fault detection technique is used for an address decoder as they are assumed to be covered with array testing. Some of earlier MBIST controllers do not support Algos for checking ASOF faults, so our approach is to use a functional tester pattern to catch these faults on silicon.

What ASOF Faults?
Address decoder stuck-at faults are caused by resistive open and capacitive coupling between address lines. As semiconductor process technology moves to lower nodes it becomes one of the more prominent faults in SoCs that must be tested. So in order to qualify a part stuck-at faults should be part of your test program. This fault can only be caught when memories are accessed with addresses that are hamming distance apart. But in core-based patterns it is hard to guarantee that hamming distanced addresses are generated back-to-back because of the instruction pipeline of the core, so and there is always a chance of coverage misses on silicon.

This problem is illustrated in Figure 1 of a NAND gate, and its behavior is shown in Table 1 . The pattern that can detect the stuck-at fault is shown in Figure 2 .

Figure 1: Open NAND Gate

Table 1: Behavior of a regular NAND gate

Figure 2: Stuck-at fault pattern

However, this set of patterns will not screen ADSOF for ‘b’ since the floating output in Figure 1 will retain its 1 state even after applying a 0 input to ‘b’ due to output capacitance C. Detection of this fault requires the output line Z to be discharged with the first pattern, “1, 1”. Therefore, the set of patterns to detect both stuck-at faults and ADSOF are:

This logic forms the basis of our flow to detect ADSOF using functional LRE patterns. The algorithm implemented shown in Table 2 generates addresses which are Hamming distance 1 apart and follow writes and reads as mentioned in Table 1 above. These patterns are then post-processed to run on the ATE tester.

Table 2. Algorithm for ADSOF values Hamming distance-1 apart.

Figure 3: Address Decoder

On the address decoder shown in Figure 3 , it is then necessary to perform following sequence of Write (memory location with low resistive bridge b/w C and B at A7):

     Write C (10110 111) with value 1.
     Write A (00100 111) with value 0.
     Read C (10110 111) , read result will be 1 PASS
     Write C (10110 111) with value 1. {C and B are Hamming distance apart)
     Write B (00110 111) with value 0.
     Read C (10110 111) , read result will be 0 FAIL

So from the above example it is clear that ASOF faults can be found in patterns where memory under test is accessed using addresses that are Hamming distance apart. Since the core has pipeline architecture so it is not possible to generate Hamming distance apart addresses using the core, so we have come up with a way to use direct memory addressing (DMA) to generate Hamming distance addresses.

An algorithm for catching address decoder faults
This algorithm is used to catch address decoder fault using DMA (direct memory accesses) module in an innovative way. A standard configuration is used to detect address decoder stuck-open faults (ADSOF) in RAMs for PPC (Power PC) based designs using the DMA. The DMA contains two features that support an ASOF test:

  1. The source address can be incremented by an arbitrary number (16-bit field). This is used to generate address pairs that are Hamming distance of 1 apart (up to a 64k byte RAM).
  2. If the source transfer port size is less than the destination, the DMA will buffer up source reads until the size of the destination is filled. This feature is used to generate back-to-back reads. For most cases, the optimum transfer size difference is for the source size to be 1/2 of the destination size. This generates two source reads that are a Hamming Distance of 1 apart, followed by a destination write.

There are SoC specific features that may affect the validity of this test.

  1. This test runs most efficiently if errors can be detected by moving data from the MUT to a scratch test address. Either SoC-level error detection or signature analysis (MISR or CRC) is used to actually detect the defects. This test can do direct comparison of the read data, but this makes the test much longer (~10X longer). So please make use of ECC, signature analysis, or write data to an external port whenever feasible.
  2. This test requires that the DMA be the only master connected to the RAM during the back-to-back reads. The CPU is placed into a Wait mode (or infinite loop if the PPC core does not support the Wait instruction) to prevent accesses to the MUT during the test. All other bus masters must be idle. If the code must be run from internal RAM (no cache) and the processor does not support the Wait opcode, then the test may not detect all ADSOF faults.

The algorithm described here can be executed using Core or DMA, depending on the architecture of the SoC. All the functions and tasks needed are built on an already existing testbench environment, reducing chances for incompatibility. The algorithm has been optimized to check only those row and column bits that are not checked by MBIST. Detection of ADSOF using functional tester patterns can be achieved (if the check is missing from MBIST) for needed automotive level quality.

[1] Matthias Klaus, et al., “Tests for Resistive and Capacitive Defects in Address Decoders,” Proc. Asian Test Symposium, 2001, pp. 31-36

[2] L. Dilillo, et al., “New March Elements for Address Decoder Open and Resistive Open Fault Detection in SRAMs”, Journal Integrated Circuits and Systems 2008, pp. 7-12

[3] Powell, T., et al., ”Chasing Subtle Embedded RAM Defects for Nanometer Technologies”, Proc. International Test Conference, 2005, pp. 850-859

Aashish Mittal has been a staff design engineer at Freescale Semiconductor's India Design Centre for over 14 years. He has a Master of Technology degree from Banaras Hindu University. He has worked on multiple SoCs in front-end verification, testbench integration, and verification for testing domain, with his areas of interest being dual core, security, debug, and low power architecture. He can be reached at

Glenn Carson is a Test Engineer in the Automotive Microcontroller Group at Freescale Semiconductor, in Austin, Texas. He has a BSEE in Electrical Engineering from Texas A&M University and a MSEE from the National Technological University (now part of Walden University). He has worked in Test Engineering for over 30 years and most of that time he has been involved in microcontrollers targeted for automotive applications. He can be reached at .

Nitin Goel was a senior design engineer at Freescale Semiconductor India Pvt. Ltd for over 6 years. He graduated from Netaji Subhash Institute Of Technology, Delhi, in 2006. Since then he has worked in front-end verification domain. Along with experience in IP level, SoC level and core verification , he has also worked in tester pattern development and debugging.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.