Skip to content
VLSIMentor

DFT · Chapter 9 · Logic BIST (LBIST) — chapter closer

LBIST for In-Field & Safety Test

This lesson delivers logic BIST's payoff: because it is self-contained and needs no tester, the chip can test itself in-system, out in the field. That enables two safety-critical uses. Power-on self-test runs LBIST at boot to verify the logic still works before the system relies on it. Periodic self-test runs it during operation to catch latent and aging faults that develop over the product's life and that manufacturing test cannot see. This is exactly what functional safety demands: standards such as automotive ISO 26262 and industrial IEC 61508 require diagnostic coverage of faults during operation, and LBIST with MBIST is a key safety mechanism to meet it. The run must fit a safety time window, and because pseudo-random patterns may miss random-resistant faults, test points or a deterministic top-up may be needed.

Intermediate13 min readDFTIn-Field TestFunctional SafetyISO 26262POST

Chapter 9 · Section 9.5 · Logic BIST (LBIST) — chapter closer

Project thread — the mini-SoC runs LBIST at power-on and periodically for functional safety; Chapter 10 (JTAG) provides the in-system access to start it and read results.

1. Why Should I Learn This?

This is why LBIST exists — in-field, in-system self-test for functional safety, which manufacturing test can't provide.

  • Power-on self-test (POST): verify the logic at boot before operation.
  • Periodic/runtime self-test: catch latent/aging faults during the product's life.
  • Functional safety (ISO 26262 / IEC 61508) requires diagnostic coverage during operation — LBIST (+ MBIST) is a safety mechanism.
  • Trade-offs: fit a safety time window (runtime) + hit diagnostic-coverage (pseudo-random → test points/top-up).

2. Real Silicon Story — the fault that developed after the factory

An automotive controller passed all manufacturing test (ATPG + MBIST) and shipped clean — zero-DPPM-class quality (1.5). Years into the vehicle's life, a latent defect in the logic — a marginal via that degraded with thermal cycling — finally failed. Manufacturing test could never have caught it: it wasn't a defect at the factory; it developed over time, in the field.

This is the gap functional safety exists to close. ISO 26262 requires the ECU to detect faults during operation — so a defect that appears after shipment is caught by the system, not by the driver. The mechanism was LBIST: the controller ran a power-on self-test at every start and a periodic self-test in idle windows, so the degraded logic was detected by the chip's own signature check and the system entered a safe state.

Lesson: manufacturing test proves the part was good when built; in-field self-test (LBIST + MBIST) proves it's still good while operating. Safety requires the latter — latent/aging faults develop after the factory, and only on-chip, in-system self-test can catch them.

3. Factory Perspective — in-field safety through each lens

  • What the safety engineer sees: LBIST/MBIST as safety mechanisms contributing diagnostic coverage to the ISO 26262 metrics (single-point-fault, latent-fault), run within the fault-tolerant time interval.
  • What the DFT engineer sees: the coverage vs runtime vs safety-window balance — enough coverage (test points/top-up) in a short enough run (segmented POST/periodic).
  • What the system/software engineer sees: the scheduling — POST at boot, periodic self-test in idle windows — and the safe-state response to a fail.
  • What management cares about: that in-field self-test is a market-access requirement for automotive/aero/medical — without it, the part can't be certified; it's the safety complement to manufacturing DPPM (1.5).

4. Concept — in-field uses, safety context, and trade-offs

The two in-field uses:

  • Power-on self-test (POST): run LBIST at boot → verify the logic is healthy before the system trusts it. (Also MBIST for memory, Chapter 8.)
  • Periodic / runtime self-test: run LBIST periodically or in idle windows during operation → detect latent/aging faults as they develop.

Why manufacturing test isn't enough:

  • Manufacturing test catches defects present at the factory. Latent/aging faults (electromigration, oxide wear, latent defects) develop over the product's life → only in-field self-test can catch them.

The functional-safety context:

  • ISO 26262 (automotive), IEC 61508 (industrial) require a diagnostic coverage of faults during operation — the fraction of dangerous faults the system detects itself — scored via single-point-fault and latent-fault metrics.
  • LBIST (logic) + MBIST (memory) are the on-chip safety mechanisms that provide much of that coverage. A valid signature (X-free, 9.4) is essential — an invalid self-test is worse than none.

The trade-offs (the engineering):

  • Safety time window: the self-test must fit — POST within the boot budget; periodic self-test within the fault-tolerant time interval (how long a fault may go undetected). → runtime matters; often the run is segmented.
  • Coverage: pseudo-random patterns (9.1) may miss random-resistant, safety-critical faults → add test points, weighting, or a deterministic top-up to hit the required diagnostic coverage.
  • Complement, not replace: LBIST complements ATPG manufacturing test (higher coverage on the tester) and MBIST memory test — together they form the safety self-test.
At power-on POST runs LBIST and MBIST; during operation periodic self-test runs within the fault-tolerant time interval to catch latent faults; a fail triggers a safe stateIn-field self-test: power-on (POST) + periodic (runtime) within the safety windowIn-field self-test: power-on (POST) + periodic (runtime) within the safety window1Power-on (POST)LBIST + MBIST at boot → healthy before operation2Operationsystem runs its function3Periodic self-testidle windows, within fault-tolerant time interval4Catch latent/aging faultsdevelop over life — manufacturing test can't5Fail → safe statediagnostic coverage during operation (ISO 26262)
Figure 1 - in-field LBIST across the product's life (representative). At every POWER-ON, POST runs LBIST (+ MBIST) to verify logic + memory are healthy BEFORE operation. During OPERATION, PERIODIC self-test runs in idle windows within the FAULT-TOLERANT TIME INTERVAL to catch LATENT/AGING faults that develop over life (which manufacturing test could not). A FAIL -> the system enters a SAFE STATE. This delivers the DIAGNOSTIC COVERAGE during operation that functional safety (ISO 26262 / IEC 61508) requires. LBIST/MBIST are the on-chip SAFETY MECHANISMS; a valid (X-free, 9.4) signature is essential.

The safety requirement flows down into the LBIST self-test as a stack:

The safety self-test stack: safety standard, diagnostic-coverage target, safety mechanisms LBIST/MBIST, valid signature, X-free design
Figure 2 - the functional-safety self-test stack (representative), top-down. A SAFETY STANDARD (ISO 26262 / IEC 61508) sets a required DIAGNOSTIC COVERAGE of faults during operation. That is met by SAFETY MECHANISMS -- on-chip LBIST (logic) + MBIST (memory) -- run at POST + periodically within the FAULT-TOLERANT TIME INTERVAL. Those depend on a VALID SIGNATURE, which requires an X-FREE design in test mode (9.4) and enough coverage (pseudo-random + test points/deterministic top-up, 9.1). Each layer sets the requirement below it; the whole stack is what makes a part CERTIFIABLE for a safety market.

5. Mental Model — a smoke detector, not just a building inspection

Manufacturing test and in-field self-test are like a building inspection versus a smoke detector.

  • The building inspection (ATPG/MBIST at manufacturing) certifies the building was up to code when built — thorough, done once, by experts with instruments (the tester). But it happens before anyone moves in, and it can't catch a fire that starts years later.
  • The smoke detector (LBIST/MBIST in the field) is installed inside and runs itself — it can't do a full inspection (pseudo-random, signature-only), but it watches continuously and catches the fire that develops after the inspectors left (a latent/aging fault).
  • A safety code requires both: the inspection (built right) and the detector (stays safe). And the detector must actually work — a detector with a dead battery (an invalid, X-contaminated signature, 9.4) is worse than none, because you think you're protected.
  • The detector must also respond fast enough — sound within the time it takes for the fire to become dangerous (the fault-tolerant time interval), which is why runtime and periodic scheduling matter.

Manufacturing test is the inspection; in-field LBIST is the smoke detector — safety needs both, and the detector must work and respond in time.

6. Working Example — POST, periodic, and the coverage/window balance

Deploy LBIST for safety on the mini-SoC:

Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
# In-field LBIST safety deployment - REPRESENTATIVE, SIMPLIFIED, tool-neutral:
  POWER-ON (POST): run LBIST (K1 patterns) + MBIST at boot -> verify logic + memory healthy BEFORE operation
                   must fit the BOOT time budget (segment if needed)
  PERIODIC (runtime): run LBIST (K2 patterns, possibly SEGMENTED across idle windows) during operation
                   must complete within the FAULT-TOLERANT TIME INTERVAL (FTTI) -> latent-fault detection
  ON FAIL: signature != golden -> enter SAFE STATE (system-level response)
  COVERAGE: pseudo-random alone may miss RANDOM-RESISTANT safety-critical faults
            -> add TEST POINTS / WEIGHTING / a DETERMINISTIC top-up to hit the required DIAGNOSTIC COVERAGE (ISO 26262)
  VALID SIGNATURE: design must be X-FREE in LBIST mode (9.4) + MISR wide enough (aliasing negligible, 9.3)
# LBIST (logic) + MBIST (memory) = the on-chip SAFETY MECHANISMS -> diagnostic coverage DURING operation.
Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
# The three-way balance (coverage / runtime / window) - REPRESENTATIVE:
  MORE coverage   -> MORE patterns -> LONGER runtime -> may not fit the safety window
  SHORTER runtime -> FEWER patterns -> LOWER coverage -> may miss the diagnostic-coverage target
  FIX: hit the coverage target EFFICIENTLY -- test points/top-up raise coverage-per-pattern; SEGMENT the run across
       idle windows to fit the FTTI. Balance coverage vs runtime within the safety time window.

7. Industry Flow — manufacturing test + in-field self-test

The two test regimes span the product's life, both required for safety:

At manufacturing ATPG and MBIST ensure low DPPM; in the field LBIST and MBIST run at power-on and periodically for diagnostic coverage during operationManufacturing test (clean at factory) + in-field self-test (safe for life)Manufacturing test (clean at factory) + in-field self-test (safe for life)1Manufacturing: ATPG + MBISTtester, high coverage → DPPM (1.5)2Ship cleangood when built3In-field: POST (LBIST/MBIST)verify at boot4In-field: periodic self-testlatent/aging faults, within FTTI5Diagnostic coverage (ISO 26262)safe for life → certifiable
Figure 3 - manufacturing test + in-field self-test across the lifecycle (representative). AT MANUFACTURING: ATPG (Ch5-7, tester) + MBIST (Ch8) -> high coverage, low DPPM (1.5) -> the part ships CLEAN. IN THE FIELD: LBIST (logic) + MBIST (memory) run at POWER-ON (POST) and PERIODICALLY within the fault-tolerant time interval -> catch LATENT/AGING faults -> DIAGNOSTIC COVERAGE during operation (ISO 26262) -> the part stays SAFE for its whole life. The two COMPLEMENT: manufacturing proves 'good when built'; in-field self-test proves 'still good while operating'. Access to run in-system BIST is via JTAG (Ch10).

8. Debugging Session — the safety self-test that doesn't fit (or doesn't cover)

1

An LBIST safety self-test either doesn't fit the fault-tolerant time window (too many patterns) or misses the required diagnostic-coverage target because pseudo-random patterns can't reach random-resistant safety-critical faults; the fix is to balance coverage vs runtime -- add test points/deterministic top-up to raise coverage-per-pattern and segment the run across idle windows to fit the window -- rather than choosing between safety coverage and timing

BALANCE COVERAGE vs RUNTIME WITHIN THE SAFETY WINDOW — TEST POINTS + SEGMENTATION
Symptom

An automotive part's LBIST safety self-test has a problem — one of two: either it doesn't fit the fault-tolerant time interval (too many patterns → too long), or it misses the required diagnostic-coverage target (pseudo-random patterns don't reach some safety-critical faults). The team feels forced to choose between safety coverage and timing.

Root Cause

LBIST safety self-test is a three-way balance — diagnostic coverage, runtime, and the safety time window — and the apparent 'choose coverage or timing' dilemma comes from treating it as two-way and from pseudo-random's inefficiency on random-resistant faults. The safety case sets a diagnostic-coverage target (the fraction of dangerous faults the self-test must detect during operation) and a fault-tolerant time interval (how long a fault may go undetected before it's dangerous) — so the self-test must hit the coverage target within the time window. Two forces collide: (1) pseudo-random patterns (9.1) have low coverage per pattern and struggle with random-resistant faults, so reaching the coverage target naively takes many patterns → long runtime; and (2) shortening the run to fit the window drops coverage below target. Treated as a two-way trade ('coverage or timing'), it looks unsolvable — but that framing ignores the efficiency lever: you can raise coverage per pattern (so you need fewer patterns for the same coverage) and spread the run over time (so a longer test still fits). The real problem is inefficient coverage (pseudo-random on hard faults) and a single-shot run, not a fundamental conflict between safety and timing.

Fix

Raise coverage-per-pattern with test points / a deterministic top-up, and segment the run across idle windows so it fits the fault-tolerant time interval — hit the coverage target and the timing. Attack coverage efficiency: add control/observe test points (6.4) at the random-resistant, safety-critical faults so pseudo-random patterns detect them (fewer patterns for the target), use weighted random where it helps, and add a small deterministic top-up (a few ATPG-style patterns) for the stubborn faults — so the diagnostic-coverage target is met with far fewer patterns. Attack timing: segment the periodic self-test across idle windows, running a portion each window so the full test completes within the fault-tolerant time interval without a single long stall; run POST at boot within the boot budget. Ensure the signature stays valid (X-free, 9.4) and aliasing-negligible (wide MISR, 9.3), since an invalid self-test provides no real coverage. The principle to lock in: LBIST's payoff is in-field self-test — power-on (POST) and periodic/runtime — that catches latent and aging faults over the product's life, meeting the functional-safety requirement (ISO 26262 / IEC 61508) for diagnostic coverage during operation that manufacturing test cannot provide; and deploying it is a balance of diagnostic coverage, runtime, and the safety time window — resolved not by trading safety for timing but by raising coverage-per-pattern (test points, weighting, deterministic top-up for random-resistant faults) and segmenting the run across idle windows to fit the fault-tolerant time interval, with a valid X-free, wide-MISR signature throughout. (Pseudo-random limits are 9.1; test points are 6.4; valid-signature requirements are 9.3/9.4; access to run in-system BIST is Chapter 10.)

9. Common Mistakes

  • Assuming manufacturing test covers safety. It catches factory defects — latent/aging faults need in-field self-test.
  • Treating coverage-vs-timing as two-way. Add test points/top-up (coverage-per-pattern) and segment (fit the window).
  • Ignoring the safety time window. POST fits the boot budget; periodic fits the fault-tolerant time interval.
  • Running an invalid self-test. An X-contaminated (9.4) or aliasing-prone (9.3) signature provides no real coverage — worse than none.
  • Forgetting LBIST complements ATPG/MBIST. Together they form the manufacturing + in-field safety picture.

10. Industry Best Practices

  • Deploy POST + periodic self-test — verify at boot, catch latent/aging faults during operation.
  • Meet the diagnostic-coverage target efficiently — test points/weighting/deterministic top-up for random-resistant faults.
  • Fit the safety time window — segment the periodic run across idle windows (FTTI); POST within the boot budget.
  • Ensure a valid signature — X-free (9.4) and wide MISR (9.3) — an invalid self-test gives no coverage.
  • Combine LBIST + MBIST as the on-chip safety mechanisms; keep ATPG/MBIST for manufacturing (1.5).

11. Senior Engineer Thinking

  • Beginner: "We passed manufacturing test — the safety part is covered."
  • Senior: "Manufacturing test proves it was good when built — safety needs in-field detection of latent/aging faults during operation (ISO 26262). I run LBIST at POST and periodically within the fault-tolerant time interval, hit the diagnostic-coverage target with test points + a deterministic top-up (pseudo-random is inefficient on hard faults), segment the run to fit the window, and keep the signature valid (X-free, wide MISR). Manufacturing + in-field, both required."

The senior deploys in-field self-test for safety and balances coverage/runtime/window, never assuming manufacturing test suffices.

12. Silicon Impact

In-field and safety test is the reason logic BIST exists, and it reframes the entire DFT effort: manufacturing test (ATPG + MBIST) proves the part was good when built; in-field self-test (LBIST + MBIST) proves it's still good while operating — and safety-critical systems require the latter. The distinction is physical: latent and aging faults (electromigration, oxide wear, latent manufacturing defects) develop over the product's life, so they are invisible to any factory test and can only be caught by on-chip, in-system self-test — run at power-on (POST) and periodically during operation. This is exactly what functional-safety standards (ISO 26262, IEC 61508) codify: a required diagnostic coverage of faults during operation, scored through single-point-fault and latent-fault metrics, met by LBIST/MBIST as safety mechanisms — which makes in-field self-test a certification gate and a market-access requirement for automotive, aerospace, and medical parts, not an optional feature. The engineering is a genuine three-way balance — diagnostic coverage vs runtime vs the safety time window — and the mature resolution is to raise coverage-per-pattern (test points, weighting, deterministic top-up for random-resistant faults, since pseudo-random is inefficient on them) and to segment the run across idle windows to fit the fault-tolerant time interval, all while keeping the signature valid (X-free, 9.4) and aliasing-negligible (wide MISR, 9.3) — because an invalid self-test is worse than none (it looks protected). This closes Chapter 9 and connects the entire curriculum: fault models (Ch2) → scan/ATPG/coverage/compression (Ch3–7) for manufacturing DPPM (1.5) → MBIST (Ch8) and LBIST (Ch9) for memory and logic self-test → in-field/safety — the full arc from 'catch defects cheaply at the factory' to 'keep the system safe for its whole life.' The remaining piece — how the outside world accesses the chip to start BIST and read results in-system — is Chapter 10 (boundary scan / JTAG), the standard test-access mechanism that makes all of this operable.

13. Engineering Checklist

  • Deployed POST (boot) + periodic self-test (runtime) — LBIST (logic) + MBIST (memory).
  • Met the diagnostic-coverage target (ISO 26262) — test points/top-up for random-resistant faults.
  • Fit the safety time window — POST in boot budget; periodic segmented within the fault-tolerant time interval.
  • Ensured a valid signature (X-free 9.4; wide MISR 9.3) — no invalid self-test.
  • Combined with ATPG/MBIST manufacturing test; defined the safe-state response to a fail.

14. Try Yourself

  1. Explain why manufacturing test can't catch latent/aging faults, and why in-field self-test can.
  2. Describe POST and periodic LBIST, and the fault-tolerant time interval the periodic run must fit.
  3. State what ISO 26262 / IEC 61508 require (diagnostic coverage during operation) and how LBIST/MBIST meet it.
  4. Resolve a coverage-vs-window conflict with test points/top-up (coverage-per-pattern) + segmentation (fit).
  5. Explain why an invalid signature (X, 9.4 / aliasing, 9.3) makes the safety self-test worse than none.

The concepts are tool-neutral. Real safety metrics/coverage come from the DFT + functional-safety flow. No paid tool required.

15. Interview Perspective

  • Weak: "LBIST lets the chip test itself in the field."
  • Good: "LBIST runs at power-on and periodically to catch faults during operation, for functional safety."
  • Senior: "LBIST's payoff is in-field self-test. Manufacturing test (ATPG/MBIST) proves the part was good when built, but latent/aging faults develop over life and are invisible to factory test — so safety requires on-chip self-test during operation: POST at boot and periodic self-test in idle windows. ISO 26262 / IEC 61508 require a diagnostic coverage of faults during operation, and LBIST (logic) + MBIST (memory) are the safety mechanisms that provide it — contributing to single-point-fault and latent-fault metrics. Deploying it is a coverage vs runtime vs safety-window balance: pseudo-random is inefficient on random-resistant faults, so I add test points / a deterministic top-up to raise coverage-per-pattern, and segment the run to fit the fault-tolerant time interval — keeping the signature valid (X-free, wide MISR), because an invalid self-test is worse than none. It complements manufacturing test — and it's a certification gate for automotive/aero/medical."

16. Interview / Review Questions

17. Key Takeaways

  • LBIST's payoff is in-field, in-system self-test — power-on self-test (POST) at boot and periodic/runtime self-test during operation — which a tester-based test cannot provide (9.1).
  • It catches latent and aging faults that develop over the product's life (electromigration, oxide wear, latent defects) — invisible to manufacturing test because they weren't defects at the factory.
  • Functional safety (ISO 26262, IEC 61508) requires a diagnostic coverage of faults during operation; LBIST (logic) + MBIST (memory) are the on-chip safety mechanisms that meet it (single-point-fault / latent-fault metrics) — a certification / market-access gate for automotive/aero/medical.
  • Deployment is a three-way balance — diagnostic coverage vs runtime vs the safety time window — resolved by raising coverage-per-pattern (test points/weighting/deterministic top-up for random-resistant faults) and segmenting the run across idle windows to fit the fault-tolerant time interval.
  • Throughout, the signature must be valid — X-free (9.4) and aliasing-negligible (wide MISR, 9.3) — because an invalid self-test is worse than none; LBIST complements manufacturing ATPG/MBIST (DPPM, 1.5). Next: Chapter 10 — Boundary Scan & JTAG (the test-access mechanism that starts BIST and reads results in-system).

18. Quick Revision

LBIST for in-field & safety (Ch9 closer). LBIST's payoff = IN-FIELD self-test (self-contained, no tester): POST at boot (verify before operation) + PERIODIC/runtime self-test (catch LATENT/AGING faults that develop over life — invisible to manufacturing test). Functional safety (ISO 26262 / IEC 61508) requires diagnostic coverage DURING operation → LBIST (logic) + MBIST (memory) = safety mechanisms (single-point-fault / latent-fault metrics) → a certification gate for automotive/aero/medical. Deploy = balance coverage vs runtime vs safety time window: raise coverage-per-pattern (test points/weighting/deterministic top-up for random-resistant faults) + SEGMENT the run to fit the fault-tolerant time interval; keep the signature VALID (X-free 9.4, wide MISR 9.3 — invalid self-test is worse than none). Complements manufacturing ATPG/MBIST (1.5). Next: Chapter 10 — Boundary Scan & JTAG.