MBIST Controller Architecture

Chapter 8 · Section 8.4 · Memory BIST (MBIST)

Project thread — this controller runs March C- (8.3) on the mini-SoC memory in 8.6, and its comparator's failing-address capture feeds repair (8.5).

1. Why Should I Learn This?

The controller is how a March test becomes silicon — a tiny on-chip machine that generates, runs, and checks the test.

• Address generator (up/down counter) + data generator (backgrounds) + control FSM (sequences the algorithm) + comparator (go/no-go + failing-address capture).
• A wrapper muxes the memory functional vs BIST and bypasses it in scan (fixes the 7.5 X-source).
• Interface: bist_en, done, go/nogo; shared controllers; at-speed; JTAG access.
• The comparator's failure data feeds BISR (8.5) for repair.

2. Real Silicon Story — the go/no-go that couldn't be repaired

A team's MBIST controller reported a clean go/no-go — just a single pass/fail bit per memory. When a memory failed, that was all they knew: fail. They couldn't repair it, because repair (8.5) needs to know which rows/columns failed — and the controller never captured the failing address.

The controller had been built as minimal — a comparator that only sets a flag — to save area. But for a memory with redundancy (8.5), a go/no-go bit is nearly useless: redundancy allocation needs the failing addresses to decide which spares to swap in. So repairable memories were being scrapped on a single fail bit, hurting yield (1.2) — the very thing redundancy exists to protect.

The fix was a diagnosis-capable comparator: capture the failing address (and failing bits) so BISR (8.5) could compute a repair solution. Lesson: the comparator isn't just a pass/fail flag — for repairable memories it must capture failure data (failing address/bits), or you can't repair and you throw away yield.

3. Factory Perspective — the controller through each lens

• What the test engineer sees: the BIST interface (bist_en, done, go/nogo) and — for diagnosis — the failing-address capture; JTAG to start BIST and read results; shared controllers (serial/parallel).
• What the yield engineer sees: that the comparator's failing-address data drives repair (8.5) — without it, repairable memories are scrapped (yield, 1.2).
• What the RTL/DV / memory engineer sees: the wrapper/mux integration — functional vs BIST select and bypass in scan (kills the 7.5 X-source) — an insertion task on their block.
• What management cares about: that MBIST is tiny area (a small FSM + wrapper) for on-chip, at-speed, repairable memory test — and that controller sharing trades test time vs area (1.4).

4. Concept — the blocks and the interface

Address generator:

• A counter that produces addresses in ascending (⇑) and descending (⇓) order — the address order each March element requires (8.3).

Data generator:

• Produces the write data: 0/1 for the March operations, and data backgrounds (checkerboard, solid, column/row stripes) to stress coupling and neighborhood faults (8.2).

Control FSM (the brain):

• Sequences the March elements and operations (r/w, 0/1), handles timing and at-speed clocking, and encodes the algorithm (8.3). A small FSM — negligible area vs the memory.

Comparator:

• Compares each read to the expected value → go/no-go (pass/fail) flag.
• For diagnosis/repair: also captures the failing address and failing bits — the data BISR (8.5) needs.

Wrapper / mux (integration):

• Muxes the memory's address/data/control between functional and BIST modes (a test-mode select).
• Bypasses/initializes the memory outputs in scan → removes the 7.5 X-source so logic compression runs clean.

Interface & deployment:

• Interface: bist_en (start), done, go/nogo (fail) — small.
• Shared controllers: one controller can test multiple memories — serially (less area) or in parallel (less test time) — a 1.4 trade.
• At-speed: runs at the memory's rated clock (catches timing/retention, 8.2/8.3).
• Access via JTAG/TAP (Chapter 10): start BIST, read go/no-go + failure data.
• Feeds BISR (8.5): failing-address data → repair.

5. Mental Model — a robot librarian running the inspection

The MBIST controller is a robot librarian installed inside the library (the chip) to run the inspection walk (March, 8.3) by itself.

• Its legs are the address generator — it walks the aisles in order, up and down.
• Its hands are the data generator — it places the right books (0/1 and patterns/backgrounds) on the shelves.
• Its brain is the control FSM — it knows the whole walk (the algorithm) and does it at full pace (at-speed).
• Its eyes + notebook are the comparator — it checks each shelf against expectations and, crucially, writes down which shelf was wrong (the failing address) — not just 'something's wrong.'
• A switchable door (the wrapper/mux) lets the library run normally (functional) or hand control to the robot (BIST), and seals the shelves off during outside audits (bypass in scan) so they don't confuse the auditors (the 7.5 X-source).
• You talk to the robot through the front desk (JTAG): 'start the inspection,' 'are you done,' 'pass or fail,' 'which shelves failed.'

A robot that walks, places, checks, and writes down which shelf failed — because 'fail' alone can't tell the repair crew (BISR) which shelf to fix.

6. Working Example — the controller running March C-

The controller sequencing March C- (8.3) and capturing a failure:

# MBIST controller running March C- - REPRESENTATIVE, SIMPLIFIED, tool-neutral:
  bist_en=1 -> Control FSM starts. It sequences March C- (8.3), driving:
    Address generator: sweeps 0..N-1 (up) and N-1..0 (down) per element
    Data generator:    supplies w0/w1 (and backgrounds for coupling/NPSF, 8.2)
    (through the WRAPPER in BIST mode -> memory address/data/control come from the controller, at-speed)
  Comparator: each read is checked vs EXPECTED (from the algorithm) -> go/no-go
    on MISMATCH: capture FAILING ADDRESS + failing bit(s) -> for diagnosis + BISR (8.5)
  When the March completes: done=1 ; go/nogo reflects pass/fail
# Interface seen by the tester (via JTAG, Ch10): start bist_en, poll done, read go/nogo + failing-address log.

# Shared controller trade (test time vs area) - REPRESENTATIVE:
  SERIAL:   one controller tests memory A, then B, then C -> least area, MOST test time (sum)
  PARALLEL: one controller (or per-memory) tests A,B,C at once -> least test time, MORE area/routing
  -> choose per the test-time budget (1.4) and area budget. At-speed either way.
# Wrapper also BYPASSES/INITIALIZES the memory in SCAN mode -> no X into the compactor (7.5) -> logic compression clean.

7. Industry Flow — the BIST run

The controller executes a self-contained run from enable to result:

8. Debugging Session — MBIST fails but you can't repair

9. Common Mistakes

• Go/no-go-only for a repairable memory. Repair needs the failing address — capture it for BISR (8.5).
• Forgetting the scan-bypass in the wrapper. In scan, the memory must be bypassed/initialized (7.5 X-source).
• Ignoring data backgrounds. Coupling/NPSF need checkerboard/solid backgrounds from the data generator (8.2).
• Running MBIST slowly. It must be at-speed for timing/retention (8.2/8.3).
• Over- or under-sharing controllers. Serial saves area but costs test time; parallel the reverse (1.4).

10. Industry Best Practices

• Capture failing addresses/bits for repairable memories (feeds BISR, 8.5) — go/no-go only for non-repairable.
• Wrapper: functional / BIST / scan-bypass — resolve the 7.5 X-source.
• Provide data backgrounds (checkerboard/solid) for coupling/NPSF (8.2).
• Run at-speed; access via JTAG/TAP (Chapter 10).
• Choose controller sharing (serial/parallel) per the test-time vs area budget (1.4).

11. Senior Engineer Thinking

• Beginner: "MBIST says fail — the memory's bad, scrap it."
• Senior: "Is this memory repairable? Then a go/no-go bit is useless — I need the comparator to capture the failing address so BISR can allocate spares and repair it (yield!). I also make sure the wrapper bypasses the memory in scan (7.5), and the data generator provides backgrounds for coupling. Go/no-go for non-repairable; diagnosis capture for repairable."

The senior builds a diagnosis-capable controller for repairable memories — a fail bit alone scraps yield.

12. Silicon Impact

The MBIST controller is the small but essential hardware that turns the March algorithm (8.3) into an on-chip, at-speed, self-contained memory test — delivering exactly the properties 8.1 promised: tiny test data (the test is generated, not streamed), at-speed operation (catching timing/retention), and in-system capability (via JTAG, Chapter 10). Its blocks map cleanly to a March test — address generator (the ⇑/⇓ order), data generator (values + backgrounds for coupling/NPSF), control FSM (the algorithm), comparator (pass/fail) — and it's tiny area next to the memory, so it's an easy win. The design decision that carries the most weight is the comparator's capability: a go/no-go bit is enough for a non-repairable memory, but for a repairable one (with redundancy, 8.5) it is nearly useless — BISR needs the failing addresses to allocate spares, so a diagnosis-capable comparator is what turns a fail into a repair and recovers yield (1.2) that a single fail bit would throw away. The wrapper carries the other high-value integration point: besides selecting functional vs BIST, it bypasses/initializes the memory in scan, which is the concrete resolution of 7.5's X-source — so the same insertion that makes the memory self-testing also makes logic scan compression clean. Practical deployment choices — shared controllers (serial for area, parallel for test time, 1.4) and JTAG access — round out an architecture that is cheap, at-speed, and repairable. For the RTL/DV / memory engineer, MBIST insertion is an integration task on their block (the wrapper, the bypass), and choosing a diagnosis-capable controller for repairable memories is the difference between recovering yield and scrapping dies — which is exactly what 8.5 (BISR) and the 8.6 worked example build on.

13. Engineering Checklist

• Controller has address generator (up/down), data generator (backgrounds), control FSM, comparator.
• Comparator captures failing addresses/bits for repairable memories (feeds BISR, 8.5).
• Wrapper selects functional / BIST and bypasses/initializes in scan (7.5 X-source).
• Runs at-speed; JTAG/TAP access (Ch10); sharing (serial/parallel) per test-time/area budget (1.4).
• Confirmed the interface (bist_en, done, go/nogo) and diagnosis capability match the repair plan.

14. Try Yourself

1. Draw the controller: address gen + data gen + control FSM + comparator → wrapper → memory.
2. Trace a March C- run (8.3): FSM sequences elements, addr gen sweeps up/down, comparator checks reads.
3. Show the wrapper selecting functional vs BIST and bypassing the memory in scan (7.5).
4. Add failing-address capture to the comparator and explain why BISR (8.5) needs it.
5. Compare serial vs parallel controller sharing (test time vs area, 1.4).

The architecture is tool-neutral; MBIST insertion is a DFT tool. No paid tool required to reason about the controller.

15. Interview Perspective

• Weak: "The MBIST controller tests the memory."
• Good: "It has an address generator, data generator, control FSM, and comparator, and runs the March test on-chip."
• Senior: "The MBIST controller generates and runs the March test (8.3) on-chip: an address generator (up/down counter → the ⇑/⇓ order), a data generator (0/1 + backgrounds for coupling/NPSF), a control FSM that sequences the algorithm at-speed, and a comparator that produces go/no-go and — for repairable memories — captures the failing address/bits so BISR can allocate spares (a go/no-go bit alone can't drive repair). A wrapper/mux selects functional vs BIST and bypasses the memory in scan (fixing the 7.5 X-source). Interface: bist_en/done/go-nogo; controllers can be shared (serial for area, parallel for test time); access via JTAG (Ch10). It's tiny area for on-chip, at-speed, repairable memory test."

16. Interview / Review Questions

17. Key Takeaways

• The MBIST controller is the on-chip hardware that generates and runs the March test (8.3): an address generator (up/down counter → address order), a data generator (0/1 + backgrounds for coupling/NPSF), a control FSM (sequences the algorithm at-speed), and a comparator (read vs expected → go/no-go).
• For repairable memories, the comparator must also capture the failing address and bits — the data BISR (8.5) needs to allocate spares; a go/no-go bit alone cannot drive repair and scraps yield (1.2).
• A wrapper/mux selects the memory's functional vs BIST mode and bypasses/initializes it in scan — the concrete resolution of the 7.5 X-source (so logic compression runs clean).
• The interface is small (bist_en, done, go/nogo); controllers are often shared across memories (serial for area, parallel for test time — 1.4); everything runs at-speed; access is via JTAG/TAP (Chapter 10).
• MBIST insertion (like scan insertion) adds a wrapper per memory + a (shared) controller — a tiny-area way to make memories self-testing and repairable; the comparator's failure data feeds BISR (8.5). Next: 8.5 — redundancy & built-in self-repair.

18. Quick Revision

MBIST controller architecture. The on-chip hardware that GENERATES + runs the March test (8.3): ADDRESS GENERATOR (up/down counter → address order), DATA GENERATOR (0/1 + backgrounds for coupling/NPSF), CONTROL FSM (sequences the algorithm, at-speed — the brain), COMPARATOR (read vs expected → go/no-go, + capture FAILING ADDRESS/bits for repairable memories → BISR 8.5). WRAPPER/MUX: functional vs BIST select + bypass/init in scan (fixes 7.5 X-source). Interface: bist_en / done / go-nogo. Shared controllers (serial=area, parallel=test time, 1.4); at-speed; JTAG access (Ch10). Go/no-go-only can't drive repair → repairable memory needs failing-address capture or you scrap yield (1.2). Tiny FSM area. Next: 8.5 — redundancy & built-in self-repair.