DFT · Chapter 8 · Memory BIST (MBIST)
March Algorithms
March tests are the core algorithms that memory BIST uses to test every cell. A March test is a sequence of March elements, and each element applies read and write operations to every cell in a set address order, ascending, descending, or either direction. A classic example is March C-minus, which uses six elements and ten operations per cell, so it scales as ten times the memory size and stays linear rather than exhaustive. Each element earns its place: reading and writing both zero and one catches stuck-at and transition faults, sweeping up and down with read-after-write catches coupling and decoder faults, and a pause element catches retention. The key idea is that March tests are algorithmic. The on-chip controller generates them instead of storing millions of patterns, so test data is tiny and the test runs at speed.
Intermediate13 min readDFTMarch TestMarch C-CouplingAlgorithmic Test
Chapter 8 · Section 8.3 · Memory BIST (MBIST)
Project thread — March C- is the algorithm the mini-SoC memory's MBIST runs (8.6); this lesson explains its elements and what each detects.
1. Why Should I Learn This?
March tests are the MBIST algorithm — and understanding their elements is understanding how memories are actually tested.
- A March test = a sequence of elements, each a sequence of r/w ops over every cell in an address order.
- March C- = 10N ops (6 elements) — linear, scalable; MATS+ (5N) weaker, March SS longer/stronger.
- ⇑/⇓ read-after-write catches coupling/decoder; a pause catches retention.
- March is algorithmic — generated on-chip, not stored → tiny test data, at-speed.
2. Real Silicon Story — the short March that missed coupling
A team chose a short March test (MATS+, ~5N) to save test time on a memory-heavy SoC. It passed, and they shipped. Then field failures traced to coupling faults — writes to one cell disturbing a neighbor.
The short algorithm was the cause. MATS+ covers stuck-at and some transition faults, but it lacks the up-and-down read-after-write structure that coupling detection requires — you need to sweep the array in both address orders so that either cell can be the aggressor, and read an already-verified cell after a neighbor's write. MATS+ doesn't do enough of that, so coupling faults passed. The test wasn't broken; it was too weak for the fault classes present.
The fix was to move to a stronger March — March C- (10N) or March SS — that covers coupling (and decoder), accepting the modest extra test time (still linear). Lesson: March tests trade coverage for length, and a too-short algorithm misses coupling/retention; match the March strength to the fault classes (8.2), not to the shortest runtime.
3. Factory Perspective — March tests through each lens
- What the test engineer sees: the March algorithm chosen (MATS+/C-/SS…), its length (N-multiple → test time), and the fault classes it covers — a coverage vs test-time dial.
- What the yield engineer sees: that a failing March element/address localizes the fault class and cell — feeding diagnosis and repair (8.5).
- What the RTL/DV / memory engineer sees: that the memory's fault classes (coupling from adjacency, retention from process) dictate which March is needed — a weak one is an escape risk.
- What management cares about: that March is algorithmic (tiny test data, at-speed) — cheap test data volume — but the algorithm choice is a coverage/DPPM vs test-time trade (1.4/1.5).
4. Concept — March elements, complexity, and coverage
Anatomy of a March test:
- A March test = an ordered list of March elements.
- A March element = an address order (⇑ up / ⇓ down / ⇕ either) + a sequence of operations (r0, r1, w0, w1) applied to every cell before moving to the next cell (or the whole element sweeps all cells).
- Notation: e.g. ⇑(r0, w1) = 'in ascending address order, for each cell: read expecting 0, then write 1.'
March C- (the canonical 10N):
{ ⇕(w0); ⇑(r0,w1); ⇑(r1,w0); ⇓(r0,w1); ⇓(r1,w0); ⇕(r0) }— 6 elements, 10 operations/cell → 10N.- ⇕(w0): initialize all cells to 0.
- ⇑(r0,w1) / ⇑(r1,w0): ascending — read the expected value (catches stuck-at/transition), then write the opposite (sets up the next check and can disturb coupled cells).
- ⇓(r0,w1) / ⇓(r1,w0): descending — the reverse order so the other cell can be the aggressor (essential for coupling).
- ⇕(r0): final read of 0.
How coupling is detected (the key mechanism):
- Sweeping ⇑ then ⇓ with read-after-write means: after you write a cell, later you read a different cell that was already verified — if a neighbor's write disturbed it (coupling), the read mismatches → detected. Doing both orders ensures either cell can be the aggressor.
Complexity — linear and scalable:
- March C- = 10N operations; MATS+ ≈ 5N; March SS/LR longer. All are O(N) in memory size — scalable (exhaustive would be exponential/huge).
- Coverage vs length trade: shorter → less coverage (MATS+ misses coupling), longer → more fault classes (SS) at more test time (1.4).
Retention:
- Add a pause element (write all, wait, read all) to cover retention (DRF, 8.2) — a timed phase.
Algorithmic — the MBIST fit:
- March is generated on-chip by the controller (8.4), not stored → tiny test data, at-speed — the properties 8.1 promised.
The address order sweeping the array is what catches coupling:
5. Mental Model — walking library aisles, both ways, with a stopwatch
A March test is a librarian's inspection walk — done methodically, both directions, with a pause.
- Initialize: walk every aisle and place a '0' book on every shelf (⇕ w0).
- Walk up the aisles: at each shelf, check the book is still '0' (r0 — is it stuck/disturbed?), then swap it to '1' (w1). Because you check before you swap, if a previous shelf's swap knocked over this one, you catch it.
- Walk up again, then down: repeat reading/swapping — and crucially do it descending too, so a shelf that gets disturbed by a higher-numbered neighbor is also caught. Both directions means any shelf can be the culprit (aggressor) and any other the victim — that's coupling coverage.
- Pause and re-check: at the end, wait a while, then read every shelf — books that faded (retention) are caught.
- And you don't carry a giant script — you know the walk by heart (the algorithm), so you need only remember the rules, not a list of every step (tiny test data), and you walk at normal pace (at-speed).
Walk every shelf, both directions, checking before swapping, with a pause — that's a March test.
6. Working Example — March C- and what each element covers
Trace March C- and a coupling detection:
# March C- (10N) - REPRESENTATIVE, SIMPLIFIED, tool-neutral. up=ascending addr, down=descending, both=either.
M0: both (w0) # initialize all cells to 0
M1: up (r0, w1) # read 0 (STUCK-AT/coupling), write 1
M2: up (r1, w0) # read 1 (TRANSITION/coupling), write 0
M3: down (r0, w1) # DESCENDING -> the OTHER cell can be aggressor (coupling)
M4: down (r1, w0) # descending read 1, write 0
M5: both (r0) # final read 0
(+ optional PAUSE element: w-all, WAIT, r-all -> RETENTION, 8.2)
Total = 10 ops/cell = 10N -> LINEAR (scalable). Generated on-chip by the controller (8.4), not stored.# How a coupling fault is caught - REPRESENTATIVE:
Suppose writing cell A (aggressor) FLIPS cell B (victim) - an inversion coupling fault (8.2).
During an UP sweep, cell B was read-verified, then later cell A is written -> B is now WRONG.
A subsequent read of B (in this or the DOWN sweep) MISMATCHES its expected value -> DETECTED.
If A > B, the UP order catches it; if A < B, the DOWN order does -> BOTH orders needed (Figure 2).
# A single-order or no-read-after-write test (e.g. weak MATS+) would MISS the direction it doesn't sweep.7. Industry Flow — selecting and running a March
The fault classes pick the March; the controller generates and runs it:
8. Debugging Session — MBIST misses a coupling fault
MBIST passes but a coupling fault escapes, and the team assumes MBIST covers all memory faults; the chosen March test was too short (MATS+, lacking the up-and-down read-after-write structure), so it covers stuck-at but not coupling -- the fix is a stronger March (C- or SS) matched to the fault classes, accepting the modest extra linear test time
A TOO-SHORT MARCH MISSES COUPLING — MATCH ALGORITHM STRENGTH TO FAULT CLASSESMBIST passes, but a coupling fault escapes to the field. The team assumed 'MBIST covers all memory faults' and is puzzled that a memory with a clean MBIST result still failed.
The chosen March test was too short to cover coupling — it lacked the ascending-and-descending read-after-write structure that coupling detection requires — so it covered stuck-at but was structurally blind to the coupling fault that escaped. MBIST is only as strong as the March algorithm it runs, and March tests trade coverage for length (8.2/this lesson). A short algorithm like MATS+ (~5N) covers stuck-at and some transition faults, but coupling detection has a specific structural requirement: you must sweep the array in both ascending and descending address orders with read-after-write, so that either cell can be the aggressor and a disturbed, already-verified cell is caught on a later read. MATS+ doesn't do enough of that — it doesn't provide the both-orders read-after-write coverage — so a coupling fault (a write to one cell disturbing a neighbor) passes. The assumption 'MBIST covers all memory faults' is the real error: MBIST covers exactly the fault classes its March algorithm targets, and a weak algorithm leaves coupling (and retention, if no pause) uncovered. The escape isn't a broken controller — it's a too-weak algorithm for the memory's fault classes (8.2).
Choose a March test strong enough for the memory's fault classes — March C- (10N) or March SS for coupling, plus a pause element for retention — accepting the modest, still-linear extra test time. Move from MATS+ to March C- (or a longer March SS/LR), which provides the ⇑ and ⇓ read-after-write structure that catches coupling (both aggressor directions) and address-decoder faults, and add a pause element if retention is a concern (8.2). The cost is more operations per cell (5N → 10N or more), but it's still O(N) — linear and scalable — so the test-time increase is modest and worth it for the coverage (a coupling escape is a field/DPPM failure, 1.5). Match the algorithm strength to the fault classes present (adjacency-driven coupling, process-driven retention), and confirm the fault-coverage mapping covers them. The principle to lock in: a March test is a sequence of March elements — read/write operations applied to every cell in ascending or descending address order — and each element covers specific fault classes: read/write both values cover stuck-at and transition, ascending-and-descending read-after-write cover coupling and address-decoder (so either cell can be aggressor), and a pause element covers retention; March tests trade coverage for length (MATS+ 5N < March C- 10N < March SS), so MBIST covers only the fault classes its chosen March targets, and a coupling or retention escape means the March was too short — the fix is a stronger, still-linear March matched to the memory's fault classes, not more runs of a weak one. (The fault classes are 8.2; the controller that generates the March is 8.4; coverage/signoff is 6.5.)
9. Common Mistakes
- Assuming 'MBIST covers all memory faults.' It covers only what its March algorithm targets — match to fault classes.
- Choosing the shortest March for test time. MATS+ misses coupling — use C-/SS where coupling matters.
- Sweeping only one address order. Coupling needs both ⇑ and ⇓ (either cell as aggressor).
- Omitting a pause element. Retention is caught only by a timed pause (8.2).
- Storing March patterns. March is algorithmic — generate it on-chip (8.4); don't store it.
10. Industry Best Practices
- Match the March algorithm to the fault classes (8.2) — coupling/retention/decoder need C-/SS + pause.
- Use both ⇑ and ⇓ read-after-write for coupling/decoder coverage.
- Add a pause element for retention; run at-speed for timing.
- Trade coverage vs length deliberately (test time, 1.4) — but never below the fault classes present.
- Generate on-chip (algorithmic) — tiny test data; keep the fault-coverage mapping documented.
11. Senior Engineer Thinking
- Beginner: "MBIST passed, so the memory's fully tested."
- Senior: "MBIST covers only what its March algorithm targets. Was it MATS+ (5N) — which misses coupling — or March C-/SS with up-and-down read-after-write and a pause for retention? A coupling escape means the March was too short. I pick the March matched to the fault classes (8.2), accept the linear extra test time, and confirm the coverage mapping."
The senior chooses the March strength by fault class, never assumes MBIST is automatically complete.
12. Silicon Impact
March algorithms are the workhorse of memory test, and their design is a beautiful example of matching an algorithm to a fault physics. Because a memory is a dense, regular array whose faults involve cell interaction (coupling), decoding, and leakage, the right test is algorithmic — a sequence of read/write operations swept over every cell in specific address orders — and its structure directly encodes the fault requirements of 8.2: read/write both values for stuck-at/transition, ascending-and-descending read-after-write for coupling and address-decoder (so either cell can be the aggressor), and a pause for retention. The 10N complexity of a test like March C- is the property that makes memory test feasible at scale — it's linear, so even huge arrays are testable in reasonable time, where an exhaustive test would be impossible. And because March is algorithmic — generated on-chip, not stored — it delivers the tiny test data volume and at-speed operation that 8.1 promised, exactly what large memories need. The critical engineering judgment is the coverage-vs-length trade: MATS+ (5N) is cheap but misses coupling; March C- (10N) and March SS cover more at more test time — and the classic escape is choosing too short an algorithm and then wrongly assuming 'MBIST covers all memory faults' (it covers only what its March targets). For the DFT/memory engineer, the mandate is to select the March strength to the memory's actual fault classes — adjacency-driven coupling, process-driven retention — because a weak algorithm is a silent escape/DPPM liability (1.5) that looks fine on a pass/fail sheet. These algorithms are what the MBIST controller (8.4) generates and runs, and what detects (and localizes for repair, 8.5) the faults on the project's mini-SoC memory in 8.6.
13. Engineering Checklist
- Selected a March algorithm matched to the memory's fault classes (8.2).
- Included ⇑ and ⇓ read-after-write for coupling/decoder (both aggressor directions).
- Added a pause element for retention; ran at-speed for timing.
- Traded coverage vs length (test time, 1.4) deliberately — not below the fault classes present.
- Confirmed the fault-coverage mapping; generated the March on-chip (algorithmic, 8.4).
14. Try Yourself
- Write out March C- (6 elements) and label what each element covers (stuck-at/transition/coupling).
- Count the operations per cell (10) and confirm the test is 10N (linear).
- Show how a coupling fault (write A flips B) is caught — and why both ⇑ and ⇓ are needed.
- Add a pause element for retention; explain the write-wait-read timing.
- Compare MATS+ (5N) vs March C- (10N) — what each covers and the test-time trade.
The algorithm is tool-neutral. Real March coverage/length come from the MBIST flow (8.4). No paid tool required to trace a March test.
15. Interview Perspective
- Weak: "A March test writes and reads the memory to test it."
- Good: "It's a sequence of read/write operations swept over the cells in address order; March C- is a common one."
- Senior: "A March test is a sequence of March elements, each a sequence of r/w operations applied to every cell in an address order (⇑/⇓/⇕). March C- is
{⇕w0; ⇑r0,w1; ⇑r1,w0; ⇓r0,w1; ⇓r1,w0; ⇕r0}— 10N, linear. Each element covers a fault class (8.2): r/w both values → stuck-at/transition; ⇑ and ⇓ read-after-write → coupling/decoder (so either cell can be aggressor — you need both orders); a pause element → retention. March tests trade coverage for length — MATS+ (5N) is weaker (misses coupling), March SS is longer/stronger — so a coupling escape means the March was too short. And it's algorithmic — generated on-chip, not stored → tiny test data, at-speed. I match the March strength to the fault classes."
16. Interview / Review Questions
17. Key Takeaways
- A March test is a sequence of March elements, each a sequence of read/write operations (r0/r1/w0/w1) applied to every cell in an address order (⇑ up / ⇓ down / ⇕ either).
- March C- =
{⇕w0; ⇑r0,w1; ⇑r1,w0; ⇓r0,w1; ⇓r1,w0; ⇕r0}— 6 elements, 10 ops/cell = 10N — linear and scalable (exhaustive would be infeasible). - Each element covers a fault class (8.2): r/w both values → stuck-at/transition; ⇑ and ⇓ read-after-write → coupling and address-decoder (both orders so either cell can be aggressor); a pause element → retention.
- March tests trade coverage for length: MATS+ (5N, weaker) < March C- (10N) < March SS/LR — so MBIST covers only the fault classes its March targets, and a coupling/retention escape means the March was too short.
- March is algorithmic — generated on-chip by the controller (8.4), not stored → tiny test data and at-speed — so match the March strength to the memory's fault classes (coverage/DPPM vs test-time, 1.4/1.5). Next: 8.4 — MBIST controller architecture.
18. Quick Revision
March algorithms. A March test = a sequence of March ELEMENTS; each element = r/w ops (r0/r1/w0/w1) over EVERY cell in an ADDRESS ORDER (⇑ up / ⇓ down / ⇕ either). March C- =
{⇕w0; ⇑r0,w1; ⇑r1,w0; ⇓r0,w1; ⇓r1,w0; ⇕r0}= 6 elements, 10 ops/cell = 10N → LINEAR/scalable. Coverage: r/w both values → stuck-at/transition; ⇑ AND ⇓ read-after-write → coupling + decoder (either cell can be aggressor — need BOTH orders); pause element → retention. Trade coverage vs length: MATS+ 5N (weak) < C- 10N < SS/LR. MBIST covers only what its March targets → a coupling escape = March too short → use stronger (still linear). Algorithmic: generated on-chip, not stored → tiny test data, at-speed. Next: 8.4 — MBIST controller architecture.