123 Main Street, New York, NY 10001

Submit Your BOM

Built-in Self-Test (BIST) for Instrument Self-Check

Built-in Self-Test (BIST) for Instrument Self-Check

← Back to: Test & Measurement / Instrumentation

Built-in Self-Test (BIST) in instruments is a closed-loop health check that proves “ready to measure” by running loopback or reference injection, extracting signatures, making graded PASS/MARGINAL/FAIL decisions, and saving evidence logs for diagnosis. It does not replace calibration; it complements it by catching early degradation, preventing false pass/fail, and enabling fast localization when a test fails.

What BIST means in instruments (scope & promises)

Built-in Self-Test (BIST) is an instrument’s internal method for proving measurement-chain health, catching early faults, and producing traceable evidence. It is not a replacement for calibration: calibration establishes absolute accuracy against traceable standards, while BIST establishes that the instrument is behaving consistently and safely within a defined self-test model.

The three deliverables a practical BIST must provide
  • Fast decision (Go/No-Go): a repeatable PASS/FAIL gate that can run quickly (power-up, production, or field) with controlled false-fail risk.
  • Degradation awareness: a margin or trend signal (PASS, MARGINAL, FAIL) that flags drift before failure becomes user-visible.
  • Evidence for diagnosis: standardized logs (configuration + signature summary + timestamp + error codes) so failures are reproducible and triageable.
Scope boundaries that keep BIST reliable
  • BIST PASS ≠ calibrated accuracy: it indicates internal consistency and health under a defined test stimulus/response model.
  • BIST FAIL is not a single root cause: the failure may originate in the stimulus, path selection, observation, or signature logic—not only the main path.
  • One-time PASS is not a lifetime guarantee: periodic or on-demand tests and trend-aware decision logic are required for early drift detection.
What instrument BIST promises: gate, trend, and evidence (not calibration) Block-style cover diagram with three pillars labeled Go/No-Go gate, Degradation trend, and Evidence log, plus a boundary note that BIST does not replace calibration. Built-in Self-Test (BIST) Health proof · Early fault catch · Traceable evidence Go / No-Go Fast decision gate PASS / FAIL with controlled false fails Degradation Margin & trend PASS / MARGINAL / FAIL before user-visible errors Evidence Logs that reproduce Config + signature + code for diagnosis & clustering Boundary: BIST proves health and consistency; calibration proves absolute accuracy.

BIST architecture map (loopback / injection / redundancy)

A robust instrument BIST is a reusable set of engineering blocks that implement a closed-loop stimulus → response check. The key is to keep every decision reproducible: a known test configuration is applied, a measurable response is captured, a compact signature is compared to an expected band, and a decision plus evidence is recorded.

Minimal closed-loop (the one line that every implementation must preserve)
Stimulus → Path Select / Inject → Observe → Signature → Decision → Log
Three structural patterns (what each is best at)
  • Loopback (self-check): fastest and most repeatable for connectivity and functional health gating. Risk: false passes if the loop bypasses critical segments or if unintended coupling mimics a valid response.
  • Reference injection: validates deeper portions of the chain using a known stimulus injected at a controlled point. Requirement: the reference and the injection path must be self-identifying (configuration state must be captured in the log).
  • Redundancy cross-check: compares two paths or channels to reveal divergence without requiring an absolute reference. Limitation: common-mode drift can mask faults unless the fault model is explicitly covered by the signature.
Two test objectives (what the decision is trying to guarantee)
  • Go/No-Go: “Is the chain healthy enough to operate?” The emphasis is repeatability, speed, and controlled false-fail rate.
  • Parametric self-test: “How far is the chain from expected behavior?” The emphasis is signature design, tolerance bands, and margin trending to detect drift early.
Practical implementation rule (prevents “non-reproducible PASS”)

Every BIST result must be tied to a specific, logged configuration: stimulus parameters, selected path state, observation window, and signature method. Without configuration identity, a PASS/FAIL is not portable across time, temperature, or service actions—and it becomes unusable evidence.

Instrument BIST architecture: stimulus, path select/inject, observe, signature, decision, and logging Block diagram showing the minimal closed-loop for BIST with optional loopback and redundancy cross-check paths, ending in decision and error logging. BIST Closed-Loop Architecture Stimulus → Select/Inject → Observe → Signature → Decision → Log Stimulus Known Select / Inject Path state DUT Path Chain under test Observe Features Signature Compare band Loopback Redundancy cross-check Compare two paths/channels to detect divergence Decision PASS / MARGINAL / FAIL Log Key requirement: tie every result to a logged configuration (stimulus, path state, window, signature method).

Stimulus generation & reference injection (what “known-good” means)

BIST results are only as trustworthy as the stimulus and the injection path. A “known-good” stimulus is not a claim—it is a verifiable object with identity, repeatability, and bounded uncertainty. If the stimulus cannot be proven stable and the injection path cannot be proven controlled, a PASS/FAIL becomes non-reproducible evidence and drift detection loses meaning.

Three stimulus forms (describe the shape and the job, not the instrument)
  • DC / step: exposes offset shifts, saturation, polarity mistakes, and “does the path respond at all” health issues.
  • Sine / sweep: checks linear behavior and frequency-content integrity using compact signatures (e.g., harmonic/spur structure and response shape).
  • Pseudo-random / sequences: stresses dynamic behavior and repeatability; useful when signatures rely on statistics or correlation rather than a single point.
When a reference injection is trustworthy
  • Source self-proof: the reference source must self-check and self-monitor, and its environment (e.g., temperature/rail state) must be captured so repeatability is measurable over time.
  • Path controllability: the injection path state must be readable (logged configuration identity), and contact/continuity must be verifiable to prevent “phantom injection” or unintended coupling.
  • Stimulus reproducibility: phase, amplitude, and time alignment must be consistent within defined limits so the same configuration produces comparable signatures.
Engineering gate (prevents “BIST only measured the stimulus”)

The total stimulus uncertainty (source + injection path + environment + capture noise) must be clearly smaller than the decision threshold. A practical rule is to keep uncertainty comfortably below the tolerance band so the signature comparison is dominated by chain health, not by the stimulus itself. This also reduces false failures and makes trend tracking meaningful.

Reference injection trust chain for instrument BIST Block diagram showing a reference source with self-proof, a controllable injection path with logged state, then DUT path, observe window, signature compare, and evidence log. A small uncertainty bar is shown below a decision threshold line. Reference Injection Trust Chain Prove the stimulus, prove the path, then trust the signature Reference Source Self-check Monitor Repeatable Injection Path State logged Contact verified DUT Path Under test Observe Fixed window Signature Compare Log Uncertainty must be below the decision threshold source path capture threshold

Observation & capture (what to measure during self-test)

BIST observation is not “capture everything.” It is a controlled measurement that extracts a minimal sufficient set of features needed for a repeatable signature comparison. The fastest reliable self-tests focus on comparability: fixed windows, stable averaging rules, and features that map cleanly to the chosen fault model.

Observation layers (from raw evidence to compact signatures)
  • Raw waveform: small snapshots for evidence and sanity checks (not the main decision input).
  • Statistics: mean/variance and repeatability to quantify noise and drift.
  • Frequency content: harmonic/spur structure and noise-floor shape when it improves fault separation.
  • Timing behavior: delay and edge metrics when stability over time is the health signal.
Minimal sufficient feature set (keep only what changes the decision)
  • Amplitude / gain: detects scaling errors and gross path deviation.
  • Offset / bias: catches baseline shifts that distort signatures.
  • Noise floor: reveals early degradation and intermittent problems.
  • Harmonics / spurs: indicates nonlinearity growth or unexpected coupling.
  • Rise time / response shape: highlights dynamic limitations and changes.
  • Delay stability: provides timing-health indicators without expanding into routing systems.
Capture rules that keep signatures comparable
  • Fixed window identity: window length and extraction method must be stable and recorded as configuration identity.
  • Averaging strategy: multiple short windows vs fewer longer windows is a time/robustness trade; keep the rule consistent for trending.
  • BIST gating only: use simple self-test gating conditions (stable state, known configuration) without expanding into routing subsystems.
BIST observation pipeline: fixed capture window to features to signature Diagram showing a waveform, a fixed capture window, feature extraction capsules (gain, offset, noise, spurs, rise, delay), then a compact signature pack written to an evidence log. Capture Window → Features → Signature Minimal sufficient measurements for repeatable decisions Raw response Fixed window Feature extract Gain Offset Noise Spurs Rise Delay Signature Compare Evidence log Record window identity and extraction method so signatures remain comparable across time.

Signature analysis (golden, tolerance bands, and decision logic)

Signature analysis is what turns BIST into a quantifiable and traceable system. Instead of “run once and hope,” the result becomes a repeatable comparison against a defined golden reference with tolerance bands, guard-banding, and a decision policy that can be tuned for false-fail rate, early drift detection, and field actionability.

Three practical signature types (choose by speed, explainability, and trending needs)
  • Hash / CRC (fast consistency): compresses a capture into a quick “same vs different” check. Best for fast gates; weak for explaining why a failure occurred.
  • Feature vector (interpretable): compares a compact set of features (e.g., mean, variance, peak, distortion/spur indicators) to support margin tracking and drift trending.
  • Mask / envelope (shape-based): verifies that a response trace stays within an allowed band, ideal for “shape health” with clear pass regions.
Golden + tolerance band + guard-banding (make false-fails and missed-fails controllable)
  • Golden reference: a known-good signature bound to a specific configuration identity (stimulus, path state, capture window, and algorithm version) so comparisons remain valid over time.
  • Tolerance bands: the allowed region that accounts for measurement noise and expected environmental variation; comparisons must be done against a band, not a single curve.
  • Guard-banding: a deliberate safety margin inside the tolerance band that reserves a “near-edge” region for warnings and actions, improving reliability without forcing immediate FAIL.
Decision tiers (field-actionable outputs)
  • PASS: signature comfortably inside the band with healthy margin; log the margin for trending.
  • MARGINAL: still inside the band but close to guard limits or trending worse; increase self-test frequency or request service/recertification steps.
  • FAIL: signature outside the band or consistency broken; block critical use and store a reproducible snapshot (config identity + signature summary + failure code).
Signature decision example with golden trace, tolerance band, and typical failure patterns Diagram shows a golden response trace with an upper and lower tolerance band and a guard-band region. Three small panels illustrate offset shift, gain change, and elevated noise/spur behavior. Golden + Tolerance Band + Failure Patterns Bands enable tunable decisions and explainable outcomes Signature band tolerance band guard band Golden Tolerance Typical failure patterns (concept examples) Offset shift Gain change Noise / spur Use margin and guard-banding to separate PASS from early-warning MARGINAL states.

Loopback planning (where to close the loop, and what it covers)

Loopback planning turns “add a loopback” into an engineering coverage map. A loopback point determines what faults are observable, what segments remain untested, and how well a failure can be isolated. The most useful implementations layer loopbacks: a fast gate for basic health, plus deeper loopbacks that narrow the fault region.

Loopback tiers (each tier trades coverage vs isolation vs complexity)
  • Input-end loopback: fastest connectivity and basic response checks; weak coverage of deeper segments.
  • Mid-node loopback: enables segment-by-segment isolation and higher diagnostic value; requires more controlled switching and logging.
  • Output-end loopback: longest-path health gate; may hide faults if unintended coupling creates “plausible” responses without truly covering critical segments.
Two principles that make loopback choices defensible
  • Observability: the observation point must show enough signature difference between “healthy” and “faulted” behavior under the chosen stimulus.
  • Isolation: multiple loopbacks should narrow the fault region by comparing which loopbacks pass and which fail under identical logged configurations.
Preventing false passes (self-proof the loopback path)
  • State must be readable: loopback switch states and the selected point must be logged as configuration identity.
  • Continuity must be verifiable: add a quick “path confirmation” step so an open contact cannot masquerade as a valid loopback.
  • Guard against leakage/coupling: use discriminative stimuli and signatures so unintended coupling cannot mimic a healthy response.
Loopback planning map showing input, mid-node, and output loopback coverage A simplified chain with three loopback closure points is shown. Each point highlights covered segments and blind spots, with small badges for observability and isolation trade-offs. Loopback Point Map (Coverage vs Blind Spots) Choose loopback points to balance observability and isolation Measurement chain seg A seg B seg C seg D Input loopback covers A blind Obs ✔ Iso △ Mid-node loopback covers A–C blind spot remains for D Obs ✔ Iso ✔ Output loopback covers A–D Obs △ Iso △ Best practice: combine a fast gate loopback with a deeper mid-node loopback for isolation.

Coverage & fault model (prove what BIST can and cannot catch)

“BIST done” means more than running a script. It requires a declared fault model, a coverage statement, and evidence logs that allow a result to be reproduced under the same configuration identity. This section defines what faults are targeted, what can be detected vs isolated, what is explicitly out of scope, and how time/complexity and false-fail control shape the final plan.

Fault model taxonomy (what changes in the signature)
  • Open / short: missing response, saturation, clipping, or hard CRC/consistency breaks.
  • Offset drift: baseline shift; mask/envelope moves; offset feature shrinks margin.
  • Gain drift: scaled response; gain-related features trend; guard-band margin collapses.
  • Noise rise: higher variance/noise-floor indicators; repeatability degrades.
  • Nonlinearity worsening: distortion/spur indicators grow; response shape deviates.
  • Switch/path failure: declared state vs observed response mismatch; segment pass/fail pattern becomes inconsistent.
Coverage statement (make boundaries explicit)
Detects
Faults that reliably push the signature outside tolerance bands or break consistency checks under the defined stimulus, path state, and capture window.
Isolates to a segment
Faults that can be narrowed by comparing results across multiple loopback points or tiers, turning “fail” into a bounded region of suspicion.
Not covered
Behaviors requiring absolute traceability or external reference validation. These must be addressed by calibration or external test procedures, not by BIST.
Real-world constraints (turn trade-offs into tiers)
  • Time budget: short tests favor fast consistency checks; longer tests enable deeper isolation and stronger fault separation.
  • Resource occupancy: self-test consumes stimulus/capture windows and may limit normal operation; tiers define when deeper tests are allowed.
  • False-fail control: thresholds, guard-banding, and re-test rules determine whether “near-edge” results become MARGINAL or hard FAIL.
Coverage versus time and complexity trade-off using BIST tiers A, B, and C Stair-step chart shows tiers A/B/C increasing coverage and isolation at the cost of time and complexity. A small badge indicates false-fail control via thresholds and re-test rules. Coverage vs Time / Complexity (Tiers) Use tiers to make trade-offs explicit and reviewable Coverage & isolation ↑ Time / complexity → Tier A Fast gate Tier B Balanced Basic isolation Tier C Diagnostic Deeper loopbacks Stronger separation Better isolation False-fail control: thresholds + guard-band + re-test Tiering allows a “fast gate” for routine checks and a deeper diagnostic tier only when needed.

BIST vs calibration (how to complement, not replace)

BIST proves health; calibration proves accuracy. BIST detects consistency breaks, early degradation, and abnormal behavior under a controlled self-test configuration. Calibration restores and documents absolute accuracy against external traceability. The most robust programs connect them: BIST trends drive calibration timing, and post-calibration baselines refresh the “known-good” signature.

Role boundary (simple rule that prevents misuse)
  • BIST (health): repeatability, consistency, margin trending, early warning, evidence logging.
  • Calibration (accuracy): traceability to standards, long-term drift correction, specification alignment.
Complementary workflow (decision rules)
  • PASS but margin shrinking: keep operation allowed, increase monitoring, and generate a calibration recommendation or shorten the interval.
  • MARGINAL: escalate to a deeper diagnostic BIST tier and prioritize service or recertification planning.
  • FAIL: block critical use, run a localization-oriented BIST sequence, and then decide between repair and calibration based on bounded evidence.
Data loop (how they feed each other)
  • BIST → calibration: trend and margin history helps prioritize which units need attention first and when.
  • Calibration → BIST: after calibration, record a refreshed baseline signature (with versioning and configuration identity) as a new known-good reference.
Lifecycle action path linking BIST states to calibration and service actions State diagram with PASS, MARGINAL, and FAIL. Arrows show degradation flow and recovery after service or calibration. Each state lists small action tags such as log margin, increase test frequency, diagnostic BIST, block use, and recommend calibration. PASS → MARGINAL → FAIL (Action Path) BIST drives actions; calibration restores accuracy and refreshes baselines PASS Log margin Trend watch Normal operation Recommend calibration (if margin shrinks) MARGINAL Increase test frequency Run diagnostic BIST tier Plan service / recertify Prepare calibration action FAIL Block critical use Store evidence snapshot Localization BIST sequence Repair or calibration decision margin shrinks out of band Service / calibration refresh baseline Keep configuration identity and versions in logs so “health” evidence remains comparable across time.

Production test sequence (time budget, gating, binning)

In production, BIST must be fast, deterministic, and statistically useful. The common structure is POST → Quick BIST → (conditional) Extended BIST → Binning. Time budgets are assigned per stage, gating rules keep throughput high, and retry policies prevent occasional noise from turning into false rejects. Each unit should leave the line with a compact evidence record that enables population analytics (top signatures, failure distribution, and drift signals).

Sequence blocks (why each block exists)
  • POST: minimal health gate at power-up; catches obvious hard failures early.
  • Quick BIST: high-throughput gate with fixed windows and stable signatures.
  • Extended BIST: only for edge/failed units; adds isolation strength and stronger fault separation.
  • Binning: converts results into actionable grades and routes units to pass, retest, service, or scrap paths.
Design points that make it fast and stable
  • Time budget per stage: set a hard cap for POST, Quick, and Extended so throughput is predictable; treat timeout as a defined outcome.
  • Gating rules: PASS with healthy margin exits early; MARGINAL escalates to Extended; FAIL goes directly to a localization-oriented sequence.
  • Retry policy: re-test only for edge cases, with a fixed retry limit and a clear aggregation rule (e.g., vote or escalate) to reduce false rejects.
Statistics to collect (make failures optimizable)
  • Failure distribution: bins and signature categories across lots, shifts, and revisions.
  • Top signatures: the most common failure patterns and the most common “near-edge” marginal patterns.
  • Trend signals: rising marginal rate or shrinking margin at constant configuration identity.
Production BIST sequence with time budget bars, gating, retry points, and binning outputs Flow diagram shows POST to Quick BIST, then gating to either binning or extended BIST. Time budget bars illustrate relative duration. Retry points handle edge cases. Binning outputs PASS/MARGINAL/FAIL grades and a statistics block aggregates top signatures. Production Sequence (Gating + Time Budget + Binning) Fast path for healthy units; deeper path only when needed Flow POST minimal set Quick BIST fixed window Gate PASS? Extended BIST deeper isolation PASS MARGINAL / FAIL retry Time budget POST Quick Extended Binning PASS MARGINAL FAIL Stats top signatures fail distribution Keep evidence compact but complete: configuration identity + result tier + signature summary + retry count.

Field self-test modes (POST / periodic / on-demand)

Field self-test turns BIST into an operations tool. Three modes cover different needs: POST provides a minimal power-up gate, Periodic tracks degradation trends with consistent configuration identity, and On-demand adds localization steps when a user suspects abnormal behavior. Each mode must define test depth, evidence outputs, and a non-disruption policy (or an explicit maintenance mode) so normal measurement is not silently compromised.

Mode definitions (same template for all modes)
  • Trigger: what starts the test (power-up, timer, or user request).
  • Test set: tier depth and which signatures are collected.
  • Output: PASS/MARGINAL/FAIL plus compact evidence fields.
  • Policy: what happens to operation and user actions after each result tier.
Non-disruption rule (or explicit maintenance mode)

If a self-test can affect measurement availability or validity, it should run only in idle windows or enter a declared maintenance mode with start/stop timestamps recorded in the evidence log. Silent interference should be avoided.

Degradation-aware actions (field-friendly outcomes)
  • PASS: normal operation; keep margin and trend history for comparison.
  • MARGINAL: warn and limit risk actions; increase periodic checks and suggest deeper on-demand test.
  • FAIL: block critical use; capture evidence snapshot and prompt service/localization steps.
Field self-test modes overview with triggers, tier depth, and evidence outputs Three columns show POST, Periodic, and On-demand self-tests. Each column includes a trigger icon, tier depth tags, and PASS/MARGINAL/FAIL evidence outputs, with a shared non-disruption/maintenance rule bar. Field Self-Test Modes Triggers, depth, and evidence outputs for operations POST Trigger: power-up Depth: Tier A PASS MARGINAL FAIL Evidence: compact log Periodic Trigger: timer Depth: Tier A/B PASS MARGINAL FAIL Evidence: margin trend On-demand Trigger: user Depth: Tier B/C PASS MARGINAL FAIL Evidence: localization Non-disruption: run in idle windows or enter maintenance mode with timestamps in the log Consistent configuration identity is required for meaningful periodic trends and comparisons.

Error logging & evidence (make failures diagnosable)

A production- and field-ready BIST should not behave like a single indicator light. It should produce an evidence package that makes failures reproducible, comparable across time, and clusterable into repeatable root-cause classes. The goal is simple: a FAIL or MARGINAL record should answer what happened, under which configuration, how close it was to the threshold, and what next action is appropriate.

Evidence package model (think “evidence bag”)
  • Header (context): who/when/how the test ran (identity, mode, timestamp, config identity).
  • Signature (small + comparable): compact summary that supports clustering (CRC/hash + key features + margins + decision + failure_code).
  • Snapshot (optional + conditional): only for MARGINAL/FAIL (or “debug tier”) to keep logs small while enabling diagnosis.
Minimal log field set (small but sufficient)
  • test_id — unique per run (include a monotonic counter if available).
  • mode — POST / periodic / on_demand.
  • timestamp — include a time_source tag (RTC vs monotonic).
  • config_hash — configuration identity (thresholds, windows, tier depth, signature version).
  • signature_summary — CRC/hash plus a compact digest of key features and margin-to-threshold.
  • decision — PASS / MARGINAL / FAIL.
  • failure_code — enumerable class for clustering and actions.
  • retry_count + retry_rule_id — prevents yield/statistics distortion.
  • duration_bucket — helps detect timeouts/throughput drift without storing large timing traces.
  • snapshot (optional) — short window stats or short-series digest (only when triggered).

Why config_hash matters: without configuration identity, the same unit can generate “different” outcomes simply because thresholds, capture windows, or signature versions changed. That breaks reproducibility and makes trend analysis meaningless.

failure_code taxonomy (small set, high utility)
failure_code
Meaning + typical next action
PATH_OPEN
Observed signature suggests an open path. Escalate to localization tier; verify path state and retry consistency.
PATH_SHORT
Observed signature suggests a short/clip condition. Block high-risk operation; capture snapshot; service workflow.
SWITCH_STUCK
Commanded state conflicts with observed signature. Escalate to a connectivity/isolation check sequence; log state readback.
GAIN_DRIFT
Gain-related features moved beyond tolerance with stable retries. Mark MARGINAL/FAIL; trend tracking; recommend service if persistent.
OFFSET_DRIFT
Offset-related features moved beyond tolerance. Store margin history; raise check frequency; suggest deeper diagnostics when worsening.
NOISE_RISE
Noise floor increased beyond tolerance. Capture summary + short snapshot; use periodic mode to confirm repeatability.
NONLINEARITY_WORSEN
Template/mask exceeded in a repeatable way. Escalate tier depth; preserve signature vector and envelope violation summary.
TIMING_ANOMALY
Capture windows/features are inconsistent across retries. Mark as unstable; require controlled re-run and evidence timestamps.
TIMEOUT
Stage exceeded its budget. Treat as a defined outcome (fail or escalate) and record duration bucket for throughput analysis.
INCONSISTENT_RETRY
Retry results disagree. Do not over-fit thresholds; label as unstable and require a controlled re-run or deeper isolation tier.

The key is stability: keep the taxonomy small, keep labels consistent across firmware versions, and always link each outcome to a next action.

Evidence chain rules + common pitfalls (what breaks diagnosis)
  • Keep logs small: store only Header + Signature for PASS; store Snapshot only for MARGINAL/FAIL or debug tiers.
  • Version everything: signature computation changes should bump a signature_version (or be embedded into config_hash).
  • Never drop config context: missing config_hash makes results non-reproducible and trends non-comparable.
  • Do not create “unique failures”: unstable field names, inconsistent units, or ad-hoc failure codes prevent clustering.
  • Watch retries: if retry_count and retry_rule_id are not logged, yield and top-signature statistics become misleading.
  • Avoid timestamp ambiguity: record time_source and monotonic counters when RTC trust is limited.
Example BOM parts (MPNs) for an evidence-capable BIST

These are representative part numbers commonly used to support evidence storage, timestamps, and integrity. They are examples, not mandates.

Nonvolatile memory (log storage)
  • FM24CL64B (I²C F-RAM) — frequent small writes, counters, compact evidence records.
  • CY15B104Q (SPI F-RAM) — larger log capacity and fast writes for evidence bursts.
  • 24LC256 (I²C EEPROM) — lower-frequency evidence/config storage with wear-aware policies.
Timestamp source (for trustworthy evidence chronology)
  • DS3231 (RTC with temperature compensation) — stable timestamps for long-term field logs.
Evidence integrity (optional, for tamper-resistant logs)
  • ATECC608B (secure element) — signing/attestation of evidence packages and config identity.
  • OPTIGA Trust M (secure element family) — device identity and evidence integrity hooks.
  • SLM 9670 (TPM) — standardized evidence integrity workflows when a TPM is preferred.
Reset/watchdog evidence (to capture system-health events)
  • TPS3850 (supervisor / window watchdog class) — structured reset/watchdog event evidence for diagnosis.
Evidence package structure for BIST logs: header, signature, and optional snapshot A large evidence bag contains three layers: Header for context, Signature for compact comparable summaries, and Snapshot as optional conditional data. Outputs include storage and export paths. A seal icon indicates integrity checks. Evidence Bag (Log Package) Structured logs that are reproducible, comparable, and clusterable Header (context) test_id · mode · timestamp · config_hash Signature (compact summary) CRC / hash · key features · margin decision · failure_code · retry info Snapshot (optional) window stats or short-series digest (triggered) seal Outputs Store (NVM) Export (host log) Keep PASS logs small; attach snapshots only when needed to preserve storage and throughput.

Request a Quote

Accepted Formats

pdf, csv, xls, xlsx, zip

Attachment

Drag & drop files here or use the button below.

FAQs (Built-in Self-Test / BIST)

These FAQs stay inside the BIST closed loop: when to run, what to run, how to decide, how to avoid false results, how to localize after a failure, and how to use logs as evidence.

1) What is the fundamental difference between BIST and calibration?
BIST proves health and catches early degradation with repeatable signatures and evidence logs. Calibration establishes accuracy traceability and corrects long-term drift against a reference standard. BIST should not replace calibration; it complements it. A typical policy is: stable PASS with worsening margin triggers a “calibration recommended” action, while FAIL triggers localization steps and service.
2) When should loopback be used, and when is reference injection required?
Use loopback to verify path continuity and segment coverage (does the selected path behave as expected, end-to-end or per segment). Use reference injection when the test must be anchored to a known-good stimulus, enabling quantitative feature checks and margin tracking. A practical rule: loopback proves “the path can close,” injection proves “the system responds correctly to a known input.”
3) Why doesn’t a single PASS prove long-term health, and how should trends be judged?
A single PASS only proves the system met thresholds once under one configuration. Long-term health needs trend signals: margin-to-threshold over time, increasing marginal rate, and clustering of similar failure codes. Periodic self-tests should run with a stable config identity (config_hash), so signatures remain comparable and degradation can be detected early.
4) How should tolerance bands be designed to avoid false fails?
Start with a golden signature, then apply guard-banding so normal variation stays well inside the PASS region. Ensure stimulus uncertainty and capture variation are much smaller than the decision thresholds; otherwise the test measures the stimulus, not health. Use graded outcomes (PASS/MARGINAL/FAIL) and restrict retries to near-boundary results with a fixed retry rule to avoid statistics distortion.
5) Is CRC/Hash sufficient for signatures, and when are feature vectors or masks needed?
CRC/Hash is excellent for fast consistency checks (did the result match a known pattern). For parametric drift, a compact feature vector (offset, gain, noise, distortion indicators, and margins) provides better sensitivity and trending. Masks/envelopes help when the failure mode is “shape/region out of bounds.” Choose the simplest form that still clusters failures reliably.
6) How should BIST coverage be defined so it is “provable”?
“Provable” coverage starts from an explicit fault model (open/short, drift, noise rise, nonlinearity, switch faults, timeout/instability). Separate detection coverage (can it be detected?) from localization coverage (can it be narrowed to a segment or class?). Also list what is not covered and must be handled elsewhere. Evidence logs should bind each result to config_hash and signature version.
7) Why does BIST sometimes produce false passes, and how can they be prevented?
False passes often come from unverified path state (a switch is stuck, a bypass exists, or a leakage path mimics a valid signal), or from signatures that are too coarse to distinguish “nearly right” from “right.” Prevention includes path state readback checks, multi-point or segmented loopbacks, negative checks (conditions that should fail), and margin-based decisions tied to config_hash so results remain comparable and repeatable.
8) What is the minimum POST set that stays fast but still has high value?
POST should be a minimal, deterministic gate: confirm configuration identity is valid, confirm the test can select and observe a path, and collect a small signature that catches hard failures quickly. Keep POST short; do not expand it into a full diagnostic routine. If POST is MARGINAL/FAIL, escalate into quick or localization tiers and attach evidence fields (config_hash, signature summary, failure code, retry count).
9) How should periodic self-test frequency be chosen without disturbing measurement?
Frequency should follow risk and drift speed: more critical use and faster degradation drivers justify tighter intervals, while stable systems can run less often. To avoid disturbance, run periodic BIST in idle windows or enter an explicit maintenance mode with timestamps recorded. Keep the test set and config_hash stable so margins are comparable; trend quality matters more than simply increasing test frequency.
10) After FAIL, what “localization BIST” should run first to save time?
Start with the cheapest segmentation: short, deterministic tests that isolate whether the failure is repeatable and which segment class it belongs to. Use failure_code to choose the next step (path-open/short vs drift vs instability). Prefer tests that cut the search space quickly before running longer tiers. Always capture a compact snapshot only when it adds diagnosis value; otherwise keep evidence small and consistent.
11) What is the most commonly missing but most critical context in logs?
The most damaging omission is configuration identity: config_hash (or an equivalent) that binds thresholds, windows, tier depth, and signature version. Without it, results are not reproducible and trends are not comparable. The next most common gaps are retry policy (retry_rule_id and retry_count), time source tags for timestamps, and margin-to-threshold. These fields are small, but they determine whether evidence can be used.
12) How can historical BIST logs enable degradation alerts instead of only post-mortems?
Degradation alerts come from leading indicators: shrinking margin-to-threshold, rising marginal rate, and growing clusters of the same failure_code. Compare only runs with the same config_hash so signals are consistent. Define alert rules such as “margin slope exceeds a limit” or “marginal count crosses a threshold.” Actions can include increasing periodic frequency, recommending service, or limiting high-risk operation—before a hard FAIL appears.
icnavigator

ICNavigator helps engineers find verified ICs, alternatives, and fast quotes.

Explore
Categories
  • Power Management
  • MCU
  • Automotive ICs
  • Sensors
  • Interface & Transceivers
  • Analog Front-End
Get in Touch
  • Email: hello@icnavigator.com
  • WeChat/WhatsApp: +86-xxxx

© 2025 ICNavigator. All rights reserved.