Production Test & BIST for DACs (Design-for-Test Hooks)
← Back to:Digital-to-Analog Converters (DACs)
Production Test & BIST turns DAC performance into repeatable, auditable pass/fail decisions at manufacturing speed.
The goal is to achieve the required coverage with minimal time and false fails, using built-in tests, fast spectral/DC checks, traceable calibration, and structured data feedback to keep production under control.
What “Production Test & BIST” must guarantee
Production test is not an “instrument demo”. It is a repeatable proof that a DAC will stay within limits under factory constraints: throughput (UPH), fixture cost, measurement repeatability (GR&R), limited temperature points, and automated decisioning. This section defines what “production-controlled” means so every later test item maps back to an explicit guarantee.
The three guarantees (what the line must prove)
- Screen: catch hard faults and gross parametric escapes (opens/shorts, stuck outputs, severe nonlinearity, unstable behavior).
- Performance: confirm key metrics with guard bands under realistic capture limits (bandwidth, ENOB, noise floor, drift).
- Calibrate-ready: enable stable coefficient generation (offset/gain or multi-point) with traceable storage and verification.
Coverage must be tiered. A high-UPH line cannot run “everything”. Instead, define Basic vs Full coverage: Basic maximizes fault screening and prevents false fails; Full adds deeper spectral/linearity checks and extra temperature points when the product risk demands it.
| Field | What it controls | Typical choices |
|---|---|---|
| UPH target | Test time budget and number of points | High-UPH (minimal points) vs lower-UPH (more sweeps) |
| Coverage tier | Which categories must be proven on every unit | Basic / Full |
| Temperature points | Drift sensitivity and coefficient stability claims | 1 point (room) / 2 points / 3 points |
| Decision guard band | False-fail risk vs escape risk | Fixed margin (dB/LSB) or % of spec |
| Calibration requirement | Whether the line must write/verify coefficients | None / offset+gain / multi-point LUT (only if stable & measurable) |
Practical rules that prevent scope creep
- Define UPH and temperature points first; coverage tier follows from the time budget.
- Screening comes before grading; otherwise throughput collapses and false fails rise.
- If measurement uncertainty is larger than the guard band, performance limits are not meaningful.
- Only calibrate on the line when coefficients stay stable and can be verified quickly.
Production test architecture: from stimulus to decision
A production result is only as trustworthy as the measurement chain. The chain must be decomposed into blocks so that each failure can be attributed (stimulus, fixture, DUT, capture, compute, limits, logging) and each block has explicit control knobs. This prevents false fails and avoids “fixing” the wrong part of the system.
The canonical chain
Stimulus → Switch / Fixture → DUT (DAC) → Capture → Compute → Limits → Log
External instruments should be described by role and error terms, not by brand names. For example: DMM/SMU for DC accuracy and sourcing; audio analyzer or ADC capture + FPGA for spectral metrics; scope for step transient verification. The correct architecture makes measurement uncertainty explicit so guard bands can be set rationally.
| Block | Dominant error terms | Control knobs (what to tune) | Must-log fields |
|---|---|---|---|
| Stimulus | Amplitude error, source distortion, phase noise/jitter | Level selection, coherent tone bins, warm-up | Amplitude setpoint, tone freq, source mode |
| Fixture / Matrix | Parasitics, crosstalk, contact resistance, ground return | Load configuration, shielding, routing, self-check | Fixture ID, cable ID, contact check result |
| DUT | True distortion, INL/DNL, glitch behavior, drift | BIST modes, output mode, code patterns | Config registers, BIST code, temperature readback |
| Capture | ENOB floor, capture jitter, front-end distortion | Sample rate, bandwidth, anti-aliasing, averaging | FS, BW, record length, calibration state |
| Compute | Window leakage, bin mismatch, estimator bias | Window type, coherent capture, mask templates | Window, bins, averaging count, masks used |
| Limits | Guard band too tight (false fails) or too loose (escapes) | Limit versions, temp-dependent limits, re-test rules | Limit version, pass/fail reason code |
| Log | Missing traceability blocks root-cause analysis | Schema lock, mandatory fields, anomaly flags | Serial/lot, fixture/instrument IDs, timestamps |
Minimal capture & compute template (fast + robust)
- Use a record length that supports stable FFT bins and a repeatable noise estimate.
- Prefer coherent captures when possible; otherwise lock a window+mask strategy and keep it consistent across stations.
- Log every knob that can change the result (FS, BW, N, window, masks, limit version).
Test access & observability hooks to request from vendors
Production success depends on observability: the ability to stimulate known conditions, read back results, and log a reproducible signature. Without DFT/BIST hooks, a line is forced to over-invest in external instruments and still risks false fails and untraceable escapes. This section turns “DFT capability” into vendor questions and mandatory fields.
Must-have hooks (minimum set for a controllable line)
- Internal test tone / step with phase continuity and programmable level.
- Loopback paths (digital and mixed) with clear coverage claims and blind spots.
- PRBS / code patterns to stress major-carry and code-dependent behavior.
- Reference bypass / monitor (where allowed) for source-vs-DUT separation.
- Output open/short detection or status that flags overload / clamp events.
- Temperature readback and a stable “ready-to-test” state indicator.
- Status registers + CRC / config verify for deterministic station-to-station behavior.
BIST must be treated as a measurable contract, not a marketing checkbox. A usable BIST exposes (1) how to start it, (2) how long it takes, (3) what the result granularity is, and (4) which statistics can be read back. Fine-grained error codes reduce debug time and prevent “bin dumping”.
| Hook / field | Production purpose | Output (what is read back) | What to ask vendors |
|---|---|---|---|
| BIST start condition | Repeatability & automation | Start/ready bits | After reset? after config? needs warm-up? |
| BIST runtime | UPH budgeting | typ/max time (ms) | Worst-case time across temp/voltage? |
| Result granularity | Fast triage | PASS/FAIL + error code | Bitfield? enum? how many unique codes? |
| Readback statistics | Screen vs grade vs calibrate | RMS / SFDR / INL summary | Which stats are available and their units? |
| Config verify (CRC) | Prevent station-to-station drift | CRC / lock bits | Is there a “config snapshot” register? |
| OTP/EEPROM endurance | Calibration & auditability | Write-count / CRC | Write cycles, page size, verify/readback method? |
Fast “go/no-go” checklist for procurement
- BIST provides both error codes and at least one readback statistic (not just PASS/FAIL).
- Runtime is bounded and documented; a timeout behavior is defined.
- Configuration can be verified (CRC/lock) and logged deterministically.
- Coefficient storage has endurance and integrity checks (CRC + version fields).
Built-in sine/step: how to use internal generators correctly
Built-in waveform generators are most valuable when they produce repeatable, short-runtime evidence. A production program should treat internal sine and step as “recipes”: fixed setup, fixed capture configuration, fixed metrics, and versioned limits. The goal is stable decisions, not maximum waveform complexity.
What each built-in waveform is best for
- Sine: fast SFDR/THD/SNDR screening and grading using a small set of key tones (not full sweeps).
- Step: major-carry stress, overshoot/settling extraction, and a coarse stability check of the output path under a defined load.
Correct setup prioritizes phase continuity, bounded amplitude (avoid clipping and avoid noise-floor domination), and capture synchrony. When coherence is not possible, lock a window+mask strategy to prevent station-to-station differences from turning into false fails.
| Recipe field | Why it matters in production | What to lock |
|---|---|---|
| Tone bin / code pair | Controls leakage and repeatability | Fixed bins (preferred) or fixed window+mask |
| Record length (N) | Stabilizes noise estimate and spur ranking | One or two approved N values |
| Window type | Defines bias and leakage behavior | Single approved window per non-coherent mode |
| Amplitude setting | Avoids clipping and noise-floor domination | Bounded %FS (policy + guard band) |
| Update rate & sync | Prevents timebase mismatch artifacts | Trigger alignment / coherent capture policy |
| Step settling timestamp | Turns waveforms into scalars (repeatable metrics) | Start point, threshold definition, and measurement BW |
Failure patterns to triage (without scope creep)
- Stable spur location but poor SFDR: verify compute settings (bins/window) and fixture/capture repeatability before attributing to coupling.
- Step ringing: lock load and measurement bandwidth first; then compare output modes and only then isolate external post-stage effects.
Loopback self-test: digital and mixed-signal loopbacks
Loopback is only useful when its coverage claim is explicit. A loopback PASS does not automatically mean “analog performance is good”. Production programs should treat each loopback path as a contract: what it covers, what it cannot cover, and what evidence is logged.
What loopbacks can and cannot prove
- Digital loopback: validates interface, registers, and timing/data integrity. It does not cover analog distortion or noise.
- Mixed-signal loopback: routes DAC output into an internal/external capture/compare path. It can cover gain/offset and some dynamic behavior, but results are capture-limited (ENOB/BW/jitter).
- Full external loop: exercises the end-to-end production chain (fixture + capture + compute). It best represents real decisions, but is most sensitive to fixture variation and requires GR&R discipline.
Mixed loopback often needs a small calibration layer to stabilize comparisons: select a reference channel, align sampling/decision latency, and normalize gain so thresholds remain valid across temperature points and station differences. All alignment and normalization parameters must be logged; otherwise loopback results cannot be reproduced.
| Loop type | Covers | Blind spots | Typical evidence |
|---|---|---|---|
| Digital loop | IO, registers, timing, data integrity | Analog distortion, noise, settling, load effects | CRC/BER, error flags, pass/fail code |
| Mixed loop | Gain/offset, coarse dynamics, threshold checks | Capture-limited spur/noise floor, aliasing artifacts | Compare stats, RMS/level, code + summary |
| Full external | End-to-end decision realism | Fixture/cable sensitivity, compute/version drift | FFT masks, limit version, pass/fail reason |
| Field to lock & log | Why it is mandatory | Example values |
|---|---|---|
| Loop path ID | Coverage changes by path | DIG_LOOP / MIX_LOOP / EXT_LOOP |
| Reference channel | Normalizes station variation | CH0 as ref, others relative |
| Alignment delay | Stabilizes compare windows | sample_offset (ticks) |
| Compare threshold | Defines pass/fail boundary | level/limit, margin |
| Decision statistic + coverage claim version | Prevents “PASS” without meaning | RMS, spur-count, claim_v |
Quick rules that avoid false confidence
- Digital loopback PASS proves control and timing, not analog purity.
- Mixed loopback results must include capture configuration and statistic definitions.
- Any loopback used for binning must log a coverage claim version and limit version.
Spectral sweeps at production speed: SFDR/THD/SNDR without pain
Production FFT is constrained by short record lengths, environment noise, and fixture coupling. The right approach is not “more sweep points”, but fewer, high-discrimination points plus robust estimators: fixed capture settings, fixed windows, mask-based spur search, and versioned guard bands.
A production-friendly point strategy
- Low / Mid / High tone points (3 total) to separate common defect classes quickly.
- One near-edge point (near-Nyquist or near-image, chosen by the product use case) to expose boundary weaknesses.
- Mask + guard band decisions to control false fails under fixture/environment variation.
| Test point | Purpose | Recipe fields to lock | Decision outputs |
|---|---|---|---|
| Low | Expose low-frequency coupling and gross nonlinearity | bin, N, window, amplitude, mask ID | SFDR, max spur, mask pass |
| Mid | Representative operating region | bin, N, window, averaging, mask ID | THD/SFDR, noise estimate |
| High | Stress bandwidth edges and dynamic weaknesses | Fs/BW, N, window, mask ID | max spur, mask pass |
| Near-edge | Reveal boundary artifacts | tone placement rule + mask regions | mask fail reason + guard band |
| Mask / limit field | What it does | Must-log |
|---|---|---|
| Spur search region | Defines where max-spur is evaluated | region ID + bounds |
| Exclude bands | Avoid known interference or non-evaluated bins | list of excluded ranges |
| Noise region | Controls SNDR/noise estimate stability | method + region ID |
| Guard band + limit version | Controls false fail vs escape | margin + limit_v |
Rules that keep spectral testing fast and stable
- Lock N, window, and mask versions; do not allow station-specific “tuning”.
- Prefer a few high-discrimination points over long sweeps; add points only when escape analysis proves value.
- Log mask/limit versions and guard-band application; otherwise results cannot be audited.
Linearity & DC sweeps: INL/DNL/gain/offset with minimal time
Production DC linearity testing is a balance between coverage, time, and measurement-chain integrity. The fastest programs lock a small number of approved code sets and turn raw readings into repeatable scalars: gain/offset, monotonic flags, peak DNL signatures, and INL summaries with versioned limits.
Code-point strategies (coverage claim vs runtime)
- Full sweep: maximum coverage, highest time cost. Best for characterization or low-UPH lines.
- Segment sampling: sparse points per segment; fast and stable for grading when limits are built on the same recipe.
- Key codes: major-carry and boundary codes; fastest for defect screening, not a substitute for full INL/DNL grading.
Measurement choice should be driven by repeatability rather than absolute resolution. DMM/SMU paths are typically stable but slower; high-resolution ADC capture can be much faster but becomes sensitive to capture ENOB, reference stability, settling behavior, and station-to-station timing differences. Regardless of instruments, production success depends on locking the recipe and logging drift evidence.
| Strategy | Covers | Blind spots | Best use |
|---|---|---|---|
| Full sweep | Dense INL/DNL signatures | UPH impact, drift accumulation | Characterization, slow lines |
| Segment sampling | Stable summaries (INL/DNL peak/shape) | Misses fine local steps | Performance grading at speed |
| Key codes | Major carry/boundary defects | No full linearity characterization | Fast screening (defect catch) |
| Recipe field | Why it controls accuracy | Must-log output |
|---|---|---|
| Code set ID | Defines coverage and repeatability | code_set_v, list hash |
| Wait per code | Prevents settling from corrupting readings | t_wait, measurement BW |
| Averages / samples | Reduces noise and station variance | N_avg, outlier rule |
| De-glitch rule | Avoids transient corruption | discard_N, clamp flags |
| Drift correction | Separates DUT error from chain drift | ref_code recheck, drift metric |
| Limits + guard band | Prevents “tuning” and supports audit | limit_v, guard_band |
Split thresholds: screening vs grading
- Screening thresholds focus on functional defects (monotonic breaks, major-carry anomalies) using key codes.
- Grading thresholds use segment sampling or denser sets to produce stable summaries with guard bands.
- All bins must log the code-set version and drift evidence; otherwise results cannot be reproduced.
Calibration hooks: coefficient stability, storage, and auditability
Calibration becomes production-ready only when coefficients are stable, storable, and auditable. The default approach is simple offset/gain calibration; multi-point LUTs and temperature segmentation are justified only when the measurement uncertainty is well below targets and coefficients remain stable across voltage, temperature, and load variation.
Production calibration types (cost vs stability requirements)
- Offset/gain (1st order): fast, robust, and easiest to audit. Default choice.
- Multi-point LUT: only when coefficient noise is low and stability is proven across conditions.
- Temperature segmentation: ties coefficients to temperature windows and requires logged temperature evidence.
- Aging re-cal policy: defines triggers, re-run scope, and rollback to last-known-good.
Coefficient stability should be treated as a measurable gate. If coefficients drift more than the allowed guard band under normal variations, calibration becomes a maintenance burden. If the measurement chain cannot support the needed uncertainty, LUT fitting turns into overfitting and writes measurement noise into non-volatile memory.
| Calibration type | Production cost | Stability gate | Risk |
|---|---|---|---|
| Offset/gain | Low | Small drift across V/T/load | Under-corrects structured nonlinearity |
| Multi-point LUT | Medium–High | Uncertainty ≪ target error | Overfitting, station mismatch |
| Temp segments | High (temp points) | Stable per window + temperature evidence | Wrong window selection, audit gaps |
| Aging re-cal | Lifecycle dependent | Trigger policy validated | Field complexity without rollback |
| Audit/storage field | Why it matters | Must-log |
|---|---|---|
| Coefficient format version | Prevents parsing mistakes and silent misuse | coef_fmt_v |
| CRC / integrity check | Detects corruption and partial writes | crc_type + crc_value |
| Write-count / endurance | Avoids wearing out storage | write_count + limit |
| Timestamp + station ID | Supports traceability and audit | ts + station_id |
| Active bank + rollback pointer | Enables last-known-good recovery | bank_A/B + rollback |
| Post-write verification | Prevents “written but invalid” states | readback + quick check result |
A production-ready calibration loop
- Measure with a locked recipe and log temperature evidence.
- Fit coefficients within a bounded model (avoid overfitting).
- Write to non-volatile memory with version + CRC.
- Read back and verify using a quick, repeatable check.
- Log timestamp, station ID, and limit version for audit.
- Provide a rollback path to last-known-good coefficients.
Multi-channel sync test: alignment, skew, and phase coherence checks
Multi-channel “sync” is not a single number. Production programs should validate three independent consistencies: update skew (simultaneous updates), relative phase (phase coherence), and gain mismatch (amplitude match). Each metric needs a locked recipe, a reference channel, and versioned limits.
| Metric | Meaning | Primary test | Logged outputs |
|---|---|---|---|
| Update skew | Relative update timing across channels | Simultaneous step + threshold crossing | max/min/σ, reference CH, limit_v |
| Relative phase | Phase error for same-frequency tones | In-phase sine + correlation/phase estimate | deg + equivalent time, freq ID |
| Gain mismatch | Amplitude consistency across channels | Tone RMS/fundamental level compare | Δgain, channel spread, guard band |
Two production-friendly test recipes
- In-phase sine: estimate relative phase (deg) and equivalent time skew via correlation/phase difference; summarize across channels.
- Simultaneous step: measure update skew using a fixed threshold crossing rule (e.g., 50%); summarize max/min/σ.
| Recipe field | Why it must be locked | Examples |
|---|---|---|
| Reference channel | Defines all relative metrics | CH0 ref |
| Sine: freq + record length | Controls estimator stability | 1–3 points, fixed N |
| Estimator method | Prevents station-specific “tuning” | xcorr / phase |
| Step: threshold rule | Defines update timing consistently | 50% crossing |
| Limits + guard band | Supports audit and stable binning | limit_v, guard_band |
Thresholds should be system-driven
- Update skew limits should map to the system tolerance for simultaneous updates.
- Phase error limits should map to allowable coherence loss at the target tone frequencies.
- Gain mismatch limits should map to allowable amplitude imbalance in the application.
Guarding against false fails: fixtures, GR&R, and environmental control
False fails waste capacity through retests and drive unstable yields. Robust production testing treats the measurement chain as a controlled system: fixtures, instruments, environment, and procedure. GR&R and station control are the foundation; without them, limits become tuning knobs.
| Source | Typical symptom | Fast check | Mitigation |
|---|---|---|---|
| Fixture | Intermittent fails, channel-dependent shifts | Contact health, cable swap, matrix self-check | Periodic fixture verification and replacement rules |
| Instrument | Station-to-station drift, range-dependent deltas | Calibration status, golden correlation | Fixed ranges, scheduled calibration, drift alarms |
| Environment | Temperature-sensitive yield swings | Warm-up gate, temp stability evidence | Controlled airflow/EMI, temp monitoring |
| Procedure | Retest abuse, silent recipe changes | Script/limit version audit | Version lock + quarantine rules |
| Control field | What it prevents | Example policy |
|---|---|---|
| Golden unit check frequency | Undetected station drift | per shift / per X hours |
| Station calibration interval | Slow instrument/fixture drift | weekly/monthly + alarm triggers |
| Retest rules | Yield inflation and hidden escapes | max retries + quarantine |
| Warm-up gate | Cold-start shifts and false fails | fixed warm-up + temp stable |
| Version lock (script/limits) | Silent recipe changes | script_v + limit_v in logs |
Robust flow controls (minimal set)
- Lock capture settings, scripts, and limit versions; do not “tune” at the station.
- Use golden-unit correlation to detect drift early; stop or downgrade the station on mismatch.
- Enforce retest caps and quarantine rules; retest is not a yield tool.
- Require warm-up and temperature stability evidence before running binning tests.
Production reporting & failure analysis: data schema, binning, and feedback
Production testing only becomes controllable when results are reproducible, searchable, and actionable. A minimal schema must capture identity, conditions, station assets (material numbers), recipe/limit versions, key metrics, and final bin decisions. Binning should separate functional fails, performance grades, and reworkable station issues so feedback can flow to design, supply chain, and firmware calibration without guesswork.
Material-number examples to make assets and versions traceable
- Fixture / matrix: FIX-SWMTX-64CH-R01-001, FIX-PROB-DAC-R02-003
- Cable set: CAB-SMA-SET-R01-012, CAB-DIFF-PAIR-R01-005
- Calibration kit: CAL-LOAD-NET-R01-004, CAL-REF-LOWNOISE-R01-002
- Golden unit: GOLD-DAC-16B-R01-001, GOLD-DAC-RF-R01-002
- Software / limits / schema: SW-ATE-TESTPKG-R12-0007, LIM-DAC-PROD-R08-0021, SCHEMA-JSON-R03-0004
| Field | Type | Unit / enum | Source | Notes |
|---|---|---|---|---|
| serial_no | string | — | MES/label | required |
| lot_id | string | — | MES | required |
| wafer_id | string | — | MES | optional but recommended |
| temp_point_id | enum | T0/T1/T2 | ATE | required |
| temp_c_meas | float | °C | sensor | log evidence for temp windows |
| warmup_gate | bool | true/false | procedure | required if warm-up is mandatory |
| station_id | string | — | ATE | required |
| fixture_mn | string | material number | asset DB | e.g., FIX-SWMTX-64CH-R01-001 |
| cable_set_mn | string | material number | asset DB | e.g., CAB-SMA-SET-R01-012 |
| switch_matrix_mn | string | material number | asset DB | e.g., FIX-SWMTX-64CH-R01-001 |
| golden_unit_mn | string | material number | asset DB | e.g., GOLD-DAC-16B-R01-001 |
| test_recipe_v | string | — | ATE | must be version-locked |
| limit_v | string | — | ATE | e.g., LIM-DAC-PROD-R08-0021 |
| schema_v | string | — | DB | e.g., SCHEMA-JSON-R03-0004 |
| sfdr_db | float | dBc | computed | store by freq_id if multiple points |
| sndr_db | float | dB | computed | summary scalar for fast binning |
| inl_lsb | float | LSB | computed | store peak or percentile summary |
| offset_lsb | float | LSB | computed | log pre/post calibration if used |
| bist_code | enum/int | PASS/FAIL + code | DUT reg | use vendor-defined error granularity |
| cal_coef_fmt_v | string | — | firmware/ATE | e.g., CAL-COEF-FMT-R05-0009 |
| cal_coef_crc | string | hex | computed | integrity evidence |
| bin_code | enum | Fxx/Pxx/Rxx/Sxx | ATE | must be rule-defined |
| fail_reason_code | enum | CONTACT/DRIFT/LIMIT/BIST/SYNC/LINEARITY/SPECTRAL | computed | supports fast root-cause filtering |
| Bin | Definition | Evidence fields | Disposition |
|---|---|---|---|
| F01 | BIST fail or hard functional failure | bist_code, test_recipe_v, station_id | scrap/hold per policy |
| F03 | Monotonic/major-carry anomaly confirmed | inl_lsb summary, key-code flags | scrap |
| P10 | Performance grade A (within guard band) | sfdr_db, sndr_db, inl_lsb, limit_v | ship |
| P20 | Performance grade B | metrics + guard band applied | ship (tiered) |
| R01 | Reworkable: contact/station instability suspected | retest_count, golden correlation, fixture_mn | quarantine + controlled retest |
| S02 | Lot-level anomaly detected (needs hold) | lot_id, fail_reason_code trend, alarm_id | hold lot + root-cause workflow |
| Alarm | Trigger | Threshold version | Action |
|---|---|---|---|
| ALM-GOLDEN-001 | Golden unit correlation drifts beyond band | ALM-V-R03 | stop/downgrade station, recalibrate assets |
| ALM-DRIFT-002 | Station trend: SFDR/INL shifts over time window | ALM-V-R03 | force station check + quarantine recent lots |
| ALM-RETEST-003 | Retest_count exceeds cap or pattern indicates abuse | ALM-V-R03 | auto-bin to quarantine, audit procedure |
| ALM-LOT-004 | Lot anomaly: fail_reason spike (e.g., BIST or CONTACT) | ALM-V-R03 | hold lot, trigger supplier/design review |
Feedback mapping: metric drift → ownership → action
- SFDR drops with golden correlation failure often points to station clock/capture chain or shielding changes (asset checks first).
- INL jumps localized to key codes often points to contact instability or code-set/recipe drift (lock recipe + fixture health evidence).
- BIST codes clustering by lot/wafer should trigger lot hold and supplier/process investigation (trace by lot_id/wafer_id).
- Calibration anomalies require coef format/CRC/bank evidence and rollback to last-known-good (audit storage first).
Request a Quote
FAQs — Production Test & BIST
These FAQs focus only on production test coverage, BIST usage, loopbacks, fast spectral/DC checks, false-fail control, and traceable reporting. Each answer includes a compact action plan and the minimum fields to log for auditability.
What must “production coverage” guarantee for a DAC test program?
Production coverage should guarantee screening for defects, performance guardrails, and traceable calibration support under UPH constraints.
Do this
- Define coverage tiers (Basic vs Full) with a fixed test list (DC, spectral, sync, BIST, calibration verify).
- Separate hard screens (functional) from grading (performance) and document bin rules.
- Lock recipe/limits versions to prevent station tuning and preserve auditability.
Log these fields
serial_no, lot_id, temp_point_id, station_id, fixture_mn, test_recipe_v, limit_v, bin_code, fail_reason_code
Common traps
- Using “PASS/FAIL only” without bins hides root causes and inflates retests.
- Changing limits at the station breaks comparability across lots and weeks.
How many FFT frequency points are enough for production SFDR/THD screening?
For production speed, 1–3 representative tone points usually provide strong defect discrimination, plus one “stress” point if the product requires it.
Do this
- Pick points to cover low/mid/high band where distortion and coupling differ.
- Use a mask + guard band instead of chasing single-bin spurs.
- Keep tone bins coherent with record length to avoid spectral leakage artifacts.
Log these fields
freq_id, fin_hz, record_len_n, window_id, sfdr_db, thd_db, sndr_db, mask_id, guard_band_db
Common traps
- Adding many frequency points increases time but does not fix unstable measurement chains.
- Comparing SFDR numbers across stations without identical record/window settings.
How short can FFT record length be before SFDR becomes unstable?
Record length can be shortened only until the estimator variance stays below the guard band and station noise floor remains well separated from spur limits.
Do this
- Validate stability with repeated runs on a golden unit and compute σ(SFDR) per station.
- Use a fixed window and coherent tone bin selection to minimize leakage.
- Set guard bands so statistical variation does not cause false fails.
Log these fields
record_len_n, repeats_k, sfdr_db, sfdr_sigma_db, station_id, golden_unit_mn, limit_v, guard_band_db
Common traps
- Shortening N without quantifying σ causes yield swings and “mystery drifts.”
- Blaming DUT when station noise dominates the spur region.
Full-code sweep is too slow—how can INL/DNL be screened without missing major-carry issues?
Use a two-tier code strategy: always test a fixed set of “key codes” (major boundaries) and add sparse sampling for broader coverage.
Do this
- Define key-code sets: near midscale, segment boundaries, and major carry transitions.
- Use fixed settling/averaging per code to keep station-to-station repeatability.
- Separate screening thresholds from grading thresholds (bins) to avoid overfailing.
Log these fields
code_set_id, key_codes_list_hash, settle_us, avg_count, inl_lsb, dnl_lsb, offset_lsb, gain_ppm, bin_code
Common traps
- Changing code sets by station breaks historical comparability and masks lot issues.
- Using too-aggressive averaging hides contact noise until it becomes escapes.
BIST passes but external tests fail—what are the most common blind spots?
A BIST PASS often indicates internal logic is healthy, but it may not cover external loading, fixture coupling, or system-level clocks/capture limits.
Do this
- Treat BIST as a fast screen; pair it with a minimal external metric (e.g., one spectral point or key-code DC check).
- If external fails cluster by station, inspect fixture_mn/cable_set_mn correlations first.
- Log and trend BIST codes; code patterns often correlate with specific missing hooks.
Log these fields
bist_code, bist_runtime_ms, station_id, fixture_mn, cable_set_mn, external_test_id, sfdr_db, inl_lsb, fail_reason_code
Common traps
- Claiming analog distortion coverage from a digital-only loopback/BIST.
- Ignoring station clustering and escalating to design before checking assets.
How should built-in sine/step be configured to be production-grade?
Built-in generators become production-grade when amplitude, timing, and capture are locked, and results are evaluated with robust metrics (mask/settling rules).
Do this
- Choose sine amplitude below clip but high enough to separate noise from spur limits.
- Choose coherent tone bin/record length; lock window, repeats, and estimator method.
- For step: lock step size and define settling/overshoot measurement points consistently.
Log these fields
tone_id, fin_hz, tone_amp_fs, record_len_n, window_id, sfdr_db, step_id, step_amp_lsb, settle_us, overshoot_pct
Common traps
- Changing amplitude/frequency per station to “help yield.”
- Using step results to diagnose stability without recording load configuration.
Digital loopback vs mixed-signal loopback—what can each actually validate?
Digital loopback validates registers, interface timing, and data paths; mixed-signal loopback can add gain/offset and partial dynamic checks but remains limited by the capture chain.
Do this
- Use digital loopback for fast functional screens and configuration audits.
- Use mixed-signal loopback only with declared coverage claims and stable capture calibration.
- Keep a minimal external check to catch load/fixture-driven failures.
Log these fields
loopback_mode, coverage_claim_id, compare_threshold, capture_chain_id, capture_cal_v, pass_fail, fail_reason_code
Common traps
- Assuming mixed loopback measures absolute SFDR without capture-chain calibration evidence.
- Using loopback-only coverage for products sensitive to external loading.
How should retest limits be set without hiding real escapes?
Retest should be a controlled diagnostic tool, not a yield tool. Cap retests and quarantine units that require repeated attempts.
Do this
- Define max retries per failure class (contact-suspected vs hard functional) and enforce it in software.
- Create a quarantine bin (Rxx) when retest_count exceeds the cap.
- Require a station/fixture check when retest patterns spike.
Log these fields
retest_count, first_fail_reason, final_bin_code, station_id, fixture_mn, time_stamp, rule_id, action_taken
Common traps
- Allowing unlimited retests creates escapes and destroys yield truth.
- Failing to quarantine hides intermittent contact issues that later become returns.
How does golden-unit correlation detect station drift quickly?
A golden unit provides a stable reference. If its metrics drift at one station, the measurement chain is drifting, not the DUT population.
Do this
- Run the golden unit at a fixed schedule (per shift or per X hours) using the same recipes and limits.
- Trend key metrics and alarm when deviation exceeds a control band.
- Stop or downgrade the station until fixture/instrument checks pass.
Log these fields
golden_unit_mn, golden_check_ts, station_id, fixture_mn, sfdr_db, inl_lsb, alarm_id, alarm_threshold_v
Common traps
- Using multiple “goldens” without certification/version tracking.
- Allowing recipe differences between golden checks and production runs.
What must be logged as material-number traceability for fixtures and software?
Any item that can change results must be traceable by a material number or version so anomalies can be correlated and contained.
Do this
- Assign material numbers to fixture, probe, cable sets, and calibration kits (asset DB).
- Treat limits, test packages, and schemas as versioned items and log their IDs.
- Block test execution if required IDs are missing (data completeness gate).
Log these fields
fixture_mn, probe_mn, cable_set_mn, cal_kit_mn, golden_unit_mn, test_pkg_v, limit_v, schema_v
Common traps
- Correlating by “station name” without asset identifiers misses root cause.
- Updating limit files without a version bump creates untraceable yield shifts.
How can calibration coefficients be made auditable (CRC, versioning, rollback)?
Coefficients are auditable when storage integrity and provenance are logged: format version, CRC, timestamp, and a last-known-good rollback path.
Do this
- Store coef_fmt_v, coef_bank_id, coef_crc, and write_count with every programming event.
- Verify by read-back and a minimal validation test (e.g., offset/gain summary) after write.
- Support rollback to last-known-good if CRC fails or verification fails.
Log these fields
cal_coef_fmt_v, cal_coef_crc, cal_bank_id, cal_write_count, cal_ts, verify_pass, offset_lsb, gain_ppm, limit_v
Common traps
- Treating coefficients as “internal details” with no versioning makes field returns untraceable.
- Writing too often without tracking write_count risks endurance failures.
