MBIST — Memory Built-In Self-Test
Fault Models · March Algorithms · Repair

Why Memories Need Special Test

By Day 6 you understood ATPG and fault coverage for logic circuits. But every modern SoC contains dozens — sometimes hundreds — of embedded memories: SRAMs for caches, register files, FIFOs, ROM for boot code. These memories are fundamentally different from random logic, and standard scan ATPG fails to test them properly.

The root issue is that ATPG treats embedded memories as black boxes. Scan can observe inputs and outputs of the memory, but the internal bitcell array (often millions of transistors in a dense 6T or 8T bitcell layout) is invisible to scan chains. The bitcells, wordlines, bitlines, sense amplifiers, and address decoders are all untested.

Memory faults also have a completely different physical nature:

• Bitcell faults — a single storage transistor fails to hold charge (stuck-at or transition fault)
• Coupling faults — capacitive or resistive coupling between adjacent bitcells causes one cell write to disturb a neighbor
• Address decoder faults — a wordline driver selects the wrong row, causing the wrong cell to be accessed
• Sense amplifier faults — the differential sense amp reads incorrectly near the threshold

The solution is MBIST — Memory Built-In Self-Test. Rather than relying on external scan chains, a dedicated test controller is synthesized adjacent to each memory instance. This MBIST controller takes over the memory's address, data, and control inputs during test mode, applies a sequence of read/write patterns called a March algorithm, and checks all responses internally. The result is a single pass/fail flag (or a fail address list for repair).

Memory Fault Models

Just as logic DFT uses stuck-at and path-delay fault models, memory testing uses a set of fault models that map directly to physical failure mechanisms in the bitcell array:

Stuck-At Fault (SAF)

A bitcell is permanently stuck at 0 (SAF-0) or stuck at 1 (SAF-1) regardless of what is written to it. Caused by oxide breakdown, metal short to power/ground, or a failed access transistor. Detection: write the opposite value and read back — a mismatch indicates SAF.

Transition Fault (TF)

The cell can hold either value when left alone, but it cannot perform the 0→1 transition (TF-1) or the 1→0 transition (TF-0). Caused by a weak write driver or marginal bitline precharge. Detection: force the specific transition and verify the final state.

Coupling Fault (CF)

Writing to an aggressor cell disturbs the content of a victim cell through capacitive or resistive coupling. Three sub-types exist:

• CFin (Inversion Coupling): the victim cell inverts whenever the aggressor cell transitions. If aggressor goes 0→1, victim flips from 0 to 1 (or 1 to 0).
• CFid (Idempotent Coupling): the victim is forced to a fixed value (0 or 1) whenever the aggressor transitions, regardless of victim's prior value.
• CFst (State Coupling): the victim is disturbed only when the aggressor is in a specific state (e.g., aggressor=1 forces victim=0). Hardest to detect — requires March LR.

Address Fault (AF)

The address decoder maps address A to the wrong physical row or column. Two cells may share the same address (aliasing) or a cell may be unreachable. Detected by writing unique patterns per address and verifying that reading the same address returns the written value, not a neighbor's value.

Read Destructive Fault (RDF)

A single read operation destroys the cell's content — the sense amplifier read current discharges the storage node below the switching threshold. Rare in modern designs but exists in aggressive technology nodes. Detection: read a cell and immediately read it again — the second read must return the same value.

March Algorithm Basics

A March test is a structured sequence of memory operations that systematically exercises every cell in every address order needed to detect the target fault models. The notation is standardized and compact.

A March test consists of a sequence of March elements. Each March element has the form:

Where:

• ↑ = ascending address order (address 0, 1, 2, ..., N-1)
• ↓ = descending address order (address N-1, N-2, ..., 0)
• ⇕ = either direction (used in some advanced algorithms)

Operations within each March element are applied to every address in the specified order before moving to the next March element:

The complexity of a March test is measured in the number of memory operations performed, expressed as a multiple of N (the number of cells). Each operation (read or write at one address) counts as 1. A complexity of 10N means 10 operations per cell — a 1 Mbit memory requires 10 million operations.

March C− Algorithm

March C− is the most widely used MBIST algorithm in industry. It was derived from the original March C algorithm by removing one March element that was proven redundant, reducing complexity from 12N to 10N while retaining the same fault coverage. The minus sign (−) in the name denotes this removal.

The complete March C− sequence has 6 March elements:

Complexity: 10N. Count the operations: M0=1N, M1=2N, M2=2N, M3=2N, M4=2N, M5=1N → total 10N.

Fault coverage of March C−:

• SAF (Stuck-At Faults) — Yes
• TF (Transition Faults) — Yes
• CFin (Inversion Coupling) — Yes
• CFid (Idempotent Coupling) — Yes
• AF (Address Faults) — Yes (partial)
• CFst (State Coupling) — No — need March LR

March LR Algorithm

March LR was proposed to detect state coupling faults (CFst) that March C− cannot catch. A CFst fault only manifests when the aggressor cell is in a specific state — for example, victim is disturbed only when aggressor=1. March C− misses this because it always transitions the aggressor before reading the victim. March LR uses a different traversal pattern that keeps the aggressor static while reading the victim.

Complexity: 14N operations. The additional 4N overhead vs March C− buys CFst detection.

When to choose March LR over March C−: Use March LR when your technology node or memory compiler characterization data shows CFst faults — common in very dense 6T SRAM bitcells at 7 nm and below where inter-cell coupling is high. For most 28 nm and older designs, March C− is sufficient. The test time cost of 14N vs 10N is roughly 40% longer for the MBIST phase.

MBIST Controller Architecture

An MBIST controller is a dedicated RTL block synthesized alongside the memory. In test mode, it takes over the memory's address and data buses and runs the March algorithm autonomously. A typical MBIST controller consists of four sub-modules:

• Address Generator: Counts addresses in ascending or descending order. For March C−, it must support both directions and know when to reverse.
• Data Generator / Background Pattern Generator: Generates the write data (w0 or w1) for each March element and the expected read data (r0 or r1) for comparison.
• March FSM Controller: Sequences through the March elements, controlling address direction, data pattern, read/write mode, and clock count.
• Response Analyzer / Comparator: Compares memory read output against expected data. Records fail addresses for repair analysis.

MBIST FSM States

The March FSM inside the MBIST controller steps through these states:

Redundancy and Repair Analysis

A key insight of modern SRAM design is that no memory is manufactured perfect at advanced nodes. To compensate, foundries add spare rows and columns to every SRAM. A 256-row SRAM might have 260 physical rows — 4 are spares. If up to 4 rows have faults, the memory can be repaired by activating spare rows and deactivating the faulty ones.

The repair flow has two phases:

1. Fault Detection (MBIST): Run the March algorithm. Record all failing (address, bit) pairs in a Fail Address Register (FAR). This gives a map of defective cells.
2. Repair Analysis: An algorithm (often run on ATE or by BISR logic on-chip) determines the minimum set of spare rows/columns to activate to cover all failing cells. This is a set-cover optimization problem.

BISR — Built-In Self-Repair

Traditional repair analysis runs off-chip on the ATE, which is slow and requires shipping fail data to ATE software. BISR (Built-In Self-Repair) embeds the repair analysis logic on-chip alongside the MBIST controller. After MBIST completes, the BISR block:

1. Reads the fail address log from the FAR
2. Runs the repair algorithm to compute the optimal spare row/column mapping
3. Programs the e-fuse (electrically programmable fuse) array that controls the redundancy row/column decoders
4. Verifies the repair by re-running MBIST — pass/fail is checked again

E-fuse programming is a one-time operation using a high-current pulse. After programming, the SRAM's address decoder permanently redirects accesses to faulty rows through the spare rows. The fuses are read at power-up to reconstruct the repair mapping.

MBIST Integration in SoC

A modern SoC may contain 50 to 500 separate embedded memories. Instantiating one MBIST controller per memory would consume enormous area. Modern MBIST integration uses a hierarchical approach:

IEEE P1500 Wrapper

IEEE P1500 (CTLW — Core Test Language Wrapper) defines a standard interface for wrapping IP blocks — including memories — so they can be accessed via a common test infrastructure. The P1500 wrapper provides: a serial scan interface (WSI/WSO), a parallel interface for fast data access, and standardized control signals (ShiftWR, CaptureWR, UpdateWR). MBIST controllers connect to the P1500 wrapper to receive test enable signals and report results.

Hierarchical MBIST

A top-level MBIST controller fans out test signals to multiple sub-controllers. Memories can be tested in parallel (faster, but more power) or in series (lower power, longer time). A JTAG interface at the top of the hierarchy allows the test engineer to select which memories to test, observe fail addresses, and trigger repair.

Frequently Asked Questions