MBIST vs LBIST

In short: Use MBIST (a BIST controller running March algorithms) to test the dense, regular, non-logic structure of embedded SRAM/ROM arrays, and use LBIST (an LFSR pattern generator plus a MISR signature analyzer wrapped around scan chains) to test random logic — they solve different fault models and are almost always deployed together on the same SoC.

Ask any DFT engineer "how do you test the memories versus the logic on a chip without a tester full of application vectors?" and you are really asking them to contrast two self-test engines. Both are forms of Built-In Self-Test (BIST): on-chip hardware that generates stimulus and checks responses with no external pattern storage. But a 2 Mb SRAM and a 500k-gate datapath fail in completely different ways, so the two engines look nothing alike. This article walks through why March algorithms suit memories, why LFSR/MISR pseudo-random logic suits scan logic, and how to decide what to put where.

Two problems, two fault models

A memory array is a regular 2D grid of bit cells sharing word lines, bit lines, and sense amplifiers. Its defects are correspondingly structural: stuck-at faults, transition faults (a cell that cannot make a 0→1 or 1→0 flip), and — critically — coupling faults where writing one cell corrupts a physical neighbour, plus address-decoder faults. Random logic, by contrast, is an irregular web of gates and flops whose dominant model is the single stuck-at fault (and transition/path-delay for at-speed). You cannot sensibly "march" through random logic, and you cannot efficiently cover a memory's neighbour-coupling with pseudo-random vectors. Hence two engines.

Rule of thumb: regular arrays → deterministic, algorithmic patterns (March). Irregular logic → pseudo-random patterns compressed into a signature (LFSR/MISR). Mixing them up is the classic interview trap.

MBIST: March algorithms for memories

A March test is a finite sequence of March elements applied to every address in a defined order (ascending ⇑ or descending ⇓), where each element is a set of read/write operations. The canonical March C- has six elements and 10N complexity (N = number of addresses):

{⇕(w0); ⇑(r0,w1); ⇑(r1,w0); ⇓(r0,w1); ⇓(r1,w0); ⇕(r0)}

That single sequence covers all stuck-at faults, transition faults, address-decoder faults, and both inversion and idempotent coupling faults. Concrete cost: for a 1 Mb memory (N≈1,048,576), 10N is ~10.5M operations; at a 400 MHz BIST clock that is roughly 26 µs — trivial on a tester. Heavier algorithms trade time for coverage: March SS (22N) and March RAW target read-destructive and data-retention faults; a retention test adds a programmable delay (e.g. 100 ms) between write and read to catch leaky cells.

The MBIST controller is a small FSM that sequences these elements, an address generator, and a data/comparator path. In practice you do not hand-write this: Siemens Tessent MemoryBIST, Synopsys DesignWare STAR Memory System, and Cadence solutions auto-insert the controller, wrap each memory, share one controller across many instances via a daisy-chained interface, and often bundle BIRA/BISR (built-in redundancy allocation and repair) that blows spare rows/columns using fuses when a repairable fault is found.

LBIST: LFSR + MISR for logic

Logic BIST wraps your existing scan infrastructure. An LFSR (linear-feedback shift register — a shift register with XOR taps defined by a primitive polynomial) generates a long, repeatable pseudo-random bit stream that is scanned into the chains as test stimulus. After each capture cycle the responses are shifted out and compacted by a MISR (multiple-input signature register — essentially an LFSR fed by many parallel inputs) into a single final signature. You compare that one signature against the fault-free value computed in simulation: match = pass. This is the STUMPS architecture (Self-Test Using MISR and Parallel Shift-register sequence generator), used by Synopsys DesignWare STAR / SMS LogicBIST and Siemens Tessent LogicBIST.

Two practical wrinkles dominate LBIST engineering. First, X-sources (unknown values from uninitialised RAM outputs, bus contention, or non-scan flops) corrupt a MISR signature irreparably, so you must add X-bounding logic or mask them — far more intrusive than in deterministic ATPG. Second, pseudo-random patterns have poor coverage on random-pattern-resistant faults (deep AND/OR trees), so you insert test points to lift coverage from the high-80s into the mid-90s percent; expect tens of thousands of patterns rather than ATPG's few thousand.

Why LBIST at all when ATPG exists? In-field and power-on self-test. Automotive ISO 26262 and aerospace parts must self-check at key-on with no tester present — LBIST runs from an on-chip ROM seed and reports a single pass/fail, which pure ATPG cannot do.

Side-by-side comparison

When to use each (and both)

They are not competitors — a typical SoC uses MBIST for every memory and either LBIST or deterministic ATPG (or both) for logic. Choose MBIST wherever you have a compiled memory instance; it is the only efficient way to hit coupling faults and the only path to in-field repair. Choose LBIST when the product spec demands in-system or power-on logic self-test (automotive, medical, aerospace), when you want to burn-in at high coverage without a huge tester pattern set, or as a security measure. Use plain ATPG when you only need manufacturing coverage and a tester is available — it reaches ~99% stuck-at with far fewer patterns. For a deeper treatment of the logic side, see our companion piece on logic BIST architectures, and for how all of this is stitched together at the top level read our guide to the scan chain and test access architecture.

Teams building silicon from scratch frequently pair this in-house DFT know-how with a design-services partner; if you need hands-on RTL-to-GDSII and DFT insertion support, Avecas offers VLSI design and DFT services that complement the fundamentals we teach here.

Want to insert real MBIST and LBIST in Tessent and DesignWare, debug X-sources, and read coverage reports like a pro? Join the hands-on CourseTron DFT & Testability course and build a full self-test flow end to end.

Frequently asked questions

Can one BIST engine test both memory and logic?

No, not efficiently. The patterns and checkers are fundamentally different: March sequences with per-op comparators for arrays, pseudo-random vectors with signature compaction for logic. Real SoCs instantiate separate MBIST and LBIST controllers, though a shared IEEE 1687 (IJTAG) network often orchestrates both.

Why not just use ATPG for everything?

ATPG gives the best coverage-per-pattern for logic but needs a tester to apply and compare vectors, so it cannot run in the field. LBIST trades pattern efficiency for autonomy. Memories need algorithmic March tests regardless, because pseudo-random vectors miss coupling and decoder faults.

What is a MISR signature and what happens on a mismatch?

The MISR compacts millions of response bits into one short register value. The fault-free "golden" signature is precomputed in simulation; any mismatch flags a fault but — because of compaction — does not tell you which one. That loss of diagnosability is the price of zero on-chip response storage.

What is BISR and why is it tied to MBIST?

Built-In Self-Repair uses MBIST's fault map to allocate spare rows/columns (BIRA) and permanently reconfigure the array via fuses, turning a would-be scrap die into a working one. It only makes sense for memories because their regular structure includes redundant elements; logic has no equivalent.