DFT March Algorithm? Checkerboard 2

5. Why March seems intuitive from a memory structure perspective

5.1 How to Access

SRAM Consider a bank:

• Select a specific row (wordline) with the address bus
• Read or write the value of a cell through the bitline associated with that row
• Can only control "one address" at a time

So the basic unit of test is naturally this.

"Select one address → perform a read/write sequence → move to the next address"

This flow itself overlaps almost 1:1 with the March element definition.

5.2 How do you catch an address decoder fault?

For example, at an address:

• Decoder fault causes two rows to light up at the same time.
• At this address, w1 causes the intended cell to be 1, as well as the cell in the neighboring row.

Now, at another address:

• We expect the neighboring cell to be r0, but it reads 1.

If we iterate over r0, r1, going up and down several times like March C-, we will surely read at some point the "unintended cell turned on together and overwrote" value.

This is the mechanism by which March C- detects Address decoder fault.

5.3 How to catch a coupling fault:

Coupling fault is the following situation.

A fault in which the value of a neighbor cell (victim) is not changed or maintained when a specific operation (write, toggle) is performed on the aggressor cell

March C- is:

• immediately after doing w1 to any cell
• the pattern of checking its neighbor cell with r0 or r1 is repeated multiple times, reversing the up/down direction.

In the process:

• In order to find "faults that are only revealed when a neighboring cell's pattern is in a certain state," we force various relative orderings.
• This takes a little more time than simply writing/reading the Checkerboard pattern once, but it gives you much higher fault coverage.
• Now, let's plug in the Checkerboard that we often hear about in practice.
• Let's start with a one-line definition.
• In bitwise terms:
  • Pattern A: 0x55... (...0101 0101)
  • Pattern B: 0xAA... (...1010 1010)
• By address, this is usually:
  • Even address → 0x5555_5555
  • Odd address → 0xAAAA_AAAA
• Or you can reverse it, so that the 0s and 1s alternate like a chessboard both horizontally (bitwise) and vertically (addresswise).
• The opposite pattern is called Inverse-checkerboard.
• All-0, All-1 patterns are of course important.
  • w0 → r0, w1 → r1 is enough to cover Stuck-at fault.
  • Transition fault is also covered to some extent.
• The problem is Interaction between neighboring cells.
  • Short/bridge between bitline/wordline
  • Coupling fault
  • Neighborhood pattern sensitive fault (NPSF)
• These faults are often only visible in the following situations.
  • When two cells have different values (0/1)
  • When the neighborhood has a specific pattern (e.g. 010/101)
• For example, if two cells are weakly shorted:
  • If they are both 0, the short may not be noticeable because it is 0, and the value may be skewed because current flows only when one is 0 and the other is 1.
• So, from a test perspective:
• The simplest way to do that is with the Checkerboard pattern.
• Here's where it gets confusing.
  • March algorithm =
    ↑, ↓ + (r0, w1, r1, w0 ...) =
    A sequence of operations
  • Checkerboard =
    The data background
• In other words, it's easier to look at the structure like this.
  1. Set the data background to one of solid 0 / solid 1 / checkerboard / inverse-checkerboard
  2. Execute the March algorithm sequence in that state
• For example:
  • Step 1: Fill the entire memory with Checkerboard.
  • Step 2: Perform the ↑(rX, wY) element of March C- while in that state.
  • Step 3: Switch to Inverse-checkerboard and march again.
• This is the kind of configuration you often see in MBIST tool scripts.
• We have defined the Algorithm and Background orthogonally, and the combination improves fault coverage.
• In the actual product specification, it looks something like this.
  • Consumer SoC:
    • March C- @ solid 0/1
    • Add a short checkerboard sequence if needed
  • Automotive / Server-class SoC:
    • March C- @ solid 0/1
    • March C- @ checkerboard / inverse-checkerboard
    • Add March SS, NPSF-oriented algorithms to meet diagnostic coverage targets.
• Now, finally, let's summarize "When is this test vector/algorithm determined in the design flow?".ATPG vector here.
• In the real world, the process of selecting an algorithm can usually be summarized as follows.
  1. Product nature
     • Consumer electronics SoC → "Moderate quality + short test time"
     • Automotive / Safety-critical → "Very high reliability + accept longer test time"
  2. Target DPPM/PPM, Standard requirements
     • ISO 26262 diagnostic coverage
     • Foundry / customer coverage guideline
  3. Memory characteristics
     • Single-port / Dual-port / Multi-port SRAM
     • Register file, CAM, ROM, eDRAM, eFlash, etc.
     • With or without bitcell structure, redundancy, ECC
     • E.g: eFlash/eFuse/NVM includes program/erase/retention test
     • Multi-port SRAM uses March variant with read/write combinations between ports for port interaction faults
• In practice, Memory compiler / IP vendor often comes with a recommended March set.
• As a DFT engineer, you take this and
  • check if it meets your company standards / customer requirements
    • Example) March C- + March LA + Checkerboard
    • DFT engineers on new projects use these as defaults, and only tune for unusual memory (eFlash, special SRAM, etc.)
  1. Logic tests and memory tests are different in philosophy:
     • Logic: scan + ATPG, gate-level fault-focused
     • Memory: address-by-address sequential access, cell/neighbor/decoder fault-focused
  2. March algorithm is a test that repeats a read/write sequence by marching through addresses.
     • The combination of direction (↑/↓) + operation (r0/r1/w0/w1) is the key
  3. The basic concept is March X, and the actual practice is based on March C-.
  4. Checkerboard is not an algorithm, but a background.
     • March C- @ solid 0/1 for the cell itself, and
     • March C- @ checkerboard/inverse-checkerboard for the neighbor-interaction.
  5. Algorithm selection is determined by tool options in the MBIST insertion step.
     • You don't just read a paper and pick a pretty March and put it on later when creating vectors,
     • It is determined at the time of DFT architecture / MBIST insertion by looking at test requirements, memory characteristics, and test time.

"This SRAM macro achieves XX% fault coverage based on March C- + Checkerboard"

Test requirement + Memory characteristics + Test time(ATE cost) + Tool/Library defaults

7.1 Algorithm Selection Criteria

7. When and how is March / Checkerboard determined from MBIST perspective?"

Algorithm: March C-
Background: solid 0/1, checkerboard, inverse-checkerboard

6.3 Relationship between Checkerboard and March

We want to create a situation where "neighboring cells always have opposite values", so that we can
stimulate interference between bitlines/cells/wordlines as much as possible.

6.2 Why Checkerboard? (Can't it be All-0/All-1?)

Checkerboard pattern = a data background created so that memory cells are always opposite in value to their neighbors, such as
01010101... / 10101010....

6.1 What is the Checkerboard pattern:

6. Checkerboard Background and March Algorithm

and if not, customize it by adding more March elements, adding backgrounds, etc.Additionally, many companies have a standard set of MBIST algorithms at the BU / company level:In practice, it is rare for individual engineers to design March algorithms from scratch, and standard templates + some customization is more the norm.

요약: Good points for DFT/ATPG engineers to remember

To summarize, as a DFT/ATPG engineer, the following points are useful to have in your head.With this knowledge, you'll have a better idea of how to control the DFT team in chip design meetings, and you'll be much more comfortable when reading MBIST specs or foundry guidelines.And when the time comes to design your own custom March + background, this frame will be a good starting point.